Abstract
  The Industry needs a common Mobile Data synchronization Protocol
  Characteristics of a common synchronization Protocol
  The SyncML inititiative

Abstract

The popularity of mobile computing and communications devices can be traced to their ability to deliver information to users when needed. Users want ubiquitous access to information and applications from the device at hand, plus they want to access and update this information on the fly.

The ability to use applications and information on one mobile device, then to synchronize any updates with the applications and information back at the office, or on the network, is key to the utility and popularity of this pervasive, disconnected way of computing.

Unfortunately, today we cannot achieve these dual visions:

• Networked data that support synchronization with any mobile device
• Mobile devices that support synchronization with any networked data

Rather, there is a proliferation of different, proprietary data synchronization protocols for mobile devices. Each of these protocols is only available for selected transports, implemented on a selected subset of devices, and able to access a small set of net-worked data. The absence of a single synchronization standard poses many problems for end users, device manufacturers, application developers, and service providers.

SyncML is a new industry initiative to develop and promote a single, common data synchronization protocol that can be used industry-wide. Driving the initiative are Ericsson, IBM, Lotus, Motorola, Nokia, Palm Inc., Psion, Starfish Software. Additional companies are being recruited to join and participate.

The SyncML initiative expects to release an open protocol for data synchronization, called SyncML, mid 2000.

The Industry Needs a Common Mobile Data Synchronization Protocol

Mobile computing has an Achilles heel - data synchronization. All the popular mobile devices - handheld computers, mobile phones, pagers, laptops - synchronize their data with network applications, desktop calendars, and other locations where information is stored. This ability to access and update information on the fly is key to the pervasive nature of mobile computing. Yet, today, almost every device uses a different technology for performing data synchronization.

What is a Synchronization Protocol?

By definition, mobile users are not always connected to a network and its stored data. Users retrieve data from the network and store it on the mobile device, where they access and manipulate the local copy of the data. Periodically, users reconnect with the network to send any local changes back to the networked data repository. Users also have the opportunity to learn about updates made to the networked data while the device was disconnected. Occasionally, they need to resolve conflicts among the updates made to the networked data. This reconciliation operation - where updates are exchanged and conflicts are resolved -is known as data synchronization.

Data synchronization, then, is the process of making two sets of data look identical. For a mobile device, synchronization applies to the data that the mobile device stores locally.

A data synchronization protocol defines the workflow for communication during a data synchronization session when the mobile device is connected to the network. The protocol must support naming and identification of records, common protocol commands to synchronize local and network data, and it can support identification and resolution of synchronization conflicts.

The Synchronization Problem Today

Today the industry offers a variety of non-interoperable data synchronization products, each connecting data from a few types of data repositories to a few devices. Each protocol functions only for selected transports, and is implemented on a few devices. Most synchronization products use different communication protocols over the network. The proliferation of non-interoperable synchronization technologies complicates the tasks of users, device manufacturers, service providers, and application developers. The lack of a common data synchronization protocol is impeding the growth in use of mobile devices, restricting users' ability to access data, and limiting the delivery of mobile data services.

Back to top

Benefits of a Common Synchronization Protocol

Let's look at each group that will benefit from adoption of an industry-wide data synchronization protocol.

• End Users - Today's user of mobile devices is probably using a different synchroni-zation product with every device. That is, there is one procedure for synchronizing files between a laptop and networked data, another for synchronizing calendar on a handheld computer, and yet another remote access to email. Each technology can synchronize only a few applications, or is limited to a particular type of network connection. This arrangement is expensive to install, confusing to configure and operate, and costly to administer. With SyncML, they will be able to buy devices that synchronize with a broader range of data.

• Device Manufacturers - While every device manufacturer wants to support the technologies that will support the data access needs of all users and service providers, in practice a device will support one data synchronization technology. This choice is forced upon the manufacturer by constraints of storage space, memory, power consumption, and cost. Device manufacturers will benefit from a common protocol that will make the device interoperable with a broader range of applications, services, and network and transmission technologies.

• Service Providers - Service providers moving into the growth arena of application hosting are particularly concerned that a proliferation of synchronization technologies will make it impossible to deploy and support their customers in a cost-effective man-ner. Already, to support the range of data types and devices in use, service providers must install and configure multiple server infrastructures, maintain and support that infrastructure, and maintain compatibility and performance. The alternative now available, to use a single solution for data connectivity, involves the risk of a tight coupling to a proprietary solution. With SyncML, they will be able to provide connecti-vity to a wider selection of applications.

• Application Developers - Choosing to support multiple synchronization technolo-gies enables an application to support more types of devices and networked data, but that choice comes at a cost. The developer loses the flexibility of evolving the choice of networked data repository while maintaining backward compatibility. It also increases the cost of application development and the complexity of the resulting product. The added complexity of the networked data repository can create a barrier to installation and adoption by service providers. With SyncML, they will be able to develop an application that can connect to a more diverse set of devices and networ-ked data.

Back to top

Characteristics of a Common Synchronization Protocol

The goal of a common synchronization protocol is symmetric. It would connect any to any, over any network. That is, it would:

• Synchronize networked data with any mobile device
  
• Synchronize a mobile device with any networked data

The data synchronization protocol would synchronize networked data with many different devices, including handheld computers, mobile phones, automotive computers, and desktop PCs. A user could access and manipulate the same set of data from different devices. For example, a user could read e-mail from either a handheld or a mobile phone, and still maintain a consistent, updated record of which messages had been read.

Similarly, with any-to-any synchronization, mobile devices could support more types of data, including e-mail, calendar, contact management information, enterprise data stored in databases, and documents on the web. With such functionality a user who received an order via e-mail could access the company inventory system on the same device to determine a delivery date.

To accomplish this goal, the protocol needs the following characteristics:

• Operate effectively over wireless and wireline networks
• Support a variety of transport protocols
• Support arbitrary networked data
• Enable data access from a variety of applications
• Address the resource limitations of the mobile device
• Build upon existing Internet and Web technologies
• The protocol's minimal function needs to deliver the most commonly required
  synchronization capability across the entire range of devices.
  

Effective Over Wireless and Wireline Networks

A common synchronization protocol must work over all networks used by mobile devices, both wireless and wireline. The various wireless networks commonly used by mobile devices demand the most from a protocol, since these wireless networks share common features of high network latency, limited bandwidth, relatively high packet costs, and low reliability of both data and connectivity.

• High network latency - Network latency is the delay introduced when a packet is momentarily stored, analyzed and then forwarded. Wireless networks, with a high latency, require a robust synchronization protocol.
• Limited bandwidth - To minimize bandwidth requirements and the associated pro-cessing demands, the protocol should allow alternate binary encoding techniques to both the data and the synchronization commands. The WBXML (WAP Binary XML) standard adopted by the WAP Forum and submitted to the W3C represents a good candidate encoding technique for limited bandwidth environments.
• Relatively high packet costs - The protocol must minimize the number of request-response interactions between the device and the networked data. An optimal protocol would generate a single request-response pair of messages. In this model, a request from a mobile device would contain all updates to its local data. The response message would provide the updates, with conflicts already identified and possibly resolved. Any protocol adopted by the industry should seek to enable this minimalist messaging model.
• Low reliability of both data and connectivity - In order to function with only intermittent connection to the network, the protocol must survive inadvertent disconnection during the synchronization procedure. Even when a disconnection is encountered, the protocol must ensure that the device and the networked data repository stay consistent and make progress when the connection is reestablished.

Support Various Transport Protocols and Media

Since wireless networks employ different transport protocols and media, a protocol must work smoothly and efficiently over:

• HTTP 1 (i.e. the Internet)
• WSP (the Wireless Session Protocol, part of the WAP protocol suite)
• OBEX (i.e. Bluetooth, IrDA, and other local connectivity) It can also be deployed over: ¥ SMTP, POP3, and IMAP
• Pure TCP/IP networks
• Proprietary wireless communication protocols

An effective synchronization protocol cannot depend on any capabilities that cannot be made available over these transports. To be efficient, the protocol should minimize duplicating features provided by the transport.

A reliable request-response model can be efficiently deployed across all of these trans-port protocols. An effective protocol could be built on this model. Moreover, defining a MIME (Multi-Purpose Internet Mail Extensions) content-type for the protocol units will allow the protocol to be transported across any of these different transports. Optional enhancements to the transport protocol should include security and compression capabilities.

Back to top

Support Arbitrary Networked Data

Since a design goal is for mobile devices to communicate with a broad range of networ-ked data, the protocol must support concurrent synchronization with multiple network data repositories. The protocol should not mandate how data is represented or structu-red on the device or within the networked data repository after synchronization is com-plete.

To ensure interoperability, the protocol must describe how common data formats are represented over the network. To ensure extensibility, the protocol should permit the definition of new data formats as needs arise. In addition, the protocol must allow implementers to define experimental, non-standard synchronization protocol primitives.

The common data formats that a protocol must support from the outset include:

• Common personal data formats, such as vCard for contact information, vCalendar and iCalendar for calendar, todo, and journal information
• Collaborative objects such as e-mail and network news
• Relational data
• XML (the Extensible Markup Language) and HTML documents
• Binary data, binary large objects, or "blobs"

Enable Data Access from a Variety of Applications

The specification shall be programming language independent. In order to work effecti-vely with many applications, the synchronization protocol must not make assumptions about the programming language and cannot assume that both ends of the synchroni-zation process share a single language environment.

To facilitate rapid deployment of the protocol the reference code shall be provided for a common programming language. However, this will not restrict any implementation to only this language.

Address the Resource Limitations of the Mobile Device

Mobile devices have limited memory and processor capacity, a characteristic that sets the rules for developing a synchronization protocol.

The protocol implementation needs to fit within the memory footprint of the common mobile devices on the market today, in either static code or run-time execution space. In addition, the data exchanged by the protocol itself should be small and require mini-mal code to transfer it to and from the device. Data exchanged using the protocol may be encoded in a binary format (such as WBXML) to reduce memory requirements for storing received synchronization messages and reduce processor resources needed to parse and process that data.

A small footprint and processor requirement gives the protocol several key advantages. A small code size eases the porting overhead and increases the likelihood that imple-mentations will be available for all processor and/or operating system platforms. It also reduces device manufacturers' cost of adoption, an important consideration.

Optimally, a subset of the protocol would support embedded systems specialized for a particular type of data.

Build Upon Existing Internet and Web Technologies

Where possible, the protocol needs to make use of existing Internet and Web techno-logies. These technologies are implemented widely and are well tested, so their use within the protocol will ensure easy implementation and interoperability testing.

XML, the Extensible Markup Language, is rapidly emerging as the lingua franca for representing structured data over the Web. To the extent possible, the protocol should use XML to represent data being exchanged during a synchronization session.

Other useful standards in this space include MIME for registering the format of the data synchronization protocol messages.

Promote Interoperability

The protocol needs to be interoperable, synchronizing networked data with any mobile device and synchronizing a mobile device with any networked data. This includes a mar-ket space where mobile devices are small-footprint devices with minimal processor and memory resources and powerful network servers capable of executing sophisticated synchronization logic.

1.
Strictly speaking, HTTP usually runs over TCP/IP, so one might simply rely on the underlying TCP/IP connectivity. However, in many virtual private network (VPN) environments, HTTP is the only protocol that is allowed through corporate firewalls. Moreover, the HTTP abstraction has been deployed over a variety of proprietary networks and is, therefore, a useful abstraction in its own right.

The SyncML Initiative

To accelerate the market's vision of ubiquitous data access from any device to any networked data, Ericsson, IBM, Lotus, Motorola, Nokia, Palm Inc., Psion, Starfish Software have formed the SyncML initiative. This industry initiative will deliver a common synchronization protocol that can be used industry-wide.

SyncML initiative will work with end users, device manufacturers, data providers, infra-structure developers, application developers, and service providers to define a common mobile data synchronization protocol, SyncML. This protocol will meet the resource constraints of mobile devices and wireless networks and will provide the extensibility to support a range of data types. The goal of the SyncML initiative is to deliver the protocol in the future for formal adoption and maintenance by an established standards body.

To enable adoption of the SyncML, SyncML initiative will deliver:

• An architectural specification
• Two protocol specifications (SyncML representation protocol and SyncML synchronization protocol
• Bindings to common transport protocols
• Interfaces for a common programming language
• An openly available prototype implementation of the protocol

Information about the group, including information on how to join the SyncML initiative, is available on its web site www.SyncML.org

The SyncML initiative is actively recruiting members of existing groups to join in the SyncML efforts.

Back to top