CR page 1

Release #

3GPP TS %&'1(3 )#'('( "%((%*(+$

3GPP TS 27.103 V5.0.0 (2002-06)

Technical Specification

UMTS, terminal, WAN, !n"#r$ni%ati$n

%eywords

3GPP

3rd Generation Partnership Project; Postal address Technical Specification Group Terminals; Wide area network s nchroni!ation standard 3GPP support office address 650 &$'te (e )'"i$le - S$*#ia Anti*$li "Release #$ Val+$nne - ,&AN-.
Tel./ 033 1 22 21 12 00 ,a3/ 033 1 23 65 17 16

&nternet
#tt*/44555.36**.$r6

Copyright Notification 'o part may be reproduced e(cept as authori!ed by written permission. The copyri ht and the fore oin restriction e(tend to reproduction in all media.
) *++*, 3GPP Or has ani!ational Partners (-.&/, 2T"&, T3, TT-, TT0). The present document been developed within the 3 rd 01T", Generation Partnership Project (3GPP TM) and may be further elaborated for the purposes of 3GPP.
The present document has not been subject to any approval process by the 3GPP Or ani!ational Partners and shall not be implemented. This "pecification is provided for future development wor# within 3GPP only. The Or ani!ational Partners accept no liability for any use of this "pecification. "pecifications and reports for implementation of the 3GPP TM system should be obtained via the 3GPP Or ani!ational Partners$ Publications Offices.

-ll ri hts reserved.

3GPP

Release #

3GPP TS %&'1(3 )#'('( "%((%*(+$

-$ntent
0ontents....................................................................................................................................................3 4oreword...................................................................................................................................................5 3 "cope......................................................................................................................................................6 * .eferences..............................................................................................................................................6 3 7efinitions and abbreviations.................................................................................................................6
3.3 7efinitions.............................................................................................................................................................6 3.* -bbreviations.........................................................................................................................................................8

5 /ac# round............................................................................................................................................9
5.3 &rM0 9 5.* /luetooth................................................................................................................................................................9 5.3 1-P 9 5.5 "yncM:................................................................................................................................................................9

6 "yncM:.................................................................................................................................................9
6.3 "yncM: Overview...............................................................................................................................................9 6.3.3 .educe the number of messa es bein sent over the air....................................................................................; 6.3.* .educe the messa e si!e.....................................................................................................................................; 6.3.3 Provide a robust authentication mechanism......................................................................................................; 6.3.5 Transport &ndependence.....................................................................................................................................; 6.3.6 7atatype &ndependence.......................................................................................................................................; 6.* 0han e of 0lient<"erver .oles from .elease ==...................................................................................................; 6.3 Transport /indin s................................................................................................................................................= 6.5 "ecurity..................................................................................................................................................................= 6.6 0onnection.............................................................................................................................................................= 6.8 "endin and .eceivin &nformation......................................................................................................................= 6.9 &ntermittent 0onnectivity.......................................................................................................................................= 6.; 0ompatibility with .elease ==...............................................................................................................................= 6.= >se 0ase with "yncM:....................................................................................................................................3+

Annex A (informative): Change history.......................................................................................11

3GPP

Release #

3GPP TS %&'1(3 )#'('( "%((%*(+$

,$re5$r(
This Technical "pecification has been produced by the 3rd Generation Partnership Project (3GPP). The contents of the present document are subject to continuin wor# within the T"G and may chan e followin formal T"G approval. "hould the T"G modify the contents of the present document, it will be re?released by the T"G with an identifyin chan e of release date and an increase in version number as follows@ Aersion (.y.! where@ ( the first di it@ 3 presented to T"G for informationB * presented to T"G for approvalB 3 or reater indicates T"G approved document under chan e control. y the second di it is incremented for all chan es of substance, i.e. technical enhancements, corrections, updates, etc. ! the third di it is incremented when editorial only chan es have been incorporated in the document.

3GPP

Release #

3GPP TS %&'1(3 )#'('( "%((%*(+$

S"$*e

This specification provides a definition of a 1ide -rea "ynchroni!ation protocol. The synchroni!ation protocol is based upon current synchroni!ation industry standards. The present document covers 1ide -rea 'etwor# "ynchroni!ation between current and future mobile communication end?user devices, des#top applications and server?based information servers. This is a livin document and, as such, it will evaluate new technolo ies (e. . CM:) for inclusion as they become readily available.

&e7eren"e
.eferences are either specific (identified by date of publication, edition number, version number, etc.) or non?specific. 4or a specific reference, subseDuent revisions do not apply. 4or 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 . E3F E*F E3F E5F /luetooth@ /luetooth "&G, /luetooth "pecifications, version 3.+, Guly 3===. (http@<<www.bluetooth.com<) &rM0, &nfrared 7ata -ssociation, H"pecifications for &r Mobile 0ommunications (&rM0)H, version 3.3, +3 March 3===, plus all applicable errata. (http@<<www.irda.or <) &rO/2C, &nfrared 7ata -ssociation, H&r Object 2(chan e Protocol &rO/2CH, version 3.*, -pril 3===, plus all applicable errata. (http@<<www.irda.or <) v0alendar, the &nternet Mail 0onsortium, Hv0alendar ? The 2lectronic 0alendarin and "chedulin 2(chan e 4ormat ? Aersion 3.+H, 3; "eptember 3==8. (http@<<www.imc.or <pdi<vcal ?3+.doc) v0ard, the &nternet Mail 0onsortium, Hv0ard ? The 2lectronic /usiness 0ard ? Aersion *.3H, 3; "eptember 3==8.(http@<<www.imc.or <pdi<vcard ?*3.doc) 1-P, 1-P 4orum, H1-P Technical "pecifications "uiteH, version 3.3, Gune 3===. (http@<<www.wapforum.com<) CM:, 130, I2(tensible Mar#up :an ua e (CM:) 3.+J, v3.+, .20?(ml?3==;+*3+, 4eb 3==; "yncM: initiative, "yncM: Technical "pecifications, version 3.+ (http@<<www.syncml.or ) 3GPP T. *9.=+3, 7iscussion of "ynchroni!ation "tandards

The followin documents contain provisions which, throu h reference in this te(t, constitute provisions of the present document.

E6F E8F E9F E;F E=F

3
3.1

8e7initi$n an( a++re9iati$n

8e7initi$n

4or the purposes of the present document, the followin terms and definitions apply@ Bluetooth@ a technolo y specification for short ran e radio lin#s between mobile P0s, mobile phones and other portable devices. (http@ <<www.bluetooth.com<)

3GPP

Release #

3GPP TS %&'1(3 )#'('( "%((%*(+$

GET@ the operation of reDuestin that the server returns an object to the client as defined in the &r7- &rO/2C specification GSM@ Global "ystem for Mobile communications TT!@ KyperTe(t Transfer Protocol "r#A@ an industry consortium set up to define a set of short ran e &r communications standards. (http@ <<www.irda.or <) $evel 1@ minimum level support defined in the &r7- &rM0 set of specifications $evel %@ access level support defined in the &r7- &rM0 set of specifications $evel &@ inde( level support defined in the &r7- &rM0 set of specifications $evel '@ sync level support defined in the &r7- &rM0 set of specifications Ma("tems: describes to the server the mappin of a local >&7 to a server >&7 M"ME @ Multipurpose &nternet Mail 2(tension !)T@ the operation of sendin one object from the client to the server as defined in the &r7- &rO/2C specification SS$@ "ecure "oc#et :ayer Syn* Alert: - "yncM: command for reDuestin a synchroni!ation on a particular datastore. Syn*hroni+ation@ the process of e(chan in information between multiple physical or virtual locations for the purpose of ensurin that each location$s copy of that information reflects the same information content Syn*M$ initiative: an industry initiative set up to define a data synchroni!ation standard based on CM: (http@<<www.syncml.or <) vCalen,ar@ a format defined by the &M0 for electronic calendarin and schedulin e(chan e with e(tensions as defined in the &r7- &rM0 set of specifications vCar,@ a format defined by the &M0 for electronic business card e(chan e with e(tensions as defined in the &r7&rM0 set of specifications -A!@ an industry consortium set up to define a set of standards to empower mobile users with wireless devices to easily access and interact with information and services. (http@ <<www.wapforum.com<) -i,e Area .et/or0@ a eo raphically?lar e ran e wireless connection between two or more devices for the purpose of transferrin information. :ar e eo raphical ran e is typically defined as one #ilometer or more in distance

3.2
0oo#ie &2T4 &M0 &r &r7&rM0 &rO/2C O/2C P7P&M "yncM: >&7 >.: 1-P 1/CM: 1M: 1"P

A++re9iati$n
a method of trac#in http?based information &nternet 2n ineerin Tas# 4orce &nternet Mail 0onsortium &nfrared &nfrared 7ata -ssociation &r Mobile 0ommunications &r Object 2Cchan e Object 2(chan e Personal 7i ital -ssistant Personal &nformation Mana er "ynchroni!ation Mar#up :an ua e. >niDue &dentification >niversal .esource :ocation 1ireless -pplication Protocol 1ireless /inary CM: 1ireless Mar#up :an ua e 1ireless "ession Protocol

4or the purposes of the present document, the followin abbreviations apply@

3GPP

Release #

&

3GPP TS %&'1(3 )#'('( "%((%*(+$

CM:

eCtensible Mar#up :an ua e

:a";6r$'n(

This bac# round material is a synopsis of the material presented in 3G T. *9.=+3. 'ote that .elease == is based on &rM0 "ync. This release reflects a chan e to "yncM:.

1.1

<rM-

The &rM0 standard was developed as an e(tension to the &r7- standard for the purpose of providin an open standard for data e(chan e between mobile devices or between mobile devices and des#tops or P7-s. -mon other thin s, &rM0 defines four levels of support for information e(chan e. /y definition, each hi her level must support all of the precedin levels. The four levels are@ :evel 3 (Minimum :evel), :evel * (-ccess :evel), :evel 3 (&nde( :evel), and :evel 5 ("ync :evel). :evel 5 does not reDuire :evel 3. :evel * and :evel 5 are the most relevant for synchroni!ation. &rM0 has been adopted by &r7- and /luetooth initiatives.

1.2 1.3

:l'et$$t# WAP

/luetooth has adopted the &rM0 standard as the basis for their synchroni!ation specification.

1-P has not specified a synchroni!ation standard. The 1-P 4orum is currently evaluatin synchroni!ation technolo ies and is e(pected to identify a technolo y later in *++3.

1.1

S!n"M)

"yncM: is an CM:?based specification for data synchroni!ation. &t accommodates not only traditional local synchroni!ation but also the special reDuirements associated with remote synchroni!ation in wide?area wireless environments with intermittent connectivity. "yncM: is based on a client?server model. "yncM: specifications consist of three major components@ representation protocol, synchroni!ation protocol, and transport bindin s. The .epresentation protocol defines CM:?based messa es for synchroni!ation, whereas the "ynchroni!ation protocol defines synchroni!ation in the form of messa e seDuence charts. The Transport bindin specification defines a mechanism to carry synchroni!ation messa es over different transport mechanisms.

5
5.1

S!n"M)
S!n"M) =9er9ie5
.educe the number of messa es bein sent over the air, .educe the messa e si!e, Provide a robust authentication mechanism, Transport independence, 7atatype independence.

"yncM: was desi ned with a number of oals@

3GPP

Release #

3GPP TS %&'1(3 )#'('( "%((%*(+$

5.1.1 &e('"e t#e n'm+er $7 me a6e +ein6 ent $9er t#e air
To achieve a reduction in the number of messa es bein transmitted, the "yncM: device is reDuired to determine which of the objects to be synchroni!ed has chan ed since the last synchroni!ation for each server. This way, the "yncM: device may tell the server what has chan ed, and then the server may tell the device what has chan ed and to ether they may determine the most appropriate course of action. &n the case where there are no chan es from the server or client, there could be as few as two messa es e(chan ed. &n the case where the server is sendin additions to the device, there could be as few as four messa es e(chan ed. - detailed e(planation of the messa es bein e(chan ed may be found in the protocol document E;F.

5.1.2 &e('"e t#e me a6e i%e

"yncM: messa es can be in either CM: or 1/CM:. The CM: version is rather lar e, as the ta s are clearly spelled out. The CM: version ma#es for easier debu in , but is much too lar e for normal use over a wireless networ#. 1/CM: has the same structure as CM:, but replaces the te(t strin s with binary ta s. This produces much smaller messa es, at the e(pense of human readability. "yncM: devices are reDuired to support only CM: or 1/CM:, not both. "yncM: servers must support both CM: and 1/CM:.

5.1.3 Pr$9i(e a r$+' t a't#enti"ati$n me"#ani m

"yncM: has reDuired authentication on the messa e level, and optional authentication for the datastores and individual objects. The authentication is either /asic (username@password) or M76 (username@password@nonce). "tron er authentication and encryption are wor# items for the year *++3. To #eep the authentication free from casual viewin , the data is base85 encrypted. &t is possible to send an initial messa e to the "yncM: server usin /asic authentication, and have the server reject the messa e, as#in instead for M76 authentication. &t is also possible authentication for every messa e bein sent to the server and device.

5.1.1 Tran *$rt <n(e*en(en"e

"yncM: has the capability of operatin over a several transport mechanisms. Aersion 3.+ specifies O/2C, 1"P and KTTP. To achieve this independence, "yncM: has defined a set of specifications and conformance for each transport. 2ach transport must be able to carry a "yncM: messa e reliably between "yncM: devices. 2ach transport must be able to send a messa e to a device, and then be able to wait for a response from that device.

5.1.5 8atat!*e <n(e*en(en"e

"yncM: has specified a minimal set of objects for "yncM: servers to support, but has not made the same reDuirements for "yncM: clients. These objects are v0ard *.3, and v0alendar 3.+. "yncM: only reDuires that an object be a re istered M&M2 type for it to be synchroni!ed. /oth a client and server must support this object for it to be synchroni!ed. The 7evice &nformation object indicates which objects are supported for any datastore. The 7evice &nformation Object must be e(chan ed on the first synchroni!ation between a client and server. Typically, "yncM: servers will support a wide variety of datatypes, while a "yncM: client will support only one datatype (in the interest of smaller footprint). &f a new datatype is created, it is very easy for this to be supported.

5.2 -#an6e $7 -lient4Ser9er &$le 7r$m &elea e 22

"yncM: uses the followin description for client<server roles@ I- client is a device (or application) which initiates a reDuest for a session. The server is a device that passively waits for session reDuests from client devices. The server can either accept the reDuest or reject it.J &rM0 defines the client as@ IThe &rM0 0lient is the device that initiates communication with an &rM0 "erver. Typical &rM0 0lients are P0s. Kowever, in some cases, P7-s, pa ers and phones may also be &rM0 clients. &rM0 0lients can only communicate

3GPP

Release #

3GPP TS %&'1(3 )#'('( "%((%*(+$

with &rM0 servers. 4or instance, an &rM0 client may reDuest a particular Phone /oo# record from an &rM0 "erver.J &rM0 also defines the server as@ IThe &rM0 "erver listens for reDuests from &rM0 clients. Typical "ervers are pa ers, phones and P7-s. &rM0 "ervers can not initiate communication, and can only communicate with &rM0 clients.I

5.3 Tran *$rt :in(in6

The transport to be used should be either KTTP or 1"P. 7etails on the transport bindin s may be found on the "yncM: website. E;F

5.1 Se"'rit!
2ach "yncM: messa e must e(chan e authentication credentials on each messa e level and may e(chan e additional authentication for each datastore as well. This authentication process will only uarantee that the client and server can rely on each other for the duration of the session. 4or lon er duration security, the basic level of authentication is not adeDuate, instead M76 authentication should be used. This will uarantee authentication not only over a session, but between sessions as well. 2ncryption is not currently available in "yncM: and must be supplied by the transports. Transport from the mobile device to the ateway is well protected. Transport from the ateway to the server should be sent via a secure channel, such as KTTP".

5.5 -$nne"ti$n
The connect seDuence sets up the connection from the mobile device to the synchroni!ation server. The client must choose a session id that is uniDue between the client and server and must determine what level of authentication to use (basic or M76). Once the authentication has been decided, the client is free to start the actual connection process. 'ote that the connect procedure is always invo#ed by the client and that the transport bindin documents detail the connection process. Persistent connections should be terminated only after the last e(pected response from the server has been received.

5.6 Sen(in6 an( &e"ei9in6 <n7$rmati$n

/oth 1"P and KTTP transport bindin s use the Post method for sendin and receivin "yncM: messa es to the server.

5.7 <ntermittent -$nne"ti9it!

/oth the 1"P and KTTP transport bindin s operate over networ#s with hi h latency and have timeouts built in. /oth transport bindin s operate as follows@ I&n the case of a server timeout, the "yncM: client "KO>:7 establish a new KTTP session with the KTTP server and attempt to resend the current "yncM: pac#a e, be innin with the first "yncM: command for which the "yncM: client has not received an ac#nowled ement. &n the event that the "yncM: client reDuested that no responses be sent, the "yncM: client "KO>:7 be in retransmittin with the first "yncM: command in the "yncM: pac#a e. &n the case of a client timeout durin a "yncM: client?initiated data synchroni!ation, the "yncM: server "KO>:7 clean up the T0P connection and do no further processin of the "yncM: reDuest.J E;F

5.> -$m*ati+ilit! 5it# &elea e 22

3GPP

Release #

1(

3GPP TS %&'1(3 )#'('( "%((%*(+$

0ompatibility between this release and .elease == assumes that, within the networ#, there is a tar et server to act upon synchroni!ation transactions. This tar et server is the destination or ori in for all M2 synchroni!ation translations. This tar et server has to be able to differentiate between .elease == "ync and newer versions of "ync. &f the new transport lin# is O/2C, then there will be different O/2C tar et headers for .elease == and newer releases. &f the new transport lin# is not O/2C, then the server will differentiate between .elease == and newer releases by port number or M&M2 type. &n either case, there is a distinctive method for determinin how to service the "ync transaction. 0ompatibility also assumes that the e(istin data store types may be maintained as currently defined in both the client and the server. 'ewer data store types may not need to maintain bac#wards compatibility since the older .elease == clients would not understand the new types.

5.2

U e -a e 5it# S!n"M)

The user wants to synchroni!e data. &f the user has not previously set up the remote synchroni!ation, the user will have to enter in the >.: for the server, the authentication data (user name, password, and possibly a nonce), as well as any datastores to be synchroni!ed. The device will have to maintain this information in the local stora e of the device. The user then chooses with which remote server to synchroni!e and then starts the synchroni!ation. The server will receive a messa e from the client with authori!ation information and a "ync -lert for each datastore to be synchroni!ed. The server will send bac# a messa e to the client with a status for all of the "ync -lerts as well as the authori!ation. 'ote that the server has the option to tell the client to not send any more authentication at this point. :i#ewise, the server could tell the client to switch to more robust authentication and have it resend the first messa e with M76 authentication. The client will send a messa e to the server with all of the chan ed data since the last synchroni!ation with that server. The server will respond with a messa e containin a status on all of the chan ed data and all of server?chan ed data since the last synchroni!ation. &f there is any data from the server, then the client will have to send a messa e bac# to the server with status on the serverLs chan ed data reDuests, and possibly some Map&tems. Map&tems are used to tell the server how to map the local >&7s to the serverLs >&7s. Map&tems are only sent to the server if the server has sent any new objects to the client. &f the client has sent a new objectto the server, the server will ta#e care of any >&7 mappin at that time. &f the client had sent any Map&tems to the server, then the server will send a final messa e to the client with a status on all of the Map&tems sent. The user will then see a prompt tellin them the synchroni!ation is now complete and, possibly, indicate any errors.

3GPP

Release #

11

3GPP TS %&'1(3 )#'('( "%((%*(+$

Anne3 A (in7$rmati9e)/ -#an6e #i t$r!

Change histor
/ate 22402400 15403401 07406402 TSG 0 T?2 T?11 T?16 TSG /oc' TP-000113 TP-01002> CR 001 002 Re1 Su2ject3Comment 1 <ntr$('"ti$n $7 PUS@ an( TA&G.T A((iti$n $7 S!n"M) U*6ra(e t$ &el-5 4ld 3.0.0 3.1.0 5.+.+ 5ew 3.1.0 1.0.0 6.+.+

3GPP