List of Bluetooth protocols: Difference between revisions

Revision as of 16:45, 19 January 2010

Latest revision as of 14:22, 15 March 2025

(250 intermediate revisions by more than 100 users not shown)

Line 1:

{{Short description|none}}

'''[[Bluetooth]]''' uses a variety of '''[[protocol (computing)|protocol]]s'''. 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.

{{More citations needed|date=March 2012}}

[[File:BluetoothLogo.svg|thumb|right]]

'''The wireless data exchange standard [[Bluetooth]]''' uses a variety of '''[[protocol (computing)|protocol]]s'''. 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 bluetoothBluetooth 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 bluetoothBluetooth 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 bluetoothBluetooth 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 Connectionconnection-oriented Lesslogical transport]] (ACL) link{{anchor|ACL}} ===

The normal type of radio link used for general data packets using a polling [[Time division multiple access|TDMA]] scheme to arbritratearbitrate access. It can carry severalpackets differentof packetseveral types, which are distinguished by:

* length (1, 3, or 5 time slots depending on required payload size)

* forward[[Forward error correction]] (optionally reducing the data rate in favour of reliability)

* modulation (EDR[[Bluetooth#Bluetooth -2.0 enhanced+ dataEDR|Enhanced rateData -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 L2CAPL2PLAY 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 orientedConnection-Oriented (SCO) link{{anchor|SCO}} ===

The type of radio link used for voice data. AnA SCO link is a set of reserved timeslotstime onslots anseparated existingby ACLthe 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.

enhancedEnhanced 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 behavefor moregreater likeintervals generalbetween datapackets than SCO, thus increasing radio availability for other links.

=== Link managementManagement protocolProtocol (LMP){{anchor|LMP}} ===

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

=== Host/controller interfaceController Interface (HCI){{anchor|HCI}} ===

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

=== Low Energy Link Layer (LE LL){{anchor|LELL}} ===

== Host Stack ==

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 stack ==

=== Logical link control and adaptation protocol (L2CAP){{anchor|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/ACL link.

L2CAP's functions include:

Line 45 ⟶ 51:

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 isochronousasynchronous 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){{anchor|BNEP}} ===

'''BNEP'''<ref>https://www.bluetooth.com/specifications/specs/bluetooth-network-encapsulation-protocol-1-0/ {{Bare URL PDF|date=March 2022}}</ref> 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.RFCOMM){{anchor|RFCOMM}} ===

The Bluetooth protocol RFComm.RFCOMM is a simple set of transport protocols, made on top of the L2CAP protocol, providing emulated [[RS-232]] [[serial port]]s (up to sixty simultaneous connections to a Bluetooth device at a time). The protocol is based on the ETSI standard TS&nbsp;07.10.

RFComm.RFCOMM is sometimes called ''serial port emulation''. The Bluetooth ''serial port profile'' (SPP) is based on this protocol.

RFComm.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.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 RFCommRFCOMM.

In the protocol stack, RFComm.RFCOMM is bound to L2CAP.

www.bluetooth.com

=== Service discovery protocol (SDP){{anchor|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 profile]]s are supported by the headset (''[[Bluetooth_profileBluetooth profile#Headset_Profile_Headset Profile .28HSP.29|headset profile]]'', ''[[Bluetooth_profileBluetooth profile#Hands-Free_Profile_Free Profile .28HFP.29|hands free profile]]'', ''[[Bluetooth_profileBluetooth profile#Advanced_Audio_Distribution_Profile_Advanced Audio Distribution Profile .28A2DP.29|advanced audio distribution profile]]'', etc.) and the protocol multiplexormultiplexer 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}}

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 profile]]s are supported by the headset (''[[Bluetooth_profile#Headset_Profile_.28HSP.29|headset profile]]'', ''[[Bluetooth_profile#Hands-Free_Profile_.28HFP.29|hands free profile]]'', ''[[Bluetooth_profile#Advanced_Audio_Distribution_Profile_.28A2DP.29|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.

=== Telephony control protocol (TCPTCS){{anchor|TCS}} ===

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

Used to setupset 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.

TCPTCS is used by the ''[[Bluetooth_profileBluetooth profile#Intercom_Profile_Intercom Profile .28ICP.29|intercom]]'' (ICP) and ''[[Bluetooth_profileBluetooth profile#Cordless_Telephony_Profile_Cordless Telephony Profile .28CTP.29|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.

=== Audio/visualvideo datacontrol transport protocol (AVDTPAVCTP){{anchor|AVCTP}} ===

In the protocol stack, TCP is bound to L2CAP.

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 Audio/visual control transportthe protocol (stack, AVCTP) ===is bound to L2CAP.

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

=== Audio/video data transport protocol (AVDTP){{anchor|AVDTP}} ===

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){{anchor|OBEX}} ===

{{mainMain|OBEXOBject EXchange}}

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

=== Low Energy Attribute Protocol (ATT){{anchor|ATT}} ===

In the protocol stack, OBEX is bound to RFComm.

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, TCPATT is bound to L2CAP.

== See also ==

* [[Bluetooth]]

=== Low Energy Security Manager Protocol (SMP){{anchor|SMP}} ===

* [[Bluetooth profile]]

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

In the protocol stack, AVCTPSMP is bound to L2CAP.

== References ==

{{Reflist}}

== External links ==

*[https://web.archive.org/web/20100225214851/http://www.bluetooth.com/Bluetooth/Technology/Works/Data_Transport_Architecture.htm Bluetooth.com - Data Transport Architecture]

*[http://developers.sunOracle.com/mobility/midp/articles/bluetooth1/ - Bluetooth protocol stack overview with diagram (halfway down the page)]

*[http://www.palowireless.com/infotooth/tutorial/l2cap.asp Palowireless.com - L2CAP Tutorial]

*[https://www.bluetooth.com/specifications/specs/ Bluetooth Specifications directory]

*[http://www.palowireless.com/infotooth/tutorial/rfcomm.asp InfoTooth RFCOMM Tutorial]

*[http://developers.sun.com/mobility/midp/articles/bluetooth1/ Bluetooth protocol stack overview with diagram (halfway the page)]

[[Category:Bluetooth]]

[[Category:Lists of network protocols|Bluetooth]]

[[cs:Protokoly Bluetooth]]

[[es:Protocolos Bluetooth]]

[[ru:L2CAP]]