Bluetooth Packet Structure

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

Bluetooth LE Packet Structure

Bit Ordering in Bluetooth LE 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 b₀.

• 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 Bluetooth LE devices use packet formats for: Bluetooth LE Uncoded Physical Layer (PHY), Bluetooth LE 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 Bluetooth LE packet structure, see Volume 6, Part B, Section 2 of the Bluetooth Core Specification [2].

Bluetooth LE 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 Bluetooth LE 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 Bluetooth LE 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 Bluetooth LE 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 Bluetooth LE 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 x²⁴+x¹⁰+x⁹+x⁶+x⁴+x³+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 Bluetooth LE uncoded PHY packet structure, refer to Volume 6, Part B, Section 2.1 of Bluetooth Core Specification [2].

Bluetooth LE Coded PHY

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

Each Bluetooth LE 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 Bluetooth LE coded PHY does not contain the CTE.

Preamble.  The Bluetooth LE 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 Bluetooth LE 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 Bluetooth LE Uncoded Physical Layer (PHY) section, the new value for the access address of the Bluetooth LE 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
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 Bluetooth LE coded PHY packet structure has the same formatting as the PDU in the Bluetooth LE uncoded PHY packet.

CRC.  The CRC in the Bluetooth LE coded PHY packet structure has the same formatting as the CRC in the Bluetooth LE 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 Bluetooth LE 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 Bluetooth LE coded PHY. This table maps different types of PDUs with the physical channels and the PHYs on which the Bluetooth LE 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
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 Bluetooth LE 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 Bluetooth LE device has more data to send. If neither of Central and Peripheral Bluetooth LE device has set the MD bit in their packets, the packet from the Peripheral closes the connection event. If the Central and Peripheral devices have set the MD bit, the Central can continue the connection event by sending another packet, and the Peripheral 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.

Opcode	LL 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 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 Bluetooth LE packet with a CTE. However, when receiving a Bluetooth LE 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 Bluetooth LE 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 Type	LAP	Access Code Length (Bits)	Description
Channel access code (CAC)	Central	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 Central's BD_ADDR.
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 device’s BD_ADDR.
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 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 Field	Size of the Field (Bits)	Description
Logical transport address (LT_ADDR)	3	This field indicates the destination Peripheral(s) for a packet in a Central-to-Peripheral transmission slot and indicates the source Peripheral for a Peripheral-to-Central transmission slot.
Type	4	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 Peripheral 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 Central and a specific Peripheral.

• Extended SCO (eSCO): Similar to SCO, it reserves slots between the Central and a specific Peripheral. 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 Central and all active Peripherals participating in the piconet. ACL supports asynchronous and isochronous services. Between a Central and a Peripheral, only a single ACL logical transport must exist.

• CSB: It is used to transport profile broadcast data from a Central to multiple Peripherals. 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 Type	TYPE Code	Slot Occupancy	Payload Header (Bytes)	User Payload (Bytes)	FEC	MIC	CRC	Logical Transport Types Supported
ID	N/A	1	N/A	N/A	N/A	N/A	N/A	N/A
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
FHS	0010	1	N/A	18	2/3	N/A	Yes	SCO, ACL
DM1	0011	1	1	0-17	2/3	C.1	Yes	SCO, ACL, CSB
DH1	0100	1	1	0-27	No	C.1	Yes	ACL, CSB
DM3	1010	3	2	0-121	2/3	C.1	Yes	ACL, CSB
DH3	1011	3	2	0-183	No	C.1	Yes	ACL, CSB
DM5	1110	5	2	0-224	2/3	C.1	Yes	ACL, CSB
DH5	1111	5	2	0-339	No	C.1	Yes	ACL, CSB
2-DH1	0100	1	2	0-54	No	C.1	Yes	ACL, CSB
2-DH3	1010	3	2	0-367	No	C.1	Yes	ACL, CSB
2-DH5	1110	5	2	0-679	No	C.1	Yes	ACL, CSB
3-DH1	1000	1	2	0-83	No	C.1	Yes	ACL, CSB
3-DH3	1011	3	2	0-552	No	C.1	Yes	ACL, CSB
3-DH5	1111	5	2	0-1021	No	C.1	Yes	ACL, CSB
HV1	0101	1	N/A	10	1/3	No	No	SCO
HV2	0110	1	N/A	20	2/3	No	No	SCO
HV3	0111	1	N/A	30	No	No	No	SCO
DV	1000	1	1 D	10+(0-9) D	2/3 D	No	Yes D	SCO
EV3	0111	1	N/A	1-30	No	No	Yes	eSCO
EV4	1100	3	N/A	1-120	2/3	No	Yes	eSCO
EV5	1101	3	N/A	1-180	No	No	Yes	eSCO
2-EV3	0110	1	N/A	1-60	No	No	Yes	eSCO
2-EV5	1100	3	N/A	1-360	No	No	Yes	eSCO
3-EV3	0111	1	N/A	1-90	No	No	Yes	eSCO
3-EV5	1101	3	N/A	1-540	No	No	Yes	eSCO

Payload Format

The Bluetooth 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, 2021. https://www.bluetooth.com/.

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

Related Topics

• Bluetooth Technology Overview
• Bluetooth Protocol Stack
• Comparison of Bluetooth BR/EDR and Bluetooth LE Specifications