For the purposes of the present document, the following terms and definitions apply: Bluetooth: bvCalendar: bvCard: GET: IrDA: Latency: Level 1: Level 2: Level 3: Level 4: Personal Area Network: PUT: Radio Frequency (RF): Synchronization: SyncML initiative: Ultra: vCalendar: vCard: WAP: Wide Area Devices: Wide Area Network: Wireless Information Devices:

For the purposes of the present document, the following abbreviations apply: DID IAS IBM ICNIRP IETF IMC Ir IrDA IrLAP IrLMP IrMC IrOBEX LUID MDSP MNCRS OBEX PDA PIM SyncML TTP WAP WBXML: WML: XML:

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.

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

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.

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.

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.

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.

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:

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.