Main Content

Bluetooth Packet Structure

The Bluetooth® Special Interest Group (SIG) [1] and [2] defines different packet structures for Bluetooth low energy (BLE) and Bluetooth basic rate/enhanced data rate (BR/EDR) devices.

BLE Packet Structure

Bit Ordering in BLE Packets

When defining packets and messages in the baseband specification, the bit ordering follows the little-endian format. In this format, these rules apply:

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

  • LSB is the first bit sent over the air.

  • When illustrating the packet structure, the LSB is shown on the left side.

Moreover, data fields generated internally at the baseband level (packet header and payload header length), must be transmitted with the LSB first. For example, a 3-bit parameter is sent as: b0b1b2 = 110 over the air, where 1 is sent first and 0 is sent last.

The BLE devices use packet formats for: BLE Uncoded Physical Layer (PHY), BLE Coded PHY, Advertising Physical Channel PDU, Data Physical Channel PDU, and Constant Tone Extension and In-Phase Quadrature (IQ) Sampling.

Note

For more information about BLE packet structure, see volume 6, Part B, Section 2 of the Bluetooth Core Specification [2].

BLE Uncoded Physical Layer (PHY)

The Bluetooth Core Specification [2] defines two physical layer (PHY) transmission modes (LE 1M and LE 2M) for uncoded PHY. This figure shows the packet structure for the BLE uncoded PHY operating on LE 1M and LE 2M.

Each packet contains four mandatory fields (preamble, access-address, protocol data unit (PDU), and cyclic redundancy check (CRC)) and one optional field (constant tone extension (CTE)). The preamble is transmitted first, followed by the access address, PDU, CRC, and CTE (if present) in that order. The entire packet is transmitted at the same symbol rate of 1 Msym/s or 2 Msym/s.

Preamble.  All link layer (LL) packets contain a preamble, which is used in the receiver to perform frequency synchronization, automatic gain control (AGC) training, and symbol timing estimation. The preamble is a fixed sequence of alternating 0 and 1 bits. For the BLE packets transmitted on the LE 1M PHY and LE 2M PHY, the preamble size is 1 octet and 2 octets, respectively.

Access address.  The access address is a 4-octet value. Each LL connection between any two devices and each periodic advertising train has a distinct access address. Each time the BLE device needs a new access address, the LL generates a new random value adhering to these requirements:

  • The value must not be the access address for any existing LL connection on this device.

  • The value must not be the access address for any enabled periodic advertising train.

  • The value must have no more than six successive 1s or 0s.

  • The value must not be the access address for any advertising channel packets.

  • The value must not be a sequence that differs from the access address of advertising physical channel packets by only 1 bit.

  • All four octets for the value must not be equal.

  • The value must have a minimum of two transitions in the most significant 6 bits.

If the random value does not satisfy the above requirements, a new random value is generated until it meets all of the requirements.

PDU.  When a BLE packet is transmitted on either the primary or secondary advertising physical channel or the periodic physical channel, the PDU is defined as the Advertising Physical Channel PDU. When a packet is transmitted on the data physical channel, the PDU is defined as the Data Physical Channel PDU.

CRC.  The size of the CRC is 3 octets and is calculated on the PDU of all LL packets. If the PDU is encrypted, then the CRC is calculated after encryption of the PDU is complete. The CRC polynomial has the form x24+x10+x9+x6+x4+x3+x+1.

For more information about CRC generation, see volume 6, Part B, Section 3.1.1 of the Bluetooth Core Specification [2].

CTE.  The CTE consists of a constantly modulated series of unwhitened 1s. This field has a variable length that ranges from 16 µs to 160 µs.

For more information about the CTE, see volume 6, Part B, Section 2.5.1 of the Bluetooth Core Specification [2].

Note

For more information about BLE uncoded PHY packet structure, refer to Vol 6, Part B, Section 2.1 of Bluetooth Core Specification [2].

BLE Coded PHY

This figure shows the packet structure for the BLE coded PHY and is implemented for BLE packets on all the physical channels.

Each BLE packet consists of a preamble and these two forward error correcting (FEC) blocks:

  • FEC block 1— This block contains three fields: access address, coding indicator (CI), and TERM1. This block implements an S=8 coding scheme, where each bit represents eight symbols. This gives a data rate of 125 Kbps.

  • FEC block 2— This block contains these three fields: PDU, CRC, and TERM2. This block implements an S=8 or S=2 coding scheme. In the S=2 coding scheme, each bit represents two symbols. Therefore, the data rate is 500 Kbps.

The BLE coded PHY does not contain the CTE.

Preamble.  The BLE coded PHY preamble is 80 symbols in length and contains 10 repetitions of the symbol pattern '00111100' (in the transmission order).

Access address.  The length of BLE coded PHY access address is 256 symbols. For more information, see Access address. In addition to the requirements listed in the access address subsection of the BLE Uncoded Physical Layer (PHY) section, the new value for the access address of the BLE coded PHY must also meet these requirements:

  • The value must have at least three 1s in the last significant bits.

  • The value must have no more than 11 transitions in the least significant 16 bits.

CI.  The CI field consists of two bits as shown in this table:

Bits in CIDescription
00b

FEC block 2 coded using S=8

01b

FEC block 2 coded using S=2

All other values

Reserved for future use

PDU.  The PDU in the BLE coded PHY packet structure has the same formatting as the PDU in the BLE uncoded PHY packet.

CRC.  The CRC in the BLE coded PHY packet structure has the same formatting as the CRC in the BLE uncoded PHY packet.

TERM1 and TERM2.  Each FEC block contains a terminator at the end of the block. That terminator is referred to as TERM1 and TERM2. Each terminator is 3 bits long and forms the termination sequence during the FEC encoding process.

Note

For more information about BLE coded PHY packet structure, see volume 6, Part B, Section 2.2 of the Bluetooth Core Specification [2].

Advertising Physical Channel PDU

The packet structure format of the advertising physical channel PDU is shown in this figure.

The advertising physical channel PDU has a 16-bit header and a variable-size payload. The 16-bit header field of the advertising physical channel PDU is shown in this figure.

The PDU type field in the advertising channel PDU header defines different types of PDUs that can be transmitted on the BLE coded PHY. This table maps different types of PDUs with the physical channels and the PHYs on which the BLE packet might appear. The table also indicates the PHY transmission modes supported for each type of advertising physical channel PDU.

PDU TypePDU NamePhysical ChannelLE 1M SupportLE 2M SupportLE Coded Support
0000b

ADV_IND

Primary Advertising

Yes

  
0001b

ADV_DIRECT_IND

Primary Advertising

Yes  
0010b

ADV_NONCONN_IND

Primary Advertising

Yes

  
0011b

SCAN_REQ

Primary Advertising

Yes

  

AUX_SCAN_REQ

Secondary Advertising

Yes

Yes

Yes

0100b

SCAN_RSP

Primary Advertising

Yes

  
0101b

CONNECT_IND

Primary Advertising

Yes

  

AUX_CONNECT_REQ

Secondary Advertising

Yes

Yes

Yes

0110b

ADV_SCAN_IND

Primary Advertising

Yes

  
0111b

ADV_EXT_IND

Primary Advertising

Yes

 

Yes

AUX_ADV_IND

Secondary Advertising

Yes

Yes

Yes

AUX_SCAN_RSP

Secondary Advertising

Yes

Yes

Yes

AUX_SYNC_IND

Periodic

Yes

Yes

Yes

AUX_CHAIN_IND

Secondary Advertising and Periodic

Yes

Yes

Yes

1000b

AUX_CONNECT_RSP

Secondary Advertising

Yes

Yes

Yes

All other values

Reserved for future use

The RFU field is reserved for future use. The ChSel, TxAdd, and RxAdd fields of the advertising physical channel PDU header contain information specific to the type of PDU defined for each advertising physical channel PDU separately. If the ChSel, TxAdd, or RxAdd fields are not defined as used in a given PDU, then they are considered as reserved for future use.

The Length field of the advertising physical channel PDU header denotes the length of the payload in octets. The valid range of the Length field is 1 to 255 octets.

The Payload field in the advertising physical channel PDU packet structure is specific to the type of PDUs listed in the preceding table.

Note

For more information about advertising physical channel PDUs, see volume 6, Part B, Section 2.3 of the Bluetooth Core Specification [2].

Data Physical Channel PDU

The packet structure format of the data physical channel PDU is shown in this figure.

The data physical channel PDU has a 16-bit or 24-bit header, a variable length payload in the range [0, 251] octets, and can include a 32-bit message integrity check (MIC) field. The MIC is not included in an unencrypted LL connection or in an encrypted LL connection with a data channel PDU containing an empty payload. The MIC is included in an encrypted LL connection with a data channel PDU containing a nonzero length payload. In this case, the MIC is calculated as specified in volume 6, Part E, Section 1 of the Bluetooth Core Specification [2].

The header field of the data physical channel PDU is shown in this figure.

The data physical channel PDU header includes these fields:

  • Link layer identifier (LLID) — This field indicates whether the packet is an LL data PDU or LL control PDU.

    • 00b — Reserved for future use

    • 01b — LL Data PDU, which can be a continuation fragment of an logical link control and adaptation (L2CAP) message or an empty PDU

    • 10b — LL Data PDU, which can be a start of an L2CAP message or a complete L2CAP message with no fragmentation

    • 11b — LL control PDU

  • Next expected sequence number (NESN): The LL uses this field to either acknowledge the last data physical channel PDU sent by the peer or to request the peer to resend the last data physical channel PDU. For more information about NESN, see volume 6, Part B, Section 4.5.9 of the Bluetooth Core Specification [2].

  • Sequence number (SN): The LL uses this field to identify the BLE packets sent by it. For more information about the SN, see volume 6, Part B, Section 4.5.9 of the Bluetooth Core Specification [2].

  • More data (MD): This field indicates that the BLE device has more data to send. If neither of master and slave BLE device has set the MD bit in their packets, the packet from the slave closes the connection event. If the master and slave devices have set the MD bit, the master can continue the connection event by sending another packet, and the slave must listen after sending its packet. For more information about MD, see volume 6, Part B, Section 4.5.6 of the Bluetooth Core Specification [2].

  • CTEInfo present (CP): This field indicates whether the data physical channel PDU header has a CTEInfo field and, subsequently whether the data physical channel packet has a CTE. For more information about the packet structure of the CTEInfo field, see volume 6, Part B, Section 2.5.2 of the Bluetooth Core Specification [2].

  • Length: This field indicates the size, in octets, of the payload and MIC, if present. The size of this field is in the range [0, 255] octets.

  • CTEInfo: This field indicates the type and length of the CTE.

The two types of data physical channel PDUs are: LL Data PDU and LL Control PDU.

LL Data PDU.  The LL uses the LL data PDU to send L2CAP data. The LLID field in the LL data channel PDU header is set to either 01b or 10b. An LL data PDU is referred to as an empty PDU if

  • The LLID field of the LL data channel PDU header is set to 01b.

  • The Length field of the LL data channel PDU header is set to 00000000b.

An LL data PDU with the LLID field in the header set to 10b does not have the Length field set to 00000000b.

LL Control PDU.  The LL uses the LL data PDU to control the LL connection. If the LLID field of data physical channel PDU header is set to 11b, the data physical channel PDU contains an LL control PDU. This figure shows the LL control PDU payload.

The Opcode field defines different types of LL control PDUs as shown in this table.

OpcodeLL Control PDU
0x00

LL_CONNECTION_UPDATE_IND

0x01

LL_CHANNEL_MAP_IND

0x02

LL_TERMINATE_IND

0x03

LL_ENC_REQ

0x04

LL_ENC_RSP

0x05

LL_START_ENC_REQ

0x06

LL_START_ENC_RSP

0x07

LL_UNKNOWN_RSP

0x08

LL_FEATURE_REQ

0x09

LL_FEATURE_RSP

0x0A

LL_PAUSE_ENC_REQ

0x0B

LL_PAUSE_ENC_RSP

0x0C

LL_VERSION_IND

0x0D

LL_REJECT_IND

0x0E

LL_SLAVE_FEATURE_REQ

0x0F

LL_CONNECTION_PARAM_REQ

0x10

LL_CONNECTION_PARAM_RSP

0x11

LL_REJECT_EXT_IND

0x12

LL_PING_REQ

0x13

LL_PING_RSP

0x14

LL_LENGTH_REQ

0x15

LL_LENGTH_RSP

0x16

LL_PHY_REQ

0x17

LL_PHY_RSP

0x18

LL_PHY_UPDATE_IND

0x19

LL_MIN_USED_CHANNELS_IND

0x1A

LL_CTE_REQ

0x1B

LL_CTE_RSP

0x1C

LL_PERIODIC_SYNC_IND

0x1D

LL_CLOCK_ACCURACY_REQ

0x1E

LL_CLOCK_ACCURACY_RSP

All other values

Reserved for future use

The CtrData field in the LL control PDU is specific to the value of the Opcode field. For more information about different LL control PDUs and their corresponding CtrData field structure, see volume 6, Part B, Sections 2.4.2.1 to 2.4.2.28 of the Bluetooth Core Specification [2].

Constant Tone Extension and In-Phase Quadrature (IQ) Sampling

The length of the CTE is variable and in the range [16, 160] µs. This field contains a constantly modulated series of 1s with no whitening applied. The CTE is of two types: antenna switching during CTE transmission (AoD) and antenna switching during CTE reception (AoA). When receiving a packet containing an AoD CTE, the receiver does not need to switch antennae. When receiving a packet containing an AoA CTE, the receiver performs antenna switching at the rate and according to the switching pattern configured by the host. In both cases, the receiver takes an IQ sample at each microsecond during the reference period and an IQ sample each sample slot. The controller reports the IQ samples to the host. The receiver samples the entire CTE regardless of its length, unless this conflicts with other activities. For more information about CTE, see volume 6, Part B, Sections 2.5.1 to 2.5.3 of the Bluetooth Core Specification [2].

When requested by the host, the receiver performs IQ sampling when receiving a valid BLE packet with a CTE. However, when receiving a BLE packet with a CTE and an incorrect CRC, the receiver might perform IQ sampling. For more information about IQ sampling, see volume 6, Part B, Section 2.5.4 of the Bluetooth Core Specification [2].

Note

For more information about data physical channel PDUs, see volume 6, Part B, Section 2.4 of the Bluetooth Core Specification [2].

Bluetooth BR/EDR Packet Structure

Bit Ordering in Bluetooth BR/EDR Packets

The bit ordering in Bluetooth BR/EDR packets follows the same format as the Bit Ordering in BLE Packets.

Bluetooth BR/EDR devices use packet formats for: BR Mode, EDR Mode, Access Code, Packet Header, Packet Types, and Payload Format.

Note

For more information about Bluetooth BR/EDR packet structure, see volume 2, Part B, Section 6 of the Bluetooth Core Specification [2].

General Format

BR Mode.  The general format of Bluetooth BR packets is shown in this figure. Each packet consists of these fields: the access code (68 or 72 bits), header (54 bits), and payload in the range [0, 2790] bits.

The Bluetooth Core Specification [2] defines different types of packets. A packet can consist of:

  • The shortened access code only

  • The access code and the packet header

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

EDR Mode.  The general format of Bluetooth EDR packets is shown in this figure.

The format and modulation of the access code and the packet header fields are similar to that of BR packets. Following the header field, the EDR packets have a guard time in the range [4.75, 5.25] µs, a sync sequence (11 µs), payload in the range [0, 2790] bits, and trailer (two symbols) fields.

Access Code

Each packet starts with an access code. If a packet header follows, the access code is 72 bits long. Otherwise, the length of the access code is 68 bits. In this case, the access code is referred to as a shortened access code. The shortened access code does not contain a trailer. The access code is used for synchronization, DC offset compensation, and identification of all packets exchanged on the physical channel. 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. This figure shows the packet structure of the access code.

Different access code types use different lower address parts (LAPs) to construct the sync word. A summary of different access code types is shown in this table.

Access Code TypeLAPAccess Code Length (Bits)Description
Channel access code (CAC)Master72

This access code is used in the connection state, synchronization train substate, and synchronization scan substate. It is derived from the LAP of the Master's BD_ADDR .

Device access code (DAC)Paged device68 or 72

This access code is used during page, page scan, and page response substates. It is derived from the paged devices's BD_ADDR.

Dedicated inquiry access code (DIAC)Dedicated68 or 72

This access code is used in the inquiry substate for dedicated inquiry operations.

General inquiry access code (GIAC)Reserved68 or 72

This access code is used in the inquiry substate for general inquiry operations.

For DAC, DIAC, and GIAC access code types, the access code length of 72 bits is used only in combination with frequency hopping sequence (FHS) packets. When used as self-contained messages without a header, the DAC, DIAC and GIAC do not include trailer bits and are of length 68 bits.

The CAC consists of a preamble, sync word, and trailer.

  • Preamble: It is a fixed 4-symbol pattern of 1s and 0s that facilitates DC compensation. If the LSB of the following sync word is 1 or 0, the preamble sequence is 1010 or 0101 (in transmission order), respectively.

  • Sync word: It is a 64-bit code word derived from a 24-bit LAP address. The construction guarantees a large Hamming distance between sync words based on different LAPs. The autocorrelation properties of the sync word improve timing acquisition.

  • Trailer: It is appended to the sync word as soon as the packet header follows the access code. The trailer is a fixed 4-symbol pattern of 1s and 0s. The trailer together with the three MSBs of the sync word form a 7-bit pattern of alternating 1s and 0s which is 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.

Note

For more information about access code in Bluetooth BR/EDR, see volume 2, Part B, Section 6.3 of the Bluetooth Core Specification [2].

Packet Header

The structure of the Bluetooth BR/EDR packet header is shown in this figure.

This table provides a brief description about the packet header fields.

Packet Header FieldSize of the Field (Bits)Description
Logical transport address (LT_ADDR)3

This field indicates the destination slave(s) for a packet in a master-to-slave transmission slot and indicates the source slave for a slave-to-master transmission slot.

Type4

This field specifies the type of packet used. The Bluetooth Core Specification [2] defines 16 different types of BR/EDR packets. The value in this field depends on the value of LT_ADDR field in the packet. This field determines the number of slots occupied by the current packet.

Flow control (FLOW)1

This field implements the flow control of BR/EDR packets over the asynchronous connection-oriented logical (ACL) transport. When the receive buffer for the ACL logical transport is full, a 'STOP' indication (FLOW = 0) is returned to stop the other device from transmitting data temporarily. When the receive buffer can accept data, a 'GO' indication (FLOW = 1) is returned.

Automatic repeat request number (ARQN)1

This field informs the source of a successful transfer of payload data with the CRC. This field is reserved for future use on the connectionless slave broadcast (CSB) logical transport.

Sequence number (SEQN)1

This field provides a sequential numbering scheme to order the data packet stream. This field is reserved for future use on the CSB logical transport.

Header error check (HEC)8

This field checks the packet header integrity. Before generating the HEC, the HEC generator is initialized with an 8-bit value. These 8 bits correspond to the upper address part (UAP). After the initialization, the HEC generator calculates the HEC value for the 10 header bits. Before checking the HEC, the receiver initializes the HEC check circuitry with the appropriate 8-bit UAP. If the HEC does not check the packet header integrity, the entire packet is discarded.

Note

For more information about packet header used in Bluetooth BR/EDR, see volume 2, Part B, Section 6.4 of the Bluetooth Core Specification [2].

Packet Types

The packets used in the piconet are related to these logical transports on which they are used.

  • Synchronous connection-oriented (SCO): It is a circuit-switched connection that reserved slots between the master and a specific slave.

  • Extended SCO (eSCO): Similar to SCO, it reserves slots between the master and a specific slave. eSCO supports a retransmission window following the reserved slots. Together, the reserved slots and the retransmission window form the complete eSCO window.

  • ACL: It provides a packet-switched connection between the master and all active slaves participating in the piconet. ACL supports asynchronous and isochronous services. Between a master and a slave, only a single ACL logical transport must exist.

  • CSB: It is used to transport profile broadcast data from a master to multiple slaves. A CSB logical transport is unreliable.

This table summarizes the packets defined for the SCO, eSCO, ACL, and CSB logical transport types.

Note

The column entries followed by "D" means data field only. "C.1" implies that the MIC value is mandatory when encryption with AES-CCM is enabled. Otherwise, MIC is excluded. For more information about different packet types used in Bluetooth BR/EDR, see volume 2, Part B, Sections 6.5 and 6.7 of the Bluetooth Core Specification [2].

Packet TypeTYPE Code Slot OccupancyPayload Header (Bytes)User Payload (Bytes)FECMICCRCLogical Transport Types Supported
IDN/A1N/AN/AN/AN/AN/AN/A
NULL00001N/AN/AN/AN/AN/ASCO, eSCO, ACL, CSB
POLL00011N/AN/AN/AN/AN/ASCO, eSCO, ACL
FHS00101N/A182/3N/AYesSCO, ACL
DM10011110-172/3C.1YesSCO, ACL, CSB
DH10100110-27NoC.1YesACL, CSB
DM31010320-1212/3C.1YesACL, CSB
DH31011320-183NoC.1YesACL, CSB
DM51110520-2242/3C.1YesACL, CSB
DH51111520-339NoC.1YesACL, CSB
2-DH10100120-54NoC.1YesACL, CSB
2-DH31010320-367NoC.1YesACL, CSB
2-DH51110520-679NoC.1YesACL, CSB
3-DH11000120-83NoC.1YesACL, CSB
3-DH31011320-552NoC.1YesACL, CSB
3-DH51111520-1021NoC.1YesACL, CSB
HV101011N/A101/3NoNoSCO
HV201101N/A202/3NoNoSCO
HV301111N/A30NoNoNoSCO
DV100011 D10+(0-9) D2/3 DNoYes DSCO
EV301111N/A1-30NoNoYeseSCO
EV411003N/A1-1202/3NoYeseSCO
EV511013N/A1-180NoNoYeseSCO
2-EV301101N/A1-60NoNoYeseSCO
2-EV511003N/A1-360NoNoYeseSCO
3-EV301111N/A1-90NoNoYeseSCO
3-EV511013N/A1-540NoNoYeseSCO

Payload Format

The Buetooth Core Specification [2] defines two types of payload field formats: synchronous data field (for ACL packets) and asynchronous data field (for SCO and eSCO packets). However, the DV packets contain both the synchronous and asynchronous data fields.

  • Synchronous data field: In SCO, which supports only the BR mode, the length of the synchronous data field is fixed. The synchronous data field contains only the synchronous data body portion and does not have a payload header. In BR eSCO, the synchronous data field consists of these two segments: a synchronous data body and a CRC code. In this case, no payload header is present. In EDR eSCO, the synchronous data field consists of a guard time, synchronization sequence, synchronous data body, CRC code, and trailer. In this case, no payload header is present.

  • Asynchronous data field: The BR ACL packets have an asynchronous data field consisting of payload header, payload body, MIC (if applicable), and CRC (if applicable). This figure shows the 8-bit payload header format for BR single-slot ACL packets.

    EDR ACL packets have an asynchronous data field consisting of guard time, synchronization sequence, payload header, payload body, MIC (if applicable), CRC (if applicable), and trailer. This figure shows the 16-bit payload header format for EDR multislot ACL packets.

    Note

    For more information about the payload format, see volume 2, Part B, Sections 6.6.1 and 6.6.2 of the Bluetooth Core Specification [2].

References

[1] Bluetooth Technology Website. “Bluetooth Technology Website | The Official Website of Bluetooth Technology.” Accessed November 22, 2019. https://www.bluetooth.com/.

[2] Bluetooth Special Interest Group (SIG). "Bluetooth Core Specification." Version 5.1. https://www.bluetooth.com/.

Related Topics