BR/EDR Controller

Specification of the Bluetooth® System

Volume 2

Covered Core Package Version: v6.0

Version Date: 2024-08-27

Bluetooth SIG Proprietary

 BR/EDR Controller
Part A

RADIO SPECIFICATION

Bluetooth SIG Proprietary

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 2, Part A Page 428
Radio Specification

CONTENTS

1 Scope ......................................................................................................... 430

1.1 Requirements .............................................................................. 430
1.1.1 π/4-DQPSK modulation ............................................... 431
1.1.2 8DPSK modulation ...................................................... 431
1.1.3 3-slot packets ............................................................... 431
1.1.4 5-slot packets ............................................................... 432
1.1.5 Power control ............................................................... 432
1.1.6 Enhanced power control .............................................. 432

2 Frequency bands and channel arrangement ......................................... 433

3 Transmitter characteristics ...................................................................... 434

3.1 Basic Rate ................................................................................... 434
3.1.1 Modulation characteristics ........................................... 434
3.1.2 Spurious emissions ...................................................... 435
3.1.2.1 In-band spurious emission ........................... 435
3.1.3 Radio frequency tolerance ........................................... 436
3.2 Enhanced Data Rate ................................................................... 436
3.2.1 Modulation characteristics ........................................... 436
3.2.1.1 Modulation method overview ....................... 436
3.2.1.2 Differential phase encoding .......................... 437
3.2.1.3 Pulse shaping ............................................... 438
3.2.1.4 Modulation accuracy .................................... 438
3.2.2 Spurious emissions ...................................................... 439
3.2.2.1 In-band spurious emission ........................... 439
3.2.3 Radio frequency tolerance ........................................... 440
3.2.4 Relative transmit power ............................................... 441

4 Receiver characteristics .......................................................................... 442

4.1 Basic Rate ................................................................................... 442
4.1.1 Actual sensitivity level .................................................. 442
4.1.2 Interference performance ............................................ 442
4.1.3 Out-of-band blocking ................................................... 443
4.1.4 Intermodulation characteristics .................................... 443
4.1.5 Maximum usable level ................................................. 444
4.1.6 Received Signal Strength Indication ............................ 444
4.1.7 Reference signal definition .......................................... 444
4.2 Enhanced Data Rate ................................................................... 444
4.2.1 Actual sensitivity level .................................................. 444
4.2.2 BER floor performance ................................................ 444

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 2, Part A Page 429
Radio Specification

4.2.3 Interference performance ............................................ 444

4.2.4 Maximum usable level ................................................. 445
4.2.5 Out-of-band and intermodulation characteristics ......... 445
4.2.6 Reference signal definition .......................................... 446

5 Power management .................................................................................. 447

5.1 Power classes ............................................................................. 447
5.2 Power control .............................................................................. 447
5.3 Enhanced power control ............................................................. 448

Appendix A Test conditions ................................................................................ 449

A.1 Nominal test conditions ............................................................... 449
A.1.1 Nominal temperature ................................................... 449
A.1.2 Nominal power source ................................................. 449
A.2 [This section is no longer used] ................................................... 449

Appendix B [This Appendix is no longer used] ................................................ 450

Appendix C Modulation accuracy definition ..................................................... 451

C.1 Enhanced Data Rate modulation accuracy ................................. 451
C.1.1 RMS DEVM ................................................................. 453
C.1.2 Peak DEVM ................................................................. 453

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 2, Part A Page 430
Radio Specification

1 SCOPE

Bluetooth devices operate in the unlicensed 2.4 GHz ISM (Industrial Scientific Medical)
band. A frequency hop transceiver is applied to combat interference and fading.

Two modulation modes are defined. A mandatory mode, called Basic Rate, uses a
shaped, binary FM modulation to minimize transceiver complexity. An optional mode,
called Enhanced Data Rate, uses PSK modulation and has two variants: π/4-DQPSK
and 8DPSK. The symbol rate for all modulation modes is 1 Msym/s. The gross air data
rate is 1 Mb/s for Basic Rate, 2 Mb/s for Enhanced Data Rate using π/4-DQPSK and 3
Mb/s for Enhanced Data Rate using 8DPSK.

A Time Division Duplex (TDD) scheme is used in both modes. The specification defines
the requirements for a Bluetooth radio for the Basic Rate and Enhanced Data Rate
modes.

Requirements are defined for two reasons:

• Provide compatibility between radios used in the system

• Define the quality of the system

The Bluetooth radio shall fulfil the stated requirements under the operating conditions
specified in Appendix A. The radio parameters shall be measured according to the
methods described in the RF Test Specification.

The Bluetooth SIG maintains regulatory content associated with Bluetooth technology
in the 2.4 GHz ISM band on its web site, at https://www.bluetooth.com/regulatory-
requirements/.

1.1 Requirements
A device supporting RF shall meet the requirements of Section 3 for any packet it is
able to transmit and the requirements of Section 4 for any packet it is able to receive.

The device shall be able to transmit and receive GFSK packets, according to the
requirements in Section 3.1 and Section 4.1, of any length between 68 µs and 426 µs.

The device shall be able to transmit and receive any packet type it supports on all of the
79 channels specified in Section 2.

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 2, Part A Page 431
Radio Specification

RF has the following optional features:

• π/4-DQPSK modulation
• 8DPSK modulation
• 3-slot packets
• 5-slot packets
• Power control
• Enhanced power control
• Power class 1 (see Section 5.1)

For each row of Table 1.1, if a device supports the feature named in the first column
then that device shall also support the feature named in the second column.

Feature Required feature

8DPSK modulation π/4-DQPSK modulation
5-slot packets 3-slot packets
Enhanced power control Power control
Power class 1 Power control

Table 1.1: Features that require other features

1.1.1 π/4-DQPSK modulation

A device that supports π/4-DQPSK modulation shall be able to transmit and receive
packets using π/4-DQPSK modulation (Enhanced Data Rate 2 Mb/s packets) according
to the requirements in Section 3.2 and Section 4.2 with a payload field of up to 248
symbols.

1.1.2 8DPSK modulation

A device that supports 8DPSK modulation shall be able to transmit and receive packets
using 8DPSK modulation (Enhanced Data Rate 3 Mb/s packets) according to the
requirements in Section 3.2 and Section 4.2 with a payload field of up to 246 symbols.

1.1.3 3-slot packets

A device that supports 3-slot packets shall be able to transmit and receive Basic Rate
packets of any length between 68 µs and 1686 µs and, if supported, Enhanced Data
Rate packets with a payload field of up to 1500 symbols.

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 2, Part A Page 432
Radio Specification

1.1.4 5-slot packets

A device that supports 5-slot packets shall be able to transmit and receive Basic Rate
packets of any length between 68 µs and 2916 µs and, if supported, Enhanced Data
Rate packets with a payload field of up to 2748 symbols.

1.1.5 Power control

A device that supports power control shall be capable of adjusting its transmission
power, shall be capable of responding to legacy power control requests (see [Vol 2] Part
C, Section 4.1.3), and shall meet the requirements in Section 5.2.

1.1.6 Enhanced power control

A device that supports enhanced power control shall be capable of responding to

enhanced power control requests (see [Vol 2] Part C, Section 4.1.3.1) and shall meet
the requirements in Section 5.3.

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 2, Part A Page 433
Radio Specification

2 FREQUENCY BANDS AND CHANNEL

ARRANGEMENT

The Bluetooth system operates in the 2.4 GHz ISM band. This frequency band is 2400
MHz to 2483.5 MHz.

Frequency Range RF Channels

2.400 GHz to 2.4835 GHz f=2402+k MHz, k=0,...,78

Table 2.1: Operating frequency bands

RF channels are spaced 1 MHz and are ordered in channel number k as shown in
Table 2.1.

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 2, Part A Page 434
Radio Specification

3 TRANSMITTER CHARACTERISTICS

The requirements stated in this section are given as power levels at the antenna
connector of the Bluetooth device; this is also referred to as the radiative transmit power
level of the device. If the device does not have a connector, a reference antenna with 0
dBi gain is assumed. Power level values used in HCI commands, HCI events, and Link
Manager Protocol (LMP) PDUs shall be assumed to be the radiative transmit power
level of the device unless specified otherwise.

Due to difficulty in measurement accuracy in radiated measurements, systems with an

integral antenna should provide a temporary antenna connector during RF qualification
testing.

3.1 Basic Rate

3.1.1 Modulation characteristics

The Modulation is GFSK (Gaussian Frequency Shift Keying) with a bandwidth-bit period
product BT=0.5. The Modulation index shall be between 0.28 and 0.35. A binary one
shall be represented by a positive frequency deviation, and a binary zero shall be
represented by a negative frequency deviation. The symbol timing shall be less than
±20 ppm.

Ideal Z ero C rossing

Ft+fd

Fm in-
T ransm it
Frequency Tim e
Ft F m in +

F t - fd
Z ero C rossing Error

Figure 3.1: GFSK parameters definition

For each transmission, the minimum frequency deviation, Fmin = min{|Fmin+|, Fmin-},
which corresponds to 1010 sequence shall be no smaller than ±80% of the frequency

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 2, Part A Page 435
Radio Specification

deviation (fd) with respect to the transmit frequency Ft, which corresponds to a
00001111 sequence.

In addition, the minimum frequency deviation shall never be smaller than 115 kHz. The
data transmitted has a symbol rate of 1 Msym/s.

The zero crossing error is the time difference between the ideal symbol period and the
measured crossing time. This shall be less than ± 1/8 of a symbol period.

See Figure 3.1 for the definitions of some symbols and terms in these requirements.

3.1.2 Spurious emissions

In-band spurious emissions shall be measured with a frequency hopping radio

transmitting on one RF channel and receiving on a second RF channel; this means
that the synthesizer may change RF channels between reception and transmission, but
always returns to the same transmit RF channel.

3.1.2.1 In-band spurious emission

Within the ISM band the transmitter shall pass a spectrum mask, given in Table 3.1.
The spectrum shall comply with the 20 dB bandwidth definition in FCC part 15.247
and shall be measured accordingly. In addition to the FCC requirement an adjacent
channel power on adjacent channels with a difference in RF channel number of two or
greater is defined. This adjacent channel power is defined as the sum of the measured
power in a 1 MHz bandwidth. The transmitted power shall be measured in a 100 kHz
bandwidth using maximum hold. The device shall transmit on RF channel M and the
adjacent channel power shall be measured on RF channel number N. The transmitter
shall transmit a pseudo random data pattern in the payload throughout the test.

Frequency offset Transmit Power

± 500 kHz -20 dBc
2 MHz (|M-N| = 2) -20 dBm
3 MHz or greater (|M-N| ≥ 3) -40 dBm

Table 3.1: Transmit Spectrum mask

Note: If the output power is less than 0 dBm then, wherever appropriate, the FCC's
20 dB relative requirement overrules the absolute adjacent channel power requirement
stated in Table 3.1.

Exceptions are allowed in up to three bands of 1 MHz width centered on a frequency

which is an integer multiple of 1 MHz. They shall comply with an absolute value of –20
dBm.

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 2, Part A Page 436
Radio Specification

3.1.3 Radio frequency tolerance

The transmitted initial center frequency shall be within ±75 kHz from Fc. The initial
frequency accuracy is defined as being the frequency accuracy before any packet
information is transmitted.

The frequency drift requirement is not included in the ±75 kHz.

The limits on the transmitter center frequency drift within a packet are specified in
Table 3.2. The different packets are defined in the Baseband Specification.

Duration of Packet Frequency Drift

Max length one slot packet ±25 kHz
Max length three slot packet ±40 kHz
Max length five slot packet ±40 kHz
Maximum drift rate1 400 Hz/µs

Table 3.2: Maximum allowable frequency drifts in a packet

1The maximum drift rate is allowed anywhere in a packet.

3.2 Enhanced Data Rate

A key characteristic of the Enhanced Data Rate mode is that the modulation mode is
changed within the packet. The access code and packet header, as defined in [Vol 2]
Part B, Table 6.1, are transmitted with the Basic Rate 1 Mb/s GFSK modulation mode,
whereas the subsequent synchronization sequence, payload, and trailer sequence are
transmitted using the Enhanced Data Rate PSK modulation mode.

3.2.1 Modulation characteristics

During access code and packet header transmission the Basic Rate GFSK modulation
mode shall be used. During the transmission of the synchronization sequence, payload,
and trailer sequence a PSK type of modulation with a data rate of 2 Mb/s or optionally
3 Mb/s shall be used. The following subsections specify the PSK modulation for this
transmission.

3.2.1.1 Modulation method overview

The PSK modulation format defined for the 2 Mb/s transmission shall be π/4 rotated
differential encoded quaternary phase shift keying (π/4-DQPSK).

The PSK modulation format defined for the 3 Mb/s transmission shall be differential
encoded 8-ary phase shift keying (8DPSK).

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 2, Part A Page 437
Radio Specification

The modulation shall employ square-root raised cosine pulse shaping to generate the
equivalent lowpass information-bearing signal v(t). The output of the transmitter shall be
a bandpass signal that can be represented as
j2πF ct
S t = Re v t e (EQ 1)

with Fc denoting the carrier frequency.

3.2.1.2 Differential phase encoding

For the M-ary modulation, the binary data stream {bn}, n=1,2,3, ...N, shall be mapped
onto a corresponding sequence {Sk}, k=1,2, ...N÷log2(M) of complex valued signal
points. M=4 applies for 2 Mb/s and M=8 applies for 3 Mb/s. Gray coding shall be applied
as shown in Table 3.3 and Table 3.4. In the event that the length of the binary data
stream N is not an integer multiple of log2(M), the last symbol of the sequence {Sk} shall
be formed by appending data zeros to the appropriate length. The signal points Sk shall
be defined by:
jφ
Sk = Sk − 1e k k = 1, 2 , ..N÷log2 M (EQ 2)

S0 = ejϕ with ϕ ∈ 0, 2π (EQ 3)

The relationship between the binary input bk and the phase ϕk shall be as defined in
Table 3.3 for the 2 Mb/s transmission and in Table 3.4 for the 3 Mb/s transmission.

b2k-1 b2k φk
0 0 π/4
0 1 3π/4
1 1 -3π/4
1 0 -π/4
Table 3.3: π/4-DQPSK mapping

b3k-2 b3k-1 3k φk
0 0 0 0
0 0 1 π/4
0 1 1 π/2
0 1 0 3π/4
1 1 0 π
1 1 1 -3π/4
1 0 1 -π/2
1 0 0 -π/4
Table 3.4: 8DPSK mapping

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 2, Part A Page 438
Radio Specification

3.2.1.3 Pulse shaping

The lowpass equivalent information-bearing signal v(t) shall be generated according to

vt = ∑ Skp t – kT (EQ 4)
k

in which the symbol period T shall be 1 µs.

The frequency spectrum P(f), which corresponds to the square-root raised cosine pulse
p(t) of the pulse shaping filter is:

1−β
1 when 0≤ f ≤ 2T

P f = 1
1 − sin
π 2 fT −1
when
1−β
≤ f ≤
1+β (EQ 5)
2 2β 2T 2T
0 elsewhere
The roll off factor β shall be 0.4.

3.2.1.4 Modulation accuracy

The measurement of modulation accuracy utilizes differential error vector magnitude

(DEVM) with tracking of the carrier frequency drift. The definition of DEVM and the
derivation of the RMS and peak measures of DEVM are given in Appendix C.

The DEVM shall be measured over the synchronization sequence and payload portions
of the packet, but not the trailer symbols. For each modulation method and each
measurement carrier frequency, the DEVM measurement is made over a total of 200
non-overlapping blocks, where each block contains 50 symbols.

The transmitted packets shall be the longest supported packet type for each modulation
method, as defined in [Vol 2] Part B, Table 6.8 and [Vol 2] Part B, Table 6.9.

The DEVM is measured using a square-root raised cosine filter, with a roll-off of 0.4 and
a 3 dB bandwidth of ±500 kHz.

3.2.1.4.1 RMS DEVM

The RMS DEVM for any of the measured blocks shall not exceed 0.20 for π/4-DQPSK
and 0.13 for 8DPSK.

3.2.1.4.2 99% DEVM

The 99% DEVM (defined as the DEVM value for which 99% of measured symbols have
a lower DEVM) shall not exceed 0.30 for π/4-DQPSK and 0.20 for 8DPSK.

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 2, Part A Page 439
Radio Specification

3.2.1.4.3 Peak DEVM

The Peak DEVM shall not exceed 0.35 for π/4-DQPSK and 0.25 for 8DPSK.

3.2.2 Spurious emissions

In-band spurious emissions shall be measured with a frequency hopping radio

transmitting on one RF channel and receiving on a second RF channel; this means
that the synthesizer may change RF channels between reception and transmission, but
always returns to the same transmit RF channel.

3.2.2.1 In-band spurious emission

Within the ISM band the power spectral density of the transmitter shall comply with the
following requirements when sending pseudo random data. All power measurements
shall use a 100 kHz bandwidth with maximum hold. The power measurements between
1 MHz and 1.5 MHz from the carrier shall be at least 26 dB below the maximum power
measurement up to 500 kHz from the carrier. The adjacent channel power for channels
at least 2 MHz from the carrier is defined as the sum of the power measurements over a
1 MHz channel and shall not exceed -20 dBm for the second adjacent channels and -40
dBm for the third and subsequent adjacent channels. These requirements shall apply
to the transmitted signal from the start of the guard time to the end of the power down
ramp. The spectral mask is illustrated in Figure 3.2.

Exceptions are allowed in up to 3 bands of 1 MHz width centered on a frequency which

is an integer multiple of 1 MHz. They shall comply with an absolute value of –20 dBm.

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 2, Part A Page 440
Radio Specification

26 dB

-20 dBm

-40 dBm

FC - 2.5 MHz FC - 1.5 MHz FC - 1 MHz Carrier FC FC + 1 MHz FC + 1.5 MHz FC + 2.5 MHz

Figure 3.2: Transmitter spectrum mask

3.2.3 Radio frequency tolerance

The same carrier frequencies Fc as used for Basic Rate transmissions shall be used
for the Enhanced Data Rate transmissions. The transmitted initial center frequency
accuracy shall be within ±75 kHz from Fc. The maximum excursion from Fc (frequency
offset plus drift) shall not exceed ±75 kHz.

The initial frequency accuracy is defined as being the frequency accuracy before any
information is transmitted.

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 2, Part A Page 441
Radio Specification

Sync
Access Code Header Guard Payload Trailer
Word

Maximum Excursion

±10 kHz

±75 kHz

FC

Maximum Excursion

Figure 3.3: Carrier frequency mask

The requirements on accuracy and stability are illustrated by Figure 3.3 for the
Enhanced Data Rate packet format defined in Definition: Baseband Specification . The
higher frequency accuracy requirement shall start at the first symbol of the header. The
maximum drift over the header, synchronization sequence and payload shall be ±10
kHz.

3.2.4 Relative transmit power

The requirement on the relative power of the GFSK and DPSK portions of the
Enhanced Data Rate packet is defined as follows. The average power level during
the transmission of access code and header is denoted as PGFSK and the average
power level during the transmission of the synchronization sequence and the payload is
denoted as PDPSK. The following inequalities shall be satisfied independently for each
Enhanced Data Rate packet transmitted:

(PGFSK - 4 dB) < PDPSK < (PGFSK + 1 dB)

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 2, Part A Page 442
Radio Specification

4 RECEIVER CHARACTERISTICS

The receiver characteristics shall be measured using loopback as defined in [Vol 3] Part
D, Section 1.

The reference sensitivity level referred to in this section is -70 dBm.

4.1 Basic Rate

4.1.1 Actual sensitivity level

The actual sensitivity level is defined as the input level for which a raw bit error rate
(BER) of 0.1% is met. The receiver sensitivity shall be below or equal to –70 dBm when
receiving signals specified in Section 3.1.

4.1.2 Interference performance

The interference performance on Co-channel and adjacent 1 MHz and 2 MHz shall
be measured with the wanted signal 10 dB over the reference sensitivity level. For
interference performance on all other RF channels the wanted signal shall be 3 dB
over the reference sensitivity level. If the frequency of an interfering signal is outside
of the band 2400 MHz to 2483.5 MHz, the out-of-band blocking specification (see
Section 4.1.3) shall apply. The interfering signal shall be Bluetooth-modulated (see
Section 4.1.7). The BER shall be ≤0.1% for all the signal-to-interference ratios listed in
Table 4.1:

Frequency of Interference Ratio

Co-Channel interference, C/Ico-channel 11 dB
Adjacent (1 MHz) interference1, C/I1 MHz 0 dB
Adjacent (2 MHz) interference1, C/I2 MHz -30 dB
Adjacent (≥3 MHz) interference1, C/I≥3 MHz -40 dB
Image frequency Interference1,2,3, C/IImage -9 dB
Adjacent (1 MHz) interference to in-band image frequency1, C/IImage±1MHz -20 dB

Table 4.1: Interference performance

1If two adjacent channel specifications from Table 4.1 are applicable to the same channel, the more relaxed
specification applies.
2In-band image frequency
3If the image frequency ≠ n MHz, then the image reference frequency is defined as the closest n MHz

frequency for integer n.

These specifications are only to be tested at nominal temperature conditions with

a device receiving on one RF channel and transmitting on a second RF channel;

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 2, Part A Page 443
Radio Specification

this means that the synthesizer may change RF channels between reception and
transmission, but always returns to the same receive RF channel.

RF channels where the requirements are not met are called spurious response RF
channels. Five spurious response RF channels are allowed at RF channels with a
distance of ≥2 MHz from the wanted signal. On these spurious response RF channels a
relaxed interference requirement C/I = -17 dB shall be met.

4.1.3 Out-of-band blocking

The out-of-band suppression (or rejection) shall be measured with the wanted signal
3 dB over the reference sensitivity level. The interfering signal shall be a continuous
wave signal. The BER shall be ≤0.1%. The out-of-band blocking shall fulfil the following
requirements:

Interfering Signal Frequency Interfering Signal Power Level

30 MHz to 2000 MHz -10 dBm
2000 MHz to 2399 MHz -27 dBm
2484 MHz to 3000 MHz -27 dBm
3000 MHz to 12.75 GHz -10 dBm

Table 4.2: Out-of-band suppression (or rejection) requirements

24 exceptions are permitted which are dependent upon the given RF channel and
are centered at a frequency which is an integer multiple of 1 MHz. For at least 19
of these spurious response frequencies, a reduced interference level of at least -50
dBm is allowed in order to achieve the required BER = 0.1% performance, whereas for
a maximum of 5 of the spurious frequencies the interference level may be assumed
arbitrarily lower.

4.1.4 Intermodulation characteristics

The reference sensitivity performance, BER = 0.1%, shall be met under the following
conditions:

• The wanted signal shall be at frequency f0 with a power level 6 dB over the reference
sensitivity level.
• A static sine wave signal shall be at a frequency f1 with a power level of –39 dBm.
• A Bluetooth modulated signal (see Section 4.1.7) shall be at f2 with a power level of
-39 dBm.

Frequencies f0, f1 and f2 shall be chosen such that f 0=2f 1‐f 2 and f 2‐f 1 =n MHz, where n
can be 3, 4, or 5. The system shall fulfill at least one of the three alternatives (n=3, 4, or
5).

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 2, Part A Page 444
Radio Specification

4.1.5 Maximum usable level

The maximum usable input level that the receiver operates at shall be greater than -20
dBm. The BER shall be less than or equal to 0.1% at –20 dBm input power.

4.1.6 Received Signal Strength Indication

If a device supports Received Signal Strength Indication (RSSI) the accuracy shall be
±6 dB. If the device is aware that the RSSI varies across frequencies, then it should
update the RSSI value of a packet depending on the frequency that the packet was
received on before using the value, e.g., before reporting it to the Host.

4.1.7 Reference signal definition

A Bluetooth modulated interfering signal shall be defined as:

Modulation = GFSK
Modulation index = 0.32±1%
BT= 0.5±1%
Bit Rate = 1 Mb/s ±1 ppm
Modulating Data for wanted signal = PRBS9
Modulating Data for interfering signal = PRBS15
Frequency accuracy better than ±1 ppm.

4.2 Enhanced Data Rate

4.2.1 Actual sensitivity level

The actual sensitivity level shall be defined as the input level for which a raw bit
error rate (BER) of 0.01% is met. The requirement for a Bluetooth π/4-DQPSK and
8DPSK Enhanced Data Rate receiver shall be an actual sensitivity level of –70 dBm or
better. The receiver shall achieve the –70 dBm sensitivity level when receiving signals
specified in Section 3.2.

4.2.2 BER floor performance

The receiver shall achieve a BER less than 0.001% at 10 dB above the reference
sensitivity level.

4.2.3 Interference performance

The interference performance for co-channel and adjacent 1 MHz and 2 MHz channels
shall be measured with the wanted signal 10 dB above the reference sensitivity level.
On all other frequencies the wanted signal shall be 3 dB above the reference sensitivity
level. The requirements in this section shall only apply if the frequency of the interferer
is inside of the band 2400 MHz to 2483.5 MHz.

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 2, Part A Page 445
Radio Specification

The interfering signal for co-channel interference shall be similarly modulated as the
desired signal. The interfering signal for other channels shall be equivalent to a nominal
Bluetooth Basic Rate GFSK transmitter. The interfering signal shall carry random data.

A BER of 0.1% or better shall be achieved for the signal to interference ratios defined in
Table 4.3.

Frequency of Interference π/4-DQPSK 8DPSK Ratio

Ratio
Co-Channel interference, C/I co-channel 13 dB 21 dB
Adjacent (1 MHz) interference1, C/I1 MHz 0 dB 5 dB
Adjacent (2 MHz) interference1, C/I2 MHz -30 dB -25 dB
Adjacent (≥3 MHz) interference1 -40 dB -33 dB
Image frequency interference1,2,3, C/IImage -7 dB 0 dB
Adjacent (1 MHz) interference to in-band image frequency1,2,3, -20 dB -13 dB
C/IImage ±1 MHz

Table 4.3: Interference performance

1If two adjacent channel specifications from Table 4.3 are applicable to the same channel, the more relaxed
specification applies.
2In-band image frequency.
3If the image frequency is not equal to n MHz, then the image reference frequency is defined as the closest

n MHz frequency for integer n.

These specifications are only to be tested at nominal temperature conditions with

a receiver hopping on one frequency; this means that the synthesizer may change
frequency between receive slot and transmit slot, but always returns to the same
receive frequency.

Frequencies where the requirements are not met are called spurious response
frequencies. Five spurious response frequencies are allowed at frequencies with a
distance of ≥2 MHz from the wanted signal. On these spurious response frequencies
a relaxed interference requirement C/I = -15 dB for π/4-DQPSK and C/I = -10 dB for
8DPSK shall be met.

4.2.4 Maximum usable level

The maximum usable input level that the receiver operates at shall be greater than -20
dBm. The BER shall be less than or equal to 0.1% at -20 dBm input power.

4.2.5 Out-of-band and intermodulation characteristics

The Basic Rate out-of-band blocking and intermodulation requirements also apply
to Enhanced Data Rate since they result in adequate performance. No additional
requirements apply to Enhanced Data Rate.

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 2, Part A Page 446
Radio Specification

4.2.6 Reference signal definition

A 2 Mb/s Bluetooth signal used as "wanted" or "interfering signal" is defined as:

Modulation = π/4-DQPSK
Symbol Rate = 1 Msym/s ± 1 ppm
Frequency accuracy better than ±1 ppm
Modulating Data for wanted signal = PRBS9
Modulating Data for interfering signal = PRBS15
RMS Differential Error Vector Magnitude < 5%
Average power over the GFSK and DPSK portions of the packet shall be equal to within
±1 dB

A 3 Mb/s Bluetooth signal used as "wanted" or "interfering signal" is defined as:

Modulation = 8DPSK
Symbol Rate = 1 Msym/s ± 1 ppm
Frequency accuracy better than ±1 ppm
Modulating Data for wanted signal = PRBS9
Modulating Data for interfering signal = PRBS15
RMS Differential Error Vector Magnitude < 5%
Average power over the GFSK and DPSK portions of the packet shall be equal to within
±1 dB

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 2, Part A Page 447
Radio Specification

5 POWER MANAGEMENT

5.1 Power classes

Bluetooth devices are classified into three power classes based on their output power
capabilities level at the maximum power setting (Pmax) the device supports, as defined
in Table 5.1.

Power Class Requirements

1 100 mW (20 dBm) ≥ Pmax > 2.5 mW (4 dBm)
2 2.5 mW (4 dBm) ≥ Pmax > 1 mW (0 dBm)
3 1 mW (0 dBm) ≥ Pmax
Table 5.1: Power classes

A class 1 device shall be able to adjust its transmit power down to 4 dBm or less.

If a class 1 device is paging or inquiring very close to another device, the input power
can be larger than the requirement in Section 4.1.5. This can cause the receiving device
to fail to respond. It may therefore be useful to page at class 2 or 3 power in addition to
paging at power class 1.

If the receiving device in a connection does not support the necessary messaging for
sending power control messages (see [Vol 2] Part C, Section 4.1.3), then the output
power of the transmitting device shall not exceed the maximum output power of power
class 2.

5.2 Power control

A device that supports power control shall have a set of transmission power levels;
the difference in power level between adjacent levels forms a “power step”. The power
steps shall form a monotonic sequence, with a maximum step size of 8 dB and a
minimum step size of 2 dB. The power level at the lowest power step should be less
than -30 dBm.

The transmit power level difference between the packet headers of all supported packet
types at any given power step shall not exceed 10 dB.

A device that supports power control shall control the output power in a physical link
in response to LMP commands received from a peer device that is capable of sending
such requests (see [Vol 2] Part C, Section 4.1.3).

Using high transmit power in use cases where short ranges could be encountered can
cause the receiver on the remote device to be saturated and result in link failure. Power

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 2, Part A Page 448
Radio Specification

control requests can be used to adjust a connected remote device’s transmit power
level based on the receiver’s signal level.

A power class 1 device can use power control to limit the transmitted power of a remote
device to no more than +4 dBm. A power class 2 or class 3 device can use power
control to optimize the power consumption and reduce the overall interference level for
all devices that use the same spectrum that Bluetooth devices use.

5.3 Enhanced power control

When communicating with a device that does not support enhanced power control, a
device that supports enhanced power control shall have an equal number of power
steps for each supported modulation scheme so that all supported modulation modes
shall reach their respective maximum (or minimum) levels at the same time. The power
levels may vary per modulation mode.

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 2, Part A Page 449
Radio Specification

Appendix A Test conditions

A.1 Nominal test conditions

A.1.1 Nominal temperature

The nominal temperature conditions for tests shall be +15 to +35 °C. When it is
impractical to carry out the test under this condition a note to this effect, stating the
ambient temperature, shall be recorded. The actual value during the test shall be
recorded in the test report.

A.1.2 Nominal power source

The normal test voltage for the equipment shall be the nominal voltage for which the
equipment was designed.

A.2 [This section is no longer used]

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 2, Part A Page 450
Radio Specification

Appendix B [This Appendix is no longer used]

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 2, Part A Page 451
Radio Specification

Appendix C Modulation accuracy definition

C.1 Enhanced Data Rate modulation accuracy

The Enhanced Data Rate modulation accuracy is defined by the differential error vector,
being the difference between the vectors representing consecutive symbols of the
transmitted signal, after passing the signal through a specified measurement filter,
sampling it at the symbol rate with an optimum sampling phase and compensating it
for carrier frequency error and for the ideal carrier phase changes. The magnitude of
the normalized differential error vector is called the Differential Error Vector Magnitude
(DEVM). The objective of the DEVM is to estimate the modulation errors that would be
perceived by a differential receiver.

In an ideal transmitter, the input bit sequence {bj} is mapped onto a complex valued
symbol sequence {Sk}. Subsequently, this symbol sequence is transformed into a
baseband signal S(t) by means of a pulse-shaping filter.

In an actual transmitter implementation, the bit sequence {bj} generates a baseband

equivalent transmitted signal Y(t). This signal Y(t) contains, besides the desired
component S(t), multiple distortion components. This is illustrated in Figure C.1 (in
Figure C.1 and Figure C.2 a circle with an X indicates a mixer).

Actual TX

Ideal TX (Baseband)

{bj} {Sk} Pulse S(t) Y(t) R(t)

Mapper Distortions
Shaping

exp(jωct)

Figure C.1: TX model

Let Z(t) be the output of the measurement filter after first compensating the received
signal for the initial center frequency error, ωi, of the received packet, i.e. the output
after down conversion and filtering the transmit signal R(t) (see Figure C.2).The
measurement filter is defined by a square-root raised cosine shaping filter with a roll-off
factor equal to 0.4 and 3 dB bandwidth of ±500 kHz.

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 2, Part A Page 452
Radio Specification

Let {Zk(ε)} be the sequence of samples obtained by sampling the signal Z(t) with a
sampling period equal to the symbol period T and a sampling phase equal to ε such that
Zk(ε)=Z((k+ε)T).

This sequence {Zk(ε)} would coincide with the symbol sequence {Sk} if no distortion is
present and the correct timing phase ε is chosen.

To reflect the behavior of a typical differential receiver, the sample sequence {Zk(ε)}
should be compensated for carrier frequency drift. Therefore, the sequence {Zk(ε)} is
multiplied by a factor W-k in which W = ejωT accounts for the frequency offset ω. A
constant value of ω is used for each DEVM block of N = 50 symbols, but ω may vary
between DEVM blocks (the values of ω can be used to measure carrier frequency drift).

In addition, {Zk(ε)} is compensated for the ideal phase changes between symbols by
multiplying it with the complex conjugate of the symbol sequence {Sk}. However, it is
not necessary to compensate {Zk(ε)} for initial carrier phase or output power of the
transmitter.

Let {Qk(ε,ω)} denote the compensated sequence {Zk(ε)}, where the ideal phase changes
have been removed and ε and ω are chosen optimally to minimize the DEVM, (i.e.
remove time and frequency uncertainty). For a transmitter with no distortions other than
a constant frequency error, {Qk(ε,ω)} is a complex constant that depends on the initial
carrier phase and the output power of the transmitter.

The differential error sequence {Ek(ε,ω)} is defined as the difference between {Qk(ε,ω)}
and {Qk-1(ε,ω)}. This reflects the modulation errors that would be perceived by a
differential receiver. For a transmitter with no distortions other than a constant frequency
error, {Ek(ε,ω)} is zero.

The definitions of the DEVM measures are based upon this differential error sequence
{Ek(ε,ω)}. The generation of the error sequence is depicted in Figure C.2 (the circle with
the + indicates a direct summation function; the input with the "−" is negated before
being summed).

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 2, Part A Page 453
Radio Specification

Delay
Ek(ε,ω)
1 µs

Qk(ε,ω)

Measurement Z(t) Zk(ε)

R(t)
Filter

e -j(ωc-ωi)t Sk*×W-k

Figure C.2: Error sequence generation

C.1.1 RMS DEVM

The root mean squared DEVM (RMS DEVM) computed over N = 50 symbols is defined
as:

N
∑ Ek ε, ω 2

k=1
RMS DEVM = min N (EQ 6)
ε, ω
∑ Qk ε, ω 2

k=1

As can be seen from the expression above, the RMS DEVM is the square-root of the
normalized power of the error.

C.1.2 Peak DEVM

The DEVM at symbol k is defined as:

2
Ek ε0, ω0
DEVM k = N (EQ 7)
∑ Qj ε0, ω0 /N
2

j=1

where ε0 and ω0 are the values for ε and ω used to calculate the RMS DEVM.

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 2, Part A Page 454
Radio Specification

The peak DEVM is defined as:

Peak DEVM = max DEVM k (EQ 8)

k

Bluetooth SIG Proprietary Version Date: 2024-08-27

 BR/EDR Controller
Part B

BASEBAND
SPECIFICATION

This Part describes the specification of the

Bluetooth Link Controller which carries out the
Baseband protocols and other low-level link
routines.

Bluetooth SIG Proprietary

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 2, Part B Page 456
Baseband Specification

CONTENTS

1 General description .................................................................................. 463

1.1 Bluetooth clock ............................................................................ 464
1.2 Bluetooth Device addressing ...................................................... 465
1.2.1 Reserved addresses .................................................... 466
1.3 Access codes .............................................................................. 467

2 Physical channels ..................................................................................... 468

2.1 Physical channel definition .......................................................... 469
2.2 Basic piconet physical channel ................................................... 469
2.2.1 Central and Peripheral roles ........................................ 469
2.2.2 Hopping characteristics ............................................... 470
2.2.3 Time slots .................................................................... 470
2.2.4 Piconet clocks .............................................................. 471
2.2.5 Transmit/receive timing ................................................ 471
2.2.5.1 Piconet physical channel timing ................... 472
2.2.5.2 Piconet physical channel re-
synchronization ............................................ 474
2.3 Adapted piconet physical channel ............................................... 475
2.3.1 Hopping characteristics ............................................... 475
2.4 Page scan physical channel ........................................................ 475
2.4.1 Clock estimate for paging ............................................ 476
2.4.2 Hopping characteristics ............................................... 476
2.4.3 Paging procedure timing .............................................. 476
2.4.4 Page response timing .................................................. 477
2.5 Inquiry scan physical channel ..................................................... 479
2.5.1 Clock for inquiry ........................................................... 479
2.5.2 Hopping characteristics ............................................... 480
2.5.3 Inquiry procedure timing .............................................. 480
2.5.4 Inquiry response timing ............................................... 480
2.6 Hop selection .............................................................................. 481
2.6.1 General selection scheme ........................................... 482
2.6.2 Selection kernel ........................................................... 485
2.6.2.1 First addition operation ................................ 486
2.6.2.2 XOR operation ............................................. 486
2.6.2.3 Permutation operation .................................. 487
2.6.2.4 Second addition operation ........................... 488
2.6.2.5 Register bank ............................................... 488
2.6.3 Adapted hop selection kernel ...................................... 488
2.6.3.1 Channel re-mapping function ....................... 489

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 2, Part B Page 457
Baseband Specification

2.6.4 Control word ................................................................ 490

2.6.4.1 Page scan and inquiry scan hopping
sequences .................................................... 491
2.6.4.2 Page hopping sequence .............................. 492
2.6.4.3 Peripheral page response hopping
sequence ...................................................... 492
2.6.4.4 Central page response hopping sequence .. 493
2.6.4.5 Inquiry hopping sequence ............................ 493
2.6.4.6 Inquiry response hopping sequence ............ 494
2.6.4.7 Basic and adapted channel hopping
sequence ...................................................... 494
2.6.4.8 Synchronization train RF channels .............. 494
2.7 Synchronization scan physical channel ...................................... 494
2.7.1 Hopping characteristics ............................................... 494
2.7.2 Synchronization Train procedure timing ...................... 494
2.7.3 Synchronization Scan procedure timing ...................... 496

3 Physical links ............................................................................................ 497

3.1 Link supervision for active physical links ..................................... 497
3.2 Link supervision for Connectionless Peripheral Broadcast
physical links ............................................................................... 498
3.3 Authenticated payload timeout for active links ............................ 498

4 Logical transports ..................................................................................... 499

4.1 General ........................................................................................ 499
4.2 Logical transport address (LT_ADDR) ........................................ 499
4.3 Synchronous logical transports ................................................... 500
4.4 Asynchronous logical transport ................................................... 500
4.5 Transmit/receive routines ............................................................ 501
4.5.1 TX routine .................................................................... 501
4.5.1.1 ACL traffic .................................................... 502
4.5.1.2 SCO traffic .................................................... 503
4.5.1.3 Mixed data/voice traffic ................................ 503
4.5.1.4 eSCO traffic .................................................. 504
4.5.1.5 Default packet types ..................................... 504
4.5.2 RX routine .................................................................... 504
4.5.3 Flow control ................................................................. 505
4.5.3.1 Destination control ....................................... 506
4.5.3.2 Source control .............................................. 506
4.6 Active Peripheral broadcast transport ......................................... 506
4.7 [This section is no longer used] ................................................... 507
4.8 Connectionless Peripheral Broadcast logical transport ............... 507

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 2, Part B Page 458
Baseband Specification

5 Logical links .............................................................................................. 508

5.1 Link Control logical link (LC) ....................................................... 508
5.2 ACL Control logical links (ACL-C and APB-C) ............................ 508
5.3 User asynchronous/isochronous logical links (ACL‑U and
APB‑U) ........................................................................................ 509
5.3.1 Pausing the ACL-U logical link .................................... 509
5.4 User synchronous data logical link (SCO-S) ............................... 509
5.5 User extended synchronous data logical link (eSCO-S) ............. 509
5.6 Logical link priorities .................................................................... 509
5.7 Profile broadcast data logical link ................................................ 510

6 Packets ...................................................................................................... 511

6.1 General format ............................................................................ 511
6.1.1 Basic Rate ................................................................... 511
6.1.2 Enhanced Data Rate ................................................... 511
6.2 Bit ordering .................................................................................. 512
6.3 Access code ................................................................................ 512
6.3.1 Access code types ....................................................... 512
6.3.2 Preamble ..................................................................... 513
6.3.3 Sync word .................................................................... 513
6.3.3.1 Synchronization word definition ................... 513
6.3.3.2 Pseudo-random noise sequence generation 516
6.3.4 Trailer ........................................................................... 517
6.4 Packet header ............................................................................. 517
6.4.1 LT_ADDR ..................................................................... 518
6.4.2 TYPE ........................................................................... 518
6.4.3 FLOW .......................................................................... 518
6.4.4 ARQN .......................................................................... 518
6.4.5 SEQN ........................................................................... 519
6.4.6 HEC ............................................................................. 519
6.5 Packet types ................................................................................ 519
6.5.1 Common packet types ................................................. 522
6.5.1.1 ID packet ...................................................... 522
6.5.1.2 NULL packet ................................................ 522
6.5.1.3 POLL packet ................................................ 522
6.5.1.4 FHS packet .................................................. 522
6.5.1.5 DM1 packet .................................................. 524
6.5.2 SCO packets ................................................................ 524
6.5.2.1 HV1 packet ................................................... 525
6.5.2.2 HV2 packet ................................................... 525
6.5.2.3 HV3 packet ................................................... 525
6.5.2.4 DV packet ..................................................... 525
6.5.3 eSCO packets .............................................................. 525

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 2, Part B Page 459
Baseband Specification

6.5.3.1 EV3 packet ................................................... 526

6.5.3.2 EV4 packet ................................................... 526
6.5.3.3 EV5 packet ................................................... 526
6.5.3.4 2-EV3 packet ................................................ 526
6.5.3.5 2-EV5 packet ................................................ 526
6.5.3.6 3-EV3 packet ................................................ 527
6.5.3.7 3-EV5 packet ................................................ 527
6.5.4 ACL packets ................................................................ 527
6.5.4.1 DM1 packet .................................................. 527
6.5.4.2 DH1 packet .................................................. 527
6.5.4.3 DM3 packet .................................................. 528
6.5.4.4 DH3 packet .................................................. 528
6.5.4.5 DM5 packet .................................................. 528
6.5.4.6 DH5 packet .................................................. 528
6.5.4.7 AUX1 packet ................................................ 528
6.5.4.8 2-DH1 packet ............................................... 528
6.5.4.9 2-DH3 packet ............................................... 529
6.5.4.10 2-DH5 packet ............................................... 529
6.5.4.11 3-DH1 packet ............................................... 529
6.5.4.12 3-DH3 packet ............................................... 529
6.5.4.13 3-DH5 packet ............................................... 529
6.6 Payload format ............................................................................ 529
6.6.1 Synchronous data field ................................................ 530
6.6.2 Asynchronous data field .............................................. 531
6.7 Packet summary .......................................................................... 535

7 Bit stream processing .............................................................................. 537

7.1 Error checking ............................................................................. 538
7.1.1 HEC generation ........................................................... 539
7.1.2 CRC generation ........................................................... 540
7.2 Data whitening ............................................................................ 541
7.3 Error correction ............................................................................ 542
7.4 FEC code: rate 1/3 ...................................................................... 543
7.5 FEC code: rate 2/3 ...................................................................... 543
7.6 ARQ scheme ............................................................................... 544
7.6.1 Unnumbered ARQ ....................................................... 544
7.6.2 Retransmit filtering ....................................................... 548
7.6.2.1 Initialization of SEQN at start of new
connection .................................................... 549
7.6.2.2 ACL and SCO retransmit filtering ................. 549
7.6.2.3 eSCO retransmit filtering .............................. 550
7.6.2.4 FHS retransmit filtering ................................ 550

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 2, Part B Page 460
Baseband Specification

7.6.2.5
Extended inquiry response retransmit
filtering .......................................................... 550
7.6.2.6 Packets without CRC retransmit filtering ...... 551
7.6.3 Flushing payloads ........................................................ 551
7.6.4 Multi-Peripheral considerations ................................... 552
7.6.5 Active Peripheral Broadcast packets ........................... 552
7.7 Erroneous synchronous data reporting ....................................... 553
7.8 Message Integrity Check ............................................................. 553

8 Link Controller operation ......................................................................... 554

8.1 Overview of states ....................................................................... 554
8.2 Standby state .............................................................................. 555
8.3 Connection establishment substates .......................................... 555
8.3.1 Page Scan substate .................................................... 555
8.3.2 Page substate .............................................................. 557
8.3.3 Page response substates ............................................ 559
8.3.3.1 Peripheral Page Response substate ........... 562
8.3.3.2 Central Page Response substate ................ 563
8.4 Device discovery substates ......................................................... 564
8.4.1 Inquiry Scan substate .................................................. 565
8.4.2 Inquiry substate ........................................................... 566
8.4.3 Inquiry Response substate .......................................... 567
8.5 Connection state ......................................................................... 569
8.6 Active mode ................................................................................. 571
8.6.1 Polling in the Active mode ........................................... 572
8.6.2 SCO ............................................................................. 572
8.6.3 eSCO ........................................................................... 573
8.6.4 Broadcast scheme ....................................................... 576
8.6.5 Role switch .................................................................. 577
8.6.6 Scatternet .................................................................... 579
8.6.6.1 Inter-piconet communications ...................... 579
8.6.7 Hop sequence switching .............................................. 580
8.6.8 Channel classification and channel map selection ...... 583
8.6.9 Power management .................................................... 584
8.6.9.1 Packet handling ........................................... 584
8.6.9.2 Slot occupancy ............................................. 584
8.6.9.3 Recommendations for low-power operation 584
8.6.9.4 Enhanced Data Rate .................................... 585
8.6.10 Piconet clock adjustment ............................................. 585
8.6.10.1 Coarse clock adjustment .............................. 585
8.6.10.2 Coarse Clock Adjustment Recovery mode .. 587
8.6.10.3 Clock Dragging ............................................. 588
8.6.11 Slot Availability Mask (SAM) ........................................ 588

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 2, Part B Page 461
Baseband Specification

8.6.11.1 SAM anchor point ......................................... 592

8.6.11.2 SAM scheduling ........................................... 593
8.7 Sniff mode ................................................................................... 595
8.7.1 Sniff Transition mode ................................................... 597
8.7.2 Sniff subrating .............................................................. 597
8.7.2.1 Sniff mode timeout ....................................... 598
8.7.2.2 Sniff Subrating mode .................................... 598
8.8 Hold mode ................................................................................... 599
8.9 [This section is no longer used] ................................................... 599
8.10 Connectionless Peripheral Broadcast mode ............................... 599
8.10.1 Connectionless Peripheral Broadcast transmit
operation ...................................................................... 600
8.10.2 Connectionless Peripheral Broadcast receive
operation ...................................................................... 601
8.10.3 AFH in Connectionless Peripheral Broadcast ............. 602
8.11 Synchronization establishment substates ................................... 602
8.11.1 Synchronization Scan substate ................................... 602
8.11.2 Synchronization Train substate ................................... 602

9 Audio .......................................................................................................... 606

9.1 LOG PCM codec ......................................................................... 606
9.2 CVSD codec ................................................................................ 606
9.3 Error handling .............................................................................. 609
9.4 General audio requirements ........................................................ 609
9.4.1 Signal levels ................................................................. 609
9.4.2 CVSD audio quality ..................................................... 609

Appendix A General audio recommendations .................................................. 610

A.1 Maximum sound pressure ........................................................... 610
A.2 [This section is no longer used] ................................................... 610
A.3 Audio levels for Bluetooth ........................................................... 610
A.4 Microphone path ......................................................................... 611
A.5 Loudspeaker path ....................................................................... 611
A.6 Bluetooth voice interface ............................................................. 611
A.7 Frequency mask .......................................................................... 612

Appendix B Timers ............................................................................................... 614

B.1 List of timers ................................................................................ 614
B.1.1 inquiryTO ..................................................................... 614
B.1.2 pageTO ........................................................................ 614
B.1.3 extended_pageTO ....................................................... 614
B.1.4 pagerespTO ................................................................. 614
B.1.5 newconnectionTO ........................................................ 614

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 2, Part B Page 462
Baseband Specification

B.1.6 supervisionTO .............................................................. 615

B.1.7 CPB_supervisionTO .................................................... 615
B.1.8 synchronization_trainTO .............................................. 615
B.1.9 synchronization_scanTO ............................................. 615
B.1.10 authenticatedPayloadTO ............................................. 616
B.1.11 CLK_adj_dragTO ......................................................... 616

Appendix C Recommendations for AFH operation in Hold, Sniff, and

Connectionless Peripheral Broadcast modes .............................. 617
C.1 Operation at the Central .............................................................. 617
C.2 [This section is no longer used] ................................................... 618
C.3 AFH operation in Sniff mode ....................................................... 618
C.4 AFH operation in Hold mode ....................................................... 618
C.5 AFH operation in Connectionless Peripheral Broadcast ............. 618

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 2, Part B Page 463
Baseband Specification

1 GENERAL DESCRIPTION

This part specifies the normal operation of a Bluetooth Baseband.

The Bluetooth system provides a point-to-point connection or a point-to-multipoint

connection, see (a) and (b) in Figure 1.1. In a point-to-point connection the physical
channel is shared between two Bluetooth devices. In a point-to-multipoint connection,
the physical channel is shared among several Bluetooth devices. Two or more devices
sharing the same physical channel form a piconet. One Bluetooth device acts as the
Central of the piconet, whereas the other device(s) act as Peripheral(s). Up to seven
Peripherals can be active in the piconet. The channel access is controlled by the
Central. An unlimited number of Peripherals can receive data on the physical channel
carrying the Connectionless Peripheral Broadcast physical link.

Piconets that have common devices are called a scatternet, see (c) in Figure 1.1.
Each piconet only has a single Central, however, Peripherals can participate in different
piconets on a time-division multiplex basis. In addition, a Central in one piconet can be
a Peripheral in other piconets. Piconets shall not be frequency synchronized and each
piconet has its own hopping sequence.

Central
Peripheral

a b c

Figure 1.1: Piconets with a single Peripheral operation (a), a multi-Peripheral operation (b) and a
scatternet operation (c)

Data is transmitted over the air in packets. Two modes are defined: a mandatory mode
called Basic Rate and an optional mode called Enhanced Data Rate. The symbol rate
for all modulation modes is 1 Msym/s. The gross air data rate is 1 Mb/s for Basic Rate.
Enhanced Data Rate has a primary modulation mode that provides a gross air data rate
of 2 Mb/s, and a secondary modulation mode that provides a gross air data rate of 3
Mb/s.

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 2, Part B Page 464
Baseband Specification

The general Basic Rate packet format is shown in Figure 1.2. Each packet consists of 3
entities: the access code, the header, and the payload.

Figure 1.2: Standard Basic Rate packet format

The general Enhanced Data Rate packet format is shown in Figure 1.3. Each
packet consists of 6 entities: the access code, the header, the guard period, the
synchronization sequence, the Enhanced Data Rate payload and the trailer. The access
code and header use the same modulation mode as for Basic Rate packets while
the synchronization sequence, the Enhanced Data Rate payload and the trailer use
the Enhanced Data Rate modulation mode. The guard time allows for the transition
between the modulation modes.

Figure 1.3: Standard Enhanced Data Rate packet format

1.1 Bluetooth clock

Every Bluetooth device shall have a native clock that shall be derived from a free
running reference clock. Offsets may be added to the reference clock to synchronize the
native clock with other non-Bluetooth systems. For synchronization with other Bluetooth
devices, offsets are used that, when added to the native clock, provide temporary
Bluetooth clocks that are mutually synchronized. It should be noted that the Bluetooth
clock has no relation to the time of day; it may therefore be initialized to any value. The
clock has a cycle of about a day. If the clock is implemented with a counter, a 28-bit
counter is required that shall wrap around at 228 -1. The least significant bit (LSB) shall
tick in units of 312.5 μs (i.e. half a time slot), giving a clock rate of 3.2 kHz.

The clock determines critical periods and triggers the events in the device. Four periods
are important in the Bluetooth system: 312.5 μs, 625 μs, 1.25 ms, and 1.28 s; these
periods correspond to the timer bits CLK0, CLK1, CLK2, and CLK12, respectively, see
Figure 1.4.

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 2, Part B Page 465
Baseband Specification

CLK 27 12 11 10 9 8 7 6 5 4 3 2 1 0 3.2 kHz

312.5 μs
625 μs
1.25 ms
1.28 s

Figure 1.4: Bluetooth clock

In the different modes and states a device can reside in, the clock has different
appearances:

• CLKR reference clock

• CLKN native clock
• CLKE estimated clock
• CLK Central's clock

CLKR is the reference clock driven by the free running system clock. CLKN may be
offset from the reference clock by a timing offset. In Standby state and in Hold, Sniff,
and Connectionless Peripheral Broadcast modes the reference clock shall have a worst
case accuracy of ±250 ppm. In all other circumstances, it shall have a worst case
accuracy of ±20 ppm; this accuracy shall also be used by the piconet Central while
performing Piconet Clock Adjustment (see Section 8.6.10).

See Section 2.2.4 for the definition of CLK and Section 2.4.1 for the definition of CLKE.

The Central may adjust its native clock during the existence of the piconet within certain
limits (see Section 8.6.10.3). The Central may also perform a coarse adjustment of the
native clock by using the LMP_CLK_ADJ sequence.

1.2 Bluetooth Device addressing

Each Bluetooth device shall be allocated a unique 48-bit Bluetooth Device Address
(BD_ADDR). The address shall be a 48-bit extended unique identifier (EUI-48) created
in accordance with section 8.2 ("Universal addresses") of the IEEE 802-2014 standard
(http://standards.ieee.org/findstds/standard/802-2014.html).

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 2, Part B Page 466
Baseband Specification

Creation of a valid EUI-48 requires one of the following MAC Address Block types to be
obtained from the IEEE Registration Authority:

• MAC Address Block Large (MA-L)

• MAC Address Block Medium (MA-M)
• MAC Address Block Small (MA-S)

See http://standards.ieee.org/develop/regauth/index.html for information on obtaining

one of these MAC Address Blocks. See also the IEEE’s guidelines for use of these
addresses (https://standards.ieee.org/develop/regauth/tut/eui.pdf).

Figure 1.5 illustrates how the LAP, UAP, and NAP map to the EUI-48. The bit pattern in
Figure 1.5 is an example BD_ADDR.

LSB MSB
EUI-48

LAP UAP NAP

0000 0001 0000 0000 0000 0000 0001 0010 0111 1011 0011 0101

Figure 1.5: Format of BD_ADDR

The BD_ADDR may take any values except those that would have any of the 64
reserved LAP values for general and dedicated inquiries (see Section 1.2.1).

1.2.1 Reserved addresses

A block of 64 contiguous LAPs is reserved for inquiry operations; one LAP common
to all devices is reserved for general inquiry, the remaining 63 LAPs are reserved for
dedicated inquiry of specific classes of devices (see Assigned Numbers). The same
LAP values are used regardless of the contents of UAP and NAP. Consequently, none
of these LAPs can be part of a user BD_ADDR.

The reserved LAP addresses are 0x9E8B00 to 0x9E8B3F. The general inquiry LAP is
0x9E8B33. All addresses have the LSB at the rightmost position, hexadecimal notation.
The default check initialization (DCI) is used as the UAP whenever one of the reserved
LAP addresses is used. The DCI is defined to be 0x00 (hexadecimal).

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 2, Part B Page 467
Baseband Specification

1.3 Access codes

In the Bluetooth system all transmissions over the physical channel begin with an
access code. Three different access codes are defined, see also Section 6.3.1:

• device access code (DAC)

• channel access code (CAC)
• inquiry access code (IAC)

All access codes are derived from the LAP of a device address or an inquiry address.
The device access code is used during Page, Page Scan, Central Page Response,
and Peripheral Page Response substates and shall be derived from the paged device’s
BD_ADDR. The channel access code is used in the Connection state, Synchronization
Train substate, and Synchronization Scan substate, and forms the beginning of all
packets exchanged on the piconet physical channel. The channel access code shall be
derived from the LAP of the Central’s BD_ADDR. Finally, the inquiry access code shall
be used in the Inquiry substate. There is one general IAC (GIAC) for general inquiry
operations and there are 63 dedicated IACs (DIACs) for dedicated inquiry operations.

The access code also indicates to the receiver the arrival of a packet. It is used for
timing synchronization and offset compensation. The receiver correlates against the
entire synchronization word in the access code, providing very robust signaling.

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 2, Part B Page 468
Baseband Specification

2 PHYSICAL CHANNELS

The lowest architectural layer in the Bluetooth system is the physical channel. A
number of types of physical channels are defined. All Bluetooth physical channels
are characterized by the combination of a basic pseudo-random frequency hopping
sequence (which, for physical links on the adapted piconet physical channel, is then
modified by the AFH_channel_map (defined in [Vol 2] Part C, Section 5.2) for that
link), the specific slot timing of the transmissions, the access code and packet header
encoding. These aspects, together with the range of the transmitters, define the
signature of the physical channel. For the basic and adapted piconet physical channels
frequency hopping is used to change frequency periodically to reduce the effects of
interference.

Two devices that wish to communicate use a shared physical channel for this
communication. To achieve this, their transceivers must be tuned to the same RF
frequency at the same time, and they must be within a nominal range of each other.

Given that the number of RF carriers is limited and that many Bluetooth devices could
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 always
present at the start of every transmitted packet.

Several Bluetooth 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 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 of these 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 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

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 2, Part B Page 469
Baseband Specification

actively involved in communications over the channel.) At a minimum, a device need

only be capable of connection to one physical channel at a time, however, advanced
devices may be capable of connecting simultaneously to more than one physical
channel, but the specification does not assume that this is possible.

2.1 Physical channel definition

Physical channels, apart from the synchronization scan physical channel (which uses a
set of fixed RF channels), are defined by a basic pseudo-random RF channel hopping
sequence, the packet (slot) timing, and an access code. The hopping sequences
are determined by the UAP and LAP of a Bluetooth Device Address, the selected
basic hopping sequence, and – for the adapted piconet physical channel – the
AFH_channel_map being used on a physical link. The phase in the hopping sequence
is determined by the Bluetooth clock. All physical channels are subdivided into time
slots. Within the physical channel, each reception or transmission event is associated
with a time slot or time slots. For each reception or transmission event an RF channel
is selected by the hop selection kernel (see Section 2.6).The maximum hop rate is
1600 hops per second in the Connection state, the Synchronization Train substate, and
the Synchronization Scan substate and the maximum is 3200 hops per second in the
Inquiry and Page substates.

The following physical channels are defined:

• basic piconet physical channel

• adapted piconet physical channel
• page scan physical channel
• inquiry scan physical channel
• synchronization scan physical channel

2.2 Basic piconet physical channel

During the Connection state the basic piconet physical channel is used by default. The
adapted piconet physical channel may also be used. The adapted piconet physical
channel is identical to the basic piconet physical channel except for the differences
listed in Section 2.3.

2.2.1 Central and Peripheral roles

The basic piconet physical channel is defined by the Central of the piconet. The
Central controls the traffic on the piconet physical channel by a polling scheme (see
Section 8.5).

Bluetooth SIG Proprietary Version Date: 2024-08-27

 BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 2, Part B Page 470
Baseband Specification

By definition, the device that initiates a connection by paging is the Central. Once a
piconet has been established, the Central and Peripheral may exchange roles. This is
described in Section 8.6.5.

2.2.2 Hopping characteristics

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

through all 79 RF channels. The frequency hopping in the piconet physical channel
is determined by the Bluetooth clock and BD_ADDR of the Central. When the piconet
is established, the Central's clock is communicated to the Peripherals. Each Peripheral
shall add an offset to its native clock to synchronize with the Central's clock. Since the
clocks are independent, the offsets must be updated regularly. All devices participating
in the piconet are time-synchronized and hop-synchronized to the channel.

The basic piconet physical channel uses the basic channel hopping sequence and is
described in Section 2.6.

2.2.3 Time slots

The basic piconet physical channel is divided into time slots, each 625 μs in length. The
time slots are numbered according to the most significant 27 bits of the Bluetooth clock
CLK27-1 of the piconet Central. The slot numbering ranges from 0 to 227-1 and is cyclic
with a cycle length of 227. The time slot number is denoted as k.

A TDD scheme is used where Central and Peripheral alternately transmit, see
Figure 2.1. The packet start shall be aligned with the slot start. Packets may extend
over up to five time slots.

625 µs

k k+1 k+2 k+3 k+4 k+5 k+6 k+7 k+8 k+9 k+10 k+11 k+12 k+13
Central
Peripheral

Figure 2.1: Multi-slot packets

The term slot pairs is used to indicate two adjacent time slots starting with a Central-to-
Peripheral transmission slot.

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 2, Part B Page 471
Baseband Specification

2.2.4 Piconet clocks

CLK is the clock of the Central of the piconet. It shall be used for all timing and
scheduling activities in the piconet. All devices shall use the CLK to schedule their
transmission and reception. The CLK shall be derived from the reference clock
CLKR (see Section 1.1) by adding a time_base_offset and a peripheral_clock_offset,
see Figure 2.2. The time_base_offset is a value that devices may use to store a
locally generated offset to CLKN caused by alignment to an external time base. The
peripheral_clock_offset shall be zero for the Central since CLK is identical to its own
native clock CLKN. Each Peripheral shall add an appropriate peripheral_clock_offset
to its CLKN such that the CLK corresponds to the CLKN of the Central. Although all
CLKNs in the devices run at the same nominal rate, mutual drift causes inaccuracies
in CLK. Therefore, the peripheral_clock_offset in the Peripherals must be regularly
updated such that CLK is approximately CLKN of the Central.

CLKN(central)
a) CLKR(central) + + CLK

time_base_offset peripheral_clock_offset = 0

CLKN(peripheral)
b) CLKR(peripheral) + + CLK

time_base_offset peripheral_clock_offset

Figure 2.2: Derivation of CLK in Central (a) and in Peripheral (b)

Changes in time_base_offset are only made by the Central of a piconet; a device acting
only as a Peripheral has no need to distinguish CLKR and CLKN in normal operation.
In a scatternet situation, a Controller may be changing both time_base_offset to align
its CLKN with an external clock, either collocated or at the request of a Peripheral,
and peripheral_clock_offset to maintain synchronization with a different piconet clock. In
some cases, it is not possible to determine how much of an observed offset is caused
by external frame timing alignment (time_base_offset) and how much is caused by the
offset between Central and Peripheral (peripheral_clock_offset).

2.2.5 Transmit/receive timing

The Central transmission shall always start at even numbered time slots (CLK1=0) and
the Peripheral transmission shall always start at odd numbered time slots (CLK1=1).

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 2, Part B Page 472
Baseband Specification

Due to packet types that cover more than a single slot, Central transmission may
continue in odd numbered slots and Peripheral transmission may continue in even
numbered slots, see Figure 2.1.

All timing diagrams shown in Section 2 are based on the signals as present at the
antenna. The term “exact” when used to describe timing refers to an ideal transmission
or reception and neglects timing jitter and clock frequency imperfections.

The average timing of packet transmission shall not drift faster than 20 ppm relative to
the ideal slot timing of 625 μs. The instantaneous timing shall not deviate more than
1 μs from the average timing. Thus, the absolute packet transmission timing tk of slot
boundary k shall fulfill the equation:
k
tk = ∑ 1 + di T N + jk + offset, (EQ 1)
i=1

where TN is the nominal slot length (625 μs), jk denotes jitter ( jk ≤ 1 μs) at the start
of slot k, and, dk, denotes the drift ( dk ≤ 20 ppm) within slot k. The jitter and drift can
vary arbitrarily within the given limits for every slot, while offset is an arbitrary but fixed
constant. For Hold and Sniff modes the drift and jitter parameters specified in Link
Manager Protocol [Vol 2] Part C, Section 4.3.1 apply.

2.2.5.1 Piconet physical channel timing

In the figures, only single-slot packets are shown as an example.

The Central TX/RX timing is shown in Figure 2.3. In Figure 2.3 and Figure 2.4 the
channel hopping frequencies are indicated by f(k) where k is the time slot number. After
transmission, a return packet is expected N × 625 μs after the start of the TX packet
where N is an odd, integer larger than 0. N depends on the type of the transmitted
packet.

To allow for some time slipping, an uncertainty window is defined around the exact
receive timing. During normal operation, the window length shall be 20 μs, which allows
the RX packet to arrive up to 10 μs too early or 10 μs too late. It is recommended
that Peripherals implement variable sized windows or time tracking to accommodate a
Central's absence of more than 250 ms.

During the beginning of the RX cycle, the access correlator shall search for the correct
channel access code over the uncertainty window. If an event trigger does not occur
the receiver may go to sleep until the next RX event. If in the course of the search,
it becomes apparent that the correlation output will never exceed the final threshold,
the receiver may go to sleep earlier. If a trigger event occurs, the receiver shall remain
open to receive the rest of the packet unless the packet is for another device, a non-
recoverable header error is detected, or a non-recoverable payload error is detected.

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 2, Part B Page 473
Baseband Specification

TX slot RX slot TX slot

hop f(k) hop f(k+1) hop f(k+2)

<= 426 µs ± 10 µs

625 µs

1250 µs

Figure 2.3: RX/TX cycle of Central transceiver in normal mode for single-slot packets

Each Central transmission shall be derived from bit 2 of the Central's native Bluetooth
clock, thus the current transmission will be scheduled M × 1250 μs after the start of
the previous Central TX burst where M depends on the transmitted and received packet
type and is an even, integer larger than 0. The Central TX timing shall be derived from
the Central's native Bluetooth clock, and thus it will not be affected by time drifts in the
Peripheral(s).

Peripherals maintain an estimate of the Central’s native clock by adding a timing offset
to the Peripheral’s native clock (see Section 2.2.4). This offset shall be updated each
time a packet is received from the Central. By comparing the exact RX timing of the
received packet with the estimated RX timing, Peripherals shall correct the offset for any
timing misalignments. Since only the channel access code is required to synchronize
the Peripheral, Peripheral RX timing can be corrected with any packet sent in the
Central-to-Peripheral transmission slot.

The Peripheral's TX/RX timing is shown in Figure 2.4. The Peripheral’s transmission
shall be scheduled N × 625 μs after the start of the Peripheral’s RX packet where N is
an odd, positive integer larger than 0. If the Peripheral’s RX timing drifts, so will its TX
timing. During periods when a Peripheral is in the Active mode (see Section 8.6) and is
prevented from receiving valid channel access codes from the Central due to local RF
interference, Peripheral activity in a different piconet, or any other reason, the Peripheral
may increase its receive uncertainty window and/or use predicted timing drift to increase
the probability of receiving the Central's bursts when reception resumes.

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 2, Part B Page 474
Baseband Specification

RX slot TX slot RX slot

hop f(k) hop f(k+1) hop f(k+2)

±10 µs

625 µs

1250 µs

Figure 2.4: RX/TX cycle of Peripheral transceiver in normal mode for single-slot packets

2.2.5.2 Piconet physical channel re-synchronization

In the piconet physical channel, a Peripheral can lose synchronization if it does not
receive a packet from the Central at least every 200 ms (or less if the low power clock
is used). The Central may fail to transmit to the Peripheral due to the Central being
busy with other tasks such as maintaining connections to other devices in Sniff or Hold
modes, due to SCO, eSCO, or Connectionless Peripheral Broadcast activity, due to the
Central being involved in a scatternet, or due to interference. When re-synchronizing to
the piconet physical channel a Peripheral shall listen for the Central before it may send
information (except for a Connectionless Peripheral Broadcast Receiver device which
shall listen for the Transmitter but does not send information). In this case, the length
of the synchronization search window in the Peripheral may be increased from 20 µs
to a larger value X µs as illustrated in Figure 2.5. Only RX hop frequencies are used:
the hop frequency used in the Central-to-Peripheral (RX) slot shall also be used in the
uncertainty window, even when it is extended into the preceding time interval normally
used for the Peripheral-to-Central (TX) slot.

If the length of search window, X, exceeds 1250 µs, consecutive windows shall avoid
overlapping search windows. Consecutive windows should instead be centered at f(k),
f(k+4),... f(k+4i) (where 'i' is an integer), which gives a maximum value X=2500 µs, or
even at f(k), f(k+6),...f(k+6i) which gives a maximum value X=3750 µs. The RX hop
frequencies used shall correspond to the Central-to-Peripheral transmission slots.

It is recommended that single slot packets are transmitted by the Central during
Peripheral re-synchronization.

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 2, Part B Page 475
Baseband Specification

Estimated start of Central TX

RX slot

hop g(2m-2) hop f(k) hop f(k) hop f(k+2)

X µs

625 µs

Figure 2.5: RX timing of Peripheral returning from Hold mode

2.3 Adapted piconet physical channel

For devices that enter Connectionless Peripheral Broadcast mode, the device that
transmits Connectionless Peripheral Broadcast packets is the Central of the piconet and
any device that receives Connectionless Peripheral Broadcast packets is a Peripheral of
the piconet.

2.3.1 Hopping characteristics

Each physical link on the adapted piconet physical channel shall use at least Nmin RF
channels (where Nmin is 20).

The adapted piconet physical channel uses the adapted channel hopping sequence
described in Section 2.6.

Adapted piconet physical channels can be used for connected devices that have
adaptive frequency hopping (AFH) enabled. There are two distinctions between basic
and adapted piconet physical channels. The first is the same channel mechanism that
makes the Peripheral frequency the same as the preceding Central transmission. The
second aspect is that the adapted piconet physical channel may be based on less than
the full 79 frequencies of the basic piconet physical channel. Each physical link on an
adapted piconet physical channel may use a different set of frequencies.

2.4 Page scan physical channel

Although Central and Peripheral roles are not defined prior to a connection, the term
Central is used for the paging device (that becomes a Central in the Connection state)

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 2, Part B Page 476
Baseband Specification

and Peripheral is used for the page scanning device (that becomes a Peripheral in the
Connection state).

2.4.1 Clock estimate for paging

A paging device uses an estimate of the native clock of the page scanning device,
CLKE; i.e. an offset shall be added to the CLKN of the pager to approximate the CLKN
of the recipient, see Figure 2.6. CLKE shall be derived from the native CLKN by adding
an offset. By using the CLKN of the recipient, the pager might be able to speed up the
connection establishment.

Note: CLKR is never used for deriving CLKE or for any other control of the hopping
kernel.

CLKN(pager)
CLKR(pager) + + CLKE  CLKN

Estimated
time_base_offset
Offset

Figure 2.6: Derivation of CLKE

2.4.2 Hopping characteristics

The page scan physical channel follows a slower hopping pattern than the basic piconet
physical channel and is a short pseudo-random hopping sequence through the RF
channels. The timing of the page scan channel shall be determined by the native
Bluetooth clock of the scanning device. The frequency hopping sequence is determined
by the Bluetooth address of the scanning device.

The page scan physical channel uses the page, Central page response, Peripheral
page response, and page scan hopping sequences specified in Section 2.6.

2.4.3 Paging procedure timing

During the paging procedure, the Central shall transmit paging messages (see
Table 8.3) corresponding to the Peripheral to be connected. Since the paging message
is a very short packet, the hop rate is 3200 hops per second. In a single TX slot
interval, the paging device shall transmit on two different hop frequencies. In Figure 2.7
to Figure 2.11, f(k) is used for the frequencies of the page hopping sequence and f'(k)
denotes the corresponding page response sequence frequencies. The first transmission
starts where CLK0 = 0 and the second transmission starts where CLK0 = 1.

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 2, Part B Page 477
Baseband Specification

In a single RX slot interval, the paging device shall listen for the Peripheral page
response message on two different hop frequencies. Similar to transmission, the
nominal reception starts where CLK0 = 0 and the second reception nominally starts
where CLK0 = 1; see Figure 2.7. During the TX slot, the paging device shall send the
paging message at the TX hop frequencies f(k) and f(k+1). In the RX slot, it shall listen
for a response on the corresponding RX hop frequencies f’(k) and f’(k+1). The listening
periods shall be exactly timed 625 μs after the corresponding paging packets, and shall
include a ±10 μs uncertainty window.

TX slot RX slot TX slot

hop f(k) hop f(k+1) hop f'(k) hop f'(k+1) hop f(k+2) hop f(k+3)

68 µs ±10 µs

312.5 µs
625 µs

Figure 2.7: RX/TX cycle of transceiver in Page mode

2.4.4 Page response timing

At connection setup a Central page response packet is transmitted from the Central
to the Peripheral (see Table 8.3). This packet establishes the timing and frequency
synchronization. After the Peripheral has received the page message, it shall return
a response message that consists of the Peripheral page response packet and shall
follow 625 μs after the receipt of the page message. The Central shall send the
Central page response packet in the TX slot following the RX slot in which it received
the Peripheral’s response, according to the RX/TX timing of the Central. The time
difference between the Peripheral page response and Central page response message
will depend on the timing of the page message the Peripheral received. In Figure 2.8,
the Peripheral receives the paging message sent first in the Central-to-Peripheral slot.
It then responds with a first Peripheral page response packet in the first half of the
Peripheral-to-Central slot. The timing of the Central page response packet is based
on the timing of the page message sent first in the preceding Central-to-Peripheral
slot: there is an exact 1250 μs delay between the first page message and the Central
page response packet. The packet is sent at the hop frequency f(k+1) which is the hop
frequency following the hop frequency f(k) the page message was received in.

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 2, Part B Page 478
Baseband Specification

Central-to-Peripheral slot Peripheral-to-Central slot Central-to-Peripheral slot

hop f(k) hop f(k+1) hop f'(k) hop f(k+1)

68 µs

Central

ID ID FHS

ID

hop f(k) hop f(k+1)

Peripheral

625 µs 312.5 µs

Figure 2.8: Timing of page response packets on successful page in first half slot

In Figure 2.9, the Peripheral receives the paging message sent second in the Central-
to-Peripheral slot. It then responds with a Peripheral page response packet in the
second half of the Peripheral-to-Central slot exactly 625 μs after the receipt of the page
message. The timing of the Central page response packet is still based on the timing
of the page message sent first in the preceding Central-to-Peripheral slot: there is an
exact 1250 μs delay between the first page message and the Central page response
packet. The packet is sent at the hop frequency f(k+2) which is the hop frequency
following the hop frequency f(k+1) the page message was received in.

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 2, Part B Page 479
Baseband Specification

Central-to-Peripheral slot Peripheral-to-Central slot Central-to-Peripheral slot

hop f(k) hop f(k+1) hop f'(k) hop f'(k+1) hop f(k+2)

68 μs

Central

ID ID FHS

ID

hop f(k+1) hop f(k+2)

Peripheral

625 μs

Figure 2.9: Timing of page response packets on successful page in second half slot

The Peripheral shall adjust its RX/TX timing according to the reception of the Central
page response packet (and not according to the reception of the page message). That
is, the second Peripheral page response message that acknowledges the reception of
the Central page response packet shall be transmitted 625 μs after the start of the
Central page response packet.

2.5 Inquiry scan physical channel

Although Central and Peripheral roles are not defined prior to a connection, the term
Central is used for the inquiring device and Peripheral is used for the inquiry scanning
device.

2.5.1 Clock for inquiry

The clock used for inquiry and inquiry scan shall be the device's native clock.

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 2, Part B Page 480
Baseband Specification

2.5.2 Hopping characteristics

The inquiry scan channel follows a slower hopping pattern than the piconet physical
channel and is a short pseudo-random hopping sequence through the RF channels.
The timing of the inquiry scan channel is determined by the native Bluetooth clock of the
scanning device while the frequency hopping sequence is determined by the general
inquiry access code.

The inquiry scan physical channel uses the inquiry, inquiry response, and inquiry scan
hopping sequences described in Section 2.6.

2.5.3 Inquiry procedure timing

During the inquiry procedure, the Central shall transmit inquiry messages with the
general or dedicated inquiry access code. The timing for inquiry is the same as for
paging (see Section 2.4.3).

2.5.4 Inquiry response timing

An inquiry response packet is transmitted from the Peripheral to the Central after the
Peripheral has received an inquiry message (see Table 8.5). This packet contains
information necessary for the inquiring Central to page the Peripheral (see definition of
the FHS packet in Section 6.5.1.4) and follows 625 μs after the receipt of the inquiry
message. If the Peripheral transmits an extended inquiry response packet, it shall be
transmitted 1250 μs after the start of the inquiry response packet.

In Figure 2.10 and Figure 2.11, f(k) is used for the frequencies of the inquiry hopping
sequence and f'(k) denotes the corresponding inquiry response sequence frequency.
The inquiry response packet and the extended inquiry response packet are received
by the Central at the hop frequency f'(k) when the inquiry message received by the
Peripheral was first in the Central-to-Peripheral slot.

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 2, Part B Page 481
Baseband Specification

Central-to-Peripheral slot Peripheral-to-Central slot Central-to-Peripheral slot Peripheral-to-Central slot Central-to-Peripheral slot

hop f(k) hop f(k+1) hop f ’(k) hop f ’(k)

68 µs

Central ID

hop f ’(k) hop f ’(k)

hop f(k) Extended Inquiry
FHS
Peripheral Response packet

625 µs 1250 µs

Figure 2.10: Timing of inquiry response packets on successful inquiry in first half slot

When the inquiry message received by the Peripheral was the second in the Central-to-
Peripheral slot the inquiry response packet and the extended inquiry response packet
are received by the Central at the hop frequency f'(k+1).

Central-to-Peripheral slot Peripheral-to-Central slot Central-to-Peripheral slot Peripheral-to-Central slot Central-to-Peripheral slot

hop f(k) hop f(k+1) hop f ’(k) hop f ’(k+1) hop f ’(k+1)
68 µs

Central ID

hop f ’(k+1) hop f ’(k+1)

hop f(k+1) Extended Inquiry
Peripheral FHS
Response packet

625 µs 1250 µs

Figure 2.11: Timing of inquiry response packets on successful inquiry in second half slot

2.6 Hop selection

Bluetooth devices shall use the hopping kernel as defined in the following sections.

In total, six types of hopping sequence are defined – five for the basic hop system and
one for an adapted set of hop locations used by adaptive frequency hopping (AFH).
These sequences are:

• A page hopping sequence with 32 wake-up frequencies distributed equally over the
79 MHz, with a period length of 32.

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 2, Part B Page 482
Baseband Specification

• A page response hopping sequence covering 32 response frequencies that are in a

one-to-one correspondence to the current page hopping sequence. The Central and
Peripheral use different rules to obtain the same sequence.
• An inquiry hopping sequence with 32 wake-up frequencies distributed equally over
the 79 MHz, with a period length of 32.
• An inquiry response hopping sequence covering 32 response frequencies that are in
a one-to-one correspondence to the current inquiry hopping sequence.
• A basic channel hopping sequence which has a very long period length, which does
not show repetitive patterns over a short time interval, and which distributes the hop
frequencies equally over the 79 MHz during a short time interval.
• An adapted channel hopping sequence derived from the basic channel hopping
sequence which uses the same channel mechanism and may use fewer than 79
frequencies. The adapted channel hopping sequence is only used in place of the
basic channel hopping sequence. All other hopping sequences are not affected by
hop sequence adaptation.

In addition, a set of synchronization train RF channels with 3 fixed frequencies is

defined.

2.6.1 General selection scheme

The selection scheme consists of two parts:

• selecting a sequence;
• mapping this sequence onto the hop frequencies.

The general block diagram of the hop selection scheme is shown in Figure 2.12. The
mapping from the input to a particular RF channel index is performed in the selection
box.

The inputs to the selection box are the selected clock, frozen clock, N, koffset,
interlace_offset, address, sequence selection and AFH_channel_map. The source of
the clock input depends on the hopping sequence selected. Additionally, each hopping
sequence uses different bits of the clock (see Table 2.2). N, interlace_offset, and koffset
are defined in Section 2.6.4.

The sequence selection input can be set to the following values:

• page scan
• inquiry scan
• page

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 2, Part B Page 483
Baseband Specification

• inquiry
• Central page response
• Peripheral page response
• inquiry response
• basic channel
• adapted channel

The address input consists of 28 bits as specified in Table 2.3 (see Section 2.6.4). The
hopping sequence is selected by the sequence selection input to the selection box.

When the adapted channel hopping sequence is selected, the AFH_channel_map is an

additional input to the selection box. The AFH_channel_map indicates which channels
shall be used and which shall be unused. These terms are defined in Section 2.6.3.

Sequence Selection AFH_channel_map

28
UAP/LAP

SELECTION RF channel
index
27 BOX
CLOCK

Frozen CLOCK N koffset knudge Interlace_Offset

Figure 2.12: General block diagram of hop selection scheme

The output, RF channel index, constitutes a pseudo-random sequence. The RF channel

index is mapped to RF channel frequencies using the equation in [Vol 2] Part A,
Table 2.1.

The selection scheme chooses a segment of 32 hop frequencies spanning about 64

MHz and visits these hops in a pseudo-random order. Next, a different 32-hop segment
is chosen, etc. In the page, Central page response, Peripheral page response, page
scan, inquiry, inquiry response and inquiry scan hopping sequences, the same 32-hop
segment is used all the time (the segment is selected by the address; different devices
will have different paging segments). When the basic channel hopping sequence is
selected, the output constitutes a pseudo-random sequence that slides through the 79
hops. The principle is depicted in Figure 2.13.

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 2, Part B Page 484
Baseband Specification

0 2 4 6 62 64 78 1 73 75 77

segment 1

segment 2 Δ

segment 3

segment length Δ

32 16

Figure 2.13: Hop selection scheme in Connection state

The RF frequency shall remain fixed for the duration of the packet. The RF frequency
for the packet shall be derived from the Bluetooth clock value in the first slot of
the packet. The RF frequency in the first slot after a multi-slot packet shall use
the frequency as determined by the Bluetooth clock value for that slot. Figure 2.14
illustrates the hop definition on single- and multi-slot packets.

625 µs

f(k) f(k+1) f(k+2) f(k+3) f(k+4) f(k+5) f(k+6)

f(k) f(k+3) f(k+4) f(k+5) f(k+6)

f(k) f(k+5) f(k+6)

Figure 2.14: Single- and multi-slot packets

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 2, Part B Page 485
Baseband Specification

When the adapted channel hopping sequence is used, the pseudo-random

sequence contains only frequencies that are in the RF channel set defined by the
AFH_channel_map input. The adapted sequence has similar statistical properties to
the non-adapted hop sequence. In addition, the Peripheral responds with its packet
on the same RF channel that was used by the Central to address that Peripheral (or
would have been in the case of a synchronous reserved slot without a validly received
Central-to-Peripheral transmission). This is called the same channel mechanism of
AFH. Thus, the RF channel used for the Central to Peripheral packet is also used for
the immediately following Peripheral to Central packet. An example of the same channel
mechanism is illustrated in Figure 2.15. The same channel mechanism shall be used
whenever the adapted channel hopping sequence is selected.

fk fk f k+2 f k+2 f k+6 f k+6

Central Tx
3-slot packet 5-slot packet

Peripheral Tx
3-slot packet

CLK k k+1 k+2 k+3 k+4 k+5 k+6 k+7 k+8 k+9 k+10 k+11 k+12 k+13

Figure 2.15: Example of the same channel mechanism

2.6.2 Selection kernel

The basic hop selection kernel shall be as shown in Figure 2.16 and is used for the
page, page response, inquiry, inquiry response and basic channel hopping selection
kernels. In these substates the AFH_channel_map input is unused. The adapted
channel hopping selection kernel is described in Section 2.6.3. The X input determines
the phase in the 32-hop segment, whereas Y1 and Y2 selects between Central-to-
Peripheral and Peripheral-to-Central. The inputs A to D determine the ordering within
the segment, the inputs E and F determine the mapping onto the hop frequencies. The
kernel addresses a register containing the RF channel indices. This list is ordered so
that first all even RF channel indices are listed and then all odd hop frequencies. In this
way, a 32-hop segment spans about 64 MHz.

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 2, Part B Page 486
Baseband Specification

A B C D E F
5
Y1 XOR
5 4 9 7 7
5

0
5 5 X 5 5 7
2
X ADD O PERM5 ADD
R 4
mod 32 mod 79

Y2 78
1
3

77

Figure 2.16: Block diagram of the basic hop selection kernel for the hop system

The selection procedure consists of an addition, an XOR operation, a permutation

operation, an addition, and finally a register selection. In Section 2.6.2 and Table 2.2,
the notation Ai is used for bit i of the BD_ADDR.

2.6.2.1 First addition operation

The first addition operation only adds a constant to the phase and applies a mod
32 operation. For the page hopping sequence, the first addition is redundant since it
only changes the phase within the segment. However, when different segments are
concatenated (as in the basic channel hopping sequence), the first addition operation
will have an impact on the resulting sequence.

2.6.2.2 XOR operation

In the XOR operation, the four LSBs of the output of the first addition (designated Z′
here) are XORed with the address bits A22-19, while the Z′4 bit is left unaltered. The
operation is illustrated in Figure 2.17.

A22 A21 A20 A19

Z'0 Z0
Z'1 Z1
Z'2 Z2
Z'3 Z3
Z'4 Z4

Figure 2.17: XOR operation for the hop system

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 2, Part B Page 487
Baseband Specification

2.6.2.3 Permutation operation

The permutation operation involves the switching from 5 inputs to 5 outputs for the hop
system, controlled by the control word. The permutation or switching box shall be as
shown in Figure 2.18. It consists of 7 stages of butterfly operations. The control of the
butterflies by the control signals P is shown in Table 2.1. P0-8 corresponds to D0-8, and,
Pi+9 corresponds to Ci ⊕ Y1 for i = 0…4 in Figure 2.16.

Control signal Butterfly Control signal Butterfly

P0 {Z0,Z1} P7 {Z3,Z4}
P1 {Z2,Z3} P8 {Z1,Z4}
P2 {Z1,Z2} P9 {Z0,Z3}
P3 {Z3,Z4} P10 {Z2,Z4}
P4 {Z0,Z4} P11 {Z1,Z3}
P5 {Z1,Z3} P12 {Z0,Z3}
P6 {Z0,Z2} P13 {Z1,Z2}

Table 2.1: Control of the butterflies for the hop system

The Z input is the output of the XOR operation as described in the previous section. The
butterfly operation can be implemented with multiplexers as depicted in Figure 2.19.

stage 1 2 3 4 5 6 7

P13 P12 P11 P10 P9 P8 P7 P6 P5 P4 P3 P2 P1 P0

Z0

Z1

Z2

Z3

Z4

Figure 2.18: Permutation operation for the hop system

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 2, Part B Page 488
Baseband Specification

0
1

1
0

Figure 2.19: Butterfly implementation

2.6.2.4 Second addition operation

The addition operation selects the hop frequencies to be used by the current segment
and also switches between Central-to-Peripheral and Peripheral-to-Central. It adds the
output of the current permutation (which selects a channel within the segment), a
constant, the clock bit selecting Central or Peripheral slots, and a value used to switch
each segment to a new set of channels in Connection state. The addition is applied mod
79.

2.6.2.5 Register bank

The output of the adder addresses a bank of 79 registers. The registers are loaded with
the synthesizer code words corresponding to the hop frequencies 0 to 78.

The upper half of the bank contains the even hop frequencies, whereas the lower half of
the bank contains the odd hop frequencies.

2.6.3 Adapted hop selection kernel

The adapted hop selection kernel is based on the basic hop selection kernel defined in
the preceding sections.

The inputs to the adapted hop selection kernel are the same as for the basic hop
system kernel except that the input AFH_channel_map (defined in Link Manager
Protocol [Vol 2] Part C, Section 5.2) is used. The AFH_channel_map indicates which
RF channels shall be used and which shall be unused. When hop sequence adaptation
is enabled, the number of used RF channels may be reduced from 79 to some smaller
value N. All devices shall be capable of operating on an adapted hop sequence
(AHS) with Nmin ≤ N ≤ 79, with any combination of used RF channels within the
AFH_channel_map that meets this constraint. Nmin is defined in Section 2.3.1.

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 2, Part B Page 489
Baseband Specification

Adaptation of the hopping sequence is achieved through two additions to the basic
channel hopping sequence according to Figure 2.16:

• Unused RF channels are re-mapped uniformly onto used RF channels. That is, if
the hop selection kernel of the basic system generates an unused RF channel,
an alternative RF channel out of the set of used RF channels is selected pseudo-
randomly.
• The used RF channel generated for the Central-to-Peripheral packet is also used for
the immediately following Peripheral-to-Central packet (see Section 2.6.1).

2.6.3.1 Channel re-mapping function

When the adapted hop selection kernel is selected, the basic hop selection kernel
according to Figure 2.16 is initially used to determine an RF channel. If this RF
channel is unused according to the AFH_channel_map, the unused RF channel is
re-mapped by the re-mapping function to one of the used RF channels. If the RF
channel determined by the basic hop selection kernel is already in the set of used
RF channels, no adjustment is made. The hop sequence of the (non-adapted) basic
hop equals the sequence of the adapted selection kernel on all locations where used
RF channels are generated by the basic hop. This property facilitates all Peripherals
remaining synchronized even if they are not all using the same hopping sequence.

A block diagram of the re-mapping mechanism is shown in Figure 2.20. The re-mapping
function is a post-processing step to the selection kernel from Figure 2.16, denoted as
‘Hop selection of the basic hop’. The output fk of the basic hop selection kernel is an RF
channel number that ranges between 0 and 78. This RF channel will either be in the set
of used RF channels or in the set of unused RF channels.

Hop Selection of
UAP/LAP Is fk in YES
basic hop sy stem fk
the set of used Use fk for next slot
CLK carriers?

NO

Re-mapping Function

E
Y2 k' fk'
F' ADD Use fk' instead of fk
mod N for next slot
PERM5out

Mapping Table

AFH_channel_map

Figure 2.20: Block diagram of adaptive hop selection mechanism

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 2, Part B Page 490
Baseband Specification

When an unused RF channel is generated by the basic hop selection mechanism, it is

re-mapped to the set of used RF channels as follows. A new index k’ ∈ {0, 1,..., N-1} is
calculated using some of the parameters from the basic hop selection kernel:

k’ = (PERM5out + E + F’ + Y2) mod N

where F’ is defined in Table 2.2. The index k’ is then used to select the re-mapped
channel from a mapping table that contains all of the even used RF channels in
ascending order followed by all the odd used RF channels in ascending order (i.e.,
the mapping table of Figure 2.16 with all the unused RF channels removed).

2.6.4 Control word

The control word of the kernel is controlled by the overall control signals X, Y1, Y2, A
to F, and F’ as illustrated in Figure 2.16 and Figure 2.20. During paging and inquiry,
the inputs A to E use the address values as given in the corresponding columns of
Table 2.2. In addition, the inputs X, Y1 and Y2 are used. The F and F’ inputs are
unused. The clock bits CLK6-2 (i.e., input X) specify the phase within the length 32
sequence. CLK1 (i.e., inputs Y1 and Y2) is used to select between TX and RX. The
address inputs determine the sequence order within segments. The final mapping onto
the hop frequencies is determined by the register contents.

During the Connection state (see Section 8.5), the inputs A, C and D shall be derived
from the address bits being bit-wise XORed with the clock bits as shown in the
“Connection state” column of Table 2.2 (the two most significant bits, MSBs, are XORed
together, the two second MSBs are XORed together, etc.).

(a) Page scan / (e) Page (g) Central page Connection state
(b) Generalized Interlaced (f) Inquiry response
Page Scan (h) Peripheral page
(c) Inquiry scan response
(d) Generalized Interlaced (k) Inquiry response
Inquiry Scan
X (a) CLKN16‑12 (e) Xp4-0 (g) Xprc4-0 CLK6-2
(b) (CLKN16‑12 + interlace (f) Xi4-0 (h) Xprp4-0
offset) mod 32 (k) Xir4-0
(c) Xir4-0
(d) (Xir4-0 + interlace
offset) mod 32
Y1 0 (e) CLKE1 (g) CLKE1 CLK1
(f) CLKN1 (h) CLKN1
(k) 1
Y2 32 × Y1

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 2, Part B Page 491
Baseband Specification

(a) Page scan / (e) Page (g) Central page Connection state
(b) Generalized Interlaced (f) Inquiry response
Page Scan (h) Peripheral page
(c) Inquiry scan response
(d) Generalized Interlaced (k) Inquiry response
Inquiry Scan
A A 27-23 A27-23 ⊕ CLK25-21
B A 22-19
C A 8,6,4,2,0 A8,6,4,2,0 ⊕ CLK20-16
D A 18-10 A18-10 ⊕ CLK15-7
E A 13,11,9,7,5,3,1
F 0 16 × CLK27-7 mod 79
F’ n/a 16 × CLK27-7 mod N

Table 2.2: Control for hop system

The five X input bits vary depending on the current state of the device. In the Page
Scan and Inquiry Scan substates, the native clock (CLKN) shall be used. In Connection
state the Central's clock (CLK) shall be used as input. The situation is somewhat more
complicated for the other states.

The address bits A0 to A27 depend on the sequence selection input as specified in
Table 2.3.

Sequence A23–0 A27–24

Page scan LAP of the device being paged UAP3–0 of the device being paged
Page
Central page response
Peripheral page response
Inquiry scan GIAC (0x9E8B33) DCI (0x00)
Inquiry
Inquiry response
Basic channel LAP of the Central UAP3–0 of the Central
Adapted channel

Table 2.3: Address bits for each sequence selection input

2.6.4.1 Page scan and inquiry scan hopping sequences

For the transmitted access code and in the receiver correlator, the appropriate GIAC
or DIAC shall be used. The application decides which inquiry access code to use
depending on the purpose of the inquiry.

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 2, Part B Page 492
Baseband Specification

2.6.4.2 Page hopping sequence

When the sequence selection input is set to page, the paging device shall start using
the A-train, i.e., f k − 8 , …, f k , …, f k + 7 , where f(k) is the source’s estimate
of the current receiver frequency in the paged device. The index k is a function of
all the inputs in Figure 2.16. There are 32 possible paging frequencies within each
1.28 second interval. Half of these frequencies belong to the A-train, the rest (i.e.,
f k + 8 , …, f k + 15 , f k − 16 , …, f k − 9 ) belong to the B-train. In order to achieve
the -8 offset of the A-train, a constant of 24 shall be added to the clock bits (which
is equivalent to -8 due to the mod 32 operation). The B-train is obtained by setting
the offset to 8. In the case where slots to receive the first Peripheral response are
periodically not available, an additional offset (knudge) is added to the clock bits in order
to shift the train by an integer multiple of 1.25 ms duration. A cyclic shift of the order
within the trains is also necessary in order to avoid a possible repetitive mismatch
between the paging and scanning devices. Thus,

Xp = CLKE16 − 12 + koffset + knudge +

(EQ 2)
CLKE4 − 2, 0 − CLKE16 − 12 + 32 mod 16 mod 32,
where

24 A‐train,
koffset = (EQ 3)
8 B‐train.

0 During 1st 2×Npage repetitions

knudge = (EQ 4)
Even During all other repetitions.
Alternatively, each switch between the A- and B-trains may be accomplished by adding
16 to the current value of koffset (originally initialized with 24).

2.6.4.3 Peripheral page response hopping sequence

When the sequence selection input is set to Peripheral page response, in order to
eliminate the possibility of losing the link due to discrepancies of the native clock CLKN
and the Central’s clock estimate CLKE, the five bits CLKN16-12 shall be frozen at their
current value. The value shall be frozen at the content it has in the slot where the
recipient’s access code is detected. The native clock shall not be stopped; it is merely
the values of the bits used for creating the X-input that are kept fixed for a while. A
frozen value is denoted by an asterisk (*) in the discussion below.

For each response slot the paged device shall use an X-input value one larger (mod 32)
than in the preceding response slot. However, the first response shall be made with the
X-input kept at the same value as it was when the access code was recognized. Let N
be a counter starting at zero. Then, the X-input in the (N + 1) -th response slot (the first

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 2, Part B Page 493
Baseband Specification

response slot being the one immediately following the page slot now responding to) of
the Peripheral Page Response substate is:

Xprp = CLKN*16 − 12 + N mod 32, (EQ 5)

The counter N shall be set to zero in the slot where the Peripheral acknowledges the
page (see Figure 8.3 and Figure 8.4). Then, the value of N shall be increased by one
each time CLKN1 is set to zero, which corresponds to the start of a Central TX slot.
The X-input shall be constructed this way until the first FHS packet is received and the
immediately following response packet has been transmitted. After this the Peripheral
shall enter the Connection state using the parameters received in the FHS packet.

2.6.4.4 Central page response hopping sequence

When the sequence selection input is set to Central page response, the Central shall
freeze its estimate of the Peripheral's clock to the value that triggered a response
from the paged device. It is equivalent to using the values of the clock estimate when
receiving the Peripheral’s response (since only CLKE1 will differ from the corresponding
page transmission). Thus, the values are frozen when the Peripheral’s ID packet is
received. In addition to the clock bits used, the current values of koffset and knudge shall
also be frozen. The Central shall adjust its X-input in the same way the paged device
does, i.e., by incrementing this value by one for each time CLKE1 is set to zero. The first
increment shall be done before sending the FHS packet to the paged device. Let N be a
counter starting at one. The rule for forming the X-input is:

Xprc = CLKE*16 − 12+k*offset+k*nudge+

(EQ 6)
CLKE*4 − 2, 0−CLKE*16 − 12 mod 16 + N mod 32,
The value of N shall be increased each time CLKE1 is set to zero, which corresponds to
the start of a Central TX slot.

2.6.4.5 Inquiry hopping sequence

When the sequence selection input is set to inquiry, the X-input is similar to that used
in the page hopping sequence. Since no particular device is addressed, the native clock
CLKN of the inquirer shall be used. Moreover, which of the two train offsets to start with
is of no real concern in this state. Consequently,

Xi = CLKN16 − 12 + koffset + knudge +

(EQ 7)
CLKN4 − 2, 0 − CLKN16 − 12 mod 16] mod 32
where koffset and knudge are defined by (EQ 3) and (EQ 4).

The initial choice of koffset is arbitrary.

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 2, Part B Page 494
Baseband Specification

2.6.4.6 Inquiry response hopping sequence

The inquiry response hopping sequence is similar to the Peripheral page response
hopping sequence with respect to the X-input. The clock input shall not be frozen, thus
the following equation applies:

Xir = CLKN16 − 12 + N mod 32, (EQ 8)

Furthermore, the counter N is increased not on CLKE1 basis, but rather after each FHS
packet has been transmitted in response to the inquiry. There is no restriction on the
initial value of N as it is independent of the corresponding value in the inquiring unit.

The Xir value used for the extended inquiry response packet shall be the same Xir value
as calculated for the immediately preceding FHS packet.

2.6.4.7 Basic and adapted channel hopping sequence

In the basic and adapted channel hopping sequences, the clock bits to use in the basic
or adapted hopping sequence generation shall always be derived from the Central's
clock, CLK.

2.6.4.8 Synchronization train RF channels

The synchronization train and synchronization scan use RF channels from the set of
three fixed RF channels with indices 0, 24, and 78.

2.7 Synchronization scan physical channel

The synchronization scan physical channel enables devices to receive synchronization
train packets.

2.7.1 Hopping characteristics

When a device enters the Synchronization Scan substate, it shall scan the
synchronization train RF channels using the timing defined in Section 2.7.3. Each
individual scan window shall use a different RF channel than the previous two scan
windows.

The synchronization scan physical channel shall use all of the synchronization train RF
channels defined in Section 2.6.4.8.

2.7.2 Synchronization Train procedure timing

The Central shall use the synchronization train procedure only when Connectionless
Peripheral Broadcast mode is enabled or during the Coarse Clock Adjustment Recovery
Mode (Section 8.6.10.2); these can happen concurrently. During the synchronization
train procedure, the Central shall attempt to transmit synchronization train packets on

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 2, Part B Page 495
Baseband Specification

all of the RF channels specified in Section 2.6.4.8. The transmission of synchronization

train packets on each RF channel is independent of the transmission on other RF
channels. For each RF channel, the Central shall:

1. Establish synchronization train events that are separated by TSync_Train_Interval slots.

During Coarse Clock Adjustment Recovery Mode the value of TSync_Train_Interval
shall be 32. At all other times, it shall be the value selected by the Controller from a
range provided by the Host ([Vol 4] Part E, Section 7.3.90).
2. Attempt to send a synchronization train packet between each pair of
synchronization train events.
3. In the absence of scheduling conflicts, delay the start of the synchronization
train packet transmission by TSync_Train_Delay slots from the synchronization train
event, where TSync_Train_Delay is a (pseudo-)random number between 0 and
TSync_Train_Delay_Max. Each value of TSync_Train_Delay shall be an even integer.
TSync_Train_Delay_Max shall equal 4 slots during Coarse Clock Adjustment Recovery
Mode and 16 slots at all other times. Each synchronization packet transmission
shall start at the beginning of a time slot where CLK[1:0]=0b00.
4. If the transmission of the synchronization train packet conflicts with the timing of
higher priority packets, the actual delay may be adjusted to avoid the conflict.
The actual delay should stay within the range 0 to TSync_Train_Delay_Max and shall
not be greater than or equal to TSync_Train_Interval. If it is not possible to transmit
the complete packet before the next synchronization train event, it shall not be
transmitted.
Increasing the delay beyond the recommended range (0 to TSync_Train_Delay_Max)
increases the chance that the scanning device will miss the packet.
5. There shall be no more than one synchronization train packet transmitted between
any two consecutive synchronization train events.
6. The actual delays used shall not all be the same for any three consecutive
synchronization train packets (though any two may be).

Note: Subject to the above requirements, synchronization train events on different RF

channels may be managed separately or may be co-ordinated using the same value of
TSync_Train_Delay.

Figure 2.21 shows the timing relationship of consecutive synchronization train packets
on a single RF channel.

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 2, Part B Page 496
Baseband Specification

Synchronization train event

TSync_Train_Delay_Max TSync_Train_Delay_Max

TSync_Train_Delay TSync_Train_Delay

TSync_Train_Interval

Figure 2.21: Synchronization train packet timing on a single channel

2.7.3 Synchronization Scan procedure timing

During the Synchronization Scan procedure, a device performs synchronization scans

on the synchronization train RF channels. During each scan window, the device listens
for the duration of TSync_Scan_Window. The RF channel for each scan window shall
be selected as specified in Section 2.7.1. Each scan window should be continuous
and not interrupted by other activities. The interval between the start of consecutive
scan windows shall be equal to TSync_Scan_Interval. The values for TSync_Scan_Window and
TSync_Scan_Interval shall be chosen as follows:

• During Connectionless Peripheral Broadcast, refer to [Vol 4] Part E, Section 7.1.52.

• During Coarse Clock Adjustment Recovery Mode, the values chosen are
implementation specific.

This timing relationship is shown in Figure 2.22.

≤ TSync_Scan_Interval ≤ TSync_Scan_Interval

TSync_Scan_Window TSync_Scan_Window TSync_Scan_Window

f1 f2 f3

scan scan scan

Figure 2.22: Synchronization scan timing

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 2, Part B Page 497
Baseband Specification

3 PHYSICAL LINKS

A physical link represents a Baseband connection between devices. A physical link

is always associated with exactly one physical channel. Physical links have common
properties that apply to all logical transports on the physical link.

Other than the Connectionless Peripheral Broadcast physical link, common properties
of physical links are:

• Power control (see [Vol 2] Part C, Section 4.1.3)

• Link supervision (see Section 3.1 and [Vol 2] Part C, Section 4.1.6)
• Encryption (see [Vol 2] Part H, Section 4 and [Vol 2] Part C, Section 4.2.5)
• Channel quality-driven data rate change (see [Vol 2] Part C, Section 4.1.7)
• Multi-slot packet control (see [Vol 2] Part C, Section 4.1.10)

and for physical links on the adapted piconet physical channel:

• AFH channel map (see Section 2.3 and [Vol 2] Part C, Section 4.1.4)

The Connectionless Peripheral Broadcast physical link is associated with the BR/EDR
adapted piconet physical channel, a single logical transport (the CPB logical transport),
and does not support the Link Manager protocol. For information on link supervision on
Connectionless Peripheral Broadcast physical links, see Section 3.2. Multi-slot packets
on Connectionless Peripheral Broadcast physical links are controlled by the Host and
specified at the profile level.

3.1 Link supervision for active physical links

A connection can break down due to various reasons such as a device moving out
of range, encountering severe interference or a power failure condition. Since this can
happen without any prior warning, it is important to monitor the link on both the Central
and the Peripheral side to avoid possible collisions when the logical transport address
(see Section 4.2) is reassigned to another Peripheral.

To be able to detect link loss, both the Central and the Peripheral shall use a link
supervision timer, T supervision. Upon reception of a valid packet header with one of
the Peripheral's addresses (see Section 4.2) on the physical link, the timer shall be
reset. If at any time in Connection state, the timer reaches the supervisionTO value, the
connection shall be considered disconnected. The same link supervision timer shall be
used for SCO, eSCO, and ACL logical transports.

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 2, Part B Page 498
Baseband Specification

The timeout period, supervisionTO, is negotiated by the Link Manager. Its value shall be
chosen so that the supervision timeout will be longer than hold and sniff periods.

3.2 Link supervision for Connectionless Peripheral Broadcast

physical links
For Connectionless Peripheral Broadcast physical links, only the Receiver side
monitors the link. To detect link loss, the Receiver shall use a link supervision timer,
TCPB_Supervision. Each Connectionless Peripheral Broadcast Receiver shall reset the
timer upon reception of a Connectionless Peripheral Broadcast packet with a valid
packet header. If at any time in Connectionless Peripheral Broadcast mode of the
Connection state, the timer reaches the CPB_supervisionTO value, the connection shall
be considered disconnected.

For each Receiver, the timeout period, CPB_supervisionTO, can be provided by the
Host (see Section B.1.7).

3.3 Authenticated payload timeout for active links

For active physical links, when encryption is enabled and AES-CCM is used, a device
monitors the time between receiving packets from the remote device containing a MIC.
To ensure the integrity of the link, an Authenticated Payload timer, TAuthenticated_Payload, is
used. Each device shall reset the timer upon reception of a packet with a valid MIC. The
timer shall not be reset upon the reception of a retransmitted packet. If at any time in the
Connection state, the timer reaches the authenticatedPayloadTO value, the Host shall
be notified. The timeout period, authenticatedPayloadTO, shall be provided by the Host.

The device shall reset the timer each time after the Host is notified. The Controller shall
reset the timer when the Host writes the authenticatedPayloadTO value.

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 2, Part B Page 499
Baseband Specification

4 LOGICAL TRANSPORTS

4.1 General

Between Central and Peripheral(s), different types of logical transports may be

established. Five logical transports have been defined:

• Synchronous Connection-Oriented (SCO) logical transport

• Extended Synchronous Connection-Oriented (eSCO) logical transport
• Asynchronous Connection-Oriented (ACL) logical transport
• Active Peripheral Broadcast (APB) logical transport
• Connectionless Peripheral Broadcast (CPB) logical transport.

The synchronous logical transports are point-to-point logical transports between a

Central and a single Peripheral in the piconet. The synchronous logical transports
typically support time-bounded information like voice or general synchronous data. The
Central maintains the synchronous logical transports by using reserved slots at regular
intervals. In addition to the reserved slots the eSCO logical transport may have a
retransmission window after the reserved slots.

The ACL logical transport is also a point-to-point logical transport between the Central
and a Peripheral. In the slots not reserved for synchronous logical transport(s), the
Central can establish an ACL logical transport on a per-slot basis to any Peripheral,
including the Peripheral(s) already engaged in a synchronous logical transport.

The APB logical transport is used by a Central to communicate with active Peripherals.

The CPB logical transport is used by a Central to send profile broadcast data to zero or
more Peripherals.

4.2 Logical transport address (LT_ADDR)

Each Peripheral active in a piconet is assigned a primary 3-bit logical transport address
(LT_ADDR). The all-zero LT_ADDR is reserved for APB broadcast messages. The
CPB logical transport uses a single non-zero LT_ADDR. The Central does not have
an LT_ADDR. A Central's timing relative to the Peripherals’ distinguishes it from the
Peripherals. A secondary LT_ADDR is assigned to the Peripheral for each eSCO logical
transport in use in the piconet. The secondary LT_ADDR shall not be 0. Only eSCO
traffic (i.e. NULL, POLL, and one of the EV packet types as negotiated at eSCO logical
transport setup) may be sent on these LT_ADDRs. ACL traffic (including LMP) shall
always be sent on the primary LT_ADDR. A Peripheral shall only accept packets with

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 2, Part B Page 500
Baseband Specification

matching primary or secondary LT_ADDR and broadcast packets. The LT_ADDR is

carried in the packet header (see Section 6.4). The LT_ADDR shall only be valid for as
long as a Peripheral is connected. As soon as it is disconnected, the Peripheral shall
lose all of its LT_ADDRs.

The primary LT_ADDR shall be assigned by the Central to the Peripheral when the
Peripheral is activated. This is either at connection establishment or role switch, when
the primary LT_ADDR is carried in the FHS payload.

At any given time an LT_ADDR (other than the special case of the all-zero LT_ADDR)
is either unused or is used for exactly one of the three purposes of the primary address
for a Peripheral, a secondary address for eSCO traffic, or for a CPB logical transport.
Therefore allocating a secondary LT_ADDR for an eSCO logical transport, or reserving
an LT_ADDR for the CPB logical transport, reduces the maximum number of active
Peripherals possible in the piconet.

4.3 Synchronous logical transports

The first type of synchronous logical transport, the SCO logical transport, is a
symmetric, point-to-point transport between the Central and a specific Peripheral. The
SCO logical transport reserves slots and can therefore be considered as a circuit-
switched connection between the Central and the Peripheral. The Central may support
up to three SCO links to the same Peripheral or to different Peripherals. A Peripheral
may support up to three SCO links from the same Central, or two SCO links if the links
originate from different Centrals. SCO packets are never retransmitted.

The second type of synchronous logical transport, the eSCO logical transport, is a point-
to-point logical transport between the Central and a specific Peripheral. eSCO logical
transports may be symmetric or asymmetric. Similar to SCO, eSCO reserves slots
and can therefore be considered a circuit-switched connection between the Central
and the Peripheral. In addition to the reserved slots, eSCO supports a retransmission
window immediately following the reserved slots. Together, the reserved slots and the
retransmission window form the complete eSCO window.

4.4 Asynchronous logical transport

In the slots not reserved for synchronous logical transports, the Central may exchange
packets with any Peripheral on a per-slot basis. The ACL logical transport provides a
packet-switched connection between the Central and all active Peripherals participating
in the piconet. Both asynchronous and isochronous services are supported. Only
a single ACL logical transport shall exist between any two devices. For most ACL
packets, packet retransmission is applied to assure data integrity.

ACL packets not addressed to a specific Peripheral (LT_ADDR=0) are considered as

broadcast packets and should be received by every Peripheral except Peripherals with

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 2, Part B Page 501
Baseband Specification

only a CPB logical transport. If there is no data to be sent on the ACL logical transport
and no polling is required, no transmission is required.

4.5 Transmit/receive routines

This section describes the way to use the packets as defined in Section 6 in order to
support the traffic on the ACL, SCO and eSCO logical transports. Both single-Peripheral
and multi-Peripheral configurations are considered. In addition, the use of buffers for the
TX and RX routines are described.

4.5.1 TX routine

The TX routine is carried out separately for each asynchronous and synchronous logical
transport. Figure 4.1 shows the asynchronous and synchronous buffers as used in
the TX routine. In this figure, only a single TX asynchronous buffer and a single TX
synchronous buffer are shown. In the Central, there is a separate TX asynchronous
buffer for each Peripheral. In addition there can be one or more TX synchronous buffers
for each synchronous Peripheral (different SCO or eSCO logical transports could either
reuse the same TX synchronous buffer, or each have their own TX synchronous buffer).
Each TX buffer consists of two FIFO registers: one current register which can be
accessed and read by the Link Controller in order to compose the packets, and one
next register that can be accessed by the Baseband Resource Manager to load new
information. The positions of the switches S1 and S2 determine which register is current
and which register is next; the switches are controlled by the Link Controller. The
switches at the input and the output of the FIFO registers can never be connected to the
same register simultaneously.

TX asynchronous buffer

current/next data FIFO

asynchronous
S1a S1b
I/O port
next/current data FIFO

packet
composer
TX synchronous buffer

current/next voice FIFO

synchronous
S2a S2b
I/O port
next/current voice FIFO

Figure 4.1: Functional diagram of TX buffering

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 2, Part B Page 502
Baseband Specification

Of the packets common to the ACL and SCO logical transports (NULL, POLL and
DM1), only the DM1 packet carries a payload that is exchanged between the Link
Controller and the Link Manager; this packet makes use of the asynchronous buffer.
All ACL packets make use of the asynchronous buffer. All SCO and eSCO packets
make use of the synchronous buffer except for the DV packet where the synchronous
data part is handled by the synchronous buffer and the data part is handled by
the asynchronous buffer. In the next sections, the operation for ACL traffic, SCO
traffic, eSCO traffic, and combined data-voice traffic on the SCO logical transport are
described.

4.5.1.1 ACL traffic

In the case of asynchronous data only the TX ACL buffer in Figure 4.1 has to be
considered. In this case, only packet types DM or DH are used, and these can have
different lengths. The length is indicated in the payload header. The selection of DM or
DH packets should depend on the quality of the link. See [Vol 2] Part C, Section 4.1.7.

The default packet type in pure data traffic is NULL (see Section 6.5.1.2). This means
that, if there is no data to be sent (the data traffic is asynchronous, and therefore
pauses occur in which no data is available) or no Peripherals need to be polled, NULL
packets are sent instead – in order to send link control information to the other device
(e.g. ACK/STOP information for received data). When no link control information is
available (either no need to acknowledge and/or no need to stop the RX flow) no packet
is sent at all.

The TX routine works as follows. The Baseband Resource Manager loads new data
information in the register to which the switch S1a points. Next, it gives a command to
the Link Controller, which forces the switch S1 to change (both S1a and S1b switch
synchronously). When the payload needs to be sent, the packet composer reads the
current register and, depending on the packet type, builds a payload which is appended
to the channel access code and the header and is subsequently transmitted. In the
response packet (which arrives in the following RX slot if it concerned a Central
transmission, or may be postponed until some later RX slot if it concerned a Peripheral
transmission), the result of the transmission is reported back. In case of an ACK, the
switch S1 changes position; if a NAK (explicit or implicit) is received instead, the switch
S1 will not change position. In that case, the same payload is retransmitted at the next
TX occasion.

As long as the Baseband Resource Manager keeps loading the registers with new
information, the Link Controller will automatically transmit the payload; in addition,
retransmissions are performed automatically in case of errors. The Link Controller will
send NULL or nothing when no new data is loaded. If no new data has been loaded
in the next register, during the last transmission, the packet composer will be pointing
to an empty register after the last transmission has been acknowledged and the next

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 2, Part B Page 503
Baseband Specification

register becomes the current register. If new data is loaded in the next register, a Flush
command is required to switch the S1 switch to the proper register. As long as the
Baseband Resource Manager keeps loading the data and type registers before each TX
slot, the data is automatically processed by the Link Controller since the S1 switch is
controlled by the ACK information received in response. However, if the traffic from the
Baseband Resource Manager is interrupted once and a default packet is sent instead, a
Flush command is necessary to continue the flow in the Link Controller.

The Flush command may also be used in case of time-bounded (isochronous) data.
In case of a bad link, many retransmissions are necessary. In certain applications, the
data is time-bounded: if a payload is retransmitted all the time because of link errors, it
may become outdated, and the system might decide to continue with more recent data
instead and skip the payload that does not come through. This is accomplished by the
Flush command as well. With the flush, the switch S1 is forced to change and the Link
Controller is forced to consider the next data payload and overrules the ACK control.
Any ACL type of packet can be used to send data or link control information to any other
ACL Peripheral.

4.5.1.2 SCO traffic

On the SCO logical transport only HV and DV packet types are used, See Section 6.5.2.
The synchronous port may continuously load the next register in the synchronous
buffer. The S2 switches are changed according to the Tsco interval. This Tsco interval is
negotiated between the Central and the Peripheral at the time the SCO logical transport
is established.

For each new SCO slot, the packet composer reads the current register after which the
S2 switch is changed. If the SCO slot has to be used to send control information with
high priority concerning a control packet between the Central and the SCO Peripheral,
or a control packet between the Central and any other Peripheral, the packet composer
will discard the SCO information and use the control information instead. This control
information shall be sent in a DM1 packet. Data or link control information may also
be exchanged between the Central and the SCO Peripheral by using the DV or DM1
packets.

4.5.1.3 Mixed data/voice traffic

In Section 6.5.2, a DV packet has been defined that can support both data and voice
simultaneously on a single SCO logical transport. When the TYPE is DV, the Link
Controller reads the data register to fill the data field and the voice register to fill
the voice field. Thereafter, the switch S2 is changed. However, the position of S1
depends on the result of the transmission as on the ACL logical transport: only if an
ACK has been received will the S1 switch change its position. In each DV packet,
the voice information is new, but the data information might be retransmitted if the
previous transmission failed. If there is no data to be sent, the SCO logical transport will

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 2, Part B Page 504
Baseband Specification

automatically change from DV packet type to the current HV packet type used before
the mixed data/voice transmission.

A Flush command is necessary when the data stream has been interrupted and new
data has arrived.

Combined data-voice transmission can also be accomplished by using a separate ACL

logical transport in addition to the SCO logical transport(s) if channel capacity permits
this.

4.5.1.4 eSCO traffic

On the eSCO logical transport only EV, POLL and NULL packet types are used, see
Section 6.5.3. The synchronous port may continuously load the next register in the
synchronous buffer. The S2 switches are changed according to the TeSCO interval. This
TeSCO interval is negotiated between the Central and the Peripheral at the time the
eSCO logical transport is established.

For each new eSCO slot, the packet composer reads the current register after which the
S2 switch is changed. If the eSCO slot has to be used to send control information with
high priority concerning a control packet between the Central and the eSCO Peripheral,
or an ACL packet between the Central and any other Peripheral, the packet composer
will discard the eSCO information and use the control information instead. Control
information to the eSCO Peripheral is sent in a DM1 packet on the primary LT_ADDR.

4.5.1.5 Default packet types

On the ACL links, the default type is always NULL both for the Central and the
Peripheral. This means that if no user information needs to be sent, either a NULL
packet is sent if there is ACK or STOP information, or no packet is sent at all. The
NULL packet can be used by the Central to allocate the next Peripheral-to-Central
slot to a certain Peripheral (namely the one addressed). However, the Peripheral is
not forced to respond to the NULL packet from the Central. If the Central requires a
response, it sends a POLL packet.

The SCO and eSCO packet types are negotiated at the LM level when the SCO or
eSCO logical transport is established. The agreed packet type is also the default packet
type for the reserved SCO or eSCO slots.

4.5.2 RX routine

The RX routine is carried out separately for the ACL logical transport and the
synchronous logical transports. However, in contrast to the Central TX asynchronous
buffer, a single RX buffer is shared among all Peripherals. For the synchronous buffer,
how the different synchronous logical transports are distinguished depends on whether

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 2, Part B Page 505
Baseband Specification

extra synchronous buffers are required or not. Figure 4.2 shows the asynchronous and
synchronous buffers as used in the RX routine. The RX asynchronous buffer consists of
two FIFO registers: one register that can be accessed and loaded by the Link Controller
with the payload of the latest RX packet, and one register that can be accessed by the
Baseband Resource Manager to read the previous payload. The RX synchronous buffer
also consists of two FIFO registers: one register which is filled with newly arrived voice
information, and one register which can be read by the voice processing unit.

RX asynchronous buffer

current/next data FIFO

asynchronous
S1a S1b
I/O port
packet de-composer

next/current data FIFO

RX synchronous buffer

current/next voice FIFO

synchronous
S2a S2b
I/O port
next/current voice FIFO

Figure 4.2: Functional diagram of RX buffering

Since the TYPE indication in the header (see Section 6.4.2) of the received packet
indicates whether the payload contains data and/or voice, the packet de-composer can
automatically direct the traffic to the proper buffers. The switch S1 changes every time
the Baseband Resource Manager reads the old register. If the next payload arrives
before the RX register is emptied, a STOP indication is included in the packet header
of the next TX packet that is returned. The STOP indication is removed again as soon
as the RX register is emptied. The SEQN field is checked before a new ACL payload is
stored into the asynchronous register (flush indication in LLID and broadcast messages
influence the interpretation of the SEQN field see Section 7.6).

The S2 switch is changed every TSCO or TeSCO for SCO and eSCO respectively. If, due
to errors in the header, no new synchronous payload arrives, the switch still changes.
The synchronous data processing unit then processes the synchronous data to account
for the missing parts.

4.5.3 Flow control

Since the RX ACL buffer can be full while a new payload arrives, flow control is
required. The header field FLOW in the return TX packet may use STOP or GO in
order to control the transmission of new data.

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 2, Part B Page 506
Baseband Specification

4.5.3.1 Destination control

As long as data cannot be received, a STOP indication shall be transmitted which

is automatically inserted by the Link Controller into the header of the return packet.
STOP shall be returned as long as the RX ACL buffer is not emptied by the Baseband
Resource Manager. When new data can be accepted again, the GO indication shall be
returned. GO shall be the default value. All packet types not including data can still be
received. Voice communication for example is not affected by the flow control. Although
a device can-not receive new information, it may still continue to transmit information:
the flow control shall be separate for each direction.

4.5.3.2 Source control

On the reception of a STOP signal, the Link Controller shall automatically switch to the
default packet type. The ACL packet transmitted just before the reception of the STOP
indication shall be kept until a GO signal is received. It may be retransmitted as soon
as a GO indication is received. Only default packets shall be sent as long as the STOP
indication is received. When no packet is received, GO shall be assumed implicitly. The
default packets contain link control information (in the header) for the receive direction
(which may still be open) and may contain synchronous data (HV or EV packets). When
a GO indication is received, the Link Controller may resume transmitting the data that is
present in the TX ACL buffers.

In a multi-Peripheral configuration, only the transmission to the Peripheral that issued

the STOP signal shall be stalled. This means that the Central shall only stop
transmission from the TX ACL buffer corresponding to the Peripheral that momentarily
cannot accept data.

4.6 Active Peripheral broadcast transport

The Active Peripheral Broadcast logical transport is used to transport L2CAP user traffic
and certain LMP traffic to all devices in the piconet that are currently connected to the
piconet 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 logical transport is unreliable. To improve reliability somewhat 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 the reserved, all-zero, LT_ADDR. Packets on
the APB logical transport may be sent by the Central at any time.

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 2, Part B Page 507
Baseband Specification

4.7 [This section is no longer used]

4.8 Connectionless Peripheral Broadcast logical transport

The CPB logical transport is used to transport profile broadcast data from a Transmitter
(Central) to multiple Receivers (Peripherals). There is no acknowledgment scheme and
the traffic is unidirectional.

Note: The CPB logical transport is not used for L2CAP connection-oriented channels,
L2CAP control signaling, or LMP control signaling.

The CPB logical transport is unreliable. To improve reliability each packet payload may
be transmitted a number of times.

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 2, Part B Page 508
Baseband Specification

5 LOGICAL LINKS

The following logical links are defined:

• Link Control (LC)

• ACL Control (ACL-C and APB-C)
• User Asynchronous/Isochronous (ACL-U and APB-U)
• User Synchronous (SCO-S)
• User Extended Synchronous (eSCO-S)
• Profile Broadcast Data (PBD)

The control logical link LC is used at the link control level. The ACL-C and APB-C
logical links are used at the link manager level. The ACL-U and APB-U logical links
are used to carry either asynchronous or isochronous user information. The SCO-S,
and eSCO-S logical links are used to carry synchronous user information. The PBD
logical link is used to carry profile broadcast data. The LC logical link is carried in the
packet header, all other logical links are carried in the packet payload. The ACL-C,
ACL-U, APB-C, and APB-U logical links are indicated in the logical link ID, LLID,
field in the payload header. The SCO-S and eSCO-S logical links are carried by the
synchronous logical transports only; the ACL-U link is normally carried by the ACL
logical transport; however, it may also be carried by the data in the DV packet on the
SCO logical transport. The ACL-C link may be carried either by the SCO or the ACL
logical transport. The APB-C and APB-U links are carried by the APB logical transport.
The PBD logical link is carried by the CPB logical transport.

5.1 Link Control logical link (LC)

The LC control logical link shall be mapped onto the packet header. This logical
link carries low level link control information like ARQ, flow control, and payload
characterization. The LC logical link is carried in every packet except in the ID packet
which does not have a packet header.

5.2 ACL Control logical links (ACL-C and APB-C)

The ACL-C and APB-C logical links shall carry control information exchanged between
the link managers of the Central and the Peripheral(s). The ACL-C logical link shall use
DM1 or DV packets. DV packets shall only be used on the ACL-C link if the ACL-C
message is less than or equal to 9 bytes and an HV1 synchronous logical transport is in
use. The APB-C logical link shall use DM1 packets. The ACL-C and APB-C logical links
are indicated by the LLID code 0b11 in the payload header.

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 2, Part B Page 509
Baseband Specification

5.3 User asynchronous/isochronous logical links (ACL‑U and

APB‑U)
The ACL-U and APB-U logical links shall carry L2CAP asynchronous and isochronous
user data. These messages may be transmitted in one or more Baseband packets.
For fragmented messages, the start packet shall use an LLID code of 0b10 in the
payload header. Remaining continuation packets shall use LLID code 0b01. If there is
no fragmentation, all packets shall use the LLID start code 0b10.

For each logical link, the Controller shall transmit data over the air in the same order
that it is received from the Host. The boundaries between packets over the air for a
specific L2CAP PDU may be different from the boundaries in the data provided by the
Host. Each new L2CAP PDU shall start a new packet over the air. (See [Vol 3] Part A,
Section 7.2.1 for related requirements in L2CAP.)

For each logical link, the Controller shall transmit the data received over the air to
the Host (whether over HCI or otherwise) in the same order that it was received. The
boundaries in the data sent to the Host for a specific L2CAP PDU may be different
from the boundaries between packets received over the air. The Controller shall retain
boundaries between L2CAP PDUs. Data from different logical links may be interleaved.
(See [Vol 3] Part A, Section 7.2.2 for related requirements in L2CAP.)

5.3.1 Pausing the ACL-U logical link

When paused by the LM, the Link Controller transmits the current packet with ACL-U
information, if any, until an ACK is received. While the ACL-U logical link is paused, the
Link Controller shall not transmit any (more) packets with ACL-U logical link information.

When the ACL-U logical link is resumed by the LM, the Link Controller may resume
transmitting packets with ACL-U information.

5.4 User synchronous data logical link (SCO-S)

The SCO-S logical link carries transparent synchronous user data. This logical link is
carried over the synchronous logical transport SCO.

5.5 User extended synchronous data logical link (eSCO-S)

The eSCO-S logical link also carries transparent synchronous user data. This logical
link is carried over the extended synchronous logical transport eSCO.

5.6 Logical link priorities

The ACL-C logical link shall have a higher priority than the ACL-U logical link when
scheduling traffic on the shared ACL logical transport, except in the case when

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 2, Part B Page 510
Baseband Specification

retransmissions of unacknowledged ACL packets shall be given priority over traffic on

the ACL-C logical link. The APB-C logical link shall have a higher priority than the
APB-U logical link when scheduling traffic on the shared APB logical transport. The
ACL-C logical link should also have priority over traffic on the SCO-S and eSCO-S
logical links but opportunities for interleaving the logical links should be taken. The
ACL-C, SCO-S, and eSCO-S logical links should have priority over traffic on the PBD
logical link.

5.7 Profile broadcast data logical link

The PBD logical link carries profile broadcast data. Messages shall not be fragmented
and shall always use LLID start code 0b10.

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 2, Part B Page 511
Baseband Specification

6 PACKETS

Bluetooth devices shall use the packets as defined in the following sections.

6.1 General format

6.1.1 Basic Rate

The general packet format of Basic Rate packets is shown in Figure 6.1. Each packet
consists of 3 entities: the access code, the header, and the payload. In the figure, the
number of bits per entity is indicated.

LSB 68/72 54 0 - 2790 MSB

ACCESS
HEADER PAYLOAD
CODE

Figure 6.1: General Basic Rate packet format

The access code is 72 or 68 bits and the header is 54 bits. The payload ranges from
zero to a maximum of 2790 bits. Different packet types have been defined. A packet
may consist of:

• the shortened access code only (see Section 6.5.1.1)

• the access code and the packet header
• the access code, the packet header and the payload.

6.1.2 Enhanced Data Rate

The general format of Enhanced Data Rate packets is shown in Figure 6.2. The
access code and packet header are identical in format and modulation to Basic
Rate packets. Enhanced Data Rate packets have a guard time and synchronization
sequence following the packet header. Following the payload are two trailer symbols.
The guard time, synchronization sequence and trailer are defined in Section 6.6.

LSB MSB

ACCESS ENHANCED DATA RATE

HEADER GUARD SYNC TRAILER
CODE PAYLOAD

GFSK DPSK

Figure 6.2: General Enhanced Data Rate packet format

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 2, Part B Page 512
Baseband Specification

6.2 Bit ordering

The bit ordering when defining packets and messages in the Baseband Specification,
follows the little-endian format. The following rules apply:

• The least significant bit (LSB) corresponds to b0;

• The LSB is the first bit sent over the air;
• In illustrations, the LSB is shown on the left side;

Furthermore, data fields generated internally at Baseband level, such as the packet
header fields and payload header length, shall be transmitted with the LSB first. For
instance, a 3-bit parameter X=3 is sent as:

b0b1b2 = 110

over the air where 1 is sent first and 0 is sent last.

6.3 Access code

Every packet starts with an access code. If a packet header follows, the access code
is 72 bits long, otherwise the access code is 68 bits long and is known as a shortened
access code. The shortened access code does not contain a trailer. This access code
is used for synchronization, DC offset compensation and identification. The access code
identifies all packets exchanged on a physical channel: all packets sent in the same
physical channel are preceded by the same access code. In the receiver of the device,
a sliding correlator correlates against the access code and triggers when a threshold is
exceeded. This trigger signal is used to determine the receive timing.

The shortened access code is used in paging and inquiry. In this case, the access code
itself is used as a signaling message and neither a header nor a payload is present.

The access code consists of a preamble, a sync word, and possibly a trailer, see
Figure 6.3. For details see Section 6.3.1.

LSB 4 64 4 MSB

PREAMBLE SYNC WORD TRAILER

Figure 6.3: Access code format

6.3.1 Access code types

The different access code types use different Lower Address Parts (LAPs) to construct
the sync word. The LAP field of the BD_ADDR is explained in Section 1.2. A summary
of the different access code types is in Table 6.1.

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 2, Part B Page 513
Baseband Specification

Code type LAP Code length Comments

CAC Central 72
DAC Paged device 68/721
See also Section 1.3
GIAC Reserved 68/721
DIAC Dedicated 68/721

Table 6.1: Summary of access code types

1length 72 is only used in combination with FHS packets

The CAC consists of a preamble, sync word, and trailer and its total length is 72 bits.
When used as self-contained messages without a header, the DAC and IAC do not
include the trailer bits and are of length 68 bits.

6.3.2 Preamble

The preamble is a fixed zero-one pattern of 4 symbols used to facilitate DC

compensation. The sequence is either ‘1010’ or ‘0101’ (in transmission order),
depending on whether the LSB of the following sync word is 1 or 0, respectively. The
preamble is shown in Figure 6.4.

LSB MSB LSB LSB MSB LSB

1010 1 0101 0

preamble sync word preamble sync word

Figure 6.4: Preamble

6.3.3 Sync word

The sync word is a 64-bit code word derived from a 24 bit address (LAP); for the CAC
the Central’s LAP is used; for the GIAC and the DIAC, reserved, dedicated LAPs are
used; for the DAC, the Peripheral LAP is used. The construction results in a large
Hamming distance between sync words based on different LAPs. In addition, the good
auto correlation properties of the sync word improve timing acquisition.

6.3.3.1 Synchronization word definition

The sync words are based on a (64,30) expurgated block code with an overlay (bit-wise
XOR) of a 64 bit full length pseudo-random noise (PN) sequence. The expurgated code
results in a large Hamming distance (dmin = 14) between sync words based on different

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 2, Part B Page 514
Baseband Specification

addresses. The PN sequence improves the auto correlation properties of the access
code. The following steps describe how the sync word shall be generated:

1. Generate information sequence;

2. XOR this with the “information covering” part of the PN overlay sequence;
3. Generate the codeword;
4. XOR the codeword with all 64 bits of the PN overlay sequence;

The information sequence is generated by appending 6 bits to the 24 bit LAP (step 1).
The appended bits are '001101' (in transmission order) if the MSB of the LAP equals 0.
If the MSB of the LAP is 1 the appended bits are '110010'. The LAP MSB together with
the appended bits constitute a length-seven Barker sequence. The purpose of including
a Barker sequence is to further improve the auto correlation properties. In step 2 the
information is pre-scrambled by XORing it with the bits p34… p63 of the PN sequence
(defined in Section 6.3.3.2). After generating the codeword (step 3), the complete PN
sequence is XORed to the codeword (step 4). This step de-scrambles the information
part of the codeword. At the same time the parity bits of the codeword are scrambled.
Consequently, the original LAP and Barker sequence are ensured a role as a part of
the access code sync word, and the cyclic properties of the underlying code is removed.
The principle is depicted in Figure 6.5.

In the following discussion, binary sequences will be denoted by their

corresponding D-transform (in which Di represents a delay of i time units). Let
p' D = p'0 + p'1D + … + p'62D62 be the 63 bit PN sequence, where p'0 is the first bit (LSB)
leaving the PRNG (see Figure 6.6), and, p'62 is the last bit (MSB). To obtain 64 bits,
an extra zero is appended at the end of this sequence (thus, p' D is unchanged). For
notational convenience, the reciprocal of this extended polynomial, p D = D63 p' 1/D ,
will be used in the following discussion. This is the sequence p' D in reverse order.
We denote the 24 bit lower address part (LAP) of the Bluetooth Device Address by
a D = a0 + a1D + … + a23D23 (a0 is the LSB of the Bluetooth Device Address).

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 2, Part B Page 515
Baseband Specification

Figure 6.5: Construction of the sync word

The (64,30) block code generator polynomial is denoted g D = 1 + D g′ D , where

g′ D is the generator polynomial 0x37CD0EB67 of a primitive binary (63,30) BCH code.
Thus, g(D) is

g D = 0x585713DA9, (EQ 9)
where the left-most bit corresponds to the high-order (g34) coefficient. The DC-free four
bit sequences '0101' and '1010' (in transmission order) can be written

F 0 D = D + D3,
(EQ 10)
F 1 D = 1 + D2,
respectively. Furthermore,

B0 D = D2 + D3 + D5,
(EQ 11)
B1 D = 1 + D + D4,

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 2, Part B Page 516
Baseband Specification

which are used to create the length seven Barker sequences. Then, the access code
shall be generated by the following procedure:

1. Format the 30 information bits to encode:

x D = a D + D24Ba23 D .

2. Add the information covering part of the PN overlay sequence:

x D = x D + p34 + p35D + … + p63D29 .

3. Generate parity bits of the (64,30) expurgated block code:1

c D = D34x D mod g D .
4. Create the codeword:

s D = D34x D + c D .
5. Add the PN sequence:
s D =s D +p D .
6. Append the (DC-free) preamble and trailer:

y D = F c0 D + D4s D + D68F a23 D .

6.3.3.2 Pseudo-random noise sequence generation

To generate the PN sequence the primitive polynomial h(D) = 1 + D + D3 + D4 + D6 shall

be used. The LFSR and its starting state are shown in Figure 6.6. The PN sequence
generated (including the extra terminating zero) becomes 0x83848D96BBCC54FC. The
LFSR output starts with the left-most bit of this PN sequence. This corresponds to p′ D
of the previous section. Thus, using the reciprocal p′ D as overlay gives the 64 bit
sequence:

p = ′3F 2A33DD69B121C1′ (EQ 12)

(in transmission order) where the left-most bit is p0 = 0 (there are two initial zeros in the
binary representation of the hexadecimal digit 3), and p63 = 1 is the right-most bit.

1 0 0 0 0 0

Figure 6.6: LFSR and the starting state to generate p′ D

1x(D) mod y(D) denotes the remainder when x(D) is divided by y(D).

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 2, Part B Page 517
Baseband Specification

6.3.4 Trailer

The trailer is appended to the sync word as soon as the packet header follows the
access code. This is typically the case with the CAC, but the trailer is also used in
the DAC and IAC when these codes are used in FHS packets exchanged during page
response and inquiry response.

The trailer is a fixed zero-one pattern of four symbols. The trailer together with the three
MSBs of the syncword form a 7-bit pattern of alternating ones and zeroes which can
be used for extended DC compensation. The trailer sequence is either ‘1010’ or ‘0101’
(in transmission order) depending on whether the MSB of the sync word is 0 or 1,
respectively. The choice of trailer is illustrated in Figure 6.7.

MSB LSB MSB MSB LSB MSB

----0 1010 ----1 0101

sync word trailer sync word trailer

a) b)

Figure 6.7: Trailer in CAC when MSB of sync word is 0 (a), and when MSB of sync word is 1 (b)

6.4 Packet header

The header contains link control (LC) information and consists of 6 fields:

• LT_ADDR: 3-bit logical transport address

• TYPE: 4-bit type code
• FLOW: 1-bit flow control
• ARQN: 1-bit acknowledge indication
• SEQN: 1-bit sequence number
• HEC: 8-bit header error check

The total header, including the HEC, consists of 18 bits, see Figure 6.8, and is encoded
with a rate 1/3 FEC (not shown but described in Section 7.4) resulting in a 54-bit
header. The LT_ADDR and TYPE fields shall be sent LSB first.

LSB 3 4 1 1 1 8 MSB

LT_ADDR TYPE FLOW ARQN SEQN HEC

Figure 6.8: Header format

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 2, Part B Page 518
Baseband Specification

6.4.1 LT_ADDR

The 3-bit LT_ADDR field contains the logical transport address for the packet (see
Section 4.2). This field indicates the destination Peripheral (or Peripherals in the case of
a broadcast) for a packet in a Central-to-Peripheral transmission slot and indicates the
source Peripheral for a Peripheral-to-Central transmission slot.

6.4.2 TYPE

Sixteen different types of packets can be distinguished. The 4-bit TYPE code specifies
which packet type is used. The interpretation of the TYPE code depends on the logical
transport address in the packet. First, it shall be determined whether the packet is sent
on a SCO logical transport, an eSCO logical transport, an ACL logical transport, or a
CPB logical transport. Second, it shall be determined whether Enhanced Data Rate
has been enabled for the logical transport (ACL or eSCO) indicated by LT_ADDR. It
can then be determined which type of SCO packet, eSCO packet, or ACL packet has
been received. The TYPE code determines how many slots the current packet will
occupy (see the slot occupancy column in Table 6.2). This allows the non-addressed
receivers to refrain from listening to the channel for the duration of the remaining slots.
In Section 6.5, each packet type is described in more detail.

6.4.3 FLOW

The FLOW bit is used for flow control of packets over the ACL logical transport.
When the RX buffer for the ACL logical transport in the recipient is full, a STOP
indication (FLOW=0) shall be returned to stop the other device from transmitting data
temporarily. The STOP signal only affects ACL packets. Packets including only link
control information (POLL and NULL packets), SCO packets or eSCO packets can still
be received. When the RX buffer can accept data, a GO indication (FLOW=1) shall be
returned. When no packet is received, or the received header is in error, a GO shall
be assumed implicitly. In this case, the Peripheral can receive a new packet with CRC
although its RX buffer is still not emptied. The Peripheral shall then return a NAK in
response to this packet even if the packet passed the CRC check.

The FLOW bit is not used on the eSCO logical transport and shall be set to one on
transmission and ignored upon receipt. The FLOW bit is reserved for future use on the
CPB logical transport.

6.4.4 ARQN

The 1-bit acknowledgment indication ARQN is used to inform the source of a successful
transfer of payload data with CRC, and can be positive acknowledge ACK or negative
acknowledge NAK. See Section 7.6 for initialization and usage of this bit.

The ARQN bit is reserved for future use on the CPB logical transport.

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 2, Part B Page 519
Baseband Specification

6.4.5 SEQN

The SEQN bit provides a sequential numbering scheme to order the data packet
stream. See Section 7.6.2 for initialization and usage of the SEQN bit. For
Active Peripheral Broadcast packets, a modified sequencing method is used, see
Section 7.6.5.

The SEQN bit is reserved for future use on the CPB logical transport.

6.4.6 HEC

Each header has a header-error-check to check the header integrity. The HEC is an
8-bit word (generation of the HEC is specified in Section 7.1.1). Before generating
the HEC, the HEC generator is initialized with an 8-bit value. For FHS packets sent
in Central Page Response substate, the Peripheral upper address part (UAP) shall
be used. For FHS packets and extended inquiry response packets sent in Inquiry
Response substate, the default check initialization (DCI, see Section 1.2.1) shall be
used. In all other cases, the UAP of the Central shall be used.

After the initialization, a HEC shall be calculated for the 10 header bits. Before checking
the HEC, the receiver shall initialize the HEC check circuitry with the proper 8-bit
UAP (or DCI). If the HEC does not check, the entire packet shall be discarded. More
information can be found in Section 7.1.

6.5 Packet types

The packets used on the piconet are related to the logical transports on which they are
used. Four logical transports with distinct packet types are defined (see Section 4):

• SCO logical transport

• eSCO logical transport
• ACL logical transport
• CPB logical transport.

To indicate the different packets on a logical transport, the 4-bit TYPE code is used. The
packet types are divided into four segments. The first segment is reserved for control
packets. All control packets occupy a single time slot. The second segment is reserved
for packets occupying a single time slot. The third segment is reserved for packets
occupying three time slots. The fourth segment is reserved for packets occupying five
time slots. The slot occupancy is reflected in the segmentation and can directly be
derived from the type code. Table 6.2 summarizes the packets defined for the SCO,
eSCO, ACL, and CPB logical transport types; a dash means the value is reserved for
future use.

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 2, Part B Page 520
Baseband Specification

All packet types with a payload shall use GFSK modulation unless specified otherwise
in the following sections.

ACL logical transports Enhanced Data Rate packet types are explicitly selected via
LMP using the packet_type_table (ptt) parameter. eSCO Enhanced Data Rate packet
types are selected when the eSCO logical transport is established. Enhanced Data Rate
packet types for the CPB logical transport are selected when the CPB logical transport
is established.

Bluetooth SIG Proprietary Version Date: 2024-08-27

 Segment TYPE Slot SCO eSCO eSCO ACL ACL logical CPB CPB logical
code occu- logical logical logical logical transport logical transport
b3b2b1b0 pancy transport transport transport transport (2-3 Mb/s) transport (2-3 Mb/s)
(1 Mb/s) (1 Mb/s) (2-3 Mb/s) (1 Mb/s) ptt=1 (1 Mb/s)
ptt=0
1 0000 1 NULL NULL NULL NULL NULL NULL NULL
0001 1 POLL POLL POLL POLL POLL — —
0010 1 FHS — — FHS FHS — —
Baseband Specification

Bluetooth SIG Proprietary

0011 1 DM1 — — DM1 DM1 DM1 DM1
2 0100 1 — — — DH1 2-DH1 DH1 2-DH1
0101 1 HV1 — — — — — —
0110 1 HV2 — 2-EV3 — — — —
0111 1 HV3 EV3 3-EV3 — — — —
1000 1 DV — — — 3-DH1 — 3-DH1
1001 1 — — — AUX1 AUX1 — —
3 1010 3 — — — DM3 2-DH3 DM3 2-DH3
1011 3 — — — DH3 3-DH3 DH3 3-DH3
1100 3 — EV4 2-EV5 — — — —
1101 3 — EV5 3-EV5 — — — —
BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 2, Part B

4 1110 5 — — — DM5 2-DH5 DM5 2-DH5

1111 5 — — — DH5 3-DH5 DH5 3-DH5

Table 6.2: Packets defined for synchronous, asynchronous, and CPB logical transport types

Version Date: 2024-08-27

Page 521
BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 2, Part B Page 522
Baseband Specification

6.5.1 Common packet types

There are five common kinds of packets. In addition to the types listed in segment 1 of
Table 6.2, the ID packet is also a common packet type but is not listed in segment 1
because it does not have a packet header.

6.5.1.1 ID packet

The identity or ID packet consists of the device access code (DAC) or inquiry access
code (IAC). It has a fixed length of 68 bits. It is a very robust packet since the receiver
uses a bit correlator to match the received packet to the known bit sequence of the ID
packet.

The ID packet shall only be used where explicitly stated in paging (see Section 8.3),
inquiry (see Section 8.4), and role switch (see Section 8.6.5). It shall not be used where
any other packet type is permitted.

6.5.1.2 NULL packet

The NULL packet has no payload and consists of the channel access code and packet
header only. Its total (fixed) length is 126 bits. The NULL packet may be used to
return link information to the source regarding the success of the previous transmission
(ARQN), or the status of the RX buffer (FLOW). The NULL packet does not require
acknowledgment.

6.5.1.3 POLL packet

The POLL packet is very similar to the NULL packet. It does not have a payload.
In contrast to the NULL packet, it requires a confirmation from the recipient. It is
not a part of the ARQ scheme. The POLL packet does not affect the ARQN and
SEQN fields. Upon reception of a POLL packet the Peripheral shall respond with a
packet even when the Peripheral does not have any information to send unless the
Peripheral has scatternet commitments in that timeslot. This return packet is an implicit
acknowledgment of the POLL packet. This packet can be used by the Central in a
piconet to poll the Peripherals. Peripherals shall not transmit the POLL packet. POLL
packets shall not be sent on a Connectionless Peripheral Broadcast logical transport.

6.5.1.4 FHS packet

The FHS packet is a special control packet containing, among other things, the
Bluetooth Device Address and the clock of the sender. The payload contains 144
information bits plus a 16-bit CRC code. The payload is coded with a rate 2/3 FEC
with a gross payload length of 240 bits.

Figure 6.9 illustrates the format and contents of the FHS payload. The FHS packet is
used in Central page response, inquiry response and in role switch.

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 2, Part B Page 523
Baseband Specification

The FHS packet is not encrypted. No payload header or MIC is present.

The FHS packet contains real-time clock information. This clock information shall be
updated before each retransmission. The retransmission of the FHS payload is different
than retransmissions of ordinary data payloads where the same payload is used for
each retransmission. The FHS packet is used for frequency hop synchronization before
the piconet channel has been established, or when an existing piconet changes to
a new piconet. However, the FHS packet is not used by Connectionless Peripheral
Broadcast Receivers for frequency hop synchronization with Connectionless Peripheral
Broadcast Transmitters.

LSB MSB
34 24 1 1 2 2 8 16 24 3 26 3

Class of LT_ Previously

Parity bits LAP EIR Reserved SR SP UAP NAP CLK 27-2 used
device ADDR

Figure 6.9: Format of the FHS payload

Each field is described in more detail below:

Parity bits This 34-bit field contains the parity bits that form the first part of the sync word of
the access code of the device that sends the FHS packet. These bits are derived
from the LAP as described in Section 1.2.
LAP This 24-bit field shall contain the lower address part of the device that sends the
FHS packet.
EIR This bit shall indicate that an extended inquiry response packet may follow. See
Section 8.4.3.
Reserved This 1-bit field is reserved for future use.
SR This 2-bit field is the page scan repetition mode field and indicates the interval
between two consecutive page scan windows, see also Table 6.4 and Table 8.1
SP This 2-bit field shall be set to 0b10.
UAP This 8-bit field shall contain the upper address part of the device that sends the
FHS packet.
NAP This 16-bit field shall contain the non-significant address part of the device that
sends the FHS packet (see also Section 1.2 for LAP, UAP, and NAP).
Class of Device This 24-bit field shall contain the Class of Device of the device that sends the
FHS packet. The field is defined in Assigned Numbers.

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 2, Part B Page 524
Baseband Specification

LT_ADDR This 3-bit field shall contain the logical transport address the recipient shall use if
the FHS packet is used at connection setup or role switch. A Peripheral respond-
ing to a Central or a device responding to an inquiry request message shall
include an all-zero LT_ADDR field if it sends the FHS packet.
CLK27-2 This 26-bit field shall contain the value of the native clock of the device that sends
the FHS packet, sampled at the beginning of the transmission of the access
code of this FHS packet. This clock value has a resolution of 1.25 ms (two-slot
interval). For each new transmission, this field is updated so that it accurately
reflects the real-time clock value.

Table 6.3: Description of the FHS payload

The device sending the FHS shall set the SR bits according to Table 6.4.

SR bit format b1b0 SR (page scan repetition) mode

00 R0
01 R1
10 R2
11 Reserved for future use

Table 6.4: Contents of SR field

The LAP, UAP, and NAP together form the 48-bit Bluetooth Device Address of the
device that sends the FHS packet. Using the parity bits and the LAP, the recipient can
directly construct the channel access code of the sender of the FHS packet.

When initializing the HEC and CRC for the FHS packet of inquiry response, the UAP
shall be the DCI.

6.5.1.5 DM1 packet

DM1 is part of segment 1 in order to support control messages in any logical transport
that allows the DM1 packet (see Table 6.2). However, it may also carry regular user
data. Since the DM1 packet can be regarded as an ACL packet, it will be discussed in
Section 6.5.4.

6.5.2 SCO packets

HV and DV packets are used on the synchronous SCO logical transport. The HV
packets do not include a MIC or CRC and shall not be retransmitted. DV packets
include a CRC on the data section, but not on the synchronous data section. DV
packets do not include a MIC. The data section of DV packets shall be retransmitted.
SCO packets may be routed to the synchronous I/O port. Four packets are allowed on
the SCO logical transport: HV1, HV2, HV3 and DV. These packets are typically used for
64 kb/s speech transmission but may be used for transparent synchronous data.

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 2, Part B Page 525
Baseband Specification

SCO packets shall only be encrypted with E0 when E0 is enabled. SCO packets shall
not be sent when AES-CCM Encryption is enabled.

6.5.2.1 HV1 packet

The HV1 packet has 10 information bytes. The bytes are protected with a rate 1/3 FEC.
No MIC is present. No CRC is present. The payload length is fixed at 240 bits. There is
no payload header present.

6.5.2.2 HV2 packet

The HV2 packet has 20 information bytes. The bytes are protected with a rate 2/3 FEC.
No MIC is present. No CRC is present. The payload length is fixed at 240 bits. There is
no payload header present.

6.5.2.3 HV3 packet

The HV3 packet has 30 information bytes. The bytes are not protected by FEC. No
MIC is present. No CRC is present. The payload length is fixed at 240 bits. There is no
payload header present.

6.5.2.4 DV packet

The DV packet is a combined data - voice packet. The DV packet shall only be used in
place of an HV1 packet. The payload is divided into a voice field of 80 bits and a data
field containing up to 150 bits, see Figure 6.10. The voice field is not protected by FEC.
The data field has between 1 and 10 information bytes (including the 1-byte payload
header) plus a 16-bit CRC code. No MIC is present. The data field (including the CRC)
is encoded with a rate 2/3 FEC. Since the DV packet has to be sent at regular intervals
due to its synchronous contents, it is listed under the SCO packet types. The voice and
data fields shall be treated separately. The voice field shall be handled in the same way
as normal SCO data and shall never be retransmitted; that is, the voice field is always
new. The data field is checked for errors and shall be retransmitted if necessary. When
the asynchronous data field in the DV packet has not been acknowledged before the
SCO logical transport is terminated, the asynchronous data field shall be retransmitted
in a DM1 packet.

LSB 72 54 80 45 - 150 MSB

ACCESS VOICE DATA
HEADER
CODE FIELD FIELD

Figure 6.10: DV packet format

6.5.3 eSCO packets

EV packets are used on the synchronous eSCO logical transport. The packets include
a CRC and retransmission may be applied if no acknowledgment of proper reception

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 2, Part B Page 526
Baseband Specification

is received within the retransmission window. No MIC is present. eSCO packets may
be routed to the synchronous I/O port. Three eSCO packet types (EV3, EV4, EV5) are
defined for Basic Rate operation and four additional eSCO packet types (2-EV3, 3-EV3,
2-EV5, 3-EV5) for Enhanced Data Rate operation. The eSCO packets may be used for
64 kb/s speech transmission as well as transparent data at 64 kb/s and other rates.

6.5.3.1 EV3 packet

The EV3 packet has between 1 and 30 information bytes plus a 16-bit CRC code. No
MIC is present. The bytes are not protected by FEC. The EV3 packet may cover up to
a single time slot. There is no payload header present. The payload length is set during
the LMP eSCO setup and remains fixed until the link is removed or re-negotiated.

6.5.3.2 EV4 packet

The EV4 packet has between 1 and 120 information bytes plus a 16-bit CRC code.
No MIC is present. The EV4 packet may cover to up three time slots. The information
plus CRC bits are coded with a rate 2/3 FEC. There is no payload header present. The
payload length is set during the LMP eSCO setup and remains fixed until the link is
removed or re-negotiated.

6.5.3.3 EV5 packet

The EV5 packet has between 1 and 180 information bytes plus a 16-bit CRC code. No
MIC is present. The bytes are not protected by FEC. The EV5 packet may cover up to
three time slots. There is no payload header present. The payload length is set during
the LMP eSCO setup and remains fixed until the link is removed or re-negotiated.

6.5.3.4 2-EV3 packet

The 2-EV3 packet is similar to the EV3 packet except that the payload is modulated
using π/4-DQPSK. It has between 1 and 60 information bytes plus a 16-bit CRC code.
No MIC is present. The bytes are not protected by FEC. The 2-EV3 packet covers a
single time slot. There is no payload header present. The payload length is set during
the LMP eSCO setup and remains fixed until the link is removed or re-negotiated.

6.5.3.5 2-EV5 packet

The 2-EV5 packet is similar to the EV5 packet except that the payload is modulated
using π/4-DQPSK. It has between 1 and 360 information bytes plus a 16-bit CRC
code. No MIC is present. The bytes are not protected by FEC. The 2-EV5 packet
may cover up to three time slots. There is no payload header present. The payload
length is set during the LMP eSCO setup and remains fixed until the link is removed or
re-negotiated.

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 2, Part B Page 527
Baseband Specification

6.5.3.6 3-EV3 packet

The 3-EV3 packet is similar to the EV3 packet except that the payload is modulated
using 8DPSK. It has between 1 and 90 information bytes plus a 16-bit CRC code. No
MIC is present. The bytes are not protected by FEC. The 3-EV3 packet covers a single
time slot. There is no payload header present. The payload length is set during the LMP
eSCO setup and remains fixed until the link is removed or re-negotiated.

6.5.3.7 3-EV5 packet

The 3-EV5 packet is similar to the EV5 packet except that the payload is modulated
using 8DPSK. It has between 1 and 540 information bytes plus a 16-bit CRC code. No
MIC is present. The bytes are not protected by FEC. The 3-EV5 packet may cover up to
three time slots. There is no payload header present. The payload length is set during
the LMP eSCO setup and remains fixed until the link is removed or re-negotiated.

6.5.4 ACL packets

ACL packets are used on the asynchronous logical transport and the CPB logical
transport. The information carried may be user data for either logical transport or control
data for the asynchronous logical transport.

Six packet types are defined for Basic Rate operation: DM1, DH1, DM3, DH3, DM5,
and DH5. Six additional packets are defined for Enhanced Data Rate operation: 2-DH1,
3-DH1, 2-DH3, 3-DH3, 2-DH5 and 3-DH5. The AUX1 packet is also defined for test
purposes.

The length indicator in the payload header specifies the number of user bytes
(excluding payload header, MIC and the CRC code).

6.5.4.1 DM1 packet

The DM1 packet carries data information only. The payload has between 1 and 18
information bytes (including the 1-byte payload header) plus a 16-bit CRC code. A
32-bit MIC is present only when encryption with AES-CCM is enabled. The DM1 packet
occupies a single time slot. The information bits, MIC bits (when present), plus CRC bits
are coded with a rate 2/3 FEC. The payload header in the DM1 packet is 1 byte long,
see Figure 6.12.

6.5.4.2 DH1 packet

This packet is similar to the DM1 packet, except that the information in the payload is
not FEC encoded. As a result, the DH1 packet has between 1 and 28 information bytes
(including the 1-byte payload header) plus a 16-bit CRC code. A 32-bit MIC is present
only when encryption with AES-CCM is enabled. The DH1 packet occupies a single
time slot.

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 2, Part B Page 528
Baseband Specification

6.5.4.3 DM3 packet

The DM3 packet may occupy up to three time slots. The payload has between 2 and
123 information bytes (including the 2-byte payload header) plus a 16-bit CRC code. A
32-bit MIC is present only when encryption with AES-CCM is enabled. The information
bits, MIC bits (when present), plus CRC bits are coded with a rate 2/3 FEC. The
payload header in the DM3 packet is 2 bytes long, see Figure 6.13.

6.5.4.4 DH3 packet

This packet is similar to the DM3 packet, except that the information in the payload
is not FEC encoded. As a result, the DH3 packet has between 2 and 185 information
bytes (including the 2-byte payload header) plus a 16-bit CRC code. A 32-bit MIC is
present only when encryption with AES-CCM is enabled. The DH3 packet may occupy
up to three time slots.

6.5.4.5 DM5 packet

The DM5 packet may occupy up to five time slots. The payload has between 2 and
226 information bytes (including the 2-byte payload header) plus a 16-bit CRC code.
A 32-bit MIC is present only when encryption with AES-CCM is enabled. The payload
header in the DM5 packet is 2 bytes long. The information bits, MIC bits (when present),
plus CRC bits are coded with a rate 2/3 FEC.

6.5.4.6 DH5 packet

This packet is similar to the DM5 packet, except that the information in the payload
is not FEC encoded. As a result, the DH5 packet has between 2 and 341 information
bytes (including the 2-byte payload header) plus a 16-bit CRC code. A 32-bit MIC is
present only when encryption with AES-CCM is enabled. The DH5 packet may occupy
up to five time slots.

6.5.4.7 AUX1 packet

This packet resembles a DH1 packet but has no MIC or CRC code. The AUX1 packet
has between 1 and 30 information bytes (including the 1-byte payload header). The
AUX1 packet occupies a single time slot. The AUX1 packet shall only be used in test
mode (see [Vol 3] Part D). The Link Controller shall discard any AUX1 packet received
in any other circumstances.

6.5.4.8 2-DH1 packet

This packet is similar to the DH1 packet except that the payload is modulated using
π/4-DQPSK. The 2-DH1 packet has between 2 and 56 information bytes (including the
2-byte payload header) plus a 16-bit CRC code. A 32-bit MIC is present only when
encryption with AES-CCM is enabled.The 2-DH1 packet occupies a single time slot.

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 2, Part B Page 529
Baseband Specification

6.5.4.9 2-DH3 packet

This packet is similar to the DH3 packet except that the payload is modulated using
π/4-DQPSK. The 2-DH3 packet has between 2 and 369 information bytes (including
the 2-byte payload header) plus a 16-bit CRC code. A 32-bit MIC is present only when
encryption with AES-CCM is enabled. The 2-DH3 packet may occupy up to three time
slots.

6.5.4.10 2-DH5 packet

This packet is similar to the DH5 packet except that the payload is modulated using
π/4-DQPSK. The 2-DH5 packet has between 2 and 681 information bytes (including
the 2-byte payload header) plus a 16-bit CRC code. A 32-bit MIC is present only when
encryption with AES-CCM is enabled. The 2-DH5 packet may occupy up to five time
slots.

6.5.4.11 3-DH1 packet

This packet is similar to the DH1 packet except that the payload is modulated using
8DPSK. The 3-DH1 packet has between 2 and 85 information bytes (including the
2-byte payload header) plus a 16-bit CRC code. A 32-bit MIC is present only when
encryption with AES-CCM is enabled. The 3-DH1 packet occupies a single time slot.

6.5.4.12 3-DH3 packet

This packet is similar to the DH3 packet except that the payload is modulated using
8DPSK. The 3-DH3 packet has between 2 and 554 information bytes (including the
2-byte payload header) plus a 16-bit CRC code. A 32-bit MIC is present only when
encryption with AES-CCM is enabled. The 3-DH3 packet may occupy up to three time
slots.

6.5.4.13 3-DH5 packet

This packet is similar to the DH5 packet except that the payload is modulated using
8DPSK. The 3-DH5 packet has between 2 and 1023 information bytes (including the
2-byte payload header) plus a 16-bit CRC code. A 32-bit MIC is present only when
encryption with AES-CCM is enabled. The 3-DH5 packet may occupy up to five time
slots.

6.6 Payload format

In the payload, two fields are distinguished: the synchronous data field and the
asynchronous data field. The ACL packets only have the asynchronous data field and
the SCO and eSCO packets only have the synchronous data field – with the exception
of the DV packets which have both.

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 2, Part B Page 530
Baseband Specification

6.6.1 Synchronous data field

In SCO, which is only supported in Basic Rate mode, the synchronous data field has a
fixed length and consists only of the synchronous data body portion. No payload header
is present.

In Basic Rate eSCO, the synchronous data field consists of two segments: a
synchronous data body and a CRC code. No payload header is present.

In Enhanced Data Rate eSCO, the synchronous data field consists of five segments: a
guard time, a synchronization sequence, a synchronous data body, a CRC code and a
trailer. No payload header is present.

1. Enhanced Data Rate guard time

For Enhanced Data Rate packets the guard time is defined as the period starting
at the end of the last GFSK symbol of the header and ending at the start of the
reference symbol of the synchronization sequence. The length of the guard time
shall be between 4.75 µs and 5.25 µs.
2. Enhanced Data Rate synchronization sequence
For Enhanced Data Rate packets the symbol timing at the start of the
synchronization sequence shall be within ±¼ µs of the symbol timing of the last
GFSK symbol of the packet header. The length of the synchronization sequence is
11 µs (11 DPSK symbols) and consists of a reference symbol (with arbitrary phase)
followed by ten DPSK symbols.
The phase changes between the DPSK symbols (shown in Figure 6.11) shall be
φ1, φ2, φ3, φ4, φ5, φ6, φ7, φ8, φ9, φ10 =
3π/4, ‐ 3π/4, 3π/4, ‐ 3π/4, 3π/4, ‐ 3π/4, ‐ 3π/4, 3π/4, 3π/4, 3π/4 (EQ 13)

End of Guard EDR

Header Time sref s1 s2 s3 s4 s5 s6 s7 s8 s9 s10 Payload
5 µs

ϕ1 ϕ2 ϕ3 ϕ4 ϕ5 ϕ6 ϕ7 ϕ8 ϕ9 ϕ10

Figure 6.11: Synchronization sequence

Sref is the reference symbol. φ1 is the phase change between the reference symbol
and the first DPSK symbol S1. φk is the phase change between the k-1th symbol
Sk-1 and the kth symbol Sk

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 2, Part B Page 531
Baseband Specification

Note: The synchronization sequence may be generated using the modulator by

pre-pending the data with bits that generate the synchronization sequence.

For π/4-DQPSK, the bit sequence used to generate the synchronization sequence
is 0,1,1,1,0,1,1,1,0,1,1,1,1,1,0,1,0,1,0,1.

For 8DPSK, the bit sequence used to generate the synchronization sequence is
0,1,0,1,1,1,0,1,0,1,1,1,0,1,0,1,1,1,1,1,1,0,1,0,0,1,0,0,1,0.
3. Synchronous data body
For HV and DV packets, the synchronous data body length is fixed. For EV
packets, the synchronous data body length is negotiated during the LMP eSCO
setup. Once negotiated, the synchronous data body length remains constant
unless re-negotiated. The synchronous data body length may be different for each
direction of the eSCO logical transport.
4. CRC code
The 16-bit CRC in the payload is generated as specified in Section 7.1. The 8-bit
UAP of the Central is used to initialize the CRC generator.
Only the Synchronous data body segment is used to generate the CRC code.
5. Enhanced Data Rate trailer
For Enhanced Data Rate packets, two trailer symbols shall be added to the end of
the payload. The trailer bits shall be all zero, i.e. {00, 00} for the π/4-DQPSK and
{000, 000} for the 8DPSK.

6.6.2 Asynchronous data field

Basic rate ACL packets have an asynchronous data field consisting of two, three or
four segments: a payload header, a payload body, possibly a MIC, and possibly a CRC
code.

Enhanced Data Rate ACL packets have an asynchronous data field consisting of six
or seven segments: a guard time, a synchronization sequence, a payload header, a
payload body, possibly a MIC, a CRC and a trailer.

1. Enhanced Data Rate guard time

This is the same as defined for the Synchronous data field in Section 6.6.1.
2. Enhanced Data Rate synchronization sequence
This is the same as defined for the Synchronous data field in Section 6.6.1.
3. Payload header
The payload header is one or two bytes long. Basic rate packets in segments one
and two have a 1-byte payload header; Basic Rate packets in segments three

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 2, Part B Page 532
Baseband Specification

and four and all Enhanced Data Rate packets have a 2-byte payload header. The
payload header specifies the logical link (2-bit LLID indication), controls the flow on
the logical channels (1-bit FLOW indication), and has a payload length indicator (5
bits and 10 bits for 1-byte and 2-byte payload headers, respectively). In the case of
a 2-byte payload header, the length indicator is extended by five bits into the next
byte. The remaining three bits of the second byte are reserved for future use. The
formats of the 1-byte and 2-byte payload headers are shown in Figure 6.12 and
Figure 6.13.

LSB MSB
2 1 5

LLID FLOW LENGTH

Figure 6.12: Payload header format for Basic Rate single-slot ACL packets

LSB MSB
2 1 10 3

LLID FLOW LENGTH RFU

Figure 6.13: Payload header format for multi-slot ACL packets and all EDR ACL packets

The LLID field shall be transmitted first, the length field last. In Table 6.5, more
details about the contents of the LLID field are listed.
LLID Logical Link Information
0b00 Reserved for future use
0b01 ACL‑U and Continuation fragment of an L2CAP message
APB‑U
0b10 ACL‑U and Start of an L2CAP message or no fragmentation
APB‑U
PBD Profile broadcast data, no fragmentation
0b11 ACL‑C and LMP message
APB‑C

Table 6.5: Logical Link LLID field contents

An L2CAP message may be fragmented into several packets. Code 0b10 shall
be used for an ACL-U or APB-U packet carrying the first fragment of such a
message; code 0b01 shall be used for continuing fragments. The first fragment of
an L2CAP message sent over HCI is identified by having a Packet_Boundary_Flag
value of 0b00 or 0b10 both of which are mapped to LLID code 0b10. If there is
no fragmentation, code 0b10 shall be used for every packet. ACL packets used
over the PBD logical link do not use fragmentation. For ACL packets used over the

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 2, Part B Page 533
Baseband Specification

PBD logical link, LLID code 0b10 shall be used by the transmitter. Any ACL packet
used over the PBD logical link with LLID not equal to 0b10 shall be ignored by the
receiver. Code 0b11 shall be used for LMP messages. Code 0b00 is reserved for
future use.
The flow indicator in the payload is used to control the flow at the L2CAP level.
It is used to control the flow per logical link. FLOW=1 means flow-on (GO) and
FLOW=0 means flow-off (STOP). After a new connection has been established the
flow indicator shall be set to GO. When a device receives a payload header with
the flow bit set to STOP, it shall stop the transmission of ACL-U packets before
an additional amount of payload data is sent. This amount is defined as the flow
control lag, expressed as a number of bytes. The shorter the flow control lag, the
less buffering the other device must dedicate to this function. The flow control lag
shall not exceed 1792 bytes (7 × 256 bytes). In order to allow devices to optimize
the selection of packet length and buffer space, the flow control lag of a given
implementation shall be provided in the LMP_FEATURES_RES message.
If a packet containing the payload flow bit of STOP is received, with a valid
packet header but bad payload, the payload flow control bit shall be ignored. The
Baseband acknowledgment contained in the packet header will be received and a
further ACL packet may be transmitted. Each occurrence of this situation allows a
further ACL packet to be sent in spite of the flow control request being sent via
the payload header flow control bit. It is recommended that devices that use the
payload header flow bit should ensure that no further ACL packets are sent until
the payload flow bit has been correctly received. This can be accomplished by
simultaneously turning on the flow bit in the packet header and keeping it on until
an ACK is received back (ARQN=1). This will typically be only one round trip time.
The Baseband Resource Manager is responsible for setting and processing the
flow bit in the payload header. Real-time flow control shall be carried out at
the packet level by the Link Controller via the flow bit in the packet header
(see Section 6.4.3). With the payload flow bit, traffic from the remote end can
be controlled. It is allowed to generate and send an ACL packet with payload
length zero irrespective of flow status. L2CAP start-fragment and continue-fragment
indications (LLID=10 and LLID=01) also retain their meaning when the payload
length is equal to zero (i.e. an empty start-fragment shall not be sent in the middle
of an on-going ACL-U or APB-U packet transmission). It is always allowed to
send an ACL packet with length=0 and LLID=01. The payload flow bit has its own
meaning for each logical link, see Table 6.6. On the ACL-C, APB-C, and APB-U
logical links, no flow control is applied and the payload FLOW bit shall always be
set to one. On the PBD logical link, no flow control is applied and the payload
FLOW bit shall always be set to zero.

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 2, Part B Page 534
Baseband Specification

LLID Logical Link Usage and semantics of the ACL payload header FLOW bit
code
b1b0
00 Reserved for future use.
01 ACL-U Flow control of the ACL-U channel (L2CAP messages).
APB-U Always set FLOW=1 on transmission and ignore the bit on re-
ception.
PBD Reserved for future use.
10 ACL-U Flow control of the ACL-U channel (L2CAP messages).
APB-U Always set FLOW=1 on transmission and ignore the bit on re-
ception.
PBD Always set FLOW=0 on transmission and ignore the bit on re-
ception.
11 ACL-C and Always set FLOW=1 on transmission and ignore the bit on re-
APB-C ception.

Table 6.6: Use of payload header flow bit on the Logical Links

The length indicator shall be set to the number of bytes (i.e. 8-bit words) in the
payload excluding the payload header, MIC, and the CRC code; i.e. the payload
body only. With reference to Figure 6.12 and Figure 6.13, the MSB of the length
field in a 1-byte header is the last (right-most) bit in the payload header; the MSB of
the length field in a 2-byte header is the fourth bit to the left from the right-most end
of the second byte in the payload header.
4. Payload body
The payload body includes the user information and determines the effective user
throughput. The length of the payload body is indicated in the length field of the
payload header.
5. Message Integrity Check
The 32-bit Message Integrity Check (MIC) in the payload is generated as specified
in [Vol 2] Part H, Section 9.2.
6. CRC code generation
The 16-bit cyclic redundancy check code in the payload is generated as specified
in Section 7.1. Before determining the CRC code, an 8-bit value is used to initialize
the CRC generator. For the CRC code in the FHS packets sent in Central Page
Response substate, the UAP of the Peripheral is used. For the FHS packet and the
extended inquiry response packet sent in Inquiry Response substate, the DCI (see
Section 1.2.1) is used. For all other packets, the UAP of the Central is used.
Only the Payload header, Payload body, and MIC segments (if present) are used to
generate the CRC code.

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 2, Part B Page 535
Baseband Specification

7. Enhanced Data Rate trailer

This is the same as defined for the Synchronous data field in Section 6.6.1.

6.7 Packet summary

A summary of the packets and their characteristics is shown in Table 6.7, Table 6.8,
and Table 6.9. The payload represents the packet payload excluding FEC, CRC, and
payload header.

Type Payload FEC MIC CRC Symmetric Max. Asymmetric

Rate Max. Rate
(bytes)
ID N/A N/A N/A N/A N/A N/A
NULL N/A N/A N/A N/A N/A N/A
POLL N/A N/A N/A N/A N/A N/A
FHS 18 2/3 N/A Yes N/A N/A

Table 6.7: Link control packets

Type Payload User FEC MIC CRC Symmetric Asymmetric Max. Rate
Header Payload Max. Rate (kb/s)
(bytes) (bytes) (kb/s) Forward Reverse
DM1 1 0-17 2/3 C.1 Yes 108.8 108.8 108.8
DH1 1 0-27 No C.1 Yes 172.8 172.8 172.8
DM3 2 0-121 2/3 C.1 Yes 258.1 387.2 54.4
DH3 2 0-183 No C.1 Yes 390.4 585.6 86.4
DM5 2 0-224 2/3 C.1 Yes 286.7 477.8 36.3
DH5 2 0-339 No C.1 Yes 433.9 723.2 57.6
2-DH1 2 0-54 No C.1 Yes 345.6 345.6 345.6
2-DH3 2 0-367 No C.1 Yes 782.9 1174.4 172.8
2-DH5 2 0-679 No C.1 Yes 869.1 1448.5 115.2
3-DH1 2 0-83 No C.1 Yes 531.2 531.2 531.2
3-DH3 2 0-552 No C.1 Yes 1177.6 1766.4 265.6
3-DH5 2 0-1021 No C.1 Yes 1306.9 2178.1 177.1
C.1: Mandatory when encryption with AES-CCM enabled, else excluded

Table 6.8: ACL packets.

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 2, Part B Page 536
Baseband Specification

Type Payload Header User Payload FEC MIC CRC Symmetric Max. Rate
(bytes) (bytes) (kb/s)
HV1 N/A 10 1/3 No No 64.0
HV2 N/A 20 2/3 No No 64.0
HV3 N/A 30 no No No 64.0
DV1 1D 10+(0-9) D 2/3 D No Yes D 64.0+57.6 D
EV3 N/A 1-30 No No Yes 96
EV4 N/A 1-120 2/3 No Yes 192
EV5 N/A 1-180 No No Yes 288
2-EV3 N/A 1-60 No No Yes 192
2-EV5 N/A 1-360 No No Yes 576
3-EV3 N/A 1-90 No No Yes 288
3-EV5 N/A 1-540 No No Yes 864

Table 6.9: Synchronous packets

1Items followed by ‘D’ relate to data field only.

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 2, Part B Page 537
Baseband Specification

7 BIT STREAM PROCESSING

Bluetooth devices shall use the bit stream processing schemes as defined in the
following sections.

Before the payload is sent over the air interface, several bit manipulations are
performed in the transmitter to increase reliability and security. An HEC is added to the
packet header, the header bits are scrambled with a whitening word, and FEC coding
is applied. In the receiver, the inverse processes are carried out. Figure 7.1 shows the
processes carried out for the packet header both at the transmit and the receive side.
All header bit processes are mandatory except that whitening and de-whitening shall not
be performed on synchronization train packets. In Figure 7.1 processes not performed
on all packet types are indicated by dashed blocks.

TX header HEC generation whitening FEC encoding

(LSB first)

RF interface

RX header HEC checking de-whitening decoding

Figure 7.1: Header bit processes

Figure 7.2 shows the processes that may be carried out on the payload. In addition
to the processes defined for the packet header, encryption can be applied on the
payload. Whitening and de-whitening, as explained in Section 7.2, are mandatory for
every payload except synchronization train payloads, where they are forbidden.All other
processes are optional and depend on the packet type (see Section 6.6) and whether
encryption is enabled. In Figure 7.2, optional processes are indicated by dashed blocks.
When E0 encryption is used, the entire payload shall be encrypted. When AES-CCM
encryption is used, only the payload body and MIC shall be encrypted; the payload
header and CRC shall not be encrypted..

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 2, Part B Page 538
Baseband Specification

CRC encryption (E0)

TX Payload
whitening encoding
(LSB first)
encryption and
MIC generation CRC
(AES-CCM)

RF interface

CRC decryption (E0)

RX Payload de-whitening decoding

decryption and
MIC verification CRC
(AES-CCM)

Figure 7.2: Payload bit processes

7.1 Error checking

The packet can be checked for errors or wrong delivery using the channel access code,
the HEC in the header, and the CRC in the payload. At packet reception, the access
code is checked first. Since the 64-bit sync word in the channel access code is derived
from the 24-bit Central’s LAP, this checks if the LAP is correct, and prevents the receiver
from accepting a packet of another piconet (provided the LAP field of the Central's
BD_ADDR is different).

The HEC and CRC computations are initialized as follows:

• In the Inquiry Response substate, the DCI value shall be used for the FHS and
Extended Inquiry Response packet.
• In the Central Page Response substate, the UAP of the Peripheral shall be used in
the FHS packet.
• In the Connection state, the UAP of the Central shall be used. Even though the
access code may be the same for two piconets the different UAP values will typically
cause the HEC and CRC to fail.
• During Role Switch starting from the TDD switch, the UAP of the new Peripheral shall
be used for the FHS packet.

The generation and check of the HEC and CRC are summarized in Figure 7.5 and
Figure 7.8. Before calculating the HEC or CRC, the shift registers in the HEC/CRC
generators shall be initialized with the 8-bit UAP (or DCI) value. Then the header and
payload information shall be shifted into the HEC and CRC generators, respectively
(with the LSB first).

A packet has a valid header if the access code is correct for the piconet and the HEC
has the correct value, irrespective of the values of the other header fields.

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 2, Part B Page 539
Baseband Specification

7.1.1 HEC generation

The HEC generating LFSR is depicted in Figure 7.3. The generator polynomial is g(D)
= (D + 1)(D7 + D4 + D3 + D2 + 1) = D8 + D7 + D5 + D2 + D + 1. Initially this circuit shall
be pre-loaded with the 8-bit UAP such that the LSB of the UAP (denoted UAP0) goes to
the left-most shift register element, and, UAP7 goes to the right-most element. The initial
state of the HEC LFSR is depicted in Figure 7.4. Then the data shall be shifted in with
the switch S set in position 1. When the last data bit has been clocked into the LFSR,
the switch S shall be set in position 2, and, the HEC can be read out from the register.
The LFSR bits shall be read out from right to left (i.e., the bit in position 7 is the first to
be transmitted, followed by the bit in position 6, etc.).

S 2
D0 D1 D2 D5 D7 D8
1

Position 0 1 2 3 4 5 6 7
Data in (LSB first)

Figure 7.3: LFSR circuit generating the HEC

Position: 0 1 2 3 4 5 6 7
LFSR: UAP 0 UAP 1 UAP 2 UAP 3 UAP 4 UAP 5 UAP 6 UAP 7

Figure 7.4: Initial state of the HEC generating circuit

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 2, Part B Page 540
Baseband Specification

TX part

8-bit UAP or DCI

HEC
circuitry

LSB MSB
8-bit
10-bit header info
HEC
RX part

LSB first 8-bit UAP

HEC
zero remainder
circuitry

Figure 7.5: HEC generation and checking

7.1.2 CRC generation

The 16 bit LFSR for the CRC is constructed similarly to the HEC using the CRC-CCITT
generator polynomial g(D) = D16 + D12 + D5 + 1 (i.e., 0x11021) (see Figure 7.6). For
this case, the 8 left-most bits shall be initially loaded with the 8-bit UAP (UAP0 to the
left and UAP7 to the right) while the 8 right-most bits shall be reset to zero. The initial
state of the 16 bit LFSR is specified in Figure 7.7. The switch S shall be set in position
1 while the data is shifted in. After the last bit has entered the LFSR, the switch shall be
set in position 2, and, the register’s contents shall be transmitted, from right to left (i.e.,
starting with position 15, then position 14, etc.).

2
D0 D5 D12 S D16
1

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

Figure 7.6: The LFSR circuit generating the CRC

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 2, Part B Page 541
Baseband Specification

Position: 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
LFSR: UAP0 UAP1 UAP2 UAP3 UAP4 UAP5 UAP6 UAP7 0 0 0 0 0 0 0 0

Figure 7.7: Initial state of the CRC generating circuit

TX part

8-bit UAP or DCI

appended with 8 zero bits

CRC
circuitry

LSB MSB
16-bit
data info
CRC
RX part
8-bit UAP
LSB first
appended with 8 zero bits

CRC
zero remainder
circuitry

Figure 7.8: CRC generation and checking

7.2 Data whitening

Before transmission of all packets both the header and the payload shall be scrambled
with a data whitening word in order to randomize the data from highly redundant
patterns and to minimize DC bias in the packet. The scrambling shall be performed
prior to the FEC encoding. As an exception, Synchronization train packets shall not be
scrambled with a data whitening word.

At the receiver, the received data of scrambled packets shall be descrambled using the
same whitening word generated in the recipient. The descrambling shall be performed
after FEC decoding.

The whitening word is generated with the polynomial g(D) = D7 + D4 + 1 (i.e., 0x91)
and shall be subsequently XORed with the header and the payload. The whitening word
is generated with the linear feedback shift register shown in Figure 7.9. Before each
transmission, the shift register shall be initialized with a portion of the Central's clock,
CLK6-1, extended with an MSB of value one. This initialization shall be carried out with

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 2, Part B Page 542
Baseband Specification

CLK1 written to position 0, CLK2 written to position 1, etc. Exceptions are the FHS
packet sent during inquiry response or Central page response, and the extended inquiry
response packet sent during inquiry response, where initialization of the whitening
register shall be carried out differently. Instead of the Central's clock, the X-input used
in the inquiry or page response (depending on current state) routine shall be used, see
Table 2.2. The 5-bit value shall be extended with two MSBs of value 1. During register
initialization, the LSB of X (i.e., X0) shall be written to position 0, X1 shall be written to
position 1, etc.

data in (LSB first)

0 4
D D D7

0 1 2 3 4 5 6

data out

Figure 7.9: Data whitening LFSR

After initialization, the packet header and the payload (including the CRC) are whitened.
The payload whitening shall continue from the state the whitening LFSR had at the end
of HEC. There shall be no re-initialization of the shift register between packet header
and payload. The first bit of the “data in” sequence shall be the LSB of the packet
header.

For Enhanced Data Rate packets, whitening shall not be applied to the guard,
synchronization and trailer portions of the Enhanced Data Rate packets. During the
periods where whitening is not applied the LFSR shall be paused.

7.3 Error correction

There are three error correction schemes defined for Bluetooth:

• 1/3 rate FEC

• 2/3 rate FEC
• ARQ scheme for the data

The purpose of the FEC scheme on the data payload is to reduce the number
of retransmissions. However, in a reasonably error-free environment, FEC gives
unnecessary overhead that reduces the throughput. Therefore, the packet definitions
given in Section 6 have been kept flexible to use FEC in the payload or not, resulting in
the DM and DH packets for the ACL logical transport, HV packets for the SCO logical
transport, and EV packets for the eSCO logical transport. The packet header is always
protected by a 1/3 rate FEC since it contains valuable link information and is designed
to withstand more bit errors.

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 2, Part B Page 543
Baseband Specification

Correction measures to mask errors in the voice decoder are not included in this
section. This matter is discussed in Section 9.3.

7.4 FEC code: rate 1/3

A simple 3-times repetition FEC code is used for the header. The repetition code is
implemented by repeating each bit three times, see the illustration in Figure 7.10. The
3-times repetition code is used for the entire header, as well as for the synchronous
data field in the HV1 packet.

b b b b b b b b b
0 0 0 1 1 1 2 2 2

Figure 7.10: Bit-repetition encoding scheme

7.5 FEC code: rate 2/3

The other FEC scheme is a (15,10) shortened Hamming code. The generator
polynomial is g(D) = (D + 1)(D4 + D +1). This corresponds to 0x35. The LFSR
generating this code is depicted in Figure 7.11. Initially all register elements are set
to zero. The 10 information bits are sequentially fed into the LFSR with the switches
S1 and S2 set in position 1. Then, after the final input bit, the switches S1 and S2 are
set in position 2, and the five parity bits are shifted out. The parity bits are appended to
the information bits. Subsequently, each block of 10 information bits is encoded into a
15 bit codeword. This code can correct all single errors and detect all double errors in
each codeword. This 2/3 rate FEC is used in the DM packets, in the data field of the
DV packet, in the FHS packet, in the HV2 packet, and in the EV4 packet. Since the
encoder operates with information segments of length 10, tail bits with value zero shall
be appended after the CRC bits to bring the total number of bits equal to a multiple of
10. The number of tail bits to append shall be the least possible that achieves this (i.e.,
in the interval 0...9). These tail bits are not included in the payload length indicator for
ACL packets or in the payload length field of the eSCO setup LMP command.

S1 2
D0 D2 D4 D5
1
2
S2

1
Data in (LSB first)

Figure 7.11: LFSR generating the (15,10) shortened Hamming code

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 2, Part B Page 544
Baseband Specification

7.6 ARQ scheme

With an automatic repeat request scheme, DM packets, DH packets, the data field of
DV packets, and EV packets shall be transmitted until acknowledgment of a successful
reception is returned by the destination (or timeout is exceeded). The acknowledgment
information shall be included in the header of the return packet. The ARQ scheme
is only used on the payload in the packet and only on packets that have a CRC.
The packet header and the synchronous data payload of HV and DV packets are not
protected by the ARQ scheme.

7.6.1 Unnumbered ARQ

Bluetooth uses a fast, unnumbered acknowledgment scheme. An ACK (ARQN=1) or

a NAK (ARQN=0) is returned in response to the receipt of a previously received
packet. The Peripheral shall respond in the Peripheral-to-Central slot directly following
the Central-to-Peripheral slot unless the Peripheral has scatternet commitments in that
timeslot; the Central shall respond at the next event addressing the same Peripheral
(the Central may have addressed other Peripherals between the last received packet
from the considered Peripheral and the Central’s response to this packet). A packet
reception is successful if the HEC passes and, when present, the MIC and CRC pass.

In the first POLL packet at the start of a new connection (as a result of a page, page
scan, or role switch) the Central shall initialize the ARQN bit to NAK. The response
packet sent by the Peripheral shall also have the ARQN bit set to NAK. The subsequent
packets shall use the following rules. The initial value of the Central’s eSCO ARQN at
link set-up shall be NAK.

The ARQN bit shall only be affected by data packets containing CRC and empty slots.
As shown in Figure 7.12, Figure 7.13, and Figure 7.14, upon successful reception of a
CRC packet, the ARQN bit shall be set to ACK. If, in any receive slot in the Peripheral,
or, in a receive slot in the Central following transmission of a packet, one of these
events applies:

1. no access code is detected

2. the HEC fails
3. the CRC fails
4. the MIC fails.

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 2, Part B Page 545
Baseband Specification

then the ARQN bit shall be set to NAK except in the conditions below:

• In eSCO the ARQN bit may be set to ACK even when the CRC on an EV packet has
failed thus enabling delivery of erroneous packets.
• For ACL packets, if a CRC packet with a correct header has the same SEQN as the
previously received CRC packet, the ARQN bit shall be set to ACK and the payload
shall be ignored without checking the CRC.

Packets that have correct HEC but that are addressed to other Peripherals, or packets
other than DH, DM, DV or EV packets, shall not affect the ARQN bit, except as noted
in Section 7.6.2.2. In these cases the ARQN bit shall be left as it was prior to reception
of the packet. For eSCO packets, the SEQN shall not be used when determining the
ARQN. If an eSCO packet has been received successfully within the eSCO window
subsequent receptions within the eSCO window shall be ignored. At the end of the
eSCO window, the Central’s ARQN shall be retained for the first Central-to-Peripheral
transmission in the next eSCO window.

The ARQN bit in the FHS packet is not meaningful. Contents of the ARQN bit in the
FHS packet shall not be checked.

The ARQN bit in the extended inquiry response packet is reserved for future use.

Broadcast packets shall be checked on errors using the CRC, but no ARQ scheme shall
be applied. Broadcast packets shall never be acknowledged.

In Figure 7.12, TX refers to the next transmission that the device makes, which might
not be in the next slot. NO TX indicates that the device is not allowed to transmit in the
next slot.

In Figure 7.14, "Packet OK" means that the packet has an allowed TYPE for the
connection and the CRC is valid.

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 2, Part B Page 546
Baseband Specification

RX

Role
Peripheral Central

TRIGGER? TRIGGER?
F F
T T

HEC OK? HEC OK?

F F
T T

ARQN=NAK in
next transmission
on all LT_ADDRs

LT_ADDR LT_ADDR
OK? F OK? F
T T

Take previous ARQN=NAK in

ARQN in next next transmission
transmission on Reserved on this slot's
all LT_ADDRs LT_ADDR
slot? T
F

NO
"A" TX "A" TX
TX

Figure 7.12: Stage 1 of the receive protocol for determining the ARQN bit

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 2, Part B Page 547
Baseband Specification

"A"

eSCO
LT_ADDR? "B"
T
F

DM/DH/DV Packet Reserved

type?

POLL/
NULL/HV
SEQN =
SEQNOLD
F
SEQN =
SEQNOLD
T
T
F

CRC OK?
F
T

MIC OK?
(if present)
F
T

SEQNOLD =
SEQN

Ignore payload Accept payload Reject payload

ARQN=ACK in Take previous ARQN=NAK in

next transmission ARQN in next next transmission
on ACL transmission on on ACL
LT_ADDR ACL LT_ADDR LT_ADDR

TX

Figure 7.13: Stage 2 (ACL) of the receive protocol for determining the ARQN bit

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 2, Part B Page 548
Baseband Specification

"B"

Already
received valid
payload in
T this eSCO
window

Packet OK?
F
T

Ignore payload Accept payload Reject payload

ARQN=ACK in ARQN=NAK in
next transmission next transmission
on eSCO on eSCO
LT_ADDR LT_ADDR

TX

Figure 7.14: Stage 2 (eSCO) of the receive protocol for determining the ARQN bit

7.6.2 Retransmit filtering

The data payload shall be transmitted until a positive acknowledgment is received or a

timeout is exceeded. A retransmission shall be carried out either because the packet
transmission itself failed, or because the acknowledgment transmitted in the return
packet failed (which has a lower failure probability since the header is more heavily
coded). In the latter case, the destination keeps receiving the same payload over and

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 2, Part B Page 549
Baseband Specification

over again. In order to filter out the retransmissions in the destination, the SEQN
bit is present in the header. Normally, this bit is alternated for every new CRC data
payload transmission. In case of a retransmission, this bit shall not be changed so the
destination can compare the SEQN bit with the previous SEQN value. If different, a new
data payload has arrived; otherwise it is the same data payload and may be ignored.
Only new data payloads shall be transferred to the Baseband Resource Manager.

Note: CRC data payloads can be carried only by DM, DH, DV or EV packets.

7.6.2.1 Initialization of SEQN at start of new connection

The SEQN bit of the first CRC data packet at the start of a connection (as a result of
page, page scan, or role switch) on both the Central and the Peripheral sides shall be
set to 1. The subsequent packets shall use the rules in the following sections.

7.6.2.2 ACL and SCO retransmit filtering

The SEQN bit shall only be affected by the CRC data packets as shown in Figure 7.15.
It shall be inverted every time a new CRC data packet is sent. The CRC data packet
shall be retransmitted with the same SEQN number until an ACK is received or the
packet is flushed. When an ACK is received, a new payload may be sent and on
that transmission the SEQN bit shall be inverted. If a device decides to flush (see
Section 7.6.3), and it has not received an acknowledgment for the current packet,
it shall replace the current packet with an ACL-U continuation packet with the same
sequence number as the current packet and length zero. If it replaces the current
packet in this way it shall not move on to transmit the next packet until it has received
an ACK.

If the Peripheral receives a packet other than DH, DM, DV or EV with the SEQN bit
inverted from that in the last header successfully received on the same LT_ADDR,
it shall set the ARQN bit to NAK until a DH, DM, DV or EV packet is successfully
received.

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 2, Part B Page 550
Baseband Specification

TX

DM/DH/DV?
F
T

Has latest
DM/DH/DV packet
been ACKed? F
T

Invert SEQN FLUSH?

T

Send zero length

Send new payload Send old payload payload in ACL-U
continuation packet

RX

Figure 7.15: Transmit filtering for packets with CRC

7.6.2.3 eSCO retransmit filtering

In eSCO, the SEQN bit shall be toggled every eSCO window. The value shall be
constant for the duration of the eSCO window. The initial value of SEQN shall be zero.

For a given eSCO window the SEQN value shall be constant.

7.6.2.4 FHS retransmit filtering

The SEQN bit in the FHS packet is not meaningful. This bit may be set to any value.
Contents of the SEQN bit in the FHS packet shall not be checked.

7.6.2.5 Extended inquiry response retransmit filtering

The SEQN bit in the extended inquiry response packet is reserved for future use.

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 2, Part B Page 551
Baseband Specification

7.6.2.6 Packets without CRC retransmit filtering

During transmission of packets without a CRC the SEQN bit shall remain the same as it
was in the previous packet.

7.6.3 Flushing payloads

On ACL logical transports, the ARQ scheme can cause variable delay in the traffic
flow since retransmissions are inserted to assure error-free data transfer. For certain
communication links, only a limited amount of delay is allowed: retransmissions are
allowed up to a certain limit at which the current payload shall be ignored. This
data transfer is indicated as isochronous traffic. This means that the retransmit
process must be overruled in order to continue with the next data payload. Aborting
the retransmit scheme is accomplished by flushing the old data and forcing the Link
Controller to take the next data instead.

Flushing results in loss of remaining portions of an L2CAP message. Therefore, the

packet following the flush shall have a start packet indication of LLID = 10 in the payload
header for the next L2CAP message. This informs the destination of the flush (see
Section 6.6). Flushing will not necessarily result in a change in the SEQN bit value, see
the previous section.

The Flush Timeout defines a maximum period after which all segments of the ACL-
U packet with a Packet_Boundary_Flag value of 10 are flushed from the Controller
buffer. The Flush Timeout shall start when the First segment of the ACL-U packet
is stored in the Controller buffer. If the First segment of an ACL-U packet has a
Packet_Boundary_Flag value of 00, it is non-automatically-flushable and shall not cause
the Flush Timeout to start. After the Flush timeout has expired the Link Controller
may continue transmissions according to the procedure described in Section 7.6.2.2,
however the Baseband Resource Manager shall not continue the transmission of the
ACL-U packet to the Link Controller. If the Baseband Resource Manager has further
segments of the packet queued for transmission to the Link Controller it shall delete
the remaining segments of the ACL-U packet from the queue. In case the complete
ACL-U packet was not stored in the Controller buffer yet, any Continuation segments,
received for the ACL logical transport, shall be flushed, until a First segment is received.
When the complete ACL-U packet has been flushed, the Link Manager shall continue
transmission of the next ACL-U packet for the ACL logical transport. The default Flush
Timeout shall be infinite, i.e. re-transmissions are carried out until physical link loss
occurs. This is also referred to as a 'reliable channel.' All devices shall support the
default Flush Timeout. Reliable data shall be sent over a channel with a finite flush
timeout by marking reliable packets as non-automatically-flushable.

On eSCO logical transports, packets shall be automatically flushed at the end of the
eSCO window.

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 2, Part B Page 552
Baseband Specification

Connectionless Peripheral Broadcast packets are transmitted at each scheduled

Connectionless Peripheral Broadcast Instant. If no new data is available, the
Connectionless Peripheral Broadcast Transmitter shall transmit a packet with the last
available data in the payload.

7.6.4 Multi-Peripheral considerations

In a piconet with multiple logical transports, the Central shall carry out the ARQ protocol
independently on each logical transport.

7.6.5 Active Peripheral Broadcast packets

APB broadcast packets are packets transmitted by the Central to all the Peripherals
simultaneously (see Section 8.6.4) If multiple hop sequences are being used each
transmission may only be received by some of the Peripherals. In this case the Central
shall repeat the transmission on each hop sequence. An APB broadcast packet shall be
indicated by the all-zero LT_ADDR.

Note: The FHS packet and the extended inquiry response packet are the only packets
which may have an all-zero LT_ADDR but are not broadcast packets.

Broadcast packets shall not be acknowledged (at least not at the LC level), hence each
broadcast packet is transmitted at least a fixed number of times. An APB broadcast
packet should be transmitted NBC times before the next broadcast packet of the same
broadcast message is transmitted, see Figure 7.16. Optionally, an APB broadcast
packet may be transmitted NBC + 1 times, so NBC=1 means that each broadcast packet
should be sent only once but may be sent twice. However, time-critical broadcast
information may abort the ongoing broadcast train. In addition, an LMP packet sent
on the APB-C logical link is always a complete message for these purposes and is
always sent exactly once; the LMP specification may provide requirements for whether
and when to send another message with the same or related contents.

If multiple hop sequences are being used then the Central may transmit on the different
hop sequences in any order, providing that transmission of a new broadcast packet
shall not be started until all transmissions of any previous broadcast packet have
completed on all hop sequences. The transmission of a single broadcast packet may be
interleaved among the hop sequences to minimize the total time to broadcast a packet.
The Central has the option of transmitting only NBC times on channels common to all
hop sequences.

APB broadcast packets with a CRC shall have their own sequence number. The SEQN
of the first broadcast packet with a CRC shall be set to SEQN = 1 by the Central and
shall be inverted for each new broadcast packet with CRC thereafter. APB broadcast
packets without a CRC have no influence on the sequence number. The Peripheral
shall accept the SEQN of the first broadcast packet it receives in a connection and

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 2, Part B Page 553
Baseband Specification

shall check for change in SEQN for subsequent broadcast packets. Since there is
no acknowledgment of broadcast messages and there is no end packet indication, it
is important to receive the start packets correctly. To ensure this, repetitions of the
broadcast packets that are L2CAP start packets and LMP packets shall not be filtered
out. These packets shall be indicated by LLID=1X in the payload header as explained in
Table 6.5. Only repetitions of the L2CAP continuation packets shall be filtered out.

broadcast message

broadcast packets 1 2 M

1 2 N
BC

1 1 1 2 2 2 M M M
t

Figure 7.16: Broadcast repetition scheme

7.7 Erroneous synchronous data reporting

Erroneous data reporting may be enabled for synchronous links. When enabled,
synchronous data shall be processed as follows:

• If, during an (e)SCO interval, an eSCO packet was received with valid HEC, an
allowed TYPE for the connection, and valid CRC, or a SCO packet was received with
valid HEC, the received payload data shall be sent to the upper-edge of the Controller
with a "good data" indication.
• If, during an eSCO interval, eSCO packets with valid HEC were received, but none of
them had an allowed TYPE for the connection and a valid CRC, the best known data
available (e.g., data derived from the received data or the actual payload data that
was received with a CRC error) shall be sent to the upper-edge of the Controller with
a "data with possible errors" indication.
• If, during an (e)SCO interval, no SCO or eSCO packet with valid HEC has been
received, a "lost data" indication shall be sent to the upper-edge of the Controller.

7.8 Message Integrity Check

When encryption with AES-CCM is enabled, a Message Integrity Check (MIC) is added
to the payload before the CRC for packets that are defined to include the MIC. The MIC
is sent Most Significant Octet (MSO) first.

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 2, Part B Page 554
Baseband Specification

8 LINK CONTROLLER OPERATION

This section describes how a piconet is established and how devices can be added to
and released from the piconet. Several states of operation of the devices are defined to
support these functions. In addition, the operation of several piconets with one or more
common members, the scatternet, is discussed.

8.1 Overview of states

Figure 8.1 shows a state diagram illustrating the different states used in the Link
Controller. There are two major states: Standby and Connection; in addition, there
are nine substates, Page, Page Scan, Inquiry, Inquiry Scan, Synchronization Train,
Synchronization Scan, Central Page Response, Peripheral Page Response, and Inquiry
Response (the Central Page Response, Peripheral Page Response, and Inquiry
Response substates are not shown in the simplified figure below). The substates are
interim states that are used to establish connections and enable device discovery. To
move from one state or substate to another, either commands from the link manager are
used, or internal signals in the Link Controller are used (such as the trigger signal from
the correlator and the timeout signals).

STANDBY

Synchronization Inquiry
Train

Synchronization Inquiry
Scan Scan

Page Page Scan

CONNECTION

Figure 8.1: State diagram of Link Controller

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 2, Part B Page 555
Baseband Specification

8.2 Standby state

The Standby state is the default state in the device. In this state, the device may be in
a low-power mode. Only the native clock is running with a worst case accuracy of ±250
ppm.

The Controller may leave the Standby state to scan for page or inquiry messages, or to
page or inquiry itself.

8.3 Connection establishment substates

In order to establish new connections the paging procedure or the synchronization

scan procedure is used. Only the Bluetooth Device Address is required to set up a
connection using the paging procedure. Knowledge about the clock, obtained from the
inquiry procedure (see Section 8.4) or from a previous connection with this device,
and the page scanning mode of the other device will accelerate the paging procedure.
A device that establishes a connection using a page procedure will automatically
become the Central of the connection. A device that establishes a connection using
a synchronization scan procedure does so in two steps. First, from within the
Synchronization Scan substate, the BR/EDR Controller follows the synchronization
scan procedure to collect clock, packet timing, and AFH channel map information from
the Central and then transitions to the Standby state. Second, as commanded by the
Host, the BR/EDR Controller transitions from the Standby state to the Connectionless
Peripheral Broadcast mode of the Connection state.

The truncated page procedure is a modification of the paging procedure and is used to
deliberately generate a page response timeout on the Peripheral.

8.3.1 Page Scan substate

In the Page Scan substate, a device may be configured to use either the standard or
generalized interlaced scanning procedure. During a standard scan, a device listens for
the duration of the scan window Tw_page_scan (11.25 ms default, see HCI [Vol 4] Part E,
Section 7.3.20), while the generalized interlaced scan is performed as two back to back
scans of Tw_page_scan. If the scan interval is not at least twice the scan window, then
generalized interlaced scan shall not be used. During each scan window, the device
shall listen at a single hop frequency, its correlator matched to its device access code
(DAC). The scan window shall be long enough to completely scan 16 page frequencies.

When a device enters the Page Scan substate, it shall select the scan frequency
according to the page hopping sequence determined by the device's Bluetooth Device
Address, see Section 2.6.4.1. The phase in the sequence shall be determined by
CLKN16-12 of the device’s native clock; that is, every 1.28 s a different frequency is
selected.

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 2, Part B Page 556
Baseband Specification

In the case of a standard scan, if the correlator exceeds the trigger threshold during
the page scan, the device shall enter the Peripheral Page Response substate described
in Section 8.3.3.1. The scanning device may also use generalized interlaced scan.
In this case, if the correlator does not exceed the trigger threshold during the first
scan it shall scan a second time using the phase in the sequence determined by
[CLKN16-12 + interlace_offset] mod 32. If on this second scan the correlator exceeds the
trigger threshold the device shall enter the Peripheral Page Response substate using
[CLKN16-12 + interlace_offset] mod 32 as the frozen CLKN* in the calculation for Xprp
(see Section 2.6.4.3 for details). If the correlator does not exceed the trigger threshold
during a scan in normal mode or during the second scan in interlaced scan mode it shall
return to either the Standby or Connection state.

The interlace_offset value ranges from 0 to 31. The value 16 should be used unless the
pattern of slots that are not available for scanning implies a different value should be
used.

The Page Scan substate can be entered from the Standby state or the Connection
state. In the Standby state, no connection has been established and the device can use
all the capacity to carry out the page scan. Before entering the Page Scan substate
from the Connection state, the device should reserve as much capacity as possible
for scanning. If desired, the device may place ACL connections in Hold mode (see
Section 8.8) or Sniff mode (see Section 8.7). Synchronous connections should not be
interrupted by the page scan, although eSCO retransmissions should be paused during
the scan. The page scan may be interrupted by the reserved synchronous slots which
should have higher priority than the page scan. SCO packets should be used requiring
the least amount of capacity (HV3 packets). The scan window shall be increased to
minimize the setup delay. If one SCO logical transport is present using HV3 packets and
TSCO=6 slots or one eSCO logical transport is present using EV3 packets and TeSCO=6
slots, a total scan window Tw_page_scan of at least 36 slots (22.5 ms) is recommended; if
two SCO links are present using HV3 packets and TSCO=6 slots or two eSCO links are
present using EV3 packets and TeSCO=6 slots, a total scan window of at least 54 slots
(33.75 ms) is recommended.

The scan interval Tpage_scan is defined as the interval between the beginnings of two
consecutive page scans. A distinction is made between the case where the scan
interval is equal to the scan window Tw_page_scan (continuous scan), the scan interval
is maximal 1.28 s, or the scan interval is maximal 2.56 s. These three cases shall
determine the behavior of the paging device; that is, whether the paging device shall
use R0, R1 or R2, see also Section 8.3.2. Table 8.1 illustrates the relationship between
Tpage_scan and modes R0, R1 and R2. Although scanning in the R0 mode is continuous,
the scanning may be interrupted for example by reserved synchronous slots. The scan
interval information (also known as the page scan repetition mode) is included in the SR
field in the FHS packet.

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 2, Part B Page 557
Baseband Specification

SR mode Tpage_scan
R0 ≤ 1.28 s and = Tw_page_scan
R1 ≤ 1.28 s
R2 ≤ 2.56 s

Table 8.1: Relationship between scan interval and page scan repetition modes R0, R1, and R2

8.3.2 Page substate

The Page substate is used by the Central (source) to activate and connect to a
Peripheral (destination) in the Page Scan substate. The Central tries to coincide with
the Peripheral's scan activity by repeatedly transmitting the paging message consisting
of the Peripheral’s device access code (DAC) in different hop channels. Since the
Bluetooth clocks of the Central and the Peripheral are not synchronized, the Central
does not know exactly when the Peripheral wakes up and on which hop frequency.
Therefore, it transmits a train of identical page messages at different hop frequencies
and listens in between the transmit intervals until it receives a response from the
Peripheral.

The page procedure in the Central consists of a number of steps. First, the Host
communicates the BD_ADDR of the Peripheral to the Controller. This BD_ADDR shall
be used by the Central to determine the page hopping sequence; see Section 2.6.4.2.
If the BD_ADDR of the Peripheral is identical to the BD_ADDR of the Central, then the
Central's Controller shall reject the page procedure. For the phase in the sequence,
the Central shall use an estimate of the Peripheral’s clock. For example, this estimate
can be derived from timing information that was exchanged during the last encounter
with this particular device (which could have acted as a Central at that time), or from
an inquiry procedure. With this estimate CLKE of the Peripheral’s Bluetooth clock, the
Central can predict on which hop channel the Peripheral starts page scanning.

The estimate of the Bluetooth clock in the Peripheral can be completely wrong.
Although the Central and the Peripheral use the same hopping sequence, they use
different phases in the sequence and might never select the same frequency. To
compensate for the clock drifts, the Central shall send its page message during a
short time interval on a number of wake-up frequencies. It shall transmit also on hop
frequencies just before and after the current, predicted hop frequency. During each
TX slot, the Central shall sequentially transmit on two different hop frequencies. In the
following RX slot, the receiver shall listen sequentially to two corresponding RX hops for
an ID packet. The RX hops shall be selected according to the page response hopping
sequence. The page response hopping sequence is strictly related to the page hopping
sequence: for each page hop there is a corresponding page response hop. The RX/TX
timing in the Page substate is described in Section 2.2.5, see also Figure 2.7. In the
next TX slot, the Central shall transmit on two hop frequencies different from the former
ones.

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 2, Part B Page 558
Baseband Specification

Note: The hop rate is increased to 3200 hops per second.

With the increased hopping rate as described above, the transmitter can cover 16
different hop frequencies in 16 slots or 10 ms. The page hopping sequence is
divided over two paging trains A and B of 16 frequencies. Train A includes the 16
hop frequencies surrounding the current, predicted hop frequency f(k), where k is
determined by the clock estimate CLKE16-12. The first train consists of hops

f(k-8), f(k-7),...,f(k),...,f(k+7)

When the difference between the Bluetooth clocks of the Central and the Peripheral is
between -8x1.28 s and +7x1.28 s, one of the frequencies used by the Central will be
the hop frequency the Peripheral will listen to. Since the Central does not know when
the Peripheral will enter the Page Scan substate, the Central has to repeat this train A
Npage times or until a response is obtained, whichever is shorter. If the Peripheral scan
interval corresponds to R1, the repetition number is at least 128; if the Peripheral scan
interval corresponds to R2 or if the Central has not previously read the Peripheral's SR
(page scan repetition) mode, the repetition number is at least 256. If the Central has not
previously read the Peripheral's SR mode it shall use Npage >= 256.

Note: CLKE16-12 changes every 1.28 s; therefore, every 1.28 s, the trains will include
different frequencies of the page hopping set.

When the difference between the Bluetooth clocks of the Central and the Peripheral is
less than -8x1.28 s or larger than +7x1.28 s, the remaining 16 hops are used to form the
new 10 ms train B. The second train consists of hops

f(k-16), f(k-15),...,f(k-9),f(k+8)...,f(k+15)

Train B shall be repeated for Npage times. If no response is obtained, knudge may be
updated in the case where slots to receive are periodically not available and train A
shall be tried again Npage times. Alternate use of train A and train B and updates
of knudge shall be continued until a response is received or the timeout pageTO +
extended_pageTO is exceeded. If a response is returned by the Peripheral, the Central
enters the Central Page Response substate.

The Page substate may be entered from the Standby state or the Connection state. In
the Standby state, no connection has been established and the device can use all the
capacity to carry out the page. Before entering the Page substate from the Connection
state, the device should free as much capacity as possible for paging. To ensure this, it
is recommended that the ACL connections are put on hold. However, the synchronous
connections shall not be disturbed by the page. This means that the page will be
interrupted by the reserved SCO and eSCO slots which have higher priority than the
page. In order to obtain as much capacity for paging, it is recommended to use the
SCO packets which use the least amount of capacity (HV3 packets). If SCO or eSCO

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 2, Part B Page 559
Baseband Specification

links are present, the repetition number Npage of a single train shall be increased, see
Table 8.2. Here it has been assumed that the HV3 packet are used with an interval
TSCO=6 slots or EV3 packets are used with an interval of TeSCO=6 slots, which would
correspond to a 64 kb/s synchronous link.

SR mode no synchronous link one synchronous link two synchronous links

(HV3) (HV3)
R0 Npage≥1 Npage≥2 Npage≥3
R1 N page≥128 Npage≥256 Npage≥384
R2 Npage≥256 Npage≥512 Npage≥768

Table 8.2: Relationship between train repetition and paging modes R0, R1 and R2 when synchronous
links are present

The construction of the page train shall be independent of the presence of synchronous
links; that is, synchronous packets are sent on the reserved slots but shall not affect the
hop frequencies used in the unreserved slots, see Figure 8.2.

10 ms train

1,2 3,4 5,6 7,8 9,10 11,12 13,14 15,16 1,2 3,4 5,6 7,8 9,10 11,12 13,14 15,16 1,2 3,4 5,6

a)

Synchronous slot
1,2 5,6 7,8 11,12 13,14 1,2 3,4 7,8 9,10 13,14 15,16 3,4 5,6

b)

Synchronous slots
1,2 7,8 13,14 3,4 9,10 15,16 5,6

c)

Figure 8.2: Conventional page (a), page while one synchronous link present (b), page while two
synchronous links present (c)

8.3.3 Page response substates

When a page message is successfully received by the Peripheral, there is a coarse

frequency hopping synchronization between the Central and the Peripheral. Both the
Central and the Peripheral enter a response substate to exchange vital information
to continue the connection setup. It is important for the piconet connection that both
devices shall use the same channel access code, use the same channel hopping
sequence, and their clocks are synchronized. These parameters shall be derived from
the Central. The device that initializes the connection (starts paging) is defined as

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 2, Part B Page 560
Baseband Specification

the Central (which is thus only valid during the time the piconet exists). The channel
access code and channel hopping sequence shall be derived from the Bluetooth
Device Address (BD_ADDR) of the Central. The timing shall be determined by the
Central's clock. An offset shall be added to the Peripheral’s native clock to temporarily
synchronize the Peripheral's clock to the Central's clock. At start-up, the Central's
parameters are transmitted from the Central to the Peripheral. The messaging between
the Central and the Peripheral at start-up is specified in this section.

If Central and Peripheral are already connected (irrespective of roles) then the
Peripheral shall either ignore the page or shall immediately close the existing
connection without sending any further packets relating to that connection and then
continue with the page response procedure.

If the BD_ADDR of the Central is identical to the BD_ADDR of the Peripheral, then the
Peripheral's Controller shall ignore the page and end the page response procedure.

The initial messaging between Central and Peripheral is shown in Table 8.3 and in
Figure 8.3 and Figure 8.4. In those two figures frequencies f (k), f(k+1), etc. are the
frequencies of the page hopping sequence determined by the Peripheral’s BD_ADDR.
The frequencies f’(k), f’(k+1), etc. are the corresponding page_response frequencies
(Peripheral-to-Central). The frequencies g(m) belong to the basic channel hopping
sequence.

Step Message Packet Direction Hopping Access Code

Type Sequence and Clock
1 Page ID Central to Peripheral Page Peripheral
2 First Peripheral page ID Peripheral to Central Page response Peripheral
response
3 Central page re- FHS Central to Peripheral Page Peripheral
sponse
4 Second Peripheral ID Peripheral to Central Page response Peripheral
page response
5 1st packet Central POLL Central to Peripheral Channel Central
6 1st packet Peripheral NULL/DM Peripheral to Central Channel Central
1/DH1

Table 8.3: Initial messaging during start-up

In step 1 (see Table 8.3), the Central is in Page substate and the Peripheral in the Page
Scan substate. Assume in this step that the page message sent by the Central reaches
the Peripheral. On receiving the page message, the Peripheral enters the Peripheral
Page Response substate in step 2. The Central waits for a reply from the Peripheral
and when this arrives in step 2, it shall enter the Central Page Response substate in
step 3.

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 2, Part B Page 561
Baseband Specification

Note: During the initial message exchange, all parameters are derived from the
Peripheral’s device address, and that only the page hopping and page response
hopping sequences are used (are also derived from the Peripheral’s device address).
When the Central and Peripheral enter the response states, their clock input to the page
and page response hop selection is frozen as is described in Section 2.6.4.3.

step 1 step 2 step 3 step 4 step 5 step 6

f(k) f(k+1) f(k+1) g(m)

CENTRAL

PAGE FHS POLL

f'(k) f'(k+1) g(m+1)

PERIPHERAL

RESPONSE RESPONSE 1st

Traffic

page hopping sequence basic channel hopping sequence

Figure 8.3: Messaging at initial connection when Peripheral responds to first page message

step 1 step 2 step 3 step 4 step 5 step 6

f(k) f(k+1) f(k+2) g(m)

CENTRAL

PAGE FHS POLL

f'(k+1) f'(k+2) g(m+1)

PERIPHERAL

RESPONSE RESPONSE 1st TRAFFIC

page hopping sequence basic channel hopping sequence

Figure 8.4: Messaging at initial connection when Peripheral responds to second page message

In the case of the truncated page procedure, the messaging stops after step 2 in the
sequence shown in Table 8.3. This procedure is illustrated in Figure 8.5 and Figure 8.6.

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 2, Part B Page 562
Baseband Specification

Standard part of the Truncated part of the

paging sequence paging sequence

Central ID ID FHS

FHS not
sent

Peripheral ID

Figure 8.5: First half slot truncated page

Standard part of the Truncated part of the

paging sequence paging sequence

Central ID ID FHS

FHS not
sent
ID
Peripheral

Figure 8.6: Second half slot truncated page

8.3.3.1 Peripheral Page Response substate

After having received the page message in step 1, the Peripheral shall transmit a
Peripheral page response message (the Peripheral's device access code) in step 2.
This response message shall be the Peripheral’s device access code. The Peripheral
shall transmit this response 625 μs after the beginning of the received page message
and at the response hop frequency that corresponds to the hop frequency in which the
page message was received. The Peripheral’s transmission is therefore time aligned
to the Central’s transmission. During initial messaging, the Peripheral shall still use
the page response hopping sequence to return information to the Central. The clock
input CLKN16-12 shall be frozen at the value it had at the time the page message was
received.

After having sent the response message, the Peripheral’s receiver shall be activated
312.5 μs after the start of the response message and shall await the arrival of an FHS
packet.

Note: An FHS packet can arrive 312.5 μs after the arrival of the page message as
shown in Figure 8.4, and not after 625 μs as is usually the case in the piconet physical
channel RX/TX timing (more details about the timing can be found in Section 2.4.4).

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 2, Part B Page 563
Baseband Specification

If the setup fails before the Connection state has been reached, the following procedure
shall be carried out. The Peripheral shall listen as long as no FHS packet is received
until pagerespTO is exceeded. Every 1.25 ms, however, it shall select the next Central-
to-Peripheral hop frequency according to the page hop sequence. If nothing is received
after pagerespTO, the Peripheral shall return back to the Page Scan substate for
one scan period. Length of the scan period depends on the synchronous reserved
slots present. If no page message is received during this additional scan period, the
Peripheral shall resume scanning at its regular scan interval and return to the state it
was in prior to the first page scan state.

If an FHS packet is received by the Peripheral in the Peripheral Page Response

substate, the Peripheral shall return a Peripheral page response message in step 4 to
acknowledge reception of the FHS packet. This response shall use the page response
hopping sequence. The transmission of the Peripheral page response packet is based
on the reception of the FHS packet. Then the Peripheral shall change to the Central's
channel access code and clock as received from the FHS packet. Only the 26 MSBs
of the Central's clock are transferred: the timing shall be such that CLK1 and CLK0 are
both zero at the time the FHS packet was received as the Central transmits in even
slots only. The offset between the Central’s clock and the Peripheral’s clock shall be
determined from the Central’s clock in the FHS packet and reported to the Peripheral’s
Baseband Resource Manager.

Finally, the Peripheral enters the Connection state in step 5. From then on, the
Peripheral shall use the Central’s clock and the Central's BD_ADDR to determine the
basic channel hopping sequence and the channel access code. The Peripheral shall
use the LT_ADDR in the FHS payload as the primary LT_ADDR in the Connection
state. The connection mode shall start with a POLL packet transmitted by the Central.
The Peripheral may respond with a NULL, DM1, or DH1 packet. If the POLL packet is
not received by the Peripheral, or the response packet is not received by the Central,
within newconnectionTO number of slots after FHS packet acknowledgment, the Central
and the Peripheral shall return to Page and Page Scan substates, respectively. See
Section 8.5.

8.3.3.2 Central Page Response substate

When the Central has received a Peripheral page response message in step 2, and
the Central is not executing the truncated page procedure, it shall enter the Central
Response substate. It shall freeze the current clock input to the page hop selection
scheme. The Central shall then transmit an FHS packet in step 3 containing the
Central’s real-time Bluetooth clock, the Central’s BD_ADDR, the BCH parity bits, and
the Class of Device. The FHS packet contains all information to construct the channel
access code without requiring a mathematical derivation from the Central's Bluetooth
Device Address. The LT_ADDR field in the packet header of FHS packets in the
Central Page Response substate shall be set to all-zeros. The FHS packet shall be

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 2, Part B Page 564
Baseband Specification

transmitted at the beginning of the Central-to-Peripheral slot following the slot in which
the Peripheral responded. The FHS packet shall carry the all-zero LT_ADDR. The TX
timing of the FHS is not based on the reception of the response packet from the
Peripheral. The FHS packet may therefore be sent 312.5 μs after the reception of the
response packet like shown in Figure 8.4 and not 625 μs after the received packet as is
usual in the piconet physical channel RX/TX timing, see also Section 2.4.4.

After the Central has sent its FHS packet, it shall wait for a second Peripheral page
response message in step 4 acknowledging the reception of the FHS packet. This
response shall be the Peripheral’s device access code. If no response is received,
the Central shall retransmit the FHS packet with an updated clock and still using the
Peripheral’s parameters. It shall retransmit the FHS packet with the clock updated each
time until a second Peripheral page response message is received, or the timeout
of pagerespTO is exceeded. In the latter case, the Central shall return to the Page
substate and send an error message to the Baseband Resource Manager. During the
retransmissions of the FHS packet, the Central shall use the page hopping sequence.

If the Peripheral’s response is received, the Central shall change to using the Central’s
parameters, so it shall use the channel access code and the Central's clock. The
lower clock bits CLK0 and CLK1 shall be reset to zero at the start of the FHS packet
transmission and are not included in the FHS packet. Finally, the Central enters the
Connection state in step 5. The Central BD_ADDR shall be used to change to a
new hopping sequence, the basic channel hopping sequence. The basic channel
hopping sequence uses all 79 hop channels in a pseudo-random fashion, see also
Section 2.6.4.7. The Central shall now send its first traffic packet in a hop determined
with the new (Central) parameters. This first packet shall be a POLL packet. See
Section 8.5. This packet shall be sent within newconnectionTO number of slots after
reception of the FHS packet acknowledgment. The Peripheral may respond with a
NULL, DM1, or DH1 packet. If the POLL packet is not received by the Peripheral or the
POLL packet response is not received by the Central within newconnectionTO number
of slots, the Central and the Peripheral shall return to Page and Page Scan substates,
respectively.

8.4 Device discovery substates

In order to discover other devices a device shall enter Inquiry substate. In this substate,
it shall repeatedly transmit the inquiry message (ID packet, see Section 6.5.1.1) at
different hop frequencies. The inquiry hop sequence is derived from the LAP of the
GIAC. Thus, even when DIACs are used, the applied hopping sequence is generated
from the GIAC LAP. A device that allows itself to be discovered, shall regularly enter the
Inquiry Scan substate to respond to inquiry messages. The following sections describe
the message exchange and contention resolution during inquiry response. The inquiry
response is optional: a device is not forced to respond to an inquiry message.

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 2, Part B Page 565
Baseband Specification

During the Inquiry substate, the discovering device collects the Bluetooth Device
Addresses and clocks of all devices that respond to the inquiry message. In addition,
the discovering device also collects extended information (e.g. local name and
supported services) from devices that respond with an extended inquiry response
packet. It can then, if desired, make a connection to any one of the discovered devices
by means of the previously described page procedure.

The inquiry message broadcast by the source does not contain any information about
the source. However, it may indicate which class of devices should respond. There is
one general inquiry access code (GIAC) to inquire for any device, and a number of
dedicated inquiry access codes (DIAC) that only inquire for a certain type of device. The
inquiry access codes are derived from reserved Bluetooth Device Addresses and are
further described in Section 6.3.1.

8.4.1 Inquiry Scan substate

The Inquiry Scan substate is very similar to the Page Scan substate. However, instead
of scanning for the device's device access code, the receiver shall scan for the inquiry
access code long enough to completely scan for 16 inquiry frequencies. Two types of
scans are defined: standard and generalized interlaced. In the case of a standard scan
the length of this scan period is denoted Tw_inquiry_scan (11.25 ms default, see HCI [Vol
4] Part E, Section 7.3.22). The standard scan is performed at a single hop frequency
as defined by Xir4-0 (see Section 2.6.4.6). The generalized interlaced scan is performed
as two back to back scans of Tw_inquiry_scan where the first scan is on the normal hop
frequency and the second scan is defined by [Xir4-0 + interlace_offset] mod 32. If the
scan interval is not at least twice the scan window then generalized interlaced scan
shall not be used. The inquiry procedure uses 32 dedicated inquiry hop frequencies
according to the inquiry hopping sequence. These frequencies are determined by the
general inquiry address. The phase is determined by the native clock of the device
carrying out the inquiry scan; the phase changes every 1.28 s.

The interlace_offset value ranges from 0 to 31. The value 16 should be used unless the
pattern of slots that are not available for scanning implies a different value should be
used.

Instead of, or in addition to, the general inquiry access code, the device may scan for
one or more dedicated inquiry access codes. However, the scanning shall follow the
inquiry scan hopping sequence determined by the general inquiry address. If an inquiry
message is received during an inquiry wake-up period, the device shall enter the Inquiry
Response substate.

The Inquiry Scan substate can be entered from the Standby state or the Connection
state. In the Standby state, no connection has been established and the device can
use all the capacity to carry out the inquiry scan. Before entering the Inquiry Scan

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 2, Part B Page 566
Baseband Specification

substate from the Connection state, the device should reserve as much capacity as
possible for scanning. If desired, the device may place ACL logical transports in Sniff
mode or Hold mode. Synchronous logical transports are preferably not interrupted by
the inquiry scan, although eSCO retransmissions should be paused during the scan. In
this case, the inquiry scan may be interrupted by the reserved synchronous slots. SCO
packets should be used requiring the least amount of capacity (HV3 packets). The scan
window, Tw inquiry scan, shall be increased to increase the probability to respond to an
inquiry message. If one SCO logical transport is present using HV3 packets and TSCO=6
slots or one eSCO logical transport is present using EV3 packets and TeSCO=6 slots,
a total scan window of at least 36 slots (22.5 ms) is recommended; if two SCO links
are present using HV3 packets and TSCO=6 slots or two eSCO links are present using
EV3 packets and TeSCO=6 slots, a total scan window of at least 54 slots (33.75 ms) is
recommended.

The scan interval Tinquiry scan is defined as the interval between two consecutive inquiry
scans. The inquiry scan interval shall be less than or equal to 2.56 s.

8.4.2 Inquiry substate

The Inquiry substate is used to discover new devices. This substate is very similar to
the Page substate; the TX/RX timing shall be the same as in paging, see Section 2.4.4
and Figure 2.7. The TX and RX frequencies shall follow the inquiry hopping sequence
and the inquiry response hopping sequence, and are determined by the general
inquiry access code and the native clock of the discovering device. In between inquiry
transmissions, the receiver shall scan for inquiry response messages. When a response
is received, the entire packet (an FHS packet) shall be read. If the EIR bit in the FHS
packet is set to one, the device should try to receive the extended inquiry response
packet 1250 μs after the start of the FHS packet. After this, the device shall continue
with inquiry transmissions. The device in an Inquiry substate shall not acknowledge
the inquiry response messages. If enabled by the Host (see HCI [Vol 4] Part E,
Section 7.3.50), the RSSI value of the inquiry response message shall be measured.
It shall keep probing at different hop channels and in between listening for response
packets. As in the Page substate, two 10 ms trains A and B are defined, splitting
the 32 frequencies of the inquiry hopping sequence into two 16-hop parts. A single
train shall be repeated for at least Ninquiry=256 times before a new train is used. In
order to collect all responses in an error-free environment, at least three train switches
must have taken place. As a result, the Inquiry substate may have to last for 10.24 s
unless the inquirer collects enough responses and aborts the Inquiry substate earlier.
If desired, the inquirer may also prolong the Inquiry substate to increase the probability
of receiving all responses in an error-prone environment. When some receive slots are
periodically not available, it may require up to 31 train switches to collect all responses
in an error-free environment, depending on the pattern of the available receive slots.
Before each switch to train A, knudge may be updated. As a result, the Inquiry substate
may have to last for 40.96 s. If an inquiry procedure is automatically initiated periodically

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 2, Part B Page 567
Baseband Specification

(say a 10 s period every minute), then the interval between two inquiry instances shall
be determined randomly. This is done to avoid two devices synchronizing their inquiry
procedures.

The Inquiry substate is continued until stopped by the Baseband Resource Manager
(when it decides that it has sufficient number of responses), when a timeout has been
reached (Inquiry_Length + Extended_Inquiry_Length), or by a command from the Host
to cancel the inquiry procedure.

The Inquiry substate can be entered from the Standby state or the Connection state.
In the Standby state, no connection has been established and the device can use
all the capacity to carry out the inquiry. Before entering the Inquiry substate from the
Connection state, the device should free as much capacity as possible for inquiry.
To ensure this, it is recommended that the ACL logical transports are placed in Sniff
mode or Hold mode. However, the reserved slots of synchronous logical transports shall
not be disturbed by the inquiry. This means that the inquiry will be interrupted by the
reserved SCO and eSCO slots which have higher priority than the inquiry. In order to
obtain as much capacity as possible for inquiry, it is recommended to use the SCO
packets which use the least amount of capacity (HV3 packets). If SCO or eSCO links
are present, the repetition number Ninquiry shall be increased, see Table 8.4.

Here it has been assumed that HV3 packets are used with an interval TSCO=6 slots or
EV3 packets are used with an interval of TeSCO=6 slots, which would correspond to a 64
kb/s synchronous link.

No synchronous links One synchronous link Two synchronous links

(HV3) (HV3)
Ninquiry ≥ 256 ≥ 512 ≥ 768

Table 8.4: Increase of train repetition when synchronous links are present

If an extended inquiry response packet could not be received because of higher priority
traffic, the reception failed due to HEC or CRC failure, or because the packet type is not
supported by the device, the inquiry response shall be reported to higher layers as an
extended inquiry response with all-zero data.

8.4.3 Inquiry Response substate

The response substate for inquiries differs completely from the Peripheral Page
Response substate applied for pages. When the inquiry message is received in the
Inquiry Scan substate, the recipient shall return an inquiry response (FHS) packet
containing the recipient's device address (BD_ADDR) and other parameters. If the
recipient has non-zero extended inquiry response data to send it shall return an
extended inquiry response packet after the FHS packet.

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 2, Part B Page 568
Baseband Specification

The following protocol in the Peripheral's inquiry response shall be used. On the first
inquiry message received in the Inquiry Scan substate the Peripheral shall enter the
Inquiry Response substate. If the Peripheral has non-zero extended inquiry response
data to send it shall return an FHS packet with the EIR bit set to one to the Central
625 μs after the inquiry message was received. It shall then return an extended inquiry
response packet 1250 μs after the start of the FHS packet. If the Peripheral's extended
inquiry response data is all zeroes the Peripheral shall only return an FHS packet with
the EIR bit set to zero. A contention problem could arise when several devices are
in close proximity to the inquiring device and all respond to an inquiry message at
the same time. However, because every device has a free running clock it is highly
unlikely that they all use the same phase of the inquiry hopping sequence. In order
to avoid repeated collisions between devices that wake up in the same inquiry hop
channel simultaneously, a device shall back-off for a random period of time. Thus, if
the device receives an inquiry message and returns an FHS packet, it shall generate a
random number, RAND, between 0 and MAX_RAND. For scanning intervals ≥ 1.28 s
MAX_RAND shall be 1023, however, for scanning intervals < 1.28 s MAX_RAND may
be as small as 127. A profile that uses a special DIAC may choose to use a smaller
MAX_RAND than 1023 even when the scanning interval is ≥ 1.28 s. The Peripheral
shall return to the Connection or Standby state for the duration of at least RAND time
slots. Before returning to the Connection and Standby state, the device may go through
the Page Scan substate. After at least RAND slots, the device shall add an offset of 1
to the phase in the inquiry hop sequence (the phase has a 1.28 s resolution) and return
to the Inquiry Scan substate again. If the Peripheral is triggered again, it shall repeat
the procedure using a new RAND. The offset to the clock accumulates each time an
FHS packet is returned. During a probing window, a Peripheral may respond multiple
times, but on different frequencies and at different times. Reserved synchronous slots
should have priority over response packets; that is, if a response packet overlaps
with a reserved synchronous slot, it shall not be sent but the next inquiry message
is awaited. If a device has extended inquiry response data to send but the extended
inquiry response packet overlaps with a reserved synchronous slot the FHS packet may
be sent with the EIR bit set to zero.

The messaging during the inquiry routines is summarized in Table 8.5. In step 1, the
Central transmits an inquiry message using the inquiry access code and its own clock.
The Peripheral responds with the FHS packet containing the Peripheral’s Bluetooth
Device Address, native clock and other Peripheral information. This FHS packet is
returned at times that tend to be random. The FHS packet is not acknowledged in
the inquiry routine, but it is retransmitted at other times and frequencies as long as
the Central is probing with inquiry messages. If the Peripheral has non-zero extended
inquiry response data it sends an extended inquiry response packet to the Central in
step 3.

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 2, Part B Page 569
Baseband Specification

The extended inquiry response packet is an ACL packet with type DM1, DM3, DM5,
DH1, DH3 or DH5. To minimize interference it is recommended to use the shortest
packet that fits the data. The packet shall be sent on the same frequency as the FHS
packet, 1250 µs after the start of the FHS packet. In the packet header, LT_ADDR shall
be set to zero. TYPE shall be one of DM1, DM3, DM5, DH1, DH3 or DH5. FLOW,
ARQN and SEQN shall all be set to zero and ignored during receipt. The HEC LFSR
shall be initialized with the same DCI (default check initialization) as for the FHS packet.
In the payload header, LLID shall contain the value 10 (start of an L2CAP message
or no fragmentation). FLOW shall be set to zero and ignored upon receipt. The length
of the payload body (LENGTH) shall be smaller than or equal to 240 bytes. The CRC
LFSR shall be initialized with the same DCI as for the FHS packet. The data whitening
LFSR shall be initialized with the same value as for the FHS packet.

The payload data has two parts, a significant part followed by a non-significant part.
The significant part contains a sequence of data structures as defined in [Vol 3] Part C,
Section 8. The non-significant part contains all-zero octets.

The Baseband shall not change any octets in the significant part. When transmitting
data, the non-significant part octets may be omitted from the payload.

A device shall store a single extended inquiry response packet. This packet shall be
used with all IACs.

Step Message Packet Direction Hopping Access Code

Type Sequence and Clock
1 Inquiry ID Central to Periph- inquiry inquiry
eral
2 Inquiry response FHS Peripheral to Cen- inquiry response inquiry
tral
3 Extended Inquiry DM1, DM3, Peripheral to Cen- same frequency as inquiry
Response DM5, DH1, tral step 2
DH3, DH5

Table 8.5: Messaging during inquiry routines

8.5 Connection state

In the Connection state, the connection has been established and packets can be
sent back and forth, with the exception of Connectionless Peripheral Broadcast mode,
in which case packets are only sent from the Central. In both devices, the channel
access code (derived from the Central's BD_ADDR), the Central's Bluetooth clock, and
the AFH_channel_map are used. Connection state uses the basic or adapted channel
hopping sequence.

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 2, Part B Page 570
Baseband Specification

There are two ways to enter the Connection state. A device can transition from the
Page or Page Scan substates to the Connection state or directly from the Standby state
to the Connectionless Peripheral Broadcast mode of the Connection state.

If a device enters from the Page or Page Scan substates, the Connection state starts
with a POLL packet sent by the Central to verify the switch to the Central’s timing and
channel frequency hopping. The Peripheral may respond with a NULL, DM1, or DH1
packet. If the Peripheral does not receive the POLL packet or the Central does not
receive the response packet for newconnectionTO number of slots, both devices shall
return to Page or Page Scan substate.

The first information packets in the Connection state contain control messages that
characterize the link and give more details regarding the devices. These messages are
exchanged between the link managers of the devices. For example, they may define
the SCO logical transport and the sniff parameters. Then the transfer of user information
can start by alternately transmitting and receiving packets.

The Connection state is left through a Detach or Reset command. The Detach
command is used if the link has been disconnected in the normal way; all configuration
data in the Link Controller shall remain valid. The Reset command is a soft reset of
the Link Controller. The functionality of the soft reset is described in [Vol 4] Part E,
Section 7.3.2.

In the Connection state, if a device is not going to be nominally present on the channel
at all times it may describe its unavailability by using Sniff mode or Hold mode (see
Figure 8.7).

If a device enters the Connectionless Peripheral Broadcast mode of the Connection

state, the Transmitter (Central) starts by sending packets on the CPB logical transport
and the Receiver (Peripheral) starts by receiving packets sent on the CPB logical
transport.

CONNECTION State
Connectionless
Peripheral Active
Broadcast mode mode

Sniff Hold
mode mode

Figure 8.7: Connection state

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 2, Part B Page 571
Baseband Specification

8.6 Active mode

In the Active mode, both Central and Peripheral actively participate on the channel.
Up to seven Peripherals may be in the Active mode at any given time in a piconet.
The Central schedules the transmission based on traffic demands to and from the
different Peripherals. In addition, it supports regular transmissions to keep Peripherals
synchronized to the channel. Peripherals in the Active mode listen in the Central-to-
Peripheral slots for packets. These devices are known as active Peripherals. If an
active Peripheral is not addressed, it may sleep until the next new Central transmission.
Peripherals can derive the number of slots the Central has reserved for transmission
from the TYPE field in the packet header; during this time, the non-addressed
Peripherals do not have to listen on the Central-to-Peripheral slots. When a device
is participating in multiple piconets it should listen in the Central-to-Peripheral slot for
the current piconet. It is recommended that a device not be away from each piconet
in which it is participating for more than Tpoll slots. A periodic Central transmission is
required to keep the Peripherals synchronized to the channel. Since the Peripherals
only need the channel access code to synchronize, any packet type can be used for this
purpose.

Only the Peripheral that is addressed by one of its LT_ADDRs (primary or secondary)
may return a packet in the next Peripheral-to-Central slot. If no valid packet header is
received, the Peripheral may only respond in its reserved SCO or eSCO Peripheral-to-
Central slot. In the case of a broadcast message, no Peripheral shall return a packet.

TX
Central 1 2 2 1
RX

TX

Peripheral 1 RX

TX

Peripheral 2 RX

Figure 8.8: RX/TX timing in multi-Peripheral configuration

For ACL logical transports the mode selection may be left to real time packet type
selections. The packet type table (ptt) in Section 6.5 allows the selection of Basic Rate
or Enhanced Data Rate for each of the packet type codes, however; the DM1 packet is

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 2, Part B Page 572
Baseband Specification

available in all packet type tables. ACL traffic over this given physical or logical link shall
utilize the packet types in the given column of Table 6.2.

8.6.1 Polling in the Active mode

The Central always has full control over the piconet. Due to the TDD scheme,
Peripherals can only communicate with the Central and not other Peripherals. In order
to avoid collisions on the ACL logical transport, a Peripheral is only allowed to transmit
in the Peripheral-to-Central slot when addressed by the LT_ADDR in the packet header
in the preceding Central-to-Peripheral slot. If the LT_ADDR in the preceding slot does
not match, or a valid packet header was not received, the Peripheral shall not transmit.

The Central normally attempts to poll a Peripheral's ACL logical transport no less
often than once every Tpoll slots. Tpoll is set by the Link Manager (see [Vol 2] Part
C, Section 4.1.8).

The Peripheral's ACL logical transport may be polled with any packet type except
for FHS and ID. For example, polling during SCO may use HV packets, since the
Peripheral may respond to an HV packet with a DM1 packet (see Section 8.6.2).

8.6.2 SCO

The SCO logical transport shall be established by the Central sending a SCO setup
message via the LM protocol. This message contains timing parameters including the
SCO interval TSCO and the offset DSCO to specify the reserved slots.

In order to prevent clock wrap-around problems, an initialization flag in the SCO setup
message indicates whether initialization procedure 1 or 2 is being used. The Peripheral
shall apply the initialization method as indicated by the initialization flag. The Central
shall use initialization 1 when the MSB of the Central's current clock (CLK27) is 0; it
shall use initialization 2 when the MSB of the Central's current clock (CLK27) is 1. The
Central-to-Peripheral SCO slots reserved by the Central and the Peripheral shall be
initialized on the slots for which the clock satisfies the applicable equation:

CLK27 − 1 mod T SCO=DSCO for initialization 1

CLK27, CLK26 − 1 mod T SCO=DSCO for initialization 2
The Peripheral-to-Central SCO slots shall directly follow the reserved Central-to-
Peripheral SCO slots. After initialization, the clock value CLK(k+1) for the next Central-
to-Peripheral SCO slot shall be derived by adding the fixed interval TSCO to the clock
value of the current Central-to-Peripheral SCO slot:

CLK27 − 1 k + 1 = CLK27 − 1 k + T SCO

The Central will send SCO packets to the Peripheral at regular intervals (the SCO
interval TSCO counted in slots) in the reserved Central-to-Peripheral slots. An HV1

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 2, Part B Page 573
Baseband Specification

packet can carry 1.25 ms of speech at a 64 kb/s rate. An HV1 packet shall therefore be
sent every two time slots (TSCO=2). An HV2 packet can carry 2.5 ms of speech at a 64
kb/s rate. An HV2 packet shall therefore be sent every four time slots (TSCO=4). An HV3
packet can carry 3.75 ms of speech at a 64 kb/s rate. An HV3 packet shall therefore be
sent every six time slots (TSCO=6).

The Peripheral is allowed to transmit in the slot reserved for its SCO logical transport
unless a packet with the correct access code was received in the preceding slot and the
LT_ADDR did not address this Peripheral (irrespective of whether or not the HEC was
correct). If the correct LT_ADDR was received in the preceding slot but the HEC was
incorrect, the Peripheral should not transmit in the reserved SCO slot.

Since the DM1 packet is recognized on the SCO logical transport, it may be sent during
the SCO reserved slots if a valid packet header with the primary LT_ADDR is received
in the preceding slot. DM1 packets sent during SCO reserved slots shall only be used to
send ACL-C data.

The Peripheral shall not transmit anything other than an HV packet in a reserved SCO
slot unless it decodes its own Peripheral address in the packet header of the packet in
the preceding Central-to-Peripheral transmission slot.

8.6.3 eSCO

The eSCO logical transport is established by sending an eSCO setup message via
the LM protocol. This message contains timing parameters including the eSCO interval
TeSCO and the offset DeSCO to specify the reserved slots.

To enter eSCO, the Central or Peripheral shall send an eSCO setup message via
the LM protocol. This message shall contain the eSCO interval TeSCO and an offset
DeSCO. In order to prevent clock wrap-around problems, an initialization flag in the
eSCO setup message indicates whether initialization procedure 1 or 2 shall be used.
The device sending the eSCO setup message shall use initialization 1 when the MSB
of the Central's current clock (CLK27) is 0; it shall use initialization 2 when the MSB
of the Central's current clock (CLK27) is 1. The device that receives the eSCO setup
message shall apply the initialization method as indicated by the initialization flag. The
Central-to-Peripheral eSCO slots reserved by the Central and the Peripheral shall be
initialized on the slots for which the clock satisfies the applicable equation:

CLK27 − 1 mod T eSCO= DeSCO for initialization 1

CLK27, CLK26 − 1 mod T eSCO= DeSCO for initialization 2

The Peripheral-to-Central eSCO slots shall directly follow the reserved Central-to-
Peripheral eSCO slots. After initialization, the clock value CLK(k+1) for the next Central-

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 2, Part B Page 574
Baseband Specification

to-Peripheral eSCO slot shall be found by adding the fixed interval TeSCO to the clock
value of the current Central-to-Peripheral eSCO slot:

CLK27 − 1 k + 1 = CLK27 − 1 k + T eSCO

When an eSCO logical transport is established, the Central shall assign an additional
LT_ADDR to the Peripheral. This provides the eSCO logical transport with an ARQ
scheme that is separate from that of the ACL logical transport. All traffic on a particular
eSCO logical transport, and only that eSCO traffic, is carried on the eSCO LT_ADDR.
The eSCO ARQ scheme uses the ARQN bit in the packet header, and operates
similarly to the ARQ scheme on ACL links.

The Central may send a packet in the reserved Central-to-Peripheral slot. The
Peripheral may transmit on the eSCO LT_ADDR in the following slot either if it received
a packet on the eSCO LT_ADDR in the previous slot, or if it did not receive a valid
packet header in the previous slot. When the Central-to-Peripheral packet type is a
three-slot packet, the Peripheral’s transmit slot is the fourth slot of the eSCO reserved
slots.

A Central shall transmit in an eSCO retransmission window on a given eSCO LT_ADDR

only if it addressed that eSCO LT_ADDR or did not transmit any packet in the
immediately preceding eSCO reserved slots. A Peripheral shall transmit in an eSCO
retransmission window on a given eSCO LT_ADDR only if it received a valid packet
header and that LT_ADDR on the eSCO channel in the previous Central-to-Peripheral
transmission slot. The Central may transmit on any non-eSCO LT_ADDR in any
Central-to-Peripheral transmission slot inside the eSCO retransmission window; if it
addresses a Peripheral, that Peripheral may respond on the ACL channel as usual.

The Central shall only transmit on an eSCO LT_ADDR in the retransmission window if
there are enough slots left for both the Central and Peripheral packets to complete
in the retransmission window. If the Central is transmitting a NULL packet (with
ARQN=ACK), then this requires one slot, otherwise it requires enough slots for the
Central’s negotiated eSCO packet type plus:

• if the Central’s packet has ARQN=NAK, then enough slots for the Peripheral’s
negotiated eSCO packet type;
• if the Central’s packet has ARQN=ACK, then one slot.

The Central may refrain from transmitting in any slot during the eSCO retransmission
window. When there is no data to transmit from Central to Peripheral, either due to
the traffic being unidirectional or due to the Central-to-Peripheral packet having been
ACK’ed, the Central shall use the POLL packet. When the Central-to-Peripheral packet
has been ACK’ed, and the Peripheral-to-Central packet has been correctly received,
the Central shall not address the Peripheral on the eSCO LT_ADDR until the next

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 2, Part B Page 575
Baseband Specification

eSCO reserved slot, with the exception that the Central may transmit a NULL packet
with ARQN=ACK on the eSCO LT_ADDR. If the Central is transmitting on the eSCO
LT_ADDR during a retransmission slot and there is no data to transmit from Peripheral
to Central, either due to the traffic being unidirectional or due to the Peripheral-to-
Central packet having been ACK'ed, the Peripheral shall use NULL packets. eSCO
traffic should be given priority over ACL traffic in the retransmission window.

Figure 8.9 shows the eSCO window when single slot packets are used.

eSCO Retransmission eSCO Retransmission

Instant Window Instant Window

C C

P P

eSCO Window eSCO Window

Figure 8.9: eSCO window details for single-slot packets

When multi-slot packets are used in either direction of the eSCO logical transport, the
first transmission continues into the following slots. The retransmission window in this
case starts the slot after the end of the Peripheral-to-Central packet, i.e. two, four or six
slots immediately following the eSCO instant are reserved and should not be used for
other traffic. Figure 8.10 shows the eSCO window when multi-slot packets are used in
one direction and single-slot packets are used in the other direction.

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 2, Part B Page 576
Baseband Specification

eSCO
Instant

Reserved Retransmission
Slots Window

eSCO Window

Figure 8.10: eSCO window details for asymmetric traffic

eSCO windows may overlap on the Central, but shall not overlap on an individual
Peripheral.

In the reserved slots both Central and Peripheral shall only listen and transmit at their
allocated slots at the first transmission time of each eSCO window. Intermittent lapses
due to, for instance, time-critical signaling during connection establishment are allowed.
Both Central and Peripheral may refrain from sending data and may use instead POLL
and NULL packets respectively. When the Central transmits a POLL packet instead of
an eSCO 3-slot packet, or the Peripheral does not receive anything in the reserved
Central-to-Peripheral transmission slot, it shall start any transmission in the same slot
as if the Central had transmitted the negotiated packet type. For example, if the Central
had negotiated an EV5 packet the Peripheral would transmit three slots later. If the
Central does not receive a Peripheral transmission in response to an eSCO packet it
causes an implicit NAK of the packet in question. The listening requirements for the
Peripheral during the retransmission window are the same as for an active ACL logical
transport.

8.6.4 Broadcast scheme

The Central of the piconet can broadcast messages to all Peripherals on the APB
logical transport. An APB broadcast packet shall have an LT_ADDR set to all zero. If a
new broadcast message carries APB-U data, it may be fragmented in the same way as
ACL packets. Therefore it shall start with a packet carrying the start of L2CAP message
indication (LLID=0b10) and may be followed by packets carrying the continuation of
L2CAP message indication (LLID=0b01). If a new broadcast message carries APB-C
data, it shall not be fragmented and shall consist of a single packet carrying the LMP
message indication (LLID=0b11). In either case, the Central may carry out a number
of retransmissions of each of these packets to increase the probability for error-free
delivery; see also Section 7.6.5.

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 2, Part B Page 577
Baseband Specification

A broadcast packet shall never be acknowledged by the Baseband.

The Broadcast LT_ADDR shall use a ptt=0.

8.6.5 Role switch

There are several occasions when a role switch is used:

• A role switch is necessary in order to make a paging device a Peripheral when

joining an existing piconet, since by definition the paging device is initially Central of a
piconet involving the pager (Central) and the paged (Peripheral) device.
• A role switch is necessary in order for a Peripheral in an existing piconet to set up
a new piconet with itself as Central and the original piconet Central as Peripheral.
If the original piconet had more than one Peripheral, then this implies a double role
for the original piconet Central; it becomes a Peripheral in the new piconet while still
maintaining the original piconet as Central.

Prior to the role switch, encryption if present, shall be paused or disabled in the old
piconet. A role switch shall not be performed if the physical link is in Sniff or Hold mode,
or has any synchronous logical transports.

For the Central and Peripheral involved in the role switch, the switch results in a
reversal of their TX and RX timing: a TDD switch. Additionally, since the piconet
parameters are derived from the Bluetooth Device Address and clock of the Central, a
role switch inherently involves a redefinition of the piconet as well: a piconet switch. The
new piconet's parameters shall be derived from the former Peripheral's device address
and clock.

Assume device A is to become Central; device B was the former Central. Then there
are two alternatives: either the Peripheral initiates the role switch or the Central initiates
the role switch. These alternatives are described in Link Manager Protocol, [Vol 2] Part
C, Section 4.4.2. The Baseband procedure is the same regardless of which alternative
is used.

To begin the role switch, A and B shall perform a TDD switch using the former hopping
scheme (still using the Bluetooth Device Address and clock of device B), so there is
no piconet switch yet. The slot offset information sent by A shall not be used yet; it is
used when both devices have switched to the new piconet and device B is positioning
its correlation window. Device A now becomes the Central, device B the Peripheral.

At the moment of the TDD switch, both devices A and B shall start a timer with a time
out of newconnectionTO. The timer shall be stopped in B as soon as it receives an FHS
packet from A on the TDD-switched channel. The timer shall be stopped in A as soon
as it receives an ID packet from B. If the newconnectionTO expires, A and B shall return
to the old piconet timing and AFH state, taking their old roles of Peripheral and Central

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 2, Part B Page 578
Baseband Specification

respectively. The FHS packet shall be sent by A using the "old" piconet parameters.
The LT_ADDR in the FHS packet header shall be the former LT_ADDR used by device
A. The LT_ADDR carried in the FHS payload shall be the new LT_ADDR intended for
device B when operating on the new piconet. After the FHS acknowledgment, which
is the ID packet and shall be sent by B on the old hopping sequence, both A and B
shall use the new channel parameters of the new piconet as indicated by the FHS with
the sequence selection set to basic channel hopping sequence. If the new Central A
has physical links that are AFH enabled, following the piconet switch the new Central is
responsible for controlling the AFH operational mode of its new Peripheral B.

Since the old and new Centrals' clocks are synchronized, the clock information sent
in the FHS payload shall indicate the new Central's clock at the beginning of the FHS
packet transmission. Furthermore, the 1.25 ms resolution of the clock information given
in the FHS packet is not sufficient for aligning the slot boundaries of the two piconets.
The slot-offset information in the LMP message previously sent by device A shall be
used to provide more accurate timing information. The slot offset indicates the delay
between the start of the Central-to-Peripheral slots of the old and new piconet channels.
This timing information ranges from 0 to 1249 μs with a resolution of 1 μs. It shall be
used together with the clock information in the FHS packet to accurately position the
correlation window when switching to the new Central's timing after acknowledgment of
the FHS packet.

After reception of the FHS packet acknowledgment, the new Central A shall switch to
its own timing with the sequence selection set to the basic channel hopping sequence
and shall send a POLL packet to verify the switch. Both A and B shall start a new
timer with a time out of newconnectionTO on FHS packet acknowledgment. The start
of this timer shall be aligned with the beginning of the first Central TX slot boundary
of the new piconet, following the FHS packet acknowledgment. B shall stop the timer
when the POLL packet is received; A shall stop the timer when the POLL packet is
acknowledged. The Peripheral B shall respond with a NULL, DM1, or DH1 packet to
acknowledge the POLL. Any pending AFH_Instant shall be cancelled once the POLL
packet has been received by the Peripheral. If no response is received, A shall re-send
the POLL packet until newconnectionTO is reached. If this timer expires, both A and B
shall return to the old piconet timing with the old roles: B as Central and A as Peripheral.
Expiry of the timer shall also restore the state associated with AFH (including any
pending AFH_Instant), Channel Quality Driven Data Rate (CQDDR, Link Manager
Protocol [Vol 2] Part C, Section 4.1.7) and power control (Link Manager Protocol [Vol 2]
Part C, Section 4.1.3). The role switch procedure may then restart from the TDD switch.
Aligning the timer with TX boundaries of the new piconet ensures that no device returns
to the old piconet timing in the middle of a Central RX slot.

The messaging during a successful role switch is summarized in Table 8.6.

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 2, Part B Page 579
Baseband Specification

Step Message or Packet Type Direction Central

1 LMP_ACCEPTED Responder → Initiator B
2 FHS A→B B
3 ID B→A B
4 POLL A→B A
5 NULL/DM1/DH1 B→A A

Table 8.6: Messaging during successful role switch

After the role switch the ACL logical transport is reinitialized as if it were a new
connection. For example, the SEQN of the first data packet containing a CRC on the
new piconet channel shall be set according to the rules in Section 7.6.2.

8.6.6 Scatternet

Multiple piconets can cover the same area. Since each piconet has a different Central,
the piconets hop independently, each with their own hopping sequence and phase as
determined by the respective Central. In addition, the packets carried on the channels
are preceded by different channel access codes as determined by the Centrals’ device
addresses. As more piconets are added, the probability of collisions increases; a
graceful degradation of performance results as is common in frequency-hopping spread
spectrum systems.

If multiple piconets cover the same area, a device can participate in two or more
overlaying piconets by applying time multiplexing. To participate on the proper channel,
it shall use the associated Central’s device address and proper clock offset to obtain
the correct phase. A device can act as a Peripheral in several piconets, but only as a
Central in a single piconet: since two piconets with the same Central are synchronized
and use the same hopping sequence, they are one and the same piconet. A group of
piconets in which connections exist between different piconets is called a scatternet.

A Central or Peripheral can become a Peripheral in another piconet by being paged by

the Central of this other piconet. On the other hand, a device participating in one piconet
can page the Central or Peripheral of another piconet. Since the paging device always
starts out as Central, a role switch is required if a Peripheral role is desired. This is
described in Section 8.6.5.

8.6.6.1 Inter-piconet communications

Time multiplexing must be used to switch between piconets. Devices may achieve
the time multiplexing necessary to implement scatternet by using Sniff mode or by
remaining in an active ACL connection. For an ACL connection in piconets where the
device is a Peripheral in the Connection state, it may choose not to listen in every
Central slot. In this case it should be recognized that the quality of service on this

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 2, Part B Page 580
Baseband Specification

link can degrade abruptly if the Peripheral is not present enough to match up with the
Central polling that Peripheral. Similarly, in piconets where the device is Central it may
choose not to transmit in every Central slot. In this case it is important to honor Tpoll
as much as possible. Devices in Sniff mode could have sufficient time to visit another
piconet in between sniff slots. When the device is a Peripheral using Sniff mode and
there are not sufficient idle slots, the device may choose to not listen to all Central
transmission slots in the sniff_attempts period or during the subsequent sniff_timeout
period. A Central is not required to transmit during sniff slots and therefore has flexibility
for scatternet. If SCO or eSCO links are established, other piconets shall only be visited
in the non-reserved slots in between reserved slots. This is only possible if there is a
single SCO logical transport using HV3 packets or eSCO links where at least four slots
remain in between the reserved slots. Since the multiple piconets are not synchronized,
guard time must be left to account for misalignment. This means that only 2 slots can
effectively be used to visit another piconet in between the HV3 packets.

Since the clocks of two Centrals of different piconets are not synchronized, a Peripheral
participating in two piconets shall maintain two offsets that, added to its own native
clock, create the two Centrals' clocks. Since the two Centrals' clocks drift independently,
the Peripheral must regularly update the offsets in order to keep synchronization to both
Centrals.

8.6.7 Hop sequence switching

Hop sequence adaptation is controlled by the Central and can be set to either enabled
or disabled. Once enabled, hop sequence adaptation shall apply to all logical transports
on a physical link. Once enabled, the Central may periodically update the set of used
and unused channels as well as disable hop sequence adaptation on a physical link.
When a Central has multiple physical links the state of each link is independent of all
other physical links.

When hop sequence adaptation is enabled, the sequence selection hop selection kernel
input is set to adapted channel hopping sequence and the AFH_channel_map input is
set to the appropriate set of used and unused channels. Additionally, the same channel
mechanism shall be used. When hop sequence adaptation is enabled with all channels
used this is known as AHS(79).

When hop sequence adaptation is disabled, the sequence selection input of the hop
selection kernel is set to basic channel hopping sequence (the AFH_channel_map input
is unused in this case) and the same channel mechanism shall not be used.

The hop sequence adaptation state shall be changed when the Central sends
the LMP_SET_AFH PDU and a Baseband acknowledgment is received. When the
Baseband acknowledgment is received prior to the hop sequence switch instant,
AFH_Instant, (See Link Manager Protocol [Vol 2] Part C, Section 4.1.4) the hop
sequence proceeds as shown in Figure 8.11.

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 2, Part B Page 581
Baseband Specification

AFH_Instant
AFH CMD
Central t

ACK
Peripheral t

Hop Sequence
Non-AHS AHS(A)
(Enabling)
Hop Sequence AHS(A) Non-AHS
(Disabling)
Hop Sequence AHS(A) AHS(B)
(Updating)

Figure 8.11: Successful hop sequence switching

When the Baseband acknowledgment is not received prior to the AFH_Instant the
Central shall use a recovery hop sequence for the Peripheral(s) that did not respond
with an acknowledgment (this may be because the Peripheral did not hear the Central’s
transmission or the Central did not hear the Peripheral’s transmission). When hop
sequence adaptation is being enabled or disabled the recovery sequence shall be the
AFH_channel_map specified in the LMP_SET_AFH PDU. When the AFH_channel_map
is being updated the Central shall choose a recovery sequence that includes all of
the RF channels marked as used in either the old or new AFH_channel_map, e.g.
AHS(79). Once the Baseband acknowledgment is received the Central shall use the
AFH_channel_map in the LMP_SET_AFH PDU starting with the next transmission to
the Peripheral. See Figure 8.12.

AFH_Instant
AFH CMD
Central t

ACK
Peripheral ? ?
t

Hop Sequence
Non-AHS AHS(A)
(Enabling)
Hop Sequence AHS(A) Non-AHS
(Disabling)
Hop Sequence AHS(A) AHS(B)
Recovery
(Updating)
Sequence

Figure 8.12: Recovery hop sequences

When the AFH_Instant occurs during a multi-slot packet transmitted by the Central, the
Peripheral shall use the same hopping sequence parameters as the Central used at the
start of the multi-slot packet. An example of this is shown in Figure 8.13. In this figure
the basic channel hopping sequence is designated f. The first adapted channel hopping

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 2, Part B Page 582
Baseband Specification

sequence is designated with f', and the second adapted channel hopping sequence is
designated f''.

f f f' f'
k k+3 k+4 k+4

Central
3-slot packet
Tx
Enabling

Peripheral
Tx
CLK k k+1 k+2 k+3 k+4 k+5

AFH_Instant
f' f' f" f"
i i i+4 i+4

Central
3-slot packet
Tx
Updating

Peripheral
Tx
CLK i i+1 i+2 i+3 i+4 i+5

AFH_Instant
f" f" f f
j j j+4 j+5
Central
3-slot packet
Tx
Disabling

Peripheral
Tx
CLK j j+1 j+2 j+3 j+4 j+5

AFH_Instant

Figure 8.13: AFH_Instant changes during multi-slot packets transmitted by the Central

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 2, Part B Page 583
Baseband Specification

8.6.8 Channel classification and channel map selection

RF channels are classified as being unknown, bad or good. These classifications are
determined individually by the Central and Peripherals based on local information (e.g.
active or passive channel assessment methods or from the Host via HCI). Information
received from other devices via LMP (for example, an AFH_channel_map from a
Central or a channel classification report from a Peripheral) shall not be included in
a device’s channel classification.

The three possible channel classifications shall be as defined in Table 8.7.

Classification Definition
unknown A channel shall be classified as unknown if the channel assessment measurements
are insufficient to reliably classify the channel, and the channel is not marked as bad
in the most recent HCI_ Set_AFH_Host_Channel_Classification command.
bad A channel may be classified as bad if an ACL or synchronous throughput failure
measure associated with it has exceeded a threshold (defined by the particular chan-
nel assessment algorithm employed).
A channel may also be classified as bad if an interference-level measure associated
with it, determining the interference level that the link poses upon other systems in
the vicinity, has exceeded a threshold (defined by the particular channel assessment
algorithm employed).
A channel shall be classified as bad when it is marked as bad in the most recent
HCI_ Set_AFH_Host_Channel_Classification command.
good A channel shall be classified as good if it is not either unknown or bad.
Table 8.7: Channel classification descriptions

A Central with AFH enabled physical links shall determine an AFH_channel_map for
each such link (two or more links may use the same map) based on any combination of
the following information:

• Channel classification from local measurements (e.g. active or passive channel

assessment in the Controller), if supported and enabled. The Host may enable or
disable local measurements using the HCI_ Write_AFH_Channel_Assessment_Mode
command, defined in the HCI Functional Specification [Vol 4] Part E, Section 7.3.54 if
HCI is present.
• Channel classification information from the Host using the HCI_
Set_AFH_Host_Channel_Classification command, defined in the HCI Functional
Specification [Vol 4] Part E, Section 7.3.46 if HCI is present. Channels classified as
bad in the most recent AFH_Host_Channel_Classification shall be marked as unused
in the AFH_channel_map.
• Channel classification reports received from Peripherals in
LMP_CHANNEL_CLASSIFICATION PDUs, defined in the LMP Specification [Vol 2]
Part C, Section 4.1.5.

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 2, Part B Page 584
Baseband Specification

The algorithm used by the Central to combine these information sources and generate
the AFH_channel_map is not defined in the specification and will be implementation
specific. At no time shall the number of channels used be less than Nmin, defined in
Section 2.3.1.

If a Central determines that all channels should be used, it may keep AFH operation
enabled using an AFH_channel_map of 79 used channels, i.e., AHS(79).

For all devices that support the Synchronization Train substate (see Section 8.11.2), the
RF channel indices used for the Synchronization Train (see Section 2.6.4.8) shall be
marked as unused in the AFH_channel_map for all logical links.

8.6.9 Power management

Features are provided to allow low-power operation. These features are both at the
microscopic level when handling the packets, and at the macroscopic level when using
certain operation modes.

8.6.9.1 Packet handling

In order to minimize power consumption, packet handling is minimized both at TX and

RX sides. At the TX side, power is minimized by only sending useful data. This means
that if only link control information needs to be exchanged, NULL packets may be used.
No transmission is required if there is no link control information to be sent, or if the
transmission would only involve a NAK (NAK is implicit on no reply). If there is data to
be sent, the payload length shall be adapted in order to send only the valid data bytes.
At the RX side, packet processing takes place in different steps. If no valid access code
is found in the search window, the transceiver may return to sleep. If an access code is
found, the receiver device shall start to process the packet header. If the HEC fails, the
device may return to sleep after the packet header. A valid header indicates if a payload
will follow and how many slots are involved.

8.6.9.2 Slot occupancy

As was described in Section 6.5, the packet type indicates how many slots a packet
may occupy. A Peripheral not addressed in the packet header may go to sleep for the
remaining slots the packet occupies. This can be read from the TYPE code.

8.6.9.3 Recommendations for low-power operation

The most common and flexible method for reducing power consumption is the use of
Sniff mode. Hold mode can also be used by repeated negotiation of hold periods.

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 2, Part B Page 585
Baseband Specification

8.6.9.4 Enhanced Data Rate

Enhanced Data Rate provides power saving because of the ability to send a given
amount of data in either fewer packets or with the same (or similar) number of packets
but with shorter payloads.

8.6.10 Piconet clock adjustment

A Central may adjust the piconet clock during the existence of a piconet using two
mechanisms: Coarse Clock Adjustment and Clock Dragging. Both mechanisms may be
used within the same piconet.

8.6.10.1 Coarse clock adjustment

The Central carries out a coarse clock adjustment by selecting an adjustment instant
(clk_adj_instant), which shall be a Central-to-Peripheral slot, and the amount of the
adjustment, and then broadcasting these parameters to all Peripherals by sending
LMP_CLK_ADJ (see [Vol 2] Part C, Section 4.1.14.1). The amount of the adjustment is
specified as two values: clk_adj_slots, which is the change in the value of CLK[27:1] at
the clk_adj_instant, and clk_adj_us, which is the number of microseconds between the
start of a Central slot in the old clock (CLKold) and in the new clock (CLKnew) domains.

The Central shall provide the opportunity for each Peripheral to acknowledge the
adjustment with LMP_CLK_ADJ_ACK (see [Vol 2] Part C, Section 4.1.14.1). If
the Central receives any other packet than LMP_CLK_ADJ_ACK with the current
clk_adj_id, it should poll the Peripheral more times until the expected acknowledgment
is received or the Peripheral responds with a NULL packet. If any Peripheral does
not acknowledge the adjustment, the Central shall start the Coarse Clock Adjustment
Recovery Mode (see Section 8.6.10.2).

When the clk_adj_instant occurs, the Central will add (clk_adj_slots × 625 +
clk_adj_us) µs to time_base_offset and the Peripheral(s) will add the same amount
to peripheral_clock_offset. If the clk_adj_instant occurs during a multi-slot packet the
adjustment is delayed until the start of the following Central-to-Peripheral slot. If a role
switch is successful prior to the clk_adj_instant, the pending coarse clock adjustment
shall be discarded. The effect of the adjustment is that devices will use the new clock
domain starting at clk_adj_instant.

Figure 8.14 shows an example of a positive clock adjustment. In this example the
clk_adj_instant is set to slot 12 (which is in the old clock domain), clk_adj_slots is
set to 6 and clk_adj_us is set to 400. Time is moved forward clk_adj_slots × 625 +
clk_adj_us = 6 × 625 + 400 = 4150 µs. The initial slot in the new clock domain is at
CLKnew[27:1] = clk_adj_instant + clk_adj_slots = 12 + 6 = 18. This is an even value
so the first slot is a Central-to-Peripheral slot. A positive clk_adj_us means that the
first slot is assumed to have started clk_adj_us before the clk_adj_instant, and hence

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 2, Part B Page 586
Baseband Specification

only 625 – clk_adj_us = 225 µs remains after the instant. Since transmissions cannot
be started part way through a slot, this partial slot is unusable. The first complete slot
after the clk_adj_instant is a Peripheral-to-Central slot which can be used, for example,
for eSCO. If clk_adj_slots had been an odd number, the first complete slot would have
been a Central-to-Peripheral slot. The first complete Central-to-Peripheral slot in this
example happens at CLKnew[27:1] = 20.

clk_adj_instant = 12

CLKold[27:1] 11 12 13

17 18 19 20
CLKnew [27:1]
625 µs
clk_adj_us
= 400 µs
start of slot
clk_adj_instant +
clk_adj_slots =
12 + 6 = 18

Last Peripheral slot Unusable First new Peripheral slot First new complete Central
in CLKold domain 225 µs in CLKnew domain slot in CLKnew domain

Figure 8.14: Positive coarse clock adjustment

Figure 8.15 shows an example of a negative clock adjustment. In this example the
clk_adj_instant is again set to slot 12, clk_adj_slots is set to 0 and clk_adj_us is set to
–400. Time is moved by clk_adj_slots × 625 + clk_adj_us = 0 × 625 + (–400) = –400 µs,
which is 400 µs backwards. The initial slot in the CLKnew domain is at CLKnew[27:1] =
clk_adj_instant + clk_adj_slots = 12 + 0 = 12. This is an even value so the first slot is a
Central-to-Peripheral slot. A negative clk_adj_us means that the first slot in the CLKnew
domain starts clk_adj_us after clk_adj_instant. The time between the first slot in the
CLKnew domain and clk_adj_instant (in this case 400 µs) is effectively a continuation of
the previous slot, even if its number changes, and hence is unusable. (This is the case
whenever clk_adj_us is negative, even when clk_adj_slots is non-zero.)

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 2, Part B Page 587
Baseband Specification

clk_adj_instant = 12

CLKold[27:1] 11 12 13

CLKnew [27:1] 10 11 12 13

clk_adj_us 625 µs
= - 400 µs

start of slot
clk_adj_instant +
clk_adj_slots =
12 + 0 = 12

Last Peripheral slot Unusable First new Central slot First new Peripheral slot in
in CLKold domain 400 µs in CLKnew domain CLKnew domain

Figure 8.15: Negative coarse clock adjustment

If clk_adj_us is zero then the adjustment alters the slot numbering but not the actual
times at which slots start. Therefore all slots remain available for use, though if
clk_adj_slots is odd then there will be two consecutive Peripheral-to-Central slots.

8.6.10.2 Coarse Clock Adjustment Recovery mode

In Coarse Clock Adjustment Recovery Mode, the Central enters the Synchronization
Train substate (see Section 8.11.2). The Central should remain in this substate
and transmit synchronization train packets until all Peripherals have acknowledged
the adjustment with the LMP_CLK_ADJ_ACK PDU, or link supervision timeout has
expired for the last unresponsive Peripheral. The Central may cancel Coarse Clock
Adjustment Recovery Mode to initiate another coarse clock adjustment or for any other
reason. During Coarse Clock Adjustment Recovery Mode the Central shall continue
broadcasting LMP_CLK_ADJ PDUs (see [Vol 2] Part C, Section 4.1.14.1).

When a Peripheral does not detect any transmissions from its Central it may enter
the Synchronization Scan substate (see Section 8.11.1) and scan for synchronization
train packets as defined in Section 2.7. TSync_Scan_Window should be set large enough to
enable reception of at least one synchronization train packet. A Peripheral that could
have lost its connection to the Central due to coarse clock adjustment should prioritize
synchronization scan.

A Peripheral that receives a Synchronization Train packet with the BD_ADDR of its
Central shall change the value of peripheral_clock_offset to make CLK correspond to
the contents of the packet and then exit the Synchronization Scan substate. If the new
clock is in the range CLKOLD–LSTO to CLKOLD (where LSTO is the link supervision
timeout period), then this shall be treated as a negative change. In this case, the
Peripheral shall not transmit any packet and shall ignore all received directed packets
until the value of CLK, after being changed, is strictly greater than the value of CLK the
last time it transmitted or received (as appropriate) a packet. If the new clock is outside

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 2, Part B Page 588
Baseband Specification

this range then this shall be treated as a positive change (and thus might involve a clock
wrap).

8.6.10.3 Clock Dragging

Clock Dragging means that the Central periodically adjusts its time_base_offset (see
Section 2.2.4) until a desired time adjustment has been accomplished.

Each single adjustment shall be performed by a directed packet from the Central
to each Peripheral and a response (e.g., Baseband acknowledgment) from each
Peripheral. If a Peripheral does not respond, the Central shall suspend its updating
of time_base_offset (but should continue to poll that Peripheral) at least until each
Peripheral has either responded or has failed to respond for at least CLK_adj_dragTO.
In case several Peripherals fail to respond, the Central should ensure that each of
the failing Peripherals gets at least one CLK_adj_dragTO to respond (these may
be concurrent for multiple Peripherals). The Central need not allow more than one
suspension of CLK_adj_dragTO for any given Peripheral during a link supervision
timeout for that Peripheral.

A single adjustment shall be less than or equal to 3 µs. Within any period of 125 ms, the
total adjustment in a single direction shall be less than or equal to 5 µs.

Note: These requirements apply to the changes to time_base_offset and are applied
irrespective of the accuracy of the Central's reference clock (see Section 1.1). This
means that Peripherals may observe a change in CLK greater than 20ppm.

If a Central is performing Clock Dragging when it initiates a Coarse Clock Adjustment,

a new Clock Dragging, or a sequence containing an instant or timing control flags,
or receives a request from a Peripheral to initiate such a sequence, it shall abort
the current Clock Dragging before processing the new request or carrying out the
sequence. If the Central has suspended clock dragging during CLK_adj_dragTO, it shall
reject new requests until the timeout period expires or the timeout is cancelled because
all of the Peripherals have responded.

8.6.11 Slot Availability Mask (SAM)

Slot Availability Mask (SAM) allows two Bluetooth devices to indicate to each other
the availability of their time slots for transmission and reception. From the Baseband
point of view, SAM provides a map - the SAM slot map - which marks the availability
of Bluetooth slots. The availability arises from either external conditions (e.g., MWS
coexistence) or internal conditions (e.g., topology management for scatternets). The
SAM slot map marks each slot using one of four type codes defined in [Vol 2] Part C,
Section 5.2 and repeated for convenience in Table 8.8.

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 2, Part B Page 589
Baseband Specification

Slot type code Meaning

0 The slot is not available for either transmission or reception
1 The slot is available for transmission but not reception
2 The slot is available for reception but not transmission
3 The slot is available for both transmission and reception

Table 8.8: SAM slot types

Note: A Central may mark Central-to-Peripheral slots available for reception and
Peripheral-to-Central slots available for transmission, because such slots may be used
in this way for multi-slot packets; similarly for a Peripheral. A SAM slot map with all slots
set to type 3 is equivalent to not using SAM and simply performing normal scheduling.

Figure 8.16 shows an example of a SAM slot map. The Central-to-Peripheral slots are
labeled with the letter 'C' and Peripheral-to-Central slots with the letter 'P'.

Bluetooth Slot C P C P C P C C P C P
Can Transmit
Can Receive
Type Code 2 0 1 1 1 2 2 3 3 3 2

Figure 8.16: An example of a SAM slot map

A SAM slot map has a finite length and is repeated indefinitely until changed by the
associated LMP procedures. SAM anchor points are spaced regularly with an interval
of TSAM, in units of slots. Between adjacent SAM anchor points, the slot map indicates
when the device is able to transmit and receive. The SAM slot map is effectively
repeated every TSAM until it is changed.

The SAM interval TSAM is further divided into NSAM_SM sub-intervals of equal length,
TSAM_SM, such that TSAM = TSAM_SM × NSAM_SM. TSAM_SM shall be an even integer so as
to contain TX/RX slot pairs.

The words "SAM submap" (or simply "submap" when there is no ambiguity from
the context) will be used to denote a sub-interval of TSAM_SM slots. Each submap is
assigned one of the four usage types defined in [Vol 2] Part C, Section 5.2 and repeated
for convenience in Table 8.9.

Submaptype code Meaning

0 Each slot is individually available or unavailable as configured. Slots may have
different availabilities for transmission and reception.
1 All slots are available for transmission and reception.

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 2, Part B Page 590
Baseband Specification

Submaptype code Meaning

2 All slots are unavailable for transmission and reception.
3 Reserved for future use

Table 8.9: SAM submap types

The SAM facilities specify each SAM slot map at the submap granularity. Figure 8.17
shows an example of a SAM slot map in terms of submaps in the local device. Each box
represents a sub-interval of TSAM_SM slots, with the label on the box indicating the type
of the submap.

At the submap level of granularity, transmit and receive are handled identically; the
difference will only appear inside submaps with type 0.

TSAM_SM

SAM Slot Map

0 0 1 1 1 0 1 1 2 1 2 1 0 0 1 1 0 0 1 ...
Submaps Types

TSAM

Anchor Point

Figure 8.17: Example of a SAM slot map in terms of submaps in the local device

In addition to the SAM slot maps, the Controller also maintains a single "SAM type 0
submap" that is used to specify the availability of individual slots for those submaps
shown as having type 0. The Controller then combines the SAM slot map at submap
granularity with the first TSAM_SM entries of the type 0 submap to generate the effective
maps. Figure 8.18 shows a SAM slot map and a SAM type 0 submap together with the
resulting effective map.

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 2, Part B Page 591
Baseband Specification

TSAM_SM Ignored for this map

C P C P C P C P

SAM Type 0 TX
…………………
Submap RX
Slot Type 1 3 2 0 3 2 3 0
Fixed to 56 Fields

TSAM_SM

SAM Slot Map 1 0 0 2 1

at Submaps
Granularity TSAM

Anchor Point

TSAM_SM
Bluetooth Slot C P C P C P C P C P C P C P C P C P C P
Can Transmit

Can Receive

Type Code 3 3 3 3 1 3 2 0 1 3 2 0 0 0 0 0 3 3 3 3
TSAM

Figure 8.18: Example of a SAM slot map and SAM type 0 submap being combined

Figure 8.19 shows an example of a SAM type 0 submap for a collocated MWS.

Collocated MWS
Downlink
MWS Uplink MWS Downlink
MWS Frame
Bluetooth Slot C P C P C P C P C P C P C P C P
Example Can Transmit
SAM Submap Can Receive
with Type 0
Type Code 2 2 0 1 1 1 1 1 1 2 2 2 2 2 2 2

TSAM_SM

Figure 8.19: Examples of SAM type 0 submap at a Bluetooth device with a collocated MWS

The assumption in the example is that, in order to prevent mutual interference

between Bluetooth and MWS radios, Bluetooth transmissions are not available during
MWS downlink durations and Bluetooth reception is not available during MWS uplink
durations. The MWS frame is 10 ms long and the SAM type 0 submap needs to have
the same length, so TSAM_SM is 16.

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 2, Part B Page 592
Baseband Specification

Figure 8.20 shows another example of a collocated Bluetooth device with a low traffic
load in the MWS Uplink. In this case, the implementation chooses to mark the MWS
Uplink portion available for both TX and RX, because there is a good chance that it can
receive Central packets and respond to them without interference from MWS.

Figure 8.20: Examples of SAM type 0 submap at a Bluetooth device with a collocated MWS with low
uplink traffic load

SAM allows each device to send its local slot availability to the other, in which
case the availability of slots depends on the combined slot maps. The scheduling
recommendations for such a SAM slot map are described in Section 8.6.11.2.

A device that supports the SAM feature shall be capable of storing three distinct SAM
slot maps from each connected remote device. A remote device can only define one
type 0 submap, which can be referenced by any of its defined SAM slot maps. The
remote device may redefine its type 0 submap at any time.

8.6.11.1 SAM anchor point

SAM slot maps are periodic, defined by an interval TSAM and an offset DSAM.
Figure 8.21 shows an example of SAM slot maps designed to correspond to periodic
MWS active and inactivity cycles.

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 2, Part B Page 593
Baseband Specification

MWS MWS MWS MWS MWS MWS MWS

Downlink Uplink Downlink Uplink Inactivity Downlink Uplink

Type 0 Submap Type 0 Submap Type 1 Submap Type 1 Submap Type 0 Submap

TSAM_SM
Anchor Point Anchor Point
TSAM

Figure 8.21: An example of SAM slot maps for a periodic MWS active and inactive cycles

SAM anchor points are the start points of the first slot in the SAM slot maps.
SAM anchor points are computed from TSAM and DSAM using the Central's current
clock, which is known to both devices. The first SAM anchor point is indicated by
SAM_Instant. In order to prevent problems caused by the clock wrap-around, the LMP
message carries an additional timing control flag, which indicates whether initialization
procedure 1 or 2 shall be used. The initiating device shall use initialization 1 when the
MSB of the Central's current clock (CLK27) is 0; it shall use initialization 2 when the
MSB of the Central's current clock (CLK27) is 1. The responding device shall apply the
initialization method indicated by the initialization flag. The SAM anchor points shall be
initialized on the slots for which the clock satisfies the applicable equations:

CLK27 − 1 mod T SAM= DSAM for initialization 1

CLK27, CLK26 − 1 mod T SAM = DSAM for initialization 2
After initialization, the clock value CLK(k+1) for the next SAM anchor point can be found
by adding the fixed interval TSAM to the clock value of the current anchor point:

CLK27 − 1 k + 1 = CLK27 − 1 k + T SAM

The SAM anchor point shall be a Central-to-Peripheral slot. As a corollary, the first slot
of every SAM submap is also a Central-to-Peripheral slot.

8.6.11.2 SAM scheduling

SAM enables each device to send its local slot availability to the other. The scheduler in
the Bluetooth Controller should consider the SAM slot maps from both local and remote
devices for packet scheduling. The only effect of using the SAM information is to restrict
a device's transmission and reception opportunities.

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 2, Part B Page 594
Baseband Specification

For all ACL packets and for eSCO packets in the retransmission window:

1. The Central should only transmit a packet if the required Central-to-Peripheral

slots are marked as available for transmission in the Central's SAM slot map and
available for reception in the Peripheral's SAM slot map.
2. The Peripheral should only transmit a packet if the required slots are marked as
available for reception in the Central's SAM slot map and available for transmission
in the Peripheral's SAM slot map.
3. The Peripheral may choose not to listen to the Central in Central-to-Peripheral slots
that are marked either unavailable for transmission in the Central’s SAM slot map
or unavailable for reception in the Peripheral’s SAM slot map.

For all ACL packets, the Central should only transmit a packet if the slot immediately
following the Central's packet is marked as available for transmission in the Peripheral's
SAM slot map and available for reception in the Central's SAM slot map.

For eSCO packets in the retransmission window, the Central should only transmit a
packet if either:

1. the slot immediately following the Central's packet is marked as available for
transmission in the Peripheral's SAM slot map and available for reception in the
Central's SAM slot map;
2. this is the last opportunity for the Central to transmit this packet in this
retransmission window; or
3. for all subsequent Central-to-Peripheral slots in the same retransmission window
that provide sufficient remaining slots for the Central to transmit the same packet,
the rules in this section state that the Central should not transmit the packet.

In SCO and eSCO reserved slots, either the Central or the Peripheral may choose
not to transmit a SCO or eSCO packet unless the required slots are marked both as
available for transmission in the local SAM slot map and available for reception in the
remote SAM slot map.

Figure 8.22 below illustrates possible scheduling results with combined SAM slot maps
from Central and Peripheral.

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 2, Part B Page 595
Baseband Specification

Bluetooth Slot C P C P C P C P

Can Transmit
at Central

Can Receive
at Central

Can Transmit
at Peripheral

Can Receive
at Peripheral

1-Slot Packet C→P P→C

3-Slot Packet
C→P P→C
(Central)

3-Slot Packet
C→P P→C
(Peripheral)

Figure 8.22: Example of possible scheduling results with combined SAM slot maps from Central and
Peripheral

8.7 Sniff mode

In Sniff mode, the duty cycle of the Peripheral’s activity in the piconet may be reduced.
If a Peripheral is in Active mode on an ACL logical transport, it shall listen in every ACL
slot to the Central’s traffic, unless that link is being treated as a scatternet link or is
absent due to Hold mode. With Sniff mode, the time slots when a Peripheral is listening
are reduced, so the Central shall only transmit to a Peripheral in specified time slots.
The sniff anchor points are spaced regularly with an interval of Tsniff.

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 2, Part B Page 596
Baseband Specification

Sniff interval (Tsniff)

Central-to- Peripheral-to- Central-to- Peripheral-to- Central-to- Peripheral-to-

Peripheral slot Central slot Peripheral slot Central slot Peripheral slot Central slot

Sniff anchor point Sniff anchor point

Figure 8.23: Sniff anchor points

The Peripheral listens in Central-to-Peripheral transmission slots starting at the sniff

anchor point. It shall use the following rules to determine whether to continue listening:

• If fewer than Nsniff attempt Central-to-Peripheral transmission slots have elapsed since
the sniff anchor point then the Peripheral shall continue listening.
• If the Peripheral has received a packet with a matching LT_ADDR that contains
ACL data (DM, DH, or DV packets) in the preceding Nsniff timeout Central-to-Peripheral
transmission slots then it shall continue listening.
• If the Peripheral has transmitted a packet containing ACL data (DM, DH, or DV
packets) in the preceding Nsniff timeout Peripheral-to-Central transmission slots then it
shall continue listening.
• If the Peripheral has received any packet with a matching LT_ADDR in the preceding
Nsniff timeout Central-to-Peripheral transmission slots then it may continue listening.
• A device may override the rules above and stop listening prior to Nsniff timeout or the
remaining Nsniff attempt slots if it has activity in another piconet.

It is possible that activity from one sniff timeout may extend to the next sniff anchor
point. Any activity from a previous sniff timeout shall not affect activity after the next sniff
anchor point. So in the above rules, only the slots since the last sniff anchor point are
considered.

Note: Nsniff attempt=1 and Nsniff timeout=0 cause the Peripheral to listen only at the slot
beginning at the sniff anchor point, irrespective of packets received from the Central.

N sniff attempt =0 shall not be used.

Sniff mode only applies to asynchronous logical transports and their associated
LT_ADDR. Sniff mode shall not apply to synchronous logical transports, therefore,
both Centrals and Peripherals shall still respect the reserved slots and retransmission
windows of synchronous links.

To enter Sniff mode, the Central or Peripheral shall issue a sniff setup message via
the LM protocol. This message includes the sniff interval Tsniff and an offset Dsniff. In

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 2, Part B Page 597
Baseband Specification

addition, an initialization flag indicates whether initialization procedure 1 or 2 shall be

used. The device sending the sniff request shall use initialization 1 when the MSB of
the Central's current clock (CLK27) is 0; it shall use initialization 2 when the MSB of
the Central's current clock (CLK27) is 1. The device that receives the sniff request shall
apply the initialization method as indicated by the initialization flag irrespective of its own
CLK 27 value. The sniff anchor point determined by the Central and the Peripheral shall
be initialized on the slots for which the clock satisfies the applicable equation:

CLK27 − 1 mod T sniff = Dsniff for initialization 1

CLK27, CLK26 − 1 mod T sniff = Dsniff for initialization 2

this implies that Dsniff must be even

After initialization, the clock value CLK(k+1) for the next sniff anchor point shall be
derived by adding the fixed interval Tsniff to the clock value of the current sniff anchor
point:

CLK27 − 1 k + 1 = CLK27 − 1 k + T sniff

8.7.1 Sniff Transition mode

Sniff Transition mode is a special mode which is used during the transition between
Sniff mode and Active mode. It is required because during this transition it is unclear
which mode (Sniff or Active) the Peripheral is in and it is necessary to ensure that the
Peripheral is polled correctly regardless of which mode it is in.

In Sniff Transition mode the Central shall maintain the Active mode poll interval in case
the Peripheral is in Active mode. In addition the Central shall poll the Peripheral at
least once in the sniff attempt transmit slots starting at each sniff anchor point. This
transmission counts for the Active mode polling as well. The Central shall use its high
power accurate clock when in Sniff Transition mode.

The precise circumstances under which the Central enters Sniff Transition mode are
defined in [Vol 2] Part C, Section 4.5.3.1.

8.7.2 Sniff subrating

When sniff subrating is enabled by the Link Manager a device alternates between
Sniff mode and Sniff Subrating mode. Sniff Subrating mode allows a device to use a
reduced number of sniff anchor points. A device shall transition from Sniff mode to
Sniff Subrating mode based on the Sniff mode timeout value (see Section 8.7.2.1).
A device shall transition from Sniff Subrating mode to Sniff mode whenever ACL-U,
APB-U, ACL-C, or APB-C data is received from the remote device.

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 2, Part B Page 598
Baseband Specification

Sniff mode timeout expired

Sniff Subrating
Sniff mode
mode

Data received

Figure 8.24: Sniff subrating

A Peripheral in Sniff Subrating mode shall also temporarily enter Sniff mode after
transmitting a packet requiring acknowledgment until the Baseband acknowledgment
is received.

Once sniff subrating is enabled the Central and Peripheral may be in Sniff mode or Sniff
Subrating mode at different times. The rules defined in Section 8.7.2.2 describe how the
two devices maintain synchronization and can reliably exchange data.

8.7.2.1 Sniff mode timeout

The Sniff mode timeout value Tsniff_mode_timeout used by a device shall be at least the
greater of the value specified by the peer over LMP and any value specified by the
Host.

Whenever a packet containing ACL-U, APB-U, ACL-C, or APB-C data is received by a

device in Sniff Subrating mode it shall transition to Sniff mode, re-start the Sniff mode
timeout timer, and shall then use all sniff anchor points until at least Tsniff_mode_timeout
slots have expired. If ACL-U, APB-U, ACL-C, or APB-C data is received before
Tsniff_mode_timeout slots have passed since the last ACL-U, APB-U, ACL-C, or APB-C
data was received, the Sniff mode timeout timer shall be restarted. NULL and POLL
packets do not contain ACL or APB data and shall not restart the Sniff mode timeout
timer.

8.7.2.2 Sniff Subrating mode

When the Sniff mode timeout has expired a device shall enter sniff subrating mode. In
Sniff Subrating mode the mandatory sniff subrating anchor points at which the Central
shall transmit to the Peripheral and the Peripheral shall listen for the Central, are
defined in Table 8.10 (where M is the max subrate received by the Central, N is the max
subrate received by the Peripheral, A is the sniff subrating instant, and k is any positive
integer).

j≤X

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 2, Part B Page 599
Baseband Specification

When sniff subrating is enabled, the rules specified in Section 8.7 for Nsniff attempt and
Nsniff Timeout shall apply to sniff subrating anchor points.

Central Peripheral
M=N CLK M ( k ) = A + [ Tsniff × M × k ] CLK N ( k ) = A + [ Tsniff × N × k ]
M>N At least once every j anchor points CLK N ( k ) = A + [ Tsniff × N × k ]
satisfying
CLK N ( k ) = A + [ Tsniff × N × k ], where
j= M÷N
M<N CLK M( k ) = A + [ Tsniff × M × k ] At least once every j anchor points
satisfying
CLK M( k ) = A + [ Tsniff × M × k ], where
j= N÷M

Table 8.10: Sniff subrating anchor points

8.8 Hold mode

During the Connection state, the ACL logical transport to a Peripheral can be put in
a Hold mode. In Hold mode the Peripheral temporarily shall not support ACL packets
on the channel. Any synchronous packet during reserved synchronous slots (from SCO
and eSCO links) shall be supported. With the Hold mode, capacity can be made free
to do other things like scanning, paging, inquiring, or attending another piconet. The
device in Hold mode can also enter a low-power sleep mode. During Hold mode, the
Peripheral keeps its logical transport address(es) (LT_ADDR).

Prior to entering Hold mode, Central and Peripheral agree on the time duration the
Peripheral remains in Hold mode. A timer shall be initialized with the holdTO value.
When the timer is expired, the Peripheral shall wake up, synchronize to the traffic on the
channel and will wait for further Central transmissions.

8.9 [This section is no longer used]

8.10 Connectionless Peripheral Broadcast mode

In Connectionless Peripheral Broadcast mode, the Transmitter broadcasts packets to
zero or more Receivers.

The Transmitter can broadcast messages to multiple Receivers in Connectionless

Peripheral Broadcast mode. For this purpose, the Transmitter (Central) shall reserve
an LT_ADDR for use only by Connectionless Peripheral Broadcast traffic. In
Connectionless Peripheral Broadcast mode, the Transmitter transmits packets at
specified intervals.

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 2, Part B Page 600
Baseband Specification

8.10.1 Connectionless Peripheral Broadcast transmit operation

In Connectionless Peripheral Broadcast mode, the Transmitter transmits packets on

the CPB logical transport at intervals requested by the Host in Central-to-Peripheral
transmission slots.

If the Host has not yet provided the BR/EDR Controller with any data packets to
transmit since enabling the broadcast, or if the length of the data is zero, the BR/EDR
Controller shall transmit NULL packets. This is different than the case where the Host
has provided data since enabling the broadcast but has not provided new data since
the previous broadcast packet. In that case, the BR/EDR Controller resends the most
recent data.

The Host may provide Connectionless Peripheral Broadcast data through HCI
commands. Because HCI commands are limited to 255 bytes, a single command
cannot carry the maximum payloads allowed by larger packets, such as DH5.
Therefore, HCI commands for Connectionless Peripheral Broadcast allow fragmentation
of large payloads at the HCI level. The BR/EDR Controller shall assemble all HCI
fragments of a packet before transmission and shall not transmit incomplete packets.
Until such assembly is complete, the Controller shall continue to transmit the previous
data (if any).

Figure 8.25 shows the timing of Connectionless Peripheral Broadcast packets.

Connectionless Peripheral Broadcast Interval

(TConnectionless_Peripheral_Broadcast)

Central-to- Peripheral-to- Central-to- Peripheral-to-

Peripheral slot Central slot Peripheral slot Central slot

Connectionless Peripheral Connectionless Peripheral

Broadcast Instant Broadcast Instant

Figure 8.25: Connectionless Peripheral Broadcast timing

Connectionless Peripheral Broadcast Instants are separated by the Connectionless

Peripheral Broadcast Interval (TConnectionless_Peripheral_Broadcast). The Connectionless
Peripheral Broadcast interval can be any even value from 0x0002 to 0xFFFE slots
and is negotiated between the BR/EDR Controller and the Host during CPB setup.
At the start of each Connectionless Peripheral Broadcast Instant, the Connectionless

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 2, Part B Page 601
Baseband Specification

Peripheral Broadcast packet is transmitted using the adapted piconet physical channel.
Connectionless Peripheral Broadcast packets shall not be encrypted.

The Transmitter shall stop transmitting Connectionless Peripheral Broadcast packets

after CPB_supervisionTO slots have passed without transmission of a Connectionless
Peripheral Broadcast packet. CPB_supervisionTO may be any even value from 0x0002
to 0xFFFE slots. Connectionless Peripheral Broadcast packets can fail to transmit for a
certain continuous period of time due to scheduling conflicts from higher priority traffic.

8.10.2 Connectionless Peripheral Broadcast receive operation

In Connectionless Peripheral Broadcast mode, the Receiver is synchronized to a

Connectionless Peripheral Broadcast Transmitter and is receiving profile broadcast data
on the LT_ADDR reserved by the Transmitter for the CPB logical transport.

When requesting synchronization establishment, the Host provides the Controller with
the Transmitter’s clock offset and the next Connectionless Peripheral Broadcast Instant
received from the synchronization train. Because of delays in the Host, it is possible
that the Connectionless Peripheral Broadcast Instant occurs in the past. The BR/EDR
Controller shall support Connectionless Peripheral Broadcast instants at least 1 second
in the past. The Receiver should determine whether the Connectionless Peripheral
Broadcast Instant is in the past or the future by using the Transmitter’s clock offset and
its own clock to estimate the Transmitter's current clock and start listening from the next
broadcast instant.

The Skip parameter is set by the Host and specifies the number of consecutive
Connectionless Peripheral Broadcast instants which the receiver may skip after
successfully receiving a Connectionless Peripheral Broadcast packet. If the
Connectionless Peripheral Broadcast packet is received successfully, the payload data
shall be forwarded to the Host. If no Connectionless Peripheral Broadcast packet is
received by a Receiver during a Connectionless Peripheral Broadcast Instant, the
Receiver shall ignore Skip and instead listen at every scheduled Connectionless
Peripheral Broadcast Instant until it is able to successfully receive a Connectionless
Peripheral Broadcast packet or until CPB_supervisionTO number of slots have passed.

The BR/EDR Controller shall stop listening for Connectionless Peripheral Broadcast
packets after CPB_supervisionTO slots have passed without receiving a Connectionless
Peripheral Broadcast packet.

The BR/EDR Controller may transfer Connectionless Peripheral Broadcast data to the
Host through HCI events. Because HCI events are limited to 255 bytes a received
packet will not necessarily fit into a single HCI event. The BR/EDR Controller shall
fragment and transfer such packets using multiple HCI events.

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 2, Part B Page 602
Baseband Specification

8.10.3 AFH in Connectionless Peripheral Broadcast

Connectionless Peripheral Broadcast packets shall be transmitted on the adapted

piconet channel and the synchronization train shall always contain the current AFH
channel map for the PBD logical link.

8.11 Synchronization establishment substates

8.11.1 Synchronization Scan substate

The Synchronization Scan substate is used by Peripherals to receive synchronization

train packets from the piconet Central. The Synchronization Scan substate can be
entered from the Standby or Connection states. In the Synchronization Scan substate,
a device uses the Synchronization Scan procedure (see Section 2.7.3). During each
synchronization scan window, the device shall listen on a single frequency with its
correlator matched to the Central’s channel access code (CAC).

If the correlator exceeds the trigger threshold during the Synchronization Scan
procedure, the scanning device shall receive the synchronization train packet, whose
contents are defined in Table 8.11. Upon reception of the synchronization train packet
the device shall exit the Synchronization Scan substate and return to the Standby
or Connection state as appropriate. If the packet is not received the device should
stay in the Synchronization Scan substate. If the synchronization_scanTO expires
before reception of a Synchronization Train packet, the device shall return to the
Standby state. A device attempting to synchronize to a Connectionless Peripheral
Broadcast transport shall ignore any synchronization train packet whose Connectionless
Peripheral Broadcast LT_ADDR field in the payload is set to zero.

The synchronization scan may be interrupted by higher priority traffic. In particular, the
reserved synchronous slots should have higher priority than the synchronization scan.

8.11.2 Synchronization Train substate

The Synchronization Train substate is used by the Central of the piconet to transmit
synchronization train packets. The Synchronization Train substate can be entered from
the Standby or Connection states. In the Synchronization Train substate, a device uses
the Synchronization Train procedure (see Section 2.7.2). During the Synchronization

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 2, Part B Page 603
Baseband Specification

Train procedure, the Central repeatedly transmits synchronization train packets on the
channels specified in Section 2.6.4.8. While in the Synchronization Train substate:

• if Connectionless Peripheral Broadcast mode is enabled, the Central shall continue to

transmit Connectionless Peripheral Broadcast packets in addition to synchronization
train packets;
• if the Central is in Coarse Clock Adjustment Recovery Mode, it shall continue
transmitting and receiving on all active logical transports to all Peripherals that have
acknowledged the Coarse Clock Adjustment (see [Vol 2] Part C, Section 4.1.14.1).

Reserved SCO and eSCO slots should have higher priority than the synchronization
train. Once the Central enters the Synchronization Train substate, it shall remain in the
Synchronization Train substate until synchronization_trainTO expires or the Host directs
otherwise. The Central shall transition to the Standby or Connection state when exiting
the Synchronization Train substate.

The synchronization train packet is a basic rate ACL packet with type DM3 and
LT_ADDR of zero. FLOW, ARQN and SEQN shall all be set to zero upon transmission
and ignored upon receipt. The HEC LFSR shall be initialized with the Central’s UAP.
In the payload header, the LLID shall contain the value 0b10 (start of an L2CAP
message or no fragmentation). FLOW in the payload header shall be set to zero upon
transmission and ignored upon reception. The length of the payload body (LENGTH)
shall be 28 bytes. The CRC LFSR shall be initialized with the Central’s UAP. Data
whitening is not used. Encryption is not used.

There are two possible formats. Format 1 shall be used when the synchronization train
is being transmitted by a device which is the Central of a piconet where Connectionless
Peripheral Broadcast mode is enabled, and format 2 shall be used otherwise. The
format of the payload portion of the DM3 packet used in the synchronization train is
shown in Table 8.11.

Bytes Field Length Format 1 Description Format 2

Description
0-3 CLK 4 Bytes Current piconet clock (CLK) Current piconet
clock (CLK)
4-7 Future Connectionless Pe- 4 Bytes CLK[27:1] corresponding to CLK[27:1] + 1600
ripheral Broadcast Instant the start of a future Connec- slots
tionless Peripheral Broad-
cast Instant.

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 2, Part B Page 604
Baseband Specification

Bytes Field Length Format 1 Description Format 2

Description
8-17 AFH Channel Map 10 Bytes The current AFH_Channel_- Unspecified
Map used for the PBD log-
ical link. The format is the
same as the Link Manager
AFH_Channel_Map parame-
ter, see [Vol 2] Part C, Ta-
ble 5.2.
18-23 Central BD_ADDR 6 Bytes Central’s BD_ADDR Central’s
BD_ADDR
24-25 Connectionless Peripheral 2 Bytes Time duration in slots from Unspecified
Broadcast Interval the start of a Connection-
less Peripheral Broadcast
packet to the start of the
next Connectionless Periph-
eral Broadcast packet. Shall
be even.
26 Connectionless Peripheral 1 Byte The LT_ADDR reserved for 0x00
Broadcast LT_ADDR the CPB logical transport.
27 Service Data 1 Byte Defined by the service us- 0x00
ing the Connectionless Pe-
ripheral Broadcast feature.

Table 8.11: Synchronization train packet payload body

The Host provides the Service Data for the synchronization train packet payload body
when format 1 is used. The BR/EDR Controller provides the data for all other fields.

All devices in the Synchronization Scan substate shall accept payloads of any length
from 28 to 121 bytes and shall ignore bytes 28 (counting from 0) and beyond.

When format 1 is used the Future Connectionless Peripheral Broadcast Instant in the
synchronization train packet payload shall correspond to one of the next 4 broadcast
instants. Figure 8.26 shows an example of valid and invalid values for this field.

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 2, Part B Page 605
Baseband Specification

STP = SynchronizationTrain Packet

CPBI = Connectionless Peripheral Broadcast Instant

Invalid
Valid

CPBI 0 CPBI 1 CPBI 2 CPBI 3 CPBI 4 CPBI 5

STP

Figure 8.26: Examples of synchronization train pointing to Connectionless Peripheral Broadcast Instant

The Central shall not transmit synchronization train packets in a Connectionless

Peripheral Broadcast Instant.

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 2, Part B Page 606
Baseband Specification

9 AUDIO

On the air-interface, either a 64 kb/s log PCM (Pulse Code Modulation) format (A-law or
μ-law) may be used, or a 64 kb/s CVSD (Continuous Variable Slope Delta Modulation)
may be used. The latter format applies an adaptive delta modulation algorithm with
syllabic companding.

The voice coding on the line interface is designed to have a quality equal to or better
than the quality of 64 kb/s log PCM.

Table 9.1 summarizes the voice coding schemes supported on the air interface. The
appropriate voice coding scheme is selected after negotiations between the Link
Managers.

Voice Codecs
linear CVSD
8-bit logarithmic A-law
μ-law

Table 9.1: Voice coding schemes supported on the air interface

9.1 LOG PCM codec

Since the synchronous logical transports on the air-interface can support a 64 kb/s
information stream, a 64 kb/s log PCM traffic can be used for transmission. Either A-law
or μ-law compression may be applied. In the event that the line interface uses A-law
and the air interface uses μ-law or vice versa, a conversion from A-law to μ-law shall be
performed. The compression method shall follow ITU-T recommendations G. 711.

9.2 CVSD codec

A more robust format for voice over the air interface is delta modulation. This
modulation scheme follows the waveform where the output bits indicate whether the
prediction value is smaller or larger than the input waveform. To reduce slope overload
effects, syllabic companding is applied: the step size is adapted according to the
average signal slope. The input to the CVSD encoder shall be 64000 samples per
second linear PCM (typically 16 bits, but actual value is implementation specific). Block
diagrams of the CVSD encoder and CVSD decoder are shown in Figure 9.1, Figure 9.2
and Figure 9.3. The system shall be clocked at 64 kHz.

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 2, Part B Page 607
Baseband Specification

Figure 9.1: Block diagram of CVSD encoder with syllabic companding

Figure 9.2: Block diagram of CVSD decoder with syllabic companding

b(k)

δ(k) D Sat. x̂(k – 1)

ŷ(k) ŷ(k – 1) y(k – 1)
h

Figure 9.3: Accumulator procedure

Let sgn x = 1 for x ≥ 0, otherwise sgn x = − 1. On air these numbers shall be

represented by the sign bit; i.e. negative numbers are mapped to “1” and positive and
zero numbers are mapped to “0”.

Denote the CVSD encoder output bit b(k), the encoder input x(k), the accumulator
contents y(k), and the step size δ k . Furthermore, let h be the decay factor for the
accumulator, let β denote the decay factor for the step size, and, let α be the syllabic
companding parameter. The latter parameter monitors the slope by considering the K
most recent output bits.

Let

x k = ℎy k . (EQ 14)

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 2, Part B Page 608
Baseband Specification

Then, the CVSD encoder internal state shall be updated according to the following set
of equations:

b k = sgn x k − x k − 1 , (EQ 15)

1, if J bits in the last K output bits are equal,

α= (EQ 16)
0, otherwise,

min δ k − 1 + δmin, δmax , α = 1,

δk = (EQ 17)
max βδ k − 1 , δmin , α = 0,

min y k , ymax , y k ≥ 0 .
yk = (EQ 18)
max y k , ymin , y k < 0 .
where

y k =x k−1 +b k δ k . (EQ 19)

In these equations, δmin and δmax are the minimum and maximum step sizes, and, ymin
and ymax are the accumulator’s negative and positive saturation values, respectively.
Over air, the bits shall be sent in the same order they are generated by the CVSD
encoder.

For a 64 kb/s CVSD, the parameters as shown in Table 9.2 shall be used. The numbers
are based on a 16 bit signed number output from the accumulator. These values result
in a time constant of 0.5 ms for the accumulator decay, and a time constant of 16 ms for
the step size decay

Parameter Value
h 1
1− 32

β 1
1− 1024

J 4
K 4
δmin 10
δmax 1280
ymin −215 or −215 + 1
ymax 215 − 1

Table 9.2: CVSD parameter values. The values are based on a 16-bit signed number output from the
accumulator.

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 2, Part B Page 609
Baseband Specification

9.3 Error handling

In the DV, HV3, EV3, EV5, 2-EV3, 3-EV3, 2-EV5 and 3-EV5 packets, the voice is
not protected by FEC. The quality of the voice in an error-prone environment then
depends on the robustness of the voice coding scheme and, in the case of eSCO, the
retransmission scheme. CVSD, in particular, is rather insensitive to random bit errors,
which are experienced as white background noise. However, when a packet is rejected
because either the channel access code, the HEC test was unsuccessful, or the CRC
has failed, measures have to be taken to “fill” in the lost speech segment.

The voice payload in the HV2 and EV4 packets are protected by a 2/3 rate FEC. For
errors that are detected but cannot be corrected, the receiver should try to minimize
the audible effects. For instance, from the 15-bit FEC segment with uncorrected errors,
the 10-bit information part as found before the FEC decoder should be used. The HV1
packet is protected by a 3 bit repetition FEC. For this code, the decoding scheme will
always assume zero or one-bit errors. Thus, there exist no detectable but uncorrectable
error events for HV1 packets.

9.4 General audio requirements

9.4.1 Signal levels

For A-law and μ-law log-PCM encoded signals the requirements on signal levels shall
follow the ITU-T recommendation G.711.

Full swing at the 16 bit linear PCM interface to the CVSD encoder is defined to be 3
dBm0.

9.4.2 CVSD audio quality

For Bluetooth audio quality the requirements are put on the transmitter side. The 64000
samples per second linear PCM input signal should have negligible spectral power
density above 4 kHz. The power spectral density in the 4 kHz to 32 kHz band of the
decoded signal at the 64000 samples per second linear PCM output, should be more
than 20 dB below the maximum in the 0 kHz to 4 kHz range.

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 2, Part B Page 610
Baseband Specification

Appendix A General audio recommendations

The abbreviations in Table A.1 are used only in this appendix.

A/D Analog to digital conversion

BTR Bluetooth Radio
D/A Digital to analog conversion
ERP Ear Reference Point
LR Loudness Rating
MRP Microphone Reference Point
PGA Programmable Gain Amplifier
RLR Receive Loudness Rating
SLR Send Loudness Rating

Table A.1: Abbreviations for general audio recommendations

A.1 Maximum sound pressure

It is the sole responsibility of each manufacturer to design their audio products in a safe
way with regards to injury to the human ear. The Bluetooth Specification doesn’t specify
maximum sound pressure from an audio device.

A.2 [This section is no longer used]

A.3 Audio levels for Bluetooth

Audio levels shall be calculated as SLR and RLR. The calculation methods are
specified in ITU-T Recommendation P.79.

The physical test set-up for Handsets and Headsets is described in ITU-T
Recommendation P.51 and P.57

The physical test set-up for speakerphones and “Vehicle hands-free systems” is
specified in ITU-T Recommendation P.34.

A general equation for computation of LR for telephone sets is given by ITU-T

recommendations P.79 and is given by
N2
10
LR = − log10
m ∑ 10
m si − wi ÷ 10
, (EQ 20)
i = N1

where

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 2, Part B Page 611
Baseband Specification

m is a constant (~ 0.2).
wi = weighting coefficient (different for the various LRs).
Si = the sensitivity at frequency Fi , of the electro-acoustic path
N1,N2, consecutive filter bank numbers (Art. Index: 200 Hz to 4000 Hz)

(EQ 20) is used for calculating the SLR according to Figure A.1, and RLR according to
Figure A.2. When calculating LRs one must only include those parts of the frequency
band where an actual signal transmission can occur in order to ensure that the additive
property of LRs is retained. Therefore ITU-T P.79 uses only the frequency band 200 Hz
to 4000 Hz in LR computations.

A.4 Microphone path

SLR measurement model

Figure A.1: SLR measurement set-up

A.5 Loudspeaker path

RLR measurement model

Figure A.2: RLR measurement set-up

A.6 Bluetooth voice interface

The specification for the Bluetooth voice interface should follow in the first place
the ITU-T Recommendations P.79, which specifies the loudness ratings for telephone
sets. These recommendations give general guidelines and specific algorithms used for
calculating the loudness ratings of the audio signal with respect to ERP.

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 2, Part B Page 612
Baseband Specification

For Bluetooth voice interface to the different cellular system terminals, loudness
and frequency recommendations based on the cellular standards should be used.
For example, GSM 03.50 gives recommendation for both the loudness ratings and
frequency mask for a GSM terminal interconnection with Bluetooth.

1- The output of the CVSD decoder are 16-bit linear PCM digital samples, at a sampling
frequency of 8000 samples per second. Bluetooth also supports 8-bit log PCM samples
of A-law and μ-law type. The sound pressure at the ear reference point for a given
16‑bit CVSD sample, should follow the sound pressure level given in the cellular
standard specification.

2- A maximum sound pressure which can be represented by a 16-bit linear PCM

sample at the output of the CVSD decoder should be specified according to the
loudness rating, in ITU P.79 and at PGA value of 0 dB. PGAs are used to control
the audio level at the terminals by the user. For conversion between various PCM
representations: A-law, μ-law and linear PCM, ITU-T G.711, G.712, G.714 give
guidelines and PCM value relationships. Zero-code suppression based on ITU-T G.711
is also recommended to avoid network mismatches.

A.7 Frequency mask

When interfacing a Bluetooth terminal to a digital cellular mobile terminal, the CVSD
decoder signal should conform to the frequency mask given in the GSM cellular
standard so that the speech coders operate in the intended manner. A recommendation
for a frequency mask is given in Table A.2. Figure A.3 shows a plot of the frequency
mask for Bluetooth (solid line). The GSM frequency mask (dotted line) is shown in
Figure A.3 for comparison.

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 2, Part B Page 613
Baseband Specification

Figure A.3: Plot of recommended frequency mask for Bluetooth. The GSM send frequency mask is given
for comparison (dotted line).

Frequency Upper Limit Lower Limit

(Hz) (dB) (dB)
50 -20 none
300 4 -12
1000 4 -9
2000 4 -9
3000 4 -9
3400 4 -12
4000 0 none

Table A.2: Recommended frequency mask for Bluetooth

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 2, Part B Page 614
Baseband Specification

Appendix B Timers

This appendix contains a list of Baseband timers related to inactivity timeout defined in
the specification. Definitions and default values of the timers are listed below

All timer values are given in slots.

B.1 List of timers

B.1.1 inquiryTO

The inquiryTO defines the number of slots the Inquiry substate shall last. The timer
value may be changed by the Host. HCI provides a command to change the timer
value.

B.1.2 pageTO

The pageTO defines the number of slots the Page substate can last before a response
is received when the extended_pageTO is zero. The timer value may be changed by
the Host. HCI provides a command to change the timer value.

B.1.3 extended_pageTO

The extended_pageTO defines the number of additional slots the Page substate can
last beyond pageTO before a response is received. The timer value may be changed by
the Host. HCI provides a command to change the timer value.

B.1.4 pagerespTO

In the Peripheral, pagerespTO defines the number of slots the Peripheral shall await
the Central’s response, FHS packet, after sending the page acknowledgment ID packet.
In the Central, pagerespTO defines the number of slots the Central should wait for
the FHS packet acknowledgment before returning to Page substate. Both Central and
Peripheral units should use the same value for this timeout, to allow common page/scan
intervals after reaching pagerespTO.

The pagerespTO value is 8 slots.

B.1.5 newconnectionTO

Every time a new connection is started through paging, scanning, or role switch, the
Central sends a POLL packet as the first packet in the new connection. Transmission
and acknowledgment of this POLL packet is used to confirm the new connection. If the
POLL packet is not received by the Peripheral or the response packet is not received by

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 2, Part B Page 615
Baseband Specification

the Central for newconnectionTO number of slots, both the Central and the Peripheral
should return to the previous substate.

newconnectionTO value is 32 slots.

B.1.6 supervisionTO

The supervisionTO is used by both the Central and Peripheral to monitor link loss. If
a device does not receive any packets that pass the HEC check and have the proper
LT_ADDR for a period of supervisionTO, it shall consider the link to be disconnected.
The supervision timer keeps running in Hold mode and Sniff mode.

The supervisionTO value may be changed by the Host. HCI provides a command to
change the timer value. At the Baseband level a default value equivalent to 20 seconds
should be used.

B.1.7 CPB_supervisionTO

The CPB_supervisionTO is used by the Peripheral to monitor connection loss and by

the Central to monitor scheduling conflicts and shall be between 0x0002 to 0xFFFE
with only even values valid. At the Baseband level a default value equivalent to 5.12
seconds should be used. The Host can change the value of CPB_supervisionTO.

B.1.8 synchronization_trainTO

The synchronization_trainTO is used by the Central to determine how long to continue

broadcasting Synchronization Train packets and shall be between 0x00000002 to
0x07FFFFFE with only even values valid. At the Baseband level a default value
equivalent to 120 seconds should be used for Connectionless Peripheral Broadcast and
a default value equivalent to 20 seconds should be used for Coarse Clock Adjustment
Recovery Mode. The Host may change the value of synchronization_trainTO that is
used during Connectionless Peripheral Broadcast.

B.1.9 synchronization_scanTO

The synchronization_scanTO is used by the Peripheral to determine when to stop

scanning for synchronization train packets. It shall be between 0x0022 to 0xFFFE
with only even values valid. At the Baseband level a default value equivalent to 5.12
seconds should be used for Connectionless Peripheral Broadcast and a default value
equivalent to 20 seconds should be used during Coarse Clock Adjustment Recovery
Mode. The Host may change the value of synchronization_scanTO that is used during
Connectionless Peripheral Broadcast.

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 2, Part B Page 616
Baseband Specification

B.1.10 authenticatedPayloadTO

The authenticatedPayloadTO is the maximum amount of time, in seconds, allowed

between receiving packets containing a MIC. The Host can change the value of
authenticatedPayloadTO.

The default value for authenticatedPayloadTO is 30 seconds.

B.1.11 CLK_adj_dragTO

The CLK_adj_dragTO is the minimum amount of time, in seconds, the drag shall be
suspended when a Peripheral has not responded after the Central has dragged the
clock.

The CLK_adj_dragTO value shall be 1 second.

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 2, Part B Page 617
Baseband Specification

Appendix C Recommendations for AFH operation in

Hold, Sniff, and Connectionless Peripheral Broadcast
modes

The three possible AFH operation modes for an AFH capable Peripheral in Hold mode
and Sniff mode are the same three AFH operation modes used during Connection state:

• Enabled (using an AHS with some RF channels unused)

• Enabled (using AHS(79))
• Disabled

The Central may place an AFH capable Peripheral in any of the three AFH operating
modes.

C.1 Operation at the Central

A Central that has one or more Peripherals in Hold mode or Sniff mode and decides to
update them simultaneously shall schedule an AFH_Instant for a time that allows it to
update all these Peripherals (as well as its active Peripherals) with the new adaptation.

A Central that has multiple Peripherals with non-overlapping “wake” times (e.g.
Peripherals in Sniff mode with different timing parameters) may keep them enabled
on the same adaptation provided that its scheduling of the AFH_Instant allows enough
time to update them all.

This timing is summarized in Figure C.1. In this example the Central decides that a
hop sequence adaptation applying to all its Peripherals at the same time is required.
However it cannot schedule an AFH_Instant until it has informed its active Peripheral,
its Peripheral in Hold mode, and its Peripheral in Sniff mode.

If it decides that only some Peripherals require the new adaptation, it need only take
those Peripherals into account when scheduling the AFH_Instant.

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 2, Part B Page 618
Baseband Specification

THS

AFH-enabled
Sniff mode

ENA (Earliest Next Adaptation for this device)

Peripheral
awake

THS

AFH-enabled Awake Awake Awake

Peripheral in
Hold mode

ENA
THS

AFH-enabled Awake
Peripheral not

ENA
in a power-
saving mode

Central
activity

Previous Central Earliest next

AFH_Instant decides on possible
a new AH AFH_Instant

Figure C.1: Timing constraint on AFH_Instant with Peripherals in Hold and Sniff modes

C.2 [This section is no longer used]

C.3 AFH operation in Sniff mode

Once a Peripheral has been placed in Sniff mode, the Central may periodically change
its AHS without taking the Peripheral out of Sniff mode.

C.4 AFH operation in Hold mode

A Peripheral that is in Hold mode cannot send or receive any LMP messages. Once
the Peripheral has left Hold mode the Central may subsequently update the Peripheral’s
adaptation.

C.5 AFH operation in Connectionless Peripheral Broadcast

After the Transmitter’s BR/EDR Controller notifies the Transmitter’s Host that the AFH
channel map has changed for the PBD logical link, the Transmitter’s Host may restart
the synchronization train to allow Receivers to obtain the updated AFH channel map.
This is shown in Figure C.2.

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 2, Part B Page 619
Baseband Specification

Host Controller

AFH
Channel
Map
Change

HCI_Connectionless_Peripheral_Broadcast_Channel_Map_Change

HCI_Start_Synchronization_Train

HCI_Command_Status

Sync Train

Sync Train

HCI_Synchronization_Train_Complete

Figure C.2: AFH map change – Connectionless Peripheral Broadcast Transmitter

Modification of the AFH channel map will affect Receivers using a different AFH channel
map. Depending on the overlap between a Receiver’s current AFH channel map and
the current AFH channel map of the Transmitter (Central), the Receiver may miss
some Connectionless Peripheral Broadcast instants and, in the case of disjoint or nearly
disjoint AFH channel maps, the Receiver may lose synchronization. Receivers should
monitor the Connectionless Peripheral Broadcast reception rate and obtain the current
AFH channel map of the Transmitter (via the synchronization train) if degradation
exceeds desired thresholds.

Bluetooth SIG Proprietary Version Date: 2024-08-27

 BR/EDR Controller
Part C

LINK MANAGER
PROTOCOL
SPECIFICATION

This Part describes the Link Manager protocol

(LMP) which is used for link set-up and control.
The signals are interpreted and filtered out by the
Link Manager on the receiving side and are not
propagated to higher layers.

Bluetooth SIG Proprietary

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 2, Part C Page 621
Link Manager Protocol Specification

CONTENTS

1 Introduction ............................................................................................... 625

2 General rules ............................................................................................. 626

2.1 Message transport ...................................................................... 626
2.2 Synchronization ........................................................................... 626
2.3 Packet format .............................................................................. 627
2.4 Transactions ................................................................................ 628
2.4.1 LMP response timeout ................................................. 628
2.5 Error handling .............................................................................. 629
2.5.1 Transaction collision resolution .................................... 630
2.6 Procedure rules ........................................................................... 630
2.7 General response messages ...................................................... 631
2.8 LMP message constraints ........................................................... 631

3 Device features ......................................................................................... 632

3.1 General description ..................................................................... 632
3.2 Feature definitions ....................................................................... 632
3.3 Feature mask definition ............................................................... 637
3.4 Link Manager interoperability policy ............................................ 640
3.5 Feature requirements .................................................................. 640
3.5.1 [This section is no longer used] ................................... 643
3.5.2 [This section is no longer used] ................................... 643

4 Procedure rules ........................................................................................ 644

4.1 Connection control ...................................................................... 644
4.1.1 Connection establishment ........................................... 644
4.1.2 Detach ......................................................................... 645
4.1.3 Power control ............................................................... 646
4.1.3.1 Enhanced power control .............................. 648
4.1.4 Adaptive frequency hopping ........................................ 649
4.1.4.1 Central enables AFH .................................... 650
4.1.4.2 Central disables AFH ................................... 651
4.1.4.3 Central updates AFH .................................... 651
4.1.4.4 AFH operation in Hold and Sniff modes ....... 652
4.1.5 Channel classification .................................................. 652
4.1.5.1 Channel classification reporting
enabling and disabling ................................. 653
4.1.6 Link supervision ........................................................... 654
4.1.7 Channel quality driven data rate change (CQDDR) .... 655
4.1.8 Quality of service (QoS) ............................................... 656

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 2, Part C Page 622
Link Manager Protocol Specification

4.1.8.1 Central notifies Peripheral of the

quality of service .......................................... 656
4.1.8.2 Device requests new quality of service ........ 656
4.1.9 Paging scheme parameters ......................................... 657
4.1.9.1 Page mode ................................................... 657
4.1.9.2 Page Scan mode ......................................... 658
4.1.10 Control of multi-slot packets ........................................ 658
4.1.11 Enhanced Data Rate ................................................... 659
4.1.12 Encapsulated LMP PDUs ............................................ 660
4.1.12.1 Sending an encapsulated PDU .................... 661
4.1.13 Ping .............................................................................. 662
4.1.14 Piconet clock adjustment ............................................. 663
4.1.14.1 Central coarse adjustment of piconet clock . 664
4.1.14.2 Peripheral request for coarse
adjustment of piconet clock .......................... 665
4.1.15 Slot Availability Mask ................................................... 667
4.1.15.1 SAM type 0 submap configuration ............... 669
4.1.15.2 SAM slot map define .................................... 669
4.1.15.3 SAM switch sequence .................................. 669
4.1.15.4 SAM change during the transmission
of a multi-slot packet .................................... 670
4.1.15.5 SAM and role switching ................................ 670
4.1.15.6 SAM and Sniff mode .................................... 670
4.2 Security ....................................................................................... 671
4.2.1 Authentication .............................................................. 671
4.2.1.1 Claimant has link key (legacy
authentication) .............................................. 672
4.2.1.2 Claimant has no link key (legacy
authentication and secure authentication) ... 672
4.2.1.3 Repeated attempts ....................................... 673
4.2.1.4 Responder has link key (secure
authentication) .............................................. 673
4.2.2 Pairing .......................................................................... 674
4.2.2.1 Responder accepts pairing and has a
variable PIN .................................................. 675
4.2.2.2 Responder accepts pairing and has a
fixed PIN ....................................................... 675
4.2.2.3 Responder rejects pairing ............................ 676
4.2.2.4 Creation of the link key ................................. 676
4.2.2.5 Repeated attempts ....................................... 677
4.2.3 Change link key ........................................................... 677
4.2.4 Change current link key type ....................................... 678
4.2.4.1 Change to a temporary link key ................... 678

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 2, Part C Page 623
Link Manager Protocol Specification

4.2.4.2 Semi-permanent link key becomes

current link key ............................................. 679
4.2.5 Encryption .................................................................... 679
4.2.5.1 Encryption mode .......................................... 680
4.2.5.2 Encryption key size ...................................... 681
4.2.5.3 Start encryption ............................................ 683
4.2.5.4 Stop encryption ............................................ 684
4.2.5.5 Pause encryption ......................................... 685
4.2.5.6 Resume encryption ...................................... 687
4.2.5.7 Change encryption key or random number .. 688
4.2.5.8 Encryption key refresh ................................. 689
4.2.6 Request supported encryption key size ....................... 689
4.2.7 Secure Simple Pairing ................................................. 690
4.2.7.1 IO capability exchange ................................. 691
4.2.7.2 Public key exchange .................................... 692
4.2.7.3 Authentication stage 1 ................................. 693
4.2.7.4 Authentication stage 2: DHKey check .......... 701
4.3 Informational requests ................................................................. 703
4.3.1 Timing accuracy ........................................................... 703
4.3.2 Clock offset .................................................................. 704
4.3.3 LMP version ................................................................. 705
4.3.4 Supported features ...................................................... 706
4.3.5 Name request .............................................................. 707
4.4 Role switch .................................................................................. 708
4.4.1 Slot offset ..................................................................... 708
4.4.2 Role switch .................................................................. 709
4.5 Modes of operation ..................................................................... 712
4.5.1 Hold mode ................................................................... 712
4.5.1.1 Central forces Hold mode ............................ 712
4.5.1.2 Peripheral forces Hold mode ....................... 713
4.5.1.3 Central or Peripheral requests Hold mode ... 713
4.5.2 [This section is no longer used] ................................... 714
4.5.3 Sniff mode .................................................................... 714
4.5.3.1 Central or Peripheral requests Sniff mode ... 715
4.5.3.2 Moving a Peripheral from Sniff mode to
Active mode ................................................. 716
4.5.3.3 Sniff subrating .............................................. 717
4.6 Logical transports ........................................................................ 718
4.6.1 SCO logical transport ................................................... 718
4.6.1.1 Central initiates a SCO link .......................... 719
4.6.1.2 Peripheral initiates a SCO link ..................... 720
4.6.1.3 Central requests change of SCO
parameters ................................................... 721

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 2, Part C Page 624
Link Manager Protocol Specification

4.6.1.4 Peripheral requests change of SCO

parameters ................................................... 721
4.6.1.5 Remove a SCO link ...................................... 721
4.6.2 eSCO logical transport ................................................. 721
4.6.2.1 Central initiates an eSCO link ...................... 722
4.6.2.2 Peripheral initiates an eSCO link ................. 723
4.6.2.3 Central or Peripheral requests change
of eSCO parameters .................................... 724
4.6.2.4 Remove an eSCO link .................................. 724
4.6.2.5 Rules for the LMP negotiation and
renegotiation ................................................ 725
4.6.2.6 Negotiation state definitions ......................... 726
4.7 Test mode .................................................................................... 726
4.7.1 Activation and deactivation of Test mode .................... 726
4.7.2 Control of Test mode .................................................... 727
4.7.3 Summary of Test mode PDUs ..................................... 728

5 Summary ................................................................................................... 731

5.1 PDU summary ............................................................................. 731
5.2 Parameter definitions .................................................................. 739
5.3 LMP encapsulated ...................................................................... 750
5.4 Default values ............................................................................. 750

Appendix A Changes to parameter names ........................................................ 752

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 2, Part C Page 625
Link Manager Protocol Specification

1 INTRODUCTION

The Link Manager Protocol (LMP) is used to control and negotiate all aspects of the
operation of the Bluetooth connection between two devices. This includes the set-up
and control of logical transports and logical links, and for control of physical links.

The Link Manager Protocol is used to communicate between the Link Managers
(LM) on the two devices. All LMP messages shall apply solely to the physical link
and associated logical links and logical transports between the sending and receiving
devices.

The protocol is made up of a series of messages which shall be transferred over the
ACL-C or APB-C logical link between two devices. LMP messages shall be interpreted
and acted-upon by the LM and shall not be directly propagated to higher protocol layers.

Figure 1.1: Link Manager Protocol signaling layer

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 2, Part C Page 626
Link Manager Protocol Specification

2 GENERAL RULES

2.1 Message transport

LMP messages shall be exchanged over the ACL-C logical link that is carried on the
default ACL logical transport ([Vol 2] Part B, Section 4.4) or over the APB-C logical link
that is carried on the APB logical transport ([Vol 2] Part B, Section 4.6). LMP messages
shall be carried on the default ACL logical transport unless specified otherwise in
Sections 4 and 5. The ACL-C and APB-C logical links are distinguished from the ACL-U
and APB-U logical links (which carry L2CAP and user data) by the Logical Link Identifier
(LLID) field carried in the payload header of variable-length packets ([Vol 2] Part B,
Section 6.6.2).

The control logical links have a higher priority than other traffic - see [Vol 2] Part B,
Section 5.6.

The error detection and correction capabilities of the Baseband ACL logical transport
are generally sufficient for the requirements of the LMP. Therefore LMP messages do
not contain any additional error detection information beyond what can be realized by
means of sanity checks performed on the contents of LMP messages. Any such checks
and protections to overcome undetected errors in LMP messages is an implementation
matter.

2.2 Synchronization
This section explains why many of the LMP message sequences are defined as they
are. It does not create any requirements.

LMP messages are carried on the ACL-C and APB-C logical links, which do not
guarantee a time to deliver or acknowledge packets. LMP procedures take account
of this when synchronizing state changes in the two devices. For example, criteria are
defined that specify when a logical transport address (LT_ADDR) may be re-used after
it becomes available due to a device leaving the piconet. Other LMP procedures, such
as hold or role switch include the Bluetooth clock as a parameter in order to define a
fixed synchronization point. The transitions into and out of Sniff mode are protected with
a transition mode.

The LC normally attempts to communicate with each Peripheral no less often than
every Tpoll slots (see Section 4.1.8) based on the Tpoll for that Peripheral.

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 2, Part C Page 627
Link Manager Protocol Specification

LC LC
Central Peripheral
Message From LM
▲
Message
▲
Message
Tdeliver Tpoll
Message Message To LM
▲
Ack

Message

Ack
Tack
Message

Ack

Message

Ack Available Ack

Figure 2.1: Transmission of a message from Central to Peripheral1

Figure 2.1 illustrates the fundamental problem. It shows the transmission of a packet
from the Central to the Peripheral in conditions of heavy interference for illustrative
purposes. It is obvious that neither side can determine the value of either Tdeliver or Tack.
It is therefore not possible to use simple messages to identify uniquely the instant at
which a state change occurs in the other device.

2.3 Packet format

Each PDU is assigned either a 7 or a 15 bit opcode used to uniquely identify different
types of PDUs, see Table 5.1. The first 7 bits of the opcode and a transaction ID are
located in the first byte of the payload body. If the initial 7 bits of the opcode have one of
the special escape values 124 to 127 then an additional byte of opcode is located in the
second byte of the payload and the combination uniquely identifies the PDU.

The FLOW bit in the packet header is always 1 and shall be ignored on reception.

If the PDU contains one or more parameters these are placed in the payload starting
immediately after the opcode, i.e. at byte 2 if the PDU has a 7 bit opcode or byte 3
if the PDU has a 15 bit opcode. The number of bytes used depends on the length
of the parameters. The representation of each parameter is determined by its type as
specified in [Vol 1] Part E, Section 2.9.

1Note the diagram shows the limiting case where the Central transmits the message at intervals of T
poll. In the
case of heavy interference improved performance is gained by transmitting more often.

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 2, Part C Page 628
Link Manager Protocol Specification

LMP messages shall be transmitted using DM1 packets, however if an HV1 SCO link is
in use and the length of the payload is no greater than 9 bytes then DV packets may be
used.

LSB MSB
T
I Opcode Parameters
D
LMP PDU with 7 bit Opcode

LSB MSB
T
Escape Extended
I Parameters
Opcode Opcode
D
LMP PDU with 15 bit Opcode

Figure 2.2: Payload body when LMP PDUs are sent

2.4 Transactions
The LMP operates in terms of transactions. A transaction is a connected set of
message exchanges which achieve a particular purpose. All PDUs which form part of
the same transaction shall have the same value for the transaction ID which is stored as
part of the first byte of the opcode (see Section 2.3).

The transaction ID is in the least significant bit. It shall be 0 if the PDU forms part of a
transaction that was initiated by the Central and 1 if the transaction was initiated by the
Peripheral.

Each sequence described in Section 4 shall be defined as a transaction. For pairing,

see Section 4.2.2, and encryption, see Section 4.2.5, all sequences belonging to each
section shall be counted as one transaction and shall use the same transaction ID.
For connection establishment, see Section 4.1.1, LMP_HOST_CONNECTION_REQ
and the response with LMP_ACCEPTED or LMP_NOT_ACCEPTED shall form one
transaction and have the transaction ID of 0. LMP_SETUP_COMPLETE is a stand-
alone PDU, which forms a transaction by itself.

For error handling, see Section 2.5, the PDU to be rejected and
LMP_NOT_ACCEPTED or LMP_NOT_ACCEPTED_EXT shall form a single
transaction.

2.4.1 LMP response timeout

The time between receiving a Baseband packet carrying an LMP PDU and sending a
Baseband packet carrying a valid response PDU, according to the procedure rules in

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 2, Part C Page 629
Link Manager Protocol Specification

Section 4, shall be less than the LMP Response Timeout. The value of this timeout is
30 seconds. The LMP Response Timeout is applied not only to sequences described
in Section 4, but also to the series of the sequences defined as the transactions in
Section 4. It shall also be applied to the series of LMP transactions that take place
during a period when traffic on the ACL-U logical link is disabled for the duration of the
series of LMP transactions, for example during the enabling of encryption.

The LMP Response Timeout shall restart each time an LMP PDU which requires a reply
is queued for transmission by the Baseband.

LMP messages sent on the APB-C logical link have special rules and are not subject to
the LMP Response Timeout.

2.5 Error handling

If the LM receives a PDU with an unknown opcode (e.g. one added in a
higher version of the specification), it shall respond with LMP_NOT_ACCEPTED or
LMP_NOT_ACCEPTED_EXT with the Error_Code Unknown LMP PDU (0x19). The
Opcode parameter shall be the unrecognized opcode.

If the LM receives a PDU which contains valid parameters followed by extra data,
it shall either ignore the extra data or shall respond with LMP_NOT_ACCEPTED or
LMP_NOT_ACCEPTED_EXT with the Error_Code Invalid LMP Parameters (0x1E).

If the LM receives a PDU which is too short to hold all the parameters, it shall either
continue with implementation-specific values for the missing or damaged parameters
or shall respond with LMP_NOT_ACCEPTED or LMP_NOT_ACCEPTED_EXT with the
Error_Code Invalid LMP Parameters (0x1E).

If the LM receives a PDU with the correct length but with invalid parameters, it
shall respond with LMP_NOT_ACCEPTED or LMP_NOT_ACCEPTED_EXT with the
Error_Code Invalid LMP Parameters (0x1E).

If the maximum response time (see Section 2.4.1) is exceeded or if a link loss is
detected (see [Vol 2] Part B, Section 3.1), the party that waits for the response shall
conclude that the procedure has terminated unsuccessfully.

Erroneous LMP messages can be caused by errors on the channel or systematic errors
at the transmit side. To detect the latter case, the LM should monitor the number of
erroneous messages and disconnect if it exceeds a threshold, which is implementation-
dependent.

When the LM receives a PDU that is not allowed, and the PDU normally expects a
PDU reply, for example LMP_HOST_CONNECTION_REQ, the LM shall return PDU
LMP_NOT_ACCEPTED or LMP_NOT_ACCEPTED_EXT with the Error_Code LMP

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 2, Part C Page 630
Link Manager Protocol Specification

PDU Not Allowed (0x24). If the PDU normally doesn’t expect a reply, for example
LMP_SRES or LMP_TEMP_KEY, the PDU shall be ignored.

If the LM recognizes the PDU as optional but unsupported then it shall reply
with LMP_NOT_ACCEPTED or LMP_NOT_ACCEPTED_EXT with the Error_Code
Unsupported LMP Feature (0x1A) if the PDU would normally generate a reply;
otherwise it shall ignore the PDU and no reply is generated.

2.5.1 Transaction collision resolution

Since LMP PDUs are not interpreted in real time, collision situations can occur
where both LMs initiate the same procedure and both cannot be completed. In
this situation, the Central shall reject the Peripheral-initiated procedure by sending
LMP_NOT_ACCEPTED or LMP_NOT_ACCEPTED_EXT with the Error_Code LMP
Error Transaction Collision / LL Procedure Collision (0x23). The Central-initiated
procedure shall then be completed.

Collision situations can also occur where both LMs initiate different procedures and both
cannot be completed. In this situation, the Central shall reject the Peripheral-initiated
procedure by sending LMP_NOT_ACCEPTED or LMP_NOT_ACCEPTED_EXT with
the Error_Code Different Transaction Collision (0x2A). The Central-initiated procedure
shall then be completed.

2.6 Procedure rules

Each procedure is described and depicted with a sequence diagram. The symbols in
Figure 2.3 are used in the sequence diagrams:

A B

PDU1

PDU2

PDU3

PDU4

PDU5

Figure 2.3: Symbols used in sequence diagrams

PDU1 is a PDU sent from A to B. PDU2 is a PDU sent from B to A. PDU3 is a PDU that
is optionally sent from A to B. PDU4 is a PDU that is optionally sent from B to A. PDU5
is a PDU sent from either A or B. A vertical line indicates that more PDUs can optionally
be sent.

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 2, Part C Page 631
Link Manager Protocol Specification

2.7 General response messages

The PDUs LMP_ACCEPTED, LMP_ACCEPTED_EXT, LMP_NOT_ACCEPTED and
LMP_NOT_ACCEPTED_EXT are used as response messages to other PDUs in
a number of different procedures. LMP_ACCEPTED or LMP_ACCEPTED_EXT
includes the opcode of the message which is accepted. LMP_NOT_ACCEPTED
or LMP_NOT_ACCEPTED_EXT includes the opcode of the message which is not
accepted and the error code why it is not accepted.

LMP_ACCEPTED_EXT and LMP_NOT_ACCEPTED_EXT shall be used when the

opcode is 15 bits in length. LMP_ACCEPTED and LMP_NOT_ACCEPTED shall be
used when the opcode is 7 bits in length.

M/O PDU Contents

M LMP_ACCEPTED Opcode
M LMP_NOT_ACCEPTED Opcode
Error_Code
O LMP_ACCEPTED_EXT Escape_Opcode
Extended_Opcode
O LMP_NOT_ACCEPTED_EXT Escape_Opcode
Extended_Opcode
Error_Code

Table 2.1: General response messages

2.8 LMP message constraints

The following principles are used in the design of LMP.

• No LMP message exceeds the maximum payload length of a single DM1 packet i.e.
17 bytes in length ([Vol 2] Part B, Section 6.5.4.1).
• All LMP messages are of fixed length.
• The LMP version number is not used to indicate the presence or absence of
functionality.

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 2, Part C Page 632
Link Manager Protocol Specification

3 DEVICE FEATURES

3.1 General description

Each PDU is either Mandatory or Optional as defined by the M/O field in the tables of
Section 4. An M in this field shall indicate that support for the PDU is mandatory. An O in
this field shall indicate that support for the PDU is optional and it shall be followed by the
number(s) of the feature(s) involved in brackets.

Some features have associated LMP feature bits. Support of these features may be
required by the qualification process but the LM still considers them to be optional since
it must interoperate with devices which do not support them.

The LM does not need to be able to transmit a PDU which is optional. Support of
optional PDUs is indicated by a device's features mask. The features mask can be read
(see Section 4.3.4). An LM shall not send or be sent any PDU which is incompatible
with the features signaled in its or its peer's features mask, as detailed in Section 3.2.

The set of features supported by the LM shall not change while the Controller has a
connection to another device. A peer device may cache the device's feature mask or
extended feature mask, or the LM may cache a peer's feature mask or extended feature
mask, during a connection.

3.2 Feature definitions

Feature Definition
3-slot Enhanced This feature indicates whether the device supports the transmission and reception
Data Rate ACL of three-slot Enhanced Data Rate packets on the ACL-U logical link.
packets
3-slot Enhanced This feature indicates whether the device supports the transmission and reception
Data Rate eSCO of 3-slot Enhanced Data Rate packets for the transport of traffic on the eSCO
packets logical transport.
3 slot packets This feature indicates whether the device supports the transmission and reception
of both DM3 and DH3 packets for the transport of traffic on the ACL-U logical link.
5-slot Enhanced This feature indicates whether the device supports the transmission and reception
Data Rate ACL of 5-slot Enhanced Data Rate packets for the transport of traffic on the ACL-U
packets logical link.
5 slot packets This feature indicates whether the device supports the transmission and reception
of both DM5 and DH5 packets for the transport of traffic on the ACL-U logical link.
AFH capable This indicates whether the device is able to support the Adaptive Frequency
Central Hopping mechanism as a Central as defined in [Vol 2] Part B, Section 2.3 using
the LMP sequences defined in Section 4.1.4.

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 2, Part C Page 633
Link Manager Protocol Specification

Feature Definition
AFH capable Pe- This feature indicates whether the device is able to support the Adaptive Frequen-
ripheral cy Hopping mechanism as a Peripheral as defined in [Vol 2] Part B, Section 2.3
using the LMP sequences defined in Section 4.1.4.
AFH classification This feature indicate whether the device is able to support the AFH classification
Central mechanism as a Central as defined in [Vol 2] Part B, Section 8.6.8 using the LMP
sequences defined in Section 4.1.5.
AFH classification This feature indicates whether the device is able to support the AFH classification
Peripheral mechanism as a Peripheral as defined in [Vol 2] Part B, Section 8.6.8 using the
LMP sequences defined in Section 4.1.5.
A-law log syn- This feature indicates whether the device is capable of supporting A-law Log
chronous data format data as defined in [Vol 2] Part B, Section 9.1 on the SCO and eSCO logical
transports.
Broadcast en- This feature indicates whether the device is capable of supporting broadcast
cryption encryption as defined in [Vol 2] Part H, Section 4.2 and also the LMP sequences
defined in Section 4.2.6 and Section 4.2.4.
Channel Quality This feature indicates whether the LM is capable of recommending a packet type
Driven Data Rate (or types) depending on the channel quality using the LMP sequences defined in
Section 4.1.7.
Coarse Clock Ad- This feature indicates whether the device is able to support coarse clock adjust-
justment ments using the LMP sequences defined in Section 4.1.14.
Connectionless This feature indicates whether the device supports Connectionless Peripheral
Peripheral Broad- Broadcast as Receiver.
cast - Receiver
Operation
Connectionless This feature indicates whether the device supports Connectionless Peripheral
Peripheral Broad- Broadcast as Transmitter.
cast - Transmitter
Operation
CVSD synchro- This feature indicates whether the device is capable of supporting CVSD format
nous data data as defined in [Vol 2] Part B, Section 9.2 on the SCO and eSCO logical
transports.
Encapsulated This feature indicates whether the device is capable of supporting the Encapsula-
PDU ted PDU mechanism as defined in Section 4.1.12.1.
Encryption This feature indicates whether the device supports the encryption of packet con-
tents using the LMP sequence defined in Section 4.2.5.
Enhanced Data This feature indicates whether the device supports the transmission and reception
Rate ACL 2 Mb/s of 2-DH1 packets for the transport of traffic on the ACL-U logical link.
mode
Enhanced Data This feature indicates whether the device supports the transmission and reception
Rate ACL 3 Mb/s of 3-DH1 packets for the transport of traffic on the ACL-U logical link.
mode

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 2, Part C Page 634
Link Manager Protocol Specification

Feature Definition
Enhanced Data This feature indicates whether the device supports the transmission and reception
Rate eSCO 2 of 2-EV3 packets for the transport of traffic on the eSCO logical transport.
Mb/s mode
Enhanced Data This feature indicates whether the device supports the transmission and reception
Rate eSCO 3 of 3-EV3 packets for the transport of traffic on the eSCO logical transport.
Mb/s mode
Enhanced power This feature indicates whether the device is able to support enhanced power
control control using the LMP sequences defined in Section 4.1.3.1.
Erroneous Data This feature indicates whether the device is able to support the Packet_Sta-
Reporting tus_Flag and the HCI commands HCI_Write_Default_Erroneous_Data_Reporting
and HCI_Read_Default_Erroneous_Data_Reporting.
EV4 packets This feature indicates whether the device is capable of supporting the EV4 packet
type defined in [Vol 2] Part B, Section 6.5.3.2 on the eSCO logical transport.
EV5 packets This feature indicates whether the device is capable of supporting the EV5 packet
type defined in [Vol 2] Part B, Section 6.5.3.3 on the eSCO logical transport.
Extended fea- This feature indicates whether the device is able to support the extended features
tures mask using the LMP sequences defined in Section 4.3.4.
Extended Inquiry This feature indicates whether the device supports extended inquiry response as
Response defined in [Vol 2] Part B, Section 8.4.3.
Extended SCO This feature indicates whether the device is able to support the eSCO logical
link transport as defined in [Vol 2] Part B, Section 5.5 and the EV3 packet defined in
[Vol 2] Part B, Section 6.5.3.1 using the LMP sequences defined in Section 4.6.2.
Flow control lag This is defined as the total amount of ACL-U data that can be sent following the
receipt of a valid payload header with the payload header flow bit set to 0 and is in
units of 256 bytes. See further in [Vol 2] Part B, Section 6.6.2.
Generalized inter- This feature indicates whether the device is able to support the generalized inter-
laced scan laced scan mechanism described in [Vol 2] Part B, Section 8.3.1 and Section
8.4.1.
The presence of this feature has only local meaning and does not imply support
for any additional LMP PDUs or sequences.
Hold mode This feature indicates whether the device is able to support Hold mode as defined
in [Vol 2] Part B, Section 8.8 using the LMP sequences defined in Section 4.5.1.
HV2 packets This feature indicates whether the device is capable of supporting the HV2 packet
type as defined in [Vol 2] Part B, Section 6.5.2.2 on the SCO logical transport.
HV3 packets This feature indicates whether the device is capable of supporting the HV3 packet
type as defined in [Vol 2] Part B, Section 6.5.2.3 on the SCO logical transport.
Inquiry Response This feature bit indicates whether the device supports sending the HCI_Inqui-
Notification event ry_Response_Notification event to the Host.

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 2, Part C Page 635
Link Manager Protocol Specification

Feature Definition
Interlaced inquiry This feature indicates whether the device is capable of supporting the interlaced
scan inquiry scan mechanism as defined in [Vol 2] Part B, Section 8.4.1. The presence
of this feature has only local meaning and does not imply support for any addition-
al LMP PDUs or sequences.
Interlaced page This feature indicates whether the device is capable of supporting the interlaced
scan page scan mechanism as defined in [Vol 2] Part B, Section 8.3.1. The presence of
this feature has only local meaning and does not imply support for any additional
LMP PDUs or sequences.
LE Supported This feature indicates whether the Controller supports LE.
(Controller) The local Host uses this feature bit to determine whether the Controller supports
LE.
A remote device does not use this feature bit.
LE Supported This feature indicates that the Host supports LE.
(Host) The local Host sets this feature bit to indicate to a remote device that the local
device is capable of supporting LE.
A remote Host uses this feature bit to determine whether an LE connection to the
peer device is possible.
Link Supervision This feature bit indicates whether the device supports the sending the
Timeout Changed HCI_Link_Supervision_Timeout_Changed event to the Host.
event
μ-law log syn- This feature indicates whether the device is capable of supporting µ-law Log
chronous data format data as defined in [Vol 2] Part B, Section 9.1 on the SCO and eSCO logical
transports.
Non-flushable This feature indicates that the device supports the capability to correctly handle
Packet Boundary HCI ACL Data packets with a Packet_Boundary_Flag value of 00 (Non-Automati-
Flag cally-Flushable packet).
Paging parameter This feature indicates whether the LM is capable of supporting the signaling of
negotiation changes in the paging scheme as defined in Section 4.1.9.
Pause Encryption When this feature bit is enabled on both sides, then the encryption pause and
resume sequences shall be used. If either side does not support the Pause
Encryption feature bit, then the encryption pause and resume sequences shall not
be used.
Ping This feature indicates whether the device supports the transmission and reception
of ping messages.
Power control This feature indicates whether the device is capable of adjusting its transmis-
sion power. This feature indicates the ability to receive the LMP_INCR_POW-
ER and LMP_DECR_POWER PDUs and transmit the LMP_MAX_POWER and
LMP_MIN_POWER PDUs, using the LMP sequences defined in Section 4.1.3.
These sequences may be used even if the remote device does not support the
power control feature, as long as it supports the Power control requests feature.

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 2, Part C Page 636
Link Manager Protocol Specification

Feature Definition
Power control re- This feature indicates whether the device is capable of determining if the
quests transmit power level of the other device should be adjusted and will send
the LMP_INCR_POWER and LMP_DECR_POWER PDUs to request the ad-
justments. It indicates the ability to receive the LMP_MAX_POWER and
LMP_MIN_POWER PDUs, using the LMP sequences defined in Section 4.1.3.
These sequences may be used even if the remote device does not support the
RSSI feature, as long as it supports the power control feature.
Role switch This feature indicates whether the device supports the exchange of Central and
Peripheral roles as defined by [Vol 2] Part B, Section 8.6.5 using the LMP se-
quence defined in Section 4.4.2.
RSSI with inquiry This feature indicates whether the device is capable of reporting the RSSI with
results inquiry results as defined in [Vol 2] Part B, Section 8.4.2. The presence of this
feature has only local meaning and does not imply support for any additional LMP
PDUs or sequences.
SCO link This feature shall indicate whether the device is able to support the SCO logical
transport as defined in [Vol 2] Part B, Section 4.3, the HV1 packet defined in [Vol
2] Part B, Section 6.5.2.1 and receiving the DV packet defined in [Vol 2] Part B,
Section 6.5.2.4 using the LMP sequence defined in Section 4.6.1.
Secure Connec- This feature indicates whether the Controller is able to support AES-CCM, the
tions (Controller P-256 Elliptic Curve for Secure Simple Pairing, and enhanced authentication us-
Support) ing the LMP sequences defined in Section 4.2.7.
Secure Connec- This feature indicates whether the Host is capable of supporting Secure Connec-
tions (Host Sup- tions.
port) If HCI is supported, this bit shall be set if the HCI_Write_Secure_Connec-
tions_Host_Support command has been issued by the Host. When HCI is not
supported, this bit may be set using a vendor specific mechanism.
Secure Simple This feature indicates whether the Link Manager is capable of supporting Secure
Pairing (Control- Simple Pairing as defined in Section 4.2.7.
ler Support)
Secure Simple This feature indicates whether the Host is capable of supporting Secure Simple
Pairing (Host Pairing as defined in Section 4.2.7.
Support) If HCI is supported, this bit shall be set if the HCI_Write_Simple_Pairing_Mode
command has been issued to enable the Secure Simple Pairing feature. When
HCI is not supported, this bit may be set using a vendor specific mechanism.
Simultaneous LE This feature indicates that the Controller supports simultaneous LE and BR/EDR
and BR/EDR to links to the same remote device.
Same Device Ca- The local Host uses this feature bit to determine whether the Controller is capable
pable (Controller) of supporting simultaneous LE and BR/EDR connections to a remote device.
A remote device does not use this feature bit.
Slot Availability This feature indicates whether the device is able to support Slot Availability Mask
Mask using the LMP sequences defined in Section 4.1.15.
Slot offset This feature indicates whether the LM supports the transfer of the slot offset using
the LMP sequence defined in Section 4.4.1.

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 2, Part C Page 637
Link Manager Protocol Specification

Feature Definition
Sniff mode This feature indicates whether the device is able to support Sniff mode as defined
in [Vol 2] Part B, Section 8.7 using the LMP sequences defined in Section 4.5.3.
Sniff subrating This feature indicates whether the device is able to support sniff subrating as
defined in [Vol 2] Part B, Section 8.7.2 using the LMP sequences defined in
Section 4.5.3.3.
Synchronization This feature indicates whether the device supports Synchronization Scan as Pe-
Scan ripheral.
Synchronization This feature indicates whether the device supports Synchronization Train as Cen-
Train tral.
Timing accuracy This feature indicates whether the LM supports requests for timing accuracy using
the LMP sequence defined in Section 4.3.1.
Train nudging This feature indicates whether the device is able to support the train nudging
mechanism described in [Vol 2] Part B, Section 8.3.2 and Section 8.4.2.
The presence of this feature has only local meaning and does not imply support
for any additional LMP PDUs or sequences.
Transparent syn- This feature indicates whether the device is capable of supporting transparent
chronous data synchronous data as defined in [Vol 2] Part B, Section 6.4.3 on the SCO and
eSCO logical transports.
Variable Inquiry This feature indicates whether the device is capable of setting the TX power level
TX Power Level for Inquiry.

Table 3.1: Feature definitions

3.3 Feature mask definition

The features are represented as a bit mask when they are transferred in LMP
messages. For each feature a single bit is specified which shall be set to 1 if the feature
is supported and set to 0 otherwise. The single exception is the flow control lag which is
coded as a 3 bit field with the least significant bit in byte 2 bit 4 and the most significant
bit in byte 2 bit 6. All unassigned feature bits are reserved for future use.

No. Supported feature Byte Bit

0 3 slot packets 0 0
1 5 slot packets 0 1
2 Encryption 0 2
3 Slot offset 0 3
4 Timing accuracy 0 4
5 Role switch 0 5
6 Hold mode 0 6
7 Sniff mode 0 7

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 2, Part C Page 638
Link Manager Protocol Specification

No. Supported feature Byte Bit

8 Previously used 1 0
9 Power control requests 1 1
10 Channel quality driven data rate (CQDDR) 1 2
11 SCO link 1 3
12 HV2 packets 1 4
13 HV3 packets 1 5
14 μ-law log synchronous data 1 6
15 A-law log synchronous data 1 7
16 CVSD synchronous data 2 0
17 Paging parameter negotiation 2 1
18 Power control 2 2
19 Transparent synchronous data 2 3
20 Flow control lag (least significant bit) 2 4
21 Flow control lag (middle bit) 2 5
22 Flow control lag (most significant bit) 2 6
23 Broadcast Encryption 2 7
24 Reserved for future use 3 0
25 Enhanced Data Rate ACL 2 Mb/s mode 3 1
26 Enhanced Data Rate ACL 3 Mb/s mode 3 2
27 Enhanced inquiry scan (see note) 3 3
28 Interlaced inquiry scan 3 4
29 Interlaced page scan 3 5
30 RSSI with inquiry results 3 6
31 Extended SCO link (EV3 packets) 3 7
32 EV4 packets 4 0
33 EV5 packets 4 1
34 Reserved for future use 4 2
35 AFH capable Peripheral 4 3
36 AFH classification Peripheral 4 4
37 Previously used 4 5
38 LE Supported (Controller) 4 6
39 3-slot Enhanced Data Rate ACL packets 4 7
40 5-slot Enhanced Data Rate ACL packets 5 0

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 2, Part C Page 639
Link Manager Protocol Specification

No. Supported feature Byte Bit

41 Sniff subrating 5 1
42 Pause encryption 5 2
43 AFH capable Central 5 3
44 AFH classification Central 5 4
45 Enhanced Data Rate eSCO 2 Mb/s mode 5 5
46 Enhanced Data Rate eSCO 3 Mb/s mode 5 6
47 3-slot Enhanced Data Rate eSCO packets 5 7
48 Extended Inquiry Response 6 0
49 Simultaneous LE and BR/EDR to Same Device Capable 6 1
(Controller)
50 Reserved for future use 6 2
51 Secure Simple Pairing (Controller Support) 6 3
52 Encapsulated PDU 6 4
53 Erroneous Data Reporting 6 5
54 Non-flushable Packet Boundary Flag 6 6
55 Reserved for future use 6 7
56 HCI_Link_Supervision_Timeout_Changed event 7 0
57 Variable Inquiry TX Power Level 7 1
58 Enhanced Power Control 7 2
59 Reserved for future use 7 3
60 Reserved for future use 7 4
61 Reserved for future use 7 5
62 Reserved for future use 7 6
63 Extended features 7 7

Table 3.2: Feature mask page 0 definitions

No. Supported Feature Byte Bit

64 Secure Simple Pairing (Host Support) 0 0
65 LE Supported (Host) 0 1
66 Previously used 0 2
67 Secure Connections (Host Support) 0 3

Table 3.3: Feature mask page 1 definitions

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 2, Part C Page 640
Link Manager Protocol Specification

No. Supported Feature Byte Bit

128 Connectionless Peripheral Broadcast – Transmitter Opera- 0 0
tion
129 Connectionless Peripheral Broadcast – Receiver Operation 0 1
130 Synchronization Train 0 2
131 Synchronization Scan 0 3
132 HCI_Inquiry_Response_Notification event 0 4
133 Generalized interlaced scan 0 5
134 Coarse Clock Adjustment 0 6
135 Reserved for future use 0 7
136 Secure Connections (Controller Support) 1 0
137 Ping 1 1
138 Slot Availability Mask 1 2
139 Train nudging 1 3

Table 3.4: Feature mask page 2 definitions

Note: Feature bit 27 (“Enhanced Inquiry Scan”) is no longer used in the specification.
Devices may set this bit but are not required to.

3.4 Link Manager interoperability policy

Link managers of any version shall interpret using the lowest common subset of
functionality by reading the LMP features mask (defined in Table 3.2).

An optional LMP PDU shall only be sent to a device if the corresponding feature bit is
set in its feature mask. The exception to this are certain PDUs (see Section 4.1.1) which
can be sent before the features mask is requested.

Note: A higher version device with a restricted feature set is indistinguishable from a
lower version device with the same features.

3.5 Feature requirements

Note: In the tables in this section, numbers in parentheses before feature names are the
corresponding feature bit numbers (see Section 3.3).

Any device supporting any feature with a feature bit number greater than or equal to 64
shall support Extended features and shall set feature bit 63.

The features listed in Table 3.5 are mandatory in this version of the specification (see
Section 3.1) and these feature bits shall be set.

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 2, Part C Page 641
Link Manager Protocol Specification

Feature
(2) Encryption
(51) Secure Simple Pairing (Controller Support)
(52) Encapsulated PDU

Table 3.5: Mandatory features

For each row of Table 3.6, either every feature named in that row shall be supported or
none of the features named in that row shall be supported.

Features
(7) Sniff mode (41) Sniff subrating

Table 3.6: Mutually supporting features

For each row of Table 3.7, not more than one feature in that row shall be supported.

Features
(23) Broadcast encryption (134) Coarse clock adjustment

Table 3.7: Mutually exclusive features

For each row of Table 3.8, if the feature named in the first column is supported then the
feature named in the second column shall be supported.

Feature Required feature

(5) Role switch (3) Slot offset
(12) HV2 packets (11) SCO link
(13) HV3 packets (11) SCO link
(14) µ-law log synchronous data (11) SCO link or
(31) Extended SCO link (EV3 packets)
(15) A-law log synchronous data (11) SCO link or
(31) Extended SCO link (EV3 packets)
(16) CVSD log synchronous data (11) SCO link or
(31) Extended SCO link (EV3 packets)
(19) Transparent synchronous data (11) SCO link or
(31) Extended SCO link (EV3 packets)
(23) Broadcast encryption (2) Encryption
(26) Enhanced Data Rate ACL 3 Mb/s mode (25) Enhanced Data Rate ACL 2 Mb/s mode
(32) EV4 packets (31) Extended SCO link (EV3 packets)
(33) EV5 packets (31) Extended SCO link (EV3 packets)

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 2, Part C Page 642
Link Manager Protocol Specification

Feature Required feature

(36) AFH classification Peripheral (35) AFH capable Peripheral
(39) 3-slot Enhanced Data Rate ACL packets (25) Enhanced Data Rate ACL 2 Mb/s mode
(40) 5-slot Enhanced Data Rate ACL packets (25) Enhanced Data Rate ACL 2 Mb/s mode
(42) Pause encryption (2) Encryption
(44) AFH classification Central (43) AFH capable Central
(45) Enhanced Data Rate eSCO 2 Mb/s mode (31) Extended SCO link (EV3 packets)
(46) Enhanced Data Rate eSCO 3 Mb/s mode (45) Enhanced Data Rate eSCO 2 Mb/s mode
(47) 3-slot Enhanced Data Rate eSCO packets (45) Enhanced Data Rate eSCO 2 Mb/s mode
(48) Extended inquiry response (30) RSSI with inquiry results
(49) Simultaneous LE and BR/EDR to Same Device (38) LE Supported (Controller)
Capable (Controller)
(51) Secure Simple Pairing (Controller Support) (2) Encryption
(53) Erroneous data reporting (11) SCO link or
(31) Extended SCO link (EV3 packets)
(58) Enhanced power control (9) Power control requests and
(18) Power control
(65) LE Supported (Host) (38) LE Supported (Controller)
(67) Secure Connections (Host Support) (64) Secure Simple Pairing (Host Support) and
(136) Secure Connections (Controller Support)
(128) Connectionless Peripheral Broadcast – Trans- (130) Synchronization Train
mitter Operation
(129) Connectionless Peripheral Broadcast – Receiv- (131) Synchronization Scan
er Operation
(133) Generalized interlaced scan (28) Interlaced inquiry scan or
(29) Interlaced page scan
(134) Coarse clock adjustment (35) AFH capable Peripheral and
(43) AFH capable Central and
(130) Synchronization Train and
(131) Synchronization Scan
(136) Secure Connections (Controller Support) (2) Encryption and
(42) Pause encryption and
(137) Ping

Table 3.8: Features that require other features

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 2, Part C Page 643
Link Manager Protocol Specification

For each row of Table 3.9, the feature in the first column shall be supported if and only if
the implementation supports HCI and the HCI command or event named in the second
column.

Feature HCI command or event

(53) Erroneous Data Reporting HCI_Write_Default_Erroneous_Data_Reporting
(56) Link Supervision Timeout Changed event HCI_Link_Supervision_Timeout_Changed
(132) Inquiry Response Notification event HCI_Inquiry_Response_Notification

Table 3.9: Features relating to HCI commands and events

3.5.1 [This section is no longer used]

3.5.2 [This section is no longer used]

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 2, Part C Page 644
Link Manager Protocol Specification

4 PROCEDURE RULES

4.1 Connection control

4.1.1 Connection establishment

After the paging procedure, LMP procedures for clock offset request, LMP version,
supported features, name request and detach may then be initiated.

Paging Paged
device device
Baseband page procedure

LMP procedures for clock offset request, LMP version, supported

features, name request and/or detach
LMP_HOST_CONNECTION_REQ

LMP_ACCEPTED or LMP_NOT_ACCEPTED

LMP procedures for pairing, authentication and encryption

LMP_SETUP_COMPLETE

LMP_SETUP_COMPLETE

Figure 4.1: Connection establishment

When the paging device wishes to create a connection involving layers above LM, it
sends an LMP_HOST_CONNECTION_REQ PDU. When the other side receives this
message, the Host is informed about the incoming connection. The remote device
can accept or reject the connection request by sending an LMP_ACCEPTED PDU or
an LMP_NOT_ACCEPTED PDU. Alternatively, if the Peripheral needs a role switch,
see Section 4.4.2, it sends an LMP_SLOT_OFFSET PDU and LMP_SWITCH_REQ
PDU after it has received an LMP_HOST_CONNECTION_REQ PDU. If the role
switch fails the LM shall continue with the creation of the connection unless this
cannot be supported due to limited resources in which case the connection shall be
terminated with an LMP_DETACH PDU with Error_Code Remote Device Terminated
Connection due to Low Resources (0x14). When the role switch has been successfully
completed, the old Peripheral will reply with an LMP_ACCEPTED PDU or an
LMP_NOT_ACCEPTED PDU to the LMP_HOST_CONNECTION_REQ PDU (with the
transaction ID set to 0).

If the paging device receives an LMP_NOT_ACCEPTED PDU in response to

LMP_HOST_CONNECTION_REQ it shall immediately disconnect the link using the
mechanism described in Section 4.1.2.

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 2, Part C Page 645
Link Manager Protocol Specification

If the LMP_HOST_CONNECTION_REQ PDU is accepted, LMP security procedures

(pairing, authentication and encryption) may be invoked. When a device is not
going to initiate any more security procedures during connection establishment
it sends an LMP_SETUP_COMPLETE PDU. When both devices have sent
LMP_SETUP_COMPLETE PDUs the traffic can be transferred on the BR/EDR ACL
logical transport.

M/O PDU Contents

M LMP_HOST_CONNECTION_REQ none
M LMP_SETUP_COMPLETE none
Table 4.1: Connection establishment PDU

4.1.2 Detach

The connection between two Bluetooth devices may be detached anytime by the
Central or the Peripheral. An Error_Code parameter is included in the message to
inform the other party of why the connection is detached.

M/O PDU Contents

M LMP_DETACH Error_Code
Table 4.2: Detach PDU

The initiating LM shall pause traffic on the ACL-U logical link (see [Vol 2] Part B,
Section 5.3.1). The initiating LM then queues the LMP_DETACH for transmission and
it shall start a timer for 6×Tpoll slots where Tpoll is the poll interval for the connection.
If the initiating LM receives the Baseband acknowledgment before the timer expires it
starts a timer for 3×Tpoll slots. When this timer expires, and if the initiating LM is the
Central, the LT_ADDR(s) may be re-used immediately. If the initial timer expires then
the initiating LM drops the link and starts a timer for Tlinksupervisiontimeout slots after which
the LT_ADDR(s) may be re-used if the initiating LM is the Central.

When the receiving LM receives the LMP_DETACH, it shall start a timer for 6×Tpoll
slots if it is the Central and 3×Tpoll if it is the Peripheral. On timer expiration, the
link shall be detached and, if the receiving LM is the Central, the LT_ADDR(s) may
be re-used immediately. If the receiver never receives the LMP_DETACH then a link
supervision timeout will occur, the link will be detached, and the LT_ADDR may be
re-used immediately.

If at any time during this or any other LMP sequence the Link supervision timeout
expires then the link shall be terminated immediately and the LT_ADDR(S) may be
re-used immediately.

If the connection is in Hold mode, the initiating LM shall wait for Hold mode to end
before initiating the procedure defined above. If the connection is in Sniff mode,

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 2, Part C Page 646
Link Manager Protocol Specification

the initiating LM shall perform the procedure to exit Sniff mode before initiating the
procedure defined above. If the procedure to exit Sniff mode does not complete within
the LMP response timeout (30 seconds) the procedure defined above shall be initiated
anyway.

Initiating
LM
LM
LMP_DETACH

Sequence 1: Connection closed by sending LMP_DETACH

If there are any SCO or eSCO connections open on the same physical link, sending or
receiving the LMP_DETACH PDU implicitly removes them and the initiating LM should
not send separate PDUs for this purpose when detaching.

4.1.3 Power control

If the received signal characteristics differ too much from the preferred value of a
Bluetooth device, it may request an increase or a decrease of the other device’s
transmit power level. A device's transmit power level is a property of the physical link,
and affects all logical transports carried over the physical link. Power control requests
carried over the default ACL-C logical link shall only affect the physical link associated
with the requesting device’s default ACL-C logical link; they shall not affect the power
level used on the physical links to other Peripherals.

Two power control mechanisms are specified: legacy power control (see Table 4.3) and
enhanced power control (see Table 4.4 and Section 4.1.3.1).

M/O PDU Contents

O(9) LMP_INCR_POWER_REQ Reserved
O(9) LMP_DECR_POWER_REQ Reserved
O(18) LMP_MAX_POWER none
O(18) LMP_MIN_POWER none
Table 4.3: Legacy power control PDU

M/O PDU Contents

O(58) LMP_POWER_CONTROL_REQ Power_Adj_Req
O(58) LMP_POWER_CONTROL_RES Power_Adj_Rsp
Table 4.4: Enhanced power control PDU

The power adjustment requests may be made at any time using the legacy power
control mechanism following a successful Baseband Paging procedure and before

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 2, Part C Page 647
Link Manager Protocol Specification

the link manager supported features responses have been processed. After the Link
Manager supported features responses have been processed, if both devices support
enhanced power control (see Section 4.1.3.1) then only enhanced power control shall
be used. Otherwise, if either device supports only the legacy power control mechanism
then only legacy power control shall be used.

If a device does not support power control requests this is indicated in the
supported features list and thus no power control requests shall be sent after
the supported features response has been processed. Prior to this time, a power
control adjustment might be sent, and if the recipient does not support power
control, it shall send LMP_MAX_POWER in response to LMP_INCR_POWER_REQ
and LMP_MIN_POWER in response to LMP_DECR_POWER_REQ or shall send
LMP_NOT_ACCEPTED with the Error_Code Unsupported LMP Feature (0x1A) in
response to either PDU.

Upon receipt of an LMP_INCR_POWER_REQ PDU or LMP_DECR_POWER_REQ

PDU the output power shall be increased or decreased one step. See [Vol 2] Part A,
Section 5.2 for the definition of the step size.

Initiating
LM
LM
LMP_INCR_POWER_REQ or LMP_DECR_POWER_REQ

Sequence 2: A device requests a change of the other device’s TX power

If the receiver of LMP_INCR_POWER_REQ is at maximum power LMP_MAX_POWER

shall be returned. The device shall only request an increase again after having
requested a decrease at least once. If the receiver of LMP_DECR_POWER_REQ is
at minimum power then LMP_MIN_POWER shall be returned and the device shall only
request a decrease after having requested an increase at least once.

Initiating
LM
LM
LMP_INCR_POWER_REQ

LMP_MAX_POWER

Sequence 3: The TX power cannot be increased

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 2, Part C Page 648
Link Manager Protocol Specification

Initiating
LM
LM
LMP_DECR_POWER_REQ

LMP_MIN_POWER

Sequence 4: The TX power cannot be decreased

One byte in LMP_INCR/DECR_POWER_REQ is reserved for future use.

4.1.3.1 Enhanced power control

Enhanced power control shall only be used when both devices support the enhanced
power control LMP feature. Legacy power control shall not be used when both devices
support the enhanced power control LMP feature.

4.1.3.1.1 Sending enhanced power control requests

To adjust the remote device's output power, a device shall send the
LMP_POWER_CONTROL_REQ PDU with the Power_Adj_Req parameter.

The Power_Adj_Req parameter may be set to: one step up, one step down,
or all the way to the max power level. The remote device shall respond
with an LMP_POWER_CONTROL_RES PDU. The responder shall transmit the
LMP_POWER_CONTROL_RES PDU at the new power level. Upon reception of the
LMP_POWER_CONTROL_RES PDU, the initiating device should restart any processes
used to determine whether additional power level changes are required.

If the receiver of the LMP_POWER_CONTROL_REQ PDU has indicated that the output
power levels for all of the supported modulation modes are at maximum the requesting
device shall only request an increase again after having requested a decrease at least
once. If the receiver of the LMP_POWER_CONTROL_REQ PDU has indicated that
the output power levels for all of the supported modulation modes are at minimum the
requesting device shall only request a decrease after having requested an increase at
least once.

A new LMP_POWER_CONTROL_REQ PDU shall not be sent until an

LMP_POWER_CONTROL_RES PDU has been received.

4.1.3.1.2 Responding to enhanced power control requests

When a device receives an LMP_POWER_CONTROL_REQ PDU with the

Power_Adj_Req parameter set to "increment one step," all supported modulations that
are not at the maximum level shall be increased one step.

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 2, Part C Page 649
Link Manager Protocol Specification

When a device receives an LMP_POWER_CONTROL_REQ PDU with the

Power_Adj_Req parameter set to "decrement one step", all supported modulations that
are not at the minimum level shall be decreased one step.

Implementations shall not violate the relative power level between modulations (see [Vol
2] Part A, Section 5.2).

When a device receives an LMP_POWER_CONTROL_REQ PDU with the

Power_Adj_Req parameter set to "increment power to maximum value", each
supported modulation mode shall be set to its maximum power level.

Note: See [Vol 2] Part A, Section 5.2 for requirements on the relative power levels of
different modulation modes.

The responding LM shall send the LMP_POWER_CONTROL_RES PDU to indicate

the status for every modulation. The Power_Adj_Rsp parameter has three 2-bit fields
indicating the status for each modulation mode: GFSK, π/4-DQPSK and 8DPSK. Each
2-bit field shall be set to one of the following values: not supported, changed one step,
max power, or min power. The changed one step value shall only be used when the
power level for that modulation mode has not reached the minimum or maximum level.

The not supported value shall be used for each unsupported modulation type.

The responder shall transmit the LMP_POWER_CONTROL_RES PDU at the new

transmit power level and shall not change its power level until requested by the remote
device by a subsequent LMP_POWER_CONTROL_REQ PDU.

Initiating
LM
LM
LMP_POWER_CONTROL_REQ

LMP_POWER_CONTROL_RES

Sequence 5: A device responds to a power control request

4.1.4 Adaptive frequency hopping

AFH is used to improve the performance of physical links in the presence of

interference as well as reducing the interference caused by physical links on other
devices in the ISM band. AFH shall only be used during Connection state.

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 2, Part C Page 650
Link Manager Protocol Specification

M/O PDU Contents

O(35) Rx LMP_SET_AFH AFH_Instant,
O(43) Tx AFH_Mode,
AFH_Channel_Map

Table 4.5: AFH PDU

The LMP_SET_AFH PDU contains three parameters: AFH_Instant, AFH_Mode, and

AFH_Channel_Map. The parameter, AFH_Instant, specifies the instant at which the
hopset switch shall become effective. This is specified as a Bluetooth Clock value of
the Central’s clock, that is available to both devices. The AFH instant is chosen by the
Central and shall be an even value at least 6×Tpoll or 96 slots (whichever is greater)
in the future. The AFH_Instant shall be within 12 hours of the current clock value.
The parameter AFH_Mode, specifies whether AFH shall be enabled or disabled. The
parameter AFH_Channel_Map, specifies the set of channels that shall be used if AFH is
enabled.

When the LMP_SET_AFH PDU is received the AFH instant shall be compared with
the current Bluetooth clock value. If it is in the past then the AFH_Instant has passed
and the Peripheral shall immediately configure the hop selection kernel (see [Vol 2]
Part B, Section 2.6.3) with the new AFH_Mode and AFH_Channel_Map specified in the
LMP_SET_AFH PDU. If it is in the future then a timer shall be started to expire at the
AFH instant. When this timer expires it shall configure the hop selection kernel with the
new AFH_Mode and AFH_Channel_Map.

The Central shall not send a new LMP_SET_AFH PDU to a Peripheral until it has
received the Baseband acknowledgment for any previous LMP_SET_AFH addressed to
that Peripheral and the instant has passed.

Role switch while AFH is enabled shall follow the procedures define by [Vol 2] Part B,
Section 8.6.5.

4.1.4.1 Central enables AFH

Prior to enabling AFH the Central LM shall pause traffic on the ACL-U logical
link (see [Vol 2] Part B, Section 5.3.1). The Central shall then enable AFH on a
physical link by sending the LMP_SET_AFH PDU with AFH_Mode set to enabled, the
AFH_Channel_Map parameter containing the set of used and unused channels, and an
AFH_instant. The LM shall not calculate the AFH instant until after traffic on the ACL-U
logical link has been stopped. The Central considers the physical link to have entered
AFH-enabled operation once the Baseband acknowledgment has been received and
the AFH_Instant has passed. Once the Baseband acknowledgment has been received
the Central shall restart transmission on the ACL-U logical link.

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 2, Part C Page 651
Link Manager Protocol Specification

Central Peripheral
LM LM

LMP_SET_AFH (enable, map)

Sequence 6: Central enables AFH

4.1.4.2 Central disables AFH

Prior to disabling AFH the Central LM shall pause traffic on the ACL-U logical link
([Vol 2] Part B, Section 5.3.1). The Central shall then disable AFH operation on a
physical link by sending the LMP_SET_AFH PDU with AFH_mode set to disabled and
an AFH_Instant. The AFH_Channel_Map parameter is not valid when AFH_Mode is
disabled. The LM shall not calculate the AFH instant until after traffic on the ACL-U
logical link has been stopped. The Central considers the physical link to have entered
AFH-disabled operation once the Baseband acknowledgment has been received and
the AFH_Instant has passed. Once the Baseband acknowledgment has been received
the Central shall restart transmission on the ACL-U logical link.

Central Peripheral
LM LM

LMP_SET_AFH (disable)

Sequence 7: Central disables AFH

4.1.4.3 Central updates AFH

A Central shall update the AFH parameters on a physical link by sending the
LMP_SET_AFH PDU with AFH_Mode set to enabled, an AFH_Instant and a new
AFH_Channel_Map. The Central shall consider the Peripheral to have the updated
AFH parameters once the Baseband acknowledgment has been received and the
AFH_Instant has passed.

Central Peripheral
LM LM

LMP_SET_AFH (enable, map)

Sequence 8: Central updates AFH

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 2, Part C Page 652
Link Manager Protocol Specification

4.1.4.4 AFH operation in Hold and Sniff modes

A Peripheral in Hold mode or Sniff mode shall retain the AFH_Mode and
AFH_Channel_Map it was using prior to entering those modes. A Central may change
the AFH_Mode while a Peripheral is in Sniff mode.

A Central that receives a request from an AFH-enabled Peripheral to enter Hold mode
or Sniff mode and decides to operate the Peripheral using a different hop sequence
shall respond with an LMP_SET_AFH PDU specifying the new hop sequence.

The Central continues with the LMP signaling, for Hold or Sniff initiation, once the
Baseband acknowledgment for the LMP_SET_AFH PDU has been received. Optionally,
the Central may delay the continuation of this LMP signaling until after the instant. An
AFH capable Peripheral shall support both of these cases.

A Central that receives a request from an AFH-enabled Peripheral to enter Hold mode
or Sniff mode and decides not to change the Peripheral's hop sequence shall respond
exactly as it would do without AFH. In this case, AFH operation has no effect on the
LMP signaling.

4.1.5 Channel classification

A Central may request channel classification information from a Peripheral that is AFH-
enabled.

A Peripheral that supports the AFH_classification_Peripheral feature

shall perform channel classification and reporting according to its
AFH_reporting_mode. The Central shall control the AFH_reporting_mode using the
LMP_CHANNEL_CLASSIFICATION_REQ PDU. The Peripheral shall report its channel
classification using the LMP_CHANNEL_CLASSIFICATION PDU.

The Peripheral shall report pairs of channels as good, bad or unknown. See Table 5.2
for the detailed format of the AFH_Channel_Classification parameter. When one
channel in the nth channel pair is good and the other channel is unknown the nth
channel pair shall be reported as good. When one channel in the nth channel pair
is bad and the other is unknown the nth channel pair shall be reported as bad. It is
implementation dependent what to report when one channel in a channel pair is good
and the other is bad.

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 2, Part C Page 653
Link Manager Protocol Specification

M/O PDU Contents

O(36) Rx LMP_CHANNEL_CLASSIFICATION_REQ AFH_Reporting_Mode,
O(44) Tx AFH_Min_Interval,
AFH_Max_Interval
O(36) Tx LMP_CHANNEL_CLASSIFICATION AFH_Channel_-
Classification
O(44) Rx

Table 4.6: Channel classification PDU

The LMP_CHANNEL_CLASSIFICATION_REQ PDU contains three parameters:

AFH_Reporting_Mode, AFH_Min_Interval, and AFH_Max_Interval. In the disabled
state, the Peripheral shall not generate any channel classification reports.
The parameter AFH_min_interval, defines the minimum amount of time from
the last LMP_CHANNEL_CLASSIFICATION command that was sent before
the next LMP_CHANNEL_CLASSIFICATION PDU may be sent. The parameter
AFH_max_interval, defines the maximum amount of time between the change in
the channel classification being detected by a Peripheral and its generation of an
LMP_CHANNEL_CLASSIFICATION PDU. The AFH_max_interval shall be equal to or
larger than AFH_min_interval.

The AFH_reporting_mode parameter shall determine if the Peripheral is in

the enabled or disabled state. The default state, prior to receipt of any
LMP_CHANNEL_CLASSIFICATION_REQ PDUs, shall be disabled.

AFH_reporting_mode is implicitly set to the disabled state when any of the following
occur:

• Establishment of a connection at the Baseband level

• Role switch
• Entry to Hold mode operation

AFH_reporting_mode is implicitly restored to its former value when any of the following
occur:

• Exit from Hold mode

• Failure of role switch

4.1.5.1 Channel classification reporting enabling and disabling

A Central enables Peripheral channel classification reporting by sending

the LMP_CHANNEL_CLASSIFICATION_REQ PDU with the AFH_reporting_mode
parameter set to enabled.

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 2, Part C Page 654
Link Manager Protocol Specification

When a Peripheral has had classification reporting enabled by the Central

it shall send the LMP_CHANNEL_CLASSIFICATION PDU according to the
information in the latest LMP_CHANNEL_CLASSIFICATION_REQ PDU. The
LMP_CHANNEL_CLASSIFICATION PDU shall not be sent if there has been no change
in the Peripheral’s channel classification.

A Central disables Peripheral channel classification reporting by sending

the LMP_CHANNEL_CLASSIFICATION_REQ PDU with the AFH_reporting_mode
parameter set to disabled.

Central Peripheral
LM LM
LMP_CHANNEL_CLASSIFICATION_REQ (enable)

...

LMP_CHANNEL_CLASSIFICATION

...

LMP_CHANNEL_CLASSIFICATION

...

LMP_CHANNEL_CLASSIFICATION_REQ (disable)

Sequence 9: Channel classification reporting

4.1.6 Link supervision

Each physical link has a timer that is used for link supervision. This timer is used to
detect physical link loss caused by devices moving out of range, or being blocked by
interference, a device’s power-down, or other similar failure cases. Link supervision is
specified in [Vol 2] Part B, Section 3.1.

M/O PDU Contents

M LMP_SUPERVISION_TIMEOUT Supervision_Timeout

Table 4.7: Set supervision timeout PDU

Central Peripheral
LM LM
LMP_SUPERVISION_TIMEOUT

Sequence 10: Setting the link supervision timeout

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 2, Part C Page 655
Link Manager Protocol Specification

4.1.7 Channel quality driven data rate change (CQDDR)

The data throughput for a given packet type depends on the quality of the RF channel.
Quality measurements in the receiver of one device can be used to dynamically
control the packet type transmitted from the remote device for optimization of the data
throughput. Device A sends the LMP_AUTO_RATE PDU once to notify device B to
enable this feature. Once enabled, device B may request packet type(s) that A should
transmit by sending the LMP_PREFERRED_RATE PDU. This PDU has a parameter
which determines the preferred error coding (with or without 2/3 FEC) and optionally the
preferred size in slots of the packets. Device A is not required to change to the packet
type specified by this parameter. Device A shall not send a packet that is larger than
max slots (see Section 4.1.10) even if the preferred size is greater than this value.

The Data_Rate parameter includes the preferred rate for Basic Rate and Enhanced
Data Rate modes. When operating in Basic Rate mode, the device shall use bits 0 to
2 to determine the preferred data rate. When operating in Enhanced Data Rate mode,
the device shall use bits 3 to 6 to determine the preferred data rate. For devices that
support Enhanced Data Rate, the preferred rates for both Basic Rate and Enhanced
Data Rate modes shall be valid at all times.

These PDUs may be sent at any time after connection setup is completed.

M/O PDU Contents

O(10) LMP_AUTO_RATE none
O(10) LMP_PREFERRED_RATE Data_Rate

Table 4.8: Quality-driven change of the data rate PDU

A LM B LM

LMP_AUTO_RATE

Sequence 11: A notifies B to enable CQDDR

A LM B LM

LMP_PREFERRED_RATE

Sequence 12: B sends A a preferred packet type

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 2, Part C Page 656
Link Manager Protocol Specification

4.1.8 Quality of service (QoS)

The LM provides QoS capabilities. A poll interval, Tpoll , that is defined as the maximum
time between transmissions from the Central to a particular Peripheral on the ACL
logical transport, is used to support bandwidth allocation and latency control - see [Vol
2] Part B, Section 8.6.1 for details. The poll interval shall be met in the Active and Sniff
modes except when there are collisions with page, page scan, inquiry and inquiry scan,
during time critical LMP sequences in the current piconet and any other piconets in
which the Bluetooth device is a member, and during critical Baseband sequences (such
as the page response, initial Connection state until the first POLL, and role switch).
These PDUs may be sent at any time after connection setup is completed.

Central and Peripheral negotiate the number of repetitions for broadcast packets (NBC ),
see [Vol 2] Part B, Section 7.6.5.

M/O PDU Contents

M LMP_QUALITY_OF_SERVICE Poll_Interval
NBC
M LMP_QUALITY_OF_SERVICE_REQ Poll_Interval
NBC

Table 4.9: Quality of service PDU

4.1.8.1 Central notifies Peripheral of the quality of service

The Central notifies the Peripheral of the new poll interval and NBC by sending the
LMP_QUALITY_OF_SERVICE PDU. The Peripheral cannot reject the notification.

Central Peripheral
LM LM
LMP_QUALITY_OF_SERVICE

Sequence 13: Central notifies Peripheral of quality of service

4.1.8.2 Device requests new quality of service

Either the Central or the Peripheral may request a new poll interval and NBC
by sending an LMP_QUALITY_OF_SERVICE_REQ PDU. The parameter NBC is
meaningful only when it is sent by a Central to a Peripheral. For transmission of
LMP_QUALITY_OF_SERVICE_REQ PDUs from a Peripheral, this parameter shall be
ignored by the Central. The request can be accepted or rejected. This allows the
Central and Peripheral to dynamically negotiate the quality of service as needed.

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 2, Part C Page 657
Link Manager Protocol Specification

The selected poll interval by the Peripheral shall be less than or equal to the specified
Access Latency for the outgoing traffic of the ACL link (see L2CAP Definition: Quality of
Service (QoS) option [Vol 3] Part A, Section 5.3).

Initiating
LM
LM
LMP_QUALITY_OF_SERVICE_REQ

LMP_ACCEPTED

Sequence 14: Device accepts new quality of service

Initiating
LM
LM
LMP_QUALITY_OF_SERVICE_REQ

LMP_NOT_ACCEPTED

Sequence 15: Device rejects new quality of service

4.1.9 Paging scheme parameters

LMP provides a means to negotiate the paging scheme parameters that are used the
next time a device is paged.

M/O PDU Contents

O(17) LMP_PAGE_MODE_REQ Paging_Scheme
Paging_Scheme_Settings
O(17) LMP_PAGE_SCAN_MODE_REQ Paging_Scheme
Paging_Scheme_Settings

Table 4.10: Paging scheme request PDU

4.1.9.1 Page mode

This procedure is initiated from device A and negotiates the paging scheme used
when device A pages device B. Device A proposes a paging scheme including the
parameters for this scheme and device B can accept or reject. On rejection the old
setting shall not be changed. A request to switch to a reserved paging scheme shall be
rejected.

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 2, Part C Page 658
Link Manager Protocol Specification

A LM B LM

LMP_PAGE_MODE_REQ

LMP_ACCEPTED or LMP_NOT_ACCEPTED

Sequence 16: Negotiation for Page mode

4.1.9.2 Page Scan mode

This procedure is initiated from device A and negotiates the paging scheme and paging
scheme settings used when device B pages device A. Device A proposes a paging
scheme and paging scheme settings and device B may accept or reject. On reject
the old setting is not changed. A request specifying the mandatory scheme shall be
accepted. A request to switch to a reserved scheme shall be rejected. This procedure
should be used when device A changes its paging scheme settings. A Peripheral should
also send this message to the Central after connection establishment, to inform the
Central of the Peripheral's current paging scheme and paging scheme settings.

A LM B LM

LMP_PAGE_SCAN_MODE_REQ

LMP_ACCEPTED or LMP_NOT_ACCEPTED

Sequence 17: Negotiation for Page Scan mode

4.1.10 Control of multi-slot packets

The number of consecutive slots used by a device on an ACL-U logical link can be
limited. It does not affect traffic on the eSCO links where the packet sizes are defined
as part of link setup. A device allows the remote device to use a maximum number
of slots by sending the PDU LMP_MAX_SLOT providing a Max_Slots parameter.
Each device can request to use a maximal number of slots by sending the PDU
LMP_MAX_SLOT_REQ providing a Max_Slots parameter. After a new connection (as
a result of page or page scan), or after a role switch, the value shall be 1 slot. These
PDUs can be sent at any time after connection setup is completed.

M/O PDU Contents

M LMP_MAX_SLOT Max_Slots
M LMP_MAX_SLOT_REQ Max_Slots

Table 4.11: Multi-slot packet control PDU

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 2, Part C Page 659
Link Manager Protocol Specification

Initiating
LM
LM
LMP_MAX_SLOT

Sequence 18: Device allows Remote Device to use a maximum number of slots

Initiating
LM
LM
LMP_MAX_SLOT_REQ

LMP_ACCEPTED

Sequence 19: Device requests a maximum number of slots. Remote Device accepts.

Initiating
LM
LM
LMP_MAX_SLOT_REQ

LMP_NOT_ACCEPTED

Sequence 20: Device requests a maximum number of slots. Remote Device rejects

4.1.11 Enhanced Data Rate

A device may change the packet type table, ptt, to select which if any of the packets and
optional modulation modes are to be used on an ACL logical transport.

Either the Central or the Peripheral may request a new packet type table and therefore
the packets and modulation mode to be used on this ACL link. After a new Baseband
connection, as a result of page or page scan, the default value for ptt shall be 0.

The change of the modulation mode for an ACL logical transport shall not affect the
packet and packet types used for an associated SCO logical transport on the same
LT_ADDR.

Note: Enhanced Data Rate eSCO links are negotiated using the LMP eSCO link_req as
described in Section 4.6.2.

Before changing the packet type table, the initiator shall finalize the transmission of the
current ACL packet with ACL-U information and shall stop ACL-U transmissions. It shall
then send the LMP_PACKET_TYPE_TABLE_REQ PDU.

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 2, Part C Page 660
Link Manager Protocol Specification

If the receiver rejects the change, then it shall respond with an

LMP_NOT_ACCEPTED_EXT PDU.

If the receiver accepts the change, then it shall finalize the transmission of the current
ACL packet with ACL-U information and shall stop ACL-U transmissions, it shall change
to the new packet type table and shall respond with an LMP_ACCEPTED_EXT PDU.
When it receives the Baseband acknowledgment for the LMP_ACCEPTED_EXT PDU it
shall restart ACL-U transmissions.

When the initiator receives an LMP_NOT_ACCEPTED_EXT PDU the initiator shall

restart ACL-U transmissions.

When the initiator receives an LMP_ACCEPTED_EXT PDU it shall change the packet
type table and restart ACL-U transmissions.

M/O PDU Contents

O(25) LMP_PACKET_TYPE_TABLE_REQ Packet_Type_Table

Table 4.12: Enhanced Data Rate PDUs

LM-A LM-B

LMP_PACKET_TYPE_TABLE_REQ

LMP_NOT_ACCEPTED_EXT

Sequence 21: Packet type table change is rejected

LM-A LM-B

LMP_PACKET_TYPE_TABLE_REQ

LMP_ACCEPTED_EXT

Sequence 22: Packet type table change is accepted

4.1.12 Encapsulated LMP PDUs

Some transactions require sending LMP payload data that is longer than 16 octets. To
enable a link manager to send a large PDU, an encapsulated LMP PDU is defined. An
encapsulated LMP PDU is composed of a minimum of two LMP messages, a header
PDU and one or more payload PDUs.

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 2, Part C Page 661
Link Manager Protocol Specification

M/O PDU Contents

O(52) LMP_ENCAPSULATED_HEADER Encap_Major_Type
Encap_Minor_Type
Encap_Payload_Length
O(52) LMP_ENCAPSULATED_PAYLOAD Encap_Data

Table 4.13: Encapsulated LMP PDUs

4.1.12.1 Sending an encapsulated PDU

The LMP_ENCAPSULATED_HEADER PDU shall be sent by the initiating device when

it needs to send an encapsulated PDU. This PDU shall be either accepted or rejected
using the LMP_ACCEPTED or LMP_NOT_ACCEPTED PDUs. If the major and minor
types are not supported the PDU shall be rejected with Error_Code Unsupported LMP
Parameter Value (0x20). If the LMP_ENCAPSULATED_HEADER PDU is accepted,
then one or more LMP_ENCAPSULATED_PAYLOAD PDUs will be sent with the
encapsulated data sent in sequence, 16 octets at a time, or if this is last packet, the
correct number of octets and then zero padded.

Each LMP_ENCAPSULATED_PAYLOAD PDU shall be accepted or rejected.

If the LMP_ENCAPSULATED_HEADER PDU is rejected, then the
opcode in the LMP_NOT_ACCEPTED PDU shall be the opcode for
the LMP_ENCAPSULATED_HEADER and not the Encap_Major_Type or
Encap_Minor_Type. If the LMP_ENCAPSULATED_PAYLOAD PDU is rejected, then
the opcode in the LMP_NOT_ACCEPTED PDU shall be the opcode for the
LMP_ENCAPSULATED_PAYLOAD.

A responding device may reject the final LMP_ENCAPSULATED_PAYLOAD PDU after

accepting the LMP_ENCAPSULATED_HEADER PDU. This is so that the link manager
can still reject an encapsulated message after all the data has been received.

Initiating
LM
LM
LMP_ENCAPSULATED_HEADER

LMP_ACCEPTED or LMP_NOT_ACCEPTED

LMP_ENCAPSULATED_PAYLOAD

LMP_ACCEPTED or LMP_NOT_ACCEPTED

LMP_ENCAPSULATED_PAYLOAD

LMP_ACCEPTED or LMP_NOT_ACCEPTED

Sequence 23: Sending an encapsulated PDU

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 2, Part C Page 662
Link Manager Protocol Specification

Between sending an LMP_ENCAPSULATED_HEADER PDU and an

LMP_ENCAPSULATED_PAYLOAD PDU, or between each of the
LMP_ENCAPSULATED_PAYLOAD PDUs, either device shall be able to send the
following LMP PDUs without causing a "different transaction collision" error.

• LMP_CHANNEL_CLASSIFICATION
• LMP_DECR_POWER_REQ
• LMP_DETACH
• LMP_INCR_POWER_REQ
• LMP_MAX_POWER
• LMP_MAX_SLOT
• LMP_MIN_POWER
• LMP_PREFERRED_RATE
• LMP_SET_AFH

4.1.13 Ping

When both devices support the Ping feature, a Link Manager may verify the presence of
the remote Link Manager by using the LMP ping mechanism. The LMP ping mechanism
may also be used to verify message integrity on the ACL logical transport by forcing the
remote device to send an ACL packet that contains a MIC.

Note: Since the LMP_PING_RES PDU contains a MIC and will update the packet
counter, the sender of the LMP_PING_REQ PDU can verify that packets with earlier
packet counter values have not been deliberately suppressed by an attacker.

M/O PDU Contents

O(137) LMP_PING_REQ none
O(137) LMP_PING_RES none

Table 4.14: Ping PDUs

The initiating link manager sends the LMP_PING_REQ PDU. The responding link
manager responds with the LMP_PING_RES PDU. The initiating link manager may
be a Central or Peripheral.

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 2, Part C Page 663
Link Manager Protocol Specification

Initiating
LM
LM
LMP_PING_REQ

LMP_PING_RES

Sequence 24: Ping PDUs

The Link Manager shall send an LMP_PING_REQ PDU when the remote device has
not sent a packet containing a payload protected by a MIC within an authenticated
payload timeout set by the Host (see [Vol 4] Part E, Section 7.3.94). The Link Manager
should send an LMP_PING_REQ PDU in advance enough of the expiration of the
authenticated payload timeout to allow the remote device reasonable time to respond
with an LMP_PING_RES PDU before the timeout expires.

4.1.14 Piconet clock adjustment

The Central may adjust the piconet clock (e.g. to align with an external time base) by
initiating the Coarse Clock Adjustment or Clock Dragging procedures. A Peripheral may
request that the Central adjust the piconet clock.

M/O PDU Contents

O(134) LMP_CLK_ADJ Clk_Adj_ID
Clk_Adj_Instant
Clk_Adj_Offset
Clk_Adj_Slots
Clk_Adj_Mode
Clk_Adj_Clk
O(134) LMP_CLK_ADJ_ACK Clk_Adj_ID
O(134) LMP_CLK_ADJ_REQ Clk_Adj_Offset
Clk_Adj_Slots
Clk_Adj_Period

Table 4.15: Piconet clock adjustment PDUs

Piconet clock adjustment requests may be made at any time after the Link Manager
supported features responses have been processed.

The Central is free to reject any request for an adjustment; an implementation may, for
instance, accept coarse clock adjustment requests from one Peripheral but reject all
requests from any other Peripheral.

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 2, Part C Page 664
Link Manager Protocol Specification

4.1.14.1 Central coarse adjustment of piconet clock

The coarse clock adjustment procedure shall only be used if all connected Peripherals
declare support for the Coarse Clock Adjustment feature.

For all devices that may use Coarse Clock Adjustment Recovery Mode (see [Vol 2] Part
B, Section 8.6.10.2), the RF channel indices used for the Synchronization Train (see
[Vol 2] Part B, Section 2.6.4.8) shall be marked as unused in the AFH_Channel_Map for
all logical links.

The Central may use the Clk_Adj_Period parameter from one or more Peripherals, in
addition to other scheduling considerations, to select an optimal value of Clk_Adj_Slots.

The Central selects the parameters of the coarse clock adjustment. Some parameters
shall remain the same for every LMP_CLK_ADJ PDU associated with a given
adjustment. These are the number of slots (Clk_Adj_Slots) between 0 and 255, an
offset within a slot (Clk_Adj_Offset) between –624 µs and 624 µs, a coarse clock
adjustment instant (Clk_Adj_Instant), which is specified in the old time domain before
the instant, and an identifier for the instant (Clk_Adj_ID). The Clk_Adj_Instant shall
be at least 12 slots in the future and no more than 12 hours away. The Clk_Adj_ID
shall be different for any two adjacent adjustments and for any two adjustments whose
instants are closer together in time than the longest Link Supervision Timeout period
for any Peripheral. Each LMP_CLK_ADJ PDU also contains the value of CLK when
it is transmitted (Clk_Adj_Clk) and a flag Clk_Adj_Mode, which shall be set to Before
Instant if the LMP_CLK_ADJ PDU is sent before the instant or to After Instant if the
LMP_CLK_ADJ PDU is sent on or after the instant.

To initiate the coarse adjustment, the Central starts broadcasting the LMP_CLK_ADJ
PDU using the APB-C logical link and, unless all Peripherals have acknowledged,
it should broadcast the LMP_CLK_ADJ PDU at least 6 times before the adjustment
instant. The Central shall continue to broadcast the LMP_CLK_ADJ PDU until all
Peripherals have acknowledged the adjustment with an LMP_CLK_ADJ_ACK PDU or
the Central has left Coarse Clock Adjustment Recovery Mode.

The Central shall not initiate a coarse clock adjustment if there are any transactions
outstanding that involve LMP PDUs containing an instant or timing control flags
including, but not limited to: role switch, adaptive frequency hopping, SCO, eSCO, sniff,
sniff subrating, hold, and encryption pause and resume.

The Central shall not initiate another sequence containing an instant or timing control
flags before an outstanding clock adjustment instant has been reached, while waiting for
CLK_adj_dragTO to expire (see [Vol 2] Part B, Appendix B), or while in Coarse Clock
Adjustment Recovery Mode (see [Vol 2] Part B, Section 8.6.10.2); however the latter
may be terminated by the Central in order to initiate the request. If a request to initiate
such a sequence is received before an outstanding clock adjustment instant is reached

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 2, Part C Page 665
Link Manager Protocol Specification

or CLK_adj_dragTO has been cancelled or has expired, the request shall be rejected
with the Error_Code Different Transaction Collision (0x2A).

A Peripheral shall discard and not acknowledge an LMP_CLK_ADJ PDU with a value of
Clk_Adj_ID that is the same as that in the most recently received LMP_CLK_ADJ PDU,
if any, and any LMP_CLK_ADJ PDU with any parameters outside the valid range (see
Section 5.2).

On receipt of an LMP_CLK_ADJ PDU that passes these checks, the Peripheral shall
reply with an LMP_CLK_ADJ_ACK PDU (on the ACL-C logical link) containing the
same value of Clk_Adj_ID as in the LMP_CLK_ADJ PDU and shall change the value
of peripheral_clock_offset, if not already performed, as described in [Vol 2] Part B,
Section 8.6.10.1, either at the adjustment instant or, if that has passed, immediately.

Central Peripheral Peripheral

LM LM LM

LMP_CLK_ADJ
(broadcast)

LMP_CLK_ADJ_ACK

LMP_CLK_ADJ_ACK

Sequence 25: Central initiates a coarse clock adjustment

4.1.14.2 Peripheral request for coarse adjustment of piconet clock

The Peripheral may request a coarse adjustment of the piconet clock by sending the
LMP_CLK_ADJ_REQ PDU to the Central. The LMP_CLK_ADJ_REQ PDU contains
three parameters: Clk_Adj_Offset, Clk_Adj_Slots, and Clk_Adj_Period. The parameters
Clk_Adj_Offset and Clk_Adj_Slots have the same meaning as in the LMP_CLK_ADJ
PDU and Clk_Adj_Slots or Clk_Adj_Offset shall be non-zero. If non-zero, the parameter
Clk_Adj_Period is an indication to the Central that the request is for any of a set
of possible adjustments, all of which are equally acceptable to the Peripheral. These
adjustments are those where the number of slots is equal to Clk_Adj_Slots + N ×
Clk_Adj_Period, where N is zero or a positive integer, and the offset within a slot
equals Clk_Adj_Offset. For example, if Clk_Adj_Slots is 18 and Clk_Adj_Period is
48, then the acceptable adjustments are 18, 66, 114, 162, and 210 slots. A value of
zero for Clk_Adj_Period indicates that an adjustment of any number of slots is equally
acceptable to the Peripheral (that is, the Central may ignore the value of Clk_Adj_Slots).

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 2, Part C Page 666
Link Manager Protocol Specification

A request for a coarse adjustment shall also update the Central’s local record of
Clk_Adj_Period for the Peripheral.

The Peripheral may indicate its preferred Clk_Adj_Period to the Central without
requesting a clock adjustment. In this case it shall set Clk_Adj_Slots and Clk_Adj_Offset
to zero. Upon receiving an LMP_CLK_ADJ_REQ PDU with Clk_Adj_Slots and
Clk_Adj_Offset set to zero, the Central shall respond with an LMP_ACCEPTED_EXT
PDU and update its local record of Clk_Adj_Period for the Peripheral, but shall not
initialize any clock adjustment. The Central is not required to honor a Peripheral’s
preferred Clk_Adj_Period when making coarse clock adjustments.

The Central may accept the coarse clock adjustment request from the Peripheral
by sending an LMP_ACCEPTED_EXT PDU. This indicates that the Central intends
to carry out a coarse clock adjustment with the requested value of Clk_Adj_Offset;
however, the value of Clk_Adj_Slots may be different to that requested and might not
follow the Clk_Adj_Period parameter.

Central Peripheral
LM LM
LMP_CLK_ADJ_REQ

LMP_ACCEPTED_EXT

Sequence 26: Central accepts Peripheral request for a coarse clock adjustment

The Central may reject the coarse clock adjustment request from the Peripheral
by sending an LMP_NOT_ACCEPTED_EXT PDU with the Error_Code Command
Disallowed (0x0C) (see [Vol 1] Part F, Section 2.12). The Central's decision not to follow
the Clk_Adj_Slots or Clk_Adj_Period parameters does not constitute a rejection.

The Central may implement the coarse clock adjustment request from the Peripheral
by carrying out clock dragging (see [Vol 2] Part B, Section 8.6.10.3) to achieve the
requested clock adjustment. If so, it shall send an LMP_NOT_ACCEPTED_EXT PDU
with the Error_Code Coarse Clock Adjustment Rejected but Will Try to Adjust Using
Clock Dragging (0x40) (see [Vol 1] Part F, Section 2.61).

Central Peripheral
LM LM
LMP_CLK_ADJ_REQ

LMP_NOT_ACCEPTED_EXT

Sequence 27: Central rejects a Peripheral request for coarse clock adjustment

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 2, Part C Page 667
Link Manager Protocol Specification

4.1.15 Slot Availability Mask

SAM LMP sequences may be initiated at any time after Link Manager supported
features responses have been processed.

Either the Central or the Peripheral may initiate the LMP_SAM_SET_TYPE0 PDU to
configure the SAM type 0 submap of the local device. The initiation may be triggered by
the HCI command HCI_Set_External_Frame_Configuration for MWS coexistence.

Either the Central or the Peripheral may initiate the LMP_SAM_DEFINE_MAP PDU to
define a new or modify an existing local SAM slot map. The initiation may be triggered
by the HCI command HCI_Set_MWS_PATTERN_Configuration for MWS coexistence. If
a type 0 submap is used with the LMP_SAM_DEFINE_MAP PDU, the Controller shall
first execute the SAM set type 0 LMP sequence to configure the SAM type 0 submap,
then the SAM define map LMP sequence itself.

Either the Central or the Peripheral may initiate the LMP_SAM_SWITCH PDU to switch
to a local SAM slot map that has been defined by previous SAM set type 0 and
SAM define map LMP sequences. This may be triggered by the real-time signals (e.g.
MWS_PATTERN_Index, FRAME_SYNC, etc.) from the Coexistence Logical Interface
(see [Vol 7] Part A), which contain information for the SAM_Index to be activated
and the SAM anchor point for MWS coexistence. Piconet Clock Adjustment may be
performed to create more available slot pairs per MWS frame before initiating the SAM
switch LMP sequence.

These SAM LMP sequences will be described in detail in the following subsections.

M/O PDU Contents

O(138) LMP_SAM_SET_TYPE0 Update_Mode
SAM_Type0_Submap
O(138) LMP_SAM_DEFINE_MAP SAM_Index
TSAM_SM
NSAM_SM
SAM_Submaps
O(138) LMP_SAM_SWITCH SAM_Index
Timing_Control_Flags
DSAM
SAM_Instant

Table 4.16: PDUs used for SAM negotiation

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 2, Part C Page 668
Link Manager Protocol Specification

The LMP_SAM_SET_TYPE0 PDU contains the following SAM parameters from the
sender:

1. Update_Mode: When Update_Mode is set to 0, the existing slot maps containing

the type 0 submap are invalidated and the corresponding SAM_Index shall not be
used until the map with that index has been redefined in a subsequent SAM define
map LMP sequence. When Update_Mode is set to 1, the new type 0 submap shall
take effect immediately. When Update_Mode is set to 2, the new type 0 submap
shall take effect at the start of the next sub-interval.
2. SAM_Type0_Submap: This parameter specifies the types of each slot in the type 0
submap. The length of this parameter corresponds to 56 slots but, when it is used
in a map, only the first TSAM_SM entries are significant.
Different maps can have different values of TSAM_SM.

The LMP_SAM_DEFINE_MAP PDU contains the following parameters from the sender:

1. SAM_Index: Index of the SAM slot map this PDU applies to. If the same
SAM_Index has been previously defined, then the previous map parameters
associated with the map shall be discarded and replaced by the parameters
contained in this PDU.
2. TSAM_SM: Length of each SAM submap in slots. It shall be an even integer in the
range 2 to 56.
3. NSAM_SM: The number of SAM submaps in the SAM slot map.
4. SAM_Submaps: This parameter specifies the types of the SAM submaps, using 2
bits for each submap. The length of this parameter corresponds to 48 submaps, but
only the first NSAM_SM entries are significant.

The LMP_SAM_SWITCH PDU contains the following parameters from the sender:

1. SAM_Index: Index of the SAM slot map. It shall either be the index of a valid map,
in which case SAM should be enabled and that map selected, or shall be 0xFF,
which indicates that SAM should be disabled (meaning that, for SAM purposes, all
slots are available for both transmission and reception). Disabling SAM does not
invalidate a SAM slot map or the type 0 submap.
2. Timing_Control_Flags: This parameter is used to avoid clock wrap-around during
the sequence, using one of the two initialization rules.
3. DSAM: SAM offset that is used to compute the SAM anchor point. Only even values
are valid.
4. SAM_Instant: Bits 27:1 of the Central's clock value when the SAM slot map is
to be activated. This is used to indicate the first anchor point of the slot map.
The new SAM slot map may be activated at SAM_Instant even if the Baseband
acknowledgment is not received.

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 2, Part C Page 669
Link Manager Protocol Specification

4.1.15.1 SAM type 0 submap configuration

Either the Central or the Peripheral may initiate the SAM type 0 submap configuration
sequence by sending an LMP_SAM_SET_TYPE0 PDU to the responder. Both devices
shall save the SAM parameters contained in this PDU. Update_Mode shall not be set
to 0 if the active SAM slot map contains a type 0 submap. If the responder can accept
the parameters, it shall send an LMP_ACCEPTED_EXT PDU. If the Update_Mode
parameter is set to 0 and the active SAM slot map contains a type 0 submap, it
shall send an LMP_NOT_ACCEPTED_EXT PDU with the Error_Code Invalid LMP
Parameters (0x1E).

Initiating
LM
LM
LMP_SAM_SET_TYPE0

LMP_ACCEPTED_EXT or LMP_NOT_ACCEPTED_EXT

Sequence 28: SAM type 0 submap configuration sequence

4.1.15.2 SAM slot map define

Either the Central or the Peripheral may initiate the SAM slot map define sequence
by sending an LMP_SAM_DEFINE_MAP PDU. If NSAM_SM is set to zero, the map
shall be deleted. The SAM_Index parameter shall not be 0xFF or that of the
currently selected map. The slot map may only contain a type 0 submap if the
LMP_SAM_SET_TYPE0 sequence has already been used to define the type 0 submap.
If the responder can accept the parameters, it shall send an LMP_ACCEPTED_EXT
PDU. If a SAM type 0 submap is used in an LMP_SAM_DEFINE_MAP PDU without
successfully completing the LMP_SAM_SET_TYPE0 sequence in advance, it shall
send an LMP_NOT_ACCEPTED_EXT PDU with the Error_Code Type0 Submap Not
Defined (0x41).

Initiating Responding
LM LM
LMP_SAM_DEFINE_MAP

LMP_ACCEPTED_EXT or LMP_NOT_ACCEPTED_EXT

Sequence 29: SAM slot map define sequence

4.1.15.3 SAM switch sequence

Either the Central or the Peripheral may initiate the SAM switch sequence by
sending an LMP_SAM_SWITCH PDU to the responder. There are two initialization

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 2, Part C Page 670
Link Manager Protocol Specification

procedures to prevent problems caused by clock wrap-around; see [Vol 2] Part B,

Section 8.6.11.1 for details. The SAM_Index shall refer to a SAM slot map that is
currently valid (the special value 0xFF is always valid). If the responder can accept
the parameters, it shall send an LMP_ACCEPTED_EXT PDU. If the SAM_Index is
invalid (e.g., the associated SAM_Index configuration has not yet been defined with
LMP_SAM_DEFINE_MAP_SEQUENCE), it shall send an LMP_NOT_ACCEPTED_EXT
PDU with the Error_Code Invalid LMP Parameters (0x1E).

Each Controller shall notify its Host of a successful SAM switch sequence specifying a
different SAM_Index to that currently selected (it may, but need not, notify the Host if the
sequence specifies the current map). The currently selected map remains in effect if the
change is not accepted.

Initiating Responding
LM LM
LMP_SAM_SWITCH

LMP_ACCEPTED_EXT or LMP_NOT_ACCEPTED_EXT

Sequence 30: SAM switch sequence

4.1.15.4 SAM change during the transmission of a multi-slot packet

SAM slot map changes do not affect the transmission of a multi-slot packet that spans
the change instant. In the case of a Central-to-Peripheral packet, the new map can
mean that the Peripheral may choose not to reply to the packet.

4.1.15.5 SAM and role switching

The Central and Peripheral shall disable SAM at the role switch instant. If the role
switch fails, both devices shall resume using the SAM parameters prior to the role
switch instant

SAM mode may be reconfigured and re-enabled after the successful completion of a
role switch using the new piconet clock.

4.1.15.6 SAM and Sniff mode

If sniff negotiation is requested when SAM is already enabled, the device should
align sniff with SAM by choosing the sniff anchor point to be an available Central-to-
Peripheral slot and the sniff period to be an integer multiple of TSAM. If such alignment is
not possible, the sniff configuration shall take precedence, even if this requires a device
to transmit or receive on a slot marked as unavailable by SAM. The SAM slot maps
shall be reinstated when devices exit Sniff mode.

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 2, Part C Page 671
Link Manager Protocol Specification

Note: Even though Sniff mode overrides the SAM slot maps, a device still might not be
able to transmit or receive because of scatternet commitments, a coexistence clash, or
some other reason.

4.2 Security
Each random number mentioned in this section shall be created according to [Vol 2]
Part H, Section 2.

4.2.1 Authentication

Two authentication procedures are defined: legacy and secure authentication. Legacy
authentication shall be performed when at least one device does not support both
the Secure Connections (Controller Support) and Secure Connections (Host Support)
features and the local device allows legacy authentication to be used. Secure
authentication shall be performed when both devices support the Secure Connections
(Controller Support) and Secure Connections (Host Support) features.

The legacy authentication procedure is based on a challenge-response scheme as

described in [Vol 2] Part H, Section 3.2.2. The verifier sends an LMP_AU_RAND PDU
that contains a random number (the challenge) to the claimant. The claimant calculates
a response, that is a function of this challenge, the claimant’s BD_ADDR and a secret
key. The response is sent back to the verifier, which checks if the response was correct
or not. The response shall be calculated as described in [Vol 2] Part H, Section 6.1. A
successful calculation of the authentication response requires that two devices share a
secret key. This key is created as described in Section 4.2.2. Both the Central and the
Peripheral can be verifiers. The sequences for legacy authentication are described in
Section 4.2.1.1 and Section 4.2.1.2.

The secure authentication procedure is a challenge-response scheme as described in

[Vol 2] Part H, Section 5. The verifier sends an LMP_AU_RAND PDU that contains a
random number (the challenge) to the claimant. The claimant responds with another
LMP_AU_RAND PDU also containing a random number. Both Link Managers calculate
the Device Authentication Key using the h4 function (see [Vol 2] Part H, Section 7.7.7)
and then calculate the SRES_C, SRES_P and ACO values using the h5 function (see
[Vol 2] Part H, Section 7.7.8). The Peripheral (regardless of whether it was the verifier or
claimant) sends its response (SRES_P) to the Central. The Central sends its response
(SRES_C) to the Peripheral. A successful calculation of the authentication response
requires that two devices share a secret key. The sequences for secure authentication
are described in Section 4.2.1.2 and Section 4.2.1.4.

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 2, Part C Page 672
Link Manager Protocol Specification

M/O PDU Contents

M LMP_AU_RAND Random_Number
M LMP_SRES Authentication_Rsp

Table 4.17: Authentication PDUs

4.2.1.1 Claimant has link key (legacy authentication)

If the claimant has a link key associated with the verifier, it shall calculate the
response and sends it to the verifier with LMP_SRES. The verifier checks the
response. If the response is not correct, the verifier may end the connection by
sending an LMP_DETACH PDU with the Error_Code Authentication Failure (0x05), see
Section 4.1.2.

Verifier Claimant
LM LM
LMP_AU_RAND

LMP_SRES

Sequence 31: Authentication. Claimant has link key.

Upon reception of an LMP_AU_RAND, an LM shall reply with LMP_SRES before

initiating its own authentication.

Note: There can be conflicting actions from the Central and the Peripheral which could
lead to the two devices having different Authenticated Ciphering Offsets (ACOs, see
[Vol 2] Part H, Section 6.1) when they calculate the encryption key. The following
procedures assure that this cannot occur:

• procedure in Section 2.5.1 (Transaction Collision Resolution) when the Central and
Peripheral simultaneously initiate an authentication.
• procedure in Section 4.2.5.1 when encryption parameters are being negotiated.

4.2.1.2 Claimant has no link key (legacy authentication and secure authentication)

If the claimant does not have a link key associated with the verifier it shall send an
LMP_NOT_ACCEPTED PDU with the Error_Code PIN or Key Missing (0x06) after
receiving an LMP_AU_RAND PDU ([Vol 1] Part F, Section 2.6).

Note: This sequence is identical for legacy authentication and secure authentication.

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 2, Part C Page 673
Link Manager Protocol Specification

Verifier Claimant
LM LM
LMP_AU_RAND

LMP_NOT_ACCEPTED

Sequence 32: Authentication fails. Claimant has no link key.

4.2.1.3 Repeated attempts

The scheme described in [Vol 2] Part H, Section 5.1 shall be applied when an
authentication fails.

4.2.1.4 Responder has link key (secure authentication)

Both the Central and Peripheral LM act as verifier and claimant. The initiator is the
device that sends the LMP_AU_RAND PDU first.

The initiator sends an LMP_AU_RAND PDU to the responder. If the responder has a
link key associated with the initiator, it shall respond with an LMP_AU_RAND PDU.
The initiator and responder shall calculate the response. The Peripheral responds first
with an LMP_SRES PDU containing SRES_P. The Central shall then respond with an
LMP_SRES PDU containing SRES_C. The Central shall verify that the SRES_P sent
by the Peripheral matches the SRES_P calculated by the Central. The Peripheral shall
verify that the SRES_C sent by the Central matches the SRES_C calculated by the
Peripheral. If the response is not correct, then the device receiving the wrong SRES
value may end the connection by sending an LMP_DETACH PDU with the Error_Code
Authentication Failure (0x05) (see Section 4.1.2).

Initiating LM Responding
(Central) LM
LMP_AU_RAND

LMP_AU_RAND

LMP_SRES

LMP_SRES

Sequence 33: Secure authentication. Responder has link key. Initiator is Central.

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 2, Part C Page 674
Link Manager Protocol Specification

Initiating LM Responding
(Peripheral) LM
LMP_AU_RAND

LMP_AU_RAND

LMP_SRES

LMP_SRES

Sequence 34: Secure authentication. Responder has link key. Initiator is Peripheral.

In the case where the Central and Peripheral both initiate the secure authentication
sequence, the Central shall reject the Peripheral’s LMP_AU_RAND PDU with an
LMP_NOT_ACCEPTED PDU with the Error_Code LMP Error Transaction Collision /
LL Procedure Collision (0x23). The Peripheral shall send another LMP_AU_RAND PDU
with transaction ID set to 0 (Central).

Note: Secure Authentication is a mutual authentication.

4.2.2 Pairing

When two devices do not have a common link key an initialization key (Kinit) shall be
created using either the pairing or Secure Simple Pairing procedures. When pairing is
used, Kinit shall be created based on a PIN, and a random number and a BD_ADDR.
Kinit shall be created as specified in [Vol 2] Part H, Section 6.3. When both devices have
calculated Kinit the link key shall be created, and a mutual authentication is performed.
The pairing procedure starts with a device sending an LMP_IN_RAND PDU; this device
is referred to as the "initiating LM" or "initiator" in Section 4.2.2.1 - Section 4.2.2.5. The
other device is referred to as the "responding LM" or "responder". The PDUs used in the
pairing procedure are:

M/O PDU Contents

M LMP_IN_RAND Random_Number
M LMP_AU_RAND Random_Number
M LMP_SRES Authentication_Rsp
M LMP_COMB_KEY Random_Number
M LMP_UNIT_KEY Key

Table 4.18: Pairing PDUs

The Link Manager shall not send an LMP_UNIT_KEY PDU.

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 2, Part C Page 675
Link Manager Protocol Specification

All sequences described in Section 4.2.2, including the mutual authentication after the
link key has been created, shall form a single transaction. The transaction ID from the
first LMP_IN_RAND shall be used for all subsequent sequences.

4.2.2.1 Responder accepts pairing and has a variable PIN

If the responder accepts the pairing and has a variable PIN, then it shall reply with an
LMP_ACCEPTED PDU. Both devices shall then calculate Kinit based on the BD_ADDR
of the responder and the procedure continues with creation of the link key; see
Section 4.2.2.4.

Initiating Responding
LM LM
LMP_IN_RAND

LMP_ACCEPTED

Sequence 35: Pairing accepted. Responder has a variable PIN. Initiator has a variable or fixed PIN.

4.2.2.2 Responder accepts pairing and has a fixed PIN

If the responder accepts the pairing and has a fixed PIN, then it shall generate a new
random number and send it back in an LMP_IN_RAND PDU. If the initiator has a
variable PIN, then it shall accept the LMP_IN_RAND PDU and shall respond with an
LMP_ACCEPTED PDU. Both sides shall then calculate Kinit based on the last IN_RAND
and the BD_ADDR of the initiator. The procedure continues with creation of the link key;
see Section 4.2.2.4.

Initiating Responding
LM LM
LMP_IN_RAND

LMP_IN_RAND

LMP_ACCEPTED

Sequence 36: Responder has a fixed PIN and initiator has a variable PIN

If the responder has a fixed PIN and the initiator also has a fixed PIN, then the second
LMP_IN_RAND shall be rejected by the initiator sending an LMP_NOT_ACCEPTED
PDU with the Error_Code Pairing not Allowed (0x18).

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 2, Part C Page 676
Link Manager Protocol Specification

Initiating Responding
LM LM
LMP_IN_RAND

LMP_IN_RAND

LMP_NOT_ACCEPTED

Sequence 37: Both devices have a fixed PIN

4.2.2.3 Responder rejects pairing

If the responder rejects pairing (e.g., because the user has disabled pairing on the
device) it shall send an LMP_NOT_ACCEPTED PDU with the Error_Code Pairing not
Allowed (0x18) after receiving an LMP_IN_RAND PDU.

Initiating Responding
LM LM
LMP_IN_RAND

LMP_NOT_ACCEPTED

Sequence 38: Responder rejects pairing

4.2.2.4 Creation of the link key

When Kinit is calculated in both devices the link key shall be created. This link key will be
used in the authentication between the two devices for all subsequent connections until
it is changed; see Section 4.2.3 and Section 4.2.4. The link key created in the pairing
procedure will be a combination key; both devices send an LMP_COMB_KEY PDU and
the link key shall be calculated as described in [Vol 2] Part H, Section 3.2.

The content of the LMP_COMB_KEY PDU is LK_RAND bitwise XORed with Kinit. Any
device configured to use a combination key shall store the link key.

When the new link key has been created mutual authentication shall be performed
to confirm that the same link key has been created in both devices. After mutual
authentication, if encryption is enabled, the initiating device shall pause and immediately
resume encryption to produce a new encryption key.

Note: This will cause a new encryption key to be generated from the ACO created
during the mutual authentication process and, when E0 encryption is used, the random
number sent in the LMP_START_ENCRYPTION_REQ PDU which occurs in response
to the resumption of encryption.

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 2, Part C Page 677
Link Manager Protocol Specification

Initiating Responding
LM LM
LMP_COMB_KEY

LMP_COMB_KEY

Sequence 39: Creation of the link key

If, in sequence 39, either device sends an LMP_UNIT_KEY PDU, the other device shall
respond with an LMP_NOT_ACCEPTED PDU with the Error_Code set to Pairing with
Unit Key Not Supported (0x29).

4.2.2.5 Repeated attempts

When the authentication after creation of the link key fails because of an incorrect
Authentication_Rsp, the scheme described in [Vol 2] Part H, Section 5.1 shall be
applied.

4.2.3 Change link key

The link key can be changed. The contents of the LMP_COMB_KEY PDU is protected
by a bitwise XOR with the current link key.

M/O PDU Contents

M LMP_COMB_KEY Random_Number

Table 4.19: Change link key PDU

Initiating
LM
LM
LMP_COMB_KEY

LMP_COMB_KEY

Sequence 40: Successful change of the link key

The new link key shall be stored and the old link key shall be discarded. The new link
key shall be used as link key for all the following connections between the two devices
until the link key is changed again. The new link key also becomes the current link key.
It will remain the current link key until the link key is changed again, or until a temporary
link key is created, see Section 4.2.4.

When the new link key has been created, mutual or secure authentication shall be
performed to confirm that the same link key has been created in both devices.

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 2, Part C Page 678
Link Manager Protocol Specification

If both devices support the Secure Connections (Controller Support) and Secure
Connections (Host Support) features, the device that initiated the change link key shall
initiate the Secure Authentication procedure. Otherwise, the first authentication in the
mutual authentication is performed with the device that initiated the change link key as
verifier. When finalized an authentication in the reverse direction is performed.

After mutual or secure authentication, if encryption is enabled, the initiating device shall
pause and immediately resume encryption to produce a new encryption key.

Note: This will cause a new encryption key to be generated from the ACO created
during the mutual authentication process, and when E0 encryption is used, the random
number sent in the LMP_START_ENCRYPTION_REQ PDU which occurs in response
to the resumption of encryption.

4.2.4 Change current link key type

The current link key can be a semi-permanent link key or a temporary link key. It may be
changed temporarily, but the change shall only be valid for the current connection, see
[Vol 2] Part H, Section 3.1. Changing to a temporary link key is necessary if the piconet
is to support encrypted broadcast. The current link key shall not be changed before the
connection establishment procedure has completed.

M/O PDU Contents

O(23) LMP_TEMP_RAND Random_Number
O(23) LMP_TEMP_KEY Key
O(23) LMP_USE_SEMI_PERMANENT_KEY none

Table 4.20: Change current link key PDU

4.2.4.1 Change to a temporary link key

The Central starts by creating the temporary link key K_temp as specified in [Vol 2] Part
H (EQ 4). Then the Central shall generate a random number, RAND, and shall send it
to the Peripheral in an LMP_TEMP_RAND PDU. Both sides then calculate an overlay
denoted OVL as OVL= E22 (current link key, RAND, 16). The Central shall then send
K_temp protected by XORing with OVL to the Peripheral in an LMP_TEMP_KEY PDU.
The Peripheral calculates K_temp, based on OVL, that becomes the current link key. It
shall be the current link key until the devices fall back to the semi-permanent link key,
see Section 4.2.4.2.

Note: The terminology in this section is the same as used in [Vol 2] Part H,
Section 3.2.8.

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 2, Part C Page 679
Link Manager Protocol Specification

Central Peripheral
LM LM
LMP_TEMP_RAND

LMP_TEMP_KEY

Sequence 41: Change to a temporary link key

All sequences described in Section 4.2.4.1, including the mutual authentication after
K_temp has been created, shall form a single transaction. The transaction ID shall be
set to 0.

When the devices have changed to the temporary key, a mutual authentication shall
be made to confirm that the same link key has been created in both devices. The
first authentication in the mutual authentication shall be performed with the Central as
verifier. When finalized an authentication in the reverse direction is performed.

Should the mutual authentication fail at either side, the LM of the verifier should start
the detach procedure. This will allow the procedure to succeed even though one of the
devices may be erroneous.

4.2.4.2 Semi-permanent link key becomes current link key

After the current link key has been changed to K_temp, this change can be undone
and the semi-permanent link key becomes the current link key again. If encryption
is used on the link, the procedure to go back to the semi-permanent link key shall
be immediately followed by the Central stopping encryption using the procedure
described in Section 4.2.5.4. Encryption may be restarted by the Central according
to the procedures in Section 4.2.5.3. This is to assure that encryption with encryption
parameters known by other devices in the piconet is not used when the semi-permanent
link key is the current link key.

Central Peripheral
LM LM
LMP_USE_SEMI_PERMANENT_KEY

LMP_ACCEPTED

Sequence 42: Link key changed to the semi-permanent link key

4.2.5 Encryption

If at least one authentication has been performed encryption may be used. Two
encryption mechanisms are defined: E0 encryption (legacy) and AES-CCM encryption.

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 2, Part C Page 680
Link Manager Protocol Specification

If both devices support the Secure Connections (Controller Support) and Secure
Connections (Host Support) features, then AES-CCM shall be used when encryption
is enabled. If at least one device does not support both the Secure Connections
(Controller Support) and Secure Connections (Host Support) features, then E0 shall
be used when encryption is enabled.

In order for the Central to use the same encryption parameters for all Peripherals in the
piconet where E0 encryption would be used it shall issue a temporary key, K_temp. The
Central shall make this key the current link key for all Peripherals in the piconet where
E0 encryption would be used before encryption is started, see Section 4.2.4. This is
required if broadcast packets are to be encrypted.

Note: Packets encrypted with broadcast encryption can not be received by Peripherals
that have AES-CCM encryption enabled. When the local Controller supports Secure
Connections and there are not any Peripherals in the piconet that do not support
Secure Connections, broadcast packets will not be encrypted and may be received by
Peripherals that support Secure Connections.

M/O PDU Contents

O (2) LMP_ENCRYPTION_MODE_REQ Encryption_Mode
O (2) LMP_ENCRYPTION_KEY_SIZE_REQ Key_Size
O (2) LMP_START_ENCRYPTION_REQ Random_Number
O (2) LMP_STOP_ENCRYPTION_REQ none
O (42) LMP_PAUSE_ENCRYPTION_REQ none
O (42) LMP_RESUME_ENCRYPTION_REQ none
O (136) LMP_PAUSE_ENCRYPTION_AES_REQ Random_Number

Table 4.21: Encryption handling PDU

All sequences described in Section 4.2.5 shall form a single transaction. The
transaction ID from the LMP_ENCRYPTION_MODE_REQ PDU shall be used for all
start encryption and stop encryption sequences.

Where the specification requires a device to resume encryption as part of one

procedure and then pause it as part of a following procedure, the device may omit
both the resume and the subsequent pause.

4.2.5.1 Encryption mode

The Central and the Peripheral must agree upon whether to use
encryption (Encryption_Mode=1 in LMP_ENCRYPTION_MODE_REQ) or not
(Encryption_Mode=0). If the semi-permanent key is used, encryption shall only apply
to point-to-point packets. If the temporary link key is used, encryption shall apply to
both point-to-point packets and broadcast packets. If Central and Peripheral agree on

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 2, Part C Page 681
Link Manager Protocol Specification

the encryption mode, the Central continues to give more detailed information about the
encryption.

If a device receives an LMP_ENCRYPTION_MODE_REQ with an Encryption_Mode

value of 2 then the device should treat it as if the Encryption_Mode value was 1.

If both devices support both the Secure Connections (Controller Support) and Secure
Connections (Host Support) features, setting the Encryption_Mode to 0 shall not
be allowed. If a device receives an LMP_ENCRYPTION_MODE_REQ PDU with
Encryption_Mode set to 0, it shall respond with an LMP_NOT_ACCEPTED PDU with
Error_Code Encryption Mode Not Allowed (0x25).

The initiating LM shall pause traffic on the ACL-U logical link (see
[Vol 2] Part B, Section 5.3.1). The initiating device shall then send the
LMP_ENCRYPTION_MODE_REQ PDU. If the responding device accepts the change
in encryption mode then it shall complete the transmission of the current packet on the
ACL logical transport and shall then suspend transmission on the ACL-U logical link.
The responding device shall then send the LMP_ACCEPTED PDU.

ACL-U logical link traffic shall only be resumed after the attempt to encrypt or decrypt
the logical transport is completed, i.e. at the end of Sequence 43 (on failure), 45, 46, or
47.

Initiating
LM
LM
LMP_ENCRYPTION_MODE_REQ

LMP_ACCEPTED or LMP_NOT_ACCEPTED

Sequence 43: Negotiation for encryption mode

After a device has sent an LMP_ENCRYPTION_MODE_REQ PDU it shall not send

an LMP_AU_RAND PDU before encryption is started. After a device has received an
LMP_ENCRYPTION_MODE_REQ PDU and sent an LMP_ACCEPTED PDU it shall not
send an LMP_AU_RAND PDU before encryption is started. If an LMP_AU_RAND PDU
is sent violating these rules, the claimant shall respond with an LMP_NOT_ACCEPTED
PDU with the Error_Code LMP PDU Not Allowed (0x24). This assures that devices
will not have different ACOs when they calculate the encryption key. If the encryption
mode is not accepted or the encryption key size negotiation results in disagreement the
devices may send an LMP_AU_RAND PDU again.

4.2.5.2 Encryption key size

Note: This section uses the same terms as in [Vol 2] Part H, Section 4.1.

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 2, Part C Page 682
Link Manager Protocol Specification

The Central sends an LMP_ENCRYPTION_KEY_SIZE_REQ PDU including the

suggested key size L_sug_c, that shall initially be equal to L_max_c. If L_min_p ≤
L_sug_c ≤ L_max_p, the Peripheral shall respond with an LMP_ACCEPTED PDU and
L_sug_c shall be used as the key size.

If L_sug_c > L_max_p, the Peripheral shall send back an

LMP_ENCRYPTION_KEY_SIZE_REQ PDU including the Peripheral’s suggested key
size L_sug_p set to L_max_p. If L_sug_c < L_min_p, the Peripheral shall send back an
LMP_NOT_ACCEPTED PDU with the Error_Code Unsupported LMP Parameter Value
(0x20) and the devices shall not communicate using encryption.

If the Peripheral sends back an LMP_ENCRYPTION_KEY_SIZE_REQ PDU, then

the Central performs the corresponding test on the Peripheral’s suggestion. This
procedure is repeated until a key size agreement is reached or it becomes
clear that no such agreement can be reached. If an agreement is reached
a device sends an LMP_ACCEPTED PDU and the key size in the last
LMP_ENCRYPTION_KEY_SIZE_REQ PDU shall be used.

If a key size is agreed, encryption is then started; see Section 4.2.5.3. If an agreement
is not reached a device sends an LMP_NOT_ACCEPTED PDU with the Error_Code
Unsupported LMP Parameter Value (0x20) and the devices shall not communicate
using encryption.

L_max_c and L_max_p shall be set to at least 7 octets. L_min_c and L_min_p should
be set to at least 7 octets. The values of L_max_c, L_min_c, L_max_p, and L_min_p
shall not change during an ACL connection between the Central and the Peripheral.

Note: If the Host of either the Central or the Peripheral uses services that require
security mode 4 (see [Vol 3] Part C, Section 5.2.2.8), a key size longer than the key size
negotiated by the two Link Managers can be enforced.

Central Peripheral
LM LM
LMP_ENCRYPTION_KEY_SIZE_REQ

LMP_ENCRYPTION_KEY_SIZE_REQ

LMP_ENCRYPTION_KEY_SIZE_REQ

LMP_ACCEPTED

Sequence 44: Encryption key size negotiation successful

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 2, Part C Page 683
Link Manager Protocol Specification

Central Peripheral
LM LM
LMP_ENCRYPTION_KEY_SIZE_REQ

LMP_ENCRYPTION_KEY_SIZE_REQ

LMP_ENCRYPTION_KEY_SIZE_REQ

LMP_NOT_ACCEPTED

Sequence 45: Encryption key size negotiation failed

4.2.5.3 Start encryption

To start encryption, the Central issues the random number EN_RAND and calculates
the encryption key. See [Vol 2] Part H, Section 3.2.5. The random number shall be the
same for all Peripherals in the piconet when broadcast encryption is used. The Central
then sends an LMP_START_ENCRYPTION_REQ PDU, that includes EN_RAND.

The Peripheral shall calculate the encryption key when this message is received and
shall acknowledge with an LMP_ACCEPTED PDU. For E0, the encryption key shall
be calculated using the E3 algorithm (see [Vol 2] Part H, Section 6.4). For AES-CCM,
the encryption key shall be calculated using the h3 algorithm (see [Vol 2] Part H,
Section 7.7.6).

Note: For AES-CCM, the EN_RAND is not used when creating the encryption key.

If encryption has been paused, then this sequence shall not be used.

Central Peripheral
LM LM
LMP_START_ENCRYPTION_REQ

LMP_ACCEPTED

Sequence 46: Start encryption

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 2, Part C Page 684
Link Manager Protocol Specification

Starting encryption shall be performed in three steps:

1. Central is configured to transmit unencrypted packets and to receive encrypted

packets.
2. Peripheral is configured to transmit and receive encrypted packets.
3. Central is configured to transmit and receive encrypted packets.

Between step 1 and step 2, Central-to-Peripheral transmission is possible. This is when

an LMP_START_ENCRYPTION_REQ PDU is transmitted. Step 2 is triggered when the
Peripheral receives this message. Between step 2 and step 3, Peripheral-to-Central
transmission is possible. This is when an LMP_ACCEPTED PDU is transmitted. Step 3
is triggered when the Central receives this message.

4.2.5.4 Stop encryption

To stop encryption a device shall send an LMP_ENCRYPTION_MODE_REQ PDU with

the parameter Encryption_Mode equal to 0 (no encryption). The other device responds
with an LMP_ACCEPTED PDU or an LMP_NOT_ACCEPTED PDU (the procedure is
described in Sequence 43 in Section 4.2.5.1). If accepted, encryption shall be stopped
by the Central sending an LMP_STOP_ENCRYPTION_REQ PDU and the Peripheral
shall respond with an LMP_ACCEPTED PDU according to Sequence 47.

If encryption has been paused, then this sequence shall not be used.

Central Peripheral
LM LM
LMP_STOP_ENCRYPTION_REQ

LMP_ACCEPTED

Sequence 47: Stop encryption

Stopping encryption shall be performed in three steps, similar to the procedure for
starting encryption.

1. Central is configured to transmit encrypted packets and to receive unencrypted

packets.
2. Peripheral is configured to transmit and receive unencrypted packets.
3. Central is configured to transmit and receive unencrypted packets.

Between step 1 and step 2 Central to Peripheral transmission is possible. This is when
an LMP_STOP_ENCRYPTION_REQ PDU is transmitted. Step 2 is triggered when the
Peripheral receives this message. Between step 2 and step 3 Peripheral to Central

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 2, Part C Page 685
Link Manager Protocol Specification

transmission is possible. This is when an LMP_ACCEPTED PDU is transmitted. Step 3

is triggered when the Central receives this message.

4.2.5.5 Pause encryption

For E0 encryption:

• To pause encryption without disabling encryption, a device shall finalize

the transmission of the current ACL-U data packet and then send an
LMP_PAUSE_ENCRYPTION_REQ PDU (with the transaction ID set to the role of
the device at the time the LMP_PAUSE_ENCRYPTION_REQ PDU is sent).

For AES-CCM encryption:

• To pause encryption without disabling encryption, a device shall finalize

the transmission of the current ACL-U data packet and then send an
LMP_PAUSE_ENCRYPTION_AES_REQ PDU (with the transaction ID set to the
role of the device at the time the LMP_PAUSE_ENCRYPTION_AES_REQ PDU is
sent). The LMP_PAUSE_ENCRYPTION_AES_REQ PDU includes a random number
EN_RAND.

If the responding device is a Central, then the Central shall finalize the
transmission of the current ACL-U data packet and then respond with an
LMP_STOP_ENCRYPTION_REQ PDU to the Peripheral.

If the responding device is a Peripheral, then the Peripheral shall finalize

the transmission of the current ACL-U data packet and then respond with
an LMP_PAUSE_ENCRYPTION_REQ PDU. The Central shall respond to the
LMP_PAUSE_ENCRYPTION_REQ PDU with an LMP_STOP_ENCRYPTION_REQ
PDU to the Peripheral.

When the Peripheral receives the LMP_STOP_ENCRYPTION_REQ PDU it shall

respond with an LMP_ACCEPTED PDU.

Central Peripheral
LM LM
LMP_PAUSE_ENCRYPTION_REQ

LMP_PAUSE_ENCRYPTION_REQ

LMP_STOP_ENCRYPTION_REQ

LMP_ACCEPTED

Sequence 48: Central-initiated pausing of encryption (E0)

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 2, Part C Page 686
Link Manager Protocol Specification

Central Peripheral
LM LM
LMP_PAUSE_ENCRYPTION_AES_REQ

LMP_PAUSE_ENCRYPTION_REQ

LMP_STOP_ENCRYPTION_REQ

LMP_ACCEPTED

Sequence 49: Central-initiated pausing of encryption (AES-CCM)

Central Peripheral
LM LM
LMP_PAUSE_ENCRYPTION_REQ

LMP_STOP_ENCRYPTION_REQ

LMP_ACCEPTED

Sequence 50: Peripheral-initiated pausing of encryption (E0)

Central Peripheral
LM LM
LMP_PAUSE_ENCRYPTION_REQ

LMP_STOP_ENCRYPTION_REQ

LMP_ACCEPTED

Sequence 51: Peripheral-initiated pausing of encryption (AES-CCM)

For E0 encryption:

• The LMP_PAUSE_ENCRYPTION_REQ PDU and LMP_STOP_ENCRYPTION_REQ

PDU shall only be rejected when a transaction collision needs to be resolved.

For AES-CCM encryption:

• The LMP_PAUSE_ENCRYPTION_AES_REQ PDU and

LMP_STOP_ENCRYPTION_REQ PDU shall only be rejected when a transaction
collision needs to be resolved.

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 2, Part C Page 687
Link Manager Protocol Specification

Pausing encryption shall be performed in three steps, similar to the procedure for
stopping encryption.

1. Central is configured to transmit encrypted packets and to receive unencrypted

packets.
2. Peripheral is configured to transmit and receive unencrypted packets.
3. Central is configured to transmit and receive unencrypted packets.

Between step 1 and step 2 Central-to-Peripheral transmission is possible. This is

when the LMP_STOP_ENCRYPTION_REQ PDU is transmitted from the Central to the
Peripheral. Step 2 is triggered when the Peripheral receives this message. Between
step 2 and step 3 Peripheral-to-Central transmission is possible. This is when an
LMP_ACCEPTED PDU is transmitted. Step 3 is triggered when the Central receives
this message.

Note: A device can only restart ACL-U data traffic by resuming encryption using the
procedures in Section 4.2.5.6.

4.2.5.6 Resume encryption

Initiating – Responding –
Central LM Peripheral LM
LMP_START_ENCRYPTION_REQ

LMP_ACCEPTED

Sequence 52: Initiating Central LM resumes encryption

Initiating – Responding –
Peripheral LM Central LM
LMP_RESUME_ENCRYPTION_REQ

LMP_START_ENCRYPTION_REQ

LMP_ACCEPTED

Sequence 53: Initiating Peripheral LM resumes encryption

For E0 encryption:

• If the responding device is a Peripheral, then the Peripheral shall calculate the
encryption key and respond with an LMP_ACCEPTED PDU.
• If the responding device is a Central, then the Central shall respond with
an LMP_START_ENCRYPTION_REQ PDU. The Peripheral, upon receiving the

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 2, Part C Page 688
Link Manager Protocol Specification

LMP_START_ENCRYPTION_REQ PDU from the Central, shall calculate the

encryption key and respond with an LMP_ACCEPTED PDU.

For AES-CCM encryption:

• If the resume encryption was the result of a Change Connection Link Key procedure,
the LMs shall calculate a new encryption key using the h3 algorithm (see [Vol 2] Part
H, Section 7.7.6).
• If the responding device is a Peripheral, then the Peripheral shall respond with an
LMP_ACCEPTED PDU.
• If the responding device is a Central, then the Central shall respond with
an LMP_START_ENCRYPTION_REQ PDU. The Peripheral, upon receiving the
LMP_START_ENCRYPTION_REQ PDU from the Central, shall respond with an
LMP_ACCEPTED PDU.

Note: When AES-CCM is used, the EN_RAND value in the

LMP_START_ENCRYPTION_REQ PDU is not used.

The LMP_RESUME_ENCRYPTION_REQ PDU and the

LMP_START_ENCRYPTION_REQ PDU shall not be rejected.

Resuming encryption shall be performed in three steps, similar to the procedure for
starting encryption:

1. Central is configured to transmit unencrypted packets and to receive encrypted

packets.
2. Peripheral is configured to transmit and receive encrypted packets.
3. Central is configured to transmit and receive encrypted packets.

Between step 1 and step 2, Central-to-Peripheral transmission is possible. This is when

the LMP_START_ENCRYPTION_REQ PDU is transmitted from the Central. Step 2
is triggered when the Peripheral receives this message. Between step 2 and step 3,
Peripheral-to-Central transmission is possible. This is when an LMP_ACCEPTED PDU
is transmitted. Step 3 is triggered when the Central receives this message.

Note: For a Peripheral-initiated resumption of encryption, step 1 is not started when

the Central has received the LMP_RESUME_ENCRYPTION_REQ PDU from the
Peripheral, but when the Central sends the LMP_START_ENCRYPTION_REQ PDU.

Once encryption has been resumed, the device shall restart ACL-U traffic.

4.2.5.7 Change encryption key or random number

If the encryption key or encryption random number need to be changed, or if the

current link key needs to be changed according to the procedures in Section 4.2.3

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 2, Part C Page 689
Link Manager Protocol Specification

and Section 4.2.4, encryption shall be paused and resumed after completion, using the
procedures in Section 4.2.5.5 and Section 4.2.5.6, for the new parameters to be valid.
If the Pause Encryption feature is not supported by both devices, encryption shall be
stopped and re-started after completion, using the procedures in Section 4.2.5.3 and
Section 4.2.5.4, for the new parameters to be valid.

4.2.5.8 Encryption key refresh

When E0 encryption is used, the Link Manager shall refresh the encryption key within
228 ticks of the Bluetooth clock from the previous start or resume of encryption. When
AES-CCM encryption is used, the Link Manager shall refresh the encryption key before
either the PayloadCounter or dayCounter roll over. To refresh the encryption key,
the Link Manager shall Pause encryption using the procedure in Section 4.2.5.5 and
immediately Resume encryption using the procedure in Section 4.2.5.6.

Note: The roll over will occur at least 238 ticks of the Bluetooth clock after the previous
start of encryption.

If the encryption key has not been refreshed before the rollover event, the link shall be
terminated immediately.

4.2.6 Request supported encryption key size

It is possible for the Central to request a Peripheral's supported encryption key sizes.

M/O PDU Contents

O(23) LMP_ENCRYPTION_KEY_SIZE_MASK_REQ none
O(23) LMP_ENCRYPTION_KEY_SIZE_MASK_RES Key_Size_Mask

Table 4.22: Encryption key size request PDU

The Central shall send an LMP_ENCRYPTION_KEY_MASK_REQ PDU to the

Peripheral to obtain the Peripheral’s supported encryption key sizes.

The Peripheral shall return a bit mask indicating all broadcast encryption key sizes
supported. The least significant bit shall indicate support for a key size of 1, the next
most significant bit shall indicate support for a key size of 2 and so on up to a key size
of 16. In all cases a bit set to 1 shall indicate support for a key size; a bit set to 0 shall
indicate that the key size is not supported.

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 2, Part C Page 690
Link Manager Protocol Specification

Central Peripheral
LM LM
LMP_ENCRYPTION_KEY_SIZE_MASK_REQ

LMP_ENCRYPTION_KEY_SIZE_MASK_RES

Sequence 54: Request for supported encryption key sizes

4.2.7 Secure Simple Pairing

There are four stages defined in the Secure Simple Pairing LM process:

• IO capabilities exchange
• Public key exchange
• Authentication stage 1
• Authentication stage 2

The devices shall first exchange the IO capabilities to determine the proper algorithm
to be used. Three algorithms have been specified: Numeric comparison, Passkey entry,
Out of band.

In following sections, the device requesting the IO capabilities is referred to as the

"Initiating LM" or "Initiator". The other device is referred to as the "LM" or "Responder".
This designation remains throughout the entire Secure Simple Pairing procedure.

M/O PDU Contents

O(51) LMP_IO_CAPABILITY_REQ IO_Capabilities,
OOB_Auth_Data,
Authentication_Requirements
O(51) LMP_IO_CAPABILITY_RES IO_Capabilities,
OOB_Auth_Data,
Authentication_Requirements
O(51) LMP_SIMPLE_PAIRING_CONFIRM Commitment_Value
O(51) LMP_SIMPLE_PAIRING_NUMBER Nonce_Value
O(51) LMP_DHKEY_CHECK Confirmation_Value
O(51) LMP_NUMERIC_COMPARISON_FAILED none
O(51) LMP_OOB_FAILED none

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 2, Part C Page 691
Link Manager Protocol Specification

M/O PDU Contents

O(51) LMP_KEYPRESS_NOTIFICATION Notification_Type
O(51) LMP_PASSKEY_ENTRY_FAILED none

Table 4.23: Secure simple pairing PDUs

4.2.7.1 IO capability exchange

The Link Managers shall use the local and remote IO capabilities to determine which
association model shall be used.

If Simple_Pairing_Mode is set to enabled, the Initiator shall request the IO capabilities

from the Host. The initiator shall send an LMP_IO_CAPABILITY_REQ PDU to the
Responder. If Simple_Pairing_Mode is set to enabled on the responding device, it shall
reply with an LMP_IO_CAPABILITY_RES PDU containing its IO capabilities description.

The OOB_Auth_Data parameter shall be set as shown in Table 4.24.

Local Device
Does not support Secure Supports Secure
Connections Connections
Does not have OOB Data No OOB Data Received No OOB Data Received
Does not support Secure Con- OOB Data Received OOB Data Received
nections.
Remote Device

P-192 OOB Data Available

Only P-192 OOB Data OOB Data Received No OOB Data Received
Supports Secure

Available
OOB Data Received 1
Connections

P-192 OOB Data and OOB Data Received

P-256 OOB Data Availa-
ble
Only P-256 OOB Data No OOB Data Received 1 OOB Data Received
Available

Table 4.24: Setting the OOB_Auth_Data parameter

1A device that does not support Secure Connections cannot generate P-256 OOB data.

Initiating
LM
LM
LMP_IO_CAPABILITY_REQ

LMP_IO_CAPABILITY_RES

Sequence 55: IO capability exchange

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 2, Part C Page 692
Link Manager Protocol Specification

4.2.7.1.1 IO capability exchange transaction collision and resolution

If both Link Managers attempt to become the initiator of the IO capability exchange,
the Central’s Link Manager shall send an LMP_NOT_ACCEPTED_EXT PDU with
Error_Code LMP Error Transaction Collision / LL Procedure Collision (0x23). The
Peripheral’s Link Manager shall respond with the LMP_IO_CAPABILITY_RES PDU.

The Central’s LM shall remain the initiating LM for the remainder of the Secure Simple
Pairing sequences.

Central Peripheral
LM LM
LMP_IO_CAPABILITY_REQ

LMP_IO_CAPABILITY_REQ

LMP_NOT_ACCEPTED_EXT (transaction collision)

LMP_IO_CAPABILITY_RES

Sequence 56: IO capability exchange with transaction collision (Central transmitting

LMP_IO_CAPABILITY_REQ first) and resolution

Central Peripheral
LM LM
LMP_IO_CAPABILITY_REQ

LMP_IO_CAPABILITY_REQ

LMP_NOT_ACCEPTED_EXT (transaction collision)

LMP_IO_CAPABILITY_RES

Sequence 57: IO capability exchange with transaction collision (Peripheral transmitting

LMP_IO_CAPABILITY_REQ first) and resolution

4.2.7.2 Public key exchange

Once the IO capabilities are exchanged, public keys shall be exchanged between the
two devices.

Since the public key size is longer than the payload body length of a DM1
packet, the exchange shall be done using the LMP_ENCAPSULATED_HEADER and
LMP_ENCAPSULATED_PAYLOAD PDUs as defined in Section 4.1.12.

When at least one device does not support Secure Connections, the P-192 curve shall
be used for calculating the public and private keys. When both devices support Secure
Connections, the P-256 curve shall be used for calculating the public and private keys.

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 2, Part C Page 693
Link Manager Protocol Specification

The Initiator shall first send its public key, and the Responder shall reply with its public
key.

Initiating
LM
LM
LMP_ENCAPSULATED_HEADER (public key)

LMP_ACCEPTED

Repeat N Times
LMP_ENCAPSULATED_PAYLOAD

LMP_ACCEPTED

LMP_ENCAPSULATED_HEADER (public key)

LMP_ACCEPTED

Repeat N Times
LMP_ENCAPSULATED_PAYLOAD

LMP_ACCEPTED

Sequence 58: Public key exchange

A public key shall be considered as received when the last

LMP_ENCAPSULATED_PAYLOAD has been received and the associated
LMP_ACCEPTED PDU has been sent.

The device can then start computing its Diffie Hellman Key.

4.2.7.3 Authentication stage 1

One of the following procedures shall be used in Authentication stage 1:

• If one or both devices have the OOB_Auth_Data parameter set to Received, the
Out-of-Band procedure shall be used.
• If both devices have the Authentication_Requirements parameter set to one of the
man-in-the middle (MITM) Protection Not Required options, the Numeric Comparison
procedure shall be used.
• If one or both devices have the Authentication_Requirements parameter set to one
of the MITM Protection Required options, the Passkey Entry procedure shall be used
if the either the local or remote IO Capability is set to KeyboardOnly and the other
IO capability is not set to NoInputNoOutput. Otherwise, the Numeric Comparison
authentication procedure shall be used.

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 2, Part C Page 694
Link Manager Protocol Specification

4.2.7.3.1 Authentication stage 1: Numeric Comparison

Once public keys have been exchanged, both devices shall generate a random number.

The Responder shall compute its commitment as defined in [Vol 2] Part

H, Section 7.7.1, and shall send this value to the Initiator by using
LMP_SIMPLE_PAIRING_CONFIRM PDU. The Initiator shall then send an
LMP_SIMPLE_PAIRING_NUMBER PDU with its generated random number. The
Responder shall acknowledge by sending an LMP_ACCEPTED PDU.

The Responder shall then send an LMP_SIMPLE_PAIRING_NUMBER containing

its own generated random number. Upon reception, the Initiator shall calculate the
commitment as defined in [Vol 2] Part H, Section 7.7.1 and compare it to the one
received previously with the LMP_SIMPLE_PAIRING_CONFIRM PDU. If both values
are equal, the Initiator shall respond with an LMP_ACCEPTED PDU.

Initiating
LM
LM
LMP_SIMPLE_PAIRING_CONFIRM

LMP_SIMPLE_PAIRING_NUMBER

LMP_ACCEPTED

LMP_SIMPLE_PAIRING_NUMBER

LMP_ACCEPTED

Sequence 59: Numeric Comparison Authentication: Commitment check success

4.2.7.3.1.1 Commitment check failure

If the calculated commitment by the Initiator is not equal to the received

commitment, the Initiator shall abort the Secure Simple Pairing process by sending
an LMP_NOT_ACCEPTED PDU with reason "Authentication Failure."

Initiating
LM
LM
LMP_SIMPLE_PAIRING_CONFIRM

LMP_SIMPLE_PAIRING_NUMBER

LMP_ACCEPTED

LMP_SIMPLE_PAIRING_NUMBER

LMP_NOT_ACCEPTED

Sequence 60: Numeric Comparison authentication: Commitment check failure

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 2, Part C Page 695
Link Manager Protocol Specification

4.2.7.3.1.2 Numeric Comparison failure on Initiator side

If the user on the initiating side indicates that the confirm values do not match (e.g.,
as indicated by the HCI_User_Confirmation_Request_Negative_Reply command) the
initiating LM shall send an LMP_NUMERIC_COMPARISON_FAILURE PDU.

The Secure Simple Pairing process shall then be aborted. The Link Managers shall not
disconnect the connection.

Initiating
LM
LM
LMP_NUMERIC_COMPARISON_FAILED

Sequence 61: Authentication stage 1: Numeric Comparison failure on Initiator side

4.2.7.3.1.3 Numeric Comparison failure on Responder side

If the user on the responding side indicates that the confirm values do not match
(e.g., as indicated by the HCI_User_Confirmation_Request_Negative_Reply command)
the responding LM shall send an LMP_NOT_ACCEPTED PDU in response to the
LMP_DHKEY_CHECK PDU sent in authentication stage 2 (see Section 4.2.7.4).

The Secure Simple Pairing process shall then be aborted. The Link Managers shall not
disconnect the connection.

Initiating
LM
LM
LMP_SIMPLE_PAIRING_CONFIRM

LMP_SIMPLE_PAIRING_NUMBER

LMP_ACCEPTED

LMP_SIMPLE_PAIRING_NUMBER

LMP_ACCEPTED

LMP_DHKEY_CHECK (authentication stage 2)

LMP_NOT_ACCEPTED

Sequence 62: Authentication stage 1: Numeric Comparison failure on Responder side

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 2, Part C Page 696
Link Manager Protocol Specification

4.2.7.3.2 Authentication stage 1: Passkey Entry Authentication

The initiating LM shall start the following procedure after receiving the Passkey Reply
from the Host. This procedure shall be repeated 20 times:

1. The Initiator and the Responder shall generate a new random number.
2. The Initiator and the Responder shall calculate the local commitment value using
the exchanged public keys, the local random number, and the passkey from the
local Host, according to [Vol 2] Part H, Section 7.7.1.
3. The Initiator shall send an LMP_SIMPLE_PAIRING_CONFIRM PDU with the
commitment it calculated in step 2.
4. The Responder shall respond with an LMP_SIMPLE_PAIRING_CONFIRM PDU
with the commitment it calculated in step 2.
5. The Initiator shall then send an LMP_SIMPLE_PAIRING_NUMBER PDU with the
random number it generated in step 1.
6. The Responder shall then calculate commitment from the exchanged public keys,
the random number it received and the passkey from the local Host, according
to [Vol 2] Part H, Section 7.7.1. If the calculated commitment and the received
commitment are equal, the Responder shall reply with an LMP_ACCEPTED PDU.
7. The Responder shall then send an LMP_SIMPLE_PAIRING_NUMBER PDU with
the random value it generated in step 1.
8. The Initiator shall calculate the commitment using the exchanged public keys, the
random number it received, and the passkey from the local Host, according to [Vol
2] Part H, Section 7.7.1. If the calculated commitment is equal to the received
commitment, the Initiator shall reply with an LMP_ACCEPTED PDU.

Initiating
LM
LM

Repeat 20 times
LMP_SIMPLE_PAIRING_CONFIRM

LMP_SIMPLE_PAIRING_CONFIRM

LMP_SIMPLE_PAIRING_NUMBER

LMP_ACCEPTED

LMP_SIMPLE_PAIRING_NUMBER

LMP_ACCEPTED

Sequence 63: Authentication passkey entry

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 2, Part C Page 697
Link Manager Protocol Specification

When this procedure has successfully passed 20 times, the Secure Simple Pairing
process continues with the Authentication step 2 as described in Section 4.2.7.4.

4.2.7.3.2.1 Commitment check failure on the Responder side

If during one of the 20 repetitions, the commitment calculated by the Responder is not
equal to the one received from the Initiator (step 6), the Responder shall abort the
Secure Simple Pairing process by sending an LMP_NOT_ACCEPTED PDU with reason
"Authentication Failure."

Secure Simple Pairing procedures shall then be aborted. The Link Managers shall not
disconnect the connection.

Initiating
LM
LM

LMP_SIMPLE_PAIRING_CONFIRM

LMP_SIMPLE_PAIRING_CONFIRM

LMP_SIMPLE_PAIRING_NUMBER

LMP_NOT_ACCEPTED

Sequence 64: Authentication passkey entry: Commitment check failure on the Responder side

4.2.7.3.2.2 Commitment check failure on the Initiator side

If during one of the 20 repetitions, the commitment calculated by the Initiator is not
equal to the one received from the Responder (step 8), the Initiator shall abort the
Secure Simple Pairing process by sending an LMP_NOT_ACCEPTED PDU with reason
"Authentication Failure".

Secure Simple Pairing procedures shall then be aborted. The Link Managers shall not
disconnect the connection.

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 2, Part C Page 698
Link Manager Protocol Specification

Initiating
LM
LM

LMP_SIMPLE_PAIRING_CONFIRM

LMP_SIMPLE_PAIRING_CONFIRM

LMP_SIMPLE_PAIRING_NUMBER

LMP_ACCEPTED

LMP_SIMPLE_PAIRING_NUMBER

LMP_NOT_ACCEPTED

Sequence 65: Authentication passkey entry: Commitment check failure on the Initiator side

4.2.7.3.2.3 Passkey Entry failure on Initiator side

If the initiating side indicates that the passkey was not entered or canceled (e.g., as
indicated by the HCI_User_Passkey_Request_Negative_Reply command) the initiating
LM shall send an LMP_PASSKEY_ENTRY_FAILED PDU.

Secure Simple Pairing process shall then be aborted. The Link Managers shall not
disconnect the connection.

Initiating
LM
LM
LMP_PASSKEY_ENTRY_FAILED

Sequence 66: Authentication stage 1: Passkey Entry failure on Initiator side

4.2.7.3.3 Passkey Entry failure on Responding side

If the responding side indicates that the passkey was not entered or canceled
(e.g., as indicated by the HCI_User_Passkey_Request_Negative_Reply command),
the responding LM shall send an LMP_NOT_ACCEPTED PDU in response to the
LMP_SIMPLE_PAIRING_CONFIRM PDU.

The Secure Simple Pairing process shall then be aborted. The Link Managers shall not
disconnect the connection.

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 2, Part C Page 699
Link Manager Protocol Specification

Initiating
LM
LM
LMP_SIMPLE_PAIRING_CONFIRM

LMP_NOT_ACCEPTED

Sequence 67: Authentication stage 1: Passkey Entry failure on Responding side

4.2.7.3.4 Keypress notifications

A Controller that allows the Host to change its IO capabilities shall send notifications on
key presses to the remote side using the LMP_KEYPRESS_NOTIFICATION PDU when
the Host sets the IO capabilities to KeyboardOnly IO and when Secure Simple Pairing is
supported on the Host and Controller.

Initiating
LM
LM
LMP_KEYPRESS_NOTIFICATION

Sequence 68: Keypress notifications

4.2.7.3.5 Authentication stage 1: OOB

Upon reception of the OOB information (as defined in [Vol 2] Part H, Section 7.2.2)
from the Host, the devices shall compare the received commitment from its Host,
with the one calculated using the secret number received from the Host and the
public key received from the remote device. If the local Host has not set the OOB
Authentication Data Present, the LM shall set the remote secret number to zero and
base the subsequent calculations on this value.

If the commitment check on the initiator is valid, the Initiator shall then
generate a random number (nonce) and send it to the Responder using an
LMP_SIMPLE_PAIRING_NUMBER PDU. If the commitment succeeds, the Responder
shall acknowledge by sending an LMP_ACCEPTED PDU otherwise it shall send
an LMP_NOT_ACCEPTED PDU. The Responder shall then generate a random
number (nonce) and send it to the Initiator using an LMP_SIMPLE_PAIRING_NUMBER
PDU. If the commitment succeeds, the Initiator shall acknowledge by sending an
LMP_ACCEPTED PDU otherwise it shall send an LMP_NOT_ACCEPTED PDU.

If the commitment values don't match in the Initiator, the procedure in

Section 4.2.7.3.5.2 shall apply.

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 2, Part C Page 700
Link Manager Protocol Specification

If the commitment values don't match in the Responder, the procedure in

Section 4.2.7.3.5.1 shall apply.

Initiating
LM
LM
LMP_SIMPLE_PAIRING_NUMBER

LMP_ACCEPTED

LMP_SIMPLE_PAIRING_NUMBER

LMP_ACCEPTED

Sequence 69: Authentication OOB: Only one device is OOB-r capable

When these operations have been passed successfully, Secure Simple Pairing
procedures continue with Authentication step 2 as described in Section 4.2.7.4.

4.2.7.3.5.1 Commitment check failure on the Responder side

If the commitment received OOB from the Host is not equal to the calculated
commitment, the Responder shall send an LMP_NOT_ACCEPTED PDU with reason
"Authentication Failure" in response to the LMP_SIMPLE_PAIRING_NUMBER PDU.

Secure Simple Pairing process shall then be aborted. The Link Managers shall not
disconnect the connection.

Initiating
LM
LM
LMP_SIMPLE_PAIRING_NUMBER

LMP_NOT_ACCEPTED

Sequence 70: Authentication stage 1 OOB: Commitment check failure on the Responder side

4.2.7.3.5.2 Commitment check failure on the Initiator side

If the commitment received OOB from the Host is not equal to the calculated
commitment, the Initiator shall send an LMP_NOT_ACCEPTED PDU with reason
"Authentication Failure" in response to the LMP_SIMPLE_PAIRING_NUMBER PDU.

Secure Simple Pairing process shall then be aborted. The Link Managers shall not
disconnect the connection.

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 2, Part C Page 701
Link Manager Protocol Specification

Initiating
LM
LM
LMP_SIMPLE_PAIRING_NUMBER

LMP_ACCEPTED

LMP_SIMPLE_PAIRING_NUMBER

LMP_NOT_ACCEPTED

Sequence 71: Authentication stage 1 OOB: Commitment check failure on the Initiator side

4.2.7.3.6 Out-of-band information not available on the Initiator side

If the Host on the initiating side does not have out-of-band information the Initiator shall
send an LMP_OOB_FAILED PDU.

The Secure Simple Pairing process shall then be aborted. The Link Managers shall not
disconnect the connection.

Initiating
LM
LM
LMP_OOB_FAILED

Sequence 72: Authentication stage 1 OOB: OOB information not available on the Initiator side

4.2.7.4 Authentication stage 2: DHKey check

At this stage, both devices compute new confirmation values based on Diffie-Hellman
key and previously exchanged information according to [Vol 2] Part H, Section 7.7.4.

The Initiator shall send an LMP_DHKEY_CHECK PDU to the Responder. If the

Initiator has determined that the received public key is invalid (see [Vol 2] Part H,
Section 7.6), the PDU shall include a confirmation value that is different from the
computed confirmation value (for example, substituting a randomly generated number).
Otherwise, the PDU shall include the computed confirmation value.

Upon reception, if the received value is not equal to the one calculated according to
[Vol 2] Part H, Section 7.7.4, or if the received public key is invalid (see [Vol 2] Part
H, Section 7.6), then the Responder shall follow the procedure in Section 4.2.7.4.1.
Otherwise it shall reply with an LMP_ACCEPTED PDU.

The Responder shall then send an LMP_DHKEY_CHECK PDU, including the

confirmation value it has computed, to the Initiator. Upon reception, if the received
value is not equal to the one calculated according to [Vol 2] Part H, Section 7.7.4,

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 2, Part C Page 702
Link Manager Protocol Specification

or if the received public key is invalid (see [Vol 2] Part H, Section 7.6), then the
Initiator shall follow the procedure in Section 4.2.7.4.1. Otherwise it shall reply with
an LMP_ACCEPTED PDU.

At this point, both devices shall compute the link key according to [Vol 2] Part H,
Section 7.7.3.

If at least one device does not support both the Secure Connections (Controller
Support) and the Secure Connections (Host Support) features, the Initiator shall then
start standard mutual authentication as described in Section 4.2.1.1

If both devices support both the Secure Connections (Controller Support) and the
Secure Connections (Host Support) features, the Initiator shall then start secure
authentication as described in Section 4.2.1.4.

After secure authentication, if encryption is enabled, the initiating device shall pause
and immediately resume encryption to produce a new encryption key.

Note: This will cause a new encryption key to be generated using the h3 function
including the ACO created during the secure authentication process.

Initiating
LM LM

LMP_DHKEY_CHECK

LMP_ACCEPTED

LMP_DHKEY_CHECK

LMP_ACCEPTED

Sequence 73: DHKey check

A device that detects an invalid public key (see [Vol 2] Part H, Section 7.6) from the
peer at any point during the Secure Simple Pairing process shall fail the pairing process
and therefore not create a link key.

4.2.7.4.1 Check failure

If either Link Manager receives a public key that is invalid (see [Vol 2] Part H,
Section 7.6), it shall send an LMP_NOT_ACCEPTED PDU with reason "Authentication
Failure". If either Link Manager receives a confirmation value via LMP that is not equal
to the one it has calculated according to [Vol 2] Part H, Section 7.7.4, it shall send an
LMP_NOT_ACCEPTED PDU with reason "Authentication Failure".

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 2, Part C Page 703
Link Manager Protocol Specification

The Secure Simple Pairing procedures shall then be aborted. The Link Managers shall
not disconnect the connection.

Initiating
LM
LM
LMP_DHKEY_CHECK

LMP_NOT_ACCEPTED

Sequence 74: DHKey check: Check failure on the Responder side

Initiating
LM LM

LMP_DHKEY_CHECK

LMP_ACCEPTED

LMP_DHKEY_CHECK

LMP_NOT_ACCEPTED

Sequence 75: DHKey check: Check failure on the Initiator side

4.2.7.4.1.1 [This section is no longer used]

4.3 Informational requests

4.3.1 Timing accuracy

LMP supports requests for the timing accuracy. This information can be used to
minimize the scan window during piconet physical channel re-synchronization (see [Vol
2] Part B, Section 2.2.5.2). The timing accuracy parameters returned are the long term
drift measured in ppm and the long term jitter measured in µs of the worst case clock
used. These parameters are fixed for a certain device and shall be identical when
requested several times. Reported time accuracy shall not include changes caused
by performing Piconet Clock Adjustment. If timing accuracy information has not been
received from the remote device, the worst-case values (drift = 250 ppm and jitter = 10
µs) shall be used.

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 2, Part C Page 704
Link Manager Protocol Specification

M/O PDU Contents

O(4) LMP_TIMING_ACCURACY_REQ none
O(4) LMP_TIMING_ACCURACY_RES Drift
Jitter

Table 4.25: Request limited timing PDU

Initiating
LM
LM
LMP_TIMING_ACCURACY_REQ

LMP_TIMING_ACCURACY_RES

Sequence 76: The requested device supports timing accuracy information

Initiating
LM
LM
LMP_TIMING_ACCURACY_REQ

LMP_NOT_ACCEPTED

Sequence 77: The requested device does not support timing accuracy information

4.3.2 Clock offset

The clock offset can be used to speed up the paging time the next time the same device
is paged. The Central can request the clock offset at anytime following a successful
Baseband Paging procedure (i.e., before, during or after connection setup). The clock
offset shall be defined by the following equation:

(CLKN16-2 Peripheral - CLKN16-2 Central) mod 215.

M/O PDU Contents

M LMP_CLKOFFSET_REQ none
M LMP_CLKOFFSET_RES Clock_Offset

Table 4.26: PDUs used for clock offset request

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 2, Part C Page 705
Link Manager Protocol Specification

Central Peripheral
LM LM
LMP_CLKOFFSET_REQ

LMP_CLKOFFSET_RES

Sequence 78: Clock offset requested

4.3.3 LMP version

LMP supports requests for the version of the LM protocol. The

LMP_VERSION_REQ and LMP_VERSION_RES PDUs contain three parameters:
Version, Company_Identifier and Subversion. Version specifies the version of the
Bluetooth LMP specification that the device supports. All companies that create
a unique implementation of the LM shall have their own Company_Identifier. The
same company is also responsible for the administration and maintenance of the
Subversion. It is recommended that each company has a unique Subversion for each
RF/BB/LM implementation. For a given Version and Company_Identifier, the values of
the Subversion shall increase each time a new implementation is released. For both
Company_Identifier and Subversion the value 0xFFFF means that no valid number
applies. There is no ability to negotiate the version of the LMP. The sequence below
is only used to exchange the parameters. LMP version can be requested at anytime
following a successful Baseband Paging procedure.

Note: A given value for Version does not indicate that the device supports all the
features in the corresponding version of the specification; the relevant feature bits (see
Section 4.3.4) should be checked instead.

Note: A larger value for Version does not necessarily indicate a higher version of the
specification.

M/O PDU Contents

M LMP_VERSION_REQ Version
Company_Identifier
Subversion
M LMP_VERSION_RES Version
Company_Identifier
Subversion

Table 4.27: PDUs used for LMP version request

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 2, Part C Page 706
Link Manager Protocol Specification

Initiating
LM
LM
LMP_VERSION_REQ

LMP_VERSION_RES

Sequence 79: Request for LMP version

4.3.4 Supported features

The supported features may be requested at anytime following a successful

Baseband Paging procedure by sending the LMP_FEATURES_REQ PDU. Upon
reception of an LMP_FEATURES_REQ PDU, the receiving device shall return an
LMP_FEATURES_RES PDU.

The extended features mask provides support for more than 64 features.
Support for the extended features mask is indicated by the presence of the
appropriate bit in the LMP features mask. The LMP_FEATURES_REQ_EXT
and LMP_FEATURES_RES_EXT PDUs operate in precisely the same way as
the LMP_FEATURES_REQ and LMP_FEATURES_RES PDUs except that they
allow the various pages of the extended features mask to be requested. The
LMP_FEATURES_REQ_EXT may be sent at any time following the exchange of the
LMP_FEATURES_REQ and LMP_FEATURES_RSP PDUs.

The LMP_FEATURES_REQ_EXT PDU contains a Features_Page parameter that

specifies which page is requested and the contents of that page for the requesting
device. Pages are numbered from 0 to 255 with page 0 corresponding to the normal
features mask. Each page consists of 64 bits. If a device does not support any
page number it shall return an Extended_Features parameter with every bit set to
0. It also contains the maximum features page number containing any non-zero bit
for this device. The recipient of an LMP_FEATURES_REQ_EXT PDU shall respond
with an LMP_FEATURES_RES_EXT PDU containing the same page number and the
appropriate features page along with its own maximum features page number.

If the extended features request is not supported then all bits in all extended features
pages for that device shall be assumed to be zero.

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 2, Part C Page 707
Link Manager Protocol Specification

Initiating
LM
LM
LMP_FEATURES_REQ

LMP_FEATURES_RES

Sequence 80: Request for supported features

M/O PDU Contents

M LMP_FEATURES_REQ Features
M LMP_FEATURES_RES Features
O(63) LMP_FEATURES_REQ_EXT Features_Page
Max_Supported_Page
Extended_Features
O(63) LMP_FEATURES_RES_EXT Features_Page
Max_Supported_Page
Extended_Features

Table 4.28: PDUs used for features request

Initiating
LM
LM
LMP_FEATURES_REQ_EXT

LMP_FEATURES_RES_EXT

Sequence 81: Request for extended features

4.3.5 Name request

LMP supports name request to another device. The name is a user-friendly name
associated with the device and consists of a maximum of 248 bytes coded according
to the UTF-8 standard (more specifically, the type utf8{248z} defined in [Vol 1]
Part E, Section 2.9.3). The name is fragmented over one or more DM1 packets.
When an LMP_NAME_REQ PDU is sent, a Name_Offset indicates which fragment is
expected. The corresponding LMP_NAME_RES PDU carries the same Name_Offset,

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 2, Part C Page 708
Link Manager Protocol Specification

the Name_Length indicating the total number of bytes in the name of the device and the
Name_Fragment, where:

• Name_Fragment(N) = name(N + Name_Offset), if (N + Name_Offset) <

Name_Length
• Name_Fragment(N) = 0,otherwise.

Here 0 ≤ N ≤ 13. In the first sent LMP_NAME_REQ PDU, Name_Offset=0. Sequence

82 is then repeated until the initiator has collected all fragments of the name. The name
request may be made at any time following a successful Baseband Paging procedure.

M/O PDU Contents

M LMP_NAME_REQ Name_Offset
M LMP_NAME_RES Name_Offset
Name_Length
Name_Fragment

Table 4.29: Name request PDUs

Initiating
LM
LM
LMP_NAME_REQ

LMP_NAME_RES

Sequence 82: Request for device name

4.4 Role switch

4.4.1 Slot offset

With LMP_SLOT_OFFSET the information about the difference between the slot
boundaries in different piconets is transmitted. The LMP_SLOT_OFFSET PDU may
be sent anytime after the Baseband Paging procedure has completed if the ACL
logical transport is in Active mode and a synchronous logical transport is not being
negotiated by the LM. This PDU carries the parameters Slot_Offset and BD_ADDR. The
Slot_Offset shall be the time, in microseconds, from the start of a Central transmission
in the current piconet to the start of the next following Central transmission in the
piconet where the BD_ADDR device (normally the Peripheral) is Central at the time that
the request is interpreted by the BD_ADDR device.

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 2, Part C Page 709
Link Manager Protocol Specification

Central transmissions in
piconet where Peripheral
becomes the Central after
role switch

Central transmissions in
piconet before role switch

Slot offset in
microseconds

Figure 4.2: Slot offset for role switch

See Section 4.4.2 for the use of LMP_SLOT_OFFSET in the context of the role switch.
In the case of role switch the BD_ADDR is that of the Peripheral.

M/O PDU Contents

O(3) LMP_SLOT_OFFSET Slot_Offset
BD_ADDR

Table 4.30: Slot offset PDU

Initiating
LM
LM
LMP_SLOT_OFFSET

Sequence 83: Slot offset information is sent

4.4.2 Role switch

Since the paging device always becomes the Central of the piconet, a role switch is
sometimes needed; see [Vol 2] Part B, Section 8.6.5. A role switch may be performed
as part of connection establishment (see Section 4.1.1) or any time after connection
establishment has completed.

The LMP_SWITCH_REQ shall be sent only if the ACL logical transport is in Active
mode, encryption is stopped or paused, and all synchronous logical transports on the
same physical link are disabled. LMP_SWITCH_REQ shall not be initiated or accepted
while a synchronous logical transport is being negotiated by the LM.

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 2, Part C Page 710
Link Manager Protocol Specification

M/O PDU Contents

O(5) LMP_SWITCH_REQ Switch_Instant
O(5) LMP_SLOT_OFFSET Slot_Offset
BD_ADDR

Table 4.31: Role switch PDUs

Role switch is performed by an initiating device and a responding device.

First, the initiating LM shall pause traffic on the ACL-U logical link (see [Vol 2] Part B,
Section 5.3.1). Next, if the Encryption_Mode is set to "encryption" then it shall initiate
either the pause encryption sequence (see Section 4.2.5.5.) if both devices support
pausing encryption or the stop encryption sequence (see Section 4.2.5.4) otherwise. If it
is the Peripheral, it shall next send an LMP_SLOT_OFFSET PDU. Finally, it shall send
an LMP_SWITCH_REQ PDU.

If the responding device accepts the role switch, then first it shall pause traffic on the
ACL-U logical link if it is not already paused. If it is the Peripheral, it shall next send
an LMP_SLOT_OFFSET PDU. Finally, it shall send an LMP_ACCEPTED PDU. The two
devices shall then perform the Baseband Role Switch procedure. If it rejects the role
switch, it shall send an LMP_NOT_ACCEPTED PDU.

When the role switch has been completed at the Baseband level (successfully or not),
or has been rejected, then:

• If the initiating device had paused encryption, it shall initiate the resume encryption
sequence (see Section 4.2.5.6). When AES-CCM encryption is used, the LMs
shall calculate a new encryption key using the h3 algorithm (see [Vol 2] Part H,
Section 7.7.6) with the BD_ADDRs for the new Central and Peripheral prior to
resuming encryption.
• If the initiating device had stopped encryption, it shall initiate the start encryption
sequence (see Section 4.2.5.3).

Both devices shall then re-enable transmission on the ACL-U logical link.

The transaction ID for the role switch PDUs in the sequence (LMP_SLOT_OFFSET
and LMP_SWITCH_REQ along with the associated LMP_ACCEPTED or
LMP_NOT_ACCEPTED) shall be set to 0 when the initiating device is the Central and 1
when it is the Peripheral.

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 2, Part C Page 711
Link Manager Protocol Specification

Peripheral Central
LM LM
LMP_SLOT_OFFSET

LMP_SWITCH_REQ

LMP_ACCEPTED or LMP_NOT_ACCEPTED

Sequence 84: Role switch (Peripheral initiated)

Central Peripheral
LM LM

LMP_SWITCH_REQ

LMP_SLOT_OFFSET (if accepted)

LMP_ACCEPTED or LMP_NOT_ACCEPTED

Sequence 85: Role switch (Central initiated)

The LMP_SWITCH_REQ PDU contains a parameter, Switch_Instant, which specifies

the instant at which the TDD switch is performed. This is specified as a Bluetooth clock
value of the Central's clock, that is available to both devices. This instant is chosen by
the sender of the message and shall be at least 2×Tpoll or 32 (whichever is greater) slots
in the future. The switch instant shall be within 12 hours of the current clock value to
avoid clock wrap.

The sender of the LMP_SWITCH_REQ PDU selects the switch instant and queues the
LMP_SWITCH_REQ PDU to LC for transmission and starts a timer to expire at the
switch instant. When the timer expires it initiates the mode switch. In the case of a
Central initiated switch if the LMP_SLOT_OFFSET PDU has not been received by the
switch instant the role switch is carried out without an estimate of the Peripheral's slot
offset. If an LMP_NOT_ACCEPTED PDU is received before the timer expires then the
timer is stopped and the role switch shall not be initiated.

When the LMP_SWITCH_REQ is received the switch instant is compared with the
Central's current clock value. If it is in the past then the instant has been passed
and an LMP_NOT_ACCEPTED PDU with the Error_Code Instant Passed (0x28) shall
be returned. If it is in the future then an LMP_ACCEPTED PDU shall be returned,
assuming the role switch is accepted, and a timer is started to expire at the switch
instant. When this timer expires the role switch shall be initiated.

After a successful role switch the supervision timeout and poll interval (Tpoll) shall be set
to their default values. The authentication state and the ACO shall remain unchanged.

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 2, Part C Page 712
Link Manager Protocol Specification

Adaptive Frequency Hopping shall follow the procedures described in [Vol 2] Part B,
Section 8.6.5. The default value for Max_Slots shall be used.

A role switch, whether successful or failed, does not affect the state of the Link Manager
and of the ACL-C and ACL-U logical links except where explicitly stated.

4.5 Modes of operation

4.5.1 Hold mode

The ACL logical transport of a connection between two Bluetooth devices can be placed
in Hold mode for a specified hold time. See [Vol 2] Part B, Section 8.8 for details.

M/O PDU Contents

O(6) LMP_HOLD Hold_Time, Hold_Instant
O(6) LMP_HOLD_REQ Hold_Time, Hold_Instant

Table 4.32: Hold mode PDUs

The LMP_HOLD and LMP_HOLD_REQ PDUs both contain a parameter, Hold_Instant,

that specifies the instant at which the hold becomes effective. This is specified as a
Bluetooth clock value of the Central's clock, that is available to both devices. The hold
instant is chosen by the sender of the message and should be at least 6×Tpoll slots in
the future. The hold instant shall be within 12 hours of the current clock value to avoid
clock wrap.

4.5.1.1 Central forces Hold mode

The Central may force Hold mode if there has previously been a request for Hold mode
that has been accepted by the Peripheral. The hold time included in the PDU when
the Central forces Hold mode shall not be longer than any hold time the Peripheral has
previously accepted when there was a request for Hold mode.

The Central LM shall first pause traffic on the ACL-U logical link (see [Vol 2] Part B,
Section 5.3.1). It shall select the hold instant and queue the LMP_HOLD PDU to its
LC for transmission. It shall then start a timer to wait until the hold instant occurs.
When this timer expires then the connection shall enter Hold mode. If the Baseband
acknowledgment for the LMP_HOLD PDU is not received then the Central may enter
Hold mode, but it shall not use its low accuracy clock during the hold.

When the Peripheral LM receives an LMP_HOLD PDU it compares the hold instant with
the Central's current clock value. If it is in the future then it starts a timer to expire at this
instant and enters Hold mode when it expires.

When the Central LM exits from Hold mode it re-enables transmission on the ACL-U
logical link.

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 2, Part C Page 713
Link Manager Protocol Specification

Central Peripheral
LM LM
LMP_HOLD

Sequence 86: Central forces Peripheral into Hold mode

4.5.1.2 Peripheral forces Hold mode

The Peripheral may force Hold mode if there has previously been a request for Hold
mode that has been accepted by the Central. The hold time included in the PDU when
the Peripheral forces Hold mode shall not be longer than any hold time the Central has
previously accepted when there was a request for Hold mode.

The Peripheral LM shall first complete the transmission of the current packet on the
ACL logical transport and then shall suspend transmission on the ACL-U logical link. It
shall select the hold instant and queue the LMP_HOLD PDU to its LC for transmission.
It shall then wait for an LMP_HOLD PDU from the Central acting according to the
procedure described in Section 4.5.1.1.

When the Central LM receives an LMP_HOLD PDU it shall pause traffic on the ACL-U
logical link (see [Vol 2] Part B, Section 5.3.1). It shall then inspect the hold instant. If
this is less than 6×Tpoll slots in the future it shall modify the instant so that it is at least
6×Tpoll slots in the future. It shall then send an LMP_HOLD PDU using the mechanism
described in Section 4.5.1.1.

When the Central and Peripheral LMs exit from Hold mode they shall re-enable
transmission on the ACL-U logical link.

Central Peripheral
LM LM
LMP_HOLD

LMP_HOLD

Sequence 87: Peripheral forces Central into Hold mode

4.5.1.3 Central or Peripheral requests Hold mode

The Central or the Peripheral may request to enter Hold mode. Upon receipt of the
request, the same request with modified parameters may be returned or the negotiation
may be terminated. If an agreement is seen an LMP_ACCEPTED PDU terminates the
negotiation and the ACL link is placed in Hold mode. If no agreement is seen, an

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 2, Part C Page 714
Link Manager Protocol Specification

LMP_NOT_ACCEPTED PDU with the Error_Code Unsupported LMP Parameter Value

(0x20) terminates the negotiation and Hold mode is not entered.

The initiating LM shall pause traffic on the ACL-U logical link (see [Vol 2] Part B,
Section 5.3.1). On receiving an LMP_HOLD_REQ PDU the receiving LM shall complete
the transmission of the current packet on the ACL logical transport and then shall
suspend transmission on the ACL-U logical link.

The LM sending the LMP_HOLD_REQ PDU selects the hold instant, that shall be at
least 9×Tpoll slots in the future. If this is a response to a previous LMP_HOLD_REQ
PDU and the contained hold instant is at least 9×Tpoll slots in the future then this shall
be used. The LMP_HOLD_REQ PDU shall then be queued to its LC for transmission
and a timer shall be started to expire at this instant and the connection enters Hold
mode when it expires unless an LMP_NOT_ACCEPTED or LMP_HOLD_REQ PDU is
received by its LM before that point. If the LM receiving LMP_HOLD_REQ PDU agrees
to enter Hold mode it shall return an LMP_ACCEPTED PDU and shall start a timer to
expire at the hold instant. When this timer expires it enters Hold mode.

When each LM exits from Hold mode it shall re-enable transmission on the ACL-U
logical link.

Initiating
LM
LM
LMP_HOLD_REQ

LMP_HOLD_REQ

LMP_HOLD_REQ

LMP_ACCEPTED or LMP_NOT_ACCEPTED

Sequence 88: Negotiation for Hold mode

4.5.2 [This section is no longer used]

4.5.3 Sniff mode

To enter Sniff mode, Central and Peripheral negotiate a sniff interval TSniff and a sniff
offset, DSniff, that specifies the timing of the sniff slots. The offset determines the time of
the first sniff slot; after that the sniff slots follow periodically with the sniff interval TSniff.
To avoid clock wrap-around during the initialization, one of two options is chosen for the
calculation of the first sniff slot. The Timing_Control_Flags parameter in the sniff request
message indicates this.

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 2, Part C Page 715
Link Manager Protocol Specification

When the ACL logical transport is in Sniff mode the Central shall only start a
transmission in the sniff slots. Two parameters control the listening activity in the
Peripheral: the Sniff_Attempt and the Sniff_Timeout. The Sniff_Attempt parameter
determines for how many slots the Peripheral shall listen when the Peripheral is not
treating this as a scatternet link, beginning at the sniff slot, even if it does not receive a
packet with its own LT_ADDR. The Sniff_Timeout parameter determines for how many
additional slots the Peripheral shall listen when the Peripheral is not treating this as a
scatternet link if it continues to receive only packets with its own LT_ADDR. It is not
possible to modify the sniff parameters while the device is in Sniff mode.

4.5.3.1 Central or Peripheral requests Sniff mode

Either the Central or the Peripheral may request entry to Sniff mode. The process
is initiated by sending an LMP_SNIFF_REQ PDU containing a set of parameters.
The receiving LM shall then decide whether to reject the attempt by sending an
LMP_NOT_ACCEPTED PDU, to suggest different parameters by replying with an
LMP_SNIFF_REQ PDU or to accept the request.

M/O PDU Contents

O(7) LMP_SNIFF_REQ Timing_Control_Flags
DSniff
TSniff
Sniff_Attempt
Sniff_Timeout
O(7) LMP_UNSNIFF_REQ -
O(41) LMP_SNIFF_SUBRATING_REQ Max_Sniff_Subrate
Min_Sniff_Mode_Timeout
Sniff_Subrating_Instant
O(41) LMP_SNIFF_SUBRATING_RES Max_Sniff_Subrate
Min_Sniff_Mode_Timeout
Sniff_Subrating_Instant
Table 4.33: Sniff mode PDUs

Before the first time that the Central sends LMP_SNIFF_REQ in a transaction it shall
enter Sniff Transition mode. If the Central receives or sends an LMP_NOT_ACCEPTED
PDU it shall exit from Sniff Transition mode.

If the Central receives an LMP_SNIFF_REQ PDU it shall enter Sniff Transition mode (if
not already in it) and then determine whether to accept the request. The Central may
reply with an LMP_NOT_ACCEPTED PDU or, if it can enter Sniff mode but requires a
different set of parameters, it shall respond with an LMP_SNIFF_REQ PDU containing
the new parameters. If the Central decides that the parameters are acceptable then it

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 2, Part C Page 716
Link Manager Protocol Specification

shall send an LMP_ACCEPTED PDU; when it receives the Baseband acknowledgment

for this PDU it shall exit Sniff Transition mode and enter Sniff mode.

If the Central receives an LMP_ACCEPTED PDU the Central shall exit from Sniff
Transition mode and enter Sniff mode.

If the Peripheral receives an LMP_SNIFF_REQ PDU it shall determine whether to

accept the request. The Peripheral may reply with an LMP_NOT_ACCEPTED PDU
to reject the request or, if it can enter Sniff mode but requires a different set of
parameters, it shall respond with an LMP_SNIFF_REQ PDU containing the new
parameters. If the Peripheral decides that the parameters are acceptable then it shall
send an LMP_ACCEPTED PDU and enter Sniff mode. If the Peripheral receives an
LMP_NOT_ACCEPTED PDU it shall terminate the attempt to enter Sniff mode.

Initiating
LM
LM
LMP_SNIFF_REQ

LMP_SNIFF_REQ

LMP_SNIFF_REQ

LMP_ACCEPTED or LMP_NOT_ACCEPTED

Sequence 89: Negotiation for Sniff mode

4.5.3.2 Moving a Peripheral from Sniff mode to Active mode

Sniff mode may be exited by either the Central or the Peripheral sending an
LMP_UNSNIFF_REQ PDU. The requested device shall reply with an LMP_ACCEPTED
PDU.

If the Central requests an exit from Sniff mode it shall enter Sniff Transition mode
and then send an LMP_UNSNIFF_REQ PDU. When the Peripheral receives the
LMP_UNSNIFF_REQ it shall exit from Sniff mode and reply with an LMP_ACCEPTED
PDU. When the Central receives the LMP_ACCEPTED PDU it shall exit from Sniff
Transition mode and enter Active mode.

If the Peripheral requests an exit from Sniff mode it shall send an LMP_UNSNIFF_REQ
PDU. When the Central receives the LMP_UNSNIFF_REQ PDU it shall enter Sniff
Transition mode and then send an LMP_ACCEPTED PDU. When the Peripheral
receives the LMP_ACCEPTED PDU it shall exit from Sniff mode and enter Active mode.
When the Central receives the Baseband acknowledgment for the LMP_ACCEPTED
PDU it shall leave Sniff Transition mode and enter Active mode.

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 2, Part C Page 717
Link Manager Protocol Specification

Initiating
LM
LM
LMP_UNSNIFF_REQ

LMP_ACCEPTED

Sequence 90: Peripheral moved from Sniff mode to Active mode

4.5.3.3 Sniff subrating

Once Sniff mode has been started, sniff subrating may be initiated by either Link
Manager.

The LMP_SNIFF_SUBRATING_REQ and LMP_SNIFF_SUBRATING_RES PDUs

specify parameters that the peer and initiating device shall use respectively for sniff
subrating.

The Sniff_Subrating_Instant value shall be used to calculate the first sniff subrating
anchor point. The Sniff_Subrating_Instant value shall be a maximum of 216 time slots
(40.9 seconds) from the Central's current clock and shall be a sniff anchor point. The
Sniff_Subrating_Instant value should indicate a clock value in the future with respect to
the clock value when the LMP message is first sent.

If the LMP_SNIFF_SUBRATING_REQ PDU is sent by the Central, the

Sniff_Subrating_Instant value shall be used. The Peripheral shall reply with an
LMP_SNIFF_SUBRATING_RES PDU using the same Sniff_Subrating_Instant value
given by the Central.

When the LMP_SNIFF_SUBRATING_REQ PDU is sent by the Peripheral, the

Sniff_Subrating_Instant value shall be ignored. The Central shall reply with an
LMP_SNIFF_SUBRATING_RES PDU with the Sniff_Subrating_Instant value that shall
be used for sniff subrating.

The initiating device shall not transition to the new sniff subrating parameters until
the sniff subrating instant has passed and the LMP_SNIFF_SUBRATING_RES PDU
has been received. The non-initiating device shall remain in Sniff mode and shall not
transition to the new sniff subrating parameters until after the sniff subrating instant
has passed and the Baseband acknowledgment of the LMP_SNIFF_SUBRATING_RES
PDU has been received.

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 2, Part C Page 718
Link Manager Protocol Specification

Initiating
LM
LM
LMP_SNIFF_SUBRATING_REQ

LMP_SNIFF_SUBRATING_RES

Sequence 91: LM accepts sniff subrating request

A device shall not send a new LMP_SNIFF_SUBRATING_REQ PDU until the previous
sniff subrating transaction has completed and the sniff subrating instant has passed.

The maximum clock interval between two sniff subrating anchor points shall
be less than the link supervision timeout. If the link supervision timeout needs
to be updated to a shorter value than the clock interval between two sniff
subrating anchor points, the Central shall disable sniff subrating, shall send the
LMP_SUPERVISION_TIMEOUT PDU with the new supervision timeout value, and
shall start using the new supervision timeout value after receiving a Baseband
acknowledgment for the LMP_SUPERVISION_TIMEOUT PDU. Upon reception of the
LMP_SUPERVISION_TIMEOUT PDU the Peripheral shall disable sniff subrating and
shall start using the new supervision timeout value.

The Central shall initiate sniff subrating with the Max_Sniff_Subrate parameter
less than the new supervision timeout. The Peripheral shall respond with the
LMP_SNIFF_SUBRATING_RES PDU with the Max_Sniff_Subrate parameter less than
the new supervision timeout.

4.6 Logical transports

When a connection is first established between two devices the connection consists of
the ACL logical transport (carrying the ACL-C logical link for LMP messages and the
ACL-U logical link for L2CAP data) and the APB logical transport carrying the APB-C
logical links for LMP messages and the APB-U logical link for L2CAP data. One or
more synchronous logical transports (SCO or eSCO) may then be added. A new logical
transport shall not be created if it would cause all slots to be allocated to reserved slots
on secondary LT_ADDRs.

4.6.1 SCO logical transport

The SCO logical transport reserves slots separated by the SCO interval, Tsco. The
first slot reserved for the SCO logical transport is defined by Tsco and the SCO offset,
Dsco. See [Vol 2] Part B, Section 8.6.2 for details. A device shall initiate a request for
HV2 or HV3 packet type only if the other device supports that type. A device shall
initiate CVSD, μ-law or A-law coding or uncoded (transparent) data only if the other
device supports the corresponding feature. To avoid problems with a wrap-around of

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 2, Part C Page 719
Link Manager Protocol Specification

the clock during initialization of the SCO logical transport, the Timing_Control_Flags
parameter is used to indicate how the first SCO slot shall be calculated. The SCO link is
distinguished from all other SCO links by a SCO handle. The SCO handle zero shall not
be used.

The Link Manager shall not initiate a SCO connection, and shall reject any request for a
SCO connection, while AES-CCM encryption is in use.

Note: The Peripheral interprets the initialization flag in the Timing_Control_Flags in

terms of the Central’s Bluetooth clock. See [Vol 2] Part B, Section 8.6.2.

M/O PDU Contents

O(11) LMP_SCO_LINK_REQ SCO_Handle
Timing_Control_Flags
Dsco
Tsco
SCO_Packet
Air_Mode
O(11) LMP_REMOVE_SCO_LINK_REQ SCO_Handle
Error_Code
Table 4.34: SCO link management PDUs

4.6.1.1 Central initiates a SCO link

When establishing a SCO link the Central sends a request, a LMP_SCO_LINK_REQ

PDU, with parameters that specify the timing, packet type and coding that will be used
on the SCO link. Each of the SCO packet types supports three different voice coding
formats on the air-interface: µ-law log PCM, A-law log PCM and CVSD. The air coding
by log PCM or CVSD may be deactivated to achieve a transparent synchronous data
link at 64 kb/s.

The slots used for the SCO links are determined by three parameters controlled by the
Central: Tsco, Dsco and a flag indicating how the first SCO slot is calculated. After the
first slot, the SCO slots follow periodically at an interval of Tsco.

If the Peripheral does not accept the SCO link, but can operate with a different set of
SCO parameters, it can indicate what it does not accept in the Error_Code parameter
of an LMP_NOT_ACCEPTED PDU. The Central may then issue a new request with
modified parameters.

The SCO handle in the message shall be different from existing SCO link(s).

If the SCO packet type is HV1 the LMP_ACCEPTED shall be sent using the DM1
packet.

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 2, Part C Page 720
Link Manager Protocol Specification

Central Peripheral
LM LM
LMP_SCO_LINK_REQ

LMP_ACCEPTED or LMP_NOT_ACCEPTED

Sequence 92: Central requests a SCO link

4.6.1.2 Peripheral initiates a SCO link

The Peripheral may initiate the establishment of a SCO link. The Peripheral
sends an LMP_SCO_LINK_REQ PDU with the SCO handle set to zero; the
Timing_Control_Flags parameter shall be ignored by the Central, while the DSCO
parameter should be set to 0. If the Central is not capable of establishing a SCO
link, it replies with an LMP_NOT_ACCEPTED PDU. Otherwise it sends back an
LMP_SCO_LINK_REQ PDU. This message includes the assigned SCO handle, Dsco
and the timing control flags. The Central should try to use the same parameters
as in the Peripheral request; if the Central cannot meet that request, it is allowed
to use other values. The Peripheral shall then reply with LMP_ACCEPTED or
LMP_NOT_ACCEPTED PDU.

If the SCO packet type is HV1 the LMP_ACCEPTED shall be sent using the DM1
packet.

Central Peripheral
LM LM
LMP_SCO_LINK_REQ

LMP_NOT_ACCEPTED

Sequence 93: Central rejects Peripheral’s request for a SCO link

Central Peripheral
LM LM
LMP_SCO_LINK_REQ

LMP_SCO_LINK_REQ

LMP_ACCEPTED or LMP_NOT_ACCEPTED

Sequence 94: Central accepts Peripheral’s request for a SCO link

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 2, Part C Page 721
Link Manager Protocol Specification

4.6.1.3 Central requests change of SCO parameters

The Central sends an LMP_SCO_LINK_REQ PDU, where the SCO_Handle is the

handle of the SCO link the Central wishes to change parameters for. If the Peripheral
accepts the new parameters, it replies with an LMP_ACCEPTED PDU and the SCO
link will change to the new parameters. If the Peripheral does not accept the new
parameters, it shall reply with an LMP_NOT_ACCEPTED PDU and the SCO link is left
unchanged. When the Peripheral replies with an LMP_NOT_ACCEPTED PDU it shall
indicate in the Error_Code parameter what it does not accept. The Central may then try
to change the SCO link again with modified parameters. The sequence is the same as
in Section 4.6.1.1.

4.6.1.4 Peripheral requests change of SCO parameters

The Peripheral sends an LMP_SCO_LINK_REQ PDU, where the SCO_Handle is

the handle of the SCO link to be changed. The parameters Timing_Control_Flags
and Dsco in this PDU shall be ignored by the Central. If the Central does not
accept the new parameters it shall reply with an LMP_NOT_ACCEPTED PDU and
the SCO link is left unchanged. If the Central accepts the new parameters it shall
reply with an LMP_SCO_LINK_REQ PDU containing the same parameters as in
the Peripheral request. When receiving this message the Peripheral replies with an
LMP_NOT_ACCEPTED PDU if it does not accept the new parameters. The SCO link
is then left unchanged. If the Peripheral accepts the new parameters it replies with
an LMP_ACCEPTED PDU and the SCO link will change to the new parameters. The
sequence is the same as in Section 4.6.1.2.

4.6.1.5 Remove a SCO link

The Central or Peripheral may remove the SCO link by sending a request including the
SCO handle of the SCO link to be removed and an Error_Code indicating why the SCO
link is removed. The receiving side shall respond with an LMP_ACCEPTED PDU.

Initiating
LM
LM
LMP_REMOVE_SCO_LINK_REQ

LMP_ACCEPTED

Sequence 95: SCO link removed

4.6.2 eSCO logical transport

After an ACL link has been established, one or more extended SCO (eSCO) links
can be set up to the remote device. The eSCO links are similar to SCO links using

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 2, Part C Page 722
Link Manager Protocol Specification

timing control flags, an interval TeSCO and an offset DeSCO. As opposed to SCO links,
eSCO links have a configurable data rate that may be asymmetric, and can be set up
to provide limited retransmissions of lost or damaged packets inside a retransmission
window of size WeSCO. The DeSCO shall be based on CLK.

Note: The Peripheral interprets the initialization flag in the Timing_Control_Flags in

terms of the Central’s Bluetooth clock. See [Vol 2] Part B, Section 8.6.2.

The parameters DeSCO, TeSCO, WeSCO, eSCO_Packet_Type C→P, eSCO_Packet_Type

P→C, Packet_Length C→P, Packet_Length P→C are henceforth referred to as the
negotiable parameters.

M/O PDU Contents

eSCO_Handle
eSCO_LT_ADDR
Timing_Control_Flags
DeSCO
TeSCO
WeSCO
O(31) LMP_eSCO_LINK_REQ
eSCO_Packet_Type C→P
eSCO_Packet_Type P→C
Packet_Length C→P
Packet_Length P→C
Air_Mode
Negotiation_State
eSCO_Handle
O(31) LMP_REMOVE_eSCO_LINK_REQ
Error_Code

Table 4.35: PDUs used for managing the eSCO links

4.6.2.1 Central initiates an eSCO link

When establishing an eSCO link the Central sends an LMP_eSCO_LINK_REQ

PDU specifying all parameters. The Peripheral may accept this with an
LMP_ACCEPTED_EXT PDU, reject it with an LMP_NOT_ACCEPTED_EXT PDU, or
respond with its own LMP_eSCO_LINK_REQ specifying alternatives for some or all
parameters. The Peripheral shall not negotiate the eSCO_Handle or eSCO_LT_ADDR
parameters. The negotiation of parameters continues until the Central or Peripheral
either accepts the latest parameters with an LMP_ACCEPTED_EXT PDU, or terminates
the negotiation with an LMP_NOT_ACCEPTED_EXT PDU. The negotiation shall use
the procedures defined in Section 4.6.2.5.

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 2, Part C Page 723
Link Manager Protocol Specification

Central Peripheral
LM LM
LMP_eSCO_LINK_REQ

LMP_eSCO_LINK_REQ

LMP_eSCO_LINK_REQ

LMP_ACCEPTED_EXT or LMP_NOT_ACCEPTED_EXT

Sequence 96: Central requests an eSCO link

4.6.2.2 Peripheral initiates an eSCO link

When attempting to establish an eSCO link the Peripheral shall send an

LMP_eSCO_LINK_REQ PDU specifying all parameters except eSCO_LT_ADDR, which
is reserved for future use, and eSCO_Handle, which shall be set to zero. The
Central may respond to this with an LMP_eSCO_LINK_REQ PDU, filling in these
missing parameters, and potentially changing the other requested parameters. The
Peripheral can accept this with an LMP_ACCEPTED_EXT PDU, or respond with a
further LMP_eSCO_LINK_REQ PDU specifying alternatives for some or all of the
parameters. The negotiation of parameters continues until the Central or Peripheral
either accepts the latest parameters with an LMP_ACCEPTED_EXT PDU, or terminates
the negotiation with an LMP_NOT_ACCEPTED_EXT PDU.

Central Peripheral
LM LM
LMP_eSCO_LINK_REQ

LMP_eSCO_LINK_REQ

LMP_eSCO_LINK_REQ

LMP_ACCEPTED_EXT or LMP_NOT_ACCEPTED_EXT

Sequence 97: Peripheral requests an eSCO link

The Central may reject the request immediately with an LMP_NOT_ACCEPTED_EXT

PDU. The negotiation shall use the procedures defined in Section 4.6.2.5.

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 2, Part C Page 724
Link Manager Protocol Specification

Central Peripheral
LM LM
LMP_eSCO_LINK_REQ

LMP_NOT_ACCEPTED_EXT

Sequence 98: Central rejects Peripheral’s request for an eSCO link

4.6.2.3 Central or Peripheral requests change of eSCO parameters

The Central or Peripheral may request a renegotiation of the eSCO parameters. The
Central or Peripheral shall send an LMP_eSCO_LINK_REQ PDU with the eSCO handle
of the eSCO link the device wishes to renegotiate. The remote device may accept the
changed parameters immediately with LMP_ACCEPTED_EXT PDU, or the negotiation
may be continued with further LMP_eSCO_LINK_REQ PDUs until the Central or
Peripheral accepts the latest parameters with an LMP_ACCEPTED_EXT PDU or
terminates the negotiation with an LMP_NOT_ACCEPTED_EXT PDU. In the case of
termination with an LMP_NOT_ACCEPTED_EXT PDU, the eSCO link continues on the
previously negotiated parameters.

The sequence is the same as in Section 4.6.2.2.

During re-negotiation, the eSCO LT_ADDR and eSCO handle shall not be re-negotiated
and shall be set to the originally negotiated values. The negotiation shall use the
procedures defined in Section 4.6.2.5.

4.6.2.4 Remove an eSCO link

Either the Central or Peripheral may remove the eSCO link by sending
an LMP_REMOVE_eSCO_LINK_REQ PDU including the eSCO handle of the
eSCO link to be removed and an Error_Code indicating why the eSCO link
is removed. The receiving side shall respond with an LMP_ACCEPTED_EXT
PDU. The Peripheral shall shut down its eSCO logical transport before
sending its PDU (LMP_REMOVE_eSCO_LINK_REQ for Peripheral initiated removal,
LMP_ACCEPTED_EXT for Central initiated). The Central shall not reassign the eSCO
LT_ADDR until the end of the removal procedure. If, for some reason, such as the
Peripheral being out of range, the procedure cannot be completed, the Central shall
not reassign the eSCO LT_ADDR until the primary LT_ADDR is available for reuse
(supervision timeout).

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 2, Part C Page 725
Link Manager Protocol Specification

Initiating
LM
LM
LMP_REMOVE_eSCO_LINK_REQ

LMP_ACCEPTED_EXT

Sequence 99: eSCO link removed

4.6.2.5 Rules for the LMP negotiation and renegotiation

Rule 1: the Negotiation_State shall be set to 0 by the initiating LM. After the initial
LMP_eSCO_LINK_REQ is sent the Negotiation_State shall not be set to 0.

Rule 2: if the bandwidth (defined as 1600 times the packet length in bytes divided by
TeSCO in slots) for either RX or TX or the Air_Mode cannot be accepted the device shall
send LMP_NOT_ACCEPTED_EXT with the appropriate Error_Code.

Rule 3: Bandwidth and Air_Mode are not negotiable and shall not be changed
for the duration of the negotiation. Once one side has rejected the negotiation
(with LMP_NOT_ACCEPTED_EXT) a new negotiation may be started with different
bandwidth and Air_Mode parameters.

Rule 4: if the parameters will cause a latency violation (TeSCO + WeSCO + reserved
synchronous slots > allowed local latency) the device should propose new parameters
that shall not cause a reserved slot violation or latency violation for the device that is
sending the parameters. In this case the Negotiation_State shall be set to 3. Otherwise
the device shall send LMP_NOT_ACCEPTED_EXT.

Rule 5: once a device has received an LMP_eSCO_LINK_REQ with the

Negotiation_State set to 3 (latency violation), the device shall not propose any
combination of packet type, TeSCO, and WeSCO that will give an equal or larger latency
than the combination that caused the latency violation for the other device.

Rule 6: if the parameters cause both a reserved slot violation and a latency violation or
if the parameters are not supported and a latency violation occurs, then the device shall
set the Negotiation_State to 3 (latency violation).

Rule 7: if the parameters will cause a reserved slot violation the device should
propose new parameters that shall not cause a reserved slot violation. In this
case the Negotiation_State shall be set to 2. Otherwise the device shall send
LMP_NOT_ACCEPTED_EXT.

Rule 8: If the requested parameters are not supported the device should propose a
setting that is supported, and set the Negotiation_State to 4. If it is not possible to find
such a parameter set, the device shall send LMP_NOT_ACCEPTED_EXT.

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 2, Part C Page 726
Link Manager Protocol Specification

Rule 9: when proposing new parameters for reasons other than a latency violation,
reserved slot violation, or configuration not supported, the Negotiation_State shall be
set to 1.

4.6.2.6 Negotiation state definitions

Reserved Slot Violation: a reserved slot violation is when the receiving LM cannot
setup the requested eSCO logical transport because the eSCO reserved slots would
overlap with other regularly scheduled slots (e.g. other synchronous reserved slots or
sniff anchor points).

Latency Violation: a latency violation is when the receiving LM cannot setup the
requested eSCO logical transport because the latency (WeSCO+TeSCO + reserved
synchronous slots) is greater than the maximum allowed latency.

Configuration not supported: The combination of parameters requested is not inside the
supported range for the device.

4.7 Test mode

LMP has PDUs to support testing of the Bluetooth radio and Baseband. See [Vol 3] Part
D, Section 1 for a detailed description of these test modes.

4.7.1 Activation and deactivation of Test mode

The activation may be carried out locally (via a HW or SW interface), or using the air
interface.

• For activation over the air interface, entering the test mode shall be locally enabled for
security and type approval reasons. The implementation of this local enabling is not
subject to standardization.
The tester sends an LMP command that shall force the IUT to enter test mode. The
IUT shall terminate all normal operation before entering the test mode.
The IUT shall return an LMP_ACCEPTED PDU on reception of an activation
command. An LMP_NOT_ACCEPTED PDU shall be returned if the IUT is not locally
enabled.
• If the activation is performed locally using a HW or SW interface, the IUT shall
terminate all normal operation before entering the test mode.
Until a connection to the tester exists, the device shall perform page scan and inquiry
scan. Extended scan activity is recommended.

The test mode is activated by sending an LMP_TEST_ACTIVATE PDU to the

implementation under test (IUT). The IUT is always the Peripheral. The LM shall be
able to receive this message at any time. If entering test mode is locally enabled in

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 2, Part C Page 727
Link Manager Protocol Specification

the IUT, then it shall respond with an LMP_ACCEPTED PDU and test mode is entered.
Otherwise the IUT responds with an LMP_NOT_ACCEPTED PDU and the IUT remains
in normal operation. The Error_Code in the LMP_NOT_ACCEPTED PDU shall be LMP
PDU Not Allowed (0x24).

Central Peripheral
LM LM
LMP_TEST_ACTIVATE

LMP_ACCEPTED

Sequence 100: Activation of test mode successful

Central Peripheral
LM LM
LMP_TEST_ACTIVATE

LMP_NOT_ACCEPTED

Sequence 101: Activation of Test mode fails. Peripheral is not allowed to enter Test mode.

The test mode can be deactivated in two ways. Sending an LMP_TEST_CONTROL

PDU with Test_Scenario set to "exit test mode" exits the test mode and the Peripheral
returns to normal operation still connected to the Central. Sending an LMP_DETACH
PDU to the IUT ends the test mode and the connection.

4.7.2 Control of Test mode

Control and configuration is performed using special LMP commands (see

Section 4.7.3). These commands shall be rejected if the Bluetooth device is not in test
mode. In this case, an LMP_NOT_ACCEPTED shall be returned. The IUT shall return
an LMP_ACCEPTED on reception of a control command when in test mode.

A Bluetooth device in test mode shall ignore all LMP commands not related to control
of the test mode. LMP commands dealing with power control and the request for LMP
features (LMP_FEATURES_REQ), and adaptive frequency hopping (LMP_SET_AFH,
LMP_CHANNEL_CLASSIFICATION_REQ and LMP_CHANNEL_CLASSIFICATION)
are allowed in test mode; the normal procedures are also used to test the adaptive
power control.

The IUT shall leave the test mode when an LMP_DETACH command is received or an
LMP_TEST_CONTROL command is received with Test_Scenario set to 'exit test mode'.

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 2, Part C Page 728
Link Manager Protocol Specification

When the IUT has entered test mode, the LMP_TEST_CONTROL PDU can be sent to
the IUT to start a specific test. This PDU is acknowledged with an LMP_ACCEPTED
PDU. If a device that is not in test mode receives an LMP_TEST_CONTROL PDU, then
it responds with an LMP_NOT_ACCEPTED PDU, where the Error_Code shall be LMP
PDU Not Allowed (0x24).

Central Peripheral
LM LM
LMP_TEST_CONTROL

LMP_ACCEPTED

Sequence 102: Control of Test mode successful

Central Peripheral
LM LM
LMP_TEST_CONTROL

LMP_NOT_ACCEPTED

Sequence 103: Control of Test mode rejected since Peripheral is not in Test mode

4.7.3 Summary of Test mode PDUs

Table 4.36 lists all LMP messages used for test mode. To ensure that the contents
of the LMP_TEST_CONTROL PDU are suitably whitened (important when sent in
transmitter mode), all parameters listed in Table 4.37 are XORed with 0x55 before being
sent.

PDU Possible Position in

LMP PDU number Direction Contents Payload
LMP_TEST_ACTIVATE 56 C→P none
LMP_TEST_CONTROL 57 C→P Test_Scenario 2
Hopping_Mode 3
Tx_Frequency 4
Rx_Frequency 5
Power_Mode 6
Poll_Period 7
Packet_Type 8
Test_Data_Length 9-10

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 2, Part C Page 729
Link Manager Protocol Specification

PDU Possible Position in

LMP PDU number Direction Contents Payload
LMP_DETACH 7 C→P none
LMP_ACCEPTED 3 C←P none
LMP_NOT_ACCEPTED 4 C←P none

Table 4.36: LMP messages used for Test mode

Length
Name (bytes) Type Detailed
Test_Scenario 1 uint8 0 Pause Test Mode
1 Transmitter test – 0 pattern
2 Transmitter test – 1 pattern
3 Transmitter test – 1010 pattern
4 Pseudorandom bit sequence
5 Closed Loop Back – ACL packets
6 Closed Loop Back – Synchronous packets
7 ACL packets without whitening
8 Synchronous packets without whitening
9 Transmitter test – 1111 0000 pattern
10–254 Reserved for future use
255 Exit Test Mode
The value is XORed with 0x55.
Hopping_Mode 1 uint8 0 RX/TX on single frequency
1 Normal hopping
2–255 Reserved for future use
The value is XORed with 0x55.
Tx_Frequency 1 uint8 f = [2402 + k] MHz
The value is XORed with 0x55.
Rx_Frequency 1 uint8 f = [2402 + k] MHz
The value is XORed with 0x55.
Power_Mode 1 uint8 0 fixed TX output power
1 adaptive power control
The value is XORed with 0x55.
Poll_Period 1 uint8 Unit: 1.25 ms
The value is XORed with 0x55.

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 2, Part C Page 730
Link Manager Protocol Specification

Length
Name (bytes) Type Detailed
Packet_Type 1 uint8 Bits 3-0
numbering as in packet header, see [Vol 2]
Part B, Section 6.4.2
Bits 7-4
0: ACL/SCO
1: eSCO
2: Enhanced Data Rate ACL
3: Enhanced Data Rate eSCO
4-15: Reserved for future use
The value is XORed with 0x55.
Test_Data_Length 2 uint16 This is equal to the length of user data in
[Vol 2] Part B, Section 6.5, in bytes, exclud-
ing the payload header and CRC if present
in the relevant type of packet.
The value is XORed with 0x5555.

Table 4.37: Parameters used in LMP_TEST_CONTROL PDU

The control PDU is used for both transmitter and loop back tests. The following
restrictions apply for the parameter settings:

Parameter Restrictions Transmitter Test Restrictions Loopback Test

Tx_Frequency 0 ≤ k ≤ 78 0 ≤ k ≤ 78
Rx_Frequency same as Tx_Frequency 0 ≤ k ≤ 78
Poll_Period none not applicable (set to 0)
Test_Data_Length Depends on packet type. See [Vol 2] Part B, Ta- For ACL and SCO packets:
ble 6.8 and [Vol 2] Part B, Table 6.9 not applicable (set to 0)
For eSCO packets:
see [Vol 2] Part B, Table 6.8

Table 4.38: Restrictions on the parameters in the LMP_TEST_CONTROL PDU

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 2, Part C Page 731
Link Manager Protocol Specification

5 SUMMARY

5.1 PDU summary

Where the "Possible direction" column in Table 5.1 shows "B", the PDU is sent on the
APB-C logical link. All other PDUs are sent on the ACL-C logical link and only in the
direction(s) indicated.

Position
Length Packet Possible in
LMP PDU (bytes) Opcode type direction Contents payload
LMP_ACCEPTED 2 3 DM1/DV C↔P Opcode 2
LMP_ACCEPTED_- 4 127/01 DM1 C↔P Escape_Opcode 3
EXT
Extended_- 4
Opcode
LMP_AU_RAND 17 11 DM1 C↔P Random_Number 2–17
LMP_AUTO_RATE 1 35 DM1/DV C↔P none
LMP_CHANNEL_- 12 127/17 DM1 C←P AFH_Channel_- 3–12
CLASSIFICATION Classification
LMP_CHANNEL_- 7 127/16 DM1 C→P AFH_Reporting_- 3
CLASSIFICATION_- Mode
REQ
AFH_Min_Interval 4–5
AFH_Max_- 6–7
Interval
LMP_CLK_ADJ 15 127/5 DM1 B Clk_Adj_ID 3
Clk_Adj_Instant 4–7
Clk_Adj_Offset 8–9
Clk_Adj_Slots 10
Clk_Adj_Mode 11
Clk_Adj_Clk 12–15
LMP_CLK_ADJ_- 3 127/6 DM1 C←P Clk_Adj_ID 3
ACK
LMP_CLK_ADJ_- 6 127/7 DM1 C←P Clk_Adj_Offset 3–4
REQ
Clk_Adj_Slots 5
Clk_Adj_Period 6
LMP_CLKOFFSET_- 1 5 DM1/DV C→P none
REQ

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 2, Part C Page 732
Link Manager Protocol Specification

Position
Length Packet Possible in
LMP PDU (bytes) Opcode type direction Contents payload
LMP_CLKOFFSET_- 3 6 DM1/DV C←P Clock_Offset 2–3
RES
LMP_COMB_KEY 17 9 DM1 C↔P Random_Number 2–17
LMP_DECR_- 2 32 DM1/DV C↔P Reserved 2
POWER_REQ
LMP_DETACH 2 7 DM1/DV C↔P Error_Code 2
LMP_DHKEY_- 17 65 DM1 C↔P Confirmation_- 2–17
CHECK Value
LMP_- 4 61 DM1 C↔P Encap_Major_- 2
ENCAPSULATED_- Type
HEADER
Encap_Minor_- 3
Type
Encap_Payload_- 4
Length
LMP_- 17 62 DM1 C↔P Encap_Data 2–17
ENCAPSULATED_-
PAYLOAD
LMP_- 1 58 DM1 C→P none
ENCRYPTION_-
KEY_SIZE_MASK_-
REQ
LMP_- 3 59 DM1 C←P Key_Size_Mask 2–3
ENCRYPTION_-
KEY_SIZE_MASK_-
RES
LMP_- 2 16 DM1/DV C↔P Key_Size 2
ENCRYPTION_-
KEY_SIZE_REQ
LMP_- 2 15 DM1/DV C↔P Encryption_Mode 2
ENCRYPTION_-
MODE_REQ
LMP_eSCO_LINK_- 16 127/12 DM1 C↔P eSCO_Handle 3
REQ (see Note 1)
eSCO_LT_ADDR 4
Timing_Control_- 5
Flags
DeSCO 6
TeSCO 7
WeSCO 8

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 2, Part C Page 733
Link Manager Protocol Specification

Position
Length Packet Possible in
LMP PDU (bytes) Opcode type direction Contents payload
eSCO_Packet_- 9
Type C→P
eSCO_Packet_- 10
Type P→C
Packet_Length 11–12
C→P
Packet_Length 13–14
P→C
Air_Mode 15
Negotiation_State 16
LMP_FEATURES_- 9 39 DM1/DV C↔P Features 2–9
REQ
LMP_FEATURES_- 12 127/03 DM1 C↔P Features_Page 3
REQ_EXT
Max_Supported_- 4
Page
Extended_- 5–12
Features
LMP_FEATURES_- 9 40 DM1/DV C↔P Features 2–9
RES
LMP_FEATURES_- 12 127/04 DM1 C↔P Features_Page 3
RES_EXT
Max_Supported_- 4
Page
Extended_- 5–12
Features
LMP_HOLD 7 20 DM1/DV C↔P Hold_Time 2–3
Hold_Instant 4–7
LMP_HOLD_REQ 7 21 DM1/DV C↔P Hold_Time 2–3
Hold_Instant 4–7
LMP_HOST_- 1 51 DM1/DV C↔P none
CONNECTION_REQ
LMP_IN_RAND 17 8 DM1 C↔P Random_Number 2–17
LMP_INCR_- 2 31 DM1/DV C↔P Reserved 2
POWER_REQ
LMP_IO_- 5 127/25 DM1 C↔P IO_Capabilities 3
CAPABILITY_REQ
OOB_Auth_Data 4

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 2, Part C Page 734
Link Manager Protocol Specification

Position
Length Packet Possible in
LMP PDU (bytes) Opcode type direction Contents payload
Authentication_- 5
Requirements
LMP_IO_- 5 127/26 DM1 C↔P IO_Capabilities 3
CAPABILITY_RES
OOB_Auth_Data 4
Authentication_- 5
Requirements
LMP_KEYPRESS_- 3 127/30 DM1 C↔P Notification_Type 2
NOTIFICATION
LMP_MAX_POWER 1 33 DM1/DV C↔P none
LMP_MAX_SLOT 2 45 DM1/DV C↔P Max_Slots 2
LMP_MAX_SLOT_- 2 46 DM1/DV C↔P Max_Slots 2
REQ
LMP_MIN_POWER 1 34 DM1/DV C↔P none
LMP_NAME_REQ 2 1 DM1/DV C↔P Name_Offset 2
LMP_NAME_RES 17 2 DM1 C↔P Name_Offset 2
Name_Length 3
Name_Fragment 4–17
LMP_NOT_- 3 4 DM1/DV C↔P Opcode 2
ACCEPTED
Error_Code 3
LMP_NOT_- 5 127/02 DM1 C↔P Escape_Opcode 3
ACCEPTED_EXT
Extended_- 4
Opcode
Error_Code 5
LMP_NUMERIC_- 2 127/27 DM1 C↔P none
COMPARISON_-
FAILED
LMP_OOB_FAILED 2 127/29 DM1 C↔P none
LMP_PACKET_- 3 127/11 DM1 C↔P Packet_Type_- 3
TYPE_TABLE_REQ Table
LMP_PAGE_- 3 53 DM1/DV C↔P Paging_Scheme 2
MODE_REQ
Paging_- 3
Scheme_Settings
LMP_PAGE_- 3 54 DM1/DV C↔P Paging_Scheme 2
SCAN_MODE_REQ
Paging_- 3
Scheme_Settings

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 2, Part C Page 735
Link Manager Protocol Specification

Position
Length Packet Possible in
LMP PDU (bytes) Opcode type direction Contents payload
LMP_PASSKEY_- 2 127/28 DM1 C↔P none
FAILED
LMP_PAUSE_- 17 66 DM1 C↔P Random_Number 2–17
ENCRYPTION_-
AES_REQ
LMP_PAUSE_- 2 127/23 DM1 C↔P none
ENCRYPTION_REQ
LMP_PING_REQ 2 127/33 DM1 C↔P none
LMP_PING_RES 2 127/34 DM1 C↔P none
LMP_POWER_- 3 127/31 DM1/DV C↔P Power_Adj_Req 3
CONTROL_REQ
LMP_POWER_- 3 127/32 DM1/DV C↔P Power_Adj_Rsp 3
CONTROL_RES
LMP_PREFER- 2 36 DM1/DV C↔P Data_Rate 2
RED_RATE
LMP_QUALITY_- 4 41 DM1/DV C→P Poll_Interval 2–3
OF_SERVICE
NBC 4
LMP_QUALITY_- 4 42 DM1/DV C↔P Poll_Interval 2–3
OF_SERVICE_REQ
NBC 4
LMP_REMOVE_- 4 127/13 DM1 C↔P eSCO_Handle 3
eSCO_LINK_REQ
Error_Code 4
(see Note 1)

LMP_REMOVE_- 3 44 DM1/DV C↔P SCO_Handle 2

SCO_LINK_REQ
Error_Code 3
LMP_RESUME_- 2 127/24 DM1 C←P none
ENCRYPTION_REQ
LMP_SAM_- 17 127/36 DM1 C↔P SAM_Index 3
DEFINE_MAP
TSAM_SM 4
NSAM_SM 5
SAM_Submaps 6–17
LMP_SAM_SET_- 17 127/35 DM1 C↔P Update_Mode 3
TYPE0
SAM_Type0_- 4–17
Submap
LMP_SAM_SWITCH 9 127/37 DM1 C↔P SAM_Index 3

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 2, Part C Page 736
Link Manager Protocol Specification

Position
Length Packet Possible in
LMP PDU (bytes) Opcode type direction Contents payload
Timing_Control_- 4
Flags
DSAM 5
SAM_Instant 6–9
LMP_SCO_LINK_- 7 43 DM1/DV C↔P SCO_Handle 2
REQ
Timing_Control_- 3
Flags
Dsco 4
Tsco 5
SCO_Packet 6
Air_Mode 7
LMP_SET_AFH 16 60 DM1 C→P AFH_Instant 2–5
AFH_Mode 6
AFH_Channel_- 7–16
Map
LMP_SETUP_- 1 49 DM1 C↔P none
COMPLETE
LMP_SIMPLE_- 17 63 DM1 C↔P Commitment_- 2–17
PAIRING_CONFIRM Value
LMP_SIMPLE_- 17 64 DM1 C↔P Nonce_Value 2–17
PAIRING_NUMBER
LMP_SLOT_- 9 52 DM1/DV C↔P Slot_Offset 2–3
OFFSET
BD_ADDR 4–9
LMP_SNIFF_REQ 10 23 DM1 C↔P Timing_Control_- 2
Flags
DSniff 3–4
TSniff 5–6
Sniff_Attempt 7–8
Sniff_Timeout 9–10
LMP_SNIFF_- 9 127/21 DM1 C↔P Max_Sniff_- 3
SUBRATING_REQ Subrate
Min_Sniff_Mode_- 4–5
Timeout
Sniff_Subrating_- 6–9
Instant

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 2, Part C Page 737
Link Manager Protocol Specification

Position
Length Packet Possible in
LMP PDU (bytes) Opcode type direction Contents payload
LMP_SNIFF_- 9 127/22 DM1 C↔P Max_Sniff_- 3
SUBRATING_RES Subrate
Min_Sniff_Mode_- 4–5
Timeout
Sniff_Subrating_- 6–9
Instant
LMP_SRES 5 12 DM1/DV C↔P Authentication_- 2–5
Rsp
LMP_START_- 17 17 DM1 C→P Random_Number 2–17
ENCRYPTION_REQ
LMP_STOP_- 1 18 DM1/DV C→P none
ENCRYPTION_REQ
LMP_SUPERVI- 3 55 DM1/DV C→P Supervision_- 2–3
SION_TIMEOUT Timeout
LMP_SWITCH_REQ 5 19 DM1 C↔P Switch_Instant 2–5
LMP_TEMP_KEY 17 14 DM1 C→P Key 2–17
LMP_TEMP_RAND 17 13 DM1 C→P Random_Number 2–17
LMP_TEST_- 1 56 DM1/DV C→P none
ACTIVATE
LMP_TEST_- 10 57 DM1 C→P Test_Scenario 2
CONTROL
Hopping_Mode 3
Tx_Frequency 4
Rx_Frequency 5
Power_Mode 6
Poll_Period 7
Packet_Type 8
Test_Data_Length 9–10
LMP_TIMING_- 1 47 DM1/DV C↔P none
ACCURACY_REQ
LMP_TIMING_- 3 48 DM1/DV C↔P Drift 2
ACCURACY_RES
Jitter 3
LMP_UNIT_KEY 17 10 DM1 C↔P Key 2–17
LMP_UNSNIFF_- 1 24 DM1/DV C↔P none
REQ

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 2, Part C Page 738
Link Manager Protocol Specification

Position
Length Packet Possible in
LMP PDU (bytes) Opcode type direction Contents payload
LMP_USE_SEMI_- 1 50 DM1/DV C→P none
PERMANENT_KEY
LMP_VERSION_- 6 37 DM1/DV C↔P Version 2
REQ
Company_- 3–4
Identifier
Subversion 5–6
LMP_VERSION_- 6 38 DM1/DV C↔P Version 2
RES
Company_- 3–4
Identifier
Subversion 5–6

Table 5.1: Coding of the different LM PDUs

Note 1. Parameters coincide with their namesakes in LMP_SCO_LINK_REQ and

LMP_REMOVE_SCO_LINK_REQ apart from the following:

1. eSCO_LT_ADDR - the eSCO connection will be active on an additional LT_ADDR

that needs to be defined. The Central is not allowed to re-assign an active eSCO
link to a different LT_ADDR.
2. DeSCO, TeSCO - as per LMP_SCO_LINK_REQ but with a greater flexibility in values
(e.g. no longer fixed with respect to HV1, HV2, and HV3 packet choice).
3. WeSCO - the eSCO retransmission window size (in slots)
4. packet type and packet length may be prescribed differently in Central-to-
Peripheral or Peripheral-to-Central directions for asynchronous eSCO links
5. packet length (in bytes) - eSCO packet types no longer have fixed length
6. negotiation state – this is used to better enable the negotiation of the negotiable
parameters: DeSCO, TeSCO, WeSCO, eSCO_Packet_Type C→P, eSCO_Packet_Type
P→C, Packet_Length C→P, Packet_Length P→C. When responding to an eSCO
link request with a new suggestion for these parameters, this flag may be set to 1
to indicate that the last received negotiable parameters are possible, but the new
parameters specified in the response eSCO link request would be preferable, to 2
to indicate that the last received negotiable parameters are not possible as they
cause a reserved slot violation or to 3 to indicate that the last received negotiable
parameters would cause a latency violation. The flag is set to zero in the initiating
LMP_eSCO_LINK_REQ.

Note: The following opcodes were previously used: 22, 25 to 30. All other opcodes not
listed in Table 5.1 are reserved for future use.

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 2, Part C Page 739
Link Manager Protocol Specification

5.2 Parameter definitions

Where no mandatory range is given, the mandatory range consists of all valid values
that are not reserved for future use.

Length
(bytes)
Name Type Unit Detailed

Access_Scheme 1 uint4 0: polling technique

1-15: reserved for future use
AFH_Channel_Classification 10 uint2 [40] The nth (numbering from 0) element
defines the classification of channels
2n and 2n+1, other than the 39th ele-
ment which just contains the classifi-
cation of channel 78.
The value of each element indicates:
0 = unknown
1 = good
2 = reserved for future use
3 = bad
AFH_Channel_Map 10 uint1 [80] If AFH_Mode is not 1 (enabled), the
contents of this parameter are re-
served for future use. Otherwise:
The nth (numbering from 0) element
(in the range 0 to 78) contains the
value for channel n.
Element 79 is reserved for future
use.
The value of each element indicates:
0: channel n is unused
1: channel n is used
AFH_Instant 4 uint32 slots Bits 27:1 of the Central's clock value
at the time of switching hop sequen-
ces. Only even values are valid.
AFH_Max_Interval 2 uint16 slots Range is 0x0640 to 0xBB80 slots (1
to 30 s)
Only even values are valid
AFH_Min_Interval 2 uint16 slots Range is 0x0640 to 0xBB80 slots (1
to 30 s)
Only even values are valid

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 2, Part C Page 740
Link Manager Protocol Specification

Length
(bytes)
Name Type Unit Detailed

AFH_Mode 1 uint8 0: disabled

1: enabled
2-255: reserved for future use
AFH_Reporting_Mode 1 uint8 0: disabled
1: enabled
2-255: reserved for future use
Air_Mode 1 uint8 0: µ-law log
1: A-law log
2: CVSD
3: transparent data
4-255: reserved for future use
Authentication_Rsp 4 multiple
bytes
Authentication_- 1 uint8 0x00: MITM Protection Not Required
Requirements – No Bonding
0x01: MITM Protection Required –
No Bonding
0x02: MITM Protection Not Required
– Dedicated Bonding
0x03: MITM Protection Required –
Dedicated Bonding
0x04: MITM Protection Not Required
– General Bonding
0x05: MITM Protection Required –
General Bonding
0x06 to 0xFF: reserved for future use
BD_ADDR 6 multiple BD_ADDR of the sending device
bytes
Clk_Adj_Clk 4 uint32 slot pairs CLK[27:2] for the moment that the
PDU is transmitted.
Clk_Adj_ID 1 uint8 Clk_Adj_ID is chosen by the Central
as a handle to identify a Coarse
Clock Adjustment event.
Clk_Adj_Instant 4 uint32 slots CLKold[27:1] at the time of the coarse
clock adjustment, based on the val-
ue of time_base_offset before the
adjustment is made. Only even val-
ues are valid.

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 2, Part C Page 741
Link Manager Protocol Specification

Length
(bytes)
Name Type Unit Detailed

Clk_Adj_Mode 1 uint8 0: Before Instant

1: After Instant
2-255: reserved for future use
Clk_Adj_Offset 2 sint16 µs The offset between the old and new
slot boundaries. Valid range is ‒624
to +624.
Clk_Adj_Period 1 uint8 slots Indicates to the Central that adding
an integer multiple of this value to
Clk_Adj_Slots gives an equally ac-
ceptable adjustment. The value of
Clk_Adj_Period shall be zero or
an even number greater than
Clk_Adj_Slots. Only even values are
valid.
Clk_Adj_Slots 1 uint8 slots The difference between the clocks at
the adjustment instant
(i.e. CLKnew[27:1] - CLKold[27:1]).
Clock_Offset 2 uint15 1.25 ms (CLKN16-2 Peripheral -
CLKN16-2 Central) mod 215
Commitment_Value 16 uint128
Company_Identifier 2 uint16 see Assigned Numbers
Confirmation_Value 16 uint128

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 2, Part C Page 742
Link Manager Protocol Specification

Length
(bytes)
Name Type Unit Detailed

Data_Rate 1 uint8 When in Basic Rate mode:

bit 0 = 0: use FEC
bit 0 = 1: do not use FEC
bits 1-2=0: No packet-size prefer-
ence available
bits 1-2=1: use 1-slot packets
bits 1-2=2: use 3-slot packets
bits 1-2=3: use 5-slot packets
When in Enhanced Data Rate mode:
bits 3-4=0: use DM1 packets
bits 3-4=1: use 2 Mb/s packets
bits 3-4=2: use 3 Mb/s packets
bits 3-4=3: reserved for future use
bits 5-6=0: No packet-size prefer-
ence available
bits 5-6=1: use 1-slot packets
bits 5-6=2: use 3-slot packets
bits 5-6=3: use 5-slot packets
bit 7: reserved for future use
DeSCO 1 uint8 slots Only even values less than TeSCO
are valid
Drift 1 uint8 ppm
DSAM 1 uint8 slots Only even values less than TSAM are
valid
DSCO 1 uint8 slots Only even values less than TSCO are
valid
DSniff 2 uint16 slots Only even values less than TSniff are
valid
Encap_Data 16 Multiple MSBs zero padded when data is less
bytes than 16 bytes.
Little-endian format
Encap_Major_Type 1 uint8 See Table 5.4
Encap_Minor_Type 1 uint8 See Table 5.4
Encap_Payload_Length 1 uint8 See Table 5.4

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 2, Part C Page 743
Link Manager Protocol Specification

Length
(bytes)
Name Type Unit Detailed

Encryption_Mode 1 uint8 0: no encryption

1: encryption
2: previously used
3-255: reserved for future use
Error_Code 1 uint8 See [Vol 1] Part F
Escape_Opcode 1 uint8 Identifies which Escape_Opcode is
being acknowledged: range 124-127
eSCO_Handle 1 uint8
eSCO_LT_ADDR 1 uint3 Logical transport address for the eS-
CO logical transport. Valid range is
1-7.
eSCO_Packet_Type 1 uint8 0x00 (C → P): POLL
0x00 (P → C): NULL
0x07: EV3
0x0C: EV4
0x0D: EV5
0x26: 2-EV3
0x2C: 2-EV5
0x37: 3-EV3
0x3D: 3-EV5
Other values are reserved for future
use
Extended_Features 8 uint1 [64] The nth (numbering from 0) element
represents feature number 64P + n
in Tables 3.2 onwards, where P is
the relevant features page number.
Extended_Opcode 1 uint8 Which Extended_Opcode is being
acknowledged
Features 8 uint1 [64] The nth (numbering from 0) element
represents feature number n in Ta-
ble 3.2
Features_Page 1 uint8 Identifies which page of extended
features is being requested.
0 means standard features
1-255 other feature pages
Hold_Instant 4 uint32 slots Bits 27:1 of the Central's clock value.
Only even values are valid

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 2, Part C Page 744
Link Manager Protocol Specification

Length
(bytes)
Name Type Unit Detailed

Hold_Time 2 uint16 slots Only even values less than or equal

to (supervisionTO × 0.999) are valid.
Mandatory range 0x0014 to 0x8000.
IO_Capabilities 1 uint8 0: Display only
1: Display YesNo
2: KeyboardOnly
3: NoInputNoOutput
4-255: reserved for future use
Jitter 1 uint8 µs
Key 16 multiple
bytes
Key_Size 1 uint8 byte
Key_Size_Mask 2 uint1 [16] Supported broadcast encryption key
sizes: first element is support for
length 1, and so on. The bit shall be
one if the key size is supported.
Max_Slots 1 uint8 slots
Max_Sniff_Subrate 1 uint8 subrate Valid range: 1-255
Max_Supported_Page 1 uint8 Highest page of extended features
which contains a non-zero bit for the
originating device. Range 0-255
Min_Sniff_Mode_Timeout 2 uint16 slots Only even values are valid
Name_Fragment 14 utf8s{14z UTF-8 characters.
}
Name_Length 1 uint8 bytes
Name_Offset 1 uint8 bytes
NBC 1 uint8 Minimum number of times that an
APB broadcast packet should be
sent.

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 2, Part C Page 745
Link Manager Protocol Specification

Length
(bytes)
Name Type Unit Detailed

Negotiation_State 1 uint8 0: Initiate negotiation

1: the latest received set of nego-
tiable parameters were possible but
these parameters are preferred.
2: the latest received set of nego-
tiable parameters would cause a re-
served slot violation.
3: the latest received set of negotia-
ble parameters would cause a laten-
cy violation.
4: the latest received set of negotia-
ble parameters are not supported.
Other values are reserved for future
use
Nonce_Value 16 Multiple Little-endian Format
bytes
Notification_Type 1 uint8 0=passkey entry started
1=passkey digit entered
2=passkey digit erased
3=passkey cleared
4=passkey entry completed
5-255: reserved for future use
NPoll 1 uint8
NSAM_SM 1 uint8 submaps Number of submaps in the SAM slot
map; range 0 to 48
OOB_Auth_Data 1 uint8 0: No OOB Authentication Data re-
ceived
1: OOB Authentication Data received
2-255: reserved for future use
Opcode 1 uint8

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 2, Part C Page 746
Link Manager Protocol Specification

Length
(bytes)
Name Type Unit Detailed

Packet_Length 2 uint16 bytes Length of the eSCO payload

0 for POLL/NULL
1-30 for EV3
1-120 for EV4
1-180 for EV5
1-60 for 2-EV3
1-360 for 2-EV5
1-90 for 3-EV3
1-540 for 3-EV5
Other values are invalid
Packet_Type_Table 1 uint8 0: 1 Mb/s only
1: 2/3 Mb/s
2-255: reserved for future use
Paging_Scheme 1 uint8 0: mandatory scheme
1-255: reserved for future use
Paging_Scheme_Settings 1 uint8 For mandatory scheme:
0: R0
1: R1
2: R2
3-255: reserved for future use
Poll_Interval 2 uint16 slots Only even values are valid. Mandato-
ry range 0x0006 to 0x1000.
Power_Adj_Req 1 uint8 0: decrement power one step
1: increment power one step
2: increase to maximum power
3-255: reserved for future use

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 2, Part C Page 747
Link Manager Protocol Specification

Length
(bytes)
Name Type Unit Detailed

Power_Adj_Rsp 1 uint2 [4] element 0: GFSK

element 1: π/4-DQPSK
element 2: 8DPSK
element 3: reserved for future use
Each 2-bit value is defined as follows
0: not supported
1: changed one step, (not min or
max)
2: max power
3: min power
Random_Number 16 multiple
bytes
Reserved 1 uint8 Reserved for future use
SAM_Index 1 uint8 Index of the SAM slot map. Mandato-
ry values 0, 1, 2, and 0xFF.
SAM_Instant 4 uint32 slots CLK[27:1] at the instant the SAM slot
map is to be activated. Only even
values are valid.
SAM_Submaps 12 uint2 [48] This parameter contains 48 2-bit
fields. Only the first NSAM_SM fields
are significant; the remainder are re-
served for future use.
The nth (numbering from 0) such field
defines the submap type of the nth
submap in the map.
The meanings of the possible values
are:
0 = Each slot is individually available
or unavailable as configured. Slots
may have different availabilities for
transmission and reception
1 = All slots are available for trans-
mission and reception
2 = All slots are unavailable for trans-
mission and reception
3 = reserved for future use

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 2, Part C Page 748
Link Manager Protocol Specification

Length
(bytes)
Name Type Unit Detailed

SAM_Type0_Submap 14 uint2 [56] This parameter contains 56 2-bit

fields.
The nth (numbering from 0) such field
defines the slot type of the nth slot.
The meanings of the possible values
are:
0 = The slot is not available for either
transmission or reception
1 = The slot is available for transmis-
sion but not reception
2 = The slot is available for reception
but not transmission
3 = The slot is available for both
transmission and reception
SCO_Handle 1 uint8
SCO_Packet 1 uint8 0: HV1
1: HV2
2: HV3
3-255: reserved for future use
Slot_Offset 2 uint16 µs Valid range is 0 to 1249
Sniff_Attempt 2 uint16 received Number of receive slots. Mandatory
slots range 1 to Tsniff ÷2
Sniff_Subrating_Instant 4 uint32 slots Bits 27:1 of the Central's clock value
Only even values are valid
Sniff_Timeout 2 uint16 received Number of receive slots. Mandatory
slots range 0 to 0x0028.
Subversion 2 uint16 Defined by each company
Supervision_Timeout 2 uint16 slots Mandatory values 0 and 0x0190 to
0xFFFF. 0 means an infinite timeout
Switch_Instant 4 uint32 slots Bits 27:1 of the Central's clock value
Only even values are valid
TeSCO 1 uint8 slots Valid range is 4 – 254 slots Only
even values are valid

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 2, Part C Page 749
Link Manager Protocol Specification

Length
(bytes)
Name Type Unit Detailed

Timing_Control_Flags 1 uint8 bit 0 is ignored by the recipient

bit 1 = 0: use initialization 1
bit 1 = 1: use initialization 2
bit 2 is ignored by the recipient
bits 3-7: reserved for future use
TSAM_SM 1 uint8 slots Length of each SAM submap.
Range 2 to 56.
Only even values are valid
Tsco 1 uint8 slots Only even values are valid. Mandato-
ry values 2 and 6.
TSniff 2 uint16 slots Only even values less than or equal
to (supervisionTO × 0.999) are valid.
Mandatory values: valid values in the
range 0x0006 to 0x0540.
Update_Mode 1 uint8 0: Existing SAM slot maps containing
any type 0 submaps are invalidated
1: The defined type 0 submap takes
effect immediately
2:The defined type 0 submap takes
effect at the start of the next sub-in-
terval
All other values are reserved for fu-
ture use.
Version 1 uint8 See Assigned Numbers
W eSCO 1 uint8 slots Number of slots in the retransmission
window
Valid range is 0 – 254 slots Only
even values are valid

Table 5.2: Parameters in LM PDUs

If a parameter is described as "only even values are valid" and a device receives an
LMP PDU with an odd value for this parameter field, the PDU should be rejected with an
error code of Invalid LMP Parameters (0x1E).

Where a parameter is described as bits N:M of some other value V, the parameter
value in the PDU shall be V shifted right by M bits. Where the space available for the
parameter is greater than that needed (N-M+1 bits), the parameter value still occupies
the entire space and the remaining bits shall be zero.

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 2, Part C Page 750
Link Manager Protocol Specification

For example, if a 16 bit parameter is equal to 0xDEAD and bits 10:6 are stored in a
uint8, the resulting parameter will be 0x1A.

The recipient shall accept any of the values for the eSCO parameter listed in Table 5.3
and may accept any other value listed for the parameter in Table 5.2.

Single Slot Packets 3-Slot Packets

Packet type and T eSCO EV3: 6 EV4: 16
2-EV3: 6-12 (even) EV5: 16
3-EV3: 6-18 (even) 2-EV5: 16
3-EV5: 16
W eSCO 0, 2, and 4 0 and 6
Packet_Length (in each direction) 10 × TeSCO ÷ 2 10 × TeSCO ÷ 2
Air_Mode At least one of A-law, µ-law, transparent
CVSD, transparent

Table 5.3: Mandatory parameter ranges for eSCO packet types

5.3 LMP encapsulated

Name Major Type Minor Type Payload Length Detailed

P-192 Public Key 1 1 48 X, Y format
Bytes 23-0: X co-ordinate
Bytes 47-24: Y co-ordinate
Little-endian Format
P-256 Public Key 1 2 64 X, Y format
Bytes 31-0: X co-ordinate
Bytes 63-32: Y co-ordinate
Little-endian Format

Table 5.4: LMP encapsulated

All other combinations of major and minor type are reserved for future use.

5.4 Default values

Devices shall use these values before anything else has been negotiated:

Parameter Value
AFH_Mode disabled
AFH_Reporting_Mode disabled

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 2, Part C Page 751
Link Manager Protocol Specification

Parameter Value
Drift 250
Jitter 10
Max_Slots 1
Poll_Interval 40

Table 5.5: Device default values

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 2, Part C Page 752
Link Manager Protocol Specification

Appendix A Changes to parameter names

Previous versions of this specification used different names for some of the parameters
listed in Section 5.2. Table A.1 shows the previous and current names where a name
has been changed; Table A.2 shows those names that have not changed.

Previous name Current name

access scheme Access_Scheme
AFH_channel_classification AFH_Channel_Classification
AFH_channel_map AFH_Channel_Map
AFH_instant AFH_Instant
AFH_max_interval AFH_Max_Interval
AFH_min_interval AFH_Min_Interval
AFH_mode AFH_Mode
AFH_reporting_mode AFH_Reporting_Mode
air mode Air_Mode
authentication response Authentication_Rsp
clk_adj_clk Clk_Adj_Clk
clk_adj_id Clk_Adj_ID
clk_adj_instant Clk_Adj_Instant
clk_adj_mode Clk_Adj_Mode
clk_adj_period Clk_Adj_Period
clk_adj_slots Clk_Adj_Slots
clk_adj_us Clk_Adj_Offset
clock offset Clock_Offset
Commitment value Commitment_Value
CompId Company_Identifier
Confirmation value Confirmation_Value
data rate Data_Rate
drift Drift
Dsniff DSniff
encapsulated data Encap_Data
encapsulated major type Encap_Major_Type
encapsulated minor type Encap_Minor_Type

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 2, Part C Page 753
Link Manager Protocol Specification

Previous name Current name

encapsulated payload length Encap_Payload_Length
encryption mode Encryption_Mode
error code Error_Code
escape op code Escape_Opcode
eSCO handle eSCO_Handle
eSCO LT_ADDR eSCO_LT_ADDR
eSCO packet type eSCO_Packet_Type
extended features Extended_Features
extended op code Extended_Opcode
features Features
features page Features_Page
for future use Reserved
hold instant Hold_Instant
hold time Hold_Time
hopping mode Hopping_Mode
jitter Jitter
key Key
key size Key_Size
key size mask Key_Size_Mask
length of test data Test_Data_Length
max slots Max_Slots
max supported page Max_Supported_Page
max_sniff_subrate Max_Sniff_Subrate
min_sniff_mode_timeout Min_Sniff_Mode_Timeout
name fragment Name_Fragment
name length Name_Length
name offset Name_Offset
negotiation state Negotiation_State
Nonce Value Nonce_Value
Notification Type Notification_Type
Npoll NPoll
NSAM-SM NSAM_SM
OOB Authentication Data OOB_Auth_Data

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 2, Part C Page 754
Link Manager Protocol Specification

Previous name Current name

op code Opcode
packet length Packet_Length
packet type Packet_Type
packet type table Packet_Type_Table
paging scheme Paging_Scheme
paging scheme settings Paging_Scheme_Settings
poll interval Poll_Interval
poll period Poll_Period
power_adjustment_request Power_Adj_Req
power_adjustment_response Power_Adj_Rsp
power control mode Power_Mode
random number Random_Number
RX frequency RX_Frequency
SAM_Type0-Submap SAM_Type0_Submap
SCO handle SCO_Handle
SCO packet SCO_Packet
slot offset Slot_Offset
sniff attempt Sniff_Attempt
sniff timeout Sniff_Timeout
sniff_subrating_instant Sniff_Subrating_Instant
SubVersNr Subversion
supervision timeout Supervision_Timeout
switch instant Switch_Instant
test scenario Test_Scenario
timing control flags Timing_Control_Flags
TSAM-SM TSAM_SM
Tsniff TSniff
TX frequency TX_Frequency
Update Mode Update_Mode
VersNr Version

Table A.1: Changes to parameter names

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 2, Part C Page 755
Link Manager Protocol Specification

Parameter name
Authentication_Requirements
BD_ADDR
DeSCO
DSAM
DSCO
IO_Capabilities
NBC
SAM_Index
SAM_Instant
SAM_Submaps
TeSCO
TSCO
WeSCO

Table A.2: Unchanged parameter names

Bluetooth SIG Proprietary Version Date: 2024-08-27

 BR/EDR Controller
Part D

[THIS PART IS NO LONGER

USED]

Controller Error Codes are located in [Vol 1] Part F

Bluetooth SIG Proprietary

 BR/EDR Controller
Part E

[THIS PART IS NO LONGER

USED]

Host Controller Interface Functional Specification is

located in [Vol 4] Part E

Bluetooth SIG Proprietary

 BR/EDR Controller
Part F

MESSAGE SEQUENCE
CHARTS

Examples of interactions between Host Controller

Interface commands and events and Link Manager
Protocol Data Units are represented in the form
of message sequence charts. These charts show
typical interactions and do not indicate all possible
protocol behavior.

Bluetooth SIG Proprietary

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 2, Part F Page 759
Message Sequence Charts

CONTENTS

1 Introduction ............................................................................................... 761

1.1 Notation ....................................................................................... 761
1.2 Flow of control ............................................................................. 762
1.3 Example MSC ............................................................................. 762
1.4 Forward compatibility .................................................................. 762

2 Services without connection request ..................................................... 764

2.1 Remote Name Request ............................................................... 764
2.2 One-time inquiry .......................................................................... 766
2.3 Periodic inquiry ............................................................................ 768

3 ACL connection establishment and detachment ................................... 771

3.1 Connection setup ........................................................................ 773

4 Optional activities after ACL connection establishment ...................... 781

4.1 Authentication requested ............................................................ 781
4.2 Secure Simple Pairing message sequence charts ...................... 783
4.2.1 Optional OOB information collection ........................... 784
4.2.2 Enable Secure Simple Pairing and Secure
Connections ................................................................. 785
4.2.3 Connection establishment ........................................... 786
4.2.4 L2CAP connection request for a secure service ......... 786
4.2.5 Optional OOB information transfer .............................. 787
4.2.6 Start Secure Simple Pairing ........................................ 787
4.2.7 IO capability exchange ................................................ 789
4.2.8 Public key exchange .................................................... 789
4.2.9 Authentication .............................................................. 790
4.2.10 Numeric Comparison ................................................... 791
4.2.11 Numeric Comparison failure on initiating side ............. 792
4.2.12 Numeric Comparison failure on responding side ......... 793
4.2.13 Passkey Entry .............................................................. 793
4.2.14 Passkey Entry failure on responding side ................... 795
4.2.15 Passkey Entry failure on initiator side .......................... 796
4.2.16 Out of Band .................................................................. 797
4.2.17 OOB failure on initiator side ......................................... 799
4.2.18 DHKey checks ............................................................. 799
4.2.19 Calculate link key ......................................................... 801
4.2.20 Enable encryption ........................................................ 802
4.2.21 L2CAP connection response ....................................... 802
4.2.22 LMP ping ...................................................................... 803

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 2, Part F Page 760
Message Sequence Charts

4.3 Link Supervision Timeout Changed event ................................... 805

4.4 Set Connection Encryption .......................................................... 806
4.5 Change connection link key ........................................................ 808
4.6 Change connection link key with encryption pause and
resume ........................................................................................ 808
4.7 Temporary Link Key .................................................................... 810
4.8 Read remote supported features ................................................ 811
4.9 Read remote extended features .................................................. 812
4.10 Read clock offset ......................................................................... 813
4.11 Role switch on an encrypted link using encryption pause
and resume ................................................................................. 814
4.12 Refreshing encryption keys ......................................................... 816
4.13 Read remote version information ................................................ 817
4.14 QoS setup ................................................................................... 818
4.15 Switch role ................................................................................... 819
4.16 [This section is no longer used] ................................................... 821
4.17 [This section is no longer used] ................................................... 821
4.18 Slot availability mask ................................................................... 821
4.19 LMP transaction collision ............................................................ 825

5 Synchronous connection establishment and detachment ................... 826

5.1 Synchronous connection setup ................................................... 826
5.2 Synchronous connection setup with enhanced
synchronous commands ............................................................. 833

6 Sniff and Hold modes ............................................................................... 840

6.1 Sniff mode ................................................................................... 840
6.2 Hold mode ................................................................................... 841
6.3 [This section is no longer used] ................................................... 843

7 Buffer management, flow control ............................................................ 844

8 Loopback mode ........................................................................................ 846

8.1 Local Loopback mode ................................................................. 846
8.2 Remote Loopback mode ............................................................. 848

9 Connectionless Peripheral Broadcast services .................................... 850

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 2, Part F Page 761
Message Sequence Charts

1 INTRODUCTION

This Part shows typical interactions between Host Controller Interface (HCI) commands
and events and Link Manager (LM) Protocol Data Units (PDU) on the BR/EDR
Controller. It provides message sequence charts (MSCs) for a range of common Link
Manager procedures and the associated Host commands.

This Part illustrates only the most useful scenarios, it does not cover all possible
alternatives. Furthermore, the message sequence charts do not consider errors over
the air interface or Host interface. In all message sequence charts it is assumed that all
events are not masked, so the Controller will not filter out any events.

The sequence of messages in these message sequence charts is for illustrative

purposes. The messages may be sent in a different order where allowed by the Link
Manager or HCI. If any of these charts differ with text in the Baseband, Link Manager, or
HCI Parts, the text in those Parts overrides these charts.

1.1 Notation
The notation used in the message sequence charts (MSCs) consists of ovals, elongated
hexagons, boxes, lines, and arrows. The vertical lines terminated on the top by a
shadow box and at the bottom by solid oval indicate a protocol entity that resides in
a device. MSCs describe interactions between these entities and states those entities
may be in.

The following symbols represent interactions and states:

Oval Defines the context for the message sequence chart.

Hexagon Indicates a condition needed to start the transactions below this hexagon. The location
and width of the Hexagon indicates which entity or entities make this decision.
Box Replaces a group of transactions. May indicate a user action, or a procedure in the
Baseband.
Dashed Optional group of transactions.
Box
Solid Ar- Represents a message, signal or transaction. Can be used to show LMP and HCI
row traffic.
Some Baseband packet traffic is also shown. These are prefixed by BB followed by
either the type of packet, or an indication that there is an ACK signal in a packet.
Dashed Represents an optional message, signal or transaction. Can be used to show LMP and
Arrow HCI traffic.

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 2, Part F Page 762
Message Sequence Charts

1.2 Flow of control

Some message sequences are split into several charts. In these charts, numbers
indicate normal or required ordering and letters represent alternative paths. For
example, Step 4 is after Step 3, and Step 5a could be executed instead of Step 5b.

1.3 Example MSC

The protocol entities represented in the example shown in Figure 1.1 illustrate the
interactions of two devices named A and B. Each device includes a Host and a LM
entity in this example. Other MSCs in this Part may show the interactions of more than
two devices.

LM­A LM­B
Host A Central Peripheral Host B

Step 1: Context Statement for following chart

User Input

HCI_Command

HCI_Event

LMP_message

Group of Transactions

LMP_message

LM­A Decision

LMP_optional

LM­A & LM­B Decision

LMP_message

LMP_message

HCI_Event HCI_Event

Figure 1.1: Example MSC

1.4 Forward compatibility

Many of the message sequences in this Part use HCI commands or events that have
enhanced or extended variants that were added to the specification later than the

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 2, Part F Page 763
Message Sequence Charts

relevant sequence. Such variants can be related commands or events with different
names (e.g., HCI_Flush and HCI_Enhanced_Flush commands) or commands or events
with multiple versions (e.g., HCI_Encryption_Change event). In some instances (for
example, see [Vol 4] Part E, Section 3.1.1), a Host is required to use the new variant
rather than the one shown in the MSC. Even when this is not a requirement, Host
implementers may prefer to use the newer variants.

In these circumstances, the MSCs have not been rewritten to use newer features but
have been left unchanged. In general, the new commands and events will directly
replace the old ones, but this is not always the case and readers should not assume it.

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 2, Part F Page 764
Message Sequence Charts

2 SERVICES WITHOUT CONNECTION REQUEST

2.1 Remote Name Request

The service Remote Name Request is used to find out the name of the remote device
without requiring an explicit ACL connection.

Step 1: The Host sends an HCI_Set_Event_Mask with the bit of Remote Host
Supported Features Notification event (bit 60) set and an HCI_Remote_Name_Request
command expecting that its local device will automatically try to connect to the remote
device. (See Figure 2.1.)

LM­A LM­B
Host A Central Peripheral Host B

Step 1: Host A requests sending Remote_Name_Request

HCI_Set_Event_Mask
Only necessary if the
(bit 60 is set)
local Host wants to
know the remote Host
HCI_Command_Complete features (LMP feature
page 1)

HCI_Remote_Name_Request

HCI_Command_Status

Figure 2.1: Remote name request

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 2, Part F Page 765
Message Sequence Charts

Step 2a: If an ACL connection does not exist device A pages device B. After the
Baseband Paging procedure, the local device attempts to get the remote device's
extended features, send an HCI_Remote_Host_Supported_Features_Notification event,
get the remote name, disconnect, and return the name of the remote device to the Host.
(See Figure 2.2.)

LM­A LM­B
Host A Central Peripheral Host B

Step 2a: LM­A does not have a Baseband connection to Device B

Device A pages Device B

LMP_FEATURES_REQ

LMP_FEATURES_RES

LMP_FEATURES_REQ_EXT
Only if bit 60 is set in
the event mask and the
remote device supports LMP_FEATURES_RES_EXT
extended features
HCI_Remote_Host_
Supported_Features_
Notification

LMP_NAME_REQ

LMP_NAME_RES

HCI_Remote_Name_
Request_Complete

LMP_DETACH

Figure 2.2: Remote name request if no current Baseband connection

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 2, Part F Page 766
Message Sequence Charts

Step 2b: If an ACL connection exists when the request is made, then the Remote Name
Request procedure will be executed like an optional service. No Paging and no ACL
disconnect is done. (See Figure 2.3.)

LM­A LM­B
Host A Central Peripheral Host B

Step 2b: LM­A already has a Baseband connection to Device B

LMP_NAME_REQ

LMP_NAME_RES

HCI_Remote_Name_
Request_Complete

Figure 2.3: Remote name request with Baseband connection

2.2 One-time inquiry

Inquiry is used to detect and collect nearby devices.

Step 1: The Host sends an HCI_Inquiry command. (See Figure 2.4.)

LM­A
Host A Central BB­B BB­C

Step 1: Host A starts Inquiry procedure

HCI_Inquiry

HCI_Command_Status

Figure 2.4: Host A starts inquiry procedure

Step 2: The Controller will start the Baseband Inquiry procedure with the specified
Inquiry Access Code and Inquiry Length. When inquiry responses are received, the
Controller extracts the required information and returns the information related to

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 2, Part F Page 767
Message Sequence Charts

the found devices using one or more HCI_Inquiry_Result events to the Host. (See
Figure 2.5.)

LM­A
Host A Central BB­B BB­C

Step 2: Inquiry is active

Device A Performs Inquiry by sending ID packets,

receives FHS packets from Device B and Device C

BB

HCI_Inquiry Result

BB

HCI_Inquiry_Result

Figure 2.5: LM-A performs inquiry and reports result

Step 3a: If the Host wishes to terminate an Inquiry, the HCI_Inquiry_Cancel command
is used to immediately stop the inquiry procedure. (See Figure 2.6.)

LM­A
Host A Central BB­B BB­C

Step 3a: Host A decides to cancel Current Inquiry

HCI_Inquiry_Cancel

HCI_Command_Complete

Figure 2.6: Host A cancels inquiry

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 2, Part F Page 768
Message Sequence Charts

Step 3b: If the Inquiry procedure is completed due to the number of results obtained, or
the Inquiry Length has expired, an HCI_Inquiry_Complete event is returned to the Host.
(See Figure 2.7.)

LM­A
Host A Central BB­B BB­C

Step 3b: LM­A terminates Inquiry when Inquiry

Length expired or Num Responses returned

HCI_Inquiry_Complete

Figure 2.7: LM-A terminates current inquiry

2.3 Periodic inquiry

Periodic inquiry is used when the inquiry procedure is to be repeated periodically.

Step 1: The Hosts sends an HCI_Periodic_Inquiry_Mode command. (See Figure 2.8.)

LM­A
Host A Central BB­B BB­C

Step 1: Host A requires Periodic Inquiry

HCI_Periodic_Inquiry

HCI_Command_Complete

Figure 2.8: Host A starts periodic inquiry

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 2, Part F Page 769
Message Sequence Charts

Step 2: The Controller will start a periodic Inquiry. In the inquiry cycle, one or several
HCI_Inquiry_Result events will be returned. (See Figure 2.9.)

LM­A
Host A Central BB­B BB­C

Step 2: Periodically an Inquiry is Performed

Device A Performs Inquiry

Receives FHS packets from Device B and Device C

BB

HCI_Inquiry_Result

BB

HCI_Inquiry_Result

Figure 2.9: LM-A periodically performs an inquiry and reports result

Step 3: An HCI_Inquiry_Complete event will be returned to the Host when the current
periodic inquiry has finished. (See Figure 2.10.)

LM­A
Host A Central BB­B BB­C

Step 3: LM­A terminates Inquiry when Inquiry Length or Num Responses returned

HCI_Inquiry_Complete

Figure 2.10: LM-A terminates current inquiry

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 2, Part F Page 770
Message Sequence Charts

Step 4: The periodic Inquiry can be stopped using the HCI_Exit_Periodic_Inquiry_Mode

command. (See Figure 2.11.)

LM­A
Host A Central BB­B BB­C

Step 4: Host A decides to cancel Current Periodic Inquiry

HCI_Exit_Periodic_
Inquiry_Mode

HCI_Command_Complete

Figure 2.11: Host A decides to exit periodic inquiry

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 2, Part F Page 771
Message Sequence Charts

3 ACL CONNECTION ESTABLISHMENT AND

DETACHMENT

A flow diagram of the establishment and detachment of a connection between two

devices is shown in Figure 3.1. The process is illustrated in 9 distinct steps. A number
of these steps may be optionally performed, such as authentication and encryption.
Some steps are required, such as the Connection Request and Setup Complete steps.
The steps in the overview diagram directly relate to the steps in the following message
sequence charts.

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 2, Part F Page 772
Message Sequence Charts

Step 1: Create Connection

Step 2: Features Exchange

Step 3: Connection Request

Step 4: Optional Role Switch

Step 5: Optional AFH

Step 6: Optional Security

Step 7a: Optional Step 7b: Optional

Pairing Authentication

Step 8: Optional Encryption

Step 9: Setup Complete

Optional Data Flow

Step 10: Disconnection

Figure 3.1: Overview diagram for connection setup

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 2, Part F Page 773
Message Sequence Charts

3.1 Connection setup

Step 1: The Host sends an HCI_Create_Connection command to the Controller. The
Controller then performs a Baseband Paging procedure with the specified BD_ADDR.
(See Figure 3.2.)

LM­A LM­B
Host A Central Peripheral Host B

Step 1: Host A requests a connection to Device B

HCI_Create_Connection

HCI_Command_Status

Device A pages Device B

Figure 3.2: Host A requests connection with device B

Step 2: Optionally, the LM may decide to exchange features.

(See Figure 3.3.)

LM­A LM­B
Host A Central Peripheral Host B

Step 2: LM­A exchanges Extended Features with LM­B

LMP_FEATURES_REQ_EXT

LMP_FEATURES_RES_EXT

LMP_FEATURES_REQ_EXT

LMP_FEATURES_RES_EXT

Figure 3.3: LM-A and LM-B exchange features

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 2, Part F Page 774
Message Sequence Charts

Step 3: The LM on the Central will request an LMP_HOST_CONNECTION_REQ PDU.

The LM on the Peripheral will then confirm that a connection is OK, and if so, what role
is preferred. (See Figure 3.4)

LM­A LM­B
Host A Central Peripheral Host B

Step 3: LM­A sends Host Connection Request to LM­B

LMP_HOST_
CONNECTION_REQ

HCI_Connection_Request

Figure 3.4: LM-A requests Host connection

Step 4a: The remote Host rejects this connection, and the link is terminated. (See
Figure 3.5.)

LM­A LM­B
Host A Central Peripheral Host B

Step 4a: LM­B rejects Connection Request from LM­A

HCI_Reject_Connection_
Request

HCI_Command_Status

LMP_NOT_ACCEPTED

LMP_DETACH

HCI_Connection_Complete HCI_Connection_Complete
(Host Rejected) (Host Rejected)

Figure 3.5: Device B rejects connection request

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 2, Part F Page 775
Message Sequence Charts

Step 4b: The remote Host accepts this connection. (See Figure 3.6.)

LM­A LM­B
Host A Central Peripheral Host B

Step 4b: LM­B accepts Connection Request from LM­A as a Peripheral

HCI_Accept_Connection_
Request (Peripheral Preferred)

HCI_Command_Status

LMP_ACCEPTED

Figure 3.6: Device B accepts connection request

Step 4c: The remote Host accepts this connection but with the preference of being
a Central. This will cause a role switch to occur before the LMP_ACCEPTED for the
LMP_HOST_CONNECTION_REQ PDU is sent. (See Figure 3.7.)

LM­A LM­B
Host A Central Peripheral Host B

Step 4c: LM­B accepts Connection Request from LM­A as a Central

HCI_Accept_Connection_
Request (Central Preferred)

HCI_Command_Status

LMP_SLOT_OFFSET

LMP_SWITCH_REQ

LMP_ACCEPTED

Role Switch

LMP_ACCEPTED
(LMP_HOST_CONNECTION_
REQ)

HCI_Role_Change (Peripheral) HCI_Role_Change (Central)

Figure 3.7: Device B accepts connection requests as Central

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 2, Part F Page 776
Message Sequence Charts

Step 5: After the features have been exchanged and AFH support is determined
to be available, the Central may at any time send an LMP_SET_AFH and
LMP_CHANNEL_CLASSIFICATION_REQ PDU. (See Figure 3.8.)

LM­A LM­B
Host A Central Peripheral Host B

Step 5: LM­A may enable AFH

LMP_SET_AFH

LM­A may enable channel classification

LMP_CHANNEL_CLASSIFICATION_
REQ

LMP_CHANNEL_CLASSIFICATION

LMP_CHANNEL_CLASSIFICATION

Figure 3.8: LM-A starts Adaptive Frequency Hopping

Step 6: The LM will request if authentication is required. It does this by requesting the
Link Key for this connection from the Host. (See Figure 3.9.)

LM­A LM­B
Host A Central Peripheral Host B

Step 6: LM Authentication required

HCI_Link_Key_Request

Figure 3.9: Authentication initiated

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 2, Part F Page 777
Message Sequence Charts

Step 7a: If authentication is required by the higher layers and the devices to be
connected do not have a common link key, a pairing procedure will be used. The LM will
have requested a link key from the Host for this connection. If there is a negative reply,
then a PIN code will be requested. This PIN code will be requested on both sides of the
connection, and authentication performed based on this PIN code. The last step is for
the new link key for this connection to be passed to the Host so that it may store it for
future connections. (See Figure 3.10.)

LM­A LM­B
Host A Central Peripheral Host B

Step 7a: Pairing during connection establishment

HCI_Link_Key_Request_
Negative_Reply

HCI_Command_Complete

HCI_PIN_Code_Request

User inputs
PIN Code

HCI_PIN_Code_
Request_Reply

HCI_Command_Complete

LMP_IN_RAND

HCI_PIN_Code_Request

User inputs
PIN Code

HCI_PIN_Code_
Request_Reply

HCI_Command_Complete

LMP_ACCEPTED

LMP_COMB_KEY

LMP_COMB_KEY

LMP_AU_RAND

LMP_SRES

LMP_AU_RAND

LMP_SRES

HCI_Link_Key_Notification HCI_Link_Key_Notification

Figure 3.10: Pairing during connection setup

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 2, Part F Page 778
Message Sequence Charts

Step 7b: If a common link key exists between the devices, then pairing is not needed.
The LM will have asked for a link key from the Host for this connection. If this
is a positive reply, then the link key is used for authentication. If the configuration
parameter Authentication_Enable is set, then the authentication procedure is executed.
This MSC only shows the case when Authentication_Enable is set on both sides. (See
Figure 3.11.)

LM­A LM­B
Host A Central Peripheral Host B

Step 7b: Authentication during connection establishment

HCI_Link_Key_Request_Reply

HCI_Command_Complete

LMP_AU_RAND

HCI_Link_Key_Request

HCI_Link_Key_Request_Reply

LMP_SRES

HCI_Command_Complete

LMP_AU_RAND

LMP_SRES

Figure 3.11: Authentication during connection setup

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 2, Part F Page 779
Message Sequence Charts

Step 8: Once the pairing or authentication procedure is successful, the encryption

procedure may be started. This MSC only shows the set up of an encrypted point-to-
point connection. (See Figure 3.12.)

LM­A LM­B
Host A Central Peripheral Host B

Step 8: Starting encryption during connection establishment

If (encryption required)

LMP_ENCRYPTION_MODE_REQ

LMP_ACCEPTED

LMP_ENCRYPTION_KEY_SIZE_
REQ

LMP_ACCEPTED

LMP_START_ENCRYPTION_REQ

LMP_ACCEPTED

Figure 3.12: Starting encryption during connection setup

Step 9: The LMs indicate that the connection is setup by sending

LMP_SETUP_COMPLETE PDU. This will cause the Host to be notified of the new
Connection_Handle, and this connection may be used to send higher layer data such as
L2CAP information. (See Figure 3.13.)

LM­A LM­B
Host A Central Peripheral Host B

Step 9: LM­A finishes Connection Setup with LM­B

LMP_SETUP_COMPLETE

LMP_SETUP_COMPLETE

HCI_Connection_Complete HCI_Connection_Complete

Figure 3.13: LM-A and LM-B finishes connection setup

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 2, Part F Page 780
Message Sequence Charts

Step 10: Once the connection is no longer needed, either device may terminate
the connection using the HCI_Disconnect command and LMP_DETACH message
PDU. The disconnection procedure is one-sided and does not need an explicit
acknowledgment from the remote LM. The use of ARQ Acknowledgment from the
Baseband indicates that the remote LM has received the LMP_DETACH PDU. (See
Figure 3.14.)

LM­A LM­B
Host A Central Peripheral Host B

Step 10: Host A decides to terminate connection

HCI_Disconnect

HCI_Command_Status

LMP_DETACH

BB ACK

HCI_Disconnection_Complete HCI_Disconnection_Complete

Figure 3.14: Host A decides to disconnect

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 2, Part F Page 781
Message Sequence Charts

4 OPTIONAL ACTIVITIES AFTER ACL CONNECTION

ESTABLISHMENT

4.1 Authentication requested

Step 1: Authentication can be explicitly executed at any time after a connection has
been established. If no Link Key is available then the Link Key is required from the Host.
(See Figure 4.1.)

Note: If the Controller or LM and the Host do not have the Link Key, the devices
will need to pair using a procedure such as that in Section 3.1 Step 7a or that in
Section 4.2.

Host A LM­A LM­B Host B

Step 1: Host A requests authentication (Legacy Authentication)

HCI_Authentication_
Requested

HCI_Command_Status

If (link key missing)

then Link Key Required

HCI_Link_Key_Request

HCI_Link_Key_Request_
Reply

HCI_Command_Complete

LMP_AU_RAND

HCI_Link_Key_Request

HCI_Link_Key_Request_
Reply

HCI_Command_Complete

LMP_SRES

HCI_Authentication_
Complete

Figure 4.1: Authentication requested (legacy authentication)

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 2, Part F Page 782
Message Sequence Charts

When both devices support Secure Connections, Secure Authentication is used.

LM­A LM­B
Host A Central Peripheral Host B

Step 1: Host A requests authentication (Secure Authentication)

HCI_Authentication_
Requested

HCI_Command_Status

If (link key missing)

then Link Key Required

HCI_Link_Key_Request

HCI_Link_Key_Request_
Reply

HCI_Command_Complete

LMP_AU_RAND

HCI_Link_Key_Request

HCI_Link_Key_Request_
Reply

HCI_Command_Complete

LMP_AU_RAND

LMP_SRES

LMP_SRES

HCI_Authentication_
Complete

Figure 4.2: Authentication requested (secure authentication)

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 2, Part F Page 783
Message Sequence Charts

4.2 Secure Simple Pairing message sequence charts

A flow diagram of Secure Simple Pairing between two devices is shown in Figure 4.3.
The process is illustrated in 11 distinct steps. A number of these steps have a number of
different options.

Step 1: Optional OOB Information Collection

Step 2: Enable Secure Simple Pairing

Step 3a: L2CAP Step 3b: Optional

Connection Request OOB Information
for a Secure Service Transfer

Step 4: Start Secure Simple Pairing

Step 5: IO Capability Exchange

Step 6: Public Key Exchange

Step 7a: Step 7b: Step 7c:

Optional Numeric Optional Passkey Optional
Comparison Entry OOB

Step 8: DHKey Checks

Step 9: Calculate Link Key

Step 10: Enable Encryption

Step 11: L2CAP Connection Response

Figure 4.3: Secure Simple Pairing - flow diagram

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 2, Part F Page 784
Message Sequence Charts

4.2.1 Optional OOB information collection

If a device supports OOB information exchange, then the Host should request the C and
R values from the Controller that need to be sent by OOB. It is then assumed that the
Host transfers this information to the OOB system. This could occur a long time before,
for example at the factory for a passive tag.

LM­A LM­B
Host A Central Peripheral Host B

Step 1a: Optional OOB Information Collection

HCI_Read_Local_OOB_Data HCI_Read_Local_OOB_Data

HCI_Command_Complete HCI_Command_Complete

CR CR
transferred transferred
to OOB to OOB

Figure 4.4: Optional OOB information collection (P-192 only)

When the Controller and Host support Secure Connections, the

HCI_Read_Local_OOB_Extended_Data command is used instead of
HCI_Read_Local_OOB_Data.

LM­A LM­B
Host A Central Peripheral Host B

Step 1b: Optional OOB Information Collection

HCI_Read_Local_OOB_ HCI_Read_Local_OOB_
Extended_Data Extended_Data

HCI_Command_Complete HCI_Command_Complete

CR CR
transferred transferred
to OOB to OOB

Figure 4.5: Optional OOB information collection (P-192 and P-256)

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 2, Part F Page 785
Message Sequence Charts

4.2.2 Enable Secure Simple Pairing and Secure Connections

To enable Secure Simple Pairing, a device must use the

HCI_Write_Simple_Pairing_Mode command. This must be done before any connections
that use Secure Simple Pairing are created.

LM­A LM­B
Host A Central Peripheral Host B

Step 2a: Enable Secure Simple Pairing

HCI_Write_Simple_Pairing_
Mode (enabled)

HCI_Command_Complete

HCI_Write_Simple_Pairing_
Mode (enabled)

HCI_Command_Complete

Figure 4.6: Enable Secure Simple Pairing

To configure the Controller to use Secure Connections HCI commands and events,
a device must use the HCI_Write_Secure_Connections_Host_Support command. This
must be done when no ACL connections are present.

LM­A LM­B
Host A Central Peripheral Host B

Step 2b: Write Secure Connections Host Support on Device A

HCI_Write_Secure_
Connections_Host_Support
(enabled)

HCI_Command_Complete

Figure 4.7: Enable Secure Connections Host Support

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 2, Part F Page 786
Message Sequence Charts

To configure the Controller to enforce a maximum interval between packets

containing a MIC (when AES-CCM encryption is used), a device must use the
HCI_Write_Authenticated_Payload_Timeout command.

LM­A LM­B
Host A Central Peripheral Host B

Step 2c: Write Authenticated Payload Timeout on Device A

HCI_Write_Authenticated_
Payload_Timeout

HCI_Command_Complete

Figure 4.8: Set Authenticated_Payload_Timeout

4.2.3 Connection establishment

Secure Simple Pairing, once it is enabled, is triggered by one of two possible actions. It
could be triggered by an L2CAP connection request to a service that requires security,
or it could be triggered by an OOB transfer of information.

4.2.4 L2CAP connection request for a secure service

Once a connection has been established between two devices, if a device requests an
L2CAP connection to a service that requires authentication and encryption, then the
device will start Secure Simple Pairing.

L2CAP A L2CAP B

Step 3a: L2CAP Connection Request for a Secure Service

L2CAP Connection Request

L2CAP Connection Response (Pending)

Figure 4.9: L2CAP connection request for a secure service

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 2, Part F Page 787
Message Sequence Charts

4.2.5 Optional OOB information transfer

Even if a Bluetooth connection has not been established between two devices, an OOB
transfer can occur that transfers the Bluetooth Device Address of the device, and other
OOB information for authentication. If an OOB transfer occurs, then the Host can start
Secure Simple Pairing.

Host A Host B

Step 3b: Optional OOB Information Transfer

OOB Transfer

OOB Transfer

Device A connects to Device B

Figure 4.10: Optional OOB information transfer

4.2.6 Start Secure Simple Pairing

Once the Host has determined that Secure Simple Pairing should start, it issues
an HCI_Authentication_Requested command to the Controller. This will cause the
Controller to generate a request for a link key. If the Host has a link key for this
connection, then pairing is not required, and the link key can be used immediately
once it has been authenticated. Secure Simple Pairing will only be used if an

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 2, Part F Page 788
Message Sequence Charts

HCI_Link_Key_Request_Negative_Reply command is sent from the Host to the

Controller on the initiating side.

Host A LMP A LMP B Host B

Step 4: Start Secure Simple Pairing

HCI_Authentication_
Requested

HCI_Command_Status

HCI_Link_Key_Request

HCI_Link_Key_Request_
Negative_Reply

HCI_Command_Complete

Figure 4.11: Start Secure Simple Pairing

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 2, Part F Page 789
Message Sequence Charts

4.2.7 IO capability exchange

To be able to determine the correct authentication algorithm to use, the input / output
capabilities of the two devices are exchanged.

Host A LM­A LM­B Host B

Step 5: IO Capability Exchange

HCI_IO_Capability_Request

HCI_IO_Capability_
Request_Reply

HCI_Command_Complete

LMP_IO_CAPABILITY_REQ

HCI_IO_Capability_Response

HCI_IO_Capability_Request

HCI_IO_Capability_
Request_Reply

HCI_Command_Complete

LMP_IO_CAPABILITY_RES

HCI_IO_Capability_Response

Figure 4.12: IO capability exchange

4.2.8 Public key exchange

Next the public keys are exchanged between the two devices. Once a device has
received the public key of the peer device, it can start to calculate the Diffie Hellman

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 2, Part F Page 790
Message Sequence Charts

Key (DHKey). This may take a long time, and should be started early, so that user
interaction can hide the calculation time. The DHKey is not required until step 8.

Host A LM­A LM­B Host B

Step 6: Public Key Exchange

LMP_ENCAPSULATED_
HEADER
(P­192_public_key or
P­256_public_key)

LMP_ACCEPTED

Repeat 3x for P­192 and 4x for P­256

LMP_ENCAPSULATED_
PAYLOAD

LMP_ACCEPTED

Start
Calculating
DHKey

LMP_ENCAPSULATED_
HEADER
(P­192_public_key or
P­256_public_key)

LMP_ACCEPTED

Repeat 3x for P­192 and 4x for P­256

LMP_ENCAPSULATED_
PAYLOAD

LMP_ACCEPTED

Start
Calculating
DHKey

Figure 4.13: Public key exchange

4.2.9 Authentication

A device can be authenticated by using one of three algorithms. The choice of algorithm
is determined by the combination of the IO capabilities of the two devices.

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 2, Part F Page 791
Message Sequence Charts

4.2.10 Numeric Comparison

The numeric comparison step will be done when both devices have output capabilities,
or if one of the devices has no input or output capabilities. If both devices have output
capabilities, this step requires the displaying of a user confirmation value. This value
should be displayed until the end of step 8. If one or both devices do not have output
capabilities, the same protocol is used but the Hosts will skip the step asking for
the user confirmation. The sequence for Just Works is identical to that of Numeric
Comparison with the exception that the Host will not show the numbers to the user.

Host A LM­A LM­B Host B

Step 7a: Numeric Comparison

Pick N Pick N
Calculate C

LMP_SIMPLE_PAIRING_
CONFIRM

LMP_SIMPLE_PAIRING_NUMBER

LMP_ACCEPTED

LMP_SIMPLE_PAIRING_NUMBER

Check C

LMP_ACCEPTED

Calculate User Calculate User

Confirm Value Confirm Value

HCI_User_Confirmation_Request HCI_User_Confirmation_Request
(Value) (Value)

User Confirms User Confirms

Value Value

HCI_User_Confirmation_ HCI_User_Confirmation_
Request_Reply Request_Reply

HCI_Command_Complete HCI_Command_Complete

Figure 4.14: Numeric Comparison authentication

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 2, Part F Page 792
Message Sequence Charts

4.2.11 Numeric Comparison failure on initiating side

If the numeric comparison fails on the initiating side due to the user indicating that the
confirmation values do not match, Secure Simple Pairing is terminated.

Host A LM­A LM­B Host B

Step 7a: Numeric Comparison

Pick N Pick N
Calculate C

LMP_SIMPLE_PAIRING_
CONFIRM

LMP_SIMPLE_PAIRING_NUMBER

LMP_ACCEPTED

LMP_SIMPLE_PAIRING_NUMBER

Check C

LMP_ACCEPTED

Calculate User Calculate User

Confirm Value Confirm Value

HCI_User_Confirmation_Request HCI_User_Confirmation_Request
(Value) (Value)

User Confirms User Confirms

Value Value

HCI_User_Confirmation_ HCI_User_Confirmation_
Request_Negative_Reply Request_Reply

HCI_Command_Complete HCI_Command_Complete

LMP_NUMERIC_COMPARISON_
FAILED

HCI_Simple_Pairing_Complete HCI_Simple_Pairing_Complete
(failure) (failure)

Figure 4.15: Numeric Comparison authentication (failure on initiating side)

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 2, Part F Page 793
Message Sequence Charts

4.2.12 Numeric Comparison failure on responding side

If the numeric comparison fails on the responding side due to the user indicating that
the confirmation values do not match, Secure Simple Pairing is terminated.

Host A LM­A LM­B Host B

Step 7a: Numeric Comparison

Pick N Pick N
Calculate C

LMP_SIMPLE_PAIRING_
CONFIRM

LMP_SIMPLE_PAIRING_NUMBER

LMP_ACCEPTED

LMP_SIMPLE_PAIRING_NUMBER

Check C

LMP_ACCEPTED

Calculate User Calculate User

Confirm Value Confirm Value

HCI_User_Confirmation_Request HCI_User_Confirmation_Request
(Value) (Value)

User Confirms User Confirms

Value Value

HCI_User_Confirmation_ HCI_User_Confirmation_
Request_Reply Request_Negative_Reply

HCI_Command_Complete HCI_Command_Complete

LMP_DHKEY_CHECK

LMP_NOT_ACCEPTED

HCI_Simple_Pairing_Complete HCI_Simple_Pairing_Complete
(failure) (failure)

Figure 4.16: Numeric Comparison failure on responding side

4.2.13 Passkey Entry

The Passkey Entry step is used in two cases: when one device has numeric input
only and the other device has either a display or numeric input capability or when both

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 2, Part F Page 794
Message Sequence Charts

devices only have numeric input capability. In this step, one device display a number
to be entered by the other device or the user enters a number on both devices. This
number should be displayed until the end of step 8. Key press notification messages are
shown during the user input phase.

Host A LM­A LM­B Host B

Step 7b: Passkey Entry (Initiator=DisplayOnly or DisplayYesNo , Responder=KeyboardOnly)

HCI_User_Passkey_Notification HCI_User_Passkey_Request

Example Notifications

HCI_Send_Keypress_Notification
(Notification_Type=Entry Started)
LMP_KEYPRESS_NOTIFICATION
HCI_Keypress_Notification
(Notification_Type=Entry Started)
HCI_Command_Complete
User

Input
HCI_Send_Keypress_Notification
(Notification_Type=Entry
LMP_KEYPRESS_NOTIFICATION
Completed)
HCI_Keypress_Notification
(Notification_Type=Entry
Completed) HCI_Command_Complete

HCI_User_Passkey_Request_
Reply

HCI_Command_Complete

Repeat 20 times

LMP_SIMPLE_PAIRING_
CONFIRM

LMP_SIMPLE_PAIRING_
CONFIRM

LMP_SIMPLE_PAIRING_NUMBER

Check C

LMP_ACCEPTED

LMP_SIMPLE_PAIRING_NUMBER

Check C

LMP_ACCEPTED

Figure 4.17: Passkey Entry authentication

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 2, Part F Page 795
Message Sequence Charts

4.2.14 Passkey Entry failure on responding side

If the Passkey Entry fails on the responding side, Secure Simple Pairing is terminated.

Host A LM­A LM­B Host B

Step 7b: Passkey Entry (Responding Device Failure,

Initiator=DisplayOnly or DisplayYesNo, Responder=KeyboardOnly

HCI_User_Passkey_Notification HCI_User_Passkey_Request

User Input

HCI_User_Passkey_Request_
Negative_Reply

HCI_Command_Complete

LMP_SIMPLE_PAIRING_
CONFIRM

LMP_NOT_ACCEPTED

HCI_Simple_Pairing_Complete HCI_Simple_Pairing_Complete
(failure) (failure)

Figure 4.18: Passkey Entry failure on responding side

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 2, Part F Page 796
Message Sequence Charts

4.2.15 Passkey Entry failure on initiator side

If the Passkey Entry fails on the initiating side, Secure Simple Pairing is terminated. This
is only possible if the initiating LM side sends an HCI_User_Passkey_Request event.

Host A LM­A LM­B Host B

Step 7b: Passkey Entry (Initiating Device Failure,

Initiator=KeyboardOnly, Responder=DisplayOnly or DisplayYesNo)

HCI_User_Passkey_Request HCI_User_Passkey_Notification

HCI_User_Passkey_Request_
Negative_Reply

HCI_Command_Complete

LMP_PASSKEY_ENTRY_
FAILED

HCI_Simple_Pairing_Complete HCI_Simple_Pairing_Complete
(failure) (failure)

Figure 4.19: Passkey Entry failure on initiating side

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 2, Part F Page 797
Message Sequence Charts

4.2.16 Out of Band

The OOB authentication will only be done when both devices have some OOB
information to use. This step requires no user interaction.

Host A LM­A LM­B Host B

Step 7c: OOB

HCI_Remote_OOB_Data_ HCI_Remote_OOB_Data_
Request Request

HCI_Remote_OOB_Data_ HCI_Remote_OOB_Data_
Request_Reply Request_Reply

HCI_Command_Complete HCI_Command_Complete

Check C Check C
from OOB from OOB

Pick N Pick N
Calculate C Calculate C

LMP_SIMPLE_PAIRING_
NUMBER

LMP_ACCEPTED

LMP_SIMPLE_PAIRING_
NUMBER

LMP_ACCEPTED

Figure 4.20: OOB authentication (P-192)

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 2, Part F Page 798
Message Sequence Charts

Host A LM­A LM­B Host B

Step 7c: OOB

HCI_Remote_OOB_Data_ HCI_Remote_OOB_Data_
Request Request

HCI_Remote_OOB_Extended_ HCI_Remote_OOB_Extended_
Data_Request_Reply Data_Request_Reply

HCI_Command_Complete HCI_Command_Complete

Check C Check C
from OOB from OOB

Pick N Pick N
Calculate C Calculate C

LMP_SIMPLE_PAIRING_
NUMBER

LMP_ACCEPTED

LMP_SIMPLE_PAIRING_
NUMBER

LMP_ACCEPTED

Figure 4.21: OOB authentication (P-256)

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 2, Part F Page 799
Message Sequence Charts

4.2.17 OOB failure on initiator side

If the initiating side does not have OOB information, Secure Simple Pairing is
terminated.

Host A LM­A LM­B Host B

Step 7c: OOB

HCI_Remote_OOB_Data_ HCI_Remote_OOB_Data_
Request Request

HCI_Remote_OOB_Data_ HCI_Remote_OOB_Data_
Request_Negative_Reply Request_Reply

HCI_Command_Complete HCI_Command_Complete

Check C Check C
from OOB from OOB

Pick N Pick N
Calculate C Calculate C

LMP_OOB_FAILED

HCI_Simple_Pairing_Complete HCI_Simple_Pairing_Complete
(failure) (failure)

Figure 4.22: OOB authentication failure on initiating side

4.2.18 DHKey checks

Once the devices have been authenticated, and the DHKey calculation has completed,
the DHKey value generated is checked. If this succeeds, then both devices would have

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 2, Part F Page 800
Message Sequence Charts

finished displaying information to the user about the process, and therefore a message
is sent from the Controller to the Host to notify it to stop displaying this information.

Host A LM­A LM­B Host B

Step 8: DHKey Checks

DHKey DHKey
Calculation Calculation
Finished Finished

LMP_DHKEY_CHECK

Check E

LMP_ACCEPTED

LMP_DHKEY_CHECK

Check E

LMP_ACCEPTED

HCI_Simple_Pairing_Complete HCI_Simple_Pairing_Complete

User User
Confirmation Confirmation
Finishes Finishes

Figure 4.23: DHKey checks

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 2, Part F Page 801
Message Sequence Charts

4.2.19 Calculate link key

Once Secure Simple Pairing is complete, the link key can be calculated from the DHKey
and used as input to a standard mutual authentication. Once this is complete, an
HCI_Link_Key_Notification event will be generated.

Host A LM­A LM­B Host B

Step 9: Calculate Link Key

Calculate Calculate
Link Key Link Key

LMP_AU_RAND

LMP_SRES

LMP_AU_RAND

LMP_SRES

HCI_Link_Key_Notification HCI_Link_Key_Notification

Figure 4.24: Calculate link key

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 2, Part F Page 802
Message Sequence Charts

4.2.20 Enable encryption

Once the link key has been notified to the Host, the HCI_Authentication_Requested
command will complete with an HCI_Authentication_Complete event. The Host can
then turn on encryption using the standard methods.

Host A LM­A LM­B Host B

Step 10: Start Encryption

HCI_Authentication_Complete

HCI_Set_Connection_Encryption
(on)

HCI_Command_Status

LMP_ENCRYPTION_MODE_
REQ

LMP_ACCEPTED

LMP_ENCRYPTION_KEY_
SIZE_REQ

LMP_ACCEPTED

LMP_START_
ENCRYPTION_REQ

LMP_ACCEPTED

HCI_Encryption_Change (on) HCI_Encryption_Change (on)

Figure 4.25: Start encryption

4.2.21 L2CAP connection response

If this Secure Simple Pairing was triggered by an L2CAP Connection Request, then
only after all of the above steps have completed can the L2CAP Connection Response
message be sent.

L2CAP A L2CAP B

Step 11: L2CAP Connection Response

L2CAP Connection Response (Success)

Figure 4.26: L2CAP Connection Response

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 2, Part F Page 803
Message Sequence Charts

4.2.22 LMP ping

When the Authenticated Payload Timeout has nearly expired, the Link Manager
will force the remote device to send a packet containing a MIC by sending the
LMP_PING_REQ PDU.

LM­A LM­B
Host A Central Peripheral Host B

Packet containing a MIC

TAuthenticated_Payload
nearly expired

LMP_PING_REQ

LMP_PING_RES

Figure 4.27: Successful ping

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 2, Part F Page 804
Message Sequence Charts

When a packet with a MIC has not been received within the Authenticated Payload
Timeout, the Host is notified that the timer has expired.

LM­A LM­B
Host A Central Peripheral Host B

Packet containing a MIC

TAuthenticated_Payload
nearly expired

LMP_PING_REQ

TAuthenticated_Payload
expired

HCI_Authenticated_Payload_
Timeout_Expired

TAuthenticated_Payload
nearly expired

TAuthenticated_Payload
expired

HCI_Authenticated_Payload_
Timeout_Expired

LMP response
timeout expired

TAuthenticated_Payload
nearly expired

LMP_PING_REQ

Figure 4.28: Unsuccessful ping

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 2, Part F Page 805
Message Sequence Charts

4.3 Link Supervision Timeout Changed event

When enabled by the Host, the Peripheral generates
an HCI_Link_Supervision_Timeout_Changed event after the
LMP_SUPERVISION_TIMEOUT PDU is received.

LM­A LM­B
Host A Central Peripheral Host B

Step 1: Central’s Host changes link supervision timeout

HCI_Write_Link_Supervision_
Timeout

LMP_SUPERVISION_TIMEOUT

HCI_Command_Complete

HCI_Link_Supervision_Timeout_
Changed

Figure 4.29: Link supervision timeout event

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 2, Part F Page 806
Message Sequence Charts

4.4 Set Connection Encryption

Step 1: The Host may at any time turn on encryption using the
HCI_Set_Connection_Encryption command. This command can be originated from
either the Central or Peripheral sides. Only the Central side is shown in
Figure 4.30. If this command is sent from a Peripheral, the only difference is that
the LMP_ENCRYPTION_MODE_REQ PDU will be sent from the Peripheral. The
LMP_ENCRYPTION_KEY_SIZE_REQ and LMP_START_ENCRYPTION_REQ PDUs
will always be requested from the Central. (See Figure 4.30.)

LM­A LM­B
Host A Central Peripheral Host B

Step 1: Host A requests encryption on

HCI_Set_Connection_Encryption
(on)

HCI_Command_Status

LMP_ENCRYPTION_MODE_
REQ

LMP_ACCEPTED

LMP_ENCRYPTION_KEY_
SIZE_REQ

LMP_ACCEPTED

LMP_START_ENCRYPTION_
REQ

LMP_ACCEPTED

HCI_Encryption_Change (on) HCI_Encryption_Change (on)

Figure 4.30: Encryption requested

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 2, Part F Page 807
Message Sequence Charts

Step 2: To terminate the use of encryption, the HCI_Set_Connection_Encryption

command is used. (See Figure 4.31.)

LM­A LM­B
Host A Central Peripheral Host B

Step 2: Host A requests encryption off

HCI_Set_Connection_Encryption
(off)

HCI_Command_Status

LMP_ENCRYPTION_MODE_
REQ

LMP_ACCEPTED

LMP_STOP_ENCRYPTION_
REQ

LMP_ACCEPTED

HCI_Encryption_Change (off) HCI_Encryption_Change (off)

Figure 4.31: Encryption off requested

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 2, Part F Page 808
Message Sequence Charts

4.5 Change connection link key

Step 1: The Central’s Host (Host A) may change the connection link key using the
HCI_Change_Connection_Link_Key command. A new link key will be generated and
the Hosts will be notified of this new link key. (See Figure 4.32.)

LM­A LM­B
Host A Central Peripheral Host B

Step 1: Host A requests Connection Link Key Change

HCI_Change_Connection_
Link_Key

HCI_Command_Status

LMP_COMB_KEY

LMP_COMB_KEY

LMP_AU_RAND

LMP_SRES

LMP_AU_RAND

LMP_SRES

HCI_Link_Key_Notification HCI_Link_Key_Notification

HCI_Change_Connection_
Link_Key_Complete

Figure 4.32: Change connection link key

4.6 Change connection link key with encryption pause and resume
Step 1: The Central’s Host (Host A) may change the connection link key using the
HCI_Change_Connection_Link_Key command. A new link key will be generated and
the Hosts will be notified of this new link key. Encryption will then be paused and

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 2, Part F Page 809
Message Sequence Charts

resumed, immediately using this new link key to generate a new encryption key. (See
Figure 4.33.)

LM­A LM­B
Host A Central Peripheral Host B

Step 1: Change Connection Link Key with Encryption Pause and Resume

HCI_Change_Connection_
Link_Key

HCI_Command_Status

LMP_COMB_KEY

LMP_COMB_KEY

LMP_AU_RAND

LMP_SRES

LMP_AU_RAND

LMP_SRES

HCI_Link_Key_Notification HCI_Link_Key_Notification

LMP_PAUSE_ENCRYPTION_
REQ

LMP_PAUSE_ENCRYPTION_
REQ

LMP_STOP_ENCRYPTION_
REQ

LMP_ACCEPTED

LMP_START_ENCRYPTION_
REQ

LMP_ACCEPTED

HCI_Encryption_Key_Refresh_ HCI_Encryption_Key_Refresh_
Complete Complete

HCI_Change_Connection_
Link_Key_Complete

Figure 4.33: Change connection link key with encryption pause and resume

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 2, Part F Page 810
Message Sequence Charts

4.7 Temporary Link Key

Step 1: The Host changes to a Temporary Link Key from a Semi-permanent Link
Key using the HCI_Link_Key_Selection command when at least one device does not
support Encryption Pause and Resume. (See Figure 4.34.)

LM­A LM­B
Host A Central Peripheral Host B

Step 1: Host requests switch from Semi­permanent Link Key to Temporary Link Key

HCI_Link_Key_Selection
(temporary link key)

HCI_Command_Status

LMP_TEMP_RAND

LMP_TEMP_KEY

LMP_AU_RAND

LMP_SRES

LMP_AU_RAND

LMP_SRES

If (encryption is
enabled) then
restart encryption

LMP_ENCRYPTION_MODE_
REQ (off)

LMP_ACCEPTED

LMP_STOP_ENCRYPTION_
REQ

LMP_ACCEPTED

LMP_ENCRYPTION_MODE_
REQ (on)

LMP_ACCEPTED

LMP_ENCRYPTION_KEY_
SIZE_REQ

LMP_ACCEPTED

LMP_START_ENCRYPTION_
REQ

LMP_ACCEPTED

HCI_Link_Key_Type_Changed HCI_Link_Key_Type_Changed

Figure 4.34: Change to temporary link key

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 2, Part F Page 811
Message Sequence Charts

Step 2: The Host changes to a Semi-permanent Link Key from a Temporary Link Key
using the HCI_Link_Key_Selection command. (See Figure 4.35.)

LM­A LM­B
Host A Central Peripheral Host B

Step 2: Host requests switch from Temporary Link Key to Semi­permanent Link Key

HCI_Link_Key_Selection
(semi­permanent link key)

HCI_Command_Status

LMP_USE_SEMI_
PERMANENT_KEY

LMP_ACCEPTED

If (encryption is
enabled) then
restart encryption

LMP_ENCRYPTION_MODE_
REQ (off)

LMP_ACCEPTED

LMP_STOP_ENCRYPTION_
REQ

LMP_ACCEPTED

LMP_ENCRYPTION_MODE_
REQ (on)

LMP_ACCEPTED

LMP_ENCRYPTION_KEY_
SIZE_REQ

LMP_ACCEPTED

LMP_START_ENCRYPTION_
REQ

LMP_ACCEPTED

HCI_Link_Key_Type_Changed HCI_Link_Key_Type_Changed

Figure 4.35: Change to semi-permanent link key

4.8 Read remote supported features

Using the HCI_Read_Remote_Supported_Features command the supported LMP

Features of a remote device can be read. (See Figure 4.36.)

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 2, Part F Page 812
Message Sequence Charts

If the remote supported features have been obtained previously then the Controller may
return them without sending any LMP PDUs.

Step 1: The Host requests the supported features of a remote device.

Host A LM­A LM­B Host B

Step 1: Host A requests Supported Features from Device B

HCI_Read_Remote_Supported_
Features

HCI_Command_Status

LMP_FEATURES_REQ

LMP_FEATURES_RES

HCI_Read_Remote_Supported_
Features_Complete

Figure 4.36: Read remote supported features

4.9 Read remote extended features

Using the HCI_Read_Remote_Extended_Features command the extended LMP
features of a remote device can be read. (See Figure 4.37.)

If the remote extended features have been obtained previously then the Controller may
return them without sending any LMP PDUs.

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 2, Part F Page 813
Message Sequence Charts

Step 1: The Host requests the extended features of a remote device.

Host A LM­A LM­B Host B

Step 1: Host A requests Extended Features from Device B

HCI_Read_Remote_Extended_
Features

HCI_Command_Status

LMP_FEATURES_REQ_EXT

LMP_FEATURES_RES_EXT

HCI_Read_Remote_Extended_
Features_Complete

Figure 4.37: Read remote extended features

4.10 Read clock offset

Using the HCI_Read_Clock_Offset command the device acting as the Central can read
the Clock Offset of a Peripheral (see Figure 4.38). The Clock Offset can be used to
speed up the paging procedure in a later connection attempt.

Step 1: The Host requests the clock offset of a remote device.

LM­A LM­B
Host A (Central) (Peripheral) Host B

Step 1: Central A requests Clock Offset from Peripheral B

HCI_Read_Clock_Offset

HCI_Command_Status

LMP_CLKOFFSET_REQ

LMP_CLKOFFSET_RES

HCI_Read_Clock_Offset_
Complete

Figure 4.38: Read clock offset (Central)

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 2, Part F Page 814
Message Sequence Charts

If the command is requested from the Peripheral, the Controller will directly return an
HCI_Command_Status event and an HCI_Read_Clock_Offset_Complete event without
sending any LMP PDUs (see Figure 4.39).

LM­A LM­B
Host A (Central) (Peripheral) Host B

Step 1: Peripheral A requests Clock Offset from Central B

HCI_Read_Clock_Offset

HCI_Command_Status

HCI_Read_Clock_Offset_
Complete

Figure 4.39: Read clock offset (Peripheral)

4.11 Role switch on an encrypted link using encryption pause and

resume
The HCI_Switch_Role command can be used to explicitly switch the current Central /
Peripheral role of the local device with the specified device. The Central’s Host (A)
requests a role switch with a Peripheral. This will first pause encryption, and then
send the switch request, and the Peripheral will respond with the slot offset and
accepted. The role switch is performed by doing the TDD switch and piconet switch.

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 2, Part F Page 815
Message Sequence Charts

Encryption is resumed, and finally an HCI_Role_Change event is sent on both sides.

(See Figure 4.40.)

LM­A LM­B
Host A Central Peripheral Host B

Role Switch on an Encrypted Link Using Encryption Pause and Resume

HCI_Switch_Role

HCI_Command_Status

LMP_PAUSE_ENCRYPTION_
REQ

LMP_PAUSE_ENCRYPTION_
REQ

LMP_STOP_ENCRYPTION_
REQ

LMP_ACCEPTED

LMP_SWITCH_REQ

LMP_SLOT_OFFSET

LMP_ACCEPTED

Role Switch Occurs

LM­A LM­B
Peripheral Central

LMP_RESUME_ENCRYPTION_
REQ

LMP_START_ENCRYPTION_
REQ

LMP_ACCEPTED

HCI_Encryption_Key_Refresh_ HCI_Encryption_Key_Refresh_
Complete Complete

HCI_Role_Change HCI_Role_Change

Figure 4.40: Role switch on an encrypted link using encryption pause and resume

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 2, Part F Page 816
Message Sequence Charts

4.12 Refreshing encryption keys

The HCI_Refresh_Encryption_Key command may be used by the Central's Host to
explicitly pause and resuming encryption to refresh the encryption key. After encryption
is resumed an HCI_Encryption_Key_Refresh_Complete event is sent on both sides.
(See Figure 4.41).

LM­A LM­B
Host A Central Peripheral Host B

Refreshing the Encryption Key with Encryption Pause and Resume (E0)

Optional HCI initiation

HCI_Refresh_Encryption_Key

HCI_Command_Status

LMP_PAUSE_ENCRYPTION_
REQ

LMP_PAUSE_ENCRYPTION_
REQ

LMP_STOP_ENCRYPTION_
REQ

LMP_ACCEPTED

LMP_START_ENCRYPTION_
REQ

LMP_ACCEPTED

HCI_Encryption_Key_Refresh_ HCI_Encryption_Key_Refresh_
Complete Complete

Figure 4.41: Refreshing encryption keys (E0)

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 2, Part F Page 817
Message Sequence Charts

When both devices support Secure Connections, the encryption key refresh sequence
is performed as follows.

LM­A LM­B
Host A Central Peripheral Host B

Refreshing the Encryption Key with Encryption Pause and Resume (AES­CCM)

HCI_Refresh_Encryption_Key

HCI_Command_Status

LMP_PAUSE_ENCRYPTION_
AES_REQ

LMP_PAUSE_ENCRYPTION_
REQ

LMP_STOP_ENCRYPTION_
REQ

LMP_ACCEPTED

LMP_START_ENCRYPTION_
REQ

LMP_ACCEPTED

HCI_Encryption_Key_Refresh_ HCI_Encryption_Key_Refresh_
Complete Complete

Figure 4.42: Refreshing encryption keys (AES-CCM)

4.13 Read remote version information

Using the HCI_Read_Remote_Version_Information command the version information of
a remote device can be read. (See Figure 4.43.)

If the remote version information has been obtained previously then the Controller may
return them without sending any LMP PDUs.

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 2, Part F Page 818
Message Sequence Charts

Step 1: The Host requests the version information of a remote device.

Host A LM­A LM­B Host B

Step 1: Host A requests Remote Version Information from Host B

HCI_Read_Remote_
Version_Information

HCI_Command_Status

LMP_VERSION_REQ

LMP_VERSION_RES

HCI_Read_Remote_Version_
Information_Complete

Figure 4.43: Read remote version information

4.14 QoS setup

Using the HCI_Flow_Specification command the Quality of Service (QoS) and Flow
Specification requirements of a connection can be notified to a Controller. The
Controller may then change the quality of service parameters with a remote device.
(See Figure 4.44.)

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 2, Part F Page 819
Message Sequence Charts

Step 1: The Host sends QoS parameters to a remote device.

LM­A LM­B
Host A Central Peripheral Host B

Step 1: Host A notifies LM­B of QoS parameters

HCI_Flow_Specification (Tx)

HCI_Command_Status

HCI_Flow_Specification_
Complete (Tx)

HCI_Flow_Specification (Rx)

HCI_Command_Status

LMP_QUALITY_OF_SERVICE_
REQ

LMP_ACCEPTED

HCI_Flow_Specification_ HCI_Flow_Specification_
Complete (Rx) Complete (Rx)

Figure 4.44: QoS flow specification

4.15 Switch role

The HCI_Switch_Role command can be used to explicitly switch the current Central /
Peripheral role of the local device with the specified device.

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 2, Part F Page 820
Message Sequence Charts

Step 1a: The Central’s Host (A) requests a role switch with a Peripheral. This will send
the switch request, and the Peripheral will respond with the slot offset and accepted.
(See Figure 4.45.)

LM­A LM­B
Host A Central Peripheral Host B

Step 1a: Central’s Host A requests Role Switch with Peripheral Device B

HCI_Switch_Role

HCI_Command_Status

LMP_SWITCH_REQ

LMP_SLOT_OFFSET

LMP_ACCEPTED

Figure 4.45: Central requests role switch

Step 1b: The Peripheral’s Host (B) requests a role switch with a Central. This will
send the slot offset and the switch request, and the Central will respond with a
LMP_ACCEPTED PDU. (See Figure 4.46.)

LM­A LM­B
Host A Central Peripheral Host B

Step 1b: Peripheral’s Host B requests Role Switch with Central Device B

HCI_Switch_Role

HCI_Command_Status

LMP_SLOT_OFFSET

LMP_SWITCH_REQ

LMP_ACCEPTED

Figure 4.46: Peripheral requests role switch

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 2, Part F Page 821
Message Sequence Charts

Step 2: The role switch is performed by doing the TDD switch and piconet switch.
Finally an HCI_Role_Change event is sent on both sides. (See Figure 4.47.)

LM­A LM­B
Host A Central Peripheral Host B

Step 2: Role Switch is performed

Role Switch performed

using TDD Switch

Piconet Switch

HCI_Role_Change (Peripheral) HCI_Role_Change (Central)

Figure 4.47: Role switch is performed

4.16 [This section is no longer used]

4.17 [This section is no longer used]

4.18 Slot availability mask

Step 1: The setup of SAM may be triggered by the Link Manager for MWS coexistence
or topology management purposes. SAM setup may be triggered by HCI commands

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 2, Part F Page 822
Message Sequence Charts

as shown in Figure 4.48 or by the real-time signals (e.g. MWS_PATTERN_Index,

FRAME_SYNC, etc.) from the Coexistence Logical Interface (see [Vol 7] Part A ).

Piconet Clock Adjustment may be performed to create more available slot pairs per
MWS frame.

Host A LM­A LM­B Host B

Step 1: Device A performs Piconet Clock Adjust

Optional

HCI_Set_MWS_Transport_Layer

HCI_Command_Complete

HCI_Set_MWS_Signaling

HCI_Command_Complete

HCI_Set_External_Frame_
Configuration

HCI_Command_Complete

HCI_Set_MWS_PATTERN_
Configuration

HCI_Command_Complete

PCA carried out

Figure 4.48: SAM configuration setup on device A

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 2, Part F Page 823
Message Sequence Charts

Step 2: The Link Manager on device A sends the SAM configuration to device B and
then selects a SAM map (see Figure 4.49).

Host A LM­A LM­B Host B

Step 2: SAM configuration set up and enabled

LM A decides
to enable SAM

LMP_SAM_SET_TYPE0

LMP_ACCEPTED_EXT

LMP_SAM_DEFINE_MAP

LMP_ACCEPTED_EXT

LMP_SAM_SWITCH

LMP_ACCEPTED_EXT

HCI_SAM_Status_Change HCI_SAM_Status_Change

Figure 4.49: SAM configuration transmitted to device B

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 2, Part F Page 824
Message Sequence Charts

Step 3: Device A receives a new configuration (possibly over HCI), sends it to device B,
and switches to using it (see Figure 4.50).

Host A LM­A LM­B Host B

Step 3: Device A changes the SAM slot map

Optional

HCI_Set_MWS_PATTERN_
Configuration

HCI_Command_Complete

LM A decides to add
a new SAM slot map

LMP_SAM_DEFINE_MAP
(new SAM_Index)

LMP_ACCEPTED_EXT

LM A decides to switch
to the new slot map

LMP_SAM_SWITCH
(new SAM_Index)

LMP_ACCEPTED_EXT

HCI_SAM_Status_Change HCI_SAM_Status_Change
(new Local_SAM_Index) (new Remote_SAM_Index)

Figure 4.50: SAM configuration change

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 2, Part F Page 825
Message Sequence Charts

4.19 LMP transaction collision

The Link Managers of both the Central and Peripheral may initiate the same LMP
transaction at the same time.

LM­A LM­B
Host A Central Peripheral Host B

Step 1: Both Host A and Host B request Sniff Mode

HCI_Sniff_Mode HCI_Sniff_Mode

HCI_Command_Status HCI_Command_Status

LM
P_ REQ
SN F_
IF F
F_ NI
REQ P _S
LM

LMP_NOT_ACCEPTED
(LMP Error
Transaction Collision)

HCI_Mode_Change
(LMP Error
Transaction Collision)

LMP_ACCEPTED

Sniff mode started

HCI_Mode_Change (sniff) HCI_Mode_Change (sniff)

Figure 4.51: LMP transaction collision

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 2, Part F Page 826
Message Sequence Charts

5 SYNCHRONOUS CONNECTION ESTABLISHMENT

AND DETACHMENT

5.1 Synchronous connection setup

Using the HCI_Setup_Synchronous_Connection command, a Host can add a
synchronous logical channel to the link. A synchronous logical link can be provided
by creating a SCO or an eSCO logical transport.

Note: An ACL connection must be established before a synchronous connection can be

created.

Step 1a: Central requests a synchronous connection with a device. (See Figure 5.1.)

LM­A LM­B
Host A Central Peripheral Host B

Step 1a: Host A requests a synchronous connection with Device B

HCI_Setup_Synchronous_
Connection (EV3 | EV4 | EV5)

HCI_Command_Status

LMP_eSCO_LINK_REQ

HCI_Connection_Request
(eSCO)

HCI_Accept_Synchronous_
Connection_Request
(EV3 | EV4 | EV5)

LMP_eSCO_LINK_REQ

LMP_eSCO_LINK_REQ

LMP_ACCEPTED_EXT

Synchronous connection started

HCI_Synchronous_Connection_ HCI_Synchronous_Connection_
Complete (eSCO) Complete (eSCO)

Figure 5.1: Central requests synchronous EV3, EV4, or EV5 connection

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 2, Part F Page 827
Message Sequence Charts

Step 1b: Peripheral requests a synchronous connection with a device. (See Figure 5.2.)

LM­A LM­B
Host A Central Peripheral Host B

Step 1b: Host B requests a synchronous connection with Device A

HCI_Setup_Synchronous_
Connection (EV3 | EV4 | EV5)

HCI_Command_Status

LMP_eSCO_LINK_REQ

HCI_Connection_Request
(eSCO)

HCI_Accept_Synchronous_
Connection_Request
(EV3 | EV4 | EV5)

HCI_Command_Status

LMP_eSCO_LINK_REQ

LMP_eSCO_LINK_REQ

LMP_eSCO_LINK_REQ

LMP_ACCEPTED_EXT

Synchronous connection started

HCI_Synchronous_Connection_ HCI_Synchronous_Connection_
Complete (eSCO) Complete (eSCO)

Figure 5.2: Peripheral requests synchronous EV3, EV4, or EV5 connection

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 2, Part F Page 828
Message Sequence Charts

Step 1c: Central requests a SCO connection with a device. (See Figure 5.3.)

LM­A LM­B
Host A Central Peripheral Host B

Step 1c: Host A requests a synchronous connection with Device B

HCI_Setup_Synchronous_
Connection (HV1|HV2|HV3|
EV3|EV4|EV5)

HCI_Command_Status

LMP_SCO_LINK_REQ

HCI_Connection_Request
(SCO)

HCI_Accept_Connection_
Request

HCI_Command_Status

LMP_ACCEPTED

Synchronous connection started

HCI_Synchronous_Connection_ HCI_Connection_Complete
Complete (SCO)

Figure 5.3: Central requests synchronous connection using SCO

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 2, Part F Page 829
Message Sequence Charts

Step 1d: Central requests a SCO connection with a device. (See Figure 5.4.)

LM­A LM­B
Host A Central Peripheral Host B

Step 1d: Host A requests a synchronous connection with Device B

HCI_Setup_Synchronous_
Connection (HV1|HV2|HV3|
EV3|EV4|EV5)

HCI_Command_Status

LMP_SCO_LINK_REQ

HCI_Connection_Request (SCO)

HCI_Accept_Connection_
Request

HCI_Command_Status

LMP_ACCEPTED

Synchronous connection started

HCI_Synchronous_Connection_ HCI_Connection_Complete
Complete

Figure 5.4: Central requests synchronous connection with legacy Peripheral

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 2, Part F Page 830
Message Sequence Charts

Step 1e: Host device requests a SCO connection with a device. (See Figure 5.5.)

LM­A LM­B
Host A Central Peripheral Host B

Step 1e: Legacy Host B requests a synchronous connection with Central Device A

HCI_Add_SCO_Connection

HCI_Command_Status

LMP_SCO_LINK_REQ

HCI_Connection_Request (SCO)

HCI_Accept_Synchronous_
Connection_Request
(HV1 | HV2 | HV3)

HCI_Command_Status

LMP_SCO_LINK_REQ

LMP_ACCEPTED

Synchronous connection started

HCI_Synchronous_Connection_ HCI_Connection_Complete
Complete

Figure 5.5: Any device that supports only SCO connections requests a synchronous connection with a
device

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 2, Part F Page 831
Message Sequence Charts

Step 2a: Central renegotiates eSCO connection (see Figure 5.6.)

LM­A LM­B
Host A Central Peripheral Host B

Synchronous connection exists

with EV3, TeSCO =6, and WeSCO =4

Step 2a: Host A changes synchronous connection with Device B

HCI_Setup_Synchronous_
Connection (Retransmission_
effort = 0x00)

HCI_Command_Status

LMP_eSCO_LINK_REQ

LMP_eSCO_LINK_REQ

LMP_eSCO_LINK_REQ

LMP_ACCEPTED_EXT

Synchronous connection changed

HCI_Synchronous_Connection_ HCI_Synchronous_Connection_
Changed Changed

Figure 5.6: Central renegotiates eSCO connection

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 2, Part F Page 832
Message Sequence Charts

Step 2b: Peripheral renegotiates eSCO connection (see Figure 5.7.)

LM­A LM­B
Host A Central Peripheral Host B

Synchronous connection exists

with EV3, TeSCO =6, and WeSCO =4

Step 2b: Host B changes synchronous connection with Device A

HCI_Setup_Synchronous_
Connection (EV3,
Retransmission_effort = 0x00)

HCI_Command_Status

LMP_eSCO_LINK_REQ

LMP_eSCO_LINK_REQ

LMP_ACCEPTED_EXT

Synchronous connection changed

HCI_Synchronous_Connection_ HCI_Synchronous_Connection_
Changed Changed

Figure 5.7: Peripheral renegotiates eSCO connection

Step 3a: eSCO disconnection. (See Figure 5.8.)

LM­A LM­B
Host A Central Peripheral Host B

Step 3a: Host A requests eSCO disconnection from Device B

HCI_Disconnect

HCI_Command_Status

LMP_REMOVE_eSCO_LINK_
REQ

LMP_ACCEPTED_EXT

Synchronous connection exited

HCI_Disconnection_Complete HCI_Disconnection_Complete

Figure 5.8: Synchronous disconnection of eSCO connection

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 2, Part F Page 833
Message Sequence Charts

Step 3b: SCO disconnection. (See Figure 5.9.)

LM­A LM­B
Host A Central Peripheral Host B

Step 3b: Host A requests SCO disconnection from Device B

HCI_Disconnect

HCI_Command_Status

LMP_REMOVE_SCO_LINK_
REQ

LMP_ACCEPTED

Synchronous connection exited

HCI_Disconnection_Complete HCI_Disconnection_Complete

Figure 5.9: Synchronous disconnection of SCO connection

5.2 Synchronous connection setup with enhanced synchronous

commands
Using the HCI_Enhanced_Setup_Synchronous_Connection command, a Host can add
a synchronous logical channel to the link. A synchronous logical link can be provided by
creating a SCO or an eSCO logical transport.

Note: An ACL connection must be established before a synchronous connection can be

created.

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 2, Part F Page 834
Message Sequence Charts

Step 1a: Central requests a synchronous connection with a Peripheral.

LM­A LM­B
Host A Central Peripheral Host B

Step 1a: Host A requests a synchronous connection with Device B

HCI_Enhanced_Setup_
Synchronous_Connection
(EV3|EV4|EV5|2EV3|2EV5|
3EV3|3EV5)

HCI_Command_Status

LMP_eSCO_LINK_REQ

HCI_Connection_Request
(eSCO)

HCI_Accept_Synchronous_
Connection_Request
(EV3|EV4|EV5|2EV3|2EV5|
3EV3|3EV5)

HCI_Command_Status

LMP_eSCO_LINK_REQ

LMP_eSCO_LINK_REQ

LMP_ACCEPTED_EXT

Synchronous connection started

HCI_Synchronous_Connection_ HCI_Synchronous_Connection_
Complete (eSCO) Complete (eSCO)

Figure 5.10: Central requests synchronous connection (EV3, EV4, EV5, 2-EV3, 2-EV5, 3-EV3, or 3-EV5)

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 2, Part F Page 835
Message Sequence Charts

Step 1b: Peripheral requests a synchronous connection with a Central.

LM­A LM­B
Host A Central Peripheral Host B

Step 1b: Host B requests a synchronous connection with Device A

HCI_Enhanced_Setup_
Synchronous_Connection
(EV3|EV4|EV5|2EV3|2EV5|
3EV3|3EV5)

HCI_Command_Status

LMP_eSCO_LINK_REQ

HCI_Connection_Request
(eSCO)

HCI_Enhanced_Accept_
Synchronous_Connection_
Request
(EV3|EV4|EV5|2EV3|2EV5|
3EV3|3EV5)

HCI_Command_Status

LMP_eSCO_LINK_REQ

LMP_eSCO_LINK_REQ

LMP_eSCO_LINK_REQ

LMP_ACCEPTED_EXT

Synchronous connection started

HCI_Synchronous_Connection_ HCI_Synchronous_Connection_
Complete (eSCO) Complete (eSCO)

Figure 5.11: Peripheral requests synchronous connection (EV3, EV4, EV5, 2-EV3, 2-EV5, 3-EV3, or
3-EV5)

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 2, Part F Page 836
Message Sequence Charts

Step 1c : Central requests a SCO connection with a Peripheral.

LM­A LM­B
Host A Central Peripheral Host B

Step 1c: Host A requests a synchronous connection with Device B

HCI_Enhanced_Setup_
Synchronous_Connection
(HV1|HV2|HV3|EV3|EV4|EV5|
2EV3|2EV5|3EV3|3EV5)

HCI_Command_Status

LMP_SCO_LINK_REQ

HCI_Connection_Request (SCO)

HCI_Accept_Connection_
Request

HCI_Command_Status

LMP_ACCEPTED

Synchronous connection started

HCI_Synchronous_Connection_ HCI_Connection_
Complete (SCO) Complete (SCO)

Figure 5.12: Central requests synchronous connection (HV1, HV2, HV3, EV3, EV4, EV5, 2EV3, 2EV5,
3EV3, or 3EV5)

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 2, Part F Page 837
Message Sequence Charts

Step 1d : Peripheral requests a SCO connection with a Central.

LM­A LM­B
Host A Central Peripheral Host B

Step 1d: Host B requests a synchronous connection with Device A

HCI_Add_SCO_Connection
(HV1|HV2|HV3)

HCI_Command_Status

LMP_SCO_LINK_REQ

HCI_Connection_Request (SCO)

HCI_Enhanced_Accept_
Synchronous_Connection_
Request
(HV1|HV2|HV3)

HCI_Command_Status

LMP_SCO_LINK_REQ

LMP_ACCEPTED

Synchronous connection started

HCI_Synchronous_Connection_ HCI_Connection_Complete
Complete (SCO) (SCO)

Figure 5.13: Peripheral requests synchronous connection (HV1, HV2, or HV3)

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 2, Part F Page 838
Message Sequence Charts

Step 2a: Central renegotiates eSCO connection.

LM­A LM­B
Host A Central Peripheral Host B

Step 2a: Host A renegotiates synchronous connection with Device B

HCI_Enhanced_Setup_
Synchronous_Connection
(EV3|EV4|EV5|2EV3|2EV5|
3EV3|3EV5)

HCI_Command_Status

LMP_eSCO_LINK_REQ

LMP_eSCO_LINK_REQ

LMP_eSCO_LINK_REQ

LMP_ACCEPTED_EXT

Synchronous connection changed

HCI_Synchronous_Connection_ HCI_Synchronous_Connection_
Changed Changed

Figure 5.14: Central renegotiates synchronous connection parameter change

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 2, Part F Page 839
Message Sequence Charts

Step 2b: Peripheral renegotiates eSCO connection.

LM­A LM­B
Host A Central Peripheral Host B

Step 2b: Host B renegotiates synchronous connection with Device A

HCI_Enhanced_Setup_
Synchronous_Connection
(EV3|EV4|EV5|2EV3|2EV5|
3EV3|3EV5)

HCI_Command_Status

LMP_eSCO_LINK_REQ

LMP_eSCO_LINK_REQ

LMP_eSCO_LINK_REQ

LMP_eSCO_LINK_REQ

LMP_ACCEPTED_EXT

Synchronous connection changed

HCI_Synchronous_Connection_ HCI_Synchronous_Connection_
Changed Changed

Figure 5.15: Peripheral renegotiates synchronous connection parameter change

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 2, Part F Page 840
Message Sequence Charts

6 SNIFF AND HOLD MODES

Entry into Sniff mode or Hold mode requires an established ACL connection.

6.1 Sniff mode

The HCI_Sniff_Mode command is used to enter Sniff mode. The HCI_Exit_Sniff_Mode
command is used to exit Sniff mode.

Step 1: Host requests to enter Sniff mode. Multiple LMP_SNIFF_REQ PDUs may be
sent as the parameters for Sniff mode are negotiated. (See Figure 6.1.)

Host A LM­A LM­B Host B

Step 1: Host A requests Sniff mode with Device B

HCI_Sniff_Mode

HCI_Command_Status

LMP_SNIFF_REQ

LMP_ACCEPTED

Sniff mode started

HCI_Mode_Change (sniff) HCI_Mode_Change (sniff)

Figure 6.1: Sniff mode request

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 2, Part F Page 841
Message Sequence Charts

Step 2: Host requests to exit Sniff mode. (See Figure 6.2.)

Host A LM­A LM­B Host B

Step 2: Host A exits Sniff mode with Device B

HCI_Exit_Sniff_Mode

HCI_Command_Status

LMP_UNSNIFF_REQ

LMP_ACCEPTED

Sniff mode exited

HCI_Mode_Change (active) HCI_Mode_Change (active)

Figure 6.2: Exit Sniff mode request

6.2 Hold mode

The HCI_Hold_Mode command can be used to place a device into Hold mode. The
Controller may do this by either negotiating the Hold mode parameters or forcing Hold
mode. Hold mode will automatically end after the negotiated length of time.

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 2, Part F Page 842
Message Sequence Charts

Step 1a: A Host requests Hold mode. (See Figure 6.3.)

LM­A LM­B
Host A Central Peripheral Host B

Step 1a: Central’s Host A requests Hold Mode with Peripheral B

HCI_Hold_Mode

HCI_Command_Status

LMP_SET_AFH (AHS(79))

LMP_HOLD_REQ

LMP_ACCEPTED

Hold mode started

HCI_Mode_Change (hold) HCI_Mode_Change (hold)

Figure 6.3: Hold request

Step 1b: A Host may force Hold mode. (See Figure 6.4.)

LM­A LM­B
Host A Central Peripheral Host B

Step 1b: Central’s Host A forces Hold Mode with Peripheral B

HCI_Hold_Mode

HCI_Command_Status

LMP_SET_AFH (AHS(79))

LMP_HOLD

Hold mode started

HCI_Mode_Change (hold) HCI_Mode_Change (hold)

Figure 6.4: Central forces Hold mode

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 2, Part F Page 843
Message Sequence Charts

Step 1c: A Peripheral requests Hold mode. (See Figure 6.5.)

LM­A LM­B
Host A Central Peripheral Host B

Step 1c: Peripheral’s Host B forces Hold Mode with Central A

HCI_Hold_Mode

HCI_Command_Status

LMP_HOLD

LMP_SET_AFH (AHS(79))

LMP_HOLD

Hold mode started

HCI_Mode_Change (hold) HCI_Mode_Change (hold)

Figure 6.5: Peripheral forces Hold mode

Step 2: When Hold mode completes the Hosts are notified using the
HCI_Mode_Change event. (See Figure 6.6.)

LM­A LM­B
Host A Central Peripheral Host B

Step 2: Hold mode completes

Hold mode completes

HCI_Mode_Change (active) HCI_Mode_Change (active)

LMP_SET_AFH (current_map)

Figure 6.6: Hold mode completes

6.3 [This section is no longer used]

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 2, Part F Page 844
Message Sequence Charts

7 BUFFER MANAGEMENT, FLOW CONTROL

Buffer management is very important for resource limited devices.

This can be achieved on the Host Controller interface using the
HCI_Read_Buffer_Size command, and the HCI_Number_Of_Completed_Packets
event, and the HCI_Set_Controller_To_Host_Flow_Control, HCI_Host_Buffer_Size and
HCI_Host_Number_Of_Completed_Packets commands.

Step 1: During initialization, the Host reads the buffer sizes available in the
Controller. When an HCI Data packet has been transferred to the remote device,
and a Baseband acknowledgment has been received for this data, then an
HCI_Number_Of_Completed_Packets event will be generated. (See Figure 7.1.)

LM­A LM­B
Host A » BB­A » BB­B Host B

Step 1: Host A Initializes and uses Flow Control

HCI_Read_Buffer_Size

HCI_Command_Complete

After an ACL connection is established

ACL Data packet

Data packet

BB ACK

HCI_Number_Of_Completed_ ACL Data packet

Packets

Figure 7.1: Host to Controller flow control

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 2, Part F Page 845
Message Sequence Charts

Step 2: During initialization, the Host notifies the Controller that Host flow control
shall be used, and then the Host buffer sizes available. When a data packet
has been received from a remote device, an HCI Data packet is sent to the
Host from the Controller, and the Host shall acknowledge its receipt by sending
HCI_Host_Number_Of_Completed_Packets command. (See Figure 7.2.)

LM­A LM­B
Host A » BB­A » BB­B Host B

Step 2: Host A Initializes and uses Host Flow Control

HCI_Set_Controller_To_Host_
Flow_Control

HCI_Command_Complete

HCI_Host_Buffer_Size

HCI_Command_Complete

After an ACL connection is established

Data packet

Data packet

ACK

Data packet

HCI_Host_Number_Of_
Completed_Packets

Figure 7.2: Controller to Host flow control

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 2, Part F Page 846
Message Sequence Charts

8 LOOPBACK MODE

The loopback modes are used for testing of a device only.

8.1 Local Loopback mode

The Local Loopback mode is used to loopback received HCI commands, and HCI ACL
Data and HCI Synchronous Data packets sent from the Host to the Controller.

Step 1: The Host enters Local Loopback mode. Four HCI_Connection_Complete

events are generated and then an HCI_Command_Complete event. (See Figure 8.1.)

LM­A LM­B
Host A » BB­A » BB­B Host B

Step 1: Host A enters Local Loopback Mode

HCI_Write_Loopback_Mode
(local)

HCI_Connection_Complete
(ACL)

HCI_Connection_Complete
(SCO or eSCO)

HCI_Connection_Complete
(SCO or eSCO)

HCI_Connection_Complete
(SCO or eSCO)

HCI_Command_Complete

Figure 8.1: Entering Local Loopback mode

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 2, Part F Page 847
Message Sequence Charts

Step 2a: The Host sending HCI Data packet will receive the exact same data back in
HCI Data packets from the Controller. (See Figure 8.2.)

LM­A LM­B
Host A » BB­A » BB­B Host B

Step 2a: Host A sends data to Controller while in Local Loopback Mode

ACL Data packet

ACL Data packet

ACL Data packet

ACL Data packet

Figure 8.2: Looping back data in Local Loopback mode

Step 2b: The Host sending most HCI Command packets to the Controller will receive
an HCI_Loopback_Command event with the contents of the HCI Command packet in
the payload. (See Figure 8.3.)

LM­A LM­B
Host A » BB­A » BB­B Host B

Step 2b: Host A sends HCI commands to Controller while in Local Loopback Mode

HCI Command packet

HCI_Loopback

HCI Command packet

HCI_Loopback

Figure 8.3: Looping back commands in Local Loopback mode

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 2, Part F Page 848
Message Sequence Charts

Step 3: The Host exits Local Loopback mode. Multiple HCI_Disconnection_Complete

events are generated before the HCI_Command_Complete event. (See Figure 8.4.)

LM­A LM­B
Host A » BB­A » BB­B Host B

Step 3: Host A Exits Local Loopback Mode

HCI_Write_Loopback_Mode
(no loopback)

HCI_Disconnection_Complete
(ACL)

HCI_Disconnection_Complete
(SCO or eSCO)

HCI_Disconnection_Complete
(SCO or eSCO)

HCI_Disconnection_Complete
(SCO or eSCO)

HCI_Command_Complete

Figure 8.4: Exiting Local Loopback mode

8.2 Remote Loopback mode

The Remote Loopback mode is used to loopback data to a remote device over the air.

Step 1: The local device first enables remote loopback. The remote Host then sets up a
connection to the local device. (See Figure 8.5.)

LM­A LM­B
Host A » BB­A » BB­B Host B

Step 1: Host A enters Remote Loopback Mode

HCI_Write_Loopback_Mode
(remote)

HCI_Command_Complete

Host B creates ACL connection

Figure 8.5: Entering Remote Loopback mode

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 2, Part F Page 849
Message Sequence Charts

Step 2: Any data received from the remote Host will be looped back in the Controller of
the local device. (See Figure 8.6.)

LM­A LM­B
Host A » BB­A » BB­B Host B

Step 2: Host B sends data packets that will loopback through Device A

HCI Data packet

Data packet

ACK

HCI_Number_Of_Completed_
Packets

Data packet

HCI Data packet

Figure 8.6: Looping back data in Remote Loopback mode

Step 3: The local Host exits Remote Loopback mode. Any connections can then be
disconnected by the remote device. (See Figure 8.7.)

LM­A LM­B
Host A » BB­A » BB­B Host B

Step 3: Host A exits Remote Loopback Mode

HCI_Write_Loopback_Mode
(no loopback)

HCI_Command_Complete

Host B disconnects ACL connection

Figure 8.7: Exiting Remote Loopback mode

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 2, Part F Page 850
Message Sequence Charts

9 CONNECTIONLESS PERIPHERAL BROADCAST

SERVICES

Figure 9.1 illustrates the Truncated Page procedure.

Controller Controller
Host A A B Host B

Step 1: Device B Pages Device A Using Truncated Paging

HCI_Write_Scan_Enable

HCI_Command_Complete

HCI_Truncated_Page

HCI_Command_Status

Page

Page

Page Response

HCI_Truncated_Page_Complete

pagerespTO

HCI_Peripheral_Page_
Response_Timeout

Figure 9.1: Truncated paging

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 2, Part F Page 851
Message Sequence Charts

Figure 9.2 illustrates how Device A starts transmitting Connectionless Peripheral

Broadcast packets to Device B.

Controller Controller
Host A A B Host B

Step 2: Device A Starts Connectionless Peripheral Broadcast

HCI_Set_Reserved_LT_ADDR

HCI_Command_Complete

HCI_Set_Connectionless_
Peripheral_Broadcast_Data

HCI_Command_Complete

HCI_Set_Connectionless_
Peripheral_Broadcast

HCI_Command_Complete

Connectionless Peripheral
Broadcast packet

Connectionless Peripheral
Broadcast packet

Figure 9.2: Connectionless Peripheral Broadcast transmitter start

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 2, Part F Page 852
Message Sequence Charts

Figure 9.3 shows the Synchronization Train feature. Device A is the Connectionless
Peripheral Broadcast Transmitter. Device B is the Connectionless Peripheral Broadcast
Receiver.

Controller Controller
Host A A B Host B

Step 3: Device A Starts the Synchronization Train

HCI_Write_Synchronization_
Train_Parameters

HCI_Command_Complete

HCI_Start_Synchronization_Train

HCI_Command_Status

Synchronization Train packet

Synchronization Train packet

HCI_Receive_Synchronization_
Train

HCI_Command_Status

Synchronization Train packet

HCI_Synchronization_Train_
Received

Synchronization Train packet

Synchronization Train packet

synchronization_trainTO

HCI_Synchronization_Train_
Complete

Figure 9.3: Synchronization Train

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 2, Part F Page 853
Message Sequence Charts

Figure 9.4 illustrates how Device B starts receiving Connectionless Peripheral

Broadcast packets from Device A.

Controller Controller
Host A A B Host B

Step 4: Device B Starts Listening to Connectionless Peripheral Broadcast Packets

Connectionless Peripheral
Broadcast packet

Connectionless Peripheral
Broadcast packet

HCI_Set_Connectionless_
Peripheral_Broadcast_Receive

HCI_Command_Complete

Connectionless Peripheral
Broadcast packet

HCI_Connectionless_
Peripheral_Broadcast_Receive

Connectionless Peripheral
Broadcast packet

HCI_Connectionless_
Peripheral_Broadcast_Receive

Figure 9.4: Connectionless Peripheral Broadcast receiver start

Bluetooth SIG Proprietary Version Date: 2024-08-27

 BR/EDR Controller
Part G

SAMPLE DATA

Sample data for various parts of the Baseband

specification. All sample data are provided for
reference purpose only; they are intended as a
complement to the definitions provided elsewhere
in the specification. They can be used to check
the behavior of an implementation and avoid
misunderstandings.

Bluetooth SIG Proprietary

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 2, Part G Page 855
Sample Data

CONTENTS

1 Encryption sample data ........................................................................... 857

1.1 E0 encryption sample data .......................................................... 857
1.1.1 Generating K_session from K_enc .............................. 857
1.1.2 First set of sample data ............................................... 860
1.1.3 Second set of sample data .......................................... 870
1.1.4 Third set of samples .................................................... 880
1.1.5 Fourth set of samples .................................................. 890
1.2 AES-CCM encryption sample data ............................................. 900
1.2.1 Sample data 1 (DM1, Central → Peripheral) ............... 900
1.2.2 Sample data 2 (DM1, Central → Peripheral) ............... 901
1.2.3 Sample data 3 (DM1, Peripheral → Central) ............... 902
1.2.4 Sample data 4 (DM1, Central → Peripheral) ............... 903
1.2.5 Sample data 5 (DM1, Peripheral → Central) ............... 904
1.2.6 Sample data 6 (DH1, Central → Peripheral) ............... 905
1.2.7 Sample data 7 (DH1, Peripheral → Central) ............... 906
1.2.8 Sample data 8 (DH1, Central → Peripheral) ............... 907
1.2.9 Sample data 9 (DH1, Peripheral → Central) ............... 908
1.2.10 Sample data 10 (2-DH3, Central → Peripheral) .......... 909
1.2.11 Sample data 11 (2-DH3, Peripheral → Central) .......... 913
1.2.12 Sample data 12 (3-DH5, Central → Peripheral) .......... 917
1.2.13 Sample data 13 (3-DH5, Peripheral → Central) .......... 927
1.2.14 Sample data 14 (EV3) ................................................. 937

2 Frequency hopping sample data ............................................................. 938

2.1 First set ........................................................................................ 938
2.2 Second set .................................................................................. 944
2.3 Third set ...................................................................................... 950

3 Access code sample data ........................................................................ 957

4 HEC and packet header sample data ...................................................... 960

5 CRC sample data ...................................................................................... 961

6 Complete sample packets ........................................................................ 962

6.1 Example of DH1 packet .............................................................. 962
6.2 Example of DM1 packet .............................................................. 964

7 Secure Simple Pairing sample data ........................................................ 966

7.1 Elliptic curve sample data ........................................................... 966

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 2, Part G Page 856
Sample Data

7.1.1 P-192 sample data ...................................................... 966

7.1.1.1 P-192 data set 1 ........................................... 966
7.1.1.2 P-192 data set 2 ........................................... 966
7.1.1.3 P-192 data set 3 ........................................... 966
7.1.1.4 P-192 data set 4 ........................................... 966
7.1.1.5 P-192 data set 5 ........................................... 966
7.1.1.6 P-192 data set 6 ........................................... 967
7.1.1.7 P-192 data set 7 ........................................... 967
7.1.1.8 P-192 data set 8 ........................................... 967
7.1.1.9 P-192 data set 9 ........................................... 967
7.1.1.10 P-192 data set 10 ......................................... 967
7.1.2 P-256 sample data ...................................................... 967
7.1.2.1 P-256 data set 1 ........................................... 967
7.1.2.2 P-256 data set 2 ........................................... 968
7.2 Hash functions sample data ........................................................ 968
7.2.1 f1() ............................................................................... 968
7.2.1.1 f1() with P-192 inputs ................................... 968
7.2.1.2 f1() with P-256 inputs ................................... 969
7.2.2 g() ................................................................................ 970
7.2.2.1 g() with P-192 inputs .................................... 970
7.2.2.2 g() with P-256 inputs .................................... 970
7.2.3 f2() ............................................................................... 970
7.2.3.1 f2() with P-192 inputs ................................... 970
7.2.3.2 f2() with P-256 inputs ................................... 970
7.2.4 f3() ............................................................................... 971
7.2.4.1 f3() with P-192 inputs ................................... 971
7.2.4.2 f3() with P-256 inputs ................................... 977
7.2.5 [This section is no longer used] ................................... 977
7.2.6 h4() .............................................................................. 977
7.2.7 h5() .............................................................................. 978
7.2.8 h3() .............................................................................. 978

8 Whitening sequence sample data ........................................................... 979

9 FEC sample data ....................................................................................... 982

10 Encryption key sample data .................................................................... 983

10.1 Four tests of E1 ........................................................................... 983
10.2 Four tests of E21 ......................................................................... 988
10.3 Three tests of E22 ....................................................................... 991
10.4 Tests of E22 with Pin augmenting ............................................... 993
10.5 Four tests of E3 ......................................................................... 1004

11 Connectionless Peripheral Broadcast sample data ............................ 1009

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 2, Part G Page 857
Sample Data

1 ENCRYPTION SAMPLE DATA

1.1 E0 encryption sample data

This section contains four sets of sample data for the encryption process.

With respect to the functional description of the E0 encryption algorithm in the Bluetooth
Baseband specification, the contents of registers and resulting concurrent values
are listed as well. This by no means excludes different implementations (as far as
they produce the same encryption stream) but is intended to describe the functional
behavior.

1.1.1 Generating K_session from K_enc

where K_session(x) = g2(x)(K_enc(x) mod g1(x)).

Note: All polynomials are in hexadecimal notation.

' L ' is the effective key length in bytes.
The notation ' p: [m] ' implies that deg(p(x)) = m.

MSB LSB
L = 1
g1: [8] 00000000 00000000 00000000 0000011d
g2: [119] 00e275a0 abd218d4 cf928b9b bf6cb08f
K_enc: a2b230a4 93f281bb 61a85b82 a9d4a30e
K_enc mod g1: [7] 00000000 00000000 00000000 0000009f
g2(K_enc mod g1): [126] 7aa16f39 59836ba3 22049a7b 87f1d8a5
-----------------------------------------------------------------
L = 2
g1: [16] 00000000 00000000 00000000 0001003f
g2: [112] 0001e3f6 3d7659b3 7f18c258 cff6efef
K_enc: 64e7df78 bb7ccaa4 61433123 5b3222ad
K_enc mod g1: [12] 00000000 00000000 00000000 00001ff0
g2(K_enc mod g1): [124] 142057bb 0bceac4c 58bd142e 1e710a50
-----------------------------------------------------------------
L = 3
g1: [24] 00000000 00000000 00000000 010000db
g2: [104] 000001be f66c6c3a b1030a5a 1919808b
K_enc: 575e5156 ba685dc6 112124ac edb2c179
K_enc mod g1: [23] 00000000 00000000 00000000 008ddbc8
g2(K_enc mod g1): [127] d56d0adb 8216cb39 7fe3c591 1ff95618
-----------------------------------------------------------------
L = 4
g1: [32] 00000000 00000000 00000001 000000af
g2: [96] 00000001 6ab89969 de17467f d3736ad9
K_enc: 8917b4fc 403b6db2 1596b86d 1cb8adab

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 2, Part G Page 858
Sample Data

K_enc mod g1: [31] 00000000 00000000 00000000 aa1e78aa

g2(K_enc mod g1): [127] 91910128 b0e2f5ed a132a03e af3d8cda
-----------------------------------------------------------------
L = 5
g1: [40] 00000000 00000000 00000100 00000039
g2: [88] 00000000 01630632 91da50ec 55715247
K_enc: 785c915b dd25b9c6 0102ab00 b6cd2a68
K_enc mod g1: [38] 00000000 00000000 0000007f 13d44436
g2(K_enc mod g1): [126] 6fb5651c cb80c8d7 ea1ee56d f1ec5d02
-----------------------------------------------------------------
L = 6
g1: [48] 00000000 00000000 00010000 00000291
g2: [77] 00000000 00002c93 52aa6cc0 54468311
K_enc: 5e77d19f 55ccd7d5 798f9a32 3b83e5d8
K_enc mod g1: [47] 00000000 00000000 000082eb 4af213ed
g2(K_enc mod g1): [124] 16096bcb afcf8def 1d226a1b 4d3f9a3d
-----------------------------------------------------------------
L = 7
g1: [56] 00000000 00000000 01000000 00000095
g2: [71] 00000000 000000b3 f7fffce2 79f3a073
K_enc: 05454e03 8ddcfbe3 ed024b2d 92b7f54c
K_enc mod g1: [55] 00000000 00000000 0095b8a4 8eb816da
g2(K_enc mod g1): [126] 50f9c0d4 e3178da9 4a09fe0d 34f67b0e
-----------------------------------------------------------------
L = 8
g1: [64] 00000000 00000001 00000000 0000001b
g2: [63] 00000000 00000000 a1ab815b c7ec8025
K_enc: 7ce149fc f4b38ad7 2a5d8a41 eb15ba31
K_enc mod g1: [63] 00000000 00000000 8660806c 1865deec
g2(K_enc mod g1): [126] 532c36d4 5d0954e0 922989b6 826f78dc
-----------------------------------------------------------------
L = 9
g1: [72] 00000000 00000100 00000000 00000609
g2: [49] 00000000 00000000 0002c980 11d8b04d
K_enc: 5eeff7ca 84fc2782 9c051726 3df6f36e
K_enc mod g1: [71] 00000000 00000083 58ccb7d0 b95d3c71
g2(K_enc mod g1): [120] 016313f6 0d3771cf 7f8e4bb9 4aa6827d
-----------------------------------------------------------------
L = 10
g1: [80] 00000000 00010000 00000000 00000215
g2: [42] 00000000 00000000 0000058e 24f9a4bb
K_enc: 7b13846e 88beb4de 34e7160a fd44dc65
K_enc mod g1: [79] 00000000 0000b4de 34171767 f36981c3
g2(K_enc mod g1): [121] 023bc1ec 34a0029e f798dcfb 618ba58d
-----------------------------------------------------------------
L = 11
g1: [88] 00000000 01000000 00000000 0000013b
g2: [35] 00000000 00000000 0000000c a76024d7
K_enc: bda6de6c 6e7d757e 8dfe2d49 9a181193
K_enc mod g1: [86] 00000000 007d757e 8dfe88aa 2fcee371
g2(K_enc mod g1): [121] 022e08a9 3aa51d8d 2f93fa78 85cc1f87

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 2, Part G Page 859
Sample Data

-----------------------------------------------------------------
L = 12
g1: [96] 00000001 00000000 00000000 000000dd
g2: [28] 00000000 00000000 00000000 1c9c26b9
K_enc: e6483b1c 2cdb1040 9a658f97 c4efd90d
K_enc mod g1: [93] 00000000 2cdb1040 9a658fd7 5b562e41
g2(K_enc mod g1): [121] 030d752b 216fe29b b880275c d7e6f6f9
-----------------------------------------------------------------
L = 13
g1: [104] 00000100 00000000 00000000 0000049d
g2: [21] 00000000 00000000 00000000 0026d9e3
K_enc: d79d281d a2266847 6b223c46 dc0ab9ee
K_enc mod g1: [100] 0000001d a2266847 6b223c45 e1fc5fa6
g2(K_enc mod g1): [121] 03f11138 9cebf919 00b93808 4ac158aa
-----------------------------------------------------------------
L = 14
g1: [112] 00010000 00000000 00000000 0000014f
g2: [14] 00000000 00000000 00000000 00004377
K_enc: cad9a65b 9fca1c1d a2320fcf 7c4ae48e
K_enc mod g1: [111] 0000a65b 9fca1c1d a2320fcf 7cb6a909
g2(K_enc mod g1): [125] 284840fd f1305f3c 529f5703 76adf7cf
-----------------------------------------------------------------
L = 15
g1: [120] 01000000 00000000 00000000 000000e7
g2: [7] 00000000 00000000 00000000 00000089
K_enc: 21f0cc31 049b7163 d375e9e1 06029809
K_enc mod g1: [119] 00f0cc31 049b7163 d375e9e1 0602840e
g2(K_enc mod g1): [126] 7f10b53b 6df84b94 f22e566a 3754a37e
-----------------------------------------------------------------
L = 16
g1: [128] 1 00000000 00000000 00000000 00000000
g2: [0] 00000000 00000000 00000000 00000001
K_enc: 35ec8fc3 d50ccd32 5f2fd907 bde206de
K_enc mod g1: [125] 35ec8fc3 d50ccd32 5f2fd907 bde206de
g2(K_enc mod g1): [125] 35ec8fc3 d50ccd32 5f2fd907 bde206de
-----------------------------------------------------------------

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 2, Part G Page 860
Sample Data

1.1.2 First set of sample data

In Section 1.1.2 to Section 1.1.5 the notation X[j] means the jth octet of X rather than the
jth bit of X, counting from the LSB and an asterisk appended to an LFSR value indicates
that the switch for that LFSR is open (see step 2 of [Vol 2] Part H, Section 4.5).

Initial values for the key, BD_ADDR and clock

K_session[0] = 00 K_session[1] = 00 K_session[2] = 00 K_session[3] = 00

K_session[4] = 00 K_session[5] = 00 K_session[6] = 00 K_session[7] = 00
K_session[8] = 00 K_session[9] = 00 K_session[10] = 00 K_session[11] = 00
K_session[12] = 00 K_session[13] = 00 K_session[14] = 00 K_session[15] = 00

BD_ADDR_C[0] = 00 BD_ADDR_C[1] = 00 BD_ADDR_C[2] = 00

BD_ADDR_C[3] = 00 BD_ADDR_C[4] = 00 BD_ADDR_C[5] = 00

CL[0] = 00 CL[1] = 00 CL[2] = 00 CL[3] = 00

The corresponding values of CLK are 0x000_0000 and 0x800_0000.

===============================================================================================
Fill LFSRs with initial data
===============================================================================================

t clk# LFSR1 LFSR2 LFSR3 LFSR4 X1 X2 X3 X4 Z C[t+1] C[t] C[t-1]

0 0 0000000* 00000000* 000000000* 0000000000* 0 0 0 0 0 00 00 00

1 1 0000000* 00000001* 000000000* 0000000001* 0 0 0 0 0 00 00 00
2 2 0000000* 00000002* 000000000* 0000000003* 0 0 0 0 0 00 00 00
3 3 0000000* 00000004* 000000000* 0000000007* 0 0 0 0 0 00 00 00
4 4 0000000* 00000008* 000000000* 000000000E* 0 0 0 0 0 00 00 00
5 5 0000000* 00000010* 000000000* 000000001C* 0 0 0 0 0 00 00 00
6 6 0000000* 00000020* 000000000* 0000000038* 0 0 0 0 0 00 00 00
7 7 0000000* 00000040* 000000000* 0000000070* 0 0 0 0 0 00 00 00
8 8 0000000* 00000080* 000000000* 00000000E0* 0 0 0 0 0 00 00 00
9 9 0000000* 00000100* 000000000* 00000001C0* 0 0 0 0 0 00 00 00
10 10 0000000* 00000200* 000000000* 0000000380* 0 0 0 0 0 00 00 00
11 11 0000000* 00000400* 000000000* 0000000700* 0 0 0 0 0 00 00 00
12 12 0000000* 00000800* 000000000* 0000000E00* 0 0 0 0 0 00 00 00
13 13 0000000* 00001000* 000000000* 0000001C00* 0 0 0 0 0 00 00 00
14 14 0000000* 00002000* 000000000* 0000003800* 0 0 0 0 0 00 00 00
15 15 0000000* 00004000* 000000000* 0000007000* 0 0 0 0 0 00 00 00
16 16 0000000* 00008000* 000000000* 000000E000* 0 0 0 0 0 00 00 00

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 2, Part G Page 861
Sample Data

17 17 0000000* 00010000* 000000000* 000001C000* 0 0 0 0 0 00 00 00

18 18 0000000* 00020000* 000000000* 0000038000* 0 0 0 0 0 00 00 00
19 19 0000000* 00040000* 000000000* 0000070000* 0 0 0 0 0 00 00 00
20 20 0000000* 00080000* 000000000* 00000E0000* 0 0 0 0 0 00 00 00
21 21 0000000* 00100000* 000000000* 00001C0000* 0 0 0 0 0 00 00 00
22 22 0000000* 00200000* 000000000* 0000380000* 0 0 0 0 0 00 00 00
23 23 0000000* 00400000* 000000000* 0000700000* 0 0 0 0 0 00 00 00
24 24 0000000* 00800000* 000000000* 0000E00000* 0 1 0 0 1 00 00 00
25 25 0000000* 01000000* 000000000* 0001C00000* 0 0 0 0 0 00 00 00
26 26 0000000 02000000* 000000000* 0003800000* 0 0 0 0 0 00 00 00
27 27 0000000 04000000* 000000000* 0007000000* 0 0 0 0 0 00 00 00
28 28 0000000 08000000* 000000000* 000E000000* 0 0 0 0 0 00 00 00
29 29 0000000 10000000* 000000000* 001C000000* 0 0 0 0 0 00 00 00
30 30 0000000 20000000* 000000000* 0038000000* 0 0 0 0 0 00 00 00
31 31 0000000 40000000* 000000000* 0070000000* 0 0 0 0 0 00 00 00
32 32 0000000 00000001 000000000* 00E0000000* 0 0 0 1 1 00 00 00
33 33 0000000 00000002 000000000* 01C0000000* 0 0 0 1 1 00 00 00
34 34 0000000 00000004 000000000 0380000000* 0 0 0 1 1 00 00 00
35 35 0000000 00000008 000000000 0700000000* 0 0 0 0 0 00 00 00
36 36 0000000 00000010 000000000 0E00000000* 0 0 0 0 0 00 00 00
37 37 0000000 00000020 000000000 1C00000000* 0 0 0 0 0 00 00 00
38 38 0000000 00000040 000000000 3800000000* 0 0 0 0 0 00 00 00
39 39 0000000 00000080 000000000 7000000000* 0 0 0 0 0 00 00 00
===============================================================================================
Start clocking Summation Combiner
===============================================================================================
40 1 0000000 00000100 000000000 6000000001 0 0 0 0 0 00 00 00
41 2 0000000 00000200 000000000 4000000003 0 0 0 0 0 00 00 00
42 3 0000000 00000400 000000000 0000000007 0 0 0 0 0 00 00 00
43 4 0000000 00000800 000000000 000000000E 0 0 0 0 0 00 00 00
44 5 0000000 00001001 000000000 000000001D 0 0 0 0 0 00 00 00
45 6 0000000 00002002 000000000 000000003B 0 0 0 0 0 00 00 00
46 7 0000000 00004004 000000000 0000000077 0 0 0 0 0 00 00 00
47 8 0000000 00008008 000000000 00000000EE 0 0 0 0 0 00 00 00
48 9 0000000 00010011 000000000 00000001DD 0 0 0 0 0 00 00 00
49 10 0000000 00020022 000000000 00000003BB 0 0 0 0 0 00 00 00
50 11 0000000 00040044 000000000 0000000777 0 0 0 0 0 00 00 00
51 12 0000000 00080088 000000000 0000000EEE 0 0 0 0 0 00 00 00
52 13 0000000 00100110 000000000 0000001DDD 0 0 0 0 0 00 00 00
53 14 0000000 00200220 000000000 0000003BBB 0 0 0 0 0 00 00 00
54 15 0000000 00400440 000000000 0000007777 0 0 0 0 0 00 00 00
55 16 0000000 00800880 000000000 000000EEEE 0 1 0 0 1 00 00 00
56 17 0000000 01001100 000000000 000001DDDD 0 0 0 0 0 00 00 00

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 2, Part G Page 862
Sample Data

57 18 0000000 02002200 000000000 000003BBBB 0 0 0 0 0 00 00 00

58 19 0000000 04004400 000000000 0000077777 0 0 0 0 0 00 00 00
59 20 0000000 08008800 000000000 00000EEEEE 0 0 0 0 0 00 00 00
60 21 0000000 10011000 000000000 00001DDDDD 0 0 0 0 0 00 00 00
61 22 0000000 20022000 000000000 00003BBBBB 0 0 0 0 0 00 00 00
62 23 0000000 40044000 000000000 0000777777 0 0 0 0 0 00 00 00
63 24 0000000 00088001 000000000 0000EEEEEE 0 0 0 0 0 00 00 00
64 25 0000000 00110003 000000000 0001DDDDDD 0 0 0 0 0 00 00 00
65 26 0000000 00220006 000000000 0003BBBBBB 0 0 0 0 0 00 00 00
66 27 0000000 0044000C 000000000 0007777777 0 0 0 0 0 00 00 00
67 28 0000000 00880018 000000000 000EEEEEEE 0 1 0 0 1 00 00 00
68 29 0000000 01100031 000000000 001DDDDDDC 0 0 0 0 0 00 00 00
69 30 0000000 02200062 000000000 003BBBBBB8 0 0 0 0 0 00 00 00
70 31 0000000 044000C4 000000000 0077777770 0 0 0 0 0 00 00 00
71 32 0000000 08800188 000000000 00EEEEEEE0 0 1 0 1 0 01 00 00
72 33 0000000 11000311 000000000 01DDDDDDC1 0 0 0 1 0 00 01 00
73 34 0000000 22000622 000000000 03BBBBBB83 0 0 0 1 1 11 00 01
74 35 0000000 44000C44 000000000 0777777707 0 0 0 0 1 10 11 00
75 36 0000000 08001888 000000000 0EEEEEEE0E 0 0 0 1 1 01 10 11
76 37 0000000 10003111 000000000 1DDDDDDC1D 0 0 0 1 0 01 01 10
77 38 0000000 20006222 000000000 3BBBBBB83B 0 0 0 1 0 11 01 01
78 39 0000000 4000C444 000000000 7777777077 0 0 0 0 1 01 11 01
79 40 0000000 00018888 000000000 6EEEEEE0EF 0 0 0 1 0 10 01 11
80 41 0000000 00031110 000000000 5DDDDDC1DE 0 0 0 1 1 00 10 01
81 42 0000000 00062220 000000000 3BBBBB83BC 0 0 0 1 1 01 00 10
82 43 0000000 000C4440 000000000 7777770779 0 0 0 0 1 01 01 00
83 44 0000000 00188880 000000000 6EEEEE0EF2 0 0 0 1 0 11 01 01
84 45 0000000 00311100 000000000 5DDDDC1DE5 0 0 0 1 0 10 11 01
85 46 0000000 00622200 000000000 3BBBB83BCB 0 0 0 1 1 01 10 11
86 47 0000000 00C44400 000000000 7777707797 0 1 0 0 0 01 01 10
87 48 0000000 01888801 000000000 6EEEE0EF2F 0 1 0 1 1 11 01 01
88 49 0000000 03111003 000000000 5DDDC1DE5E 0 0 0 1 0 10 11 01
89 50 0000000 06222006 000000000 3BBB83BCBC 0 0 0 1 1 01 10 11
90 51 0000000 0C44400C 000000000 7777077979 0 0 0 0 1 00 01 10
91 52 0000000 18888018 000000000 6EEE0EF2F2 0 1 0 1 0 10 00 01
92 53 0000000 31110030 000000000 5DDC1DE5E5 0 0 0 1 1 11 10 00
93 54 0000000 62220060 000000000 3BB83BCBCB 0 0 0 1 0 00 11 10
94 55 0000000 444400C1 000000000 7770779797 0 0 0 0 0 10 00 11
95 56 0000000 08880183 000000000 6EE0EF2F2F 0 1 0 1 0 00 10 00
96 57 0000000 11100307 000000000 5DC1DE5E5F 0 0 0 1 1 01 00 10
97 58 0000000 2220060E 000000000 3B83BCBCBF 0 0 0 1 0 00 01 00
98 59 0000000 44400C1C 000000000 770779797E 0 0 0 0 0 11 00 01
99 60 0000000 08801838 000000000 6E0EF2F2FC 0 1 0 0 0 01 11 00

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 2, Part G Page 863
Sample Data

100 61 0000000 11003070 000000000 5C1DE5E5F8 0 0 0 0 1 11 01 11

101 62 0000000 220060E0 000000000 383BCBCBF0 0 0 0 0 1 01 11 01
102 63 0000000 4400C1C0 000000000 70779797E0 0 0 0 0 1 11 01 11
103 64 0000000 08018380 000000000 60EF2F2FC1 0 0 0 1 0 10 11 01
104 65 0000000 10030701 000000000 41DE5E5F82 0 0 0 1 1 01 10 11
105 66 0000000 20060E02 000000000 03BCBCBF04 0 0 0 1 0 01 01 10
106 67 0000000 400C1C05 000000000 0779797E09 0 0 0 0 1 10 01 01
107 68 0000000 0018380A 000000000 0EF2F2FC12 0 0 0 1 1 00 10 01
108 69 0000000 00307015 000000000 1DE5E5F825 0 0 0 1 1 01 00 10
109 70 0000000 0060E02A 000000000 3BCBCBF04B 0 0 0 1 0 00 01 00
110 71 0000000 00C1C055 000000000 779797E097 0 1 0 1 0 10 00 01
111 72 0000000 018380AA 000000000 6F2F2FC12F 0 1 0 0 1 11 10 00
112 73 0000000 03070154 000000000 5E5E5F825E 0 0 0 0 1 11 11 10
113 74 0000000 060E02A8 000000000 3CBCBF04BC 0 0 0 1 0 11 11 11
114 75 0000000 0C1C0550 000000000 79797E0979 0 0 0 0 1 00 11 11
115 76 0000000 18380AA0 000000000 72F2FC12F2 0 0 0 1 1 10 00 11
116 77 0000000 30701541 000000000 65E5F825E5 0 0 0 1 1 11 10 00
117 78 0000000 60E02A82 000000000 4BCBF04BCB 0 1 0 1 1 00 11 10
118 79 0000000 41C05505 000000000 1797E09796 0 1 0 1 0 11 00 11
119 80 0000000 0380AA0A 000000000 2F2FC12F2C 0 1 0 0 0 01 11 00
120 81 0000000 07015415 000000000 5E5F825E59 0 0 0 0 1 11 01 11
121 82 0000000 0E02A82A 000000000 3CBF04BCB2 0 0 0 1 0 10 11 01
122 83 0000000 1C055054 000000000 797E097964 0 0 0 0 0 01 10 11
123 84 0000000 380AA0A8 000000000 72FC12F2C9 0 0 0 1 0 01 01 10
124 85 0000000 70154151 000000000 65F825E593 0 0 0 1 0 11 01 01
125 86 0000000 602A82A3 000000000 4BF04BCB26 0 0 0 1 0 10 11 01
126 87 0000000 40550546 000000000 17E097964C 0 0 0 1 1 01 10 11
127 88 0000000 00AA0A8D 000000000 2FC12F2C99 0 1 0 1 1 01 01 10
128 89 0000000 0154151A 000000000 5F825E5932 0 0 0 1 0 11 01 01
129 90 0000000 02A82A34 000000000 3F04BCB264 0 1 0 0 0 10 11 01
130 91 0000000 05505468 000000000 7E097964C9 0 0 0 0 0 01 10 11
131 92 0000000 0AA0A8D0 000000000 7C12F2C992 0 1 0 0 0 01 01 10
132 93 0000000 154151A1 000000000 7825E59324 0 0 0 0 1 10 01 01
133 94 0000000 2A82A342 000000000 704BCB2648 0 1 0 0 1 00 10 01
134 95 0000000 55054684 000000000 6097964C91 0 0 0 1 1 01 00 10
135 96 0000000 2A0A8D09 000000000 412F2C9923 0 0 0 0 1 01 01 00
136 97 0000000 54151A12 000000000 025E593246 0 0 0 0 1 10 01 01
137 98 0000000 282A3424 000000000 04BCB2648D 0 0 0 1 1 00 10 01
138 99 0000000 50546848 000000000 097964C91A 0 0 0 0 0 01 00 10
139 100 0000000 20A8D090 000000000 12F2C99235 0 1 0 1 1 00 01 00
140 101 0000000 4151A120 000000000 25E593246A 0 0 0 1 1 11 00 01
141 102 0000000 02A34240 000000000 4BCB2648D5 0 1 0 1 1 01 11 00
142 103 0000000 05468481 000000000 17964C91AB 0 0 0 1 0 10 01 11

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 2, Part G Page 864
Sample Data

143 104 0000000 0A8D0903 000000000 2F2C992357 0 1 0 0 1 00 10 01

144 105 0000000 151A1206 000000000 5E593246AE 0 0 0 0 0 01 00 10
145 106 0000000 2A34240C 000000000 3CB2648D5C 0 0 0 1 0 00 01 00
146 107 0000000 54684818 000000000 7964C91AB8 0 0 0 0 0 11 00 01
147 108 0000000 28D09030 000000000 72C9923571 0 1 0 1 1 01 11 00
148 109 0000000 51A12060 000000000 6593246AE2 0 1 0 1 1 10 01 11
149 110 0000000 234240C0 000000000 4B2648D5C5 0 0 0 0 0 00 10 01
150 111 0000000 46848180 000000000 164C91AB8A 0 1 0 0 1 01 00 10
151 112 0000000 0D090301 000000000 2C99235714 0 0 0 1 0 00 01 00
152 113 0000000 1A120602 000000000 593246AE28 0 0 0 0 0 11 00 01
153 114 0000000 34240C04 000000000 32648D5C51 0 0 0 0 1 10 11 00
154 115 0000000 68481809 000000000 64C91AB8A2 0 0 0 1 1 01 10 11
155 116 0000000 50903012 000000000 4992357144 0 1 0 1 1 01 01 10
156 117 0000000 21206024 000000000 13246AE288 0 0 0 0 1 10 01 01
157 118 0000000 4240C048 000000000 2648D5C511 0 0 0 0 0 00 10 01
158 119 0000000 04818090 000000000 4C91AB8A23 0 1 0 1 0 00 00 10
159 120 0000000 09030120 000000000 1923571446 0 0 0 0 0 00 00 00
160 121 0000000 12060240 000000000 3246AE288D 0 0 0 0 0 00 00 00
161 122 0000000 240C0480 000000000 648D5C511B 0 0 0 1 1 00 00 00
162 123 0000000 48180900 000000000 491AB8A237 0 0 0 0 0 00 00 00
163 124 0000000 10301200 000000000 123571446F 0 0 0 0 0 00 00 00
164 125 0000000 20602400 000000000 246AE288DF 0 0 0 0 0 00 00 00
165 126 0000000 40C04800 000000000 48D5C511BE 0 1 0 1 0 01 00 00
166 127 0000000 01809001 000000000 11AB8A237D 0 1 0 1 1 00 01 00
167 128 0000000 03012002 000000000 23571446FA 0 0 0 0 0 11 00 01
168 129 0000000 06024004 000000000 46AE288DF5 0 0 0 1 0 01 11 00
169 130 0000000 0C048008 000000000 0D5C511BEA 0 0 0 0 1 11 01 11
170 131 0000000 18090011 000000000 1AB8A237D5 0 0 0 1 0 10 11 01
171 132 0000000 30120022 000000000 3571446FAA 0 0 0 0 0 01 10 11
172 133 0000000 60240044 000000000 6AE288DF55 0 0 0 1 0 01 01 10
173 134 0000000 40480089 000000000 55C511BEAA 0 0 0 1 0 11 01 01
174 135 0000000 00900113 000000000 2B8A237D54 0 1 0 1 1 10 11 01
175 136 0000000 01200227 000000000 571446FAA8 0 0 0 0 0 01 10 11
176 137 0000000 0240044E 000000000 2E288DF550 0 0 0 0 1 00 01 10
177 138 0000000 0480089C 000000000 5C511BEAA0 0 1 0 0 1 11 00 01
178 139 0000000 09001138 000000000 38A237D540 0 0 0 1 0 01 11 00
179 140 0000000 12002270 000000000 71446FAA81 0 0 0 0 1 11 01 11
180 141 0000000 240044E0 000000000 6288DF5503 0 0 0 1 0 10 11 01
181 142 0000000 480089C0 000000000 4511BEAA06 0 0 0 0 0 01 10 11
182 143 0000000 10011381 000000000 0A237D540D 0 0 0 0 1 00 01 10
183 144 0000000 20022702 000000000 1446FAA81A 0 0 0 0 0 11 00 01
184 145 0000000 40044E04 000000000 288DF55035 0 0 0 1 0 01 11 00
185 146 0000000 00089C08 000000000 511BEAA06A 0 0 0 0 1 11 01 11

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 2, Part G Page 865
Sample Data

186 147 0000000 00113810 000000000 2237D540D5 0 0 0 0 1 01 11 01

187 148 0000000 00227021 000000000 446FAA81AA 0 0 0 0 1 11 01 11
188 149 0000000 0044E042 000000000 08DF550355 0 0 0 1 0 10 11 01
189 150 0000000 0089C085 000000000 11BEAA06AA 0 1 0 1 0 10 10 11
190 151 0000000 0113810A 000000000 237D540D54 0 0 0 0 0 10 10 10
191 152 0000000 02270215 000000000 46FAA81AA9 0 0 0 1 1 10 10 10
192 153 0000000 044E042A 000000000 0DF5503553 0 0 0 1 1 10 10 10
193 154 0000000 089C0854 000000000 1BEAA06AA7 0 1 0 1 0 01 10 10
194 155 0000000 113810A8 000000000 37D540D54E 0 0 0 1 0 01 01 10
195 156 0000000 22702150 000000000 6FAA81AA9D 0 0 0 1 0 11 01 01
196 157 0000000 44E042A0 000000000 5F5503553A 0 1 0 0 0 10 11 01
197 158 0000000 09C08540 000000000 3EAA06AA75 0 1 0 1 0 10 10 11
198 159 0000000 13810A80 000000000 7D540D54EA 0 1 0 0 1 10 10 10
199 160 0000000 27021500 000000000 7AA81AA9D5 0 0 0 1 1 10 10 10
200 161 0000000 4E042A00 000000000 75503553AB 0 0 0 0 0 10 10 10
201 162 0000000 1C085400 000000000 6AA06AA756 0 0 0 1 1 10 10 10
202 163 0000000 3810A800 000000000 5540D54EAC 0 0 0 0 0 10 10 10
203 164 0000000 70215000 000000000 2A81AA9D58 0 0 0 1 1 10 10 10
204 165 0000000 6042A001 000000000 5503553AB0 0 0 0 0 0 10 10 10
205 166 0000000 40854002 000000000 2A06AA7561 0 1 0 0 1 10 10 10
206 167 0000000 010A8004 000000000 540D54EAC3 0 0 0 0 0 10 10 10
207 168 0000000 02150009 000000000 281AA9D586 0 0 0 0 0 10 10 10
208 169 0000000 042A0012 000000000 503553AB0C 0 0 0 0 0 10 10 10
209 170 0000000 08540024 000000000 206AA75618 0 0 0 0 0 10 10 10
210 171 0000000 10A80048 000000000 40D54EAC30 0 1 0 1 0 01 10 10
211 172 0000000 21500091 000000000 01AA9D5861 0 0 0 1 0 01 01 10
212 173 0000000 42A00122 000000000 03553AB0C3 0 1 0 0 0 11 01 01
213 174 0000000 05400244 000000000 06AA756186 0 0 0 1 0 10 11 01
214 175 0000000 0A800488 000000000 0D54EAC30D 0 1 0 0 1 01 10 11
215 176 0000000 15000911 000000000 1AA9D5861A 0 0 0 1 0 01 01 10
216 177 0000000 2A001223 000000000 3553AB0C35 0 0 0 0 1 10 01 01
217 178 0000000 54002446 000000000 6AA756186A 0 0 0 1 1 00 10 01
218 179 0000000 2800488D 000000000 554EAC30D5 0 0 0 0 0 01 00 10
219 180 0000000 5000911B 000000000 2A9D5861AA 0 0 0 1 0 00 01 00
220 181 0000000 20012236 000000000 553AB0C355 0 0 0 0 0 11 00 01
221 182 0000000 4002446C 000000000 2A756186AA 0 0 0 0 1 10 11 00
222 183 0000000 000488D9 000000000 54EAC30D54 0 0 0 1 1 01 10 11
223 184 0000000 000911B2 000000000 29D5861AA8 0 0 0 1 0 01 01 10
224 185 0000000 00122364 000000000 53AB0C3550 0 0 0 1 0 11 01 01
225 186 0000000 002446C8 000000000 2756186AA0 0 0 0 0 1 01 11 01
226 187 0000000 00488D90 000000000 4EAC30D540 0 0 0 1 0 10 01 11
227 188 0000000 00911B20 000000000 1D5861AA81 0 1 0 0 1 00 10 01
228 189 0000000 01223640 000000000 3AB0C35502 0 0 0 1 1 01 00 10

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 2, Part G Page 866
Sample Data

229 190 0000000 02446C80 000000000 756186AA05 0 0 0 0 1 01 01 00

230 191 0000000 0488D901 000000000 6AC30D540B 0 1 0 1 1 11 01 01
231 192 0000000 0911B203 000000000 55861AA817 0 0 0 1 0 10 11 01
232 193 0000000 12236407 000000000 2B0C35502F 0 0 0 0 0 01 10 11
233 194 0000000 2446C80E 000000000 56186AA05F 0 0 0 0 1 00 01 10
234 195 0000000 488D901C 000000000 2C30D540BF 0 1 0 0 1 11 00 01
235 196 0000000 111B2039 000000000 5861AA817E 0 0 0 0 1 10 11 00
236 197 0000000 22364072 000000000 30C35502FD 0 0 0 1 1 01 10 11
237 198 0000000 446C80E4 000000000 6186AA05FB 0 0 0 1 0 01 01 10
238 199 0000000 08D901C8 000000000 430D540BF6 0 1 0 0 0 11 01 01
239 200 0000000 11B20391 000000000 061AA817EC 0 1 0 0 0 10 11 01

Z[0] = 3D
Z[1] = C1
Z[2] = F0
Z[3] = BB
Z[4] = 58
Z[5] = 1E
Z[6] = 42
Z[7] = 42
Z[8] = 4B
Z[9] = 8E
Z[10] = C1
Z[11] = 2A
Z[12] = 40
Z[13] = 63
Z[14] = 7A
Z[15] = 1E

===============================================================================================
Reload this pattern into the LFSRs
Hold content of Summation Combiner regs and calculate new C[t+1] and Z values
===============================================================================================
LFSR1 <= 04B583D
LFSR2 <= 208E1EC1
LFSR3 <= 063C142F0
LFSR4 <= 0F7A2A42BB
C[t+1] <= 10

===============================================================================================
Generating 125 key symbols (encryption/decryption sequence)
===============================================================================================
240 1 04B583D 208E1EC1 063C142F0 0F7A2A42BB 0 1 0 0 0 10 11 01

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 2, Part G Page 867
Sample Data

241 2 096B07A 411C3D82 0C78285E1 1EF4548577 1 0 1 1 1 10 10 11

242 3 12D60F4 02387B04 18F050BC3 3DE8A90AEF 0 0 1 1 0 01 10 10
243 4 05AC1E9 0470F609 11E0A1786 7BD15215DF 0 0 0 1 0 01 01 10
244 5 0B583D2 08E1EC13 03C142F0C 77A2A42BBF 1 1 0 1 0 00 01 01
245 6 16B07A5 11C3D827 078285E18 6F4548577E 0 1 0 0 1 11 00 01
246 7 0D60F4B 2387B04F 0F050BC30 5E8A90AEFD 1 1 1 1 1 00 11 00
247 8 1AC1E97 470F609E 1E0A17860 3D15215DFA 1 0 1 0 0 11 00 11
248 9 1583D2E 0E1EC13D 1C142F0C0 7A2A42BBF4 0 0 1 0 0 01 11 00
249 10 0B07A5D 1C3D827B 18285E181 74548577E9 1 0 1 0 1 10 01 11
250 11 160F4BB 387B04F7 1050BC302 68A90AEFD2 0 0 0 1 1 00 10 01
251 12 0C1E976 70F609EE 00A178605 515215DFA5 1 1 0 0 0 00 00 10
252 13 183D2ED 61EC13DD 0142F0C0B 22A42BBF4B 1 1 0 1 1 01 00 00
253 14 107A5DA 43D827BA 0285E1817 4548577E97 0 1 0 0 0 00 01 00
254 15 00F4BB4 07B04F74 050BC302F 0A90AEFD2E 0 1 0 1 0 10 00 01
255 16 01E9769 0F609EE8 0A178605E 15215DFA5C 0 0 1 0 1 11 10 00
256 17 03D2ED3 1EC13DD0 142F0C0BD 2A42BBF4B9 0 1 0 0 0 00 11 10
257 18 07A5DA7 3D827BA0 085E1817B 548577E972 0 1 1 1 1 11 00 11
258 19 0F4BB4F 7B04F740 10BC302F6 290AEFD2E5 1 0 0 0 0 01 11 00
259 20 1E9769F 7609EE80 0178605ED 5215DFA5CA 1 0 0 0 0 10 01 11
260 21 1D2ED3F 6C13DD01 02F0C0BDA 242BBF4B94 1 0 0 0 1 00 10 01
261 22 1A5DA7E 5827BA03 05E1817B4 48577E9729 1 0 0 0 1 01 00 10
262 23 14BB4FC 304F7407 0BC302F69 10AEFD2E53 0 0 1 1 1 00 01 00
263 24 09769F9 609EE80E 178605ED2 215DFA5CA7 1 1 0 0 0 10 00 01
264 25 12ED3F2 413DD01C 0F0C0BDA4 42BBF4B94F 0 0 1 1 0 00 10 00
265 26 05DA7E5 027BA038 1E1817B49 0577E9729F 0 0 1 0 1 01 00 10
266 27 0BB4FCA 04F74071 1C302F693 0AEFD2E53F 1 1 1 1 1 11 01 00
267 28 1769F95 09EE80E3 18605ED27 15DFA5CA7F 0 1 1 1 0 11 11 01
268 29 0ED3F2B 13DD01C6 10C0BDA4F 2BBF4B94FE 1 1 0 1 0 10 11 11
269 30 1DA7E56 27BA038D 01817B49F 577E9729FD 1 1 0 0 0 10 10 11
270 31 1B4FCAD 4F74071B 0302F693E 2EFD2E53FB 1 0 0 1 0 01 10 10
271 32 169F95B 1EE80E37 0605ED27D 5DFA5CA7F7 0 1 0 1 1 01 01 10
272 33 0D3F2B7 3DD01C6E 0C0BDA4FB 3BF4B94FEF 1 1 1 1 1 00 01 01
273 34 1A7E56F 7BA038DC 1817B49F6 77E9729FDE 1 1 1 1 0 01 00 01
274 35 14FCADF 774071B9 102F693ED 6FD2E53FBD 0 0 0 1 0 00 01 00
275 36 09F95BE 6E80E373 005ED27DB 5FA5CA7F7B 1 1 0 1 1 10 00 01
276 37 13F2B7C 5D01C6E7 00BDA4FB6 3F4B94FEF7 0 0 0 0 0 11 10 00
277 38 07E56F9 3A038DCE 017B49F6C 7E9729FDEE 0 0 0 1 0 00 11 10
278 39 0FCADF2 74071B9C 02F693ED8 7D2E53FBDD 1 0 0 0 1 10 00 11
279 40 1F95BE5 680E3738 05ED27DB0 7A5CA7F7BA 1 0 0 0 1 11 10 00
280 41 1F2B7CA 501C6E71 0BDA4FB60 74B94FEF74 1 0 1 1 0 01 11 10
281 42 1E56F94 2038DCE2 17B49F6C0 69729FDEE8 1 0 0 0 0 10 01 11
282 43 1CADF29 4071B9C4 0F693ED80 52E53FBDD1 1 0 1 1 1 11 10 01
283 44 195BE53 00E37389 1ED27DB01 25CA7F7BA3 1 1 1 1 1 01 11 10

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 2, Part G Page 868
Sample Data

284 45 12B7CA6 01C6E713 1DA4FB602 4B94FEF747 0 1 1 1 0 01 01 11

285 46 056F94C 038DCE26 1B49F6C04 1729FDEE8E 0 1 1 0 1 11 01 01
286 47 0ADF299 071B9C4D 1693ED808 2E53FBDD1C 1 0 0 0 0 10 11 01
287 48 15BE532 0E37389A 0D27DB011 5CA7F7BA38 0 0 1 1 0 10 10 11
288 49 0B7CA64 1C6E7135 1A4FB6022 394FEF7471 1 0 1 0 0 01 10 10
289 50 16F94C9 38DCE26A 149F6C044 729FDEE8E2 0 1 0 1 1 01 01 10
290 51 0DF2993 71B9C4D4 093ED8089 653FBDD1C4 1 1 1 0 0 00 01 01
291 52 1BE5327 637389A9 127DB0112 4A7F7BA388 1 0 0 0 1 11 00 01
292 53 17CA64E 46E71353 04FB60224 14FEF74710 0 1 0 1 1 01 11 00
293 54 0F94C9C 0DCE26A6 09F6C0448 29FDEE8E21 1 1 1 1 1 01 01 11
294 55 1F29939 1B9C4D4D 13ED80890 53FBDD1C42 1 1 0 1 0 00 01 01
295 56 1E53272 37389A9A 07DB01121 27F7BA3884 1 0 0 1 0 10 00 01
296 57 1CA64E5 6E713534 0FB602242 4FEF747108 1 0 1 1 1 00 10 00
297 58 194C9CB 5CE26A69 1F6C04485 1FDEE8E210 1 1 1 1 0 11 00 10
298 59 1299397 39C4D4D3 1ED80890A 3FBDD1C420 0 1 1 1 0 00 11 00
299 60 053272F 7389A9A6 1DB011214 7F7BA38840 0 1 1 0 0 11 00 11
300 61 0A64E5E 6713534C 1B6022428 7EF7471081 1 0 1 1 0 00 11 00
301 62 14C9CBD 4E26A699 16C044850 7DEE8E2102 0 0 0 1 1 10 00 11
302 63 099397A 1C4D4D32 0D80890A0 7BDD1C4205 1 0 1 1 1 00 10 00
303 64 13272F4 389A9A65 1B0112141 77BA38840B 0 1 1 1 1 00 00 10
304 65 064E5E8 713534CB 160224283 6F74710817 0 0 0 0 0 00 00 00
305 66 0C9CBD1 626A6997 0C0448507 5EE8E2102E 1 0 1 1 1 01 00 00
306 67 19397A3 44D4D32E 180890A0E 3DD1C4205C 1 1 1 1 1 11 01 00
307 68 1272F46 09A9A65D 10112141D 7BA38840B8 0 1 0 1 1 10 11 01
308 69 04E5E8C 13534CBA 00224283A 7747108171 0 0 0 0 0 01 10 11
309 70 09CBD19 26A69975 004485075 6E8E2102E3 1 1 0 1 0 10 01 10
310 71 1397A32 4D4D32EB 00890A0EA 5D1C4205C7 0 0 0 0 0 00 10 01
311 72 072F465 1A9A65D7 0112141D5 3A38840B8F 0 1 0 0 1 01 00 10
312 73 0E5E8CA 3534CBAF 0224283AA 747108171F 1 0 0 0 0 00 01 00
313 74 1CBD194 6A69975E 044850755 68E2102E3E 1 0 0 1 0 10 00 01
314 75 197A329 54D32EBC 0890A0EAB 51C4205C7D 1 1 1 1 0 01 10 00
315 76 12F4653 29A65D79 112141D56 238840B8FA 0 1 0 1 1 01 01 10
316 77 05E8CA6 534CBAF2 024283AAD 47108171F4 0 0 0 0 1 10 01 01
317 78 0BD194D 269975E5 04850755B 0E2102E3E9 1 1 0 0 0 11 10 01
318 79 17A329A 4D32EBCB 090A0EAB6 1C4205C7D2 0 0 1 0 0 00 11 10
319 80 0F46535 1A65D797 12141D56D 38840B8FA5 1 0 0 1 0 11 00 11
320 81 1E8CA6A 34CBAF2F 04283AADA 7108171F4B 1 1 0 0 1 01 11 00
321 82 1D194D5 69975E5F 0850755B4 62102E3E97 1 1 1 0 0 01 01 11
322 83 1A329AA 532EBCBF 10A0EAB68 44205C7D2F 1 0 0 0 0 11 01 01
323 84 1465355 265D797F 0141D56D1 0840B8FA5E 0 0 0 0 1 01 11 01
324 85 08CA6AB 4CBAF2FF 0283AADA2 108171F4BC 1 1 0 1 0 01 01 11
325 86 1194D56 1975E5FF 050755B45 2102E3E979 0 0 0 0 1 10 01 01
326 87 0329AAD 32EBCBFF 0A0EAB68A 4205C7D2F3 0 1 1 0 0 11 10 01

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 2, Part G Page 869
Sample Data

327 88 065355A 65D797FF 141D56D14 040B8FA5E7 0 1 0 0 0 00 11 10

328 89 0CA6AB4 4BAF2FFF 083AADA28 08171F4BCF 1 1 1 0 1 11 00 11
329 90 194D569 175E5FFF 10755B450 102E3E979E 1 0 0 0 0 01 11 00
330 91 129AAD3 2EBCBFFF 00EAB68A1 205C7D2F3C 0 1 0 0 0 10 01 11
331 92 05355A6 5D797FFF 01D56D142 40B8FA5E78 0 0 0 1 1 00 10 01
332 93 0A6AB4D 3AF2FFFE 03AADA285 0171F4BCF1 1 1 0 0 0 00 00 10
333 94 14D569B 75E5FFFD 0755B450A 02E3E979E2 0 1 0 1 0 01 00 00
334 95 09AAD37 6BCBFFFA 0EAB68A15 05C7D2F3C4 1 1 1 1 1 11 01 00
335 96 1355A6E 5797FFF4 1D56D142A 0B8FA5E788 0 1 1 1 0 11 11 01
336 97 06AB4DC 2F2FFFE8 1AADA2854 171F4BCF11 0 0 1 0 0 11 11 11
337 98 0D569B8 5E5FFFD0 155B450A9 2E3E979E23 1 0 0 0 0 11 11 11
338 99 1AAD370 3CBFFFA1 0AB68A153 5C7D2F3C46 1 1 1 0 0 10 11 11
339 100 155A6E0 797FFF43 156D142A7 38FA5E788D 0 0 0 1 1 01 10 11
340 101 0AB4DC0 72FFFE87 0ADA2854E 71F4BCF11B 1 1 1 1 1 10 01 10
341 102 1569B81 65FFFD0E 15B450A9D 63E979E236 0 1 0 1 0 11 10 01
342 103 0AD3703 4BFFFA1C 0B68A153B 47D2F3C46C 1 1 1 1 1 01 11 10
343 104 15A6E07 17FFF438 16D142A76 0FA5E788D8 0 1 0 1 1 10 01 11
344 105 0B4DC0F 2FFFE870 0DA2854EC 1F4BCF11B0 1 1 1 0 1 11 10 01
345 106 169B81F 5FFFD0E1 1B450A9D8 3E979E2360 0 1 1 1 0 01 11 10
346 107 0D3703F 3FFFA1C3 168A153B0 7D2F3C46C1 1 1 0 0 1 10 01 11
347 108 1A6E07E 7FFF4386 0D142A761 7A5E788D83 1 1 1 0 1 11 10 01
348 109 14DC0FD 7FFE870C 1A2854EC2 74BCF11B07 0 1 1 1 0 01 11 10
349 110 09B81FB 7FFD0E19 1450A9D84 6979E2360E 1 1 0 0 1 10 01 11
350 111 13703F6 7FFA1C33 08A153B09 52F3C46C1C 0 1 1 1 1 11 10 01
351 112 06E07EC 7FF43867 1142A7612 25E788D838 0 1 0 1 1 00 11 10
352 113 0DC0FD8 7FE870CF 02854EC25 4BCF11B071 1 1 0 1 1 11 00 11
353 114 1B81FB1 7FD0E19E 050A9D84B 179E2360E3 1 1 0 1 0 00 11 00
354 115 1703F62 7FA1C33D 0A153B096 2F3C46C1C7 0 1 1 0 0 11 00 11
355 116 0E07EC4 7F43867B 142A7612C 5E788D838E 1 0 0 0 0 01 11 00
356 117 1C0FD88 7E870CF6 0854EC259 3CF11B071C 1 1 1 1 1 01 01 11
357 118 181FB11 7D0E19ED 10A9D84B3 79E2360E38 1 0 0 1 1 11 01 01
358 119 103F622 7A1C33DA 0153B0967 73C46C1C71 0 0 0 1 0 10 11 01
359 120 007EC45 743867B5 02A7612CE 6788D838E3 0 0 0 1 1 01 10 11
360 121 00FD88B 6870CF6B 054EC259C 4F11B071C6 0 0 0 0 1 00 01 10
361 122 01FB117 50E19ED7 0A9D84B38 1E2360E38C 0 1 1 0 0 10 00 01
362 123 03F622F 21C33DAE 153B09671 3C46C1C718 0 1 0 0 1 11 10 00
363 124 07EC45F 43867B5C 0A7612CE2 788D838E30 0 1 1 1 0 01 11 10
364 125 0FD88BF 070CF6B9 14EC259C4 711B071C61 1 0 0 0 0 10 01 11

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 2, Part G Page 870
Sample Data

1.1.3 Second set of sample data

Initial values for the key, BD_ADDR and clock

K_session[0] = 00 K_session[1] = 00 K_session[2] = 00 K_session[3] = 00

K_session[4] = 00 K_session[5] = 00 K_session[6] = 00 K_session[7] = 00
K_session[8] = 00 K_session[9] = 00 K_session[10] = 00 K_session[11] = 00
K_session[12] = 00 K_session[13] = 00 K_session[14] = 00 K_session[15] = 00

BD_ADDR_C[0] = 00 BD_ADDR_C[1] = 00 BD_ADDR_C[2] = 00

BD_ADDR_C[3] = 00 BD_ADDR_C[4] = 00 BD_ADDR_C[5] = 00

CL[0] = 00 CL[1] = 00 CL[2] = 00 CL[3] = 03

The corresponding values of CLK are 0x600_0000 and 0xE00_0000.

===============================================================================================
Fill LFSRs with initial data
===============================================================================================

t clk# LFSR1 LFSR2 LFSR3 LFSR4 X1 X2 X3 X4 Z C[t+1] C[t] C[t-1]

0 0 0000000* 00000000* 000000000* 0000000000* 0 0 0 0 0 00 00 00

1 1 0000001* 00000001* 000000001* 0000000001* 0 0 0 0 0 00 00 00
2 2 0000002* 00000002* 000000002* 0000000003* 0 0 0 0 0 00 00 00
3 3 0000004* 00000004* 000000004* 0000000007* 0 0 0 0 0 00 00 00
4 4 0000008* 00000008* 000000008* 000000000E* 0 0 0 0 0 00 00 00
5 5 0000010* 00000010* 000000010* 000000001C* 0 0 0 0 0 00 00 00
6 6 0000020* 00000020* 000000020* 0000000038* 0 0 0 0 0 00 00 00
7 7 0000040* 00000040* 000000040* 0000000070* 0 0 0 0 0 00 00 00
8 8 0000080* 00000080* 000000080* 00000000E0* 0 0 0 0 0 00 00 00
9 9 0000100* 00000100* 000000100* 00000001C0* 0 0 0 0 0 00 00 00
10 10 0000200* 00000200* 000000200* 0000000380* 0 0 0 0 0 00 00 00
11 11 0000400* 00000400* 000000400* 0000000700* 0 0 0 0 0 00 00 00
12 12 0000800* 00000800* 000000800* 0000000E00* 0 0 0 0 0 00 00 00
13 13 0001000* 00001000* 000001000* 0000001C00* 0 0 0 0 0 00 00 00
14 14 0002000* 00002000* 000002000* 0000003800* 0 0 0 0 0 00 00 00
15 15 0004000* 00004000* 000004000* 0000007000* 0 0 0 0 0 00 00 00
16 16 0008000* 00008000* 000008000* 000000E000* 0 0 0 0 0 00 00 00
17 17 0010000* 00010000* 000010000* 000001C000* 0 0 0 0 0 00 00 00
18 18 0020000* 00020000* 000020000* 0000038000* 0 0 0 0 0 00 00 00
19 19 0040000* 00040000* 000040000* 0000070000* 0 0 0 0 0 00 00 00
20 20 0080000* 00080000* 000080000* 00000E0000* 0 0 0 0 0 00 00 00

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 2, Part G Page 871
Sample Data

21 21 0100000* 00100000* 000100000* 00001C0000* 0 0 0 0 0 00 00 00

22 22 0200000* 00200000* 000200000* 0000380000* 0 0 0 0 0 00 00 00
23 23 0400000* 00400000* 000400000* 0000700000* 0 0 0 0 0 00 00 00
24 24 0800000* 00800000* 000800000* 0000E00000* 1 1 0 0 0 01 00 00
25 25 1000000* 01000000* 001000000* 0001C00000* 0 0 0 0 0 00 00 00
26 26 0000001 02000000* 002000000* 0003800000* 0 0 0 0 0 00 00 00
27 27 0000002 04000000* 004000000* 0007000000* 0 0 0 0 0 00 00 00
28 28 0000004 08000000* 008000000* 000E000000* 0 0 0 0 0 00 00 00
29 29 0000008 10000000* 010000000* 001C000000* 0 0 0 0 0 00 00 00
30 30 0000010 20000000* 020000000* 0038000000* 0 0 0 0 0 00 00 00
31 31 0000020 40000000* 040000000* 0070000000* 0 0 0 0 0 00 00 00
32 32 0000040 00000001 080000000* 00E0000000* 0 0 1 1 0 01 00 00
33 33 0000080 00000002 100000000* 01C0000000* 0 0 0 1 1 00 00 00
34 34 0000101 00000004 000000001 0380000000* 0 0 0 1 1 00 00 00
35 35 0000202 00000008 000000002 0700000000* 0 0 0 0 0 00 00 00
36 36 0000404 00000010 000000004 0E00000000* 0 0 0 0 0 00 00 00
37 37 0000808 00000020 000000008 1C00000000* 0 0 0 0 0 00 00 00
38 38 0001011 00000040 000000011 3800000000* 0 0 0 0 0 00 00 00
39 39 0002022 00000080 000000022 7000000000* 0 0 0 0 0 00 00 00
===============================================================================================
Start clocking Summation Combiner
===============================================================================================
40 1 0004044 00000100 000000044 6000000001 0 0 0 0 0 00 00 00
41 2 0008088 00000200 000000088 4000000003 0 0 0 0 0 00 00 00
42 3 0010111 00000400 000000111 0000000007 0 0 0 0 0 00 00 00
43 4 0020222 00000800 000000222 000000000E 0 0 0 0 0 00 00 00
44 5 0040444 00001001 000000444 000000001D 0 0 0 0 0 00 00 00
45 6 0080888 00002002 000000888 000000003B 0 0 0 0 0 00 00 00
46 7 0101111 00004004 000001111 0000000077 0 0 0 0 0 00 00 00
47 8 0202222 00008008 000002222 00000000EE 0 0 0 0 0 00 00 00
48 9 0404444 00010011 000004444 00000001DD 0 0 0 0 0 00 00 00
49 10 0808888 00020022 000008888 00000003BB 1 0 0 0 1 00 00 00
50 11 1011110 00040044 000011111 0000000777 0 0 0 0 0 00 00 00
51 12 0022221 00080088 000022222 0000000EEE 0 0 0 0 0 00 00 00
52 13 0044442 00100110 000044444 0000001DDD 0 0 0 0 0 00 00 00
53 14 0088884 00200220 000088888 0000003BBB 0 0 0 0 0 00 00 00
54 15 0111109 00400440 000111111 0000007777 0 0 0 0 0 00 00 00
55 16 0222212 00800880 000222222 000000EEEE 0 1 0 0 1 00 00 00
56 17 0444424 01001100 000444444 000001DDDD 0 0 0 0 0 00 00 00
57 18 0888848 02002200 000888888 000003BBBB 1 0 0 0 1 00 00 00
58 19 1111090 04004400 001111110 0000077777 0 0 0 0 0 00 00 00
59 20 0222120 08008800 002222220 00000EEEEE 0 0 0 0 0 00 00 00
60 21 0444240 10011000 004444440 00001DDDDD 0 0 0 0 0 00 00 00

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 2, Part G Page 872
Sample Data

61 22 0888480 20022000 008888880 00003BBBBB 1 0 0 0 1 00 00 00

62 23 1110900 40044000 011111100 0000777777 0 0 0 0 0 00 00 00
63 24 0221200 00088001 022222200 0000EEEEEE 0 0 0 0 0 00 00 00
64 25 0442400 00110003 044444400 0001DDDDDD 0 0 0 0 0 00 00 00
65 26 0884800 00220006 088888800 0003BBBBBB 1 0 1 0 0 01 00 00
66 27 1109000 0044000C 111111000 0007777777 0 0 0 0 1 01 01 00
67 28 0212001 00880018 022222001 000EEEEEEE 0 1 0 0 0 11 01 01
68 29 0424002 01100031 044444002 001DDDDDDC 0 0 0 0 1 01 11 01
69 30 0848004 02200062 088888004 003BBBBBB8 1 0 1 0 1 10 01 11
70 31 1090008 044000C4 111110008 0077777770 0 0 0 0 0 00 10 01
71 32 0120010 08800188 022220010 00EEEEEEE0 0 1 0 1 0 00 00 10
72 33 0240020 11000311 044440020 01DDDDDDC1 0 0 0 1 1 00 00 00
73 34 0480040 22000622 088880040 03BBBBBB83 0 0 1 1 0 01 00 00
74 35 0900081 44000C44 111100080 0777777707 1 0 0 0 0 00 01 00
75 36 1200103 08001888 022200101 0EEEEEEE0E 0 0 0 1 1 11 00 01
76 37 0400207 10003111 044400202 1DDDDDDC1D 0 0 0 1 0 01 11 00
77 38 080040E 20006222 088800404 3BBBBBB83B 1 0 1 1 0 01 01 11
78 39 100081C 4000C444 111000808 7777777077 0 0 0 0 1 10 01 01
79 40 0001038 00018888 022001010 6EEEEEE0EF 0 0 0 1 1 00 10 01
80 41 0002070 00031110 044002020 5DDDDDC1DE 0 0 0 1 1 01 00 10
81 42 00040E0 00062220 088004040 3BBBBB83BC 0 0 1 1 1 00 01 00
82 43 00081C1 000C4440 110008081 7777770779 0 0 0 0 0 11 00 01
83 44 0010383 00188880 020010103 6EEEEE0EF2 0 0 0 1 0 01 11 00
84 45 0020707 00311100 040020206 5DDDDC1DE5 0 0 0 1 0 10 01 11
85 46 0040E0E 00622200 08004040C 3BBBB83BCB 0 0 1 1 0 11 10 01
86 47 0081C1D 00C44400 100080819 7777707797 0 1 0 0 0 00 11 10
87 48 010383A 01888801 000101032 6EEEE0EF2F 0 1 0 1 0 11 00 11
88 49 0207075 03111003 000202064 5DDDC1DE5E 0 0 0 1 0 01 11 00
89 50 040E0EA 06222006 0004040C8 3BBB83BCBC 0 0 0 1 0 10 01 11
90 51 081C1D5 0C44400C 000808191 7777077979 1 0 0 0 1 00 10 01
91 52 10383AB 18888018 001010323 6EEE0EF2F2 0 1 0 1 0 00 00 10
92 53 0070756 31110030 002020646 5DDC1DE5E5 0 0 0 1 1 00 00 00
93 54 00E0EAC 62220060 004040C8C 3BB83BCBCB 0 0 0 1 1 00 00 00
94 55 01C1D59 444400C1 008081919 7770779797 0 0 0 0 0 00 00 00
95 56 0383AB2 08880183 010103232 6EE0EF2F2F 0 1 0 1 0 01 00 00
96 57 0707565 11100307 020206464 5DC1DE5E5F 0 0 0 1 0 00 01 00
97 58 0E0EACA 2220060E 04040C8C8 3B83BCBCBF 1 0 0 1 0 10 00 01
98 59 1C1D594 44400C1C 080819191 770779797E 1 0 1 0 0 00 10 00
99 60 183AB28 08801838 101032323 6E0EF2F2FC 1 1 0 0 0 00 00 10
100 61 1075650 11003070 002064647 5C1DE5E5F8 0 0 0 0 0 00 00 00
101 62 00EACA1 220060E0 0040C8C8E 383BCBCBF0 0 0 0 0 0 00 00 00
102 63 01D5943 4400C1C0 00819191D 70779797E0 0 0 0 0 0 00 00 00
103 64 03AB286 08018380 01032323A 60EF2F2FC1 0 0 0 1 1 00 00 00

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 2, Part G Page 873
Sample Data

104 65 075650C 10030701 020646475 41DE5E5F82 0 0 0 1 1 00 00 00

105 66 0EACA18 20060E02 040C8C8EA 03BCBCBF04 1 0 0 1 0 01 00 00
106 67 1D59430 400C1C05 0819191D4 0779797E09 1 0 1 0 1 00 01 00
107 68 1AB2861 0018380A 1032323A9 0EF2F2FC12 1 0 0 1 0 10 00 01
108 69 15650C3 00307015 006464752 1DE5E5F825 0 0 0 1 1 11 10 00
109 70 0ACA186 0060E02A 00C8C8EA4 3BCBCBF04B 1 0 0 1 1 00 11 10
110 71 159430C 00C1C055 019191D48 779797E097 0 1 0 1 0 11 00 11
111 72 0B28618 018380AA 032323A90 6F2F2FC12F 1 1 0 0 1 01 11 00
112 73 1650C30 03070154 064647520 5E5E5F825E 0 0 0 0 1 11 01 11
113 74 0CA1860 060E02A8 0C8C8EA40 3CBCBF04BC 1 0 1 1 0 11 11 01
114 75 19430C0 0C1C0550 19191D480 79797E0979 1 0 1 0 1 11 11 11
115 76 1286180 18380AA0 12323A900 72F2FC12F2 0 0 0 1 0 11 11 11
116 77 050C301 30701541 046475201 65E5F825E5 0 0 0 1 0 11 11 11
117 78 0A18602 60E02A82 08C8EA402 4BCBF04BCB 1 1 1 1 1 10 11 11
118 79 1430C04 41C05505 1191D4804 1797E09796 0 1 0 1 0 10 10 11
119 80 0861808 0380AA0A 0323A9008 2F2FC12F2C 1 1 0 0 0 01 10 10
120 81 10C3011 07015415 064752011 5E5F825E59 0 0 0 0 1 00 01 10
121 82 0186022 0E02A82A 0C8EA4022 3CBF04BCB2 0 0 1 1 0 10 00 01
122 83 030C045 1C055054 191D48044 797E097964 0 0 1 0 1 11 10 00
123 84 061808A 380AA0A8 123A90088 72FC12F2C9 0 0 0 1 0 00 11 10
124 85 0C30115 70154151 047520111 65F825E593 1 0 0 1 0 11 00 11
125 86 186022A 602A82A3 08EA40222 4BF04BCB26 1 0 1 1 0 00 11 00
126 87 10C0455 40550546 11D480444 17E097964C 0 0 0 1 1 10 00 11
127 88 01808AA 00AA0A8D 03A900888 2FC12F2C99 0 1 0 1 0 00 10 00
128 89 0301155 0154151A 075201111 5F825E5932 0 0 0 1 1 01 00 10
129 90 06022AA 02A82A34 0EA402222 3F04BCB264 0 1 1 0 1 00 01 00
130 91 0C04555 05505468 1D4804445 7E097964C9 1 0 1 0 0 10 00 01
131 92 1808AAA 0AA0A8D0 1A900888A 7C12F2C992 1 1 1 0 1 00 10 00
132 93 1011555 154151A1 152011115 7825E59324 0 0 0 0 0 01 00 10
133 94 0022AAB 2A82A342 0A402222B 704BCB2648 0 1 1 0 1 00 01 00
134 95 0045556 55054684 148044457 6097964C91 0 0 0 1 1 11 00 01
135 96 008AAAC 2A0A8D09 0900888AE 412F2C9923 0 0 1 0 0 01 11 00
136 97 0115559 54151A12 12011115D 025E593246 0 0 0 0 1 11 01 11
137 98 022AAB2 282A3424 0402222BA 04BCB2648D 0 0 0 1 0 10 11 01
138 99 0455564 50546848 080444575 097964C91A 0 0 1 0 1 01 10 11
139 100 08AAAC8 20A8D090 100888AEA 12F2C99235 1 1 0 1 0 10 01 10
140 101 1155591 4151A120 0011115D5 25E593246A 0 0 0 1 1 00 10 01
141 102 02AAB22 02A34240 002222BAA 4BCB2648D5 0 1 0 1 0 00 00 10
142 103 0555644 05468481 004445755 17964C91AB 0 0 0 1 1 00 00 00
143 104 0AAAC88 0A8D0903 00888AEAA 2F2C992357 1 1 0 0 0 01 00 00
144 105 1555911 151A1206 011115D55 5E593246AE 0 0 0 0 1 01 01 00
145 106 0AAB222 2A34240C 02222BAAA 3CB2648D5C 1 0 0 1 1 11 01 01
146 107 1556445 54684818 044457555 7964C91AB8 0 0 0 0 1 01 11 01

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 2, Part G Page 874
Sample Data

147 108 0AAC88B 28D09030 0888AEAAA 72C9923571 1 1 1 1 1 01 01 11

148 109 1559117 51A12060 11115D555 6593246AE2 0 1 0 1 1 11 01 01
149 110 0AB222F 234240C0 0222BAAAB 4B2648D5C5 1 0 0 0 0 10 11 01
150 111 156445F 46848180 044575557 164C91AB8A 0 1 0 0 1 01 10 11
151 112 0AC88BF 0D090301 088AEAAAE 2C99235714 1 0 1 1 0 10 01 10
152 113 159117F 1A120602 1115D555D 593246AE28 0 0 0 0 0 00 10 01
153 114 0B222FE 34240C04 022BAAABA 32648D5C51 1 0 0 0 1 01 00 10
154 115 16445FD 68481809 045755574 64C91AB8A2 0 0 0 1 0 00 01 00
155 116 0C88BFA 50903012 08AEAAAE8 4992357144 1 1 1 1 0 01 00 01
156 117 19117F5 21206024 115D555D1 13246AE288 1 0 0 0 0 00 01 00
157 118 1222FEA 4240C048 02BAAABA2 2648D5C511 0 0 0 0 0 11 00 01
158 119 0445FD5 04818090 057555744 4C91AB8A23 0 1 0 1 1 01 11 00
159 120 088BFAA 09030120 0AEAAAE88 1923571446 1 0 1 0 1 10 01 11
160 121 1117F55 12060240 15D555D11 3246AE288D 0 0 0 0 0 00 10 01
161 122 022FEAA 240C0480 0BAAABA22 648D5C511B 0 0 1 1 0 00 00 10
162 123 045FD54 48180900 175557444 491AB8A237 0 0 0 0 0 00 00 00
163 124 08BFAA9 10301200 0EAAAE889 123571446F 1 0 1 0 0 01 00 00
164 125 117F553 20602400 1D555D113 246AE288DF 0 0 1 0 0 00 01 00
165 126 02FEAA7 40C04800 1AAABA227 48D5C511BE 0 1 1 1 1 10 00 01
166 127 05FD54F 01809001 15557444F 11AB8A237D 0 1 0 1 0 00 10 00
167 128 0BFAA9F 03012002 0AAAE889E 23571446FA 1 0 1 0 0 00 00 10
168 129 17F553F 06024004 1555D113D 46AE288DF5 0 0 0 1 1 00 00 00
169 130 0FEAA7E 0C048008 0AABA227A 0D5C511BEA 1 0 1 0 0 01 00 00
170 131 1FD54FC 18090011 1557444F5 1AB8A237D5 1 0 0 1 1 00 01 00
171 132 1FAA9F9 30120022 0AAE889EB 3571446FAA 1 0 1 0 0 10 00 01
172 133 1F553F2 60240044 155D113D7 6AE288DF55 1 0 0 1 0 00 10 00
173 134 1EAA7E4 40480089 0ABA227AE 55C511BEAA 1 0 1 1 1 00 00 10
174 135 1D54FC9 00900113 157444F5D 2B8A237D54 1 1 0 1 1 01 00 00
175 136 1AA9F93 01200227 0AE889EBA 571446FAA8 1 0 1 0 1 00 01 00
176 137 1553F26 0240044E 15D113D75 2E288DF550 0 0 0 0 0 11 00 01
177 138 0AA7E4C 0480089C 0BA227AEA 5C511BEAA0 1 1 1 0 0 00 11 00
178 139 154FC98 09001138 17444F5D4 38A237D540 0 0 0 1 1 10 00 11
179 140 0A9F931 12002270 0E889EBA9 71446FAA81 1 0 1 0 0 00 10 00
180 141 153F262 240044E0 1D113D753 6288DF5503 0 0 1 1 0 00 00 10
181 142 0A7E4C5 480089C0 1A227AEA7 4511BEAA06 1 0 1 0 0 01 00 00
182 143 14FC98B 10011381 1444F5D4F 0A237D540D 0 0 0 0 1 01 01 00
183 144 09F9316 20022702 0889EBA9E 1446FAA81A 1 0 1 0 1 11 01 01
184 145 13F262D 40044E04 1113D753D 288DF55035 0 0 0 1 0 10 11 01
185 146 07E4C5A 00089C08 0227AEA7A 511BEAA06A 0 0 0 0 0 01 10 11
186 147 0FC98B4 00113810 044F5D4F5 2237D540D5 1 0 0 0 0 01 01 10
187 148 1F93169 00227021 089EBA9EB 446FAA81AA 1 0 1 0 1 11 01 01
188 149 1F262D2 0044E042 113D753D7 08DF550355 1 0 0 1 1 10 11 01
189 150 1E4C5A4 0089C085 027AEA7AE 11BEAA06AA 1 1 0 1 1 10 10 11

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 2, Part G Page 875
Sample Data

190 151 1C98B48 0113810A 04F5D4F5C 237D540D54 1 0 0 0 1 10 10 10

191 152 1931691 02270215 09EBA9EB8 46FAA81AA9 1 0 1 1 1 01 10 10
192 153 1262D22 044E042A 13D753D71 0DF5503553 0 0 0 1 0 01 01 10
193 154 04C5A44 089C0854 07AEA7AE2 1BEAA06AA7 0 1 0 1 1 11 01 01
194 155 098B488 113810A8 0F5D4F5C4 37D540D54E 1 0 1 1 0 11 11 01
195 156 1316910 22702150 1EBA9EB89 6FAA81AA9D 0 0 1 1 1 11 11 11
196 157 062D220 44E042A0 1D753D712 5F5503553A 0 1 1 0 1 11 11 11
197 158 0C5A440 09C08540 1AEA7AE25 3EAA06AA75 1 1 1 1 1 10 11 11
198 159 18B4880 13810A80 15D4F5C4B 7D540D54EA 1 1 0 0 0 10 10 11
199 160 1169100 27021500 0BA9EB897 7AA81AA9D5 0 0 1 1 0 01 10 10
200 161 02D2201 4E042A00 1753D712E 75503553AB 0 0 0 0 1 00 01 10
201 162 05A4403 1C085400 0EA7AE25C 6AA06AA756 0 0 1 1 0 10 00 01
202 163 0B48807 3810A800 1D4F5C4B8 5540D54EAC 1 0 1 0 0 00 10 00
203 164 169100F 70215000 1A9EB8971 2A81AA9D58 0 0 1 1 0 00 00 10
204 165 0D2201E 6042A001 153D712E3 5503553AB0 1 0 0 0 1 00 00 00
205 166 1A4403C 40854002 0A7AE25C6 2A06AA7561 1 1 1 0 1 01 00 00
206 167 1488079 010A8004 14F5C4B8D 540D54EAC3 0 0 0 0 1 01 01 00
207 168 09100F2 02150009 09EB8971B 281AA9D586 1 0 1 0 1 11 01 01
208 169 12201E5 042A0012 13D712E37 503553AB0C 0 0 0 0 1 01 11 01
209 170 04403CA 08540024 07AE25C6E 206AA75618 0 0 0 0 1 11 01 11
210 171 0880795 10A80048 0F5C4B8DD 40D54EAC30 1 1 1 1 1 11 11 01
211 172 1100F2A 21500091 1EB8971BA 01AA9D5861 0 0 1 1 1 11 11 11
212 173 0201E54 42A00122 1D712E374 03553AB0C3 0 1 1 0 1 11 11 11
213 174 0403CA9 05400244 1AE25C6E9 06AA756186 0 0 1 1 1 11 11 11
214 175 0807952 0A800488 15C4B8DD3 0D54EAC30D 1 1 0 0 1 11 11 11
215 176 100F2A5 15000911 0B8971BA6 1AA9D5861A 0 0 1 1 1 11 11 11
216 177 001E54A 2A001223 1712E374C 3553AB0C35 0 0 0 0 1 00 11 11
217 178 003CA94 54002446 0E25C6E98 6AA756186A 0 0 1 1 0 11 00 11
218 179 0079528 2800488D 1C4B8DD31 554EAC30D5 0 0 1 0 0 01 11 00
219 180 00F2A50 5000911B 18971BA62 2A9D5861AA 0 0 1 1 1 10 01 11
220 181 01E54A0 20012236 112E374C4 553AB0C355 0 0 0 0 0 00 10 01
221 182 03CA940 4002446C 025C6E988 2A756186AA 0 0 0 0 0 01 00 10
222 183 0795280 000488D9 04B8DD310 54EAC30D54 0 0 0 1 0 00 01 00
223 184 0F2A500 000911B2 0971BA620 29D5861AA8 1 0 1 1 1 10 00 01
224 185 1E54A00 00122364 12E374C40 53AB0C3550 1 0 0 1 0 00 10 00
225 186 1CA9400 002446C8 05C6E9880 2756186AA0 1 0 0 0 1 01 00 10
226 187 1952800 00488D90 0B8DD3101 4EAC30D540 1 0 1 1 0 11 01 00
227 188 12A5000 00911B20 171BA6202 1D5861AA81 0 1 0 0 0 10 11 01
228 189 054A000 01223640 0E374C404 3AB0C35502 0 0 1 1 0 10 10 11
229 190 0A94000 02446C80 1C6E98808 756186AA05 1 0 1 0 0 01 10 10
230 191 1528001 0488D901 18DD31011 6AC30D540B 0 1 1 1 0 10 01 10
231 192 0A50003 0911B203 11BA62023 55861AA817 1 0 0 1 0 11 10 01
232 193 14A0006 12236407 0374C4047 2B0C35502F 0 0 0 0 1 11 11 10

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 2, Part G Page 876
Sample Data

233 194 094000C 2446C80E 06E98808E 56186AA05F 1 0 0 0 0 11 11 11

234 195 1280018 488D901C 0DD31011D 2C30D540BF 0 1 1 0 1 11 11 11
235 196 0500030 111B2039 1BA62023A 5861AA817E 0 0 1 0 0 11 11 11
236 197 0A00060 22364072 174C40475 30C35502FD 1 0 0 1 1 11 11 11
237 198 14000C0 446C80E4 0E98808EA 6186AA05FB 0 0 1 1 1 11 11 11
238 199 0800180 08D901C8 1D31011D5 430D540BF6 1 1 1 0 0 10 11 11
239 200 1000301 11B20391 1A62023AB 061AA817EC 0 1 1 0 0 10 10 11

Z[0] = 25
Z[1] = 45
Z[2] = 6B
Z[3] = 55
Z[4] = 5F
Z[5] = C2
Z[6] = 20
Z[7] = E5
Z[8] = C4
Z[9] = F8
Z[10] = 3A
Z[11] = F1
Z[12] = FF
Z[13] = 89
Z[14] = 02
Z[15] = 35

===============================================================================================
Reload this pattern into the LFSRs
Hold content of Summation Combiner regs and calculate new C[t+1] and Z values
===============================================================================================
LFSR1 <= 1C45F25
LFSR2 <= 7FF8C245
LFSR3 <= 1893A206B
LFSR4 <= 1A02F1E555
C[t+1] <= 10

===============================================================================================
Generating 125 key symbols (encryption/decryption sequence)
===============================================================================================
240 1 1C45F25 7FF8C245 1893A206B 1A02F1E555 1 1 1 0 1 10 10 11
241 2 188BE4A 7FF1848B 1127440D7 3405E3CAAB 1 1 0 0 0 01 10 10
242 3 1117C95 7FE30917 024E881AF 680BC79557 0 1 0 0 0 01 01 10
243 4 022F92B 7FC6122F 049D1035E 50178F2AAF 0 1 0 0 0 11 01 01
244 5 045F257 7F8C245E 093A206BD 202F1E555E 0 1 1 0 1 10 11 01

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 2, Part G Page 877
Sample Data

245 6 08BE4AE 7F1848BC 127440D7A 405E3CAABC 1 0 0 0 1 01 10 11

246 7 117C95C 7E309178 04E881AF4 00BC795579 0 0 0 1 0 01 01 10
247 8 02F92B8 7C6122F0 09D1035E8 0178F2AAF2 0 0 1 0 0 11 01 01
248 9 05F2570 78C245E1 13A206BD0 02F1E555E5 0 1 0 1 1 10 11 01
249 10 0BE4AE1 71848BC2 07440D7A0 05E3CAABCA 1 1 0 1 1 10 10 11
250 11 17C95C3 63091784 0E881AF40 0BC7955795 0 0 1 1 0 01 10 10
251 12 0F92B87 46122F09 1D1035E80 178F2AAF2B 1 0 1 1 0 10 01 10
252 13 1F2570F 0C245E12 1A206BD01 2F1E555E56 1 0 1 0 0 11 10 01
253 14 1E4AE1F 1848BC25 1440D7A03 5E3CAABCAC 1 0 0 0 0 00 11 10
254 15 1C95C3E 3091784A 0881AF407 3C79557958 1 1 1 0 1 11 00 11
255 16 192B87D 6122F094 11035E80F 78F2AAF2B1 1 0 0 1 1 01 11 00
256 17 12570FA 4245E128 0206BD01E 71E555E562 0 0 0 1 0 10 01 11
257 18 04AE1F4 048BC250 040D7A03D 63CAABCAC5 0 1 0 1 0 11 10 01
258 19 095C3E8 091784A0 081AF407A 479557958A 1 0 1 1 0 01 11 10
259 20 12B87D1 122F0941 1035E80F4 0F2AAF2B14 0 0 0 0 1 11 01 11
260 21 0570FA3 245E1283 006BD01E9 1E555E5628 0 0 0 0 1 01 11 01
261 22 0AE1F46 48BC2506 00D7A03D2 3CAABCAC50 1 1 0 1 0 01 01 11
262 23 15C3E8C 11784A0C 01AF407A5 79557958A0 0 0 0 0 1 10 01 01
263 24 0B87D18 22F09419 035E80F4A 72AAF2B140 1 1 0 1 1 11 10 01
264 25 170FA30 45E12832 06BD01E94 6555E56280 0 1 0 0 0 00 11 10
265 26 0E1F460 0BC25065 0D7A03D28 4AABCAC501 1 1 1 1 0 00 00 11
266 27 1C3E8C0 1784A0CB 1AF407A50 1557958A03 1 1 1 0 1 01 00 00
267 28 187D181 2F094196 15E80F4A0 2AAF2B1406 1 0 0 1 1 00 01 00
268 29 10FA302 5E12832C 0BD01E941 555E56280C 0 0 1 0 1 11 00 01
269 30 01F4604 3C250658 17A03D283 2ABCAC5019 0 0 0 1 0 01 11 00
270 31 03E8C09 784A0CB0 0F407A506 557958A033 0 0 1 0 0 10 01 11
271 32 07D1812 70941960 1E80F4A0C 2AF2B14066 0 1 1 1 1 11 10 01
272 33 0FA3024 612832C1 1D01E9419 55E56280CD 1 0 1 1 0 01 11 10
273 34 1F46049 42506583 1A03D2832 2BCAC5019A 1 0 1 1 0 01 01 11
274 35 1E8C093 04A0CB07 1407A5065 57958A0335 1 1 0 1 0 00 01 01
275 36 1D18127 0941960F 080F4A0CB 2F2B14066B 1 0 1 0 0 10 00 01
276 37 1A3024F 12832C1F 101E94196 5E56280CD7 1 1 0 0 0 00 10 00
277 38 146049F 2506583E 003D2832C 3CAC5019AE 0 0 0 1 1 01 00 10
278 39 08C093E 4A0CB07D 007A50658 7958A0335D 1 0 0 0 0 00 01 00
279 40 118127C 141960FA 00F4A0CB0 72B14066BA 0 0 0 1 1 11 00 01
280 41 03024F8 2832C1F4 01E941961 656280CD74 0 0 0 0 1 10 11 00
281 42 06049F1 506583E9 03D2832C2 4AC5019AE9 0 0 0 1 1 01 10 11
282 43 0C093E2 20CB07D2 07A506585 158A0335D3 1 1 0 1 0 10 01 10
283 44 18127C5 41960FA5 0F4A0CB0B 2B14066BA7 1 1 1 0 1 11 10 01
284 45 1024F8A 032C1F4B 1E9419616 56280CD74F 0 0 1 0 0 00 11 10
285 46 0049F15 06583E97 1D2832C2C 2C5019AE9F 0 0 1 0 1 10 00 11
286 47 0093E2B 0CB07D2F 1A5065859 58A0335D3E 0 1 1 1 1 00 10 00
287 48 0127C56 1960FA5E 14A0CB0B2 314066BA7D 0 0 0 0 0 01 00 10

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 2, Part G Page 878
Sample Data

288 49 024F8AD 32C1F4BC 094196164 6280CD74FB 0 1 1 1 0 11 01 00

289 50 049F15A 6583E978 12832C2C8 45019AE9F6 0 1 0 0 0 10 11 01
290 51 093E2B5 4B07D2F0 050658591 0A0335D3ED 1 0 0 0 1 01 10 11
291 52 127C56B 160FA5E0 0A0CB0B22 14066BA7DA 0 0 1 0 0 01 01 10
292 53 04F8AD7 2C1F4BC1 141961645 280CD74FB5 0 0 0 0 1 10 01 01
293 54 09F15AF 583E9783 0832C2C8A 5019AE9F6A 1 0 1 0 0 11 10 01
294 55 13E2B5E 307D2F06 106585915 20335D3ED5 0 0 0 0 1 11 11 10
295 56 07C56BD 60FA5E0D 00CB0B22B 4066BA7DAA 0 1 0 0 0 11 11 11
296 57 0F8AD7A 41F4BC1B 019616457 00CD74FB54 1 1 0 1 0 10 11 11
297 58 1F15AF4 03E97836 032C2C8AF 019AE9F6A9 1 1 0 1 1 10 10 11
298 59 1E2B5E9 07D2F06C 06585915E 0335D3ED52 1 1 0 0 0 01 10 10
299 60 1C56BD2 0FA5E0D8 0CB0B22BC 066BA7DAA4 1 1 1 0 0 10 01 10
300 61 18AD7A5 1F4BC1B0 196164578 0CD74FB549 1 0 1 1 1 11 10 01
301 62 115AF4B 3E978361 12C2C8AF0 19AE9F6A92 0 1 0 1 1 00 11 10
302 63 02B5E96 7D2F06C2 0585915E0 335D3ED524 0 0 0 0 0 10 00 11
303 64 056BD2D 7A5E0D85 0B0B22BC1 66BA7DAA49 0 0 1 1 0 00 10 00
304 65 0AD7A5B 74BC1B0A 161645783 4D74FB5493 1 1 0 0 0 00 00 10
305 66 15AF4B6 69783615 0C2C8AF07 1AE9F6A926 0 0 1 1 0 01 00 00
306 67 0B5E96D 52F06C2B 185915E0F 35D3ED524C 1 1 1 1 1 11 01 00
307 68 16BD2DB 25E0D857 10B22BC1F 6BA7DAA499 0 1 0 1 1 10 11 01
308 69 0D7A5B7 4BC1B0AF 01645783F 574FB54933 1 1 0 0 0 10 10 11
309 70 1AF4B6F 1783615F 02C8AF07F 2E9F6A9266 1 1 0 1 1 01 10 10
310 71 15E96DF 2F06C2BF 05915E0FF 5D3ED524CC 0 0 0 0 1 00 01 10
311 72 0BD2DBF 5E0D857F 0B22BC1FE 3A7DAA4998 1 0 1 0 0 10 00 01
312 73 17A5B7F 3C1B0AFE 1645783FD 74FB549331 0 0 0 1 1 11 10 00
313 74 0F4B6FF 783615FD 0C8AF07FA 69F6A92662 1 0 1 1 0 01 11 10
314 75 1E96DFF 706C2BFB 1915E0FF5 53ED524CC4 1 0 1 1 0 01 01 11
315 76 1D2DBFE 60D857F6 122BC1FEB 27DAA49988 1 1 0 1 0 00 01 01
316 77 1A5B7FD 41B0AFEC 045783FD7 4FB5493310 1 1 0 1 1 10 00 01
317 78 14B6FFA 03615FD8 08AF07FAE 1F6A926620 0 0 1 0 1 11 10 00
318 79 096DFF4 06C2BFB1 115E0FF5D 3ED524CC40 1 1 0 1 0 01 11 10
319 80 12DBFE8 0D857F63 02BC1FEBB 7DAA499881 0 1 0 1 1 10 01 11
320 81 05B7FD0 1B0AFEC6 05783FD77 7B54933103 0 0 0 0 0 00 10 01
321 82 0B6FFA1 3615FD8C 0AF07FAEF 76A9266206 1 0 1 1 1 00 00 10
322 83 16DFF42 6C2BFB18 15E0FF5DE 6D524CC40C 0 0 0 0 0 00 00 00
323 84 0DBFE85 5857F631 0BC1FEBBD 5AA4998819 1 0 1 1 1 01 00 00
324 85 1B7FD0B 30AFEC62 1783FD77A 3549331033 1 1 0 0 1 00 01 00
325 86 16FFA16 615FD8C5 0F07FAEF5 6A92662067 0 0 1 1 0 10 00 01
326 87 0DFF42D 42BFB18B 1E0FF5DEA 5524CC40CE 1 1 1 0 1 00 10 00
327 88 1BFE85B 057F6317 1C1FEBBD5 2A4998819C 1 0 1 0 0 00 00 10
328 89 17FD0B7 0AFEC62E 183FD77AA 5493310339 0 1 1 1 1 01 00 00
329 90 0FFA16F 15FD8C5C 107FAEF55 2926620672 1 1 0 0 1 00 01 00
330 91 1FF42DF 2BFB18B9 00FF5DEAA 524CC40CE5 1 1 0 0 0 10 00 01

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 2, Part G Page 879
Sample Data

331 92 1FE85BF 57F63172 01FEBBD55 24998819CA 1 1 0 1 1 00 10 00

332 93 1FD0B7F 2FEC62E4 03FD77AAA 4933103394 1 1 0 0 0 00 00 10
333 94 1FA16FF 5FD8C5C9 07FAEF555 1266206728 1 1 0 0 0 01 00 00
334 95 1F42DFF 3FB18B93 0FF5DEAAA 24CC40CE51 1 1 1 1 1 11 01 00
335 96 1E85BFF 7F631727 1FEBBD554 4998819CA3 1 0 1 1 0 11 11 01
336 97 1D0B7FE 7EC62E4F 1FD77AAA9 1331033947 1 1 1 0 0 10 11 11
337 98 1A16FFC 7D8C5C9F 1FAEF5553 266206728E 1 1 1 0 1 10 10 11
338 99 142DFF9 7B18B93F 1F5DEAAA7 4CC40CE51D 0 0 1 1 0 01 10 10
339 100 085BFF3 7631727F 1EBBD554E 198819CA3B 1 0 1 1 0 10 01 10
340 101 10B7FE6 6C62E4FF 1D77AAA9C 3310339477 0 0 1 0 1 00 10 01
341 102 016FFCC 58C5C9FE 1AEF55538 66206728EE 0 1 1 0 0 00 00 10
342 103 02DFF98 318B93FC 15DEAAA70 4C40CE51DC 0 1 0 0 1 00 00 00
343 104 05BFF31 631727F8 0BBD554E1 18819CA3B9 0 0 1 1 0 01 00 00
344 105 0B7FE62 462E4FF1 177AAA9C2 3103394772 1 0 0 0 0 00 01 00
345 106 16FFCC5 0C5C9FE2 0EF555384 6206728EE4 0 0 1 0 1 11 00 01
346 107 0DFF98A 18B93FC4 1DEAAA709 440CE51DC9 1 1 1 0 0 00 11 00
347 108 1BFF315 31727F88 1BD554E12 0819CA3B93 1 0 1 0 0 11 00 11
348 109 17FE62A 62E4FF11 17AAA9C24 1033947726 0 1 0 0 0 01 11 00
349 110 0FFCC54 45C9FE22 0F5553849 206728EE4C 1 1 1 0 0 01 01 11
350 111 1FF98A8 0B93FC44 1EAAA7093 40CE51DC99 1 1 1 1 1 00 01 01
351 112 1FF3150 1727F889 1D554E127 019CA3B933 1 0 1 1 1 10 00 01
352 113 1FE62A0 2E4FF112 1AAA9C24F 0339477267 1 0 1 0 0 00 10 00
353 114 1FCC541 5C9FE225 15553849E 06728EE4CF 1 1 0 0 0 00 00 10
354 115 1F98A82 393FC44B 0AAA7093C 0CE51DC99F 1 0 1 1 1 01 00 00
355 116 1F31504 727F8897 1554E1279 19CA3B933E 1 0 0 1 1 00 01 00
356 117 1E62A09 64FF112F 0AA9C24F2 339477267D 1 1 1 1 0 01 00 01
357 118 1CC5412 49FE225E 1553849E4 6728EE4CFB 1 1 0 0 1 00 01 00
358 119 198A824 13FC44BC 0AA7093C9 4E51DC99F7 1 1 1 0 1 10 00 01
359 120 1315049 27F88979 154E12792 1CA3B933EE 0 1 0 1 0 00 10 00
360 121 062A093 4FF112F3 0A9C24F24 39477267DC 0 1 1 0 0 00 00 10
361 122 0C54127 1FE225E6 153849E48 728EE4CFB8 1 1 0 1 1 01 00 00
362 123 18A824E 3FC44BCD 0A7093C91 651DC99F71 1 1 1 0 0 11 01 00
363 124 115049C 7F88979A 14E127922 4A3B933EE2 0 1 0 0 0 10 11 01
364 125 02A0938 7F112F35 09C24F244 1477267DC5 0 0 1 0 1 01 10 11

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 2, Part G Page 880
Sample Data

1.1.4 Third set of samples

Initial values for the key, BD_ADDR and clock

K_session[0] = FF K_session[1] = FF K_session[2] = FF K_session[3] = FF

K_session[4] = FF K_session[5] = FF K_session[6] = FF K_session[7] = FF
K_session[8] = FF K_session[9] = FF K_session[10] = FF K_session[11] = FF
K_session[12] = FF K_session[13] = FF K_session[14] = FF K_session[15] = FF

BD_ADDR_C[0] = FF BD_ADDR_C[1] = FF BD_ADDR_C[2] = FF

BD_ADDR_C[3] = FF BD_ADDR_C[4] = FF BD_ADDR_C[5] = FF

CL[0] = FF CL[1] = FF CL[2] = FF CL[3] = 03

The corresponding values of CLK are 0x7FF_FFFE and 0xFFF_FFFE.

===============================================================================================
Fill LFSRs with initial data
===============================================================================================
t clk# LFSR1 LFSR2 LFSR3 LFSR4 X1 X2 X3 X4 Z C[t+1] C[t] C[t-1]

0 0 0000000* 00000000* 000000000* 0000000000* 0 0 0 0 0 00 00 00

1 1 0000001* 00000001* 000000001* 0000000001* 0 0 0 0 0 00 00 00
2 2 0000003* 00000002* 000000003* 0000000003* 0 0 0 0 0 00 00 00
3 3 0000007* 00000004* 000000007* 0000000007* 0 0 0 0 0 00 00 00
4 4 000000F* 00000009* 00000000F* 000000000F* 0 0 0 0 0 00 00 00
5 5 000001F* 00000013* 00000001F* 000000001F* 0 0 0 0 0 00 00 00
6 6 000003F* 00000027* 00000003F* 000000003F* 0 0 0 0 0 00 00 00
7 7 000007F* 0000004F* 00000007F* 000000007F* 0 0 0 0 0 00 00 00
8 8 00000FF* 0000009F* 0000000FF* 00000000FF* 0 0 0 0 0 00 00 00
9 9 00001FF* 0000013F* 0000001FF* 00000001FF* 0 0 0 0 0 00 00 00
10 10 00003FF* 0000027F* 0000003FF* 00000003FF* 0 0 0 0 0 00 00 00
11 11 00007FF* 000004FF* 0000007FF* 00000007FF* 0 0 0 0 0 00 00 00
12 12 0000FFF* 000009FF* 000000FFF* 0000000FFF* 0 0 0 0 0 00 00 00
13 13 0001FFF* 000013FF* 000001FFF* 0000001FFF* 0 0 0 0 0 00 00 00
14 14 0003FFF* 000027FF* 000003FFF* 0000003FFF* 0 0 0 0 0 00 00 00
15 15 0007FFF* 00004FFF* 000007FFF* 0000007FFF* 0 0 0 0 0 00 00 00
16 16 000FFFF* 00009FFF* 00000FFFF* 000000FFFF* 0 0 0 0 0 00 00 00
17 17 001FFFF* 00013FFF* 00001FFFF* 000001FFFF* 0 0 0 0 0 00 00 00
18 18 003FFFF* 00027FFF* 00003FFFF* 000003FFFF* 0 0 0 0 0 00 00 00
19 19 007FFFF* 0004FFFF* 00007FFFF* 000007FFFF* 0 0 0 0 0 00 00 00
20 20 00FFFFF* 0009FFFF* 0000FFFFF* 00000FFFFF* 0 0 0 0 0 00 00 00
21 21 01FFFFF* 0013FFFF* 0001FFFFF* 00001FFFFF* 0 0 0 0 0 00 00 00

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 2, Part G Page 881
Sample Data

22 22 03FFFFF* 0027FFFF* 0003FFFFF* 00003FFFFF* 0 0 0 0 0 00 00 00

23 23 07FFFFF* 004FFFFF* 0007FFFFF* 00007FFFFF* 0 0 0 0 0 00 00 00
24 24 0FFFFFF* 009FFFFF* 000FFFFFF* 0000FFFFFF* 1 1 0 0 0 01 00 00
25 25 1FFFFFF* 013FFFFF* 001FFFFFF* 0001FFFFFF* 1 0 0 0 1 00 00 00
26 26 1FFFFFF 027FFFFF* 003FFFFFF* 0003FFFFFF* 1 0 0 0 1 00 00 00
27 27 1FFFFFF 04FFFFFF* 007FFFFFF* 0007FFFFFF* 1 1 0 0 0 01 00 00
28 28 1FFFFFF 09FFFFFF* 00FFFFFFF* 000FFFFFFF* 1 1 0 0 0 01 00 00
29 29 1FFFFFF 13FFFFFF* 01FFFFFFF* 001FFFFFFF* 1 1 0 0 0 01 00 00
30 30 1FFFFFF 27FFFFFF* 03FFFFFFF* 003FFFFFFF* 1 1 0 0 0 01 00 00
31 31 1FFFFFF 4FFFFFFF* 07FFFFFFF* 007FFFFFFF* 1 1 0 0 0 01 00 00
32 32 1FFFFFF 1FFFFFFF 0FFFFFFFF* 00FFFFFFFF* 1 1 1 1 0 10 00 00
33 33 1FFFFFF 3FFFFFFE 1FFFFFFFF* 01FFFFFFFF* 1 1 1 1 0 10 00 00
34 34 1FFFFFF 7FFFFFFC 1FFFFFFFF 03FFFFFFFF* 1 1 1 1 0 10 00 00
35 35 1FFFFFF 7FFFFFF9 1FFFFFFFF 07FFFFFFFF* 1 1 1 1 0 10 00 00
36 36 1FFFFFF 7FFFFFF3 1FFFFFFFF 0FFFFFFFFF* 1 1 1 1 0 10 00 00
37 37 1FFFFFF 7FFFFFE7 1FFFFFFFF 1FFFFFFFFF* 1 1 1 1 0 10 00 00
38 38 1FFFFFF 7FFFFFCF 1FFFFFFFF 3FFFFFFFFF* 1 1 1 1 0 10 00 00
39 39 1FFFFFF 7FFFFF9F 1FFFFFFFF 7FFFFFFFFF* 1 1 1 1 0 10 00 00
===============================================================================================
Start clocking Summation Combiner
===============================================================================================
40 1 1FFFFFF 7FFFFF3F 1FFFFFFFF 7FFFFFFFFF 1 1 1 1 0 01 10 00
41 2 1FFFFFF 7FFFFE7F 1FFFFFFFF 7FFFFFFFFF 1 1 1 1 1 10 01 10
42 3 1FFFFFF 7FFFFCFF 1FFFFFFFF 7FFFFFFFFF 1 1 1 1 0 10 10 01
43 4 1FFFFFF 7FFFF9FF 1FFFFFFFF 7FFFFFFFFF 1 1 1 1 0 00 10 10
44 5 1FFFFFF 7FFFF3FF 1FFFFFFFF 7FFFFFFFFF 1 1 1 1 0 11 00 10
45 6 1FFFFFF 7FFFE7FE 1FFFFFFFF 7FFFFFFFFF 1 1 1 1 1 00 11 00
46 7 1FFFFFF 7FFFCFFC 1FFFFFFFF 7FFFFFFFFF 1 1 1 1 0 00 00 11
47 8 1FFFFFF 7FFF9FF9 1FFFFFFFF 7FFFFFFFFF 1 1 1 1 0 10 00 00
48 9 1FFFFFF 7FFF3FF3 1FFFFFFFF 7FFFFFFFFF 1 1 1 1 0 01 10 00
49 10 1FFFFFF 7FFE7FE6 1FFFFFFFF 7FFFFFFFFF 1 1 1 1 1 10 01 10
50 11 1FFFFFE 7FFCFFCC 1FFFFFFFE 7FFFFFFFFF 1 1 1 1 0 10 10 01
51 12 1FFFFFC 7FF9FF99 1FFFFFFFC 7FFFFFFFFF 1 1 1 1 0 00 10 10
52 13 1FFFFF8 7FF3FF33 1FFFFFFF8 7FFFFFFFFF 1 1 1 1 0 11 00 10
53 14 1FFFFF0 7FE7FE67 1FFFFFFF0 7FFFFFFFFF 1 1 1 1 1 00 11 00
54 15 1FFFFE0 7FCFFCCF 1FFFFFFE1 7FFFFFFFFF 1 1 1 1 0 00 00 11
55 16 1FFFFC0 7F9FF99F 1FFFFFFC3 7FFFFFFFFF 1 1 1 1 0 10 00 00
56 17 1FFFF80 7F3FF33E 1FFFFFF87 7FFFFFFFFE 1 0 1 1 1 00 10 00
57 18 1FFFF00 7E7FE67C 1FFFFFF0F 7FFFFFFFFC 1 0 1 1 1 00 00 10
58 19 1FFFE01 7CFFCCF8 1FFFFFE1E 7FFFFFFFF8 1 1 1 1 0 10 00 00
59 20 1FFFC03 79FF99F0 1FFFFFC3C 7FFFFFFFF0 1 1 1 1 0 01 10 00
60 21 1FFF807 73FF33E0 1FFFFF878 7FFFFFFFE1 1 1 1 1 1 10 01 10
61 22 1FFF00F 67FE67C0 1FFFFF0F0 7FFFFFFFC3 1 1 1 1 0 10 10 01

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 2, Part G Page 882
Sample Data

62 23 1FFE01E 4FFCCF80 1FFFFE1E1 7FFFFFFF87 1 1 1 1 0 00 10 10

63 24 1FFC03C 1FF99F00 1FFFFC3C3 7FFFFFFF0F 1 1 1 1 0 11 00 10
64 25 1FF8078 3FF33E01 1FFFF8787 7FFFFFFE1E 1 1 1 1 1 00 11 00
65 26 1FF00F0 7FE67C02 1FFFF0F0F 7FFFFFFC3C 1 1 1 1 0 00 00 11
66 27 1FE01E1 7FCCF805 1FFFE1E1E 7FFFFFF878 1 1 1 1 0 10 00 00
67 28 1FC03C3 7F99F00A 1FFFC3C3C 7FFFFFF0F0 1 1 1 1 0 01 10 00
68 29 1F80787 7F33E015 1FFF87878 7FFFFFE1E1 1 0 1 1 0 10 01 10
69 30 1F00F0F 7E67C02A 1FFF0F0F0 7FFFFFC3C3 1 0 1 1 1 11 10 01
70 31 1E01E1E 7CCF8054 1FFE1E1E1 7FFFFF8787 1 1 1 1 1 01 11 10
71 32 1C03C3C 799F00A9 1FFC3C3C3 7FFFFF0F0F 1 1 1 1 1 01 01 11
72 33 1807878 733E0152 1FF878787 7FFFFE1E1E 1 0 1 1 0 00 01 01
73 34 100F0F0 667C02A5 1FF0F0F0F 7FFFFC3C3C 0 0 1 1 0 10 00 01
74 35 001E1E0 4CF8054B 1FE1E1E1F 7FFFF87878 0 1 1 1 1 00 10 00
75 36 003C3C1 19F00A96 1FC3C3C3F 7FFFF0F0F0 0 1 1 1 1 00 00 10
76 37 0078783 33E0152C 1F878787F 7FFFE1E1E1 0 1 1 1 1 01 00 00
77 38 00F0F07 67C02A59 1F0F0F0FF 7FFFC3C3C3 0 1 1 1 0 11 01 00
78 39 01E1E0E 4F8054B3 1E1E1E1FF 7FFF878787 0 1 1 1 0 11 11 01
79 40 03C3C1C 1F00A966 1C3C3C3FF 7FFF0F0F0F 0 0 1 1 1 11 11 11
80 41 0787838 3E0152CC 1878787FF 7FFE1E1E1E 0 0 1 1 1 11 11 11
81 42 0F0F070 7C02A598 10F0F0FFF 7FFC3C3C3C 1 0 0 1 1 11 11 11
82 43 1E1E0E0 78054B30 01E1E1FFF 7FF8787878 1 0 0 1 1 11 11 11
83 44 1C3C1C0 700A9660 03C3C3FFE 7FF0F0F0F0 1 0 0 1 1 11 11 11
84 45 1878380 60152CC0 078787FFC 7FE1E1E1E0 1 0 0 1 1 11 11 11
85 46 10F0700 402A5980 0F0F0FFF8 7FC3C3C3C0 0 0 1 1 1 11 11 11
86 47 01E0E00 0054B300 1E1E1FFF0 7F87878780 0 0 1 1 1 11 11 11
87 48 03C1C00 00A96601 1C3C3FFE0 7F0F0F0F00 0 1 1 0 1 11 11 11
88 49 0783800 0152CC03 18787FFC0 7E1E1E1E01 0 0 1 0 0 11 11 11
89 50 0F07000 02A59806 10F0FFF80 7C3C3C3C03 1 1 0 0 1 11 11 11
90 51 1E0E000 054B300D 01E1FFF00 7878787807 1 0 0 0 0 11 11 11
91 52 1C1C001 0A96601A 03C3FFE01 70F0F0F00F 1 1 0 1 0 10 11 11
92 53 1838003 152CC035 0787FFC03 61E1E1E01E 1 0 0 1 0 10 10 11
93 54 1070007 2A59806B 0F0FFF807 43C3C3C03C 0 0 1 1 0 01 10 10
94 55 00E000F 54B300D7 1E1FFF00F 0787878078 0 1 1 1 0 10 01 10
95 56 01C001F 296601AE 1C3FFE01F 0F0F0F00F1 0 0 1 0 1 00 10 01
96 57 038003F 52CC035C 187FFC03F 1E1E1E01E2 0 1 1 0 0 00 00 10
97 58 070007F 259806B8 10FFF807F 3C3C3C03C4 0 1 0 0 1 00 00 00
98 59 0E000FE 4B300D71 01FFF00FE 7878780788 1 0 0 0 1 00 00 00
99 60 1C001FD 16601AE2 03FFE01FD 70F0F00F10 1 0 0 1 0 01 00 00
100 61 18003FA 2CC035C5 07FFC03FB 61E1E01E21 1 1 0 1 0 11 01 00
101 62 10007F4 59806B8B 0FFF807F7 43C3C03C43 0 1 1 1 0 11 11 01
102 63 0000FE8 3300D717 1FFF00FEE 0787807887 0 0 1 1 1 11 11 11
103 64 0001FD0 6601AE2F 1FFE01FDC 0F0F00F10E 0 0 1 0 0 11 11 11
104 65 0003FA0 4C035C5F 1FFC03FB8 1E1E01E21D 0 0 1 0 0 11 11 11

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 2, Part G Page 883
Sample Data

105 66 0007F40 1806B8BE 1FF807F70 3C3C03C43B 0 0 1 0 0 11 11 11

106 67 000FE81 300D717C 1FF00FEE1 7878078877 0 0 1 0 0 11 11 11
107 68 001FD02 601AE2F8 1FE01FDC2 70F00F10EF 0 0 1 1 1 11 11 11
108 69 003FA05 4035C5F0 1FC03FB84 61E01E21DE 0 0 1 1 1 11 11 11
109 70 007F40B 006B8BE0 1F807F708 43C03C43BC 0 0 1 1 1 11 11 11
110 71 00FE816 00D717C0 1F00FEE11 0780788778 0 1 1 1 0 10 11 11
111 72 01FD02C 01AE2F81 1E01FDC23 0F00F10EF1 0 1 1 0 0 10 10 11
112 73 03FA059 035C5F02 1C03FB847 1E01E21DE3 0 0 1 0 1 10 10 10
113 74 07F40B3 06B8BE05 1807F708F 3C03C43BC7 0 1 1 0 0 01 10 10
114 75 0FE8166 0D717C0B 100FEE11E 780788778F 1 0 0 0 0 01 01 10
115 76 1FD02CD 1AE2F817 001FDC23D 700F10EF1F 1 1 0 0 1 11 01 01
116 77 1FA059B 35C5F02F 003FB847A 601E21DE3F 1 1 0 0 1 10 11 01
117 78 1F40B37 6B8BE05E 007F708F4 403C43BC7F 1 1 0 0 0 10 10 11
118 79 1E8166E 5717C0BD 00FEE11E9 00788778FF 1 0 0 0 1 10 10 10
119 80 1D02CDC 2E2F817A 01FDC23D3 00F10EF1FE 1 0 0 1 0 01 10 10
120 81 1A059B9 5C5F02F5 03FB847A6 01E21DE3FD 1 0 0 1 1 01 01 10
121 82 140B373 38BE05EB 07F708F4C 03C43BC7FB 0 1 0 1 1 11 01 01
122 83 08166E7 717C0BD7 0FEE11E98 0788778FF7 1 0 1 1 0 11 11 01
123 84 102CDCF 62F817AE 1FDC23D31 0F10EF1FEF 0 1 1 0 1 11 11 11
124 85 0059B9F 45F02F5C 1FB847A63 1E21DE3FDE 0 1 1 0 1 11 11 11
125 86 00B373E 0BE05EB9 1F708F4C7 3C43BC7FBC 0 1 1 0 1 11 11 11
126 87 0166E7D 17C0BD72 1EE11E98F 788778FF78 0 1 1 1 0 10 11 11
127 88 02CDCFB 2F817AE5 1DC23D31F 710EF1FEF1 0 1 1 0 0 10 10 11
128 89 059B9F7 5F02F5CA 1B847A63F 621DE3FDE2 0 0 1 0 1 10 10 10
129 90 0B373EF 3E05EB94 1708F4C7F 443BC7FBC4 1 0 0 0 1 10 10 10
130 91 166E7DF 7C0BD728 0E11E98FF 08778FF788 0 0 1 0 1 10 10 10
131 92 0CDCFBE 7817AE50 1C23D31FF 10EF1FEF10 1 0 1 1 1 01 10 10
132 93 19B9F7D 702F5CA1 1847A63FE 21DE3FDE21 1 0 1 1 0 10 01 10
133 94 1373EFB 605EB942 108F4C7FC 43BC7FBC43 0 0 0 1 1 00 10 01
134 95 06E7DF7 40BD7285 011E98FF8 0778FF7886 0 1 0 0 1 01 00 10
135 96 0DCFBEF 017AE50A 023D31FF0 0EF1FEF10D 1 0 0 1 1 00 01 00
136 97 1B9F7DF 02F5CA15 047A63FE1 1DE3FDE21A 1 1 0 1 1 10 00 01
137 98 173EFBF 05EB942B 08F4C7FC3 3BC7FBC434 0 1 1 1 1 00 10 00
138 99 0E7DF7F 0BD72856 11E98FF87 778FF78869 1 1 0 1 1 00 00 10
139 100 1CFBEFF 17AE50AC 03D31FF0F 6F1FEF10D3 1 1 0 0 0 01 00 00
140 101 19F7DFE 2F5CA159 07A63FE1E 5E3FDE21A7 1 0 0 0 0 00 01 00
141 102 13EFBFC 5EB942B3 0F4C7FC3C 3C7FBC434F 0 1 1 0 0 10 00 01
142 103 07DF7F8 3D728566 1E98FF878 78FF78869F 0 0 1 1 0 00 10 00
143 104 0FBEFF0 7AE50ACD 1D31FF0F0 71FEF10D3E 1 1 1 1 0 11 00 10
144 105 1F7DFE1 75CA159B 1A63FE1E1 63FDE21A7D 1 1 1 1 1 00 11 00
145 106 1EFBFC3 6B942B36 14C7FC3C3 47FBC434FB 1 1 0 1 1 11 00 11
146 107 1DF7F86 5728566D 098FF8786 0FF78869F7 1 0 1 1 0 00 11 00
147 108 1BEFF0C 2E50ACDB 131FF0F0C 1FEF10D3EF 1 0 0 1 0 11 00 11

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 2, Part G Page 884
Sample Data

148 109 17DFE19 5CA159B6 063FE1E19 3FDE21A7DF 0 1 0 1 1 01 11 00

149 110 0FBFC33 3942B36D 0C7FC3C32 7FBC434FBF 1 0 1 1 0 01 01 11
150 111 1F7F866 728566DB 18FF87865 7F78869F7E 1 1 1 0 0 00 01 01
151 112 1EFF0CC 650ACDB6 11FF0F0CB 7EF10D3EFC 1 0 0 1 0 10 00 01
152 113 1DFE199 4A159B6D 03FE1E196 7DE21A7DF9 1 0 0 1 0 00 10 00
153 114 1BFC333 142B36DB 07FC3C32C 7BC434FBF3 1 0 0 1 0 00 00 10
154 115 17F8666 28566DB6 0FF878659 778869F7E6 0 0 1 1 0 01 00 00
155 116 0FF0CCC 50ACDB6D 1FF0F0CB3 6F10D3EFCC 1 1 1 0 0 11 01 00
156 117 1FE1999 2159B6DA 1FE1E1966 5E21A7DF99 1 0 1 0 1 10 11 01
157 118 1FC3332 42B36DB5 1FC3C32CC 3C434FBF33 1 1 1 0 1 10 10 11
158 119 1F86664 0566DB6B 1F8786599 78869F7E67 1 0 1 1 1 01 10 10
159 120 1F0CCC8 0ACDB6D6 1F0F0CB33 710D3EFCCE 1 1 1 0 0 10 01 10
160 121 1E19991 159B6DAC 1E1E19666 621A7DF99D 1 1 1 0 1 11 10 01
161 122 1C33323 2B36DB58 1C3C32CCC 4434FBF33B 1 0 1 0 1 00 11 10
162 123 1866647 566DB6B0 187865999 0869F7E676 1 0 1 0 0 11 00 11
163 124 10CCC8F 2CDB6D60 10F0CB333 10D3EFCCEC 0 1 0 1 1 01 11 00
164 125 019991E 59B6DAC0 01E196666 21A7DF99D9 0 1 0 1 1 10 01 11
165 126 033323C 336DB580 03C32CCCD 434FBF33B3 0 0 0 0 0 00 10 01
166 127 0666478 66DB6B01 07865999A 069F7E6766 0 1 0 1 0 00 00 10
167 128 0CCC8F0 4DB6D603 0F0CB3334 0D3EFCCECD 1 1 1 0 1 01 00 00
168 129 19991E1 1B6DAC07 1E1966669 1A7DF99D9B 1 0 1 0 1 00 01 00
169 130 13323C3 36DB580E 1C32CCCD3 34FBF33B37 0 1 1 1 1 10 00 01
170 131 0664786 6DB6B01C 1865999A7 69F7E6766F 0 1 1 1 1 00 10 00
171 132 0CC8F0D 5B6D6039 10CB3334F 53EFCCECDF 1 0 0 1 0 00 00 10
172 133 1991E1A 36DAC073 01966669E 27DF99D9BF 1 1 0 1 1 01 00 00
173 134 1323C35 6DB580E6 032CCCD3C 4FBF33B37E 0 1 0 1 1 00 01 00
174 135 064786A 5B6B01CD 065999A78 1F7E6766FC 0 0 0 0 0 11 00 01
175 136 0C8F0D5 36D6039B 0CB3334F0 3EFCCECDF9 1 1 1 1 1 00 11 00
176 137 191E1AA 6DAC0737 1966669E1 7DF99D9BF3 1 1 1 1 0 00 00 11
177 138 123C354 5B580E6E 12CCCD3C3 7BF33B37E7 0 0 0 1 1 00 00 00
178 139 04786A9 36B01CDC 05999A787 77E6766FCE 0 1 0 1 0 01 00 00
179 140 08F0D53 6D6039B8 0B3334F0E 6FCCECDF9C 1 0 1 1 0 11 01 00
180 141 11E1AA6 5AC07370 166669E1D 5F99D9BF38 0 1 0 1 1 10 11 01
181 142 03C354C 3580E6E0 0CCCD3C3A 3F33B37E70 0 1 1 0 0 10 10 11
182 143 0786A99 6B01CDC0 1999A7875 7E6766FCE1 0 0 1 0 1 10 10 10
183 144 0F0D533 56039B81 13334F0EB 7CCECDF9C2 1 0 0 1 0 01 10 10
184 145 1E1AA66 2C073703 06669E1D6 799D9BF385 1 0 0 1 1 01 01 10
185 146 1C354CC 580E6E06 0CCD3C3AC 733B37E70B 1 0 1 0 1 11 01 01
186 147 186A998 301CDC0C 199A78759 66766FCE17 1 0 1 0 1 10 11 01
187 148 10D5331 6039B818 1334F0EB2 4CECDF9C2F 0 0 0 1 1 01 10 11
188 149 01AA662 40737031 0669E1D65 19D9BF385E 0 0 0 1 0 01 01 10
189 150 0354CC5 00E6E063 0CD3C3ACB 33B37E70BD 0 1 1 1 0 00 01 01
190 151 06A998A 01CDC0C6 19A787596 6766FCE17B 0 1 1 0 0 10 00 01

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 2, Part G Page 885
Sample Data

191 152 0D53315 039B818C 134F0EB2C 4ECDF9C2F6 1 1 0 1 1 00 10 00

192 153 1AA662A 07370318 069E1D659 1D9BF385ED 1 0 0 1 0 00 00 10
193 154 154CC54 0E6E0630 0D3C3ACB3 3B37E70BDB 0 0 1 0 1 00 00 00
194 155 0A998A8 1CDC0C60 1A7875967 766FCE17B6 1 1 1 0 1 01 00 00
195 156 1533151 39B818C0 14F0EB2CE 6CDF9C2F6C 0 1 0 1 1 00 01 00
196 157 0A662A3 73703180 09E1D659D 59BF385ED8 1 0 1 1 1 10 00 01
197 158 14CC547 66E06301 13C3ACB3A 337E70BDB0 0 1 0 0 1 11 10 00
198 159 0998A8E 4DC0C602 078759675 66FCE17B61 1 1 0 1 0 01 11 10
199 160 133151D 1B818C05 0F0EB2CEB 4DF9C2F6C2 0 1 1 1 0 01 01 11
200 161 0662A3B 3703180B 1E1D659D6 1BF385ED85 0 0 1 1 1 11 01 01
201 162 0CC5477 6E063017 1C3ACB3AC 37E70BDB0B 1 0 1 1 0 11 11 01
202 163 198A8EF 5C0C602F 187596759 6FCE17B617 1 0 1 1 0 10 11 11
203 164 13151DE 3818C05F 10EB2CEB2 5F9C2F6C2F 0 0 0 1 1 01 10 11
204 165 062A3BC 703180BF 01D659D65 3F385ED85E 0 0 0 0 1 00 01 10
205 166 0C54779 6063017E 03ACB3ACB 7E70BDB0BD 1 0 0 0 1 11 00 01
206 167 18A8EF2 40C602FD 075967597 7CE17B617B 1 1 0 1 0 00 11 00
207 168 1151DE4 018C05FA 0EB2CEB2F 79C2F6C2F7 0 1 1 1 1 11 00 11
208 169 02A3BC9 03180BF5 1D659D65E 7385ED85EE 0 0 1 1 1 01 11 00
209 170 0547793 063017EB 1ACB3ACBC 670BDB0BDC 0 0 1 0 0 10 01 11
210 171 0A8EF27 0C602FD6 159675978 4E17B617B9 1 0 0 0 1 00 10 01
211 172 151DE4E 18C05FAD 0B2CEB2F1 1C2F6C2F73 0 1 1 0 0 00 00 10
212 173 0A3BC9C 3180BF5A 1659D65E3 385ED85EE6 1 1 0 0 0 01 00 00
213 174 1477938 63017EB5 0CB3ACBC6 70BDB0BDCC 0 0 1 1 1 00 01 00
214 175 08EF270 4602FD6A 19675978D 617B617B99 1 0 1 0 0 10 00 01
215 176 11DE4E1 0C05FAD5 12CEB2F1A 42F6C2F733 0 0 0 1 1 11 10 00
216 177 03BC9C3 180BF5AA 059D65E34 05ED85EE67 0 0 0 1 0 00 11 10
217 178 0779387 3017EB55 0B3ACBC68 0BDB0BDCCF 0 0 1 1 0 11 00 11
218 179 0EF270F 602FD6AA 1675978D0 17B617B99F 1 0 0 1 1 01 11 00
219 180 1DE4E1F 405FAD54 0CEB2F1A1 2F6C2F733F 1 0 1 0 1 10 01 11
220 181 1BC9C3F 00BF5AA9 19D65E342 5ED85EE67F 1 1 1 1 0 10 10 01
221 182 179387F 017EB552 13ACBC684 3DB0BDCCFE 0 0 0 1 1 10 10 10
222 183 0F270FF 02FD6AA5 075978D09 7B617B99FC 1 1 0 0 0 01 10 10
223 184 1E4E1FF 05FAD54A 0EB2F1A12 76C2F733F9 1 1 1 1 1 10 01 10
224 185 1C9C3FE 0BF5AA94 1D65E3425 6D85EE67F2 1 1 1 1 0 10 10 01
225 186 19387FD 17EB5529 1ACBC684B 5B0BDCCFE4 1 1 1 0 1 01 10 10
226 187 1270FFA 2FD6AA53 15978D096 3617B99FC9 0 1 0 0 0 01 01 10
227 188 04E1FF5 5FAD54A7 0B2F1A12C 6C2F733F93 0 1 1 0 1 11 01 01
228 189 09C3FEB 3F5AA94E 165E34258 585EE67F27 1 0 0 0 0 10 11 01
229 190 1387FD7 7EB5529C 0CBC684B1 30BDCCFE4F 0 1 1 1 1 10 10 11
230 191 070FFAE 7D6AA538 1978D0962 617B99FC9E 0 0 1 0 1 10 10 10
231 192 0E1FF5C 7AD54A70 12F1A12C4 42F733F93D 1 1 0 1 1 01 10 10
232 193 1C3FEB9 75AA94E1 05E342588 05EE67F27A 1 1 0 1 0 10 01 10
233 194 187FD73 6B5529C3 0BC684B10 0BDCCFE4F4 1 0 1 1 1 11 10 01

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 2, Part G Page 886
Sample Data

234 195 10FFAE6 56AA5386 178D09621 17B99FC9E8 0 1 0 1 1 00 11 10

235 196 01FF5CC 2D54A70C 0F1A12C43 2F733F93D0 0 0 1 0 1 10 00 11
236 197 03FEB98 5AA94E19 1E3425887 5EE67F27A1 0 1 1 1 1 00 10 00
237 198 07FD731 35529C33 1C684B10F 3DCCFE4F42 0 0 1 1 0 00 00 10
238 199 0FFAE63 6AA53866 18D09621F 7B99FC9E84 1 1 1 1 0 10 00 00
239 200 1FF5CC6 554A70CD 11A12C43F 7733F93D09 1 0 0 0 1 11 10 00

Z[0] = 59
Z[1] = 3B
Z[2] = EF
Z[3] = 07
Z[4] = 13
Z[5] = 70
Z[6] = 9B
Z[7] = B7
Z[8] = 52
Z[9] = 8F
Z[10] = 3E
Z[11] = B9
Z[12] = A5
Z[13] = AC
Z[14] = EA
Z[15] = 9E

===============================================================================================
Reload this pattern into the LFSRs
Hold content of Summation Combiner regs and calculate new C[t+1] and Z values
===============================================================================================
LFSR1 <= 1521359
LFSR2 <= 528F703B
LFSR3 <= 0AC3E9BEF
LFSR4 <= 4FEAB9B707
C[t+1] <= 00

===============================================================================================
Generating 125 key symbols (encryption/decryption sequence)
===============================================================================================
240 1 1521359 528F703B 0AC3E9BEF 4FEAB9B707 0 1 1 1 1 00 10 00
241 2 0A426B3 251EE076 1587D37DE 1FD5736E0F 1 0 0 1 0 00 00 10
242 3 1484D67 4A3DC0ED 0B0FA6FBD 3FAAE6DC1E 0 0 1 1 0 01 00 00
243 4 0909ACF 147B81DA 161F4DF7A 7F55CDB83D 1 0 0 0 0 00 01 00
244 5 121359E 28F703B5 0C3E9BEF5 7EAB9B707B 0 1 1 1 1 10 00 01
245 6 0426B3C 51EE076B 187D37DEB 7D5736E0F6 0 1 1 0 0 00 10 00

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 2, Part G Page 887
Sample Data

246 7 084D679 23DC0ED6 10FA6FBD7 7AAE6DC1EC 1 1 0 1 1 00 00 10

247 8 109ACF2 47B81DAC 01F4DF7AF 755CDB83D8 0 1 0 0 1 00 00 00
248 9 01359E4 0F703B59 03E9BEF5E 6AB9B707B1 0 0 0 1 1 00 00 00
249 10 026B3C8 1EE076B3 07D37DEBD 55736E0F63 0 1 0 0 1 00 00 00
250 11 04D6791 3DC0ED67 0FA6FBD7A 2AE6DC1EC7 0 1 1 1 1 01 00 00
251 12 09ACF22 7B81DACF 1F4DF7AF4 55CDB83D8F 1 1 1 1 1 11 01 00
252 13 1359E44 7703B59E 1E9BEF5E8 2B9B707B1F 0 0 1 1 1 10 11 01
253 14 06B3C88 6E076B3C 1D37DEBD0 5736E0F63F 0 0 1 0 1 01 10 11
254 15 0D67911 5C0ED678 1A6FBD7A1 2E6DC1EC7E 1 0 1 0 1 01 01 10
255 16 1ACF223 381DACF0 14DF7AF42 5CDB83D8FD 1 0 0 1 1 11 01 01
256 17 159E446 703B59E0 09BEF5E85 39B707B1FA 0 0 1 1 1 10 11 01
257 18 0B3C88C 6076B3C0 137DEBD0A 736E0F63F4 1 0 0 0 1 01 10 11
258 19 1679118 40ED6780 06FBD7A15 66DC1EC7E8 0 1 0 1 1 01 01 10
259 20 0CF2231 01DACF00 0DF7AF42A 4DB83D8FD1 1 1 1 1 1 00 01 01
260 21 19E4463 03B59E01 1BEF5E854 1B707B1FA3 1 1 1 0 1 10 00 01
261 22 13C88C6 076B3C03 17DEBD0A9 36E0F63F47 0 0 0 1 1 11 10 00
262 23 079118C 0ED67807 0FBD7A152 6DC1EC7E8E 0 1 1 1 0 01 11 10
263 24 0F22318 1DACF00E 1F7AF42A4 5B83D8FD1D 1 1 1 1 1 01 01 11
264 25 1E44630 3B59E01C 1EF5E8548 3707B1FA3B 1 0 1 0 1 11 01 01
265 26 1C88C61 76B3C039 1DEBD0A91 6E0F63F477 1 1 1 0 0 11 11 01
266 27 19118C3 6D678073 1BD7A1523 5C1EC7E8EF 1 0 1 0 1 11 11 11
267 28 1223187 5ACF00E6 17AF42A46 383D8FD1DE 0 1 0 0 0 11 11 11
268 29 044630E 359E01CC 0F5E8548D 707B1FA3BD 0 1 1 0 1 11 11 11
269 30 088C61C 6B3C0399 1EBD0A91A 60F63F477B 1 0 1 1 0 10 11 11
270 31 1118C39 56780733 1D7A15234 41EC7E8EF6 0 0 1 1 0 10 10 11
271 32 0231872 2CF00E67 1AF42A468 03D8FD1DEC 0 1 1 1 1 01 10 10
272 33 04630E5 59E01CCE 15E8548D1 07B1FA3BD8 0 1 0 1 1 01 01 10
273 34 08C61CB 33C0399D 0BD0A91A3 0F63F477B1 1 1 1 0 0 00 01 01
274 35 118C396 6780733A 17A152347 1EC7E8EF63 0 1 0 1 0 10 00 01
275 36 031872D 4F00E674 0F42A468E 3D8FD1DEC7 0 0 1 1 0 00 10 00
276 37 0630E5A 1E01CCE8 1E8548D1D 7B1FA3BD8E 0 0 1 0 1 01 00 10
277 38 0C61CB5 3C0399D0 1D0A91A3B 763F477B1C 1 0 1 0 1 00 01 00
278 39 18C396A 780733A0 1A1523477 6C7E8EF639 1 0 1 0 0 10 00 01
279 40 11872D5 700E6741 142A468EF 58FD1DEC72 0 0 0 1 1 11 10 00
280 41 030E5AB 601CCE83 08548D1DF 31FA3BD8E5 0 0 1 1 1 00 11 10
281 42 061CB57 40399D07 10A91A3BF 63F477B1CB 0 0 0 1 1 10 00 11
282 43 0C396AF 00733A0F 01523477E 47E8EF6396 1 0 0 1 0 00 10 00
283 44 1872D5F 00E6741F 02A468EFD 0FD1DEC72C 1 1 0 1 1 00 00 10
284 45 10E5ABE 01CCE83F 0548D1DFA 1FA3BD8E58 0 1 0 1 0 01 00 00
285 46 01CB57C 0399D07F 0A91A3BF4 3F477B1CB0 0 1 1 0 1 00 01 00
286 47 0396AF9 0733A0FE 1523477E9 7E8EF63961 0 0 0 1 1 11 00 01
287 48 072D5F3 0E6741FD 0A468EFD2 7D1DEC72C3 0 0 1 0 0 01 11 00
288 49 0E5ABE7 1CCE83FA 148D1DFA4 7A3BD8E587 1 1 0 0 1 10 01 11

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 2, Part G Page 888
Sample Data

289 50 1CB57CE 399D07F4 091A3BF49 7477B1CB0F 1 1 1 0 1 11 10 01

290 51 196AF9D 733A0FE9 123477E92 68EF63961E 1 0 0 1 1 00 11 10
291 52 12D5F3B 66741FD2 0468EFD25 51DEC72C3C 0 0 0 1 1 10 00 11
292 53 05ABE77 4CE83FA4 08D1DFA4B 23BD8E5879 0 1 1 1 1 00 10 00
293 54 0B57CEE 19D07F49 11A3BF496 477B1CB0F2 1 1 0 0 0 00 00 10
294 55 16AF9DC 33A0FE92 03477E92C 0EF63961E4 0 1 0 1 0 01 00 00
295 56 0D5F3B8 6741FD25 068EFD259 1DEC72C3C9 1 0 0 1 1 00 01 00
296 57 1ABE771 4E83FA4B 0D1DFA4B3 3BD8E58793 1 1 1 1 0 01 00 01
297 58 157CEE2 1D07F496 1A3BF4967 77B1CB0F26 0 0 1 1 1 00 01 00
298 59 0AF9DC5 3A0FE92D 1477E92CE 6F63961E4D 1 0 0 0 1 11 00 01
299 60 15F3B8B 741FD25A 08EFD259C 5EC72C3C9B 0 0 1 1 1 01 11 00
300 61 0BE7716 683FA4B4 11DFA4B39 3D8E587937 1 0 0 1 1 10 01 11
301 62 17CEE2D 507F4968 03BF49672 7B1CB0F26E 0 0 0 0 0 00 10 01
302 63 0F9DC5B 20FE92D0 077E92CE4 763961E4DC 1 1 0 0 0 00 00 10
303 64 1F3B8B6 41FD25A0 0EFD259C9 6C72C3C9B9 1 1 1 0 1 01 00 00
304 65 1E7716D 03FA4B40 1DFA4B393 58E5879373 1 1 1 1 1 11 01 00
305 66 1CEE2DB 07F49680 1BF496727 31CB0F26E6 1 1 1 1 1 11 11 01
306 67 19DC5B7 0FE92D00 17E92CE4E 63961E4DCD 1 1 0 1 0 10 11 11
307 68 13B8B6F 1FD25A00 0FD259C9C 472C3C9B9A 0 1 1 0 0 10 10 11
308 69 07716DF 3FA4B400 1FA4B3938 0E58793735 0 1 1 0 0 01 10 10
309 70 0EE2DBF 7F496800 1F4967271 1CB0F26E6A 1 0 1 1 0 10 01 10
310 71 1DC5B7F 7E92D000 1E92CE4E2 3961E4DCD4 1 1 1 0 1 11 10 01
311 72 1B8B6FF 7D25A001 1D259C9C4 72C3C9B9A9 1 0 1 1 0 01 11 10
312 73 1716DFF 7A4B4002 1A4B39389 6587937352 0 0 1 1 1 10 01 11
313 74 0E2DBFF 74968005 149672713 4B0F26E6A5 1 1 0 0 0 11 10 01
314 75 1C5B7FE 692D000B 092CE4E26 161E4DCD4B 1 0 1 0 1 00 11 10
315 76 18B6FFC 525A0017 1259C9C4D 2C3C9B9A96 1 0 0 0 1 10 00 11
316 77 116DFF8 24B4002F 04B39389B 587937352C 0 1 0 0 1 11 10 00
317 78 02DBFF1 4968005F 096727136 30F26E6A58 0 0 1 1 1 00 11 10
318 79 05B7FE3 12D000BF 12CE4E26C 61E4DCD4B1 0 1 0 1 0 11 00 11
319 80 0B6FFC7 25A0017F 059C9C4D8 43C9B9A963 1 1 0 1 0 00 11 00
320 81 16DFF8E 4B4002FF 0B39389B1 07937352C6 0 0 1 1 0 11 00 11
321 82 0DBFF1C 168005FF 167271363 0F26E6A58C 1 1 0 0 1 01 11 00
322 83 1B7FE38 2D000BFF 0CE4E26C7 1E4DCD4B18 1 0 1 0 1 10 01 11
323 84 16FFC70 5A0017FF 19C9C4D8F 3C9B9A9631 0 0 1 1 0 11 10 01
324 85 0DFF8E1 34002FFF 139389B1E 7937352C62 1 0 0 0 0 00 11 10
325 86 1BFF1C3 68005FFF 07271363D 726E6A58C4 1 0 0 0 1 10 00 11
326 87 17FE387 5000BFFE 0E4E26C7B 64DCD4B188 0 0 1 1 0 00 10 00
327 88 0FFC70F 20017FFD 1C9C4D8F6 49B9A96311 1 0 1 1 1 00 00 10
328 89 1FF8E1F 4002FFFB 19389B1ED 137352C623 1 0 1 0 0 01 00 00
329 90 1FF1C3F 0005FFF7 1271363DB 26E6A58C46 1 0 0 1 1 00 01 00
330 91 1FE387F 000BFFEE 04E26C7B6 4DCD4B188C 1 0 0 1 0 10 00 01
331 92 1FC70FF 0017FFDC 09C4D8F6D 1B9A963118 1 0 1 1 1 00 10 00

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 2, Part G Page 889
Sample Data

332 93 1F8E1FF 002FFFB8 1389B1EDA 37352C6231 1 0 0 0 1 01 00 10

333 94 1F1C3FF 005FFF70 071363DB4 6E6A58C462 1 0 0 0 0 00 01 00
334 95 1E387FE 00BFFEE0 0E26C7B68 5CD4B188C5 1 1 1 1 0 01 00 01
335 96 1C70FFC 017FFDC1 1C4D8F6D1 39A963118A 1 0 1 1 0 11 01 00
336 97 18E1FF9 02FFFB82 189B1EDA2 7352C62315 1 1 1 0 0 11 11 01
337 98 11C3FF2 05FFF705 11363DB45 66A58C462B 0 1 0 1 1 11 11 11
338 99 0387FE4 0BFFEE0A 026C7B68B 4D4B188C56 0 1 0 0 0 11 11 11
339 100 070FFC9 17FFDC15 04D8F6D16 1A963118AD 0 1 0 1 1 11 11 11
340 101 0E1FF92 2FFFB82B 09B1EDA2C 352C62315A 1 1 1 0 0 10 11 11
341 102 1C3FF24 5FFF7057 1363DB458 6A58C462B4 1 1 0 0 0 10 10 11
342 103 187FE48 3FFEE0AE 06C7B68B0 54B188C569 1 1 0 1 1 01 10 10
343 104 10FFC90 7FFDC15C 0D8F6D161 2963118AD2 0 1 1 0 1 01 01 10
344 105 01FF920 7FFB82B9 1B1EDA2C2 52C62315A5 0 1 1 1 0 00 01 01
345 106 03FF240 7FF70573 163DB4584 258C462B4B 0 1 0 1 0 10 00 01
346 107 07FE481 7FEE0AE6 0C7B68B08 4B188C5696 0 1 1 0 0 00 10 00
347 108 0FFC902 7FDC15CD 18F6D1610 163118AD2D 1 1 1 0 1 00 00 10
348 109 1FF9204 7FB82B9A 11EDA2C20 2C62315A5B 1 1 0 0 0 01 00 00
349 110 1FF2408 7F705735 03DB45841 58C462B4B6 1 0 0 1 1 00 01 00
350 111 1FE4810 7EE0AE6B 07B68B082 3188C5696C 1 1 0 1 1 10 00 01
351 112 1FC9021 7DC15CD6 0F6D16105 63118AD2D8 1 1 1 0 1 00 10 00
352 113 1F92042 7B82B9AD 1EDA2C20B 462315A5B0 1 1 1 0 1 00 00 10
353 114 1F24084 7705735A 1DB458416 0C462B4B61 1 0 1 0 0 01 00 00
354 115 1E48108 6E0AE6B5 1B68B082C 188C5696C3 1 0 1 1 0 11 01 00
355 116 1C90211 5C15CD6A 16D161059 3118AD2D86 1 0 0 0 0 10 11 01
356 117 1920422 382B9AD5 0DA2C20B3 62315A5B0D 1 0 1 0 0 10 10 11
357 118 1240845 705735AA 1B4584167 4462B4B61A 0 0 1 0 1 10 10 10
358 119 048108A 60AE6B55 168B082CF 08C5696C34 0 1 0 1 0 01 10 10
359 120 0902114 415CD6AB 0D161059E 118AD2D869 1 0 1 1 0 10 01 10
360 121 1204228 02B9AD56 1A2C20B3D 2315A5B0D2 0 1 1 0 0 11 10 01
361 122 0408451 05735AAD 14584167B 462B4B61A4 0 0 0 0 1 11 11 10
362 123 08108A2 0AE6B55B 08B082CF7 0C5696C348 1 1 1 0 0 10 11 11
363 124 1021144 15CD6AB6 1161059EF 18AD2D8690 0 1 0 1 0 10 10 11
364 125 0042289 2B9AD56C 02C20B3DE 315A5B0D20 0 1 0 0 1 10 10 10

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 2, Part G Page 890
Sample Data

1.1.5 Fourth set of samples

Initial values for the key, BD_ADDR and clock

K_session[0] = 21 K_session[1] = 87 K_session[2] = F0 K_session[3] = 4A

K_session[4] = BA K_session[5] = 90 K_session[6] = 31 K_session[7] = D0
K_session[8] = 78 K_session[9] = 0D K_session[10] = 4C K_session[11] = 53
K_session[12] = E0 K_session[13] = 15 K_session[14] = 3A K_session[15] = 63

BD_ADDR_C[0] = 2C BD_ADDR_C[1] = 7F BD_ADDR_C[2] = 94

BD_ADDR_C[3] = 56 BD_ADDR_C[4] = 0F BD_ADDR_C[5] = 1B

CL[0] = 5F CL[1] = 1A CL[2] = 00 CL[3] = 02

The corresponding values of CLK are 0x400_34BE and 0xC00_34BE.

===============================================================================================
Fill LFSRs with initial data
===============================================================================================

t clk# LFSR1 LFSR2 LFSR3 LFSR4 X1 X2 X3 X4 Z C[t+1] C[t] C[t-1]

0 0 0000000* 00000000* 000000000* 0000000000* 0 0 0 0 0 00 00 00

1 1 0000000* 00000001* 000000001* 0000000001* 0 0 0 0 0 00 00 00
2 2 0000001* 00000002* 000000002* 0000000003* 0 0 0 0 0 00 00 00
3 3 0000002* 00000004* 000000004* 0000000007* 0 0 0 0 0 00 00 00
4 4 0000004* 00000009* 000000008* 000000000F* 0 0 0 0 0 00 00 00
5 5 0000008* 00000013* 000000010* 000000001E* 0 0 0 0 0 00 00 00
6 6 0000010* 00000027* 000000021* 000000003D* 0 0 0 0 0 00 00 00
7 7 0000021* 0000004F* 000000043* 000000007A* 0 0 0 0 0 00 00 00
8 8 0000042* 0000009F* 000000087* 00000000F4* 0 0 0 0 0 00 00 00
9 9 0000084* 0000013F* 00000010F* 00000001E9* 0 0 0 0 0 00 00 00
10 10 0000108* 0000027F* 00000021F* 00000003D2* 0 0 0 0 0 00 00 00
11 11 0000211* 000004FE* 00000043E* 00000007A5* 0 0 0 0 0 00 00 00
12 12 0000422* 000009FC* 00000087C* 0000000F4A* 0 0 0 0 0 00 00 00
13 13 0000845* 000013F8* 0000010F8* 0000001E94* 0 0 0 0 0 00 00 00
14 14 000108B* 000027F0* 0000021F1* 0000003D29* 0 0 0 0 0 00 00 00
15 15 0002117* 00004FE1* 0000043E3* 0000007A52* 0 0 0 0 0 00 00 00
16 16 000422E* 00009FC2* 0000087C6* 000000F4A4* 0 0 0 0 0 00 00 00
17 17 000845D* 00013F84* 000010F8C* 000001E948* 0 0 0 0 0 00 00 00
18 18 00108BA* 00027F08* 000021F18* 000003D290* 0 0 0 0 0 00 00 00
19 19 0021174* 0004FE10* 000043E30* 000007A520* 0 0 0 0 0 00 00 00
20 20 00422E8* 0009FC21* 000087C61* 00000F4A41* 0 0 0 0 0 00 00 00

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 2, Part G Page 891
Sample Data

21 21 00845D1* 0013F842* 00010F8C3* 00001E9482* 0 0 0 0 0 00 00 00

22 22 0108BA3* 0027F084* 00021F186* 00003D2905* 0 0 0 0 0 00 00 00
23 23 0211747* 004FE109* 00043E30C* 00007A520B* 0 0 0 0 0 00 00 00
24 24 0422E8F* 009FC213* 00087C619* 0000F4A417* 0 1 0 0 1 00 00 00
25 25 0845D1E* 013F8426* 0010F8C32* 0001E9482F* 1 0 0 0 1 00 00 00
26 26 108BA3D 027F084D* 0021F1864* 0003D2905E* 0 0 0 0 0 00 00 00
27 27 011747B 04FE109B* 0043E30C9* 0007A520BC* 0 1 0 0 1 00 00 00
28 28 022E8F6 09FC2136* 0087C6192* 000F4A4179* 0 1 0 0 1 00 00 00
29 29 045D1EC 13F8426C* 010F8C325* 001E9482F2* 0 1 0 0 1 00 00 00
30 30 08BA3D9 27F084D8* 021F1864B* 003D2905E5* 1 1 0 0 0 01 00 00
31 31 11747B3 4FE109B0* 043E30C97* 007A520BCA* 0 1 0 0 1 00 00 00
32 32 02E8F67 1FC21360 087C6192E* 00F4A41795* 0 1 1 1 1 01 00 00
33 33 05D1ECF 3F8426C1 10F8C325C* 01E9482F2B* 0 1 0 1 0 01 00 00
34 34 0BA3D9F 7F084D82 01F1864B8 03D2905E56* 1 0 0 1 0 01 00 00
35 35 1747B3E 7E109B04 03E30C970 07A520BCAC* 0 0 0 1 1 00 00 00
36 36 0E8F67C 7C213608 07C6192E1 0F4A417958* 1 0 0 0 1 00 00 00
37 37 1D1ECF8 78426C11 0F8C325C3 1E9482F2B1* 1 0 1 1 1 01 00 00
38 38 1A3D9F0 7084D822 1F1864B86 3D2905E563* 1 1 1 0 1 01 00 00
39 39 147B3E1 6109B044 1E30C970C 7A520BCAC6* 0 0 1 0 1 00 00 00
===============================================================================================
Start clocking Summation Combiner
===============================================================================================
40 1 08F67C2 42136088 1C6192E18 74A417958D 1 0 1 1 1 01 00 00
41 2 11ECF84 0426C111 18C325C30 69482F2B1B 0 0 1 0 0 00 01 00
42 3 03D9F08 084D8222 11864B861 52905E5637 0 0 0 1 1 11 00 01
43 4 07B3E10 109B0444 030C970C3 2520BCAC6E 0 1 0 0 0 01 11 00
44 5 0F67C21 21360889 06192E186 4A417958DC 1 0 0 0 0 10 01 11
45 6 1ECF843 426C1112 0C325C30C 1482F2B1B8 1 0 1 1 1 11 10 01
46 7 1D9F086 04D82225 1864B8619 2905E56370 1 1 1 0 0 01 11 10
47 8 1B3E10D 09B0444B 10C970C32 520BCAC6E1 1 1 0 0 1 10 01 11
48 9 167C21B 13608897 0192E1865 2417958DC3 0 0 0 0 0 00 10 01
49 10 0CF8436 26C1112F 0325C30CB 482F2B1B87 1 1 0 0 0 00 00 10
50 11 19F086D 4D82225E 064B86197 105E56370F 1 1 0 0 0 01 00 00
51 12 13E10DB 1B0444BC 0C970C32F 20BCAC6E1F 0 0 1 1 1 00 01 00
52 13 07C21B7 36088979 192E1865E 417958DC3F 0 0 1 0 1 11 00 01
53 14 0F8436E 6C1112F2 125C30CBD 02F2B1B87F 1 0 0 1 1 01 11 00
54 15 1F086DD 582225E4 04B86197B 05E56370FF 1 0 0 1 1 10 01 11
55 16 1E10DBA 30444BC9 0970C32F7 0BCAC6E1FF 1 0 1 1 1 11 10 01
56 17 1C21B75 60889793 12E1865EE 17958DC3FF 1 1 0 1 0 01 11 10
57 18 18436EA 41112F27 05C30CBDD 2F2B1B87FF 1 0 0 0 0 10 01 11
58 19 1086DD4 02225E4E 0B86197BA 5E56370FFF 0 0 1 0 1 00 10 01
59 20 010DBA8 0444BC9D 170C32F74 3CAC6E1FFF 0 0 0 1 1 01 00 10
60 21 021B750 0889793A 0E1865EE8 7958DC3FFF 0 1 1 0 1 00 01 00

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 2, Part G Page 892
Sample Data

61 22 0436EA0 1112F274 1C30CBDD0 72B1B87FFE 0 0 1 1 0 10 00 01

62 23 086DD40 2225E4E9 186197BA1 656370FFFC 1 0 1 0 0 00 10 00
63 24 10DBA81 444BC9D3 10C32F743 4AC6E1FFF8 0 0 0 1 1 01 00 10
64 25 01B7502 089793A7 01865EE86 158DC3FFF1 0 1 0 1 1 00 01 00
65 26 036EA05 112F274E 030CBDD0D 2B1B87FFE3 0 0 0 0 0 11 00 01
66 27 06DD40B 225E4E9C 06197BA1A 56370FFFC6 0 0 0 0 1 10 11 00
67 28 0DBA817 44BC9D39 0C32F7434 2C6E1FFF8D 1 1 1 0 1 10 10 11
68 29 1B7502E 09793A72 1865EE868 58DC3FFF1B 1 0 1 1 1 01 10 10
69 30 16EA05D 12F274E5 10CBDD0D0 31B87FFE36 0 1 0 1 1 01 01 10
70 31 0DD40BA 25E4E9CB 0197BA1A1 6370FFFC6D 1 1 0 0 1 11 01 01
71 32 1BA8174 4BC9D397 032F74343 46E1FFF8DA 1 1 0 1 0 11 11 01
72 33 17502E8 1793A72F 065EE8687 0DC3FFF1B4 0 1 0 1 1 11 11 11
73 34 0EA05D0 2F274E5E 0CBDD0D0F 1B87FFE369 1 0 1 1 0 10 11 11
74 35 1D40BA0 5E4E9CBD 197BA1A1F 370FFFC6D2 1 0 1 0 0 10 10 11
75 36 1A81741 3C9D397B 12F74343F 6E1FFF8DA5 1 1 0 0 0 01 10 10
76 37 1502E82 793A72F6 05EE8687F 5C3FFF1B4B 0 0 0 0 1 00 01 10
77 38 0A05D05 7274E5ED 0BDD0D0FF 387FFE3696 1 0 1 0 0 10 00 01
78 39 140BA0B 64E9CBDA 17BA1A1FF 70FFFC6D2C 0 1 0 1 0 00 10 00
79 40 0817416 49D397B4 0F74343FE 61FFF8DA59 1 1 1 1 0 11 00 10
80 41 102E82C 13A72F69 1EE8687FD 43FFF1B4B3 0 1 1 1 0 00 11 00
81 42 005D058 274E5ED2 1DD0D0FFA 07FFE36966 0 0 1 1 0 11 00 11
82 43 00BA0B0 4E9CBDA5 1BA1A1FF5 0FFFC6D2CD 0 1 1 1 0 00 11 00
83 44 0174160 1D397B4A 174343FEA 1FFF8DA59B 0 0 0 1 1 10 00 11
84 45 02E82C0 3A72F695 0E8687FD4 3FFF1B4B37 0 0 1 1 0 00 10 00
85 46 05D0580 74E5ED2B 1D0D0FFA9 7FFE36966E 0 1 1 1 1 00 00 10
86 47 0BA0B00 69CBDA56 1A1A1FF53 7FFC6D2CDC 1 1 1 1 0 10 00 00
87 48 1741600 5397B4AC 14343FEA6 7FF8DA59B8 0 1 0 1 0 00 10 00
88 49 0E82C01 272F6959 08687FD4D 7FF1B4B370 1 0 1 1 1 00 00 10
89 50 1D05802 4E5ED2B3 10D0FFA9A 7FE36966E0 1 0 0 1 0 01 00 00
90 51 1A0B004 1CBDA566 01A1FF535 7FC6D2CDC0 1 1 0 1 0 11 01 00
91 52 1416009 397B4ACC 0343FEA6B 7F8DA59B80 0 0 0 1 0 10 11 01
92 53 082C013 72F69599 0687FD4D7 7F1B4B3701 1 1 0 0 0 10 10 11
93 54 1058026 65ED2B33 0D0FFA9AF 7E36966E03 0 1 1 0 0 01 10 10
94 55 00B004D 4BDA5667 1A1FF535E 7C6D2CDC06 0 1 1 0 1 01 01 10
95 56 016009B 17B4ACCE 143FEA6BD 78DA59B80D 0 1 0 1 1 11 01 01
96 57 02C0137 2F69599D 087FD4D7B 71B4B3701A 0 0 1 1 1 10 11 01
97 58 058026F 5ED2B33B 10FFA9AF6 636966E034 0 1 0 0 1 01 10 11
98 59 0B004DF 3DA56677 01FF535ED 46D2CDC068 1 1 0 1 0 10 01 10
99 60 16009BF 7B4ACCEF 03FEA6BDB 0DA59B80D0 0 0 0 1 1 00 10 01
100 61 0C0137F 769599DF 07FD4D7B7 1B4B3701A1 1 1 0 0 0 00 00 10
101 62 18026FE 6D2B33BE 0FFA9AF6E 36966E0342 1 0 1 1 1 01 00 00
102 63 1004DFC 5A56677D 1FF535EDD 6D2CDC0684 0 0 1 0 0 00 01 00
103 64 0009BF9 34ACCEFB 1FEA6BDBB 5A59B80D09 0 1 1 0 0 10 00 01

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 2, Part G Page 893
Sample Data

104 65 00137F2 69599DF7 1FD4D7B76 34B3701A12 0 0 1 1 0 00 10 00

105 66 0026FE5 52B33BEF 1FA9AF6EC 6966E03424 0 1 1 0 0 00 00 10
106 67 004DFCA 256677DF 1F535EDD8 52CDC06848 0 0 1 1 0 01 00 00
107 68 009BF94 4ACCEFBE 1EA6BDBB0 259B80D091 0 1 1 1 0 11 01 00
108 69 0137F29 1599DF7C 1D4D7B760 4B3701A123 0 1 1 0 1 10 11 01
109 70 026FE53 2B33BEF9 1A9AF6EC0 166E034246 0 0 1 0 1 01 10 11
110 71 04DFCA7 56677DF2 1535EDD81 2CDC06848D 0 0 0 1 0 01 01 10
111 72 09BF94F 2CCEFBE4 0A6BDBB03 59B80D091B 1 1 1 1 1 00 01 01
112 73 137F29E 599DF7C9 14D7B7607 33701A1236 0 1 0 0 1 11 00 01
113 74 06FE53C 333BEF93 09AF6EC0E 66E034246C 0 0 1 1 1 01 11 00
114 75 0DFCA79 6677DF26 135EDD81D 4DC06848D8 1 0 0 1 1 10 01 11
115 76 1BF94F2 4CEFBE4D 06BDBB03B 1B80D091B1 1 1 0 1 1 11 10 01
116 77 17F29E5 19DF7C9A 0D7B76077 3701A12363 0 1 1 0 1 00 11 10
117 78 0FE53CA 33BEF934 1AF6EC0EF 6E034246C6 1 1 1 0 1 11 00 11
118 79 1FCA794 677DF269 15EDD81DF 5C06848D8C 1 0 0 0 0 01 11 00
119 80 1F94F29 4EFBE4D2 0BDBB03BE 380D091B19 1 1 1 0 0 01 01 11
120 81 1F29E53 1DF7C9A5 17B76077D 701A123633 1 1 0 0 1 11 01 01
121 82 1E53CA6 3BEF934B 0F6EC0EFB 6034246C66 1 1 1 0 0 11 11 01
122 83 1CA794D 77DF2696 1EDD81DF6 406848D8CD 1 1 1 0 0 10 11 11
123 84 194F29B 6FBE4D2C 1DBB03BED 00D091B19B 1 1 1 1 0 11 10 11
124 85 129E536 5F7C9A59 1B76077DA 01A1236337 0 0 1 1 1 00 11 10
125 86 053CA6C 3EF934B3 16EC0EFB4 034246C66E 0 1 0 0 1 10 00 11
126 87 0A794D9 7DF26967 0DD81DF69 06848D8CDD 1 1 1 1 0 01 10 00
127 88 14F29B3 7BE4D2CF 1BB03BED3 0D091B19BB 0 1 1 0 1 01 01 10
128 89 09E5366 77C9A59F 176077DA6 1A12363377 1 1 0 0 1 11 01 01
129 90 13CA6CD 6F934B3F 0EC0EFB4D 34246C66EF 0 1 1 0 1 10 11 01
130 91 0794D9B 5F26967F 1D81DF69A 6848D8CDDF 0 0 1 0 1 01 10 11
131 92 0F29B37 3E4D2CFE 1B03BED35 5091B19BBE 1 0 1 1 0 10 01 10
132 93 1E5366F 7C9A59FD 16077DA6B 212363377C 1 1 0 0 0 11 10 01
133 94 1CA6CDF 7934B3FB 0C0EFB4D6 4246C66EF9 1 0 1 0 1 00 11 10
134 95 194D9BE 726967F6 181DF69AD 048D8CDDF2 1 0 1 1 1 11 00 11
135 96 129B37D 64D2CFED 103BED35B 091B19BBE5 0 1 0 0 0 01 11 00
136 97 05366FA 49A59FDA 0077DA6B7 12363377CA 0 1 0 0 0 10 01 11
137 98 0A6CDF5 134B3FB4 00EFB4D6E 246C66EF95 1 0 0 0 1 00 10 01
138 99 14D9BEA 26967F69 01DF69ADD 48D8CDDF2B 0 1 0 1 0 00 00 10
139 100 09B37D4 4D2CFED2 03BED35BB 11B19BBE56 1 0 0 1 0 01 00 00
140 101 1366FA8 1A59FDA5 077DA6B77 2363377CAC 0 0 0 0 1 01 01 00
141 102 06CDF51 34B3FB4A 0EFB4D6EF 46C66EF959 0 1 1 1 0 00 01 01
142 103 0D9BEA2 6967F695 1DF69ADDF 0D8CDDF2B2 1 0 1 1 1 10 00 01
143 104 1B37D45 52CFED2A 1BED35BBF 1B19BBE564 1 1 1 0 1 00 10 00
144 105 166FA8A 259FDA54 17DA6B77E 363377CAC8 0 1 0 0 1 01 00 10
145 106 0CDF515 4B3FB4A9 0FB4D6EFC 6C66EF9591 1 0 1 0 1 00 01 00
146 107 19BEA2B 167F6952 1F69ADDF8 58CDDF2B22 1 0 1 1 1 10 00 01

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 2, Part G Page 894
Sample Data

147 108 137D457 2CFED2A5 1ED35BBF1 319BBE5645 0 1 1 1 1 00 10 00

148 109 06FA8AF 59FDA54A 1DA6B77E2 63377CAC8B 0 1 1 0 0 00 00 10
149 110 0DF515F 33FB4A95 1B4D6EFC4 466EF95916 1 1 1 0 1 01 00 00
150 111 1BEA2BF 67F6952A 169ADDF88 0CDDF2B22C 1 1 0 1 0 11 01 00
151 112 17D457F 4FED2A55 0D35BBF10 19BBE56459 0 1 1 1 0 11 11 01
152 113 0FA8AFE 1FDA54AB 1A6B77E20 3377CAC8B3 1 1 1 0 0 10 11 11
153 114 1F515FD 3FB4A957 14D6EFC40 66EF959166 1 1 0 1 1 10 10 11
154 115 1EA2BFA 7F6952AF 09ADDF880 4DDF2B22CC 1 0 1 1 1 01 10 10
155 116 1D457F4 7ED2A55F 135BBF100 1BBE564598 1 1 0 1 0 10 01 10
156 117 1A8AFE8 7DA54ABF 06B77E200 377CAC8B31 1 1 0 0 0 11 10 01
157 118 1515FD0 7B4A957F 0D6EFC401 6EF9591663 0 0 1 1 1 00 11 10
158 119 0A2BFA1 76952AFE 1ADDF8803 5DF2B22CC7 1 1 1 1 0 00 00 11
159 120 1457F42 6D2A55FD 15BBF1007 3BE564598E 0 0 0 1 1 00 00 00
160 121 08AFE84 5A54ABFB 0B77E200F 77CAC8B31C 1 0 1 1 1 01 00 00
161 122 115FD09 34A957F7 16EFC401F 6F95916639 0 1 0 1 1 00 01 00
162 123 02BFA12 6952AFEF 0DDF8803E 5F2B22CC73 0 0 1 0 1 11 00 01
163 124 057F424 52A55FDF 1BBF1007D 3E564598E7 0 1 1 0 1 01 11 00
164 125 0AFE848 254ABFBF 177E200FA 7CAC8B31CF 1 0 0 1 1 10 01 11
165 126 15FD090 4A957F7E 0EFC401F5 795916639E 0 1 1 0 0 11 10 01
166 127 0BFA121 152AFEFD 1DF8803EA 72B22CC73C 1 0 1 1 0 01 11 10
167 128 17F4243 2A55FDFA 1BF1007D4 6564598E78 0 0 1 0 0 10 01 11
168 129 0FE8486 54ABFBF4 17E200FA8 4AC8B31CF0 1 1 0 1 1 11 10 01
169 130 1FD090C 2957F7E8 0FC401F51 15916639E1 1 0 1 1 0 01 11 10
170 131 1FA1219 52AFEFD1 1F8803EA3 2B22CC73C2 1 1 1 0 0 01 01 11
171 132 1F42432 255FDFA2 1F1007D47 564598E785 1 0 1 0 1 11 01 01
172 133 1E84865 4ABFBF44 1E200FA8F 2C8B31CF0B 1 1 1 1 1 11 11 01
173 134 1D090CB 157F7E88 1C401F51E 5916639E17 1 0 1 0 1 11 11 11
174 135 1A12196 2AFEFD11 18803EA3C 322CC73C2E 1 1 1 0 0 10 11 11
175 136 142432C 55FDFA23 11007D479 64598E785C 0 1 0 0 1 01 10 11
176 137 0848659 2BFBF446 0200FA8F2 48B31CF0B9 1 1 0 1 0 10 01 10
177 138 1090CB2 57F7E88C 0401F51E4 116639E173 0 1 0 0 1 00 10 01
178 139 0121964 2FEFD118 0803EA3C8 22CC73C2E6 0 1 1 1 1 00 00 10
179 140 02432C9 5FDFA230 1007D4791 4598E785CD 0 1 0 1 0 01 00 00
180 141 0486593 3FBF4461 000FA8F23 0B31CF0B9B 0 1 0 0 0 00 01 00
181 142 090CB26 7F7E88C3 001F51E47 16639E1736 1 0 0 0 1 11 00 01
182 143 121964D 7EFD1187 003EA3C8F 2CC73C2E6C 0 1 0 1 1 01 11 00
183 144 0432C9B 7DFA230E 007D4791E 598E785CD8 0 1 0 1 1 10 01 11
184 145 0865936 7BF4461C 00FA8F23C 331CF0B9B0 1 1 0 0 0 11 10 01
185 146 10CB26D 77E88C38 01F51E479 6639E17361 0 1 0 0 0 00 11 10
186 147 01964DA 6FD11870 03EA3C8F2 4C73C2E6C2 0 1 0 0 1 10 00 11
187 148 032C9B4 5FA230E1 07D4791E4 18E785CD84 0 1 0 1 0 00 10 00
188 149 0659368 3F4461C2 0FA8F23C9 31CF0B9B09 0 0 1 1 0 00 00 10
189 150 0CB26D0 7E88C384 1F51E4793 639E173612 1 1 1 1 0 10 00 00

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 2, Part G Page 895
Sample Data

190 151 1964DA0 7D118709 1EA3C8F27 473C2E6C24 1 0 1 0 0 00 10 00

191 152 12C9B41 7A230E12 1D4791E4E 0E785CD848 0 0 1 0 1 01 00 10
192 153 0593683 74461C24 1A8F23C9C 1CF0B9B091 0 0 1 1 1 00 01 00
193 154 0B26D06 688C3848 151E47938 39E1736123 1 1 0 1 1 10 00 01
194 155 164DA0D 51187091 0A3C8F271 73C2E6C247 0 0 1 1 0 00 10 00
195 156 0C9B41A 2230E123 14791E4E3 6785CD848F 1 0 0 1 0 00 00 10
196 157 1936835 4461C247 08F23C9C6 4F0B9B091E 1 0 1 0 0 01 00 00
197 158 126D06A 08C3848E 11E47938D 1E1736123C 0 1 0 0 0 00 01 00
198 159 04DA0D5 1187091C 03C8F271B 3C2E6C2478 0 1 0 0 1 11 00 01
199 160 09B41AA 230E1238 0791E4E37 785CD848F1 1 0 0 0 0 01 11 00
200 161 1368354 461C2470 0F23C9C6F 70B9B091E3 0 0 1 1 1 10 01 11
201 162 06D06A9 0C3848E1 1E47938DF 61736123C6 0 0 1 0 1 00 10 01
202 163 0DA0D52 187091C3 1C8F271BE 42E6C2478D 1 0 1 1 1 00 00 10
203 164 1B41AA4 30E12387 191E4E37C 05CD848F1A 1 1 1 1 0 10 00 00
204 165 1683549 61C2470F 123C9C6F9 0B9B091E34 0 1 0 1 0 00 10 00
205 166 0D06A92 43848E1E 047938DF3 1736123C68 1 1 0 0 0 00 00 10
206 167 1A0D524 07091C3C 08F271BE7 2E6C2478D1 1 0 1 0 0 01 00 00
207 168 141AA49 0E123879 11E4E37CF 5CD848F1A2 0 0 0 1 0 00 01 00
208 169 0835492 1C2470F3 03C9C6F9F 39B091E345 1 0 0 1 0 10 00 01
209 170 106A925 3848E1E6 07938DF3F 736123C68B 0 0 0 0 0 11 10 00
210 171 00D524A 7091C3CD 0F271BE7E 66C2478D16 0 1 1 1 0 01 11 10
211 172 01AA495 6123879B 1E4E37CFD 4D848F1A2D 0 0 1 1 1 10 01 11
212 173 035492A 42470F36 1C9C6F9FB 1B091E345B 0 0 1 0 1 00 10 01
213 174 06A9255 048E1E6C 1938DF3F6 36123C68B7 0 1 1 0 0 00 00 10
214 175 0D524AB 091C3CD8 1271BE7EC 6C2478D16E 1 0 0 0 1 00 00 00
215 176 1AA4957 123879B1 04E37CFD8 5848F1A2DD 1 0 0 0 1 00 00 00
216 177 15492AF 2470F363 09C6F9FB0 3091E345BA 0 0 1 1 0 01 00 00
217 178 0A9255E 48E1E6C7 138DF3F61 6123C68B75 1 1 0 0 1 00 01 00
218 179 1524ABD 11C3CD8F 071BE7EC3 42478D16EB 0 1 0 0 1 11 00 01
219 180 0A4957B 23879B1F 0E37CFD87 048F1A2DD6 1 1 1 1 1 00 11 00
220 181 1492AF6 470F363F 1C6F9FB0E 091E345BAD 0 0 1 0 1 10 00 11
221 182 09255EC 0E1E6C7F 18DF3F61D 123C68B75B 1 0 1 0 0 00 10 00
222 183 124ABD9 1C3CD8FF 11BE7EC3A 2478D16EB6 0 0 0 0 0 01 00 10
223 184 04957B3 3879B1FE 037CFD874 48F1A2DD6D 0 0 0 1 0 00 01 00
224 185 092AF66 70F363FD 06F9FB0E9 11E345BADB 1 1 0 1 1 10 00 01
225 186 1255ECD 61E6C7FA 0DF3F61D3 23C68B75B7 0 1 1 1 1 00 10 00
226 187 04ABD9B 43CD8FF5 1BE7EC3A7 478D16EB6E 0 1 1 1 1 00 00 10
227 188 0957B37 079B1FEA 17CFD874E 0F1A2DD6DD 1 1 0 0 0 01 00 00
228 189 12AF66F 0F363FD4 0F9FB0E9C 1E345BADBB 0 0 1 0 0 00 01 00
229 190 055ECDE 1E6C7FA9 1F3F61D39 3C68B75B76 0 0 1 0 1 11 00 01
230 191 0ABD9BC 3CD8FF53 1E7EC3A73 78D16EB6EC 1 1 1 1 1 00 11 00
231 192 157B379 79B1FEA7 1CFD874E6 71A2DD6DD9 0 1 1 1 1 11 00 11
232 193 0AF66F3 7363FD4E 19FB0E9CD 6345BADBB2 1 0 1 0 1 01 11 00

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 2, Part G Page 896
Sample Data

233 194 15ECDE6 66C7FA9D 13F61D39A 468B75B765 0 1 0 1 1 10 01 11

234 195 0BD9BCC 4D8FF53A 07EC3A735 0D16EB6ECA 1 1 0 0 0 11 10 01
235 196 17B3799 1B1FEA75 0FD874E6A 1A2DD6DD94 0 0 1 0 0 00 11 10
236 197 0F66F33 363FD4EA 1FB0E9CD5 345BADBB28 1 0 1 0 0 11 00 11
237 198 1ECDE67 6C7FA9D5 1F61D39AA 68B75B7650 1 0 1 1 0 00 11 00
238 199 1D9BCCF 58FF53AB 1EC3A7354 516EB6ECA0 1 1 1 0 1 11 00 11
239 200 1B3799E 31FEA756 1D874E6A8 22DD6DD940 1 1 1 1 1 00 11 00

Z[0] = 3F
Z[1] = B1
Z[2] = 67
Z[3] = D2
Z[4] = 2F
Z[5] = A6
Z[6] = 1F
Z[7] = B9
Z[8] = E6
Z[9] = 84
Z[10] = 43
Z[11] = 07
Z[12] = D8
Z[13] = 1E
Z[14] = E7
Z[15] = C3

===============================================================================================
Reload this pattern into the LFSRs
Hold content of Summation Combiner regs and calculate new C[t+1] and Z values
===============================================================================================
LFSR1 <= 0E62F3F
LFSR2 <= 6C84A6B1
LFSR3 <= 11E431F67
LFSR4 <= 61E707B9D2
C[t+1] <= 00

===============================================================================================
Generating 125 key symbols (encryption/decryption sequence)
===============================================================================================
240 1 0E62F3F 6C84A6B1 11E431F67 61E707B9D2 1 1 0 1 0 00 11 00
241 2 1CC5E7F 59094D63 03C863ECE 43CE0F73A5 1 0 0 1 0 11 00 11
242 3 198BCFF 32129AC6 0790C7D9D 079C1EE74A 1 0 0 1 1 01 11 00
243 4 13179FE 6425358C 0F218FB3A 0F383DCE94 0 0 1 0 0 10 01 11
244 5 062F3FD 484A6B19 1E431F675 1E707B9D28 0 0 1 0 1 00 10 01

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 2, Part G Page 897
Sample Data

245 6 0C5E7FB 1094D632 1C863ECEB 3CE0F73A50 1 1 1 1 0 11 00 10

246 7 18BCFF7 2129AC64 190C7D9D7 79C1EE74A1 1 0 1 1 0 00 11 00
247 8 1179FEE 425358C8 1218FB3AE 7383DCE942 0 0 0 1 1 10 00 11
248 9 02F3FDD 04A6B190 0431F675D 6707B9D285 0 1 0 0 1 11 10 00
249 10 05E7FBB 094D6320 0863ECEBB 4E0F73A50B 0 0 1 0 0 00 11 10
250 11 0BCFF77 129AC640 10C7D9D77 1C1EE74A16 1 1 0 0 0 11 00 11
251 12 179FEEE 25358C80 018FB3AEE 383DCE942C 0 0 0 0 1 10 11 00
252 13 0F3FDDC 4A6B1900 031F675DD 707B9D2859 1 0 0 0 1 01 10 11
253 14 1E7FBB8 14D63200 063ECEBBA 60F73A50B3 1 1 0 1 0 10 01 10
254 15 1CFF771 29AC6401 0C7D9D774 41EE74A167 1 1 1 1 0 10 10 01
255 16 19FEEE2 5358C803 18FB3AEE9 03DCE942CE 1 0 1 1 1 01 10 10
256 17 13FDDC4 26B19007 11F675DD2 07B9D2859C 0 1 0 1 1 01 01 10
257 18 07FBB88 4D63200E 03ECEBBA4 0F73A50B38 0 0 0 0 1 10 01 01
258 19 0FF7711 1AC6401D 07D9D7748 1EE74A1670 1 1 0 1 1 11 10 01
259 20 1FEEE23 358C803B 0FB3AEE91 3DCE942CE1 1 1 1 1 1 01 11 10
260 21 1FDDC47 6B190076 1F675DD23 7B9D2859C2 1 0 1 1 0 01 01 11
261 22 1FBB88F 563200ED 1ECEBBA47 773A50B385 1 0 1 0 1 11 01 01
262 23 1F7711E 2C6401DB 1D9D7748F 6E74A1670A 1 0 1 0 1 10 11 01
263 24 1EEE23D 58C803B6 1B3AEE91E 5CE942CE15 1 1 1 1 0 11 10 11
264 25 1DDC47A 3190076C 1675DD23D 39D2859C2B 1 1 0 1 0 01 11 10
265 26 1BB88F4 63200ED9 0CEBBA47A 73A50B3856 1 0 1 1 0 01 01 11
266 27 17711E8 46401DB2 19D7748F5 674A1670AD 0 0 1 0 0 11 01 01
267 28 0EE23D0 0C803B64 13AEE91EA 4E942CE15B 1 1 0 1 0 11 11 01
268 29 1DC47A0 190076C8 075DD23D4 1D2859C2B7 1 0 0 0 0 11 11 11
269 30 1B88F41 3200ED90 0EBBA47A9 3A50B3856E 1 0 1 0 1 11 11 11
270 31 1711E83 6401DB20 1D7748F53 74A1670ADC 0 0 1 1 1 11 11 11
271 32 0E23D07 4803B641 1AEE91EA7 6942CE15B8 1 0 1 0 1 11 11 11
272 33 1C47A0F 10076C82 15DD23D4F 52859C2B71 1 0 0 1 1 11 11 11
273 34 188F41E 200ED905 0BBA47A9E 250B3856E3 1 0 1 0 1 11 11 11
274 35 111E83C 401DB20A 17748F53D 4A1670ADC7 0 0 0 0 1 00 11 11
275 36 023D078 003B6414 0EE91EA7A 142CE15B8E 0 0 1 0 1 10 00 11
276 37 047A0F0 0076C828 1DD23D4F5 2859C2B71C 0 0 1 0 1 11 10 00
277 38 08F41E1 00ED9050 1BA47A9EA 50B3856E39 1 1 1 1 1 01 11 10
278 39 11E83C2 01DB20A0 1748F53D5 21670ADC72 0 1 0 0 0 10 01 11
279 40 03D0785 03B64141 0E91EA7AA 42CE15B8E4 0 1 1 1 1 11 10 01
280 41 07A0F0A 076C8283 1D23D4F54 059C2B71C8 0 0 1 1 1 00 11 10
281 42 0F41E14 0ED90507 1A47A9EA9 0B3856E390 1 1 1 0 1 11 00 11
282 43 1E83C29 1DB20A0F 148F53D52 1670ADC720 1 1 0 0 1 01 11 00
283 44 1D07853 3B64141E 091EA7AA5 2CE15B8E40 1 0 1 1 0 01 01 11
284 45 1A0F0A6 76C8283C 123D4F54B 59C2B71C81 1 1 0 1 0 00 01 01
285 46 141E14C 6D905079 047A9EA97 33856E3902 0 1 0 1 0 10 00 01
286 47 083C299 5B20A0F2 08F53D52F 670ADC7204 1 0 1 0 0 00 10 00
287 48 1078533 364141E4 11EA7AA5E 4E15B8E408 0 0 0 0 0 01 00 10

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 2, Part G Page 898
Sample Data

288 49 00F0A67 6C8283C8 03D4F54BC 1C2B71C811 0 1 0 0 0 00 01 00

289 50 01E14CE 59050791 07A9EA978 3856E39022 0 0 0 0 0 11 00 01
290 51 03C299C 320A0F23 0F53D52F1 70ADC72045 0 0 1 1 1 01 11 00
291 52 0785339 64141E47 1EA7AA5E2 615B8E408A 0 0 1 0 0 10 01 11
292 53 0F0A673 48283C8E 1D4F54BC4 42B71C8115 1 0 1 1 1 11 10 01
293 54 1E14CE6 1050791C 1A9EA9788 056E39022B 1 0 1 0 1 00 11 10
294 55 1C299CD 20A0F239 153D52F10 0ADC720456 1 1 0 1 1 11 00 11
295 56 185339B 4141E472 0A7AA5E20 15B8E408AC 1 0 1 1 0 00 11 00
296 57 10A6736 0283C8E4 14F54BC41 2B71C81158 0 1 0 0 1 10 00 11
297 58 014CE6C 050791C9 09EA97882 56E39022B0 0 0 1 1 0 00 10 00
298 59 0299CD9 0A0F2393 13D52F104 2DC7204561 0 0 0 1 1 01 00 10
299 60 05339B3 141E4726 07AA5E208 5B8E408AC3 0 0 0 1 0 00 01 00
300 61 0A67366 283C8E4C 0F54BC411 371C811587 1 0 1 0 0 10 00 01
301 62 14CE6CC 50791C98 1EA978822 6E39022B0F 0 0 1 0 1 11 10 00
302 63 099CD99 20F23930 1D52F1045 5C7204561E 1 1 1 0 0 01 11 10
303 64 1339B33 41E47260 1AA5E208B 38E408AC3D 0 1 1 1 0 01 01 11
304 65 0673666 03C8E4C0 154BC4117 71C811587A 0 1 0 1 1 11 01 01
305 66 0CE6CCC 0791C980 0A978822E 639022B0F5 1 1 1 1 1 11 11 01
306 67 19CD999 0F239301 152F1045C 47204561EB 1 0 0 0 0 11 11 11
307 68 139B332 1E472603 0A5E208B9 0E408AC3D6 0 0 1 0 0 11 11 11
308 69 0736664 3C8E4C06 14BC41172 1C811587AD 0 1 0 1 1 11 11 11
309 70 0E6CCC8 791C980C 0978822E5 39022B0F5A 1 0 1 0 1 11 11 11
310 71 1CD9990 72393019 12F1045CB 7204561EB4 1 0 0 0 0 11 11 11
311 72 19B3320 64726033 05E208B97 6408AC3D69 1 0 0 0 0 11 11 11
312 73 1366640 48E4C067 0BC41172F 4811587AD3 0 1 1 0 1 11 11 11
313 74 06CCC81 11C980CF 178822E5E 1022B0F5A6 0 1 0 0 0 11 11 11
314 75 0D99903 2393019E 0F1045CBC 204561EB4C 1 1 1 0 0 10 11 11
315 76 1B33206 4726033D 1E208B979 408AC3D699 1 0 1 1 1 10 10 11
316 77 166640D 0E4C067B 1C41172F2 011587AD33 0 0 1 0 1 10 10 10
317 78 0CCC81B 1C980CF6 18822E5E5 022B0F5A66 1 1 1 0 1 01 10 10
318 79 1999036 393019EC 11045CBCA 04561EB4CD 1 0 0 0 0 01 01 10
319 80 133206C 726033D9 0208B9794 08AC3D699B 0 0 0 1 0 11 01 01
320 81 06640D9 64C067B3 041172F29 11587AD337 0 1 0 0 0 10 11 01
321 82 0CC81B3 4980CF66 0822E5E53 22B0F5A66F 1 1 1 1 0 11 10 11
322 83 1990366 13019ECC 1045CBCA6 4561EB4CDF 1 0 0 0 0 00 11 10
323 84 13206CC 26033D98 008B9794D 0AC3D699BE 0 0 0 1 1 10 00 11
324 85 0640D98 4C067B31 01172F29B 1587AD337C 0 0 0 1 1 11 10 00
325 86 0C81B30 180CF662 022E5E537 2B0F5A66F9 1 0 0 0 0 00 11 10
326 87 1903660 3019ECC5 045CBCA6F 561EB4CDF3 1 0 0 0 1 10 00 11
327 88 1206CC1 6033D98A 08B9794DE 2C3D699BE6 0 0 1 0 1 11 10 00
328 89 040D983 4067B315 1172F29BD 587AD337CC 0 0 0 0 1 11 11 10
329 90 081B306 00CF662A 02E5E537A 30F5A66F98 1 1 0 1 0 10 11 11
330 91 103660C 019ECC55 05CBCA6F4 61EB4CDF31 0 1 0 1 0 10 10 11

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 2, Part G Page 899
Sample Data

331 92 006CC19 033D98AB 0B9794DE8 43D699BE62 0 0 1 1 0 01 10 10

332 93 00D9833 067B3156 172F29BD0 07AD337CC5 0 0 0 1 0 01 01 10
333 94 01B3066 0CF662AC 0E5E537A0 0F5A66F98B 0 1 1 0 1 11 01 01
334 95 03660CD 19ECC559 1CBCA6F41 1EB4CDF317 0 1 1 1 0 11 11 01
335 96 06CC19B 33D98AB2 19794DE83 3D699BE62F 0 1 1 0 1 11 11 11
336 97 0D98336 67B31565 12F29BD06 7AD337CC5F 1 1 0 1 0 10 11 11
337 98 1B3066D 4F662ACA 05E537A0C 75A66F98BF 1 0 0 1 0 10 10 11
338 99 1660CDB 1ECC5594 0BCA6F418 6B4CDF317E 0 1 1 0 0 01 10 10
339 100 0CC19B7 3D98AB29 1794DE831 5699BE62FC 1 1 0 1 0 10 01 10
340 101 198336F 7B315653 0F29BD062 2D337CC5F9 1 0 1 0 0 11 10 01
341 102 13066DE 7662ACA7 1E537A0C5 5A66F98BF2 0 0 1 0 0 00 11 10
342 103 060CDBC 6CC5594F 1CA6F418B 34CDF317E4 0 1 1 1 1 11 00 11
343 104 0C19B78 598AB29F 194DE8317 699BE62FC9 1 1 1 1 1 00 11 00
344 105 18336F1 3315653F 129BD062E 5337CC5F92 1 0 0 0 1 10 00 11
345 106 1066DE2 662ACA7E 0537A0C5C 266F98BF25 0 0 0 0 0 11 10 00
346 107 00CDBC5 4C5594FD 0A6F418B9 4CDF317E4B 0 0 1 1 1 00 11 10
347 108 019B78B 18AB29FA 14DE83172 19BE62FC96 0 1 0 1 0 11 00 11
348 109 0336F16 315653F4 09BD062E5 337CC5F92C 0 0 1 0 0 01 11 00
349 110 066DE2D 62ACA7E8 137A0C5CA 66F98BF258 0 1 0 1 1 10 01 11
350 111 0CDBC5B 45594FD1 06F418B95 4DF317E4B1 1 0 0 1 0 11 10 01
351 112 19B78B6 0AB29FA2 0DE83172B 1BE62FC962 1 1 1 1 1 01 11 10
352 113 136F16C 15653F45 1BD062E57 37CC5F92C5 0 0 1 1 1 10 01 11
353 114 06DE2D9 2ACA7E8B 17A0C5CAE 6F98BF258B 0 1 0 1 0 11 10 01
354 115 0DBC5B2 5594FD16 0F418B95D 5F317E4B16 1 1 1 0 0 01 11 10
355 116 1B78B64 2B29FA2C 1E83172BB 3E62FC962C 1 0 1 0 1 10 01 11
356 117 16F16C8 5653F458 1D062E577 7CC5F92C58 0 0 1 1 0 11 10 01
357 118 0DE2D91 2CA7E8B0 1A0C5CAEF 798BF258B1 1 1 1 1 1 01 11 10
358 119 1BC5B23 594FD161 1418B95DF 7317E4B163 1 0 0 0 0 10 01 11
359 120 178B647 329FA2C2 083172BBF 662FC962C7 0 1 1 0 0 11 10 01
360 121 0F16C8E 653F4584 1062E577F 4C5F92C58E 1 0 0 0 0 00 11 10
361 122 1E2D91C 4A7E8B09 00C5CAEFE 18BF258B1C 1 0 0 1 0 11 00 11
362 123 1C5B238 14FD1613 018B95DFC 317E4B1639 1 1 0 0 1 01 11 00
363 124 18B6471 29FA2C27 03172BBF9 62FC962C72 1 1 0 1 0 01 01 11
364 125 116C8E2 53F4584E 062E577F3 45F92C58E4 0 1 0 1 1 11 01 01

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 2, Part G Page 900
Sample Data

1.2 AES-CCM encryption sample data

All values below are hexadecimal and follow notation of AES-CCM: MSbyte to LSbyte &
msbit to lsbit.

1.2.1 Sample data 1 (DM1, Central → Peripheral)

Payload byte length: 00

K: 89678967 89678967 45234523 45234523
Payload counter: 0000bc614e
Zero-length ACL-U Continuation: 0
Direction: 0
Initialization vector: 66778899 aabbccdd
LT_ADDR: 1
Packet Type: 3
LLID: 2
Payload:

B0: 494e61bc 0000ddcc bbaa9988 77660000

B1: 00190200 00000000 00000000 00000000

Y0: bb01f0c5 16dfd7b5 0d0cccb8 eaebb347

Y1: a9adf6e6 7876cf95 118a09d5 ac3f216e

T: a9adf6e6

CTR0: 014e61bc 0000ddcc bbaa9988 77660000

S0: b90f2b23 f63717d3 38e0559d 1e7e785e

MIC: 10a2ddc5
Encrypted payload:

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 2, Part G Page 901
Sample Data

1.2.2 Sample data 2 (DM1, Central → Peripheral)

Payload byte length: 08

K: 89678967 89678967 45234523 45234523
Payload counter: 0000bc614e
Zero-length ACL-U Continuation: 0
Direction: 0
Initialization vector: 66778899 aabbccdd
LT_ADDR: 1
Packet Type: 3
LLID: 2
Payload: 68696a6b 6c6d6e6f

B0: 494e61bc 0000ddcc bbaa9988 77660008

B1: 00190200 00000000 00000000 00000000
B2: 68696a6b 6c6d6e6f 00000000 00000000

Y0: 95ddc3d4 2c9a70f1 61a28ee2 c08271ab

Y1: 418635ff 54615443 8aceca41 fe274779
Y2: 08d78b32 9d78ed33 b285fc42 e178d781

T: 08d78b32

CTR0: 014e61bc 0000ddcc bbaa9988 77660000

CTR1: 014e61bc 0000ddcc bbaa9988 77660001

S0: b90f2b23 f63717d3 38e0559d 1e7e785e

S1: d8c7e3e1 02050abb 025d0895 17cbe5fb

MIC: b1d8a011
Encrypted payload: b0ae898a 6e6864d4

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 2, Part G Page 902
Sample Data

1.2.3 Sample data 3 (DM1, Peripheral → Central)

Payload byte length: 08

K: 89678967 89678967 45234523 45234523
Payload counter: 0000bc614e
Zero-length ACL-U Continuation: 0
Direction: 1
Initialization vector: 66778899 aabbccdd
LT_ADDR: 1
Packet Type: 3
LLID: 2
Payload: 68696a6b 6c6d6e6f

B0: 494e61bc 0020ddcc bbaa9988 77660008

B1: 00190200 00000000 00000000 00000000
B2: 68696a6b 6c6d6e6f 00000000 00000000

Y0: 31081122 b1cca37a 5f04d238 897b9bc8

Y1: 02ee3065 95c5d55a d0a030a3 3bee507b
Y2: 7382a2ba aa874418 14eafbef 41f57180

T: 7382a2ba

CTR0: 014e61bc 0020ddcc bbaa9988 77660000

CTR1: 014e61bc 0020ddcc bbaa9988 77660001

S0: 2a4d408d 2035b058 cc2fbf3b 8de15c73

S1: 9c89f68f b31bf4b5 7fbc7e83 123bd8a8

MIC: 59cfe237
Encrypted payload: f4e09ce4 df769ada

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 2, Part G Page 903
Sample Data

1.2.4 Sample data 4 (DM1, Central → Peripheral)

Payload byte length: 11

K: ce2ad11b a11456bd bd9d8b1f 848322fc
Payload counter: 00bdb3be95
Zero-length ACL-U Continuation: 0
Direction: 0
Initialization vector: 82b8b727 5bf92769
LT_ADDR: 1
Packet Type: 3
LLID: 2
Payload: 86126da5 dbb39164 9ba1cac4 60917233
05

B0: 4995beb3 bd006927 f95b27b7 b8820011

B1: 00190200 00000000 00000000 00000000
B2: 86126da5 dbb39164 9ba1cac4 60917233
B3: 05000000 00000000 00000000 00000000

Y0: ab182b6f e8bca0a9 7cc306e0 eab19e84

Y1: c198f821 49061035 977a5aae 60c51726
Y2: 45dd4181 40facb43 0f73f71b 49ea36ae
Y3: 7b112114 38d06bc2 98cb22db c5218041

T: 7b112114

CTR0: 0195beb3 bd006927 f95b27b7 b8820000

CTR1: 0195beb3 bd006927 f95b27b7 b8820001
CTR2: 0195beb3 bd006927 f95b27b7 b8820002

S0: bd3d1368 1478c30c 62b734ac e8e00c6e

S1: bfaa326d 8d84d8f6 e4518d12 20babe4f
S2: fc4a6327 776a3136 604a1ab8 20836505

MIC: c62c327c
Encrypted payload: 39b85fc8 56374992 7ff047d6 402bcc7c
f9

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 2, Part G Page 904
Sample Data

1.2.5 Sample data 5 (DM1, Peripheral → Central)

Payload byte length: 11

K: ce2ad11b a11456bd bd9d8b1f 848322fc
Payload counter: 00bdb3be95
Zero-length ACL-U Continuation: 0
Direction: 1
Initialization vector: 82b8b727 5bf92769
LT_ADDR: 1
Packet Type: 3
LLID: 2
Payload: 86126da5 dbb39164 9ba1cac4 60917233
05

B0: 4995beb3 bd206927 f95b27b7 b8820011

B1: 00190200 00000000 00000000 00000000
B2: 86126da5 dbb39164 9ba1cac4 60917233
B3: 05000000 00000000 00000000 00000000

Y0: 2c317af0 b12026df 8400f84e aa8e53e7

Y1: 1ec2c0c5 74e2cad3 3e143b2b 9d63095d
Y2: e7f08f4b d7c24c04 651434d8 a84f8ae9
Y3: d6f08416 0d556004 6c9b850b 1b579614

T: d6f08416

CTR0: 0195beb3 bd206927 f95b27b7 b8820000

CTR1: 0195beb3 bd206927 f95b27b7 b8820001
CTR2: 0195beb3 bd206927 f95b27b7 b8820002

S0: d8bc791d b48ea182 ef438e70 ee0f50e1

S1: c5e90ff5 6e1e06b3 4d6b699c 9fb72e3d
S2: b68f4956 19bea370 0a1f118e a5dd6aff

MIC: 0e4cfd0b
Encrypted payload: 43fb6250 b5ad97d7 d6caa358 ff265c0e
b3

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 2, Part G Page 905
Sample Data

1.2.6 Sample data 6 (DH1, Central → Peripheral)

Payload byte length: 14

K: 7b04934f d9d25294 ef1a014d a094f0b5
Payload counter: 006267f78b
Zero-length ACL-U Continuation: 0
Direction: 0
Initialization vector: 74ca58e8 b136986f
LT_ADDR: 1
Packet Type: 4
LLID: 2
Payload: 9bb3a2bd dd043b3a 904cc247 0a1d545f
b2095e3d

B0: 498bf767 62006f98 36b1e858 ca740014

B1: 00210200 00000000 00000000 00000000
B2: 9bb3a2bd dd043b3a 904cc247 0a1d545f
B3: b2095e3d 00000000 00000000 00000000

Y0: ae691727 39e614a3 e0be3227 ac9afd99

Y1: 47b13424 8ff2f5f7 eaea4fdd 0fab9d92
Y2: 36154960 3c1fc026 4509902e de57dfc3
Y3: 1d45d8f7 950a39c3 9779bb7c d1b3fe17

T: 1d45d8f7

CTR0: 018bf767 62006f98 36b1e858 ca740000

CTR1: 018bf767 62006f98 36b1e858 ca740001
CTR2: 018bf767 62006f98 36b1e858 ca740002

S0: 254593c4 cd12c6a7 d9dec572 95524b75

S1: af492e65 ca391b26 e8ce9653 498ed0de
S2: 869271ed ac79c1bc 3cf0f959 c2711f3b

MIC: 38004b33
Encrypted payload: 34fa8cd8 173d201c 78825414 43938481
349b2fd0

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 2, Part G Page 906
Sample Data

1.2.7 Sample data 7 (DH1, Peripheral → Central)

Payload byte length: 14

K: 7b04934f d9d25294 ef1a014d a094f0b5
Payload counter: 006267f78b
Zero-length ACL-U Continuation: 0
Direction: 1
Initialization vector: 74ca58e8 b136986f
LT_ADDR: 1
Packet Type: 4
LLID: 2
Payload: 9bb3a2bd dd043b3a 904cc247 0a1d545f
b2095e3d

B0: 498bf767 62206f98 36b1e858 ca740014

B1: 00210200 00000000 00000000 00000000
B2: 9bb3a2bd dd043b3a 904cc247 0a1d545f
B3: b2095e3d 00000000 00000000 00000000

Y0: 55410490 6f3a5827 e5a04a60 7cf19ad5

Y1: 000cc95c c0d099ca b15b244b d3440c24
Y2: bd1d9815 96438c28 eebfd508 6cf80d34
Y3: 8c227888 d0725a21 ffba99b2 38043d5e

T: 8c227888

CTR0: 018bf767 62206f98 36b1e858 ca740000

CTR1: 018bf767 62206f98 36b1e858 ca740001
CTR2: 018bf767 62206f98 36b1e858 ca740002

S0: 1404487a 919e16c8 b3245d80 2b364231

S1: 82082cbc 57038db7 4823be9a 34e0a8d7
S2: 1b5f7526 d26fe763 7669dfee 63743d3a

MIC: 982630f2
Encrypted payload: 19bb8e01 8a07b68d d86f7cdd 3efdfc88
a9562b1b

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 2, Part G Page 907
Sample Data

1.2.8 Sample data 8 (DH1, Central → Peripheral)

Payload byte length: 1b

K: 7b04934f d9d25294 ef1a014d a094f0b5
Payload counter: 006267f78b
Zero-length ACL-U Continuation: 0
Direction: 0
Initialization vector: 74ca58e8 b136986f
LT_ADDR: 1
Packet Type: 4
LLID: 2
Payload: 8f11d05e e0e749b5 eeda42f9 2b184502
95388ce5 872916b4 bf7260

B0: 498bf767 62006f98 36b1e858 ca74001b

B1: 00210200 00000000 00000000 00000000
B2: 8f11d05e e0e749b5 eeda42f9 2b184502
B3: 95388ce5 872916b4 bf726000 00000000

Y0: 28015834 f3117a84 904800f7 ebd4b0d4

Y1: 15c4a61e b7ae954e 2c9d1b19 3ba2a9e5
Y2: 832c185d 1effc0ee 94d3a26e 23aca8e6
Y3: dcef7067 fc38a84e 893670a6 fb9e069b

T: dcef7067

CTR0: 018bf767 62006f98 36b1e858 ca740000

CTR1: 018bf767 62006f98 36b1e858 ca740001
CTR2: 018bf767 62006f98 36b1e858 ca740002

S0: 254593c4 cd12c6a7 d9dec572 95524b75

S1: af492e65 ca391b26 e8ce9653 498ed0de
S2: 869271ed ac79c1bc 3cf0f959 c2711f3b

MIC: f9aae3a3
Encrypted payload: 2058fe3b 2ade5293 0614d4aa 629695dc
13aafd08 2b50d708 838299

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 2, Part G Page 908
Sample Data

1.2.9 Sample data 9 (DH1, Peripheral → Central)

Payload byte length: 1b

K: 7b04934f d9d25294 ef1a014d a094f0b5
Payload counter: 006267f78b
Zero-length ACL-U Continuation: 0
Direction: 1
Initialization vector: 74ca58e8 b136986f
LT_ADDR: 1
Packet Type: 4
LLID: 2
Payload: 8f11d05e e0e749b5 eeda42f9 2b184502
95388ce5 872916b4 bf7260

B0: 498bf767 62206f98 36b1e858 ca74001b

B1: 00210200 00000000 00000000 00000000
B2: 8f11d05e e0e749b5 eeda42f9 2b184502
B3: 95388ce5 872916b4 bf726000 00000000

Y0: feb39b06 54b486da bf1cec46 b5c5ec2a

Y1: eeda0fc3 4057d94e 3572448d 67b640f4
Y2: 48461729 ec1c7060 3b0f88ce becef21a
Y3: b1ff4755 658c2aa2 862952a5 1ca041a1

T: b1ff4755

CTR0: 018bf767 62206f98 36b1e858 ca740000

CTR1: 018bf767 62206f98 36b1e858 ca740001
CTR2: 018bf767 62206f98 36b1e858 ca740002

S0: 1404487a 919e16c8 b3245d80 2b364231

S1: 82082cbc 57038db7 4823be9a 34e0a8d7
S2: 1b5f7526 d26fe763 7669dfee 63743d3a

MIC: a5fb0f2f
Encrypted payload: 0d19fce2 b7e4c402 a6f9fc63 1ff8edd5
8e67f9c3 5546f1d7 c91bbf

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 2, Part G Page 909
Sample Data

1.2.10 Sample data 10 (2-DH3, Central → Peripheral)

Payload byte length: 16f

K: 7b04934f d9d25294 ef1a014d a094f0b5
Payload counter: 006267f78b
Zero-length ACL-U Continuation: 0
Direction: 0
Initialization vector: 74ca58e8 b136986f
LT_ADDR: 1
Packet Type: a
LLID: 2
Payload: 969b0972 549738ea 89120710 55797f19
631dd8e7 219308a0 836e8d6b a55ec08f
42604406 543c2f96 60c261c3 1c3d8826
73aab82e bd5a8278 93625aa8 b9a4c5b3
bc310174 e4d6436e 2e44aa08 1d64e751
b5501222 dcc34270 6aefd398 1e10b2e2
56e20d95 1e4e68cc 3fdd4b5c 8e93809a
ff008232 3b6a864e b8556219 e94fbdd2
500550e9 939e6108 43a375ab a75d1f6d
a0304656 b45f488c 0ba40259 4e1ee6a1
c59301e8 f1507906 40dc0c24 330120c0
ac7f6707 e7f00d4a ea6c0577 a31abbb6
4f9b6bab 47bfa387 c89bbbe1 6d8cbd49
4a9c452f 9d46ab05 dcf0f434 f4c27bce
2e0e177d 1aba438d 64a8cd72 ca0c170c
9fa6e227 992fe354 98c94581 f1d869ee
b07ffcf2 c19b35c8 5e22939e b54c772c
2c4c0963 f51a653d 777879f2 d1ab67fc
ba300c9e fa3ba62e 9f70e4b9 1a996f81
7a9dff0b 56fd15c2 e9858db3 9b33e8c2
254df11b 64b9ac36 409f2406 5c9e478a
fc3b8161 b32d1b56 9236e631 23ed2a53
89d4c4e0 8a799f0a 370e7310 734c9f

B0: 498bf767 62006f98 36b1e858 ca74016f

B1: 00510200 00000000 00000000 00000000
B2: 969b0972 549738ea 89120710 55797f19
B3: 631dd8e7 219308a0 836e8d6b a55ec08f
B4: 42604406 543c2f96 60c261c3 1c3d8826
B5: 73aab82e bd5a8278 93625aa8 b9a4c5b3

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 2, Part G Page 910
Sample Data

B6: bc310174 e4d6436e 2e44aa08 1d64e751

B7: b5501222 dcc34270 6aefd398 1e10b2e2
B8: 56e20d95 1e4e68cc 3fdd4b5c 8e93809a
B9: ff008232 3b6a864e b8556219 e94fbdd2
B10: 500550e9 939e6108 43a375ab a75d1f6d
B11: a0304656 b45f488c 0ba40259 4e1ee6a1
B12: c59301e8 f1507906 40dc0c24 330120c0
B13: ac7f6707 e7f00d4a ea6c0577 a31abbb6
B14: 4f9b6bab 47bfa387 c89bbbe1 6d8cbd49
B15: 4a9c452f 9d46ab05 dcf0f434 f4c27bce
B16: 2e0e177d 1aba438d 64a8cd72 ca0c170c
B17: 9fa6e227 992fe354 98c94581 f1d869ee
B18: b07ffcf2 c19b35c8 5e22939e b54c772c
B19: 2c4c0963 f51a653d 777879f2 d1ab67fc
B20: ba300c9e fa3ba62e 9f70e4b9 1a996f81
B21: 7a9dff0b 56fd15c2 e9858db3 9b33e8c2
B22: 254df11b 64b9ac36 409f2406 5c9e478a
B23: fc3b8161 b32d1b56 9236e631 23ed2a53
B24: 89d4c4e0 8a799f0a 370e7310 734c9f00

Y0: 29d89cd3 f2a1cf11 de30fb32 7e036fd8

Y1: 969453f9 b7ed6ed5 0bb166ac ad84b447
Y2: 29c1dbe6 569d3bcd 517acede fdf9b2a3
Y3: 87ae6d80 ceb1d9ae e7e009f3 0564b2b4
Y4: f7b4d9bf a1fa7bba 484cba56 f72c649c
Y5: 7cff7307 318bed9a 94c81c3f 7fa87554
Y6: ccf442c7 832413c6 1387b50f 1d6af991
Y7: fda7fb71 83c5a785 a798814c d0a4f4ef
Y8: ca85d795 514e510a e715b603 ad7fd821
Y9: 65527777 4efa23ca d5124e05 0597d5ff
Y10: b17f66c4 8a523b41 950f09c0 fc3a2a15
Y11: 886ec25e ed7cd1af 44de48bf fde11c40
Y12: cd685d0d 10a34a2f 2fa75fee c8a36979
Y13: d7486efa 056ebad9 0f6fe2ac f9871d36
Y14: c28103ad 2fe40cb6 42337daa fee66a03
Y15: c4a313af aad33282 8db4432c 73550d1c
Y16: e29b7baa b3c83223 72fc11d5 b15c01bb
Y17: 22737a00 4e7f26b9 c9f368e1 a90843ae
Y18: 11f9a9f7 997119fb ebad9814 230e9f11
Y19: 026c4112 d016c255 9595bdc9 a8b14e95
Y20: dfe4c01a b101dfca 4bd2ca7e 4342d595

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 2, Part G Page 911
Sample Data

Y21: 5a128313 b4180f77 80a029cc 23a0c1fc

Y22: b4df1ace 2e0a3a2a 968d45e4 7a11a3cf
Y23: d2fb23c5 4849439d 80e8fed4 7ee0e5cb
Y24: da1c4547 7eab6f64 b771cf1e 8ca278ad

T: da1c4547

CTR0: 018bf767 62006f98 36b1e858 ca740000

CTR1: 018bf767 62006f98 36b1e858 ca740001
CTR2: 018bf767 62006f98 36b1e858 ca740002
CTR3: 018bf767 62006f98 36b1e858 ca740003
CTR4: 018bf767 62006f98 36b1e858 ca740004
CTR5: 018bf767 62006f98 36b1e858 ca740005
CTR6: 018bf767 62006f98 36b1e858 ca740006
CTR7: 018bf767 62006f98 36b1e858 ca740007
CTR8: 018bf767 62006f98 36b1e858 ca740008
CTR9: 018bf767 62006f98 36b1e858 ca740009
CTR10: 018bf767 62006f98 36b1e858 ca74000a
CTR11: 018bf767 62006f98 36b1e858 ca74000b
CTR12: 018bf767 62006f98 36b1e858 ca74000c
CTR13: 018bf767 62006f98 36b1e858 ca74000d
CTR14: 018bf767 62006f98 36b1e858 ca74000e
CTR15: 018bf767 62006f98 36b1e858 ca74000f
CTR16: 018bf767 62006f98 36b1e858 ca740010
CTR17: 018bf767 62006f98 36b1e858 ca740011
CTR18: 018bf767 62006f98 36b1e858 ca740012
CTR19: 018bf767 62006f98 36b1e858 ca740013
CTR20: 018bf767 62006f98 36b1e858 ca740014
CTR21: 018bf767 62006f98 36b1e858 ca740015
CTR22: 018bf767 62006f98 36b1e858 ca740016
CTR23: 018bf767 62006f98 36b1e858 ca740017

S0: 254593c4 cd12c6a7 d9dec572 95524b75

S1: af492e65 ca391b26 e8ce9653 498ed0de
S2: 869271ed ac79c1bc 3cf0f959 c2711f3b
S3: 31554cb7 aa9b1dfb 24ba8b26 eab59ad8
S4: 7cb39415 9dce80e6 0ac0e5e0 9667747e
S5: 9727b319 ccbcc251 d539fd08 497942c8
S6: bd972408 212a147c 3eb66687 1488e2d9
S7: aef3e149 6b4e615b 309a7f93 53ca2981
S8: 6b276914 1d957bec 4c87e76d ee681e76

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 2, Part G Page 912
Sample Data

S9: a2df383f eece9b0d 4553f2e8 6f8b6035

S10: 11dac6bc c4177830 c7038ee1 e6cb0579
S11: 30bfd1cf 7fa95155 7c0757bf f14840a0
S12: 2315682b 1f4cb1f6 10fd4365 4d9b6155
S13: 7f4aa2fd 211bbc18 9ff3dcd7 c8102220
S14: a072aa38 70e32a62 f7214fb1 97dbfbfd
S15: f7c2b622 96a1f9e1 d3e7837f 293f6e86
S16: e63dc9fd 830944d5 b9fa2257 b0e19402
S17: eceef697 e76f671f 5e7e8c6e ae43f63b
S18: a9bccd3a 4ae6b498 40a6ead6 cd6200a8
S19: 2b624b6b f923eb0f 110ff341 4b1ab902
S20: a47db290 f068ca62 c9236eec ddb431f4
S21: a4ad3dc5 7e324250 1938950e 7b3827fd
S22: 364c32d8 35f63c05 5c8f32dd e560cc8f
S23: f2fd81dc cd12d0cc 2e4f7834 43a74630

MIC: ff59d683
Encrypted payload: 39d22717 9eae23cc 61dc9143 1cf7afc7
e58fa90a 8deac91c bf9e7432 672fdfb4
733508b1 fea7326d 4478eae5 f68812fe
0f192c3b 2094029e 99a2bf48 2fc3b1cd
2b16b26d 286a813f fb7d5700 541da599
08c7362a fde9560c 5459b51f 0a98503b
f811ecdc 75000997 0f4734cf dd59a91b
9427eb26 26fffda2 f4d28574 0727a3a4
f2da68d6 7d50fa05 06f08743 c8d67f58
b1ea80ea 704830bc cca78cb8 a8d5e3d8
f52cd027 8ef92853 3cdb5b9b c2496060
8f6a0f2c f8bcbcbc fa914612 ee81dae3
30d1c956 66a41f9f 57686736 a59c9f69
eaeeef17 eda58167 2bd1bb85 63198033
d9cca15f 8c1bba6c b74f4e0d e333798a
799b2bda 1a26a781 213367d6 4139fdec
5c910a65 26f452d7 005c1ff0 1b0f8117
85f0c459 bffcd1a5 37de9324 1cc96754
915247f5 03184d21 8e7f17f8 5183d683
dee04d9b a695dfa0 20a6e35f 4687d936
81e0ccde 1a8bee66 59a7b108 27a66077
ca77b3b9 86db2753 ceb9d4ec c68de6dc
7b29453c 476b4fc6 19410b24 30ebd9

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 2, Part G Page 913
Sample Data

1.2.11 Sample data 11 (2-DH3, Peripheral → Central)

Payload byte length: 16f

K: 7b04934f d9d25294 ef1a014d a094f0b5
Payload counter: 006267f78b
Zero-length ACL-U Continuation: 0
Direction: 1
Initialization vector: 74ca58e8 b136986f
LT_ADDR: 1
Packet Type: a
LLID: 2
Payload: 969b0972 549738ea 89120710 55797f19
631dd8e7 219308a0 836e8d6b a55ec08f
42604406 543c2f96 60c261c3 1c3d8826
73aab82e bd5a8278 93625aa8 b9a4c5b3
bc310174 e4d6436e 2e44aa08 1d64e751
b5501222 dcc34270 6aefd398 1e10b2e2
56e20d95 1e4e68cc 3fdd4b5c 8e93809a
ff008232 3b6a864e b8556219 e94fbdd2
500550e9 939e6108 43a375ab a75d1f6d
a0304656 b45f488c 0ba40259 4e1ee6a1
c59301e8 f1507906 40dc0c24 330120c0
ac7f6707 e7f00d4a ea6c0577 a31abbb6
4f9b6bab 47bfa387 c89bbbe1 6d8cbd49
4a9c452f 9d46ab05 dcf0f434 f4c27bce
2e0e177d 1aba438d 64a8cd72 ca0c170c
9fa6e227 992fe354 98c94581 f1d869ee
b07ffcf2 c19b35c8 5e22939e b54c772c
2c4c0963 f51a653d 777879f2 d1ab67fc
ba300c9e fa3ba62e 9f70e4b9 1a996f81
7a9dff0b 56fd15c2 e9858db3 9b33e8c2
254df11b 64b9ac36 409f2406 5c9e478a
fc3b8161 b32d1b56 9236e631 23ed2a53
89d4c4e0 8a799f0a 370e7310 734c9f

B0: 498bf767 62206f98 36b1e858 ca74016f

B1: 00510200 00000000 00000000 00000000
B2: 969b0972 549738ea 89120710 55797f19
B3: 631dd8e7 219308a0 836e8d6b a55ec08f
B4: 42604406 543c2f96 60c261c3 1c3d8826
B5: 73aab82e bd5a8278 93625aa8 b9a4c5b3

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 2, Part G Page 914
Sample Data

B6: bc310174 e4d6436e 2e44aa08 1d64e751

B7: b5501222 dcc34270 6aefd398 1e10b2e2
B8: 56e20d95 1e4e68cc 3fdd4b5c 8e93809a
B9: ff008232 3b6a864e b8556219 e94fbdd2
B10: 500550e9 939e6108 43a375ab a75d1f6d
B11: a0304656 b45f488c 0ba40259 4e1ee6a1
B12: c59301e8 f1507906 40dc0c24 330120c0
B13: ac7f6707 e7f00d4a ea6c0577 a31abbb6
B14: 4f9b6bab 47bfa387 c89bbbe1 6d8cbd49
B15: 4a9c452f 9d46ab05 dcf0f434 f4c27bce
B16: 2e0e177d 1aba438d 64a8cd72 ca0c170c
B17: 9fa6e227 992fe354 98c94581 f1d869ee
B18: b07ffcf2 c19b35c8 5e22939e b54c772c
B19: 2c4c0963 f51a653d 777879f2 d1ab67fc
B20: ba300c9e fa3ba62e 9f70e4b9 1a996f81
B21: 7a9dff0b 56fd15c2 e9858db3 9b33e8c2
B22: 254df11b 64b9ac36 409f2406 5c9e478a
B23: fc3b8161 b32d1b56 9236e631 23ed2a53
B24: 89d4c4e0 8a799f0a 370e7310 734c9f00

Y0: 34969012 2648722b fb7771dd b1b38b1b

Y1: 8c511978 793004c6 975e5f19 93c19d99
Y2: 482014e5 39ddbbd4 0833c079 5bab45ef
Y3: b994181f a79795ce a6968237 28ad1659
Y4: 7b8fea33 1c4c8c50 d8ae584b bfc65033
Y5: e185c7b7 dd9831f5 2e0d2140 95368c09
Y6: d598bb23 fb4d4e82 a8b74b2b c95b5b71
Y7: 6c5c7fc1 8cc70897 3bb594a8 39541943
Y8: c7f822e8 7546115f 80d57035 7960abb8
Y9: a430ddc8 58f529f1 97bebcb7 e9160550
Y10: c9bf7627 33253b87 1490fbd7 353a3175
Y11: 1d93c403 de2c3b76 62e6ea6e cbf757c0
Y12: 0d607c00 af5502d9 2d56d483 745f6855
Y13: e27bdc66 de323cff a3a1620d 1637310e
Y14: 840d6d95 6785fead 710de246 e944bf2e
Y15: 806b9eb6 6517c4f8 1d55f260 e08f455b
Y16: 36883866 2f7275ab 6ba45111 2431882d
Y17: e5b4f1f6 cbbcc363 33ef1b05 94b5385e
Y18: e8d47695 67be9d89 04445e73 8a45e019
Y19: 77639b94 f0f9907c db541ef0 c8d45e4b
Y20: a2bd914a 281e1d5f 0c9b8de4 3fcb6565

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 2, Part G Page 915
Sample Data

Y21: 6c1072e6 5581e658 7d7a0561 e8a85ddf

Y22: 8256c105 5c932ba8 bb71936b c727d10f
Y23: 2f4cc66a d568be7e 500a7448 6c2278ad
Y24: 2ca06cb0 0009e3c3 9e123a8a 2c2869dc

T: 2ca06cb0

CTR0: 018bf767 62206f98 36b1e858 ca740000

CTR1: 018bf767 62206f98 36b1e858 ca740001
CTR2: 018bf767 62206f98 36b1e858 ca740002
CTR3: 018bf767 62206f98 36b1e858 ca740003
CTR4: 018bf767 62206f98 36b1e858 ca740004
CTR5: 018bf767 62206f98 36b1e858 ca740005
CTR6: 018bf767 62206f98 36b1e858 ca740006
CTR7: 018bf767 62206f98 36b1e858 ca740007
CTR8: 018bf767 62206f98 36b1e858 ca740008
CTR9: 018bf767 62206f98 36b1e858 ca740009
CTR10: 018bf767 62206f98 36b1e858 ca74000a
CTR11: 018bf767 62206f98 36b1e858 ca74000b
CTR12: 018bf767 62206f98 36b1e858 ca74000c
CTR13: 018bf767 62206f98 36b1e858 ca74000d
CTR14: 018bf767 62206f98 36b1e858 ca74000e
CTR15: 018bf767 62206f98 36b1e858 ca74000f
CTR16: 018bf767 62206f98 36b1e858 ca740010
CTR17: 018bf767 62206f98 36b1e858 ca740011
CTR18: 018bf767 62206f98 36b1e858 ca740012
CTR19: 018bf767 62206f98 36b1e858 ca740013
CTR20: 018bf767 62206f98 36b1e858 ca740014
CTR21: 018bf767 62206f98 36b1e858 ca740015
CTR22: 018bf767 62206f98 36b1e858 ca740016
CTR23: 018bf767 62206f98 36b1e858 ca740017

S0: 1404487a 919e16c8 b3245d80 2b364231

S1: 82082cbc 57038db7 4823be9a 34e0a8d7
S2: 1b5f7526 d26fe763 7669dfee 63743d3a
S3: a3673258 5020c6cd d72bf517 accb632d
S4: 8a60ebb6 59c59ac1 a45a1ffd f54f7cd7
S5: 036f35c7 130c8a30 25e9da14 706df5bc
S6: e328cbb0 09c91d56 f010b40e e0fc5c3f
S7: 626d3d67 b53eb139 e155c9a2 df407b17
S8: d94e430b 829c7caf 289d2898 3c68aa5a

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 2, Part G Page 916
Sample Data

S9: d6343452 d92cb1ac b3fde90b e2f0789f

S10: 8ab8413c 0df18adf ae07a74f 82b3c91f
S11: 61bfac52 125b8fc4 eaac30f7 5a543821
S12: 68899f8f 2892931d 88b08926 7fa3cfc9
S13: 86b668c5 4ef24455 22a45f42 61aea816
S14: f57b4941 8332f0b3 7749ea30 53a711ee
S15: 593562a8 45c75a7c 70030f08 6fedd965
S16: f85e742f a743f353 6a22b384 be1dabdc
S17: ed7e317b 635deed3 e8b619f2 9bc65eb0
S18: 2035622d 94718ad6 c1631fa2 755883f4
S19: 40f50638 ad826c4a 3ca4fb88 467445ae
S20: e27eb632 0c2aee5c 9210b1c7 736fb897
S21: 711a9be3 c7054fa5 82ec70b6 028489e7
S22: 7b543081 c52e2cba 26400e6b 46642d0d
S23: d9564733 01fa7fae 7cfac2a7 239639e2

MIC: 38a424ca
Encrypted payload: 149325ce 0394b55d c131b98a 6199d7ce
7842adc1 f3fcefc3 f5075285 c62afdb5
e107765e 041ce95b b7e994d4 b0f6eb0b
f9ca5398 e49f18b9 37384555 4cebb964
bf5e34b3 f7dac95e 0bad701c 6d0912ed
5678d992 d50a5f26 9aff6796 feeceedd
348f30f2 ab70d9f5 de8882fe 51d3fb8d
264ec139 b9f6fae1 90c84a81 d5271788
863164bb 4ab2d0a4 f05e9ca0 45ad67f2
2a88076a b9aec253 a5a3a516 ccad2fbe
a42cadba e30bf6c2 aa703cd3 695518e1
c4f6f888 cf629e57 62dc8c51 dcb9747f
c92d036e 094de7d2 ea3fe4a3 0c22155f
bfe70c6e 1e745bb6 abb91e04 a7656a20
773b75d5 5f7d19f1 14abc27a a5e1ce69
67f89608 3e6c1007 f2ebf605 4fc5c232
5d01cd89 a2c6db1b b6948a6c 2e8a299c
0c796b4e 616befeb b61b6650 a4f3e408
fac50aa6 57b9ca64 a3d41f31 5ced2a2f
98e34939 5ad7fb9e 7b953c74 e85c5055
54576af8 a3bce393 c27354b0 5e1ace6d
876fb1e0 760337ec b476e85a 6589075e
508283d3 8b83e0a4 4bf4b1b7 50daa6

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 2, Part G Page 917
Sample Data

1.2.12 Sample data 12 (3-DH5, Central → Peripheral)

Payload byte length: 3fd

K: 7b04934f d9d25294 ef1a014d a094f0b5
Payload counter: 006267f78b
Zero-length ACL-U Continuation: 0
Direction: 0
Initialization vector: 74ca58e8 b136986f
LT_ADDR: 1
Packet Type: f
LLID: 2
Payload: 6d42614c 50694940 209c8bd5 5be57733
3ec1066a 76cb602e a58ced25 f98ceb94
58bc3db4 e7c46bb9 e23f9220 68bfca00
c1da8f08 1c10e526 0ea37fab 3d91be9f
3a4e68e9 006cca11 fdc76c59 1e20769d
e1e34385 af105dab 4d44eda7 eacd1974
5414d5a9 568d67af c05aedd9 6726a130
7ebe31fd 81881237 c953d2a5 42c57c3b
019691ef 911953fb 39264712 c61e3e5e
21286421 85891af5 bf8ca291 59c30596
11bbe5cd 8f88a7bb b8afd34a 4211eed5
850ca781 cc9cf5b9 06d5fced 79d35981
39a1a239 2965b0d5 c6c03a9f e22433ba
08e7aac7 7d207392 b3486ead dd5c81c6
5454d575 edd91892 0a2f0fe9 f6d5c037
fec1272e f22c9aa0 d02b3412 81f60847
887cd303 a82937cf ded4be2d 139342ce
bd09041a f5eaa675 4307eb2d 20a60f7b
1b944afe e3ae1a6f 476021c7 d30d300e
44f9eaa2 42e8cb7a 6d74d5b5 0f2d6c1b
d436f44f 1ddf8579 70821a65 117e1200
e0270f00 7cbe6bb2 020ec332 bc464299
20131eb1 e8864206 3b4a8324 522cfe0a
a5209fd7 3f11a1e0 da00c945 835b6b5f
ec9eaea9 9d177dc0 cbd2efe8 21b388c3
78b2e137 c84f37a4 5599ffc0 a9106204
5ed1439f 7e67ea1d 6ab024f7 247e85df
bf15d19c b0f488d2 cb06bed9 644ec34c
2e69f752 4af38319 81c7556e 359bfaf5
22a00878 4ce3e7e2 362698ea 6c00001d

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 2, Part G Page 918
Sample Data

fdf0936d 2cf7a318 ed4f0447 ad506cdd

c2fcf8b7 328bb527 063859b5 f60819d3
eebdd291 0a12c6af 1c670a30 38fd9e2c
4a6a3ad7 a51982bd 8d4fabf5 a8c16517
831661b0 09405052 9fba337b 2b3544cf
6811a761 093afd66 8b154a21 a5941b88
a482c5ce f04b18c1 c2e67d7d f90c3a4d
d4ee12fe 4b734174 d3ee8b0c 1ade74eb
237710da 4694764b 7cce26c4 7a2570bf
30bb18c7 6571ab05 26892de7 b5d62840
7f300971 14d6014b 2ca566b3 d6ad1ef5
96e552e6 defc287e 6a5a5c16 be31d26a
392e1570 a9f9e0b3 32d223e5 b15407f3
41cc55f8 3296f3f5 175ebece 580a3f24
49494406 fa75e051 c829441b ce7cba98
cb7ea85d 8031787d 9495b971 c6925f64
2726ef05 932d3f1a 14a9bd1a d88a9b31
6f54d80e 9fe31dcf c94c1f6a 92cc2c82
60bd9296 e075b884 2976b667 041800df
520e7a28 e5b9314a 0bb93966 1aba4643
829544e2 d69f255c ce5bfa89 9a4704f3
be803081 fbc36f5c 65fb13c8 69fc770a
07cbc8ff 50b8dbe3 b171e9f9 ebc8cf22
49127607 32973806 95979b3c d75a3f8f
f933a408 d4945f63 96755d6e 493b554b
58e78f5b a21d31b3 bbcddf62 83e94233
15a3bea8 3a6ff73f f02809da 3c6d8208
acfd6f05 b62bb5a5 91f1e4d5 4b84d357
2f00672a 3e3c434c 1736072b 45f6370c
bb46706b 56a57e86 3ed2217a 816e5c09
1e2895f7 89b57c5e c0a67011 d5f2f69d
6dac3941 3bc897dc cb42d3bc ffda31e0
e961f3fb e4f40041 69e86cc0 530e891c
7665902a 1ce0804c 921780ae e2

B0: 498bf767 62006f98 36b1e858 ca7403fd

B1: 00790200 00000000 00000000 00000000
B2: 6d42614c 50694940 209c8bd5 5be57733
B3: 3ec1066a 76cb602e a58ced25 f98ceb94
B4: 58bc3db4 e7c46bb9 e23f9220 68bfca00
B5: c1da8f08 1c10e526 0ea37fab 3d91be9f

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 2, Part G Page 919
Sample Data

B6: 3a4e68e9 006cca11 fdc76c59 1e20769d

B7: e1e34385 af105dab 4d44eda7 eacd1974
B8: 5414d5a9 568d67af c05aedd9 6726a130
B9: 7ebe31fd 81881237 c953d2a5 42c57c3b
B10: 019691ef 911953fb 39264712 c61e3e5e
B11: 21286421 85891af5 bf8ca291 59c30596
B12: 11bbe5cd 8f88a7bb b8afd34a 4211eed5
B13: 850ca781 cc9cf5b9 06d5fced 79d35981
B14: 39a1a239 2965b0d5 c6c03a9f e22433ba
B15: 08e7aac7 7d207392 b3486ead dd5c81c6
B16: 5454d575 edd91892 0a2f0fe9 f6d5c037
B17: fec1272e f22c9aa0 d02b3412 81f60847
B18: 887cd303 a82937cf ded4be2d 139342ce
B19: bd09041a f5eaa675 4307eb2d 20a60f7b
B20: 1b944afe e3ae1a6f 476021c7 d30d300e
B21: 44f9eaa2 42e8cb7a 6d74d5b5 0f2d6c1b
B22: d436f44f 1ddf8579 70821a65 117e1200
B23: e0270f00 7cbe6bb2 020ec332 bc464299
B24: 20131eb1 e8864206 3b4a8324 522cfe0a
B25: a5209fd7 3f11a1e0 da00c945 835b6b5f
B26: ec9eaea9 9d177dc0 cbd2efe8 21b388c3
B27: 78b2e137 c84f37a4 5599ffc0 a9106204
B28: 5ed1439f 7e67ea1d 6ab024f7 247e85df
B29: bf15d19c b0f488d2 cb06bed9 644ec34c
B30: 2e69f752 4af38319 81c7556e 359bfaf5
B31: 22a00878 4ce3e7e2 362698ea 6c00001d
B32: fdf0936d 2cf7a318 ed4f0447 ad506cdd
B33: c2fcf8b7 328bb527 063859b5 f60819d3
B34: eebdd291 0a12c6af 1c670a30 38fd9e2c
B35: 4a6a3ad7 a51982bd 8d4fabf5 a8c16517
B36: 831661b0 09405052 9fba337b 2b3544cf
B37: 6811a761 093afd66 8b154a21 a5941b88
B38: a482c5ce f04b18c1 c2e67d7d f90c3a4d
B39: d4ee12fe 4b734174 d3ee8b0c 1ade74eb
B40: 237710da 4694764b 7cce26c4 7a2570bf
B41: 30bb18c7 6571ab05 26892de7 b5d62840
B42: 7f300971 14d6014b 2ca566b3 d6ad1ef5
B43: 96e552e6 defc287e 6a5a5c16 be31d26a
B44: 392e1570 a9f9e0b3 32d223e5 b15407f3
B45: 41cc55f8 3296f3f5 175ebece 580a3f24
B46: 49494406 fa75e051 c829441b ce7cba98

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 2, Part G Page 920
Sample Data

B47: cb7ea85d 8031787d 9495b971 c6925f64

B48: 2726ef05 932d3f1a 14a9bd1a d88a9b31
B49: 6f54d80e 9fe31dcf c94c1f6a 92cc2c82
B50: 60bd9296 e075b884 2976b667 041800df
B51: 520e7a28 e5b9314a 0bb93966 1aba4643
B52: 829544e2 d69f255c ce5bfa89 9a4704f3
B53: be803081 fbc36f5c 65fb13c8 69fc770a
B54: 07cbc8ff 50b8dbe3 b171e9f9 ebc8cf22
B55: 49127607 32973806 95979b3c d75a3f8f
B56: f933a408 d4945f63 96755d6e 493b554b
B57: 58e78f5b a21d31b3 bbcddf62 83e94233
B58: 15a3bea8 3a6ff73f f02809da 3c6d8208
B59: acfd6f05 b62bb5a5 91f1e4d5 4b84d357
B60: 2f00672a 3e3c434c 1736072b 45f6370c
B61: bb46706b 56a57e86 3ed2217a 816e5c09
B62: 1e2895f7 89b57c5e c0a67011 d5f2f69d
B63: 6dac3941 3bc897dc cb42d3bc ffda31e0
B64: e961f3fb e4f40041 69e86cc0 530e891c
B65: 7665902a 1ce0804c 921780ae e2000000

Y0: ebe10d25 4ab27e31 1ea87d16 867d7904

Y1: 99b84ef8 a25d519e 700f76f1 85a74583
Y2: 23fd3478 f96bddd9 dd2e7ded 25f2515e
Y3: 5659d15b 1b569b1f 298f4430 7459cbe0
Y4: d0e6d2f8 939e7c9d 3774cf46 642295ce
Y5: 7e6662bc 99ec7ecc d985ddd4 d2365187
Y6: 421bb569 a5f4d07a 5157fed4 db03f630
Y7: 9fa62969 f43263b1 ac3e269f 15b844ff
Y8: a36e0d50 b75b2feb 45d8c9ee 052f33e4
Y9: 6245ece7 0ad0e314 2ce6ad6b f406b745
Y10: 41ff1de6 e1b3ccec eb6cfb07 fd150751
Y11: 43cae883 dd43266d 2f717cd4 b7c777ba
Y12: 92e3f4b7 bc4b8613 38c0043b 6885fbfb
Y13: b1595644 ec0a8e4e 803994e6 f3d284c5
Y14: e9f7ec01 c4f11349 a5f0a3aa efe88c98
Y15: 8c48cadc 7483c350 c11b6cb4 b8f32b25
Y16: b76f72f5 d54da8e0 b70bcaae 0727f4ed
Y17: b700d8e8 585256f8 38530196 ef3a4a6e
Y18: e0a0f7f0 8f252298 48f8e404 ff4d9f93
Y19: aea86952 8f028974 d890f4e5 52e6da13
Y20: 36566635 1c0a0078 9ee4499b d30ac682

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 2, Part G Page 921
Sample Data

Y21: 886e6fcb 9e9fe3e8 dbfa13ae 7d1e44a7

Y22: 43c5285e de2846da 266a4720 cbd3713e
Y23: 52c47b3e d9a6666e 566eaba7 9275a90f
Y24: ac04ee00 56922a78 5f48347a 3a2360f7
Y25: 33b5496f 546e71f0 80272f6a d189898a
Y26: 5519cbaf ff8fe542 4934f09a 39584456
Y27: 913a3746 5e6ad4c1 7fce844c f72dc1d8
Y28: 46cef034 a103a8f4 ac13040c 6c466b4b
Y29: 6cbffa5e 2dff5b95 87ba863b 26eab593
Y30: f3dbf258 03f21f71 4d03c4a2 7be84598
Y31: b3c7f849 ab6e9612 e9ece9d5 57c4c813
Y32: 39043423 c60f8fd8 2c108055 6f387c76
Y33: f9dd8872 1fa6f4f4 e5345613 fd5495fd
Y34: cf3d7135 63d2ccfd 41507bd0 fe759830
Y35: 8215cff7 93ae5d92 446fb102 632b4fb8
Y36: 8b02ecb6 fcc063f6 fb41e34a 19afdb3a
Y37: 982e82d3 171d9fb0 ab5b8fbf 17dc00d2
Y38: 2dc18652 f4818748 e3c5fe0e 36b47716
Y39: e6eaef36 46e56552 8ed8c309 ea46ba7f
Y40: 40842220 827424b0 b2f7d5cf b201b5e4
Y41: 5153e29d bc85bafb 36dea69c ec1f1a43
Y42: 08614ff3 44d96b3a f5b9e763 5600b69c
Y43: 2550a964 b17af58b 1843199b 1394de57
Y44: 11cda830 619505fa 49d971c9 c8051abb
Y45: d73824df 17b8ccc2 b52ba9ea ff6f6097
Y46: 100d3219 3486065d 9e7e7ebd 235c34c1
Y47: 440e8fbf e2af1797 2fa75056 2e1941d4
Y48: 91eb5850 4d92d2b8 a64b0e8e 34cf38ef
Y49: 715b4924 0a081cee 2509e363 c746ba6b
Y50: 1cc42047 e5fa2dfb 1c0901f0 a01676c5
Y51: 2634d6db 62d0d5b7 328c5278 6d44b7b1
Y52: 79a0548c 8589f663 323c1604 6af753a8
Y53: e0ba54a0 412e68c1 13c5daf1 8a6e275a
Y54: a1a5e608 3359873b cfb66476 052fcb79
Y55: ce70f15c f2971ebe 7c2d1e3c a288f591
Y56: d9a64946 58968fda 4756668d a5b82b89
Y57: 0c2d5786 6ae786a6 03c6db95 6d26186a
Y58: 00732c24 192905a4 3edaeb0d cc3d4a95
Y59: ae9a2e1c 042112df 4578395b cba685b1
Y60: 50fdc48d 0af8812c b3e64e85 3316b083
Y61: d2c14e67 888a7401 85bd5b91 37d6977a

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 2, Part G Page 922
Sample Data

Y62: 4b882e82 ca8338bb 2278c4d3 8d07f474

Y63: 4bf051e5 19bc961e 38c52cae 50e61d87
Y64: 657025a1 064ec7d6 e1d16bc0 049931bf
Y65: 6de9dbe8 c5a2ed24 66701ea3 4caee13e

T: 6de9dbe8

CTR0: 018bf767 62006f98 36b1e858 ca740000

CTR1: 018bf767 62006f98 36b1e858 ca740001
CTR2: 018bf767 62006f98 36b1e858 ca740002
CTR3: 018bf767 62006f98 36b1e858 ca740003
CTR4: 018bf767 62006f98 36b1e858 ca740004
CTR5: 018bf767 62006f98 36b1e858 ca740005
CTR6: 018bf767 62006f98 36b1e858 ca740006
CTR7: 018bf767 62006f98 36b1e858 ca740007
CTR8: 018bf767 62006f98 36b1e858 ca740008
CTR9: 018bf767 62006f98 36b1e858 ca740009
CTR10: 018bf767 62006f98 36b1e858 ca74000a
CTR11: 018bf767 62006f98 36b1e858 ca74000b
CTR12: 018bf767 62006f98 36b1e858 ca74000c
CTR13: 018bf767 62006f98 36b1e858 ca74000d
CTR14: 018bf767 62006f98 36b1e858 ca74000e
CTR15: 018bf767 62006f98 36b1e858 ca74000f
CTR16: 018bf767 62006f98 36b1e858 ca740010
CTR17: 018bf767 62006f98 36b1e858 ca740011
CTR18: 018bf767 62006f98 36b1e858 ca740012
CTR19: 018bf767 62006f98 36b1e858 ca740013
CTR20: 018bf767 62006f98 36b1e858 ca740014
CTR21: 018bf767 62006f98 36b1e858 ca740015
CTR22: 018bf767 62006f98 36b1e858 ca740016
CTR23: 018bf767 62006f98 36b1e858 ca740017
CTR24: 018bf767 62006f98 36b1e858 ca740018
CTR25: 018bf767 62006f98 36b1e858 ca740019
CTR26: 018bf767 62006f98 36b1e858 ca74001a
CTR27: 018bf767 62006f98 36b1e858 ca74001b
CTR28: 018bf767 62006f98 36b1e858 ca74001c
CTR29: 018bf767 62006f98 36b1e858 ca74001d
CTR30: 018bf767 62006f98 36b1e858 ca74001e
CTR31: 018bf767 62006f98 36b1e858 ca74001f
CTR32: 018bf767 62006f98 36b1e858 ca740020
CTR33: 018bf767 62006f98 36b1e858 ca740021

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 2, Part G Page 923
Sample Data

CTR34: 018bf767 62006f98 36b1e858 ca740022

CTR35: 018bf767 62006f98 36b1e858 ca740023
CTR36: 018bf767 62006f98 36b1e858 ca740024
CTR37: 018bf767 62006f98 36b1e858 ca740025
CTR38: 018bf767 62006f98 36b1e858 ca740026
CTR39: 018bf767 62006f98 36b1e858 ca740027
CTR40: 018bf767 62006f98 36b1e858 ca740028
CTR41: 018bf767 62006f98 36b1e858 ca740029
CTR42: 018bf767 62006f98 36b1e858 ca74002a
CTR43: 018bf767 62006f98 36b1e858 ca74002b
CTR44: 018bf767 62006f98 36b1e858 ca74002c
CTR45: 018bf767 62006f98 36b1e858 ca74002d
CTR46: 018bf767 62006f98 36b1e858 ca74002e
CTR47: 018bf767 62006f98 36b1e858 ca74002f
CTR48: 018bf767 62006f98 36b1e858 ca740030
CTR49: 018bf767 62006f98 36b1e858 ca740031
CTR50: 018bf767 62006f98 36b1e858 ca740032
CTR51: 018bf767 62006f98 36b1e858 ca740033
CTR52: 018bf767 62006f98 36b1e858 ca740034
CTR53: 018bf767 62006f98 36b1e858 ca740035
CTR54: 018bf767 62006f98 36b1e858 ca740036
CTR55: 018bf767 62006f98 36b1e858 ca740037
CTR56: 018bf767 62006f98 36b1e858 ca740038
CTR57: 018bf767 62006f98 36b1e858 ca740039
CTR58: 018bf767 62006f98 36b1e858 ca74003a
CTR59: 018bf767 62006f98 36b1e858 ca74003b
CTR60: 018bf767 62006f98 36b1e858 ca74003c
CTR61: 018bf767 62006f98 36b1e858 ca74003d
CTR62: 018bf767 62006f98 36b1e858 ca74003e
CTR63: 018bf767 62006f98 36b1e858 ca74003f
CTR64: 018bf767 62006f98 36b1e858 ca740040

S0: 254593c4 cd12c6a7 d9dec572 95524b75

S1: af492e65 ca391b26 e8ce9653 498ed0de
S2: 869271ed ac79c1bc 3cf0f959 c2711f3b
S3: 31554cb7 aa9b1dfb 24ba8b26 eab59ad8
S4: 7cb39415 9dce80e6 0ac0e5e0 9667747e
S5: 9727b319 ccbcc251 d539fd08 497942c8
S6: bd972408 212a147c 3eb66687 1488e2d9
S7: aef3e149 6b4e615b 309a7f93 53ca2981
S8: 6b276914 1d957bec 4c87e76d ee681e76

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 2, Part G Page 924
Sample Data

S9: a2df383f eece9b0d 4553f2e8 6f8b6035

S10: 11dac6bc c4177830 c7038ee1 e6cb0579
S11: 30bfd1cf 7fa95155 7c0757bf f14840a0
S12: 2315682b 1f4cb1f6 10fd4365 4d9b6155
S13: 7f4aa2fd 211bbc18 9ff3dcd7 c8102220
S14: a072aa38 70e32a62 f7214fb1 97dbfbfd
S15: f7c2b622 96a1f9e1 d3e7837f 293f6e86
S16: e63dc9fd 830944d5 b9fa2257 b0e19402
S17: eceef697 e76f671f 5e7e8c6e ae43f63b
S18: a9bccd3a 4ae6b498 40a6ead6 cd6200a8
S19: 2b624b6b f923eb0f 110ff341 4b1ab902
S20: a47db290 f068ca62 c9236eec ddb431f4
S21: a4ad3dc5 7e324250 1938950e 7b3827fd
S22: 364c32d8 35f63c05 5c8f32dd e560cc8f
S23: f2fd81dc cd12d0cc 2e4f7834 43a74630
S24: 7875bf58 8a162375 b25069d6 b82f4f36
S25: a66bb2d0 43870301 47dbe7f1 92f04b34
S26: 52b87f3e 796b208e 5a0f57c1 6de88c53
S27: 312e84cd 8f627142 ffa9b6cd 56ce3c59
S28: 6695a4dd 1e85cb05 c2070e7c fa16dd90
S29: 10df7734 8a106a97 3b37c508 e54fc157
S30: 54abd840 17756b69 0b7e187b ef5c8ea5
S31: 0bf5f442 c3fecabd 64b313ca 9787f134
S32: aaed31c5 98d1b73a ceaf242d 37b08fd4
S33: 37946570 fcf94220 77cf63da 4781771b
S34: ab5dd397 a7c0d893 7b17c1d2 eb9bc233
S35: 7367b29c 0ecc6a76 1a3c5602 40ca2ca2
S36: 6b593c6d f7485995 f36f1169 089c0be9
S37: ffca503f cfb8848c 73e37041 508128a3
S38: 444e1461 b95ef61a 90c93236 5aaa9fa8
S39: 4099c123 717f86df 23e16eaf 7ed015df
S40: 730217d1 28fa1af8 720864ad 99430469
S41: 43e6b844 95068645 5aca15ed 1bc668a6
S42: 9ee17b6a 65f56326 42e4b829 b5348945
S43: acf20ec7 151b75f0 dd4023ba d099b71c
S44: 41880777 e033c519 79eee51e 14a9246d
S45: 02bb2b01 4981e028 ddb66c67 a7077a1b
S46: db90a526 db75c631 d31af69d ef7b9082
S47: fddfda45 35a30553 78f655cb eae4d1d3
S48: 3472e976 3205e39b e8295a5d 9be10244
S49: fbe961bd 23f25c70 c87cac28 157b55d1

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 2, Part G Page 925
Sample Data

S50: 20a9174a 8da17e48 167086fd 5201ccbb

S51: 390a62b8 90a669c1 b89476ac a46ee788
S52: e354ab7f bd3afd7d 02361116 91afbf21
S53: cbe14419 ab1a4841 3155aaab e1d41a64
S54: cf8fd9f8 8d63ce6a c4c81f7b 852a081f
S55: c6abaae1 44875175 f239963a 194565d1
S56: 8f420880 95982bda d1317139 e9ca663b
S57: 5c7e5c2e 9a457be9 325620ed e0465cf7
S58: f9eb32f4 e1804702 eaff74d1 dea8a295
S59: eb66a965 5551f198 b13495a8 2200509c
S60: a0ee623d 5562b3a6 2cea2c8d f60eb0d8
S61: e7562630 9f7d5b7b 4da8effc e4a1e015
S62: fa1a5da9 7cdfed2b efd7b409 e065c33e
S63: 238ac0b6 f00d1b5b 77b091cc f4a4ffc4
S64: 533e37d7 b179b943 53511492 e4f58248

MIC: 48ac482c
Encrypted payload: c20b4f29 9a505266 c8521d86 126ba7ed
b8537787 dab2a192 997c147c 3bfdf4af
69e97103 4d5f7642 c6851906 820a50d8
bd691b1d 81de65c0 04639a4b abf6cae1
ad69dbf0 ccd00840 28fe9151 57593455
5c74678d 8e3a49d7 73f28b20 fe45fbad
fae734e0 3dc306f4 f0c0924a 34ec88b1
159958e9 9c1d69db 85d435c8 acad624d
a349a9d0 7fd7c8f6 7c75b5fa a9955e6b
30f2a29d 419e62c5 788f2c70 bf0800ef
21043402 f021f6ee c4a884f5 b359ae75
a619cfaa d3d0444f 1628bf88 344838d4
46eb00c4 087e0ccd 5933e648 2a34119a
a89500ff 0dc359f0 4469211c 4a877a3b
a3966357 7b78e173 d9c88c96 dfeaaeb1
18fceed3 7125de75 69d11645 31179c45
64922594 4f4650d0 80aa3243 bdd0b4f5
14b5c920 bf0c12ed 03a101fb edc40fd3
30f60195 1a8df160 566fd286 9817890c
e0845832 b2800118 a457bb59 d2995def
709bc98a 63edc729 69ba8f6b 6a4635fd
d66b3dd8 494857b7 5e81f1ef 59268e16
d2ee9f6d 259492ca 1505fb10 118bb83a
dd55208f b5078295 6850a093 3b742469

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 2, Part G Page 926
Sample Data

4af51c79 de907ec1 8c090819 b343c3f7

2a0a9e09 b124172a 0f96a801 c4f8ee57
6fffc752 f1059b5f 9519923a 72b0b986
d9807541 ae7143d7 0901b0a5 9e581edc
3eb68066 c0e3e98e baf09066 d0d43ba2
760bd038 5b968c8b 3d588091 835c8eb8
f605672f ef0969a5 89fc178d 3ad79de9
6811c972 aa5a021d c8977d98 c1b89607
d929b7e1 f6eb848f 6ba869ea 7f7ce937
e137e940 02d95a2e f6586a27 435aa724
f071d32c 078c3a24 85866579 6bff686d
03489b0c fe72a4f3 787a5b48 ad081061
5b4895f1 3ff39c4d b1050d3c a98d12ee
90a0069f f22db76e 4327b93a 4074eb43
63eed1f9 37ebf094 5f2f486b 04f56560
43b90f16 4d8bb1fd 5481494a 2c952c29
3cd6b135 81d0870e 766f735e cd6b7653
0804298c bb094b58 28bee43f 0b055b2f
95dc1bb7 bce29543 ef92005f 61cdb0ef
0044528f d2a536ec 6eb05bd0 4ca31b49
4bf26f07 b3f40079 159f287c 697bc083
10ee0d7b 5b44be4c 478f4fec 29e9cfe6
daf93540 a68e3a49 6c5fe8d1 326e4ae2
5b263178 ade6fe54 21654537 092d2ec6
9b54f32b c387e4f4 e10a1a4f 1163550e
72a76d62 68184f02 1dc9bf9b 48bb8af8
bb9f265a 46394c9d 76cf8c25 3e29e37b
5dd49bfe 46f99221 67cd02de f853c82b
cc2a8ce6 fba293a2 80244352 0a1cd546
869dafff bff4f66c 515f8447 52703790
3f980ee9 90130e16 644ccb54 507e309a
d7a587db 37851a69 6afcae5b 6a232408
49dde286 a02a8cd6 c27e2937 dc2bdeff
55165df1 57abf2a7 7b0e9004 952c71c2
c466ce4f 6b6db2d4 a6029283 67f66790
1ba81256 03c7cd20 12380df7 7760ecd1
f97eb3c7 16c82725 8d0e9fed 31531688
97b664e8 47177af7 249567b5 1fbff2de
caeb334d 14f91b1a 1e58fd0c a7aa76d8
255ba7fd ad99390f c146943c 06

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 2, Part G Page 927
Sample Data

1.2.13 Sample data 13 (3-DH5, Peripheral → Central)

Payload byte length: 3fd

K: 7b04934f d9d25294 ef1a014d a094f0b5
Payload counter: 006267f78b
Zero-length ACL-U Continuation: 0
Direction: 1
Initialization vector: 74ca58e8 b136986f
LT_ADDR: 1
Packet Type: f
LLID: 2
Payload: 6d42614c 50694940 209c8bd5 5be57733
3ec1066a 76cb602e a58ced25 f98ceb94
58bc3db4 e7c46bb9 e23f9220 68bfca00
c1da8f08 1c10e526 0ea37fab 3d91be9f
3a4e68e9 006cca11 fdc76c59 1e20769d
e1e34385 af105dab 4d44eda7 eacd1974
5414d5a9 568d67af c05aedd9 6726a130
7ebe31fd 81881237 c953d2a5 42c57c3b
019691ef 911953fb 39264712 c61e3e5e
21286421 85891af5 bf8ca291 59c30596
11bbe5cd 8f88a7bb b8afd34a 4211eed5
850ca781 cc9cf5b9 06d5fced 79d35981
39a1a239 2965b0d5 c6c03a9f e22433ba
08e7aac7 7d207392 b3486ead dd5c81c6
5454d575 edd91892 0a2f0fe9 f6d5c037
fec1272e f22c9aa0 d02b3412 81f60847
887cd303 a82937cf ded4be2d 139342ce
bd09041a f5eaa675 4307eb2d 20a60f7b
1b944afe e3ae1a6f 476021c7 d30d300e
44f9eaa2 42e8cb7a 6d74d5b5 0f2d6c1b
d436f44f 1ddf8579 70821a65 117e1200
e0270f00 7cbe6bb2 020ec332 bc464299
20131eb1 e8864206 3b4a8324 522cfe0a
a5209fd7 3f11a1e0 da00c945 835b6b5f
ec9eaea9 9d177dc0 cbd2efe8 21b388c3
78b2e137 c84f37a4 5599ffc0 a9106204
5ed1439f 7e67ea1d 6ab024f7 247e85df
bf15d19c b0f488d2 cb06bed9 644ec34c
2e69f752 4af38319 81c7556e 359bfaf5
22a00878 4ce3e7e2 362698ea 6c00001d

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 2, Part G Page 928
Sample Data

fdf0936d 2cf7a318 ed4f0447 ad506cdd

c2fcf8b7 328bb527 063859b5 f60819d3
eebdd291 0a12c6af 1c670a30 38fd9e2c
4a6a3ad7 a51982bd 8d4fabf5 a8c16517
831661b0 09405052 9fba337b 2b3544cf
6811a761 093afd66 8b154a21 a5941b88
a482c5ce f04b18c1 c2e67d7d f90c3a4d
d4ee12fe 4b734174 d3ee8b0c 1ade74eb
237710da 4694764b 7cce26c4 7a2570bf
30bb18c7 6571ab05 26892de7 b5d62840
7f300971 14d6014b 2ca566b3 d6ad1ef5
96e552e6 defc287e 6a5a5c16 be31d26a
392e1570 a9f9e0b3 32d223e5 b15407f3
41cc55f8 3296f3f5 175ebece 580a3f24
49494406 fa75e051 c829441b ce7cba98
cb7ea85d 8031787d 9495b971 c6925f64
2726ef05 932d3f1a 14a9bd1a d88a9b31
6f54d80e 9fe31dcf c94c1f6a 92cc2c82
60bd9296 e075b884 2976b667 041800df
520e7a28 e5b9314a 0bb93966 1aba4643
829544e2 d69f255c ce5bfa89 9a4704f3
be803081 fbc36f5c 65fb13c8 69fc770a
07cbc8ff 50b8dbe3 b171e9f9 ebc8cf22
49127607 32973806 95979b3c d75a3f8f
f933a408 d4945f63 96755d6e 493b554b
58e78f5b a21d31b3 bbcddf62 83e94233
15a3bea8 3a6ff73f f02809da 3c6d8208
acfd6f05 b62bb5a5 91f1e4d5 4b84d357
2f00672a 3e3c434c 1736072b 45f6370c
bb46706b 56a57e86 3ed2217a 816e5c09
1e2895f7 89b57c5e c0a67011 d5f2f69d
6dac3941 3bc897dc cb42d3bc ffda31e0
e961f3fb e4f40041 69e86cc0 530e891c
7665902a 1ce0804c 921780ae e2

B0: 498bf767 62206f98 36b1e858 ca7403fd

B1: 00790200 00000000 00000000 00000000
B2: 6d42614c 50694940 209c8bd5 5be57733
B3: 3ec1066a 76cb602e a58ced25 f98ceb94
B4: 58bc3db4 e7c46bb9 e23f9220 68bfca00
B5: c1da8f08 1c10e526 0ea37fab 3d91be9f

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 2, Part G Page 929
Sample Data

B6: 3a4e68e9 006cca11 fdc76c59 1e20769d

B7: e1e34385 af105dab 4d44eda7 eacd1974
B8: 5414d5a9 568d67af c05aedd9 6726a130
B9: 7ebe31fd 81881237 c953d2a5 42c57c3b
B10: 019691ef 911953fb 39264712 c61e3e5e
B11: 21286421 85891af5 bf8ca291 59c30596
B12: 11bbe5cd 8f88a7bb b8afd34a 4211eed5
B13: 850ca781 cc9cf5b9 06d5fced 79d35981
B14: 39a1a239 2965b0d5 c6c03a9f e22433ba
B15: 08e7aac7 7d207392 b3486ead dd5c81c6
B16: 5454d575 edd91892 0a2f0fe9 f6d5c037
B17: fec1272e f22c9aa0 d02b3412 81f60847
B18: 887cd303 a82937cf ded4be2d 139342ce
B19: bd09041a f5eaa675 4307eb2d 20a60f7b
B20: 1b944afe e3ae1a6f 476021c7 d30d300e
B21: 44f9eaa2 42e8cb7a 6d74d5b5 0f2d6c1b
B22: d436f44f 1ddf8579 70821a65 117e1200
B23: e0270f00 7cbe6bb2 020ec332 bc464299
B24: 20131eb1 e8864206 3b4a8324 522cfe0a
B25: a5209fd7 3f11a1e0 da00c945 835b6b5f
B26: ec9eaea9 9d177dc0 cbd2efe8 21b388c3
B27: 78b2e137 c84f37a4 5599ffc0 a9106204
B28: 5ed1439f 7e67ea1d 6ab024f7 247e85df
B29: bf15d19c b0f488d2 cb06bed9 644ec34c
B30: 2e69f752 4af38319 81c7556e 359bfaf5
B31: 22a00878 4ce3e7e2 362698ea 6c00001d
B32: fdf0936d 2cf7a318 ed4f0447 ad506cdd
B33: c2fcf8b7 328bb527 063859b5 f60819d3
B34: eebdd291 0a12c6af 1c670a30 38fd9e2c
B35: 4a6a3ad7 a51982bd 8d4fabf5 a8c16517
B36: 831661b0 09405052 9fba337b 2b3544cf
B37: 6811a761 093afd66 8b154a21 a5941b88
B38: a482c5ce f04b18c1 c2e67d7d f90c3a4d
B39: d4ee12fe 4b734174 d3ee8b0c 1ade74eb
B40: 237710da 4694764b 7cce26c4 7a2570bf
B41: 30bb18c7 6571ab05 26892de7 b5d62840
B42: 7f300971 14d6014b 2ca566b3 d6ad1ef5
B43: 96e552e6 defc287e 6a5a5c16 be31d26a
B44: 392e1570 a9f9e0b3 32d223e5 b15407f3
B45: 41cc55f8 3296f3f5 175ebece 580a3f24
B46: 49494406 fa75e051 c829441b ce7cba98

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 2, Part G Page 930
Sample Data

B47: cb7ea85d 8031787d 9495b971 c6925f64

B48: 2726ef05 932d3f1a 14a9bd1a d88a9b31
B49: 6f54d80e 9fe31dcf c94c1f6a 92cc2c82
B50: 60bd9296 e075b884 2976b667 041800df
B51: 520e7a28 e5b9314a 0bb93966 1aba4643
B52: 829544e2 d69f255c ce5bfa89 9a4704f3
B53: be803081 fbc36f5c 65fb13c8 69fc770a
B54: 07cbc8ff 50b8dbe3 b171e9f9 ebc8cf22
B55: 49127607 32973806 95979b3c d75a3f8f
B56: f933a408 d4945f63 96755d6e 493b554b
B57: 58e78f5b a21d31b3 bbcddf62 83e94233
B58: 15a3bea8 3a6ff73f f02809da 3c6d8208
B59: acfd6f05 b62bb5a5 91f1e4d5 4b84d357
B60: 2f00672a 3e3c434c 1736072b 45f6370c
B61: bb46706b 56a57e86 3ed2217a 816e5c09
B62: 1e2895f7 89b57c5e c0a67011 d5f2f69d
B63: 6dac3941 3bc897dc cb42d3bc ffda31e0
B64: e961f3fb e4f40041 69e86cc0 530e891c
B65: 7665902a 1ce0804c 921780ae e2000000

Y0: b7b63a11 d2ff710c 5d821353 120fe064

Y1: 31635446 16989968 dbd392df 77ab44b2
Y2: fe667b06 7ef88846 a74b5119 476c5ca9
Y3: 03db41e6 902e40ff fa6d86e6 92a2c630
Y4: 0a1c2366 e55a2cd0 701fe43d 34becee0
Y5: 8e8c6fd4 dfb9071b 3feb7938 defa835e
Y6: 61b2fe53 6f876519 43698e8d f7ca327e
Y7: 3705a0c3 39989f81 377afb1b d9f01569
Y8: d96211f1 959c7a64 3ee0a727 b4ad2ae2
Y9: 7cdc85ed d204d4ce 33665710 bcd4f7f1
Y10: 9a6d0fed cfde263e 62eddf28 fab38c98
Y11: 98915f60 f70cc4df 74ac9931 1a4f2990
Y12: 4a88113a 754243af c00324ef 117678f7
Y13: a0f620c0 b3a903fa 648210ef 63eef46f
Y14: f526db99 20291004 225a762f 129e58ff
Y15: 8ee96b03 494a8b18 1e1194b7 babb8a27
Y16: 59b69b74 0455f2ac 65f9c651 34ceae70
Y17: 9c0a2ee9 64e57ffb 57bcd10d f3c8a567
Y18: ee339202 c09ff61a 72fc2a2f 183b370e
Y19: 57b1bac2 63769a7b db0eac84 6b49aca4
Y20: 20e3786a e9526a50 cdc9dcc5 c579a3bf

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 2, Part G Page 931
Sample Data

Y21: 6bc61121 214dd538 aa3cc0a3 9abab72a

Y22: 5a42d758 fb854450 55199e78 ba42ca62
Y23: fc9cf1f6 58691ce8 01ca2501 25223403
Y24: cfa5ab4f 90431bc8 f832f148 db633e8e
Y25: 7254ae54 60a7dcbd 3470df60 7af3c1ca
Y26: 436205c4 763e68ab 390907e2 da236e8d
Y27: 6738b5db e1b8b739 d5eccc0d 47ab511c
Y28: 65a1dd1e f661d376 1c917ea7 f171dc7e
Y29: 55a82897 a7d19703 87e783cd 52ddecd8
Y30: 7e0ae507 5c9b8dc1 e4981e02 377472b5
Y31: 035d4dd3 493a84b5 0c2bd3ae 2f9f728b
Y32: 34441d1c cd9400d9 164c74b3 5021a97e
Y33: 4c5c3051 0c1d8571 782993c0 3a7a9e13
Y34: 63453300 3bc6cc3d 53a36db3 79f2b047
Y35: e3630826 7ac4040c b087d657 953a4560
Y36: 967ef5bd bf821572 466bf00f aefd751b
Y37: 4f19c371 c5da0b9f 4bc55452 05dab223
Y38: 6fa54807 d40a41ca 3c41bf6a 890d56c9
Y39: fb2d42e7 013c1e0d 17aa1e01 090fe190
Y40: f6104499 02efdc76 6cae97b7 f27d8765
Y41: 5d9ebc6d 22b48c7c 276b9670 636433cb
Y42: d85fb261 60c02b6d 348e6616 8d79f268
Y43: c66ab5e0 7fc159dd 07f41e8d 511989d0
Y44: e18f58b0 c831550b 2aa0f002 51899793
Y45: c36620e2 7a396916 74cc358f 36d4ae68
Y46: 6b1cb137 b69d021f 764150fd 5b29744f
Y47: cc3b7f27 a69a9666 6919d755 6893a18f
Y48: b1e1c8f8 936c88d1 b2540bf8 e82032d9
Y49: 045ad0f2 638df0e6 79357e37 0240dd8a
Y50: 455f563e 5cf94329 a4efbede ac30d09f
Y51: f6e8f947 ec78897c 96fe5879 a1519ede
Y52: f2a0a601 d7765bb7 0a41a0b6 fae10c36
Y53: 86bcc098 bcd1e930 7b008ec5 6c027ccb
Y54: 8f0f380b c973be6a c88d8a4d 45f86b0c
Y55: 2b5ca348 5bb4015a e9b907f6 1cc77400
Y56: a2755ca8 2c52702b ed08736d ef68938a
Y57: d92292d5 0a0cf7cd 79d95799 6c6dff88
Y58: 469d1262 83afb58c 9810c732 a4a36a79
Y59: bb563499 7ca1c960 8357c393 60148fff
Y60: 83e8dbc7 67e501de 080aac2d 0501b9ec
Y61: 956f13a2 c14f9476 d268896c f24ed47a

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 2, Part G Page 932
Sample Data

Y62: 1dfcb90c 4b088e40 830784fe f9dbe7c6

Y63: e7c8898d 9c033db9 117191d0 57d0d5cb
Y64: 6a187312 e7bc05cc bd8e8199 e9e7348d
Y65: 682ec5d4 8fec944f 0e02eeb0 bcf11786

T: 682ec5d4

CTR0: 018bf767 62206f98 36b1e858 ca740000

CTR1: 018bf767 62206f98 36b1e858 ca740001
CTR2: 018bf767 62206f98 36b1e858 ca740002
CTR3: 018bf767 62206f98 36b1e858 ca740003
CTR4: 018bf767 62206f98 36b1e858 ca740004
CTR5: 018bf767 62206f98 36b1e858 ca740005
CTR6: 018bf767 62206f98 36b1e858 ca740006
CTR7: 018bf767 62206f98 36b1e858 ca740007
CTR8: 018bf767 62206f98 36b1e858 ca740008
CTR9: 018bf767 62206f98 36b1e858 ca740009
CTR10: 018bf767 62206f98 36b1e858 ca74000a
CTR11: 018bf767 62206f98 36b1e858 ca74000b
CTR12: 018bf767 62206f98 36b1e858 ca74000c
CTR13: 018bf767 62206f98 36b1e858 ca74000d
CTR14: 018bf767 62206f98 36b1e858 ca74000e
CTR15: 018bf767 62206f98 36b1e858 ca74000f
CTR16: 018bf767 62206f98 36b1e858 ca740010
CTR17: 018bf767 62206f98 36b1e858 ca740011
CTR18: 018bf767 62206f98 36b1e858 ca740012
CTR19: 018bf767 62206f98 36b1e858 ca740013
CTR20: 018bf767 62206f98 36b1e858 ca740014
CTR21: 018bf767 62206f98 36b1e858 ca740015
CTR22: 018bf767 62206f98 36b1e858 ca740016
CTR23: 018bf767 62206f98 36b1e858 ca740017
CTR24: 018bf767 62206f98 36b1e858 ca740018
CTR25: 018bf767 62206f98 36b1e858 ca740019
CTR26: 018bf767 62206f98 36b1e858 ca74001a
CTR27: 018bf767 62206f98 36b1e858 ca74001b
CTR28: 018bf767 62206f98 36b1e858 ca74001c
CTR29: 018bf767 62206f98 36b1e858 ca74001d
CTR30: 018bf767 62206f98 36b1e858 ca74001e
CTR31: 018bf767 62206f98 36b1e858 ca74001f
CTR32: 018bf767 62206f98 36b1e858 ca740020
CTR33: 018bf767 62206f98 36b1e858 ca740021

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 2, Part G Page 933
Sample Data

CTR34: 018bf767 62206f98 36b1e858 ca740022

CTR35: 018bf767 62206f98 36b1e858 ca740023
CTR36: 018bf767 62206f98 36b1e858 ca740024
CTR37: 018bf767 62206f98 36b1e858 ca740025
CTR38: 018bf767 62206f98 36b1e858 ca740026
CTR39: 018bf767 62206f98 36b1e858 ca740027
CTR40: 018bf767 62206f98 36b1e858 ca740028
CTR41: 018bf767 62206f98 36b1e858 ca740029
CTR42: 018bf767 62206f98 36b1e858 ca74002a
CTR43: 018bf767 62206f98 36b1e858 ca74002b
CTR44: 018bf767 62206f98 36b1e858 ca74002c
CTR45: 018bf767 62206f98 36b1e858 ca74002d
CTR46: 018bf767 62206f98 36b1e858 ca74002e
CTR47: 018bf767 62206f98 36b1e858 ca74002f
CTR48: 018bf767 62206f98 36b1e858 ca740030
CTR49: 018bf767 62206f98 36b1e858 ca740031
CTR50: 018bf767 62206f98 36b1e858 ca740032
CTR51: 018bf767 62206f98 36b1e858 ca740033
CTR52: 018bf767 62206f98 36b1e858 ca740034
CTR53: 018bf767 62206f98 36b1e858 ca740035
CTR54: 018bf767 62206f98 36b1e858 ca740036
CTR55: 018bf767 62206f98 36b1e858 ca740037
CTR56: 018bf767 62206f98 36b1e858 ca740038
CTR57: 018bf767 62206f98 36b1e858 ca740039
CTR58: 018bf767 62206f98 36b1e858 ca74003a
CTR59: 018bf767 62206f98 36b1e858 ca74003b
CTR60: 018bf767 62206f98 36b1e858 ca74003c
CTR61: 018bf767 62206f98 36b1e858 ca74003d
CTR62: 018bf767 62206f98 36b1e858 ca74003e
CTR63: 018bf767 62206f98 36b1e858 ca74003f
CTR64: 018bf767 62206f98 36b1e858 ca740040

S0: 1404487a 919e16c8 b3245d80 2b364231

S1: 82082cbc 57038db7 4823be9a 34e0a8d7
S2: 1b5f7526 d26fe763 7669dfee 63743d3a
S3: a3673258 5020c6cd d72bf517 accb632d
S4: 8a60ebb6 59c59ac1 a45a1ffd f54f7cd7
S5: 036f35c7 130c8a30 25e9da14 706df5bc
S6: e328cbb0 09c91d56 f010b40e e0fc5c3f
S7: 626d3d67 b53eb139 e155c9a2 df407b17
S8: d94e430b 829c7caf 289d2898 3c68aa5a

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 2, Part G Page 934
Sample Data

S9: d6343452 d92cb1ac b3fde90b e2f0789f

S10: 8ab8413c 0df18adf ae07a74f 82b3c91f
S11: 61bfac52 125b8fc4 eaac30f7 5a543821
S12: 68899f8f 2892931d 88b08926 7fa3cfc9
S13: 86b668c5 4ef24455 22a45f42 61aea816
S14: f57b4941 8332f0b3 7749ea30 53a711ee
S15: 593562a8 45c75a7c 70030f08 6fedd965
S16: f85e742f a743f353 6a22b384 be1dabdc
S17: ed7e317b 635deed3 e8b619f2 9bc65eb0
S18: 2035622d 94718ad6 c1631fa2 755883f4
S19: 40f50638 ad826c4a 3ca4fb88 467445ae
S20: e27eb632 0c2aee5c 9210b1c7 736fb897
S21: 711a9be3 c7054fa5 82ec70b6 028489e7
S22: 7b543081 c52e2cba 26400e6b 46642d0d
S23: d9564733 01fa7fae 7cfac2a7 239639e2
S24: 202ed696 6fbc2ecf f0982979 25bef3ea
S25: e2148e71 5935e2a5 bd175ee9 a799a549
S26: 77310821 6671e6dc 3a121369 a557aa4f
S27: 6d6c2659 06036f0c 1cec57ed 4a36158d
S28: b216aab3 be06fde0 262ae2ea e81cd2e5
S29: 0b56812e 52b653f9 0e27362e dd7dcbd4
S30: df590fb5 d38ea1cd f8eb2d5b 3d474253
S31: 6493924c 073da4bf d5658181 48b52d76
S32: e8491efc f7d18b0a 027f656e c6886a7d
S33: eb26ca54 5d221211 73a037ec e43053e9
S34: fa2f9edf 4e9d9c1c aa6e786c e743c1c0
S35: cf833d58 0d508e0e da69560a 66d3c03b
S36: f5922c3b 4382f00f 9b64ebb1 b2accbb0
S37: 9a3faeeb 69fdb9e1 3a025f2d 299c177e
S38: 376d0236 76cfe2b1 1c0e342a afe6418b
S39: 1d2a5ab1 7dc816ee 6c37e855 07f11bd7
S40: c33e7e9f 7669ad90 44625f47 1155c411
S41: bae0615e 9d48b215 0b9e7065 04b09ef7
S42: 606e0db2 17e5251d ba08c3db f20915fd
S43: f28282de b65b5dcc 0b88f0d0 20fa4810
S44: 701e67ab aa5af6c2 1bf15c6f ea339a58
S45: bd5176ce 91b3298f fe989ff0 c6ff991f
S46: 9eb857c4 bfec9af6 b1c78acd f3aabd69
S47: 7acfb2d7 217154f8 09cd5f4c 9728c6cc
S48: 66b07ebe 3665809d 7b855491 4bf90528
S49: 91a82a7d f3744bd0 7fc8850c 08554c8d

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 2, Part G Page 935
Sample Data

S50: 0fa45385 3cca72db eaa031b2 65c9d590

S51: 2bf70aa1 dab678d7 f8d8a2b2 88dc22da
S52: 1633856d aacda2bb 94f1d66b 0f4ad876
S53: b09b906a ff48f724 b9524495 409a0a62
S54: 7cda29ed 1e6f903d b7a9f4c5 26c28530
S55: f5338a50 74e0c5ed 214c4380 70886009
S56: 9cd2fb3c f8e8d55f 93a10ccd f288eead
S57: 9f1b72ba 2e506062 9dcc02a2 a3536e0e
S58: ea50be8b e9ffe171 c6f64b44 1357e68e
S59: 5d3c94b8 ef4051ff 79cd4200 3d9a3208
S60: 14267f84 ee8d7e71 df5d46ec 361f1648
S61: 7871fd55 dbcbcf6c 20c2902d 58935861
S62: 33b892d6 63807bf4 ddc0cc2b 3e037547
S63: 611a7ca9 85d3571a 1b6a0917 40795e7c
S64: ef6adb06 6b6cb075 5ac5a39a 08ae7e7b

MIC: 7c2a8dae
Encrypted payload: ef4a4df0 076ac4f7 68bf354f 6f05dfe4
259e734c a4a4874d d3e532cb 9af8d6ae
fbdb0fec b7e4ad74 35146737 c474a92d
4bba64be 45d57fe7 aaf96056 c8dec248
39215d2e 13604021 d82eb64d 6e4d8321
02cb8835 a6d940fd bd5459a9 0a31454b
3679e8ce e3b3d696 210f247b b866da27
a7f072f6 03146e98 e1cefa3d 7eadd661
d7a2a5bd 4835e257 8adbae19 24ee46c1
ab90251d 8878902a 118b05de db70cc89
7004499f 9dd3287f 5203e3bd 1845d6f4
ed85380e e40e66a4 8e6575cb 06709648
bf17cafc 6797f480 e46465dd 838a9bac
fd9ce386 fe128321 c401849d 8efb9028
0d61b7dd a81e42ee 7a2c00e1 99381952
069f5301 556f69f3 ba098796 3feba39b
6502e278 cb74d91c 3662a7df 88551c7e
9d3c6637 619b2ca3 8264f48f 55fe8c8f
5b614cc6 4e2c7625 7bc4da4f 957975a0
a6875c90 4ec22526 ff646472 7c42d48c
a52c6fac dadacadc f26e6ad3 13fa9be7
9b733f81 b9904708 244ecd59 fa226f94
f9455982 e97c3da8 47b04183 71bac7e8
850e4941 50ad8f2f 2a98e03c a6e598b5

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 2, Part G Page 936
Sample Data

0e8a20d8 c4229f65 76c5b101 862a2d8a

0f83e916 ae3ed178 6f8beca9 0c47c84b
33bd65c6 78648511 765c731a 6e489052
0d037b2f 0ef27532 ed2c5c33 8c5211a9
253f767c 1845d0e0 8fe06340 e8e63121
fdf907cd 9f6d462f cecdb5b1 5147424e
99630121 2bca07a7 382a85c6 e5e541ab
2ab5e64b c55a3e2d 04473cdb 308073ae
059b18c5 5730d4be 6fc73ddc dccdcdc5
b045a408 eb841ea1 2721d399 4f82a4d7
4c955ce8 0410de5c 45d36571 4de684f4
9d838b5a 4ab80d69 1071a190 1738d038
3ebd6b25 99b6a120 f8e42250 d0902d33
e38310c8 3dbca3c5 cfe0bf26 b5383560
3e5d4a6b 3b5c60a5 10f9ce91 7dd46b68
f3856658 13180695 62eb72a0 a483ec51
c5d0682f 899eb35e 273b16d6 d21d8002
f68b5f54 c9190d63 d0529fcd 4c38c797
cbac97ae 1fa2bd7f 395ad335 91ae4fe3
31d23253 98cc0537 0cafe2a1 b239a57c
f41832c8 6bc6c9de 36b1dbeb 08832387
55c6ff99 3fdde28b 255233bc 3538e20d
5de95dd2 b25c6be2 1d64e256 4fa25dfd
09e4a6b0 a9869d52 b2c94bfb d93529aa
f115b8eb 1301f354 56be336b 0c4d4c52
5daa29ad d9734391 e11908d4 7f7393d3
a9624e43 0c295d8b 3683583b 129b2629
a8b3b5ec 510ecde7 f10ac5a3 66b6af7c
b7505895 aff02cc7 0823ad6c ab52c540
35c85fea 2cf8a83b 223e6ff9 f198babf
0c002e58 a0749a8e b7391eee 39b33542
c4357467 5af5e4ec 286cd3af 7161ac9e
8ab8cc12 143f975d 6de40b78 9f3eec06
46add18e 5fd454d4 5707af91 58d335d9
723cf392 d17c12b3 6efb452b 786c0504
af600fef b82800f7 e18f6796 b7714a41
665968a2 527eb332 e064e03c 8d61aefc
5e14ab97 5848ec28 16821f97 c1d944a7
887b8f52 6127575b 728265d7 1377d760
990f4b2c 778c3039 c8d22334 ea

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 2, Part G Page 937
Sample Data

1.2.14 Sample data 14 (EV3)

Payload byte length: 1e

K: 972b7dcd be8942b7 d8fdc356 a5590aca
CLK[27:1]: 030b5a8f
dayCounter: 061a
Initialization vector: 70b690bd dfe9630f
LT_ADDR: 1
Packet Type: 7
Payload: 4625f778 578290f9 0ee83576 b3f8a898
faff3fe4 5db812b2 e189297a fd89

CTR0: 018f5a0b d3700f63 e9dfbd90 b6700000

CTR1: 018f5a0b d3700f63 e9dfbd90 b6700001
CTR2: 018f5a0b d3700f63 e9dfbd90 b6700002

Encrypted payload: 76637937 69b2ba4c 41704100 d6c4602a

dbae2a87 f77a9fdb a0c56d2c b532

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 2, Part G Page 938
Sample Data

2 FREQUENCY HOPPING SAMPLE DATA

The section contains three sets of sample data showing the basic and adapted hopping
schemes for different combinations of addresses and initial clock values.

2.1 First set

Hop sequence {k} for Page Scan and Inquiry Scan substates:
CLKN start: 0x0000000
UAP / LAP: 0x00000000
#ticks: 0000 | 1000 | 2000 | 3000 | 4000 | 5000 | 6000 | 7000 |
--------------------------------------------------------
0x0000000: 0 | 2 | 4 | 6 | 8 | 10 | 12 | 14 |
0x0008000: 16 | 18 | 20 | 22 | 24 | 26 | 28 | 30 |
0x0010000: 32 | 34 | 36 | 38 | 40 | 42 | 44 | 46 |
0x0018000: 48 | 50 | 52 | 54 | 56 | 58 | 60 | 62 |
0x0020000: 0 | 2 | 4 | 6 | 8 | 10 | 12 | 14 |
0x0028000: 16 | 18 | 20 | 22 | 24 | 26 | 28 | 30 |
0x0030000: 32 | 34 | 36 | 38 | 40 | 42 | 44 | 46 |
0x0038000: 48 | 50 | 52 | 54 | 56 | 58 | 60 | 62 |

Hop sequence {k} for Page and Inquiry substates:

CLKE start: 0x0000000
UAP / LAP: 0x00000000
#ticks: 00 01 02 03 | 04 05 06 07 | 08 09 0a 0b | 0c 0d 0e 0f |
--------------------------------------------------------
0x0000000: 48 50 09 13 | 52 54 41 45 | 56 58 11 15 | 60 62 43 47 |
0x0000010: 00 02 64 68 | 04 06 17 21 | 08 10 66 70 | 12 14 19 23 |
0x0000020: 48 50 09 13 | 52 54 41 45 | 56 58 11 15 | 60 62 43 47 |
0x0000030: 00 02 64 68 | 04 06 17 21 | 08 10 66 70 | 12 14 19 23 |
...
0x0001000: 48 18 09 05 | 20 22 33 37 | 24 26 03 07 | 28 30 35 39 |
0x0001010: 32 34 72 76 | 36 38 25 29 | 40 42 74 78 | 44 46 27 31 |
0x0001020: 48 18 09 05 | 20 22 33 37 | 24 26 03 07 | 28 30 35 39 |
0x0001030: 32 34 72 76 | 36 38 25 29 | 40 42 74 78 | 44 46 27 31 |
...
0x0002000: 16 18 01 05 | 52 54 41 45 | 56 58 11 15 | 60 62 43 47 |
0x0002010: 00 02 64 68 | 04 06 17 21 | 08 10 66 70 | 12 14 19 23 |
0x0002020: 16 18 01 05 | 52 54 41 45 | 56 58 11 15 | 60 62 43 47 |
0x0002030: 00 02 64 68 | 04 06 17 21 | 08 10 66 70 | 12 14 19 23 |
...
0x0003000: 48 50 09 13 | 52 22 41 37 | 24 26 03 07 | 28 30 35 39 |

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 2, Part G Page 939
Sample Data

0x0003010: 32 34 72 76 | 36 38 25 29 | 40 42 74 78 | 44 46 27 31 |
0x0003020: 48 50 09 13 | 52 22 41 37 | 24 26 03 07 | 28 30 35 39 |
0x0003030: 32 34 72 76 | 36 38 25 29 | 40 42 74 78 | 44 46 27 31 |

Hop sequence {k} for Peripheral Response substate:

CLKN* = 0x0000010
UAP / LAP: 0x00000000
#ticks: 00 | 02 04 | 06 08 | 0a 0c | 0e 10 | 12 14 | 16 18 | 1a 1c | 1e
----------------------------------------------------------------
0x0000012: 64 | 02 68 | 04 17 | 06 21 | 08 66 | 10 70 | 12 19 | 14 23 | 16
0x0000032: 01 | 18 05 | 20 33 | 22 37 | 24 03 | 26 07 | 28 35 | 30 39 | 32
0x0000052: 72 | 34 76 | 36 25 | 38 29 | 40 74 | 42 78 | 44 27 | 46 31 | 48
0x0000072: 09 | 50 13 | 52 41 | 54 45 | 56 11 | 58 15 | 60 43 | 62 47 | 00

Hop sequence {k} for Central Response substate:

Offset value: 24
CLKE* = 0x0000012
UAP / LAP: 0x00000000
#ticks: 00 02 | 04 06 | 08 0a | 0c 0e | 10 12 | 14 16 | 18 1a | 1c 1e |
----------------------------------------------------------------
0x0000014: 02 68 | 04 17 | 06 21 | 08 66 | 10 70 | 12 19 | 14 23 | 16 01 |
0x0000034: 18 05 | 20 33 | 22 37 | 24 03 | 26 07 | 28 35 | 30 39 | 32 72 |
0x0000054: 34 76 | 36 25 | 38 29 | 40 74 | 42 78 | 44 27 | 46 31 | 48 09 |
0x0000074: 50 13 | 52 41 | 54 45 | 56 11 | 58 15 | 60 43 | 62 47 | 00 64 |

Hop sequence {k} for Connection state (Basic channel hopping sequence;
ie, non-AFH):
CLK start: 0x0000010
UAP/LAP: 0x00000000
#ticks: 00 02 | 04 06 | 08 0a | 0c 0e | 10 12 | 14 16 | 18 1a | 1c 1e |
----------------------------------------------------------------
0x0000010: 08 66 | 10 70 | 12 19 | 14 23 | 16 01 | 18 05 | 20 33 | 22 37 |
0x0000030: 24 03 | 26 07 | 28 35 | 30 39 | 32 72 | 34 76 | 36 25 | 38 29 |
0x0000050: 40 74 | 42 78 | 44 27 | 46 31 | 48 09 | 50 13 | 52 41 | 54 45 |
0x0000070: 56 11 | 58 15 | 60 43 | 62 47 | 32 17 | 36 19 | 34 49 | 38 51 |
0x0000090: 40 21 | 44 23 | 42 53 | 46 55 | 48 33 | 52 35 | 50 65 | 54 67 |
0x00000b0: 56 37 | 60 39 | 58 69 | 62 71 | 64 25 | 68 27 | 66 57 | 70 59 |
0x00000d0: 72 29 | 76 31 | 74 61 | 78 63 | 01 41 | 05 43 | 03 73 | 07 75 |
0x00000f0: 09 45 | 13 47 | 11 77 | 15 00 | 64 49 | 66 53 | 68 02 | 70 06 |
0x0000110: 01 51 | 03 55 | 05 04 | 07 08 | 72 57 | 74 61 | 76 10 | 78 14 |
0x0000130: 09 59 | 11 63 | 13 12 | 15 16 | 17 65 | 19 69 | 21 18 | 23 22 |
0x0000150: 33 67 | 35 71 | 37 20 | 39 24 | 25 73 | 27 77 | 29 26 | 31 30 |
0x0000170: 41 75 | 43 00 | 45 28 | 47 32 | 17 02 | 21 04 | 19 34 | 23 36 |
0x0000190: 33 06 | 37 08 | 35 38 | 39 40 | 25 10 | 29 12 | 27 42 | 31 44 |

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 2, Part G Page 940
Sample Data

0x00001b0: 41 14 | 45 16 | 43 46 | 47 48 | 49 18 | 53 20 | 51 50 | 55 52 |
0x00001d0: 65 22 | 69 24 | 67 54 | 71 56 | 57 26 | 61 28 | 59 58 | 63 60 |
0x00001f0: 73 30 | 77 32 | 75 62 | 00 64 | 49 34 | 51 42 | 57 66 | 59 74 |
0x0000210: 53 36 | 55 44 | 61 68 | 63 76 | 65 50 | 67 58 | 73 03 | 75 11 |
0x0000230: 69 52 | 71 60 | 77 05 | 00 13 | 02 38 | 04 46 | 10 70 | 12 78 |
0x0000250: 06 40 | 08 48 | 14 72 | 16 01 | 18 54 | 20 62 | 26 07 | 28 15 |
0x0000270: 22 56 | 24 64 | 30 09 | 32 17 | 02 66 | 06 74 | 10 19 | 14 27 |
0x0000290: 04 70 | 08 78 | 12 23 | 16 31 | 18 03 | 22 11 | 26 35 | 30 43 |
0x00002b0: 20 07 | 24 15 | 28 39 | 32 47 | 34 68 | 38 76 | 42 21 | 46 29 |
0x00002d0: 36 72 | 40 01 | 44 25 | 48 33 | 50 05 | 54 13 | 58 37 | 62 45 |
0x00002f0: 52 09 | 56 17 | 60 41 | 64 49 | 34 19 | 36 35 | 50 51 | 52 67 |
0x0000310: 38 21 | 40 37 | 54 53 | 56 69 | 42 27 | 44 43 | 58 59 | 60 75 |
0x0000330: 46 29 | 48 45 | 62 61 | 64 77 | 66 23 | 68 39 | 03 55 | 05 71 |
0x0000350: 70 25 | 72 41 | 07 57 | 09 73 | 74 31 | 76 47 | 11 63 | 13 00 |
0x0000370: 78 33 | 01 49 | 15 65 | 17 02 | 66 51 | 70 67 | 03 04 | 07 20 |
0x0000390: 68 55 | 72 71 | 05 08 | 09 24 | 74 59 | 78 75 | 11 12 | 15 28 |
0x00003b0: 76 63 | 01 00 | 13 16 | 17 32 | 19 53 | 23 69 | 35 06 | 39 22 |
0x00003d0: 21 57 | 25 73 | 37 10 | 41 26 | 27 61 | 31 77 | 43 14 | 47 30 |
0x00003f0: 29 65 | 33 02 | 45 18 | 49 34 | 19 04 | 21 08 | 23 20 | 25 24 |

Hop Sequence {k} for Connection state (Adapted channel hopping sequence
with all channels used; ie, AFH(79)):
CLK start: 0x0000010
ULAP: 0x00000000
Used Channels:0x7fffffffffffffffffff
#ticks: 00 02 | 04 06 | 08 0a | 0c 0e | 10 12 | 14 16 | 18 1a | 1c 1e |
---------------------------------------------------------------
0x0000010 08 08 | 10 10 | 12 12 | 14 14 | 16 16 | 18 18 | 20 20 | 22 22 |
0x0000030 24 24 | 26 26 | 28 28 | 30 30 | 32 32 | 34 34 | 36 36 | 38 38 |
0x0000050 40 40 | 42 42 | 44 44 | 46 46 | 48 48 | 50 50 | 52 52 | 54 54 |
0x0000070 56 56 | 58 58 | 60 60 | 62 62 | 32 32 | 36 36 | 34 34 | 38 38 |
0x0000090 40 40 | 44 44 | 42 42 | 46 46 | 48 48 | 52 52 | 50 50 | 54 54 |
0x00000b0 56 56 | 60 60 | 58 58 | 62 62 | 64 64 | 68 68 | 66 66 | 70 70 |
0x00000d0 72 72 | 76 76 | 74 74 | 78 78 | 01 01 | 05 05 | 03 03 | 07 07 |
0x00000f0 09 09 | 13 13 | 11 11 | 15 15 | 64 64 | 66 66 | 68 68 | 70 70 |
0x0000110 01 01 | 03 03 | 05 05 | 07 07 | 72 72 | 74 74 | 76 76 | 78 78 |
0x0000130 09 09 | 11 11 | 13 13 | 15 15 | 17 17 | 19 19 | 21 21 | 23 23 |
0x0000150 33 33 | 35 35 | 37 37 | 39 39 | 25 25 | 27 27 | 29 29 | 31 31 |
0x0000170 41 41 | 43 43 | 45 45 | 47 47 | 17 17 | 21 21 | 19 19 | 23 23 |
0x0000190 33 33 | 37 37 | 35 35 | 39 39 | 25 25 | 29 29 | 27 27 | 31 31 |
0x00001b0 41 41 | 45 45 | 43 43 | 47 47 | 49 49 | 53 53 | 51 51 | 55 55 |
0x00001d0 65 65 | 69 69 | 67 67 | 71 71 | 57 57 | 61 61 | 59 59 | 63 63 |
0x00001f0 73 73 | 77 77 | 75 75 | 00 00 | 49 49 | 51 51 | 57 57 | 59 59 |

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 2, Part G Page 941
Sample Data

0x0000210 53 53 | 55 55 | 61 61 | 63 63 | 65 65 | 67 67 | 73 73 | 75 75 |
0x0000230 69 69 | 71 71 | 77 77 | 00 00 | 02 02 | 04 04 | 10 10 | 12 12 |
0x0000250 06 06 | 08 08 | 14 14 | 16 16 | 18 18 | 20 20 | 26 26 | 28 28 |
0x0000270 22 22 | 24 24 | 30 30 | 32 32 | 02 02 | 06 06 | 10 10 | 14 14 |
0x0000290 04 04 | 08 08 | 12 12 | 16 16 | 18 18 | 22 22 | 26 26 | 30 30 |
0x00002b0 20 20 | 24 24 | 28 28 | 32 32 | 34 34 | 38 38 | 42 42 | 46 46 |
0x00002d0 36 36 | 40 40 | 44 44 | 48 48 | 50 50 | 54 54 | 58 58 | 62 62 |
0x00002f0 52 52 | 56 56 | 60 60 | 64 64 | 34 34 | 36 36 | 50 50 | 52 52 |
0x0000310 38 38 | 40 40 | 54 54 | 56 56 | 42 42 | 44 44 | 58 58 | 60 60 |
0x0000330 46 46 | 48 48 | 62 62 | 64 64 | 66 66 | 68 68 | 03 03 | 05 05 |
0x0000350 70 70 | 72 72 | 07 07 | 09 09 | 74 74 | 76 76 | 11 11 | 13 13 |
0x0000370 78 78 | 01 01 | 15 15 | 17 17 | 66 66 | 70 70 | 03 03 | 07 07 |
0x0000390 68 68 | 72 72 | 05 05 | 09 09 | 74 74 | 78 78 | 11 11 | 15 15 |
0x00003b0 76 76 | 01 01 | 13 13 | 17 17 | 19 19 | 23 23 | 35 35 | 39 39 |
0x00003d0 21 21 | 25 25 | 37 37 | 41 41 | 27 27 | 31 31 | 43 43 | 47 47 |
0x00003f0 29 29 | 33 33 | 45 45 | 49 49 | 19 19 | 21 21 | 23 23 | 25 25 |

Hop Sequence {k} for Connection state (Adapted channel hopping sequence
with channels 0 to 21 unused):
CLK start: 0x0000010
ULAP: 0x00000000
Used Channels:0x7fffffffffffffc00000
#ticks: 00 02 | 04 06 | 08 0a | 0c 0e | 10 12 | 14 16 | 18 1a | 1c 1e |
---------------------------------------------------------------
0x0000010 30 30 | 32 32 | 34 34 | 36 36 | 38 38 | 40 40 | 42 42 | 22 22 |
0x0000030 24 24 | 26 26 | 28 28 | 30 30 | 32 32 | 34 34 | 36 36 | 38 38 |
0x0000050 40 40 | 42 42 | 44 44 | 46 46 | 48 48 | 50 50 | 52 52 | 54 54 |
0x0000070 56 56 | 58 58 | 60 60 | 62 62 | 32 32 | 36 36 | 34 34 | 38 38 |
0x0000090 40 40 | 44 44 | 42 42 | 46 46 | 48 48 | 52 52 | 50 50 | 54 54 |
0x00000b0 56 56 | 60 60 | 58 58 | 62 62 | 64 64 | 68 68 | 66 66 | 70 70 |
0x00000d0 72 72 | 76 76 | 74 74 | 78 78 | 45 45 | 49 49 | 47 47 | 51 51 |
0x00000f0 53 53 | 57 57 | 55 55 | 59 59 | 64 64 | 66 66 | 68 68 | 70 70 |
0x0000110 45 45 | 47 47 | 49 49 | 51 51 | 72 72 | 74 74 | 76 76 | 78 78 |
0x0000130 53 53 | 55 55 | 57 57 | 59 59 | 61 61 | 63 63 | 65 65 | 23 23 |
0x0000150 33 33 | 35 35 | 37 37 | 39 39 | 25 25 | 27 27 | 29 29 | 31 31 |
0x0000170 41 41 | 43 43 | 45 45 | 47 47 | 61 61 | 65 65 | 63 63 | 23 23 |
0x0000190 33 33 | 37 37 | 35 35 | 39 39 | 25 25 | 29 29 | 27 27 | 31 31 |
0x00001b0 41 41 | 45 45 | 43 43 | 47 47 | 49 49 | 53 53 | 51 51 | 55 55 |
0x00001d0 65 65 | 69 69 | 67 67 | 71 71 | 57 57 | 61 61 | 59 59 | 63 63 |
0x00001f0 73 73 | 77 77 | 75 75 | 66 66 | 49 49 | 51 51 | 57 57 | 59 59 |
0x0000210 53 53 | 55 55 | 61 61 | 63 63 | 65 65 | 67 67 | 73 73 | 75 75 |
0x0000230 69 69 | 71 71 | 77 77 | 66 66 | 68 68 | 70 70 | 76 76 | 78 78 |
0x0000250 72 72 | 74 74 | 23 23 | 25 25 | 27 27 | 29 29 | 26 26 | 28 28 |

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 2, Part G Page 942
Sample Data

0x0000270 22 22 | 24 24 | 30 30 | 32 32 | 68 68 | 72 72 | 76 76 | 23 23 |
0x0000290 70 70 | 74 74 | 78 78 | 25 25 | 27 27 | 22 22 | 26 26 | 30 30 |
0x00002b0 29 29 | 24 24 | 28 28 | 32 32 | 34 34 | 38 38 | 42 42 | 46 46 |
0x00002d0 36 36 | 40 40 | 44 44 | 48 48 | 50 50 | 54 54 | 58 58 | 62 62 |
0x00002f0 52 52 | 56 56 | 60 60 | 64 64 | 34 34 | 36 36 | 50 50 | 52 52 |
0x0000310 38 38 | 40 40 | 54 54 | 56 56 | 42 42 | 44 44 | 58 58 | 60 60 |
0x0000330 46 46 | 48 48 | 62 62 | 64 64 | 66 66 | 68 68 | 34 34 | 36 36 |
0x0000350 70 70 | 72 72 | 38 38 | 40 40 | 74 74 | 76 76 | 42 42 | 44 44 |
0x0000370 78 78 | 32 32 | 46 46 | 48 48 | 66 66 | 70 70 | 34 34 | 38 38 |
0x0000390 68 68 | 72 72 | 36 36 | 40 40 | 74 74 | 78 78 | 42 42 | 46 46 |
0x00003b0 76 76 | 32 32 | 44 44 | 48 48 | 50 50 | 23 23 | 35 35 | 39 39 |
0x00003d0 52 52 | 25 25 | 37 37 | 41 41 | 27 27 | 31 31 | 43 43 | 47 47 |
0x00003f0 29 29 | 33 33 | 45 45 | 49 49 | 50 50 | 52 52 | 23 23 | 25 25 |

Hop Sequence {k} for Connection state (Adapted channel hopping sequence
with even channels used):
CLK start: 0x0000010
ULAP: 0x00000000
Used Channels:0x55555555555555555555
#ticks: 00 02 | 04 06 | 08 0a | 0c 0e | 10 12 | 14 16 | 18 1a | 1c 1e |
---------------------------------------------------------------
0x0000010 08 08 | 10 10 | 12 12 | 14 14 | 16 16 | 18 18 | 20 20 | 22 22 |
0x0000030 24 24 | 26 26 | 28 28 | 30 30 | 32 32 | 34 34 | 36 36 | 38 38 |
0x0000050 40 40 | 42 42 | 44 44 | 46 46 | 48 48 | 50 50 | 52 52 | 54 54 |
0x0000070 56 56 | 58 58 | 60 60 | 62 62 | 32 32 | 36 36 | 34 34 | 38 38 |
0x0000090 40 40 | 44 44 | 42 42 | 46 46 | 48 48 | 52 52 | 50 50 | 54 54 |
0x00000b0 56 56 | 60 60 | 58 58 | 62 62 | 64 64 | 68 68 | 66 66 | 70 70 |
0x00000d0 72 72 | 76 76 | 74 74 | 78 78 | 00 00 | 04 04 | 02 02 | 06 06 |
0x00000f0 08 08 | 12 12 | 10 10 | 14 14 | 64 64 | 66 66 | 68 68 | 70 70 |
0x0000110 00 00 | 02 02 | 04 04 | 06 06 | 72 72 | 74 74 | 76 76 | 78 78 |
0x0000130 08 08 | 10 10 | 12 12 | 14 14 | 16 16 | 18 18 | 20 20 | 22 22 |
0x0000150 32 32 | 34 34 | 36 36 | 38 38 | 24 24 | 26 26 | 28 28 | 30 30 |
0x0000170 40 40 | 42 42 | 44 44 | 46 46 | 16 16 | 20 20 | 18 18 | 22 22 |
0x0000190 32 32 | 36 36 | 34 34 | 38 38 | 24 24 | 28 28 | 26 26 | 30 30 |
0x00001b0 40 40 | 44 44 | 42 42 | 46 46 | 48 48 | 52 52 | 50 50 | 54 54 |
0x00001d0 64 64 | 68 68 | 66 66 | 70 70 | 56 56 | 60 60 | 58 58 | 62 62 |
0x00001f0 72 72 | 76 76 | 74 74 | 00 00 | 48 48 | 50 50 | 56 56 | 58 58 |
0x0000210 52 52 | 54 54 | 60 60 | 62 62 | 64 64 | 66 66 | 72 72 | 74 74 |
0x0000230 68 68 | 70 70 | 76 76 | 00 00 | 02 02 | 04 04 | 10 10 | 12 12 |
0x0000250 06 06 | 08 08 | 14 14 | 16 16 | 18 18 | 20 20 | 26 26 | 28 28 |
0x0000270 22 22 | 24 24 | 30 30 | 32 32 | 02 02 | 06 06 | 10 10 | 14 14 |
0x0000290 04 04 | 08 08 | 12 12 | 16 16 | 18 18 | 22 22 | 26 26 | 30 30 |
0x00002b0 20 20 | 24 24 | 28 28 | 32 32 | 34 34 | 38 38 | 42 42 | 46 46 |

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 2, Part G Page 943
Sample Data

0x00002d0 36 36 | 40 40 | 44 44 | 48 48 | 50 50 | 54 54 | 58 58 | 62 62 |
0x00002f0 52 52 | 56 56 | 60 60 | 64 64 | 34 34 | 36 36 | 50 50 | 52 52 |
0x0000310 38 38 | 40 40 | 54 54 | 56 56 | 42 42 | 44 44 | 58 58 | 60 60 |
0x0000330 46 46 | 48 48 | 62 62 | 64 64 | 66 66 | 68 68 | 00 00 | 02 02 |
0x0000350 70 70 | 72 72 | 04 04 | 06 06 | 74 74 | 76 76 | 08 08 | 10 10 |
0x0000370 78 78 | 78 78 | 12 12 | 14 14 | 66 66 | 70 70 | 00 00 | 04 04 |
0x0000390 68 68 | 72 72 | 02 02 | 06 06 | 74 74 | 78 78 | 08 08 | 12 12 |
0x00003b0 76 76 | 78 78 | 10 10 | 14 14 | 16 16 | 20 20 | 32 32 | 36 36 |
0x00003d0 18 18 | 22 22 | 34 34 | 38 38 | 24 24 | 28 28 | 40 40 | 44 44 |
0x00003f0 26 26 | 30 30 | 42 42 | 46 46 | 16 16 | 18 18 | 20 20 | 22 22 |

Hop Sequence {k} for Connection state (Adapted channel hopping sequence
with odd channels used):
CLK start: 0x0000010
ULAP: 0x00000000
Used Channels:0x2aaaaaaaaaaaaaaaaaaa
#ticks: 00 02 | 04 06 | 08 0a | 0c 0e | 10 12 | 14 16 | 18 1a | 1c 1e |
---------------------------------------------------------------
0x0000010 09 09 | 11 11 | 13 13 | 15 15 | 17 17 | 19 19 | 21 21 | 23 23 |
0x0000030 25 25 | 27 27 | 29 29 | 31 31 | 33 33 | 35 35 | 37 37 | 39 39 |
0x0000050 41 41 | 43 43 | 45 45 | 47 47 | 49 49 | 51 51 | 53 53 | 55 55 |
0x0000070 57 57 | 59 59 | 61 61 | 63 63 | 33 33 | 37 37 | 35 35 | 39 39 |
0x0000090 41 41 | 45 45 | 43 43 | 47 47 | 49 49 | 53 53 | 51 51 | 55 55 |
0x00000b0 57 57 | 61 61 | 59 59 | 63 63 | 65 65 | 69 69 | 67 67 | 71 71 |
0x00000d0 73 73 | 77 77 | 75 75 | 01 01 | 01 01 | 05 05 | 03 03 | 07 07 |
0x00000f0 09 09 | 13 13 | 11 11 | 15 15 | 65 65 | 67 67 | 69 69 | 71 71 |
0x0000110 01 01 | 03 03 | 05 05 | 07 07 | 73 73 | 75 75 | 77 77 | 01 01 |
0x0000130 09 09 | 11 11 | 13 13 | 15 15 | 17 17 | 19 19 | 21 21 | 23 23 |
0x0000150 33 33 | 35 35 | 37 37 | 39 39 | 25 25 | 27 27 | 29 29 | 31 31 |
0x0000170 41 41 | 43 43 | 45 45 | 47 47 | 17 17 | 21 21 | 19 19 | 23 23 |
0x0000190 33 33 | 37 37 | 35 35 | 39 39 | 25 25 | 29 29 | 27 27 | 31 31 |
0x00001b0 41 41 | 45 45 | 43 43 | 47 47 | 49 49 | 53 53 | 51 51 | 55 55 |
0x00001d0 65 65 | 69 69 | 67 67 | 71 71 | 57 57 | 61 61 | 59 59 | 63 63 |
0x00001f0 73 73 | 77 77 | 75 75 | 03 03 | 49 49 | 51 51 | 57 57 | 59 59 |
0x0000210 53 53 | 55 55 | 61 61 | 63 63 | 65 65 | 67 67 | 73 73 | 75 75 |
0x0000230 69 69 | 71 71 | 77 77 | 03 03 | 05 05 | 07 07 | 13 13 | 15 15 |
0x0000250 09 09 | 11 11 | 17 17 | 19 19 | 21 21 | 23 23 | 29 29 | 31 31 |
0x0000270 25 25 | 27 27 | 33 33 | 35 35 | 05 05 | 09 09 | 13 13 | 17 17 |
0x0000290 07 07 | 11 11 | 15 15 | 19 19 | 21 21 | 25 25 | 29 29 | 33 33 |
0x00002b0 23 23 | 27 27 | 31 31 | 35 35 | 37 37 | 41 41 | 45 45 | 49 49 |
0x00002d0 39 39 | 43 43 | 47 47 | 51 51 | 53 53 | 57 57 | 61 61 | 65 65 |
0x00002f0 55 55 | 59 59 | 63 63 | 67 67 | 37 37 | 39 39 | 53 53 | 55 55 |
0x0000310 41 41 | 43 43 | 57 57 | 59 59 | 45 45 | 47 47 | 61 61 | 63 63 |

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 2, Part G Page 944
Sample Data

0x0000330 49 49 | 51 51 | 65 65 | 67 67 | 69 69 | 71 71 | 03 03 | 05 05 |
0x0000350 73 73 | 75 75 | 07 07 | 09 09 | 77 77 | 01 01 | 11 11 | 13 13 |
0x0000370 03 03 | 01 01 | 15 15 | 17 17 | 69 69 | 73 73 | 03 03 | 07 07 |
0x0000390 71 71 | 75 75 | 05 05 | 09 09 | 77 77 | 03 03 | 11 11 | 15 15 |
0x00003b0 01 01 | 01 01 | 13 13 | 17 17 | 19 19 | 23 23 | 35 35 | 39 39 |
0x00003d0 21 21 | 25 25 | 37 37 | 41 41 | 27 27 | 31 31 | 43 43 | 47 47 |
0x00003f0 29 29 | 33 33 | 45 45 | 49 49 | 19 19 | 21 21 | 23 23 | 25 25 |

2.2 Second set

Hop sequence {k} for Page Scan and Inquiry Scan substates:
CLKN start: 0x0000000
ULAP: 0x2a96ef25
#ticks: 0000 | 1000 | 2000 | 3000 | 4000 | 5000 | 6000 | 7000 |
--------------------------------------------------------
0x0000000: 49 | 13 | 17 | 51 | 55 | 19 | 23 | 53 |
0x0008000: 57 | 21 | 25 | 27 | 31 | 74 | 78 | 29 |
0x0010000: 33 | 76 | 1 | 35 | 39 | 3 | 7 | 37 |
0x0018000: 41 | 5 | 9 | 43 | 47 | 11 | 15 | 45 |
0x0020000: 49 | 13 | 17 | 51 | 55 | 19 | 23 | 53 |
0x0028000: 57 | 21 | 25 | 27 | 31 | 74 | 78 | 29 |
0x0030000: 33 | 76 | 1 | 35 | 39 | 3 | 7 | 37 |
0x0038000: 41 | 5 | 9 | 43 | 47 | 11 | 15 | 45 |

Hop sequence {k} for Page and Inquiry substates:

CLKE start: 0x0000000
ULAP: 0x2a96ef25
#ticks: 00 01 02 03 | 04 05 06 07 | 08 09 0a 0b | 0c 0d 0e 0f |
--------------------------------------------------------
0x0000000: 41 05 10 04 | 09 43 06 16 | 47 11 18 12 | 15 45 14 32 |
0x0000010: 49 13 34 28 | 17 51 30 24 | 55 19 26 20 | 23 53 22 40 |
0x0000020: 41 05 10 04 | 09 43 06 16 | 47 11 18 12 | 15 45 14 32 |
0x0000030: 49 13 34 28 | 17 51 30 24 | 55 19 26 20 | 23 53 22 40 |
...
0x0001000: 41 21 10 36 | 25 27 38 63 | 31 74 65 59 | 78 29 61 00 |
0x0001010: 33 76 02 75 | 01 35 77 71 | 39 03 73 67 | 07 37 69 08 |
0x0001020: 41 21 10 36 | 25 27 38 63 | 31 74 65 59 | 78 29 61 00 |
0x0001030: 33 76 02 75 | 01 35 77 71 | 39 03 73 67 | 07 37 69 08 |
...
0x0002000: 57 21 42 36 | 09 43 06 16 | 47 11 18 12 | 15 45 14 32 |
0x0002010: 49 13 34 28 | 17 51 30 24 | 55 19 26 20 | 23 53 22 40 |
0x0002020: 57 21 42 36 | 09 43 06 16 | 47 11 18 12 | 15 45 14 32 |
0x0002030: 49 13 34 28 | 17 51 30 24 | 55 19 26 20 | 23 53 22 40 |

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 2, Part G Page 945
Sample Data

...
0x0003000: 41 05 10 04 | 09 27 06 63 | 31 74 65 59 | 78 29 61 00 |
0x0003010: 33 76 02 75 | 01 35 77 71 | 39 03 73 67 | 07 37 69 08 |
0x0003020: 41 05 10 04 | 09 27 06 63 | 31 74 65 59 | 78 29 61 00 |
0x0003030: 33 76 02 75 | 01 35 77 71 | 39 03 73 67 | 07 37 69 08 |

Hop sequence {k} for Peripheral Response substate:

CLKN* = 0x0000010
ULAP: 0x2a96ef25
#ticks: 00 | 02 04 | 06 08 | 0a 0c | 0e 10 | 12 14 | 16 18 | 1a
--------------------------------------------------------
0x0000012: 34 | 13 28 | 17 30 | 51 24 | 55 26 | 19 20 | 23 22 | 53
0x0000032: 42 | 21 36 | 25 38 | 27 63 | 31 65 | 74 59 | 78 61 | 29
0x0000052: 02 | 76 75 | 01 77 | 35 71 | 39 73 | 03 67 | 07 69 | 37
0x0000072: 10 | 05 04 | 09 06 | 43 16 | 47 18 | 11 12 | 15 14 | 45

Hop sequence {k} for Central Response substate:

Offset value: 24
CLKE* = 0x0000012
ULAP: 0x2a96ef25
#ticks: 00 02 | 04 06 | 08 0a | 0c 0e | 10 12 | 14 16 | 18 1a |
--------------------------------------------------------
0x0000014: 13 28 | 17 30 | 51 24 | 55 26 | 19 20 | 23 22 | 53 40 |
0x0000034: 21 36 | 25 38 | 27 63 | 31 65 | 74 59 | 78 61 | 29 00 |
0x0000054: 76 75 | 01 77 | 35 71 | 39 73 | 03 67 | 07 69 | 37 08 |
0x0000074: 05 04 | 09 06 | 43 16 | 47 18 | 11 12 | 15 14 | 45 32 |

Hop sequence {k} for Connection state (Basic channel hopping sequence; ie,
non-AFH):
CLK start: 0x0000010
ULAP: 0x2a96ef25
#ticks: 00 02 | 04 06 | 08 0a | 0c 0e | 10 12 | 14 16 | 18 1a | 1c 1e |
---------------------------------------------------------------
0x0000010: 55 26 | 19 20 | 23 22 | 53 40 | 57 42 | 21 36 | 25 38 | 27 63 |
0x0000030: 31 65 | 74 59 | 78 61 | 29 00 | 33 02 | 76 75 | 01 77 | 35 71 |
0x0000050: 39 73 | 03 67 | 07 69 | 37 08 | 41 10 | 05 04 | 09 06 | 43 16 |
0x0000070: 47 18 | 11 12 | 15 14 | 45 32 | 02 66 | 47 60 | 49 64 | 04 54 |
0x0000090: 06 58 | 51 52 | 53 56 | 08 70 | 10 74 | 55 68 | 57 72 | 59 14 |
0x00000b0: 61 18 | 27 12 | 29 16 | 63 30 | 65 34 | 31 28 | 33 32 | 67 22 |
0x00000d0: 69 26 | 35 20 | 37 24 | 71 38 | 73 42 | 39 36 | 41 40 | 75 46 |
0x00000f0: 77 50 | 43 44 | 45 48 | 00 62 | 26 11 | 69 05 | 73 07 | 36 17 |
0x0000110: 40 19 | 04 13 | 08 15 | 38 25 | 42 27 | 06 21 | 10 23 | 12 48 |
0x0000130: 16 50 | 59 44 | 63 46 | 14 56 | 18 58 | 61 52 | 65 54 | 28 64 |
0x0000150: 32 66 | 75 60 | 00 62 | 30 72 | 34 74 | 77 68 | 02 70 | 20 01 |

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 2, Part G Page 946
Sample Data

0x0000170: 24 03 | 67 76 | 71 78 | 22 09 | 58 43 | 24 37 | 26 41 | 68 47 |
0x0000190: 70 51 | 36 45 | 38 49 | 72 55 | 74 59 | 40 53 | 42 57 | 44 78 |
0x00001b0: 46 03 | 12 76 | 14 01 | 48 07 | 50 11 | 16 05 | 18 09 | 60 15 |
0x00001d0: 62 19 | 28 13 | 30 17 | 64 23 | 66 27 | 32 21 | 34 25 | 52 31 |
0x00001f0: 54 35 | 20 29 | 22 33 | 56 39 | 19 04 | 62 63 | 66 00 | 07 73 |
0x0000210: 11 10 | 54 69 | 58 06 | 23 75 | 27 12 | 70 71 | 74 08 | 76 33 |
0x0000230: 01 49 | 44 29 | 48 45 | 13 35 | 17 51 | 60 31 | 64 47 | 05 41 |
0x0000250: 09 57 | 52 37 | 56 53 | 21 43 | 25 59 | 68 39 | 72 55 | 78 65 |
0x0000270: 03 02 | 46 61 | 50 77 | 15 67 | 51 36 | 17 18 | 19 34 | 41 24 |
0x0000290: 43 40 | 09 22 | 11 38 | 57 28 | 59 44 | 25 26 | 27 42 | 29 63 |
0x00002b0: 31 00 | 76 61 | 78 77 | 45 67 | 47 04 | 13 65 | 15 02 | 37 71 |
0x00002d0: 39 08 | 05 69 | 07 06 | 53 75 | 55 12 | 21 73 | 23 10 | 33 16 |
0x00002f0: 35 32 | 01 14 | 03 30 | 49 20 | 75 60 | 39 48 | 43 56 | 00 66 |
0x0000310: 04 74 | 47 62 | 51 70 | 08 68 | 12 76 | 55 64 | 59 72 | 61 18 |
0x0000330: 65 26 | 29 14 | 33 22 | 69 20 | 73 28 | 37 16 | 41 24 | 77 34 |
0x0000350: 02 42 | 45 30 | 49 38 | 06 36 | 10 44 | 53 32 | 57 40 | 63 50 |
0x0000370: 67 58 | 31 46 | 35 54 | 71 52 | 28 13 | 73 03 | 75 11 | 34 17 |
0x0000390: 36 25 | 02 15 | 04 23 | 42 21 | 44 29 | 10 19 | 12 27 | 14 48 |
0x00003b0: 16 56 | 61 46 | 63 54 | 22 52 | 24 60 | 69 50 | 71 58 | 30 64 |
0x00003d0: 32 72 | 77 62 | 00 70 | 38 68 | 40 76 | 06 66 | 08 74 | 18 01 |
0x00003f0: 20 09 | 65 78 | 67 07 | 26 05 | 44 29 | 32 23 | 36 25 | 70 43 |

Hop Sequence {k} for Connection state (Adapted channel hopping sequence with
all channels used; ie, AFH(79)):
CLK start: 0x0000010
ULAP: 0x2a96ef25
Used Channels:0x7fffffffffffffffffff
#ticks: 00 02 | 04 06 | 08 0a | 0c 0e | 10 12 | 14 16 | 18 1a | 1c 1e |
---------------------------------------------------------------
0x0000010 55 55 | 19 19 | 23 23 | 53 53 | 57 57 | 21 21 | 25 25 | 27 27 |
0x0000030 31 31 | 74 74 | 78 78 | 29 29 | 33 33 | 76 76 | 01 01 | 35 35 |
0x0000050 39 39 | 03 03 | 07 07 | 37 37 | 41 41 | 05 05 | 09 09 | 43 43 |
0x0000070 47 47 | 11 11 | 15 15 | 45 45 | 02 02 | 47 47 | 49 49 | 04 04 |
0x0000090 06 06 | 51 51 | 53 53 | 08 08 | 10 10 | 55 55 | 57 57 | 59 59 |
0x00000b0 61 61 | 27 27 | 29 29 | 63 63 | 65 65 | 31 31 | 33 33 | 67 67 |
0x00000d0 69 69 | 35 35 | 37 37 | 71 71 | 73 73 | 39 39 | 41 41 | 75 75 |
0x00000f0 77 77 | 43 43 | 45 45 | 00 00 | 26 26 | 69 69 | 73 73 | 36 36 |
0x0000110 40 40 | 04 04 | 08 08 | 38 38 | 42 42 | 06 06 | 10 10 | 12 12 |
0x0000130 16 16 | 59 59 | 63 63 | 14 14 | 18 18 | 61 61 | 65 65 | 28 28 |
0x0000150 32 32 | 75 75 | 00 00 | 30 30 | 34 34 | 77 77 | 02 02 | 20 20 |
0x0000170 24 24 | 67 67 | 71 71 | 22 22 | 58 58 | 24 24 | 26 26 | 68 68 |
0x0000190 70 70 | 36 36 | 38 38 | 72 72 | 74 74 | 40 40 | 42 42 | 44 44 |
0x00001b0 46 46 | 12 12 | 14 14 | 48 48 | 50 50 | 16 16 | 18 18 | 60 60 |

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 2, Part G Page 947
Sample Data

0x00001d0 62 62 | 28 28 | 30 30 | 64 64 | 66 66 | 32 32 | 34 34 | 52 52 |
0x00001f0 54 54 | 20 20 | 22 22 | 56 56 | 19 19 | 62 62 | 66 66 | 07 07 |
0x0000210 11 11 | 54 54 | 58 58 | 23 23 | 27 27 | 70 70 | 74 74 | 76 76 |
0x0000230 01 01 | 44 44 | 48 48 | 13 13 | 17 17 | 60 60 | 64 64 | 05 05 |
0x0000250 09 09 | 52 52 | 56 56 | 21 21 | 25 25 | 68 68 | 72 72 | 78 78 |
0x0000270 03 03 | 46 46 | 50 50 | 15 15 | 51 51 | 17 17 | 19 19 | 41 41 |
0x0000290 43 43 | 09 09 | 11 11 | 57 57 | 59 59 | 25 25 | 27 27 | 29 29 |
0x00002b0 31 31 | 76 76 | 78 78 | 45 45 | 47 47 | 13 13 | 15 15 | 37 37 |
0x00002d0 39 39 | 05 05 | 07 07 | 53 53 | 55 55 | 21 21 | 23 23 | 33 33 |
0x00002f0 35 35 | 01 01 | 03 03 | 49 49 | 75 75 | 39 39 | 43 43 | 00 00 |
0x0000310 04 04 | 47 47 | 51 51 | 08 08 | 12 12 | 55 55 | 59 59 | 61 61 |
0x0000330 65 65 | 29 29 | 33 33 | 69 69 | 73 73 | 37 37 | 41 41 | 77 77 |
0x0000350 02 02 | 45 45 | 49 49 | 06 06 | 10 10 | 53 53 | 57 57 | 63 63 |
0x0000370 67 67 | 31 31 | 35 35 | 71 71 | 28 28 | 73 73 | 75 75 | 34 34 |
0x0000390 36 36 | 02 02 | 04 04 | 42 42 | 44 44 | 10 10 | 12 12 | 14 14 |
0x00003b0 16 16 | 61 61 | 63 63 | 22 22 | 24 24 | 69 69 | 71 71 | 30 30 |
0x00003d0 32 32 | 77 77 | 00 00 | 38 38 | 40 40 | 06 06 | 08 08 | 18 18 |
0x00003f0 20 20 | 65 65 | 67 67 | 26 26 | 44 44 | 32 32 | 36 36 | 70 70 |

Hop Sequence {k} for Connection state (Adapted channel hopping sequence with
channels 0 to 21 unused):
CLK start: 0x0000010
ULAP: 0x2a96ef25
Used Channels:0x7fffffffffffffc00000
#ticks: 00 02 | 04 06 | 08 0a | 0c 0e | 10 12 | 14 16 | 18 1a | 1c 1e |
---------------------------------------------------------------
0x0000010 55 55 | 50 50 | 23 23 | 53 53 | 57 57 | 52 52 | 25 25 | 27 27 |
0x0000030 31 31 | 74 74 | 78 78 | 29 29 | 33 33 | 76 76 | 32 32 | 35 35 |
0x0000050 39 39 | 34 34 | 38 38 | 37 37 | 41 41 | 36 36 | 40 40 | 43 43 |
0x0000070 47 47 | 42 42 | 46 46 | 45 45 | 55 55 | 47 47 | 49 49 | 57 57 |
0x0000090 59 59 | 51 51 | 53 53 | 61 61 | 63 63 | 55 55 | 57 57 | 59 59 |
0x00000b0 61 61 | 27 27 | 29 29 | 63 63 | 65 65 | 31 31 | 33 33 | 67 67 |
0x00000d0 69 69 | 35 35 | 37 37 | 71 71 | 73 73 | 39 39 | 41 41 | 75 75 |
0x00000f0 77 77 | 43 43 | 45 45 | 53 53 | 26 26 | 69 69 | 73 73 | 36 36 |
0x0000110 40 40 | 57 57 | 61 61 | 38 38 | 42 42 | 59 59 | 63 63 | 65 65 |
0x0000130 69 69 | 59 59 | 63 63 | 67 67 | 71 71 | 61 61 | 65 65 | 28 28 |
0x0000150 32 32 | 75 75 | 53 53 | 30 30 | 34 34 | 77 77 | 55 55 | 73 73 |
0x0000170 24 24 | 67 67 | 71 71 | 22 22 | 58 58 | 24 24 | 26 26 | 68 68 |
0x0000190 70 70 | 36 36 | 38 38 | 72 72 | 74 74 | 40 40 | 42 42 | 44 44 |
0x00001b0 46 46 | 65 65 | 67 67 | 48 48 | 50 50 | 69 69 | 71 71 | 60 60 |
0x00001d0 62 62 | 28 28 | 30 30 | 64 64 | 66 66 | 32 32 | 34 34 | 52 52 |
0x00001f0 54 54 | 73 73 | 22 22 | 56 56 | 37 37 | 62 62 | 66 66 | 25 25 |
0x0000210 29 29 | 54 54 | 58 58 | 23 23 | 27 27 | 70 70 | 74 74 | 76 76 |

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 2, Part G Page 948
Sample Data

0x0000230 76 76 | 44 44 | 48 48 | 31 31 | 35 35 | 60 60 | 64 64 | 23 23 |
0x0000250 27 27 | 52 52 | 56 56 | 39 39 | 25 25 | 68 68 | 72 72 | 78 78 |
0x0000270 78 78 | 46 46 | 50 50 | 33 33 | 51 51 | 35 35 | 37 37 | 41 41 |
0x0000290 43 43 | 27 27 | 29 29 | 57 57 | 59 59 | 25 25 | 27 27 | 29 29 |
0x00002b0 31 31 | 76 76 | 78 78 | 45 45 | 47 47 | 31 31 | 33 33 | 37 37 |
0x00002d0 39 39 | 23 23 | 25 25 | 53 53 | 55 55 | 39 39 | 23 23 | 33 33 |
0x00002f0 35 35 | 76 76 | 78 78 | 49 49 | 75 75 | 39 39 | 43 43 | 40 40 |
0x0000310 44 44 | 47 47 | 51 51 | 48 48 | 52 52 | 55 55 | 59 59 | 61 61 |
0x0000330 65 65 | 29 29 | 33 33 | 69 69 | 73 73 | 37 37 | 41 41 | 77 77 |
0x0000350 42 42 | 45 45 | 49 49 | 46 46 | 50 50 | 53 53 | 57 57 | 63 63 |
0x0000370 67 67 | 31 31 | 35 35 | 71 71 | 28 28 | 73 73 | 75 75 | 34 34 |
0x0000390 36 36 | 42 42 | 44 44 | 42 42 | 44 44 | 50 50 | 52 52 | 54 54 |
0x00003b0 56 56 | 61 61 | 63 63 | 22 22 | 24 24 | 69 69 | 71 71 | 30 30 |
0x00003d0 32 32 | 77 77 | 40 40 | 38 38 | 40 40 | 46 46 | 48 48 | 58 58 |
0x00003f0 60 60 | 65 65 | 67 67 | 26 26 | 44 44 | 32 32 | 36 36 | 70 70 |

Hop Sequence {k} for Connection state (Adapted channel hopping sequence with
even channels used):
CLK start: 0x0000010
ULAP: 0x2a96ef25
Used Channels:0x55555555555555555555
#ticks: 00 02 | 04 06 | 08 0a | 0c 0e | 10 12 | 14 16 | 18 1a | 1c 1e |
---------------------------------------------------------------
0x0000010 52 52 | 16 16 | 20 20 | 50 50 | 54 54 | 18 18 | 22 22 | 24 24 |
0x0000030 28 28 | 74 74 | 78 78 | 26 26 | 30 30 | 76 76 | 78 78 | 32 32 |
0x0000050 36 36 | 00 00 | 04 04 | 34 34 | 38 38 | 02 02 | 06 06 | 40 40 |
0x0000070 44 44 | 08 08 | 12 12 | 42 42 | 02 02 | 44 44 | 46 46 | 04 04 |
0x0000090 06 06 | 48 48 | 50 50 | 08 08 | 10 10 | 52 52 | 54 54 | 56 56 |
0x00000b0 58 58 | 24 24 | 26 26 | 60 60 | 62 62 | 28 28 | 30 30 | 64 64 |
0x00000d0 66 66 | 32 32 | 34 34 | 68 68 | 70 70 | 36 36 | 38 38 | 72 72 |
0x00000f0 74 74 | 40 40 | 42 42 | 00 00 | 26 26 | 66 66 | 70 70 | 36 36 |
0x0000110 40 40 | 04 04 | 08 08 | 38 38 | 42 42 | 06 06 | 10 10 | 12 12 |
0x0000130 16 16 | 56 56 | 60 60 | 14 14 | 18 18 | 58 58 | 62 62 | 28 28 |
0x0000150 32 32 | 72 72 | 00 00 | 30 30 | 34 34 | 74 74 | 02 02 | 20 20 |
0x0000170 24 24 | 64 64 | 68 68 | 22 22 | 58 58 | 24 24 | 26 26 | 68 68 |
0x0000190 70 70 | 36 36 | 38 38 | 72 72 | 74 74 | 40 40 | 42 42 | 44 44 |
0x00001b0 46 46 | 12 12 | 14 14 | 48 48 | 50 50 | 16 16 | 18 18 | 60 60 |
0x00001d0 62 62 | 28 28 | 30 30 | 64 64 | 66 66 | 32 32 | 34 34 | 52 52 |
0x00001f0 54 54 | 20 20 | 22 22 | 56 56 | 14 14 | 62 62 | 66 66 | 02 02 |
0x0000210 06 06 | 54 54 | 58 58 | 18 18 | 22 22 | 70 70 | 74 74 | 76 76 |
0x0000230 76 76 | 44 44 | 48 48 | 08 08 | 12 12 | 60 60 | 64 64 | 00 00 |
0x0000250 04 04 | 52 52 | 56 56 | 16 16 | 20 20 | 68 68 | 72 72 | 78 78 |
0x0000270 78 78 | 46 46 | 50 50 | 10 10 | 46 46 | 12 12 | 14 14 | 36 36 |

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 2, Part G Page 949
Sample Data

0x0000290 38 38 | 04 04 | 06 06 | 52 52 | 54 54 | 20 20 | 22 22 | 24 24 |
0x00002b0 26 26 | 76 76 | 78 78 | 40 40 | 42 42 | 08 08 | 10 10 | 32 32 |
0x00002d0 34 34 | 00 00 | 02 02 | 48 48 | 50 50 | 16 16 | 18 18 | 28 28 |
0x00002f0 30 30 | 76 76 | 78 78 | 44 44 | 70 70 | 34 34 | 38 38 | 00 00 |
0x0000310 04 04 | 42 42 | 46 46 | 08 08 | 12 12 | 50 50 | 54 54 | 56 56 |
0x0000330 60 60 | 24 24 | 28 28 | 64 64 | 68 68 | 32 32 | 36 36 | 72 72 |
0x0000350 02 02 | 40 40 | 44 44 | 06 06 | 10 10 | 48 48 | 52 52 | 58 58 |
0x0000370 62 62 | 26 26 | 30 30 | 66 66 | 28 28 | 68 68 | 70 70 | 34 34 |
0x0000390 36 36 | 02 02 | 04 04 | 42 42 | 44 44 | 10 10 | 12 12 | 14 14 |
0x00003b0 16 16 | 56 56 | 58 58 | 22 22 | 24 24 | 64 64 | 66 66 | 30 30 |
0x00003d0 32 32 | 72 72 | 00 00 | 38 38 | 40 40 | 06 06 | 08 08 | 18 18 |
0x00003f0 20 20 | 60 60 | 62 62 | 26 26 | 44 44 | 32 32 | 36 36 | 70 70 |

Hop Sequence {k} for Connection state (Adapted channel hopping sequence with
odd channels used):
CLK start: 0x0000010
ULAP: 0x2a96ef25
Used Channels:0x2aaaaaaaaaaaaaaaaaaa
#ticks: 00 02 | 04 06 | 08 0a | 0c 0e | 10 12 | 14 16 | 18 1a | 1c 1e |
---------------------------------------------------------------
0x0000010 55 55 | 19 19 | 23 23 | 53 53 | 57 57 | 21 21 | 25 25 | 27 27 |
0x0000030 31 31 | 77 77 | 03 03 | 29 29 | 33 33 | 01 01 | 01 01 | 35 35 |
0x0000050 39 39 | 03 03 | 07 07 | 37 37 | 41 41 | 05 05 | 09 09 | 43 43 |
0x0000070 47 47 | 11 11 | 15 15 | 45 45 | 07 07 | 47 47 | 49 49 | 09 09 |
0x0000090 11 11 | 51 51 | 53 53 | 13 13 | 15 15 | 55 55 | 57 57 | 59 59 |
0x00000b0 61 61 | 27 27 | 29 29 | 63 63 | 65 65 | 31 31 | 33 33 | 67 67 |
0x00000d0 69 69 | 35 35 | 37 37 | 71 71 | 73 73 | 39 39 | 41 41 | 75 75 |
0x00000f0 77 77 | 43 43 | 45 45 | 05 05 | 31 31 | 69 69 | 73 73 | 41 41 |
0x0000110 45 45 | 09 09 | 13 13 | 43 43 | 47 47 | 11 11 | 15 15 | 17 17 |
0x0000130 21 21 | 59 59 | 63 63 | 19 19 | 23 23 | 61 61 | 65 65 | 33 33 |
0x0000150 37 37 | 75 75 | 05 05 | 35 35 | 39 39 | 77 77 | 07 07 | 25 25 |
0x0000170 29 29 | 67 67 | 71 71 | 27 27 | 63 63 | 29 29 | 31 31 | 73 73 |
0x0000190 75 75 | 41 41 | 43 43 | 77 77 | 01 01 | 45 45 | 47 47 | 49 49 |
0x00001b0 51 51 | 17 17 | 19 19 | 53 53 | 55 55 | 21 21 | 23 23 | 65 65 |
0x00001d0 67 67 | 33 33 | 35 35 | 69 69 | 71 71 | 37 37 | 39 39 | 57 57 |
0x00001f0 59 59 | 25 25 | 27 27 | 61 61 | 19 19 | 67 67 | 71 71 | 07 07 |
0x0000210 11 11 | 59 59 | 63 63 | 23 23 | 27 27 | 75 75 | 01 01 | 03 03 |
0x0000230 01 01 | 49 49 | 53 53 | 13 13 | 17 17 | 65 65 | 69 69 | 05 05 |
0x0000250 09 09 | 57 57 | 61 61 | 21 21 | 25 25 | 73 73 | 77 77 | 05 05 |
0x0000270 03 03 | 51 51 | 55 55 | 15 15 | 51 51 | 17 17 | 19 19 | 41 41 |
0x0000290 43 43 | 09 09 | 11 11 | 57 57 | 59 59 | 25 25 | 27 27 | 29 29 |
0x00002b0 31 31 | 03 03 | 05 05 | 45 45 | 47 47 | 13 13 | 15 15 | 37 37 |
0x00002d0 39 39 | 05 05 | 07 07 | 53 53 | 55 55 | 21 21 | 23 23 | 33 33 |

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 2, Part G Page 950
Sample Data

0x00002f0 35 35 | 01 01 | 03 03 | 49 49 | 75 75 | 39 39 | 43 43 | 07 07 |
0x0000310 11 11 | 47 47 | 51 51 | 15 15 | 19 19 | 55 55 | 59 59 | 61 61 |
0x0000330 65 65 | 29 29 | 33 33 | 69 69 | 73 73 | 37 37 | 41 41 | 77 77 |
0x0000350 09 09 | 45 45 | 49 49 | 13 13 | 17 17 | 53 53 | 57 57 | 63 63 |
0x0000370 67 67 | 31 31 | 35 35 | 71 71 | 35 35 | 73 73 | 75 75 | 41 41 |
0x0000390 43 43 | 09 09 | 11 11 | 49 49 | 51 51 | 17 17 | 19 19 | 21 21 |
0x00003b0 23 23 | 61 61 | 63 63 | 29 29 | 31 31 | 69 69 | 71 71 | 37 37 |
0x00003d0 39 39 | 77 77 | 07 07 | 45 45 | 47 47 | 13 13 | 15 15 | 25 25 |
0x00003f0 27 27 | 65 65 | 67 67 | 33 33 | 51 51 | 39 39 | 43 43 | 77 77 |

2.3 Third set

Hop sequence {k} for Page Scan and Inquiry Scan substates:
CLKN start: 0x0000000
ULAP: 0x6587cba9
#ticks: 0000 | 1000 | 2000 | 3000 | 4000 | 5000 | 6000 | 7000 |
--------------------------------------------------------
0x0000000: 16 | 65 | 67 | 18 | 20 | 53 | 55 | 6 |
0x0008000: 8 | 57 | 59 | 10 | 12 | 69 | 71 | 22 |
0x0010000: 24 | 73 | 75 | 26 | 28 | 45 | 47 | 77 |
0x0018000: 0 | 49 | 51 | 2 | 4 | 61 | 63 | 14 |
0x0020000: 16 | 65 | 67 | 18 | 20 | 53 | 55 | 6 |
0x0028000: 8 | 57 | 59 | 10 | 12 | 69 | 71 | 22 |
0x0030000: 24 | 73 | 75 | 26 | 28 | 45 | 47 | 77 |
0x0038000: 0 | 49 | 51 | 2 | 4 | 61 | 63 | 14 |

Hop sequence {k} for Page and Inquiry substates:

CLKE start: 0x0000000
ULAP: 0x6587cba9
#ticks: 00 01 02 03 | 04 05 06 07 | 08 09 0a 0b | 0c 0d 0e 0f |
--------------------------------------------------------
0x0000000: 00 49 36 38 | 51 02 42 40 | 04 61 44 46 | 63 14 50 48 |
0x0000010: 16 65 52 54 | 67 18 58 56 | 20 53 60 62 | 55 06 66 64 |
0x0000020: 00 49 36 38 | 51 02 42 40 | 04 61 44 46 | 63 14 50 48 |
0x0000030: 16 65 52 54 | 67 18 58 56 | 20 53 60 62 | 55 06 66 64 |
...
0x0001000: 00 57 36 70 | 59 10 74 72 | 12 69 76 78 | 71 22 03 01 |
0x0001010: 24 73 05 07 | 75 26 11 09 | 28 45 13 30 | 47 77 34 32 |
0x0001020: 00 57 36 70 | 59 10 74 72 | 12 69 76 78 | 71 22 03 01 |
0x0001030: 24 73 05 07 | 75 26 11 09 | 28 45 13 30 | 47 77 34 32 |
...
0x0002000: 08 57 68 70 | 51 02 42 40 | 04 61 44 46 | 63 14 50 48 |
0x0002010: 16 65 52 54 | 67 18 58 56 | 20 53 60 62 | 55 06 66 64 |

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 2, Part G Page 951
Sample Data

0x0002020: 08 57 68 70 | 51 02 42 40 | 04 61 44 46 | 63 14 50 48 |
0x0002030: 16 65 52 54 | 67 18 58 56 | 20 53 60 62 | 55 06 66 64 |
...
0x0003000: 00 49 36 38 | 51 10 42 72 | 12 69 76 78 | 71 22 03 01 |
0x0003010: 24 73 05 07 | 75 26 11 09 | 28 45 13 30 | 47 77 34 32 |
0x0003020: 00 49 36 38 | 51 10 42 72 | 12 69 76 78 | 71 22 03 01 |
0x0003030: 24 73 05 07 | 75 26 11 09 | 28 45 13 30 | 47 77 34 32 |

Hop sequence {k} for Peripheral Response substate:

CLKN* = 0x0000010
ULAP: 0x6587cba9
#ticks: 00 | 02 04 | 06 08 | 0a 0c | 0e 10 | 12 14 | 16 18 | 1a 1c | 1e
----------------------------------------------------------------
0x0000012: 52 | 65 54 | 67 58 | 18 56 | 20 60 | 53 62 | 55 66 | 06 64 | 08
0x0000032: 68 | 57 70 | 59 74 | 10 72 | 12 76 | 69 78 | 71 03 | 22 01 | 24
0x0000052: 05 | 73 07 | 75 11 | 26 09 | 28 13 | 45 30 | 47 34 | 77 32 | 00
0x0000072: 36 | 49 38 | 51 42 | 02 40 | 04 44 | 61 46 | 63 50 | 14 48 | 16

Hop sequence {k} for Central Response substate:

Offset value: 24
CLKE* = 0x0000012
ULAP: 0x6587cba9
#ticks: 00 02 | 04 06 | 08 0a | 0c 0e | 10 12 | 14 16 | 18 1a | 1c 1e |
----------------------------------------------------------------
0x0000014: 65 54 | 67 58 | 18 56 | 20 60 | 53 62 | 55 66 | 06 64 | 08 68 |
0x0000034: 57 70 | 59 74 | 10 72 | 12 76 | 69 78 | 71 03 | 22 01 | 24 05 |
0x0000054: 73 07 | 75 11 | 26 09 | 28 13 | 45 30 | 47 34 | 77 32 | 00 36 |
0x0000074: 49 38 | 51 42 | 02 40 | 04 44 | 61 46 | 63 50 | 14 48 | 16 52 |

Hop sequence {k} for Connection state (Basic channel hopping sequence; ie,
non-AFH):
CLK start: 0x0000010
ULAP: 0x6587cba9
#ticks: 00 02 | 04 06 | 08 0a | 0c 0e | 10 12 | 14 16 | 18 1a | 1c 1e |
----------------------------------------------------------------
0x0000010: 20 60 | 53 62 | 55 66 | 06 64 | 08 68 | 57 70 | 59 74 | 10 72 |
0x0000030: 12 76 | 69 78 | 71 03 | 22 01 | 24 05 | 73 07 | 75 11 | 26 09 |
0x0000050: 28 13 | 45 30 | 47 34 | 77 32 | 00 36 | 49 38 | 51 42 | 02 40 |
0x0000070: 04 44 | 61 46 | 63 50 | 14 48 | 50 05 | 16 07 | 20 09 | 48 11 |
0x0000090: 52 13 | 06 15 | 10 17 | 38 19 | 42 21 | 08 23 | 12 25 | 40 27 |
0x00000b0: 44 29 | 22 31 | 26 33 | 54 35 | 58 37 | 24 39 | 28 41 | 56 43 |
0x00000d0: 60 45 | 77 62 | 02 64 | 30 66 | 34 68 | 00 70 | 04 72 | 32 74 |
0x00000f0: 36 76 | 14 78 | 18 01 | 46 03 | 72 29 | 42 39 | 44 43 | 74 41 |
0x0000110: 76 45 | 46 47 | 48 51 | 78 49 | 01 53 | 50 63 | 52 67 | 03 65 |

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 2, Part G Page 952
Sample Data

0x0000130: 05 69 | 54 55 | 56 59 | 07 57 | 09 61 | 58 71 | 60 75 | 11 73 |
0x0000150: 13 77 | 30 15 | 32 19 | 62 17 | 64 21 | 34 31 | 36 35 | 66 33 |
0x0000170: 68 37 | 38 23 | 40 27 | 70 25 | 27 61 | 72 71 | 76 73 | 25 75 |
0x0000190: 29 77 | 78 00 | 03 02 | 31 04 | 35 06 | 01 16 | 05 18 | 33 20 |
0x00001b0: 37 22 | 07 08 | 11 10 | 39 12 | 43 14 | 09 24 | 13 26 | 41 28 |
0x00001d0: 45 30 | 62 47 | 66 49 | 15 51 | 19 53 | 64 63 | 68 65 | 17 67 |
0x00001f0: 21 69 | 70 55 | 74 57 | 23 59 | 53 22 | 35 12 | 37 28 | 67 14 |
0x0000210: 69 30 | 23 32 | 25 48 | 55 34 | 57 50 | 39 40 | 41 56 | 71 42 |
0x0000230: 73 58 | 27 36 | 29 52 | 59 38 | 61 54 | 43 44 | 45 60 | 75 46 |
0x0000250: 77 62 | 15 00 | 17 16 | 47 02 | 49 18 | 31 08 | 33 24 | 63 10 |
0x0000270: 65 26 | 19 04 | 21 20 | 51 06 | 06 54 | 65 42 | 69 58 | 18 46 |
0x0000290: 22 62 | 55 64 | 59 01 | 08 68 | 12 05 | 71 72 | 75 09 | 24 76 |
0x00002b0: 28 13 | 57 66 | 61 03 | 10 70 | 14 07 | 73 74 | 77 11 | 26 78 |
0x00002d0: 30 15 | 47 32 | 51 48 | 00 36 | 04 52 | 63 40 | 67 56 | 16 44 |
0x00002f0: 20 60 | 49 34 | 53 50 | 02 38 | 38 78 | 12 05 | 14 13 | 44 07 |
0x0000310: 46 15 | 16 17 | 18 25 | 48 19 | 50 27 | 24 33 | 26 41 | 56 35 |
0x0000330: 58 43 | 20 21 | 22 29 | 52 23 | 54 31 | 28 37 | 30 45 | 60 39 |
0x0000350: 62 47 | 00 64 | 02 72 | 32 66 | 34 74 | 08 01 | 10 09 | 40 03 |
0x0000370: 42 11 | 04 68 | 06 76 | 36 70 | 70 31 | 42 35 | 46 43 | 74 39 |
0x0000390: 78 47 | 48 49 | 52 57 | 01 53 | 05 61 | 56 65 | 60 73 | 09 69 |
0x00003b0: 13 77 | 50 51 | 54 59 | 03 55 | 07 63 | 58 67 | 62 75 | 11 71 |
0x00003d0: 15 00 | 32 17 | 36 25 | 64 21 | 68 29 | 40 33 | 44 41 | 72 37 |
0x00003f0: 76 45 | 34 19 | 38 27 | 66 23 | 11 71 | 05 18 | 07 22 | 13 20 |

Hop Sequence {k} for Connection state (Adapted channel hopping sequence with
all channels used; ie, AFH(79)):
CLK start: 0x0000010
ULAP: 0x6587cba9
Used Channels:0x7fffffffffffffffffff
#ticks: 00 02 | 04 06 | 08 0a | 0c 0e | 10 12 | 14 16 | 18 1a | 1c 1e |
---------------------------------------------------------------
0x0000010 20 20 | 53 53 | 55 55 | 06 06 | 08 08 | 57 57 | 59 59 | 10 10 |
0x0000030 12 12 | 69 69 | 71 71 | 22 22 | 24 24 | 73 73 | 75 75 | 26 26 |
0x0000050 28 28 | 45 45 | 47 47 | 77 77 | 00 00 | 49 49 | 51 51 | 02 02 |
0x0000070 04 04 | 61 61 | 63 63 | 14 14 | 50 50 | 16 16 | 20 20 | 48 48 |
0x0000090 52 52 | 06 06 | 10 10 | 38 38 | 42 42 | 08 08 | 12 12 | 40 40 |
0x00000b0 44 44 | 22 22 | 26 26 | 54 54 | 58 58 | 24 24 | 28 28 | 56 56 |
0x00000d0 60 60 | 77 77 | 02 02 | 30 30 | 34 34 | 00 00 | 04 04 | 32 32 |
0x00000f0 36 36 | 14 14 | 18 18 | 46 46 | 72 72 | 42 42 | 44 44 | 74 74 |
0x0000110 76 76 | 46 46 | 48 48 | 78 78 | 01 01 | 50 50 | 52 52 | 03 03 |
0x0000130 05 05 | 54 54 | 56 56 | 07 07 | 09 09 | 58 58 | 60 60 | 11 11 |
0x0000150 13 13 | 30 30 | 32 32 | 62 62 | 64 64 | 34 34 | 36 36 | 66 66 |
0x0000170 68 68 | 38 38 | 40 40 | 70 70 | 27 27 | 72 72 | 76 76 | 25 25 |

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 2, Part G Page 953
Sample Data

0x0000190 29 29 | 78 78 | 03 03 | 31 31 | 35 35 | 01 01 | 05 05 | 33 33 |
0x00001b0 37 37 | 07 07 | 11 11 | 39 39 | 43 43 | 09 09 | 13 13 | 41 41 |
0x00001d0 45 45 | 62 62 | 66 66 | 15 15 | 19 19 | 64 64 | 68 68 | 17 17 |
0x00001f0 21 21 | 70 70 | 74 74 | 23 23 | 53 53 | 35 35 | 37 37 | 67 67 |
0x0000210 69 69 | 23 23 | 25 25 | 55 55 | 57 57 | 39 39 | 41 41 | 71 71 |
0x0000230 73 73 | 27 27 | 29 29 | 59 59 | 61 61 | 43 43 | 45 45 | 75 75 |
0x0000250 77 77 | 15 15 | 17 17 | 47 47 | 49 49 | 31 31 | 33 33 | 63 63 |
0x0000270 65 65 | 19 19 | 21 21 | 51 51 | 06 06 | 65 65 | 69 69 | 18 18 |
0x0000290 22 22 | 55 55 | 59 59 | 08 08 | 12 12 | 71 71 | 75 75 | 24 24 |
0x00002b0 28 28 | 57 57 | 61 61 | 10 10 | 14 14 | 73 73 | 77 77 | 26 26 |
0x00002d0 30 30 | 47 47 | 51 51 | 00 00 | 04 04 | 63 63 | 67 67 | 16 16 |
0x00002f0 20 20 | 49 49 | 53 53 | 02 02 | 38 38 | 12 12 | 14 14 | 44 44 |
0x0000310 46 46 | 16 16 | 18 18 | 48 48 | 50 50 | 24 24 | 26 26 | 56 56 |
0x0000330 58 58 | 20 20 | 22 22 | 52 52 | 54 54 | 28 28 | 30 30 | 60 60 |
0x0000350 62 62 | 00 00 | 02 02 | 32 32 | 34 34 | 08 08 | 10 10 | 40 40 |
0x0000370 42 42 | 04 04 | 06 06 | 36 36 | 70 70 | 42 42 | 46 46 | 74 74 |
0x0000390 78 78 | 48 48 | 52 52 | 01 01 | 05 05 | 56 56 | 60 60 | 09 09 |
0x00003b0 13 13 | 50 50 | 54 54 | 03 03 | 07 07 | 58 58 | 62 62 | 11 11 |
0x00003d0 15 15 | 32 32 | 36 36 | 64 64 | 68 68 | 40 40 | 44 44 | 72 72 |
0x00003f0 76 76 | 34 34 | 38 38 | 66 66 | 11 11 | 05 05 | 07 07 | 13 13 |

Hop Sequence {k} for Connection state (Adapted channel hopping sequence with
channels 0 to 21 unused):
CLK start: 0x0000010
ULAP: 0x6587cba9
Used Channels:0x7fffffffffffffc00000
#ticks: 00 02 | 04 06 | 08 0a | 0c 0e | 10 12 | 14 16 | 18 1a | 1c 1e |
---------------------------------------------------------------
0x0000010 29 29 | 53 53 | 55 55 | 72 72 | 74 74 | 57 57 | 59 59 | 76 76 |
0x0000030 78 78 | 69 69 | 71 71 | 22 22 | 24 24 | 73 73 | 75 75 | 26 26 |
0x0000050 28 28 | 45 45 | 47 47 | 77 77 | 66 66 | 49 49 | 51 51 | 68 68 |
0x0000070 70 70 | 61 61 | 63 63 | 23 23 | 50 50 | 25 25 | 29 29 | 48 48 |
0x0000090 52 52 | 72 72 | 76 76 | 38 38 | 42 42 | 74 74 | 78 78 | 40 40 |
0x00000b0 44 44 | 22 22 | 26 26 | 54 54 | 58 58 | 24 24 | 28 28 | 56 56 |
0x00000d0 60 60 | 77 77 | 68 68 | 30 30 | 34 34 | 66 66 | 70 70 | 32 32 |
0x00000f0 36 36 | 23 23 | 27 27 | 46 46 | 72 72 | 42 42 | 44 44 | 74 74 |
0x0000110 76 76 | 46 46 | 48 48 | 78 78 | 32 32 | 50 50 | 52 52 | 34 34 |
0x0000130 36 36 | 54 54 | 56 56 | 38 38 | 40 40 | 58 58 | 60 60 | 42 42 |
0x0000150 44 44 | 30 30 | 32 32 | 62 62 | 64 64 | 34 34 | 36 36 | 66 66 |
0x0000170 68 68 | 38 38 | 40 40 | 70 70 | 27 27 | 72 72 | 76 76 | 25 25 |
0x0000190 29 29 | 78 78 | 34 34 | 31 31 | 35 35 | 32 32 | 36 36 | 33 33 |
0x00001b0 37 37 | 38 38 | 42 42 | 39 39 | 43 43 | 40 40 | 44 44 | 41 41 |
0x00001d0 45 45 | 62 62 | 66 66 | 46 46 | 50 50 | 64 64 | 68 68 | 48 48 |

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 2, Part G Page 954
Sample Data

0x00001f0 52 52 | 70 70 | 74 74 | 23 23 | 53 53 | 35 35 | 37 37 | 67 67 |
0x0000210 69 69 | 23 23 | 25 25 | 55 55 | 57 57 | 39 39 | 41 41 | 71 71 |
0x0000230 73 73 | 27 27 | 29 29 | 59 59 | 61 61 | 43 43 | 45 45 | 75 75 |
0x0000250 77 77 | 46 46 | 48 48 | 47 47 | 49 49 | 31 31 | 33 33 | 63 63 |
0x0000270 65 65 | 50 50 | 52 52 | 51 51 | 59 59 | 65 65 | 69 69 | 71 71 |
0x0000290 22 22 | 55 55 | 59 59 | 61 61 | 65 65 | 71 71 | 75 75 | 24 24 |
0x00002b0 28 28 | 57 57 | 61 61 | 63 63 | 67 67 | 73 73 | 77 77 | 26 26 |
0x00002d0 30 30 | 47 47 | 51 51 | 53 53 | 57 57 | 63 63 | 67 67 | 69 69 |
0x00002f0 73 73 | 49 49 | 53 53 | 55 55 | 38 38 | 65 65 | 67 67 | 44 44 |
0x0000310 46 46 | 69 69 | 71 71 | 48 48 | 50 50 | 24 24 | 26 26 | 56 56 |
0x0000330 58 58 | 73 73 | 22 22 | 52 52 | 54 54 | 28 28 | 30 30 | 60 60 |
0x0000350 62 62 | 53 53 | 55 55 | 32 32 | 34 34 | 61 61 | 63 63 | 40 40 |
0x0000370 42 42 | 57 57 | 59 59 | 36 36 | 70 70 | 42 42 | 46 46 | 74 74 |
0x0000390 78 78 | 48 48 | 52 52 | 76 76 | 23 23 | 56 56 | 60 60 | 27 27 |
0x00003b0 31 31 | 50 50 | 54 54 | 78 78 | 25 25 | 58 58 | 62 62 | 29 29 |
0x00003d0 33 33 | 32 32 | 36 36 | 64 64 | 68 68 | 40 40 | 44 44 | 72 72 |
0x00003f0 76 76 | 34 34 | 38 38 | 66 66 | 29 29 | 23 23 | 25 25 | 31 31 |

Hop Sequence {k} for Connection state (Adapted channel hopping sequence with
even channels used):
CLK start: 0x0000010
ULAP: 0x6587cba9
Used Channels:0x55555555555555555555
#ticks: 00 02 | 04 06 | 08 0a | 0c 0e | 10 12 | 14 16 | 18 1a | 1c 1e |
---------------------------------------------------------------
0x0000010 20 20 | 52 52 | 54 54 | 06 06 | 08 08 | 56 56 | 58 58 | 10 10 |
0x0000030 12 12 | 68 68 | 70 70 | 22 22 | 24 24 | 72 72 | 74 74 | 26 26 |
0x0000050 28 28 | 44 44 | 46 46 | 76 76 | 00 00 | 48 48 | 50 50 | 02 02 |
0x0000070 04 04 | 60 60 | 62 62 | 14 14 | 50 50 | 16 16 | 20 20 | 48 48 |
0x0000090 52 52 | 06 06 | 10 10 | 38 38 | 42 42 | 08 08 | 12 12 | 40 40 |
0x00000b0 44 44 | 22 22 | 26 26 | 54 54 | 58 58 | 24 24 | 28 28 | 56 56 |
0x00000d0 60 60 | 76 76 | 02 02 | 30 30 | 34 34 | 00 00 | 04 04 | 32 32 |
0x00000f0 36 36 | 14 14 | 18 18 | 46 46 | 72 72 | 42 42 | 44 44 | 74 74 |
0x0000110 76 76 | 46 46 | 48 48 | 78 78 | 78 78 | 50 50 | 52 52 | 00 00 |
0x0000130 02 02 | 54 54 | 56 56 | 04 04 | 06 06 | 58 58 | 60 60 | 08 08 |
0x0000150 10 10 | 30 30 | 32 32 | 62 62 | 64 64 | 34 34 | 36 36 | 66 66 |
0x0000170 68 68 | 38 38 | 40 40 | 70 70 | 24 24 | 72 72 | 76 76 | 22 22 |
0x0000190 26 26 | 78 78 | 00 00 | 28 28 | 32 32 | 78 78 | 02 02 | 30 30 |
0x00001b0 34 34 | 04 04 | 08 08 | 36 36 | 40 40 | 06 06 | 10 10 | 38 38 |
0x00001d0 42 42 | 62 62 | 66 66 | 12 12 | 16 16 | 64 64 | 68 68 | 14 14 |
0x00001f0 18 18 | 70 70 | 74 74 | 20 20 | 50 50 | 32 32 | 34 34 | 64 64 |
0x0000210 66 66 | 20 20 | 22 22 | 52 52 | 54 54 | 36 36 | 38 38 | 68 68 |
0x0000230 70 70 | 24 24 | 26 26 | 56 56 | 58 58 | 40 40 | 42 42 | 72 72 |

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 2, Part G Page 955
Sample Data

0x0000250 74 74 | 12 12 | 14 14 | 44 44 | 46 46 | 28 28 | 30 30 | 60 60 |
0x0000270 62 62 | 16 16 | 18 18 | 48 48 | 06 06 | 62 62 | 66 66 | 18 18 |
0x0000290 22 22 | 52 52 | 56 56 | 08 08 | 12 12 | 68 68 | 72 72 | 24 24 |
0x00002b0 28 28 | 54 54 | 58 58 | 10 10 | 14 14 | 70 70 | 74 74 | 26 26 |
0x00002d0 30 30 | 44 44 | 48 48 | 00 00 | 04 04 | 60 60 | 64 64 | 16 16 |
0x00002f0 20 20 | 46 46 | 50 50 | 02 02 | 38 38 | 12 12 | 14 14 | 44 44 |
0x0000310 46 46 | 16 16 | 18 18 | 48 48 | 50 50 | 24 24 | 26 26 | 56 56 |
0x0000330 58 58 | 20 20 | 22 22 | 52 52 | 54 54 | 28 28 | 30 30 | 60 60 |
0x0000350 62 62 | 00 00 | 02 02 | 32 32 | 34 34 | 08 08 | 10 10 | 40 40 |
0x0000370 42 42 | 04 04 | 06 06 | 36 36 | 70 70 | 42 42 | 46 46 | 74 74 |
0x0000390 78 78 | 48 48 | 52 52 | 76 76 | 00 00 | 56 56 | 60 60 | 04 04 |
0x00003b0 08 08 | 50 50 | 54 54 | 78 78 | 02 02 | 58 58 | 62 62 | 06 06 |
0x00003d0 10 10 | 32 32 | 36 36 | 64 64 | 68 68 | 40 40 | 44 44 | 72 72 |
0x00003f0 76 76 | 34 34 | 38 38 | 66 66 | 06 06 | 00 00 | 02 02 | 08 08 |

Hop Sequence {k} for Connection state (Adapted channel hopping sequence with
odd channels used):
CLK start: 0x0000010
ULAP: 0x6587cba9
Used Channels:0x2aaaaaaaaaaaaaaaaaaa
#ticks: 00 02 | 04 06 | 08 0a | 0c 0e | 10 12 | 14 16 | 18 1a | 1c 1e |
---------------------------------------------------------------
0x0000010 23 23 | 53 53 | 55 55 | 09 09 | 11 11 | 57 57 | 59 59 | 13 13 |
0x0000030 15 15 | 69 69 | 71 71 | 25 25 | 27 27 | 73 73 | 75 75 | 29 29 |
0x0000050 31 31 | 45 45 | 47 47 | 77 77 | 03 03 | 49 49 | 51 51 | 05 05 |
0x0000070 07 07 | 61 61 | 63 63 | 17 17 | 53 53 | 19 19 | 23 23 | 51 51 |
0x0000090 55 55 | 09 09 | 13 13 | 41 41 | 45 45 | 11 11 | 15 15 | 43 43 |
0x00000b0 47 47 | 25 25 | 29 29 | 57 57 | 61 61 | 27 27 | 31 31 | 59 59 |
0x00000d0 63 63 | 77 77 | 05 05 | 33 33 | 37 37 | 03 03 | 07 07 | 35 35 |
0x00000f0 39 39 | 17 17 | 21 21 | 49 49 | 75 75 | 45 45 | 47 47 | 77 77 |
0x0000110 01 01 | 49 49 | 51 51 | 03 03 | 01 01 | 53 53 | 55 55 | 03 03 |
0x0000130 05 05 | 57 57 | 59 59 | 07 07 | 09 09 | 61 61 | 63 63 | 11 11 |
0x0000150 13 13 | 33 33 | 35 35 | 65 65 | 67 67 | 37 37 | 39 39 | 69 69 |
0x0000170 71 71 | 41 41 | 43 43 | 73 73 | 27 27 | 75 75 | 01 01 | 25 25 |
0x0000190 29 29 | 03 03 | 03 03 | 31 31 | 35 35 | 01 01 | 05 05 | 33 33 |
0x00001b0 37 37 | 07 07 | 11 11 | 39 39 | 43 43 | 09 09 | 13 13 | 41 41 |
0x00001d0 45 45 | 65 65 | 69 69 | 15 15 | 19 19 | 67 67 | 71 71 | 17 17 |
0x00001f0 21 21 | 73 73 | 77 77 | 23 23 | 53 53 | 35 35 | 37 37 | 67 67 |
0x0000210 69 69 | 23 23 | 25 25 | 55 55 | 57 57 | 39 39 | 41 41 | 71 71 |
0x0000230 73 73 | 27 27 | 29 29 | 59 59 | 61 61 | 43 43 | 45 45 | 75 75 |
0x0000250 77 77 | 15 15 | 17 17 | 47 47 | 49 49 | 31 31 | 33 33 | 63 63 |
0x0000270 65 65 | 19 19 | 21 21 | 51 51 | 11 11 | 65 65 | 69 69 | 23 23 |
0x0000290 27 27 | 55 55 | 59 59 | 13 13 | 17 17 | 71 71 | 75 75 | 29 29 |

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 2, Part G Page 956
Sample Data

0x00002b0 33 33 | 57 57 | 61 61 | 15 15 | 19 19 | 73 73 | 77 77 | 31 31 |
0x00002d0 35 35 | 47 47 | 51 51 | 05 05 | 09 09 | 63 63 | 67 67 | 21 21 |
0x00002f0 25 25 | 49 49 | 53 53 | 07 07 | 43 43 | 17 17 | 19 19 | 49 49 |
0x0000310 51 51 | 21 21 | 23 23 | 53 53 | 55 55 | 29 29 | 31 31 | 61 61 |
0x0000330 63 63 | 25 25 | 27 27 | 57 57 | 59 59 | 33 33 | 35 35 | 65 65 |
0x0000350 67 67 | 05 05 | 07 07 | 37 37 | 39 39 | 13 13 | 15 15 | 45 45 |
0x0000370 47 47 | 09 09 | 11 11 | 41 41 | 75 75 | 47 47 | 51 51 | 01 01 |
0x0000390 05 05 | 53 53 | 57 57 | 01 01 | 05 05 | 61 61 | 65 65 | 09 09 |
0x00003b0 13 13 | 55 55 | 59 59 | 03 03 | 07 07 | 63 63 | 67 67 | 11 11 |
0x00003d0 15 15 | 37 37 | 41 41 | 69 69 | 73 73 | 45 45 | 49 49 | 77 77 |
0x00003f0 03 03 | 39 39 | 43 43 | 71 71 | 11 11 | 05 05 | 07 07 | 13 13 |

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 2, Part G Page 957
Sample Data

3 ACCESS CODE SAMPLE DATA

Different access codes (GIAC, DIACs, others...)

LAP with LSB as rightmost bit.

Bit transmit order on air

--------------------------------->
LAP: | Preamble: | Sync word: | Trailer: |
--------------------------------------------------
000000 | 5 | 7e7041e3 4000000d | 5 |
ffffff | a | e758b522 7ffffff2 | a |
9e8b33 | 5 | 475c58cc 73345e72 | a |
9e8b34 | 5 | 28ed3c34 cb345e72 | a |
9e8b36 | 5 | 62337b64 1b345e72 | a |
9e8b39 | a | c05747b9 e7345e72 | a |
9e8b3d | 5 | 7084eab0 2f345e72 | a |
9e8b42 | 5 | 64c86d2b 90b45e72 | a |
9e8b48 | a | e3c3725e 04b45e72 | a |
9e8b4f | a | 8c7216a6 bcb45e72 | a |
9e8b57 | a | b2f16c30 fab45e72 | a |
9e8b60 | 5 | 57bd3b22 c1b45e72 | a |
9e8b6a | a | d0b62457 55b45e72 | a |
9e8b75 | a | 81843a39 abb45e72 | a |
9e8b81 | 5 | 0ca96681 e0745e72 | a |
9e8b8e | a | aecd5a5c 1c745e72 | a |
9e8b9c | 5 | 17453fbf ce745e72 | a |
9e8bab | a | f20968ad f5745e72 | a |
9e8bbb | 5 | 015f4a1e f7745e72 | a |
9e8bcc | a | d8c695a0 0cf45e72 | a |
9e8bde | 5 | 614ef043 def45e72 | a |
9e8bf1 | a | ba81ddc7 a3f45e72 | a |
9e8c05 | 5 | 64a7dc4f 680c5e72 | a |
9e8c1a | 5 | 3595c221 960c5e72 | a |
9e8c30 | a | cb35cc0d 830c5e72 | a |
9e8c47 | 5 | 12ac13b3 788c5e72 | a |
9e8c5f | 5 | 2c2f6925 3e8c5e72 | a |
9e8c78 | 5 | 3a351c84 078c5e72 | a |
9e8c92 | 5 | 7396d0f3 124c5e72 | a |
9e8cad | 5 | 5b0fdfc4 6d4c5e72 | a |
9e8cc9 | a | aea2eb38 e4cc5e72 | a |
9e8ce6 | 5 | 756dc6bc 99cc5e72 | a |
9e8d04 | 5 | 214cf934 882c5e72 | a |
9e8d23 | 5 | 37568c95 b12c5e72 | a |
9e8d43 | 5 | 72281560 f0ac5e72 | a |
9e8d64 | 5 | 643260c1 c9ac5e72 | a |
9e8d86 | a | e044f493 986c5e72 | a |
9e8da9 | 5 | 3b8bd917 e56c5e72 | a |
9e8dcd | a | ce26edeb 6cec5e72 | a |

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 2, Part G Page 958
Sample Data

9e8df2 | a | e6bfe2dc 13ec5e72 | a |

9e8e18 | a | 82dcde3d c61c5e72 | a |
9e8e3f | a | 94c6ab9c ff1c5e72 | a |
9e8e67 | a | 969059a6 799c5e72 | a |
9e8e90 | a | c4dfccef 425c5e72 | a |
9e8eba | 5 | 3a7fc2c3 575c5e72 | a |
9e8ee5 | 5 | 57985401 69dc5e72 | a |
9e8f11 | 5 | 0ae2a363 623c5e72 | a |
9e8f3e | a | d12d8ee7 1f3c5e72 | a |
9e8f6c | 5 | 547063a8 0dbc5e72 | a |
9e8f9b | 5 | 063ff6e1 367c5e72 | a |
9e8fcb | a | c9bc5cfe f4fc5e72 | a |
9e8ffc | 5 | 2cf00bec cffc5e72 | a |
9e902e | a | 8ec5052f 5d025e72 | a |
9e9061 | 5 | 1074b15e 61825e72 | a |
9e9095 | a | 9d59ede6 2a425e72 | a |
9e90ca | a | f0be7b24 14c25e72 | a |
9e9100 | 5 | 10e10dd0 c0225e72 | a |
9e9137 | a | f5ad5ac2 fb225e72 | a |
9e916f | a | f7fba8f8 7da25e72 | a |
9e91a8 | 5 | 2f490e5b c5625e72 | a |
9e91e2 | a | 94979982 91e25e72 | a |
9e921d | 5 | 26cda478 2e125e72 | a |
9e9259 | a | aacb81dd 26925e72 | a |
9e9296 | a | bfac7f5b da525e72 | a |
9e92d4 | a | c9a7b0a7 cad25e72 | a |
9e9313 | a | c142bdde 32325e72 | a |
616cec | 5 | 586a491f 0dcda18d | 5 |
616ceb | 5 | 37db2de7 b5cda18d | 5 |
616ce9 | 5 | 7d056ab7 65cda18d | 5 |
616ce6 | a | df61566a 99cda18d | 5 |
616ce2 | 5 | 6fb2fb63 51cda18d | 5 |
616cdd | 5 | 472bf454 2ecda18d | 5 |
616cd7 | a | c020eb21 bacda18d | 5 |
616cd0 | a | af918fd9 02cda18d | 5 |
616cc8 | a | 9112f54f 44cda18d | 5 |
616cbf | 5 | 488b2af1 bf4da18d | 5 |
616cb5 | a | cf803584 2b4da18d | 5 |
616caa | a | 9eb22bea d54da18d | 5 |
616c9e | a | a49cb509 9e4da18d | 5 |
616c91 | 5 | 06f889d4 624da18d | 5 |
616c83 | a | bf70ec37 b04da18d | 5 |
616c74 | a | ed3f797e 8b8da18d | 5 |
616c64 | 5 | 1e695bcd 898da18d | 5 |
616c53 | a | fb250cdf b28da18d | 5 |
616c41 | 5 | 42ad693c 608da18d | 5 |
616c2e | a | a5b7cc14 dd0da18d | 5 |
616c1a | a | 9f9952f7 960da18d | 5 |
616c05 | a | ceab4c99 680da18d | 5 |
616bef | a | d403ddde fdf5a18d | 5 |
616bd8 | 5 | 314f8acc c6f5a18d | 5 |

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 2, Part G Page 959
Sample Data

616bc0 | 5 | 0fccf05a 80f5a18d | 5 |

616ba7 | 5 | 25030d57 7975a18d | 5 |
616b8d | a | dba3037b 6c75a18d | 5 |
616b72 | 5 | 4439ce17 13b5a18d | 5 |
616b56 | a | 8d417247 5ab5a18d | 5 |
616b39 | 5 | 6a5bd76f e735a18d | 5 |
616b1b | 5 | 592e8166 b635a18d | 5 |
616afc | 5 | 28609d46 cfd5a18d | 5 |
616adc | 5 | 51cb8c1f 4ed5a18d | 5 |
616abb | 5 | 7b047112 b755a18d | 5 |
616a99 | 5 | 4871271b e655a18d | 5 |
616a76 | 5 | 24bdc8c4 9b95a18d | 5 |
616a52 | a | edc57494 d295a18d | 5 |
616a2d | a | f989f30f 6d15a18d | 5 |
616a07 | 5 | 0729fd23 7815a18d | 5 |
6169e0 | a | 8bf0ba4f 81e5a18d | 5 |
6169b8 | a | 89a64875 0765a18d | 5 |
61698f | 5 | 6cea1f67 3c65a18d | 5 |
616965 | 5 | 2549d310 29a5a18d | 5 |
61693a | 5 | 48ae45d2 1725a18d | 5 |
61690e | 5 | 7280db31 5c25a18d | 5 |
6168e1 | a | ce1b9f34 61c5a18d | 5 |
6168b3 | 5 | 4b46727b 7345a18d | 5 |
616884 | a | ae0a2569 4845a18d | 5 |
616854 | a | ea5fc581 4a85a18d | 5 |
616823 | 5 | 33c61a3f b105a18d | 5 |
6167f1 | a | c49fb8c5 63f9a18d | 5 |
6167be | 5 | 5a2e0cb4 5f79a18d | 5 |
61678a | 5 | 60009257 1479a18d | 5 |
616755 | a | 86314e62 eab9a18d | 5 |
61671f | 5 | 3defd9bb be39a18d | 5 |
6166e8 | a | bff7e728 c5d9a18d | 5 |
6166b0 | a | bda11512 4359a18d | 5 |
616677 | 5 | 6513b3b1 fb99a18d | 5 |
61663d | a | decd2468 af19a18d | 5 |
616602 | a | f6542b5f d019a18d | 5 |
6165c6 | a | dc44b49b d8e9a18d | 5 |
616589 | 5 | 42f500ea e469a18d | 5 |
61654b | a | bf2885e1 34a9a18d | 5 |
61650c | a | ec4c69b5 4c29a18d | 5 |

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 2, Part G Page 960
Sample Data

4 HEC AND PACKET HEADER SAMPLE DATA

This section contains examples of HECs computed for sample UAP and packet header
contents (Data). The resulting 54 bit packet headers are shown in the rightmost column.
The UAP, Data and HEC values are in hexadecimal notation, while the header is in octal
notation. The header is transmitted from left to right over the air.

UAP Data HEC Header (octal)

--------------------------------------------
00 123 e1 770007 007070 000777
47 123 06 770007 007007 700000
00 124 32 007007 007007 007700
47 124 d5 007007 007070 707077
00 125 5a 707007 007007 077070
47 125 bd 707007 007070 777707
00 126 e2 077007 007007 000777
47 126 05 077007 007070 700000
00 127 8a 777007 007007 070007
47 127 6d 777007 007070 770770
00 11b 9e 770770 007007 777007
47 11b 79 770770 007070 077770
00 11c 4d 007770 007070 770070
47 11c aa 007770 007007 070707
00 11d 25 707770 007070 700700
47 11d c2 707770 007007 000077
00 11e 9d 077770 007070 777007
47 11e 7a 077770 007007 077770
00 11f f5 777770 007070 707777
47 11f 12 777770 007007 007000

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 2, Part G Page 961
Sample Data

5 CRC SAMPLE DATA

This section shows the CRC computed for a sample 10 byte payload and a
UAP of 0x47.

Data:
-----

data[0] = 0x4e
data[1] = 0x01
data[2] = 0x02
data[3] = 0x03
data[4] = 0x04
data[5] = 0x05
data[6] = 0x06
data[7] = 0x07
data[8] = 0x08
data[9] = 0x09

UAP = 0x47

==> CRC = 6d d2

Codeword (hexadecimal notation):

---------------------------------

4e 01 02 03 04 05 06 07 08 09 6d d2

NB: Over the air each byte in the codeword

is sent with the LSB first.

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 2, Part G Page 962
Sample Data

6 COMPLETE SAMPLE PACKETS

6.1 Example of DH1 packet

Packet header: (MSB...LSB)

--------------------------
LT_ADDR = 011
TYPE = 0100 (DH1)
FLOW = 0
ARQN = 1
SEQN = 0

Payload: (MSB...LSB)
--------------------
payload length: 5 bytes
logical channel = 10 (UA/I, Start L2CAP message)
flow = 1
data byte 1 = 00000001
data byte 2 = 00000010
data byte 3 = 00000011
data byte 4 = 00000100
data byte 5 = 00000101

HEC and CRC initialization: (MSB...LSB)

---------------------------------------
uap = 01000111

NO WHITENING USED

AIR DATA (LSB...MSB)

Packet header (incl HEC):

-------------------------
111111000
000000111000
000111000
000111111000000000000000

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 2, Part G Page 963
Sample Data

Payload (incl payload header and CRC):

-------------------------------------------------------------
01110100
10000000
01000000
11000000
00100000
10100000
1110110000110110

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 2, Part G Page 964
Sample Data

6.2 Example of DM1 packet

Packet header: (MSB...LSB)
--------------------------
LT_ADDR = 011
TYPE = 0011 (DM1)
FLOW = 0
ARQN = 1
SEQN = 0

Payload: (MSB...LSB)
--------------------
payload length: 5 bytes
logical channel = 10 (UA/I, Start L2CAP message)
flow = 1
data byte 1 = 00000001
data byte 2 = 00000010
data byte 3 = 00000011
data byte 4 = 00000100
data byte 5 = 00000101

HEC and CRC initialization: (MSB...LSB)

---------------------------------------
uap = 01000111

NO WHITENING USED

AIR DATA (LSB...MSB)

Packet header (incl HEC):

-------------------------
111111000
111111000000
000111000
111000000111111111111000

Payload (incl payload header, FEC23, CRC and 6 padded zeros):

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 2, Part G Page 965
Sample Data

-------------------------------------------------------------
0111010010 11001
0000000100 01011
0000110000 11110
0000100000 00111
1010000011 01100
1011000011 00010
0110000000 10001

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 2, Part G Page 966
Sample Data

7 SECURE SIMPLE PAIRING SAMPLE DATA

This section provides sample data for the Secure Simple Pairing cryptographic functions
(f1, f2, f3, g and the ECDH calculations).

7.1 Elliptic curve sample data

In each data set, the bytes are ordered from least significant on the right to most
significant on the left.

7.1.1 P-192 sample data

7.1.1.1 P-192 data set 1

Private A: 07915f86918ddc27005df1d6cf0c142b625ed2eff4a518ff
Private B: 1e636ca790b50f68f15d8dbe86244e309211d635de00e16d
Public A(x): 15207009984421a6586f9fc3fe7e4329d2809ea51125f8ed
Public A(y): b09d42b81bc5bd009f79e4b59dbbaa857fca856fb9f7ea25
DHKey: fb3ba2012c7e62466e486e229290175b4afebc13fdccee46

7.1.1.2 P-192 data set 2

Private A: 52ec1ca6e0ec973c29065c3ca10be80057243002f09bb43e
Private B: 57231203533e9efe18cc622fd0e34c6a29c6e0fa3ab3bc53
Public A(x): 45571f027e0d690795d61560804da5de789a48f94ab4b07e
Public A(y): 0220016e8a6bce74b45ffec1e664aaa0273b7cbd907a8e2b
DHKey: a20a34b5497332aa7a76ab135cc0c168333be309d463c0c0

7.1.1.3 P-192 data set 3

Private A: 00a0df08eaf51e6e7be519d67c6749ea3f4517cdd2e9e821
Private B: 2bf5e0d1699d50ca5025e8e2d9b13244b4d322a328be1821
Public A(x): 2ed35b430fa45f9d329186d754eeeb0495f0f653127f613d
Public A(y): 27e08db74e424395052ddae7e3d5a8fecb52a8039b735b73
DHKey: 3b3986ba70790762f282a12a6d3bcae7a2ca01e25b87724e

7.1.1.4 P-192 data set 4

Private A: 030a4af66e1a4d590a83e0284fca5cdf83292b84f4c71168
Private B: 12448b5c69ecd10c0471060f2bf86345c5e83c03d16bae2c
Public A(x): f24a6899218fa912e7e4a8ba9357cb8182958f9fa42c968c
Public A(y): 7c0b8a9ebe6ea92e968c3a65f9f1a9716fe826ad88c97032
DHKey: 4a78f83fba757c35f94abea43e92effdd2bc700723c61939

7.1.1.5 P-192 data set 5

Private A: 604df406c649cb460be16244589a40895c0db7367dc11a2f
Private B: 526c2327303cd505b9cf0c012471902bb9e842ce32b0addc

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 2, Part G Page 967
Sample Data

Public A(x): cbe3c629aceb41b73d475a79fbfe8c08cdc80ceec00ee7c9

Public A(y): f9f70f7ae42abda4f33af56f7f6aa383354e453fa1a2bd18
DHKey: 64d4fe35567e6ea0ca31f947e1533a635436d4870ce88c45

7.1.1.6 P-192 data set 6

Private A: 1a2c582a09852979eb2cee18fb0befb9a55a6d06f6a8fad3
Private B: 243778916920d68df535955bc1a3cccd5811133a8205ae41
Public A(x): eca2d8d30bbef3ba8b7d591fdb98064a6c7b870cdcebe67c
Public A(y): 2e4163a44f3ae26e70dae86f1bf786e1a5db5562a8ed9fee
DHKey: 6433b36a7e9341940e78a63e31b3cf023282f7f1e3bf83bd

7.1.1.7 P-192 data set 7

Private A: 0f494dd08b493edb07228058a9f30797ff147a5a2adef9b3
Private B: 2da4cd46d9e06e81b1542503f2da89372e927877becec1be
Public A(x): 9f56a8aa27346d66652a546abacc7d69c17fd66e0853989f
Public A(y): d7234c1464882250df7bbe67e0fa22aae475dc58af0c4210
DHKey: c67beda9baf3c96a30616bf87a7d0ae704bc969e5cad354b

7.1.1.8 P-192 data set 8

Private A: 7381d2bc6ddecb65126564cb1af6ca1985d19fb57f0fff16
Private B: 18e276beff75adc3d520badb3806822e1c820f1064447848
Public A(x): 61c7f3c6f9e09f41423dce889de1973d346f2505a5a3b19b
Public A(y): 919972ff4cd6aed8a4821e3adc358b41f7be07ede20137df
DHKey: 6931496eef2fcfb03e0b1eef515dd4e1b0115b8b241b0b84

7.1.1.9 P-192 data set 9

Private A: 41c7b484ddc37ef6b7952c379f87593789dac6e4f3d8d8e6
Private B: 33e4eaa77f78216e0e99a9b200f81d2ca20dc74ad62d9b78
Public A(x): 9f09c773adb8e7b66b5d986cd15b143341a66d824113c15f
Public A(y): d2000a91738217ab8070a76c5f96c03de317dfab774f4837
DHKey: a518f3826bb5fa3d5bc37da4217296d5b6af51e5445c6625

7.1.1.10 P-192 data set 10

Private A: 703cf5ee9c075f7726d0bb36d131c664f5534a6e6305d631
Private B: 757291c620a0e7e9dd13ce09ceb729c0ce1980e64d569b5f
Public A(x): fa2b96d382cf894aeeb0bd985f3891e655a6315cd5060d03
Public A(y): f7e8206d05c7255300cc56c88448158c497f2df596add7a2
DHKey: 12a3343bb453bb5408da42d20c2d0fcc18ff078f56d9c68c

7.1.2 P-256 sample data

7.1.2.1 P-256 data set 1

Private A: 3f49f6d4 a3c55f38 74c9b3e3 d2103f50 4aff607b eb40b799 5899b8a6 cd3c1abd

Private B: 55188b3d 32f6bb9a 900afcfb eed4e72a 59cb9ac2 f19d7cfb 6b4fdd49 f47fc5fd

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 2, Part G Page 968
Sample Data

Public A(x): 20b003d2 f297be2c 5e2c83a7 e9f9a5b9 eff49111 acf4fddb cc030148 0e359de6
Public A(y): dc809c49 652aeb6d 63329abf 5a52155c 766345c2 8fed3024 741c8ed0 1589d28b
Public B(x): 1ea1f0f0 1faf1d96 09592284 f19e4c00 47b58afd 8615a69f 559077b2 2faaa190
Public B(y): 4c55f33e 429dad37 7356703a 9ab85160 472d1130 e28e3676 5f89aff9 15b1214a
DHKey: ec0234a3 57c8ad05 341010a6 0a397d9b 99796b13 b4f866f1 868d34f3 73bfa698

7.1.2.2 P-256 data set 2

Private A: 06a51669 3c9aa31a 6084545d 0c5db641 b48572b9 7203ddff b7ac73f7 d0457663

Private B: 529aa067 0d72cd64 97502ed4 73502b03 7e8803b5 c60829a5 a3caa219 505530ba
Public A(x): 2c31a47b 5779809e f44cb5ea af5c3e43 d5f8faad 4a8794cb 987e9b03 745c78dd
Public A(y): 91951218 3898dfbe cd52e240 8e43871f d0211091 17bd3ed4 eaf84377 43715d4f
Public B(x): f465e43f f23d3f1b 9dc7dfc0 4da87581 84dbc966 204796ec cf0d6cf5 e16500cc
Public B(y): 0201d048 bcbbd899 eeefc424 164e33c2 01c2b010 ca6b4d43 a8a155ca d8ecb279
DHKey: ab85843a 2f6d883f 62e5684b 38e30733 5fe6e194 5ecd1960 4105c6f2 3221eb69

7.2 Hash functions sample data

In each data set, the bytes are ordered from least significant on the right to most
significant on the left.

7.2.1 f1()

7.2.1.1 f1() with P-192 inputs

Set 1a
U: 15207009984421a6586f9fc3fe7e4329d2809ea51125f8ed
V: 356b31938421fbbf2fb331c89fd588a69367e9a833f56812
X: d5cb8454d177733effffb2ec712baeab
Z: 00
output: 1bdc955a9d542ffc9f9e670cdf665010

Set 1b
U: 15207009984421a6586f9fc3fe7e4329d2809ea51125f8ed
V: 356b31938421fbbf2fb331c89fd588a69367e9a833f56812
X: d5cb8454d177733effffb2ec712baeab
Z: 80
output: 611325ebcb6e5269b868113306095fa6

Set 1c
U: 15207009984421a6586f9fc3fe7e4329d2809ea51125f8ed
V: 356b31938421fbbf2fb331c89fd588a69367e9a833f56812
X: d5cb8454d177733effffb2ec712baeab
Z: 81
output: b68df39fd8a406b06a6c517d3666cf91

Set 2a (swapped U and V inputs compared with set 1)

U: 356b31938421fbbf2fb331c89fd588a69367e9a833f56812

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 2, Part G Page 969
Sample Data

V: 15207009984421a6586f9fc3fe7e4329d2809ea51125f8ed
X: d5cb8454d177733effffb2ec712baeab
Z: 00
output: f4e1ec4b88f305e81477627b1643a927

Set 2b (swapped U and V inputs compared with set 1)

U: 356b31938421fbbf2fb331c89fd588a69367e9a833f56812
V: 15207009984421a6586f9fc3fe7e4329d2809ea51125f8ed
X: d5cb8454d177733effffb2ec712baeab
Z: 80
output: ac6aa7cfa96ae99dd3a74225adb068ae

Set 2c (swapped U and V inputs compared with set 1)

U: 356b31938421fbbf2fb331c89fd588a69367e9a833f56812
V: 15207009984421a6586f9fc3fe7e4329d2809ea51125f8ed
X: d5cb8454d177733effffb2ec712baeab
Z: 81
output: 5ad4721258aa1fa06082edad980d0cc5

Set 3a (U and V set to same value as U in set 1)

U: 15207009984421a6586f9fc3fe7e4329d2809ea51125f8ed
V: 15207009984421a6586f9fc3fe7e4329d2809ea51125f8ed
X: d5cb8454d177733effffb2ec712baeab
Z: 00
output: 49125fc1e8cdc615826c15e5d23ede41

Set 3b (U and V set to same value as V in set 1)

U: 356b31938421fbbf2fb331c89fd588a69367e9a833f56812
V: 356b31938421fbbf2fb331c89fd588a69367e9a833f56812
X: d5cb8454d177733effffb2ec712baeab
Z: 80
output: 159f204c520565175c2b9c523acad2eb

Set 3c (U and V set to same value as V in set 1)

U: 356b31938421fbbf2fb331c89fd588a69367e9a833f56812
V: 356b31938421fbbf2fb331c89fd588a69367e9a833f56812
X: d5cb8454d177733effffb2ec712baeab
Z: 81
output: 9a162ff9a8235e5b12539ba0ff9179da

7.2.1.2 f1() with P-256 inputs

Set 1a
U: 20b003d2f297be2c5e2c83a7e9f9a5b9eff49111acf4fddbcc0301480e359de6
V: 55188b3d32f6bb9a900afcfbeed4e72a59cb9ac2f19d7cfb6b4fdd49f47fc5fd
X: d5cb8454d177733effffb2ec712baeab
Z: 00
output: D301CE92CC7B9E3F51D2924B8B33FACA

Set 1b
U: 20b003d2f297be2c5e2c83a7e9f9a5b9eff49111acf4fddbcc0301480e359de6

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 2, Part G Page 970
Sample Data

V: 55188b3d32f6bb9a900afcfbeed4e72a59cb9ac2f19d7cfb6b4fdd49f47fc5fd
X: d5cb8454d177733effffb2ec712baeab
Z: 80
output: 7E431112C10DE8A3984C8AC8149FF6EC

7.2.2 g()

7.2.2.1 g() with P-192 inputs

Set 1
U: 15207009984421a6586f9fc3fe7e4329d2809ea51125f8ed
V: 356b31938421fbbf2fb331c89fd588a69367e9a833f56812
X: d5cb8454d177733effffb2ec712baeab
Y: a6e8e7cc25a75f6e216583f7ff3dc4cf
output: 52146a1e
output (decimal): 1377069598
6 digits (decimal):069598

7.2.2.2 g() with P-256 inputs

Set 1
U: 20b003d2f297be2c5e2c83a7e9f9a5b9eff49111acf4fddbcc0301480e359de6
V: 55188b3d32f6bb9a900afcfbeed4e72a59cb9ac2f19d7cfb6b4fdd49f47fc5fd
X: d5cb8454d177733effffb2ec712baeab
Y: a6e8e7cc25a75f6e216583f7ff3dc4cf
output: 000240E0
output (decimal): 147680
6 digits (decimal): 147680

7.2.3 f2()

7.2.3.1 f2() with P-192 inputs

Set 1
W: fb3ba2012c7e62466e486e229290175b4afebc13fdccee46
N1: d5cb8454d177733effffb2ec712baeab
N2: a6e8e7cc25a75f6e216583f7ff3dc4cf
keyID: 62746c6b
A1: 56123737bfce
A2: a713702dcfc1
output: c234c1198f3b520186ab92a2f874934e

7.2.3.2 f2() with P-256 inputs

Set 1
W: ec0234a357c8ad05341010a60a397d9b99796b13b4f866f1868d34f373bfa698
N1: d5cb8454d177733effffb2ec712baeab
N2: a6e8e7cc25a75f6e216583f7ff3dc4cf
keyID: 62746c6b
A1: 56123737bfce

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 2, Part G Page 971
Sample Data

A2: a713702dcfc1
output: 47300bb95c7404129450674b1741104d

7.2.4 f3()

7.2.4.1 f3() with P-192 inputs

Set 1
W: fb3ba2012c7e62466e486e229290175b4afebc13fdccee46
N1: d5cb8454d177733effffb2ec712baeab
N2: a6e8e7cc25a75f6e216583f7ff3dc4cf
R: 12a3343bb453bb5408da42d20c2d0fc8
IOcap: 000000
A1: 56123737bfce
A2: a713702dcfc1
output: 5e6a346b8add7ee80e7ec0c2461b1509

Set 2
W: fb3ba2012c7e62466e486e229290175b4afebc13fdccee46
N1: d5cb8454d177733effffb2ec712baeab
N2: a6e8e7cc25a75f6e216583f7ff3dc4cf
R: 12a3343bb453bb5408da42d20c2d0fc8
IOcap: 000001
A1: 56123737bfce
A2: a713702dcfc1
output: 7840e5445a13e3ce6e48a2decbe51482

Set 3
W: fb3ba2012c7e62466e486e229290175b4afebc13fdccee46
N1: d5cb8454d177733effffb2ec712baeab
N2: a6e8e7cc25a75f6e216583f7ff3dc4cf
R: 12a3343bb453bb5408da42d20c2d0fc8
IOcap: 000002
A1: 56123737bfce
A2: a713702dcfc1
output: da9afb5c6c9dbe0af4722b532520c4b3

Set 4
W: fb3ba2012c7e62466e486e229290175b4afebc13fdccee46
N1: d5cb8454d177733effffb2ec712baeab
N2: a6e8e7cc25a75f6e216583f7ff3dc4cf
R: 12a3343bb453bb5408da42d20c2d0fc8
IOcap: 000003
A1: 56123737bfce
A2: a713702dcfc1
output: 2c0f220c50075285852e01bcee4b5f90

Set 5

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 2, Part G Page 972
Sample Data

W: fb3ba2012c7e62466e486e229290175b4afebc13fdccee46
N1: d5cb8454d177733effffb2ec712baeab
N2: a6e8e7cc25a75f6e216583f7ff3dc4cf
R: 12a3343bb453bb5408da42d20c2d0fc8
IOcap: 000100
A1: 56123737bfce
A2: a713702dcfc1
output: 0a096af0fa61dce0933987febe95fc7d

Set 6
W: fb3ba2012c7e62466e486e229290175b4afebc13fdccee46
N1: d5cb8454d177733effffb2ec712baeab
N2: a6e8e7cc25a75f6e216583f7ff3dc4cf
R: 12a3343bb453bb5408da42d20c2d0fc8
IOcap: 000101
A1: 56123737bfce
A2: a713702dcfc1
output: 49b8d74007888e770e1a49d6810069b9

Set 7
W: fb3ba2012c7e62466e486e229290175b4afebc13fdccee46
N1: d5cb8454d177733effffb2ec712baeab
N2: a6e8e7cc25a75f6e216583f7ff3dc4cf
R: 12a3343bb453bb5408da42d20c2d0fc8
IOcap: 000102
A1: 56123737bfce
A2: a713702dcfc1
output: 309cd0327dec2514894a0c88b101a436

Set 8
W: fb3ba2012c7e62466e486e229290175b4afebc13fdccee46
N1: d5cb8454d177733effffb2ec712baeab
N2: a6e8e7cc25a75f6e216583f7ff3dc4cf
R: 12a3343bb453bb5408da42d20c2d0fc8
IOcap: 000103
A1: 56123737bfce
A2: a713702dcfc1
output: 4512274ba875b156c2187e2061b90434

Set 9 (same as set 1 with N1 and N2 swapped and A1 and A2 swapped)

W: fb3ba2012c7e62466e486e229290175b4afebc13fdccee46
N1: a6e8e7cc25a75f6e216583f7ff3dc4cf
N2: d5cb8454d177733effffb2ec712baeab
R: 12a3343bb453bb5408da42d20c2d0fc8
IOcap: 000000
A1: a713702dcfc1
A2: 56123737bfce
output: 8d56dc59e70855f563b5e85e42d5964e

Set 10 (same as set 2 with N1 and N2 swapped and A1 and A2 swapped)

W: fb3ba2012c7e62466e486e229290175b4afebc13fdccee46

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 2, Part G Page 973
Sample Data

N1: a6e8e7cc25a75f6e216583f7ff3dc4cf
N2: d5cb8454d177733effffb2ec712baeab
R: 12a3343bb453bb5408da42d20c2d0fc8
IOcap: 000001
A1: a713702dcfc1
A2: 56123737bfce
output: c92fdacbf0ce931e9c4087a9dfb7bc0b

Set 11 (same as set 3 with N1 and N2 swapped and A1 and A2 swapped)

W: fb3ba2012c7e62466e486e229290175b4afebc13fdccee46
N1: a6e8e7cc25a75f6e216583f7ff3dc4cf
N2: d5cb8454d177733effffb2ec712baeab
R: 12a3343bb453bb5408da42d20c2d0fc8
IOcap: 000002
A1: a713702dcfc1
A2: 56123737bfce
output: 52ac910200dc34285bbbf2144883c498

Set 12 (same as set 4 with N1 and N2 swapped and A1 and A2 swapped)

W: fb3ba2012c7e62466e486e229290175b4afebc13fdccee46
N1: a6e8e7cc25a75f6e216583f7ff3dc4cf
N2: d5cb8454d177733effffb2ec712baeab
R: 12a3343bb453bb5408da42d20c2d0fc8
IOcap: 000003
A1: a713702dcfc1
A2: 56123737bfce
output: c419d677e0d426e6bb36de5fa54c5041

Set 13 (same as set 5 with N1 and N2 swapped and A1 and A2 swapped)

W: fb3ba2012c7e62466e486e229290175b4afebc13fdccee46
N1: a6e8e7cc25a75f6e216583f7ff3dc4cf
N2: d5cb8454d177733effffb2ec712baeab
R: 12a3343bb453bb5408da42d20c2d0fc8
IOcap: 000100
A1: a713702dcfc1
A2: 56123737bfce
output: fb0e1f9f7c623c1bf2675fcff1551137

Set 14 (same as set 6 with N1 and N2 swapped and A1 and A2 swapped)

W: fb3ba2012c7e62466e486e229290175b4afebc13fdccee46
N1: a6e8e7cc25a75f6e216583f7ff3dc4cf
N2: d5cb8454d177733effffb2ec712baeab
R: 12a3343bb453bb5408da42d20c2d0fc8
IOcap: 000101
A1: a713702dcfc1
A2: 56123737bfce
output: 16c7be68184f1170fbbb2bef5a9c515d

Set 15 (same as set 7 with N1 and N2 swapped and A1 and A2 swapped)

W: fb3ba2012c7e62466e486e229290175b4afebc13fdccee46
N1: a6e8e7cc25a75f6e216583f7ff3dc4cf

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 2, Part G Page 974
Sample Data

N2: d5cb8454d177733effffb2ec712baeab
R: 12a3343bb453bb5408da42d20c2d0fc8
IOcap: 000102
A1: a713702dcfc1
A2: 56123737bfce
output: 24849f33d3ac05fef9034c18d9adb310

Set 16 (same as set 8 with N1 and N2 swapped and A1 and A2 swapped)

W: fb3ba2012c7e62466e486e229290175b4afebc13fdccee46
N1: a6e8e7cc25a75f6e216583f7ff3dc4cf
N2: d5cb8454d177733effffb2ec712baeab
R: 12a3343bb453bb5408da42d20c2d0fc8
IOcap: 000103
A1: a713702dcfc1
A2: 56123737bfce
output: e0f484bb0b071483285903e85094046b

Set 17
W: fb3ba2012c7e62466e486e229290175b4afebc13fdccee46
N1: d5cb8454d177733effffb2ec712baeab
N2: a6e8e7cc25a75f6e216583f7ff3dc4cf
R: 12a3343bb453bb5408da42d20c2d0fc8
IOcap: 010000
A1: 56123737bfce
A2: a713702dcfc1
output: 4bf22677415ed90aceb21873c71c1884

Set 18
W: fb3ba2012c7e62466e486e229290175b4afebc13fdccee46
N1: d5cb8454d177733effffb2ec712baeab
N2: a6e8e7cc25a75f6e216583f7ff3dc4cf
R: 12a3343bb453bb5408da42d20c2d0fc8
IOcap: 010001
A1: 56123737bfce
A2: a713702dcfc1
output: 0d4b97992eb570efb369cfe45e1681b5

Set 19
W: fb3ba2012c7e62466e486e229290175b4afebc13fdccee46
N1: d5cb8454d177733effffb2ec712baeab
N2: a6e8e7cc25a75f6e216583f7ff3dc4cf
R: 12a3343bb453bb5408da42d20c2d0fc8
IOcap: 010002
A1: 56123737bfce
A2: a713702dcfc1
output: 0f0906bbfa75e95c471e97c4211b2741

Set 20
W: fb3ba2012c7e62466e486e229290175b4afebc13fdccee46
N1: d5cb8454d177733effffb2ec712baeab
N2: a6e8e7cc25a75f6e216583f7ff3dc4cf

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 2, Part G Page 975
Sample Data

R: 12a3343bb453bb5408da42d20c2d0fc8
IOcap: 010003
A1: 56123737bfce
A2: a713702dcfc1
output: 88f1f60ce1ff4bf8aa08a170dd061d4e

Set 21
W: fb3ba2012c7e62466e486e229290175b4afebc13fdccee46
N1: d5cb8454d177733effffb2ec712baeab
N2: a6e8e7cc25a75f6e216583f7ff3dc4cf
R: 12a3343bb453bb5408da42d20c2d0fc8
IOcap: 010100
A1: 56123737bfce
A2: a713702dcfc1
output: 940f88f25317c358d9bd2f146778e36b

Set 22
W: fb3ba2012c7e62466e486e229290175b4afebc13fdccee46
N1: d5cb8454d177733effffb2ec712baeab
N2: a6e8e7cc25a75f6e216583f7ff3dc4cf
R: 12a3343bb453bb5408da42d20c2d0fc8
IOcap: 010101
A1: 56123737bfce
A2: a713702dcfc1
output: 591396355ac4dc72be05a15e718ec945

Set 23
W: fb3ba2012c7e62466e486e229290175b4afebc13fdccee46
N1: d5cb8454d177733effffb2ec712baeab
N2: a6e8e7cc25a75f6e216583f7ff3dc4cf
R: 12a3343bb453bb5408da42d20c2d0fc8
IOcap: 010102
A1: 56123737bfce
A2: a713702dcfc1
output: a3dc055f656abb1d6e11d3f37340189a

Set 24
W: fb3ba2012c7e62466e486e229290175b4afebc13fdccee46
N1: d5cb8454d177733effffb2ec712baeab
N2: a6e8e7cc25a75f6e216583f7ff3dc4cf
R: 12a3343bb453bb5408da42d20c2d0fc8
IOcap: 010103
A1: 56123737bfce
A2: a713702dcfc1
output: fd5412a22ba5dd893852608f8ab0c934

Set 25 (same as set 1 with N1 and N2 swapped and A1 and A2 swapped)

W: fb3ba2012c7e62466e486e229290175b4afebc13fdccee46
N1: a6e8e7cc25a75f6e216583f7ff3dc4cf
N2: d5cb8454d177733effffb2ec712baeab
R: 12a3343bb453bb5408da42d20c2d0fc8

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 2, Part G Page 976
Sample Data

IOcap: 010000
A1: a713702dcfc1
A2: 56123737bfce
output: 2a742039c5fd6c6faafce17b619ac56f

Set 26 (same as set 2 with N1 and N2 swapped and A1 and A2 swapped)

W: fb3ba2012c7e62466e486e229290175b4afebc13fdccee46
N1: a6e8e7cc25a75f6e216583f7ff3dc4cf
N2: d5cb8454d177733effffb2ec712baeab
R: 12a3343bb453bb5408da42d20c2d0fc8
IOcap: 010001
A1: a713702dcfc1
A2: 56123737bfce
output: a60d89efb52db7905179a6c63b8f212a

Set 27 (same as set 3 with N1 and N2 swapped and A1 and A2 swapped)

W: fb3ba2012c7e62466e486e229290175b4afebc13fdccee46
N1: a6e8e7cc25a75f6e216583f7ff3dc4cf
N2: d5cb8454d177733effffb2ec712baeab
R: 12a3343bb453bb5408da42d20c2d0fc8
IOcap: 010002
A1: a713702dcfc1
A2: 56123737bfce
output: cb02f803d755fd936f0a832f4ee9fd4a

Set 28 (same as set 4 with N1 and N2 swapped and A1 and A2 swapped)

W: fb3ba2012c7e62466e486e229290175b4afebc13fdccee46
N1: a6e8e7cc25a75f6e216583f7ff3dc4cf
N2: d5cb8454d177733effffb2ec712baeab
R: 12a3343bb453bb5408da42d20c2d0fc8
IOcap: 010003
A1: a713702dcfc1
A2: 56123737bfce
output: 00786c04a24561485aaf22808871b874

Set 29 (same as set 5 with N1 and N2 swapped and A1 and A2 swapped)

W: fb3ba2012c7e62466e486e229290175b4afebc13fdccee46
N1: a6e8e7cc25a75f6e216583f7ff3dc4cf
N2: d5cb8454d177733effffb2ec712baeab
R: 12a3343bb453bb5408da42d20c2d0fc8
IOcap: 010100
A1: a713702dcfc1
A2: 56123737bfce
output: 2a58ef2d99281d472a88027423f8215f

Set 30 (same as set 6 with N1 and N2 swapped and A1 and A2 swapped)

W: fb3ba2012c7e62466e486e229290175b4afebc13fdccee46
N1: a6e8e7cc25a75f6e216583f7ff3dc4cf
N2: d5cb8454d177733effffb2ec712baeab
R: 12a3343bb453bb5408da42d20c2d0fc8
IOcap: 010101

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 2, Part G Page 977
Sample Data

A1: a713702dcfc1
A2: 56123737bfce
output: ff7ab3752a144232f2cbbcbf979f5517

Set 31 (same as set 7 with N1 and N2 swapped and A1 and A2 swapped)

W: fb3ba2012c7e62466e486e229290175b4afebc13fdccee46
N1: a6e8e7cc25a75f6e216583f7ff3dc4cf
N2: d5cb8454d177733effffb2ec712baeab
R: 12a3343bb453bb5408da42d20c2d0fc8
IOcap: 010102
A1: a713702dcfc1
A2: 56123737bfce
output: 9d7fccef23625b1cc684fbf3f8b0e182

Set 32 (same as set 8 with N1 and N2 swapped and A1 and A2 swapped)

W: fb3ba2012c7e62466e486e229290175b4afebc13fdccee46
N1: a6e8e7cc25a75f6e216583f7ff3dc4cf
N2: d5cb8454d177733effffb2ec712baeab
R: 12a3343bb453bb5408da42d20c2d0fc8
IOcap: 010103
A1: a713702dcfc1
A2: 56123737bfce
output: 864f87e26dece4dfdde30ade1e463d4f

7.2.4.2 f3() with P-256 inputs

Set 1
W: ec0234a357c8ad05341010a60a397d9b99796b13b4f866f1868d34f373bfa698
N1: d5cb8454d177733effffb2ec712baeab
N2: a6e8e7cc25a75f6e216583f7ff3dc4cf
R: 12a3343bb453bb5408da42d20c2d0fc8
IOcap: 000000
A1: 56123737bfce
A2: a713702dcfc1
output: 5634c83c9996a86b53473fe25979ec90

7.2.5 [This section is no longer used]

7.2.6 h4()

Set 1a
keyID: 6274646b
A1: 56123737bfce
A2: a713702dcfc1
input: 6274646b56123737bfcea713702dcfc1
W: c234c1198f3b520186ab92a2f874934e
output: b089c4e39d7c192c3aba3c2109d24c0dc039e700adf3a263008e65a8b00fb1fa
Device Authentication Key: b089c4e39d7c192c3aba3c2109d24c0d

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 2, Part G Page 978
Sample Data

7.2.7 h5()

Set 1a
R1: d5cb8454d177733effffb2ec712baeab
R2: a6e8e7cc25a75f6e216583f7ff3dc4cf
input: d5cb8454d177733effffb2ec712baeaba6e8e7cc25a75f6e216583f7ff3dc4cf
W: b089c4e39d7c192c3aba3c2109d24c0d
output: 746af87e1eeb1137c683b97d9d421f911f3ddf100403871b362958c458976d65
SRES_C: 746af87e
SRES_P: 1eeb1137
ACO: c683b97d9d421f91

7.2.8 h3()

Set 1a
keyID: 6274616b
A1: 56123737bfce
A2: a713702dcfc1
ACO: c683b97d9d421f91
input: 6274616b56123737bfcea713702dcfc1c683b97d9d421f91
W: c234c1198f3b520186ab92a2f874934e
output: 677b377f74a5d501121c46492d4cb489e27fe151026ab47f271a47399c8969ff
AES Encryption key: 677b377f74a5d501121c46492d4cb489

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 2, Part G Page 979
Sample Data

8 WHITENING SEQUENCE SAMPLE DATA

This section shows the output of the whitening sequence generator.

Whitening Whitening
Sequence LFSR
(=D7) D7.....D0
-----------------------
1 1111111
1 1101111
1 1001111
0 0001111
0 0011110
0 0111100
1 1111000
1 1100001
1 1010011
0 0110111
1 1101110
1 1001101
0 0001011
0 0010110
0 0101100
1 1011000
0 0100001
1 1000010
0 0010101
0 0101010
1 1010100
0 0111001
1 1110010
1 1110101
1 1111011
1 1100111
1 1011111
0 0101111
1 1011110
0 0101101
1 1011010
0 0100101
1 1001010
0 0000101
0 0001010
0 0010100
0 0101000
1 1010000
0 0110001
1 1100010
1 1010101

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 2, Part G Page 980
Sample Data

0 0111011
1 1110110
1 1111101
1 1101011
1 1000111
0 0011111
0 0111110
1 1111100
1 1101001
1 1000011
0 0010111
0 0101110
1 1011100
0 0101001
1 1010010
0 0110101
1 1101010
1 1000101
0 0011011
0 0110110
1 1101100
1 1001001
0 0000011
0 0000110
0 0001100
0 0011000
0 0110000
1 1100000
1 1010001
0 0110011
1 1100110
1 1011101
0 0101011
1 1010110
0 0111101
1 1111010
1 1100101
1 1011011
0 0100111
1 1001110
0 0001101
0 0011010
0 0110100
1 1101000
1 1000001
0 0010011
0 0100110
1 1001100
0 0001001
0 0010010
0 0100100

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 2, Part G Page 981
Sample Data

1 1001000
0 0000001
0 0000010
0 0000100
0 0001000
0 0010000
0 0100000
1 1000000
0 0010001
0 0100010
1 1000100
0 0011001
0 0110010
1 1100100
1 1011001
0 0100011
1 1000110
0 0011101
0 0111010
1 1110100
1 1111001
1 1100011
1 1010111
0 0111111
1 1111110
1 1101101
1 1001011
0 0000111
0 0001110
0 0011100
0 0111000
1 1110000
1 1110001
1 1110011
1 1110111
1 1111111

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 2, Part G Page 982
Sample Data

9 FEC SAMPLE DATA

================================================

Rate 2/3 FEC -- (15,10) Shortened Hamming Code

================================================

Data is in hexadecimal notation, the codewords are in binary notation.

The codeword bits are sent from left to right over the air interface.
The space in the codeword indicates the start of parity bits.

Data: Codeword:

0x001 1000000000 11010

0x002 0100000000 01101
0x004 0010000000 11100
0x008 0001000000 01110
0x010 0000100000 00111
0x020 0000010000 11001
0x040 0000001000 10110
0x080 0000000100 01011
0x100 0000000010 11111
0x200 0000000001 10101

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 2, Part G Page 983
Sample Data

10 ENCRYPTION KEY SAMPLE DATA

For Section 10.1 to Section 10.5, the hexadecimal sample data is written with the least
significant byte at the leftmost position and the most significant byte at the rightmost
position. Within each byte, the least significant bit (LSB) is at the rightmost position and
the most significant bit (MSB) is at the leftmost position Thus, a line reading:

aco: 48afcdd4bd40fef76693b113

means aco[0]=0x48, ac[1]=0xAF, ..., aco[11]=0x13. The LSB of aco[11] is 1 and the
MSB of aco[11] is 0.

Key [ i]: denotes the ith sub-key in Ar or A'r;

round r: denotes the input to the rth round;
added ->: denotes the input to round 3 in
A'r after adding original input (of round 1).

10.1 Four tests of E1

rand :00000000000000000000000000000000
address :000000000000
key :00000000000000000000000000000000
round 1:00000000000000000000000000000000
Key [ 1]:00000000000000000000000000000000
Key [ 2]:4697b1baa3b7100ac537b3c95a28ac64
round 2:78d19f9307d2476a523ec7a8a026042a
Key [ 3]:ecabaac66795580df89af66e66dc053d
Key [ 4]:8ac3d8896ae9364943bfebd4969b68a0
round 3:600265247668dda0e81c07bbb30ed503
Key [ 5]:5d57921fd5715cbb22c1be7bbc996394
Key [ 6]:2a61b8343219fdfb1740e6511d41448f
round 4:d7552ef7cc9dbde568d80c2215bc4277
Key [ 7]:dd0480dee731d67f01a2f739da6f23ca
Key [ 8]:3ad01cd1303e12a1cd0fe0a8af82592c
round 5:fb06bef32b52ab8f2a4f2b6ef7f6d0cd
Key [ 9]:7dadb2efc287ce75061302904f2e7233
Key [10]:c08dcfa981e2c4272f6c7a9f52e11538
round 6:b46b711ebb3cf69e847a75f0ab884bdd
Key [11]:fc2042c708e409555e8c147660ffdfd7
Key [12]:fa0b21001af9a6b9e89e624cd99150d2
round 7:c585f308ff19404294f06b292e978994
Key [13]:18b40784ea5ba4c80ecb48694b4e9c35
Key [14]:454d54e5253c0c4a8b3fcca7db6baef4
round 8:2665fadb13acf952bf74b4ab12264b9f
Key [15]:2df37c6d9db52674f29353b0f011ed83

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 2, Part G Page 984
Sample Data

Key [16]:b60316733b1e8e70bd861b477e2456f1
Key [17]:884697b1baa3b7100ac537b3c95a28ac
round 1:158ffe43352085e8a5ec7a88e1ff2ba8
Key [ 1]:e9e5dfc1b3a79583e9e5dfc1b3a79583
Key [ 2]:7595bf57e0632c59f435c16697d4c864
round 2:0b5cc75febcdf7827ca29ec0901b6b5b
Key [ 3]:e31b96afcc75d286ef0ae257cbbc05b7
Key [ 4]:0d2a27b471bc0108c6263aff9d9b3b6b
round 3:e4278526c8429211f7f2f0016220aef4
added ->:f1b68365fd6217f952de6a89831fd95c
Key [ 5]:98d1eb5773cf59d75d3b17b3bc37c191
Key [ 6]:fd2b79282408ddd4ea0aa7511133336f
round 4:d0304ad18337f86040145d27aa5c8153
Key [ 7]:331227756638a41d57b0f7e071ee2a98
Key [ 8]:aa0dd8cc68b406533d0f1d64aabacf20
round 5:84db909d213bb0172b8b6aaf71bf1472
Key [ 9]:669291b0752e63f806fce76f10e119c8
Key [10]:ef8bdd46be8ee0277e9b78adef1ec154
round 6:f835f52921e903dfa762f1df5abd7f95
Key [11]:f3902eb06dc409cfd78384624964bf51
Key [12]:7d72702b21f97984a721c99b0498239d
round 7:ae6c0b4bb09f25c6a5d9788a31b605d1
Key [13]:532e60bceaf902c52a06c2c283ecfa32
Key [14]:181715e5192efb2a64129668cf5d9dd4
round 8:744a6235b86cc0b853cc9f74f6b65311
Key [15]:83017c1434342d4290e961578790f451
Key [16]:2603532f365604646ff65803795ccce5
Key [17]:882f7c907b565ea58dae1c928a0dcf41
sres :056c0fe6
aco :48afcdd4bd40fef76693b113
-----------------------------------------
rand :bc3f30689647c8d7c5a03ca80a91eceb
address :7ca89b233c2d
key :159dd9f43fc3d328efba0cd8a861fa57
round 1:bc3f30689647c8d7c5a03ca80a91eceb
Key [ 1]:159dd9f43fc3d328efba0cd8a861fa57
Key [ 2]:326558b3c15551899a97790e65ff669e
round 2:3e950edf197615638cc19c09f8fedc9b
Key [ 3]:62e879b65b9f53bbfbd020c624b1d682
Key [ 4]:73415f30bac8ab61f410adc9442992db
round 3:6a7640791cb536678936c5ecd4ae5a73
Key [ 5]:5093cfa1d31c1c48acd76df030ea3c31
Key [ 6]:0b4acc2b8f1f694fc7bd91f4a70f3009
round 4:fca2c022a577e2ffb2aa007589693ec7
Key [ 7]:2ca43fc817947804ecff148d50d6f6c6
Key [ 8]:3fcd73524b533e00b7f7825bea2040a4
round 5:e97f8ea4ed1a6f4a36ffc179dc6bb563
Key [ 9]:6c67bec76ae8c8cc4d289f69436d3506
Key [10]:95ed95ee8cb97e61d75848464bffb379
round 6:38b07261d7340d028749de1773a415c7
Key [11]:ff566c1fc6b9da9ac502514550f3e9d2

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 2, Part G Page 985
Sample Data

Key [12]:ab5ce3f5c887d0f49b87e0d380e12f47
round 7:58241f1aed7c1c3e047d724331a0b774
Key [13]:a2cab6f95eac7d655dbe84a6cd4c47f5
Key [14]:f5caff88af0af8c42a20b5bbd2c8b460
round 8:3d1aaeff53c0910de63b9788b13c490f
Key [15]:185099c1131cf97001e2f36fda415025
Key [16]:a0ebb82676bc75e8378b189eff3f6b1d
Key [17]:cf5b348aaee27ae332b4f1bfa10289a6
round 1:2e4b417b9a2a9cfd7d8417d9a6a556eb
Key [ 1]:fe78b835f26468ab069fd3991b086fda
Key [ 2]:095c5a51c6fa6d3ac1d57fa19aa382bd
round 2:b8bca81d6bb45af9d92beadd9300f5ed
Key [ 3]:1af866df817fd9f4ec00bc704192cffc
Key [ 4]:f4a8a059c1f575f076f5fbb24bf16590
round 3:351aa16dec2c3a4787080249ed323eae
added ->:1b65e2167656d6bafa8c19904bd79445
Key [ 5]:8c9d18d9356a9954d341b4286e88ea1f
Key [ 6]:5c958d370102c9881bf753e69c7da029
round 4:2ce8fef47dda6a5bee74372e33e478a2
Key [ 7]:7eb2985c3697429fbe0da334bb51f795
Key [ 8]:af900f4b63a1138e2874bfb7c628b7b8
round 5:572787f563e1643c1c862b7555637fb4
Key [ 9]:834c8588dd8f3d4f31117a488420d69b
Key [10]:bc2b9b81c15d9a80262f3f48e9045895
round 6:16b4968c5d02853c3a43aa4cdb5f26ac
Key [11]:f08608c9e39ad3147cba61327919c958
Key [12]:2d4131decf4fa3a959084714a9e85c11
round 7:10e4120c7cccef9dd4ba4e6da8571b01
Key [13]:c934fd319c4a2b5361fa8eef05ae9572
Key [14]:4904c17aa47868e40471007cde3a97c0
round 8:f9081772498fed41b6ffd72b71fcf6c6
Key [15]:ea5e28687e97fa3f833401c86e6053ef
Key [16]:1168f58252c4ecfccafbdb3af857b9f2
Key [17]:b3440f69ef951b78b5cbd6866275301b
sres :8d5205c5
aco :3ed75df4abd9af638d144e94
-----------------------------------------
rand :0891caee063f5da1809577ff94ccdcfb
address :c62f19f6ce98
key :45298d06e46bac21421ddfbed94c032b
round 1:0891caee063f5da1809577ff94ccdcfb
Key [ 1]:45298d06e46bac21421ddfbed94c032b
Key [ 2]:8f03e1e1fe1c191cad35a897bc400597
round 2:1c6ca013480a685c1b28e0317f7167e1
Key [ 3]:4f2ce3a092dde854ef496c8126a69e8e
Key [ 4]:968caee2ac6d7008c07283daec67f2f2
round 3:06b4915f5fcc1fc551a52048f0af8a26
Key [ 5]:ab0d5c31f94259a6bf85ee2d22edf56c
Key [ 6]:dfb74855c0085ce73dc17b84bfd50a92
round 4:077a92b040acc86e6e0a877db197a167
Key [ 7]:8f888952662b3db00d4e904e7ea53b5d

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 2, Part G Page 986
Sample Data

Key [ 8]:5e18bfcc07799b0132db88cd6042f599
round 5:7204881fb300914825fdc863e8ceadf3
Key [ 9]:bfca91ad9bd3d1a06c582b1d5512dddf
Key [10]:a88bc477e3fa1d5a59b5e6cf793c7a41
round 6:27031131d86cea2d747deb4f756143aa
Key [11]:f3cfb8dac8aea2a6a8ef95af3a2a2767
Key [12]:77beb90670c5300b03aa2b2232d3d40c
round 7:fc8c13d49149b1ce8d86f96e44a00065
Key [13]:b578373650af36a06e19fe335d726d32
Key [14]:6bcee918c7d0d24dfdf42237fcf99d53
round 8:04ef5f5a7ddf846cda0a07782fc23866
Key [15]:399f158241eb3e079f45d7b96490e7ea
Key [16]:1bcfbe98ecde2add52aa63ea79fb917a
Key [17]:ee8bc03ec08722bc2b075492873374af
round 1:d989d7a40cde7032d17b52f8117b69d5
Key [ 1]:2ecc6cc797cc41a2ab02007f6af396ae
Key [ 2]:acfaef7609c12567d537ae1cf9dc2198
round 2:8e76eb9a29b2ad5eea790db97aee37c1
Key [ 3]:079c8ff9b73d428df879906a0b87a6c8
Key [ 4]:19f2710baf403a494193d201f3a8c439
round 3:346bb7c35b2539676375aafe3af69089
added ->:edf48e675703a955b2f0fc062b71f95c
Key [ 5]:d623a6498f915cb2c8002765247b2f5a
Key [ 6]:900109093319bc30108b3d9434a77a72
round 4:fafb6c1f3ebbd2477be2da49dd923f69
Key [ 7]:e28e2ee6e72e7f4e5b5c11f10d204228
Key [ 8]:8e455cd11f8b9073a2dfa5413c7a4bc5
round 5:7c72230df588060a3cf920f9b0a08f06
Key [ 9]:28afb26e2c7a64238c41cefc16c53e74
Key [10]:d08dcafc2096395ba0d2dddd0e471f4d
round 6:55991df991db26ff00073a12baa3031d
Key [11]:fcffdcc3ad8faae091a7055b934f87c1
Key [12]:f8df082d77060252c02d91e55bd6a7d6
round 7:70ec682ff864375f63701fa4f6be5377
Key [13]:bef3706e523d708e8a44147d7508bc35
Key [14]:3e98ab283ca2422d56a56cf8b06caeb3
round 8:172f12ec933da85504b4ea5c90f8f0ea
Key [15]:87ad9625d06645d22598dd5ef811ea2c
Key [16]:8bd3db0cc8168009e5da90877e13a36f
Key [17]:0e74631d813a8351ac7039b348c41b42
sres :00507e5f
aco :2a5f19fbf60907e69f39ca9f
-----------------------------------------
rand :0ecd61782b4128480c05dc45542b1b8c
address :f428f0e624b3
key :35949a914225fabad91995d226de1d92
round 1:0ecd61782b4128480c05dc45542b1b8c
Key [ 1]:35949a914225fabad91995d226de1d92
Key [ 2]:ea6b3dcccc8ee5d88de349fa5010404f
round 2:8935e2e263fbc4b9302cabdfc06bce3e
Key [ 3]:920f3a0f2543ce535d4e7f25ad80648a

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 2, Part G Page 987
Sample Data

Key [ 4]:ad47227edf9c6874e80ba80ebb95d2c9
round 3:b4c8b878675f184a0c72f3dab51f8f05
Key [ 5]:81a941ca7202b5e884ae8fa493ecac3d
Key [ 6]:bcde1520bee3660e86ce2f0fb78b9157
round 4:77ced9f2fc42bdd5c6312b87fc2377c5
Key [ 7]:c8eee7423d7c6efa75ecec0d2cd969d3
Key [ 8]:910b3f838a02ed441fbe863a02b4a1d0
round 5:fe28e8056f3004d60bb207e628b39cf2
Key [ 9]:56c647c1e865eb078348962ae070972d
Key [10]:883965da77ca5812d8104e2b640aec0d
round 6:1f2ba92259d9e88101518f145a33840f
Key [11]:61d4cb7e4f8868a283327806a9bd8d4d
Key [12]:9f57de3a3ff310e21dc1e696ce060304
round 7:cc9b5d0218d29037e88475152ebebb2f
Key [13]:7aa1d8adc1aeed7127ef9a18f6eb2d8e
Key [14]:b4db9da3bf865912acd14904c7f7785d
round 8:b04d352bedc02682e4a7f59d7cda1dba
Key [15]:a13d7141ef1f6c7d867e3d175467381b
Key [16]:08b2bc058e50d6141cdd566a307e1acc
Key [17]:057b2b4b4be5dc0ac49e50489b8006c9
round 1:5cfacc773bae995cd7f1b81e7c9ec7df
Key [ 1]:1e717950f5828f3930fe4a9395858815
Key [ 2]:d1623369b733d98bbc894f75866c544c
round 2:d571ffa21d9daa797b1a0a3c962fc64c
Key [ 3]:4abf27664ae364cc8a7e5bcf88214cc4
Key [ 4]:2aaedda8dc4933dd6aeaf6e5c0d5a482
round 3:e17c8e498a00f125bf654c938c23f36d
added ->:bd765a3eb1ae8a796856048df0c1bab2
Key [ 5]:bc7f8ab2d86000f47b1946cc8d7a7a2b
Key [ 6]:6b28544cb13ec6c5d98470df2cf900b7
round 4:a9727c26f2f06bd9920e83c8605dcd76
Key [ 7]:1be840d9107f2c9523f66bb19f5464a1
Key [ 8]:61d6fb1aa2f0c2b26fb2a3d6de8c177c
round 5:aeff751f146eab7e4626b2e2c9e2fb39
Key [ 9]:adabfc82570c568a233173099f23f4c2
Key [10]:b7df6b55ad266c0f1ff7452101f59101
round 6:cf412b95f454d5185e67ca671892e5bd
Key [11]:8e04a7282a2950dcbaea28f300e22de3
Key [12]:21362c114433e29bda3e4d51f803b0cf
round 7:16165722fe4e07ef88f8056b17d89567
Key [13]:710c8fd5bb3cbb5f132a7061de518bd9
Key [14]:0791de7334f4c87285809343f3ead3bd
round 8:28854cd6ad4a3c572b15490d4b81bc3f
Key [15]:4f47f0e5629a674bfcd13770eb3a3bd9
Key [16]:58a6d9a16a284cc0aead2126c79608a1
Key [17]:a564082a0a98399f43f535fd5cefad34
sres :80e5629c
aco :a6fe4dcde3924611d3cc6ba1

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 2, Part G Page 988
Sample Data

10.2 Four tests of E21

rand :00000000000000000000000000000000
address :000000000000
round 1:00000000000000000000000000000000
Key [ 1]:00000000000000000000000000000006
Key [ 2]:4697b1baa3b7100ac537b3c95a28dc94
round 2:98611307ab76bbde9a86af1ce8cad412
Key [ 3]:ecabaac66795580df89af66e665d863d
Key [ 4]:8ac3d8896ae9364943bfebd4a2a768a0
round 3:820999ad2e6618f4b578974beeedf9e7
added ->:820999ad2e6618f4b578974beeedf9e7
Key [ 5]:5d57921fd5715cbb22c1bedb1c996394
Key [ 6]:2a61b8343219fdfb1740e9541d41448f
round 4:acd6edec87581ac22dbdc64ea4ced3a2
Key [ 7]:dd0480dee731d67f01ba0f39da6f23ca
Key [ 8]:3ad01cd1303e12a18dcfe0a8af82592c
round 5:1c7798732f09fbfe25795a4a2fbc93c2
Key [ 9]:7dadb2efc287ce7b0c1302904f2e7233
Key [10]:c08dcfa981e2f4572f6c7a9f52e11538
round 6:c05b88b56aa70e9c40c79bb81cd911bd
Key [11]:fc2042c708658a555e8c147660ffdfd7
Key [12]:fa0b21002605a6b9e89e624cd99150d2
round 7:abacc71b481c84c798d1bdf3d62f7e20
Key [13]:18b407e44a5ba4c80ecb48694b4e9c35
Key [14]:454d57e8253c0c4a8b3fcca7db6baef4
round 8:e8204e1183ae85cf19edb2c86215b700
Key [15]:2d0b946d9db52674f29353b0f011ed83
Key [16]:76c316733b1e8e70bd861b477e2456f1
Key [17]:8e4697b1baa3b7100ac537b3c95a28ac
Ka :d14ca028545ec262cee700e39b5c39ee
-----------------------------------------
rand :2dd9a550343191304013b2d7e1189d09
address :cac4364303b6
round 1:cac4364303b6cac4364303b6cac43643
Key [ 1]:2dd9a550343191304013b2d7e1189d0f
Key [ 2]:14c4335b2c43910c5dcc71d81a14242b
round 2:e169f788aad45a9011f11db5270b1277
Key [ 3]:55bfb712cba168d1a48f6e74cd9f4388
Key [ 4]:2a2b3aacca695caef2821b0fb48cc253
round 3:540f9c76652e92c44987c617035037bf
added ->:9ed3d23566e45c007fcac9a1c9146dfc
Key [ 5]:a06aab22d9a287384042976b4b6b00ee
Key [ 6]:c229d054bb72e8eb230e6dcdb32d16b7
round 4:83659a41675f7171ea57909dc5a79ab4
Key [ 7]:23c4812ab1905ddf77dedaed4105649a
Key [ 8]:40d87e272a7a1554ae2e85e3638cdf52
round 5:0b9382d0ed4f2fccdbb69d0db7b130a4
Key [ 9]:bdc064c6a39f6b84fe40db359f62a3c4
Key [10]:58228db841ce3cee983aa721f36aa1b9
round 6:c6ebda0f8f489792f09c189568226c1f

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 2, Part G Page 989
Sample Data

Key [11]:a815bacd6fa747a0d4f52883ac63ebe7
Key [12]:a9ce513b38ea006c333ecaaefcf1d0f8
round 7:75a8aba07e69c9065bcd831c40115116
Key [13]:3635e074792d4122130e5b824e52cd60
Key [14]:511bdb61bb28de72a5d794bffbf407df
round 8:57a6e279dcb764cf7dd6a749dd60c735
Key [15]:a32f5f21044b6744b6d913b13cdb4c0a
Key [16]:9722bbaeef281496ef8c23a9d41e92f4
Key [17]:807370560ad7e8a13a054a65a03b4049
Ka :e62f8bac609139b3999aedbc9d228042
-----------------------------------------
rand :dab3cffe9d5739d1b7bf4a667ae5ee24
address :02f8fd4cd661
round 1:02f8fd4cd66102f8fd4cd66102f8fd4c
Key [ 1]:dab3cffe9d5739d1b7bf4a667ae5ee22
Key [ 2]:e315a8a65d809ec7c289e69c899fbdcc
round 2:ef85ff081b8709405e19f3e275cec7dc
Key [ 3]:df6a119bb50945fc8a3394e7216448f3
Key [ 4]:87fe86fb0d58b5dd0fb3b6b1dab51d07
round 3:aa25c21bf577d92dd97381e3e9edcc54
added ->:a81dbf5723d8dbd524bf5782ebe5c918
Key [ 5]:36cc253c506c0021c91fac9d8c469e90
Key [ 6]:d5fda00f113e303809b7f7d78a1a2b0e
round 4:9e69ce9b53caec3990894d2baed41e0d
Key [ 7]:c14b5edc10cabf16bc2a2ba4a8ae1e40
Key [ 8]:74c6131afc8dce7e11b03b1ea8610c16
round 5:a5460fa8cedca48a14fd02209e01f02e
Key [ 9]:346cfc553c6cbc9713edb55f4dcbc96c
Key [10]:bddf027cb059d58f0509f8963e9bdec6
round 6:92b33f11eadcacc5a43dd05f13d334dd
Key [11]:8eb9e040c36c4c0b4a7fd3dd354d53c4
Key [12]:c6ffecdd5e135b20879b9dfa4b34bf51
round 7:fb0541aa5e5df1a61c51aef606eb5a41
Key [13]:bf12f5a6ba08dfc4fda4bdfc68c997d9
Key [14]:37c4656b9215f3c959ea688fb64ad327
round 8:f0bbd2b94ae374346730581fc77a9c98
Key [15]:e87bb0d86bf421ea4f779a8eee3a866c
Key [16]:faa471e934fd415ae4c0113ec7f0a5ad
Key [17]:95204a80b8400e49db7cf6fd2fd40d9a
Ka :b0376d0a9b338c2e133c32b69cb816b3
-----------------------------------------
rand :13ecad08ad63c37f8a54dc56e82f4dc1
address :9846c5ead4d9
round 1:9846c5ead4d99846c5ead4d99846c5ea
Key [ 1]:13ecad08ad63c37f8a54dc56e82f4dc7
Key [ 2]:ad04f127bed50b5e671d6510d392eaed
round 2:97374e18cdd0a6f7a5aa49d1ac875c84
Key [ 3]:57ad159e5774fa222f2f3039b9cd5101
Key [ 4]:9a1e9e1068fede02ef90496e25fd8e79
round 3:9dd3260373edd9d5f4e774826b88fd2d
added ->:0519ebe9a7c6719331d1485bf3cec2c7

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 2, Part G Page 990
Sample Data

Key [ 5]:378dce167db62920b0b392f7cfca316e
Key [ 6]:db4277795c87286faee6c9e9a6b71a93
round 4:40ec6563450299ac4e120d88672504d6
Key [ 7]:ec01aa2f5a8a793b36c1bb858d254380
Key [ 8]:2921a66cfa5bf74ac535424564830e98
round 5:57287bbb041bd6a56c2bd931ed410cd4
Key [ 9]:07018e45aab61b3c3726ee3d57dbd5f6
Key [10]:627381f0fa4c02b0c7d3e7dfbffc3333
round 6:66affa66a8dcd36e36bf6c3f1c6a276e
Key [11]:33b57c925bd5551999f716e138efbe79
Key [12]:a6dc7f9aa95bcc9243aebd12608f657a
round 7:450e65184fd8c72c578d5cdecb286743
Key [13]:a6a6db00fd8c72a28ea57ea542f6e102
Key [14]:dcf3377daeb2e24e61f0ad6620951c1f
round 8:e5eb180b519a4e673f21b7c4f4573f3d
Key [15]:621240b9506b462a7fa250da41844626
Key [16]:ae297810f01f43dc35756cd119ee73d6
Key [17]:b959835ec2501ad3894f8b8f1f4257f9
Ka :5b61e83ad04d23e9d1c698851fa30447

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 2, Part G Page 991
Sample Data

10.3 Three tests of E22

(for K_temp and overlay generation)

rand :001de169248850245a5f7cc7f0d6d633
PIN :d5a51083a04a1971f18649ea8b79311a
round 1:001de169248850245a5f7cc7f0d6d623
Key [ 1]:d5a51083a04a1971f18649ea8b79311a
Key [ 2]:7317cdbff57f9b99f9810a2525b17cc7
round 2:5f05c143347b59acae3cb002db23830f
Key [ 3]:f08bd258adf1d4ae4a54d8ccb26220b2
Key [ 4]:91046cbb4ccc43db18d6dd36ca7313eb
round 3:c8f3e3300541a25b6ac5a80c3105f3c4
added ->:c810c45921c9f27f302424cbc1dbc9e7
Key [ 5]:67fb2336f4d9f069da58d11c82f6bd95
Key [ 6]:4fed702c75bd72c0d3d8f38707134c50
round 4:bd5e0c3a97fa55b91a3bbbf306ebb978
Key [ 7]:41c947f80cdc0464c50aa89070af314c
Key [ 8]:680eecfa8daf41c7109c9a5cb1f26d75
round 5:21c1a762c3cc33e75ce8976a73983087
Key [ 9]:6e33fbd94d00ff8f72e8a7a0d2cebc4c
Key [10]:f4d726054c6b948add99fabb5733ddc3
round 6:56d0df484345582f6b574a449ba155eb
Key [11]:4eda2425546a24cac790f49ef2453b53
Key [12]:cf2213624ed1510408a5a3e00b7333df
round 7:120cf9963fe9ff22993f7fdf9600d9b8
Key [13]:d04b1a25b0b8fec946d5ecfa626d04c9
Key [14]:01e5611b0f0e140bdb64585fd3ae5269
round 8:a6337400ad8cb47fefb91332f5cb2713
Key [15]:f15b2dc433f534f61bf718770a3698b1
Key [16]:f990d0273d8ea2b9e0b45917a781c720
Key [17]:f41b3cc13d4301297bb6bdfcb3e5a1dd
Ka :539e4f2732e5ae2de1e0401f0813bd0d
-----------------------------------------
rand :67ed56bfcf99825f0c6b349369da30ab
PIN :7885b515e84b1f082cc499976f1725ce
round 1:67ed56bfcf99825f0c6b349369da30bb
Key [ 1]:7885b515e84b1f082cc499976f1725ce
Key [ 2]:72445901fdaf506beb036f4412512248
round 2:6b160b66a1f6c26c1f3432f463ef5aa1
Key [ 3]:59f0e4982e97633e5e7fd133af8f2c5b
Key [ 4]:b4946ec77a41bf7c729d191e33d458ab
round 3:3f22046c964c3e5ca2a26ec9a76a9f67
added ->:580f5ad359e5c003ae0da25ace44cfdc
Key [ 5]:eb0b839f97bdf534183210678520bbef
Key [ 6]:cff0bc4a94e5c8b2a2d24d9f59031e19
round 4:87aa61fc0ff88e744c195249b9a33632
Key [ 7]:592430f14d8f93db95dd691af045776d
Key [ 8]:3b55b404222bf445a6a2ef5865247695
round 5:83dcf592a854226c4dcd94e1ecf1bc75
Key [ 9]:a9714b86319ef343a28b87456416bd52

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 2, Part G Page 992
Sample Data

Key [10]:e6598b24390b3a0bf2982747993b0d78
round 6:dee0d13a52e96bcf7c72045a21609fc6
Key [11]:62051d8c51973073bff959b032c6e1e2
Key [12]:29e94f4ab73296c453c833e217a1a85b
round 7:08488005761e6c7c4dbb203ae453fe3a
Key [13]:0e255970b3e2fc235f59fc5acb10e8ce
Key [14]:d0dfbb3361fee6d4ffe45babf1cd7abf
round 8:0d81e89bddde7a7065316c47574feb8f
Key [15]:c12eee4eb38b7a171f0f736003774b40
Key [16]:8f962523f1c0abd9a087a0dfb11643d3
Key [17]:24be1c66cf8b022f12f1fb4c60c93fd1
Ka :04435771e03a9daceb8bb1a493ee9bd8
-----------------------------------------
rand :40a94509238664f244ff8e3d13b119d3
PIN :1ce44839badde30396d03c4c36f23006
round 1:40a94509238664f244ff8e3d13b119c3
Key [ 1]:1ce44839badde30396d03c4c36f23006
Key [ 2]:6dd97a8f91d628be4b18157af1a9dcba
round 2:0eac5288057d9947a24eabc1744c4582
Key [ 3]:fef9583d5f55fd4107ad832a725db744
Key [ 4]:fc3893507016d7c1db2bd034a230a069
round 3:60b424f1082b0cc3bd61be7b4c0155f0
added ->:205d69f82bb17031f9604c465fb26e33
Key [ 5]:0834d04f3e7e1f7f85f0c1db685ab118
Key [ 6]:1852397f9a3723169058e9b62bb3682b
round 4:2c6b65a49d66af6566675afdd6fa7d7d
Key [ 7]:6c10da21d762ae4ac1ba22a96d9007b4
Key [ 8]:9aa23658b90470a78d686344b8a9b0e7
round 5:a2c537899665113a42f1ac24773bdc31
Key [ 9]:137dee3bf879fe7bd02fe6d888e84f16
Key [10]:466e315a1863f47d0f93bc6827cf3450
round 6:e26982980d79b21ed3e20f8c3e71ba96
Key [11]:0b33cf831465bb5c979e6224d7f79f7c
Key [12]:92770660268ede827810d707a0977d73
round 7:e7b063c4e2e3110b89b7e1631c762dd5
Key [13]:7be30ae4961cf24ca17625a77bb7a9f8
Key [14]:be65574a33ae30e6e82dbd2826d3cc1a
round 8:7a963e37b2c2e76b489cfe40a2cf00e5
Key [15]:ed0ba7dd30d60a5e69225f0a33011e5b
Key [16]:765c990f4445e52b39e6ed6105ad1c4f
Key [17]:52627bf9f35d94f30d5b07ef15901adc
Ka :9cde4b60f9b5861ed9df80858bac6f7f

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 2, Part G Page 993
Sample Data

10.4 Tests of E22 with Pin augmenting

for PIN lengths 1,...,16 bytes

rand :24b101fd56117d42c0545a4247357048
PIN length =16 octets
PIN :fd397c7f5c1f937cdf82d8816cc377e2
round 1:24b101fd56117d42c0545a4247357058
Key [ 1]:fd397c7f5c1f937cdf82d8816cc377e2
Key [ 2]:0f7aac9c9b53f308d9fdbf2c78e3c30e
round 2:838edfe1226266953ccba8379d873107
Key [ 3]:0b8ac18d4bb44fad2efa115e43945abc
Key [ 4]:887b16b062a83bfa469772c25b456312
round 3:8cd0c9283120aba89a7f9d635dd4fe3f
added ->:a881cad5673128ea5ad3f7211a096e67
Key [ 5]:2248cbe6d299e9d3e8fd35a91178f65b
Key [ 6]:b92af6237385bd31f8fb57fb1bdd824e
round 4:2648d9c618a622b10ef80c4dbaf68b99
Key [ 7]:2bf5ffe84a37878ede2d4c30be60203b
Key [ 8]:c9cb6cec60cb8a8f29b99fcf3e71e40f
round 5:b5a7d9e96f68b14ccebf361de3914d0f
Key [ 9]:5c2f8a702e4a45575b103b0cce8a91c6
Key [10]:d453db0c9f9ddbd11e355d9a34d9b11b
round 6:632a091e7eefe1336857ddafd1ff3265
Key [11]:32805db7e59c5ed4acabf38d27e3fece
Key [12]:fde3a8eedfa3a12be09c1a8a00890fd7
round 7:048531e9fd3efa95910540150f8b137b
Key [13]:def07eb23f3a378f059039a2124bc4c2
Key [14]:2608c58f23d84a09b9ce95e5caac1ab4
round 8:461814ec7439d412d0732f0a6f799a6a
Key [15]:0a7ed16481a623e56ee1442ffa74f334
Key [16]:12add59aca0d19532f1516979954e369
Key [17]:dd43d02d39ffd6a386a4b98b4ac6eb23
Ka :a5f2adf328e4e6a2b42f19c8b74ba884
-----------------------------------------
rand :321964061ac49a436f9fb9824ac63f8b
PIN length =15 octets
PIN :ad955d58b6b8857820ac1262d617a6
address :0314c0642543
round 1:321964061ac49a436f9fb9824ac63f9b
Key [ 1]:ad955d58b6b8857820ac1262d617a603
Key [ 2]:f281736f68e3d30b2ac7c67f125dc416
round 2:7c4a4ece1398681f4bafd309328b7770
Key [ 3]:43c157f4c8b360387c32ab330f9c9aa8
Key [ 4]:3a3049945a298f6d076c19219c47c3cb
round 3:9672b00738bdfaf9bd92a855bc6f3afb
added ->:a48b1401228194bad23161d7f6357960
Key [ 5]:c8e2eaa6d73b7de18f3228ab2173bc69
Key [ 6]:8623f44488222e66a293677cf30bf2bb
round 4:9b30247aad3bf133712d034b46d21c68
Key [ 7]:f3e500902fba31db9bae50ef30e484a4

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 2, Part G Page 994
Sample Data

Key [ 8]:49d4b1137c18f4752dd9955a5a8d2f43
round 5:4492c25fda08083a768b4b5588966b23
Key [ 9]:9d59c451989e74785cc097eda7e42ab8
Key [10]:251de25f3917dcd99c18646107a641fb
round 6:21ae346635714d2623041f269978c0ee
Key [11]:80b8f78cb1a49ec0c3e32a238e60fddf
Key [12]:beb84f4d20a501e4a24ecfbde481902b
round 7:9b56a3d0f8932f20c6a77a229514fb00
Key [13]:852571b44f35fd9d9336d3c1d2506656
Key [14]:d0a0d510fb06ba76e69b8ee3ebc1b725
round 8:6cd8492b2fd31a86978bcdf644eb08a8
Key [15]:c7ffd523f32a874ed4a93430a25976de
Key [16]:16cdcb25e62964876d951fdcc07030d3
Key [17]:def32c0e12596f9582e5e3c52b303f52
Ka :c0ec1a5694e2b48d54297911e6c98b8f
-----------------------------------------
rand :d4ae20c80094547d7051931b5cc2a8d6
PIN length =14 octets
PIN :e1232e2c5f3b833b3309088a87b6
address :fabecc58e609
round 1:d4ae20c80094547d7051931b5cc2a8c6
Key [ 1]:e1232e2c5f3b833b3309088a87b6fabe
Key [ 2]:5f0812b47cd3e9a30d7707050fffa1f2
round 2:1f45f16be89794bef33e4547c9c0916a
Key [ 3]:77b681944763244ffa3cd71b248b79b5
Key [ 4]:e2814e90e04f485958ce58c9133e2be6
round 3:b10d2f4ac941035263cee3552d774d2f
added ->:65bb4f82c9d5572f131f764e7139f5e9
Key [ 5]:520acad20801dc639a2c6d66d9b79576
Key [ 6]:c72255cdb61d42be72bd45390dd25ba5
round 4:ead4dc34207b6ea721c62166e155aaad
Key [ 7]:ebf04c02075bf459ec9c3ec06627d347
Key [ 8]:a1363dd2812ee800a4491c0c74074493
round 5:f507944f3018e20586d81d7f326aae9d
Key [ 9]:b0b6ba79493dc833d7f425be7b8dadb6
Key [10]:08cd23e536b9b9b53e85eb004cba3111
round 6:fff450f4302a2b3571e8405e148346da
Key [11]:fec22374c6937dcd26171f4d2edfada3
Key [12]:0f1a8ef5979c69ff44f620c2e007b6e4
round 7:de558779589897f3402a90ee78c3f921
Key [13]:901fb66f0779d6aad0c0fba1fe812cb5
Key [14]:a0cab3cd15cd23603adc8d4474efb239
round 8:b2df0aa0c9f07fbbaa02f510a29cf540
Key [15]:18edc3f4296dd6f1dea13f7c143117a1
Key [16]:8d3d52d700a379d72ded81687f7546c7
Key [17]:5927badfe602f29345f840bb53e1dea6
Ka :d7b39be13e3692c65b4a9e17a9c55e17
-----------------------------------------
rand :272b73a2e40db52a6a61c6520549794a
PIN length =13 octets
PIN :549f2694f353f5145772d8ae1e

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 2, Part G Page 995
Sample Data

address :20487681eb9f
round 1:272b73a2e40db52a6a61c6520549795a
Key [ 1]:549f2694f353f5145772d8ae1e204876
Key [ 2]:42c855593d66b0c458fd28b95b6a5fbf
round 2:d7276dc8073f7677c31f855bde9501e2
Key [ 3]:75d0a69ae49a2da92e457d767879df52
Key [ 4]:b3aa7e7492971afaa0fb2b64827110df
round 3:71aae503831133d19bc452da4d0e409b
added ->:56d558a1671ee8fbf12518884857b9c1
Key [ 5]:9c8cf1604a98e9a503c342e272de5cf6
Key [ 6]:d35bc2df6b85540a27642106471057d9
round 4:f41a709c89ea80481aa3d2b9b2a9f8ca
Key [ 7]:b454dda74aeb4eff227ba48a58077599
Key [ 8]:bcba6aec050116aa9b7c6a9b7314d796
round 5:20fdda20f4a26b1bd38eb7f355a7be87
Key [ 9]:d41f8a9de0a716eb7167a1b6e321c528
Key [10]:5353449982247782d168ab43f17bc4d8
round 6:a70e316997eeed49a5a9ef9ba5e913b5
Key [11]:32cbc9cf1a81e36a45153972347ce4ac
Key [12]:5747619006cf4ef834c749f2c4b9feb6
round 7:e66f2317a825f589f76b47b6aa6e73fb
Key [13]:f9b68beba0a09d2a570a7dc88cc3c3c2
Key [14]:55718f9a4f0b1f9484e8c6b186a41a4b
round 8:5f68f940440a9798e074776019804ada
Key [15]:4ecc29be1b4d78433f6aa30db974a7fb
Key [16]:8470a066ffb00cda7b08059599f919f5
Key [17]:f39a36d74e960a051e1ca98b777848f4
Ka :9ac64309a37c25c3b4a584fc002a1618
-----------------------------------------
rand :7edb65f01a2f45a2bc9b24fb3390667e
PIN length =12 octets
PIN :2e5a42797958557b23447ca8
address :04f0d2737f02
round 1:7edb65f01a2f45a2bc9b24fb3390666e
Key [ 1]:2e5a42797958557b23447ca804f0d273
Key [ 2]:18a97c856561eb23e71af8e9e1be4799
round 2:3436e12db8ffdc1265cb5a86da2fed0b
Key [ 3]:7c0908dcbc73201e17c4f7aa1ab8aec8
Key [ 4]:7cb58833602fbe4194c7cc797ce8c454
round 3:caed6af4226f67e4ad1914620803ef2a
added ->:b4c8cf04389eac4611b438993b935544
Key [ 5]:f4dce7d607b5234562d0ebb2267b08b8
Key [ 6]:560b75c5545751fd8fa99fa4346e654b
round 4:ee67c87d6f74bb75db98f68bff0192c1
Key [ 7]:32f10cefd8d3e6424c6f91f1437808af
Key [ 8]:a934a46045be30fb3be3a5f3f7b18837
round 5:792398dcbeb8d10bdb07ae3c819e943c
Key [ 9]:a0f12e97c677a0e8ac415cd2c8a7ca88
Key [10]:e27014c908785f5ca03e8c6a1da3bf13
round 6:e778b6e0c3e8e7edf90861c7916d97a8
Key [11]:1b4a4303bcc0b2e0f41c72d47654bd9f

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 2, Part G Page 996
Sample Data

Key [12]:4b1302a50046026d6c9054fc8387965a
round 7:1fafddc7efa5f04c1dec1869d3f2d9bb
Key [13]:58c334bb543d49eca562cdbe0280e0fc
Key [14]:bdb60d383c692d06476b76646c8dec48
round 8:3d7c326d074bd6aa222ea050f04a3c7f
Key [15]:78c0162506be0b5953e8403c01028f93
Key [16]:24d7dbbe834dbd7b67f57fcf0d39d60f
Key [17]:2e74f1f3331c0f6585e87b2f715e187e
Ka :d3af4c81e3f482f062999dee7882a73b
-----------------------------------------
rand :26a92358294dce97b1d79ec32a67e81a
PIN length =11 octets
PIN :05fbad03f52fa9324f7732
address :b9ac071f9d70
round 1:26a92358294dce97b1d79ec32a67e80a
Key [ 1]:05fbad03f52fa9324f7732b9ac071f9d
Key [ 2]:2504c9691c04a18480c8802e922098c0
round 2:0be20e3d76888e57b6bf77f97a8714fb
Key [ 3]:576b2791d1212bea8408212f2d43e77e
Key [ 4]:90ae36dcce8724adb618f912d1b27297
round 3:1969667060764453257d906b7e58bd5b
added ->:3f12892849c312c494542ea854bfa551
Key [ 5]:bc492c42c9e87f56ec31af5474e9226e
Key [ 6]:c135d1dbed32d9519acfb4169f3e1a10
round 4:ac404205118fe771e54aa6f392da1153
Key [ 7]:83ccbdbbaf17889b7d18254dc9252fa1
Key [ 8]:80b90a1767d3f2848080802764e21711
round 5:41795e89ae9a0cf776ffece76f47fd7a
Key [ 9]:cc24e4a86e8eed129118fd3d5223a1dc
Key [10]:7b1e9c0eb9dab083574be7b7015a62c9
round 6:29ca9e2f87ca00370ef1633505bfba4b
Key [11]:888e6d88cf4beb965cf7d4f32b696baa
Key [12]:6d642f3e5510b0b043a44daa2cf5eec0
round 7:81fc891c3c6fd99acc00028a387e2366
Key [13]:e224f85da2ab63a23e2a3a036e421358
Key [14]:c8dc22aaa739e2cb85d6a0c08226c7d0
round 8:e30b537e7a000e3d2424a9c0f04c4042
Key [15]:a969aa818c6b324bae391bedcdd9d335
Key [16]:6974b6f2f07e4c55f2cc0435c45bebd1
Key [17]:134b925ebd98e6b93c14aee582062fcb
Ka :be87b44d079d45a08a71d15208c5cb50
-----------------------------------------
rand :0edef05327eab5262430f21fc91ce682
PIN length =10 octets
PIN :8210e47390f3f48c32b3
address :7a3cdfe377d1
round 1:0edef05327eab5262430f21fc91ce692
Key [ 1]:8210e47390f3f48c32b37a3cdfe377d1
Key [ 2]:c6be4c3e425e749b620a94c779e33a7e
round 2:07ca3c7a7a6bcbc31d79a856d9cffc0e
Key [ 3]:2587cec2a4b8e4f996a9ed664350d5dd

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 2, Part G Page 997
Sample Data

Key [ 4]:70e4bf72834d9d3dbb7eb2c239216dc0
round 3:792ad2ac4e4559d1463714d2f161b6f4
added ->:7708c2ff692f0ef7626706cd387d9c66
Key [ 5]:6696e1e7f8ac037e1fff3598f0c164e2
Key [ 6]:23dbfe4d0b561bea08fbcef25e49b648
round 4:7d8c71a9d7fbdcbd851bdf074550b100
Key [ 7]:b03648acd021550edee904431a02f00c
Key [ 8]:cb169220b7398e8f077730aa4bf06baa
round 5:b6fcaa45064ffd557e4b7b30cfbb83e0
Key [ 9]:af602c2ba16a454649951274c2be6527
Key [10]:5d60b0a7a09d524143eca13ad680bc9c
round 6:b3416d391a0c26c558843debd0601e9e
Key [11]:9a2f39bfe558d9f562c5f09a5c3c0263
Key [12]:72cae8eebd7fabd9b1848333c2aab439
round 7:abe4b498d9c36ea97b8fd27d7f813913
Key [13]:15f27ea11e83a51645d487b81371d7dc
Key [14]:36083c8666447e03d33846edf444eb12
round 8:8032104338a945ba044d102eabda3b22
Key [15]:0a3a8977dd48f3b6c1668578befadd02
Key [16]:f06b6675d78ca0ee5b1761bdcdab516d
Key [17]:cbc8a7952d33aa0496f7ea2d05390b23
Ka :bf0706d76ec3b11cce724b311bf71ff5
-----------------------------------------
rand :86290e2892f278ff6c3fb917b020576a
PIN length = 9 octets
PIN :3dcdffcfd086802107
address :791a6a2c5cc3
round 1:86290e2892f278ff6c3fb917b0205765
Key [ 1]:3dcdffcfd086802107791a6a2c5cc33d
Key [ 2]:b4962f40d7bb19429007062a3c469521
round 2:1ec59ffd3065f19991872a7863b0ef02
Key [ 3]:eb9ede6787dd196b7e340185562bf28c
Key [ 4]:2964e58aacf7287d1717a35b100ae23b
round 3:f817406f1423fc2fe33e25152679eaaf
added ->:7e404e47861574d08f7dde02969941ca
Key [ 5]:6abf9a314508fd61e486fa4e376c3f93
Key [ 6]:6da148b7ee2632114521842cbb274376
round 4:e9c2a8fac22b8c7cf0c619e2b3f890ed
Key [ 7]:df889cc34fda86f01096d52d116e620d
Key [ 8]:5eb04b147dc39d1974058761ae7b73fc
round 5:444a8aac0efee1c02f8d38f8274b7b28
Key [ 9]:8426cc59eee391b2bd50cf8f1efef8b3
Key [10]:8b5d220a6300ade418da791dd8151941
round 6:9185f983db150b1bccab1e5c12eb63a1
Key [11]:82ba4ddef833f6a4d18b07aa011f2798
Key [12]:ce63d98794682054e73d0359dad35ec4
round 7:5eded2668f5916dfd036c09e87902886
Key [13]:da794357652e80c70ad8b0715dbe33d6
Key [14]:732ef2c0c3220b31f3820c375e27bb29
round 8:88a5291b4acbba009a85b7dd6a834b3b
Key [15]:3ce75a61d4b465b70c95d7ccd5799633

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 2, Part G Page 998
Sample Data

Key [16]:5df9bd2c3a17a840cdaafb76c171db7c
Key [17]:3f8364b089733d902bccb0cd3386846f
Ka : cdb0cc68f6f6fbd70b46652de3ef3ffb
-----------------------------------------
rand :3ab52a65bb3b24a08eb6cd284b4b9d4b
PIN length = 8 octets
PIN :d0fb9b6838d464d8
address :25a868db91ab
round 1:3ab52a65bb3b24a08eb6cd284b4b9d45
Key [ 1]:d0fb9b6838d464d825a868db91abd0fb
Key [ 2]:2573f47b49dad6330a7a9155b7ae8ba1
round 2:ad2ffdff408fcfab44941016a9199251
Key [ 3]:d2c5b8fb80cba13712905a589adaee71
Key [ 4]:5a3381511b338719fae242758dea0997
round 3:2ddc17e570d7931a2b1d13f6ace928a5
added ->:17914180cb12b7baa5d3e0dee734c5e0
Key [ 5]:e0a4d8ac27fbe2783b7bcb3a36a6224d
Key [ 6]:949324c6864deac3eca8e324853e11c3
round 4:62c1db5cf31590d331ec40ad692e8df5
Key [ 7]:6e67148088a01c2d4491957cc9ddc4aa
Key [ 8]:557431deab7087bb4c03fa27228f60c6
round 5:9c8933bc361f4bde4d1bda2b5f8bb235
Key [ 9]:a2551aca53329e70ade3fd2bb7664697
Key [10]:05d0ad35de68a364b54b56e2138738fe
round 6:9156db34136aa06655bf28a05be0596a
Key [11]:1616a6b13ce2f2895c722e8495181520
Key [12]:b12e78a1114847b01f6ed2f5a1429a23
round 7:84dcc292ed836c1c2d523f2a899a2ad5
Key [13]:316e144364686381944e95afd8a026bb
Key [14]:1ab551b88d39d97ea7a9fe136dbfe2e1
round 8:87bdcac878d777877f4eccf042cfee5e
Key [15]:70e21ab08c23c7544524b64492b25cc9
Key [16]:35f730f2ae2b950a49a1bf5c8b9f8866
Key [17]:2f16924c22db8b74e2eadf1ba4ebd37c
Ka :983218718ca9aa97892e312d86dd9516
-----------------------------------------
rand :a6dc447ff08d4b366ff96e6cf207e179
PIN length = 7 octets
PIN :9c57e10b4766cc
address :54ebd9328cb6
round 1:a6dc447ff08d4b366ff96e6cf207e174
Key [ 1]:9c57e10b4766cc54ebd9328cb69c57e1
Key [ 2]:00a609f4d61db26993c8177e3ee2bba8
round 2:1ed26b96a306d7014f4e5c9ee523b73d
Key [ 3]:646d7b5f9aaa528384bda3953b542764
Key [ 4]:a051a42212c0e9ad5c2c248259aca14e
round 3:a53f526db18e3d7d53edbfc9711041ed
added ->:031b9612411b884b3ce62da583172299
Key [ 5]:d1bd5e64930e7f838d8a33994462d8b2
Key [ 6]:5dc7e2291e32435665ebd6956bec3414
round 4:9438be308ec83f35c560e2796f4e0559

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 2, Part G Page 999
Sample Data

Key [ 7]:10552f45af63b0f15e2919ab37f64fe7
Key [ 8]:c44d5717c114a58b09207392ebe341f8
round 5:b79a7b14386066d339f799c40479cb3d
Key [ 9]:6886e47b782325568eaf59715a75d8ff
Key [10]:8e1e335e659cd36b132689f78c147bda
round 6:ef232462228aa166438d10c34e17424b
Key [11]:8843efeedd5c2b7c3304d647f932f4d1
Key [12]:13785aaedd0adf67abb4f01872392785
round 7:02d133fe40d15f1073673b36bba35abd
Key [13]:837d7ca2722419e6be3fae35900c3958
Key [14]:93f8442973e7fccf2e7232d1d057c73a
round 8:275506a3d08c84e94cc58ed60054505e
Key [15]:8a7a9edffa3c52918bc6a45f57d91f5d
Key [16]:f214a95d777f763c56109882c4b52c84
Key [17]:10e2ee92c5ea1ddc5eb010e55510c403
Ka :9cd6650ead86323e87cafb1ff516d1e0
-----------------------------------------
rand :3348470a7ea6cc6eb81b40472133262c
PIN length = 6 octets
PIN :fcad169d7295
address :430d572f8842
round 1:3348470a7ea6cc6eb81b404721332620
Key [ 1]:fcad169d7295430d572f8842fcad169d
Key [ 2]:b3479d4d4fd178c43e7bc5b0c7d8983c
round 2:af976da9225066d563e10ab955e6fc32
Key [ 3]:7112462b37d82dd81a2a35d9eb43cb7c
Key [ 4]:c5a7030f8497945ac7b84600d1d161fb
round 3:d08f826ebd55a0bd7591c19a89ed9bde
added ->:e3d7c964c3fb6cd3cdac01dda820c1fe
Key [ 5]:84b0c6ef4a63e4dff19b1f546d683df5
Key [ 6]:f4023edfc95d1e79ed4bb4de9b174f5d
round 4:6cd952785630dfc7cf81eea625e42c5c
Key [ 7]:ea38dd9a093ac9355918632c90c79993
Key [ 8]:dbba01e278ddc76380727f5d7135a7de
round 5:93573b2971515495978264b88f330f7f
Key [ 9]:d4dc3a31be34e412210fafa6eca00776
Key [10]:39d1e190ee92b0ff16d92a8be58d2fa0
round 6:b3f01d5e7fe1ce6da7b46d8c389baf47
Key [11]:1eb081328d4bcf94c9117b12c5cf22ac
Key [12]:7e047c2c552f9f1414d946775fabfe30
round 7:0b833bff6106d5bae033b4ce5af5a924
Key [13]:e78e685d9b2a7e29e7f2a19d1bc38ebd
Key [14]:1b582272a3121718c4096d2d8602f215
round 8:23de0bbdc70850a7803f4f10c63b2c0f
Key [15]:8569e860530d9c3d48a0870dac33f676
Key [16]:6966b528fdd1dc222527052c8f6cf5a6
Key [17]:a34244c757154c53171c663b0b56d5c2
Ka :98f1543ab4d87bd5ef5296fb5e3d3a21
-----------------------------------------
rand :0f5bb150b4371ae4e5785293d22b7b0c
PIN length = 5 octets

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 2, Part G Page 1000
Sample Data

PIN :b10d068bca
address :b44775199f29
round 1:0f5bb150b4371ae4e5785293d22b7b07
Key [ 1]:b10d068bcab44775199f29b10d068bca
Key [ 2]:aec70d1048f1bbd2c18040318a8402ad
round 2:342d2b79d7fb7cd110379742b9842c79
Key [ 3]:6d8d5cf338f29ef4420639ef488e4fa9
Key [ 4]:a1584117541b759ba6d9f7eb2bedcbba
round 3:9407e8e3e810603921bf81cfda62770a
added ->:9b6299b35c477addc437d35c088df20d
Key [ 5]:09a20676666aeed6f22176274eb433f4
Key [ 6]:840472c001add5811a054be5f5c74754
round 4:9a3ba953225a7862c0a842ed3d0b2679
Key [ 7]:fad9e45c8bf70a972fcd9bff0e8751f5
Key [ 8]:e8f30ff666dfd212263416496ff3b2c2
round 5:2c573b6480852e875df34b28a5c44509
Key [ 9]:964cdba0cf8d593f2fc40f96daf8267a
Key [10]:bcd65c11b13e1a70bcd4aafba8864fe3
round 6:21b0cc49e880c5811d24dee0194e6e9e
Key [11]:468c8548ea9653c1a10df6288dd03c1d
Key [12]:5d252d17af4b09d3f4b5f7b5677b8211
round 7:e6d6bdcd63e1d37d9883543ba86392fd
Key [13]:e814bf307c767428c67793dda2df95c7
Key [14]:4812b979fdc20f0ff0996f61673a42cc
round 8:e3dde7ce6bd7d8a34599aa04d6a760ab
Key [15]:5b1e2033d1cd549fc4b028146eb5b3b7
Key [16]:0f284c14fb8fe706a5343e3aa35af7b1
Key [17]:b1f7a4b7456d6b577fded6dc7a672e37
Ka :c55070b72bc982adb972ed05d1a74ddb
-----------------------------------------
rand :148662a4baa73cfadb55489159e476e1
PIN length = 4 octets
PIN :fb20f177
address :a683bd0b1896
round 1:148662a4baa73cfadb55489159e476eb
Key [ 1]:fb20f177a683bd0b1896fb20f177a683
Key [ 2]:47266cefbfa468ca7916b458155dc825
round 2:3a942eb6271c3f4e433838a5d3fcbd27
Key [ 3]:688853a6d6575eb2f6a2724b0fbc133b
Key [ 4]:7810df048019634083a2d9219d0b5fe0
round 3:9c835b98a063701c0887943596780769
added ->:8809bd3c1a0aace6d3dcdca4cf5c7d82
Key [ 5]:c78f6dcf56da1bbd413828b33f5865b3
Key [ 6]:eb3f3d407d160df3d293a76d1a513c4a
round 4:7e68c4bafa020a4a59b5a1968105bab5
Key [ 7]:d330e038d6b19d5c9bb0d7285a360064
Key [ 8]:9bd3ee50347c00753d165faced702d9c
round 5:227bad0cf0838bdb15b3b3872c24f592
Key [ 9]:9543ad0fb3fe74f83e0e2281c6d4f5f0
Key [10]:746cd0383c17e0e80e6d095a87fd0290
round 6:e026e98c71121a0cb739ef6f59e14d26

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 2, Part G Page 1001
Sample Data

Key [11]:fa28bea4b1c417536608f11f406ea1dd
Key [12]:3aee0f4d21699df9cb8caf5354a780ff
round 7:cd6a6d8137d55140046f8991da1fa40a
Key [13]:372b71bc6d1aa6e785358044fbcf05f4
Key [14]:00a01501224c0405de00aa2ce7b6ab04
round 8:52cd7257fe8d0c782c259bcb6c9f5942
Key [15]:c7015c5c1d7c030e00897f104a006d4a
Key [16]:260a9577790c62e074e71e19fd2894df
Key [17]:c041b7a231493acd15ddcdaee94b9f52
Ka :7ec864df2f1637c7e81f2319ae8f4671
-----------------------------------------
rand :193a1b84376c88882c8d3b4ee93ba8d5
PIN length = 3 octets
PIN :a123b9
address :4459a44610f6
round 1:193a1b84376c88882c8d3b4ee93ba8dc
Key [ 1]:a123b94459a44610f6a123b94459a446
Key [ 2]:5f64d384c8e990c1d25080eb244dde9b
round 2:3badbd58f100831d781ddd3ccedefd3f
Key [ 3]:5abc00eff8991575c00807c48f6dbea5
Key [ 4]:127521158ad6798fb6479d1d2268abe6
round 3:0b53075a49c6bf2df2421c655fdedf68
added ->:128d22de7e3247a5decf572bb61987b4
Key [ 5]:f2a1f620448b8e56665608df2ab3952f
Key [ 6]:7c84c0af02aad91dc39209c4edd220b1
round 4:793f4484fb592e7a78756fd4662f990d
Key [ 7]:f6445b647317e7e493bb92bf6655342f
Key [ 8]:3cae503567c63d3595eb140ce60a84c0
round 5:9e46a8df925916a342f299a8306220a0
Key [ 9]:734ed5a806e072bbecb4254993871679
Key [10]:cda69ccb4b07f65e3c8547c11c0647b8
round 6:6bf9cd82c9e1be13fc58eae0b936c75a
Key [11]:c48e531d3175c2bd26fa25cc8990e394
Key [12]:6d93d349a6c6e9ff5b26149565b13d15
round 7:e96a9871471240f198811d4b8311e9a6
Key [13]:5c4951e85875d663526092cd4cbdb667
Key [14]:f19f7758f5cde86c3791efaf563b3fd0
round 8:e94ca67d3721d5fb08ec069191801a46
Key [15]:bf0c17f3299b37d984ac938b769dd394
Key [16]:7edf4ad772a6b9048588f97be25bde1c
Key [17]:6ee7ba6afefc5b561abbd8d6829e8150
Ka :ac0daabf17732f632e34ef193658bf5d
-----------------------------------------
rand :1453db4d057654e8eb62d7d62ec3608c
PIN length = 2 octets
PIN :3eaf
address :411fbbb51d1e
round 1:1453db4d057654e8eb62d7d62ec36084
Key [ 1]:3eaf411fbbb51d1e3eaf411fbbb51d1e
Key [ 2]:c3a1a997509f00fb4241aba607109c64
round 2:0b78276c1ebc65707d38c9c5fa1372bd

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 2, Part G Page 1002
Sample Data

Key [ 3]:3c729833ae1ce7f84861e4dbad6305cc
Key [ 4]:c83a43c3a66595cb8136560ed29be4ff
round 3:23f3f0f6441563d4c202cee0e5cb2335
added ->:3746cbbb418bb73c2964a536cb8e83b1
Key [ 5]:18b26300b86b70acdd1c8f5cbc7c5da8
Key [ 6]:04efc75309b98cd8f1cef5513c18e41e
round 4:c61afa90d3c14bdf588320e857afdc00
Key [ 7]:517c789cecadc455751af73198749fb8
Key [ 8]:fd9711f913b5c844900fa79dd765d0e2
round 5:a8a0e02ceb556af8bfa321789801183a
Key [ 9]:bb5cf30e7d3ceb930651b1d16ee92750
Key [10]:3d97c7862ecab42720e984972f8efd28
round 6:0b58e922438d224db34b68fca9a5ea12
Key [11]:4ce730344f6b09e449dcdb64cd466666
Key [12]:38828c3a56f922186adcd9b713cdcc31
round 7:b90664c4ac29a8b4bb26debec9ffc5f2
Key [13]:d30fd865ea3e9edcff86a33a2c319649
Key [14]:1fdb63e54413acd968195ab6fa424e83
round 8:6934de3067817cefd811abc5736c163b
Key [15]:a16b7c655bbaa262c807cba8ae166971
Key [16]:7903dd68630105266049e23ca607cda7
Key [17]:888446f2d95e6c2d2803e6f4e815ddc9
Ka :1674f9dc2063cc2b83d3ef8ba692ebef
-----------------------------------------
rand :1313f7115a9db842fcedc4b10088b48d
PIN length = 1 octets
PIN :6d
address :008aa9be62d5
round 1:1313f7115a9db842fcedc4b10088b48a
Key [ 1]:6d008aa9be62d56d008aa9be62d56d00
Key [ 2]:46ebfeafb6657b0a1984a8dc0893accf
round 2:839b23b83b5701ab095bafd162ec0ac7
Key [ 3]:8e15595edcf058af62498ee3c1dc6098
Key [ 4]:dd409c3444e94b9cc08396ae967542a0
round 3:c0a2010cc44f2139427f093f4f97ae68
added ->:d3b5f81d9eecd97bbe6ccd8e4f1f62e2
Key [ 5]:487deff5d519f6a6481e947b926f633c
Key [ 6]:5b4b6e3477ed5c2c01f6e607d3418963
round 4:1a5517a0efad3575931d8ea3bee8bd07
Key [ 7]:34b980088d2b5fd6b6a2aceeda99c9c4
Key [ 8]:e7d06d06078acc4ecdbc8da800b73078
round 5:d3ce1fdfe716d72c1075ff37a8a2093f
Key [ 9]:7d375bad245c3b757380021af8ecd408
Key [10]:14dac4bc2f4dc4929a6cceec47f4c3a3
round 6:47e90cb55be6e8dd0f583623c2f2257b
Key [11]:66cfda3c63e464b05e2e7e25f8743ad7
Key [12]:77cfccda1ad380b9fdf1df10846b50e7
round 7:f866ae6624f7abd4a4f5bd24b04b6d43
Key [13]:3e11dd84c031a470a8b66ec6214e44cf
Key [14]:2f03549bdb3c511eea70b65ddbb08253
round 8:02e8e17cf8be4837c9c40706b613dfa8

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 2, Part G Page 1003
Sample Data

Key [15]:e2f331229ddfcc6e7bea08b01ab7e70c
Key [16]:b6b0c3738c5365bc77331b98b3fba2ab
Key [17]:f5b3973b636119e577c5c15c87bcfd19
Ka :38ec0258134ec3f08461ae5c328968a1

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 2, Part G Page 1004
Sample Data

10.5 Four tests of E3

rand :00000000000000000000000000000000
aco :48afcdd4bd40fef76693b113
key :00000000000000000000000000000000
round 1:00000000000000000000000000000000
Key [ 1]:00000000000000000000000000000000
Key [ 2]:4697b1baa3b7100ac537b3c95a28ac64
round 2:78d19f9307d2476a523ec7a8a026042a
Key [ 3]:ecabaac66795580df89af66e66dc053d
Key [ 4]:8ac3d8896ae9364943bfebd4969b68a0
round 3:600265247668dda0e81c07bbb30ed503
Key [ 5]:5d57921fd5715cbb22c1be7bbc996394
Key [ 6]:2a61b8343219fdfb1740e6511d41448f
round 4:d7552ef7cc9dbde568d80c2215bc4277
Key [ 7]:dd0480dee731d67f01a2f739da6f23ca
Key [ 8]:3ad01cd1303e12a1cd0fe0a8af82592c
round 5:fb06bef32b52ab8f2a4f2b6ef7f6d0cd
Key [ 9]:7dadb2efc287ce75061302904f2e7233
Key [10]:c08dcfa981e2c4272f6c7a9f52e11538
round 6:b46b711ebb3cf69e847a75f0ab884bdd
Key [11]:fc2042c708e409555e8c147660ffdfd7
Key [12]:fa0b21001af9a6b9e89e624cd99150d2
round 7:c585f308ff19404294f06b292e978994
Key [13]:18b40784ea5ba4c80ecb48694b4e9c35
Key [14]:454d54e5253c0c4a8b3fcca7db6baef4
round 8:2665fadb13acf952bf74b4ab12264b9f
Key [15]:2df37c6d9db52674f29353b0f011ed83
Key [16]:b60316733b1e8e70bd861b477e2456f1
Key [17]:884697b1baa3b7100ac537b3c95a28ac
round 1:5d3ecb17f26083df0b7f2b9b29aef87c
Key [ 1]:e9e5dfc1b3a79583e9e5dfc1b3a79583
Key [ 2]:7595bf57e0632c59f435c16697d4c864
round 2:de6fe85c5827233fe22514a16f321bd8
Key [ 3]:e31b96afcc75d286ef0ae257cbbc05b7
Key [ 4]:0d2a27b471bc0108c6263aff9d9b3b6b
round 3:7cd335b50d09d139ea6702623af85edb
added -> :211100a2ff6954e6e1e62df913a656a7
Key [ 5]:98d1eb5773cf59d75d3b17b3bc37c191
Key [ 6]:fd2b79282408ddd4ea0aa7511133336f
round 4:991dccb3201b5b1c4ceff65a3711e1e9
Key [ 7]:331227756638a41d57b0f7e071ee2a98
Key [ 8]:aa0dd8cc68b406533d0f1d64aabacf20
round 5:18768c7964818805fe4c6ecae8a38599
Key [ 9]:669291b0752e63f806fce76f10e119c8
Key [10]:ef8bdd46be8ee0277e9b78adef1ec154
round 6:82f9aa127a72632af43d1a17e7bd3a09
Key [11]:f3902eb06dc409cfd78384624964bf51
Key [12]:7d72702b21f97984a721c99b0498239d
round 7:1543d7870bf2d6d6efab3cbf62dca97d
Key [13]:532e60bceaf902c52a06c2c283ecfa32

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 2, Part G Page 1005
Sample Data

Key [14]:181715e5192efb2a64129668cf5d9dd4
round 8:eee3e8744a5f8896de95831ed837ffd5
Key [15]:83017c1434342d4290e961578790f451
Key [16]:2603532f365604646ff65803795ccce5
Key [17]:882f7c907b565ea58dae1c928a0dcf41
K_enc :cc802aecc7312285912e90af6a1e1154
-----------------------------------------
rand :950e604e655ea3800fe3eb4a28918087
aco :68f4f472b5586ac5850f5f74
key :34e86915d20c485090a6977931f96df5
round 1:950e604e655ea3800fe3eb4a28918087
Key [ 1]:34e86915d20c485090a6977931f96df5
Key [ 2]:8de2595003f9928efaf37e5229935bdb
round 2:d46f5a04c967f55840f83d1cdb5f9afc
Key [ 3]:46f05ec979a97cb6ddf842ecc159c04a
Key [ 4]:b468f0190a0a83783521deae8178d071
round 3:e16edede9cb6297f32e1203e442ac73a
Key [ 5]:8a171624dedbd552356094daaadcf12a
Key [ 6]:3085e07c85e4b99313f6e0c837b5f819
round 4:805144e55e1ece96683d23366fc7d24b
Key [ 7]:fe45c27845169a66b679b2097d147715
Key [ 8]:44e2f0c35f64514e8bec66c5dc24b3ad
round 5:edbaf77af070bd22e9304398471042f1
Key [ 9]:0d534968f3803b6af447eaf964007e7b
Key [10]:f5499a32504d739ed0b3c547e84157ba
round 6:0dab1a4c846aef0b65b1498812a73b50
Key [11]:e17e8e456361c46298e6592a6311f3fb
Key [12]:ec6d14da05d60e8abac807646931711f
round 7:1e7793cac7f55a8ab48bd33bc9c649e0
Key [13]:2b53dde3d89e325e5ff808ed505706ae
Key [14]:41034e5c3fb0c0d4f445f0cf23be79b0
round 8:3723768baa78b6a23ade095d995404da
Key [15]:e2ca373d405a7abf22b494f28a6fd247
Key [16]:74e09c9068c0e8f1c6902d1b70537c30
Key [17]:767a7f1acf75c3585a55dd4a428b2119
round 1:39809afb773efd1b7510cd4cb7c49f34
Key [ 1]:1d0d48d485abddd3798b483a82a0f878
Key [ 2]:aed957e600a5aed5217984dd5fef6fd8
round 2:6436ddbabe92655c87a7d0c12ae5e5f6
Key [ 3]:fee00bb0de89b6ef0a289696a4faa884
Key [ 4]:33ce2f4411db4dd9b7c42cc586b8a2ba
round 3:cec690f7e0aa5f063062301e049a5cc5
added -> :f7462a0c97e85c1d4572fd52b35efbf1
Key [ 5]:b5116f5c6c29e05e4acb4d02a46a3318
Key [ 6]:ff4fa1f0f73d1a3c67bc2298abc768f9
round 4:dcdfe942e9f0163fc24a4718844b417d
Key [ 7]:5453650c0819e001e48331ad0e9076e0
Key [ 8]:b4ff8dda778e26c0dce08349b81c09a1
round 5:265a16b2f766afae396e7a98c189fda9
Key [ 9]:f638fa294427c6ed94300fd823b31d10
Key [10]:1ccfa0bd86a9879b17d4bc457e3e03d6

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 2, Part G Page 1006
Sample Data

round 6:628576b5291d53d1eb8611c8624e863e
Key [11]:0eaee2ef4602ac9ca19e49d74a76d335
Key [12]:6e1062f10a16e0d378476da3943842e9
round 7:d7b9c2e9b2d5ea5c27019324cae882b3
Key [13]:40be960bd22c744c5b23024688e554b9
Key [14]:95c9902cb3c230b44d14ba909730d211
round 8:97fb6065498385e47eb3df6e2ca439dd
Key [15]:10d4b6e1d1d6798aa00aa2951e32d58d
Key [16]:c5d4b91444b83ee578004ab8876ba605
Key [17]:1663a4f98e2862eddd3ec2fb03dcc8a4
K_enc :c1beafea6e747e304cf0bd7734b0a9e2
-----------------------------------------
rand :6a8ebcf5e6e471505be68d5eb8a3200c
aco :658d791a9554b77c0b2f7b9f
key :35cf77b333c294671d426fa79993a133
round 1:6a8ebcf5e6e471505be68d5eb8a3200c
Key [ 1]:35cf77b333c294671d426fa79993a133
Key [ 2]:c4524e53b95b4bf2d7b2f095f63545fd
round 2:ade94ec585db0d27e17474b58192c87a
Key [ 3]:c99776768c6e9f9dd3835c52cea8d18a
Key [ 4]:f1295db23823ba2792f21217fc01d23f
round 3:da8dc1a10241ef9e6e069267cd2c6825
Key [ 5]:9083db95a6955235bbfad8aeefec5f0b
Key [ 6]:8bab6bc253d0d0c7e0107feab728ff68
round 4:e6665ca0772ceecbc21222ff7be074f8
Key [ 7]:2fa1f4e7a4cf3ccd876ec30d194cf196
Key [ 8]:267364be247184d5337586a19df8bf84
round 5:a857a9326c9ae908f53fee511c5f4242
Key [ 9]:9aef21965b1a6fa83948d107026134c7
Key [10]:d2080c751def5dc0d8ea353cebf7b973
round 6:6678748a1b5f21ac05cf1b117a7c342f
Key [11]:d709a8ab70b0d5a2516900421024b81e
Key [12]:493e4843805f1058d605c8d1025f8a56
round 7:766c66fe9c460bb2ae39ec01e435f725
Key [13]:b1ed21b71daea03f49fe74b2c11fc02b
Key [14]:0e1ded7ebf23c72324a0165a698c65c7
round 8:396e0ff7b2b9b7a3b35c9810882c7596
Key [15]:b3bf4841dc92f440fde5f024f9ce8be9
Key [16]:1c69bc6c2994f4c84f72be8f6b188963
Key [17]:bb7b66286dd679a471e2792270f3bb4d
round 1:45654f2f26549675287200f07cb10ec9
Key [ 1]:1e2a5672e66529e4f427b0682a3a34b6
Key [ 2]:974944f1ce0037b1febcf61a2bc961a2
round 2:990cd869c534e76ed4f4af7b3bfbc6c8
Key [ 3]:8147631fb1ce95d624b480fc7389f6c4
Key [ 4]:6e90a2db33d284aa13135f3c032aa4f4
round 3:ceb662f875aa6b94e8192b5989abf975
added -> :8b1bb1d753fe01e1c08b2ba9f55c07bc
Key [ 5]:cbad246d24e36741c46401e6387a05f9
Key [ 6]:dcf52aaec5713110345a41342c566fc8
round 4 :d4e000be5de78c0f56ff218f3c1df61b

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 2, Part G Page 1007
Sample Data

Key [ 7]:8197537aa9d27e67d17c16b182c8ec65
Key [ 8]:d66e00e73d835927a307a3ed79d035d8
round 5:9a4603bdef954cfaade2052604bed4e4
Key [ 9]:71d46257ecc1022bcd312ce6c114d75c
Key [10]:f91212fa528379651fbd2c32890c5e5f
round 6:09a0fd197ab81eb933eece2fe0132dbb
Key [11]:283acc551591fadce821b02fb9491814
Key [12]:ca5f95688788e20d94822f162b5a3920
round 7:494f455a2e7a5db861ece816d4e363e4
Key [13]:ba574aef663c462d35399efb999d0e40
Key [14]:6267afc834513783fef1601955fe0628
round 8:37a819f91c8380fb7880e640e99ca947
Key [15]:fdcd9be5450eef0f8737e6838cd38e2b
Key [16]:8cfbd9b8056c6a1ce222b92b94319b38
Key [17]:4f64c1072c891c39eeb95e63318462e0
K_enc :a3032b4df1cceba8adc1a04427224299
-----------------------------------------
rand :5ecd6d75db322c75b6afbd799cb18668
aco :63f701c7013238bbf88714ee
key :b9f90c53206792b1826838b435b87d4d
round 1:5ecd6d75db322c75b6afbd799cb18668
Key [ 1]:b9f90c53206792b1826838b435b87d4d
Key [ 2]:15f74bbbde4b9d1e08f858721f131669
round 2:72abb85fc80c15ec2b00d72873ef9ad4
Key [ 3]:ef7fb29f0b01f82706c7439cc52f2dab
Key [ 4]:3003a6aecdee06b9ac295cce30dcdb93
round 3 :2f10bab93a0f73742183c68f712dfa24
Key [ 5]:5fcdbb3afdf7df06754c954fc6340254
Key [ 6]:ddaa90756635579573fe8ca1f93d4a38
round 4:183b145312fd99d5ad08e7ca4a52f04e
Key [ 7]:27ca8a7fc703aa61f6d7791fc19f704a
Key [ 8]:702029d8c6e42950762317e730ec5d18
round 5:cbad52d3a026b2e38b9ae6fefffecc32
Key [ 9]:ff15eaa3f73f4bc2a6ccfb9ca24ed9c5
Key [10]:034e745246cd2e2cfc3bda39531ca9c5
round 6:ce5f159d0a1acaacd9fb4643272033a7
Key [11]:0a4d8ff5673731c3dc8fe87e39a34b77
Key [12]:637592fab43a19ac0044a21afef455a2
round 7 :8a49424a10c0bea5aba52dbbffcbcce8
Key [13]:6b3fde58f4f6438843cdbe92667622b8
Key [14]:a10bfa35013812f39bf2157f1c9fca4e
round 8:f5e12da0e93e26a5850251697ec0b917
Key [15]:2228fe5384e573f48fdd19ba91f1bf57
Key [16]:5f174db2bc88925c0fbc6b5485bafc08
Key [17]:28ff90bd0dc31ea2bb479feb7d8fe029
round 1:0c75eed2b54c1cfb9ff522daef94ed4d
Key [ 1]:a21ceb92d3c027326b4de775865fe8d0
Key [ 2]:26f64558a9f0a1652f765efd546f3208
round 2:48d537ac209a6aa07b70000016c602e8
Key [ 3]:e64f9ef630213260f1f79745a0102ae5
Key [ 4]:af6a59d7cebfd0182dcca9a537c4add8

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 2, Part G Page 1008
Sample Data

round 3:8b6d517ac893743a401b3fb7911b64e1
added -> :87e23fa87ddf90c1df10616d7eaf51ac
Key [ 5]:9a6304428b45da128ab64c8805c32452
Key [ 6]:8af4d1e9d80cb73ec6b44e9b6e4f39d8
round 4:9f0512260a2f7a5067efc35bf1706831
Key [ 7]:79cc2d138606f0fca4e549c34a1e6d19
Key [ 8]:803dc5cdde0efdbee7a1342b2cd4d344
round 5:0cfd7856edfafac51f29e86365de6f57
Key [ 9]:e8fa996448e6b6459ab51e7be101325a
Key [10]:2acc7add7b294acb444cd933f0e74ec9
round 6:2f1fa34bf352dc77c0983a01e8b7d622
Key [11]:f57de39e42182efd6586b86a90c86bb1
Key [12]:e418dfd1bb22ebf1bfc309cd27f5266c
round 7:ee4f7a53849bf73a747065d35f3752b1
Key [13]:80a9959133856586370854db6e0470b3
Key [14]:f4c1bc2f764a0193749f5fc09011a1ae
round 8:8fec6f7249760ebf69e370e9a4b80a92
Key [15]:d036cef70d6470c3f52f1b5d25b0c29d
Key [16]:d0956af6b8700888a1cc88f07ad226dc
Key [17]:1ce8b39c4c7677373c30849a3ee08794
K_enc :ea520cfc546b00eb7c3a6cea3ecb39ed

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 2, Part G Page 1009
Sample Data

11 CONNECTIONLESS PERIPHERAL BROADCAST

SAMPLE DATA

This section contains an example of the DM3 packet used for the synchronization train
(see [Vol 2] Part B, Section 8.11.2).

Packet header: (MSB...LSB)

--------------------------
LT_ADDR = 0
TYPE = 1010 (DM3)
FLOW = 0
ARQN = 0
SEQN = 0

Payload:
--------
logical channel = 10 (binary) (L2CAP start or no fragmentation)
payload length = 28 bytes
flow = 0
current CLK = 0x2345678
next Connectionless Peripheral Broadcast instant = 0x23457a0
AFH channel map = all channels used except 16 and 42 to 47
Central BD_ADDR = NAP 0xACDE, UAP 0x48, LAP 0x610316
Connectionless Peripheral Broadcast interval = 564 slots
Connectionless Peripheral Broadcast LT_ADDR = 1
service data = 0x69

AIR DATA

Packet header (including HEC, in transmitted bit order):

--------------------------------------------------------
000000000
000111000111
000
000
000
111111111000000000000111

Payload
-------

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 2, Part G Page 1010
Sample Data

The data forming the payload consists of the following 32 octets

(given in hexadecimal) in the order transmitted:

e2 00
78 56 34 02
d0 2b 1a 01
ff ff fe ff ff 03 ff ff ff 7f
16 03 61 48 de ac
34 02
01
69
f2 85

The bit sequence transmitted (including FEC) will therefore begin:

0100011100 01001
0000000001 10101
1110011010 11011

and end:

0100111110 10001
1000010000 00011

Bluetooth SIG Proprietary Version Date: 2024-08-27

 BR/EDR Controller
Part H

SECURITY SPECIFICATION

This Part describes the security system which

may be used at the Link Layer. The Encryption,
Authentication, and Key Generation schemes are
specified. The requirements for the supporting
process of random number generation are also
specified.

Bluetooth SIG Proprietary

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 2, Part H Page 1012
Security Specification

CONTENTS

1 Security overview ................................................................................... 1014

1.1 Pausing encryption and role switch ........................................... 1015
1.2 Change connection link keys .................................................... 1015
1.3 Periodically refreshing encryption keys ..................................... 1016

2 Random number generation .................................................................. 1017

3 Key management .................................................................................... 1019

3.1 Key types ................................................................................... 1019
3.2 Key generation and initialization ............................................... 1021
3.2.1 Generation of initialization key, Kinit ........................... 1021
3.2.2 Authentication ............................................................ 1022
3.2.3 [This section is no longer used] ................................. 1022
3.2.4 Generation of a combination key ............................... 1022
3.2.5 Generating the encryption key ................................... 1024
3.2.6 Point-to-multipoint configuration ................................ 1024
3.2.7 Modifying the link keys ............................................... 1025
3.2.8 Generating a temporary link key ................................ 1025

4 Encryption (E0) ....................................................................................... 1027

4.1 Encryption key size negotiation ................................................. 1027
4.2 Encryption of broadcast messages ........................................... 1028
4.3 Encryption concept .................................................................... 1028
4.4 Encryption algorithm ................................................................. 1029
4.4.1 The operation of the cipher ........................................ 1031
4.5 LFSR initialization ..................................................................... 1032
4.6 Key stream sequence ............................................................... 1035

5 Authentication ......................................................................................... 1036

5.1 Repeated attempts .................................................................... 1039

6 The authentication and key-generating functions ............................... 1040

6.1 The authentication function E1 .................................................. 1040
6.2 The functions Ar and A’r ............................................................. 1042
6.2.1 The round computations ............................................ 1043
6.2.2 The substitution boxes “e” and “l” .............................. 1043
6.2.3 Key scheduling .......................................................... 1045
6.3 E2-key generation function for authentication ........................... 1045
6.4 E3-key generation function for encryption ................................. 1047

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 2, Part H Page 1013
Security Specification

7 Secure Simple Pairing ............................................................................ 1049

7.1 Phase 1: Public key exchange .................................................. 1050
7.2 Phase 2: Authentication stage 1 ............................................... 1051
7.2.1 Authentication stage 1: Numeric Comparison
protocol ...................................................................... 1051
7.2.2 Authentication stage 1: Out of Band protocol ............ 1053
7.2.3 Authentication stage 1: Passkey Entry protocol ........ 1055
7.3 Phase 3: Authentication stage 2 ............................................... 1057
7.4 Phase 4: Link key calculation .................................................... 1058
7.5 Phase 5: LMP authentication and encryption ............................ 1059
7.6 Elliptic curve definition ............................................................... 1059
7.7 Cryptographic function definitions ............................................. 1060
7.7.1 The Secure Simple Pairing commitment function f1 .. 1060
7.7.2 The Secure Simple Pairing numeric verification
function g ................................................................... 1061
7.7.3 The Secure Simple Pairing key derivation
function f2 .................................................................. 1062
7.7.4 The Secure Simple Pairing check function f3 ............ 1063
7.7.5 [This section is no longer used] ................................. 1064
7.7.6 The AES encryption key generation function h3 ....... 1064
7.7.7 The Device authentication key generation
function h4 ................................................................. 1065
7.7.8 The Device authentication confirmation function h5 .. 1065

8 [This section is no longer used] ............................................................ 1067

9 AES-CCM encryption for BR/EDR ......................................................... 1068

9.1 Nonce formats ........................................................................... 1068
9.2 Counter mode blocks ................................................................ 1070
9.3 Encryption blocks ...................................................................... 1071
9.4 Encryption key size reduction ................................................... 1072
9.5 Repeated MIC failures .............................................................. 1072

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 2, Part H Page 1014
Security Specification

1 SECURITY OVERVIEW

Bluetooth wireless technology provides peer-to-peer communications over short

distances. In order to provide usage protection and information confidentiality, the
system provides security measures both at the application layer and the Link Layer.
These measures are designed to be appropriate for a peer environment.

This means that in each device, the authentication and encryption routines are
implemented in the same way.

In [Vol 2] Part H, the term "random number" includes pseudo-random numbers, subject
to the requirements in Section 2.

The security mechanisms used in BR/EDR have evolved over the course of multiple
versions of the specification in three phases: legacy, Secure Simple Pairing, and Secure
Connections. The encryption, authentication and key generation algorithms associated
with each is shown in Table 1.1.

Security Mechanism Legacy Secure Simple Pairing Secure Connections

Encryption E0 E0 AES-CCM
Authentication SAFER+ SAFER+ HMAC-SHA256
Key Generation SAFER+ P-192 ECDH P-256 ECDH
HMAC-SHA-256 HMAC-SHA-256

Table 1.1: Security algorithms

The legacy encryption, authentication and key generation algorithms are described in
Section 3 to 6. The algorithms used for Secure Simple Pairing and Secure Connections
are described in Section 7 to 9.

Four different entities are used for maintaining security at the Link Layer: a Bluetooth
Device Address, two secret keys, and a random number that shall be regenerated for
each new transaction. The four entities and their sizes are summarized in Table 1.2.

Entity Size
BD_ADDR 48 bits
Private user key, authentication 128 bits
Private user key, encryption 8 to 128 bits
configurable length (byte-wise)
RAND 128 bits

Table 1.2: Entities used in authentication and encryption procedures

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 2, Part H Page 1015
Security Specification

The Bluetooth Device Address (BD_ADDR) is the 48-bit address. The BD_ADDR can
be obtained via user interactions, or, automatically, via an inquiry routine by a device.

The secret keys are derived during initialization and are never disclosed. The encryption
key is derived from the authentication key during the authentication process. For the
authentication algorithm, the size of the key used is always 128 bits. For the encryption
algorithm, the key size may vary between 1 and 16 octets (8 - 128 bits).

The encryption key is entirely different from the authentication key. Each time encryption
is activated, a new encryption key shall be generated. Thus, the lifetime of the
encryption key does not necessarily correspond to the lifetime of the authentication
key.

It is anticipated that the authentication key will be more static in its nature than the
encryption key – once established, the particular application running on the device
decides when, or if, to change it. To underline the fundamental importance of the
authentication key to a specific link, it is often referred to as the link key.

RAND is a random number which can be derived from a random process in the device.
This is not a static parameter and will change frequently.

In this part, the terms user and application are used interchangeably to designate the
entity that is at either side.

1.1 Pausing encryption and role switch

To perform a role switch on a connection encryption must be disabled or paused
as the encryption is based off the Central's clock and Bluetooth address information.
Unfortunately, if the role switch is required, and encryption is turned off, the device on
the other end of the link will not be aware of the reason for disabling encryption, and
can therefore take two possible actions: send clear text data, or disconnect. Neither
of these possible actions is desirable. When performing a role switch on an encrypted
link, the role switch shall be performed as a single operation where possible. If this is
not possible because the other device does not support the encryption pause feature,
then when a device wishes to have an encrypted link, and encryption is disabled, then
the device should not send any user data, and should not disconnect. If both devices
support the encryption pause feature, then this procedure shall be used.

1.2 Change connection link keys

It is possible to perform a change of connection link keys while a link is encrypted,
but it is not possible to use the new link keys until encryption has been stopped and
then restarted. As with role switches, disabling encryption and then re-enabling it again
can cause user data to be sent in the clear or a disconnection to occur. The use
of encryption pausing prevents this problem from occurring. On devices that do not

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 2, Part H Page 1016
Security Specification

support the encryption pause feature, when a device wishes to have an encrypted link,
and encryption is disabled, then the device should not send any data, and should not
disconnect. If both devices support the encryption pause feature, then this procedure
shall be used.

1.3 Periodically refreshing encryption keys

If both devices support the encryption pause feature, then the encryption keys shall
be refreshed by the Link Manager at least once every 228 ticks of the Bluetooth clock
(about 23.3 hours) when E0 encryption is used and before either the PayloadCounter
or dayCounter roll over when AES-CCM encryption is used if it is not refreshed by the
Host or the remote Link Manager. To refresh an encryption key, the Host may use the
Change Connection Link Key procedure or request an encryption key refresh. If the
encryption key has not been refreshed before going stale, a device may disconnect the
link.

Note: The roll over will occur after at least 238 ticks of the Bluetooth clock or at least
2.72 years.

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 2, Part H Page 1017
Security Specification

2 RANDOM NUMBER GENERATION

Each device shall have a random number generator. Random numbers are used for
many purposes within the security functions – or instance, for the challenge-response
scheme, for generating authentication and encryption keys, nonces used in Secure
Simple Pairing, for Passkeys used in authentication. A device shall use a random
number generator compliant with [FIPS PUB 140-2] (http://csrc.nist.gov/publications/
fips/fips140-2/fips1402annexc.pdf) or a later update.

When using a pseudo-random number generator, the device shall use a seed with at
least the minimum entropy required by that pseudo-random number generator.

The random number generator shall be tested against the [FIPS

SP800-22] (http://csrc.nist.gov/publications/nistpubs/800-22-rev1a/SP800-22rev1a.pdf).
This encompasses the verification of the following statistical tests performed on the
output of the PRNG as specified by the [FIPS SP800-22]:

1. The Frequency (Monobit) Test

2. Frequency Test within a Block
3. The Runs Test
4. Test for the Longest-Run-of-Ones in a Block
5. The Binary Matrix Rank Test
6. The Discrete Fourier Transform (Spectral) Test
7. The Non-overlapping Template Matching Test
8. The Overlapping Template Matching Test
9. Maurer's "Universal Statistical" Test
10. The Linear Complexity Test
11. The Serial Test
12. The Approximate Entropy Test
13. The Cumulative Sums (Cusums) Test
14. The Random Excursions Test
15. The Random Excursions Variant Test

These tests are part of standard statistical mathematical packages. Some test suites,
like the Diehard test suite, can be used to verify FIPS compliance. Alternatively, other
tools, such as the DieHarder (http://www.phy.duke.edu/~rgb/General/rand_rate.php)
or the available NIST tools (http://csrc.nist.gov/groups/ST/toolkit/random_number.html)

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 2, Part H Page 1018
Security Specification

and the corresponding recommendations (http://csrc.nist.gov/publications/nistpubs/

800-22-rev1/SP800-22rev1.pdf) may also be used.

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 2, Part H Page 1019
Security Specification

3 KEY MANAGEMENT

It is important that the encryption key size within a specific device cannot be set by
the user – this should be a factory preset entity. In order to prevent the user from
over-riding the permitted key size, the Bluetooth Baseband processing shall not accept
an encryption key given from higher software layers. Whenever a new encryption key is
required, it shall be created as defined in Section 6.4.

Changing a link key shall also be done through the defined Baseband procedures.
Depending on what kind of link key it is, different approaches are required. The details
are found in Section 3.2.7.

3.1 Key types

The link key is a 128-bit random number which is shared between two or more parties
and is the base for all security transactions between these parties. The link key itself
is used in the authentication routine. Moreover, the link key is used as one of the
parameters when the encryption key is derived.

In the following, a session is defined as the time interval for which the device is
a member of a particular piconet. Thus, the session terminates when the device
disconnects from the piconet.

The link keys are either semi-permanent or temporary. A semi-permanent link key
may be stored in non-volatile memory and may be used after the current session is
terminated. Consequently, once a semi-permanent link key is defined, it may be used
in the authentication of several subsequent connections between the devices sharing it.
The designation semi-permanent is justified by the possibility of changing it. How to do
this is described in Section 3.2.7.

The lifetime of a temporary link key is limited by the lifetime of the current session – it
shall not be reused in a later session. Typically, in a point-to-multipoint configuration
where the same information is to be distributed securely to several recipients, a
common encryption key is useful. To achieve this, the temporary link key replaces the
semi-permanent link keys. The details of this procedure are found in Section 3.2.6.

In the following, the current link key is the link key in use at the current moment.
It can be semi-permanent or temporary. Thus, the current link key is used for all
authentications and all generation of encryption keys in the on-going connection
(session).

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 2, Part H Page 1020
Security Specification

In order to accommodate different types of applications, three types of link keys have
been defined:

• the combination key KAB

• the temporary key K_temp
• the initialization key Kinit

In addition to these keys there is an encryption key, denoted K_enc. This key is
derived from the current link key. Whenever encryption is activated by an LM command,
the encryption key shall be changed automatically. The purpose of separating the
authentication key and encryption key is to facilitate the use of a shorter encryption
key without weakening the strength of the authentication procedure. There are no
governmental restrictions on the strength of authentication algorithms. However, in
some countries, such restrictions exist on the strength of encryption algorithms.

The combination key is derived from information in both devices A and B, and is
therefore always dependent on two devices. The combination key is derived for each
new combination of two devices.

The temporary link key, K_temp, shall only be used during the current session. It shall
only replace the original link key temporarily. For example, this may be utilized when a
Central wants to reach more than one device simultaneously using the same encryption
key, see Section 3.2.6.

The initialization key, Kinit, shall be used as the link key during the initialization process
when no combination keys have been defined and exchanged yet or when a link key
has been lost. The initialization key protects the transfer of initialization parameters. The
key is derived from a random number, an L-octet PIN code, and a BD_ADDR. This key
shall only be used during initialization.

The PIN may be a fixed number provided with the device (for example when there is no
user interface). Alternatively, the PIN can be selected by the user, and then entered in
both devices that are to be matched. The latter procedure should be used when both
devices have a user interface, for example a phone and a laptop. Entering a PIN in both
devices is more secure than using a fixed PIN in one of the devices, and should be
used whenever possible. Even if a fixed PIN is used, it shall be possible to change the
PIN; this is in order to prevent re-initialization by users who once obtained the PIN. If no
PIN is available, a default value of zero may be used. The length of this default PIN is
one byte, PIN (default) = 0x00. This default PIN may be provided by the Host.

For many applications the PIN code will be a relatively short string of numbers.
Typically, it may consist of only four decimal digits. Even though this gives sufficient
security in many cases, there exist countless other, more sensitive, situations where
this is not reliable enough. Therefore, the PIN code may be chosen to be any length

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 2, Part H Page 1021
Security Specification

from 1 to 16 octets. For the longer lengths, the devices exchanging PIN codes may
use software at the application layer rather than mechanical (i.e. human) interaction.
For example, this can be a Diffie-Hellman key agreement, where the exchanged key
is passed on to the Kinit generation process in both devices, just as in the case of a
shorter PIN code.

3.2 Key generation and initialization

The link keys must be generated and distributed among the devices in order to be
used in the authentication procedure. Since the link keys shall be secret, they shall
not be obtainable through an inquiry routine in the same way as the Bluetooth Device
Addresses. The exchange of the keys takes place during an initialization phase which
shall be carried out separately for each two devices that are using authentication and
encryption. The initialization procedures consist of the following five parts:

• generation of an initialization key

• generation of link key
• link key exchange
• authentication
• generation of encryption key in each device (optional)

After the initialization procedure, the devices can proceed to communicate, or the
link can be disconnected. If encryption is implemented, the E0 algorithm shall be
used with the proper encryption key derived from the current link key. For any new
connection established between devices A and B, they shall use the common link key
for authentication, instead of once more deriving Kinit from the PIN. A new encryption
key derived from that particular link key shall be created next time encryption is
activated.

If no link key is available, the LM shall automatically start an initialization procedure.

3.2.1 Generation of initialization key, Kinit

A link key is used temporarily during initialization, the initialization key Kinit. This key
shall be derived by the E22 algorithm from a BD_ADDR, a PIN code, the length of the
PIN (in octets), and a random number IN_RAND. The principle is depicted in Figure 6.4.
The 128-bit output from E22 shall be used for key exchange during the generation of a
link key. When the devices have performed the link key exchange, the initialization key
shall be discarded.

When the initialization key is generated, the PIN is augmented with the BD_ADDR. If
one device has a fixed PIN the BD_ADDR of the other device shall be used. If both

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 2, Part H Page 1022
Security Specification

devices have a variable PIN the BD_ADDR of the device that received IN_RAND shall
be used. If both devices have a fixed PIN they cannot be paired. Since the maximum
length of the PIN used in the algorithm cannot exceed 16 octets, it is possible that
not all octets of BD_ADDR will be used. This procedure ensures that Kinit depends
on the identity of the device with a variable PIN. A fraudulent device may try to test a
large number of PINs by claiming another BD_ADDR each time. It is the application’s
responsibility to take countermeasures against this threat. If the device address is kept
fixed, the waiting interval before the next try may be increased exponentially (see
Section 5.1).

The details of the E22 algorithm can be found in Section 6.3.

3.2.2 Authentication

The legacy authentication procedure shall be carried out as described in Section 5.

During each legacy authentication, a new AU_RAND_A shall be issued.

For legacy authentication, mutual authentication is achieved by first performing

the authentication procedure in one direction and then immediately performing the
authentication procedure in the opposite direction.

The secure authentication procedure is always a mutual authentication. Secure

authentication shall be carried out as described in Section 7.7.8. During each secure
authentication, new AU_RAND_C and AU_RAND_P shall be used.

As a side effect of a successful authentication procedure an auxiliary parameter, the

Authenticated Ciphering Offset (ACO), will be computed. The ACO shall be used for
ciphering key generation as described in Section 3.2.5.

The claimant/verifier status is determined by the LM.

3.2.3 [This section is no longer used]

3.2.4 Generation of a combination key

To use a combination key, it is first generated during the initialization procedure. The
combination key is the combination of two numbers generated in device A and B,
respectively. First, each device shall generate a random number, LK_RANDA and
LK_RANDB. Then, utilizing E21 with the random number and their own BD_ADDRs,
the two random numbers

LK_KA = E21 LK_RANDA, BD_ADDR_A , (EQ 1)

and

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 2, Part H Page 1023
Security Specification

LK_KB = E21 LK_RANDB, BD_ADDR_B , (EQ 2)

shall be created in device A and device B, respectively. These numbers constitute the
devices’ contribution to the combination key that is to be created. Then, the two random
numbers LK_RANDA and LK_RANDB shall be exchanged securely by XORing with
the current link key, K . Thus, device A shall send CA = K ⊕ LK_RANDA to device B,
while device B shall send CB = K ⊕ LK_RANDB to device A. If this is done during the
initialization phase the link key K = Kinit. If CA is identical to CB, then the devices shall
terminate the process of generating the combination key (e.g., by rejecting the following
authentication).

When the random numbers LK_RANDA and LK_RANDB have been mutually
exchanged, each device shall recalculate the other device’s contribution to the
combination key. This is possible since each device knows the Bluetooth Device
Address of the other device. Thus, device A shall calculate (EQ 2) and device B shall
calculate (EQ 1). After this, both devices shall XOR the two numbers to generate
the 128-bit link key. The result shall be stored in device A as the link key KAB and
in device B as the link key KBA. If the resulting link key consists of all zeroes, then
the devices shall discard the link key and terminate the process of generating the
combination key (see [Vol 2] Part C, Section 4.2.1). When both devices have derived
the new combination key, a mutual authentication procedure shall be initiated to confirm
the success of the transaction. The old link key shall be discarded after a successful
exchange of a new combination key. The message flow between Central and Peripheral
and the principle for creating the combination key is depicted in Figure 3.1.

Unit A Unit B

LK_KA = E21 (LK_RANDA , BD_ADDR_A) LK_KB = E21 (LK_RANDB , BD_ADDR_B)

CA = LK_RANDA ⊕ K CB = LK_RANDB ⊕ K

CA

CB

LK_RANDB = CB ⊕ K LK_RANDA = CA ⊕ K
LK_KB = E21 (LK_RANDB , BD_ADDR_B) LK_KA = E21 (LK_RANDA , BD_ADDR_A)
KAB = LK_KA ⊕ LK_KB KBA = LK_KA ⊕ LK_KB = KAB

Authentication

Figure 3.1: Generating a combination key. The old link key (K) is discarded after the exchange of a new
combination key has succeeded.

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 2, Part H Page 1024
Security Specification

3.2.5 Generating the encryption key

The encryption key, K_enc, is derived by algorithm E3 from the current link key, a 96-bit
Ciphering OFfset number (COF), and a 128-bit random number. The COF is determined
in one of two ways. If the current link key is a temporary link key, then COF shall be
derived from the Central’s BD_ADDR. Otherwise the value of COF shall be set to the
value of ACO as computed during the authentication procedure. Therefore:

BD_ADDR ∥ BD_ADDR, if link key is a temporary key

COF = (EQ 3)
ACO, otherwise.
There is an explicit call of E3 when the LM activates encryption. Consequently, the
encryption key is automatically changed each time the device enters encryption mode.
The details of the key generating function E3 can be found in Section 6.4.

3.2.6 Point-to-multipoint configuration

It is possible for the Central to use separate encryption keys for each Peripheral
in a point-to-multipoint configuration with ciphering activated. Then, if the application
requires more than one Peripheral to listen to the same payload, each Peripheral must
be addressed individually. This can cause unwanted capacity loss for the piconet.
Moreover, a Peripheral might not be capable of switching between two or more
encryption keys in real time (e.g., after looking at the LT_ADDR in the header).
Thus, the Central cannot use different encryption keys for broadcast messages and
individually addressed traffic. Therefore, the Central may tell several Peripherals to use
a common link key (and, hence, indirectly also to use a common encryption key) and
may then broadcast the information encrypted. For many applications, this key is only of
temporary interest. In the following discussion, this key is denoted by K_temp.

The transfer of necessary parameters shall be protected by the routine described in

Section 3.2.8. After the confirmation of successful reception in each Peripheral, the
Central shall issue a command to the Peripherals to replace their respective current link
key by the new temporary link key. Before encryption can be activated, the Central shall
also generate and distribute a common EN_RAND to all participating Peripherals. Using
this random number and the newly derived temporary link key, each Peripheral shall
generate a new encryption key.

The Central negotiates the encryption key length to use individually with each
Peripheral that will use the temporary link key. If the Central has already negotiated with
some of these Peripherals, it has knowledge of the sizes that can be accepted. There
may be situations where the permitted key lengths of some devices are incompatible. In
that case, the Central shall exclude the limiting device from the group.

When all Peripherals have received the necessary data, the Central can communicate
information on the piconet securely using the encryption key derived from the new

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 2, Part H Page 1025
Security Specification

temporary link key. Each Peripheral in possession of the temporary link key can
eavesdrop on all encrypted traffic, not only the traffic intended for itself. The Central
may tell all participants to fall back to their old link keys simultaneously.

3.2.7 Modifying the link keys

If the key change concerns combination keys, then the procedure is straightforward.
The change procedure is identical to the procedure described in Figure 3.1, using the
current value of the combination key as link key. This procedure can be carried out
at any time after the authentication and encryption start. Since the combination key
corresponds to a single link, it can be modified each time this link is established. This
will improve the security of the system since then old keys lose their validity after each
session.

Starting up an entirely new initialization procedure is also possible. In that case, user
interaction is necessary since a PIN will be required in the authentication and encryption
procedures.

3.2.8 Generating a temporary link key

The key-change routines described so far are semi-permanent. To create the temporary
link key, which can replace the current link key during a session (see Section 3.2.6),
other means are needed. First, the Central shall create a new link key from two 128-bit
random numbers, RAND1 and RAND2. This shall be done by

K_temp = E22 RAND1, RAND2, 16). (EQ 4)

This key is a 128-bit random number. The reason for using the output of E22 and not
directly choosing a random number as the key, is to avoid possible problems with
degraded randomness due to a poor implementation of the random number generator
within the device.

Then, a third random number, RAND, shall be transmitted to the Peripheral. Using E22
with the current link key and RAND as inputs, both the Central and the Peripheral
shall compute a 128-bit overlay. The Central shall send the bitwise XOR of the overlay
and the new link key to the Peripheral. The Peripheral, who knows the overlay, shall
recalculate K_temp. To confirm the success of this transaction, the devices shall
perform a mutual authentication procedure using the new link key. This procedure
shall then be repeated for each Peripheral that receives the new link key. The ACO
values from the authentications shall not replace the current ACO, as this ACO is
needed to (re)compute a ciphering key when the Central falls back to the previous
(semi-permanent) link key.

The Central activates encryption by an LM command. Before activating encryption, the

Central shall ensure that all Peripherals receive the same random number, EN_RAND,

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 2, Part H Page 1026
Security Specification

since the encryption key is derived through the means of E3 individually in all
participating devices. Each Peripheral shall compute a new encryption key as follows:

K_enc = E3 K_temp, EN_RAND, COF (EQ 5)

where the value of COF shall be derived from the Central’s BD_ADDR as specified by
equation (EQ 3). The details of the encryption key generating function are described
in Section 6.4. The message flow between the Central and the Peripheral when
generating the temporary link key is depicted in Figure 3.2.

Note: In this case the ACO produced during the authentication is not used when
computing the ciphering key.

Central Peripheral

K_temp = E22 (RAND1, RAND2, 16)

RAND

OVL = E22 (K, RAND, 16) OVL = E22 (K, RAND, 16)
C = OVL ⊕ K_temp

K_temp = OVL ⊕ C

Authentication

Figure 3.2: Temporary link key distribution and computation of the corresponding encryption key

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 2, Part H Page 1027
Security Specification

4 ENCRYPTION (E0)

User information can be protected by encryption of the packet payload; the access code
and the packet header shall never be encrypted. The encryption of the payload shall
be carried out with a stream cipher called E0 that shall be re-synchronized for every
payload. The overall principle is shown in Figure 4.1.

The stream cipher system E0 shall consist of three parts:

• the first part performs initialization (generation of the session key). The session key
generator shall combine the input bits in an appropriate order and shall shift them into
the four LFSRs used in the key stream generator.
• the second part generates the key stream bits and shall use a method derived
from the summation stream cipher generator attributable to Massey and Rueppel.
The second part is the main part of the cipher system, as it will also be used for
initialization.
• the third part performs encryption and decryption.

K_enc K_session
plain text/cipher text

address session key Key stream z

clock generator
generator
RAND
cipher text/ plain text

Figure 4.1: Stream ciphering for Bluetooth with E0.

4.1 Encryption key size negotiation

Each device implementing the Baseband specification shall have a parameter defining
the maximal allowed key length, L_max, 1 ≤ L_max ≤ 16 (number of octets in the
key). For each application using encryption, a number L_min shall be defined indicating
the shortest acceptable key size for that particular application. Before generating the
encryption key, the devices involved shall negotiate to decide the key size to use.

The Central shall send a suggested value, L_sug_c, to the Peripheral. Initially, the
suggested value shall be set to L_max_c. If L_min_p ≤ L_sug_c, and, the Peripheral
supports the suggested length, the Peripheral shall acknowledge and this value shall be
the length of the encryption key for this link. However, if both conditions are not fulfilled,
the Peripheral shall send a new proposal, L_sug_p < L_sug_c, to the Central. This

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 2, Part H Page 1028
Security Specification

value shall be the largest among all supported lengths less than the previous Central
suggestion. Then, the Central shall perform the corresponding test on the Peripheral
suggestion. This procedure shall be repeated until a key length agreement is reached,
or, one device aborts the negotiation. An abort may be caused by lack of support for
L_sug and all smaller key lengths, or if L_sug < L_min in one of the devices. In case of
an abort link encryption cannot be employed.

The possibility of a failure in setting up a secure link is an unavoidable consequence

of letting the application decide whether to accept or reject a suggested key size.
However, this is a necessary precaution. Otherwise a fraudulent device could enforce a
weak protection on a link by claiming a short maximum key size.

4.2 Encryption of broadcast messages

There may be three settings for the Baseband regarding encryption:

1. No encryption.
This is the default setting. No messages are encrypted
2. Point-to-point only encryption.
Broadcast messages are not encrypted. This may be enabled either during the
connection establishment procedure or after the connection has been established.
3. Point-to-point and broadcast encryption.
All messages are encrypted. This may be enabled after the connection has been
established only. This setting should not be enabled unless all affected links share
the same temporary link key as well as the same EN_RAND value, both used in
generating the encryption key.

Broadcast traffic Individually addressed traffic

No encryption No encryption
No encryption Encryption (semi-permanent link key)
Encryption (temporary link key) Encryption (temporary link key)
Table 4.1: Possible encryption modes for a Peripheral in possession of a temporary link key

4.3 Encryption concept

For the encryption routine, a stream cipher algorithm is used in which ciphering bits are
XORed with the data stream to be sent over the air interface. The payload is ciphered
after the CRC bits are appended, but, prior to the FEC encoding.

Each packet payload shall be ciphered separately. The cipher algorithm E0 uses the
Central’s Bluetooth Device Address (BD_ADDR_C), 26 bits of the Central real-time
clock (CLK26-1) and the encryption key K_enc as input, see Figure 4.2.

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 2, Part H Page 1029
Security Specification

The encryption key K_enc is derived from the current link key, COF, and a random
number, EN_RAND_C (see Section 6.4). The random number shall be issued by the
Central before entering encryption mode.

Note: EN_RAND_C is publicly known since it is transmitted as plain text over the air.

Within the E0 algorithm, the encryption key K_enc is modified into another key denoted
K_session. The maximum effective size of this key shall be factory preset and may be
set to any multiple of eight between one and sixteen (i.e. 8 to 128 bits). The procedure
for deriving the key is described in Section 4.5.

The E0 algorithm shall be re-initialized at the start of each new packet (i.e. for Central-
to-Peripheral as well as for Peripheral-to-Central transmission). By using CLK26-1
at least one bit is changed between two transmissions. Thus, a new keystream is
generated after each re-initialization. For packets covering more than a single slot, the
Bluetooth clock as found in the first slot shall be used for the entire packet.

The encryption algorithm E0 generates a binary keystream, Kcipℎer, which shall be

XORed with the data to be encrypted. The cipher is symmetric; decryption shall be
performed in exactly the same way using the same key as used for encryption.

Device A (Central) Device B (Peripheral)

EN_RAND_C

BD_ADDR_C BD_ADDR_C
E0 E0
CLK CLK
K_enc K_enc

Kcipher Kcipher

dataA-B
data
dataB-A

Figure 4.2: Functional description of the encryption procedure

4.4 Encryption algorithm

The system uses linear feedback shift registers (LFSRs) whose output is combined
by a simple finite state machine (called the summation combiner) with 16 states. The
output of this state machine is the key stream sequence, or, during initialization phase,
the randomized initial start value. The algorithm uses an encryption key K_enc, a

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 2, Part H Page 1030
Security Specification

48-bit Bluetooth address, the Central's clock bits CLK26-1, and a 128-bit RAND value.
Figure 4.3 shows the setup.

There are four LFSRs (LFSR1 ,...,LFSR4 ) of lengths L1 = 25, L2 = 31, L3 = 33, and,
L4 = 39, with feedback polynomials as specified in Table 4.2. The total length of the
registers is 128. These polynomials are all primitive. The Hamming weight of all the
feedback polynomials is five.

Summation Combiner Logic

LFSR1 x1t
initial values

LFSR2 x2t

LFSR3 x3t
XOR Encryption Stream Zt
LFSR4 x4t
c0t
blend

1
z-1
2
ct T1

x1t
z-1 T2
2 ct+1
x2t XOR
x3t + st+1
2

2
2

+ ÷2
3
x4t
3 2

yt

Figure 4.3: Concept of the E0 encryption algorithm

i Li feedback fi t weight

1 25 t25 + t20 + t12 + t8 + 1 5

2 31 t31 + t24 + t16 + t12 + 1 5

3 33 t33 + t28 + t24 + t4 + 1 5

4 39 t39 + t36 + t28 + t4 + 1 5

Table 4.2: The four primitive feedback polynomials

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 2, Part H Page 1031
Security Specification

Let xti denote the ttℎ symbol of LFSRi. The value yt is derived from the four-tuple
xt1, . . . , xt4 using the following equation:

4
yt = ∑ xti, (EQ 6)
i=1

where the sum is over the integers. Thus yt can take the values 0,1,2,3, or 4. The output
of the summation generator is obtained by the following equations:

zt = xt1 ⊕ xt2 ⊕ xt3 ⊕ xt4 ⊕ ct0 ∈ 0, 1 , (EQ 7)

yt + ct
st + 1 = st1+ 1, st0+ 1 = 2
∈ 0, 1, 2, 3 , (EQ 8)

ct + 1 = ct1+ 1, ct0+ 1 = st + 1 ⊕ T 1 ct ⊕ T 2 ct − 1 , (EQ 9)

where T 1 . and T 2 . are two different linear bijections over GF(4). Suppose GF(4) is
generated by the irreducible polynomial x2 + x + 1, and let α be a zero of this polynomial
in GF(4). The mappings T 1 and T 2 are now defined as:

T 1 : GF 4 GF 4
x x
T 2 : GF 4 GF 4
x α + 1 x.
The elements of GF(4) can be written as binary vectors. This is summarized in
Table 4.3.

x T1 x T2 x

00 00 00
01 01 11
10 10 01
11 11 10

Table 4.3: The mappings T1 and T2

Since the mappings are linear, they can be implemented using XOR gates; i.e.

T 1 : x1, x0 x1, x0 ,
T 2 : x1, x0 x0, x1 ⊕ x0 .

4.4.1 The operation of the cipher

Figure 4.4 gives an overview of the operation in time. The encryption algorithm shall run
through the initialization phase before the start of transmission or reception of a new

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 2, Part H Page 1032
Security Specification

packet. Thus, for multislot packets the cipher is initialized using the clock value of the
first slot in the multislot sequence.

Central → Peripheral Peripheral → Central

Init Encrypt/Decrypt Init Encrypt/Decrypt

clock cycles (time)

Figure 4.4: Overview of the operation of encryption. Between each start of a packet (TX or RX), the
LFSRs are re-initialized.

4.5 LFSR initialization

The key stream generator is loaded with an initial value for the four LFSRs (in total 128
bits) and the 4 bits that specify the values of c0 and c–1. The 132 bit initial value is
derived from four inputs by using the key stream generator. The input parameters are
the key K_enc, a 128-bit random number RAND, a 48-bit Bluetooth Device Address,
and the 26 Central's clock bits CLK26-1.

The effective length of the encryption key may vary between 8 and 128 bits. The actual
key length as obtained from E3 is 128 bits. Then, within E0, the key length may be
reduced by a mod operation between K_enc and a polynomial of desired degree. After
reduction, the result is encoded with a block code in order to distribute the starting
states more uniformly. The operation shall be as defined in (EQ 10).

When the encryption key has been created the LFSRs are loaded with their initial
values. Then, 200 stream cipher bits are created by operating the generator. Of these
bits, the last 128 are fed back into the key stream generator as an initial value of the
four LFSRs. The values of ct and ct–1 are kept. From this point on, when clocked the
generator produces the encryption (decryption) sequence which is bitwise XORed to the
transmitted (received) payload data.

In the following, octet i of a binary sequence X is X[i]. Bit 0 of X is the LSB. Then, the
LSB of X[i] corresponds to bit 8i of the sequence X, the MSB of X[i] is bit 8i + 7 of X. For
instance, bit 24 of the Bluetooth Device Address is the LSB of BD_ADDR[3].

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 2, Part H Page 1033
Security Specification

The details of the initialization shall be as follows:

1. Create the encryption key to use from the 128-bit secret key K_enc and the 128-bit
publicly known EN_RAND. Let L, 1 ≤ L ≤ 16, be the effective key length in number
of octets. The resulting encryption key is K_session:
K_session x) = g2L x K_enc x mod g1L x (EQ 10)

where deg g1L x ) = 8L and deg g2L x ≤ 128 ‐ 8L. The polynomials are defined in
Table 4.4.
2. Shift the 3 inputs K_session, the Bluetooth Device Address, the clock, and the
six-bit constant 111001 into the LFSRs. In total, 208 bits are shifted in:
a. Open all switches shown in Figure 4.5;
b. Arrange inputs bits as shown in Figure 4.5; Set the content of all shift register
elements to zero. Set t = 0.
c. Start shifting bits into the LFSRs. The rightmost bit at each level of Figure 4.5
is the first bit to enter the corresponding LFSR.
d. When the first input bit at level i reaches the rightmost position of LFSRi, close
the switch of this LFSR.
e. At t = 39 (when the switch of LFSR4 is closed), reset both blend registers c39
= c39–1 = 0; Up to this point, the content of ct and ct–1 has been of no concern.
However, their content will now be used in computing the output sequence.
f. From now on output symbols are generated. The remaining input bits are
continuously shifted into their corresponding shift registers. When the last bit
has been shifted in, the shift register is clocked with input = 0;
Note: When finished, LFSR1 has effectively clocked 30 times with feedback
closed, LFSR2 has clocked 24 times, LFSR3 has clocked 22 times, and LFSR4
has effectively clocked 16 times with feedback closed.
3. To mix initial data, continue to clock until 200 symbols have been produced with all
switches closed (t = 239);
4. Keep blend registers ct and ct–1, make a parallel load of the last 128 generated bits
into the LFSRs according to Figure 4.6 at t = 240;

After the parallel load in item 4, the blend register contents shall be updated for each
subsequent clock.

L deg g1L deg g2L

1 [8] 00000000 00000000 00000000 0000011d [119] 00e275a0 abd218d4 cf928b9b bf6cb08f

2 [16] 00000000 00000000 00000000 0001003f [112] 0001e3f6 3d7659b3 7f18c258 cff6efef

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 2, Part H Page 1034
Security Specification

L deg g1L deg g2L

3 [24] 00000000 00000000 00000000 010000db [104] 000001be f66c6c3a b1030a5a 1919808b

4 [32] 00000000 00000000 00000001 000000af [96] 00000001 6ab89969 de17467f d3736ad9

5 [40] 00000000 00000000 00000100 00000039 [88] 00000000 01630632 91da50ec 55715247

6 [48] 00000000 00000000 00010000 00000291 [77] 00000000 00002c93 52aa6cc0 54468311

7 [56] 00000000 00000000 01000000 00000095 [71] 00000000 000000b3 f7fffce2 79f3a073

8 [64] 00000000 00000001 00000000 0000001b [63] 00000000 00000000 a1ab815b c7ec8025

9 [72] 00000000 00000100 00000000 00000609 [49] 00000000 00000000 0002c980 11d8b04d

10 [80] 00000000 00010000 00000000 00000215 [42] 00000000 00000000 0000058e 24f9a4bb

11 [88] 00000000 01000000 00000000 0000013b [35] 00000000 00000000 0000000c a76024d7

12 [96] 00000001 00000000 00000000 000000dd [28] 00000000 00000000 00000000 1c9c26b9

13 [104] 00000100 00000000 00000000 0000049d [21] 00000000 00000000 00000000 0026d9e3

14 [112] 00010000 00000000 00000000 0000014f [14] 00000000 00000000 00000000 00004377

15 [120] 01000000 00000000 00000000 000000e7 [7] 00000000 00000000 00000000 00000089

16 [128] 1 00000000 00000000 00000000 00000000 [0] 00000000 00000000 00000000 00000001

Table 4.4: Polynomials used when creating K_session1

1All polynomials are in hexadecimal notation. The LSB is in the rightmost position.

In Figure 4.5, all bits are shifted into the LFSRs, starting with the least significant bit
(LSB). For instance, from the third octet of the address, BD_ADDR[2], first BD_ADDR16
is entered, followed by BD_ADDR17, etc. Furthermore, CL0 corresponds to CLK1,...,
CL25 corresponds to CLK26.

Note: The output symbols xti, i = 1, ..., 4 are taken from the positions 24, 24, 32, and
32 for LFSR1, LFSR2,LFSR3, and LFSR4, respectively (counting the leftmost position as
number 1).

8 12 20
ADR[2] CL[1] K_session[12] K_session[8] K_session[4] K_session[0] CL24
1
24 Xt

12 16 24
ADR[3] ADR[0] K_session[13] K_session[9] K_session[5] K_session[1] CL[0]L 0 0 1
2
24 Xt

4 24 28
ADR[4] CL[2] K_session[14] K_session[10] K_session[6] K_session[2] CL25
3
32 Xt

4 28 36
ADR[5] ADR[1] K_session[15] K_session[11] K_session[7] K_session[3] CL[0]U 1 1 1
32 4
Xt
CL[0]L = CL3 ... CL0
CL[0]U = CL7 ... CL4

Figure 4.5: Arranging the input to the LFSRs

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 2, Part H Page 1035
Security Specification

In Figure 4.6, the 128 binary output symbols Z0,..., Z127 are arranged in octets denoted
Z[0],..., Z[15]. The LSB of Z[0] corresponds to the first of these symbols, the MSB of
Z[15] is the last output from the generator. These bits shall be loaded into the LFSRs
according to the figure. It is a parallel load and no update of the blend registers is
done. The first output symbol is generated at the same time. The octets shall be written
into the registers with the LSB in the leftmost position (i.e. the opposite of before). For
example, Z24 is loaded into position 1 of LFSR4.

Z[12]0
8 12 20
Z[0] Z[4] Z[8]
1
24 Xt

12 16 24
Z[1] Z[5] Z[9] Z[12]7-1
24 2
Xt

4 24 28 Z[15]0
Z[2] Z[6] Z[10] Z[13]
3
32 Xt

4 28 36
Z[3] Z[7] Z[11] Z[14] Z[15]7-1
4
32 Xt

Figure 4.6: Distribution of the 128 last generated output symbols within the LFSRs.

4.6 Key stream sequence

When the initialization is finished, the output from the summation combiner is used for
encryption/decryption. The first bit to use shall be the one produced at the parallel load,
i.e. at t = 240. The circuit shall be run for the entire length of the current payload. Then,
before the reverse direction is started, the entire initialization process shall be repeated
with updated values on the input parameters.

Sample data of the encryption output sequence can be found in [Vol 2] Part G,
Section 1.1. All implementations of encryption shall produce these encryption streams
for the given initialization values.

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 2, Part H Page 1036
Security Specification

5 AUTHENTICATION

Legacy authentication uses a challenge-response scheme in which a claimant’s

knowledge of a secret key is checked through a 2-move protocol using symmetric
secret keys. The latter implies that a correct claimant/verifier pair share the same
secret key, for example K. In the challenge-response scheme the verifier challenges the
claimant to authenticate a random input (the challenge), denoted by AU_RAND_A, with
an authentication code, denoted by E1, and return the result SRES to the verifier, see
Figure 5.1. This figure also shows that the input to E1 consists of the tuple AU_RAND_A
and the Bluetooth Device Address (BD_ADDR_B) of the claimant. The use of this
address prevents a simple reflection attack1. The secret K shared by devices A and B is
the current link key.

Figure 5.1: Challenge-response for the Bluetooth.

The challenge-response scheme for symmetric keys in legacy authentication is depicted

in Figure 5.2.

1The reflection attack actually forms no threat because all service requests are dealt with on a FIFO basis.

When preemption is introduced, this attack is potentially dangerous.

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 2, Part H Page 1037
Security Specification

Claimant (User B,
Verifier (User A) with identity IDB)

RAND

SRES = E1(key, IDB, RAND)

SRES

SRES’ = E1(key, IDB, RAND)

Check: SRES’ = SRES

Figure 5.2: Challenge-response for symmetric key systems.

In legacy authentication, the verifier is not required to be the Central. The application
indicates which device has to be authenticated. Some applications only require a
one-way authentication. However, some peer-to-peer communications, should use a
mutual authentication in which each device is subsequently the challenger (verifier)
in two authentication procedures. The LM shall process authentication preferences
from the application to determine in which direction(s) the authentication(s) takes
place. For mutual authentication with the devices of Figure 5.1, after device A has
successfully authenticated device B, device B could authenticate device A by sending
an AU_RAND_B (different from the AU_RAND_A that device A issued) to device A, and
deriving the SRES and SRES’ from the new AU_RAND_B, the address of device A, and
the link key KAB.

If a legacy authentication is successful the value of ACO as produced by E1 shall be

retained.

Secure Authentication uses a challenge-response scheme in which both devices act

as a verifier and claimant in the same sequence where the knowledge of a secret key
is checked through a 4-move protocol using symmetric secret keys. The latter implies
that a correct claimant/verifier pair share the same secret key, for example K. In the
challenge-response scheme the Central challenges the Peripheral to authenticate a
random input (the challenge), denoted by AU_RAND_C, with an authentication code,
denoted by h4 and h5, and return the resulting SRES_P to the verifier, see Figure 5.3.
Similarly, the Peripheral challenges the Central to authenticate a random input (the
challenge), denoted AU_RAND_P, with an authentication code, denoted by h4 and
h5, and return the resulting SRES_C to the verifier. This figure also shows that the
inputs to h4 and h5 consist of a secret, a string “btdk”, the Bluetooth Device Address
of the Central (BD_ADDR_C), and the Bluetooth Device Address of the Peripheral
(BD_ADDR_P). The use of these addresses prevents a simple reflection attack. The
secret K shared by the Central and Peripheral is the current link key.

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 2, Part H Page 1038
Security Specification

Central Device Peripheral Device

Device Device
Authentication AU_RAND_C Authentication
Link Key Key Key
Link Key

"btdk"
"btdk"
AU_RAND_P
h4 h5 h5 h4
BD_ADDR_C AU_RAND_C AU_RAND_C BD_ADDR_C

BD_ADDR_P AU_RAND_P AU_RAND_P

BD_ADDR_P
SRES_P

SRES_C SRES_P' ACO SRES_C' SRES_P ACO

? SRES_C ?
= =
SRES_P SRES_C

Figure 5.3: Challenge and response for secure authentication.

The challenge-response scheme for symmetric keys in secure authentication when

initiated by the Central is depicted in Figure 5.4.

Central Peripheral

AU_RAND_C

AU_RAND_P

SRES_C || SRES_P’ = SRES_C’ || SRES_P =

h5(h4(link_key, ”btdk”, BD_ADDR_C, h5(h4(link_key, ”btdk”, BD_ADDR_C,
BD_ADDR_P), AU_RAND_C, BD_ADDR_P), AU_RAND_C,
AU_RAND_P) AU_RAND_P)

SRES_P

Check SRES_P’ = SRES_P

SRES_C

Check SRES_C’ = SRES_C

Figure 5.4: Challenge-response for secure authentication.

For the purposes of this authentication protocol the roles used are those applying when
the initiating device sends its AU_RAND to the responder, irrespective of whether a role
switch happens during the protocol. The device that sends AU_RAND_C shall check
SRES_P and the device that sends AU_RAND_P shall check SRES_C. Alternatively,
the device may reject the request for a role switch during the protocol.

In secure authentication, both the Central and Peripheral are the verifier and
claimant. The application indicates which device has to be authenticated, but secure
authentication is always a mutual authentication.

If a secure authentication is successful the value of ACO as produced by h5 shall be

retained.

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 2, Part H Page 1039
Security Specification

5.1 Repeated attempts

When the authentication attempt fails, a waiting interval shall pass before the verifier
will initiate a new authentication attempt to the same claimant, or before it will respond
to an authentication attempt initiated by a device claiming the same identity as the
failed device. For each subsequent authentication failure, the waiting interval shall be
increased exponentially. For example, after each failure, the waiting interval before a
new attempt can be made could be twice as long as the waiting interval prior to the
previous attempt1. The waiting interval shall be limited to a maximum.

The maximum waiting interval depends on the implementation. The waiting time shall
exponentially decrease to a minimum when no new failed attempts are made during a
certain time period. This procedure restricts the rate at which an intruder can repeat the
authentication procedure with different keys.

To protect a device's private key, a device should implement a method to prevent

an attacker from retrieving useful information about the device's private key. For this
purpose, a device should change its private key after every pairing (successful or
failed). Otherwise, it should change its private key whenever S + 3F > 8, where S is the
number of successful pairings and F the number of failed attempts since the key was
last changed.

1Another appropriate value larger than 1 may be used.

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 2, Part H Page 1040
Security Specification

6 THE AUTHENTICATION AND KEY-GENERATING

FUNCTIONS

This section describes the algorithms used for authentication and key generation.

6.1 The authentication function E1

The authentication function E1 is a computationally secure authentication code. E1 uses

the encryption function SAFER+. The algorithm is an enhanced version of an existing
64-bit block cipher SAFER-SK128, and it is freely available. In the following discussion,
the block cipher will be denoted as the function Ar which maps using a 128-bit key, a
128-bit input to a 128-bit output, i.e.

128 128 128

Ar : 0, 1 × 0, 1 0, 1
(EQ 11)
k×x t.
The details of Ar are given in the next section. The function E1 is constructed using Ar
as follows

128 128 48 32 96
E1: 0, 1 × 0, 1 × 0, 1 0, 1 × 0, 1
(EQ 12)
K, RAND, address SRES, ACO ,
where SRES = Hasℎ K, RAND, address, 6 0, . . . , 3 , where Hasℎ is a keyed hash
function defined as1

128
× 0, 1 128 × 0, 1 8 × L × 6, 12 128
Hasℎ: 0, 1 0, 1
(EQ 13)
K, I1, I2, L A′r K , E I2, L +16 Ar K, I1 ⊕ I1 ,

and where

E = 0, 1 8 × L × 6, 12 0, 1 8 × 16
(EQ 14)
X 0, . . . , L − 1 , L X i mod L for i = 0 . . . 15 ,
is an expansion of the L octet word X into a 128-bit word. The function Ar is evaluated
twice for each evaluation of E1. The key K for the second use of Ar (actually A′r) is
offset from K as follows2

1Inthis section and in Figure 6.3, the operator +16 denotes addition mod 256 of each of the 16 octets
separately.
2The constants are the largest primes below 257 for which 10 is a primitive root.

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 2, Part H Page 1041
Security Specification

K 0 = K 0 + 233 mod 256, K 1 = K 1 ⊕ 229,

K 2 = K 2 + 223 mod 256, K 3 = K 3 ⊕ 193,
K 4 = K 4 + 179 mod 256, K 5 = K 5 ⊕ 167,
K 6 = K 6 + 149 mod 256, K 7 = K 7 ⊕ 131,
(EQ 15)
K 8 = K 8 ⊕ 233, K 9 = K 9 + 229 mod 256,
K 10 = K 10 ⊕ 223, K 11 = K 11 + 193 mod 256,
K 12 = K 12 ⊕ 179, K 13 = K 13 + 167 mod 256,
K 14 = K 14 ⊕ 149, K 15 = K 15 + 131 mod 256,
A data flowchart of the computation of E1 is shown in Figure 6.1. E1 is also used
to deliver the parameter ACO (Authenticated Ciphering Offset) that is used in the
generation of the ciphering key by E3, see equations (EQ 3) and (EQ 23). The value of
ACO is formed by octets 4 to 15 of the output of the hash function defined in (EQ 13):

ACO = Hasℎ K, RAND, address, 6 4, …, 15 . (EQ 16)

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 2, Part H Page 1042
Security Specification

RAND address

48
K Ar

offset

~ 128
K +16 E
L=6

A'r

32 96

+16
16 8-bit additions mod 256
SRES ACO

Figure 6.1: Flow of data for the computation of E1

6.2 The functions Ar and A’r

The function Ar is identical to SAFER+. It consists of a set of 8 layers, (each
layer is called a round) and a parallel mechanism for generating the sub keys
Kp j , p = 1, 2, …, 17, which are the round keys to be used in each round. The function
will produce a 128-bit result from a 128-bit random input string and a 128-bit key.
Besides the function Ar, a slightly modified version referred to as A′r is used in which
the input of round 1 is added to the input of round 3. This is done to make the modified
version non-invertible and prevents the use of A′r (especially in E2x) as an encryption
function. See Figure 6.2 for details.

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 2, Part H Page 1043
Security Specification

6.2.1 The round computations

The computations in each round are a composition of encryption with a round key,
substitution, encryption with the next round key, and, finally, a Pseudo Hadamard
Transform (PHT). The computations in a round shall be as shown in Figure 6.2. The
sub keys for round r,r = 1, 2, ..., 8 are denoted K2r–1[j], K2r[j], j = 0, 1, ..., 15. After the
last round K17[j] is applied identically to all previous odd numbered keys.

6.2.2 The substitution boxes “e” and “l”

In Figure 6.2 two boxes are shown, marked “e” and “l”. These boxes implement the
same substitutions as are used in SAFER+; i.e. they implement

e, l : 0, . . . , 255 0, . . . , 255 ,
i
e : i 45 mod 257 mod 256,
l : i j s.t. i = e j .
Their role, as in the SAFER+ algorithm, is to introduce non-linearity.

Bluetooth SIG Proprietary Version Date: 2024-08-27

 BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 2, Part H Page 1044
Security Specification

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

Only for A’r in round 3

128
A input[0..15]

128
K2r-1 [0..15]

e l l e e l l e e l l e e l l e
128
K2r [0..15]

K2r [0] K2r [15]

PHT PHT PHT PHT PHT PHT PHT PHT

ROUND r, r=1,2,...,8

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

PHT PHT PHT PHT PHT PHT PHT PHT

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

PHT PHT PHT PHT PHT PHT PHT PHT

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

PHT PHT PHT PHT PHT PHT PHT PHT

Only after last round

128
K17 [0..15]

addition mod 256

bitwise XOR
PHT(x,y) = ((2x+y) mod 256, (x+y) mod 256)

Figure 6.2: One round in Ar and A’r

In Section 6.2, the permutation boxes show how input byte indices are mapped onto
output byte indices. Thus, position 8 is mapped on position 0 (leftmost), position 11 is
mapped on position 1, etc.

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 2, Part H Page 1045
Security Specification

6.2.3 Key scheduling

In each round, 2 batches of 16 octet-wide keys are needed. These round keys are
derived as specified by the key scheduling in SAFER+. Figure 6.3 gives an overview
of how the round keys Kp[j] are determined. The bias vectors B2, B3, ..., B17 shall be
computed according to following equation:

17p + i + 1mod 257

Bp i = 45 45 mod 257 mod 256 , for i = 0, . . . , 15 . (EQ 17)

128 bit Key grouped in 16 octets

0 1 14 15

XOR the
16 octets

Select octets
0 1 14 15 16 K
1
0,1,2,...,14,15
Rotate each octet left by 3 bit positions

Select octets +16

0 1 14 15 16 K2
1,2,3,...,15,16
Rotate each octet left by 3 bit positions
B
2
Select octets +16 K3
0 1 14 15 16
2,3,4,...,16,0
...
B3

Rotate each octet left by 3 bit positions

Select Bytes +16 K17

0 1 14 15 16
16,0,1,...,13,14

B 17

Figure 6.3: Key scheduling in Ar

6.3 E2-key generation function for authentication

The key used for authentication shall be derived through the procedure that is shown
in Figure 6.4. The figure shows two modes of operation for the algorithm. In the first
mode, E21 produces a 128-bit link key, K , using a 128-bit RAND value and a 48-bit
address. This mode shall be utilized when creating combination keys. In the second
mode, E22 produces a 128-bit link key, K , using a 128-bit RAND value and an L octet

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 2, Part H Page 1046
Security Specification

user PIN. The second mode shall be used to create the initialization key, and also when
a temporary link key is to be generated.

When the initialization key is generated, the PIN is augmented with the BD_ADDR, see
Section 3.2.1 for which address to use. The augmentation shall always start with the
least significant octet of the address immediately following the most significant octet of
the PIN. Since the maximum length of the PIN used in the algorithm cannot exceed 16
octets, it is possible that not all octets of BD_ADDR will be used.

This key generating algorithm again exploits the cryptographic function E2. for mode 1
(denoted E21) is computed according to following equations:

128 48 128
E21 : 0, 1 × 0, 1 0, 1
(EQ 18)
RAND, address A′r X, Y
where (for mode 1)

X = RAND ⊕ 6 × 2120
(EQ 19)
Y = address ∥ address ∥ address 127: 0

Let L be the number of octets in the user PIN. The augmenting is defined by

PIN' = the L' least significant octets of (BD_ADDR || PIN) (EQ 20)
where L' = min { 16, L+6 }.

Then, in mode 2, E2 (denoted E22) is

8L′ 128 128
E22: 0, 1 × 0, 1 × 1, 2, . . . , 16 0, 1
(EQ 21)
PIN', RAND, L′ A′r X, Y
where

X = PIN' ∥ PIN' ∥ PIN' 127: 0

120 (EQ 22)
Y = RAND ⊕ L' × 2

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 2, Part H Page 1047
Security Specification

Figure 6.4: Key generating algorithm E2 and its two modes. Mode 1 is used for combination keys, while
mode 2 is used for Kinit and K_temp

6.4 E3-key generation function for encryption

The ciphering key K_enc used by E0 shall be generated by E3. The function E3 is
constructed using A'r as follows
128 128 96 128
E3: 0, 1 × 0, 1 × 0, 1 0, 1
(EQ 23)
K, RAND, COF Hasℎ K, RAND, COF, 12
where Hash is the hash function as defined by (EQ 13). The key length produced is
128 bits. However, before use within E0, the encryption key K_enc is shortened to the
correct encryption key length, as described in Section 4.5. A block scheme of E3 is
depicted in Figure 6.5.

The value of COF is determined as specified by equation (EQ 3).

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 2, Part H Page 1048
Security Specification

Figure 6.5: Generation of the encryption key

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 2, Part H Page 1049
Security Specification

7 SECURE SIMPLE PAIRING

The Secure Simple Pairing security functions and procedures are described in this
section. In addition, a cryptographic analysis of each procedure is provided.

There are five phases of Secure Simple Pairing:

• Phase 1: Public key exchange

• Phase 2: Authentication stage 1
• Phase 3: Authentication stage 2
• Phase 4: Link key calculation
• Phase 5: LMP Authentication and Encryption

Phases 1, 3, 4 and 5 are the same for all protocols whereas phase 2 (Authentication
stage 1) is different depending on the protocol used. Distributed through these five
phases are 13 steps as shown in Figure 7.1.

Initiating Non­initiating
Device A Device B

Step 1: Public Key Exchange

(Same for all protocols)

Steps 2 to 8: Authentication stage 1

(Protocol dependent)

Steps 9 to 11: Authentication stage 2

(Same for all protocols)

Step 12: Link Key Calculation

(Same for all protocols)

Step 13: Encryption

(Same for all protocols)

Figure 7.1: Secure Simple Pairing security phases

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 2, Part H Page 1050
Security Specification

The terminology used in the security sections is defined in Table 7.1:

Term Definition
Cx Commitment value from device X
Cxi ith commitment value from device X. Only used in the passkey entry protocol
DHKey Diffie Hellman key
Ex Check value from device X
f1( ) Used to generate the 128-bit commitment values Ca and Cb
f2( ) Used to compute the link key and possible other keys from the DHKey and random nonces
f3( ) Used to compute check values Ea and Eb in Authentication stage 2
g( ) Used to compute numeric check values
IOcapA IO capabilities of device A
IOcapB IO capabilities of device B
LK Link Key
Nx Nonce (unique random value) from device X
Nxi ith nonce (unique random value) from device X. Only used in the passkey entry protocol
PKx Public Key of device X
rx Random value generated by device X
rxi Bit i of the random value rx. Only used in the passkey entry protocol
SKx Secret (Private) Key of device X
Vx Confirmation value on device X. Only used in the numeric compare protocol.
X BD_ADDR of device X

Table 7.1: Terminology

7.1 Phase 1: Public key exchange

Initially, each device generates its own Elliptic Curve Diffie-Hellman (ECDH) public-
private key pair (step 1). See Section 5.1 for recommendations on how frequently this
key pair should be changed.

Pairing is initiated by the initiating device sending its public key to the receiving device
(step 1a). The responding device replies with its own public key (step 1b). If the two
public keys have the same X coordinate and neither is the debug key (see [Vol 4] Part
E, Section 7.6.4), each device shall fail the pairing process. These public keys are not
regarded as secret although they may identify the devices.

When both devices’ Controllers and Hosts support Secure Connections, the P-256
elliptic curve is used. When at least one device’s Controller or Host doesn’t support
Secure Connections, the P-192 elliptic curve is used.

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 2, Part H Page 1051
Security Specification

Initiating Non­initiating
Device A Device B

1a. PKa

1b. PKb

start computing DHKey start computing DHKey

DHKey = P192 (SKa, PKb) or DHKey = P192 (SKb, PKa) or
DHKey = P256 (SKa, PKb) DHKey = P256 (SKb, PKa)

Figure 7.2: Public key exchange details

A device shall validate that any public key received from any BD_ADDR is on the
correct curve (P-192 or P-256) - see Section 7.6.

7.2 Phase 2: Authentication stage 1

Authentication stage 1 has three different protocols: Numeric Comparison, Out-of-Band,

and Passkey Entry. The Just Works association model shares the Numeric Comparison
protocol and does not have a separate protocol.

The protocol is chosen based on the IO capabilities of the two devices.

Initiating Non­initiating
Device A Device B

Steps 2 to 8: Protocol dependent

Figure 7.3: Authentication stage 1 (high level)

The three protocols are described in the following sections.

7.2.1 Authentication stage 1: Numeric Comparison protocol

The Numeric Comparison protocol provides limited protection against active "man-
in-the-middle" (MITM) attacks as an active man-in-the-middle will succeed with a
probability of 0.000001 on each iteration of the protocol. Provided that there is no
MITM at the time the pairing is performed, the shared Link Key that is generated is
computationally secure from even a passive eavesdropper that may have been present
during the pairing.

The sequence diagram of Authentication stage 1 for the Numeric Comparison protocol
from the cryptographic point of view is shown in Figure 7.4.

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 2, Part H Page 1052
Security Specification

Initiating Non­initiating
Device A Device B

2a. Select Random Na 2b. Select Random Nb

3a. Set ra and rb to 0 3b. Set rb and ra to 0

3c. Compute commitment:

Cb=f1(PKbx,PKax,Nb,0)

4. Cb

5. Na

6. Nb

6a. check if Cb=f1(PKbx,PKax,Nb,0)

If check fails, abort

Va and Vb are 6 digit numbers to be displayed

on each side
(for no­display devices numbers are NOT displayed)

7a. Va=g(PKax,PKbx,Na,Nb) 7b. Vb=g(PKax,PKbx,Na,Nb)

8. USER checks if Va=Vb and confirms on each end

(for no­display devices user confirms ’ok’)

Proceed if user Proceed if user

confirms “ok” confirms “ok”

Figure 7.4: Authentication stage 1: Numeric Comparison protocol details

After the public keys have been exchanged, each device selects a random 128-bit
nonce (step 2). This value is used to mitigate replay attacks and shall be freshly
generated with each instantiation of the pairing protocol. This value shall be generated
using a random number generator that meets the requirements of Section 2.

Following this the responding device then computes a commitment to the two public
keys that have been exchanged and its own nonce value (step 3c). This commitment
is computed as a one-way function of these values and is transmitted to the initiating
device (step 4). The commitment prevents an attacker from changing these values at a
later time.

The initiating and responding devices then exchange their respective nonce values
(steps 5 and 6) and the initiating device confirms the commitment (step 6a). A failure at

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 2, Part H Page 1053
Security Specification

this point indicates the presence of an attacker or other transmission error and causes
the protocol to abort. The protocol may be repeated with or without the generation of
new public-private key pairs, but, as stated above, new nonces must be generated if the
protocol is repeated.

Assuming that the commitment check succeeds, the two devices each compute 6-digit
confirmation values that are displayed to the user on their respective devices (steps 7a,
7b, and 8). The user is expected to check that these 6-digit values match and to confirm
if there is a match. If there is no match, the protocol aborts and, as before, new nonces
must be generated if the protocol is to be repeated.

An active MITM must inject its own key material into this process to have any effect
other than denial-of-service. A simple MITM attack will result in the two 6-digit display
values being different with probability 0.999999. A more sophisticated attack may
attempt to engineer the display values to match, but this is thwarted by the commitment
sequence. If the attacker first exchanges nonces with the responding device, it must
commit to the nonce that it will use with the initiating device before it sees the nonce
from the initiating device. If the attacker first exchanges nonces with the initiating
device, it must send a nonce to the responding device before seeing the nonce from
the responding device. In each case, the attacker must commit to at least the second
of its nonces before knowing the second nonce from the legitimate devices. It therefore
cannot choose its own nonces in such a way as to cause the display values to match.

7.2.2 Authentication stage 1: Out of Band protocol

The Out-of-Band protocol is used when authentication information has been received
by at least one of the devices and indicated in the OOB Authentication Data Present
parameter in the LMP IO capability exchange sequence. The mode in which the
discovery of the peer device is first done in-band and then followed by the transmission
of authentication parameters through OOB interface is not supported. The sequence
diagram for Authentication stage 1 for Out of Band from the cryptographic point of view
is shown in Figure 7.5.

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 2, Part H Page 1054
Security Specification

Initiating Non­initiating
Device A Device B

2a. Set ra=rand, rb=0 2b. Set rb=rand, ra=0

3a. Compute commitment 3b. Compute commitment

Ca=f1(PKax,PKax,ra,0) and send 4a. Cb=f1(PKbx,PKbx,rb,0) and send 4b.

OOB Communication
A = Bluetooth address of A
B = Bluetooth address of B

At least one direction required

4a. A, ra, Ca

4b. B, rb, Cb

LMP Pairing begins

5a. If 4b received reset rb to the 5b. If 4a received reset ra to the

received value, and if received value, and if
Cb≠f1(PKbx, PKbx,rb,0) abort. Ca≠f1(PKax,PKax,ra,0) abort.
If 4b received and Device B’s If 4a received and Device A’s
IO capability does not indicate IO capability does not indicate
OOB authentication data present, OOB authentication data present,
then set ra=0. then set rb=0.

6a. Select random Na 6b. Select random Nb

7. Na

8. Nb

Figure 7.5: Authentication stage 1: Out of Band details

Principle of operation: If both devices can transmit and/or receive data over an
out-of-band channel, then mutual authentication will be based on the commitments
of the public keys (Ca and Cb) exchanged OOB in Authentication stage 1. If OOB
communication is possible only in one direction, then authentication of the device
receiving the OOB communication will be based on that device knowing a random
number r sent via OOB. In this case, r must be secret: r can be created afresh every

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 2, Part H Page 1055
Security Specification

time, or access to the device sending r must be restricted. If r is not sent by a device, it
is assumed to be 0 by the device receiving the OOB information in step 4a or 4b.

Roles of A and B: The OOB Authentication stage 1 protocol is symmetric with respect
to the roles of A and B. It does not require that device A always will initiate pairing and
it automatically resolves asymmetry in the OOB communication, e.g. in the case when
one of the devices has an NFC tag and can only transmit OOB.

Order of steps: The public key exchange must happen before the verification step 5.
In the diagram the in-band public key exchange between the devices (step 1) is done
before the OOB communication (step 4). But when the pairing is initiated by an OOB
interface, public key exchange will happen after the OOB communication (step 1 will be
between steps 4 and 5).

Values of ra and rb: Since the direction of the peer's OOB interface cannot be verified
before the OOB communication takes place, a device should always generate and if
possible transmit through its OOB interface a random number r to the peer. Each device
applies the following rules locally to set the values of its own r and the value of the
peer's r:

1. Initially, r of the device is set to a random number and r of the peer is set to 0 (step
2).
2. If a device has received OOB, it sets the peer's r value to what was sent by the
peer (Step 5).
3. If the remote device's OOB Authentication Data parameter sent in the LMP IO
capabilities exchange sequence is set to No OOB Data Received, it sets its own r
value to 0 (Step 5)

These rules ensure that when entering Authentication stage 2, both A and B have the
same values for ra and rb if OOB communication took place.

7.2.3 Authentication stage 1: Passkey Entry protocol

The Passkey Entry protocol is used when LMP IO capability exchange sequence
indicates that Passkey Entry shall be used.

The sequence diagram for Authentication stage 1 for Passkey Entry from the
cryptographic point of view is shown in Figure 7.6.

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 2, Part H Page 1056
Security Specification

Initiating Non­initiating
Device A Device B

Host

2a. Inject secret ra; Set rb = ra 2b. Inject secret rb; Set ra = rb

Execute 20 times
ra = ra1 | ra2 | … ra20
rb = rb1 | rb2 | … rb20
New random number is selected in
each round

3a. Select random Nai 3b. Select random Nbi

4a. Compute commitment: 4b. Compute commitment:

Cai=f1(PKax,PKbx,Nai,rai) Cbi=f1(PKbx,PKax,Nbi,rbi)

5. Cai

6. Cbi

7. Nai

7b. Check if Cai=f1(PKax,PKbx,Nai,rbi)

If check fails, abort

8. Nbi

8a. Check if Cbi=f1(PKbx,PKax,Nbi,rai)

If check fails, abort

Figure 7.6: Authentication stage 1: Passkey Entry details

The user inputs an identical Passkey into both devices. Alternately, the Passkey may be
generated and displayed on one device, and the user then inputs it into the other (step
2). This short shared key will be the basis of the mutual authentication of the devices.
The Passkey should be generated randomly during each pairing procedure and not be
reused from a previous procedure. Static Passkeys should not be used since they can
compromise the security of the link.

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 2, Part H Page 1057
Security Specification

Steps 3 to 8 are repeated 20 times since a 6-digit Passkey is 20 bits

(999999=0xF423F). If the device allows a shorter passkey to be entered, it shall be
prefixed with zeros (e.g. “1234” is equivalent to “001234”).

In Steps 3 to 8, each side commits to each bit of the Passkey, using a long nonce (128
bits), and sending the hash of the nonce, the bit of the Passkey, and both public keys to
the other party. The parties then take turns revealing their commitments until the entire
Passkey has been mutually disclosed. The first party to reveal a commitment for a given
bit of the Passkey effectively reveals that bit of the Passkey in the process, but the other
party then has to reveal the corresponding commitment to show the same bit value for
that bit of the Passkey, or else the first party will then abort the protocol, after which no
more bits of the Passkey are revealed.

This "gradual disclosure" prevents leakage of more than 1 bit of un-guessed Passkey
information in the case of a MITM attack. A MITM attacker with only partial knowledge
of the Passkey will only receive one incorrectly-guessed bit of the Passkey before the
protocol fails. Hence, a MITM attacker who engages first one side, then the other will
only gain an advantage of at most two bits over a simple brute-force guesser, making
the probability of success 0.000004 instead of 0.000001.

The long nonce is included in the commitment hash to make it difficult to brute-force
even after the protocol has failed. The public Diffie-Hellman values are included to tie
the Passkey protocol to the original ECDH key exchange, to prevent a MITM from
substituting the attacker's public key on both sides of the ECDH exchange in standard
MITM fashion.

At the end of this stage, Na is set to Na20 and Nb is set to Nb20 for use in
Authentication stage 2.

7.3 Phase 3: Authentication stage 2

The second stage of authentication then confirms that both devices have successfully
completed the exchange. This stage is identical in all three protocols and is shown in
Figure 7.7.

Each device computes a new confirmation value that includes the previously exchanged
values and the newly derived shared key (step 9). The initiating device then transmits
its confirmation value which is checked by the responding device (step 10). If this check
fails, it indicates that the initiating device has not confirmed the pairing, and the protocol
shall be aborted. The responding device then transmits its confirmation value which is
checked by the initiating device (step 11). A failure indicates that the responding device
has not confirmed the pairing and the protocol should abort.

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 2, Part H Page 1058
Security Specification

Initiating Non­initiating
Device A Device B

”IOcap” is the IO capability of A

”IOcapB” is the IO capability of B
A = Bluetooth address of A
B = Bluetooth address of B

9a. compute 9b. compute

Ea=f3(DHKey,Na,Nb,rb,IOcapA,A,B) Eb=f3(DHKey,Nb,Na,ra,IOcapB,B,A)

10. Ea

10b. check
Ea=f3(DHKey,Na,Nb,rb,IOcapA,A,B)
If check fails, abort

11. Eb

11a. check
Eb=f3(DHKey,Nb,Na,ra,IOcapB,B,A)
If check fails, abort

Figure 7.7: Authentication stage 2

7.4 Phase 4: Link key calculation

Once both sides have confirmed the pairing, a link key is computed from the derived
shared key and the publicly exchanged data (step 12). The nonces ensure the
freshness of the key even if long-term ECDH values are used by both sides. This link
key is used to maintain the pairing.

When computing the link key both parties shall input the parameters in the same
order (shown in Figure 7.8) to ensure that both devices compute the same key:
Nc is whichever of Na and Nb was generated by the Central and Np is the other,
while BD_ADDR_C and BD_ADDR_P are the addresses of the Central and Peripheral
respectively.

Initiating Non­initiating
Device A Device B

12. Both parties compute link key

LK=f2(DHKey,Nc,Np,”btlk”, BD_ADDR_C, BD_ADDR_P)

Figure 7.8: Link key calculation

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 2, Part H Page 1059
Security Specification

7.5 Phase 5: LMP authentication and encryption

The final phase in Secure Simple Pairing consists of authentication and generation of
the encryption key. This is the same as the final steps in legacy pairing.

7.6 Elliptic curve definition

Secure Simple Pairing supports two elliptic curves: P-192 and P-256.

Secure Simple Pairing uses the FIPS P-192 and P-256 curves defined in FIPS 186-41.
Elliptic curves are specified by p, a, b and are of the form:

E: y2 = x3 + ax + b (mod p)

In NIST P-192 and P-256, a is -3 and the following parameters are given:

• The prime modulus p, order r, base point x-coordinate Gx, base point y-coordinate
Gy.
• The integers p and r are given in decimal form; bit strings and field elements are
given in hex.

For P-192:
p =6277101735386680763835789423207666416083908700390324961279
r =6277101735386680763835789423176059013767194773182842284081
b =64210519 e59c80e7 0fa7e9ab 72243049 feb8deec c146b9b1
Gx=188da80e b03090f6 7cbf20eb 43a18800 f4ff0afd 82ff1012
Gy=07192b95 ffc8da78 631011ed 6b24cdd5 73f977a1 1e794811

The function P192 is defined as follows. Given an integer u, 0 < u < r, and a point V on
the curve E, the value P192(u,V) is computed as the x-coordinate of the uth multiple uV
of the point V.

The private keys shall be between 1 and r÷2, where r is the order of the Abelian group
on the elliptic curve (i.e., between 1 and 2192÷2).

For P-256:
p =115792089210356248762697446949407573530086143415290314195533631308867097853951
r =115792089210356248762697446949407573529996955224135760342422259061068512044369
b =5ac635d8 aa3a93e7 b3ebbd55 769886bc 651d06b0 cc53b0f6 3bce3c3e 27d2604b
Gx=6b17d1f2 e12c4247 f8bce6e5 63a440f2 77037d81 2deb33a0 f4a13945 d898c296
Gy=4fe342e2 fe1a7f9b 8ee7eb4a 7c0f9e16 2bce3357 6b315ece cbb64068 37bf51f5

1http://dx.doi.org/10.6028/NIST.FIPS.186-4

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 2, Part H Page 1060
Security Specification

The function P256 is defined as follows. Given an integer u, 0 < u < r, and a point V on
the curve E, the value P256(u, V) is computed as the x-coordinate of the uth multiple uV
of the point V.

The private keys shall be between 1 and r÷2, where r is the order of the Abelian group
on the elliptic curve (i.e., between 1 and 2256÷2).

A valid public key Q = (XQ, YQ) is one where XQ and YQ are both in the range 0 to p -
1 and satisfy the equation (YQ)2 = (XQ)3 + aXQ + b (mod p) in the relevant curve's finite
field.

A device can validate a public key by directly checking the curve equation, by
implementing elliptic curve point addition and doubling using formulas that are valid
only on the correct curve, or by other means.

7.7 Cryptographic function definitions

In addition to computing the Elliptic Curve Diffie Hellman key, the Numeric Comparison,
Out-of-Band and Passkey Entry protocols require four cryptographic functions. These
functions are known as f1, g, f2 and f3.

f1 is used to generate the 128-bit commitment values Ca and Cb

g is used to compute the 6-digit numeric check values
f2 is used to compute the link key and possible other keys from the DHKey and
random nonces
f3 is used to compute check values Ea and Eb in Authentication stage 2.

The basic building block for these functions is based on SHA-256, specified in [FIPS
PUB 180-4] (http://dx.doi.org/10.6028/NIST.FIPS.180-4).

Inside the f1, g, f2, and f3 cryptographic functions, when a multi-octet integer input
parameter is used as input to the SHA-256 and HMAC-SHA-256 functions, the most
significant octet of the integer parameter shall be the first octet of the stream and the
least significant octet of the integer parameter shall be the last octet of the stream. The
output of the f1, g, f2, and f3 cryptographic functions is a multi-octet integer where the
first octet out of SHA-256 and HMAC-SHA-256 shall be the MSB and the last octet shall
be the LSB of that parameter.

7.7.1 The Secure Simple Pairing commitment function f1

The commitments are computed with function f1. The definition of the Secure Simple
Pairing commitment function makes use of the MAC function HMAC based on
SHA-256x, which is denoted as HMAC-SHA-256X with 128-bit key X.

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 2, Part H Page 1061
Security Specification

The inputs to the Secure Simple Pairing function f1 are specified in Table 7.2.

Input Bits with P-192 Bits with P-256

U 192 256
V 192 256
X 128 128
Z 8 8

Table 7.2: Inputs to the f1 function

Z is zero (i.e., 8 bits of zeros) for Numeric Comparison and OOB protocol. In the
Passkey protocol the most significant bit of Z is set equal to one and the least significant
bit is made up from one bit of the passkey e.g. if the passkey bit is 1 then Z = 0x81 and
if the passkey bit is 0 then Z = 0x80.

The output of the Secure Simple Pairing f1 function is:

f1(U, V, X, Z) = HMAC-SHA-256X (U || V || Z) ÷ 2128

The inputs to f1 are different depending on the different protocols as specified in

Table 7.3.

Numeric Comparison Out-Of-Band Passkey Entry

Ca = f1(PKax, PKbx, Na, 0) Ca = f1(PKax, PKax, ra, 0) Cai = f1(PKax, PKbx, Nai, rai)
Cb = f1(PKbx, PKax, Nb, 0) Cb = f1(PKbx, PKbx, rb, 0) Cbi = f1(PKbx, PKax, Nbi, rbi)

Table 7.3: Inputs to f1 for the different protocols

where PKax denotes the x-coordinate of the public key PKa of A. Similarly, PKbx
denotes the x-coordinate of the public key PKb of B. Nai is the nonce value of ith round.
For each round Nai value is a new 128 bit number. Similarly, rai is one bit value of the
passkey expanded to 8 bits (either 0x80 or 0x81).

Na and Nb are nonces from Devices A and B. ra and rb are random values generated
by devices A and B.

7.7.2 The Secure Simple Pairing numeric verification function g

The Secure Simple Pairing g function is defined as follows:

The inputs to the Secure Simple Pairing function g are specified in Table 7.4.

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 2, Part H Page 1062
Security Specification

Input Bits with P-192 Bits with P-256

U 192 256
V 192 256
X 128 128
Y 128 128

Table 7.4: Inputs to the g function

The output of the Secure Simple Pairing g function is:

g(U, V, X, Y) = SHA-256(U || V || X || Y) mod 232

The numeric verification value is taken as six least significant digits of the 32-bit integer
g(PKax, PKbx, Na, Nb) where PKax denotes the x-coordinate of the public key PKa of A
and PKbx denotes the x-coordinate of the public key PKb of B.

Output of SHA-256 is truncated to 32 bits by taking the least significant 32 bits of the
output of SHA-256. This value is converted to decimal numeric value. The checksum
used for numeric comparison is the least significant six digits.

Compare Value = g (U, V, X, Y) mod 106

For example, if output = 0x 01 2e b7 2a then decimal value = 19838762 and the

checksum used for numeric comparison is 838762.

7.7.3 The Secure Simple Pairing key derivation function f2

The definition of the Secure Simple Pairing key derivation function makes use of the
MAC function HMAC based on SHA-256, which is denoted as HMAC-SHA-256W with
192-bit or 256-bit key W.

The inputs to the Secure Simple Pairing function f2 are specified in Table 7.5.

Input Bits with P-192 Bits with P-256

W 192 256
N1 128 128
N2 128 128
keyID 32 32
A1 48 48
A2 48 48

Table 7.5: Inputs to the f2 function

The string "btlk" is mapped into a keyID using ASCII as 0x62746C6B.

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 2, Part H Page 1063
Security Specification

The output of the Secure Simple Pairing f2 function is:

f2(W, N1, N2, KeyID, A1, A2) = HMAC-SHA-256W (N1 || N2 || KeyID || A1 || A2) ÷ 2128

The output of f2 is taken as the 128 most significant (leftmost) bits of the output of
HMAC-SHA-256.

The link key is then calculated as:

LK = f2(DHKey, Nc, Np, "btlk", BD_ADDR_C, BD_ADDR_P)

Nc is whichever of N1 and N2 was generated by the Central and sent to the Peripheral;
Np is the other.

7.7.4 The Secure Simple Pairing check function f3

The definition of the Secure Simple Pairing f3 check function makes use of the MAC
function HMAC based on SHA-256, which is denoted as HMAC-SHA-256W with 192-bit
or 256-bit key W.

The inputs to the Secure Simple Pairing function f3 are specified in Table 7.6.

Input Bits with P-192 Bits with P-256

W 192 256
N1 128 128
N2 128 128
IOcap 24 24
A1 48 48
A2 48 48

Table 7.6: Inputs to the f3 function

IOcap is three octets with the most significant octet as the Authentication Requirements
parameter, the middle octet as the LMP Out-of-Band Authentication Data parameter,
and the least significant octet as the LMP IO capability parameter.

The output of the Secure Simple Pairing f3 function is:

f3(W, N1, N2, R, IOcap, A1, A2) = HMAC-SHA-256W (N1 || N2 || R || IOcap || A1 || A2) ÷ 2128

The output of f3 is taken as the 128 most significant (leftmost) bits of the output of
HMAC-SHA-256. The check values are computed with function f3. The inputs to f3 are
different depending on the different protocols, as specified in Table 7.7.

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 2, Part H Page 1064
Security Specification

Numeric Comparison Out-Of-Band Passkey Entry

Ea = f3(DHKey, Na, Nb, 0, IO- Ea = f3( DHKey, Na, Nb, rb, IO- Ea = f3( DHKey, Na20, Nb20,
capA, A, B) capA, A, B) rb, IOcapA, A, B)
Eb = f3(DHKey, Nb, Na, 0, IO- Eb = f3(DHKey, Nb, Na, ra, IO- Eb = f3(DHKey, Nb20, Na20,
capB, B, A) capB, B, A) ra, IOcapB, B, A)

Table 7.7: Inputs to f3 for the different protocols

DHKey denotes the shared secret Diffie-Hellman Key computed as P192(SKa, PKb)
or P256(SKa, PKb) by A and as P192(SKb, PKa) or P256(SKb, PKa) by B. IOcapA
denotes the IO capability data of A and IOcapB denotes the IO capability data of B. In
Passkey Entry, the data ra and rb are 6-digit passkey values which are expressed as a
128-bit integer. For instance, if the 6-digit value of ra is 131313, then

R = 0x 00 00 00 00 00 00 00 00 00 00 00 00 00 02 00 f1.

The input A is the BD_ADDR of device A and the input B is the BD_ADDR of device B.

7.7.5 [This section is no longer used]

7.7.6 The AES encryption key generation function h3

AES encryption keys are created using the AES encryption key generation function h3.
The definition of the AES encryption key generation function makes use of the MAC
function HMAC based on SHA-256, which is denoted as HMAC-SHA-256T with 128-bit
key T.

The inputs to function h3 are specified in Table 7.8.

Input Bits with P-256

T 128
keyID 32
A1 48
A2 48
ACO 64

Table 7.8: Inputs to the h3 function

A1 is the BD_ADDR of the Central. A2 is the BD_ADDR of the Peripheral. ACO is the 64
bit ACO output from h5. T is the 128 bit Bluetooth Link Key derived from f2.

The string “btak” (Bluetooth AES Key) is mapped into a keyID using ASCII as
0x6274616B.

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 2, Part H Page 1065
Security Specification

The output of function h3 is:

h3(W, keyID, A1, A2, ACO) = HMAC-SHA-256T(KeyID || A1 || A2 || ACO) ÷ 2128

The output of h3 is taken as the 128 most significant (leftmost) bits of the output of
HMAC-SHA-256.

7.7.7 The Device authentication key generation function h4

With Secure Connections, a device authentication key is created using function h4. The
definition of the device authentication key generation function makes use of the MAC
function HMAC based on SHA-256, which is denoted as HMAC-SHA-256T with 128-bit
key T.

The inputs to function h4 are specified in Table 7.9.

Input Bits with P-256

T 128
keyID 32
A1 48
A2 48

Table 7.9: Inputs to the h4 function

A1 is the BD_ADDR of the Central. A2 is the BD_ADDR of the Peripheral. T is the 128
bit Bluetooth Link Key derived from f2.

The string “btdk” (Bluetooth Device Key) is mapped into a keyID using ASCII as
0x6274646B.

The output of function h4 is:

h4(W, KeyID, A1, A2) = HMAC-SHA-256T(KeyID || A1 || A2) ÷ 2128

The output of h4 is taken as the 128 most significant (leftmost) bits of the output of
HMAC-SHA-256.

7.7.8 The Device authentication confirmation function h5

With Secure Connections, device authentication confirmation values are created using
function h5. The definition of the device authentication confirmation function makes use
of the MAC function HMAC based on SHA-256, which is denoted as HMAC-SHA-256S
with 128-bit key S.

The inputs to function h5 are specified in Table 7.10.

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 2, Part H Page 1066
Security Specification

Input Bits with P-256

S 128
R1 128
R2 128

Table 7.10: Inputs to the h5 function

R1 is the 128 bit random number (AU_RAND_C) from the Central during the Link
Manager device authentication sequence. R2 is the 128 bit random number from the
Peripheral (AU_RAND_P) during the Link Manager device authentication sequence. S
is the 128-bit Bluetooth Device Authentication Key derived from h4.

The output of function h5 is:

h5(W, R1, R2 ) = HMAC-SHA-256S(R1 || R2) ÷ 2128

The output of h5 is taken as the 128 most significant (leftmost) bits of the output of
HMAC-SHA-256. The first 32 bits (leftmost) become the SRES_C. The next 32 bits
become the SRES_P. The final 64 bits become the Authentication Ciphering Offset
(ACO), which is used in h3 and as the IV for Encryption Start for the encryption nonce.

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 2, Part H Page 1067
Security Specification

8 [THIS SECTION IS NO LONGER USED]

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 2, Part H Page 1068
Security Specification

9 AES-CCM ENCRYPTION FOR BR/EDR

The Baseband provides security using Counter with CBC-MAC (CCM) as defined in
IETF RFC 3610 (http://www.ietf.org/rfc/rfc3610.txt) with a modification to the B1 counter
mode block format that omits the length of the additional authenticated data. The
description of the algorithm can also be found in the NIST Special Publication 800-38C
(http://csrc.nist.gov/publications/PubsSPs.html).

Using the notation in [4], CCM has two size parameters, M and L.

The Baseband defines these to be:

M = 4; indicating that the MIC length is 4 octets (32 bits)

Size of M represents a trade-off between message expansion and the probability that
an attacker can undetectably modify a message.

L = 2; indicating that the Length field is 2 octets (16 bits)

Size of L requires a trade-off between the maximum message size and the size of the
Nonce.

9.1 Nonce formats

All of the parameters in the nonce are unique per logical transport. The nonce will be 13
octets and will have two formats. The first format is called the payload counter format
and is used for ACL packets on the primary LT_ADDR. The second format is called the
clock format and is used for eSCO packets.

The reason for two formats has to do with two factors: potential security attacks and
synchronization. Since ACL packets on the primary LT_ADDR carry protocol, they are
susceptible to attacks that eSCO packets (only data) are not.

The descriptions of the two nonce formats are provided in Table 9.1.

Octet Field Octets Payload Counter Format Description Clock Format Description
0 Nonce0 1 PayloadCounter[7:0] CLK[8:1]
1 Nonce1 1 PayloadCounter[15:8] CLK[16:9]
2 Nonce2 1 PayloadCounter[23:16] CLK[24:17]

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 2, Part H Page 1069
Security Specification

Octet Field Octets Payload Counter Format Description Clock Format Description
3 Nonce3 1 PayloadCounter[31:24] Bits 2-0:
CLK[27:25]

Bits 7-3:
dayCounter[4:0]
4 Nonce4 1 Bits 3-0: PayloadCounter[35:32] Bits 5-0:
dayCounter[10:5]
Bit 4: zero-length ACL-U
continuation packet (1=zero-length Bits 7-6:
ACL-U continuation packet, nonceType =
0=otherwise) 0b01 (eSCO)

Bit 5: direction (0=Central to Peripheral,

1=Peripheral to Central)

Bits 7-6:
nonceType = 0b00 (ACL)
5 Nonce5 1 IV[7:0]
6 Nonce6 1 IV[15:8]
7 Nonce7 1 IV[23:16]
8 Nonce8 1 IV[31:24]
9 Nonce9 1 IV[39:32]
10 Nonce10 1 IV[47:40]
11 Nonce11 1 IV[55:48]
12 Nonce12 1 IV[63:56]

Table 9.1: Nonce formats

In the payload counter format, the PayloadCounter starts at zero for the first encrypted
packet in each direction after encryption is started or resumed and increments by one
every time an encrypted payload including zero-length payloads is accepted by the
remote device.

Note: It is possible that when encryption is being enabled or resumed, a packet may
first get transmitted unencrypted and then get retransmitted encrypted. In such a case,
the PayloadCounter gets incremented by one when the encrypted retransmission of the
packet gets accepted by the remote device.

Bit 4 of Octet 4 shall be set to 1 for a zero length ACL-U continuation packet (see [Vol 2]
Part B, Section 7.6.2.2), otherwise it shall be set to 0.

In the clock format, the Central's clock (CLK) used for the nonce shall be the value in
the first slot of the packet. After a new ACL connection has been established or a role

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 2, Part H Page 1070
Security Specification

switch has been successfully performed and when eSCO is successfully established for
the first time then the dayCounter value shall be initialized to:

1 if CLK27 in the first clock format nonce is 0, and initialization procedure 2 (see [Vol
2] Part B, Section 8.6.3) is used
0 otherwise.

After the dayCounter has been initialized, it shall increment by one every time the
Central's clock (CLK) rolls over to 0x0000000 (approximately every 23.3 hours).

Note: When Security Mode 4 is in use, eSCO will not be established before encryption
is started.

The IV is an 8 octet field. For encryption start, all octets of the IV are from the ACO
output of the last execution of h5 prior to the start of encryption. Multiple device
authentications may occur prior to starting encryption but only the ACO of the last
device authentication is used. After an encryption resume, all 8 octets of the IV are
from the EN_RAND sent by the device initiating the encryption pause (see [Vol 2]
Part C, Section 4.2.5.5). An encryption pause and resume will be required prior to the
PayloadCounter or dayCounter rolling over in order to keep the nonce fresh for an
encryption key.

Octet IV for Encryption Start IV After Resume Encryption

0 ACO[0] EN_RAND[0]
1 ACO[1] EN_RAND[1]
2 ACO[2] EN_RAND[2]
3 ACO[3] EN_RAND[3]
4 ACO[4] EN_RAND[4]
5 ACO[5] EN_RAND[5]
6 ACO[6] EN_RAND[6]
7 ACO[7] EN_RAND[7]

Table 9.2: IV construction

9.2 Counter mode blocks

For calculating the MIC, the payload is broken into two or more counter mode blocks.
The CCM specification refers to these blocks as blocks B0 – Bn. B0 applies to the
nonce, B1 applies to the associated data {that is packet header and payload header}
and additional B blocks are generated as needed for authentication of the payload body.

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 2, Part H Page 1071
Security Specification

Offset Field Size Value Description

(octets) (octets)
0 Flags 1 0x49 As per the CCM specification
1 Nonce 13 variable The nonce as described in Section 9.1.
Nonce0 shall have offset 1.
Nonce12 shall have offset 13.
14 Length[MSO] 1 variable The most significant octet of the length of the payload
body
15 Length[LSO] 1 variable The least significant octet of the length of the payload
body

Table 9.3: B0 counter mode block format

Offset Field Size Value Description

(octets)
0 Packet_Header 1 Variable The most significant octet of the packet head-
er:
[MSO]
Bit 0: 0 (ARQN masked)
Bit 1: 0 (SEQN masked)
Bit 7 – Bit 2: 0b000000
1 Packet_Header 1 Variable The least significant octet of the packet head-
er:
[LSO]
Bit 2 – Bit 0: LT_ADDR
Bit 6 – Bit 3: TYPE
Bit 7: 0 (FLOW masked)
2 Payload_Head- 1 Variable The payload header:
er Bit 1 – Bit 0: LLID
Bit 2: 0 (FLOW masked)
Bit 7 – Bit 3: 0b00000
3 Padding 13 0x00, 0x00, These octets are only used to pad the block.
0x00, 0x00, They are not part of the packet and never
0x00, 0x00, transmitted.
0x00, 0x00,
0x00, 0x00,
0x00, 0x00,
0x00

Table 9.4: B1 counter mode block format

9.3 Encryption blocks

The CCM algorithm uses the Ai blocks to generate a keystream that is used to encrypt
the MIC and payload body. Block A0 is always used to encrypt and decrypt the MIC,

Bluetooth SIG Proprietary Version Date: 2024-08-27

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 2, Part H Page 1072
Security Specification

when present. Block A1 is always used to encrypt and decrypt the first 16 octets of the
payload body. Subsequent blocks are always used to encrypt and decrypt the rest of the
payload body as needed.

Offset Field Size Value Description

(octets) (octets)
0 Flags 1 0x01 As per the CCM specification
1 Nonce 13 variable The nonce as described in Section 9.1.
Nonce0 shall have offset 1.
Nonce12 shall have offset 13.
14 i[MSO] 1 variable The most significant octet of the counter i
15 i[LSO] 1 variable The least significant octet of the counter i

Table 9.5: Encryption mode block format

9.4 Encryption key size reduction

When the devices have negotiated a key size shorter than the maximum length, the key
will be shortened by replacing the appropriate number of least significant octets of the
key with 0x00.

For example, if a 128-bit encryption key is

0x12345678_9ABCDEF0_12345678_9ABCDEF0

and it is reduced to 7 octets (56 bits), then the resulting key is

0x12345678_9ABCDE00_00000000_00000000.

9.5 Repeated MIC failures

Anytime the MIC check fails and the CRC passes on a given packet, it is considered
an authentication failure. No more than three authentication failures shall be permitted
during the lifetime of an encryption key with a given IV. The third authentication failure
shall initiate an encryption key refresh (see [Vol 2] Part C, Section 4.2.5.8). If a fourth
authentication failure occurs prior to the encryption key refresh procedure completing,
the link shall be disconnected with reason code Connection Rejected Due to Security
Reasons (0x0E).

Note: The MIC is not checked when the CRC is invalid.

Bluetooth SIG Proprietary Version Date: 2024-08-27