List of Bluetooth protocols
Bluetooth uses a variety of protocols. Core protocols are defined by the trade organization 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
Asynchronous Connection-Oriented (ACL) 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)
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 without using L2CAP retransmission and flow control mode or EL2CAP, a higher layer must handle the packet loss.
ACL links are disconnected if there is nothing received for the supervision timeout period; the default timeout is 20 seconds, but this may be modified by the master.
Synchronous connection oriented (SCO) 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.
enhanced SCO (eSCO) links use retransmissions to achieve reliability, and behave more like general data.
Link management protocol (LMP)
Used for control of the radio link between two devices. Implemented on the controller.
Host/controller interface (HCI)
Standardised communication between the host stack (e.g., a PC or mobile phone OS) and the controller (the Bluetooth IC). This standard allows the host stack or controller IC 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
Logical link control and adaptation protocol (L2CAP)
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 link. Its connection is established after the ACL link has been set up.
In basic mode, L2CAP provides packets with a payload configurable up to 64 kB, with 672 bytes as the default MTU, and 48 bytes as the minimum mandatory supported MTU. In retransmission and flow control modes, L2CAP can be configured for reliable or isochronous data per channel by performing retransmissions and CRC checks. Reliability in either of these modes is optionally and/or additionally guaranteed by the lower layer Bluetooth BDR/EDR air interface by configuring the number of retransmissions and flush timeout (time after which the radio will flush packets). In-order sequencing is guaranteed by the lower layer.
The EL2CAP specification adds an additional enhanced retransmission mode (ERTM) to the core specification, which is an improved version of retransmission and flow control modes. ERTM is required when using an AMP, such as 802.11abgn.
Bluetooth network encapsulation protocol (BNEP)
BNEP is used for delivering network packets on top of L2CAP. This protocol is used by the personal area networking (PAN) profile. BNEP performs a similar function to Subnetwork Access Protocol (SNAP) in Wireless LAN.
In the protocol stack, BNEP is bound to L2CAP
Radio frequency communication (RFComm.)
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
Service discovery protocol (SDP)
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)
In the protocol stack, SDP is bound to L2CAP.
TCP (Telephony Control Protocol)
Also referred to as telephony control protocol specification binary (TCS binary)
Used to setup and control speech and data calls between Bluetooth devices. The protocol is based on the ITU-T standard Q.931, with the provisions of Annex D applied, making only the minimum changes necessary for Bluetooth.
TCP is used by the intercom (ICP) and cordless telephony (CTP) profiles.
In the protocol stack, TCP is bound to L2CAP.
Audio/visual control transport protocol (AVTCP)
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
Audio/visual data transport protocol (AVDTP)
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
Object exchange (OBEX)
Object exchange (OBEX; 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.