Part C. Link Manager Protocol Specification
vAtlanta r00
This Part describes the Link Manager protocol (LMP) which is used for link set-up and control. The signals are interpreted and filtered out by the Link Manager on the receiving side and are not propagated to higher layers.
1. Introduction
The Link Manager Protocol (LMP) is used to control and negotiate all aspects of the operation of the Bluetooth connection between two devices. This includes the set-up and control of logical transports and logical links, and for control of physical links.
The Link Manager Protocol is used to communicate between the Link Managers (LM) on the two devices. All LMP messages shall apply solely to the physical link and associated logical links and logical transports between the sending and receiving devices.
The protocol is made up of a series of messages which shall be transferred over the ACL-C or APB-C logical link between two devices. LMP messages shall be interpreted and acted-upon by the LM and shall not be directly propagated to higher protocol layers.
2. General rules
2.1. Message transport
LMP messages shall be exchanged over the ACL-C logical link that is carried on the default ACL logical transport ([Vol 2] Part B, Section 4.4) or over the APB-C logical link that is carried on the APB logical transport ([Vol 2] Part B, Section 4.6). LMP messages shall be carried on the default ACL logical transport unless specified otherwise in Sections 4 and 5. The ACL-C and APB-C logical links are distinguished from the ACL-U and APB-U logical links (which carry L2CAP and user data) by the Logical Link Identifier (LLID) field carried in the payload header of variable-length packets ([Vol 2] Part B, Section 6.6.2).
The control logical links have a higher priority than other traffic - see [Vol 2] Part B, Section 5.6.
The error detection and correction capabilities of the Baseband ACL logical transport are generally sufficient for the requirements of the LMP. Therefore LMP messages do not contain any additional error detection information beyond what can be realized by means of sanity checks performed on the contents of LMP messages. Any such checks and protections to overcome undetected errors in LMP messages is an implementation matter.
2.2. Synchronization
This section explains why many of the LMP message sequences are defined as they are. It does not create any requirements.
LMP messages are carried on the ACL-C and APB-C logical links, which do not guarantee a time to deliver or acknowledge packets. LMP procedures take account of this when synchronizing state changes in the two devices. For example, criteria are defined that specify when a logical transport address (LT_ADDR) may be re-used after it becomes available due to a device leaving the piconet. Other LMP procedures, such as hold or role switch include the Bluetooth clock as a parameter in order to define a fixed synchronization point. The transitions into and out of Sniff mode are protected with a transition mode.
The LC normally attempts to communicate with each Peripheral no less often than every Tpoll slots (see Section 4.1.8) based on the Tpoll for that Peripheral.
Figure 2.1 illustrates the fundamental problem. It shows the transmission of a packet from the Central to the Peripheral in conditions of heavy interference for illustrative purposes. It is obvious that neither side can determine the value of either Tdeliver or Tack. It is therefore not possible to use simple messages to identify uniquely the instant at which a state change occurs in the other device.
2.3. Packet format
Each PDU is assigned either a 7 or a 15 bit opcode used to uniquely identify different types of PDUs, see Table 5.1. The first 7 bits of the opcode and a transaction ID are located in the first byte of the payload body. If the initial 7 bits of the opcode have one of the special escape values 124 to 127 then an additional byte of opcode is located in the second byte of the payload and the combination uniquely identifies the PDU.
The FLOW bit in the packet header is always 1 and shall be ignored on reception.
If the PDU contains one or more parameters these are placed in the payload starting immediately after the opcode, i.e. at byte 2 if the PDU has a 7 bit opcode or byte 3 if the PDU has a 15 bit opcode. The number of bytes used depends on the length of the parameters. The representation of each parameter is determined by its type as specified in [Vol 1] Part E, Section 2.9.
LMP messages shall be transmitted using DM1 packets, however if an HV1 SCO link is in use and the length of the payload is no greater than 9 bytes then DV packets may be used.
2.4. Transactions
The LMP operates in terms of transactions. A transaction is a connected set of message exchanges which achieve a particular purpose. All PDUs which form part of the same transaction shall have the same value for the transaction ID which is stored as part of the first byte of the opcode (see Section 2.3).
The transaction ID is in the least significant bit. It shall be 0 if the PDU forms part of a transaction that was initiated by the Central and 1 if the transaction was initiated by the Peripheral.
Each sequence described in Section 4 shall be defined as a transaction. For pairing, see Section 4.2.2, and encryption, see Section 4.2.5, all sequences belonging to each section shall be counted as one transaction and shall use the same transaction ID. For connection establishment, see Section 4.1.1, LMP_HOST_CONNECTION_REQ and the response with LMP_ACCEPTED or LMP_NOT_ACCEPTED shall form one transaction and have the transaction ID of 0. LMP_SETUP_COMPLETE is a stand-alone PDU, which forms a transaction by itself.
For error handling, see Section 2.5, the PDU to be rejected and LMP_NOT_ACCEPTED or LMP_NOT_ACCEPTED_EXT shall form a single transaction.
2.4.1. LMP response timeout
The time between receiving a Baseband packet carrying an LMP PDU and sending a Baseband packet carrying a valid response PDU, according to the procedure rules in Section 4, shall be less than the LMP Response Timeout. The value of this timeout is 30 seconds. The LMP Response Timeout is applied not only to sequences described in Section 4, but also to the series of the sequences defined as the transactions in Section 4. It shall also be applied to the series of LMP transactions that take place during a period when traffic on the ACL-U logical link is disabled for the duration of the series of LMP transactions, for example during the enabling of encryption.
The LMP Response Timeout shall restart each time an LMP PDU which requires a reply is queued for transmission by the Baseband.
LMP messages sent on the APB-C logical link have special rules and are not subject to the LMP Response Timeout.
2.5. Error handling
If the LM receives a PDU with an unknown opcode (e.g. one added in a higher version of the specification), it shall respond with LMP_NOT_ACCEPTED or LMP_NOT_ACCEPTED_EXT with the Error_Code Unknown LMP PDU (0x19). The Opcode parameter shall be the unrecognized opcode.
If the LM receives a PDU which contains valid parameters followed by extra data, it shall either ignore the extra data or shall respond with LMP_NOT_ACCEPTED or LMP_NOT_ACCEPTED_EXT with the Error_Code Invalid LMP Parameters (0x1E).
If the LM receives a PDU which is too short to hold all the parameters, it shall either continue with implementation-specific values for the missing or damaged parameters or shall respond with LMP_NOT_ACCEPTED or LMP_NOT_ACCEPTED_EXT with the Error_Code Invalid LMP Parameters (0x1E).
If the LM receives a PDU with the correct length but with invalid parameters, it shall respond with LMP_NOT_ACCEPTED or LMP_NOT_ACCEPTED_EXT with the Error_Code Invalid LMP Parameters (0x1E).
If the maximum response time (see Section 2.4.1) is exceeded or if a link loss is detected (see [Vol 2] Part B, Section 3.1), the party that waits for the response shall conclude that the procedure has terminated unsuccessfully.
Erroneous LMP messages can be caused by errors on the channel or systematic errors at the transmit side. To detect the latter case, the LM should monitor the number of erroneous messages and disconnect if it exceeds a threshold, which is implementation-dependent.
When the LM receives a PDU that is not allowed, and the PDU normally expects a PDU reply, for example LMP_HOST_CONNECTION_REQ, the LM shall return PDU LMP_NOT_ACCEPTED or LMP_NOT_ACCEPTED_EXT with the Error_Code LMP PDU Not Allowed (0x24). If the PDU normally doesn’t expect a reply, for example LMP_SRES or LMP_TEMP_KEY, the PDU shall be ignored.
If the LM recognizes the PDU as optional but unsupported then it shall reply with LMP_NOT_ACCEPTED or LMP_NOT_ACCEPTED_EXT with the Error_Code Unsupported LMP Feature (0x1A) if the PDU would normally generate a reply; otherwise it shall ignore the PDU and no reply is generated.
2.5.1. Transaction collision resolution
Since LMP PDUs are not interpreted in real time, collision situations can occur where both LMs initiate the same procedure and both cannot be completed. In this situation, the Central shall reject the Peripheral-initiated procedure by sending LMP_NOT_ACCEPTED or LMP_NOT_ACCEPTED_EXT with the Error_Code LMP Error Transaction Collision / LL Procedure Collision (0x23). The Central-initiated procedure shall then be completed.
Collision situations can also occur where both LMs initiate different procedures and both cannot be completed. In this situation, the Central shall reject the Peripheral-initiated procedure by sending LMP_NOT_ACCEPTED or LMP_NOT_ACCEPTED_EXT with the Error_Code Different Transaction Collision (0x2A). The Central-initiated procedure shall then be completed.
2.6. Procedure rules
Each procedure is described and depicted with a sequence diagram. The symbols in Figure 2.3 are used in the sequence diagrams:
PDU1 is a PDU sent from A to B. PDU2 is a PDU sent from B to A. PDU3 is a PDU that is optionally sent from A to B. PDU4 is a PDU that is optionally sent from B to A. PDU5 is a PDU sent from either A or B. A vertical line indicates that more PDUs can optionally be sent.
2.7. General response messages
The PDUs LMP_ACCEPTED, LMP_ACCEPTED_EXT, LMP_NOT_ACCEPTED and LMP_NOT_ACCEPTED_EXT are used as response messages to other PDUs in a number of different procedures. LMP_ACCEPTED or LMP_ACCEPTED_EXT includes the opcode of the message which is accepted. LMP_NOT_ACCEPTED or LMP_NOT_ACCEPTED_EXT includes the opcode of the message which is not accepted and the error code why it is not accepted.
LMP_ACCEPTED_EXT and LMP_NOT_ACCEPTED_EXT shall be used when the opcode is 15 bits in length. LMP_ACCEPTED and LMP_NOT_ACCEPTED shall be used when the opcode is 7 bits in length.
M/O | PDU | Contents |
|---|---|---|
M | LMP_ACCEPTED | Opcode |
M | LMP_NOT_ACCEPTED | Opcode Error_Code |
O | LMP_ACCEPTED_EXT | Escape_Opcode Extended_Opcode |
O | LMP_NOT_ACCEPTED_EXT | Escape_Opcode Extended_Opcode Error_Code |
2.8. LMP message constraints
The following principles are used in the design of LMP.
No LMP message exceeds the maximum payload length of a single DM1 packet i.e. 17 bytes in length ([Vol 2] Part B, Section 6.5.4.1).
All LMP messages are of fixed length.
The LMP version number is not used to indicate the presence or absence of functionality.
3. Device features
3.1. General description
Each PDU is either Mandatory or Optional as defined by the M/O field in the tables of Section 4. An M in this field shall indicate that support for the PDU is mandatory. An O in this field shall indicate that support for the PDU is optional and it shall be followed by the number(s) of the feature(s) involved in brackets.
Some features have associated LMP feature bits. Support of these features may be required by the qualification process but the LM still considers them to be optional since it must interoperate with devices which do not support them.
The LM does not need to be able to transmit a PDU which is optional. Support of optional PDUs is indicated by a device's features mask. The features mask can be read (see Section 4.3.4). An LM shall not send or be sent any PDU which is incompatible with the features signaled in its or its peer's features mask, as detailed in Section 3.2.
The set of features supported by the LM shall not change while the Controller has a connection to another device. A peer device may cache the device's feature mask or extended feature mask, or the LM may cache a peer's feature mask or extended feature mask, during a connection.
3.2. Feature definitions
Feature | Definition |
|---|---|
3-slot Enhanced Data Rate ACL packets | This feature indicates whether the device supports the transmission and reception of three-slot Enhanced Data Rate packets on the ACL-U logical link. |
3-slot Enhanced Data Rate eSCO packets | This feature indicates whether the device supports the transmission and reception of 3-slot Enhanced Data Rate packets for the transport of traffic on the eSCO logical transport. |
3 slot packets | This feature indicates whether the device supports the transmission and reception of both DM3 and DH3 packets for the transport of traffic on the ACL-U logical link. |
5-slot Enhanced Data Rate ACL packets | This feature indicates whether the device supports the transmission and reception of 5-slot Enhanced Data Rate packets for the transport of traffic on the ACL-U logical link. |
5 slot packets | This feature indicates whether the device supports the transmission and reception of both DM5 and DH5 packets for the transport of traffic on the ACL-U logical link. |
AFH capable Central | This indicates whether the device is able to support the Adaptive Frequency Hopping mechanism as a Central as defined in [Vol 2] Part B, Section 2.3 using the LMP sequences defined in Section 4.1.4. |
AFH capable Peripheral | This feature indicates whether the device is able to support the Adaptive Frequency Hopping mechanism as a Peripheral as defined in [Vol 2] Part B, Section 2.3 using the LMP sequences defined in Section 4.1.4. |
AFH classification Central | This feature indicate whether the device is able to support the AFH classification mechanism as a Central as defined in [Vol 2] Part B, Section 8.6.8 using the LMP sequences defined in Section 4.1.5. |
AFH classification Peripheral | This feature indicates whether the device is able to support the AFH classification mechanism as a Peripheral as defined in [Vol 2] Part B, Section 8.6.8 using the LMP sequences defined in Section 4.1.5. |
A-law log synchronous data | This feature indicates whether the device is capable of supporting A-law Log format data as defined in [Vol 2] Part B, Section 9.1 on the SCO and eSCO logical transports. |
Broadcast encryption | This feature indicates whether the device is capable of supporting broadcast encryption as defined in [Vol 2] Part H, Section 4.2 and also the LMP sequences defined in Section 4.2.6 and Section 4.2.4. |
Channel Quality Driven Data Rate | This feature indicates whether the LM is capable of recommending a packet type (or types) depending on the channel quality using the LMP sequences defined in Section 4.1.7. |
Coarse Clock Adjustment | This feature indicates whether the device is able to support coarse clock adjustments using the LMP sequences defined in Section 4.1.14. |
Connectionless Peripheral Broadcast - Receiver Operation | This feature indicates whether the device supports Connectionless Peripheral Broadcast as Receiver. |
Connectionless Peripheral Broadcast - Transmitter Operation | This feature indicates whether the device supports Connectionless Peripheral Broadcast as Transmitter. |
CVSD synchronous data | This feature indicates whether the device is capable of supporting CVSD format data as defined in [Vol 2] Part B, Section 9.2 on the SCO and eSCO logical transports. |
Encapsulated PDU | This feature indicates whether the device is capable of supporting the Encapsulated PDU mechanism as defined in Section 4.1.12.1. |
Encryption | This feature indicates whether the device supports the encryption of packet contents using the LMP sequence defined in Section 4.2.5. |
Enhanced Data Rate ACL 2 Mb/s mode | This feature indicates whether the device supports the transmission and reception of 2-DH1 packets for the transport of traffic on the ACL-U logical link. |
Enhanced Data Rate ACL 3 Mb/s mode | This feature indicates whether the device supports the transmission and reception of 3-DH1 packets for the transport of traffic on the ACL-U logical link. |
Enhanced Data Rate eSCO 2 Mb/s mode | This feature indicates whether the device supports the transmission and reception of 2-EV3 packets for the transport of traffic on the eSCO logical transport. |
Enhanced Data Rate eSCO 3 Mb/s mode | This feature indicates whether the device supports the transmission and reception of 3-EV3 packets for the transport of traffic on the eSCO logical transport. |
Enhanced power control | This feature indicates whether the device is able to support enhanced power control using the LMP sequences defined in Section 4.1.3.1. |
Erroneous Data Reporting | This feature indicates whether the device is able to support the Packet_Status_Flag and the HCI commands HCI_Write_Default_Erroneous_Data_Reporting and HCI_Read_Default_Erroneous_Data_Reporting. |
EV4 packets | This feature indicates whether the device is capable of supporting the EV4 packet type defined in [Vol 2] Part B, Section 6.5.3.2 on the eSCO logical transport. |
EV5 packets | This feature indicates whether the device is capable of supporting the EV5 packet type defined in [Vol 2] Part B, Section 6.5.3.3 on the eSCO logical transport. |
Extended features | This feature indicates whether the device is able to support the extended features mask using the LMP sequences defined in Section 4.3.4. |
Extended Inquiry Response | This feature indicates whether the device supports extended inquiry response as defined in [Vol 2] Part B, Section 8.4.3. |
Extended SCO link | This feature indicates whether the device is able to support the eSCO logical transport as defined in [Vol 2] Part B, Section 5.5 and the EV3 packet defined in [Vol 2] Part B, Section 6.5.3.1 using the LMP sequences defined in Section 4.6.2. |
Flow control lag | This is defined as the total amount of ACL-U data that can be sent following the receipt of a valid payload header with the payload header flow bit set to 0 and is in units of 256 bytes. See further in [Vol 2] Part B, Section 6.6.2. |
Generalized interlaced scan | This feature indicates whether the device is able to support the generalized interlaced scan mechanism described in [Vol 2] Part B, Section 8.3.1 and Section 8.4.1. The presence of this feature has only local meaning and does not imply support for any additional LMP PDUs or sequences. |
Hold mode | This feature indicates whether the device is able to support Hold mode as defined in [Vol 2] Part B, Section 8.8 using the LMP sequences defined in Section 4.5.1. |
HV2 packets | This feature indicates whether the device is capable of supporting the HV2 packet type as defined in [Vol 2] Part B, Section 6.5.2.2 on the SCO logical transport. |
HV3 packets | This feature indicates whether the device is capable of supporting the HV3 packet type as defined in [Vol 2] Part B, Section 6.5.2.3 on the SCO logical transport. |
Inquiry Response Notification event | This feature bit indicates whether the device supports sending the HCI_Inquiry_Response_Notification event to the Host. |
Interlaced inquiry scan | This feature indicates whether the device is capable of supporting the interlaced inquiry scan mechanism as defined in [Vol 2] Part B, Section 8.4.1. The presence of this feature has only local meaning and does not imply support for any additional LMP PDUs or sequences. |
Interlaced page scan | This feature indicates whether the device is capable of supporting the interlaced page scan mechanism as defined in [Vol 2] Part B, Section 8.3.1. The presence of this feature has only local meaning and does not imply support for any additional LMP PDUs or sequences. |
LE Supported (Controller) | This feature indicates whether the Controller supports LE. The local Host uses this feature bit to determine whether the Controller supports LE. A remote device does not use this feature bit. |
LE Supported (Host) | This feature indicates that the Host supports LE. The local Host sets this feature bit to indicate to a remote device that the local device is capable of supporting LE. A remote Host uses this feature bit to determine whether an LE connection to the peer device is possible. |
Link Supervision Timeout Changed event | This feature bit indicates whether the device supports the sending the HCI_Link_Supervision_Timeout_Changed event to the Host. |
μ-law log synchronous data | This feature indicates whether the device is capable of supporting µ-law Log format data as defined in [Vol 2] Part B, Section 9.1 on the SCO and eSCO logical transports. |
Non-flushable Packet Boundary Flag | This feature indicates that the device supports the capability to correctly handle HCI ACL Data packets with a Packet_Boundary_Flag value of 00 (Non-Automatically-Flushable packet). |
Paging parameter negotiation | This feature indicates whether the LM is capable of supporting the signaling of changes in the paging scheme as defined in Section 4.1.9. |
Pause Encryption | When this feature bit is enabled on both sides, then the encryption pause and resume sequences shall be used. If either side does not support the Pause Encryption feature bit, then the encryption pause and resume sequences shall not be used. |
Ping | This feature indicates whether the device supports the transmission and reception of ping messages. |
Power control | This feature indicates whether the device is capable of adjusting its transmission power. This feature indicates the ability to receive the LMP_INCR_POWER and LMP_DECR_POWER PDUs and transmit the LMP_MAX_POWER and LMP_MIN_POWER PDUs, using the LMP sequences defined in Section 4.1.3. These sequences may be used even if the remote device does not support the power control feature, as long as it supports the Power control requests feature. |
Power control requests | This feature indicates whether the device is capable of determining if the transmit power level of the other device should be adjusted and will send the LMP_INCR_POWER and LMP_DECR_POWER PDUs to request the adjustments. It indicates the ability to receive the LMP_MAX_POWER and LMP_MIN_POWER PDUs, using the LMP sequences defined in Section 4.1.3. These sequences may be used even if the remote device does not support the RSSI feature, as long as it supports the power control feature. |
Role switch | This feature indicates whether the device supports the exchange of Central and Peripheral roles as defined by [Vol 2] Part B, Section 8.6.5 using the LMP sequence defined in Section 4.4.2. |
RSSI with inquiry results | This feature indicates whether the device is capable of reporting the RSSI with inquiry results as defined in [Vol 2] Part B, Section 8.4.2. The presence of this feature has only local meaning and does not imply support for any additional LMP PDUs or sequences. |
SCO link | This feature shall indicate whether the device is able to support the SCO logical transport as defined in [Vol 2] Part B, Section 4.3, the HV1 packet defined in [Vol 2] Part B, Section 6.5.2.1 and receiving the DV packet defined in [Vol 2] Part B, Section 6.5.2.4 using the LMP sequence defined in Section 4.6.1. |
Secure Connections (Controller Support) | This feature indicates whether the Controller is able to support AES-CCM, the P-256 Elliptic Curve for Secure Simple Pairing, and enhanced authentication using the LMP sequences defined in Section 4.2.7. |
Secure Connections (Host Support) | This feature indicates whether the Host is capable of supporting Secure Connections. If HCI is supported, this bit shall be set if the HCI_Write_Secure_Connections_Host_Support command has been issued by the Host. When HCI is not supported, this bit may be set using a vendor specific mechanism. |
Secure Simple Pairing (Controller Support) | This feature indicates whether the Link Manager is capable of supporting Secure Simple Pairing as defined in Section 4.2.7. |
Secure Simple Pairing (Host Support) | This feature indicates whether the Host is capable of supporting Secure Simple Pairing as defined in Section 4.2.7. If HCI is supported, this bit shall be set if the HCI_Write_Simple_Pairing_Mode command has been issued to enable the Secure Simple Pairing feature. When HCI is not supported, this bit may be set using a vendor specific mechanism. |
Simultaneous LE and BR/EDR to Same Device Capable (Controller) | This feature indicates that the Controller supports simultaneous LE and BR/EDR links to the same remote device. The local Host uses this feature bit to determine whether the Controller is capable of supporting simultaneous LE and BR/EDR connections to a remote device. A remote device does not use this feature bit. |
Slot Availability Mask | This feature indicates whether the device is able to support Slot Availability Mask using the LMP sequences defined in Section 4.1.15. |
Slot offset | This feature indicates whether the LM supports the transfer of the slot offset using the LMP sequence defined in Section 4.4.1. |
Sniff mode | This feature indicates whether the device is able to support Sniff mode as defined in [Vol 2] Part B, Section 8.7 using the LMP sequences defined in Section 4.5.3. |
Sniff subrating | This feature indicates whether the device is able to support sniff subrating as defined in [Vol 2] Part B, Section 8.7.2 using the LMP sequences defined in Section 4.5.3.3. |
Synchronization Scan | This feature indicates whether the device supports Synchronization Scan as Peripheral. |
Synchronization Train | This feature indicates whether the device supports Synchronization Train as Central. |
Timing accuracy | This feature indicates whether the LM supports requests for timing accuracy using the LMP sequence defined in Section 4.3.1. |
Train nudging | This feature indicates whether the device is able to support the train nudging mechanism described in [Vol 2] Part B, Section 8.3.2 and Section 8.4.2. The presence of this feature has only local meaning and does not imply support for any additional LMP PDUs or sequences. |
Transparent synchronous data | This feature indicates whether the device is capable of supporting transparent synchronous data as defined in [Vol 2] Part B, Section 6.4.3 on the SCO and eSCO logical transports. |
Variable Inquiry TX Power Level | This feature indicates whether the device is capable of setting the TX power level for Inquiry. |
3.3. Feature mask definition
The features are represented as a bit mask when they are transferred in LMP messages. For each feature a single bit is specified which shall be set to 1 if the feature is supported and set to 0 otherwise. The single exception is the flow control lag which is coded as a 3 bit field with the least significant bit in byte 2 bit 4 and the most significant bit in byte 2 bit 6. All unassigned feature bits are reserved for future use.
No. | Supported feature | Byte | Bit |
|---|---|---|---|
0 | 3 slot packets | 0 | 0 |
1 | 5 slot packets | 0 | 1 |
2 | Encryption | 0 | 2 |
3 | Slot offset | 0 | 3 |
4 | Timing accuracy | 0 | 4 |
5 | Role switch | 0 | 5 |
6 | Hold mode | 0 | 6 |
7 | Sniff mode | 0 | 7 |
8 | Previously used | 1 | 0 |
9 | Power control requests | 1 | 1 |
10 | Channel quality driven data rate (CQDDR) | 1 | 2 |
11 | SCO link | 1 | 3 |
12 | HV2 packets | 1 | 4 |
13 | HV3 packets | 1 | 5 |
14 | μ-law log synchronous data | 1 | 6 |
15 | A-law log synchronous data | 1 | 7 |
16 | CVSD synchronous data | 2 | 0 |
17 | Paging parameter negotiation | 2 | 1 |
18 | Power control | 2 | 2 |
19 | Transparent synchronous data | 2 | 3 |
20 | Flow control lag (least significant bit) | 2 | 4 |
21 | Flow control lag (middle bit) | 2 | 5 |
22 | Flow control lag (most significant bit) | 2 | 6 |
23 | Broadcast Encryption | 2 | 7 |
24 | Reserved for future use | 3 | 0 |
25 | Enhanced Data Rate ACL 2 Mb/s mode | 3 | 1 |
26 | Enhanced Data Rate ACL 3 Mb/s mode | 3 | 2 |
27 | Enhanced inquiry scan (see note) | 3 | 3 |
28 | Interlaced inquiry scan | 3 | 4 |
29 | Interlaced page scan | 3 | 5 |
30 | RSSI with inquiry results | 3 | 6 |
31 | Extended SCO link (EV3 packets) | 3 | 7 |
32 | EV4 packets | 4 | 0 |
33 | EV5 packets | 4 | 1 |
34 | Reserved for future use | 4 | 2 |
35 | AFH capable Peripheral | 4 | 3 |
36 | AFH classification Peripheral | 4 | 4 |
37 | Previously used | 4 | 5 |
38 | LE Supported (Controller) | 4 | 6 |
39 | 3-slot Enhanced Data Rate ACL packets | 4 | 7 |
40 | 5-slot Enhanced Data Rate ACL packets | 5 | 0 |
41 | Sniff subrating | 5 | 1 |
42 | Pause encryption | 5 | 2 |
43 | AFH capable Central | 5 | 3 |
44 | AFH classification Central | 5 | 4 |
45 | Enhanced Data Rate eSCO 2 Mb/s mode | 5 | 5 |
46 | Enhanced Data Rate eSCO 3 Mb/s mode | 5 | 6 |
47 | 3-slot Enhanced Data Rate eSCO packets | 5 | 7 |
48 | Extended Inquiry Response | 6 | 0 |
49 | Simultaneous LE and BR/EDR to Same Device Capable (Controller) | 6 | 1 |
50 | Reserved for future use | 6 | 2 |
51 | Secure Simple Pairing (Controller Support) | 6 | 3 |
52 | Encapsulated PDU | 6 | 4 |
53 | Erroneous Data Reporting | 6 | 5 |
54 | Non-flushable Packet Boundary Flag | 6 | 6 |
55 | Reserved for future use | 6 | 7 |
56 | HCI_Link_Supervision_Timeout_Changed event | 7 | 0 |
57 | Variable Inquiry TX Power Level | 7 | 1 |
58 | Enhanced Power Control | 7 | 2 |
59 | Reserved for future use | 7 | 3 |
60 | Reserved for future use | 7 | 4 |
61 | Reserved for future use | 7 | 5 |
62 | Reserved for future use | 7 | 6 |
63 | Extended features | 7 | 7 |
No. | Supported Feature | Byte | Bit |
|---|---|---|---|
64 | Secure Simple Pairing (Host Support) | 0 | 0 |
65 | LE Supported (Host) | 0 | 1 |
66 | Previously used | 0 | 2 |
67 | Secure Connections (Host Support) | 0 | 3 |
No. | Supported Feature | Byte | Bit |
|---|---|---|---|
128 | Connectionless Peripheral Broadcast – Transmitter Operation | 0 | 0 |
129 | Connectionless Peripheral Broadcast – Receiver Operation | 0 | 1 |
130 | Synchronization Train | 0 | 2 |
131 | Synchronization Scan | 0 | 3 |
132 | HCI_Inquiry_Response_Notification event | 0 | 4 |
133 | Generalized interlaced scan | 0 | 5 |
134 | Coarse Clock Adjustment | 0 | 6 |
135 | Reserved for future use | 0 | 7 |
136 | Secure Connections (Controller Support) | 1 | 0 |
137 | Ping | 1 | 1 |
138 | Slot Availability Mask | 1 | 2 |
139 | Train nudging | 1 | 3 |
Note
Note: Feature bit 27 (“Enhanced Inquiry Scan”) is no longer used in the specification. Devices may set this bit but are not required to.
3.4. Link Manager interoperability policy
Link managers of any version shall interpret using the lowest common subset of functionality by reading the LMP features mask (defined in Table 3.2).
An optional LMP PDU shall only be sent to a device if the corresponding feature bit is set in its feature mask. The exception to this are certain PDUs (see Section 4.1.1) which can be sent before the features mask is requested.
Note
Note: A higher version device with a restricted feature set is indistinguishable from a lower version device with the same features.
3.5. Feature requirements
Note
Note: In the tables in this section, numbers in parentheses before feature names are the corresponding feature bit numbers (see Section 3.3).
Any device supporting any feature with a feature bit number greater than or equal to 64 shall support Extended features and shall set feature bit 63.
The features listed in Table 3.5 are mandatory in this version of the specification (see Section 3.1) and these feature bits shall be set.
Feature |
|---|
(2) Encryption |
(51) Secure Simple Pairing (Controller Support) |
(52) Encapsulated PDU |
For each row of Table 3.6, either every feature named in that row shall be supported or none of the features named in that row shall be supported.
Features | |
|---|---|
(7) Sniff mode | (41) Sniff subrating |
For each row of Table 3.7, not more than one feature in that row shall be supported.
Features | |
|---|---|
(23) Broadcast encryption | (134) Coarse clock adjustment |
For each row of Table 3.8, if the feature named in the first column is supported then the feature named in the second column shall be supported.
Feature | Required feature |
|---|---|
(5) Role switch | (3) Slot offset |
(12) HV2 packets | (11) SCO link |
(13) HV3 packets | (11) SCO link |
(14) µ-law log synchronous data | (11) SCO link or (31) Extended SCO link (EV3 packets) |
(15) A-law log synchronous data | (11) SCO link or (31) Extended SCO link (EV3 packets) |
(16) CVSD log synchronous data | (11) SCO link or (31) Extended SCO link (EV3 packets) |
(19) Transparent synchronous data | (11) SCO link or (31) Extended SCO link (EV3 packets) |
(23) Broadcast encryption | (2) Encryption |
(26) Enhanced Data Rate ACL 3 Mb/s mode | (25) Enhanced Data Rate ACL 2 Mb/s mode |
(32) EV4 packets | (31) Extended SCO link (EV3 packets) |
(33) EV5 packets | (31) Extended SCO link (EV3 packets) |
(36) AFH classification Peripheral | (35) AFH capable Peripheral |
(39) 3-slot Enhanced Data Rate ACL packets | (25) Enhanced Data Rate ACL 2 Mb/s mode |
(40) 5-slot Enhanced Data Rate ACL packets | (25) Enhanced Data Rate ACL 2 Mb/s mode |
(42) Pause encryption | (2) Encryption |
(44) AFH classification Central | (43) AFH capable Central |
(45) Enhanced Data Rate eSCO 2 Mb/s mode | (31) Extended SCO link (EV3 packets) |
(46) Enhanced Data Rate eSCO 3 Mb/s mode | (45) Enhanced Data Rate eSCO 2 Mb/s mode |
(47) 3-slot Enhanced Data Rate eSCO packets | (45) Enhanced Data Rate eSCO 2 Mb/s mode |
(48) Extended inquiry response | (30) RSSI with inquiry results |
(49) Simultaneous LE and BR/EDR to Same Device Capable (Controller) | (38) LE Supported (Controller) |
(51) Secure Simple Pairing (Controller Support) | (2) Encryption |
(53) Erroneous data reporting | (11) SCO link or (31) Extended SCO link (EV3 packets) |
(58) Enhanced power control | (9) Power control requests and (18) Power control |
(65) LE Supported (Host) | (38) LE Supported (Controller) |
(67) Secure Connections (Host Support) | (64) Secure Simple Pairing (Host Support) and (136) Secure Connections (Controller Support) |
(128) Connectionless Peripheral Broadcast – Transmitter Operation | (130) Synchronization Train |
(129) Connectionless Peripheral Broadcast – Receiver Operation | (131) Synchronization Scan |
(133) Generalized interlaced scan | (28) Interlaced inquiry scan or (29) Interlaced page scan |
(134) Coarse clock adjustment | (35) AFH capable Peripheral and (43) AFH capable Central and (130) Synchronization Train and (131) Synchronization Scan |
(136) Secure Connections (Controller Support) | (2) Encryption and (42) Pause encryption and (137) Ping |
For each row of Table 3.9, the feature in the first column shall be supported if and only if the implementation supports HCI and the HCI command or event named in the second column.
Feature | HCI command or event |
|---|---|
(53) Erroneous Data Reporting | HCI_Write_Default_Erroneous_Data_Reporting |
(56) Link Supervision Timeout Changed event | HCI_Link_Supervision_Timeout_Changed |
(132) Inquiry Response Notification event | HCI_Inquiry_Response_Notification |
3.5.1. [This section is no longer used]
3.5.2. [This section is no longer used]
4. Procedure rules
4.1. Connection control
4.1.1. Connection establishment
After the paging procedure, LMP procedures for clock offset request, LMP version, supported features, name request and detach may then be initiated.
When the paging device wishes to create a connection involving layers above LM, it sends an LMP_HOST_CONNECTION_REQ PDU. When the other side receives this message, the Host is informed about the incoming connection. The remote device can accept or reject the connection request by sending an LMP_ACCEPTED PDU or an LMP_NOT_ACCEPTED PDU. Alternatively, if the Peripheral needs a role switch, see Section 4.4.2, it sends an LMP_SLOT_OFFSET PDU and LMP_SWITCH_REQ PDU after it has received an LMP_HOST_CONNECTION_REQ PDU. If the role switch fails the LM shall continue with the creation of the connection unless this cannot be supported due to limited resources in which case the connection shall be terminated with an LMP_DETACH PDU with Error_Code Remote Device Terminated Connection due to Low Resources (0x14). When the role switch has been successfully completed, the old Peripheral will reply with an LMP_ACCEPTED PDU or an LMP_NOT_ACCEPTED PDU to the LMP_HOST_CONNECTION_REQ PDU (with the transaction ID set to 0).
If the paging device receives an LMP_NOT_ACCEPTED PDU in response to LMP_HOST_CONNECTION_REQ it shall immediately disconnect the link using the mechanism described in Section 4.1.2.
If the LMP_HOST_CONNECTION_REQ PDU is accepted, LMP security procedures (pairing, authentication and encryption) may be invoked. When a device is not going to initiate any more security procedures during connection establishment it sends an LMP_SETUP_COMPLETE PDU. When both devices have sent LMP_SETUP_COMPLETE PDUs the traffic can be transferred on the BR/EDR ACL logical transport.
M/O | PDU | Contents |
|---|---|---|
M | LMP_HOST_CONNECTION_REQ | none |
M | LMP_SETUP_COMPLETE | none |
4.1.2. Detach
The connection between two Bluetooth devices may be detached anytime by the Central or the Peripheral. An Error_Code parameter is included in the message to inform the other party of why the connection is detached.
M/O | PDU | Contents |
|---|---|---|
M | LMP_DETACH | Error_Code |
The initiating LM shall pause traffic on the ACL-U logical link (see [Vol 2] Part B, Section 5.3.1). The initiating LM then queues the LMP_DETACH for transmission and it shall start a timer for 6×Tpoll slots where Tpoll is the poll interval for the connection. If the initiating LM receives the Baseband acknowledgment before the timer expires it starts a timer for 3×Tpoll slots. When this timer expires, and if the initiating LM is the Central, the LT_ADDR(s) may be re-used immediately. If the initial timer expires then the initiating LM drops the link and starts a timer for Tlinksupervisiontimeout slots after which the LT_ADDR(s) may be re-used if the initiating LM is the Central.
When the receiving LM receives the LMP_DETACH, it shall start a timer for 6×Tpoll slots if it is the Central and 3×Tpoll if it is the Peripheral. On timer expiration, the link shall be detached and, if the receiving LM is the Central, the LT_ADDR(s) may be re-used immediately. If the receiver never receives the LMP_DETACH then a link supervision timeout will occur, the link will be detached, and the LT_ADDR may be re-used immediately.
If at any time during this or any other LMP sequence the Link supervision timeout expires then the link shall be terminated immediately and the LT_ADDR(S) may be re-used immediately.
If the connection is in Hold mode, the initiating LM shall wait for Hold mode to end before initiating the procedure defined above. If the connection is in Sniff mode, the initiating LM shall perform the procedure to exit Sniff mode before initiating the procedure defined above. If the procedure to exit Sniff mode does not complete within the LMP response timeout (30 seconds) the procedure defined above shall be initiated anyway.
Sequence 1: Connection closed by sending LMP_DETACH
If there are any SCO or eSCO connections open on the same physical link, sending or receiving the LMP_DETACH PDU implicitly removes them and the initiating LM should not send separate PDUs for this purpose when detaching.
4.1.3. Power control
If the received signal characteristics differ too much from the preferred value of a Bluetooth device, it may request an increase or a decrease of the other device’s transmit power level. A device's transmit power level is a property of the physical link, and affects all logical transports carried over the physical link. Power control requests carried over the default ACL-C logical link shall only affect the physical link associated with the requesting device’s default ACL-C logical link; they shall not affect the power level used on the physical links to other Peripherals.
Two power control mechanisms are specified: legacy power control (see Table 4.3) and enhanced power control (see Table 4.4 and Section 4.1.3.1).
M/O | PDU | Contents |
|---|---|---|
O(9) | LMP_INCR_POWER_REQ | Reserved |
O(9) | LMP_DECR_POWER_REQ | Reserved |
O(18) | LMP_MAX_POWER | none |
O(18) | LMP_MIN_POWER | none |
M/O | PDU | Contents |
|---|---|---|
O(58) | LMP_POWER_CONTROL_REQ | Power_Adj_Req |
O(58) | LMP_POWER_CONTROL_RES | Power_Adj_Rsp |
The power adjustment requests may be made at any time using the legacy power control mechanism following a successful Baseband Paging procedure and before the link manager supported features responses have been processed. After the Link Manager supported features responses have been processed, if both devices support enhanced power control (see Section 4.1.3.1) then only enhanced power control shall be used. Otherwise, if either device supports only the legacy power control mechanism then only legacy power control shall be used.
If a device does not support power control requests this is indicated in the supported features list and thus no power control requests shall be sent after the supported features response has been processed. Prior to this time, a power control adjustment might be sent, and if the recipient does not support power control, it shall send LMP_MAX_POWER in response to LMP_INCR_POWER_REQ and LMP_MIN_POWER in response to LMP_DECR_POWER_REQ or shall send LMP_NOT_ACCEPTED with the Error_Code Unsupported LMP Feature (0x1A) in response to either PDU.
Upon receipt of an LMP_INCR_POWER_REQ PDU or LMP_DECR_POWER_REQ PDU the output power shall be increased or decreased one step. See [Vol 2] Part A, Section 5.2 for the definition of the step size.
Sequence 2: A device requests a change of the other device’s TX power
If the receiver of LMP_INCR_POWER_REQ is at maximum power LMP_MAX_POWER shall be returned. The device shall only request an increase again after having requested a decrease at least once. If the receiver of LMP_DECR_POWER_REQ is at minimum power then LMP_MIN_POWER shall be returned and the device shall only request a decrease after having requested an increase at least once.
Sequence 3: The TX power cannot be increased
Sequence 4: The TX power cannot be decreased
One byte in LMP_INCR/DECR_POWER_REQ is reserved for future use.
4.1.3.1. Enhanced power control
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.1. Sending enhanced power control requests
To adjust the remote device's output power, a device shall send the LMP_POWER_CONTROL_REQ PDU with the Power_Adj_Req parameter.
The Power_Adj_Req parameter may be set to: one step up, one step down, or all the way to the max power level. The remote device shall respond with an LMP_POWER_CONTROL_RES PDU. The responder shall transmit the LMP_POWER_CONTROL_RES PDU at the new power level. Upon reception of the LMP_POWER_CONTROL_RES PDU, the initiating device should restart any processes used to determine whether additional power level changes are required.
If the receiver of the LMP_POWER_CONTROL_REQ PDU has indicated that the output power levels for all of the supported modulation modes are at maximum the requesting device shall only request an increase again after having requested a decrease at least once. If the receiver of the LMP_POWER_CONTROL_REQ PDU has indicated that the output power levels for all of the supported modulation modes are at minimum the requesting device shall only request a decrease after having requested an increase at least once.
A new LMP_POWER_CONTROL_REQ PDU shall not be sent until an LMP_POWER_CONTROL_RES PDU has been received.
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
4.1.4. Adaptive frequency hopping
AFH is used to improve the performance of physical links in the presence of interference as well as reducing the interference caused by physical links on other devices in the ISM band. AFH shall only be used during Connection state.
M/O | PDU | Contents |
|---|---|---|
O(35) Rx O(43) Tx | LMP_SET_AFH | AFH_Instant, AFH_Mode, AFH_Channel_Map |
The LMP_SET_AFH PDU contains three parameters: AFH_Instant, AFH_Mode, and AFH_Channel_Map. The parameter, AFH_Instant, specifies the instant at which the hopset switch shall become effective. This is specified as a Bluetooth Clock value of the Central’s clock, that is available to both devices. The AFH instant is chosen by the Central and shall be an even value at least 6×Tpoll or 96 slots (whichever is greater) in the future. The AFH_Instant shall be within 12 hours of the current clock value. The parameter AFH_Mode, specifies whether AFH shall be enabled or disabled. The parameter AFH_Channel_Map, specifies the set of channels that shall be used if AFH is enabled.
When the LMP_SET_AFH PDU is received the AFH instant shall be compared with the current Bluetooth clock value. If it is in the past then the AFH_Instant has passed and the Peripheral shall immediately configure the hop selection kernel (see [Vol 2] Part B, Section 2.6.3) with the new AFH_Mode and AFH_Channel_Map specified in the LMP_SET_AFH PDU. If it is in the future then a timer shall be started to expire at the AFH instant. When this timer expires it shall configure the hop selection kernel with the new AFH_Mode and AFH_Channel_Map.
The Central shall not send a new LMP_SET_AFH PDU to a Peripheral until it has received the Baseband acknowledgment for any previous LMP_SET_AFH addressed to that Peripheral and the instant has passed.
Role switch while AFH is enabled shall follow the procedures define by [Vol 2] Part B, Section 8.6.5.
4.1.4.1. Central enables AFH
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
4.1.4.2. Central disables 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
4.1.4.3. Central updates 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
4.1.4.4. AFH operation in Hold and Sniff modes
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.
4.1.5. Channel classification
A Central may request channel classification information from a Peripheral that is AFH-enabled.
A Peripheral that supports the AFH_classification_Peripheral feature shall perform channel classification and reporting according to its AFH_reporting_mode. The Central shall control the AFH_reporting_mode using the LMP_CHANNEL_CLASSIFICATION_REQ PDU. The Peripheral shall report its channel classification using the LMP_CHANNEL_CLASSIFICATION PDU.
The Peripheral shall report pairs of channels as good, bad or unknown. See Table 5.2 for the detailed format of the AFH_Channel_Classification parameter. When one channel in the nth channel pair is good and the other channel is unknown the nth channel pair shall be reported as good. When one channel in the nth channel pair is bad and the other is unknown the nth channel pair shall be reported as bad. It is implementation dependent what to report when one channel in a channel pair is good and the other is bad.
M/O | PDU | Contents |
|---|---|---|
O(36) Rx O(44) Tx | LMP_CHANNEL_CLASSIFICATION_REQ | AFH_Reporting_Mode, AFH_Min_Interval, AFH_Max_Interval |
O(36) Tx O(44) Rx | LMP_CHANNEL_CLASSIFICATION | AFH_Channel_Classification |
The LMP_CHANNEL_CLASSIFICATION_REQ PDU contains three parameters: AFH_Reporting_Mode, AFH_Min_Interval, and AFH_Max_Interval. In the disabled state, the Peripheral shall not generate any channel classification reports. The parameter AFH_min_interval, defines the minimum amount of time from the last LMP_CHANNEL_CLASSIFICATION command that was sent before the next LMP_CHANNEL_CLASSIFICATION PDU may be sent. The parameter AFH_max_interval, defines the maximum amount of time between the change in the channel classification being detected by a Peripheral and its generation of an LMP_CHANNEL_CLASSIFICATION PDU. The AFH_max_interval shall be equal to or larger than AFH_min_interval.
The AFH_reporting_mode parameter shall determine if the Peripheral is in the enabled or disabled state. The default state, prior to receipt of any LMP_CHANNEL_CLASSIFICATION_REQ PDUs, shall be disabled.
AFH_reporting_mode is implicitly set to the disabled state when any of the following occur:
Establishment of a connection at the Baseband level
Role switch
Entry to Hold mode operation
AFH_reporting_mode is implicitly restored to its former value when any of the following occur:
Exit from Hold mode
Failure of role switch
4.1.5.1. Channel classification reporting enabling and disabling
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
4.1.6. Link supervision
Each physical link has a timer that is used for link supervision. This timer is used to detect physical link loss caused by devices moving out of range, or being blocked by interference, a device’s power-down, or other similar failure cases. Link supervision is specified in [Vol 2] Part B, Section 3.1.
M/O | PDU | Contents |
|---|---|---|
M | LMP_SUPERVISION_TIMEOUT | Supervision_Timeout |
Sequence 10: Setting the link supervision timeout
4.1.7. Channel quality driven data rate change (CQDDR)
The data throughput for a given packet type depends on the quality of the RF channel. Quality measurements in the receiver of one device can be used to dynamically control the packet type transmitted from the remote device for optimization of the data throughput. Device A sends the LMP_AUTO_RATE PDU once to notify device B to enable this feature. Once enabled, device B may request packet type(s) that A should transmit by sending the LMP_PREFERRED_RATE PDU. This PDU has a parameter which determines the preferred error coding (with or without 2/3 FEC) and optionally the preferred size in slots of the packets. Device A is not required to change to the packet type specified by this parameter. Device A shall not send a packet that is larger than max slots (see Section 4.1.10) even if the preferred size is greater than this value.
The Data_Rate parameter includes the preferred rate for Basic Rate and Enhanced Data Rate modes. When operating in Basic Rate mode, the device shall use bits 0 to 2 to determine the preferred data rate. When operating in Enhanced Data Rate mode, the device shall use bits 3 to 6 to determine the preferred data rate. For devices that support Enhanced Data Rate, the preferred rates for both Basic Rate and Enhanced Data Rate modes shall be valid at all times.
These PDUs may be sent at any time after connection setup is completed.
M/O | PDU | Contents |
|---|---|---|
O(10) | LMP_AUTO_RATE | none |
O(10) | LMP_PREFERRED_RATE | Data_Rate |
Sequence 11: A notifies B to enable CQDDR
Sequence 12: B sends A a preferred packet type
4.1.8. Quality of service (QoS)
The LM provides QoS capabilities. A poll interval, Tpoll , that is defined as the maximum time between transmissions from the Central to a particular Peripheral on the ACL logical transport, is used to support bandwidth allocation and latency control - see [Vol 2] Part B, Section 8.6.1 for details. The poll interval shall be met in the Active and Sniff modes except when there are collisions with page, page scan, inquiry and inquiry scan, during time critical LMP sequences in the current piconet and any other piconets in which the Bluetooth device is a member, and during critical Baseband sequences (such as the page response, initial Connection state until the first POLL, and role switch). These PDUs may be sent at any time after connection setup is completed.
Central and Peripheral negotiate the number of repetitions for broadcast packets (NBC ), see [Vol 2] Part B, Section 7.6.5.
M/O | PDU | Contents |
|---|---|---|
M | LMP_QUALITY_OF_SERVICE | Poll_Interval NBC |
M | LMP_QUALITY_OF_SERVICE_REQ | Poll_Interval NBC |
4.1.8.1. Central notifies Peripheral of the quality of service
The Central notifies the Peripheral of the new poll interval and NBC by sending the LMP_QUALITY_OF_SERVICE PDU. The Peripheral cannot reject the notification.
Sequence 13: Central notifies Peripheral of quality of service
4.1.8.2. Device requests new quality of service
Either the Central or the Peripheral may request a new poll interval and NBC by sending an LMP_QUALITY_OF_SERVICE_REQ PDU. The parameter NBC 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
4.1.9. Paging scheme parameters
LMP provides a means to negotiate the paging scheme parameters that are used the next time a device is paged.
M/O | PDU | Contents |
|---|---|---|
O(17) | LMP_PAGE_MODE_REQ | Paging_Scheme Paging_Scheme_Settings |
O(17) | LMP_PAGE_SCAN_MODE_REQ | Paging_Scheme Paging_Scheme_Settings |
4.1.9.1. Page mode
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
4.1.9.2. Page Scan 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
4.1.10. Control of multi-slot packets
The number of consecutive slots used by a device on an ACL-U logical link can be limited. It does not affect traffic on the eSCO links where the packet sizes are defined as part of link setup. A device allows the remote device to use a maximum number of slots by sending the PDU LMP_MAX_SLOT providing a Max_Slots parameter. Each device can request to use a maximal number of slots by sending the PDU LMP_MAX_SLOT_REQ providing a Max_Slots parameter. After a new connection (as a result of page or page scan), or after a role switch, the value shall be 1 slot. These PDUs can be sent at any time after connection setup is completed.
M/O | PDU | Contents |
|---|---|---|
M | LMP_MAX_SLOT | Max_Slots |
M | LMP_MAX_SLOT_REQ | Max_Slots |
Sequence 18: Device allows Remote Device to use a maximum number of slots
Sequence 19: Device requests a maximum number of slots. Remote Device accepts.
Sequence 20: Device requests a maximum number of slots. Remote Device rejects
4.1.11. Enhanced Data Rate
A device may change the packet type table, ptt, to select which if any of the packets and optional modulation modes are to be used on an ACL logical transport.
Either the Central or the Peripheral may request a new packet type table and therefore the packets and modulation mode to be used on this ACL link. After a new Baseband connection, as a result of page or page scan, the default value for ptt shall be 0.
The change of the modulation mode for an ACL logical transport shall not affect the packet and packet types used for an associated SCO logical transport on the same LT_ADDR.
Note
Note: Enhanced Data Rate eSCO links are negotiated using the LMP eSCO link_req as described in Section 4.6.2.
Before changing the packet type table, the initiator shall finalize the transmission of the current ACL packet with ACL-U information and shall stop ACL-U transmissions. It shall then send the LMP_PACKET_TYPE_TABLE_REQ PDU.
If the receiver rejects the change, then it shall respond with an LMP_NOT_ACCEPTED_EXT PDU.
If the receiver accepts the change, then it shall finalize the transmission of the current ACL packet with ACL-U information and shall stop ACL-U transmissions, it shall change to the new packet type table and shall respond with an LMP_ACCEPTED_EXT PDU. When it receives the Baseband acknowledgment for the LMP_ACCEPTED_EXT PDU it shall restart ACL-U transmissions.
When the initiator receives an LMP_NOT_ACCEPTED_EXT PDU the initiator shall restart ACL-U transmissions.
When the initiator receives an LMP_ACCEPTED_EXT PDU it shall change the packet type table and restart ACL-U transmissions.
M/O | PDU | Contents |
|---|---|---|
O(25) | LMP_PACKET_TYPE_TABLE_REQ | Packet_Type_Table |
Sequence 21: Packet type table change is rejected
Sequence 22: Packet type table change is accepted
4.1.12. Encapsulated LMP PDUs
Some transactions require sending LMP payload data that is longer than 16 octets. To enable a link manager to send a large PDU, an encapsulated LMP PDU is defined. An encapsulated LMP PDU is composed of a minimum of two LMP messages, a header PDU and one or more payload PDUs.
M/O | PDU | Contents |
|---|---|---|
O(52) | LMP_ENCAPSULATED_HEADER | Encap_Major_Type Encap_Minor_Type Encap_Payload_Length |
O(52) | LMP_ENCAPSULATED_PAYLOAD | Encap_Data |
4.1.12.1. Sending an encapsulated PDU
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.
LMP_CHANNEL_CLASSIFICATION
LMP_DECR_POWER_REQ
LMP_DETACH
LMP_INCR_POWER_REQ
LMP_MAX_POWER
LMP_MAX_SLOT
LMP_MIN_POWER
LMP_PREFERRED_RATE
LMP_SET_AFH
4.1.13. Ping
When both devices support the Ping feature, a Link Manager may verify the presence of the remote Link Manager by using the LMP ping mechanism. The LMP ping mechanism may also be used to verify message integrity on the ACL logical transport by forcing the remote device to send an ACL packet that contains a MIC.
Note
Note: Since the LMP_PING_RES PDU contains a MIC and will update the packet counter, the sender of the LMP_PING_REQ PDU can verify that packets with earlier packet counter values have not been deliberately suppressed by an attacker.
M/O | PDU | Contents |
|---|---|---|
O(137) | LMP_PING_REQ | none |
O(137) | LMP_PING_RES | none |
The initiating link manager sends the LMP_PING_REQ PDU. The responding link manager responds with the LMP_PING_RES PDU. The initiating link manager may be a Central or Peripheral.
Sequence 24: Ping PDUs
The Link Manager shall send an LMP_PING_REQ PDU when the remote device has not sent a packet containing a payload protected by a MIC within an authenticated payload timeout set by the Host (see [Vol 4] Part E, Section 7.3.94). The Link Manager should send an LMP_PING_REQ PDU in advance enough of the expiration of the authenticated payload timeout to allow the remote device reasonable time to respond with an LMP_PING_RES PDU before the timeout expires.
4.1.14. Piconet clock adjustment
The Central may adjust the piconet clock (e.g. to align with an external time base) by initiating the Coarse Clock Adjustment or Clock Dragging procedures. A Peripheral may request that the Central adjust the piconet clock.
M/O | PDU | Contents |
|---|---|---|
O(134) | LMP_CLK_ADJ | Clk_Adj_ID Clk_Adj_Instant Clk_Adj_Offset Clk_Adj_Slots Clk_Adj_Mode Clk_Adj_Clk |
O(134) | LMP_CLK_ADJ_ACK | Clk_Adj_ID |
O(134) | LMP_CLK_ADJ_REQ | Clk_Adj_Offset Clk_Adj_Slots Clk_Adj_Period |
Piconet clock adjustment requests may be made at any time after the Link Manager supported features responses have been processed.
The Central is free to reject any request for an adjustment; an implementation may, for instance, accept coarse clock adjustment requests from one Peripheral but reject all requests from any other Peripheral.
4.1.14.1. Central coarse adjustment of piconet clock
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
4.1.14.2. Peripheral request for coarse adjustment of piconet clock
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
4.1.15. Slot Availability Mask
SAM LMP sequences may be initiated at any time after Link Manager supported features responses have been processed.
Either the Central or the Peripheral may initiate the LMP_SAM_SET_TYPE0 PDU to configure the SAM type 0 submap of the local device. The initiation may be triggered by the HCI command HCI_Set_External_Frame_Configuration for MWS coexistence.
Either the Central or the Peripheral may initiate the LMP_SAM_DEFINE_MAP PDU to define a new or modify an existing local SAM slot map. The initiation may be triggered by the HCI command HCI_Set_MWS_PATTERN_Configuration for MWS coexistence. If a type 0 submap is used with the LMP_SAM_DEFINE_MAP PDU, the Controller shall first execute the SAM set type 0 LMP sequence to configure the SAM type 0 submap, then the SAM define map LMP sequence itself.
Either the Central or the Peripheral may initiate the LMP_SAM_SWITCH PDU to switch to a local SAM slot map that has been defined by previous SAM set type 0 and SAM define map LMP sequences. This may be triggered by the real-time signals (e.g. MWS_PATTERN_Index, FRAME_SYNC, etc.) from the Coexistence Logical Interface (see [Vol 7] Part A), which contain information for the SAM_Index to be activated and the SAM anchor point for MWS coexistence. Piconet Clock Adjustment may be performed to create more available slot pairs per MWS frame before initiating the SAM switch LMP sequence.
These SAM LMP sequences will be described in detail in the following subsections.
M/O | PDU | Contents |
|---|---|---|
O(138) | LMP_SAM_SET_TYPE0 | Update_Mode SAM_Type0_Submap |
O(138) | LMP_SAM_DEFINE_MAP | SAM_Index TSAM_SM NSAM_SM SAM_Submaps |
O(138) | LMP_SAM_SWITCH | SAM_Index Timing_Control_Flags DSAM SAM_Instant |
The LMP_SAM_SET_TYPE0 PDU contains the following SAM parameters from the sender:
Update_Mode: When Update_Mode is set to 0, the existing slot maps containing the type 0 submap are invalidated and the corresponding SAM_Index shall not be used until the map with that index has been redefined in a subsequent SAM define map LMP sequence. When Update_Mode is set to 1, the new type 0 submap shall take effect immediately. When Update_Mode is set to 2, the new type 0 submap shall take effect at the start of the next sub-interval.
SAM_Type0_Submap: This parameter specifies the types of each slot in the type 0 submap. The length of this parameter corresponds to 56 slots but, when it is used in a map, only the first TSAM_SM entries are significant.
Different maps can have different values of TSAM_SM.
The LMP_SAM_DEFINE_MAP PDU contains the following parameters from the sender:
SAM_Index: Index of the SAM slot map this PDU applies to. If the same SAM_Index has been previously defined, then the previous map parameters associated with the map shall be discarded and replaced by the parameters contained in this PDU.
TSAM_SM: Length of each SAM submap in slots. It shall be an even integer in the range 2 to 56.
NSAM_SM: The number of SAM submaps in the SAM slot map.
SAM_Submaps: This parameter specifies the types of the SAM submaps, using 2 bits for each submap. The length of this parameter corresponds to 48 submaps, but only the first NSAM_SM entries are significant.
The LMP_SAM_SWITCH PDU contains the following parameters from the sender:
SAM_Index: Index of the SAM slot map. It shall either be the index of a valid map, in which case SAM should be enabled and that map selected, or shall be 0xFF, which indicates that SAM should be disabled (meaning that, for SAM purposes, all slots are available for both transmission and reception). Disabling SAM does not invalidate a SAM slot map or the type 0 submap.
Timing_Control_Flags: This parameter is used to avoid clock wrap-around during the sequence, using one of the two initialization rules.
DSAM: SAM offset that is used to compute the SAM anchor point. Only even values are valid.
SAM_Instant: Bits 27:1 of the Central's clock value when the SAM slot map is to be activated. This is used to indicate the first anchor point of the slot map. The new SAM slot map may be activated at SAM_Instant even if the Baseband acknowledgment is not received.
4.1.15.1. SAM type 0 submap configuration
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
4.1.15.2. SAM slot map define
Either the Central or the Peripheral may initiate the SAM slot map define sequence by sending an LMP_SAM_DEFINE_MAP PDU. If NSAM_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
4.1.15.3. SAM switch 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
4.1.15.4. SAM change during the transmission of a multi-slot packet
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.
4.1.15.5. SAM and role switching
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.
4.1.15.6. SAM and Sniff mode
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 TSAM. 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.
Note
Note: Even though Sniff mode overrides the SAM slot maps, a device still might not be able to transmit or receive because of scatternet commitments, a coexistence clash, or some other reason.
4.2. Security
Each random number mentioned in this section shall be created according to [Vol 2] Part H, Section 2.
4.2.1. Authentication
Two authentication procedures are defined: legacy and secure authentication. Legacy authentication shall be performed when at least one device does not support both the Secure Connections (Controller Support) and Secure Connections (Host Support) features and the local device allows legacy authentication to be used. Secure authentication shall be performed when both devices support the Secure Connections (Controller Support) and Secure Connections (Host Support) features.
The legacy authentication procedure is based on a challenge-response scheme as described in [Vol 2] Part H, Section 3.2.2. The verifier sends an LMP_AU_RAND PDU that contains a random number (the challenge) to the claimant. The claimant calculates a response, that is a function of this challenge, the claimant’s BD_ADDR and a secret key. The response is sent back to the verifier, which checks if the response was correct or not. The response shall be calculated as described in [Vol 2] Part H, Section 6.1. A successful calculation of the authentication response requires that two devices share a secret key. This key is created as described in Section 4.2.2. Both the Central and the Peripheral can be verifiers. The sequences for legacy authentication are described in Section 4.2.1.1 and Section 4.2.1.2.
The secure authentication procedure is a challenge-response scheme as described in [Vol 2] Part H, Section 5. The verifier sends an LMP_AU_RAND PDU that contains a random number (the challenge) to the claimant. The claimant responds with another LMP_AU_RAND PDU also containing a random number. Both Link Managers calculate the Device Authentication Key using the h4 function (see [Vol 2] Part H, Section 7.7.7) and then calculate the SRES_C, SRES_P and ACO values using the h5 function (see [Vol 2] Part H, Section 7.7.8). The Peripheral (regardless of whether it was the verifier or claimant) sends its response (SRES_P) to the Central. The Central sends its response (SRES_C) to the Peripheral. A successful calculation of the authentication response requires that two devices share a secret key. The sequences for secure authentication are described in Section 4.2.1.2 and Section 4.2.1.4.
M/O | PDU | Contents |
|---|---|---|
M | LMP_AU_RAND | Random_Number |
M | LMP_SRES | Authentication_Rsp |
4.2.1.1. Claimant has link key (legacy authentication)
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.
Note
Note: There can be conflicting actions from the Central and the Peripheral which could lead to the two devices having different Authenticated Ciphering Offsets (ACOs, see [Vol 2] Part H, Section 6.1) when they calculate the encryption key. The following procedures assure that this cannot occur:
procedure in Section 2.5.1 (Transaction Collision Resolution) when the Central and Peripheral simultaneously initiate an authentication.
procedure in Section 4.2.5.1 when encryption parameters are being negotiated.
4.2.1.2. Claimant has no link key (legacy authentication and secure 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).
Note
Note: This sequence is identical for legacy authentication and secure authentication.
Sequence 32: Authentication fails. Claimant has no link key.
4.2.1.3. Repeated attempts
The scheme described in [Vol 2] Part H, Section 5.1 shall be applied when an authentication fails.
4.2.1.4. Responder has link key (secure authentication)
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).
Note
Note: Secure Authentication is a mutual authentication.
4.2.2. Pairing
When two devices do not have a common link key an initialization key (Kinit) shall be created using either the pairing or Secure Simple Pairing procedures. When pairing is used, Kinit shall be created based on a PIN, and a random number and a BD_ADDR. Kinit shall be created as specified in [Vol 2] Part H, Section 6.3. When both devices have calculated Kinit the link key shall be created, and a mutual authentication is performed. The pairing procedure starts with a device sending an LMP_IN_RAND PDU; this device is referred to as the "initiating LM" or "initiator" in Section 4.2.2.1 - Section 4.2.2.5. The other device is referred to as the "responding LM" or "responder". The PDUs used in the pairing procedure are:
M/O | PDU | Contents |
|---|---|---|
M | LMP_IN_RAND | Random_Number |
M | LMP_AU_RAND | Random_Number |
M | LMP_SRES | Authentication_Rsp |
M | LMP_COMB_KEY | Random_Number |
M | LMP_UNIT_KEY | Key |
The Link Manager shall not send an LMP_UNIT_KEY PDU.
All sequences described in Pairing, including the mutual authentication after the link key has been created, shall form a single transaction. The transaction ID from the first LMP_IN_RAND shall be used for all subsequent sequences.
4.2.2.1. Responder accepts pairing and has a variable PIN
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 Kinit 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.
4.2.2.2. Responder accepts pairing and has a 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 Kinit 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
4.2.2.3. Responder rejects pairing
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
4.2.2.4. Creation of the link key
When Kinit 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 Kinit. 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).
4.2.2.5. Repeated attempts
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.
4.2.3. Change link key
The link key can be changed. The contents of the LMP_COMB_KEY PDU is protected by a bitwise XOR with the current link key.
M/O | PDU | Contents |
|---|---|---|
M | LMP_COMB_KEY | Random_Number |
Sequence 40: Successful change of the link key
The new link key shall be stored and the old link key shall be discarded. The new link key shall be used as link key for all the following connections between the two devices until the link key is changed again. The new link key also becomes the current link key. It will remain the current link key until the link key is changed again, or until a temporary link key is created, see Section 4.2.4.
When the new link key has been created, mutual or secure authentication shall be performed to confirm that the same link key has been created in both devices.
If both devices support the Secure Connections (Controller Support) and Secure Connections (Host Support) features, the device that initiated the change link key shall initiate the Secure Authentication procedure. Otherwise, the first authentication in the mutual authentication is performed with the device that initiated the change link key as verifier. When finalized an authentication in the reverse direction is performed.
After mutual or secure authentication, if encryption is enabled, the initiating device shall pause and immediately resume encryption to produce a new encryption key.
Note
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.
4.2.4. Change current link key type
The current link key can be a semi-permanent link key or a temporary link key. It may be changed temporarily, but the change shall only be valid for the current connection, see [Vol 2] Part H, Section 3.1. Changing to a temporary link key is necessary if the piconet is to support encrypted broadcast. The current link key shall not be changed before the connection establishment procedure has completed.
M/O | PDU | Contents |
|---|---|---|
O(23) | LMP_TEMP_RAND | Random_Number |
O(23) | LMP_TEMP_KEY | Key |
O(23) | LMP_USE_SEMI_PERMANENT_KEY | none |
4.2.4.1. Change to a temporary link key
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= E22 (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.
Note
Note: The terminology in this section is the same as used in [Vol 2] Part H, Section 3.2.8.
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.
4.2.4.2. Semi-permanent link key becomes current link key
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
4.2.5. Encryption
If at least one authentication has been performed encryption may be used. Two encryption mechanisms are defined: E0 encryption (legacy) and AES-CCM encryption. If both devices support the Secure Connections (Controller Support) and Secure Connections (Host Support) features, then AES-CCM shall be used when encryption is enabled. If at least one device does not support both the Secure Connections (Controller Support) and Secure Connections (Host Support) features, then E0 shall be used when encryption is enabled.
In order for the Central to use the same encryption parameters for all Peripherals in the piconet where E0 encryption would be used it shall issue a temporary key, K_temp. The Central shall make this key the current link key for all Peripherals in the piconet where E0 encryption would be used before encryption is started, see Section 4.2.4. This is required if broadcast packets are to be encrypted.
Note
Note: Packets encrypted with broadcast encryption can not be received by Peripherals that have AES-CCM encryption enabled. When the local Controller supports Secure Connections and there are not any Peripherals in the piconet that do not support Secure Connections, broadcast packets will not be encrypted and may be received by Peripherals that support Secure Connections.
M/O | PDU | Contents |
|---|---|---|
O (2) | LMP_ENCRYPTION_MODE_REQ | Encryption_Mode |
O (2) | LMP_ENCRYPTION_KEY_SIZE_REQ | Key_Size |
O (2) | LMP_START_ENCRYPTION_REQ | Random_Number |
O (2) | LMP_STOP_ENCRYPTION_REQ | none |
O (42) | LMP_PAUSE_ENCRYPTION_REQ | none |
O (42) | LMP_RESUME_ENCRYPTION_REQ | none |
O (136) | LMP_PAUSE_ENCRYPTION_AES_REQ | Random_Number |
All sequences described in Section 4.2.5 shall form a single transaction. The transaction ID from the LMP_ENCRYPTION_MODE_REQ PDU shall be used for all start encryption and stop encryption sequences.
Where the specification requires a device to resume encryption as part of one procedure and then pause it as part of a following procedure, the device may omit both the resume and the subsequent pause.
4.2.5.1. Encryption mode
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.
4.2.5.2. Encryption key size
Note
Note: This section uses the same terms as in [Vol 2] Part H, Section 4.1.
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.
Note
Note: If the Host of either the Central or the Peripheral uses services that require security mode 4 (see [Vol 3] Part C, Section 5.2.2.8), a key size longer than the key size negotiated by the two Link Managers can be enforced.
Sequence 44: Encryption key size negotiation successful
Sequence 45: Encryption key size negotiation failed
4.2.5.3. Start encryption
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).
Note
Note: For AES-CCM, the EN_RAND is not used when creating the encryption key.
If encryption has been paused, then this sequence shall not be used.
Sequence 46: Start encryption
Starting encryption shall be performed in three steps:
Central is configured to transmit unencrypted packets and to receive encrypted packets.
Peripheral is configured to transmit and receive encrypted packets.
Central is configured to transmit and receive encrypted packets.
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.
4.2.5.4. Stop encryption
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 stoppe