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 Limited
disseminates 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 info@vertoda.com.

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 info@vertoda.com.

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 info@vertoda.com 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 PDUs
Like 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 it
wishes 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 Primitives
Though 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 Protocol
Like 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 Components
As 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 Protocol
To 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 Protocol
One 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 Authentication
When 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_accepted
with 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 Procedures
The 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 as
LocDev 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 Profile
The 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 Profile
The 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 Profile
Like 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 Profile
The 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 Profile
The 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 Profile
The 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

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Viewers also liked

Viewers also liked (6)

Similar to The Bluetooth Protocol

Similar to The Bluetooth Protocol (20)

Recently uploaded

Recently uploaded (20)

The Bluetooth Protocol