Tech-invite
Overview21222324252627282931323334353637384‑5x

Top   in Index   Prev   None

TR 27.903
Discussion of Synchronization Standards

Use "3GPP‑Page" to get the Word version, and "ETSI‑search" to get the PDF version
V4.0.0 (PDF)  2001/04  13 p.
V3.0.0  1999/10  11 p.
Rapporteur:
Mr. Monrad, AtleEricsson LM

Content for  TR 27.903  Word version:  4.0.0

Here   Top

1  ScopeWord‑p. 5
The present document provides information on existing synchronization protocols. It summarizes proprietary and standard protocols relevant to current and future mobile communication devices.
The present document covers only synchronization between end-user devices, desktop applications, and server-based information services. It does not refer to replication or synchronization between enterprise databases.

2  References

The following documents contain provisions which, through reference in this text, constitute provisions of the present document.
  • References are either specific (identified by date of publication, edition number, version number, etc.) or non specific.
  • For a specific reference, subsequent revisions do not apply.
  • For a non-specific reference, the latest version applies. In the case of a reference to a 3GPP document (including a GSM document), a non-specific reference implicitly refers to the latest version of that document in the same Release as the present document.
[1]
Bluetooth: Bluetooth SIG, Bluetooth Specifications, version 1.0, July 1999. (http://www.bluetooth.com/)
[2]
Generic Binary Object: Infrared Data Association, "IrWW IrDA for Wrist Watches", "Generic Binary Object" Chapter 4, version 0.5, 12 July 1999. (members section of ftp://ftp.irda.org/)
[3]
ICNIRP: "Guidelines for limiting exposure to time-varying electric, magnetic, and electromagnetic fields (up to 300 GHz)", International Commission on Non-Ionizing Radiation Protection (ICNIRP), Health Physics, vol. 74, pp 494-522, April 1998.
[4]
IrLAP: Infrared Data Association, "Serial Infrared Link Access Protocol (IrLAP)", version 1.1, 16 June 1996, plus all applicable errata. (http://www.irda.org/)
[5]
IrLMP, Infrared Data Association, "Link Management Protocol", version 1.1, 23 January 1996, plus all applicable errata. (http://www.irda.org/)
[6]
IrMC, Infrared Data Association, "Specifications for Ir Mobile Communications (IrMC)", version 1.1, 01 March 1999, plus all applicable errata. (http://www.irda.org/)
[7]
IrOBEX, Infrared Data Association, "Ir Object Exchange Protocol IrOBEX", version 1.2, April 1999, plus all applicable errata. (http://www.irda.org/)
[8]
MNCRS, Mobile Network Computing Reference Specification Consortium, Mobile Network Computing Reference Specification, Data Synchronization Work Group, Application Programmer's Guide to Mobile Network Computer Data Synchronization, version 1.1, March 1999. (http://www.oadg.or.jp/activity/mncrs/mncrs03-99.html)
[9]
MDSP - Mobile Data Synchronization Protocol.
[10]
Tiny TP, Infrared Data Association, "'Tiny TP': A Flow-Control Mechanism for use with LrLMP", version 1.1, 20 October 1996, plus all applicable errata. (http://www.irda.org/)
[11]
Various documents produced for "Synchronization".
[12]
vCalendar, the Internet Mail Consortium, "vCalendar - The Electronic Calendaring and Scheduling Exchange Format - Version 1.0", 18 September 1996. (http://www.imc.org/pdi/vcal-10.doc)
[13]
vCard, the Internet Mail Consortium, "vCard - The Electronic Business Card - Version 2.1", 18 September 1996.(http://www.imc.org/pdi/vcard-21.doc)
[14]
WAP, WAP Forum, "WAP Technical Specifications Suite", version 1.1, June 1999. (http://www.wapforum.com/)
[15]
SyncML initiative, SyncML Technical Specifications, version 1.0 (http://www.syncml.org)
Up

3  Definitions and AbbreviationsWord‑p. 6

3.1  Definitions

For the purposes of the present document, the following terms and definitions apply:
Bluetooth:
a technology specification [1] for short range radio links between mobile PCs, mobile phones and other portable devices. (http://www.bluetooth.com/)
bvCalendar:
a compressed version of vCalendar as defined in the IrDA Generic Binary Object proposal [2].
bvCard:
a compressed version of vCard as defined in the IrDA Generic Binary Object proposal [2].
GET:
the operation of requesting that the server returns an object from to the client as defined in the IrDA IrOBEX specification [7].
IrDA:
an industry consortium set up to define a set of short range Ir communications standards. (http://www.irda.org/)
Latency:
time delay associated with the process of information exchange in a network.
Level 1:
minimum level support defined in the IrDA IrMC set of specifications [6].
Level 2:
Access Level support defined in the IrDA IrMC set of specifications [6].
Level 3:
Index Level support defined in the IrDA IrMC set of specifications [6].
Level 4:
Sync Level support defined in the IrDA IrMC set of specifications [6].
Personal Area Network:
a short range wireless connection between two or more devices for the purpose of transferring information. Short range is typically defined as fifty meters or less in distance.
PUT:
the operation of sending one object from the client to the server as defined in the IrDA IrOBEX specification [7].
Radio Frequency (RF):
the frequency range between 300 Hz and 300 GHz (ICNIRP definition [3]).
Synchronization:
the process of exchanging information between multiple physical or virtual locations for the purpose of ensuring that each location's copy of that information reflects the same information content.
SyncML initiative:
an industry initiative set up to define a data synchronization standard based on XML (http://www.syncml.org/)
Ultra:
a connectionless information transfer mechanism defined as part of the IrDA IrMC set of specifications [6].
vCalendar:
a format defined by the IMC for electronic calendaring and scheduling exchange [12] with extensions as defined in the IrDA IrMC set of specifications [6].
vCard:
a format defined by the IMC for electronic business card exchange [13] with extensions as defined in the IrDA IrMC set of specifications [6].
WAP:
an industry consortium set up to define a set of standards [14] to empower mobile users with wireless devices to easily access and interact with information and services. (http://www.wapforum.com/)
Wide Area Devices:
devices intended for use in 3G systems.
Wide Area Network:
a geographically-large range wireless connection between two or more devices for the purpose of transferring information. Large geographical range is typically defined as one kilometer or more in distance.
Wireless Information Devices:
wide area and short range devices intended for information transfer.
Up

3.2  AbbreviationsWord‑p. 7
For the purposes of the present document, the following abbreviations apply:
DID
Database IDentifier
IAS
Information Access Service
IBM
International Business Machines
ICNIRP
International Commission on Non-Ionizing Radiation Protection
IETF
Internet Engineering Task Force
IMC
Internet Mail Consortium
Ir
Infrared
IrDA
Infrared Data Association
IrLAP
Infrared Link Access Protocol
IrLMP
Infrared Link Management Protocol
IrMC
Ir Mobile Communications
IrOBEX
Ir Object EXchange
LUID
Unique object IDentifier
MDSP
Mobile Data Synchronization Protocol
MNCRS
Mobile Network Computer Reference Specification
OBEX
Object Exchange
PDA
Personal Digital Assistant
PIM
Personal Information Manager
SyncML
Synchronization Markup Language
TTP
Tiny TP
WAP
Wireless Application Protocol
WBXML:
Wireless Binary XML
WML:
Wireless Markup Language
XML:
eXtensible Markup Language
Up

4  Summary of Standards Activities

4.1  IrMC

The IrMC standard [6] was developed as an extension to the IrDA standard for the purpose of providing an open standard for data exchange between mobile devices or between mobile devices and desktops or PDAs. Among other things, IrMC defines four levels of support for information exchange. By definition, each higher level must support all of the preceding levels. The four levels are: Level 1 (Minimum Level), Level 2 (Access Level), Level 3 (Index Level), and Level 4 (Sync Level). (Level 4 does not require Level 3) Level 2 and Level 4 are the most relevant for synchronization. IrMC has been adopted by the IrDA and Bluetooth initiatives.
Up

4.2  Bluetooth

Bluetooth has adopted the IrMC standard [6] as the basis for their synchronization specification.

4.3  WAP

WAP [14] has not specified a synchronization standard. The WAP Forum is currently evaluating synchronization technologies and is expected to identify a technology later this year.

4.4  Other Standards ActivitiesWord‑p. 8

4.4.1  MNCRS

The MNCRS [8] (Mobile Network Computer Reference Specification) specifies an application programming interface (API) providing data-synchronization services focused on Java-enabled devices. MNCRS is promoted by a number of companies but has not been adopted by any formal standards body.

4.4.2  Synchronization

A group met informally in early 1999 for the purpose of defining a synchronization specification [11] to be presented to the 3GPP or WAP bodies. The parties involved - Symbian, Puma, Ericsson, Nokia, Motorola, Starfish, and Lotus - disbanded before any agreement was reached.

4.4.3  MDSP

MDSP [9] (Mobile Data Synchronization Protocol) is a data synchronization and data exchange protocol for networked devices promoted by IBM. It is designed primarily for use between mobile devices that are sporadically connected to the network and servers that are continuously connected to the network. In particular, MDSP is designed to handle the case where the server and device store the data they are synchronizing in different formats, using different software systems. MDSP can be used to exchange data elements, without attempting to synchronize the containers as used in a one-way synchronization to a device with no editing capabilities. MDSP has not been adopted by any formal standards body.
Up

4.5  SyncML

SyncML is an XML-based specification for data synchronization. It accommodates not only traditional local synchronization but also the special requirements associated with remote synchronization in wide-area wireless environments with intermittent connectivity. SyncML is based on a client-server model. SyncML specifications consist of three major components: representation protocol, synchronization protocol, and transport bindings. The Representation protocol defines XML-based messages for synchronization, whereas the Synchronization protocol defines synchronization in the form of message sequence charts. The Transport binding specification defines a mechanism to carry synchronization messages over different transport mechanisms.
Up

5  Overview of Synchronization Standards

5.1  Introduction

3G Wireless Information Devices will enable unprecedented access to information regardless of location. Information will continue to be stored on personal computers or servers, however users will also expect to be able to have access to that same information on handheld or palm-size devices and wireless devices.
To date, there are two adopted standards that address synchronization: IrMC and SyncML. The IrMC standard [6] is also referenced in the Bluetooth specification.
The IrMC standard [6] is defined for personal area networks running either low or high bandwidth wireless links and may be used in connection-oriented or connectionless links such as IrDA or Bluetooth. It does not currently support a specifically optimized mode for wide area network synchronization. Wide area network synchronization presents a unique set of problems for efficient and accurate synchronization.
The SyncML standard [15] is designed for use between mobile devices that are intermittently connected to the network and services that are continuously available to the network. SyncML may also be used for peer-to-peer data synchronization. SyncML is designed specifically to be format-agnostic with respect to the data to be synchronized between network services and mobile devices.
Up

5.2  IrMC OverviewWord‑p. 9
The IrMC version 1.1 specification [6] was driven by leading handset manufacturers to provide a standard means for exchanging data between mobile devices and between mobile devices and desktop, handheld PCs, and Printers of various kinds. The focus of the original specification was to extend the IrDA standard to include extensions for transferring Personal Information Manager (PIM) data, files, and isochronous voice between co-operating IrMC devices. The current IrMC specification [6] supports data exchange with Phone Book, Calendar, Messaging and Note applications on mobile devices.
The specification was recently updated (version 1.1 [6]) to better support synchronization features requested by the Bluetooth initiative, which is also committed to using IrMC version 1.1 [6] and its supporting IrOBEX [7] object exchange layer for satisfying its data exchange needs over short-distance radio links.
The scope of the IrMC specification [6] encompasses more than synchronization. Components of IrMC deal with Call Control (for mobile handsets), real time audio transmission, and permissions for getting and setting the real time clock on the mobile device. IrMC also defines four (4) distinct levels of support for information exchange, where each higher level is expected to support the preceding levels (with some exceptions, see above). For purposes of synchronization, Level 2 (Access Level) and Level 4 (Sync Level) are the only information exchange levels required to address our stated requirements.
The IrMC specification [6] and its supporting IrOBEX [7] object exchange layer is layered on top of the pre-existing IrDA stack. Since the IrMC synchronization component requires either the Connection Oriented Service or the Connectionless Oriented Service, this means that IrMC and IrOBEX, when used in an IrDA application, sit atop of the IrDA layers IrLAP [4], IrLMP [5], and possibly TTP [10] and IAS [5]. Thus, the IrMC specification [6] is a natural extension of the IrDA stack. When used in Bluetooth, IrMC and IrOBEX sit atop the Bluetooth equivalent of these layers. The object is to swap transport and below layers while keeping a common set of applications.
The information exchange levels of IrMC prescribe the text-based data formats that must be exchanged between two mobile devices. Wherever possible, industry-standard data formats are used. Where no pre-existing data format exists, IrMC defines new formats that must be supported by implementers. Required data formats include IMC's vCard [13] and vCalendar [12] plus the similarly defined constructs vMessage [6] and vNote [6]. In addition, custom data formats are prescribed for exchanging data objects (such as change logs, information logs, error logs and device information). IrMC is currently evaluating allowing the use of the IETF versions of these constructs, the binary versions called bvCard [2] and bvCalendar [2], plus a completely generic Generic Binary Object [2].
IrMC effectively addresses the synchronization needs of PIM applications residing on mobile devices, and operating in a connected or connectionless environment. At the highest level (Level 4), IrMC specifies core functionality such as database identifiers (DID), unique object identifiers (LUID), change logs and change counters or time stamps which are essential to ensure fast and reliable synchronization. The specification also includes a rich set of features for exchanging PIM data. Included in this is an Information Log that describes the characteristics of each database, a Device Information block that identifies each device with capabilities, an optional Error Log that returns record-level error codes, a mechanism for detecting new items entered while synchronization is in progress, and a means for detecting device resets.
Up

5.3  IrMC 1.1 Limitations for Wide Area Synchronization

IrMC was written to address the exchange of PIM data in a personal area network or peer-to-peer environment. However, the current IrMC specification [6] has not yet addressed synchronization in a wide area wireless network environment such as that which would exist in a 3GPP scenario.
The limitations of IrMC in a 3G environment are as follows:

5.3.1  Level 4 Dependent on Connection-based Transport Protocol

IrMC Level 4 (Sync Level) requires either a Connection Oriented Service, when using IrDA involves components such as IrLAP [4] and IrLMP [5]. By its nature, IrOBEX [7] involves establishing an explicit connection between devices, performing the necessary data exchange, and then disconnecting. A persistent connection between devices is difficult to maintain in some Wide Area Network environments. Latency can slow the transactions to an unacceptable level, or worse, cause synchronization to be stopped due to timeouts.
Up

5.3.2  Inefficient Data ExchangeWord‑p. 10
Data exchanges between an IrMC client and server tend to be chatty and quite inefficient. In particular, each object sent between devices requires a separate request/response pair using IrOBEX [7] commands. For example, GET operations entail a request and response for each object. PUT Operations can be more efficient in an Ultra [6] environment since no response is expected.

5.4  SyncML

The SyncML initiative [15] is a group of companies who have co-operated to produce an open specification for data synchronization. SyncML is a data synchronization specification that contains the following main components:
  • An XML-based data representation protocol,
  • A synchronization protocol, and
  • Transport bindings for the synchronization protocol.
The data representation specifies an XML DTD that allows the representation of all the information required to perform synchronization, including data, metadata and commands. The synchronization protocol specifies how SyncML messages conforming to the DTD are exchanged in order to allow a SyncML client and server to exchange additions, deletions, updates, and other status information. The synchronization protocol supports both two-way and one-way synchronization.
There are also DTDs which define the representation of information about the device such as memory capacity and the representation of various types of meta information such as security credentials.
Although the SyncML specification defines transport bindings that specify how to use a particular transport to exchange messages and responses, the SyncML representation and synchronization protocols are transport-independent. Each SyncML package is completely self-contained, and could, in principle, be carried by any transport. The initial bindings specified are HTTP, WSP, and OBEX. There is no reason why SyncML could not be implemented using other bindings such as email or message queues. Because SyncML messages are self-contained, multiple transports may be used without either the server or client devices having to be aware of the network topology. Thus, a short-range OBEX connection could be used for local connectivity with the messages being passed via HTTP to an Internet-hosted synchronization server.
Either the client or the server may initiate a synchronization session and both one-way and two-way synchronization are supported. Both linear and star synchronization topologies may be implemented using SyncML.
To reduce the data size, a binary coding of SyncML based on the WAP Forum's WBXML is defined. Messages may also be passed in clear text if required. In this and other ways SyncML addresses the bandwidth and resource limitations imposed by mobile devices.
SyncML is both datatype and datastore independent. SyncML can carry any datatype that can be represented as a MIME object. To promote interoperability between different implementations of SyncML, the specification includes the representation formats used for common PIM data. A conforming implementation of SyncML must use these data formats.
SyncML is an evolutionary synchronization protocol - it takes the best from IrMC, MDSP, MAL, and others, and combines them with XML and MIME datatypes to create an efficient data synchronization protocol.
Up

6  Conclusions

To address the limitations of IrMC Level 4 synchronization in a Wide Area Network, one of two actions must occur.
  1. Modifications to the IrMC Level 4 to address the above limitations within the Wide Area Network must be made.
  2. An extension to IrMC Level 4 for Wide Area Network Synchronization must be created. Ideally, this extension would operate on top of existing stacks and would use as much existing code base as possible.
SyncML synchronization does not appear to have such issues and appears to have the necessary Wide Area Network support already incorporated.
Up

$  Change HistoryWord‑p. 11

Up   Top