Host

Specification of the Bluetooth® System

Volume 3

Covered Core Package Version: v6.0

Version Date: 2024-08-27

Bluetooth SIG Proprietary

 Host
Part A

LOGICAL LINK
CONTROL AND
ADAPTATION PROTOCOL
SPECIFICATION

The Bluetooth Logical Link Control and Adaptation

Protocol (L2CAP) supports higher level protocol
multiplexing, packet segmentation and reassembly,
and the conveying of quality of service information.
The protocol state machine, packet format, and
composition are described in this Part of the
specification.

Bluetooth SIG Proprietary

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 3, Part A Page 1075
Logical Link Control and Adaptation Protocol Specification

CONTENTS

1 Introduction ............................................................................................. 1080

1.1 L2CAP features ......................................................................... 1080
1.2 Assumptions .............................................................................. 1083
1.3 Scope ........................................................................................ 1084
1.4 Terminology ............................................................................... 1084

2 General operation ................................................................................... 1088

2.1 Channel identifiers .................................................................... 1088
2.2 Operation between devices ....................................................... 1091
2.3 Operation between layers ......................................................... 1092
2.4 Modes of operation ................................................................... 1093
2.5 Mapping channels to logical links .............................................. 1095

3 Data packet format ................................................................................. 1096

3.1 Connection-oriented channels in Basic L2CAP mode .............. 1096
3.2 Connectionless data channel in Basic L2CAP mode ................ 1097
3.3 Connection-oriented channel in Retransmission/Flow
Control/Streaming modes ......................................................... 1098
3.3.1 L2CAP header fields .................................................. 1098
3.3.2 Control field ................................................................ 1099
3.3.3 L2CAP SDU Length field (2 octets) ........................... 1103
3.3.4 Information Payload field ........................................... 1103
3.3.5 Frame Check Sequence (2 octets) ............................ 1103
3.3.6 Invalid Frame Detection (Retransmission and
Flow Control modes) .................................................. 1104
3.3.7 Invalid Frame Detection algorithm ............................. 1105
3.4 Connection-oriented channels in LE Credit Based Flow
Control mode and Enhanced Credit Based Flow Control mode 1106
3.4.1 L2CAP Header fields ................................................. 1106
3.4.2 L2CAP SDU Length field (2 octets) ........................... 1107
3.4.3 Information Payload field ........................................... 1107

4 Signaling packet formats ....................................................................... 1108

4.1 L2CAP_COMMAND_REJECT_RSP (code 0x01) ..................... 1111
4.2 L2CAP_CONNECTION_REQ (code 0x02) ............................... 1112
4.3 L2CAP_CONNECTION_RSP (code 0x03) ............................... 1113
4.4 L2CAP_CONFIGURATION_REQ (code 0x04) ......................... 1115
4.5 L2CAP_CONFIGURATION_RSP (code 0x05) .......................... 1117
4.6 L2CAP_DISCONNECTION_REQ (code 0x06) ......................... 1120
4.7 L2CAP_DISCONNECTION_RSP (code 0x07) ......................... 1120

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 3, Part A Page 1076
Logical Link Control and Adaptation Protocol Specification

4.8 L2CAP_ECHO_REQ (code 0x08) ............................................. 1121

4.9 L2CAP_ECHO_RSP (code 0x09) ............................................. 1121
4.10 L2CAP_INFORMATION_REQ (code 0x0A) .............................. 1122
4.11 L2CAP_INFORMATION_RSP (code 0x0B) .............................. 1123
4.12 Extended Feature Mask ............................................................ 1124
4.13 Fixed Channels Supported over BR/EDR ................................. 1125
4.14 [This section is no longer used] ................................................. 1126
4.15 [This section is no longer used] ................................................. 1126
4.16 [This section is no longer used] ................................................. 1126
4.17 [This section is no longer used] ................................................. 1126
4.18 [This section is no longer used] ................................................. 1126
4.19 [This section is no longer used] ................................................. 1126
4.20 L2CAP_CONNECTION_PARAMETER_UPDATE_REQ
(code 0x12) ............................................................................... 1126
4.21 L2CAP_CONNECTION_PARAMETER_UPDATE_RSP
(code 0x13) ............................................................................... 1127
4.22 L2CAP_LE_CREDIT_BASED_CONNECTION_REQ (code
0x14) ......................................................................................... 1128
4.23 L2CAP_LE_CREDIT_BASED_CONNECTION_RSP (code
0x15) ......................................................................................... 1129
4.24 L2CAP_FLOW_CONTROL_CREDIT_IND (code 0x16) ........... 1131
4.25 L2CAP_CREDIT_BASED_CONNECTION_REQ (code 0x17) . 1132
4.26 L2CAP_CREDIT_BASED_CONNECTION_RSP (code 0x18) .. 1133
4.27 L2CAP_CREDIT_BASED_RECONFIGURE_REQ (code
0x19) ......................................................................................... 1135
4.28 L2CAP_CREDIT_BASED_RECONFIGURE_RSP (code
0x1A) ......................................................................................... 1136

5 Configuration parameter options .......................................................... 1137

5.1 Maximum Transmission Unit (MTU) .......................................... 1137
5.2 Flush Timeout option ................................................................. 1139
5.3 Quality of Service (QoS) option ................................................. 1140
5.4 Retransmission and Flow Control option .................................. 1144
5.5 Frame Check Sequence (FCS) option ...................................... 1149
5.6 Extended Flow Specification option .......................................... 1150
5.7 Extended Window Size option .................................................. 1155

6 State machine ......................................................................................... 1157

6.1 General rules for the state machine .......................................... 1157
6.1.1 CLOSED state ........................................................... 1158
6.1.2 WAIT_CONNECT_RSP state .................................... 1159
6.1.3 WAIT_CONNECT state ............................................. 1160
6.1.4 CONFIG state ............................................................ 1160

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 3, Part A Page 1077
Logical Link Control and Adaptation Protocol Specification

6.1.5 OPEN state ................................................................ 1165

6.1.6 WAIT_DISCONNECT state ....................................... 1166
6.1.7 [This section is no longer used] ................................. 1166
6.1.8 [This section is no longer used] ................................. 1166
6.1.9 [This section is no longer used] ................................. 1166
6.1.10 [This section is no longer used] ................................. 1166
6.1.11 [This section is no longer used] ................................. 1166
6.1.12 [This section is no longer used] ................................. 1166
6.2 Timers events ............................................................................ 1166
6.2.1 RTX ............................................................................ 1166
6.2.2 ERTX ......................................................................... 1167

7 General procedures ................................................................................ 1170

7.1 Configuration process ............................................................... 1170
7.1.1 Request Path ............................................................. 1171
7.1.2 Response Path .......................................................... 1172
7.1.3 Lockstep Configuration process ................................ 1172
7.1.4 Standard Configuration process ................................ 1175
7.2 Fragmentation and recombination ............................................ 1177
7.2.1 Fragmentation of L2CAP PDUs ................................. 1177
7.2.2 Recombination of L2CAP PDUs ................................ 1178
7.3 Encapsulation of SDUs ............................................................. 1179
7.3.1 Segmentation of L2CAP SDUs .................................. 1179
7.3.2 Reassembly of L2CAP SDUs .................................... 1180
7.3.3 Segmentation and fragmentation .............................. 1180
7.4 Delivery of erroneous L2CAP SDUs ......................................... 1181
7.5 Operation with flushing On ACL-U logical links ......................... 1182
7.6 Connectionless data channel .................................................... 1183
7.7 Operation collision resolution .................................................... 1185
7.8 [This section is no longer used] ................................................. 1185
7.9 Prioritizing data over HCI .......................................................... 1185
7.10 Supporting Extended Flow Specification for BR/EDR and
BR/EDR/LE Controllers ............................................................. 1185
7.11 Enhanced Credit-Based Flow Control Reconfiguration ............. 1187

8 Procedures for Flow Control and Retransmission .............................. 1188

8.1 Information retrieval .................................................................. 1188
8.2 Function of PDU Types for Flow Control and Retransmission .. 1188
8.2.1 Information frame (I-frame) ........................................ 1188
8.2.2 Supervisory frame (S-frame) ..................................... 1188
8.2.2.1 Receiver Ready (RR) ................................. 1189
8.2.2.2 Reject (REJ) ............................................... 1189
8.3 Variables and sequence numbers ............................................. 1189

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 3, Part A Page 1078
Logical Link Control and Adaptation Protocol Specification

8.3.1 Sending peer ............................................................. 1190

8.3.1.1 Send sequence number TxSeq ................. 1190
8.3.1.2 Send state variable NextTXSeq ................. 1190
8.3.1.3 Acknowledge state variable
ExpectedAckSeq ........................................ 1190
8.3.2 Receiving peer ........................................................... 1191
8.3.2.1 Receive sequence number ReqSeq .......... 1191
8.3.2.2 Receive state variable ExpectedTxSeq ..... 1192
8.3.2.3 Buffer state variable BufferSeq .................. 1192
8.4 Retransmission mode ............................................................... 1193
8.4.1 Transmitting frames ................................................... 1193
8.4.1.1 Last received R was set to zero ................. 1193
8.4.1.2 Last received R was set to one .................. 1195
8.4.2 Receiving I-frames ..................................................... 1195
8.4.3 I-frames pulled by the SDU reassembly function ...... 1195
8.4.4 Sending and receiving acknowledgments ................. 1195
8.4.4.1 Sending acknowledgments ........................ 1196
8.4.4.2 Receiving acknowledgments ..................... 1196
8.4.5 Receiving REJ frames ............................................... 1197
8.4.6 Waiting acknowledgments ......................................... 1197
8.4.7 Exception conditions .................................................. 1197
8.4.7.1 TxSeq sequence error ................................ 1197
8.4.7.2 ReqSeq sequence error ............................. 1198
8.4.7.3 Timer recovery error ................................... 1198
8.4.7.4 Invalid frame ............................................... 1198
8.5 Flow Control mode .................................................................... 1199
8.5.1 Transmitting I-frames ................................................. 1199
8.5.2 Receiving I-frames ..................................................... 1200
8.5.3 I-frames pulled by the SDU reassembly function ...... 1200
8.5.4 Sending and receiving acknowledgments ................. 1200
8.5.4.1 Sending acknowledgments ........................ 1200
8.5.4.2 Receiving acknowledgments ..................... 1201
8.5.5 Waiting acknowledgments ......................................... 1201
8.5.6 Exception conditions .................................................. 1201
8.5.6.1 TxSeq sequence error ................................ 1201
8.5.6.2 ReqSeq sequence error ............................. 1202
8.5.6.3 Invalid frame ............................................... 1202
8.6 Enhanced Retransmission mode .............................................. 1202
8.6.1 Function of PDU types ............................................... 1203
8.6.1.1 Receiver Ready (RR) ................................. 1203
8.6.1.2 Reject (REJ) ............................................... 1203
8.6.1.3 Receiver Not Ready (RNR) ........................ 1203
8.6.1.4 Selective Reject (SREJ) ............................. 1204

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 3, Part A Page 1079
Logical Link Control and Adaptation Protocol Specification

8.6.1.5 Functions of the Poll (P) and Final (F) bits . 1204
8.6.2 Rules for timers .......................................................... 1204
8.6.2.1 Timer rules for ACL-U logical links ............. 1205
8.6.2.2 [This section is no longer used] ................. 1205
8.6.2.3 [This section is no longer used] ................. 1205
8.6.3 General rules for the state machine .......................... 1205
8.6.4 State diagram ............................................................ 1206
8.6.5 States tables .............................................................. 1207
8.6.5.1 State machines .......................................... 1207
8.6.5.2 States ......................................................... 1208
8.6.5.3 Variables and timers ................................... 1208
8.6.5.4 Events ........................................................ 1211
8.6.5.5 Conditions .................................................. 1212
8.6.5.6 Actions ....................................................... 1214
8.6.5.7 XMIT state table ......................................... 1219
8.6.5.8 WAIT_F state table .................................... 1220
8.6.5.9 RECV state table ........................................ 1220
8.6.5.10 REJ_SENT state table ............................... 1224
8.6.5.11 SREJ_SENT state table ............................. 1227
8.7 Streaming mode ........................................................................ 1231
8.7.1 Transmitting I-frames ................................................. 1231
8.7.2 Receiving I-frames ..................................................... 1231
8.7.3 Exception conditions .................................................. 1232
8.7.3.1 TxSeq sequence error ................................ 1232

9 [This section is no longer used] ............................................................ 1233

10 Procedures for Credit Based Flow Control .......................................... 1234

10.1 LE Credit Based Flow Control mode ......................................... 1234
10.2 Enhanced Credit Based Flow Control Mode ............................. 1235

Appendix A Configuration MSCs ...................................................................... 1236

Appendix B Changes to signaling packet names ........................................... 1239

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 3, Part A Page 1080
Logical Link Control and Adaptation Protocol Specification

1 INTRODUCTION

This section of the Bluetooth Specification defines the Logical Link Control and
Adaptation Layer Protocol, referred to as L2CAP. L2CAP provides connection-oriented
and connectionless data services to upper layer protocols with protocol multiplexing
capability and segmentation and reassembly operation. L2CAP permits higher level
protocols and applications to transmit and receive upper layer data packets (L2CAP
Service Data Units, SDU) up to 64 kilobytes in length. L2CAP also permits per-channel
flow control and retransmission.

The L2CAP layer provides logical channels, named L2CAP channels, which are
multiplexed over one or more logical links.

1.1 L2CAP features

The functional requirements for L2CAP include protocol/channel multiplexing,
segmentation and reassembly (SAR), per-channel flow control, and error control.
L2CAP sits above a lower layer composed of one of the following:

1. BR/EDR Controller
2. BR/EDR/LE Controller (supporting BR/EDR and LE)
3. LE Controller (supporting LE only)

L2CAP interfaces with upper layer protocols.

Figure 1.1 breaks down L2CAP into its architectural components. The Channel
Manager provides the control plane functionality and is responsible for all internal
signaling, L2CAP peer-to-peer signaling and signaling with higher and lower layers.
It performs the state machine functionality described in Section 6 and uses message
formats described in Section 4, and Section 5. The Retransmission and Flow Control
block provides per-channel flow control and error recovery using packet retransmission.
The Resource Manager is responsible for providing a frame relay service to the
Channel Manager, the Retransmission and Flow Control block and those application
data streams that do not require Retransmission and Flow Control services. It is
responsible for coordinating the transmission and reception of packets related to
multiple L2CAP channels over the facilities offered at the lower layer interface.

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 3, Part A Page 1081
Logical Link Control and Adaptation Protocol Specification

data
data
Upper data control
layer

(SDUs)

Segmentation (Reassembly )
Resource
Manager

Channel
Retransmission & Flow Control
L2CAP Manager
(commands)
layer Encapsulation & Scheduling

(PDUs)
Fragmentation (Recombination)
(f ragments)

Lower Fragmentation (Recombination)

layer Controls
(HCI) Data/packet f low

Figure 1.1: L2CAP architectural blocks

• Protocol/channel multiplexing
L2CAP supports multiplexing over individual Controllers. An L2CAP channel shall
operate over one Controller. An L2CAP channel cannot move between Controllers.
During channel setup, protocol multiplexing capability is used to route the connection
to the correct upper layer protocol.
For data transfer, logical channel multiplexing is needed to distinguish between
multiple upper layer entities. There may be more than one upper layer entity using
the same protocol.
• Segmentation and reassembly
With the frame relay service offered by the Resource Manager, the length of
transport frames is controlled by the individual applications running over L2CAP.
Many multiplexed applications are better served if L2CAP has control over the PDU
length. This provides the following benefits:
a. Segmentation will allow the interleaving of application data units in order to
satisfy latency requirements.
b. Memory and buffer management is easier when L2CAP controls the packet size.
c. Error correction by retransmission can be made more efficient.

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 3, Part A Page 1082
Logical Link Control and Adaptation Protocol Specification

d. The amount of data that is destroyed when an L2CAP PDU is corrupted or lost
can be made smaller than the application's data unit.
e. The application is decoupled from the segmentation required to map the
application packets into the lower layer packets.
• Flow control per L2CAP channel
Controllers provide error and flow control for data going over the air and HCI flow
control exists for data going over an HCI transport. When several data streams run
over the same Controller using separate L2CAP channels, each channel requires
individual flow control. A window based flow control scheme is provided.
• Error control and retransmissions
Some applications require a residual error rate much smaller than some Controllers
can deliver. L2CAP provides error checks and retransmissions of L2CAP PDUs. The
error checking in L2CAP protects against errors due to Controllers falsely accepting
packets that contain errors but pass Controller-based integrity checks. L2CAP error
checking and retransmission also protect against loss of packets due to flushing
by the Controller. The error control works in conjunction with flow control in the
sense that the flow control mechanism will throttle retransmissions as well as first
transmissions.
• Support for Streaming
Streaming applications such as audio set up an L2CAP channel with an agreed-upon
data rate and do not want flow control mechanisms, including those in the Controller,
to alter the flow of data. A flush timeout is used to keep data flowing on the transmit
side. Streaming mode is used to stop HCI and Controller based flow control from
being applied on the receiving side.
• Fragmentation and Recombination
Some Controllers may have limited transmission capabilities and may require
fragment sizes different from those created by L2CAP segmentation. Therefore layers
below L2CAP may further fragment and recombine L2CAP PDUs to create fragments
which fit each layer’s capabilities. During transmission of an L2CAP PDU, many
different levels of fragmentation and recombination may occur in both peer devices.
The HCI driver or Controller may fragment L2CAP PDUs to honor packet size
constraints of a Host Controller Interface transport scheme. This results in HCI ACL
Data packet payloads carrying start and continuation fragments of the L2CAP PDU.
Similarly the Controller may fragment L2CAP PDUs to map them into Controller
packets. This may result in Controller packet payloads carrying start and continuation
fragments of the L2CAP PDU.
Each layer of the protocol stack may pass on different sized fragments of L2CAP
PDUs, and the size of fragments created by a layer may be different in each peer

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 3, Part A Page 1083
Logical Link Control and Adaptation Protocol Specification

device. However the PDU is fragmented within the stack, the receiving L2CAP entity
still recombines the fragments to obtain the original L2CAP PDU.
• Quality of Service
The L2CAP connection establishment process allows the exchange of information
regarding the quality of service (QoS) expected between two Bluetooth devices. Each
L2CAP implementation monitors the resources used by the protocol and ensures that
QoS contracts are honored.
For a BR/EDR or BR/EDR/LE Controller, L2CAP may support both isochronous
(Guaranteed) and asynchronous (Best Effort) data flows over the same ACL logical
link by marking packets as automatically-flushable or non-automatically-flushable by
setting the appropriate value for the Packet_Boundary_Flag in the HCI ACL Data
packet (see [Vol 4] Part E, Section 5.4.2). Automatically-flushable L2CAP packets
are flushed according to the automatic flush timeout set for the ACL logical link
on which the L2CAP channels are mapped (see [Vol 4] Part E, Section 6.19).
Non-automatically-flushable L2CAP packets are not affected by the automatic flush
timeout and will not be flushed. All L2CAP packets can be flushed by using the
HCI_Flush command (see [Vol 4] Part E, Section 7.3.4).

Note: The terms "Guaranteed" and "Best Effort" are used as a shorthand to
indicate that the implementation will or will not attempt to provide some level of
quality of service. They do not make any statement as to what actual quality is
provided; in particular, "Guaranteed" does not mean that successful delivery of data
is guaranteed. Similarly, a "guarantee" is a set of resources (such as bandwidth and
buffer space) allocated to a "Guaranteed" connection and does not mean that a
specific data rate and latency will be provided under all possible circumstances.

1.2 Assumptions
The protocol is designed based on the following assumptions:

1. Controllers provide orderly delivery of data packets, although there might be

individual packet corruption and duplicates. For devices with a BR/EDR or
BR/EDR/LE Controller, no more than one ACL-U logical link exists between any
two devices. For devices with a BR/EDR/LE or LE Controller, no more than one
LE-U logical link exists between any two devices.
2. Controllers always provide the impression of full-duplex communication channels.
This does not imply that all L2CAP communications are bi-directional.
Unidirectional traffic does not require duplex channels.
3. The L2CAP layer provides a channel with a degree of reliability based on the
mechanisms available in Controllers and with additional packet segmentation,
error detection, and retransmission that can be enabled in the enhanced L2CAP
layer. Some Controllers perform data integrity checks and resend data until it has

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 3, Part A Page 1084
Logical Link Control and Adaptation Protocol Specification

been successfully acknowledged or a timeout occurs. Other Controllers will resend

data up to a certain number of times whereupon the data is flushed. Because
acknowledgments may be lost, timeouts may occur even after the data has been
successfully sent.

Note: The use of Baseband Broadcast packets in a BR/EDR or BR/EDR/LE

Controller is unreliable and all broadcasts start the first segment of an L2CAP
packet with the same sequence bit.
4. Controllers provide error and flow control for data going over the air and HCI flow
control exists for data going over an HCI transport but some applications will want
better error control than some Controllers provide. The Flow and Error Control
block provides four modes. Enhanced Retransmission mode and Retransmission
mode offer segmentation, flow control and L2CAP PDU retransmissions. Flow
control mode offers just the segmentation and flow control functions. Streaming
mode offers segmentation and receiver side packet flushing.

1.3 Scope
The following features are outside the scope of L2CAP’s responsibilities:

• L2CAP does not transport synchronous data designated for SCO or eSCO logical
transports.
• L2CAP does not support a reliable broadcast channel. See Section 3.2.

1.4 Terminology
The following formal definitions apply:

Term Description
Upper layer The system layer above the L2CAP layer, which exchanges data with L2CAP in
the form of SDUs. The upper layer may be represented by an application or higher
protocol entity known as the Service Level Protocol. The interface of the L2CAP layer
with the upper layer is not specified.
Lower layer The system layer below the L2CAP layer, which exchanges data with the L2CAP lay-
er in the form of PDUs, or fragments of PDUs. The lower layer is mainly represented
within the Controller, however a Host Controller interface (HCI) may be involved, such
that an HCI Host driver could also be seen as the lower layer. Except for the HCI
functional specification (in case HCI is involved) the interface between L2CAP and the
lower layer is not specified.
L2CAP chan- The logical connection between two endpoints in peer devices, characterized by their
nel Channel Identifiers (CID), which is multiplexed over one Controller based logical link.

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 3, Part A Page 1085
Logical Link Control and Adaptation Protocol Specification

Term Description
SDU, or Service Data Unit: a packet of data that L2CAP exchanges with the upper layer and
L2CAP SDU transports transparently over an L2CAP channel using the procedures specified here.
The term SDU is associated with data originating from upper layer entities only, i.e.
does not include any protocol information generated by L2CAP procedures.
Segment, or A part of an SDU, as resulting from the Segmentation procedure. An SDU may be
SDU segment split into one or more segments.
Note: This term is relevant only to Enhanced Retransmission mode, Streaming mode,
Retransmission mode, Flow Control mode, LE Credit Based Flow Control mode, and
Enhanced Credit Based Flow Control mode, not to the Basic L2CAP mode.
Segmentation A procedure used in the L2CAP Retransmission and Flow Control modes, resulting in
an SDU being split into one or more smaller units, called Segments, as appropriate
for the transport over an L2CAP channel.
Note: This term is relevant only to the Enhanced Retransmission mode, Streaming
mode, Retransmission mode, Flow Control mode, LE Credit Based Flow Control
mode, and Enhanced Credit Based Flow Control mode, not to the Basic L2CAP
mode.
Reassembly The reverse procedure corresponding to Segmentation, resulting in an SDU being
re-established from the segments received over an L2CAP channel, for use by the
upper layer. The interface between the L2CAP and the upper layer is not specified;
therefore, reassembly may actually occur within an upper layer entity although it is
conceptually part of the L2CAP layer.
Note: This term is relevant only to Enhanced Retransmission mode, Streaming mode,
Retransmission mode, Flow Control mode, LE Credit Based Flow Control mode, and
Enhanced Credit Based Flow Control mode, not to the Basic L2CAP mode.
PDU, or Protocol Data Unit: a packet of data containing L2CAP protocol information fields,
L2CAP PDU control information, and/or upper layer information data. A PDU is always started by
a Basic L2CAP header. Types of PDUs are: B-frames, I-frames, S-frames, C-frames,
G-frames, and K-frames.
Basic L2CAP Minimum L2CAP protocol information that is present in the beginning of each PDU: a
header PDU length field and a field containing the Channel Identifier (CID).
Basic infor- A B-frame is a PDU used in the Basic L2CAP mode for L2CAP data packets. It
mation frame contains a complete SDU as its payload, encapsulated by a Basic L2CAP header.
(B‑frame)
Information An I-frame is a PDU used in Enhanced Retransmission mode, Streaming mode,
frame Retransmission mode, and Flow Control mode. It contains an SDU segment and
(I‑frame) additional protocol information, encapsulated by a Basic L2CAP header.
Supervisory An S-frame is a PDU used in Enhanced Retransmission mode, Retransmission mode,
frame and Flow Control mode. It contains protocol information only, encapsulated by a Basic
(S‑frame) L2CAP header, and no SDU data.
Control frame A C-frame is a PDU that contains L2CAP signaling messages exchanged between
(C‑frame) the peer L2CAP entities. C-frames are exclusively used on the L2CAP signaling
channels.

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 3, Part A Page 1086
Logical Link Control and Adaptation Protocol Specification

Term Description
Group frame A G-frame is a PDU exclusively used on the Connectionless L2CAP channel. It
(G‑frame) is encapsulated by a Basic L2CAP header and contains the PSM followed by the
completed SDU. G-frames may be used to broadcast data to active Peripherals via
Active Peripheral Broadcast or to send unicast data to a single remote device.
Credit-based A K-frame is a PDU used in LE Credit Based Flow Control mode and Enhanced
frame Credit Based Flow Control mode. It contains an SDU segment and additional protocol
(K‑frame) information, encapsulated by a Basic L2CAP header.
Fragment A part of a PDU, as resulting from a fragmentation operation. Fragments are used
only in the delivery of data to and from the lower layer. They are not used for peer-to-
peer transportation. A fragment may be a Start or Continuation Fragment with respect
to the L2CAP PDU. A fragment does not contain any protocol information beyond the
PDU; the distinction of start and continuation fragments is transported by lower layer
protocol provisions.
Note: Start Fragments always either begin with the first octet of the Basic L2CAP
header of a PDU or they have a length of zero (see [Vol 2] Part B, Section 6.6.2).
Fragmenta- A procedure used to split L2CAP PDUs to smaller parts, named fragments, appropri-
tion ate for delivery to the lower layer transport. Although described within the L2CAP
layer, fragmentation may actually occur in an HCI Host driver, and/or in a Controller,
to accommodate the L2CAP PDU transport to HCI ACL Data packet or Controller
packet sizes.
Fragmentation of PDUs may be applied in all L2CAP modes.
Recombina- The reverse procedure corresponding to fragmentation, resulting in an L2CAP PDU
tion re-established from fragments. In the receive path, full or partial recombination opera-
tions may occur in the Controller and/or the Host, and the location of recombination
does not necessarily correspond to where fragmentations occurs on the transmit side.
Maximum The maximum size of an SDU, in octets, that the upper layer entity is capable of
Transmission accepting.
Unit (MTU)
Payload Size The amount of SDU data in a single PDU, in octets; equivalently, the number of octets
in the Information Payload field of a PDU.
Maximum The maximum payload size in octets that the L2CAP layer entity is capable of accept-
PDU payload ing.
Size (MPS) In the absence of segmentation, or in the Basic L2CAP mode, the Maximum Trans-
mission Unit is the same as the Maximum PDU payload Size and the two configura-
tion parameters shall be set to the same value.
Signaling The maximum size of command information that the L2CAP layer entity is capable of
MTU (MTUsig) accepting. The MTUsig, refers to the signaling channel only and corresponds to the
maximum size of a C-frame, excluding the Basic L2CAP header. The MTUsig value of
a peer is discovered when a C-frame that is too large is rejected by the peer.

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 3, Part A Page 1087
Logical Link Control and Adaptation Protocol Specification

Term Description
Connection- The maximum size of the connection packet information that the L2CAP layer entity is
less MTU capable of accepting. The MTUcnl refers to the connectionless channel only and cor-
(MTUcnl) responds to the maximum G-frame, excluding the Basic L2CAP header and the PSM
which immediately follows it. The MTUcnl of a peer can be discovered by sending an
L2CAP_INFORMATION_REQ packet.
MaxTransmit In Enhanced Retransmission mode and Retransmission mode, MaxTransmit controls
the number of transmissions of a PDU that L2CAP is allowed to try before assuming
that the PDU (and the link) is lost. The minimum value is 1 (only 1 transmission per-
mitted). In Enhanced Retransmission mode a value 0 means infinite transmissions.
Note: Setting MaxTransmit to 1 prohibits PDU retransmissions. Failure of a single
PDU will cause the link to drop. By comparison, in Flow Control mode, failure of a
single PDU will not necessarily cause the link to drop.

Table 1.1: Terminology

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 3, Part A Page 1088
Logical Link Control and Adaptation Protocol Specification

2 GENERAL OPERATION

L2CAP is based around the concept of ’channels’. Each one of the endpoints of an
L2CAP channel is referred to by a channel identifier (CID).

2.1 Channel identifiers

A channel identifier (CID) is the local name representing a logical channel endpoint on
the device. The scope of CIDs is related to the logical link as shown in Figure 2.1.
The null identifier (0x0000) shall not be used as a destination endpoint. Identifiers
from 0x0001 to 0x003F are reserved for specific L2CAP functions. These channels
are referred to as fixed channels. An implementation of L2CAP shall support the fixed
channel 0x0001 (see Table 2.1) on all ACL‑U logical links and the fixed channels
0x0004, 0x0005, and 0x0006 (see Table 2.3) on all LE‑U logical links. Other fixed
channels may be supported on each logical link. The L2CAP_INFORMATION_REQ /
L2CAP_INFORMATION_RSP mechanism (described in Section 4.10 and Section 4.11)
shall be used to determine which fixed channels a remote device supports over the
ACL-U logical link. Each fixed channel has the same CID at each end of the logical link
carrying the channel.

The characteristics of each fixed channel are defined on a per channel basis. Fixed
channel characteristics include configuration parameters (e.g., reliability, MTU size,
QoS), security, and the ability to change parameters using the L2CAP configuration
mechanism. Table 2.1 lists the defined fixed channels, provides a reference to where
the associated channel characteristics are defined and specifies the logical link over
which the channel may operate. Fixed channels are available as soon as the ACL-U or
LE-U logical link is set up. All initialization that is normally performed when a channel is
created shall be performed for each of the supported fixed channels when the ACL-U or
LE-U logical link is set up. Fixed channels shall only run over ACL-U, APB-U, or LE-U
logical links.

Implementations are free to manage the remaining CIDs in a manner best suited for
that particular implementation, with the provision that two simultaneously active L2CAP
channels on the same logical link (i.e., to the same peer device using the same
transport) shall not share the same CID. A different CID name space exists for each
ACL-U, APB-U, and LE-U logical link. Table 2.1 to Table 2.3 summarize the definition
and partitioning of the CID name space for each type of logical link.

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 3, Part A Page 1089
Logical Link Control and Adaptation Protocol Specification

CID CID Local

N N
device

L2CAP L2CAP
multiplexer multiplexer

Remote Remote Remote

address A address B device

Address may be
equal

CID name space

Figure 2.1: Dynamically allocated CID assignments

Assignment of dynamically allocated CIDs is relative to a particular logical link and a

device can assign CIDs independently from other devices. Thus, even if the same CID
value has been assigned to (remote) channel endpoints by several remote devices
connected to a single local device, the local device can still uniquely associate each
remote CID with a different device. Further, even if the same CID value has been
assigned to (remote) channel endpoints by the same remote device, these can be
distinguished because they will be bound to a different logical link.

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 3, Part A Page 1090
Logical Link Control and Adaptation Protocol Specification

The CID name space for ACL-U logical links is as follows:

CID Description Channel Characteristics

0x0000 Null identifier Not allowed
0x0001 L2CAP Signaling chan- See Section 4
nel
0x0002 Connectionless chan- See Section 7.6
nel
0x0003 Previously used Not applicable
0x0007 BR/EDR Security Man- See [Vol 3] Part H
ager
0x003F Previously used Not applicable
0x0040 to Dynamically allocated Communicated using L2CAP configuration mechanism
0xFFFF (see Section 7.1) or the L2CAP credit based create
connection mechanism (see Section 4.25)
All other values Reserved for future use Not applicable

Table 2.1: CID name space on ACL-U logical links

The CID name space for APB-U logical links is as follows:

CID Description Channel Characteristics

0x0000 Null identifier Not allowed
0x0002 Connectionless chan- See Section 7.6
nel
All other values Reserved for future use Not applicable

Table 2.2: CID name space on APB-U logical links

The CID name space for LE-U logical links is as follows:

CID Description Channel Characteristics

0x0000 Null identifier Not Allowed
0x0004 Attribute Protocol See [Vol 3] Part F
0x0005 L2CAP LE Signaling See Section 4
channel
0x0006 Security Manager pro- See [Vol 3] Part H
tocol
0x0020 to 0x003E Assigned Numbers

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 3, Part A Page 1091
Logical Link Control and Adaptation Protocol Specification

CID Description Channel Characteristics

0x0040 to 0x007F Dynamically allocated Communicated using the L2CAP LE credit based cre-
ate connection mechanism (see Section 4.22) or the
L2CAP credit based create connection mechanism
(see Section 4.25)
All other values Reserved for future use Not applicable

Table 2.3: CID name space on LE-U logical links

2.2 Operation between devices

Figure 2.2 illustrates the use of CIDs in a communication between corresponding peer
L2CAP entities in separate devices. The connection-oriented data channels represent
a connection between two devices, where a CID, combined with the logical link,
identifies each endpoint of the channel. When used for broadcast transmissions, the
connectionless channel restricts data flow to a single direction. The connectionless
channel may be used to transmit data to all active Peripherals, using Active Peripheral
Broadcast. When used for unicast transmissions the connectionless channel may be
used in either direction between a Central and a Peripheral.

There are also a number of CIDs reserved for special purposes. The L2CAP signaling
channels are examples of reserved channels. Fixed channel 0x0001 is used to create
and establish connection-oriented data channels and to negotiate changes in the
characteristics of connection-oriented channels and to discover characteristics of the
connectionless channel operating over the ACL-U logical link.

The L2CAP Signaling channel (0x0001) and all supported fixed channels are available
immediately when the ACL-U logical link is established between two devices. Another
CID (0x0002) is reserved for all incoming and outgoing connectionless data traffic,
whether broadcast or unicast. Connectionless data traffic may flow immediately once
the ACL-U logical link is established between two devices and once the transmitting
device has determined that the remote device supports connectionless traffic.

The L2CAP LE Signaling channel (0x0005) and all supported fixed channels are
available immediately when the LE-U logical link is established between two devices.

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 3, Part A Page 1092
Logical Link Control and Adaptation Protocol Specification

Connection-oriented Connectionless Signaling

and Unicast Traffic on data channel channel
Connectionless Channel

CID

CID

CID

CID
L2CAP L2CAP L2CAP
Entity Entity Entity
CID

CID
CID
Device #1 CID CID
Device #2

CID CID

L2CAP L2CAP
Entity Entity

Device #3 Device #4

Figure 2.2: Channels between devices

Table 2.4 describes the various channel types and their source and destination
identifiers. A dynamically allocated CID is allocated to identify, along with the logical
link, the local endpoint and shall be in the range 0x0040 to 0xFFFF for ACL-U,
0x0040 to 0x007F for LE-U. Section 6 describes the state machine associated with
each connection-oriented channel with a dynamically allocated CID. Section 3.1 and
Section 3.3 describe the packet format associated with connection-oriented channels.
Section 3.2 describes the packet format associated with the connectionless channel.

Channel Type Local CID (sending) Remote CID (receiving)

Connection-oriented Dynamically allocated and fixed Dynamically allocated and fixed
Connectionless data 0x0002 (fixed) 0x0002 (fixed)
L2CAP Signaling 0x0001 and 0x0005 (fixed) 0x0001 and 0x0005 (fixed)
Table 2.4: Types of channel identifiers

2.3 Operation between layers

L2CAP implementations should follow the general architecture described below. L2CAP
implementations transfer data between upper layer protocols and the lower layer
protocol. This document lists a number of services that should be exported by any
L2CAP implementation. Each implementation shall also support a set of signaling
commands for use between L2CAP implementations. L2CAP implementations should

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 3, Part A Page 1093
Logical Link Control and Adaptation Protocol Specification

also be prepared to accept certain types of events from lower layers and generate
events to upper layers. How these events are passed between layers is implementation
specific.

Upper Layer

Request Confirm Response Indication

L2CAP Layer

Request Confirm Response Indication

Lower Layer

Figure 2.3: L2CAP transaction model

2.4 Modes of operation

L2CAP channels may operate in one of several different modes as selected for each
L2CAP channel.

The modes are:

• Basic L2CAP mode (BR/EDR and some LE fixed channels only)

• Flow Control mode (BR/EDR only)
• Retransmission mode (BR/EDR only)
• Enhanced Retransmission mode (BR/EDR only)
• Streaming mode (BR/EDR only)
• LE Credit Based Flow Control mode (LE only)
• Enhanced Credit Based Flow Control mode (BR/EDR and LE)

The modes are enabled using the configuration procedure described in Section 7.1.
The Basic L2CAP mode shall be the default mode, which is used when no other
mode is agreed. Enhanced Retransmission mode shall be used for ACL-U logical
links operating as described in Section 7.10. Enhanced Retransmission mode should

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 3, Part A Page 1094
Logical Link Control and Adaptation Protocol Specification

be enabled for reliable channels created over ACL-U logical links not operating as
described in Section 7.10. Streaming mode shall be used for ACL-U logical links
operating as described in Section 7.10. Streaming mode should be enabled for
streaming applications created over ACL-U logical links not operating as described in
Section 7.10. Enhanced Retransmission mode, Enhanced Credit Based Flow Control
mode, or Streaming mode should be enabled when supported by both L2CAP
entities. Flow Control mode and Retransmission mode shall only be enabled when
communicating with L2CAP entities that do not support Enhanced Retransmission
mode, Enhanced Credit Based Flow Control mode, or Streaming mode.

In Flow Control mode, Retransmission mode, and Enhanced Retransmission mode,

PDUs exchanged with a peer entity are numbered and acknowledged. The sequence
numbers in the PDUs are used to control buffering, and a TxWindow size is used to limit
the required buffer space and/or provide a method for flow control.

In Flow Control mode no retransmissions take place, but missing PDUs are detected
and can be reported as lost.

In Retransmission mode a timer is used to ensure that all PDUs are delivered to the
peer, by retransmitting PDUs as needed. A go-back-n repeat mechanism is used to
simplify the protocol and limit the buffering requirements.

Enhanced Retransmission mode is similar to Retransmission mode. It adds the ability

to set a POLL bit to solicit a response from a remote L2CAP entity, adds the SREJ
S-frame to improve the efficiency of error recovery and adds an RNR S-frame to replace
the R-bit for reporting a local busy condition.

Streaming mode is for real-time isochronous traffic. PDUs are numbered but are not
acknowledged. A finite flush timeout is set on the sending side to flush packets that are
not sent in a timely manner. On the receiving side if the receive buffers are full when
a new PDU is received then a previously received PDU is overwritten by the newly
received PDU. Missing PDUs can be detected and reported as lost. TxWindow size is
not used in Streaming mode.

LE Credit Based Flow Control mode is used for LE L2CAP connection-oriented

channels for flow control using a credit based scheme for L2CAP data (i.e. not signaling
packets).

Enhanced Credit Based Flow Control mode is used for L2CAP connection-oriented
channels on both LE and BR/EDR for flow control using a credit-based scheme
for L2CAP data (i.e. not signaling packets). A BR/EDR/LE device that implements
Enhanced Credit Based Flow Control mode may support it on BR/EDR only, on LE only,
or on both.

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 3, Part A Page 1095
Logical Link Control and Adaptation Protocol Specification

Enhanced Retransmission mode should be used instead of Enhanced Credit Based

Flow Control mode for data being transmitted over BR/EDR.

Care should be taken in selecting the parameters used for Enhanced Retransmission
mode and Streaming mode when they are used beneath legacy profile implementations
to ensure that performance is not negatively impacted relative to the performance
achieved when using the same profile with Basic mode on an ACL-U logical link. It
may be preferable to configure Basic mode to minimize the risk of negative performance
impacts.

2.5 Mapping channels to logical links

L2CAP maps channels to Controller logical links, which in turn run over Controller
physical links. All logical links going between a local Controller and remote Controller
run over a single physical link. There is one ACL-U logical link per BR/EDR physical link
and one LE-U logical link per LE physical link.

All Best Effort and Guaranteed channels going over a BR/EDR physical link between
two devices shall be mapped to a single ACL-U logical link. All channels going over an
LE physical link between two devices shall be treated as best effort and mapped to a
single LE-U logical link.

When a Guaranteed channel is created, a corresponding Guaranteed logical link shall

be created to carry the channel traffic. Creation of a Guaranteed logical link involves
admission control. Admission control is verifying that the guarantee can be achieved
without compromising existing guarantees. For a BR/EDR Controller, admission control
(creation of a Guaranteed logical link) shall be performed by the L2CAP layer.

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 3, Part A Page 1096
Logical Link Control and Adaptation Protocol Specification

3 DATA PACKET FORMAT

L2CAP is packet-based but follows a communication model based on channels. A

channel represents a data flow between L2CAP entities in remote devices. Channels
may be connection-oriented or connectionless. All channels other than the L2CAP
connectionless channel (CID 0x0002) and the two L2CAP signaling channels (CIDs
0x0001 and 0x0005) are connection-oriented. All L2CAP layer packet fields shall
use little-endian byte order with the exception of the information payload field. The
endianness of higher layer protocols encapsulated within L2CAP information payload is
protocol-specific.

If a PDU is received on a CID that is not assigned or is reserved for future use on the
logical link type, the recipient shall ignore that PDU.

In all L2CAP PDUs, the PDU Length field indicates the size of the entire L2CAP PDU in
octets, excluding the 4 octets of the Basic L2CAP header. Therefore a PDU cannot be
more than 65539 octets long.

In PDUs that contain an Information Payload field, the number of octets in that field (the
payload size) shall not be greater than the peer device's MPS for the channel.

3.1 Connection-oriented channels in Basic L2CAP mode

Figure 3.1 illustrates the format of the L2CAP PDU used on connection-oriented
channels. In basic L2CAP mode, the L2CAP PDU on a connection-oriented channel
is also referred to as a "B-frame".

Basic L2CAP
header
PDU Channel
Length ID Information payload

LSB 16 16 MSB

Basic information frame (B-frame)

Figure 3.1: L2CAP PDU format in Basic L2CAP mode on connection-oriented channels (field sizes in bits)

The fields shown are:

• PDU Length: 2 octets (16 bits)

For B-frames, the PDU Length equals the payload size and can be up to 65535
octets. The PDU Length field is used for recombination and serves as a simple
integrity check of the recombined L2CAP packet on the receiving end.

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 3, Part A Page 1097
Logical Link Control and Adaptation Protocol Specification

• Channel ID: 2 octets

The channel ID (CID) identifies the destination channel endpoint of the packet.
• Information payload: 0 to 65535 octets
This contains the payload received from the upper layer protocol (outgoing packet),
or delivered to the upper layer protocol (incoming packet). The payload size shall
not be greater than the peer device's MTU for the channel. The MTU for channels
with dynamically allocated CIDs is determined during channel configuration (see
Section 5.1). The minimum supported MTU values for the signaling PDUs are shown
in Table 4.1.

3.2 Connectionless data channel in Basic L2CAP mode

Figure 3.2 illustrates the L2CAP PDU format within a connectionless data channel.
Here, the L2CAP PDU is also referred to as a "G-frame".

Basic L2CAP
header

PDU
0x0002 PSM Information payload
Length
LSB 16 16 ≥16 MSB
Group frame (G-frame)

Figure 3.2: L2CAP PDU format on the connectionless channel

The fields shown are:

• PDU Length: 2 octets

For G-frames, the PDU Length equals the payload size plus the number of octets in
the PSM.
• Channel ID: 2 octets
Channel ID (0x0002) reserved for connectionless traffic.
• Protocol/Service Multiplexer (PSM): 2 octets (minimum)
For information on the PSM field see Section 4.2.
• Information payload: 0 to 65533 octets
This parameter contains the payload information to be distributed to all Peripherals
in the piconet for broadcast connectionless traffic, or to a specific remote device
for data sent via the L2CAP connectionless channel. The payload size shall not be
greater than the peer device's MTU for the channel. Implementations shall support
a connectionless MTU (MTUcnl) of 48 octets on the connectionless channel. Devices
may also explicitly change to a larger or smaller connectionless MTU (MTUcnl).

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 3, Part A Page 1098
Logical Link Control and Adaptation Protocol Specification

Note: The maximum size of the Information payload field decreases accordingly if the
PSM field is extended beyond the two octet minimum.

3.3 Connection-oriented channel in Retransmission/Flow Control/

Streaming modes
To support flow control, retransmissions, and streaming, L2CAP PDU types with
protocol elements in addition to the Basic L2CAP header are defined. The information
frames (I-frames) are used for information transfer between L2CAP entities. The
supervisory frames (S-frames) are used to acknowledge I-frames and request
retransmission of I-frames. Figure 3.3 illustrates these frames.

Basic L2CAP
header

PDU Channel
Control3 FCS1
Length ID

LSB 16 16 16 or 32 0 or 16
MSB
Supervisory frame (S-frame)

Basic L2CAP
header

L2CAP
PDU Channel
Control3 SDU, Information Payload FCS1
Length ID
Length2
LSB 16 16 16 or 32 0 or 16 0 or 16
MSB
Information frame (I-frame)

1
FCS is optional
2
Only present in the “Start of L2CAP SDU” frame, SAR=0b01
3
Standard and Enhanced Control is 16 bits, Extended Control is 32 bits

Figure 3.3: L2CAP PDU formats in Flow Control and Retransmission modes

3.3.1 L2CAP header fields

• PDU Length: 2 octets

For I-frames and S-frames, the PDU Length equals the sum of the octet lengths of the
Control, L2CAP SDU Length (when present), Information Payload, and frame check
sequence (FCS) (when present) fields. The PDU Length field of an S-frame therefore
equals 2, 4, or 6.

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 3, Part A Page 1099
Logical Link Control and Adaptation Protocol Specification

The maximum number of Information octets (the payload size) in one I-frame is based
on which fields are present and the type of the Control Field. The maximum number
of Information octets in an I-frame with a Standard Control field is as follows:
L2CAP SDU Length present and FCS present 65529 octets
L2CAP SDU Length present and FCS not present 65531 octets
L2CAP SDU Length not present and FCS present 65531 octets
L2CAP SDU Length not present and FCS not present 65533 octets

The maximum number of Information octets in an I-frame with an Extended Control

field is as follows:
L2CAP SDU Length present and FCS present 65527 octets
L2CAP SDU Length present and FCS not present 65529 octets
L2CAP SDU Length not present and FCS present 65529 octets
L2CAP SDU Length not present and FCS not present 65531 octets
• Channel ID: 2 octets
This field contains the Channel Identification (CID).

3.3.2 Control field

The Control Field identifies whether the frame is an S-frame or I-frame and contains
various information about the frame. There are three different Control Field formats:
the Standard Control Field, the Enhanced Control Field, and the Extended Control
Field. Which format is used is determined by the mode and is not indicated within the
frame. The Standard Control Field shall be used for Retransmission mode and Flow
Control mode. The Enhanced and Extended Control Fields shall be used for Enhanced
Retransmission mode and Streaming mode. The Enhanced Control Fields shall be used
until the first successful use of the Extended Window Size option (see Section 5.7) and
Extended Control Fields thereafter. The Control Field will contain sequence numbers
where applicable. Its coding is shown in Figure 3.4 to Figure 3.9. There are two different
frame types, Information frame types and Supervisory frame types. Information and
Supervisory frames types are distinguished by the least significant bit in the Control
Field.

• Information frame format (I-frame)

The I-frames are used to transfer information between L2CAP entities. Each I-frame
has a TxSeq(Send sequence number), ReqSeq(Receive sequence number) which
can acknowledge additional I-frames received by the data Link Layer entity. Each
I-frame with a Standard Control field has a retransmission bit (R bit) that affects
whether I-frames are retransmitted. Each I-frame with an Enhanced Control Field or
an Extended Control Field has an F-bit that is used in Poll/Final bit functions.

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 3, Part A Page 1100
Logical Link Control and Adaptation Protocol Specification

The SAR field in the I-frame is used for segmentation and reassembly control. The
L2CAP SDU Length field specifies the length of an SDU, including the aggregate
length across all segments if segmented.
• Supervisory frame format (S-frame)
S-frames are used to acknowledge I-frames and request retransmission of I-frames.
Each S-frame has an ReqSeq sequence number which may acknowledge additional
I-frames received by the data Link Layer entity. Each S-frame with a Standard Control
Field has a retransmission bit (R bit) that affects whether I-frames are retransmitted.
Each S-frame with an Enhanced Control field or an Extended Control Field has a Poll
bit (P-bit) and a Final bit (F-bit) and does not have an R-bit.
Defined types of S-frames are RR (Receiver Ready), REJ (Reject), RNR (Receiver
Not Ready) and SREJ (Selective Reject).

Figure 3.4: I-frame Standard Control Field format

Figure 3.5: I-frame Enhanced Control Field format

Figure 3.6: I-frame Extended Control Field format

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 3, Part A Page 1101
Logical Link Control and Adaptation Protocol Specification

Figure 3.7: S-frame Standard Control Field format

Figure 3.8: S-frame Enhanced Control Field format

Figure 3.9: S-frame Extended Control Field format

• Type
The type bit shall be 0 for an I-frame and 1 for an S-frame.
• Send Sequence Number - TxSeq
The send sequence number is used to number each I-frame, to enable sequencing
and retransmission.
• Receive Sequence Number - ReqSeq
The receive sequence number is used by the receiver side to acknowledge I-frames,
and in the REJ and SREJ frames to request the retransmission of an I-frame with a
specific send sequence number.
• Retransmission Disable Bit - R
The Retransmission Disable bit is used to implement Flow Control. The receiver
sets the bit when its internal receive buffer is full, this happens when one or more
I-frames have been received but the SDU reassembly function has not yet pulled
all the frames received. When the sender receives a frame with the Retransmission

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 3, Part A Page 1102
Logical Link Control and Adaptation Protocol Specification

Disable bit set it shall disable the RetransmissionTimer, this causes the sender to stop
retransmitting I-frames.
R=0: Normal operation. Sender uses the RetransmissionTimer to control
retransmission of I-frames. Sender does not use the MonitorTimer.
R=1: Receiver side requests sender to postpone retransmission of I-frames.
Sender monitors signaling with the MonitorTimer. Sender does not use the
RetransmissionTimer.
The functions of ReqSeq and R are independent.
• Segmentation and Reassembly - SAR
The SAR bits define whether an L2CAP SDU is segmented. For segmented SDUs,
the SAR bits also define which part of an SDU is in this I-frame, thus allowing one
L2CAP SDU to span several I-frames.
An I-frame with SAR=”Start of L2CAP SDU” also contains an L2CAP SDU Length
field, specifying the number of information octets in the total L2CAP SDU. The
encoding of the SAR bits is shown in Table 3.1.
0b00 Unsegmented L2CAP SDU
0b01 Start of L2CAP SDU
0b10 End of L2CAP SDU
0b11 Continuation of L2CAP SDU

Table 3.1: SAR control element format

• Supervisory function - S
The S-bits mark the type of S-frame. There are four types defined: RR (Receiver
Ready), REJ (Reject), RNR (Receiver Not Ready) and SREJ (Selective Reject). The
encoding is shown in Table 3.2.
0b00 RR - Receiver Ready
0b01 REJ - Reject
0b10 RNR - Receiver Not Ready
0b11 SREJ - Select Reject

Table 3.2: S control element format: type of S-frame

• Poll - P
The P-bit is set to 1 to solicit a response from the receiver. The receiver shall respond
immediately with a frame with the F-bit set to 1.
• Final - F
The F-bit is set to 1 in response to an S-frame with the P bit set to 1.

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 3, Part A Page 1103
Logical Link Control and Adaptation Protocol Specification

3.3.3 L2CAP SDU Length field (2 octets)

When an SDU spans more than one I-frame, the first I-frame in the sequence shall
be identified by SAR=0b01=”Start of L2CAP SDU”. The L2CAP SDU Length field shall
specify the total number of octets in the SDU and shall not be greater than the peer
device's MTU for the channel. The L2CAP SDU Length field shall be present in I-frames
with SAR=0b01 (Start of L2CAP SDU) and shall not be used in any other I-frames.
When the SDU is unsegmented (SAR=0b00), the L2CAP SDU Length field is not
needed and shall not be present.

3.3.4 Information Payload field

The information payload field consists of an integer number of octets. The maximum
number of octets in this field is the same as the negotiated value of the MPS
configuration parameter. The maximum number of octets in this field also depends on
which other fields are present (see Section 3.3.1). If SAR=0b00 (Unsegmented L2CAP
SDU) then the payload size shall not be greater than the peer device's MTU for the
channel.

3.3.5 Frame Check Sequence (2 octets)

The Frame Check Sequence (FCS) is 2 octets. This field is mandatory in

Retransmission and Flow Control modes. Whether it is present or absent in Enhanced
Retransmission and Streaming modes is configurable (see Section 5.5).

The FCS is constructed using the generator polynomial g(D) = D16 + D15 + D2 + 1 (see
Figure 3.10). The 16 bit LFSR is initially loaded with the value 0x0000, as depicted
in Figure 3.11. The switch S is set in position 1 while data is shifted in, LSB first for
each octet. After the last bit has entered the LFSR, the switch is set in position 2,
and the register contents are transmitted from right to left (i.e. starting with position 15,
then position 14, etc.). The FCS covers the Basic L2CAP header, Control, L2CAP SDU
Length, and Information Payload fields, if present, as shown in Figure 3.3.

2
D0 D2 D15 S D16
1
FCS out

Position 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
Data in (LSB first)

Figure 3.10: The LFSR circuit generating the FCS

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 3, Part A Page 1104
Logical Link Control and Adaptation Protocol Specification

Position 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
LFSR 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0

Figure 3.11: Initial state of the FCS generating circuit

Examples of FCS calculation, g(D) = D16 + D15 + D2 + 1:

1. I Frame

PDU Length = 14
Channel ID = 0x0040
Control = 0x0002 (SAR=0b00, ReqSeq=0b000000, R=0, TxSeq=0b000001)
Information Payload = 00 01 02 03 04 05 06 07 08 09 (10 octets, hexadecimal
notation)
==> FCS = 0x6138
==> Data to Send = 0E 00 40 00 02 00 00 01 02 03 04 05 06 07 08 09 38 61
(hexadecimal notation)
2. RR Frame

PDU Length = 4
Channel ID = 0x0040
Control = 0x0101 (ReqSeq=0b000001, R=0, S=0b00)
==> FCS = 0x14D4
==> Data to Send = 04 00 40 00 01 01 D4 14 (hexadecimal notation)

3.3.6 Invalid Frame Detection (Retransmission and Flow Control modes)

For Retransmission mode and Flow Control mode, a received PDU shall be regarded as
invalid if one of the following conditions occurs:

1. Contains an unknown CID.

2. Contains an FCS error.
3. I-frame with a payload size greater than the maximum PDU payload size (MPS).
4. I-frame that has fewer than 8 octets (i.e., PDU Length less than 4).
5. I-frame with SAR=0b01 (Start of L2CAP SDU) that has fewer than 10 octets (i.e.,
PDU Length less than 6).
6. I-frame with SAR bits that do not correspond to a normal sequence of either
unsegmented or start, continuation, end for the given CID.
7. S-frame where the PDU Length field is not equal to 4.

These error conditions may be used for error reporting.

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 3, Part A Page 1105
Logical Link Control and Adaptation Protocol Specification

3.3.7 Invalid Frame Detection algorithm

For Enhanced Retransmission mode and Streaming mode the following algorithm shall
be used for received PDUs. It may be used for Retransmission mode and Flow Control
mode:

1. Check the CID. If the PDU contains an unknown CID then it shall be ignored.
2. Check the FCS. If the PDU contains an FCS error then it shall be ignored. If the
channel is configured to use "No FCS" then the PDU is considered to have a good
FCS (no FCS error).
3. Check the following conditions. If one of the conditions occurs the channel shall be
closed or in the case of fixed channels the ACL shall be disconnected.
a. I-frame with a payload size greater than the maximum PDU payload size
(MPS).
b. I-frame that has fewer than the required number of octets. If the channel is
configured to use a Standard or Enhanced Control Field then the required
number of octets is 6 if "No FCS" is configured; otherwise, it is 8. If the channel
is configured to use the Extended Control Field then the required number of
octets is 8 if "No FCS" is configured; otherwise, it is 10.
c. S-frame where the PDU Length field is invalid. If the channel is configured to
use a Standard or Enhanced Control Field then the PDU Length field shall be
2 if "No FCS" is configured; otherwise, the PDU Length field shall be 4. If the
channel is configured to use the Extended Control Field then the PDU Length
field shall be 4 if "No FCS" is configured; otherwise, the PDU Length field shall
be 6.
4. Check the SAR bits. The SAR check is performed after the frame has been
successfully received in the correct sequence. The PDU is invalid if one of the
following conditions occurs:
a. I-frame with SAR=0b01 (Start of L2CAP SDU) that has fewer than the required
number of octets. If the channel is configured to use a Standard or Enhanced
Control field then the required number of octets is 8 if "No FCS" is configured;
otherwise, the required number of octets is 10. If the channel is configured to
use an Extended Control field then the required number of octets is 10 if "No
FCS" is configured; otherwise, the required number of octets is 12.
b. I-frame with SAR bits that do not correspond to a normal sequence of either
unsegmented or start, continuation, end for the given CID.
c. I-frame with SAR= 0b01 (Start of L2CAP SDU) where the value in the L2CAP
SDU Length field exceeds the configured MTU.
5. If the I-frame has been received in the correct sequence and is invalid as described
in 4 then the channel shall be closed or in the case of fixed channels the ACL

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 3, Part A Page 1106
Logical Link Control and Adaptation Protocol Specification

shall be disconnected. For Streaming mode and Flow Control mode if one or
more I-frames are missing from a sequence of I-frames using SAR bits of start,
continuation and end then received I-frames in the sequence may be ignored. For
Flow Control mode and Streaming mode I-frames received out of sequence with
SAR bits of unsegmented may be accepted.

If the algorithm is used for Retransmission mode or Flow control mode then it shall be
used instead of Invalid Frame detection described in Section 3.3.6.

These error conditions may be used for error reporting.

3.4 Connection-oriented channels in LE Credit Based Flow Control

mode and Enhanced Credit Based Flow Control mode

To support LE Credit Based Flow Control mode and Enhanced Credit Based Flow
Control mode, an L2CAP PDU type with protocol elements in addition to the Basic
L2CAP header is defined. In LE Credit Based Flow Control mode and Enhanced Credit
Based Flow Control mode, the L2CAP PDU on a connection-oriented channel is a
Credit-based frame (K-frame) as illustrated in Figure 3.12.

Basic L2CAP
header

L2CAP SDU
PDU Length Channel ID Information Payload
Length1
16 16 16
LSB MSB

Credit-based frame (K-frame)

1. Only present in first K-frame of the SDU

Figure 3.12: L2CAP PDU format in LE Credit Based Flow Control and Enhanced Credit Based Flow
Control modes

3.4.1 L2CAP Header fields

• PDU Length: 2 octets

For K-frames, the PDU Length field equals the payload size plus the octet length of
the L2CAP SDU Length (when present).
• Channel ID: 2 octets
The channel ID (CID) identifies the destination channel endpoint of the packet.

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 3, Part A Page 1107
Logical Link Control and Adaptation Protocol Specification

3.4.2 L2CAP SDU Length field (2 octets)

The first K-frame of the SDU shall contain the L2CAP SDU Length field that shall
specify the total number of octets in the SDU. The value shall not be greater than the
peer device's MTU for the channel. All subsequent K-frames that are part of the same
SDU shall not contain the L2CAP SDU Length field.

3.4.3 Information Payload field

The information payload field consists of an integer number of octets.

The number of octets contained in the first K-frame information payload of the SDU is
equal to the PDU Length minus 2 octets. All subsequent K-frames of the same SDU
contain the number of octets in the information payload equal to the PDU Length.

If the SDU length field value exceeds the receiver's MTU, the receiver shall disconnect
the channel. If the payload size of any K-frame exceeds the receiver's MPS, the
receiver shall disconnect the channel. If the sum of the payload sizes for the K-frames
exceeds the specified SDU length, the receiver shall disconnect the channel.

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 3, Part A Page 1108
Logical Link Control and Adaptation Protocol Specification

4 SIGNALING PACKET FORMATS

This section describes the signaling commands passed between two L2CAP entities on
peer devices. All signaling commands are sent over a signaling channel. The signaling
channel for managing channels over ACL-U logical links shall use CID 0x0001 and
the signaling channel for managing channels over LE-U logical links shall use CID
0x0005. Signaling channels are available as soon as the lower layer logical transport
is set up and L2CAP traffic is enabled. Figure 4.1 illustrates the general format of
L2CAP PDUs containing signaling commands (C-frames). Multiple commands may be
sent in a single C-frame over fixed channel CID 0x0001 while only one command
per C-frame shall be sent over fixed channel CID 0x0005. Commands take the form
of requests, responses, and indications. All L2CAP implementations shall support
the reception of C-frames with a payload size that does not exceed the signaling
MTU. The minimum supported payload size for the C-frame (MTUsig) is defined in
Table 4.1. L2CAP implementations should not use C-frames that exceed the MTUsig of
the peer device. If a device receives a C-frame that exceeds its MTUsig then it shall
send an L2CAP_COMMAND_REJECT_RSP packet containing the supported MTUsig.
Implementations shall be able to handle the reception of multiple commands in an
L2CAP packet sent over fixed channel CID 0x0001.

Note: The name of a signalling packet has a suffix indicating its type: _REQ for
requests, _RSP for responses, and _IND for indications.

A signaling packet that is not correctly formed is invalid behavior (see [Vol 1] Part E,
Section 2.7). Examples of signaling packets that are not correctly formed include:

• The packet is less than 4 octets long.

• The Data Length field is not correct for the type of packet, such as an
L2CAP_CONNECTION_REQ packet with a Data Length other than 4 or an
L2CAP_INFORMATION_RSP with InfoType = 0x0003, Result = 0x0000, and Data
Length not equal to 12.
• The PDU Length of the C-frame does not equal the sum of the sizes of the contained
packets.
• The Reason or Status field has an unknown value.
• A C-frame on fixed channel 0x0005 contains more than one signaling packet.

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 3, Part A Page 1109
Logical Link Control and Adaptation Protocol Specification

Logical Link Minimum Supported Payload Size for

the C-frame (MTUsig)
ACL-U not supporting Extended Flow Specification 48 octets
ACL-U supporting the Extended Flow Specification feature 672 octets
LE-U 23 octets

Table 4.1: Minimum signaling MTU

Basic L2CAP
header

PDU Length Channel ID Information payload

LSB 16 16 Control frame (C-frame) MSB

Channel ID = 0x0001 for ACL-U

Channel ID = 0x0005 for LE-U

Figure 4.1: L2CAP PDU format on a signaling channel

For C-frames, the PDU Length equals the payload size.

Figure 4.2 displays the general format of all signaling commands.

LSB octet 0 octet 1 octet 2 octet 3 MSB

Code Identifier Data Length

Data

Figure 4.2: Command format

The fields shown are:

• Code (1 octet)
The Code field is one octet long and identifies the type of command. When a packet
is received with a Code field that is unknown or disallowed on the signaling channel it
is received on, an L2CAP_COMMAND_REJECT_RSP packet (defined in Section 4.1)
is sent in response.
Table 4.2 lists the codes defined by this document. All codes are specified with the
most significant bit in the left-most position.

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 3, Part A Page 1110
Logical Link Control and Adaptation Protocol Specification

Code Description CIDs on which Code is

Allowed
0x01 L2CAP_COMMAND_REJECT_RSP 0x0001 and 0x0005
0x02 L2CAP_CONNECTION_REQ 0x0001
0x03 L2CAP_CONNECTION_RSP 0x0001
0x04 L2CAP_CONFIGURATION_REQ 0x0001
0x05 L2CAP_CONFIGURATION_RSP 0x0001
0x06 L2CAP_DISCONNECTION_REQ 0x0001 and 0x0005
0x07 L2CAP_DISCONNECTION_RSP 0x0001 and 0x0005
0x08 L2CAP_ECHO_REQ 0x0001
0x09 L2CAP_ECHO_RSP 0x0001
0x0A L2CAP_INFORMATION_REQ 0x0001
0x0B L2CAP_INFORMATION_RSP 0x0001
0x0C to 0x11 Previously used None
0x12 L2CAP_CONNECTION_PARAMETER_UPDATE_REQ 0x0005
0x13 L2CAP_CONNECTION_PARAMETER_UPDATE_RSP 0x0005
0x14 L2CAP_LE_CREDIT_BASED_CONNECTION_REQ 0x0005
0x15 L2CAP_LE_CREDIT_BASED_CONNECTION_RSP 0x0005
0x16 L2CAP_FLOW_CONTROL_CREDIT_IND 0x0001 and 0x0005
0x17 L2CAP_CREDIT_BASED_CONNECTION_REQ 0x0001 and 0x0005
0x18 L2CAP_CREDIT_BASED_CONNECTION_RSP 0x0001 and 0x0005
0x19 L2CAP_CREDIT_BASED_RECONFIGURE_REQ 0x0001 and 0x0005
0x1A L2CAP_CREDIT_BASED_RECONFIGURE_RSP 0x0001 and 0x0005
Other Reserved for future use Any

Table 4.2: Signaling command codes

• Identifier (1 octet)
The Identifier field is one octet long and matches responses with requests. The
requesting device sets this field and the responding device uses the same value in
its response. Within each signaling channel a different Identifier shall be used for
each successive command. Following the original transmission of an Identifier in a
command, the Identifier may be recycled if all other Identifiers have subsequently
been used.
RTX and ERTX timers are used to determine when the remote end point is not
responding to signaling requests. On the expiration of a RTX or ERTX timer, the same
identifier shall be used if a duplicate request is re-sent as stated in Section 6.2.

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 3, Part A Page 1111
Logical Link Control and Adaptation Protocol Specification

A device receiving a duplicate request on a particular signaling channel should reply

with a duplicate response on the same signaling channel. A command response with
an invalid identifier is silently discarded. Signaling identifier 0x00 is an invalid identifier
and shall never be used in any command.
• Data Length (2 octets)
The Data Length field is two octets long and indicates the size in octets of the data
field of the command only, i.e., it does not cover the Code, Identifier, and Data Length
fields.
• Data (0 or more octets)
The Data field is variable in length. The Code field determines the format of the Data
field. The Data Length field specifies the length of the Data field.

4.1 L2CAP_COMMAND_REJECT_RSP (code 0x01)

An L2CAP_COMMAND_REJECT_RSP packet shall be sent in response to a command

packet with an unknown command code or when sending the corresponding
response is inappropriate. Figure 4.3 defines the format of the packet. The identifier
shall match the identifier of the command packet being rejected. Implementations
shall always send these packets in response to unidentified signaling packets.
L2CAP_COMMAND_REJECT_RSP packets should not be sent in response to an
identified response packet.

When multiple commands are included in an L2CAP packet and the packet exceeds the
signaling MTU (MTUsig) of the receiver, a single L2CAP_COMMAND_REJECT_RSP
packet shall be sent in response. The identifier shall match the first request command
in the L2CAP packet. If only responses are recognized, the packet shall be silently
discarded.

LSB octet 0 octet 1 octet 2 octet 3 MSB

Code=0x01 Identifier Data Length

Reason Reason Data (optional)

Figure 4.3: L2CAP_COMMAND_REJECT_RSP packet

The data fields are:

• Reason (2 octets)
The Reason field describes why the request packet was rejected, and is set to one of
the Reason codes in Table 4.3.

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 3, Part A Page 1112
Logical Link Control and Adaptation Protocol Specification

Reason value Description

0x0000 Command not understood
0x0001 Signaling MTU exceeded
0x0002 Invalid CID in request
Other Reserved for future use

Table 4.3: Reason code descriptions

• Reason Data (0 or more octets)

The length and content of the Reason Data field depends on the Reason code. If the
Reason code is 0x0000, “Command not understood”, no Reason Data field is used.
If the Reason code is 0x0001, “Signaling MTU Exceeded”, the 2-octet Reason Data
field represents the maximum signaling MTU the sender of this packet can accept.
If a command refers to an invalid channel then the Reason code 0x0002 will be
returned. Typically a channel is invalid because it does not exist. The Reason
Data field shall be 4 octets containing the local (first) and remote (second) channel
endpoints (relative to the sender of the L2CAP_COMMAND_REJECT_RSP packet)
of the disputed channel. The remote endpoint is the source CID from the rejected
command. The local endpoint is the destination CID from the rejected command. If
the rejected command contains only one of the channel endpoints, the other one shall
be replaced by the null CID 0x0000.
Reason value Reason Data length Reason Data value
0x0000 0 octets
0x0001 2 octets Actual MTUsig
0x0002 4 octets Requested CIDs

Table 4.4: Reason data values

4.2 L2CAP_CONNECTION_REQ (code 0x02)

L2CAP_CONNECTION_REQ packets are sent to create an L2CAP channel between
two devices. The L2CAP channel shall be established before configuration begins.
Figure 4.4 defines the format of the packet.

LSB octet 0 octet 1 octet 2 octet 3 MSB

Code=0x02 Identifier Data Length

PSM Source CID

Figure 4.4: L2CAP_CONNECTION_REQ packet

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 3, Part A Page 1113
Logical Link Control and Adaptation Protocol Specification

The data fields are:

• Protocol/Service Multiplexer - PSM (2 octets (minimum))

The PSM field is at least two octets in length. All PSM values shall have the least
significant bit of the most significant octet equal to 0 and the least significant bit of all
other octets equal to 1.

Note: This means that all PSMs are odd numbers and that the end of a PSM can be
easily found by searching for the first even octet.

PSM values are separated into two ranges. Valid values in the first range are
assigned by the Bluetooth SIG and indicate protocols. The second range of values
are dynamically allocated and used in conjunction with the Service Discovery
protocol (SDP). The dynamically assigned values may be used to support multiple
implementations of a particular protocol.
PSM values in the first range are defined in Assigned Numbers.
Range Type Server Usage Client Usage
0x0001 to Fixed, PSM is fixed for all imple- PSM may be obtained via SDP or may
0x0EFF SIG as- mentations. be assumed for a fixed service. Proto-
signed col used is indicated by the PSM.
(Note 1)
>0x1000 Dynamic PSM may be fixed for a giv- PSM shall be obtained via SDP upon
en implementation or may every reconnection. PSM for one direc-
be assigned at the time the tion will typically be different from the
service is registered in SDP. other direction.

Table 4.5: PSM ranges and usage

1Since PSMs are odd and the least significant bit of the most significant byte is zero, the following
ranges do not contain valid PSMs: 0x0100-0x01FF, 0x0300-0x03FF, 0x0500-0x05FF, 0x0700-0x07FF,
0x0900-0x09FF, 0x0B00-0x0BFF, 0x0D00-0x0DFF. All even values are also not valid as PSMs.

• Source CID - SCID (2 octets)

The source CID is two octets in length and represents a channel endpoint on the
device sending the request. Once the channel has been configured, data packets
flowing to the sender of the request shall be sent to this CID. Thus, the Source CID
represents the channel endpoint on the device sending the request and receiving the
response. The value of the Source CID shall be from the dynamically allocated range
as defined in Table 2.1 and shall not be already allocated to a different channel on the
same logical link on the device sending the request.

4.3 L2CAP_CONNECTION_RSP (code 0x03)

When a device receives an L2CAP_CONNECTION_REQ packet, it shall send an

L2CAP_CONNECTION_RSP packet. Figure 4.5 defines the format of the packet.

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 3, Part A Page 1114
Logical Link Control and Adaptation Protocol Specification

Note: Implementations conforming to a version of the specification lower than version

4.2 may respond with an L2CAP_COMMAND_REJECT_RSP (Reason 0x0002 – Invalid
CID In Request) packet under conditions now covered by result codes of 0x0006 and
0x0007.

If the device sends an L2CAP_CONNECTION_RSP packet with result code "pending",

then it shall subsequently send another L2CAP_CONNECTION_RSP (see also [Vol 3]
Part C, Section 5.2.2.2).

LSB octet 0 octet 1 octet 2 octet 3 MSB

Code=0x03 Identifier Data Length

Destination CID Source CID

Result Status

Figure 4.5: L2CAP_CONNECTION_RSP packet

The data fields are:

• Destination Channel Identifier - DCID (2 octets)

This field contains the channel endpoint on the device sending this response packet.
Thus, the Destination CID represents the channel endpoint on the device receiving
the request and sending the response. The value of the Destination CID shall be
from the dynamically allocated range as defined in Table 2.1 and shall not be already
allocated to a different channel on the same logical link on the device sending the
response.
• Source Channel Identifier - SCID (2 octets)
This field contains the channel endpoint on the device receiving this response packet.
This is copied from the SCID field of the L2CAP_CONNECTION_REQ packet.
• Result (2 octets)
The result field indicates the outcome of the connection request. The result value of
0x0000 indicates success while a non-zero value indicates the connection request
failed or is pending. A logical channel is established on the receipt of a successful
result unless the DCID field is outside of the dynamically allocated range (see
Table 2.1) or is already allocated on the device sending the response. Table 4.6
defines values for this field. If the result field does not indicate the connection was
successful, the DCID and SCID fields may be invalid and shall be ignored.
Value Description
0x0000 Connection successful
0x0001 Connection pending

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 3, Part A Page 1115
Logical Link Control and Adaptation Protocol Specification

Value Description
0x0002 Connection refused – PSM not supported
0x0003 Connection refused – security block
0x0004 Connection refused – no resources available
0x0006 Connection refused – invalid Source CID
0x0007 Connection refused – Source CID already allocated
Other Reserved for future use

Table 4.6: Result values for the L2CAP_CONNECTION_RSP packet

• Status (2 octets)
Only defined for Result = Pending. Indicates the status of the connection. The status
is set to one of the values shown in Table 4.7.
Value Description
0x0000 No further information available
0x0001 Authentication pending
0x0002 Authorization pending
Other Reserved for future use

Table 4.7: Status values for the L2CAP_CONNECTION_RSP packet

4.4 L2CAP_CONFIGURATION_REQ (code 0x04)

L2CAP_CONFIGURATION_REQ packets are sent to establish an initial logical link
transmission contract between two L2CAP entities and also to re-negotiate this contract
whenever appropriate. The contract consists of a set of configuration parameter options
defined in Section 5. All parameter options have default values and can have previously
agreed values which are values that were accepted in a previous configuration process
or in a previous step in the current configuration process. The only parameters that
should be included in the L2CAP_CONFIGURATION_REQ packet are those that
require different values than the default or previously agreed values.

If no parameters need to be negotiated or specified then no options shall be inserted

and the continuation flag (C) shall be set to zero. Any missing configuration parameters
are assumed to have their most recently explicitly or implicitly accepted values. Even
if all default values are acceptable, an L2CAP_CONFIGURATION_REQ packet with no
options shall be sent. Implicitly accepted values are default values for the configuration
parameters that have not been explicitly negotiated for the specific channel under
configuration.

See Section 7.1 for details of the configuration procedure.

Figure 4.6 defines the format of the packet.

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 3, Part A Page 1116
Logical Link Control and Adaptation Protocol Specification

LSB octet 0 octet 1 octet 2 octet 3 MSB

Code=0x04 Identifier Data Length

Destination CID Flags

Configuration Options

Figure 4.6: L2CAP_CONFIGURATION_REQ packet

The data fields are:

• Destination CID - DCID (2 octets)

This field contains the channel endpoint on the device receiving this request packet.
• Flags (2 octets)
Figure 4.7 shows the two-octet Flags field. Note the most significant bit is shown on
the left.

MSB LSB
RFU C

Figure 4.7: L2CAP_CONFIGURATION_REQ Flags field format

Only one flag is defined, the Continuation flag (C).

When both L2CAP entities support the Extended Flow Specification option,
the Continuation flag shall not be used and shall be set to zero in all
L2CAP_CONFIGURATION_REQ and L2CAP_CONFIGURATION_RSP packets.
When all configuration options cannot fit into an L2CAP_CONFIGURATION_REQ
packet with a payload size that does not exceed the receiver's MTUsig, the
options shall be passed in multiple L2CAP_CONFIGURATION_REQ packets.
If all options fit into the receiver's MTUsig, then they shall be sent in a
single L2CAP_CONFIGURATION_REQ packet with the continuation flag set to
zero. Each L2CAP_CONFIGURATION_REQ packet shall only contain complete
options - partially formed options shall not be sent in a packet. Each
L2CAP_CONFIGURATION_REQ packet shall be tagged with a different Identifier
and shall be matched with an L2CAP_CONFIGURATION_RSP packet with the same
Identifier.
When used in the L2CAP_CONFIGURATION_REQ packet, the continuation flag
indicates the responder should expect to receive multiple request packets.
The responder shall reply to each L2CAP_CONFIGURATION_REQ packet.
The responder may reply to each L2CAP_CONFIGURATION_REQ packet
with an L2CAP_CONFIGURATION_RSP packet containing the same option(s)

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 3, Part A Page 1117
Logical Link Control and Adaptation Protocol Specification

present in the request (except for those error conditions more appropriate
for an L2CAP_COMMAND_REJECT_RSP packet), or the responder may
reply with a "Success" L2CAP_CONFIGURATION_RSP packet containing no
options, delaying those options until the full request has been received. The
L2CAP_CONFIGURATION_REQ packet with the continuation flag cleared shall be
treated as the L2CAP_CONFIGURATION_REQ event in the channel state machine.
When used in the L2CAP_CONFIGURATION_RSP packet, the continuation flag shall
be set to one if the flag is set to one in the request. If the continuation flag is set to
one in the response when the matching request has the flag set to zero, it indicates
the responder has additional options to send to the requestor. In this situation,
the requestor shall send null-option L2CAP_CONFIGURATION_REQ packets (with
continuation flag set to zero) to the responder until the responder replies with an
L2CAP_CONFIGURATION_RSP packet where the continuation flag is set to zero.
The L2CAP_CONFIGURATION_RSP packet with the continuation flag set to zero
shall be treated as the L2CAP_CONFIGURATION_RSP event in the channel state
machine.
The result of the configuration transaction is success if all the individual result values
are success, and is failure otherwise.
Other flags are reserved for future use.
• Configuration Options
A list of the parameters and their values to be negotiated shall be provided in
the Configuration Options field. These are defined in Section 5; in addition, as
described in that section, an implementation shall be prepared to receive any number
of unknown options. An L2CAP_CONFIGURATION_REQ packet may contain no
options (referred to as an empty or null configuration request) and can be used to
request a response. For an empty configuration request the Data Length field is set to
0x0004.

4.5 L2CAP_CONFIGURATION_RSP (code 0x05)

L2CAP_CONFIGURATION_RSP packets shall be sent in reply to

L2CAP_CONFIGURATION_REQ packets except when the error condition is covered by
an L2CAP_COMMAND_REJECT_RSP packet response. Each configuration parameter
value (if any is present) in an L2CAP_CONFIGURATION_RSP packet reflects an
‘adjustment’ to a configuration parameter value that has been sent (or, in case of
default values, implied) in the corresponding L2CAP_CONFIGURATION_REQ packet.
For example, if an L2CAP_CONFIGURATION_REQ packet relates to traffic flowing
from device A to device B, the sender of the L2CAP_CONFIGURATION_RSP packet
may adjust this value for the same traffic flowing from device A to device B, but the
response cannot adjust the value in the reverse direction.

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 3, Part A Page 1118
Logical Link Control and Adaptation Protocol Specification

The options sent in the L2CAP_CONFIGURATION_RSP packet depend on the value in

the Result field. Figure 4.8 defines the format of the packet. See also Section 7.1 for
details of the configuration process, including use of the result code "pending".

LSB octet 0 octet 1 octet 2 octet 3 MSB

Code=0x05 Identifier Data Length

Source CID Flags

Result Config

Figure 4.8: L2CAP_CONFIGURATION_RSP packet

The data fields are:

• Source CID - SCID (2 octets)

This field contains the channel endpoint on the device receiving this response
packet. The device receiving the L2CAP_CONFIGURATION_RSP packet shall
check that the Identifier field matches the same field in the corresponding
L2CAP_CONFIGURATION_REQ packet and the SCID matches its local CID paired
with the original DCID.
• Flags (2 octets)
Figure 4.9 displays the two-octet Flags field. Note the most significant bit is shown on
the left.

MSB LSB
RFU C

Figure 4.9: L2CAP_CONFIGURATION_RSP Flags field format

Only one flag is defined, the Continuation flag (C).

When both L2CAP entities support the Extended Flow Specification option,
the Continuation flag shall not be used and shall be set to zero in all
L2CAP_CONFIGURATION_REQ and L2CAP_CONFIGURATION_RSP packets.
More L2CAP_CONFIGURATION_RSP packets will follow when C is set to one. This
flag indicates that the parameters included in the response are a partial subset of
parameters being sent by the device sending the L2CAP_CONFIGURATION_RSP
packet.
The other flag bits are reserved for future use.
• Result (2 octets)
The Result field indicates whether or not the request was acceptable. See Table 4.8
for possible result codes.

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 3, Part A Page 1119
Logical Link Control and Adaptation Protocol Specification

Result Description
0x0000 Success
0x0001 Failure – unacceptable parameters
0x0002 Failure – rejected (no reason provided)
0x0003 Failure – unknown options
0x0004 Pending
0x0005 Failure - flow spec rejected
Other Reserved for future use

Table 4.8: L2CAP_CONFIGURATION_RSP result codes

• Configuration options
This field contains the list of parameters being configured. These are defined
in Section 5. On a successful result (Result=0x0000) and pending result
(Result=0x0004), these parameters contain the return values for any wild card
parameter values (see Section 5.3) and “adjustments” to non-negotiated configuration
parameter values contained in the request. A response with a successful result is also
referred to as a positive response.
On an unacceptable parameters failure (Result=0x0001) the rejected parameters
shall be sent in the response with the values that would have been accepted
if sent in the original request. Any missing configuration parameters in the
L2CAP_CONFIGURATION_REQ packet are assumed to have their default
value or previously agreed value and they too shall be included in the
L2CAP_CONFIGURATION_RSP packet if they need to be changed. A response with
an unacceptable parameters failure is also referred to as a negative response.
On an unknown option failure (Result=0x0003), the option(s) that
contain an option type field that is not understood by the recipient
of the L2CAP_CONFIGURATION_REQ packet shall be included in the
L2CAP_CONFIGURATION_RSP packet unless they are hints. Hints are
those options in the L2CAP_CONFIGURATION_REQ packet that are skipped
if not understood (see Section 5). Hints shall not be included in the
L2CAP_CONFIGURATION_RSP packet and shall not be the sole cause for rejecting
the L2CAP_CONFIGURATION_REQ packet.
On a flow spec rejected failure (Result=0x0005), an Extended Flow Spec option may
be included to reflect the QoS level that would be acceptable (see Section 7.1.3).
The decision on the amount of time (or messages) spent arbitrating the channel
parameters before terminating the negotiation is implementation specific.

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 3, Part A Page 1120
Logical Link Control and Adaptation Protocol Specification

4.6 L2CAP_DISCONNECTION_REQ (code 0x06)

Terminating an L2CAP channel requires that an L2CAP_DISCONNECTION_REQ
packet be sent and acknowledged by an L2CAP_DISCONNECTION_RSP packet.
Figure 4.10 defines the format of the packet. The receiver shall not initiate a
disconnection if the source or destination CIDs do not match.

Once an L2CAP_DISCONNECTION_REQ packet is issued, all incoming data in transit

on this L2CAP channel shall be discarded and any new additional outgoing data shall
be discarded. Once an L2CAP_DISCONNECTION_REQ packet for a channel has been
received, all data queued to be sent out on that channel shall be discarded.

LSB octet 0 octet 1 octet 2 octet 3 MSB

Code=0x06 Identifier Data Length

Destination CID Source CID

Figure 4.10: L2CAP_DISCONNECTION_REQ packet

The data fields are:

• Destination CID - DCID (2 octets)

This field specifies the endpoint of the channel to be disconnected on the device
receiving this request.
• Source CID - SCID (2 octets)
This field specifies the endpoint of the channel to be disconnected on the device
sending this request.

The SCID and DCID are relative to the sender of this request and shall match those of
the channel to be disconnected. If the DCID is not recognized by the receiver of this
message, an L2CAP_COMMAND_REJECT_RSP packet with ‘invalid CID’ result code
shall be sent in response. If the receiver finds a DCID match but the SCID fails to find
the same match, the request should be silently discarded.

4.7 L2CAP_DISCONNECTION_RSP (code 0x07)

L2CAP_DISCONNECTION_RSP packets shall be sent in response to each valid
L2CAP_DISCONNECTION_REQ packet. Figure 4.11 defines the format of the packet.

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 3, Part A Page 1121
Logical Link Control and Adaptation Protocol Specification

LSB octet 0 octet 1 octet 2 octet 3 MSB

Code=0x07 Identifier Data Length

Destination CID Source CID

Figure 4.11: L2CAP_DISCONNECTION_RSP packet

The data fields are:

• Destination CID - DCID (2 octets)

This field identifies the channel endpoint on the device sending the
L2CAP_DISCONNECTION_RSP packet.
• Source CID - SCID (2 octets)
This field identifies the channel endpoint on the device receiving the
L2CAP_DISCONNECTION_RSP packet.
The DCID and the SCID (which are relative to the sender of the
L2CAP_DISCONNECTION_REQ packet), and the Identifier fields shall match those
of the corresponding L2CAP_DISCONNECTION_REQ packet. If the CIDs do not
match, the L2CAP_DISCONNECTION_RSP packet should be silently discarded at
the receiver.

4.8 L2CAP_ECHO_REQ (code 0x08)

L2CAP_ECHO_REQ packets are used to request a response from a remote L2CAP

entity. Figure 4.12 defines the format of the packet. These requests may be used
for testing the link or for passing vendor specific information using the optional
data field. L2CAP entities shall respond to a valid L2CAP_ECHO_REQ packet with
an L2CAP_ECHO_RSP packet. The Echo Data field is optional and implementation
specific. L2CAP entities should ignore the contents of this field if present.

LSB octet 0 octet 1 octet 2 octet 3 MSB

Code=0x08 Identifier Data Length

Echo Data (optional)

Figure 4.12: L2CAP_ECHO_REQ packet

4.9 L2CAP_ECHO_RSP (code 0x09)

An L2CAP_ECHO_RSP packet shall be sent upon receiving a valid

L2CAP_ECHO_REQ packet. Figure 4.13 defines the format of the packet. The
identifier in the L2CAP_ECHO_RSP packet shall match the identifier sent in the

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 3, Part A Page 1122
Logical Link Control and Adaptation Protocol Specification

L2CAP_ECHO_REQ packet. The Echo Data field is optional and implementation

specific. It may contain the contents of the Echo Data field in the L2CAP_ECHO_REQ
packet, different data, or no data at all. L2CAP entities should ignore the contents of this
field if present.

LSB octet 0 octet 1 octet 2 octet 3 MSB

Code=0x09 Identifier Data Length

Echo Data (optional)

Figure 4.13: L2CAP_ECHO_RSP packet

4.10 L2CAP_INFORMATION_REQ (code 0x0A)

L2CAP_INFORMATION_REQ packets are used to request implementation specific

information from a remote L2CAP entity. Figure 4.14 defines the format of the
packet. L2CAP implementations shall respond to a valid L2CAP_INFORMATION_REQ
packet with an L2CAP_INFORMATION_RSP packet. It is optional to send
L2CAP_INFORMATION_REQ packets.

An L2CAP implementation shall only use optional features or attribute ranges

for which the remote L2CAP entity has indicated support through an
L2CAP_INFORMATION_RSP packet. Until an L2CAP_INFORMATION_RSP packet
which indicates support for optional features or ranges has been received only
mandatory features and ranges shall be used.

LSB octet 0 octet 1 octet 2 octet 3 MSB

Code=0x0A Identifier Data Length

InfoType

Figure 4.14: L2CAP_INFORMATION_REQ packet

The data field is:

• InfoType (2 octets)
The InfoType defines the type of implementation specific information being requested.
See Section 4.11 for details on the type of information requested.
Value Description
0x0001 Connectionless MTU
0x0002 Extended features supported

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 3, Part A Page 1123
Logical Link Control and Adaptation Protocol Specification

Value Description
0x0003 Fixed channels supported over BR/EDR
Other Reserved for future use

Table 4.9: InfoType definitions

L2CAP entities shall not send an L2CAP_INFORMATION_REQ packet with InfoType

0x0003 over fixed channel CID 0x0001 until first verifying that the Fixed Channels
bit is set in the Extended feature mask of the remote device. Support for
fixed channels is mandatory for devices with BR/EDR/LE or LE Controllers.
L2CAP_INFORMATION_REQ and L2CAP_INFORMATION_RSP packets shall not be
used over fixed channel CID 0x0005.

4.11 L2CAP_INFORMATION_RSP (code 0x0B)

An L2CAP_INFORMATION_RSP packet shall be sent upon receiving a valid

L2CAP_INFORMATION_REQ packet. Figure 4.15 defines the format of the packet.
The identifier in the L2CAP_INFORMATION_RSP packet shall match the identifier
sent in the L2CAP_INFORMATION_REQ packet. The Info field shall contain the value
associated with the InfoType field sent in the L2CAP_INFORMATION_REQ packet, or
shall be empty if the InfoType is not supported.

LSB octet 0 octet 1 octet 2 octet 3 MSB

Code=0x0B Identifier Data Length

InfoType Result

Info (optional)

Figure 4.15: L2CAP_INFORMATION_RSP packet

The data fields are:

• InfoType (2 octets)
The InfoType defines the type of implementation specific information that
was requested. This value shall be copied from the InfoType field in the
L2CAP_INFORMATION_REQ packet.
• Result (2 octets)
The Result contains information about the success of the request. If result is
"Success," the data field contains the information as specified in Table 4.11. If result is
"Not supported," no data shall be returned.

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 3, Part A Page 1124
Logical Link Control and Adaptation Protocol Specification

Value Description
0x0000 Success
0x0001 Not supported
Other Reserved for future use

Table 4.10: Result values for the L2CAP_INFORMATION_RSP packet

• Info (0 or more octets)

The contents of the Info field depends on the InfoType.
For InfoType = 0x0001, the field contains the remote entity’s 2-octet acceptable
connectionless MTU. The default value is defined in Section 3.2.
For InfoType = 0x0002, the Info field contains the 4 octet L2CAP extended
feature mask. The feature mask refers to the extended features that the L2CAP
entity sending the L2CAP_INFORMATION_RSP packet supports. The feature bits
contained in the L2CAP feature mask are specified in Section 4.12.
For InfoType = 0x0003, the Info field contains an 8 octet bit map that indicates which
Fixed L2CAP Channels (i.e., the L2CAP channels that use a CID from 0x0000 to
0x003F) are supported over BR/EDR. A list of available fixed channels is provided
in Table 2.1 in Section 2.1. A detailed description of this Info field is given in
Section 4.13.

Note: Implementations conforming to a version lower than 1.2, receiving an

L2CAP_INFORMATION_REQ packet with InfoType = 0x0002 for an L2CAP
feature discovery, return an L2CAP_INFORMATION_RSP packet with result code
"Not supported." Implementations conforming to versions 1.2, 2.0 + EDR, or
2.1 + EDR that have an all zero extended features mask may return an
L2CAP_INFORMATION_RSP packet with result code "Not supported."

InfoType Info Info length

(octets)
0x0001 Connectionless MTU 2
0x0002 Extended feature mask 4
0x0003 Fixed channels supported over BR/EDR 8

Table 4.11: L2CAP_INFORMATION_RSP Info fields

4.12 Extended Feature Mask

The features are represented as a bit mask in the L2CAP_INFORMATION_RSP

packet’s Info field (see Section 4.11). For each feature a single bit is specified which
shall be set to 1 if the feature is supported and set to 0 otherwise. All unknown or
unassigned feature bits are reserved for future use.

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 3, Part A Page 1125
Logical Link Control and Adaptation Protocol Specification

The feature mask shown in Table 4.12 consists of 4 octets (numbered octet 0 to 3), with
bit numbers 0 to 7 each.

No. Supported feature Octet Bit

0 Flow control mode 0 0
1 Retransmission mode 0 1
2 Bi-directional QoS1 0 2
3 Enhanced Retransmission mode 0 3
4 Streaming mode 0 4
5 FCS Option2 0 5
6 Extended Flow Specification for BR/EDR 0 6
7 Fixed Channels supported over BR/EDR 0 7
8 Extended Window Size 1 0
9 Unicast Connectionless Data Reception 1 1
10 Enhanced Credit Based Flow Control mode over BR/EDR 1 2
31 Reserved for feature mask extension 3 7
All others Reserved for future use All others

Table 4.12: Extended feature mask

1Peer side supports upper layer control of the Link Manager's Bi-directional QoS, see Section 5.3 for more
details.
2Peer side supports negotiating omitting FCS; see Section 5.5 for more details and the required behavior if

this bit is not set.

4.13 Fixed Channels Supported over BR/EDR

Each fixed channel supported over BR/EDR is represented by a single bit in an 8

octet bit mask. The bit associated with a channel shall be set to 1 if the L2CAP entity
supports that channel. The L2CAP Signaling channel is mandatory and therefore the bit
associated with that channel shall be set to 1. Table 4.13 shows the format of the bit
mask.

CID Fixed Channel Value Octet Bit

0x0000 Null identifier Shall be set to 0 0 0
0x0001 L2CAP Signaling channel Shall be set to 1 0 1
0x0002 Connectionless reception 0 – if not supported 0 2
1 – if supported
0x0003 Previously used 0 3
0x0004 to 0x0006 Reserved for future use 0 4-6

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 3, Part A Page 1126
Logical Link Control and Adaptation Protocol Specification

CID Fixed Channel Value Octet Bit

0x0007 BR/EDR Security Manager 0 – if not supported 0 7
1 – if supported
0x0008 to 0x003E Reserved for future use 1-6 0-7
7 0-6
0x003F Previously used 7 7
Other Reserved for future use Other

Table 4.13: Fixed Channels Supported bit mask

An L2CAP entity shall not transmit on any fixed channel (with the exception of the
L2CAP Signaling channel) until it has received a Fixed Channels Supported InfoType
from the peer L2CAP entity indicating support for that channel, or has received a
valid packet from the remote device on that fixed channel. All packets received on a
non-supported fixed channel shall be ignored.

4.14 [This section is no longer used]

4.15 [This section is no longer used]

4.16 [This section is no longer used]

4.17 [This section is no longer used]

4.18 [This section is no longer used]

4.19 [This section is no longer used]

4.20 L2CAP_CONNECTION_PARAMETER_UPDATE_REQ (code 0x12)

This command shall only be sent from the Peripheral to the Central and only if
one or more of the Peripheral’s Controller, the Central’s Controller, the Peripheral’s
Host and the Central’s Host do not support the Connection Parameters Request Link
Layer Control procedure ([Vol 6] Part B, Section 5.1.7). If a Peripheral’s Host receives
an L2CAP_CONNECTION_PARAMETER_UPDATE_REQ packet it shall respond with
an L2CAP_COMMAND_REJECT_RSP packet with reason 0x0000 (Command not
understood). Figure 4.16 defines the format of the packet.

The L2CAP_CONNECTION_PARAMETER_UPDATE_REQ packet allows the

Peripheral’s Host to request a set of new connection parameters. When the
Central’s Host receives an L2CAP_CONNECTION_PARAMETER_UPDATE_REQ
packet, depending on the parameters of other connections, the Central’s Host may
accept the requested parameters and deliver the requested parameters to its Controller

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 3, Part A Page 1127
Logical Link Control and Adaptation Protocol Specification

or reject the request. In devices supporting HCI, the Central’s Host delivers the
requested parameters to its Controller using the HCI_LE_Connection_Update command
(see [Vol 4] Part E, Section 7.8.18). If the Central’s Host accepts the requested
parameters it shall send the L2CAP_CONNECTION_PARAMETER_UPDATE_RSP
packet with result 0x0000 (Parameters accepted) otherwise it shall set the result to
0x0001 (request rejected).

The Peripheral’s Host will receive an indication from the Peripheral’s Controller when
the connection parameters have been updated. In devices supporting HCI, this
notification will be in the form of an HCI_LE_Connection_Update_Complete event
(see [Vol 4] Part E, Section 7.7.65.3). If the Central’s Controller rejects the updated
connection parameters no indication from the Peripheral’s Controller will be sent to the
Peripheral’s Host.

LSB octet 0 octet 1 octet 2 octet 3 MSB

Code=0x12 Identifier Data Length

Interval_Min Interval_Max

Latency Timeout

Figure 4.16: L2CAP_CONNECTION_PARAMETER_UPDATE_REQ packet

The data fields shall have the same meanings and requirements as the fields of the
LL_CONNECTION_PARAM_REQ PDU (see [Vol 6] Part B, Section 2.4.2.16) with the
same names.

4.21 L2CAP_CONNECTION_PARAMETER_UPDATE_RSP (code 0x13)

This response shall only be sent from the Central to the Peripheral.

The L2CAP_CONNECTION_PARAMETER_UPDATE_RSP packet shall

be sent by the Central’s Host when it receives an
L2CAP_CONNECTION_PARAMETER_UPDATE_REQ packet. Figure 4.17 defines the
format of the packet. If the Central’s Host accepts the request it shall send the
connection parameter update to its Controller.

LSB octet 0 octet 1 octet 2 octet 3 MSB

Code=0x13 Identifier Data Length

Result

Figure 4.17: L2CAP_CONNECTION_PARAMETER_UPDATE_RSP packet

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 3, Part A Page 1128
Logical Link Control and Adaptation Protocol Specification

The data field is:

• Result (2 octets)
The result field indicates the response to the request. The result value of 0x0000
indicates that the Central’s Host has accepted the connection parameters while
0x0001 indicates that the Central’s Host has rejected the connection parameters.
Result Description
0x0000 Connection Parameters accepted
0x0001 Connection Parameters rejected
Other Reserved for future use
Table 4.14: Result values for the L2CAP_CONNECTION_PARAMETER_UPDATE_RSP packet

4.22 L2CAP_LE_CREDIT_BASED_CONNECTION_REQ (code 0x14)

L2CAP_LE_CREDIT_BASED_CONNECTION_REQ packets are sent to create and
configure an L2CAP channel between two devices using LE Credit Based Flow Control
mode. Figure 4.18 defines the format of the packet.

LSB octet 0 octet 1 octet 2 octet 3 MSB

Code=0x14 Identifier Data Length

SPSM Source CID

MTU MPS

Initial Credits

Figure 4.18: L2CAP_LE_CREDIT_BASED_CONNECTION_REQ packet

The data fields are:

• Simplified Protocol/Service Multiplexer – SPSM1(2 octets)

The SPSM field is two octets in length. SPSM values are separated into two ranges.
Values in the first range are assigned by the Bluetooth SIG and indicate protocols.
Values in the second range are dynamically allocated and used in conjunction with
services defined in the GATT Server. The dynamically assigned values may be used
to support multiple implementations of a particular protocol.

Note: Unlike a normal PSM (see Section 4.2), the length of an SPSM is not variable
and each octet may be either odd or even.

SPSM values are defined in Table 4.15.

1This was called LE_PSM in versions 4.1 to 5.1.

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 3, Part A Page 1129
Logical Link Control and Adaptation Protocol Specification

Range Type Server Usage Client Usage

0x0001 to Fixed, SIG SPSM is fixed for all imple- SPSM may be assumed for fixed serv-
0x007F mentations ice. Protocol used is indicated by the
assigned
SPSM as defined in Assigned Numbers.
0x0080 to Dynamic SPSM may be fixed for a SPSM shall be obtained from the serv-
0x00FF given implementation or may ice in GATT upon every reconnection.
be assigned at the time SPSM for one direction will typically be
the service is registered in different from the other direction.
GATT
Other RFU Not applicable Not applicable

Table 4.15: L2CAP_LE_CREDIT_BASED_CONNECTION_REQ SPSM ranges

• Source CID – SCID (2 octets)

The source CID is two octets in length and represents a channel endpoint on the
device sending the request. Once the channel has been created, data packets
flowing to the sender of the request shall be sent to this CID. Thus, the Source CID
represents the channel endpoint on the device sending the request and receiving the
response. The value of the Source CID shall be from the dynamically allocated range
as defined in Table 2.3 and shall not be already allocated to a different channel on the
same logical link on the device sending the request.
• Maximum Transmission Unit – MTU (2 octets)
The MTU field specifies the maximum SDU size (in octets) that the L2CAP layer
entity sending the L2CAP_LE_CREDIT_BASED_CONNECTION_REQ packet can
receive on this channel. L2CAP implementations shall support a minimum MTU size
of 23 octets.
• Maximum PDU Payload Size – MPS (2 octets)
The MPS field specifies the maximum PDU payload size (in octets) that the L2CAP
layer entity sending the L2CAP_LE_CREDIT_BASED_CONNECTION_REQ packet
is capable of receiving on this channel. L2CAP implementations shall support a
minimum MPS of 23 octets and may support an MPS up to 65533 octets.
• Initial Credits – (2 octets)
The initial credit value indicates the number of K-frames that the
peer device can send to the L2CAP layer entity sending the
L2CAP_LE_CREDIT_BASED_CONNECTION_REQ packet. The initial credit value
shall be in the range 0 to 65535.

4.23 L2CAP_LE_CREDIT_BASED_CONNECTION_RSP (code 0x15)

When a device receives an L2CAP_LE_CREDIT_BASED_CONNECTION_REQ packet,
it shall send an L2CAP_LE_CREDIT_BASED_CONNECTION_RSP packet. Figure 4.19
defines the format of the packet.

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 3, Part A Page 1130
Logical Link Control and Adaptation Protocol Specification

LSB octet 0 octet 1 octet 2 octet 3 MSB

Code=0x15 Identifier Data Length

Destination CID MTU

MPS Initial Credits

Result

Figure 4.19: L2CAP_LE_CREDIT_BASED_CONNECTION_RSP packet

The data fields are:

• Destination CID – DCID (2 octets)

The destination CID is two octets in length and represents a channel endpoint on
the device sending the response. Once the channel has been created, data packets
flowing to the sender of the response shall be sent to this CID. Thus, the destination
CID represents the channel endpoint on the device receiving the request and sending
the response. The value of the Destination CID shall be from the dynamically
allocated range as defined in Table 2.3 and shall not be already allocated to a
different channel on the same logical link on the device sending the response.
• Maximum Transmission Unit – MTU (2 octets)
The MTU field specifies the maximum SDU size (in octets) that the L2CAP layer
entity sending the L2CAP_LE_CREDIT_BASED_CONNECTION_RSP packet can
receive on this channel. L2CAP implementations shall support a minimum MTU size
of 23 octets.
• Maximum PDU Payload Size – MPS (2 octets)
The MPS field specifies the maximum PDU payload size (in octets) that the L2CAP
layer entity sending the L2CAP_LE_CREDIT_BASED_CONNECTION_RSP packet
is capable of receiving on this channel. L2CAP implementations shall support a
minimum MPS of 23 octets and may support an MPS up to 65533 octets.
• Initial Credits – (2 octets)
The initial credit value indicates the number of K‑frames that the
peer device can send to the L2CAP layer entity sending the
L2CAP_LE_CREDIT_BASED_CONNECTION_RSP packet. The initial credit value
shall be in the range 0 to 65535.
• Result – (2 octets)
The result field indicates the outcome of the connection request. A result value of
0x0000 indicates success while a non-zero value indicates the connection request
was refused. A logical channel is established on the receipt of a successful result.

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 3, Part A Page 1131
Logical Link Control and Adaptation Protocol Specification

Table 4.16 defines values for this field. The DCID, MTU, MPS and Initial Credits fields
shall be ignored when the result field indicates the connection was refused.
Value Description
0x0000 Connection successful
0x0002 Connection refused – SPSM not supported
0x0004 Connection refused – no resources available
0x0005 Connection refused – insufficient authentication
0x0006 Connection refused – insufficient authorization
0x0007 Connection refused – encryption key size too short1
0x0008 Connection refused – insufficient encryption
0x0009 Connection refused – invalid Source CID
0x000A Connection refused – Source CID already allocated
0x000B Connection refused – unacceptable parameters
Other Reserved for future use

Table 4.16: Result values for the L2CAP_LE_CREDIT_BASED_CONNECTION_RSP packet

1This was previously "Connection refused - insufficient encryption key size".

4.24 L2CAP_FLOW_CONTROL_CREDIT_IND (code 0x16)

A device shall send an L2CAP_FLOW_CONTROL_CREDIT_IND packet when it is

capable of receiving additional K-frames (for example after it has processed one or
more K-frames) in LE Credit Based Flow Control mode and Enhanced Credit Based
Flow Control mode. Figure 4.20 defines the format of the packet.

LSB octet 0 octet 1 octet 2 octet 3 MSB

Code=0x16 Identifier Data Length

CID Credits

Figure 4.20: L2CAP_FLOW_CONTROL_CREDIT_IND packet

The data fields are:

• CID – (2 octets)
The CID is two octets in length and represents the source channel endpoint of the
device sending the L2CAP_FLOW_CONTROL_CREDIT_IND packet. For example, a
received L2CAP_FLOW_CONTROL_CREDIT_IND packet with a given CID (0x0042)
would provide credits for the receiving device’s destination CID (0x0042).

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 3, Part A Page 1132
Logical Link Control and Adaptation Protocol Specification

• Credits – (2 octets)
The credit value field represents number of credits the receiving device can
increment, corresponding to the number of K-frames that can be sent to the
peer device sending the L2CAP_FLOW_CONTROL_CREDIT_IND packet. The credit
value field shall be a number between 1 and 65535.

4.25 L2CAP_CREDIT_BASED_CONNECTION_REQ (code 0x17)

L2CAP_CREDIT_BASED_CONNECTION_REQ packets are sent to create and
configure up to five L2CAP channels between two devices. Figure 4.21 defines the
format of the packet.

LSB octet 0 octet 1 octet 2 octet 3 MSB

Code=0x17 Identifier Data Length

SPSM MTU

MPS Initial Credits

Source CID [0] ...

Figure 4.21: L2CAP_CREDIT_BASED_CONNECTION_REQ packet

The data fields are:

• Simplified Protocol/Service Multiplexer – SPSM (2 octets)

The SPSM is defined in Section 4.22.
• Maximum Transmission Unit – MTU (2 octets)
The MTU field specifies the maximum SDU size (in octets) that the L2CAP
layer entity sending the L2CAP_CREDIT_BASED_CONNECTION_REQ packet can
receive on each of the Source CID channels. L2CAP implementations shall support a
minimum MTU size of 64 octets for these channels.
• Maximum PDU Payload Size – MPS (2 octets)
The MPS field specifies the maximum PDU payload size (in octets) that the L2CAP
layer entity sending the L2CAP_CREDIT_BASED_CONNECTION_REQ packet is
capable of receiving on each of the Source CID channels. L2CAP implementations
shall support a minimum MPS of 64 octets and may support an MPS up to 65533
octets for these channels.
• Initial Credits – (2 octets)
The Initial Credit field value indicates the number of K-frames that
the peer device can send to the L2CAP layer entity sending the

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 3, Part A Page 1133
Logical Link Control and Adaptation Protocol Specification

L2CAP_CREDIT_BASED_CONNECTION_REQ packet on each of the Source CID

channels. The initial credit value shall be in the range of 1 to 65535.
• Source CID – (2 to 10 octets)
The Source CID is an array of up to 5 two-octet values and represents the channel
endpoints on the device sending the request. Once a channel has been created, data
packets flowing to the sender of the request shall be sent to these CIDs. Each entry in
the array shall be non-zero and represents a request for a channel. The value of each
Source CID shall be from the dynamically allocated range as defined in Table 2.1 or
Table 2.3 (depending on the transport in use) and shall not be already allocated to a
different channel on the same logical link on the device sending the request.

4.26 L2CAP_CREDIT_BASED_CONNECTION_RSP (code 0x18)

When a device receives an L2CAP_CREDIT_BASED_CONNECTION_REQ
packet, it shall send an L2CAP_CREDIT_BASED_CONNECTION_RSP packet.
If the device sends an L2CAP_CREDIT_BASED_CONNECTION_RSP packet
with a result code "pending", then it shall subsequently send another
L2CAP_CREDIT_BASED_CONNECTION_RSP (see also [Vol 3] Part C,
Section 5.2.2.2). Figure 4.22 defines the format of the packet.

LSB octet 0 octet 1 octet 2 octet 3 MSB

Code=0x18 Identifier Data Length

MTU MPS

Initial Credits Result

Destination CID [0] ...

Figure 4.22: L2CAP_CREDIT_BASED_CONNECTION_RSP packet

The data fields are:

• Maximum Transmission Unit – MTU (2 octets)

The MTU field specifies the maximum SDU size (in octets) that the L2CAP
layer entity sending the L2CAP_CREDIT_BASED_CONNECTION_RSP packet can
receive on each of the Destination CID channels. L2CAP implementations shall
support a minimum MTU size of 64 octets.
• Maximum PDU Payload Size – MPS (2 octets)
The MPS field specifies the maximum PDU payload size (in octets) that the
L2CAP layer entity sending the L2CAP_CREDIT_BASED_CONNECTION_RSP
packet is capable of receiving on each of the Destination CID channels. L2CAP

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 3, Part A Page 1134
Logical Link Control and Adaptation Protocol Specification

implementations shall support a minimum MPS of 64 octets and may support an MPS
up to 65533 octets.
• Initial Credits – (2 octets)
The Initial Credit field value indicates the number of K-frames that
the peer device can send to the L2CAP layer entity sending the
L2CAP_CREDIT_BASED_CONNECTION_RSP packet on each of the Destination
CID channels. The initial credit value shall be in the range of 1 to 65535.
• Result – (2 octets)
The Result field indicates the outcome of the connection request. Table 4.17 defines
values for this field. The Destination CID, MTU, MPS and Initial Credits fields shall
be ignored when the Result field indicates that all connections were refused or all
connections are pending.
Value Description
0x0000 All connections successful
0x0002 All connections refused – SPSM not supported
0x0004 Some connections refused – insufficient resources available
0x0005 All connections refused – insufficient authentication
0x0006 All connections refused – insufficient authorization
0x0007 All connections refused – encryption key size too short1
0x0008 All connections refused – insufficient encryption
0x0009 Some connections refused – invalid Source CID
0x000A Some connections refused – Source CID already allocated
0x000B All connections refused – unacceptable parameters
0x000C All connections refused – invalid parameters
0x000D All connections pending – no further information available
0x000E All connections pending – authentication pending
0x000F All connections pending – authorization pending
Other Reserved for future use

Table 4.17: Result values for the L2CAP_CREDIT_BASED_CONNECTION_RSP packet

1This was previously "All connections refused - insufficient encryption key size".

• Destination CID – (2 to 10 octets)

The Destination CID is an array of up to 5 two-octet values
and represents the channel endpoints on the device sending the
L2CAP_CREDIT_BASED_CONNECTION_RSP packet. The value of the Destination
CID shall be from the dynamically allocated range as defined in Table 2.1 or Table 2.3

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 3, Part A Page 1135
Logical Link Control and Adaptation Protocol Specification

(depending on the transport in use) and shall not be already allocated to a different
channel on the same logical link on the device sending the response. Once a channel
has been created, data packets flowing to the sender of the response shall be sent
to these CIDs. The order of the Destination CIDs shall correspond to the order of
the Source IDs in the corresponding L2CAP_CREDIT_BASED_CONNECTION_REQ
packet. If a Destination CID is non-zero, the channel was established. If a
Destination CID is 0x0000, the channel was not established. If a device receives
an L2CAP_CREDIT_BASED_CONNECTION_RSP packet with an already-assigned
Destination CID, then both the original channel and the new channel shall not be
used.

4.27 L2CAP_CREDIT_BASED_RECONFIGURE_REQ (code 0x19)

A device shall send an L2CAP_CREDIT_BASED_RECONFIGURE_REQ packet when
its receive MTU or MPS values have changed compared to when the channel was
created or last reconfigured. Figure 4.23 defines the format of the packet.

Note: The current MTU and MPS values of the channels may be different before this
packet is sent.

LSB octet 0 octet 1 octet 2 octet 3 MSB

Code=0x19 Identifier Data Length

MTU MPS

Destination CID [0] ...

Figure 4.23: L2CAP_CREDIT_BASED_RECONFIGURE_REQ packet

The data fields are:

• Maximum Transmission Unit – MTU (2 octets)

The MTU field specifies the maximum SDU size (in octets) that the L2CAP
layer entity sending the L2CAP_CREDIT_BASED_RECONFIGURE_REQ packet can
receive on each of the Destination CID channels. The MTU field shall be greater than
or equal to the greatest current MTU size of these channels.
• Maximum PDU Payload Size – MPS (2 octets)
The MPS field specifies the maximum PDU payload size (in octets) that the L2CAP
layer entity sending the L2CAP_CREDIT_BASED_RECONFIGURE_REQ packet is
capable of receiving on each of the Destination CID channels. If more than one
channel is being configured, the MPS field shall be greater than or equal to the
current MPS size of each of these channels. If only one channel is being configured,
the MPS field may be less than the current MPS of that channel.

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 3, Part A Page 1136
Logical Link Control and Adaptation Protocol Specification

• Destination CID – (2 to 10 octets)

The Destination CID is an array of up to 5 two-octet values which shall
be non-zero and represent the channel endpoints on the device sending the
L2CAP_CREDIT_BASED_RECONFIGURE_REQ packet.

4.28 L2CAP_CREDIT_BASED_RECONFIGURE_RSP (code 0x1A)

When a device receives an L2CAP_CREDIT_BASED_RECONFIGURE_REQ packet,
it shall send an L2CAP_CREDIT_BASED_RECONFIGURE_RSP packet. Figure 4.24
defines the format of the packet.

LSB octet 0 octet 1 octet 2 octet 3 MSB

Code=0x1A Identifier Data Length

Result

Figure 4.24: L2CAP_CREDIT_BASED_RECONFIGURE_RSP

The data fields are:

• Result (2 octets)

The Result field contains information about the success of the request.

Value Description
0x0000 Reconfiguration successful
0x0001 Reconfiguration failed - reduction in size of MTU not allowed
0x0002 Reconfiguration failed - reduction in size of MPS not allowed for more than
one channel at a time
0x0003 Reconfiguration failed - one or more Destination CIDs invalid
0x0004 Reconfiguration failed - other unacceptable parameters
All other val- Reserved for future use
ues

Table 4.18: Result values for the L2CAP_CREDIT_BASED_RECONFIGURE_RSP packet

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 3, Part A Page 1137
Logical Link Control and Adaptation Protocol Specification

5 CONFIGURATION PARAMETER OPTIONS

Options are a mechanism to extend the configuration parameters. Options shall be

transmitted as information elements containing an option type, an option length, and
one or more option data fields. Figure 5.1 illustrates the format of an option.

LSB octet 0 octet 1 octet 2 octet 3 MSB

Option Option
Option data
Type Length

Figure 5.1: Configuration option format

The configuration option fields are:

• Option Type (1 octet)

The Option Type field defines the parameters being configured. If the option is not
recognized (e.g. because the option is defined in a higher version of the specification
than the version the implementation conforms to) then:
– If the most significant bit of the type is 0 (i.e. types 0x00 to 0x7F), the recipient shall
refuse the entire configuration request.
– If the most significant bit of the type is 1 (i.e. types 0x80 to 0xFF), the recipient shall
ignore the option and continue processing with the next option (if any).
• Option Length (1 octet)
The Option Length field defines the number of octets in the option data. Thus an
option type without option data has a length of 0.
• Option data
The contents of this field are dependent on the option type.

5.1 Maximum Transmission Unit (MTU)

This option specifies the maximum SDU size the sender of this option is capable of
accepting for a channel. The Option Type is 0x01, and the Option Length is 2 octets,
carrying the two-octet MTU size value as the only information element (see Figure 5.2).

MTU is not a negotiated value, it is an informational parameter that each device can
specify independently. It indicates to the remote device that the local device can receive,
in this channel, an MTU larger than the minimum required. All L2CAP implementations
shall support a minimum MTU of 48 octets over the ACL-U logical link and 23 octets
over the LE-U logical link; however, some protocols and profiles explicitly require
support for a larger MTU. The minimum MTU for a channel is the larger of the L2CAP

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 3, Part A Page 1138
Logical Link Control and Adaptation Protocol Specification

minimum 48 octet MTU and any MTU explicitly required by the protocols and profiles
using that channel.

Note: The MTU is only affected by the profile directly using the channel. For example, if
a service discovery transaction is initiated by a non service discovery profile, that profile
does not affect the MTU of the L2CAP channel used for service discovery.

The following rules shall be used when responding to an

L2CAP_CONFIGURATION_REQ packet specifying the MTU for a channel:

• A request specifying any MTU greater than or equal to the minimum MTU for the
channel shall be accepted.
• A request specifying an MTU smaller than the minimum MTU for the channel may be
rejected.

The signaling described in Section 4.5 may be used to reject an MTU smaller than
the minimum MTU for a channel. The "failure-unacceptable parameters" result sent
to reject the MTU shall include the proposed value of MTU that the remote device
intends to transmit. It is implementation specific whether the local device continues the
configuration process or disconnects the channel.

If the remote device sends a positive L2CAP_CONFIGURATION_RSP packet it should

include the actual MTU to be used on this channel for traffic flowing into the local
device. Following the above rules, the actual MTU cannot be less than 48 bytes.This
is the minimum of the MTU in the L2CAP_CONFIGURATION_REQ packet and the
outgoing MTU capability of the device sending the L2CAP_CONFIGURATION_RSP
packet. The new agreed value (the default value in a future re-configuration) is the value
specified in the response.

Note: For backwards compatibility reception of the MTU option in a negative

L2CAP_CONFIGURATION_RSP packet where the MTU option is not in error should
be interpreted in the same way as it is in a positive L2CAP_CONFIGURATION_RSP
packet (e.g. the case where another configuration option value is unacceptable but the
negative L2CAP_CONFIGURATION_RSP packet contains the MTU option in addition to
the unacceptable option).

The MTU to be used on this channel for the traffic flowing in the opposite direction will
be established when the remote device sends its own L2CAP_CONFIGURATION_REQ
packet as explained in Section 4.4.

If the configured mode is Enhanced Retransmission mode or Streaming mode then

MTU shall not be reconfigured to a smaller size.

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 3, Part A Page 1139
Logical Link Control and Adaptation Protocol Specification

LSB octet 0 octet 1 octet 2 octet 3 MSB

Option Option MTU
Type=0x01 Length=2

Figure 5.2: MTU option format

The option data field is:

• Maximum Transmission Unit - MTU (2 octets)

The MTU field is the maximum SDU size, in octets, that the originator of the request
can accept for this channel. The MTU is asymmetric and the sender of the request
shall specify the MTU it can receive on this channel if it differs from the default value.
L2CAP implementations shall support a minimum MTU size of 48 octets. The default
value is 672 octets.

5.2 Flush Timeout option

This option is used to inform the recipient of the Flush Timeout the sender is going to
use. This option shall not be used if the Extended Flow Specification is used. The Flush
Timeout is defined in the BR/EDR Baseband specification [Vol 2] Part B, Section 3.3.
The Option Type is 0x02 and the Option Length is 2 octets (see Figure 5.3). The Flush
Timeout option is negotiable.

If the remote device returns a negative response to this option and the local device
cannot honor the proposed value, then it shall either continue the configuration process
by sending a new request with the original value, or disconnect the channel. The flush
timeout applies to all channels on the same ACL logical transport but may be overridden
on a packet by packet basis by marking individual L2CAP packets as non-automatically-
flushable via the Packet_Boundary_Flag in the HCI ACL Data packet (see Section 1.1).

LSB octet 0 octet 1 octet 2 octet 3 MSB

Option Option Flush Timeout
Type=0x02 Length=2

Figure 5.3: Flush Timeout option format

The option data field is:

• Flush Timeout
This value is the Flush Timeout in milliseconds. This is an asymmetric value and the
sender of the request shall specify its flush timeout value if it differs from the default
value of 0xFFFF.

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 3, Part A Page 1140
Logical Link Control and Adaptation Protocol Specification

Possible values are:

0x0001 - no retransmissions at the Baseband level should be performed since the
minimum polling interval is 1.25 ms.
0x0002 to 0xFFFE - Flush Timeout used by the Baseband.
0xFFFF - an infinite amount of retransmissions. This is also referred to as a ’reliable
channel’. In this case, the Baseband shall continue retransmissions until physical link
loss is declared by link manager timeouts.

5.3 Quality of Service (QoS) option

This option specifies a flow specification similar to RFC 13631. Although the RFC flow
specification addresses only the transmit characteristics, the Bluetooth QoS interface
can handle the two directions (Tx and Rx) in the negotiation as described below.

If no QoS configuration parameter is negotiated the link shall assume the default
parameters. The Option Type is 0x03. This option shall not be used if the Extended
Flow Specification option is used. The QoS option is negotiable. Figure 5.4 specifies the
format of this option.

In an L2CAP_CONFIGURATION_REQ packet, this option describes the outgoing traffic

flow from the device sending the request. In a positive L2CAP_CONFIGURATION_RSP
packet, this option describes the incoming traffic flow agreement to the device
sending the response. In a negative L2CAP_CONFIGURATION_RSP packet, this
option describes the preferred incoming traffic flow to the device sending the response.

L2CAP implementations are only required to support ’Best Effort’ service, support for
any other service type is optional. Best Effort does not require any guarantees. If
no QoS option is placed in the request, Best Effort shall be assumed. If any QoS
guarantees are required then a QoS configuration request shall be sent.

The remote device’s L2CAP_CONFIGURATION_RSP packet contains information

that depends on the value of the result field (see Section 4.5). If the request
was for Guaranteed Service, the response shall include specific values for any
wild card parameters (see Token Rate and Token Bucket Size descriptions)
contained in the request. If the result is “Failure – unacceptable parameters”,
the response shall include a list of outgoing flow specification parameters and
parameter values that would make a new L2CAP_CONNECTION_REQ packet
from the local device acceptable by the remote device. Both explicitly referenced
in an L2CAP_CONFIGURATION_REQ packet or implied configuration parameters
can be included in an L2CAP_CONFIGURATION_RSP packet. Recall that any
missing configuration parameters from an L2CAP_CONFIGURATION_REQ packet are
assumed to have their most recently accepted values.

1Internet Engineering Task Force, “A Proposed Flow Specification”, RFC 1363, September 1992.

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 3, Part A Page 1141
Logical Link Control and Adaptation Protocol Specification

If an L2CAP_CONFIGURATION_REQ packet contains any QoS option parameters set

to “do not care” then the L2CAP_CONFIGURATION_RSP packet shall set the same
parameters to “do not care”. This rule applies for Best Effort and, if the parameter is
allowed to be set to the "do not care" value, for Guaranteed Service.

0 31
Option Option Flags Service
Type=0x03 Length=22 Type
Token Rate

Token Bucket Size (octets)

Peak Bandwidth (octets/second)

Latency (microseconds)

Delay Variation (microseconds)

Figure 5.4: Quality of Service (QoS) option format containing Flow Specification

The option data fields are:

• Flags (1 octet)
Reserved for future use.
• Service Type (1 octet)
This field indicates the level of service required. Table 5.1 defines the different
services available. The default value is ‘Best effort’.
If ‘Best effort’ is selected, the remaining parameters should be treated as optional
by the remote device. The remote device may choose to ignore the fields, try to
satisfy the parameters but provide no response (QoS option omitted in the response
message), or respond with the settings it will try to meet.
If ‘No traffic’ is selected, the remainder of the fields shall be ignored because there is
no data being sent across the channel in the outgoing direction.
Value Description
0x00 No traffic
0x01 Best effort (Default)
0x02 Guaranteed
Other Reserved for future use
Table 5.1: Service type definitions
• Token Rate (4 octets)
The value of this field represents the average data rate with which the application
transmits data. The application may send data at this rate continuously. On a short

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 3, Part A Page 1142
Logical Link Control and Adaptation Protocol Specification

time scale the application may send data in excess of the average data rate,
dependent on the specified Token Bucket Size and Peak Bandwidth (see below).
The Token Bucket Size and Peak Bandwidth allow the application to transmit data in
a 'bursty' fashion.
The Token Rate signaled between two L2CAP peers is the data transmitted by the
application and shall exclude the L2CAP protocol overhead. The Token Rate signaled
over the interface between L2CAP and the Link Manager shall include the L2CAP
protocol overhead. Furthermore the Token Rate value signaled over this interface
may also include the aggregation of multiple L2CAP channels onto the same ACL
logical transport.
The Token Rate is the rate with which traffic credits are provided. Credits can
be accumulated up to the Token Bucket Size. Traffic credits are consumed when
data is transmitted by the application. When traffic is transmitted, and there are
insufficient credits available, the traffic is non-conformant. The Quality of Service
guarantees are only provided for conformant traffic. For non-conformant traffic there
may be insufficient resources such as bandwidth and buffer space. Furthermore
non-conformant traffic may violate the QoS guarantees of other traffic flows.
The Token Rate is specified in octets per second. The value 0x00000000 indicates
no token rate is specified. This is the default value and means “do not care”. When
the Guaranteed service is selected, the default value shall not be used. The value
0xFFFFFFFF is a wild card matching the maximum token rate available. The meaning
of this value depends on the service type. For best effort, the value is a hint that the
application wants as much bandwidth as possible. For Guaranteed service the value
represents the maximum bandwidth available at the time of the request.
• Token Bucket Size (4 octets)
The Token Bucket Size specifies a limit on the 'burstiness' with which the application
may transmit data. The application may offer a burst of data equal to the Token
Bucket Size instantaneously, limited by the Peak Bandwidth (see below). The Token
Bucket Size is specified in octets.
The Token Bucket Size signaled between two L2CAP peers is the data transmitted
by the application and shall exclude the L2CAP protocol overhead. The Token Bucket
Size signaled over the interface between L2CAP and Link Manager shall include
the L2CAP protocol overhead. Furthermore the Token Bucket Size value over this
interface may include the aggregation of multiple L2CAP channels onto the same
ACL logical transport.
The value of 0x00000000 means that no token bucket is needed; this is the default
value. When the Guaranteed service is selected, the default value shall not be used.
The value 0xFFFFFFFF is a wild card matching the maximum token bucket available.
The meaning of this value depends on the service type. For best effort, the value

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 3, Part A Page 1143
Logical Link Control and Adaptation Protocol Specification

indicates the application wants a bucket as big as possible. For Guaranteed service
the value represents the maximum L2CAP SDU size.
The Token Bucket Size is a property of the traffic carried over the L2CAP channel.
The Maximum Transmission Unit (MTU) is a property of an L2CAP implementation.
For the Guaranteed service the Token Bucket Size shall be smaller or equal to the
MTU.
• Peak Bandwidth (4 octets)
The value of this field, expressed in octets per second, limits how fast packets from
applications may be sent back-to-back. Some systems can take advantage of this
information, resulting in more efficient resource allocation.
The Peak Bandwidth signaled between two L2CAP peers specifies the data
transmitted by the application and shall exclude the L2CAP protocol overhead. The
Peak Bandwidth signaled over the interface between L2CAP and Link Manager shall
include the L2CAP protocol overhead. Furthermore the Peak Bandwidth value over
this interface may include the aggregation of multiple L2CAP channels onto the same
ACL logical transport.
The value of 0x00000000 means "do not care." This states that the device has no
preference on incoming maximum bandwidth, and is the default value. When the
Guaranteed service is selected, the default value shall not be used.
• Access Latency (4 octets)
The value of this field is the maximum acceptable delay of an L2CAP packet to
the air-interface. The precise interpretation of this number depends on over which
interface this flow parameter is signaled. When signaled between two L2CAP peers,
the Access Latency is the maximum acceptable delay between the instant when
the L2CAP SDU is received from the upper layer and the start of the L2CAP SDU
transmission over the air. When signaled over the interface between L2CAP and
the Link Manager, it is the maximum delay between the instant the first fragment of
an L2CAP PDU is stored in the Controller buffer and the initial transmission of the
L2CAP packet on the air.
Thus the Access Latency value may be different when signaled between L2CAP
and the Link Manager to account for any queuing delay at the L2CAP transmit
side. Furthermore the Access Latency value may include the aggregation of multiple
L2CAP channels onto the same ACL logical transport.
The Access Latency is expressed in microseconds. The value 0xFFFFFFFF means
“do not care” and is the default value. When the Guaranteed service is selected, the
default value shall not be used.
• Delay Variation (4 octets)
The value of this field is the difference, in microseconds, between the maximum and
minimum possible delay of an L2CAP SDU between two L2CAP peers. The Delay

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 3, Part A Page 1144
Logical Link Control and Adaptation Protocol Specification

Variation is a purely informational parameter. The value 0xFFFFFFFF means “do not
care” and is the default value.

5.4 Retransmission and Flow Control option

This option specifies whether retransmission and flow control is used. If the feature
is used both incoming and outgoing parameters are specified by this option. The
Retransmission and Flow Control option contains both negotiable parameters and non-
negotiable parameters. The mode parameter controls both incoming and outgoing data
flow (i.e. both directions have to agree) and is negotiable. The other parameters control
incoming data flow and are non-negotiable. Figure 5.5 specifies the format of this
option.

0 31
Option
Option Type=0x04 Mode TxWindow size
Length=9
Monitor timeout
Max Transmit Retransmission timeout
(least significant byte)
Monitor timeout Maximum PDU payload size
(most significant byte) (MPS)

Figure 5.5: Retransmission and Flow Control option format

The option data fields are:

• Mode (1 octet)
The field contains the requested mode of the link. Possible values are shown in
Table 5.2.
Value Description
0x00 L2CAP Basic mode
0x01 Retransmission mode
0x02 Flow control mode
0x03 Enhanced Retransmission mode
0x04 Streaming mode
Other Reserved for future use
Table 5.2: Mode definitions

The Basic L2CAP mode is the default. If Basic L2CAP mode is requested then all
other parameters shall be ignored.
Enhanced Retransmission mode should be enabled if a reliable channel has been
requested. Enhanced Retransmission mode shall only be sent to an L2CAP entity
that has previously advertised support for the mode in its Extended Feature Mask
(see Section 4.12).

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 3, Part A Page 1145
Logical Link Control and Adaptation Protocol Specification

Streaming mode should be enabled if a finite L2CAP Flush Timeout is set on an

L2CAP connection. Streaming mode shall only be sent to a device that has previously
advertised support for the mode in the Extended Feature Mask (see Section 4.12).
Flow Control mode and Retransmission mode shall only be used for backwards
compatibility with L2CAP entities that do not support Enhanced Retransmission mode
or Streaming mode.
• TxWindow size (1 octet)
This field specifies the size of the transmission window for Flow Control mode,
Retransmission mode, and Enhanced Retransmission mode. The range is 1 to 32
for Flow Control mode and Retransmission mode. The range is 1 to 63 for Enhanced
Retransmission mode.
In Retransmission mode and Flow Control mode this parameter should be negotiated
to reflect the buffer sizes allocated for the connection on both sides. In general, the
Tx Window size should be made as large as possible to maximize channel utilization.
Tx Window size also controls the delay on flow control action. The transmitting device
can send as many PDUs fit within the window.
In Enhanced Retransmission mode this value indicates the maximum number
of I-frames that the sender of the option can receive without acknowledging
some of the received frames. It is not negotiated. It is an informational
parameter that each L2CAP entity can specify separately. In general, the
TxWindow size should be made as large as possible to maximize channel
utilization. The transmitting L2CAP entity can send as many PDUs as will fit
within the receiving L2CAP entity's TxWindow. TxWindow size values in an
L2CAP_CONFIGURATION_RSP packet indicate the maximum number of packets
the sender can send before it requires an acknowledgment. In other words it
represents the number of unacknowledged packets the sender can hold. The value
sent in an L2CAP_CONFIGURATION_RSP packet shall be less than or equal to the
TxWindow size sent in the L2CAP_CONFIGURATION_REQ packet. The receiver of
this option in the L2CAP_CONFIGURATION_RSP packet may use this value as part
of its acknowledgment algorithm.
In Streaming mode this value is reserved for future use.
• MaxTransmit (1 octet)
This field controls the number of transmissions of a single I-frame that L2CAP is
allowed to try in Retransmission mode and Enhanced Retransmission mode. The
minimum value is 1 (one transmission is permitted).
MaxTransmit controls the number of retransmissions that L2CAP is allowed to try
in Retransmission mode and Enhanced Retransmission mode before accepting that
a packet and the channel is lost. When a packet is lost after being transmitted
MaxTransmit times the channel shall be disconnected by sending a Disconnect
request (see Section 4.6). In Enhanced Retransmission mode MaxTransmit controls

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 3, Part A Page 1146
Logical Link Control and Adaptation Protocol Specification

the number of retransmissions for I-frames and S-frames with P-bit set to 1. The
sender of the option in an L2CAP_CONFIGURATION_REQ packet specifies the
value that shall be used by the receiver of the option. MaxTransmit values in an
L2CAP_CONFIGURATION_RSP packet shall be ignored. Lower values might be
appropriate for services requiring low latency. Higher values will be suitable for a
link requiring robust operation. A value of 1 means that no retransmissions will be
made but also means that the channel will be disconnected as soon as a packet
is lost. MaxTransmit shall not be set to zero in Retransmission mode. In Enhanced
Retransmission mode a value of zero for MaxTransmit means infinite retransmissions.
In Streaming mode this value is reserved for future use.
• Retransmission timeout (2 octets)
This is the value in milliseconds of the retransmission timeout (this value is used to
initialize the RetransmissionTimer).
The purpose of this timer in retransmission mode is to activate a retransmission in
some exceptional cases. In such cases, any delay requirements on the channel may
be broken, so the value of the timer should be set high enough to avoid unnecessary
retransmissions due to delayed acknowledgments. Suitable values could be 100’s of
milliseconds and up.
The purpose of this timer in flow control mode is to supervise I-frame transmissions.
If an acknowledgment for an I-frame is not received within the time specified by
the RetransmissionTimer value, either because the I-frame has been lost or the
acknowledgment has been lost, the timeout will cause the transmitting side to
continue transmissions. Suitable values are implementation dependent.
The purpose of this timer in Enhanced Retransmission mode is to detect lost I-frames
and initiate appropriate error recovery. The value used for the Retransmission timeout
is specified in Section 8.6.2. The value sent in an L2CAP_CONFIGURATION_REQ
packet is also specified in Section 8.6.2. A value for the Retransmission timeout shall
be sent in a positive L2CAP_CONFIGURATION_RSP packet and indicates the value
that will be used by the sender of the L2CAP_CONFIGURATION_RSP packet.
In Streaming mode this value is reserved for future use.
• Monitor timeout (2 octets)
In Retransmission mode this is the value in milliseconds of the interval at which
S-frames should be transmitted on the return channel when no frames are received
on the forward channel. (this value is used to initialize the MonitorTimer, see below).
This timer ensures that lost acknowledgments are retransmitted. Its main use is
to recover Retransmission Disable Bit changes in lost frames when no data is
being sent. The timer shall be started immediately upon transitioning to the open
state. It shall remain active as long as the connection is in the open state and the
retransmission timer is not active. Upon expiration of the Monitor timer an S-frame

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 3, Part A Page 1147
Logical Link Control and Adaptation Protocol Specification

shall be sent and the timer shall be restarted. If the monitor timer is already active
when an S-frame is sent, the timer shall be restarted. An idle connection will have
periodic monitor traffic sent in both directions. The value for this timeout should also
be set to 100’s of milliseconds or higher.
In Enhanced Retransmission mode the Monitor timeout is used to detect lost S-
frames with P-bit set to 1. If the timeout occurs before a response with the F-bit
set to 1 is received the S-frame is resent. The value used for the Monitor timeout
is specified in Section 8.6.3. The value sent in an L2CAP_CONFIGURATION_REQ
packet is also specified in Section 8.6.2. A value for the Monitor timeout shall be sent
in a positive L2CAP_CONFIGURATION_RSP packet and indicates the value that will
be used by the sender of the L2CAP_CONFIGURATION_RSP packet.
In Streaming mode this value is reserved for future use.
• Maximum PDU payload Size - MPS (2 octets)
The maximum payload size that the L2CAP layer entity sending the option in
an L2CAP_CONFIGURATION_REQ packet is capable of accepting, i.e. the MPS
corresponds to the maximum PDU payload size. Each device specifies the value
separately. An MPS value sent in a positive L2CAP_CONFIGURATION_RSP packet
is the actual MPS the receiver of the L2CAP_CONFIGURATION_REQ packet will use
on this channel for traffic flowing into the local device. An MPS value sent in a positive
L2CAP_CONFIGURATION_RSP packet shall be equal to or smaller than the value
sent in the L2CAP_CONFIGURATION_REQ packet.

When using Retransmission mode and Flow Control mode the settings are configured
separately for the two directions of an L2CAP connection. For example, in operating
with an L2CAP entity implementing a lower version of the specification, an
L2CAP connection can be configured as Flow Control mode in one direction and
Retransmission mode in the other direction. If Basic L2CAP mode is configured in one
direction and Retransmission mode or Flow control mode is configured in the other
direction on the same L2CAP channel then the channel shall not be used.

Note: This asymmetric configuration only occurs during configuration.

When using Enhanced Retransmission mode or Streaming mode, both directions of the
L2CAP connection shall be configured to the same mode. A precedence algorithm shall
be used by both devices so a mode conflict can be resolved in a quick and deterministic
manner.

There are two operating states:

• A device has a preferred mode but is willing to use another mode (known as "state
1"), and
• A device requires a specific mode (known as "state 2"). This includes cases where
channels are created over ACL-U logical links operating as described in Section 7.10.

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 3, Part A Page 1148
Logical Link Control and Adaptation Protocol Specification

In state 1, Basic L2CAP mode has the highest precedence and shall take precedence
over Enhanced Retransmission mode and Streaming mode. Enhanced Retransmission
mode has the second highest precedence and shall take precedence over all other
modes except Basic L2CAP mode. Streaming mode shall have the next level of
precedence after Enhanced Retransmission mode.

In state 2, a layer above L2CAP requires Enhanced Retransmission mode or Streaming

mode. In this case, the required mode takes precedence over all other modes.

A device does not know in which state the remote device is operating so the state 1
precedence algorithm assumes that the remote device may be a state 2 device. If the
mode proposed by the remote device has a higher precedence (according to the state
1 precedence) then the algorithm will operate such that creation of a channel using the
remote device's mode has higher priority than disconnecting the channel.

The algorithm for state 1 devices is divided into two parts. Part one covers the case
where the remote device proposes a mode with a higher precedence than the state 1
local device. Part two covers the case where the remote device proposes a mode with a
lower precedence than the state 1 local device. Part one of the algorithm is as follows:

• When the remote device receives the L2CAP_CONFIGURATION_REQ packet from

the local device it will either reject the local device's L2CAP_CONFIGURATION_REQ
packet by sending a negative L2CAP_CONFIGURATION_RSP packet or disconnect
the channel. The negative L2CAP_CONFIGURATION_RSP packet will contain the
remote device's desired mode.
• Upon receipt of the negative L2CAP_CONFIGURATION_RSP packet the local device
shall either send a second L2CAP_CONFIGURATION_REQ packet proposing the
mode contained in the remote device's negative L2CAP_CONFIGURATION_RSP
packet or disconnect the channel.
• When the local device receives the L2CAP_CONFIGURATION_REQ packet from
the remote device it shall send a positive L2CAP_CONFIGURATION_RSP packet or
disconnect the channel.
• If the mode in the remote Device's negative L2CAP_CONFIGURATION_RSP packet
does not match the mode in the remote device's L2CAP_CONFIGURATION_REQ
packet then the local device shall disconnect the channel.

Part two of the algorithm is as follows:

• When the local device receives the L2CAP_CONFIGURATION_REQ packet from

the remote device it shall reject the L2CAP_CONFIGURATION_REQ packet
by sending a negative L2CAP_CONFIGURATION_RSP packet proposing its
desired mode. The local device's desired mode shall be the same mode it
sent in its L2CAP_CONFIGURATION_REQ packet. Upon receiving the negative

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 3, Part A Page 1149
Logical Link Control and Adaptation Protocol Specification

L2CAP_CONFIGURATION_RSP packet the remote device will either send a second

L2CAP_CONFIGURATION_REQ packet or disconnect the channel.
• If the local device receives a second L2CAP_CONFIGURATION_REQ packet from
the remote device that does not contain the desired mode then the local device shall
disconnect the channel.
• If the local device receives a negative L2CAP_CONFIGURATION_RSP packet then it
shall disconnect the channel.

An example of the algorithm for state 1 devices is as follows:

• The remote device proposes Basic L2CAP mode in an

L2CAP_CONFIGURATION_REQ packet and the local device proposes Enhanced
Retransmission mode or Streaming mode. The remote device rejects the
local device's L2CAP_CONFIGURATION_REQ packet by sending a negative
L2CAP_CONFIGURATION_RSP packet proposing Basic mode. The local device
will send a second L2CAP_CONFIGURATION_REQ packet proposing Basic
L2CAP mode or disconnect the channel. If the local device sends a second
L2CAP_CONFIGURATION_REQ packet that does not propose Basic L2CAP mode
then the remote device will disconnect the channel. If the local device rejects the
remote device's L2CAP_CONFIGURATION_REQ packet then the remote device will
disconnect the channel.

The algorithm for state 2 devices is as follows:

• If the local device proposes a mode in an L2CAP_CONFIGURATION_REQ packet

and the remote device proposes a different mode or rejects the local device's
L2CAP_CONFIGURATION_REQ packet then the local device shall disconnect the
channel.

For Enhanced Retransmission mode and Streaming mode the Retransmission timeout
and Monitor Timeout parameters of the Retransmission and Flow Control option
parameters may be changed but all other parameters shall not be changed in a
subsequent reconfiguration after the channel has reached the OPEN state.

5.5 Frame Check Sequence (FCS) option

This option is used to specify the type of Frame Check Sequence (FCS) that will be
included on S/I-frames that are sent. It is non-negotiable. The FCS option shall only be
used when the mode is configured to, or in an L2CAP_CONFIGURATION_REQ packet
that contains an option configuring it to, Enhanced Retransmission mode or Streaming
mode. This option shall only be used if the peer L2CAP entity has indicated support for
the FCS Option in the Extended Features Mask (see Section 4.12).

Figure 5.6 specifies the format of this option. The Option Type is 0x05. "No FCS"
shall only be used if both L2CAP entities send the FCS Option with value 0x00 (No

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 3, Part A Page 1150
Logical Link Control and Adaptation Protocol Specification

FCS) in an L2CAP_CONFIGURATION_REQ packet. If one L2CAP entity sends the

FCS Option with "No FCS" in an L2CAP_CONFIGURATION_REQ packet and the other
L2CAP sends the FCS Option with a value other than "No FCS" then the default
shall be used. If one or both L2CAP entities do not send the FCS option in an
L2CAP_CONFIGURATION_REQ packet then the default shall be used.

LSB octet 0 octet 1 octet 2 octet 3 MSB

Option Option FCS Type
Type=0x05 Length=1

Figure 5.6: FCS option format

The FCS types are shown in Table 5.3

Value Description
0x00 No FCS
0x01 16-bit FCS defined in section 3.3.5 (default)
Other Reserved for future use

Table 5.3: FCS types

Value of 0x00 is set when the sender wishes to omit the FCS from S/I-frames.

5.6 Extended Flow Specification option

This option specifies a flow specification for requesting a desired Quality of Service
(QoS) on a channel. It is non-negotiable. Extended Flow Specification may be
supported on channels created over ACL-U logical links (see Section 7.10). If both
devices show support for Extended Flow Specification for BR/EDR in the Extended
Feature mask (see Table 4.12) then all channels created between the two devices shall
use an Extended Flow Specification. The Quality of Service option and Flush Timeout
option shall not be used if the Extended Flow Specification is used.

The parameters in the Extended Flow Specification option specify the traffic stream in
the outgoing direction (transmitted traffic). The Option Type is 0x06. Figure 5.7 specifies
the format of this option.

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 3, Part A Page 1151
Logical Link Control and Adaptation Protocol Specification

0 31

Option Option Service

Identifier
Type=0x06 Length=16 Type
SDU Inter-arrival Time
Maximum SDU Size
(least significant octets)
SDU Inter-arrival Time Access Latency
(remaining octets) (least significant octets)
Access Latency Flush Timeout
(remaining octets) (least significant octets)
Flush Timeout
(remaining octets)

Figure 5.7: Extended Flow Specification option format

If no Extended Flow Specification is provided by the upper layer, an Extended Flow

Specification with following default values shall be used:

Qos Parameter Default Value

Identifier 0x01
Service Type Best Effort
Maximum SDU size 0xFFFF
SDU Inter-arrival Time 0xFFFFFFFF
Access Latency 0xFFFFFFFF
Flush Timeout 0xFFFFFFFF

Table 5.4: Default values for Extended Flow Specification

For a Best Effort channel no latency, air-time or bandwidth guarantees shall be

assumed.

The parameters of the Extended Flow Specification are shown in Table 5.5:

QoS parameter Parameter Size in Octets Unit

Identifier 1 none
Service Type 1 none
Maximum SDU Size 2 octets
SDU Inter-arrival Time 4 microseconds
Access Latency 4 microseconds
Flush Timeout 4 microseconds

Table 5.5: Traffic parameters for L2CAP QoS configuration

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 3, Part A Page 1152
Logical Link Control and Adaptation Protocol Specification

• Identifier (1 octet)
This field provides a unique identifier for the flow specification. This identifier is used
by some Controllers in the process of setting up the QoS request. Each active flow
specification sent by a device to configure an L2CAP channel shall have a unique
Identifier. An Identifier can be reused when the L2CAP channel associated with
the flow spec is disconnected. The Identifier shall be unique within the scope of a
physical link. Extended Flow Specifications for channels on different physical links
may have the same Identifier. The Identifier for an Extended Flow Specification with
Service Type Best Effort shall be 0x01.
Since the Identifier for an Extended Flow Specification with Service Type Best Effort
is fixed to 0x01 it is possible to generate a Best Effort Extended Flow Specification
for the remote device without performing the Lockstep Configuration process. (The
Lockstep Configuration process is described in Section 7.1.3).
• Service Type (1 octet)
This field indicates the level of service required. Table 5.6 defines the different Service
Types values. The default value is 'Best effort'. If 'Best effort' is selected then Access
Latency and Flush Timeout shall both be set to 0xFFFFFFFF. Maximum SDU size
and SDU Inter-arrival Time are used to indicate the maximum data rate that the
application can deliver to L2CAP for transmission. The remote device should respond
with lower settings indicating the maximum rate at which it can receive data (for
example, maximum rate data it can write to a mass storage device, etc.). Values
of 0xFFFF for Maximum SDU size and 0xFFFFFFFF for SDU Inter-arrival time are
used when the actual values are not known. If Maximum SDU size is set to 0xFFFF
then SDU Inter-arrival time shall be set to 0xFFFFFFFF, if SDU Inter-arrival time is
set to 0xFFFFFFFF then Maximum SDU size shall be set to 0xFFFF. This tells the
Controller to allocate as much bandwidth as possible.

If “Guaranteed” is selected the QoS parameters can be used to identify different types of
Guaranteed traffic.

• Guaranteed bandwidth traffic is traffic with a minimum data rate but no particular
latency requested. Latency will be related to the link supervision timeout. For this type
of traffic Access Latency is set to 0xFFFFFFFF.
• Guaranteed Latency traffic is traffic with only latency requirements. For this type of
traffic SDU Inter-arrival time is set to 0xFFFFFFFF. HID interrupt channel and AVRCP
are examples of this type of traffic.
• Both Guaranteed Latency and Bandwidth traffic has both a latency and bandwidth
requirement. An example is Audio/Video streaming.

If 'No Traffic' is selected the remainder of the fields shall be ignored because there is no
data being sent across the channel in the outgoing direction.

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 3, Part A Page 1153
Logical Link Control and Adaptation Protocol Specification

Value Description
0x00 No Traffic
0x01 Best effort (Default)
0x02 Guaranteed
Other Reserved for future use

Table 5.6: Service type definitions

A channel shall not be configured as “Best Effort” in one direction and “Guaranteed”
in the other direction. If a channel is configured in this way it shall be disconnected.
A channel may be configured as “No Traffic” in one direction and “Best Effort” in
the other direction. The “No Traffic” refers to the application traffic not the Enhanced
Retransmission mode supervisory traffic. A channel configured in this way is considered
to have a service type of Best Effort. A channel may be configured as “No Traffic” in
one direction and “Guaranteed” in the other direction. A channel configure in this way is
considered to have a service type of Guaranteed.

Once configured the service type of a channel shall not be changed during
reconfiguration.

• Maximum SDU Size (2 octets)

The Maximum SDU Size parameter specifies the maximum size of the SDUs
transmitted by the application. If the Service Type is “Guaranteed” then traffic
submitted to L2CAP with a larger size is considered non-conformant. QoS guarantees
are only provided for conformant traffic.
• SDU Inter-arrival time (4 octets)
The SDU Inter-arrival time parameter specifies the time between consecutive SDUs
generated by the application. For streaming traffic, SDU Inter-arrival time should be
set to the average time between SDUs. For variable rate traffic and best effort traffic,
SDU Inter-arrival time should be set to the minimum time between SDUs. If the
Service Type is “Guaranteed” then traffic submitted to L2CAP with a smaller interval,
is considered non-conformant. QoS guarantees are only provided for conformant
traffic.
• Access Latency (4 octets)
The Access Latency parameter specifies the maximum delay between consecutive
transmission opportunities on the air-interface for the connection. Access latency is
based on the time base of the Controller, which is not necessarily synchronous to the
time base being used by the Host or the application.
For streaming traffic (such as in A2DP), the Access Latency should be set to indicate
the time budgeted for transmission of the data over the air, and would normally be

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 3, Part A Page 1154
Logical Link Control and Adaptation Protocol Specification

roughly equal to the Flush Timeout minus the duration of streaming data which can be
stored in the receive side application buffers.
For non-streaming, bursty traffic (such as in HID and AVRCP), the Access Latency
parameter value sent in the L2CAP_CONFIGURATION_REQ packet should be set
to the desired latency, minus any HCI transport delays and any other stack delays
that may be expected on the device and on target Host systems. The remote device
receiving the L2CAP_CONFIGURATION_REQ packet may send an Access Latency
parameter value in the L2CAP_CONFIGURATION_RSP packet which is equal to
or lower than the value it received. The remote device may send a lower value to
account for other traffic it may be carrying, or overhead activities it may be carrying
out.
If HCI is used then the Host should take into account the latency of the HCI transport
when determining the value for the Access Latency. For example if the application
requires an Access Latency of 20 ms and the HCI transport has a latency of 5 ms
then the value for Access Latency should be 15 ms.
• Flush Timeout (4 Octets)
The Flush Timeout defines a maximum period after which all segments of the SDU
are flushed from L2CAP and the Controller. A Flush Timeout value of 0xFFFFFFFF
indicates that data will not be discarded by the transmitting side, even if the link
becomes congested, and thus in this case data is treated as reliable and is never
flushed.
The device receiving the L2CAP_CONFIGURATION_REQ packet with Flush Timeout
set to 0xFFFFFFFF should not modify this parameter. The Flush Timeout for a “Best
Effort” channel shall be set to 0xFFFFFFFF.
However, if the Traffic Type is “Guaranteed” and the transmit side buffer is limited,
then the Flush Timeout parameter given in the L2CAP_CONFIGURATION_REQ
packet may be set to a value corresponding to the duration of streaming data
which the transmit buffer can hold before it must begin discarding data. The
side receiving the L2CAP_CONFIGURATION_REQ packet may then set the Flush
Timeout parameter in the L2CAP_CONFIGURATION_RSP packet to a lower value if
the receive side buffer is smaller than the transmit side buffer.

Note: The total available buffer space is typically a combination of application buffers,
any buffers maintained by the L2CAP implementation, and HCI buffers provided by
the Controller.

The Flush Timeout should normally be set to a value which is larger than the Access
Latency, and which also accounts for buffers maintained by the application on the
receive side such as de-jitter buffers used in audio and video streaming applications.
In general, the Flush Timeout value should be selected to ensure that the Flush
Timeout expires when the application buffers are about to be exhausted.

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 3, Part A Page 1155
Logical Link Control and Adaptation Protocol Specification

Flush Timeout may be set to 0x00000000 to indicate that no retransmissions are to

occur. Data may be flushed immediately after transmission in this case. This behavior
is useful in applications such as gaming where the tolerable latency is on the order of
a few milliseconds, and hence the information contained in a packet will become stale
very rapidly. In such applications, it is preferable to send “fresher” data if the last SDU
submitted for transmission was not transmitted as a result of interference.

5.7 Extended Window Size option

This option is used to negotiate the maximum extended window size. The Option Type
is 0x07 and the option is non-negotiable. Figure 5.8 specifies the format of this option.

LSB octet 0 octet 1 octet 2 octet 3 MSB

Option Option Max Window Size
Type=0x07 Length=2

Figure 5.8: Extended Window Size option format

The allowable values for the Maximum Extended Window Size are:

Value Description
0x0000 Invalid value for Enhanced Retransmission mode
Valid for Streaming mode
0x0001 to Valid maximum window size (frames) for Enhanced Retransmission mode. Invalid
0x3FFF for Streaming mode
Other Reserved for future use
Table 5.7: Extended Window Size values

This option shall only be sent if the peer L2CAP entity has indicated support for the
Extended Window size feature in the Extended Features Mask (see Section 4.12).

This option shall be ignored if the channel is configured to use Basic L2CAP mode (see
Section 5.4).

For Enhanced Retransmission mode, this option has the same directional semantics
as the Retransmission and Flow Control option (see Section 5.4). The sender of
an L2CAP_CONFIGURATION_REQ packet containing this option is suggesting the
maximum window size (possibly based on its own internal L2CAP receive buffer
resources) that the peer L2CAP entity should use when sending data.

For Streaming mode, this option is used to enable use of the Extended Control Field
and if sent, shall have a value of 0.

If this option is successfully configured then the Maximum Window Size negotiated
using the Retransmission and Flow Control option (see Section 5.4) shall be ignored.

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 3, Part A Page 1156
Logical Link Control and Adaptation Protocol Specification

If this option is successfully configured in either direction then both L2CAP entities shall
use the Extended Control Fields in all S/I-frames (see Section 3.3.2).

If the option is only configured in one direction then the maximum window size for the
opposite direction shall be taken from the maximum window size value in the existing
Retransmission and Flow Control option. In this configuration both L2CAP entities shall
use the extended control fields in all S/I-frames.

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 3, Part A Page 1157
Logical Link Control and Adaptation Protocol Specification

6 STATE MACHINE

The state machine does not necessarily represent all possible scenarios.

6.1 General rules for the state machine

It is implementation specific, and outside the scope of the specification, how the
transmissions are triggered.

“Ignore” means that the signal can be silently discarded.

The following states have been defined to clarify the protocol; the actual number of
states and naming in a given implementation is outside the scope of the specification:

• 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.
• OPEN – user data transfer state.
• WAIT_DISCONNECT – a disconnect request has been sent, pending a disconnect
response.

In the following state tables and descriptions, the L2CAP_Data message corresponds
to one of the PDU formats used on connection-oriented data channels as described in
Section 3, including PDUs containing B-frames, I-frames, or S-frames.

Some state transitions and actions are triggered only by internal events effecting one
of the L2CAP entity implementations, not by preceding L2CAP signaling messages. It
is implementation-specific and out of the scope of the specification, how these internal
events are realized; just for the clarity of specifying the state machine, the following
abstract internal events are used in the state event tables, as far as needed:

• OpenChannel_Req – a local L2CAP entity is requested to set up a new connection-

oriented channel.
• OpenChannel_Rsp – a local L2CAP entity is requested to finally accept or refuse a
pending connection request.
• ConfigureChannel_Req – a local L2CAP entity is requested to initiate an outgoing
configuration request.

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 3, Part A Page 1158
Logical Link Control and Adaptation Protocol Specification

• CloseChannel_Req – a local L2CAP entity is requested to close a channel.

• SendData_Req – a local L2CAP entity is requested to transmit an SDU.
• ReconfigureChannel_Req – a local L2CAP entity is requested to reconfigure the
parameters of a connection-oriented channel.
• ControllerLogicalLinkInd – a Controller indicates the acceptance or rejection of a
logical link request with an Extended Flow Specification.

There is a single state machine for each L2CAP connection-oriented channel that is
active. A state machine is created for each new L2CAP_CONNECTION_REQ received.
The state machine always starts in the CLOSED state.

To simplify the state event tables, the RTX and ERTX timers, as well as the handling
of request retransmissions are described in Section 6.2 and not included in the state
tables.

L2CAP messages not bound to a specific data channel and thus not impacting
a channel state (e.g. L2CAP_INFORMATION_REQ, L2CAP_ECHO_REQ) are not
covered in this section.

The following states and transitions are illustrated in Figure 6.1.

6.1.1 CLOSED state

Event Condition Action Next State

OpenChannel_req - Send L2CAP_CONNEC- WAIT_-
TION_REQ CONNECT_RSP
L2CAP_CONNEC- Normal, connection Send L2CAP_CONNEC- CONFIG
TION_REQ is possible TION_RSP (success) (substate
WAIT_CONFIG)
L2CAP_CONNEC- Need to indicate L2CAP_CONNEC- WAIT_CONNECT
TION_REQ pending TION_RSP (pending)
L2CAP_CONNEC- No resource, not Send L2CAP_CONNEC- CLOSED
TION_REQ approved, etc. TION_RSP (refused)
L2CAP_CONNEC- - Ignore CLOSED
TION_RSP
L2CAP_CONFIGURA- - Send L2CAP_COM- CLOSED
TION_REQ MAND_REJECT_RSP (with
reason Invalid CID)
L2CAP_CONFIGURA- - Ignore CLOSED
TION_RSP

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 3, Part A Page 1159
Logical Link Control and Adaptation Protocol Specification

Event Condition Action Next State

L2CAP_DISCONNEC- - Send L2CAP_DISCONNEC- CLOSED
TION_REQ TION_RSP
L2CAP_DISCONNEC- - Ignore CLOSED
TION_RSP
L2CAP_Data - Ignore CLOSED

Table 6.1: CLOSED state event table

Note: The L2CAP_CONNECTION_REQ message is not mentioned in any of the other

states apart from the CLOSED state, as it triggers the establishment of a new channel,
thus the branch into a new instance of the state machine.

6.1.2 WAIT_CONNECT_RSP state

Event Condition Action Next State

L2CAP_CONNEC- Success indica- Send L2CAP_CONFIGURA- CONFIG (substate
TION_RSP ted in result TION_REQ WAIT_CONFIG)
L2CAP_CONNEC- Result pending - WAIT_CONNECT_RSP
TION_RSP
L2CAP_CONNEC- Remote side refu- - CLOSED
TION_RSP ses connection
L2CAP_CONFIGU- - Send L2CAP_COMMAND_- WAIT_CONNECT_RSP
RATION_REQ REJECT_RSP (with reason
Invalid CID)
L2CAP_CONFIGU- - Ignore WAIT_CONNECT_RSP
RATION_RSP
L2CAP_DISCON- - Ignore WAIT_CONNECT_RSP
NECTION_RSP
L2CAP_Data - Ignore WAIT_CONNECT_RSP

Table 6.2: WAIT_CONNECT_RSP state event table

Note: An L2CAP_DISCONNECTION_REQ message is not included here, since the

Source and Destination CIDs are not available yet to relate it correctly to the state
machine of a specific channel.

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 3, Part A Page 1160
Logical Link Control and Adaptation Protocol Specification

6.1.3 WAIT_CONNECT state

Event Condition Action Next State

OpenChannel_Rsp Pending connec- Send CONFIG (substate
tion request is fi- L2CAP_CONNEC WAIT_CONFIG)
nally acceptable TION_RSP (suc-
cess)
OpenChannel_Rsp Pending connec- Send CLOSED
tion request is fi- L2CAP_CON-
nally refused NECTION_RSP
(refused)
L2CAP_CONNEC- - Ignore WAIT_CONNECT
TION_RSP
L2CAP_CONFIGURA- - Ignore WAIT_CONNECT
TION_RSP
L2CAP_DISCONNEC- - Ignore WAIT_CONNECT
TION_RSP
L2CAP_Data - Ignore WAIT_CONNECT

Table 6.3: WAIT_CONNECT state event table

Note: An L2CAP_DISCONNECTION_REQ or L2CAP_CONFIGURATION_REQ

message is not included here, since the Source and Destination CIDs are not available
yet to relate it correctly to the state machine of a specific channel.

6.1.4 CONFIG state

Two configuration processes exist as described in Section 7.1. The configuration

processes are the Standard process and the Lockstep process.

In the Standard and Lockstep configuration processes both L2CAP entities initiate a
configuration request during the configuration process. This means that each device
adopts an initiator role for the outgoing configuration request, and an acceptor role
for the incoming configuration request. Configurations in both directions may occur
sequentially, but can also occur in parallel.

In the Lockstep configuration process both L2CAP entities send

L2CAP_CONFIGURATION_REQ packets and receive L2CAP_CONFIGURATION_RSP
packets with a pending result code before submitting the flow specifications to their local
Controllers. A final L2CAP_CONFIGURATION_RSP packet is sent by each L2CAP
entity indicating the response from its local Controller.

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 3, Part A Page 1161
Logical Link Control and Adaptation Protocol Specification

The following substates are distinguished within the CONFIG state:

• WAIT_CONFIG – a device has sent or received a connection response, but has

neither initiated a configuration request yet, nor received a configuration request with
acceptable parameters.
• WAIT_SEND_CONFIG – for the initiator path, a configuration request has not yet
been initiated, while for the response path, a request with acceptable options has
been received.
• WAIT_CONFIG_REQ_RSP – for the initiator path, a request has been sent but a
positive response has not yet been received, and for the acceptor path, a request with
acceptable options has not yet been received.
• WAIT_CONFIG_RSP – the acceptor path is complete after having responded to
acceptable options, but for the initiator path, a positive response on the recent
request has not yet been received.
• WAIT_CONFIG_REQ – the initiator path is complete after having received a positive
response, but for the acceptor path, a request with acceptable options has not yet
been received.
• WAIT_IND_FINAL_RSP – for both the initiator and acceptor, the Extended Flow
Specification has been sent to the local Controller but neither a response from
Controller nor the final configuration response has yet been received.
• WAIT_FINAL_RSP – the device received an indication from the Controller accepting
the Extended Flow Specification and has sent a positive response. It is waiting for the
remote device to send a configuration response.
• WAIT_CONTROL_IND – the device has received a positive response and is waiting
for its Controller to accept or reject the Extended Flow Specification.

According to Section 6.1.1 and Section 6.1.2, the CONFIG state is entered via
WAIT_CONFIG substate from either the CLOSED state, the WAIT_CONNECT state,
or the WAIT_CONNECT_RSP state. The CONFIG state is left for the OPEN state if
both the initiator and acceptor paths complete successfully.

For better overview, separate tables are given: Table 6.4 shows the success transitions;
therein, transitions on one of the minimum paths (no previous non-success transitions)
are shaded. Table 6.5 shows the non-success transitions within the configuration
process, and Table 6.6 shows further transition cause by events not belonging to
the configuration process itself. The following configuration states and transitions are
illustrated in Figure 6.2.

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 3, Part A Page 1162
Logical Link Control and Adaptation Protocol Specification

Previous state Event Condition Action Next State

WAIT_CONFIG ConfigureChan- Standard Send WAIT_CONFIG_-
nel_ Req process L2CAP_CONFIG REQ_RSP
URATION_REQ
WAIT_CONFIG ConfigureChan- Lockstep Send WAIT_CONFIG_-
nel_ Req process L2CAP_CONFIG- REQ_RSP
URATION_REQ
(Ext Flow Spec
plus other op-
tions)
WAIT_CONFIG L2CAP_CONFIG- Options ac- Send WAIT_SEND_-
URATION_REQ ceptable L2CAP_CONFIG- CONFIG
URATION_RSP
Standard
(success)
process
WAIT_CONFIG L2CAP_CONFIG- Options ac- Send WAIT_SEND_-
URATION_REQ ceptable L2CAP_CONFIG- CONFIG
URATION_RSP
Lockstep
(pending)
process
WAIT_CONFIG_- L2CAP_CONFIG- Options ac- Send WAIT_CONFIG_-
REQ_RSP URATION_REQ ceptable L2CAP_CONFIG- RSP
URATION_RSP
(success)
WAIT_CONFIG_- L2CAP_CONFIG- Remote side (continue waiting WAIT_CONFIG_-
REQ_RSP URATION_RSP accepts op- for configuration REQ
tions request)
WAIT_CONFIG_REQ L2CAP_CONFIG- Options ac- Send OPEN
URATION_REQ ceptable L2CAP_CONFIG-
URATION_RSP
Standard
(success)
process
WAIT_CONFIG_REQ L2CAP_CONFIG- Options ac- Send WAIT_IND_-
URATION_REQ ceptable L2CAP_CONFIG- FINAL_RSP
URATION_RSP
Lockstep
(pending)
process
WAIT_SEND_CONFIG ConfigureChan- none Send WAIT_CONFIG_-
nel_ Req L2CAP_CONFIG- RSP
URATION_REQ
WAIT_CONFIG_RSP L2CAP_CONFIG- Remote side none OPEN
URATION_RSP accepts op-
tions
Standard
process

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 3, Part A Page 1163
Logical Link Control and Adaptation Protocol Specification

Previous state Event Condition Action Next State

WAIT_CONFIG_RSP L2CAP_CONFIG- Remote side none WAIT_IND_-
URATION_RSP accepts op- FINAL_RSP
tion
Lockstep
proc
WAIT_IND_FINAL_- ControllerLogical Reject Send WAIT_CONFIG
RSP L2CAP_CONFIG-
LinkInd
URATION_RSP
(fail)
WAIT_IND_FINAL_- ControllerLogical Accept Send WAIT_FINAL_-
RSP L2CAP_CONFIG- RSP
LinkInd
URATION_RSP
(success)
WAIT_IND_FINAL_- L2CAP_CONFIG- Remote side none WAIT_CONFIG
RSP URATION_RSP fail
WAIT_IND_FINAL_- L2CAP_CONFIG- Remote side none WAIT_-
RSP URATION_RSP success CONTROL_IND
WAIT_FINAL_RSP L2CAP_CONFIG- Remote side none WAIT_CONFIG
URATION_RSP fail
WAIT_FINAL_RSP L2CAP_CONFIG- Remote side none OPEN
URATION_RSP success
WAIT_CONTROL_IND ControllerLogical Reject Send WAIT_CONFIG
L2CAP_CONFIG-
LinkInd
URATION_RSP
(fail)
WAIT_CONTROL_IND ControllerLogical Accept Send OPEN
L2CAP_CONFIG-
LinkInd
URATION_RSP
(success)

Table 6.4: CONFIG state event table

Previous state Event Condition Action Next State

WAIT_CONFIG L2CAP_CONFIG- Options not Send WAIT_CONFIG
URATION_REQ acceptable L2CAP_CONFIG-
URATION_RSP
(fail)
WAIT_CONFIG L2CAP_CONFIG- none Ignore WAIT_CONFIG
URATION_RSP
WAIT_SEND_CONFIG L2CAP_CONFIG- none Ignore WAIT_SEND_-
URATION_RSP CONFIG

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 3, Part A Page 1164
Logical Link Control and Adaptation Protocol Specification

Previous state Event Condition Action Next State

WAIT_CONFIG_- L2CAP_CONFIG- Options not Send WAIT_CONFIG_-
REQ_RSP URATION_REQ acceptable L2CAP_CONFIG- REQ_RSP
URATION_RSP
(fail)
WAIT_CONFIG_- L2CAP_CONFIG- Remote side Send WAIT_CONFIG_-
REQ_RSP URATION_RSP rejects op- L2CAP_CONFIG- REQ_RSP
tions URATION_REQ
(new options)
WAIT_CONFIG_REQ L2CAP_CONFIG- Options not Send WAIT_CONFIG_-
URATION_REQ acceptable L2CAP_CONFIG- REQ
URATION_RSP
(fail)
WAIT_CONFIG_REQ L2CAP_CONFIG- none Ignore WAIT_CONFIG_-
URATION_RSP REQ
WAIT_CONFIG_RSP L2CAP_CONFIG- Remote side Send WAIT_CONFIG_-
URATION_RSP rejects op- L2CAP_CONFIG- RSP
tions URATION_REQ
(new options)

Table 6.5: CONFIG state/substates event table: non-success transitions within configuration process

Previous state Event Condition Action Next State

CONFIG (any sub- CloseChan- Any internal rea- Send WAIT_-
state) nel_Req son to stop L2CAP_DISCON- DISCONNECT
NECTION_REQ
CONFIG (any sub- L2CAP_DIS none Send CLOSED
state) CONNECTI L2CAP_DISCON-
ON_REQ NECTION_RSP
CONFIG (any sub- L2CAP_DIS none Ignore CONFIG (remain
state) CONNECTI in substate)
ON_RSP
CONFIG (any sub- L2CAP_Da- none Process the PDU CONFIG (remain
state) ta in substate)

Table 6.6: CONFIG state/substates event table: events not related to configuration process

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 3, Part A Page 1165
Logical Link Control and Adaptation Protocol Specification

Notes:

• Receiving data PDUs (L2CAP_Data) in CONFIG state should be relevant only in

case of a transition to a reconfiguration procedure (from OPEN state). Discarding the
received data is allowed only in Retransmission mode and Enhanced Retransmission
mode. Discarding an S-frame is allowed but not recommended. If a S-frame is
discarded, the monitor timer will cause a new S-frame to be sent after a time out.
• Indicating a failure in a configuration response does not necessarily imply a failure of
the overall configuration procedure; instead, based on the information received in the
negative response, a modified configuration request may be triggered.

6.1.5 OPEN state

Event Condition Action Next State

SendData_req none Send L2CAP_Data packet ac- OPEN
cording to configured mode
ReconfigureChannel_Req none Complete outgoing SDU CONFIG (sub-
state WAIT_CON-
Send L2CAP_CONFIGURA-
FIG_REQ_RSP)
TION_REQ
CloseChannel_Req none Send L2CAP_DISCONNEC- WAIT_-
TION_REQ DISCONNECT
L2CAP_CONNECTION_RSP none Ignore OPEN
L2CAP_CONFIGURATION_- Incoming Complete outgoing SDU CONFIG (substate
REQ config op- WAIT_SEND_-
Send L2CAP_CONFIGURA-
tions ac- CONFIG)
TION_RSP (ok)
ceptable
L2CAP_CONFIGURATION_- Incoming Complete outgoing SDU OPEN
REQ config op- Send L2CAP_CONFIGURA-
tions not TION_RSP (fail)
acceptable
L2CAP_DISCONNECTION_- none Send L2CAP_DISCONNEC- CLOSED
REQ TION_RSP
L2CAP_DISCONNECTION_- none Ignore OPEN
RSP
L2CAP_Data none Process the PDU OPEN

Table 6.7: OPEN state event table

The outgoing SDU shall be completed from the view of the remote entity. Therefore
all PDUs forming the SDU shall have been reliably transmitted by the local entity and
acknowledged by the remote entity, before entering the configuration state.

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 3, Part A Page 1166
Logical Link Control and Adaptation Protocol Specification

6.1.6 WAIT_DISCONNECT state

Event Condition Action Next State

L2CAP_CONNECTION_RSP none Ignore WAIT_DIS-
CONNECT
L2CAP_CONFIGURATION_- none Send L2CAP_COMMAND_- WAIT_DIS-
REQ REJECT_RSP with reason Invalid CONNECT
CID
L2CAP_CONFIGURATION_- none Ignore WAIT_DIS-
RSP CONNECT
L2CAP_DISCONNECTION_- none Send L2CAP_DISCONNECTION_- CLOSED
REQ RSP
L2CAP_DISCONNECTION_- none none CLOSED
RSP
L2CAP_Data none Ignore WAIT_DIS-
CONNECT

Table 6.8: WAIT_DISCONNECT state event table

6.1.7 [This section is no longer used]

6.1.8 [This section is no longer used]

6.1.9 [This section is no longer used]

6.1.10 [This section is no longer used]

6.1.11 [This section is no longer used]

6.1.12 [This section is no longer used]

6.2 Timers events

6.2.1 RTX

The Response Timeout eXpired (RTX) timer is used to terminate the channel when the
remote endpoint is unresponsive to signaling requests. This timer is started when a
signaling request (see Section 7) is sent to the remote device. This timer is disabled
when the response is received. If the initial timer expires, a duplicate Request message
may be sent or the channel identified in the request may be disconnected. If a duplicate
Request message is sent, the RTX timeout value shall be reset to a new value
at least double the previous value. When retransmitting the Request message, the
context of the same state shall be assumed as with the original transmission. If a
Request message is received that is identified as a duplicate (retransmission), it shall
be processed in the context of the same state which applied when the original Request
message was received.

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 3, Part A Page 1167
Logical Link Control and Adaptation Protocol Specification

Implementations have the responsibility to decide on the maximum number of Request

retransmissions performed at the L2CAP level before terminating the channel identified
by the Requests. The exception is fixed channel CIDs since they can never be
terminated. On the LE transport, the Peripheral's Host may disconnect the link on
the expiry of the RTX timer. The decision should be based on the flush timeout of
the signaling link. The longer the flush timeout, the more retransmissions may be
performed at the physical layer and the reliability of the channel improves, requiring
fewer retransmissions at the L2CAP level.

For example, if the flush timeout is infinite, no retransmissions should be performed

at the L2CAP level. When terminating the channel, it is not necessary to send an
L2CAP_DISCONNECTION_REQ and enter WAIT_DISCONNECT state. Channels can
be transitioned directly to the CLOSED state.

The value of this timer is implementation-dependent but the minimum initial value is
1 second and the maximum initial value is 60 seconds. One RTX timer shall exist
for each outstanding signaling request, including each L2CAP_ECHO_REQ. The timer
disappears on the final expiration, when the response is received, or the physical link is
lost. The maximum elapsed time between the initial start of this timer and the initiation
of channel termination (if no response is received) is 60 seconds.

6.2.2 ERTX

The Extended Response Timeout eXpired (ERTX) timer is used in place of the RTX
timer when it is suspected the remote endpoint is performing additional processing of a
request signal. This timer is started when the remote endpoint responds that a request
is pending, e.g., when an L2CAP_CONNECTION_RSP event with a “connect pending”
result (0x0001) is received. This timer is disabled when the formal response is received
or the physical link is lost. If the initial timer expires, a duplicate Request may be sent or
the channel may be disconnected.

If a duplicate Request is sent, the particular ERTX timer disappears, replaced by a new
RTX timer and the whole timing procedure restarts as described previously for the RTX
timer.

The value of this timer is implementation-dependent but the minimum initial value is 60
seconds and the maximum initial value is 300 seconds. Similar to RTX, there shall be at
least one ERTX timer for each outstanding request that received a Pending response.
There should be at most one (RTX or ERTX) associated with each outstanding request.
The maximum elapsed time between the initial start of this timer and the initiation of
channel termination (if no response is received) is 300 seconds. When terminating the
channel, it is not necessary to send an L2CAP_DISCONNECTION_REQ and enter
WAIT_DISCONNECT state. Channels should be transitioned directly to the CLOSED
state.

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 3, Part A Page 1168
Logical Link Control and Adaptation Protocol Specification

Event:L2CAP_CONNECTION_RSP
Event:L2CAP_CONNECTION_RSP (refused)
(refused) CLOSED Action: -
Action: -

Event:L2CAP_CONNECTION_REQ Event:OpenChannelReq
Action:L2CAP_CONNECTION_RSP Action:L2CAP_CONNECTION_REQ
(pending)

WAIT_
WAIT_
CONNECT_
CONNECT
RSP

Event:L2CAP_DISCONNECTION_REQ Event:L2CAP_CONNECTION_REQ
Action:L2CAP_DISCONNECTION_RSP Action:L2CAP_CONNECTION_RSP
Event:OpenChannelRes (success)
(success)
Action:L2CAP_CONNECTION_RSP
(success) Event:L2CAP_CONNECTION_RSP
(success)
Event:L2CAP_CONFIGURATION_REQ Action: -
Action:L2CAP_COMMAND_REJECT_RSP
(invalid CID)

Event:L2CAP_CONNECTION_RSP OR
L2CAP_CONFIGURATION_REQ OR Event:L2CAP_Data
L2CAP_Data Action: Process the PDU
Event:CloseChannelReq
Action:Ignore
Action:L2CAP_DISCONNECTION_REQ
WAIT_DIS-
CONFIG
CONNECT
Event:L2CAP_CONFIGURATION_REQ
Action:L2CAP_CONFIGURATION_RSP Event:ReconfigureChannelReq
Action:Complete outgoing SDU
L2CAP_CONFIGURATION_REQ

Event:L2CAP_CONFIGURATION_REQ
options acceptable
Action:L2CAP_CONFIGURATION_RSP
(success)
Event:L2CAP_DISCONNECTION_REQ
Action:L2CAP_DISCONNECTION_RSP Event:L2CAP_CONFIGURATION_REQ
options not acceptable
Action:L2CAP_CONFIGURATION_RSP
Event:L2CAP_DISCONNECTION_RSP (fail)
Event:CloseChannelReq
Action: -
Action:L2CAP_DISCONNECTION_REQ

CLOSED OPEN
Event:L2CAP_DISCONNECTION_REQ
Action:L2CAP_DISCONNECTION_RSP

Event:SendDataReq
Action: Send L2CAP_Data packet

Event:L2CAP_Data
Action: Process the PDU

Event:L2CAP_DISCONNECTION_RSP
OR L2CAP_CONNECTION_RSP
Action: Ignore

Figure 6.1: States and transitions

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 3, Part A Page 1169
Logical Link Control and Adaptation Protocol Specification

WAIT_ WAIT_
Event: ControllerIndication
CONNECT_ (reject) CONTROL
RSP Action: L2CAP_CONNECTION_RSP _IND
(fail)

CLOSED
Event: L2CAP_CONNECTION_RSP
Event: ControllerIndication
(accept)
Action: L2CAP_CONNECTION_RSP
Event: L2CAP_CONNECTION_REQ (success)
Action: L2CAP_CONNECTION_RSP WAIT_
(success)
FINAL_
RSP
Event: L2CAP_CONFIGURATION_RSP
(fail)
Event: L2CAP_CONFIGURATION_RSP
WAIT_ (success)
CONNECT Event: OpenChannel_Rsp
(success)
Action: L2CAP_CONNECTION_RSP
(success) Event: ControllerIndication (reject)
WAIT_ Action: L2CAP_CONNECTION_RSP (fail) OPEN
CONFIG or
Event: L2CAP_CONFIGURATION_RSP (fail)

Event: L2CAP_CONFIGURATION_REQ
options not acceptable
Action: L2CAP_CONFIGURATION_RSP Event: L2CAP_CONFIGURATION_REQ
(fail) options not acceptable
Action: L2CAP_CONFIGURATION_RSP Event: ControllerIndication Event: L2CAP_CONFIGURATION_RSP
(fail) (accept) (success)
Action: L2CAP_CONNECTION_RSP
(success)

Event: ConfigureChannelReq
Action: L2CAP_CONFIGURATION_REQ
WAIT_
CONFIG_
Event: L2CAP_CONFIGURATION_REQ REQ
options acceptable
Action: L2CAP_CONFIGURATION_RSP
(success) or (pending) Event: L2CAP_CONFIGURATION_REQ
Event: L2CAP_CONFIGURATION_RSP options acceptable
options acceptable Action: L2CAP_CONFIGURATION_RSP
Event: L2CAP_CONFIGURATION_RSP (pending)
(fail)
Action: L2CAP_CONFIGURATION_REQ
(new options) Event: L2CAP_CONFIGURATION_REQ
WAIT_ options acceptable WAIT_IND_
CONFIG_ Action: L2CAP_CONFIGURATION_RSP
(success) FINAL_RSP
REQ_RSP

WAIT_
Event: L2CAP_CONFIGURATION_REQ
SEND_ options not acceptable OPEN
CONFIG Action: L2CAP_CONFIGURATION_RSP
(fail)

Event: L2CAP_CONFIGURATION_REQ
options acceptable
Action: L2CAP_CONFIGURATION_RSP
(success) Event: L2CAP_CONFIGURATION_RSP
options acceptable
Event: L2CAP_CONFIGURATION_RSP
options acceptable
Event: ConfigureChannelReq
Action: L2CAP_CONFIGURATION_REQ

WAIT_
CONFIG_
RSP

Event: L2CAP_CONFIGURATION_RSP
(fail)
Action: L2CAP_CONFIGURATION_REQ
(new options)

Figure 6.2: Configuration states and transitions

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 3, Part A Page 1170
Logical Link Control and Adaptation Protocol Specification

7 GENERAL PROCEDURES

This section describes the general operation of L2CAP, including the configuration
process, the handling and the processing of user data for transportation over the
air interface. This section also describes the operation of L2CAP features including
the delivery of erroneous packets, the flushing of expired data and operation in
connectionless mode, operation collision resolution, aggregation of best effort flow
specifications, and prioritizing data over HCI.

Procedures for the flow control and retransmission modes are described in Section 8.

7.1 Configuration process

Configuration consists of two processes, the Standard process and the Lockstep
process. The Lockstep process shall be used if both L2CAP entities support the
Extended Flow Specification option otherwise the Standard process shall be used.

For both processes, configuring the channel parameters shall be done independently for
both directions. Both configurations may be done in parallel.

Each configuration parameter is one-directional. The configuration parameters describe

the non default parameters the device sending an L2CAP_CONFIGURATION_REQ
packet will accept. The configuration request cannot request a change in the
parameters the device receiving the request will accept.

If a device needs to establish the value of a configuration parameter the remote device
will accept, then it must wait for an L2CAP_CONFIGURATION_REQ packet containing
that configuration parameter to be sent from the remote device.

The Lockstep process is used when the channel parameters include an Extended Flow
Specification option. The Lockstep process can be divided into two phases. In the
first phase, each L2CAP entity shall receive an Extended Flow Specification option
along with all non-default parameters from its peer L2CAP entity and then present the
pair of Extended Flow specifications (local and remote) to its local Controller. In the
second phase, each L2CAP entity shall report the result from its local Controller to the
peer L2CAP entity. The Lockstep process is described in Section 7.1.3. The Standard
process is described in Section 7.1.4.

Both the Lockstep and Standard processes can be abstracted into the initial Request
configuration path and a Response configuration path, followed by the reverse direction
phase. Reconfiguration follows a similar two-phase process by requiring configuration in
both directions.

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 3, Part A Page 1171
Logical Link Control and Adaptation Protocol Specification

During a reconfiguration session, all data traffic on the channel should be

suspended pending the outcome of the configuration. If an L2CAP entity receives an
L2CAP_CONFIGURATION_REQ packet while it is waiting for a response it shall not
block sending the L2CAP_CONFIGURATION_RSP packet, otherwise the configuration
process may deadlock.

7.1.1 Request Path

The Request Path can configure the following:

• requester’s incoming MTU

• requester’s outgoing flush timeout
• requester’s outgoing QoS
• requester’s incoming and outgoing flow and error control information
• requester's incoming and outgoing Frame Check Sequence option
• requester's outgoing QoS using Extended Flow Specification option
• requester's incoming Extended Window size option plus incoming and outgoing frame
format.

Table 7.1 defines the configuration options that may be placed in an

L2CAP_CONFIGURATION_REQ packet.

Parameter Description
MTU Incoming MTU information
FlushTO Outgoing flush timeout1
QoS Outgoing QoS information1
RFCMode Incoming and outgoing Retransmission and Flow Control mode
FCS Incoming and outgoing Frame Check Sequence
ExtFlowSpec Outgoing QoS information1
ExtWindow Incoming Extended Window size plus incoming and outgoing frame format

Table 7.1: Parameters allowed in request

1FlushTO,QoS and ExtFlowSpec are considered QoS information. ExtFlowSpec is used instead of
FlushTO and QoS when both devices support ExtFlowSpec.

The state machine for the configuration process is described in Section 6.

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 3, Part A Page 1172
Logical Link Control and Adaptation Protocol Specification

7.1.2 Response Path

The Response Path can configure the following:

• responder’s outgoing MTU, that is the remote side’s incoming MTU

• remote side’s flush timeout
• responder’s incoming QoS Flow Specification (remote side’s outgoing QoS Flow
Specification)
• responder’s incoming and outgoing Flow and Error Control information
• responder's incoming QoS Extended Flow Specification (remote side's outgoing QoS
Flow Specification)
• responder's outgoing Extended Window size.

For the Standard process, if a request-oriented parameter is not present in the

Request message (reverts to last agreed value), the remote side may negotiate
for a non-default value by including the proposed value in a negative Response
message. Table 7.2 defines the configuration options that may be placed in an
L2CAP_CONFIGURATION_RSP packet.

Parameter Description
MTU Outgoing MTU information
FlushTO Incoming flush timeout1
QoS Incoming QoS information1
RFCMode Incoming and outgoing Retransmission and Flow Control mode
ExtFlowSpec Incoming QoS information1
ExtWindow Outgoing Extended Window size

Table 7.2: Parameters allowed in response

1FlushTO,QoS and ExtFlowSpec are considered QoS information. ExtFlowSpec is used instead of
FlushTO and QoS when both devices support ExtFLowSpec

7.1.3 Lockstep Configuration process

L2CAP_CONFIGURATION_REQ packets are sent to establish or change the channel

parameters including the QoS contract between two L2CAP entities. An Extended
Flow Specification option along with any non-default parameters shall be sent in
an L2CAP_CONFIGURATION_REQ packet following the sending or receipt of a
Connect Response which accepts an L2CAP Connect Request for the channel being
configured. Unlike the Standard process, negotiation involving the sending of multiple
L2CAP_CONFIGURATION_REQ packets shall not be performed. In other words, only
one L2CAP_CONFIGURATION_REQ packet shall be sent by each L2CAP entity during

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 3, Part A Page 1173
Logical Link Control and Adaptation Protocol Specification

the Lockstep configuration process. The Lockstep process shall only be used during
channel reconfiguration when an Extended Flow Specification option is present in the
L2CAP_CONFIGURATION_REQ packet used for reconfiguration.

The Extended Flow Specification shall only be sent for channels created on
the ACL-U logical link if both the local and remote L2CAP entities have
indicated support for the Extended Flow Specification for BR/EDR in their
Extended Features masks. The Extended Features mask shall be obtained via
the L2CAP_INFORMATION_REQ/L2CAP_INFORMATION_RSP signaling mechanism
(InfoType = 0x0002) prior to the issuance of the L2CAP_CONFIGURATION_REQ
packet. If an L2CAP_CONFIGURATION_REQ packet is sent containing the Extended
Flow Specification option then the Quality of Service option and Flush Timeout option
shall not be included.

L2CAP_CONFIGURATION_RSP packets shall be sent in reply to

L2CAP_CONFIGURATION_REQ packets except when the error condition is covered by
an L2CAP_COMMAND_REJECT_RSP response. Although the L2CAP Configuration
signaling mechanism allows for the use of wildcards, wildcard values are not supported
in the Extended Flow Specification since each parameter represents a property of the
traffic in one direction only, and no negotiation is intended to be performed at the L2CAP
Configuration level.

The recipient of an L2CAP_CONFIGURATION_REQ packet shall perform all necessary

checks with the Controller to validate that the requested QoS can be granted. In
the case of a BR/EDR or BR/EDR/LE Controller the L2CAP layer performs the
Controller checks. If HCI is used then the L2CAP entity should check that the
requested QoS can be achieved over the HCI transport. In order to perform these
checks, the recipient needs to have the QoS parameters for both directions. In
order for each side to determine when to perform relevant Controller checks, each
side will reply with a result “Pending” (0x0004). If no parameters are sent in the
L2CAP_CONFIGURATION_RSP packet with result “Pending” then the parameters sent
in the L2CAP_CONFIGURATION_REQ packet have been accepted without change.
This Lockstep procedure results in both L2CAP entities performing the following:

• Receiving an L2CAP_CONFIGURATION_REQ packet containing the Extended Flow

Specification option along with all non-default parameters
• Sending an L2CAP_CONFIGURATION_RSP packet with any modifications to
the Extended Flow Specification option and allowed modifications to non-default
parameters (result “Pending”)
• Sending an L2CAP_CONFIGURATION_REQ packet containing the Extended Flow
Specification option along with all non-default parameters

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 3, Part A Page 1174
Logical Link Control and Adaptation Protocol Specification

• Receiving an L2CAP_CONFIGURATION_RSP packet containing any modifications

to the Extended Flow Specification option and allowed modifications to non-default
parameters (result “Pending”).

The ERTX timer is used when an L2CAP_CONFIGURATION_RSP packet is received

with result “Pending” (see Section 6.2.2).

If an L2CAP_CONFIGURATION_RSP packet with result “success” is received before an

L2CAP_CONFIGURATION_RSP packet with result “pending” is received the recipient
shall disconnect the channel. This is a violation of the Lockstep configuration process.

If a device sends an Extended Flow Specification option in an

L2CAP_CONFIGURATION_REQ packet with service type “Best Effort” and receives an
L2CAP_CONFIGURATION_REQ packet with service type “Guaranteed,” the channel
shall be disconnected. If a device sends an Extended Flow Specification in an
L2CAP_CONFIGURATION_REQ packet with type “Guaranteed” and receives an
L2CAP_CONFIGURATION_REQ packet with service type “Best Effort,” the channel
shall be disconnected.

If the service type is “Best Effort” then values for certain parameters may be sent in an
L2CAP_CONFIGURATION_RSP packet with result “Pending” to indicate the maximum
bandwidth the sender of the L2CAP_CONFIGURATION_RSP packet is capable to
receive. The values sent in an L2CAP_CONFIGURATION_RSP packet with result
“Pending” and service type Best Effort shall be in accordance with Table 7.3.

Parameter Changes permitted by responder

Maximum SDU Size May decrease only
SDU Inter-arrival Time May increase only
Access Latency None
Flush Timeout None

Table 7.3: Permitted parameter in L2CAP_CONFIGURATION_RSP packets for service type “Best Effort”

After the L2CAP_CONFIGURATION_RSP packet is received with result “Pending,”

L2CAP may issue the necessary checks with the Controller.

If the Controller cannot support the Extended Flow Specifications with service type
“Guaranteed,” then the recipient of the L2CAP_CONFIGURATION_REQ packet shall
send an L2CAP_CONFIGURATION_RSP packet indicating a result code of “Failure -
flow spec rejected” (0x0005). If the Controller indicates that it can support the Extended
Flow Specifications, then the recipient of the L2CAP_CONFIGURATION_REQ packet
shall send an L2CAP_CONFIGURATION_RSP packet with result code of “Success”
(0x0000) with no parameters.

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 3, Part A Page 1175
Logical Link Control and Adaptation Protocol Specification

If the Result of the L2CAP_CONFIGURATION_RSP packet is Failure (0x0005) for

service type “Guaranteed” then an Extended Flow Specification option may be
sent in the L2CAP_CONFIGURATION_RSP packet. The Extended Flow Specification
parameters sent in the L2CAP_CONFIGURATION_RSP packet may be changed to
reflect a QoS level that would be acceptable, but shall only be changed in accordance
with Table 7.4.

Parameter Changes permitted by responder

Maximum SDU Size None
SDU Inter-arrival Time None
Access Latency May decrease only
Flush Timeout May decrease only (unless set to
0xFFFFFFFF, in which case no change is per-
mitted)

Table 7.4: Permitted parameter changes in L2CAP_CONFIGURATION_RSP packets for service type
“Guaranteed”

If an L2CAP_CONFIGURATION_RSP packet is received containing the Extended Flow

Specification option with the same values sent earlier, the upper layer shall be notified
of the error.

7.1.4 Standard Configuration process

For the Standard process the following general procedure shall be used for each
direction:

1. Local device informs the remote device of the parameters that the local device will
accept using an L2CAP_CONFIGURATION_REQ packet.
2. Remote device responds, agreeing or disagreeing with these values, including the
default ones, using an L2CAP_CONFIGURATION_RSP packet.
3. The local and remote devices repeat steps (1) and (2) until agreement on all
parameters is reached.

The decision on the amount of time (or messages) spent configuring the channel
parameters before terminating the configuration is left to the implementation, but it shall
not last more than 120 seconds.

There are two types of configuration parameters: negotiable and non-negotiable.

Negotiable parameters are those that a remote side receiving an

L2CAP_CONFIGURATION_REQ packet can disagree with by sending an
L2CAP_CONFIGURATION_RSP packet with the Unacceptable Parameters (0x0001)
result code, proposing new values that can be accepted. Non-negotiable parameters

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 3, Part A Page 1176
Logical Link Control and Adaptation Protocol Specification

are only informational and the recipient of an L2CAP_CONFIGURATION_REQ packet

cannot disagree with them but can provide adjustments to the values in a positive
L2CAP_CONFIGURATION_RSP packet. Section 5 identifies each parameter as
negotiable or non-negotiable.

Note: MTU is non-negotiable but can be rejected if a value lower than the mandated
minimum is proposed (See Section 5.1).

The following rules shall be used for parameter negotiation in the Request Path:

1. An L2CAP entity shall send at least one L2CAP_CONFIGURATION_REQ packet

as part of initial configuration or reconfiguration. If all default or previously agreed
values are acceptable, an L2CAP_CONFIGURATION_REQ packet with no options
shall be sent.
2. When an L2CAP entity receives a positive L2CAP_CONFIGURATION_RSP
packet from the remote device it shall consider all configuration parameters
explicitly contained in the L2CAP_CONFIGURATION_REQ packet along with
the default and previously agreed values not explicitly contained in the
L2CAP_CONFIGURATION_REQ packet as accepted by the remote device.
3. When an L2CAP entity receives a negative L2CAP_CONFIGURATION_RSP
packet and sends a new L2CAP_CONFIGURATION_REQ packet it shall include
all the options it sent in the previous L2CAP_CONFIGURATION_REQ packet with
the same values except the negotiable options that were explicitly rejected in the
negative L2CAP_CONFIGURATION_RSP packet which will have new values.

Note: The resending of all the options provides backwards compatibility with remote
implementations that don’t assume rule 4 when responding.
4. Negotiable options not included in a negative L2CAP_CONFIGURATION_RSP
packet are considered accepted by the remote device.

Note: For backwards compatibility if non-negotiable options are included in a

negative L2CAP_CONFIGURATION_RSP packet, they should be processed as if
the response was positive.

The following rules shall be used for parameter negotiation in the Response Path:

1. A positive L2CAP_CONFIGURATION_RSP packet accepts the values

of all configuration parameters explicitly contained in the received
L2CAP_CONFIGURATION_REQ packet and the default and previously agreed
values not explicitly provided.
2. An L2CAP Entity shall send a negative L2CAP_CONFIGURATION_RSP packet
to reject negotiable parameter values that are unacceptable, be it values
explicitly provided in the received L2CAP_CONFIGURATION_REQ packet or

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 3, Part A Page 1177
Logical Link Control and Adaptation Protocol Specification

previously agreed or default values. The rejected parameters sent in a negative

L2CAP_CONFIGURATION_RSP packet shall have values that are acceptable to
the L2CAP entity sending the negative L2CAP_CONFIGURATION_RSP packet.
3. All negotiable options being rejected shall be rejected in the same negative
L2CAP_CONFIGURATION_RSP packet.
4. The only options allowed in a negative L2CAP_CONFIGURATION_RSP packet
are the negotiable options being rejected. No wildcards or adjustments to non-
negotiable options shall be in a negative L2CAP_CONFIGURATION_RSP packet.
5. Negotiable options not included in the negative L2CAP_CONFIGURATION_RSP
packet are considered accepted.

7.2 Fragmentation and recombination

Fragmentation is the breaking down of PDUs into smaller pieces for delivery from
L2CAP to the lower layer. Recombination is the process of reassembling a PDU from
fragments delivered up from the lower layer. Fragmentation and Recombination may be
applied to any L2CAP PDUs.

7.2.1 Fragmentation of L2CAP PDUs

An L2CAP implementation may fragment any L2CAP PDU for delivery to the lower
layers, whether directly to the Controller or over HCI. All fragments associated with
a specific L2CAP PDU shall be sent to the Controller, in the same order as their
contents occur in the PDU, before any other fragment associated with the same logical
link. Fragments associated with different logical links may be interleaved. (See [Vol 2]
Part B, Section 5.3 and [Vol 6] Part B, Section 4.5.17 for related requirements on the
Controller.)

For example, in the BR/EDR Controller the two LLID bits defined in the first octet
of Baseband payload (also called the frame header) are used to signal the start
and continuation of L2CAP PDUs. LLID shall be 0b10 for the first segment in an
L2CAP PDU and 0b01 for a continuation segment. An illustration of fragmentation for a
BR/EDR Controller is shown in Figure 7.1. An example of how fragmentation might be
used in a device with HCI is shown in Figure 7.2.

PDU Length CID Payload

LLID=0b10 LLID=0b01 LLID=0b01

Figure 7.1: L2CAP fragmentation in a BR/EDR Controller

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 3, Part A Page 1178
Logical Link Control and Adaptation Protocol Specification

Note: The BR/EDR Link Controller is able to impose a different fragmentation on the
PDU by using “start” and “continuation” indications as fragments are translated into
Baseband packets. Thus, both L2CAP and the BR/EDR Link Controller use the same
mechanism to control the size of fragments.

Service Data Unit

Encapsulate SDU
into L2CAP
L2CAP PDU Length CID L2CAP Payload
B-frame

Connection Handle Flags=Start Length HCI data payload

Connection Handle Flags=Continue Length HCI data payload

Segment L2CAP packet
HCI into the payload of many
HCI ACL Data packets.

Host Connection Handle Flags=Continue Length HCI data payload

Software

Transfer packets to HCI 1 HCI 2 HCI n

HCI-USB USB driver Start Continue Continue

USB Send USB

packets over bus USB 1 USB 2 USB 3 USB 4 USB 5 USB p
Driver

USB Hardware bus

USB Receive USB

Driver packets. USB 1 USB 2 USB 3 USB 4 USB 5 USB p

Embedded
Software Re-assemble &
HCI-USB buffer packets HCI 1 HCI 2 HCI n

Assemble 1,3 & 5 Air 1 Air 2 Air 3 Air q

Link Controller slot packet types as Start Continue Continue Continue
appropriate

Radio modulation and transmission

Figure 7.2: Example of fragmentation processes in a device with a BR/EDR Controller and USB HCI
transport

7.2.2 Recombination of L2CAP PDUs

The Controller will provide fragments of L2CAP PDUs to the L2CAP implementation. It
is the responsibility of L2CAP to reassemble PDUs and SDUs and to check the length
field of the SDUs. The L2CAP layer shall reassemble the fragments it receives from the
Controller into complete PDUs, which may then further be combined into SDUs. (See
[Vol 2] Part B, Section 5.3 and [Vol 6] Part B, Section 4.5.17 for related requirements on
the Controller.)

An L2CAP implementation shall use the PDU Length field in the header of L2CAP
PDUs, see Section 3, as a consistency check and shall discard any L2CAP PDUs that
fail to match the PDU Length field. If channel reliability is not needed, packets with
invalid lengths may be silently discarded. For reliable channels using Basic mode, an
L2CAP implementation shall indicate to the upper layer that the channel has become
unreliable. Reliable channels are defined by having an infinite flush timeout value as

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 3, Part A Page 1179
Logical Link Control and Adaptation Protocol Specification

specified in Section 5.2. For higher data integrity L2CAP should be operated in the
Enhanced Retransmission mode.

7.3 Encapsulation of SDUs

All SDUs are encapsulated into one or more L2CAP PDUs.

In Basic L2CAP mode, an SDU shall be encapsulated with a minimum of L2CAP

protocol elements, resulting in a type of L2CAP PDU called a Basic Information Frame
(B-frame).

Segmentation and Reassembly operations are only used in Enhanced Retransmission

mode, Streaming mode, Retransmission mode, Flow Control mode, LE Credit Based
Flow Control mode, and Enhanced Credit Based Flow Control mode. SDUs may be
segmented into a number of smaller packets called SDU segments. Each segment shall
be encapsulated with L2CAP protocol elements resulting in an L2CAP PDU called an
Information Frame (I-frame) or a Credit-based Frame (K-frame).

The maximum size of an SDU segment shall be given by the Maximum PDU Payload
Size (MPS). The MPS parameter may be exported using an implementation specific
interface to the upper layer.

The specification does not describe a service interface with the upper layer, nor
does it assume any specific buffer management scheme of a Host implementation.
Consequently, a reassembly buffer may be part of the upper layer entity. It is assumed
that SDU boundaries are preserved between peer upper layer entities.

7.3.1 Segmentation of L2CAP SDUs

In Flow Control, Streaming, or Retransmission modes, incoming SDUs may be broken

down into segments, which shall then be individually encapsulated with L2CAP protocol
elements (header and checksum fields) to form I-frames. I-frames are subject to flow
control and may be subject to retransmission procedures. The header carries a 2 bit
SAR field that is used to identify whether the I-frame is a 'start', 'end' or 'continuation'
packet or whether it carries a complete, unsegmented SDU.

In LE Credit Based Flow Control or Enhanced Credit Based Control modes,

incoming SDUs may be broken down into segments, which shall then be individually
encapsulated with L2CAP protocol elements (header fields) to form K-frames. The
header of the first segment contains the length of the entire SDU.

Figure 7.3 illustrates segmentation and fragmentation.

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 3, Part A Page 1180
Logical Link Control and Adaptation Protocol Specification

L2CAP SDU

I-frame I-frame

HCI
Fragment/ Fragment/ Fragment/ Fragment/
BB payload BB payload BB payload BB payload

Figure 7.3: Segmentation and fragmentation of an SDU in a BR/EDR Controller

7.3.2 Reassembly of L2CAP SDUs

The receiving side uses the SAR field of incoming 'I-frames' for the reassembly process.
The L2CAP SDU Length field, present in the “start of SDU” I-frame, is an extra integrity
check, and together with the sequence numbers may be used to indicate lost L2CAP
SDUs to the application.

The receiving side uses the SDU length of the first K-frame and the PDU length of each
K-frame for the reassembly process.

Figure 7.3 illustrates segmentation and fragmentation.

7.3.3 Segmentation and fragmentation

Figure 7.4 illustrates the use of segmentation and fragmentation operations to transmit
a single SDU. While SDUs and L2CAP PDUs are transported in peer-to-peer
fashion, the fragment size used by the Fragmentation and Recombination routines
are implementation specific and may be different in the sender and the receiver. The
over-the-air sequence of packet fragments as created by the sender is common to both
devices.

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 3, Part A Page 1181
Logical Link Control and Adaptation Protocol Specification

Service Data Unit

PDU Length Channel ID Control SDU length Information payload FCS

L2CAP

PDU Length Channel ID Control Information payload FCS

Segment SDU into

the payload of many
L2CAP I-frames or K-frames
PDU Length Channel ID Control Information payload FCS

Connection_Handle Flags=start Length HCI data payload

Connection_Handle Flags=continue Length HCI data payload

HCI
Fragment L2CAP PDU
into the payload of multiple
HCI ACL Data packets. Connection_Handle Flags=continue
Flags=continue Length Length HCIpayload
HCI data data payload

Transfer packets to HCI 1 HCI 2 HCI n

HCI-USB USB driver Start Continue Continue

Host USB Send USB

Driver packets over bus USB 1 USB 2 USB 3 USB 4 USB 5 USB p
Software
USB Hardware bus

Embedded USB Receive USB

Driver packets. USB 1 USB 2 USB 3 USB 4 USB 5 USB p
Software

Re-assemble &
HCI-USB buffer packets HCI 1 HCI 2 HCI n

Assemble 1,3 & 5 Air 1 Air 2 Air 3 Air q

Link Controller slot packet types as
Start Continue Continue Continue
appropriate

Radio modulation and transmission

Figure 7.4: Example of segmentation and fragment processes in a device with a BR/EDR Controller and
USB HCI Transport1

7.4 Delivery of erroneous L2CAP SDUs

Some applications may require corrupted or incomplete L2CAP SDUs to be delivered
to the upper layer. If delivery of erroneous L2CAP SDUs is enabled, the receiving side
will pass information to the upper layer on which parts of the L2CAP SDU (i.e., which
L2CAP frames) have been lost, failed the error check, or passed the error check. If
delivery of erroneous L2CAP SDUs is disabled, the receiver shall discard any L2CAP
SDU segment with any missing frames or any frames failing the error checks. L2CAP
SDUs whose SDU Length field (if provided) does not equal the sum of the segment
payload sizes shall also be discarded.

1For simplicity, the stripping of any additional HCI and USB specific information fields prior to the creation of
the Baseband packets (Air_1, Air_2, etc.) is not shown in the figure.

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 3, Part A Page 1182
Logical Link Control and Adaptation Protocol Specification

7.5 Operation with flushing On ACL-U logical links

In the L2CAP configuration using either the Flush Timeout option or the Extended Flow
Specification option, the Flush timeout may be set separately per L2CAP channel, but in
the BR/EDR Baseband, the flush mechanisms operate per ACL logical transport.

When there is more than one L2CAP channel mapped to the same ACL logical
transport, the automatic flush timeout does not discriminate between L2CAP channels.
The automatic flush timeout also applies to unicast data sent via the L2CAP
connectionless channel. The exception is packets marked as non-automatically-
flushable via the Packet_Boundary_Flag in the HCI ACL Data packet (see Section 1.1).
The automatic flush timeout flushes a specific automatically-flushable L2CAP PDU. The
HCI_Flush command flushes all outstanding L2CAP PDUs for the ACL logical transport
including L2CAP PDUs marked as non-automatically-flushable. Therefore, care has to
be taken when using the Automatic Flush Timeout and the HCI_Flush command. The
HCI_Enhanced_Flush command should be used instead.

All packets associated with a reliable connection shall be marked as non-automatically-

flushable (if it is mapped to an ACL logical transport with a finite automatic flush
timeout) or L2CAP Enhanced Retransmission mode or Retransmission mode shall be
used. In Enhanced Retransmission mode or Retransmission mode, loss of flushed
L2CAP PDUs on the channel is detected by the L2CAP ARQ mechanism and they are
retransmitted. L2CAP Enhanced Retransmission mode or Retransmission mode can be
used for other purposes such as the need for a residual error rate that is much smaller
than the Baseband can deliver. In this situation L2CAP Enhanced Retransmission mode
or Retransmission mode and the Non-Flushable Packet Boundary Flag feature can be
used at the same time.

If it is desired to send unicast data via the L2CAP connectionless channel which is
not subject to automatic flushing, then the data should be marked as non-automatically
flushable if it is mapped to an ACL logical transport with a finite automatic flush timeout.
Unicast data sent via the L2CAP connectionless channel may be marked flushable.

There is only one automatic flush timeout setting per ACL logical transport. Therefore,
all time bounded L2CAP channels on an ACL logical transport with an automatic flush
timeout setting should configure the same flush timeout value at the L2CAP level. The
flush timeout setting for the ACL logical transport also applies to unicast data sent via
the L2CAP connectionless channel which are marked flushable.

If Automatic Flush Timeout is used, then it should be taken into account that it only
flushes one L2CAP PDU. If one PDU has timed out and needs flushing, then other
automatically-flushable packets on the same logical transport are also likely to need
flushing. Therefore, flushing can be handled by the HCI_Enhanced_Flush command so
that all outstanding automatically-flushable L2CAP PDUs are flushed.

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 3, Part A Page 1183
Logical Link Control and Adaptation Protocol Specification

When both reliable and isochronous data is to be sent over the same ACL logical
transport, an infinite Automatic Flush Timeout can be used. In this case the isochronous
data can be flushed using the HCI_Enhanced_Flush command with Packet_Type set to
“Automatically-Flushable Only,” thus preserving the reliable data.

7.6 Connectionless data channel

In addition to connection-oriented channels, L2CAP also provides a connectionless
channel. Data sent on the connectionless channel shall only be sent over the BR/EDR
radio. The connectionless channel allows broadcast transmissions from the Central to
all members of the piconet or unicast transmissions from either a Central or Peripheral
to a single remote device. Data sent through the connectionless channel is sent in a
best-effort manner. The connectionless channel provided by L2CAP has no quality of
service.

While L2CAP itself does not provide retransmission for data sent via the connectionless
channel, the Baseband does provide an ARQ scheme for unicast data (see [Vol 2] Part
B, Section 7.6). If a higher degree of reliability is desired for unicast data sent via the
connectionless L2CAP channel than is provided by the Baseband ARQ scheme then an
ARQ scheme should be implemented at a higher layer.

No acknowledgment is provided by the Baseband for broadcast transmissions and

hence broadcast transmissions sent via the connectionless L2CAP channel are
unreliable and hence might or might not reach each member of the piconet.

The receiving L2CAP entity may silently discard data received via the connectionless
L2CAP channel if the data packet is addressed to a PSM and no application is
registered to receive data on that PSM.

L2CAP does not provide flow control for either connection-oriented L2CAP channels
operating in Basic mode or for traffic on the connectionless L2CAP channel. Hence
if data received by L2CAP is not accepted by the target applications in a timely
manner, congestion can occur in a receiving L2CAP implementation. For connection-
oriented channels, the receiving L2CAP entity may elect to close a channel if the target
application for that channel does not accept the data in a timely manner. Since this
option is not available for unicast data received via the connectionless L2CAP channel,
the receiving L2CAP entity may instead elect to de-register the application receiving
the data or to disconnect the underlying physical link. An application shall be notified
if it is de-registered. If the underlying physical link is disconnected then all applications
utilizing that physical link shall be notified.

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 3, Part A Page 1184
Logical Link Control and Adaptation Protocol Specification

Unicast data shall only be sent via the connectionless L2CAP channel to a remote
device if the remote device indicates support for Unicast Connectionless Data
Reception in the L2CAP Extended Features Mask.1

The L2CAP Extended Features Mask should be retrieved using the

L2CAP_INFORMATION_REQ packet to determine if Unicast Connectionless Data
Reception is supported. Optionally, support for Unicast Connectionless Data Reception
can be inferred from information obtained via a SDP or EIR. For example, if a service
is found via SDP or EIR that is known to mandate the support of UCD, then it
may be assumed that the device indicating support for the service supports Unicast
Connectionless Data Reception.

Unicast data sent via the L2CAP connectionless channel are subject to automatic
flushing and hence the packet boundary flags should be set appropriately if the
Controller supports the Packet Boundary Flag feature. See Section 7.5 for further
details. Since the receiving L2CAP entity has no mechanism to enable it to know
whether received packets were originally marked as flushable or non-flushable on the
transmitting device, the receiving L2CAP entity should treat all unicast packets received
via the connectionless L2CAP packet as non-flushable.

If encryption is required for a given profile, then the profile or application shall ensure
that authentication is performed and encryption is enabled prior to sending any unicast
data on the connectionless L2CAP channel by utilizing Security mode 4 as defined in
GAP ([Vol 3] Part C, Section 5.2.2). There is no mechanism provided in the specification
to prevent reception of unencrypted data on the connectionless L2CAP channel. An
application which requires received data to be encrypted should ignore any unencrypted
data it may receive over the connectionless channel.

Broadcast transmissions to the connectionless channel are sent with the broadcast
LT_ADDR and hence may be received by any of the Peripherals in the piconet. If it
is desirable to restrict the reception of the transmitted data to only a subset of the
Peripherals in the piconet, then higher level encryption may be used to support private
communication.

The Central will not receive transmissions broadcast on the connectionless channel.
Therefore, higher layer protocols must loopback any broadcast data traffic being sent to
the Central if required.

The connectionless data channel shall not be used with Enhanced Retransmission
mode, Retransmission mode or Flow Control mode.

1The Unicast Connectionless Data Reception bit in the L2CAP Extended Features Mask does not in any way
indicate support or lack of support for reception of broadcast data on the connectionless L2CAP channel
even though both broadcast data and unicast data are sent and received using the same CID (0x0002).
For historical reasons, there is no bit to indicate support for sending or receiving of broadcast data on the
connectionless L2CAP channel.

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 3, Part A Page 1185
Logical Link Control and Adaptation Protocol Specification

7.7 Operation collision resolution

When two devices request the same operation by sending a request packet with the
same code, a collision can occur. Some operations require collision resolution. The
description of each operation in Section 4 will indicate if collision resolution is required.
Both devices must know which request will be rejected. The following algorithm shall be
used by both devices to determine which request to reject.

1. Set i=0 (representing the least significant octet of the BD_ADDR).

2. Compare the octet[i] of the BD_ADDR of both devices. If the octets are not equal
go to step 4.
3. Increment i by 1. Go to step 2.
4. The device with the larger BD_ADDR octet shall reject the request from the other
device.

7.8 [This section is no longer used]

7.9 Prioritizing data over HCI

In order for Guaranteed channels to meet their guarantees, L2CAP should prioritize
traffic over the HCI transport in devices that support HCI. Packets for Guaranteed
channels should receive higher priority than packets for Best Effort channels.

7.10 Supporting Extended Flow Specification for BR/EDR and

BR/EDR/LE Controllers

If both the local L2CAP entity and the remote L2CAP entity indicate support for
Extended Flow Specification for BR/EDR in the Extended Feature Mask then all
channels created between the two devices shall send an Extended Flow Specification
option and shall use the Lockstep configuration procedure. In addition all channels shall
use Enhanced Retransmission mode or Streaming mode. If one or both L2CAP entities
do not indicate support for Extended Flow Specification for BR/EDR in the Extended
Feature Mask then the Lockstep configuration procedure shall not be used and the
Extended Flow Specification option shall not be sent for channels created over the
ACL-U logical link between the two devices.

The L2CAP entity shall perform admission control for Guaranteed channels during the
Lockstep configuration procedure (see Section 7.1.3). Admission control is performed
to determine if the requested Guaranteed QoS can be achieved by the BR/EDR
or BR/EDR/LE Controller over an ACL-U logical link without compromising existing
Guaranteed channels running on the Controller. If HCI is used then the L2CAP entity
shall also verify that the QoS can be achieved over the HCI transport.

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 3, Part A Page 1186
Logical Link Control and Adaptation Protocol Specification

In performing admission control the L2CAP layer shall reject a Guaranteed QoS request
that causes at least one of the following rules to be violated.

• The total guaranteed data rate in both directions shall not exceed two times the
highest Symmetric Max of an ACL-U logical link over the BR/EDR or BR/EDR/LE
Controller (see [Vol 2] Part B, Section 6.7). For example, for a Basic Rate Controller
the highest Symmetric Max Rate is 433.9 kb/s (DH5) from [Vol 2] Part B, Table 6.8.
Two times that value is 867.8 kb/s.
• The total guaranteed data rate in any one direction shall not exceed the highest
Asymmetric Max Rate of an ACL-U logical link (see [Vol 2] Part B, Section 6.7). For
example, the highest Asymmetric Max Rate for Basic Rate is 723.2 kb/s (DH5 packet)
from [Vol 2] Part B, Table 6.8.

The data rate of a Guaranteed channel is calculated by dividing the Maximum SDU
size in an Extended Flow Specification by the SDU Inter-arrival time. Total guaranteed
data rate in both directions is calculated by taking the sum of the data rates in both
directions for all existing Guaranteed channels plus the data rate in both directions of
the requested Guaranteed channel (i.e. data rates from the both outgoing and incoming
Extended Flow Specifications). Total guaranteed data rate for one direction is calculated
by taking the sum of the data rates in one direction for all existing Guaranteed channels
plus the data rate in the same direction of the requested Guaranteed channel.

An L2CAP entity should use additional information for admission control that may result
in a Guaranteed QoS request being rejected even if none of the rules are violated. This
allows the L2CAP entity to account for things such as CQDDR, SCO/eSCO channels,
LMP traffic, page scanning, etc.

In order to meet the access latency and/or data rate required by a Guaranteed channel,
the L2CAP entity should:

• Prioritize traffic over the HCI transport in devices that support HCI.
• Give conformant packets for Guaranteed channels higher priority than packets for
Best Effort channels. Packets for Best Effort channels should have higher priority than
non-conformant packets for Guaranteed channels. (See Section 5.6 for a discussion
of non-conformant and conformant traffic).
• Utilize the SAR feature to restrict the PDU sizes of Best Effort SDUs so that they do
not prevent the Controller from sending the SDUs of the Guaranteed channel within
the time periods required by its Extended Flow Specification.

When a channel is reconfigured the Lockstep configuration process is

only used when an Extended Flow Specification option is present in the
L2CAP_CONFIGURATION_REQ packet as described in Section 7.1.3.

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 3, Part A Page 1187
Logical Link Control and Adaptation Protocol Specification

7.11 Enhanced Credit-Based Flow Control Reconfiguration

In Enhanced Credit Based Flow Control mode, each individual channel has its own
MTU and MPS; both of these values can be reconfigured independently.

To perform reconfiguration, a device shall send an

L2CAP_CREDIT_BASED_RECONFIGURE_REQ packet to the peer device with the
new proposed MTU and MPS values and a set of channels to be reconfigured. The
request shall not decrease the MTU of any channel and shall not decrease the MPS of
a channel if more than one channel is specified.

When an L2CAP_CREDIT_BASED_RECONFIGURE_REQ packet is received and

all the parameters are valid, the recipient shall complete sending all existing
PDUs that require an MPS larger than the new MPS value for the channel
in the L2CAP_CREDIT_BASED_RECONFIGURE_REQ packet and then send the
L2CAP_CREDIT_BASED_RECONFIGURE_RSP packet, with a zero Result field, to the
peer device.

After the L2CAP_CREDIT_BASED_RECONFIGURE_RSP packet is sent,

the MTU and MPS values of the channels included in the
L2CAP_CREDIT_BASED_RECONFIGURE_REQ packet shall be set to the MTU and
MPS fields from that packet, and new SDUs shall be sent using the new MTU and MPS
values.

When an L2CAP_CREDIT_BASED_RECONFIGURE_REQ packet is

received with invalid parameters, the recipient shall send an
L2CAP_CREDIT_BASED_RECONFIGURE_RSP PDU with a non-zero Result field and
not change any MTU and MPS values.

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 3, Part A Page 1188
Logical Link Control and Adaptation Protocol Specification

8 PROCEDURES FOR FLOW CONTROL AND

RETRANSMISSION

When Enhanced Retransmission mode, Streaming mode, Flow Control mode, or

Retransmission mode is used, the procedures defined in this section shall be used,
including the numbering of information frames, the handling of SDU segmentation and
reassembly, and the detection and notification of frames with errors. Retransmission
mode and Enhanced Retransmission mode also allow the sender to resend frames with
errors on request from the receiver.

8.1 Information retrieval

Before attempting to configure Enhanced Retransmission mode, Streaming mode, Flow
Control mode, or Retransmission mode on a channel, support for the suggested mode
shall be verified by performing an information retrieval for the “Extended features
supported” information type (0x0002). If the information retrieval is not successful or
the “Extended features mask” bit is not set for the wanted mode, the mode shall not be
suggested in a configuration request.

8.2 Function of PDU Types for Flow Control and Retransmission

Two frame formats are defined for Enhanced Retransmission mode, Streaming mode,
Flow Control mode, and Retransmission mode (see Section 3.3). The I-frame is used to
transport user information instead of the B-frame. The S-frame is used for supervision.

8.2.1 Information frame (I-frame)

I-frames are sequentially numbered frames containing information fields. I-frames also
include some of the functionality of RR frames (see below).

8.2.2 Supervisory frame (S-frame)

The S-frame is used to control the transmission of I-frames. For Retransmission mode
and Flow Control mode, the S-frame has two formats: Receiver Ready (RR) and Reject
(REJ). A description of how S-frames are used in Enhanced Retransmission mode
is given in Section 8.6.1. S-frames are not used in Streaming mode. The following
description of S-frames only applies to Retransmission mode and Flow Control mode.

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 3, Part A Page 1189
Logical Link Control and Adaptation Protocol Specification

8.2.2.1 Receiver Ready (RR)

The receiver ready (RR) S-frame is used to:

1. Acknowledge I-frames numbered up to and including ReqSeq - 1.

2. Enable or disable retransmission of I-frames by updating the receiver with the
current status of the Retransmission Disable Bit.

The RR frame has no information field.

8.2.2.2 Reject (REJ)

The reject (REJ) S-frame is used to request retransmission of all I-frames starting with
the I-frame with TxSeq equal to ReqSeq specified in the REJ. The value of ReqSeq
in the REJ frame acknowledges I-frames numbered up to and including ReqSeq - 1.
I-frames that have not been transmitted, shall be transmitted following the retransmitted
I-frames.

When a REJ is transmitted, it triggers a REJ Exception condition. A second REJ frame
shall not be transmitted until the REJ Exception condition is cleared. The receipt of an
I-frame with a TxSeq equal to the ReqSeq of the REJ frame clears the REJ Exception.
The REJ Exception condition only applies to traffic in one direction.

Note: This means that only valid I-frames can be rejected.

8.3 Variables and sequence numbers

The sending peer uses the following variables and sequence numbers:

• TxSeq – the send sequence number used to sequentially number each new I-frame
transmitted.
• NextTxSeq – the sequence number to be used in the next new I-frame transmitted.
• ExpectedAckSeq – the sequence number of the next I-frame expected to be
acknowledged by the receiving peer.

The receiving peer uses the following variables and sequence numbers:

• ReqSeq – The sequence number sent in an acknowledgment frame to request

transmission of I-frame with TxSeq = ReqSeq and acknowledge receipt of I-frames up
to and including (ReqSeq-1).
• ExpectedTxSeq – the value of TxSeq expected in the next I-frame.
• BufferSeq – When segmented I-frames are buffered this is used to delay
acknowledgment of received I-frame so that new I-frame transmissions do not cause
buffer overflow.

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 3, Part A Page 1190
Logical Link Control and Adaptation Protocol Specification

All variables have the range 0 to 63. Arithmetic operations on state variables
(NextTXSeq, ExpectedTxSeq, ExpectedAckSeq, BufferSeq) and sequence numbers
(TxSeq, ReqSeq) contained in this document shall be taken mod 64.

8.3.1 Sending peer

8.3.1.1 Send sequence number TxSeq

I-frames contain TxSeq, the send sequence number of the I-frame. When an I-frame is
first transmitted, TxSeq is set to the value of the send state variable NextTXSeq. TxSeq
is not changed if the I-frame is retransmitted.

8.3.1.2 Send state variable NextTXSeq

The CID sent in the information frame is the destination CID and identifies the remote
endpoint of the channel. A send state variable NextTxSeq shall be maintained for each
remote endpoint. NextTxSeq is the sequence number of the next in-sequence I-frame
to be transmitted to that remote endpoint. When the link is created NextTXSeq shall be
initialized to 0.

The value of NextTxSeq shall be incremented by 1 after each in-sequence I-frame

transmission, and shall not exceed ExpectedAckSeq by more than the maximum
number of outstanding I-frames (TxWindow). The value of TxWindow shall be in the
range 1 to 32 for Retransmission mode and Flow Control mode. The value of TxWindow
shall be in the range 1 to 63 for Enhanced Retransmission mode.

8.3.1.3 Acknowledge state variable ExpectedAckSeq

The CID sent in the information frame is the destination CID and identifies the remote
endpoint of the channel. An acknowledge state variable ExpectedAckSeq shall be
maintained for each remote endpoint. ExpectedAckSeq is the sequence number of the
next in-sequence I-frame that the remote receiving peer is expected to acknowledge.
(ExpectedAckSeq – 1 equals the TxSeq of the last acknowledged I-frame). When the
link is created ExpectedAckSeq shall be initialized to 0.

Note: If the next acknowledgment acknowledges a single I-frame then its ReqSeq will
be expectedAckSeq + 1.

If a valid ReqSeq is received from the peer then ExpectedAckSeq is set to ReqSeq.
A valid ReqSeq value is one that is in the range ExpectedAckSeq ≤ ReqSeq ≤
NextTxSeq.

Note: The comparison with NextTXSeq must be ≤ in order to handle the situations
where there are no outstanding I-frames.

These inequalities shall be interpreted in the following way: ReqSeq is valid, if and
only if (ReqSeq-ExpectedAckSeq) mod 64 ≤ (NextTXSeq-ExpectedAckSeq) mod 64.

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 3, Part A Page 1191
Logical Link Control and Adaptation Protocol Specification

Furthermore, from the description of NextTXSeq, it can be seen that (NextTXSeq-

ExpectedAckSeq) mod 64 ≤ TxWindow.

ExpectedAckSeq NextTxSeq
TxWindow

F1 F2 F3 F4 F5 F6 F7 F8 F9

Transmitted and Not yet

acknowledged transmitted
Transmitted but
not yet Upon transmission:
acknowledged ReqSeq = ExpectedTxSeq;
TxSeq = NextTxSeq;
INC(NextTxSeq);

Figure 8.1: Example of the transmitter side

Figure 8.1 shows TxWindow=5, and three frames awaiting transmission. The frame with
number F7 may be transmitted when the frame with F2 is acknowledged. When the
frame with F7 is transmitted, TxSeq is set to the value of NextTXSeq. After TxSeq has
been set, NextTxSeq is incremented by one.

The sending peer expects to receive valid ReqSeq values, which are in the range
ExpectedAckSeq to NextTxSeq. Upon receipt of a ReqSeq value equal to the current
NextTxSeq all outstanding I-frames have been acknowledged by the receiver.

8.3.2 Receiving peer

8.3.2.1 Receive sequence number ReqSeq

All I-frames and S-frames contain ReqSeq, the send sequence number (TxSeq) that the
receiving peer requests in the next I-frame.

When an I-frame or an S-frame is transmitted, the value of ReqSeq shall be set

to the current value of the receive state variable ExpectedTxSeq or the buffer state
variable BufferSeq. The value of ReqSeq shall indicate that the data Link Layer
entity transmitting the ReqSeq has correctly received all I-frames numbered up to and
including ReqSeq – 1.

Note: The option to set ReqSeq to BufferSeq instead of ExpectedTxSeq allows the
receiver to impose flow control for buffer management or other purposes. In this
situation, if BufferSeq<>ExpectedTxSeq, the receiver should also set the retransmission
disable bit to 1 to prevent unnecessary retransmissions.

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 3, Part A Page 1192
Logical Link Control and Adaptation Protocol Specification

8.3.2.2 Receive state variable ExpectedTxSeq

Each channel shall have a receive state variable (ExpectedTxSeq). The receive state
variable is the sequence number (TxSeq) of the next in-sequence I-frame expected.

The value of the receive state variable shall be the last in-sequence, valid I-frame
received.

8.3.2.3 Buffer state variable BufferSeq

Each channel may have an associated BufferSeq. BufferSeq is used to delay

acknowledgment of frames until they have been pulled by the upper layers, thus
preventing buffer overflow. BufferSeq and ExpectedTxSeq are equal when there is no
extra segmentation performed and frames are pushed to the upper layer immediately
on reception. When buffer space is scarce, for example when frames reside in the
buffer for a period, the receiver may choose to set ReqSeq to BufferSeq instead of
ExpectedTxSeq, incrementing BufferSeq as buffer space is released. The windowing
mechanism will ensure that transmission is halted when ExpectedTxSeq - BufferSeq is
equal to TxWindow.

Note: Owing to the variable size of I-frames, updates of BufferSeq may be based on
changes in available buffer space instead of delivery of I-frame contents.

I-frames shall have sequence numbers in the range ExpectedTxSeq ≤ TxSeq <
(BufferSeq + TxWindow).

On receipt of an I-frame with TxSeq equal to ExpectedTxSeq, ExpectedTxSeq shall

be incremented by one regardless of how many I-frames with TxSeq greater than
ExpectedTxSeq were previously received.

BufferSeq
ExpectedTxSeq Invalid TxSeq
values
TxWindow

F1 F2 F3 F4 F5 F6 F7 F8 F9

Received and Valid TxSeq Received but not

pulled by values yet pulled by
reassembly function reassembly function

Figure 8.2: Example of the receiver side

Figure 8.2 shows TxWindow=5. F1 is successfully received and pulled by the upper
layer. BufferSeq shows that F2 is the next I-frame to be pulled, and ExpectedTxSeq

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 3, Part A Page 1193
Logical Link Control and Adaptation Protocol Specification

points to the next I-frame expected from the peer. An I-frame with TxSeq equal to 5 has
been received thus triggering an SREJ or REJ exception. The star indicates I-frames
received but discarded owing to the SREJ or REJ exception. They will be resent as part
of the error recovery procedure.

In Figure 8.2 there are several I-frames in a buffer awaiting the SDU reassembly
function to pull them and the TxWindow is full. The receiver would usually disable
retransmission in Retransmission mode or Flow Control mode by setting the
Retransmission Disable Bit to 1 and send an RR back to the sending side. This
tells the transmitting peer that there is no point in performing retransmissions. Both
sides will send S-frames to make sure the peer entity knows the current value of the
Retransmission Disable Bit.

8.4 Retransmission mode

8.4.1 Transmitting frames

A new I-frame shall only be transmitted when the TxWindow is not full. No I-frames shall
be transmitted if the last RetransmissionDisableBit (R) received is set to one.

A previously transmitted I-frame may be retransmitted as a result of an error recovery

procedure, even if the TxWindow is full. When an I-frame is retransmitted it shall always
be sent with the same TxSeq value used in its initial transmission.

The state of the RetransmissionDisableBit (R) is stored and used along with the
state of the RetransmissionTimer to decide the actions when transmitting I-frames.
The RetransmissionTimer is running whenever I-frames have been sent but not
acknowledged.

8.4.1.1 Last received R was set to zero

If the last R received was set to zero, then I-frames may be transmitted. If there are any
I-frames which have been sent and not acknowledged then they shall be retransmitted
when the RetransmissionTimer elapses. If the retransmission timer has not elapsed
then a retransmission shall not be sent and only new I-frames may be sent.

• If unacknowledged I-frames have been sent and the RetransmissionTimer

has elapsed, then an unacknowledged I-frame shall be retransmitted. The
RetransmissionTimer shall be restarted.
• If unacknowledged I-frames have been sent but the Retransmission timer has not
elapsed, then a new I-frame shall be sent if one is waiting and no timer action shall be
taken.
• If no unacknowledged I-frames have been sent and a new I-frame is waiting, then the
new I-frame shall be sent, the RetransmissionTimer shall be started, and the Monitor
Timer shall be stopped if it is running.

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 3, Part A Page 1194
Logical Link Control and Adaptation Protocol Specification

• If no unacknowledged I-frames have been sent, no new I-frames are waiting to be

transmitted, and the RetransmissionTimer is running, then the retransmission timer
shall be stopped and the monitor timer shall be started.

Table 8.1 summarizes actions when the RetransmissionTimer is in use and R=0.

Unacknowledged Retransmission New Transmit Action Timer Action

I‑frames sent Timer has I‑frames
= Retransmission elapsed are waiting
Timer is running
True True True or Retransmit un- Restart Retrans-
False acknowledged mission Timer
I‑frame
True False True Transmit new No timer action
I‑frame
True False False No transmit ac- No Timer action
tion
False False True Transmit new Restart Retrans-
I‑frame mission Timer
False False False No Transmit ac- If MonitorTimer is
tion not running then re-
start MonitorTimer

Table 8.1: Summary of actions when the RetransmissionTimer is in use and R=0

If the RetransmissionTimer is not in use, no unacknowledged I-frames have been sent

and no new I-frames are waiting to be transmitted

• If the MonitorTimer is running and has not elapsed, then no transmit action shall be
taken and no timer action shall be taken.
• If the MonitorTimer has elapsed, then an S-frame shall be sent and the MonitorTimer
shall be restarted.

If any I-frames become available for transmission, then the MonitorTimer shall be
stopped, the RetransmissionTimer shall be started, and the rules for when the
RetransmissionTimer is in use shall be applied.

When an I-frame is sent ReqSeq shall be set to ExpectedTxSeq, TxSeq shall be set to
NextTxSeq and NextTxSeq shall be incremented by one.

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 3, Part A Page 1195
Logical Link Control and Adaptation Protocol Specification

8.4.1.2 Last received R was set to one

If the last R received was set to one, then I-frames shall not be transmitted. The only
frames which may be sent are S-frames. An S-frame shall be sent according to the
rules below:

• If the MonitorTimer is running and has not elapsed, then no transmit action shall be
taken and no timer action shall be taken.
• If the MonitorTimer has elapsed, then an S-frame shall be sent and the MonitorTimer
shall be restarted.

8.4.2 Receiving I-frames

Upon receipt of a valid I-frame with TxSeq equal to ExpectedTxSeq, the frame shall be
accepted for the SDU reassembly function. ExpectedTxSeq is used by the reassembly
function.

The first valid I-frame received after an REJ was sent, with a TxSeq of the received
I-frame equal to ReqSeq of the REJ, shall clear the REJ Exception condition.

The ReqSeq shall be processed according to Section 8.4.6.

If a valid I-frame with TxSeq ≠ ExpectedTxSeq is received then an exception condition

shall be triggered which is handled according to Section 8.4.7.

8.4.3 I-frames pulled by the SDU reassembly function

When the L2CAP layer has removed one or more I-frames from the buffer, BufferSeq
may be incremented in accordance with the amount of buffer space released. If
BufferSeq is incremented, an acknowledgment shall be sent to the peer entity.

Note: Since the primary purpose of BufferSeq is to prevent buffer overflow, an

implementation may choose to set BufferSeq in accordance with how many new
incoming I-frames could be stored rather than how many have been removed.

The acknowledgment may either be an RR or an I-frame. The acknowledgment shall

be sent to the peer L2CAP entity with ReqSeq equal to BufferSeq. When there are no
I-frames buffered for pulling ExpectedTxSeq is equal to BufferSeq.

If the MonitorTimer is active then it shall be restarted to indicate that a signal has been
sent to the peer L2CAP entity.

8.4.4 Sending and receiving acknowledgments

Either the MonitorTimer or the RetransmissionTimer shall be active while in

Retransmission mode. Both timers shall not be active concurrently.

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 3, Part A Page 1196
Logical Link Control and Adaptation Protocol Specification

8.4.4.1 Sending acknowledgments

Whenever an L2CAP entity transmits an I-frame or an S-frame, ReqSeq shall be set to

ExpectedTxSeq or BufferSeq.

8.4.4.2 Receiving acknowledgments

On receipt of a valid S-frame or I-frame, the ReqSeq contained in the frame shall
acknowledge previously transmitted I-frames. ReqSeq acknowledges I-frames with a
TxSeq up to and including ReqSeq – 1.

The following rules shall be applied:

1. If the RetransmissionDisableBit changed value from 0 to 1 (stop retransmissions)

then the receiving entity shall
a. If the RetransmissionTimer is running then stop it and start the MonitorTimer.
b. Store the state of the RetransmissionDisableBit received.
2. If the RetransmissionDisableBit changed value from 1 to 0 (start retransmissions)
then the receiving entity shall
a. Store the state of the RetransmissionDisableBit received.
b. If there are any I-frames that have been sent but not acknowledged, then stop
the MonitorTimer and start the RetransmissionTimer.
c. Any buffered I-frames shall be transmitted according to Section 8.4.1.
3. If any unacknowledged I-frames were acknowledged by the ReqSeq contained in
the frame, and the RetransmissionDisableBit equals 1 (retransmissions stopped),
then the receiving entity shall
a. Follow the rules in Section 8.4.1.
4. If any unacknowledged I-frames were acknowledged by the ReqSeq contained
in the frame and the RetransmissionDisableBit equals 0 (retransmissions started)
then the receiving entity shall
a. If the RetransmissionTimer is running, then stop it.
b. If any unacknowledged I-frames have been sent then the RetransmissionTimer
shall be restarted.
c. Follow the rules in Section 8.4.1.
d. If the RetransmissionTimer is not running and the MonitorTimer is not running,
then start the MonitorTimer.

On receipt of a valid S-frame or I-frame the ReqSeq contained in the frame shall
acknowledge previously transmitted I-frames. ExpectedAckSeq shall be set to ReqSeq

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 3, Part A Page 1197
Logical Link Control and Adaptation Protocol Specification

to indicate that the I-frames with TxSeq up to and including (ReqSeq - 1) have been
acknowledged.

8.4.5 Receiving REJ frames

Upon receipt of a valid REJ frame, where ReqSeq identifies an I-frame not yet
acknowledged, the ReqSeq acknowledges I-frames with TxSeq up to and including
ReqSeq - 1. Therefore the REJ acknowledges all I-frames before the I-frame it is
rejecting.

ExpectedAckSeq shall be set equal to ReqSeq to mark I-frames up to and including

ReqSeq - 1 as received.

NextTXSeq shall be set to ReqSeq to cause transmissions of I-frames to resume from

the point where TxSeq equals ReqSeq.

If ReqSeq equals ExpectedAckSeq then the REJ frame shall be ignored.

8.4.6 Waiting acknowledgments

A counter, TransmitCounter, counts the number of times an L2CAP PDU has been
transmitted. This shall be set to 1 after the first transmission. If the RetransmissionTimer
expires the following actions shall be taken:

1. If the TransmitCounter is less than MaxTransmit then:

a. Increment the TransmitCounter by one.
b. Retransmit the last unacknowledged I-frame, according to Section 8.4.1.
2. If the TransmitCounter is equal to MaxTransmit this channel to the peer entity shall
be assumed lost. The channel shall move to the CLOSED state and appropriate
action shall be taken to report this to the upper layers.

8.4.7 Exception conditions

Exception conditions may occur as the result of physical layer errors or L2CAP
procedural errors. The error recovery procedures which are available following the
detection of an exception condition at the L2CAP layer in Retransmission mode are
defined in this section.

8.4.7.1 TxSeq sequence error

A TxSeq sequence error exception condition occurs in the receiver when a valid I-frame
is received which contains a TxSeq value which is not equal to the expected value, thus
TxSeq is not equal to ExpectedTxSeq.

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 3, Part A Page 1198
Logical Link Control and Adaptation Protocol Specification

The TxSeq sequence error may be due to three different causes:

• Duplicated I-frame
The duplicated I-frame is identified by a TxSeq in the range BufferSeq to
ExpectedTxSeq – 1 (BufferSeq ≤TxSeq<ExpectedTxSeq). The ReqSeq and
RetransmissionDisableBit shall be processed according to Section 8.4.4. The
Information field shall be discarded since it has already been received.
• Out-of-sequence I-frame
The out-of-sequence I-frame is identified by a TxSeq within the valid range. The
ReqSeq and RetransmissionDisableBit shall be processed according to Section 8.4.4.
A REJ exception is triggered, and an REJ frame with ReqSeq equal to
ExpectedTxSeq shall be sent to initiate recovery. The received I-frame shall be
discarded.
• Invalid TxSeq
An invalid TxSeq value is a value that does not meet either of the above conditions.
An I-frame with an invalid TxSeq is likely to have errors in the control field and shall
be silently discarded.

8.4.7.2 ReqSeq sequence error

An ReqSeq sequence error exception condition occurs in the transmitter when a valid
S-frame or I-frame is received which contains an invalid ReqSeq value. An invalid
ReqSeq is one that is not in the range ExpectedAckSeq ≤ ReqSeq ≤ NextTxSeq.

The L2CAP entity shall close the channel as a consequence of an ReqSeq Sequence
error.

8.4.7.3 Timer recovery error

If an L2CAP entity fails to receive an acknowledgment for the last I-frame sent, then it
will not detect an out-of-sequence exception condition and therefore will not transmit an
REJ frame.

The L2CAP entity that transmitted an unacknowledged I-frame shall, on the expiry of
the RetransmissionTimer, take appropriate recovery action as defined in Section 8.4.6.

8.4.7.4 Invalid frame

Any frame received which is invalid (as defined in Section 3.3.6) shall be discarded, and
no action shall be taken as a result of that frame.

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 3, Part A Page 1199
Logical Link Control and Adaptation Protocol Specification

8.5 Flow Control mode

When a link is configured to work in flow control mode, the flow control operation is
similar to the procedures in retransmission mode, but all operations dealing with CRC
errors in received packets are not used. Therefore

• REJ frames shall not be used in Flow Control mode.

• The RetransmissionDisableBit shall always be set to zero in the transmitter, and shall
be ignored in the receiver.

The behavior of flow control mode is specified in this section.

Assuming that the TxWindow size is equal to the buffer space available in the receiver
(counted in number of I-frames), in flow control mode the number of unacknowledged
frames in the transmitter window is always less than or equal to the number of frames
for which space is available in the receiver.

Note: A missing frame still occupies a place in the window.

Missing ExpectedTxSeq
(lost or BufferSeq
corrupted) Invalid TxSeq
I-frame values
TxWindow

1 2 3 4 5 6 7 8 9

Received and Valid TxSeq Received but not

pulled by values yet pulled by
reassembly function reassembly function

Figure 8.3: Overview of the receiver side when operating in Flow Control mode

8.5.1 Transmitting I-frames

A new I-frame shall only be transmitted when the TxWindow is not full.

Upon transmission of the I-frame the following actions shall be performed:

• If no unacknowledged I-frames have been sent then the MonitorTimer shall be

stopped and the RetransmissionTimer shall be started.
• If any I-frames have been sent and not acknowledged then the RetransmissionTimer
remains active and no timer operation is performed.

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 3, Part A Page 1200
Logical Link Control and Adaptation Protocol Specification

The control field parameter ReqSeq shall be set to ExpectedTxSeq, TxSeq shall be set
to NextTXSeq and NextTXSeq shall be incremented by one.

8.5.2 Receiving I-frames

Upon receipt of a valid I-frame with TxSeq equal to ExpectedTxSeq, the frame shall
be made available to the reassembly function. ExpectedTxSeq shall be incremented by
one. An acknowledgment shall not be sent until the SDU reassembly function has pulled
the I-frame.

Upon receipt of a valid I-frame with an out-of-sequence TxSeq (see Section 8.5.6) all
frames with a sequence number less than TxSeq shall be assumed lost and marked
as missing. The missing I-frames are in the range from ExpectedTxSeq (the frame that
the device was expecting to receive) up to TxSeq-1, (the frame that the device actually
received). ExpectedTxSeq shall be set to TxSeq +1. The received I-frame shall be
made available for pulling by the reassembly function. The acknowledgment shall not
occur until the SDU reassembly function has pulled the I-frame. The ReqSeq shall be
processed according to Section 8.5.4.

8.5.3 I-frames pulled by the SDU reassembly function

When the L2CAP layer has removed one or more I-frames from the buffer, BufferSeq
may be incremented in accordance with the amount of buffer space released. If
BufferSeq is incremented, an acknowledgment shall be sent to the peer entity. If the
MonitorTimer is active then it shall be restarted to indicate that a signal has been sent to
the peer L2CAP entity.

Note: Since the primary purpose of BufferSeq is to prevent buffer overflow, an

implementation may choose to set BufferSeq in accordance with how many new
incoming I-frames could be stored rather than how many have been removed.

The acknowledgment may be an RR or an I-frame. The acknowledgment shall be sent

to the peer L2CAP entity with ReqSeq equal to BufferSeq. When there is no I-frame
buffered for pulling, ExpectedTxSeq is equal to BufferSeq.

8.5.4 Sending and receiving acknowledgments

One of the timers MonitorTimer or RetransmissionTimer shall always be active while in

Flow Control mode. Both timers shall never be active concurrently.

8.5.4.1 Sending acknowledgments

Whenever a data Link Layer entity transmits an I-frame or a S-frame, ReqSeq shall be
set to ExpectedTxSeq or BufferSeq.

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 3, Part A Page 1201
Logical Link Control and Adaptation Protocol Specification

8.5.4.2 Receiving acknowledgments

On receipt of a valid S-frame or I-frame the ReqSeq contained in the frame shall be
used to acknowledge previously transmitted I-frames. ReqSeq acknowledges I-frames
with a TxSeq up to and including ReqSeq – 1.

1. If any outstanding I-frames were acknowledged then

a. Stop the RetransmissionTimer
b. If there are still unacknowledged I-frames then restart the
RetransmissionTimer, otherwise start the MonitorTimer.
c. Transmit any I-frames awaiting transmission according to Section 8.5.1.

ExpectedAckSeq shall be set to ReqSeq to indicate that the I-frames with TxSeq up to
and including ExpectedAckSeq have been acknowledged.

8.5.5 Waiting acknowledgments

If the RetransmissionTimer expires the following actions shall be taken:

The I-frame supervised by the RetransmissionTimer shall be considered lost, and

ExpectedAckSeq shall be incremented by one.

1. If I-frames are waiting to be sent

a. the RetransmissionTimer is restarted.
b. I-frames awaiting transmission are transmitted according to Section 8.5.1.
2. If there are no I-frames waiting to be sent
a. If there are still unacknowledged I-frames the RetransmissionTimer is
restarted, otherwise the MonitorTimer is started.

8.5.6 Exception conditions

Exception conditions may occur as the result of physical layer errors or L2CAP
procedural errors. The error recovery procedures which are available following the
detection of an exception condition at the L2CAP layer in flow control only mode are
defined in this section.

8.5.6.1 TxSeq sequence error

A TxSeq sequence error exception condition occurs in the receiver when a valid I-frame
is received which contains a TxSeq value which is not equal to the expected value, thus
TxSeq is not equal to ExpectedTxSeq.

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 3, Part A Page 1202
Logical Link Control and Adaptation Protocol Specification

The TxSeq sequence error may be due to three different causes:

• Duplicated I-frame
The duplicated I-frame is identified by a TxSeq in the range BufferSeq to
ExpectedTxSeq – 1. The ReqSeq shall be processed according to Section 8.5.4.
The Information field shall be discarded since it has already been received.
• Out-of-sequence I-frame
The out-of-sequence I-frame is identified by a TxSeq such that ExpectedTxSeq <
TxSeq < (BufferSeq + TxWindow). The ReqSeq shall be processed according to
Section 8.5.4.
The missing I-frame(s) are considered lost and ExpectedTXSeq is set equal to
TxSeq+1 as specified in Section 8.5.2. The missing I-frame(s) are reported as lost
to the SDU reassembly function.
• Invalid TxSeq
An invalid TxSeq value is a value that does not meet either of the above conditions
and TxSeq is not equal to ExpectedTxSeq. An I-frame with an invalid TxSeq is likely
to have errors in the control field and shall be silently discarded.

8.5.6.2 ReqSeq sequence error

An ReqSeq sequence error exception condition occurs in the transmitter when a valid
S-frame or I-frame is received which contains an invalid ReqSeq value. An invalid
ReqSeq is one that is not in the range ExpectedAckSeq ≤ ReqSeq ≤ NextTXSeq.

The L2CAP entity shall close the channel as a consequence of an ReqSeq Sequence
error.

An L2CAP entity that fails to receive an acknowledgment for an I-frame shall, on

the expiry of the RetransmissionTimer, take appropriate recovery action as defined in
Section 8.5.5.

8.5.6.3 Invalid frame

Any frame received that is invalid (as defined in Section 3.3.6) shall be discarded, and
no action shall be taken as a result of that frame, unless the receiving L2CAP entity is
configured to deliver erroneous frames to the layer above L2CAP. In that case, the data
contained in invalid frames may also be added to the receive buffer and made available
for pulling from the SDU reassembly function.

8.6 Enhanced Retransmission mode

Enhanced Retransmission mode operates as an HDLC balanced data link operational
mode. Either L2CAP entity may send frames at any time without receiving explicit

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 3, Part A Page 1203
Logical Link Control and Adaptation Protocol Specification

permission from the other L2CAP entity. A transmission may contain single or multiple
frames and shall be used for I-frame transfer and/or to indicate status change.

8.6.1 Function of PDU types

Enhanced Retransmission mode uses I-frames to transfer upper layer information and
S-frames for supervision. There are four S-frames defined: Receiver Ready (RR),
Reject (REJ), Receiver Not Ready (RNR), and Selective Reject (SREJ). All frames
formats in Enhanced Retransmission mode shall use the Enhanced Control Field.

8.6.1.1 Receiver Ready (RR)

The RR frame shall be used by an L2CAP entity to

1. Indicate that it is ready to receive I-frames

2. Acknowledge previously received I-frames numbered up to and including ReqSeq -
1.

An RR with P-bit set to 1 (P=1) is used to indicate the clearance of any busy condition
that was initiated by an earlier transmission of an RNR frame by the same L2CAP entity.

8.6.1.2 Reject (REJ)

The REJ frame shall be used by an L2CAP entity to request retransmission of I-frames
starting with the frame numbered ReqSeq. I-frames numbered ReqSeq - 1 and below
shall be considered acknowledged. Additional I-frames awaiting initial transmission may
be transmitted following the retransmitted I-frame(s) up to the TxWindow size of the
receiver.

At most only one REJ exception from a given L2CAP entity to another L2CAP entity
shall be established at any given time. A REJ frame shall not be transmitted until an
earlier REJ exception condition or all earlier SREJ exception conditions have been
cleared. The REJ exception condition shall be cleared upon the receipt of an I-frame
with TxSeq equal to the ReqSeq of the REJ frame.

Two L2CAP entities may be in REJ exception conditions with each other at the same
time.

8.6.1.3 Receiver Not Ready (RNR)

The RNR frame shall be used by an L2CAP entity to indicate a busy condition
(i.e. temporary inability to receive I-frames). I-frames numbered up to and including
ReqSeq - 1 shall be considered acknowledged. The I-frame numbered ReqSeq and
any subsequent I-frames sent shall not be considered acknowledged. The acceptance
status of these I-frames shall be indicated in subsequent transfers.

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 3, Part A Page 1204
Logical Link Control and Adaptation Protocol Specification

8.6.1.4 Selective Reject (SREJ)

The SREJ frame shall be used by an L2CAP entity to request retransmission of one
I-frame. The ReqSeq shall indicate the TxSeq of the earliest I-frame to be retransmitted
(not yet reported by a SREJ). If the P-bit is set to 1 then I-frames numbered up to and
including ReqSeq -1 shall be considered acknowledged. If the P-bit is set to 0 then the
ReqSeq field in the SREJ shall not indicate acknowledgment of I-frames.

Each SREJ exception condition shall be cleared upon receipt of an I-frame with TxSeq
equal to the ReqSeq sent in the SREJ frame.

An L2CAP entity may transmit one or more SREJ frames with the P=0 before one or
more earlier SREJ exception conditions initiated with SREJ(P=0) have been cleared.
An L2CAP entity shall not transmit more than one SREJ with P=1 before all earlier
SREJ exception conditions have been cleared. A SREJ frame shall not be transmitted
if an earlier REJ exception condition has not been cleared. Likewise a REJ frame shall
not be transmitted if one or more SREJ exception conditions have not been cleared.
Only one I-frame shall be retransmitted in response to receiving a SREJ frame with
P=0. Additional I-frames awaiting initial transmission may be transmitted following the
retransmission of the specific I-frame requested by SREJ with P=1.

8.6.1.5 Functions of the Poll (P) and Final (F) bits

P-bit set to 1 shall be used to solicit a response frame with the F-bit set to 1 from the
remote L2CAP entity at the earliest respond opportunity. At most only one frame with a
P=1 shall be outstanding in a given direction at a given time. Before an L2CAP entity
issues another frame with P=1, it shall have received a response frame from the remote
L2CAP entity with F=1. If no valid frame is received with F=1 within Monitor timeout
period, the frame with P=1 may be retransmitted.

The Final bit shall be used to indicate the frame as a response to a soliciting poll
(S‑frame with P=1). The frame with F=1 shall not be retransmitted. The Monitor-timeout
is not used to monitor lost frames with F=1. Additional frames with F=0 may be
transmitted following the frame with F=1.

S-frames shall not be transmitted with both the F-bit and the P-bit set to 1 at the same
time.

8.6.2 Rules for timers

Timers are started upon transmission of a packet. Timers should be started when the
corresponding packet leaves the Controller (transmitted or flushed). If the timer is not
started when the packet leaves the Controller then it shall be started when the packet
is delivered to the Controller. The specific rules for BR/EDR and BR/EDR/LE Controllers
are described in the following sections.

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 3, Part A Page 1205
Logical Link Control and Adaptation Protocol Specification

8.6.2.1 Timer rules for ACL-U logical links

If a flush timeout does not exist on the ACL-U logical link for the channel using
Enhanced Retransmission mode then the value for the Retransmission timeout shall be
at least two seconds and the value for the Monitor timeout shall be at least 12 seconds.

If a flush timeout exists on the link for Enhanced Retransmission mode then the value
for the Retransmission timeout shall be three times the value of flush timeout, subject to
a minimum of 1 second and maximum of 2 seconds.

If a flush timeout exists on the link for Enhanced Retransmission mode and both sides
of the link are configured to the same flush timeout value then the monitor timeout shall
be set to a value at least as large as the Retransmission timeout otherwise the value of
the Monitor timeout shall be six times the value of flush timeout, subject to a minimum of
the retransmission timeout value and a maximum of 12 seconds.

If an L2CAP entity knows that a specific packet has been flushed instead of transmitted
then it may execute proper error recovery procedures immediately.

When configuring a channel over an ACL-U logical link the values sent in an
L2CAP_CONFIGURATION_REQ packet for Retransmission timeout and Monitor
timeout shall be 0.

Note: If the link has a flush timeout and the Non-Flushable Packet Boundary Flag
feature is used to mark the Enhanced Retransmission mode packets as non-flushable
then the link does not have a flush timeout with regards to Enhanced Retransmission
mode.

8.6.2.2 [This section is no longer used]

8.6.2.3 [This section is no longer used]

8.6.3 General rules for the state machine

Enhanced Retransmission mode is specified using a pair of state machines, a

Transmitter state machine and a Receiver state machine. The following rules apply
to the state machine pair.

1. The state machine pair specifies the behavior of the protocol. Designers and
implementers may choose any design / implementation technique they wish, but
it shall behave in a manner identical to the external behavior of the specified state
machines.
2. There is a single state machine pair for each active L2CAP channel configured to
use Enhanced Retransmission mode.

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 3, Part A Page 1206
Logical Link Control and Adaptation Protocol Specification

3. Variables are used to limit the number of states by maintaining the state of
particular conditions. The variables are defined in Section 8.6.5.2.
4. For some combinations of event and condition, the state tables provide an action
that involves alternatives or alternative groups of actions. The alternatives are
mutually exclusive; selection of an alternate is done based upon (i) local status,
(ii) a layer management action, or (iii) an implementation decision. There is no
relationship between the order of the alternatives between events, nor is it implied
that the same alternative must be selected every time the event occurs.
5. The state tables use timers. Any Start Timer action restarts the specified timer from
its initial value, even if the timer is already running. When the timer reaches 0 the
appropriate timer expired event is set and the timer stops. The Stop Timer action
stops a timer if it is running.
6. Events not recognized in a particular state are assumed to remain pending until
any masking flag is modified or a transition is made to a state where they can be
recognized.
7. Some state transitions and actions are triggered by internal events (e.g. requests
from the upper layer). It is implementation specific how these internal events are
realized. They are used for clarity in specifying the state machine. All events
including Internal events are described in Section 8.6.5.3.
8. The state machines specify the exact frames to be sent by transmitters but are
relaxed on what receivers are allowed to accept as valid. For example there are
cases where the transmitter is required to send a frame with P=1. The correct
response is a frame with F=1 but in some cases the receiver is allowed to accept a
frame with F=0 in addition to F=1.

8.6.4 State diagram

The state diagram in Figure 8.4 shows the states and the main transitions. Not all
events are shown on the state diagram.

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 3, Part A Page 1207
Logical Link Control and Adaptation Protocol Specification

SREJ_
SENT

Monitor Timer expires

Recv I-frames, S-frames Action: send RR(P=1) or RNR(P=1)
Action: send RR, RNR,
I-frames

RECV WAIT_F

REJ_
SENT

XMIT
Note 1: Implementations may choose
between sending an REJ or SREJ
when receiving an I-frame with
Transmitter State Machine
Unexpected TxSeq

Figure 8.4: Receiver state machine

8.6.5 States tables

8.6.5.1 State machines

Enhanced Retransmission mode is described as a pair of state machine. The Receiver

state machine handles all received frames while the Transmitter State machine handles
all asynchronous events including requests from the upper layer and the expiration of
timers.

The Receiver state machine “calls” the Transmitter state machine using the PassToTx
action. This shows up in the Transmitter state machine as an event. When the
Transmitter state machine is called it runs to completion before returning to the Receiver
state machine. Running to completion means that all actions are executed and the
Transmitter state is changed to the new state.

The Receiver and Transmitter state machine share variables and timers.

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 3, Part A Page 1208
Logical Link Control and Adaptation Protocol Specification

8.6.5.2 States

The following states have been defined to specify the protocol; the actual number of
states and naming in a given implementation is outside the scope of the specification:

RECV—This is the main state of the Receiver state machine.

REJ_SENT—The L2CAP entity has sent a REJ frame to cause the remote L2CAP
entity to resend I-frame(s). The L2CAP entity is waiting for the I-frame with a TxSeq
that matches the ReqSeq sent in the REJ. Whether to send a REJ versus a SREJ is
implementation dependent.

SREJ_SENT—The L2CAP entity has sent one or more SREJ frames to cause the
remote L2CAP entity to resend missing I-frame(s). The local L2CAP entity is waiting for
all requested I-frames to be received. If additional missing I-frames are detected while in
SREJ_SENT then additional SREJ frames or a REJ frame can be sent to request those
I-frames. Whether to send a SREJ versus a REJ is implementation dependent.

XMIT—This is the main state of the Transmitter state machine.

WAIT_F—Local busy has been cleared or the Retransmission timer has expired and an
S-frame with P=1 has been sent. The local L2CAP entity is waiting for a frame with F=1.
New I-frames cannot be sent while in the WAIT_F state to prevent the situation where
retransmission of I-frames could result in the channel being disconnected.

8.6.5.3 Variables and timers

Variables are used to limit the number of states and help clarify the state chart tables.
Variables can be set to values, evaluated in conditions and compared in conditional
statements. They are also used in the action descriptions. Below is a list of the
operators, connectives and statements that can be used with variables.

Operator, Description
connective or statement
:= Assignment operator. Used to set a variable to a value
= Relational operator "equal"
> Relational operator "greater than"
< Relational operator "less than"
≥ Relational operator "greater than or equal"
≤ Relational operator "less than or equal"
+ Arithmetic operator "plus"

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 3, Part A Page 1209
Logical Link Control and Adaptation Protocol Specification

Operator, Description
connective or statement
and logical connective "and." It returns TRUE if both operands are TRUE
otherwise it returns FALSE.
or logical connective "or." It returns TRUE if either of its operands are
TRUE otherwise it returns FALSE.
if (expression) then { Conditional Statement. If expression is TRUE then the statement is
executed otherwise the statement is not executed. The statement is
statement
composed of one or more actions. All the actions in the statement are
} indented under the if ... then clause and contained within braces “{ }”.
if (expression) then { Conditional Statement. If expression is TRUE then statement1 is exe-
cuted otherwise statement2 is executed. A statement is composed of
statement1
one or more actions. All the actions in the statement1 are indented
} under the if ... then clause and contained within braces “{ }”. All the ac-
else { tions of statement2 are indented under the else clause and contained
within braces “{ }”.
statement2
}

Table 8.2: Operators, connectives, and statements used with variables

Enhanced Retransmission mode uses the following variables and sequence numbers
described in Section 8.3:

• TxSeq
• NextTxSeq
• ExpectedAckSeq
• ReqSeq
• ExpectedTxSeq
• BufferSeq

In addition to the variables above the following variables and timers are used:

RemoteBusy—when set to TRUE RemoteBusy indicates that the local L2CAP entity
has received an RNR from the remote L2CAP entity and considers the remote L2CAP
entity as busy. When the remote device is busy it will likely discard I-frames sent to it.
The RemoteBusy flag is set to FALSE when the local L2CAP Entity receives an RR,
REJ or SREJ. When set to FALSE the local L2CAP entity considers the remote L2CAP
entity able to accept I-frames. When the channel is created RemoteBusy shall be set to
FALSE.

LocalBusy—when set to TRUE, LocalBusy indicates the local L2CAP entity is busy
and will discard received I-frames. When set to FALSE the local L2CAP entity is not

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 3, Part A Page 1210
Logical Link Control and Adaptation Protocol Specification

busy and is able to receive I-frames. When the channel is created LocalBusy shall be
set to FALSE.

UnackedFrames—holds the number of unacknowledged I-frames. When the channel is

created UnackedFrames shall be set to 0.

UnackedList—holds the unacknowledged I-frames so they can be retransmitted if

necessary. I-frames in the list are accessed via their TxSeq number. For example
UnackedList[5] accesses the I-frame with TxSeq 5.

PendingFrames—holds the number of pending I-frames. I-frames passed to L2CAP

from the upper layer may be unable to be sent immediately because the remote L2CAP
entity's TxWindow is full, is in a busy condition or the local L2CAP is in the incorrect
state. When I-frames cannot be sent they are stored in a queue until conditions allow
them to be sent. When the channel is created PendingFrames shall be set to 0.

SrejList—is a list of TxSeq values for I-frames that are missing and need to be
retransmitted using SREJ. A SREJ has already been sent for each TxSeq on the list.
When SrejList is empty it equals 0 (i.e. SrejList = 0). If SrejList is not empty it is greater
than 0 (i.e. SrejList > 0).

RetryCount—holds the number of times an S-frame operation is retried. If an operation

is tried MaxTransmit times without success the channel shall be closed.

RetryIframes[ ]—holds a retry counter for each I-frame that is sent within the receiving
device's TxWindow. Each time an I-frame is retransmitted the corresponding counter
within RetryIframes is incremented by one. When an attempt to retransmit the I-frame is
made and the counter is equal to MaxTransmit then the channel shall be closed.

RNRsent—when set to TRUE it means that the local L2CAP entity has sent an RNR
frame. It is used to determine if the L2CAP entity needs to send an RR to the remote
L2CAP entity to clear the busy condition. When the channel is created RNRsent shall
be set to FALSE.

RejActioned—is used to prohibit a frame with F=1 from causing I-frames already
retransmitted in response to a REJ from being retransmitted again. RejActioned is set to
TRUE if a received REJ is actioned when a frame sent with P=1 is unanswered. When
the channel is created RejActioned shall be set to FALSE.

SrejActioned—is used in conjunction with SrejSaveReqSeq to prohibit a frame with

F=1 from causing an I-frame already retransmitted in response to a SREJ from being
retransmitted again. SrejActioned is set to TRUE if a received SREJ is actioned when a
frame sent with P=1 is unanswered. When the channel is created SrejActioned shall be
set to FALSE.

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 3, Part A Page 1211
Logical Link Control and Adaptation Protocol Specification

SrejSaveReqSeq—is used to save the ReqSeq of a SREJ frame that causes

SrejActioned to be set to TRUE.

SendRej—when set to TRUE it indicates that the local L2CAP entity has determined
that a REJ should be sent in the SREJ_SENT state while processing received I-frames.
The sending of new SREJ frames is stopped. When the channel is created SendRej
shall be set to FALSE.

BufferSeqSrej—is used while in the SREJ_SENT state to keep track of the value to
which BufferSeq will be set upon exit of the SREJ_SENT state.

FramesSent—is used to keep track of the number I-frames sent by the Send-Data and
Retransmit-I-frames actions.

MaxTxWin—contains the maximum window size plus 1. It is used in TxWindow mod

operations as the divisor and in state table conditions. This value shall be set to 16384
(0x4000) if the Extended Window Size option is used; otherwise it shall be set to 64.

RetransTimer—The Retransmission Timer is used to detect lost I-frames. When the

channel is created the RetransTimer shall be off.

MonitorTimer—The Monitor Timer is used to detect lost S-frames. When the channel is
created the MonitorTimer shall be off.

8.6.5.4 Events

Data-Request—The upper layer has requested that an SDU be sent. The SDU may
need to be broken into multiple I-frames by L2CAP based on the MPS of the remote
device and/or the maximum PDU allowed by the HCI or QoS requirements of the
system.

Local-Busy-Detected—A local busy condition occurs when the local L2CAP entity is
temporarily unable to receive, or unable to continue to receive, I-frames due to internal
constraints. For example, the upper layer has not pulled received I-frames and the
local L2CAP entity needs to send an acknowledgment to the remote L2CAP entity.
The method for handling the detection of local busy is implementation specific. An
implementation may wait to send an RNR to see if the busy condition will clear before
the remote L2CAP entity's Retransmission timer expires. If the busy condition clears
then frames can be acknowledged with an RR or I-frame. If the busy condition does not
clear before the remote L2CAP entity's Retransmission timer expires then an RNR shall
be sent in response to the RR or RNR poll sent by the remote L2CAP entity. Optionally
an implementation may send an RNR as soon as the local busy condition is detected.

Local-Busy-Clear—The local busy condition clears when L2CAP has buffer space to
receive more I-frames (i.e. SDU Reassembly function and/or upper layer has pulled
I-frames) and if necessary the upper layer has cleared the busy condition.

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 3, Part A Page 1212
Logical Link Control and Adaptation Protocol Specification

Recv ReqSeqAndFbit—This is an event generated by the Receiver state machine. It

contains the ReqSeq and F-bit value of a received frame. The value of the F-bit can be
checked in a condition.

Recv Fbit—This is an event generated by the Receiver state machine. It contains the
F-bit value of a received frame. The value of the F-bit can be checked in a condition.

RetransTimer-Expires—The Retransmission Timer has counted to down to 0 and

stopped.

MonitorTimer-Expires—The Monitor Timer has counted down to 0 and stopped.

Recv I-frame—Receive an I-frame with any value for the F-bit.

Recv RR, REJ, RNR, SREJ (P=x) or (F=x)—Receive a specific S-frame (RR, REJ,
etc.) with a specific value for the P and/or F bit. The F-bit and the P-bit shall not both be
set to 1 in a transmitted S-frame so received S-frames with both P and F set to 1 should
be ignored. If the P and/or F bit value is not specified in the event then either value is
accepted.

Recv RRorRNR—Receive an RR or RNR with any value for the P-bit and F-bit.

Recv REJorSREJ—Receive an REJ or SREJ with any value for the P-bit and F-bit.

Recv frame—This is catch-all for all frames that are not explicitly declared as events in
the state table.

8.6.5.5 Conditions

RemoteBusy = TRUE or FALSE—TRUE indicates the remote L2CAP entity is in a

busy condition and FALSE indicates the remote L2CAP entity is not busy.

LocalBusy = TRUE or FALSE—TRUE indicates the local L2CAP entity is in a busy

condition and FALSE indicates the local L2CAP entity is not busy.

RemWindow-Not-Full—The number of unacknowledged I-frames sent by L2CAP has

not yet reached the TxWindow size of the remote L2CAP entity.

RemWindow-Full—The number of unacknowledged I-frames sent by the L2CAP entity

has reached the TxWindow size of the remote L2CAP entity. No more I-frames shall be
sent until one or more I-frames have been acknowledged.

RNRsent = TRUE or FALSE—TRUE indicates an RNR has been sent while a local
busy condition exists. It is set to FALSE when the local busy condition clears.

F = 0 or 1—the F-bit of a received frame is checked. The F-bit of the received frame is
available as part of the Recv ReqSeqAndFbit and Recv Fbit events.

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 3, Part A Page 1213
Logical Link Control and Adaptation Protocol Specification

RetryIframes[i] < or ≥ MaxTransmit—Compare the appropriate counter in

RetryIframes after processing the ReqSeq in the receive frame to determine if it has
reached MaxTransmit or not.

RetryCount < or ≥ MaxTransmit—Compare RetryCount to determine if it has reached

MaxTransmit or not.

With-Expected-TxSeq—The TxSeq of a received I-frame is equal to ExpectedTxSeq.

With-Valid-ReqSeq—The ReqSeq of the received frame is in the range

ExpectedAckSeq ≤ ReqSeq < NextTxSeq.

With-Valid-ReqSeq-Retrans—The ReqSeq of the received frame is in the range

ExpectedAckSeq ≤ ReqSeq < NextTxSeq.

With-Valid-F-bit —The F-bit of a received frame is valid if it is 0 or if it is 1 and a frame

sent with P=1 by the local L2CAP entity is unanswered (i.e. the local L2CAP entity send
a frame with P=1 and has not yet received a frame with F=1 until receiving this one).
If the Transmitter state machine is in the WAIT_F state then a frame sent with P=1 is
unanswered.

With-unexpected-TxSeq—The TxSeq of the received I-frame is within the TxWindow

of the L2CAP entity receiving the I-frame but has a TxSeq “greater” than
ExpectedTxSeq where “greater” means later in sequence than ExpectedTxSeq.

With-duplicate-TxSeq—The TxSeq of the received I-frame is within the TxWindow of

the L2CAP entity receiving the I-frame but has a TxSeq “less” than ExpectedTxSeq
where “less” means earlier in the sequence than ExpectedTxSeq. In other words this is
a frame that has already been received.

With-Invalid-TxSeq—The TxSeq of the received I-frame is not within the TxWindow of

the L2CAP entity receiving the frame.

With-Invalid-ReqSeq—The ReqSeq of the received frame is not in the range

ExpectedAckSeq ≤ ReqSeq < NextTxSeq.

With-Invalid-ReqSeq-Retrans—The ReqSeq of the received frame is not in the range

ExpectedAckSeq ≤ ReqSeq < NextTxSeq.

Not-With-Expected-TxSeq—The TxSeq of the received I-frame is within the TxWindow

of the L2CAP entity receiving the frame but is not equal to ExpectedTxSeq. It is either
unexpected or a duplicate.

With-Expected-TxSeq-Srej—The TxSeq of the received I-frame is equal to the TxSeq

at the head of SrejList.

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 3, Part A Page 1214
Logical Link Control and Adaptation Protocol Specification

SendRej = TRUE or FALSE—TRUE indicates that a REJ will be sent after all frames
requested using SREJ have been received.

SrejList = or > 1—Determine if the number of items in SrejList is equal to or greater

than 1.

With-Unexpected-TxSeq-Srej—The TxSeq of the received I-frame is equal to one of

the values stored in SrejList but is not the TxSeq at the head. This indicates that one
or more I-frames requested using SREJ are missing either because the SREJ was lost
or the requested I-frame(s) were lost. Either way the SREJ frames must be resent to
retrieve the missing I-frames.

With-duplicate-TxSeq-Srej—The TxSeq of the received I-frame is equal to a TxSeq of

one of the saved I-frames indicating it is a duplicate.

8.6.5.6 Actions

Send-Data—This action is executed as a result of a Data-Request event. The number

of I-frames sent without being acknowledged shall not exceed the TxWindow size of
the receiving L2CAP entity (UnackedFrames is less than or equal to the remote L2CAP
entity's TxWindow). Any I-frames that cannot be sent because they would exceed the
TxWindow size are queued for later transmission. For each I-frame the following actions
shall be carried out:

Send I-frame with TxSeq set to NextTxSeq and ReqSeq set to BufferSeq.
UnackedList[NextTxSeq] := I-frame
UnackedFrames := UnackedFrames + 1
FramesSent := FramesSent + 1
RetryIframes[NextTxSeq] := 1
NextTxSeq := (NextTxSeq + 1) mod MaxTxWin
Start-RetransTimer

Pend-Data—This action is executed as a result of a Data-Request when it is not

possible to send I-frames because the window is full, the remote L2CAP entity is in a
busy condition or the local L2CAP entity is not in a state where I-frames can be sent
(e.g. WAIT_F). The I-frame(s) are queued for later transmission.

Process-ReqSeq—the ReqSeq contained in the received frame shall acknowledge

previously transmitted I-frames. ExpectedAckSeq shall be set to ReqSeq to indicate that
the I-frames with TxSeq up to and including (ReqSeq—1) have been acknowledged.
The acknowledged I-frames shall be removed from UnackedList, the retry counters
for each acknowledged frame shall be set to 0 and the number of acknowledged
frames shall be subtracted from UnackedFrames so that UnackedFrames shall contain
the number of the remaining unacknowledged I-frames. Pending I-frames are now
available to be transmitted by the Send-Ack action. If UnackedFrames equals 0 then
Stop-RetransTimer.

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 3, Part A Page 1215
Logical Link Control and Adaptation Protocol Specification

Send RR, RNR (P=x) or (F=x)—Send the specified S-frame with the specified value for
the P-bit or F-bit. If a value for the P-bit or F-bit is not specified the value shall be 0. For
example Send RR(P=1) means send an RR with the P-bit set to 1 and the F-bit set to 0.
The ReqSeq field shall be set to BufferSeq. If an RNR is sent, RNRsent shall be set to
TRUE.

Send REJ (P =x) or (F=x)—Send a REJ with the specified value for the P-bit or F-bit.
The ReqSeq field shall be set to ExpectedTxSeq. If a value for the P-bit or F-bit is not
specified the value shall be 0, which acknowledges previously received I-frames up to
ExpectedTxSeq—1 and may allow the remote L2CAP entity to transmit new I-frames.
If the local L2CAP entity is not in a position to acknowledge the previously received
I-frames it may use SREJ(P=0) or RNR. It may also wait to send the REJ until it is able
to acknowledge the I-frames.

Send RRorRNR (P=x) or (F=1)—Send an RR or RNR with the specified value for the
P-bit or F-bit based on the value of LocalBusy. If a value for the P-bit or F-bit is not
specified the value shall be 0. An RNR shall be sent if LocalBusy equals TRUE. If
LocalBusy equals FALSE then an RR shall be sent.

Send IorRRorRNR(F=1)—Send I-frames, an RR or an RNR with the F-bit set to 1. The

following algorithm shall be used:

FramesSent:=0
if LocalBusy = TRUE then {
Send RNR(F=1)
}
if RemoteBusy = TRUE and UnackedFrames > 0 then {
Start-RetransTimer
}
RemoteBusy := FALSE
Send-Pending-I-frames
if LocalBusy = FALSE and FramesSent = 0 then {
Send RR(F=1)
}

The SendIorRRorRNR(F=1) sends frames by invoking other actions. During the

execution of SendIorRRorRNR multiple actions may be invoked. The first action invoked
shall send the first or only frame with the F-bit set to 1. All other frames sent shall have
the F-bit set to 0.

Send SREJ—Send one or more SREJ frames with P=0. For each missing I-frame
starting with ExpectedTxSeq up to but not including the TxSeq of the received I-frame,
an SREJ frame is sent with ReqSeq set to the TxSeq of the missing frame. The TxSeq
is inserted into the tail of SrejList. For example if ExpectedTxSeq is 3 and the received
I-frame has a TxSeq of 5 there are two missing I-frames. An SREJ with ReqSeq 3 is
sent followed by an SREJ with ReqSeq 4. TxSeq 3 is inserted first into SrejList followed

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 3, Part A Page 1216
Logical Link Control and Adaptation Protocol Specification

by TxSeq 4. After all SREJ frames have been sent ExpectedTxSeq shall be set to (the
TxSeq of the received I-frame + 1) mod MaxTxWin.

Send SREJ(SrejList)—Send one or more SREJ frames with P=0. An I-frame was
received that matches one of the TxSeq values in the SrejList but does not match the
head of SrejList. This means I-frames requested via SREJ are still missing. For each
TxSeq value starting with the head of SrejList and going backwards (i.e., from the head
towards the tail) through the SrejList up to but not including the TxSeq of the received
frame, an SREJ frame is sent with ReqSeq set to the TxSeq from SrejList. The TxSeq is
removed from SrejList and reinserted into the tail of SrejList. Finally, remove the TxSeq
of the received frame from the head of the list.

Send SREJ(SrejList-tail)(F=1)—Send a SREJ frame with F=1 and ReqSeq equal to

the TxSeq at the tail of SrejList.

Start-RetransTimer—If the Monitor timer is not running then start the Retransmission
Timer from its initial value (see Retransmission timeout in Section 5.4). If the
Retransmission timer is already running it is restarted from its initial value. If the Monitor
timer is running then the Retransmission timer is not started.

Start-MonitorTimer—Start the Monitor Timer from its initial value (see Monitor timeout
in Section 5.4). If the timer is already running it is restarted from its initial value.

PassToTx—Pass the ReqSeq and F-bit value of a received frame to the Transmitter
state machine. This will show up as a Recv ReqSeqAndFbit event in the Transmitter
state machine.

PassToTxFbit—Pass the F-bit value of a received frame to the Transmitter state

machine. This will show up as a Recv Fbit event in the Transmitter state machine.

Data-Indication—A received I-frame is passed to the SDU reassembly function. For

the purpose of the state machine this operation is completed immediately so the
Send_Ack action should be executed as one of the next actions. In some cases the
SDU reassembly function cannot accept the I-frame so the I-frame will be stored within
the L2CAP Entity consuming a portion of its TxWindow. When the I-frame is pulled
by the SDU reassembly function the Send_Ack action should be executed. Before the
Send_Ack action is executed BufferSeq is advanced as follows:

BufferSeq := (BufferSeq + 1) mod MaxTxWin

Increment-ExpectedTxSeq—ExpectedTxSeq is incremented as follows:

ExpectedTxSeq := (ExpectedTxSeq + 1) mod MaxTxWin

Stop-RetransTimer—the Retransmission timer is stopped.

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 3, Part A Page 1217
Logical Link Control and Adaptation Protocol Specification

Stop-MonitorTimer —the Monitor timer is stopped.

Send-Ack (F=x)—an acknowledgment with the specified value for the F-bit may be
sent. This action may occur in an action block with other actions that also send frames.
If a frame has already been sent then it is not necessary to send additional frames.

If the value for the F-bit is not specified it shall be set to 0. If the value specified
is P then the F-bit shall be set equal to the value of the P-bit of the received frame
being acknowledged. If more than one frame is sent in the acknowledgment only
the first frame shall have an F-bit set to 1. An acknowledgment is an RR, RNR, or
pending I-frame(s) (I-frames that have not been transmitted yet). If pending I-frames
are available and are allowed to be sent then as many as allowed should be sent as
an acknowledgment. Sending an RR or RNR as an acknowledgment for each received
I-frame is not required. An implementation may wait to send an RR or RNR until a
specific number of I-frames have been received, after a certain period of time has
elapsed or some other algorithm. To keep data flowing it is recommended that an
acknowledgment be sent before the TxWindow is full. It should also be noted that the
maximum size of a remote L2CAP entity's unacknowledged I-frame list may be smaller
than the local L2CAP entity's TxWindow. Therefore the local L2CAP entity should not
expect the remote L2CAP entity to send enough frames to fill its TxWindow and should
acknowledge I-frames accordingly.

The following algorithm shall be used when sending an acknowledgment.

if LocalBusy == TRUE then {

Send_RNR(F=x)
}
else if (RemoteBusy == FALSE) and Pending I-frames Exist and RemWindow-
Not-Full then {
Send-Pending-I-frames (F=x)
}
else {
Send_RR (F=x)
}

InitSrej—Initialize the variables used for processing SREJ as follows:

Clear SrejList - (remove all values)

SendRej := FALSE
BufferSeqSrej := BufferSeq

SaveIframeSrej—Save the received I-frame. Missing I-frame(s) will be retransmitted in

response to SREJ frames. Implementations may want to save the I-frame in its proper
sequence order by leaving room for the missing I-frames.

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 3, Part A Page 1218
Logical Link Control and Adaptation Protocol Specification

StoreOrIgnore—If the local L2CAP entity has room to store the received I-frame
then it may store it otherwise it shall discard it. If the received I-frame is stored,
ExpectedTxSeq is advanced as follows:

ExpectedTxSeq := (ExpectedTxSeq + 1) mod MaxTxWin

PbitOutstanding—If the Transmitter state machine of the local L2CAP entity is in the
WAIT_F state then return TRUE otherwise return FALSE.

Retransmit-I-frames—All the unacknowledged I-frames starting with the I-frame with

TxSeq equal to the ReqSeq field of the received S-frame (REJ or RR) is retransmitted.
If the P-bit of the received S-frame is 1 then the F-bit of the first I-frame sent shall
be 1. If the P-bit of the received S-frame is 0 then the F-bit of the first I-frame sent
shall be 0. The F-bit of all other unacknowledged I-frames sent shall be 0. The retry
counter in RetryIframes[ ] for each retransmitted I-frame is incremented by 1. If a retry
counter in RetryIframes[ ] is equal to MaxTransmit then the channel shall be closed.
FramesSent shall be incremented by 1 for each frame sent. If the RetransTimer is not
already running then perform the Start-RetransTimer action.

Retransmit-Requested-I-frame—The unacknowledged I-frame with TxSeq equal to

the ReqSeq field of the received S-frame (SREJ) is retransmitted. If the P-bit of the
received S-frame is 1 then the F-bit of the retransmitted I-frame shall be 1. If the P-bit of
the received S-frame is 0 then the F-bit of the retransmitted I-frame shall be 0. The retry
counter in RetryIframes[ ] corresponding to the retransmitted I-frame is incremented
by 1. If the RetransTimer is not already running then perform the Start-RetransTimer
action.

Send-Pending-I-frames (F=x)—If PbitOutstanding equals FALSE then send all pending

I-frames that can be sent without exceeding the receiver's TxWindow using the Send-
Data action. If a value for the F-bit is specified then the F-bit of the first I-frame sent
shall be set to the specified value and the F-bit of all other I-frames sent shall be set
to 0. If no value for the F-bit is specified then all I-frames sent shall have the F-bit set
to 0. Pending I-frames are I-frames that have been given to the L2CAP entity by the
upper layer but have not yet been transmitted. If one or more I-frames are sent and the
RetransTimer is not already running then perform the Start-RetransTimer action.

Close Channel—Close the L2CAP channel as described in Section 4.6.

Ignore—Silently discard the event.

CloseChannelOrIgnore—Either close the L2CAP channel as described in Section 4.6

(in which case the next state is ignored) or silently discard the event.

PopSrejList—Remove and discard the TxSeq from the head of SrejList.

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 3, Part A Page 1219
Logical Link Control and Adaptation Protocol Specification

Data-IndicationSrej—If the received I-frame fills a gap in a sequence of saved I-frames

then all the saved I-frames in the sequence are passed to the SDU reassembly function.
For the purpose of the state machine this operation is completed immediately. For
example if the TxSeq of saved I-frames before receiving an I-frame is 2, 3, 5, 6, 9
and the received I-frame has a TxSeq of 4 then it fills the gap between 3 and 5 so
the sequence 2, 3, 4, 5, 6 can be passed to the SDU reassembly function. When the
I-frames are actually removed from the L2CAP entity receive buffers either by being
processed immediately or when pulled by the SDU reassembly function, BufferSeqSrej
is advanced as follows:

BufferSeqSrej := (BufferSeqSrej + 1) mod MaxTxWin

8.6.5.7 XMIT state table

Event Condition Action Next State

Data-Request RemoteBusy = FALSE Send-Data XMIT
and
RemWindow-Not-Full
Data-Request RemoteBusy = TRUE or Pend-Data XMIT
RemWindow-Full
Local-Busy-Detected none LocalBusy := TRUE XMIT
Optionally Send RNR
Local-Busy-Clear RNRsent = TRUE LocalBusy := FALSE WAIT_F
RNRsent := FALSE
Send RR(P=1)
RetryCount := 1
Stop-RetransTimer
Start-MonitorTimer
Local-Busy-Clear RNRsent = FALSE LocalBusy := FALSE XMIT
RNRsent := FALSE
Recv ReqSeqAndFbit none Process-ReqSeq XMIT
Recv Fbit none none XMIT
RetransTimer-Expires none Send RRorRNR(P=1) WAIT_F
RetryCount := 1
Start-MonitorTimer

Table 8.3: XMIT state table

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 3, Part A Page 1220
Logical Link Control and Adaptation Protocol Specification

8.6.5.8 WAIT_F state table

Event Condition Action Next State

Data-Request none Pend-Data WAIT_F
Recv ReqSeqAndFbit F=1 Process-ReqSeq XMIT
Stop-MonitorTimer
If UnackedFrames > 0 then {
Start-RetransTimer
}
Recv ReqSeqAndFbit F=0 Process-ReqSeq WAIT_F
Recv Fbit F=1 Stop-MonitorTimer XMIT
If UnackedFrames > 0 then {
Start-RetransTimer
}
Recv Fbit F=0 none WAIT_F
MonitorTimer-Expires RetryCount < MaxTransmit RetryCount := RetryCount+1 WAIT_F
Send RRorRNR(P=1)
Start-MonitorTimer
MonitorTimer-Expires RetryCount ≥ MaxTransmit Close Channel none

Table 8.4: WAIT_F state table

8.6.5.9 RECV state table

Event Condition Action Next State

Recv I-frame With-Expected-TxSeq Increment-ExpectedTxSeq RECV
(F=0)
and With-Valid-ReqSeq PassToTx
and With-Valid-F-bit Data-Indication
and LocalBusy = FALSE Send-Ack(F=0)

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 3, Part A Page 1221
Logical Link Control and Adaptation Protocol Specification

Event Condition Action Next State

Recv I-frame With-Expected-TxSeq Increment-ExpectedTxSeq RECV
(F=1) and With-Valid-ReqSeq PassToTx
and With-Valid-F-bit Data-Indication
and LocalBusy = FALSE If RejActioned = FALSE then {
Retransmit-I-frames
Send-Pending-I-frames
} else {
RejActioned := FALSE
}
Send-Ack(F=0)
Recv I-frame With-duplicate-TxSeq PassToTx RECV
and With-Valid-ReqSeq
and With-Valid-F-bit
and LocalBusy = FALSE
Recv I-frame With-unexpected-TxSeq PassToTx REJ_SENT
and With-Valid-ReqSeq SendREJ
and With-Valid-F-bit
and LocalBusy = FALSE
Alternative 1
Recv I-frame With-unexpected-TxSeq PassToTx SREJ_SENT
and With-Valid-ReqSeq InitSrej
and With-Valid-F-bit SaveIframeSrej
and LocalBusy = FALSE SendSREJ
Alternative 2
Recv I-frame With-Expected-TxSeq PassToTx RECV
and With-Valid-ReqSeq StoreOrIgnore
and With-Valid-F-bit
and LocalBusy = TRUE
Recv I-frame With-Valid-ReqSeq PassToTx RECV
and Not-With_Expected_TxSeq
and With-Valid-F-bit
and LocalBusy = TRUE
Recv RNR With-Valid-ReqSeq RemoteBusy := TRUE RECV
(P=0) and With-Valid-F-bit PassToTx
Stop-RetransTimer

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 3, Part A Page 1222
Logical Link Control and Adaptation Protocol Specification

Event Condition Action Next State

Recv RNR With-Valid-ReqSeq RemoteBusy := TRUE RECV
(P=1) and With-Valid-F-bit PassToTx
Stop-RetransTimer
Send RRorRNR (F=1)
Recv RR(P=0) With-Valid-ReqSeq PassToTx RECV
(F=0) and With-Valid-F-bit If RemoteBusy = TRUE and Un-
ackedFrames > 0 then {
Start-RetransTimer
}
RemoteBusy := FALSE
Send-Pending-I-frames
Recv RR(F=1) With-Valid-ReqSeq RemoteBusy := FALSE RECV
and With-Valid-F-bit PassToTx
If RejActioned = FALSE then {
Retransmit-I-frames
} else {
RejActioned := FALSE
}
Send-Pending-I-frames
Recv RR(P=1) With-Valid-ReqSeq PassToTx RECV
and With-Valid-F-bit Send IorRRorRNR(F=1)
Recv REJ With-Valid-ReqSeq-Retrans and RemoteBusy := FALSE RECV
(F=0) RetryIframes[i] < MaxTransmit PassToTx
and With-Valid-F-bit Retransmit-I-frames
Send-Pending-I-frames
If PbitOutstanding then {
RejActioned := TRUE
}

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 3, Part A Page 1223
Logical Link Control and Adaptation Protocol Specification

Event Condition Action Next State

Recv REJ With-Valid-ReqSeq-Retrans and RemoteBusy := FALSE RECV
(F=1) RetryIframes[i] < MaxTransmit PassToTx
and With-Valid-F-bit If RejActioned = FALSE then {
Retransmit-I-frames
} else {
RejActioned :=FALSE
}
Send-Pending-I-frames ]
Recv SREJ With-Valid-ReqSeq-Retrans and RemoteBusy := FALSE RECV
(P=0) (F=0) RetryIframes[i] < MaxTransmit PassToTxFbit
and With-Valid-F-bit Retransmit-Requested-I-frame
If PbitOutstanding then {
SrejActioned := TRUE
SrejSaveReqSeq = ReqSeq
}
Recv SREJ With-Valid-ReqSeq-Retrans and RemoteBusy := FALSE RECV
(P=0) (F=1) RetryIframes[i] < MaxTransmit PassToTxFbit
and With-Valid-F-bit If SrejActioned = TRUE and Srej-
SaveReqSeq = ReqSeq then {
SrejActioned := FALSE
} else {
Retransmit-Requested-I-frame
}
Recv With-Valid-ReqSeq-Retrans and RemoteBusy := FALSE RECV
SREJ(P=1) RetryIframes[i] < MaxTransmit PassToTx
and With-Valid-F-bit Retransmit-Requested-I-frame
Send-Pending-I-frames
If PbitOutstanding then {
SrejActioned = TRUE
SrejSaveReqSeq := ReqSeq
}
Recv REJ With-Valid-ReqSeq-Retrans and Close Channel none
RetryIframes[i] ≥ MaxTransmit
RECV SREJ With-Valid-ReqSeq-Retrans and Close Channel none
RetryIframes[i] >= MaxTransmit

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 3, Part A Page 1224
Logical Link Control and Adaptation Protocol Specification

Event Condition Action Next State

Recv I-frame (With-Invalid-TxSeq and Close Channel none
TxWindow > MaxTxWin÷2)
or With-Invalid-ReqSeq
Recv I-frame With-Invalid-TxSeq CloseChannelOrIgnore RECV
and TxWindow ≤ MaxTxWin÷2
Recv With-Invalid-ReqSeq Close Channel none
RRorRNR
Recv REJorS- With-Invalid-ReqSeq-Retrans Close Channel none
REJ
Recv frame none Ignore RECV

Table 8.5: RECV state table

8.6.5.10 REJ_SENT state table

Event Condition Action Next State

Recv I-frame With-Expected-TxSeq Increment-ExpectedTxSeq RECV
(F=0) and With-Valid-ReqSeq PassToTx
and With-Valid-F-bit Data-Indication
Send-Ack (F=0)
Recv I-frame With-Expected-TxSeq Increment-ExpectedTxSeq RECV
(F=1) and With-Valid-ReqSeq PassToTx
and With-Valid-F-bit Data-Indication
If RejActioned = FALSE then {
Retransmit I-frames
Send-Pending-I-frames
} else {
RejActioned := FALSE
}
Send-Ack (F=0)
Recv I-frame With-Unexpected-TxSeq PassToTx REJ_SENT
and With-Valid-ReqSeq
and With-Valid-F-bit

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 3, Part A Page 1225
Logical Link Control and Adaptation Protocol Specification

Event Condition Action Next State

Recv RR (F=1) With-Valid-ReqSeq RemoteBusy := FALSE REJ_SENT
and With-Valid-F-bit PassToTx
If RejActioned = FALSE then {
Retransmit-I-frames
} else {
RejActioned := FALSE
}
Send-Pending-I-frames
Recv RR (P=0) With-Valid-ReqSeq PassToTx REJ_SENT
(F=0) and With-Valid-F-bit If RemoteBusy = TRUE and
UnackedFrames > 0 then {
Start-RetransTimer
}
RemoteBusy := FALSE
Send-Ack (F=0)
Recv RR (P=1) With-Valid-ReqSeq PassToTx REJ_SENT
and With-Valid-F-bit If RemoteBusy = TRUE and
UnackedFrames > 0 then {
Start-RetransTimer
}
RemoteBusy := FALSE
Send RR (F=1)
Recv RNR With-Valid-ReqSeq RemoteBusy := TRUE REJ_SENT
(P=1) and With-Valid-F-bit PassToTx
Send RR (F=1)
Recv RNR With-Valid-ReqSeq RemoteBusy := TRUE REJ_SENT
(P=0) and With-Valid-F-bit PassToTx
Send RR (F=0)
Recv REJ With-Valid-ReqSeq -Retrans and RemoteBusy := FALSE REJ_SENT
(F=0) RetryIframes[i] < MaxTransmit PassToTx
and With-Valid-F-bit Retransmit-I-frames
Send-Pending-I-frames
If PbitOutstanding then {
RejActioned := TRUE
}

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 3, Part A Page 1226
Logical Link Control and Adaptation Protocol Specification

Event Condition Action Next State

Recv REJ With-Valid-ReqSeq -Retrans and RemoteBusy := FALSE REJ_SENT
(F=1) RetryIframes[i] < MaxTransmit PassToTx
and With-Valid-F-bit If RejActioned = FALSE then {
Retransmit-I-frames
} else {
RejActioned := FALSE
}
Send-Pending-I-frames
Recv SREJ With-Valid-ReqSeq-Retrans and RemoteBusy := FALSE REJ_SENT
(P=0) (F=0) RetryIframes[i] < MaxTransmit PassToTxFbit
and With-Valid-F-bit Retransmit-Requested-I-frame
If PbitOutstanding then {
SrejActioned := TRUE
SrejSaveReqSeq := ReqSeq
}
Recv SREJ With-Valid-ReqSeq-Retrans and RemoteBusy := FALSE REJ_SENT
(P=0) (F=1) RetryIframes[i] < MaxTransmit PassToTxFbit
and With-Valid-F-bit If SrejActioned = TRUE and
SrejSaveReqSeq = ReqSeq then {
SrejActioned := FALSE
} else {
Retransmit-Requested-I-frame
}
Recv SREJ With-Valid-ReqSeq-Retrans and RemoteBusy := FALSE REJ_SENT
(P=1) RetryIframes[i] < MaxTransmit PassToTx
and With-Valid-F-bit Retransmit-Requested-I-frames
Send-Pending-I-frames
If PbitOutstanding then {
SrejActioned := TRUE
SrejSaveReqSeq := ReqSeq
}
Recv REJ With-Valid-ReqSeq-Retrans and Close Channel none
RetryIframes[i] ≥ MaxTransmit
Recv SREJ With-Valid-ReqSeq-Retrans and Close Channel none
(P=0) RetryIframes[i] ≥ MaxTransmit

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 3, Part A Page 1227
Logical Link Control and Adaptation Protocol Specification

Event Condition Action Next State

RECV SREJ With-Valid-ReqSeq-Retrans and Close Channel none
(P=1) RetryIframes[i] ≥ MaxTransmit
Recv I-frame (With-Invalid-TxSeq Close Channel none
and TxWindow > MaxTxWin÷2)
or With-Invalid-ReqSeq
Recv With-Invalid-ReqSeq Close Channel none
RRorRNR
RecvREJorS- With-Invalid-ReqSeq-Retrans Close Channel none
REJ
Recv I-frame With-Invalid-TxSeq CloseChannelOrIgnore REJ_SENT
and TxWindow ≤ MaxTxWin÷2
and With-Valid-ReqSeq
Recv frame none Ignore REJ_SENT

Table 8.6: REJ_SENT state table

8.6.5.11 SREJ_SENT state table

Event Condition Action Next State

Recv I-frame With-Expected-TxSeq-Srej SaveIframeSrej RECV
and With-Valid-ReqSeq PopSrejList
and With-Valid-F-bit PassToTx
and SendRej = FALSE Data-IndicatioSrej
and SrejList = 1 BufferSeq := BufferSeqSrej
Send-Ack (F=0)
Recv I-frame With-Expected-TxSeq-Srej SaveIframeSrej REJ_SENT
and With-Valid-ReqSeq PopSrejList
and With-Valid-F-bit PassToTx
and SendRej = TRUE Data-IndicationSrej
and SrejList = 1 BufferSeq := BufferSeqSrej
Send REJ
Recv I-frame With-Expected-TxSeq-Srej SaveIframeSrej SREJ_SENT
and With-Valid-ReqSeq PopSrejList
and With-Valid-F-bit PassToTx
and SrejList > 1 Data-IndicationSrej

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 3, Part A Page 1228
Logical Link Control and Adaptation Protocol Specification

Event Condition Action Next State

Recv I-frame With-Expected-TxSeq SaveIframeSrej SREJ_SENT
and With-Valid-ReqSeq Increment-ExpectedTxSeq
and With-Valid-F-bit PassToTx
Recv I-frame With-Unexpected-TxSeq SaveIframeSrej SREJ_SENT
and With-Valid-ReqSeq PassToTx
and With-Valid-F-bit Send SREJ
and SendRej = FALSE PassToTx SREJ_SENT
SendRej := TRUE
Recv I-frame With-Unexpected-TxSeq PassToTx SREJ_SENT
and With-Valid-ReqSeq
and With-Valid-F-bit
and SendRej = TRUE
Recv I-frame With-Unexpected-TxSeq-Srej SaveIframeSrej SREJ_SENT
and With-Valid-ReqSeq PassToTx
and With-Valid-F-bit Send SREJ(SrejList)
Recv I-frame With-duplicate-TxSeq-Srej PassToTx SREJ_SENT
and With-Valid-ReqSeq
and With-Valid-F-bit
Recv RR(F=1) With-Valid-ReqSeq RemoteBusy := FALSE SREJ_SENT
and With-Valid-F-bit PassToTx
If RejActioned = FALSE then {
Retransmit-I-frames
} else {
RejActioned := FALSE
}
Send-Pending-I-frames
Recv RR(P=1) With-Valid-ReqSeq PassToTx SREJ_SENT
and With-Valid-F-bit If RemoteBusy = TRUE and Un-
ackedFrames > 0 then {
Start-RetransTimer
}
RemoteBusy := FALSE
Send SREJ(SrejList-tail)(F=1)

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 3, Part A Page 1229
Logical Link Control and Adaptation Protocol Specification

Event Condition Action Next State

Recv RR(P=0) With-Valid-ReqSeq PassToTx SREJ_SENT
(F=0) and With-Valid-F-bit If RemoteBusy = TRUE and Un-
ackedFrames > 0 then {
Start-RetransTimer
}
RemoteBusy := FALSE
Send-Ack(F=0)
Recv With-Valid-ReqSeq RemoteBusy := TRUE SREJ_SENT
RNR(P=1) and With-Valid-F-bit PassToTx
Send SREJ(SrejList-tail)(F=1)
Recv With-Valid-ReqSeq RemoteBusy := TRUE SREJ_SENT
RNR(P=0) and With-Valid-F-bit PassToTx
Send RR(F=0)
Recv REJ With-Valid-ReqSeq-Retrans RemoteBusy := FALSE SREJ_SENT
(F=0) and PassToTx
RetryIframes[i] < MaxTransmit Retransmit-I-frames
and With-Valid-F-bit Send-Pending-I-frames
If PbitOutstanding then {
RejActioned := TRUE
}
Recv REJ With-Valid-ReqSeq-Retrans RemoteBusy := FALSE SREJ_SENT
(F=1) and PassToTx
RetryIframes[i] < MaxTransmit If RejActioned = FALSE then {
and With-Valid-F-bit Retransmit-I-frames
} else {
RejActioned := FALSE
}
Send-Pending-I-frames
Recv With-Valid-ReqSeq-Retrans RemoteBusy := FALSE SREJ_SENT
SREJ(P=0) and RetryIframes[i] < MaxTrans- PassToTxFbit
(F=0) mit Retransmit-Requested-I-frame
and With-Valid-F-bit If PbitOutstanding then {
SrejActioned := TRUE
SrejSaveReqSeq = ReqSeq
}

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 3, Part A Page 1230
Logical Link Control and Adaptation Protocol Specification

Event Condition Action Next State

Recv With-Valid-ReqSeq-Retrans RemoteBusy := FALSE SREJ_SENT
SREJ(P=0) and RetryIframes[i] < MaxTrans- PassToTxFbit
(F=1) mit If SrejActioned = TRUE and
and With-Valid-F-bit SrejSaveReqSeq = ReqSeq
then {
SrejActioned := FALSE
} else {
Retransmit-Requested-I-
frame
}
Recv With-Valid-ReqSeq-Retrans RemoteBusy := FALSE SREJ_SENT
SREJ(P=1) and RetryIframes[i] < MaxTrans- PassToTx
mit Retransmit-Requested-I-frame
and With-Valid-F-bit Send-Pending-I-frames
If PbitOutstanding then {
SrejActioned := TRUE
SrejSaveReqSeq = ReqSeq
}
Recv REJ With-Valid-ReqSeq-Retrans Close Channel none
and RetryIframes[i] ≥ MaxTrans-
mit
Recv With-Valid-ReqSeqRetrans Close Channel none
SREJ(P=0) and
RetryIframes[i] ≥ MaxTransmit
Recv With-Valid-ReqSeqRetrans Close Channel none
SREJ(P=1) and
RetryIframes[i] ≥ MaxTransmit
Recv I-frame (With-Invalid-TxSeq Close Channel none
and TxWindow > MaxTxWin÷2)

or With-Invalid-ReqSeq
Recv With-Invalid-ReqSeq Close Channel none
RRorRNR
Recv REJorS- With-Invalid-ReqSeq-Retrans Close Channel none
REJ

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 3, Part A Page 1231
Logical Link Control and Adaptation Protocol Specification

Event Condition Action Next State

Recv I-frame With-Invalid-TxSeq CloseChannelOrIgnore SREJ_SENT
and TxWindow ≤ MaxTxWin÷2
Recv frame none Ignore SREJ_SENT

Table 8.7: SREJ_SENT state table

8.7 Streaming mode

When a link is configured to work in Streaming mode, the frame format for outgoing
data is the same as for Enhanced Retransmission mode but frames are not
acknowledged. Therefore

• RR, REJ, RNR and SREJ frames shall not be used in Streaming mode.
• The F-bit shall always be set to zero in the transmitter, and shall be ignored in the
receiver.
• the MonitorTimer and RetransmissionTimer shall not be used in Streaming mode.

A channel configured to work in Streaming mode shall be configured with a finite value
for the Flush Timeout on the transmitter.

8.7.1 Transmitting I-frames

When transmitting a new I-frame the control field parameter ReqSeq shall be set to 0,
TxSeq shall be set to NextTXSeq and NextTXSeq shall be incremented by one.

8.7.2 Receiving I-frames

Upon receipt of a valid I-frame with TxSeq equal to ExpectedTxSeq, the frame shall
be made available to the reassembly function. ExpectedTxSeq shall be incremented by
one.

Upon receipt of a valid I-frame with an out-of-sequence TxSeq (see Section 8.7.3.1) all
frames with a sequence number less than TxSeq shall be assumed lost and marked as
missing. The missing I-frames are in the range from ExpectedTxSeq (the frame that the
device was expecting to receive) up to and including TxSeq - 1. ExpectedTxSeq shall
be set to TxSeq +1. The received I-frame shall be made available for pulling by the
reassembly function. The ReqSeq shall be ignored.

Note: It is possible for a complete window size of I-frames to be missing and thus,
no missing I-frames are detected. For example, when a window size of 63 is used
this situation occurs when 63 I-frames in a row are missing. If the ability to not detect
missing I-frames will cause problems for an application, it is recommended that the
Extended Window Size option be used.

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 3, Part A Page 1232
Logical Link Control and Adaptation Protocol Specification

If there is no buffer space for the received I-frame an existing I-frame (i.e. the oldest)
shall be discarded (flushed) freeing up buffer space for the new I-frame. The discarded
I-frame shall be marked as missing.

8.7.3 Exception conditions

Exception conditions may occur as the result of physical layer errors or L2CAP
procedural errors. The error recovery procedures which are available following the
detection of an exception condition at the L2CAP layer in Streaming mode are defined
in this section.

8.7.3.1 TxSeq sequence error

A TxSeq sequence error exception condition occurs in the receiver when a valid I-frame
is received which contains a TxSeq value which is not equal to the expected value, thus
TxSeq is not equal to ExpectedTxSeq.

The out-of-sequence I-frame is identified by a TxSeq that is greater than

ExpectedTxSeq (TxSeq > ExpectedTXSeq). The ReqSeq shall be ignored. The missing
I-frame(s) are considered lost and ExpectedTXSeq is set equal to TxSeq+1 as specified
in Section 8.7.2. The missing I-frame(s) are reported as lost to the SDU reassembly
function.

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 3, Part A Page 1233
Logical Link Control and Adaptation Protocol Specification

9 [THIS SECTION IS NO LONGER USED]

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 3, Part A Page 1234
Logical Link Control and Adaptation Protocol Specification

10 PROCEDURES FOR CREDIT BASED FLOW

CONTROL

There are two credit-based flow control modes: LE Credit Based Flow Control mode
and Enhanced Credit Based Flow Control mode.

10.1 LE Credit Based Flow Control mode

LE Credit Based Flow Control mode is used for LE L2CAP connection-oriented

channels with flow control using a credit based scheme for L2CAP data (i.e. not
signaling packets).

The number of credits (K-frames) that can be received by a device on an L2CAP

channel is determined during connection establishment. K-frames shall only be
sent on an L2CAP channel if the device has a credit count greater than zero
for that L2CAP channel. For each K-frame sent the device decreases the credit
count for that L2CAP channel by one. The peer device may return credits for an
L2CAP channel at any time by sending an L2CAP_FLOW_CONTROL_CREDIT_IND
packet. When a credit packet is received by a device it shall increment the
credit count for that L2CAP channel by the value of the Credits field in this
packet. The number of credits returned for an L2CAP channel may exceed the
initial credits provided in the L2CAP_LE_CREDIT_BASED_CONNECTION_REQ or
L2CAP_LE_CREDIT_BASED_CONNECTION_RSP packet. The device sending the
L2CAP_FLOW_CONTROL_CREDIT_IND packet shall ensure that the number of
credits returned for an L2CAP channel does not cause the credit count to exceed
65535. The device receiving the credit packet shall disconnect the L2CAP channel if
the credit count exceeds 65535. The device shall also disconnect the L2CAP channel
if it receives a K-frame on an L2CAP channel from the peer device that has a credit
count of zero. If a device receives an L2CAP_FLOW_CONTROL_CREDIT_IND packet
with credit value set to zero, the packet shall be ignored. A device shall not send credit
values of zero in L2CAP_FLOW_CONTROL_CREDIT_IND packets.

If an L2CAP_LE_CREDIT_BASED_CONNECTION_REQ packet is received and there

is insufficient authentication between the two devices, the connection shall be
rejected with a result value of “Connection refused - insufficient authentication”. If
an L2CAP_LE_CREDIT_BASED_CONNECTION_REQ packet is received and there
is insufficient authorization between the two devices, the connection shall be
rejected with a result value of “Connection refused - insufficient authorization”. If
an L2CAP_LE_CREDIT_BASED_CONNECTION_REQ packet is received and the
encryption key size is too short, the connection shall be rejected with a result value
of “Connection refused – insufficient encryption key size”.

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 3, Part A Page 1235
Logical Link Control and Adaptation Protocol Specification

Note: When encryption is not enabled, the result value “Connection refused –
insufficient authentication” does not indicate that MITM protection is required.

10.2 Enhanced Credit Based Flow Control Mode

Enhanced Credit Based Flow Control mode is used for L2CAP connection-oriented
channels on LE and BR/EDR with flow control using a credit-based scheme for L2CAP
data (i.e. not signaling packets). The ACL logical transport shall have an infinite
Automatic Flush Timeout.

The number of credits (K-frames) that can be received by a device on an L2CAP

channel is determined during connection establishment. K-frames shall only be sent
on an L2CAP channel if the device has a credit count greater than zero for that
L2CAP channel. For each K-frame sent, the sending device shall decrease the credit
count for that L2CAP channel by one. The peer device may return credits for an
L2CAP channel at any time by sending an L2CAP_FLOW_CONTROL_CREDIT_IND
packet. When a credit packet is received by a device, it shall increment the
credit count for that L2CAP channel by the value of the Credits field in this
packet. The number of credits returned for an L2CAP channel may exceed
the initial credits provided in the L2CAP_CREDIT_BASED_CONNECTION_REQ
or L2CAP_CREDIT_BASED_CONNECTION_RSP packet. The device sending the
L2CAP_FLOW_CONTROL_CREDIT_IND packet shall ensure that the number of
credits returned for an L2CAP channel does not cause the credit count to exceed
65535. The device receiving the credit packet shall disconnect the L2CAP channel if
the credit count exceeds 65535. The device shall also disconnect the L2CAP channel
if it receives a K-frame on an L2CAP channel from the peer device that has a credit
count of zero. If a device receives an L2CAP_FLOW_CONTROL_CREDIT_IND packet
with credit value set to zero, the packet shall be ignored. A device shall not send credit
values of zero in L2CAP_FLOW_CONTROL_CREDIT_IND packets.

This paragraph applies if an L2CAP_CREDIT_BASED_CONNECTION_REQ packet is

received on the LE transport. If there is insufficient authentication between the two
devices, the connection shall be rejected with a result value of “All connections refused -
insufficient authentication”. If there is insufficient authorization between the two devices,
the connection shall be rejected with a result value of “All connections refused -
insufficient authorization”. If the encryption key size is too short, the connection shall
be rejected with a result value of “All connections refused - insufficient encryption key
size”.

Note: When encryption is not enabled, the result value “All connections refused -
insufficient authentication” does not indicate that MITM protection is required.

See [Vol 3] Part C, Section 5.2.2 for the requirements for responding to a received
L2CAP_CREDIT_BASED_CONNECTION_REQ packet.

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 3, Part A Page 1236
Logical Link Control and Adaptation Protocol Specification

Appendix A Configuration MSCs

The examples in this appendix describe a sample of the multiple possible configuration
scenarios that might occur.

Figure A.1 illustrates the basic configuration process. In this example, the devices
exchange MTU information. All other values are assumed to be default.

Device A Device B
L2CA L2CA
ConfigureChannel_Req
Option=0x01
[MTU=0x00000100]
L2CAP_CONFIGURATION_REQ

L2CAP_CONFIGURATION_RSP

ConfigureChannel_Req
Option=0x01
[MTU=0x00000200]
L2CAP_CONFIGURATION_REQ

L2CAP_CONFIGURATION_RSP

Figure A.1: Basic MTU exchange

Figure A.2 illustrates how two devices interoperate even though one device supports
more options than the other does. Device A is an upgraded version. It uses a
hypothetically defined option type 0x20 for link-level security. Device B rejects the
command using the L2CAP_CONFIGURATION_RSP packet with result ‘unknown
parameter’ informing Device A that option 0x20 is not understood. Device A then
resends the request omitting option 0x20. Device B notices that it does not need to
such a large MTU and accepts the request but includes in the response the MTU option
informing Device A that Device B will not send an L2CAP packet with a payload larger
than 0x80 octets over this channel. On receipt of the response, Device A could reduce
the buffer allocated to hold incoming traffic.

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 3, Part A Page 1237
Logical Link Control and Adaptation Protocol Specification

Device A Device B
L2CA L2CA
ConfigureChannel_Req
Option=0x01
[MTU=0x00000100]
Option=0x20 L2CAP_CONFIGURATION_REQ
[Data=0xFA12D823]

L2CAP_CONFIGURATION_RSP

L2CAP_CONFIGURATION_REQ

L2CAP_CONFIGURATION_RSP

ConfigureChannel_Req
Option=0x01
[MTU=0x00000200]
L2CAP_CONFIGURATION_REQ

L2CAP_CONFIGURATION_RSP

Figure A.2: Dealing with unknown options

Figure A.3 illustrates an unsuccessful configuration request. There are two problems
described by this example. The first problem is that the configuration request
is placed in an L2CAP packet that cannot be accepted by the remote device,
due to its size. The remote device informs the sender of this problem using the
L2CAP_COMMAND_REJECT_RSP message. Device A then resends the configuration
options using two smaller L2CAP_CONFIGURATION_REQ messages.

The second problem is an attempt to configure a channel with an invalid CID. For
example device B may have no open connection on that CID (0x01234567 in this
example case).

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 3, Part A Page 1238
Logical Link Control and Adaptation Protocol Specification

Device A Device B
L2CA L2CA
ConfigureChannel_Req

L2CAP_CONFIGURATION_REQ
ID=0x1234
DCID=0x01234567
Option=0x01
[MTU=0x00000100]
Option=0x20
[Data=BIG]

L2CAP_COMMAND_REJECT_RSP
ID=0x1234
Reason=0x0001
(MTU exceeded)
Data=0x80

L2CAP_CONFIGURATION_REQ
ID=0x1235
DCID=0x01234567
Option=0x01
[MTU=0x00000100]
C flag set to 1

Co
nfig
A P_ _ ura
tion
L 2 C N D P D
A
M _R S C r
ID= D= eque
I
M
COJECT35 02 0x 0x1 st
RE 0x12 0x00 Op01234236
= tio 5
=
ID aso IDn ) [Da n=0x67
Re alid C ta= 20
BIG
(Inv ]

L2CAP_COMMAND_REJECT_RSP
ID=0x1236
Reason=0x0002
(Invalid CID)

Figure A.3: Unsuccessful configuration request

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 3, Part A Page 1239
Logical Link Control and Adaptation Protocol Specification

Appendix B Changes to signaling packet names

Previous versions of this specification used different names for the signalling packets
defined in Section 4. Table B.1 shows the previous and current names of these packets.

Previous name Current name

Command reject L2CAP_COMMAND_REJECT_RSP
Configuration request L2CAP_CONFIGURATION_REQ
Configuration response L2CAP_CONFIGURATION_RSP
Connection Parameter Update request L2CAP_CONNECTION_PARAMETER_UPDATE_REQ
Connection Parameter Update response L2CAP_CONNECTION_PARAMETER_UPDATE_RSP
Connection request L2CAP_CONNECTION_REQ
Connection response L2CAP_CONNECTION_RSP
Disconnection request L2CAP_DISCONNECTION_REQ
Disconnection response L2CAP_DISCONNECTION_RSP
Echo request L2CAP_ECHO_REQ
Echo response L2CAP_ECHO_RSP
Information request L2CAP_INFORMATION_REQ
Information response L2CAP_INFORMATION_RSP
LE Credit Based Connection request L2CAP_LE_CREDIT_BASED_CONNECTION_REQ
LE Credit Based Connection response L2CAP_LE_CREDIT_BASED_CONNECTION_RSP
LE Flow Control Credit L2CAP_FLOW_CONTROL_CREDIT_IND

Table B.1: Changes to signaling packet names

Bluetooth SIG Proprietary Version Date: 2024-08-27

 Host
Part B

SERVICE DISCOVERY
PROTOCOL (SDP)
SPECIFICATION

This Part defines a protocol for locating services

provided by or available through a Bluetooth device.

Bluetooth SIG Proprietary

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 3, Part B Page 1241
Service Discovery Protocol (SDP) Specification

CONTENTS

1 Introduction ............................................................................................. 1244

1.1 General description ................................................................... 1244
1.2 [This section is no longer used] ................................................. 1244
1.3 [This section is no longer used] ................................................. 1244
1.4 [This section is no longer used] ................................................. 1244
1.5 Conventions .............................................................................. 1244
1.5.1 Bit and byte ordering conventions ............................. 1244

2 Overview .................................................................................................. 1245

2.1 SDP Client-Server architecture ................................................. 1245
2.2 Service record ........................................................................... 1246
2.3 Service attribute ........................................................................ 1247
2.3.1 Attribute ID ................................................................. 1248
2.3.2 Attribute value ............................................................ 1248
2.4 Service class ............................................................................. 1248
2.4.1 A printer service class example ................................. 1249
2.5 Searching for services ............................................................... 1249
2.5.1 UUID .......................................................................... 1250
2.5.2 Service search patterns ............................................. 1250
2.6 Browsing for services ................................................................ 1251
2.6.1 Example service browsing hierarchy ......................... 1251

3 Data representation ................................................................................ 1254

3.1 Data element ............................................................................. 1254
3.2 Data element type descriptor .................................................... 1254
3.3 Data element size descriptor ..................................................... 1255
3.4 Data element examples ............................................................ 1256

4 Protocol description ............................................................................... 1257

4.1 Transfer byte order .................................................................... 1257
4.2 Protocol Data Unit format .......................................................... 1257
4.3 Partial responses and continuation state .................................. 1258
4.4 Error handling ............................................................................ 1259
4.4.1 SDP_ERROR_RSP PDU .......................................... 1260
4.5 Service Search transaction ....................................................... 1260
4.5.1 SDP_SERVICE_SEARCH_REQ PDU ...................... 1261
4.5.2 SDP_SERVICE_SEARCH_RSP PDU ....................... 1262
4.6 Service Attribute transaction ..................................................... 1263
4.6.1 SDP_SERVICE_ATTR_REQ PDU ............................ 1264
4.6.2 SDP_SERVICE_ATTR_RSP PDU ............................ 1265

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 3, Part B Page 1242
Service Discovery Protocol (SDP) Specification

4.7 Service Search Attribute transaction ......................................... 1266

4.7.1 SDP_SERVICE_SEARCH_ATTR_REQ PDU ........... 1267
4.7.2 SDP_SERVICE_SEARCH_ATTR_RSP PDU ........... 1269

5 Service attribute definitions ................................................................... 1271

5.1 Universal attribute definitions .................................................... 1271
5.1.1 ServiceRecordHandle attribute .................................. 1271
5.1.2 ServiceClassIDList attribute ....................................... 1272
5.1.3 ServiceRecordState attribute ..................................... 1272
5.1.4 ServiceID attribute ..................................................... 1272
5.1.5 ProtocolDescriptorList attribute ................................. 1273
5.1.6 AdditionalProtocolDescriptorLists attribute ................ 1274
5.1.7 BrowseGroupList attribute ......................................... 1275
5.1.8 LanguageBaseAttributeIDList attribute ...................... 1275
5.1.9 ServiceInfoTimeToLive attribute ................................ 1276
5.1.10 ServiceAvailability attribute ........................................ 1276
5.1.11 BluetoothProfileDescriptorList attribute ..................... 1277
5.1.12 DocumentationURL attribute ..................................... 1278
5.1.13 ClientExecutableURL attribute .................................. 1278
5.1.14 IconURL attribute ....................................................... 1278
5.1.15 ServiceName attribute ............................................... 1279
5.1.16 ServiceDescription attribute ....................................... 1279
5.1.17 ProviderName attribute .............................................. 1280
5.1.18 [This section is no longer used] ................................. 1280
5.2 ServiceDiscoveryServer service class attribute definitions ....... 1280
5.2.1 ServiceRecordHandle attribute .................................. 1280
5.2.2 ServiceClassIDList attribute ....................................... 1280
5.2.3 VersionNumberList attribute ...................................... 1281
5.2.4 ServiceDatabaseState attribute ................................. 1281
5.2.5 [This section is no longer used] ................................. 1281
5.3 BrowseGroupDescriptor service class attribute definitions ....... 1281
5.3.1 ServiceClassIDList attribute ....................................... 1282
5.3.2 GroupID attribute ....................................................... 1282
5.3.3 [This section is no longer used] ................................. 1282

6 Security .................................................................................................... 1283

Appendix A [This appendix is no longer used] ............................................... 1284

Appendix B Example SDP Transactions .......................................................... 1285

B.1 SDP example 1 – ServiceSearchRequest ................................ 1285
B.2 SDP example 2 – ServiceAttributeTransaction ......................... 1287
B.3 SDP example 3 – ServiceSearchAttributeTransaction .............. 1292

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 3, Part B Page 1243
Service Discovery Protocol (SDP) Specification

Appendix C Changes to PDU names ................................................................ 1303

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 3, Part B Page 1244
Service Discovery Protocol (SDP) Specification

1 INTRODUCTION

1.1 General description

The Service Discovery protocol (SDP) provides a means for applications to discover
which services are available and to determine the characteristics of those available
services.

1.2 [This section is no longer used]

1.3 [This section is no longer used]

1.4 [This section is no longer used]

1.5 Conventions
1.5.1 Bit and byte ordering conventions

When multiple bit fields are contained in a single byte and represented in a drawing
in this Part, the more significant (high-order) bits are shown toward the left and less
significant (low-order) bits toward the right.

Multiple-byte fields are drawn with the more significant bytes toward the left and the less
significant bytes toward the right. Multiple-byte fields are transferred in network byte
order. See Section 4.1.

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 3, Part B Page 1245
Service Discovery Protocol (SDP) Specification

2 OVERVIEW

2.1 SDP Client-Server architecture

Figure 2.1: SDP Client-Server interaction

The service discovery mechanism provides the means for client applications to discover
the existence of services provided by server applications as well as the attributes of
those services. The attributes of a service include the type or class of service offered
and the mechanism or protocol information needed to utilize the service.

From the perspective of the Service Discovery Protocol (SDP), the configuration shown
in Figure 2.1 can be simplified to that shown in Figure 2.2.

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 3, Part B Page 1246
Service Discovery Protocol (SDP) Specification

Figure 2.2: Simplified SDP Client-Server interaction

SDP involves communication between an SDP Server and an SDP Client. The server
maintains an SDP database which consists of a list of service records that describe
the characteristics of services associated with the server. Each service record contains
information about a single service. A client can retrieve information from a service
record maintained by the SDP Server by issuing an SDP request.

If the client, or an application associated with the client, decides to use a service, it
opens a separate connection to the service provider in order to utilize the service. SDP
provides a mechanism for discovering services and their attributes (including associated
service access protocols), but it does not provide a mechanism for utilizing those
services (such as delivering the service access protocols).

If multiple applications on a device provide services, an SDP Server can act on behalf of
those service providers to handle requests for information about the services that they
provide. Similarly, multiple client applications can utilize an SDP Client to query servers
on behalf of the client applications.

The set of SDP Servers that are available to an SDP Client will change dynamically
based on the RF proximity of the servers to the client. When a server becomes
available, a potential client must be notified by a means other than SDP so that the
client can use SDP to query the server about its services. Similarly, when a server
leaves proximity or becomes unavailable for any reason, there is no explicit notification
via the Service Discovery protocol. However, the client can use SDP to poll the server
and may infer that the server is not available if it no longer responds to requests.

Additional information regarding application interaction with SDP shall be contained in

the Bluetooth Service Discovery Profile document.

2.2 Service record

A service is any entity that can provide information, perform an action, or control
a resource on behalf of another entity. A service may be implemented as software,
hardware, or a combination of hardware and software.

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 3, Part B Page 1247
Service Discovery Protocol (SDP) Specification

All of the information about a service that is maintained by an SDP Server is contained
within a single service record. The service record shall only be a list of service
attributes.

A service record handle is a 32-bit number that shall uniquely identify each service
record within an SDP Server. In general, each handle is unique only within each SDP
Server. If SDP Server S1 and SDP Server S2 both contain identical service records
(representing the same service), the service record handles used to reference these
identical service records are completely independent. The handle used to reference the
service on S1 will be meaningless if presented to S2.

The Service Discovery protocol does not provide a mechanism for notifying clients
when service records are added to or removed from an SDP Server. While an L2CAP
(Logical Link Control and Adaptation Protocol) connection is established to a server, a
service record handle acquired from the server shall remain valid unless the service
record it represents is removed. If a service is removed from the server, further requests
to the server (during the L2CAP connection in which the service record handle was
acquired) using the service’s (now stale) record handle shall result in an error response
indicating an invalid service record handle. An SDP Server shall ensure that no service
record handle values are re-used while an L2CAP connection remains established.
Service record handles shall remain valid across successive L2CAP connections
while the ServiceDatabaseState attribute value remains unchanged. Further, service
record handles should remain valid until such time that the corresponding service is
permanently removed or changes in an incompatible way. See the ServiceRecordState
and ServiceDatabaseState attributes in Section 5.

A device may have a service record with a service record handle of 0x00000000
representing the SDP Server itself. This service record contains attributes for the SDP
Server and the protocol it supports. For example, one of its attributes is the list of SDP
protocol versions supported by the server.

2.3 Service attribute

Each service attribute describes a single characteristic of a service. Some examples of

service attributes are given in Table 2.1.

ServiceClassIDList Identifies the type of service represented by a service record. In other

words, the list of classes of which the service is an instance
ServiceID Uniquely identifies a specific instance of a service
ProtocolDescriptorList Specifies the protocol stack(s) that may be used to utilize a service
ProviderName The textual name of the individual or organization that provides a service
IconURL Specifies a URL that refers to an icon image that may be used to represent
a service

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 3, Part B Page 1248
Service Discovery Protocol (SDP) Specification

ServiceName A text string containing a human-readable name for the service

ServiceDescription A text string describing the service
Table 2.1: Example service attributes

See Section 5.1 for attribute definitions that are common to all service records. Service
providers can also define their own service attributes.

A service attribute consists of two components: an attribute ID and an attribute value.

2.3.1 Attribute ID

An attribute ID is a 16-bit unsigned integer that distinguishes each service attribute

from other service attributes within a service record. The attribute ID also identifies the
semantics of the associated attribute value.

A service class definition specifies each of the attribute IDs for a service class and
assigns a meaning to the attribute value associated with each attribute ID. Each
attribute ID is defined to be unique only within each service class.

All services belonging to a given service class assign the same meaning to each
particular attribute ID. See Section 2.4.

In the Service Discovery protocol, an attribute ID is represented as a data element. See

Section 3.

2.3.2 Attribute value

The attribute value is a variable length field whose meaning is determined by the
attribute ID associated with it and by the service class of the service record in which
the attribute is contained. In the Service Discovery protocol, an attribute value is
represented as a data element. (See Section 3.) Generally, any type of data element
is permitted as an attribute value, subject to the constraints specified in the service
class definition that assigns an attribute ID to the attribute and assigns a meaning to the
attribute value. See Section 5, for attribute value examples.

2.4 Service class

Each service is an instance of a service class. The service class definition provides
the definitions of all attributes contained in service records that represent instances of
that class. Each attribute definition specifies the numeric value of the attribute ID, the
intended use of the attribute value, and the format of the attribute value. A service
record contains attributes that are specific to a service class as well as universal
attributes that are common to all services.

Each service class is also assigned a unique identifier. This service class identifier is
contained in the attribute value for the ServiceClassIDList attribute, and is represented

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 3, Part B Page 1249
Service Discovery Protocol (SDP) Specification

as a UUID (see Section 2.5.1). Since the format and meanings of many attributes
in a service record are dependent on the service class of the service record, the
ServiceClassIDList attribute is very important. Its value shall be examined or verified
before any class-specific attributes are used. Since all of the attributes in a service
record must conform to all of the service’s classes, the service class identifiers
contained in the ServiceClassIDList attribute are related. Typically, each service class is
a subclass of another class whose identifier is contained in the list. A service subclass
definition differs from its superclass in that the subclass contains additional attribute
definitions that are specific to the subclass.

When a new service class is defined that is a subclass of an existing service class,
the new service class retains all of the attributes defined in its superclass. Additional
attributes may be defined that are specific to the new service class. In other words, the
mechanism for adding new attributes to some of the instances of an existing service
class is to create a new service class that is a subclass of the existing service class.

If a Service Class UUID is exposed in the SDP database of a product, then the product
containing the SDP record shall comply with the specification which defines the service
corresponding to the UUID.

2.4.1 A printer service class example

A color postscript printer with duplex capability might conform to 4 ServiceClass

definitions and have a ServiceClassIDList with UUIDs (See Section 2.5.1.) representing
the following ServiceClasses:

DuplexColorPostscriptPrinterServiceClassID,
ColorPostscriptPrinterServiceClassID,
PostscriptPrinterServiceClassID,
PrinterServiceClassID

This example is only illustrative. This is not necessarily a practical printer class
hierarchy.

2.5 Searching for services

The Service Search transaction allows a client to retrieve the service record handles
for particular service records based on the values of attributes contained within those
service records. Once an SDP Client has a service record handle, it can request the
values of specific attributes.

The capability search for service records based on the values of arbitrary attributes
is not provided. Rather, the capability is provided to search only for attributes whose

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 3, Part B Page 1250
Service Discovery Protocol (SDP) Specification

values are Universally Unique Identifiers1 (UUIDs). Important attributes of services that
can be used to search for a service are represented as UUIDs.

2.5.1 UUID

A UUID is a universally unique identifier that is expected to be unique across all space
and all time (more precisely, the probability of independently-generated UUIDs being the
same is negligible). UUIDs can be independently created in a distributed fashion. No
central registry of assigned UUIDs is required. A UUID is a 128-bit value.

To reduce the burden of storing and transferring 128-bit UUID values, a range of UUID
values has been pre-allocated for assignment to often-used, registered purposes. The
first UUID in this pre-allocated range is known as the Bluetooth_Base_UUID and has
the value 00000000-0000-1000-8000-00805F9B34FB. UUID values in the pre-allocated
range have aliases that are represented as 16-bit or 32-bit values. These aliases are
often called 16-bit and 32-bit UUIDs, but each actually represents a 128-bit UUID value.

The full 128-bit value of a 16-bit or 32-bit UUID may be computed by a simple arithmetic
operation.

128_bit_value = 16_bit_value × 296 + Bluetooth_Base_UUID

128_bit_value = 32_bit_value × 296 + Bluetooth_Base_UUID

A 16-bit UUID may be converted to 32-bit UUID format by zero-extending the 16-bit
value to 32-bits. An equivalent method is to add the 16-bit UUID value to a zero-valued
32-bit UUID.

Note: Two 16-bit UUIDs may be compared directly, as may two 32-bit UUIDs or two
128-bit UUIDs. If two UUIDs of differing sizes are to be compared, the shorter UUID
must be converted to the longer UUID format before comparison.

2.5.2 Service search patterns

A service search pattern is a list of UUIDs used to locate matching service records. A
service search pattern matches a service record if each and every UUID in the service
search pattern is contained within any of the service record’s attribute values. The
UUIDs need not be contained within any specific attributes or in any particular order
within the service record. The service search pattern matches if the UUIDs it contains
constitute a subset of the UUIDs in the service record’s attribute values. The only time
a service search pattern does not match a service record is if the service search pattern
contains at least one UUID that is not contained within the service record’s attribute
values. A valid service search pattern shall contain at least one UUID.

1The format of UUIDs is specified in ITU-T Rec. X.667(10/2012), alternatively known as ISO/IEC 9834-8:2014.

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 3, Part B Page 1251
Service Discovery Protocol (SDP) Specification

2.6 Browsing for services

Normally, a client searches for services based on some desired characteristic(s)
(represented by a UUID) of the services. However, there are times when it is desirable
to discover which types of services are described by an SDP Server’s service records
without any a priori information about the services. This process of looking for any
offered services is termed browsing. In SDP, the mechanism for browsing for services
is based on an attribute shared by all service classes. This attribute is called the
BrowseGroupList attribute. The value of this attribute contains a list of UUIDs. Each
UUID represents a browse group with which a service may be associated for the
purpose of browsing.

When a client desires to browse an SDP Server’s services, it creates a service search
pattern containing the UUID that represents the root browse group. All services that
may be browsed at the top level are made members of the root browse group by having
the root browse group’s UUID as a value within the BrowseGroupList attribute.

Normally, if an SDP Server has relatively few services, all of its services will be placed
in the root browse group. However, the services offered by an SDP Server may be
organized in a browse group hierarchy, by defining additional browse groups below the
root browse group. Each of these additional browse groups is described by a service
record with a service class of BrowseGroupDescriptor.

A browse group descriptor service record defines a new browse group by means of
its Group ID attribute. In order for a service contained in one of these newly defined
browse groups to be browseable, the browse group descriptor service record that
defines the new browse group must in turn be browseable. The hierarchy of browseable
services that is provided by the use of browse group descriptor service records allows
the services contained in an SDP Server to be incrementally browsed and is particularly
useful when the SDP Server contains many service records.

2.6.1 Example service browsing hierarchy

Figure 2.3 illustrates a fictitious service browsing hierarchy that illuminates the manner
in which browse group descriptors are used. Browse group descriptor service records
are identified with (G); other service records with (S).

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 3, Part B Page 1252
Service Discovery Protocol (SDP) Specification

Figure 2.3: Service browsing hierarchy

Table 2.2 shows the services records and service attributes necessary to implement the
browse hierarchy.

Service Name Service Class Attribute Name Attribute Value

Entertainment BrowseGroupDescriptor BrowseGroupList PublicBrowseRoot
GroupID EntertainmentID
News BrowseGroupDescriptor BrowseGroupList PublicBrowseRoot
GroupID NewsID
Reference BrowseGroupDescriptor BrowseGroupList PublicBrowseRoot
GroupID ReferenceID
Games BrowseGroupDescriptor BrowseGroupList EntertainmentID
GroupID GamesID
Movies BrowseGroupDescriptor BrowseGroupList EntertainmentID
GroupID MoviesID
Starcraft Video Game Class ID BrowseGroupList GamesID
A Bug’s Life Movie Class ID BrowseGroupList MovieID
Dictionary Z Dictionary Class ID BrowseGroupList ReferenceID
Encyclopedia X Encyclopedia Class ID BrowseGroupList ReferenceID
New York Times Newspaper ID BrowseGroupList NewspaperID

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 3, Part B Page 1253
Service Discovery Protocol (SDP) Specification

Service Name Service Class Attribute Name Attribute Value

London Times Newspaper ID BrowseGroupList NewspaperID
Local Newspaper Newspaper ID BrowseGroupList NewspaperID

Table 2.2: Service browsing hierarchy

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 3, Part B Page 1254
Service Discovery Protocol (SDP) Specification

3 DATA REPRESENTATION

Attribute values can contain information of various types with arbitrary complexity; thus
enabling an attribute list to be generally useful across a wide variety of service classes
and environments.

SDP defines a simple mechanism to describe the data contained within an attribute ID,
attribute ID range, and attribute value. The primitive construct used is the data element.

3.1 Data element

A data element is a typed data representation. It consists of two fields: a header field
and a data field. The header field, in turn, is composed of two parts: a type descriptor
and a size descriptor. The data is a sequence of bytes whose length is specified in the
size descriptor (described in Section 3.3) and whose meaning is (partially) specified by
the type descriptor.

3.2 Data element type descriptor

A data element type is represented as a 5-bit type descriptor. The type descriptor is
contained in the most significant (high-order) 5 bits of the first byte of the data element
header. The following types have been defined.

Type Valid Size Descriptor Type Description

Descriptor Values
Value
0 0 Nil, the null type
1 0, 1, 2, 3, 4 Unsigned integer
2 0, 1, 2, 3, 4 Signed integer
3 1, 2, 4 UUID, a universally unique identifier
4 5, 6, 7 Text string
5 0 Boolean (see below)
6 5, 6, 7 Data element sequence, a data element whose data
field is a sequence of data elements
7 5, 6, 7 Data element alternative, data element whose data field
is a sequence of data elements from which one data
element is to be selected.
8 5, 6, 7 URL, a uniform resource locator
Other Reserved for future use

Table 3.1: Data element

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 3, Part B Page 1255
Service Discovery Protocol (SDP) Specification

For the boolean type, false shall be represented by the value 0 and true shall be
represented by the value 1. Any other value received shall be accepted as representing
true.

3.3 Data element size descriptor

The data element size descriptor is represented as a 3-bit size index followed by 0, 8,
16, or 32 bits. The size index is contained in the least significant (low-order) 3 bits of the
first byte of the data element header. The size index is encoded as follows.

Size Index Additional bits Data Size

0 0 1 byte. Exception: if the data element type is nil, the data size is 0
bytes.
1 0 2 bytes
2 0 4 bytes
3 0 8 bytes
4 0 16 bytes
5 8 The data size is contained in the additional 8 bits, which are interpre-
ted as an unsigned integer.
6 16 The data size is contained in the additional 16 bits, which are interpre-
ted as an unsigned integer.
7 32 The data size is contained in the additional 32 bits, which are interpre-
ted as an unsigned integer.

Table 3.2: Data element size

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 3, Part B Page 1256
Service Discovery Protocol (SDP) Specification

3.4 Data element examples

Figure 3.1: Data element

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 3, Part B Page 1257
Service Discovery Protocol (SDP) Specification

4 PROTOCOL DESCRIPTION

SDP is a simple protocol with minimal requirements on the underlying transport. It can
function over a reliable packet transport (or even unreliable, if the client implements
timeouts and repeats requests as necessary).

SDP uses a request/response model where each transaction consists of one request
protocol data unit (PDU) and one response PDU. In the case where SDP is used
with the Bluetooth L2CAP transport protocol, no more than one SDP request PDU per
connection to a given SDP Server shall be outstanding at a given instant. In other
words, a client shall wait for a response to its current request before issuing another
request on the same L2CAP connection. Limiting SDP to sending one unacknowledged
request PDU provides a simple form of flow control.

The protocol examples found in Appendix B could be helpful in understanding the

protocol transactions.

4.1 Transfer byte order

The Service Discovery protocol shall transfer multiple-byte fields in standard network
byte order (big-endian), with more significant (high-order) bytes being transferred before
less-significant (low-order) bytes.

4.2 Protocol Data Unit format

Every SDP PDU consists of a PDU header followed by PDU-specific parameters. The
header contains three fields: a PDU ID, a Transaction ID, and a ParameterLength. Each
of these header fields is described here. Parameters may include a continuation state
parameter, described below; PDU-specific parameters for each PDU type are described
later in separate PDU descriptions.

Figure 4.1: Protocol Data Unit format

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 3, Part B Page 1258
Service Discovery Protocol (SDP) Specification

PDU ID: Size: 1 Byte

Value Parameter Description

N The PDU ID field identifies the type of PDU. I.e. its meaning and the specific
parameters.
0x01 SDP_ERROR_RSP
0x02 SDP_SERVICE_SEARCH_REQ
0x03 SDP_SERVICE_SEARCH_RSP
0x04 SDP_SERVICE_ATTR_REQ
0x05 SDP_SERVICE_ATTR_RSP
0x06 SDP_SERVICE_SEARCH_ATTR_REQ
0x07 SDP_SERVICE_SEARCH_ATTR_RSP
All other values Reserved for future use

TransactionID: Size: 2 Bytes

Value Parameter Description

N The TransactionID field uniquely identifies request PDUs and is used to
match response PDUs to request PDUs. The SDP Client can choose any
value for a request’s TransactionID provided that it is different from all out-
standing requests. The TransactionID value in response PDUs is required to
be the same as the request that is being responded to.
Range: 0x0000 to 0xFFFF

ParameterLength: Size: 2 Bytes

Value Parameter Description

N The ParameterLength field specifies the length (in bytes) of all parameters
contained in the PDU.
Range: 0x0000 to 0xFFFF

4.3 Partial responses and continuation state

Some SDP requests may require responses that are larger than can fit in a single
response PDU. In this case, the SDP Server shall generate a partial response along
with a continuation state parameter. The continuation state parameter can be supplied
by the client in a subsequent request to retrieve the next portion of the complete
response. The continuation state parameter is a variable length field whose first
byte contains the number of additional bytes of continuation information in the field
(InfoLength).

The format of the continuation information is not standardized among SDP Servers.
Each continuation state parameter is meaningful only to the SDP Server that generated

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 3, Part B Page 1259
Service Discovery Protocol (SDP) Specification

it. The SDP Server should not expose any sensitive information, such as internal
data structures, in the continuation state parameter. The SDP Server should validate
a continuation state parameter supplied by the client before using it.

Figure 4.2: Continuation state format

After a client receives a partial response and the accompanying continuation state
parameter, it can re-issue the original request (with a new transaction ID) and include
the continuation state in the new request indicating to the server that the remainder of
the original response is desired. The maximum allowable value of the InfoLength field is
16 (0x10).

Unless otherwise stated in a PDU response specification, an SDP Server may split
a response at any arbitrary boundary when it generates a partial response. The
SDP Server may select the boundary based on the contents of the reply, but is not
required to do so. Therefore, length fields give the lengths as measured in the complete
assembled record, not the length of the fields in the partial segment. When a service
record is segmented into partial responses all attribute list values are relative to the
complete record, not relevant to the partial record.

4.4 Error handling

Each transaction consists of a request and a response PDU. Generally, each type
of request PDU has a corresponding type of response PDU. However, if the server
determines that a request is improperly formatted or for any reason the server cannot
respond with the appropriate PDU type, it shall respond with an SDP_ERROR_RSP
PDU.

Client Server

Any Request

SDP_ERROR_RSP

Figure 4.3: Error handling

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 3, Part B Page 1260
Service Discovery Protocol (SDP) Specification

4.4.1 SDP_ERROR_RSP PDU

PDU Type PDU ID Parameters

SDP_ERROR_RSP 0x01 ErrorCode

Description:

The SDP Server generates this PDU type in response to an improperly formatted
request PDU or when the SDP Server, for whatever reason, cannot generate an
appropriate response PDU.

PDU parameters:

ErrorCode: Size: 2 Bytes

Value Parameter Description

N The ErrorCode identifies the reason that an SDP_ERROR_RSP PDU was
generated.
0x0001 Invalid/unsupported SDP version
0x0002 Invalid Service Record Handle
0x0003 Invalid request syntax
0x0004 Invalid PDU Size
0x0005 Invalid Continuation State
0x0006 Insufficient Resources to satisfy Request
All other values Reserved for future use

Note: Invalid PDU size should be used, for example, if an incoming request PDU's
length is inconsistent with the specification of that request PDU or the length parameter
of an incoming request PDU is inconsistent with that request PDU's actual contents.

4.5 Service Search transaction

Client Server

SDP_SERVICE_SEARCH_REQ

SDP_SERVICE_SEARCH_RSP

Figure 4.4: Service Search transaction

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 3, Part B Page 1261
Service Discovery Protocol (SDP) Specification

4.5.1 SDP_SERVICE_SEARCH_REQ PDU

PDU Type PDU ID Parameters

SDP_SERVICE_SEARCH_REQ 0x02 ServiceSearchPattern,
MaximumServiceRecordCount,
ContinuationState

Description:

The SDP Client generates an SDP_SERVICE_SEARCH_REQ to locate service records

that match the service search pattern given as the first parameter of the PDU. Upon
receipt of this request, the SDP Server shall examine its service record data base
and return an SDP_SERVICE_SEARCH_RSP containing the service record handles of
service records within its SDP database that match the given service search pattern, or
an appropriate error response.

No mechanism is provided to request information for all service records. However, see
Section 2.6 for a description of a mechanism that permits browsing for non-specific
services without a priori knowledge of the services.

PDU parameters:

ServiceSearchPattern: Size: Varies

Value Parameter Description

Data Element Se- The ServiceSearchPattern is a data element sequence where each element
quence in the sequence is a UUID. The sequence shall contain at least one UUID.
The maximum number of UUIDs in the sequence is 121. The list of UUIDs
constitutes a service search pattern.
1The value of 12 has been selected as a compromise between the scope of a service search and the size
of a search request PDU. It is not expected that more than 12 UUIDs will be useful in a service search
pattern.

MaximumServiceRecordCount: Size: 2 Bytes

Value Parameter Description

N MaximumServiceRecordCount is a 16-bit count specifying the maximum
number of service record handles to be returned in the response(s) to
this request. The SDP Server shall not return more handles than this val-
ue specifies. If more than N service records match the request, the SDP
Server determines which matching service record handles to return in the
response(s).
Range: 0x0001 to 0xFFFF

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 3, Part B Page 1262
Service Discovery Protocol (SDP) Specification

ContinuationState: Size: 1 to 17 Bytes

Value Parameter Description

Continuation State ContinuationState consists of an 8-bit count, N, of the number of bytes of
continuation state information, followed by the N bytes of continuation state
information that were returned in a previous response from the server. N
is required to be less than or equal to 16. If no continuation state is to be
provided in the request, N is set to 0.

4.5.2 SDP_SERVICE_SEARCH_RSP PDU

PDU Type PDU ID Parameters

SDP_SERVICE_SEARCH_RSP 0x03 TotalServiceRecordCount,
CurrentServiceRecordCount,
ServiceRecordHandleList,
ContinuationState

Description:

The SDP Server generates an SDP_SERVICE_SEARCH_RSP upon receipt of a valid

SDP_SERVICE_SEARCH_REQ. The response contains a list of service record handles
for service records that match the service search pattern given in the request. If a partial
response is generated, it shall only contain complete service record handles; a service
record handle value shall not be split across multiple PDUs.

PDU parameters:

TotalServiceRecordCount: Size: 2 Bytes

Value Parameter Description

N The TotalServiceRecordCount is an integer containing the number of serv-
ice records that match the requested service search pattern. If no service
records match the requested service search pattern, this parameter is set
to 0. N should never be larger than the MaximumServiceRecordCount val-
ue specified in the SDP_SERVICE_SEARCH_REQ. When multiple partial
responses are used, each partial response contains the same value for
TotalServiceRecordCount.
Range: 0x0000 to 0xFFFF

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 3, Part B Page 1263
Service Discovery Protocol (SDP) Specification

CurrentServiceRecordCount: Size: 2 Bytes

Value Parameter Description

N The CurrentServiceRecordCount is an integer indicating the number of serv-
ice record handles that are contained in the next parameter. If no service
records match the requested service search pattern, this parameter is set
to 0. N should never be larger than the TotalServiceRecordCount value
specified in the current response.
Range: 0x0000 to 0xFFFF

ServiceRecordHandleList: Size: (CurrentServiceRecordCount×4) Bytes

Value Parameter Description

List of 32-bit handles The ServiceRecordHandleList contains a list of service record handles. The
number of handles in the list is given in the CurrentServiceRecordCount
parameter. Each of the handles in the list refers to a service record that
matches the requested service search pattern. This list of service record
handles does not have the format of a data element. It contains no header
fields, only the 32-bit service record handles.

ContinuationState: Size: 1 to 17 Bytes

Value Parameter Description

Continuation State ContinuationState consists of an 8-bit count, N, of the number of bytes
of continuation state information, followed by the N bytes of continuation
information. If the current response is complete, this parameter consists of
a single byte with the value 0. If a partial response is contained in the PDU,
the ContinuationState parameter may be supplied in a subsequent request
to retrieve the remainder of the response.

4.6 Service Attribute transaction

Client Server

SDP_SERVICE_ATTR_REQ

SDP_SERVICE_ATTR_RSP

Figure 4.5: Service Attribute transaction

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 3, Part B Page 1264
Service Discovery Protocol (SDP) Specification

4.6.1 SDP_SERVICE_ATTR_REQ PDU

PDU Type PDU ID Parameters

SDP_SERVICE_ATTR_REQ 0x04 ServiceRecordHandle,
MaximumAttributeByteCount,
AttributeIDList,
ContinuationState

Description:

The SDP Client generates an SDP_SERVICE_ATTR_REQ to retrieve specified attribute

values from a specific service record. The service record handle of the desired service
record and a list of desired attribute IDs to be retrieved from that service record are
supplied as parameters.

Command parameters:

ServiceRecordHandle: Size: 4 Bytes

Value Parameter Description

32-bit handle The ServiceRecordHandle parameter specifies the service record from
which attribute values are to be retrieved. The handle is obtained via a
previous Service Search transaction.

MaximumAttributeByteCount: Size: 2 Bytes

Value Parameter Description

N MaximumAttributeByteCount specifies the maximum number of bytes of at-
tribute data to be returned in the response to this request. The SDP Server
shall not return more than N bytes of attribute data in the response PDU.
If the requested attributes require more than N bytes, the SDP Server deter-
mines how to segment the list. In this case the client may request each
successive segment by issuing a request containing the continuation state
that was returned in the previous response PDU. In the case where multiple
response PDUs are needed to return the attribute data, MaximumAttribute-
ByteCount specifies the maximum size of the portion of the attribute data
contained in each response PDU.
Range: 0x0007 to 0xFFFF

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 3, Part B Page 1265
Service Discovery Protocol (SDP) Specification

AttributeIDList: Size: Varies

Value Parameter Description

Data Element Se- The AttributeIDList is a data element sequence where each element in the
quence list is either an attribute ID or a range of attribute IDs. Each attribute ID is
encoded as a 16-bit unsigned integer data element. Each attribute ID range
is encoded as a 32-bit unsigned integer data element, where the high order
16 bits are interpreted as the beginning attribute ID of the range and the
low order 16 bits are interpreted as the ending attribute ID of the range.
The attribute IDs contained in the AttributeIDList shall be listed in ascending
order without duplication of any attribute ID values. Note: All attributes can
be requested by specifying the range 0x0000 to 0xFFFF.

ContinuationState: Size: 1 to 17 Bytes

Value Parameter Description

Continuation State ContinuationState consists of an 8-bit count, N, of the number of bytes of
continuation state information, followed by the N bytes of continuation state
information that were returned in a previous response from the server. N
shall be less than or equal to 16. If no continuation state is to be provided in
the request, N shall be set to 0.

4.6.2 SDP_SERVICE_ATTR_RSP PDU

PDU Type PDU ID Parameters

SDP_SERVICE_ATTR_RSP 0x05 AttributeListByteCount,
AttributeList,
ContinuationState

Description:

The SDP Server generates an SDP_SERVICE_ATTR_RSP upon receipt of a valid

SDP_SERVICE_ATTR_REQ. The response contains a list of attributes (both attribute
ID and attribute value) from the requested service record.

PDU parameters:

AttributeListByteCount: Size: 2 Bytes

Value Parameter Description

N The AttributeListByteCount contains a count of the number of bytes in the
AttributeList parameter. N shall never be larger than the MaximumAttribute-
ByteCount value specified in the SDP_SERVICE_ATTR_REQ.
Range: 0x0002 to 0xFFFF

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 3, Part B Page 1266
Service Discovery Protocol (SDP) Specification

AttributeList: Size: AttributeListByteCount

Value Parameter Description

Data Element Se- The AttributeList is a data element sequence containing attribute IDs and
quence attribute values. The first element in the sequence contains the attribute ID
of the first attribute to be returned. The second element in the sequence
contains the corresponding attribute value. Successive pairs of elements in
the list contain additional attribute ID and value pairs. Only attributes that
have non-null values within the service record and whose attribute IDs were
specified in the SDP_SERVICE_ATTR_REQ are contained in the AttributeL-
ist. Neither an attribute ID nor an attribute value is placed in the AttributeList
for attributes in the service record that have no value. The attributes are
listed in ascending order of attribute ID value.

ContinuationState: Size: 1 to 17 Bytes

Value Parameter Description

Continuation State ContinuationState consists of an 8-bit count, N, of the number of bytes
of continuation state information, followed by the N bytes of continuation
information. If the current response is complete, this parameter consists of a
single byte with the value 0. If a partial response is given, the Continuation-
State parameter may be supplied in a subsequent request to retrieve the
remainder of the response.

If a partial response is generated, the response may be arbitrarily segmented into

multiple PDUs (subject to the constraint imposed by the allowed range of values for the
AttributeListByteCount parameter). Attributes in partial responses are not required to be
completely within a single PDU.

4.7 Service Search Attribute transaction

Client Server

SDP_SERVICE_SEARCH_ATTR_REQ

SDP_SERVICE_SEARCH_ATTR_RSP

Figure 4.6: Service Search Attribute transaction

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 3, Part B Page 1267
Service Discovery Protocol (SDP) Specification

4.7.1 SDP_SERVICE_SEARCH_ATTR_REQ PDU

PDU Type PDU ID Parameters

SDP_SERVICE_SEARCH_ATTR_REQ 0x06 ServiceSearchPattern,
MaximumAttributeByteCount,
AttributeIDList,
ContinuationState

Description:

The SDP_SERVICE_SEARCH_ATTR_REQ transaction combines the capabilities of

the SDP_SERVICE_SEARCH_REQ and the SDP_SERVICE_ATTR_REQ into a single
request. As parameters, it contains both a service search pattern and a list of attributes
to be retrieved from service records that match the service search pattern. The
SDP_SERVICE_SEARCH_ATTR_REQ and its response are more complex and can
require more bytes than separate Service Search and Service Attribute transactions.
However, using SDP_SERVICE_SEARCH_ATTR_REQ can reduce the total number of
SDP transactions, particularly when retrieving multiple service records.

The service record handle for each service record is contained in the
ServiceRecordHandle attribute of that service and may be requested along with other
attributes.

PDU parameters:

ServiceSearchPattern: Size: Varies

Value Parameter Description

Data Element Se- The ServiceSearchPattern is a data element sequence where each element
quence in the sequence is a UUID. The sequence shall contain at least one UUID.
The maximum number of UUIDs in the sequence is 121. The list of UUIDs
constitutes a service search pattern.
1The value of 12 has been selected as a compromise between the scope of a service search and the size
of a search request PDU. It is not expected that more than 12 UUIDs will be useful in a service search
pattern.

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 3, Part B Page 1268
Service Discovery Protocol (SDP) Specification

MaximumAttributeByteCount: Size: 2 Bytes

Value Parameter Description

N MaximumAttributeByteCount specifies the maximum number of bytes of at-
tribute data to be returned in the response to this request. The SDP Server
shall not return more than N bytes of attribute data in the response PDU.
If the requested attributes require more than N bytes, the SDP Server deter-
mines how to segment the list. In this case the client may request each
successive segment by issuing a request containing the continuation state
that was returned in the previous response PDU. In the case where multiple
response PDUs are needed to return the attribute data, MaximumAttribute-
ByteCount specifies the maximum size of the portion of the attribute data
contained in each response PDU.
Range: 0x0007 to 0xFFFF

AttributeIDList: Size: Varies

Value Parameter Description

Data Element Se- The AttributeIDList is a data element sequence where each element in the
quence list is either an attribute ID or a range of attribute IDs. Each attribute ID is
encoded as a 16-bit unsigned integer data element. Each attribute ID range
is encoded as a 32-bit unsigned integer data element, where the high order
16 bits are interpreted as the beginning attribute ID of the range and the
low order 16 bits are interpreted as the ending attribute ID of the range.
The attribute IDs contained in the AttributeIDList shall be listed in ascending
order without duplication of any attribute ID values. Note: All attributes may
be requested by specifying the range 0x0000 to 0xFFFF.

ContinuationState: Size: 1 to 17 Bytes

Value Parameter Description

Continuation State ContinuationState consists of an 8-bit count, N, of the number of bytes of
continuation state information, followed by the N bytes of continuation state
information that were returned in a previous response from the server. N
shall be less than or equal to 16. If no continuation state is to be provided in
the request, N shall set to 0.

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 3, Part B Page 1269
Service Discovery Protocol (SDP) Specification

4.7.2 SDP_SERVICE_SEARCH_ATTR_RSP PDU

PDU Type PDU ID Parameters

SDP_SERVICE_SEARCH_ATTR_RSP 0x07 AttributeListsByteCount,
AttributeLists,
ContinuationState

Description:

The SDP Server generates an SDP_SERVICE_SEARCH_ATTR_RSP upon receipt of a

valid SDP_SERVICE_SEARCH_ATTR_REQ. The response contains a list of attributes
(both attribute ID and attribute value) from the service records that match the requested
service search pattern.

PDU parameters:

AttributeListsByteCount: Size: 2 Bytes

Value Parameter Description

N The AttributeListsByteCount contains a count of the number of bytes in the
AttributeLists parameter. N shall never be larger than the MaximumAttribute-
ByteCount value specified in the SDP_SERVICE_SEARCH_ATTR_REQ.
Range: 0x0002 to 0xFFFF

AttributeLists: Size: Varies

Value Parameter Description

Data Element Se- The AttributeLists is a data element sequence where each element in turn
quence is a data element sequence representing an attribute list. Each attribute list
contains attribute IDs and attribute values from one service record. The first
element in each attribute list contains the attribute ID of the first attribute to
be returned for that service record. The second element in each attribute
list contains the corresponding attribute value. Successive pairs of elements
in each attribute list contain additional attribute ID and value pairs. Only
attributes that have non-null values within the service record and whose
attribute IDs were specified in the SDP_SERVICE_SEARCH_ATTR_REQ
are contained in the AttributeLists. Neither an attribute ID nor attribute value
is placed in AttributeLists for attributes in the service record that have no
value. Within each attribute list, the attributes are listed in ascending order of
attribute ID value.

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 3, Part B Page 1270
Service Discovery Protocol (SDP) Specification

ContinuationState: Size: 1 to 17 Bytes

Value Parameter Description

Continuation State ContinuationState consists of an 8-bit count, N, of the number of bytes
of continuation state information, followed by the N bytes of continuation
information. If the current response is complete, this parameter consists of a
single byte with the value 0. If a partial response is given, the Continuation-
State parameter may be supplied in a subsequent request to retrieve the
remainder of the response.

If a partial response is generated, the response may be arbitrarily segmented into

multiple PDUs (subject to the constraint imposed by the allowed range of values for the
AttributeListByteCount parameter). Attributes in partial responses are not required to be
completely within a single PDU.

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 3, Part B Page 1271
Service Discovery Protocol (SDP) Specification

5 SERVICE ATTRIBUTE DEFINITIONS

The service classes and attributes contained in this document are necessarily a partial
list of the service classes and attributes supported by SDP. Only service classes that
directly support the SDP Server are included in this document. Additional service
classes will be defined in other documents and possibly in future revisions of this
document. Also, it is expected that additional attributes will be discovered that are
applicable to a broad set of services; these may be added to the list of Universal
attributes in future revisions of this document.

Where a range of values is specified for a class of attribute IDs, only numbers in that
range are assigned numbers for that class and (except for universal attributes) are only
assigned numbers for that class.

5.1 Universal attribute definitions

Universal attributes are those service attributes whose definitions are common to all
service records. This does not mean that every service record contains values for all
of these service attributes. However, if a service record has a service attribute with an
attribute ID allocated to a universal attribute, the attribute value shall conform to the
universal attribute’s definition.

These attributes may be used with any service class.

Universal attributes use attribute IDs 0x0000 to 0x00FF. Specific IDs in this range are
defined in Assigned Numbers.

Only two attributes are required to exist in every service record instance. They are
the ServiceRecordHandle and the ServiceClassIDList. All other service attributes are
optional within a service record.

5.1.1 ServiceRecordHandle attribute

Attribute Name Attribute Value Type

ServiceRecordHandle 32-bit unsigned integer

Description:

A service record handle is a 32-bit number that uniquely identifies each service record
within an SDP Server. In general, each handle is unique only within each SDP Server. If
SDP Server S1 and SDP Server S2 both contain identical service records (representing
the same service), the service record handles used to reference these identical service
records are completely independent. The handle used to reference the service on

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 3, Part B Page 1272
Service Discovery Protocol (SDP) Specification

S1 will, in general, be meaningless if presented to S2. Service record handle values

0x00000001 to 0x0000FFFF are reserved for future use.

5.1.2 ServiceClassIDList attribute

Attribute Name Attribute Value Type

ServiceClassIDList Data Element Sequence

Description:

The ServiceClassIDList attribute consists of a data element sequence in which each

data element is a UUID representing the service classes that a given service record
conforms to. The UUIDs should be listed in order from the most specific class to the
most general class unless otherwise specified by the profile specifications defining the
service classes. When profiles are enhanced, any new UUIDs should be added at the
end of the ServiceClassIDList (after any existing UUIDs) to minimize interoperability
issues with legacy implementations. The ServiceClassIDList shall contain at least one
service class UUID.

5.1.3 ServiceRecordState attribute

Attribute Name Attribute Value Type

ServiceRecordState 32-bit unsigned integer

Description:

The ServiceRecordState is a 32-bit integer that is used to facilitate caching of Service

Attributes. If this attribute is contained in a service record, its value shall be changed
when any other attribute value is added to, deleted from or changed within the service
record. This permits a client to check the value of this single attribute. If its value has not
changed since it was last checked, the client knows that no other attribute values within
the service record have changed.

5.1.4 ServiceID attribute

Attribute Name Attribute Value Type

ServiceID UUID

Description:

The ServiceID is a UUID that universally and uniquely identifies the service instance
described by the service record. This service attribute is particularly useful if the same
service is described by service records in more than one SDP Server.

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 3, Part B Page 1273
Service Discovery Protocol (SDP) Specification

5.1.5 ProtocolDescriptorList attribute

Attribute Name Attribute Value Type

ProtocolDescriptorList Data Element Sequence or Data Element Alternative

Description:

The ProtocolDescriptorList attribute describes one or more protocol stacks that can be
used to gain access to the service described by the service record.

If the ProtocolDescriptorList describes a single stack, it takes the form of a data element
sequence in which each element of the sequence is a protocol descriptor. Each protocol
descriptor is, in turn, a data element sequence whose first element is a UUID identifying
the protocol and whose successive elements are protocol-specific parameters. Potential
protocol-specific parameters are a protocol version number and a connection-port
number. The protocol descriptors are listed in order from the lowest layer protocol to
the highest layer protocol used to gain access to the service.

If it is possible for more than one kind of protocol stack to be used to gain access to the
service, the ProtocolDescriptorList takes the form of a data element alternative where
each member is a data element sequence as described in the previous paragraph.

Protocol descriptors

A protocol descriptor identifies a communications protocol and provides protocol-

specific parameters. A protocol descriptor is represented as a data element sequence.
The first data element in the sequence shall be the UUID that identifies the protocol.
Additional data elements optionally provide protocol-specific information, such as the
L2CAP protocol/service multiplexer (PSM) and the RFCOMM server channel number
(CN) shown below.

ProtocolDescriptorList examples

These examples are intended to be illustrative. The parameter formats for each protocol
are not defined within the specification.

In the first two examples, it is assumed that a single RFCOMM instance exists on top
of the L2CAP layer. In this case, the L2CAP protocol specific information (PSM) points
to the single instance of RFCOMM. In the last example, two different and independent
RFCOMM instances are available on top of the L2CAP layer. In this case, the L2CAP
protocol specific information (PSM) points to a distinct identifier that distinguishes each
of the RFCOMM instances. See the L2CAP specification ([Vol 3] Part A, Section 4.2) for
the range of allowed PSM values.

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 3, Part B Page 1274
Service Discovery Protocol (SDP) Specification

IrDA-like printer

( ( L2CAP, PSM=RFCOMM ), ( RFCOMM, CN=1 ), ( PostscriptStream ) )

IP Network Printing

( ( L2CAP, PSM=RFCOMM ), ( RFCOMM, CN=2 ), ( PPP ), ( IP ), ( TCP ), ( IPP ) )

Synchronization Protocol Descriptor Example

( ( L2CAP, PSM=0x1001 ), ( RFCOMM, CN=1 ), ( Obex ), ( vCal ) )

( ( L2CAP, PSM=0x1003 ), ( RFCOMM, CN=1 ), ( Obex ),

( otherSynchronisationApplication ) )

5.1.6 AdditionalProtocolDescriptorLists attribute

Attribute Name Attribute Value Type

AdditionalProtocolDescriptorLists Data Element Sequence

Description:

The AdditionalProtocolDescriptorLists attribute contains a sequence of

ProtocolDescriptorList-elements. Each element having the same format as the
ProtocolDescriptorList described in section 5.1.5. The ordering of the elements is
significant and should be specified and fixed in Profiles that make use of this attribute.

The AdditionalProtocolDescriptorLists attribute supports services that require

more channels in addition to the service described in Section 5.1.5. If the
AdditionalProtocolDescriptorLists attribute is included in a service record, the
ProtocolDescriptorList attribute shall be included.

AdditionalProtocolDescriptorLists examples

The following is just an illustrative example and is not meant to refer a real specified
service or protocols.

Attribute Attribute Value type Attribute Value

ProtocolDescriptorList
ProtocolDescriptor #0 DataElementSequence
ProtocolID UUID L2CAP
Param: PSM PSM FooDataProtocol
ProtocolDescriptor #1 DataElementSequence
ProtocolID UUID FooDataProtocol
AdditionalProtocolDescriptorLists
ProtocolDescriptorList #0 DataElementSequence
ProtocolDescriptor #0 DataElementSequence

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 3, Part B Page 1275
Service Discovery Protocol (SDP) Specification

ProtocolID UUID L2CAP

Param: PSM PSM FooControlProtocol
ProtocolDescriptor #1 DataElementSequence
ProtocolID UUID FooControlProtocol

5.1.7 BrowseGroupList attribute

Attribute Name Attribute Value Type

BrowseGroupList Data Element Sequence

Description:

The BrowseGroupList attribute consists of a data element sequence in which each

element is a UUID that represents a browse group to which the service record belongs.
The UUID for the top-level browse group ID, called PublicBrowseRoot and representing
the root of the browsing hierarchy, is defined in Assigned Numbers.

5.1.8 LanguageBaseAttributeIDList attribute

Attribute Name Attribute Value Type

LanguageBaseAttributeIDList Data Element Sequence

Description:

In order to support human-readable attributes for multiple natural languages in a single

service record, a base attribute ID is assigned for each of the natural languages used
in a service record. The human-readable universal attributes are then defined with an
attribute ID offset from each of these base values, rather than with an absolute attribute
ID.

The LanguageBaseAttributeIDList attribute is a list in which each member contains a

language identifier, a character encoding identifier, and a base attribute ID for each of
the natural languages used in the service record. The LanguageBaseAttributeIDList
attribute consists of a data element sequence in which each element is a 16-bit
unsigned integer. The elements are grouped as triplets (threes).

The first element of each triplet contains an identifier representing the natural language.
The language is encoded according to ISO 639:1988 (E/F): “Code for the representation
of names of languages”.

The second element of each triplet contains an identifier that specifies a character
encoding used for the language. Values for character encoding can be found in

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 3, Part B Page 1276
Service Discovery Protocol (SDP) Specification

IANA's database1, and have the values that are referred to as MIBEnum values. The
recommended character encoding is UTF-8.

The third element of each triplet contains an attribute ID that serves as the base
attribute ID for the natural language in the service record. Different service records
within a server may use different base attribute ID values for the same language.

The base attribute ID value shall be chosen so that all attributes that are specified as
being offset from it (e.g. ServiceName, ServiceDescription, and ProviderName) shall
have resulting Attribute IDs that are in the range 0x0100 to 0x01FF or a range specified
in another specification as being used for this purpose. The range 0x0100 to 0x01FF
shall only be used for this purpose.

To facilitate the retrieval of human-readable universal attributes in a principal language,

the base attribute ID value for the primary language supported by a service record
shall be 0x0100. Also, if a LanguageBaseAttributeIDList attribute is contained in a
service record, the base attribute ID value contained in its first element shall be
0x0100. If one or more human readable attributes are contained in a service record,
the LanguageBaseAttributeIDList attribute should be included in that service record.

5.1.9 ServiceInfoTimeToLive attribute

Attribute Name Attribute Value Type

ServiceInfoTimeToLive 32-bit unsigned integer

Description:

The ServiceTimeToLive attribute is a 32-bit integer that contains the number of seconds
for which the information in a service record is expected to remain valid and unchanged.
This time interval is measured from the time that the attribute value is retrieved from the
SDP Server. This value does not imply a guarantee that the service record will remain
available or unchanged. It is simply a hint that a client can use to determine a suitable
polling interval to re-validate the service record contents.

5.1.10 ServiceAvailability attribute

Attribute Name Attribute Value Type

ServiceAvailability 8-bit unsigned integer

Description:

The ServiceAvailability attribute is an 8-bit unsigned integer that represents the relative
ability of the service to accept additional clients. A value of 0xFF indicates that the

1See https://www.iana.org/assignments/character-sets/character-sets.xhtml

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 3, Part B Page 1277
Service Discovery Protocol (SDP) Specification

service is not currently in use and is thus fully available, while a value of 0x00
means that the service is not accepting new clients. For services that support multiple
simultaneous clients, intermediate values indicate the relative availability of the service
on a linear scale.

For example, a service that can accept up to 3 clients should provide ServiceAvailability
values of 0xFF, 0xAA, 0x55, and 0x00 when 0, 1, 2, and 3 clients, respectively, are
2 2
utilizing the service. The value 0xAA is approximately 3
× 0xFF and represents 3
1 1
availability, while the value 0x55 is approximately 3 × 0xFF and represents 3
availability.
The availability value is be approximated as

( 1 - ( current_number_of_clients ÷ maximum_number_of_clients ) ) × 0xFF

When the maximum number of clients is large, this formula must be modified to ensure
that ServiceAvailability values of 0x00 and 0xFF are reserved for their defined meanings
of unavailability and full availability, respectively.

Note: The maximum number of clients a service can support may vary according to the
resources utilized by the service's current clients.

A non-zero value for ServiceAvailability does not guarantee that the service will be
available for use. It should be treated as a hint or an approximation of availability status.

5.1.11 BluetoothProfileDescriptorList attribute

Attribute Name Attribute Value Type

BluetoothProfileDescriptorList Data Element Sequence

Description:

The BluetoothProfileDescriptorList attribute consists of a data element sequence in

which each element is a profile descriptor that contains information about a Bluetooth
profile to which the service represented by this service record conforms. Each profile
descriptor is a data element sequence whose first element is the UUID assigned to the
profile and whose second element is a 16-bit profile version number.

Each version of a profile is assigned a 16-bit unsigned integer profile version number,
which consists of two 8-bit fields. The higher-order 8 bits contain the major version
number field and the lower-order 8 bits contain the minor version number field.

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 3, Part B Page 1278
Service Discovery Protocol (SDP) Specification

5.1.12 DocumentationURL attribute

Attribute Name Attribute Value Type

DocumentationURL URL

Description:

This attribute is a URL which points to documentation on the service described by a

service record.

5.1.13 ClientExecutableURL attribute

Attribute Name Attribute Value Type

ClientExecutableURL URL

Description:

This attribute contains a URL that refers to the location of an application that can be
used to utilize the service described by the service record. Since different operating
environments require different executable formats, a mechanism has been defined to
allow this single attribute to be used to locate an executable that is appropriate for the
client device’s operating environment. In the attribute value URL, the first byte with the
value 0x2A (ASCII character ‘*’) is to be replaced by the client application with a string
representing the desired operating environment before the URL is to be used.

The list of standardized strings representing operating environments is contained in

Assigned Numbers.

For example, assume that the value of the ClientExecutableURL attribute is http://
my.fake/public/*/client.exe. On a device capable of executing SH3 WindowsCE files,
this URL would be changed to http://my.fake/public/sh3-microsoft-wince/client.exe. On
a device capable of executing Windows 98 binaries, this URL would be changed to
http://my.fake/public/i86-microsoft-win98/client.exe.

5.1.14 IconURL attribute

Attribute Name Attribute Value Type

IconURL URL

Description:

This attribute contains a URL that refers to the location of an icon that can be used
to represent the service described by the service record. Since different hardware
devices require different icon formats, a mechanism has been defined to allow this

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 3, Part B Page 1279
Service Discovery Protocol (SDP) Specification

single attribute to be used to locate an icon that is appropriate for the client device.
In the attribute value URL, the first byte with the value 0x2A (ASCII character ‘*’) is to
be replaced by the client application with a string representing the desired icon format
before the URL is to be used.

The list of standardized strings representing icon formats is contained in Assigned

Numbers.

For example, assume that the value of the IconURL attribute is http://my.fake/public/
icons/*. On a device that prefers 24 x 24 icons with 256 colors, this URL would
be changed to http://my.fake/public/icons/24x24x8.png. On a device that prefers 10
x 10 monochrome icons, this URL would be changed to http://my.fake/public/icons/
10x10x1.png.

5.1.15 ServiceName attribute

Attribute Name Attribute Value Type

ServiceName String

Description:

The ServiceName attribute is a string containing the name of the service represented by
a service record. It should be brief and suitable for display with an Icon representing
the service. An offset specified in Assigned Numbers is added to the attribute ID
base (contained in the LanguageBaseAttributeIDList attribute) in order to compute the
attribute ID for this attribute.

5.1.16 ServiceDescription attribute

Attribute Name Attribute Value Type

ServiceDescription String

Description:

This attribute is a string containing a brief description of the service. It should be less
than 200 characters in length. An offset specified in Assigned Numbers is added to the
attribute ID base (contained in the LanguageBaseAttributeIDList attribute) in order to
compute the attribute ID for this attribute.

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 3, Part B Page 1280
Service Discovery Protocol (SDP) Specification

5.1.17 ProviderName attribute

Attribute Name Attribute Value Type

ProviderName String

Description:

This attribute is a string containing the name of the person or organization providing
the service. An offset specified in Assigned Numbers is added to the attribute ID
base (contained in the LanguageBaseAttributeIDList attribute) in order to compute the
attribute ID for this attribute.

5.1.18 [This section is no longer used]

5.2 ServiceDiscoveryServer service class attribute definitions

This service class describes service record that contains attributes of the service
discovery server itself. The attributes listed in this section are only valid if the
ServiceClassIDList attribute contains the ServiceDiscoveryServerServiceClassID.

This service class uses attribute IDs 0x0200 to 0x02FF. Specific IDs in this range are
defined in Assigned Numbers.

5.2.1 ServiceRecordHandle attribute

Described in the universal attribute definition for ServiceRecordHandle (Section 5.1.1).

Value

A 32-bit integer with the value 0x00000000.

5.2.2 ServiceClassIDList attribute

Described in the universal attribute definition for ServiceClassIDList (Section 5.1.2).

Value

A UUID representing the ServiceDiscoveryServerServiceClassID.

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 3, Part B Page 1281
Service Discovery Protocol (SDP) Specification

5.2.3 VersionNumberList attribute

Attribute Name Attribute Value Type

VersionNumberList Data Element Sequence

Description:

The VersionNumberList is a data element sequence in which each element of the

sequence is a version number supported by the SDP Server.

A version number is a 16-bit unsigned integer consisting of two fields. The higher-order
8 bits contain the major version number field and the low-order 8 bits contain the minor
version number field. The initial version of SDP has a major version of 1 and a minor
version of 0.

5.2.4 ServiceDatabaseState attribute

Attribute Name Attribute Value Type

ServiceDatabaseState 32-bit unsigned integer

Description:

The ServiceDatabaseState is a 32-bit integer that is used to facilitate caching of service

records. If this attribute exists, its value shall be changed when any of the other service
records are added to or deleted from the server's SDP database. If this value has not
changed since the last time a client queried its value, the client knows that a) none of
the other service records maintained by the SDP Server have been added or deleted;
and b) any service record handles acquired from the server are still valid. A client shall
query this attribute's value when a connection to the server is established, prior to using
any service record handles acquired during a previous connection.

The ServiceDatabaseState attribute does not change when existing service records are
modified, including the addition, removal, or modification of service attributes. A service
record's ServiceRecordState attribute indicates when that service record is modified.

5.2.5 [This section is no longer used]

5.3 BrowseGroupDescriptor service class attribute definitions

This service class describes the ServiceRecord provided for each

BrowseGroupDescriptor service offered on a Bluetooth device. The attributes listed
in this section are only valid if the ServiceClassIDList attribute contains the
BrowseGroupDescriptorServiceClassID.

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 3, Part B Page 1282
Service Discovery Protocol (SDP) Specification

This service class uses attribute IDs 0x0200 to 0x02FF. Specific IDs in this range are
defined in Assigned Numbers.

5.3.1 ServiceClassIDList attribute

Described in the universal attribute definition for ServiceClassIDList (Section 5.1.2).

Value

A UUID representing the BrowseGroupDescriptorServiceClassID.

5.3.2 GroupID attribute

Attribute Name Attribute Value Type

GroupID UUID

Description:

This attribute contains a UUID that can be used to locate services that are members of
the browse group that this service record describes.

5.3.3 [This section is no longer used]

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 3, Part B Page 1283
Service Discovery Protocol (SDP) Specification

6 SECURITY

In Security Mode 4, SDP should use no security but may use security (an authenticated
or unauthenticated link key with encryption). See [Vol 3] Part C, Section 5.2.2).

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 3, Part B Page 1284
Service Discovery Protocol (SDP) Specification

Appendix A [This appendix is no longer used]

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 3, Part B Page 1285
Service Discovery Protocol (SDP) Specification

Appendix B Example SDP Transactions

The following are simple examples of typical SDP transactions. These are meant to be
illustrative of SDP flows. The examples do not consider:

• Caching (in a caching system, the SDP Client would make use of the
ServiceRecordState and ServiceDatabaseState attributes);
• Service availability (if this is of interest, the SDP Client should use the
ServiceAvailability and/or ServiceTimeToLive attributes);
• SDP versions (the VersionNumberList attribute could be used to determine
compatible SDP versions);
• SDP Error Responses (an SDP error response is possible for any SDP request that is
in error); and
• Communication connection (the examples assume that an L2CAP connection is
established).

The examples are meant to be illustrative of the protocol. The format used is
ObjectName[ObjectSizeInBytes] {SubObjectDefinitions} , but this is not meant
to illustrate an interface. The ObjectSizeInBytes is the size of the object in
decimal. The SubObjectDefinitions (inside of {} characters) are components of the
immediately enclosing object. Hexadecimal values shown as lower-case letters, such
as for transaction IDs and service handles, are variables (the particular value is not
important for the illustration, but each such symbol always represents the same value).
Comments are included in this manner: /* comment text */

B.1 SDP example 1 – ServiceSearchRequest

The first example is that of an SDP Client searching for a generic printing service. The
client does not specify a particular type of printing service. In the example, the SDP
Server has two available printing services. The transaction illustrates:

1. SDP Client to SDP Server: SDP_SERVICE_SEARCH_REQ, specifying the

PrinterServiceClassID (represented as a DataElement with a 32-bit UUID
value of ppp...ppp ) as the only element of the ServiceSearchPattern. The
PrinterServiceClassID is assumed to be a 32-bit UUID and the data element type
for it is illustrated. The TransactionID is illustrated as tttt .
2. SDP Server to SDP Client: SDP_SERVICE_SEARCH_RSP, returning handles to
two printing services, represented as qqqqqqqq for the first printing service and
rrrrrrrr for the second printing service. The Transaction ID is the same value as
supplied by the SDP Client in the corresponding request ( tttt ).

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 3, Part B Page 1286
Service Discovery Protocol (SDP) Specification

/* Sent from SDP Client to SDP Server */

SDP_SERVICE_SEARCH_REQ[15] {
PDUID[1] {
0x02
}
TransactionID[2] {
0xtttt
}
ParameterLength[2] {
0x000A
}
ServiceSearchPattern[7] {
DataElementSequence[7] {
0b00110 0b101 0x05
UUID[5] {
/* PrinterServiceClassID */
0b00011 0b010 0xpppppppp
}
}
}
MaximumServiceRecordCount[2] {
0x0003
}
ContinuationState[1] {
/* no continuation state */
0x00
}
}

/* Sent from SDP Server to SDP Client */

SDP_SERVICE_SEARCH_RSP[18] {
PDUID[1] {
0x03
}
TransactionID[2] {
0xtttt
}
ParameterLength[2] {
0x000D
}

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 3, Part B Page 1287
Service Discovery Protocol (SDP) Specification

TotalServiceRecordCount[2] {
0x0002
}
CurrentServiceRecordCount[2] {
0x0002
}
ServiceRecordHandleList[8] {
/* print service 1 handle */
0xqqqqqqqq
/* print service 2 handle */
0xrrrrrrrr
}
ContinuationState[1] {
/* no continuation state */
0x00
}
}

B.2 SDP example 2 – ServiceAttributeTransaction

The second example continues the first example. In Example 1, the SDP Client
obtained handles to two printing services. In Example 2, the client uses one of those
service handles to obtain the ProtocolDescriptorList attribute for that printing service.
The transaction illustrates:

1. SDP Client to SDP Server: SDP_SERVICE_ATTR_REQ, presenting the previously

obtained service handle (the one denoted as qqqqqqqq ) and specifying the
ProtocolDescriptorList attribute ID (AttributeID 0x0004) as the only attribute
requested (other attributes could be retrieved in the same transaction if desired).
The TransactionID is illustrated as uuuu to distinguish it from the TransactionID of
Example 1.
2. SDP Server to SDP Client: SDP_SERVICE_ATTR_RSP, returning the
ProtocolDescriptorList for the specified printing service. This protocol stack
is assumed to be ( (L2CAP), (RFCOMM, 2), (PostscriptStream) ). The
ProtocolDescriptorList is a data element sequence in which each element is, in
turn, a data element sequence whose first element is a UUID representing the
protocol, and whose subsequent elements are protocol-specific parameters. In this
example, one such parameter is included for the RFCOMM protocol, an 8-bit value
indicating RFCOMM server channel 2. The Transaction ID is the same value as
supplied by the SDP Client in the corresponding request ( uuuu ). The Attributes
returned are illustrated as a data element sequence where the protocol descriptors

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 3, Part B Page 1288
Service Discovery Protocol (SDP) Specification

are 32-bit UUIDs and the RFCOMM server channel is a data element with an 8-bit
value of 2.

/* Sent from SDP Client to SDP Server */

SDP_SERVICE_ATTR_REQ[17] {
PDUID[1] {
0x04
}
TransactionID[2] {
0xuuuu
}
ParameterLength[2] {
0x000C
}
ServiceRecordHandle[4] {
0xqqqqqqqq
}
MaximumAttributeByteCount[2] {
0x0080
}
AttributeIDList[5] {
DataElementSequence[5] {
0b00110 0b101 0x03
AttributeID[3] {
0b00001 0b001 0x0004
}
}
}
ContinuationState[1] {
/* no continuation state */
0x00
}
}

/* Sent from SDP Server to SDP Client */

SDP_SERVICE_ATTR_RSP[38] {
PDUID[1] {
0x05
}
TransactionID[2] {

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 3, Part B Page 1289
Service Discovery Protocol (SDP) Specification

0xuuuu
}
ParameterLength[2] {
0x0021
}
AttributeListByteCount[2] {
0x001E
}
AttributeList[30] {
DataElementSequence[30] {
0b00110 0b101 0x1C
Attribute[28] {
AttributeID[3] {
0b00001 0b001 0x0004
}
AttributeValue[25] {
/* ProtocolDescriptorList */
DataElementSequence[25] {
0b00110 0b101 0x17
/* L2CAP protocol descriptor */
DataElementSequence[7] {
0b00110 0b101 0x05
UUID[5] {
/* L2CAP Protocol UUID */
0b00011 0b010 <32-bit L2CAP UUID>
}
}
/* RFCOMM protocol descriptor */
DataElementSequence[9] {
0b00110 0b101 0x07
UUID[5] {
/* RFCOMM Protocol UUID */
0b00011 0b010 <32-bit RFCOMM UUID>
}
/* parameter for server 2 */
uint8[2] {
0b00001 0b000 0x02
}
}
/* PostscriptStream protocol descriptor */
DataElementSequence[7] {

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 3, Part B Page 1290
Service Discovery Protocol (SDP) Specification

0b00110 0b101 0x05

UUID[5] {
/* PostscriptStream Protocol UUID */
0b00011 0b010 <32-bit PostscriptStream UUID>
}
}
}
}
}
}
}
ContinuationState[1] {
/* no continuation state */
0x00
}
}
SDP_SERVICE_ATTR_REQ[17] {
PDUID[1] {
0x04
}
TransactionID[2] {
0xuuuu
}
ParameterLength[2] {
0x000C
}
ServiceRecordHandle[4] {
0xqqqqqqqq
}
MaximumAttributeByteCount[2] {
0x0080
}
AttributeIDList[5] {
DataElementSequence[5] {
0b00110 0b101 0x03
AttributeID[3] {
0b00001 0b001 0x0004
}
}
}
ContinuationState[1] {

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 3, Part B Page 1291
Service Discovery Protocol (SDP) Specification

/* no continuation state */
0x00
}
}

/* Sent from SDP Server to SDP Client */

SDP_SERVICE_ATTR_RSP[38] {
PDUID[1] {
0x05
}
TransactionID[2] {
0xuuuu
}
ParameterLength[2] {
0x0021
}
AttributeListByteCount[2] {
0x001E
}
AttributeList[30] {
DataElementSequence[30] {
0b00110 0b101 0x1C
Attribute[28] {
AttributeID[3] {
0b00001 0b001 0x0004
}
AttributeValue[25] {
/* ProtocolDescriptorList */
DataElementSequence[25] {
0b00110 0b101 0x17
/* L2CAP protocol descriptor */
DataElementSequence[7] {
0b00110 0b101 0x05
UUID[5] {
/* L2CAP Protocol UUID */
0b00011 0b010 <32-bit L2CAP UUID>
}
}
/* RFCOMM protocol descriptor */
DataElementSequence[9] {
0b00110 0b101 0x07

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 3, Part B Page 1292
Service Discovery Protocol (SDP) Specification

UUID[5] {
/* RFCOMM Protocol UUID */
0b00011 0b010 <32-bit RFCOMM UUID>
}
/* parameter for server 2 */
uint8[2] {
0b00001 0b000 0x02
}
}
/* PostscriptStream protocol descriptor */
DataElementSequence[7] {
0b00110 0b101 0x05
UUID[5] {
/* PostscriptStream Protocol UUID */
0b00011 0b010 <32-bit PostscriptStream UUID>
}
}
}
}
}
}
}
ContinuationState[1] {
/* no continuation state */
0x00
}
}

B.3 SDP example 3 – ServiceSearchAttributeTransaction

The third example is a form of service browsing, although it is not generic browsing
in that it does not make use of SDP browse groups. Instead, an SDP Client is
searching for available Synchronization services that can be presented to the user
for selection. The SDP Client does not specify a particular type of synchronization
service. In the example, the SDP Server has three available synchronization services:
an address book synchronization service and a calendar synchronization service (both
from the same provider), and a second calendar synchronization service from a different
provider. The SDP Client is retrieving the same attributes for each of these services;
namely, the data formats supported for the synchronization service (vCard, vCal, ICal,
etc.) and those attributes that are relevant for presenting information to the user about
the services. Also assume that the maximum size of a response is 400 bytes. Since the

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 3, Part B Page 1293
Service Discovery Protocol (SDP) Specification

result is larger than this, the SDP Client will repeat the request supplying a continuation
state parameter to retrieve the remainder of the response. The transaction illustrates:

1. SDP Client to SDP Server: SDP_SERVICE_SEARCH_ATTR_REQ, specifying

the generic SynchronisationServiceClassID (represented as a data element
whose 32-bit UUID value is sss...sss ) as the only element of the
ServiceSearchPattern. The SynchronisationServiceClassID is assumed to be a
32-bit UUID. The requested attributes are the ServiceRecordHandle (Attribute ID
0x0000), ServiceClassIDList (AttributeID 0x0001), IconURL (AttributeID 0x000C),
ServiceName (AttributeID 0x0100), ServiceDescription (AttributeID 0x0101), and
ProviderName (AttributeID 0x0102) attributes; as well as the service-specific
SupportedDataStores (AttributeID 0x0301). Since the first two attribute IDs (0x0000
and 0x0001) and three other attribute IDs(0x0100, 0x0101, and 0x0102 are
consecutive, they are specified as attribute ranges. The TransactionID is illustrated
as vvvv to distinguish it from the TransactionIDs of the other Examples.
Values in the service record’s primary language are requested for the text attributes
(ServiceName, ServiceDescription and ProviderName) so that absolute attribute
IDs may be used, rather than adding offsets to a base obtained from the
LanguageBaseAttributeIDList attribute.
2. SDP Server to SDP Client: SDP_SERVICE_SEARCH_ATTR_RSP, returning the
specified attributes for each of the three synchronization services. In the example,
each ServiceClassIDList is assumed to contain a single element, the generic
SynchronisationServiceClassID (a 32-bit UUID represented as sss...sss). Each
of the other attributes contain illustrative data in the example (the strings have
illustrative text; the icon URLs are illustrative, for each of the respective three
synchronization services; and the SupportedDataStore attribute is represented as
an unsigned 8-bit integer where 0x01 = vCard2.1, 0x02 = vCard3.0, 0x03 = vCal1.0
and 0x04 = iCal). One of the service records (the third for which data is returned)
has no ServiceDescription attribute. The attributes are returned as a data element
sequence, where each element is in turn a data element sequence representing a
list of attributes. Within each attribute list, the ServiceClassIDList is a data element
sequence while the remaining attributes are single data elements. The Transaction
ID is the same value as supplied by the SDP Client in the corresponding request
(0xvvvv). Since the entire result cannot be returned in a single response, a non-null
continuation state is returned in this first response.
3. The total length of the initial data element sequence (487 in the example) is
indicated in the first response, even though only a portion of this data element
sequence (368 bytes in the example, as indicated in the AttributeLists byte count)
is returned in the first response. The remainder of this data element sequence is
returned in the second response (without an additional data element header).
4. SDP Client to SDP Server: SDP_SERVICE_SEARCH_ATTR_REQ, with the same
parameters as in step 1, except that the continuation state received from the server

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 3, Part B Page 1294
Service Discovery Protocol (SDP) Specification

in step 2 is included as a request parameter. The TransactionID is changed to

0xwww to distinguish it from previous request.
5. SDP Server to SDP Client: SDP_SERVICE_SEARCH_ATTR_RSP, with the
remainder of the result computed in step 2 above. Since all of the remaining result
fits in this second response, a null continuation state is included.

/* Part 1 -- Sent from SDP Client to SDP Server */

SDP_SERVICE_SEARCH_ATTR_REQ[33] {
PDUID[1] {
0x06
}
TransactionID[2] {
0xvvvv
}
ParameterLength[2] {
0x001C
}
ServiceSearchPattern[7] {
DataElementSequence[7] {
0b00110 0b101 0x05
UUID[5] {
/* SynchronisationServiceClassID */
0b00011 0b010 0xssssssss
}
}
}
MaximumAttributeByteCount[2] {
0x0190
}
AttributeIDList[18] {
DataElementSequence[18] {
0b00110 0b101 0x10
AttributeIDRange[5] {
0b00001 0b010 0x00000001
}
AttributeID[3] {
0b00001 0b001 0x000C
}
AttributeIDRange[5] {
0b00001 0b010 0x01000102
}

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 3, Part B Page 1295
Service Discovery Protocol (SDP) Specification

AttributeID[3] {
0b00001 0b001 0x0301
} }
}
ContinuationState[1] {
/* no continuation state */
0x00
}
}

/* Part 2 -- Sent from SDP Server to SDP Client */

SDP_SERVICE_SEARCH_ATTR_RSP[384] {
PDUID[1] {
0x07
}
TransactionID[2] {
0xvvvv
}
ParameterLength[2] {
0x017B
}
AttributeListByteCount[2] {
0x0170
}
AttributeLists[368] {
DataElementSequence[487] {
0b00110 0b110 0x01E4
DataElementSequence[178] {
0b00110 0b101 0xB0
Attribute[8] {
AttributeID[3] {
0b00001 0b001 0x0000
}
AttributeValue[5] {
/* service record handle */
0b00001 0b010 0xhhhhhhhh
}
}
Attribute[10] {
AttributeID[3] {
0b00001 0b001 0x0001

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 3, Part B Page 1296
Service Discovery Protocol (SDP) Specification

}
AttributeValue[7] {
DataElementSequence[7] {
0b00110 0b101 0x05
UUID[5] {
/* SynchronisationServiceClassID */
0b00011 0b010 0xssssssss
}
}
}
}
Attribute[35] {
AttributeID[3] {
0b00001 0b001 0x000C
}
AttributeValue[32] {
/* IconURL; '*' replaced by client application */
0b01000 0b101 0x1E
"http://Synchronisation/icons/*"
}
}
Attribute[22] {
AttributeID[3] {
0b00001 0b001 0x0100
}
AttributeValue[19] {
/* service name */
0b00100 0b101 0x11
"Address Book Sync"
}
}
Attribute[59] {
AttributeID[3] {
0b00001 0b001 0x0101
}
AttributeValue[56] {
/* service description */
0b00100 0b101 0x36
"Synchronisation Service for vCard Address Book Entries"
}
}

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 3, Part B Page 1297
Service Discovery Protocol (SDP) Specification

Attribute[37] {
AttributeID[3] {
0b00001 0b001 0x0102
}
AttributeValue[34] {
/* service provider */
0b00100 0b101 0x20
"Synchronisation Specialists Inc."
}
}
Attribute[5] {
AttributeID[3] {
0b00001 0b001 0x0301
}
AttributeValue[2] {
/* Supported Data Store ’phonebook’ */
0b00001 0b000 0x01
}
}
}
DataElementSequence[175] {
0b00110 0b101 0xAD
Attribute[8] {
AttributeID[3] {
0b00001 0b001 0x0000
}
AttributeValue[5] {
/* service record handle */
0b00001 0b010 0xmmmmmmmm
}
}
Attribute[10] {
AttributeID[3] {
0b00001 0b001 0x0001
}
AttributeValue[7] {
DataElementSequence[7] {
0b00110 0b101 0x05
UUID[5] {
/* SynchronisationServiceClassID */
0b00011 0b010 0xssssssss

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 3, Part B Page 1298
Service Discovery Protocol (SDP) Specification

}
}
}
}
Attribute[35] {
AttributeID[3] {
0b00001 0b001 0x000C
}
AttributeValue[32] {
/* IconURL; '*' replaced by client application */
0b01000 0b101 0x1E
"http://Synchronisation/icons/*"
}
}
Attribute[21] {
AttributeID[3] {
0b00001 0b001 0x0100
}
AttributeValue[18] {
/* service name */
0b00100 0b101 0x10
"Appointment Sync"
}
}
Attribute[57] {
AttributeID[3] {
0b00001 0b001 0x0101
}
AttributeValue[54] {
/* service description */
0b00100 0b101 0x34
"Synchronisation Service for vCal Appointment Entries"
}
}
Attribute[37] {
AttributeID[3] {
0b00001 0b001 0x0102
}
AttributeValue[34] {
/* service provider */
0b00100 0b101 0x20

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 3, Part B Page 1299
Service Discovery Protocol (SDP) Specification

"Synchronisation Specialists Inc."

}
}
Attribute[5] {
AttributeID[3] {
0b00001 0b001 0x0301
}
AttributeValue[2] {
/* Supported Data Store ’calendar’ */
0b00001 0b000 0x03
}
}
}
/* } Data element sequence of attribute lists */
/* is not completed in this PDU. */
}
ContinuationState[9] {
/* 8 bytes of continuation state */
0x08 0xzzzzzzzzzzzzzzzz
}
}

/* Part 3 -- Sent from SDP Client to SDP Server */

SDP_SERVICE_SEARCH_ATTR_REQ[41] {
PDUID[1] {
0x06
}
TransactionID[2] {
0xwwww
}
ParameterLength[2] {
0x0024
}
ServiceSearchPattern[7] {
DataElementSequence[7] {
0b00110 0b101 0x05
UUID[5] {
/* SynchronisationServiceClassID */
0b00011 0b010 0xssssssss
}
}

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 3, Part B Page 1300
Service Discovery Protocol (SDP) Specification

}
MaximumAttributeByteCount[2] {
0x0180
}
AttributeIDList[18] {
DataElementSequence[18] {
0b00110 0b101 0x10
AttributeIDRange[5] {
0b00001 0b010 0x00000001
}
AttributeID[3] {
0b00001 0b001 0x000C
}
AttributeIDRange[5] {
0b00001 0b010 0x01000102
}
AttributeID[3] {
0b00001 0b001 0x0301
}
}
}
ContinuationState[9] {
/* same 8 bytes of continuation state */
/* received in part 2 */
0x08 0xzzzzzzzzzzzzzzzz
}
}

Part 4 -- Sent from SDP Server to SDP Client

SDP_SERVICE_SEARCH_ATTR_RSP[115] {
PDUID[1] {
0x07
}
TransactionID[2] {
0xwwww
}
ParameterLength[2] {
0x006E
}
AttributeListByteCount[2] {

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 3, Part B Page 1301
Service Discovery Protocol (SDP) Specification

0x006B
}
AttributeLists[107] {
/* Continuing the data element sequence of */
/* attribute lists begun in Part 2. */
DataElementSequence[107] {
0b00110 0b101 0x69
Attribute[8] {
AttributeID[3] {
0b00001 0b001 0x0000
}
AttributeValue[5] {
/* service record handle */
0b00001 0b010 0xFFFFFFFF
}
}
Attribute[10] {
AttributeID[3] {
0b00001 0b001 0x0001
}
AttributeValue[7] {
DataElementSequence[7] {
0b00110 0b101 0x05
UUID[5] {
/* SynchronisationServiceClassID */
0b00011 0b010 0xssssssss
}
}
}
}
Attribute[35] {
AttributeID[3] {
0b00001 0b001 0x000C
}
AttributeValue[32] {
/* IconURL; '*' replaced by client application */
0b01000 0b101 0x1E
"http://DevManufacturer/icons/*"
}
}
Attribute[18] {

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 3, Part B Page 1302
Service Discovery Protocol (SDP) Specification

AttributeID[3] {
0b00001 0b001 0x0100
}
AttributeValue[15] {
/* service name */
0b00100 0b101 0x0D
"Calendar Sync"
}
}
Attribute[29] {
AttributeID[3] {
0b00001 0b001 0x0102
}
AttributeValue[26] {
/* service provider */
0b00100 0b101 0x18
"Device Manufacturer Inc."
}
}
Attribute[5] {
AttributeID[3] {
0b00001 0b001 0x0301
}
AttributeValue[2] {
/* Supported Data Store ’calendar’ */
0b00001 0b000 0x03
}
}
}
/* This completes the data element sequence */
/* of attribute lists begun in Part 2. */
}
ContinuationState[1] {
/* no continuation state */
0x00
}
}

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 3, Part B Page 1303
Service Discovery Protocol (SDP) Specification

Appendix C Changes to PDU names

Previous versions of this specification used different names for the PDUs defined in
Section 4. Table C.1 shows the previous and current names of these PDUs.

Previous name Current name

SDP_ErrorResponse SDP_ERROR_RSP
SDP_ServiceAttributeRequest SDP_SERVICE_ATTR_REQ
SDP_ServiceAttributeResponse SDP_SERVICE_ATTR_RSP
SDP_ServiceSearchAttributeRequest SDP_SERVICE_SEARCH_ATTR_REQ
SDP_ServiceSearchAttributeResponse SDP_SERVICE_SEARCH_ATTR_RSP
SDP_ServiceSearchRequest SDP_SERVICE_SEARCH_REQ
SDP_ServiceSearchResponse SDP_SERVICE_SEARCH_RSP

Table C.1: Changes to PDU names

Bluetooth SIG Proprietary Version Date: 2024-08-27

 Host
Part C

GENERIC ACCESS
PROFILE

This profile defines the generic procedures related

to discovery of Bluetooth devices (idle mode
procedures) and link management aspects of
connecting to Bluetooth devices (connecting mode
procedures). It also defines procedures related to
use of different security levels. In addition, this
profile includes common format requirements for
parameters accessible on the user interface level.

Bluetooth SIG Proprietary

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 3, Part C Page 1305
Generic Access Profile

CONTENTS

1 Foreword .................................................................................................. 1315

1.1 Scope ........................................................................................ 1315
1.2 Symbols and conventions ......................................................... 1316
1.2.1 [This section is no longer used] ................................. 1316
1.2.2 Signaling diagram conventions .................................. 1316
1.2.3 Notation for timers and counters ............................... 1317
1.2.4 Notation for UUIDs ..................................................... 1317
1.3 GAP requirements ..................................................................... 1317

2 Profile overview ...................................................................................... 1318

2.1 Profile stack ............................................................................... 1318
2.2 Profile roles ............................................................................... 1318
2.2.1 Roles when operating over BR/EDR Physical
Transport ................................................................... 1318
2.2.2 Roles when operating over an LE physical transport 1319
2.2.2.1 Broadcaster role ......................................... 1321
2.2.2.2 Observer role ............................................. 1321
2.2.2.3 Peripheral role ............................................ 1322
2.2.2.4 Central role ................................................. 1322
2.2.2.5 Concurrent operation in multiple GAP
roles ........................................................... 1322
2.3 User requirements and scenarios ............................................. 1322
2.4 Profile fundamentals ................................................................. 1322
2.5 [This section is no longer used] ................................................. 1323

3 User interface aspects ........................................................................... 1324

3.1 The user interface level ............................................................. 1324
3.2 Representation of Bluetooth parameters .................................. 1324
3.2.1 Bluetooth Device Address (BD_ADDR) ..................... 1324
3.2.1.1 Definition .................................................... 1324
3.2.1.2 Term on user interface level ....................... 1324
3.2.1.3 Representation ........................................... 1324
3.2.2 Bluetooth Device Name (the user-friendly name) ...... 1324
3.2.2.1 Definition .................................................... 1324
3.2.2.2 Term on user interface level ....................... 1325
3.2.2.3 Representation ........................................... 1325
3.2.3 Bluetooth Passkey (Bluetooth PIN) ........................... 1325
3.2.3.1 Definition .................................................... 1325
3.2.3.2 Terms at user interface level ...................... 1325
3.2.3.3 Representation ........................................... 1325

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 3, Part C Page 1306
Generic Access Profile

3.2.4 Class of Device .......................................................... 1327

3.2.4.1 Definition .................................................... 1327
3.2.4.2 Term on user interface level ....................... 1327
3.2.4.3 Representation ........................................... 1327
3.2.4.4 Usage ......................................................... 1327
3.2.5 Appearance characteristic ......................................... 1328
3.2.5.1 Definition .................................................... 1328
3.2.5.2 Usage at user interface level ..................... 1328
3.2.5.3 Representation ........................................... 1328
3.2.6 Broadcast Code ......................................................... 1328
3.2.6.1 Definition .................................................... 1328
3.2.6.2 Terms at user interface level ...................... 1328
3.2.6.3 Representation ........................................... 1328
3.3 Pairing ....................................................................................... 1329

4 Modes – BR/EDR physical transport ..................................................... 1330

4.1 Discoverability modes ............................................................... 1330
4.1.1 Non-discoverable mode ............................................. 1331
4.1.1.1 Definition .................................................... 1331
4.1.1.2 Term on UI-level ......................................... 1331
4.1.2 Limited Discoverable mode ....................................... 1331
4.1.2.1 Definition .................................................... 1331
4.1.2.2 Conditions .................................................. 1332
4.1.2.3 Term on UI-level ......................................... 1332
4.1.3 General Discoverable mode ...................................... 1332
4.1.3.1 Definition .................................................... 1332
4.1.3.2 Conditions .................................................. 1332
4.1.3.3 Term on UI-level ......................................... 1333
4.2 Connectability modes ................................................................ 1333
4.2.1 Non-connectable mode ............................................. 1333
4.2.1.1 Definition .................................................... 1333
4.2.1.2 Term on UI-level ......................................... 1333
4.2.2 Connectable mode .................................................... 1334
4.2.2.1 Definition .................................................... 1334
4.2.2.2 Term on UI-level ......................................... 1335
4.3 Bondable modes ....................................................................... 1335
4.3.1 Non-bondable mode .................................................. 1335
4.3.1.1 Definition .................................................... 1335
4.3.1.2 Term on UI-level ......................................... 1335
4.3.2 Bondable mode ......................................................... 1335
4.3.2.1 Definition .................................................... 1335
4.3.2.2 Term on UI-level ......................................... 1336
4.4 Synchronizability modes ........................................................... 1336

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 3, Part C Page 1307
Generic Access Profile

4.4.1 Non-synchronizable mode ......................................... 1336

4.4.1.1 Definition .................................................... 1336
4.4.1.2 Term on UI-level ......................................... 1336
4.4.2 Synchronizable mode ................................................ 1336
4.4.2.1 Definition .................................................... 1336
4.4.2.2 Term on UI-level ......................................... 1336

5 Security aspects – BR/EDR physical transport ................................... 1337

5.1 Authentication ........................................................................... 1337
5.1.1 Purpose ..................................................................... 1337
5.1.2 Term on UI level ......................................................... 1337
5.1.3 Procedure .................................................................. 1338
5.1.4 Conditions .................................................................. 1339
5.2 Security modes .......................................................................... 1339
5.2.1 Legacy security modes .............................................. 1340
5.2.1.1 Security mode 1 (non-secure) .................... 1340
5.2.1.2 Security mode 2 (service level
enforced security) ....................................... 1340
5.2.1.3 Security mode 3 (link level enforced
security) ...................................................... 1340
5.2.2 Security mode 4 (service level enforced security) ..... 1341
5.2.2.1 Security for access to remote service
(initiating side) ............................................ 1342
5.2.2.2 Security for access to local service by
remote device (responding side) ................ 1345
5.2.2.3 Secure Simple Pairing after
authentication failure .................................. 1348
5.2.2.4 IO capabilities ............................................. 1349
5.2.2.5 Mapping of input / output capabilities
to IO capability ........................................... 1350
5.2.2.6 IO and OOB capability mapping to
authentication stage 1 method ................... 1350
5.2.2.7 Out of Band (OOB) ..................................... 1352
5.2.2.8 Security database ...................................... 1353

6 Idle mode procedures – BR/EDR physical transport .......................... 1358

6.1 General Inquiry .......................................................................... 1358
6.1.1 Purpose ..................................................................... 1358
6.1.2 Term on UI level ......................................................... 1359
6.1.3 Description ................................................................. 1359
6.1.4 Conditions .................................................................. 1359
6.2 Limited Inquiry ........................................................................... 1359
6.2.1 Purpose ..................................................................... 1359

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 3, Part C Page 1308
Generic Access Profile

6.2.2 Term on UI level ......................................................... 1360

6.2.3 Description ................................................................. 1360
6.2.4 Conditions .................................................................. 1360
6.3 Name Discovery ........................................................................ 1360
6.3.1 Purpose ..................................................................... 1360
6.3.2 Term on UI level ......................................................... 1361
6.3.3 Description ................................................................. 1361
6.3.3.1 Name Request ........................................... 1361
6.3.3.2 Name Discovery ......................................... 1361
6.3.4 Conditions .................................................................. 1362
6.4 Device Discovery ....................................................................... 1362
6.4.1 Purpose ..................................................................... 1362
6.4.2 Term on UI level ......................................................... 1362
6.4.3 Description ................................................................. 1362
6.4.4 Conditions .................................................................. 1363
6.5 Bonding ..................................................................................... 1363
6.5.1 Purpose ..................................................................... 1363
6.5.2 Term on UI level ......................................................... 1363
6.5.3 Description ................................................................. 1364
6.5.3.1 General Bonding ........................................ 1364
6.5.3.2 Dedicated Bonding ..................................... 1364
6.5.4 Conditions .................................................................. 1366

7 Establishment procedures – BR/EDR physical transport ................... 1367

7.1 Link Establishment .................................................................... 1367
7.1.1 Purpose ..................................................................... 1367
7.1.2 Term on UI level ......................................................... 1367
7.1.3 Description ................................................................. 1368
7.1.3.1 B in security mode 1, 2, or 4 ...................... 1368
7.1.3.2 B in security mode 3 ................................... 1369
7.1.4 Conditions .................................................................. 1369
7.2 Channel Establishment ............................................................. 1370
7.2.1 Purpose ..................................................................... 1370
7.2.2 Term on UI level ......................................................... 1370
7.2.3 Description ................................................................. 1370
7.2.3.1 B in security mode 2 or 4 ........................... 1371
7.2.3.2 B in security mode 1 or 3 ........................... 1371
7.2.4 Conditions .................................................................. 1371
7.3 Connection Establishment ........................................................ 1372
7.3.1 Purpose ..................................................................... 1372
7.3.2 Term on UI level ......................................................... 1372
7.3.3 Description ................................................................. 1372
7.3.3.1 B in security mode 2 or 4 ........................... 1372

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 3, Part C Page 1309
Generic Access Profile

7.3.3.2 B in security mode 1 or 3 ........................... 1373

7.3.4 Conditions .................................................................. 1373
7.4 Establishment of additional connection ..................................... 1373
7.5 Synchronization Establishment ................................................. 1374
7.5.1 Purpose ..................................................................... 1374
7.5.2 Term on UI Level ........................................................ 1374
7.5.3 Description ................................................................. 1374
7.5.4 Conditions .................................................................. 1374

8 Extended inquiry response data format ............................................... 1376

9 Operational modes and procedures – LE physical transport ............ 1378

9.1 Broadcast mode and Observation procedure ........................... 1378
9.1.1 Broadcast mode ......................................................... 1379
9.1.1.1 Definition .................................................... 1379
9.1.1.2 Conditions .................................................. 1379
9.1.2 Observation procedure .............................................. 1379
9.1.2.1 Definition .................................................... 1379
9.1.2.2 Conditions .................................................. 1379
9.2 Discovery modes and procedures ............................................. 1380
9.2.1 Requirements ............................................................ 1380
9.2.2 Non-discoverable mode ............................................. 1380
9.2.2.1 Description ................................................. 1380
9.2.2.2 Conditions .................................................. 1381
9.2.3 Limited Discoverable mode ....................................... 1381
9.2.3.1 Description ................................................. 1381
9.2.3.2 Conditions .................................................. 1381
9.2.4 General Discoverable mode ...................................... 1382
9.2.4.1 Description ................................................. 1382
9.2.4.2 Conditions .................................................. 1383
9.2.5 Limited Discovery procedure ..................................... 1384
9.2.5.1 Description ................................................. 1384
9.2.5.2 Conditions .................................................. 1384
9.2.6 General Discovery procedure .................................... 1385
9.2.6.1 Description ................................................. 1385
9.2.6.2 Conditions .................................................. 1386
9.2.7 Name Discovery procedure ....................................... 1387
9.2.7.1 Description ................................................. 1387
9.2.7.2 Conditions .................................................. 1387
9.3 Connection modes and procedures .......................................... 1387
9.3.1 Requirements ............................................................ 1388
9.3.2 Non-connectable mode ............................................. 1389
9.3.2.1 Description ................................................. 1389

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 3, Part C Page 1310
Generic Access Profile

9.3.2.2 Conditions .................................................. 1389

9.3.3 Directed Connectable mode ...................................... 1389
9.3.3.1 Description ................................................. 1389
9.3.3.2 Conditions .................................................. 1389
9.3.4 Undirected Connectable mode .................................. 1389
9.3.4.1 Description ................................................. 1389
9.3.4.2 Conditions .................................................. 1390
9.3.5 Auto Connection Establishment procedure ............... 1390
9.3.5.1 Description ................................................. 1390
9.3.5.2 Conditions .................................................. 1390
9.3.6 General Connection Establishment procedure .......... 1392
9.3.6.1 Description ................................................. 1392
9.3.6.2 Conditions .................................................. 1393
9.3.7 Selective Connection Establishment procedure ........ 1394
9.3.7.1 Description ................................................. 1394
9.3.7.2 Conditions .................................................. 1394
9.3.8 Direct Connection Establishment procedure ............. 1396
9.3.8.1 Description ................................................. 1396
9.3.8.2 Conditions .................................................. 1396
9.3.9 Connection Parameter Update procedure ................. 1397
9.3.9.1 Description ................................................. 1397
9.3.9.2 Conditions .................................................. 1397
9.3.10 Terminate Connection procedure .............................. 1398
9.3.10.1 Description ................................................. 1398
9.3.10.2 Conditions .................................................. 1398
9.3.11 Connection Establishment Timing parameters .......... 1398
9.3.11.1 Description ................................................. 1398
9.3.11.2 Conditions .................................................. 1398
9.3.12 Connection interval timing parameters ...................... 1399
9.3.12.1 Description ................................................. 1399
9.3.12.2 Conditions .................................................. 1400
9.3.13 Connected Isochronous Stream Central
Establishment procedure ........................................... 1401
9.3.13.1 Description ................................................. 1401
9.3.13.2 Conditions .................................................. 1401
9.3.14 Connected Isochronous Stream Peripheral
Establishment procedure ........................................... 1401
9.3.14.1 Description ................................................. 1401
9.3.14.2 Conditions .................................................. 1401
9.3.15 Connected Isochronous Stream Terminate
procedure ................................................................... 1401
9.3.15.1 Description ................................................. 1401
9.3.15.2 Conditions .................................................. 1401

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 3, Part C Page 1311
Generic Access Profile

9.3.16 Connection Subrate procedure .................................. 1402

9.3.16.1 Description ................................................. 1402
9.3.16.2 Conditions .................................................. 1402
9.3.17 Periodic Advertising Connection procedure .............. 1402
9.3.17.1 Definition .................................................... 1402
9.3.17.2 Conditions .................................................. 1402
9.4 Bonding modes and procedures ............................................... 1402
9.4.1 Requirements ............................................................ 1403
9.4.2 Non-bondable mode .................................................. 1403
9.4.2.1 Description ................................................. 1403
9.4.2.2 Conditions .................................................. 1403
9.4.3 Bondable mode ......................................................... 1403
9.4.3.1 Description ................................................. 1403
9.4.3.2 Conditions .................................................. 1403
9.4.4 Bonding procedure .................................................... 1403
9.4.4.1 Description ................................................. 1403
9.4.4.2 Conditions .................................................. 1404
9.5 Periodic advertising modes and procedure ............................... 1404
9.5.1 Periodic Advertising Synchronizability mode ............. 1405
9.5.1.1 Definition .................................................... 1405
9.5.1.2 Conditions .................................................. 1405
9.5.2 Periodic Advertising mode ......................................... 1405
9.5.2.1 Definition .................................................... 1405
9.5.2.2 Conditions .................................................. 1405
9.5.3 Periodic Advertising Synchronization
Establishment procedure ........................................... 1406
9.5.3.1 Definition .................................................... 1406
9.5.3.2 Conditions .................................................. 1406
9.5.4 Periodic Advertising Synchronization Transfer
procedure ................................................................... 1406
9.5.4.1 Definition .................................................... 1406
9.5.4.2 Conditions .................................................. 1406
9.5.5 [This section is no longer used] ................................. 1406
9.5.5.1 .................................................................... 1407
9.5.5.2 .................................................................... 1407
9.6 Isochronous Broadcast modes and procedures ........................ 1407
9.6.1 Broadcast Isochronous Synchronizability mode ........ 1407
9.6.1.1 Definition .................................................... 1407
9.6.1.2 Conditions .................................................. 1407
9.6.2 Broadcast Isochronous Broadcasting mode .............. 1408
9.6.2.1 Definition .................................................... 1408
9.6.2.2 Conditions .................................................. 1408

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 3, Part C Page 1312
Generic Access Profile

9.6.3 Broadcast Isochronous Synchronization

Establishment procedure ........................................... 1408
9.6.3.1 Definition .................................................... 1408
9.6.3.2 Conditions .................................................. 1408
9.6.4 Broadcast Isochronous Channel Map Update
procedure ................................................................... 1408
9.6.4.1 Definition .................................................... 1408
9.6.4.2 Conditions .................................................. 1408
9.6.5 Broadcast Isochronous Terminate procedure ............ 1408
9.6.5.1 Definition .................................................... 1408
9.6.5.2 Conditions .................................................. 1409
9.7 Channel Sounding procedures .................................................. 1409
9.7.1 Channel Sounding initiator procedure ....................... 1409
9.7.1.1 Description ................................................. 1409
9.7.1.2 Conditions .................................................. 1409
9.7.2 Channel Sounding reflector procedure ...................... 1409
9.7.2.1 Description ................................................. 1409
9.7.2.2 Conditions .................................................. 1409

10 Security aspects – LE physical transport ............................................ 1411

10.1 Requirements ............................................................................ 1411
10.2 LE security modes ..................................................................... 1412
10.2.1 LE security mode 1 .................................................... 1412
10.2.2 LE security mode 2 .................................................... 1412
10.2.3 Mixed security modes requirements .......................... 1413
10.2.4 Secure Connections Only mode ................................ 1413
10.2.5 LE security mode 3 .................................................... 1413
10.3 Authentication procedure .......................................................... 1414
10.3.1 Responding to a service request ............................... 1414
10.3.1.1 Handling of GATT indications and
notifications ................................................ 1418
10.3.1.2 Cross-transport key generation .................. 1418
10.3.2 Initiating a service request ......................................... 1418
10.3.2.1 Cross-transport key generation .................. 1422
10.3.2.2 Handling of GATT indications and
notifications ................................................ 1422
10.4 Data signing .............................................................................. 1422
10.4.1 Connection Data Signing procedure .......................... 1422
10.4.2 Authenticate Signed Data procedure ......................... 1423
10.5 Authorization procedure ............................................................ 1424
10.6 Encryption procedure ................................................................ 1424
10.7 Privacy feature .......................................................................... 1425
10.7.1 Privacy feature in a Peripheral .................................. 1426

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 3, Part C Page 1313
Generic Access Profile

10.7.1.1 Privacy feature in a Peripheral with

Controller-based privacy ............................ 1427
10.7.1.2 Privacy feature in a Peripheral with
Host-based privacy .................................... 1427
10.7.2 Privacy feature in a Central ....................................... 1427
10.7.2.1 Privacy feature in a Central with
Controller-based privacy ............................ 1428
10.7.2.2 Privacy feature in a Central with Host-
based privacy ............................................. 1428
10.7.3 Privacy feature in a Broadcaster ............................... 1428
10.7.4 Privacy feature in an Observer .................................. 1429
10.8 Random Device address ........................................................... 1429
10.8.1 Static address ............................................................ 1430
10.8.2 Private address .......................................................... 1430
10.8.2.1 Non-Resolvable Private Address
Generation procedure ................................ 1430
10.8.2.2 Resolvable Private Address
Generation procedure ................................ 1430
10.8.2.3 Resolvable Private Address Resolution
procedure ................................................... 1430
10.9 Encrypted Broadcast Isochronous Group ................................. 1430
10.10 Encrypted Advertising Data procedure ..................................... 1431
10.11 LE Channel Sounding ............................................................... 1431
10.11.1 Channel Sounding security ........................................ 1431

11 Advertising and Scan Response data format ...................................... 1432

12 GAP service and characteristics for GATT Server .............................. 1434

12.1 Device Name characteristic ....................................................... 1435
12.2 Appearance characteristic ......................................................... 1435
12.3 Peripheral Preferred Connection Parameters characteristic ..... 1436
12.4 Central Address Resolution characteristic ................................ 1437
12.5 Resolvable Private Address Only characteristic ....................... 1437
12.6 Encrypted Data Key Material .................................................... 1438
12.7 LE GATT Security Levels Characteristic ................................... 1439

13 BR/EDR/LE operation ............................................................................. 1441

13.1 Modes, procedures, and security aspects ................................. 1441
13.1.1 Discoverable mode requirements .............................. 1441
13.2 Bonding for BR/EDR/LE implementations ................................. 1441
13.3 Relationship between physical transports ................................. 1442

14 BR/EDR/LE security aspects ................................................................. 1443

14.1 Cross-transport key derivation .................................................. 1443

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 3, Part C Page 1314
Generic Access Profile

14.2 Collision handling ...................................................................... 1444

14.3 Secure Connections Only Mode ............................................... 1444

15 Bluetooth Device requirements ............................................................. 1445

15.1 Bluetooth Device address ......................................................... 1445
15.1.1 Bluetooth Device Address types ................................ 1445
15.1.1.1 Public Bluetooth address ........................... 1445
15.1.1.2 Random Bluetooth address ....................... 1445
15.2 GATT Profile requirements ........................................................ 1445
15.3 SDP requirements ..................................................................... 1445
15.4 SDP service record requirement ............................................... 1446

16 Definitions ............................................................................................... 1448

16.1 General definitions .................................................................... 1448
16.2 Connection-related definitions ................................................... 1448
16.3 Device-related definitions .......................................................... 1449
16.4 Procedure-related definitions .................................................... 1450
16.5 Security-related definitions ........................................................ 1450

17 References .............................................................................................. 1452

Appendix A Timers and Constants ................................................................... 1453

Appendix B Information Flows of Related Procedures .................................. 1458

B.1 LMP – authentication ................................................................ 1458
B.2 LMP – pairing ............................................................................ 1459
B.3 Service Discovery ...................................................................... 1459
B.4 Generating a resolvable private address .................................. 1460
B.5 Resolving a resolvable private address .................................... 1460

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 3, Part C Page 1315
Generic Access Profile

1 FOREWORD

Interoperability between devices from different manufacturers is provided for a specific

service and use case, if the devices conform to a Bluetooth SIG- defined profile
specification. A profile defines a selection of messages and procedures (generally
termed capabilities) from the Bluetooth SIG specifications and gives a description of
the air interface for specified service(s) and use case(s).

Whether the provision of a feature is mandatory or optional is stated separately for both
sides of the Bluetooth air interface.

1.1 Scope
The purpose of the Generic Access Profile is:

To introduce definitions, recommendations and common requirements related to modes

and access procedures that are to be used by transport and application profiles.

To describe how devices are to behave in standby and connecting states in order to
avoid situations where links and channels cannot be established between Bluetooth
devices or that prevent multi-profile operation. Special focus is put on discovery, link
establishment and security procedures.

To state requirements on user interface aspects, mainly coding schemes and names of
procedures and parameters, that are needed to provide a satisfactory user experience.

This profile defines three implementation transport types based on the supported Core
Configurations as defined in [Vol 0] Part D, Section 2. These implementation transport
types are defined in Table 1.1:

Implementation Description
Transport Type
BR/EDR-only Implementations of a BR/EDR Core Configuration (see [Vol 0] Part D, Sec-
tion 2.1.1, [Vol 0] Part D, Section 2.2.1, and [Vol 0] Part D, Section 2.3.1)
LE only Implementations of an LE Core Configuration (see [Vol 0] Part D, Sec-
tion 2.1.2, [Vol 0] Part D, Section 2.2.2, and [Vol 0] Part D, Section 2.3.2)
BR/EDR/LE Implementations of a BR/EDR/LE Core Configuration (see [Vol 0] Part
D, Section 2.1.3, [Vol 0] Part D, Section 2.2.3, and [Vol 0] Part D, Sec-
tion 2.3.3)

Table 1.1: Implementation transport types

The terms physical transport, physical link and physical channel as defined in [Vol 1]
Part A, Section 3 are used in the specification.

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 3, Part C Page 1316
Generic Access Profile

1.2 Symbols and conventions

1.2.1 [This section is no longer used]

1.2.2 Signaling diagram conventions

The arrows shown in Figure 1.1 are used in diagrams describing procedures:

A B

PROC1

PROC2

PROC3

PROC4

PROC5

MSG1

MSG2

MSG3

Figure 1.1: Arrows used in signaling diagrams

In Figure 1.1, the following cases are shown: PROC1 is a sub-procedure initiated by
B. PROC2 is a sub-procedure initiated by A. PROC3 is a sub-procedure where the
initiating side is undefined (may be both A or B). Dashed arrows denote optional steps.
PROC4 indicates an optional sub-procedure initiated by A, and PROC5 indicates an
optional sub-procedure initiated by B.

MSG1 is a message sent from B to A. MSG2 is a message sent from A to B. MSG3

indicates an optional message from A to B.

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 3, Part C Page 1317
Generic Access Profile

1.2.3 Notation for timers and counters

Timers are introduced specific to this profile. To distinguish them from timers used in
the Bluetooth protocol specifications and other profiles, these timers are named in the
following format: ’TGAP(nnn)’.

1.2.4 Notation for UUIDs

The use of « » (e.g. «Device Name») indicates a Bluetooth SIG-defined UUID.

1.3 GAP requirements

The sections of GAP that apply to an implementation depend on which Core-Host
Configuration or Core-Complete Configuration (see [Vol 0] Part D, Section 2) it
implements, as shown in Table 1.2.

Core Configuration Applicable sections

BR/EDR 1 to 8, 12, 15 to 17, Appendices A and B
LE 1 to 3, 9 to 12, 15 to 17, Appendices A and B
BR/EDR/LE All

Table 1.2: Required sections for each Core Configuration

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 3, Part C Page 1318
Generic Access Profile

2 PROFILE OVERVIEW

2.1 Profile stack

GAP Generic Attribute Profile

(GATT)
Security
Manager
SDP (SM) Attribute Protocol (ATT)

Logical Link Control and Adaptation Protocol (L2CAP)

Link Manager Protocol (LMP) Link Layer (LL)

Figure 2.1: Relationship of GAP with lower layers of the Bluetooth architecture

The purpose of this profile is to describe:

• Profile roles
• Discoverability modes and procedures
• Connection modes and procedures
• Security modes and procedures

2.2 Profile roles

2.2.1 Roles when operating over BR/EDR Physical Transport

In GAP, for describing the Bluetooth communication that occurs between two devices in
the BR/EDR GAP role, the generic notation of the A-party (the paging device in case
of link establishment, or initiator in case of another procedure on an established link)
and the B-party (paged device or acceptor) is used. The A-party is the one that, for a
given procedure, initiates device discovery, initiates the establishment of a physical link
or initiates a transaction on an existing link.

This profile handles the procedures between two devices related to discovery and
connecting (link and connection establishment) for the case where none of the two
devices has any link established as well as the case where (at least) one device has a
link established (possibly to a third device) before starting the described procedure.

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 3, Part C Page 1319
Generic Access Profile

Figure 2.2: This profile covers procedures initiated by one device (A) towards another device (B) whether
or not they have an existing Bluetooth link active

The initiator and the acceptor generally operate the generic procedures according to
this profile or another profile referring to this profile. If the acceptor operates according
to several profiles simultaneously, this profile describes generic mechanisms for how to
handle this.

2.2.2 Roles when operating over an LE physical transport

There are four GAP roles defined for devices operating over an LE physical transport:

• Broadcaster
• Observer
• Peripheral
• Central

The GAP roles "Central" and "Peripheral" are related to, but not the same as, the Link
Layer roles with the same names and therefore can have different requirements. If a
connection is established successfully, the device with one of these GAP roles will also
have the corresponding Link Layer role. However, the device can be in the GAP role
without a connection being established.

Table 2.1 defines requirements for physical layer and Link Layer functionalities for each
GAP role when operating over an LE physical transport.

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 3, Part C Page 1320
Generic Access Profile

GAP Roles When Operating Over an

LE Physical Transport
Broadcaster Observer Peripheral Central
Physical layer functionality:
• Transmitter characteristics M O M M
• Receiver characteristics O M M M
Link Layer functionality:
States:
• Standby state M M M M
• Advertising state M E M E
• Scanning state E M E M
• Initiating state E E E M
• Synchronization State E O E E
• Isochronous Broadcasting State O E E E
• Connection state Peripheral role E E M E
Central role E E E M
Advertising event types:
• Connectable and scannable undirected event E E M E
• Connectable undirected event1 E E O E
• Connectable directed event E E O E
• Non-connectable and non-scannable undirec- M E O E
ted event
• Non-connectable and non-scannable directed O E O E
event1
• Scannable undirected event O E O E
• Scannable directed event1 O E O E
Scanning type:
• Passive scanning E M E O
• Active scanning E O E C.1
Link Layer control procedures:
• Connection Update procedure E E M M
• Channel Map Update procedure E E M M
• Encryption procedure E E O O
• Central-initiated Feature Exchange procedure E E M M

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 3, Part C Page 1321
Generic Access Profile

GAP Roles When Operating Over an

LE Physical Transport
Broadcaster Observer Peripheral Central
• Peripheral-initiated Feature Exchange proce- E E C.2 C.2
dure
• Connection Parameters Request procedure E E O O
• Version Exchange procedure E E M M
• ACL Termination procedure E E M M
• LE Ping procedure E E O O
• Data Length Update procedure E E O O
• PHY Update procedure E E O O
• Minimum Number Of Used Channels proce- E E O O
dure
• Periodic Advertising Sync Transfer procedure E E O O
• Connected Isochronous Stream Creation pro- E E O O
cedure
• Connected Isochronous Stream Termination E E O O
procedure
Broadcast control procedures:
• Broadcast Isochronous Channel Map Update O O E E
procedure
• Broadcast Isochronous Termination procedure O O E E
C.1: Optional if passive scanning is supported, otherwise mandatory.
C.2: Mandatory if Connection Parameters Request procedure is supported, otherwise optional.
Table 2.1: GAP requirements for physical layer and Link Layer functionalities for each GAP role when
operating over an LE physical transport

1These advertising event types are excluded if the device does not support LE Extended Advertising.

2.2.2.1 Broadcaster role

A device operating in the Broadcaster role is a device that sends advertising events
or periodic advertising events as described in [Vol 6] Part B, Section 4.4.2, and may
also send Broadcast Isochronous Stream (BIS) events as described in [Vol 6] Part B,
Section 4.4.6. A device operating in the Broadcaster role is referred to as a Broadcaster
and shall have a transmitter and may have a receiver.

2.2.2.2 Observer role

A device operating in the Observer role is a device that receives advertising events or
periodic advertising events as described in [Vol 6] Part B, Section 4.4.3, and may also

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 3, Part C Page 1322
Generic Access Profile

receive BIS events as described in [Vol 6] Part B, Section 4.4.6. A device operating in
the Observer role is referred to as an Observer and shall have a receiver and may have
a transmitter.

2.2.2.3 Peripheral role

Any device that accepts the establishment of an LE active physical link using any of the
connection establishment procedures as defined in Section 9 is referred to as being in
the Peripheral role. A device operating in the Peripheral role will be in the Peripheral
role in the Link Layer Connection state as described in [Vol 6] Part B, Section 4.5. A
device operating in the Peripheral role is referred to as a Peripheral. A Peripheral shall
have both a transmitter and a receiver.

2.2.2.4 Central role

A device that supports the Central role initiates the establishment of an LE active
physical link. A device operating in the Central role will be in the Central role in the Link
Layer Connection state as described in [Vol 6] Part B, Section 4.5. A device operating in
the Central role is referred to as a Central. A Central shall have both a transmitter and a
receiver.

2.2.2.5 Concurrent operation in multiple GAP roles

A device may operate in multiple GAP roles concurrently if supported by the Controller.
The Host should read the supported Link Layer states and state combinations from the
Controller before any procedures or modes are used.

2.3 User requirements and scenarios

The Bluetooth user should, where expected, be able to connect a Bluetooth device
to any other Bluetooth device. Even if the two connected devices don’t share any
common application, it should be possible for the user to find this out using basic
Bluetooth capabilities. When the two devices do share the same application but are
from different manufacturers, the ability to connect them should not be blocked just
because manufacturers choose to call basic Bluetooth capabilities by different names
on the user interface level or implement basic procedures to be executed in different
orders.

2.4 Profile fundamentals

This profile states the requirements on names, values and coding schemes used for
names of parameters and procedures experienced on the user interface level.

This profile defines modes of operation that are not service- or profile-specific, but
that are generic and can be used by profiles referring to this profile, and by devices
implementing multiple profiles.

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 3, Part C Page 1323
Generic Access Profile

This profile defines the general procedures that can be used for discovering identities,
names and basic capabilities of other Bluetooth devices that are in a mode where they
can be discovered. Only procedures where no channel or connection establishment is
used are specified.

This profile defines the general procedure for how to create bonds (i.e., dedicated
exchange of link keys) between Bluetooth devices.

This profile describes the general procedures that can be used for establishing
connections to other Bluetooth devices that are in a mode that allows them to accept
connections and service requests.

2.5 [This section is no longer used]

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 3, Part C Page 1324
Generic Access Profile

3 USER INTERFACE ASPECTS

3.1 The user interface level

In the context of the specification, the user interface level refers to places (such
as displays, dialog boxes, manuals, packaging, advertising, etc.) where users of
Bluetooth devices encounters names, values and numerical representation of Bluetooth
terminology and parameters.

This profile specifies the generic terms that should be used on the user interface level.

3.2 Representation of Bluetooth parameters

3.2.1 Bluetooth Device Address (BD_ADDR)

3.2.1.1 Definition

A BD_ADDR is the address used by a Bluetooth device as defined in Section 15.1. It is

received from a remote device during the device discovery procedure.

3.2.1.2 Term on user interface level

When the Bluetooth address is referred to on the UI level, the term ‘Bluetooth Device
Address’ should be used.

3.2.1.3 Representation

On the Baseband level the BD_ADDR is represented as 48 bits (see [Vol 2] Part B,
Section 1.2). On the Link Layer the public and random device address are represented
as 48-bit addresses.

On the UI level the Bluetooth address shall be represented as 12 hexadecimal

characters, possibly divided into sub-parts separated by ‘:’ (e.g., ‘000C3E3A4B69’ or
‘00:0C:3E:3A:4B:69’). On the UI level any number shall have the MSB -&gt; LSB (from
left to right) ‘natural’ ordering.

3.2.2 Bluetooth Device Name (the user-friendly name)

3.2.2.1 Definition

The Bluetooth Device Name is the user-friendly name that a Bluetooth device exposes
to remote devices. For a BR/EDR-only implementation, the name is a character string
returned in the LMP_NAME_RES in response to an LMP_NAME_REQ. For an LE-only
implementation, the name is a character string held in the Device Name characteristic
as defined in Section 12.1.

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 3, Part C Page 1325
Generic Access Profile

3.2.2.1.1 Bluetooth Device Name in a BR/EDR/LE implementation

A BR/EDR/LE implementation shall have a single Bluetooth Device Name which shall
be identical irrespective of the physical channel used to perform the name discovery
procedure.

For the BR/EDR physical channel the name is received in the LMP_NAME_RES. For
the LE physical channel the name can be read from the Device Name characteristic as
defined in Section 12.1.

Note: The Device Name Characteristic of the local device can be read by a remote
device using ATT over BR/EDR if the local device supports ATT over BR/EDR.

3.2.2.2 Term on user interface level

When the Bluetooth Device Name is referred to on the UI level, the term ‘Bluetooth
Device Name’ should be used.

3.2.2.3 Representation

The Bluetooth Device Name can be up to 248 bytes (see [Vol 2] Part C, Section 4.3.5).
It shall be encoded according to UTF-8 (therefore the name entered on the UI level
may be restricted to as few as 62 characters if codepoints outside the range U+0000 to
U+007F are used).

A device cannot expect that a general remote device is able to handle more than the
first 40 characters of the Bluetooth Device Name. If a remote device has limited display
capabilities, it may use only the first 20 characters.

3.2.3 Bluetooth Passkey (Bluetooth PIN)

3.2.3.1 Definition

The Bluetooth Passkey may be used to authenticate two Bluetooth devices with each
other during the creation of a mutual link key via the pairing procedure. The passkey
may be used in the pairing procedures to generate the initial link key.

The PIN may be entered on the UI level but may also be stored in the device; e.g., in
the case of a device without an interface for entering and displaying digits.

3.2.3.2 Terms at user interface level

When the Bluetooth PIN is referred to on the UI level, the term ‘Bluetooth Passkey’
should be used.

3.2.3.3 Representation

There are a number of different representations of the Bluetooth Passkey. At a high

level there are two distinct representations: one used with the Secure Simple Pairing

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 3, Part C Page 1326
Generic Access Profile

and Security Manager, and another used with legacy pairing (where it is generally
referred to as the Bluetooth PIN).

For Secure Simple Pairing and Security Manager, the Bluetooth Passkey is a 6-
digit numerical value. It is represented as integer value in the range 0x00000000 –
0x000F423F (000000 to 999999). The numeric value may be used as the input to the
Authentication stage 1 for Secure Simple Pairing Passkey Entry (see [Vol 2] Part H,
Section 7.2.3), or as the TK value in the Security Manager for the process defined in
[Vol 3] Part H, Section 2.3.5.

For legacy pairing (see Section B.2), the Bluetooth PIN has different representations on
different levels. PINBB is used on the Baseband level, and PINUI is used on the user
interface level. PINBB is the PIN used in [Vol 2] Part H, Section 3.2.1 for calculating the
initialization key during the Pairing procedure.

PINUI is the character representation of the PIN that is entered on the UI level. The
transformation from PINUI to PINBB shall be according to UTF-8. PINBB may be 128
bits (16 bytes).

PIN codes may be up to 16 characters. In order to take advantage of the full level of
security all PINs should be 16 characters long. Variable PINs should be composed of
alphanumeric characters chosen from within the Unicode range U+0000 to U+007F. If
the PIN contains any decimal digits these shall be encoded using the Unicode Basic
Latin characters (i.e., U+0030 to U+0039) (Note 1).

For compatibility with devices with numeric keypads, fixed PINs shall be composed of
only decimal digits, and variable PINs should be composed of only decimal digits.

If a device supports entry of characters outside the Unicode range U+0000 to U+007F,
other Unicode code points may be used (Note 2), except the Halfwidth and Fullwidth
Forms (i.e., U+FF00 to U+FFEF) shall not be used (Note 3).

Examples:

User-entered code Corresponding PINBB[0..length-1]

(value as a sequence of octets in hexadecimal notation)
’0196554200906493’ length = 16, value = 0x30 0x31 0x39 0x36 0x35 0x35 0x34 0x32 0x30 0x30
0x39 0x30 0x36 0x34 0x39 0x33
’Børnelitteratur’ length = 16, value = 0x42 0xC3 0xB8 0x72 0x6E 0x65 0x6C 0x69 0x74 0x74
0x65 0x72 0x61 0x74 0x75 0x72

Note 1: This is to prevent interoperability problems since there are decimal digits at
other code points (e.g., the Fullwidth digits at code points U+FF10 to U+FF19).

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 3, Part C Page 1327
Generic Access Profile

Note 2: Unicode characters outside the Basic Latin range (U+0000 to U+007F) encode
to multiple bytes; therefore, when characters outside the Basic Latin range are used
the maximum number of characters in the PINUI will be less than 16. The second
example illustrates a case where a 15 character string encodes to 16 bytes because the
character ø is outside the Basic Latin range and encodes to two bytes (0xC3 0xB8).

Note 3: This is to prevent interoperability problems since the Halfwidth and Fullwidth
forms contain alternative variants of ASCII, Katakana, Hangul, punctuation and
symbols. All of the characters in the Halfwidth and Fullwidth forms have other related
Unicode characters; for example, U+3150 (Hangul Letter AE) can be used instead of
U+FFC3 (Halfwidth Hangul Letter AE).

3.2.4 Class of Device

3.2.4.1 Definition

Class of Device is a parameter received during the device discovery procedure on

the BR/EDR physical transport, indicating the type of device. The Class of Device
parameter is only used on BR/EDR and BR/EDR/LE devices using the BR/EDR
physical transport.

3.2.4.2 Term on user interface level

The information within the Class of Device parameter should be referred to as

‘Bluetooth Device Class’ (i.e., the major and minor device class fields) and ‘Bluetooth
Service Type’ (i.e., the service class field). The terms for the defined Bluetooth Device
Classes and Bluetooth Service Types are defined in [3].

When using a mix of information found in the Bluetooth Device Class and the Bluetooth
Service Type, the term ‘Bluetooth Device Type’ should be used.

3.2.4.3 Representation

The Class of Device is a bit field and is defined in [3]. The UI-level representation of the
information in the Class of Device is implementation specific.

3.2.4.4 Usage

Some devices provide more than one service and a given service may be provided
by different device types. Therefore, the device type does not have a one-to-one
relationship with services supported. The major and minor device class field should
not be used to determine whether a device supports any specific service(s). It may
be used as an indication of devices that are most likely to support desired services
before service discovery requests are made, and it may be used to guide the user when
selecting among several devices that support the same service.

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 3, Part C Page 1328
Generic Access Profile

3.2.5 Appearance characteristic

3.2.5.1 Definition

The Appearance characteristic contains a 16-bit number that can be mapped to an

icon or string that describes the physical representation of the device during the device
discovery procedure. It is a characteristic of the GAP service located on the device’s
GATT Server. See Section 12.2.

3.2.5.2 Usage at user interface level

The Appearance characteristic value should be mapped to an icon or string or

something similar that conveys to the user a visual description of the device. This allows
the user to determine which device is being discovered purely by visual appearance. If
a string is displayed, this string should be translated into the language selected by the
user for the device.

3.2.5.3 Representation

The Appearance characteristic value shall be set to one of the 16-bit numbers assigned
by the Bluetooth SIG and defined in Section 1.12 of [4]. The UI-level representation of
the Appearance characteristic value is implementation specific.

3.2.6 Broadcast Code

3.2.6.1 Definition

The Broadcast_Code parameter is used to support an encrypted BIG. It is used in

the process of encrypting the data in the transmission of an encrypted BIG and in the
process of decrypting the data in the reception of a BIS within that BIG.

3.2.6.2 Terms at user interface level

When the Broadcast_Code parameter is referred to on the UI level, the term ‘Bluetooth
Privacy Code’ should be used.

3.2.6.3 Representation

The Broadcast_Code parameter has different representations on different levels.

On the UI level, the Broadcast Code parameter shall be represented as a string of at

least 4 octets that meets the requirements in Section 3.2.3.3 for a PINUI (e.g., it is not
more than 16 octets when represented in UTF-8). 16 octets should be used for higher
level of security.

On all levels other than UI, the Broadcast Code parameter shall be represented as
a 128-bit value. The transformation from string to number shall be by representing

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 3, Part C Page 1329
Generic Access Profile

the string in UTF-8, placing the resulting bytes in 8-bit fields of the value starting
at the least significant bit, and then padding with zeros in the most significant bits
if necessary. For example, the string “Børne House” is represented as the value
0x00000000_6573756F_4820656E_72B8C342.

3.3 Pairing
Pairing over a BR/EDR physical link is defined on LMP level (LMP pairing, see
Section B.2). Pairing over an LE physical link is defined by the Security Manager
specification ([Vol 3] Part H, Section 2.3). Either the user initiates the bonding procedure
and enters the passkey with the explicit purpose of creating a bond (and maybe also a
secure relationship) between two Bluetooth devices, or the user is requested to enter
the passkey during the establishment procedure since the devices did not share a
common link key beforehand. In the first case, the user is said to perform “bonding (with
entering of passkey)” and in the second case the user is said to “authenticate using the
passkey.”

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 3, Part C Page 1330
Generic Access Profile

4 MODES – BR/EDR PHYSICAL TRANSPORT

Group Ref. Mode Support

Discoverability modes: 4.1 Non-discoverable C.1
Limited discoverable O
General discoverable O
Connectability modes: 4.2 Non-connectable O
Connectable M
Bondable modes: 4.3 Non-bondable C.4
Bondable C.2
Synchronizability modes: 4.4 Non-synchronizable M
Synchronizable C.5
C.1: Mandatory if limited discoverable mode is supported or general discoverable mode is not
supported, otherwise optional.
C.2: Mandatory if the bonding procedure is supported, otherwise optional.
C.4: Optional if Bondable mode is supported, otherwise mandatory.
C.5: Mandatory if the Synchronization Train procedure is supported, otherwise excluded.
Table 4.1: Conformance requirements related to modes defined in this section

4.1 Discoverability modes

With respect to inquiry, a Bluetooth device shall be either in non-discoverable mode or
in a discoverable mode. (The device shall be in one, and only one, discoverability mode
at a time.) The two discoverable modes defined here are called limited discoverable
mode and general discoverable mode. Inquiry is defined in [Vol 2] Part B, Section 8.4.

When a Bluetooth device is in non-discoverable mode it does not respond to inquiry.

A Bluetooth device is said to be made discoverable, or set into a discoverable mode,

when it is in limited discoverable mode or in general discoverable mode. Even when a
Bluetooth device is made discoverable, it may be unable to respond to inquiry due to
other Baseband activity (for example, reserved synchronous slots should have priority
over response packets, so that synchronous links may prevent a response from being
returned). A Bluetooth device that does not respond to inquiry is called a silent device.

After being made discoverable, the Bluetooth device shall be discoverable for at least
TGAP(103).

The speed of discovery is dependent on the configuration of the inquiry scan interval
and inquiry scan type of the Bluetooth device. The Host is able to configure these

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 3, Part C Page 1331
Generic Access Profile

parameters based on trade-offs between power consumption, bandwidth and the

desired speed of discovery.

4.1.1 Non-discoverable mode

4.1.1.1 Definition

When a Bluetooth device is in non-discoverable mode, it shall never enter the

INQUIRY_SCAN state.

4.1.1.2 Term on UI-level

Bluetooth device is ‘non-discoverable’ or in ’non-discoverable mode’.

4.1.2 Limited Discoverable mode

4.1.2.1 Definition

The limited discoverable mode should be used by devices that need to be discoverable
only for a limited period of time, during temporary conditions, or for a specific event.

There are two common reasons to use limited discoverable mode:

• Limited discoverable mode can be used to allow remote devices using the general
inquiry procedure to prioritize or otherwise identify devices in limited discoverable
mode when presenting discovered devices to the end user because, typically, the
user is interacting with them.
• Limited discoverable mode can also be used to allow remote devices using the limited
inquiry procedure to filter out devices using the general discoverable mode.

A Bluetooth device should not be in limited discoverable mode for more than TGAP(104).
The scanning for the limited inquiry access code can be done either in parallel or
in sequence with the scanning of the general inquiry access code. When in limited
discoverable mode, one of the following options shall be used.

• Parallel scanning
When a Bluetooth device is in limited discoverable mode and when discovery speed
is more important than power consumption or bandwidth, it is recommended that the
Bluetooth device enter the INQUIRY_SCAN state at least every TGAP(105) and that
Interlaced Inquiry scan is used.
If, however, power consumption or bandwidth is important, but not critical, it is
recommended that the Bluetooth device enter the INQUIRY_SCAN state at least
every TGAP(102) and Interlaced Inquiry scan is used.

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 3, Part C Page 1332
Generic Access Profile

When power consumption or bandwidth is critical it is recommended that the

Bluetooth device enter the INQUIRY_SCAN state at least every TGAP(102) and Non-
interlaced Inquiry scan is used.
In all cases the Bluetooth device shall enter the INQUIRY_SCAN state at least once
in TGAP(102) and scan for the GIAC and the LIAC for at least TGAP(101).
When either a SCO or eSCO link is in operation, it is recommended to use interlaced
scan to significantly decrease the discoverability time.
• Sequential scanning
When a Bluetooth device is in limited discoverable mode, it shall enter the
INQUIRY_SCAN state at least once in TGAP(102) and scan for the GIAC for at least
TGAP(101) and enter the INQUIRY_SCAN state more often than once in TGAP(102)
and scan for the LIAC for at least TGAP(101).
If an inquiry message is received when in limited discoverable mode, the entry
into the INQUIRY_RESPONSE state takes precedence over the next entries into
INQUIRY_SCAN state until the inquiry response is completed.

4.1.2.2 Conditions

When a device is in limited discoverable mode it shall set bit number 13 in the Major
Service Class part of the Class of Device/Service field [3].

4.1.2.3 Term on UI-level

Bluetooth device is ‘discoverable’ or in ‘discoverable mode’.

4.1.3 General Discoverable mode

4.1.3.1 Definition

The general discoverable mode shall be used by devices that need to be

discoverable continuously or for no specific condition.

Devices in the general discoverable mode will not be discovered by devices performing
the limited inquiry procedure. General discoverable mode should not be used if it is
known that the device performing discovery will be using the limited inquiry procedure
(see Section 6.1).

4.1.3.2 Conditions

When a Bluetooth device is in general discoverable mode and when discovery speed
is more important than power consumption or bandwidth, it is recommended that the
Bluetooth device enter the INQUIRY_SCAN state at least every TGAP(105) and that
Interlaced Inquiry scan is used.

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 3, Part C Page 1333
Generic Access Profile

If, however, power consumption or bandwidth is important, but not critical, it is

recommended that the Bluetooth device enter the INQUIRY_SCAN state at least every
TGAP(102) and Interlaced Inquiry scan is used.

When power consumption or bandwidth is critical it is recommended that the Bluetooth

device enter the INQUIRY_SCAN state at least every TGAP(102) and Non-interlaced
Inquiry scan is used.

In all cases the Bluetooth device shall enter the INQUIRY_SCAN state at least once in
TGAP(102) and scan for the GIAC for at least TGAP(101).

When either a SCO or eSCO link is in operation, it is recommended to use interlaced

scan to significantly decrease the discoverability time.

A device in general discoverable mode shall not respond to a LIAC inquiry.

4.1.3.3 Term on UI-level

Bluetooth device is ‘discoverable’ or in ‘discoverable mode’.

4.2 Connectability modes

With respect to paging, a Bluetooth device shall be either in non-connectable mode or

connectable mode. Paging is defined in [Vol 2] Part B, Section 8.3.

When a Bluetooth device is in non-connectable mode it does not respond to paging.

When a Bluetooth device is in connectable mode it responds to paging.

The speed of connections is dependent on the configuration of the page scan interval
and page scan type of the Bluetooth device. The Host is able to configure these
parameters based on trade-offs between power consumption, bandwidth and the
desired speed of connection.

4.2.1 Non-connectable mode

4.2.1.1 Definition

When a Bluetooth device is in non-connectable mode it shall never enter the

PAGE_SCAN state.

4.2.1.2 Term on UI-level

Bluetooth device is ‘non-connectable’ or in ‘non-connectable mode’.

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 3, Part C Page 1334
Generic Access Profile

4.2.2 Connectable mode

4.2.2.1 Definition

When a Bluetooth device is in connectable mode it shall periodically enter the

PAGE_SCAN state. The device performs page scan using the Bluetooth Device
Address, BD_ADDR. Connection speed is a trade-off between power consumption /
available bandwidth and speed. The Bluetooth Host is able to make these trade-offs
using the Page Scan interval, Page Scan window, and Interlaced Scan parameters.

R0 page scanning should be used when connection speeds are critically important and
when the paging device has a very good estimate of the Bluetooth clock. Under these
conditions it is possible for paging to complete within two times the page scan window.
Because the page scan interval is equal to the page scan window it is not possible
for any other traffic to go over the Bluetooth link when using R0 page scanning. In R0
page scanning it is not possible to use interlaced scan. R0 page scanning is the highest
power consumption mode of operation.

When connection times are critical but the other device either does not have an
estimate of the Bluetooth clock or when the estimate is possibly out of date, it is better
to use R1 page scanning with a very short page scan interval, TGAP(106), and Interlaced
scan. This configuration is also useful to achieve nearly the same connection speeds
as R0 page scanning but using less power and leaving bandwidth available for other
connections. Under these circumstances it is possible for paging to complete within
TGAP(106). In this case the Bluetooth device shall page scan for at least TGAP(101).

When connection times are important but not critical enough to sacrifice significant
bandwidth and/or power consumption it is recommended to use either TGAP(107) or
TGAP(108) for the scanning interval. Using Interlaced scan will reduce the connection
time by half but may use twice the power consumption. Under these circumstances it
is possible for paging to complete within one or two times the page scanning interval
depending on whether Interlaced Scan is used. In this case the Bluetooth device shall
page scan for at least TGAP(101).

In all cases the Bluetooth device shall enter the PAGE_SCAN state at least once in
TGAP(102) and scan for at least TGAP(101).

The page scan interval, page scan window size, and scan type for the six scenarios are
described in Table 4.2:

Scenario Page Scan Interval Page Scan Window Scan Type

R0 (1.28 s) TGAP(107) TGAP(107) Normal scan
Fast R1 (100 ms) TGAP(106) TGAP(101) Interlaced scan

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 3, Part C Page 1335
Generic Access Profile

Scenario Page Scan Interval Page Scan Window Scan Type

Medium R1 (1.28 s) TGAP(107) TGAP(101) Interlaced scan
Slow R1 (1.28 s) TGAP(107) TGAP(101) Normal scan
Fast R2 (2.56 s) TGAP(108) TGAP(101) Interlaced scan
Slow R2 (2.56 s) TGAP(108) TGAP(101) Normal scan
Table 4.2: Page scan parameters for connection speed scenarios

When either a SCO or eSCO link is in operation, it is recommended to use interlaced

scan to significantly decrease the connection time.

4.2.2.2 Term on UI-level

Bluetooth device is ‘connectable’ or in ‘connectable mode’.

4.3 Bondable modes

With respect to bonding, a Bluetooth device shall be either in non-bondable mode or
in bondable mode. In bondable mode the Bluetooth device accepts bonding initiated by
the remote device, and in non-bondable mode it does not.

4.3.1 Non-bondable mode

4.3.1.1 Definition

When a Bluetooth device is in non-bondable mode it shall not accept a pairing request
that results in bonding. Devices in non-bondable mode may accept connections that do
not request or require bonding.

A device in non-bondable mode shall respond to a received LMP_IN_RAND with

LMP_NOT_ACCEPTED with the reason pairing not allowed.

When both devices support Secure Simple Pairing and the local device is in non-
bondable mode, the local Host shall respond to an IO capability request where
the Authentication_Requirements parameter requests dedicated bonding or general
bonding with a negative response.

4.3.1.2 Term on UI-level

Bluetooth device is ‘non-bondable’ or in ‘non-bondable mode’ or “does not accept

bonding”.

4.3.2 Bondable mode

4.3.2.1 Definition

When a Bluetooth device is in bondable mode, and Secure Simple Pairing is not
supported by either the local or remote device, the local device shall respond to a

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 3, Part C Page 1336
Generic Access Profile

received LMP_IN_RAND with LMP_ACCEPTED (or with LMP_IN_RAND if it has a fixed

PIN).

When both devices support Secure Simple Pairing, the local Host shall respond to a
user confirmation request with a positive response.

4.3.2.2 Term on UI-level

Bluetooth device is ‘bondable’ or in ‘bondable mode’ or “accepts bonding”.

4.4 Synchronizability modes

A Bluetooth device shall be either in non-synchronizable mode or synchronizable mode.
The synchronization train procedure is defined in [Vol 2] Part B, Section 2.7.2.

When a Bluetooth device is in synchronizable mode, it transmits timing and frequency

information for its active Connectionless Peripheral Broadcast packets. When a
Bluetooth device is non-synchronizable, timing and frequency information is not
transmitted.

The Host is able to configure the Synchronization Train interval based on trade-offs
between bandwidth, potential interference to other devices, power consumption, and the
desired time for a Peripheral to receive a synchronization train packet.

4.4.1 Non-synchronizable mode

4.4.1.1 Definition

When a Bluetooth device is in non-synchronizable mode it shall never enter the

Synchronization Train substate.

4.4.1.2 Term on UI-level

Bluetooth device is ‘non-synchronizable’ or in ‘non-synchronizable mode’.

4.4.2 Synchronizable mode

4.4.2.1 Definition

When a Bluetooth device is in synchronizable mode, it shall enter the Synchronization

Train substate using a synchronization train interval of TGAP(Sync_Train_Interval).

After being made synchronizable, the Bluetooth device shall be synchronizable for at
least TGAP(Sync_Train_Duration).

4.4.2.2 Term on UI-level

Bluetooth device is 'synchronizable' or in 'synchronizable mode'.

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 3, Part C Page 1337
Generic Access Profile

5 SECURITY ASPECTS – BR/EDR PHYSICAL

TRANSPORT

Procedure Ref. Support

Authentication 5.1 M
Security mode 1 5.2.1.1 E
Security mode 2 5.2.1.2 C.1
Security mode 3 5.2.1.3 E
Security mode 4 5.2.2 M
C.1: Security mode 2 may only be used for backwards compatibility when the remote device does
not support Secure Simple Pairing.

Table 5.1: Conformance requirements related to the generic authentication procedure and the security
modes defined in this section

5.1 Authentication
5.1.1 Purpose

The generic authentication procedure describes how the LMP-authentication and LMP-
pairing procedures are used when authentication is initiated by one Bluetooth device
towards another, depending on if a link key exists or not and if pairing is allowed or not.

5.1.2 Term on UI level

‘Bluetooth authentication’.

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 3, Part C Page 1338
Generic Access Profile

5.1.3 Procedure

Figure 5.1 defines the generic authentication procedure.

Authentication
start

link yes
authenticated
already?

no

link key yes

available?

no
fail
LMP authentication

ok

no Initiate
pairing?

yes

fail
LMP pairing

ok

authentication
authentication ok
failed

Figure 5.1: Definition of the generic authentication procedure

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 3, Part C Page 1339
Generic Access Profile

5.1.4 Conditions

The local device shall initiate authentication after link establishment. The remote device
may initiate security during or after link establishment.

5.2 Security modes

The flow chart in Figure 5.2, including the steps in Figure 5.3, Figure 5.4, and
Figure 5.5, specifies the overall channel establishment procedures. The following
subsections give more details of these procedures.

Paging

Link Setup

LMP_HOST_
CONNECTION_REQ

Yes Security initiated

by remote device?

No
Figure 5.3
(pre-2.1 only)

LMP_ACCEPTED

Link Setup
complete

Responding
2.0 or lower
Device version?
2.1 or higher

Initiating Side Role? Responding Side

Figure 5.4 Figure 5.5

Security Mode 2
(Security Mode 4) (Security Mode 4)

Figure 5.2: Channel establishment with security

A device may support two security modes simultaneously: security mode 2 for
backwards compatibility with remote devices that do not support Secure Simple Pairing
and security mode 4 for devices that support Secure Simple Pairing.

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 3, Part C Page 1340
Generic Access Profile

5.2.1 Legacy security modes

Legacy security modes apply to those devices with a Controller or a Host that does not
support SSP.

5.2.1.1 Security mode 1 (non-secure)

When a remote Bluetooth device is in security mode 1 it will never initiate any
security procedure (i.e., it will never send LMP_AU_RAND, LMP_IN_RAND or
LMP_ENCRYPTION_MODE_REQ).

5.2.1.2 Security mode 2 (service level enforced security)

When a remote Bluetooth device is in security mode 2 it will not initiate any security
procedure before a channel establishment request (L2CAP_CONNECTION_REQ) has
been received or a channel establishment procedure has been initiated by itself.
Whether a security procedure is initiated or not depends on the security requirements of
the requested channel or service.

A Bluetooth device in security mode 2 should classify the security requirements of its
services using at least the following attributes:

• Authorization required
• Authentication required
• Encryption required

Note: Security mode 1 can be considered (at least from a remote device point of view)
as a special case of security mode 2 where no service has registered any security
requirements.

5.2.1.3 Security mode 3 (link level enforced security)

When a remote Bluetooth device is in security mode 3 it will initiate security procedures
before it sends LMP_SETUP_COMPLETE.

A Bluetooth device in security mode 3 may reject the Host connection request
(respond with LMP_NOT_ACCEPTED to the LMP_HOST_CONNECTION_REQ) based
on settings in the Host (e.g., only communication with pre-paired devices allowed).

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 3, Part C Page 1341
Generic Access Profile

LMP_NOT_ACCEPTED

Figure 5.3: Security mode 3 with a legacy remote device

5.2.2 Security mode 4 (service level enforced security)

A Bluetooth device in security mode 4 shall classify the security requirements of its
services using at least the following attributes (in order of decreasing security):

• Authenticated link key required

• Unauthenticated link key required
• Security optional; limited to specific services (see Section 5.2.2.8).

When both devices support Secure Simple Pairing, GAP shall require at least an
unauthenticated link key and enabling encryption for all connections except those
allowed to have security level 0 (see Section 5.2.2.8). A profile or protocol may
define services that require more security (e.g., an authenticated link key) or no
security (although unencrypted connections are only allowed when connecting to a
service allowed to have security level 0). To allow an unauthenticated link key to be
created during the Secure Simple Pairing procedure, the Authentication_Requirements
parameter may be set to one of the MITM Protection Not Required options.

When the device is in Bondable Mode, it shall enable Secure Simple Pairing mode prior
to entering Connectable Mode or establishing a link.

A Bluetooth device in security mode 4 shall respond to authentication requests during

link establishment when the remote device is in security mode 3 for backwards
compatibility reasons.

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 3, Part C Page 1342
Generic Access Profile

A Bluetooth device in security mode 4 enforces its security requirements before it

attempts to access services offered by a remote device and before it grants access to
services it offers to remote devices. Service access may occur via L2CAP channels or
via channels established by protocols above L2CAP such as RFCOMM.

For services transmitting unicast data over the connectionless L2CAP channel, the
transmitting device shall enforce its security requirements prior to sending data. There
is no mechanism for a device receiving data via the L2CAP connectionless channel
to prevent unencrypted data from being received. Hence, Section 5.2.2.1 addresses
unicast connectionless data transmission together with devices initiating connection-
oriented channels while Section 5.2.2.2 covers only devices responding to requests for
connection-oriented channel establishment but does not cover unicast connectionless
data reception.

A device may be in a Secure Connections Only mode. When in Secure Connections

Only mode, all services (except those allowed to have Security Mode 4, Level 0)
available on the BR/EDR physical transport require Security Mode 4, Level 4. The
device shall reject both new outgoing and incoming service level connections when the
service requires Security Mode 4, Level 4 and either the physical transport does not
support Secure Connections or unauthenticated pairing is being requested.

A device operating with a physical transport operating in Secure Connections Only

mode may disconnect the ACL connection using error code 0x05 (Authentication
Failure) when the physical transport that does not support Secure Connections, tries
to access a service that requires Security Mode 4, Level 4.

Note: A device may operate several physical transports simultaneously - in this

case all physical transports are required to enable Secure Connections Only Mode
simultaneously.

5.2.2.1 Security for access to remote service (initiating side)

When the responding device does not support Secure Simple Pairing, it may disconnect
the link while the initiating device is requesting the PIN to be entered by the user.
This may occur due to the lack of an L2CAP channel being present for longer than an
implementation-specific amount of time (e.g., a few seconds). When this occurs, the
initiating device shall allow the user to complete entering the PIN and shall then re-page
the remote device and restart the pairing procedure (see [Vol 2] Part C, Section 4.2.2)
using the PIN entered.

5.2.2.1.1 Pairing required for access to remote service

When a Bluetooth device in security mode 4 initiates access to a remote service via
a connection-oriented L2CAP channel, the service requires security, and a sufficient
link-key is not available, the local device shall perform pairing procedures and enable

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 3, Part C Page 1343
Generic Access Profile

encryption before sending a channel establishment request (an L2CAP connection

request or a higher-layer channel establishment request such as that of RFCOMM).

When a Bluetooth device in security mode 4 transmits data to a remote service via
the unicast connectionless L2CAP channel and a sufficient link-key is not available, the
local device shall perform pairing procedures and enable encryption before transmitting
unicast data on the connectionless L2CAP channel.

See Section 5.2.2.8 for details on determining whether or not a link key is sufficient.

If pairing does not succeed, the local device shall not send a channel establishment
request. The local device may re-try pairing up to three (3) times. If pairing fails three
consecutive times, the local device shall disconnect the ACL link with error code 0x05 -
Authentication Failure.

If the link key generated is not at least as good as the expected or required type, the
local device shall fail the establishment and may disconnect the ACL link with error code
0x05 - Authentication Failure.

5.2.2.1.2 Authentication required for access to remote service

When a Bluetooth device in security mode 4 initiates access to a remote service via a
connection-oriented L2CAP channel and a sufficient link key is available for the remote
device, it shall authenticate the remote device and enable encryption before sending a
channel establishment request (an L2CAP connection request or a higher layer-channel
establishment request such as that of RFCOMM).

When a Bluetooth device in security mode 4 transmits unicast data to a remote service
via the connectionless L2CAP channel and security is required for the application and a
sufficient link-key is available then the local device shall authenticate the remote device
and enable encryption before transmitting unicast data on the L2CAP connectionless
channel.

See Section 5.2.2.8 for details on determining whether or not a link key is sufficient.

If authentication is required by the service but does not succeed, or if a sufficient

link-key is not available, then the local device shall not enable encryption. If encryption
is not enabled or if enabling encryption does not result in the correct encryption type
(i.e. AES-CCM or E0), the local device shall not send a channel establishment request
and shall not send any unicast data via the L2CAP connectionless channel for that
application. The Host may then notify the user and offer to perform pairing.

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 3, Part C Page 1344
Generic Access Profile

Channel
Establistment or
Connection
Establistment or
preparation for
connectionless
data TX

Yes, security not required (Level 0)

Yes

Secure Simple
Pairing or Legacy
Pairing

Abort

L2CAP
L2CAP connection
CONNECTION
- request
REQ
or application-specific
request or
connectionless data TX

Figure 5.4: Channel establishment using security mode 4 for initiating side

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 3, Part C Page 1345
Generic Access Profile

5.2.2.1.3 Cross-transport key generation and distribution

After encryption is enabled and both devices support cross-transport key generation,
the Central of the BR/EDR transport may perform LE key generation and distribution
([Vol 3] Part H, Section 2.3.5.7). The Peripheral shall not perform LE key generation and
distribution.

If a role switch gets performed after enabling encryption but before the LE keys can
be generated and distributed, the new Central may perform LE key generation and
distribution once the role switch has completed. The new Peripheral shall not perform
LE key generation and distribution once the role switch has completed.

5.2.2.2 Security for access to local service by remote device (responding side)

When a remote device attempts to access a service offered by a Bluetooth device that
is in security mode 4 and the service requires security, a sufficient link key exists, and
authentication has not been performed, the local device shall authenticate the remote
device and enable encryption after the channel establishment request is received but
before a channel establishment confirmation (L2CAP connection response with result
code of 0x0000 or a higher-level channel establishment confirmation such as that of
RFCOMM) is sent.

When L2CAP is the channel establishment protocol being used for the requested
service, an L2CAP connection response signaling packet shall be sent by the
responding device containing a pending result code following receipt of an L2CAP
connection request and prior to initiating security procedures which can result in
prompting the local user for input (e.g., pairing using a PIN or Secure Simple Pairing
using either the Passkey entry or Numerical Comparison association models). This will
stop the L2CAP RTX timer on the remote device (which may be as short as 1 second)
and will invoke the ERTX timer on the remote device, which is a minimum duration of 60
seconds.

See [Vol 3] Part A, Section 6.2 for additional information on L2CAP RTX and ERTX
timers. See also [Vol 3] Part A, Section 4.3 and [Vol 3] Part A, Section 4.26 for
additional information on the L2CAP connection response signaling packets and the
defined result codes.

Higher layer channel establishment protocols should be designed to restrict timeouts to

be 30 seconds or longer to allow for user input, or provide mechanisms to dynamically
extend timeouts when user input may be required.

If authentication or pairing fails when a remote device is attempting to access

a local service, the local device shall send a negative response to the channel
establishment request (L2CAP connection request or application-specific channel
establishment request) indicating a security issue if possible. If the channel

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 3, Part C Page 1346
Generic Access Profile

establishment protocol is L2CAP, then the result code in the L2CAP connection
response shall be set to indicate that the connection was refused due to
security reasons. If an L2CAP_CONNECTION_RSP is being sent, then the
result code shall be set to 0x0003 (connection refused - security block). If an
L2CAP_CREDIT_BASED_CONNECTION_RSP is being sent, then the result code
shall be set to 0x0005 (All connections refused - insufficient authentication), 0x0006
(All connections refused - insufficient authorization), 0x0007 (All connections refused
- encryption key size too short), or 0x0008 (All connections refused - insufficient
encryption).

If the remote device has indicated support for Secure Simple Pairing, a channel
establishment request is received for a service other than SDP, and encryption has
not yet been enabled, then the local device shall disconnect the ACL link with error code
0x05 - Authentication Failure.

5.2.2.2.1 Pairing required for access to local service by remote device

When a remote device attempts to access a service offered by a Bluetooth device

that is in security mode 4 and pairing is required due to the link key being absent or
insufficient, the local device shall perform pairing procedures and enable encryption
after the channel establishment request is received and before a channel establishment
confirmation (L2CAP connection response with result code of 0x0000 or a higher-level
channel establishment response such as that of RFCOMM) is sent.

See Section 5.2.2.6 for details on determining whether or not a link key is sufficient.

If pairing does not succeed, then the local device shall not send a channel
establishment confirmation. The local device may retry pairing up to three (3) times.
If pairing fails three consecutive times, then the local device shall disconnect the ACL
link with error code 0x05 - Authentication Failure.

If the link-key generated is not at least as good as the expected or required type or if
enabling encryption does not result in the correct encryption type (i.e. AES-CCM or E0),
then the local device shall fail the channel establishment and may disconnect the ACL
link with error code 0x05 - Authentication Failure.

5.2.2.2.2 Authentication required for access to local service by remote device

See Section 5.2.2.6 for details on determining whether or not a link key is sufficient.

If authentication does not succeed, then the local device shall not send a channel
establishment confirmation. The Host may at this point notify the user and offer to
perform pairing.

A Bluetooth device in security mode 4 shall respond to authentication and pairing

requests during link establishment when the remote device is in security mode 3 for

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 3, Part C Page 1347
Generic Access Profile

backwards compatibility reasons. However, authentication of the remote device shall be

performed after the receipt of the channel establishment request is received, and before
the channel establishment response is sent.

L2CAP connection
request
or application-specific
request

Que ry security
DB

Rejecte d Yes, security not require d ( Level 0 )

Access?

Yes, security req uired (Levels, 1, 2, 3 and 4)

Link Key G ood Yes

Eno ugh?

No No Yes
Encryption
Ena bled?

Yes Remote de vice No

suppor ts S SP?
Secure Simple
Pairing or Legacy Au th enticati on
Pairing

No
Success?

No Success and Yes

correct link ke y
type ?
Yes
En cr yp tio n

No

No Encryption
key size lo ng
eno ugh?

Cross-transport
Yes No
Key gener atio n
and distribution
possible?

Yes
LE key ge neration
and distribution
([vo l 3] Part H,
Section 2.3.5.7)
L2CAP connection
L2CAP connection
response (failure) or
response (success) or
application-specific
application-specific
failure report
accept message

Figure 5.5: Channel establishment using security mode 4 for the responding side

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 3, Part C Page 1348
Generic Access Profile

5.2.2.2.3 Cross-transport key generation and distribution

After encryption is enabled and both devices support cross-transport key generation,
the Central of the BR/EDR transport may perform LE key generation and distribution
([Vol 3] Part H, Section 2.3.5.7). The Peripheral shall not perform LE key generation and
distribution.

If a role switch gets performed after enabling encryption but before the LE keys can
be generated and distributed, the new Central may perform LE key generation and
distribution once the role switch has completed. The new Peripheral shall not perform
LE key generation and distribution once the role switch has completed.

5.2.2.3 Secure Simple Pairing after authentication failure

When both devices support Secure Simple Pairing all non-SDP connections are
encrypted regardless of whether security was required or whether the devices are
bonded or not. The initial connection between the two devices will result in a link key
through Secure Simple Pairing. Depending on whether or not bonding was performed
and the security policy of the initiating device, the link key may be stored. When the link
key is stored, subsequent connections to the same device will use authentication but
this may fail if the remote device has deleted the link key. Table 5.2 defines what shall
be done depending on the type of the link key and whether bonding was performed or
not.

Link Key Type Devices Bonded? Action to take when Authentication Fails
Combination No Depends on security policy of the device:
• Option 1: Automatically initiate pairing
• Option 2: Notify user and ask if pairing is ok

Option 2 is recommended.
Combination Yes Notify user of security failure
Unauthenticated No Depends on security policy of the device:
• Option 1: Automatically initiate secure simple pairing
• Option 2: Notify user and ask if secure simple pairing is ok.

Option 1 is recommended.
Unauthenticated Yes Notify user of security failure

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 3, Part C Page 1349
Generic Access Profile

Link Key Type Devices Bonded? Action to take when Authentication Fails
Authenticated No Depends on security policy of the device:
• Option 1: Automatically initiate secure simple pairing
• Option 2: Notify user and ask if secure simple pairing is ok

Option 2 is recommended.
Authenticated Yes Notify user of security failure

Table 5.2: Secure Simple Pairing after authentication failure

Non-bonded authenticated or unauthenticated link keys may be considered disposable

by either device and may be deleted at any time.

5.2.2.4 IO capabilities

Once a connection is established, if the Host determines that security is necessary

and both devices support Secure Simple Pairing, the devices perform an IO capability
exchange. The purpose of the IO capability exchange is to determine the authentication
algorithm used in the Authentication stage 1 phase of Secure Simple Pairing.

The input and output capabilities are described in Table 5.3:

Capability Description
No input Device does not have the ability to indicate 'yes' or 'no'
Yes / No Device has at least two buttons that are mapped easily to 'yes' and 'no' or the
device has a mechanism whereby the user can indicate either 'yes' or 'no' (see
note below).
Keyboard Device has a numeric keyboard that can input the numbers '0' to '9' and a confir-
mation. Device also has two buttons that can be easily mapped to 'yes' and 'no'
or the device has a mechanism whereby the user can indicate either 'yes' or 'no'
(see Note below).

Table 5.3: User input capabilities

Note: 'yes' could be indicated by pressing a button within a certain time limit otherwise
'no' would be assumed.

Capability Description
No output Device does not have the ability to display or communicate a 6 digit decimal
number
Numeric output Device has the ability to display or communicate a 6 digit decimal number

Table 5.4: User output capabilities

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 3, Part C Page 1350
Generic Access Profile

5.2.2.5 Mapping of input / output capabilities to IO capability

The individual input and output capabilities are mapped to a single IO capability which is
later used to determine which authentication algorithm will be used.

Local Output Capability

No Output Numeric Output
Local Input

No input NoInputNoOutput DisplayOnly

Capability

Yes / No NoInputNoOutput DisplayYesNo

Keyboard KeyboardOnly DisplayYesNo

Table 5.5: IO capability mapping

When a device has OOB authentication information from the remote device, it will
indicate it in the LMP_IO_CAPABILITY_RES PDU. When either device has OOB
information, the OOB association model will be used.

The Host may allow the Link Manager to ignore the IO capabilities and use the Numeric
Comparison protocol with automatic accept by setting the Authentication_Requirements
parameter to one of the MITM Protection Not Required options.

5.2.2.6 IO and OOB capability mapping to authentication stage 1 method

Determining which association model to use in Authentication stage 1 is performed in

three steps. First, the devices look at the OOB Authentication Data Present parameter
received in the remote IO capabilities. If either device has received OOB authentication
data then the OOB association model is used. The event of receiving the OOB
information is indicated by a device to its peer in the IO Capability Exchange step of
Secure Simple Pairing.

Device A
Has not received remote Has received remote OOB
OOB authentication data authentication data
Has not received remote Use the IO capability map- Use OOB association with
OOB authentication data ping table ra = 0
Device B

rb from OOB
Has received remote OOB Use OOB association with Use OOB association with
authentication data ra from OOB ra from OOB
rb = 0 rb from OOB

Table 5.6: IO and OOB capability mapping

Second, if neither device has received OOB authentication data and if both devices
have set the Authentication_Requirements parameter to one of the MITM Protection Not

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 3, Part C Page 1351
Generic Access Profile

Required options, authentication stage 1 shall function as if both devices set their IO
capabilities to DisplayOnly (e.g., Numeric comparison with automatic confirmation on
both devices).

Finally, if neither device has received OOB authentication data and if one or
both devices have set the Authentication_Requirements parameter to one of the
MITM Protection Required options, the IO and OOB capabilities are mapped to
the authentication stage 1 method as defined in Table 5.7. A Host that has set
the Authentication_Requirements parameter to one of the MITM Protection Required
options shall verify that the resulting Link Key is an Authenticated Combination Key (see
[Vol 4] Part E, Section 7.7.24). Table 5.7 also lists whether the combination key results
in an authenticated or unauthenticated link key.

Device A (Initiator)
Display Only DisplayYesNo KeyboardOnly NoInputNoOutput
DisplayOnly Numeric Com- Numeric Com- Passkey Entry: Numeric Compari-
parison with parison with Responder Dis- son with automatic
automatic con- automatic con- play, Initiator In- confirmation on both
firmation on firmation on put. devices.
both devices. device B only.
Unauthentica- Unauthentica- Authenticated Unauthenticated
ted ted
DisplayYesNo Numeric Com- Numeric Com- Passkey Entry: Numeric Compari-
Device B (Responder)

parison with parison: Both Responder Dis- son with automatic

automatic con- Display, Both play, Initiator In- confirmation on de-
firmation on Confirm. put. vice A only and
device A only. Yes/No confirmation
whether to pair on
device B. Device B
does not show the
confirmation value.
Unauthentica- Authenticated Authenticated Unauthenticated
ted
Keyboard Only Passkey Entry: Passkey Entry: Passkey Entry: In- Numeric Compari-
Initiator Dis- Initiator Dis- itiator and Res- son with automatic
play, Respond- play, Respond- ponder Input. confirmation on both
er Input. er Input. devices.
Authenticated Authenticated Authenticated Unauthenticated

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 3, Part C Page 1352
Generic Access Profile

Device A (Initiator)
Display Only DisplayYesNo KeyboardOnly NoInputNoOutput
NoInputNoOut- Numeric Com- Numeric Com- Numeric Compari- Numeric
put parison with parison with son with automat- Comparison
automatic con- automatic con- ic confirmation on
firmation on firmation on both devices. with automatic con-
both devices. device B only firmation on both
and Yes/No devices.
confirmation
on whether to
pair on device
A. Device A
does not show
the confirma-
tion value.
Unauthentica- Unauthentica- Unauthenticated Unauthenticated
ted ted
Table 5.7: IO capability mapping to authentication stage 1

Note: The "DisplayOnly" IO capability only provides unidirectional authentication.

5.2.2.7 Out of Band (OOB)

An out of band mechanism may also be used to communicate discovery information as

well as other information related to the pairing process.

The contents of the OOB data block are:

Mandatory contents:

• Length (2 bytes)
• BD_ADDR (6 bytes)

Optional contents:

• Class of Device (3 bytes)

• Secure Simple Pairing Hash C (16 bytes)
• Secure Simple Pairing Randomizer R (16 bytes)
• Local name (variable length)
• Other information

The length field includes all bytes in the OOB data block including the length field itself.
The BD_ADDR will be a fixed field in the beginning of the OOB data block. Following
the BD_ADDR will be zero or more EIR tag fields containing optional contents. The EIR
tag format will be used for the optional contents. See Figure 5.6.

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 3, Part C Page 1353
Generic Access Profile

OOB Data Block

Mandatory Part Optional parts

EIR Data EIR Data EIR Data

LENGTH BD_ADDR ...
Structure 1 Structure 2 Structure N

1 octet Length octets

Length Data

n octets Length - n octets

EIR Data Type EIR Data

Figure 5.6: OOB data block format

If Secure Simple Pairing fails when one or both devices have OOB Authentication Data
present, both devices shall discard the OOB Authentication Data and the device that
originally initiated authentication shall re-initiate authentication. Although the user may
get involved in authentication as defined by the IO capabilities of the two devices, falling
back to the in-band association model will prevent deadlock conditions when one or
both devices has stale OOB Authentication Data.

There is a MIME type defined for use with the OOB data format. The MIME type can be
found from the following link: http://www.iana.org/assignments/media-types/application/
vnd.bluetooth.ep.oob

5.2.2.8 Security database

A Bluetooth device in security mode 4 shall classify and enforce the security
requirements of its services using the following levels attributes (in order of decreasing
security) for use when pairing with remote devices supporting Secure Simple Pairing:

• Level 4, for services with the following attributes:

Authentication of the remote device required
MITM protection required
128-bit equivalent strength for link and encryption keys required using FIPS approved
algorithms (E0 not allowed, SAFER+ not allowed, and P-192 not allowed; encryption
key not shortened)
User interaction acceptable

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 3, Part C Page 1354
Generic Access Profile

• Level 3, for services with the following attributes:

Authentication of the remote device required
MITM protection required
Encryption required
At least 56-bit equivalent strength for encryption key should be used
User interaction acceptable
• Level 2, for services with the following attributes:
Authentication of the remote device required
MITM protection not required
Encryption required
At least 56-bit equivalent strength for encryption key should be used
• Level 1, for services with the following attributes:
Authentication of the remote device required when encryption is enabled
MITM protection not required
At least 56-bit equivalent strength for encryption key when encryption is enabled
should be used
Minimal user interaction desired
• Level 0: Service requires the following:
Authentication of the remote device not required
MITM protection not required
No encryption required
No user interaction required
Security Mode 4 Level 0 shall only be used for:
a. L2CAP fixed signaling channels with CIDs 0x0001, 0x0003, and 0x003F
b. SDP
c. broadcast data sent on the connectionless L2CAP channel (CID 0x0002)
d. services with the combinations of Service Class UUIDs and L2CAP traffic types
listed in Section 1 of [5].

The security level required for each service offered should be stored in a security
database that is accessed to determine the type of link key and the encryption key
size that is required for access to the respective service. The security level required
for service data transmitted on an L2CAP connection-oriented channel may differ from

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 3, Part C Page 1355
Generic Access Profile

the security level required for service data transmitted on another L2CAP connection-
oriented channel or on the connectionless L2CAP channel. Table 5.8 shows the type
of link key required for each security level for both remote devices that support Secure
Simple Pairing and for those that do not.

Security Level Required for Service Link Key type Link Key Comments
required for type
remote required for
devices that remote
support SSP devices that
do not
support SSP
Level 4 Authenticated NA Highest Security
• Authentication of the remote device (P-256 based Only possible when both
required Secure Simple devices support Secure
Pairing and Se- Connections
• MITM protection required
cure Authenti-
• Encryption required cation)
• User interaction acceptable
Level 3 Authenticated Combination High Security
• Authentication of the remote device (16 digit PIN
required recommen-
ded)
• MITM protection required
• Encryption required
• User interaction acceptable
Level 2 Unauthentica- Combination Medium Security
ted
• Authentication of the remote device
required
• MITM protection not necessary
• Encryption desired
Level 1 Unauthentica- None Low Security
ted
• Authentication of the remote device
required when encryption is enabled
• MITM protection not necessary
• Encryption not necessary1
• Minimal user interaction desired

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 3, Part C Page 1356
Generic Access Profile

Security Level Required for Service Link Key type Link Key Comments
required for type
remote required for
devices that remote
support SSP devices that
do not
support SSP
Level 0 None None Permitted only for SDP
and service data sent via
• Authentication of the remote device
either L2CAP fixed sig-
not required
naling channels or the
• MITM protection not necessary L2CAP connectionless
channel to PSMs that
• Encryption not necessary
correspond to service
• No user interaction desired class UUIDs which are
allowed to utilize Level 0.

Table 5.8: Security level mapping to link key requirements

1Though encryption is not necessary for the service for Level 1, the specification mandates the use of
encryption for all services other than SDP when the remote device supports SSP.

An authenticated link key is a link key where either the numeric comparison, out-
of-band, or passkey entry Secure Simple Pairing association models were used.
An authenticated link key has protection against MITM attacks. To ensure that an
authenticated link key is created during the Secure Simple Pairing procedure, the
Authentication_Requirements parameter should be set to one of the MITM Protection
Required options.

An unauthenticated link key is a link key where the “Just Works” Secure Simple
Pairing association model was used (see [Vol 1] Part A, Section 5.2.4). An
unauthenticated link key does not have protection against MITM attacks. To allow an
unauthenticated link key to be created during the Secure Simple Pairing procedure, the
Authentication_Requirements parameter may be set to one of the MITM Protection Not
Required options.

When both devices support Secure Simple Pairing and at least one device does not
support Secure Connections, the strength of the link key is 96 effective bits. When both
devices support Secure Connections, the strength of the link key is 128 effective bits.
Secure Connections does not change the protection against MITM attacks.

A combination link key is a link key where BR/EDR Legacy Pairing was used to
generate the link-key (see [Vol 2] Part C, Section 4.2.2.4).

When both devices support Secure Simple Pairing, GAP shall require at least an
unauthenticated link key and enable encryption for service traffic sent or received via
connection-oriented L2CAP channels. A profile or protocol may define services that
require more security (for example, an authenticated link key) or no security in the case

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 3, Part C Page 1357
Generic Access Profile

of SDP or service traffic sent via the L2CAP connectionless channel for services that do
not require security.

When the device is in Bondable Mode, it shall enable Secure Simple Pairing mode prior
to entering Connectable Mode or establishing a link.

A Bluetooth device in security mode 4 shall respond to authentication and pairing

requests during link establishment when the remote device is in security mode 3 for
backwards compatibility reasons. See Section 5.2.1.3 for more information.

The remote Controller's and remote Host's support for Secure Simple Pairing shall be
determined by the Link Manager Secure Simple Pairing (Host Support) feature bit.

A previously generated link key is considered “sufficient” if the link key type is of
the type required for the service, or of a higher strength. Authenticated link keys are
considered higher strength than Unauthenticated or Combination keys. Unauthenticated
link keys are considered higher strength than Combination keys.

A device shall enforce an encryption key with at least 128-bit equivalent strength for
all services that require Security Mode 4, Level 4. For all other services that require
encryption, a device should enforce an encryption key with at least 56-bit equivalent
strength, irrespective of whether the remote device supports Secure Simple Pairing.

After encryption has been enabled, the Host should check the encryption key size using
either the HCI_Read_Encryption_Key_Size command (see [Vol 4] Part E, Section 7.5.7)
or a vendor-specific method.

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 3, Part C Page 1358
Generic Access Profile

6 IDLE MODE PROCEDURES – BR/EDR PHYSICAL

TRANSPORT

The requirements for devices initiating the inquiry and discovery procedures (device A)
are specified in Table 6.1. The requirements on the behavior of the responding device
(device B) are specified in Table 4.1.

Procedure Ref. Support

General inquiry 6.1 C.1
Limited inquiry 6.2 C.1
Name discovery 6.3 O
Device discovery 6.4 O
Bonding 6.5 O
C.1: If initiation of bonding is supported, support for at least one inquiry procedure is mandatory,
otherwise optional.

Note: Support for LMP-pairing is mandatory (see [Vol 2] Part C, Section 4.2.2).

Table 6.1: Requirements for initiating inquiry and discovery procedures

6.1 General Inquiry

6.1.1 Purpose

The purpose of the general inquiry procedure is to provide the initiator with the
Bluetooth Device Address, clock, Class of Device, and extended inquiry response
information of devices in either general discoverable mode or limited discoverable
mode.

The general inquiry procedure should be used for general purpose discovery, i.e. to
discover all discoverable devices regardless of whether they are in general discoverable
mode or limited discoverable mode. A device which discovers devices using the general
inquiry procedure and presents them to users in some fashion should distinguish
devices in the limited discoverable mode from those in the general discoverable mode,
e.g., by sorting them to the top of a list of discovered devices or highlighting them in
some way.

Note: The rationale for distinguishing the devices in limited discoverable mode to the
end user is that devices typically enter limited discoverable mode only after explicit
action by the end user, indicating that the user’s immediate goal is to discover and
interact with that specific device.

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 3, Part C Page 1359
Generic Access Profile

6.1.2 Term on UI level

‘Bluetooth Device Inquiry’.

6.1.3 Description

Figure 6.1 specifies the procedure.

A B B’ B”

Inquiry (GIAC)

inquiry_res

inquiry_res

list of
Bluetooth
Device
Addresses

Figure 6.1: General inquiry, where B is a device in non-discoverable mode, B´ is a device in limited
discoverable mode and B” is a device in general discoverable mode. (Note: All discoverable devices are
discovered using general inquiry, independent of which discoverable mode they are in.)

6.1.4 Conditions

When general inquiry is initiated by a Bluetooth device, the INQUIRY state shall last
TGAP(100) or longer, unless the inquirer collects enough responses and determines to
abort the INQUIRY state earlier. The Bluetooth device shall perform inquiry using the
GIAC.

In order for Device A to receive inquiry responses, the remote devices in range have to
be made discoverable (limited or general).

6.2 Limited Inquiry

6.2.1 Purpose

The purpose of the limited inquiry procedure is to provide the initiator with the Bluetooth
Device Address, clock, Class of Device, and extended inquiry response information
of limited discoverable devices. The latter devices are devices that are in range with
regard to the initiator, and set to scan for inquiry messages with the Limited Inquiry
Access Code.

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 3, Part C Page 1360
Generic Access Profile

The limited inquiry procedure should only be used when it is known that the devices to
be discovered are using limited discoverable mode. The general inquiry procedure (see
Section 6.1) should be used for general purpose discovery when it is desired to discover
all devices regardless of whether they are using limited discoverable mode or general
discoverable mode.

6.2.2 Term on UI level

’Bluetooth Device Inquiry’.

6.2.3 Description

Figure 6.2 specifies the procedure.

A B B’ B”

Inquiry (LIAC)

inquiry_res

list of
Bluetooth
Device
Addresses

Figure 6.2: Limited inquiry where B is a device in non-discoverable mode, B’ is a device in limited
discoverable mode and B” is a device in general discoverable mode. (Note: Only limited discoverable
devices can be discovered using limited inquiry.)

6.2.4 Conditions

When limited inquiry is initiated by a Bluetooth device, the INQUIRY state shall last
TGAP(100) or longer, unless the inquirer collects enough responses and determines to
abort the INQUIRY state earlier. The Bluetooth device shall perform inquiry using the
LIAC.

In order for Device A to receive inquiry responses, the remote devices in range has to
be made limited discoverable.

6.3 Name Discovery

6.3.1 Purpose

The purpose of name discovery is to provide the initiator with the Bluetooth Device
Name of connectable devices (i.e., devices in range that will respond to paging).

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 3, Part C Page 1361
Generic Access Profile

6.3.2 Term on UI level

’Bluetooth Device Name Discovery’

6.3.3 Description

6.3.3.1 Name Request

Name request is the procedure for retrieving the Bluetooth Device Name from a
connectable Bluetooth device. It is not necessary to perform the full link establishment
procedure (see Section 7.1) in order to just to get the name of another device.
Figure 6.3 specifies the procedure.

A B

Paging

LMP_NAME_REQ

LMP_NAME_RES

LMP_DETACH

Figure 6.3: Name Request procedure

6.3.3.2 Name Discovery

Name discovery is the procedure for retrieving the Bluetooth Device Name from
connectable Bluetooth devices by performing name request towards known devices
(i.e., Bluetooth devices for which the Bluetooth Device Addresses are available).
Figure 6.4 specifies the procedure.

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 3, Part C Page 1362
Generic Access Profile

A B B’ B”

list of
Bluetooth
Device
Addresses

Name request

Name request

Name request

list of
Bluetooth
Device
Names

Figure 6.4: Name discovery procedure

6.3.4 Conditions

In the name request procedure, the initiator will use the Device Access Code of the
remote device as retrieved immediately beforehand – normally through an inquiry
procedure.

6.4 Device Discovery

This section only applies to BR/EDR-only and BR/EDR/LE implementations.

6.4.1 Purpose

The purpose of device discovery is to provide the initiator with the Bluetooth Device
Address, clock, Class of Device, Bluetooth Device Name, and extended inquiry
response information of discoverable devices.

6.4.2 Term on UI level

’Bluetooth Device Discovery’

6.4.3 Description

During the Device Discovery procedure, first an inquiry (either general or limited) is
performed, and then name discovery is done towards some or all of the devices that

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 3, Part C Page 1363
Generic Access Profile

responded to the inquiry. If the initiator of the device discovery receives a complete
local name or a shortened local name that is considered long enough, via an extended
inquiry response from a remote device, the initiator should not do a separate name
discovery for that device.

A B B’ B”

initiate device make discoverable & connectable

discovery

Inquiry

list of discovered
Bluetooth devices
(Bluetooth Device
Addresses and
Extended Inquiry
Response information)

Name discovery

list of discovered
Bluetooth devices
(Bluetooth
Device Names)

Figure 6.5: Device Discovery procedure

6.4.4 Conditions

Conditions for both inquiry (general or limited) and name discovery must be fulfilled
(i.e., devices discovered during device discovery must be both discoverable and
connectable).

6.5 Bonding
6.5.1 Purpose

The purpose of bonding is to create a relation between two Bluetooth devices based
on a common link key (a bond). The link key is created and exchanged (pairing) during
the bonding procedure and is expected to be stored by both Bluetooth devices, to be
used for future authentication. In addition to pairing, the bonding procedure can involve
higher-layer initialization procedures.

6.5.2 Term on UI level

’Bluetooth Bonding’

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 3, Part C Page 1364
Generic Access Profile

6.5.3 Description

Two forms of bonding are described in the following sections: General Bonding and
Dedicated Bonding.
6.5.3.1 General Bonding

General Bonding refers to the process of performing bonding during connection setup
or channel establishment procedures as a precursor to accessing a service. Figure 6.6
specifies General Bonding.

When the devices that are performing General Bonding both support Secure Simple
Pairing, the Authentication_Requirements parameter should be set to MITM Protection
Not Required – General Bonding unless the security policy of an available local service
requires MITM Protection in which case the Authentication_Requirements parameter
shall be set to MITM Protection Required – General Bonding. 'No bonding' is used when
the device is performing a Secure Simple Pairing procedure, but does not intend to
retain the link key after the physical link is disconnected.

A B

Initiate bonding Make bondable

(BD_ADDR)

Delete
link key
to paged
device

LMP_HOST_CONNECTION_REQ

LMP_ACCEPTED

LMP_SETUP_COMPLETE

LMP_SETUP_COMPLETE

Pairing

Update list of paired devices Update list of paired devices

Figure 6.6: General Bonding procedure

6.5.3.2 Dedicated Bonding

Dedicated Bonding refers to a procedure wherein one device connects to another only
for the purpose of pairing without accessing a particular service. Figure 6.7 specifies

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 3, Part C Page 1365
Generic Access Profile

Dedicated Bonding. The main difference with dedicated bonding, as compared to a

pairing done during link or channel establishment, is that for bonding it is the paging
device (A) that initiates the authentication.

When the devices that are performing Dedicated Bonding both support Secure Simple
Pairing, the Authentication_Requirements parameter should be set to MITM Protection
Not Required – Dedicated Bonding unless the security policy of an available local
service requires MITM Protection in which case the Authentication Required parameter
shall be set to MITM Protection Required – Dedicated Bonding. 'No bonding' is used
when the device is performing a Secure Simple Pairing procedure, but does not intend
to retain the link key after the physical link is disconnected.

As an exception to the normal process, device B shall also accept pairing before
the exchange of LMP_SETUP_COMPLETE PDUs (this can only happen if device A
conforms to a lower version of the specification).

A B

Initiate bonding Make bondable

(BD_ADDR)

Delete
link key
to paged
device

LMP_HOST_CONNECTION_REQ

LMP_ACCEPTED

Pairing
(only when device
A is 2.0 or below)

LMP_SETUP_COMPLETE

LMP_SETUP_COMPLETE

Pairing
(normal case)

LMP_DETACH

Update list of paired devices Update list of paired devices

Figure 6.7: Dedicated Bonding procedure

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 3, Part C Page 1366
Generic Access Profile

6.5.4 Conditions

Before bonding can be initiated, the initiating device (A) must know the Device
Access Code of the device to pair with. This is normally done by first performing
device discovery. A Bluetooth Device that can initiate bonding (A) should use limited
inquiry, and a Bluetooth Device that accepts bonding (B) should support the limited
discoverable mode.

Bonding is in principle the same as link establishment with the conditions:

• The paged device (B) shall be set into bondable mode. The paging device (A) is
assumed to allow pairing since it has initiated the bonding procedure.
• The paging device (the initiator of the bonding procedure, A) shall initiate
authentication.
• Before initiating the authentication part of the bonding procedure, the paging device
should delete any link key corresponding to a previous bonding with the paged
device.

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 3, Part C Page 1367
Generic Access Profile

7 ESTABLISHMENT PROCEDURES – BR/EDR

PHYSICAL TRANSPORT

Procedure Ref. Support in A Support in B

Link Establishment 7.1 M M
Channel Establishment 7.2 O M
Connection Establishment 7.3 O O
Synchronization Establishment 7.5 O O

Table 7.1: Establishment procedures

The establishment procedures defined here do not include any discovery part. Before
establishment procedures are initiated, the information provided during device discovery
(in the FHS packet or the extended inquiry response packet of the inquiry response
or in the response to a name request or in the synchronization train packet) must be
available in the initiating device.

This information is:

• The Bluetooth Device Address (BD_ADDR) from which the Device Access Code is
generated
• The system clock of the remote device

Additional information provided during device discovery that may be useful for making
the decision to initiate an establishment procedure is:

• The Class of Device

• The Device name
• The supported Service Classes.

7.1 Link Establishment

7.1.1 Purpose

The purpose of the Link Establishment procedure is to establish a logical transport

(of ACL type) between two Bluetooth devices using procedures from the Baseband
Specification and Link Manager Protocol.

7.1.2 Term on UI level

‘Bluetooth link establishment’

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 3, Part C Page 1368
Generic Access Profile

7.1.3 Description

In this subsection, the paging device (A) is in security mode 3. During link
establishment, the paging device cannot distinguish if the paged device (B) is in security
mode 1, 2 or 4.

7.1.3.1 B in security mode 1, 2, or 4

Figure 7.1 specifies the procedure.

A B

Init make connectable

Paging

Switch negotiation

Link setup

LMP_HOST_CONNECTION_REQ

LMP_ACCEPTED

Authentication

Encryption negotiation

Link setup complete

Figure 7.1: Link Establishment procedure when the paging device (A) is in security mode 3 and the paged
device (B) is in security mode 1, 2, or 4

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 3, Part C Page 1369
Generic Access Profile

7.1.3.2 B in security mode 3

Figure 7.2 specifies the procedure.

A B

Init Make connectable

Paging

Link setup

LMP_HOST_CONNECTION_REQ

Switch negotiation

LMP_ACCEPTED

Authentication

Authentication

Encryption negotiation

Link setup complete

Figure 7.2: Link Establishment procedure when both the paging device (A) and the paged device (B) are
in security mode 3

7.1.4 Conditions

The paging procedure shall be according to [Vol 2] Part B, Section 8.3 and the
paging device should use the Device Access Code and page mode received through a
previous inquiry. When paging is completed, a physical link between the two Bluetooth
devices is established.

If role switching is needed it should be done as early as possible after the physical link
is established. If the paging device does not accept the switch, the paged device has to
consider whether to keep the physical link or not.

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 3, Part C Page 1370
Generic Access Profile

Both devices may perform link setup (using LMP procedures that require no interaction
with the Host on the remote side). Optional LMP features can be used after having
confirmed (using LMP_FEATURES_REQ) that the other device supports the feature.

When the paging device needs to go beyond the link setup phase, it issues a request to
be connected to the Host of the remote device. If the paged device is in security mode
3, this is the trigger for initiating authentication.

The paging device shall send LMP_HOST_CONNECTION_REQ during link

establishment (i.e., before channel establishment) and may initiate authentication only
after having sent LMP_HOST_CONNECTION_REQ.

After an authentication has been performed, any of the devices can initiate encryption.

Further link configuration may take place after the LMP_HOST_CONNECTION_REQ.

When both devices are satisfied, they send LMP_SETUP_COMPLETE.

Link establishment is completed when both devices have sent

LMP_SETUP_COMPLETE.

7.2 Channel Establishment

7.2.1 Purpose

The purpose of the Channel Establishment procedure is to establish a Bluetooth

channel (L2CAP channel) between two Bluetooth devices as described in [Vol 3] Part A,
Section 4.2.

7.2.2 Term on UI level

’Bluetooth channel establishment’

7.2.3 Description

In this subsection, the initiator (A) is in security mode 3. During channel establishment,
the initiator cannot distinguish if the acceptor (B) is in security mode 1 or 3.

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 3, Part C Page 1371
Generic Access Profile

7.2.3.1 B in security mode 2 or 4

Figure 7.3 specifies the procedure.

A B

established link

L2CAP_CONNECTION_REQ

Authentication

Encryption negotiation

L2CAP_CONNECTION_RSP (success)

Figure 7.3: Channel Establishment procedure when the initiator (A) is in security mode 3 and the acceptor
(B) is in security mode 2 or 4

7.2.3.2 B in security mode 1 or 3

Figure 7.4 specifies the procedure.

A B

established link

L2CAP_CONNECTION_REQ

L2CAP_CONNECTION_RSP (success)

Figure 7.4: Channel Establishment procedure when the initiator (A) is in security mode 3 and the acceptor
(B) is in security mode 1 or 3

7.2.4 Conditions

Channel establishment starts after link establishment is completed when the initiator
sends a channel establishment request (L2CAP_CONNECTION_REQ).

Depending on security mode, security procedures may take place after the channel
establishment has been initiated.

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 3, Part C Page 1372
Generic Access Profile

Channel establishment is completed when the acceptor responds to the channel

establishment request (with a positive L2CAP_CONNECTION_RSP).

7.3 Connection Establishment

7.3.1 Purpose

The purpose of the Connection Establishment procedure is to establish a connection

between applications on two Bluetooth devices.

7.3.2 Term on UI level

’Bluetooth connection establishment’

7.3.3 Description

In this subsection, the initiator (A) is in security mode 3. During connection

establishment, the initiator cannot distinguish if the acceptor (B) is in security mode
1 or 3. The connection establishment request and accept messages are defined by the
application protocol.

7.3.3.1 B in security mode 2 or 4

Figure 7.5 specifies the procedure.

A B

established channel

connection establishment request

Authentication

Encryption negotiation

connection establishment accept

Figure 7.5: Connection Establishment procedure when the initiator (A) is in security mode 3 and the
acceptor (B) is in security mode 2 or 4

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 3, Part C Page 1373
Generic Access Profile

7.3.3.2 B in security mode 1 or 3

Figure 7.6 specifies the procedure.

A B

established channel

connection establishment request

connection establishment accept

Figure 7.6: Connection Establishment procedure when the initiator (A) is in security mode 3 and the
acceptor (B) is in security mode 1 or 3

7.3.4 Conditions

Connection establishment starts after channel establishment is completed, when the

initiator sends a connection establishment request. This request may be a TCS SETUP
message [2] in the case of a Bluetooth telephony application Cordless Telephony
Profile, or initialization of RFCOMM and establishment of DLC [1] in the case of a serial
port-based application Serial Port Profile (although neither TCS or RFCOMM use the
term ‘connection’ for this).

Connection establishment is completed when the acceptor accepts the connection

establishment request.

7.4 Establishment of additional connection

When a Bluetooth device has established one connection with another Bluetooth
device, it may be available for establishment of:

• A second connection on the same channel, and/or

• A second channel on the same logical link, and/or
• A second physical link.

If the new establishment procedure is to be towards the same device, the security part
of the establishment depends on the security modes used. If the new establishment
procedure is to be towards a new remote device, the device should behave according
to Active modes independent of the fact that it already has another physical link
established (unless allowed co-incident radio and Baseband events have to be
handled).

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 3, Part C Page 1374
Generic Access Profile

7.5 Synchronization Establishment

7.5.1 Purpose

The purpose of the Synchronization Establishment procedure is for a device to receive

synchronization train packets using the procedures in [Vol 2] Part B, Section 2.7.3

7.5.2 Term on UI Level

’Bluetooth synchronization establishment’

7.5.3 Description

In Figure 7.7 the receiving device (B) is attempting to receive synchronization train
packets from device (A).

A B

Set Connectionless
Peripheral Broadcast

Broadcast

Start Synchronization Train Broadcast

Broadcast

Broadcast

Sync Train

Receive Synchronization Train

Sync Train

Synchronization Train Received

Figure 7.7: Synchronization Establishment procedure

7.5.4 Conditions

After receiving a synchronization train packet, the receiving device can listen to and
receive profile data sent via Connectionless Peripheral Broadcast by device A.

Devices A and B may go through a separate Link Establishment procedure any time
they desire to establish an ACL logical transport between each other. They may also
use Connectionless Peripheral Broadcast procedures with an ACL logical transport
already established.

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 3, Part C Page 1375
Generic Access Profile

The receiving device shall enter the Synchronization Scan substate using a scan
interval of TGAP(Sync_Scan_Interval) and a scan window of TGAP(Sync_Scan_Window).

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 3, Part C Page 1376
Generic Access Profile

8 EXTENDED INQUIRY RESPONSE DATA FORMAT

The extended inquiry response data format is shown in Figure 8.1. The data is 240
octets and consists of a significant part and a non-significant part. The significant part
contains a sequence of data structures. Each data structure shall have a length field of
one octet, which contains the Length value, and a data field of Length octets. The first
n octets of the data field contain the extended inquiry response (EIR) data type. The
content of the remaining Length - n octets in the data field depends on the value of the
EIR data type and is called the EIR data. The non-significant part extends the extended
inquiry response to 240 octets and shall contain all-zero octets.

Extended Inquiry Response (240 octets)

Significant part Non-significant part

EIR Data EIR Data EIR Data

... 000...000
Structure 1 Structure 2 Structure N

1 octet Length octets

Length Data

n octets Length - n octets

EIR Data Type EIR Data

Figure 8.1: Extended inquiry response data format

The extended inquiry response data formats and meanings are defined in Section 1 of
[4].The extended inquiry response data type values are defined in Assigned Numbers.

If the length field is set to zero, then the data field has zero octets. This shall only occur
to allow an early termination of the tagged data.

To reduce interference, the Host should try to minimize the amount of EIR data such
that the Baseband can use a 1-slot or 3-slot EIR packet. This is advantageous because
it reduces interference and maximizes the probability that the EIR packet will be
received. If applications on a Host provide more than 240 bytes of extended inquiry
response data, it is up to the Host to limit it to 240 octets.

The EIR data shall be sent during the inquiry response state. In selecting the packet
type to be used, FEC (DM1 or DM3) should be considered to maximize the range.

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 3, Part C Page 1377
Generic Access Profile

The Host shall include the device name in the EIR data according to the following rules:

1. If the device does not have a device name (i.e., no octets) and
a. If there is no other data to be sent in the EIR packet, the Host shall send a
name tag with zero length and the type field set to indicate that this is the
complete name (i.e., total of 2 octets with length = 1).
b. If there is other important data to be sent in the EIR packet and a zero octet
name tag will not fit, the Host may avoid sending the name tag.
2. If the device has a device name (greater than zero octets) and
a. If it is too long be included in the EIR packet (given the choice of packet type
and any other data that is being sent), the Host may send a shortened version
of the name (even no octets) and shall mark the name as 'shortened' to inform
the receiver that a remote name request is required obtain the full name if the
name is needed.
b. If there are no other data to be sent in the EIR packet (given the choice of
packet type selected), the Host shall maximize the length of the device name
to be sent, this may be complete or shortened name (e.g., if DM1 packet is
chosen and device name characters equates to greater than 15 octets, then
Host sends first few characters that equates to 15 octets or less with shortened
flag).

Note: It is not necessary to understand each and every EIR data type. If the Host does
not understand a given EIR data type value it should just skip over Length octets and
look for the next EIR data structure.

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 3, Part C Page 1378
Generic Access Profile

9 OPERATIONAL MODES AND PROCEDURES – LE

PHYSICAL TRANSPORT

Several different modes and procedures may be performed simultaneously over an LE

physical transport. The following modes and procedures are defined for use over an LE
physical transport:

• Broadcast mode and Observation procedure

• Discovery modes and procedures
• Connection modes and procedures
• Bonding modes and procedures
• Periodic advertising modes and procedure
• Isochronous broadcast modes and procedures
• Channel Sounding procedures

Each of the above modes and procedures are independent from each other but are
closely related since a combination of the modes and procedures are necessary for
most devices to communicate with each other. Both the modes and procedures may be
entered or executed respectively as a result of direct user action or autonomously by a
device.

The Host shall configure the Controller with its local Link Layer feature information as
defined in [Vol 6] Part B, Section 4.6 before performing any of the above modes and
procedures.

The types of advertising used in these modes and procedures for each of the
associated GAP roles are defined in Section 2.2.2 Table 2.1.

9.1 Broadcast mode and Observation procedure

The Broadcast mode and Observation procedure allow two devices to communicate in
a unidirectional connectionless manner using the advertising events. The requirements
for a device operating in a specific GAP role to support the Broadcast mode and
Observation procedure are defined in Table 9.1.

Broadcast Mode and Observation Ref. Peripheral Central Broadcaster Observer

procedure
Broadcast mode 9.1.1 E E M E
Observation procedure 9.1.2 E E E M

Table 9.1: Broadcast mode and observation procedure requirements

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 3, Part C Page 1379
Generic Access Profile

9.1.1 Broadcast mode

9.1.1.1 Definition

The Broadcast mode provides a method for a device to send connectionless data in
advertising events.

9.1.1.2 Conditions

A device in the Broadcast mode shall send data using non-connectable advertising
events.

A device in the Broadcast mode may send non-connectable and non-scannable

undirected or non-connectable and non-scannable directed advertising events
anonymously by excluding the Broadcaster's address.

The advertising data shall be formatted using the Advertising Data (AD) type format
as defined in Section 1.3 of [4]. A device in the Broadcast mode shall not set the ‘LE
General Discoverable Mode’ flag or the ‘LE Limited Discoverable Mode’ flag in the Flags
AD Type as defined in Section 1.3 of [4].

Note: All data sent by a device in the Broadcast mode is considered unreliable since
there is no acknowledgment from any device that may have received the data.

The device may configure and enable multiple independent advertising sets. Each
advertising set may have an independent advertising filter policy.

9.1.2 Observation procedure

9.1.2.1 Definition

The Observation procedure provides a method for a device to receive connectionless

data from a device that is sending advertising events.

9.1.2.2 Conditions

A device performing the Observation procedure may use passive scanning or active
scanning to receive advertising events.

A device performing the Observation procedure may use active scanning to also receive
scan response data sent by any device in the Broadcast mode that advertises using
scannable advertising events.

When a device performing the Observation procedure receives a resolvable private

address in the advertising event, the device may resolve the private address by using
the resolvable private address resolution procedure as defined in Section 10.8.2.3.

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 3, Part C Page 1380
Generic Access Profile

Note: In use cases where a device in the Broadcast mode sends dynamic data, the
receiving device should disable duplicate filtering capability in the Controller so that the
Host receives all advertising packets received by the Controller.

9.2 Discovery modes and procedures

All devices shall be in either non-discoverable mode or one of the discoverable

modes. A device in the discoverable mode shall be in either the general discoverable
mode or the limited discoverable mode. A device in the non-discoverable mode is
not discoverable. Devices operating in either the general discoverable mode or the
limited discoverable mode can be found by the discovering device. A device that is
discovering other devices performs either the limited discovery procedure as defined in
Section 9.2.5 or the general discovery procedure as defined in Section 9.2.6.

Some devices may only scan for advertising events using legacy advertising PDUs.
It is therefore recommended that devices using advertising events with the extended
advertising PDUs also use an advertising set with advertising events that use legacy
advertising PDUs.

If the device is in one of the discoverable modes, and if multiple advertising sets are
used with the same Identity Address or the same IRK, then those advertising sets shall
also share the same advertising filter policy.

9.2.1 Requirements

Discovery modes and procedures Ref. Peripheral Central Broadcaster Observer

Non-Discoverable mode 9.2.2 M E E E
Limited Discoverable mode 9.2.3 O E E E
General Discoverable mode 9.2.4 C.1 E E E
Limited Discovery procedure 9.2.5 E O E E
General Discovery procedure 9.2.6 E M E E
Name Discovery procedure 9.2.7 O O E E
C.1: Optional if limited discoverable mode is supported, otherwise mandatory.

Table 9.2: Device Discovery requirements

9.2.2 Non-discoverable mode

9.2.2.1 Description

A device configured in non-discoverable mode will not be discovered by any device that
is performing either the general discovery procedure or the limited discovery procedure.

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 3, Part C Page 1381
Generic Access Profile

9.2.2.2 Conditions

A device in the non-discoverable mode may send advertising events. If the device
sends advertising events, it shall not set the ‘LE General Discoverable Mode’ flag or ‘LE
Limited Discoverable Mode’ flag in the Flags AD type (see Section 1.3 of [4]).

If the device sends advertising events, then it is recommended that the Host configures
the Controller as follows:

• The Host should set the advertising filter policy for all advertising sets to either
‘process scan and connection requests only from devices in the Filter Accept List’ or
‘process scan and connection requests from all devices’.
• The Host should set the advertising intervals as defined in Section 9.3.11.

9.2.3 Limited Discoverable mode

9.2.3.1 Description

Devices configured in the limited discoverable mode are discoverable for a limited
period of time by other devices performing the limited or general device discovery
procedure. Devices typically enter the limited discoverable mode when a user performs
a specific action.

There are two common reasons to use limited discoverable mode:

• Limited discoverable mode can be used to allow remote devices using the general
discovery procedure to prioritize or otherwise identify devices in limited discoverable
mode when presenting discovered devices to the end user because, typically, the
user is interacting with them.
• Limited discoverable mode can also be used to allow remote devices using the limited
discovery procedure to filter out devices using the general discoverable mode.

9.2.3.2 Conditions

A device in the limited discoverable mode shall send advertising event types with the
advertising data including the Flags AD type as defined in Section 1.3 of [4] with all the
following flags set as described:

• The LE Limited Discoverable Mode flag set to one.

• The LE General Discoverable Mode flag set to zero.
• For an LE-only implementation with all the following flags set as described:
a. The ‘BR/EDR Not Supported’ flag to set one.
b. The ‘Simultaneous LE and BR/EDR to Same Device Capable (Controller)’ flag
set to zero.

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 3, Part C Page 1382
Generic Access Profile

The advertising data should also include the following AD types to enable a faster
connectivity experience:

• TX Power Level AD type defined in Section 1.5 of [4].

• Local Name AD type defined in Section 1.2 of [4].
• Service UUIDs AD type defined in Section 1.1 of [4].
• Peripheral Connection Interval Range AD type as defined in Section 1.9 of [4].

Devices shall remain in the limited discoverable mode no longer than

TGAP(lim_adv_timeout).

While a device is in limited discoverable mode the Host configures the Controller as
follows:

• The Host shall set the advertising filter policy for all advertising sets that share the
same Identity Address or the same IRK to ‘process scan and connection requests
from all devices’.
• The Host should set the advertising intervals as defined in Section 9.3.11.

The device shall remain in limited discoverable mode until a connection is established
or the Host terminates the mode.

Note: The choice of advertising interval is a trade-off between power consumption and
device discovery time.

The device may configure and enable multiple independent advertising sets.

9.2.4 General Discoverable mode

9.2.4.1 Description

Devices configured in the general discoverable mode are discoverable for an indefinite
period of time by devices performing the general discovery procedure. Devices typically
enter general discoverable mode autonomously.

Devices in the general discoverable mode will not be discovered by devices performing
the limited discovery procedure. General discoverable mode should not be used if
it is known that the device performing discovery will be using the limited discovery
procedure (see Section 9.2.5).

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 3, Part C Page 1383
Generic Access Profile

9.2.4.2 Conditions

A device in general discoverable mode shall send advertising events with the
advertising data including the Flags AD data type as defined in Section 1.3 of [4] with all
the following flags set as described:

• The LE Limited Discoverable Mode flag set to zero.

• The LE General Discoverable Mode flag set to one.
• For an LE-only implementation with all the following flags set as described:
a. The ‘BR/EDR Not Supported’ flag set to one.
b. The ‘Simultaneous LE and BR/EDR to Same Device Capable (Controller)’ flag
set to zero.

The advertising data should also include the following AD types to enable a faster
connectivity experience:

• TX Power Level AD type as defined in Section 1.5 of [4].

• Local Name AD type as defined in Section 1.2 of [4].
• Service UUIDs AD type as defined in Section 1.1 of [4].
• Peripheral Connection Interval Range AD type as defined in Section 1.9 of [4].

While a device is in general discoverable mode the Host configures the Controller as
follows:

• The Host shall set the advertising filter policy for all advertising sets that share the
same Identity Address or the same IRK to ‘process scan and connection requests
from all devices’.
• The Host should set the advertising intervals as defined in Section 9.3.11.

The device shall remain in general discoverable mode until a connection is established
or the Host terminates the mode.

Note: Host data used in legacy advertising events that change frequently should be
placed in the advertising data and static data should be placed in the scan response
data.

Note: The choice of advertising interval is a trade-off between power consumption and
device discovery time.

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 3, Part C Page 1384
Generic Access Profile

9.2.5 Limited Discovery procedure

9.2.5.1 Description

A device performing the limited discovery procedure receives the device address,
advertising data and scan response data from devices in the limited discoverable mode
only.

The limited discovery procedure should only be used when it is known that the devices
to be discovered are using limited discoverable mode. The general discovery procedure
(see Section 9.2.6) should be used for general purpose discovery when it is desired to
discover all devices regardless of whether they are using limited discoverable mode or
general discoverable mode.

Central Peripheral Peripheral

make general
discoverable

start scanning

make limited discoverable

advertising event (‘limited’)

advertising event (‘general’)

stop scanning

list of limited
discoverable
mode
devices only

Figure 9.1: A Central performing limited discovery procedure discovering Peripherals in the limited
discoverable mode

9.2.5.2 Conditions

It is recommended that the device scan on all the PHYs it supports.

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 3, Part C Page 1385
Generic Access Profile

When a Host performs the limited discovery procedure, the Host configures the
Controller as follows:

1. The Host shall set the scanning filter policy to an unfiltered scanning policy (see
[Vol 6] Part B, Section 4.3.3).
2. The Host should set the scan interval and scan window as defined in
Section 9.3.11.
3. The Host should configure the Controller to use active scanning.

The Host shall begin scanning for advertising packets and should continue for
a minimum of TGAP(lim_disc_scan_min) when scanning on the LE 1M PHY and
TGAP(lim_disc_scan_min_coded) when scanning on the LE Coded PHY, unless the Host
ends the limited discovery procedure.

The Host shall check for the Flags AD type in the advertising data. If the Flags AD
type is present and the LE Limited Discoverable Flag is set to one then the Host shall
consider the device as a discovered device, otherwise the advertising data shall be
ignored. The Flag AD type is defined in Section 1.3 of [4]. The advertising data of the
discovered device may contain data with other AD types, e.g. Service UUIDs AD type,
TX Power Level AD type, Local Name AD type, Peripheral Connection Interval Range
AD type. The Host may use the data in performing any of the connection establishment
procedures.

The Host shall ignore the 'Simultaneous LE and BR/EDR to Same Device Capable
(Controller)' bit in the Flags AD type.

9.2.6 General Discovery procedure

9.2.6.1 Description

A device performing the general discovery procedure receives the device address,
advertising data and scan response data from devices in the limited discoverable mode
or the general discoverable mode.

The general discovery procedure should be used for general purpose discovery, i.e. to
discover all discoverable devices regardless of whether they are in general discoverable
mode or limited discoverable mode. A device which discovers devices using the general
discovery procedure and presents them to users in some fashion should distinguish
devices in the limited discoverable mode from those in the general discoverable mode,
e.g., by sorting them to the top of a list of discovered devices or highlighting them in
some way.

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 3, Part C Page 1386
Generic Access Profile

Note: The rationale for distinguishing the devices in limited discoverable mode to the
end user is that devices typically enter limited discoverable mode only after explicit
action by the end user, indicating that the user’s immediate goal is to discover and
interact with that specific device.

Central Peripheral Peripheral

make general
discoverable

start scanning

make limited discoverable

advertising event (‘limited’)

advertising event (‘general’)

stop scanning

list of all
limited and
general
discoverable
mode
devices

Figure 9.2: A Central performing General Discovery procedure discovering Peripherals in the Limited
Discoverable mode and General Discoverable mode

9.2.6.2 Conditions

It is recommended that the device scan on all the PHYs it supports.

When a Host performs the general discovery procedure, the Host configures the
Controller as follows:

1. The Host shall set the scanning filter policy to an unfiltered scanning policy (see
[Vol 6] Part B, Section 4.3.3).
2. The Host should set the scan interval and scan window as defined in
Section 9.3.11.
3. The Host should configure the Controller to use active scanning.

The Host shall begin scanning for advertising packets and should continue for
a minimum of TGAP(gen_disc_scan_min) when scanning on the LE 1M PHY and

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 3, Part C Page 1387
Generic Access Profile

TGAP(gen_disc_scan_min_coded) when scanning on the LE Coded PHY. The procedure

may be terminated early by the Host.

The Host shall check for the Flags AD type in the advertising data. If the Flags AD
type (see Section 1.3 of [4]) is present and either the LE General Discoverable Mode
flag is set to one or the LE Limited Discoverable Mode flag is set to one then the
Host shall consider the device as a discovered device, otherwise the advertising data
shall be ignored. The advertising data of the discovered device may contain data with
other AD types, e.g. Service UUIDs AD type, TX Power Level AD type, Local Name
AD type, Peripheral Connection Interval Range AD type. The Host may use the data in
performing any of the connection establishment procedures as defined in Section 9.3.

The Host shall ignore the 'Simultaneous LE and BR/EDR to Same Device Capable
(Controller)' bit in the Flags AD type.

9.2.7 Name Discovery procedure

9.2.7.1 Description

The name discovery procedure is used to obtain the Bluetooth Device Name of a
remote connectable device.

9.2.7.2 Conditions

If the complete device name is not acquired while performing either the limited
discovery procedure or the general discovery procedure, then the name discovery
procedure may be performed.

The name discovery procedure shall be performed as follows:

1. The Host shall establish a connection using one of the connection establishment
procedures as defined in Section 9.3.
2. The Host shall read the device name characteristic using the GATT procedure
Read Using Characteristic UUID [Vol 3] Part G, Section 4.8.2
3. The connection may be terminated after the GATT procedure has completed.

9.3 Connection modes and procedures

The connection modes and procedures allow a device to establish a connection to
another device.

When devices are connected, the parameters of the connection can be updated with
the Connection Parameter Update procedure. The connected device may terminate
the connection using the Terminate Connection procedure. The requirements for a
device to support the connection modes and procedures are defined in Table 9.3. These

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 3, Part C Page 1388
Generic Access Profile

requirements refer to the specific role a device is operating in. Devices supporting
multiple roles shall support the specified modes and procedures for a given role while
operating in that role.

9.3.1 Requirements

Connection Modes and Procedures Ref. Peripheral Central Broadcaster Observer

Non-connectable mode 9.3.2 M E M M
Directed connectable mode 9.3.3 O E E E
Undirected connectable mode 9.3.4 M E E E
Auto connection establishment proce- 9.3.5 E O E E
dure
General connection establishment pro- 9.3.6 E O E E
cedure
Selective connection establishment pro- 9.3.7 E O E E
cedure
Direct connection establishment proce- 9.3.8 E M E E
dure
Periodic Advertising Connection proce- 9.3.17 C.3 C.4 E E
dure
Connection parameter update procedure 9.3.9 O M E E
Terminate connection procedure 9.3.10 M M E E
Connected Isochronous Stream Central 9.3.13 E C.1 E E
Establishment procedure
Connected Isochronous Stream Periph- 9.3.14 C.1 E E E
eral Establishment procedure
Connected Isochronous Stream Termi- 9.3.15 C.1 C.1 E E
nate procedure
Connection Subrate procedure 9.3.16 C.2 C.2 E E
C.1: Mandatory if Connected Isochronous Streams are supported, otherwise excluded.
C.2: Mandatory if the Connection Subrating feature is supported, otherwise excluded.
C.3: Mandatory if the Periodic Advertising with Responses - Scanner feature is supported, other-
wise Excluded
C.4: Mandatory if the Periodic Advertising with Responses - Advertiser feature is supported, other-
wise Excluded

Table 9.3: Connection modes and procedures requirements

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 3, Part C Page 1389
Generic Access Profile

9.3.2 Non-connectable mode

9.3.2.1 Description

A device in the non-connectable mode shall not allow a connection to be established.

9.3.2.2 Conditions

A Peripheral in the non-connectable mode may send non-connectable advertising

events. In this case it is recommended that the Host configures the Controller as
follows:

• The Host should set the advertising filter policy to either ‘process scan and
connection requests only from devices in the Filter Accept List’ or ‘process scan and
connection requests from all devices’.
• The Host should set the advertising intervals as defined in Section 9.3.11.

The device may configure and enable multiple independent advertising sets. Each
advertising set may have an independent advertising filter policy.

9.3.3 Directed Connectable mode

9.3.3.1 Description

A device in the directed connectable mode shall accept a connection request from
a known peer device performing the auto connection establishment procedure or the
general connection establishment procedure.

9.3.3.2 Conditions

A Peripheral shall send connectable directed advertising events.

The device may configure and enable multiple independent advertising sets. Each
advertising set may have an independent advertising filter policy.

9.3.4 Undirected Connectable mode

9.3.4.1 Description

A device in the undirected connectable mode shall accept a connection request from
a device performing the auto connection establishment procedure or the general
connection establishment procedure.

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 3, Part C Page 1390
Generic Access Profile

9.3.4.2 Conditions

A Peripheral should follow the guidelines defined in Section 9.3.11. A Peripheral shall
send either connectable and scannable undirected advertising events or connectable
undirected advertising events.

The device may configure and enable multiple independent advertising sets. Each
advertising set may have an independent advertising filter policy.

9.3.5 Auto Connection Establishment procedure

9.3.5.1 Description

The auto connection establishment procedure allows the Host to configure the
Controller to autonomously establish a connection with one or more devices in the
directed connectable mode or the undirected connectable mode. This procedure uses
the Filter Accept List in the initiator to store the addresses of the devices that can be
connected to. The Controller autonomously establishes a connection with a device with
the device address that matches the address stored in the Filter Accept List.

9.3.5.2 Conditions

Figure 9.3 shows the flow chart for a device performing the auto connection
establishment procedure.

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 3, Part C Page 1391
Generic Access Profile

Auto connection
establishment
procedure

Host writes list of device addresses to

the Controller Filter Accept List

Host sets initiator filter policy to:

‘process connectable advertising packets
from all devices in the Filter Accept List’

Host sets connection, Peripheral

latency and scan parameters

End of procedure

Figure 9.3: Flow chart for a device performing the Auto Connection Establishment procedure

When a Host performs the auto connection establishment procedure, the Host
configures the Controller as follows:

1. The Host shall write the list of device addresses that are to be auto connected to
into the Filter Accept List.
2. The Host shall set the initiator filter policy to ‘process connectable advertising
packets from all devices in the Filter Accept List’.
3. The Host should set the scan interval and scan window as defined in
Section 9.3.11.
4. The Host should set connection parameters as defined in Section 9.3.12.

This procedure is terminated when a connection is established or when the Host

terminates the procedure.

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 3, Part C Page 1392
Generic Access Profile

9.3.6 General Connection Establishment procedure

9.3.6.1 Description

The general connection establishment procedure allows the Host to establish a

connection with a set of known peer devices in the directed connectable mode or the
undirected connectable mode.

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 3, Part C Page 1393
Generic Access Profile

9.3.6.2 Conditions

Figure 9.4 shows the flow chart for a device performing the general connection
establishment procedure.

General connection
establishment procedure

Host sets scanning filter policy to

an unfiltered scanning policy

Host sets scan parameters and starts

scanning

Host compares received

advertisers address with the list of
devices it wants to connect to
No

Connect to
Peripheral
device?

Yes

Stop scanning

Initiate connection using the

direct connection establishment
procedure

Connection successful

End of procedure

Figure 9.4: Flow chart for a device performing the General Connection Establishment procedure

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 3, Part C Page 1394
Generic Access Profile

When a Host performs the general connection establishment procedure, the Host
configures the Controller as follows:

1. The Host shall set the scanning filter policy to an unfiltered scanning policy (see
[Vol 6] Part B, Section 4.3.3).
2. The Host should set the scan interval as defined in Section 9.3.11.
3. The Host should set the scan window as defined in Section 9.3.11.
4. The Host shall start active scanning or passive scanning.
5. The Host should set connection parameters as defined in Section 9.3.12.

When the Host discovers a device to which the Host may attempt to connect, the
Host shall stop the scanning, and initiate a connection using the direct connection
establishment procedure.

This procedure is terminated when a connection is established or when the Host

terminates the procedure.

9.3.7 Selective Connection Establishment procedure

9.3.7.1 Description

The selective connection establishment procedure allows the Host to establish a

connection, using the Host selected connection configuration parameters, with any
device whose address is stored in the Filter Accept List.

9.3.7.2 Conditions

Figure 9.5 shows the flow chart for a device performing the selective connection
establishment procedure.

When a Host performs the selective connection establishment procedure, the Host
configures the Controller as follows:

1. The Host shall write the list of device addresses that are to be selectively
connected into the Filter Accept List.
2. The Host shall set the scanning filter policy to a filtered scanning policy (see [Vol 6]
Part B, Section 4.3.3).
3. The Host should set the scan interval as defined in Section 9.3.11.
4. The Host should set the scan window as defined in Section 9.3.11.
5. The Host shall start active scanning or passive scanning.

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 3, Part C Page 1395
Generic Access Profile

When the Host discovers one of the peer devices it is connecting to, the Host shall stop
scanning, and initiate a connection using the direct connection establishment procedure
with the connection configuration parameters for that peer device.

This procedure is terminated when a connection is established or when the Host

terminates the procedure.

Selective connection
establishment procedure

Host writes list of device addresses to

the Controller Filter Accept List
to selectively connect to

Host sets scanning filter policy

to a filtered scanning policy

Host sets scan parameters

Start scanning

Host compares received

advertiser’s address with the list of
devices it wants to connect to

Connect to
Peripheral no
device?
yes

Stop scanning

Initiate connection using the direct

connection establishment procedure
with the connection configuration
parameters for the Peripheral

End of procedure

Figure 9.5: Flow chart for a device performing the Selective Connection Establishment procedure

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 3, Part C Page 1396
Generic Access Profile

9.3.8 Direct Connection Establishment procedure

9.3.8.1 Description

The direct connection establishment procedure allows the Host to establish a

connection with the Host selected connection configuration parameters with a single
peer device.

9.3.8.2 Conditions

Figure 9.6 shows the flow chart for a device performing the direct connection
establishment procedure.

Direct connection
establishment procedure

Host sets initiator filter policy to ‘ignore the

Filter Accept List and process connectable
advertising packets from a specific single
device specified by the Host’

Host sets the connection parameters for

the Peripheral

Host Initiates a connection to the

Peripheral

End of procedure

Figure 9.6: Flow chart for a device performing the Direct Connection Establishment procedure

When a Host performs the direct connection establishment procedure, the Host
configures the Controller as follows:

1. The Host shall set the initiator filter policy to ‘ignore the Filter Accept List and
process connectable advertising packets from a specific single device specified by
the Host’.
2. The Host shall set the peer address to the device address of the specific single
device.

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 3, Part C Page 1397
Generic Access Profile

3. The Host should set connection parameters as defined in Section 9.3.12.

4. The Host shall initiate a connection.

This procedure is terminated when a connection is established or when the Host

terminates the procedure.

9.3.9 Connection Parameter Update procedure

9.3.9.1 Description

The connection parameter update procedure allows a Peripheral or Central to update

the parameters of an established ACL connection.

9.3.9.2 Conditions

A Central initiating the connection parameter update procedure shall use the Link Layer
Connection Update procedure defined in [Vol 6] Part B, Section 5.1.1 with the required
connection parameters if either the Central or the Peripheral does not support the
Connection Parameters Request Link Layer Control procedure.

If both the Central and Peripheral support the Connection Parameters Request Link
Layer control procedure, then the Central or Peripheral initiating the connection
parameter update procedure should use the Connection Parameters Request Link
Layer Control procedure defined in [Vol 6] Part B, Section 5.1.7 with the required
connection parameters.

If either the Central or the Peripheral does not support the Connection Parameters
Request Link Layer Control procedure, then the Peripheral initiating the connection
parameter update procedure shall use the L2CAP_CONNECTION_PARAMETER_-
UPDATE_REQ command defined in [Vol 3] Part A, Section 4.20 with the required
connection parameters. The Peripheral shall not send an L2CAP_CONNECTION_-
PARAMETER_UPDATE_REQ command within TGAP(conn_param_timeout) of an
L2CAP_CONNECTION_PARAMETER_UPDATE_RSP being received. When the
Central accepts the Peripheral initiated Connection Parameter Update, the
Central should initiate the Link Layer Connection Update procedure defined in
[Vol 6] Part B, Section 5.1.1 with the required connection parameters within
TGAP(conn_param_timeout).

If the requested or updated connection parameters are unacceptable to the Central

or Peripheral then it may disconnect the connection with the error code 0x3B
(Unacceptable Connection Parameters). Devices should be tolerant of connection
parameters given to them by the remote device.

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 3, Part C Page 1398
Generic Access Profile

9.3.10 Terminate Connection procedure

9.3.10.1 Description

The Terminate Connection procedure allows a Host to terminate the connection with a
peer device.

9.3.10.2 Conditions

The Host should first terminate any associated CIS(es) prior to terminating the ACL.

The Host initiating the terminate connection procedure shall use the Link Layer ACL
Termination procedure defined in [Vol 6] Part B, Section 5.1.6.

9.3.11 Connection Establishment Timing parameters

9.3.11.1 Description

The connection establishment timing parameters are used during initial connection
establishment between a Central and a Peripheral.

A Central should use one of the GAP connection establishment procedures to initiate a
connection to a Peripheral in a connectable mode. The procedures and modes that may
use these timing parameters are defined in Section 9.3.4 to Section 9.3.8.

9.3.11.2 Conditions

A Central starting a user-initiated GAP connection establishment procedure should

use the recommended scan interval TGAP(scan_fast_interval) and scan window
TGAP(scan_fast_window) for TGAP(scan_fast_period) when scanning on the LE 1M
PHY and should use scan interval TGAP(scan_fast_interval_coded) and scan window
TGAP(scan_fast_window_coded) for TGAP(scan_fast_period) when scanning on the LE
Coded PHY.

A Central that is background scanning (i.e. as part of a GAP connection

establishment procedure that is not user-initiated) should use the recommended
scan interval TGAP(scan_slow_interval1) and scan window TGAP(scan_slow_window1)
when scanning on the LE 1M PHY and should use scan interval
TGAP(scan_slow_interval1_coded) and scan window TGAP(scan_slow_window1_coded)
when scanning on the LE Coded PHY. Alternatively the Central may use
TGAP(scan_slow_interval2) and scan window TGAP(scan_slow_window2) when
scanning on the LE 1M PHY and should use TGAP(scan_slow_interval2_coded) and
scan window TGAP(scan_slow_window2_coded) when scanning on the LE Coded PHY.

A Peripheral entering any of the following GAP Modes should use the
recommended advertising interval TGAP(adv_fast_interval1) for TGAP(adv_fast_period)

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 3, Part C Page 1399
Generic Access Profile

when advertising on the LE 1M PHY and should use TGAP(adv_fast_interval1_coded)

for TGAP(adv_fast_period) when advertising on the LE Coded PHY:

• Undirected Connectable Mode

• Limited Discoverable Mode and sending connectable undirected advertising events
• General Discoverable Mode and sending connectable undirected advertising events
• Directed Connectable Mode and sending low duty cycle connectable directed
advertising events

A Peripheral when entering any of the following GAP Modes and sending non-
connectable advertising events should use the recommended advertising interval
TGAP(adv_fast_interval2) for TGAP(adv_fast_period) when advertising on the LE 1M
PHY and should use TGAP(adv_fast_interval2_coded) for TGAP(adv_fast_period) when
advertising on the LE Coded PHY:

• Non-Discoverable Mode
• Non-Connectable Mode
• Limited Discoverable Mode
• General Discoverable Mode

A Peripheral that is background advertising in any GAP Mode other than GAP Directed
Connectable Mode with high duty cycle connectable directed advertising events should
use the recommended advertising interval TGAP (adv_slow_interval) when advertising
on the LE 1M PHY and should use TGAP (adv_slow_interval_coded) when advertising
on the LE Coded PHY.

Note: When advertising interval values of less than 100 ms are used for non-
connectable or scannable undirected advertising in environments where the advertiser
can interfere with other devices, it is recommended that steps be taken to minimize the
interference. For example, the advertising might be alternately enabled for only a few
seconds and disabled for several minutes.

9.3.12 Connection interval timing parameters

9.3.12.1 Description

The connection interval timing parameters are used within a connection. Initial
connection interval is used to ensure procedures such as bonding, encryption setup and
service discovery are completed quickly. The connection interval should be changed
to the value in the Peripheral Preferred Connection Parameters characteristic after
initiating procedures are complete.

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 3, Part C Page 1400
Generic Access Profile

9.3.12.2 Conditions

The Central should either read the Peripheral Preferred Connection Parameters
characteristic (see Section 12.3) or retrieve the parameters from advertising data (see
Section 12.3).

The connection interval should be set to TGAP(initial_conn_interval) when establishing

a connection on the LE 1M PHY and to TGAP(initial_conn_interval_coded) when
establishing a connection on the LE Coded PHY and connPeripheralLatency should be
set to zero. These parameters should be used until the Central has no further pending
actions to perform or until the Peripheral performs a Connection Parameter Update
procedure (see Section 9.3.9).

After the Central has no further pending actions to perform and the Peripheral has not
initiated any other actions within TGAP(conn_pause_central), then the Central should
invoke the Connection Parameter Update procedure (see Section 9.3.9) and change the
connection interval to that specified in the Peripheral Preferred Connection Parameters
characteristic.

If the Central has not read the Peripheral Preferred Connection Parameters
characteristic, then the Central may choose the connection parameters to be used.

After the Peripheral has no further pending actions to perform and the Central has
not initiated any other actions within TGAP(conn_pause_central), then the Peripheral
may perform a Connection Parameter Update procedure (see Section 9.3.9). The
Peripheral should not perform a Connection Parameter Update procedure within
TGAP(conn_pause_peripheral) after establishing a connection.

At any time a key refresh or encryption setup procedure is required and the current
connection interval is greater than TGAP(initial_conn_interval) when connected on the
LE 1M PHY or LE 2M PHY or greater than TGAP(initial_conn_interval_coded) when
connected on the LE Coded PHY, the key refresh or encryption setup procedure should
be preceded with a Connection Parameter Update procedure (see Section 9.3.9).
The connection interval should be set to TGAP(initial_conn_interval) when connected
on the LE 1M PHY or the LE 2M PHY and TGAP(initial_conn_interval_coded) when
connected on the LE Coded PHY, connSubrateFactor should be set to 1, and
connPeripheralLatency should be set to zero. This fast connection interval should
be maintained until the key refresh or encryption setup procedure is complete. It
should then switch to the value in the Peripheral Preferred Connection Parameters
characteristic.

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 3, Part C Page 1401
Generic Access Profile

9.3.13 Connected Isochronous Stream Central Establishment procedure

9.3.13.1 Description

The Connected Isochronous Stream Central Establishment procedure allows the Host
of a Central to establish a CIS with a Peripheral using the Host selected parameters.

9.3.13.2 Conditions

When two devices are connected, a Central may establish one or more CISes with
a Peripheral. A CIS is established by the Central using the Connected Isochronous
Stream Creation procedure (see [Vol 6] Part B, Section 5.1.15). The Central and or
Peripheral may send isochronous data over the established CIS.

9.3.14 Connected Isochronous Stream Peripheral Establishment procedure

9.3.14.1 Description

The Connected Isochronous Stream Peripheral Establishment procedure allows the

Host of the Peripheral to accept or reject the request from a Central to establish a CIS.

9.3.14.2 Conditions

When two devices are connected, the Peripheral may receive a request from the
Central to establish a CIS. Once the request is received, the Host in the Peripheral shall
either accept or reject the request. If it accepts the request, the CIS can be established
using the Connected Isochronous Stream Creation procedure defined in [Vol 6] Part B,
Section 5.1.15.

9.3.15 Connected Isochronous Stream Terminate procedure

9.3.15.1 Description

The Connected Isochronous Stream Terminate procedure allows a Host to terminate

a CIS with a peer device. The CIS shall also be terminated when the ACL between
the Central and Peripheral is terminated, using the Terminate Connection procedure
(Section 9.3.10).

9.3.15.2 Conditions

The Host initiating the Connected Isochronous Stream Terminate procedure shall use
the Connected Isochronous Stream Termination control procedure defined in [Vol 6]
Part B, Section 5.1.16.

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 3, Part C Page 1402
Generic Access Profile

9.3.16 Connection Subrate procedure

9.3.16.1 Description

The Connection Subrate procedure allows a Peripheral or Central to modify the

connection subrating and other connection parameters of an established ACL
connection.

9.3.16.2 Conditions

The Central initiating this procedure shall use the Link Layer Connection Subrate
Update procedure defined in [Vol 6] Part B, Section 5.1.19 and the Peripheral initiating
this procedure shall use the Connection Subrate Request procedure defined in [Vol 6]
Part B, Section 5.1.20.

If the requested subrate connection parameters are unacceptable to the Central then it
may reject them. If the updated subrate connection parameters are unacceptable to the
Peripheral it cannot reject them but may follow up by using the Connection Parameter
Request procedure (see [Vol 6] Part B, Section 5.1.7) or the Connection Subrate
Request procedure (see [Vol 6] Part B, Section 5.1.20) to change them. Devices should
be tolerant of the connection parameters requested by the peer device.

9.3.17 Periodic Advertising Connection procedure

9.3.17.1 Definition

The periodic advertising connection procedure provides a method for a periodic

advertiser to initiate a Link Layer connection with a synchronized device.

9.3.17.2 Conditions

A device performing the periodic advertising connection procedure shall initiate the Link
Layer connection procedure using periodic advertising trains with responses (see [Vol 6]
Part B, Section 4.4.2.12.2).

9.4 Bonding modes and procedures

Bonding allows two connected devices to exchange and store security and identity
information to create a trusted relationship. The security and identity information as
defined in [Vol 3] Part H, Section 2.4.1 is also known as the bonding information. When
the devices store the bonding information, it is known as the phrases ‘devices have
bonded’ or ‘a bond is created’.

There are two modes for bonding, non-bondable mode and bondable mode. Bonding
may only occur between two devices in bondable mode. The requirements for a device
to support the bonding modes and procedure are defined in Table 9.4.

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 3, Part C Page 1403
Generic Access Profile

9.4.1 Requirements

Bonding Ref. Peripheral Central Broadcaster Observer

Non-Bondable mode 9.4.2 M M E E
Bondable mode 9.4.3 O O E E
Bonding procedure 9.4.4 C.1 C.1 E E
C.1: Mandatory if Bondable mode is supported, otherwise Excluded.

Table 9.4: Bonding requirements

9.4.2 Non-bondable mode

9.4.2.1 Description

A device in the non-bondable mode does not allow a bond to be created with a peer
device.

9.4.2.2 Conditions

If a device does not support pairing as defined in the Security Manager section then it is
considered to be in non-bondable mode.

If Security Manager pairing is supported, the Host shall set the Bonding_Flags to ‘No
Bonding’ as defined in [Vol 3] Part H, Section 3.5.1 and bonding information shall not be
exchanged or stored.

9.4.3 Bondable mode

9.4.3.1 Description

A device in the bondable mode allows a bond to be created with a peer device in the
bondable mode.

9.4.3.2 Conditions

The Host shall set the Bonding_Flags to ‘Bonding’ as defined in [Vol 3] Part H,
Section 3.5.1 during the pairing procedure.

9.4.4 Bonding procedure

9.4.4.1 Description

The bonding procedure may be performed when a non-bonded device tries to access
a service that requires bonding. The bonding procedure may be performed for the
purpose of creating a bond between two devices.

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 3, Part C Page 1404
Generic Access Profile

Central Peripheral

established link

Access to service is protected and bonding

is required

SM pairing (general bonding)

update list of paired devices update list of paired devices

Figure 9.7: Bonding requirements

9.4.4.2 Conditions

The Central shall be in the bondable mode and shall initiate the pairing process as
defined in Section 2.1. If the Peripheral is in the bondable mode, the devices shall
exchange and store the bonding information in the security database.

If a device supports the generation of resolvable private addresses as defined in

Section 10.8.2.2 and generates a resolvable private address for its local address, it shall
send Identity Information with SMP, including a valid IRK. If a device does not generate
a resolvable private address for its own address and the Host sends Identity Information
with SMP, the Host shall send an all-zero IRK. If a device supports resolving resolvable
private addresses as defined in Section 10.8.2.3, it shall request the peer device to
send its Identity Information with SMP. The Host can abort the pairing procedure if the
authentication requirements are not sufficient to distribute the IRK.

9.5 Periodic advertising modes and procedure

The periodic advertising modes and procedure allow two or more devices to
communicate in a connectionless manner using extended advertising events and
periodic advertising events. These modes and procedures can also make use of
existing connections. The requirements for a device operating in a specific GAP role
to support these modes and procedures are defined in Table 9.5.

Mode and Procedures Ref. Broadcaster Observer Peripheral Central

Periodic Advertising 9.5.1 O E E E
Synchronizability mode
Periodic Advertising 9.5.2 C.1 E E E
mode

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 3, Part C Page 1405
Generic Access Profile

Mode and Procedures Ref. Broadcaster Observer Peripheral Central

Periodic Advertising 9.5.3 E O O O
Synchronization Estab-
lishment procedure
Periodic Advertising 9.5.4 E E C.2 C.2
Synchronization Trans-
fer procedure
C.1: Mandatory if Periodic Advertising Synchronizability mode is supported, otherwise excluded.
C.2: Optional if Periodic Advertising Mode is supported or the Periodic Advertising Synchronization
Establishment procedure is supported, otherwise excluded.

Table 9.5: Periodic advertising modes and periodic advertising procedure requirements

9.5.1 Periodic Advertising Synchronizability mode

9.5.1.1 Definition

The periodic advertising synchronizability mode provides a method for a device to

send synchronization information about a periodic advertising train (with or without
responses) using advertisements.

9.5.1.2 Conditions

A device in the periodic advertising synchronizability mode shall send synchronization

information for a periodic advertising train (with or without responses) in non-
connectable and non-scannable extended advertising events. The advertising interval
used is unrelated to the interval between the periodic advertising events.

A device shall not be in periodic advertising synchronizability mode unless it is also

in periodic advertising mode. It may leave, and possibly re-enter, periodic advertising
synchronizability mode while remaining in periodic advertising mode.

9.5.2 Periodic Advertising mode

9.5.2.1 Definition

On periodic advertising trains without responses, the periodic advertising mode provides
a method for a device to send advertising data at periodic and deterministic intervals.
On periodic advertising trains with responses, a device may send advertising data in
one or more subevents to synchronized devices who may also send data back to the
device.

9.5.2.2 Conditions

A device in the periodic advertising mode shall send periodic advertising events at the
interval and using the frequency hopping sequence specified in the periodic advertising

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 3, Part C Page 1406
Generic Access Profile

synchronization information. On periodic advertising trains with responses, the interval

may be divided into subevents. During a subevent, a synchronized device may send
data back to the device in response slots.

A device entering periodic advertising mode shall also enter periodic advertising
synchronizability mode for at least long enough to complete one extended advertising
event (see [Vol 6] Part B, Section 4.4.2.12).

9.5.3 Periodic Advertising Synchronization Establishment procedure

9.5.3.1 Definition

The periodic advertising synchronization establishment procedure provides a method

for a device to receive periodic advertising synchronization information and to
synchronize to a periodic advertising train.

9.5.3.2 Conditions

A device performing the periodic advertising synchronization establishment procedure

shall scan for non-connectable and non-scannable advertising events containing
synchronization information about a periodic advertising train or shall accept periodic
advertising synchronization information over an existing connection by taking part in
the Link Layer Periodic Advertising Sync Transfer procedure defined in [Vol 6] Part
B, Section 5.1.13. When a device receives synchronization information for a periodic
advertising train, it may listen for periodic advertising events at the intervals and using
the frequency hopping sequence specified in the periodic advertising synchronization
information. If a device receives synchronization information about periodic advertising
with responses, it may listen to one or more subevents in the interval and may send
data to the periodic advertiser.

9.5.4 Periodic Advertising Synchronization Transfer procedure

9.5.4.1 Definition

The periodic advertising synchronization transfer procedure provides a method for a

device to send synchronization information about a periodic advertising train over an
existing connection.

9.5.4.2 Conditions

A device performing the periodic advertising synchronization transfer procedure shall

initiate the Link Layer Periodic Advertising Sync Transfer procedure defined in [Vol 6]
Part B, Section 5.1.13.

9.5.5 [This section is no longer used]

The Periodic Advertising Connection procedure is described in Section 9.3.17.

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 3, Part C Page 1407
Generic Access Profile

9.6 Isochronous Broadcast modes and procedures

The Isochronous Broadcast modes and procedures allow two or more devices to
communicate in a unidirectional, connectionless manner by using extended advertising
events, periodic advertising events, and BIG and BIS events. The requirements for a
device that operates in a specific GAP role to support these modes and procedures are
defined in Table 9.6.

Modes and Procedures Ref. Peripheral Central Broadcaster Observer

Broadcast Isochronous Synchronizability 9.6.1 E E C.1 E
mode
Broadcast Isochronous Broadcasting 9.6.2 E E O E
mode
Broadcast Isochronous Synchronization 9.6.3 E E E O
Establishment procedure
Broadcast Isochronous Channel Map Up- 9.6.4 E E C.1 C.2
date procedure
Broadcast Isochronous Terminate proce- 9.6.5 E E C.1 C.2
dure
C.1: Mandatory if Broadcast Isochronous Broadcasting mode is supported, otherwise excluded.
C.2: Mandatory if Broadcast Isochronous Synchronization Establishment procedure is supported,
otherwise excluded.

Table 9.6: Isochronous Broadcast modes and procedure requirements

9.6.1 Broadcast Isochronous Synchronizability mode

9.6.1.1 Definition

The Broadcast Isochronous Synchronizability mode provides a method for a device to

transmit the synchronization information of a BIG.

9.6.1.2 Conditions

A device shall also be in the Broadcast Isochronous Broadcasting mode while it is in the
Broadcast Isochronous Synchronizability mode. A device in the Broadcast Isochronous
Synchronizability mode shall send the BIGInfo in the ACAD field which is located in the
AUX_SYNC_IND PDU of periodic advertisement ([Vol 6] Part B, Section 2.3.4.8).

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 3, Part C Page 1408
Generic Access Profile

9.6.2 Broadcast Isochronous Broadcasting mode

9.6.2.1 Definition

The Broadcast Isochronous Broadcasting mode provides a method for a device in the
Broadcaster role to send encrypted or unencrypted Broadcast Isochronous PDUs in
subevents of BISes of a BIG ([Vol 6] Part B, Section 4.4.6).

9.6.2.2 Conditions

A device in the Broadcast Isochronous Broadcasting mode shall send isochronous

PDUs in subevents of BISes of a BIG ([Vol 6] Part B, Section 4.4.6).

9.6.3 Broadcast Isochronous Synchronization Establishment procedure

9.6.3.1 Definition

The Broadcast Isochronous Synchronization Establishment procedure provides a way

for a device to synchronize to a BIS.

9.6.3.2 Conditions

A device that performs the Broadcast Isochronous Synchronization Establishment

procedure shall first perform the Periodic Advertising Synchronization Establishment
procedure (Section 9.5.3) and receive the synchronization information. The
synchronization information is used to synchronize to the required BIS in the BIG ([Vol
6] Part B, Section 4.4.6).

9.6.4 Broadcast Isochronous Channel Map Update procedure

9.6.4.1 Definition

The Broadcast Isochronous Channel Map Update procedure allows a Broadcaster to

use and transmit a new channel map of a BIG, or an Observer to receive and use a new
channel map for a BIG.

9.6.4.2 Conditions

In this procedure, the Broadcaster sends the channel map command in the BIG events
([Vol 6] Part B, Section 4.4.6.4). When an Observer receives a channel map message, it
uses the new channel when receiving data from the BIG.

9.6.5 Broadcast Isochronous Terminate procedure

9.6.5.1 Definition

The Broadcast Isochronous Terminate procedure allows a Host of a Broadcaster to

terminate a BIG, or the Host of an Observer to terminate synchronization with a BIG.

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 3, Part C Page 1409
Generic Access Profile

9.6.5.2 Conditions

The Host initiating the Broadcast Isochronous Stream Terminate procedure shall use
the Broadcast Isochronous Stream Termination control procedure defined in [Vol 6] Part
B, Section 5.6.2.

9.7 Channel Sounding procedures

The Channel Sounding procedures allow two devices to exchange information that may
be used for distance approximation between the two. During this exchange, each device
must select the alternate procedure type.

Connection Sounding Procedures Ref. Peripheral Central Broadcaster Observer

CS initiator procedure 9.7.1 O O E E
CS reflector procedure 9.7.2 O O E E

Table 9.7: Channel Sounding procedure requirements

9.7.1 Channel Sounding initiator procedure

9.7.1.1 Description

The CS initiator procedure allows a Peripheral or Central to initiate a CS procedure.

9.7.1.2 Conditions

If the CS initiator role is supported by the Controller, then the Host may enable
the initiator role by commanding the Controller to set the initiator role flag in the
Configuration Exchange procedure as described in [Vol 6] Part B, Section 5.1.25.

If both the Central and Peripheral support the CS procedure, then the Central or
Peripheral initiating the CS procedure shall do so in the manner described in [Vol 6]
Part B, Section 5.1.26.

9.7.2 Channel Sounding reflector procedure

9.7.2.1 Description

The CS reflector procedure allows a Peripheral or Central to respond to a CS initiator

procedure.

9.7.2.2 Conditions

If the CS reflector role is supported by the Controller, then the Host may enable the
reflector role by commanding the Controller to set the Responder Role flag in the
Configuration Exchange procedure as described in [Vol 6] Part B, Section 5.1.25.

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 3, Part C Page 1410
Generic Access Profile

The Central or Peripheral responding to the CS procedure shall do so in the manner

described in [Vol 6] Part B, Section 5.1.26.

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 3, Part C Page 1411
Generic Access Profile

10 SECURITY ASPECTS – LE PHYSICAL

TRANSPORT

This section defines the modes and procedures that relate to the security of either an
ACL connection or broadcast. The modes and procedures that relate to the security of
a CIS shall be the same as that used in its associated ACL. The following modes and
procedures are defined:

• LE security mode 1
• LE security mode 2
• LE security mode 3
• Authentication procedure
• Authorization procedure
• Connection data signing procedure
• Authenticate signed data procedure
• Encrypted Advertising Data procedure

Requirements for a device to support the LE security modes and procedures is shown
in Table 10.1.

10.1 Requirements

Security Modes and Procedures Ref. Broadcaster Observer Peripheral Central

LE Security mode 1 10.2.1 E E O O
LE Security mode 2 10.2.2 E E O O
LE Security mode 3 10.2.5 O O E E
Authentication procedure 10.3 E E O O
Authorization procedure 10.5 E E O O
Connection data signing procedure 10.4.1 E E O O
Authenticate signed data procedure 10.4.2 E E O O
Encrypted Advertising Data procedure 10.10 O O O O

Table 10.1: Requirements related to security modes and procedures

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 3, Part C Page 1412
Generic Access Profile

10.2 LE security modes

The security requirements of a device, a service or a service request are expressed in
terms of a security mode and security level. Each service or service request may have
its own security requirement. The device may also have a security requirement.

There are three LE security modes, LE security mode 1, LE security mode 2, and LE
security mode 3.

10.2.1 LE security mode 1

LE security mode 1 has the following security levels:

1. No security (No authentication and no encryption)

2. Unauthenticated pairing with encryption
3. Authenticated pairing with encryption
4. Authenticated LE Secure Connections pairing with encryption using a 128-bit
strength encryption key.

For certain services that require LE security mode 1, levels 2 or 3, a device may enforce
the use of LE Secure Connections pairing before those services can be used.

A connection operating in LE security mode 1 level 2 shall also satisfy the security
requirements for LE security mode 1 level 1.

A connection operating in LE security mode 1 level 3 shall also satisfy the security
requirements for LE security mode 1 level 2 or LE security mode 1 level 1.

A connection operating in LE security mode 1 level 3 shall also satisfy the security
requirements for LE security mode 2.

A connection operating in LE security mode 1 level 4 shall also satisfy the security
requirements for LE security mode 1 level 3 or LE security mode 1 level 2 or LE security
mode 1 level 1.

A connection operating in LE security mode 1 level 4 shall also satisfy the security
requirements for LE security mode 2.

10.2.2 LE security mode 2

LE security mode 2 has two security levels:

1. Unauthenticated pairing with data signing

2. Authenticated pairing with data signing

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 3, Part C Page 1413
Generic Access Profile

LE security mode 2 shall only be used for connection based data signing.

Data signing as defined in Section 10.4 shall not be used when a connection is
operating in LE security mode 1 level 2, LE security mode 1 level 3, or LE security
mode 1 level 4.

10.2.3 Mixed security modes requirements

If there are requirements for both LE security mode 1 and LE security mode 2 level 2 for
a given physical link then LE security mode 1 level 3 shall be used.

If there are requirements for both LE security mode 1 level 3 and LE security mode 2 for
a given physical link then LE security mode 1 level 3 shall be used.

If there are requirements for both LE security mode 1 level 2 and LE security mode 2
level 1 for a given physical link then LE security mode 1 level 2 shall be used.

If there are requirements for both LE security mode 1 level 4 and any other security
mode or level for a given physical link then LE security mode 1 level 4 shall be used.

10.2.4 Secure Connections Only mode

A device may be in a Secure Connections Only mode. When in Secure Connections

Only mode only security mode 1 level 4 shall be used except for services that only
require security mode 1 level 1.

The device shall only accept new outgoing and incoming service level connections for
services that require Security Mode 1, Level 4 when the remote device supports LE
Secure Connections and authenticated pairing is used.

10.2.5 LE security mode 3

LE security mode 3 has three security levels:

1. No security (no authentication and no encryption)

2. Use of unauthenticated Broadcast_Code
3. Use of authenticated Broadcast_Code

LE security mode 3 shall be used to broadcast a Broadcast Isochronous Group (BIG) in

an Isochronous Broadcaster or receive a BIS in a Synchronized Receiver.

A device operating in security mode 3 level 1 shall require that the isochronous data is
unencrypted.

A device that operates in LE security mode 3 level 2 shall require a Broadcast_Code to

encrypt the data that is transmitted in a BIS.

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 3, Part C Page 1414
Generic Access Profile

A device that operates in LE security mode 3 level 3 shall require a Broadcast_Code

to encrypt the data that is transmitted in a BIS. If the device has not received a
Broadcast_Code using an authenticated method when the service requires Level 3
security and has a user interface capable of doing so, then the device shall indicate an
appropriate error to the user (e.g., Insufficient Security for Broadcast_Code).

10.3 Authentication procedure

The authentication procedure describes how the required security is established when
a device initiates a service request to a remote device and when a device receives a
service request from a remote device. The authentication procedure covers LE security
mode 1. The authentication procedure shall only be initiated after a connection has
been established.

LE security mode 2 pertains to the use of data signing and is covered in Section 10.4.

Authentication in LE security mode 1 is achieved by enabling encryption as defined

in Section 10.6. The security of the encryption is impacted by the type of pairing
performed. There are two types of pairing: authenticated pairing or unauthenticated
pairing. Authenticated pairing involves performing the pairing procedure defined in [Vol
3] Part H, Section 2.1 with the authentication set to ‘MITM protection’. Unauthenticated
pairing involves performing the pairing procedure with authentication set to ‘No MITM
protection’.

Note: In this section, the terms “authenticated pairing” and “unauthenticated pairing”
refer to the security method used to perform pairing and are not related to the
authentication of previously bonded devices during a reconnection.

Section 10.3.1 specifies the authentication procedure when a device responds to a

service request. Section 10.3.2 specifies the authentication procedure when a device
initiates a service request.

10.3.1 Responding to a service request

In this section the local device is the device responding to a service request made by
a remote device. In the L2CAP protocol the local device responds with a connection
response to a remote device making a connection request. In GATT, the local device is
the GATT Server and the remote device is the GATT Client.

When a local device receives a service request from a remote device, it shall respond
with an error code if the service request is denied. The error code is dependent on
whether the current connection is encrypted or not and on the type of pairing that was
performed to create the LTK or STK to be used.

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 3, Part C Page 1415
Generic Access Profile

When a local device receives a service request from a remote device it shall behave
according to the following rules:

• The local device’s security database specifies the security settings required to accept
a service request. If no encryption and no data signing are required, the service
request shall be accepted. If encryption is required the local device shall send an
error code as defined in Table 10.2. If no encryption is required, but data signing is
required, then the local device behavior is as defined in Section 10.4.
• If neither an LTK nor an STK is available, the service request shall be rejected with
the error code “Insufficient Authentication”.
Note: When the link is not encrypted, the error code “Insufficient Authentication” does
not indicate that MITM protection is required.
• If an LTK or an STK is available and encryption is required (LE security mode 1) but
encryption is not enabled, the service request shall be rejected with the error code
“Insufficient Encryption”. If the encryption is enabled with a key size that is too short
then the service request shall be rejected with the error code “Encryption Key Size
Too Short.”
• If an authenticated pairing is required but only an unauthenticated pairing has
occurred and the link is currently encrypted, the service request shall be rejected
with the error code “Insufficient Authentication.”

Note: When unauthenticated pairing has occurred and the link is currently encrypted,
the error code “Insufficient Authentication” indicates that MITM protection is required.
• If LE Secure Connections pairing is required but LE legacy pairing has occurred and
the link is currently encrypted, the service request shall be rejected with the error
code “Insufficient Authentication”.

The local device will respond with the minimum security level required for access to its
services. If the local device has no security requirement it should default to the minimum
security level that the local device is capable of as defined in pairing phase 1, (see [Vol
3] Part H, Section 2.1).

A local device shall not require an authenticated pairing (MITM) if the local device does
not support the required IO capabilities or OOB data1.

The local device responds to a service request from a remote device are summarized in
Table 10.2.

1If
an OOB mechanism is used, the level of MITM protection is dependent upon the properties of the OOB
communications channel. See [Vol 3] Part H, Section 2.3.5.1 for more information

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 3, Part C Page 1416
Generic Access Profile

Link Local Local Device Pairing Status

Encryp- Device’s
No LTK Unauthenticated Authenticated Authenticated
tion Access
LTK (with LTK without LTK with
State Requirement No STK
or without LE Secure Secure
for Service
LE Secure Connections Connections
Connections) or or
Unauthenticated Authenticated
STK STK
None Request suc- Request suc- Request suc- Request suc-
ceeds ceeds ceeds ceeds
Encryption, Error Resp.: Error Resp.: In- Error Resp.: Error Resp.:
No MITM Pro- Insufficient Au- sufficient Encryp- Insufficient En- Insufficient En-
Unencrypted

tection thentication tion cryption cryption

Encryption, Error Resp.: Error Resp.: In- Error Resp.: Error Resp.:
MITM Protec- Insufficient Au- sufficient Encryp- Insufficient En- Insufficient En-
tion thentication tion cryption cryption
Encryption, Error Resp.: Error Resp.: In- Error Resp.: Error Resp.:
MITM Protec- Insufficient Au- sufficient Encryp- Insufficient En- Insufficient En-
tion, Secure thentication tion cryption cryption
Connections
None N/A Request suc- Request suc- Request suc-
ceeds ceeds ceeds
(Not possible
Encryption, to be encryp- Request suc- Request suc- Request suc-
No MITM Pro- ted without ceeds ceeds ceeds
tection LTK)
Encrypted

Encryption, Error Resp.: In- Request suc- Request suc-

MITM Protec- sufficient Authen- ceeds ceeds
tion tication
Encryption, Error Resp.: In- Error Resp.: Request suc-
MITM Protec- sufficient Authen- Insufficient Au- ceeds
tion, Secure tication thentication
Connections

Table 10.2: Local device responds to a service request

Figure 10.1 shows how a server handles a service request.

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 3, Part C Page 1417
Generic Access Profile

Receive a Service
Request

Query security DB

Access to service No, security not

rejected
successful? required (level 1)

Yes

Bond Exists? Yes

No

Current security
No
Good Enough?

Pairing

Yes

Success and Encryption No

No correct Security Yes
Needed? (Mode 2)
level?

Yes

Remote
No supports
encryption?

Yes

Encryption

Cross-transport
Key derivation No
possible?

Yes
Perform Service
Abort BR/EDR Request on
Link Key generation Local Device

Figure 10.1: Flow chart for a local device handling a service request from a remote device

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 3, Part C Page 1418
Generic Access Profile

10.3.1.1 Handling of GATT indications and notifications

A client “requests” a server to send indications and notifications by appropriately

configuring the server via a Client Characteristic Configuration Descriptor. Since
the configuration is persistent across a disconnection and reconnection, security
requirements shall be checked against the configuration upon a reconnection before
sending indications or notifications. When a server reconnects to a client to send an
indication or notification for which security is required, the server shall initiate or request
encryption with the client prior to sending an indication or notification. If the client does
not have an LTK, indicating that the client has lost the bond, enabling encryption will fail.

10.3.1.2 Cross-transport key generation

After encryption is enabled, the correct security level has been achieved, and both
devices support cross-transport key generation, the both devices may perform BR/EDR
link key derivation.

Note: If the LTK has an encryption key size that is shorter than 16 octets (128 bits), the
BR/EDR link key is derived before the LTK gets masked.

10.3.2 Initiating a service request

In this section the local device is the device initiating a service request to a remote
device. In the L2CAP protocol the local device sends the connection request and the
remote device sends the connection response. In GATT, the local device is the GATT
Client and the remote device is the GATT Server.

When a local device initiates a service request to a remote device it shall behave
according to the following rules:

• The local device’s security database specifies the security required to initiate a
service request. If no encryption is required by the local device then the service
request may proceed without encryption or pairing.
• If an LTK is not available but encryption is required, the pairing procedure shall
be initiated with the local device’s required authentication settings. If the pairing
procedure fails then the service request shall be aborted.

Note: When encryption is not enabled, the error code “Insufficient Authentication”
does not indicate to the local device that MITM protection is required.

Note: If the local device is a Peripheral then it may send a Peripheral Initiated
Security Request as defined in [Vol 3] Part H, Section 2.4.6.
• If pairing has occurred but the encryption key size is insufficient the pairing procedure
shall be executed with the required encryption key size. If the pairing procedure fails
then the service request shall be aborted.

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 3, Part C Page 1419
Generic Access Profile

• If an LTK is available and encryption is required (LE security mode 1) then encryption
shall be enabled before the service request proceeds as defined in Section 10.6.
Once encryption is enabled the service request shall proceed. If encryption fails,
then either the bond no longer exists on the remote device or the wrong device has
been connected. If the local device does not abandon the service request, it shall
trigger a user interaction to confirm the remote device and then re-bond, perform
service discovery, and reconfigure the remote device (reconfiguring the remote device
can involve actions such as re-enabling indications and notifications on the relevant
characteristics). If the local device had previously determined that the remote device
did not have the «Service Changed» characteristic, or if the local device determines
by reading the «Database Hash» characteristic that the database has not changed,
then service discovery may be skipped.
• If an authenticated pairing is required but only an unauthenticated pairing has
occurred and the link is currently encrypted, the pairing procedure shall be executed
with the required authentication settings. If the pairing procedure fails or an
authenticated pairing cannot be performed with the IO capabilities of the local device
and remote device, then the service request shall be aborted.
When a bond has been created between two devices, any reconnection should result
in the local device enabling or requesting encryption with the remote device before
initiating any service request.
If a local device does not enable encryption before initiating a service request and
relies on the error codes to determine the security requirements, the local device
shall not request pairing with MITM protection in response to receiving an “Insufficient
Authentication” error code from the remote device while the link is unencrypted. The
local device shall only set the MITM protection required flag if the local device itself
requires MITM protection.
• If encryption is not enabled at the time of the service request, the error code
“Insufficient Authentication” is received, and the local device currently has an LTK,
then the encryption procedure should be started (see Section 10.6). If this fails (likely
indicating that the remote device has lost the bond and no longer has the LTK) or
the local device does not have the correct LTK, then it should re-pair. If it re-pairs, it
shall trigger a user interaction to confirm the remote device before starting the pairing
procedure. IO capabilities are exchanged in pairing phase 1, (see [Vol 3] Part H,
Section 2.1) and the security level shall be determined by the devices’ IO capabilities
and MITM requirements.
• If encryption is not enabled at the time of the service request, the error code
“Insufficient Encryption” is received, and the local device currently has an LTK, then
the encryption procedure shall be started (see Section 10.6). If starting encryption
fails (likely indicating that the remote device has lost the bond and no longer has the
LTK) or the local device does not have the correct LTK, then it should re-pair. If it

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 3, Part C Page 1420
Generic Access Profile

re-pairs, it shall trigger a user interaction to confirm the remote device before starting
the pairing procedure.
• If LE Secure Connections authenticated pairing is required but the remote device
does not support LE Secure Connections, then the service request shall be aborted.

Figure 10.2 shows how a client issues a service request.

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 3, Part C Page 1421
Generic Access Profile

Initiate a service
request to a
remote device

Local device
queries security
DB

Access
No to service
allowed?

Yes

Remote No, security not

device needs
authenticating? required Mode1,
(level 1)

Yes

Bond Exists
Yes
Locally?

No

No Current security
Good Enough?

Pairing

Yes

Success and
No correct Security Encryption
level?

Yes

Cross-transport
Key derivation No
possible?

Yes

Local device BR/EDR Perform Service

abandons Link Key generation request on
procedure remote device

Figure 10.2: Flow chart for a local device issuing a service request to a remote device

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 3, Part C Page 1422
Generic Access Profile

10.3.2.1 Cross-transport key generation

After encryption is enabled, the correct security level has been achieved, and both
devices support cross-transport key generation, the both devices may perform BR/EDR
link key derivation.

Note: If the LTK has an encryption key size that is shorter than 16 octets (128 bits), the
BR/EDR link key is derived before the LTK gets masked.

10.3.2.2 Handling of GATT indications and notifications

A client requests a server to send indications and notifications by appropriately

configuring the server via a Client Characteristic Configuration Descriptor. Since the
configuration is persistent across a disconnection and reconnection, the client shall
check the security requirements against the configuration upon a reconnection before
processing any indications or notifications from the server. Any notifications received
before the security requirements are met shall be ignored. Any indications received
before the security requirements are met shall be confirmed and then discarded. When
a client reconnects to a server and expects to receive indications or notifications for
which security is required, the client shall enable encryption with the server. If the server
does not have an LTK, indicating that the server has lost the bond, enabling encryption
will fail.

10.4 Data signing

The data signing is used for transferring authenticated data between two devices in an
unencrypted connection. The data signing method is used by services that require fast
connection set up and fast data transfer.

If a service request specifies LE security mode 2, the connection data signing procedure
shall be used.

10.4.1 Connection Data Signing procedure

A device shall generate a new Connection Signature Resolving Key CSRK for each set
of peer device(s) to which it sends signed data in connections. CSRK is defined in [Vol
3] Part H, Section 2.4.2.2.

The data shall be formatted using the Signing Algorithm as defined in [Vol 3] Part
H, Section 2.4.5 where m is the Data PDU to be signed, k is the CSRK and the
SignCounter is the counter value. A Signature is composed of the counter value and the
Message Authentication Code (MAC) generated by the Signing Algorithm. The counter
value shall be incremented by one for each new Data PDU sent.

The format of signed data is shown in Figure 10.3.

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 3, Part C Page 1423
Generic Access Profile

Data PDU Signature

LSB MSB
Variable 12 octets

SignCounter MAC

LSB MSB
4 octets 8 octets

Figure 10.3: Generic format of signed data

10.4.2 Authenticate Signed Data procedure

If encryption is not required and CSRK is available (LE security mode 2) then the
data signing procedure shall be used when making a service request involving a write
operation.

Note: The existence of the bond on the server can be determined by successfully
enabling encryption with the server using the encryption procedure defined in Section
10.6. A higher layer profile may allow a client to not perform the authentication
procedure. Alternatively, a higher layer protocol may signal the client that the signature
check has failed due to a lost bond, and the client may then take action to notify the
user or attempt to pair again to reestablish the bond.

A device receiving signed data shall authenticate it by performing the Signing Algorithm.
The signed data shall be authenticated by performing the Signing Algorithm where m
is the Data PDU to be authenticated, k is the stored CSRK and the SignCounter is the
received counter value. If the MAC computed by the Signing Algorithm does not match
the received MAC, the verification fails and the Host shall ignore the received Data
PDU.

Since the server does not respond to a Signed Write command, the higher layer
application is not necessarily notified of the ignored request. Hence, it is recommended
that the server disconnect the link in case the client is a malicious device attempting to
mount a security attack.

If the server has no stored CSRK upon receiving a signed write command, it shall
ignore the received Data PDU. Since the server does not respond to a Signed
Write command, the higher layer application is not necessarily notified of the ignored
request. Although the disconnection may be an adequate indication to the user that
the devices need to be paired, it is recommended that implementers consider providing
an explanatory indication to the user that the devices need to be paired to establish a
CSRK.

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 3, Part C Page 1424
Generic Access Profile

If the server receives a request from a client for a write operation that requires
a response (i.e. other than a Signed Write command or Write command), and
encryption is not enabled, then the server shall respond with the error code “Insufficient
Authentication”.

If the link is encrypted and the server receives a request from a client for which the
server requires data signing but does not require encryption, then the server shall
complete the request if it is otherwise valid as the encrypted state of the link is
considered to satisfy the signing requirement.

As required by Section 10.2.2, for a given link, signed data is not used at the same time
as encryption. Therefore, if the client wishes to test that the server is still bonded, and
thus enables encryption, further data transfer must occur without signing, assuming the
server does not disconnect the link as recommended above.

If a higher layer determines the bond no longer exists on the server, the client shall
trigger a user interaction to confirm the remote device and then re-bond, perform
service discovery, and reconfigure the server. If the client had previously determined
that the server did not have the «Service Changed» characteristic, or the client
determines by reading the «Database Hash» characteristic that the database has not
changed, then service discovery may be skipped.

The receiving device shall protect against a replay attack by comparing the received
SignCounter with previously received SignCounter from the same peer device. If the
SignCounter was previously used then the receiving device shall ignore the Data PDU.

10.5 Authorization procedure

A service may require authorization before allowing access. Authorization is a
confirmation by the user to continue with the procedure. Authentication does not
necessarily provide authorization. Authorization may be granted by user confirmation
after successful authentication.

10.6 Encryption procedure

A Central may encrypt a connection using the Encryption Session Setup as defined in
[Vol 3] Part H, Section 2.4.4 to provide integrity and confidentiality.

A Peripheral may encrypt a connection using the Peripheral Initiated Security Request
as defined in [Vol 3] Part H, Section 2.4.6 to provide integrity and confidentiality.

If the encryption procedure fails and either the Central or Peripheral used a Resolvable
Private Address for the connection establishment, then the current Resolvable Private
Address(es) shall be immediately discarded and new Resolvable Private Address(es)
shall be generated.

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 3, Part C Page 1425
Generic Access Profile

10.7 Privacy feature

The privacy feature provides a level of privacy which makes it more difficult for an
attacker to track a device over a period of time. The requirements for a device to
support the privacy feature are defined in Table 10.3.

Privacy Requirements Ref. Broadcaster Observer Peripheral Central

Privacy feature 10.7 O O O O
Non-resolvable private ad- 10.8.2.1 C.2 C.4 O O
dress generation procedure
Resolvable private address 10.8.2.2 C.3 C.5 C.1 C.1
generation procedure
Resolvable private address 10.8.2.3 E O C.1 C.1
resolution procedure
Bondable Mode 9.4.3 E E C.1 C.1
Bonding procedure 9.4.4 E E C.1 C.1
C.1: Mandatory if privacy feature is supported, otherwise optional
C.2: Mandatory if privacy feature is supported and resolvable private address generation procedure
is not supported, otherwise optional
C.3: Mandatory if privacy feature is supported and non-resolvable private address generation proce-
dure is not supported, otherwise optional
C.4: Mandatory if privacy feature and active scanning are supported and resolvable private address
generation procedure is not supported, otherwise optional
C.5: Mandatory if privacy feature and active scanning are supported and non-resolvable private
address generation procedure is not supported, otherwise optional

Table 10.3: Requirements related to privacy feature

Two modes of privacy exist:

• Device Privacy Mode: When a device is in device privacy mode, it is only concerned
about its own privacy. It should accept advertising packets from peer devices that
contain their Identity Addresses as well as their private address, even if the peer
device has distributed its IRK.
• Network Privacy Mode. When a device is in network privacy mode, it shall not
accept advertising packets containing the Identity Address of peer devices that have
distributed their IRK.

Note: If the Resolvable Private Address Only characteristic is not present in the GAP
service of the remote device then it may use its Identity Address over the air.

A device may use different modes for different peers.

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 3, Part C Page 1426
Generic Access Profile

If a device, i.e. Host and Controller, claims support for the privacy feature, the
requirements in this section shall be met.

A device may support either just Host-based privacy or both Host-based and Controller-
based privacy. When a device supports Controller-based privacy, the Host configures
the Controller to perform some of the privacy functionality.

If a device supports Controller-based privacy, the requirements in the following

paragraphs shall be met.

• The Host may maintain a resolving list by adding and removing device identities. A
device identity consists of the peer’s Identity Address and a local and peer’s IRK pair.
The local or peer’s IRK shall be an all-zero key if not applicable for the particular
device identity.
• If a peer device provides an all-zero Identity Address during pairing, the Host shall
choose a unique identifier to substitute the peer’s device Identity Address. The Host
shall ensure that all identities provided to the Controller are unique.
• When address resolution is enabled in the Controller, all references to peer devices
that are included in the resolving list from Host to the Controller shall be done using
the peer’s device Identity Address. Likewise, all incoming events from the Controller
to the Host will use the peer’s device identity, if the peer’s device address has been
resolved.
• If the Host wants to be in device privacy mode, it shall so instruct the Controller for
each peer in the resolving list.

10.7.1 Privacy feature in a Peripheral

The privacy-enabled Peripheral shall use a resolvable private address as the

advertiser's device address when in connectable mode.

A Peripheral shall use non-resolvable or resolvable private addresses when in non-

connectable mode as defined in Section 9.3.2.

If a privacy-enabled Peripheral, that has a stored bond, receives a resolvable private

address, the Host may resolve the resolvable private address by performing the
‘resolvable private address resolution procedure’ as defined in Section 10.8.2.3. If the
resolution is successful, the Host may accept the connection. If the resolution procedure
fails, then the Host shall either accept the connection from the new, unresolved device,
disconnect with the error code "Authentication failure", or perform the pairing procedure,
or perform the authentication procedure as defined in Section 10.3. Accepting the
connection from the new, unresolved device, can result in exposing the device name
or unique data to the Central.

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 3, Part C Page 1427
Generic Access Profile

The device should not send the device name or unique data in the advertising data that
can be used to recognize the device.

10.7.1.1 Privacy feature in a Peripheral with Controller-based privacy

A privacy-enabled Peripheral shall use either the undirected connectable mode as

defined in Section 9.3.4 or directed connectable mode as defined in Section 9.3.3.
The directed connectable mode shall only be used if the peer device supports Address
Resolution in the Controller.

The Host shall enable resolvable private address generation by enabling it in the
Controller and populating the resolving list.

By default, network privacy mode is used when private addresses are resolved and
generated by the Controller.

If the advertising data or the scan response data change regularly then those changes
should be synchronized with any changes in private addresses (both local and remote).
For this purpose, the Host should either instruct the Controller to synchronize address
changes with those data changes or, if the Controller does not support that feature,
generate private addresses as described in Section 10.7.1.2 instead of offloading
private address generation to the Controller.

10.7.1.2 Privacy feature in a Peripheral with Host-based privacy

A privacy-enabled Peripheral should use the undirected connectable mode as defined in

Section 9.3.2, to create a connection.

The Host shall generate a resolvable private address using the ‘resolvable private
address generation procedure’ as defined in Section 10.8.2.2 or non-resolvable private
address procedure as defined in Section 10.8.2.1. The Host shall set a timer equal to
TGAP(private_addr_int). The Host shall generate a new resolvable private address or
non-resolvable private address when the timer TGAP(private_addr_int) expires.

Note: TGAP(private_addr_int) timer need not be run if a Peripheral is not advertising.

10.7.2 Privacy feature in a Central

The privacy-enabled Central shall use a resolvable private address as the initiator's
device address.

During active scanning, a privacy enabled Central shall use a non-resolvable or

resolvable private address.

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 3, Part C Page 1428
Generic Access Profile

If, a privacy-enabled Central, that has a stored bond, receives a resolvable private
address, the Host may resolve the resolvable private address by performing the
"resolvable private address resolution procedure" as defined in Section 10.8.2.3.

10.7.2.1 Privacy feature in a Central with Controller-based privacy

A privacy-enabled Central with Address Resolution enabled in the Controller can use
any of the connection establishment procedures defined in Section 9.3.

By default, network privacy mode is used when private addresses are resolved and
generated by the Controller.

10.7.2.2 Privacy feature in a Central with Host-based privacy

A privacy-enabled Central should use the general connection establishment procedure

defined in Section 9.3.6 to create a connection.

The Host shall generate a resolvable private address using the ‘resolvable private
address generation procedure’ as defined in Section 10.8.2.2 or non-resolvable private
address procedure as defined in Section 10.8.2.1. The Host shall set a timer equal to
TGAP(private_addr_int). The Host shall generate a new resolvable private address or
non-resolvable private address when the timer TGAP(private_addr_int) expires.

Note: TGAP(private_addr_int) timer need not be run if a Central is not scanning or

connected.

10.7.3 Privacy feature in a Broadcaster

A privacy-enabled Broadcaster shall use the Broadcast mode defined in Section 9.1.1.
The Broadcaster shall use either a resolvable private address or non-resolvable private
address.

If Address Resolution is not supported or disabled in the Controller, the following applies
to the Host: The Host shall generate a resolvable private address using the ‘resolvable
private address generation procedure’ as defined in Section 10.8.2.2 or non-resolvable
private address procedure as defined in Section 10.8.2.1. The Host shall set a timer
to TGAP(private_addr_int). The Host shall generate a new resolvable private address or
non-resolvable private address when the timer TGAP(private_addr_int) expires.

Note: TGAP(private_addr_int) timer need not be run if a Broadcaster is not advertising.

The device should not send the device name or unique data in the advertising data
which can be used to recognize the device.

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 3, Part C Page 1429
Generic Access Profile

10.7.4 Privacy feature in an Observer

A privacy-enabled Observer shall use the Observation procedure defined in

Section 9.1.2. During active scanning, a privacy enabled Observer shall use either a
resolvable private address or non-resolvable private address.

If Address Resolution is not supported or disabled in the Controller, the following applies
to the Host: The Host shall generate a resolvable private address using the ‘resolvable
private address generation procedure’ as defined in Section 10.8.2.2 or non-resolvable
private address procedure as defined in Section 10.8.2.1. The Host shall set a timer
equal to TGAP(private_addr_int). The Host shall generate a new resolvable private
address or non-resolvable private address when the timer TGAP(private_addr_int)
expires. The value of TGAP(private_addr_int) shall not be greater than 1 hour.

Note: TGAP(private_addr_int) timer need not be run if an Observer is not scanning.

10.8 Random Device address

For the purposes of this profile, the random device address may be of either of the
following two sub-types:

• Static address
• Private address

The term random device address refers to both static and private address types.

The transmission of a random device address is optional. A device shall accept the
reception of a random device address from a remote device.

The private address may be of either of the following two sub-types:

• Non-resolvable private address

• Resolvable private address

A bonded device shall process a resolvable private address as defined in

Section 10.8.2.3 or by establishing a connection and then performing the authentication
procedure as defined in Section 10.3. A device that generates a resolvable private
address for its local address shall always request to distribute its IRK value as defined
in [Vol 3] Part H, Section 3.6.4 if both sides are bondable, unless keys have been
pre-distributed.

After a device has distributed its IRK, it should use resolvable private addresses when
establishing a connection with a peer device to which the IRK has been distributed.

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 3, Part C Page 1430
Generic Access Profile

10.8.1 Static address

The Host can generate a static address using the procedure described in [Vol 6] Part B,
Section 1.3.2.1.

10.8.2 Private address

The private address may be of either of the following two sub-types:

• Non-resolvable private address

• Resolvable private address

10.8.2.1 Non-Resolvable Private Address Generation procedure

The Host can generate a non resolvable private address using the procedure described
in [Vol 6] Part B, Section 1.3.2.2.

10.8.2.2 Resolvable Private Address Generation procedure

The Host can generate a resolvable private address where the Host has its IRK using
the procedure described in [Vol 6] Part B, Section 1.3.2.2.

10.8.2.3 Resolvable Private Address Resolution procedure

The Host can resolve a resolvable private address where the Host has the peer
device’s IRK or the local device's IRK, using the procedure described in [Vol 6] Part
B, Section 1.3.2.3.

10.9 Encrypted Broadcast Isochronous Group

A device with a service that requires using an unauthenticated encrypted BIG shall set
its security to LE security mode 3 level 2. A device with a service that requires using an
authenticated encrypted BIG shall set its security to LE security mode 3 level 3.

When a user initiates a service that includes broadcasting an encrypted BIG, the Host
shall provide the Broadcast_Code associated with the encrypted BIG to the Controller.

When a user initiates a service that requires the reception of an encrypted BIS, the
device needs to know the Broadcast_Code for that encrypted BIS. If the device does
not have the Broadcast_Code or cannot obtain the Broadcast_Code and has a user
interface, then it shall indicate an appropriate error (e.g., Code Unavailable) to the user.

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 3, Part C Page 1431
Generic Access Profile

10.10 Encrypted Advertising Data procedure

A Broadcaster may encrypt advertising data using an Encrypted Data data type. The
data is encrypted using key material that is known by both devices as defined in Section
1.23.3 of [7].

The key material is exposed using the Encrypted Data Key Material characteristic on
the Broadcaster.

The scanning device shall read the Encrypted Data Key Material characteristic on an
advertising device to obtain the key material for a device if it wants to interpret the
encrypted advertising data being sent.

10.11 LE Channel Sounding

A device with a service that requires using the CS procedure described in Section 9.7
must first encrypt the underlying LE connection as described in [Vol 6] Part B,
Section 4.5.18.2.

10.11.1 Channel Sounding security

Channel Sounding provides the following levels of channel measurement security for
the application layer:

1. Either CS tone or CS RTT

2. 150 ns CS RTT accuracy and CS tones
3. 10 ns CS RTT accuracy and CS tones
4. Level 3 with the addition of CS RTT sounding sequence or random sequence
payloads, and support of the Normalized Attack Detector Metric requirements as
described in [Vol 6] Part H, Section 3.5.1.

A device that operates in security level 1 shall use CS tone or CS RTT within a CS
procedure.

A device that operates in security level 2 shall use 150 ns or better CS RTT accuracy
and CS tones within a CS procedure.

A device that operates in security level 3 shall use 10 ns or better CS RTT accuracy and
CS tones within a CS procedure.

A device that operates in security level 4 shall meet the requirements of security level
3 and shall also require that the CS procedure uses either CS RTT with sounding
sequence or CS RTT with random sequence, and that the device shall also support
the Normalized Attack Detector Metric requirements as described in [Vol 6] Part H,
Section 3.5.1.

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 3, Part C Page 1432
Generic Access Profile

11 ADVERTISING AND SCAN RESPONSE DATA

FORMAT

The format of Advertising, Periodic Advertising, and Scan Response data is shown
in Figure 11.1. The data consists of a significant part and a non-significant part. The
significant part contains a sequence of AD structures. Each AD structure shall have a
Length field of one octet, which contains the Length value and shall not be zero, and
a Data field of Length octets. The first octet of the Data field shall contain the AD type
field. The content of the remaining Length - 1 octets in the Data field depends on the
value of the AD type field and is called the AD data. The non-significant part shall only
be present when necessary to fill a fixed-length field and shall contain all-zero octets.

Data

Significant part Non-significant part

----------
AD Structure 1 AD Structure 2 AD Structure 'N Ob000 ...000

I
- ----------
I
Length octets ---
i Length
1 -·
I
I
Data

I
I 1 octet
I Length - 1 octets

I AD Type IAD Data

Figure 11.1: Advertising and Scan Response data format

Only the significant part of the data should be sent over the air.

The data is sent in advertising or periodic advertising events. Host Advertising data
is placed in the AdvData field of ADV_IND, ADV_NONCONN_IND, ADV_SCAN_IND,
AUX_ADV_IND, and AUX_CHAIN_IND PDUs. Additional Controller Advertising Data is
placed in the ACAD field of AUX_ADV_IND, AUX_SYNC_IND, and AUX_SCAN_RSP
PDUs. Periodic Advertising data is placed in the AdvData field of AUX_SYNC_IND,
AUX_SYNC_SUBEVENT_IND, AUX_SYNC_SUBEVENT_RSP, and AUX_CHAIN_IND
PDUs. Scan Response data is sent in the ScanRspData field of SCAN_RSP PDUs
or the AdvData field of AUX_SCAN_RSP PDUs. If the complete data cannot fit in
the AdvData field of an AUX_ADV_IND, AUX_SYNC_IND, or AUX_SCAN_RSP PDU,

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 3, Part C Page 1433
Generic Access Profile

AUX_CHAIN_IND PDUs are used to send the remaining fragments of the data. In this
case, an AD Structure may be fragmented over two or more PDUs.

The AD type data formats and meanings are defined in Section 1 of [4]. The AD type
identifier values are defined in Assigned Numbers.

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 3, Part C Page 1434
Generic Access Profile

12 GAP SERVICE AND CHARACTERISTICS FOR

GATT SERVER

The GATT Server shall contain the GAP service as defined in the GAP Service
Requirements in Table 12.1. A device shall have only one instance of the GAP service
in the GATT Server. The GAP service shall be a GATT based primary service with the
service UUID as «GAP Service» defined in Assigned Numbers.

BR/EDR GAP LE Broadcaster LE Observer LE Peripheral LE Central

Role
GAP Service C.1 E E M M
C.1: Mandatory for BR/EDR/LE type devices, otherwise optional

Table 12.1: GAP service requirements

The characteristics requirements for the GAP service in each of the GAP roles are
shown in Table 12.2.

Characteristics Ref. BR/EDR LE LE LE LE

GAP Role Broadcaster Observer Peripheral Central
Device Name 12.1 C.1 E E M M
Appearance 12.2 C.1 E E M M
Peripheral Preferred 12.3 O E E O E
Connection Param-
eters
Central Address 12.4 O E E C.3 C.2
Resolution
Resolvable Private 12.5 O E E C.3 C.3
Address Only
Encrypted Data Key 12.6 O E E O E
Material
LE GATT Security 12.7 E E E O O
Levels
C.1: Mandatory for BR/EDR/LE type devices, otherwise optional
C.2: Mandatory if Link Layer privacy is supported, otherwise excluded
C.3: Optional if Link Layer privacy is supported, otherwise excluded

Table 12.2: Requirements related to GAP service characteristics

A device that supports multiple GAP roles contains all the characteristics to meet
the requirements for the supported roles. The device shall continue to expose the

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 3, Part C Page 1435
Generic Access Profile

characteristics when the device is operating in the role in which the characteristics are
not valid.

12.1 Device Name characteristic

The Device Name characteristic shall contain the name of the device as an UTF-8
string as defined in Section 3.2.2. When the device is discoverable, the Device Name
characteristic value shall be readable without authentication or authorization. When the
device is not discoverable, the Device Name Characteristic should not be readable
without authentication or authorization. The Device Name characteristic value may be
writable. If writable, authentication and authorization may be defined by a higher layer
specification or be implementation specific.

Attribute Attribute Type Attribute Attribute Permissions

Handle Value
0xMMMM 0x2A00 – Device Readable without authentication or authorization when
UUID for «De- Name discoverable.
vice Name» Optionally writable, authentication and authorization
may be defined by a higher layer specification or be
implementation specific.

Table 12.3: Device Name characteristic

The Device Name characteristic value shall be 0 to 248 octets in length.

A device shall have only one instance of the Device Name characteristic.

12.2 Appearance characteristic

The Appearance characteristic defines the representation of the external appearance

of the device. This enables the discovering device to represent the device to the user
using an icon, or a string, or similar. The Appearance characteristic value shall be
readable without authentication or authorization. The Appearance characteristic value
may be writable. If writable, authentication and authorization may be defined by a higher
layer specification or be implementation specific.

Attribute Attribute Type Attribute Attribute Permissions

Handle Value
0xMMMM 0x2A01 – Appearance Readable without authentication or authorization.
UUID for «Ap- Optionally writable, authentication and authorization
pearance» may be defined by a higher layer specification or be
implementation specific.

Table 12.4: Appearance characteristic

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 3, Part C Page 1436
Generic Access Profile

The Appearance characteristic value shall be the enumerated value as defined in

Assigned Numbers. The Appearance characteristic value shall be 2 octets in length.
A device shall have only one instance of the Appearance characteristic.

12.3 Peripheral Preferred Connection Parameters characteristic

The Peripheral Preferred Connection Parameters (PPCP) characteristic contains the

preferred connection parameters of the Peripheral.

The Peripheral Preferred Connection Parameters characteristic value shall be readable.

Authentication and authorization may be defined by a higher layer specification or be
implementation specific.

The Peripheral Preferred Connection Parameters characteristic value shall not be

writable.

Attribute Handle Attribute Type Attribute Value Attribute Permissions

0xMMMM 0x2A04 – UUID for Peripheral Preferred Readable, authentication and
«Peripheral Prefer- Connection Param- authorization may be defined by
red Connection Pa- eters a higher layer specification or be
rameters» implementation specific
Not writable

Table 12.5: Peripheral Preferred Connection Parameters characteristic

The Peripheral Preferred Connection Parameters characteristic value shall be 8 octets

in length. A device shall have only one instance of the Peripheral Preferred Connection
Parameters characteristic. The format of the value is specified in Table 12.6.

Name Size
(Octet)
Interval_Min 2
Interval_Max 2
Latency 2
Timeout 2

Table 12.6: Format of the Peripheral Preferred Connection Parameters data

Each field shall have the same meaning and requirements as the field of the
LL_CONNECTION_PARAM_REQ PDU (see [Vol 6] Part B, Section 2.4.2.16) with the
same name, or shall contain the value 0xFFFF which indicates that no specific value is
requested.

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 3, Part C Page 1437
Generic Access Profile

12.4 Central Address Resolution characteristic

The Peripheral should check if the peer device supports address resolution by reading
the Central Address Resolution characteristic before using directed advertisement
where the target address is set to a Resolvable Private Address (RPA).

The Central Address Resolution characteristic defines whether the device supports
privacy with address resolution. See Table 12.7.

Attribute Handle Attribute Type Attribute Value Attribute Permissions

0xMMMM 0x2AA6 - UUID of Central Address Readable without authentication
or authorization.
«Central Address Resolution Support
Not writable.
Resolution»

Table 12.7: Central Address Resolution characteristic

The Central Address Resolution characteristic value shall be 1 octet in length:

0 = address resolution is not supported in this device

1 = address resolution is supported in this device

All other values are reserved for future use.

A device shall have only one instance of the Central Address Resolution characteristic.
If the Central Address Resolution characteristic is not present, then it shall be assumed
that Central Address Resolution is not supported.

12.5 Resolvable Private Address Only characteristic

The device should check if the peer will only use Resolvable Private Addresses (RPAs)
after bonding by reading the Resolvable Private Address Only characteristic, in order to
determine if it will satisfy its privacy mode as defined in Section 10.7.

The Resolvable Private Address Only characteristic defines whether the device will only
use Resolvable Private Addresses (RPAs) as local addresses. See Table 12.8.

Attribute Handle Attribute Type Attribute Value Attribute Permissions

0xMMMM 0x2AC9 - UUID of Resolvable Private Readable without authentication
«Resolvable Private Address Only or authorization.
Address Only» Not writable.

Table 12.8: Resolvable Private Address Only characteristic

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 3, Part C Page 1438
Generic Access Profile

The Resolvable Private Address Only characteristic value shall be 1 octet in length:

0 = only Resolvable Private Addresses will be used as local addresses after

bonding

All other values are reserved for future use.

A device shall have only one instance of the Resolvable Private Address Only
characteristic. If the Resolvable Private Address Only characteristic is not present, then
it cannot be assumed that only Resolvable Private Addresses will be used over the air.

12.6 Encrypted Data Key Material

The Encrypted Data Key Material characteristic allows advertising data associated
with the GAP service to be decrypted and authenticated using the key material. The
Encrypted Data Key characteristic value shall not be writable. The Encrypted Data Key
Material characteristic shall only be readable when authenticated and authorized. When
read, the key material is stored on the local device. The key material may be discarded
at any time on a local device.

The Encrypted Data Key Material characteristic may support indications. If the
characteristic supports indications, the client has configured the characteristic for
indications, and the characteristic value changes after being authenticated and
authorized, then the characteristic shall be indicated by the server to the client.

The Encrypted Data Key Material characteristic can be used by other services to allow
those services to expose separate key material for encrypted advertising data used by
those services.

Attribute Handle Attribute Type Attribute Value Attribute Permissions

0xMMMM 0x2B88 - UUID Key Material Readable when authenticated
for «Encrypted Data and authorized.
Key Material» Indicatable when authenticated
and authorized.
Not writable.

Table 12.9: Encrypted Data Key Material characteristic

The Key Material is composed of a 128-bit value that is used as the session key and a
64-bit value that is used as the IV for encrypting and authenticating the Encrypted Data
as defined in Section 1.23.3 of [4], as shown in Table 12.10. The server should update
the Key Material periodically.

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 3, Part C Page 1439
Generic Access Profile

Field Size (octets) Description

Session Key 16 The shared session key.
IV 8 The initialization vector.

Table 12.10: Key Material format

12.7 LE GATT Security Levels Characteristic

This section specifies the LE GATT Security Levels characteristic.

The LE GATT Security Levels characteristic shall contain the highest security
requirements of the GATT server when operating on a LE connection. The value of
the LE GATT Security Levels characteristic shall be static during a connection.

The format of the LE GATT Security Levels characteristic is given in Table 12.11.

Attribute Handle Attribute Type Attribute Value Attribute Permissions

0xMMMM 0x2BF5 - UUID for Sequence of one or Read Only,
«LE GATT Security more Security Level No Encryption required,
Levels» Requirements
No Authentication,
No Authorization

Table 12.11: LE GATT Security Levels characteristic

The Attribute Value is a sequence of Security Level Requirements, each with the type
uint8[2]. Each Security Level Requirement consists of a Security Mode field followed by
a Security Level field. The Security Mode and Security Level shall be expressed as the
same number as used in their definitions; e.g., mode 1 is represented as 0x01 and level
4 is represented as 0x04.

Meeting any one of the security requirements provided for a given mode shall be
sufficient for the GATT server to allow the GATT client to use all the GATT procedures
permitted by the characteristic properties for all characteristics on the server operating
in that mode. If any one of the security requirements specified in the LE GATT Security
Levels characteristic is met, no GATT procedure will fail for a security-related reason
(such as insufficient authentication). For example, the attribute value 0x01 0x04 for the
LE GATT Security Levels characteristic means that the GATT server requires level 4
when operating in security mode 1 on a LE connection.

Note: The Security Level value is not a minimum; specifying (say) level 2 for a mode
does not mean that level 3, level 4, or even level 87 would suffice instead. However,
in many cases a given security level satisfies the security requirements of other levels
as well. For example, LE security mode 1 levels 3 and 4, by definition, both satisfy the
requirements for mode 1 level 2 and so could be used with a GATT server that requires
mode 1 level 2.

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 3, Part C Page 1440
Generic Access Profile

The security modes and levels for LE are defined in Section 10.

A device shall have at most one instance of a LE GATT Security Levels characteristic.

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 3, Part C Page 1441
Generic Access Profile

13 BR/EDR/LE OPERATION

This section describes the requirements for BR/EDR/LE implementations. The

implementation may support any LE GAP roles allowed by the Controller over the LE
physical channel. The requirements for each role are defined in Section 9.

Feature Ref. Broadcaster Observer Peripheral Central

BR/EDR/LE modes and procedures 13.1 and O O O O
13.2

Table 13.1: Requirements for the modes of BR/EDR/LE implementations

13.1 Modes, procedures, and security aspects

All modes, procedures and security aspects shall follow the requirements as specified
for the physical transport over which they operate. Sections 4, 5, 6 and 7 specify the
requirements for the modes, procedures and security aspects for operations performed
over the BR/EDR physical transport. Sections 9 and 9.6 specify the requirements for the
modes, procedures and security aspects performed over the LE physical transport. It is
optional to support both physical transports simultaneously to the same remote device.

13.1.1 Discoverable mode requirements

A device shall expose the capabilities of both physical transports for both Limited and
General Discoverable Mode using the advertisement Flag AD Type as follows:

a. The ‘BR/EDR Not Supported’ bit in the Flags AD type shall be set to 0 as defined in
Section 1.3 of [4].
b. The 'Simultaneous LE and BR/EDR to Same Device Capable (Controller)' bit in the
Flags AD type shall be set to 0.

The ‘LE Supported (Controller)’ and ‘LE Supported (Host)’ bits in the LMP features shall
be set as defined in [Vol 2] Part C, Section 3.2.

13.2 Bonding for BR/EDR/LE implementations

The requirements for BR/EDR/LE implementations are shown in Table 13.2.

Bonding Requirement Ref. Peripheral Central

Bonding 6.5 / 9.4.4 O O

Table 13.2: Requirements for the bonding of BR/EDR/LE implementations

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 3, Part C Page 1442
Generic Access Profile

If the remote device supports the BR/EDR physical transport, the bonding procedures
for the BR/EDR physical transport as defined in Section 6.5 shall be used.

If the remote device supports the LE physical transport, the bonding procedures for the
LE physical transport as defined in Section 9.4.4 shall be used.

13.3 Relationship between physical transports

To determine if both the BR/EDR physical transport and the LE physical transport are
established to the same peer device, the device shall use either the public address used
on the LE advertising physical channel or the public address from the BD_ADDR field
contained in the SMP Identity Address Information packet ([Vol 3] Part H, Section 3.6.5)
if it has been received.

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 3, Part C Page 1443
Generic Access Profile

14 BR/EDR/LE SECURITY ASPECTS

The requirements for BR/EDR/LE implementations are shown in Table 14.1.

Security aspects Ref. Peripheral Central

Security aspects 14 M M
Table 14.1: Requirements for the security aspects of BR/EDR/LE implementations

If the remote device supports the BR/EDR physical transport the security procedures for
the BR/EDR physical transport as defined in Section 5 shall be used.

If the remote device supports the LE physical transport the security procedures for the
LE physical transport as defined in Section 9.6 shall be used.

If the LE transport in a BR/EDR/LE device supports Secure Connections, the security

procedures in Section 14.1 may also be used.

14.1 Cross-transport key derivation

If both the local and remote devices support Secure Connections over the BR/EDR and
LE transports, devices may optionally generate keys of identical strength and the same
MITM protection for both transports as part of a single pairing procedure (see [Vol 3]
Part H, Section 2.3.5.7).

If both the local and remote devices support Secure Connections over the LE transport
but not over the BR/EDR transport, then the devices may optionally generate the
BR/EDR keys of identical strength and the same MITM protection as the LE keys as
part of the LE pairing procedure (see [Vol 3] Part H, Section 2.3.5.7).

If an LE LTK already exists and the BR/EDR link key is weaker in either strength or
MITM protection, then neither device shall generate an LE LTK using cross-transport
key derivation from a BR/EDR link key. If either device receives a request to generate
an LE LTK using cross-transport key derivation, it shall respond with a Pairing Failed
message with reason "Cross-transport Key Derivation/Generation not allowed".

If the BR/EDR link key has been generated by a Controller that does not perform
remote public key validation (see [Vol 2] Part H, Section 7.6), then the local device shall
not generate an LE LTK using cross-transport key derivation from a BR/EDR link key.
If the local device receives a request to generate an LE LTK using cross-transport key
derivation, it shall respond with a Pairing Failed message with reason "Cross-transport
Key Derivation/Generation not allowed".

If a BR/EDR link key already exists and the LE LTK is weaker in either strength or
MITM protection, then the local device shall not generate a BR/EDR link key using

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 3, Part C Page 1444
Generic Access Profile

cross-transport key derivation from the LE LTK. If both devices request cross-transport
key derivation during pairing, then the local device shall either silently skip deriving the
BR/EDR link key or stop the pairing procedure by sending a Pairing Failed message
with reason "Cross-transport Key Derivation/Generation not allowed".

Note: The Host can use the HCI_Read_Local_Simple_Pairing_Options command (see

[Vol 4] Part E, Section 7.4.9) or vendor-specific methods to determine whether the
Controller performs remote public key validation.

If the LE LTK has been generated (e.g., using the HCI_LE_Generate_DHKey

command; see [Vol 4] Part E, Section 7.8.37) by a Controller that does not perform
remote public key validation (see [Vol 3] Part H, Section 2.3.5.6.1), then the BR/EDR
link key shall not be generated from such an LE LTK using cross-transport key
derivation.

Note: The Host can use the Remote Public Key Validation feature bit (see [Vol
6] Part B, Section 4.6) or vendor-specific methods to determine whether the
HCI_LE_Generate_DHKey command performs the remote public key validation.

14.2 Collision handling

If pairing has been initiated by the local device on the BR/EDR transport, and a pairing
request is received from the same remote device on the LE transport, the LE pairing
shall be rejected with SMP error code BR/EDR Pairing in Progress (0x0D) if both sides
support LE Secure Connections.

If a BR/EDR/LE device supports LE Secure Connections, then it shall initiate pairing on

only one transport at a time to the same remote device.

14.3 Secure Connections Only Mode

If a BR/EDR/LE device is in Secure Connections Only Mode, then this mode applies
to both transports and the requirements in both Section 5.2.2 and Section 10.2.4 shall
apply.

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 3, Part C Page 1445
Generic Access Profile

15 BLUETOOTH DEVICE REQUIREMENTS

15.1 Bluetooth Device address

All Bluetooth devices shall have a Bluetooth Device Address (BD_ADDR) that uniquely
identifies the device to another Bluetooth device. The specific Bluetooth Device Address
requirements depend on the type of Bluetooth device.

15.1.1 Bluetooth Device Address types

15.1.1.1 Public Bluetooth address

A Bluetooth public address used as the BD_ADDR for the BR/EDR physical channel is
defined in [Vol 2] Part B, Section 1.2. A Bluetooth public address used as the BD_ADDR
for the LE physical channel is defined in [Vol 6] Part B, Section 1.3.

15.1.1.2 Random Bluetooth address

A random device address used as the BD_ADDR on the LE physical channel is defined
in Section 10.8.

15.2 GATT Profile requirements

The requirements for supporting a GATT Client or GATT Server are specified in
Table 15.1.

BR/EDR LE LE LE LE
GAP Role Broadcaster Observer Peripheral Central
GATT Client O E E O O
GATT Server C.1 E E M M
C.1: Mandatory if the GATT Profile is supported on the BR/EDR physical transport; otherwise
excluded

Table 15.1: Requirements based on GAP roles supported

15.3 SDP requirements

The requirements for supporting an SDP Client or SDP Server are specified in
Table 15.2. There shall be no more than one active SDP Server per device.

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 3, Part C Page 1446
Generic Access Profile

BR/EDR-Only and BR/EDR/LE LE-Only

Implementations Implementations
SDP Client C.1 E
SDP Server C.2 E
C.1: Optional if SDP Server is supported, otherwise mandatory.
C.2: Mandatory to support if GATT Server is supported, otherwise optional.

Table 15.2: Requirements based on GAP roles supported

15.4 SDP service record requirement

A BR/EDR or BR/EDR/LE device that supports a GATT Server accessible over the
BR/EDR physical transport and that supports only one of ATT or EATT shall publish the
SDP record shown below in Table 15.3; if both ATT and EATT are supported, the device
shall publish the SDP record shown below in Table 15.4. The GAP Service Start Handle
shall be set to the attribute handle of the «GAP Service» service declaration. The GAP
Service End Handle shall be set to the attribute handle of the last attribute within the
«GAP Service» service definition group.

Item Type Value Meaning

Attribute ID uint16 0x0001 ServiceClassIDList
Attribute Value Data element sequence (1 item)
Service Class UUID «GAP Service»
Attribute ID uint16 0x0004 ProtocolDescriptorList
Attribute Value Data element sequence (2 items)
Protocol Descriptor Data element sequence (2 items)
Protocol UUID «L2CAP»
Parameter 0 uint16 0x001F PSM = ATT
or 0x0027 or PSM = EATT
Protocol Descriptor Data element sequence (3 items)
Protocol UUID «ATT»
Parameter 0 uint16 0xHHHH GAP service start handle
Parameter 1 uint16 0xHHHH GAP service end handle
Attribute ID uint16 0x0005 BrowseGroupList
Attribute Value Data element sequence (1 item)
Group UUID «PublicBrowseRoot»

Table 15.3: SDP record for the Generic Access Profile, if only one of ATT or EATT is supported

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 3, Part C Page 1447
Generic Access Profile

Item Type Value Meaning

Attribute ID uint16 0x0001 ServiceClassIDList
Attribute Value Data element sequence (1 item)
Service class UUID «GAP Service»
Attribute ID uint16 0x0004 ProtocolDescriptorList
Attribute Value Data element sequence (2 items)
Protocol Descriptor Data element sequence (2 items)
Protocol UUID «L2CAP»
Parameter 0 uint16 0x001F PSM = ATT
Protocol Descriptor Data element sequence (3 items)
Protocol UUID «ATT»
Parameter 0 uint16 0xHHHH GAP service start handle
Parameter 1 uint16 0xHHHH GAP service end handle
Attribute ID uint16 0x000D AdditionalProtocolDescriptorLists
Attribute Value Data element sequence (1 item)
Protocol Descriptor List Data element sequence (2 items)
Protocol Descriptor Data element sequence (2 items)
Protocol UUID «L2CAP»
Parameter 0 uint16 0x0027 PSM = EATT
Protocol Descriptor Data element sequence (3 items)
Protocol UUID «ATT»
Parameter 0 uint16 0xHHHH GAP service start handle
Parameter 1 uint16 0xHHHH GAP service end handle
Attribute ID uint16 0x0005 BrowseGroupList
Attribute Value Data element sequence (1 item)
Group UUID «PublicBrowseRoot»

Table 15.4: SDP record for the Generic Access Profile, if both ATT and EATT are supported

If a BR/EDR or BR/EDR/LE device supports a GATT-based service on the BR/EDR

transport, the service shall exist in the SDP Server and the GATT Server.

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 3, Part C Page 1448
Generic Access Profile

16 DEFINITIONS

In the following, terms written with capital letters refer to states.

Most definitions in this section are BR/EDR specific.

16.1 General definitions

Mode: A set of directives that defines how a device will respond to certain events.

Idle: As seen from a remote device, a Bluetooth device is idle, or is in idle mode, when
there is no link established between them.

Bond: A relation between two Bluetooth devices defined by creating, exchanging and
storing a common link key. The bond is created through the bonding or LMP-pairing
procedures.

16.2 Connection-related definitions

Physical channel: See [Vol 2] Part B, Section 2.1.

Piconet: A set of Bluetooth devices sharing the same physical channel defined by the
Central's parameters (clock and BD_ADDR).

Physical link: A Baseband-level connection1 between two devices established using

paging. A physical link comprises a sequence of transmission slots on a physical
channel alternating between Central and Peripheral transmission slots.

ACL link: An asynchronous (packet-switched) connection1 between two devices

created on LMP level. Traffic on an ACL link uses ACL packets to be transmitted.

SCO link: A synchronous (circuit-switched) connection1 for reserved bandwidth

communications; e.g. voice between two devices, created on the LMP level by reserving
slots periodically on a physical channel. Traffic on a SCO link uses SCO packets to
be transmitted. SCO links can be established only after an ACL link has first been
established.

Link: Shorthand for an ACL link.

PAGE: A Baseband state where a device transmits page trains, and processes any
eventual responses to the page trains.

1The term ’connection’ used here is not identical to the definition below. It is used in the absence of a more

concise term.

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 3, Part C Page 1449
Generic Access Profile

PAGE_SCAN: A Baseband state where a device listens for page trains.

Page: The transmission by a device of page trains containing the Device Access Code
of the device to which the physical link is requested.

Page scan: The listening by a device for page trains containing its own Device Access
Code.

Channel: A logical connection on L2CAP level between two devices serving a single
application or higher layer protocol.

Connection: A connection between two peer applications or higher layer protocols

mapped onto a channel.

Connecting: A phase in the communication between devices when a connection

between them is being established. (Connecting phase follows after the link
establishment phase is completed.)

Connect (to service): The establishment of a connection to a service. If not already

done, this includes establishment of a physical link, link and channel as well.

16.3 Device-related definitions

Discoverable device: A Bluetooth device in range that will respond to an inquiry
(normally in addition to responding to page).

Silent device: A Bluetooth device appears as silent to a remote device if it does not
respond to inquiries made by the remote device. A device may be silent due to being
non-discoverable or due to baseband congestion while being discoverable.

Connectable device: Bluetooth device in range that will respond to a page.

Trusted device: A paired device that is explicitly marked as trusted.

Paired device: A Bluetooth device with which a link key has been exchanged (either
before connection establishment was requested or during connecting phase).

Pre-paired device: A Bluetooth device with which a link key was exchanged, and the
link key is stored, before link establishment.

Un-paired device: A Bluetooth device for which there was no exchanged link key
available before connection establishment was requested.

Known device: A Bluetooth device for which at least the BD_ADDR is stored.

Un-known device: Bluetooth device for which no information (BD_ADDR, link key or
other) is stored.

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 3, Part C Page 1450
Generic Access Profile

Authenticated device: A Bluetooth device whose identity has been verified during the
lifetime of the current link, based on the authentication procedure.

16.4 Procedure-related definitions

Paging: A procedure for establishing a physical link of ACL type on Baseband level,
consisting of a page action of the initiator and a page scan action of the responding
device.

Link establishment: A procedure for establishing a link on LMP level. A link is

established when both devices have agreed that LMP setup is completed.

Channel establishment: A procedure for establishing a channel on L2CAP level.

Connection establishment: A procedure for creating a connection mapped onto a

channel.

Creation of a trusted relationship: A procedure where the remote device is marked as

a trusted device. This includes storing a common link key for future authentication and
pairing (if the link key is not available).

Creation of a secure connection: A procedure of establishing a connection, including

authentication and encryption.

Device discovery: A procedure for retrieving the Bluetooth Device Address, clock, and
Class of Device from discoverable devices.

Name discovery: A procedure for retrieving the user-friendly name (the Bluetooth
Device Name) of a connectable device.

Service discovery: Procedures for querying and browsing for services offered by or
through another Bluetooth device.

16.5 Security-related definitions

Authentication: A generic procedure based on LMP-authentication if a link key exists
or on LMP-pairing if no link key exists.

LMP-authentication: An LMP level procedure for verifying the identity of a remote

device. The procedure is based on a challenge-response mechanism using a random
number, a secret key and the BD_ADDR of the non-initiating device. The secret key
used can be a previously exchanged link key.

Authorization: A procedure where a user of a Bluetooth device grants a specific

(remote) Bluetooth device access to a specific service. Authorization implies that the
identity of the remote device can be verified through authentication.

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 3, Part C Page 1451
Generic Access Profile

Authorize: The act of granting a specific Bluetooth device access to a specific service.
It may be based upon user confirmation, or given the existence of a trusted relationship.

LMP-pairing: A procedure that authenticates two devices, based on a PIN, and

subsequently creates a common link key that can be used as a basis for a trusted
relationship or a (single) secure connection. The procedure consists of the steps:
creation of an initialization key (based on a random number and a PIN), creation and
exchange of a common link key and LMP-authentication based on the common link key.

Bonding: A dedicated procedure for performing the first authentication, where a

common link key is created and stored for future use.

Trusting: The marking of a paired device as trusted. Trust marking can be done by the
user, or automatically by the device (e.g. when in bondable mode) after a successful
pairing.

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 3, Part C Page 1452
Generic Access Profile

17 REFERENCES

[1] RFCOMM
[2] Telephony Control Specification
[3] Assigned Numbers Specification: https://www.bluetooth.com/specifications/
assigned-numbers
[4] Core Specification Supplement, Part A, Data Types Specification
[5] Core Specification Supplement, Part C, Services Permitted to use Security Mode
4 Level 0

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 3, Part C Page 1453
Generic Access Profile

Appendix A Timers and Constants

The following timers are required by this profile.

Timer name Value Description Requirement or

Recommendation
TGAP(100) 10.24 s Time span that a Bluetooth device per- Recommended value
forms device discovery
TGAP(101) 10.625 A discoverable Bluetooth device en- Required value
ms ters INQUIRY_SCAN for at least
TGAP(101) every TGAP(102)
TGAP(102) 2.56 s Maximum time between repeated IN- Recommended value
QUIRY_SCAN enterings when power
consumption or bandwidth is more im-
portant than discovery speed
TGAP(103) 30.72 s Minimum time span that a device is in Required value
discoverable mode
TGAP(104) 1 min Maximum time span that a device is in Recommended value
limited discoverable mode
TGAP(105) 100 ms Maximum time between INQUI- Recommended value
RY_SCAN enterings when discovery
speed is more important than power
consumption or bandwidth
TGAP(106) 100 ms Maximum time between PAGE_SCAN Recommended value
enterings when connection speed is
more important than power consump-
tion or bandwidth
TGAP(107) 1.28 s Maximum time between PAGE_SCAN Recommended value
enterings (R1 page scan) when power
consumption or bandwidth is more im-
portant than connection speed
TGAP(108) 2.56 s Maximum time between PAGE_SCAN Recommended value
enterings (R2 page scan) when power
consumption or bandwidth is more im-
portant than connection speed

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 3, Part C Page 1454
Generic Access Profile

Timer name Value Description Requirement or

Recommendation
TGAP(adv_fast_- 90 ms to Minimum to maximum advertising in- Recommended value
interval1_coded) 180 ms terval in the following GAP Modes on
the LE Coded PHY when user initi-
ated:
1. Undirected Connectable Mode
2. Limited Discoverable Mode and
sending connectable undirected
advertising events
3. General Discoverable Mode and
sending connectable undirected
advertising events
4. Directed Connectable Mode and
sending low duty cycle connecta-
ble directed advertising events
TGAP(adv_fast_- 30 ms to Minimum to maximum advertising in- Recommended value
interval1) 60 ms terval in the following GAP Modes on
the LE 1M PHY when user initiated:
1. Undirected Connectable Mode
2. Limited Discoverable Mode and
sending connectable undirected
advertising events
3. General Discoverable Mode and
sending connectable undirected
advertising events
4. Directed Connectable Mode and
sending low duty cycle directed
advertising events
TGAP(adv_fast_- 300 ms Minimum to maximum advertising in- Recommended value
interval2_coded) to 450 terval in the following GAP Modes on
ms the LE Coded PHY when user initi-
ated and sending non-connectable ad-
vertising events:
1. Non-Discoverable Mode
2. Non-Connectable Mode
3. Limited Discoverable Mode
4. General Discoverable Mode

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 3, Part C Page 1455
Generic Access Profile

Timer name Value Description Requirement or

Recommendation
TGAP(adv_fast_- 100 ms Minimum to maximum advertising in- Recommended value
interval2) to 150 terval in the following GAP Modes on
ms the LE 1M PHY when user initiated
and sending non-connectable adver-
tising events:
1. Non-Discoverable Mode
2. Non-Connectable Mode
3. Limited Discoverable Mode
4. General Discoverable Mode
TGAP(adv_fast_period) 30 s Minimum time to perform advertising Recommended value
when user initiated
TGAP(adv_slow_- 3 s to Minimum to maximum advertisement Recommended value
interval_coded) 3.6 s interval in any discoverable or con-
nectable mode when background ad-
vertising on the LE Coded PHY
TGAP(adv_slow_- 1 s to Minimum to maximum advertisement Recommended value
interval) 1.2 s interval in any discoverable or con-
nectable mode when background ad-
vertising on the LE 1M PHY
TGAP(conn_param_- 30 s Connection parameter update notifica- Recommended value
timeout) tion timer when performing the con-
nection parameter update procedure
TGAP(conn_pause_- 1s Central idle timer Recommended value
central)
TGAP(conn_pause_- 5s Minimum time upon connection estab- Recommended value
peripheral) lishment before the Peripheral starts a
connection update procedure
TGAP(gen_disc_scan_- 30.72 s Minimum time to perform scanning Recommended value
min_coded) when performing the general discov-
ery procedure on the LE Coded PHY
TGAP(gen_disc_- 10.24 s Minimum time to perform scanning Recommended value
scan_min) when performing the general discov-
ery procedure on the LE 1M PHY
TGAP(initial_conn_- 90 ms to Minimum to maximum connection in- Recommended value
interval_coded) 150 ms terval upon any connection establish-
ment on the LE Coded PHY
TGAP(initial_conn_- 30 ms to Minimum to maximum connection in- Recommended value
interval) 50 ms terval upon any connection establish-
ment on the LE 1M PHY
TGAP(lim_adv_timeout) 180 s Maximum time to remain advertising Required value
when in the limited discoverable mode

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 3, Part C Page 1456
Generic Access Profile

Timer name Value Description Requirement or

Recommendation
TGAP(lim_disc_scan_- 33.75 Scan interval used in the limited dis- Recommended value
int_coded) ms covery procedure on the LE Coded
PHY
TGAP(lim_disc_scan_- 11.25 Scan interval used in the limited dis- Recommended value
int) ms covery procedure on the LE 1M PHY
TGAP(lim_disc_scan_- 30.72 s Minimum time to perform scanning Recommended value
min_coded) when performing the limited discovery
procedure on the LE Coded PHY
TGAP(lim_disc_scan_- 10.24 s Minimum time to perform scanning Recommended value
min) when performing the limited discovery
procedure on the LE 1M PHY
TGAP(private_addr_int) 15 min Maximum time interval between pri- Recommended value
vate address change
TGAP 90 ms to Scan interval in any discovery or con- Recommended value
(scan_fast_interval_- 180 ms nection establishment procedure when
coded user initiated on the LE Coded PHY
TGAP(scan_fast_- 30 ms to Scan interval in any discovery or con- Recommended value
interval) 60 ms nection establishment procedure when
user initiated on the LE 1M PHY
TGAP(scan_fast_- 30.72 s Minimum time to perform scanning Recommended value
period) when user initiated
TGAP(scan_fast_- 90 ms Scan window in any discovery or con- Recommended value
window_coded) nection establishment procedure when
user initiated on the LE Coded PHY
TGAP(scan_fast_- 30 ms Scan window in any discovery or con- Recommended value
window) nection establishment procedure when
user initiated on the LE 1M PHY
TGAP(scan_slow_- 3.84 s Scan interval in any discovery or con- Recommended value
interval1_coded) nection establishment procedure when
background scanning on the LE Co-
ded PHY
TGAP(scan_slow_- 1.28 s Scan interval in any discovery or con- Recommended value
interval1) nection establishment procedure when
background scanning on the LE 1M
PHY
TGAP(scan_slow_- 7.68 s Scan interval in any discovery or con- Recommended value
interval2_coded) nection establishment procedure when
background scanning on the LE Co-
ded PHY

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 3, Part C Page 1457
Generic Access Profile

Timer name Value Description Requirement or

Recommendation
TGAP(scan_slow_- 2.56 s Scan interval in any discovery or con- Recommended value
interval2) nection establishment procedure when
background scanning on the LE 1M
PHY
TGAP(scan_slow_- 33.75 Scan window in any discovery or con- Recommended value
window1_coded) ms nection establishment procedure when
background scanning on the LE Co-
ded PHY
TGAP(scan_slow_- 11.25 Scan window in any discovery or con- Recommended value
window1) ms nection establishment procedure when
background scanning on the LE 1M
PHY
TGAP(scan_slow_- 67.5 ms Scan window in any discovery or con- Recommended value
window2_coded) nection establishment procedure when
background scanning on the LE Co-
ded PHY
TGAP(scan_slow_- 22.5 ms Scan window in any discovery or con- Recommended value
window2) nection establishment procedure when
background scanning on the LE 1M
PHY
TGAP(Sync_Scan_- 320 ms Interval between the start of adjacent Recommended value
Interval) synchronization scan windows
TGAP(Sync_Scan_- 91.25 Duration of Synchronization scan win- Recommended value
Window) ms dow
TGAP(Sync_Train_- 30.72 s Duration of synchronizability mode Required value
Duration)
TGAP(Sync_Train_- 80 ms Interval between Synchronization Recommended value
Interval) Train events

Table A.1: Defined GAP timers

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 3, Part C Page 1458
Generic Access Profile

Appendix B Information Flows of Related

Procedures

B.1 LMP – authentication

Authentication at the link level is specified in [Vol 2] Part C, Section 4.2.1.

Verifier
(initiator) Claimant

init_authentication

secret key (link key or Kinit) secret key (link key or Kinit)

Generate
random
number

LMP_AU_RAND

Calculate Calculate
challenge response
(random
number)

LMP_SRES

Compare

result (ok or fail)

Figure B.1: LMP authentication

The secret key used here is an already exchanged link key.

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 3, Part C Page 1459
Generic Access Profile

B.2 LMP – pairing

Pairing at the link level is specified in [Vol 2] Part C, Section 4.2.2.

Verifier
(initiator) Claimant

init_pairing

Generate
random
number

LMP_IN_RAND

LMP_ACCEPTED

PIN PIN

Calculate Calculate
Kinit Kinit

Create link key

LMP authentication

Link Key Link Key

Figure B.2: LMP pairing

The PIN used here is PINBB.

The create link key procedure is described in [Vol 2] Part C, Section 4.2.2.4 and [Vol
2] Part H, Section 3.2. A mutual authentication takes place irrespective of the current
security mode.

B.3 Service Discovery

The Service Discovery Protocol specifies what PDUs are used over-the-air to inquire
about services and service attributes. The procedures for discovery of supported

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 3, Part C Page 1460
Generic Access Profile

services and capabilities using the Service Discovery Protocol are described in higher
layer specifications. This is just an example.

A B

initiate service discovery make connectable

Link establishment

Channel establishment

service discovery session

Channel release

LMP_DETACH

Figure B.3: Service Discovery procedure

B.4 Generating a resolvable private address

Generating a resolvable private address is described in Section 10.8.2.2.

B.5 Resolving a resolvable private address

Resolving a resolvable private address is described in Section 10.8.2.3.

Bluetooth SIG Proprietary Version Date: 2024-08-27

 Host
Part D

TEST SUPPORT

Bluetooth SIG Proprietary

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 3, Part D Page 1462
Test Support

CONTENTS

1 Test methodology ................................................................................... 1463

1.1 BR/EDR test scenarios .............................................................. 1463
1.1.1 Test setup .................................................................. 1463
1.1.2 Transmitter test .......................................................... 1464
1.1.2.1 Packet format ............................................. 1464
1.1.2.2 Pseudorandom sequence .......................... 1466
1.1.2.3 Control of transmit parameters ................... 1467
1.1.2.4 Power control ............................................. 1467
1.1.2.5 Switch between different frequency
settings ....................................................... 1467
1.1.2.6 Adaptive Frequency Hopping ..................... 1468
1.1.3 LoopBack test ............................................................ 1468
1.1.4 Pause test .................................................................. 1472
1.2 [This section is no longer used] ................................................. 1472
1.3 References ................................................................................ 1472

2 [This section is no longer used] ............................................................ 1473

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 3, Part D Page 1463
Test Support

1 TEST METHODOLOGY

This section describes the test modes for hardware and low-level functionality tests of
Bluetooth devices.

The BR/EDR Test mode supports testing of the Bluetooth transmitter and receiver
including transmitter tests (packets with constant bit patterns) and loopback tests. It
is intended mainly for testing of the radio and Baseband and may also be used for
in-production and after-sales testing.

1.1 BR/EDR test scenarios

A device in BR/EDR Test mode shall not support normal operation. For security reasons
the BR/EDR Test mode is designed such that it offers no benefit to the user. Therefore,
no data output or acceptance on a HW or SW interface shall be allowed.

1.1.1 Test setup

The setup consists of an implementation under test (IUT) and a tester. Optionally,
additional measurement equipment may be used.

Cont rol commands

J\ ►
Test data Implementation
Tester ◄ ►
Under Test
----·----1
i Additional 1 1'
1 Measurement I
1 Equipment I__ J Local activation/enabling
I (optional) J
L _______ _

Figure 1.1: Setup for Test mode

Tester and IUT form a piconet where the tester acts as Central and has full control over
the test procedure. The IUT acts as Peripheral.

The control is done via the air interface using LMP commands (see [Vol 2] Part
C, Section 4.7.3). Hardware interfaces to the IUT may exist, but are not subject to
standardization.

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 3, Part D Page 1464
Test Support

The test mode is a special state of the Bluetooth model. For security and type approval
reasons, a Bluetooth device in test mode shall not support normal operation. When
the IUT leaves the test mode it enters the standby state. After power-off the Bluetooth
device shall return to the standby state.

1.1.2 Transmitter test

The Bluetooth device transmits a constant bit pattern. This pattern is transmitted
periodically with packets aligned to the Peripheral TX timing of the piconet formed by
tester and IUT. The same test packet is repeated for each transmission.

The transmitter test is started when the Central sends the first POLL packet. In non-
hopping mode the agreed frequency is used for this POLL packet.

The tester (Central) transmits control or POLL packets in the Central-to-Peripheral

transmission slots. The IUT (Peripheral) shall transmit packets in the following
Peripheral-to-Central transmission slot. The tester’s polling interval is fixed and defined
by the LMP_TEST_CONTROL PDU. The implementation under test may transmit its
burst according to the normal timing even if no packet from the tester was received. In
this case, the ARQN bit is shall be set to NAK.

The burst length may exceed the length of a one slot packet. In this case the tester may
take the next free Central TX slot for polling. The timing is illustrated in Figure 1.2.

Burst Length Burst Length

POLL POLL

Test packet Test packet

time
Central TX Peripheral TX Central TX Peripheral TX Central TX Peripheral TX

Figure 1.2: Timing for transmitter test

1.1.2.1 Packet format

The test packet is a normal Bluetooth packet, see Figure 1.3. For the payload itself see
below.

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 3, Part D Page 1465
Test Support

Packet
Access Code Payload
Header

ACL Packet Guard &Sync Payload

Test Payload CRC
(with CRC) (EDR only) Header

Payload
AUX1 Packet Test Payload
Header

SCO Packet Test Payload

Guard &Sync
eSCO Packet Test Payload CRC
(EDR only)

Figure 1.3: General format of TX packet

During configuration the tester defines:

• the packet type to be used

• payload length

For the payload length, the restrictions from the Baseband specification shall apply
(see [Vol 2] Part B, Section 6.5). In case of ACL, SCO and eSCO packets the payload
structure defined in the Baseband specification is preserved as well, see Figure 1.3.

For the transmitter test mode, only packets without FEC should be used; i.e. HV3, EV3,
EV5, DH1, DH3, DH5, 2-EV3, 2-EV5, 3-EV3, 3-EV5, 2-DH1, 2-DH3, 2-DH5, 3-DH1,
3-DH3, 3-DH5 and AUX1 packets.

In transmitter test mode, the packets exchanged between the tester and the IUT shall
not be scrambled with the whitening sequence. Whitening shall be turned off when the
IUT has accepted to enter the transmitter test mode, and shall be turned on when the
IUT has accepted to exit the transmitter test mode, see Figure 1.4. Implementations
shall ensure that retransmissions of the LMP_ACCEPTED messages use the same
whitening status as used in the original LMP_ACCEPTED.

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 3, Part D Page 1466
Test Support

TESTER IUT

LMP_TEST_CONTROL
(Enter Transmitter Test mode)

Whitening on
LMP_ACCEPTED

LMP_TEST_CONTROL
(Exit Transmitter Test mode) Whitening off

LMP_ACCEPTED

Whitening on

Figure 1.4: Use of whitening in Transmitter mode

1.1.2.2 Pseudorandom sequence

The same pseudorandom sequence of bits shall be used for each transmission (i.e. the
packet is repeated). A PRBS9 sequence is used, see [1] and [2].

The properties of this sequence are as follows (see [2]). The sequence may be
generated in a nine-stage shift register whose 5th and 9th stage outputs are XORed
(see Figure 1.5), and the result is fed back to the input of the first stage. The sequence
begins with the first ONE of 9 consecutive ONEs; i.e. the shift register is initialized with
nine ones.

• Number of shift register stages: 9

• Length of pseudo-random sequence: 29-1 = 511 bits
• Longest sequence of zeros: 8 (non-inverted signal)

Figure 1.5: Linear feedback shift register for generation of the PRBS sequence

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 3, Part D Page 1467
Test Support

1.1.2.3 Control of transmit parameters

The following parameters can be set to configure the transmitter test:

1. Bit pattern:
• Constant zero
• Constant one
• Alternating 1010...1
• Alternating 1111 0000 1111 0000...1
• Pseudorandom bit pattern
• Transmission off
2. Frequency selection:
• Single frequency
• Normal hopping
3. TX frequency
• (2402 + k) MHz for channel k
4. Default poll period in TDD frames (n × 1.25 ms)
5. Packet Type
6. Length of test payload

1.1.2.4 Power control

When the legacy power control mechanism is tested the IUT shall start transmitting
at the maximum power and shall reduce/increase its power by one step on every
LMP_INCR_POWER_REQ or LMP_DECR_POWER_REQ PDU received. When the
enhanced power control mechanism is tested the IUT shall start transmitting at the
maximum power and shall reduce/increase its power by one step or go to the maximum
power level when a LMP_POWER_CONTROL_REQ PDU is received.

1.1.2.5 Switch between different frequency settings

A change in the frequency selection becomes effective when the LMP procedure is
completed:

When the tester receives the LMP_ACCEPTED it shall then transmit POLL packets
containing the ACK for at least 8 slots (4 transmissions). When these transmissions

1It is recommended that the sequence starts with a one; but, as this is irrelevant for measurements, it is also

allowed to start with a zero.

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 3, Part D Page 1468
Test Support

have been completed the tester shall change to the new frequency hop and whitening
settings.

After sending LMP_ACCEPTED the IUT shall wait for the LC level ACK for the
LMP_ACCEPTED. When this is received it shall change to the new frequency hop and
whitening settings.

There will be an implementation defined delay after sending the LMP_ACCEPTED

before the TX or loopback test starts. Testers shall be able to cope with this.

Note: Loss of the LMP_ACCEPTED PDU will eventually lead to a loss of frequency
synchronization that cannot be recovered. Similar problems occur in normal operation,
when the hopping pattern changes.

1.1.2.6 Adaptive Frequency Hopping

Adaptive Frequency Hopping (AFH) shall only be used when the Hopping Mode is set
to 79 channels (e.g., Hopping Mode = 1) in the LMP_TEST_CONTROL PDU. If AFH is
used, the normal LMP commands and procedures shall be used. When AFH is enabled
prior to entering test mode it shall continue to be used with the same parameters if
Hopping Mode = 1 until the AFH parameters are changed by the LMP_SET_AFH PDU.

The channel classification reporting state shall be retained upon entering

or exiting Test Mode. The IUT shall change the channel classification
reporting state in Test Mode based on control messages from the
tester (e.g., LMP_CHANNEL_CLASSIFICATION_REQ) and from the Host
(HCI_Write_AFH_Channel_Assessment_Mode).

1.1.3 LoopBack test

In loopback, the implementation under test receives normal Baseband packets

containing payload Accepted from the tester. The received packets shall be decoded
in the IUT, and the payload shall be sent back using the same packet type. The return
packet shall be sent back in either the Peripheral-to-Central transmission slot directly
following the transmission of the tester, or it is delayed and sent back in the Peripheral-
to-Central transmission slot after the next transmission of the tester (see Figure 1.7 to
Figure 1.9).

There is no signaling to determine or control the mode. The device behavior shall be
fixed or adjusted by other means, and shall not change randomly.

The tester can select whether whitening is on or off. This setting holds for both uplink
and downlink. For switching the whitening status, the same rules as in Section 1.1.2
(Figure 1.4) shall apply.

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 3, Part D Page 1469
Test Support

The following rules apply (for illustration see Figure 1.6):

• If the synch word was not detected, the IUT shall not reply.
• If the header error check (HEC) fails, the IUT shall either reply with a NULL packet
with the ARQN bit set to NAK or send nothing.
• If the packet contains an LMP message relating to the control of the test mode this
command shall be executed and the packet shall not be returned, though ACK or
NAK shall be returned as per the usual procedure. Other LMP commands shall be
ignored and no packet returned.
• The payload FEC is decoded and the payload shall be encoded again for
transmission. This allows testing of the FEC handling. If the pure bit error rate shall be
determined the tester chooses a packet type without FEC.
• The CRC shall be evaluated. In the case of a failure, ARQN=NAK shall be returned.
The payload shall be returned as received.
A new CRC for the return packet shall be calculated for the returned payload
regardless of whether the CRC was valid or not.
• If the CRC fails for a packet with a CRC and a payload header, the number of bytes
as indicated in the (possibly erroneous) payload header shall be looped back.

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 3, Part D Page 1470
Test Support

Receive Path: Synch found

Decode Header

faili
HEC

o.k.
Packet type Build NULL
without FEC + ARQN = NAK
Payload:
decode FEC
Send

Packet type
without CRC fail
CRC

o.k.

ARQN = ACK ARQN = NAK

LMP message fail

LLID CRC
other o.k.

Take payload Execute Discard

as decoded LMP command packet

Transmit Path:

Packet type
without FEC Code FEC

Packet type
Add CRC
without CRC

Build packet
(incl. ARQN)

Send

Figure 1.6: IUT packet handling in loopback test

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 3, Part D Page 1471
Test Support

The timing for normal and delayed loopback is illustrated in Figure 1.7 to Figure 1.9:

RX packet TX packet RX packet TX packet RX packet TX packet

Figure 1.7: Payload and ARQN handling in normal loopback

Figure 1.8: Payload and ARQN handling in delayed loopback – start

Figure 1.9: Payload and ARQN handling in delayed loopback – end

The whitening is performed in the same way as it is used in normal Active mode.

The following parameters can be set to configure the loop back test:

1. Packet Class1 ACL packets

SCO packets
eSCO packets
ACL packets without whitening
SCO packets without whitening
eSCO packets without whitening

1This is included because the packet type numbering is ambiguous.

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 3, Part D Page 1472
Test Support

2. Frequency Selection
Single frequency (independent for RX and TX)
Normal hopping
3. Power level: (To be used according radio specification requirements)
power control or fixed TX power

The switch of the frequency setting is done exactly as for the transmitter test (see
Section 1.1.2.5).

1.1.4 Pause test

Pause test is used by testers to put the implementation under test into Pause Test mode
from either the loopback or transmitter test modes.

When an LMP_TEST_CONTROL PDU that specifies Pause Test is received the IUT
shall stop the current test and enter Pause Test mode. In the case of a transmitter test
this means that no more packets shall be transmitted. While in Pause Test mode the
IUT shall respond normally to POLL packets (i.e. responds with a NULL packet). The
IUT shall also respond normally to all the LMP packets that are allowed in test mode.

When the test scenario is set to Pause Test all the other fields in the
LMP_TEST_CONTROL PDU shall be ignored. There shall be no change in hopping
scheme or whitening as a result of a request to pause test.

1.2 [This section is no longer used]

1.3 References

[1] CCITT Recommendation O.153 (1992), Basic parameters for the measurement
of error performance at bit rates below the primary rate.
[2] ITU-T Recommendation O.150 (1996), General requirements for instrumentation
for performance measurements on digital transmission equipment.

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 3, Part D Page 1473
Test Support

2 [THIS SECTION IS NO LONGER USED]

Bluetooth SIG Proprietary Version Date: 2024-08-27

 Host
Part E

[THIS PART IS NO LONGER

USED]

Bluetooth SIG Proprietary

 Host
Part F

ATTRIBUTE PROTOCOL
(ATT)

This Part defines the Attribute Protocol; a protocol

for discovering, reading, and writing attributes on a
peer device

Bluetooth SIG Proprietary

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 3, Part F Page 1476
Attribute Protocol (ATT)

CONTENTS

1 Introduction ............................................................................................. 1478

1.1 Scope ........................................................................................ 1478
1.2 [This section is no longer used] ................................................. 1478
1.3 Conventions .............................................................................. 1478

2 Protocol overview ................................................................................... 1479

3 Protocol requirements ............................................................................ 1481

3.1 Introduction ............................................................................... 1481
3.2 Basic concepts .......................................................................... 1481
3.2.1 Attribute type .............................................................. 1481
3.2.2 Attribute handle ......................................................... 1481
3.2.3 Attribute handle grouping .......................................... 1482
3.2.4 Attribute value ............................................................ 1482
3.2.5 Attribute permissions ................................................. 1482
3.2.6 Control-point attributes .............................................. 1484
3.2.7 Protocol methods ....................................................... 1484
3.2.8 Exchanging MTU size ................................................ 1484
3.2.9 Long attribute values ................................................. 1485
3.2.10 Atomic operations ...................................................... 1485
3.2.11 ATT bearers ............................................................... 1486
3.3 Attribute PDU ............................................................................ 1486
3.3.1 Attribute PDU format .................................................. 1488
3.3.2 Sequential protocol .................................................... 1489
3.3.3 Transaction ................................................................ 1490
3.4 Attribute Protocol PDUs ............................................................ 1490
3.4.1 Error handling ............................................................ 1490
3.4.1.1 ATT_ERROR_RSP .................................... 1490
3.4.2 MTU exchange .......................................................... 1493
3.4.2.1 ATT_EXCHANGE_MTU_REQ ................... 1493
3.4.2.2 ATT_EXCHANGE_MTU_RSP ................... 1493
3.4.3 Find information ......................................................... 1495
3.4.3.1 ATT_FIND_INFORMATION_REQ ............. 1495
3.4.3.2 ATT_FIND_INFORMATION_RSP .............. 1495
3.4.3.3 ATT_FIND_BY_TYPE_VALUE_REQ ......... 1496
3.4.3.4 ATT_FIND_BY_TYPE_VALUE_RSP ......... 1498
3.4.4 Reading attributes ..................................................... 1499
3.4.4.1 ATT_READ_BY_TYPE_REQ ..................... 1499
3.4.4.2 ATT_READ_BY_TYPE_RSP ..................... 1501
3.4.4.3 ATT_READ_REQ ....................................... 1502

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 3, Part F Page 1477
Attribute Protocol (ATT)

3.4.4.4 ATT_READ_RSP ....................................... 1502

3.4.4.5 ATT_READ_BLOB_REQ ........................... 1503
3.4.4.6 ATT_READ_BLOB_RSP ............................ 1504
3.4.4.7 ATT_READ_MULTIPLE_REQ ................... 1505
3.4.4.8 ATT_READ_MULTIPLE_RSP .................... 1506
3.4.4.9 ATT_READ_BY_GROUP_TYPE_REQ ..... 1506
3.4.4.10 ATT_READ_BY_GROUP_TYPE_RSP ...... 1509
3.4.4.11 ATT_READ_MULTIPLE_VARIABLE_REQ 1510
3.4.4.12 ATT_READ_MULTIPLE_VARIABLE_RSP . 1511
3.4.5 Writing attributes ........................................................ 1511
3.4.5.1 ATT_WRITE_REQ ..................................... 1511
3.4.5.2 ATT_WRITE_RSP ...................................... 1513
3.4.5.3 ATT_WRITE_CMD ..................................... 1513
3.4.5.4 ATT_SIGNED_WRITE_CMD ..................... 1514
3.4.6 Queued writes ............................................................ 1515
3.4.6.1 ATT_PREPARE_WRITE_REQ .................. 1516
3.4.6.2 ATT_PREPARE_WRITE_RSP ................... 1518
3.4.6.3 ATT_EXECUTE_WRITE_REQ .................. 1518
3.4.6.4 ATT_EXECUTE_WRITE_RSP ................... 1519
3.4.7 Server initiated ........................................................... 1519
3.4.7.1 ATT_HANDLE_VALUE_NTF ..................... 1519
3.4.7.2 ATT_HANDLE_VALUE_IND ...................... 1520
3.4.7.3 ATT_HANDLE_VALUE_CFM ..................... 1521
3.4.7.4 ATT_MULTIPLE_HANDLE_VALUE_NTF .. 1521
3.4.8 Attribute Opcode summary ........................................ 1521
3.4.9 Attribute PDU response summary ............................. 1523

4 Security considerations ......................................................................... 1529

5 References .............................................................................................. 1531

Appendix A Changes to PDU names ................................................................ 1532

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 3, Part F Page 1478
Attribute Protocol (ATT)

1 INTRODUCTION

1.1 Scope
The Attribute Protocol allows a device referred to as the server to expose a set of
attributes and their associated values to a peer device referred to as the client. These
attributes exposed by the server can be discovered, read, and written by a client, and
can be indicated and notified by the server.

1.2 [This section is no longer used]

1.3 Conventions
In this Part PDU names appear in italics. Error codes defined in Table 3.4 (see
Section 3.4.1.1) appear in italics followed by the numeric code (e.g. Attribute Not Found
(0x0A)). Other names such as parameters appear in Roman text.

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 3, Part F Page 1479
Attribute Protocol (ATT)

2 PROTOCOL OVERVIEW

The Attribute Protocol defines two roles; a server role and a client role. It allows a server
to expose a set of attributes to a client that are accessible using the Attribute Protocol.

An attribute is a discrete value that has the following three properties associated with it:

a. attribute type, defined by a UUID

b. attribute handle
c. a set of permissions that are defined by each higher layer specification that utilizes
the attribute; these permissions cannot be accessed using the Attribute Protocol.

The attribute type specifies what the attribute represents. Bluetooth SIG defined
attribute types are defined in Assigned Numbers and used by an associated higher
layer specification. Non-Bluetooth SIG attribute types may also be defined.

The attribute handle uniquely identifies an attribute on a server, allowing a client to

reference the attribute in read or write requests; see Section 3.4.4, Section 3.4.5,
and Section 3.4.6. It allows a client to uniquely identify the attribute being notified or
indicated, see Section 3.4.7. Clients are able to discover the handles of the server’s
attributes; see Section 3.4.3. Permissions may be applied to an attribute to prevent
applications from obtaining or altering an attribute’s value. An attribute may be defined
by a higher layer specification to be readable or writable or both, and may have
additional security requirements. For more information, see Section 3.2.5.

A client may send Attribute Protocol requests to a server, and the server shall respond
to all requests that it receives. A device can implement both client and server roles,
and both roles can function concurrently in the same device and between the same
devices. There shall be only one instance of a server on each Bluetooth device; this
implies that the attribute handles shall be identical for all supported bearers. For a given
client, the server shall have one set of attributes, which shall have the same value and
properties irrespective of which bearer is used. The server can support multiple clients.
The attribute values can be the same or different for each client as defined by GATT or
a higher layer specification.

Note: Multiple services may be exposed on a single server by allocating separate

ranges of handles for each service. The discovery of these handle ranges is defined by
a higher layer specification.

The Attribute Protocol has notification and indication capabilities that provide an efficient
way of sending attribute values to a client without the need for them to be read; see
Section 3.3.

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 3, Part F Page 1480
Attribute Protocol (ATT)

All Attribute Protocol requests are sent over an ATT bearer. There can be multiple ATT
bearers established between two devices. Each ATT bearer uses a separate L2CAP
channel and can have a different configuration.

In LE, there is a single ATT bearer that uses a fixed channel that is available as soon
as the ACL connection is established. Additional ATT bearers can be established using
L2CAP (see Section 3.2.11).

In BR/EDR, one or more ATT bearers can be established using L2CAP (see
Section 3.2.11).

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 3, Part F Page 1481
Attribute Protocol (ATT)

3 PROTOCOL REQUIREMENTS

3.1 Introduction

Each attribute has an attribute type that identifies, by means of a UUID (Universally
Unique IDentifier), what the attribute represents so that a client can understand the
attributes exposed by a server. Each attribute has an attribute handle that is used for
accessing the attribute on a server, as well as an attribute value.

An attribute value is accessed using its attribute handle. The attribute handles are
discovered by a client using Attribute Protocol PDUs (Protocol Data Unit). Attributes that
have the same attribute type may exist more than once in a server. Attributes also have
a set of permissions that controls whether they can be read or written, or whether the
attribute value shall be sent over an encrypted link. Security aspects of the Attribute
Protocol are defined in Section 4.

3.2 Basic concepts

3.2.1 Attribute type

A universally unique identifier (UUID) is used to identify every attribute type. A UUID is
considered unique over all space and time. A UUID can be independently created by
anybody and distributed or published as required. There is no central registry for UUIDs,
as they are based off a unique identifier that is not duplicated. The Attribute Protocol
allows devices to identify attribute types using UUIDs regardless of the local handle
used to identify them in a read or write request.

Universal unique identifiers are defined in SDP [Vol 3] Part B, Section 2.5.1.

All 32-bit Attribute UUIDs shall be converted to 128-bit UUIDs when the Attribute UUID
is contained in an ATT PDU.

3.2.2 Attribute handle

An attribute handle is a 16-bit value that is assigned by each server to its own attributes
to allow a client to reference those attributes. An attribute handle shall not be reused
while an ATT bearer exists between a client and its server.

Attribute handles on any given server shall have unique, non-zero values. Attributes are
ordered by attribute handle.

An attribute handle of value 0x0000 is reserved for future use. An attribute handle of
value 0xFFFF is known as the maximum attribute handle.

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 3, Part F Page 1482
Attribute Protocol (ATT)

Note: Attributes can be added or removed while an ATT bearer is established; however,
an attribute that has been removed cannot be replaced by another attribute with the
same handle while any ATT bearer is established.

3.2.3 Attribute handle grouping

Grouping is defined by a specific attribute placed at the beginning of a range of other

attributes that are grouped with that attribute, as defined by a higher layer specification.
Clients can request the first and last handles associated with a group of attributes.

3.2.4 Attribute value

An attribute value is an octet array that may be either fixed or variable length. For
example, it can be a one octet value, or a four octet integer, or a variable length string.
An attribute may contain a value that is too large to transmit in a single PDU and can be
sent using multiple PDUs. The values that are transmitted are opaque to the Attribute
Protocol. The encoding of these octet arrays is defined by the attribute type.

When transmitting attribute values in a request, a response, a notification or an

indication, the attribute value length is not sent in any field of the majority of PDUs.
The length of a variable length field in those PDUs is implicitly given by the length of the
packet that carries this PDU. This implies that:

• Only one attribute value can be placed in a single request, response, notification
or indication unless the attribute values have lengths known by both the server and
client, as defined by the attribute type.
• This attribute value will always be the only variable length field of a request,
response, notification or indication.
• The bearer protocol (e.g. L2CAP) preserves datagram boundaries.

Note: Some responses include multiple attribute values, for example when client
requests multiple attribute reads. For the client to determine the attribute value
boundaries, the attribute values must have a fixed size defined by the attribute type.

There are some PDUs where the length of attribute values is included as a field within
the PDU and therefore the above implications do not apply to these PDUs.

3.2.5 Attribute permissions

An attribute has a set of permission values associated with it. The permissions
associated with an attribute specifies that it may be read and/or written. The
permissions associated with the attribute specifies the security level required for read
and/or write access, as well as notification and/or indication. The permissions of a given
attribute are defined by a higher layer specification, and are not discoverable using the
Attribute Protocol.

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 3, Part F Page 1483
Attribute Protocol (ATT)

If access to a secure attribute requires an authenticated link, and the client

is not already authenticated with the server with sufficient security, then an
ATT_ERROR_RSP PDU shall be sent with the Error Code parameter set to Insufficient
Authentication (0x05). When a client receives this error code it may try to authenticate
the link, and if the authentication is successful, it can then access the secure attribute.

If access to a secure attribute requires an encrypted link, and the link is not encrypted,
then an ATT_ERROR_RSP PDU shall be sent with the Error Code parameter set to
Insufficient Encryption (0x0F). When a client receives this error code it may try to
encrypt the link and if the encryption is successful, it can then access the secure
attribute.

If access to a secure attribute requires an encrypted link, and the link is encrypted but
with an encryption key size that is too short for the level of security required, then an
ATT_ERROR_RSP PDU shall be sent with the Error Code parameter set to Encryption
Key Size Too Short (0x0C). When a client receives this error code it may try to encrypt
the link with a longer key size, and if the encryption is successful, it can then access the
secure attribute.

Attribute permissions are a combination of access permissions, encryption permissions,

authentication permissions and authorization permissions.

The following access permissions are possible:

• Readable
• Writeable
• Readable and writable

The following encryption permissions are possible:

• Encryption required
• No encryption required

The following authentication permissions are possible:

• Authentication Required
• No Authentication Required

The following authorization permissions are possible:

• Authorization Required
• No Authorization Required

Encryption, authentication, and authorization permissions can have different

possibilities; for example, a specific attribute could require a particular kind of

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 3, Part F Page 1484
Attribute Protocol (ATT)

authentication or a certain minimum encryption key length. An attribute can have

several combinations of permissions that apply; for example, a specific attribute could
allow any of the following:

• Read if encrypted (authentication not required)

• Write if authenticated and encrypted
• Read or write if authenticated and authorized (irrespective of encryption)

Access permissions are used by a server to determine if a client can read and/or write
an attribute value.

Authentication permissions are used by a server to determine if an authenticated

physical link is required when a client attempts to access an attribute. Authentication
permissions are also used by a server to determine if an authenticated physical link is
required before sending a notification or indication to a client.

Authorization permissions determine if a client needs to be authorized before accessing

an attribute value.

Different bearers for the same client may be on links with different security properties.
Therefore, the server must not assume that when a client has been authenticated on
the link carrying one bearer, it has been authenticated on all bearers. The different
security properties might have other implications that an implementation needs to take
into account.

3.2.6 Control-point attributes

Attributes that cannot be read, but can only be written, notified or indicated are called
control-point attributes. These control-point attributes can be used by higher layers
to enable device specific procedures, for example the writing of a command or the
indication when a given procedure on a device has completed.

3.2.7 Protocol methods

The Attribute Protocol uses methods defined in Section 3.4 to find, read, write,
notify, and indicate attributes. A method is categorized as either a command, a
request, a response, a notification, an indication, or a confirmation; see Section 3.3.
Some Attribute Protocol PDUs can also include an Authentication Signature, to allow
authentication of the originator of this PDU without requiring encryption. The method
and signed bit are known as the opcode.

3.2.8 Exchanging MTU size

ATT_MTU is defined as the maximum size of any packet sent between a client and a
server. A higher layer specification defines the default ATT_MTU value.

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 3, Part F Page 1485
Attribute Protocol (ATT)

When using an L2CAP channel with a fixed CID, the client and server may
optionally exchange the maximum size of a packet that can be received using the
ATT_EXCHANGE_MTU_REQ and ATT_EXCHANGE_MTU_RSP PDUs. Both devices
then use the minimum of these exchanged values for all further communication (see
Section 3.4.2). A device that is acting as a server and client at the same time shall use
the same value for Client Rx MTU and Server Rx MTU.

When using an L2CAP channel with a dynamically allocated CID, the ATT_MTU shall
be set to the L2CAP MTU size.

The ATT_MTU value is a per ATT bearer value. A device with multiple ATT bearers may
have a different ATT_MTU value for each ATT bearer.

3.2.9 Long attribute values

The longest attribute that can be sent in a single packet is (ATT_MTU-1) octets in size.
At a minimum, the Attribute Opcode is included in an Attribute PDU.

An attribute value may be defined to be larger than (ATT_MTU-1) octets in size. These
attributes are called long attributes.

To read the entire value of an attributes larger than (ATT_MTU-1) octets, the
ATT_READ_BLOB_REQ PDU is used. It is possible to read the first (ATT_MTU-1)
octets of a long attribute value using the ATT_READ_REQ PDU.

To write the entire value of an attribute larger than (ATT_MTU-3) octets, the
ATT_PREPARE_WRITE_REQ and ATT_EXECUTE_WRITE_REQ PDUs are used. It
is possible to write the first (ATT_MTU-3) octets of a long attribute value using the
ATT_WRITE_CMD PDU.

It is not possible to determine if an attribute value is longer than (ATT_MTU-3) octets

using this protocol. A higher layer specification will state that a given attribute can have
a maximum length larger than (ATT_MTU-3) octets.

The maximum length of an attribute value shall be 512 octets.

Note: The protection of an attribute value changing when reading the value using
multiple Attribute Protocol PDUs is the responsibility of the higher layer.

3.2.10 Atomic operations

The server shall treat each request or command as an atomic operation that cannot be
affected by another ATT bearer sending a request or command at the same time. If an
ATT bearer is terminated for any reason (user action or loss of the radio link), the value
of any modified attribute is the responsibility of the higher layer specification.

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 3, Part F Page 1486
Attribute Protocol (ATT)

Long attributes cannot be read or written in a single atomic operation.

3.2.11 ATT bearers

An ATT bearer is a channel used to send Attribute Protocol PDUs. Each ATT bearer
uses an L2CAP channel which shall be either a dynamically allocated channel or the
LE Attribute Protocol fixed channel (see [Vol 3] Part A, Section 2.1). A device may have
any number of dynamically allocated channels and at most one fixed channel as ATT
bearers to a peer device.

An ATT bearer connects an ATT Client on one device to an ATT Server on the peer
device and may also connect an ATT Server on the first device to an ATT Client on the
peer device. Whether a received Attribute PDU is intended for the ATT Client or for the
ATT Server is determined by the PDU type (see Section 3.3).

The L2CAP channel mode determines the behavior of Attribute Protocol on that ATT
bearer. If the L2CAP channel mode is using Enhanced Credit Based Flow Control
mode or (on BR/EDR) Enhanced Retransmission mode, the ATT bearer is known as an
Enhanced ATT bearer. Any ATT bearer that is not an Enhanced ATT bearer, using any
other L2CAP channel mode, is known as an Unenhanced ATT bearer.

Except where explicitly stated, the behavior of an Enhanced ATT bearer that uses
Enhanced Credit Based Flow Control mode shall be identical to the behavior of an ATT
bearer that does not use Enhanced Credit Based Flow Control mode.

An ATT bearer is terminated when either the L2CAP channel (if dynamically allocated)
or the underlying physical link is disconnected.

An LE fixed channel can only be terminated by disconnecting the physical link.

A higher-layer specification may require an Enhanced ATT bearer.

A device that supports L2CAP over multiple logical transports may, subject to any
other requirements in this specification, support ATT bearers on some or all of those
transports.

3.3 Attribute PDU

Attribute PDUs have one of six types, which are indicated by the suffix to the PDU name
as shown in Table 3.1:

Type Purpose Suffix

Commands PDUs sent to a server by a client that do not invoke a response. CMD
Requests PDUs sent to a server by a client that invoke a response. REQ

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 3, Part F Page 1487
Attribute Protocol (ATT)

Type Purpose Suffix

Responses PDUs sent to a client by a server in response to a request. RSP
Notifications Unsolicited PDUs sent to a client by a server that do not invoke a confirma- NTF
tion.
Indications Unsolicited PDUs sent to a client by a server that invoke a confirmation. IND
Confirmations PDUs sent to a server by a client to confirm receipt of an indication. CFM

Table 3.1: Attribute PDUs

A server shall be able to receive and properly respond to the following request PDUs:

• ATT_FIND_INFORMATION_REQ
• ATT_READ_REQ

Support for all other PDU types in a server can be specified in a higher layer
specification, see Section 3.4.8.

If a client sends a request, then the client shall support all possible response PDUs for
that request.

If a server receives a request that it does not support, then the server shall respond
with the ATT_ERROR_RSP PDU with the Error Code parameter set to Request Not
Supported (0x06), with the Attribute Handle In Error set to 0x0000.

If a server receives a command that it does not support, indicated by the Command
Flag of the PDU set to one, then the server shall ignore the command.

If the server receives an invalid request – for example, the PDU is the wrong length
– then the server shall respond with the ATT_ERROR_RSP PDU with the Error Code
parameter set to Invalid PDU (0x04), with the Attribute Handle In Error set to 0x0000.

If a server does not have sufficient resources to process a request, then the server
shall respond with the ATT_ERROR_RSP PDU with the Error Code parameter set to
Insufficient Resources (0x11), with the Attribute Handle In Error set to 0x0000.

If a server cannot process a request because an error was encountered during the
processing of this request, then the server shall respond with the ATT_ERROR_RSP
PDU with the Error Code parameter set to Unlikely Error (0x0E), with the Attribute
Handle In Error set to 0x0000.

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 3, Part F Page 1488
Attribute Protocol (ATT)

3.3.1 Attribute PDU format

Attribute PDUs have the following format:

Name Size (octets) Description

Attribute Op- 1 The attribute PDU operation code
code bit 7: Authentication Signature Flag
bit 6: Command Flag
bits 5-0: Method
Attribute Pa- 0 to (ATT_MTU The attribute PDU parameters
rameters - X) X = 1 if Authentication Signature Flag of the Attribute Opcode is
0
X = 13 if Authentication Signature Flag of the Attribute Opcode is
1
Authentication 0 or 12 Optional authentication signature for the Attribute Opcode and
Signature Attribute Parameters

Table 3.2: Format of attribute PDU

Multi-octet fields within the Attribute Protocol shall be sent least significant octet first
(little-endian) with the exception of the Attribute Value field. The endian-ness of the
Attribute Value field is defined by a higher layer specification.

The Attribute Opcode is composed of three fields, the Authentication Signature Flag, the
Command Flag, and the Method. The Method is a 6-bit value that determines the format
and meaning of the Attribute Parameters.

If the Authentication Signature Flag of the Attribute Opcode is set to one, the
Authentication Signature value shall be appended to the end of the attribute PDU, and
X is 13. If the Authentication Signature Flag of the Attribute Opcode is set to zero, the
Authentication Signature value shall not be appended, and X is 1.

The Authentication Signature field is calculated as defined in Security Manager (see

[Vol 3] Part H, Section 2.4.5). This value provides an Authentication Signature for the
variable length message (m) consisting of the following values in this order: Attribute
Opcode, Attribute Parameters.

An Attribute PDU that includes an Authentication Signature should not be sent on an

encrypted link.

Note: An encrypted link already includes authentication data on every packet and
therefore adding more authentication data is not required.

If the Command Flag of the Attribute Opcode is set to one, the PDU shall be considered
to be a command.

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 3, Part F Page 1489
Attribute Protocol (ATT)

Only the ATT_WRITE_CMD PDU may include an Authentication Signature (and

therefore becomes an ATT_SIGNED_WRITE_CMD PDU).

3.3.2 Sequential protocol

Many Attribute Protocol PDUs use a sequential request-response protocol.

Once a client sends a request to a server, that client shall send no other request to the
same server on the same ATT bearer until a response PDU has been received.

Indications sent from a server also use a sequential indication-confirmation protocol.

No other indications shall be sent to the same client from this server on the same ATT
bearer until a confirmation PDU has been received. The client, however, is free to send
commands and requests prior to sending a confirmation.

For notifications, which do not have a response PDU, there is no flow control and a
notification can be sent at any time.

For commands, which do not have a response PDU, there is no flow control and a
command can be sent at any time.

Note: A server can be flooded with commands, and a higher layer specification can
define how to prevent this from occurring.

Commands that are received but cannot be processed, due to buffer overflows or
a change-unaware client (see [Vol 3] Part G, Section 2.5.2.1), shall be discarded.
Therefore, those PDUs must be considered to be unreliable.

On an Unenhanced ATT bearer, notifications that are received but cannot be processed
due to buffer overflows shall be discarded. Therefore, those PDUs must be considered
to be unreliable.

On an Enhanced ATT bearer, notifications shall always be processed when received.

Note: Flow control for each client and a server is independent.

Note: It is possible for a server to receive a request, send one or more notifications, and
then the response to the original request. The flow control of requests is not affected by
the transmission of the notifications.

Note: It is possible for a server to receive a request and then a command before
responding to the original request. The flow control of requests is not affected by the
transmission of commands.

Note: It is possible for a notification from a server to be sent after an indication has been
sent but the confirmation has not been received. The flow control of indications is not
affected by the transmission of notifications.

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 3, Part F Page 1490
Attribute Protocol (ATT)

Note: It is possible for a client to receive an indication from a server and then send
a request or command to that server before sending the confirmation of the original
indication.

3.3.3 Transaction

An Attribute Protocol request and response or indication-confirmation pair is considered

a single transaction. A transaction shall always be performed on one ATT bearer, and
shall not be split over multiple ATT bearers.

On the client, a transaction shall start when the request is sent by the client. A
transaction shall complete when the response is received by the client.

On a server, a transaction shall start when a request is received by the server. A

transaction shall complete when the response is sent by the server.

On a server, a transaction shall start when an indication is sent by the server. A

transaction shall complete when the confirmation is received by the server.

On a client, a transaction shall start when an indication is received by the client. A

transaction shall complete when the confirmation is sent by the client.

A transaction not completed within 30 seconds shall time out. Such a transaction shall
be considered to have failed and the local higher layers shall be informed of this failure.
No more Attribute Protocol requests, commands, indications or notifications shall be
sent to the target device on this ATT bearer.

To send another Attribute Protocol PDU, a new ATT bearer must be established
between these devices. The existing ATT bearer may need to be terminated before
the new ATT bearer is established.

If the ATT bearer is terminated during a transaction, then the transaction shall be
considered to be closed, and any values that were being modified on the server will be
in an undetermined state.

Note: Each ATT_PREPARE_WRITE_REQ and each ATT_READ_BLOB_REQ PDU

starts a separate request and therefore a separate transaction.

3.4 Attribute Protocol PDUs

3.4.1 Error handling

3.4.1.1 ATT_ERROR_RSP

The ATT_ERROR_RSP PDU is used to state that a given request cannot be performed,
and to provide the reason.

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 3, Part F Page 1491
Attribute Protocol (ATT)

Note: Commands (i.e. the ATT_WRITE_CMD and ATT_SIGNED_WRITE_CMD PDUs)

do not generate this response.

Parameter Size (octets) Description

Attribute Opcode 1 0x01 = ATT_ERROR_RSP PDU
Request Opcode In Error 1 The request that generated this ATT_ERROR_RSP PDU
Attribute Handle In Error 2 The attribute handle that generated this ATT_ER-
ROR_RSP PDU
Error Code 1 The reason why the request has generated an ATT_ER-
ROR_RSP PDU

Table 3.3: Format of the ATT_ERROR_RSP PDU

The Request Opcode In Error parameter shall be set to the Attribute Opcode of the
request that generated this error.

The Attribute Handle In Error parameter shall be set to the attribute handle in the
original request that generated this error. If there was no attribute handle in the original
request or if the request is not supported, then the value 0x0000 shall be used for this
field.

The Error Code parameter shall be set to one of the following values:

Name Error Description

Code
Invalid Handle 0x01 The attribute handle given was not valid on this server.
Read Not Permitted 0x02 The attribute cannot be read.
Write Not Permitted 0x03 The attribute cannot be written.
Invalid PDU 0x04 The attribute PDU was invalid.
Insufficient Authenti- 0x05 The attribute requires authentication before it can be read or
cation written.
Request Not Suppor- 0x06 ATT Server does not support the request received from the cli-
ted ent.
Invalid Offset 0x07 Offset specified was past the end of the attribute.
Insufficient Authoriza- 0x08 The attribute requires authorization before it can be read or writ-
tion ten.
Prepare Queue Full 0x09 Too many prepare writes have been queued.
Attribute Not Found 0x0A No attribute found within the given attribute handle range.
Attribute Not Long 0x0B The attribute cannot be read using the ATT_READ_BLOB_REQ
PDU.

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 3, Part F Page 1492
Attribute Protocol (ATT)

Name Error Description

Code
Encryption Key Size 0x0C The Encryption Key Size used for encrypting this link is too short.
Too Short1
Invalid Attribute Value 0x0D The attribute value length is invalid for the operation.
Length
Unlikely Error 0x0E The attribute request that was requested has encountered an
error that was unlikely, and therefore could not be completed as
requested.
Insufficient Encryption 0x0F The attribute requires encryption before it can be read or written.
Unsupported Group 0x10 The attribute type is not a supported grouping attribute as de-
Type fined by a higher layer specification.
Insufficient Resources 0x11 Insufficient Resources to complete the request.
Database Out Of Sync 0x12 The server requests the client to rediscover the database.
Value Not Allowed 0x13 The attribute parameter value was not allowed.
Application Error 0x80 – Application error code defined by a higher layer specification.
0x9F
Common Profile and 0xE0 – Common profile and service error codes defined in [1]
Service Error Codes 0xFF
Reserved for future All other Reserved for future use.
use values

Table 3.4: Error codes

1This was previously "Insufficient Encryption Key Size".

The Error Code values listed in Section 3.4.2 to Section 3.4.8 are not necessarily the
only ones permitted in response to those PDUs. See Section 3.4.9 for the definitive list
of which Error Code values are permitted.

If more than one error code applies, then it is vendor-specific which error code is
transmitted in the ATT_ERROR_RSP PDU.

If an error code is received in the ATT_ERROR_RSP PDU that is not understood by the
client, for example an error code that was reserved for future use that is now being used
in a future version of the specification, then the ATT_ERROR_RSP PDU shall still be
considered to state that the given request cannot be performed for an unknown reason.

Note: Sending an ATT_ERROR_RSP PDU should not cause the ATT Server to
disconnect from the client. The client may upgrade the security and retry the request, so
the server should give the client sufficient time to perform such an upgrade.

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 3, Part F Page 1493
Attribute Protocol (ATT)

3.4.2 MTU exchange

3.4.2.1 ATT_EXCHANGE_MTU_REQ

The ATT_EXCHANGE_MTU_REQ PDU is used by the client to inform the server of the
client’s maximum receive MTU size and request the server to respond with its maximum
receive MTU size.

Parameter Size (octets) Description

Attribute Opcode 1 0x02 = ATT_EXCHANGE_MTU_REQ
Client Rx MTU 2 Client receive MTU size

Table 3.5: Format of ATT_EXCHANGE_MTU_REQ PDU

The Client Rx MTU shall be greater than or equal to the default ATT_MTU.

This request shall only be sent once during a connection by the client. The Client Rx
MTU parameter shall be set to the maximum size of the Attribute Protocol PDU that the
client can receive.

3.4.2.2 ATT_EXCHANGE_MTU_RSP

The ATT_EXCHANGE_MTU_RSP PDU is sent in reply to a received

ATT_EXCHANGE_MTU_REQ PDU.

Parameter Size (octets) Description

Attribute Opcode 1 0x03 = ATT_EXCHANGE_MTU_RSP
Server Rx MTU 2 ATT Server receive MTU size

Table 3.6: Format of ATT_EXCHANGE_MTU_RSP PDU

The Server Rx MTU shall be greater than or equal to the default ATT_MTU.

The Server Rx MTU parameter shall be set to the maximum size of the Attribute
Protocol PDU that the server can receive.

The server and client shall set ATT_MTU to the minimum of the Client Rx MTU and the
Server Rx MTU. The size is the same to ensure that a client can correctly detect the
final packet of a long attribute read.

This ATT_MTU value shall be applied in the server after this response has been sent
and before any other Attribute Protocol PDU is sent.

This ATT_MTU value shall be applied in the client after this response has been received
and before any other Attribute Protocol PDU is sent.

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 3, Part F Page 1494
Attribute Protocol (ATT)

If either Client Rx MTU or Service Rx MTU are incorrectly less than the default
ATT_MTU, then the ATT_MTU shall not be changed and the ATT_MTU shall be the
default ATT_MTU.

If a device is both a client and a server, the following rules shall apply:

1. A device's ATT_EXCHANGE_MTU_REQ PDU shall contain the same MTU as the

device's ATT_EXCHANGE_MTU_RSP PDU (i.e. the MTU shall be symmetric).
2. If MTU is exchanged in one direction, that is sufficient for both directions.
3. It is permitted, (but not necessary - see 2.) to exchange MTU in both directions, but
the MTUs shall be the same in each direction (see 1.)
4. If an Attribute Protocol Request is received after the MTU Exchange Request is
sent and before the MTU Exchange Response is received, the associated Attribute
Protocol Response shall use the default MTU. Figure 3.1 shows an example that is
covered by this rule. In this case device A and device B both use the default MTU
for the Attribute Protocol Response.
5. Once the MTU Exchange Request has been sent, the initiating device shall not
send an Attribute Protocol Indication or Notification until after the MTU Exchange
Response has been received.

Note: This stops the risk of a cross-over condition where the MTU size is unknown
for the Indication or Notification.

A B

Exchange U=23)
MTU Req (using MT
(150) ATT Req

Exchange MTU Rsp (100)

MTU=100

ATT Rsp (using MTU=23)

MTU=100

Figure 3.1: MTU Request and Response exchange

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 3, Part F Page 1495
Attribute Protocol (ATT)

3.4.3 Find information

3.4.3.1 ATT_FIND_INFORMATION_REQ

The ATT_FIND_INFORMATION_REQ PDU is used to obtain the mapping of attribute

handles with their associated types. This allows a client to discover the list of attributes
and their types on a server.

Parameter Size (octets) Description

Attribute Opcode 1 0x04 = ATT_FIND_INFORMATION_REQ
Starting Handle 2 First requested handle number
Ending Handle 2 Last requested handle number

Table 3.7: Format of ATT_FIND_INFORMATION_REQ PDU

Only attributes with attribute handles between the Starting Handle parameter and the
Ending Handle parameter will be returned. To read all attributes, the Starting Handle
parameter shall be set to 0x0001, and the Ending Handle parameter shall be set to
0xFFFF. The Starting Handle parameter shall be less than or equal to the Ending
Handle parameter.

If one or more attributes will be returned, an ATT_FIND_INFORMATION_RSP PDU

shall be sent.

If a server receives an ATT_FIND_INFORMATION_REQ PDU with the Starting Handle

parameter greater than the Ending Handle parameter or the Starting Handle parameter
is 0x0000, an ATT_ERROR_RSP PDU shall be sent with the Error Code parameter set
to Invalid Handle (0x01); the Attribute Handle In Error parameter shall be set to the
Starting Handle parameter.

If no attributes will be returned, an ATT_ERROR_RSP PDU shall be sent with the

Error Code parameter set to Attribute Not Found (0x0A); the Attribute Handle In Error
parameter shall be set to the Starting Handle parameter.

The server shall not respond to the ATT_FIND_INFORMATION_REQ PDU with

an ATT_ERROR_RSP PDU with the Error Code parameter set to Insufficient
Authentication (0x05), Insufficient Authorization (0x08), Encryption Key Size Too Short
(0x0C), Database Out of Sync (0x12), Application Error (0x80 to 0x9F), or Common
Profile and Service Error Codes (0xE0 to 0xFF).

3.4.3.2 ATT_FIND_INFORMATION_RSP

The ATT_FIND_INFORMATION_RSP PDU is sent in reply to a received

ATT_FIND_INFORMATION_REQ PDU and contains information about this server.

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 3, Part F Page 1496
Attribute Protocol (ATT)

Parameter Size (octets) Description

Attribute Opcode 1 0x05 = ATT_FIND_INFORMATION_RSP
Format 1 The format of the information data.
Information Data 4 to (ATT_MTU-2) The information data whose format is determined by the For-
mat field
Table 3.8: Format of ATT_FIND_INFORMATION_RSP PDU

The Find Information Response shall have complete handle-UUID pairs. Such pairs
shall not be split across response packets; this also implies that a handle-UUID pair
shall fit into a single response packet. The handle-UUID pairs shall be returned in
ascending order of attribute handles.

The Format parameter can contain one of two possible values.

Name Format Description

Handle(s) and 16-bit Bluetooth 0x01 A list of 1 or more handles with their 16-bit Bluetooth
UUID(s) UUIDs
Handle(s) and 128-bit UUID(s) 0x02 A list of 1 or more handles with their 128-bit UUIDs
Table 3.9: Format field values

The information data field is comprised of a list of data defined in Table 3.10 and
Table 3.11 depending on the value chosen for the format.

Handle 16-bit Bluetooth UUID

2 octets 2 octets
Table 3.10: Format 0x01 – handle and 16-bit Bluetooth UUIDs

Handle 128-bit UUID

2 octets 16 octets
Table 3.11: Format 0x02 – handle and 128-bit UUIDs

If sequential attributes have differing UUID sizes, the ATT_FIND_INFORMATION_RSP

PDU shall end with the first attribute of the pair even though this may mean that it is not
filled with the maximum possible amount of (handle, UUID) pairs. This is because it is
not possible to include attributes with differing UUID sizes into a single response packet.
In this situation, the client must use another ATT_FIND_INFORMATION_REQ PDU with
its starting handle updated to fetch the second attribute of the pair and any further ones
in its original request.

3.4.3.3 ATT_FIND_BY_TYPE_VALUE_REQ

The ATT_FIND_BY_TYPE_VALUE_REQ PDU is used to obtain the handles of

attributes that have a 16-bit UUID attribute type and attribute value.This allows the

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 3, Part F Page 1497
Attribute Protocol (ATT)

range of handles associated with a given attribute to be discovered when the attribute
type determines the grouping of a set of attributes.

Note: Generic Attribute Profile defines grouping of attributes by attribute type.

Parameter Size (octets) Description

Attribute Opcode 1 0x06 = ATT_FIND_BY_TYPE_VALUE_REQ PDU
Starting Handle 2 First requested handle number
Ending Handle 2 Last requested handle number
Attribute Type 2 2 octet UUID to find
Attribute Value 0 to (ATT_MTU-7) Attribute value to find

Table 3.12: Format of ATT_FIND_BY_TYPE_VALUE_REQ PDU

Only attributes with attribute handles between the Starting Handle parameter and the
Ending Handle parameter that match the requested attribute type and the attribute value
that have sufficient permissions to allow reading will be returned. To read all attributes,
the Starting Handle parameter shall be set to 0x0001, and the Ending Handle parameter
shall be set to 0xFFFF.

If one or more handles will be returned, an ATT_FIND_BY_TYPE_VALUE_RSP PDU

shall be sent.

Note: Attribute values will be compared in terms of length and binary representation.

Note: It is not possible to use this request on an attribute that has a value longer than
(ATT_MTU-7).

If a server receives an ATT_FIND_BY_TYPE_VALUE_REQ PDU with the Starting

Handle parameter greater than the Ending Handle parameter or the Starting Handle
parameter is 0x0000, an ATT_ERROR_RSP PDU shall be sent with the Error Code
parameter set to Invalid Handle (0x01). The Attribute Handle In Error parameter shall be
set to the Starting Handle parameter.

If no attributes will be returned, an ATT_ERROR_RSP PDU shall be sent by the server

with the Error Code parameter set to Attribute Not Found (0x0A). The Attribute Handle
In Error parameter shall be set to the starting handle.

The server shall not respond to the ATT_FIND_BY_TYPE_VALUE_REQ PDU with

an ATT_ERROR_RSP PDU with the Error Code parameter set to Insufficient
Authentication (0x05), Insufficient Authorization (0x08), Encryption Key Size Too Short
(0x0C), Insufficient Encryption (0x0F), Database Out of Sync (0x12), Application Error
(0x80 to 0x9F), or Common Profile and Service Error Codes (0xE0 to 0xFF).

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 3, Part F Page 1498
Attribute Protocol (ATT)

3.4.3.4 ATT_FIND_BY_TYPE_VALUE_RSP

The ATT_FIND_BY_TYPE_VALUE_RSP PDU is sent in reply to a received

ATT_FIND_BY_TYPE_VALUE_REQ PDU and contains information about this server.

Parameter Size (octets) Description

Attribute Opcode 1 0x07 = ATT_FIND_BY_TYPE_VALUE_RSP PDU
Handles Information List 4 to (ATT_MTU-1) A list of 1 or more Handle Informations

Table 3.13: Format of ATT_FIND_BY_TYPE_VALUE_RSP PDU

The Handles Information List field is a list of one or more Handle Informations. The
Handles Information field is an attribute handle range as defined in Table 3.14.

Found Attribute Handle Group End Handle

2 octets 2 octets

Table 3.14: Format of the Handles Information

The ATT_FIND_BY_TYPE_VALUE_RSP PDU shall contain one or more complete

Handles Information. Such Handles Information shall not be split across response
packets. The Handles Information List is ordered sequentially based on the found
attribute handles.

For each handle that matches the attribute type and attribute value in the
ATT_FIND_BY_TYPE_VALUE_REQ PDU a Handles Information shall be returned.
The Found Attribute Handle shall be set to the handle of the attribute that has the
exact attribute type and attribute value from the ATT_FIND_BY_TYPE_VALUE_REQ
PDU. If the attribute type in the ATT_FIND_BY_TYPE_VALUE_REQ PDU is a
grouping attribute as defined by a higher layer specification, the Group End Handle
shall be defined by that higher layer specification. If the attribute type in the
ATT_FIND_BY_TYPE_VALUE_REQ PDU is not a grouping attribute as defined by a
higher layer specification, the Group End Handle shall be equal to the Found Attribute
Handle.

Note: The Group End Handle may be greater than the Ending Handle in the
ATT_FIND_BY_TYPE_VALUE_REQ PDU.

If a server receives an ATT_FIND_BY_TYPE_VALUE_REQ PDU, the server shall

respond with the ATT_FIND_BY_TYPE_VALUE_RSP PDU containing as many handles
for attributes that match the requested attribute type and attribute value that exist in the
server that will fit into the maximum PDU size of (ATT_MTU-1).

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 3, Part F Page 1499
Attribute Protocol (ATT)

3.4.4 Reading attributes

3.4.4.1 ATT_READ_BY_TYPE_REQ

The ATT_READ_BY_TYPE_REQ PDU is used to obtain the values of attributes where

the attribute type is known but the handle is not known.

Parameter Size (octets) Description

Attribute Opcode 1 0x08 = ATT_READ_BY_TYPE_REQ PDU
Starting Handle 2 First requested handle number
Ending Handle 2 Last requested handle number
Attribute Type 2 or 16 2 or 16 octet UUID

Table 3.15: Format of ATT_READ_BY_TYPE_REQ PDU

Only the attributes with attribute handles between the Starting Handle and the Ending
Handle with the attribute type that is the same as the Attribute Type given will be
returned. To search through all attributes, the starting handle shall be set to 0x0001 and
the ending handle shall be set to 0xFFFF.

Note: All attribute types are effectively compared as 128-bit UUIDs, even if a 16-bit
UUID is provided in this request or defined for an attribute. See [Vol 3] Part B,
Section 2.5.1.

The starting handle shall be less than or equal to the ending handle. If a server
receives an ATT_READ_BY_TYPE_REQ PDU with the Starting Handle parameter
greater than the Ending Handle parameter or the Starting Handle parameter is 0x0000,
an ATT_ERROR_RSP PDU shall be sent with the Error Code parameter set to Invalid
Handle (0x01). The Attribute Handle In Error parameter shall be set to the Starting
Handle parameter.

If no attribute with the given type exists within the handle range, then no attribute handle
and value will be returned, and an ATT_ERROR_RSP PDU shall be sent with the
Error Code parameter set to Attribute Not Found (0x0A). The Attribute Handle In Error
parameter shall be set to the starting handle.

The attributes returned shall be the attributes with the lowest handles within the handle
range. These are known as the requested attributes.

If the attributes with the requested type within the handle range have attribute
values that have the same length, then these attributes can all be read in a
single request. However, if those attributes have different lengths, then multiple
ATT_READ_BY_TYPE_REQ PDUs must be issued.

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 3, Part F Page 1500
Attribute Protocol (ATT)

The ATT Server shall include as many attributes as possible in the response in order to
minimize the number of PDUs required to read attributes of the same type.

When multiple attributes match, then the rules below shall be applied to each in turn.

• Only attributes that can be read shall be returned in an ATT_READ_BY_TYPE_RSP

PDU.
• If an attribute in the set of requested attributes would cause an ATT_ERROR_RSP
PDU then this attribute cannot be included in an ATT_READ_BY_TYPE_RSP PDU
and the attributes before this attribute shall be returned.
• If the first attribute in the set of requested attributes would cause an
ATT_ERROR_RSP PDU then no other attributes in the requested attributes can be
considered.

The server shall respond with an ATT_READ_BY_TYPE_RSP PDU if the requested

attributes have sufficient permissions to allow reading.

If the client has insufficient authorization to read the requested attribute then an
ATT_ERROR_RSP PDU shall be sent with the Error Code parameter set to Insufficient
Authorization (0x08). The Attribute Handle In Error parameter shall be set to the handle
of the attribute causing the error.

If the client has insufficient security to read the requested attribute then an
ATT_ERROR_RSP PDU shall be sent with the Error Code parameter set to Insufficient
Authentication (0x05). The Attribute Handle In Error parameter shall be set to the
handle of the attribute causing the error.

If the client has an encryption key size that is too short to read the requested attribute
then an ATT_ERROR_RSP PDU shall be sent with the Error Code parameter set to
Encryption Key Size Too Short (0x0C). The Attribute Handle In Error parameter shall be
set to the handle of the attribute causing the error.

If the client has not enabled encryption, and encryption is required to read the requested
attribute, then an ATT_ERROR_RSP PDU shall be sent with the Error Code parameter
set to Insufficient Encryption (0x0F). The Attribute Handle In Error parameter shall be
set to the handle of the attribute causing the error.

If the requested attribute’s value cannot be read due to permissions then an

ATT_ERROR_RSP PDU shall be sent with the Error Code parameter set to Read Not
Permitted (0x02). The Attribute Handle In Error parameter shall be set to the handle of
the attribute causing the error.

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 3, Part F Page 1501
Attribute Protocol (ATT)

Note: If there are multiple attributes with the requested type within the handle range,
and the client would like to get the next attribute with the requested type, it would have
to issue another ATT_READ_BY_TYPE_REQ PDU with its starting handle updated.
The client can be sure there are no more such attributes remaining once it gets an
ATT_ERROR_RSP PDU with the Error Code parameter set to Attribute Not Found
(0x0A).

3.4.4.2 ATT_READ_BY_TYPE_RSP

The ATT_READ_BY_TYPE_RSP PDU is sent in reply to a received

ATT_READ_BY_TYPE_REQ PDU and contains the handles and values of the attributes
that have been read.

Parameter Size (octets) Description

Attribute Opcode 1 0x09 = ATT_READ_BY_TYPE_RSP PDU
Length 1 The size of each attribute handle-value pair
Attribute Data List 2 to (ATT_MTU-2) A list of Attribute Data

Table 3.16: Format of ATT_READ_BY_TYPE_RSP PDU

The ATT_READ_BY_TYPE_RSP PDU shall contain complete handle-value pairs. Such

pairs shall not be split across response packets. The handle-value pairs shall be
returned sequentially based on the attribute handle.

The Length parameter shall be set to the size of one attribute handle-value pair.

The maximum length of an attribute handle-value pair is 255 octets, bounded by the
Length parameter that is one octet. Therefore, the maximum length of an attribute value
returned in this response is (Length – 2) = 253 octets.

The attribute handle-value pairs shall be set to the value of the attributes identified by
the attribute type within the handle range within the request. If the attribute value is
longer than (ATT_MTU - 4) or 253 octets, whichever is smaller, then the first (ATT_MTU
- 4) or 253 octets shall be included in this response.

Note: The ATT_READ_BLOB_REQ PDU (see Section 3.4.4.5) can be used to read the
remaining octets of a long attribute value.

The Attribute Data field is comprised of a list of attribute handle and value pairs as
defined in Table 3.17.

Attribute Handle Attribute Value

2 octets (Length – 2) octets

Table 3.17: Format of the Attribute Data

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 3, Part F Page 1502
Attribute Protocol (ATT)

3.4.4.3 ATT_READ_REQ

The ATT_READ_REQ PDU is used to request the server to read the value of an
attribute and return its value in an ATT_READ_RSP PDU.

Parameter Size (octets) Description

Attribute Opcode 1 0x0A = ATT_READ_REQ PDU
Attribute Handle 2 The handle of the attribute to be read

Table 3.18: Format of ATT_READ_REQ PDU

The attribute handle parameter shall be set to a valid handle.

The server shall respond with an ATT_READ_RSP PDU if the handle is valid and the
attribute has sufficient permissions to allow reading.

If the client has insufficient authorization to read the requested attribute then an
ATT_ERROR_RSP PDU shall be sent with the Error Code parameter set to Insufficient
Authorization (0x08).

If the client has insufficient security to read the requested attribute then an
ATT_ERROR_RSP PDU shall be sent with the Error Code parameter set to Insufficient
Authentication (0x05).

If the client has an encryption key size that is too short to read the requested attribute
then an ATT_ERROR_RSP PDU shall be sent with the Error Code parameter set to
Encryption Key Size Too Short (0x0C).

If the client has not enabled encryption, and encryption is required to read the requested
attribute, then an ATT_ERROR_RSP PDU shall be sent with the Error Code parameter
set to Insufficient Encryption (0x0F).

If the handle is invalid, then an ATT_ERROR_RSP PDU shall be sent with the Error
Code parameter set to Invalid Handle (0x01).

If the attribute value cannot be read due to permissions then an ATT_ERROR_RSP

PDU shall be sent with the Error Code parameter set to Read Not Permitted (0x02).

3.4.4.4 ATT_READ_RSP

The ATT_READ_RSP PDU is sent in reply to a received Read Request and contains
the value of the attribute that has been read.

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 3, Part F Page 1503
Attribute Protocol (ATT)

Parameter Size (octets) Description

Attribute Opcode 1 0x0B = ATT_READ_RSP PDU
Attribute Value 0 to (ATT_MTU-1) The value of the attribute with the handle given

Table 3.19: Format of ATT_READ_RSP PDU

The attribute value shall be set to the value of the attribute identified by the attribute
handle in the request. If the attribute value is longer than

(ATT_MTU-1) then the first (ATT_MTU-1) octets shall be included in this response.

Note: The ATT_READ_BLOB_REQ PDU (see Section 3.4.4.5) can be used to read the
remaining octets of a long attribute value.

3.4.4.5 ATT_READ_BLOB_REQ

The ATT_READ_BLOB_REQ PDU is used to request the server to read part of the
value of an attribute at a given offset and return a specific part of the value in an
ATT_READ_BLOB_RSP PDU.

Parameter Size (octets) Description

Attribute Opcode 1 0x0C = ATT_READ_BLOB_REQ PDU
Attribute Handle 2 The handle of the attribute to be read
Value Offset 2 The offset of the first octet to be read

Table 3.20: Format of ATT_READ_BLOB_REQ PDU

The attribute handle parameter shall be set to a valid handle.

The value offset parameter is based from zero; the first value octet has an offset of zero,
the second octet has a value offset of one, etc.

The server shall respond with an ATT_READ_BLOB_RSP PDU if the handle is valid
and the attribute and value offset is not greater than the length of the attribute value and
has sufficient permissions to allow reading.

If the client has insufficient authorization to read the requested attribute then an
ATT_ERROR_RSP PDU shall be sent with the Error Code parameter set to Insufficient
Authorization (0x08).

If the client has insufficient security to read the requested attribute then an
ATT_ERROR_RSP PDU shall be sent with the Error Code parameter set to Insufficient
Authentication (0x05).

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 3, Part F Page 1504
Attribute Protocol (ATT)

If the client has an encryption key size that is too short to read the requested attribute
then an ATT_ERROR_RSP PDU shall be sent with the Error Code parameter set to
Encryption Key Size Too Short (0x0C).

If the client has not enabled encryption, and encryption is required to read the requested
attribute, then an ATT_ERROR_RSP PDU shall be sent with the Error Code parameter
set to Insufficient Encryption (0x0F).

If the handle is invalid, then an ATT_ERROR_RSP PDU shall be sent with the Error
Code parameter set to Invalid Handle (0x01).

If the attribute value cannot be read due to permissions then an ATT_ERROR_RSP

PDU shall be sent with the Error Code parameter set to Read Not Permitted (0x02).

If the value offset of the Read Blob Request is greater than the length of the attribute
value, an ATT_ERROR_RSP PDU shall be sent with the Error Code parameter set to
Invalid Offset (0x07).

If the attribute value has a fixed length that is less than or equal to (ATT_MTU - 1) octets
in length, then an ATT_ERROR_RSP PDU may be sent with the Error Code parameter
set to Attribute Not Long (0x0B).

If the value offset of the ATT_READ_BLOB_REQ PDU is equal to the length of the
attribute value, then the length of the part attribute value in the response shall be zero.

Note: If the attribute is longer than (ATT_MTU-1) octets, the ATT_READ_BLOB_REQ

PDU is the only way to read the additional octets of a long attribute. The
first (ATT_MTU-1) octets may be read using an ATT_READ_RSP PDU; the first
(ATT_MTU-3) octets can be received in an ATT_HANDLE_VALUE_NTF or an
ATT_HANDLE_VALUE_IND PDU.

Note: Some, but not all, long attributes have their length specified by a higher layer
specification. If the long attribute has a variable length, the only way to get to the end
of it is to read it part by part until the value in the ATT_READ_BLOB_RSP PDU has a
length shorter than (ATT_MTU-1) or an ATT_ERROR_RSP PDU is sent with the Error
Code parameter set to Invalid Offset (0x07).

Note: The value of a Long Attribute may change between the server receiving one
ATT_READ_BLOB_REQ PDU and the next ATT_READ_BLOB_REQ PDU. A higher
layer specification should be aware of this and define appropriate behavior.

3.4.4.6 ATT_READ_BLOB_RSP

The ATT_READ_BLOB_RSP PDU is sent in reply to a received

ATT_READ_BLOB_REQ PDU and contains part of the value of the attribute that has
been read.

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 3, Part F Page 1505
Attribute Protocol (ATT)

Parameter Size (octets) Description

Attribute Opcode 1 0x0D = ATT_READ_BLOB_RSP
Part Attribute Value 0 to (ATT_MTU-1) Part of the value of the attribute with the handle given

Table 3.21: Format of ATT_READ_BLOB_RSP PDU

The part attribute value shall be set to part of the value of the attribute identified by the
attribute handle and the value offset in the request. If the value offset is equal to the
length of the attribute value, then the length of the part attribute value shall be zero. If
the attribute value is longer than (Value Offset + ATT_MTU-1) then (ATT_MTU-1) octets
from Value Offset shall be included in this response.

3.4.4.7 ATT_READ_MULTIPLE_REQ

The ATT_READ_MULTIPLE_REQ PDU is used to request the server to read

two or more values of a set of attributes and return their values in an
ATT_READ_MULTIPLE_RSP PDU. Only values that have a known fixed size can
be read, with the exception of the last value that can have a variable length. The
knowledge of whether attributes have a known fixed size is defined in a higher layer
specification.

Parameter Size (octets) Description

Attribute Opcode 1 0x0E = ATT_READ_MULTIPLE_REQ PDU
Set Of Handles 4 to (ATT_MTU-1) A set of two or more attribute handles.

Table 3.22: Format of ATT_READ_MULTIPLE_REQ PDU

The attribute handles in the Set Of Handles parameter shall be valid handles.

The server shall respond with an ATT_READ_MULTIPLE_RSP PDU if all the handles
are valid and all attributes have sufficient permissions to allow reading.

Note: The attribute values for the attributes in the Set Of Handles parameters do not
have to all be the same size.

Note: The attribute handles in the Set Of Handles parameter do not have to be in
attribute handle order; they are in the order that the values are required in the response.

If the client has insufficient authorization to read any of the attributes then an
ATT_ERROR_RSP PDU shall be sent with the Error Code parameter set to Insufficient
Authorization (0x08).

If the client has insufficient security to read any of the attributes then an
ATT_ERROR_RSP PDU shall be sent with the Error Code parameter set to Insufficient
Authentication (0x05).

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 3, Part F Page 1506
Attribute Protocol (ATT)

If the client has an encryption key size that is too short to read any of the attributes
then an ATT_ERROR_RSP PDU shall be sent with the Error Code parameter set to
Encryption Key Size Too Short (0x0C).

If the client has not enabled encryption, and encryption is required to read the requested
attribute, then an ATT_ERROR_RSP PDU shall be sent with the Error Code parameter
set to Insufficient Encryption (0x0F).

If any of the handles are invalid, then an ATT_ERROR_RSP PDU shall be sent with the
Error Code parameter set to Invalid Handle (0x01).

If any of the attribute values cannot be read due to permissions then an

ATT_ERROR_RSP PDU shall be sent with the Error Code parameter set to Read Not
Permitted (0x02).

If an ATT_ERROR_RSP PDU is sent, the Attribute Handle In Error parameter shall be

set to the handle of the first attribute causing the error.

3.4.4.8 ATT_READ_MULTIPLE_RSP

The ATT_READ_MULTIPLE_RSP PDU is sent in reply to a received

ATT_READ_MULTIPLE_REQ PDU and contains the values of the attributes that have
been read.

Parameter Size (octets) Description

Attribute Opcode 1 0x0F = ATT_READ_MULTIPLE_RSP PDU
Set Of Values 0 to (ATT_MTU-1) A set of two or more values

Table 3.23: Format of ATT_READ_MULTIPLE_RSP PDU

The Set Of Values parameter shall be a concatenation of attribute values for each of
the attribute handles in the request in the order that they were requested. If the Set Of
Values parameter is longer than (ATT_MTU-1) then only the first (ATT_MTU-1) octets
shall be included in this response.

Note: A client should not use this request for attributes when the Set Of Values
parameter could be (ATT_MTU-1) as it will not be possible to determine if the last
attribute value is complete, or if it overflowed.

3.4.4.9 ATT_READ_BY_GROUP_TYPE_REQ

The ATT_READ_BY_GROUP_TYPE_REQ PDU is used to obtain the values of

attributes where the attribute type is known, the type of a grouping attribute as defined
by a higher layer specification, but the handle is not known.

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 3, Part F Page 1507
Attribute Protocol (ATT)

Parameter Size (octets) Description

Attribute Opcode 1 0x10 = ATT_READ_BY_GROUP_TYPE_REQ PDU
Starting Handle 2 First requested handle number
Ending Handle 2 Last requested handle number
Attribute Group Type 2 or 16 2 or 16 octet UUID

Table 3.24: Format of ATT_READ_BY_GROUP_TYPE_REQ PDU

Only the attributes with attribute handles between the Starting Handle and the Ending
Handle with the attribute type that is the same as the Attribute Group Type given will be
returned. To search through all attributes, the starting handle shall be set to 0x0001 and
the ending handle shall be set to 0xFFFF.

Note: All attribute types are effectively compared as 128-bit UUIDs, even if a 16-bit
UUID is provided in this request or defined for an attribute. See [Vol 3] Part B,
Section 2.5.1.

The starting handle shall be less than or equal to the ending handle. If a server receives
an ATT_READ_BY_GROUP_TYPE_REQ PDU with the Starting Handle parameter
greater than the Ending Handle parameter or the Starting Handle parameter is 0x0000,
an ATT_ERROR_RSP PDU shall be sent with the Error Code parameter set to Invalid
Handle (0x01). The Attribute Handle In Error parameter shall be set to the Starting
Handle parameter.

If the Attribute Group Type is not a supported grouping attribute as defined by a

higher layer specification then an ATT_ERROR_RSP PDU shall be sent with the Error
Code parameter set to Unsupported Group Type (0x10). The Attribute Handle In Error
parameter shall be set to the Starting Handle.

If no attribute with the given type exists within the handle range, then no attribute handle
and value will be returned, and an ATT_ERROR_RSP PDU shall be sent with the
Error Code parameter set to Attribute Not Found (0x0A). The Attribute Handle In Error
parameter shall be set to the starting handle.

The attributes returned shall be the attributes with the lowest handles within the handle
range. These are known as the requested attributes.

If the attributes with the requested type within the handle range have attribute
values that have the same length, then these attributes can all be read in a
single request. However, if those attributes have different lengths, then multiple
ATT_READ_BY_GROUP_TYPE_REQ PDUs must be issued.

The ATT Server shall include as many attributes as possible in the response in order to
minimize the number of PDUs required to read attributes of the same type.

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 3, Part F Page 1508
Attribute Protocol (ATT)

When multiple attributes match, then the rules below shall be applied to each in turn.

• Only attributes that can be read shall be returned in an

ATT_READ_BY_GROUP_TYPE_RSP PDU.
• If an attribute in the set of requested attributes would cause an
ATT_ERROR_RSP PDU then this attribute cannot be included in an
ATT_READ_BY_GROUP_TYPE_RSP PDU and the attributes before this attribute
shall be returned.
• If the first attribute in the set of requested attributes would cause an
ATT_ERROR_RSP PDU then no other attributes in the requested attributes can be
considered.

The server shall respond with an ATT_READ_BY_GROUP_TYPE_RSP PDU if the

requested attributes have sufficient permissions to allow reading.

If the client has insufficient authorization to read the requested attribute then an
ATT_ERROR_RSP PDU shall be sent with the Error Code parameter set to Insufficient
Authorization (0x08). The Attribute Handle In Error parameter shall be set to the handle
of the attribute causing the error.

If the client has insufficient security to read the requested attribute then an
ATT_ERROR_RSP PDU shall be sent with the Error Code parameter set to Insufficient
Authentication (0x05). The Attribute Handle In Error parameter shall be set to the
handle of the attribute causing the error.

If the client has an encryption key size that is too short to read the requested attribute
then an ATT_ERROR_RSP PDU shall be sent with the Error Code parameter set to
Encryption Key Size Too Short (0x0C). The Attribute Handle In Error parameter shall be
set to the handle of the attribute causing the error.

If the client has not enabled encryption, and encryption is required to read the requested
attribute, then an ATT_ERROR_RSP PDU shall be sent with the Error Code parameter
set to Insufficient Encryption (0x0F). The Attribute Handle In Error parameter shall be
set to the handle of the attribute causing the error.

If the requested attribute’s value cannot be read due to permissions then an

ATT_ERROR_RSP PDU shall be sent with the Error Code parameter set to Read Not
Permitted (0x02). The Attribute Handle In Error parameter shall be set to the handle of
the attribute causing the error.

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 3, Part F Page 1509
Attribute Protocol (ATT)

Note: If there are multiple attributes with the requested type within the handle range,
and the client would like to get the next attribute with the requested type, it would have
to issue another ATT_READ_BY_GROUP_TYPE_REQ PDU with its starting handle
updated. The client can be sure there are no more such attributes remaining once it
gets an ATT_ERROR_RSP PDU with the Error Code parameter set to Attribute Not
Found (0x0A).

The server shall not respond to the ATT_READ_BY_GROUP_TYPE_REQ PDU with an

ATT_ERROR_RSP PDU with the error code Database Out of Sync (0x12).

3.4.4.10 ATT_READ_BY_GROUP_TYPE_RSP

The ATT_READ_BY_GROUP_TYPE_RSP PDU is sent in reply to a received

ATT_READ_BY_GROUP_TYPE_REQ PDU and contains the handles and values of the
attributes that have been read.

Parameter Size (octets) Description

Attribute Opcode 1 0x11 = ATT_READ_BY_GROUP_TYPE_RSP PDU
Length 1 The size of each Attribute Data
Attribute Data List 4 to (ATT_MTU-2) A list of Attribute Data

Table 3.25: Format of ATT_READ_BY_GROUP_TYPE_RSP PDU

The ATT_READ_BY_GROUP_TYPE_RSP PDU shall contain complete Attribute Data.

An Attribute Data shall not be split across response packets. The Attribute Data List is
ordered sequentially based on the attribute handles.

The Length parameter shall be set to the size of the one Attribute Data.

The maximum length of an Attribute Data is 255 octets, bounded by the Length
parameter that is one octet. Therefore, the maximum length of an attribute value
returned in this response is (Length – 4) = 251 octets.

The Attribute Data List shall be set to the value of the attributes identified by the
attribute type within the handle range within the request. If the attribute value is longer
than (ATT_MTU - 6) or 251 octets, whichever is smaller, then the first (ATT_MTU - 6) or
251 octets shall be included in this response.

Note: The ATT_READ_BLOB_REQ PDU (see Section 3.4.4.5) can be used to read the
remaining octets of a long attribute value.

The Attribute Data List is comprised of a list of Attribute Data as defined in Table 3.26.

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 3, Part F Page 1510
Attribute Protocol (ATT)

Attribute Handle End Group Handle Attribute Value

2 octets 2 octets (Length - 4) octets

Table 3.26: Format of the Attribute Data

3.4.4.11 ATT_READ_MULTIPLE_VARIABLE_REQ

The ATT_READ_MULTIPLE_VARIABLE_REQ PDU is used to request that the server

read two or more values of a set of attributes that have a variable or unknown value
length and return their values in an ATT_READ_MULTIPLE_VARIABLE_RSP PDU.

Parameter Size (octets) Description

Attribute Opcode 1 0x20 = ATT_READ_MULTIPLE_VARIABLE_REQ PDU
Set Of Handles 4 to (ATT_MTU-1) A set of two or more attribute handles

Table 3.27: Format of ATT_READ_MULTIPLE_VARIABLE_REQ PDU

The attribute handles in the Set Of Handles parameter shall all be valid handles.

The server shall respond with an ATT_READ_MULTIPLE_VARIABLE_RSP PDU if all

attributes have sufficient permissions to allow reading.

Note: The attribute values for the attributes in the Set Of Handles parameters do not
have to all be the same size.

Note: The attribute handles in the Set Of Handles parameter do not have to be in
attribute handle order; they are in the order that the values are required in the response.

If the client has insufficient authorization to read any of the attributes, then an
ATT_ERROR_RSP PDU shall be sent with the error code Insufficient Authorization.

If the client has insufficient security to read any of the attributes, then an
ATT_ERROR_RSP PDU shall be sent with the error code Insufficient Authentication.

If the client has an encryption key size that is too short to read any of the attributes, then
an ATT_ERROR_RSP PDU shall be sent with the error code Encryption Key Size Too
Short.

If the client has not enabled encryption, and encryption is required to read any of the
attributes, then an ATT_ERROR_RSP PDU shall be sent with the error code Insufficient
Encryption.

If any of the handles are invalid, then an ATT_ERROR_RSP PDU shall be sent with the
error code Invalid Handle.

If any of the attribute values cannot be read due to permissions, then an

ATT_ERROR_RSP PDU shall be sent with the error code Read Not Permitted.

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 3, Part F Page 1511
Attribute Protocol (ATT)

If an ATT_ERROR_RSP PDU is sent, the Attribute Handle In Error parameter in the

ATT_ERROR_RSP PDU (see Section 3.4.1.1) shall be set to the handle of the first
attribute causing the error.

3.4.4.12 ATT_READ_MULTIPLE_VARIABLE_RSP

The ATT_READ_MULTIPLE_VARIABLE_RSP PDU is sent in reply to a received

ATT_READ_MULTIPLE_VARIABLE_REQ PDU and contains the lengths and values of
the attributes that have been read.

Parameter Size (octets) Description

Attribute Opcode 1 0x21 = ATT_READ_MULTIPLE_VARIABLE_RSP
Length Value Tuple List 4 to (ATT_MTU-1) A list of Length Value Tuples

Table 3.28: Format of ATT_READ_MULTIPLE_VARIABLE_RSP PDU

The Length Value Tuple List shall be a concatenation of Length Value Tuples for each of
the attribute handles in the request in the order that they were requested. If the Length
Value Tuple List is longer than (ATT_MTU-1) octets, then it shall be truncated after
(ATT_MTU-1) or, if that would be within the Value Length field of a Length Value Tuple,
at the start of the Length Value Tuple.

Note: The ATT_READ_BLOB_REQ PDU (see Section 3.4.4.5) can be used to read the
remaining octets of a long attribute value.

The Value Length field in a Length Value Tuple shall be set to the length of the Attribute
Value field. The Attribute Value field in a Length Value Tuple shall be set to the value of
the attribute being read.

Value Length Attribute Value

2 octets (Value Length) octets

Table 3.29: Format of the Length Value Tuple

Note: If a Length Value Tuple is truncated, then the amount of Attribute Value will be
less than the value of the Value Length field. The client must therefore not use the Value
Length to determine the amount of the Attribute Value actually included in the PDU.

3.4.5 Writing attributes

3.4.5.1 ATT_WRITE_REQ

The ATT_WRITE_REQ PDU is used to request the server to write the value of an
attribute and acknowledge that this has been achieved in an ATT_WRITE_RSP PDU.

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 3, Part F Page 1512
Attribute Protocol (ATT)

Parameter Size (octets) Description

Attribute Opcode 1 0x12 = ATT_WRITE_REQ PDU
Attribute Handle 2 The handle of the attribute to be written
Attribute Value 0 to (ATT_MTU-3) The value to be written to the attribute

Table 3.30: Format of ATT_WRITE_REQ PDU

The Attribute Handle shall be set to a valid handle.

The Attribute Value shall be set to the new value of the attribute.

If the attribute value has a variable length, then the attribute value shall be truncated or
lengthened to match the length of the Attribute Value parameter.

Note: If an attribute value has a variable length and if the Attribute Value parameter is of
zero length, the attribute value will be fully truncated.

If the attribute value has a fixed length and the Attribute Value parameter length is
less than or equal to the length of the attribute value, the octets of the attribute
value parameter length shall be written; all other octets in this attribute value shall be
unchanged.

The server shall respond with an ATT_WRITE_RSP PDU if the handle is valid, the
attribute has sufficient permissions to allow writing, and the attribute value has a valid
size and format, and it is successful in writing the attribute.

If the attribute value has a variable length and the Attribute Value parameter length
exceeds the maximum valid length of the attribute value then the server shall respond
with an ATT_ERROR_RSP PDU with the Error Code parameter set to Invalid Attribute
Value Length (0x0D).

If the attribute value has a fixed length and the requested attribute value parameter
length is greater than the length of the attribute value then the server shall respond with
an ATT_ERROR_RSP PDU with the Error Code parameter set to Invalid Attribute Value
Length (0x0D).

If the client has insufficient authorization to write the requested attribute then an
ATT_ERROR_RSP PDU shall be sent with the Error Code parameter set to Insufficient
Authorization (0x08).

If the client has insufficient security to write the requested attribute then an
ATT_ERROR_RSP PDU shall be sent with the Error Code parameter set to Insufficient
Authentication (0x05).

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 3, Part F Page 1513
Attribute Protocol (ATT)

If the client has an encryption key size that is too short to write the requested attribute
then an ATT_ERROR_RSP PDU shall be sent with the Error Code parameter set to
Encryption Key Size Too Short (0x0C).

If the client has not enabled encryption, and encryption is required to write the
requested attribute, then an ATT_ERROR_RSP PDU shall be sent with the Error Code
parameter set to Insufficient Encryption (0x0F).

If the handle is invalid, then an ATT_ERROR_RSP PDU shall be sent with the Error
Code parameter set to Invalid Handle (0x01).

If the attribute value cannot be written due to permissions then an ATT_ERROR_RSP

PDU shall be sent with the Error Code parameter set to Write Not Permitted (0x03).

If the attribute value cannot be written due to an application error then an

ATT_ERROR_RSP PDU shall be sent with an error code defined by a higher layer
specification.

3.4.5.2 ATT_WRITE_RSP

The ATT_WRITE_RSP PDU is sent in reply to a valid ATT_WRITE_REQ PDU and

acknowledges that the attribute has been successfully written.

Parameter Size (octets) Description

Attribute Opcode 1 0x13 = ATT_WRITE_RSP PDU

Table 3.31: Format of ATT_WRITE_RSP

The ATT_WRITE_RSP PDU shall be sent after the attribute value is written.

3.4.5.3 ATT_WRITE_CMD

The ATT_WRITE_CMD PDU is used to request the server to write the value of an
attribute, typically into a control-point attribute.

Parameter Size (octets) Description

Attribute Opcode 1 0x52 = ATT_WRITE_CMD PDU
Attribute Handle 2 The handle of the attribute to be set
Attribute Value 0 to (ATT_MTU-3) The value of be written to the attribute

Table 3.32: Format of ATT_WRITE_CMD PDU

The attribute handle parameter shall be set to a valid handle.

The attribute value parameter shall be set to the new value of the attribute.

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 3, Part F Page 1514
Attribute Protocol (ATT)

If the attribute value has a variable length, then the attribute value shall be truncated or
lengthened to match the length of the attribute value parameter.

Note: If an attribute value has a variable length and if the attribute value parameter is of
zero length, the attribute value will be fully truncated.

If the attribute value has a fixed length and the attribute value parameter length is
less than or equal to the length of the attribute value, the octets up to the attribute
value parameter length shall be written; all other octets in this attribute value shall be
unchanged.

If the attribute value has a variable length and the attribute value parameter length
exceeds the maximum valid length of the attribute value then the server shall ignore the
command.

If the attribute value has a fixed length and the requested attribute value parameter
length is greater than the length of the attribute value then the server shall ignore the
command.

No ATT_ERROR_RSP or ATT_WRITE_RSP PDUs shall be sent in response to this

command. If the server cannot write this attribute for any reason the command shall be
ignored.

3.4.5.4 ATT_SIGNED_WRITE_CMD

This command shall not be used on an Enhanced ATT bearer.

The ATT_SIGNED_WRITE_CMD PDU is used to request the server to write the value
of an attribute with an authentication signature, typically into a control-point attribute.

Parameter Size (Octets) Description

Attribute Opcode 1 0xD2 = ATT_SIGNED_WRITE_CMD PDU
Attribute Handle 2 The handle of the attribute to be set
Attribute Value 0 to (ATT_MTU‑15) The value to be written to the attribute
Authentication Signature 12 Authentication signature for the Attribute Opcode, At-
tribute Handle and Attribute Value parameters
Table 3.33: Format of ATT_SIGNED_WRITE_CMD

The attribute handle parameter shall be set to a valid handle.

The attribute value parameter shall be set to the new value of the attribute.

The attribute signature shall be calculated as defined in Section 3.3.1.

For example, if the variable length message m to be signed is ‘D212001337’,

SignCounter is 0x00000001 and key is 0x611B64EBFBCD1FD372EC9196DF425E50,

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 3, Part F Page 1515
Attribute Protocol (ATT)

then message to be signed (M) by the CMAC function is the octet sequence
‘D21200133701000000’.

The padding(M) is 0x0000000137130012D280000000000000, resultant CMAC is

0xF20F903C931E87F159B64F012574B4D0 and Authentication Signature is the octet
sequence ‘01000000F1871E933C900FF2’.

The final signed message is ‘D21200133701000000F1871E933C900FF2’.

If the attribute value has a variable length, then the attribute value shall be truncated or
lengthened to match the length of the attribute value parameter.

Note: If an attribute value has a variable length and if the attribute value parameter is of
zero length, the attribute value will be fully truncated.

If the attribute value has a fixed length and the attribute value parameter length is
less than or equal to the length of the attribute value, the octets up to the attribute
value parameter length shall be written; all other octets in this attribute value shall be
unchanged.

If the attribute value has a variable length and the attribute value parameter length
exceeds the maximum valid length of the attribute value then the server shall ignore the
command.

If the attribute value has a fixed length and the requested attribute value parameter
length is greater than the length of the attribute value then the server shall ignore the
command.

If the authentication signature verification fails, then the server shall ignore the
command.

No ATT_ERROR_RSP PDU or ATT_WRITE_RSP PDU shall be sent in response to this

command. If the server cannot write this attribute for any reason the command shall be
ignored.

3.4.6 Queued writes

The purpose of queued writes is to queue up writes of values of multiple attributes in

a first-in first-out queue and then execute the write on all of them in a single atomic
operation.

Each client's queued values are separate; the execution of one queue shall not affect
the preparation or execution of any other client's queued values. Each client has a
single queue regardless of how many ATT bearers are currently established.

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 3, Part F Page 1516
Attribute Protocol (ATT)

3.4.6.1 ATT_PREPARE_WRITE_REQ

The ATT_PREPARE_WRITE_REQ PDU is used to request the server to prepare

to write the value of an attribute. The server will respond to this request with an
ATT_PREPARE_WRITE_RSP PDU, so that the client can verify that the value was
received correctly.

A client may send more than one ATT_PREPARE_WRITE_REQ PDU to a server, which
will queue and send a response for each handle value pair.

A server may limit the number of prepared writes that it can queue. A higher layer
specification should define this limit.

After an ATT_PREPARE_WRITE_REQ PDU has been issued, and the response

received, any other attribute command or request can be issued from the same client to
the same server.

Any actions on attributes that exist in the prepare queue shall proceed as if the prepare
queue did not exist, and the prepare queue shall be unaffected by these actions. A
subsequent execute write will write the values in the prepare queue even if the value of
the attribute has changed since the prepare writes were started.

The Attribute Protocol makes no determination on the validity of the Part Attribute Value
or the Value Offset. A higher layer specification determines the meaning of the data.

Each ATT_PREPARE_WRITE_REQ PDU will be queued even if the attribute handle

is the same as a previous ATT_PREPARE_WRITE_REQ PDU. These will then be
executed in the order received, causing multiple writes for this attribute to occur.

If all ATT bearers belonging to the same client are lost while a number of pending
prepare write values have been queued, the queue will be cleared and no writes will be
executed.

Parameter Size (octets) Description

Attribute Opcode 1 0x16 = ATT_PREPARE_WRITE_REQ PDU
Attribute Handle 2 The handle of the attribute to be written
Value Offset 2 The offset of the first octet to be written
Part Attribute Value 0 to (ATT_MTU-5) The value of the attribute to be written

Table 3.34: Format of ATT_PREPARE_WRITE_REQ PDU

The Attribute Handle parameter shall be set to a valid handle.

The Value Offset parameter shall be set to the offset of the first octet where the Part
Attribute Value parameter is to be written within the attribute value. The Value Offset

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 3, Part F Page 1517
Attribute Protocol (ATT)

parameter is based from zero; the first octet has an offset of zero, the second octet has
an offset of one, etc.

The server shall respond with an ATT_PREPARE_WRITE_RSP PDU if the handle

is valid, the attribute has sufficient permissions to allow writing at this time, and the
prepare queue has sufficient space.

Note: The Attribute Value validation is done when an ATT_EXECUTE_WRITE_REQ

PDU is received. Hence, any Invalid Offset (0x07) or Invalid Attribute Value Length
(0x0D) errors are generated when an ATT_EXECUTE_WRITE_REQ PDU is received.

If the client has insufficient authorization to write the requested attribute then an
ATT_ERROR_RSP PDU shall be sent with the Error Code parameter set to Insufficient
Authorization (0x08).

If the client has insufficient security to write the requested attribute then an
ATT_ERROR_RSP PDU shall be sent with the Error Code parameter set to Insufficient
Authentication (0x05).

If the client has an encryption key size that is too short to write the requested attribute
then an ATT_ERROR_RSP PDU shall be sent with the Error Code parameter set to
Encryption Key Size Too Short (0x0C).

If the client has not enabled encryption, and encryption is required to write the
requested attribute, then an ATT_ERROR_RSP PDU shall be sent with the Error Code
parameter set to Insufficient Encryption (0x0F).

If the server does not have sufficient space to queue this request then an
ATT_ERROR_RSP PDU shall be sent with the Error Code parameter set to Prepare
Queue Full (0x09).

If the handle is invalid, then an ATT_ERROR_RSP PDU shall be sent with the Error
Code parameter set to Invalid Handle (0x01).

If the attribute value cannot be written then an ATT_ERROR_RSP PDU shall be sent
with the Error Code parameter set to Write Not Permitted (0x03).

The server shall not change the value of the attribute until an
ATT_EXECUTE_WRITE_REQ PDU is received.

If an ATT_PREPARE_WRITE_REQ PDU was invalid, and therefore an

ATT_ERROR_RSP PDU has been issued, then this prepared write will be considered to
have not been received. All existing prepared writes in the prepare queue shall not be
affected by this invalid request.

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 3, Part F Page 1518
Attribute Protocol (ATT)

3.4.6.2 ATT_PREPARE_WRITE_RSP

The ATT_PREPARE_WRITE_RSP PDU is sent in response to a received

ATT_PREPARE_WRITE_REQ PDU and acknowledges that the value has been
successfully received and placed in the prepare write queue.

Parameter Size (octets) Description

Attribute Opcode 1 0x17 = ATT_PREPARE_WRITE_RSP PDU
Attribute Handle 2 The handle of the attribute to be written
Value Offset 2 The offset of the first octet to be written
Part Attribute Value 0 to (ATT_MTU-5) The value of the attribute to be written

Table 3.35: Format of ATT_PREPARE_WRITE_RSP PDU

The attribute handle shall be set to the same value as in the corresponding
ATT_PREPARE_WRITE_REQ PDU.

The value offset and part attribute value shall be set to the same values as in the
corresponding ATT_PREPARE_WRITE_REQ PDU.

3.4.6.3 ATT_EXECUTE_WRITE_REQ

The ATT_EXECUTE_WRITE_REQ PDU is used to request the server to write or cancel

the write of all the prepared values currently held in the prepare queue from this client.
This request shall be handled by the server as an atomic operation.

Parameter Size (octets) Description

Attribute Opcode 1 0x18 = ATT_EXECUTE_WRITE_REQ PDU
Flags 1 0x00 – Cancel all prepared writes
0x01 – Immediately write all pending prepared values

Table 3.36: Format of ATT_EXECUTE_WRITE_REQ PDU

When the flags parameter is set to 0x01, all pending prepare write values that are
currently queued shall be written in the order they were received in the corresponding
ATT_PREPARE_WRITE_REQ PDUs. The queue shall then be cleared and an
ATT_EXECUTE_WRITE_RSP PDU shall be sent.

When the flags parameter is set to 0x00 all pending prepare write values
shall be discarded for this client. The queue shall then be cleared, and an
ATT_EXECUTE_WRITE_RSP PDU shall be sent.

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 3, Part F Page 1519
Attribute Protocol (ATT)

Note: If multiple ATT bearers were used to send the prepare write requests, then the
order that writes sent on different ATT bearers are executed is not specified and is
not reported to the client. In addition, if the ATT_EXECUTE_WRITE_REQ PDU is sent
before the client has received responses to all the prepare write requests, the requests
for which the client has not yet received a response might form part of a subsequent
write rather than this one; this is also not reported to the client.

If there are no pending prepared write values, then no values are written, and an
ATT_EXECUTE_WRITE_RSP PDU shall be sent.

If the prepared Attribute Value exceeds the maximum valid length of the attribute value
then all pending prepare write values shall be discarded for this client, the queue shall
then be cleared, and an ATT_ERROR_RSP PDU shall be sent with the Error Code
parameter set to Invalid Attribute Value Length (0x0D).

If the prepare Value Offset is greater than the current length of the attribute value
then all pending prepare write values shall be discarded for this client, the queue shall
be cleared and then an ATT_ERROR_RSP PDU shall be sent with the Error Code
parameter set to Invalid Offset (0x07).

If the pending prepared write values cannot be written, due to an application error, the
queue shall be cleared and then an ATT_ERROR_RSP PDU shall be sent with a higher
layer specification defined error code. The Attribute Handle In Error parameter shall
be set to the attribute handle of the attribute from the prepare queue that caused this
application error. The state of the attributes that were to be written from the prepare
queue is not defined in this case.

3.4.6.4 ATT_EXECUTE_WRITE_RSP

The ATT_EXECUTE_WRITE_RSP PDU is sent in response to a received

ATT_EXECUTE_WRITE_REQ PDU.

Parameter Size Description

Attribute Opcode 1 0x19 - ATT_EXECUTE_WRITE_RSP PDU

Table 3.37: Format of ATT_EXECUTE_WRITE_RSP PDU

The ATT_EXECUTE_WRITE_RSP PDU shall be sent after the attributes are written. In
case an action is taken in response to the write, an indication may be used once the
action is complete.

3.4.7 Server initiated

3.4.7.1 ATT_HANDLE_VALUE_NTF

A server can send a notification of an attribute’s value at any time.

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 3, Part F Page 1520
Attribute Protocol (ATT)

Parameter Size (octets) Description

Attribute Opcode 1 0x1B = ATT_HANDLE_VALUE_NTF PDU
Attribute Handle 2 The handle of the attribute
Attribute Value 0 to (ATT_MTU-3) The current value of the attribute

Table 3.38: Format of ATT_HANDLE_VALUE_NTF PDU

The attribute handle shall be set to a valid handle.

The attribute value shall be set to the current value of the attribute identified by the
attribute handle.

If the attribute value is longer than (ATT_MTU-3) octets, then only the first (ATT_MTU-3)
octets of this attributes value can be sent in a notification.

Note: For a client to get a long attribute, it must use the ATT_READ_BLOB_REQ PDU
(see Section 3.4.4.5) following the receipt of this notification.

If the attribute handle or the attribute value is invalid, then this notification shall be
ignored upon reception.

3.4.7.2 ATT_HANDLE_VALUE_IND

A server can send an indication of an attribute’s value.

Parameter Size (octets) Description

Attribute Opcode 1 0x1D = ATT_HANDLE_VALUE_IND PDU
Attribute Handle 2 The handle of the attribute
Attribute Value 0 to (ATT_MTU-3) The current value of the attribute

Table 3.39: Format of ATT_HANDLE_VALUE_IND PDU

The attribute handle shall be set to a valid handle.

The attribute value shall be set to the current value of the attribute identified by the
attribute handle.

If the attribute value is longer than (ATT_MTU-3) octets, then only the first (ATT_MTU -
3) octets of this attributes value can be sent in an indication.

Note: For a client to get a long attribute, it must use the ATT_READ_BLOB_REQ PDU
(see Section 3.4.4.5) following the receipt of this indication.

The client shall send an ATT_HANDLE_VALUE_CFM PDU in response to an

ATT_HANDLE_VALUE_IND PDU. No further indications to this client shall occur until
the confirmation has been received by the server.

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 3, Part F Page 1521
Attribute Protocol (ATT)

If the attribute handle or the attribute value is invalid, the client shall send an
ATT_HANDLE_VALUE_CFM PDU in response and shall discard the handle and value
from the received indication.

3.4.7.3 ATT_HANDLE_VALUE_CFM

The ATT_HANDLE_VALUE_CFM PDU is sent in response to a received

ATT_HANDLE_VALUE_IND PDU and confirms that the client has received an indication
of the given attribute.

Parameter Size (octets) Description

Attribute Opcode 1 0x1E = ATT_HANDLE_VALUE_CFM PDU

Table 3.40: Format of ATT_HANDLE_VALUE_CFM PDU

3.4.7.4 ATT_MULTIPLE_HANDLE_VALUE_NTF

A server can send a notification of two or more attributes' values at any time.

Parameter Size (octets) Description

Attribute Opcode 1 0x23 = ATT_MULTIPLE_-
HANDLE_VALUE_NTF
Handle Length Value Tuple List 8 to (ATT_MTU-1) A list of Handle Length Value Tuples

Table 3.41: Format of ATT_MULTIPLE_HANDLE_VALUE_NTF PDU

The Handle Length Value Tuple List shall be a concatenation of Handle Length Value
Tuples for each of the attributes being notified.

The server shall not truncate a Handle Length Value Tuple.

The Attribute Handle field in a Handle Length Value Tuple shall be set to the handle of
the attribute being notified. The Value Length field in a Handle Length Value Tuple shall
be set to the length of the Attribute Value field. The Attribute Value field in a Handle
Length Value Tuple shall be set to the value of the attribute being notified.

Attribute Handle Value Length Attribute Value

2 octets 2 octets (Value Length) octets

Table 3.42: Format of the Handle Length Value Tuple

If an attribute handle or an attribute value is invalid, then the client shall ignore that
attribute when receiving this notification.

3.4.8 Attribute Opcode summary

Table 3.43 gives a summary of the Attribute Protocol PDUs.

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 3, Part F Page 1522
Attribute Protocol (ATT)

Attribute PDU Name Attribute Opcode Parameters

ATT_ERROR_RSP 0x01 Request Opcode in Error,
Attribute Handle In Error,
Error Code
ATT_EXCHANGE_MTU_REQ 0x02 Client Rx MTU
ATT_EXCHANGE_MTU_RSP 0x03 Server Rx MTU
ATT_FIND_INFORMATION_REQ 0x04 Starting Handle,
Ending Handle
ATT_FIND_INFORMATION_RSP 0x05 Format,
Information Data
ATT_FIND_BY_TYPE_VALUE_REQ 0x06 Starting Handle,
Ending Handle,
Attribute Type,
Attribute Value
ATT_FIND_BY_TYPE_VALUE_RSP 0x07 Handles Information List
ATT_READ_BY_TYPE_REQ 0x08 Starting Handle,
Ending Handle,
UUID
ATT_READ_BY_TYPE_RSP 0x09 Length,
Attribute Data List
ATT_READ_REQ 0x0A Attribute Handle
ATT_READ_RSP 0x0B Attribute Value
ATT_READ_BLOB_REQ 0x0C Attribute Handle,
Value Offset
ATT_READ_BLOB_RSP 0x0D Part Attribute Value
ATT_READ_MULTIPLE_REQ 0x0E Handle Set
ATT_READ_MULTIPLE_RSP 0x0F Value Set
ATT_READ_BY_GROUP_TYPE_REQ 0x10 Start Handle,
Ending Handle,
UUID
ATT_READ_BY_GROUP_TYPE_RSP 0x11 Length,
Attribute Data List
ATT_WRITE_REQ 0x12 Attribute Handle,
Attribute Value
ATT_WRITE_RSP 0x13 none

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 3, Part F Page 1523
Attribute Protocol (ATT)

Attribute PDU Name Attribute Opcode Parameters

ATT_WRITE_CMD 0x52 Attribute Handle,
Attribute Value
ATT_PREPARE_WRITE_REQ 0x16 Attribute Handle,
Value Offset,
Part Attribute Value
ATT_PREPARE_WRITE_RSP 0x17 Attribute Handle,
Value Offset,
Part Attribute Value
ATT_EXECUTE_WRITE_REQ 0x18 Flags
ATT_EXECUTE_WRITE_RSP 0x19 none
ATT_READ_MULTIPLE_VARIABLE_REQ 0x20 Set Of Handles
ATT_READ_MULTIPLE_VARIABLE_RSP 0x21 Length Value Tuple List
ATT_MULTIPLE_HANDLE_VALUE_NTF 0x23 Handle Length Value Tuple List
ATT_HANDLE_VALUE_NTF 0x1B Attribute Handle,
Attribute Value
ATT_HANDLE_VALUE_IND 0x1D Attribute Handle,
Attribute Value
ATT_HANDLE_VALUE_CFM 0x1E none
ATT_SIGNED_WRITE_CMD 0xD2 Attribute Handle,
Attribute Value,
Authentication Signature

Table 3.43: Attribute Protocol summary

3.4.9 Attribute PDU response summary

Table 3.44 gives a summary of the Attribute PDU Method responses that are allowed.
Each method indicates the method that should be sent as a successful response,
and whether an ATT_ERROR_RSP PDU can be sent in response instead. If an
ATT_ERROR_RSP PDU can be sent, then Table 3.44 also indicates the error codes
that are valid within this ATT_ERROR_RSP PDU for the given method.

Attribute PDU Method Successful Response ATT_ERROR_- Valid Error Codes

PDU RSP Allowed
ATT_EXCHANGE_- ATT_EXCHANGE_- Yes Request Not Supported (0x06)
MTU_REQ MTU_RSP
ATT_FIND_- ATT_FIND_- Yes Invalid Handle (0x01),
INFORMATION_REQ INFORMATION_RSP Attribute Not Found (0x0A)

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 3, Part F Page 1524
Attribute Protocol (ATT)

Attribute PDU Method Successful Response ATT_ERROR_- Valid Error Codes

PDU RSP Allowed
ATT_FIND_BY_- ATT_FIND_BY_- Yes Invalid Handle (0x01),
TYPE_VALUE_REQ TYPE_VALUE_RSP Request Not Supported
(0x06),
Attribute Not Found (0x0A)
ATT_READ_BY_- ATT_READ_BY_- Yes Invalid Handle (0x01),
TYPE_REQ TYPE_RSP Database Out of Sync (0x12),
Request Not Supported
(0x06),
Attribute Not Found (0x0A),
Insufficient Authorization
(0x08),
Insufficient Authentication
(0x05),
Insufficient Encryption (0x0F),
Encryption Key Size Too Short
(0x0C),
Read Not Permitted (0x02),
Application Error (0x80 to
0x9F),
Common Profile and Service
Error Codes (0xE0 to 0xFF)
ATT_READ_REQ ATT_READ_RSP Yes Invalid Handle (0x01),
Database Out Of Sync (0x12),
Insufficient Authorization
(0x08),
Insufficient Authentication
(0x05),
Insufficient Encryption (0x0F),
Encryption Key Size Too Short
(0x0C),
Read Not Permitted (0x02),
Application Error (0x80 to
0x9F),
Common Profile and Service
Error Codes (0xE0 to 0xFF)

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 3, Part F Page 1525
Attribute Protocol (ATT)

Attribute PDU Method Successful Response ATT_ERROR_- Valid Error Codes

PDU RSP Allowed
ATT_READ_BLOB_- ATT_READ_BLOB_- Yes Invalid Handle (0x01),
REQ RSP Database Out Of Sync (0x12),
Request Not Supported
(0x06),
Insufficient Authorization
(0x08),
Insufficient Authentication
(0x05),
Insufficient Encryption (0x0F),
Encryption Key Size Too Short
(0x0C),
Read Not Permitted (0x02),
Invalid Offset (0x07),
Attribute Not Long (0x0B),
Application Error (0x80 to
0x9F),
Common Profile and Service
Error Codes (0xE0 to 0xFF)
ATT_READ_- ATT_READ_- Yes Invalid Handle (0x01),
MULTIPLE_REQ MULTIPLE_RSP Database Out Of Sync (0x12),
Request Not Supported
(0x06),
Insufficient Authorization
(0x08),
Insufficient Authentication
(0x05),
Insufficient Encryption (0x0F),
Encryption Key Size Too Short
(0x0C),
Read Not Permitted (0x02),
Application Error (0x80 to
0x9F),
Common Profile and Service
Error Codes (0xE0 to 0xFF)

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 3, Part F Page 1526
Attribute Protocol (ATT)

Attribute PDU Method Successful Response ATT_ERROR_- Valid Error Codes

PDU RSP Allowed
ATT_READ_BY_- ATT_READ_BY_- Yes Invalid Handle (0x01),
GROUP_TYPE_REQ GROUP_TYPE_RSP Request Not Supported
(0x06),
Attribute Not Found (0x0A),
Insufficient Authorization
(0x08),
Insufficient Authentication
(0x05),
Insufficient Encryption (0x0F),
Encryption Key Size Too Short
(0x0C),
Read Not Permitted (0x02),
Unsupported Group Type
(0x10),
Application Error (0x80 to
0x9F),
Common Profile and Service
Error Codes (0xE0 to 0xFF)
ATT_READ_- ATT_READ_- Yes Invalid Handle (0x01),
MULTIPLE_- MULTIPLE_- Database Out Of Sync (0x12),
VARIABLE_REQ VARIABLE_RSP
Request Not Supported
(0x06),
Insufficient Authorization
(0x08),
Insufficient Authentication
(0x05),
Insufficient Encryption (0x0F),
Encryption Key Size Too Short
(0x0C),
Read Not Permitted (0x02),
Application Error (0x80 to
0x9F),
Common Profile and Service
Error Codes (0xE0 to 0xFF)

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 3, Part F Page 1527
Attribute Protocol (ATT)

Attribute PDU Method Successful Response ATT_ERROR_- Valid Error Codes

PDU RSP Allowed
ATT_WRITE_REQ ATT_WRITE_RSP Yes Invalid Handle (0x01),
Database Out Of Sync (0x12),
Request Not Supported
(0x06),
Insufficient Authorization
(0x08),
Insufficient Authentication
(0x05),
Insufficient Encryption (0x0F),
Encryption Key Size Too Short
(0x0C),
Write Not Permitted (0x03),
Invalid Attribute Value Length
(0x0D),
Application Error (0x80 to
0x9F),
Common Profile and Service
Error Codes (0xE0 to 0xFF)
ATT_WRITE_CMD none No none
ATT_SIGNED_- none No none
WRITE_CMD
ATT_PREPARE_- ATT_PREPARE_- Yes Invalid Handle (0x01),
WRITE_REQ WRITE_RSP Database Out Of Sync (0x12),
Request Not Supported
(0x06),
Insufficient Authorization
(0x08),
Insufficient Authentication
(0x05),
Write Not Permitted (0x03),
Prepare Queue Full (0x09),
Insufficient Encryption (0x0F),
Encryption Key Size Too Short
(0x0C),
Application Error (0x80 to
0x9F),
Common Profile and Service
Error Codes (0xE0 to 0xFF)

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 3, Part F Page 1528
Attribute Protocol (ATT)

Attribute PDU Method Successful Response ATT_ERROR_- Valid Error Codes

PDU RSP Allowed
ATT_EXECUTE_- ATT_EXECUTE_- Yes Application Error (0x80 to
WRITE_REQ WRITE_RSP 0x9F),
Common Profile and Service
Error Codes (0xE0 to 0xFF),
Invalid Offset (0x07),
Invalid Attribute Value Length
(0x0D)
ATT_HANDLE_- none No none
VALUE_NTF
ATT_HANDLE_- ATT_HANDLE_- No none
VALUE_IND VALUE_CFM
ATT_MULTIPLE_- none No none
HANDLE_VALUE_-
NTF

Table 3.44: Attribute request and response summary

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 3, Part F Page 1529
Attribute Protocol (ATT)

4 SECURITY CONSIDERATIONS

The Attribute Protocol can be used to access information that may require both
authorization and an authenticated and encrypted physical link before an attribute can
be read or written.

If such a request is issued when the client has not been authorized to access this
information, the server shall send an ATT_ERROR_RSP PDU with the Error Code
parameter set to Insufficient Authorization (0x08). The authorization requirements for
access to a given attribute are not defined in this Part. Each device implementation will
determine how authorization occurs. Authorization procedures are defined in GAP, and
may be further refined in a higher layer specification.

If such a request is issued when the physical link is unauthenticated, the server shall
send an ATT_ERROR_RSP PDU with the Error Code parameter set to Insufficient
Authentication (0x05). A client wanting to read or write this attribute can then request
that the physical link be authenticated, and once this has been completed, send the
request again.

The Attribute Protocol can be used to notify or indicate the value of an attribute that
may require an authenticated and encrypted physical link before an attribute notification
or indication is performed. A server wanting to notify or indicate this attribute can then
request that the physical link be authenticated, and once this has been completed, send
the notification or indication.

The list of attributes that a device supports is not considered private or confidential
information, and therefore the ATT_FIND_INFORMATION_REQ PDU shall always
be permitted. This implies that the error code Insufficient Authorization (0x08) or
Insufficient Authentication (0x05) shall not be used in an ATT_ERROR_RSP PDU for
an ATT_FIND_INFORMATION_REQ PDU.

For example, an attribute value may be allowed to be read by any device, but only
written by an authenticated device. An implementation should take this into account,
and not assume that just because it can read an attribute’s value, it will also be able to
write the value. Similarly, just because an attribute value can be written, does not mean
that an attribute value can also be read. Each individual attribute could have different
security requirements.

When a client accesses an attribute, the order of checks that are performed on
the server will have security implications. A server shall check authentication and
authorization requirements before any other check is performed.

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 3, Part F Page 1530
Attribute Protocol (ATT)

Note: For example, if the authentication and authorization requirement checks are not
performed first then the size of an attribute could be determined by sending repeated
ATT_READ_BLOB_REQ PDUs for an attribute that a client does not have access to,
because either the error code Invalid Offset (0x07) or Insufficient Authentication (0x05)
would be returned.

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 3, Part F Page 1531
Attribute Protocol (ATT)

5 REFERENCES

[1] Core Specification Supplement, Part B, Common Profile and Service Error
Codes

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 3, Part F Page 1532
Attribute Protocol (ATT)

Appendix A Changes to PDU names

Previous versions of this specification used different names for the PDUs defined in
Section 3.4. Table A.1 shows the previous and current names of these PDUs.

Previous name Current name

Error Response ATT_ERROR_RSP
Exchange MTU Request ATT_EXCHANGE_MTU_REQ
Exchange MTU Response ATT_EXCHANGE_MTU_RSP
Execute Write Request ATT_EXECUTE_WRITE_REQ
Execute Write Response ATT_EXECUTE_WRITE_RSP
Find By Type Value Request ATT_FIND_BY_TYPE_VALUE_REQ
Find By Type Value Response ATT_FIND_BY_TYPE_VALUE_RSP
Find Information Request ATT_FIND_INFORMATION_REQ
Find Information Response ATT_FIND_INFORMATION_RSP
Handle Value Confirmation ATT_HANDLE_VALUE_CFM
Handle Value Indication ATT_HANDLE_VALUE_IND
Handle Value Notification ATT_HANDLE_VALUE_NTF
Prepare Write Request ATT_PREPARE_WRITE_REQ
Prepare Write Response ATT_PREPARE_WRITE_RSP
Read Blob Request ATT_READ_BLOB_REQ
Read Blob Response ATT_READ_BLOB_RSP
Read by Group Type Request ATT_READ_BY_GROUP_TYPE_REQ
Read by Group Type Response ATT_READ_BY_GROUP_TYPE_RSP
Read By Type Request ATT_READ_BY_TYPE_REQ
Read By Type Response ATT_READ_BY_TYPE_RSP
Read Multiple Request ATT_READ_MULTIPLE_REQ
Read Multiple Response ATT_READ_MULTIPLE_RSP
Read Request ATT_READ_REQ
Read Response ATT_READ_RSP
Signed Write Command ATT_SIGNED_WRITE_CMD
Write Command ATT_WRITE_CMD

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 3, Part F Page 1533
Attribute Protocol (ATT)

Previous name Current name

Write Request ATT_WRITE_REQ
Write Response ATT_WRITE_RSP

Table A.1: Changes to PDU names

Bluetooth SIG Proprietary Version Date: 2024-08-27

 Host
Part G

GENERIC ATTRIBUTE
PROFILE (GATT)

This Part defines the Generic Attribute Profile that

describes a service framework using the Attribute
Protocol for discovering services, and for reading
and writing characteristic values on a peer device.

Bluetooth SIG Proprietary

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 3, Part G Page 1535
Generic Attribute Profile (GATT)

CONTENTS

1 Introduction ............................................................................................. 1538

1.1 Scope ........................................................................................ 1538
1.2 Profile dependency ................................................................... 1538
1.3 [This section is no longer used] ................................................. 1538
1.4 [This section is no longer used] ................................................. 1538
1.5 Conventions .............................................................................. 1538

2 Profile overview ...................................................................................... 1539

2.1 Protocol stack ............................................................................ 1539
2.2 Configurations and roles ........................................................... 1539
2.3 User requirements and scenarios ............................................. 1540
2.4 Profile fundamentals ................................................................. 1541
2.5 Attribute Protocol ....................................................................... 1541
2.5.1 Overview .................................................................... 1541
2.5.2 Attribute caching ........................................................ 1542
2.5.2.1 Robust Caching .......................................... 1544
2.5.3 Attribute grouping ...................................................... 1548
2.5.4 UUIDs ........................................................................ 1548
2.6 GATT Profile hierarchy .............................................................. 1548
2.6.1 Overview .................................................................... 1548
2.6.2 Service ....................................................................... 1549
2.6.3 Included services ....................................................... 1550
2.6.4 Characteristic ............................................................. 1550
2.7 Configured Broadcast ............................................................... 1550

3 Service interoperability requirements .................................................. 1552

3.1 Service definition ....................................................................... 1552
3.2 Include definition ....................................................................... 1553
3.3 Characteristic definition ............................................................. 1553
3.3.1 Characteristic declaration .......................................... 1554
3.3.1.1 Characteristic Properties ............................ 1555
3.3.1.2 Characteristic Value Attribute Handle ........ 1555
3.3.1.3 Characteristic UUID ................................... 1556
3.3.2 Characteristic Value declaration ................................ 1556
3.3.3 Characteristic descriptor declarations ....................... 1556
3.3.3.1 Characteristic Extended Properties ........... 1557
3.3.3.2 Characteristic User Description .................. 1557
3.3.3.3 Client Characteristic Configuration ............ 1558
3.3.3.4 Server Characteristic Configuration ........... 1559
3.3.3.5 Characteristic Presentation Format ............ 1560

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 3, Part G Page 1536
Generic Attribute Profile (GATT)

3.3.3.6 Characteristic Aggregate Format ............... 1562

3.4 Summary of GATT Profile attribute types .................................. 1563

4 GATT feature requirements .................................................................... 1564

4.1 Overview ................................................................................... 1564
4.2 Feature support and procedure mapping .................................. 1564
4.3 Server configuration .................................................................. 1566
4.3.1 Exchange MTU .......................................................... 1566
4.4 Primary Service Discovery ........................................................ 1567
4.4.1 Discover All Primary Services .................................... 1567
4.4.2 Discover Primary Service by Service UUID ............... 1568
4.5 Relationship Discovery .............................................................. 1570
4.5.1 Find Included Services .............................................. 1570
4.6 Characteristic discovery ............................................................ 1571
4.6.1 Discover All Characteristics of a Service ................... 1571
4.6.2 Discover Characteristics by UUID ............................. 1572
4.7 Characteristic Descriptor Discovery .......................................... 1574
4.7.1 Discover All Characteristic Descriptors ...................... 1574
4.8 Characteristic Value Read ......................................................... 1575
4.8.1 Read Characteristic Value ......................................... 1575
4.8.2 Read Using Characteristic UUID ............................... 1576
4.8.3 Read Long Characteristic Value ................................ 1577
4.8.4 Read Multiple Characteristic Values .......................... 1578
4.8.5 Read Multiple Variable Length Characteristic Values 1579
4.9 Characteristic Value Write ......................................................... 1580
4.9.1 Write Without Response ............................................ 1580
4.9.2 Signed Write Without Response ................................ 1580
4.9.3 Write Characteristic Value ......................................... 1581
4.9.4 Write Long Characteristic Value ................................ 1582
4.9.5 Characteristic Value Reliable Writes .......................... 1583
4.10 Characteristic Value Notification ................................................ 1585
4.10.1 Single Notification ...................................................... 1586
4.10.2 Multiple Variable Length Notifications ........................ 1586
4.11 Characteristic Value Indication .................................................. 1586
4.11.1 Indication ................................................................... 1587
4.12 Characteristic Descriptors ......................................................... 1587
4.12.1 Read Characteristic Descriptor .................................. 1587
4.12.2 Read Long Characteristic Descriptor ......................... 1588
4.12.3 Write Characteristic Descriptor .................................. 1589
4.12.4 Write Long Characteristic Descriptor ......................... 1590
4.13 GATT procedure mapping to ATT protocol opcodes ................. 1591
4.14 Procedure timeouts ................................................................... 1594

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 3, Part G Page 1537
Generic Attribute Profile (GATT)

5 L2CAP interoperability requirements ................................................... 1595

5.1 BR/EDR L2CAP interoperability requirements .......................... 1595
5.1.1 ATT_MTU .................................................................. 1595
5.1.2 BR/EDR channel requirements ................................. 1595
5.1.3 [This section is no longer used] ................................. 1596
5.2 LE L2CAP interoperability requirements ................................... 1596
5.2.1 ATT_MTU .................................................................. 1596
5.2.2 LE channel requirements ........................................... 1596
5.3 Enhanced ATT bearer L2CAP interoperability requirements .... 1596
5.3.1 ATT_MTU .................................................................. 1597
5.3.2 Channel Requirements .............................................. 1597
5.4 L2CAP collision mitigation ......................................................... 1597
5.5 Bearer support .......................................................................... 1597

6 GAP interoperability requirements ....................................................... 1599

6.1 BR/EDR GAP interoperability requirements .............................. 1599
6.1.1 Connection Establishment ......................................... 1599
6.2 LE GAP interoperability requirements ....................................... 1599
6.2.1 Connection Establishment ......................................... 1599
6.2.2 Profile roles ................................................................ 1600
6.3 Disconnected events ................................................................. 1600
6.3.1 Notifications and indications while disconnected ....... 1600

7 Defined Generic Attribute Profile service ............................................. 1601

7.1 Service Changed ....................................................................... 1601
7.2 Client Supported Features ........................................................ 1602
7.3 Database Hash ......................................................................... 1604
7.3.1 Database Hash calculation ........................................ 1605
7.4 Server Supported Features ....................................................... 1606

8 Security considerations ......................................................................... 1607

8.1 Authentication requirements ..................................................... 1607
8.2 Authorization requirements ....................................................... 1608

9 SDP interoperability requirements ........................................................ 1609

10 References .............................................................................................. 1611

Appendix A Example ATT Server contents ...................................................... 1612

Appendix B Example Database Hash ............................................................... 1615

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 3, Part G Page 1538
Generic Attribute Profile (GATT)

1 INTRODUCTION

1.1 Scope

The Generic Attribute profile (GATT) defines a service framework using the Attribute
Protocol. This framework defines procedures and formats of services and their
characteristics. The procedures defined include discovering, reading, writing, notifying
and indicating characteristics, as well as configuring the broadcast of characteristics.

1.2 Profile dependency

Generic Access Profile

Generic Attribute Profile

Example Application
Profile

Figure 1.1: Profile dependencies

Figure 1.1 depicts the structure and the dependencies of the profiles. A profile is
dependent upon another profile if it re-uses parts of that profile by implicitly or explicitly
referencing it.

1.3 [This section is no longer used]

1.4 [This section is no longer used]

1.5 Conventions

In this Part the use of literal terms such as procedure, PDUs, opcodes, or function
names appear in italics. Specific names of fields in structures, packets, etc. also appear
in italics. The use of « » (e.g. «Primary Service») indicates a UUID. Attribute Protocol
error codes (see [Vol 3] Part F, Table 3.4) appear in italics followed by the numeric error
code.

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 3, Part G Page 1539
Generic Attribute Profile (GATT)

2 PROFILE OVERVIEW

The GATT profile is designed to be used by an application or another profile, so that a

client can communicate with a server. The server contains a number of attributes, and
the GATT Profile defines how to use the Attribute Protocol to discover, read, write and
obtain indications of these attributes, as well as configuring broadcast of attributes.

2.1 Protocol stack

Figure 2.1 shows the peer protocols used by this profile.

Application Application

Attribute Attribute
Protocol Protocol

L2CAP L2CAP

Controller Controller

Figure 2.1: Protocol model

2.2 Configurations and roles

The following roles are defined for devices that implement this profile:

Client—This is the device that initiates commands and requests towards the server and
can receive responses, indications and notifications sent by the server.

Server—This is the device that accepts incoming commands and requests from the
client and sends responses, indications and notifications to a client.

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 3, Part G Page 1540
Generic Attribute Profile (GATT)

Note: The roles are not fixed to the device. The roles are determined when a device
initiates a defined procedure, and they are released when the procedure ends.

A device can act in both roles at the same time.

An example of configurations illustrating the roles for this profile is depicted in

Figure 2.2.

Figure 2.2: Examples of configuration

In Figure 2.2, the computer is the temperature service client and the sensor is the
temperature service server. The computer initiates procedures to configure the sensor
or to read the sensor values. In this example the sensor provides information about the
characteristics the sensor device exposes as part of the temperature service and may
permit some characteristics to be written. Also, the sensor responds to read requests
with the appropriate values.

2.3 User requirements and scenarios

The following scenarios are covered by this profile:

• Exchanging configuration
• Discovery of services and characteristics on a device
• Reading a characteristic value
• Writing a characteristic value
• Notification of a characteristic value
• Indication of a characteristic value

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 3, Part G Page 1541
Generic Attribute Profile (GATT)

2.4 Profile fundamentals

This profile can be used over any physical link, using the Attribute Protocol L2CAP
channel, known as the ATT Bearer. Here is a brief summary of lower layer requirements
communication between the client and the server.

• An ATT bearer is established using “Channel Establishment” as defined in Section 6.

• The profile roles are not tied to the Controller roles (i.e. Central or Peripheral).
• On an LE Physical link, use of security features such as authorization, authentication
and encryption are optional. On a BR/EDR physical link encryption is mandatory.
• Multi-octet fields within the GATT profile shall be sent least significant octet first
(little-endian) with the exception of the Characteristic Value field. The Characteristic
Value and any fields within it shall be little-endian unless otherwise defined in the
specification which defines the characteristic.
• Multiple ATT bearers may be established between a client and a server. The server
can determine if ATT bearers are from the same client, and vice versa, by using
connection information such as the Bluetooth Device Address of the peer device.

2.5 Attribute Protocol

The GATT profile requires the implementation of the Attribute Protocol (See [Vol 3] Part
F) and those Attribute Protocol PDUs required by Section 4.2 and Section 4.13.

2.5.1 Overview

The GATT Profile uses the Attribute Protocol to transport data in the form of commands,
requests, responses, indications, notifications and confirmations between devices. This
data is contained in Attribute Protocol PDUs as specified in Figure 2.3.

1 Octet Variable Length 12 Octets (when present)

Opcode Attribute Parameters Authentication Signature

Figure 2.3: Attribute Protocol PDU

The Opcode contains the specific command, request, response, indication, notification
or confirmation opcode and a flag for authentication. The Attribute Parameters contain
data for the specific command or request or the data returned in a response, indication,
or notification. The Authentication Signature is optional and is described in [Vol 3] Part
H, Section 2.4.5.

Attribute Protocol commands and requests act on values stored in Attributes on the
server device. An Attribute is composed of four parts: Attribute Handle, Attribute Type,

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 3, Part G Page 1542
Generic Attribute Profile (GATT)

Attribute Value, and Attribute Permissions. Figure 2.4 shows a logical representation
of an Attribute. The actual representation for a given implementation is specific to that
implementation.

implementation
2 Octets 2 or 16 Octets variable length specific

Attribute Handle Attribute Type Attribute Value Attribute Permissions

Figure 2.4: Logical attribute representation

The Attribute Handle is an index corresponding to a specific Attribute. The Attribute

Type is a UUID that describes the Attribute Value. The Attribute Value is the data
described by the Attribute Type and indexed by the Attribute Handle. The Attributes
are ordered by increasing Attribute Handle values. Attribute Handle values may begin
at any value between 0x0001 and 0xFFFF. Although the Attribute Handle values are
in increasing order, following Attribute Handle values may differ by more than one.
That is to say there may be gaps between successive Attribute Handles. When the
specification requires two attribute handles to be adjacent or for one to immediately
follow one the other, such gaps are still permitted and shall be ignored.

Attribute Permissions is part of the Attribute that cannot be read from or written to using
the Attribute Protocol. It is used by the server to determine whether read or write access
is permitted for a given attribute. Attribute Permissions are established by the GATT
profile, a higher layer profile or are implementation specific if not specified.

2.5.2 Attribute caching

Attribute caching is an optimization that allows the client to discover the Attribute
information such as Attribute Handles used by the server once and use the same
Attribute information across reconnections without rediscovery. If the client does not
cache the Attribute information, then it must rediscover the Attribute information at each
reconnection. With caching, time is saved and a significant number of packets need
not be exchanged between the client and server. The Attribute information that shall be
cached by a client is the Attribute Handles of all server attributes and the GATT service
characteristics values.

Attribute Handles used by the server should not change over time. This means that
once an Attribute Handle is discovered by a client the Attribute Handle for that Attribute
should not be changed.

Some circumstances may cause servers to change the Attribute Handles used for
services, perhaps due to a factory reset or a firmware upgrade procedure being
performed. The following is only required on the server if the services on the server

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 3, Part G Page 1543
Generic Attribute Profile (GATT)

can be added, modified or removed. If GATT based services on the server cannot be
changed during the usable lifetime of the device, the Service Changed characteristic
shall not exist on the server and the client does not need to ever perform service
discovery after the initial service discovery for that server.

To support caching when a server supports changes in GATT based services, an

indication is sent by the server to clients when a service is added, removed, or modified
on the server. A client may also detect a service change by reading the Database
Hash characteristic if that characteristic exists on the server. A GATT based service is
considered modified if the binding of the Attribute Handles to the associated Attributes
grouped within a service definition are changed. Any change to the GATT service
definition characteristic values other than the Service Changed characteristic value and
the Client Supported Features characteristic value themselves shall also be considered
a modification.

For clients that have a trusted relationship (i.e. bond) with the server, the attribute
cache is valid across connections. For clients with a trusted relationship and not in a
connection when a service change occurs, the server shall send an indication when
the client reconnects to the server (see Section 7.1). For clients that do not have a
trusted relationship with the server and that do not support reading the Database Hash
characteristic, the attribute cache is valid only during the connection. Clients without
a trusted relationship that do support reading the Database Hash characteristic may
validate the attribute cache on connection setup. Clients without a trusted relationship
shall receive an indication when the service change occurs only during the current
connection.

Note: Clients without a trusted relationship that support caching must either
perform service discovery or detect service changes by reading the Database
Hash characteristic on each connection if the server supports the Service Changed
characteristic.

The server shall send an ATT_HANDLE_VALUE_IND PDU containing the range of

affected Attribute Handles that shall be considered invalid in the client’s attribute cache.
The start Attribute Handle shall be the start Attribute Handle of the service definition
containing the change and the end Attribute Handle shall be the last Attribute Handle
of the service definition containing the change. The value in the indication is composed
of two 16-bit Attribute Handles concatenated to indicate the affected Attribute Handle
range.

Note: A server may set the affected Attribute Handle range to 0x0001 to 0xFFFF to
indicate to the client to rediscover the entire set of Attribute Handles on the server.

If the Database Hash characteristic exists on the server then, each time a service
change occurs, the server shall update the Database Hash characteristic value with the
new Database Hash (see Section 7.3).

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 3, Part G Page 1544
Generic Attribute Profile (GATT)

If the Database Hash characteristic value has changed since the last time it was read,
the client shall consider its attribute cache invalid and shall not make use of the cached
information until it has performed service discovery or obtained the changed database
definitions using an out-of-band mechanism.

The client, upon receiving an ATT_HANDLE_VALUE_IND PDU containing the range of

affected Attribute Handles, shall consider the attribute cache invalid over the affected
Attribute Handle range. Any outstanding request transaction shall be considered invalid
if the Attribute Handle is contained within the affected Attribute Handle range. The
client must perform service discovery before the client uses any service that has an
attribute within the affected Attribute Handle range. Alternatively, the client may read
the Database Hash characteristic and obtain the changed database definitions using
an out-of-band mechanism. If the client receives an ATT_HANDLE_VALUE_IND PDU
during service discovery and the client has read the Database Hash characteristic prior
to the service discovery, the client may read the Database Hash characteristic again to
determine if the current service discovery can be continued or if a new service discovery
is required.

Once the server has received the ATT_HANDLE_VALUE_CFM PDU, the server can
consider the client to be aware of the updated Attribute Handles.

The client shall consider the affected Attribute Handle range to be invalid in its attribute
cache and perform the discovery procedures to restore the attribute cache. The server
shall store service changed information for all bonded devices.

2.5.2.1 Robust Caching

Robust Caching is a feature where the server sends an ATT_ERROR_RSP PDU to the
client if the server does not consider the client to be aware of a service change.

If the Database Hash and Service Changed characteristics are both present on the
server, then the server shall support the Robust Caching feature.

From the perspective of a server, each connected client is either "change-aware" or

"change-unaware" regarding changes in the database definitions. After connecting to
a server, the initial state of a client without a trusted relationship is change-aware.
The initial state of a client with a trusted relationship is unchanged from the previous
connection unless the database has been updated since the last connection, in which
case the initial state is change-unaware.

Whenever the server updates the database definitions, all connected clients become
change-unaware. A change-unaware connected client becomes change-aware when
it reads the Database Hash characteristic and then the server receives another ATT
request from the client. A change-unaware client using multiple ATT bearers shall wait

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 3, Part G Page 1545
Generic Attribute Profile (GATT)

until the server has responded to all pending requests before reading the Database
Hash characteristic (see Figure 2.5).

Client - Client -
Server
Bearer 1 Bearer 2

Database
updated

Client is
change-unaware
ATT Request 1 (Handle)

ATT Request 2 (Handle)

ATT Response (Database Out of Sync)

Attribute cache
is invalid

ATT Response (Database Out of Sync)

No pending requests on any bearer

ATT Request (UUID=Database Hash)

ATT Response (Database Hash Value)

ATT Request

Client is
change-aware

ATT Response

Figure 2.5: Transition to change-aware state for a client using multiple ATT bearers

In addition, a change-unaware connected client using exactly one ATT bearer becomes
change-aware when either of the following happen:

• The client receives and confirms a Handle Value Indication for the Service Changed
characteristic (see Figure 2.6).
• The server sends the client a response with the Error Code parameter set to
Database Out Of Sync (0x12) and then the server receives another ATT request
from the client (see Figure 2.7).

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 3, Part G Page 1546
Generic Attribute Profile (GATT)

Client Server

Database
updated

Client is
change-unaware

ATT Command (Handle)

Server ignores
the command

Service Changed Indication

Attribute cache
is invalid

ATT Command (Handle)

Server ignores
the command

Service Changed Confirmation

Client is
change-aware

ATT Command (Handle)

Server accepts
the command

ATT Request (Handle)

ATT Response (Success)

Figure 2.6: Transition to change-aware state for a client using exactly one ATT bearer, triggered by a
Service Changed confirmation

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 3, Part G Page 1547
Generic Attribute Profile (GATT)

Client Server

Database
updated

Client is
change-unaware

ATT Command (Handle)

Server ignores
the command

ATT Request (Handle) OR ATT Request (UUID=Database Hash)

ATT Comman Read)

d (Handle) Sync OR Hash
(D atabase Out Of
ATT Response

Server ignores
the command

Attribute cache
is invalid

ATT Request

Client is
change-aware

ATT Response (Success)

ATT Command (Handle)

Server accepts
the command

Figure 2.7: Transition to change-aware state for a client using exactly one ATT bearer, triggered by the
ATT response "Database Out Of Sync" or "Hash Read"

If a client that has indicated support for robust caching (by setting the Robust Caching
bit in the Client Supported Features characteristic) is change-unaware then the server
shall send an ATT_ERROR_RSP PDU with the Error Code parameter set to Database
Out Of Sync (0x12) when either of the following happen:

• That client requests an operation at any Attribute Handle or list of Attribute Handles
by sending an ATT request.
• That client sends an ATT_READ_BY_TYPE_REQ PDU with Attribute Type other than
«Include» or «Characteristic» and an Attribute Handle range other than 0x0001 to
0xFFFF.

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 3, Part G Page 1548
Generic Attribute Profile (GATT)

The ATT_ERROR_RSP PDU is sent only once per bearer after the client becomes
change-unaware, unless the client disconnects or the database changes again before
the client becomes change-aware in which case the ATT_ERROR_RSP PDU shall
be sent again. If a change-unaware client sends an ATT command, the server shall
ignore it. Except for a Handle Value Indication for the Service Changed characteristic,
the server shall not send notifications and indications to such a client until it becomes
change-aware. If a client is change-aware, then the server shall perform the operation
normally.

Note: To reduce the probability of blocked notifications and indications, servers should
send this indication as soon as possible after a service change.

If a client receives an ATT_ERROR_RSP PDU with the Error Code parameter set to
Database Out Of Sync (0x12), it shall consider its attribute cache invalid and shall not
make use of the cached information until it has performed service discovery or obtained
the changed database definitions using an out-of-band mechanism.

2.5.3 Attribute grouping

The Generic Attribute Profile defines the grouping of attributes for three
attribute types: «Primary Service», «Secondary Service» and «Characteristic».
A group begins with a declaration, and ends as defined in Section 3.1 for
services and Section 3.3 for characteristics. Not all of the grouping attributes
can be used in the ATT_READ_BY_GROUP_TYPE_REQ PDU. The «Primary
Service» and «Secondary Service» grouping types may be used in the
ATT_READ_BY_GROUP_TYPE_REQ PDU. The «Characteristic» grouping type shall
not be used in the ATT_READ_BY_GROUP_TYPE_REQ PDU.

2.5.4 UUIDs

All 16-bit UUIDs shall be contained in exactly 2 octets. All 128-bit UUIDs shall be
contained in exactly 16 octets.

All 32-bit UUIDs shall be converted to 128-bit UUIDs when the UUID is contained in an
ATT PDU. See [Vol 3] Part B, Section 2.5.1 for the method of conversion.

2.6 GATT Profile hierarchy

2.6.1 Overview

The GATT Profile specifies the structure in which profile data is exchanged. This
structure defines basic elements such as services and characteristics, used in a profile.
All of the elements are contained by Attributes. Attributes used in the Attribute Protocol
are containers that carry this profile data.

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 3, Part G Page 1549
Generic Attribute Profile (GATT)

The top level of the hierarchy is a profile. A profile is composed of one or more services
necessary to fulfill a use case. A service is composed of characteristics or inclusions
of other services. Each characteristic contains a value and may contain optional
information about the value. The service and characteristic and the components of the
characteristic (i.e. value and descriptors) contain the profile data and are all stored in
Attributes on the server.

Profile

Service Service

Include Include

Include Include

Characteristic Characteristic
Properties Properties

Value Value

Descriptor Descriptor

Descriptor Descriptor

Characteristic Characteristic
Properties Properties

Value Value

Descriptor Descriptor

Descriptor Descriptor

Figure 2.8: GATT Profile hierarchy

2.6.2 Service

A service is a collection of data and associated behaviors to accomplish a particular

function or feature. In GATT, a service is defined by its service definition. A service
definition may contain included services, mandatory characteristics, and optional
characteristics.

To maintain backward compatibility with earlier clients, later versions of a service

definition can only add new included services or optional characteristics. Later versions
of a service definition are forbidden from changing behaviors from previous versions of
the service definition.

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 3, Part G Page 1550
Generic Attribute Profile (GATT)

There are two types of services: primary service and secondary service. A primary
service is a service that exposes functionality of this device. A primary service can be
included by another service. Primary services can be discovered using Primary Service
Discovery procedures. A secondary service is a service that should only be included
from a primary service or another secondary service or other higher layer specification.
A secondary service is only relevant in the context of the entity that includes it.

The determination of whether a service is either a primary or secondary service can be

mandated by a higher layer specification.

Note: There is no procedure for discovering secondary services.

Services may be used in one or more higher layer specifications to fulfill a particular use
case.

The service definition is described in Section 3.1.

2.6.3 Included services

An included service is a method to reference another service definition existing on

the server into the service being defined. To include another service, an include
definition is used at the beginning of the service definition. When a service definition
uses an include definition to include a service, the entire included service definition
becomes part of the new service definition. This includes all the included services
and characteristics of the included service. The included service still exists as an
independent service. A service that is included by another service shall not be changed
by the act of inclusion or by the including service. There are no limits to the number of
include definitions or the depth of nested includes in a service definition.

The include definition is described in Section 3.2.

2.6.4 Characteristic

A characteristic is a value used in a service along with properties and configuration

information about how the value is accessed and information about how the value
is displayed or represented. In GATT, a characteristic is defined by its characteristic
definition. A characteristic definition contains a characteristic declaration, characteristic
properties, and a value and may contain descriptors that describe the value or permit
configuration of the server with respect to the characteristic.

The characteristic definition is described in Section 3.3.

2.7 Configured Broadcast

For LE physical links, Configured Broadcast is a method for a client to indicate to
a server which Characteristic Value shall be broadcast in the advertising data when

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 3, Part G Page 1551
Generic Attribute Profile (GATT)

the server is executing the Broadcast mode procedure. For BR/EDR physical links,
Configured Broadcast is not supported.

To configure a Characteristic Value to be broadcast by the server when in Broadcast

mode, the client sets the broadcast configuration bit described in Section 3.3.3.4. The
frequency of the broadcast is part of the service behavior definition. The data shall
be broadcast as part of the Service Data Advertising Data type as defined in Section
1.11 of [3]. If multiple characteristics can simultaneously be enabled for broadcast, the
service specification defines how the characteristics are to be formatted in the service
data which follows the service UUID in the Service Data Advertising Data type payload.

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 3, Part G Page 1552
Generic Attribute Profile (GATT)

3 SERVICE INTEROPERABILITY REQUIREMENTS

3.1 Service definition

A service definition shall contain a service declaration and may contain include
definitions and characteristic definitions. The service definition ends before the next
service declaration or after the maximum Attribute Handle is reached. Service
definitions appear on the server in an order based on Attribute Handle.

All include definitions and characteristic definitions contained within the service
definition are considered to be part of the service. All include definitions shall
immediately follow the service declaration and precede any characteristic definitions. A
service definition may have zero or more include definitions. All characteristic definitions
shall be immediately following the last include definition or, in the event of no include
definitions, immediately following the service declaration. A service definition may
have zero or more characteristic definitions. There is no upper limit for include or
characteristic definitions.

A service declaration is an Attribute with the Attribute Type set to the UUID for «Primary
Service» or «Secondary Service». The Attribute Value shall be the 16-bit Bluetooth
UUID or 128-bit UUID for the service, known as the service UUID. A client shall
support the use of both 16-bit and 128-bit UUIDs. A client may ignore any service
definition with an unknown service UUID. An unknown service UUID is a UUID for an
unsupported service. The Attribute Permissions shall be read-only and shall not require
authentication or authorization.

When multiple services exist, services definitions with service declarations using 16-
bit Bluetooth UUID should be grouped together (i.e. listed sequentially) and services
definitions with service declarations using 128-bit UUID should be grouped together.

Attribute Attribute Type Attribute Value Attribute Permission

Handle
0xNNNN 0x2800 – UUID for «Primary 16-bit Bluetooth UUID or Read Only,
Service» OR 0x2801 for «Sec- 128-bit UUID for Service No Authentication,
ondary Service»
No Authorization

Table 3.1: Service declaration

A device or higher level specification may have multiple service definitions and may
have multiple service definitions with the same service UUID.

All Attributes on a server shall either contain a service declaration or exist within a
service definition.

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 3, Part G Page 1553
Generic Attribute Profile (GATT)

Service definitions contained in a server may appear in any order; a client shall not
assume the order of service definitions on a server.

3.2 Include definition

An include definition shall contain only one include declaration.

The include declaration is an Attribute with the Attribute Type set to the UUID for
«Include». The Attribute Value shall be set to the included service Attribute Handle,
the End Group Handle, and the service UUID. The Service UUID shall only be present
when the UUID is a 16-bit Bluetooth UUID.The Attribute Permissions shall be read only
and not require authentication or authorization.

Attribute Attribute Attribute Value Attribute Permission

Handle Type
0xNNNN 0x2802 – Included Service End Group Service Read Only,
UUID for Attribute Handle Handle UUID No Authentication,
«Include»
No Authorization

Table 3.2: Include declaration

A server shall not contain a service definition with an include definition to another
service that includes the original service. This applies to each of the services the
included definition references. This is referred to as a circular reference.

If the client detects a circular reference or detects nested include declarations to a

greater level than it expects, it should terminate or stop using the ATT bearer.

3.3 Characteristic definition

A characteristic definition shall contain a characteristic declaration, a Characteristic
Value declaration and may contain characteristic descriptor declarations. A
characteristic definition ends at the start of the next characteristic declaration or service
declaration or after the maximum Attribute Handle. Characteristic definitions appear on
the server within a service definition in an order based on Attribute Handle.

Each declaration above is contained in a separate Attribute. The two required

declarations are the characteristic declaration and the Characteristic Value declaration.
The Characteristic Value declaration shall exist immediately following the characteristic
declaration. Any optional characteristic descriptor declarations are placed after the
Characteristic Value declaration. The order of the optional characteristic descriptor
declarations is not significant.

A characteristic definition may be defined to concatenate several Characteristic Values

into a single aggregated Characteristic Value. This may be used to optimize read

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 3, Part G Page 1554
Generic Attribute Profile (GATT)

and writes of multiple Characteristic Values through the reading and writing of a
single aggregated Characteristic Value. This type of characteristic definition is the
same as a normal characteristic definition. The characteristic declaration shall use
a characteristic UUID that is unique to the aggregated characteristic definition. The
aggregated characteristic definition may also contain a characteristic aggregate format
descriptor that describes the display format of the aggregated Characteristic Value.

3.3.1 Characteristic declaration

A characteristic declaration is an Attribute with the Attribute Type set to the UUID for
«Characteristic» and Attribute Value set to the Characteristic Properties, Characteristic
Value Attribute Handle and Characteristic UUID. The Attribute Permissions shall be
readable and not require authentication or authorization.

If the server changes any characteristic declaration Attribute Value while the server has
a trusted relationship with any client, then it shall send each client a Service Changed
Indication indicating a change in the service holding the Characteristic Declaration (see
Section 7.1).

Attribute Attribute Attribute Value Attribute Permissions

Handle Types
0xNNNN 0x2803–UUID Character- Characteristic Character- Read Only,
for «Character- istic Proper- Value Attribute istic UUID No Authentication,
istic» ties Handle
No Authorization

Table 3.3: Characteristic declaration

The Attribute Value of a characteristic declaration is read only.

Attribute Value Size Description

Characteristic Properties 1 octets Bit field of characteristic properties
Characteristic Value Handle 2 octets Handle of the Attribute containing the value of this
characteristic
Characteristic UUID 2 or 16 octets 16-bit Bluetooth UUID or 128-bit UUID for Character-
istic Value

Table 3.4: Attribute Value field in characteristic declaration

A service may have multiple characteristic definitions with the same Characteristic
UUID.

Within a service definition, some characteristics may be mandatory and those

characteristics shall be located after the include declarations and before any optional
characteristics within the service definition. A client shall not assume any order
of those characteristics that are mandatory or any order of those characteristics

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 3, Part G Page 1555
Generic Attribute Profile (GATT)

that are optional within a service definition. Whenever possible and within the
requirements stated earlier, characteristics definitions with characteristic declarations
using 16-bit Bluetooth UUIDs should be grouped together (i.e. listed sequentially) and
characteristics definitions with characteristic declarations using 128-bit UUIDs should be
grouped together.

3.3.1.1 Characteristic Properties

The Characteristic Properties bit field determines how the Characteristic Value can be
used, or how the characteristic descriptors (see Section 3.3.3) can be accessed. If the
bits defined in Table 3.5 are set, the action described is permitted. Multiple characteristic
properties can be set.

These bits shall be set according to the procedures allowed for this characteristic, as
defined by higher layer specifications, without regard to security requirements.

Properties Value Description

Broadcast 0x01 If set, permits broadcasts of the Characteristic Value using Server Charac-
teristic Configuration Descriptor. If set, the Server Characteristic Configu-
ration Descriptor shall exist.
Read 0x02 If set, permits reads of the Characteristic Value using procedures defined
in Section 4.8
Write Without 0x04 If set, permit writes of the Characteristic Value without response using
Response procedures defined in Section 4.9.1.
Write 0x08 If set, permits writes of the Characteristic Value with response using proce-
dures defined in Section 4.9.3 or Section 4.9.4.
Notify 0x10 If set, permits notifications of a Characteristic Value without acknowledg-
ment using the procedure defined in Section 4.10. If set, the Client Char-
acteristic Configuration Descriptor shall exist.
Indicate 0x20 If set, permits indications of a Characteristic Value with acknowledgment
using the procedure defined in Section 4.11. If set, the Client Characteris-
tic Configuration Descriptor shall exist.
Authenticated 0x40 If set, permits signed writes to the Characteristic Value using the proce-
Signed Writes dure defined in Section 4.9.2.
Extended Prop- 0x80 If set, additional characteristic properties are defined in the Characteristic
erties Extended Properties Descriptor defined in Section 3.3.3.1. If set, the Char-
acteristic Extended Properties Descriptor shall exist.

Table 3.5: Characteristic Properties bit field

3.3.1.2 Characteristic Value Attribute Handle

The Characteristic Value Attribute Handle field is the Attribute Handle of the Attribute
that contains the Characteristic Value.

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 3, Part G Page 1556
Generic Attribute Profile (GATT)

3.3.1.3 Characteristic UUID

The Characteristic UUID field is a 16-bit Bluetooth UUID or 128-bit UUID that describes
the type of Characteristic Value. A client shall support the use of both 16-bit and 128-bit
Characteristic UUIDs. A client may ignore any characteristic definition with an unknown
Characteristic UUID. An unknown characteristic UUID is a UUID for an unsupported
characteristic.

3.3.2 Characteristic Value declaration

The Characteristic Value declaration contains the value of the characteristic. It is the
first Attribute after the characteristic declaration. All characteristic definitions shall have
a Characteristic Value declaration.

A Characteristic Value declaration is an Attribute with the Attribute Type set to the
16-bit Bluetooth or 128-bit UUID for the Characteristic Value used in the characteristic
declaration. The Attribute Value is set to the Characteristic Value. The Attribute
Permissions are specified by the service or may be implementation specific if not
specified otherwise.

Attribute Attribute Type Attribute Value Attribute Permissions

Handle
0xNNNN 0xUUUU – 16-bit Bluetooth Characteristic Val- Higher layer profile or imple-
UUID or 128-bit UUID for ue mentation specific
Characteristic UUID

Table 3.6: Characteristic Value declaration

3.3.3 Characteristic descriptor declarations

Characteristic descriptors are used to contain related information about the

Characteristic Value. The GATT profile defines a standard set of characteristic
descriptors that can be used by higher layer profiles. Higher layer profiles may
define additional characteristic descriptors that are profile specific. Each characteristic
descriptor is identified by the characteristic descriptor UUID. A client shall support the
use of both 16-bit and 128-bit characteristic descriptor UUIDs. A client may ignore any
characteristic descriptor declaration with an unknown characteristic descriptor UUID. An
unknown characteristic descriptor UUID is a UUID for an unsupported characteristic
descriptor.

Characteristic descriptors if present within a characteristic definition shall follow the

Characteristic Value declaration. The characteristic descriptor declaration may appear
in any order within the characteristic definition. The client shall not assume the order
in which a characteristic descriptor declaration appears in a characteristic definition
following the Characteristic Value declaration.

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 3, Part G Page 1557
Generic Attribute Profile (GATT)

Characteristic descriptor declaration permissions are defined by a higher layer profile

or are implementation specific. A client shall not assume all characteristic descriptor
declarations are readable.

3.3.3.1 Characteristic Extended Properties

The Characteristic Extended Properties declaration is a descriptor that defines

additional Characteristic Properties. If the Extended Properties bit of the Characteristic
Properties is set then this characteristic descriptor shall exist. The characteristic
descriptor may occur in any position within the characteristic definition after the
Characteristic Value. Only one Characteristic Extended Properties declaration shall exist
in a characteristic definition.

The characteristic descriptor is contained in an Attribute and the Attribute Type shall
be set to the UUID for «Characteristic Extended Properties» and the Attribute Value
shall be two octets in length and shall contain the Characteristic Extended Properties
Bit Field. The Attribute Permissions shall be readable without authentication and
authorization being required.

Attribute Attribute Type Attribute Value Attribute Permissions

Handle
0xNNNN 0x2900 – UUID for «Charac- Characteristic Extended Read Only,
teristic Extended Properties» Properties Bit Field No Authentication,
No Authorization

Table 3.7: Characteristic Extended Properties declaration

The Characteristic Extended Properties bit field describes additional properties on

how the Characteristic Value can be used, or how the characteristic descriptors (see
Section 3.3.3.3) can be accessed. If the bits defined in Table 3.8 are set, the action
described is permitted. Multiple additional properties can be set.

Bit Number Property Description

0 Reliable Write If set, permits reliable writes of the Characteristic Value using the
procedure defined in Section 4.9.5
1 Writable Auxiliaries If set, permits writes to the characteristic descriptor defined in
Section 3.3.3.2
All other bits Reserved for future use

Table 3.8: Characteristic Extended Properties bit field

3.3.3.2 Characteristic User Description

The Characteristic User Description declaration is an optional characteristic descriptor

that defines a UTF-8 string of variable size that is a user textual description of

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 3, Part G Page 1558
Generic Attribute Profile (GATT)

the Characteristic Value. If the Writable Auxiliaries bit of the Characteristic Extended
Properties is set then this characteristic descriptor can be written. The characteristic
descriptor may occur in any position within the characteristic definition after the
Characteristic Value. Only one Characteristic User Description declaration shall exist
in a characteristic definition.

The characteristic descriptor is contained in an Attribute and the Attribute Type shall be
set to the UUID for «Characteristic User Description» and the Attribute Value shall be
set to the characteristic user description UTF-8 string. The Attribute Permissions are
specified by the profile or may be implementation specific if not specified otherwise.

Attribute Attribute Type Attribute Value Attribute Permissions

Handle
0xNNNN 0x2901 – UUID for Characteristic User De- Higher layer profile or imple-
«Characteristic User De- scription UTF-8 String mentation specific
scription»

Table 3.9: Characteristic User Description declaration

3.3.3.3 Client Characteristic Configuration

The Client Characteristic Configuration declaration is an optional characteristic

descriptor that defines how the characteristic may be configured by a specific client.
The Client Characteristic Configuration descriptor value shall be persistent across
connections for bonded devices. The Client Characteristic Configuration descriptor
value shall be set to the default value at each connection with non-bonded devices.The
characteristic descriptor value is a bit field. When a bit is set, that action shall
be enabled, otherwise it will not be used. The Client Characteristic Configuration
descriptor may occur in any position within the characteristic definition after the
Characteristic Value. Only one Client Characteristic Configuration declaration shall exist
in a characteristic definition.

A client may write this configuration descriptor to control the configuration of this
characteristic on the server for the client. Each client has its own instantiation of the
Client Characteristic Configuration. Reads of the Client Characteristic Configuration
only shows the configuration for that client and writes only affect the configuration of
that client. Authentication and authorization may be required by the server to write
the configuration descriptor. The Client Characteristic Configuration declaration shall be
readable and writable.

The characteristic descriptor is contained in an Attribute. The Attribute Type shall be

set to the UUID for «Client Characteristic Configuration». The Attribute Value shall
be two octets in length and shall be set to the characteristic descriptor value. The
Attribute Permissions are specified by the profile or may be implementation specific if
not specified otherwise.

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 3, Part G Page 1559
Generic Attribute Profile (GATT)

Attribute Attribute Type Attribute Value Attribute Permissions

Handle
0xNNNN 0x2902 – UUID for Characteristic Readable with no authentication or authoriza-
«Client Character- Configuration tion.
istic Configuration» Bits Writable with authentication and authorization
defined by a higher layer specification or is
implementation specific.

Table 3.10: Client Characteristic Configuration declaration

The following Client Characteristic Configuration bits are defined:

Bit Number Configuration Description

0 Notification The Characteristic Value shall be notified. This value shall only be set
if the characteristic’s properties have the notify bit set.
1 Indication The Characteristic Value shall be indicated. This value shall only be
set if the characteristic’s properties have the indicate bit set.
All other bits Reserved for future use.

Table 3.11: Client Characteristic Configuration bit field definition

If both the Notification and Indication bits are set, then the server shall use the
notification procedure (see Section 4.10) when an acknowledgment is not required by a
higher-layer specification or shall use the indication procedure (see Section 4.11) when
an acknowledgment is required. The server should not use both procedures to send the
same characteristic value.

The server may reject a request to set both the Notification and Indication bits for the
same characteristic.

The default value for the Client Characteristic Configuration descriptor value shall be
0x0000.

Between a client and a server there shall be a single Client Characteristic Configuration
Descriptor irrespective of the number of ATT bearers between them.

3.3.3.4 Server Characteristic Configuration

The Server Characteristic Configuration declaration is an optional characteristic

descriptor that defines how the characteristic may be configured for the server. The
characteristic descriptor value is a bit field. When a bit is set, that action shall
be enabled, otherwise it will not be used. The Server Characteristic Configuration
descriptor may occur in any position within the characteristic definition after the
Characteristic Value. Only one Server Characteristic Configuration declaration shall
exist in a characteristic definition. The Server Characteristic Configuration declaration
shall be readable and writable.

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 3, Part G Page 1560
Generic Attribute Profile (GATT)

A client may write this configuration descriptor to control the configuration of this
characteristic on the server for all clients. There is a single instantiation of the
Server Characteristic Configuration for all clients. Reads of the Server Characteristic
Configuration shows the configuration all clients and writes affect the configuration for
all clients. Authentication and authorization may be required by the server to write the
configuration descriptor.

The characteristic descriptor is contained in an Attribute. The Attribute Type shall be

set to the UUID for «Server Characteristic Configuration». The Attribute Value shall
be two octets in length and shall be set to the characteristic descriptor value. The
Attribute Permissions are specified by the profile or may be implementation specific if
not specified otherwise.

Attribute Attribute Type Attribute Value Attribute Permissions

Handle
0xNNNN 0x2903 – UUID for Characteristic Readable with no authentication or authoriza-
«Server Character- Configuration tion.
istic Configuration» Bits Writable with authentication and authorization
defined by a higher layer specification or is
implementation specific.

Table 3.12: Server Characteristic Configuration declaration

The following Server Characteristic Configuration bits are defined:

Bit Number Configuration Description

0 Broadcast The Characteristic Value shall be broadcast when the server is in
the broadcast procedure if advertising data resources are available.
This value can only be set if the characteristic’s properties have the
broadcast bit set.
All other bits Reserved for future use.

Table 3.13: Server Characteristic Configuration bit field definition

3.3.3.5 Characteristic Presentation Format

The Characteristic Presentation Format declaration is an optional characteristic

descriptor that defines the format of the Characteristic Value. The characteristic
descriptor may occur in any position within the characteristic definition after the
Characteristic Value. If more than one Characteristic Presentation Format declaration
exists in a characteristic definition, then a Characteristic Aggregate Format declaration
shall exist as part of the characteristic definition.

The characteristic presentation format value is composed of five parts: format,

exponent, unit, name space, and description.

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 3, Part G Page 1561
Generic Attribute Profile (GATT)

The characteristic descriptor is contained in an Attribute. The Attribute Type shall be set
to the UUID for «Characteristic Presentation Format». The Attribute Value shall be set
to the characteristic descriptor value. The Attribute Permissions shall be read only and
not require authentication or authorization.

Attribute Attribute Type Attribute Value Attribute

Handle Permissions
0xNNNN 0x2904 – UUID For- Expo- Unit Name De- Read only
for «Characteris- mat nent Space scrip-
No Authentication,
tic Presentation tion
Format» No Authorization

Table 3.14: Characteristic Presentation Format declaration

The definition of the Characteristic Presentation Format descriptor Attribute Value field
is the following.

Field Name Value Size Description

Format 1 octet Format of the value of this characteristic as defined in [1].
Exponent 1 octet Exponent field to determine how the value of this characteristic is further
formatted.
Unit 2 octets The unit of this characteristic as defined in [1]
Name Space 1 octet The name space of the description as defined in [1]
Description 2 octets The description of this characteristic as defined in a higher layer profile.

Table 3.15: Characteristic Presentation Format value definition

3.3.3.5.1 Bit ordering

The bit ordering used for the Characteristic Presentation Format descriptor shall be
little-endian.

3.3.3.5.2 Format

The format field determines how a single value contained in the Characteristic Value is
formatted. The values of this field are defined in Assigned Numbers [1].

3.3.3.5.3 Exponent

The exponent field is used with integer data types to determine how the value is further
formatted. The exponent field is only used on integer format types. The exponent field
has type sint8.

actual value = Characteristic Value × 10Exponent

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 3, Part G Page 1562
Generic Attribute Profile (GATT)

As can be seen in the above equation, the actual value is a combination of the
Characteristic Value and the value 10 to the power Exponent. This is sometimes known
as a fixed point number.

For example, if the Exponent is 2 and the Characteristic Value is 23, the actual value
would be 2300.

For example, if the Exponent is -3 and the Characteristic Value is 3892, the actual value
would be 3.892.

3.3.3.5.4 Unit

The Unit is a UUID as defined in Assigned Numbers [1].

3.3.3.5.5 Name Space

The Name Space field is used to identify the organization, as defined in Assigned
Numbers [1], that is responsible for defining the enumerations for the description field.

3.3.3.5.6 Description

The Description is an enumerated value as defined in Assigned Numbers [1] from the
organization identified by the Name Space field.

3.3.3.6 Characteristic Aggregate Format

The Characteristic Aggregate Format declaration is an optional characteristic descriptor

that defines the format of an aggregated Characteristic Value.

The characteristic descriptor may occur in any position within the characteristic
definition after the Characteristic Value. Only one Characteristic Aggregate Format
declaration shall exist in a characteristic definition.

The Characteristic Aggregate Format value is composed of a list of Attribute Handles of

Characteristic Presentation Format declarations, where each Attribute Handle points to
a Characteristic Presentation Format declaration.

The Attribute Permissions shall be read only and not require authentication or
authorization.

Attribute Attribute Type Attribute Value Attribute Permissions

Handle
0xNNNN 0x2905 – UUID for List of Attribute Handles for the Read only
«Characteristic Aggre- Characteristic Presentation For- No authentication
gate Format» mat Declarations
No authorization

Table 3.16: Characteristic Aggregate Format declaration

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 3, Part G Page 1563
Generic Attribute Profile (GATT)

The List of Attribute Handles is the concatenation of multiple 16-bit Attribute Handle
values into a single Attribute Value. The list shall contain at least two Attribute Handle
for Characteristic Presentation Format declarations. The Characteristic Value shall be
decomposed by each of the Characteristic Presentation Format declarations pointed to
by the Attribute Handles. The order of the Attribute Handles in the list is significant.

If more than one Characteristic Presentation Format declarations exist in a

characteristic definition, there shall also be one Characteristic Aggregate Format
declaration. The Characteristic Aggregate Format declaration shall include each
Characteristic Presentation Format declaration in the characteristic definition in the
list of Attribute Handles. Characteristic Presentation Format declarations from other
characteristic definitions may also be used.

A Characteristic Aggregate Format declaration may exist without a Characteristic

Presentation Format declaration existing in the characteristic definition. The
Characteristic Aggregate Format declaration may use Characteristic Presentation
Format declarations from other characteristic definitions.

3.4 Summary of GATT Profile attribute types

Table 3.17 summarizes the attribute types defined by the GATT Profile.

Attribute Type UUID Description

«Primary Service» 0x2800 Primary Service Declaration
«Secondary Service» 0x2801 Secondary Service Declaration
«Include» 0x2802 Include Declaration
«Characteristic» 0x2803 Characteristic Declaration
«Characteristic Extended Properties» 0x2900 Characteristic Extended Properties
«Characteristic User Description» 0x2901 Characteristic User Description Descriptor
«Client Characteristic Configuration» 0x2902 Client Characteristic Configuration Descriptor
«Server Characteristic Configuration» 0x2903 Server Characteristic Configuration Descriptor
«Characteristic Presentation Format» 0x2904 Characteristic Presentation Format Descriptor
«Characteristic Aggregate Format» 0x2905 Characteristic Aggregate Format Descriptor

Table 3.17: Summary of GATT Profile attribute types

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 3, Part G Page 1564
Generic Attribute Profile (GATT)

4 GATT FEATURE REQUIREMENTS

4.1 Overview

There are 11 features defined in the GATT Profile:

1. Server Configuration
2. Primary Service Discovery
3. Relationship Discovery
4. Characteristic Discovery
5. Characteristic Descriptor Discovery
6. Reading a Characteristic Value
7. Writing a Characteristic Value
8. Notification of a Characteristic Value
9. Indication of a Characteristic Value
10. Reading a Characteristic Descriptor
11. Writing a Characteristic Descriptor

Each of the features is mapped to procedures and sub-procedures. These procedures

and sub-procedures describe how the Attribute Protocol is used to accomplish the
corresponding feature.

4.2 Feature support and procedure mapping

Table 4.1 maps each feature to the procedures used for that feature, and indicates
whether the procedure is optional or mandatory for that feature. The procedures are
described in the referenced section.

If an ATT PDU is supported on any ATT bearer, then it shall be supported on all
supported ATT bearers with the following exceptions:

• The Exchange MTU sub-procedure shall only be supported on the LE Fixed Channel
Unenhanced ATT bearer.
• The Signed Write Without Response sub-procedure shall only be supported on the LE
Fixed Channel Unenhanced ATT bearer.

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 3, Part G Page 1565
Generic Attribute Profile (GATT)

Feature Sub-Procedure Ref. Support in Support in

Client Server
Server Configuration Exchange MTU 4.3.1 O O
Primary Service Discov- Discover All Primary Serv- 4.4.1 O M
ery ices
Discover Primary Service 4.4.2 O M
By Service UUID
Relationship Discovery Find Included Services 4.5.1 O M
Characteristic Discovery Discover All Characteristics 4.6.1 O M
of a Service
Discover Characteristics by 4.6.2 O M
UUID
Characteristic Descriptor Discover All Characteristic 4.7.1 O M
Discovery Descriptors
Characteristic Value Read Characteristic Value 4.8.1 O M
Read
Read Using Characteristic 4.8.2 O M
UUID
Read Long Characteristic 4.8.3 O C.4
Value
Read Multiple Characteris- 4.8.4 O O
tic Values
Read Multiple Variable 4.8.5 O C.4
Length Characteristic Val-
ues
Characteristic Value Write Without Response 4.9.1 O C.1
Write
Signed Write Without Re- 4.9.2 O O
sponse
Write Characteristic Value 4.9.3 O C.2
Write Long Characteristic 4.9.4 O C.4
Value
Characteristic Value Relia- 4.9.5 O O
ble Writes
Characteristic Value No- Single Notification 4.10.1 C.4 C.4
tification
Multiple Variable Length 4.10.2 C.4 C.4
Notifications
Characteristic Value In- Indication 4.11.1 M C.3
dication

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 3, Part G Page 1566
Generic Attribute Profile (GATT)

Feature Sub-Procedure Ref. Support in Support in

Client Server
Characteristic Descriptor Read Characteristic De- 4.12.1 O C.4
Value Read scriptor
Read Long Characteristic 4.12.2 O C.4
Descriptor
Characteristic Descriptor Write Characteristic De- 4.12.3 O C.4
Value Write scriptor
Write Long Characteristic 4.12.4 O O
Descriptor
C.1: Write Without Response is mandatory if Signed Write Without Response or Enhanced ATT
Bearers are supported otherwise optional
C.2: Write Characteristic Value is mandatory if Write Long Characteristic Value or Enhanced ATT
Bearers are supported otherwise optional
C.3: If Service Changed Characteristic is present, this feature is mandatory, otherwise optional.
C.4: If Enhanced ATT Bearers are supported then this feature is mandatory, otherwise optional.

Table 4.1: GATT feature mapping to procedures

4.3 Server configuration

This procedure is used by the client to configure the Attribute Protocol. This procedure
has only one sub-procedure used to set the MTU sizes.

4.3.1 Exchange MTU

This sub-procedure is used by the client to set the ATT_MTU to the maximum possible
value that can be supported by both devices when the client supports a value greater
than the default ATT_MTU for the Attribute Protocol. This sub-procedure shall only be
initiated once during a connection.

This sub-procedure shall not be used on a BR/EDR physical link since the MTU size is
negotiated using L2CAP channel configuration procedures.

The ATT_EXCHANGE_MTU_REQ PDU is used by this sub-procedure. The Client Rx

MTU parameter shall be set to the maximum MTU that this client can receive.

Two possible responses can be sent from the server for

the ATT_EXCHANGE_MTU_REQ PDU: ATT_EXCHANGE_MTU_RSP and
ATT_ERROR_RSP PDUs.

An ATT_ERROR_RSP PDU is returned if an error occurred on the server.

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 3, Part G Page 1567
Generic Attribute Profile (GATT)

The server shall respond to this message with an ATT_EXCHANGE_MTU_RSP PDU

with the Server Rx MTU parameter set to the maximum MTU that this server can
receive.

If the ATT_ERROR_RSP PDU is sent by the server with the Error Code parameter set
to Request Not Supported (0x06), the Attribute Opcode is not supported and the default
MTU shall be used.

Once the messages have been exchanged, the ATT_MTU shall be set to the minimum
of the Client Rx MTU and Server Rx MTU values.

Client Server

ATT_EXCHANGE_MTU_REQ (0x0200)

ATT_EXCHANGE_MTU_RSP (0x0032)

Figure 4.1: Exchange MTU

For example, in Figure 4.1, based on the exchanged ATT_MTU values, the ATT_MTU
would be 0x0032.

4.4 Primary Service Discovery

This procedure is used by a client to discover primary services on a server. Once the
primary services are discovered, additional information about the primary services can
be accessed using other procedures, including characteristic discovery and relationship
discovery to find other related primary and secondary services.

There are two sub-procedures that can be used for primary service discovery: Discover
All Primary Services and Discover Primary Service by Service UUID.

4.4.1 Discover All Primary Services

This sub-procedure is used by a client to discover all the primary services on a server.

The ATT_READ_BY_GROUP_TYPE_REQ PDU shall be used with the Attribute Type

parameter set to the UUID for «Primary Service». The Starting Handle shall be set to
0x0001 and the Ending Handle shall be set to 0xFFFF.

Two possible responses can be sent from the server for the
ATT_READ_BY_GROUP_TYPE_REQ PDU: ATT_READ_BY_GROUP_TYPE_RSP
and ATT_ERROR_RSP PDUs.

An ATT_ERROR_RSP PDU is returned if an error occurred on the server.

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 3, Part G Page 1568
Generic Attribute Profile (GATT)

The ATT_READ_BY_GROUP_TYPE_RSP PDU returns a list of Attribute Handle, End

Group Handle, and Attribute Value tuples corresponding to the services supported
by the server. Each Attribute Value contained in the response is the Service UUID
of a service supported by the server. The Attribute Handle is the handle for the
service declaration. The End Group Handle is the handle of the last attribute within
the service definition. The End Group Handle of the last service in a device can
be 0xFFFF. The ATT_READ_BY_GROUP_TYPE_REQ PDU shall be issued again
with the Starting Handle set to one greater than the last End Group Handle in the
ATT_READ_BY_GROUP_TYPE_RSP PDU.

This sub-procedure is complete when the ATT_ERROR_RSP PDU is received and the
Error Code parameter is set to Attribute Not Found (0x0A) or when the End Group
Handle in the Read by Type Group Response is 0xFFFF.

The sub-procedure may end early if a desired primary service is found prior to
discovering all the primary services on the server.

The service declaration described in Section 3.1 specifies that the service declaration
is readable and requires no authentication or authorization, therefore insufficient
authentication or read not permitted errors shall not occur.

Client Server

ATT_READ_BY_GROUP_TYPE_REQ (0x0001, 0xFFFF, «Primary Service»)

ATT_READ_BY_GROUP_TYPE_RSP (0x06, 0x0001, 0x000F, «UUID1»,

0x0010, 0x0017, «UUID2», 0x0100, 0x01FF, «UUID3»)
ATT_READ_BY_GROUP_TYPE_REQ (0x0200, 0xFFFF, «Primary Service»)

ATT_READ_BY_GROUP_TYPE_RSP (0x06, 0x02CF, 0x02FF, «UUID4»,

0x0300, 0x03FF, «UUID5», 0x0400, 0x04FF, «UUID6»)
ATT_READ_BY_GROUP_TYPE_REQ (0x0500, 0xFFFF, «Primary Service»)

ATT_ERROR_RSP («ATT_READ_BY_GROUP_TYPE_REQ», 0x0500,

«Attribute Not Found»)

Figure 4.2: Discover All Primary Services example

4.4.2 Discover Primary Service by Service UUID

This sub-procedure is used by a client to discover a specific primary service on a server

when only the Service UUID is known. The specific primary service may exist multiple
times on a server. The primary service being discovered is identified by the service
UUID.

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 3, Part G Page 1569
Generic Attribute Profile (GATT)

The ATT_FIND_BY_TYPE_VALUE_REQ PDU shall be used with the Attribute Type

parameter set to the UUID for «Primary Service» and the Attribute Value set to the
16-bit Bluetooth UUID or 128-bit UUID for the specific primary service. The Starting
Handle shall be set to 0x0001 and the Ending Handle shall be set to 0xFFFF.

Two possible responses can be sent from the server for the
ATT_FIND_BY_TYPE_VALUE_REQ PDU: ATT_FIND_BY_TYPE_VALUE_RSP and
ATT_ERROR_RSP PDUs.

An ATT_ERROR_RSP PDU is returned if an error occurred on the server.

The ATT_FIND_BY_TYPE_VALUE_RSP PDU returns a list of Attribute Handle ranges.

The Attribute Handle range is the starting handle and the ending handle of the service
definition. The End Group Handle of the last service in a device can be 0xFFFF. If the
Attribute Handle range for the Service UUID being searched is returned and the End
Found Handle is not 0xFFFF, the ATT_FIND_BY_TYPE_VALUE_REQ PDU may be
issued again with the Starting Handle set to one greater than the last Attribute Handle
range in the ATT_FIND_BY_TYPE_VALUE_RSP PDU.

This sub-procedure is complete when the ATT_ERROR_RSP PDU is received and the
Error Code parameter is set to Attribute Not Found (0x0A) or when the End Group
Handle in the ATT_FIND_BY_TYPE_VALUE_RSP PDU is 0xFFFF.

The sub-procedure may end early if a desired primary service is found prior to
discovering all the primary services of the specified service UUID supported on the
server.

The service declaration described in Section 3.1 specifies that the service declaration
is readable and requires no authentication or authorization, therefore insufficient
authentication or read not permitted errors shall not occur.

Client Server

ATT_FIND_BY_TYPE_VALUE_REQ (0x0001, 0xFFFF, «Primary Service»,

«UUID1»)
ATT_FIND_BY_TYPE_VALUE_RSP (0x0200, 0x0214)

ATT_FIND_BY_TYPE_VALUE_REQ (0x0215, 0xFFFF, «Primary Service»,

«UUID1»)

ATT_ERROR_RSP («ATT_FIND_BY_TYPE_VALUE_REQ», 0x0215,

«Attribute Not Found»)

Figure 4.3: Discover Primary Service by Service UUID example

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 3, Part G Page 1570
Generic Attribute Profile (GATT)

4.5 Relationship Discovery

This procedure is used by a client to discover service relationships to other services.

There is one sub-procedure that can be used for relationship discovery: Find Included
Services.

4.5.1 Find Included Services

This sub-procedure is used by a client to find include service declarations within a

service definition on a server. The service specified is identified by the service handle
range.

The ATT_READ_BY_TYPE_REQ PDU shall be used with the Attribute Type parameter
set to the UUID for «Include» The Starting Handle shall be set to the starting handle
of the specified service and the Ending Handle shall be set to the ending handle of
the specified service. The sub-procedure may end early if a desired included service is
found prior to discovering all the included services of the specified service supported on
the server.

Two possible responses can be sent from the server for

the ATT_READ_BY_TYPE_REQ PDU: ATT_READ_BY_TYPE_RSP and
ATT_ERROR_RSP PDUs.

An ATT_ERROR_RSP PDU is returned if an error occurred on the server.

The ATT_READ_BY_TYPE_RSP PDU returns a set of Attribute Handle and Attribute

Value pairs corresponding to the included services in the service definition. Each
Attribute Value contained in the response is composed of the Attribute Handle of the
included service declaration and the End Group Handle. If the service UUID is a 16-bit
Bluetooth UUID it is also returned in the response. The ATT_READ_BY_TYPE_REQ
PDU shall be issued again with the Starting Handle set to one greater than the last
Attribute Handle in the ATT_READ_BY_TYPE_RSP PDU.

The sub-procedure is complete when either the ATT_ERROR_RSP PDU is

received with the Error Code parameter set to Attribute Not Found (0x0A) or the
ATT_READ_BY_TYPE_RSP PDU has an Attribute Handle of the included service
declaration that is equal to the Ending Handle of the request.

To get the included service UUID when the included service uses a 128-bit UUID, the
ATT_READ_REQ PDU is used. The Attribute Handle for the ATT_READ_REQ PDU is
the Attribute Handle of the included service.

The include declaration described in Section 3.2 specifies that the include declaration
is readable and requires no authentication or authorization, therefore insufficient
authentication or read not permitted errors shall not occur.

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 3, Part G Page 1571
Generic Attribute Profile (GATT)

Client Server

ATT_READ_BY_TYPE_REQ (0x0200, 0x0214, «Include»)

ATT_READ_BY_TYPE_RSP (0x08, 0x0201, 0x0500, 0x0518,

«UUID1»)

ATT_READ_BY_TYPE_REQ (0x0202, 0x0214, «Include»)

ATT_READ_BY_TYPE_RSP (0x06, 0x0202, 0x0550, 0x0568)

ATT_READ_REQ («0x0550»)

ATT_READ_RSP («UUID2»)

ATT_READ_BY_TYPE_REQ (0x0203, 0x0214, «Include»)

ATT_ERROR_RSP («ATT_READ_BY_TYPE_REQ», 0x0203,

«Attribute Not Found»)

Figure 4.4: Find Included Services example

4.6 Characteristic discovery

This procedure is used by a client to discover service characteristics on a server. Once
the characteristics are discovered additional information about the characteristics can
be discovered or accessed using other procedures.

There are two sub-procedures that can be used for characteristic discovery: Discover
All Characteristics of a Service and Discover Characteristics by UUID.

4.6.1 Discover All Characteristics of a Service

This sub-procedure is used by a client to find all the characteristic declarations within a
service definition on a server when only the service handle range is known. The service
specified is identified by the service handle range.

The ATT_READ_BY_TYPE_REQ PDU shall be used with the Attribute Type parameter
set to the UUID for «Characteristic» The Starting Handle shall be set to starting handle
of the specified service and the Ending Handle shall be set to the ending handle of the
specified service.

Two possible responses can be sent from the server for

the ATT_READ_BY_TYPE_REQ PDU: ATT_READ_BY_TYPE_RSP and
ATT_ERROR_RSP PDUs.

An ATT_ERROR_RSP PDU is returned if an error occurred on the server.

The ATT_READ_BY_TYPE_RSP PDU returns a list of Attribute Handle and Attribute

Value pairs corresponding to the characteristics in the service definition. The Attribute

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 3, Part G Page 1572
Generic Attribute Profile (GATT)

Handle is the handle for the characteristic declaration. The Attribute Value is the
Characteristic Properties, Characteristic Value Handle and Characteristic UUID. The
ATT_READ_BY_TYPE_REQ PDU shall be issued again with the Starting Handle set to
one greater than the last Attribute Handle in the ATT_READ_BY_TYPE_RSP PDU.

The sub-procedure is complete when the ATT_ERROR_RSP PDU is received

and the Error Code parameter is set to Attribute Not Found (0x0A) or the
ATT_READ_BY_TYPE_RSP PDU has an Attribute Handle that is equal to the Ending
Handle of the request.

The sub-procedure may end early if a desired characteristic is found prior to discovering
all the characteristics of the specified service supported on the server.

Note: The characteristic declaration described in Section 3.3 specifies that the
characteristic declaration is readable and requires no authentication or authorization,
therefore insufficient authentication or read not permitted errors should not occur.

Client Server

ATT_READ_BY_TYPE_REQ (0x0200, 0x0214, «Characteristic»)

ATT_READ_BY_TYPE_RSP (0x07, 0x0203, 0x02, 0x0204, «UUID1»,

0x0210, 0x02, 0x0212, «UUID2»)

ATT_READ_BY_TYPE_REQ (0x0211, 0x0214, «Characteristic»)

ATT_ERROR_RSP («ATT_READ_BY_TYPE_REQ», 0x0211,

«Attribute Not Found»)

Figure 4.5: Discover All Characteristics of a Service example

Note: In this example «UUID1» and «UUID2» are 16 bits (2 octets).

If they were 128 bits (16 octets) then the ATT_READ_BY_TYPE_RSP PDU data would
instead be:

0x15, 0x0203, 0x02, 0x0204, «UUID1», 0x0210, 0x02, 0x0212, «UUID2»

4.6.2 Discover Characteristics by UUID

This sub-procedure is used by a client to discover service characteristics on a server

when only the service handle ranges are known and the characteristic UUID is known.
The specific service may exist multiple times on a server. The characteristics being
discovered are identified by the characteristic UUID.

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 3, Part G Page 1573
Generic Attribute Profile (GATT)

The ATT_READ_BY_TYPE_REQ PDU is used to perform the beginning of the sub-

procedure. The Attribute Type is set to the UUID for «Characteristic» and the Starting
Handle and Ending Handle parameters shall be set to the service handle range.

Two possible responses can be sent from the server for

the ATT_READ_BY_TYPE_REQ PDU: ATT_READ_BY_TYPE_RSP and
ATT_ERROR_RSP PDUs.

An ATT_ERROR_RSP PDU is returned if an error occurred on the server.

The ATT_READ_BY_TYPE_RSP PDU returns a list of Attribute Handle and Attribute

Value pairs corresponding to the characteristics contained in the handle range provided.
Each Attribute Value in the list is the Attribute Value for the characteristic declaration.
The Attribute Value contains the characteristic properties, Characteristic Value Handle
and characteristic UUID. The Attribute Value for each Attribute Handle and Attribute
Value pairs are checked for a matching characteristic UUID. Once found, the sub-
procedure continues until the end of the service handle range is exhausted. The
ATT_READ_BY_TYPE_REQ PDU is issued again with the Starting Handle set to one
greater than the last Attribute Handle in the ATT_READ_BY_TYPE_RSP PDU.

If the ATT_ERROR_RSP PDU is sent by the server with the Error Code parameter set
to Attribute Not Found (0x0A), the characteristic does not exist on the server within the
handle range provided.

The sub-procedure may end early if a desired characteristic is found prior to discovering
all the characteristics for the specified service supported on the server.

The characteristic declaration described in Section 3.3 specifies that the characteristic
declaration is readable and requires no authentication or authorization, therefore
insufficient authentication or read not permitted errors shall not occur.

Client Server

ATT_READ_BY_TYPE_REQ (0x0200, 0x0214, «Characteristic»)

ATT_READ_BY_TYPE_RSP (0x07, 0x0203, 0x02, 0x0204, «UUID1»,

0x0210, 0x02, 0x0212, «UUID2»)

ATT_READ_BY_TYPE_REQ (0x0213, 0x0214, «Characteristic»)

ATT_ERROR_RSP («ATT_READ_BY_TYPE_REQ», 0x0213,

«Attribute Not Found»)

Figure 4.6: Discover Characteristics by UUID example

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 3, Part G Page 1574
Generic Attribute Profile (GATT)

4.7 Characteristic Descriptor Discovery

This procedure is used by a client to discover characteristic descriptors of a
characteristic. Once the characteristic descriptors are discovered additional information
about the characteristic descriptors can be accessed using other procedures.

There is one sub-procedure that can be used for characteristic descriptor discovery:
Discover All Characteristic Descriptors.

4.7.1 Discover All Characteristic Descriptors

This sub-procedure is used by a client to find all the characteristic descriptor’s

Attribute Handles and Attribute Types within a characteristic definition when only the
characteristic handle range is known. The characteristic specified is identified by the
characteristic handle range.

The ATT_FIND_INFORMATION_REQ PDU shall be used with the Starting Handle set
to the handle of the specified characteristic value + 1 and the Ending Handle set to the
ending handle of the specified characteristic.

Two possible responses can be sent from the server for the
ATT_FIND_INFORMATION_REQ PDU: ATT_FIND_INFORMATION_RSP and
ATT_ERROR_RSP PDUs.

An ATT_ERROR_RSP PDU is returned if an error occurred on the server.

The ATT_FIND_INFORMATION_RSP PDU returns a list of Attribute Handle

and Attribute Type pairs corresponding to the characteristic descriptors in the
characteristic definition. The Attribute Handle is the handle for the characteristic
descriptor declaration. The Attribute Type is the characteristic descriptor UUID. The
ATT_FIND_INFORMATION_REQ PDU shall be issued again with the Starting Handle
set to one greater than the last Attribute Handle in the ATT_FIND_INFORMATION_RSP
PDU.

The sub-procedure is complete when the ATT_ERROR_RSP PDU is received

and the Error Code parameter is set to Attribute Not Found (0x0A) or the
ATT_FIND_INFORMATION_RSP PDU has an Attribute Handle that is equal to the
Ending Handle of the request.

The sub-procedure may end early if a desired Characteristic Descriptor is found prior to
discovering all the characteristic descriptors of the specified characteristic.

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 3, Part G Page 1575
Generic Attribute Profile (GATT)

Client Server

ATT_FIND_INFORMATION_REQ (0x0205, 0x020F)

ATT_FIND_INFORMATION_RSP (0x01, 0x0205, «UUID1», 0x0206,

«UUID2»)

ATT_FIND_INFORMATION_REQ (0x0207, 0x020F)

ATT_ERROR_RSP («ATT_FIND_INFORMATION_REQ», 0x0207,

«Attribute Not Found»)

Figure 4.7: Discover All Characteristic Descriptors example

4.8 Characteristic Value Read

This procedure is used to read a Characteristic Value from a server. There are four
sub-procedures that can be used to read a Characteristic Value: Read Characteristic
Value, Read Using Characteristic UUID, Read Long Characteristic Value, and Read
Multiple Characteristic Values.

4.8.1 Read Characteristic Value

This sub-procedure is used to read a Characteristic Value from a server when the
client knows the Characteristic Value Handle. The ATT_READ_REQ PDU is used
with the Attribute Handle parameter set to the Characteristic Value Handle. The
ATT_READ_RSP PDU returns the Characteristic Value in the Attribute Value parameter.

The ATT_READ_RSP PDU only contains the complete Characteristic Value if that is
less than or equal to (ATT_MTU – 1) octets in length. If the Characteristic Value is
greater than (ATT_MTU – 1) octets in length, the ATT_READ_RSP PDU only contains
the first portion of the Characteristic Value and the Read Long Characteristic Value
procedure may be used if the rest is required.

An ATT_ERROR_RSP PDU shall be sent by the server in response to the

ATT_READ_REQ PDU if insufficient authentication, insufficient authorization, a too-
short encryption key size is used by the client, or if a read operation is not permitted on
the Characteristic Value. The Error Code parameter is set as specified in the Attribute
Protocol.

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 3, Part G Page 1576
Generic Attribute Profile (GATT)

Client Server

ATT_READ_REQ (0x0002)

ATT_READ_RSP ("Example Device")

Figure 4.8: Read Characteristic Value example

4.8.2 Read Using Characteristic UUID

This sub-procedure is used to read a Characteristic Value from a server when the client
only knows the characteristic UUID and does not know the handle of the characteristic.

The ATT_READ_BY_TYPE_REQ PDU is used to perform the sub-procedure. The

Attribute Type is set to the known characteristic UUID and the Starting Handle and
Ending Handle parameters shall be set to the range over which this read is to be
performed. This is typically the handle range for the service in which the characteristic
belongs.

Two possible responses can be sent from the server for

the ATT_READ_BY_TYPE_REQ PDU: ATT_READ_BY_TYPE_RSP and
ATT_ERROR_RSP PDUs.

An ATT_ERROR_RSP PDU is returned if an error occurred on the server.

The ATT_READ_BY_TYPE_RSP PDU returns a list of Attribute Handle and Attribute

Value pairs corresponding to the first characteristics contained in the handle range that
will fit into the ATT_READ_BY_TYPE_RSP PDU. This procedure does not return the
complete list of all characteristics with the given characteristic UUID within the range of
values. If such an operation is required, then the Discover Characteristics by UUID sub
procedure shall be used.

If the ATT_ERROR_RSP PDU is sent by the server with the Error Code parameter set
to Attribute Not Found (0x0A), the characteristic does not exist on the server within the
handle range provided.

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 3, Part G Page 1577
Generic Attribute Profile (GATT)

Client Server

ATT_READ_BY_TYPE_REQ (0x0001, 0xFFFF, «UUID12»)

ATT_READ_BY_TYPE_RSP (0x04, 0x0380, 0x08EC)

Figure 4.9: Read Using Characteristic UUID example

4.8.3 Read Long Characteristic Value

This sub-procedure is used to read a Characteristic Value from a server when the client
knows the Characteristic Value Handle and the length of the Characteristic Value is
longer than can be sent in a single ATT_READ_RSP PDU.

The ATT_READ_REQ and ATT_READ_BLOB_REQ PDUs are used to perform this

sub-procedure. The Attribute Handle shall be set to the Characteristic Value Handle
of the Characteristic Value to be read. To read the complete Characteristic Value
an ATT_READ_REQ PDU should be used for the first part of the value and
ATT_READ_BLOB_REQ PDUs shall used for the rest. The Value Offset parameter of
each ATT_READ_BLOB_REQ PDU shall be set to the offset of the next octet within
the Characteristic Value that has yet to be read. The ATT_READ_BLOB_REQ PDU
is repeated until the ATT_READ_BLOB_RSP PDU’s Part Attribute Value parameter is
shorter than (ATT_MTU – 1).

For each ATT_READ_BLOB_REQ PDU a ATT_READ_BLOB_RSP PDU is received

with a portion of the Characteristic Value contained in the Part Attribute Value
parameter.

An ATT_ERROR_RSP PDU shall be sent by the server in response to the

ATT_READ_BLOB_REQ PDU if insufficient authentication, insufficient authorization, a
too-short encryption key size is used by the client, or if a read operation is not permitted
on the Characteristic Value. The Error Code parameter is set as specified in the
Attribute Protocol. If the Characteristic Value has a fixed length that is not longer than
(ATT_MTU – 1), then the server may respond to the first ATT_READ_BLOB_REQ_PDU
with an ATT_ERROR_RSP PDU with the Error Code parameter set to Attribute Not
Long (0x0B).

Note: The ATT_READ_BLOB_REQ PDU with zero offset may be used to read the first
part of the value of the Attribute.

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 3, Part G Page 1578
Generic Attribute Profile (GATT)

Client Server

ATT_READ_REQ (0x0003)

ATT_READ_RSP ("A Very Long Device Nam")

ATT_READ_BLOB_REQ (0x0003, 0x0016)

ATT_READ_BLOB_RSP ("e Using A Long Attribu")

ATT_READ_BLOB_REQ (0x0003, 0x002C)

ATT_READ_BLOB_RSP ("te")

Figure 4.10: Read Long Characteristic Value example

4.8.4 Read Multiple Characteristic Values

This sub-procedure is used to read multiple Characteristic Values from a server when
the client knows the Characteristic Value Handles. The ATT_READ_MULTIPLE_REQ
PDU is used with the Set Of Handles parameter set to the Characteristic Value Handles.
The ATT_READ_MULTIPLE_RSP PDU returns the Characteristic Values in the Set Of
Values parameter.

The ATT_READ_MULTIPLE_RSP PDU only contains a set of Characteristic Values that

is less than or equal to (ATT_MTU – 1) octets in length. If the Set Of Values is greater
than (ATT_MTU – 1) octets in length, only the first (ATT_MTU – 1) octets are included in
the response.

Note: A client should not request multiple Characteristic Values when the response’s
Set Of Values parameter is equal to (ATT_MTU – 1) octets in length since it is
not possible to determine if the last Characteristic Value was read or additional
Characteristic Values exist but were truncated.

An ATT_ERROR_RSP PDU shall be sent by the server in response to

the ATT_READ_MULTIPLE_RSP PDU if insufficient authentication, insufficient
authorization, a too-short encryption key size, or insufficient encryption is used by the
client, or if a read operation is not permitted on any of the Characteristic Values. The
Error Code parameter is set as specified in the Attribute Protocol.

Refer to the Attribute Protocol specification for the format of the Set Of Handles and Set
Of Values parameter.

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 3, Part G Page 1579
Generic Attribute Profile (GATT)

Client Server

ATT_READ_MULTIPLE_REQ (0x0380, 0x0009)

ATT_READ_MULTIPLE_RSP (0x08EC, 0x0A)

Figure 4.11: Read Multiple Characteristic Values example

4.8.5 Read Multiple Variable Length Characteristic Values

This sub-procedure is used to read multiple variable length Characteristic Values

from a server when the client knows the Characteristic Value Handles. The
Attribute Protocol ATT_READ_MULTIPLE_VARIABLE_REQ PDU is used with
the Set Of Handles parameter set to the Characteristic Value Handles. The
ATT_READ_MULTIPLE_VARIABLE_RSP PDU returns the Characteristic Values in the
Length Value Tuple List parameter.

The ATT_READ_MULTIPLE_VARIABLE_RSP PDU can only contain a Length Value

Tuple List that is less than or equal to (ATT_MTU – 1) octets in length. If the Length
Value Tuple List is greater than (ATT_MTU – 1) octets in length, only the first (ATT_MTU
– 1) octets are included in the response.

An ATT_ERROR_RSP PDU shall be sent by the server in response to the

ATT_READ_MULTIPLE_VARIABLE_REQ PDU if insufficient authentication, insufficient
authorization, a too-short encryption key size, or insufficient encryption is used by the
client, or if a read operation is not permitted on any of the Characteristic Values. The
Error Code parameter is set as specified in the Attribute Protocol.

Refer to the Attribute Protocol specification for the format of the Set Of Handles and
Length Value Tuple List parameter.

Client Server

ATT_READ_MULTIPLE_VARIABLE_REQ (0x0380, 0x0009)

ATT_READ_MULTIPLE_VARIABLE_RSP (0x0002, 0x08EC, 0x0001,

0x0A)

Figure 4.12: Read Multiple Variable Length Characteristic Values example

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 3, Part G Page 1580
Generic Attribute Profile (GATT)

4.9 Characteristic Value Write

This procedure is used to write a Characteristic Value to a server.

There are five sub-procedures that can be used to write a Characteristic Value: Write
Without Response, Signed Write Without Response, Write Characteristic Value, Write
Long Characteristic Value and Characteristic Value Reliable Writes.

4.9.1 Write Without Response

This sub-procedure is used to write a Characteristic Value to a server when the

client knows the Characteristic Value Handle and the client does not need an
acknowledgment that the write was successfully performed. This sub-procedure only
writes the first (ATT_MTU – 3) octets of a Characteristic Value. This sub-procedure
cannot be used to write a long characteristic; instead the Write Long Characteristic
Value sub-procedure should be used.

The ATT_WRITE_CMD PDU is used for this sub-procedure. The Attribute Handle
parameter shall be set to the Characteristic Value Handle. The Attribute Value
parameter shall be set to the new Characteristic Value.

If the Characteristic Value write request is too long (see [Vol 3] Part F, Section 3.4.5.1)
or has an invalid value as defined by the profile, then the write shall not succeed and no
error shall be generated by the server.

Client Server

ATT_WRITE_CMD (0x0022, 0x01)

Figure 4.13: Write Without Response example

4.9.2 Signed Write Without Response

This sub-procedure is used to write a Characteristic Value to a server when the client
knows the Characteristic Value Handle and the ATT bearer is not encrypted. This
sub-procedure shall only be used if the Characteristic Properties authenticated bit is
enabled and the client and server device share a bond as defined in [Vol 3] Part C,
Generic Access Profile.

This sub-procedure only writes the first (ATT_MTU – 15) octets of an Attribute Value.
This sub-procedure cannot be used to write a long Attribute.

The ATT_SIGNED_WRITE_CMD PDU is used for this sub-procedure. The Attribute

Handle parameter shall be set to the Characteristic Value Handle. The Attribute Value

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 3, Part G Page 1581
Generic Attribute Profile (GATT)

parameter shall be set to the new Characteristic Value authenticated by signing the
value, as defined in the Security Manager [Vol 3] Part H, Section 2.4.5.

If the authenticated Characteristic Value that is written is too long (see [Vol 3] Part F,
Section 3.4.5.4), has an invalid value as defined by the profile, or the signed value
does not authenticate the client, then the write shall not succeed and no error shall be
generated by the server.

If a connection is already encrypted with LE security mode 1, level 2 or level 3 as

defined in [Vol 3] Part C, Section 10.2 then, a Write Without Response as defined in
Section 4.9.1 shall be used instead of a Signed Write Without Response.

On BR/EDR, the ATT bearer is always encrypted, due to the use of Security Mode 4,
therefore this sub-procedure shall not be used.

Client Server

ATT_SIGNED_WRITE_CMD (0x0022, 0x800000022184374801)

Figure 4.14: Signed Write Without Response example

4.9.3 Write Characteristic Value

This sub-procedure is used to write a Characteristic Value to a server when the

client knows the Characteristic Value Handle. This sub-procedure only writes the first
(ATT_MTU – 3) octets of a Characteristic Value. This sub-procedure cannot be used to
write a long Attribute; instead the Write Long Characteristic Value sub-procedure should
be used.

The ATT_WRITE_REQ PDU is used to for this sub-procedure. The Attribute Handle
parameter shall be set to the Characteristic Value Handle. The Attribute Value
parameter shall be set to the new characteristic.

An ATT_WRITE_RSP PDU shall be sent by the server if the write of the Characteristic
Value succeeded.

An ATT_ERROR_RSP PDU shall be sent by the server in response to the

ATT_WRITE_REQ PDU if insufficient authentication, insufficient authorization, a too-
short encryption key size is used by the client, the Attribute Value to be written is too
long (see [Vol 3] Part F, Section 3.4.5.1), or if a write operation is not permitted on
the Characteristic Value. The Error Code parameter is set as specified in the Attribute
Protocol. If the Characteristic Value has an invalid value as defined by the profile, then
the value shall not be written and an ATT_ERROR_RSP PDU shall be sent with the
Error Code parameter set to Application Error (0x80 – 0x9F) by the server.

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 3, Part G Page 1582
Generic Attribute Profile (GATT)

Client Server

ATT_WRITE_REQ (0x0002, "My Device")

ATT_WRITE_RSP ()

Figure 4.15: Write Characteristic Value example

4.9.4 Write Long Characteristic Value

This sub-procedure is used to write a Characteristic Value to a server when the client
knows the Characteristic Value Handle but the length of the Characteristic Value is
longer than can be sent in a single ATT_WRITE_REQ PDU.

The ATT_PREPARE_WRITE_REQ and ATT_EXECUTE_WRITE_REQ PDUs are used

to perform this sub-procedure. The Attribute Handle parameter shall be set to the
Characteristic Value Handle of the Characteristic Value to be written. The Part Attribute
Value parameter shall be set to the part of the Attribute Value that is being written.
The Value Offset parameter shall be the offset within the Characteristic Value to
be written. To write the complete Characteristic Value the offset should be set to
0x0000 for the first ATT_PREPARE_WRITE_REQ PDU. The offset for subsequent
ATT_PREPARE_WRITE_REQ PDUs is the next octet that has yet to be written. The
ATT_PREPARE_WRITE_REQ PDU is repeated until the complete Characteristic Value
has been transferred, after which an ATT_EXECUTE_WRITE_REQ PDU is used to
write the complete value.

Note: The values in the ATT_PREPARE_WRITE_RSP PDU do not need to be verified

in this sub-procedure.

An ATT_ERROR_RSP PDU shall be sent by the server in response to

the ATT_PREPARE_WRITE_REQ PDU if insufficient authentication, insufficient
authorization, a too-short encryption key size is used by the client, the prepared
attribute value is too long (see [Vol 3] Part F, Section 3.4.6.3), or if a write operation is
not permitted on the Characteristic Value. The Error Code parameter is set as specified
in the Attribute Protocol. If the Attribute Value has an invalid value as defined by the
profile, then the write shall not succeed and an ATT_ERROR_RSP PDU shall be sent
with the Error Code parameter set to Application Error (0x80 – 0x9F) by the server.

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 3, Part G Page 1583
Generic Attribute Profile (GATT)

Client Server

ATT_PREPARE_WRITE_REQ (0x0003, 0x0000, "My Special Device ")

ATT_PREPARE_WRITE_RSP (0x0003, 0x0000, "My Special Device ")

ATT_PREPARE_WRITE_REQ (0x0003, 0x0012, "Next To The Kitche")

ATT_PREPARE_WRITE_RSP (0x0003, 0x0012, "Next To The Kitche")

ATT_PREPARE_WRITE_REQ (0x0003, 0x0024, "n Door")

ATT_PREPARE_WRITE_RSP (0x0003, 0x0024, "n Door")

ATT_EXECUTE_WRITE_REQ (0x01)

ATT_EXECUTE_WRITE_RSP ()

Figure 4.16: Write Long Characteristic Value example

4.9.5 Characteristic Value Reliable Writes

This sub-procedure is used to write a Characteristic Value to a server when the client
knows the Characteristic Value Handle, and assurance is required that the correct
Characteristic Value is going to be written by transferring the Characteristic Value to be
written in both directions before the write is performed. A higher-layer protocol can also
use this sub-procedure to write multiple values in order in a single operation.

The sub-procedure has two phases; the first phase prepares the Characteristic Values
to be written. To do this, the client transfers the Characteristic Values to the server.
The server checks the validity of the Characteristic Values. The client also checks each
Characteristic Value to verify it was correctly received by the server using the server
responses. Once this is complete, the second phase performs the execution of all of the
prepared Characteristic Value writes on the server from this client.

In the first phase, the ATT_PREPARE_WRITE_REQ PDU is used. The Attribute Handle
shall be set to the Characteristic Value Handle that is to be prepared to write. The Value
Offset and Part Attribute Value parameter shall be set to the new Characteristic Value.

Two possible responses can be sent from the server for the ATT_PREPARE_WRITE_-
REQ PDU: ATT_PREPARE_WRITE_RSP and ATT_ERROR_RSP PDUs.

If the number of prepared write requests exceeds the number of prepared writes
supported, then an ATT_ERROR_RSP PDU with the Error Code parameter set to
Prepare Queue Full (0x09) shall be sent by the server.

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 3, Part G Page 1584
Generic Attribute Profile (GATT)

An ATT_ERROR_RSP PDU shall be sent by the server in response to

the ATT_PREPARE_WRITE_REQ PDU if insufficient authentication, insufficient
authorization, a too-short encryption key size is used by the client, the prepared
attribute value is too long (see [Vol 3] Part F, Section 3.4.6.3), or if a write operation is
not permitted on the Characteristic Value. The Error Code parameter is set as specified
in the Attribute Protocol.

If a Characteristic Value is prepared two or more times during this sub-procedure, then
all prepared values are written to the same Characteristic Value in the order that they
were prepared.

If an ATT_PREPARE_WRITE_RSP PDU is returned, then the Value Offset and Part

Attribute Value parameter in the response shall be checked with the Value Offset
and Part Attribute Value parameter that was sent in the ATT_PREPARE_WRITE_REQ
PDU; if they are different, then the value has been corrupted during transmission,
and the sub-procedure shall be aborted by sending an ATT_EXECUTE_WRITE_REQ
PDU with the Flags parameter set to 0x00 to cancel all prepared writes. The complete
sub-procedure may be restarted.

Multiple ATT_PREPARE_WRITE_REQ PDUs can be sent by a client, each of which will

be queued by the server.

In the second phase, the ATT_EXECUTE_WRITE_REQ PDU is used. The Attribute

Flags parameter shall be set to 0x01 to immediately write all pending prepared values
in the order that they were prepared. The server shall write the prepared writes once it
receives this request and shall only send the ATT_EXECUTE_WRITE_RSP PDU once
all the prepared values have been successfully written. If the Characteristic Value has
an invalid value as defined by the profile, then the write shall not succeed, and an
ATT_ERROR_RSP PDU with the Error Code parameter set to Application Error (0x80
– 0x9F) shall be sent by the server. The state of the Characteristic Values that were
prepared is undefined.

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 3, Part G Page 1585
Generic Attribute Profile (GATT)

Client Server

ATT_PREPARE_WRITE_REQ (0x0323, 0x0000, 0x00)

ATT_PREPARE_WRITE_RSP (0x0323, 0x0000, 0x00)

ATT_PREPARE_WRITE_REQ (0x0324, 0x0000, 0x0103)

ATT_PREPARE_WRITE_RSP (0x0324, 0x0000, 0x0103)

ATT_PREPARE_WRITE_REQ (0x0325, 0x0000, 0xC0)

ATT_PREPARE_WRITE_RSP (0x0325, 0x0000, 0xC0)

ATT_PREPARE_WRITE_REQ (0x0327, 0x0000, 0xFF)

ATT_PREPARE_WRITE_RSP (0x0327, 0x0000, 0xFF)

ATT_PREPARE_WRITE_REQ (0x0326, 0x0000, 0x07)

ATT_PREPARE_WRITE_RSP (0x0326, 0x0000, 0x07)

ATT_PREPARE_WRITE_REQ (0x0323, 0x0000, 0x01)

ATT_PREPARE_WRITE_RSP (0x0323, 0x0000, 0x01)

ATT_EXECUTE_WRITE_REQ (0x01)

ATT_EXECUTE_WRITE_RSP ()

Figure 4.17: Characteristic Value Reliable Writes example

4.10 Characteristic Value Notification

This procedure is used to notify a client of the value of a Characteristic Value
from a server without expecting any Attribute Protocol layer acknowledgment that
the notification was successfully received. There are two sub-procedures that can be
used to notify a value: Single Notification1 and Multiple Variable Length Notifications.
Notifications can be configured using the Client Characteristic Configuration descriptor
(See Section 3.3.3.3).

A profile defines when to use notifications.

1This was previously just "Notifications".

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 3, Part G Page 1586
Generic Attribute Profile (GATT)

4.10.1 Single Notification

This sub-procedure is used when a server is configured to notify a Characteristic Value

to a client.

The ATT_HANDLE_VALUE_NTF PDU is used to perform this sub-procedure. The

Attribute Handle parameter shall be set to the Characteristic Value Handle being
notified, and the Attribute Value parameter shall be set to the Characteristic Value.

Client Server

ATT_HANDLE_VALUE_NTF (0x0009, 0x0A)

Figure 4.18: Notifications example

4.10.2 Multiple Variable Length Notifications

This sub-procedure is used when a server is configured to notify multiple Characteristic

Values to a client.

The Attribute Protocol ATT_MULTIPLE_HANDLE_VALUE_NTF PDU is used to perform

this sub-procedure. The Handle Length Value Tuple List parameter shall include the set
of Characteristic Value Handles and associated Attribute Values.

Client Server

ATT_MULTIPLE_HANDLE_VALUE_NTF (0x0380, 0x0002, 0x08EC,

0x0009, 0x0001, 0x0A)

Figure 4.19: Multiple Variable Length Notifications example

4.11 Characteristic Value Indication

This procedure is used to indicate the Characteristic Value from a server to a

client. There is one sub-procedure that can be used to indicate a value: Indication.
Indications can be configured using the Client Characteristic Configuration descriptor
(See Section 3.3.3.3).

A profile defines when to use indications.

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 3, Part G Page 1587
Generic Attribute Profile (GATT)

4.11.1 Indication

This sub-procedure is used when a server is configured to indicate a Characteristic

Value to a client and expects an Attribute Protocol layer acknowledgment that the
indication was successfully received.

The ATT_HANDLE_VALUE_IND PDU is used to perform this sub-procedure. The

Attribute Handle parameter shall be set to the Characteristic Value Handle being
indicated, and the Attribute Value parameter shall be set to the Characteristic Value.
Once the ATT_HANDLE_VALUE_IND PDU is received by the client, the client shall
respond with an ATT_HANDLE_VALUE_CFM PDU.

Client Server

ATT_HANDLE_VALUE_IND (0x0009, 0x09)

ATT_HANDLE_VALUE_CFM ()

Figure 4.20: Indication example

4.12 Characteristic Descriptors

This procedure is used to read and write characteristic descriptors on a server.

There are four sub-procedures that can be used to read and write characteristic
descriptors: Read Characteristic Descriptor, Read Long Characteristic Descriptor, Write
Characteristic Descriptor, and Write Long Characteristic Descriptor.

4.12.1 Read Characteristic Descriptor

This sub-procedure is used to read a characteristic descriptor from a server when the
client knows the characteristic descriptor declaration’s Attribute handle.

The ATT_READ_REQ PDU is used for this sub-procedure. The ATT_READ_REQ PDU
is used with the Attribute Handle parameter set to the characteristic descriptor handle.
The ATT_READ_RSP PDU returns the characteristic descriptor value in the Attribute
Value parameter.

An ATT_ERROR_RSP PDU shall be sent by the server in response to the

ATT_READ_REQ PDU if insufficient authentication, insufficient authorization, a too-
short encryption key size is used by the client, or if a read operation is not permitted on
the Characteristic Value. The Error Code parameter is set accordingly.

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 3, Part G Page 1588
Generic Attribute Profile (GATT)

Client Server

ATT_READ_REQ (0x0206)

ATT_READ_RSP ("Outside Temperature")

Figure 4.21: Read Characteristic Descriptor example

4.12.2 Read Long Characteristic Descriptor

This sub-procedure is used to read a characteristic descriptor from a server when

the client knows the characteristic descriptor declaration’s Attribute handle and the
length of the characteristic descriptor declaration is longer than can be sent in a single
ATT_READ_RSP PDU.

The ATT_READ_BLOB_REQ PDU is used to perform this sub-procedure. The Attribute

Handle parameter shall be set to the characteristic descriptor handle. The Value
Offset parameter shall be the offset within the characteristic descriptor to be read. To
read the complete characteristic descriptor the offset should be set to 0x00 for the
first ATT_READ_BLOB_REQ PDU. The offset for subsequent ATT_READ_BLOB_REQ
PDUs is the next octet that has yet to be read. The ATT_READ_BLOB_REQ PDU
is repeated until the ATT_READ_BLOB_RSP PDU’s Part Attribute Value parameter is
zero or an ATT_ERROR_RSP PDU is sent by the server with the Error Code parameter
set to Invalid Offset (0x07).

For each ATT_READ_BLOB_REQ PDU an ATT_READ_BLOB_RSP PDU is received

with a portion of the characteristic descriptor value contained in the Part Attribute Value
parameter.

An ATT_ERROR_RSP PDU shall be sent by the server in response to the

ATT_READ_BLOB_REQ PDU if insufficient authentication, insufficient authorization, a
too-short encryption key size is used by the client, or if a read operation is not permitted
on the characteristic descriptor. The Error Code parameter is set accordingly.

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 3, Part G Page 1589
Generic Attribute Profile (GATT)

Client Server

ATT_READ_BLOB_REQ (0x0003, 0x0000)

ATT_READ_BLOB_RSP ("A Very Long Device Nam")

ATT_READ_BLOB_REQ (0x0003, 0x0016)

ATT_READ_BLOB_RSP ("e Using A Long Attribu")

ATT_READ_BLOB_REQ (0x0003, 0x002C)

ATT_READ_BLOB_RSP ("te")

Figure 4.22: Read Long Characteristic Descriptor example

Note: The ATT_READ_BLOB_REQ PDU may be used to read the remainder of

an characteristic descriptor value where the first part was read using a simple
ATT_READ_REQ PDU.

Client Server

ATT_READ_REQ (0x0214)

ATT_READ_RSP ("Outside Relative H")

ATT_READ_BLOB_REQ (0x0214, 0x0012)

ATT_READ_BLOB_RSP ("umidity")

Figure 4.23: Read Long Characteristic Descriptor (following simple read) example

4.12.3 Write Characteristic Descriptor

This sub-procedure is used to write a characteristic descriptor value to a server when

the client knows the characteristic descriptor handle.

The ATT_WRITE_REQ PDU is used for this sub-procedure. The Attribute Handle
parameter shall be set to the characteristic descriptor handle. The Attribute Value
parameter shall be set to the new characteristic descriptor value.

An ATT_WRITE_RSP PDU shall be sent by the server if the write of the characteristic
descriptor value succeeded.

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 3, Part G Page 1590
Generic Attribute Profile (GATT)

An ATT_ERROR_RSP PDU shall be sent by the server in response to the

ATT_WRITE_REQ PDU if insufficient authentication, insufficient authorization, a too-
short encryption key size is used by the client, the Attribute Value to be written is too
long (see [Vol 3] Part F, Section 3.4.5.1), or if a write operation is not permitted on the
Characteristic Value. The Error Code parameter shall be set as specified in the Attribute
Protocol. If the characteristic descriptor value has an invalid value as defined by the
profile or the operation is not permitted at this time, then the value shall not be written
and an ATT_ERROR_RSP PDU shall be sent with the Error Code parameter set to
Application Error (0x80 – 0x9F) by the server.

Client Server

ATT_WRITE_REQ (0x0206, "Patio Temperature")

ATT_WRITE_RSP ()

Figure 4.24: Write Characteristic Descriptor example

4.12.4 Write Long Characteristic Descriptor

This sub-procedure is used to write a characteristic descriptor value to a server when

the client knows the characteristic descriptor handle but the length of the characteristic
descriptor value is longer than can be sent in a single ATT_WRITE_REQ PDU.

The ATT_PREPARE_WRITE_REQ and ATT_EXECUTE_WRITE_REQ PDUs are used

to perform this sub-procedure. The Attribute Handle parameter shall be set to the
Characteristic Descriptor Handle of the Characteristic Value to be written. The Part
Attribute Value parameter shall be set to the part of the Attribute Value that is being
written. The Value Offset parameter shall be the offset within the Characteristic Value
to be written. To write the complete Characteristic Value the offset should be set to
0x0000 for the first ATT_PREPARE_WRITE_REQ PDU. The offset for subsequent
ATT_PREPARE_WRITE_REQ PDUs is the next octet that has yet to be written. The
ATT_PREPARE_WRITE_REQ PDU is repeated until the complete Characteristic Value
has been transferred, after which an ATT_EXECUTE_WRITE_REQ PDU is used to
write the complete value.

Note: The values in the ATT_PREPARE_WRITE_RSP PDU do not need to be verified

in this sub-procedure.

An ATT_ERROR_RSP PDU shall be sent by the server in response to the

ATT_PREPARE_WRITE_REQ or ATT_EXECUTE_WRITE_REQ PDUs if insufficient
authentication, insufficient authorization, a too-short encryption key size is used by the

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 3, Part G Page 1591
Generic Attribute Profile (GATT)

client, or if a write operation is not permitted on the Characteristic Value. The Error
Code parameter is set as specified in the Attribute Protocol. If the Attribute Value that is
written is the wrong size, or has an invalid value as defined by the profile, then the write
shall not succeed and an ATT_ERROR_RSP PDU shall be sent with the Error Code
parameter set to Application Error (0x80 – 0x9F) by the server.

Client Server

ATT_PREPARE_WRITE_REQ (0x0214, 0x0000, "My Special Device ")

ATT_PREPARE_WRITE_RSP (0x0214, 0x0000, "My Special Device ")

ATT_PREPARE_WRITE_REQ (0x0214, 0x0012, "Next To The Kitche")

ATT_PREPARE_WRITE_RSP (0x0214, 0x0012, "Next To The Kitche")

ATT_PREPARE_WRITE_REQ (0x0214, 0x0024, "n Door")

ATT_PREPARE_WRITE_RSP (0x0214, 0x0024, "n Door")

ATT_EXECUTE_WRITE_REQ (0x01)

ATT_EXECUTE_WRITE_RSP ()

Figure 4.25: Write Long Characteristic Descriptor example

4.13 GATT procedure mapping to ATT protocol opcodes

Table 4.2 describes the mapping of the ATT protocol opcodes to the GATT procedures
and sub-procedures. Only those portions of the ATT protocol requests, responses,
notifications or indications necessary to implement the mandatory or supported optional
sub-procedures is required.

Feature Sub-Procedure ATT Protocol Opcodes

Server Configuration Exchange MTU ATT_EXCHANGE_MTU_REQ
ATT_EXCHANGE_MTU_RSP
ATT_ERROR_RSP
Primary Service Discov- Discover All Primary Serv- ATT_READ_BY_GROUP_TYPE_REQ
ery ices ATT_READ_BY_GROUP_TYPE_RSP
ATT_ERROR_RSP

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 3, Part G Page 1592
Generic Attribute Profile (GATT)

Feature Sub-Procedure ATT Protocol Opcodes

Discover Primary Service By ATT_FIND_BY_TYPE_VALUE_REQ
Service UUID ATT_FIND_BY_TYPE_VALUE_RSP
ATT_ERROR_RSP
Relationship Discovery Find Included Services ATT_READ_BY_TYPE_REQ
ATT_READ_BY_TYPE_RSP
ATT_ERROR_RSP
Characteristic Discov- Discover All Characteristics ATT_READ_BY_TYPE_REQ
ery of a Service ATT_READ_BY_TYPE_RSP
ATT_ERROR_RSP
Discover Characteristics by ATT_READ_BY_TYPE_REQ
UUID ATT_READ_BY_TYPE_RSP
ATT_ERROR_RSP
Characteristic Descrip- Discover All Characteristic ATT_FIND_INFORMATION_REQ
tor Discovery Descriptors ATT_FIND_INFORMATION_RSP
ATT_ERROR_RSP
Characteristic Value Read Characteristic Value ATT_READ_REQ
Read ATT_READ_RSP
ATT_ERROR_RSP
Read Using Characteristic ATT_READ_BY_TYPE_REQ
UUID ATT_READ_BY_TYPE_RSP
ATT_ERROR_RSP
Read Long Characteristic ATT_READ_BLOB_REQ
Value ATT_READ_BLOB_RSP
ATT_ERROR_RSP
Read Multiple Characteristic ATT_READ_MULTIPLE_REQ
Values ATT_READ_MULTIPLE_RSP
ATT_ERROR_RSP
Read Multiple Variable ATT_READ_MULTIPLE_VARIABLE_REQ
Length Characteristic Values ATT_READ_MULTIPLE_VARIABLE_RSP
ATT_ERROR_RSP
Characteristic Value Write Without Response ATT_WRITE_CMD
Write
Signed Write Without Re- ATT_SIGNED_WRITE_CMD
sponse

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 3, Part G Page 1593
Generic Attribute Profile (GATT)

Feature Sub-Procedure ATT Protocol Opcodes

Write Characteristic Value ATT_WRITE_REQ
ATT_WRITE_RSP
ATT_ERROR_RSP
Write Long Characteristic ATT_PREPARE_WRITE_REQ
Value ATT_PREPARE_WRITE_RSP
ATT_EXECUTE_WRITE_REQ
ATT_EXECUTE_WRITE_RSP
ATT_ERROR_RSP
Characteristic Value Reliable ATT_PREPARE_WRITE_REQ
Writes ATT_PREPARE_WRITE_RSP
ATT_EXECUTE_WRITE_REQ
ATT_EXECUTE_WRITE_RSP
ATT_ERROR_RSP
Characteristic Value No- Single Notification ATT_HANDLE_VALUE_NTF
tification
Multiple Variable Length No- ATT_MULTIPLE_HANDLE_VALUE_NTF
tifications
Characteristic Value In- Indication ATT_HANDLE_VALUE_IND
dication ATT_HANDLE_VALUE_CFM
Characteristic Descrip- Read Characteristic Descrip- ATT_READ_REQ
tor Value Read tor ATT_READ_RSP
ATT_ERROR_RSP
Read Long Characteristic ATT_READ_BLOB_REQ
Descriptor ATT_READ_BLOB_RSP
ATT_ERROR_RSP
Characteristic Descrip- Write Characteristic Descrip- ATT_WRITE_REQ
tor Value Write tor ATT_WRITE_RSP
ATT_ERROR_RSP
Write Long Characteristic ATT_PREPARE_WRITE_REQ
Descriptor ATT_PREPARE_WRITE_RSP
ATT_PREPARE_WRITE_REQ
ATT_PREPARE_WRITE_RSP
ATT_ERROR_RSP

Table 4.2: GATT procedure mapping to ATT protocol opcodes

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 3, Part G Page 1594
Generic Attribute Profile (GATT)

4.14 Procedure timeouts

GATT procedures are protected from failure with an Attribute Protocol transaction
timeout.

If the Attribute Protocol transaction times out, the procedure shall be considered to have
failed, and the local higher layer shall be notified. No further GATT procedures shall
be performed on that ATT bearer. A new GATT procedure shall only be performed on
another ATT bearer.

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 3, Part G Page 1595
Generic Attribute Profile (GATT)

5 L2CAP INTEROPERABILITY REQUIREMENTS

The following default values shall be used by an implementation of this profile. The
default values used may be different depending on the physical channel that the
Attribute Protocol is being sent over.

5.1 BR/EDR L2CAP interoperability requirements

When using an Unenhanced ATT bearer, L2CAP connection-oriented channels over
BR/EDR not in Enhanced Flow Control mode can be used to transmit Attribute Protocol
PDUs. These channels use the channel establishment procedure from L2CAP using
the ATT fixed PSM (see [1]) including the configuration procedure to determine the
ATT_MTU (see [Vol 3] Part A, Section 5.1). Therefore, the ATT bearer (or the logical
link as referred to in the Attribute Protocol) is, in this case, an established L2CAP
connection-oriented channel.

5.1.1 ATT_MTU

At the end of the L2CAP configuration phase, upon transition to the OPEN state, the
ATT_MTU for this ATT bearer shall be set to the minimum of the negotiated Maximum
Transmission Unit configuration options.

Note: The minimum ATT_MTU for BR/EDR is 48 octets, as defined by L2CAP in [Vol 3]
Part A, Section 5.1.

5.1.2 BR/EDR channel requirements

All Attribute Protocol messages sent by GATT over an L2CAP channel are sent using a
dynamic channel ID derived by connecting using a fixed PSM. The use of a fixed PSM
allows rapid reconnection of the L2CAP channel for Attribute Protocol as a preliminary
SDP query is not required.

All packets sent on this L2CAP channel shall be Attribute PDUs.

PDUs shall be reliably sent.

The flow specification for the Attribute Protocol shall be best effort.

If operating in Basic L2CAP mode, the information payload of the L2CAP B-frame shall
be a single Attribute PDU.

The channel shall be encrypted. The Key_Type shall be either an Unauthenticated

Combination Key or an Authenticated Combination Key.

The L2CAP connection may be initiated by the client or by the server.

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 3, Part G Page 1596
Generic Attribute Profile (GATT)

5.1.3 [This section is no longer used]

5.2 LE L2CAP interoperability requirements

When using an Unenhanced ATT bearer, the channel used to carry Attribute Protocol
PDUs over LE is the Attribute L2CAP fixed channel.

To terminate the ATT bearer, the physical channel has to be disconnected.

5.2.1 ATT_MTU

Both GATT Client and GATT Server implementations shall support an ATT_MTU not
less than the default value.

Default Value Value for LE

ATT_MTU 23

Table 5.1: LE L2CAP ATT_MTU

5.2.2 LE channel requirements

L2CAP fixed CID 0x0004 shall be used for the Attribute Protocol. All packets sent on
this fixed channel shall be Attribute Protocol PDUs.

The flow specification for the Attribute Protocol shall be best effort.

PDUs shall be reliably sent, and not flushed.

The retransmission and flow control mode for this channel shall be Basic L2CAP mode

The default parameters for the payload of the L2CAP B-frame shall be a single Attribute
PDU.

Parameter Value
MTU 23
Flush Timeout 0xFFFF (Infinite)
QoS Best Effort
Mode Basic Mode

Table 5.2: Attribute Protocol fixed channel configuration parameters

5.3 Enhanced ATT bearer L2CAP interoperability requirements

When using an Enhanced ATT bearer over BR/EDR, L2CAP connection-oriented
channels in Enhanced Retransmission Mode are used to transmit Attribute Protocol
PDUs. Such channels are established using L2CAP_CONNECTION_REQ packets.

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 3, Part G Page 1597
Generic Attribute Profile (GATT)

When using an Enhanced ATT bearer over LE, L2CAP connection-oriented

channels in Enhanced Credit Based Flow Control mode are used to
transmit Attribute Protocol PDUs. Such channels are established using
L2CAP_CREDIT_BASED_CONNECTION_REQ packets.

In both cases, the EATT fixed PSM [1] is used and the ATT bearer is the established
L2CAP connection-oriented channel.

Multiple L2CAP channels can be established between a client and a server.

5.3.1 ATT_MTU

The ATT_MTU for the Enhanced ATT bearer shall be set to

the minimum of the MTU field values of the two devices; these
values come from the L2CAP_CREDIT_BASED_CONNECTION_REQ and
L2CAP_CREDIT_BASED_CONNECTION_RSP signaling packets or the latest
L2CAP_CREDIT_BASED_RECONFIGURE_REQ packets.

Note: The minimum ATT_MTU for an Enhanced ATT bearer is 64 octets.

5.3.2 Channel Requirements

All Attribute Protocol messages sent by GATT over an L2CAP Enhanced Credit Based
Flow Control mode channel are sent using one of the dynamic channel IDs derived by
connecting using a fixed PSM.

All packets sent on this L2CAP channel shall be Attribute PDUs.

The flow specification for the Attribute Protocol shall be best effort.

The information payload of the L2CAP K-frame shall be a single Attribute PDU.

The channel shall be encrypted.

5.4 L2CAP collision mitigation

If both devices request L2CAP connections simultaneously and both devices have
limited resources, a device may reject the incoming request and find its own request is
also rejected. In this situation, the Central may retry immediately but the Peripheral shall
wait a minimum of 100 ms before retrying; on LE connections, the Peripheral shall wait
at least 2 × (connPeripheralLatency + 1) × connInterval if that is longer.

5.5 Bearer support

A GATT implementation supporting bearers over BR/EDR shall support at least one of
Unenhanced and Enhanced ATT bearers over BR/EDR and may support both.

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 3, Part G Page 1598
Generic Attribute Profile (GATT)

A GATT implementation supporting bearers over LE shall support Unenhanced ATT

bearers over LE and may support Enhanced ATT bearers over LE.

Note: A GATT implementation supporting bearers over both BR/EDR and LE therefore
may support any combination of bearers provided that it supports Unenhanced ATT
bearers over LE and at least one type of ATT bearer over BR/EDR.

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 3, Part G Page 1599
Generic Attribute Profile (GATT)

6 GAP INTEROPERABILITY REQUIREMENTS

6.1 BR/EDR GAP interoperability requirements

6.1.1 Connection Establishment

To establish an Unenhanced ATT bearer, the Channel Establishment procedure (as

defined in [Vol 3] Part C, Section 7.2) shall be used with the PSM set to ATT.

Either device may establish an ATT bearer at any time.

To establish an Enhanced ATT bearer, the Section 5.3 procedure shall be used with
the fixed PSM set to EATT. A device shall not attempt to establish an Enhanced
ATT bearer with a peer unless it is aware that the peer supports Enhanced ATT
bearers, for example by using an out of band method, via a higher layer protocol, or
because the device has checked the peer’s Server Supported Features characteristic
(see Section 7.4) or its SDP record.

Either device may terminate an ATT bearer at any time.

No idle mode procedures or modes are defined by this profile.

6.2 LE GAP interoperability requirements

6.2.1 Connection Establishment

To establish an Unenhanced ATT bearer, the Connection Establishment procedure (as

defined in [Vol 3] Part C, Section 9.3.5 to Section 9.3.8) shall be used.

To establish an Enhanced ATT bearer, the Section 5.3 procedure shall be used with the
fixed PSM set to EATT.

Either device may terminate an ATT bearer at any time.

No idle mode procedures or modes are defined by this profile.

Note: Unlike BR/EDR, it is not necessary to check the Server Supported Features
characteristic before attempting to establish an Enhanced ATT bearer.

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 3, Part G Page 1600
Generic Attribute Profile (GATT)

6.2.2 Profile roles

This profile can be used in the following profile roles (as defined in [Vol 3] Part C,
Section 2.2.2):

• Central
• Peripheral

6.3 Disconnected events

6.3.1 Notifications and indications while disconnected

If a client has configured the server to send a notification or indication to the client, it
shall be configured to allow re-establishment of the connection when it is disconnected.

If the client is disconnected, but intends to become a Central in the connection it shall
perform a GAP connection establishment procedure. If the client is disconnected, but
intends to become a Peripheral in the connection it shall go into a GAP connectable
mode.

A server shall re-establish a connection with a client when an event or trigger operation
causes a notification or indication to a client.

If the server is disconnected, but intends to become a Peripheral in the connection it

shall go into a GAP connectable mode. If the server is disconnected, but intends to
become a Central in the connection it shall perform a GAP connection establishment
procedure.

If the server cannot re-establish a connection, then the notification or indication for this
event shall be discarded and no further connection re-establishment shall occur, until
another event occurs.

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 3, Part G Page 1601
Generic Attribute Profile (GATT)

7 DEFINED GENERIC ATTRIBUTE PROFILE SERVICE

All characteristics defined within this section shall be contained in a primary service with
the service UUID set to «GATT Service» as defined in Section 3.1. Only one instance of
the GATT service shall be exposed on a GATT Server.

Table 7.1 lists characteristics that may be present in the server and the characteristics
that may be supported by the client.

Characteristic Ref. Support in Client Support in Server

Service Changed 7.1 M C.1
Client Supported Features 7.2 O C.2
Database Hash 7.3 O O
Server Supported Features 7.4 O C.3
C.1: Mandatory if service definitions on the server can be added, changed, or removed; otherwise
excluded
C.2: Mandatory if the Database Hash and Service Changed characteristics are supported or if En-
hanced ATT Bearer or Multiple Variable Length Notifications are supported; otherwise excluded
C.3: Mandatory if any of the features in Table 7.11 are supported, otherwise optional

Table 7.1: GATT service characteristic support

The assigned UUIDs for these characteristics are defined in Assigned Numbers [1].

7.1 Service Changed

The «Service Changed» characteristic is a control-point attribute (as defined in [Vol 3]
Part F, Section 3.2.6) that shall be used to indicate to connected devices that services
have changed (i.e., added, removed or modified). The characteristic shall be used to
indicate to clients that have a trusted relationship (i.e. bond) with the server when GATT
based services have changed when they re-connect to the server. See Section 2.5.2.

This Characteristic Value shall be configured to be indicated using the Client

Characteristic Configuration descriptor by a client. Indications caused by changes to
the Service Changed Characteristic Value shall be considered lost if the client has
erroneously not enabled indications in the Client Characteristic Configuration descriptor
(see [Vol 3] Part F, Section 3.3.3).

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 3, Part G Page 1602
Generic Attribute Profile (GATT)

Attribute Attribute Attribute Value Attribute

Handle Type Permission
0xNNNN 0x2803 – Character- 0xMMMM = 0x2A05 – No Authentication,
UUID for istic Prop- Handle of Char- UUID for No Authorization
«Characteris- erties = acteristic Value «Service
tic» 0x20 Changed»

Table 7.2: Service Changed Characteristic declaration

The Service Changed Characteristic Value is two 16-bit Attribute Handles concatenated
together indicating the beginning and ending Attribute Handles affected by an addition,
removal, or modification to a GATT-based service on the server. A change to a
characteristic value is not considered a modification of the service. If a change has
been made to any of the GATT service definition characteristic values other than the
Service Changed characteristic value and the Client Supported Features characteristic
value, the range shall also include the beginning and ending Attribute Handle for the
GATT service definition.

Attribute Attribute Type Attribute Value Attribute Permission

Handle
0xMMMM 0x2A05 – UUID 0xSSSS – Start of 0xTTTT – End of No Authentication,
for «Service Affected Attribute Affected Attribute No Authorization, Not
Changed» Handle Range Handle Range Readable, Not Writable

Table 7.3: Service Changed Characteristic Value declaration

There shall be only one instance of the Service Changed characteristic within the GATT
service definition. A Service Changed characteristic value shall exist for each client with
a trusted relationship.

If the list of GATT based services and the service definitions cannot change for the
lifetime of the device then this characteristic shall not exist, otherwise this characteristic
shall exist.

If the Service Changed characteristic exists on the server, the Characteristic Value
Indication support on the server is mandatory.

The client shall support Characteristic Value Indication of the Service Changed
characteristic.

The Service Changed characteristic Attribute Handle on the server shall not change if
the server has a trusted relationship with any client.

7.2 Client Supported Features

The Client Supported Features characteristic is used by the client to inform the server
which features are supported by the client. If the characteristic exists on the server, the

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 3, Part G Page 1603
Generic Attribute Profile (GATT)

client may update the Client Supported Features bit field. If a client feature bit is set
by a client and the server supports that feature, the server shall fulfill all requirements
associated with this feature when communicating with this client. If a client feature bit is
not set by a client, then the server shall not use any of the features associated with that
bit when communicating with this client.

Attribute Attribute Attribute Value Attribute

Handle Type Permission
0xNNNN 0x2803 – Character- 0xMMMM = 0x2B29 – Read only,
UUID for istic Prop- Handle of Char- UUID for «Cli-
No Authentication,
«Characteris- erties = acteristic Value ent Suppor-
tic» 0x0A ted Features» No Authorization

Table 7.4: Client Supported Features characteristic declaration

The format of the Client Supported Features characteristic is defined in Table 7.5.

Attribute Attribute Type Attribute Value Attribute Permission

Handle
0xMMMM 0x2B29 - UUID for 0xXX...XX (variable length) - Client Readable,
«Client Supported Features Writable,
Features»
No Authentication,
No Authorization

Table 7.5: Client Supported Features value declaration

The Client Supported Features characteristic value is an array of octets, each of which
is a bit field. The allocation of these bits is specified in Table 7.6. All bits not listed are
reserved for future use. The array should not have any trailing all-zero octets.

If any octet number in Table 7.6 does not appear in the attribute value because it is too
short, the server shall behave as if that octet were present with a value of zero.

Client Features Octet Bit Ref. Description

Robust Caching 0 0 2.5.2.1 The client supports robust caching
Enhanced ATT bearer 0 1 5.3 The client supports Enhanced ATT bearer
Multiple Handle Value Notifica- 0 2 4.10.2 The client supports receiving ATT_MULTI-
tions PLE_HANDLE_VALUE_NTF PDUs

Table 7.6: Client Supported Features bit assignments

The default value for the Client Supported Features characteristic value shall be all bits
set to zero.

There shall be only one instance of the Client Supported Features characteristic within
the GATT service definition.

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 3, Part G Page 1604
Generic Attribute Profile (GATT)

A Client Supported Features characteristic value shall exist for each connected client.
For clients with a trusted relationship, the characteristic value shall be persistent across
connections. For clients without a trusted relationship the characteristic value shall be
set to the default value at each connection.

The Attribute Handle of the Client Supported Features characteristic on the server shall
not change during a connection or if the server has a trusted relationship with any client.

A client shall not clear any bits it has set. The server shall respond to any such request
with the Error Code parameter set to Value Not Allowed (0x13).

7.3 Database Hash

The Database Hash characteristic contains the result of a hash function applied to the
service definitions in the GATT database. The client may read the characteristic at any
time to determine if services have been added, removed, or modified. If any of the input
fields to the hash function (as listed in Section 7.3.1) have changed, the server shall
calculate a new Database Hash and update the characteristic value.

The Database Hash characteristic is a read-only attribute.

Attribute Attribute Attribute Value Attribute

Handle Type Permission
0xNNNN 0x2803 – Character- 0xMMMM = 0x2B2A – Read only,
UUID for istic Prop- Handle of Char- UUID for
No Authentication,
«Characteris- erties = acteristic Value «Database
tic» 0x02 Hash» No Authorization

Table 7.7: Database Hash characteristic declaration

The characteristic value is a 128-bit unsigned integer number. The calculation of the
Database Hash is specified in Section 7.3.1.

Attribute Attribute Type Attribute Value Attribute Permission

Handle
0xMMMM 0x2B2A - UUID for «Database uint128 - Database Hash Read only,
Hash» No Authentication,
No Authorization

Table 7.8: Database Hash characteristic value declaration

There is only one instance of the Database Hash characteristic within the GATT service
definition. The same Database Hash value is used for all clients, whether a trusted
relationship exists or not.

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 3, Part G Page 1605
Generic Attribute Profile (GATT)

In order to read the value of this characteristic the client shall always use the GATT
Read Using Characteristic UUID sub-procedure. The Starting Handle should be set to
0x0001 and the Ending Handle should be set to 0xFFFF.

If a client reads the value of this characteristic while the server is re-calculating the hash
following a change to the database, the server shall return the new hash, delaying its
response until it is available.

7.3.1 Database Hash calculation

The Database Hash shall be calculated according to RFC-4493[2]. This RFC defines
the Cipher-based Message Authentication Code (CMAC) using AES-128 as the block
cipher function, also known as AES-CMAC.

The inputs to AES-CMAC are:

m is the variable length data to be hashed

k is the 128-bit key, which shall be all zero
(0x00000000_00000000_00000000_00000000)

The 128-bit Database Hash is generated as follows:

Database Hash = AES-CMACk(m), where m is calculated as follows:

In ascending order of attribute handles, starting with the first handle,

concatenate the fields Attribute Handle, Attribute Type, and Attribute Value if
the attribute has one of the following types: «Primary Service», «Secondary
Service», «Included Service», «Characteristic», or «Characteristic Extended
Properties», concatenate the fields Attribute Handle and Attribute Type if the
attribute has one of the following types: «Characteristic User Description»,
«Client Characteristic Configuration», «Server Characteristic Configuration»,
«Characteristic Presentation Format», or «Characteristic Aggregate Format», and
ignore the attribute if it has any other type (such attributes are not part of the
concatenation).
For each Attribute Handle, the fields shall be concatenated in the order given
above. The byte order used for each field or subfield value shall be little-endian.
If a field contains subfields, the subfields shall be concatenated in the order
they appear in Section 3 (Service Interoperability Requirements). For instance,
a characteristic declaration value of {0x02, 0x0005, 0x2A00} is represented after
concatenation as 02 05 00 00 2A.

The formats of the fields Attribute Handle, Attribute Type, and Attribute Value for
the Attribute Types listed above are defined in Section 3 (Service Interoperability
Requirements).

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 3, Part G Page 1606
Generic Attribute Profile (GATT)

If the length of m is not a multiple of the AES-CMAC block length of 128 bits, padding
shall be applied as specified in RFC-4493 Section 2.4.

7.4 Server Supported Features

The Server Supported Features characteristic is a read-only characteristic that shall
be used to indicate support for server features. The server shall set a bit only if the
corresponding feature is supported.

Attribute Attribute Attribute Value Attribute

Handle Type Permission
0xNNNN 0x2803 – Character- 0xMMMM = 0x2B3A – Read Only,
UUID for istic Prop- Handle of Char- UUID for No Authentication,
«Characteris- erties = acteristic Value «Server Sup-
tic» 0x02 ported Fea- No Authorization
tures»

Table 7.9: Server Supported Features characteristic declaration

Attribute Attribute Type Attribute Value Attribute

Handle Permission
0xMMMM 0x2B3A – UUID for «Server 0xuu - Server Supported Readable
Supported Features» Features

Table 7.10: Server Supported Features value declaration

The Server Supported Features characteristic is an array of octets, each of which is

a bit field. The allocation of these bits is specified in Table 7.11. All bits not listed are
reserved for future use. The array should not have any trailing all-zero octets.

Server Supported Features Octet Bit Ref. Description

EATT Supported 0 0 5.3 Enhanced ATT bearer supported

Table 7.11: Server Supported Features bit assignments

If any octet number in Table 7.11 does not appear in the attribute value because it is too
short, the client shall behave as if that octet were present with the value of zero.

There shall be only one instance of the Server Supported Features characteristic within
the GATT service definition.

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 3, Part G Page 1607
Generic Attribute Profile (GATT)

8 SECURITY CONSIDERATIONS

8.1 Authentication requirements

Authentication in the GATT Profile is applied to each characteristic independently.

Authentication requirements are specified in this profile, related higher layer
specifications or are implementation specific if not specified otherwise.

The GATT Profile procedures are used to access information that may require the client
to be authenticated and have an encrypted connection before a characteristic can be
read or written.

If such a request is issued when the physical link is unauthenticated or unencrypted, the
server shall send an ATT_ERROR_RSP PDU. The client wanting to read or write this
characteristic can then request that the physical link be authenticated using the GAP
authentication procedure, and once this has been completed, send the request again.

The list of services and characteristics that a device supports is not considered private
or confidential information, and therefore the Service and Characteristic Discovery
procedures shall always be permitted. This implies that an Error Code parameter set
to Insufficient Authentication (0x05) shall not be used in an ATT_ERROR_RSP PDU for
a Find Information Request.

Note: A characteristic may be allowed to be read by any device, but only written by an
authenticated device. An implementation should take this into account, and not assume
that if it can read a Characteristic Value, it will also be able to write the Characteristic
Value. Similarly, if a characteristic can be written, it does not mean the characteristic
can also be read. Each individual characteristic could have different security properties.

Once sufficient authentication of the client has been established to allow access
to one characteristic within a service definition, a server may also allow access to
other characteristics within the service definition depending on the higher level or
implementation specific requirements.

A server may allow access to most characteristics within a service definition once
sufficient authentication has been performed, but restrict access to other characteristics
within the same service definition. This may result due to some characteristics requiring
stronger authentication requirements than currently enabled.

Once a server has authenticated a client for access to characteristics in one

service definition, it may automatically allow access to characteristics in other service
definitions.

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 3, Part G Page 1608
Generic Attribute Profile (GATT)

8.2 Authorization requirements

Authorization in the GATT Profile is applied to each characteristic independently.
Authorization requirements may be specified in this profile, related higher layer
specifications or are implementation specific if not specified otherwise.

The GATT Profile can be used to access information that may require authorization
before a characteristic can be read or written.

If such a request is issued to a characteristic contained in a service definition that is not

authorized, the responder shall send an ATT_ERROR_RSP PDU with the Error Code
parameter set to Insufficient Authorization (0x08).

Once a server has authorized a client for access to characteristics in one group or
service definition, it may automatically allow access to characteristics in other service
definitions.

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 3, Part G Page 1609
Generic Attribute Profile (GATT)

9 SDP INTEROPERABILITY REQUIREMENTS

A device that supports GATT over BR/EDR and only one of ATT or EATT shall publish
the SDP record shown in Table 9.1; if both ATT and EATT are supported, the device
shall publish the SDP record shown in Table 9.2. The GATT Service Start Handle shall
be set to the attribute handle of the «GATT Service» service declaration. The GATT
Service End Handle shall be set to the attribute handle of the last attribute within the
«GATT Service» service definition group.

Item Type Value Meaning

Attribute ID uint16 0x0001 ServiceClassIDList
Attribute Value Data element sequence (1 item)
Service Class UUID «GATT Service»
Attribute ID uint16 0x0004 ProtocolDescriptorList
Attribute Value Data element sequence (2 items)
Protocol Descriptor Data element sequence (2 items)
Protocol UUID «L2CAP»
Parameter 0 uint16 0x001F PSM = ATT
or 0x0027 or PSM = EATT
Protocol Descriptor Data element sequence (3 items)
Protocol UUID «ATT»
Parameter 0 uint16 0xHHHH GATT service start handle
Parameter 1 uint16 0xHHHH GATT service end handle
Attribute ID uint16 0x0005 BrowseGroupList
Attribute Value Data element sequence (1 item)
Group UUID «PublicBrowseRoot»

Table 9.1: SDP record for the Generic Attribute Profile, if only one of ATT or EATT is supported

Item Type Value Meaning

Attribute ID uint16 0x0001 ServiceClassIDList
Attribute Value Data element sequence (1 item)
Service class UUID «GATT Service»
Attribute ID uint16 0x0004 ProtocolDescriptorList
Attribute Value Data element sequence (2 items)
Protocol Descriptor Data element sequence (2 items)

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 3, Part G Page 1610
Generic Attribute Profile (GATT)

Item Type Value Meaning

Protocol UUID «L2CAP»
Parameter 0 uint16 0x001F PSM = ATT
Protocol Descriptor Data element sequence (3 items)
Protocol UUID «ATT»
Parameter 0 uint16 0xHHHH GATT service start handle
Parameter 1 uint16 0xHHHH GATT service end handle
Attribute ID uint16 0x000D AdditionalProtocolDescrip-
torLists
Attribute Value Data element sequence (1 item)
Protocol Descriptor List Data element sequence (2 items)
Protocol Descriptor Data element sequence (2 items)
Protocol UUID «L2CAP»
Parameter 0 uint16 0x0027 PSM = EATT
Protocol Descriptor Data element sequence (3 items)
Protocol UUID «ATT»
Parameter 0 uint16 0xHHHH GATT service start handle
Parameter 1 uint16 0xHHHH GATT service end handle
Attribute ID uint16 0x0005 BrowseGroupList
Attribute Value Data element sequence (1 item)
Group UUID «PublicBrowseRoot»

Table 9.2: SDP record for the Generic Attribute Profile, if both ATT and EATT are supported

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 3, Part G Page 1611
Generic Attribute Profile (GATT)

10 REFERENCES

[1] Assigned Numbers Specification: https://www.bluetooth.com/specifications/

assigned-numbers
[2] RFC-4493: http://www.ietf.org/rfc/rfc4493.txt
[3] Core Specification Supplement, Part A, Data Types Specification

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 3, Part G Page 1612
Generic Attribute Profile (GATT)

Appendix A Example ATT Server contents

Table A.1 shows an example ATT Server and the attributes contained on the server.

Note: This example does not necessarily use UUIDs or services defined by the
Bluetooth SIG or in adopted profiles.

Handle Attribute Type Attribute Value

0x0001 «Primary Service» «GAP Service»
0x0004 «Characteristic» {0x02, 0x0006, «Device Name»}
0x0006 «Device Name» “Example Device”
0x0010 «Primary Service» «GATT Service»
0x0011 «Characteristic» {0x26, 0x0012, «Service Changed»}
0x0012 «Service Changed» 0x0000, 0x0000
0x0100 «Primary Service» «Battery State Service»
0x0106 «Characteristic» {0x02, 0x0110, «Battery State»}
0x0110 «Battery State» 0x04
0x0200 «Primary Service» «Thermometer Humidity Service»
0x0201 «Include» {0x0500, 0x0504, «Manufacturer Service»}
0x0202 «Include» {0x0550,0x0568}
0x0203 «Characteristic» {0x02, 0x0204, «Temperature»}
0x0204 «Temperature» 0x028A
0x0205 «Characteristic Presentation Format» {0x0E, 0xFE, «degrees Celsius», 0x01,
«Outside»}
0x0206 «Characteristic User Description» “Outside Temperature”
0x0210 «Characteristic» {0x02, 0x0212, «Relative Humidity»}
0x0212 «Relative Humidity» 0x27
0x0213 «Characteristic Presentation Format» {0x04, 0x00, «Percent», «Bluetooth SIG», «Out-
side»}
0x0214 «Characteristic User Description» “Outside Relative Humidity”
0x0280 «Primary Service» «Weight Service»
0x0281 «Include» 0x0505, 0x0509, «Manufacturer Service»}
0x0282 «Characteristic» {0x02, 0x0283, «Weight kg»}
0x0283 «Weight kg» 0x00005582

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 3, Part G Page 1613
Generic Attribute Profile (GATT)

Handle Attribute Type Attribute Value

0x0284 «Characteristic Presentation Format» {0x08, 0xFD, «kilogram», «Bluetooth SIG», «Hang-
ing»}
0x0285 «Characteristic User Description» “Rucksack Weight”
0x0300 «Primary Service» «Position Service»
0x0301 «Characteristic» {0x02, 0x0302, «Latitude Longitude»}
0x0302 «Latitude Longitude» 0x28BEAFA40B320FCE
0x0304 «Characteristic» {0x02, 0x0305, «Latitude Longitude Elevation»}
0x0305 «Latitude Longitude Elevation» 0x28BEAFA40B320FCE0176
0x0400 «Primary Service» «Alert Service»
0x0401 «Characteristic» {0x0E, 0x0402, «Alert Enumeration»}
0x0402 «Alert Enumeration» 0x00
0x0500 «Secondary Service» «Manufacturer Service»
0x0501 «Characteristic» {0x02, 0x0502, «Manufacturer Name»}
0x0502 «Manufacturer Name» “ACME Temperature Sensor”
0x0503 «Characteristic» {0x02, 0x0504, «Serial Number»}
0x0504 «Serial Number» “237495-3282-A”
0x0505 «Secondary Service» «Manufacturer Service»
0x0506 «Characteristic» {0x02, 0x0507, «Manufacturer Name»}
0x0507 «Manufacturer Name» “ACME Weighing Scales”
0x0508 «Characteristic» {0x02, 0x0509, «Serial Number»}
0x0509 «Serial Number» “11267-2327A00239”
0x0550 «Secondary Service» «Vendor Specific Service»
0x0560 «Characteristic» {0x02, 0x0568, «Vendor Specific Type»}
0x0568 «Vendor Specific Type» 0x56656E646F72

Table A.1: Examples of ATT Server contents

As can be seen, the ATT Server indicates support for ten services: GAP Service, GATT
Service, Battery State Service, Thermometer Humidity Service, Weight Service, Position
Service, Alert Service, two Manufacturer Services, and a Vendor Specific Service.

The server contains the following information about each of the services:

• The characteristic containing the name of the device is “Example Device”.

• The characteristic indicating the server supports all the attribute opcodes, and
supports two prepared write values.

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 3, Part G Page 1614
Generic Attribute Profile (GATT)

• The characteristic containing the battery state with a value of 0x04, meaning it is
discharging.
• The characteristic containing the outside temperature with a value of 6.5 °C.
• The characteristic containing the outside relative humidity with a value of 39%.
• The characteristic containing the weight hanging off the device with a value of 21.89
kg.
• The characteristic containing the position of this device with the value of 68.3585444
degrees north, 18.7830222 degrees east, with an elevation of 374 meters.
• The characteristic containing the temperature sensor manufacturer with the value of
ACME Temperature Sensor.
• The characteristic containing the serial number for the temperature sensor with a
value of 237495-3282-A.
• The characteristic containing the weighing sensor is manufacturer with a value of
ACME Weight Scales.
• The characteristic containing the serial number for the weighing sensor with a value
of 11267-2327A00239.

The device is therefore on the side of the Abisko Turiststation, Norrbottens Län,
Sweden, with a battery in good state, measuring a relatively warm day, with low
humidity, and a heavy rucksack.

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 3, Part G Page 1615
Generic Attribute Profile (GATT)

Appendix B Example Database Hash

Table B.1 shows how the variable length data m for calculating the Database Hash is
constructed from an example GATT database. The column Included in Hash indicates
whether the Attribute Handle (H), Attribute Type (T), or Attribute Value (V) are included
in m.

Attribute Attribute Attribute Notes Included Data Included in

Handle Type Value in Hash m
0x0001 0x2800 0x1800 Primary Service: GAP HTV 01 00 00 28 00
Service 18
0x0002 0x2803 {0x0A, Characteristic (Read, HTV 02 00 03 28 0A
0x0003, Write): Device Name 03 00 00 2A
0x2A00}
0x0003 0x2A00 any Characteristic Value: De- No none
vice Name
0x0004 0x2803 {0x02, Characteristic (Read): HTV 04 00 03 28 02
0x0005, Appearance 05 00 01 2A
0x2A01}
0x0005 0x2A01 any Characteristic Value: Ap- No none
pearance
0x0006 0x2800 0x1801 Primary Service: GATT HTV 06 00 00 28 01
Service 18
0x0007 0x2803 {0x20, Characteristic (Indicate): HTV 07 00 03 28 20
0x0008, Service Changed 08 00 05 2A
0x2A05}
0x0008 0x2A05 any Characteristic Value: No none
Service Changed
0x0009 0x2902 0x0002 Client Characteristic Con- HT 09 00 02 29
figuration Descriptor
0x000A 0x2803 {0x0A, Characteristic (Read, HTV 0A 00 03 28 0A
0x000B, Write): Client Supported 0B 00 29 2B
0x2B29} Features
0x000B 0x2B29 any Characteristic Value: Cli- No none
ent Supported Features
0x000C 0x2803 {0x02, Characteristic (Read): HTV 0C 00 03 28 02
0x000D, Database Hash 0D 00 2A 2B
0x2B2A}
0x000D 0x2B2A any Characteristic Value: Da- No none
tabase Hash

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 3, Part G Page 1616
Generic Attribute Profile (GATT)

Attribute Attribute Attribute Notes Included Data Included in

Handle Type Value in Hash m
0x000E 0x2800 0x1808 Primary Service: Glucose HTV 0E 00 00 28 08
Service 18
0x000F 0x2802 {0x0014, Included Service: Battery HTV 0F 00 02 28 14
0x0016, Service 00 16 00 0F 18
0x180F}
0x0010 0x2803 {0xA2, Characteristic (Read, In- HTV 10 00 03 28 A2
0x0011, dicate, Extended Proper- 11 00 18 2A
0x2A18} ties): Glucose Measure-
ment
0x0011 0x2A18 any Characteristic Value: Glu- No none
cose Measurement
0x0012 0x2902 0x0002 Client Characteristic Con- HT 12 00 02 29
figuration Descriptor
0x0013 0x2900 0x0000 Extended Properties HTV 13 00 00 29 00
00
0x0014 0x2801 0x180F Secondary Service: Bat- HTV 14 00 01 28 0F
tery Service 18
0x0015 0x2803 {0x02, Characteristic (Read): HTV 15 00 03 28 02
0x0016, 16 00 19 2A
Battery Level
0x2A19}
0x0016 0x2A19 any Characteristic Value: Bat- No none
tery Level

Table B.1: Example database

The resulting variable length data m divided into blocks M0 to M6 is:

M0: 01000028 00180200 03280A03 00002A04

M1: 00032802 0500012A 06000028 01180700
M2: 03282008 00052A09 0002290A 0003280A
M3: 0B00292B 0C000328 020D002A 2B0E0000
M4: 2808180F 00022814 0016000F 18100003
M5: 28A21100 182A1200 02291300 00290000
M6: 14000128 0F181500 03280216 00192A

The resulting Database Hash is (MSB to LSB):

Database Hash = AES-CMACk(m) = F1 CA 2D 48 EC F5 8B AC 8A

88 30 BB B9 FB A9 90

Note: The bytes in M0 to M6 and the Database Hash are ordered from the most
significant on the left to the least significant on the right.

Bluetooth SIG Proprietary Version Date: 2024-08-27

 Host
Part H

SECURITY MANAGER
SPECIFICATION

The Security Manager (SM) defines the protocol

and behavior to manage pairing, authentication, and
encryption between LE-only or BR/EDR/LE devices.

Bluetooth SIG Proprietary

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 3, Part H Page 1618
Security Manager Specification

CONTENTS

1 Introduction ............................................................................................. 1622

1.1 Scope ........................................................................................ 1622
1.2 Conventions .............................................................................. 1622
1.2.1 Bit and byte ordering conventions ............................. 1622
1.2.2 Random numbers ...................................................... 1623

2 Security Manager .................................................................................... 1624

2.1 Introduction ............................................................................... 1624
2.2 Cryptographic toolbox ............................................................... 1626
2.2.1 Security function e ..................................................... 1627
2.2.2 Random address hash function ah ............................ 1627
2.2.3 Confirm value generation function c1 for LE
legacy pairing ............................................................. 1628
2.2.4 Key generation function s1 for LE legacy pairing ...... 1629
2.2.5 Function AES-CMAC ................................................. 1630
2.2.6 LE Secure Connections confirm value
generation function f4 ................................................ 1630
2.2.7 LE Secure Connections key generation function f5 ... 1631
2.2.8 LE Secure Connections check value generation
function f6 .................................................................. 1633
2.2.9 LE Secure Connections numeric comparison
value generation function g2 ..................................... 1634
2.2.10 Link key conversion function h6 ................................ 1635
2.2.11 Link key conversion function h7 ................................ 1635
2.3 Pairing methods ........................................................................ 1636
2.3.1 Security Properties .................................................... 1637
2.3.2 IO capabilities ............................................................ 1638
2.3.3 OOB authentication data ........................................... 1638
2.3.4 Encryption key size .................................................... 1639
2.3.5 Pairing algorithms ...................................................... 1639
2.3.5.1 Selecting key generation method ............... 1640
2.3.5.2 LE legacy pairing - Just Works ................... 1642
2.3.5.3 LE legacy pairing - Passkey Entry ............. 1643
2.3.5.4 Out of band ................................................ 1643
2.3.5.5 LE legacy pairing phase 2 .......................... 1644
2.3.5.6 LE Secure Connections pairing phase 2 .... 1646
2.3.5.7 Cross-transport key derivation ................... 1654
2.3.6 Repeated attempts .................................................... 1654
2.4 Security in Bluetooth Low Energy ............................................. 1655

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 3, Part H Page 1619
Security Manager Specification

2.4.1 Definition of keys and values ..................................... 1655

2.4.2 Generation of distributed keys ................................... 1656
2.4.2.1 Generation of IRK ...................................... 1656
2.4.2.2 Generation of CSRK .................................. 1656
2.4.2.3 LE legacy pairing - generation of LTK,
EDIV and Rand .......................................... 1657
2.4.2.4 Derivation of BR/EDR link key from LE
LTK ............................................................. 1657
2.4.2.5 Derivation of LE LTK from BR/EDR link
key .............................................................. 1658
2.4.3 Distribution of keys .................................................... 1658
2.4.3.1 LE legacy pairing key distribution .............. 1658
2.4.3.2 LE Secure Connections key distribution .... 1659
2.4.4 Encrypted session setup ........................................... 1659
2.4.4.1 Encryption setup using STK ....................... 1660
2.4.4.2 Encryption setup using LTK ....................... 1660
2.4.5 Signing algorithm ....................................................... 1661
2.4.6 Peripheral Security Request ...................................... 1662

3 Security Manager Protocol .................................................................... 1665

3.1 Introduction ............................................................................... 1665
3.2 Security Manager Channel over L2CAP ................................... 1665
3.3 Command format ....................................................................... 1665
3.4 SMP timeout .............................................................................. 1666
3.5 Pairing methods ........................................................................ 1667
3.5.1 Pairing Request ......................................................... 1667
3.5.2 Pairing Response ...................................................... 1670
3.5.3 Pairing Confirm .......................................................... 1672
3.5.4 Pairing Random ......................................................... 1673
3.5.5 Pairing Failed ............................................................. 1674
3.5.6 Pairing Public Key ...................................................... 1676
3.5.7 Pairing DHKey Check ................................................ 1676
3.5.8 Keypress Notification ................................................. 1677
3.6 Security in Bluetooth Low Energy ............................................. 1678
3.6.1 Key distribution and generation ................................. 1678
3.6.2 Encryption Information ............................................... 1681
3.6.3 Central Identification .................................................. 1682
3.6.4 Identity Information .................................................... 1682
3.6.5 Identity Address Information ...................................... 1683
3.6.6 Signing Information .................................................... 1684
3.6.7 Security Request ....................................................... 1684

4 References .............................................................................................. 1686

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 3, Part H Page 1620
Security Manager Specification

Appendix A EDIV and Rand Generation ........................................................... 1687

A.1 EDIV masking ............................................................................ 1687
A.1.1 DIV mask generation function dm ............................. 1687
A.1.2 EDIV generation ........................................................ 1688
A.1.3 DIV recovery .............................................................. 1688

Appendix B Key Management ........................................................................... 1689

B.1 Database lookup ....................................................................... 1689
B.2 Key hierarchy ............................................................................ 1689
B.2.1 Diversifying function d1 ............................................. 1690
B.2.2 Generating keys from ER .......................................... 1691
B.2.3 Generating keys from IR ............................................ 1692

Appendix C Message sequence charts ............................................................ 1693

C.1 Phase 1: Pairing feature exchange ........................................... 1694
C.1.1 Peripheral security request – Central requests
pairing ........................................................................ 1694
C.2 Phase 2: Authenticating and encrypting .................................... 1694
C.2.1 LE legacy pairing ....................................................... 1695
C.2.1.1 Legacy Phase 2: Short Term Key
generation – Just Works ............................ 1695
C.2.1.2 Legacy Phase 2: Short Term Key
generation – Passkey Entry ....................... 1696
C.2.1.3 Legacy Phase 2: Short Term Key
generation – Out of Band ........................... 1697
C.2.2 LE Secure Connections ............................................. 1697
C.2.2.1 Public key exchange .................................. 1698
C.2.2.2 Authentication stage 1 ............................... 1698
C.2.2.3 Long Term Key calculation ......................... 1709
C.2.2.4 Authentication stage 2 (DHKey checks) .... 1709
C.3 Phase 3: Transport specific key distribution .............................. 1711
C.4 Security re-established using previously distributed LTK .......... 1711
C.4.1 Central initiated security - Central initiated Link
Layer encryption ........................................................ 1711
C.4.2 Peripheral security request - Central initiated
Link Layer encryption ................................................ 1712
C.5 Failure conditions ...................................................................... 1712
C.5.1 Pairing not supported by Peripheral .......................... 1712
C.5.2 Central rejects pairing because of key size ............... 1713
C.5.3 Peripheral rejects pairing because of key size .......... 1713
C.5.4 Passkey Entry failure on Central ............................... 1714
C.5.5 Passkey Entry failure on Peripheral .......................... 1715
C.5.6 Peripheral rejects Central’s confirm value ................. 1715

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 3, Part H Page 1621
Security Manager Specification

C.5.7 Central rejects Peripheral’s confirm value ................. 1716

Appendix D Sample data ................................................................................... 1718

D.1 AES-CMAC RFC4493 test vectors ............................................ 1718
D.1.1 Example 1: Len = 0 .................................................... 1718
D.1.2 Example 2: Len = 16 .................................................. 1718
D.1.3 Example 3: Len = 40 .................................................. 1718
D.1.4 Example 4: Len = 64 .................................................. 1718
D.2 f4 LE SC confirm value generation function .............................. 1718
D.3 f5 LE SC key generation function .............................................. 1719
D.4 f6 LE SC check value generation function ................................ 1719
D.5 g2 LE SC numeric comparison generation function .................. 1720
D.6 h6 LE SC link key conversion function ...................................... 1720
D.7 ah random address hash functions ........................................... 1720
D.8 h7 LE SC link key conversion function ...................................... 1720
D.9 LTK to link key conversion using CT2=1 ................................... 1720
D.10 LTK to link key conversion using CT2=0 ................................... 1720
D.11 Link key to LTK conversion using CT2=1 .................................. 1721
D.12 Link key to LTK conversion using CT2=0 .................................. 1721

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 3, Part H Page 1622
Security Manager Specification

1 INTRODUCTION

1.1 Scope
The Security Manager defines methods of pairing and key distribution, a protocol for
those methods and a security toolbox to be used by those methods and other parts of
an LE-only or BR/EDR/LE device.

GAP

SM ATT

L2CAP

Figure 1.1: Relationship of the Security Manager to the rest of the LE Bluetooth architecture

The document describes Central and Peripheral roles in terms of protocol and
requirements; these have the same meaning and are mapped to the LE device roles
described in [Vol 1] Part A, Section 1.2 or BR/EDR device roles (see [Vol 1] Part A,
Section 1.1).

1.2 Conventions
1.2.1 Bit and byte ordering conventions

When multiple bit fields are contained in a single octet and represented in a drawing
in this Part, the least significant (low-order) bits are shown toward the left and most
significant (high-order) bits toward the right.

Multiple-octet fields are drawn with the least significant octets toward the left and the
most significant octets toward the right. Multiple-octet fields shall be transmitted with the
least significant octet first.

Multiple-octet values written in hexadecimal notation have the most significant octet
towards the left and the least significant octet towards the right, for example if ‘12’ is the
most significant octet and ‘34’ is the least significant octet it would be written as 0x1234.

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 3, Part H Page 1623
Security Manager Specification

1.2.2 Random numbers

In [Vol 3] Part H, the term "random number" includes pseudo-random numbers.

Random number generators should conform to the requirements of [Vol 2] Part H,
Section 2.

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 3, Part H Page 1624
Security Manager Specification

2 SECURITY MANAGER

2.1 Introduction
The Security Manager (SM) uses a key distribution approach to perform identity
and encryption functionalities in radio communication. This means that each device
generates and controls the keys it distributes and no other device affects the generation
of these keys. The strength of a key is as strong as the algorithms implemented inside
the distributing device.

The security architecture is designed such that memory and processing requirements
for a responding device are lower than the memory and processing requirement for an
initiating device.

Pairing is performed to establish keys which can then be used to encrypt a link. A
transport-specific key distribution is then performed to share the keys, which can be
used to encrypt a link in future reconnections, to verify signed data, and to resolve
private addresses.

Pairing is a three-phase process. The first two phases are always used and may be
followed by an optional transport specific key distribution phase (see Figure 2.1):

• Phase 1: Pairing Feature Exchange

• Phase 2 (LE legacy pairing): Short Term Key (STK) Generation
• Phase 2 (LE Secure Connections): Long Term Key (LTK) Generation
• Phase 3: Transport Specific Key Distribution

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 3, Part H Page 1625
Security Manager Specification

Initiator Responder

Phase 1: Established LL connection

(Optional) Security_Request

Pairing_Request

Pairing_Response

Phase 2: Pairing over SMP

Legacy pairing or Secure Connections

Phase 3: Establishment of encrypted connection with key generated in

phase 2

Key Distribution

Key Distribution

Key Distribution

Figure 2.1: LE pairing phases

The devices shall first exchange authentication requirements and IO capabilities in the
Pairing Feature Exchange to determine which of the following methods shall be used in
Phase 2:

• Just Works
• Numeric Comparison (Only for LE Secure Connections)
• Passkey Entry
• Out Of Band (OOB)

Authentication requirements retrieved from the Pairing Feature Exchange also

determine whether LE Secure Connections or LE legacy pairing is used.

Optionally, Phase 3 may then be performed to distribute transport specific keys, for
example the Identity Resolving Key (IRK) value and Identity Address information. Phase
1 and Phase 3 are identical regardless of the method used in Phase 2.

Phase 3 shall only be performed on a link which is encrypted using:

• The STK generated in Phase 2 when using LE legacy pairing or

• The LTK generated in Phase 2 when using LE Secure Connections or
• The shared Link Key generated using BR/EDR pairing (see Section 2.3.5.7).

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 3, Part H Page 1626
Security Manager Specification

Phase 1 and Phase 2 may be performed on a link which is either encrypted or not
encrypted.

2.2 Cryptographic toolbox

In order to support random addressing, pairing and other operations SM provides a
toolbox of cryptographic functions. The following cryptographic functions are defined:

• ah is used to create a 24-bit hash used in random address creation and resolution.

The following cryptographic functions are defined to support the LE legacy pairing
process:

• c1 is used to generate confirm values used during the pairing process.

• s1 is used to generate the STK during the pairing process.

The following cryptographic functions are defined to support the LE Secure Connections
pairing process:

• f4 is used to generate confirm values during the pairing process.

• f5 is used to generate the LTK and the MacKey during the pairing process.
• f6 is used to generate the check values during authentication stage 2 in the pairing
process.
• g2 is used to generate the 6-digit numeric comparison values during authentication
stage 1 in the pairing process.
• h6 is used to generate the LE LTK from a BR/EDR link key derived from Secure
Connections and is used to generate the BR/EDR link key from an LE LTK derived
from Secure Connections.
• h7 is used to generate intermediate keys while generating the LE LTK from a BR/EDR
link key derived from Secure Connections and the BR/EDR link key from an LE LTK
derived from Secure Connections.

The building block for the cryptographic functions ah, c1 and s1 is the security function
e.

The building block for the cryptographic functions f4, f5, f6, g2, h6, and h7 is the security
function AES-CMAC.

Inside the f4, f5, f6, g2, h6, and h7 functions when a multi-octet integer parameter is
used as input to AES-CMAC the most significant octet of the integer shall be the first
octet of the stream and the least significant octet of the integer shall be the last octet
of the stream. The output of AES-CMAC inside these functions is a multi-octet integer
where the first octet is MSB and the last octet is LSB of this integer.

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 3, Part H Page 1627
Security Manager Specification

2.2.1 Security function e

Security function e generates 128-bit encryptedData from a 128-bit key and 128-bit
plaintextData using the AES-128-bit block cypher as defined in FIPS-1971:

encryptedData = e(key, plaintextData)

The most significant octet of key corresponds to key[0], the most significant octet
of plaintextData corresponds to in[0] and the most significant octet of encryptedData
corresponds to out[0] using the notation specified in FIPS-1971.

Note: The security function e can be implemented in a Host or be implemented using

the HCI_LE_Encrypt command (see [Vol 4] Part E, Section 7.8.22).

2.2.2 Random address hash function ah

The random address hash function ah is used to generate a hash value that is used in
resolvable private addresses, see [Vol 3] Part C, Section 10.8.2.

The following are inputs to the random address hash function ah:

k is 128 bits
r is 24 bits
padding is 104 bits

r is concatenated with padding to generate r' which is used as the 128-bit input
parameter plaintextData to security function e:

r’ = padding || r

The least significant octet of r becomes the least significant octet of r’ and the most
significant octet of padding becomes the most significant octet of r’.

For example, if the 24-bit value r is 0x423456 then r’ is

0x00000000000000000000000000423456.

The output of the random address function ah is:

ah(k, r) = e(k, r’) mod 224

The output of the security function e is then truncated to 24 bits by taking the least
significant 24 bits of the output of e as the result of ah.

1NIST Publication FIPS-197 (http://csrc.nist.gov/publications/fips/fips197/fips-197.pdf)

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 3, Part H Page 1628
Security Manager Specification

2.2.3 Confirm value generation function c1 for LE legacy pairing

During the LE legacy pairing process confirm values are exchanged. This confirm value
generation function c1 is used to generate the confirm values.

The following are inputs to the confirm value generation function c1:

k is 128 bits
r is 128 bits
pres is 56 bits
preq is 56 bits
iat is 1 bit
ia is 48 bits
rat is 1 bit
ra is 48 bits
padding is 32 zero bits

iat is concatenated with 7 zero bits to create iat’ which is 8 bits in length. iat is the least
significant bit of iat’.

rat is concatenated with 7 zero bits to create rat’ which is 8 bits in length. rat is the least
significant bit of rat’.

pres, preq, rat’ and iat’ are concatenated to generate p1 which is XORed with r and
used as 128-bit input parameter plaintextData to security function e:

p1 = pres || preq || rat’ || iat’

The octet of iat’ becomes the least significant octet of p1 and the most significant octet
of pres becomes the most significant octet of p1.

For example, if the 8-bit iat’ is 0x01, the 8-bit rat’ is 0x00, the 56-bit preq
is 0x07071000000101 and the 56 bit pres is 0x05000800000302 then p1 is
0x05000800000302070710000001010001.

ra is concatenated with ia and padding to generate p2 which is XORed with the result of
the security function e using p1 as the input parameter plaintextData and is then used
as the 128-bit input parameter plaintextData to security function e:

p2 = padding || ia || ra

The least significant octet of ra becomes the least significant octet of p2 and the most
significant octet of padding becomes the most significant octet of p2.

For example, if 48-bit ia is 0xA1A2A3A4A5A6 and the 48-bit ra is 0xB1B2B3B4B5B6

then p2 is 0x00000000A1A2A3A4A5A6B1B2B3B4B5B6.

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 3, Part H Page 1629
Security Manager Specification

The output of the confirm value generation function c1 is:

c1 (k, r, preq, pres, iat, rat, ia, ra) = e(k, e(k, r ⊕ p1) ⊕ p2)

The 128-bit output of the security function e is used as the result of confirm value
generation function c1.

For example, if the 128-bit k is 0x00000000000000000000000000000000, the

128-bit value r is 0x5783D52156AD6F0E6388274EC6702EE0, the 128-bit value
p1 is 0x05000800000302070710000001010001 and the 128-bit value p2 is
0x00000000A1A2A3A4A5A6B1B2B3B4B5B6 then the 128-bit output from the c1
function is 0x1E1E3FEF878988EAD2A74DC5BEF13B86.

2.2.4 Key generation function s1 for LE legacy pairing

The key generation function s1 is used to generate the STK during the LE legacy
pairing process.

The following are inputs to the key generation function s1:

k is 128 bits
r1 is 128 bits
r2 is 128 bits

The most significant 64-bits of r1 are discarded to generate r1’ and the most significant
64-bits of r2 are discarded to generate r2’.

For example if the 128-bit value r1 is 0x000F0E0D0C0B0A091122334455667788

then r1’ is 0x1122334455667788. If the 128-bit value r2 is
0x010203040506070899AABBCCDDEEFF00 then r2’ is 0x99AABBCCDDEEFF00.

r1’ is concatenated with r2’ to generate r’ which is used as the 128-bit input parameter
plaintextData to security function e:

r’ = r1’ || r2’

The least significant octet of r2’ becomes the least significant octet of r’ and the most
significant octet of r1’ becomes the most significant octet of r’.

For example, if the 64-bit value r1’ is 0x1122334455667788 and r2’ is

0x99AABBCCDDEEFF00 then r’ is 0x112233445566778899AABBCCDDEEFF00.

The output of the key generation function s1 is:

s1(k, r1, r2) = e(k, r’)

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 3, Part H Page 1630
Security Manager Specification

The 128-bit output of the security function e is used as the result of key generation
function s1.

For example if the 128-bit value k is

0x00000000000000000000000000000000

and the 128-bit value r' is

0x112233445566778899AABBCCDDEEFF00

then the output from the key generation function s1 is

0x9a1fe1f0e8b0f49b5b4216ae796da062.

2.2.5 Function AES-CMAC

RFC-44931 defines the Cipher-based Message Authentication Code (CMAC) that uses
AES-128 as the block cipher function, also known as AES-CMAC.

The inputs to AES-CMAC are:

m is the variable length data to be authenticated

k is the 128-bit key

The 128-bit message authentication code (MAC) is generated as follows:2

MAC = AES-CMACk(m)

A device can implement AES functions in the Host or can use the HCI_LE_Encrypt
command (see [Vol 4] Part E, Section 7.8.22) in order to use the AES function in the
Controller.

2.2.6 LE Secure Connections confirm value generation function f4

During the LE Secure Connections pairing process, confirm values are exchanged.
These confirm values are computed using the confirm value generation function f4.

This confirm value generation function makes use of the MAC function AES-CMACX,
with a 128-bit key X.

The inputs to function f4 are:

U is 256 bits
V is 256 bits

1http://www.ietf.org/rfc/rfc4493.txt
2RFC4493 uses the notation MAC = AES-CMAC(k,m) where k is the key. This is functionally the same as the
notation used in this specification MAC = AES-CMACk(m)

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 3, Part H Page 1631
Security Manager Specification

X is 128 bits
Z is 8 bits

Z is zero (i.e. 8 bits of zeros) for Numeric Comparison and OOB protocol. In the
Passkey Entry protocol, the most significant bit of Z is set equal to one and the least
significant bit is made up from one bit of the passkey e.g. if the passkey bit is 1, then Z =
0x81 and if the passkey bit is 0, then Z = 0x80.

U, V and Z are concatenated and used as input m to the function AES-CMAC and X is
used as the key k.

The inputs to f4 are different depending on different association models:

Numeric Comparison/ Out-Of-Band Passkey Entry

Just Works
Ca = f4(PKax, PKbx, Na, 0) Ca = f4(PKax, PKax, ra, 0) Cai = f4(PKax, PKbx, Nai, rai)
Cb = f4(PKbx, PKax, Nb, 0) Cb = f4(PKbx, PKbx, rb, 0) Cbi = f4(PKbx, PKax, Nbi, rbi)

Table 2.1: Inputs to f4 for the different protocols

PKax denotes the x-coordinate of the public key PKa of A.

Similarly, PKbx denotes the x-coordinate of the public key PKb of B.

Nai is the nonce value of ith round. For each round Nai value is a new 128-bit number.
Similarly, rai is a one bit value of the passkey expanded to 8 bits (either 0x80 or 0x81).

Na and Nb are nonces from Devices A and B. ra and rb are random values generated
by devices A and B.

The output of the confirm value generation function f4 is as follows:

f4(U, V, X, Z) = AES-CMACX (U || V || Z)

The least significant octet of Z becomes the least significant octet of the AES-CMAC
input message m and the most significant octet of U becomes the most significant octet
of the AES-CMAC input message m.

2.2.7 LE Secure Connections key generation function f5

The LE Secure Connections key generation function f5 is used to generate derived

keying material in order to create the LTK and keys for the commitment function f6
during the LE Secure Connections pairing process.

The definition of this key generation function makes use of the MAC function AES-
CMACT with a 128-bit key T.

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 3, Part H Page 1632
Security Manager Specification

The inputs to function f5 are:

W is 256 bits
N1 is 128 bits
N2 is 128 bits
A1 is 56 bits
A2 is 56 bits

The key (T) is computed as follows:

T = AES-CMACSALT (W)

SALT is the 128-bit value:

0x6C888391_AAF5A538_60370BDB_5A6083BE

Counter, keyID, N1, N2, A1, A2, and Length are concatenated and used as input m to
the function AES-CMAC and T is used as the key k.

Counter is one octet. Length is two octets.

The string “btle” is mapped into a keyID using ASCII as 0x62746C65.

The output of the key generation function f5 is as follows:

f5(W, N1, N2, A1, A2) = AES-CMACT (Counter = 0 || keyID || N1 || N2

|| A1 || A2 || Length = 256) || AES-CMACT (Counter = 1 || keyID || N1
|| N2 || A1 || A2 || Length = 256)

The least significant octet of Length becomes the least significant octet of the AES-
CMAC input message m and the most significant octet of Counter becomes the most
significant octet of the AES-CMAC input message m.

The LTK and MacKey are calculated as:

MacKey || LTK = f5(DHKey, Nc, Np, BD_ADDR_C, BD_ADDR_P)

DHKey is the shared secret Diffie-Hellman key generated during LE Secure

Connections pairing phase 2.

Nc is whichever of N1 and N2 was generated by the Central and sent to the Peripheral;
Np is the other.

BD_ADDR_C is the device address of the Central and BD_ADDR_P is the device
address of the Peripheral. The device addresses are the values used during connection
setup. The least significant bit in the most significant octet in both BD_ADDR_C and

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 3, Part H Page 1633
Security Manager Specification

BD_ADDR_P is set to 1 if the address is a random address and set to 0 if the address
is a public address. The 7 most significant bits of the most significant octet in both
BD_ADDR_C and BD_ADDR_P are set to 0.

The LTK is the least significant 128 bits (Counter = 1) of f5. The MacKey (see
Section 2.2.8) is the most significant 128 bits (Counter = 0) of f5.

A device can implement Diffie-Hellman key generation in the Host or can use the
HCI_LE_Generate_DHKey command (see [Vol 4] Part E, Section 7.8.37) to generate
the key in the Controller.

Note: When using the HCI_LE_Generate_DHKey command, the device can only pair
one remote device at a time.

2.2.8 LE Secure Connections check value generation function f6

The LE Secure Connections check value generation function f6 is used to generate

check values during authentication stage 2 of the LE Secure Connections pairing
process.

The definition of the f6 function makes use of the MAC function AES-CMACW with a
128-bit key W.

The inputs to function f6 are:

W is 128 bits
N1 is 128 bits
N2 is 128 bits
R is 128 bits
IOcap is 24 bits
A1 is 56 bits
A2 is 56 bits

N1, N2, R, IOcap, A1 and A2 are concatenated and used as input m to the function
AES-CMAC and W is used as the key k.

The inputs to f6 are different depending on different association models:

Numeric Comparison/ Out-Of-Band Passkey Entry

Just Works
Ea = f6(MacKey, Na, Nb, 0, IOcapA, Ea = f6(MacKey, Na, Nb, rb, Ea = f6(MacKey, Na20, Nb20,
A, B) IOcapA, A, B) rb, IOcapA, A, B)
Eb = f6(MacKey, Nb, Na, 0, IOcapB, Eb = f6(MacKey, Nb, Na, ra, Eb = f6(MacKey, Nb20, Na20,
B, A) IOcapB, B, A) ra, IOcapB, B, A)

Table 2.2: Inputs to f6 for the different protocols

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 3, Part H Page 1634
Security Manager Specification

MacKey is the 128-bit MSBs of the output of f5.

Na is the random number sent by the Central to the Peripheral and Nb is the random
number sent by the Peripheral to the Central.

IOcapA is the capabilities of the Central and IOcapB is the capabilities of the Peripheral.
IOcapA and IOcapB are both three octets with the most significant octet as the AuthReq
parameter, the middle octet as the OOB data flag and the least significant octet as the
IO capability parameter. The AuthReq, OOB data flag and IO capability parameters are
present in the Pairing Request and Pairing Response SMP packets.

In Passkey Entry, ra and rb are 6-digit passkey values expressed as a 128-bit integer.
For instance, if the 6-digit value of ra is 131313 then

ra = 0x 00 00 00 00 00 00 00 00 00 00 00 00 00 02 00 f1

A is the device address of the Central and B is the device address of the Peripheral.
The least significant bit in the most significant octet in both A and B is set to 1 if the
address is a random address and set to 0 if the address is a public address. The 7 most
significant bits of the most significant octet in both A and B are set to 0.

The output of the check value generation function f6 is as follows:

f6(W, N1, N2, R, IOcap, A1, A2) =

AES-CMACW (N1 || N2 || R || IOcap || A1 || A2)

The least significant octet of A2 becomes the least significant octet of the AES-CMAC
input message m and the most significant octet of N1 becomes the most significant
octet of the AES-CMAC input message m.

2.2.9 LE Secure Connections numeric comparison value generation function g2

The LE Secure Connections numeric comparison value generation function g2 is used

to generate the numeric comparison values during authentication stage 1 of the LE
Secure Connections pairing process.

The definition of g2 makes use of the MAC function AES-CMACX with 128-bit key X.

The inputs to function g2 are:

U is 256 bits
V is 256 bits
X is 128 bits
Y is 128 bits

U, V, and Y are concatenated and used as input m to the function AES-CMAC and X is
used as the key k.

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 3, Part H Page 1635
Security Manager Specification

The output of the numeric comparison value generation function g2 is as follows:

g2(U, V, X, Y) = AES-CMACX(U || V || Y) mod 232

The least significant octet of Y becomes the least significant octet of the AES-CMAC
input message m and the most significant octet of U becomes the most significant octet
of the AES-CMAC input message m.

The numeric verification value is taken as the six least significant digits of the 32-bit
integer g2(PKax, PKbx, Na, Nb) where PKax denotes the x-coordinate of the public key
PKa of A and PKbx denotes the x-coordinate of the public key PKb of B. Na and Nb are
nonces from devices A and B. The value is then converted to decimal numeric value.
The checksum used for numeric comparison is the least significant six digits.

Compare Value = g2 (U, V, X, Y) mod 106

For example, if output = 0x 01 2e b7 2a then decimal value = 19838762 and the

checksum used for numeric comparison is 838762.

2.2.10 Link key conversion function h6

The function h6 is used to convert keys of a given size from one key type to another key
type with equivalent strength.

The definition of the h6 function makes use of the hashing function AES-CMACW with
128-bit key W.

The inputs to function h6 are:

W is 128 bits
keyID is 32 bits

keyID is used as input m to the hashing function AES-CMAC and the most significant
128-bits of W are used as the key k (2.2.5).

The output of h6 is as follows:

h6(W, keyID) = AES-CMACW(keyID)

2.2.11 Link key conversion function h7

The function h7 is used to convert keys of a given size from one key type to another key
type with equivalent strength.

The definition of the h7 function makes use of the hashing function AES-CMACSALT with
128-bit key SALT.

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 3, Part H Page 1636
Security Manager Specification

The inputs to function h7 are:

SALT is 128 bits

W is 128 bits

W is used as input m to the hashing function AES-CMAC and SALT is used as the key k
(2.2.5).

The output of h7 is as follows:

h7(SALT, W) = AES-CMACSALT(W)

2.3 Pairing methods

When pairing is started, the Pairing Feature Exchange shall be initiated by the
initiating device. If the responding device does not support pairing or pairing cannot be
performed then the responding device shall respond using the Pairing Failed message
with the error code “Pairing Not Supported” otherwise it responds with a Pairing
Response message.

The Pairing Feature Exchange is used to exchange IO capabilities, OOB authentication

data availability, authentication requirements, key size requirements and which transport
specific keys to distribute. The IO capabilities, OOB authentication data availability and
authentication requirements are used to determine the key generation method used in
Phase 2.

All of the LE legacy pairing methods use and generate 2 keys:

1. Temporary Key (TK): a 128-bit temporary key used in the pairing process which is
used to generate STK (see Section 2.3.5.5).
2. Short Term Key (STK): a 128-bit temporary key used to encrypt a connection
following pairing.

The LE Secure Connections pairing methods use and generate 1 key:

1. Long Term Key (LTK): a 128-bit key used to encrypt the connection following
pairing and subsequent connections.

Authentication requirements are set by GAP, (see [Vol 3] Part C, Section 10.3).
The authentication requirements include the type of bonding and man-in-the-middle
protection (MITM) requirements.

The initiating device indicates to the responding device which transport specific keys it
would like to send to the responding device and which keys it would like the responding
device to send to the initiator. The responding device replies with the keys that the

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 3, Part H Page 1637
Security Manager Specification

initiating device shall send and the keys that the responding device shall send. The keys
that can be distributed are defined in Section 2.4.3. If the device receives a command
with invalid parameters, it shall respond with Pairing Failed command with the error
code “Invalid Parameters.”

2.3.1 Security Properties

Security Properties provided by SM are classified into the following categories:

• LE Secure Connections pairing

• Authenticated MITM protection
• Unauthenticated no MITM protection
• No security requirements

LE Secure Connections pairing utilizes the P-256 elliptic curve (see [Vol 2] Part H,
Section 7.6).

In LE legacy pairing, Authenticated man-in-the-middle (MITM) protection is obtained

by using the passkey entry pairing method or may be obtained using the out of band
pairing method. In LE Secure Connections pairing, Authenticated man-in-the-middle
(MITM) protection is obtained by using the passkey entry pairing method or the numeric
comparison method or may be obtained using the out of band pairing method. To
ensure that Authenticated MITM Protection is generated, the selected Authentication
Requirements option must have MITM protection specified.

Unauthenticated no MITM Protection does not have protection against MITM attacks.

For LE Legacy Pairing, none of the pairing methods provide protection against a
passive eavesdropper during the pairing process as predictable or easily established
values for TK are used. If the pairing information is distributed without an eavesdropper
being present then all the pairing methods provide confidentiality.

An initiating device shall maintain a record of the Security Properties for the distributed
keys in a security database.

A responding device may maintain a record of the distributed key sizes and Security
Properties for the distributed keys in a security database. Depending upon the key
generation method and negotiated key size a responding device may have to shorten
the key length (see Section 2.3.4) so that the initiator and responder are using identical
keys.

Security Properties of the key generated in phase 2 under which the keys are
distributed shall be stored in the security database.

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 3, Part H Page 1638
Security Manager Specification

2.3.2 IO capabilities

Input and output capabilities of a device are combined to generate its IO capabilities.
The input capabilities are described in Table 2.3. The output capabilities are described
in Table 2.4.

Capability Description
No input Device does not have the ability to indicate ‘yes’ or ‘no’
Yes / No Device has at least two buttons that can be easily mapped to 'yes' and 'no' or the device
has a mechanism whereby the user can indicate either 'yes' or 'no' (see note below).
Keyboard Device has a numeric keyboard that can input the numbers '0' to '9' and a confirmation.
Device also has at least two buttons that can be easily mapped to 'yes' and 'no' or the
device has a mechanism whereby the user can indicate either 'yes' or 'no' (see note
below).
Table 2.3: User input capabilities

Note: 'yes' could be indicated by pressing a button within a certain time limit otherwise
'no' would be assumed.

Capability Description
No output Device does not have the ability to display or communicate a 6 digit decimal number
Numeric output Device has the ability to display or communicate a 6 digit decimal number
Table 2.4: User output capabilities

The individual input and output capabilities are mapped to a single IO capability for
that device which is used in the pairing feature exchange. The mapping is described in
Table 2.5.

Local output capacity

No output Numeric output
No input NoInputNoOutput DisplayOnly
Local input
capacity

Yes/No NoInputNoOutput1 DisplayYesNo

Keyboard KeyboardOnly KeyboardDisplay

Table 2.5: IO capabilities mapping

1None of the pairing algorithms can use Yes/No input and no output, therefore NoInputNoOutput is used as
the resulting IO capability.

2.3.3 OOB authentication data

An out of band mechanism may be used to communicate information which is used

during the pairing process. The information shall be a sequence of AD structures (see
[Vol 3] Part C, Section 11).

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 3, Part H Page 1639
Security Manager Specification

The OOB data flag shall be set if a device has the peer device's out of band
authentication data. A device uses the peer device's out of band authentication data
to authenticate the peer device. In LE legacy pairing, the out of band method is used if
both the devices have the other device's out of band authentication data available. In LE
Secure Connections pairing, the out of band method is used if at least one device has
the peer device's out of band authentication data available.

2.3.4 Encryption key size

Each device shall have maximum and minimum encryption key length parameters
which defines the maximum and minimum size of the encryption key allowed in octets.
The maximum and minimum encryption key length parameters shall be between 7
octets (56 bits) and 16 octets (128 bits), in 1 octet (8 bit) steps. This is defined by a
profile or device application.

The shorter of the initiating and responding devices’ maximum encryption key length
parameters shall be used as the encryption key size.

Both the initiating and responding devices shall check that the resultant encryption key
size is not shorter than the minimum key size parameter for that device and if it is, the
device shall send the Pairing Failed command with error code “Encryption Key Size”.

The encryption key size may be stored so it can be checked by any service that has
minimum encryption key length requirements.

If a key has an encryption key size that is shorter than 16 octets (128 bits), it shall be
created by masking the appropriate number of most significant octets of the generated
key to provide a resulting key that has the agreed encryption key size. The key shall
be masked after generation and, if required, after the key is used to derive a BR/EDR
link key. The key shall be masked before the key is distributed, used for encryption, or
stored.

For example, if a 128-bit encryption key is

0x12345678_9ABCDEF0_12345678_9ABCDEF0

and it is reduced to 7 octets (56 bits), then the resulting key is

0x00000000_00000000_00345678_9ABCDEF0.

2.3.5 Pairing algorithms

The information exchanged in Phase 1 is used to select which key generation method is
used in Phase 2.

When LE legacy pairing is used, the pairing is performed by each device generating
a Temporary Key (TK). The method to generate TK depends upon the pairing method

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 3, Part H Page 1640
Security Manager Specification

chosen using the algorithm described in Section 2.3.5.1. If Just Works is used then
TK shall be generated as defined in Section 2.3.5.2. If Passkey Entry is used then
TK shall be generated as defined in Section 2.3.5.3. If Out Of Band is used then TK
shall be generated as defined in Section 2.3.5.4. The TK value shall be used in the
authentication mechanism defined in Section 2.3.5.5 to generate the STK and encrypt
the link.

2.3.5.1 Selecting key generation method

If both devices have not set the MITM option in the Authentication Requirements Flags,
then the IO capabilities shall be ignored and the Just Works association model shall be
used.

In LE legacy pairing, if both devices have Out of Band authentication data, then the
Authentication Requirements Flags shall be ignored when selecting the pairing method
and the Out of Band pairing method shall be used. Otherwise, the IO capabilities of the
device shall be used to determine the pairing method as defined in Table 2.8.

In LE Secure Connections pairing, if one or both devices have out of band

authentication data, then the Authentication Requirements Flags shall be ignored when
selecting the pairing method and the Out of Band pairing method shall be used.
Otherwise, the IO capabilities of the device shall be used to determine the pairing
method as defined in Table 2.8.

Table 2.6 defines the STK generation method when at least one of the devices does not
support LE Secure Connections.

Initiator
OOB Set OOB Not Set
MITM Set MITM Not MITM Set MITM Not Set
Set
OOB Set MITM Set Use OOB Use OOB Use IO Capabili- Use IO Capabil-
ties ities
MITM Not Use OOB Use OOB Use IO Capabili- Use Just Works
Responder

Set ties
OOB Not MITM Set Use IO Capa- Use IO Capa- Use IO Capabili- Use IO Capabil-
Set bilities bilities ties ities
MITM Not Use IO Capa- Use Just Use IO Capabili- Use Just Works
Set bilities Works ties

Table 2.6: Rules for using Out-of-Band and MITM flags for LE legacy pairing

Table 2.7 defines the LTK generation method when both devices support LE Secure
Connections.

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 3, Part H Page 1641
Security Manager Specification

Initiator
OOB Set OOB Not Set
MITM Set MITM Not MITM Set MITM Not Set
Set
OOB Set MITM Set Use OOB Use OOB Use OOB Use OOB
MITM Not Use OOB Use OOB Use OOB Use OOB
Responder

Set
OOB Not MITM Set Use OOB Use OOB Use IO Capabili- Use IO Capabili-
Set ties ties
MITM Not Use OOB Use OOB Use IO Capabili- Use Just Works
Set ties

Table 2.7: Rules for using Out-of-Band and MITM flags for LE Secure Connections pairing

Initiator
Responder DisplayOnly Keyboard Keyboard
Display Only NoInput Display
YesNo NoOutput

Display On- Just Works Just Works Passkey Entry: Just Works Passkey Entry:
ly responder dis- responder dis-
Unauthenticated Unauthen- Unauthen-
plays, initiator plays, initiator
ticated ticated
inputs inputs
Authenticated Authenticated
Display Just Works Just Works Passkey Entry: Just Works Passkey Entry
YesNo (For LE Lega- responder dis- (For LE Legacy
Unauthenticated Unauthen-
cy Pairing) plays, initiator Pairing): res-
ticated
inputs ponder dis-
Unauthen-
plays, initiator
ticated Authenticated
inputs
Authenticated
Numeric Com- Numeric Com-
parison (For parison (For LE
LE Secure Secure Con-
Connections) nections)
Authenticated Authenticated
Keyboard Passkey Entry: Passkey Entry: Passkey Entry: Just Works Passkey Entry:
Only initiator dis- initiator dis- initiator and initiator dis-
Unauthen-
plays, respond- plays, res- responder in- plays, respond-
ticated
er inputs ponder inputs put er inputs
Authenticated Authenticated Authenticated Authenticated

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 3, Part H Page 1642
Security Manager Specification

Initiator
Responder DisplayOnly Keyboard Keyboard
Display Only NoInput Display
YesNo NoOutput

NoInput Just Works Just Works Just Works Just Works Just Works
NoOutput Unauthenticated Unauthen- Unauthen- Unauthen- Unauthen-
ticated ticated ticated ticated
Keyboard Passkey Entry: Passkey Entry Passkey Entry: Just Works Passkey Entry
Display initiator dis- (For LE Lega- responder dis- (For LE Legacy
Unauthen-
plays, respond- cy Pairing): plays, initiator Pairing):
ticated
er inputs inputs
initiator dis- initiator dis-
Authenticated plays, res- Authenticated plays, respond-
ponder inputs er inputs
Authenticated Authenticated
Numeric Com- Numeric Com-
parison (For parison (For LE
LE Secure Secure Con-
Connections) nections)
Authenticated Authenticated

Table 2.8: Mapping of IO capabilities to key generation method

The generated key will either be an Authenticated or Unauthenticated key. If the out
of band authentication method is used and the Out of Band mechanism is known to
be secure from eavesdropping the key is assumed to be Authenticated; however, the
exact strength depends upon the method used to transfer the out of band information.
If the Out of Band method is used and the Out of Band mechanism is not secure from
eavesdropping or the level of eavesdropping protection is unknown, the key shall be
Unauthenticated. The mapping of IO capabilities to an authenticated or unauthenticated
key is described in Table 2.8.

In LE legacy pairing, if the initiating device has Out of Band data and the responding
device does not have Out of Band data then the responding device may send the
Pairing Failed command with the error code “OOB Not Available” instead of the Pairing
Response command.

If the key generation method does not result in a key that provides sufficient Security
Properties (see Section 2.3.1) then the device shall send the Pairing Failed command
with the error code “Authentication Requirements”.

2.3.5.2 LE legacy pairing - Just Works

The Just Works STK generation method provides no protection against eavesdroppers
or man in the middle attacks during the pairing process. If the attacker is not present

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 3, Part H Page 1643
Security Manager Specification

during the pairing process then confidentiality can be established by using encryption on
a future connection.

Both devices set the TK value used in the authentication mechanism defined in
Section 2.3.5.5 to zero.
2.3.5.3 LE legacy pairing - Passkey Entry

The Passkey Entry STK generation method uses 6 numeric digits passed out of band
by the user between the devices. A 6 digit numeric randomly generated passkey
achieves approximately 20 bits of entropy.

If the IO capabilities of a device are DisplayOnly or if Table 2.8 defines that the device
displays the passkey, then that device shall display a randomly generated passkey
value between 000,000 and 999,999. The display shall ensure that all 6 digits are
displayed – including zeros. The other device shall allow the user to input a value
between 000,000 and 999,999.

If the IO capabilities of both devices are KeyboardOnly then the user generates a
random 6-digit passkey value and enters it into both devices. Both devices shall allow
the user to input a value between 000,000 and 999,999.

The passkey should be generated randomly during each pairing procedure and not be
reused from a previous procedure. Static passkeys should not be used since they can
compromise the security of the link.

If entry of passkey in UI fails to occur or is cancelled then the device shall send Pairing
Failed command with reason code “Passkey Entry Failed”.

For example, if the user entered passkey is ‘019655’ then TK shall be

0x00000000000000000000000000004CC7.

The passkey Entry method does not provide protection against active “man-in-the-
middle” (MITM) attacks.

The Passkey Entry STK generation method provides very limited protection against
eavesdroppers during the pairing process because of the limited range of possible TK
values which STK is dependent upon. If the attacker is not present during the pairing
process then confidentiality and authentication can be established by using encryption
on a future connection.

The TK value shall then be used in the authentication mechanism defined in

Section 2.3.5.5.
2.3.5.4 Out of band

An out of band mechanism may be used to communicate information to help with device
discovery, for example device address, and the 128-bit TK value used in the pairing

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 3, Part H Page 1644
Security Manager Specification

process. The TK value shall be a 128-bit random number using the requirements for
random generation defined in [Vol 2] Part H, Section 2.

If the OOB communication is resistant to MITM attacks, then this association method
is also resistant to MITM attacks. Also, in the Out of Band method, the size of
authentication parameter (TK) need not be restricted by what the user can comfortably
read or type. For that reason, the Out of Band method can be more secure than
using the Passkey Entry or Just Works methods. However, both devices need to have
matching OOB interfaces.

MITM protection is only provided if an active man-in-the-middle chance of a successful

attack has a probability of 0.000001 or less in succeeding.

2.3.5.5 LE legacy pairing phase 2

The initiating device generates a 128-bit random number (LP_RAND_I).

The initiating device calculates the 128-bit confirm value (LP_CONFIRM_I) using the
confirm value generation function c1 (see Section 2.2.3) with the input parameter k set
to TK, the input parameter r set to LP_RAND_I, the input parameter preq set to Pairing
Request command as exchanged with the peer device (i.e. without any modifications),
the input parameter pres set to the Pairing Response command as exchanged with the
peer device (i.e. without any modifications), the input parameter iat set to the initiating
device address type, ia set to the initiating device address, rat set to the responding
device address type and ra set to the responding device address:

LP_CONFIRM_I = c1(TK, LP_RAND_I,

Pairing Request command, Pairing Response command,
initiating device address type, initiating device address,
responding device address type, responding device address)

Initiating and responding device addresses used for confirmation generation shall be
device addresses used during connection setup, see [Vol 3] Part C, Section 9.3

The responding device generates a 128-bit random number (LP_RAND_R).

The responding device calculates the 128-bit confirm value (LP_CONFIRM_R) using
the confirm value generation function c1 (see Section 2.2.3) with the input parameter
k set to TK, the input parameter r set to LP_RAND_R, the input parameter preq set
to Pairing Request command, the input parameter pres set to the Pairing Response
command, the input parameter iat set to the initiating device address type, ia set to the
initiating device address, rat set to the responding device address type and ra set to the
responding device address:

LP_CONFIRM_R = c1(TK, LP_RAND_R,

Pairing Request command, Pairing Response command,

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 3, Part H Page 1645
Security Manager Specification

initiating device address type, initiating device address,

responding device address type, responding device address)

The initiating device transmits LP_CONFIRM_I to the responding device. When the
responding device receives LP_CONFIRM_I it transmits LP_CONFIRM_R to the
initiating device. When the initiating device receives LP_CONFIRM_R it transmits
LP_RAND_I to the responding device.

The responding device verifies the LP_CONFIRM_I value by repeating the calculation
the initiating device performed, using the LP_RAND_I value received.

If the responding device’s calculated LP_CONFIRM_I value does not match the
received LP_CONFIRM_I value from the initiating device then the pairing process shall
be aborted and the responding device shall send the Pairing Failed command with
reason code “Confirm Value Failed”.

If the responding device’s calculated LP_CONFIRM_I value matches the received

LP_CONFIRM_I value from the initiating device the responding device transmits
LP_RAND_R to the initiating device.

The initiating device verifies the received LP_CONFIRM_R value by repeating the
calculation the responding device performed, using the LP_RAND_R value received.

If the initiating devices calculated LP_CONFIRM_R value does not match the received
LP_CONFIRM_R value from the responding device then the pairing process shall be
aborted and the initiating device shall send the Pairing Failed command with the reason
code “Confirm Value Failed”.

If the initiating device’s calculated LP_CONFIRM_R value matches the received

LP_CONFIRM_R value from the responding device the initiating device then calculates
STK and tells the Controller to enable encryption.

STK is generated using the key generation function s1 defined in Section 2.2.4 with the
input parameter k set to TK, the input parameter r1 set to LP_RAND_R, and the input
parameter r2 set to LP_RAND_I:

STK = s1(TK, LP_RAND_R, LP_RAND_I)

If the encryption key size is shorter than 128 bits then the STK shall be masked to the
correct key size as described in Section 2.3.4.

The initiator shall use the generated STK to either enable encryption on the link or if
encryption has already been enabled, perform the encryption pause procedure (see
Section 2.4.4.1).

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 3, Part H Page 1646
Security Manager Specification

2.3.5.6 LE Secure Connections pairing phase 2

The Long Term Key is generated in LE Secure Connections pairing phase 2.

2.3.5.6.1 Public key exchange

Initially, each device generates its own Elliptic Curve Diffie-Hellman (ECDH) public-
private key pair (phase 1). The public-private key pair contains a private (secret) key,
and a public key. The private keys of devices A and B are denoted as SKa and
SKb respectively. The public keys of devices A and B are denoted as PKa and PKb
respectively. See Section 2.3.6 for recommendations on how frequently this key pair
should be changed.

Pairing is initiated by the initiating device sending its public key to the receiving device
(phase 1a). The responding device replies with its own public key (phase 1b). If the two
public keys have the same X coordinate and neither is the debug key, each device shall
fail the pairing process. These public keys are not regarded as secret although they
may identify the devices.

Initiating Non-initiating
Device A Device B

Public Key Exchange

1a. PKa

1b. PKb

Start computing DHKey Start computing DHKey

DHKey = P256(SKa,PKb) DHKey = P256(SKb,PKa)

Figure 2.2: Public key exchange

A device shall validate that any public key received from any BD_ADDR is on the
correct curve (P-256).

A valid public key Q = (XQ, YQ) is one where XQ and YQ are both in the range 0 to p -
1 and satisfy the equation (YQ)2 = (XQ)3 + aXQ + b (mod p) in the relevant curve's finite
field. See [Vol 2] Part H, Section 7.6 for the values of a, b, and p.

A device can validate a public key by directly checking the curve equation, by
implementing elliptic curve point addition and doubling using formulas that are valid
only on the correct curve, or by other means.

A device that detects an invalid public key from the peer at any point during the LE
Secure Connections pairing process shall not use the resulting LTK, if any.

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 3, Part H Page 1647
Security Manager Specification

After the public keys have been exchanged, the device can then start computing the
Diffie-Hellman Key.

When the Security Manager is placed in a Debug mode it shall use the following
Diffie-Hellman private / public key pair:

Private key: 3f49f6d4 a3c55f38 74c9b3e3 d2103f50 4aff607b eb40b799 5899b8a6 cd3c1abd
Public key (X): 20b003d2 f297be2c 5e2c83a7 e9f9a5b9 eff49111 acf4fddb cc030148 0e359de6
Public key (Y): dc809c49 652aeb6d 63329abf 5a52155c 766345c2 8fed3024 741c8ed0 1589d28b

If a device receives this debug public key and it is in a mode in which it cannot accept
the debug key then it may send the Pairing Failed command with the reason set to
"Invalid Parameters".

Note: Only one side (initiator or responder) needs to set Secure Connections debug
mode in order for debug equipment to be able to determine the LTK and, therefore, be
able to monitor the encrypted connection.

2.3.5.6.2 Authentication stage 1 – Just Works or Numeric Comparison

The Numeric Comparison association model will be used during pairing if the MITM
bit is set to 1 in the Authentication Requirements in the Pairing Request PDU
and/or Pairing Response PDU and both devices have IO capabilities set to either
DisplayYesNo or KeyboardDisplay.

The sequence diagram of Authentication stage 1 for the Just Works or Numeric
Comparison protocol from the cryptographic point of view is shown in Figure 2.3.

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 3, Part H Page 1648
Security Manager Specification

Initiating Non­initiating
Device A Device B

Authentication stage 1: Just Works

2a. Select Random Na 2b. Select Random Nb

3a. Set ra and rb to 0 3b. Set rb and ra to 0

3c. Compute confirmation:

Cb=f4(PKb,PKa,Nb,0)

4. Cb

5. Na

6. Nb

6a. Check if Cb=f4(PKb,PKa,Nb,0)

If check fails, abort

Va and Vb are 6 digit

numbers to be displayed
on each side, if possible.

7a. Va=g2(PKa,PKb,Na,Nb) 7b. Vb=g2(PKa,PKb,Na,Nb)

USER checks if Va = Vb
Proceed if each USER confirms ”OK”

Proceed if user Proceed if user

confirms ”OK” confirms ”OK”

Figure 2.3: "Authentication stage 1: Just Works or Numeric Comparison, LE Secure Connections

After the public keys have been exchanged, each device selects a random 128-bit
nonce (step 2). This value is used to mitigate replay attacks and shall be freshly
generated with each instantiation of the pairing protocol. This value shall be generated
using a random number generator that meets the requirements of [Vol 2] Part H,
Section 2.

Following this the responding device then computes a commitment to the two public
keys that have been exchanged and its own nonce value (step 3c). This commitment
is computed as a one-way function of these values and is transmitted to the initiating
device (step 4). The commitment prevents an attacker from changing these values at a
later time.

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 3, Part H Page 1649
Security Manager Specification

The initiating and responding devices then exchange their respective nonce values
(steps 5 and 6) and the initiating device confirms the commitment (step 6a). A failure at
this point indicates the presence of an attacker or other transmission error and causes
the protocol to abort. The protocol may be repeated with or without the generation
of new public-private key pairs, but new nonces shall be generated if the protocol is
repeated.

When Just Works is used, the commitment checks (steps 7a and 7b) are not performed
and the user is not shown the 6-digit values.

When Numeric Comparison is used, assuming that the commitment check succeeds,
the two devices each compute 6-digit confirmation values that are displayed to the user
on their respective devices (steps 7a, 7b, and 8). The user is expected to check that
these 6-digit values match and to confirm if there is a match. If there is no match, the
protocol aborts and, as before, new nonces shall be generated if the protocol is to be
repeated.

An active MITM must inject its own key material into this process to have any effect
other than denial-of-service. A simple MITM attack will result in the two 6-digit display
values being different with probability 0.999999. A more sophisticated attack may
attempt to engineer the display values to match, but this is thwarted by the commitment
sequence. If the attacker first exchanges nonces with the responding device, it must
commit to the nonce that it will use with the initiating device before it sees the nonce
from the initiating device. If the attacker first exchanges nonces with the initiating
device, it must send a nonce to the responding device before seeing the nonce from
the responding device. In each case, the attacker must commit to at least the second
of its nonces before knowing the second nonce from the legitimate devices. It therefore
cannot choose its own nonces in such a way as to cause the display values to match.

2.3.5.6.3 Authentication stage 1 – Passkey Entry

The Passkey Entry protocol is used when SMP IO capability exchange sequence
indicates that Passkey Entry shall be used.

The sequence diagram for Authentication stage 1 for Passkey Entry from the
cryptographic point of view is shown in Figure 2.4.

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 3, Part H Page 1650
Security Manager Specification

Initiating Non­initiating
Device A Device B

Authentication stage 1: Passkey Entry

2a. Inject secret ra, 2b. Inject secret rb,

set rb = ra set ra = rb

Execute 20 times:
ra = ra1 | ra2 | … ra20
rb = rb1 | rb2 | … rb20
New random numbers are
selected in each round

3a. Select random Nai 3b. Select random Nbi

4a. Compute confirm: 4b. Compute confirm:

Cai=f4(PKa, PKb, Nai, rai) Cbi=f4(PKb, PKa, Nbi, rbi)

5. Cai

6. Cbi

7. Nai

7a. Check if
Cai=f4(PKa, PKb, Nai, rbi).
If check fails, abort.

8. Nbi

8a. Check if
Cbi=f4(PKb, PKa, Nbi, rai).
If check fails, abort.

Figure 2.4: Authentication stage 1: Passkey Entry, LE Secure Connections

The user inputs an identical Passkey into both devices. Alternately, the Passkey may be
generated and displayed on one device, and the user then inputs it into the other (step
2). This short shared key will be the basis of the mutual authentication of the devices.
The Passkey should be generated randomly during each pairing procedure and not be
reused from a previous procedure. Static Passkeys should not be used since they can
compromise the security of the link.

Steps 3 to 8 are repeated 20 times since a 6-digit Passkey is 20 bits

(999999=0xF423F). If the device allows a shorter passkey to be entered, it shall be
prefixed with zeros (e.g. “1234” is equivalent to “001234”).

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 3, Part H Page 1651
Security Manager Specification

In Steps 3 to 8, each side commits to each bit of the Passkey, using a long nonce (128
bits), and sending the hash of the nonce, the bit of the Passkey, and both public keys to
the other party. The parties then take turns revealing their commitments until the entire
Passkey has been mutually disclosed. The first party to reveal a commitment for a given
bit of the Passkey effectively reveals that bit of the Passkey in the process, but the other
party then has to reveal the corresponding commitment to show the same bit value for
that bit of the Passkey, or else the first party will then abort the protocol, after which no
more bits of the Passkey are revealed.

This "gradual disclosure" prevents leakage of more than 1 bit of un-guessed Passkey
information in the case of a MITM attack. A MITM attacker with only partial knowledge
of the Passkey will only receive one incorrectly-guessed bit of the Passkey before the
protocol fails. Hence, a MITM attacker who engages first one side, then the other will
only gain an advantage of at most two bits over a simple brute-force guesser, making
the probability of success 0.000004 instead of 0.000001.

The long nonce is included in the commitment hash to make it difficult to brute force
even after the protocol has failed. The public Diffie-Hellman values are included to tie
the Passkey protocol to the original ECDH key exchange, to prevent a MITM from
substituting the attacker's public key on both sides of the ECDH exchange in standard
MITM fashion.

At the end of this stage, Na is set to Na20 and Nb is set to Nb20 for use in
Authentication stage 2.

2.3.5.6.4 Authentication stage 1 – Out of Band

The Out-of-Band protocol is used when authentication information has been received
by at least one of the devices and indicated in the OOB data flag parameter included
in the SMP Pairing Request and SMP Pairing Response PDU. The mode in which the
discovery of the peer device is first done in-band and then followed by the transmission
of authentication parameters through OOB interface is not supported. The sequence
diagram for Authentication stage 1 for Out of Band from the cryptographic point of view
is shown in Figure 2.5.

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 3, Part H Page 1652
Security Manager Specification

Initiating Non-initiating
Device A Device B

Authentication stage 1: Out of Band

2a. Set ra=rand, rb=0 2b. Set rb=rand, ra=0

3a. Compute confirm: 3b. Compute confirm:

Ca=f4(PKa,PKa,ra,0) Cb=f4(PKb,PKb,rb,0)
and send 4a. and send 4b.

OOB Communication
A = Device Address used during pairing
B = Device Address used during pairing

4a. A, ra, Ca

4b. B, rb, Cb

Security Manager Pairing begins

5a. If 4b received reset rb 5b. If 4a received reset ra

to the received value, and to the received value, and
if Cb≠f4(PKb,PKb,rb,0) if Ca≠f4(PKa,PKa,ra,0)
abort. If 4b received and abort. If 4a received and
Device B’s IO data flag Device A’s IO data flag
does not indicate OOB does not indicate OOB
authentication data authentication data
present, set ra=0 present, set rb=0

6a. Select random Na 6b. Select random Nb

7. Na

8. Nb

Figure 2.5: Authentication stage 1: Out of Band, LE Secure Connections

Principle of operation. If both devices can transmit and/or receive data over an
out-of-band channel, then mutual authentication will be based on the commitments
of the public keys (Ca and Cb) exchanged OOB in Authentication stage 1. If OOB
communication is possible only in one direction, then authentication of the device
receiving the OOB communication will be based on that device knowing a random
number r sent via OOB. In this case, r must be secret: r can be created afresh every
time, or access to the device sending r must be restricted. If r is not sent by a device, it
is assumed to be 0 by the device receiving the OOB information in step 4a or 4b.

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 3, Part H Page 1653
Security Manager Specification

Roles of A and B. The OOB Authentication stage 1 protocol is symmetric with respect
to the roles of A and B. It does not require that device A always will initiate pairing and it
automatically resolves asymmetry in the OOB communication.

Order of steps. The public key exchange must happen before the verification step 5.
In the diagram the in-band public key exchange between the devices (step 1) is done
before the OOB communication (step 4). But when the pairing is initiated by an OOB
interface, public key exchange will happen after the OOB communication (step 1 will be
between steps 4 and 5).

Values of ra and rb: Since the direction of the peer's OOB interface cannot be verified
before the OOB communication takes place, a device should always generate and if
possible transmit through its OOB interface a random number r to the peer. Each device
applies the following rules locally to set the values of its own r and the value of the
peer's r:

1. Initially, r of the device is set to a random number and r of the peer is set to 0 (step
2).
2. If a device has received OOB, it sets the peer's r value to what was sent by the
peer (Step 5).
3. If the remote device's OOB data flag sent in the SMP Pairing Request or SMP
Pairing Response is set to “OOB Authentication data not present”, it sets its own r
value to 0 (Step 5)

2.3.5.6.5 Authentication stage 2 and long term key calculation

The second stage of authentication then confirms that both devices have successfully
completed the exchange. This stage is identical in all three protocols and is shown in
Figure 2.6.

Each device computes the MacKey and the LTK using the previously exchanged values
and the newly derived shared key (step 9). Each device then computes a new key
confirmation value that includes the previously exchanged values and the newly derived
MacKey (step 10a and 10b). The initiating device then transmits its key confirmation
value, which is checked by the responding device (step 11). If this check fails, it
indicates that the initiating device has not confirmed the pairing, and the protocol shall
be aborted. The responding device then transmits its key confirmation value, which is
checked by the initiating device (step 12). A failure indicates that the responding device
has not confirmed the pairing and the protocol shall abort.

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 3, Part H Page 1654
Security Manager Specification

Initiating Non­initiating
Device A Device B

Authentication stage 2: LTK Calculation

IOcapA is from Pairing Request command

IOcapB is from Pairing Response command
A = Device Address of A used during pairing
B = Device Address of B used during pairing

9. Compute the LTK and MacKey: 9. Compute the LTK and MacKey:
MacKey || LTK = f5(DHKey,Na,Nb,A,B) MacKey || LTK = f5(DHKey,Na,Nb,A,B)

10a. Compute: EA = 10b. Compute: EB =

f6(MacKey,Na,Nb,rb,IOcapA,A,B) f6(MacKey,Nb,Na,ra,IOcapB,B,A)

10. Ea

11. Check if Ea =
f6(MacKey,Na,Nb,rb,IOcapA,A,B)
If check fails, abort.

12. Eb

12a. Check if Eb =
f6(MacKey,Nb,Na,ra,IOcapB,B,A)
If check fails, abort.

Figure 2.6: Authentication stage 2 and long term key calculation

2.3.5.7 Cross-transport key derivation

When a pair of BR/EDR/LE devices support Secure Connections on a transport, the

devices may optionally generate a key of identical strength for the other transport. There
are two sequences:

• If Secure Connections pairing occurs on the LE transport, the procedures in

Section 2.4.2.4 may be used.
• If Secure Connections pairing occurs on the BR/EDR transport, the procedures in
Section 2.4.2.5 may be used.

2.3.6 Repeated attempts

When a pairing procedure fails a waiting interval shall pass before the verifier will
initiate a new Pairing Request command or Security Request command to the same
claimant, or before it will respond to a Pairing Request command or Security Request
command initiated by a device claiming the same identity as the failed device. For

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 3, Part H Page 1655
Security Manager Specification

each subsequent failure, the waiting interval shall be increased exponentially. That is,
after each failure, the waiting interval before a new attempt can be made, could be for
example, twice as long as the waiting interval prior to the previous attempt1. The waiting
interval should be limited to a maximum.

The maximum waiting interval depends on the implementation. The waiting time shall
exponentially decrease to a minimum when no new failed attempts are made during a
certain time period. This procedure restricts the rate at which an intruder can repeat the
pairing procedure with different keys.

To protect a device's private key, a device should implement a method to prevent

an attacker from retrieving useful information about the device's private key. For this
purpose, a device should change its private key after every pairing (successful or
failed). Otherwise, it should change its private key whenever S + 3F > 8, where S is the
number of successful pairings and F the number of failed attempts since the key was
last changed.

2.4 Security in Bluetooth Low Energy

Security shall be initiated by the Security Manager in the device in the Central role.
The device in the Peripheral role shall be the responding device. The Peripheral may
request the Central to initiate pairing or other security procedures, see Section 2.4.6.

The Peripheral in the key distribution phase gives keys to the Central so a reconnection
can be encrypted, its random addresses can be resolved, or the Central can verify
signed data from the Peripheral.

The Central may also provide keys to the Peripheral so a reconnection can be
encrypted if the roles are reversed, the Central’s random addresses can be resolved, or
the Peripheral can verify signed data from the Central.

2.4.1 Definition of keys and values

LE security uses the following keys and values for encryption, signing, and random
addressing:

1. Identity Resolving Key (IRK) is a 128-bit key used to generate and resolve random
addresses.
2. Connection Signature Resolving Key (CSRK) is a 128-bit key used to sign data and
verify signatures on the receiving device.
3. Long Term Key (LTK) is a 128-bit key used to generate the contributory session key
for an encrypted connection. Link Layer encryption is described in [Vol 6] Part B,
Section 5.1.3.

1Another appropriate integer value larger than 1 may be used.

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 3, Part H Page 1656
Security Manager Specification

4. Encrypted Diversifier (EDIV) is a 16-bit stored value used to identify the LTK
distributed during LE legacy pairing. A new EDIV is generated each time a unique
LTK is distributed.
5. Random Number (Rand) is a 64-bit stored valued used to identify the LTK
distributed during LE legacy pairing. A new Rand is generated each time a unique
LTK is distributed.

2.4.2 Generation of distributed keys

Any method of generation of keys that are being distributed that results in the keys
having 128 bits of entropy can be used, as the generation method is not visible outside
the Peripheral (see Appendix B). The keys shall not be generated only from information
that is distributed to the Central or only from information that is visible outside of the
Peripheral.

2.4.2.1 Generation of IRK

The Identity Resolving Key (IRK) is used for resolvable private address construction
(see [Vol 3] Part C, Section 10.8.2). A Central that has received IRK from a Peripheral
can resolve that Peripheral’s random device addresses. A Peripheral that has received
IRK from a Central can resolve that Central’s random device addresses. The privacy
concept only protects against devices that are not part of the set to which the IRK has
been given.

IRK can be assigned, or randomly generated by the device during manufacturing, or

some other method could be used. If IRK is randomly generated then the requirements
for random generation defined in [Vol 2] Part H, Section 2 shall be used.

The encryption key size does not apply to IRK; therefore, its size does not need to be
shortened before distribution.

2.4.2.2 Generation of CSRK

The Connection Signature Resolving Key (CSRK) is used to sign data in a connection.
A device that has received CSRK can verify signatures generated by the distributing
device. The signature only protects against devices that are not part of the set to which
CSRK has been given.

CSRK can be assigned or randomly generated by the device during manufacturing,

or some other method could be used. If CSRK is randomly generated then the
requirements for random generation defined in [Vol 2] Part H, Section 2 shall be used.

The encryption key size does not apply to CSRK, therefore its size does not need to be
shortened before distribution.

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 3, Part H Page 1657
Security Manager Specification

2.4.2.3 LE legacy pairing - generation of LTK, EDIV and Rand

Devices which support encryption in the Link Layer Connection state in the Peripheral
Role shall be capable of generating LTK, EDIV, and Rand.

The EDIV and Rand are used by the Peripheral to establish a previously shared LTK in
order to start an encrypted connection with a previously paired Central.

The generated LTK size shall not be longer than the negotiated encryption key size, so
its size may need to be shortened (see Section 2.3.4).

New values of LTK, EDIV, and Rand shall be generated each time they are distributed.

The Peripheral may store the mapping between EDIV, Rand and LTK in a security
database so the correct LTK value is used when the Central requests encryption.
Depending upon the LTK generation method additional information may be stored, for
example the size of the distributed LTK.

The Central may also distribute EDIV, Rand, and LTK to the Peripheral which can be
used to encrypt a reconnection if the device roles are reversed in a future connection.

2.4.2.4 Derivation of BR/EDR link key from LE LTK

The LTK from the LE physical transport can be converted to the BR/EDR link key for the
BR/EDR transport as follows, using intermediate link key (ILK) as an intermediate value:

If at least one device sets CT2 = 0 then

1. ILK = h6(LTK, “tmp1”)

2. BR/EDR link key = h6(ILK, “lebr”)

If both devices set CT2 = 1 then

1. ILK = h7(SALT, LTK)

2. BR/EDR link key = h6(ILK, “lebr”)

The string “lebr” is mapped into a keyID using ASCII as 0x6C656272.

The string “tmp1” is mapped into a keyID using ASCII as 0x746D7031 and into a SALT
as 0x00000000_00000000_00000000_746D7031.

Note: If the LTK has an encryption key size that is shorter than 16 octets (128 bits), then
the BR/EDR link key is derived before the LTK gets masked.

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 3, Part H Page 1658
Security Manager Specification

2.4.2.5 Derivation of LE LTK from BR/EDR link key

The BR/EDR Link Key from the BR/EDR physical transport can be converted to the
LTK for the LE transport as follows, using intermediate long term key (ILTK) as an
intermediate value:

If at least one device sets CT2 = 0 then

1. ILTK = h6(Link Key, “tmp2”)

2. LTK = h6(ILTK, “brle”)

If both devices set CT2 = 1 then

1. ILTK = h7(SALT, Link Key)

2. LTK = h6(ILTK, “brle”)

The string “brle” is mapped into a keyID using ASCII as 0x62726C65.

The string “tmp2” is mapped into a keyID using ASCII as 0x746D7032 and into a SALT
as 0x00000000_00000000_00000000_746D7032.

2.4.3 Distribution of keys

Key distribution for LE Legacy Pairing and LE Secure Connections is described in the
following sections.

2.4.3.1 LE legacy pairing key distribution

The Peripheral may distribute to the Central the following keys:

• LTK, EDIV, and Rand

• IRK
• CSRK

The Central may distribute to the Peripheral the following keys:

• LTK, EDIV, and Rand

• IRK
• CSRK

The security properties of the distributed keys shall be set to the security properties of
the STK that was used to distribute them. For example if STK has Unauthenticated
no MITM Protection security properties then the distributed keys shall have
Unauthenticated no MITM Protection security properties.

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 3, Part H Page 1659
Security Manager Specification

The link shall be encrypted or re-encrypted using STK generated in Phase 2 (see
Section 2.4.4.1) before any keys are distributed.

Note: The distributed EDIV and Rand values are transmitted in clear text by the Central
to the Peripheral during encrypted session setup.

The BD_ADDR that is received in the Identity Address Information command shall only
be considered valid once a reconnection has occurred using the BD_ADDR and LTK
distributed during that pairing. Once this is successful the BD_ADDR and the distributed
keys shall be associated with that device in the security database.

A device may request encrypted session setup to use the LTK, EDIV, and Rand values
distributed by the Peripheral when the key distribution phase has completed; however,
this does not provide any additional security benefit. If an attacker has established the
distributed LTK value then performing encrypted session setup to use the distributed
values does not provide any protection against that attacker.

2.4.3.2 LE Secure Connections key distribution

The Central and Peripheral may distribute the following keys:

• IRK
• CSRK

The security properties of the distributed keys shall be set to the security properties of
the LTK that was used to distribute them. For example if LTK has Unauthenticated
no MITM Protection security properties then the distributed keys shall have
Unauthenticated no MITM Protection security properties.

The link shall be encrypted or re-encrypted using LTK generated in Phase 2 (see
Section 2.4.4.1) before any keys are distributed.

The BD_ADDR that is received in the Identity Address Information command shall only
be considered valid once a reconnection has occurred using the BD_ADDR and LTK
generated during that pairing. Once this is successful the BD_ADDR and the distributed
keys shall be associated with that device in the security database.

2.4.4 Encrypted session setup

During the encrypted session setup the Central sends a 16-bit Encrypted Diversifier
value, EDIV, and a 64-bit Random Number, Rand, distributed by the Peripheral during
pairing, to the Peripheral. The Central’s Host provides the Link Layer with the Long
Term Key to use when setting up the encrypted session. The Peripheral’s Host receives
the EDIV and Rand values and provides a Long Term Key to the Peripheral’s Link Layer
to use when setting up the encrypted link.

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 3, Part H Page 1660
Security Manager Specification

When both devices support LE Secure Connections, the EDIV and Rand are set to
zero.

2.4.4.1 Encryption setup using STK

To distribute LTK and other keys in pairing Phase 3 an encrypted session needs to be
established (see Section 2.3.5.5).

The encrypted session is setup using STK generated in Phase 2 (see Section
Section 2.3.5.5) as the Long Term Key provided to the Link Layer, (see [Vol 6] Part
B, Section 5.1.3.1) EDIV, and Rand values shall be set to zero.

If the link is already encrypted then the encryption pause procedure is performed using
STK generated in Phase 2 as the Long Term Key provided to the Link Layer (see [Vol 6]
Part B, Section 5.1.3.2). EDIV and Rand values shall be set to zero.

2.4.4.2 Encryption setup using LTK

The Central must have the security information (LTK, EDIV, and Rand) distributed by
the Peripheral in LE legacy pairing or the LTK generated in LE Secure Connections to
setup an encrypted session.

The Central initiates the encrypted session using the security information; see [Vol 6]
Part B, Section 5.1.3.1. If the link is already encrypted the encryption pause procedure
is performed using the security information; see [Vol 6] Part B, Section 5.1.3.2.

In LE legacy pairing, the EDIV and Rand values are used to establish LTK which is used
as the Long Term Key on the Peripheral. If LTK cannot be established from EDIV and
Rand values then the Peripheral shall reject the request to encrypt the link and may
optionally disconnect the link.

The LTK size shall not be longer than the negotiated encryption key size, so its size may
need to be shortened (see Section 2.3.4).

When the security information is stored, subsequent encryption setups may fail if the
remote device has deleted the security information. Table 2.9 defines what shall be
done depending on the type of the security properties and whether or not bonding was
performed when subsequent encryption setup fails.

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 3, Part H Page 1661
Security Manager Specification

Security Devices Action to take when enabling encryption fails

Properties Bonded
Unauthenticated, No Depends on security policy of the device:
no MITM protec-
• Option 1: Automatically initiate pairing.
tion
• Option 2: Notify user and ask if pairing is ok.

Option 1 is recommended.
Unauthenticated, Yes Notify user of security failure.
no MITM protec-
tion
Authenticated No Depends on security policy of the device:
MITM protection
• Option 1: Automatically initiate pairing.
• Option 2: Notify user and ask if pairing is ok.

Option 2 is recommended.
Authenticated Yes Notify user of security failure.
MITM protection

Table 2.9: Action after encryption setup failure

2.4.5 Signing algorithm

An LE device can send signed data without having to establish an encrypted session
with a peer device. Data shall be signed using CSRK. A device performing signature
verification must have received CSRK from the signing device. The sending device will
use its CSRK to sign the transmitted data.

The following are inputs to the signing algorithm:

m is variable length
k is 128 bits
SignCounter is 32 bits

Signing shall be performed using the algorithm defined in the NIST Special Publication
800-38B [1] using AES-128 as the block cipher. NIST SP 800-38B defines the message
authentication code (MAC) generation function:

MAC = CMAC(K, M, Tlen)

The bit length of the MAC (Tlen) shall be 64 bits. The key used for signature generation
(k) shall be set to CSRK.

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 3, Part H Page 1662
Security Manager Specification

The message to be signed (M) by the CMAC function is the concatenation of the
variable length message to be signed (m) and 4 octet string representing the 32-bit
counter value (SignCounter) least significant octet first.

M = m || SignCounter

For example, if data to be signed is the 7 octet sequence ‘3456789ABCDEF1’

and SignCounter is set to 67653874 (0x040850F2) then M is the octet sequence
‘3456789ABCDEF1F2500804’. Examples of CMAC generation using AES-128 as the
block cipher are included in NIST Special Publication 800-38B Appendix D.

The SignCounter shall be initialized to zero when CSRK is generated and incremented
for every message that is signed with a given CSRK.

Note: If a device generates 100,000 signed events a day, a 32-bit counter will wrap after
approximately 117 years.

The 64-bit result of the CMAC function is used as the result of the signing algorithm.

To verify a signature a device computes the MAC of a received message and

SignCounter and compares it with the received MAC. If the MAC does not match then
the signature verification has failed. If the MACs match then the signature verification
has succeeded.

The device performing verification should store the last verified SignCounter in the
security database and compare it with a received SignCounter to prevent replay attacks.
If the received SignCounter is greater than the stored value then the message has not
been seen by the local device before and the security database can be updated.

2.4.6 Peripheral Security Request

The Peripheral may request security by transmitting a Security Request command to

the Central. When a Central receives a Security Request command it may encrypt the
link, initiate the pairing procedure, or reject the request.

The Peripheral shall not send the Security Request command if the pairing procedure is
in progress, or if the encryption procedure is in progress.

The Security Request command includes the required security properties. A security
property of MITM protection required shall only be set if the Peripheral’s IO capabilities
would allow the Passkey Entry association model to be used or out of band
authentication data is available.

The Central shall ignore the Peripheral’s Security Request if the Central has sent a
Pairing Request without receiving a Pairing Response from the Peripheral or if the
Central has initiated encryption mode setup.

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 3, Part H Page 1663
Security Manager Specification

If pairing or encryption mode is not supported or cannot be initiated at the time when the
Peripheral’s Security Request command is received, then the Central shall respond with
a Pairing Failed command with the reason set to “Pairing Not Supported.”

After receiving a Security Request, the Central shall first check whether it has
the required security information to enable encryption; see Section 2.4.4.2. If this
information is missing or does not meet the security properties requested by the
Peripheral, then the Central shall initiate the pairing procedure. If the pairing procedure
is successful, the Central’s security database is updated with the keys and security
properties are distributed during the pairing procedure.

If the Central has the required security information to enable encryption and it meets
the security properties request by the Peripheral, it shall perform encryption setup using
LTK, see Section 2.4.4.2.

Figure 2.7 shows a summary of the actions and decisions that a Central shall take when
receiving a Security Request.

The Peripheral shall check that any Pairing Request command received from
the Central after sending a Security Request command contains Authentication
Requirements that meet the requested security properties.

If the Peripheral requests a security property that is not Just Works and receives an
encryption procedure request after sending a Security Request command then it shall
check that any existing Security Information is of sufficient security properties.

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 3, Part H Page 1664
Security Manager Specification

Peripheral
Security Request

Sent Pairing
Yes
Request?

No

No Have LTK

Yes

LTK >=
No Requested
Security Level

Yes

Already Encrypted No

Yes

Pair, Encrypt and

Encryption Key
replace keys if Encrypt Ignore Request
Refresh
successful

End

Figure 2.7: Central actions after receiving Security Request command

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 3, Part H Page 1665
Security Manager Specification

3 SECURITY MANAGER PROTOCOL

3.1 Introduction
The Security Manager Protocol (SMP) is used for pairing and transport specific key
distribution.

3.2 Security Manager Channel over L2CAP

All SMP commands are sent over the Security Manager Channel which is an L2CAP
fixed channel (see [Vol 3] Part A, Section 2.1). The configuration parameters for the
Security Manager Channel when LE Secure Connections is not supported shall be as
shown below in Table 3.1.

Parameter Value
MTU 23
Flush Timeout 0xFFFF (Infinite)
QoS Best Effort
Mode Basic Mode

Table 3.1: Security Manager Channel configuration parameters without LE Secure Connections

The configuration parameters for the Security Manager Channel when LE Secure
Connections is supported shall be as shown below in Table 3.2.

Parameter Value
MTU 65
Flush Timeout 0xFFFF (Infinite)
QoS Best Effort
Mode Basic Mode

Table 3.2: Security Manager Channel configuration parameters with LE Secure Connections

3.3 Command format

The general format for all SMP commands is shown in Figure 3.1.

LSB 1 octet 0 to 22 or 64 octets MSB

Code Data

Figure 3.1: SMP command format

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 3, Part H Page 1666
Security Manager Specification

The following are the fields shown:

• Code (1 octet)
The Code field is one octet long and identifies the type of command. Table 3.3 lists
the codes defined by this document. If a packet is received with a Code that is
reserved for future use it shall be ignored.
Code Description Logical Link Supported
0x01 Pairing Request LE-U, ACL-U
0x02 Pairing Response LE-U, ACL-U
0x03 Pairing Confirm LE-U
0x04 Pairing Random LE-U
0x05 Pairing Failed LE-U, ACL-U
0x06 Encryption Information LE-U
0x07 Central Identification LE-U
0x08 Identity Information LE-U, ACL-U
0x09 Identity Address Information LE-U, ACL-U
0x0A Signing Information LE-U, ACL-U
0x0B Security Request LE-U
0x0C Pairing Public Key LE-U
0x0D Pairing DHKey Check LE-U
0x0E Pairing Keypress Notification LE-U
All other values Reserved for future use

Table 3.3: SMP command codes

• Data (0 or more octets)

The Data field is variable in length. The Code field determines the format of the Data
field.

If a device does not support pairing then it shall respond with a Pairing Failed command
with the reason set to “Pairing Not Supported” (see Section 3.5.5) when any command
is received. If pairing is supported then all commands shall be supported.

3.4 SMP timeout

To protect the Security Manager protocol from stalling, a Security Manager Timer is
used. Upon transmission of the Security Request command or reception of the Security
Request command, the Security Manager Timer shall be reset and restarted. Upon
transmission of the Pairing Request command or reception of the Pairing Request
command, the Security Manager Timer shall be reset and started.

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 3, Part H Page 1667
Security Manager Specification

The Security Manager Timer shall be reset when an L2CAP SMP command is queued
for transmission. The Security Manager Timer should be reset upon reception of a
Keypress Notification (if the timer is not reset on receipt of a Keypress Notification, the
Security Manager can time out before the peer's Security Manager because there is no
response to a Keypress Notification).

When a Pairing process completes (whether successfully or not), the Security Manager
Timer shall be stopped.

If the Security Manager Timer reaches 30 seconds, the procedure shall be considered
to have failed, and the local higher layer shall be notified. No further SMP commands
shall be sent over the L2CAP Security Manager Channel. A new Pairing process shall
only be performed when a new physical link has been established.

3.5 Pairing methods

The SMP commands defined in this section are used to perform Pairing Feature
Exchange and key generation (see Section 2.1).

3.5.1 Pairing Request

The initiator starts the Pairing Feature Exchange by sending a Pairing Request
command to the responding device. The Pairing Request command is defined in
Figure 3.2.

The rules for handing a collision between a pairing procedure on the LE transport and a
pairing procedure on the BR/EDR transport are defined in [Vol 3] Part C, Section 14.2.

LSB octet 0 octet 1 octet 2 octet 3 MSB

IO OOB
Code=0x01 AuthReq
Capability data flag
Maximum Initiator Key Responder
Encryption Key
Key Size Distribution Distribution

Figure 3.2: Pairing Request packet

The following data fields are used:

• IO Capability (1 octet)
Table 3.4 defines the values which are used when exchanging IO capabilities (see
Section 2.3.2).

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 3, Part H Page 1668
Security Manager Specification

Value Description
0x00 DisplayOnly
0x01 DisplayYesNo
0x02 KeyboardOnly
0x03 NoInputNoOutput
0x04 KeyboardDisplay
0x05 to 0xFF Reserved for future use

Table 3.4: IO capability values

• OOB data flag (1 octet)

Table 3.5 defines the values which are used when indicating whether OOB
authentication data is available (see Section 2.3.3).

Value Description
0x00 OOB Authentication data not present
0x01 OOB Authentication data from remote device present
0x02 to 0xFF Reserved for future use

Table 3.5: OOB data present values

• AuthReq (1 octet)
The AuthReq field is a bit field that indicates the requested security properties (see
Section 2.3.1) for the STK and LTK and GAP bonding information (see [Vol 3] Part C,
Section 9.4).
Figure 3.3 defines the authentication requirements bit field.

LSB MSB

Bonding_Flags MITM SC Keypress CT2 RFU

(2 bits) (1 bit) (1 bit) (1 bit) (1 bit) (2 bits)

Figure 3.3: Authentication requirements flags

The Bonding_Flags field is a 2-bit field that indicates the type of bonding being
requested by the initiating device as defined in Table 3.6.

Bonding_Flags Bonding Type

b1b0
00 No Bonding
01 Bonding

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 3, Part H Page 1669
Security Manager Specification

Bonding_Flags Bonding Type

b1b0
10 Reserved for future use
11 Reserved for future use

Table 3.6: Bonding flags

The MITM field is a 1-bit flag that is set to one if the device is requesting MITM
protection, otherwise it shall be set to 0. A device sets the MITM flag to one to request
an Authenticated security property for the STK when using LE legacy pairing and the
LTK when using LE Secure Connections.

The SC field is a 1 bit flag. If LE Secure Connections pairing is supported by the device,
then the SC field shall be set to 1, otherwise it shall be set to 0. If both devices support
LE Secure Connections pairing, then LE Secure Connections pairing shall be used,
otherwise LE Legacy pairing shall be used.

The keypress field is a 1-bit flag that is used only in the Passkey Entry protocol and
shall be ignored in other protocols. When both sides set that field to one, Keypress
notifications shall be generated and sent using SMP Pairing Keypress Notification
PDUs.

The CT2 field is a 1-bit flag that shall be set to 1 upon transmission to indicate support
for the h7 function. See sections 2.4.2.4 and 2.4.2.5.

• Maximum Encryption Key Size (1 octet)

This value defines the maximum encryption key size in octets that the device can
support. The maximum key size shall be in the range 7 to 16 octets.
• Initiator Key Distribution / Generation (1 octet)
The Initiator Key Distribution / Generation field indicates which keys the initiator
is requesting to distribute / generate or use during the Transport Specific Key
Distribution phase (see Section 2.4.3). The Initiator Key Distribution / Generation field
format and usage is defined in Section 3.6.1.
• Responder Key Distribution / Generation (1 octet)
The Responder Key Distribution / Generation field indicates which keys the initiator
is requesting the responder to distribute / generate or use during the Transport
Specific Key Distribution phase (see Section 2.4.3). The Responder Key Distribution /
Generation field format and usage is defined in Section 3.6.1.

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 3, Part H Page 1670
Security Manager Specification

If Secure Connections pairing has been initiated over BR/EDR, the following fields of
the SM Pairing Request PDU are reserved for future use:

• the IO Capability field,

• the OOB data flag field, and
• all bits in the Auth Req field except the CT2 bit.

3.5.2 Pairing Response

This command is used by the responding device to complete the Pairing Feature
Exchange after it has received a Pairing Request command from the initiating device,
if the responding device allows pairing. The Pairing Response command is defined in
Figure 3.4.

The rules for handing a collision between a pairing procedure on the LE transport and a
pairing procedure on the BR/EDR transport are defined in [Vol 3] Part C, Section 14.2.

If a Pairing Request is received over the BR/EDR transport when either cross-transport
key derivation/generation is not supported or the BR/EDR transport is not encrypted
using a Link Key generated using P256, a Pairing Failed shall be sent with the error
code Cross-Transport Key Derivation/Generation Not Allowed (0x0E).

If a Pairing Request is received and the device is not ready to perform the pairing
procedure, a Pairing Failed may be sent with the error code Busy (0x10).

LSB octet 0 octet 1 octet 2 octet 3 MSB

IO OOB
Code=0x02 AuthReq
Capability data flag
Maximum Initiator Key Responder
Encryption Key
Key Size Distribution Distribution

Figure 3.4: Pairing Response packet

The following data fields are used:

• IO Capability (1 octet)
Table 3.4 defines the values which are used when exchanging IO capabilities (see
Section 2.3.2).
• OOB data flag (1 octet)
Table 3.5 defines the values which are used when indicating whether OOB
authentication data is available (see Section 2.3.3).

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 3, Part H Page 1671
Security Manager Specification

• AuthReq (1 octet)
The AuthReq field is a bit field that indicates the requested security properties (see
Section 2.3.1) for the STK or LTK and GAP bonding information (see [Vol 3] Part C,
Section 9.4).
Figure 3.3 defines the authentication requirements bit field.
The Bonding_Flags field is a 2-bit field that indicates the type of bonding being
requested by the responding device as defined in Table 3.6.
The MITM field is a 1-bit flag that is set to one if the device is requesting MITM
protection, otherwise it shall be set to 0. A device sets the MITM flag to one to request
an Authenticated security property for the STK when using LE legacy pairing and the
LTK when using LE Secure Connections.
The SC field is a 1 bit flag. If LE Secure Connections pairing is supported by the
device, then the SC field shall be set to 1, otherwise it shall be set to 0. If both
devices support LE Secure Connections pairing, then LE Secure Connections pairing
shall be used, otherwise LE Legacy pairing shall be used.
The keypress field is a 1-bit flag that is used only in the Passkey Entry protocol and
shall be ignored in other protocols. When both sides set that field to one, Keypress
notifications shall be generated and sent using SMP Pairing Keypress Notification
PDUs.
The CT2 field is a 1-bit flag that shall be set to 1 upon transmission to indicate
support for the h7 function. See Sections 2.4.2.4 and 2.4.2.5.
• Maximum Encryption Key Size (1 octet)
This value defines the maximum encryption key size in octets that the device can
support. The maximum key size shall be in the range 7 to 16 octets.
• Initiator Key Distribution (1 octet)
The Initiator Key Distribution field defines which keys the initiator shall distribute and
use during the Transport Specific Key Distribution phase (see Section 2.4.3). The
Initiator Key Distribution field format and usage are defined in Section 3.6.1.
• Responder Key Distribution (1 octet)
The Responder Key Distribution field defines which keys the responder shall
distribute and use during the Transport Specific Key Distribution phase (see
Section 2.4.3). The Responder Key Distribution field format and usage are defined
in Section 3.6.1.

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 3, Part H Page 1672
Security Manager Specification

If Secure Connections pairing has been initiated over BR/EDR, the following fields of
the SM Pairing Response PDU are reserved for future use:

• the IO Capability field,

• the OOB data flag field, and
• all bits in the Auth Req field except the CT2 bit.

3.5.3 Pairing Confirm

This is used following a successful Pairing Feature Exchange to start STK Generation
for LE legacy pairing and LTK Generation for LE Secure Connections pairing. The
Pairing Confirm command is defined in Figure 3.5.

This command is used by both devices to send the confirm value to the peer
device, see Section 2.3.5.5 for LE legacy pairing and Section 2.3.5.6 for LE Secure
Connections pairing.

The initiating device starts key generation by sending the Pairing Confirm command to
the responding device. If the initiating device wants to abort pairing it can transmit a
Pairing Failed command instead.

The responding device sends the Pairing Confirm command after it has received a
Pairing Confirm command from the initiating device.

LSB octet 0 octet 1 octet 2 octet 3 MSB

Code=0x03 Confirm Value

Confirm Value

Confirm Value

Confirm Value

Confirm
Value

Figure 3.5: Pairing Confirm packet

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 3, Part H Page 1673
Security Manager Specification

The following data field is used:

• Confirm value (16 octets)

In LE legacy pairing, the initiating device sends LP_CONFIRM_I and the responding
device sends LP_CONFIRM_R as defined in Section 2.3.5.5. In LE Secure
Connections, Ca and Cb are defined in Section 2.2.6.

3.5.4 Pairing Random

This command is used by the initiating and responding device to send the random
number used to calculate the Confirm value sent in the Pairing Confirm command. The
Pairing Random command is defined in Figure 3.6.

The initiating device sends a Pairing Random command after it has received a Pairing
Confirm command from the responding device.

In LE legacy pairing, the responding device shall send a Pairing Random command
after it has received a Pairing Random command from the initiating device if the Confirm
value calculated on the responding device matches the Confirm value received from the
initiating device. If the calculated Confirm value does not match then the responding
device shall respond with the Pairing Failed command.

In LE Secure Connections, the responding device shall send a Pairing Random

command after it has received a Pairing Random command from the initiating device. If
the calculated Confirm value does not match then the responding device shall respond
with the Pairing Failed command.

The initiating device shall encrypt the link using the generated key (STK in LE legacy
pairing or LTK in LE Secure Connections) if the Confirm value calculated on the
initiating device matches the Confirm value received from the responding device. The
successful encryption or re-encryption of the link is the signal to the responding device
that key generation has completed successfully. If the calculated Confirm value does not
match then the initiating device shall respond with the Pairing Failed command.

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 3, Part H Page 1674
Security Manager Specification

LSB octet 0 octet 1 octet 2 octet 3 MSB

Code=0x04 Random value

Random value

Random value

Random value

Random
value

Figure 3.6: Pairing Random packet

The following are the data fields:

• Random value (16 octets)

In LE legacy pairing, the initiating device sends LP_RAND_I and the responding
device sends LP_RAND_R as defined in Section 2.3.5.5. In LE Secure Connections,
the initiating device sends Na and the responding device sends Nb.

3.5.5 Pairing Failed

This is used when there has been a failure during pairing and reports that the pairing
procedure has been stopped and no further communication for the current pairing
procedure is to occur. The Pairing Failed command is defined in Figure 3.7.

Any subsequent pairing procedure shall restart from the Pairing Feature Exchange
phase.

This command may be sent at any time during the pairing process by either device in
response to a message from the remote device.

During LE Secure Connections pairing, this command shall be sent if the remote
device's public key is invalid (see Section 2.3.5.6.1). The Reason field shall be set
to "DHKey Check Failed".

LSB octet 0 octet 1 MSB

Code=0x05 Reason

Figure 3.7: Pairing Failed packet

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 3, Part H Page 1675
Security Manager Specification

The following data field is used:

• Reason (1 octets)

The Reason field indicates why the pairing failed. The reason codes are defined in
Table 3.7.

Value Name Description

0x01 Passkey Entry The user input of passkey failed, for example, the user cancelled the
Failed operation.
0x02 OOB Not Available The OOB data is not available.
0x03 Authentication Re- The pairing procedure cannot be performed as authentication re-
quirements quirements cannot be met due to IO capabilities of one or both
devices.
0x04 Confirm Value The confirm value does not match the calculated compare value.
Failed
0x05 Pairing Not Suppor- Pairing is not supported by the device.
ted
0x06 Encryption Key The resultant encryption key size is not long enough for the security
Size requirements of this device.
0x07 Command Not Sup- The SMP command received is not supported on this device.
ported
0x08 Unspecified Rea- Pairing failed due to an unspecified reason.
son
0x09 Repeated Attempts Pairing or authentication procedure is disallowed because too little
time has elapsed since last pairing request or security request.
0x0A Invalid Parameters The Invalid Parameters error code indicates that the command
length is invalid or that a parameter is outside of the specified range.
0x0B DHKey Check Indicates to the remote device that the DHKey Check value received
Failed doesn’t match the one calculated by the local device.
0x0C Numeric Compari- Indicates that the confirm values in the numeric comparison protocol
son Failed do not match.
0x0D BR/EDR pairing in Indicates that the pairing over the LE transport failed due to a Pair-
progress ing Request sent over the BR/EDR transport in progress.
0x0E Cross-transport Indicates that the BR/EDR Link Key generated on the BR/EDR
Key Deriva- transport cannot be used to derive and distribute keys for the LE
tion/Generation not transport or the LE LTK generated on the LE transport cannot be
allowed used to derive a key for the BR/EDR transport.
0x0F Key Rejected Indicates that the device chose not to accept a distributed key.

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 3, Part H Page 1676
Security Manager Specification

Value Name Description

0x10 Busy Indicates that the device is not ready to perform a pairing procedure.
All other Reserved for future use.
values

Table 3.7: Pairing Failed reason codes

3.5.6 Pairing Public Key

This message is used to transfer the device’s local public key (X and Y co-ordinates) to
the remote device. This message is used by both the initiator and responder. This PDU
is only used for Secure Connections. Its format is specified in Figure 3.8.

LSB Octet 0 Octet 1 Octet 2 Octet 3 MSB

Code = 0x0C Public Key X [0-2]
Public Key X [3-6]
Public Key X [7-10]
Public Key X [11-14]
Public Key X [15-18]
Public Key X [19-22]
Public Key X [23-26]
Public Key X [27-30]
Public Key X
Public Key Y [0-2]
[31]
Public Key Y [3-6]
Public Key Y [7-10]
Public Key Y [11-14]
Public Key Y [15-18]
Public Key Y [19-22]
Public Key Y [23-26]
Public Key Y [27-30]
Public Key Y
[31]

Figure 3.8: Pairing Public Key PDU

3.5.7 Pairing DHKey Check

This message is used to transmit the 128-bit DHKey Check values (Ea and Eb)
generated using f6. These are confirmation values generated using the DHKey. This
message is used by both initiator and responder. This PDU is only used for LE Secure
Connections. Its format is specified in Figure 3.9.

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 3, Part H Page 1677
Security Manager Specification

LSB Octet 0 Octet 1 Octet 2 Octet 3 MSB

Code = 0x0D DHKey Check (E) [0-2]
DHKey Check (E) [3-6]
DHKey Check (E) [7-10]
DHKey Check (E) [11-14]
DHKey check
(E) [15]

Figure 3.9: Pairing DHKey Check PDU

3.5.8 Keypress Notification

This message is used during the Passkey Entry protocol by a device with KeyboardOnly
IO capabilities to inform the remote device when keys have been entered or erased. Its
format is specified in Figure 3.10.

LSB Octet 0 Octet 1 MSB

Code = 0x0E Notification Type

Figure 3.10: Pairing Keypress Notification PDU

Notification Type can take one of the following values:

Value Parameter Description

0 Passkey entry started
1 Passkey digit entered
2 Passkey digit erased
3 Passkey cleared
4 Passkey entry completed
5 to 255 Reserved for future use

Table 3.8: Notification Type

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 3, Part H Page 1678
Security Manager Specification

3.6 Security in Bluetooth Low Energy

3.6.1 Key distribution and generation

Bluetooth Low Energy devices can distribute keys from the Peripheral to the Central
and from the Central to the Peripheral. When using LE legacy pairing, the following keys
may be distributed from the Peripheral to the Central:

• LTK using Encryption Information command

• EDIV and Rand using Central Identification command
• IRK using Identity Information command
• Public device or static random address using Identity Address Information command
• CSRK using Signing Information command

When using LE Secure Connections, the following keys may be distributed from the
Peripheral to the Central:

• IRK using Identity Information command

• Public device or static random address using Identity Address Information command
• CSRK using Signing Information command

When using LE legacy pairing, the Central may distribute to the Peripheral the following
key:

• LTK using Encryption Information command

• EDIV and Rand using Central Identification command
• IRK using Identity Information command
• Public device or static random address using Identity Address Information command
• CSRK using Signing Information command

When using LE Secure Connections, the Central may distribute to the Peripheral the
following key:

• IRK using Identity Information command

• Public device or static random address using Identity Address Information command
• CSRK using Signing Information command

The keys which are to be distributed in the Transport Specific Key Distribution phase
are indicated in the Key Distribution field of the Pairing Request and Pairing Response
commands see Section 3.5.1 and Section 3.5.2.

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 3, Part H Page 1679
Security Manager Specification

The format of the Initiator Key Distribution / Generation field and Responder Key
Distribution / Generation field in the Pairing Request and Pairing Response commands
for LE is defined in Figure 3.11.

LSB MSB

EncKey IdKey SignKey LinkKey RFU

(1 bit) (1 bit) (1 bit) (1 bit) (4 bits)

Figure 3.11: LE Key Distribution format

The Key Distribution / Generation field has the following flags:

• In LE legacy pairing, EncKey is a 1-bit field that is set to one to indicate that the
device shall distribute LTK using the Encryption Information command followed by
EDIV and Rand using the Central Identification command.
In LE Secure Connections pairing, when SMP is running on the LE transport, then the
EncKey field shall be ignored. EDIV and Rand shall be set to zero and shall not be
distributed.
When SMP is running on the BR/EDR transport, the EncKey field is set to one to
indicate that the device would like to derive the LTK from the BR/EDR Link Key. When
EncKey is set to 1 by both devices in the initiator and responder Key Distribution /
Generation fields, the procedures for calculating the LTK from the BR/EDR Link Key
shall be used.
• IdKey is a 1-bit field that is set to one to indicate that the device shall distribute IRK
using the Identity Information command followed by its public device or static random
address using Identity Address Information.
• SignKey is a 1-bit field that is set to one to indicate that the device shall distribute
CSRK using the Signing Information command.
• LinkKey is a 1-bit field. When SMP is running on the LE transport, the LinkKey field
is set to one to indicate that the device would like to derive the Link Key from the
LTK. When LinkKey is set to 1 by both devices in the initiator and responder Key
Distribution / Generation fields, the procedures for calculating the BR/EDR link key
from the LTK shall be used. Devices not supporting LE Secure Connections shall
set this bit to zero and ignore it on reception. When SMP is running on the BR/EDR
transport, the LinkKey field is reserved for future use.

The Initiator Key Distribution / Generation field in the Pairing Request command is
used by the Central to request which keys are distributed or generated by the initiator
to the responder. The Responder Key Distribution / Generation field in the Pairing
Request command is used by the Central to request which keys are distributed or
generated by the responder to the initiator. The Initiator Key Distribution / Generation

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 3, Part H Page 1680
Security Manager Specification

field in the Pairing Response command from the Peripheral defines the keys that
shall be distributed or generated by the initiator to the responder. The Responder Key
Distribution / Generation field in the Pairing Response command from the Peripheral
defines the keys that shall be distributed or generated by the responder to the initiator.
The Peripheral shall not set to one any flag in the Initiator Key Distribution / Generation
or Responder Key Distribution / Generation field of the Pairing Response command that
the Central has set to zero in the Initiator Key Distribution / Generation and Responder
Key Distribution / Generation fields of the Pairing Request command.

When using LE legacy pairing, the keys shall be distributed in the following order:

1. LTK by the Peripheral

2. EDIV and Rand by the Peripheral
3. IRK by the Peripheral
4. BD_ADDR by the Peripheral
5. CSRK by the Peripheral
6. LTK by the Central
7. EDIV and Rand by the Central
8. IRK by the Central
9. BD_ADDR by the Central
10. CSRK by the Central

When using LE Secure Connections, the keys shall be distributed in the following order:

1. IRK by the Peripheral

2. BD_ADDR by the Peripheral
3. CSRK by the Peripheral
4. IRK by the Central
5. BD_ADDR by the Central
6. CSRK by the Central

If a key is not being distributed then the command to distribute that key shall not be
sent.

Note: If a key is not distributed, then the capabilities that use this key will not be
available. For example, if an LTK is not distributed from the Peripheral to the Central,
then the Central cannot encrypt a future link with that Peripheral, therefore pairing would
have to be performed again.

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 3, Part H Page 1681
Security Manager Specification

Note: The initiator should determine the keys needed based on the capabilities that
are required by higher layer specifications. For example, if the initiator determines that
encryption is required in a future link with that Peripheral, then the initiator must request
that Peripheral's LTK is distributed by setting the EncKey bit to one in the Responder
Key Distribution / Generation field of the Pairing Request command.

A device may reject a distributed key by sending the Pairing Failed command with the
reason set to "Key Rejected".

If EncKey, IdKey, and SignKey are set to zero in the Initiator Key Distribution /
Generation and Responder Key Distribution / Generation fields, then no keys shall be
distributed or generated and the link will be encrypted using the generated STK when
using LE legacy pairing and LTK when using LE Secure Connections pairing.

Key distribution is complete in the device sending the final key when it receives the
Baseband acknowledgment for that key and is complete in the receiving device when it
receives the final key being distributed.

3.6.2 Encryption Information

Encryption Information is used in the LE legacy pairing Transport Specific Key

Distribution to distribute LTK that is used when encrypting future connections. The
Encryption Information command is defined in Figure 3.12.

The Encryption Information command shall only be sent when the link has been
encrypted or re-encrypted using the generated STK.

LSB octet 0 octet 1 octet 2 octet 3 MSB

Code=0x06 Long Term Key

Long Term Key

Long Term Key

Long Term Key

Long Term
Key

Figure 3.12: Encryption Information packet

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 3, Part H Page 1682
Security Manager Specification

The following is the data field:

• Long Term Key (16 octets)

The generated LTK value being distributed, see Section 2.4.2.3.

3.6.3 Central Identification

Central Identification is used in the LE legacy pairing Transport Specific Key Distribution
phase to distribute EDIV and Rand which are used when encrypting future connections.
The Central Identification command is defined in Figure 3.13.

The Central Identification command shall only be sent when the link has been encrypted
or re-encrypted using the generated STK.

LSB octet 0 octet 1 octet 2 octet 3 MSB

Code=0x07 EDIV Rand

Rand

Rand

Figure 3.13: Central Identification packet

The following data fields are used:

• EDIV (2 octets)
The EDIV value being distributed (see Section 2.4.2.3).
• Rand (8 octets)
64-bit Rand value being distributed (see Section 2.4.2.3).

3.6.4 Identity Information

Identity Information is used in the Transport Specific Key Distribution phase to distribute
the IRK. The Identity Information command is defined in Figure 3.14.

The Identity Information command shall only be sent when the link has been encrypted
or re-encrypted using the generated key.

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 3, Part H Page 1683
Security Manager Specification

LSB octet 0 octet 1 octet 2 octet 3 MSB

Code=0x08 Identity Resolving Key

Identity Resolving Key

Identity Resolving Key

Identity Resolving Key

Identity
Resolving
Key

Figure 3.14: Identity Information packet

The following are the data fields:

• Identity Resolving Key (16 octets)

128-bit IRK value being distributed (see Section 2.4.2.1).

Note: An all zero Identity Resolving Key data field indicates that a device does not have
a valid resolvable private address.

3.6.5 Identity Address Information

Identity Address Information is used in the Transport Specific Key Distribution phase
to distribute its public device address or static random address. The Identity Address
Information command is defined in Figure 3.15.

The Identity Address Information command shall only be sent when the link has been
encrypted or re-encrypted using the generated key.

LSB octet 0 octet 1 octet 2 octet 3 MSB

Code=0x09 AddrType BD_ADDR

BD_ADDR

Figure 3.15: Identity Address Information packet

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 3, Part H Page 1684
Security Manager Specification

The data fields are:

• AddrType (1 octet)
If BD_ADDR is a public device address, then AddrType shall be set to 0x00. If
BD_ADDR is a static random device address then AddrType shall be set to 0x01.
• BD_ADDR (6 octets)
This field is set to the distributing device’s public device address or static random
address.

3.6.6 Signing Information

Signing Information is used in the Transport Specific Key Distribution to distribute the
CSRK which a device uses to sign data. The Signing Information command is defined in
Figure 3.16.

The Signing Information command shall only be sent when the link has been encrypted
or re-encrypted using the generated key.

LSB octet 0 octet 1 octet 2 octet 3 MSB

Code=0x0A Signature Key

Signature Key

Signature Key

Signature Key

Signature
Key

Figure 3.16: Signing Information packet

The following data field is used:

• Signature Key (16 octets)

128-bit CSRK that is being distributed; see Section 2.4.2.2.

3.6.7 Security Request

The Security Request command is used by the Peripheral to request that the Central
initiates security with the requested security properties, see Section 2.4.6. The Security
Request command is defined in Figure 3.17.

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 3, Part H Page 1685
Security Manager Specification

LSB octet 0 octet 1 MSB

Code=0x0B AuthReq

Figure 3.17: Security Request packet

The following data field is used:

• AuthReq (1 octet)
The AuthReq field is a bit field that indicates the requested security properties (see
Section 2.3.1) for the STK or LTK and GAP bonding information (see [Vol 3] Part C,
Section 9.4).
Figure 3.3 defines the authentication requirements bit field.
The Bonding_Flags field is a 2-bit field that indicates the type of bonding being
requested by the responding device as defined in Table 3.6.
The MITM field is a 1-bit flag that is set to one if the device is requesting MITM
protection, otherwise it shall be set to 0. A device sets the MITM flag to one to request
an Authenticated security property for the STK when using LE legacy pairing and the
LTK when using LE Secure Connections.
The SC field is a 1 bit flag. If LE Secure Connections pairing is supported by the
device, then the SC field shall be set to 1, otherwise it shall be set to 0. If both
devices support LE Secure Connections pairing, then LE Secure Connections pairing
shall be used, otherwise LE Legacy pairing shall be used.
The keypress field is a 1-bit flag that is used only in the Passkey Entry protocol and
shall be ignored in other protocols. When both sides set that field to one, Keypress
notifications shall be generated and sent using SMP Pairing Keypress Notification
PDUs.

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 3, Part H Page 1686
Security Manager Specification

4 REFERENCES

[1] NIST Special Publication 800-38B: http://dx.doi.org/10.6028/NIST.SP.800-38B

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 3, Part H Page 1687
Security Manager Specification

Appendix A EDIV and Rand Generation

EDIV and Rand are used by the responding device to identify an initiator and recover
LTK. This section provides an example of how the distributed EDIV value is a masked
version of the real value (DIV) which is used to recover LTK. Other methods can be
used that provide equal or higher levels of confidentially for DIV.

A.1 EDIV masking

The masking process uses a Diversifier Hiding Key (DHK) which is a 128-bit key that is
never distributed.

DHK can be assigned, randomly generated by the device during manufacturing, part of
a key hierarchy (see Appendix B, Section B.2.3) or some other method could be used,
that results in DHK having 128 bits of entropy. If DHK is randomly generated then the
requirements for random generation defined in [Vol 2] Part H, Section 2 shall be used.

If DHK is changed then DIV values cannot be recovered from previously distributed
EDIV values.

Section A.1.1 defines a cryptographic function that is used by the responding device
when generating EDIV and recovering DIV.

Section A.1.2 describes how a responding device generates an EDIV value to be

distributed to an initiating device and Section A.1.3 describes how the responding
device recovers DIV from a distributed EDIV value.

A.1.1 DIV mask generation function dm

DIV is masked before distribution and unmasked during the encryption session setup
using the output of the DIV mask generation function dm.

The following are inputs to the DIV mask generation function dm:

k is 128 bits
r is 64 bits
padding is 64 bits

r is concatenated with padding to generate r’ which is used as the 128-bit input

parameter plaintextData to security function e:

r’ = padding || r

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 3, Part H Page 1688
Security Manager Specification

The least significant octet of r becomes the least significant octet of r’ and the most
significant octet of padding becomes the most significant octet of r’.

For example, if the 64-bit value r is 0x123456789ABCDEF0 then r’ is

0x0000000000000000123456789ABCDEF0.

The output of the DIV mask generation function dm is

dm(k, r) = e(k, r’) mod 216

The output of the security function e is then truncated to 16 bits by taking the least
significant 16 bits of the output of e as the result of dm.

A.1.2 EDIV generation

The responding device generates a 64-bit random value, Rand. The Rand value is
used to generate 16-bit Y using the DIV mask generation function dm with the input
parameter k set to DHK and the input parameter r set to Rand.

Y = dm(DHK, Rand)

The responding device then masks the DIV value to be distributed by bitwise XORing it
with Y to generate EDIV.

EDIV = Y xor DIV

EDIV and Rand are distributed to an initiating device during the transport specific key
distribution phase using the Central Identification command.

A.1.3 DIV recovery

When the responding device receives a request to encrypt a session it calculates Y

using the DIV mask generation function dm with the input parameter k set to DHK and
the input parameter r set to Rand. The Y value is bitwise XORed with EDIV from the
initiator to recover DIV.

DIV = Y xor EDIV

The recovered DIV value can then used to recover LTK which is used to enable
encryption on the link.

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 3, Part H Page 1689
Security Manager Specification

Appendix B Key Management

The security provided by different methods can vary and care should be taken to ensure
that a chosen method is suitable for a device’s requirements.

Section B.1 uses a database for managing the keys. Section B.2 uses a key hierarchy
to manage the keys.

B.1 Database lookup

The LTK which is distributed is a 128-bit random number which is stored in a database,
using EDIV as an index. There is no direct relationship between LTK and EDIV.

The requirements for random generation defined in [Vol 2] Part H, Section 2 shall be
used when generating LTK. This method provides an LTK with 128 bits of entropy.

CSRK, IRK, and other keys shall also be stored in the database. There is no
relationship between the keys stored in the database or distributed LTKs, EDIVs, or
Rands.

If the example EDIV and Rand generation method described in Section A.1 is used then
the database shall be used to store DHK. DIV should be used as the index to recover
LTK.

B.2 Key hierarchy

A key hierarchy can be used to generate the keys.

IR ER

IRK LTK CSRK

Figure B.1: Example key hierarchy

Figure B.1 is an example key hierarchy where LTK and CSRK are generated from a
common ER key, and IRK is generated from a common IR key.

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 3, Part H Page 1690
Security Manager Specification

1. ER is a 128-bit key generated for each LE device that supports encrypted

connections. It is used to generate LTK using EDIV; see Section B.2.2.
2. IR is a 128-bit key generated for each LE device that supports encrypted
connections, uses random addresses or signing data. IR is used to generate
IRK and CSRK, see Section B.2.3. It can also be used to generate DHK; see
Section A.1.

New LTK, EDIV, Rand, and CSRK values shall be generated each time they are
distributed. If ER is changed then any previously distributed LTK or CSRK keys will
no longer be valid.

The distributed IRK shall be the same for all devices it is distributed to. If IR is changed
then any previously distributed IRK keys will no longer be valid.

The distributing device only needs to store IR and ER. LTK, IRK, and CSRK can be
regenerated when they are required. This reduces the storage requirements on the
distributing device.

Section B.2.1 defines an example of the key diversifying function which can be used to
generate LTK, IRK, CSRK, and other keys. Other implementations of this function can
be used depending upon the exact security requirements of the device.

The NIST Special Publication 800-108 (http://csrc.nist.gov/publications/PubsSPs.html)

defines key derivation functions which could be used instead of the example diversifying
function d1.

B.2.1 Diversifying function d1

Diversified keys are generated with function d1. The diversifying function d1 makes use
of the security function e.

The following are inputs to diversifying function d1:

k is 128 bits
d is 16 bits
r is 16 bits
padding is 96 bits

d is concatenated with r and padding to generate d’, which is used as the 128-bit input
parameter plaintextData to security function e:

d’ = padding || r || d

The least significant octet of d becomes the least significant octet of d’ and the most
significant octet of padding becomes the most significant octet of d’.

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 3, Part H Page 1691
Security Manager Specification

For example, if the 16-bit value d is 0x1234 and the 16-bit value r is 0xABCD, then d’ is
0x000000000000000000000000ABCD1234.

The output diversifying function d1 is:

d1(k, d, r) = e(k, d’)

The 128-bit output of the security function e is used as the result of diversifying function
d1.

B.2.2 Generating keys from ER

ER is used to generate LTK and CSRK. ER can be assigned, randomly generated by

the device during manufacturing or some other method could be used, that results in
ER having 128 bits of entropy. If ER is randomly generated then the requirements for
random generation defined in [Vol 2] Part H, Section 2 shall be used.

The EDIV and Rand generation method described in Appendix A shall be used. LTK is
the result of the diversifying function d1 with the ER as the input parameter k, the DIV
as the input parameter d, and the value 0 as the input parameter r; see Section B.2.1.

LTK = d1(ER, DIV, 0)

LTK can be recovered from ER and DIV by repeating the calculation when LTK is
required.

CSRK is the result of the diversifying function d1 with the ER as the input parameter
k, the DIV as the input parameter d, and the value 1 as the input parameter r; see
Section B.2.1.

CSRK = d1(ER, DIV, 1)

CSRK can be recovered from ER and DIV by repeating the calculation when CSRK is
required.

This method provides an LTK and CSRK with limited amount of entropy because LTK
and CSRK are directly related to EDIV and may be less secure than other generation
methods.

To reduce the probability of the same LTK or CSRK value being generated, the DIV
values must be unique for each CSRK, LTK, EDIV, and Rand set that is distributed.

A method for preventing a malicious device from repeatedly pairing and collecting
CSRK, LTK and DIV information, which could be used in a known plain text attack in
ER, should be implemented.

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 3, Part H Page 1692
Security Manager Specification

Note: The generation of LTK using ER is only applicable when doing LE Legacy Pairing.
The generation of CSRK using ER is applicable both when doing LE Legacy Pairing and
LE Secure Connections Pairing.

B.2.3 Generating keys from IR

IR can be used to generate IRK and other required keys. IR can be assigned, randomly
generated by the device during manufacturing or some other method could be used,
that results in IR having 128 bits of entropy. If IR is randomly generated then the
requirements for random generation defined in Section A.1 shall be used.

IRK is the result of the diversifying function d1 with IR as the input parameter k and
the value 1 as the input parameter d and the value 0 as the input parameter r; see
Section B.2.1.

IRK = d1(IR, 1, 0)

If the example EDIV and Rand generation method described in EDIV and Rand
Generation, Section A.1 is used then DHK can be the result of diversifying function
d1 with IR as the input parameter k and the value 3 as the input parameter d and the
value 0 as the input parameter r.

DHK = d1(IR, 3, 0)

Other keys can be generated by using different values for k as the input to the
diversifying function d1. If the value of k is reused for a given IR then the resulting
key will be the same.

Note: The generation of DHK using IR is only applicable when doing LE Legacy Pairing.
The generation of IRK using IR is applicable both when doing LE Legacy Pairing and LE
Secure Connections Pairing.

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 3, Part H Page 1693
Security Manager Specification

Appendix C Message sequence charts

This appendix illustrates only the most common scenarios; it does not cover all possible
alternatives. Furthermore, the message sequence charts do not consider errors over the
air interface or Host interface. If any of these charts differ with text elsewhere in this
Part, then that text overrides these charts.

A flow diagram of pairing is shown in Figure C.1. The process has 4 steps. Step 2 has a
number of different options.

Step 1: Pairing Feature Exchange

Step 2a: Optional Short Step 2b: Optional Short Step 2c: Optional Short
Term Key (STK) Term Key (STK) Generation Term Key (STK)
Generation – Just Works – Passkey Entry Generation – OOB

Step 3: Encrypt Link Using Generated STK

Step 4: Transport Specific Key Distribution

Figure C.1: Pairing process overview

Note: In all the MSCs, the Central is also the Initiating Device and the Peripheral is also
the Responding (non-Initiating) Device.

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 3, Part H Page 1694
Security Manager Specification

C.1 Phase 1: Pairing feature exchange

The Central initiates the pairing procedure using Pairing Request command as shown in
Figure C.2.

Central Peripheral

Step 1: Central initiates pairing

Pairing Request (IO Capability, OOB data flag, AuthReq, Max Enc Key Size, Init Key Distribution, Resp Key Distribution)

Pairing Response (IO Capability, OOB data flag, AuthReq, Max Enc Key Size, Init Key Distribution, Resp Key Distribution)

Phase 2 Pairing Method selected from parameters of Pairing Request and Pairing Response

Figure C.2: Pairing initiated by Central

C.1.1 Peripheral security request – Central requests pairing

The Peripheral may request the Central initiates security procedures. Figure C.3 shows
an example where the Peripheral requests security and the Central initiates pairing in
response.

Central Peripheral

Step 1: Peripheral requests security, Central initiates pairing

Security Request (AuthReq)

Pairing Request (IO Capability, OOB data flag, AuthReq, Max Enc Key Size, Init Key Distribution, Resp Key Distribution)

Pairing Response (IO Capability, OOB data flag, AuthReq, Max Enc Key Size, Init Key Distribution, Resp Key Distribution)

LE Legacy Pairing Phase 2 Pairing Method selected from parameters of

Pairing Request and Pairing Response

Figure C.3: Peripheral security request, Central initiated pairing

C.2 Phase 2: Authenticating and encrypting

After Pairing Feature Exchange has completed a pairing method is selected one of
the possible short term key generation sequences are used. This can be Just Works,
Passkey Entry or Out of Band pairing method.

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 3, Part H Page 1695
Security Manager Specification

C.2.1 LE legacy pairing

The following subsections include message sequence charts for LE legacy pairing.

C.2.1.1 Legacy Phase 2: Short Term Key generation – Just Works

After Pairing Feature Exchange has completed a pairing method is selected. Figure C.4
shows the Just Works pairing method.

Central Peripheral

Step 1: Just Works Pairing After Phase 1: Pairing Feature Change

Just Works pairing algorithm selected from parameters of Pairing Request

and Pairing Response on Phase 1: Pairing Feature Exchange

Create LP_RAND_I Create LP_RAND_R

TK=0x00 TK=0x00

LP_CONFIRM_I = c1(TK, LP_RAND_I, Pairing Request LP_CONFIRM_R = c1(TK, LP_RAND_R, Pairing Request
command, Pairing Response command, initiating device command, Pairing Response command, initiating device
address type, initiating device address, responding address type, initiating device address, responding
device address type, responding device address) device address type, responding device address)

PairingConfirm (LP_CONFIRM_I)

PairingConfirm (LP_CONFIRM_R)

PairingRandom (LP_RAND_I)

Check for confirm value match

PairingRandom (LP_RAND_R)

Check for confirm value match

STK is calculated by running s1 with the TK value as the key input

and initiator and responder random numbers.
STK = s1(TK, LP_RAND_R, LP_RAND_I)

Link is then encrypted using STK, see [Vol 6] Part D, Section 6.6

Figure C.4: Legacy Just Works pairing method

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 3, Part H Page 1696
Security Manager Specification

C.2.1.2 Legacy Phase 2: Short Term Key generation – Passkey Entry

After Pairing Feature Exchange has completed, a pairing method is selected. Figure C.5
shows the Passkey Entry pairing method.

Central Peripheral

Step 1: Passkey Entry Pairing After Phase 1: Pairing Feature Change

Passkey Entry pairing algorithm selected from parameters of Pairing Request

and Pairing Response on Phase 1: Pairing Feature Exchange

Create LP_RAND_I Create LP_RAND_R

Set TK = User input passkey Set TK = User input passkey

LP_CONFIRM_I = c1(TK, LP_RAND_I, Pairing Request LP_CONFIRM_R = c1(TK, LP_RAND_R, Pairing Request
command, Pairing Response command, initiating device command, Pairing Response command, initiating device
address type, initiating device address, responding address type, initiating device address, responding
device address type, responding device address) device address type, responding device address)

PairingConfirm (LP_CONFIRM_I)

PairingConfirm (LP_CONFIRM_R)

PairingRandom (LP_RAND_I)

Check for confirm value match

PairingRandom (LP_RAND_R)

Check for confirm value match

STK is calculated by running s1 with the TK value as the key input

and initiator and responder random numbers.
STK = s1(TK, LP_RAND_R, LP_RAND_I)

Link is then encrypted using STK, see [Vol 6] Part D, Section 6.6

Figure C.5: Legacy Passkey Entry pairing method

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 3, Part H Page 1697
Security Manager Specification

C.2.1.3 Legacy Phase 2: Short Term Key generation – Out of Band

After Pairing Feature Exchange has completed, a pairing method is selected. Figure C.6
shows the Out of Band pairing method.

Central Peripheral

Step 1: Out Of Band Pairing After Phase 1: Pairing Feature Change

Out of band pairing algorithm selected from parameters of Pairing

Request and Pairing Response on Phase 1: Pairing Feature Exchange

Create LP_RAND_I Create LP_RAND_R

Set TK = to the OOB Security Set TK = to the OOB Security
Manager TK value Manager TK value

LP_CONFIRM_I = c1(TK, LP_RAND_I, Pairing Request LP_CONFIRM_R = c1(TK, LP_RAND_R, Pairing Request
command, Pairing Response command, initiating device command, Pairing Response command, initiating device
address type, initiating device address, responding address type, initiating device address, responding
device address type, responding device address) device address type, responding device address)

PairingConfirm (LP_CONFIRM_I)

PairingConfirm (LP_CONFIRM_R)

PairingRandom (LP_RAND_I)

Check for confirm value match

PairingRandom (LP_RAND_R)

Check for confirm value match

STK is calculated by running s1 with the TK value as the key input

and initiator and responder random numbers.
STK = s1(TK, LP_RAND_R, LP_RAND_I)

Link is then encrypted using STK, see [Vol 6] Part D, Section 6.6

Figure C.6: Legacy OOB pairing method

C.2.2 LE Secure Connections

The following subsections include message sequence charts for LE Secure

Connections.

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 3, Part H Page 1698
Security Manager Specification

C.2.2.1 Public key exchange

In Step 1a and 1b, the two devices exchange public keys. The Central sends its public
key to the Peripheral followed by Peripheral sending its public key to the Central.

Central Peripheral

Step 1a and 1b: Public Key Exchange

Pairing Public Key

Pairing Public Key

Start generating Start generating

DHKey DHKey

Figure C.7: Pairing Phase 2 – Public Key Exchange

C.2.2.2 Authentication stage 1

The following subsections include message sequence charts for the success and failure
cases in each association model.

C.2.2.2.1 Successful Numeric Comparison (or Just Works)

The numeric comparison step will be done when both devices have output capabilities,
or if one of the devices has no input or output capabilities. If both devices have output
capabilities, this step requires the displaying of a user confirmation value. This value
should be displayed until the end of step 2. If one or both devices do not have output
capabilities, the same protocol is used but the Hosts will skip the step asking for the
user confirmation.

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 3, Part H Page 1699
Security Manager Specification

Note: The sequence for Just Works is identical to that of Numeric Comparison with the
exception that the Host will not show the numbers to the user.

Central Peripheral

Step 2: Secure Connections Key (LTK) Generation

- Just Works or Numeric Comparison

Pick Na, Pick Nb,

Set ra & rb = 0 Set ra & rb = 0

Calculate
confirmation
Pairing Confirm (Cb)

Pairing Random (Na)

Pairing Random (Nb)

Check
Confirmation -
success

Calculate User Calculate User

Confirm Value Confirm Value

These values are presented to the user

User Confirms User Confirms

Value Value
(Success) (Success)

Figure C.8: Pairing Phase 2, authentication stage 1, successful Numeric Comparison

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 3, Part H Page 1700
Security Manager Specification

C.2.2.2.2 Numeric Comparison – Confirm Check failure on the Initiator side

If the Confirm value calculated by the Initiator is not equal to the Commitment value
received from the Responder, the Initiator will abort Pairing process by sending Pairing
Failed with reason “Confirm Value Failed”.

Central Peripheral

Step 2: Secure Connections Key (LTK) Generation

- Just Works or Numeric Comparison

Pick Na, Pick Nb,

Set ra & rb = 0 Set ra & rb = 0

Calculate
confirmation
Pairing Confirm (Cb)

Pairing Random (Na)

Pairing Random (Nb)

Check
Confirmation
Abort if
mismatch
Pairing Failed (confirm check failure)

Figure C.9: Pairing Phase 2, authentication stage 1, Numeric Comparison – Confirm Check failure on
Initiator side

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 3, Part H Page 1701
Security Manager Specification

C.2.2.2.3 Numeric Comparison failure on the Initiator side

If the numeric comparison fails on the initiating side due to the user indicating that the
confirmation values do not match, Pairing is terminated.

Central Peripheral

Step 2: Secure Connections Key (LTK) Generation

- Just Works or Numeric Comparison

Pick Na, Pick Nb,

Set ra & rb = 0 Set ra & rb = 0

Calculate
confirmation
Pairing Confirm (Cb)

Pairing Random (Na)

Pairing Random (Nb)

Check
Confirmation -
success

Calculate User Calculate User

Confirm Value Confirm Value

These values are presented to the user

User Does not User Confirms

Confirm Value Value (Success)
Pairing Failed (Numeric Comparison Failed)

Figure C.10: Pairing Phase 2, authentication stage 1, Numeric Comparison failure on Initiator side

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 3, Part H Page 1702
Security Manager Specification

C.2.2.2.4 Numeric Comparison failure on the Responding side

If the numeric comparison fails on the responding side due to the user indicating that
the confirmation values do not match, Pairing is terminated.

Central Peripheral

Step 2: Secure Connections Key (LTK) Generation

- Just Works or Numeric Comparison

Pick Na, Pick Nb,

Set ra & rb = 0 Set ra & rb = 0

Calculate
confirmation
Pairing Confirm (Cb)

Pairing Random (Na)

Pairing Random (Nb)

Check
Confirmation -
success

Calculate User Calculate User

Confirm Value Confirm Value

These values are presented to the user

User Confirms User Does not

Value Confirm Value
Pairing Failed (Numeric Comparison Failed)

Figure C.11: Pairing Phase 2, authentication stage 1, Numeric Comparison failure on Responding side

C.2.2.2.5 Successful Passkey Entry

The Passkey Entry step is used in two cases: when one device has numeric input
only and the other device has either a display or numeric input capability. In this step,
one device display a number to be entered by the other device or the user enters a

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 3, Part H Page 1703
Security Manager Specification

number on both devices. Key press notification messages are shown during the user
input phase.

Central Peripheral

Step 2: Secure Connections Key (LTK) Generation - Passkey Entry

Example Notifications

Pairing Keypress Notification

User
Pairing Keypress Notification Input

Repeat 20 times

Pick Nai Pick Nbi

Use bit i of ra Use bit i of rb
Calculate Calculate
Confirm Confirm
Pairing Confirm (Cai)

Pairing Confirm (Cbi)

Pairing Random (Nai)

Check Confirm
(matches)
Pairing Random (Nbi)

Check Confirm
(matches)

Figure C.12: Pairing Phase 2, authentication stage 1, Successful Passkey Entry

Note: Passkey Entry may prolong pairing experience because of the time required to
execute 20 repetitions over SMP.

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 3, Part H Page 1704
Security Manager Specification

C.2.2.2.6 Passkey Entry – Confirm Check failure on the Responder side

If during one of the 20 repetitions, the Confirm calculated by the Responder is not equal
to the one received from the Initiator, the Responder will abort the Pairing process by
sending Pairing Failed with reason “Confirm Value Failed.”

Central Peripheral

Step 2: Secure Connections Key (LTK) Generation - Passkey Entry

Pick Nai Pick Nbi

Use bit i of ra Use bit i of rb
Calculate Calculate
Confirm Confirm
Pairing Confirm (Cai)

Pairing Confirm (Cbi)

Pairing Random (Nai)

Check Confirm
(does not match)
Pairing Failed (Confirm Value Failed)

Figure C.13: Pairing Phase 2, authentication stage 1, Passkey Entry – Confirm Check failure on
Responder side

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 3, Part H Page 1705
Security Manager Specification

C.2.2.2.7 Passkey Entry – Confirm Check failure on the Initiator side

If during one of the 20 repetitions, the Confirm calculated by the Initiator is not equal
to the one received from the Responder, the Initiator will abort the Pairing process by
sending Pairing Failed with reason “Confirm Value Failed”.

Central Peripheral

Step 2: Secure Connections Key (LTK) Generation - Passkey Entry

Example Notifications

Pairing Keypress Notification

User
Pairing Keypress Notification Input

Repeat 20 times

Pick Nai Pick Nbi

Use bit i of ra Use bit i of rb
Calculate Calculate
Confirm Confirm
Pairing Confirm (Cai)

Pairing Confirm (Cbi)

Pairing Random (Nai)

Check Confirm
(matches)
Pairing Random (Nbi)

Check Confirm
(does not match)

Pairing Failed

Figure C.14: Pairing Phase 2, authentication stage 1, Passkey Entry – Confirm Check failure on Initiator
side

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 3, Part H Page 1706
Security Manager Specification

C.2.2.2.8 Passkey Entry failure on the Responding side

If the passkey entry fails on the responding side, Pairing is terminated.

Central Peripheral

Step 2: Secure Connections Key (LTK) Generation - Passkey Entry

Pairing Confirm (Ca)

Pairing Failed (Passkey Entry Failed)

Figure C.15: Pairing Phase 2, authentication stage 1, Passkey Entry failure on Responding side

C.2.2.2.9 Passkey Entry Failure on the Initiator Side

If the passkey entry fails on the initiating side, Pairing is terminated.

Central Peripheral

Step 2: Secure Connections Key (LTK) Generation - Passkey Entry

Pairing Failed (Passkey Entry Failed)

Figure C.16: Pairing Phase 2, authentication stage 1, Passkey Entry failure on Initiator side

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 3, Part H Page 1707
Security Manager Specification

C.2.2.2.10 Successful Out of Band

The OOB authentication will only be done when at least one device has some OOB
information to use. This step requires no user interaction.

Central Peripheral

Step 2: Secure Connection Key (LTK) Generation - Out of Band

Check Confirm Check Confirm

received from received from
OOB (Confirm OOB (Confirm
matches) matches)

Pick Na Pick Nb
Pairing Random (Na)

Pairing Random (Nb)

Figure C.17: Pairing Phase 2, authentication stage 1, successful Out of Band

C.2.2.2.11 Out of Band – Confirm Check failure on the Responder side

If the Confirm value received from OOB is not equal to the calculated Confirm value, the
Responder will abort the Pairing process by sending Pairing Failed with reason “Confirm
Value Failed”.

Central Peripheral

Step 2: Secure Connection Key (LTK) Generation - Out of Band

Check Confirm Check Confirm

received from received from
OOB (Confirm OOB (Confirm
matches) No match)

Pick Na Pick Nb
Pairing Random (Na)

Pairing Failed (Confirm Value Failed)

Figure C.18: Pairing Phase 2, authentication stage 1, Out of Band – Confirm Check failure on Responder
side

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 3, Part H Page 1708
Security Manager Specification

C.2.2.2.12 Out of Band - Confirm Check failure on the Initiating side

If the Confirm value received from OOB is not equal to the calculated Confirm value, the
Initiator will abort the Pairing process by sending Pairing Failed with reason "Confirm
Value Failed".

Central Peripheral

Step 2: Secure Connection Key (LTK) Generation - Out of Band

Check Confirm Check Confirm

received from received from
OOB (Confirm OOB (Confirm
No match) matches)

Pick Na Pick Nb
Pairing Failed (Confirm Value Failed)

Figure C.19: Pairing Phase 2: authentication stage 1, Out of Band – Confirm Check failure on Initiator
side

C.2.2.2.13 Out of Band Failure on the Initiator side (OOB information not available)

If the initiating side does not have the responder's OOB information, Pairing is
terminated.

Central Peripheral

Step 2: Secure Connection Key (LTK) Generation - Out of Band

Pairing Failed (OOB Not Available)

Figure C.20: Pairing Phase 2, authentication stage 1, Out of Band failure on Initiator side

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 3, Part H Page 1709
Security Manager Specification

C.2.2.2.14 Out of Band Failure on the Responding side (OOB information not available)

If the responding side does not have the initiator's OOB information, Pairing is
terminated.

Central Peripheral

Step 2: Secure Connection Key (LTK) Generation - Out of Band

Pairing Random (Na)

Pairing Failed (OOB Not Available)

Figure C.21: Pairing Phase 2, authentication stage 1, Out of Band failure on Responding side

C.2.2.3 Long Term Key calculation

Once the DHKey generation is complete, the Long Term Key (LTK) is calculated from
the DHKey.

Central Peripheral

Step 3: Long Term Key (LTK) Calculation

DHKey DHKey
calculation calculation
finished finished

Calculate Long Calculate Long

Term Key (LTK) Term Key (LTK)

Figure C.22: Long Term Key calculation

C.2.2.4 Authentication stage 2 (DHKey checks)

Once the LTK calculation and authentication stage 1 have completed, the DHKey value
generated is checked by exchanging DHKey Check values generated using the DHKey.

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 3, Part H Page 1710
Security Manager Specification

If this succeeds, then both devices would have finished displaying information to the
user about the process, and therefore the Host can stop displaying this information.

Central Peripheral

Step 4: DHKey Checks

Calculate Calculate
DHKey Check DHKey Check
value Ea value Eb

Pairing DHKey Check value Ea

Check DHKey
Check value Ea
(check
successful)

Pairing DHKey Check value Eb

Check DHKey
Check value Eb
(check
successful)

Figure C.23: Pairing Phase 2, authentication stage 2, DHKey checks

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 3, Part H Page 1711
Security Manager Specification

C.3 Phase 3: Transport specific key distribution

After short term key generation and the link has been encrypted, transport specific keys
are distributed. Figure C.24 shows an example of all keys and values being distributed
by Central and Peripheral.

Central Peripheral

Step 1: Phase 3: Transport Specific Key Distribution.

All keys and values distributed by Peripheral and Central

Keys to be distributed is determined by the Key Distribution parameters of Pairing Request

and Pairing Response from Phase 1: Pairing Feature Exchange

Encryption Information (Long Term Key)

Central Identification (EDIV, Rand)

Identity Information (Identity Resolving Key)

Identity Address Information (AddrType, BD_ADDR)

Signing Information (Signature Key)

Encryption Information (Long Term Key)

Central Identification (EDIV, Rand)

Identity Information (Identity Resolving Key)

Identity Address Information (AddrType, BD_ADDR)

Signing Information (Signature Key)

Figure C.24: Transport specfic key distribution

C.4 Security re-established using previously distributed LTK

Devices may re-establish security using a previously distributed LTK. The Central
always initiates the encryption procedures, and therefore there are two possible
sequences: Central initiated and Peripheral requested.

C.4.1 Central initiated security - Central initiated Link Layer encryption

The Central initiates encryption procedures. There is no SM signaling to enable this; the
Central initiates Link Layer encryption only. See [Vol 6] Part D, Section 6.6.

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 3, Part H Page 1712
Security Manager Specification

C.4.2 Peripheral security request - Central initiated Link Layer encryption

The Peripheral may request the Central initiates security procedures. Figure C.25
shows an example where the Peripheral requests security and the Central initiates Link
Layer encryption.

Central Peripheral

Step 1: Peripheral Initiates Security, Central Initiates Link Layer Encryption

Security Request (AuthReq)

Link is encrypted using previously distributed LTK,

see [Vol 6] Part D, Section 6.6.

Figure C.25: Peripheral security request, Central initiates Link Layer encryption

C.5 Failure conditions

The following sequences show possible failure conditions and their associated
signaling.

C.5.1 Pairing not supported by Peripheral

If the Peripheral does not support pairing or pairing cannot be performed the Peripheral
can reject the request from the Central. Figure C.26 shows the Peripheral rejecting a
Pairing Request command from the Central.

Central Peripheral

Step 1: Peripheral device does not support pairing or pairing cannot be performed
Pairing Request (IO Capability, OOB data flag, AuthReq, Maximum Encryption Key Size, Key Distribution)

Pairing Failed ("Pairing Not Supported")

Figure C.26: Peripheral rejects pairing attempt

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 3, Part H Page 1713
Security Manager Specification

C.5.2 Central rejects pairing because of key size

During Pairing Feature Exchange the size of the Encryption Key is negotiated.
Figure C.27 shows an example where the Central terminates the pairing procedure
because the resulting key size is not acceptable.

Central Peripheral

Step 1: Peripheral device does not support pairing or pairing cannot be performed
Pairing Request (IO Capability, OOB data flag, AuthReq, Maximum Encryption Key Size, Key Distribution)

Pairing Response (IO Capability, OOB data flag, AuthReq, Maximum Encryption Key Size, Key Distribution)

Pairing Failed ("Encryption Key Size")

Figure C.27: Central rejects pairing because of key size

C.5.3 Peripheral rejects pairing because of key size

During Pairing Feature Exchange the size of the Encryption Key is negotiated.
Figure C.28 shows an example where the Peripheral terminates the pairing procedure
because the resulting key size is not acceptable.

Central Peripheral

Step 1: Peripheral rejects pairing because the Encryption Key Size is not sufficient

Alt Pairing Request (IO Capability, OOB data flag, AuthReq, Maximum Encryption Key Size, Key Distribution)

Pairing Response (IO Capability, OOB data flag, AuthReq, Maximum Encryption Key Size, Key Distribution)

Pairing Confirm (LP_CONFIRM_I)

Pairing Failed ("Encryption Key Size")

Alt Pairing Request (IO Capability, OOB data flag, AuthReq, Maximum Encryption Key Size, Key Distribution)

Pairing Failed ("Encryption Key Size")

Figure C.28: Peripheral rejects pairing because of key size

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 3, Part H Page 1714
Security Manager Specification

C.5.4 Passkey Entry failure on Central

During Passkey Entry pairing the user enters a passkey on both devices. Figure C.29
shows an example where the passkey entry fails on the Central.

Central Peripheral

Step 1: Passkey Entry failure on Central

Pairing Request (IO Capability, OOB data flag, AuthReq, Maximum Encryption Key Size, Key Distribution)

Pairing Response (IO Capability, OOB data flag, AuthReq, Maximum Encryption Key Size, Key Distribution)

Create LP_RAND_R
Set TK = User input passkey
Passkey is not entered
LP_CONFIRM_R = c1(TK, LP_RAND_R, Pairing Request
command, Pairing Response command, initiating device
address type, initiating device address, responding
device address type, responding device address)

Pairing Failed ("Passkey Entry Failed")

Figure C.29: Passkey Entry failure on Central

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 3, Part H Page 1715
Security Manager Specification

C.5.5 Passkey Entry failure on Peripheral

During Passkey Entry pairing the user enters a passkey on both devices. Figure C.30
shows an example where the passkey entry fails on the Peripheral.

Central Peripheral

Step 1: Passkey entry not performed on Peripheral

Pairing Request (IO Capability, OOB data flag, AuthReq, Maximum Encryption Key Size, Key Distribution)

Pairing Response (IO Capability, OOB data flag, AuthReq, Maximum Encryption Key Size, Key Distribution)

Create LP_RAND_R
Set TK = User input passkey
Passkey is not entered
LP_CONFIRM_R = c1(TK, LP_RAND_R, Pairing Request
command, Pairing Response command, initiating device
address type, initiating device address, responding
device address type, responding device address)

PairingConfirm (LP_CONFIRM_I)

Pairing Failed ("Passkey Entry Failed")

Figure C.30: Passkey Entry failure on Peripheral

C.5.6 Peripheral rejects Central’s confirm value

During Passkey Entry pairing the user enters a passkey on both devices. Figure C.31
shows an example where a different passkey is entered on both devices. This sequence
could also occur if any of the inputs to c1 (Passkey, LP_RAND_I, LP_RAND_R, Pairing

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 3, Part H Page 1716
Security Manager Specification

Request command, Pairing Response command, address types or addresses) are

incorrect or altered.

Central Peripheral

Step 1: Passkey entry with different passkeys entered on each device

Create LP_RAND_I Create LP_RAND_R

Set TK = User input passkey Set TK = User input passkey

LP_CONFIRM_I = c1(TK, LP_RAND_I, Pairing Request LP_CONFIRM_R = c1(TK, LP_RAND_R, Pairing Request
command, Pairing Response command, initiating device command, Pairing Response command, initiating device
address type, initiating device address, responding address type, initiating device address, responding
device address type, responding device address) device address type, responding device address)

PairingConfirm (LP_CONFIRM_I)

PairingConfirm (LP_CONFIRM_R)

PairingRandom (LP_RAND_I)

Confirm value does not match

Pairing Failed ("Confirm Value Failed")

Figure C.31: Different passkeys entered

C.5.7 Central rejects Peripheral’s confirm value

During all the pairing methods the Central and Peripheral send random numbers and
confirm values. Figure C.32 shows an example where the Central rejects pairing
because it cannot verify the confirm value from the Peripheral because any of the

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 3, Part H Page 1717
Security Manager Specification

inputs to c1 (Passkey, LP_RAND_I, LP_RAND_R, Pairing Request command, Pairing

Response command, address types or addresses) are incorrect or altered.

Central Peripheral

Step 1: LP_CONFIRM_R verification failure on Central device

Create LP_RAND_I Create LP_RAND_R

Set TK = User input passkey Set TK = User input passkey

LP_CONFIRM_I = c1(TK, LP_RAND_I, Pairing Request LP_CONFIRM_R = c1(TK, LP_RAND_R, Pairing Request
command, Pairing Response command, initiating device command, Pairing Response command, initiating device
address type, initiating device address, responding address type, initiating device address, responding
device address type, responding device address) device address type, responding device address)

PairingConfirm (LP_CONFIRM_I)

PairingConfirm (LP_CONFIRM_R)

PairingRandom (LP_RAND_I)

Check for confirm value match

PairingRandom (LP_RAND_R)

Check for confirm value match

Pairing Failed ("Confirm Value Failed")

Figure C.32: Central rejects LP_CONFIRM_R value from Peripheral

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 3, Part H Page 1718
Security Manager Specification

Appendix D Sample data

In each data set in this section, the bytes are ordered from most significant on the left to
least significant on the right. ‘M’ represents the message byte array for which the AES
CMAC is calculated.

D.1 AES-CMAC RFC4493 test vectors

The following test vectors are referenced from RFC4493.

K 2b7e1516 28aed2a6 abf71588 09cf4f3c

Subkey Generation
AES_128(key,0) 7df76b0c 1ab899b3 3e42f047 b91b546f
K1 fbeed618 35713366 7c85e08f 7236a8de
K2 f7ddac30 6ae266cc f90bc11e e46d513b

D.1.1 Example 1: Len = 0

M <empty string>
AES_CMAC bb1d6929 e9593728 7fa37d12 9b756746

D.1.2 Example 2: Len = 16

M 6bc1bee2 2e409f96 e93d7e11 7393172a

AES_CMAC 070a16b4 6b4d4144 f79bdd9d d04a287c

D.1.3 Example 3: Len = 40

M0 6bc1bee2 2e409f96 e93d7e11 7393172a

M1 ae2d8a57 1e03ac9c 9eb76fac 45af8e51
M2 30c81c46 a35ce411
AES_CMAC dfa66747 de9ae630 30ca3261 1497c827

D.1.4 Example 4: Len = 64

M0 6bc1bee2 2e409f96 e93d7e11 7393172a

M1 ae2d8a57 1e03ac9c 9eb76fac 45af8e51
M2 30c81c46 a35ce411 e5fbc119 1a0a52ef
M3 f69f2445 df4f9b17 ad2b417b e66c3710
AES_CMAC 51f0bebf 7e3b9d92 fc497417 79363cfe

D.2 f4 LE SC confirm value generation function

U 20b003d2 f297be2c 5e2c83a7 e9f9a5b9
eff49111 acf4fddb cc030148 0e359de6
V 55188b3d 32f6bb9a 900afcfb eed4e72a
59cb9ac2 f19d7cfb 6b4fdd49 f47fc5fd

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 3, Part H Page 1719
Security Manager Specification

X d5cb8454 d177733e ffffb2ec 712baeab

Z 0x00
M0 20b003d2 f297be2c 5e2c83a7 e9f9a5b9
M1 eff49111 acf4fddb cc030148 0e359de6
M2 55188b3d 32f6bb9a 900afcfb eed4e72a
M3 59cb9ac2 f19d7cfb 6b4fdd49 f47fc5fd
00
AES_CMAC f2c916f1 07a9bd1c f1eda1be a974872d

D.3 f5 LE SC key generation function

DHKey(W) ec0234a3 57c8ad05 341010a6 0a397d9b
99796b13 b4f866f1 868d34f3 73bfa698
T 3c128f20 de883288 97624bdb 8dac6989
keyID 62746c65
N1 d5cb8454 d177733e ffffb2ec 712baeab
N2 a6e8e7cc 25a75f6e 216583f7 ff3dc4cf
A1 00561237 37bfce
A2 00a71370 2dcfc1
Length 0100
(LTK)
M0 0162746c 65d5cb84 54d17773 3effffb2
M1 ec712bae aba6e8e7 cc25a75f 6e216583
M2 f7ff3dc4 cf005612 3737bfce 00a71370
M3 2dcfc101 00
AES_CMAC 69867911 69d7cd23 980522b5 94750a38
(MacKey)
M0 0062746c 65d5cb84 54d17773 3effffb2
M1 ec712bae aba6e8e7 cc25a75f 6e216583
M2 f7ff3dc4 cf005612 3737bfce 00a71370
M3 2dcfc101 00
AES_CMAC 2965f176 a1084a02 fd3f6a20 ce636e20

D.4 f6 LE SC check value generation function

N1 d5cb8454 d177733e ffffb2ec 712baeab
N2 a6e8e7cc 25a75f6e 216583f7 ff3dc4cf
MacKey 2965f176 a1084a02 fd3f6a20 ce636e20
R 12a3343b b453bb54 08da42d2 0c2d0fc8
IOcap 010102
A1 00561237 37bfce
A2 00a71370 2dcfc1
M0 d5cb8454 d177733e ffffb2ec 712baeab
M1 a6e8e7cc 25a75f6e 216583f7 ff3dc4cf
M2 12a3343b b453bb54 08da42d2 0c2d0fc8
M3 01010200 56123737 bfce00a7 13702dcf
M4 c1
AES_CMAC e3c47398 9cd0e8c5 d26c0b09 da958f61

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 3, Part H Page 1720
Security Manager Specification

D.5 g2 LE SC numeric comparison generation function

U 20b003d2 f297be2c 5e2c83a7 e9f9a5b9
eff49111 acf4fddb cc030148 0e359de6
V 55188b3d 32f6bb9a 900afcfb eed4e72a
59cb9ac2 f19d7cfb 6b4fdd49 f47fc5fd
X d5cb8454 d177733e ffffb2ec 712baeab
Y a6e8e7cc 25a75f6e 216583f7 ff3dc4cf
M0 20b003d2 f297be2c 5e2c83a7 e9f9a5b9
M1 eff49111 acf4fddb cc030148 0e359de6
M2 55188b3d 32f6bb9a 900afcfb eed4e72a
M3 59cb9ac2 f19d7cfb 6b4fdd49 f47fc5fd
M4 a6e8e7cc 25a75f6e 216583f7 ff3dc4cf
AES_CMAC 1536d18d e3d20df9 9b7044c1 2f9ed5ba
g2 2f9ed5ba

D.6 h6 LE SC link key conversion function

Key ec0234a3 57c8ad05 341010a6 0a397d9b
keyID 6c656272
M 6c656272
AES_CMAC 2d9ae102 e76dc91c e8d3a9e2 80b16399

D.7 ah random address hash functions

IRK ec0234a3 57c8ad05 341010a6 0a397d9b
prand 00000000 00000000 00000000 00708194
M 00000000 00000000 00000000 00708194
AES_128 159d5fb7 2ebe2311 a48c1bdc c40dfbaa
ah 0dfbaa

D.8 h7 LE SC link key conversion function

Key ec0234a3 57c8ad05 341010a6 0a397d9b
SALT 00000000 00000000 00000000 746D7031
AES_CMAC fb173597 c6a3c0ec d2998c2a 75a57011

D.9 LTK to link key conversion using CT2=1

LTK 368df9bc e3264b58 bd066c33 334fbf64
Link Key 287ad379 dca40253 0a39f1f4 3047b835

D.10 LTK to link key conversion using CT2=0

LTK 368df9bc e3264b58 bd066c33 334fbf64
Link Key bc1ca4ef 633fc1bd 0d8230af ee388fb0

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 3, Part H Page 1721
Security Manager Specification

D.11 Link key to LTK conversion using CT2=1

Link Key 05040302 01000908 07060504 03020100
LTK e85e09eb 5eccb3e2 69418a13 3211bc79

D.12 Link key to LTK conversion using CT2=0

Link Key 05040302 01000908 07060504 03020100
LTK a813fb72 f1a3dfa1 8a2c9a43 f10d0a30

Bluetooth SIG Proprietary Version Date: 2024-08-27