List of Bluetooth protocols

This article needs additional citations for verification. Please help improve this article by adding citations to reliable sources. Unsourced material may be challenged and removed. Find sources: "List of Bluetooth protocols" – news · newspapers · books · scholar · JSTOR (March 2012) (Learn how and when to remove this message)

The wireless data exchange standard 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 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.

The normal type of radio link used for general data packets using a polling TDMA scheme to arbitrate access. It can carry packets of several 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 (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 L2PLAY 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.

The type of radio link used for voice data. A SCO link is a set of reserved time slots separated by the SCO interval T_sco which is determined during logical link establishment by the Central device. Each device transmits encoded voice data in the reserved timeslot. There are no retransmissions, but forward error correction can be optionally applied. SCO packets may be sent every 1, 2, or 3 time slots.

Enhanced SCO (eSCO) links allow greater flexibility in setting up links: they may use retransmissions to achieve reliability, allow for a wider variety of packet types and for greater intervals between packets than SCO, thus increasing radio availability for other links.

Used for control of the radio link between two devices, mobile dmv, querying device abilities and power control. Implemented on the controller.

Standardized communication between the host stack (e.g., a PC or mobile phone OS) and the controller (the Bluetooth integrated circuit (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.

This is the LMP equivalent for Bluetooth Low Energy (LE), but is simpler. It is implemented on the controller and manages advertisement, scanning, connection and security from a low-level, close to the hardware point of view from Bluetooth perspective.

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/ACL link.

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 asynchronous 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 (Alternate MAC/PHY), such as 802.11abgn.

BNEP^[1] 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.

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 (SPP) 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.

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 multiplexer 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.

Also referred to as telephony control protocol specification binary (TCS binary)

Used to set up 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.

TCS is used by the intercom (ICP) and cordless telephony (CTP) profiles. The telephone control protocol specification is not called TCP, to avoid confusion with transmission control protocol (TCP) used for Internet communication.

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.

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; 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.).

Similar in scope to SDP but specially adapted and simplified for Low Energy Bluetooth. It allows a client to read and/or write certain attributes exposed by the server in a non-complex, low-power friendly manner.

In the protocol stack, ATT is bound to L2CAP.

This is used by Bluetooth Low Energy implementations for pairing and transport specific key distribution.

In the protocol stack, SMP is bound to L2CAP.

• Bluetooth.com - Data Transport Architecture
• Oracle.com - Bluetooth protocol stack overview with diagram (halfway down the page)
• Bluetooth Specifications directory