Reviewing the Protocol Stack

The wide range of possible Bluetooth applications means that there are many
Bluetooth software layers.The lower layers (Radio Baseband, Link Controller, and
Link Manager) are very similar to the over-air transmissions.They can provide
voice connections and a single data pipe between two Bluetooth devices.To ease
integration of Bluetooth into existing applications, the specification provides
middle layers that attempt to hide some of the complexities of wireless communications.
In combination, these layers, when transmitting, can take many familiar
data formats and protocols, package them, multiplex them together, and pass
them on in a manner that matches the lower layers’ capabilities. Matching layers
at the receiving end de-multiplex and un-package the data.
At the bottom of the stack are some layers that are fundamental to Bluetooth
wireless technology: Radio Baseband, Link Manager, Logical Link Control and
Adaptation Protocol (L2CAP), and Service Discovery Protocol (SDP).Above
these layers, different applications require different selections from the higher
layers. Each profile calls up the higher layers it requires. If you implement more
than one profile in your application, you may be able to reuse the common
layers. Not all stack vendors support all layers so, if you are buying in a stack,
www.syngress.com
www.syngress.com
make sure that it supports the layers required for your application’s profiles.
Figure 2.1 shows the layers defined by the Bluetooth specification (shown
unshaded) and some other common layers (shown shaded).
L2CAP
Logical Link Control and Adaptation Protocol multiplexes upper layer data onto
the single Asynchronous ConnectionLess (ACL) connection between two
devices and, in the case of a master device, directs data to the appropriate slave.
It also segments and reassembles the data into chunks that fit into the maximum
HCI payload (the HCI is the Host Controller Interface, which connects higher
layers on a host to lower layers on a Bluetooth device). Locally, each L2CAP
logical channel has a unique Channel Identifier (CID), although this does not
necessarily match the CID used by the remote device to identify the other end
of the same channel. CIDs 0x0000 to 0x003F are reserved with 0x0000 being
Exploring the Foundations of Bluetooth • Chapter 2 71
Figure 2.1 Bluetooth Protocol Stack
Application
Baseband:
Link Manager,
Link Controller
and Radio
L2CAP
SDP
Audio
TCS
RFCOMM
OBEX
Device Manager
Connection
Manager
Security
Manager
Control
Data
Audio
HCI HCI
72 Chapter 2 • Exploring the Foundations of Bluetooth
unused; 0x0001 carrying signaling information; and 0x0002 identifying received
broadcast data.
The stack layers that sit above L2CAP can be identified by a Protocol
Service Multiplexor (PSM) value. Remote devices request a connection to a
particular PSM, and L2CAP allocates a CID.There may be several open channels
carrying the same PSM data. Each Bluetooth defined layer above L2CAP has its
own PSM:
 SDP – 0x0001
 RFCOMM – 0x0003
 Telephony Control Protocol Specification Binary (TCS-BIN) – 0x0005
 TCS-BIN-CORDLESS – 0x0007
L2CAP only deals with data traffic, not voice, and all channels, apart from
broadcasts (transmissions from a master to more than one slave simultaneously),
are considered reliable.
RFCOMM
RFCOMM (a name coming from an Radio Frequency [RF]-oriented emulation
of the serial COM ports on a PC) emulates full 9-pin RS232 serial communication
over an L2CAP channel. It is based on the TS 07.10 standard for a software
emulation of the RS232 hardware interface.TS 07.10 includes the ability to multiplex
several emulated serial ports onto a single data connection using a different
Data Link Connection Identifier (DLCI) for each port. However, each TS 07.10
session can only connect over a single L2CAP channel and thus only communicate
with one device.A master device must have separate RFCOMM sessions
running for each slave requiring a serial port connection.
Version 1.1 of the Bluetooth specification has added to the capabilities of the
standard TS07.10 specification by providing flow control capabilities.This caters
for mobile devices with limited data processing and storage capabilities allowing
them to limit the incoming flow of data.
OBEX
The Object Exchange standard (OBEX) was developed by the Infrared Data
Association (IrDA) to facilitate operations common to IR-enabled devices like
personal digital assistants (PDAs) and laptops. Rather than develop a new standard,
the Bluetooth SIG took OBEX largely as is, detailed a few specifics
regarding Bluetooth implementation (e.g., making some optional features mandatory),
and used it in the File Transfer, Synchronisation, and Object Push profiles.
OBEX allows users to put and get data objects, create and delete folders and
objects, and specify the working directory at the remote end of the link. IrDA has
also provided formats for data objects, while the Bluetooth specification has
adopted the vCard format for business card exchange and the vCal format for
exchanging calendars.
PPP
The Point-to-Point Protocol (PPP) is the existing method used when transferring
Transmission Control Protocol/Internet Protocol (TCP/IP) data over
modem connections.The Bluetooth specification reuses this protocol in the
local area network (LAN) Access Profile to route network data over an
RFCOMM port.Work is already underway on a TCP/IP layer that will sit
directly above L2CAP, bypassing and removing the overhead of PPP and
RFCOMM.This work is hinted at in some areas of the specification, but in v1.1
PPP, is all that’s available.
TCS Binary
Telephony Control Protocol Specification Binary (TCS Binary, also called TCSBIN),
is based on the International Telecommunication Union-Telecommunication
Standardization Sector (ITU-T) Q.931 standard for telephony call control. It
includes a range of signaling commands from group management to incoming
www.syngress.com
74 Chapter 2 • Exploring the Foundations of Bluetooth
call notification, as well as audio connection establishment and termination. It is
used in both the Cordless Telephony and Intercom profiles.
SDP
The Service Discovery Protocol differs from all other layers above L2CAP in that
it is Bluetooth-centered. It is not designed to interface to an existing higher layer
protocol, but instead addresses a specific requirement of Bluetooth operation:
finding out what services are available on a connected device.The SDP layer acts
like a service database.The local application is responsible for registering available
services on the database and keeping records up to date. Remote devices may
then query the database to find out what services are available and how to connect
to them.The details of service discovery can be complex and are discussed
further in Chapter 5, but each profile describes exactly what information should
be registered with SDP based on the application implementation.
Management Entities
Device, Security, and Connection Managers are not protocol layers so much as
function blocks.The Device Manager handles the lower level operation of the
Bluetooth device.The Connection Manager is responsible for coordinating the
requirements of different applications using Bluetooth channels and sometimes
automating common procedures.The Security Manager checks that users of the
Bluetooth services have sufficient security privileges.
HCI
The Host Controller Interface is not a software layer, but a transport and communications
protocol that aids interoperability between different manufacturers’
solutions. It is not mandatory to use the HCI interfaces defined in the specification
(Universal Serial Bus [USB]; RS232; or a simple Universal Asynchronous
Receive Transmit [UART]), or indeed any HCI transport at all, if there are better
solutions for your application.
Lower Layers
The lower layers (Radio Baseband, Link Controller, and Link Manager) format
the over-air transmissions, handle error detection and re-transmission, and manage
the links between devices.
Table 2.1 illustrates which profiles use which layers.