The Stack And Packet Exchange
The Bluetooth Stack
The Bluetooth stack is a set of hierarchical protocols designed to deal with the data required to make a successful Bluetooth session. These protocols can be divided into two areas. First is the lower stack, also called a “controller stack”, which contains the timing and radio control protocol (where the Bluetooth header information is used to determine channel-hopping synchronization, for example, or rejecting a channel for too much interference). Then there's the upper stack, also called the “host stack,” which deals with the higher-level data, for example the “how” of dealing with a two-way VoIP call’s audio requirements over a Bluetooth connection.
The controller stack is most commonly implemented in the hardware of the Bluetooth module/chip itself. The relevant protocols are:
- ACL, or Asynchronous Connection-Less, a protocol for sending error-sensitive data like a document. The connection is asynchronous because the receiver and transmitter take turns sending while the other receives. ACL implements forward error-correction and retransmission of a data packet in the absence of acknowledgement.
- SCO, or Synchronous Connection-Oriented, a link protocol used for voice data, where each transmitter in the link simply sends data during its time slot without waiting for acknowledgement. There is no retransmission of data, but forward error-correction can be implemented.
- LMP, or Link Manager Protocol, used to handle link establishment between radios, queries and power control.
- LE LL, or Low Energy Link Layer, an equivalent of LMP for Bluetooth Low Energy links.
- HCI, or Host Controller Interface, a standardized communication protocol used to bridge the host stack and the control stack. There are multiple standards for HCI, and multiple hardware implementations.
The host stack most commonly sits at the operating system level of a PC, smartphone or other advanced device. In certain cases, like Bluetooth headsets, there may be no host stack at all, or a simplified host stack implemented in the device firmware. Protocols inherent in the host stack are:
- L2CAP, or Logical Link Control and Adaptation Protocol, used to pass packets from the host to the HCI, or, when the HCI is omitted, directly to the LMP. L2CAP multiplexes data between different higher-layer protocols (voice data for a phone call transmitted alongside data input from a Bluetooth keyboard, for example), segments and reassembles Bluetooth data packets.
- BNEP, or Bluetooth Network Encapsulation Protocol, used to deliver network packets above L2CAP.
- RFCOMM, or Radio Frequency Communication, a protocol used to emulate RS-232 serial ports.
- SDP, or Service Discovery Protocol, used to allow devices to discover each others' service parameters and which Bluetooth profiles are supported.
- TCS, or Telephony Control Protocol Specification, used to set up and control calls (voice and data) between devices.
- AVCTP, or Audio/Video Control Transport Protocol, used to transfer Audio Video Control over the L2CAP link.
- AVDTP, or Audio/Video distribution Transport Protocol, designed for audio and video distribution (such as streaming music to stereo headsets).
- OBEX, or Object Exchange, used for simple data exchange between devices, for example a document or image.
- ATT, or low energy ATTribute Protocol, the low-energy equivalent of SDP
- SMP, or Low Energy Security Manager, a protocol used for pairing and specific key distribution.
Apart from the location of implementation, the stack can be divided according to the type of link:
- Physical Links: a baseband connection between two devices, associated with exactly one physical channel. Physical link properties include power control, link supervision and encryption.
- Logical Transports: data transport between master and slaves. These include SCO and ACL.
- Logical Links: “virtual” links that control various transports. These are defined to be Link Control, ACL Control, User Asynchronous/Isochronous (ACL-U), User Synchronous (SCO-S) and User Extended Synchronous (eSCO-S).
Bluetooth Packets And Packet Exchange
With the Enhanced Data Rate implemented as of Bluetooth v3.0, data packets are split into two types: the Basic Rate packet, which consists of the access code, header and payload, and the Enhanced Data Rate Packet, which consists of the access code, header, guard period, synchronization sequence, enhanced data rate payload and trailer. Here is what the basic data rate Bluetooth packet structure looks like:
Packet handling and packet sub-components defined by the Bluetooth specification can become rather involved. For example, the Access Code begins with a preamble, a sync-word and a trailer. The preamble and first bit of the sync word provide bit-synchronization, allowing the receiver to set a "decision threshold" of incoming signal strength for the lowest possible BER. The last portion of the sync word and the trailer provide data for decoding the header, which follows the Access Code. Further, there are multiple types of access codes, depending on the operation to be performed: the Channel Access Code (CAC) is included in all packets and is used by piconet members to determine whether they should accept the rest of the packet, the Device Access Code (DAC) is used by the master to page a specific device, the General Inquiry Access Code (GIAC) is used by the master to inquire which Bluetooth devices are within range and the Dedicated Inquiry Access Code (DIAC) is used by the master to page only a specific type of device (to page only printers in the building, for instance, not headsets or smartphones).
The packet header is a 54-bit, six-field entry providing the real data a piconet needs to function, including the addresses of the active slaves the master is addressing, the type of packet being sent (ACL or SCO, for example), the flow of packets to control buffering, an acknowledgement of successful receipt, a sequential number bit to prevent acceptance of duplicate or retransmitted packets and a unique sequence generated from a given polynomial function in order to protect the device from accepting an incorrect packet.
Packets consisting of only an access code and header are called NULL and POLL. They're used to convey flow, acknowledgement or ping a slave for a response.
The payload itself is the biggest chunk of data transmitted, and its structure varies depending on what kind of data is being transmitted.