Introduction to SyncML

    enRaiser
    By enRaiser

    The phone generally has different kind of data, and depending on the category, different kinds of management operation can be offered. See the table below.

    Type Description Examples Operation
    PIM Information related to User Contacts, Reminders,Emails, Syncronization
    Settings parameter required to connect with servers Browser,Email,MMS account  information. Provisioninig
    BLOB Big files. Ringtones,Pictures,Songs, Phone Image Download,Upload

     

    Syncronization :  If  two different copies of a database is allowed to get modified indepependent of each other, Then at an appropriate time these modification should be reciprocated to other copy, and the conflicts must be resolved. This is called syncronization.

     

    Provisioning : Device must be automatically updated  with device parameters, like phone application settings, Initial settings etc. This is called Provisioning.

     

    Standardization and Client-server Architecture.

    In all kind of mobile facilities listed above the solution is generally client-server architecture. In this Architecture the communication must be standardized. Other wise it will be very difficult to interoperate between a client device of one company and the server solution of the other company. You will be forced to buy the server solution of the same company.

    How SyncML Born

    Before SyncML also all this facilities were being provided by various companies. However it was not matured and the implementation was proprietary. Being proprietary it was too difficult for the operators to have unique solution for various kinds of devices.

    So Mobile companies like Nokia, Motorola and server developers like IBM Openwave have collaborated and created a consortium by name SyncML.

     

    Why the name SyncML

    It has not been explained but what I think is

    SyncML  :=   Synchronization using XML technology.

     

    As the name reveilles SyncML started as solution for Data Synchronization only. And later on it also standardized Device Management functionality.

     

    Responsibilities

    The responsibility of the SyncML consortium is to standardize the communication between client and server for the above kind of functionalities. Publish the specification of the standard. Specify the test cases for the approval of the SyncML product .etc.

     

    Later the SyncML consortium has been acquired by OMA forum.

    Basics

     

    XML

     

    l     Simple Flexible and well formed

    l     Free and Extensible

     

    <?xml version=”1.0″ encoding=”ISO-8859-1″?>

    <note date=12/11/2002>

    <to>Tove</to>

    <from>Jani</from>

    </note>

     

    l  Element

    l  Parent-child relationship between element

    l  Attribute

     

    DTD  Datatype definition

    It is a set of compilation rules to validate the xml document. It is just like  C compiler uses a set of C rules to compile a C file.

     

    WBXML

    To Reduce the payload size on the network, the xml file is compressed and converted into wbxml(wireless binary XML) file.

    Give a hexadecimal number to each xml token (element/attribute etc)

    Use id hex number for repetitive strings.

     

     

     

    DMTree and DMObject

    Device Management Tree is just like a Unix file system. In Unix Operating system we represent everything as a file. Data, Device Driver, Some OS interface are also represented as files. The /proc directory is a best example of it. So a simple definition of DMTree could be. Everything in device this need to be managed externally can be represented a DMobject and a Tree which correlate and represents this collection of object, is called DMTree. Doing this we can make the Device Management simple and scalable.

     

    Unix File System DMTree
    File, folder DMObject or Node, File is to leafnode and folder is to Intermidiate node
    Operations like Open,close,Read, Write, Add,Delete,Rename Operations like Get,Update,Add,Delete,Copy,Rename,Execute
    Client does remote login to Unix Server and does above operations on objects Server does Remote login to Device client and does above operations.
    Permission to do above operation for a particular client. This properties is supported in Unix file system. Not supported in DM.
    Properties supported  are :  Name,Size, (Type, & ACL are there in Windos OS) Run time properties :  Name,Size, Format,,Type,ACL
    No DF property.. DFProperties :

     

    AccessType,Default Values,Description,DFFormat,Occurrence,Scope,

     

    Standard Objects

    Some of the management object have been informed by the the SyncML Specification. They are called Standard Object.

    ./SyncML   DmAcc  , Con

    ./DevInfo

    DevDetail

     

     

    Device Description Framework DDF

     

    Device Management Tree is a Tree of Management objects existing in the device, where as DDF is a template for the DMTree. DDF is kind of a MOU between Server and Client, So that Server can get an Idea of phones limitation and what is what.

     

    DMTree is different for different devices of the same product and, it keeps changing whenever there is action taken by Server/User on the data. Whereas DDF is contant for  particular product. DDF itself is a XML document and it follows a Well-defined DTD. It helps in specifying the following

    1. Top level permanent tree which is not going to change.
    2. Occurrences of similar sub-tree.
    3. Which operations are allowed?
    4. Empty Node Name facility.
    5. Runtime Property list and Default Values.

     

    What is DF Properties

    The properties which are specified in the DDF and so which are not going to change are called DFProperty.

    AccessType , Default Value ,Description, DFFormat, Occurrence, Scope,

     

    DDF is not DTD

    DTD is compilation rules for parsing particular XML document. Where as DDF is a template of the DM tree. It itself is a XML doc, the DDF also has its own DTD.

     

    What is Protocol

    Any protocol is basically made up of two components.

    1. Representation protocol.   It describes about the packet format and fields.
    2. Communication protocol. It describes about understanding between client and server about who will do what and when. It also describes about handshaking, fragmentation, authentication .etc.

    Protocol stack can be represented in two pictures.  top to bottom.

    When I say SyncML sits over HTTP. This sentence contains much information in itself.

     

     

     

     

     

     

    Packet Format

    Generally a packet has three parts command, headers and Paylod. In the above picture, the SyncML packet is a payload for Http Packet, similarly HTTP packet is a payload for TCP packet.

     

    HTTP Protocol: Packet format

    The packet format is as follow. The first is method, which is followed by headers and which is followed by payload or Body.

    HTTP Protocol: Communication

     

     

     

    SyncML.DM Notification /Pkg 0

    In client Server architecture first the client establishes the socket connection with the server and then sends the first packets to the server. This is also true with the SyncML.DM. However in the case of SyncML.DM it is quite possible that the server decides when to start the DM Session. This is because scheduled jobs. So the server will first send a out of band trigger to the client. It could be SMS or WAP push message or anything. This is called Notification or Pkg 0. After receiving the Notification the client will first establish TCP and HTTP connection and then sends a pkg1. And thus the DM Session starts.

     

    SyncML.DM Protocol (Communication protocol)

     

    Session ID

    It is a unique Id to identify the DM Session between this client and this server. If it is a server initiated session then the server generates it and sends to client as part of Pkg0. or if it is a client initiated session then the client generates it. The session Id must be included in Pkg 1 and 2.

     

    Multiple Messages in package.

    There can be a limitation on the size of the SyncML payload. This limitation might be imposed by the transport protocol, or due to non-availability of memory. Therefore a SyncML package can be made of 1 or more payload/SyncML Messages. The recipient responses to each message with “Continue” message until the message indicates that it is the last message of the concerned package.

     

    Pkg 1 : Client Information and session Id.

    Pkg 2   Server Information, session Id and management commands.

    Pkg 3   Client response to the management commands.

    Pkg 4   further management commands.

    SyncML Representation Protocol

     

    SyncML,

    SyncHeader

    Chal

    Target, Source, LocUri

    RespUri

    SyncBody

    Cmd

    Cred

    Final

    MsgId

    Security

    Digest

    Nonce

    Algorythm  MD5, HMAC

    Challanging with NextNonce