Radio Baseband LMP HCI L2CAP RFCOMM SDP Profiles

Link Manager Protocol (LMP)


    The Link Manager carries out link setup, authentication, link configuration and other protocols. It discovers other remote LMís and communicates with them via the Link Manager Protocol (LMP). To perform its service provider role, the LM uses the services of the underlying Link Controller (LC).

    The Link Manager Protocol essentially consists of a number of PDU (protocol Data Units), which are sent from one device to another, determined by the AM_ADDR in the packet header. LM PDUs are always sent as single-slot packets and the payload header is therefore one byte.

    DM1 packets are used to transport LM PDUs except if an SCO link is present using HV1 packets and length of content is less than 9 bytes. In this case DV packets are used.

    The following is a brief list of the types of PDU's available and their function/operation. These PDU are either Mandatory : M (must be supported), or Optional : O ( optionally supported)

For more details : Download the LMP Specification from the SIG website, or visit the Documents Page.


Table Of Contents

3.1 LMP PDUs
3.1.1 General Response
3.1.2 Authentication   
3.1.3 Pairing
3.1.4 Change Link Key
3.1.5 Change the Current Link Key
3.1.6 Encryption
3.1.7 Slot Offset Request
3.1.8 Clock Offset Request
3.1.9 Timing Accuracy Information Request
3.1.10 LMP Version
3.1.11 Supported Features
3.1.12 Switch of Master-Slave Role
3.1.13 Name Request
3.1.14 Detach
3.1.15 Hold Mode
3.1.16 Sniff Mode
3.1.17 Park Mode
3.1.18 Power Control
3.1.19 Channel Quality-Driven Change
3.1.20 Quality of Service
3.1.21 SCO Links
3.1.22 Control of Multi-Slot Packets
3.1.23 Paging Scheme
3.1.24 Link Supervision
3.1.25 Connection Establishment
3.1.26 Test Mode
3.1.27 Error Handling


3.1  LMP PDUs

3.1.1  General Response

(M) LMP_accepted , LMP_not_accepted

    These PDU's are used as response messages to other PDU's in a number of different procedures, containing the opcode of the message that is being responded to.


3.1.2  Authentication

(M)  LMP_au_rand , LMP_sres

    The authentication procedure is based on a challenge-response scheme. The verifier sends an LMP_au_rand PDU which contains a random number (the challenge) to the claimant. The claimant calculates a response, which is a function of the 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. A successful calculation of the authentication response requires that two devices share a secret key.  Both the master and the slave can be verifiers.


3.1.3  Pairing

(M) LMP_in_rand , LMP_au_rand , LMP_sres , LMP_comb_key , LMP_unit_key

    When two devices do not have a common link key an initialization key (K init ) is created based on a PIN and a random number. When both devices have calculated K init the link key is created, and finally a mutual authentication is made. The pairing procedure starts with a device sending LMP_in_rand; this device is referred to as "initiating LM" or "initiator" in. The other device is referred to as "responding LM" or "responder".


3.1.4  Change Link Key 

(M) LMP_comb_key

    If the link key is derived from combination keys and the current link is the semi-permanent link key, the link key can be changed. If the link key is a unit key, the units must go through the pairing procedure in order to change the link key. The contents of LMP_comb_key is protected by a bitwise XOR with the current link key.


3.1.5  Change the Current Link Key

(M) LMP_temp_rand , LMP_temp_key , LMP_use_semi_permanent_key

    The current link key can be a semi-permanent link key or a temporary link key key. It can be changed temporarily, but the change is only valid for the session. Changing to a temporary link key is necessary if the piconet is to support encrypted broadcast.


3.1.6  Encryption

(O) LMP_encryption_mode_req , LMP_encryption_key_size_req , LMP_start_encryption_req ,            LMP_stop_encryption_req

    If at least one authentication has been performed encryption may be used. If the master wants all slaves in the piconet to use the same encryption parameters it must issue a temporary key (K master ) and make this key the current link key for all slaves in the piconet before encryption is started. This is necessary if broadcast packets should be encrypted.


3.1.7  Clock Offset Request

(M) LMP_clkoffset_req, LMP_clkoffset_res

    When a slave receives the FHS packet, the difference is computed between its own clock and the masterís clock included in the payload of the FHS packet. The clock offset is also updated each time a packet is received from the master. The master can request this clock offset anytime during the connection. By saving this clock offset the master knows on what RF channel the slave wakes up to PAGE SCAN after it has left the piconet. This can be used to speed up the paging time the next time the same device is paged.


3.1.8  Slot Offset Request

(O) LMP_slot_offset

    With LMP_slot_offset the information about the difference between the slot boundaries in different piconets is transmitted. This PDU carries the parameters slot offset and BD_ADDR. The slot offset is the subtraction of time in us of the start of the masterís TX slot in the piconet where the PDU is transmitted from the time in us of the start of the masterís TX slot in the piconet where the BD_ADDR device is master modulo 1250.

. Before doing a master-slave switch, this PDU shall be transmitted from the device that becomes master in the switch procedure. The PDU can also be useful in inter-piconet communications.


3.1.9  Timing Accuracy Information Request

(O) LMP_timing_accuracy_req , LMP_timing_accuracy_res

    LMP supports requests for the timing accuracy. This information can be used to minimize the scan window for a given hold time when returning from hold and to extend the maximum hold time. It can also be used to minimize the scan window when scanning for the sniff mode slots or the park mode beacon packets. The timing accuracy parameters returned are the long term drift measured in ppm and the long term jitter measured in Ķs of the clock used during hold, sniff and park mode. These parameters are fixed for a certain device and must be identical when requested several times.


3.1.10  LMP Version

(M) LMP_version_req , LMP_version_res

    The LMP layer supports requests for the version of the LM protocol. The requested device will send a response with three parameters: VersNr, CompId and Sub-VersNr. VersNr specifies the version of the Bluetooth LMP specification that the device supports. CompId is used to track possible problems with the lower Bluetooth layers. All companies that create a unique implementation of the Link Manager shall have their own CompId. The same company is also responsible for the administration and maintenance of the SubVersNr. It is recommended that each company has a unique SubVersNr for each RF/BB/LM implementation.


3.1.11  Supported Features

(M) LMP_features_req , LMP_features_res

    The Bluetooth radio and link controller may support only a subset of the packet types and features described in Baseband Specification and Radio Specification. A device may not send any packets other than ID, FHS, NULL, POLL, DM1 or DH1 before it is aware of the supported features of the other device. After the features request has been carried out, the intersection of the supported packet types for both sides may also be transmitted. Whenever a request is issued, it must be compatible with the supported features of the other device. For instance, when establishing an SCO link the initiator may not propose to use HV3 packets if that packet type is not supported by the other device.


3.1.12  Switch of Master-Slave Role

(O) LMP_switch_req , LMP_slot_offset

    Since the paging device always becomes the master of the piconet, a switch of the master-slave role is sometimes needed. Suppose device A is slave and device B is master. The device that initiates the switch finalises the transmission of the current L2CAP message and then sends LMP_switch_req. Note: in a slave initiated master-slave switch the slave (A)  will first send LMP_slot_offset, then LMP_switch. In a master initiated master-slave switch, the master (B) will first send LMP_switch, before receiving LMP_slot_offset from the slave (A). If the switch is accepted, the other device finalises the transmission of the current L2CAP message and then responds with LMP_accepted. The switch procedure then takes place, and afterwards device A is master and device B is slave.


3.1.13  Name Request

(M) LMP_name_req , LMP_name_res

    LMP supports name request to another Bluetooth device. The name is a user-friendly name associated with the Bluetooth device and consists of a maximum of 248 bytes coded according to the UTF-8 standard. The name is fragmented over one or more DM1 packets.


3.1.14  Detach

(M) LMP_detach

    The connection between two Bluetooth devices can be closed anytime by the master or the slave. A reason parameter is included in the message to inform the other party of why the connection is closed.


3.1.15  Hold Mode

(O) LMP_hold , LMP_hold_req

    The ACL link of a connection between two Bluetooth devices can be placed in hold mode for a specified hold time. During this time no ACL packets will be transmitted from the master. The hold mode is typically entered when there is no need to send data for a relatively long time. The transceiver can then be turned off in order to save power. But the hold mode can also be used if a device wants to discover or be discovered by other Bluetooth devices, or wants to join other piconets. What a device actually does during the hold time is not controlled by the hold message, but it is up to each device to decide.


3.1.16  Sniff Mode

(O) LMP_sniff_req , LMP_unsniff_req

    To enter sniff mode, master and slave negotiate a sniff interval T sniff and a sniff offset, D sniff , which specifies the timing of the sniff slots. The offset determines the time of the first sniff slot; after that the sniff slots follows periodically with the sniff interval T sniff . When the link is in sniff mode the master can only start a transmission in the sniff slot. Two parameters control the listening activity in the slave. The sniff attempt parameter determines for how many slots the slave must listen, beginning at the sniff slot, even if it does not receive a packet with its own AM address. The sniff timeout parameter determines for how many additional slots the slave must listen if it continues to receive only packets with its own AM address.


3.1.17  Park Mode

(O)  LMP_park_req , LMP_unpark_PM_ADDR_req , LMP_unpark_BD_ADDR_req , LMP_set_broadcast_scan_window , LMP_modify_beacon

    If a slave does not need to participate in the channel, but still should be FH-synchronized, it can be placed in park mode. In this mode the device gives up its AM_ADDR but still re-synchronizes to the channel by waking up at the beacon instants separated by the beacon interval. The beacon interval, a beacon offset and a flag indicating how the first beacon instant is calculated determine the first beacon instant. After this the beacon instants follow periodically at the predetermined beacon interval. At the beacon instant the parked slave can be activated again by the master, the master can change the park mode parameters, transmit broadcast information or let the parked slaves request access to the channel.

    All PDUs sent from the master to the parked slaves are broadcast. These PDUs are the only PDUs that can be sent to a slave in park mode and the only PDUs that can be broadcast. When a slave is placed in park mode it is assigned a unique PM_ADDR, which can be used by the master to unpark that slave.


3.1.18  Power Control

(O) LMP_incr_power_req , LMP_decr_power_req , LMP_max_power , LMP_min_power

    If the RSSI value differs too much from the preferred value of a Bluetooth device, it can request an increase or a decrease of the other deviceís TX power. Upon receipt of this message, the output power is increased or decreased one step. At the master side the TX power is completely independent for different slaves; a request from one slave can only effect the masterís TX power for that same slave.The power adjustment requests can be made at anytime following a successful baseband paging procedure. If a device does not support power control requests this is indicated in the supported features list.



3.1.19  Channel Quality-Driven Change (between DM and DH)

(O) LMP_auto_rate , LMP_preferred_rate

    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. If a device A wants the remote device B to have this control it sends LMP_auto_rate once. The device B can then send back LMP_preferred_rate to device A whenever it wishes to change the packet type that A transmits.

    This PDU has a parameter which determines the preferred coding (with or without 2/3FEC) and the preferred size (in slots) of the packets. Device A is not required to change to the packet type specified by this parameter and may never send a packet that is larger than the maximum allowed number of slots even if the preferred size is greater than this value.


3.1.20  Quality of Service

(M) LMP_quality_of_service , LMP_quality_of_service_req

    The LM provides Quality of Service capabilities. A poll interval, which is defined as the maximum time between subsequent transmissions from the master to a particular slave, is used to support bandwidth allocation and latency control.  In addition, master and slave negotiate the number of repetitions for broadcast packets (NBC).


3.1.21  SCO Links

(O) LMP_SCO_link_req , LMP_remove_SCO_link_req

    When a connection has been established between two Bluetooth devices the connection consists of an ACL link. One or more SCO links can then be established. The SCO link reserves slots separated by the SCO interval, T sco . The first slot reserved for the SCO link is defined by T sco and the SCO delay, D sco . After that the SCO slots follows periodically with the SCO interval. Each SCO link is distinguished from all other SCO links by an SCO handle.


3.1.22  Control of Multi-Slot Packets

(M) LMP_max_slot , LMP_max_slot_req

    The number of slots used by a device can be limited. A device allows the remote device to use a maximal number of slots by sending the PDU LMP_max_slot providing max slots as parameter. Each device can request to use a maximal number of slots by sending the PDU LMP_max_slot_req providing max slots as parameter. After a new connection, as a result of page, page scan, master-slave switch or unpark, the default value is 1 slot. Two PDUs are used for the control of multi-slot packets.These PDUs can be sent at anytime after connection setup is completed.


3.1.23  Paging Scheme

(O) LMP_page_mode_req , LMP_page_scan_mode_req

    In addition to the mandatory paging scheme, the Bluetooth system defines optional paging schemes. LMP provides a means to negotiate the paging scheme, which is to be used the next time a unit is paged.


3.1.24  Link Supervision

(M) LMP_supervision_timeout

    Each Bluetooth link has a timer that is used for link supervision. This timer is used to detect link loss caused by devices moving out of range, a deviceís power-down, or other similar failure cases. An LMP procedure is used to set the value of the supervision timeout.


3.1.25  Connection Establishment

(M) LMP_host_connection_req , LMP_setup_complete

    When the paging device wishes to create a connection involving layers above LM, it sends LMP_host_connection_req. 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 LMP_accepted or LMP_not_accepted.

    If LMP_host_connection_req is accepted, LMP security procedures (pairing, authentication and encryption) can be invoked. When a device is not going to initiate any more security procedures during connection establishment it sends LMP_setup_complete. When both devices have sent LMP_setup_complete the first packet on a logical channel different from LMP can then be transmitted.


3.1.26  Test Mode

(M) LMP_test_activate , LMP_test_control

    LMP has PDUs to support different Bluetooth test modes, which are used for certification and compliance testing of the Bluetooth radio and baseband.


3.1.27  Error Handling

(M) LMP_not_accepted

    If the Link Manager receives a PDU with unrecognised opcode, it responds with LMP_not_accepted with the reason code unknown LMP PDU. The opcode parameter that is echoed back is the unrecognised opcode. If the Link Manager receives a PDU with invalid parameters, it responds with LMP_not_accepted with the reason code invalid LMP parameters. If the maximum response time is exceeded or if a link loss is detected 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.


Note , the above text contains excerpts from the Bluetooth SIG's Specification, as well as various interpretations of the Specs. For complete details of the various sections, consult the actual Bluetooth Specification.