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:
= 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.
For more information about BLE packet structure, see volume 6, Part B, Section 2 of the Bluetooth Core Specification .
The Bluetooth Core Specification  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 .
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 .
For more information about BLE uncoded PHY packet structure, refer to Vol 6, Part B, Section 2.1 of Bluetooth Core Specification .
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 CI||Description|
FEC block 2 coded using S=8
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.
For more information about BLE coded PHY packet structure, see volume 6, Part B, Section 2.2 of the Bluetooth Core Specification .
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 Type||PDU Name||Physical Channel||LE 1M Support||LE 2M Support||LE Coded Support|
Secondary Advertising and Periodic
|All other values|
Reserved for future use
The RFU field is reserved for future use. The
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
RxAdd fields are not defined as used in
a given PDU, then they are considered as reserved for future use.
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
Payload field in the advertising physical channel PDU packet
structure is specific to the type of PDUs listed in the preceding table.
For more information about advertising physical channel PDUs, see volume 6, Part B, Section 2.3 of the Bluetooth Core Specification .
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 .
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 .
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 .
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 .
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 .
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.
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
LL data PDU is referred to as an empty PDU if
The LLID field of the LL data channel PDU header is set to
The Length field of the LL data channel PDU header is set to
An LL data PDU with the LLID field in the header set to
not have the Length field set to
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.
|Opcode||LL Control PDU|
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 126.96.36.199 to 188.8.131.52 of the Bluetooth Core Specification .
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 .
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 .
For more information about data physical channel PDUs, see volume 6, Part B, Section 2.4 of the Bluetooth Core Specification .
The bit ordering in Bluetooth BR/EDR packets follows the same format as the Bit Ordering in BLE Packets.
For more information about Bluetooth BR/EDR packet structure, see volume 2, Part B, Section 6 of the Bluetooth Core Specification .
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  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.
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 Type||LAP||Access Code Length (Bits)||Description|
|Channel access code (CAC)||Master||72|
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
|Device access code (DAC)||Paged device||68 or 72|
This access code is used during page, page scan, and page response
substates. It is derived from the paged devices's
|Dedicated inquiry access code (DIAC)||Dedicated||68 or 72|
This access code is used in the inquiry substate for dedicated inquiry operations.
|General inquiry access code (GIAC)||Reserved||68 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
0, the preamble sequence is
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
0101 (in transmission order)
depending on whether the MSB of the sync word is
For more information about access code in Bluetooth BR/EDR, see volume 2, Part B, Section 6.3 of the Bluetooth Core Specification .
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 Field||Size 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.
This field specifies the type of packet used. The Bluetooth Core Specification  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.
For more information about packet header used in Bluetooth BR/EDR, see volume 2, Part B, Section 6.4 of the Bluetooth Core Specification .
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.
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 .
|Packet Type||TYPE Code||Slot Occupancy||Payload Header (Bytes)||User Payload (Bytes)||FEC||MIC||CRC||Logical Transport Types Supported|
|NULL||0000||1||N/A||N/A||N/A||N/A||N/A||SCO, eSCO, ACL, CSB|
|POLL||0001||1||N/A||N/A||N/A||N/A||N/A||SCO, eSCO, ACL|
|DM1||0011||1||1||0-17||2/3||C.1||Yes||SCO, ACL, CSB|
|DV||1000||1||1 D||10+(0-9) D||2/3 D||No||Yes D||SCO|
The Buetooth Core Specification  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.
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 .
 Bluetooth Technology Website. “Bluetooth Technology Website | The Official Website of Bluetooth Technology.” Accessed November 22, 2019. https://www.bluetooth.com/.
 Bluetooth Special Interest Group (SIG). "Bluetooth Core Specification." Version 5.1. https://www.bluetooth.com/.