List of Bluetooth protocols

The wireless data exchange standard Bluetooth uses a variety of protocols. Core protocols are defined by the trade organization Bluetooth SIG. Add 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

Link layer

The lowest layer of the Bluetooth protocol stack has no name (unlike Ethernet), but is responsible for transporting Bluetooth packets between devices on the piconet. Four "physical channels" are defined for each piconet: the basic piconet channel, which transports normal communication between devices; the adapted piconet channel, similar to the basic; the inquiry scan channel, for discovering Bluetooth devices; and the page scan channel, for connecting new devices. Each channel hops through the RF channels in a predetermined manner.

All packets have a "channel access code" header field which distinguishes the piconet from other piconets using the same RF channel. Additionally, packets in the basic and adapted piconet channels have the LT_ADDR header field, which specifies the packet's "logical transport." Logical transports only exist between the master and slave devices, never between slaves. Additionally, some logical transports can carry multiple logical links.

There are five types of logical transport:

Asynchronous Connection-Less (ACL)

The normal type of radio link used for general data packets using a polling TDMA scheme to arbitrate access. ACL can carry packets of several types, which are distinguished by:

Each device receives a default ACL logical transport when it joins the piconet. The connection must be explicitly set up and accepted between two devices before packets can be transferred. Each ACL "logical transport" carries one or more ACL "logical links", which are distinguished by the Logical Link ID (LLID) field of the ACL header. The default ACL has two default logical links: ACL-C for LMP control signaling, and the default ACL-U for L2CAP.

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 logical transports 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.

For legacy reasons, ACL and SCO logical transports share LT_ADDR's. Their packets are differentiated by timing.

Synchronous Connection-Oriented (SCO)

The type of radio link used for voice data. A SCO link is a set of reserved timeslots on an existing ACL transport. 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 timeslots.

Unlike ACL, SCO data is streamed instead of framed, so no distinction exists between SCO logical transports and logical links.

Active Slave Broadcast (ASB)

An implicit logical transport that carries broadcast L2CAP user data (but not L2CAP control commands). It uses the reserved LT_ADDR of 0, which it shares with Parked Slave Broadcast; their packets are differentiated by timing instead.

Parked Slave Broadcast (PSB)

An implicit logical transport that can carry a subset of LMP and broadcast L2CAP data. It uses the LT_ADDR 0, so its packets are superficially indistinguishable from ASB packets. However, only clients that have been "parked" with LMP (involving closing all their logical transports) listen for PSB packets.

Link control protocol (LC)

Used to communicate flow control, acknowledgement, and retransmission requests. It is embedded in the headers of logical transport protocols, except that ACL and SCO share an LC connection which can be carried in either's header.

Link manager protocol (LMP)

Used to control the connections between two devices, including creating, modifying, and releasing logical transports and logical links, querying device abilities, "parking" devices, and power control. LMP is carried over the ACL-C logical link of the default ACL logical transport, or over PSB. Implemented in the controller.

Low-energy link layer (LELL)

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.

Host controller interface (HCI)

The pseudo-protocol referring to any standardized communication between the host stack (e.g., a PC or mobile phone OS) and the controller (the Bluetooth IC). An HCI decouples the host from the controller, allowing either to be swapped without affecting the other. Bluetooth defines several HCI standards, each for a different hardware interface to transfer the same commands, events, and data packets. The most commonly used are USB (in PCs) and UART (in mobile phones and PDAs).

It must expose enough functionality to allow the host: to discover, add, and manage devices on the piconet; to configure controller properties; to set up, manage, and release logical transports and links; and to write directly to the baseband's buffer for SCO and eSCO streaming.

In simple Bluetooth devices (e.g., headsets), the host stack and controller can be implemented on the same microprocessor. In this case an HCI serves no purpose, and often implemented only 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 ACL/ASB/PSB link.

L2CAP's functions include:

It is channel-based, and control commands are sent on channel 0x0001. This signaling channel is available as soon as the default ACL-U logical link has been set up, and is used to set up additional channels. L2CAP channels can be connection-oriented or group-oriented, and are transported by ACL in the former case, or by ASB or PSB in the latter.

In basic mode, L2CAP provides packets with a payload configurable up to 64 kB, with 672 bytes as the default maximum transmission unit (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.

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 are supported by each other, 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.

Telephony Control Protocol Specification (TCS)

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.

TCP is used by the intercom (ICP) and cordless telephony (CTP) profiles.

Audio/video control transport protocol (AVCTP)

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/video distribution 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)

Main article: 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.

Low Energy Attribute Protocol (ATT)

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.

External links

This article is issued from Wikipedia - version of the 11/9/2016. The text is available under the Creative Commons Attribution/Share Alike but additional terms may apply for the media files.