Introduction to Bluetooth protocol stack (bluetooth® stack)

1 Preface

This article simply introduces the Bluetooth protocol stack, including the HCI layer, ACL link,

L2CAP layer, SDP service and several common profiles that let beginners of the Bluetooth protocol stack
An overall framework for the entire Bluetooth protocol stack is understood. 2 HCI Layer Control of 2.1 HCI command and Response

Because different HCI commands have different processes for the results, some do not require results, and some require

Wait for the result to perform the next action, some in a certain state to be effective, for this
In the HCI layer, there is a mechanism for each command that is sent to check whether the current
This command can be sent (sometimes the HCI controller cannot receive commands at this time and cannot
Sent), if the command can be sent, check whether the command must wait for the result, and
And wait for the result to time out, and then start a timer to monitor the command's
Returns the result, and executes the command timeout process if the timeout has not yet been turned on. 2.2 HCI Grouping

"Bluetooth protocol and its source Code analysis" page 208
"Bluetooth_core_v4.2.pdf" 779 pages
"Bluetooth protocol and its source code analysis" The book can be purchased or downloaded from the Internet, where the label
Blog is the version of the online download, non-full version, if not on the number, to find their own corresponding bit
Reset
"Bluetooth_core_v4.2.pdf" Download Address:
https://www.bluetooth.org/DocMan/handlers/DownloadDoc.ashx?doc_id=286439 2.3 HCI CONFIGURATION PARAMETERS

"Bluetooth_core_v4.2.pdf" 787 page 2.4 Link Control Instructions

"Bluetooth protocol and its source Code Analysis" page 214
"Bluetooth_core_v4.2.pdf" 813 page 2.5 link Policy Command

"Bluetooth protocol and its source Code Analysis" page 216
"Bluetooth_core_v4.2.pdf" 926 page 2.6 host controller and baseband commands

"Bluetooth protocol and its source Code Analysis" page 216
"Bluetooth_core_v4.2.pdf" 951 page 2.7 Information parameter command

"Bluetooth protocol and its source Code analysis" page 218
"Bluetooth_core_v4.2.pdf" 1097 page 2.8 Status parameter command

"Bluetooth protocol and its source Code analysis" page 218
"Bluetooth_core_v4.2.pdf" 1110 page 2.9 Test command

"Bluetooth protocol and its source Code analysis" page 218
"Bluetooth_core_v4.2.pdf" 1138 page 2.10 Events

"Bluetooth protocol and its source Code Analysis" page 219
"Bluetooth_core_v4.2.pdf" 1152-page 2.11 ble controller command

"Bluetooth_core_v4.2.pdf" 1271 page 3 ACL link

L2cap communication is based on an ACL link, with only one ACL chain between two Bluetooth devices

Path, identified by the connect handle. Prior to any communication with L2CAP, the
You need to establish an ACL link, two pairs of Bluetooth devices, first establish an ACL pass
Code. Once the ACL link is established, some l2cap interactions are made and the information is obtained, but
When information needs to be obtained based on the SDP profile, L2cap creates an SDP logical chain
Path (identified by channel ID), the SDP interaction is established in the L2CAP channel
, after the SDP interaction is complete, the logical link of the SDP is broken, and if no subsequent
It needs to interact again, the ACL link will also break, but because it has been paired, the upper layer will
Save the ACL pairing information. 4 L2cap Layer 4.1 l2cap Layer Position

4.2 L2cap Bag

"Bluetooth_core_v4.2.pdf" 1737 pages

The type of L2CAP package is determined by the CID (Channel ID):
0x0000 Null identifier (not used)
0x0001 L2cap signaling Channel (signaling channel)
0X0002 connectionless channel (no connection channels for broadcast)
0x0003 AMP Manager Protocol
0x0004 Attribute Protocol (BLE)
0x0005 Low Energy L2cap signaling channel (BLE signaling channel)
0x0006 Security Manager Protocol (BLE)
0x0007 Br/edr Security Manager
0x0008-0x001f Reserved
0x0020-0x003e Assigned Numbers
0x003f AMP Test Manager
0X0040-0XFFFF dynamically allocated (dynamically allocated channel after connection, hosting profile data) 4.3 connection-oriented CHANNELS in BASIC

L2CAP Basic frame packet for connection 4.4 connectionless DATA CHANNEL in basic

L2cap non-connected frame envelope 4.5 connection-oriented CHANNEL in Retransmission/flow control/streaming

L2CAP connection-oriented retransmission, flow control frame Packet 4.6 connection-oriented CHANNELS in LE credits BASED flow control

L2cap for connection channel (ble use) 4.7 l2cap signaling Packet

"Bluetooth_core_v4.2.pdf" 1749 pages

L2cap signaling packet, where the content format of infromation payload is as follows:

Code value:

4.8 Status of the L2CAP layer

"Bluetooth_core_v4.2.pdf" 1802 pages
Closed–channel not connected.
Wait_connect–a Connection request has been received and only a
Connection response with indication "pending" can is sent.
Wait_connect_rsp–a connection request has been sent, pending a
Positive connect response.
config–the different options is being negotiated for both sides; This
State comprises a number of substates, see sections 6.1.3 on page 114
open–user data transfer state.
wait_disconnect–a DISCONNECT request has been sent, pending a
Disconnect response.
Wait_create–a Channel creation request has been received
Response with indication "pending" can is sent. This was similar to
Wait_connect.
Wait_create_rsp–a Channel creation request has been sent, pending
A channel creation response. This was similar to WAIT_CONNECT_RSP.
Wait_move–a request to MOVE the current channel to another Controller
have been received, but only a response with indication "pending" can is
Sent.
Wait_move_rsp–a request to MOVE a channel to another Controller have
been sent, pending a move response
wait_move_confirm–a response to the MOVE channel request have
been sent, waiting for a confirmation of the move operation by the initiator
Side
wait_confirm_rsp–a Move channel CONFIRM have been sent, waiting for
A move channel confirm response.

Various states receive different events in the processing, l2cap the focus.

5 Service Discovery Protocol (SDP) 5.1 SDP Protocol Data Unit (PDU)

"Bluetooth_core_v4.2.pdf" 1926 pages
Each SDP protocol Data unit (PDU) is assigned a parameter group by the PDU header and PDU
Yes. Message header contains three domains: Protocol data unit ID, transaction ID, and parameter length
Parameterlength, the parameter includes a subsequent state parameter.
5.2 SDP Connection establishment process

5.3 Service Record

Each service attribute describes a single characteristic of a service. Some
Examples of service attributes are:
5.4 Common SDP-acquired information

PnP information: Some Bluetooth headphones do not implement this part;
5.5 UUID Definition

Https://www.bluetooth.com/specifications/assigned-numbers/service-discovery 6 Universal access Profiles (Generic access profile, GAP)

Gap is the basis for all other profiles that define a baseband chain between Bluetooth devices
The general approach to the road. In addition, GAP defines the following:
Features that must be implemented in all Bluetooth devices
Common steps for discovering and linking devices
Basic user interface Terminology.

Gap handles the discovery and connection process between two devices that are not connected, and Gap ensures
Two Bluetooth devices can exchange information via Bluetooth technology. For the operation of Gap, directly from the
HCI command grouping control. 7 Rfcomm Protocol 7.1 rfcomm Data packet format

Frame Structure for Basic option

The contents of each part within a package

Uih frames with p/f-bit = 1 and credits based flow control used.

8 Audio/video CONTROL TRANSPORT PROTOCOL (AVCTP)

Audio/video Control Transport Protocol (AVCTP), which is used to Transport command and response

Messages for controlling Audio Video features in conformant
Devices. This protocol enables a device-to-support more than
One control profile at the same time; Each supported profile
shall define its own message formatting and/or usage rules. the location of the 8.1 avctp

AVCTP Protocol Packet

9 Audio/video REMOTE CONTROL profile (AVCRP)

The defines the requirements for bluetooth®devices necessary for the

Audio/video Remote Control usage case. The requirements
is expressed in terms of end-user services, and by defining
The features and procedures that is required for
Interoperability between Bluetooth devices in the
Audio/video Remote Control usage case. 9.1 AVRC

Generic audio/video Distribution Profile (GAVDP)

  This profiles defines the requirements for

Bluetooth®devices necessary to set up streaming channels
Used for support of audio/video distribution. The
Requirements is expressed in terms of the services provided to
Applications, and by defining the features and procedures
That is required for interoperability between Bluetooth
Devices in the Audio/video distribution usage model. 10.1 GAVDP Protocol location

audio/video distribution TRANSPORT PROTOCOL (AVDTP)

This protocol defines a/V stream negotiation, 

establishment, and transmission procedures. Also specified
Is the message formats that is exchanged between such
Devices to transport their A/V streams in A/V distribution
Applications. 11.1 AVDTP

11.2 AVDTP Some examples of interactions

Advanced AUDIO Distribution Profile (A2DP) 12.1 A2DP Protocol Location

Hand S-free profile (HFP)

The Hands-free profile (HFP) 1.7.1 specification

Defines a set of functions such that a Mobile Phone can be
Used in conjunction with a hands-free device (e.g., installed
In the car or represented by a wearable device such as a
Headset), with a Bluetooth Link providing a wireless means
For both remote control of the Mobile Phone by the hands-
Free device and voice connections between the Mobile
Phone and the Hands-free device. 13.1 HFP Protocol location

HEADSET profile (HSP)

This profiles defines the requirements for 

Bluetooth®devices necessary to support the Headset use
Case. The requirements is expressed in terms of end-user
Services, and by defining the features and procedures is
Required for interoperability between Bluetooth devices in the
Headset use case. 14.1 HSP Protocol location

HSP (cell phone specification) – provides the base required for communication between the mobile phone (mobile phone) and the headset
This feature.
HFP (Hands-free specification) – added some expansion functions on the basis of HSP, originally only
Used to control mobile phones from stationary in-car hands-free devices.
A2DP (Advanced Audio Transfer Specification) – allows the transmission of stereo audio signals. (Compared with
Mono-channel encryption in HSP and HFP, which is much better quality).
AVRCP (audio/Video remote control Specification) – for use from controllers (e.g. stereo headphones) to
A target device (such as a computer with Media Player) sends commands such as forward hop, pause
and playback). Human Interface Device (HID) profile

This profiles defines how devices with Bluetooth  

Wireless communications can use the HID specification
Initially to discover the feature set of a Bluetooth HID device,
And then communicate with the Bluetooth HID device. This
Profile further defines how a device with Bluetooth wireless
Communications can support HID services over the Bluetooth
protocol stack using the Logical Link Control and adaptation
Protocol (l2cap) layer. 15.1 HID Protocol location

15.2 HID Head message

Serial Port profile (SPP)

This profiles defines the requirements for  

Bluetooth®devices necessary for setting up emulated serial
Cable connections using RFCOMM between-peer devices. The requirements is expressed in terms of services
provided to applications, and by defining the features and
Procedures that is required for interoperability between
Bluetooth devices. 16.1 SPP Protocol location