Part B. Link Layer Specification
vAtlanta r00
This Part describes the Bluetooth Low Energy Link Layer.
1. General description
1.1. Link Layer states
The operation of the Link Layer can be described in terms of a state machine with the following states:
Standby State
Advertising State
Scanning State
Initiating State
Connection State
Synchronization State
Isochronous Broadcasting State
The Link Layer state machine allows only one state to be active at a time. The Link Layer shall have at least one Link Layer state machine that supports one of Advertising state or Scanning state. The Link Layer may have multiple instances of the Link Layer state machine.
The Link Layer in the Standby state does not transmit or receive any packets. The Standby state can be entered from any other state.
The Link Layer in the Advertising state will be transmitting advertising physical channel packets and possibly listening to and responding to responses triggered by these advertising physical channel packets. A device in the Advertising state is known as an advertiser. The Advertising state can be entered from the Standby state.
The Link Layer in the Scanning state will be listening for advertising physical channel packets from devices that are advertising. A device in the Scanning state is known as a scanner. The Scanning state can be entered from the Standby state.
The Link Layer in the Initiating state will be listening for advertising physical channel packets from a specific device(s) and responding to these packets to initiate a connection with another device. A device in the Initiating state is known as an initiator. The Initiating state can be entered from the Standby state.
The Connection state can be entered either from the Initiating state or the Advertising state. A device in the Connection state is known as being in a connection.
Within the Connection state, two roles are defined:
Central Role
Peripheral Role
When entered from the Initiating state, the Connection state shall be in the Central Role. When entered from the Advertising state, the Connection state shall be in the Peripheral Role.
The Link Layer in the Central Role will communicate with a device in the Peripheral Role and defines the timings of transmissions.
The Link Layer in the Peripheral Role will communicate with a single device in the Central Role.
The Link Layer in the Synchronization State will be listening for periodic physical channel packets forming a specific periodic advertising train, coming from a specified device that is transmitting periodic advertising. The Synchronization State can be entered from the Standby State. While in this State, the Host may direct the Link Layer to listen for isochronous data packets coming from a specified device that is transmitting a Broadcast Isochronous Group (BIG). A device that is in the Synchronization State and is receiving isochronous data packets is referred as a Synchronized Receiver.
The Link Layer in the Isochronous Broadcasting State will transmit isochronous data packets on an isochronous physical channel. The Isochronous Broadcasting State can be entered from the Standby State. A device that is in the Isochronous Broadcasting State is referred as an Isochronous Broadcaster.
1.1.1. Permitted state and role combinations
The Link Layer may optionally support multiple state machines. If it does support multiple state machines, then any combination of states and roles may be supported. In particular, subject to the requirements in Section 4.5, the Link Layer may be in the Connection State multiple times with any mix of Central Role and Peripheral Role.
Note: A device supporting scanning for periodic advertising (see Section 4.4.3.4) must support at least two state machines.
A Link Layer implementation is not required to support all the possible state combinations that are allowed by the specification. However, if it supports a state or state combination given in the "combination A" column of Table 1.1, it shall also support the corresponding state or state combination in the "combination B" column.
Combination A | Combination B |
|---|---|
Initiating plus any combination C of other states | Connection (Central role) plus the same combination C |
Connection (Central role) plus Initiating plus any combination C of other states | Connection (Central role) to more than one device in the Peripheral role plus the same combination C |
A connectable Advertising state plus any combination C of other states | Connection (Peripheral role) plus the same combination C |
Connection (Peripheral role) plus a connectable Advertising state plus any combination C of other states | Connection (Peripheral role) to more than one device in the Central role plus the same combination C |
In each case, the combination of other states C may be empty. In the last two rows, "other states" includes other connectable Advertising states.
1.1.2. Devices supporting only some states
Devices supporting only some Link Layer states or only one of the two roles within the Connection state are not required to support features (including supporting particular PDUs, procedures, data lengths, or HCI commands or particular features of an HCI command) that are only used by a state or mode that the device does not support.
1.2. Bit ordering
The bit ordering when defining fields within the packet or Protocol Data Unit (PDU) in the Link Layer 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 defined in the Link Layer, such as the PDU header fields, shall be transmitted with the LSB first. For instance, a 3-bit parameter X=3 is sent as:
Over the air, 1 is sent first, 1 is sent next, and 0 is sent last. This is shown as 110 in the specification.
Binary field values specified in the specification that follow the format 0b10101010 (e.g., the advertising physical channel Access Address in Section 2.1.2) are written with the MSB to the left.
Multi-octet fields, with the exception of the Cyclic Redundancy Check (CRC) and the Message Integrity Check (MIC), shall be transmitted with the least significant octet first. Each octet within multi-octet fields, with the exception of the CRC (see Section 3.1.1), shall be transmitted in LSB first order. For example, the 48-bit addresses in the advertising physical channel PDUs shall be transmitted with the least significant octet first, followed by the remainder of the five octets in increasing order.
Multi-octet field values specified in the specification (e.g. the CRC initial value in Section 2.3.3.1) are written with the most significant octet to the left; for example in 0x112233445566, the octet 0x11 is the most significant octet.
Where a packet or PDU is shown in a figure as containing more than one field, the fields shall be transmitted in the order shown in the figure, leftmost first.
1.3. Device address
Devices are identified using a device address and an address type; the address type indicates either a public device address or a random device address. A public device address and a random device address are both 48 bits in length.
A device shall use at least one type of device address and may use both. The device may be addressed by any device address that it uses.
A device's Identity Address is a Public Device Address or Random Static Device Address that it uses in packets it transmits. If a device is using Resolvable Private Addresses, it shall also have an Identity Address.
Whenever two device addresses are compared, the comparison shall include the device address type (i.e. if the two addresses have different types, they are different even if the two 48-bit addresses are the same).
1.3.1. Public device address
The public device address shall be created in accordance with [Vol 2] Part B, Section 1.2, with the exception that the restriction on LAP values does not apply unless the public device address will also be used as a BD_ADDR for a BR/EDR Controller.
1.3.2. Random device address
The random device address may be of either of the following:
Static address
Private address.
The specific sub-type is indicated by the two most significant bits of the random device address as shown in Table 1.2.
Address [47:46] | Sub-Type |
|---|---|
0b00 | Non-resolvable private address |
0b01 | Resolvable private address |
0b10 | Reserved for future use |
0b11 | Static device address |
The term random device address refers to both static and private address types.
The transmission of a random device address is optional. A device shall accept the reception of a random device address from a remote device.
1.3.2.1. Static device address
A static address is a 48-bit randomly generated address and shall meet the following requirements:
At least one bit of the random part of the address shall be 0
At least one bit of the random part of the address shall be 1
The format of a static address is shown in Figure 1.2.
A device may choose to initialize its static address to a new value after each power cycle. A device shall not change its static address value once initialized until the device is power cycled.
Note
Note: If the static address of a device is changed, then the address stored in peer devices will not be valid and the ability to reconnect using the old address will be lost.
1.3.2.2. Private device address generation
The private address may be of either of the following two sub-types:
Non-resolvable private address
Resolvable private address
To generate a non-resolvable address, the device shall generate a 48-bit address with the following requirements:
At least one bit of the random part of the address shall be 1
At least one bit of the random part of the address shall be 0
The address shall not be equal to the public address
The format of a non-resolvable private address is shown in Figure 1.3.
To generate a resolvable private address, the device must have either the Local Identity Resolving Key (IRK) or the Peer Identity Resolving Key (IRK). The resolvable private address shall be generated with the IRK and a randomly generated 24-bit number. The random number is known as prand and shall meet the following requirements:
At least one bit of the random part of prand shall be 0
At least one bit of the random part of prand shall be 1
The format of the resolvable private address is shown in Figure 1.4.
The hash is generated using the random address function ah defined in [Vol 3] Part H, Section 2.2.2 with the input parameter k set to the device’s IRK and the input parameter r set to prand.
The prand and hash are concatenated to generate the random address in the following manner:
The least significant octet of hash becomes the least significant octet of randomAddress and the most significant octet of prand becomes the most significant octet of randomAddress.
1.3.2.3. Private device address resolution
A resolvable private address may be resolved if the corresponding device’s IRK is available using this procedure. If a resolvable private address is resolved, the device can associate this address with the peer device.
The resolvable private address (RPA) is divided into a 24-bit random part (prand) and a 24-bit hash part (hash). The least significant octet of the RPA becomes the least significant octet of hash and the most significant octet of RPA becomes the most significant octet of prand. A localHash value is then generated using the random address hash function ah defined in [Vol 3] Part H, Section 2.2.2 with the input parameter k set to IRK of the known device and the input parameter r set to the prand value extracted from the RPA.
The localHash value is then compared with the hash value extracted from RPA. If the localHash value matches the extracted hash value, then the identity of the peer device has been resolved.
If a device has more than one stored IRK, the device repeats the above procedure for each stored IRK to determine if the received resolvable private address is associated with a stored IRK, until either address resolution is successful for one of the IRKs or all have been tried.
Note
Note: A device that cannot resolve a private address within T_IFS_150 may respond on the reception of the next event.
A non-resolvable private address cannot be resolved.
1.4. Physical channel
As specified in [Vol 6] Part A, Section 2, 40 RF channels are defined in the 2.4 GHz ISM band. These RF channels are divided into 3 RF channels known as the "primary advertising channels", used for initial advertising and all legacy advertising activities, and 37 RF channels known as the "general-purpose channels", used for the majority of communications. Each of these RF channels is allocated a unique channel index (see Section 1.4.1).
These two groups of RF channels are used in four LE physical channels: advertising, periodic, isochronous, and data. The advertising physical channel uses both groups for discovering devices, initiating a connection, and broadcasting data; within this, the primary advertising channels form the primary advertising physical channel and the general-purpose channels form the secondary advertising physical channel. The remaining physical channels only use the general-purpose channels.
Two devices that wish to communicate use a shared physical channel. To achieve this, their transceivers must be tuned to the same RF channel at the same time.
Given that the number of RF channels is limited, and that many Bluetooth devices may be operating independently within the same spatial and temporal area, there is a strong likelihood of two independent Bluetooth devices having their transceivers tuned to the same RF channel, resulting in a physical channel collision. To mitigate the unwanted effects of this collision, each transmission on a physical channel starts with an Access Address that is used as a correlation code by devices tuned to the physical channel. This Access Address is a property of the physical channel. The Access Address is present at the start of every transmitted packet.
The Link Layer uses one physical channel at a given time.
Whenever the Link Layer is synchronized to the timing, frequency, and Access Address of a physical channel, it is said to be 'connected' on the data physical channel or ‘synchronized’ to the periodic physical channel or isochronous physical channel (whether or not it is actively involved in communications over the channel).
1.4.1. Physical channel indices
Table 1.3 shows the mapping from RF Channel to Physical Channel Index and RF Channel group. A ‘●’ in Table 1.3 indicates the RF channel and index are part of the specified channel group; a blank cell indicates that they are not part of that group.
RF Channel (Center Frequency) | Physical Channel Index | RF Channel Group | |
|---|---|---|---|
Primary Advertising | General purpose | ||
2402 MHz | 37 | ● | |
2404 MHz | 0 | ● | |
2406 MHz | 1 | ● | |
... | ... | ... | ... |
2424 MHz | 10 | ● | |
2426 MHz | 38 | ● | |
2428 MHz | 11 | ● | |
2430 MHz | 12 | ● | |
... | ... | ... | ... |
2478 MHz | 36 | ● | |
2480 MHz | 39 | ● | |
2. Air interface packets
LE devices shall use the packets as defined in the following sections. There are two basic formats: one for the LE Uncoded PHYs, described in Section 2.1, and one for the LE Coded PHY, described in Section 2.2.
Additional packet formats specific to Channel Sounding are defined in [Vol 6] Part H, Section 2.
2.1. Packet format for the LE Uncoded PHYs
The following packet format is defined for the LE Uncoded PHYs (LE 1M and LE 2M) and is used for packets on all physical channels.
This packet format is shown in Figure 2.1. Each packet consists of four mandatory fields and one optional field. The mandatory fields are Preamble, Access Address, PDU, and CRC. The optional field is Constant Tone Extension.
The preamble is 1 octet when transmitting or receiving on the LE 1M PHY and 2 octets when transmitting or receiving on the LE 2M PHY. The Access Address is 4 octets. The PDU range is from 2 to 258 octets. The CRC is 3 octets.
The Preamble is transmitted first, followed by the Access Address, PDU, CRC, and Constant Tone Extension (if present) in that order. The entire packet is transmitted at the same symbol rate (either 1 Msym/s or 2 Msym/s modulation).
Packets (not including the Constant Tone Extension) take between 44 and 2128 µs to transmit.
When the Constant Tone Extension is present, the Constant Tone Extension duration is between 16 and 160 µs, as shown in Figure 2.1.
2.1.1. Preamble
All Link Layer packets have a preamble which is used in the receiver to perform frequency synchronization, symbol timing estimation, and Automatic Gain Control training. The preamble is a fixed sequence of alternating 0 and 1 bits. For packets transmitted on the LE 1M PHY, the preamble is 8 bits; for packets transmitted on the LE 2M PHY, the preamble is 16 bits. The first bit of the preamble (in transmission order) shall be the same as the LSB of the Access Address. The preamble is shown in Figure 2.2.
2.1.2. Access Address
All AUX_SYNC_IND, AUX_CHAIN_IND, AUX_SYNC_SUBEVENT_IND, AUX_CONNECT_REQ, and AUX_CONNECT_RSP PDUs sent on a periodic advertising train shall use the Access Address (AA) value set in the SyncInfo field (see Section 2.3.4.6) contained in the AUX_ADV_IND PDU that describes the train. All AUX_SYNC_SUBEVENT_RSP PDUs sent on a periodic advertising with responses train shall use the Access Address value set in the Periodic Advertising Response Timing Information (see Section 1.24 of [1]) contained in the AUX_ADV_IND PDU that describes the train. For a given periodic advertising with responses train, the AA value of the AUX_SYNC_SUBEVENT_RSP PDUs shall be different from the AA value of the AUX_SYNC_SUBEVENT_IND PDUs.
The Access Address for all other advertising physical channel packets shall be 0b10001110_10001001_10111110_11010110 (0x8E89BED6).
It is intended that each Link Layer connection between any two devices, each BIS, and each periodic advertising train has a different Access Address.
The Link Layer in the Initiating state shall generate a new Access Address for each initiating PDU it sends (see Section 2.3.3.1). The Link Layer in the Advertising state shall generate a new Access Address each time that it enables a periodic advertising train and, for periodic advertising with responses, a second Access Address for the responses. The first address is sent in the SyncInfo field (see Section 2.3.4.6) of PDUs referring to that periodic advertising train and the second in the Periodic Advertising Response Timing Information (see Section 1.24 of [1]) for the train.
The Link Layer in the Central Role in the Connected State shall generate a new Access Address for each Connected Isochronous Stream (CIS) it creates. The address is sent in the Link Layer Control PDU that is used to create the CIS (see Section 2.4.2.31).
The Access Address shall be a 32-bit value. Each time it needs a new Access Address (except for a Broadcast Isochronous Stream (BIS)), the Link Layer shall generate a new random value.
Each Access Address shall meet the following requirements:
It shall not be the Access Address for any existing ACL connection or CIS on this device.
It shall not be the Access Address for any enabled periodic advertising train.
It shall not be the Access Address for any existing BIS on this device.
It shall not be the Access Address for any existing BIG Control logical link on this device.
If it is the Access Address for a new CIS, it shall differ by more than one bit from any other Access Address being used on the same device.
It shall have no more than six consecutive zeros or ones.
It shall not be the advertising physical channel packets’ Access Address.
It shall not be a sequence that differs from the advertising physical channel packets’ Access Address by only one bit.
It shall not have all four octets equal.
It shall have no more than 24 transitions.
It shall have a minimum of two transitions in the most significant six bits.
The Link Layer in the Isochronous Broadcasting State shall generate a new Seed Access Address (SAA) for each BIG. The Access Addresses for the constituent BIS(es) are derived from the SAA. The SAA shall be a random number that meets the following requirements:
SAA19 = SAA15 SAA22 = SAA16 ≠ SAA15 SAA25 = 0 SAA23 = 1
For any pair of BIGs transmitted by the same device, the SAA15-0 values shall differ in at least two bits.
The Access Address for each BIS and for the BIG Control logical link (see Section 4.4.6.7) in a BIG shall be derived from the SAA for that BIG.
For each BIS logical transport, the Access Address shall be equal to the SAA bit-wise XORed with a diversifier word (DW) for that logical transport derived from a Diversifier (D) as follows:
D = ((35 × n) + 42) mod 128 where n is the BIS number, or 0 for the BIG Control logical link
For example, if n=1, D=77=0b01001101 and DW = 0xFD060000.
The seed for the random number generator shall be from a physical source of entropy and should have at least 20 bits of entropy.
If the random number and, in the case of an SAA, the derived Access Addresses for the BIS and the BIG Control logical link do not meet the above requirements, new random numbers shall be generated until the requirements are met.
On an implementation that also supports the LE Coded PHY (see Section 2.2), the Access Address shall also meet the following requirements:
It shall have at least three ones in the least significant 8 bits.
It shall have no more than eleven transitions in the least significant 16 bits.
2.1.3. PDU
The preamble and Access Address are followed by a PDU. When a packet is transmitted on either the primary or secondary advertising physical channel or the periodic physical channel, the PDU shall be the Advertising Physical Channel PDU as defined in Section 2.3. When a packet is transmitted on the data physical channel, the PDU shall be the Data Physical Channel PDU as defined in Section 2.4. When a packet is transmitted on the isochronous physical channel, the PDU shall be one of the Isochronous Physical Channel PDUs as defined in Section 2.6.
2.1.4. CRC
The PDU is followed by a 24-bit CRC. It shall be calculated over the PDU. The CRC polynomial is defined in Section 3.1.1.
2.1.5. Constant Tone Extension
The CRC is followed by an optional Constant Tone Extension, which consists of a constantly modulated series of unwhitened 1s. The Constant Tone Extension is not included in CRC or MIC calculations. The Constant Tone Extension field shall not be present in a packet sent on the isochronous physical channel. The Constant Tone Extension is discussed further in Section 2.5.
2.2. Packet format for the LE Coded PHY
The following packet format is defined for the LE Coded PHY and is used for packets on all physical channels. This packet format is shown in Figure 2.3.
Each packet consists of the Preamble, FEC block 1, and FEC block 2.
The Preamble is not coded.
The FEC block 1 consists of three fields: Access Address, Coding Indicator (CI), and TERM1. These shall use the S=8 coding scheme as defined in Section 3.3.1.
The CI determines which coding scheme is used for FEC block 2.
The FEC block 2 consists of three fields: PDU, CRC, and TERM2. These shall use either the S=2 or S=8 coding scheme as defined in Section 3.3, depending on the value of the CI.
The entire packet is transmitted with 1 Msym/s modulation.
Table 2.1 captures the size and duration of the data packet fields.
Fields | |||||||
|---|---|---|---|---|---|---|---|
Preamble | Access Address | CI | TERM1 | PDU | CRC | TERM2 | |
Number of Bits | Uncoded | 32 | 2 | 3 | 16 – 2056 | 24 | 3 |
Duration when using S=8 coding (µs) | 80 | 256 | 16 | 24 | 128 – 16448 | 192 | 24 |
Duration when using S=2 coding (µs) | 80 | 256 | 16 | 24 | 32 – 4112 | 48 | 6 |
Packets take between 462 and 17040 µs to transmit.
Note
Note: There is no Constant Tone Extension on the LE Coded PHY.
2.2.1. Preamble
The Preamble is 80 symbols in length and consists of 10 repetitions of the symbol pattern '00111100' (in transmission order).
2.2.2. Access Address
The Access Address is specified in Section 2.1.2.
2.2.3. Coding Indicator
The Coding Indicator (CI) consists of two bits as defined in Table 2.2.
CI | Meaning |
|---|---|
0b00 | FEC Block 2 coded using S=8 |
0b01 | FEC Block 2 coded using S=2 |
All other values | Reserved for future use |
2.2.4. PDU
When a packet is transmitted on either the primary or secondary advertising physical channel or the periodic physical channel, the PDU shall be the Advertising Physical Channel PDU as defined in Section 2.3. When a packet is transmitted on the data physical channel, the PDU shall be the Data Physical Channel PDU as defined in Section 2.4. When a packet is transmitted on the isochronous physical channel, the PDU shall be one of the Isochronous Physical Channel PDUs as defined in Section 2.6.
2.2.5. CRC
The CRC is 24 bits in length and the value is calculated over all the PDU bits. The CRC generator polynomial is defined in Section 3.1.1.
2.2.6. TERM1 and TERM2
There is a terminator at the end of each FEC block referred to as TERM1 and TERM2. Each terminator is 3 bits long and forms the termination sequence defined in Section 3.3.1.
2.3. Advertising physical channel PDU
Note
Note: Despite the name, the advertising physical channel PDU is also used on the periodic physical channel.
The advertising physical channel PDU has a 16-bit header and a variable size payload. Its format is as shown in Figure 2.4. The 16-bit Header field of the advertising physical channel PDU is as shown in Figure 2.5.
The PDU Type field of the advertising physical channel PDU that is contained in the header indicates the PDU type as defined in Table 2.3, which also shows which channel and which PHYs the packet may appear on. A ‘●’ in Table 2.3 indicates that the PDU may appear on that PHY; a blank cell indicates that the PDU shall not appear on that PHY.
PDU Type | PDU Name | Physical Channel | Permitted PHYs | ||
|---|---|---|---|---|---|
LE 1M | LE 2M | LE Coded | |||
0b0000 | ADV_IND | Primary Advertising | ● | ||
0b0001 | ADV_DIRECT_IND | Primary Advertising | ● | ||
0b0010 | ADV_NONCONN_IND | Primary Advertising | ● | ||
0b0011 | SCAN_REQ | Primary Advertising | ● | ||
AUX_SCAN_REQ | Secondary Advertising | ● | ● | ● | |
0b0100 | SCAN_RSP | Primary Advertising | ● | ||
0b0101 | CONNECT_IND | Primary Advertising | ● | ||
AUX_CONNECT_REQ | Secondary Advertising | ● | ● | ● | |
0b0110 | ADV_SCAN_IND | Primary Advertising | ● | ||
0b0111 | ADV_EXT_IND | Primary Advertising | ● | ● | |
AUX_ADV_IND | Secondary Advertising | ● | ● | ● | |
AUX_SCAN_RSP | Secondary Advertising | ● | ● | ● | |
AUX_SYNC_IND | Periodic | ● | ● | ● | |
AUX_CHAIN_IND | Secondary Advertising and Periodic | ● | ● | ● | |
AUX_SYNC_SUBEVENT_IND | Periodic | ● | ● | ● | |
AUX_SYNC_SUBEVENT_RSP | Periodic | ● | ● | ● | |
0b1000 | AUX_CONNECT_RSP | Secondary Advertising | ● | ● | ● |
0b1001 | ADV_DECISION_IND | Primary Advertising | ● | ● | |
All other values | Reserved for future use | ||||
The ChSel, TxAdd and RxAdd fields of the advertising physical channel PDU that are contained in the header contain information specific to the PDU type 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 shall be considered reserved for future use.
The Length field of the advertising physical channel PDU header indicates the length of the payload in octets. The valid range of the Length field shall be 1 to 255 octets.
The Payload fields in the advertising physical channel PDUs are specific to the PDU Type and are defined in Section 2.3.1 to Section 2.3.4. The PDU Types marked as Reserved for future use shall not be sent and shall be ignored upon receipt.
Within advertising physical channel PDUs, advertising data or scan response data from the Host may be included in the Payload in some PDU Types. The format of this data is defined in [Vol 3] Part C, Section 11.
Some advertising physical channel PDUs contain an AuxPtr field (see Section 2.3.4.5) which points to a packet containing another advertising physical channel PDU. In this case, the second packet and PDU are the auxiliary packet and auxiliary PDU of the original PDU, which in turn is the superior packet and superior PDU of the second one.
Note
Note: A PDU can only have one auxiliary PDU but more than one superior PDU.
Given a packet, its subordinate set consists of its auxiliary packet, if any, and the subordinate set of the auxiliary packet. A packet without an AuxPtr field has an empty subordinate set.
2.3.1. Advertising PDUs
The following advertising physical channel PDU Types are called advertising PDUs:
ADV_IND
ADV_DIRECT_IND
ADV_NONCONN_IND
ADV_SCAN_IND
ADV_EXT_IND
ADV_DECISION_IND
AUX_ADV_IND
AUX_SYNC_IND
AUX_CHAIN_IND
AUX_SYNC_SUBEVENT_IND
AUX_SYNC_SUBEVENT_RSP
These PDUs are sent by the Link Layer in the Advertising state and received by a Link Layer in the Scanning state or Initiating state. The ADV_IND, ADV_DIRECT_IND, ADV_NONCONN_IND, and ADV_SCAN_IND PDUs are called “legacy advertising PDUs”. The ADV_EXT_IND, ADV_DECISION_IND, AUX_ADV_IND, AUX_SYNC_IND, AUX_CHAIN_IND, AUX_SYNC_SUBEVENT_IND, and AUX_SYNC_SUBEVENT_RSP PDUs are called “extended advertising PDUs”. The ADV_DECISION_IND PDU is also called a “decision PDU”. Advertising events using legacy advertising PDUs are called “legacy advertising events”.
2.3.1.1. ADV_IND
The Payload field of the ADV_IND PDU is shown in Figure 2.6. The PDU shall be used in connectable and scannable undirected advertising events. The TxAdd in the advertising physical channel PDU header indicates whether the advertiser’s address in the AdvA field is public (TxAdd = 0) or random (TxAdd = 1). The ChSel field in the advertising physical channel PDU header shall be set to 1 if the advertiser supports the LE Channel Selection Algorithm #2 feature (see Section 4.5.8.3).
The AdvA field shall contain the advertiser’s public or random device address as indicated by TxAdd. The AdvData field, if not empty, shall contain Advertising Data from the advertiser’s Host.
2.3.1.2. ADV_DIRECT_IND
The Payload field of the ADV_DIRECT_IND PDU is shown in Figure 2.7. The PDU shall only be used in connectable directed advertising events. The TxAdd in the advertising physical channel PDU header indicates whether the advertiser’s address in the AdvA field is public (TxAdd = 0) or random (TxAdd = 1). The RxAdd in the advertising physical channel PDU header indicates whether the target’s address in the TargetA field is public (RxAdd = 0) or random (RxAdd = 1). The ChSel field in the advertising physical channel PDU header shall be set to 1 if the advertiser supports the LE Channel Selection Algorithm #2 feature (see Section 4.5.8.3).
The AdvA field shall contain the advertiser’s public or random device address as indicated by TxAdd. The TargetA field is the address of the device to which this PDU is addressed. The TargetA field shall contain the target’s public or random device address as indicated by RxAdd.
Note
Note: This packet does not contain any Host data.
2.3.1.3. ADV_NONCONN_IND
The Payload field of the ADV_NONCONN_IND PDU is shown in Figure 2.8. The PDU shall only be used in non-connectable and non-scannable undirected advertising events. The TxAdd in the advertising physical channel PDU header indicates whether the advertiser’s address in the AdvA field is public (TxAdd = 0) or random (TxAdd = 1).
The AdvA field shall contain the advertiser’s public or random device address as indicated by TxAdd. The AdvData field, if not empty, shall contain Advertising Data from the advertiser’s Host.
2.3.1.4. ADV_SCAN_IND
The Payload field of the ADV_SCAN_IND PDU is shown in Figure 2.9. The PDU shall only be used in scannable undirected advertising events. The TxAdd in the advertising physical channel PDU header indicates whether the advertiser’s address in the AdvA field is public (TxAdd = 0) or random (TxAdd = 1).
The AdvA field shall contain the advertiser’s public or random device address as indicated by TxAdd. The AdvData field, if not empty, shall contain Advertising Data from the advertiser’s Host.
2.3.1.5. ADV_EXT_IND
The ADV_EXT_IND PDU uses the Common Extended Advertising Payload Format described in Section 2.3.4. The PDU may be used in the advertising events indicated by the AdvMode field value. An advertising event using an ADV_EXT_IND PDU is directed if, and only if, either the TargetA field is present or the AuxPtr field is present and points to a PDU where the TargetA field is present.
The Common Extended Advertising Payload Format fields permitted in the ADV_EXT_IND PDU are shown in Table 2.4.
Common Extended Advertising Payload Format fields | ||||||||||
|---|---|---|---|---|---|---|---|---|---|---|
Event Type | Adv Mode | AdvA | TargetA | CTE Info | ADI | Aux Ptr | Sync Info | Tx Power | ACAD | Adv Data |
Non-Connectable and Non-Scannable Undirected without auxiliary packet | 0b00 | M | X | X | X | X | X | O | X | X |
Non-Connectable and Non-Scannable Undirected with auxiliary packet | 0b00 | C.1 | X | X | M | M | X | C.1 | X | X |
Non-Connectable and Non-Scannable Directed without auxiliary packet | 0b00 | M | M | X | X | X | X | O | X | X |
Non-Connectable and Non-Scannable Directed with auxiliary packet | 0b00 | C.1 | C.1 | X | M | M | X | C.1 | X | X |
Connectable Undirected | 0b01 | X | X | X | M | M | X | C.1 | X | X |
Connectable Directed | 0b01 | X | X | X | M | M | X | C.1 | X | X |
Scannable Undirected | 0b10 | X | X | X | M | M | X | C.1 | X | X |
Scannable Directed | 0b10 | X | X | X | M | M | X | C.1 | X | X |
RFU | 0b11 | |||||||||
| ||||||||||
For the non-connectable and non-scannable directed and non-connectable and non-scannable undirected event types without ACAD or AdvData, the Controller can choose whether or not to use an auxiliary packet. See Sections 4.4.2.6 and 4.4.2.9.
Fields reserved for future use shall not be present when the packet is sent and shall be ignored when received.
Any auxiliary packet shall be an AUX_ADV_IND packet.
2.3.1.6. AUX_ADV_IND
The AUX_ADV_IND PDU uses the Common Extended Advertising Payload Format described in Section 2.3.4. The PDU may be used in the advertising events indicated by the AdvMode field value.
The AdvMode field indicates the type of advertising event the AUX_ADV_IND packet is being used for and shall have the same value as the field in the superior PDU of this PDU.
The Common Extended Advertising Payload Format fields permitted in the AUX_ADV_IND PDU are shown in Table 2.5.
The PHY used for the AUX_ADV_IND shall be specified in the AuxPtr field of the superior PDU. The PHY specified in any AuxPtr field in an AUX_ADV_IND PDU shall be the same as the PHY the PDU was sent on.
If this PDU and its superior PDU both have an ADI field, the values in these fields shall be the same.
Note
Note: The ADI field can be used to detect collisions.
Any auxiliary PDU shall be an AUX_CHAIN_IND PDU.
The SyncInfo field, when present, shall point to an AUX_SYNC_IND PDU.
Common Extended Advertising Payload Format fields | ||||||||||
|---|---|---|---|---|---|---|---|---|---|---|
Adv Mode | Event Type | AdvA | TargetA | CTE Info | ADI | Aux Ptr | Sync Info | Tx Power | ACAD | Adv Data |
0b00 | Non-Connectable and Non-Scannable Undirected | C.1 | X | X | M | O | O | O | O | O |
0b00 | Non-Connectable and Non-Scannable Directed | C.1 | C.2 | X | M | O | O | O | O | O |
0b01 | Connectable Undirected | C.2 | X | X | M | X | X | O | O | O |
0b01 | Connectable Directed | M | M | X | M | X | X | O | O | O |
0b10 | Scannable Undirected | C.2 | X | X | M | X | X | O | O | X |
0b10 | Scannable Directed | M | M | X | M | X | X | O | O | X |
0b11 | RFU | |||||||||
| ||||||||||
2.3.1.7. AUX_SYNC_IND
The AUX_SYNC_IND PDU uses the Common Extended Advertising Payload Format described in Section 2.3.4. The PDU is used in periodic advertising.
The AdvMode field shall be set to 0b00.
The Common Extended Advertising Payload Format fields permitted in the AUX_SYNC_IND PDU are shown in Table 2.6.
The PHY used for the AUX_SYNC_IND PDU shall be that specified in Section 4.4.2.12.
Any auxiliary PDU shall be an AUX_CHAIN_IND PDU.
The Advertising SID subfield of the ADI field shall have the same value as that in the superior PDU of this PDU.
Common Extended Advertising Payload Format fields | ||||||||||
|---|---|---|---|---|---|---|---|---|---|---|
Adv Mode | Event Type | AdvA | TargetA | CTE Info | ADI | Aux Ptr | Sync Info | Tx Power | ACAD | Adv Data |
0b00 | Non-Connectable and Non-Scannable Undirected | X | X | O | O | O | X | O | O | O |
0b01 to 0b11 | RFU | |||||||||
2.3.1.8. AUX_CHAIN_IND
The AUX_CHAIN_IND PDU uses the Common Extended Advertising Payload Format described in Section 2.3.4. The PDU is used to hold additional AdvData. Its superior PDU is an AUX_ADV_IND, AUX_SYNC_IND, AUX_SCAN_RSP or another AUX_CHAIN_IND PDU.
The AdvMode field shall be set to 0b00.
The Common Extended Advertising Payload Format fields permitted in the AUX_CHAIN_IND PDU are shown in Table 2.7.
The PHY used for the AUX_CHAIN_IND PDU shall be the same as the PHY used for its superior PDU.
The ADI field, when present, shall have the same value as the field in the superior PDU.
Note
Note: The ADI field can be used to detect collisions.
Any auxiliary PDU shall be another AUX_CHAIN_IND PDU.
Common Extended Advertising Payload Format fields | ||||||||||
|---|---|---|---|---|---|---|---|---|---|---|
Adv Mode | Event Type | AdvA | TargetA | CTE Info | ADI | Aux Ptr | Sync Info | Tx Power | ACAD | Adv Data |
0b00 | Chained data | X | X | C.2 | C.1 | O | X | O | X | O |
0b01 to 0b11 | RFU | |||||||||
| ||||||||||
2.3.1.9. AUX_SYNC_SUBEVENT_IND
The AUX_SYNC_SUBEVENT_IND PDU uses the Common Extended Advertising Payload Format described in Section 2.3.4. This PDU is used in PAwR.
The AdvMode field shall be set to 0x00.
The Common Extended Advertising Payload Format fields permitted in the AUX_SYNC_SUBEVENT_IND PDU are shown in Table 2.8.
The PHY used for the AUX_SYNC_SUBEVENT_IND shall be that specified in Section 4.4.2.12.
The Advertising SID subfield of the ADI field shall have the same value as that in the superior PDU of this PDU.
Common Extended Advertising Payload Format fields | ||||||||||
|---|---|---|---|---|---|---|---|---|---|---|
Adv Mode | Event Type | AdvA | TargetA | CTE Info | ADI | Aux Ptr | Sync Info | Tx Power | ACAD | Adv Data |
0b00 | Subevent Indication | X | X | O | O | X | X | O | O | O |
0b01 to 0b11 | RFU | |||||||||
2.3.1.10. AUX_SYNC_SUBEVENT_RSP
The AUX_SYNC_SUBEVENT_RSP PDU uses the Common Extended Advertising Payload Format described in Section 2.3.4. This PDU is used in PAwR.
The AdvMode field shall be set to 0x00.
The Common Extended Advertising Payload Format fields permitted in the AUX_SYNC_SUBEVENT_RSP PDU are shown in Table 2.9.
The PHY used for the AUX_SYNC_SUBEVENT_RSP shall be that specified in Section 4.4.2.12.
Common Extended Advertising Payload Format fields | ||||||||||
|---|---|---|---|---|---|---|---|---|---|---|
Adv Mode | Event Type | AdvA | TargetA | CTE Info | ADI | Aux Ptr | Sync Info | Tx Power | ACAD | Adv Data |
0b00 | Subevent Response | O | X | O | X | X | X | O | O | O |
0b01 to 0b11 | RFU | |||||||||
2.3.1.11. ADV_DECISION_IND
The Payload field of the ADV_DECISION_IND PDU is shown in Figure 2.10. The PDU may be used in the undirected advertising events indicated by the AdvMode field value.
The Extended Header field is the same as the Extended Header field of the Common Extended Advertising Payload Format (see Section 2.3.4); the fields permitted in the ADV_DECISION_IND PDU are shown in Table 2.10.
Common Extended Advertising Payload Format Extended Header fields | |||||||||
|---|---|---|---|---|---|---|---|---|---|
Adv Mode | Event Type | AdvA | TargetA | CTEInfo | ADI | AuxPtr | SyncInfo | TxPower | ACAD |
0b00 | Non-Connectable and Non-Scannable Undirected | O | X | X | O | M | X | C.1 | X |
0b01 | Connectable Undirected | O | X | X | O | M | X | C.1 | X |
0b10 | Scannable Undirected | O | X | X | O | M | X | C.1 | X |
0b11 | RFU | ||||||||
| |||||||||
The format of the Decision Data field is shown in Figure 2.11:
The Decision Type Flags bit field definitions are listed in Table 2.11.
Bit number | Subfield |
|---|---|
0 | Resolvable Tag |
All other bits | Reserved for future use |
If a bit in the Decision Type Flags field is set to 1, then the corresponding subfield of Decision Data shall be present; otherwise, the corresponding subfield shall not be present. Therefore, the Decision Data field must be long enough to hold all the subfields indicated in the Decision Type Flags field. Any octets of the Decision Data following these subfields form the Arbitrary Data subfield.
A Resolvable Tag shall have the format shown in Figure 2.12.
 |
A Resolvable Tag is said to resolve against a key provided by the Host if the Hash field equals the value ah(key, prand), where prand is the value of the Prand field and ah is the function defined in [Vol 3] Part H, Section 2.2.2.
The auxiliary PDU shall be an AUX_ADV_IND PDU.
2.3.2. Scanning PDUs
The following advertising physical channel PDU types are called scanning PDUs.
SCAN_REQ
SCAN_RSP
AUX_SCAN_REQ
AUX_SCAN_RSP
The SCAN_REQ and AUX_SCAN_REQ PDUs are called scan request PDUs. The SCAN_RSP and AUX_SCAN_RSP PDUs are called scan response PDUs.
Where these PDUs are used to reply to a scannable advertisement, the PHY used for them shall be the same as the PHY used for the PDU that they reply to.
2.3.2.1. SCAN_REQ and AUX_SCAN_REQ
The Payload field of the SCAN_REQ and AUX_SCAN_REQ PDUs is shown in Figure 2.13. The TxAdd in the advertising physical channel PDU header indicates whether the scanner’s address in the ScanA field is public (TxAdd = 0) or random (TxAdd = 1). The RxAdd in the advertising physical channel PDU header indicates whether the advertiser’s address in the AdvA field is public (RxAdd = 0) or random (RxAdd = 1).
The ScanA field shall contain the scanner’s public or random device address as indicated by TxAdd. The AdvA field is the address of the device to which this PDU is addressed. The AdvA field shall contain the advertiser’s public or random device address as indicated by RxAdd.
Note
Note: These PDUs do not contain any Host Data.
2.3.2.2. SCAN_RSP
The Payload field of the SCAN_RSP PDU is shown in Figure 2.14. The TxAdd in the advertising physical channel PDU header indicates whether the advertiser’s address in the AdvA field is public (TxAdd = 0) or random (TxAdd = 1). The Length field indicates the size of the payload (AdvA and ScanRspData) in octets.
The AdvA field shall contain the advertiser’s public or random device address as indicated by TxAdd. The ScanRspData field may contain any data from the advertiser’s Host.
2.3.2.3. AUX_SCAN_RSP
The AUX_SCAN_RSP PDU uses the Common Extended Advertising Payload Format described in Section 2.3.4.
The AdvMode field shall be set to 0b00.
The Common Extended Advertising Payload Format fields permitted in the AUX_SCAN_RSP PDU are shown in Table 2.12.
The ADI field, if present, shall have the same value as the field in the AUX_ADV_IND PDU that the scanner responded to.
Note
Note: The ADI field can be used to detect collisions.
Any auxiliary PDU shall be an AUX_CHAIN_IND PDU.
Common Extended Advertising Payload Format fields | ||||||||||
|---|---|---|---|---|---|---|---|---|---|---|
Adv Mode | Event Type | AdvA | TargetA | CTE Info | ADI | Aux Ptr | Sync Info | Tx Power | ACAD | Adv Data |
0b00 | Scan response | M | X | X | O | O | X | O | O | M |
0b01 to 0b11 | RFU | |||||||||
2.3.3. Initiating PDUs
The following advertising physical channel PDU Types are called initiating PDUs:
CONNECT_IND
AUX_CONNECT_REQ
AUX_CONNECT_RSP
The CONNECT_IND and the AUX_CONNECT_REQ PDUs are sent by the Link Layer in the Initiating state and received by the Link Layer in the Advertising state. The AUX_CONNECT_RSP PDU is sent by the Link Layer in the Advertising state and received by the Link Layer in the Initiating state.
The PHY used for these PDUs shall be the same as the PHY used for the PDU that they reply to.
2.3.3.1. CONNECT_IND and AUX_CONNECT_REQ
The Payload field of the CONNECT_IND and AUX_CONNECT_REQ PDUs is shown in Figure 2.15. TxAdd in the advertising physical channel PDU header indicates whether the address in the InitA field is public (TxAdd = 0) or random (TxAdd = 1). The RxAdd in the advertising physical channel PDU header indicates whether the address in the AdvA field is public (RxAdd = 0) or random (RxAdd = 1).
The ChSel field in the CONNECT_IND PDU header shall be set to 1 if both the initiator and advertiser support the LE Channel Selection Algorithm #2 feature (see Section 4.5.8.3). If the initiator supports the LE Channel Selection Algorithm #2 feature but the advertiser does not, the initiator may set the ChSel field to 0 or 1. The ChSel field in the CONNECT_IND PDU header shall be set to 0 if the initiator does not support the LE Channel Algorithm #2 feature. The ChSel field in the AUX_CONNECT_REQ PDU header is reserved for future use.
The InitA field shall contain the Initiator’s public or random device address as indicated by TxAdd. The AdvA field shall contain the advertiser’s public or random device address as indicated by RxAdd.
The format of the LLData field is shown in Figure 2.16.
The AA field shall contain the ACL connection’s Access Address determined by the Link Layer following the rules specified in Section 2.1.2.
The CRCInit field shall contain the initialization value for the CRC calculation for the ACL connection, as defined in Section 3.1.1. It shall be a random value, generated by the Link Layer. The seed for the random number generator shall be from a physical source of entropy and should have at least 20 bits of entropy.
The WinSize field shall be set to indicate the transmitWindowSize value, as defined in Section 4.5.3 in the following manner:
transmitWindowSize = WinSize × 1.25 ms.
The WinOffset field shall be set to indicate the transmitWindowOffset value, as defined in Section 4.5.3 in the following manner:
transmitWindowOffset = WinOffset × 1.25 ms.
The Interval field shall be set to indicate the connInterval as defined in Section 4.5.1 in the following manner:
connInterval = Interval × 1.25 ms.
The Latency field shall be set to indicate the connPeripheralLatency value, as defined in Section 4.5.1 in the following manner:
connPeripheralLatency = Latency.
The Timeout field shall be set to indicate the connSupervisionTimeout value, as defined in Section 4.5.2, in the following manner:
connSupervisionTimeout = Timeout × 10 ms.
The ChM field shall contain the channel map indicating Used and Unused data channels. Every channel is represented with a bit positioned as per the data channel index as defined in Section 1.4.1. The LSB represents data channel index 0 and the bit in position 36 represents data channel index 36. A bit value of 0 indicates that the channel is Unused. A bit value of 1 indicates that the channel is Used. The bits in positions 37, 38 and 39 are reserved for future use.
Note
Note: When mapping from RF channels to data channel index, there is a gap where advertising channel index 38 is placed.
The Hop field shall be set to indicate the hopIncrement used in the data channel selection algorithm as defined in Section 4.5.8.2. It shall have a random value in the range 5 to 16.
The SCA field shall be set to indicate the centralSCA used to determine the Central's worst case sleep clock accuracy as defined in Section 4.2.2. The value of the SCA field shall be set as defined in Table 2.13.
SCA | centralSCA or peripheralSCA |
|---|---|
0 | 251 ppm to 500 ppm |
1 | 151 ppm to 250 ppm |
2 | 101 ppm to 150 ppm |
3 | 76 ppm to 100 ppm |
4 | 51 ppm to 75 ppm |
5 | 31 ppm to 50 ppm |
6 | 21 ppm to 30 ppm |
7 | 0 ppm to 20 ppm |
2.3.3.2. AUX_CONNECT_RSP
The AUX_CONNECT_RSP PDU uses the Common Extended Advertising Payload Format described in Section 2.3.4.
The AdvMode field shall be set to 0b00.
The Common Extended Advertising Payload Format fields permitted in the AUX_CONNECT_RSP PDU are shown in Table 2.14.
Common Extended Advertising Payload Format fields | ||||||||||
|---|---|---|---|---|---|---|---|---|---|---|
Adv Mode | Event Type | AdvA | TargetA | CTE Info | ADI | Aux Ptr | Sync Info | Tx Power | ACAD | Adv Data |
0b00 | Connection response | M | M | X | X | X | X | X | X | X |
0b01 to 0b11 | RFU | |||||||||
2.3.4. Common Extended Advertising Payload Format
The following extended Advertising Physical Channel PDUs share the same Advertising Physical Channel PDU payload format, referred to in the specification as the “Common Extended Advertising Payload Format”:
ADV_EXT_IND
AUX_ADV_IND
AUX_SCAN_RSP
AUX_SYNC_IND
AUX_CHAIN_IND
AUX_CONNECT_RSP
AUX_SYNC_SUBEVENT_IND
AUX_SYNC_SUBEVENT_RSP
The common extended advertising payload format is shown in Figure 2.17.
The Extended Header Length is a value between 0 and 63 and indicates the size of the variable length Extended Header field.
The AdvMode field indicates the mode of the advertisement. The value of the AdvMode field shall be set as defined in Table 2.15.
Value | Mode | |
|---|---|---|
0b00 | Non-connectable | Non-scannable |
0b01 | Connectable | Non-scannable |
0b10 | Non-connectable | Scannable |
0b11 | Reserved for future use | |
AdvData, if present, shall contain advertising data from the advertiser’s Host. The maximum size of AdvData depends on the size of the Extended Header. The size of the AdvData can be calculated by subtracting the length of the Extended Header plus one octet from the Length specified in the Advertising physical channel PDU Header.
The Extended Header field is a variable length header that is present if, and only if, the Extended Header Length field is non-zero. The format of the Extended Header is shown in Figure 2.18.
The Extended Header Flags bit field definitions are shown in Table 2.16.
Bit | Extended Header |
|---|---|
0 | AdvA |
1 | TargetA |
2 | CTEInfo |
3 | AdvDataInfo (ADI) |
4 | AuxPtr |
5 | SyncInfo |
6 | TxPower |
7 | Reserved for future use |
If a flag bit is set to 1, the corresponding Extended Header field is present; otherwise, the corresponding Extended Header field is not present. The Extended Header fields that are present are always in the same order as the flags in the Extended Header flags (i.e., the AdvA field is first if present, then the TargetA field if present, etc.).
Whether an Extended Header flag and corresponding Extended Header field is mandatory, optional, or reserved for future use is dependent on the Advertising Physical Channel PDU in which the extended header is used.
2.3.4.1. AdvA field
When present, the AdvA field is six octets with the format shown in Figure 2.19.
The Advertising Address field contains the advertiser’s device address. If the AdvA field is present, TxAdd in the advertising physical channel PDU header indicates whether this address is public (TxAdd = 0) or random (TxAdd = 1).
2.3.4.2. TargetA field
When present, the TargetA field is six octets with the format shown in Figure 2.20.
The Target Address field contains the scanner’s or initiator’s device address to which the advertisement is directed. If the TargetA field is present, RxAdd in the advertising physical channel PDU header indicates whether this address is public (RxAdd = 0) or random (RxAdd = 1).
2.3.4.3. CTEInfo field
The presence of the CTEInfo field indicates that the packet includes a Constant Tone Extension. The CTEInfo field is defined in Section 2.5.2.
2.3.4.4. AdvDataInfo field
When present, the AdvDataInfo (ADI) field is two octets with the format shown in Figure 2.21.
The Advertising Set ID (SID) is set by the advertiser's Host to identify an advertising set transmitted by this device.
The Advertising Data ID (DID) is set by the advertiser to indicate to the scanner whether it can assume that the data contents in the AdvData are a duplicate of the previous AdvData sent in an earlier packet.
2.3.4.5. AuxPtr field
When present, the AuxPtr field is three octets with the format shown in Figure 2.22.
The presence of the AuxPtr field indicates that some or all of the advertisement data is in a subsequent auxiliary packet. The contents of the AuxPtr field describe this packet.
The Channel Index field contains the general-purpose channel index (see Section 1.4.1) used to transmit the auxiliary packet.
The Offset Units field indicates the units used by the Aux Offset Field. The value of the Offset Units field shall be set as defined in Table 2.17.
Value | Units |
|---|---|
0 | 30 µs |
1 | 300 µs |
The Aux Offset field contains the time from a reference point to the approximate start of the auxiliary packet, where the reference point is the start of the packet containing the AuxPtr field. The value of the AUX Offset field is in the unit of time indicated by the Offset Units field; the offset is determined by multiplying the value by the unit. The Aux Offset shall be at least the length of the packet plus T_MAFS (see Section 4.1.2). The Offset Units field shall be set to 0 if the Aux Offset is less than 245,700 µs.The auxiliary packet shall not start any earlier than the Aux Offset after the reference point and shall start no later than the Aux Offset plus one Offset Unit after the reference point. This allows the Link Layer to round the Aux Offset to the Offset Unit.
The Aux PHY field indicates the PHY used to transmit the auxiliary packet. The value of the Aux PHY field shall be set as defined in Table 2.18.
Value | PHY used |
|---|---|
0b000 | LE 1M |
0b001 | LE 2M |
0b010 | LE Coded |
0b011 – 0b111 | Reserved for future use |
The CA field contains the clock accuracy of the advertiser that will be used between the packet containing this data and the auxiliary packet. The value of the CA field shall be set as defined in Table 2.19.
CA Value | Advertiser’s Clock Accuracy |
|---|---|
0 | 51 ppm to 500 ppm |
1 | 0 ppm to 50 ppm |
An AuxPtr field with an Aux Offset of zero is permitted and indicates that no auxiliary packet will be transmitted but the Host advertising data in the current PDU is incomplete (see Section 2.3.4.9); it shall be treated as equivalent to one referring to an AUX_CHAIN_IND PDU that is never received. The remaining fields shall contain valid values.
2.3.4.6. SyncInfo field
When present, the SyncInfo field is 18 octets with the format shown in Figure 2.24.
The presence of the SyncInfo field indicates the presence of a periodic advertising train (using AUX_SYNC_IND PDUs or AUX_SYNC_SUBEVENT_IND PDUs). The contents of the SyncInfo field describe this periodic advertising train.
The Offset Units field indicates the units used by the Offset Base field. The value of the Offset Units field shall be set as defined in Table 2.20.
Value | Units |
|---|---|
0 | 30 µs |
1 | 300 µs |
The SyncInfo field can appear in an advertising PDU or in an LL_PERIODIC_SYNC_IND PDU or LL_PERIODIC_SYNC_WR_IND PDU (see Section 2.4.2.27 and Section 2.4.2.40).
The syncPacketWindowOffset value is the time from a reference point to the start of the AUX_SYNC_IND or the AUX_SYNC_SUBEVENT_IND of subevent 0 packet that this SyncInfo field describes. If the SyncInfo appears in an advertising PDU, the reference point is the start of the packet containing it. If it appears in an LL_PERIODIC_SYNC_IND PDU or an LL_PERIODIC_SYNC_WR_IND PDU, the reference point is specified by that PDU. The value of syncPacketWindowOffset is determined by multiplying the value of the Offset Base field by the unit of time indicated by the Offset Units field and then, if the Offset Adjust field is set to 1, adding 2.4576 seconds. The Offset Units field shall be set to 0 if syncPacketWindowOffset is less than 245,700 µs. The Offset Adjust field shall be set to 0 if the Offset Units field is set to 0 or if the SyncInfo field appears within an advertising PDU. As illustrated in Figure 2.25, the packet containing the AUX_SYNC_IND PDU or AUX_SYNC_SUBEVENT_IND PDU shall not start any earlier than syncPacketWindowOffset after the reference point and shall start no later than syncPacketWindowOffset plus one Offset unit after the reference point. This allows the Link Layer to round syncPacketWindowOffset to the Offset Unit.
A value of 0 for syncPacketWindowOffset indicates that the time to the next AUX_SYNC_IND or AUX_SYNC_SUBEVENT_IND packet is greater than can be represented.
The Interval field contains the time, in 1.25 ms units, from the start of one packet of the periodic advertising train to the start of the next packet. The value shall not be less than 6 (7.5 ms).
The ChM field contains the channel map indicating Used and Unused RF channels on the periodic physical channel. Every channel is represented with a bit positioned as per the channel index as defined in Section 1.4.1. The LSB represents channel index 0 and the bit in position 36 represents channel index 36. A bit value of 0 indicates that the channel is Unused. A bit value of 1 indicates that the channel is Used.
The AA, CRCInit, and SCA fields have the same meaning as the corresponding fields in the CONNECT_IND PDU (see Section 2.3.3.1).
The PeriodicEventCounter field contains the value of paEventCounter (see Section 4.4.2.1) that applies to the AUX_SYNC_IND or AUX_SYNC_SUBEVENT_IND packet that this SyncInfo field describes.
2.3.4.7. TxPower field
When present, the TxPower is one octet with the format shown in Figure 2.26.
 |
The Tx Power Level field is the same value defined for the Tx Power Advertising Data type defined in Section 1.5 of [1].
If the Host instructs the Controller to include the TxPower field in an advertisement, then it shall be included in the AUX_ADV_IND PDU if the extended advertising event contains one and in all the ADV_EXT_IND PDUs otherwise. Any AUX_CHAIN_IND PDUs should not contain a TxPower field. If the Host instructs the Controller to include the TxPower field in a periodic advertisement, then it shall be included in the AUX_SYNC_IND, AUX_SYNC_SUBEVENT_IND, or AUX_SYNC_SUBEVENT_RSP PDUs but not in any AUX_CHAIN_IND PDUs.
2.3.4.8. ACAD field
The remainder of the extended header forms the Additional Controller Advertising Data (ACAD) field. The length of this field is the Extended Header length minus the sum of the size of the extended header flags (1 octet) and those fields indicated by the flags as present. ACAD cannot be fragmented across multiple advertising physical channel PDUs; it shall always fit inside a single advertising physical channel PDU.
The ACAD field, if present, shall hold data from the advertiser’s Controller or intended to be used by the recipient’s Controller. It uses the format described in [Vol 3] Part C, Section 11.
The ACAD type formats and meanings are defined in Section 1 of [1]. The ACAD type identifier values are defined in Assigned Numbers.
2.3.4.9. Host Advertising Data
The portion of the PDU after the extended header forms the AdvData field. The length of this field is specified in Section 2.3.4.
The AdvData field, if present, shall hold data from the advertiser’s Host in the format described in [Vol 3] Part C, Section 11. If the Host does not provide any data, the AdvData field shall be omitted but, for all other purposes in this Part, this shall be treated as if the Host had provided data.
The Controller may support fragmentation of Host Advertising Data. The total amount of Host Advertising Data before fragmentation shall not exceed 1650 octets. When the Link Layer fragments the Host advertising data, the number of fragments and the size of each fragment are chosen by the Controller. The Controller should minimize the number of fragments to ensure more reliability in delivering the entire Host advertising data. The Host may indicate a preference whether the Controller should fragment the Host advertising data, but the Controller may ignore the preference. If the amount of advertising or scan response data to be sent in an extended advertising or scanning PDU plus the Extended Header Length, AdvMode, and Extended Header exceed the maximum Advertising Physical Channel PDU payload (255 octets), the Link Layer shall fragment the Host advertising data.
The Link Layer shall place the multiple fragments in the AdvData field of different PDUs. When Host advertising data is fragmented the first fragment shall be placed in the AUX_ADV_IND, AUX_SYNC_IND or AUX_SCAN_RSP PDU while subsequent fragments shall be placed in AUX_CHAIN_IND PDUs. Each AUX_CHAIN_IND PDU is the auxiliary PDU of the PDU containing the previous fragment; AUX_CHAIN_IND PDUs not containing AdvData shall not have an auxiliary PDU containing AdvData.
If the Link Layer has fragmented the Host advertising data but is subsequently unable to transmit all the fragments, the last fragment that it is able to transmit should contain an AuxPtr field with an Aux Offset of zero so that scanners are aware that the data has been truncated.
2.4. Data Physical Channel PDU
The Data Physical Channel PDU has a 16 or 24 bit header, a variable size payload, and may include a Message Integrity Check (MIC) field.
The Data Physical Channel PDU is as shown in Figure 2.27.
The Header field of the Data Physical Channel PDU is as shown in Figure 2.28.
The 16 or 24 bit Header field consists of 6 or 7 fields that are specified in Table 2.21.
The MIC field shall not be included in an un-encrypted ACL connection, or in an encrypted ACL connection with a Data Channel PDU with a zero length Payload.
The MIC field shall be included in an encrypted ACL connection, with a Data Channel PDU with a non-zero length Payload and shall be calculated as specified in [Vol 6] Part E, Section 1.
The payload format depends on the LLID field of the Header. If the LLID field is 0b01 or 0b10, the Data Physical Channel PDU Payload contains an LL Data PDU as defined in Section 2.4.1. If the LLID field is 0b11 then the Data Physical Channel PDU Payload contains an LL Control PDU as defined in Section 2.4.2.
The NESN bit of the Header is defined in Section 4.5.9.
The SN bit of the Header is defined in Section 4.5.9.
The MD bit of the Header is defined in Section 4.5.6.
The CTEInfo Present (CP) field of the Header indicates whether the Data Physical Channel PDU Header has a CTEInfo field and therefore whether the data physical channel packet has a Constant Tone Extension. If the CP field is 0, then no CTEInfo field is present in the Data Channel PDU Header and there is no Constant Tone Extension in the data physical channel packet. If the CP field is 1, then the CTEInfo field in the Data Physical Channel PDU Header is present and the data physical channel packet includes a Constant Tone Extension.
The Length field of the Header indicates the length of the Payload and MIC if included. The length field has the range 0 to 255 octets. The Payload shall be less than or equal to 251 octets in length. The MIC is 4 octets in length.
The CTEInfo field of the Header is present if indicated in the CP field. The CTEInfo field is defined in Section 2.5.2. The CTEInfo field can be present in the header of any Data Physical Channel PDU. However, the Link Layer shall not transmit a Data Physical Channel PDU containing a CTEInfo field unless it has determined that the peer device supports the Receiving Constant Tone Extensions feature (see Section 4.6.22).
Note
Note: A Controller that transmits a PDU containing a CTEInfo field will not necessarily be able to receive one and vice-versa.
In this version of the specification, the only way to request a remote device to send a packet containing the CTEInfo field is via the Constant Tone Extension Request procedure.
Field name | Description |
|---|---|
LLID | The LLID indicates whether the packet is an LL Data PDU or an LL Control PDU. 0b00 = Reserved for future use 0b01 = LL Data PDU: Continuation fragment of an L2CAP message, or an Empty PDU. 0b10 = LL Data PDU: Start of an L2CAP message or a complete L2CAP message with no fragmentation. 0b11 = LL Control PDU |
NESN | Next Expected Sequence Number |
SN | Sequence Number |
MD | More Data |
CP | CTEInfo Present |
Length | The Length field indicates the size, in octets, of the Payload and MIC, if included. |
CTEInfo | The CTEInfo field indicates the type and length of the Constant Tone Extension. |
2.4.1. LL Data PDU
An LL Data PDU is a Data Channel PDU that is used to send L2CAP data. The LLID field in the Header shall be set to either 0b01 or 0b10.
An LL Data PDU with the LLID field in the Header set to 0b01, and the Length field set to 0b00000000, is known as an Empty PDU. The Central’s Link Layer may send an Empty PDU to the Peripheral to allow the Peripheral to respond with any Data Physical Channel PDU, including an Empty PDU.
An LL Data PDU with the LLID field in the Header set to 0b10 shall not have the Length field set to 0 and should not have it set to less than 4.
Note
Note: If the Link Layer receives an HCI ACL Data Packet with Data_Total_Length equal to 0b00000000 and Packet_Boundary_Flag set to 0b00 (i.e., a start fragment), then the Link Layer cannot simply transmit the fragment over the air but, as this section requires, must instead combine it with one or more of the following continuation fragments to form a PDU with LLID set to 0b10 and non-zero length.
2.4.2. LL Control PDU
An LL Control PDU is a Data Physical Channel PDU that is used to control the Link Layer connection.
The Payload field of the LL Control PDU is shown in Figure 2.29.
An LL Control PDU shall not have the Length field set to 0b00000000.
The Opcode field identifies different types of LL Control PDU, as defined in Table 2.22.
The CtrData field in the LL Control PDU is specified by the Opcode field and is defined in the following subsections. For a given Opcode the length of the CtrData field is fixed.
Where the description of a field within the CtrData field gives a range of valid values or other restrictions on a value (e.g. that field X is less than field Y), all other values shall be reserved for future use. The range may be directly specified in the relevant subsection for the LL Control PDU or indirectly, possibly in a section referenced by that subsection (e.g. the range of the WinSize field in Section 2.4.2.1 is derived from the range of the transmitWindowSize value specified in Section 4.5.3).
If no range is specified for a field, then all values for that field are valid.
Except where explicitly stated otherwise, all fields within the CtrData field in an LL Control PDU that hold an integer shall be interpreted as unsigned.
Opcode | LL Control PDU Name |
|---|---|
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_PERIPHERAL_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 |
0x1F | LL_CIS_REQ |
0x20 | LL_CIS_RSP |
0x21 | LL_CIS_IND |
0x22 | LL_CIS_TERMINATE_IND |
0x23 | LL_POWER_CONTROL_REQ |
0x24 | LL_POWER_CONTROL_RSP |
0x25 | LL_POWER_CHANGE_IND |
0x26 | LL_SUBRATE_REQ |
0x27 | LL_SUBRATE_IND |
0x28 | LL_CHANNEL_REPORTING_IND |
0x29 | LL_CHANNEL_STATUS_IND |
0x2A | LL_PERIODIC_SYNC_WR_IND |
0x2B | LL_FEATURE_EXT_REQ |
0x2C | LL_FEATURE_EXT_RSP |
0x2D | LL_CS_SEC_RSP |
0x2E | LL_CS_CAPABILITIES_REQ |
0x2F | LL_CS_CAPABILITIES_RSP |
0x30 | LL_CS_CONFIG_REQ |
0x31 | LL_CS_CONFIG_RSP |
0x32 | LL_CS_REQ |
0x33 | LL_CS_RSP |
0x34 | LL_CS_IND |
0x35 | LL_CS_TERMINATE_REQ |
0x36 | LL_CS_FAE_REQ |
0x37 | LL_CS_FAE_RSP |
0x38 | LL_CS_CHANNEL_MAP_IND |
0x39 | LL_CS_SEC_REQ |
0x3A | LL_CS_TERMINATE_RSP |
0x3B | LL_FRAME_SPACE_REQ |
0x3C | LL_FRAME_SPACE_RSP |
0xF0 to 0xFB | Reserved for specification development purposes |
All other values | Reserved for future use |
If an LL Control PDU is received that is not supported or reserved for future use, the Link Layer shall respond with an LL_UNKNOWN_RSP PDU. The UnknownType field of the LL_UNKNOWN_RSP PDU shall be set to the value of the Opcode in the received PDU.
If an LL Control PDU is received with the wrong length or with invalid CtrData fields, the Link Layer may continue with the relevant Link Layer procedure with an implementation-specific interpretation of the data (e.g., if the PDU is too long it can ignore the extra data; if a field is out of range it can use the nearest permitted value). If it does not continue the procedure, it shall respond with an LL_UNKNOWN_RSP PDU or, if the relevant procedure allows it, an LL_REJECT_IND or LL_REJECT_EXT_IND PDU. The UnknownType field of the LL_UNKNOWN_RSP PDU or the RejectOpcode field of the LL_REJECT_EXT_IND PDU shall be set to the value of the Opcode in the received PDU.
2.4.2.1. LL_CONNECTION_UPDATE_IND
The format of the CtrData field is as shown in Figure 2.30.
The WinSize field shall be set to indicate the transmitWindowSize value, as defined in Section 4.5.3 in the following manner:
transmitWindowSize = WinSize × 1.25 ms.
The WinOffset field shall be set to indicate the transmitWindowOffset value, as defined in Section 4.5.3, in the following manner:
transmitWindowOffset = WinOffset × 1.25 ms.
The Interval field shall be set to indicate the connInterval value, as defined in Section 4.5.1, in the following manner:
connInterval = Interval × 1.25 ms.
The Latency field shall be set to indicate the connPeripheralLatency value, as defined by Section 4.5.1, in the following manner:
connPeripheralLatency = Latency.
The Timeout field shall be set to indicate the connSupervisionTimeout value, as defined by Section 4.5.2, in the following manner:
connSupervisionTimeout = Timeout × 10 ms.
The Instant field shall be set to indicate the instant described in Section 5.1.1.
2.4.2.2. LL_CHANNEL_MAP_IND
The format of the CtrData field is shown in Figure 2.31.
The ChM field shall contain the channel map indicating Used and Unused data channels. Every channel is represented with a bit positioned as per the data channel index defined by Section 1.4.1. The format of this field is identical to the ChM field in the CONNECT_IND PDU (see Section 2.3.3.1).
The Instant field shall be set to indicate the instant described in Section 5.1.2.
2.4.2.3. LL_TERMINATE_IND
The format of the CtrData field is shown in Figure 2.32.
The ErrorCode field shall be set to inform the remote device why the connection is about to be terminated. See [Vol 1] Part F, Controller Error Codes for details.
2.4.2.4. LL_ENC_REQ
The format of the CtrData field is shown in Figure 2.33.
The Rand field shall contain a random number that is provided by the Host and used with EDIV (see [Vol 3] Part H, Section 2.4.4).
The EDIV field shall contain the encrypted diversifier.
The SKD_C field shall contain the Central’s portion of the session key diversifier.
The IV_C field shall contain the Central’s portion of the initialization vector.
2.4.2.5. LL_ENC_RSP
The format of the CtrData field is shown in Figure 2.34.
The SKD_P field shall contain the Peripheral’s portion of the session key diversifier.
The IV_P field shall contain the Peripheral’s portion of the initialization vector.
2.4.2.6. LL_START_ENC_REQ
The LL_START_ENC_REQ PDU does not have a CtrData field.
2.4.2.7. LL_START_ENC_RSP
The LL_START_ENC_RSP PDU does not have a CtrData field.
2.4.2.8. LL_UNKNOWN_RSP
The format of the CtrData field is shown in Figure 2.35.
UnknownType shall contain the Opcode field value of the received LL Control PDU.
2.4.2.9. LL_FEATURE_REQ
The format of the CtrData field is shown in Figure 2.36.
FeatureSet shall contain the set of features supported by the Central’s Link Layer as specified in Section 4.6.
2.4.2.10. LL_FEATURE_RSP
The format of the CtrData field is shown in Figure 2.37.
FeatureSet[0] shall contain a set of features supported by the Link Layers of both the Central and Peripheral.
FeatureSet[1-7] shall contain a set of features supported by the Link Layer that transmits this PDU.
See Section 4.6 for the list of features.
2.4.2.11. LL_PAUSE_ENC_REQ
The LL_PAUSE_ENC_REQ packet does not have a CtrData field.
2.4.2.12. LL_PAUSE_ENC_RSP
The LL_PAUSE_ENC_RSP packet does not have a CtrData field.
2.4.2.13. LL_VERSION_IND
The format of the CtrData field is shown in Figure 2.38.
Version field shall contain the version of the Bluetooth Link Layer specification supported by the Controller (see Assigned Numbers).
Company_Identifier field shall contain the company identifier of the manufacturer of the Bluetooth Controller (see Assigned Numbers).
Subversion field shall contain a unique value for each implementation or revision of an implementation of the Bluetooth Controller.
Note
Note: A given value of 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.6) should be checked instead.
Note
Note: A larger value for Version does not necessarily indicate a higher version of the specification.
2.4.2.14. LL_REJECT_IND
The format of the CtrData field is shown in Figure 2.39.
ErrorCode shall contain the reason a request was rejected; see [Vol 1] Part F, Controller Error Codes.
2.4.2.15. LL_PERIPHERAL_FEATURE_REQ
The format of the CtrData field is shown in Figure 2.40.
FeatureSet shall contain the set of features supported by the Peripheral’s Link Layer as specified in Section 4.6.
2.4.2.16. LL_CONNECTION_PARAM_REQ
The format of the CtrData field is shown in Figure 2.41.
 |
The Interval_Min field shall be set to indicate the minimum value of connInterval, as defined in Section 4.5.1, in the following manner:
connInterval = Interval_Min × 1.25 ms.
The Interval_Max field shall be set to indicate the maximum value of connInterval, as defined in Section 4.5.1, in the following manner:
connInterval = Interval_Max × 1.25 ms.
The value shall not be less than the value of Interval_Min.
The Latency field shall be set to indicate the connPeripheralLatency value, as defined by Section 4.5.1, in the following manner:
connPeripheralLatency = Latency.
The Timeout field shall be set to indicate the connSupervisionTimeout value, as defined by Section 4.5.2, in the following manner:
connSupervisionTimeout = Timeout × 10 ms.
The PreferredPeriodicity field shall be set to indicate a value the connInterval is preferred to be a multiple of. PreferredPeriodicity is in units of 1.25 ms. E.g. if the PreferredPeriodicity is set to 100, it implies that connInterval is preferred to be any multiple of 125 ms. A value of zero means no preference. The PreferredPeriodicity shall be less than or equal to Interval_Max.
The ReferenceConnEventCount field shall be set to indicate the value of the connEventCounter relative to which all the valid Offset0 to Offset5 fields have been calculated.
Note
Note: The ReferenceConnEventCount field is independent of the Instant field in the LL_CONNECTION_UPDATE_IND PDU.
The Offset0, Offset1, Offset2, Offset3, Offset4, and Offset5 fields shall be set to indicate the possible values of the position of the anchor points of the LE connection with the updated connection parameters relative to the ReferenceConnEventCount. The Offset0 to Offset5 fields are in units of 1.25 ms and are in decreasing order of preference; that is, Offset0 is the most preferred value, followed by Offset1, and so on. Offset0 to Offset5 shall be less than Interval_Max. A value of 0xFFFF means not valid. Valid Offset0 to Offset5 fields shall contain unique values. Valid fields shall always be before invalid fields.
2.4.2.17. LL_CONNECTION_PARAM_RSP
The format of the LL_CONNECTION_PARAM_RSP PDU is identical to the format of the LL_CONNECTION_PARAM_REQ PDU (see Section 2.4.2.16).
2.4.2.18. LL_REJECT_EXT_IND
The format of the CtrData field is shown in Figure 2.42.
RejectOpcode shall contain the Opcode field value of the LL Control PDU being rejected.
ErrorCode shall contain the reason the LL Control PDU was being rejected. See [Vol 1] Part F, Controller Error Codes for a list of error codes and descriptions.
This PDU shall be issued only when the remote Link Layer supports the Extended Reject Indication Link Layer feature ( Section 4.6). Otherwise, the LL_REJECT_IND PDU ( Section 2.4.2.14) shall be issued instead.
2.4.2.19. LL_PING_REQ
The LL_PING_REQ PDU does not have a CtrData field.
2.4.2.20. LL_PING_RSP
The LL_PING_RSP PDU does not have a CtrData field.
2.4.2.21. LL_LENGTH_REQ and LL_LENGTH_RSP
The format of the CtrData field for both the LL_LENGTH_REQ and LL_LENGTH_RSP PDUs is shown in Figure 2.43.
MaxRxOctets shall be set to the sender’s connMaxRxOctets value, as defined in Section 4.5.10. The MaxRxOctets field shall have a value not less than 27 octets.
MaxRxTime shall be set to the sender’s connMaxRxTime value, as defined in Section 4.5.10. The MaxRxTime field shall have a value not less than 328 μs.
MaxTxOctets shall be set to the sender’s connMaxTxOctets value, as defined in Section 4.5.10. The MaxTxOctets field shall have a value not less than 27 octets.
MaxTxTime shall be set to the sender’s connMaxTxTime value, as defined in Section 4.5.10. The MaxTxTime field shall have a value not less than 328 μs.
2.4.2.22. LL_PHY_REQ and LL_PHY_RSP
The format of the CtrData field for both the LL_PHY_REQ and LL_PHY_RSP PDUs is shown in Figure 2.44.
TX_PHYS shall be set to indicate the transmitter PHYs that the sender prefers to use.
RX_PHYS shall be set to indicate the receiver PHYs that the sender prefers to use.
These fields each consist of 8 bits; at least one bit in each field shall be set to 1. The bits that are set indicate which PHY or PHYs the sender prefers to use.
Bit number | Meaning |
|---|---|
0 | LE 1M PHY |
1 | LE 2M PHY |
2 | LE Coded PHY |
3 | LE 2M 2BT PHY (for Channel Sounding only; otherwise RFU) |
4–7 | Reserved for future use |
2.4.2.23. LL_PHY_UPDATE_IND
The format of the CtrData field is shown in