The Bluetooth Protocol

The Bluetooth Protocol – A White Paper by Vertoda

Copyright © Sykoinia Limited 2009 1





Please Read before reading this White Paper

This white paper is not distributed under a GPL license. Use of this white paper is subject to the following terms:

This white paper is copyrighted by Sykoinia Limited. Copyright © Sykoinia Limited 2009. All Rights Reserved.

You may create a printed copy of this white paper solely for your own personal use. Conversion to other formats is allowed as long as the actual content is not altered or

edited in any way. You shall not publish or distribute this white paper in any form or on any media, except

if you distribute the documentation in a manner similar to how Sykoinia Limiteddisseminates it (that is, electronically for download on a Web site with the software) or on a CD-ROM or similar medium, provided however that the white paper is disseminated together with the software on the same medium.

Any other use, such as any dissemination of printed copies or use of this white paper, in whole or in part, in another publication, requires the prior written consent from an authorised representative of Sykoinia Limited.

Sykoinia Limited reserves any and all rights to this white paper not expressly granted above.

For more information on the terms of this license or if you are interested in doing a translation, please contact us at [email protected].

If you find a typographical error in this white paper or if you have thought of a way to make this white paper better please contact us at [email protected].

Please note that this white paper is for informational purposes. Sykoinia Limited accepts no responsibility for any loss due to the use of this white paper.

If you have any comments please email us at [email protected] with your feedback.



Abstract

The Bluetooth protocol is one of the better-known technologies in the field of pervasive computing and plays a major role in the consumer electronics marketplace in devices such as digital cameras, mobile phones and laptops. This paper outlines selected layers of the Bluetooth protocol stack.



Table of Contents

Table of Contents....................................................................................................................................5

Glossary...................................................................................................................................................8

1. Introduction ..................................................................................................................................11

2. The Transport Layer ..........................................................................................................................12

2.1 The Service Discovery Protocol (SDP) .........................................................................................12

2.1.1 Service Discovery Protocol PDUs .........................................................................................12

2.1.2 Service Discovery Protocol Primitives..................................................................................13

2.2 The RFCOMM Protocol ...........................................................................................................14

3. The Session Layer..............................................................................................................................16

3.1 IrDA Interoperability ...................................................................................................................16

3.2 Telephony Control Protocol Specification ..................................................................................18

3.2.1 Overview and Protocol Components ...................................................................................18

3.2.2 Operation of TCS Protocol ...................................................................................................18

3.2.3 Other Feature of the TCS Protocol.......................................................................................20

3.3 Interoperability Requirements for Bluetooth as a WAP Bearer .................................................21

4. The Bluetooth Network Layer – The Host Controller Interface ......................................................22

4.1 Overview .....................................................................................................................................22

4.2 HCI Events and Commands .........................................................................................................22

4.3 USB and RS232 Transport Layers ................................................................................................23

5. The Bluetooth Profiles ......................................................................................................................25

5.1 Generic Access Profile.................................................................................................................25

5.1.1 Security and Authentication ................................................................................................25

5.1.2 Inquiry and Pairing Procedures............................................................................................25

5.2 Service Discovery Application Profile..........................................................................................26



5.3 The Telephony Profiles................................................................................................................27

5.4 The Serial Port Profiles................................................................................................................28

5.5 The Networking Profiles..............................................................................................................29

5.5.1 The Dial-up Networking Profile............................................................................................29

5.5.2 The LAN Access Profile .........................................................................................................31

5.6 The Object Exchange Profiles......................................................................................................32

5.6.1 The Generic Object Exchange Profile...................................................................................32

5.6.2 The Object Push Profile........................................................................................................33

5.6.3 The File Transfer Profile .......................................................................................................34

5.6.4 The Synchronisation Profile .................................................................................................34

References ............................................................................................................................................36





Glossary

ACK Acknowledgement command or packet

ACL Asynchronous Connectionless Link

AG Audio Gateway

API Application Programming Interface

AT Telephony Control Commands

CDMA Code Division Multiple Access

CID Channel Identifier

CTP Cordless Telephone Profile

CO Connection Oriented

DCE Data Communications Equipment

DCE Data Circuit Endpoint

DHCP Dynamic Host Configuration Protocol

DLCI Data Link Connection Identifier

DNS Domain Name Service

DT Data Terminal

DTE Data Terminal Endpoint

DTE Data Terminal Equipment

DTMF Dual Tone Multi Frequency

DUNP Dial-Up Networking Profile

ETSI European Telecommunications Standards Institute

FTP File Transfer Protocol

GAP Generic Access Profile

GOEP Generic Object Exchange Profile



GSM Global System for Mobile Communications

GW Gateway

HCI Host Controller Interface

HS Headset

HTTP Hypertext Transfer Protocol

IANA Internet Assigned Numbers Authority

IP Internet Protocol

IrDA Infra Red Data Association

IrMC IrDA Interoperability

L2CAP Logical Link Layer and Adaptation Protocol

LAN Local Area Network

LAP LAN Access Protocol

LIAC Limited Inquiry Access Code

LMP Link Manager Protocol

ME Management Entity

OBEX Object Exchange Protocol

OGF Opcode Group Subfield

OPP Object Push Profile

OSI Open System Interconnect

PAN Persona Area Network

PDC Personal Digital Cellular (Japan)

PDU Packet Data Unit

PPP Point-to-Point Protocol

QoS Quality of Service

RPN Remote Port Negotiation



SCO Synchronous Connection Oriented Link

SDAP Service Discovery Application Protocol

SDP Service Discovery Protocol

SNMP Simple Network Management Protocol

SPP Serial Port Profile

TCS Telephony Control Protocol Specification

TCS-BIN Telephony Control Protocol Specification -Binary

TCP Transmission Control Protocol

TL Terminal

UART Universal Asynchronous Receiver and Transmitter

UDP User Datagram Protocol

USB Universal Serial Bus

TETRA Terrestrial Trunked Radio

WAP Wireless Application Protocol

WUG Wireless User Group



1. Introduction

This white paper outlines selected profiles and layers of the protocol stack, which are major components of the Bluetooth specification. The specific components described here are the RFCOMM protocol of the transport layer of the Bluetooth protocol stack, selected aspects of the protocol’s session layer and network layer as well as the various profiles that describe the envisaged uses of Bluetooth protocol.



2. The Transport Layer

2.1 The Service Discovery Protocol (SDP)

This section outlines the Packet Data Units (PDUs) and primitives of the SDP.

2.1.1 Service Discovery Protocol PDUsLike the other protocols described in the specification, SDP uses a Packet Data Unit for communication between the client and server. The exchange of SDP PDU between a client and server is defined as a transaction in the specification. The PDU header specifies the type of PDU being sent in its PDU ID field, a TransactionID field which uniquely identifies request PDUs and is used to match request and response PDUs and the ParameterLength field specifies the length of all parameters in the PDU. Again there are several types for PDUs defined to cater for different operations. Like most PDUs, responses that cannot be fit into a single PDU may be fragmented.

To search for a Service a client performs a ServiceSearch transaction and will send an SDP_ServiceSearchRequest PDU to the SDP server. This PDU will contain a ServiceSearchPattern as outlined above which must include between one and twelve UUIDs. The client can also specify the maximum number of records to be returned for its request in the MaximumServiceRecordCount field. ContinuationState is used to denote that the request is a segment of a previous request. The Server will then reply with an SDP_ServiceSearchResponse PDU which will tell the client the number of service records that the service pattern found in its TotalServiceRecordCount field, the number of Service Record Handle that are included in this response PDU in the CurrentServiceRecordCount field and a list of the record handles in the ServiceRecordHandleList field. Again the ContinuationState is used when the response PDU cannot store all the record details in a single packet.

Once a list of services has been obtained by the client, it can perform a ServiceAttribute transaction by sending an SDP_ServiceAttributeRequest PDU to the service to retrieve specific attribute values from a specific service record. The service record is specified by the ServiceRecordHandle field and the attribute values wanted are included in an AttributeIDList field. The maximum number of bytes of attribute data to be returned in the response is denoted by the AttributeIDList field and once again ContinuationState caters for segmentation. The SDP_ServiceAttributeResponse PDU sent by the server returns the list of attribute IDs and their values with the size of this field in bytes being specified by the AttributeListByteCount field.

If the client has not previously searched for a service and hence does not have a handle for the service attributes it wants to find out about it performs a ServiceSearchAttribute transaction. The SDP_ServiceSearchAttributeRequest PDU sent by the client specifies the UUIDs of the services it wishes to find out about in the ServiceSearchPattern field as well as a list of the attribute IDs itwishes to obtain information about in the AttributeIDList field. Again, there are MaximumAttributeByteCount fields and ContinuationState fields specified for this PDU. In this



case the server will respond with an SDP_ServiceSearchAttributeResponse PDU with the attribute IDs and their values in the AttributeLists field as well as a handle of the matching services. Unlike the ServiceSearch and ServiceAttributeSearch, which are considered to be individual transactions, the ServiceSearchAttribute is a combination of both of these transactions.

It should be noted that, despite being a key operation in a discovery protocol, there is no browsing transaction. This is because the client can use the BrowseGroupList attribute when it wishes to perform this operation. A service pattern is created which contains the attribute that represents the root browse group. Though the lack of an explicit browse operation can be criticized as being unclear, it does reuse the current features and reduces the number of transactions that a device must cater for, an important issue for a simple low-power device.

Error Handling is catered for with the SDP_ErrorResponse PDU, which is sent by the SDP server if the request it receives from the client is improperly formatted or the server cannot respond with the appropriate PDU type. Some reasons for returning this PDU include an invalid PDU size or an unsupported SDP version.

2.1.2 Service Discovery Protocol PrimitivesThough the specification explicitly states that SDP is not an API it does define primitives

which can be mapped to APIs such as the Salutation API [1]. For example, both the serviceBrowse() primitive which searches for services in a specified list of devices (i.e. service browsing) and the getRemDevName() primitive which retrieves the names of devices associated with a particular service can be mapped to the SlmQueryCapability() service primitive. The latter primitive can also be mapped to the overloaded SlmQueryCapability() primitive that specifies the service attributes to look for in a specified list of devices. This primitive can also be used by the SDP serviceSearch() primitive which specifies the service to search for and which of their attributes to retrieve. getRemDevName() can also be mapped to SlmSearchCapability() as can enumerateRemDev(), which is used to search for all devices in the range of a Bluetooth device. There is however no mapping for terminatePrimitive(), which terminates the actions executed as a result of invoking a service primitive. Similarly, the Salutation API has functional primitives for the registration and unregistration of services with the SDP Server’s Local Salutation Manager.

It must be noted that SDP is only applicable to the discovery of device capabilities for the purpose of data transfer. In other words it runs over L2CAP. A similar mechanism for voice could also be of interest – for example, in the TETRA (Terrestrial Trunked Radio) system outlined in [2], not all devices may support voice or voice and data over Bluetooth so a discovery capability may be useful here.

While both the L2CAP and SDP protocols deal with the transport of data and discovery of device capabilities, neither meet one of the key aims of the Bluetooth specification that the need for cables be removed. The RFCOMM protocol is thus defined to meet this requirement.



2.2 The RFCOMM ProtocolLike L2CAP and SDP, the RFCOMM protocol is considered in [3] to be a middleware protocol as it is difficult to categorise. Again, however, the specification designates this as a transport protocol and its use of port numbers and flow control is consistent with this layer. Its purpose of serial port emulation seems to suggest that it is a network layer protocol as it facilitates transport but it plays no role in implementing the details of the datalink layer. Again, RFCOMM is only applicable for the transport of ACL data and runs over the L2CAP layer.

Unlike the other sections of the specification, RFCOMM does not contain a complete description for the protocol. This is because it is based on the ETSI standard TS 07.10. Essentially it is a transport protocol, which emulates the 9 circuits of the RS-232 serial ports. It can support up to 60 simultaneous connections between two Bluetooth devices. The RFCOMM layer looks very much like a typical serial interface – indeed, its name connotes a wireless instance of a virtual COM port. This connection can be a wireless connection between two devices or a wireless connection with two devices with a wired connection to a third non-Bluetooth device. RFCOMM’s primary focus is on the concept of multiplexing. Multiplexed serial communications occurs when there are many clients of the serial interface and the serial port thus needs to be shareable through multiplexed connections.

A pair of Bluetooth devices may open multiple emulated serial ports, each ongoing connection between the client and server being represented by a unique (for the RFCOMM session) Data Link Connection Identifier (DLCI) with a value between 2 and 61. In the optional case of multiple serial ports and multiple Bluetooth devices, the RFCOMM entity must be able to run multiple TS 07.10 multiplexer sessions, each multiplexer session having its own L2CAP CID. When sending control signals RS-232 does not distinguish between DTE and DCE devices and are instead sent as a number of DTE/DCE independent signals. An implicit null modem is created when two devices of the same kind are connected together. It is envisaged that the RFCOMM protocol itself will be part of a port driver, which includes a serial port emulation entity that maps a system-specific API to the RFCOMM services. The application layer that would otherwise use a serial port communication interface will use this driver.

The specification also outlines the multiplexer control commands that can be used. Though the support of some of these commands is optional in TS 07.10 their support is mandatory in RFCOMM. For example, the Remote Port Negotiation (RPN) command, which is used when port settings change, is mandatory in RFCOMM. The rationale for this would appear to be the ad hoc wireless nature of Bluetooth piconets, which would make it more likely that such changes are made.

As one would expect, RFCOMM differs substantially from traditional serial ports. For example, no differentiation is made between data terminal equipment (DTE) such as a computer and data communications equipment (DCE). Furthermore, typical serial ports pace data transfer using XON/XOFF pacing while the flows that take place with RFCOMM are Bluetooth specific and affect all DLCIs. RFCOMM also has some dependencies on the L2CAP lower layer protocol – it uses L2CAP channels to establish connections and depends on the protocol for the reliable



transmission of its data. The power saving modes can also be set for a Bluetooth device without interference from RFCOMM. RFCOMM can itself state its latency requirements to L2CAP, which may be used in deciding which low power mode to use.

Despite the sparseness of its description in the specification, the RFCOMM protocol is critical to any Bluetooth piconet that transfers data between its members. A key aim of the Bluetooth specification is that devices can communicate with legacy applications, many of which use serial ports. The LAN access model is a key example of this use.

The protocol is used for the transport of other protocols such as PPP and OBEX, the latter being a protocol used for the exchange of objects.



3. The Session Layer

The Bluetooth Specification also makes provision for protocols, which can be classified as session layer type protocols as they provide the abstraction of bidirectional or full-duplex service. These protocols will not be implemented in every Bluetooth application. Rather their use is contingent upon the purpose of the device. Typical examples would be Mobile Internet, voice and synchronisation applications, all of which give the illusion of full-duplex service.

3.1 IrDA Interoperability

Bluetooth and IrDA can be considered to be complementary rather than competing technologies. While Bluetooth is superior in terms of its range and transmission pattern IrDA has the edge in terms of its low cost and power consumption and higher data rate. To this end, IrDA Interoperability middleware protocols have been defined in the specification with a particular emphasis on the Bluetooth OBEX protocol for the exchange of objects between devices. This protocol offers the same features for applications as the IrDA IrOBEX protocol, thus enabling applications to work over both the Bluetooth and IrDA protocol stacks.

IrOBEX is a session protocol originally defined by IrDA. As such, it is considered to be an adopted protocol both because it was not originally defined by the specification authors and also because it is not unique to the Bluetooth stack. There are some differences between IrOBEX and the version used in Bluetooth. For example, unlike IrOBEX, which considers both connection oriented and connectionless scenarios, Bluetooth’s OBEX protocol only runs over connection-oriented protocols such as TCP/IP.

The OBEX protocol defines data in terms of objects. These objects can be in either vCard, vCalendar, vMessage or vNote formats. OBEX protocol operations are in pair sets which are formed by requests issued by the client with responses issued by the server, the client waiting for a server response before issuing a new request. The most fundamental operation is that of connection establishment. The connection operation starts a session when the OBEX client sends a Connect-request. When the server receives the request it grants or denies the establishment of the OBEX connection by sending an appropriate response packet. Once a connection has been established it can only be disconnected by a request/response pair or by failures. In other words the connection is not automatically disconnected after each OBEX object has completely transmitted.

A client can push OBEX objects to a server using the Put-request once OBEX connection has been established with a response required from the server for every Put-request packet even though a Put-request may consist of more than one packet. The converse operation is the Get operation where the client is able to pull OBEX objects from the server using the Get-request. As the object is returned as a sequence of headers, the client has to send a request packet for



every response packet. Both of these operations can be aborted by the client’s sending of an Abort-request even if it is in the middle of a request/response sequence.

As the potential applications of OBEX such as File Transfer and Synchronisation by their nature necessitate the use of serial port emulation, the specification details how OBEX is mapped over RFCOMM. A Bluetooth device, which supports the use of the OBEX protocol, must be able to act as a client, server or both. Separate RFCOMM server channels must be used for each server that is running at any one time and OBEX applications must be able to register correct information in the service discovery database.

The other point to note is that OBEX does not receive packets directly from RFCOMM if the former is running over the serial port. Instead OBEX receives a byte stream from a serial port emulated by RFCOMM. OBEX looks for opcodes in the byte stream to detect request packets and response codes for response packets. These codes are considered to be the start of the packet. The absence of an end flag for the packet is compensated for by the fact that the length of the packet is included as the second field so that the packet boundaries can be determined. Unrecognisable data is discarded.

To establish an OBEX connection over RFCOMM a client first must use SDP to discover the information needed, for instance the RFCOMM channel, for connecting to the server. The client then uses the discovered RFCOMM channel to establish the RFCOMM connection and then start an OBEX session by initiating the OBEX connection operation. The disconnection of an OBEX session over RFCOMM consists of closing the RFCOMM channel assigned to the client once this device receives a response from its Disconnect-request. Pulling and putting operations are carried out using the standard Get-requests and Put-requests.

OBEX can also run over the TCP/IP transport protocol. Any Bluetooth device, which supports OBEX over TCP/IP, is assigned the IANA defined TCP port number 650 if it is a server. This port number can be altered to a value above 1023. The client is not assigned a port number but cannot use one that is in the 0-1023 range. An OBEX server starting up over TCP/IP must initialise its port with the designated value of 650 or a number greater than 1023 as outlined above as well as registering its capabilities into the service discovery database.

There is also additional overhead for the connection establishment initiated by the client as it must initialise a socket associated to a TCP port number above 1023 and establish a TCP connection with the host of the server as well as performing service discovery and initiating the connection operation. The disconnection operation also requires that the TCP session dedicated for the session be closed. Pulling and pushing of packet mirrors the behaviour of OBEX over RFCOMM.

The IrDA interoperability chapter of the specification does not claim to outline anything new. Rather, the intention is to adopt the IrMC framework for use in a Bluetooth environment and as such aids in ensuring that Bluetooth is compatible with legacy applications. Furthermore, adopting protocols such as IrDA also saves the effort of developing new technology. The



development of transport for voice data, for example, could have been very complex were it not for the adoption of the TCS-BIN protocol.

3.2 Telephony Control Protocol Specification

3.2.1 Overview and Protocol ComponentsAs noted previously, voice communication is also possible between Bluetooth devices. Like synchronisation operations, voice communication is bidirectional in appearance and in this instance is facilitated by the TCS Binary Protocol. TCS Binary is a bit-oriented protocol. It defines the call control signalling for the establishment of voice and data calls between Bluetooth devices i.e. SCO links. The protocol runs over the datalink and network layer protocols, i.e. L2CAP and LMP, and though much of its functionality resembles transport protocols such as TCP, it is considered to be a session layer protocol as it provides biduplex communication.

TCS uses both point-to-point signaling and point-to-multipoint signalling, the former being a single-point configuration used when it is known to which Bluetooth device a call needs to be established while the latter multipoint-configuration is used when more than one device is available for call establishment. Point-to-point signalling is mapped over the connection-oriented L2CAP channel while point-to-multipoint signalling is mapped over the connectionless channel as it is sent as broadcast information on the beacon channel. Once a Bluetooth device is notified of a call request using a point-to-point signalling channel it uses this signalling channel to establish the speech or data channel. With point-to-multipoint signalling, though only one device will answer a call using a point-to-point signalling channel all devices will previously have been notified of the call request using a point-to-multipoint signalling channel.

The TCS binary interface consists of a number of components. The Call Control entity provides information to the speech synchronisation control about when to connect or disconnect the speech paths. The entity essentially controls the LMP directly in order to establish and release SCO links. The interface also sends SETUP messages using point-to-multipoint signalling to L2CAP for transmission on the connectionless channel and is itself used by L2CAP to inform TCS of a SETUP message received on the connectionless channel. Messages sent using point-to-point signalling are also transmitted by means of this interface. The interface also has a group management entity for controlling the LMP and Link Controller directly during initialisation procedures to control inquiry, paging and pairing.

3.2.2 Operation of TCS ProtocolTo initiate a call request the outgoing side sends a SETUP message and starts a timer T303. If no response is received before T303 expires, the outgoing side will, if it is in a multipoint configuration, return to the default null state, thus stopping the transmission of the SETUP message. For a single-point configuration the outgoing side must also send a RELEASE COMPLETE message (containing an error cause #102 – recovery on timer expiry) to the incoming side as the message was sent over a connection-oriented channel.



The SETUP message must always contain the call class, as well as all the information required by the incoming side to process the call. In addition, the SETUP message can also indicate which bearer channel is used in a call. As one would expect with a packet used in the Bluetooth system, the bearer channel denotes whether SCO or ACL links are to be used. If, however, no bearer channel is indicated, a separate channel will not be established. The number information of the called party may be optionally incomplete. In such a case overlap sending is required. When the incoming side receives incomplete called-number information it starts Timer T302, sends a SETUP ACKNOWLEDGE message to the outgoing side and enters the overlap receiving state. Once the outgoing side receives this SETUP ACKNOWLEDGE message it enters the overlap sending state and starts timer T303 having stopped timer T304. The outgoing side then sends the remainder of the call information (if any) in the called party number information element of one or more INFORMATION messages, timer T304 being restarted every time the INFORMATION message is sent. If the INFORMATION message it receives does not include an indication that sending is complete and it cannot determine that the called party number is complete the incoming side restarts timer T302.

If either timer expires, call clearing is initiated with the cause being denoted as cause #102 -recovery on timer expiry, in the case of the outgoing side and as cause #28 - invalid number format, in the case of the incoming side. If, however, the incoming side determines that the number information is complete at the time of its timer’s expiry it shall send a CALL PROCEEDING, ALERTING or CONNECT message.

Once the incoming side has determined that the call establishment initiated by the SETUP message can take place it will send a CALL PROCEEDING message to the outgoing side to acknowledge the message and to indicate that the call is being processed and then enters the incoming call proceeding state. The outgoing side enters the outgoing call proceeding state, stops timer T303 and starts timer T310 once it receives this message. If the outgoing side has not received any communication as to the progress or termination of the call by the expiry of timer T310 it shall initiate call clearing. When the incoming side determines that the user has been alerted at the called address it will send an ALERTING message and enter the call received state. The outgoing side will stop all its running timers once it receives this message, begin an internally generated alert indication, enter the call delivered state and start timer T301. Once again call clearing is initiated if this timer expires.

Once the call has been accepted the incoming side will send a CONNECT message to the outgoing side, stops the user alerting and starts timer T313. Upon receipt, the outgoing side shall stop any internally generated alerting indications, stops any running timers, sends a CONNECT ACKNOWLEDGE message to indicate the completion of the requested bearer channel to the incoming side and enters the active state. The incoming side then connects to the bearer channel, stops timer T313 and enters the active state. While in this active state, both sides may exchange any information pertaining to the ongoing call using INFORMATION messages. If a multipoint configuration is used only one incoming side from many will be chosen so the outgoing side must send a RELEASE message to all other incoming sides that have responded to the SETUP message to indicate that the call is no longer available to them. In addition to this



non-selected user clearing, in-band tones and announcements are also catered for and are sent in a dedicated progress message.

3.2.3 Other Feature of the TCS ProtocolOne of the core features of a telephony system is call clearing capability. Clearing is initiated by the outgoing side’s sending of a DISCONNECT message, starting timer T305, disconnecting from the bearer channel and entering the disconnect request state, the incoming side entering a disconnect indication state upon receipt of the message.

The incoming side also disconnects from the bearer channel, starts timer T308, sends a RELEASE message to the outgoing side and enters the request release state. The outgoing side then cancels its T305 timer, sends a RELEASE COMPLETE message and returns to the null state. The incoming side subsequently returns to the null state as well as having stopped timer T308 and released the bearer channel. If either of the timers expire the operation will still attempt to proceed with indication of the expiry given. In-band tones and announcements can also be used in this procedure.

To cater for group management the specification defines the concept of a Wireless User Group (WUG). This is simply a number of Bluetooth devices that support TCS. The master-slave concept is used here as one of the devices, typically a gateway with access to the external network and always the piconet master, will be designated as the WUG master. All members of the WUG in range of the master are either active or parked members of the piconet and each member knows which unit is the WUG master and what other units in its range are members of the WUG. Once a unit has paired and initialised encryption with the master, no further pairing or initialisation is needed between it and the other members. However, because of this unconscious pairing, a unit is not granted access rights to all other WUG members. Instead, a specific procedure must be followed.

TCS also provides support for the Calling Line Identity, START DTMF messages and Register Recall. Connectionless TCS is also outlined in the specification.

The transmission of voice data has potentially wide applicability and possible uses are described in the Three-in-One phone and Ultimate Headset profiles in [3]. Its possible deployment is illustrated by its potential use in Bluetooth enabled cellular phones where a user can contact another user within a 10m range without incurring charges from its service provider. On initial inspection, it may appear that the exchange of voice data over such a short distance is of limited interest but as the protocol is omnidirectional and transmission is not affected by obstructions there is a broad scope for use in an office environment where users on different floors or in different areas can contact each other.



3.3 Interoperability Requirements for Bluetooth as a WAP Bearer

Despite its hype, WAP is simply a protocol. It is also not as prevalent as its promotion would suggest –the relative number of handsets is tiny. For example, in the UK the sale of Nokia’s 7110 phones was estimated at only 2000 [4]. However its popularity stems from the fact that it provides a truly standard way of linking the Internet to a mobile phone as it runs over GSM, CDMA or PDC. Unusually for volume 1 of the specification the use of the WAP protocol in the Bluetooth environment is illustrated by usage cases and unlike TCS or RS232 the protocol is given a description. In terms of the Bluetooth stack, WAP is considered here as a session layer protocol as it provides transport functionality for the wireless terminals that the core Bluetooth transport layer does not provide. [5] provides an overview of the WAP protocol.

The first usage case outlined in the specification is the ‘Briefcase Trick’, which is a hidden computing scenario that allows the user’s laptop and mobile phone to communicate without user intervention or the removal of the laptop from its briefcase in order to update the user’s email. The ‘Forbidden Message’ hidden computing scenario allows the user to compose messages while no dial-up connection is possible as the laptop later connects to the mobile phone for message transmission when connection is possible. The ‘WAP Smart Kiosk’ usage case allows a user to connect a Bluetooth enabled mobile device for communication with a kiosk in a public location such as an airport, thus providing the user with information specific to the particular location of the kiosk.

WAP, like the other higher layers of the Bluetooth protocol stack, needs a mechanism to access hardware components such as the baseband and link manager. This is provided by the Host Controller Interface.



4. The Bluetooth Network Layer – The Host Controller Interface

4.1 Overview

The last major section of Volume 1 of the Specification is the Host Controller Interface (HCI). Though difficult to classify, it can be argued that the Bluetooth HCI is a network layer protocol as it provides application access to the lower layer protocols in the stack such as the baseband and link manager. Though by far the largest portion of the specification with three subsections and being over 300 pages in length the implementation of the HCI is actually optional. This is because the protocol is unnecessary when the Bluetooth transport protocols are implemented on the same host processor that runs the applications. However a host controller unit is required if the transport protocols are implemented as an independent add-on - for instance, a plugin card –in a Bluetooth module as it must interpret information received from the host layer and pass it to appropriate module components such as the link manager or link controller. Additionally, it also passes data it receives from the module to the host.

The HCI consists of three components. The HCI Firmware, the host controller, exists at the Bluetooth module level and implements the commands for the Bluetooth hardware by accessing baseband and link manager commands as well as hardware status, control and event registers. The HCI transport component provides the mechanism for communication between the Bluetooth module and host. This component, the Host Controller Transport layer, may in fact consist of several intermediate layers that provide for the transparent transfer of data. The specification reuses the Universal Serial Bus (USB) protocol, the RS-232 serial port protocol and the universal asynchronous receiver and transmitter (UART) protocol for transport, this last protocol being a subset of RS-232 and is usable if the module attaches directly to the UART of a serial port without the need for cables. The HCI transport also has a driver to provide the components at the module and the host with the ability to exchange information with each other. Lastly, the HCI driver exchanges data and commands with the Host Controller.

4.2 HCI Events and Commands

A Host is notified that something has occurred by the receipt of an asynchronous notification of a HCI event no matter what transport layer is used. The received event packet is parsed by the host to determine what has happened. Such a packet is classified as a HCI Event packet and consists of an Event_Code field to determine the event type, the total length of the parameters in the Parameter_Total_Length field and the parameters in Event_Parameter fields numbered 0-N. Events are generally sent to notify the host of the completion of operations or the occurrence of errors. The specification describes events pertaining to connection, mode selection, QoS and security. For example, the Connection Request Event notifies the host of an incoming connection request.



The corollaries of HCI Event PDUs are HCI Command PDUs, which carry control information from the HCI layer to the host controller. The structure of the PDUs is similar to that used for event PDUs with the command type denoted in the Op_Code field and the parameters and their lengths carried in Parameter_Total_Length and Parameter fields. The command PDUs are themselves subdivided in the specification. The Link Control commands, which have a value of 0x01 in the OGF subfield of the Op_Code, allow the Host Controller to control connections to other Bluetooth devices. Effectively, LMP commands are performed instructing the Link Manager to create and modify link layer connections with Bluetooth remote devices and perform inquiries of other Bluetooth devices in range. A common Link Control command would be the Inquiry command, which causes the Bluetooth device to enter Inquiry Mode in order to discover other Bluetooth devices in its range. Once these commands are completed, corresponding event PDUs are sent to the host – for the example just given this would be the Inquiry Result Event.

The other subclass specific to the Link Manager level is that of the Link Policy commands (OGF is 0x02), which are used to modify the Link Manager’s behaviour so that changes to the link layer connections with Bluetooth remote devices occur. In the main, these commands pertain to QoS setup, mode selection and roles. The Host Controller and Baseband commands (OGF is 0x03) also provide control of the capabilities of the Link Manager but in addition are also used for access to and control of the actual Bluetooth device as well as the Host Controller and Baseband. Again, many of these commands relate to security and mode selection. The Informational Parameters (OGF is 0x04) command class is implementation specific and is fixed by the manufacturer of the Bluetooth hardware. These commands provide information about the Bluetooth devices and the capabilities of the Host Controller, Link Manager and Baseband. The current state of the Host Controller, Link Manager and Baseband can also be ascertained through the use of the Status Parameters command class (OGF is 0x05). The final command class outlined in the specification is that of Testing commands with an OGF of 0x06.

The final type of HCI packet is the HCI data packet, which is used to carry fragments of L2CAP PDUs and SCO data between the Host and the Host Controller. The format of the data packet depends on the data being transmitted is an ACL or SCO packet.

4.3 USB and RS232 Transport Layers

The specification also describes the transport layers for USB and RS232. Typically the USB hardware is envisaged as either being a dongle or integrated onto the motherboard of a notebook PC. HCI commands are differentiated from USB commands using class codes. The USB firmware will consist of an interface zero for bulk and interrupt endpoints and an interface one to provide scalable isochronous bandwidth consumption. While the former has no alternate settings, the latter has four that provide different consumption based on the required isochronous bandwidth. The endpoints are spread across the two interfaces so bulk and interrupt transactions do not have to be terminated when adjusting isochronous bandwidth consumption. Isochronous endpoints transfer SCO data; bulk endpoints perform this task for ACL data while HCI command packets are sent via the control endpoint 0.



The HCI RS232 transport layer facilitates the use of the Bluetooth HCI over one physical RS232 interface between the Bluetooth Host and the Bluetooth Host Controller. Though HCI command, event and data packets can be sent over this transport layer, a packet indicator must be added to differentiate between the HCI packet types. The RS232 transport layer also provides the ability to transmit Error Reporting and Negotiation packets, the former being used by the receiver to report the nature of an error to the transmitting side while the latter is used to negotiate communication settings and protocols. The frame of an RS232 Transport Packet for HCI packets consists of the packet type and a sequence number as well as the HCI packet.

RS232 is a very common protocol for serial ports. On the other hand it would appear that the HCI UART Transport layer is considered to be of lesser significance as a paltry 4 pages are dedicated to it but one must consider that a lot of the material in the RS232 addendum is of relevance here. The Objective of the HCI UART Transport Layer is to make it possible to use the HCI over a serial interface between two UARTs. Again packet indicators are used for the HCI command, event and data packets.



5. The Bluetooth Profiles

The usage of the Bluetooth protocol determines its success. This section details the Bluetooth profiles. A knowledge of these profiles is useful to garner a sense of the potential widespread applicability of the Bluetooth protocol.

5.1 Generic Access Profile

The security and authentication section of the Generic Access Profile is now outlined here.

5.1.1 Security and AuthenticationWhen in pairable mode a Bluetooth Device accepts pairing initiated by a remote device. The former will respond to a received LMP_in_rand with LMP_accepted or with LMP_in_rand if it has a fixed PIN. In non-pairable mode it responds to a received LMP_in_rand with LMP_not_acceptedwith the reason pairing not allowed.

The generic profile also describes the general authentication procedure. It outlines how the LMP-authentication and LMP-pairing procedures are used when authentication is initiated by one Bluetooth device towards another depending on whether a link key exists and if pairing is allowed.

There are three security modes – mode 1, 2 and 3. A device operating in mode 1 does not have any security barrier and never initiates a security procedure i.e. it never sends LMP_au_rand, LMP_in_rand and LMP_encryption_mode PDUs. A Bluetooth device in mode 2 shall not initiate any security procedure before it receives an L2CAP_ConnectReq channel establishment request PDU or before it initiates a channel establishment procedure itself. A Bluetooth device operating in mode 3 enforces security at the link manager layer. Authentication occurs before the transmission and receipt of the LMP_setup_complete PDU, i.e. prior to upper layer data communications. A Bluetooth device in security mode 3 may reject the host connection request with an LMP_not_accepted PDU based on settings with the host. For example, only communication with pre-paired devices is allowed. A Bluetooth device may only be in one security mode at a time.

5.1.2 Inquiry and Pairing ProceduresThe connectivity and security modes are associated with procedures that a Bluetooth device follows to react to inquiries, pages, PDUs etc. The idle mode refers to the sending device. General inquiries are used to discover devices in general discoverable mode. This provides the initiator with the Bluetooth device address, clock, Class of Device and used page scan mode of general discoverable devices. Devices in limited discoverable mode will also be discovered using general inquiry. General inquiries should be used by devices that need to discover Bluetooth devices that are made discoverable continuously or for no specific condition.



The Limited inquiry procedure provides the initiator with the Bluetooth Device address, clock, Class of Device and used page scan mode of limited discoverable devices. This procedure should be used by devices that need to discover other devices that are made discoverable only for a limited period of time, during temporary conditions or for a specific event. Since the discoverable device may not scan for the LIAC, the initiator may choose either the general or limited inquiry procedure.

Name discoveries provide the initiator with the Bluetooth Device Name of connectable devices. The Name request procedure retrieves the Bluetooth Device Name from a connectable Bluetooth device. The full link establishment procedure need not be performed. Device discovery provides the initiator with the Bluetooth address, Class of Device, page scan mode used and Bluetooth device name of discoverable devices. For this procedure a general or limited inquiry is performed and then name discovery is performed for some or all of the devices that responded to the inquiry.

Bonding is a pairing procedure executed for the purpose of creating a bond between two Bluetooth devices based on a common link key. The link key is created and exchanged during the bonding procedure and is stored by each device for future authentication. General Bonding combines bonding with additional higher layer initialisation procedures. It consists of link establishment, channel establishment, higher layer initialisation, channel release and the sending of an LMP_Detach PDU by the initiator. In contrast, the purpose of Dedicated Bonding is only to create and exchange a link key between two Bluetooth devices, i.e. upper-layer transactions are not involved.

The initiating device must know the Device Access Code of the device to pair with by performing device discovery for example. The initiator should use limited inquiry and the Bluetooth device that accepts the bonding should support the limited discoverable mode. Any link key set in a previous bonding to the paged device is deleted by the paging device before starting authentications.

5.2 Service Discovery Application Profile

The Service Discovery Application Profile (SDAP) provides a common and standard method for performing service discovery using the Bluetooth protocol stack [3]. SDAP is the only protocol that defines API like abstractions of service primitives and is aimed primarily at application writers.

A device participating in service discovery may be either a local device implementing the service discovery application or may be a remote device that is contacted by the local device to inquire about services. The former implements the client portion of the SDP layer while the latter implements its server portion.

The service discovery user application (SrvDscApp) in a local device (LocDev) initiates SDP transactions by sending service inquiries from the SDP Servers of remote devices (RemDevs).



RemDevs respond to these LocDev inquiries by maintaining a database that contains service records for its available services. SDP uses the connection-oriented (CO) transport service in L2CAP, which in turn uses the baseband ACL links to carry the SDP PDUs over the air. No more than the default settings for the protocol layers below the SDP layer need be used for the implementation of this profile i.e. authentication is necessary.

LocDev and RemDev device roles only exist for the duration of an SDP transaction. A device can act as a LocDev or RemDev at different times or even at the same time depending upon when it creates and responds to service inquiries. Both masters and slaves in a piconet can act asLocDev or RemDev devices. [6] describes the type of SDP transactions that can be carried out.

5.3 The Telephony Profiles

There are two main telephony profiles – cordless telephony and intercom. Each profile involves the routing of audio traffic in SCO packets over the Bluetooth air interface. These profiles are considered to be two of the parts of the ‘3-in-1’ phone usage case, the other being standard cellular telephony using for example, GSM or CDMA.

The Cordless Telephony Profile (CTP) encompasses all devices that use Bluetooth technology for short-range voice communication. The devices are distinct from cellular phones and terminals as they are for use with a local base station. The two main roles defined are the Gateway (GW) which acts as a terminal endpoint from the external network point of view and handles all call set-up requests to and from the external network. The terminal (TL) is the wireless user telephone and can be a PC or dual Cordless/Cellular phone as well as a cordless telephone. The CTP supports one GW, which acts as the piconet master and up to 7 TL slaves. An L2CAP connection is established and maintained when a TL connects to a gateway for as long as it remains in the piconet so that only the TCS-BIN protocol needs to be initiated over the existing L2CAP connection when a call is made or received. The audio stream is directly connected to the Baseband protocol.

As this profile significantly influenced the development of TCS-BIN most of the CTP is devoted to TCS-BIN procedures.1 These include connection management, call control procedures, supplementary services, group management procedures and connectionless procedures. There is a heavy emphasis on security in this profile. Only trusted TLs are allowed to connect to the GW and all traffic in a piconet must be encrypted.

The other profile of note that is based on TCS-BIN is the Intercom profile. The protocol stack mirrors that of the Cordless Telephony profile. As its name implies it implements the intercom part of the ‘3-in-1’ phone use case. With the intercom profile two devices (phone, computer etc.) that both support TCS-BIN can make a direct voice connection using the Bluetooth air-interface and is established using telephony based signaling. The intercom profile has the potential to

1 As outlined in 3.2.



provide cost savings to users. For example, two cellular phone users within 10 metres of each other can engage in a speech call using Bluetooth technology without incurring charges from their service provider.

5.4 The Serial Port Profiles

The Serial Port Profile (SPP) defines the requirements for Bluetooth devices necessary for setting up emulated serial cable connections using RFCOMM between two peer devices. The profile stack for a Serial Port Emulation is RFCOMM and SDP at the transport layer and Baseband, L2CAP and LMP at the OSI layer 1 and 2.

The applications on the initiator and acceptor sides are typically legacy applications, which want to communicate over a serial cable. Legacy applications will not know about Bluetooth procedures for setting up emulated serial cable connection so there must be a Bluetooth helper application on both sides. The order of connection does not necessarily have anything to do with the order in which the legacy applications are started on each side.

Only one scenario is covered by the SPP but many other profiles inherit from it as it is used in many cable-replacement scenarios. The SPP covers the setting up of virtual serial ports on two devices (e.g. PCs, PC and a Printer) and emulating a serial cable between the two devices. Any legacy application may be run on either device using the virtual serial port as if there were a real serial cable connecting the two devices.

Like the other more generic profiles there is an emphasis on security in the SPP. While the use of security features such as authorisation, authentication and encryption is optional for the execution of this profile, support for authentication and encryption is mandatory such that the device can take part in the corresponding procedures if requested from a peer device. Bonding is optional and the devices are peers i.e. there are no fixed master-slave roles. The initiator performs Link Establishment and Service Discovery Procedures also have to be performed to set up an emulated serial cable connection. The transport of control information and data is performed by RFCOMM.

In a typical serial port profile operation the initiator queries the acceptor for its server channel number using SDP. Server channels are used to multiplex RFCOMM connections. On response by the acceptor, authentication may be performed if requested. Once the L2CAP connection is established, an RFCOMM connection is established on the server channel.

SPP is an abstract profile so it is unlikely to be used directly by applications. Applications are more likely to implement some other profile such as the Headset profile.

One of the more well known use cases is the Ultimate Headset which can be wirelessly connected for the purpose of acting as a remote device’s audio input and output interface thus increasing the users freedom of movement. The Headset Profile defines the requirements for Bluetooth Devices necessary to support this use case. There are two roles defined for this



profile. The Audio Gateway (AG) is the device that is the gateway of the audio input and output while the Headset is the device acting as the AG’s remote audio input and output mechanism.

The AG and HS both use the OSI layer 1 and 2 Bluetooth protocols as well as SDP, RFCOMM and Headset Control. The latter is the entity responsible for headset specific control signaling, which is AT command based. The applications for the Audio Gateway and Headset sides are Audio Port Emulation and Audio Driver respectively. The audio port emulation layer is the entity emulating the audio port on the cellular phone or PC and the audio driver is the driver software in the headset. SPP is used as the base standard for the Bluetooth protocols used in this profile.

Unlike other voice-oriented protocols, security is not given a significant priority here as it is up to the user to enforce security on devices that support authentication or encryption. Again, the Headset Profile differs from other Telephony Protocols in that it is based upon SPP rather than TCS-BIN. This is because the rationale behind the Headset Profile is to provide a low-cost headset and this would be difficult to achieve with a TCS-BIN implementation much of whose functionality would be redundant anyway for the simple Headset Profile.

As in SPP the devices are peers. The HS and AG both provide serial port emulation using the SPP. Serial Port emulation is used to transport the user data including modem control signals and AT commands from the HS to the AG. AT commands are parsed by the AG and responses are sent to the HS.

Most headset applications are expected to be embedded in headset equipment but may also be found in computers or telephones. According to [3], the audio control and routing used for headsets can be generalized to other similar cases such as audio routing to an automobile.

5.5 The Networking Profiles

The networking profiles use Bluetooth wireless communications to remove the need for cables. The primary goal of these profiles is for long-range data communications and networking. The use cases supported are Dial-up Networking, Fax and LAN Access.

5.5.1 The Dial-up Networking ProfileThe Internet Bridge usage model facilitates modem access to a PC through phone or cordless modem and gives a user fax and dial-up networking capabilities without the need for a physical connection to the PC. The Dial-up Networking profile (DUNP) covers part of this use case. The profile covers the use of a cellular phone or modem by a computer as a wireless modem for connecting to a dial-up Internet access server and to receive data calls.

Again, two device roles are defined for this profile. In this instance, the Gateway (GW) is the device that provides access to the public network, for example, a cellular phone or modem while the Data Terminal (DT) device uses the dial-up services of the gateway, for example, the laptop and a desktop PC. In terms of the conventional modem system architecture, the GW is



considered the Data Circuit Endpoint (DCE) and the DT is considered to be the Data Terminal Endpoint (DTE). Both devices are considered to be peers. However, it should be noted that link establishment is always initiated by the DT.

The RFCOMM, SDP, LMP, L2CAP and Baseband protocols are common to the stack on both the GW and DT sides. Dialing and control is also common to both devices. These are the commands and procedures used for automatic dialing and control over the asynchronous serial link provided by the lower layers. At the application layer the GW has a modem emulation layer which, as its name implies, emulates the modem while the DT has a modem driver, which acts as its driver software at its application layer.

Again, SPP is used as the base standard for the Bluetooth specific protocols, i.e. all requirements stated in the SPP generally apply. Both the GW and DT provide serial port emulation. This facilitates the transport of user data, modem control signals and AT commands, the latter being parsed by the GW and sent to the DT.

As should be expected of a networking profile, DUNP has a significant emphasis on security. An initialisation procedure must be performed before a GW can be used with a DT for the first time. This involves exchanging a PIN code, creating link keys and service discovery. Typically this initialisation support must be manually activated and a PIN code must be entered on the DT, typically a PC or Laptop keyboard. Security is ensured by authentication on connection establishment and all user data is encrypted. As usual the baseband and LMP mechanisms are used for this.

Dial-up networking is an area where computing and communications overlap. Telephony devices access telephone networks so that computing devices can use that connection to access data networks. Though the use of dial-up networking is already facilitated by some mobile phones without the use of Bluetooth technology, these normally require a cable connection between phone and PC. Even in the case of infra-red technology the phone has to be directly facing the PC, a constraint not imposed by Bluetooth.

Once connection has been established, a typical dial-up networking profile operation consists of a DT such as a Laptop sending AT commands over RFCOMM to a GW such as a Bluetooth enabled cellular phone. ACL data traffic is then sent to the GW and then onto the Internet while, as outlined above, there may be optional SCO audio feedback. Like most of the other profiles that use the SPP, the DUNP is intended to enable legacy applications to take advantage of Bluetooth wireless links for existing functions. Once network connection has been established, applications that use standard networking profiles such as TCP/IP, HTTP, UDP/IP and FTP can use the dial-up networking connections to execute. It should be noted that voice calls and fax service are not supported here, the former being covered by the Telephony profiles while the latter has its own profile.

Though the Fax Profile is very similar to the Dial-up Networking Profile in that both involve the modulation and demodulation of commands and data between two end points over a telephone line, there are some differences in terms of the AT command set used. Nevertheless, it may



appear curious that it warrants its own profile as there is much commonality in terms of the protocol stack and device roles. However, Fax transmission is not an operation usually associated with Dial-up Networking and this may be the rationale behind the Fax operation having its own profile.

5.5.2 The LAN Access ProfileThe last networking profile outlined by the specification is the LAN Access profile. As the name implies, this profile defines how Bluetooth-enabled devices can access a Local Area Network using PPP. Like the DUNP, it uses established networking protocols such as IP over a Bluetooth wireless link to obtain access to a data network. However, in this instance, a network data access point is used instead of a modem or phone. Usage of the LAN Access Profile is restricted to PPP over the Bluetooth link. The specification authors chose PPP, as it is a widely deployed means of allowing access to data networks, providing authentication, encryption and data compression.

As is usual for these profiles, two device roles are specified in [7]. The LAN Access Point (LAP) is the Bluetooth Device that provides access to a LAN. Examples include ethernet, fiber channel, cable modem and firewire. The LAP acts as the PPP server. RFCOMM is used to transport the PPP packets and can also be used for flow control of the PPP data stream. The data terminal (DT) uses the services of the LAP and could be a PC or Laptop, for example. The DT is considered to be the PPP client.

There are several scenarios covered by this profile. A single DT can use a LAP to connect to a Local Area Network. Once connected, the DT will act as if it were connected to the LAN via dial-up networking and can access the services of the LAN. Multiple DTs can also use a single LAP for LAN connection and can communicate with each other via the LAP. Finally, two Bluetooth enabled PCs can form a single connection with each other. In this case one device will act as a LAP and the other as its DT client.

In terms of the protocol stack, the DT and LAP use the same Bluetooth protocols. At OSI layer 1 and 2, the core Baseband, LMP and L2CAP protocols are used and at the transport layer SDP and RFCOMM are both used. As pointed out above, the adopted PPP protocol is used over the latter. In addition, a Management Entity (ME) is used to coordinate procedures during initialisation, configuration and connection management. As one would expect, TCP, UDP and IP are all used on the Data Terminal side for data transmission to the LAN. PPP-Networking is used by the LAN Access Point to take IP packets to and from the PPP layer and place them on the LAN.

The LAN Access Profile has been criticised for not being as robust as expected in particular for peer-to-peer communication. However, as is pointed out in [6], there is not yet a fully accepted way for achieving peer-to-peer communication in wireless ad-hoc networks. While it is argued that this is the best solution that the specification authors could achieve given their time constraints it must also be acknowledged that IP Networking issues such as address assignment, name resolution and default router assignment in an ad-hoc network with no DHCP or DNS



services pose issues that are not addressed in the profile. However this has been acknowledged by the specification authors and there is currently an extension and enhancement working group examining Personal Area Networking (PAN) with a view to its inclusion in version 2.0 of the specification.

As for the Dial-up Networking Profile the LAP has a myriad of uses. In addition to the common data communications such as FTP, File Transfer, email etc. other protocols such as WAP can operate over the PPP link. A possible area for research is the feasibility of operating other protocols over PPP. For example, SNMP, the network management protocol, could be operated over PPP.

While the networking profiles deal with the connection to and the transfer of data over a communications network there is also a need to deal with cases where objects such as files are transferred from one Bluetooth-enabled device to another without the need to connect to a network. The specification authors acknowledge this in their development of the Object Exchange Profiles.

5.6 The Object Exchange Profiles

5.6.1 The Generic Object Exchange ProfileLike the SPP, the Generic Object Exchange Profile (GOEP) is an abstract profile that is used as a derivative in several other profiles. The GOEP defines the requirements necessary for the support of object exchange usage models in Bluetooth devices such as Synchronisation, File Transfer and Object Push. While the most common devices using the networking profiles would be desktop PCs and Laptops it is envisaged that the primary users of the Object Exchange Usage Models would be notebook PCs, PDAs, smart phones and mobile phones.

The two device roles defined for this protocol are the Server which provides an Object Exchange Server that data objects can be pushed and pulled to and from respectively and the Client which is the device that pushes and pulls data objects to and from the server. The core and adopted Bluetooth protocols used in the stack are the Baseband, LMP, L2CAP and SDP for the former and OBEX for the latter. There are no fixed master-slave roles. The two stacks differ only at the application layer. The Application Client layer sends and receives data objects from the server using the OBEX operations while the Application Server layer represents the data storage to and from which the data object can be sent or retrieved.

The scenarios covered by the GOEP profile are basic – the pushing of data objects to a Server by a Client and the pulling of data objects from a Server by a Client. It is assumed that the Server Device is in the discoverable and connectable modes when the client initiates inquiry and link establishment procedures respectively. Only point-to-point configurations are supported, i.e. only one Client per Server. Unlike the networking profiles, security requirements are not as rigorous as security is application dependent.



5.6.2 The Object Push ProfileThe GOEP is a foundation for other more concrete profiles. The simplest of these is the Object Push Profile (OPP) and covers the pushing of an object from one Bluetooth device to another. The specification envisages that this will most commonly be a business card, which can be represented using the vCard Format. The Bluetooth Core and Adopted Protocols used in the stack of this profile mirrors that of the GOEP. The device roles are that of Push Server and Push Client. The former acts as an object exchange server while the latter pushes and pulls objects to and from the Push Server.

Though the primary motivation of the OPP is to push an object such as a business card or appointment to a Push Server, the name is somewhat misleading as it also covers the scenarios where a Push Client pulls a business card from or exchanges business cards with a Push Server.

As with the GOEP, Link Level authentication, encryption and bonding are mandatory to support but optional to use while OBEX authentication is not used. The OPP does not require the server or client to enter the discoverable or connectable mode. The profile only points out that end user interaction is needed on the Client side to initiate the Object push, business card pull or business card exchange.

The profile mandates that mode selection for the push servers should be implemented. The Object Exchange Mode enables Push Clients to push and pull objects to and from the Push Server. When entering this mode Push Servers should set their device in limited discoverable mode. The profile recommends that this mode be enabled and disabled by user interaction. The profile also outlines function selection on the client side representing the three scenarios outlined above. As with mode selection, the Object Push, Business Card Pull and Business Card Exchange functions require user interaction.

A typical Object Push operation is initiated when the user sets the Push Server into Object Exchange mode. The Push Client user then selects the Object Push function on the device. A list of Push Servers that may support the Object Push Service is then displayed to the user. The user then selects a Push Server to push the Object to. When an Object is received in the push Server the profile advises that the Push Server user should be asked to accept or reject the request. The procedures for Business Card Pull and Exchange operations are similar to that of Object Push, the only difference being the selection by the user on the Client side. With all operations the user may have to enter a Bluetooth PIN if authentication is used.

OPP restricts the type of Objects that can be transferred to those Objects which are in vCard 2.1, vCalendar 1.0, vMessage and vNote content formats for Phone Book, Calendar, Messaging and Notes applications respectively. Indeed it can be considered to be a subset of file transfer. The File Transfer Profile on the other hand is broader in scope as it facilitates the transfer of files and directories.



5.6.3 The File Transfer ProfileThe File Transfer Usage Model offers the ability to transfer files such as spreadsheets or documents from one Bluetooth enabled device such as a PC or Laptop to another. The scenarios covered are the use of a Bluetooth device to browse the file system or what is termed in the profile as the object store of another device. Browsing involved the view of objects such as files and folders and navigating the directory folder of another device. The transfer of files and folders from one device to another is also envisaged, as is object manipulation, for example, deleting and creating objects. File transfer is likely to be a widely supported operation in Bluetooth implementations. As one would expect, user interaction is needed to initiate the operations outlined. This is where both OPP and the File Transfer protocol differ from the Synchronisation Profile where Object Exchange can be implemented programmatically.

5.6.4 The Synchronisation ProfileThe Synchronisation Usage model is one of the most common examples cited when describing potential Bluetooth applications. For example, data on a PDA can be automatically synchronised when the former comes into the range of a desktop PC or Laptop. The core Bluetooth protocols in the Synchronisation Profile’s stack are the same as those used in the other GOEP derived profiles. However the mechanism used to synchronise the objects is the IrMC protocol. The synchronisation involved is typically unidirectional object transfer but may be more complex involving, for example, conflict resolution. As with OPP the vCard 2.1, vCalendar 1.0, vMessage and vNote content formats must be supported for the synchronisation of phonebooks, calendars, messages and notes respectively. The roles for this profile are defined in terms of the IrMC specification. The IrMC server provides the object exchange server and is typically a mobile phone or PDA while the IrMC Client is the device that pulls and pushes the objects to and from the IrMC Server and is typically a PC. Both devices can initiate link and channel establishments.

The specification covers three scenarios. An IrMC Client may pull an object to be synchronised from an IrMC Server, synchronise the object with that on the IrMC Client and push the newly synchronised object back to the IrMC Server. Alternatively this scenario may be initiated by the IrMC Server sending a sync command to the IrMC Client. The IrMC Client may also initiate synchronisation automatically. However, though synchronisation may be carried out without user intervention the profile does not mandate the IrMC server or client to enter any discoverable or connectable modes automatically so end-user intervention may be needed.

Synchronisation is a potentially dangerous operation. For example, an IrMC Client could easily send a virus onto its server especially as it is envisaged that automatic synchronisation may not be noticed by the user. Unsurprisingly, the specification does acknowledge this by its requirement that bonding, link level authentication and encryption must always be used for this profile.

The Synchronisation profile caters for the selection of two modes. In the Initialisation mode, the IrMC Server is in the Limited Discoverable, Connectable and Pairable modes. The profile



advises that the IrMC Client use the Limited Inquiry procedure when discovering the IrMC Server. Both the IrMC Client and Server can enter the General Sync Mode. The device is in connectable mode in this case and is used for the IrMC Server when the IrMC Client connects the server and starts the synchronisation. The mode is used by the IrMC Client when the synchronisation is initiated by the IrMC Server. The devices can enter these modes automatically but are not required to do so, i.e. user intervention is supported.

Before initiating a synchronisation scenario the IrMC Server device must be in the General Sync Mode, and if not, the mode must be activated by the user. The user then activates an application for synchronisation and a list of devices within the client’s range is then displayed. The user then selects a device to be connected to and synchronised, an alert being generated if this device does not support synchronisation. Once security procedures have been performed the synchronisation operation is then carried out. The objects are pulled from the IrMC Server, the synchronisation is performed and the resulting synchronised objects are then pushed back to the IrMC Server.

If the IrMC Server wants to initiate synchronisation the Client must be in the General Sync Mode. As this operation may be carried out without any interaction from the Client User, user intervention should not be required. The user then selects the Sync Command in the IrMC Server and the synchronisation with the IrMC client is then carried out. With the automatic synchronisation scenario the Client starts synchronisation without notifying the user once the IrMC Server enters its proximity. As the client needs to notice the IrMC Server the latter must be in the General Sync mode. Automatic Synchronisation support is required for IrMC Servers but is optional for Clients.



References

[1] Miller, Brent

Mapping Salutation Architecture APIs to Bluetooth Service Discovery Layer

Version 1.0

Bluetooth White Paper

01 July 1999

[2] Angell, Chris

Bluetooth as a 3G Enabler

White Paper

Intercai Modiale Ltd

http://www.intercai.co.uk

[3] Bisdikian, Chatschik

Miller, Brent A.

Bluetooth Revealed

© Prentice Hall 2001

[4] WAP Insight

A rough guide to WAP

14 Feb 2000

[5] An Introduction to WAP

http://www.mobileipworld.com/wp/wp4/htm

[6] Mettala, Riku

Bluetooth Protocol Architecture

Bluetooth White Paper

Aug 25th 1999



[7] Sundry Contributors

Specification of the Bluetooth System Version 1.0B

Volume 2 Profiles

December 1st 1999

http://www.bluetooth.com

The Bluetooth Protocol

Technology

white paper

bluetooth protocol stack

protocol components

rfcomm protocol

sykoinia limited reserves

operation of tcs protocol

bluetooth profiles

service discovery protocol