In our discussion of the final Object Exchange (OBEX) foundation profile, we consider the features and procedures that are required to realise a compliant Synchronisation Profile. In our earlier discussion of the Object Push Profile, Chapter 12, we discussed our everyday ability to exchange a varied amount of data in various contexts. For example, at conferences or exhibitions we may collect business cards, which contain information relating to a business address, a range of contact telephone numbers and an email address. This type of exchange is referred to as Personal Data Interchange (PDI), where this data may be transferred to several electronic devices, such as a mobile phone, Personal Digital Assistant (PDA) or a notebook. With the amount of data held on these various devices, synchronisation is used to ensure its accuracy and that the data is consistent for all devices. This profile defines a set of features and procedures which, in turn, allow users to synchronise the information contained on these separate devices.
In Figure 14-1 and Figure 14-2, we demonstrate the types of devices that are capable of synchronisation. In this chapter, we discuss the requirements of the profile itself and the expectations of the underlying dependency, the Generic Object Exchange Profile (GOEP), Chapter 11. It is important to remember that there are numerous applications that already support synchronisation, where the underlying transport may vary. You may remember from our discussion of the GOEP that transparency is provided for applications that reside above the OBEX Protocol.
Figure 14-1. The Synchronisation usage model shown allows the user to exchange Object Stores between a mobile phone and a notebook.
Figure 14-2. The Synchronisation usage model shown allows the user to exchange Object Stores between a notebook and a PDA.
The Synchronisation Profile is dependent upon the features and procedures that are described in the GOEP. The GOEP is, in turn, dependent upon the Generic Access, Chapter 2, the Service Discovery Application, Chapter 3 and the Serial Port Profiles, Chapter 6; the core dependency illustrated in this chapter relates to the capabilities as described in the GOEP.
This section considers our existing usage model through scenarios that may be typical for the Synchronisation Profile. We begin by exploring the existing model where a Bluetooth-enabled notebook, PDA and mobile phone are capable of synchronising Object Stores. There will be more about this later in the chapter.
Figure 14-1 and Figure 14-2 show the current usage models in this scenario. The role of the notebook acting as a client initiates a one-to-one communications link with another Bluetooth-enabled device, where it takes on the role of a server. The Synchronisation Profile usage model prescribes the ability to synchronise data between Bluetooth-enabled devices.
The Synchronization Profile provides two new roles: a Client and a Server. The client device is capable of pushing and pulling objects to and from the server, whereas the server provides the facility to allow the client device to push and pull the objects. In this context, an object refers to an Object Store, which is a database containing many IrMC [1] Objects.
In our introduction, we touched upon the notion that a set of features and procedures exist to help govern the operation of Bluetooth-enabled devices, which support the Synchronisation Profile. At the heart of this profile, the GOEP establishes core capabilities that are realised in the Synchronisation Profile. Tasks such as object push and manipulation can take place between devices, where such objects may include large files or complete directory structures, as previous outlined. The GOEP and its underlying capabilities have been designed with portability in mind and, as such, any existing application may make use of the GOEP.
There are no fixed master-slave roles. This leaves either device free to initiate and terminate a connection, although typically the client will initiate the primary connection, where inquiry and device discovery procedures are undertaken. Participating devices in this profile must be required to perform bonding, pairing, authentication and encryption when requested to do so, but their use within this profile is optional. The use of OBEX authentication is supported, but its use is also optional. In Figure 14-3, we illustrate the specific Bluetooth protocol stack components that are dependent upon a compliant profile.
Figure 14-3. The core components of the Bluetooth protocol stack are shown, illustrating how the components of the Synchronisation Profile are integrated.
Table 14-1. The list of behavioural characteristics that are typical for this profile.
|
CONFIGURATION |
ROLE |
DESCRIPTION |
|---|---|---|
|
DeviceA |
Client |
This device is capable of pushing and pulling objects from the server. The client establishes a relationship with the server before data objects can be exchanged and manipulated; the client will typically initiate the connection. |
|
Initiator |
This configuration describes the device that instigates the original connection or the device that wishes to initiate communication over an existing link. | |
|
DeviceB |
Server |
A server provides object exchange capability which, in turn, allows client devices to push and pull objects from the server. This type of device would typically accept connections from clients and allow the client to create or manipulate data objects. |
|
Acceptor |
This configuration describes the process of the device accepting the initiated communication from DeviceA. |
In Table 14-1, clarification is provided with regard to the roles used within the context of this profile. In general, DeviceA represents the initiating party and DeviceB represents the accepting party. The terms are often used interchangeably when describing specific operations in various contexts and are provided here for reference.
The Synchronisation Profile should enable three core features, which include the ability to Synchronise; this is further divided into four types (Phonebooks, Calendars, Emails and Notes), Sync Command and Automatic Synchronisation as shown in Table 14-2. During the Initialisation Sync Mode, the server is placed into limited or general discovery and permits the connection and pairing of client devices. During General Sync Mode, both the server and client may enter this mode allowing devices to connect. When a client initiates a connection with a server and the intent is to synchronise, the server will then enter this mode. Similarly, when a server initiates a connection with the client, the client will also enter the General Sync Mode. User intervention is required to enable these two modes of operation. These particular features and their associated functionality are now described in more detail with an emphasis provided for user expectation. Devices whose behaviour mimic a server should be configured as such, where Figure 14-4 illustrates the configuration options available to some Bluetooth-enabled devices.
Figure 14-4. The generic options available to the user. The user can configure their set-up relating to how information is exchanged between two devices. (Courtesy of TDK Systems Europe.)
Table 14-2. The illustration shows specific behavioural procedures that this profile depends upon to realise its compliant implementation.
|
FEATURE |
CLIENT |
SERVER |
|---|---|---|
|
Synchronisation |
M |
M |
|
Sync Command |
M |
O |
|
Automatic Synchronisation |
O |
M |
This feature provides synchronisation capabilities on both the client and server; as such, its support is considered mandatory. If authentication is required, the user may be prompted to enter a Bluetooth Passkey; OBEX authentication may be used during this process.
Interoperability at the application level is achieved through the support of the various object data types that are available. In Table 14-3, we identify the various data object formats and their associated specifications. It is the application that is responsible for providing the relevant data object support; Bluetooth wireless technology is used as the transport medium.
Table 14-3. The table identifies the object types and formats available that must be supported by any application using the Synchronisation Profile.
|
FORMAT |
DESCRIPTION |
|---|---|
|
vCard |
Synchronisation applications must support the capabilities and format provided within the Internet Mail Consortium, “vCard: The Electronic Business Card,” Version 2.1, September 1996. |
|
vCalendar |
Synchronisation applications must support the capabilities and format provided within the vCalendar specification. This is discussed in further detail in The Internet Mail Consortium, “vCalendar: The Electronic Calendaring and Scheduling Exchange Format,” Version 1.0, September 1996. |
|
vMessaging |
Synchronisation applications must support the capabilities and format provided within the Infrared Data Association, “Specification for Ir Mobile Communications (IrMC),” Version 1.1, March 1999. |
|
vNotes |
Synchronisation applications must support the capabilities and format provided within the Infrared Data Association, “Specification for Ir Mobile Communications (IrMC),” Version 1.1, March 1999. |
The user should perform an inquiry and discovery procedure to ascertain the capabilities of the server device. Once he or she has identified the appropriate server, the user can select and make use of the facilities it has available. Users should not use the services of a server that does not support a data object type; however, if a data object is used inadvertently, then the server should report an appropriate error message indicating that the object is not supported. As illustrated in Figure 14-4, the user can configure the server to support the various object types; as such, it is capable of supporting these objects when requested by the client to do so. Here, the mode of operation is supported by the General Sync Mode. In this particular example, these objects relate to the checked items as shown on the illustration (that is, Business Cards, Calendar Items, E-Mail Messages and Notes).
The client device typically initiates the synchronisation sequence, where the user may now continue to make use of the services it provides. The user can use a double-click [2] or right-click operation to begin the process of synchronisation. In Figure 14-5 and in Figure 14-6, we illustrate the effect of a successful synchronisation where all the object stores are the same on both devices.
Figure 14-5. Right-clicking the icon causes a pop-up menu to appear offering the ability to synchronise. (Courtesy of TDK Systems Europe.)
Figure 14-6. As a result of a successful synchronisation, the application is updated to reflect the phone contacts as stored on the mobile phone handset. (Courtesy of TDK Systems Europe.)
Servers must be capable of managing multiple objects during an OBEX connection, although it is not mandatory for clients to support multiple object transfer. You may recall from the Generic Object Exchange Profile, Chapter 11, that a push function is managed through a Put operation, a pull function is managed through a Get operation, where an OBEX session has been established beforehand with a Connect operation. The disconnection of an OBEX session is managed with the Disconnect operation and so on; this is discussed in more detail in Section 14.5.1.2, OBEX in the Synchronisation Profile.
This feature is used during the condition where the server wishes to initiate synchronisation. With this feature, the client is placed into General Sync Mode. This is done without the need for user intervention. Again, the user will select the ability to synchronise in very much the same way as previously illustrated in Figure 14-5. The user may be prompted to authenticate with the device, where he or she may be required to enter a Bluetooth Passkey as shown in Figure 14-7; furthermore, the user may also be requested to use OBEX authentication, which is discussed in more detail later in this chapter.
During this operation, both devices will automatically synchronise their object stores. The client will initiate this automation, as the server moves closer into radio range and the server will remain in General Sync Mode. During this operation, the user may be prompted as to the progress of the automatic synchronisation as we have illustrated in Figure 14-8.
In the following sections, we take an opportunity to explore in greater depth the dependencies that make up this profile.
In Figure 14-9, we provide a conceptual illustration representing the dependencies that make up the Synchronisation Profile; the areas that are shaded are relevant to this profile. As you can see, the profile depends upon the basic functionality offered to us by the Generic Access Profile, Chapter 2, the Service Discovery Application Profile, Chapter 3, the Serial Port Profile, Chapter 6 and the Generic Object Exchange Profile, Chapter 11. We will now discuss the basic requirements of these dependent components and any deviations that may occur from the basic functionality originally offered to us.
Figure 14-9. The dependent components of the Bluetooth protocol stack that make up the Synchronisation Profile. The areas that are shaded are relevant to this profile.
In the Service Discovery Application Profile, Chapter 3, we introduced the characteristics of the mechanisms used to retrieve service information from a remote device. Typically, a client will initiate an inquiry and discovery procedure as outlined in our previous section, to learn of the devices in radio range. A client would then make use of an application, which would embody the functionality of the underlying Service Discovery Protocol (SDP). The Service Discovery Application (SrvDscApp) uses an SDP Client to instigate a request to the remote device where the SDP Server will respond; as such, the client and server must employ the use of an SDP client and server respectively, as illustrated in Table 14-4.
Protocol Data Units (PDUs) are used to instruct the SDP server to undertake browsing procedures and to retrieve service record information; you may recall that these PDUs carry payloads about requests containing AttributeIDs and AttributeValues describing exactly what is being sought. As we previously discussed, the client and server operate a request and response paradigm. SDAP will construct PDUs containing information relating to the AttributeID and AttributeValues which, in turn, instruct the server to carry out its operation. The various request and response PDUs that are required are shown Table 14-5, where features indicated are described as mandatory (M), optional (O) and excluded (X).
A service record is maintained for each service a device is capable of supporting and, as such, a Service Record Handle is created to uniquely identify this. The ServiceRecordHandle is a 32-bit unsigned integer and is stored on the SDP server. The service record shown in Table 14-6 identifies a synchronisation server (IrMC Server) and Table 14-7 identifies the sync command server (IrMC Client). Both tables provide a list of AttributeIDs, which ultimately identify the services that make up the Synchronisation Profile. A minimum of two attributes are required to make a service record; these are ServiceRecordHandle and ServiceClassIDList, where it must contain at least one UUID.
Table 14-4. As a minimum, the local device must support the use of a client application and the remote device must support the use of a server.
|
FEATURE |
CLIENT |
SERVER |
|---|---|---|
|
SDP Client |
M |
X |
|
SDP Server |
X |
M |
Table 14-5. The list of PDUs that are required for the operation of the Syncronisation Profile.
|
PDU |
CLIENT |
SERVER |
|---|---|---|
|
|
X |
M |
|
|
O |
X |
|
|
X |
O |
|
|
O |
X |
|
|
X |
O |
|
|
M |
X |
|
|
X |
M |
When browsing for services on the remote device, a local device constructs a search pattern using a Universally Unique Identifier (UUID). A UUID is a 128-bit value, which has been shortened for use within Bluetooth. The shortcut has been provided by first establishing a Bluetooth Base UUID, which we discussed in the Service Discovery Application Profile, Chapter 3.
The UUIDs that have been presented in this chapter are aliases and take the form of what is referred to as a 16-bit UUID or a 32-bit UUID but, in turn, they all should refer to the 128-bit notation. These UUIDs have been assigned and can be referenced in the Bluetooth Special Interest Group, Bluetooth Assigned Numbers, v1.1, February 2001. For the search pattern to be successful, they all need to be converted to the 128-bit notation, since they will all be compared at this range. An arithmetic conversion algorithm is used to construct the 128-bit value.
Table 14-8 summarises the service class UUIDs used to identify the particular profile in use; this also correlates with the identification of the device during a device discovery procedure, as previously discussed in the Generic Object Exchange Profile, Chapter 11.
As part of the service record, the identification of the dependent underlying protocols are also identified. The local device retrieves this information, where it can fully understand the exact requirements needed to fulfil the service. The Synchronisation Profile is dependent on the protocols as shown in Table 14-9 also showing their associated UUID values.
The IrMC server device is capable of supporting several data objects, which are summarised in Table 14-10. The AttributeValue that would follow is an 8-bit unsigned integer used to uniquely identify the particular object; these values are also shown.
Table 14-6. The list of mandatory and configurable items that make up IrMC Server service discovery record.
|
ATTRIBUTE |
DESCRIPTION |
|---|---|
|
|
With an |
ServiceClassIDList ServiceClass0 |
With an |
ProtocolDescriptorList
Protocol0
Protocol1
ParameterFor1
Protocol2 |
With an |
BluetoothProfile
DescriptorList
Profile0
ParameterFor0 |
With an |
|
|
With a base |
|
|
With an |
Table 14-7. The list of mandatory and configurable items that make up IrMC Client service discovery record.
|
ATTRIBUTE |
DESCRIPTION |
|---|---|
|
|
With an |
ServiceClassIDList ServiceClass0 |
With an |
ProtocolDescriptorList
Protocol0
Protocol1
ParameterFor1
Protocol2 |
With an |
BluetoothProfile
DescriptorList
Profile0
ParameterFor0 |
With an |
|
|
With a base |
In this section, we consider the objectives of OBEX in the profile and its expectations. In establishing our operations and its primitive functionality, the profile discusses mandatory features that it expects from the protocol and provides guidance with regard to how a request and response packet should be constructed and subsequently used. In Table 14-11, we identify the operations that must be supported by the client and server devices to enable a compliant Synchronisation Profile.
Table 14-8. The list of service classes that match a corresponding profile.
|
CLASSES |
UUID |
|---|---|
|
|
|
|
|
|
Table 14-9. The list of protocols that are used in this profile; their associated UUID values are also shown.
|
PROTOCOL |
UUID |
|---|---|
|
|
|
|
|
|
|
|
|
Table 14-10. The list of supported objects that a client device is capable of supporting.
|
OBJECTS |
VALUE |
|---|---|
|
Phonebook |
|
|
Calendar |
|
|
Notes |
|
|
Messages |
|
Table 14-11. The required OBEX operations that should be supported in the client and server devices.
|
OPERATION |
CLIENT |
SERVER |
|---|---|---|
|
Connect |
M |
M |
|
Disconnect |
M |
M |
|
Put |
M |
M |
|
Get |
M |
M |
|
Abort |
M |
M |
In Table 14-12, we identify the optional and mandatory OBEX headers that are used during the generic operation of all synchronisation features, where OBEX authentication is supported. The OBEX headers that are not shown are excluded from the operation of this profile. In the following sections, we discuss the specific operations as outlined in Table 14-12 and consider their support in this profile.
Prior to establishing an OBEX session, authentication may occur prior to an OBEX session establishment. An OBEX password may be required and can match the Bluetooth Passkey for convenience; this itself reduces the user complexity. Further convenience can be provided for the user as both the client and server may store the passkey for future ad-hoc connections.
As a minimum, GOEP must be able to support OBEX without authentication. If it is requested, then support for the authentication challenge should be provided; we discuss this in Section 14.5.1.2.2, OBEX Connection with Authentication. In Table 14-13, we provide a list of mandatory fields that make up or request packets and provide further information with regard to its usage within the structure.
Table 14-12. The required OBEX headers that should be supported by the general features that are available during synchronisation.
|
HEADER |
CLIENT |
SERVER |
|---|---|---|
|
Name |
M |
M |
|
Length |
M |
M |
|
Time |
O |
O |
|
Description |
O |
O |
|
Target |
M |
M |
|
HTTP |
O |
O |
|
Body |
M |
M |
|
End of Body |
M |
M |
|
Who |
M |
M |
|
ConnectionID |
M |
M |
|
Authentication Challenge |
M |
M |
|
Authentication Response |
M |
M |
|
Application Parameters |
M |
M |
Table 14-13. The fields and headers that are a mandatory feature of the Connect-request operation.
|
NAME |
TYPE |
SUPPORT |
|---|---|---|
|
|
Field |
M |
|
|
Field |
M |
|
|
Field |
M |
|
|
Field |
M |
|
|
Field |
M |
|
|
Header |
C |
As you know, the Connect request is used to establish the OBEX session and the Target header is used to identify the targeted service. In this instance, the Target header is used to denote IrMC Sync. The Connect response message is shown in Table 14-14, where the ResponseCode will indicate 0xA0 if the connection was successful. The ConnectionID and Who headers must be used if the Target header was used in the original Connect request.
In our previous section, we provided the scenario and features that are required to establish an OBEX session without authentication. This section now discusses in more detail the features expected from the OBEX protocol when authentication is required. This new authentication procedure is an additional requirement above the Bluetooth specific authentication process, that is, a Bluetooth Passkey is used to instigate the pairing process, where Bluetooth authentication can then occur. The OBEX authentication is used to establish a trusted relationship at the client and server level, where it is the server that will initiate the challenge. The server is unable to commit to an OBEX session, until the authentication features are fully adhered to. In the first instance of sending a Connect request, the client is unaware that authentication is required and, as such, it sends a request in the usual manner, the fields of which have been previously illustrated in Table 14-13.
Table 14-14. The fields and headers that are a mandatory feature of the Connect-response operation.
|
NAME |
TYPE |
SUPPORT |
|---|---|---|
|
|
Field |
M |
|
|
Field |
M |
|
|
Field |
M |
|
|
Field |
M |
|
|
Field |
M |
|
|
Header |
M |
|
|
Header |
M |
The client learns of the news when it receives the response from the server. When we look more closely at the fields used in our Connect response as shown in Table 14-15, we notice that the AuthenticationChallenge header is used. Furthermore, when the client parses the ResponseCode it will learn of the value 0x41 Unauthorised; this notifies the client that it must send a new Connect request with the AuthenticationChallenge and AuthenticationResponse headers as shown in Table 14-16. These headers carry the digest-challenge string and digest-response strings, respectively.
The fields and headers used in the second response are shown in Table 14-17. If the ResponseCode, contains the value 0xA0 from the server, then authentication has been successful. The OBEX session can now be established.
At some point an established OBEX session will be terminated, which may be due to a user request or a loss of connection. The session is terminated using the Disconnect operation, where the OpCode has the value 0x81. In Table 14-18, we show the rest of the fields that are used during this operation.
The Disconnect response message is shown in Table 14-19, where the ResponseCode will indicate 0xA0 if the disconnection was successful; this operation is not refused by the server.
Data is transferred to the server using the Put request, where the OpCode may indicate 0x02 for multiple packets and 0x82 to indicate that it has sent the last packet. The features used for this transaction are identified in Table 14-20, where the ConnectionID is mandatory if the Target header was used in the original Connect request. You may recall that the OBEX connection establishment used the Target header.
Table 14-15. The fields and headers that are a mandatory feature of the first Connect-response for authentication.
|
NAME |
TYPE |
SUPPORT |
|---|---|---|
|
|
Field |
M |
|
|
Field |
M |
|
|
Field |
M |
|
|
Field |
M |
|
|
Field |
M |
|
|
Header |
M |
Table 14-16. The fields and headers that are a mandatory feature of the second Connect-request for authentication.
|
NAME |
TYPE |
SUPPORT |
|---|---|---|
|
|
Field |
M |
|
|
Field |
M |
|
|
Field |
M |
|
|
Field |
M |
|
|
Field |
M |
|
|
Header |
C |
|
|
Header |
M |
|
|
Header |
M |
The Name header is used to identify the object being transferred and the Body/End of Body headers are used to identify the start and end of the object being transferred. In Table 14-21, we identify the features that are required in the Put response, where the ResponseCode may indicate 0x90 for continue in response to the Put OpCode 0x02 or 0xA0 for successful in response to the Put OpCode for successful completion of the transfer.
Table 14-17. The fields and headers that are a mandatory feature of the second Connect-response for authentication.
|
NAME |
TYPE |
SUPPORT |
|---|---|---|
|
|
Field |
M |
|
|
Field |
M |
|
|
Field |
M |
|
|
Field |
M |
|
|
Field |
M |
|
|
Header |
M |
|
|
Header |
M |
|
|
Header |
M |
Table 14-18. The fields and headers that are a mandatory feature of the Disconnect-request operation.
|
NAME |
TYPE |
SUPPORT |
|---|---|---|
|
|
Field |
M |
|
|
Field |
M |
Table 14-19. The fields and headers that are a mandatory feature of the Disconnect-response operation.
|
NAME |
TYPE |
SUPPORT |
|---|---|---|
|
|
Field |
M |
|
|
Field |
M |
Table 14-20. The fields and headers that are a mandatory feature of the Put-request operation.
|
NAME |
TYPE |
SUPPORT |
|---|---|---|
|
|
Field |
M |
|
|
Field |
M |
|
|
Header |
M |
|
|
Header |
M |
|
|
Header |
M |
Data is transferred from the server using the Get request, where the OpCode may indicate 0x03 for multiple packets and 0x83 to indicate that it has retrieved the last packet. The features used for this transaction are identified in Table 14-22, where the ConnectionID is mandatory if the Target header was used in the original Connect request.
The Name header is used to identify the object being transferred and the Type header is used to identify the type of object being pulled. In Table 14-23, we identify the features that are required in the Get response, where the ResponseCode may indicate 0x90 for continue in response to the Get OpCode 0x03 or 0xA0 for successful in response to the Get OpCode for successful completion of the transfer. The Name header is used to identify the object being transferred and the Body/End of Body headers are used to identify the start and end of the object being pulled.
The Synchronisation Profile is based upon the GOEP.
We exchange information with each other all the time and this profile allows us to keep this information consistent between our personal devices.
Our current usage models allow us to synchronise vCard, vCalendar, vMessage and vNotes.
These objects can be pushed and pulled and, as such, the profile defines two roles: a client and a server.
Many devices are capable of supporting the Synchronisation Profile, such as mobile phones, notebooks and PDAs.
The Synchronisation Profile enables three core features: Synchronisation, Sync Command and Automatic Synchronisation.
The inherent capabilities within the GOEP provide the profile with its generic operations.
[1] The Infra-red Mobile Communications (IrMC) Object refers to the inclusion of vCard, vCalendar and vNotes.
[2] The double-click and right-click operations refer to a mouse that is connected to your client device (in this example, a PC or notebook computer running a Microsoft Windows operating system) and where both operations trigger the same method of access. It is noted that an operation may vary from device to device and, as such, the number of buttons may vary on a mouse. Indeed, no mouse may be connected. The example just draws your attention to how it may be possible and acknowledges that implementations may differ.