Bluetooth Core Specification

Enhanced power control shall only be used when both devices support the enhanced power control LMP feature. Legacy power control shall not be used when both devices support the enhanced power control LMP feature.

4.1.3.1.2. Responding to enhanced power control requests

When a device receives an LMP_POWER_CONTROL_REQ PDU with the Power_Adj_Req parameter set to "increment one step," all supported modulations that are not at the maximum level shall be increased one step.

When a device receives an LMP_POWER_CONTROL_REQ PDU with the Power_Adj_Req parameter set to "decrement one step", all supported modulations that are not at the minimum level shall be decreased one step.

Implementations shall not violate the relative power level between modulations (see [Vol 2] Part A, Section 5.2).

When a device receives an LMP_POWER_CONTROL_REQ PDU with the Power_Adj_Req parameter set to "increment power to maximum value", each supported modulation mode shall be set to its maximum power level.

Note

Note: See [Vol 2] Part A, Section 5.2 for requirements on the relative power levels of different modulation modes.

The responding LM shall send the LMP_POWER_CONTROL_RES PDU to indicate the status for every modulation. The Power_Adj_Rsp parameter has three 2-bit fields indicating the status for each modulation mode: GFSK, π/4-DQPSK and 8DPSK. Each 2-bit field shall be set to one of the following values: not supported, changed one step, max power, or min power. The changed one step value shall only be used when the power level for that modulation mode has not reached the minimum or maximum level.

The not supported value shall be used for each unsupported modulation type.

The responder shall transmit the LMP_POWER_CONTROL_RES PDU at the new transmit power level and shall not change its power level until requested by the remote device by a subsequent LMP_POWER_CONTROL_REQ PDU.

Sequence 5: A device responds to a power control request

Prior to enabling AFH the Central LM shall pause traffic on the ACL-U logical link (see [Vol 2] Part B, Section 5.3.1). The Central shall then enable AFH on a physical link by sending the LMP_SET_AFH PDU with AFH_Mode set to enabled, the AFH_Channel_Map parameter containing the set of used and unused channels, and an AFH_instant. The LM shall not calculate the AFH instant until after traffic on the ACL-U logical link has been stopped. The Central considers the physical link to have entered AFH-enabled operation once the Baseband acknowledgment has been received and the AFH_Instant has passed. Once the Baseband acknowledgment has been received the Central shall restart transmission on the ACL-U logical link.

Sequence 6: Central enables AFH

Prior to disabling AFH the Central LM shall pause traffic on the ACL-U logical link ([Vol 2] Part B, Section 5.3.1). The Central shall then disable AFH operation on a physical link by sending the LMP_SET_AFH PDU with AFH_mode set to disabled and an AFH_Instant. The AFH_Channel_Map parameter is not valid when AFH_Mode is disabled. The LM shall not calculate the AFH instant until after traffic on the ACL-U logical link has been stopped. The Central considers the physical link to have entered AFH-disabled operation once the Baseband acknowledgment has been received and the AFH_Instant has passed. Once the Baseband acknowledgment has been received the Central shall restart transmission on the ACL-U logical link.

Sequence 7: Central disables AFH

A Central shall update the AFH parameters on a physical link by sending the LMP_SET_AFH PDU with AFH_Mode set to enabled, an AFH_Instant and a new AFH_Channel_Map. The Central shall consider the Peripheral to have the updated AFH parameters once the Baseband acknowledgment has been received and the AFH_Instant has passed.

Sequence 8: Central updates AFH

A Peripheral in Hold mode or Sniff mode shall retain the AFH_Mode and AFH_Channel_Map it was using prior to entering those modes. A Central may change the AFH_Mode while a Peripheral is in Sniff mode.

A Central that receives a request from an AFH-enabled Peripheral to enter Hold mode or Sniff mode and decides to operate the Peripheral using a different hop sequence shall respond with an LMP_SET_AFH PDU specifying the new hop sequence.

The Central continues with the LMP signaling, for Hold or Sniff initiation, once the Baseband acknowledgment for the LMP_SET_AFH PDU has been received. Optionally, the Central may delay the continuation of this LMP signaling until after the instant. An AFH capable Peripheral shall support both of these cases.

A Central that receives a request from an AFH-enabled Peripheral to enter Hold mode or Sniff mode and decides not to change the Peripheral's hop sequence shall respond exactly as it would do without AFH. In this case, AFH operation has no effect on the LMP signaling.

A Central enables Peripheral channel classification reporting by sending the LMP_CHANNEL_CLASSIFICATION_REQ PDU with the AFH_reporting_mode parameter set to enabled.

When a Peripheral has had classification reporting enabled by the Central it shall send the LMP_CHANNEL_­CLASSIFICATION PDU according to the information in the latest LMP_CHANNEL_­CLASSIFICATION_­REQ PDU. The LMP_CHANNEL_­CLASSIFICATION PDU shall not be sent if there has been no change in the Peripheral’s channel classification.

A Central disables Peripheral channel classification reporting by sending the LMP_CHANNEL_CLASSIFICATION_REQ PDU with the AFH_reporting_mode parameter set to disabled.

Sequence 9: Channel classification reporting

The Central notifies the Peripheral of the new poll interval and N_BC by sending the LMP_QUALITY_OF_SERVICE PDU. The Peripheral cannot reject the notification.

Sequence 13: Central notifies Peripheral of quality of service

Either the Central or the Peripheral may request a new poll interval and N_BC by sending an LMP_QUALITY_­OF_­SERVICE_­REQ PDU. The parameter N_BC is meaningful only when it is sent by a Central to a Peripheral. For transmission of LMP_QUALITY_OF_SERVICE_REQ PDUs from a Peripheral, this parameter shall be ignored by the Central. The request can be accepted or rejected. This allows the Central and Peripheral to dynamically negotiate the quality of service as needed.

The selected poll interval by the Peripheral shall be less than or equal to the specified Access Latency for the outgoing traffic of the ACL link (see L2CAP Definition: Quality of Service (QoS) option [Vol 3] Part A, Section 5.3).

Sequence 14: Device accepts new quality of service

Sequence 15: Device rejects new quality of service

This procedure is initiated from device A and negotiates the paging scheme used when device A pages device B. Device A proposes a paging scheme including the parameters for this scheme and device B can accept or reject. On rejection the old setting shall not be changed. A request to switch to a reserved paging scheme shall be rejected.

Sequence 16: Negotiation for Page mode

This procedure is initiated from device A and negotiates the paging scheme and paging scheme settings used when device B pages device A. Device A proposes a paging scheme and paging scheme settings and device B may accept or reject. On reject the old setting is not changed. A request specifying the mandatory scheme shall be accepted. A request to switch to a reserved scheme shall be rejected. This procedure should be used when device A changes its paging scheme settings. A Peripheral should also send this message to the Central after connection establishment, to inform the Central of the Peripheral's current paging scheme and paging scheme settings.

Sequence 17: Negotiation for Page Scan mode

The LMP_ENCAPSULATED_HEADER PDU shall be sent by the initiating device when it needs to send an encapsulated PDU. This PDU shall be either accepted or rejected using the LMP_ACCEPTED or LMP_NOT_ACCEPTED PDUs. If the major and minor types are not supported the PDU shall be rejected with Error_Code Unsupported LMP Parameter Value (0x20). If the LMP_ENCAPSULATED_HEADER PDU is accepted, then one or more LMP_ENCAPSULATED_PAYLOAD PDUs will be sent with the encapsulated data sent in sequence, 16 octets at a time, or if this is last packet, the correct number of octets and then zero padded.

Each LMP_ENCAPSULATED_PAYLOAD PDU shall be accepted or rejected. If the LMP_ENCAPSULATED_HEADER PDU is rejected, then the opcode in the LMP_NOT_ACCEPTED PDU shall be the opcode for the LMP_ENCAPSULATED_HEADER and not the Encap_Major_Type or Encap_Minor_Type. If the LMP_ENCAPSULATED_PAYLOAD PDU is rejected, then the opcode in the LMP_NOT_ACCEPTED PDU shall be the opcode for the LMP_ENCAPSULATED_PAYLOAD.

A responding device may reject the final LMP_ENCAPSULATED_PAYLOAD PDU after accepting the LMP_ENCAPSULATED_HEADER PDU. This is so that the link manager can still reject an encapsulated message after all the data has been received.

Sequence 23: Sending an encapsulated PDU

Between sending an LMP_ENCAPSULATED_HEADER PDU and an LMP_ENCAPSULATED_PAYLOAD PDU, or between each of the LMP_ENCAPSULATED_PAYLOAD PDUs, either device shall be able to send the following LMP PDUs without causing a "different transaction collision" error.

The coarse clock adjustment procedure shall only be used if all connected Peripherals declare support for the Coarse Clock Adjustment feature.

For all devices that may use Coarse Clock Adjustment Recovery Mode (see [Vol 2] Part B, Section 8.6.10.2), the RF channel indices used for the Synchronization Train (see [Vol 2] Part B, Section 2.6.4.8) shall be marked as unused in the AFH_Channel_Map for all logical links.

The Central may use the Clk_Adj_Period parameter from one or more Peripherals, in addition to other scheduling considerations, to select an optimal value of Clk_Adj_Slots.

The Central selects the parameters of the coarse clock adjustment. Some parameters shall remain the same for every LMP_CLK_ADJ PDU associated with a given adjustment. These are the number of slots (Clk_Adj_Slots) between 0 and 255, an offset within a slot (Clk_Adj_Offset) between ­­–624 µs and 624 µs, a coarse clock adjustment instant (Clk_Adj_Instant), which is specified in the old time domain before the instant, and an identifier for the instant (Clk_Adj_ID). The Clk_Adj_Instant shall be at least 12 slots in the future and no more than 12 hours away. The Clk_Adj_ID shall be different for any two adjacent adjustments and for any two adjustments whose instants are closer together in time than the longest Link Supervision Timeout period for any Peripheral. Each LMP_CLK_ADJ PDU also contains the value of CLK when it is transmitted (Clk_Adj_Clk) and a flag Clk_Adj_Mode, which shall be set to Before Instant if the LMP_CLK_ADJ PDU is sent before the instant or to After Instant if the LMP_CLK_ADJ PDU is sent on or after the instant.

To initiate the coarse adjustment, the Central starts broadcasting the LMP_CLK_ADJ PDU using the APB-C logical link and, unless all Peripherals have acknowledged, it should broadcast the LMP_CLK_ADJ PDU at least 6 times before the adjustment instant. The Central shall continue to broadcast the LMP_CLK_ADJ PDU until all Peripherals have acknowledged the adjustment with an LMP_CLK_ADJ_ACK PDU or the Central has left Coarse Clock Adjustment Recovery Mode.

The Central shall not initiate a coarse clock adjustment if there are any transactions outstanding that involve LMP PDUs containing an instant or timing control flags including, but not limited to: role switch, adaptive frequency hopping, SCO, eSCO, sniff, sniff subrating, hold, and encryption pause and resume.

The Central shall not initiate another sequence containing an instant or timing control flags before an outstanding clock adjustment instant has been reached, while waiting for CLK_adj_dragTO to expire (see [Vol 2] Part B, Appendix B), or while in Coarse Clock Adjustment Recovery Mode (see [Vol 2] Part B, Section 8.6.10.2); however the latter may be terminated by the Central in order to initiate the request. If a request to initiate such a sequence is received before an outstanding clock adjustment instant is reached or CLK_adj_dragTO has been cancelled or has expired, the request shall be rejected with the Error_Code Different Transaction Collision (0x2A).

A Peripheral shall discard and not acknowledge an LMP_CLK_ADJ PDU with a value of Clk_Adj_ID that is the same as that in the most recently received LMP_CLK_ADJ PDU, if any, and any LMP_CLK_ADJ PDU with any parameters outside the valid range (see Section 5.2).

On receipt of an LMP_CLK_ADJ PDU that passes these checks, the Peripheral shall reply with an LMP_CLK_ADJ_ACK PDU (on the ACL-C logical link) containing the same value of Clk_Adj_ID as in the LMP_CLK_ADJ PDU and shall change the value of peripheral_clock_offset, if not already performed, as described in [Vol 2] Part B, Section 8.6.10.1, either at the adjustment instant or, if that has passed, immediately.

Sequence 25: Central initiates a coarse clock adjustment

The Peripheral may request a coarse adjustment of the piconet clock by sending the LMP_CLK_ADJ_REQ PDU to the Central. The LMP_CLK_ADJ_REQ PDU contains three parameters: Clk_Adj_Offset, Clk_Adj_Slots, and Clk_Adj_Period. The parameters Clk_Adj_Offset and Clk_Adj_Slots have the same meaning as in the LMP_CLK_ADJ PDU and Clk_Adj_Slots or Clk_Adj_Offset shall be non-zero. If non-zero, the parameter Clk_Adj_Period is an indication to the Central that the request is for any of a set of possible adjustments, all of which are equally acceptable to the Peripheral. These adjustments are those where the number of slots is equal to Clk_Adj_Slots + N × Clk_Adj_Period, where N is zero or a positive integer, and the offset within a slot equals Clk_Adj_Offset. For example, if Clk_Adj_Slots is 18 and Clk_Adj_Period is 48, then the acceptable adjustments are 18, 66, 114, 162, and 210 slots. A value of zero for Clk_Adj_Period indicates that an adjustment of any number of slots is equally acceptable to the Peripheral (that is, the Central may ignore the value of Clk_Adj_Slots). A request for a coarse adjustment shall also update the Central’s local record of Clk_Adj_Period for the Peripheral.

The Peripheral may indicate its preferred Clk_Adj_Period to the Central without requesting a clock adjustment. In this case it shall set Clk_Adj_­Slots and Clk_Adj_­Offset to zero. Upon receiving an LMP_CLK_­ADJ_­REQ PDU with Clk_Adj_­Slots and Clk_Adj_­Offset set to zero, the Central shall respond with an LMP_ACCEPTED_­EXT PDU and update its local record of Clk_Adj_­Period for the Peripheral, but shall not initialize any clock adjustment. The Central is not required to honor a Peripheral’s preferred Clk_Adj_­Period when making coarse clock adjustments.

The Central may accept the coarse clock adjustment request from the Peripheral by sending an LMP_ACCEPTED_EXT PDU. This indicates that the Central intends to carry out a coarse clock adjustment with the requested value of Clk_Adj_Offset; however, the value of Clk_Adj_Slots may be different to that requested and might not follow the Clk_Adj_Period parameter.

Sequence 26: Central accepts Peripheral request for a coarse clock adjustment

The Central may reject the coarse clock adjustment request from the Peripheral by sending an LMP_NOT_ACCEPTED_EXT PDU with the Error_Code Command Disallowed (0x0C) (see [Vol 1] Part F, Section 2.12). The Central's decision not to follow the Clk_Adj_Slots or Clk_Adj_Period parameters does not constitute a rejection.

The Central may implement the coarse clock adjustment request from the Peripheral by carrying out clock dragging (see [Vol 2] Part B, Section 8.6.10.3) to achieve the requested clock adjustment. If so, it shall send an LMP_NOT_­ACCEPTED_­EXT PDU with the Error_Code Coarse Clock Adjustment Rejected but Will Try to Adjust Using Clock Dragging (0x40) (see [Vol 1] Part F, Section 2.61).

Sequence 27: Central rejects a Peripheral request for coarse clock adjustment

Either the Central or the Peripheral may initiate the SAM type 0 submap configuration sequence by sending an LMP_SAM_SET_TYPE0 PDU to the responder. Both devices shall save the SAM parameters contained in this PDU. Update_Mode shall not be set to 0 if the active SAM slot map contains a type 0 submap. If the responder can accept the parameters, it shall send an LMP_ACCEPTED_­EXT PDU. If the Update_Mode parameter is set to 0 and the active SAM slot map contains a type 0 submap, it shall send an LMP_NOT_­ACCEPTED_­EXT PDU with the Error_Code Invalid LMP Parameters (0x1E).

Sequence 28: SAM type 0 submap configuration sequence

Either the Central or the Peripheral may initiate the SAM slot map define sequence by sending an LMP_SAM_DEFINE_MAP PDU. If N_{SAM_SM} is set to zero, the map shall be deleted. The SAM_Index parameter shall not be 0xFF or that of the currently selected map. The slot map may only contain a type 0 submap if the LMP_SAM_SET_TYPE0 sequence has already been used to define the type 0 submap. If the responder can accept the parameters, it shall send an LMP_ACCEPTED_EXT PDU. If a SAM type 0 submap is used in an LMP_SAM_DEFINE_MAP PDU without successfully completing the LMP_SAM_SET_TYPE0 sequence in advance, it shall send an LMP_NOT_­ACCEPTED_­EXT PDU with the Error_Code Type0 Submap Not Defined (0x41).

Sequence 29: SAM slot map define sequence

Either the Central or the Peripheral may initiate the SAM switch sequence by sending an LMP_SAM_SWITCH PDU to the responder. There are two initialization procedures to prevent problems caused by clock wrap-around; see [Vol 2] Part B, Section 8.6.11.1 for details. The SAM_Index shall refer to a SAM slot map that is currently valid (the special value 0xFF is always valid). If the responder can accept the parameters, it shall send an LMP_ACCEPTED_­EXT PDU. If the SAM_Index is invalid (e.g., the associated SAM_Index configuration has not yet been defined with LMP_SAM_­DEFINE_­MAP_­SEQUENCE), it shall send an LMP_NOT_­ACCEPTED_­EXT PDU with the Error_Code Invalid LMP Parameters (0x1E).

Each Controller shall notify its Host of a successful SAM switch sequence specifying a different SAM_Index to that currently selected (it may, but need not, notify the Host if the sequence specifies the current map). The currently selected map remains in effect if the change is not accepted.

Sequence 30: SAM switch sequence

SAM slot map changes do not affect the transmission of a multi-slot packet that spans the change instant. In the case of a Central-to-Peripheral packet, the new map can mean that the Peripheral may choose not to reply to the packet.

The Central and Peripheral shall disable SAM at the role switch instant. If the role switch fails, both devices shall resume using the SAM parameters prior to the role switch instant

SAM mode may be reconfigured and re-enabled after the successful completion of a role switch using the new piconet clock.

If sniff negotiation is requested when SAM is already enabled, the device should align sniff with SAM by choosing the sniff anchor point to be an available Central-to-Peripheral slot and the sniff period to be an integer multiple of T_SAM. If such alignment is not possible, the sniff configuration shall take precedence, even if this requires a device to transmit or receive on a slot marked as unavailable by SAM. The SAM slot maps shall be reinstated when devices exit Sniff mode.

If the claimant has a link key associated with the verifier, it shall calculate the response and sends it to the verifier with LMP_SRES. The verifier checks the response. If the response is not correct, the verifier may end the connection by sending an LMP_DETACH PDU with the Error_Code Authentication Failure (0x05), see Section 4.1.2.

Sequence 31: Authentication. Claimant has link key.

Upon reception of an LMP_AU_RAND, an LM shall reply with LMP_SRES before initiating its own authentication.

If the claimant does not have a link key associated with the verifier it shall send an LMP_NOT_­ACCEPTED PDU with the Error_Code PIN or Key Missing (0x06) after receiving an LMP_AU_­RAND PDU ([Vol 1] Part F, Section 2.6).

Sequence 32: Authentication fails. Claimant has no link key.

The scheme described in [Vol 2] Part H, Section 5.1 shall be applied when an authentication fails.

Both the Central and Peripheral LM act as verifier and claimant. The initiator is the device that sends the LMP_AU_RAND PDU first.

The initiator sends an LMP_AU_RAND PDU to the responder. If the responder has a link key associated with the initiator, it shall respond with an LMP_AU_RAND PDU. The initiator and responder shall calculate the response. The Peripheral responds first with an LMP_SRES PDU containing SRES_P. The Central shall then respond with an LMP_SRES PDU containing SRES_C. The Central shall verify that the SRES_P sent by the Peripheral matches the SRES_P calculated by the Central. The Peripheral shall verify that the SRES_C sent by the Central matches the SRES_C calculated by the Peripheral. If the response is not correct, then the device receiving the wrong SRES value may end the connection by sending an LMP_DETACH PDU with the Error_Code Authentication Failure (0x05) (see Section 4.1.2).

Sequence 33: Secure authentication. Responder has link key. Initiator is Central.

Sequence 34: Secure authentication. Responder has link key. Initiator is Peripheral.

In the case where the Central and Peripheral both initiate the secure authentication sequence, the Central shall reject the Peripheral’s LMP_AU_RAND PDU with an LMP_NOT_ACCEPTED PDU with the Error_Code LMP Error Transaction Collision / LL Procedure Collision (0x23). The Peripheral shall send another LMP_AU_RAND PDU with transaction ID set to 0 (Central).

If the responder accepts the pairing and has a variable PIN, then it shall reply with an LMP_ACCEPTED PDU. Both devices shall then calculate K_init based on the BD_ADDR of the responder and the procedure continues with creation of the link key; see Section 4.2.2.4.

Sequence 35: Pairing accepted. Responder has a variable PIN. Initiator has a variable or fixed PIN.

If the responder accepts the pairing and has a fixed PIN, then it shall generate a new random number and send it back in an LMP_IN_RAND PDU. If the initiator has a variable PIN, then it shall accept the LMP_IN_RAND PDU and shall respond with an LMP_ACCEPTED PDU. Both sides shall then calculate K_init based on the last IN_RAND and the BD_ADDR of the initiator. The procedure continues with creation of the link key; see Section 4.2.2.4.

Sequence 36: Responder has a fixed PIN and initiator has a variable PIN

If the responder has a fixed PIN and the initiator also has a fixed PIN, then the second LMP_IN_RAND shall be rejected by the initiator sending an LMP_NOT_ACCEPTED PDU with the Error_Code Pairing not Allowed (0x18).

Sequence 37: Both devices have a fixed PIN

If the responder rejects pairing (e.g., because the user has disabled pairing on the device) it shall send an LMP_NOT_ACCEPTED PDU with the Error_Code Pairing not Allowed (0x18) after receiving an LMP_IN_RAND PDU.

Sequence 38: Responder rejects pairing

When K_init is calculated in both devices the link key shall be created. This link key will be used in the authentication between the two devices for all subsequent connections until it is changed; see Section 4.2.3 and Section 4.2.4. The link key created in the pairing procedure will be a combination key; both devices send an LMP_COMB_KEY PDU and the link key shall be calculated as described in [Vol 2] Part H, Section 3.2.

The content of the LMP_COMB_KEY PDU is LK_RAND bitwise XORed with K_init. Any device configured to use a combination key shall store the link key.

When the new link key has been created mutual authentication shall be performed to confirm that the same link key has been created in both devices. After mutual authentication, if encryption is enabled, the initiating device shall pause and immediately resume encryption to produce a new encryption key.

Note: This will cause a new encryption key to be generated from the ACO created during the mutual authentication process and, when E0 encryption is used, the random number sent in the LMP_START_ENCRYPTION_REQ PDU which occurs in response to the resumption of encryption.

Sequence 39: Creation of the link key

If, in sequence 39, either device sends an LMP_UNIT_KEY PDU, the other device shall respond with an LMP_NOT_ACCEPTED PDU with the Error_Code set to Pairing with Unit Key Not Supported (0x29).

When the authentication after creation of the link key fails because of an incorrect Authentication_Rsp, the scheme described in [Vol 2] Part H, Section 5.1 shall be applied.

The Central starts by creating the temporary link key K_temp as specified in [Vol 2] Part H (EQ 4). Then the Central shall generate a random number, RAND, and shall send it to the Peripheral in an LMP_TEMP_RAND PDU. Both sides then calculate an overlay denoted OVL as OVL= E₂₂ (current link key, RAND, 16). The Central shall then send K_temp protected by XORing with OVL to the Peripheral in an LMP_TEMP_KEY PDU. The Peripheral calculates K_temp, based on OVL, that becomes the current link key. It shall be the current link key until the devices fall back to the semi-permanent link key, see Section 4.2.4.2.

Sequence 41: Change to a temporary link key

All sequences described in Section 4.2.4.1, including the mutual authentication after K_temp has been created, shall form a single transaction. The transaction ID shall be set to 0.

When the devices have changed to the temporary key, a mutual authentication shall be made to confirm that the same link key has been created in both devices. The first authentication in the mutual authentication shall be performed with the Central as verifier. When finalized an authentication in the reverse direction is performed.

Should the mutual authentication fail at either side, the LM of the verifier should start the detach procedure. This will allow the procedure to succeed even though one of the devices may be erroneous.

After the current link key has been changed to K_temp, this change can be undone and the semi-permanent link key becomes the current link key again. If encryption is used on the link, the procedure to go back to the semi-permanent link key shall be immediately followed by the Central stopping encryption using the procedure described in Section 4.2.5.4. Encryption may be restarted by the Central according to the procedures in Section 4.2.5.3. This is to assure that encryption with encryption parameters known by other devices in the piconet is not used when the semi-permanent link key is the current link key.

Sequence 42: Link key changed to the semi-permanent link key

The Central and the Peripheral must agree upon whether to use encryption (Encryption_Mode=1 in LMP_ENCRYPTION_MODE_REQ) or not (Encryption_Mode=0). If the semi-permanent key is used, encryption shall only apply to point-to-point packets. If the temporary link key is used, encryption shall apply to both point-to-point packets and broadcast packets. If Central and Peripheral agree on the encryption mode, the Central continues to give more detailed information about the encryption.

If a device receives an LMP_ENCRYPTION_MODE_REQ with an Encryption_Mode value of 2 then the device should treat it as if the Encryption_Mode value was 1.

If both devices support both the Secure Connections (Controller Support) and Secure Connections (Host Support) features, setting the Encryption_Mode to 0 shall not be allowed. If a device receives an LMP_ENCRYPTION_MODE_REQ PDU with Encryption_Mode set to 0, it shall respond with an LMP_NOT_ACCEPTED PDU with Error_Code Encryption Mode Not Allowed (0x25).

The initiating LM shall pause traffic on the ACL-U logical link (see [Vol 2] Part B, Section 5.3.1). The initiating device shall then send the LMP_ENCRYPTION_MODE_REQ PDU. If the responding device accepts the change in encryption mode then it shall complete the transmission of the current packet on the ACL logical transport and shall then suspend transmission on the ACL-U logical link. The responding device shall then send the LMP_ACCEPTED PDU.

ACL-U logical link traffic shall only be resumed after the attempt to encrypt or decrypt the logical transport is completed, i.e. at the end of Sequence 43 (on failure), 45, 46, or 47.

Sequence 43: Negotiation for encryption mode

After a device has sent an LMP_ENCRYPTION_MODE_REQ PDU it shall not send an LMP_AU_RAND PDU before encryption is started. After a device has received an LMP_ENCRYPTION_MODE_REQ PDU and sent an LMP_ACCEPTED PDU it shall not send an LMP_AU_RAND PDU before encryption is started. If an LMP_AU_RAND PDU is sent violating these rules, the claimant shall respond with an LMP_NOT_­ACCEPTED PDU with the Error_Code LMP PDU Not Allowed (0x24). This assures that devices will not have different ACOs when they calculate the encryption key. If the encryption mode is not accepted or the encryption key size negotiation results in disagreement the devices may send an LMP_AU_RAND PDU again.

The Central sends an LMP_ENCRYPTION_KEY_SIZE_REQ PDU including the suggested key size L_sug_c, that shall initially be equal to L_max_c. If L_min_p ≤ L_sug_c ≤ L_max_p, the Peripheral shall respond with an LMP_ACCEPTED PDU and L_sug_c shall be used as the key size.

If L_sug_c > L_max_p, the Peripheral shall send back an LMP_ENCRYPTION_­KEY_­SIZE_­REQ PDU including the Peripheral’s suggested key size L_sug_p set to L_max_p. If L_sug_c < L_min_p, the Peripheral shall send back an LMP_NOT_ACCEPTED PDU with the Error_Code Unsupported LMP Parameter Value (0x20) and the devices shall not communicate using encryption.

If the Peripheral sends back an LMP_ENCRYPTION_KEY_SIZE_REQ PDU, then the Central performs the corresponding test on the Peripheral’s suggestion. This procedure is repeated until a key size agreement is reached or it becomes clear that no such agreement can be reached. If an agreement is reached a device sends an LMP_ACCEPTED PDU and the key size in the last LMP_ENCRYPTION_KEY_SIZE_REQ PDU shall be used.

If a key size is agreed, encryption is then started; see Section 4.2.5.3. If an agreement is not reached a device sends an LMP_NOT_ACCEPTED PDU with the Error_Code Unsupported LMP Parameter Value (0x20) and the devices shall not communicate using encryption.

L_max_c and L_max_p shall be set to at least 7 octets. L_min_c and L_min_p should be set to at least 7 octets. The values of L_max_c, L_min_c, L_max_p, and L_min_p shall not change during an ACL connection between the Central and the Peripheral.

Sequence 44: Encryption key size negotiation successful

Sequence 45: Encryption key size negotiation failed

To start encryption, the Central issues the random number EN_RAND and calculates the encryption key. See [Vol 2] Part H, Section 3.2.5. The random number shall be the same for all Peripherals in the piconet when broadcast encryption is used. The Central then sends an LMP_START_ENCRYPTION_REQ PDU, that includes EN_RAND.

The Peripheral shall calculate the encryption key when this message is received and shall acknowledge with an LMP_ACCEPTED PDU. For E0, the encryption key shall be calculated using the E3 algorithm (see [Vol 2] Part H, Section 6.4). For AES-CCM, the encryption key shall be calculated using the h3 algorithm (see [Vol 2] Part H, Section 7.7.6).

If encryption has been paused, then this sequence shall not be used.

Sequence 46: Start encryption

Starting encryption shall be performed in three steps:

Between step 1 and step 2, Central-to-Peripheral transmission is possible. This is when an LMP_START_ENCRYPTION_REQ PDU is transmitted. Step 2 is triggered when the Peripheral receives this message. Between step 2 and step 3, Peripheral-to-Central transmission is possible. This is when an LMP_ACCEPTED PDU is transmitted. Step 3 is triggered when the Central receives this message.

To stop encryption a device shall send an LMP_ENCRYPTION_MODE_REQ PDU with the parameter Encryption_Mode equal to 0 (no encryption). The other device responds with an LMP_ACCEPTED PDU or an LMP_NOT_ACCEPTED PDU (the procedure is described in Sequence 43 in Section 4.2.5.1). If accepted, encryption shall be stopped by the Central sending an LMP_STOP_ENCRYPTION_REQ PDU and the Peripheral shall respond with an LMP_ACCEPTED PDU according to Sequence 47.

If encryption has been paused, then this sequence shall not be used.

Sequence 47: Stop encryption

Stopping encryption shall be performed in three steps, similar to the procedure for starting encryption.

Between step 1 and step 2 Central to Peripheral transmission is possible. This is when an LMP_STOP_ENCRYPTION_REQ PDU is transmitted. Step 2 is triggered when the Peripheral receives this message. Between step 2 and step 3 Peripheral to Central transmission is possible. This is when an LMP_ACCEPTED PDU is transmitted. Step 3 is triggered when the Central receives this message.

For E0 encryption:

For AES-CCM encryption:

If the responding device is a Central, then the Central shall finalize the transmission of the current ACL-U data packet and then respond with an LMP_STOP_ENCRYPTION_REQ PDU to the Peripheral.

If the responding device is a Peripheral, then the Peripheral shall finalize the transmission of the current ACL-U data packet and then respond with an LMP_PAUSE_ENCRYPTION_REQ PDU. The Central shall respond to the LMP_PAUSE_ENCRYPTION_REQ PDU with an LMP_STOP_ENCRYPTION_REQ PDU to the Peripheral.

When the Peripheral receives the LMP_STOP_ENCRYPTION_REQ PDU it shall respond with an LMP_ACCEPTED PDU.

Sequence 48: Central-initiated pausing of encryption (E0)

Sequence 49: Central-initiated pausing of encryption (AES-CCM)

Sequence 50: Peripheral-initiated pausing of encryption (E0)

Sequence 51: Peripheral-initiated pausing of encryption (AES-CCM)

For E0 encryption:

For AES-CCM encryption:

Pausing encryption shall be performed in three steps, similar to the procedure for stopping encryption.

Between step 1 and step 2 Central-to-Peripheral transmission is possible. This is when the LMP_STOP_ENCRYPTION_REQ PDU is transmitted from the Central to the Peripheral. Step 2 is triggered when the Peripheral receives this message. Between step 2 and step 3 Peripheral-to-Central transmission is possible. This is when an LMP_ACCEPTED PDU is transmitted. Step 3 is triggered when the Central receives this message.

Sequence 52: Initiating Central LM resumes encryption

Sequence 53: Initiating Peripheral LM resumes encryption

For E0 encryption:

For AES-CCM encryption:

The LMP_RESUME_­ENCRYPTION_­REQ PDU and the LMP_START_ENCRYPTION_REQ PDU shall not be rejected.

Resuming encryption shall be performed in three steps, similar to the procedure for starting encryption:

Between step 1 and step 2, Central-to-Peripheral transmission is possible. This is when the LMP_START_ENCRYPTION_REQ PDU is transmitted from the Central. Step 2 is triggered when the Peripheral receives this message. Between step 2 and step 3, Peripheral-to-Central transmission is possible. This is when an LMP_ACCEPTED PDU is transmitted. Step 3 is triggered when the Central receives this message.

Once encryption has been resumed, the device shall restart ACL-U traffic.

If the encryption key or encryption random number need to be changed, or if the current link key needs to be changed according to the procedures in Section 4.2.3 and Section 4.2.4, encryption shall be paused and resumed after completion, using the procedures in Section 4.2.5.5 and Section 4.2.5.6, for the new parameters to be valid. If the Pause Encryption feature is not supported by both devices, encryption shall be stopped and re-started after completion, using the procedures in Section 4.2.5.3 and Section 4.2.5.4, for the new parameters to be valid.

When E0 encryption is used, the Link Manager shall refresh the encryption key within 2²⁸ ticks of the Bluetooth clock from the previous start or resume of encryption. When AES-CCM encryption is used, the Link Manager shall refresh the encryption key before either the PayloadCounter or dayCounter roll over. To refresh the encryption key, the Link Manager shall Pause encryption using the procedure in Section 4.2.5.5 and immediately Resume encryption using the procedure in Section 4.2.5.6.

If the encryption key has not been refreshed before the rollover event, the link shall be terminated immediately.

The Link Managers shall use the local and remote IO capabilities to determine which association model shall be used.

If Simple_Pairing_Mode is set to enabled, the Initiator shall request the IO capabilities from the Host. The initiator shall send an LMP_IO_CAPABILITY_REQ PDU to the Responder. If Simple_Pairing_Mode is set to enabled on the responding device, it shall reply with an LMP_IO_CAPABILITY_RES PDU containing its IO capabilities description.

The OOB_Auth_Data parameter shall be set as shown in Table 4.24.

Sequence 55: IO capability exchange

4.2.7.1.1. IO capability exchange transaction collision and resolution

If both Link Managers attempt to become the initiator of the IO capability exchange, the Central’s Link Manager shall send an LMP_NOT_ACCEPTED_EXT PDU with Error_Code LMP Error Transaction Collision / LL Procedure Collision (0x23). The Peripheral’s Link Manager shall respond with the LMP_IO_CAPABILITY_RES PDU.

The Central’s LM shall remain the initiating LM for the remainder of the Secure Simple Pairing sequences.

Sequence 56: IO capability exchange with transaction collision (Central transmitting LMP_IO_CAPABILITY_REQ first) and resolution

Sequence 57: IO capability exchange with transaction collision (Peripheral transmitting LMP_IO_CAPABILITY_REQ first) and resolution

Once the IO capabilities are exchanged, public keys shall be exchanged between the two devices.

Since the public key size is longer than the payload body length of a DM1 packet, the exchange shall be done using the LMP_ENCAPSULATED_HEADER and LMP_ENCAPSULATED_PAYLOAD PDUs as defined in Section 4.1.12.

When at least one device does not support Secure Connections, the P-192 curve shall be used for calculating the public and private keys. When both devices support Secure Connections, the P-256 curve shall be used for calculating the public and private keys.

The Initiator shall first send its public key, and the Responder shall reply with its public key.

Sequence 58: Public key exchange

A public key shall be considered as received when the last LMP_ENCAPSULATED_PAYLOAD has been received and the associated LMP_ACCEPTED PDU has been sent.

The device can then start computing its Diffie Hellman Key.

One of the following procedures shall be used in Authentication stage 1:

4.2.7.3.1. Authentication stage 1: Numeric Comparison

Once public keys have been exchanged, both devices shall generate a random number.

The Responder shall compute its commitment as defined in [Vol 2] Part H, Section 7.7.1, and shall send this value to the Initiator by using LMP_SIMPLE_PAIRING_CONFIRM PDU. The Initiator shall then send an LMP_SIMPLE_PAIRING_NUMBER PDU with its generated random number. The Responder shall acknowledge by sending an LMP_ACCEPTED PDU.

The Responder shall then send an LMP_SIMPLE_PAIRING_NUMBER containing its own generated random number. Upon reception, the Initiator shall calculate the commitment as defined in [Vol 2] Part H, Section 7.7.1 and compare it to the one received previously with the LMP_SIMPLE_PAIRING_CONFIRM PDU. If both values are equal, the Initiator shall respond with an LMP_ACCEPTED PDU.

Sequence 59: Numeric Comparison Authentication: Commitment check success

4.2.7.3.1.1. Commitment check failure

If the calculated commitment by the Initiator is not equal to the received commitment, the Initiator shall abort the Secure Simple Pairing process by sending an LMP_NOT_ACCEPTED PDU with reason "Authentication Failure."

Sequence 60: Numeric Comparison authentication: Commitment check failure

4.2.7.3.1.2. Numeric Comparison failure on Initiator side

If the user on the initiating side indicates that the confirm values do not match (e.g., as indicated by the HCI_User_Confirmation_Request_Negative_Reply command) the initiating LM shall send an LMP_NUMERIC_COMPARISON_FAILURE PDU.

The Secure Simple Pairing process shall then be aborted. The Link Managers shall not disconnect the connection.

Sequence 61: Authentication stage 1: Numeric Comparison failure on Initiator side

4.2.7.3.1.3. Numeric Comparison failure on Responder side

If the user on the responding side indicates that the confirm values do not match (e.g., as indicated by the HCI_User_Confirmation_Request_Negative_Reply command) the responding LM shall send an LMP_NOT_ACCEPTED PDU in response to the LMP_DHKEY_­CHECK PDU sent in authentication stage 2 (see Section 4.2.7.4).

The Secure Simple Pairing process shall then be aborted. The Link Managers shall not disconnect the connection.

Sequence 62: Authentication stage 1: Numeric Comparison failure on Responder side

4.2.7.3.2. Authentication stage 1: Passkey Entry Authentication

The initiating LM shall start the following procedure after receiving the Passkey Reply from the Host. This procedure shall be repeated 20 times:

1. The Initiator and the Responder shall generate a new random number.

2. The Initiator and the Responder shall calculate the local commitment value using the exchanged public keys, the local random number, and the passkey from the local Host, according to [Vol 2] Part H, Section 7.7.1.

3. The Initiator shall send an LMP_SIMPLE_PAIRING_CONFIRM PDU with the commitment it calculated in step 2.

4. The Responder shall respond with an LMP_SIMPLE_PAIRING_CONFIRM PDU with the commitment it calculated in step 2.

5. The Initiator shall then send an LMP_SIMPLE_PAIRING_NUMBER PDU with the random number it generated in step 1.

6. The Responder shall then calculate commitment from the exchanged public keys, the random number it received and the passkey from the local Host, according to [Vol 2] Part H, Section 7.7.1. If the calculated commitment and the received commitment are equal, the Responder shall reply with an LMP_ACCEPTED PDU.

7. The Responder shall then send an LMP_SIMPLE_PAIRING_NUMBER PDU with the random value it generated in step 1.

8. The Initiator shall calculate the commitment using the exchanged public keys, the random number it received, and the passkey from the local Host, according to [Vol 2] Part H, Section 7.7.1. If the calculated commitment is equal to the received commitment, the Initiator shall reply with an LMP_ACCEPTED PDU.

Sequence 63: Authentication passkey entry

When this procedure has successfully passed 20 times, the Secure Simple Pairing process continues with the Authentication step 2 as described in Section 4.2.7.4.

4.2.7.3.2.1. Commitment check failure on the Responder side

If during one of the 20 repetitions, the commitment calculated by the Responder is not equal to the one received from the Initiator (step 6), the Responder shall abort the Secure Simple Pairing process by sending an LMP_NOT_ACCEPTED PDU with reason "Authentication Failure."

Secure Simple Pairing procedures shall then be aborted. The Link Managers shall not disconnect the connection.

Sequence 64: Authentication passkey entry: Commitment check failure on the Responder side

4.2.7.3.2.2. Commitment check failure on the Initiator side

If during one of the 20 repetitions, the commitment calculated by the Initiator is not equal to the one received from the Responder (step 8), the Initiator shall abort the Secure Simple Pairing process by sending an LMP_NOT_ACCEPTED PDU with reason "Authentication Failure".

Secure Simple Pairing procedures shall then be aborted. The Link Managers shall not disconnect the connection.

Sequence 65: Authentication passkey entry: Commitment check failure on the Initiator side

4.2.7.3.2.3. Passkey Entry failure on Initiator side

If the initiating side indicates that the passkey was not entered or canceled (e.g., as indicated by the HCI_User_­Passkey_­Request_­Negative_­Reply command) the initiating LM shall send an LMP_PASSKEY_ENTRY_FAILED PDU.

Secure Simple Pairing process shall then be aborted. The Link Managers shall not disconnect the connection.

Sequence 66: Authentication stage 1: Passkey Entry failure on Initiator side

4.2.7.3.3. Passkey Entry failure on Responding side

If the responding side indicates that the passkey was not entered or canceled (e.g., as indicated by the HCI_User_Passkey_Request_Negative_Reply command), the responding LM shall send an LMP_NOT_ACCEPTED PDU in response to the LMP_SIMPLE_­PAIRING_­CONFIRM PDU.

The Secure Simple Pairing process shall then be aborted. The Link Managers shall not disconnect the connection.

Sequence 67: Authentication stage 1: Passkey Entry failure on Responding side

4.2.7.3.4. Keypress notifications

A Controller that allows the Host to change its IO capabilities shall send notifications on key presses to the remote side using the LMP_KEYPRESS_NOTIFICATION PDU when the Host sets the IO capabilities to KeyboardOnly IO and when Secure Simple Pairing is supported on the Host and Controller.

Sequence 68: Keypress notifications

4.2.7.3.5. Authentication stage 1: OOB

Upon reception of the OOB information (as defined in [Vol 2] Part H, Section 7.2.2) from the Host, the devices shall compare the received commitment from its Host, with the one calculated using the secret number received from the Host and the public key received from the remote device. If the local Host has not set the OOB Authentication Data Present, the LM shall set the remote secret number to zero and base the subsequent calculations on this value.

If the commitment check on the initiator is valid, the Initiator shall then generate a random number (nonce) and send it to the Responder using an LMP_SIMPLE_PAIRING_NUMBER PDU. If the commitment succeeds, the Responder shall acknowledge by sending an LMP_ACCEPTED PDU otherwise it shall send an LMP_NOT_ACCEPTED PDU. The Responder shall then generate a random number (nonce) and send it to the Initiator using an LMP_SIMPLE_PAIRING_NUMBER PDU. If the commitment succeeds, the Initiator shall acknowledge by sending an LMP_ACCEPTED PDU otherwise it shall send an LMP_NOT_ACCEPTED PDU.

If the commitment values don't match in the Initiator, the procedure in Section 4.2.7.3.5.2 shall apply.

If the commitment values don't match in the Responder, the procedure in Section 4.2.7.3.5.1 shall apply.

Sequence 69: Authentication OOB: Only one device is OOB-r capable

When these operations have been passed successfully, Secure Simple Pairing procedures continue with Authentication step 2 as described in Section 4.2.7.4.

4.2.7.3.5.1. Commitment check failure on the Responder side

If the commitment received OOB from the Host is not equal to the calculated commitment, the Responder shall send an LMP_NOT_ACCEPTED PDU with reason "Authentication Failure" in response to the LMP_SIMPLE_PAIRING_NUMBER PDU.

Secure Simple Pairing process shall then be aborted. The Link Managers shall not disconnect the connection.

Sequence 70: Authentication stage 1 OOB: Commitment check failure on the Responder side

4.2.7.3.5.2. Commitment check failure on the Initiator side

If the commitment received OOB from the Host is not equal to the calculated commitment, the Initiator shall send an LMP_NOT_ACCEPTED PDU with reason "Authentication Failure" in response to the LMP_SIMPLE_PAIRING_NUMBER PDU.

Secure Simple Pairing process shall then be aborted. The Link Managers shall not disconnect the connection.

Sequence 71: Authentication stage 1 OOB: Commitment check failure on the Initiator side

4.2.7.3.6. Out-of-band information not available on the Initiator side

If the Host on the initiating side does not have out-of-band information the Initiator shall send an LMP_OOB_FAILED PDU.

The Secure Simple Pairing process shall then be aborted. The Link Managers shall not disconnect the connection.

Sequence 72: Authentication stage 1 OOB: OOB information not available on the Initiator side

At this stage, both devices compute new confirmation values based on Diffie-Hellman key and previously exchanged information according to [Vol 2] Part H, Section 7.7.4.

The Initiator shall send an LMP_DHKEY_CHECK PDU to the Responder. If the Initiator has determined that the received public key is invalid (see [Vol 2] Part H, Section 7.6), the PDU shall include a confirmation value that is different from the computed confirmation value (for example, substituting a randomly generated number). Otherwise, the PDU shall include the computed confirmation value.

Upon reception, if the received value is not equal to the one calculated according to [Vol 2] Part H, Section 7.7.4, or if the received public key is invalid (see [Vol 2] Part H, Section 7.6), then the Responder shall follow the procedure in Section 4.2.7.4.1. Otherwise it shall reply with an LMP_ACCEPTED PDU.

The Responder shall then send an LMP_DHKEY_CHECK PDU, including the confirmation value it has computed, to the Initiator. Upon reception, if the received value is not equal to the one calculated according to [Vol 2] Part H, Section 7.7.4, or if the received public key is invalid (see [Vol 2] Part H, Section 7.6), then the Initiator shall follow the procedure in Section 4.2.7.4.1. Otherwise it shall reply with an LMP_ACCEPTED PDU.

At this point, both devices shall compute the link key according to [Vol 2] Part H, Section 7.7.3.

If at least one device does not support both the Secure Connections (Controller Support) and the Secure Connections (Host Support) features, the Initiator shall then start standard mutual authentication as described in Section 4.2.1.1

If both devices support both the Secure Connections (Controller Support) and the Secure Connections (Host Support) features, the Initiator shall then start secure authentication as described in Section 4.2.1.4.

After secure authentication, if encryption is enabled, the initiating device shall pause and immediately resume encryption to produce a new encryption key.

Sequence 73: DHKey check

A device that detects an invalid public key (see [Vol 2] Part H, Section 7.6) from the peer at any point during the Secure Simple Pairing process shall fail the pairing process and therefore not create a link key.

4.2.7.4.1. Check failure

If either Link Manager receives a public key that is invalid (see [Vol 2] Part H, Section 7.6), it shall send an LMP_NOT_ACCEPTED PDU with reason "Authentication Failure". If either Link Manager receives a confirmation value via LMP that is not equal to the one it has calculated according to [Vol 2] Part H, Section 7.7.4, it shall send an LMP_NOT_ACCEPTED PDU with reason "Authentication Failure".

The Secure Simple Pairing procedures shall then be aborted. The Link Managers shall not disconnect the connection.

Sequence 74: DHKey check: Check failure on the Responder side

Sequence 75: DHKey check: Check failure on the Initiator side

4.2.7.4.1.1. [This section is no longer used]

The Central may force Hold mode if there has previously been a request for Hold mode that has been accepted by the Peripheral. The hold time included in the PDU when the Central forces Hold mode shall not be longer than any hold time the Peripheral has previously accepted when there was a request for Hold mode.

The Central LM shall first pause traffic on the ACL-U logical link (see [Vol 2] Part B, Section 5.3.1). It shall select the hold instant and queue the LMP_HOLD PDU to its LC for transmission. It shall then start a timer to wait until the hold instant occurs. When this timer expires then the connection shall enter Hold mode. If the Baseband acknowledgment for the LMP_HOLD PDU is not received then the Central may enter Hold mode, but it shall not use its low accuracy clock during the hold.

When the Peripheral LM receives an LMP_HOLD PDU it compares the hold instant with the Central's current clock value. If it is in the future then it starts a timer to expire at this instant and enters Hold mode when it expires.

When the Central LM exits from Hold mode it re-enables transmission on the ACL-U logical link.

Sequence 86: Central forces Peripheral into Hold mode

The Peripheral may force Hold mode if there has previously been a request for Hold mode that has been accepted by the Central. The hold time included in the PDU when the Peripheral forces Hold mode shall not be longer than any hold time the Central has previously accepted when there was a request for Hold mode.

The Peripheral LM shall first complete the transmission of the current packet on the ACL logical transport and then shall suspend transmission on the ACL-U logical link. It shall select the hold instant and queue the LMP_HOLD PDU to its LC for transmission. It shall then wait for an LMP_HOLD PDU from the Central acting according to the procedure described in Section 4.5.1.1.

When the Central LM receives an LMP_HOLD PDU it shall pause traffic on the ACL-U logical link (see [Vol 2] Part B, Section 5.3.1). It shall then inspect the hold instant. If this is less than 6×T_poll slots in the future it shall modify the instant so that it is at least 6×T_poll slots in the future. It shall then send an LMP_HOLD PDU using the mechanism described in Section 4.5.1.1.

When the Central and Peripheral LMs exit from Hold mode they shall re-enable transmission on the ACL-U logical link.

Sequence 87: Peripheral forces Central into Hold mode

The Central or the Peripheral may request to enter Hold mode. Upon receipt of the request, the same request with modified parameters may be returned or the negotiation may be terminated. If an agreement is seen an LMP_ACCEPTED PDU terminates the negotiation and the ACL link is placed in Hold mode. If no agreement is seen, an LMP_NOT_ACCEPTED PDU with the Error_Code Unsupported LMP Parameter Value (0x20) terminates the negotiation and Hold mode is not entered.

The initiating LM shall pause traffic on the ACL-U logical link (see [Vol 2] Part B, Section 5.3.1). On receiving an LMP_HOLD_REQ PDU the receiving LM shall complete the transmission of the current packet on the ACL logical transport and then shall suspend transmission on the ACL-U logical link.

The LM sending the LMP_HOLD_REQ PDU selects the hold instant, that shall be at least 9×T_poll slots in the future. If this is a response to a previous LMP_HOLD_REQ PDU and the contained hold instant is at least 9×T_poll slots in the future then this shall be used. The LMP_HOLD_REQ PDU shall then be queued to its LC for transmission and a timer shall be started to expire at this instant and the connection enters Hold mode when it expires unless an LMP_NOT_ACCEPTED or LMP_HOLD_REQ PDU is received by its LM before that point. If the LM receiving LMP_HOLD_REQ PDU agrees to enter Hold mode it shall return an LMP_ACCEPTED PDU and shall start a timer to expire at the hold instant. When this timer expires it enters Hold mode.

When each LM exits from Hold mode it shall re-enable transmission on the ACL-U logical link.

Sequence 88: Negotiation for Hold mode

Either the Central or the Peripheral may request entry to Sniff mode. The process is initiated by sending an LMP_SNIFF_REQ PDU containing a set of parameters. The receiving LM shall then decide whether to reject the attempt by sending an LMP_NOT_ACCEPTED PDU, to suggest different parameters by replying with an LMP_SNIFF_REQ PDU or to accept the request.

Before the first time that the Central sends LMP_SNIFF_REQ in a transaction it shall enter Sniff Transition mode. If the Central receives or sends an LMP_NOT_ACCEPTED PDU it shall exit from Sniff Transition mode.

If the Central receives an LMP_SNIFF_REQ PDU it shall enter Sniff Transition mode (if not already in it) and then determine whether to accept the request. The Central may reply with an LMP_NOT_ACCEPTED PDU or, if it can enter Sniff mode but requires a different set of parameters, it shall respond with an LMP_SNIFF_REQ PDU containing the new parameters. If the Central decides that the parameters are acceptable then it shall send an LMP_ACCEPTED PDU; when it receives the Baseband acknowledgment for this PDU it shall exit Sniff Transition mode and enter Sniff mode.

If the Central receives an LMP_ACCEPTED PDU the Central shall exit from Sniff Transition mode and enter Sniff mode.

If the Peripheral receives an LMP_SNIFF_REQ PDU it shall determine whether to accept the request. The Peripheral may reply with an LMP_NOT_ACCEPTED PDU to reject the request or, if it can enter Sniff mode but requires a different set of parameters, it shall respond with an LMP_SNIFF_REQ PDU containing the new parameters. If the Peripheral decides that the parameters are acceptable then it shall send an LMP_ACCEPTED PDU and enter Sniff mode. If the Peripheral receives an LMP_NOT_ACCEPTED PDU it shall terminate the attempt to enter Sniff mode.

Sequence 89: Negotiation for Sniff mode

Sniff mode may be exited by either the Central or the Peripheral sending an LMP_UNSNIFF_REQ PDU. The requested device shall reply with an LMP_ACCEPTED PDU.

If the Central requests an exit from Sniff mode it shall enter Sniff Transition mode and then send an LMP_UNSNIFF_REQ PDU. When the Peripheral receives the LMP_UNSNIFF_REQ it shall exit from Sniff mode and reply with an LMP_ACCEPTED PDU. When the Central receives the LMP_ACCEPTED PDU it shall exit from Sniff Transition mode and enter Active mode.

If the Peripheral requests an exit from Sniff mode it shall send an LMP_UNSNIFF_REQ PDU. When the Central receives the LMP_UNSNIFF_REQ PDU it shall enter Sniff Transition mode and then send an LMP_ACCEPTED PDU. When the Peripheral receives the LMP_ACCEPTED PDU it shall exit from Sniff mode and enter Active mode. When the Central receives the Baseband acknowledgment for the LMP_ACCEPTED PDU it shall leave Sniff Transition mode and enter Active mode.

Sequence 90: Peripheral moved from Sniff mode to Active mode

Once Sniff mode has been started, sniff subrating may be initiated by either Link Manager.

The LMP_SNIFF_SUBRATING_REQ and LMP_SNIFF_SUBRATING_RES PDUs specify parameters that the peer and initiating device shall use respectively for sniff subrating.

The Sniff_Subrating_Instant value shall be used to calculate the first sniff subrating anchor point. The Sniff_Subrating_Instant value shall be a maximum of 2¹⁶ time slots (40.9 seconds) from the Central's current clock and shall be a sniff anchor point. The Sniff_Subrating_Instant value should indicate a clock value in the future with respect to the clock value when the LMP message is first sent.

If the LMP_SNIFF_SUBRATING_REQ PDU is sent by the Central, the Sniff_Subrating_Instant value shall be used. The Peripheral shall reply with an LMP_SNIFF_SUBRATING_RES PDU using the same Sniff_Subrating_Instant value given by the Central.

When the LMP_SNIFF_SUBRATING_REQ PDU is sent by the Peripheral, the Sniff_Subrating_Instant value shall be ignored. The Central shall reply with an LMP_SNIFF_SUBRATING_RES PDU with the Sniff_Subrating_Instant value that shall be used for sniff subrating.

The initiating device shall not transition to the new sniff subrating parameters until the sniff subrating instant has passed and the LMP_SNIFF_SUBRATING_RES PDU has been received. The non-initiating device shall remain in Sniff mode and shall not transition to the new sniff subrating parameters until after the sniff subrating instant has passed and the Baseband acknowledgment of the LMP_SNIFF_SUBRATING_RES PDU has been received.

Sequence 91: LM accepts sniff subrating request

A device shall not send a new LMP_SNIFF_SUBRATING_REQ PDU until the previous sniff subrating transaction has completed and the sniff subrating instant has passed.

The maximum clock interval between two sniff subrating anchor points shall be less than the link supervision timeout. If the link supervision timeout needs to be updated to a shorter value than the clock interval between two sniff subrating anchor points, the Central shall disable sniff subrating, shall send the LMP_SUPERVISION_TIMEOUT PDU with the new supervision timeout value, and shall start using the new supervision timeout value after receiving a Baseband acknowledgment for the LMP_SUPERVISION_TIMEOUT PDU. Upon reception of the LMP_SUPERVISION_TIMEOUT PDU the Peripheral shall disable sniff subrating and shall start using the new supervision timeout value.

The Central shall initiate sniff subrating with the Max_Sniff_Subrate parameter less than the new supervision timeout. The Peripheral shall respond with the LMP_SNIFF_SUBRATING_RES PDU with the Max_Sniff_Subrate parameter less than the new supervision timeout.

When establishing a SCO link the Central sends a request, a LMP_SCO_LINK_REQ PDU, with parameters that specify the timing, packet type and coding that will be used on the SCO link. Each of the SCO packet types supports three different voice coding formats on the air-interface: µ-law log PCM, A-law log PCM and CVSD. The air coding by log PCM or CVSD may be deactivated to achieve a transparent synchronous data link at 64 kb/s.

The slots used for the SCO links are determined by three parameters controlled by the Central: T_sco, D_sco and a flag indicating how the first SCO slot is calculated. After the first slot, the SCO slots follow periodically at an interval of T_sco.

If the Peripheral does not accept the SCO link, but can operate with a different set of SCO parameters, it can indicate what it does not accept in the Error_Code parameter of an LMP_NOT_ACCEPTED PDU. The Central may then issue a new request with modified parameters.

The SCO handle in the message shall be different from existing SCO link(s).

If the SCO packet type is HV1 the LMP_ACCEPTED shall be sent using the DM1 packet.

Sequence 92: Central requests a SCO link

The Peripheral may initiate the establishment of a SCO link. The Peripheral sends an LMP_SCO_LINK_REQ PDU with the SCO handle set to zero; the Timing_Control_Flags parameter shall be ignored by the Central, while the D_SCO parameter should be set to 0. If the Central is not capable of establishing a SCO link, it replies with an LMP_NOT_ACCEPTED PDU. Otherwise it sends back an LMP_SCO_LINK_REQ PDU. This message includes the assigned SCO handle, D_sco and the timing control flags. The Central should try to use the same parameters as in the Peripheral request; if the Central cannot meet that request, it is allowed to use other values. The Peripheral shall then reply with LMP_ACCEPTED or LMP_NOT_ACCEPTED PDU.

If the SCO packet type is HV1 the LMP_ACCEPTED shall be sent using the DM1 packet.

Sequence 93: Central rejects Peripheral’s request for a SCO link

Sequence 94: Central accepts Peripheral’s request for a SCO link

The Central sends an LMP_SCO_LINK_REQ PDU, where the SCO_Handle is the handle of the SCO link the Central wishes to change parameters for. If the Peripheral accepts the new parameters, it replies with an LMP_ACCEPTED PDU and the SCO link will change to the new parameters. If the Peripheral does not accept the new parameters, it shall reply with an LMP_NOT_ACCEPTED PDU and the SCO link is left unchanged. When the Peripheral replies with an LMP_NOT_ACCEPTED PDU it shall indicate in the Error_Code parameter what it does not accept. The Central may then try to change the SCO link again with modified parameters. The sequence is the same as in Section 4.6.1.1.

The Peripheral sends an LMP_SCO_LINK_REQ PDU, where the SCO_Handle is the handle of the SCO link to be changed. The parameters Timing_Control_Flags and D_sco in this PDU shall be ignored by the Central. If the Central does not accept the new parameters it shall reply with an LMP_NOT_ACCEPTED PDU and the SCO link is left unchanged. If the Central accepts the new parameters it shall reply with an LMP_SCO_LINK_REQ PDU containing the same parameters as in the Peripheral request. When receiving this message the Peripheral replies with an LMP_NOT_ACCEPTED PDU if it does not accept the new parameters. The SCO link is then left unchanged. If the Peripheral accepts the new parameters it replies with an LMP_ACCEPTED PDU and the SCO link will change to the new parameters. The sequence is the same as in Section 4.6.1.2.

The Central or Peripheral may remove the SCO link by sending a request including the SCO handle of the SCO link to be removed and an Error_Code indicating why the SCO link is removed. The receiving side shall respond with an LMP_ACCEPTED PDU.

Sequence 95: SCO link removed

When establishing an eSCO link the Central sends an LMP_eSCO_LINK_REQ PDU specifying all parameters. The Peripheral may accept this with an LMP_ACCEPTED_EXT PDU, reject it with an LMP_NOT_ACCEPTED_EXT PDU, or respond with its own LMP_eSCO_LINK_REQ specifying alternatives for some or all parameters. The Peripheral shall not negotiate the eSCO_Handle or eSCO_LT_ADDR parameters. The negotiation of parameters continues until the Central or Peripheral either accepts the latest parameters with an LMP_ACCEPTED_EXT PDU, or terminates the negotiation with an LMP_NOT_ACCEPTED_EXT PDU. The negotiation shall use the procedures defined in Section 4.6.2.5.

Sequence 96: Central requests an eSCO link

When attempting to establish an eSCO link the Peripheral shall send an LMP_eSCO_LINK_REQ PDU specifying all parameters except eSCO_LT_ADDR, which is reserved for future use, and eSCO_Handle, which shall be set to zero. The Central may respond to this with an LMP_eSCO_LINK_REQ PDU, filling in these missing parameters, and potentially changing the other requested parameters. The Peripheral can accept this with an LMP_ACCEPTED_EXT PDU, or respond with a further LMP_eSCO_LINK_REQ PDU specifying alternatives for some or all of the parameters. The negotiation of parameters continues until the Central or Peripheral either accepts the latest parameters with an LMP_ACCEPTED_EXT PDU, or terminates the negotiation with an LMP_NOT_ACCEPTED_EXT PDU.

Sequence 97: Peripheral requests an eSCO link

The Central may reject the request immediately with an LMP_NOT_ACCEPTED_EXT PDU. The negotiation shall use the procedures defined in Section 4.6.2.5.

Sequence 98: Central rejects Peripheral’s request for an eSCO link

The Central or Peripheral may request a renegotiation of the eSCO parameters. The Central or Peripheral shall send an LMP_eSCO_LINK_REQ PDU with the eSCO handle of the eSCO link the device wishes to renegotiate. The remote device may accept the changed parameters immediately with LMP_ACCEPTED_EXT PDU, or the negotiation may be continued with further LMP_eSCO_LINK_REQ PDUs until the Central or Peripheral accepts the latest parameters with an LMP_ACCEPTED_EXT PDU or terminates the negotiation with an LMP_NOT_ACCEPTED_EXT PDU. In the case of termination with an LMP_NOT_ACCEPTED_EXT PDU, the eSCO link continues on the previously negotiated parameters.

The sequence is the same as in Section 4.6.2.2.

During re-negotiation, the eSCO LT_ADDR and eSCO handle shall not be re-negotiated and shall be set to the originally negotiated values. The negotiation shall use the procedures defined in Section 4.6.2.5.

Either the Central or Peripheral may remove the eSCO link by sending an LMP_REMOVE_­eSCO_­LINK_­REQ PDU including the eSCO handle of the eSCO link to be removed and an Error_Code indicating why the eSCO link is removed. The receiving side shall respond with an LMP_ACCEPTED_EXT PDU. The Peripheral shall shut down its eSCO logical transport before sending its PDU (LMP_REMOVE_eSCO_LINK_REQ for Peripheral initiated removal, LMP_ACCEPTED_EXT for Central initiated). The Central shall not reassign the eSCO LT_ADDR until the end of the removal procedure. If, for some reason, such as the Peripheral being out of range, the procedure cannot be completed, the Central shall not reassign the eSCO LT_ADDR until the primary LT_ADDR is available for reuse (supervision timeout).

Sequence 99: eSCO link removed

Rule 1: the Negotiation_State shall be set to 0 by the initiating LM. After the initial LMP_eSCO_LINK_REQ is sent the Negotiation_State shall not be set to 0.

Rule 2: if the bandwidth (defined as 1600 times the packet length in bytes divided by T_eSCO in slots) for either RX or TX or the Air_Mode cannot be accepted the device shall send LMP_NOT_ACCEPTED_EXT with the appropriate Error_Code.

Rule 3: Bandwidth and Air_Mode are not negotiable and shall not be changed for the duration of the negotiation. Once one side has rejected the negotiation (with LMP_NOT_ACCEPTED_EXT) a new negotiation may be started with different bandwidth and Air_Mode parameters.

Rule 4: if the parameters will cause a latency violation (T_eSCO + W_eSCO + reserved synchronous slots > allowed local latency) the device should propose new parameters that shall not cause a reserved slot violation or latency violation for the device that is sending the parameters. In this case the Negotiation_State shall be set to 3. Otherwise the device shall send LMP_NOT_ACCEPTED_EXT.

Rule 5: once a device has received an LMP_eSCO_LINK_REQ with the Negotiation_State set to 3 (latency violation), the device shall not propose any combination of packet type, T_eSCO, and W_eSCO that will give an equal or larger latency than the combination that caused the latency violation for the other device.

Rule 6: if the parameters cause both a reserved slot violation and a latency violation or if the parameters are not supported and a latency violation occurs, then the device shall set the Negotiation_State to 3 (latency violation).

Rule 7: if the parameters will cause a reserved slot violation the device should propose new parameters that shall not cause a reserved slot violation. In this case the Negotiation_State shall be set to 2. Otherwise the device shall send LMP_NOT_ACCEPTED_EXT.

Rule 8: If the requested parameters are not supported the device should propose a setting that is supported, and set the Negotiation_State to 4. If it is not possible to find such a parameter set, the device shall send LMP_NOT_ACCEPTED_EXT.

Rule 9: when proposing new parameters for reasons other than a latency violation, reserved slot violation, or configuration not supported, the Negotiation_State shall be set to 1.

Reserved Slot Violation: a reserved slot violation is when the receiving LM cannot setup the requested eSCO logical transport because the eSCO reserved slots would overlap with other regularly scheduled slots (e.g. other synchronous reserved slots or sniff anchor points).

Latency Violation: a latency violation is when the receiving LM cannot setup the requested eSCO logical transport because the latency (W_eSCO+T_eSCO + reserved synchronous slots) is greater than the maximum allowed latency.

Configuration not supported: The combination of parameters requested is not inside the supported range for the device.