1 Introduction
本文只要对蓝牙协议栈做一个简单介绍，包含hci层、acl链路、
- 1
The l2cap layer, sdp service and several common profiles allow those who are new
to the Bluetooth protocol stack to have an overall understanding of the entire Bluetooth protocol stack.
2 HCI layer
HCI (host communication interface) host communication port, it mainly provides a unified communication port for the upper layer, which is mainly used to transmit commands and time. The approximate relationship diagram is as follows,
The host (user app) controls the Bluetooth by sending the commands defined in the communication protocol to control the Bluetooth to enter the response working mode. After the Bluetooth processing, it will return to the notification host in the form of an event.
Protocol data format
There are 4 types of data format transmitted by HCI, namely command, acl, sco and event. The corresponding types in the protocol data are
command(0x01) command pocket
acl(0x02) ACL Data pocket
sco(0x03) SCO Data Packet
event (0x04) event is mainly used by the be device to notify the host when an event occurs
command pocket
The data format of command pocket is as follows, you can also read the Bluetooth protocol stack document to understand.
Is opcode a command operation? It consists of ocf and ogf.
Is opcode a command operation? It consists of ocf and ogf.
ACL Data pocket
acl is mainly used for asynchronous exchange of data between master and slave devices, such as music playback, our l2cap is using this mode. The protocol data format of the data packet is as follows,
The handle represents the handle of the current communication channel, and the PB Flag (packet boundary flag) represents the receivable layer of the packet.
SCO Data Packet
SCO is mainly used for the transmission of synchronized data between ble and host. The data packet format is as follows,
The handle is as described above, the PSF is as follows,
Event Packet
The event is mainly used by the be device to notify the host when an event occurs, and the format is as follows.
2.1 Control of Hci commands and responses
由于不同的hci命令对结果有不同的处理，有的不需要结果，有些需要
- 1
The next action can be performed after waiting for the result. Some are valid in a certain state. For this
, there is a mechanism in the hci layer. Every time a command is sent, it will first check whether
the command can be sent (sometimes the hci controller cannot currently receive it). command can not be
sent), if the commands can be sent to check whether the command is necessarily wait for the results, and
and wait for the results of the timeout is the number, and then start a timer to monitor the command
returns the result, if not the result of a timeout, Perform command timeout processing.
2.2 hci grouping
"Bluetooth protocol and its source code analysis" 208
"bluetooth_Core_v4.2.pdf" 779 Ye
, "Bluetooth protocol and its source code analysis," The book can be purchased or downloaded from the Internet, where the standard
blog is to download the online version, non-intact If the version is not correct, find the corresponding location by yourself
.
"Bluetooth_Core_v4.2.pdf" download link:
https://www.bluetooth.org/DocMan/handlers/DownloadDoc.ashx?doc_id=286439
2.3 HCI CONFIGURATION PARAMETERS
《Bluetooth_Core_v4.2.pdf》 787
2.4 Link control commands
"Bluetooth Protocol and Source Code Analysis" page 214
"bluetooth_Core_v4.2.pdf" page 813
2.5 Link Policy Command
"Bluetooth Protocol and Source Code Analysis" 216 pages
"bluetooth_Core_v4.2.pdf" 926 pages
2.6 Host controller and baseband commands
"Bluetooth Protocol and Source Code Analysis" 216 pages
"bluetooth_Core_v4.2.pdf" 951 pages
2.7 Information parameter command
"Bluetooth Protocol and Source Code Analysis" page 218
"bluetooth_Core_v4.2.pdf" page 1097
2.8 Status parameter commands
"Bluetooth Protocol and Source Code Analysis" 218 pages
"bluetooth_Core_v4.2.pdf" 1110 pages
2.9 Test command
"Bluetooth Protocol and Source Code Analysis" 218 pages
"bluetooth_Core_v4.2.pdf" 1138 pages
2.10 Event
"Bluetooth Protocol and Source Code Analysis" 219 pages
"bluetooth_Core_v4.2.pdf" 1152 pages
2.11 BLE controller commands
《Bluetooth_Core_v4.2.pdf》 1271
3 ACL link
L2CAP的通信是基于ACL链路的，两个蓝牙设备之间只有一条ACL链
- 1
Road, identified by Connect Handle. Before any communication with L2CAP, it is
necessary to establish an ACL link first. To pair two Bluetooth devices, first establish an ACL
passcode. After the ACL link is established, some interaction L2CAP access to the information, but
require access to information-based Profile SDP, L2CAP SDP will create a logical chain
path, interaction is established SDP (identified by the Channel ID) in the L2CAP Channel
carried on, after the SDP interaction is complete, disconnect logical link SDP, if not behind
it and then need to interact, ACL link will be disconnected, but because they have been paired, the upper layer will
save the ACL pairing.
4 L2CAP layer
4.1 l2cap layer location
4.2 L2CAP package
《Bluetooth_Core_v4.2.pdf》 1737
The type of L2CAP packet is determined by CID (Channel ID):
0x0000 Null identifier (not used)
0x0001 L2CAP Signaling channel (signaling channel)
0x0002 Connectionless channel (connectionless channel, used for broadcasting)
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 after the connection is established Channel, carrying profile data)
4.3 CONNECTION-ORIENTED CHANNELS IN BASIC
L2CAP connection-oriented basic frame packet
4.4 CONNECTIONLESS DATA CHANNEL IN BASIC
L2CAP connectionless frame packet
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 CREDIT BASED FLOW CONTROL
L2CAP connection-oriented channel (used by BLE)
4.7 L2CAP signaling packet
《Bluetooth_Core_v4.2.pdf》 1749
The L2CAP signaling packet, in which the content format of the infromation payload is as follows:
Code value:
4.8 State of the L2CAP layer
《bluetooth_Core_v4.2.pdf》1802页
• CLOSED – channel not connected.
• WAIT_CONNECT – a connection request has been received, but only a
connection response with indication “pending” can be sent.
• WAIT_CONNECT_RSP – a connection request has been sent, pending a
positive connect response.
• CONFIG – the different options are being negotiated for both sides; this
state comprises a number of substates, see Section 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, but only a
response with indication “pending” can be sent. This state is similar to
WAIT_CONNECT.
• WAIT_CREATE_RSP – a channel creation request has been sent, pending
a channel creation response. This state is similar to WAIT_CONNECT_RSP.
• WAIT_MOVE – a request to move the current channel to another Controller
has been received, but only a response with indication “pending” can be
sent.
• WAIT_MOVE_RSP – a request to move a channel to another Controller has
been sent, pending a move response
• WAIT_MOVE_CONFIRM – a response to the move channel request has
been sent, waiting for a confirmation of the move operation by the initiator
side
• WAIT_CONFIRM_RSP – a move channel confirm has been sent, waiting for
a move channel confirm response.
各种状态下收到不同事件的处理，L2CAP的重点。
- 1
5 Service Discovery Protocol（SDP）
5.1 SDP protocol data unit (PDU)
"Bluetooth_Core_v4.2.pdf" page 1926
Each SDP protocol data unit (PDU) is composed of PDU header and PDU specified parameters
. The message header contains three fields: 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 Information obtained by common SDP
PnP Information: Some Bluetooth headsets do not implement this part;
5.5 UUID definition
https://www.bluetooth.com/specifications/assigned-numbers/service-discovery
6 Generic Access Profile (GAP)
GAP is the basis of all other configuration files. It defines a
general method for establishing a baseband link between Bluetooth devices . In addition, GAP also defines the following:
functions
that must be implemented in all Bluetooth devices to discover and link device General procedure
Basic user interface terminology.
GAP handles the discovery and connection establishment process between two unconnected devices. GAP ensures that
two Bluetooth devices can exchange information through Bluetooth technology. For the operation of GAP, it is directly controlled by
HCI command grouping.
7 RFCOMM protocol
7.1 RFCOMM data packet format
Frame Structure for Basic option
Each part of a package
UIH frames with P/F-bit = 1 and credit 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
- 1
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.
8.1 Location of AVCTP
AVCTP protocol packet
9 AUDIO/VIDEO REMOTE CONTROL PROFILE(AVCRP)
This profile defines the requirements for Bluetooth® devices necessary for the support of the
- 1
Audio/Video Remote Control usage case. The requirements
are expressed in terms of end-user services, and by defining
the features and procedures that are required for
interoperability between Bluetooth devices in the
Audio/Video Remote Control usage case.
9.1 AVRC
10 Generic Audio/Video Distribution Profile (GAVDP)
This profile defines the requirements for
- 1
Bluetooth® devices necessary to set up streaming channels
used for support of audio/video distribution. The
requirements are expressed in terms of services provided to
applications, and by defining the features and procedures
that are required for interoperability between Bluetooth
devices in the Audio/Video Distribution usage model.
10.1 GAVDP protocol location
11 AUDIO/VIDEO DISTRIBUTION TRANSPORT PROTOCOL(AVDTP)
This protocol defines A/V stream negotiation,
- 1
establishment, and transmission procedures. Also specified
are the message formats that are exchanged between such
devices to transport their A/V streams in A/V distribution
applications.
11.1 AVDTP
11.2 Some interactive examples of AVDTP
12 ADVANCED AUDIO DISTRIBUTION PROFILE (A2DP)
12.1 A2DP protocol location
13 Hand s-Free Profile(HFP)
The Hands-Free Profile (HFP) 1.7.1 specification
- 1
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
14 HEADSET PROFILE(HSP)
This profile defines the requirements for
- 1
Bluetooth® devices necessary to support the Headset use
case. The requirements are expressed in terms of end-user
services, and by defining the features and procedures that are
required for interoperability between Bluetooth devices in the
Headset use case.
14.1 HSP protocol location
HSP (Mobile Phone Specification)-Provides the basic
functions required for communication between a mobile phone (mobile phone) and a headset .
HFP (Hands-Free Specification) – On the basis of HSP, some extended functions have been added, which were originally only
used to control mobile phones from fixed car hands-free devices.
A2DP (Advanced Audio Transmission Specification)-allows the transmission of stereo audio signals. (Compared to the
mono encryption used for HSP and HFP, the quality is much better).
AVRCP (Audio/Video Remote Control Specification)-Used to
send commands (such as skip forward, pause,
and play) from a controller (such as stereo headset) to a target device (such as a computer with Media Player ).
15 Human Interface Device (HID) Profile
This profile defines how devices with Bluetooth
- 1
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
16 Serial Port Profile(SPP)
This profile defines the requirements for
- 1
Bluetooth® devices necessary for setting up emulated serial
cable connections using RFCOMM between two peer devices. The requirements are expressed in terms of services
provided to applications, and by defining the features and
procedures that are required for interoperability between
Bluetooth devices.
16.1 SPP protocol location
