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.
(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.
(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.
(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".
(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.
(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.
(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.
(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.
(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.
(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.
(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.
(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.
(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.
(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.
(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.
(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.
(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.
(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.
(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.
(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.
(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).
(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.
(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.
(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.
(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.
(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.
(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.
(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.
|