Architecture, Change

History, and Conventions

Specification of the Bluetooth® System

Volume 1

Covered Core Package Version: v6.0

Version Date: 2024-08-27

Bluetooth SIG Proprietary

 Architecture, Change History,
And Conventions
Part A

ARCHITECTURE

Bluetooth SIG Proprietary

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 1, Part A Page 218
Architecture

CONTENTS

1 General description .................................................................................. 223

1.1 Overview of BR/EDR operation ................................................... 224
1.2 Overview of Bluetooth Low Energy operation ............................. 226
1.3 [This section is no longer used] ................................................... 232
1.4 Nomenclature .............................................................................. 232

2 Core system architecture ......................................................................... 239

2.1 Core architectural blocks ............................................................. 242
2.1.1 Host architectural blocks .............................................. 243
2.1.1.1 Channel manager ........................................ 243
2.1.1.2 L2CAP resource manager ........................... 243
2.1.1.3 Security Manager Protocol ........................... 243
2.1.1.4 Attribute Protocol .......................................... 244
2.1.1.5 [This section is no longer used] ................... 244
2.1.1.6 Generic Attribute Profile ............................... 244
2.1.1.7 Generic Access Profile ................................. 244
2.1.1.8 Service Discovery Protocol .......................... 244
2.1.2 BR/EDR/LE Controller architectural blocks ................. 244
2.1.2.1 Device manager ........................................... 244
2.1.2.2 Link manager ............................................... 245
2.1.2.3 Baseband resource manager ....................... 245
2.1.2.4 Link Controller .............................................. 246
2.1.2.5 PHY .............................................................. 246
2.1.2.6 Isochronous Adaptation Layer ..................... 246
2.1.2.7 Channel Sounding ....................................... 246
2.1.3 [This section is no longer used] ................................... 247

3 Transport architecture .............................................................................. 248

3.1 Core traffic bearers ...................................................................... 248
3.1.1 Framed data traffic ....................................................... 250
3.1.2 Unframed data traffic ................................................... 251
3.1.3 Reliability of traffic bearers .......................................... 252
3.1.3.1 BR/EDR reliability ......................................... 252
3.1.3.2 LE reliability .................................................. 253
3.1.3.3 [This section is no longer used] ................... 254
3.2 Transport architecture entities ..................................................... 254
3.2.1 BR/EDR generic packet structure ................................ 254
3.2.2 LE generic packet structure ......................................... 256
3.2.3 LE Channel Sounding generic packet structure
and signaling format .................................................... 260

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 1, Part A Page 219
Architecture

3.3 Physical channels ....................................................................... 261

3.3.1 BR/EDR physical channels .......................................... 262
3.3.1.1 Basic piconet channel .................................. 262
3.3.1.2 Adapted piconet channel ............................. 264
3.3.1.3 Inquiry scan channel .................................... 264
3.3.1.4 Page scan channel ...................................... 266
3.3.1.5 Synchronization scan channel ..................... 267
3.3.2 LE physical channels ................................................... 268
3.3.2.1 LE piconet physical channel ........................ 269
3.3.2.2 Advertising physical channels ...................... 270
3.3.2.3 Periodic physical channel ............................ 271
3.3.2.4 LE Isochronous physical channel ................ 272
3.3.2.5 LE Channel Sounding physical channel ...... 274
3.3.3 [This section is no longer used] ................................... 275
3.4 Physical links ............................................................................... 275
3.4.1 BR/EDR links supported by the basic and
adapted piconet physical channels .............................. 276
3.4.1.1 Active physical link ....................................... 276
3.4.1.2 [This section is no longer used] ................... 277
3.4.1.3 Connectionless Peripheral Broadcast
physical link .................................................. 277
3.4.2 BR/EDR links supported by the scanning
physical channels ........................................................ 277
3.4.3 LE links supported by the LE physical channels ......... 277
3.4.3.1 Active physical link ....................................... 277
3.4.3.2 Advertising physical link ............................... 278
3.4.3.3 Periodic physical link .................................... 278
3.4.3.4 Isochronous physical links ........................... 278
3.4.3.5 Channel Sounding physical link ................... 278
3.4.4 [This section is no longer used] ................................... 279
3.5 Logical links and logical transports ............................................. 279
3.5.1 Casting ......................................................................... 281
3.5.2 Scheduling and acknowledgment scheme .................. 281
3.5.3 Class of data ................................................................ 282
3.5.4 Logical transports ........................................................ 283
3.5.4.1 BR/EDR asynchronous connection-
oriented (ACL) .............................................. 283
3.5.4.2 BR/EDR synchronous connection-
oriented (SCO) ............................................. 283
3.5.4.3 BR/EDR extended synchronous
connection-oriented (eSCO) ........................ 284
3.5.4.4 BR/EDR active Peripheral broadcast (APB) 284
3.5.4.5 [This section is no longer used] ................... 285

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 1, Part A Page 220
Architecture

3.5.4.6LE asynchronous connection (LE ACL) ....... 285

3.5.4.7LE advertising broadcast (ADVB) ................ 286
3.5.4.8Connectionless Peripheral Broadcast
(CPB) ........................................................... 286
3.5.4.9 LE periodic advertising ................................. 286
3.5.4.10 Connected Isochronous Stream (CIS) ......... 287
3.5.4.11 Connected Isochronous Group (CIG) .......... 288
3.5.4.12 Broadcast Isochronous Stream (BIS) .......... 288
3.5.4.13 Broadcast Isochronous Group (BIG) ............ 288
3.5.5 Logical links ................................................................. 289
3.5.5.1 BR/EDR logical links .................................... 289
3.5.5.2 LE logical links ............................................. 290
3.5.5.3 [This section is no longer used] ................... 291
3.6 L2CAP channels ......................................................................... 291
3.7 Isochronous Adaptation Layer (ISOAL) ...................................... 292
3.8 Power control .............................................................................. 292
3.8.1 Power control in BR/EDR ............................................ 292
3.8.2 Power control in LE ...................................................... 293

4 Communication topology and operation ................................................ 294

4.1 Piconet topology .......................................................................... 294
4.1.1 BR/EDR topology ......................................................... 294
4.1.2 LE topology .................................................................. 297
4.2 Operational procedures and modes ............................................ 299
4.2.1 BR/EDR procedures .................................................... 299
4.2.1.1 Inquiry (discovering) procedure ................... 299
4.2.1.2 Paging (connecting) procedure .................... 300
4.2.1.3 Connected mode .......................................... 300
4.2.1.4 Hold mode .................................................... 301
4.2.1.5 Sniff mode .................................................... 301
4.2.1.6 [This section is no longer used] ................... 301
4.2.1.7 Role switch procedure .................................. 301
4.2.1.8 Enhanced Data Rate .................................... 302
4.2.1.9 Connectionless Peripheral Broadcast mode 302
4.2.2 LE procedures ............................................................. 303
4.2.2.1 Device filtering procedure ............................ 303
4.2.2.2 Advertising procedure .................................. 303
4.2.2.3 Scanning procedure ..................................... 304
4.2.2.4 Discovering procedure ................................. 305
4.2.2.5 Connecting procedure .................................. 305
4.2.2.6 Connected mode .......................................... 306
4.2.2.7 Periodic advertising procedure .................... 307

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 1, Part A Page 221
Architecture

4.2.2.8 Periodic advertising synchronization

procedure ..................................................... 307
4.2.2.9 Periodic advertising synchronized mode ..... 308
4.2.2.10 Decision-based scanning ............................. 308
4.2.3 [This section is no longer used] ................................... 308

5 Security overview ..................................................................................... 309

5.1 Security architecture ................................................................... 309
5.2 BR/EDR Secure Simple Pairing .................................................. 311
5.2.1 Security goals .............................................................. 312
5.2.2 Passive eavesdropping protection ............................... 312
5.2.3 Man-in-the-middle protection ....................................... 313
5.2.4 Association models ...................................................... 313
5.2.4.1 Numeric Comparison ................................... 314
5.2.4.2 Just Works ................................................... 314
5.2.4.3 Out of Band .................................................. 314
5.2.4.4 Passkey Entry .............................................. 315
5.2.4.5 Association model overview ......................... 316
5.3 Secure Connections Only mode ................................................. 316
5.4 LE security ................................................................................... 317
5.4.1 Association models ...................................................... 317
5.4.2 Key generation ............................................................ 317
5.4.3 Encryption .................................................................... 317
5.4.4 Signed Data ................................................................. 318
5.4.5 Privacy feature ............................................................. 318
5.4.6 Encrypted Advertising Data ......................................... 319
5.5 [This section is no longer used] ................................................... 320
5.6 Key generation between BR/EDR and LE physical transports ... 320

6 Bluetooth application architecture .......................................................... 321

6.1 Bluetooth profiles ........................................................................ 321
6.2 Generic Access Profile ................................................................ 321
6.3 Profile hierarchy .......................................................................... 322
6.4 Generic Attribute Architecture ..................................................... 323
6.4.1 Attribute Protocol ......................................................... 323
6.4.2 Generic Attribute Profile ............................................... 324
6.5 GATT-Based Profile hierarchy ..................................................... 324
6.5.1 Service ......................................................................... 325
6.5.2 Included services ......................................................... 326
6.5.3 Characteristic ............................................................... 326
6.6 [This section is no longer used] ................................................... 326

7 Coexistence and collocation ................................................................... 327

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 1, Part A Page 222
Architecture

7.1 Core features supporting coexistence and collocation ................ 327

7.2 Adaptive Frequency Hopping ...................................................... 328
7.3 Coexistence between Bluetooth Devices and Wireless
LAN Devices ................................................................................ 329
7.4 Mobile Wireless Standards (MWS) coexistence ......................... 329
7.5 Synchronizing Bluetooth with an external timing source ............. 332
7.6 Piconet clock adjustment ............................................................ 333
7.7 Slot Availability Mask (SAM) ....................................................... 334

8 Direction finding using Bluetooth Low Energy ...................................... 335

8.1 Angle of arrival (AoA) method ..................................................... 335
8.2 Angle of departure (AoD) method ............................................... 336

9 Channel Sounding using Bluetooth Low Energy .................................. 339

9.1 Channel Sounding procedure ..................................................... 339
9.2 Distance estimation based on phase and amplitude information 340
9.3 Distance estimation based on RTT packets ................................ 342
9.4 Security features ......................................................................... 343

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 1, Part A Page 223
Architecture

1 GENERAL DESCRIPTION

This Part of the specification provides an overview of the Bluetooth system architecture,
communication topologies, and data transport features. The text in this Part of the
specification is intended to provide an introduction to Bluetooth and does not cover
every detail or every corner case. In case of discrepancy with other parts of this
specification, the other text is to be relied on.

Bluetooth wireless technology is a short-range communications system intended to

replace the cable(s) connecting portable and/or fixed electronic devices. The key
features of Bluetooth wireless technology are robustness, low power consumption, and
low cost. Many features of the specification are optional, allowing product differentiation.

There are two forms of Bluetooth wireless technology systems: Basic Rate (BR) and
Low Energy (LE). Both systems include device discovery, connection establishment and
connection mechanisms. The Basic Rate system includes an optional Enhanced Data
Rate (EDR) extension. The Basic Rate system offers synchronous and asynchronous
connections with data rates of 721.2 kb/s for Basic Rate and 2.1 Mb/s for Enhanced
Data Rate. The LE system includes features designed to enable products that require
lower current consumption, lower complexity and lower cost than BR/EDR. The LE
system is also designed for use cases and applications with lower data rates and has
lower duty cycles. The LE system includes an optional 2 Mb/s physical layer data rate
and also offers isochronous data transfer in a connection-oriented and connectionless
mechanism that uses the isochronous transports. The LE system also includes the
optional modulation of tones used to convey information useful for distance estimation.
Depending on the use case or application, one system including any optional parts may
be more optimal than the other.

Devices implementing both systems can communicate with other devices implementing
both systems as well as devices implementing either system. Some profiles and use
cases will be supported by only one of the systems. Therefore, devices implementing
both systems have the ability to support the most use cases.

The Bluetooth core system consists of a Host and one or more Controllers. A Host is
a logical entity defined as all of the layers below the non-core profiles and above the
Host Controller interface (HCI). A Controller is a logical entity defined as all of the layers
below HCI. An implementation of the Host and Controller may contain the respective
parts of the HCI.

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 1, Part A Page 224
Architecture

An implementation of the Bluetooth Core has only one Controller which may be one of
the following configurations:

• a BR/EDR Controller including the Radio, Baseband, Link Manager and optionally
HCI.
• an LE Controller including the LE PHY, Link Layer and optionally HCI.
• a combined BR/EDR Controller portion and LE Controller portion (as identified in the
previous two bullets) into a single Controller.

Host Host Host

LE BR/EDR BR/EDR LE
Controller Controller Controller Controller

Figure 1.1: Bluetooth Host and Controller combinations: (from left to right): LE Only Controller, BR/EDR
only Controller, and BR/EDR/LE Controller

1.1 Overview of BR/EDR operation

The Basic Rate / Enhanced Data Rate (BR/EDR) radio (physical layer or PHY) operates
in the unlicensed ISM band at 2.4 GHz. The system employs a frequency hopping
transceiver to combat interference and fading and provides many FHSS carriers.
Basic Rate radio operation uses a shaped, binary frequency modulation to minimize
transceiver complexity. The symbol rate is 1 megasymbol per second (Msym/s)
supporting the bit rate of 1 megabit per second (Mb/s) or, with Enhanced Data Rate,
a gross air bit rate of 2 Mb/s or 3 Mb/s. These modes are known as Basic Rate and
Enhanced Data Rate respectively.

During typical operation a physical radio channel is shared by a group of devices

that are synchronized to a common clock and frequency hopping pattern. One device
provides the synchronization reference and is known as the Central. All other devices
synchronized to a Central’s clock and frequency hopping pattern are known as
Peripherals. A group of devices synchronized in this fashion form a piconet. This is
the fundamental form of communication in the Bluetooth BR/EDR wireless technology.

Devices in a piconet use a specific frequency hopping pattern, which is algorithmically

determined by certain fields in the Bluetooth address and clock of the Central. The
basic hopping pattern is a pseudo-random ordering of the 79 frequencies, separated by
1 MHz, in the ISM band. The hopping pattern can be adapted – on a per-Peripheral
basis – to exclude a portion of the frequencies that are used by interfering devices. The

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 1, Part A Page 225
Architecture

adaptive hopping technique improves Bluetooth co-existence with static (non-hopping)

ISM systems when they are co-located.

The physical channel is sub-divided into time units known as slots. Data is transmitted
between Bluetooth devices in packets that are positioned in these slots. When
circumstances permit, a number of consecutive slots may be allocated to a single
packet. Frequency hopping may take place between the transmission or reception of
packets. Bluetooth technology provides the effect of full duplex transmission through the
use of a Time-Division Duplex (TDD) scheme.

Above the physical channel there is a layering of links and channels and associated
control protocols. The hierarchy of channels and links from the physical channel
upwards is physical channel, physical link, logical transport, logical link and L2CAP
channel. These are discussed in more detail in Section 3.3 to Section 3.6 but are
introduced here to aid the understanding of the remainder of this section.

Typically within a physical channel, a physical link is formed between a Central and
one or more Peripherals. Exceptions to this include Inquiry scan and Page scan
physical channels, which have no associated physical link. The physical link provides
bidirectional packet transport between the Central and Peripherals, except in the case
of a Connectionless Peripheral Broadcast physical link. In that case, the physical link
provides a unidirectional packet transport from the Central to a potentially unlimited
number of Peripherals. Since a physical channel could include multiple Peripherals,
there are restrictions on which devices may form a physical link. There is a physical
link between each Peripheral and the Central. Physical links are not formed directly
between the Peripherals in a piconet.

The physical link is used as a transport for one or more logical links that support unicast
synchronous, asynchronous and isochronous traffic, and broadcast traffic. Traffic on
logical links is multiplexed onto the physical link by occupying slots assigned by a
scheduling function in the resource manager.

A control protocol for the baseband and physical layers is carried over logical links in
addition to user data. This is the Link Manager protocol (LMP). Devices that are active
in a piconet have a default asynchronous connection-oriented logical transport that is
used to transport the LMP protocol signaling. For historical reasons this is known as
the ACL logical transport. With the exception of Connectionless Peripheral Broadcast
devices, the primary ACL logical transport is the one that is created whenever a
device joins a piconet. Connectionless Peripheral Broadcast devices may join the
piconet purely to listen to Connectionless Peripheral Broadcast packets. In that case,
a Connectionless Peripheral Broadcast logical transport is created (also called a CPB
logical transport) and no ACL logical transport is required. For all devices, additional
logical transports may be created to transport synchronous data streams when required.

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 1, Part A Page 226
Architecture

The Link Manager function uses LMP to control the operation of devices in the piconet
and provide services to manage the lower architectural layers (radio and baseband).
The LMP protocol is carried on the primary ACL and Active Peripheral Broadcast logical
transports.

Above the baseband the L2CAP layer provides a channel-based abstraction to

applications and services. It carries out segmentation and reassembly of application
data and multiplexing and de-multiplexing of multiple channels over a shared logical
link. L2CAP has a protocol control channel that is carried over the default ACL logical
transport. Application data submitted to the L2CAP protocol may be carried on any
logical link that supports the L2CAP protocol.

1.2 Overview of Bluetooth Low Energy operation

Like the BR/EDR radio, the LE radio operates in the unlicensed 2.4 GHz ISM band. The
LE system employs a frequency hopping transceiver to combat interference and fading
and provides many FHSS carriers. LE radio operation uses a shaped, binary frequency
modulation, and optional amplitude shift keying modulation to minimize transceiver
complexity. LE uses terminology that differs from BR/EDR to describe supported PHYs
with regards to differences in modulation, coding that may be applied, and the resulting
data rates. The mandatory symbol rate is 1 megasymbol per second (Msym/s), where
1 symbol represents 1 bit therefore supporting a bit rate of 1 megabit per second
(Mb/s), which is referred to as the LE 1M PHY. The 1 Msym/s symbol rate may
optionally support error correction coding, which is referred to as the LE Coded PHY.
This may use either of two coding schemes: S=2, where 2 symbols represent 1 bit
therefore supporting a bit rate of 500 kb/s, and S=8, where 8 symbols represent 1 bit
therefore supporting a bit rate of 125 kb/s. An optional symbol rate of 2 Msym/s may
be supported, with a bit rate of 2 Mb/s, which is referred to as the LE 2M PHY, when
using a bandwidth-symbol time product (BT) of 0.5. An additional optional symbol rate
at 2 Msym/s using a BT of 2.0 is also supported when used for the purpose of distance
estimation, which is referred to as the LE 2M 2BT PHY. The 2 Msym/s symbol rate
supports uncoded data only. LE 1M, LE 2M, and 2M 2BT are collectively referred to as
the LE Uncoded PHYs. Section 3.2.2 describes this terminology in more detail.

The amplitude shift keying modulation scheme is employed to modulate tones for
the purpose of gathering information for distance estimation. Section 3.2.3 describes
amplitude shift keying in more detail.

LE employs two multiple access schemes: Frequency division multiple access (FDMA)
and time division multiple access (TDMA). A TDMA-based polling scheme is used in
which one device transmits a packet at a predetermined time and a corresponding
device responds with a packet after a predetermined interval.

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 1, Part A Page 227
Architecture

For the purposes of data transfer, 40 physical channels, separated by 2 MHz, are used
in the FDMA scheme. Three are used as primary advertising channels and 37 are used
as general-purpose channels (including as secondary advertising channels).

For the purpose of distance estimation, 72 physical channels, separated by 1 MHz, are
used in the FDMA scheme.

The physical channel is sub-divided into time units known as events. Data is transmitted
between LE devices in packets that are positioned in these events. The following types
of events exist: Advertising, Extended Advertising, Periodic Advertising, Connection,
Isochronous events (which are partitioned into BIS, BIG, CIS, and CIG events), and
Channel Sounding events.

Devices that transmit advertising packets on the advertising PHY channels are referred
to as advertisers. Devices that receive advertising packets on the advertising physical
channels without the intention to connect to the advertising device are referred to as
scanners. Transmissions on the advertising PHY channels occur in advertising events.
At the start of each advertising event, the advertiser sends an advertising packet
corresponding to the advertising event type. Depending on the type of advertising
packet, the scanner may make a request to the advertiser on the same advertising
PHY channel which may be followed by a response from the advertiser on the same
advertising PHY channel. The advertising PHY channel changes on the next advertising
packet sent by the advertiser in the same advertising event. The advertiser may end the
advertising event at any time during the event. Each advertising packet in an advertising
event uses a different advertising PHY channel. Each advertising event may use a
different order for the advertising PHY channels.

Advertising event Advertising event

Adv Adv Scanner Adv Adv Adv Adv

Adv Ch(k) Adv Ch(k+1) Adv Ch(k+2) Adv Ch(m) Adv Ch(m+1)

Figure 1.2: Advertising events

LE devices may fulfill the entire communication in the case of unidirectional or

broadcast communication between two or more devices using advertising events. LE
devices may also use advertising events to establish bi-directional connections with
another device and to establish asynchronous or isochronous periodic broadcasts.
Asynchronous periodic broadcasts may allow the advertiser to receive responses from

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 1, Part A Page 228
Architecture

one or more devices. These additional activities make use of the general purpose
channels in various ways.

Devices that need to form an ACL connection to another device listen for connectable
advertising packets. Such devices are referred to as initiators. If the advertiser is using
a connectable advertising event, an initiator may make a connection request using
the same advertising PHY channel on which it received the connectable advertising
packet. The advertising event is ended and connection events begin if the advertiser
receives and accepts the request for a connection be initiated. Once a connection is
established, the initiator becomes the Central in what is referred to as a piconet and the
advertising device becomes the Peripheral. Connection events are used to send data
packets between the Central and Peripherals. In connection events, channel hopping
occurs at the start of each connection event. Within a connection event, the Central
and Peripheral alternate sending data packets using the same data PHY channel. The
Central initiates the beginning of each connection event and can end each connection
event at any time.

Advertising event Connection event Connection event

Adv Initiator C→P P→C C→P P→C C→P P→C

Adv Ch(k) Data Ch(x) Data Ch(x+1)

Figure 1.3: Connection events

Devices in a piconet use a specific frequency hopping pattern, which is algorithmically

determined by a field contained in the connection request sent by an initiating device.
The hopping pattern used on the LE data channel is a pseudo-random ordering of the
37 frequencies in the ISM band. The hopping pattern used in a Channel Sounding
procedure is a pseudo-random ordering of 72 frequencies in the ISM band. The hopping
pattern can be adapted to exclude a portion of the frequencies that are used by
interfering devices. The adaptive hopping technique improves Bluetooth co-existence
with static (non-hopping) ISM systems when these systems are co-located and have
access to information about the local radio environment. A Peripheral can classify
frequencies as good and bad and provide that information to the Central. The Central
can take this information into consideration while adapting the hopping pattern.

Using an ACL connection, a Central can establish one or more isochronous connections
that use the isochronous physical channel. An isochronous connection is used to
transfer isochronous data between the Central and a Peripheral by using a logical
transport, which is referred to as a Connected Isochronous Stream (CIS). A CIS

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 1, Part A Page 229
Architecture

consists of CIS events that occur at regular intervals (designated ISO_Interval). Every
CIS event consists of one or more subevents. In each subevent, the Central transmits
once and the Peripheral responds. If the Central and Peripheral have completed
transferring the scheduled isochronous data in a CIS event, all remaining subevents in
that event will have no radio transmissions and the event is closed. Each subevent uses
a PHY channel which is determined by using the channel selection algorithm. The PHY
channel that is used for a subevent is marked as ISO Ch(eventcount, subeventcount),
as shown in Figure 1.4.

Event x Event x+1

Subevent 1 Subevent 2 Subevent 1 Subevent 2

ISO Ch(x,1) ISO Ch(x,2) ISO Ch(x+1,1) ISO Ch(x+1,2)

C→P P→C C→P P→C C→P P→C C→P P→C

ISO_Interval

Figure 1.4: CIS events and subevents

A device can use an isochronous physical channel to broadcast isochronous data by

using isochronous connectionless logical transports. An isochronous connectionless
logical transport is referred to as a Broadcast Isochronous Stream (BIS). A BIS consists
of BIS events that occur at regular intervals (designated ISO_Interval). Every BIS event
consists of one or more subevents. In every subevent, a broadcasting device transmits
an isochronous data packet. Each subevent uses a PHY channel that is determined
using the channel selection algorithm.

A device can transmit several BISes with synchronized timing; this is referred to as
a Broadcast Isochronous Group (BIG). The various BIS events together form a BIG
event. The device can also use the isochronous physical channel to broadcast control
information in a Control subevent, which is transmitted at the end of all subevents for a
BIG, as shown in Figure 1.5.

A device that transmits BIG events also transmits periodic advertisement events
that contain synchronization information of the BIG. A device that is scanning can
synchronize to those periodic advertising events and receive the synchronization
information. Using this synchronization information, the device can synchronize to one
or more BISes in the BIG and receive the isochronous data. Figure 1.5 shows two
BIG events: one with and one without a Control subevent. Each subevent uses a PHY
channel marked as ISO Ch(eventcount, subeventcount), as shown in Figure 1.5.

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 1, Part A Page 230
Architecture

BIG Event x BIG Event x+1

BIS Event x BIS Event x+1

Tx Tx Tx Tx Tx Tx Tx

Control
Subevent 1 Subevent 2 Subevent 3 Subevent 1 Subevent 2 Subevent 3
subevent
ISO Ch(x,1) ISO Ch(x,2) ISO Ch(x,3) ISO Ch(x+1,1) ISO Ch(x+1,2) ISO Ch(x+1,3)
ISO Ch(x+1,1)
ISO_Interval

Figure 1.5: BIG and BIS events, BIS subevents, and Control subevent

Devices can use the LE Channel Sounding physical link to exchange information that
can later be used for distance estimation calculations. A Channel Sounding procedure
(and hence, the first Channel Sounding event within that procedure) is started at an
offset from an ACL connection event anchor point. A Channel Sounding procedure
exists only for a limited duration, and consists of Channel Sounding events, subevents,
and steps. Channel Sounding events may contain one or more subevents. Channel
Sounding subevents contain two or more Channel Sounding steps. Channel Sounding
steps contain bilateral exchanges between the two Channel Sounding peers known as
the initiator and reflector. The Channel Sounding initiator transmits first in each step,
followed by one or more transmissions from the Channel Sounding reflector. These
transmissions may be a packet-based GFSK-modulated exchange or a tone-based,
amplitude shift keying modulated exchange, or both.

The general structure of Channel Sounding events and subevents is shown in

Figure 1.6.

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 1, Part A Page 231
Architecture

Figure 1.6: Channel Sounding events and subevents

Each exchange within a Channel Sounding step contains information that can be
measured. These measurements can be further processed to produce a distance
estimate. The step content is discussed in more detail in [Vol 6] Part H, Section 4.3.
These exchanges also carry security-related information that may assist in the detection
of an external attacker who is attempting to indirectly manipulate the measured results,
which could in turn affect the distance estimate. The Channel Sounding step exchanges
use a PHY channel that is determined using a channel selection algorithm. For Channel
Sounding, this channel selection algorithm, as well as other security-related information,
is seeded using a Deterministic Random Bit Generator (DRBG). The security key
material for this DRBG is known only by the respective initiator and reflector devices.

Above the physical channel there are concepts of links, channels and associated control
protocols. The hierarchy is physical channel, physical link, logical transport, logical link,
and L2CAP channel. These are discussed in more detail in Section 3.3 to Section 3.6
but are introduced here to aid the understanding of the remainder of this section.

Within a physical channel, a physical link is formed between devices. The active
physical link provides bidirectional packet transport between the Central and
Peripherals. Centrals may have physical links to more than one Peripheral at a time and
Peripherals may have physical links to more than one Central at a time. A device may
be Central and Peripheral in different piconets at the same time. Role changes between
a Central and Peripheral are not supported. The advertising and periodic physical links
provide a unidirectional packet transport from the advertiser to a potentially unlimited
number of scanners or initiators.

The physical link is used as a transport for one or more logical links that support
asynchronous traffic. Traffic on logical links is multiplexed onto the physical link
assigned by a scheduling function in the resource manager.

A control protocol for the link and physical layers is carried over logical links in addition
to user data. This is the Link Layer protocol (LL). Devices that are active in a piconet

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 1, Part A Page 232
Architecture

have a default LE asynchronous connection logical transport (LE ACL) that is used
to transport the LL protocol signaling. The default LE ACL is the one that is created
whenever a piconet is created.

The Link Layer function uses the LL protocol to control the operation of devices in the
piconet and provide services to manage the lower architectural layers (PHY and LL).

Overall, a piconet consists of one ACL logical transport over the active physical link plus
zero or more CIS logical transports over the isochronous physical link(s). In addition,
zero or more transitory Channel Sounding procedures may exist over the Channel
Sounding physical link.

Just as in BR/EDR, above the Link Layer the L2CAP layer provides a channel-
based abstraction to applications and services. It carries out fragmentation and de-
fragmentation of application data and multiplexing and de-multiplexing of multiple
channels over a shared logical link. L2CAP has a protocol control channel that is carried
over the primary ACL logical transport.

In addition to L2CAP, LE provides two additional protocol layers that reside on top
of L2CAP. The Security Manager protocol (SMP) uses a fixed L2CAP channel to
implement the security functions between devices. The other is the Attribute Protocol
(ATT) that provides a method to communicate small amounts of data over a fixed
L2CAP channel. The Attribute Protocol is also used by devices to determine the
services and capabilities of other devices. The Attribute Protocol may also be used
over BR/EDR.

The LE radio provides a means for detecting the relative direction of another LE radio
by using the Angle of Arrival (AoA) or Angle of Departure (AoD) method.

1.3 [This section is no longer used]

1.4 Nomenclature

Where the following terms appear in the specification they have the meaning given in
Table 1.1.

Active Peripheral Broadcast The logical transport that is used to transport L2CAP user traffic
(APB) and some kinds of LMP traffic to all active devices in the piconet
over the BR/EDR Controller. See Section 3.5.4.4
Ad Hoc Network A network typically created in a spontaneous manner. An ad hoc
network requires no formal infrastructure and is limited in tempo-
ral and spatial extent.
Advertiser A Bluetooth Low Energy device that broadcasts advertising pack-
ets during advertising events on advertising channels

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 1, Part A Page 233
Architecture

Advertising event A series of between one and three advertising packets on differ-
ent advertising physical channels sent by an advertiser.
Advertising Packet A packet containing an advertising PDU. See [Vol 6] Part B, Sec-
tion 2.3.1
Angle of Arrival (AoA) Angle of Arrival is the relative direction at which a propagating RF
wave that was transmitted by a single antenna is incident on an
antenna array.
Angle of Departure (AoD) Angle of Departure is the relative direction from which a propa-
gating RF wave that was transmitted using an antenna array is
incident on another antenna.
BD_ADDR The Bluetooth Device Address, BD_ADDR, is used to identify a
Bluetooth device.
Bluetooth Bluetooth is a wireless communication link, operating in the un-
licensed ISM band at 2.4 GHz using a frequency hopping trans-
ceiver. It allows real-time AV and data communications between
Bluetooth Hosts. The link protocol is based on time slots.
Bluetooth Baseband The part of the Bluetooth system that specifies or implements
the medium access and physical layer procedures to support the
exchange of real-time voice, data information streams, and ad
hoc networking between Bluetooth Devices.
Bluetooth Clock A 28 bit clock internal to a BR/EDR Controller sub-system that
ticks every 312.5 µs. The value of this clock defines the slot
numbering and timing in the various physical channels.
Bluetooth Controller A generic term referring to a Controller.
Bluetooth Device A device that is capable of short-range wireless communications
using the Bluetooth system.
Bluetooth Device Address A 48 bit address used to identify each Bluetooth device.
BR/EDR Bluetooth basic rate (BR) and enhanced data rate (EDR).
BR/EDR Controller A term referring to the Bluetooth Radio, Baseband, Link Manager,
and HCI layers.
BR/EDR Piconet Physical Chan- A Channel that is divided into time slots in which each slot is
nel related to an RF hop frequency. Consecutive hops normally corre-
spond to different RF hop frequencies and occur at a standard
hop rate of 1600 hops per second. These consecutive hops fol-
low a pseudo-random hopping sequence, hopping through a 79
RF channel set, or optionally fewer channels when Adaptive Fre-
quency Hopping (AFH) is in use.
BR/EDR/LE Bluetooth basic rate (BR), enhanced data rate (EDR) and low
energy (LE).
C-plane Control plane
Channel Either a physical channel or an L2CAP channel, depending on the
context.

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 1, Part A Page 234
Architecture

Channel Sounding A Bluetooth Low Energy feature that measures and distributes
information that can be used to approximate distances between
devices.
Channel Sounding event A group of Channel Sounding subevents that are anchored from a
common LE connection event.
Channel Sounding procedure A group of Channel Sounding events that are sequenced serially
for the purpose of gathering information useful for estimating the
distance between two devices.
Channel Sounding step In Channel Sounding, an individual exchange between two devi-
ces.
Channel Sounding subevent A group of Channel Sounding steps that are associated with a
specific coherent timing.
Connect (to service) The establishment of a connection to a service. If not already
done, this also includes establishment of a physical link, logical
transport, logical link and L2CAP channel.
Connectable device A BR/EDR device in range that periodically listens on its page
scan physical channel and will respond to a page on that channel.
An LE device that is advertising using a connectable advertising
event.
Connected devices Two BR/EDR devices and with a physical link between them.
Connecting A phase in the communication between devices when a connec-
tion between the devices is being established. (Connecting phase
follows after the link establishment phase is completed.)
Connection A connection between two peer applications or higher layer proto-
cols mapped onto an L2CAP channel.
Connection establishment A procedure for creating a connection mapped onto a channel.
Connection event A series of one or more pairs of interleaving data packets sent be-
tween a Central and a Peripheral on the same physical channel.
Connectionless Peripheral Broad- A feature that enables a Central to broadcast information to an
cast (CPB) unlimited number of Peripherals.
Connectionless Peripheral Broad- A Bluetooth device that receives broadcast information from a
cast Receiver Connectionless Peripheral Broadcast Transmitter. The device is a
Peripheral of the piconet.
Connectionless Peripheral Broad- A Bluetooth device that sends Connectionless Peripheral Broad-
cast Transmitter cast messages for reception by one or more Connectionless Pe-
ripheral Broadcast receivers. The device is the Central of the
piconet.
Controller A collective term referring to all of the layers below HCI.
Coverage area The area where two Bluetooth devices can exchange messages
with acceptable quality and performance.
Creation of a secure connection A procedure of establishing a connection, including authentication
and encryption.

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 1, Part A Page 235
Architecture

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 authen-
tication, or pairing, when a link key is not available.
Device discovery A procedure for retrieving the Bluetooth Device Address, clock,
and Class of Device from discoverable devices.
Discoverable device A BR/EDR device in range that periodically listens on an inquiry
scan physical channel and will respond to an inquiry on that chan-
nel. An LE device in range that is advertising with a connectable
or scannable advertising event with a discoverable flag set in the
advertising data. This device is in the discoverable mode.
Discoverable Mode A Bluetooth device that is performing inquiry scans in BR/EDR or
advertising with a discoverable or connectable advertising event
with a discoverable flag set in LE.
Discovery procedure A Bluetooth device that is carrying out the inquiry procedure in
BR/EDR or scanning for advertisers using a discoverable or con-
nectable advertising event with a discoverable flag set in LE.
HCI The Host Controller interface (HCI) provides a command inter-
face to the baseband Controller and link manager and access to
hardware status and control registers. This interface provides a
uniform method of accessing the Bluetooth baseband capabilities.
Host A logical entity defined as all of the layers below the non-core pro-
files and above the Host Controller interface (HCI); i.e., the layers
specified in Volume 3. A Bluetooth Host attached to a Bluetooth
Controller may communicate with other Bluetooth Hosts attached
to their Controllers as well.
Initiator From the perspective of an advertising bearer, a Bluetooth Low
Energy device that listens on advertising physical channels for
connectable advertising events to form connections.
From the perspective of Channel Sounding, the device that trans-
mits first within a Channel Sounding step.
Inquiring device A BR/EDR device that is carrying out the inquiry procedure. This
device is performing the discovery procedure.
Inquiry A procedure where a Bluetooth device transmits inquiry messag-
es and listens for responses in order to discover the other Blue-
tooth devices that are within the coverage area.
Inquiry scan A procedure where a Bluetooth device listens for inquiry messag-
es received on its inquiry scan physical channel.
Interoperability The ability of two or more devices to exchange information and to
use the information that has been exchanged.
Isochronous data Information in a stream where each information entity in the
stream is bound by a time relationship to previous and successive
entities.
Known device A Bluetooth device for which at least the BD_ADDR is stored.

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 1, Part A Page 236
Architecture

L2CAP Logical Link Control and Adaptation Protocol

L2CAP Channel A logical connection on L2CAP level between two devices serving
a single application or higher layer protocol.
L2CAP Channel establishment A procedure for establishing a logical connection on L2CAP level.
LE Bluetooth Low Energy
Link Shorthand for a logical link.
Link establishment A procedure for establishing the default ACL link and hierarchy of
links and channels between devices.
Link key A secret key that is known by two devices and is used to authenti-
cate the link.
LMP authentication An LMP level procedure for verifying the identity of a remote
device.
LMP pairing A procedure that authenticates two devices and creates a com-
mon link key that can be used as a basis for a trusted relationship
or a (single) secure connection.
Logical link The lowest architectural level used to offer independent data
transport services to clients of the Bluetooth system.
Logical transport Shared acknowledgment protocol and link identifiers between dif-
ferent logical links.
Name discovery A procedure for retrieving the user-friendly name (the Bluetooth
Device Name) of a connectable device.
Packet Format of aggregated bits that are transmitted on a physical
channel.
Page The initial phase of the connection procedure where a device
transmits a train of page messages until a response is received
from the target device or a time-out occurs.
Page scan A procedure where a device listens for page messages received
on its page scan physical channel.
Paging device A Bluetooth device that is carrying out the page procedure.
Paired device A Bluetooth device for which a link key has been created (either
before connection establishment was requested or during con-
necting phase).
Passkey A 6-digit number used to authenticate connections when Secure
Simple Pairing is used.
Periodic advertising synchroniza- The control information describing a periodic advertisement that
tion information a Bluetooth Low Energy device uses to synchronize to the adver-
tisement it describes.
Physical Channel Characterized by synchronized occupancy of a sequence of RF
carriers by one or more devices. A number of physical channel
types exist with characteristics defined for their different purpo-
ses.

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 1, Part A Page 237
Architecture

Physical link A Baseband or Link Layer level connection between two devices.
Physical Transport PHY packet transmission and/or reception on an RF channel us-
ing one or more modulation schemes.
Piconet A collection of devices (up to eight devices in BR/EDR, exactly
two devices in LE) occupying a shared physical channel where
one of the devices is the Piconet Central and the remaining devi-
ces are connected to it.
Piconet Central The BR/EDR device in a piconet whose Bluetooth Clock and
Bluetooth Device Address are used to define the piconet physical
channel characteristics.
The LE device in a piconet which initiates the creation of the
piconet, chooses the Access Address that identifies the piconet,
and transmits first in each connection event.
Piconet Peripheral Any BR/EDR device in a piconet that is not the Piconet Central,
but is connected to the Piconet Central.
The LE device in a piconet which is not the Central but communi-
cates with it.
PIN A user-friendly number that can be used to authenticate connec-
tions to a device before pairing has taken place.
Profile Broadcast Data (PBD) A logical link that carries data from a Connectionless Peripheral
Broadcast Transmitter to one or more
Connectionless Peripheral Broadcast Receivers.
Pseudo-Noise Bit Sequence A series of bits that are generated randomly.
Reflector In Channel Sounding, the device that transmits second within a
Channel Sounding step in response to a transmission from an
initiator.
Resolving List A list of records used to generate and resolve Resolvable Private
Addresses. Each record contains a local Identity Resolving Key, a
peer Identity Resolving Key, and a peer Identity Address.
Round-Trip Time The time it takes for a packet to travel from an originating device
to a responding device and back again to the originating device.
Scanner A Bluetooth Low Energy device that listens for advertising events
on the advertising physical channels.
Scatternet Two or more piconets that have one or more devices in common.
Service discovery Procedures for querying and browsing for services offered by or
through another Bluetooth device.
Service Layer Protocol A protocol that uses an L2CAP channel for transporting PDUs.
Silent device A Bluetooth enabled device appears as silent to a remote device
if it does not respond to inquiries made by the remote device.
Synchronization Scan Physical A physical channel that enables a Peripheral to receive synchro-
Channel nization train packets from a Central.

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 1, Part A Page 238
Architecture

Synchronization Train A series of packets transmitted on a set of fixed frequencies that

deliver sufficient information for a receiving device to start receiv-
ing corresponding Connectionless Peripheral Broadcast packets
or to recover the current piconet clock after missing a Coarse
Clock Adjust.
Tick (BR/EDR) the time between changes of the value of the Bluetooth
Clock: 312.5 µs.
U-plane User plane
Unknown device A Bluetooth device for which no information (Bluetooth Device
Address, link key or other) is stored.

Table 1.1: Nomenclature

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 1, Part A Page 239
Architecture

2 CORE SYSTEM ARCHITECTURE

The Bluetooth Core system consists of a Host and a Controller. A minimal

implementation of the Bluetooth BR/EDR core system covers the four lowest layers
and associated protocols defined by the Bluetooth specification as well as one
common service layer protocol; the Service Discovery Protocol (SDP) and the overall
profile requirements are specified in the Generic Access Profile (GAP). A minimal
implementation of a Bluetooth LE only core system covers the four lowest layers and
associated protocols defined by the Bluetooth specification as well as two common
service layer protocols; the Security Manager (SM) and Attribute Protocol (ATT) and the
overall profile requirements are specified in the Generic Attribute Profile (GATT) and
Generic Access Profile (GAP). Implementations combining Bluetooth BR/EDR and LE
include both of the minimal implementations described above.

A complete Bluetooth application requires a number of additional service and higher

layer protocols that are defined in the Bluetooth specification, but are not described
here. The core system architecture is shown in Figure 2.1.

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 1, Part A Page 240
Architecture

ATT/
SMP SDP
GAP GATT

Channel Manager

L2cap Resource
Manager
L2CAP

Host

HCI
C/E SCO ACL C/E C/E ACL ISO C/E

Link Link Channel

ISOAL
Manager Manager Sounding

Device
Manager Baseband Resource Manager

Link Controller Link Controller

BR/EDR Radio and LE Radio (PHY)

BR/EDR Controller LE Controller

C-plane and control services C/E Command/Event SCO Synchronous (SCO, eSCO) data path
Broadcast Isochronous Stream (BIS)
U-plane and data traffic ACL Asynchronous (ACL) data path ISO
Connected Isochronous Stream (CIS)

Figure 2.1: Bluetooth core system architecture

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 1, Part A Page 241
Architecture

Figure 2.1 shows the Core blocks, each with its associated communication protocol.
Link Manager, Link Controller and BR/EDR Radio blocks comprise a BR/EDR
Controller. Link Manager, Link Controller and LE Radio blocks comprise an LE
Controller. L2CAP, SDP and GAP blocks comprise a BR/EDR Host. L2CAP, SMP,
Attribute Protocol, GAP and Generic Attribute Profile (GATT) blocks comprise an LE
Host. A BR/EDR/LE Host combines the set of blocks from each respective Host. This
is a common implementation involving a standard physical communication interface
between the Controller and the Host. Although this interface is optional the architecture
is designed to allow for its existence and characteristics. The Bluetooth specification
enables interoperability between independent Bluetooth systems by defining the
protocol messages exchanged between equivalent layers, and also interoperability
between independent Bluetooth Controllers and Bluetooth Hosts by defining a common
interface between Bluetooth Controllers and Bluetooth Hosts.

A number of functional blocks and the path of services and data between them are
shown. The functional blocks shown in the diagram provide a set of conceptual entities
that are used when describing the requirements of the specification; in general the
Bluetooth specification does not define the details of implementations except where this
is required for interoperability. Thus the functional blocks in Figure 2.1 are shown in
order to aid description of the system behavior. An implementation may be different from
the system shown in Figure 2.1.

Standard interactions are defined for all inter-device operation, where Bluetooth devices
exchange protocol signaling according to the Bluetooth specification. The Bluetooth
core system protocols are the Radio (PHY) protocol, Link Control (LC) and Link
Manager (LM) protocol or Link Layer (LL) protocol, and Logical Link Control and
Adaptation protocol (L2CAP), all of which are fully defined in subsequent parts of
the Bluetooth specification. In addition, the Service Discovery protocol (SDP) and the
Attribute Protocol (ATT) are service layer protocols that may be required by some
Bluetooth applications.

The Bluetooth core system offers services through a number of service access points
that are shown in the diagram as ellipses. These services consist of the basic primitives
that control the Bluetooth core system. The services can be split into three types. There
are device control services that modify the behavior and modes of a Bluetooth device,
transport control services that create, modify and release traffic bearers (channels and
links), and data services that are used to submit data for transmission over traffic
bearers. It is common to consider the first two as belonging to the C-plane and the last
as belonging to the U-plane.

A service interface to the Bluetooth Controller is defined such that the Controller may
be considered a standard part. In this configuration the Bluetooth Controller operates
the lowest four layers. The Bluetooth Host operates the L2CAP layer and other
higher layers. The standard interface is called the Host Controller interface (HCI) and

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 1, Part A Page 242
Architecture

its service access points are represented by the ellipses on the upper edge of the
Bluetooth Controller in Figure 2.1. Implementation of this standard service interface is
optional.

As the Bluetooth architecture is defined with the possibility of separate Host and
Controller(s) communicating through one or more HCI transports, a number of general
assumptions are made. Bluetooth Controllers are assumed to have limited data
buffering capabilities in comparison with the Host. Therefore the L2CAP layer is
expected to carry out some simple resource management when submitting L2CAP
PDUs to the Controller for transport to a peer device. This includes segmentation
of L2CAP SDUs into more manageable PDUs and then the fragmentation of PDUs
into start and continuation packets of a size suitable for the Controller buffers, and
management of the use of Controller buffers to ensure availability for channels with
Quality of Service (QoS) commitments.

The BR/EDR Baseband and LE Link Layer provide the basic acknowledgment/repeat
request (ARQ) protocol in Bluetooth. The L2CAP layer can optionally provide a further
error detection and retransmission to the L2CAP PDUs. This feature is recommended
for applications with requirements for a low probability of undetected errors in the user
data. A further optional feature of L2CAP is a window-based flow control that can be
used to manage buffer allocation in the receiving device. Both of these optional features
augment the QoS performance in certain scenarios. Not all of the L2CAP capabilities
are available when using the LE system.

Although these assumptions are not always required for embedded Bluetooth
implementations that combine all layers in a single system, the general architectural
and QoS models are defined with these assumptions in mind, in effect a lowest common
denominator.

Automated conformance testing of implementations of the Bluetooth core system is

required. This is achieved by allowing the tester to control the implementation through
the PHY interface, test interfaces such as Direct Test Mode (DTM), and test commands
and events over HCI which are only required for conformance testing.

The tester exchanges messages with the implementation under test (IUT) through the
PHY interface to ensure the correct responses to requests from remote devices. The
tester controls the IUT through HCI, DTM, or test commands to cause the IUT to
originate exchanges through the PHY interface so that these can also be verified as
compliant.

2.1 Core architectural blocks

This section describes the function and responsibility of each of the blocks shown in
Figure 2.1. An implementation is not required to follow the architecture described above,

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 1, Part A Page 243
Architecture

though every implementation is still required to conform to the protocol specifications,

behaviors, and other requirements specified in subsequent parts of the Bluetooth
specification.

2.1.1 Host architectural blocks

2.1.1.1 Channel manager

The channel manager is responsible for creating, managing and closing L2CAP
channels for the transport of service protocols and application data streams. The
channel manager uses the L2CAP protocol to interact with a channel manager on a
remote (peer) device to create these L2CAP channels and connect their endpoints
to the appropriate entities. The channel manager interacts with its local link manager
to create new logical links (if necessary) and to configure these links to provide the
required quality of service for the type of data being transported.

2.1.1.2 L2CAP resource manager

The L2CAP resource manager block is responsible for managing the ordering of
submission of PDU fragments to the baseband and some relative scheduling between
channels to ensure that L2CAP channels with QoS commitments are not denied access
to the physical channel due to Controller resource exhaustion. This is required because
the architectural model does not assume that a Controller has limitless buffering, or that
the HCI is a pipe of infinite bandwidth.

L2CAP Resource Managers may also carry out traffic conformance policing to check
that applications are submitting L2CAP SDUs within the bounds of their negotiated
QoS settings. The general Bluetooth data transport model assumes well-behaved
applications, and does not define how an implementation is expected to deal with this
problem.

2.1.1.3 Security Manager Protocol

The Security Manager Protocol (SMP) is the peer-to-peer protocol used to generate
encryption keys and identity keys. The protocol operates over a dedicated fixed L2CAP
channel. The SMP block also manages storage of the encryption keys and identity keys
and is responsible for generating random addresses and resolving random addresses to
known device identities. The SMP block interfaces with the Controller to provide stored
keys used for encryption and authentication during the encryption or pairing procedures.

This block is only used in LE systems. Similar functionality in the BR/EDR system is
contained in the Link Manager block in the Controller. SMP functionality is in the Host
on LE systems to reduce the implementation cost of the LE only Controllers.

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 1, Part A Page 244
Architecture

2.1.1.4 Attribute Protocol

The Attribute Protocol (ATT) block implements the peer-to-peer protocol between an
ATT Server and an ATT Client. The ATT Client communicates with an ATT Server
on a remote device over a dedicated fixed L2CAP channel. The ATT Client sends
commands, requests, and confirmations to the ATT Server. The ATT Server sends
responses, notifications and indications to the client. These ATT Client commands and
requests provide a means to read and write values of attributes on a peer device with
an ATT Server.

2.1.1.5 [This section is no longer used]

2.1.1.6 Generic Attribute Profile

The Generic Attribute Profile (GATT) block represents the functionality of the ATT
Server and, optionally, the ATT Client. The profile describes the hierarchy of services,
characteristics and attributes used in the ATT Server. The block provides interfaces
for discovering, reading, writing and indicating of service characteristics and attributes.
GATT is used on LE devices for LE profile service discovery.

2.1.1.7 Generic Access Profile

The Generic Access Profile (GAP) block represents the base functionality common to
all Bluetooth devices such as modes and access procedures used by the transports,
protocols and application profiles. GAP services include device discovery, connection
modes, security, authentication, association models and service discovery.

2.1.1.8 Service Discovery Protocol

The Service Discovery Protocol (SDP) provides a mechanism to allow clients to search
for needed services based on specific attributes of the service, including search based
on class of service and browsing the entire database. SDP is used on BR/EDR devices
for BR/EDR profile service discovery.

SDP focuses on discovering services available from or through Bluetooth devices. It

does not define methods for accessing services once they are discovered with SDP; the
access method is service-specific.

2.1.2 BR/EDR/LE Controller architectural blocks

In implementations where the BR/EDR and LE systems are combined, the architectural
blocks may be shared between systems or each system may have their own
instantiation of the block.

2.1.2.1 Device manager

The device manager is the functional block in the baseband that controls the general
behavior of the Bluetooth device. It is responsible for all operations of the Bluetooth

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 1, Part A Page 245
Architecture

system that are not directly related to data transport, such as inquiring for the presence
of nearby Bluetooth devices, connecting to Bluetooth devices, or making the local
Bluetooth device discoverable or connectable by other devices.

The device manager requests access to the transport medium from the baseband
resource Controller in order to carry out its functions.

The device manager also controls local device behavior implied by a number of the HCI
commands, such as managing the device local name, any stored link keys, and other
functionality.

2.1.2.2 Link manager

The link manager is responsible for the creation, modification and release of logical
links (and, if required, their associated logical transports), as well as the update of
parameters related to physical links between devices. The link manager achieves this
by communicating with the link manager in remote Bluetooth devices using the Link
Manager Protocol (LMP) in BR/EDR and the Link Layer Protocol (LL) in LE.

The LM or LL protocol allows the creation of new logical links and logical transports
between devices when required, as well as the general control of link and transport
attributes such as the enabling of encryption on the logical transport, the adapting of
transmit power on the physical link, or the adjustment of QoS settings in BR/EDR for a
logical link.

2.1.2.3 Baseband resource manager

The baseband resource manager is responsible for all access to the radio medium.
It has two main functions. At its heart is a scheduler that grants time on the physical
channels to all of the entities that have negotiated an access contract. The other main
function is to negotiate access contracts with these entities. An access contract is
effectively a commitment to deliver a certain QoS that is required in order to provide a
user application with an expected performance.

The access contract and scheduling function must take account of any behavior that
requires use of the Controller. This includes (for example) the normal exchange of
data between connected devices over logical links, and logical transports, as well as
the use of the radio medium to carry out inquiries, make connections, be discoverable
or connectable, or to take readings from unused carriers during the use of adaptive
frequency hopping mode.

In some cases in BR/EDR systems the scheduling of a logical link results in changing
a logical link to a different physical channel from the one that was previously used. This
may be (for example) due to involvement in scatternet, a periodic inquiry function, or
page scanning. When the physical channels are not time slot aligned, then the resource

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 1, Part A Page 246
Architecture

manager also accounts for the realignment time between slots on the original physical
channel and slots on the new physical channel. In some cases the slots will be naturally
aligned due to the same device clock being used as a reference for both physical
channels.

2.1.2.4 Link Controller

The Link Controller is responsible for the encoding and decoding of Bluetooth packets
from the data payload and parameters related to the physical channel, logical transport
and logical link.

The Link Controller carries out the link control protocol signaling in BR/EDR and Link
Layer protocol in LE (in close conjunction with the scheduling function of the resource
manager), which is used to communicate flow control and acknowledgment and
retransmission request signals. The interpretation of these signals is a characteristic of
the logical transport associated with the baseband packet. Interpretation and control of
the link control signaling is normally associated with the resource manager’s scheduler.

2.1.2.5 PHY

The PHY block is responsible for transmitting and receiving packets of information on
the physical channel. A control path between the baseband and the PHY block allows
the baseband block to control the timing and frequency carrier of the PHY block. The
PHY block transforms a stream of data to and from the physical channel and the
baseband into required formats.

2.1.2.6 Isochronous Adaptation Layer

The Isochronous Adaptation Layer (ISOAL) enables the upper layer to send or receive
isochronous data to or from the Link Layer in a flexible way such that the size and
interval of data packets in the upper layer can be different from the size and interval
of data packets in the Link Layer. The ISOAL uses fragmentation/recombination or
segmentation/reassembly operations to convert upper layer data units into lower layer
data units (or the other way around).

2.1.2.7 Channel Sounding

The Channel Sounding block is responsible for creation, modification, and release
of Channel Sounding physical links. Channel Sounding related capabilities are first
exchanged between peer Channel Sounding blocks and procedure configuration
parameters are established. Security parameters are then set up. Thereafter, Channel
Sounding exchanges are coordinated via this block, which includes Channel Sounding
event, subevent, and step timing. Step transmission and reception is also generated
and coordinated through this block. This data is then sent to the Host. From these
exchanges, data is collected that may be used by the Host for distance estimation and
attack detection.

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 1, Part A Page 247
Architecture

2.1.3 [This section is no longer used]

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 1, Part A Page 248
Architecture

3 TRANSPORT ARCHITECTURE

The Bluetooth data transport system follows a layered architecture. This description of
the Bluetooth system describes the Bluetooth core transport layers up to and including
L2CAP channels. All Bluetooth operational modes follow the same generic transport
architecture, which is shown in Figure 3.1.

L2CAP L2CAP Channels

Layer

Logical Links
Logical
Layer
Logical Transports

Physical Links

Physical
Physical Channels
Layer
Physical Transports

Figure 3.1: Bluetooth generic data transport architecture

For efficiency and legacy reasons, the Bluetooth transport architecture includes a sub-
division of the logical layer, distinguishing between logical links and logical transports.
This sub-division provides a general (and commonly understood) concept of a logical
link that provides an independent transport between two or more devices. The logical
transport sub-layer is required to describe the inter-dependence between some of the
logical link types (mainly for reasons of legacy behavior).

The ACL, SCO, and eSCO connections are considered as logical transports but
often behave as separate physical links. However, they are not as independent as
might be desired, due to their shared use of resources such as the LT_ADDR and
acknowledgment/repeat request (ARQ) scheme. Hence the architecture is incapable of
representing these logical transports with a single transport layer. The additional logical
transport layer goes some way towards describing this behavior.

3.1 Core traffic bearers

The Bluetooth core system provides a number of standard traffic bearers for the
transport of service protocol and application data. These are shown in Figure 3.2 below

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 1, Part A Page 249
Architecture

(for ease of representation this is shown with higher layers to the left and lower layers to
the right).

Application Bluetooth core

Logical
L2CAP Channels/ISOAL Logical Links
Transports

Traffic Types BR/EDR

Channel LE Link
Link
Manager Layer
Manager

Higher Layer Protocol ACL-C

Signalling
Signalling
BR/EDR ACL
ACL-U

Reliable
Asynchronous LE-C
Framed User Data
LE ACL
LE-U
Higher Layer Framed Unicast
Isochronous User
Data

Constant Rate SCO-S SCO

Isochronous User
Data
eSCO-S eSCO

LE-S CIS
LE-F

LEB-C BIS

ADVB-C
ADVB

PADVB
Advertisement Broadcast ADVB-U

Unreliable
Asynchronous
APB-C
Framed User Data

Active Broadcast APB-U APB

Isochronous
Unframed Profile PBD CPB
Data

Figure 3.2: Bluetooth traffic bearers

The core traffic bearers that are available to applications are shown in Figure 3.2 as the
shaded rounded rectangles. The architectural layers that are defined to provide these
services are described in Section 2. A number of data traffic types are shown on the left
of the diagram linked to the traffic bearers that are typically suitable for transporting that
type of data traffic.

The logical links are named using the names of the associated logical transport and a
suffix that indicates the type of data that is transported. (C for control links carrying LMP

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 1, Part A Page 250
Architecture

or LL messages, U for L2CAP links carrying user data (L2CAP PDUs) and S for stream
links carrying unformatted synchronous or isochronous data.) It is common for the suffix
to be removed from the logical link without introducing ambiguity, thus a reference to the
default ACL logical transport can be resolved to mean the ACL-C logical link in cases
where the LMP protocol is being discussed, the LE-C logical link in cases where LL
protocol is being discussed, or the ACL-U or LE-U logical links when the L2CAP layer is
being discussed.

The mapping of application traffic types to Bluetooth core traffic bearers in Figure 3.2
is based on matching the traffic characteristics with the bearer characteristics. It is
recommended to use these mappings as they provide the most natural and efficient
method of transporting the data with its given characteristics.

However, an application (or an implementation of the Bluetooth core system) may

choose to use a different traffic bearer, or a different mapping to achieve a similar
result. For example, in a BR/EDR piconet with only one Peripheral, the Central may
choose to transport L2CAP broadcasts over the ACL-U logical link rather than over the
APB-U logical link. This will probably be more efficient in terms of bandwidth (if the
physical channel quality is not too degraded). Use of alternative transport paths to those
in Figure 3.2 is only acceptable if the characteristics of the application traffic type are
preserved.

Figure 3.2 shows a number of application traffic types. These are used to classify the
types of data that may be submitted to the Bluetooth core system. The original data
traffic type can be different from the type that is submitted to the Bluetooth core system
if an intervening process modifies it. For example, video data is generated at a constant
rate but an intermediate coding process may alter this to variable rate, e.g. by MPEG4
encoding. For the purposes of the Bluetooth core system, only the characteristic of the
submitted data is of interest.

3.1.1 Framed data traffic

The L2CAP layer services provide a frame-oriented transport for asynchronous and
isochronous user data. The application submits data to this service in variable-sized
frames (up to a negotiated maximum for the channel) and these frames are delivered
in the same form to the corresponding application on the remote device. There is no
requirement for the application to insert additional framing information into the data,
although it may do so if this is required (such framing is invisible to the Bluetooth core
system).

Connection-oriented L2CAP channels may be created for transport of unicast (point-to-

point) data between two Bluetooth devices. Connection-oriented channels provide a
context within which specific properties may be applied to data transported on the
channel. For example, quality of service parameters or flow and error control modes

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 1, Part A Page 251
Architecture

may be applied. Connection-oriented L2CAP channels are created using the L2CAP
connection procedure.

A connectionless BR/EDR L2CAP channel exists for broadcasting data or for

transport of unicast data. In the case of piconet topologies the Central is always
the source of broadcast data and the Peripheral(s) are the recipients. Broadcast
traffic on the connectionless L2CAP channel is uni-directional. Unicast data sent on
the connectionless L2CAP channels may be uni-directional or bi-directional. Unicast
data sent on the L2CAP connectionless channel provides an alternate mechanism
to send data with the same level of reliability as an L2CAP connection-oriented
channel operating in Basic mode but without the additional latency incurred by opening
an L2CAP connection-oriented channel. LE L2CAP connectionless channels are not
supported.

BR/EDR L2CAP channels have an associated QoS setting that defines constraints on
the delivery of the frames of data. These QoS settings may be used to indicate (for
example) that the data is isochronous, and therefore has a limited lifetime after which it
becomes invalid, or that the data should be delivered within a given time period, or that
the data is reliable and should be delivered without error, however long this takes.

Some L2CAP channels are fixed channels created when the ACL-U and/or LE-U logical
links are established. These fixed channels have fixed channel identifiers and fixed
configurations and do not permit negotiation of the configuration after they are created.
These fixed channels are used for BR/EDR and LE L2CAP signaling (ACL-U or LE-U),
connectionless channel (ACL-U and APB-U), Security Manager Protocol (LE-U), and
Attribute Protocol (ACL-U or LE-U).

The L2CAP channel manager is responsible for arranging to transport the L2CAP
channel data frames on an appropriate baseband logical link, possibly multiplexing this
onto the baseband logical link with other L2CAP channels with similar characteristics.

3.1.2 Unframed data traffic

If the application does not require delivery of data in frames, possibly because it
includes in-stream framing, or because the data is a pure stream, then it may avoid
the use of L2CAP channels and make direct use of a baseband logical link.

The Bluetooth core system supports the direct transport of application data that is
isochronous and of a constant rate (either bit-rate, or frame-rate for pre-framed data),
using a SCO-S or eSCO-S logical link. These logical links reserve physical channel
bandwidth and provide a constant rate transport locked to the piconet clock. Data
is transported in fixed size packets at fixed intervals with both of these parameters
negotiated during channel establishment. eSCO links provide a greater choice of bit-
rates and also provide greater reliability by using limited retransmission in case of
error. Enhanced Data Rate operation is supported for eSCO, but not for SCO logical

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 1, Part A Page 252
Architecture

transports. SCO and eSCO logical transports do not support multiplexed logical links
or any further layering within the Bluetooth core. An application may choose to layer a
number of streams within the submitted SCO/eSCO stream, provided that the submitted
stream is, or has the appearance of being, a constant rate stream.

The Bluetooth core system also supports the direct transport of application data using
a Profile Broadcast Data (PBD) logical link. This logical link is similar to SCO-S
and eSCO-S since it reserves physical channel bandwidth, provides a constant rate
transport locked to the piconet clock, and transports data at fixed intervals. It does not
support multiplexed logical links or any further layering within the Bluetooth core but,
unlike SCO-S and eSCO-S, it supports broadcasting data from a single transmitter to
many receivers.

The application chooses the most appropriate type of logical link from those available at
the baseband, and creates and configures it to transport the data stream, and releases
it when completed. (The application will normally also use a framed L2CAP unicast
channel to transport its C-plane information to the peer application on the remote
device.)

If the application data is isochronous and of a variable rate, then this may only be
carried by the L2CAP unicast channel, and hence will be treated as framed data.

Unframed data traffic is not supported in the LE system.

3.1.3 Reliability of traffic bearers

A link or channel is characterized as reliable if the receiver is capable of detecting errors

in received packets and requesting retransmission until the errors are removed. This
is known as an Automatic Repeat reQuest (ARQ) scheme. Due to the error detection
systems used, some residual undetected errors may still remain in the received data.
The rate at which these occur depends on the details of the error detection system.

A link or channel is characterized as unreliable if the receiver is not capable of detecting

errors in received packets or if it can detect errors but cannot request retransmission.
In the latter case (such as with most broadcast links), the packets passed on by the
receiver to higher layers may be without error but there is no guarantee that all the
packets that were sent are received. Uses for unreliable links are normally dependent
on techniques to improve the redundancy of the transmission, such as the use of
Forward Error Connection or the repetition of data from the higher layers while the data
is valid, in order to increase the probability that the receiver is able to receive at least
one of the copies successfully.

3.1.3.1 BR/EDR reliability

Bluetooth is a wireless communications system. In poor RF environments, this system

should be considered inherently unreliable. To counteract this the system provides

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 1, Part A Page 253
Architecture

levels of protection at each layer. The baseband packet header uses forward error
correcting (FEC) coding to allow error correction by the receiver and a header error
check (HEC) to detect errors remaining after correction. Certain Baseband packet types
include FEC for the payload. Furthermore, some Baseband packet types include a
cyclic redundancy error check (CRC).

On ACL logical transports the results of the error detection algorithm are used to
drive a simple ARQ protocol. This provides an enhanced reliability by re-transmitting
packets that do not pass the receiver’s error checking algorithm. It is possible to modify
this scheme to support latency-sensitive packets by discarding an unsuccessfully
transmitted packet at the transmitter if the packet’s useful life has expired. eSCO links
use a modified version of this scheme to improve reliability by allowing a limited number
of retransmissions.

The resulting reliability gained by this ARQ scheme is only as dependable as the ability
of the HEC and CRC codes to detect errors. In most cases this is sufficient, however it
has been shown that for the longer packet types the probability of an undetected error
is too high to support typical applications, especially those with a large amount of data
being transferred.

The L2CAP layer provides an additional level of error control that is designed to detect
the occasional errors not detected by the baseband and request retransmission of
the affected data. This provides the level of reliability required by typical Bluetooth
applications. The resulting rate of residual errors is comparable to the rate in other
communication systems.

The transmitter may remove packets from the transmit queue such that the receiver
does not receive all the packets in the sequence. If this happens detection of the
missing packets is delegated to the L2CAP layer.

Stream links have a reliability characteristic somewhere between a reliable and an

unreliable link, depending on the current operating conditions.

3.1.3.2 LE reliability

Like BR/EDR, in poor RF environments, the LE system should be considered inherently

unreliable. To counteract this, the system provides levels of protection at each layer.
The LL packet uses a 24-bit cyclic redundancy error check (CRC) to cover the contents
of the packet payload. If the CRC verification fails on the packet payload, the packet is
not acknowledged by the receiver and the packet gets retransmitted by the sender.

Because of the longer CRC and the shorter typical message compared with BR/EDR,
it is not necessary for the L2CAP layer to provide a separate error detection and
retransmission mechanism.

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 1, Part A Page 254
Architecture

3.1.3.3 [This section is no longer used]

3.2 Transport architecture entities

The Bluetooth transport architecture entities are shown in Figure 3.3 and are described
from the lowest layer upwards in the subsequent sections.
Channels

L2CAP \

Isochronous
ISOAL

Unicast Broadcast
Adaptation
Layer
Logical

Control User Control Profile Control User Control User Control LE- LE-
Links

User
(LMP) (L2CAP) (LMP) (L2CAP) SCO-S eSCO-S Broadcast (LL) (L2CAP) (LL) (LL) (LL) Stream Framed
ACL-C ACL-U APB-C APB-U Data (PBD) LE-C LE-U ADVB-C ADVB-U LEB-C LE-S LE-F
Transports
Logical

BR/EDR LE LE LE
APB SCO eSCO CPB ADVB PADVB PAwR
ACL ACL BIS CIS

BR/EDR LE
LE LE LE LE
Physical

BR/EDR Channel
Links

Connectionless Active Advertising Periodic Isochronous

Active Peripheral Broadcast Sounding
Physical Physical Physical Physical
Physical Link Physical Link Physical
Link Link Link Link
Link
Channels
Physical

BR/EDR BR/EDR BR/EDR BR/EDR BR/EDR LE Channel LE LE

Basic Adapted Page Inquiry LE Piconet LE Periodic
Synchronization Sounding Advertising Isochronous
Piconet Piconet Scan Scan Physical Physical
Scan Physical Physical Physical Physical
Physical Physical Physical Physical Channel Channel
Channel Channel Channel Channel
Channel Channel Channel Channel
Transports
Physical

BR/EDR Physical Transport LE Physical Transport

Figure 3.3: Overview of transport architecture entities and hierarchy

The BR/EDR Physical Transport encapsulates the BR/EDR Physical Channels.

Transfers using the BR/EDR Physical Transport use the BR/EDR Generic Packet
Structure. The LE Physical Transport encapsulates the LE Physical Channels. Transfers
using the LE Physical Transport use the LE Generic Packet Structure for transferring
user data and LL control information. The LE Physical Transport is also used for
transfers using the Channel Sounding generic packet structure and signaling format.

3.2.1 BR/EDR generic packet structure

The generic packet structure nearly reflects the architectural layers found in the
Bluetooth BR/EDR system. The BR/EDR packet structure is designed for optimal use in
normal operation. It is shown in Figure 3.4.

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 1, Part A Page 255
Architecture

Carries the physical channel

access code
Carries the logical transport Layer Information
identifier
EDR Physical layer mode
change
Carries the logical link
identifier
Payload

Guard &
Channel Access Code Packet Header Sync Payload Header Payload Body MIC CRC
(EDR Only)

Carries the link control

LC protocol
Carries LMP messages, L2CAP signals,
L2CAP frames or other user data
Protocols

Figure 3.4: BR/EDR packet structure

Packets normally only include the fields that are necessary to represent the layers
required by the transaction. Thus a simple inquiry request over an inquiry scan physical
channel does not create or require a logical link or higher layer and therefore consists
only of the channel access code (associated with the physical channel).

All packets include the channel access code. This is used to identify communications on
a particular physical channel, and to exclude or ignore packets on a different physical
channel that happens to be using the same RF carrier in physical proximity.

There is no direct field within the BR/EDR packet structure that represents or contains
information relating to physical links. This information is implied by the combination of
the logical transport address (LT_ADDR) carried in the packet header and the channel
access code (CAC).

Most BR/EDR packets include a packet header. The packet header is always present in
packets transmitted on physical channels that support physical links, logical transports
and logical links. The packet header carries the LT_ADDR, which is used by each
receiving device to determine if the packet is addressed to the device and is used to
route the packet internally.

The BR/EDR packet header also carries part of the link control (LC) protocol that
is operated per logical transport (except for ACL and SCO transports that operate a
shared LC protocol carried on either logical transport).

The Enhanced Data Rate (EDR) packets have a guard time and synchronization
sequence before the payload. This is a field used for physical layer change of
modulation scheme.

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 1, Part A Page 256
Architecture

The payload header is present in all packets on logical transports that support multiple
logical links. The payload header includes a logical link identifier field used for routing
the payload, and a field indicating the length of the payload body. Some packet types
also include a CRC at the end of the packet payload that is used to detect most errors
in received packets. When AES-CCM encryption is enabled, ACL packets include a
Message Integrity Check (MIC) just prior to the CRC.

EDR packets have a trailer after the CRC.

The packet payload body is used to transport the user data. The interpretation of this
data is dependent on the logical transport and logical link identifiers. For ACL logical
transports Link Manager protocol (LMP) messages and L2CAP signals are transported
in the packet payload body, along with general user data from applications.

For SCO, eSCO, and CPB logical transports the payload body contains the user data
for the logical link.

3.2.2 LE generic packet structure

LE radio operation is based on four PHYs and makes use of two modulation symbol
rates. Table 3.1 summarizes the properties of each of the LE PHYs. Each packet
transmitted uses a single PHY. Three of the PHYs are uncoded - that is, each bit maps
directly to a single radio symbol in the packet - while the fourth PHY is error correction
coded. There are two coding schemes: S=8 and S=2, where S is the number of symbols
per bit.

PHY Modulation symbol Modulation Coding scheme Data rate

rate bandwidth-
Access Payload
symbol time
Header
product (BT)
LE 1M 1 Msym/s modulation BT=0.5 Uncoded Uncoded 1 Mb/s
LE 2M 2 Msym/s modulation BT=0.5 Uncoded Uncoded 2 Mb/s
LE 2M 2BT1 2 Msym/s modulation BT=2.0 Uncoded Uncoded 2 Mb/s
LE Coded 1 Msym/s modulation BT=0.5 S=8 S=8 125 kb/s
S=2 500 kb/s
Table 3.1: Summary of PHYs, modulation schemes, and coding schemes

1LE 2M 2BT is used only for Channel Sounding.

The "Access Header" referred to in Table 3.1 includes all the bits in the packet format
associated with the particular PHY prior to the start of the PDU Header but not including
the preamble. The preamble is excluded as this is uncoded for all PHYs.

The "Payload" referred to in Table 3.1 includes all the bits in the packet format from the
PDU Header to the end of the packet.

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 1, Part A Page 257
Architecture

The general structure of the Link Layer Air Interface packet closely reflects the
architectural layers found in the LE system. The packet structure for the LE Uncoded
PHYs is designed for optimal use in normal operation and is shown in Figure 3.5.

Carries physical channel

access code
Carries the logical transport
and logical link identifiers

Constant Tone
Preamble Access Address PDU Header PDU Payload MIC CRC Extension

Carries one of the following:

L2CAP signals, L2CAP frames, ISOAL segments,
isochronous data, or other user data

Figure 3.5: The packet structure for the LE Uncoded PHYs

The packet structure for the LE Coded PHY is designed for optimal use in extended
range operation and is shown in Figure 3.6.

Layer Information

Carries physical channel Carries logical transport

access code and logical link identifiers

Preamble Access Address CI TERM1 PDU Header PDU Payload MIC CRC TERM2

Carries one of the following: L2CAP

Access signals, L2CAP frames, ISOAL segments,
Header isochronous data, or other user data

Carries the Link Layer Protocol

Figure 3.6: The packet structure for the LE Coded PHY

When using the LE Coded PHY, it is recommended to carefully consider the impact
of radio-on time for power consumption and duty cycle for scheduling and coexistence
over the air. The LE Coded PHY with S=8 coding (125 kb/s) represents the worst case,

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 1, Part A Page 258
Architecture

when considering radio-on time and duty cycle, where each packet sent over the air will
be approximately 8 times larger than LE 1M.

Table 3.2 illustrates the on-air time of advertising events with different sizes of AdvData.
The first is using connectable and scannable undirected advertising events where the
AdvData is sent on the primary advertising physical channel. The second is using
events where the AdvData is offloaded to the secondary advertising physical channel.
The usage of the primary and secondary advertising physical channels is described in
Section 3.3.2.2. Numbers in parentheses are hypothetical and show cases that are not
valid.

AdvData Connectable Undirected Advertising Connectable Undirected Advertising

[Bytes] event [µs] event Using Offloading [µs]
LE 1M LE Coded S=8 LE 1M LE Coded S=8
0 384 (3,312) 568 4,864
15 744 (6,192) 688 5,824
31 1,128 (9,264) 816 6,848
100 (2,784) (22,512) 1,368 11,264
245 (6,264) (50,352) 2,528 20,544

Table 3.2: On-air time for various advertising events

Note: The events without offloading were calculated using three ADV_IND PDUs, while
the events with offloading used three ADV_EXT_IND PDUs containing only the AuxPtr
and ADI fields plus one AUX_ADV_IND PDU with the AdvA and ADI fields present and
holding the AdvData.

Table 3.3 illustrates, for a range of payload sizes, the difference in Link Layer Data
Physical Channel PDU packet durations for connections over the LE 1M PHY and LE
Coded PHY with S=8 coding. Connection duty cycle for a specific implementation may
be easily calculated from this information.

Payload [bytes] LL Data Physical Channel PDU [µs]

LE 1M LE Coded S=8
0 80 720
15 200 1,680
31 328 2,704
100 880 7,120
255 2,120 17,040

Table 3.3: On-air time for various data physical channel packets not containing Constant Tone Extensions

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 1, Part A Page 259
Architecture

The physical link identifier is not contained in the Link Layer Air Interface packet. The
physical channel identifiers are either fixed, are determined at connection setup, or are
determined at periodic advertising setup. All LE packets include the Access Address.
This is used to identify communications on a physical channel, and to exclude or
ignore packets on different physical channels that are using the same PHY channels
in physical proximity. The Access Address determines whether the packet is directed
to the advertising physical channel (and thus an advertising physical link) used for
non-periodic advertising, the periodic physical channel used for periodic advertising,
or to a piconet physical channel (and thus an active physical link to a device). The
LE advertising physical channel used for non-periodic advertising uses a fixed Access
Address. The LE periodic physical channel used for periodic advertising and LE piconet
physical channels use a randomly generated 32-bit value as their Access Address.
This provides a high number of periodic advertising trains and a high number of active
devices that can be addressed in an LE periodic advertisement or an LE piconet.

All LE packets include a PDU header. The PDU header determines the type of
advertisement broadcast or logical link carried over the physical channel.

For advertising physical channel PDUs, the PDU header contains the type of
advertisement payload, the device address type for addresses contained in the
advertisement, and the advertising physical channel PDU payload length. Most
advertising physical channel PDU payloads contain the advertiser's address and
advertising data. One advertising physical channel PDU payload only contains
the advertiser's device address and the initiator's device address in which the
advertisement is directed. Advertising physical channel PDUs with scan requests
payloads contain the scanner's device address and the advertiser's device address.
Advertising physical channel PDUs with scan responses contain advertiser's device
address and the scan response data. Advertising physical channel PDUs with
connection request payloads contain the initiator's device address, advertiser's device
address and connection setup parameters.

For Data Physical Channel PDUs, the PDU header contains the Logical Link Identifier
(LLID), the Next Expected Sequence Number (NESN), Sequence Number (SN), More
Data (MD), CTEInfo Present (CP), payload length, and may contain CTEInfo. For
Data Physical Channel PDUs that contain control commands, the Data Channel PDU
payload contains a command opcode and control data that is specific to the command.
There is an optional Message Integrity Check (MIC) value that is used to authenticate
the data PDU. For Data Physical Channel PDUs that are data, the Data Physical
Channel PDU payload contains L2CAP data.

An Isochronous Physical Channel PDU can be either a Connected Isochronous or

Broadcast Isochronous PDU. A Connected Isochronous PDU contains a header and
may contain an isochronous payload. The header field contains the Logical Link
Identifier (LLID), Sequence Number (SN), Next Expected Sequence Number (NESN),

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 1, Part A Page 260
Architecture

Close Isochronous Event (CIE), Null PDU Indicator (NPI), and the payload length. A
Connected Isochronous PDU may also contain a Message Integrity Check (MIC) field.

A Broadcast Isochronous PDU contains a header and either isochronous or control

data. The header field contains the Logical Link Identifier (LLID), the Control Subevent
Sequence Number (CSSN), the Control Subevent Transmission Flag (CSTF), and the
payload length. The Broadcast Isochronous PDU may also contain a Message Integrity
Check (MIC) field.

Both advertising physical channel packets and data physical channel packets can
contain a Constant Tone Extension, which can be used for determining the relative
direction of a received radio signal.

3.2.3 LE Channel Sounding generic packet structure and signaling format

An LE Channel Sounding (CS) operation employs two types of packet structures. The
first packet structure makes use of the LE 1M, LE 2M, and LE 2M 2BT PHYs described
in Section 3.2.2 and uses the same modulation described for those PHYs. The second
packet structure employs the carrier tone modulated with amplitude shift keying.

The first packet structure used with the LE 1M, LE 2M, and LE 2M 2BT PHYs contains
a preamble, an Access Address with trailer bits, and an optional payload as shown
in Figure 3.7. Unlike the packet formats described in Section 3.2.2, a PDU header is
not needed, because the presence and the content type of the optional payload are
pre-negotiated.

Carries physical channel

access code

Trailer
Preamble Access Address
Bits

Carries either a random bit sequence or

a sounding sequence with marker
insertion

Figure 3.7: The Channel Sounding packet structure for LE 1M and 2M PHYs

The Preamble is the same as the preamble described for LE Uncoded PHYs in
Section 3.2.2.

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 1, Part A Page 261
Architecture

Similarly for CS, the Access Address is also the same as described in Section 3.2.2
but contains a bit sequence known only to the CS initiator and reflector pair. This CS
Access Address is changed on every transmission.

The Trailer is a 4-bit sequence, alternating between 0 and 1 bits.

The “Payload” also follows the coding scheme rules described in Section 3.2.2.
However, its content format is pre-selected and consists of either a bit sequence known
only to the initiator and reflector pair, or a repeating [0 1] sounding sequence, with
intermittent insertion of markers.

The second packet structure which is modulated using amplitude shift keying consists
of one or more transmissions at the channel carrier frequency followed by an optional
carrier transmission, over a selected antenna path. An antenna path is defined as single
communication path between a specific physical antenna element on a transmitter
to a specific physical antenna element on a receiver. The first set of transmissions
can repeat over several antenna paths. The presence or non-presence of the final
transmission extension concludes this transmission sequence. This format is shown in
Figure 3.8.

Carrier transmissions over an antenna path selection

Antenna Antenna Antenna Antenna

Extension
Path A Path B Path C Path D

Carrier extension transmission

Figure 3.8: The Channel Sounding packet structure for modulated carrier transmissions.

3.3 Physical channels

A number of types of physical channel are defined. All Bluetooth physical channels
are characterized by a set of PHY frequencies combined with temporal parameters
and restricted by spatial considerations. For the basic and adapted piconet physical
channels frequency hopping is used to change frequency periodically to reduce the
effects of interference and for regulatory reasons.

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 1, Part A Page 262
Architecture

The Bluetooth BR/EDR system and LE system differ slightly in the way they use
physical channels.

3.3.1 BR/EDR physical channels

In the BR/EDR core system, peer devices use a shared physical channel for
communication. To achieve this their transceivers need to be tuned to the same PHY
frequency at the same time, and they need to be within a nominal range of each other.

Given that the number of RF carriers is limited and that many Bluetooth devices may
be operating independently within the same spatial and temporal area there is a strong
likelihood of two independent Bluetooth devices having their transceivers tuned to the
same RF carrier, resulting in a physical channel collision. To mitigate the unwanted
effects of this collision each transmission on a physical channel starts with an access
code that is used as a correlation code by devices tuned to the physical channel. This
channel access code is a property of the physical channel. The access code is present
at the start of every transmitted packet.

Several BR/EDR physical channels are defined. Each is optimized and used for a
different purpose. Two of these physical channels (the basic piconet channel and
adapted piconet channel) are used for communication between connected devices
and are associated with a specific piconet. Other BR/EDR physical channels are used
for discovering (the inquiry scan channel) and connecting (the page scan channel)
Bluetooth devices. The synchronization scan physical channel is used by devices to
obtain timing and frequency information about the Connectionless Peripheral Broadcast
physical link or to recover the current piconet clock.

A Bluetooth device can only use one BR/EDR physical channel at any given time.
In order to support multiple concurrent operations the device uses time-division
multiplexing between the channels. In this way a Bluetooth device can appear
to operate simultaneously in several piconets, as well as being discoverable and
connectable.

Whenever a Bluetooth device is synchronized to the timing, frequency and access code
of a physical channel it is said to be ‘connected’ to this channel (whether or not it
is actively involved in communications over the channel). The Bluetooth specification
assumes that a device is only capable of connecting to one physical channel at any
time. Advanced devices may be capable of connecting simultaneously to more than one
physical channel, but the specification does not assume that this is possible.

3.3.1.1 Basic piconet channel

3.3.1.1.1 Overview

The basic piconet channel is used for communication between connected devices
during normal operation.

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 1, Part A Page 263
Architecture

3.3.1.1.2 Characteristics

The basic piconet channel is characterized by a pseudo-random sequence hopping

through the PHY channels. The hopping sequence is unique for the piconet and is
determined by the Bluetooth Device Address of the Central. The phase in the hopping
sequence is determined by the Bluetooth clock of the Central. All Bluetooth devices
participating in the piconet are time- and hop-synchronized to the channel.

The channel is divided into time slots where each slot corresponds to an PHY hop
frequency. Consecutive hops correspond to different PHY hop frequencies. The time
slots are numbered according to the Bluetooth clock of the piconet Central. Packets are
transmitted by Bluetooth devices participating in the piconet aligned to start at a slot
boundary. Each packet starts with the channel access code, which is derived from the
Bluetooth Device Address of the piconet Central.

On the basic piconet channel the Central controls access to the channel. The Central
starts its transmission in even-numbered time slots only. Packets transmitted by the
Central are aligned with the slot start and define the piconet timing. Packets transmitted
by the Central may occupy up to five time slots depending on the packet type.

Each Central transmission is a packet carrying information on one of the logical

transports. Peripherals may transmit on the physical channel in response. The
characteristics of the response are defined by the logical transport that is addressed.

For example, on the asynchronous connection-oriented logical transport (ACL), the

addressed Peripheral responds by transmitting a packet containing information for the
same logical transport that is nominally aligned with the next (odd-numbered) slot start.
Such a packet may occupy up to five time slots, depending on the packet type. On a
broadcast logical transport no Peripherals are allowed to respond.

3.3.1.1.3 Topology

A basic piconet channel may be shared by any number of Bluetooth devices, limited
only by the resources available on the piconet Central. Only one device is the piconet
Central, all others being piconet Peripherals. All communication is between the Central
and Peripherals. There is no direct communication between Peripherals on the piconet
channel.

There is, however, a limitation on the number of logical transports that can be supported
within a piconet. This means that although there is no theoretical limit to the number of
Bluetooth devices that share a channel there is a limit to the number of these devices
that can be actively involved in exchanging data with the Central.

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 1, Part A Page 264
Architecture

3.3.1.1.4 Supported layers

The basic piconet channel supports a number of physical links, logical transports,
logical links and L2CAP channels used for general purpose communications.

3.3.1.2 Adapted piconet channel

3.3.1.2.1 Overview

The adapted piconet channel differs from the basic piconet channel in two ways.
First, the frequency on which a Peripheral transmits is the same as the frequency
used by its Central in the preceding transmission. In other words the frequency is not
recomputed between Central and subsequent Peripheral packets. Second, the adapted
piconet channel may be based on fewer than the full 79 frequencies. A number of
frequencies may be excluded from the hopping pattern by being marked as “unused”.
The remainder of the 79 frequencies are included. The two sequences are the same
except that whenever the basic pseudo-random hopping sequence selects an unused
frequency, it is replaced with an alternative chosen from the used set. The set of
frequencies used may vary between different physical links on the same adapted
piconet channel.

Because the adapted piconet channel uses the same timing and access code as the
basic piconet channel, physical links on the two channels are often coincident. This
provides a deliberate benefit as it allows Peripherals in either the basic piconet channel
or the adapted piconet channel to adjust their synchronization to the Central.

The topology and supported layers of the adapted piconet physical channel are identical
to the basic piconet physical channel with one exception: on the adapted piconet
physical channel, it is possible for a single Central to transmit data to an unlimited
number of Peripherals using a single CPB logical transport. In this case, however, data
is only transferred from Central to Peripheral and not from Peripheral to Central.

3.3.1.3 Inquiry scan channel

3.3.1.3.1 Overview

In order for a device to be discovered, an inquiry scan channel is used. A discoverable

device listens for inquiry requests on its inquiry scan channel and then sends a
response to that request. In order for a device to discover other devices, it iterates
(hops) through all possible inquiry scan channel frequencies in a pseudo-random
fashion, sending an inquiry request on each frequency and listening for any response.

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 1, Part A Page 265
Architecture

3.3.1.3.2 Characteristics

Inquiry scan channels follow a slower hopping pattern and use an access code to
distinguish between occasional occupancy of the same radio frequency by two co-
located devices using different physical channels.

The access code used on the inquiry scan channel is taken from a reserved set of
inquiry access codes that are shared by all Bluetooth devices. One access code is used
for general inquiries, and a number of additional access codes are reserved for limited
inquiries. Each device has access to a number of different inquiry scan channels. As all
of these channels share an identical hopping pattern, a device may concurrently occupy
more than one inquiry scan channel if it is capable of concurrently correlating more than
one access code.

A device using one of its inquiry scan channels remains passive on that channel until
it receives an inquiry message on this channel from another Bluetooth device. This is
identified by the appropriate inquiry access code. The inquiry scanning device will then
follow the inquiry response procedure to return a response to the inquiring device.

In order for a device to discover other Bluetooth devices it uses the inquiry scan channel
to send inquiry requests. As it has no prior knowledge of the devices to discover, it
cannot know the exact characteristics of the inquiry scan channel.

The device takes advantage of the fact that inquiry scan channels have a reduced
number of hop frequencies and a slower rate of hopping. The inquiring device transmits
inquiry requests on each of the inquiry scan hop frequencies and listens for an inquiry
response. Transmissions are done at a faster rate, allowing the inquiring device to cover
all inquiry scan frequencies in a reasonably short time period.

3.3.1.3.3 Topology

Inquiring and discoverable devices use a simple exchange of packets to fulfill the
inquiring function. The topology formed during this transaction is a simple and transient
point-to-point connection.

3.3.1.3.4 Supported layers

During the exchange of packets between an inquiring and discoverable device it may be
considered that a temporary physical link exists between these devices. However, the
concept is quite irrelevant as it has no physical representation but is only implied by the
brief transaction between the devices. No further architectural layers are considered to
be supported.

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 1, Part A Page 266
Architecture

3.3.1.4 Page scan channel

3.3.1.4.1 Overview

A connectable device (one that is prepared to accept connections) does so using a

page scan channel. A connectable device listens for a page request on its page scan
channel and, once received, enters into a sequence of exchanges with this device.
In order for a device to connect to another device, it iterates (hops) through all page
scan channel frequencies in a pseudo-random fashion, sending a page request on each
frequency and listening for a response.

3.3.1.4.2 Characteristics

The page scan channel uses an access code derived from the scanning device’s
Bluetooth Device Address to identify communications on the channel. The page scan
channel uses a slower hopping rate than the hop rate of the basic and adapted piconet
channels. The hop selection algorithm uses the Bluetooth device clock of the scanning
device as an input.

A device using its page scan channel remains passive until it receives a page request
from another Bluetooth device. This is identified by the page scan channel access code.
The two devices will then follow the page procedure to form a connection. Following a
successful conclusion of the page procedure both devices switch to the basic piconet
channel that is characterized by having the paging device as Central.

In order for a device to connect to another Bluetooth device it uses the page scan
channel of the target device in order to send page requests. If the paging device does
not know the phase of the target device’s page scan channel it therefore does not
know the current hop frequency of the target device. The paging device transmits page
requests on each of the page scan hop frequencies and listens for a page response.
This is done at a faster hop rate, allowing the paging device to cover all page scan
frequencies in a reasonably short time period.

The paging device may have some knowledge of the target device’s Bluetooth clock
(indicated during a previous inquiry transaction between the two devices, or as a result
of a previous involvement in a piconet with the device), in this case it is able to predict
the phase of the target device’s page scan channel. It may use this information to
optimize the synchronization of the paging and page scanning process and speed up
the formation of the connection.

3.3.1.4.3 Topology

Paging and connectable devices use a simple exchange of packets to fulfill the paging
function. The topology formed during this transaction is a simple and transient point-to-
point connection.

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 1, Part A Page 267
Architecture

3.3.1.4.4 Supported layers

During the exchange of packets between a paging and connectable device it may be
considered that a temporary physical link exists between these devices. However, the
concept is quite irrelevant as it has no physical representation but is only implied by the
brief transaction between the devices. No further architectural layers are considered to
be supported.

3.3.1.5 Synchronization scan channel

3.3.1.5.1 Overview

In order to receive packets sent on the CPB logical transport, a device must first
obtain information about the timing and frequency channels of those packets. If a
device misses a Coarse Clock Adjustment notification, it needs to recover the current
piconet clock. The synchronization scan channel is provided for these purposes. A
scanning device listens for synchronization train packets on the synchronization scan
channel. Once a synchronization train packet is received, the device may stop listening
for synchronization train packets because it has the timing and frequency information
necessary to start receiving packets sent on the CPB logical transport or to recover the
piconet clock.

3.3.1.5.2 Characteristics

The synchronization scan channel uses an access code derived from the Bluetooth
Device Address of the synchronization train transmitter to identify synchronization train
packets on the channel. Once a synchronization train packet is received, the scanning
BR/EDR Controller may start receiving packets sent on the CPB logical transport,
depending on the needs of the Host and any applicable profile(s).

3.3.1.5.3 Topology

The topology formed during this scan is transient and point-to-multipoint. There can be
an unlimited number of scanning devices simultaneously receiving synchronization train
packets from the same synchronization train transmitter.

3.3.1.5.4 Supported layers

There is a one-way flow of packets from the synchronization train transmitting device
to the scanning device(s). This may be considered a temporary physical link that exists
only until the scanning device receives the required information. No further architectural
layers are considered to be supported.

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 1, Part A Page 268
Architecture

3.3.2 LE physical channels

In the LE core system, two Bluetooth devices use a shared physical channel for
communication. To achieve this, their transceivers need to be tuned to the same PHY
frequency at the same time, and they need to be within a nominal range of each other.

Given that the number of PHY channels is limited, and many Bluetooth devices can be
operating independently within the same spatial and temporal area, there is a strong
likelihood of two pairs of independent Bluetooth devices having their transceivers tuned
to the same PHY channel, resulting in a collision. Unlike BR/EDR, where an access
code is used to identify the piconet, LE uses a randomly generated Access Address to
identify a physical channel between devices. In the event that two devices happen to
share the same PHY channel in the same area, the targeted device Access Address is
used as a correlator to determine to which device the communication is directed.

Five LE physical channels are defined. Each is optimized and used for a different
purpose. The LE piconet physical channel is used for communication between
connected devices and is associated with a specific piconet. The LE advertising
physical channel is used for broadcasting advertisements to LE devices. These
advertisements can be used to discover, connect, or send user data to scanner or
initiator devices. The periodic physical channel is used to send user data to scanner
devices in periodic advertisements at a specified interval. The LE isochronous physical
channel is used to transfer isochronous data between LE devices in an LE piconet or to
transfer isochronous data between unconnected LE devices. The LE Channel Sounding
physical channel carries security-related information, as well as content used for the
purpose of measuring the time, phase, and amplitude of the communication channel
between two LE devices in an LE piconet.

An LE device can only use one of these LE physical channels at any given time.
In order to support multiple concurrent operations the device uses time-division
multiplexing between the channels. In this way a Bluetooth device can appear to
support connected devices while simultaneously sending advertising broadcasts.

Whenever an LE device is synchronized to the timing and frequency of the physical

channel it is said to be connected or synchronized to this channel (whether or not it
is actively involved in communications over the channel). The Bluetooth specification
assumes that a device is only capable of connecting to one physical channel at a time.
Advanced devices may be capable of connecting or synchronizing simultaneously to
more than one physical channel, but the specification does not make this assumption.

Packets on both the LE piconet physical channel and the LE advertisement broadcast
channel can contain a Constant Tone Extension that can be used for the purpose of
direction finding.

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 1, Part A Page 269
Architecture

3.3.2.1 LE piconet physical channel

3.3.2.1.1 Overview

The LE piconet physical channel is used for communication between connected LE

devices during normal operation.

3.3.2.1.2 Characteristics

The LE piconet physical channel is characterized by the access address, a pseudo-

random sequence of PHY channels, and three additional parameters provided by the
Central. The first is the channel map that indicates the set of PHY channels used in the
piconet. The second is a pseudo random number used as an index into the complete
set of PHY channels. The third is the timing of the first data packet sent by the Central
after the connection request.

The channel is divided into connection events where each connection event
corresponds to a PHY hop channel. Consecutive connection events correspond to
different PHY hop channels. The first packet sent by the Central after the connection
establishment sets an anchor point for the timing of all future connection events. In a
connection event the Central transmits packets to a Peripheral in the piconet and the
Peripheral may respond with a packet of its own.

On the LE piconet physical channel the Central controls access to the channel. The
Central starts its transmission in a connection event that occurs at regular intervals.
Packets transmitted by the Central are aligned with the connection event start and
define the piconet timing.

Each Central transmission contains a packet carrying information on one of the logical
transports. The Peripheral can transmit on the physical channel in response.

The LE piconet physical channel is similar to the BR/EDR adapted piconet channel
in that the set of PHY channels used can be modified to avoid interference. The set
of used channels in the channel map is established by the Central during connection
setup. While in a connection the Central can change the channel map when necessary
to avoid new interferers. The Peripheral can provide channel classification information
to the Central.

There are 37 LE piconet channels. The Central can reduce this number through the
channel map indicating the used channels. When the hopping pattern hits an unused
channel the unused channel is replaced with an alternate from the set of used channels.
The LE Piconet physical channel can use any LE PHY.

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 1, Part A Page 270
Architecture

3.3.2.1.3 Topology

An LE piconet physical channel is shared by exactly two LE devices.

An LE device may belong to one or more piconets at a time, that is, an LE device may
be a Peripheral in zero or more piconets and may also be a Central in zero or more
piconets.

Only one LE piconet physical channel can exist between two LE device identities or
non-resolvable private addresses.

3.3.2.1.4 Supported layers

The LE piconet physical channel supports L2CAP channels used for general purpose
communications.

3.3.2.2 Advertising physical channels

3.3.2.2.1 Overview

An LE advertising physical channel is used to set up connections between two devices

or to communicate broadcast information between unconnected devices.

3.3.2.2.2 Characteristics

There are two LE advertising physical channels: the primary advertising physical
channel and the secondary advertising physical channel.

The primary advertising physical channel is a set of three fixed PHY channels spread
evenly across the LE frequency spectrum. The number of primary advertising PHY
channels can be reduced by the advertising device in order to reduce interference. The
primary advertising physical channel can use either the LE 1M or LE Coded PHY.

The primary advertising physical channel is divided into advertising events where each
advertising event can hop on all primary advertising PHY channels. The advertising
events occur at regular intervals which are slightly modified with a random delay to aid
in interference avoidance.

On the primary advertising physical channel the advertising device controls access to
the physical channel. The advertising device starts its transmission in an advertising
event and transmits advertising packets on one or more of the primary advertising PHY
channels. Each advertising packet is sent on a different advertising PHY channel at a
fixed interval. Seven types of advertising events can be used, with each advertising
event type having different sized advertising packets. The PDU payloads of these
advertising packets can vary in length from 6 to 37 octets.

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 1, Part A Page 271
Architecture

Some advertising events sent by the advertising device permit the listening device
to concurrently send scan requests or connection requests packets on the same
advertising PHY channel in which the advertising packet was received. The advertising
device can send a scan response packet again on the same advertising PHY channel
within the same advertising event. The payload of the scan response packet can vary in
length from 6 to 37 octets.

The secondary advertising physical channel is a set of 37 fixed PHY channels spread
across the LE frequency spectrum. These are the same fixed LE PHY channels used
by the data physical channel. The secondary advertising physical channel uses the
same channel indices as the data physical channel. The payload of advertising packets
used on the secondary advertising physical channel can vary in length from 0 to 255
octets. Advertising packets on the secondary advertising physical channel are not part
of the advertising event but are part of the extended advertising event. These extended
advertising events begin at the same time as the advertising event on the primary
advertising physical channel and conclude with the last packet on the secondary
advertising physical channel.

The secondary advertising physical channel is used to offload data that would otherwise
be transmitted on the primary advertising physical channel. Advertising packets on
the secondary advertising physical channel ("auxiliary packets") are scheduled by the
advertiser when sufficient over-the-air time is available. The advertising packet on the
primary advertising physical channel contains the PHY channel and the offset to the
start time of the auxiliary packet.

The secondary advertising physical channel can use any LE PHY. All advertising
packets on the secondary advertising physical channel in the same extended
advertising event use the same PHY, which is specified in the advertising packet on
the primary advertising physical channel.

3.3.2.2.3 Topology

An LE advertising physical channel can be shared by any number of LE devices. Any

number of LE devices can transmit advertising packets while sharing the advertising
physical channel. Any number of scanning devices can listen on the advertising physical
channel. An advertising device can advertise and be connected on an LE piconet
physical channel simultaneously. Scanning devices may also be connected to one or
more LE piconet physical channels simultaneously.

3.3.2.3 Periodic physical channel

3.3.2.3.1 Overview

An LE periodic physical channel is used to set up a periodic broadcast between

unconnected devices.

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 1, Part A Page 272
Architecture

3.3.2.3.2 Characteristics

The periodic physical channel is characterized by a pseudo-random sequence of PHY

channels and additional parameters provided by the advertiser. These are the channel
map that indicates the set of PHY channels used in the periodic broadcast, the event
counter used to determine the channel hopping sequence, the offset indicating the
timing of the first periodic broadcast packet, and the interval between successive
periodic broadcasts.

The channel is divided into periodic advertising events where the start of a periodic
advertising event corresponds to a PHY hop channel. The start of consecutive periodic
advertising events corresponds to different PHY hop channels. The first packet sent by
the advertiser after the broadcast is established sets an anchor point for the timing of all
future periodic advertising events.

On the periodic physical channel, the advertising device controls access to the physical
channel. The advertiser starts its transmission in a periodic advertising event that
occurs at regular intervals. Packets transmitted by the advertiser are aligned with the
periodic advertising event and specified broadcast timing. Additional packets may also
be transmitted between the periodic advertising events. The payload of packets sent by
the advertiser may vary in length from 0 octets to 255 octets.

Each advertiser transmission contains a packet carrying information on the PADVB

logical transports. Scanners cannot transmit on the physical channel.

There are 37 PHY channels. The advertiser can reduce this number through the
channel map indicating the used channels. When the hopping pattern hits an unused
channel, the unused channel is replaced with an alternate from the set of used
channels. The periodic physical channel can use any PHY. All periodic advertising
events use the same PHY used by the advertiser in the packet describing the
characteristics of the periodic physical channel.

3.3.2.3.3 Topology

An LE periodic physical channel can be shared by any number of LE devices. Any

number of LE devices can transmit periodic advertising packets while sharing the same
periodic physical PHY channels. Any number of scanning devices can listen on the
periodic physical channel. An advertising device can advertise and be synchronized
on an LE periodic physical channel simultaneously. Scanning devices may also be
synchronized to one or more LE periodic physical channels simultaneously.

3.3.2.4 LE Isochronous physical channel

The LE isochronous physical channel can be created to transfer isochronous data

between LE devices.

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 1, Part A Page 273
Architecture

3.3.2.4.1 Overview

The LE isochronous physical channel is used to transfer isochronous data between

connected or unconnected LE devices.

3.3.2.4.2 Characteristics

The LE isochronous physical channel is characterized by a pseudo-random sequence

of PHY channels and by three additional parameters that are provided by a Central or
a connectionless broadcaster. The first parameter is the channel map that indicates the
set of PHY channels. The second parameter is a pseudo random number that is used
as an index into the complete set of PHY channels. The third parameter is the timing
of the first data packet. The timing of the first packet of a CIS is provided in the Link
Layer message that is sent in the associated ACL connection by the Central during the
CIS establishment phase. The timing of the first packet of a BIS is referenced from a
periodic advertising event associated with the BIS.

The LE isochronous physical channel is used to transfer isochronous data in

isochronous events that occur at regular intervals. Each isochronous event is divided
into one or more subevents. Each subevent uses a PHY channel that is selected by the
channel selection algorithm.

In any subevent in an isochronous connection, the Central transmits a packet to the

Peripheral and the Peripheral may respond with a packet of its own. The Central
controls the access to the LE isochronous physical channel. In every CIS event,
the Central starts its transmission at the start of the first subevent. Packets that are
transmitted by the Central are time aligned with the start of every subevent.

A Broadcasting Isochronous transmitter transmits isochronous data packets and control

packets. Any device that is synchronized to the BIS can receive these packets. The
broadcasting device controls access to the LE isochronous physical channel. Within BIS
events, the broadcasting device starts its transmission in the first subevent. Packets that
are transmitted by the broadcasting device are aligned with the start of every subevent.

There are 37 PHY channels. The Central or the isochronous stream transmitter
can reduce this number through the channel map that indicates the used channels.
When the channel selection algorithm selects an unused channel, the unused channel
is replaced with an alternate from the set of used channels. For CISes, the LE
isochronous physical channel uses the set of PHY channels that are enabled on the
LE piconet physical channel. The LE isochronous physical channel can use any LE
PHY.

3.3.2.4.3 Topology

The LE isochronous physical channel in a CIS can be used for one-to-one

communication between the devices that are in the LE piconet. The Central may

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 1, Part A Page 274
Architecture

establish one or more CISes with the Peripheral in the LE piconet; that is, the LE
isochronous physical channel can carry one or more CIS logical transports between a
given Central and Peripheral. The LE isochronous physical channel and all the CISes it
carries are terminated when the associated LE piconet physical channel is terminated.
If a Central has established piconets with more than one Peripheral, it can establish
LE isochronous physical channels with more than one of these Peripherals at the same
time.

The LE isochronous physical channel can be used for one-to-many communication

topologies of unconnected LE devices. Each LE isochronous physical channel can carry
one or more BIS logical transports.

3.3.2.5 LE Channel Sounding physical channel

The LE CS physical channel can be created to transfer time and phase information that
can be used to generate a distance estimate.

3.3.2.5.1 Overview

An LE CS physical channel is used to exchange time-interleaved modulated tones

and packets that allow a pair of devices to measure the time of flight, amplitude, and
phase of signals sent over the communication channel. This information can be used to
estimate the distance between two LE devices.

3.3.2.5.2 Characteristics

The LE CS physical channel is characterized by a pre-negotiated sequence of

exchanges that make up a CS procedure. Characteristics and content of these
exchanges is derived from the output of a Deterministic Random Bit Generator (DRBG).
The DRBG is used to generate the content of the CS Access Address and payload
content. It is also used to influence the modulated content of tone transmissions. Finally,
the DRBG is used to seed the selection of the pseudo-random sequence of the PHY
channels used in the channel hop sequence of a Channel Sounding procedure.

The duration of a CS procedure is determined by the time it takes for a predetermined

number of CS steps to be exchanged. Additional time may be required to partition the
CS steps into subevents in order to coexist with other activities using the same radio or
spectrum.

CS steps are defined as a bidirectional exchange between initiator and reflector

devices. These steps are further aggregated into a related timing group known as a
CS subevent. These subevents are timed from an offset of the underlying LE piconet
physical channel connection event anchor point. A CS event is defined as the group of
all CS subevents offset from the same LE piconet physical channel connection event
anchor point.

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 1, Part A Page 275
Architecture

Each step exchange may include a modulated packet, a modulated tone, or both. The
initiator device transmits first, followed by at least one transmission from the reflector.
A modulated tone may be transmitted more than once in each direction in cases where
multiple antenna paths are employed.

3.3.2.5.3 Topology

An LE Channel Sounding physical channel is used for one-to-one communication

between two devices that are in the same piconet, where one is in the initiator role
and the other is in the reflector role. In the context of CS, an initiator is the device that
starts the CS procedure, and a reflector is the device that responds. The procedure’s
operating parameters are exchanged in Link Layer control messages. LE CS physical
channel timing depends on the timing of the initiator device, which is followed by the
reflector device. The LE Central device may assume either the initiator or reflector role.
Likewise, the LE Peripheral device may assume either role.

An LE device can use only one LE Channel Sounding physical channel at a time. To
support multiple concurrent Channel Sounding operations, the device uses time-division
multiplexing between multiple LE Channel Sounding physical channels, which allows a
device to appear to support multiple connected devices with Channel Sounding physical
channels.

3.3.3 [This section is no longer used]

3.4 Physical links

A physical link represents a baseband connection between Bluetooth devices. A
physical link is always associated with exactly one physical channel (although a
physical channel may support more than one physical link). Within the Bluetooth system
a physical link is a virtual concept that has no direct representation within the structure
of a transmitted packet.

In BR/EDR the access code packet field, together with the clock and address of the
Central Bluetooth device, is used to identify a physical channel. In LE, the access
address and channel map, including hopIncrement in the case of Channel Selection
Algorithm #1 or an event counter in the case of Channel Selection Algorithm #2, are
used to identify a physical channel. For BR/EDR and LE, there is no subsequent part
of the packet that directly identifies the physical link. Instead, the physical link may
be identified by association with the logical transport, as each logical transport is only
received on one physical link.

Some physical link types have properties that may be modified. An example of this is
the transmit power for the link. Other physical link types have no modifiable properties.
In the case of BR/EDR physical links with modifiable properties the LM protocol is used
to adapt these properties. In the case of LE physical links with modifiable properties

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 1, Part A Page 276
Architecture

the LL protocol is used to adapt these properties. As the LM protocol (BR/EDR) or

LL protocol (LE) is supported at a higher layer (by a logical link) the appropriate
physical link is identified by implication from the logical link that transports the LM or
LL signaling.

In the situation where a transmission is broadcast over a number of different physical

links, then the transmission parameters are selected to be suitable for all of the physical
links.

3.4.1 BR/EDR links supported by the basic and adapted piconet physical
channels

The basic piconet physical channel supports a physical link which may only be active.
The adapted piconet physical channel may support several physical links, including
active and Connectionless Peripheral Broadcast. An active physical link is a point-to-
point link between the Central and a Peripheral. A Connectionless Peripheral Broadcast
physical link is a point-to-multipoint link between the Transmitter (Central) and zero or
more Receivers (Peripherals). At least one physical link on the piconet physical channel
is always present when a Peripheral is synchronized in the piconet.

3.4.1.1 Active physical link

The physical link between a Central and a Peripheral is active if a default ACL logical
transport exists between the devices. Active physical links have no direct identification
of their own, but are identified by association with the default ACL logical transport ID
with which there is a one-to-one correspondence.

An active physical link has the associated property of radio transmit power in each
direction. Transmissions from Peripherals are always directed over the active physical
link to the Central, and use the transmit power that is a property of this link in the
Peripheral to Central direction. Transmissions from the Central may be directed over a
single active physical link (to a specific Peripheral) or over a number of physical links
(to a group of Peripherals in the piconet). In the case of point-to-point transmissions
the Central uses the appropriate transmit power for the physical link in question. (In the
case of point-to-multipoint transmissions the Central uses a transmit power appropriate
for the set of devices addressed.)

Active physical links may be placed into Hold or Sniff mode. The effect of these modes
is to modify the periods when the physical link is active and may carry traffic. Logical
transports that have defined scheduling characteristics are not affected by these modes
and continue according to their pre-defined scheduling behavior. The default ACL
logical transport and other links with undefined scheduling characteristics are subject
to the mode of the active physical link.

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 1, Part A Page 277
Architecture

3.4.1.2 [This section is no longer used]

3.4.1.3 Connectionless Peripheral Broadcast physical link

A Connectionless Peripheral Broadcast physical link is present on a Receiver

(Peripheral) when it is synchronized in the piconet where a CPB logical transport
exists. On a Transmitter (Central), a Connectionless Peripheral Broadcast physical
link is present when a CPB logical transport exists whether or not any Receivers
are synchronized. The Connectionless Peripheral Broadcast physical link is a point-to-
multipoint unidirectional link between a Transmitter and zero or more Receivers.

Connectionless Peripheral Broadcast physical links do not support power control

because there is no feedback from Receivers to the Transmitter. Traffic is always
directed from a single Transmitter to zero or more Receivers.

Connectionless Peripheral Broadcast packets are sent at regular intervals. The BR/EDR
Controller selects an interval within a range requested by the Host.

3.4.2 BR/EDR links supported by the scanning physical channels

In the case of inquiry scan and page scan channels, the physical link exists for a
relatively short time and cannot be controlled or modified in any way. These types of
physical links are not further elaborated.

3.4.3 LE links supported by the LE physical channels

The LE piconet physical channels support an LE active physical link. The physical link is
a point-to-point link between the Central and a Peripheral. It is always present when the
Peripheral is in a connection with the Central.

The LE advertising physical channels support an LE advertising physical link. The

physical link is a broadcast between the advertiser device and one or more scanner or
initiator devices. It is always present when the advertiser is broadcasting advertisement
events.

The LE periodic physical channels support an LE periodic physical link. The physical
link is a broadcast between the advertiser device and one or more scanner devices. It is
always present when the advertiser is broadcasting periodic advertising events.

The LE isochronous physical channels support LE isochronous physical links. An

LE isochronous physical link can be a point-to-point link between a Central and a
Peripheral or a connectionless link between a broadcast isochronous transmitter and
multiple receiving devices.
3.4.3.1 Active physical link

The physical link between a Central and a Peripheral is active if a default LE ACL
logical transport exists between the devices. Active physical links are each associated

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 1, Part A Page 278
Architecture

with a separate piconet physical channel, which in turn is identified by the randomly
generated Access Address used in the Link Layer packet. Each Access Address has a
one-to-one relationship with the Central and the Peripheral of the active physical link.

An active physical link has the associated property of radio transmit power in each
direction, which may be different in each direction. A device uses the appropriate
transmit power for the physical link in question.

3.4.3.2 Advertising physical link

An advertising physical link between an advertising device and an initiating device for
the purposes of forming a connection (active physical link) can exist for a relatively short
period of time. These advertising physical links cannot be controlled or modified in any
way and these types of physical links are not further elaborated.

An advertising physical link between an advertising device and a scanning device used
for periodic broadcasting of user data can exist for longer periods of time. There is
no identification information about the physical link within the protocol. The relationship
between the advertising and scanning device is established through the use of the
Bluetooth Device Address.

3.4.3.3 Periodic physical link

A periodic physical link between an advertising device and one or more scanning
devices normally exists for a prolonged period of time. Periodic physical links are each
associated with a separate periodic physical channel, which in turn is identified by
the randomly generated Access Address used in the Link Layer packet. Each Access
Address has a one-to-one relationship with the advertiser of the periodic physical link.

3.4.3.4 Isochronous physical links

The isochronous physical link uses an isochronous physical channel and carries CIS
and BIS logical transports.

Isochronous physical links carrying CIS(es) use the appropriate transmit power level for
the physical link in question. Devices use power control on the associated ACL-C logical
link to adapt the transmit power level for the physical link.

Isochronous physical links carrying BIS(es) do not support power control because there
is no feedback from Observers to the Broadcaster. Traffic is always directed from a
single Broadcaster to zero or more Observers.

3.4.3.5 Channel Sounding physical link

Channel Sounding procedures exist within an LE Channel Sounding physical link

and are characterized by their transitory existence as well as their unique timing

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 1, Part A Page 279
Architecture

characteristics relative to an LE active physical link. Channel Sounding procedures are

based on a preexisting LE active physical link. A CS procedure’s start timing is also
dependent on the timing of the corresponding LE active physical link.

A Channel Sounding physical channel supports a Channel Sounding physical link.

3.4.4 [This section is no longer used]

3.5 Logical links and logical transports

A variety of logical links are available to support different application data transport
requirements. Each logical link is associated with a logical transport, which has a
number of characteristics. These characteristics include flow control, acknowledgment/
repeat mechanisms, sequence numbering and scheduling behavior. Logical transports
are able to carry different types of logical links (depending on the type of the logical
transport). In the case of some of the Bluetooth logical links these are multiplexed onto
the same logical transport. Logical transports may be carried by active physical links on
either the basic or the adapted piconet physical channel.

Logical transport identification and real-time (link control) signaling are carried in the
packet header, and for some logical links identification is carried in the payload header.
Control signaling that does not require single slot response times is carried out using
the LMP protocol.

Table 3.4 lists all of the logical transport types, the supported logical link types, which
type of physical links and physical channels can support them, and a brief description of
the purpose of the logical transport.

Logical Links supported Supported by Bearer Overview

transport
Asynchronous Control (LMP) BR/EDR active BR/EDR Reliable or time-boun-
Connection-Ori- ACL‑C physical link, ded, bi-directional,
ented (ACL) BR/EDR basic or point-to-point
User (L2CAP)
adapted piconet
ACL‑U
physical channel
Synchronous Stream (un- BR/EDR active BR/EDR Bi-directional, symmet-
Connection-Ori- framed) SCO-S physical link, ric, point-to-point, AV
ented (SCO) BR/EDR basic or channels. Used for 64
adapted piconet kb/s constant rate data.
physical channel

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 1, Part A Page 280
Architecture

Logical Links supported Supported by Bearer Overview

transport
Extended Syn- Stream (un- BR/EDR active BR/EDR Bi-directional, symmet-
chronous Con- framed) eSCO-S physical link, ric or asymmetric,
nection-Oriented BR/EDR basic or point-to-point, general
(eSCO) adapted piconet regular data, limited
physical channel retransmission. Used
for constant rate da-
ta synchronized to the
Central’s clock.
Active Peripheral Control (LMP) BR/EDR active BR/EDR Unreliable, uni-direc-
Broadcast (APB) physical link, ba- tional broadcast to any
APB‑C
sic or adapted devices synchronized
User (L2CAP) physical channel with the physical chan-
APB‑U nel. Used for broadcast
L2CAP groups and cer-
tain LMP messages.
Connectionless Profile Broadcast Connectionless BR/EDR Unreliable, unidirec-
Peripheral Broad- Data (PBD) Peripheral Broad- tional, point-to-multi-
cast (CPB) cast physical link, point, periodic trans-
BR/EDR adapted missions to zero or
piconet physical more devices.
channel
LE asynchronous Control (LL) LE active physical LE Reliable, bi-directional,
connection (LE LE‑C, User link, LE piconet point-to-point.
ACL (L2CAP) LE‑U physical channel
LE Advertis- Control (LL) LE advertising LE Unreliable, uni-direc-
ing Broadcast ADVB‑C, User physical link, LE tional broadcast to all
(ADVB) (LL) ADVB‑U advertising physi- devices in a given area
cal channel or directed to one re-
cipient. Used to carry
data and Link Layer
signaling between un-
connected devices.
LE Periodic Ad- Control (LL) LE periodic phys- LE Unreliable, periodic,
vertising Broad- ADVB‑C, User ical link, LE pe- unidirectional broad-
cast (PADVB) (LL) ADVB‑U riodic physical cast to all devices in a
channel given area.
Periodic Advertis- Control (LL) LE periodic phys- LE Unreliable, periodic
ing with Respon- ADVB-C, User ical link, LE pe- broadcast to all devices
ses (PAwR) (LL) ADVB-U riodic physical or a subset of devices
channel in a given area with op-
tional responses from
the devices.

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 1, Part A Page 281
Architecture

Logical Links supported Supported by Bearer Overview

transport
Connected Iso- Low Energy LE isochronous LE Unidirectional or bidir-
chronous Stream Stream (LE‑S) physical link ectional transport in a
and Low Ener- point-to-point connec-
gy Framed data tion for transferring iso-
(LE‑F) chronous data.
Broadcast Iso- Low Energy LE isochronous LE Unidirectional transport
chronous Stream Stream (LE‑S), physical link for broadcasting data
Low Energy in a point to multipoint
Framed data configuration and uni-
(LE‑F) and Low directional transport for
Energy Broadcast controlling the broad-
Control (LEB‑C) cast data.

Table 3.4: Logical transport types

The classification of each link type follows from a selection procedure within three
categories.

3.5.1 Casting

The first category is that of casting. This may be either unicast or broadcast.

• Unicast links exist between exactly two endpoints. Traffic may be sent in either
direction on unicast links.
• Broadcast links exist between one source device and zero or more receiver devices.
Traffic is unidirectional, i e., only sent from the source devices to the receiver devices.
Broadcast links are connectionless, meaning there is no procedure to create these
links, and data may be sent over them at any time. Broadcast links are unreliable, and
there is no guarantee that the data will be received.

3.5.2 Scheduling and acknowledgment scheme

The second category relates to the scheduling and acknowledgment scheme of the link,
and implies the type of traffic that is supported by the link. These are synchronous,
isochronous or asynchronous. There are no specific isochronous links defined, though
the default ACL link can be configured to operate in this fashion.

• Synchronous links provide a method of associating the transported data with the
Bluetooth piconet clock. This is achieved by reserving regular slots on the physical
channel, and transmitting fixed size packets at these regular intervals. Such links are
suitable for constant rate isochronous data.
• Asynchronous links provide a method for transporting data that has no time-based
characteristics. The data is normally expected to be retransmitted until successfully
received, and each data entity can be processed at any time after receipt, without

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 1, Part A Page 282
Architecture

reference to the time of receipt of any previous or successive entity in the stream
(providing the ordering of data entities is preserved).
• Isochronous links provide a method for transporting data that has time-based
characteristics. The data may be retransmitted until received or expired. The data rate
on the link need not be constant (this being the main difference from synchronous
links).

3.5.3 Class of data

The final category is related to the class of data that is carried by the link. This is
either control data or user data. The user data category is sub-divided into L2CAP data,
stream data, and periodic broadcast data.

• Control links are only used for transporting LMP or Link Layer messages between
two Controllers. These links are invisible above the baseband layer or Link Layer and
cannot be directly instantiated, configured, or released by applications, other than by
the use of the services, such as connection and disconnection, that have this effect
implicitly. Control links are always multiplexed with an equivalent L2CAP data link
onto a logical transport. For example, ACL-C and ACL-U are multiplexed onto an
ACL logical transport, whereas ADVB-C and ADVB-U are multiplexed onto ADVB and
PADVB logical transports. Subject to the rules defining the acknowledgment scheme,
the control link traffic normally takes priority over the L2CAP link traffic.
• L2CAP links are used to transport L2CAP PDUs, which may carry the L2CAP
signaling channel or framed user data submitted to user-instantiated L2CAP
channels. L2CAP frames submitted to the baseband may be larger than the available
Baseband packets. A link control protocol embedded within the LLID field preserves
the frame-start and frame-continuation semantics when the frame is transmitted in a
number of fragments to the receiver. Normally, L2CAP links give reliable delivery of
data priority over timely delivery.
• Stream links are used to transport user data when timely delivery of the latest data
has priority over reliability. Lost data may be replaced by padding at the receiver.
On BR/EDR, these links (SCO and eSCO) have a fixed bandwidth and are always
bidirectional between two devices; on LE, they have a variable bandwidth with a
specified maximum and may be either bidirectional between two devices (CIS) or
unidirectional broadcast (BIS).
• Periodic broadcast data is transmitted at regular intervals, possibly with jitter, by a
device. It has no acknowledgment mechanism. The same data is transmitted until
it is explicitly changed. This is sent on the PBD logical link on BR/EDR and on the
ADVB-U logical link on LE.

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 1, Part A Page 283
Architecture

3.5.4 Logical transports

3.5.4.1 BR/EDR asynchronous connection-oriented (ACL)

The asynchronous connection-oriented (ACL) logical transport is used to carry LMP

and L2CAP control signaling and best effort asynchronous user data. The ACL logical
transport uses a 1-bit ARQN/SEQN scheme to provide simple channel reliability. Every
active Peripheral within a piconet has one ACL logical transport to the piconet Central,
known as the default ACL.

The default ACL is created between the Central and the Peripheral when a device joins
a piconet (connects to the basic piconet physical channel). This default ACL is assigned
a logical transport address (LT_ADDR) by the piconet Central. This LT_ADDR is also
used to identify the active physical link when required (or as a piconet active member
identifier, effectively for the same purpose).

The LT_ADDR for the default ACL is reused for synchronous connection-oriented
logical transports between the same Central and Peripheral. Thus the LT_ADDR is
not sufficient on its own to identify the default ACL. However the packet types used on
the ACL are different from those used on the synchronous connection-oriented logical
transport. Therefore, the ACL logical transport can be identified by the LT_ADDR field in
the packet header in combination with the packet type field.

The default ACL may be used for isochronous data transport by configuring it to
automatically flush packets after the packets have expired. Asynchronous traffic can
be sent over an ACL logical transport configured for isochronous traffic by marking
the asynchronous packets as non-automatically-flushable. This allows both isochronous
and asynchronous traffic to be transferred at the same time to a single device.

If the default ACL is removed from the active physical link then all other logical
transports that exist between the Central and the Peripheral are also removed. In
the case of unexpected loss of synchronization to the piconet physical channel the
physical link and all logical transports and logical links cease to exist at the time that this
synchronization loss is detected.

3.5.4.2 BR/EDR synchronous connection-oriented (SCO)

The synchronous connection-oriented (SCO) logical transport is a symmetric, point-

to-point transport between the Central and a specific Peripheral. The SCO logical
transport reserves slots on the physical channel and can therefore be considered as
a circuit-switched connection between the Central and the Peripheral. SCO logical
transports carry 64 kb/s of information synchronized with the piconet clock. Typically
this information is an encoded voice stream. Three different SCO configurations exist,
offering a balance between robustness, delay and bandwidth consumption.

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 1, Part A Page 284
Architecture

Each SCO-S logical link is supported by a single SCO logical transport, which is
assigned the same LT_ADDR as the default ACL logical transport between the devices.
Therefore the LT_ADDR field is not sufficient to identify the destination of a received
packet. Because the SCO links use reserved slots, a device uses a combination of the
LT_ADDR, the slot numbers (a property of the physical channel) and the packet type to
identify transmissions on the SCO link.

Although slots are reserved for the SCO, it is permissible to use a reserved slot for
traffic from another channel that has a higher priority. This may be required as a result
of QoS commitments, or to send LMP signaling on the default ACL when the physical
channel bandwidth is fully occupied by SCOs. As SCOs carry different packet types to
ACLs, the packet type is used to identify SCO traffic (in addition to the slot number and
LT_ADDR).

There are no further architectural layers defined by the specification that are transported
over a SCO link. A number of standard formats are defined for the 64 kb/s stream that
is transported, or an unformatted stream is allowed where the application is responsible
for interpreting the encoding of the stream.

3.5.4.3 BR/EDR extended synchronous connection-oriented (eSCO)

The extended synchronous connection-oriented (eSCO) logical transport is a symmetric

or asymmetric, point-to-point transport between the Central and a specific Peripheral.
The eSCO reserves slots on the physical channel and can therefore be considered as a
circuit-switched connection between the Central and the Peripheral. eSCO links offer a
number of extensions over the standard SCO links, in that they support a more flexible
combination of packet types and selectable data contents in the packets and selectable
slot periods, allowing a range of synchronous bit rates to be supported.

eSCO links also can offer limited retransmission of packets (unlike SCO links where
there is no retransmission). If these retransmissions are required they take place in the
slots that follow the reserved slots, otherwise the slots may be used for other traffic.

Each eSCO-S logical link is supported by a single eSCO logical transport, identified by
a LT_ADDR that is unique within the piconet for the duration of the eSCO. eSCO-S links
are created using LM signaling and follow scheduling rules similar to SCO-S links.

There are no further architectural layers defined by the specification that are transported
over an eSCO-S link. Instead applications may use the data stream for whatever
purpose they require, subject to the transport characteristics of the stream being
suitable for the data being transported.

3.5.4.4 BR/EDR active Peripheral broadcast (APB)

The active Peripheral broadcast logical transport is used to transport LMP control
signaling and connectionless L2CAP user traffic to all devices in the piconet that are

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 1, Part A Page 285
Architecture

currently connected to the physical channel that is used by the APB. There is no
acknowledgment protocol and the traffic is uni-directional from the piconet Central to the
Peripherals. The APB channel may be used for L2CAP group traffic (a legacy of the
1.1 specification), and is never used for L2CAP connection-oriented channels or L2CAP
control signaling.

The APB logical transport is inherently unreliable because of the lack of

acknowledgment. To improve the reliability, each packet is transmitted a number of
times. An identical sequence number is used to assist with filtering retransmissions at
the Peripheral.

The APB logical transport is identified by a reserved LT_ADDR.

An APB is implicitly created whenever a piconet exists, and there is always one APB
associated with each of the active physical links (whether operating over the basic
or adapted piconet physical channel) that exist within the piconet. Because the basic
and adapted piconet physical channels, and different channel maps on the adapted
piconet physical channel, are mostly coincident, a Peripheral cannot always distinguish
which of the APB channels is being used to transmit the packets. This adds to the
general unreliability of the APB channel. (Although it is, perhaps, no more unreliable
than general missed packets.)

A Central may decide to use only one of its two possible APBs (when it has both a basic
and adapted piconet physical channel), or only one of the channel maps in use on the
adapted piconet physical channel (when it has more than one map), as with sufficient
retransmissions or careful selection of which slots to transmit on it is possible to address
all Peripherals.

The APB channel is never used to carry L2CAP control signals.

3.5.4.5 [This section is no longer used]

3.5.4.6 LE asynchronous connection (LE ACL)

The LE asynchronous connection (LE ACL) logical transport is used to carry LL and
L2CAP control signaling and best effort asynchronous user data. The LE ACL logical
transport uses a 1-bit NESN/SN scheme to provide simple channel reliability. Every
active Peripheral has one LE ACL logical transport to the piconet Central, known as the
default LE ACL.

The default LE ACL is automatically created between the Central and the Peripheral
when the piconet connecting them is created. This default LE ACL is assigned an
Access Address by the piconet Central. This Access Address is also used to identify the
active physical link and active piconet physical channel when required.

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 1, Part A Page 286
Architecture

If the default LE ACL is removed from the LE active physical link then all other LE
logical transports that exist between the Central and the Peripheral are also removed. In
the case of unexpected loss of synchronization to the LE piconet physical channel the
LE physical link and all LE logical transports and LE logical links cease to exist at the
time that this synchronization loss is detected.

3.5.4.7 LE advertising broadcast (ADVB)

The LE advertising broadcast logical transport is used to transport broadcast control

and user data to all scanning devices in a given area. There is no acknowledgment
protocol and the traffic is predominately unidirectional from the advertising device. A
scanning device can send requests over the logical transport to get additional broadcast
user data, or to form an LE ACL logical transport connection. The LE Advertising
Broadcast logical transport data is carried only over the LE advertising broadcast link.

The ADVB logical transport is inherently unreliable because of the lack of

acknowledgment. To improve the reliability, each packet is transmitted a number of
times over the LE advertising broadcast link.

An ADVB is created whenever an advertising device begins advertising. The ADVB

logical transport is identified by the advertiser's Bluetooth Device Address and
advertising set.

3.5.4.8 Connectionless Peripheral Broadcast (CPB)

The CPB logical transport is used to transport profile broadcast data to all devices
connected to the Connectionless Peripheral Broadcast logical transport. There is no
acknowledgment scheme and the traffic is unidirectional from a Transmitter to zero
or more Receivers. To improve reliability, profile broadcast data may be transmitted
multiple times.

The CPB logical transport is created on the transmitter whenever the Connectionless
Peripheral Broadcast is started. The CPB logical transport is created on the receiver
whenever Connectionless Peripheral Broadcast reception is configured. The CPB
logical transport is identified by a unique LT_ADDR within the piconet that is reserved
specifically for that purpose by the Connectionless Peripheral Broadcast Transmitter.

3.5.4.9 LE periodic advertising

3.5.4.9.1 LE periodic advertising broadcast (PADVB)

The LE periodic advertising broadcast logical transport is used to transport periodic

broadcast control and user data to all scanning devices in a given area. The data may
be constant for several periods or may change frequently. There is no acknowledgment
protocol and the traffic is unidirectional from the advertising device. The LE Periodic

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 1, Part A Page 287
Architecture

Advertising Broadcast logical transport data is carried only over the LE periodic physical
link.

The PADVB logical transport is inherently unreliable because of the lack of

acknowledgment. To improve the reliability, the period between transmissions can be
shorter than the interval between changes to the data so that each packet can be
transmitted a number of times over the LE periodic physical link.

A PADVB is created whenever an advertising device begins periodic advertising. The

PADVB logical transport is identified by the advertiser's Bluetooth Device Address,
timing, and advertising set.

3.5.4.9.2 Periodic advertising with responses (PAwR)

The LE periodic advertising with responses logical transport is used to transport

periodic broadcast control and user data to all scanning devices in a given area.
These broadcasts are grouped into subevents, allowing a subset of the devices to
be synchronized with each subevent. Each subevent can then contain information that
is directed to the subset of devices synchronized to that subevent. This allows the
broadcasting device to send data to many devices and the synchronized devices to
only have to listen very infrequently for information directed to them. The data may be
constant for several periods or may change frequently. The PAwR logical transport data
is carried only over the LE periodic physical link.

The PAwR logical transport also includes response slots. The devices that have
been directly addressed by the advertising device use response slots to send back
responses. A higher layer specification determines the set of devices that can respond
and when they respond. The PAwR logical transport is inherently unreliable, but the
ability to use response slots allows higher layer acknowledgments to be used to provide
reliability.

A PAwR logical transport is created whenever an advertising device begins periodic

advertising configured to use subevents and responses. The PAwR logical transport is
identified by the advertiser's Bluetooth Device Address, timing, and advertising set.

3.5.4.10 Connected Isochronous Stream (CIS)

The CIS is a data-symmetric or data-asymmetric, point-to-point logical transport

between the Central and a specific Peripheral. A CIS reserves transmission/reception
(Tx/Rx) periods, known as subevents, on the isochronous physical channel and can be
considered as a circuit switched connection between the Central and the Peripheral.
The CIS supports a variable flushing period for payloads, variable size data contents
in the packets, and a variable number of subevents, allowing a range of isochronous
data rates, latencies, and re-transmissions to be supported. A CIS can be configured
to retransmit packets by providing more subevents than required for transmitting the

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 1, Part A Page 288
Architecture

data. If retransmissions are required, they take place in the subevents (of the current or
subsequent events) that follow.

Each LE-S or LE-F logical link is supported by a single CIS that is identified by a unique
access address for the lifetime of the CIS. The LE-S or LE F links are created by using
Link Layer procedures. The higher layer may use the data stream for whatever purpose
it requires, as long as the transport characteristics of the stream are suitable for the
data that is being transported. All isochronous connections are terminated when the
associated LE piconet physical channel is terminated.

3.5.4.11 Connected Isochronous Group (CIG)

Each CIS is part of a CIG. A CIG may have one or more CISes, all with the same
Central but possibly different Peripherals. Multiple CISes in a CIG have a common
timing reference based on the Central timing and are synchronized in time. The
common timing reference of multiple CISes helps devices to synchronize their input
or output data. For example, when the left and right channels of an audio stereo stream,
which are received by separate devices, need to be rendered at the same time. Multiple
CISes in a CIG can be scheduled sequentially or in an interleaved arrangement.

3.5.4.12 Broadcast Isochronous Stream (BIS)

The BIS logical transport is used to transport one or more isochronous data streams to
all devices for a BIS within range. The data may be fixed or variable size, framed or
unframed. A BIS has one or more subevents for transmitting isochronous data packets.
A BIS supports transmission of multiple new isochronous data packets in every BIS
event. There is no acknowledgment protocol and the traffic is unidirectional from the
broadcasting device. The BIS logical transport is inherently unreliable because of the
lack of acknowledgment. To improve the reliability of delivery, the isochronous data
packets can be unconditionally re-transmitted by increasing the number of subevents in
every event. The reliability of delivery can also be improved by transmitting packets
in intervals earlier than the intervals they are associated with; this is called "pre-
transmission". A BIS supports LE-S or LE-F logical links. A BIS is identified by a
unique access address and the timing information. The access address and the timing
information is transmitted in the packet that is sent using the associated Periodic
Advertising Broadcast (PADVB) logical transport. A scanning device that supports the
Synchronized Receiver role feature may receive isochronous data from a BIS after
synchronizing to the BIS by using the timing information from the periodic advertising
train.

3.5.4.13 Broadcast Isochronous Group (BIG)

Each BIS is part of a BIG. A BIG may have one or more BISes. Multiple BISes in a
BIG have a common timing reference based on the broadcaster and are synchronized
in time. For example, when the left and right channels of an audio stereo stream, which

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 1, Part A Page 289
Architecture

are received by separate devices, need to be rendered at the same time. Multiple BISes
in a BIG can be scheduled sequentially or in an interleaved arrangement. A BIG also
supports a Low Energy Broadcast Control (LEB-C) logical link.

3.5.5 Logical links

Some logical transports are capable of supporting different logical links, either
concurrently multiplexed, or one of the choice.

3.5.5.1 BR/EDR logical links

Within BR/EDR logical transports, the logical link is identified by the logical link identifier
(LLID) bits in the payload header of Baseband packets that carry a data payload. The
logical links distinguish between a limited set of core protocols that are able to transmit
and receive data on the logical transports. Not all of the logical transports are able to
carry all of the logical links (the supported mapping is shown in Figure 3.2). In particular
the BR/EDR SCO and eSCO logical transports are only able to carry constant data rate
streams, and these are uniquely identified by the LT_ADDR. Such logical transports
only use packets that do not contain a payload header, as their length is known in
advance, and no LLID is necessary.

3.5.5.1.1 ACL control logical links (ACL‑C and APB‑C)

The ACL Control Logical Links (ACL-C and APB-C) are used to carry BR/EDR LMP
signaling between devices in the piconet. The ACL-C control link is normally only
carried on the default ACL logical transport (though can also be carried in DV packets
on the SCO logical transport) while the APB-C control link is only carried on the APB
logical transport. Each control link is always given priority over the corresponding data
link carried on the same logical transport.

3.5.5.1.2 User asynchronous/isochronous logical links (ACL-U and APB-U)

The user asynchronous/isochronous logical links (ACL-U and APB-U) are used to carry
all asynchronous and isochronous framed user data. The ACL-U link is normally only
carried on the default ACL logical transport (though can also be carried in DV packets
on the SCO logical transport) while the APB-U link is only carried on the APB logical
transport. Packets on the ACL-U and APB-U link are identified by one of two reserved
LLID values. One value is used to indicate that the Baseband packet contains the start
of an L2CAP frame and the other indicates a continuation of a previous frame. This
ensures correct synchronization of the L2CAP reassembler following flushed packets.
The use of this technique removes the need for a more complex L2CAP header in every
Baseband packet (the header is only required in the L2CAP start packets) because
each L2CAP frame is completely transmitted before the next one starts. (An exception
to this rule being the ability to flush a partially transmitted L2CAP frame in favor of
another L2CAP frame.)

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 1, Part A Page 290
Architecture

3.5.5.1.3 User synchronous/extended synchronous logical links (SCO‑S/eSCO‑S)

Synchronous (SCO-S) and extended synchronous (eSCO-S) logical links are used
to support isochronous data delivered in a stream without framing. These links are
associated with a single logical transport, where data is delivered in constant sized units
at a constant rate. There is no LLID within the packets on these transports, as only a
single logical link can be supported, and the packet length and scheduling period are
pre-defined and remain fixed during the lifetime of the link.

Variable rate isochronous data cannot be carried by the SCO-S or eSCO-S logical links.
In this case the data must be carried on ACL-U or APB-U logical links, which use
packets with a payload header.

3.5.5.1.4 Profile Broadcast Data (PBD) logical link

The PBD logical link is used to broadcast isochronous unframed data to multiple
receivers and resides on the CPB logical transport.

3.5.5.2 LE logical links

Within LE logical transports, the logical link is identified by the logical link identifier
(LLID) bits in the payload header of Baseband packets that carry a data payload. The
logical links distinguish between a limited set of core protocols that are able to transmit
and receive data on the logical transports. Not all of the logical transports are able to
carry all of the logical links (the supported mapping is shown in Figure 3.2).

3.5.5.2.1 Control logical link (LE-C)

The LE ACL Control Logical Link (LE-C) is used to carry LE LL signaling between the
two devices in the piconet. The control link is only carried on the default LE ACL logical
transport.

3.5.5.2.2 User asynchronous logical link (LE-U)

The user asynchronous logical link (LE-U) is used to carry all asynchronous and framed
user data. The LE-U link is carried on the LE logical transport. Packets on the LE-U link
are identified by one of two reserved LLID values. One value is used to indicate that
the Baseband packet contains the start of an L2CAP frame and the other indicates a
continuation of a previous frame or empty PDU. This ensures correct synchronization
of the L2CAP re-assembler. The use of this technique removes the need for a more
complex L2CAP header in every Baseband packet because each L2CAP frame is
completely transmitted before the next one starts.

3.5.5.2.3 Advertising Broadcast Control logical link (ADVB-C)

The LE Advertising Broadcast Control Logical Link (ADVB-C) is used to carry LE LL

signaling between unconnected devices in a given area. This signaling is the control

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 1, Part A Page 291
Architecture

commands for gathering additional broadcast user data (scan requests) or connection
requests. The control link is carried on the LE Advertising Broadcast and LE Periodic
Advertising Broadcast logical transports.

3.5.5.2.4 Advertising Broadcast User Data logical link (ADVB-U)

The LE Advertising Broadcast User Data Logical Link (ADVB-U) is used to carry LE
Advertising Broadcast and LE Periodic Advertising Broadcast user data used between
devices without the need for a connection or LE-U between the devices. The user
data link is carried on the LE Advertising Broadcast logical transport for LE Advertising
Broadcast user data and the LE Periodic Advertising Broadcast logical transport for LE
Periodic Advertising Broadcast user data.

3.5.5.2.5 Low Energy Stream (LE-S)

An LE-S is a logical link that is used to carry the unframed isochronous data packets of
an isochronous data stream in a CIS or a BIS logical transport.

3.5.5.2.6 Low Energy Framed (LE-F)

An LE-F is a logical link that is used to carry the framed isochronous data packets of an
isochronous data stream in a CIS or a BIS logical transport.

3.5.5.2.7 Low Energy Broadcast Control (LEB-C)

An LEB-C is a logical link that uses the BIS logical transport to carry the control
information for all the BISes in a BIG.

3.5.5.3 [This section is no longer used]

3.6 L2CAP channels

L2CAP provides a multiplexing role allowing many different applications to share an
ACL-U, APB-U, or LE-U logical link. Applications and service protocols interface with
L2CAP using a channel-oriented interface to create connections to equivalent entities
on other devices.

L2CAP channel endpoints are identified to their clients by a Channel Identifier (CID).
This is assigned by L2CAP, and each L2CAP channel endpoint on any device has a
different CID.

L2CAP channels may be configured to provide an appropriate Quality of Service (QoS)

to the application. L2CAP maps the channel onto the ACL-U, APB-U, or LE-U logical
link.

L2CAP supports channels that are connection-oriented and others that are group-
oriented. Group-oriented channels may be mapped onto the APB-U logical link, or

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 1, Part A Page 292
Architecture

implemented as iterated transmission to each member in turn over an ACL-U logical

link.

Apart from the creation, configuration and dismantling of channels, the main role of
L2CAP is to multiplex service data units (SDUs) from the channel clients onto the
ACL-U, APB-U, or LE-U logical link, and to carry out a simple level of scheduling,
selecting SDUs according to relative priority.

L2CAP can provide per channel flow control with the peer L2CAP layer (except on
the APB-U logical link). This option is selected by the application when the channel is
established. L2CAP can also provide enhanced error detection and retransmission to
(a) reduce the probability of undetected errors being passed to the application and (b)
recover from loss of portions of the user data when the Baseband performs a flush on
the ACL-U logical link.

In the case where an HCI is present, the L2CAP is also required to segment L2CAP
SDUs into fragments that will fit into the baseband buffers, and also to operate a token
based flow control procedure over the HCI, submitting fragments to the baseband only
when allowed to do so. This may affect the scheduling algorithm.

3.7 Isochronous Adaptation Layer (ISOAL)

The ISOAL provides a mechanism such that the timing used to generate or receive
isochronous data in the upper layer can be independent of the timing used in the CIS
or BIS logical transport used to carry the isochronous data. For example, audio codec
data can be generated at a 10 ms interval while the value of ISO_Interval for the CIS
can be 11.25 ms. The ISOAL converts upper layer isochronous data units to lower layer
isochronous data packets (or the other way around). For more information, see [Vol 6]
Part G.

3.8 Power control

The power control feature provides a mechanism to request a remote device to

adjust its transmit power level based on local signal quality information. The feature
is supported on BR/EDR active physical links (see Section 3.4.1.1) and on LE active
physical links (see Section 3.4.3.1).

3.8.1 Power control in BR/EDR

In BR/EDR, two power control mechanisms (legacy and enhanced power control) are
available. Both mechanisms support requesting an incremental change in transmit
power level. The enhanced power control mechanism also allows requesting a change
to maximum transmit power level. The requested change is applied on all supported
modulations at once since the modulation can change dynamically between packets.

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 1, Part A Page 293
Architecture

3.8.2 Power control in LE

In LE, a device can request a remote device to make a specified change in the remote
device's power level on a given PHY. This allows a faster transition to the desired power
level compared to incremental changes. A responding device can also return a value
to indicate an acceptable reduction in the power level that allows the requesting device
to further reduce its transmit power level to the minimum level possible and hence
conserve energy. The local and remote devices can also share their current transmit
power levels during this exchange to enable devices to calculate the link path loss
between them. Devices are also allowed to do autonomous local transmit power level
changes and indicate the change to the remote device.

In LE, an ACL connection can have associated connections like CIS(es). The power
control for all the PHYs used on the ACL and associated connections is managed over
the ACL connection. The Host can use the connection handle of the ACL connection to
retrieve information for all PHYs used on the ACL and associated connections.

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 1, Part A Page 294
Architecture

4 COMMUNICATION TOPOLOGY AND OPERATION

4.1 Piconet topology

4.1.1 BR/EDR topology

Any time a link is created using the BR/EDR Controller it is within the context of a
piconet. Each link connects two devices, called the “Central” and “Peripheral”. A piconet
consists of a single Central, known as the Central of the piconet, and all the Peripherals
linked to it, known as the Peripherals in the piconet.

Connected BR/EDR devices communicate on the same physical channel by

synchronizing with a common clock and hopping sequence. The common (piconet)
clock is identical to the Bluetooth clock of the Central of the piconet and the hopping
sequence is derived from the Central’s clock and the Central’s Bluetooth Device
Address (different hopping sequences may be used for different Peripherals).

The terms Central and Peripheral are only used when describing these roles in a
piconet.

A number of independent piconets may exist in close proximity. Each piconet has a
different physical channel (that is a different Central and an independent timing and
hopping sequence).

A Bluetooth device may participate concurrently in two or more piconets. It does this on
a time-division multiplexing basis. A Bluetooth device can never be a Central of more
than one piconet. (Since in BR/EDR the piconet is defined by synchronization to the
Central’s Bluetooth clock it is impossible to be the Central of two or more piconets.) A
Bluetooth device may be a Peripheral in many independent piconets.

A Bluetooth device that is a member of two or more piconets is said to be involved in

a scatternet. Involvement in a scatternet does not necessarily imply any network routing
capability or function in the Bluetooth device. The Bluetooth core protocols do not, and
are not intended to offer such functionality, which is the responsibility of higher level
protocols and is outside the scope of the specification.

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 1, Part A Page 295
Architecture

Adapted piconet
A physical channel F

E
H

B Basic piconet
G
physical channel
D

C
Basic piconet
physical channel
M
Basic piconet Inquiry scan
physical channel K
physical channel
J
N
Adapted piconet
physical channel
(Connectionless
L Peripheral Broadcast
physical link)
Synchronization scan
physical channel

Figure 4.1: Example Bluetooth BR/EDR topology

In Figure 4.1 an example topology is shown that demonstrates a number of the

architectural features described below. Device A is a Central in a piconet (represented
by the shaded area, and known as piconet A) with devices B, C, D and E as
Peripherals. Three other piconets are shown: a) one piconet with device F as Central
(known as piconet F) and devices E, G and H as Peripherals, b) one piconet with device
D as Central (known as piconet D) and device J as Peripheral, and c) one piconet with
device M as Central (known as piconet M) and device E as a Peripheral and many
devices N as Peripherals.

In piconet A there are two physical channels. Devices B and C are using the basic
piconet physical channel (represented by the blue enclosure) as they do not support
adaptive frequency hopping. Devices D and E are capable of supporting adaptive
frequency hopping, and are using the adapted piconet physical channel (represented
by the red enclosure). Device A is capable of adaptive frequency hopping, and operates
in a TDM basis on both physical channels according to which Peripheral is being
addressed.

Piconet D and piconet F are both using only a basic piconet physical channel
(represented by the cyan and magenta enclosures respectively). In the case of piconet

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 1, Part A Page 296
Architecture

D this is because device J does not support the adaptive hopping mode. Although
device D supports adaptive hopping it cannot use it in this piconet. In piconet F device F
does not support adaptive hopping, and therefore it cannot be used in this piconet.

Piconet M (represented by the orange enclosure) uses a Connectionless Peripheral

Broadcast physical link over the adaptive piconet physical channel to send Profile
Broadcast Data from the transmitter device M to many Receiver devices including E
and N.

Device K is shown in the same locality as the other devices. It is not currently a member
of a piconet, but has services that it offers to other Bluetooth devices. It is currently
listening on its inquiry scan physical channel (represented by the green enclosure),
awaiting an inquiry request from another device.

Device L is shown in the same locality as the other devices. It is not currently a member
of a piconet, but is currently listening on its synchronization scan physical channel
(represented by the brown enclosure), awaiting a synchronization train from another
device.

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 1, Part A Page 297
Architecture

4.1.2 LE topology

ing
LE Advertis el
ca l C ha nn D
Physi
A
F
el
ha t
nn
l C ne

Phy
ica co

LE l Chan

l
ne
Ch net
ys Pi

sica

an
Pic
Ph LE

ic ico
ys P
one nel

al
Ph LE
H
t

B
I J
G
C
L LE Advertising
Ph E A
ys dv Physical Channel
ica er
l C tisi
ha ng
nn
el
E

ing
LE Advertis el N
hann
K Physical C ing
LE Advertis el
hann R
O Physical C
el
ha t
nn

Phy
l C ne

el
LE l Chan
ica co

ha t
nn

Phy
l C ne
sica
ys Pi

Pic

LE l Chan
ica co
Ph LE

sica
ys Pi
one nel

Pic
Ph LE

one nel
t

L t
P
M
Q

Figure 4.2: Example of Bluetooth LE topology

In Figure 4.2 an example topology is shown that demonstrates a number of the

LE architectural features described below. Device A is a Central in two piconets
(represented by the shaded areas) with devices B and C as the respective Peripherals.
Unlike BR/EDR Peripherals, LE Peripherals do not share a single piconet or a common
physical channel with the Central. Each Peripheral communicates on a separate
physical channel with the Central. One other piconet is shown with device F as Central
and device G as a Peripheral. Device K is in a scatternet. Device K is Central of one
piconet with device L as the Peripheral and is Peripheral of a second piconet with
device M as the Central. Device O is also in a scatternet. Device O is the Peripheral
of two piconets, one with device P as the Central and the other with device Q as the
Central. In the figure, solid arrows point from Central to Peripheral; dashed arrows,

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 1, Part A Page 298
Architecture

indicating a connection initiation, point from initiator to advertiser using a connectable

advertising event; devices that are advertising are indicated using stars.

There are five other groups of devices shown:

1. Device D is an advertiser and device A is also an initiator.

2. Device E is a scanner and device C is also an advertiser.
3. Device H is an advertiser and devices I and J are scanners.
4. Device K is also an advertiser and device N is an initiator.
5. Device R is an advertiser and device O is also an initiator.

Devices A and B are using one LE piconet physical channel (represented by the
blue enclosure and a dark gray background). Devices A and C are using another
LE piconet physical channel (represented by the blue enclosure and a lighter gray
background). Device D is advertising using a connectable advertising event on the
advertising physical channel (represented by the green enclosure) and device A is an
initiator. Device A can form a connection with device D, creating a new piconet. Device
C is also advertising on the advertising physical channel (represented by the orange
enclosure) using any type of advertising events that are being captured by device E
as a scanner. Devices C and D may be using different advertising PHY channels or
different timings to avoid collisions.

Devices F and G are using a piconet and an LE piconet physical channel (represented
by the aqua enclosure). Device F is the Central and device G is the Peripheral.

Devices H, I and J are using the LE advertising physical channel (represented by the
purple enclosure). Device H is an advertiser and devices I and J are scanners.

In the scatternet involving device K, devices K and L are using one piconet and LE
piconet physical channel. Devices K and M are using another piconet and LE piconet
physical channel. Device K is also advertising using a connectable advertising event
on the advertising physical channel and device N is an initiator. Device N can form
a connection with device K resulting in device K being Peripheral of two devices and
Central of one device at the same time.

In the scatternet involving device O, devices O and P are using one piconet and LE
piconet physical channel. Devices O and Q are using another piconet and LE piconet
physical channel. Device R is advertising using a connectable advertising event on
the advertising physical channel and device O is an initiator. Device O can form a
connection with device R resulting in device O being Peripheral of two devices and
Central of one device at the same time.

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 1, Part A Page 299
Architecture

4.2 Operational procedures and modes

The typical operational mode of a Bluetooth device is to be connected to other
Bluetooth devices (in a piconet) and exchanging data with those Bluetooth devices.
As Bluetooth is an ad-hoc wireless communications technology, there are a number
of operational procedures that enable piconets to be formed so that the subsequent
communications can take place. Procedures and modes are applied at different layers
in the architecture and therefore a device may be engaged in a number of these
procedures and modes concurrently.

4.2.1 BR/EDR procedures

4.2.1.1 Inquiry (discovering) procedure

Bluetooth devices use the inquiry procedure to discover nearby devices, or to be

discovered by devices in their locality.

The inquiry procedure is asymmetrical. A Bluetooth device that tries to find other nearby
devices is known as an inquiring device and actively sends inquiry requests. Bluetooth
devices that are available to be found are known as discoverable devices and listen
for these inquiry requests and send responses. The inquiry procedure uses a special
physical channel for the inquiry requests and responses.

Both inquiring and discoverable devices may already be connected to other Bluetooth
devices in a piconet. Any time spent inquiring or occupying the inquiry scan physical
channel needs to be balanced with the demands of the QoS commitments on existing
logical transports.

The inquiry procedure does not make use of any of the architectural layers above the
physical channel, although a transient physical link may be considered to be present
during the exchange of inquiry and inquiry response information.

4.2.1.1.1 Extended Inquiry response

An Extended Inquiry Response can be used to provide miscellaneous information

during the inquiry response procedure. Data types are defined for such things as local
name and supported services, information that otherwise would have to be obtained by
establishing a connection. A device that receives a local name and a list of supported
services in an extended inquiry response does not have to connect to do a remote
name request and an SDP service search, thereby shortening the time to useful
information. It is recommended that a device includes all supported services and a
significant portion of its local name, if that name is too long to be sent in its entirety, in
the extended inquiry response.

Extended inquiry response data can be transmitted encrypted or unencrypted.

Unencrypted data can be interpreted by any device. Encrypted data can be received by

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 1, Part A Page 300
Architecture

any device but can only be decrypted and authenticated by devices that have previously
shared the session key used to encrypt the data.

The extended inquiry response procedure is backwards compatible with the standard
inquiry response procedure.

4.2.1.2 Paging (connecting) procedure

The procedure for forming connections is asymmetrical and requires that one Bluetooth
device carries out the page (connection) procedure while the other Bluetooth device is
connectable (page scanning). The procedure is targeted, so that the page procedure is
only responded to by one specified Bluetooth device.

The connectable device uses a special physical channel to listen for connection request
packets from the paging (connecting) device. This physical channel has attributes that
are specific to the connectable device, hence only a paging device with knowledge of
the connectable device is able to communicate on this channel.

Both paging and connectable devices may already be connected to other Bluetooth
devices. Any time spent paging or occupying the page scan physical channel needs to
be balanced with the demands of the QoS commitments on existing logical transports.

4.2.1.3 Connected mode

After a successful connection procedure over the BR/EDR Controller, there is a piconet
physical channel to which both devices are connected, there is a physical link between
the devices, and there are default ACL-C, ACL-U, APB-C, and APB-U logical links. Two
of these links (ACL-C and APB-C) transport the LMP control protocol and are invisible
to the layers above the Link Manager. The ACL-U link transports the L2CAP signaling
protocol and any multiplexed L2CAP best-effort channels. The APB-U link transports
L2CAP channels that are broadcast to all Peripherals on the piconet. It is common to
refer to a default ACL logical transport, which can be resolved by context, but typically
refers to the default ACL-U logical link.

When in the connected mode it is possible to create and release additional logical links
and to change the modes of the physical and logical links while remaining connected
to the piconet physical channel. It is also possible for the device to carry out inquiry,
paging or scanning procedures or to be connected to other piconets without needing
to disconnect from the original piconet physical channel. These actions are done using
the Link Manager, which exchanges Link Manager protocol messages with the remote
Bluetooth device.

During the time that a Peripheral is actively connected to a piconet there is always a
default ACL logical transport between the Peripheral and the Central. The only method
of deleting the default ACL logical transport is to detach the device from the piconet

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 1, Part A Page 301
Architecture

physical channel, at which time the entire hierarchy of L2CAP channels, logical links,
and logical transports between the devices is deleted.

4.2.1.4 Hold mode

Hold mode is not a general device mode, but applies to unreserved slots on the physical
link. When in this mode, the physical link is only active during slots that are reserved
for the operation of the synchronous link types SCO and eSCO. All asynchronous links
are inactive. Hold modes operate once for each invocation and are then exited when
complete, returning to the previous mode.

4.2.1.5 Sniff mode

Sniff mode is not a general device mode, but applies to the default ACL logical
transports. When in this mode the availability of these logical transports is modified by
defining a duty cycle consisting of periods of presence and absence. Devices that have
their default ACL logical transports in Sniff mode may use the absent periods to engage
in activity on another physical channel, or to enter reduced power mode. Sniff mode
only affects the default ACL logical transports (i.e. their shared ACL logical transport),
and does not apply to any additional SCO or eSCO logical transports that may be
active. The periods of presence and absence of the physical link on the piconet physical
channel is derived as a union of all logical transports that are built on the physical link.

Sniff subrating provides a mechanism for further reducing the active duty cycle, thereby
enhancing the power-saving capability of Sniff mode, by allowing a Host to specify
maximum transmit and receive latencies. This allows the basebands to optimize the low
power performance without having to exit and re-enter Sniff mode using Link Manager
commands.

Broadcast logical transports have no defined expectations for presence or absence.

A Central should aim to schedule broadcasts to coincide with periods of physical
link presence within the piconet physical channel, but this is not always possible or
practical. Repetition of broadcasts is defined to improve the possibilities for reaching
multiple Peripherals without overlapping presence periods. However, broadcast logical
transports cannot be considered to be reliable.

4.2.1.6 [This section is no longer used]

4.2.1.7 Role switch procedure

The role switch procedure is a method for swapping the roles of two devices connected
in a piconet. The procedure involves moving from the physical channel that is defined
by the original Central to the physical channel that is defined by the new Central. In the
process of swapping from one physical channel to the next, the hierarchy of physical
links and logical transports over the BR/EDR Controller are removed and rebuilt, with

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 1, Part A Page 302
Architecture

the exception of the APB logical transport that is implied by the topology and is not
preserved. After the role switch, the original piconet physical channel may cease to exist
or may be continued if the original Central had other Peripherals that are still connected
to the channel.

The procedure only moves the default ACL logical links and supporting layers to
the new physical channel. Any additional logical transports are not copied by this
procedure, and if required this must be carried out by higher layers. The LT_ADDRs of
any affected transports will be reassigned on the new physical channel and, therefore,
may change.

If there are any QoS commitments on the original logical transports, then these are
not preserved after a role switch. These must be renegotiated after the role switch has
completed.

4.2.1.8 Enhanced Data Rate

Enhanced Data Rate is a method of extending the capacity and types of Bluetooth
packets for the purposes of increasing the maximum throughput, providing better
support for multiple connections, and lowering power consumption, while the remainder
of the architecture is unchanged.

Enhanced Data Rate may be selected as a mode that operates independently on

each logical transport. Once enabled, the packet type bits in the packet header
are interpreted differently from their meaning in Basic Rate mode. This different
interpretation is clarified in conjunction with the logical transport address field in the
header. The result of this interpretation allows the packet payload header and payload
to be received and demodulated according to the packet type. Enhanced Data Rate can
be enabled only for the ACL and eSCO logical transports and cannot be enabled for the
SCO and broadcast logical transports.

4.2.1.9 Connectionless Peripheral Broadcast mode

Connectionless Peripheral Broadcast mode allows a piconet Central to transmit profile

broadcast data to any number of connected Peripherals using the BR/EDR adapted
piconet physical channel. To enter this mode, the Central reserves a specific logical
transport address for the CPB logical transport and starts broadcasting data using
the Connectionless Peripheral Broadcast physical link and the synchronization train
procedure. A single Profile Broadcast Data logical link is defined, which carries profile
broadcast data using the Connectionless Peripheral Broadcast logical transport. The
profile broadcast data is unframed and bypasses L2CAP.

To receive the Connectionless Peripheral Broadcast packets, a device must

connect with the Connectionless Peripheral Broadcast Transmitter which has already
established a CPB logical transport. To connect, a device follows the Synchronization

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 1, Part A Page 303
Architecture

Scan procedure to obtain the time schedule of the physical link and then starts receiving
the Connectionless Peripheral Broadcast packets. Once connected, Connectionless
Peripheral Broadcast receivers can receive profile broadcast data on the dedicated CPB
logical transport and PBD logical link.

4.2.2 LE procedures

4.2.2.1 Device filtering procedure

The device filtering procedure is a method for Controllers to reduce the number of
devices requiring communication responses. Since it is not required to respond to
requests from every device, it reduces the number of transmissions an LE Controller is
required to make which reduces power consumption. It also reduces the communication
the Controller would be required to make with the Host. This results in additional power
savings since the Host does not have to be involved.

An advertising or scanning device may employ device filtering to restrict the devices
from which it receives advertising packets, scan requests or connection requests.
In LE, some advertising packets received by a scanning device require that the
scanning device send a request to the advertising device. This advertisement can be
ignored if device filtering is used and the advertising device is being filtered. A similar
situation occurs with connection requests. Connection requests must be responded to
by advertisers unless a device filter is used to limit the devices to which the advertiser is
required to respond. Advertisers can also use device filters to limit the devices in which
it will accept a scan request or connection request.

This device filtering is accomplished through the use of a “Filter Accept List” located in
the LL block of the Controller. A Filter Accept List enumerates the remote devices that
are allowed to communicate with the local device. When a Filter Accept List is in effect,
transmissions from devices that are not in the Filter Accept List will be ignored by the
LL. Since device filtering occurs in the LL it can have a significant impact on power
consumption by filtering (or ignoring) advertising packets, scan requests or connection
requests from being sent to the higher layers for handling.

The use of device filtering during certain procedures needs to be evaluated carefully
to ensure devices are not unintentionally ignored, which may cause interoperability
problems when attempting to establish connections or receive advertising broadcasts.

4.2.2.2 Advertising procedure

An advertiser uses the advertising procedure to perform unidirectional broadcasts to

devices in the area. The unidirectional broadcast occurs without a connection between
the advertising device and the listening devices. The advertising procedure can be
used to establish connections with nearby initiating devices or used to provide periodic
broadcast of user data to scanning devices listening on the advertising physical

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 1, Part A Page 304
Architecture

channel. The advertising procedure uses the primary advertising physical channel for
all advertising broadcasts. However, the data may be offloaded on to the secondary
advertising physical channel in one or more auxiliary packets to reduce both the
occupancy of the primary advertising physical channel and the total on-air time and
also to allow the data to be longer than the maximum that will fit into a single packet.

Advertising data can be transmitted encrypted or unencrypted. Unencrypted data can

be interpreted by any scanning device. Encrypted data can be received by any scanning
device but can only be decrypted and authenticated by devices that have previously
obtained the session key used to encrypt the data.

An LE device connected in an LE piconet may also advertise using any type of

advertising event. Time spent advertising while connected needs to be balanced with
the connection requirements needed to maintain the already established connection(s).

Advertising devices may receive scan requests from listening devices in order to get
additional user data from the advertising device. Scan responses are sent by the
advertising device to the device making the scan request.

An advertising device may receive connection requests from initiator devices. If the
advertising device was using a connectable advertising event and the initiating device
is not being filtered by the device filtering procedure, the advertising device ceases
advertising and enters the connected mode. The device can begin advertising again
after it is in the connected mode.

When advertising on the LE Uncoded PHYs, scan requests and scan responses can
take place on the same PHY channel as the original advertisement or can be offloaded
to the secondary advertising physical channel. In some cases when advertising on
the LE Uncoded PHYs, connection request and connection responses are offloaded to
the secondary advertising physical channel. When advertising on the LE Coded PHY,
scan requests, scan responses, connection requests, and connection responses are
always offloaded. As with advertising data, offloading is carried out by having the initial
advertisement on the primary advertising physical channel point to an auxiliary packet
on the secondary advertising physical channel. Scan requests and scan responses,
connection requests, and connection responses are made on the same PHY and same
physical channel as the auxiliary packet.

4.2.2.3 Scanning procedure

A scanning device uses the scanning procedure to listen for unidirectional broadcasts of
user data from advertising devices using the advertising physical channel. A scanning
device can request additional user data from an advertising device by making a scan
request. The advertising device responds to these requests with additional user data
sent to the scanning device over the advertising physical channel.

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 1, Part A Page 305
Architecture

The scanning procedure can be used while connected to other LE devices. Time spent
scanning while connected needs to be balanced with the connection requirements
needed to maintain the already established connection with the other LE device in each
piconet.

If the broadcasts are connectable advertising events and the scanning device is in
the initiator mode, it can initiate a connection by sending a connection request on the
primary advertising physical channel or secondary advertising physical channel to the
advertising device. Once the connection request is sent on the primary advertising
physical channel, the scanning device ceases the initiator mode scanning for additional
broadcasts and enters the connected mode. When the connection request is sent on
the secondary advertising physical channel, the scanning device leaves the initiator
mode, ceasing scanning for additional broadcasts, and enters the connected mode
when it receives the connection response. The device can use the scanning procedure
after it enters the connected mode, allowing it to be the Central in more than one
piconet at a time.

4.2.2.4 Discovering procedure

Bluetooth devices use the advertising procedure and scanning procedure to discover
nearby devices, or to be discovered by devices in a given area.

The discovery procedure is asymmetrical. A Bluetooth device that tries to find other
nearby devices is known as a discovering device and listens for devices advertising
scannable advertising events. Bluetooth devices that are available to be found are
known as discoverable devices and actively broadcast scannable advertising events
over the advertising broadcast physical channel.

Both discovering and discoverable devices may already be connected to other

Bluetooth devices. Any time spent inquiring or occupying the advertising broadcast
physical channel needs to be balanced with the connection requirements needed to
maintain the already established connection with these other LE devices.

Using device filtering by the scanning device can prevent the scanning device from
discovering all the devices in a given area.

4.2.2.5 Connecting procedure

The procedure for forming connections is asymmetrical and requires that one Bluetooth
device carries out the advertising procedure while the other Bluetooth device carries
out the scanning procedure. The advertising procedure can be targeted, so that only
one device will respond to the advertising. The scanning device can also target
an advertising device by first discovering that the advertising device is present in
a connectable manner, and in the given area, and then scanning only connectable
advertising events from that device using the device filter. After receiving connectable

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 1, Part A Page 306
Architecture

advertising events from the targeted advertising device, it can initiate a connection by
sending the connection request to the targeted advertising device over the primary
advertising physical channel or secondary advertising physical channel.

Time spent scanning while connected needs to be balanced with the connection
requirements needed to maintain the already established connection with other LE
devices.

4.2.2.6 Connected mode

After a successful connection procedure, the devices are physically connected to each
other within a piconet. This means that there is a piconet physical channel to which
they are both connected, there is a physical link between the devices, and there are
default LE-C and LE-U logical links. When in the connected mode it is possible to
change the properties of the physical and logical links while remaining connected to the
piconet physical channel, such as changing the adaptive frequency hopping sequence
or changing the maximum length of data packets. It is also possible for the device to
carry out advertising, scanning or discovery procedures without needing to disconnect
from the original piconet physical channel.

Additional logical links are created using the Link Manager that exchanges LL Protocol
messages with the remote Bluetooth device to negotiate the creation and settings for
these links. One of these links (LE-C) transports the LL control protocol and is invisible
to the layers above the Link Manager. The other link (LE-U) transports the L2CAP
signaling protocol and any multiplexed L2CAP best-effort channels. It is common to
refer to a default LE ACL logical transport, which can be resolved by context, but
typically refers to the default LE-U logical link.

These two logical links share a logical transport.

During the time that a Peripheral is actively connected to a piconet there is always a
default LE ACL logical transport between the Peripheral and the Central. The method
of deleting the default LE ACL logical transport is to detach the device from the piconet
physical channel, at which time the entire hierarchy of L2CAP channels, logical links,
and logical transports between the devices is deleted.

4.2.2.6.1 Connection Subrating

Connection subrating is a means of quickly modifying the effective connection interval

of an existing LE ACL connection. It is accomplished by the Central and Peripheral
skipping most of the underlying connection events; for example, if the subrating factor is
set to 7 then only every 7th connection event is used.

When connection subrating is applied to an existing connection, the active duty

cycle may be quickly reduced, saving power, but the original connection interval can

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 1, Part A Page 307
Architecture

be quickly restored for improved throughput when needed. Subrated connections

rely on an underlying connection interval which is understood by both Central and
Peripheral and, in so doing, allow reliable and immediate reductions and changes to
the connection interval without waiting for connection updates which rely on an instant
several connection events in the future. Devices that have subrated their default LE
ACL logical transports may use the absent periods to engage in activity on another
logical transport, or to enter reduced power mode. An LE subrated connection interval
only affects the specified LE ACL logical transport and does not apply to any associated
LE CIS logical transports that may be active.

4.2.2.7 Periodic advertising procedure

An advertiser uses the periodic advertising procedure to perform unidirectional periodic

broadcasts to devices in the area. The unidirectional broadcast occurs without a
connection between the advertising device and the listening devices. The periodic
advertising procedure can be used to synchronize with nearby devices to provide
deterministic periodic broadcast of user data to scanning devices listening on
the advertising physical channel. The advertising procedure uses the primary and
secondary advertising physical channel to broadcast control information about the
periodic advertising, referred to as the periodic advertising synchronization information.
The advertiser can also pass the periodic advertising synchronization information to
another connected device over the LE-C logical link.

An LE device synchronized with other LE devices on the periodic physical channel

uses the periodic advertising event. Time spent periodic advertising while connected
or synchronized with other LE devices needs to be balanced with the connection and
synchronization requirements needed to maintain the already established connection(s)
or synchronizations.

4.2.2.8 Periodic advertising synchronization procedure

The procedure for synchronizing to periodic advertising consists of two parts: obtaining
the periodic advertising synchronization information and then listening for the periodic
advertisements. The first part may be done using either of two methods.

The first method requires that one Bluetooth device carries out the advertising
procedure while the other Bluetooth device carries out the scanning procedure. The
scanning device can target an advertising device by first discovering that the advertising
device is present and broadcasting periodic advertisements in the given area. The
scanning device then needs to receive the advertising events containing the periodic
advertising synchronization information from the targeted advertising device.

The second method requires that a device that already has the periodic advertising
synchronization information passes it to another connected device over the LE-C logical
link.

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 1, Part A Page 308
Architecture

Once the receiving device has obtained the periodic advertising synchronization
information, the second part of the procedure is for it to listen directly for those periodic
advertising events; the receiving device is synchronized when it has successfully
received one such event.

Synchronizing devices may already be advertising, scanning, or be connected to

other Bluetooth devices in a piconet or synchronized to other periodic advertisements.
Any time spent synchronizing to periodic advertising needs to be balanced with the
requirements needed to maintain already established connections or synchronizations.

4.2.2.9 Periodic advertising synchronized mode

After a successful periodic advertising synchronization procedure, the devices are

physically synchronized to each other. This means that there is a periodic physical
channel to which they are both synchronized, there is a periodic physical link between
the devices, and there is an ADVB-U and an ADVB-C logical link. It is also possible for
the device to carry out advertising, scanning, or discovery procedures without needing
to disconnect from the LE periodic physical channel.

A Link Layer that is listening to periodic advertising may report the data in the periodic
advertisements to the Host. When it is not reporting the data to the Host, the Link
Layer does not need to listen to as many events to maintain synchronization, thereby
potentially providing more time for other procedures or reducing power consumption.

4.2.2.10 Decision-based scanning

When advertising data is being offloaded to the secondary advertising physical channel,
the advertiser can include information about the content of the auxiliary advertising
packet in the packets on the primary advertising physical channel. This information (the
“decision data”) can be provided by the Host to the Controller on the advertising device.

A scanning device can use the decision data provided by the advertiser to filter out
auxiliary packets that its host would not make use of. It does this by deciding, based
on the decision data, whether or not to listen to those packets. This results in the
scanning device maximizing the time that it spends scanning for packets on the primary
advertising physical channel, which in turn leads to lower latency in discovery and
connection procedures.

On the scanning device, the Host can provide instructions to its Controller on how to
process the decision data to determine whether to accept or reject the received packet.

4.2.3 [This section is no longer used]

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 1, Part A Page 309
Architecture

5 SECURITY OVERVIEW

5.1 Security architecture

The Bluetooth security model includes five distinct security features: pairing, bonding,
device authentication, encryption and message integrity.

• Pairing: the process for creating one or more shared secret keys
• Bonding: the act of storing the keys created during pairing for use in subsequent
connections in order to form a trusted device pair
• Device authentication: verification that the two devices have the same keys
• Encryption: message confidentiality
• Message integrity: protects against message forgeries

The Bluetooth Core security architecture has evolved over time and therefore there are
several security mechanisms.

BR/EDR Legacy Pairing utilizes the E21 or E22 algorithms based on SAFER+.
Device authentication is based on the E1 algorithm, which is also based on SAFER+.
Encryption utilizes the E0 algorithm derived from the Massey-Rueppel algorithm. There
is no provision for cryptographic message integrity. While the CRC provides some
integrity protection, it is not considered to provide cryptographic integrity as it can be
easily forged.

Secure Simple Pairing utilizes FIPS-approved algorithms (SHA-256, HMAC-SHA-256

and the P-192 elliptic curve) and four association models: Just Works, Numeric
Comparison, Passkey Entry and Out-Of-Band (see Section 5.2). Device authentication
and encryption are the same as BR/EDR Legacy Pairing.

LE Legacy Pairing uses AES-CCM encryption and four association models similar to,
though not the same as, those in Secure Simple Pairing. It also provides signed data
and a privacy feature.

Secure Connections on the BR/EDR physical transport upgrades Secure Simple Pairing
to utilize the P-256 elliptic curve and device authentication to use FIPS-approved
algorithms (HMAC-SHA-256 and AES-CTR). Secure Connections also adds message
integrity (AES-CCM).

Secure Connections on the LE physical transport upgrades LE Legacy Pairing to

utilize FIPS-approved algorithms (AES-CMAC and P-256 elliptic curve) and adapts the
Numeric Comparison association model of Secure Simple Pairing to be used on the
Bluetooth LE physical transport. It also includes provisions for a key generated using

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 1, Part A Page 310
Architecture

Secure Connections on either physical transport to preclude the need for the user to
pair a second time on the other physical transport.

The security key hierarchy for BR/EDR is shown in Figure 5.1. The key hierarchy is
different depending on whether a physical link is using Secure Connections or legacy
security procedures and algorithms.

Claimant Verifies

Peripheral
Central Verifies
Verifies

Used by LE

Figure 5.1: BR/EDR key hierarchy

The security key hierarchy for LE is shown in Figure 5.2. The key hierarchy is different
depending on whether a physical link is using LE Secure Connections or LE legacy
pairing procedures and algorithms.

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 1, Part A Page 311
Architecture

LE Secure BR/EDR Secure

LE Legacy Pairing
Connections Pairing Connections Pairing

TK LP_ RA ND_I LP_ RA ND_R DHK ey Nc Np BD_ADDR_C BD_ADDR_P

BR/EDR Secure
Connections
s1(AES-128 ) f5(AES-CMAC-128 )

LE STK LE LTK BR/EDR Link Key

- legacy
“tmp 1” SAL T “tmp 2” SAL T

LE key
h6(A ES-CMAC-128 ) h7(A ES-CMAC-128 ) h6(A ES-CMAC-128 ) h7(A ES-CMAC-128 )
distribution:
LTK, EDIV, RAND,
ILK ILTK
IRK, CSRK “lebr” “brle”

LTK from
LE Legacy
h6(A ES-CMAC-128 ) h6(A ES-CMAC-128 )
Pairing
BR/EDR
LTK
Link Key

BR/EDR Link Key

LE key distribution IRK, CSRK

Stored
Long Term Key

Figure 5.2: LE key hierarchy

The 5.2 version of the Core Specification adds a new LE security mode that
enables transmission and reception of encrypted isochronous data over the Broadcast
Isochronous Stream (BIS) logical transport.

Channel Sounding uses an AES-128 block based DRBG to exchange content that
is used for reverification of Channel Sounding peers. The security features related to
Channel Sounding are described in Section 9.4.

5.2 BR/EDR Secure Simple Pairing

The primary goal of Secure Simple Pairing is to simplify the pairing procedure for the
user. Secondary goals are to maintain or improve the security in Bluetooth wireless
technology. Since high levels of security and ease-of-use are often at opposite ends
of the spectrum in many technologies and products, much care has been taken to
maximize security while minimizing complexity from the end user's point of view.

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 1, Part A Page 312
Architecture

5.2.1 Security goals

Secure Simple Pairing has two security goals: protection against passive eavesdropping
and protection against man-in-the-middle (MITM) attacks (active eavesdropping). It is a
goal of Secure Simple Pairing to exceed the maximum security level provided by the
use of a 16 character, alphanumeric, case-sensitive PIN with BR/EDR Legacy Pairing,
which often used a 4-digit PIN or a fixed PIN of commonly known values significantly
limiting the security on the link.

5.2.2 Passive eavesdropping protection

A strong link key coupled with a strong encryption algorithm is necessary to give the
user protection against passive eavesdropping. The strength of the link key is based
on the amount of entropy (or randomness) in its generation process which would not
be known by an attacker. Using legacy pairing, the only source of entropy is the
PIN which, in many use cases, is typically four digits either selected by the user or
fixed for a given product. Therefore, if the pairing procedure and one authentication
exchange is recorded one can run an exhaustive search to find the PIN in a very
short amount of time on commonly available computing hardware. With Secure Simple
Pairing, the recording attack becomes much harder as the attacker must have solved a
hard problem in public key cryptography in order to derive the link key from the recorded
information. This protection is independent of the length of the passkey or other numeric
values that the user must handle. Secure Simple Pairing gives the same resistance
against the recording and passive eavesdropping attacks even when the user is not
required to do anything.

Secure Simple Pairing uses Elliptic Curve Diffie Hellman (ECDH) public key
cryptography as a means to thwart passive eavesdropping attacks. ECDH provides
a very high degree of strength against passive eavesdropping attacks but it may be
subject to MITM attacks, which however, are much harder to perform in practice than
the passive eavesdropping attack (see Section 5.2.3).

Using BR/EDR Legacy Pairing with a 16 numeric digit PIN achieves about 53 bits of
entropy whereas a 16 character, alphanumeric, case sensitive PIN yields about 95 bits
of entropy when the entire 62 character set is used ([0, ... 9, 'A', ... 'Z', 'a', ... 'z']). For
devices that do not support the Secure Connections feature, Secure Simple Pairing has
approximately 96 bits of entropy using the FIPS approved P-192 elliptic curve which
is at least as good as the entropy in BR/EDR Legacy Pairing using a 16 character,
alphanumeric, case sensitive PIN. For devices that do support the Secure Connections
feature, Secure Simple Pairing has approximately 128 bits of entropy using the FIPS-
approved P-256 elliptic curve.

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 1, Part A Page 313
Architecture

5.2.3 Man-in-the-middle protection

A man-in-the-middle (MITM) attack occurs when a user wants to connect two devices
but instead of connecting directly with each other they unknowingly connect to a
third (attacking) device that plays the role of the device they are attempting to pair
with. The third device then relays information between the two devices giving the
illusion that they are directly connected. The attacking device may even eavesdrop
on communication between the two devices (known as active eavesdropping) and
is able to insert and modify information on the connection. In this type of attack,
all of the information exchanged between the two devices are compromised and the
attacker may inject commands and information into each of the devices thus potentially
damaging the function of the devices. Devices falling victim to the attack are capable
of communicating only when the attacker is present. If the attacker is not active or out
range, the two victim devices will not be able to communicate directly with each other
and the user will notice it.

To prevent MITM attacks, Secure Simple Pairing offers two user assisted numeric
methods: numerical comparison or passkey entry. If Secure Simple Pairing would use
16 decimal digit numbers, then the usability would be the same as using legacy pairing
with 16 decimal digit PIN. The chance for a MITM to succeed inserting its own link
keys in this case is a 1 in 1016 = 253 pairing instances, which is an unnecessarily low
probability.

Secure Simple Pairing protects the user from MITM attacks with a goal of offering a
1 in 1,000,000 chance that a MITM could mount a successful attack. The strength of
the MITM protections was selected to minimize the user impact by using a six digit
number for numerical comparison and Passkey entry. This level of MITM protection
was selected since, in most cases, users can be alerted to the potential presence
of a MITM attacker when the connection process fails as a result of a failed MITM
attack. While most users feel that if they have not compromised their passkey, a 4-digit
key is sufficient for authentication (i.e., bank card PIN codes), the use of six digits
allows Secure Simple Pairing to be FIPS-compliant and this was deemed to have little
perceivable usability impact.

5.2.4 Association models

Secure Simple Pairing uses four association models referred to as Numeric

Comparison, Just Works, Out Of Band, and Passkey Entry. Each of these association
models are described in more detail in the following sections.

The association model used is deterministic based on the IO capabilities of the two
devices.

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 1, Part A Page 314
Architecture

5.2.4.1 Numeric Comparison

The Numeric Comparison association model is designed for scenarios where both
devices are capable of displaying a six digit number and both are capable of having the
user enter "yes" or "no". A good example of this model is the cell phone / PC scenario.

The user is shown a six digit number (from "000000" to "999999") on both displays and
then asked whether the numbers are the same on both devices. If "yes" is entered on
both devices, the pairing is successful.

The numeric comparison serves two purposes. First, since many devices do not
have unique names, it provides confirmation to the user that the correct devices
are connected with each other. Second, the numeric comparison provides protection
against MITM attacks (see Section 5.2.3).

There is a significant difference from a cryptographic point of view between Numeric

Comparison and the PIN entry model used by BR/EDR Legacy Pairing. In the Numeric
Comparison association model, the six digit number is an artifact of the security
algorithm and not an input to it, as is the case in the PIN entry model. Knowing the
displayed number is of no benefit in decrypting the encoded data exchanged between
the two devices.

5.2.4.2 Just Works

The Just Works association model is primarily designed for scenarios where at least
one of the devices does not have a display capable of displaying a six digit number nor
does it have a keyboard capable of entering six decimal digits. A good example of this
model is the cell phone/mono headset scenario where most headsets do not have a
display.

The Just Works association model uses the Numeric Comparison protocol but the user
is never shown a number and the application may simply ask the user to accept the
connection (exact implementation is up to the manufacturer).

The Just Works association model provides the same protection as the Numeric
Comparison association model against passive eavesdropping but offers no protection
against the MITM attack.

When compared against today's experience of a headset with a fixed PIN, the security
level of the Just Works association model is considerably higher since a high degree of
protection against passive eavesdropping is realized.

5.2.4.3 Out of Band

The Out of Band (OOB) association model is primarily designed for scenarios where an
Out of Band mechanism is used to both discover the devices as well as to exchange or

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 1, Part A Page 315
Architecture

transfer cryptographic numbers used in the pairing process. In order to be effective from
a security point of view, the Out of Band channel should provide different properties in
terms of security compared to the Bluetooth radio channel. The Out of Band channel
should be resistant to MITM attacks. If it is not, security may be compromised during
authentication.

The user's experience differs a bit depending on the Out of Band mechanism. As an
example, with a Near Field Communication (NFC) solution, the user(s) will initially touch
the two devices together, and is given the option to pair the first device with the other
device. If "yes" is entered, the pairing is successful. This is a single touch experience
where the exchanged information is used in both devices. The information exchanged
includes discovery information (such as the Bluetooth Device Address) as well as
cryptographic information. One of the devices will use a Bluetooth Device Address to
establish a connection with the other device. The rest of the exchanged information is
used during authentication.

The OOB mechanism may be implemented as either read only or read/write. If one
side is read only, a one-way authentication is performed. If both sides are read/write, a
two-way authentication is performed.

The OOB protocol is selected only when the pairing process has been activated by
previous OOB exchange of information and one (or both) of the device(s) gives OOB as
the IO capabilities. The protocol uses the information which has been exchanged and
simply asks the user to confirm connection.

The OOB association model supports any OOB mechanism where cryptographic
information and the Bluetooth Device Address can be exchanged. The OOB association
model does not support a solution where the user has activated a Bluetooth connection
and would like to use OOB for authentication only.

5.2.4.4 Passkey Entry

The Passkey Entry association model is primarily designed for the scenario where one
device has input capability but does not have the capability to display six digits and
the other device has output capabilities. A good example of this model is the PC and
keyboard scenario.

The user is shown a six digit number (from "000000" to "999999") on the device with a
display, and is then asked to enter the number on the other device. If the value entered
on the second device is correct, the pairing is successful.

There is a significant difference from a cryptographic point of view between Passkey

Entry and the PIN entry model used by BR/EDR Legacy Pairing. In the Passkey Entry
association model, the six digit number is independent of the security algorithm and not

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 1, Part A Page 316
Architecture

an input to it, as is the case in the PIN entry model. Knowing the entered number is of
no benefit in decrypting the encoded data exchanged between the two devices.

5.2.4.5 Association model overview

The following diagram shows Secure Simple Pairing from the point of view of the
technology used for discovery and then the different association possibilities.

Figure 5.3: Secure Simple Pairing association models

5.3 Secure Connections Only mode

When a device requires that only FIPS-approved algorithms are used on the BR/EDR
or LE physical transport, it should enter Secure Connections Only Mode. Secure
Connections Only Mode is sometimes called a "FIPS Mode". This mode should be used
when it is more important for a device to have high security than it is for it to maintain
backwards compatibility with devices that do not support Secure Connections. The Host
will enforce that the P-256 elliptic curve is used during pairing and that, on the BR/EDR
physical transport, the secure authentication sequences are used and AES-CCM is
used for encryption.

If a BR/EDR/LE device is configured in Secure Connections Only Mode, then both the
BR/EDR and the LE transports will be in Secure Connections Only Mode.

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 1, Part A Page 317
Architecture

5.4 LE security
LE Legacy Pairing has some differences in security aspects compared to BR/EDR
security features such as Secure Simple Pairing. The association models are similar to
BR/EDR Secure Simple Pairing from the user perspective and have the same names
but have differences in the quality of the protection provided.

5.4.1 Association models

Bluetooth LE uses four association models referred to as Just Works, Numeric

Comparison, Out of Band and Passkey Entry. LE legacy pairing does not have an
equivalent of Numeric Comparison.

In LE legacy pairing, each of these association models is similar to BR/EDR Secure

Simple Pairing with the following exceptions.

• Just Works and Passkey Entry do not provide any passive eavesdropping protection.
This is because Secure Simple Pairing uses Elliptic Curve Diffie-Hellman and LE
legacy pairing does not.

In LE Secure Connections pairing, the four association models are functionally

equivalent to BR/EDR Secure Connections.

The use of each association model is based on the IO capabilities of the devices.

5.4.2 Key generation

Key generation in Bluetooth LE is performed by the Host on each LE device

independent of any other LE device. By performing key generation in the Host, the
key generation algorithms can be upgraded without the need to change the Controller.

Note: Key generation in BR/EDR is performed in the Controller.

Bluetooth LE uses multiple keys, each for a specific purpose, as follows:

• Confidentiality of data and device authentication

• Authentication of unencrypted data
• Device Identity

In LE, the key used to provide confidentiality and authentication is generated by

combining contributions from each device during pairing.

5.4.3 Encryption

Encryption in Bluetooth LE uses AES-CCM cryptography. Like BR/EDR, in LE

encryption is performed in the Controller.

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 1, Part A Page 318
Architecture

5.4.4 Signed Data

Bluetooth LE supports the ability to send authenticated data over an unencrypted ATT
bearer between two devices with a trusted relationship. This is accomplished by signing
the data with a Connection Signature Resolving Key (CSRK). The sending device
places a signature after the Data PDU. The receiving device verifies the signature and
if the signature is verified the Data PDU is assumed to come from the trusted source.
The signature is composed of a Message Authentication Code generated by the signing
algorithm and a counter. The counter is used to protect against a replay attack and is
incremented on each signed Data PDU sent.

5.4.5 Privacy feature

Bluetooth LE supports a feature that reduces the ability to track a LE device over a
period of time by changing the Bluetooth Device Address on a frequent basis.

In order for a device using the privacy feature to reconnect to known devices, the device
address, referred to as the private address, must be resolvable by the other device. The
private address is generated using the device’s identity resolving key (IRK) exchanged
during the bonding procedure.

The term “resolution” means a process used by a device to calculate the device Identity
Address from the received private address and the IRK, while the state “resolved” is the
successful result of a resolution.

There are two variants of the privacy feature. In the first variant, private addresses
are resolved and generated by the Host. In the second variant, private addresses are
resolved and generated by the Controller without involving the Host after the Host
provides the Controller device identity information. In addition, the second variant may
involve the Host when the resolving list in the Controller cannot store all the device
identity resolving keys necessary for bonded devices.

There are two modes of privacy: device privacy mode and network privacy mode. A
device in device privacy mode is only concerned about the privacy of the device and will
accept advertising packets from peer devices that contain their Identity Address as well
as ones that contain a private address, even if the peer device has distributed its IRK
in the past. In network privacy mode, a device will only accept advertising packets from
peer devices that contain private addresses. By default, network privacy mode is used
when private addresses are resolved and generated by the Controller.

The Host maintains a resolving list by adding and removing device identities. The Host
may provide the Controller with a complete resolving list or a subset of the resolving list.
A device identity consists of the peer’s Identity Address and a local and peer’s IRK pair.

When the Controller performs address resolution and the Host needs to refer to a peer
device that is included in the resolving list, it uses the peer’s device Identity Address.

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 1, Part A Page 319
Architecture

Likewise, all incoming events from the Controller to the Host will use the peer’s device
identity, provided that the peer’s device address has been resolved. If the Controller
cannot resolve the peer’s device Identity Address in an advertisement, it may pass the
event to the Host for resolution in the Host.

Device filtering becomes possible when address resolution is performed in the

Controller because the peer’s device Identity Address can be resolved prior to checking
whether it is in the Filter Accept List.

Figure 5.4 shows a logical representation of the relationship between the Controller
resolving list and the Controller Filter Accept List. Actual implementations of the
resolving list and Filter Accept List are not required to follow this model. The resolving
list may be independent of the Filter Accept List.

Filter Accept List

Resolving List Device Identity Address Address Type

Local IRK Peer IRK Peer Device Identity Address Address Type Device Identity Address Address Type

Local IRK Peer IRK Peer Device Identity Address Address Type

Local IRK Peer IRK Peer Device Identity Address Address Type Device Identity Address Address Type

Local IRK Peer IRK Peer Device Identity Address Address Type Device Identity Address Address Type

Device Identity Address Address Type

Figure 5.4: Logical representation of the resolving list and Filter Accept List

Note: Not all devices in the Filter Accept List are device Identity Addresses.

5.4.6 Encrypted Advertising Data

The privacy feature described in Section 5.4.5 allows the Bluetooth Device Address
to be changed periodically while still allowing the fingerprinting of devices based on
the contents of their advertising data. It is possible to encrypt advertising data by
encapsulating the normal advertising data within an Encrypted Data data type using a
pre-shared session key and a nonce. Because the encrypted advertising data nonce
is changed whenever the private address is changed, the encrypted data before and
after the change is also different. This approach prevents the tracking of devices based
solely on the private address and advertising data.

The encrypted advertising data pre-shared session key is communicated only to peer
devices that are authorized to receive such information. Only devices that have the key
material can decrypt and authenticate messages and track the advertising device.

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 1, Part A Page 320
Architecture

5.5 [This section is no longer used]

5.6 Key generation between BR/EDR and LE physical transports

When two BR/EDR/LE devices support Secure Connections over both transports, keys
for both transports may be generated during a single pairing procedure. The ability
to convert keys from one transport to the other prevents the need to pair twice, thus
enabling a better user experience.

The link key for BR/EDR generated during Phase 4 of Secure Simple Pairing on the
BR/EDR physical transport may be converted to a Long Term Key (LTK) for use on the
LE transport. Similarly, an LTK generated during Phase 2 of pairing on the LE physical
transport may be converted to the BR/EDR Link Key for use on the BR/EDR physical
transport.

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 1, Part A Page 321
Architecture

6 BLUETOOTH APPLICATION ARCHITECTURE

6.1 Bluetooth profiles

Application interoperability in the Bluetooth system is accomplished by Bluetooth

profiles. Bluetooth profiles define the required functions and features of each layer in
the Bluetooth system from the PHY to L2CAP and any other protocols outside of this
specification. The profile defines the vertical interactions between the layers as well as
the peer-to-peer interactions of specific layers between devices.

Bluetooth Profiles

L2CAP
Bluetooth Protocol Layers

Link Manager
Profile #1

Profile #2

Profile #3
GAP

Baseband

Radio (PHY)

Figure 6.1: Bluetooth profiles

In addition, application behaviors and data formats are also defined by the profile. When
two devices comply with all the requirements of a Bluetooth profile, interoperability of an
application is enabled.

All profiles describe service discovery requirements necessary for devices to connect,
find available application services and connection information necessary for making
application level connections.

6.2 Generic Access Profile

The Bluetooth system defines a base profile which all Bluetooth devices implement.
This profile is the Generic Access Profile (GAP), which defines the basic requirements
of a Bluetooth device. For instance, for BR/EDR, it defines a Bluetooth device to

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 1, Part A Page 322
Architecture

include the Radio, Baseband, Link Manager, L2CAP, and the Service Discovery protocol
functionality; for LE, it defines the Physical Layer, Link Layer, L2CAP, Security Manager,
Attribute Protocol and Generic Attribute Profile. This ties all the various layers together
to form the basic requirements for a Bluetooth device. It also describes the behaviors
and methods for device discovery, connection establishment, security, authentication,
association models and service discovery.

In BR/EDR, GAP defines a single role with functionality that may be present in
each device. This functionality includes how devices discovery each other, establish
connections and describes security association models used for authentication. In
BR/EDR this functionality may be present in both devices. It may be necessary for a
device to implement both the initiating and accepting functionality if the device wants to
discover or establish connections with all devices. A device may only include either the
initiating or the accepting functionality but it requires the remote device to support the
complimentary functionality to discovery or establish connections with the device. For
BR/EDR, the Controller is required to support all the functionality, however the Host may
limit this functionality based on the other profiles or use cases supported by the device.

In LE, GAP defines four specific roles: Broadcaster, Observer, Peripheral, and Central.
A device may support multiple LE GAP roles provided that the underlying Controller
supports those roles or role combinations. Each role specifies the requirements for the
underlying Controller. This allows for Controllers to be optimized for specific use cases.

The Broadcaster role is optimized for transmitter only applications. Devices supporting
the Broadcaster role use advertising to broadcast data. The Broadcaster role does
not support connections. The Observer role is optimized for receiver only applications.
Devices supporting the Observer role are the complementary device for a Broadcaster
and receives broadcast data contained in advertisements. The Observer role does not
support connections. The Peripheral role is optimized for devices that support a single
connection and are less complex than Centrals; it uses the Link Layer Peripheral role
within the connection. The Central role supports multiple connections and is the initiator
for all connections with devices in the Peripheral role; it uses the Link Layer Central
role within the connection. Devices supporting the Central role generally support more
complex functions compared to the other LE GAP roles.

6.3 Profile hierarchy

Since all Bluetooth devices are required to implement GAP, any additional profiles
implemented by a Bluetooth device become supersets of GAP. Depending on the
complexity of an application or the ability to reuse common requirements of functionality
of the Bluetooth system between many applications, additional generic profiles can be
created that depend on GAP or other generic profiles, as well as enabling other profiles.
A top level profile that describes application interoperability is called an Application
Profile.

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 1, Part A Page 323
Architecture

Application Profile #1

Generic Profile #1

Generic Access
Profile

Figure 6.2: Profile hierarchy

Application profiles contain by reference GAP and any other generic profile that
describes a set of common requirements of the Bluetooth system.

6.4 Generic Attribute Architecture

6.4.1 Attribute Protocol

To allow devices to read and write small data values held on a server, an Attribute
Protocol (ATT) is defined. Each stored value, typically only a few octets, is known as
an attribute. This protocol allows each attribute to be self-identifying using UUIDs to
identify the type of data. These UUIDs can be well-known assigned numbers defined in
the Assigned Numbers document and associated specifications, or a vendor assigned
128-bit UUID.

Attribute Protocol messages are sent over L2CAP channels, known as the ATT bearers.

Attribute Protocol defines two roles: Client and Server. A device can be both an ATT
Client and an ATT Server at the same time. Attribute Protocol messages on a single
ATT bearer allow a single transaction in each direction to be outstanding at a time.
When a response to a message is received, the next transaction can be initiated. When
multiple ATT bearers are created, each ATT bearer has a separate transaction model
and therefore multiple ATT transactions can be outstanding at the same time, one per
bearer. This can be used to allow multiple higher layer specifications to send messages
concurrently.

The ATT Server stores the attributes and accepts Attribute Protocol requests,
commands and confirmations from the ATT Client. The ATT Server sends responses
to requests and, when configured by a higher layer, sends indications and notifications
asynchronously to the ATT Client when specified events occur on the ATT Server.

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 1, Part A Page 324
Architecture

6.4.2 Generic Attribute Profile

Generic Attribute Profile (GATT) is built on top of the Attribute Protocol (ATT) and
establishes common operations and a framework for the data transported and stored
by the Attribute Protocol. GATT defines two roles: Server and Client. A GATT Client
or Server is an ATT Client or Server respectively that conforms to the requirements
in GATT. The GATT roles are not necessarily tied to specific GAP roles but may be
specified by higher layer profiles. GATT and ATT are not transport specific and can be
used in both BR/EDR and LE. However, GATT and ATT are mandatory to implement in
LE since it is used for discovering services.

GATT also specifies the format of data contained on the GATT Server. Attributes, as
transported by the Attribute Protocol, are formatted as Services and Characteristics.
Services may contain a collection of characteristics. Characteristics contain a single
value and any number of descriptors describing the characteristic value.

With the defined structure of services, characteristics and characteristic descriptors

a GATT Client that is not specific to a profile can still traverse the GATT Server
and display characteristic values to the user. The characteristic descriptors can be
used to display descriptions of the characteristic values that may make the value
understandable by the user.

6.5 GATT-Based Profile hierarchy

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.

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 references
to 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.

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 1, Part A Page 325
Architecture

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 6.3: GATT-Based Profile hierarchy

6.5.1 Service

A service is a collection of data and associated behaviors to accomplish a particular

function or feature of a device or portions of a device. A service may include other
primary or secondary services and/or a set of characteristics that make up the service.

There are two types of services: primary and secondary. A primary service is a service
that provides functionality of a device that can be used on its own. A secondary service
is a service that provides additional functionality of a device in association with a
primary service and is included from at least one primary service on the device.

To maintain backward compatibility with earlier clients, later revisions of a service

definition can only add new included services or optional characteristics. Later revisions
of a service definition are also forbidden from changing behaviors from previous revision
of the service definition.

Services may be used in one or more profiles to fulfill a particular use case.

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 1, Part A Page 326
Architecture

6.5.2 Included services

An included service is a method to incorporate another service definition on the server

as part of the service including it. When a service includes another service, the
entire included service becomes part of the new service including any nested included
services and characteristics. The included service still exists as an independent service.
There are no limits to the depth of nesting.

6.5.3 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. A characteristic definition contains a characteristic
declaration, characteristic properties, and a value. It may also contain descriptors that
describe the value or permit configuration of the server with respect to the characteristic
value.

6.6 [This section is no longer used]

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 1, Part A Page 327
Architecture

7 COEXISTENCE AND COLLOCATION

Bluetooth devices operate in the unlicensed 2.4 GHz Industrial, Scientific and Medical
(ISM) band. Many other technologies utilize the ISM band, including wireless LAN,
cordless phones, and microwave ovens. The ISM band is also close enough to other
frequency bands that Bluetooth devices may be an interferer of or a victim of other
technologies.

Radios may be collocated or non-collocated. The term "collocated" is a loose one

- in this specification, collocated radios are assumed to be in the same product (a
Multi-Radio Terminal or MRT) and may have mechanisms to coordinate their activity in
order to mitigate interference.

Determining the amount of expected isolation between radios is important for choosing
an appropriate coexistence mechanism. With sufficient isolation, frequency division
duplexing (FDD) techniques are the most efficient. With insufficient isolation or a shared
antenna, time division duplexing (TDD) techniques need to be used. In many cases, a
combination of FDD and TDD techniques are required to achieve acceptable levels of
performance.

This specification supports a variety of features that help mitigate interference to other
devices and to minimize interference from other devices. Broadly, the types of solutions
fall into the following categories:

Type Description
Frequency division Simultaneous use of multiple radios enabled by filters and/or isolation
Time division One radio may transmit or receive at a time through scheduling or prioritiza-
tion
Time alignment Activities of the collocated radios are aligned in the time domain to optimize
performances by avoiding conflicting activities. E.g. Transmissions of multi-
ple radios may occur simultaneously, multiple receptions may occur simulta-
neously, but it is not possible to transmit and receive simultaneously
Hybrid frequency and Use of frequency division, time alignment, and time division techniques de-
time division pending on the relative frequencies in use by the radios, filters and isolation

Table 7.1: Interference mitigation types

7.1 Core features supporting coexistence and collocation

There are features in the specification to specifically target the reduction of interference
from collocated or non-collocated devices.

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 1, Part A Page 328
Architecture

Feature Version Description

Introduced
Adaptive Frequen- 1.2 Allows devices to reduce the number of channels used in a
cy Hopping piconet in order to avoid interferers
HCI Set Host 1.2 Allows a Host to inform the local Bluetooth Controller of the
Channel Classifi- channels that are occupied by a collocated technology
cation
Enhanced SCO 1.2 Added retransmissions to SCO for the purpose of combating
interference
(eSCO)
MWS Coexistence CSA3 Provides a standardized interface between collocated radios for
Signaling communicating information necessary to enable some coexis-
tence techniques
Piconet Clock Ad- 4.1 Allows a Bluetooth device to align the piconet clock with an
just external technology, e.g. Long Term Evolution (LTE)
Train Nudging 4.1 Provides a mechanism to improve the success rate of page and
inquiry when the slots to receive the respective responses are
periodically not available
Generalized Inter- 4.1 Provides a mechanism to improve the success rate of page
laced Scanning scan and inquiry scan when some slots are periodically not
available for scanning
Slot Availability 5.0 Provides a mechanism for two Bluetooth devices to indicate to
Mask each other the availability of their time slots

Table 7.2: Interference mitigation features

7.2 Adaptive Frequency Hopping

Adaptive Frequency Hopping (AFH) allows Bluetooth devices to improve their immunity
to interference from and avoid causing interference to other devices in the 2.4 GHz ISM
band. The basic principle is that Bluetooth channels are classified into two categories,
used and unused, where used channels are part of the hopping sequence and unused
channels are replaced in the hopping sequence by used channels in a pseudo-random
way. This classification mechanism allows for the Bluetooth device to use either all or
fewer than the channels available. The minimum number of channels allowed by the
Bluetooth specification is 20 on BR/EDR and 2 on LE.

The specification defines the aspects of AFH necessary to ensure interoperability,

including the hopping kernel, Baseband behavior, Link Manager Protocol (LMP)
commands, Link Layer behavior and commands, and Host Controller interface (HCI)
commands and events required to change and configure hopping sequences. The
Bluetooth Specification also defines a mechanism that allows for a Peripheral to report
channel classification information to the Central.

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 1, Part A Page 329
Architecture

Adaptive Frequency Hopping utilizes metrics obtained through many sources. These
metrics are analyzed and then the resulting Channel_Map is used by the adaptive
frequency hopping kernel. The metrics may come from over-the-air measurements, data
supplied by the Host (e.g., via HCI commands), or reports by the Peripheral or from
other hardware coexistence interfaces.

While AFH is a critical element in coexistence, it is not enough in some circumstances.

7.3 Coexistence between Bluetooth Devices and Wireless LAN

Devices
Coexistence between Bluetooth and Wireless LAN has traditionally been a combination
of Adaptive Frequency Hopping (AFH) and proprietary techniques to prioritize traffic
between the two protocols. The specification does not specify signaling between the
Bluetooth Controller and a Wireless LAN device.

7.4 Mobile Wireless Standards (MWS) coexistence

Significant interference can be present between the Bluetooth radio and a collocated
MWS radio operating in frequency bands adjacent to the 2.4 GHz ISM band. This
interference can prevent one radio from receiving while the other radio is transmitting.

The “Filter recommendations for Coexistence with LTE and WiMAX” whitepaper1
describes filter specifications that, in some cases, can reduce collocated interference
to an acceptable level. The specification includes complementary solutions to traditional
filtering including features for Bluetooth Controllers and Hosts as well as signaling and
messaging mechanisms between collocated MWS and Bluetooth radios. Figure 7.1
illustrates the general architecture model for these mechanisms. This architecture
assumes separate antennas with limited isolation.

1https://www.bluetooth.com/develop-with-bluetooth/build/white-papers

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 1, Part A Page 330
Architecture

Multi-Radio Terminal (MRT)

Host

Coex Signaling
Base MWS Bluetooth
Bluetooth
Station Device Controller

Co-located Interference

Figure 7.1: MWS coexistence architecture

Two types of solutions have been considered. In the first solution, both Bluetooth
transmissions (TX) and receptions (RX) are constrained by collocated MWS activities.
Solutions of this type are called Pure TDM (Time Division Multiplexed) Mode. In
the second solution, only Bluetooth receptions are affected by collocated MWS
transmissions and Bluetooth transmissions do not impact the operation of the collocated
MWS. Solutions of this type are called Hybrid Mode and are achieved, for example,
by using steep roll-off Band Select Filters (BSFs) for the ISM band in the Bluetooth
transceiver. Hybrid Mode applies where the Bluetooth transmission’s effect on MWS is
sufficiently reduced via filtering that the Bluetooth device can transmit during the MWS
downlink time. This requires a frequency guard band between the Bluetooth and MWS
operational frequency ranges as well as constraints on both the Bluetooth BSF and the
MWS BSF. The requirement for a time domain solution still remains, but only to protect
Bluetooth reception.

These solutions are facilitated by an MWS coexistence signaling mechanism (see [Vol
7] Part A) and multiple transport layers (see [Vol 7] Part B and [Vol 7] Part C).

MWS technologies operate in licensed bands and use centralized scheduling to support
Wide Area Network services. An MWS radio synchronizes both time and frequency with
a network Base Station. The Base Station determines which MWS radio will transmit
or receive and when. MWS radios have no control over when to transmit or receive.
When Bluetooth transmissions interfere with MWS receptions in the MRT, the MWS
radio can be rendered unusable if the Bluetooth radio transmits freely. Figure 7.2 shows
how Bluetooth activity can interfere with every MWS reception opportunity and similarly
how MWS transmissions can interfere with Bluetooth reception. In the example shown
in Figure 7.2 the Bluetooth device in the MRT is operating as the Central of a piconet.
Blocks marked with a “C” are single slot Central transmissions and those marked with a
“P” are single slot Peripheral transmissions. The times at which reception by the MWS
device may be corrupted by Bluetooth transmissions are marked with a red shade.

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 1, Part A Page 331
Architecture

MWS Downlink Uplink Downlink Uplink Downlink

One MWS Frame (5ms)

Example where
Bluetooth is
Central and is not C P C P C P C P C P C P C P C P C P C P
aligned with MWS
frame boundary

Figure 7.2: MWS receptions interfered with by uncontrolled Bluetooth transmissions

Even with the best relative timing relationship (when the Bluetooth slot boundary is
aligned with the MWS frame boundary), the Bluetooth radio in the MRT suffers reduced
transmission and reception opportunities due to time multiplexing with the collocated
MWS radio. The Bluetooth radio only gets one transmission/reception opportunity every
MWS frame, as shown in Figure 7.3.

MWS Downlink Uplink Downlink Uplink Downlink

One MWS Frame (5ms)

Bluetooth slot
boundary is
aligned with MWS P C P C P C P C P C P C P C P C P C P
frame boundary

Figure 7.3: Bluetooth radio has reduced transmission/receiving opportunities

Consequently, three out of four (for 5 ms MWS frames) or seven out of eight (for 10 ms
MWS frames) slot pairs of Bluetooth can be punctured by MWS activities. Furthermore,
since Bluetooth inquiry and paging use a sequence of 16 channels at a time, when the
Bluetooth radio in the MRT is performing inquiry or paging the channel sequence will
repeat every 5 ms resulting in the same channels being repeatedly punctured by the
collocated MWS activities, see Figure 7.4. As a result, there is a high probability that
the remote scanning device will not be able to receive the page or inquiry IDs within the
current timeout.

When the inquiry or paging channel sequence gets repeatedly punctured, Train Nudging
can be used to add an additional offset to the clock bits in order to shift the channel
sequence.

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 1, Part A Page 332
Architecture

MWS Frame Duration (5 ms)

Bluetooth T T R R T T R R T T R R T T R R T T
X X X X X X X X X X X X X X X X X X
CENTRAL

MWS FAILED FAILED FAILED SUCCESS

Downlink Uplink Downlink...
Bluetooth Bluetooth Bluetooth
Transmit Disallowed Reception Corrupted Transmit Disallowed

Figure 7.4: Bluetooth radio can suffer inquiry/page failures

As MWS transmissions interfere with Bluetooth receptions in the MRT, up to 50% of

the transmitted IDs from the remote inquiry/page device will not be received by the
Bluetooth radio in the MRT performing scanning, as shown in Figure 7.5.

Based on the pattern of slots that are not available for scanning, Generalized Interlaced
Scanning can be used to tune the phase of the second scan during a back-to-back
scan.

MWS Frame Duration (5 ms)

T T R R T T R R T T R R T T R R T T R R T T
X X X X X X X X X X X X X X X X X X X X X X

Central

Peripheral
page scan page scan
(MRT)

MWS Downlink Uplink Downlink

SUCCESS FAILED FAILED SUCCESS SUCCESS

Figure 7.5: Bluetooth radio can suffer inquiry scan/page scan failures

7.5 Synchronizing Bluetooth with an external timing source

This section provides an example to illustrate the synchronization of the Bluetooth
CLK with an MWS system so that the Bluetooth slots line up with the Downlink and
Uplink times of the MWS system. The external frame in this example is LTE TDD
Frame Configuration #1 and special subframe configuration #1; however the same
mechanisms can be used for any external TDD/TDMA protocol. The example shows a
time span of 10 ms.

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 1, Part A Page 333
Architecture

[Vol 7] Part A defines the timing of the MWS frame as a fixed offset from the
FRAME_SYNC signal in the coexistence signaling. This is shown in Figure 7.6 as FS.
FS can be defined by the Host as any specific offset within the MWS frame. For a
piconet Central, the most useful position for FS is the boundary between the uplink and
the following downlink. This is because the Central needs to transmit in a Central slot
during the uplink and then receive in the following Peripheral slot during the downlink.
Putting FS at this boundary allows the Central to easily align its Bluetooth clock to put it
between these slots. The situation is reversed in a Peripheral: FS is most useful on the
boundary between the downlink and the following uplink.

The HCI command HCI_Set_External_Frame_Configuration ([Vol 4] Part E, Section

7.3.81) can be used to describe the MWS frame timing. This knowledge, together
with FS, allows the Bluetooth Controller to align the Bluetooth clock with the MWS
frame timing so as to minimize the effect of mutual interference. This is illustrated in
Figure 7.6. The red ovals show slot pairs where both MWS and Bluetooth transmit
and receive simultaneously and so do not interfere with each other. The MWS frame
structure includes a downlink portion (“D”), an uplink portion (“U”), and a special portion
(“S”) that includes a downlink and uplink portion separated by a guard period (“GP”).

FS Middle of GP

D S U U D D S U U D

Collocated
Central P C P C P C P C P C P C P C P C

Collocated
Peripheral C P C P C P C P C P C P C P C P

Figure 7.6: Alignment of MWS frame timing and Bluetooth clock

Note: In LTE, if the implementation does not have access to the exact LTE timing it can
assume that the downlink-to-uplink boundary is the middle of the GP in a special LTE
subframe.

7.6 Piconet clock adjustment

As discussed in the previous section, aligning the MWS and Bluetooth clocks correctly
greatly improves throughput on both technologies. The Central has two mechanisms at
its disposal to mitigate misalignments.

Coarse Clock Adjustments can be used to move the Bluetooth CLK using the
LMP_CLK_ADJ PDU. The clk_adj_us parameter is used to align the slots with the MWS
alignment point indicated by the FRAME_SYNC signal. The clk_adj_slots parameter
can be used to move the CLK several slots forward in time. This can be useful to align
e.g. eSCO. Coarse Clock Adjustment is expected to be used only rarely, for instance

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 1, Part A Page 334
Architecture

at MWS connection or when the MWS frame timing changes due to roaming. Coarse
Clock Adjustment can only be used when all Peripherals in the piconet support it.

The other option for the Central is to use Clock Dragging. This is a method of slowly
adjusting the phase of the clock backward or forward by making the slots a few µs
shorter or longer, respectively, until the desired CLK phase has been achieved. It should
be noted that this is a very slow rate of adjustment, as it is designed to allow a legacy
device to track the change, and therefore the requirements of [Vol 2] Part B, Section 1.1
mean that Clock Dragging must not be done at a faster rate than the maximum natural
drift between devices. For this reason its main use is to facilitate small corrections over
time if a misalignment with the MWS system is detected. If any device is connected that
does not support Coarse Clock Adjustment, slowly moving the Peripheral using Clock
Dragging is the only option.

It is recommended to let the collocated device be the Central, when possible, as

it can react much faster to correct misalignments. If a Peripheral is the collocated
device, doing a role switch to make it Central may be worth considering. Alternatively
a Peripheral can send a Piconet Clock Adjustment Request LMP packet to the Central.
The Central then has the option to perform a Coarse Clock Adjustment, Clock Dragging,
or to reject the request.

7.7 Slot Availability Mask (SAM)

Slot Availability Mask (SAM) allows two Bluetooth devices to indicate to each other time
slots that are available for transmission and reception. The SAM slot map specifies
the availability or otherwise of Bluetooth slots. A slot could be unavailable because
of external conditions (e.g., MWS coexistence) or internal conditions (e.g., scatternet
commitments). SAM does not impose new mandatory rules for the scheduling of
BR/EDR time slots. Instead, it merely provides information which allows Controllers to
refine their scheduling of Bluetooth slots to improve performance.

SAM slot maps are calculated by the Controller itself based on its scheduling
requirements. There are no HCI commands defined specifically for SAM, merely LMP
sequences that enable devices to exchange maps and indicate the map in use. The HCI
commands HCI_Set_External_Frame_Configuration (see [Vol 4] Part E, Section 7.3.81)
and HCI_Set_MWS_PATTERN_Configuration (see [Vol 4] Part E, Section 7.3.85) and
real-time signals (e.g., MWS_PATTERN_Index or FRAME_SYNC) provided by the
Coexistence Logical Interface (see [Vol 7] Part A) contain information concerning the
appropriate SAM_Index and SAM anchor point to use for MWS coexistence; these may
therefore trigger these LMP sequences.

A Controller may choose to perform a Piconet Clock Adjustment before initiating an

LMP_SAM_SWITCH sequence so as to increase the number of slot pairs available per
MWS frame.

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 1, Part A Page 335
Architecture

8 DIRECTION FINDING USING BLUETOOTH LOW

ENERGY

An LE device can make its direction available for a peer device by transmitting direction
finding enabled packets. Using direction information from several transmitters and
profile-level information giving their locations, an LE radio can calculate its own position.

This feature is supported over the LE Uncoded PHYs, but not over the LE Coded PHY.

8.1 Angle of arrival (AoA) method

An LE device can make its direction available to a peer device by transmitting direction
finding enabled packets using a single antenna.

The peer device, consisting of an RF switch and antenna array, switches antennae
while receiving part of those packets and captures IQ samples. The IQ samples can
be used to calculate the phase difference in the radio signal received using different
elements of the antenna array, which in turn can be used to estimate the angle of arrival
(AoA).

AoA

LE Transmitter

RF
Switch

LE Receiver

AoA Estimation

Figure 8.1: Angle of Arrival method

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 1, Part A Page 336
Architecture

Consider a receiver device with an antenna array consisting of two antennae, separated
by distance d. The transmitter device uses a single antenna to transmit a signal. As
shown in Figure 8.2, a perpendicular line can be drawn from an incoming signal wave
front extending to the furthest antenna (antenna 2) at the point of intersection to the
closest antenna (antenna 1). The adjacent side of that right triangle represents the path
difference relative to the angle of incidence of that wave front between both antennae.
The phase difference, ψ, in the signal arriving at the two antennae is then

ψ = (2πd cos(θ))÷λ

where λ is the wavelength of the signal and θ is the angle of arrival (measured from a
line connecting the two antennae in the receiver), and so

θ = arccos((ψλ)÷(2πd))

Note: The distance d is profile-level information that is used by the receiving device to
calculate the angle of arrival.

Radio signal
θ
Antenna 2 Antenna 1
d
Figure 8.2: Measuring the angle of arrival

8.2 Angle of departure (AoD) method

A device consisting of an RF switch and antenna array can make its angle of departure
(AoD) detectable by transmitting direction finding enabled packets, switching antennae
during transmission.

The peer device receives those packets using a single antenna and captures IQ
samples during part of those packets. Determination of the direction is based on the
different propagation delays of the LE radio signal between the transmitting elements
of the antenna array and a receiving single antenna. The propagation delays are
detectable with IQ measurements. Any receiving LE radio with a single antenna that

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 1, Part A Page 337
Architecture

supports the AoD feature can capture IQ samples and, with the aid of profile-level
information specifying the antenna layout of the transmitter, calculate the angle of
incidence of the incoming radio signal.

AoD

RF
Switch

LE Transmitter

LE Receiver

AoD Estimation

Figure 8.3: Angle of departure method

Consider a transmitter device with an antenna array consisting of two antennae,

separated by distance d. The receiver device uses a single antenna to receive the
signals. The phase difference, ψ, in the signal from antenna 1 and the signal from
antenna 2 arriving at the receiver is then

ψ = (2πd cos(θ))÷λ

where λ is the wavelength of the signal and θ is the angle of departure (measured from
a line connecting the two antennae in the transmitter), and so

θ = arccos((ψλ)÷(2πd))

Note: The distance d is profile-level information that a transmitting device exchanges

with the receiving device in order for the receiving device to calculate the angle of
departure.

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 1, Part A Page 338
Architecture

Antenna 1 Antenna 2
d
θ
Radio signal

Figure 8.4: Measuring the angle of departure

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 1, Part A Page 339
Architecture

9 CHANNEL SOUNDING USING BLUETOOTH LOW

ENERGY

An LE device can use the Channel Sounding (CS) feature to characterize the
propagation path between itself and a connected peer. The measurements obtained
from a CS procedure enable a device to estimate its distance from the peer device.
A device supporting the CS feature supports both round-trip time measurements and
phase-based ranging measurements.

9.1 Channel Sounding procedure

The CS feature consists of a combination of Link Layer procedures and a dedicated air
interface protocol that creates a tightly interlocked exchange of RF signals between two
devices on multiple RF channels. This exchange is known as a CS procedure.

A CS procedure consists of CS events, subevents and steps. These define a set of time
and frequency slots in which two devices exchange a combination of RF signals. The
purpose of that exchange is to measure the physical characteristics of the transmission
channel. These exchanges are bidirectional; both devices take turns sending and
receiving RF signals.

A CS procedure is divided into one or more CS events. A CS event consists of one

or more CS subevents. A CS subevent consists of two or more CS steps, each of
which starts with a frequency change period called T_FCS. Time separation between
CS subevents avoids continuous allocation of the RF resources of a given device and
facilitates coexistence with other RF technologies. Within a CS subevent, the first CS
steps are used to provide calibration information for the remaining CS steps within that
CS subevent. Figure 9.1 shows the relationship between CS procedures, CS events,
CS subevents, and CS steps.

Figure 9.1: CS procedure/event/subevent/step hierarchy

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 1, Part A Page 340
Architecture

Each CS subevent has a separate starting point. The Link Layer procedures that
configure devices to run the CS procedure define the CS steps for these subevents,
in terms of both time and frequency, relative to these starting points.

Four CS step types, known as mode-0 through mode-3, are defined. Each mode is used
for a specific purpose. Mode-0 is used to calibrate one device to the other in terms
of frequency and timing. Mode-1 is used to exchange a round-trip time (RTT) packet.
Mode-2 is used to exchange phase-based ranging (PBR) CS tones to measure phase
and amplitude of the communication channel. Mode-3 is used to exchange both RTT
and phase/amplitude measurements.

After the CS procedure completes, each device retains information collected from
each CS step that describes the communication channel. Mode-0 steps reflect local
frequency adjustments. Mode-1 and mode-3 steps measure time of arrival and time of
departure. Mode-2 and mode-3 steps measure phase and magnitude information in the
form of in-phase and quadrature (IQ) measurements. The reflector communicates this
information to higher layers to be sent back to the initiator.

9.2 Distance estimation based on phase and amplitude information

The Channel Sounding feature does not specify an algorithm for computing a distance
estimate, but a mathematical representation is provided here.

Let θCH(f) represent the phase delay of the channel, where f is the channel frequency,
and ΔθLO(f) represents the relative difference in phase of the RF carrier between the
devices.

Then the relative phases of a carrier measured at the reflector and initiator’s antenna is

θREFL(f) = θCH(f) + ΔθLO(f) and θINIT(f) = θCH(f) − ΔθLO(f).

Further, let AREFL(f) and AINIT(f) represent the amplitude of that measured carrier at
the reflector and initiator’s antenna. Let a phase correction term (PCT) be defined by
the angle that, if added to the internal angle of the local oscillator, would result in a
phase identical to that of the incoming signal. Then IQ values represented by the PCT
measured at the reflector and initiator are given by

PCTREFL(f) = AREFL(f)eiθREFL(f) and PCTINIT(f) = AINIT(f)eiθINIT(f)

Assume that the communication channel is symmetrical between the initiator and
reflector. Then the measured phases are dependent on both the communication
channel and the relative difference in phase of the RF carrier between the devices.

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 1, Part A Page 341
Architecture

The communication channel transfer function can then be estimated from

H2(f) = AREFL(f)eiθREFL(f) × AINIT(f)eiθINIT(f)= ACH2(f)ei2θCH(f)

Assume that from H2(f) it is possible to calculate the actual channel transfer function
H(f). Assuming that H(f) is a linear-time invariant transfer function, then an under-
resolved estimate of the impulse response h(t) can be calculated from the inverse
Fourier transform of H(f). Assuming that there is only one propagation path, then the
maximum peak in the estimate of the impulse response will occur at the delay between
the two devices, and assuming communication is at the speed of light, it is possible to
estimate the distance.

In the case of a single propagation path, a simplification may be made. Here, the
distance can also be estimated by the change in phase as a function of frequency.
Assume that the distance between initiator and reflector is x. The total distance traveled
by a reflected signal will then be 2x.
c
The equation for wavelength is λ = f . Assume that the initial phase of the initiator is
zero. If the channel is symmetrical, and if the initial phase of the reflector is zero; then
the total phase change over a distance x is given by
x xf
φCH f = − 2 × 2π λ = − 2 × 2π c

From this equation, the derivative of the phase as a function of frequency is a constant
and is proportional to distance.
dφCH f x
df
= − 4π c

From the channel transfer function, the phase change can be calculated as a function of
frequency.

φCH f = angle H 2 f (EQ 1)

An estimate of the distance, x, can then be calculated as follows.
dφCH f c
x= − df 4π

When channel measurements are taken at frequencies separated by 1 MHz, a distance

ambiguity occurs in the equation above when

φCH f + 1 MHz − φCH f (EQ 2)

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 1, Part A Page 342
Architecture

is an integer multiple of 2π. This gives a distance ambiguity every dwrap meters, as
shown below

2π 3×108 m/s
dwrap = 1 MHz 4π
= 150 m

To support distance estimation of larger distances, round-trip timing can be used to

disambiguate distance results.

9.3 Distance estimation based on RTT packets

For RTT in the CS feature, the two devices exchange packets of the format known as
CS_SYNC, which is described in [Vol 6] Part H, Section 2. Time of departure (ToD) and
time of arrival (ToA) times are used to estimate the time of flight (ToF), as shown in
Figure 9.2.

Assuming the same time base on both devices, sufficient precision of ToD and ToA for
the required distance accuracy, and line of sight conditions with no reflections, then an
estimated distance, x, can be calculated as shown in the equation below, where c is the
speed of light.
T initator ‐ T reflector
x= 2
×c

Figure 9.2: Time of arrival (ToA), time of departure (ToD), and time of flight (ToF) for RTT estimation

The accuracy of RTT ToF estimation depends on the capabilities of both devices. CS
supports RTT based on timing extracted from a CS Access Address that consists of
a 32-bit pseudo-noise bit sequence, and optionally based on timing extracted from a
sounding sequence payload of up to 96 bits or a random sequence of up to 128 bits.

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 1, Part A Page 343
Architecture

9.4 Security features

The CS feature includes security measures to reduce the probability of distance
spoofing.

RTT and phase-based ranging can be employed in the same CS subevent or in the
same CS step (CS step mode-3) to provide two partially independent estimates of
distance.

CS step mode-1 and CS step mode-3 allow devices to potentially detect whether an
attacker is present. With a random sequence, it is possible to measure how much a
received GFSK modulated packet signal differs from the expected packet signal. With a
sounding sequence, it is possible to detect the position of one or more marker signals.

A DRBG is employed by devices using the CS feature. The components used to

generate the key material for this DRBG are exchanged between the device pair under
an encrypted link and is never shared external to each device. This DRBG is used to
cryptographically randomize the channel hop selection, the use of CS step modes, the
modulation of tones, the transmission order in the case where multiple antenna paths
are used, and the CS Access Address and payload content of CS_SYNC packets.

Bluetooth SIG Proprietary Version Date: 2024-08-27

 Architecture, Change History,
And Conventions
Part B

ACRONYMS &
ABBREVIATIONS

Bluetooth SIG Proprietary

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 1, Part B Page 345
Acronyms & Abbreviations

CONTENTS

1 List of acronyms and abbreviations ....................................................... 346

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 1, Part B Page 346
Acronyms & Abbreviations

1 LIST OF ACRONYMS AND ABBREVIATIONS

Acronym or
Writing out in full Comments
abbreviation
8DPSK 8 phase Differential Phase Shift 3 Mb/s modulation type used by Enhanced
Keying Data rate
AAD Additional Authenticated Data
ACI Antenna Configuration Index
ACK Acknowledge/Acknowledgment
ACL Asynchronous Connection-oriented Reliable or time-bounded, bi-directional, point-
[logical transport] to-point
ACL-C ACL Control [logical link] (LMP)
ACL-U ACL User [logical link] (L2CAP)
ACO Authenticated Ciphering Offset
AD Advertising Data
Adv_idx Advertising channel index
ADVB LE Advertising Broadcast
ADVB-C LE Advertising Broadcast Control
(Logical Link)
ADVB-U LE Advertising Broadcast User Da-
ta (Logical Link)
ADI AdvDataInfo
AES Advanced Encryption Standard
AES-CCM Advanced Encryption Standard -
Counter with CBC-MAC
AFH Adaptive Frequency Hopping
AHS Adapted Hop Sequence
AoA Angle of Arrival
AoD Angle of Departure
APB Active Peripheral Broadcast [logi- Unreliable, uni-directional broadcast to any de-
cal transport] vices synchronized with the physical channel
APB-C APB Control [logical link] (LMP)
APB-U APB User [logical link] (L2CAP)
ARQ Automatic Repeat Request
ASK Amplitude Shift Keying
ATT Attribute Protocol

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 1, Part B Page 347
Acronyms & Abbreviations

Acronym or
Writing out in full Comments
abbreviation
BB Baseband
BCH Bose, Chaudhuri & Hocquenghem Type of code
The persons who discovered these codes in
1959 (H) and 1960 (B&C)
BD_ADDR Bluetooth Device Address
BER Bit Error Rate
BIG Broadcast Isochronous Group A group of one or more time-related Broadcast
Isochronous Streams
BIS Broadcast Isochronous Stream Connectionless isochronous logical transport
BT Bandwidth Time
C Central
C.# Conditional Any number may be used. See [Vol 1] Part E,
Section 2.11
CAC Channel Access Code
CBC-MAC Cipher Block Chaining Message
Authentication Code
CCM Counter with CBC-MAC
CIG Connected Isochronous Group A group of one or more time-related Connec-
ted Isochronous Streams
CIS Connected Isochronous Stream Point-to-point isochronous logical transport
CLKN Native Clock
CLK Central's Clock
CLKE Estimated Clock
CODEC COder DECoder
COF Ciphering Offset
CP CTEInfo Present A field in the Data Channel PDU Header to
indicate the presence of the CTEInfo field
CPB Connectionless Peripheral Broad- The logical transport enabled by the Connec-
cast tionless Peripheral Broadcast feature
CRC Cyclic Redundancy Check
CS Channel Sounding
CS Tone Channel Sounding Tone Unmodulated carrier associated with the
phase-based ranging technique
CSA Core Specification Addendum (In plural Addenda)

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 1, Part B Page 348
Acronyms & Abbreviations

Acronym or
Writing out in full Comments
abbreviation
CSRK Connection Signature Resolving
Key
CTE Constant Tone Extension
CTEInfo Constant Tone Extension Informa- A field in the Data Channel PDU Header and
tion the extended advertising header
CTS Clear to send
CVSD Continuous Variable Slope Delta
Modulation
DAC Device Access Code
DCI Default Check Initialization
DEVM Differential Error Vector Magnitude Measure of modulation error used for En-
hanced Data Rate transmitter testing
DH Data-High Rate Data packet type for high rate data
DHK Diversifier Hiding Key
DIAC Dedicated Inquiry Access Code
DID (Advertising) Data ID
DIV Diversifier
DM Data - Medium Rate Data packet type for medium rate data
DPSK Differential Phase Shift Keying Generic description of Enhanced Data Rate
modulation
DQPSK Differential Quaternary Phase Shift Modulation type used by Enhanced Data Rate
Keying
DRBG Deterministic Random Bit Genera-
tor
DTM Direct Test Mode
DV Data Voice Data packet type for data and voice
E Excluded See [Vol 1] Part E, Section 2.11
ECLD Early Commit Late Detect
EDIV Encrypted Diversifier
EDLC Early Detect Late Commit
EDR Enhanced Data Rate
EIR Extended Inquiry Response Host supplied information transmitted in the In-
quiry Response substate
EIRP Effective Isotropic Radiated Power Equivalent power that an isotropic antenna
must transmit to provide the same field power
density

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 1, Part B Page 349
Acronyms & Abbreviations

Acronym or
Writing out in full Comments
abbreviation
(e)SCO Synchronous logical link or Exten- SCO or eSCO
ded Synchronous logical link
eSCO Extended Synchronous Connec- Bi-directional, symmetric or asymmetric, point-
tion-Oriented [logical transport] to-point, general regular data, limited retrans-
mission
eSCO-S Stream eSCO (unframed) Used to support isochronous data delivered in
a stream without framing
ETSI European Telecommunications
Standards Institute
FAE Fractional Frequency Offset Actua-
tion Error
FCC Federal Communications Commis-
sion
FCS Frame Check Sequence
FDMA Frequency Division Multiple Ac-
cess
FEC Forward Error Correction code
FFO Fractional Frequency Offset
FHS Frequency Hop Synchronization
FHSS Frequency Hopping Spread Spec-
trum
FIFO First In First Out
FIPS Federal Information Processing
Standards
FM Frequency Modulation Modulation type
GAP Generic Access profile
GATT Generic Attribute profile
GFSK Gaussian Frequency Shift Keying
GIAC General Inquiry Access Code Used for GAP General Discoverable mode
and General Inquiry procedure. See Assigned
Numbers.
HCI Host Controller interface
HEC Header-Error-Check
HID Human Interface Device
HV High quality Voice e.g. HV1 packet
HW Hardware

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 1, Part B Page 350
Acronyms & Abbreviations

Acronym or
Writing out in full Comments
abbreviation
IAC Inquiry Access Code
IC Industry Canada
IEC International Electrotechnical Com-
mission
IEEE Institute of Electrical and Electron-
ics Engineers
IETF Internet Engineering Task Force
IFS Inter Frame Space
IP Internet Protocol
IPv4 Internet Protocol version 4
IPv6 Internet Protocol version 6
IQ In-phase and Quadrature
IrDA Infra-red Data Association
IRK Identity Resolving Key
ISM Industrial, Scientific, Medical
ISO International Organization for
Standardization
ISO Isochronous
ISOAL Isochronous Adaptation Layer The layer that converts data units from the up-
per layer to data units in the Link Layer and
vice versa
ITU International Telecommunication
Union
IUT Implementation Under Test
IV Initialization Vector
IV_C Initialization Vector (Central)
IV_P Initialization Vector (Peripheral)
L2CAP Logical Link Control and Adapta-
tion protocol
LAP Lower Address Part
LC Link Controller Link Controller (or Baseband) part of the Blue-
tooth protocol stack. Low level Baseband pro-
tocol handler
LC Link Control [logical link] The control logical links LC and ACL-C are
used at the link control level and link manager
level, respectively.

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 1, Part B Page 351
Acronyms & Abbreviations

Acronym or
Writing out in full Comments
abbreviation
LE Low Energy
LEB-C Low Energy Broadcast Control A logical link for control of Broadcast Isochro-
nous Streams in a Broadcast Isochronous
Group
LE-C Low Energy Control (link)
LE-F Low Energy Framed A logical link for transferring framed isochro-
nous data packets using a Connected or
Broadcast Isochronous Stream logical trans-
port
LE-S Low Energy Stream A logical link for transferring unframed iso-
chronous data packets using a Connected or
Broadcast Isochronous Stream logical trans-
port
LE-U LE User [logical link]
LFAE Local Frequency Actuation Error
LFSR Linear Feedback Shift Register
LIAC Limited Inquiry Access Code Used for GAP Limited Discoverable mode and
Limited Inquiry procedure. See Assigned Num-
bers.
LL Link Layer
LLID Logical Link Identifier
LM Link Manager
LMP Link Manager protocol For LM peer to peer communication
LR Loudness Rating
LSB Least Significant Bit
LSO Least Significant Octet
LSTO Link Supervision Timeout event Controller can send LSTO event to Host
LT_ADDR Logical Transport ADDRess
LTK Long-Term Key
M Mandatory See [Vol 1] Part E, Section 2.11
MAC Message Authentication Code
Mb/s Megabits (millions of bits) per sec-
ond
MD More Data
MIC Message Integrity Check
MITM Man-in-the-middle

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 1, Part B Page 352
Acronyms & Abbreviations

Acronym or
Writing out in full Comments
abbreviation
Msym/s Megasymbols per second
MSB Most Significant Bit
mSBC modified Sub Band Codec Hands-Free Profile v1.6 or later
MSC Message sequence chart
MSO Most Significant Octet
MTU Maximum Transmission Unit
MWS Mobile Wireless Standards For example LTE and WiMAX
N_AP Number of Antenna Paths
NADM Normalized Attack Detector Metric
NAK Negative Acknowledge
NAP Non-significant Address Part
NESN Next Expected Sequence Number
NIST National Institute of Standards and
Technology
O Optional See [Vol 1] Part E, Section 2.11
OBEX OBject EXchange protocol
OCF Opcode Command Field
OGF Opcode Group Field
OOB Out of Band
π/4-DQPSK π/4 Rotated Differential Quaternary 2 Mb/s modulation type used by Enhanced
Phase Shift Keying Data Rate
P Peripheral
PADVB LE Periodic Advertising Broadcast
(Logical Transport)
PAwR Periodic Advertising with Respon-
ses
PBD Profile Broadcast Data The name of the logical link enabled by the
Connectionless Peripheral Broadcast feature
PBF Packet Boundary Flag The device supports the capability to correctly
handle HCI ACL Data packets
PBR Phase-Based Ranging
PCM Pulse Coded Modulation
PCT Phase Correction Term
PDU Protocol Data Unit A message

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 1, Part B Page 353
Acronyms & Abbreviations

Acronym or
Writing out in full Comments
abbreviation
PHY Physical Layer
PIN Personal Identification Number
PN Pseudo-random Noise
ppm Part Per Million
PPP Point-to-Point Protocol
PRBS Pseudo Random Bit Sequence
PRNG Pseudo Random Noise Generation
PSK Phase Shift Keying Class of modulation types
ptt Packet Type Table The ptt parameter is used to select the logical
transport types via LMP.
QoS Quality of Service
RAND Random number
RF Radio Frequency
RFC Request For Comments
RFCMode Retransmission and Flow Control
Mode
RFCOMM Serial cable emulation protocol based on ETSI
TS 07.10
RFU Reserved for future use
RMS Root Mean Square
RPA Resolvable Private Address
RPL Reference Power Level
RSSI Received Signal Strength Indica-
tion
RTT Round-Trip Time
RX Receive
SAR Segmentation and Reassembly
SCA Sleep Clock Accuracy
SCO Synchronous Connection-Oriented Bi-directional, symmetric, point-to-point, AV
[logical transport] channels
SCO-S Stream SCO (unframed) Used to support isochronous data delivered in
a stream without framing
SDP Service Discovery protocol
SDU Service Data Unit

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 1, Part B Page 354
Acronyms & Abbreviations

Acronym or
Writing out in full Comments
abbreviation
SEQN Sequential Numbering scheme
SID (Advertising) Set ID
SK Session Key
SKD_C Session Key Diversifier (Central) Central portion of the Session Key Diversifier
SKD_P Session Key Diversifier (Peripher- Peripheral portion of the Session Key Diversifi-
al) er
SM Security Manager
SMP Security Manager Protocol
SN Sequence Number
SNR Signal-to-Noise Ratio
SRES Signed Response
SRK Signature Resolving Key
SSI Signal Strength Indication
SSP Secure Simple Pairing
STK Short Term Key
SW Software
T_FCS Time for Frequency Change Spac-
ing
T_FM Time for Frequency Measurement
T_GD Time for Guard period
T_IFS Time Inter Frame Space Time interval between consecutive packets on
same channel index in the situation indicated
by the suffix. See [Vol 6] Part B, Section 4.1.1.
T_IP1 Time for Interlude Period 1 (be-
tween CS packets)
T_IP2 Time for Interlude Period 2 (be-
tween CS tones)
T_MCES Time Minimum Connection Event Minimum time interval between connection
Spacing events. See [Vol 6] Part B, Section 4.1.5.
T_MSS Time Minimum Subevent Spacing Minimum time interval between subevents in
the situation indicated by the suffix. See [Vol 6]
Part B, Section 4.2.2.
T_PM Time for Phase Measurement
T_RD Time for (transmission) Ramp-
Down

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 1, Part B Page 355
Acronyms & Abbreviations

Acronym or
Writing out in full Comments
abbreviation
T_SY Time for synchronization sequence
(CS packet)
TCP/IP Transport Control Protocol/Internet
Protocol
TCS Telephony Control protocol Specifi-
cation
TDD Time-Division Duplex
TDMA Time Division Multiple Access
TK Temporary Key
ToA Time of Arrival
ToD Time of Departure
ToF Time of Flight
TX Transmit
UAP Upper Address Part
UART Universal Asynchronous receiver
Transmitter
UI User Interface
ULAP Upper and Lower Address Parts
USB Universal Serial Bus
UTF-8 8-bit UCS/Unicode Transformation
Format
UUID Universal Unique Identifier

Table 1.1: Acronyms and abbreviations

Bluetooth SIG Proprietary Version Date: 2024-08-27

 Architecture, Change History,
And Conventions
Part C

CORE SPECIFICATION
CHANGE HISTORY

Bluetooth SIG Proprietary

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 1, Part C Page 357
Core Specification Change History

CONTENTS

1 Removed features ..................................................................................... 359

2 Changes from v1.1 to v1.2 ....................................................................... 360

2.1 New features ............................................................................... 360
2.2 Structure changes ....................................................................... 360
2.3 Deprecated features list .............................................................. 361
2.4 Changes in wording .................................................................... 361
2.5 Nomenclature changes ............................................................... 361

3 Changes from v1.2 to v2.0 + EDR ............................................................ 362

3.1 New features ............................................................................... 362
3.2 Deprecated features .................................................................... 362

4 Changes from v2.0 + EDR to v2.1 + EDR ................................................ 363

4.1 New features ............................................................................... 363
4.2 Removed features ....................................................................... 363

5 Changes from v2.1 + EDR to v3.0 + HS .................................................. 364

5.1 New features ............................................................................... 364
5.2 Removed features ....................................................................... 364

6 Changes from v3.0 + HS to v4.0 .............................................................. 365

6.1 New features ............................................................................... 365
6.2 Removed features ....................................................................... 365

7 Changes from v4.0 to v4.1 ....................................................................... 366

7.1 New features ............................................................................... 366
7.1.1 Features added in CSA 4 – integrated in v4.1 ............. 366
7.1.2 Features added in CSA 3 – integrated in v4.1 ............. 366
7.1.3 Features added in CSA 2 – integrated in v4.1 ............. 367
7.2 Removed features ....................................................................... 367

8 Changes from v4.1 to v4.2 ....................................................................... 368

8.1 New features ............................................................................... 368
8.2 Errata incorporated in v4.2 .......................................................... 368

9 Changes from v4.2 to v5.0 ....................................................................... 370

9.1 New features ............................................................................... 370
9.1.1 Features added in CSA5 - integrated in v5.0 .............. 370
9.2 Removed features ....................................................................... 370
9.3 Privacy errata .............................................................................. 370

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 1, Part C Page 358
Core Specification Change History

9.4 Errata incorporated in v5.0 .......................................................... 371

10 Changes from v5.0 to v5.1 ....................................................................... 375

10.1 New features ............................................................................... 375
10.1.1 Features added in CSA6 – integrated in v5.1 .............. 375
10.2 Removed features ....................................................................... 375
10.3 Security erratum .......................................................................... 375
10.4 Errata incorporated in v5.1 .......................................................... 375

11 Changes from v5.1 to v5.2 ....................................................................... 378

11.1 New features ............................................................................... 378
11.2 Security erratum .......................................................................... 378
11.3 Errata incorporated in v5.2 .......................................................... 378

12 Changes from v5.2 to v5.3 ....................................................................... 380

12.1 New features ............................................................................... 380
12.2 Removed Features ...................................................................... 380
12.3 Errata incorporated in v5.3 .......................................................... 380
12.4 Global terminology changes ........................................................ 383

13 Changes from v5.3 to v5.4 ....................................................................... 385

13.1 New features ............................................................................... 385
13.2 Removed features ....................................................................... 385
13.3 Errata incorporated in v5.4 .......................................................... 385

14 Changes from v5.4 to v6.0 ....................................................................... 388

14.1 New features ............................................................................... 388
14.2 Removed features ....................................................................... 388
14.3 Errata incorporated in v6.0 .......................................................... 388

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 1, Part C Page 359
Core Specification Change History

1 REMOVED FEATURES

Some features have been deemed no longer useful and have been removed. The term
removed does not mean that they are no longer allowed, but that they are no longer
recommended as the best way of performing a given function.

Removed features may be implemented using the latest qualifiable version (if any) of
the specification that specifies the removed features.

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 1, Part C Page 360
Core Specification Change History

2 CHANGES FROM V1.1 TO V1.2

2.1 New features

Several new features were introduced in the version 1.2. The major areas of
improvement are:

• Architectural overview
• Faster connection
• Adaptive frequency hopping
• Extended SCO links
• Enhanced error detection and flow control
• Enhanced synchronization capability
• Enhanced flow specification

The feature descriptions are incorporated into the existing text in different core parts,
described in Volumes 2 and 3.

2.2 Structure changes

Version 1.2 was significantly restructured for better consistency and readability. The
most important structure changes have been performed in Baseband, LMP, HCI and
L2CAP. The text in these sections has been rearranged to provide:

• Presentation of the information in a more logical progression

• Removal of redundant text and requirements
• Consolidation of Baseband-related requirements (for example, the Baseband Timers
and Bluetooth Audio sections into the Baseband Specification)
• Alignment of the specification with the new architecture and terminology presented in
the Architecture Overview (see [Vol 1] Part E).

In addition, new text and requirements were added for the new features as well as many
changes throughout the specification to update the text to use IEEE language (see [Vol
1] Part E).

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 1, Part C Page 361
Core Specification Change History

2.3 Deprecated features list

Features deprecated in version 1.2 are:

• The use of Unit Keys for security

• Optional Paging schemes
• 23 channel hopping sequence
• Page scan period mode and associated commands

2.4 Changes in wording

Two general classes of changes to the wording of the Bluetooth Specification have been
done for version 1.2. They are a formalization of the language by using conventions
established by the Institute of Electrical and Electronic Engineers (IEEE), and a
regularization of Bluetooth wireless technology-specific terms. Many portions of the
version 1.1 specification use imprecise or inaccurate terms to describe attributes of
the protocol. A more accurate terminology described in Part E was introduced into the
version 1.2 specification and have been applied in future versions.

2.5 Nomenclature changes

The nomenclature in Bluetooth 1.2 was also updated due to new concepts that are
introduced together with the new features and the new architecture. See [Vol 1] Part A.

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 1, Part C Page 362
Core Specification Change History

3 CHANGES FROM V1.2 TO V2.0 + EDR

3.1 New features

Version 2.0 + EDR introduces Enhanced Data Rate (EDR). EDR provides a set of
additional packet types that use the new 2 Mb/s and 3 Mb/s modes.

In addition to EDR a set of errata provided in ESR02 has been incorporated into this
version and revised to include changes caused by the addition of EDR.

These additions are incorporated into the existing text in different core parts described
in Volumes 2 and 3.

3.2 Deprecated features

The only feature deprecated in version 2.0 + EDR is the Page Scan Period Mode and
associated commands (based on Erratum 694 which is also included in ESR02).

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 1, Part C Page 363
Core Specification Change History

4 CHANGES FROM V2.0 + EDR TO V2.1 + EDR

4.1 New features

Several new features are introduced in version 2.1 + EDR. The major areas of
improvement are:

• Erroneous Data Reporting

• Encryption Pause and Resume
• Extended Inquiry Response
• Link Supervision Timeout Changed event
• Non-Automatically-Flushable Packet Boundary Flag
• Secure Simple Pairing
• Sniff Subrating
• Security Mode 4

4.2 Removed features

No features were removed in v2.1 + EDR.

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 1, Part C Page 364
Core Specification Change History

5 CHANGES FROM V2.1 + EDR TO V3.0 + HS

5.1 New features

Several new features are introduced in version 3.0 + HS. The major areas of
improvement are:

• AMP Manager protocol (A2MP)

• Enhancements to L2CAP including
– Enhanced Retransmission Mode and Streaming Mode
– Improvements to the L2CAP state machine for AMP channels
– Fixed channel support
• Enhancements to HCI for AMP
• Enhancements to Security for AMP
• 802.11 Protocol Adaptation Layer
• Enhanced Power Control
• Unicast Connectionless Data
• HCI Read Encryption Key Size command
• Generic Test Methodology for AMP
• Enhanced USB and SDIO HCI Transports

5.2 Removed features

No features were removed in v3.0 + HS.

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 1, Part C Page 365
Core Specification Change History

6 CHANGES FROM V3.0 + HS TO V4.0

6.1 New features

Several new features are introduced in version 4.0. The major areas of improvement
are:

• Bluetooth Low Energy including

– Low Energy Physical Layer
– Low Energy Link Layer
– Enhancements to HCI for Low Energy
– Low Energy Direct Test Mode
– AES Encryption
– Enhancements to L2CAP for Low Energy
– Enhancements to GAP for Low Energy
– Attribute Protocol (ATT)
– Generic Attribute profile (GATT)
– Security Manager (SM)

6.2 Removed features

No features were removed in v4.0.

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 1, Part C Page 366
Core Specification Change History

7 CHANGES FROM V4.0 TO V4.1

7.1 New features

Several new features are introduced in the version 4.1. The major areas of improvement
are:

• BR/EDR Secure Connections

• Train nudging
• Generalized interlaced scan
• Low duty cycle directed advertising
• 32-bit UUID support in LE
• LE dual mode topology
• Piconet clock adjustment
• LE L2CAP connection-oriented channel support
• LE privacy v1.1
• LE Link Layer topology
• LE ping

7.1.1 Features added in CSA 4 – integrated in v4.1

• Connectionless Peripheral Broadcast

• Unencrypted unicast connectionless data support
• Fast advertising interval
• eSCO reserved slots clarification

7.1.2 Features added in CSA 3 – integrated in v4.1

• MWS coexistence HCI changes

• GAP connection parameters changes
• GAP authentication and lost bond
• Dual mode addressing
• Private address changes
• Common profile and service error code changes
• MWS coexistence signaling

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 1, Part C Page 367
Core Specification Change History

• Wireless coexistence interface 1 (WCI-1) transport specification

• Wireless coexistence interface 2 (WCI-2) transport specification

7.1.3 Features added in CSA 2 – integrated in v4.1

• Limited discovery time changes

• EIR and AD data types in GAP
• Audio architecture HCI changes
• Audio architecture USB changes
• 802.11n enhancements to the 802.11 PAL

7.2 Removed features

No features were removed in v4.1.

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 1, Part C Page 368
Core Specification Change History

8 CHANGES FROM V4.1 TO V4.2

8.1 New features

Several new features are introduced in version 4.2. The major areas of improvement
are:

• LE Data Packet Length Extension

• LE Secure Connections
• Link Layer privacy
• Link Layer Extended Scanner Filter policies

8.2 Errata incorporated in v4.2

Table 8.1 lists the integrated ESR08 errata items and also some ESR09 items, without
test impact, which were added to v4.2 prior to the ESR09 release.

ESR08 ESR09
Global / Several Parts 5782, 6001
V0B: Compliance Req. 5748
V1A: Architecture Overview 4767, 4768, 4858, 5526, 5531, 5965, 6086
5742, 5748
V2A: Radio 5179
V2B: Baseband 2645, 2668, 3909, 4997, 5185, 5829, 5875, 5966
5447, 5636
V2C: LMP 4934, 5118. 5756 5754, 5802, 5815, 5816, 5817,
5818, 5819
V2D: Error Codes 5645, 5660 5814
V2E: HCI 4998, 5097, 5186, 5286, 5340, 5000, 5174, 5247, 5821, 5822,
5358, 5397, 5416, 5589, 5630, 5826, 5828, 5859, 5907, 5926,
5637, 5660, 5736, 5737, 5738 5927, 5935, 5959, 5960
V2F: MSCs 5621 5762
V2G: Sample Data
V2H: Security Spec. 4815, 4830, 4903
V3A: L2CAP 2765, 3253, 3767, 3768, 3901, 5987
3902, 3903, 4603, 4734, 4735,
4776, 5419
V3B: SDP 5258 5257

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 1, Part C Page 369
Core Specification Change History

ESR08 ESR09
V3C: GAP 2341, 4087, 4778, 4895, 4935, 5803, 5938, 5939, 5964, 5989
4936, 5618, 5441, 5051
V3F: ATT 6006
V3G: GATT 3817, 4358, 5116, 5117
V3H: Security Manager 6050
V4B: USB Transport Layer 5273
V6A: Physical Layer 5179
V6B: Link Layer 5231, 5232, 5233, 5234, 5235, 5824, 5922, 5947, 5950, 5954,
5236, 5307, 5360, 5419, 5428, 5994, 6116
5526, 5577, 5653, 5656, 5706,
5707, 5720, 5721, 5722, 5723
V6C: Sample Data 4948
V6D: MSCs 4797, 4798 6032
V6F: Direct Test Mode 4834, 5749, 5751
V7A: MWS Coexistence Logi- 5001
cal Signaling
V7B: WCI-1 Transport 5004, 5619

Table 8.1: Errata integrated in v4.2

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 1, Part C Page 370
Core Specification Change History

9 CHANGES FROM V4.2 TO V5.0

9.1 New features

Several new features are introduced in version 5.0. The major areas of improvement
are:

• Slot Availability Mask (SAM)

• 2 Msym/s PHY for LE
• LE Long Range
• High Duty Cycle Non-Connectable Advertising
• LE Advertising Extensions
• LE Channel Selection Algorithm #2

9.1.1 Features added in CSA5 - integrated in v5.0

• Higher Output Power

9.2 Removed features

The following features were removed in this version of the specification:

• Park State

9.3 Privacy errata

The Privacy errata shown in Table 9.1 have been resolved and integrated in this version
of the specification.

Erratum Title
5433 In Table 9.3, C1 condition should be removed
6182 Invalid behavior with resolving address list not clear in Core or Test Spec
6214 Statement mismatch between procedure description and figure
6247 Unclear when to use LE Directed Advertising Report event or LE Advertising
Report event
6356 Defining scanner’s device address in “Scanner filter policy”
6391 Usage of peer address type not clear in privacy 1.2
6399 LE Enhanced Connection Complete event
6401 Central Address Resolution Char in LE Peripheral

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 1, Part C Page 371
Core Specification Change History

Erratum Title
6469 Advertiser is not required to check AdvA
6471 AdvA not well defined in SCAN_RSP pdu, when privacy 1.2 enabled
6508 HCI command name mismatch
6519 When an advertiser device (or scanning performing active scanning) using priva-
cy and Controller based resolvable private address generation is supposed to
answer to a scan request (or advertising) received?
6613 Privacy Mode not clearly defined
6629 LE Directed Advertising Report event - Order of parameters
6984 How does Adv respond to RPA in Connect Req when there’s no IRK and no WL

Table 9.1: Privacy errata

9.4 Errata incorporated in v5.0

Table 9.2 lists the integrated ESR09 and ESR10 errata items.

ESR09 ESR10
Global / Several Parts 5782, 6001, 6334 6570, 6751, 6855. 7076
V0B: Bluetooth Compliance 6360, 6717
Requirements
V1A: Architecture Overview 5900, 5965, 6086, 6120, 6193, 6356, 6421, 6465, 6524, 6529,
6240, 6242, 6277, 6284, 6288, 6558, 6603, 6604, 6766, 6922,
6290, 6303, 6361, 6363, 6364 7030, 7031, 7301
V1B: Acronyms & Abbrevia- 6277, 6349 6717
tions
V1C: Change History 6195, 6318
V1E: IEEE Language 6208, 6381 6421, 6422, 7521
V2A: Radio 6199, 6547
V2B: Baseband 5829, 5875, 5966, 6096, 6193, 6421, 6443, 6446, 6480, 6505,
6277, 6350 6523, 6531, 6537, 6618, 6646,
6647, 6668, 6714, 6721, 6749,
6953, 6964
V2C: LMP 5753, 5754, 5802, 5815, 5816, 4783, 6447, 6531, 6606, 6735,
5817, 5818, 5819, 6114, 6175, 6773, 6776, 6852
6176, 6177, 6193, 6210, 6277,
6289, 6291, 6295, 6332, 6339,
6388, 6389, 6404
V2D: Error Codes 5112, 5511, 5814, 6305, 6309 6421

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 1, Part C Page 372
Core Specification Change History

ESR09 ESR10
V2E: HCI 4354, 5000, 5174, 5247, 5266, 4761, 4999, 5003, 6007, 6182,
5821, 5822, 5826, 5828, 5859, 6247, 6356, 6399, 6421, 6451,
5905, 5907, 5926, 5927, 5935, 6452, 6493, 6508, 6531, 6532,
5959, 5960, 6072, 6110, 6115, 6534, 6536, 6541, 6556, 6559,
6211, 6265, 6277, 6278, 6286, 6563, 6566, 6568, 6576, 6629,
6293, 6301, 6302, 6326, 6338, 6672, 6689, 6709, 6716, 6722,
6339, 6374, 6409, 6419, 6420 6749, 6752, 6767, 6797, 6807,
6856, 6857, 6882, 6886, 6910,
6914, 6918, 6927, 6939, 6986,
6997, 6998, 7017, 7021, 7024,
7045, 7067, 7068, 7069, 7077,
7372
V2F: MSCs 5762, 5875, 6212, 6286, 6319 5089, 6218, 6428, 6531
V2H: Security Specification 6194, 6359 5791, 5792, 5882, 6421, 6902,
6906, 6907
V3A: L2CAP 5459, 5465, 5466, 5467, 5648, 3548, 6417, 6421, 6567, 6702,
5666, 5805, 5987, 6108, 6121, 6898, 6939
6277, 6307, 6333
V3B: SDP 5257, 6308 6421, 6694
V3C: GAP 4958, 5562, 5786, 5803, 5821, 4348, 4777, 4872, 4919, 5110,
5938, 5939, 5964, 5989, 6166, 5399, 5407, 5418, 5433, 5435,
6167, 6168, 6215, 6217, 6222, 5708, 5778, 6214, 6356, 6401,
6313, 6405, 6411 6421, 6439, 6502, 6510, 6574,
6575, 6599, 6732, 6745, 6764,
6897, 7032, 7033, 7354, 7355
V3D:Test Support 6421, 6525, 7075
V3F: ATT 5953, 6006, 6132, 6357 4243, 5107, 5610, 5919, 6098,
6575
V3G: GATT 4253, 4836, 5059, 6251 4654, 5242, 5359, 5383, 5717,
5718, 5719, 6575, 6582, 7028,
7065, 7066, 7072
V3H: Security Manager 4793, 4794, 5427, 5625, 6050, 4796, 6219, 6421, 6436, 6729,
6207, 6405 6796, 6824, 6946, 7461
V4A: UART Transport 6264
V4B: USB Transport Layer 5274 4165
V5A: 802.11 Protocol Adapta- 6421, 7036
tion
V6A: Physical Layer 6118, 6156 6228

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 1, Part C Page 373
Core Specification Change History

ESR09 ESR10
V6B: Link Layer 5174, 5534, 5745, 5824, 5922, 6182, 6352, 6356, 6421, 6455,
5947, 5950, 5954, 5986, 5994, 6469, 6471, 6517, 6518, 6531,
6116, 6119, 6123, 6131, 6153, 6553, 6577, 6586, 6664, 6672,
6164, 6167, 6168, 6188, 6192, 6697, 6710, 6733, 6734, 6821,
6197, 6268, 6294, 6306, 6310, 6847, 6913, 6939, 6947, 6962,
6311, 6321, 6331, 6339, 6345, 6963, 6984, 7003, 7025, 7034,
6371, 6384 7080, 7081, 7106, 7153
V6C: Sample Data 5809
V6D: MSCs 6032, 6269 6563, 6672, 6847
V6E: LE Link Layer Security 6194
V6F: Direct Test Mode 6390 6619, 6793, 6798, 7005, 7029
V7A: MWS Coexistence Logi- 6234 5002
cal Signaling
V7B: Wireless Coexistence 6915
Interface 1
V7C: Wireless Coexistence 6915
Interface 2

Table 9.2: Errata integrated in v5.0

Table 9.3 lists the integrated ESR11 errata items.

ESR11
Global / Several Parts 7238, 7239, 7340
V0C: Revision History and 7895
Acknowledgments
V1A: Architecture Overview 7421, 7422, 7423, 7484, 7772,
7777, 7980
V1B: Acronyms & Abbrevia- 7777, 7895
tions
V1C: Change History 7777
V1D: Mixing of Spec Versions 7351, 7358
V1E: IEEE Language
V2A: Radio 7278, 7526, 7662, 7777
V2B: Baseband 7304, 7305, 7320, 7651, 7777
V2C: LMP 7145, 7284, 7285, 7292, 7320,
7367, 7713
V2D: Error Codes 7293, 8039

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 1, Part C Page 374
Core Specification Change History

ESR11
V2E: HCI 7143, 7158, 7185, 7187, 7217,
7218, 7234, 7262, 7274, 7326,
7334, 7375, 7396, 7458, 7485,
7504, 7644, 7650, 7706, 7716,
7717, 7821, 7835, 7851, 7867,
7871, 7900, 7991, 8090
V2F: MSCs 7509
V3A: L2CAP 7115, 7116, 7527, 7869
V3B: SDP 7819
V3C: GAP 7873, 8024
V3D:Test Support 7878
V3F: ATT 8041
V3G: GATT 7159, 7160, 7737, 7891, 7896,
7897, 8051, 8055
V3H: Security Manager 7226, 7320, 7469
V5A: 802.11 Protocol Adapta- 7875, 7876, 7878
tion
V6A: Physical Layer 7408, 7777
V6B: Link Layer 7122, 7152, 7195, 7209, 7269,
7320, 7321, 7330, 7331, 7481,
7482, 7630, 7686, 7720, 7777,
7791, 7809, 7995, 8031
V6D: MSCs 7509
V6F: Direct Test Mode 7156, 7281, 7696
V7A: MWS Coexistence Logi- 7525
cal Signaling

Table 9.3: Errata integrated in v5.0

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 1, Part C Page 375
Core Specification Change History

10 CHANGES FROM V5.0 TO V5.1

10.1 New features

Several new features are introduced in v5.1. The major areas of improvement are:

• Angle of Arrival (AoA) and Angle of Departure (AoD)

• Advertising Channel Index
• GATT Caching
• Minor Enhancements batch 1
– HCI support for debug keys in LE Secure Connections
– Sleep clock accuracy update mechanism
– ADI field in scan response data
– Interaction between QoS and Flow Specification
– Host channel classification for secondary advertising
– Allow the SID to appear in scan response reports
– Specify the behavior when rules are violated
• Periodic Advertising Sync Transfer

10.1.1 Features added in CSA6 – integrated in v5.1

• Models
• Mesh-based model hierarchy

10.2 Removed features

The following features were removed in this version of the specification:

• Unit keys

10.3 Security erratum

Erratum 10734, which introduces new security requirements relating to pairing, has
been resolved and integrated in this version of the specification.

10.4 Errata incorporated in v5.1

Table 10.1 lists the integrated ESR errata items.

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 1, Part C Page 376
Core Specification Change History

ESR11 ESR12
Global / Several Parts 8407, 9085, 9088, 10278
V0C: Appendix 9065
V1A: Architecture Overview 8132, 8211, 8218, 8347, 8632, 9413, 9495, 9619, 9656, 9727,
8804, 8808 9790, 10049, 10241, 10245,
10349
V1B: Acronyms & Abbrevia- 10193
tions
V1C: Change History 9065
V1D: Mixing of Spec Versions 9049
V1E: General Terminology 8129 9222, 9223, 9499, 10295
V2A: Radio 9477
V2B: Baseband 8153, 8184, 8185, 8187, 8188, 9477, 9479, 9584, 9854, 9998,
8211, 8218, 8531, 8552, 8555, 10150, 10191, 10242, 10246,
8562 10291
V2C: LMP 8180, 8185, 8221, 8224, 8355, 8407, 8423, 9477, 9479, 9649,
8364, 8366, 8367, 8368, 8406, 9765, 9793, 10051, 10147,
8533, 8554, 8702, 8911 10197, 10224, 10392, 10645
V2D: Error Codes 8803
V2E: HCI 8106, 8117, 8134, 8149, 8170, 8407, 9085, 9159, 9160, 9165,
8172, 8176, 8181, 8202, 8236, 9220, 9297, 9303, 9323, 9386,
8262, 8267, 8329, 8352, 8387, 9396, 9398, 9413, 9432, 9477,
8522, 8531, 8556, 8557, 8559, 9479, 9548, 9560, 9561, 9563,
8560, 8561, 8562, 8596, 8597, 9564, 9603, 9615, 9657, 9658,
8621, 8622, 8647, 8649, 8650, 9661, 9663, 9703, 9709, 9778,
8651, 8653, 8654, 8658, 8660, 9794, 9865, 9866, 9902, 9970,
8661, 8689, 8752, 8848, 8858, 10067, 10095, 10120, 10150,
8859, 8868, 8909, 8914, 8920, 10338, 10348, 10380, 10383,
8932, 8934, 8953, 8970, 9044, 10433, 10447, 10528, 10535,
9106 10567, 10689, 10827
V2F: MSCs 8325
V2H: Security 8215 9479, 9653, 10141, 10224,
10313, 10594, 10673
V3A: L2CAP 8419, 8562 9477, 9479, 10052,10154,
10170, 10216, 10847
V3B: SDP 8562 9317, 10171, 10773
V3C: GAP 8229, 8230, 8232, 8354, 9098, 9370, 9371, 9391, 9592, 9692,
9107 10183, 10399, 10401, 10412,
10418, 10691
V3D:Test Support 8135, 8562 9477, 10147, 10410
V3E: A2MP 8562

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 1, Part C Page 377
Core Specification Change History

ESR11 ESR12
V3F: ATT 8208, 8412 9479
V3G: GATT 8562, 8563 9477, 9495, 9612, 9825, 9836,
9837, 10207
V3H: Security Manager 8562, 9074 9391, 9592, 9653, 9867, 10141
V4D: Three-wire UART 8562
V5A: 802.11 Protocol Adapta- 8562 9479, 10446
tion
V6A: Physical Layer
V6B: Link Layer 8001, 8097, 8180, 8203, 8204, 9162, 9205, 9277, 9328, 9382,
8228, 8246, 8249, 8250, 8278, 9391, 9411, 9433, 9479, 9484,
8300, 8315, 8324, 8365, 8387, 9524, 9556, 9603, 9676, 9679,
8424, 8425, 8431, 8432, 8433, 9754, 9806, 9820, 9870, 9958,
8447, 8564, 8595, 8598, 8699, 9967, 9972, 9984, 10001,
8745, 8773, 8801, 8803, 8812, 10002, 10013, 10073, 10103,
8854, 9056, 9060 10139, 10205, 10260, 10266,
10336, 10387, 10390, 10402,
10660, 10692, 10693, 10701,
10828, 11179
V6C: Sample Data 8179, 8235
V6D: MSCs 8299, 8313, 8314, 8316, 8322, 9432, 9603, 10631
8624, 8917, 9106
V6F: Direct Test Mode 8619, 8543, 9011 9799
V7A: MWS Coexistence Logi-
cal Signaling

Table 10.1: Errata integrated in v5.1

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 1, Part C Page 378
Core Specification Change History

11 CHANGES FROM V5.1 TO V5.2

11.1 New features

Several new features are introduced in v5.2. The major areas of improvement are:

• LE Isochronous Channels
• Enhanced Attribute Protocol
• LE Power Control

11.2 Security erratum

Erratum 11838, which introduces new security requirements and recommendations

relating to encryption key size on BR/EDR, has been resolved and integrated in this
version of the specification.

11.3 Errata incorporated in v5.2

Table 11.1 lists the integrated errata items.

v5.2
Global / Several Parts
V0A: Consolidated Table of Con- 11423
tents
V0C: Revision History and Acknowl-
edgments
V1A: Architecture Overview 10961, 11422, 11529, 12232
V1B: Acronyms & Abbreviations
V1C: Change History
V1D: Mixing of Spec Versions 11870
V1E: General Terminology 8544, 10987
V1F: Controller Error Codes
V2A: Radio
V2B: Baseband 11234, 11422, 11499, 11911, 11973, 11974, 12035, 12057,
12445
V2C: LMP 8544, 10939, 10993, 11505, 11838, 11921, 12057
V2F: MSCs 10972, 11070
V2H: Security 11909, 11910, 11911

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 1, Part C Page 379
Core Specification Change History

v5.2
V3A: L2CAP 11505, 11506, 11673, 11679, 12434, 12275
V3B: SDP 11505
V3C: GAP 6375, 10940, 11118, 11419, 11838, 12275, 12377
V3D:Test Support
V3E: A2MP
V3F: ATT 11112, 12105
V3G: GATT 10925, 10926, 10937, 11187, 12210, 12275, 12070
V3H: Security Manager 11294
V4D: Three-wire UART
V4E: HCI 8544, 10825, 10861, 10962, 10972, 10985, 10987, 11044,
11117, 11124, 11205, 11226, 11280, 11346, 11347, 11348,
11356, 11391, 11471, 11505, 11589, 11590, 11591, 11602,
11615, 11616, 11636, 11763, 11768, 11769, 11838, 11933,
12152, 12245, 12338, 12420, 12434, 12450, 12458, 12493,
12481, 12057, 12640
V5A: 802.11 Protocol Adaptation
V6A: Physical Layer 10958
V6B: Link Layer 10909, 10951, 10957, 11021, 11049, 11066, 11084, 11308,
11355, 11357, 11386, 11443, 11482, 11485, 11498, 11499,
11505, 11602, 11640, 11701, 11828, 12232, 12236, 12263,
13012
V6C: Sample Data 11330, 11357
V6D: MSCs 12109
V6E: Low Energy Link Layer 11551, 11649, 11683
V6F: Direct Test Mode 10984, 11731
V7A: MWS Coexistence Logical Sig- 10985
naling

Table 11.1: Errata integrated in v5.2

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 1, Part C Page 380
Core Specification Change History

12 CHANGES FROM V5.2 TO V5.3

12.1 New features

Several new features are introduced in v5.3. The major areas of improvement are:

• AdvDataInfo in Periodic Advertising

• Host to Controller Encryption Key Control Enhancements
• LE Enhanced Connection Update
• LE Channel Classification

12.2 Removed Features

The following features were removed in this version of the specification:

• Alternative MAC/PHY
• AMP Manager protocol (A2MP)
• L2CAP Enhancements for AMP
• 802.11 PAL
• 802.11n Enhancements to the 802.11 PAL

12.3 Errata incorporated in v5.3

Table 12.1 lists the integrated errata items.

v5.3
Global / Several Parts 11426, 11695, 12596, 14641, 15243, 15634
Front matter 15851, 16794
V0A: Consolidated Table of Con- 12495
tents
V0B: Bluetooth Compliance Re- 12495, 13250, 15754, 15874, 16979
quirements
V0C: Revision History and Acknowl- 12495, 15631, 15632, 16032, 16312, 16605, 17067
edgments
V1A: Architecture Overview 10421, 11289, 11421, 11424, 11733, 11925, 11927, 12348,
12495, 14689, 14866, 15301, 15315, 15379, 15461, 15525,
15526, 15527, 15533, 15583, 16013, 16113, 16209, 16506,
16614, 16671, 16794, 16817, 16825, 16833, 16980, 17139

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 1, Part C Page 381
Core Specification Change History

v5.3
V1B: Acronyms & Abbreviations 10860, 11747, 12495, 15189
V1C: Change History 10860, 12495, 14930, 15368, 16032, 16163
V1D: Mixing of Spec Versions 12495, 14945, 15055, 15850, 16065
V1E: General Terminology 10306, 10419, 11702, 12495, 13190, 13500, 14670, 14705,
14773, 14972, 15368, 15461, 15583, 15851, 16163, 16635,
16671, 16672, 16794, 16843, 16906
V1F: Controller Error Codes 11747, 12495, 12664, 12720, 13346
V2A: Radio 11289, 11424, 12654, 13254, 15065, 15201, 15306, 16404,
16981
V2B: Baseband 10860, 11289, 11421, 11751, 12348, 13150, 13180, 13528,
14732, 14866, 14972, 15131, 15282, 15306, 15334, 15461,
15583, 15607, 15633, 15642, 15670, 15833, 15851, 16209,
16380, 16673, 16794, 16817
V2C: LMP 10419, 10860, 11421, 11424, 11747, 12093, 12589, 12908,
13147, 13167, 13180, 13195, 13417, 13473, 14646, 14689,
14790, 15039, 15115, 15117, 15162, 15176, 15220, 15273,
15334, 15388, 15467, 15541, 15583, 15639, 15834, 15851,
16500, 16566, 16794
V2F: MSCs 10860, 11289, 11895, 12187, 15197, 15464, 15583, 15630,
16191, 16572, 16646, 16817
V2G: Sample Data 10860, 15547, 15851, 16981, 17025
V2H: Security 10860, 11424, 12068, 12348, 12880, 13169, 13265, 13450,
15198, 15215, 15280, 15306, 15307, 15308, 15389, 15548,
15549, 15583, 15642, 15668, 15671, 15734, 15851, 16981,
16986
V3A: L2CAP 10860, 11289, 11421, 11895, 12713, 13147, 13151, 13185,
13235, 14605, 14749, 15254, 15256, 15306, 15313, 15323,
15461, 15554, 15578, 15583, 15630, 15833, 15850, 15851,
15944, 16065, 16116, 16187, 16188, 16191, 16266, 16493,
16518, 16549, 16550, 16794, 16817, 16982, 17046
V3B: SDP 10419, 11421, 11751, 12800, 13472, 15274, 16635, 16982,
16989
V3C: GAP 10419, 10860, 11289, 11421, 11787, 12322, 12348, 12379,
12725, 12973, 13147, 13152, 13162, 13182, 13184, 13186,
13187, 13188, 13335, 13336, 13406, 13407, 13425, 13603,
14797, 14896, 15006, 15039, 15255, 15302, 15314, 15334,
15384, 15385, 15400, 15403, 15406, 15408, 15497, 15546,
15583, 15630, 15831, 15850, 15851, 15871, 15944, 16198,
16209, 16310, 16381, 16471, 16506, 16517, 16518, 16536,
16557, 16609, 16982
V3D:Test Support 10860, 15409
V3E: A2MP 11421, 13236, 16065

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 1, Part C Page 382
Core Specification Change History

v5.3
V3F: ATT 10843, 13147, 13183, 13184, 13255, 13305, 13511, 13530,
14761, 14819, 14988, 15832, 16018, 16494, 16495, 16505,
16794, 16817, 16982
V3G: GATT 10419, 10843, 11925, 12348, 12526, 13067, 13147, 13153,
13184, 13189, 13247, 13263, 13304, 13307, 13332, 13418,
14988, 15142, 15334, 15550, 15586, 15764, 15831, 15850,
16178, 16188, 16266, 16479, 16505, 16671, 16759, 16920
V3H: Security Manager 10860, 11293, 11424, 12348, 12880, 13147, 13276, 13408,
14708, 14964, 15198, 15310, 15314, 15315, 15555, 15583,
15642, 15668, 15850, 15851, 16305
V4A: UART Transport Layer 14674, 16983
V4B: USB Transport Layer 11289, 11421
V4C: Secure Digital (SD) Transport
Layer
V4D: Three-wire UART 16635
V4E: HCI 10419, 10860, 11421, 11424, 11702, 11747, 11754, 11764,
11895, 12036, 12093, 12253, 12313, 12379, 12517, 12598,
12599, 12604, 12664, 12693, 12802, 12863, 12866, 12956,
13029, 13081, 13104, 13139, 13142, 13143, 13148, 13177,
13246, 13252, 13253, 13261, 13278, 13286, 13287, 13293,
13321, 13344, 13346, 13374, 13375, 13376, 13377, 13379,
13426, 13438, 13473, 13498, 13527, 13533, 13534, 13536,
13542, 13546, 13570, 13582, 13597, 14615, 14617, 14636,
14650, 14651, 14655, 14665, 14700, 14706, 14713, 14714,
14741, 14747, 14770, 14771, 14824, 14830, 14831, 14834,
14841, 14867, 14871, 14893, 14895, 14901, 14909, 14916,
14934, 14957, 14969, 14980, 14984, 14998, 15007, 15010,
15021, 15030, 15031, 15032, 15034, 15035, 15039, 15059,
15062, 15075, 15109, 15111, 15132, 15152, 15174, 15190,
15204, 15223, 15233, 15275, 15281, 15282, 15288, 15305,
15310, 15311, 15334, 15378, 15380, 15382, 15412, 15413,
15461, 15471, 15496, 15507, 15508, 15509, 15513, 15524,
15526, 15553, 15570, 15583, 15590, 15592, 15593, 15597,
15622, 15633, 15640, 15643, 15651, 15695, 15728, 15732,
15745, 15752, 15816, 15826, 15837, 15843, 15850, 15851,
15964, 16015, 16058, 16101, 16125, 16129, 16133, 16142,
16164, 16167, 16180, 16191, 16238, 16287, 16288, 16299,
16318, 16329, 16330, 16331, 16359, 16381, 16397, 16435,
16445, 16480, 16504, 16506, 16538, 16561, 16584, 16610,
16612, 16635, 16636, 16656, 16674, 16681, 16793, 16794,
16796, 16822, 16817, 16913, 16915, 16983
V5A: 802.11 Protocol Adaptation 11421, 12253, 13473, 15523
V6A: Physical Layer 12313, 13254, 15065, 15306, 15461, 15851, 16372, 16984

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 1, Part C Page 383
Core Specification Change History

v5.3
V6B: Link Layer 11164, 11421, 11668, 11702, 11895, 12102, 12250, 12251,
12252, 12313, 12325, 12379, 12664, 12802, 12955, 13089,
13155, 13178, 13179, 13184, 13212, 13251, 13260, 13374,
13387, 13512, 13523, 13526, 13534, 13591, 13603, 14604,
14615, 14655, 14665, 14676, 14680, 14681, 14698, 14699,
14707, 14746, 14750, 14770, 14777, 14779, 14831, 14835,
14842, 14851, 14854, 14855, 14911, 14922, 14934, 14958,
14969, 14979, 15007, 15010, 15021, 15027, 15042, 15059,
15062, 15070, 15096, 15145, 15200, 15204, 15223, 15235,
15286, 15288, 15292, 15300, 15303, 15317, 15426, 15428,
15429, 15495, 15497, 15518, 15579, 15583, 15584, 15630,
15642, 15659, 15711, 15742, 15816, 15818, 15825, 15835,
15839, 15850, 15851, 15894, 15999, 16039, 16067, 16093,
16101, 16114, 16210, 16251, 16282, 16287, 16346, 16347,
16359, 16363, 16372, 16381, 16442, 16506, 16537, 16553,
16554, 16610, 16618, 16657, 16671, 16675, 16681, 16731,
16794, 16817, 16984
V6C: Sample Data 11895, 12197, 15200
V6D: MSCs 10860, 12345, 12922, 14721, 14747, 14934, 15007, 15021,
15147, 15223, 15305, 15401, 15579, 15583, 15630, 15691,
15999, 16817, 16984, 17046
V6E: Low Energy Link Layer 12068, 16039, 16093, 16681
V6F: Direct Test Mode
V6G: Isochronous Adaptation Layer 12797, 13082, 13083, 13085, 13086, 13251, 13316, 13533,
14665, 14771, 14897, 14901, 15304, 15658, 15672, 15851,
15963, 16278, 16817
V7A: MWS Coexistence Logical Sig-
naling
V7B: Wireless Coexistence Interface 11987, 11988
1 (WCI-1) Transport Specification
V7C: Wireless Coexistence Interface
2 (WCI-2) Transport Specification

Table 12.1: Errata integrated in v5.3

12.4 Global terminology changes

Certain terms that were identified as inappropriate have been replaced. As a
consequence, some other terms have also been changed to retain consistency and
some HCI command and event names had consequential changes. For a list of the
original terms and names and their replacements, see the Appropriate Language
Mapping Tables, https://www.bluetooth.com/language-mapping/Appropriate-Language-
Mapping-Table.

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 1, Part C Page 384
Core Specification Change History

These terminology changes were made under the following issues: 15328, 15334,
15336, 15338, 15342, 15343, 15344, 15345, 15346, 15347, 15348, 15349, 15350,
15351, 15352, 15353, 15354, 15355, 15356, 15357, 15358, 15359, 15360, 15361,
15362, 15363, 15389, 15529, 15531.

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 1, Part C Page 385
Core Specification Change History

13 CHANGES FROM V5.3 TO V5.4

13.1 New features

Several new features are introduced in v5.4. The major areas of improvement are:

• Advertising Coding Selection

• Encrypted Advertising Data
• LE GATT Security Levels Characteristic
• Periodic Advertising with Responses

13.2 Removed features

No features were removed in v5.4.

13.3 Errata incorporated in v5.4

Table 13.1 lists the integrated errata items.

v5.4
Global / Several Parts 17307, 20357, 20589
Front matter 17925
V0A: Consolidated Table of Con-
tents
V0B: Bluetooth Compliance Re- 15534, 20402, 22281
quirements
V0C: Version History and Acknowl- 17026, 17070, 19267, 19268, 19269, 20567, 22267, 22438
edgments
V1A: Architecture Overview 15535, 16097, 16927, 16940, 17231, 17232, 17332, 17366,
17464, 17746, 17755, 18603, 18654, 18765, 19112, 19149,
19206, 20369, 20604, 22220 22281
V1B: Acronyms & Abbreviations 17085, 17232, 17332, 18234, 19032, 19284, 20369
V1C: Change History 17232, 17332, 17993, 18302, 19025
V1D: Mixing of Spec Versions 15535, 17332
V1E: General Terminology 16542, 17028, 17090, 17888, 18234, 19202, 22345, 22439
V1F: Controller Error Codes 17332, 19090, 19198
V2A: Radio 17036, 17249, 20635

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 1, Part C Page 386
Core Specification Change History

v5.4
V2B: Baseband 15536, 15605, 17031, 17083, 17085, 17578, 17708, 17830,
17849, 18344, 19206
V2C: LMP 10969, 17031, 17083, 17532, 17565, 17591, 19206, 20605
V2F: MSCs 10969, 15536, 17039, 17391, 17566, 18068, 18946, 22220
V2G: Sample Data 10969, 17034
V2H: Security 15536, 16988, 17031, 17083, 17084, 17085, 17113, 17226,
17339, 17567, 22220
V3A: L2CAP 10969, 15248, 15537, 16591, 17042, 17043, 17044, 17050,
17051, 17085, 17232, 17319, 17332, 17464, 17468, 17560,
17568, 17580, 17709, 17849, 18303, 18341, 18343, 19054,
19098, 19206, 20635, 22220, 22441
V3B: SDP 10969, 15537, 17050, 17569, 17980
V3C: GAP 10969, 15537, 17044, 17050, 17214, 17332, 17398, 17470,
17571, 17702, 17832, 17946, 18083, 18234, 18303, 18668,
18766, 18819, 18820, 18896, 18905, 18962, 19042, 19093,
19149, 20369, 20374, 20385, 20420, 20452, 20605, 20606,
22185, 22193, 22220, 22222, 22441
V3D:Test Support 17083, 17572, 189051, 19217
V3E: A2MP 16263
V3F: ATT 10969, 16963, 17013, 17232, 17332, 17354, 17358, 17383,
17466, 17573, 17730, 19088, 22220
V3G: GATT 15248, 15537, 16947, 16962, 17232, 17332, 17574, 17698,
19169, 19194, 24889
V3H: Security Manager 10969, 15537, 16988, 17044, 17085, 17113, 17575, 17732,
18014, 18283, 19324, 22220
V4A: UART Transport Layer
V4B: USB Transport Layer 15538, 17064, 17332, 17529
V4C: Secure Digital (SD) Transport 17332
Layer
V4D: Three-wire UART 15538, 17085, 17107

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 1, Part C Page 387
Core Specification Change History

v5.4
V4E: HCI 15538, 16591, 16769, 16775, 16778, 16850, 16908, 16934,
16966, 16998, 17021, 17032, 17055, 17057, 17058, 17061,
17062, 17063, 17065, 17069, 17108, 17125, 17332, 17404,
17407, 17412, 17433, 17451, 17456, 17469, 17510, 17646,
17697, 17702, 17762, 17849, 17947, 18023, 18024, 18047,
18068, 18094, 18194, 18229, 18230, 18280, 18311, 18331,
18378, 18401, 18450, 18453, 18515, 18538, 18567, 18578,
18608, 18615, 18625, 18626, 18640, 18644, 18655, 18661,
18680, 18685, 18686, 18690, 18784, 18785, 18989, 18990,
19007, 19009, 19021, 19026, 19035, 19036, 19038, 19055,
19058, 19062, 19063, 19065, 19066, 19090, 19112, 19127,
19149, 19163, 19185, 19186, 19197, 19198, 19206, 19211,
19215, 19238, 20392, 20424, 20430, 20482, 20487, 22140,
22220, 22240, 22251, 22272, 22281, 22376, 22442
V5A: 802.11 Protocol Adaptation
V6A: Physical Layer 17052, 18446, 18460, 18627, 20635, 20636, 22443
V6B: Link Layer 10969, 16097, 16591, 16878, 17052, 17083, 17085, 17089,
17234, 17332, 17352, 17356, 17361, 17390, 17433, 17489,
17509, 17531, 17583, 17702, 17849, 17971, 17991, 18070,
18100, 18226, 18233, 18234, 18267, 18311, 18456, 18476,
18555, 18566, 18567, 18632, 18648, 18653, 18701, 18742,
18766, 18805, 18833, 18834, 18970, 18989, 18990, 19007,
19026, 19060, 19080, 19087, 19089, 19112, 19132, 19149,
19151, 19200, 19206, 19238, 19266, 20385, 20389, 20401,
20444, 20447, 20472, 20499, 20605, 20624, 22169, 22170,
22219, 22220, 22371, 22443
V6C: Sample Data 17332
V6D: MSCs 10969, 15539, 17039, 17440, 17576, 17616, 18068, 18602,
18701, 20389, 20500, 22220
V6E: Low Energy Link Layer 16988, 17548, 20635, 22178
V6F: Direct Test Mode 17083, 17090, 17231, 17577, 20409
V6G: Isochronous Adaptation Layer 17090, 17462, 18001, 18002, 19149, 20476, 22281
V7A: MWS Coexistence Logical Sig- 22444
naling
V7B: Wireless Coexistence Interface 10969, 19044, 22444
1 (WCI-1) Transport Specification
V7C: Wireless Coexistence Interface 17332, 19044, 22444
2 (WCI-2) Transport Specification

Table 13.1: Errata integrated in v5.4

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 1, Part C Page 388
Core Specification Change History

14 CHANGES FROM V5.4 TO V6.0

14.1 New features

Several new features are introduced in v6.0. The major areas of improvement are:

• Channel Sounding, including Channel Sounding HCI Updates

• LL Extended Feature Set
• Decision-Based Advertising Filtering
• Enhancements for ISOAL
• Monitoring Advertisers
• Frame Space Update

14.2 Removed features

No features were removed in v6.0.

14.3 Errata incorporated in v6.0

Table 14.1 lists the integrated errata items.

v6.0
Global / Several Parts 23618, 25794
V0A: Consolidated Table of
Contents
V0B: Bluetooth Compliance 25429
Requirements
V0C: Revision History and 19321, 24281, 24284, 25264, 25429, 25553, 25794, 25795
Acknowledgments
V0D: Core Configurations 25429
V1A: Architecture Overview 17027, 18534, 22197, 22270, 22397, 22504, 22579, 22875, 22957,
22960, 23262, 23649, 23704, 24040, 24238, 24401, 24433, 24434,
24461, 24541, 24811, 25429, 25605
V1B: Acronyms & Abbrevi- 22504, 23034, 24434, 25605, 25658
ations
V1C: Change History 22489, 25795
V1D: Mixing of Spec Ver- 23635, 25171, 25181, 25429
sions
V1E: General Terminology 16543, 18534, 22270, 23135, 23548, 24044, 24798, 24800

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 1, Part C Page 389
Core Specification Change History

v6.0
V1F: Controller Error Co- 18534, 23446, 24855
des
V2A: Radio 22270, 23548, 23620, 24457, 25101, 25429, 25605
V2B: Baseband 17250, 17736, 22270, 23034, 23054, 23127, 23508, 23549, 23624,
23635, 23983, 25658
V2C: LMP 15466, 18534, 18960, 20613, 22262, 22270, 22504, 22839, 22926,
23064, 23219, 23578, 23579, 23739, 23983, 24042, 24171, 24284,
24402, 24582, 24675, 24786, 25101, 25429, 25658
V2F: MSCs 22488, 22489, 22490, 24617
V2G: Sample Data 24573, 24797, 25429
V2H: Security 17250, 17251, 17710, 20607, 22270, 22839, 23034, 23260, 23627,
23700, 24573, 24617, 25429, 25859
V3A: L2CAP 17049, 17250, 18534, 20607, 22270, 22534, 22535, 22594, 22641,
22693, 23048, 23991, 24217, 25429, 25605
V3B: SDP 16886, 20607, 22138, 22270, 22875, 23630, 23631, 24440
V3C: GAP 17049, 17874, 18082, 18534, 18703, 20657, 22255, 22289, 22492,
22589, 22726, 22783, 23034, 23190, 23303, 23635, 23704, 24057,
24058, 24202, 24312, 24394, 24440, 24461, 24493, 24617, 24620,
24762, 25021, 25429
V3D:Test Support 17250, 18534, 22270, 22504, 25429
V3F: ATT 22396, 22416, 22489, 22538, 22693, 23071, 23634, 24892, 25429,
25605
V3G: GATT 17355, 22270, 22487, 22693, 22894, 23537, 23635, 24126, 24247,
24440, 24473, 24580, 24889, 25021, 25429, 25605, 25658
V3H: Security Manager 17049, 22270, 22482, 23259, 23262, 23700, 24202, 24265, 24617,
25605
V4A: UART
V4B: USB 22270
V4C: SD 16886, 22504, 24607
V4D: Three-wire UART 17250, 22270, 23983

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 1, Part C Page 390
Core Specification Change History

v6.0
V4E: HCI 11058, 16543, 16886, 18552, 18960, 18973, 20515, 20556, 20607,
22167, 22181, 22192, 22262, 22270, 22341, 22342, 22353, 22373,
22385, 22393, 22397, 22447, 22448, 22474, 22494, 22495, 22504,
22539, 22540, 22550, 22561, 22580, 22620, 22658, 22667, 22678,
22691, 22709, 22791, 22844, 22851, 22856, 22857, 22869, 22882,
22906, 22918, 23069, 23070, 23100, 23108, 23129, 23157, 23166,
23180, 23194, 23195, 23202, 23203, 23204, 23217, 23242, 23262,
23310, 23394, 23397, 23408, 23428, 23446, 23486, 23488, 23602,
23610, 23690, 23705, 23740, 23896, 23899, 23914, 23982, 23983,
24009, 24032, 24039, 24082, 24083, 24110, 24111, 24114, 24115,
24121, 24125, 24140, 24200, 24230, 24238, 24285, 24286, 24293,
24298, 24313, 24316, 24397, 24401, 24421, 24443, 24446, 24461,
24467, 24507, 24541, 24607, 24637, 24662, 24688, 24691, 24693,
24719, 24783, 24784, 24787, 24793, 24811, 24834, 24848, 24855,
24870, 24876, 24880, 24903, 24916, 24921, 24932, 24989, 25021,
25041, 25046, 25047, 25107, 25124, 25125, 25171, 25178, 25181,
25183, 25220, 25221, 25263, 25283, 25328, 25381, 25382, 25384,
25395, 25407, 25409, 25429, 25457, 25460, 25461, 25474, 25478,
25481, 25493, 25543, 25545, 25583, 25605, 25610, 25658, 25795
V6A: Physical Layer 22270, 22332, 22552, 23034, 23704, 24018, 24401, 24461, 24541,
24607, 24871, 24976, 25060, 25106, 25132, 25429, 25605, 25669,
25846, 25859
V6B: Link Layer 16543, 17250, 17438, 17874, 18534, 18703, 18973, 20451, 20485,
20515, 20658, 22167, 22181, 22197, 22270, 22311, 22332, 22479,
22496, 22530, 22540, 22553, 22554, 22555, 22556, 22565, 22591,
22648, 22649, 22677, 22700, 22835, 22895, 22973, 23034, 23050,
23069, 23192, 23194, 23295, 23398, 23402, 23434, 23446, 23510,
23530, 23616, 23635, 23704, 23741, 23983, 24032, 24112, 24134,
24195, 24202, 24238, 24286, 24370, 24371, 24372, 24373, 24374,
24401, 24420, 24431, 24436, 24437, 24444, 24445, 24461, 24475,
24476, 24477, 24541, 24573, 24576, 24590, 24646, 24652, 24688,
24719, 24811, 24833, 24875, 24883, 24888, 24917, 25052, 25084,
25127, 25151, 25171, 25181, 25220, 25234, 25263, 25293, 25297,
25368, 25383, 25398, 25512, 25513, 25605, 25658, 25795
V6C: Sample Data 18534, 22928, 23220, 23617, 23619, 23704, 24112, 24284, 24297,
24308, 24378, 24866, 25127, 25165, 25173
V6D: MSCs 24787, 25128, 25605
V6E: LE Link Layer Securi- 22270, 22584, 23398, 23704, 24377, 24383, 24385
ty
V6F: Direct Test Mode 17250, 18534, 22270, 22504, 24401, 24442, 24607, 24647, 24763,
24787, 24823, 24833, 24935, 25429, 25434, 25557
V6G: Isochronous Adapta- 20485, 20607, 22270, 22876, 23724, 23726, 24011, 24127, 24185,
tion Layer 24286, 24653, 24690, 24856

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 1, Part C Page 391
Core Specification Change History

v6.0
V6H: Channel Sounding 22270, 23154, 23155, 23414, 23423, 23464, 23518, 23704, 24018,
24064, 24152, 24296, 24320, 24401, 24434, 24541, 24575, 24607,
24638, 24647, 24795, 24796, 24811, 24916, 25058, 25060, 25072,
25126, 25172, 25293, 25296, 25425, 25542, 25605, 25658, 25674
V7A: MWS Coexistence 18534, 22652
Logical Signaling
V7B: WCI-1 22270
V7C: WCI-2 22270

Table 14.1: Errata integrated in v6.0

Bluetooth SIG Proprietary Version Date: 2024-08-27

 Architecture, Change History,
And Conventions
Part D

[THIS PART IS NO LONGER

USED]

Mixing requirements are located in [Vol 0] Part D.

Bluetooth SIG Proprietary

 Architecture, Change History,
And Conventions
Part E

GENERAL TERMINOLOGY
AND INTERPRETATION

Bluetooth SIG Proprietary

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 1, Part E Page 394
General Terminology and Interpretation

CONTENTS

1 Language conventions ............................................................................. 395

1.1 [This section is no longer used] ................................................... 395
1.2 [This section is no longer used] ................................................... 395
1.3 [This section is no longer used] ................................................... 395
1.4 [This section is no longer used] ................................................... 395
1.5 [This section is no longer used] ................................................... 395
1.6 [This section is no longer used] ................................................... 395
1.7 Implementation Alternatives ........................................................ 395
1.8 Discrepancies .............................................................................. 396
1.9 Appropriate Language ................................................................. 396

2 General interpretation rules ..................................................................... 397

2.1 Binary and hexadecimal values .................................................. 397
2.2 Bit numbers and bit fields ............................................................ 397
2.3 Specification of bit values ............................................................ 397
2.4 Values with restricted purposes ................................................... 398
2.4.1 Reserved for future use ............................................... 398
2.4.2 Previously used ........................................................... 398
2.4.3 Reserved for specification development purposes ...... 399
2.5 Use of invalid values in checksums and other calculations ........ 399
2.6 Assigned number requirements .................................................. 399
2.7 Responding to invalid behavior ................................................... 399
2.8 Ranges of values ........................................................................ 401
2.9 Type Names ................................................................................ 401
2.9.1 Basic types .................................................................. 402
2.9.2 Array types ................................................................... 402
2.9.3 Variable length types ................................................... 403
2.10 Mathematical conventions ........................................................... 403
2.11 Requirement status symbols ....................................................... 405
2.12 Table structure ............................................................................. 405
2.13 References to HCI commands and events ................................. 406

3 Naming conventions ................................................................................. 407

3.1 BR/EDR ....................................................................................... 407
3.2 Bluetooth Low Energy ................................................................. 407
3.2.1 Link Layer PDUs .......................................................... 407

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 1, Part E Page 395
General Terminology and Interpretation

1 LANGUAGE CONVENTIONS

In the development of a specification, the Bluetooth SIG has established the following
conventions for use of the terms “shall”, “shall not”, “should”, “should not”, “may”, “must”,
and “can”. In this Bluetooth specification, the terms in Table 1.1 have the specific
meanings given in that table, irrespective of other meanings that exist.

shall —used to express what is required by the specification and is to be implemented

exactly as written without deviation
shall not —used to express what is forbidden by the specification
should —used to express what is recommended by the specification without forbidding any-
thing
should not —used to indicate that something is discouraged but not forbidden by the specification
may —used to indicate something that is permissible within the limits of the specification
must —used to indicate either:
1. an indisputable statement of fact that is always true regardless of the circumstances
2. an implication or natural consequence if a separately-stated requirement is followed
can —used to express a statement of possibility or capability

Table 1.1: Language conventions terms and definitions

1.1 [This section is no longer used]

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 [This section is no longer used]

1.6 [This section is no longer used]

1.7 Implementation Alternatives

When specification content indicates that there are multiple alternatives to satisfy
specification requirements, if one alternative is explained or illustrated in an example
it is not intended to limit other alternatives that the specification requirements permit.

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 1, Part E Page 396
General Terminology and Interpretation

1.8 Discrepancies
It is the goal of Bluetooth SIG that specifications are clear, unambiguous, and do not
contain discrepancies. However, members can report any perceived discrepancy by
filing an erratum and can request a test case waiver as appropriate.

1.9 Appropriate Language

Certain terms that were identified as inappropriate have been replaced. As a
consequence, some other terms have also been changed to retain consistency and
some HCI command and event names had consequential changes. For a list of the
original terms and names and their replacements, see the Appropriate Language
Mapping Tables, https://www.bluetooth.com/language-mapping/Appropriate-Language-
Mapping-Table.

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 1, Part E Page 397
General Terminology and Interpretation

2 GENERAL INTERPRETATION RULES

The following rules apply throughout the specification except where explicitly
overridden.

2.1 Binary and hexadecimal values

Binary numbers are normally written with a “0b” prefix, so 0b1101 is the same as the
decimal number 13.

In some places a sequence of bits is written in quotation marks thus: '1010'. Such
sequences are not normally intended to be interpreted as numbers. The order that the
bits are to be processed will always be specified.

Hexadecimal numbers are written with a "0x" prefix, so 0x42 is the same as the decimal
number 66. The letters "a" to "f" are used to represent the digits 10 to 15, so 0x1A is
the same as the decimal number 26. The case of letters in a hexadecimal number is not
significant.

Underscore characters may be placed between the digits of binary or hexadecimal

numbers to make them easier to interpret; these underscores shall not affect the value.
For example, 0b0010_1011 and 0b00101011 both equal the decimal number 43.

All numbers not written in one of the above ways are decimal.

2.2 Bit numbers and bit fields

In some cases the specification needs to refer to some of the bits of an integer value.
Bits are always numbered from 0 as the least significant bit, so bit 0 of 0b1011 equals 1
while bit 2 equals 0. A single bit will be notated with a subscript, as in CLK5.

Sometimes it is necessary to refer to a consecutive set of bits; for example, given a

value CLK it may be necessary to refer to bits 2 to 4 of CLK (that is, the value equal to
(CLK ÷ 4) mod 8. This will be notated either by a subscript with a dash or by brackets
and a colon; the bit numbers will always be inclusive and the most significant bit number
is given first. For example, bits 2 to 4 of CLK are written CLK4-2 or CLK[4:2].

2.3 Specification of bit values

Some values in the specification are divided into individual bits, each of which has
a description. If explicit bit values are not given then this description represents the

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 1, Part E Page 398
General Terminology and Interpretation

meaning when the bit equals 1 and the opposite applies when the value is 0. For
example, a description of:

Bit 3: use 3-slot packets

means the same as:

Bit 3 = 1: use 3-slot packets;

Bit 3 = 0: do not use 3-slot packets.

2.4 Values with restricted purposes

Where a field in a packet, PDU, or other data structure, a parameter, or another variable
object is described as being split into components (e.g., when each bit of a field has a
separate meaning), the rules in this section apply to each component separately.

2.4.1 Reserved for future use

Where a field in a packet, PDU, or other data structure is described as "Reserved for
future use" (irrespective of whether in upper or lower case), the device creating an
instance of the structure to send to another device (including messages sent between a
Host and a Controller over HCI) shall set it to zero. Any device receiving or interpreting
the structure shall ignore that field; in particular, it shall not reject the structure because
of the value of the field.

Where a field, parameter, or other variable object can take a range of values and some
values are described as "Reserved for future use", devices shall not set the object to
any of those values. A device receiving an object with such a value should reject it, and
any data structure containing it, as being erroneous; however, this does not apply in
a context where the object is described as being ignored or if it is specified to ignore
unrecognized values.

Where a field, parameter, or other variable object only has meanings specified for some
values, all other values are reserved for future use.

The abbreviation "RFU" is equivalent to "Reserved for future use".

2.4.2 Previously used

The term "Previously used" (irrespective of whether in upper or lower case) indicates
that a field or value was used for a removed feature (see [Vol 1] Part C, Section 1).
Devices that do not implement that feature shall treat the field or value as reserved for
future use.

Note: These fields and values will not be used for new features.

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 1, Part E Page 399
General Terminology and Interpretation

2.4.3 Reserved for specification development purposes

The term "Reserved for specification development purposes" (irrespective of whether in

upper or lower case) indicates that a value will not appear in published specifications
but may be used during specification development.

Other than during specification development, these values shall be treated as reserved
for future use. Implementations shall not use these values for vendor-specific features
or purposes.

2.5 Use of invalid values in checksums and other calculations

Where a field or value is used as part of a checksum, CRC, cryptographic key, or

other similar calculation, and the value sent to or received from the peer is not valid
(for example, it is an RFU field that has not been set to 0 by the sender), the actual
value sent or received shall be used in the calculation and it shall not be replaced by a
different valid value.

2.6 Assigned number requirements

The Bluetooth SIG maintains a published set of assigned numbers on the Bluetooth SIG
Assigned Numbers web page. These assigned numbers are grouped in various number
spaces. Numbers assigned may overlap with other assigned numbers in different
number spaces, but no number within a number space is ever reused. The various
number spaces are defined in the specification that defines the usage of the assigned
numbers.

All assigned numbers within a given number space shall only be designated by the
Bluetooth SIG and shall only be used for their intended purposes when used within a
field, parameter, or other variable object defined to take on a value within that number
space. All values not explicitly assigned within a given number space are Reserved for
future use and subject to the requirements in Section 2.4.

All 16-bit and 32-bit UUIDs as defined in [Vol 3] Part B, Section 2.5.1, are considered
assigned numbers. All other UUID values may be used in any context where a UUID is
permitted provided they are generated according to the recommendations in ITU-T Rec.
X.667(10/2012), alternatively known as ISO/IEC 9834.8:2014.

2.7 Responding to invalid behavior

If a device receives a packet or PDU that it supports but is not permitted in its
current state, or has contents not permitted by the specification, the sending device

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 1, Part E Page 400
General Terminology and Interpretation

has exhibited invalid behavior. Unless the specification states a particular action to be
taken, the receiving device should respond in one of the following ways:

• Ignore the packet or PDU.

• Attempt to recover the situation while both not violating the specification and being
prepared for the sending device to be in a state where one or both devices cannot
recover.
• If the packet or PDU was received from the peer device in a connection, either
immediately terminate that connection or consider the connection to be lost. This
may be done at any appropriate layer; e.g., following invalid behavior on an L2CAP
channel, a device could choose to terminate either the channel or the underlying ACL
connection.

Methods for recovering from invalid behavior include, but are not limited to:

• Sending a rejection response

• If a packet or PDU is too long, ignoring the extra contents
• If a value is out of range, using the nearest permitted value
• If a field is missing, using any default value specified

Examples of packets or PDUs not permitted in the current state include:

• A POLL packet sent by a Peripheral (see [Vol 2] Part B, Section 6.5.1.3)

• An LMP_DETACH PDU received while the device is in Hold or Sniff mode (see [Vol 2]
Part C, Section 4.1.2)
• Any packet sent on the primary advertising physical channel using the LE 2M PHY or
an ADV_IND PDU sent on the LE Coded PHY (see [Vol 6] Part B, Section 2.3)
• Two consecutive LL_FEATURE_REQ PDUs sent by a Central with no
LL_FEATURE_RSP sent by the Peripheral between them (see [Vol 6] Part B,
Section 5.1.4.1)
• A second LL_VERSION_IND PDU sent by the same device during the same
connection (see [Vol 6] Part B, Section 5.1.5)
• A second ATT request or indication before the device has sent a response or
confirmation in reply to the first one

Examples of packets and PDUs with contents not permitted by the specification include:

• A packet or PDU which is required to have a specific length but does not have that
length
• A PDU where the value of a specific parameter or field is out of range (also see
Section 2.4)

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 1, Part E Page 401
General Terminology and Interpretation

• An L2CAP C-frame sent over fixed channel CID 0x0005 that contains more than one
command (see [Vol 3] Part A, Section 4) or has a length longer than that of the
enclosed command packet

Note: The appropriate response to invalid behavior will depend on the specific
circumstances and the choice made can affect the user experience. For example, a
POLL packet sent by a Peripheral could actually be a NULL packet with the TYPE field
corrupted, so it would be reasonable to ignore the POLL packet rather than terminate
the connection. On the other hand, invalid behavior during a security procedure can
indicate an attack by a third party and immediate disconnection may be appropriate.

Note: If the sending device supports different features or a different version of the
specification, invalid behavior can occur because there are different requirements and
one device has not checked for this possibility, such as by checking feature masks.

2.8 Ranges of values

Where a range is given (e.g. "the value is between 1 and 10", "in the range 7 to Nmax",
or "Size: 1-31") then the range always includes both endpoints unless explicitly stated
otherwise.

2.9 Type Names

The names defined in this section are used in the specification to indicate the type and
representation of a value.

Values shall be stored in little-endian order. Except in arrays (see Section 2.9.2), a value
of a given type shall be stored in the smallest number of octets that can contain the
value; the value shall occupy the whole of each octet except the most significant bits
of the last octet. All other bits in the last octet shall be reserved for future use. For
example, if a value has a size of 22 bits, then it occupies 3 octets:

• The 8 least significant bits (value7-0) are stored in the first octet.
• The next 8 bits (value15-8) are stored in the middle octet.
• The 6 most significant bits (value21-16) are stored in the 6 least significant bits of the
last octet.
• The 2 most significant bits of the last octet are reserved for future use.

Where a value appears in an SDP service record (see [Vol 3] Part B, Section 2.2), the
octets representing the value shall be reversed in order to match the big-endian order
used by SDP. The order of elements of an array shall be unchanged.

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 1, Part E Page 402
General Terminology and Interpretation

2.9.1 Basic types

The names uint#, where # is a decimal number other than zero, indicate an unsigned
integer with the specified number of bits; therefore uint16 is an unsigned integer with 16
bits. The value shall be represented in binary, so uint16 has the range of values 0 to
65535.

The names sint#, where # is a decimal number other than 0 or 1, indicate a signed
integer with the specified number of bits including sign; therefore sint12 is a signed
integer with 12 bits. The value shall be represented in two’s-complement binary with the
sign bit as the most significant bit, so sint12 has the range of values -2048 to +2047.

The name boolean indicates a single bit representing a truth value: a 0 bit represents
false and a 1 bit represents true.

The names float#, where # is 16, 32, 64, 128, or 256, indicate a floating point number
using the IEEE 754 interchange format with that number of bits.

The names medfloat16 and medfloat32 indicate the 16 and 32 bit floating point types
defined in ISO/IEEE 11073-20601.

The names UUID16, UUID32, and UUID128 indicate the three lengths of UUID (see
[Vol 3] Part B, Section 2.5.1). The name UUID indicates a UUID whose length is
specified separately to the value.

2.9.2 Array types

Any basic type may be converted to an array type of a specific length. The name of the
array type is formed from the name of the basic type by adding the length, in brackets,
after the name. For example, sint12[3] indicates an array of 3 values, each of type
sint12. Empty brackets indicate that the length of the array is specified elsewhere. The
original type is called the base type of the array.

If the size of the base type is 1 bit, each group of 8 consecutive elements is packed into
an octet starting at the least significant bit for the first value.

If the size of the base type is 2 bits, each group of 4 consecutive elements is packed
into an octet using bits 1-0 for the first value, bits 3-2 for the second value, bits 5-4 for
the third value, and bits 7-6 for the fourth value.

If the size of the base type is 3 bits, each consecutive pair of elements is packed into an
octet using bits 2-0 for the first value and bits 5-3 for the second value; bits 6 and 7 of
each octet are reserved for future use.

If the size of the base type is 4 bits, each consecutive pair of elements is packed into an
octet using bits 3-0 for the first value and bits 7-4 for the second value.

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 1, Part E Page 403
General Terminology and Interpretation

If the number of elements is not a multiple of 8, 4, or 2 as appropriate, the bits of the last
octet that are not occupied by values are reserved for future use.

If the size of the base type is 5 bits or more, each element of the array occupies
separate octets.

For example, the type uint2[5] occupies two octets, with the first value occupying bits
1-0 of the first octet, the fourth value occupying bits 7-6 of the first octet, the last value
occupying bits 1-0 of the second octet, and bits 7-2 of the second octet reserved for
future use. The type sint12[3] occupies six octets in total, two for each element.

2.9.3 Variable length types

The name utf8s indicates a variable length array of octets holding a string encoded
using UTF-8. A specific number of octets may be indicated by appending the number in
braces to the type name, so utf8s{6} indicates an array of 6 octets. If the actual string is
shorter than the size of the array, the first unused octet shall be zero. If the number in
braces is followed by the letter “z”, the remaining octets shall also be zero. For example,
the string “Café” is represented in the type utf8s{8z} by the octet sequence 0x43, 0x61,
0x66, 0xC3, 0xA9, 0x00, 0x00, 0x00. If a specific length is not indicated, the length is
specified separately to the value.

The name utf16s indicates a variable length array of uint16 values holding a string
encoded using UTF-16LE; the length is specified separately to the value.

The name struct indicates a variable length array of octets whose length and internal
format are specified separately to the value.

2.10 Mathematical conventions

These conventions apply to how mathematical symbols are used in this specification,
irrespective of how they are interpreted in any other context.

The operators +, −, ×, and ÷ have their usual meanings. Division is done using real
numbers unless the result is being assigned to or used as an integer, in which case the
quotient is rounded towards zero. The × operator is sometimes omitted if the meaning is
clear. In figures these operators may appear inside square boxes.

The operator mod indicates the remainder from division; x mod y is the remainder when
x is divided by y. It is only used with both operands being integers and y greater than
zero. The division is rounded down so that the remainder is always non-negative; in
other words, x mod y always equals x− x÷y × y.

The notation “(mod m)” at the end of an equation indicates that the equality is tested
after applying the mod operator on each side; in other words, “a = b (mod m)” is

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 1, Part E Page 404
General Terminology and Interpretation

equivalent to “a mod m = b mod m”. The three-way inequality “a ≤ b < c (mod m)”—with
both relational operators in the same direction but each either including or excluding
equality—is equivalent to “0 ≤ (b - a) mod m < (c - a) mod m”.

The operators + and – have equal precedence. The operators ×, ÷, and mod have equal
precedence, which is higher than that of + and −. Exponentiation has higher precedence
than all of these operators. Expressions involving operators of equal precedence are
evaluated from left to right. Precedence can be overridden using parentheses; unless
clear from the context, brackets and braces are equivalent to parentheses and are
used for clarity. Exponents and subscripts are evaluated separately as if they were in
parentheses; for example, x2−y means x raised to the power 2 − y, not the square of x
with y then subtracted.

Signed integers shall be represented as two’s complement.

Where a field, variable, parameter, or similar is specified as an integer with a specific

number of bits B, then any requirement to store a value not representable in B bits
shall be carried out by adding or subtracting 2B until the value is in range. In particular,
adding 1 to an unsigned variable with value 2B − 1 results in setting it to zero.

The relational operators <, >, ≤, ≥, =, and ≠ have lower precedence than all arithmetic
operators. Multiple relational operators are logically combined; e.g., x < y ≥ z means that
x is required to be less than y and that y is required to be at least as great as z.

The bitwise operators NOT, AND, OR, and XOR are applied to each bit of their
operands separately; for the last three, the operands will have the same number of
bits.

The symbols in Table 2.1 have the meanings given in that table.

Symbol Meaning
x the largest integer less than or equal to x
x the smallest integer greater than or equal to x
x the absolute value of x
x the square root of x

min (x, y) the minimum value of x and y; there can be more than two arguments
max (x, y) the maximum value of x and y; there can be more than two arguments
Re (z) the real part of the complex number z
Im (z) the imaginary part of the complex number z
exp (x) e (the number 2.71828...) raised to the power of x
x±y any value v such that x − y ≤ v ≤ x + y; the precedence is the same as the + operator

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 1, Part E Page 405
General Terminology and Interpretation

Symbol Meaning
logBx logarithm base B of x

x∥y concatenation of bit sequences

x! the factorial of x
⊕ bitwise XOR
⊆ subset of

Table 2.1: Assorted mathematical symbols

2.11 Requirement status symbols

In this document (such as in requirements tables), the following symbols are used:

• “M” for mandatory to support or include.

• “O” for optional to support or include. Where more than one item is optional, they are
independent: each can be supported (or included) or not, irrespective of the choice
made for any other item.
• “C.#” for conditional support or inclusion (# represents any number or number
followed by a letter); the condition will be defined nearby in terms of whether other
items are supported or included.
• “E” for excluded in this context; cannot be supported or included for this purpose, but
the item can still be supported or included if allowed for some other purpose (e.g.,
a feature can be mandatory for one role and excluded for another; a device that
supports both roles must support this feature).
• “X” for reserved for future use; excluded in this context but might change status in a
future version of this document.

2.12 Table structure

A blank cell in a table indicates that there is no useful information that can be placed in
this cell. Examples of this are:

• When there is no comment to make in a "comments" column

• In a column specifying properties when the relevant item is reserved for future use
(and therefore does not have any properties)
• In a "units" column when the relevant item is unitless

Where an explicit absence is indicated, the cell will contain "none". Examples of this
are:

• In the "condition" column of the description of a finite state machine where a rule is
unconditional

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 1, Part E Page 406
General Terminology and Interpretation

• In the "action" column of the description of a finite state machine where a rule has no
action
• In a "restrictions" column where there are no applicable restrictions
• In an interface description where there are no parameters of a specific type

2.13 References to HCI commands and events

Outside Volume 4, references to HCI commands and events indicate a possible way
of communicating between the Controller and Host and do not, of themselves, require
HCI to be supported. Instead, vendor-specific communication mechanisms may be used
when HCI is not used.

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 1, Part E Page 407
General Terminology and Interpretation

3 NAMING CONVENTIONS

3.1 BR/EDR
This section is not currently used.

3.2 Bluetooth Low Energy

3.2.1 Link Layer PDUs

A consistent naming scheme is used for Link Layer PDUs to make their purpose and
usage clearer.

The PDU name consists of up to five components. Each component is entirely

uppercase. Those components that are present are separated by a single underscore
(e.g., if only three of the five components are present, there are two underscores, not
four). In order, these components are:

1. Where the PDU is used (optional)

2. When the PDU is used (mandatory)
3. What the PDU does (optional but usually present)
4. Version (optional)
5. How the PDU is used (mandatory)

The first component ("where") indicates which physical channel the PDU is used on.
The values currently used are shown in Table 3.1.

Value Meaning
none PDU is used on the primary advertising physical channel or any non-advertising
physical channel
AUX PDU is used on the secondary advertising physical channel

Table 3.1: First component (“where”) values

The second component ("when") indicates which kind of Link Layer procedure makes
use of the PDU. The values currently used are shown in Table 3.2.

Value Meaning
ADV Normal Advertising
SYNC Periodic Advertising
SCAN Scanning

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 1, Part E Page 408
General Terminology and Interpretation

Value Meaning
CONNECT Connecting
CHAIN Fragmented Data
LL Control PDU on the Data logical transport
BIG Control PDU in a Broadcast Isochronous Group on the isochronous logical trans-
port
DATA Reliable Data Note 1
CIS Isochronous data PDU in a Connected Isochronous Stream
BIS Isochronous data PDU in a Broadcast Isochronous Stream

Table 3.2: Second component (“when”) values

Note 1This name is not currently used in the specification.

The third component ("what") distinguishes different PDUs that are found in the same
context. While it is normally present, it is sometimes omitted where there is a "default"
or "usual" case. This component may contain more than one word separated by
underlines.

For example, the different cases for legacy advertising are shown in Table 3.3.

Value Meaning
none Various
DIRECT Connectable directed
NONCONN Non-connectable and non-scannable undirected
SCAN Scannable undirected

Table 3.3: Third component (“what”) values for legacy advertising

As another example, each Link Layer PDU has a value for this component based on the
specific procedure it is used for.

The fourth component ("version") distinguishes between PDUs with the same purpose
but different contents (usually because the original PDU was found to be insufficient to
handle new features). The values currently used are shown in Table 3.4.

Value Meaning
none Original version of the PDU
EXT Extended version of the PDU

Table 3.4: Fourth component (“version”) values

The fifth and final component ("how") indicates how the PDU fits into a procedure. The
values currently used are shown in Table 3.5.

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 1, Part E Page 409
General Terminology and Interpretation

Value Meaning
IND An indication that doesn’t expect a reply
REQ A request that expects a response
RSP A response to a request

Table 3.5: Fifth component (“how”) values

Some examples of this convention in use, showing how the PDU name breaks up into
the five components, are given in Table 3.6. A blank cell indicates that the component is
omitted.

Components
PDU name
where when what version how
ADV_IND ADV IND
ADV_DIRECT_IND ADV DIRECT IND
ADV_EXT_IND ADV EXT IND
AUX_ADV_IND AUX ADV IND
AUX_CHAIN_IND AUX CHAIN IND
SCAN_REQ SCAN REQ
AUX_SYNC_IND AUX SYNC IND
LL_PHY_UPDATE_IND LL PHY_UPDATE IND
LL_LENGTH_REQ LL LENGTH REQ
LL_LENGTH_RSP LL LENGTH RSP
LL_REJECT_IND LL REJECT IND
LL_REJECT_EXT_IND LL REJECT EXT IND
BIG_CHANNEL_MAP_IND BIG CHANNEL_MAP IND

Table 3.6: Examples

Thus AUX_SYNC_IND is a PDU used for synchronous advertising on the secondary

advertising physical channel that does not expect a response.

Bluetooth SIG Proprietary Version Date: 2024-08-27

 Architecture, Change History,
And Conventions
Part F

CONTROLLER ERROR
CODES

Bluetooth SIG Proprietary

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 1, Part F Page 411
Controller Error Codes

CONTENTS

1 Overview of error codes ........................................................................... 413

1.1 Usage descriptions ...................................................................... 413
1.2 [This section is no longer used] ................................................... 413
1.3 List of error codes ....................................................................... 413

2 Error code descriptions ........................................................................... 416

2.1 Unknown HCI command (0x01) .................................................. 416
2.2 Unknown Connection Identifier (0x02) ........................................ 416
2.3 Hardware Failure (0x03) ............................................................. 416
2.4 Page Timeout (0x04) ................................................................... 416
2.5 Authentication Failure (0x05) ...................................................... 416
2.6 PIN or Key Missing (0x06) ........................................................... 416
2.7 Memory Capacity Exceeded (0x07) ............................................ 416
2.8 Connection Timeout (0x08) ......................................................... 417
2.9 Connection Limit Exceeded (0x09) ............................................. 417
2.10 Synchronous Connection Limit to a Device Exceeded (0x0A) .... 417
2.11 Connection Already Exists (0x0B) ............................................... 417
2.12 Command Disallowed (0x0C) ..................................................... 417
2.13 Connection Rejected due to Limited Resources (0x0D) ............. 417
2.14 Connection Rejected due to Security Reasons (0x0E) ............... 417
2.15 Connection Rejected due to Unacceptable BD_ADDR (0x0F) ... 418
2.16 Connection Accept Timeout Exceeded (0x10) ............................ 418
2.17 Unsupported Feature or Parameter Value (0x11) ....................... 418
2.18 Invalid HCI Command Parameters (0x12) .................................. 418
2.19 Remote User Terminated Connection (0x13) .............................. 418
2.20 Remote Device Terminated Connection due to Low
Resources (0x14) ........................................................................ 419
2.21 Remote Device Terminated Connection due to Power Off
(0x15) .......................................................................................... 419
2.22 Connection Terminated by Local Host (0x16) ............................. 419
2.23 Repeated Attempts (0x17) .......................................................... 419
2.24 Pairing not Allowed (0x18) .......................................................... 419
2.25 Unknown LMP PDU (0x19) ......................................................... 419
2.26 Unsupported Remote Feature (0x1A) ......................................... 419
2.27 SCO Offset Rejected (0x1B) ....................................................... 419
2.28 SCO Interval Rejected (0x1C) ..................................................... 420
2.29 SCO Air Mode Rejected (0x1D) .................................................. 420
2.30 Invalid LMP Parameters / Invalid LL Parameters (0x1E) ............ 420
2.31 Unspecified Error (0x1F) ............................................................. 420

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 1, Part F Page 412
Controller Error Codes

2.32 Unsupported LMP Parameter Value / Unsupported LL

Parameter Value (0x20) .............................................................. 420
2.33 Role Change not Allowed (0x21) ................................................ 420
2.34 LMP Response Timeout / LL Response Timeout (0x22) ............. 421
2.35 LMP Error Transaction Collision / LL Procedure Collision (0x23) 421
2.36 LMP PDU not Allowed (0x24) ..................................................... 421
2.37 Encryption Mode not Acceptable (0x25) ..................................... 421
2.38 Link Key cannot be Changed (0x26) ........................................... 421
2.39 Requested QoS not Supported (0x27) ........................................ 421
2.40 Instant Passed (0x28) ................................................................. 421
2.41 Pairing with Unit Key not Supported (0x29) ................................ 421
2.42 Different Transaction Collision (0x2A) ......................................... 422
2.43 QoS Unacceptable Parameter (0x2C) ........................................ 422
2.44 QoS Rejected (0x2D) .................................................................. 422
2.45 Channel Assessment Not Supported (0x2E) .............................. 422
2.46 Insufficient Security (0x2F) .......................................................... 422
2.47 Parameter Out of Mandatory Range (0x30) ................................ 422
2.48 Role Switch Pending (0x32) ........................................................ 422
2.49 Reserved Slot Violation (0x34) .................................................... 422
2.50 Role Switch Failed (0x35) ........................................................... 423
2.51 Extended Inquiry Response too Large (0x36) ............................. 423
2.52 Secure Simple Pairing not Supported by Host (0x37) ................. 423
2.53 Host Busy–Pairing (0x38) ........................................................... 423
2.54 Connection Rejected due to no Suitable Channel Found (0x39) 423
2.55 Controller Busy (0x3A) ................................................................ 423
2.56 Unacceptable Connection Parameters (0x3B) ............................ 423
2.57 Advertising Timeout (0x3C) ......................................................... 424
2.58 Connection Terminated due to MIC Failure (0x3D) ..................... 424
2.59 Connection Failed to be Established / Synchronization
Timeout (0x3E) ............................................................................ 424
2.60 [This section is no longer used] ................................................... 424
2.61 Coarse Clock Adjustment Rejected but Will Try to Adjust
Using Clock Dragging (0x40) ...................................................... 424
2.62 Type0 Submap not Defined (0x41) ............................................. 424
2.63 Unknown Advertising Identifier (0x42) ........................................ 424
2.64 Limit Reached (0x43) .................................................................. 425
2.65 Operation Cancelled by Host (0x44) ........................................... 425
2.66 Packet Too Long (0x45) .............................................................. 425
2.67 Too Late (0x46) ........................................................................... 425
2.68 Too Early (0x47) .......................................................................... 425
2.69 Insufficient Channels (0x48) ........................................................ 425

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 1, Part F Page 413
Controller Error Codes

1 OVERVIEW OF ERROR CODES

This document lists the various possible error codes. When a command fails, or an LMP
or LL message needs to indicate a failure, error codes are used to indicate the reason
for the error. Error codes have a size of one octet.

1.1 Usage descriptions

The purpose of this section is to give descriptions of how the error codes should
be used. It is beyond the scope of this document to give detailed descriptions of
all situations where error codes can be used, especially as this is implementation
dependent.

1.2 [This section is no longer used]

1.3 List of error codes

The error code of 0x00 means Success. The possible range of failure error codes is
0x01 to 0xFF. Section 2 provides an error code usage description for each failure error
code.

Values marked as “Reserved for future use” or not listed in Table 1.1 can be used in
future versions of the specification. A Host shall consider any error code that it does not
explicitly understand equivalent to the error code Unspecified Error (0x1F).

Error Code Name

0x00 Success
0x01 Unknown HCI Command
0x02 Unknown Connection Identifier
0x03 Hardware Failure
0x04 Page Timeout
0x05 Authentication Failure
0x06 PIN or Key Missing
0x07 Memory Capacity Exceeded
0x08 Connection Timeout
0x09 Connection Limit Exceeded
0x0A Synchronous Connection Limit To A Device Exceeded
0x0B Connection Already Exists
0x0C Command Disallowed

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 1, Part F Page 414
Controller Error Codes

Error Code Name

0x0D Connection Rejected due to Limited Resources
0x0E Connection Rejected Due To Security Reasons
0x0F Connection Rejected due to Unacceptable BD_ADDR
0x10 Connection Accept Timeout Exceeded
0x11 Unsupported Feature or Parameter Value
0x12 Invalid HCI Command Parameters
0x13 Remote User Terminated Connection
0x14 Remote Device Terminated Connection due to Low Resources
0x15 Remote Device Terminated Connection due to Power Off
0x16 Connection Terminated By Local Host
0x17 Repeated Attempts
0x18 Pairing Not Allowed
0x19 Unknown LMP PDU
0x1A Unsupported Remote Feature
0x1B SCO Offset Rejected
0x1C SCO Interval Rejected
0x1D SCO Air Mode Rejected
0x1E Invalid LMP Parameters / Invalid LL Parameters
0x1F Unspecified Error
0x20 Unsupported LMP Parameter Value / Unsupported LL Parameter Value
0x21 Role Change Not Allowed
0x22 LMP Response Timeout / LL Response Timeout
0x23 LMP Error Transaction Collision / LL Procedure Collision
0x24 LMP PDU Not Allowed
0x25 Encryption Mode Not Acceptable
0x26 Link Key cannot be Changed
0x27 Requested QoS Not Supported
0x28 Instant Passed
0x29 Pairing With Unit Key Not Supported
0x2A Different Transaction Collision
0x2B Reserved for future use
0x2C QoS Unacceptable Parameter
0x2D QoS Rejected

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 1, Part F Page 415
Controller Error Codes

Error Code Name

0x2E Channel Classification Not Supported
0x2F Insufficient Security
0x30 Parameter Out Of Mandatory Range
0x31 Reserved for future use
0x32 Role Switch Pending
0x33 Reserved for future use
0x34 Reserved Slot Violation
0x35 Role Switch Failed
0x36 Extended Inquiry Response Too Large
0x37 Secure Simple Pairing Not Supported By Host
0x38 Host Busy - Pairing
0x39 Connection Rejected due to No Suitable Channel Found
0x3A Controller Busy
0x3B Unacceptable Connection Parameters
0x3C Advertising Timeout
0x3D Connection Terminated due to MIC Failure
0x3E Connection Failed to be Established / Synchronization Timeout
0x3F Previously used
0x40 Coarse Clock Adjustment Rejected but Will Try to Adjust Using Clock Dragging
0x41 Type0 Submap Not Defined
0x42 Unknown Advertising Identifier
0x43 Limit Reached
0x44 Operation Cancelled by Host
0x45 Packet Too Long
0x46 Too Late
0x47 Too Early
0x48 Insufficient Channels

Table 1.1: List of possible error codes

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 1, Part F Page 416
Controller Error Codes

2 ERROR CODE DESCRIPTIONS

2.1 Unknown HCI command (0x01)

The Unknown HCI Command error code indicates that the Controller does not
understand the HCI Command packet opcode that the Host sent. The opcode given
might not correspond to any of the opcodes specified in this document, or any vendor-
specific opcodes, or the command may have not been implemented.

2.2 Unknown Connection Identifier (0x02)

The Unknown Connection Identifier error code indicates that a command was sent from
the Host that should identify a connection, but that connection does not exist or does
not identify the correct type of connection.

2.3 Hardware Failure (0x03)

The Hardware Failure error code indicates to the Host that something in the Controller
has failed in a manner that cannot be described with any other error code. The meaning
implied with this error code is implementation dependent.

2.4 Page Timeout (0x04)

The Page Timeout error code indicates that a page timed out because of the
Page Timeout configuration parameter. This error code shall only be used with
the HCI_Remote_Name_Request and HCI_Create_Connection commands or with
equivalent mechanisms when HCI is not supported.

2.5 Authentication Failure (0x05)

The Authentication Failure error code indicates that pairing or authentication failed due
to incorrect results in the pairing or authentication procedure. This could be due to an
incorrect PIN or Link Key.

2.6 PIN or Key Missing (0x06)

The PIN or Key Missing error code is used when pairing failed because of a missing
PIN, or authentication failed because of a missing Key.

2.7 Memory Capacity Exceeded (0x07)

The Memory Capacity Exceeded error code indicates to the Host that the Controller has
run out of memory to store new parameters.

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 1, Part F Page 417
Controller Error Codes

2.8 Connection Timeout (0x08)

The Connection Timeout error code indicates that either the link supervision timeout
has expired for a given connection or that the synchronization timeout has expired for a
given broadcast.

2.9 Connection Limit Exceeded (0x09)

The Connection Limit Exceeded error code indicates that an attempt to create another
connection failed because the Controller is already at its limit of the number of
connections it can support. The number of connections a device can support is
implementation dependent.

2.10 Synchronous Connection Limit to a Device Exceeded (0x0A)

The Synchronous Connection Limit to a Device Exceeded error code indicates that the
Controller has reached the limit to the number of synchronous connections that can be
achieved to a device. The number of synchronous connections a device can support is
implementation dependent.

2.11 Connection Already Exists (0x0B)

The Connection Already Exists error code indicates that an attempt was made to create
a new Connection to a device when there is already a connection to this device and
multiple connections to the same device are not permitted.

2.12 Command Disallowed (0x0C)

The Command Disallowed error code indicates that the command requested cannot be
executed because the Controller is in a state where it cannot process this command
at this time. This error shall not be used for command opcodes where the error code
Unknown HCI Command (0x01) is valid.

2.13 Connection Rejected due to Limited Resources (0x0D)

The Connection Rejected Due To Limited Resources error code indicates that a
connection was rejected due to limited resources.

2.14 Connection Rejected due to Security Reasons (0x0E)

The Connection Rejected Due To Security Reasons error code indicates that
a connection was rejected due to security requirements not being fulfilled, like
authentication or pairing.

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 1, Part F Page 418
Controller Error Codes

2.15 Connection Rejected due to Unacceptable BD_ADDR (0x0F)

The Connection Rejected due to Unacceptable BD_ADDR error code indicates that a
connection was rejected because this device does not accept the BD_ADDR. This may
be because the device will only accept connections from specific BD_ADDRs.

2.16 Connection Accept Timeout Exceeded (0x10)

The Connection Accept Timeout Exceeded error code indicates that the Connection
Accept Timeout has been exceeded for this connection attempt.

2.17 Unsupported Feature or Parameter Value (0x11)

The Unsupported Feature Or Parameter Value error code indicates that a feature or
parameter value in the HCI command is not supported. This error code shall not be
used in an LMP PDU.

2.18 Invalid HCI Command Parameters (0x12)

The Invalid HCI Command Parameters error code indicates that at least one of the HCI
command parameters is invalid.

This shall be used when:

• the parameter total length is invalid.

• a command parameter is an invalid type.
• a connection identifier does not match the corresponding event.
• a parameter is odd when it is required to be even.
• a parameter is outside of the specified range.
• two or more parameter values have inconsistent values.

Note: An invalid type can be, for example, when a SCO Connection_Handle is used
where an ACL Connection_Handle is required.

2.19 Remote User Terminated Connection (0x13)

The Remote User Terminated Connection error code indicates that the user on the
remote device either terminated the connection or stopped broadcasting packets.

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 1, Part F Page 419
Controller Error Codes

2.20 Remote Device Terminated Connection due to Low Resources

(0x14)

The Remote Device Terminated Connection due to Low Resources error code indicates
that the remote device terminated the connection because of low resources.

2.21 Remote Device Terminated Connection due to Power Off (0x15)

The Remote Device Terminated Connection due to Power Off error code indicates that
the remote device terminated the connection because the device is about to power off.

2.22 Connection Terminated by Local Host (0x16)

The Connection Terminated By Local Host error code indicates that either the local
device terminated the connection, terminated synchronization with a broadcaster, or
terminated broadcasting packets.

2.23 Repeated Attempts (0x17)

The Repeated Attempts error code indicates that the Controller is disallowing an
authentication or pairing procedure because too little time has elapsed since the last
authentication or pairing attempt failed.

2.24 Pairing not Allowed (0x18)

The Pairing Not Allowed error code indicates that the device does not allow pairing. For
example, when a device only allows pairing during a certain time window after some
user input allows pairing.

2.25 Unknown LMP PDU (0x19)

The Unknown LMP PDU error code indicates that the Controller has received an
unknown LMP opcode.

2.26 Unsupported Remote Feature (0x1A)

The Unsupported Remote Feature error code indicates that the remote device does
not support the feature associated with the issued command, LMP PDU, or Link Layer
Control PDU.

2.27 SCO Offset Rejected (0x1B)

The SCO Offset Rejected error code indicates that the offset requested in the
LMP_SCO_LINK_REQ PDU has been rejected.

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 1, Part F Page 420
Controller Error Codes

2.28 SCO Interval Rejected (0x1C)

The SCO Interval Rejected error code indicates that the interval requested in the
LMP_SCO_LINK_REQ PDU has been rejected.

2.29 SCO Air Mode Rejected (0x1D)

The SCO Air Mode Rejected error code indicates that the air mode requested in the
LMP_SCO_LINK_REQ PDU has been rejected.

2.30 Invalid LMP Parameters / Invalid LL Parameters (0x1E)

The Invalid LMP Parameters / Invalid LL Parameters error code indicates that some
LMP PDU / LL Control PDU parameters were invalid. This shall be used when:

• the PDU length is invalid.

• a parameter is odd when it is required to be even.
• a parameter is outside of the specified range.
• two or more parameters have inconsistent values.

2.31 Unspecified Error (0x1F)

The Unspecified Error error code indicates that no other error code specified is
appropriate to use.

2.32 Unsupported LMP Parameter Value / Unsupported LL Parameter

Value (0x20)

The Unsupported LMP Parameter Value / Unsupported LL Parameter Value error code
indicates that an LMP PDU or an LL Control PDU contains at least one parameter value
that is not supported by the Controller at this time. This is normally used after a long
negotiation procedure, for example during an LMP_HOLD_REQ, LMP_SNIFF_REQ
and LMP_ENCRYPTION_KEY_SIZE_REQ PDU exchanges. This may be used by the
Link Layer, for example during the Connection Parameters Request Link Layer Control
procedure.

2.33 Role Change not Allowed (0x21)

The Role Change Not Allowed error code indicates that a Controller will not allow a role
change at this time.

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 1, Part F Page 421
Controller Error Codes

2.34 LMP Response Timeout / LL Response Timeout (0x22)

The LMP Response Timeout / LL Response Timeout error code indicates that an LMP
transaction failed to respond within the LMP response timeout or an LL transaction
failed to respond within the LL response timeout.

2.35 LMP Error Transaction Collision / LL Procedure Collision (0x23)

The LMP Error Transaction Collision / LL Procedure Collision error code indicates
that an LMP transaction or LL procedure has collided with the same transaction or
procedure that is already in progress.

2.36 LMP PDU not Allowed (0x24)

The LMP PDU Not Allowed error code indicates that a Controller sent an LMP PDU with
an opcode that was not allowed.

2.37 Encryption Mode not Acceptable (0x25)

The Encryption Mode Not Acceptable error code indicates that the requested encryption
mode is not acceptable at this time.

2.38 Link Key cannot be Changed (0x26)

The Link Key cannot be Changed error code indicates that a link key cannot be
changed because a fixed unit key is being used.

2.39 Requested QoS not Supported (0x27)

The Requested QoS Not Supported error code indicates that the requested Quality of
Service is not supported.

2.40 Instant Passed (0x28)

The Instant Passed error code indicates that an LMP PDU or LL PDU that includes an
instant cannot be performed because the instant when this would have occurred has
passed.

2.41 Pairing with Unit Key not Supported (0x29)

The Pairing With Unit Key Not Supported error code indicates that it was not possible to
pair as a unit key was requested and it is not supported.

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 1, Part F Page 422
Controller Error Codes

2.42 Different Transaction Collision (0x2A)

The Different Transaction Collision error code indicates that an LMP transaction or LL
Procedure was started that collides with an ongoing transaction.

2.43 QoS Unacceptable Parameter (0x2C)

The QoS Unacceptable Parameter error code indicates that the specified quality of
service parameters could not be accepted at this time, but other parameters may be
acceptable.

2.44 QoS Rejected (0x2D)

The QoS Rejected error code indicates that the specified quality of service parameters
cannot be accepted and QoS negotiation should be terminated.

2.45 Channel Assessment Not Supported (0x2E)

The Channel Assessment Not Supported error code indicates that the Controller cannot
perform channel assessment because it is not supported.

2.46 Insufficient Security (0x2F)

The Insufficient Security error code indicates that the HCI command or LMP PDU sent
is only possible on an encrypted link.

2.47 Parameter Out of Mandatory Range (0x30)

The Parameter Out Of Mandatory Range error code indicates that a parameter value
requested is outside the mandatory range of parameters for the given HCI command or
LMP PDU and the recipient does not accept that value.

2.48 Role Switch Pending (0x32)

The Role Switch Pending error code indicates that a Role Switch is pending. This
can be used when an HCI command or LMP PDU cannot be accepted because of a
pending role switch. This can also be used to notify a peer device about a pending role
switch.

2.49 Reserved Slot Violation (0x34)

The Reserved Slot Violation error code indicates that the current Synchronous
negotiation was terminated with the negotiation state set to Reserved Slot Violation.

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 1, Part F Page 423
Controller Error Codes

2.50 Role Switch Failed (0x35)

The Role Switch Failed error code indicates that a role switch was attempted but it
failed and the original piconet structure is restored. The switch may have failed because
the TDD switch or piconet switch failed.

2.51 Extended Inquiry Response too Large (0x36)

The Extended Inquiry Response Too Large error code indicates that the extended
inquiry response, with the requested requirements for FEC, is too large to fit in any of
the packet types supported by the Controller.

2.52 Secure Simple Pairing not Supported by Host (0x37)

The Secure Simple Pairing Not Supported by Host error code indicates that the IO
capabilities request or response was rejected because the sending Host does not
support Secure Simple Pairing even though the receiving Link Manager does.

2.53 Host Busy–Pairing (0x38)

The Host Busy - Pairing error code indicates that the Host is busy with another pairing
operation and unable to support the requested pairing. The receiving device should
retry pairing again later.

2.54 Connection Rejected due to no Suitable Channel Found (0x39)

The Connection Rejected due to No Suitable Channel Found error code indicates
that the Controller could not calculate an appropriate value for the Channel selection
operation.

2.55 Controller Busy (0x3A)

The Controller Busy error code indicates that the operation was rejected because the
Controller was busy and unable to process the request.

2.56 Unacceptable Connection Parameters (0x3B)

The Unacceptable Connection Parameters error code indicates that the remote device
either terminated the connection or rejected a request because of one or more
unacceptable connection parameters.

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 1, Part F Page 424
Controller Error Codes

2.57 Advertising Timeout (0x3C)1

The Advertising Timeout error code indicates that advertising for a fixed duration
completed or, for directed advertising, that advertising completed without a connection
being created.

2.58 Connection Terminated due to MIC Failure (0x3D)

The Connection Terminated Due to MIC Failure error code indicates that either the
connection or the synchronization was terminated because the Message Integrity Check
(MIC) failed on a received packet.

2.59 Connection Failed to be Established / Synchronization Timeout

(0x3E)

The Connection Failed to be Established / Synchronization Timeout error code indicates

that the LL initiated a connection or initiated synchronization but the connection has
failed to be established or the Link Layer failed to synchronize within the specified time.

2.60 [This section is no longer used]

2.61 Coarse Clock Adjustment Rejected but Will Try to Adjust Using
Clock Dragging (0x40)

The Coarse Clock Adjustment Rejected but Will Try to Adjust Using Clock Dragging
error code indicates that the Central, at this time, is unable to make a coarse adjustment
to the piconet clock, using the supplied parameters. Instead the Central will attempt to
move the clock using clock dragging.

2.62 Type0 Submap not Defined (0x41)

The Type0 Submap Not Defined error code indicates that the LMP PDU is rejected
because the Type 0 submap is not currently defined.

2.63 Unknown Advertising Identifier (0x42)

The Unknown Advertising Identifier error code indicates that a command was sent from
the Host that should identify an Advertising or Sync handle, but the Advertising or Sync
handle does not exist.

1Formerly called Directed Advertising Timeout

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 1, Part F Page 425
Controller Error Codes

2.64 Limit Reached (0x43)

The Limit Reached error code indicates that number of operations requested has been
reached and has indicated the completion of the activity (e.g., advertising or scanning).

2.65 Operation Cancelled by Host (0x44)

The Operation Cancelled by Host error code indicates a request to the Controller issued
by the Host and still pending was successfully canceled.

2.66 Packet Too Long (0x45)

The Packet Too Long error code indicates that an attempt was made to send or receive
a packet that exceeds the maximum allowed packet length.

2.67 Too Late (0x46)

The Too Late error code indicates that information was provided too late to the
Controller.

2.68 Too Early (0x47)

The Too Early error code indicates that information was provided too early to the
Controller.

2.69 Insufficient Channels (0x48)

The Insufficient Channels error code indicates that the result of the requested operation
would yield too few physical channels.

Bluetooth SIG Proprietary Version Date: 2024-08-27