Bluetooth protocols

Bluetooth uses a variety of protocols. Core protocols are defined by the trade organisation Bluetooth SIG. Additional protocols have been adopted from other standards bodies.

This article gives an overview of the core protocols and those adopted protocols that are widely used.

The bluetooth protocol stack is split in two parts: a "controller stack" containing the timing critical radio interface, and a "host stack" dealing with high level data.The controller stack is generally implemented in a low cost silicon device containing the bluetooth radio and a microprocessor.The host stack is generally implemented as part of an operating system, or as an installable package on top of an operating system.For integrated devices such as bluetooth headsets, the host stack and controller stack can be run on the same microprocessor to reduce mass production costs, this is known as a "hostless" system.

=Controller Stack=

ACL (Asynchronous Connection Less) link

The normal type of radio link used for general data packets using a polling TDMA scheme to arbritrate access.It can carry several different packet types, which are distinguished by:
* length (1,3 or 5 time slots depending on required payload size)
* forward error correction (optionally reducing the data rate in favour of reliability)
* modulation (EDR - enhanced data rate - packets allow up to triple data rate by using a different RF modulation for the payload)

Confusingly, ACL links are actually connection oriented. A connection must be explicitly set up and accepted between two devices before packets can be transferred.

ACL packets are retransmitted automatically if unacknowledged, allowing for correction of a radio link that is subject to interference. For isochronous data, the number of retransmissions can be limited by a flush timeout; but this requires L2CAP retransmission & flow control mode or EL2CAP.

ACL links are disconnected if there is nothing received for 20 seconds (supervision timeout)

CO (Synchronous Connection Oriented) link

The type of radio link used for voice data.An SCO link is a set of reserved timeslots on an existing ACL link. Each device transmits encoded voice data in the reserved timeslot. There are no retransmissions, but forward error correction can be optionally applied.

eSCO (enhanced SCO) links use retransmissions to achieve reliability, and behave more like general data.

LMP (Link Management Protocol)

Used for control of the radio link between two devices. Implemented on the controller.

HCI (Host/Controller Interface)

Standardised communication between the Host stack (e.g. a PC or mobile phone OS) and the Controller (the bluetooth I.C.)This standard allows the host stack or controller I.C. to be swapped with minimal adaptation.

There are several HCI transport layer standards, each using a different hardware interface to transfer the same command, event and data packets.The most commonly used are USB (in PCs) and UART (in mobile phones and PDAs).

In bluetooth devices with simple functionality, e.g. headsets, the host stack and controller can be implemented on the same microprocessor. In this case the HCI is optional, although often implemented as an internal software interface.

=Host Stack=

L2CAP (Logical Link Control and Adaptation Protocol)

L2CAP is used within the Bluetooth protocol stack. It passes packets to either the Host Controller Interface (HCI) or on a hostless system, directly to the Link Manager.

L2CAP's functions include:
*Multiplexing data between different higher layer protocols.
*Segmentation and reassembly of packets.
*Providing one-way transmission management of multicast data to a group of other bluetooth devices.
*Quality of service (QoS) management for higher layer protocols.

L2CAP is used to communicate over the host ACL "(Asynchronous Connectionless)" link. Its connection is established after the ACL link has been set up.

In basic mode, L2CAP provides reliable sequenced packets with a payload configurable up to 64kB, with 672 bytes as the minimum mandatory supported size.In retransmission & flow control modes, L2CAP can be configured for reliable or isochronous data per channel by configuring the number of retransmissions and flush timeout.

The EL2CAP specification adds an additional "enhanced mode" to the core specification, which is an improved version of retransmission & flow control modes.

BNEP (Bluetooth Network Encapsulation Protocol)

BNEP is used for delivering network packets on top of L2CAP. This protocol is used by the PAN (Personal Area networking) profile.BNEP performs a similar function to SNAP in Wireless LAN.

In the protocol stack, BNEP is bound to L2CAP

RFCOMM (Radio Frequency Communication)

The Bluetooth protocol RFCOMM is a simple set of transport protocols, made on top of the L2CAP protocol, providing emulated RS-232 serial ports (up to sixty simultaneous connections to a bluetooth device at a time). The protocol is based on the ETSI standard TS 07.10.

RFCOMM is sometimes called Serial Port Emulation. The Bluetooth Serial Port Profile is based on this protocol.

RFCOMM provides a simple reliable data stream to the user, similar to TCP. It is used directly by many telephony related profiles as a carrier for AT commands, as well as being a transport layer for OBEX over bluetooth.

Many bluetooth applications use RFCOMM because of its widespread support and publicly available API on most operating systems. Additionally, applications that used a serial port to communicate can be quickly ported to use RFCOMM.

In the protocol stack, RFCOMM is bound to L2CAP

DP (Service Discovery Protocol)

Used to allow devices to discover what services each other support, and what parameters to use to connect to them.For example, when connecting a mobile phone to a bluetooth headset, SDP will be used to determine which bluetooth profiles are supported by the headset (Headset Profile, Hands Free Profile, Advanced Audio Distribution Profile etc) and the protocol multiplexor settings needed to connect to each of them.Each service is identified by a Universally Unique Identifier (UUID), with official services (Bluetooth profiles) assigned a short form UUID (16 bits rather than the full 128)

See also SDAP, which is a bluetooth profile

In the protocol stack, SDP is bound to L2CAP

AVCTP (Audio/Visual Control Transport Protocol)

Used by the remote control profile to transfer AV/C commands over an L2CAP channel.The music control buttons on a stereo headset use this protocol to control the music player

In the protocol stack, AVCTP is bound to L2CAP

AVDTP (Audio/Visual Data Transport Protocol)

Used by the advanced audio distribution profile to stream music to stereo headsets over an L2CAP channel.Intended to be used by video distribution profile.

In the protocol stack, AVDTP is bound to L2CAP

OBEX (OBject EXchange)

OBEX (abbreviation of OBject EXchange, also termed IrOBEX) is a communications protocol that facilitates the exchange of binary objects between devices. It is maintained by the Infrared Data Association but has also been adopted by the Bluetooth Special Interest Group and the SyncML wing of the Open Mobile Alliance (OMA).

In Bluetooth, OBEX is used for many profiles that require simple data exchange, e.g. object push, file transfer, basic imaging, basic printing, phonebook access etc.

In the protocol stack, OBEX is bound to RFCOMM

ee also

* Bluetooth
* Bluetooth profile

External links

* [http://bluetooth.com/Bluetooth/Technology/Works/Data_Transport_Architecture.htm Bluetooth.com - Data Transport Architecture]
* [http://www.palowireless.com/infotooth/tutorial/l2cap.asp Palowireless.com - L2CAP Tutorial]
* [http://www.palowireless.com/infotooth/tutorial/rfcomm.asp InfoTooth RFCOMM Tutorial]