1.1. Link Management Protocol (LMP)
1.1.1. Introduction and Theory
The Link Manager (LM) translates the commands into operations at the Baseband level, managing the following operations.
1) Attaching slaves to piconets, and allocating their active member addresses.
2) Breaking connections to detach Slaves from a piconet.
3) Configuring the link including Master/Slave switches
4) Establishing ACL and SCO links.
5) Putting connections into Low Power modes: Hold, Sniff and Park.
6) Controlling test modes.
A bluetooth Link Manager communicates with Link Managers on other Bluetooth devices using the Link Management protocol (LMP).
Once the connection has been setup, it can have up to three SCO connections created across it, or its mode can be changed, either to a low power mode or to a test mode (these are useful for certification of Bluetooth devices by testing authorities and for a manufacture’s production line testing of devices).
The link can be configured at any time, including at mode changes, quality of service changes, packet type changes and any power level changes. Finally, information about an active link can be retrieved at any time.
When the connection is no longer required, LMP can cause disconnection.
Demonstrations
1.1.2. ACL Link Setup
1.1.2.1. Introduction
The Link Manager establishes ACL links by controlling the Baseband; then LMP messages can be used to establish a SCO Link across an existing ACL connection.
1.1.2.2. Demo Interface
1.1.2.3. Output Description
The snapshot of the screen shown above displays the ACL Link Establishment between the Master and Slave devices. The display aspects of the demonstration are:
a) Speed Buttons (Increase and Decrease)
They are responsible for Decreasing or Increasing the speed of the display.
b) Protocol Stack
The Protocol Stack displays the position in the protocol stack, which executes the above procedures.
c) Status Windows (Master and Slave)
The status windows display the status of the Inquiring and Inquiry Scanning Devices. The Devices swap status windows after the Master-Slave Switch.
d) Display Area
The interaction between the Inquiring and Inquiry Scanning Devices is displayed here.
1.1.2.4. Theory and Description
The demonstration shows the messages involved in setting up the ACL link connection.
The Link Controller layer must establish a link between devices before LMP messages can be exchanged.
1) Link Controller Paging
For an ACL link setup the master pages the slave to establish a link between devices before LMP messages can be exchanged.
It does this by the following:
i) The Master sends an ID packet to the slave
ii) The Slave then responds by giving it its ID to the master
iii) The Master sends a Frequency Hopping Sequence (FHS), so that the slave can adjust its CLK accordingly.
iv) The Slave then sends it’s ID to the Master and now both the devices enter in to the Connection Setup State.
2) LMP Connection Setup State:
i) The Master sends a host connection request to the slave.
ii) The Slave responds by either accepting or rejecting the connection request by LMP accepted.
iii) The Master and Slave exchange more messages if there are any Optional Transactions remaining.
iv) After checking it then sends a LMP_ connection complete to the slave.
v) The slave then responds with an LMP_accepted.
1.1.3. SCO Connection on ACL
1.1.3.1. Introduction
Once an ACL link has been setup, either the Master or Slave can request a SCO link setup across the ACL link. Both Master and Slave use an LMP SCO request to initiate a SCO connection setup as discussed in the demo.
1.1.3.2. Demo Interface
1.1.3.3. Output Description
The snapshot of the screen shown above displays the ACL Link Establishment between the Master and Slave devices. The display aspects of the demonstration are:
a) Speed Buttons (Increase and Decrease)
They are responsible for Decreasing or Increasing the speed of the display.
b) Protocol Stack
The Protocol Stack displays the position in the protocol stack, which executes the above procedures.
c) Status Windows (Master and Slave)
The status windows display the status of the Inquiring and Inquiry Scanning Devices. The Devices swap status windows after the Master-Slave Switch.
d) Display Area
The interaction between the Inquiring and Inquiry Scanning Devices is displayed here.
1.1.3.4. Theory and Description
When the Master requests a SCO link, it sends an LMP_SCO_req containing the parameters of the link. SCO link parameters are:
i) SCO handle.
ii) Timing control flags.
iii) DSCO - the SCO delay which indicates when the first SCO slot will happen.
iv) TSCO - the SCO delay which separates SCO slots
v) SCO packet type to use: HV1, HV2, HV3, DV
vi) Air mode coding:m-law,A-law,CVSD.
1.1.4. Role Switch
1.1.4.1. Introduction
Normally, the device which pages becomes the Master and the device that page scans becomes the Slave. The Slave can only transmit reply to a transmission from the Master. The Master also sets packet sizes, SCO intervals, and timing. This means that the Master controls the bandwidth available to the Slave.
1.1.4.2. Demo Interface
1.1.4.3. Output Description
The snapshot of the screen shown above displays the ACL Link Establishment between the Master and Slave devices. The display aspects of the demonstration are:
a) Speed Buttons (Increase and Decrease)
They are responsible for Decreasing or Increasing the speed of the display.
b) Protocol Stack
The Protocol Stack displays the position in the protocol stack, which executes the above procedures.
c) Status Windows (Master and Slave)
The status windows display the status of the Inquiring and Inquiry Scanning Devices. The Devices swap status windows after the Master-Slave Switch.
d) Display Area
The interaction between the Inquiring and Inquiry Scanning Devices is displayed here.
1.1.4.4. Theory and Description
1. Master initiated Role Switch:
During this an FHS packet is used to synchronize the two packets. The 1.25 ms accuracy of an FHS packet is not sufficient to allow the two devices to synchronize, so the device that starts as Slave uses an LMP_slot_offset message to send the difference between its CLK and the other device’s CLK.
2. Slave initiated Role Switch:
If the Slave requests the switch, it sends this message before the LMP_switch_req. if the Master requests the switch, the Slave sends LMP_slot_offset before the LMP_accepted message.
If the role change is accepted, the Slave must take over as the Master that implies that the Master must synchronize to the Slave’s Bluetooth CLK. After the FHS packet has been acknowledged, both devices switch to the new timing.
1.1.5. Multi-slot Packets
1.1.5.1. Introduction
When a link is first set up, it uses single-slot packets by default Multi-Slot packets make more efficient use of bandwidth. Because Master’s often have links to several Slaves, it is the Master that usually has the toughest constraints on available slots, so the Master gets to choose the packet type used on a link.
1.1.5.2. Demo Interface
1.1.5.3. Output Description
The snapshot of the screen shown above displays the ACL Link Establishment between the Master and Slave devices. The display aspects of the demonstration are:
a) Speed Buttons (Increase and Decrease)
They are responsible for Decreasing or Increasing the speed of the display.
b) Protocol Stack
The Protocol Stack displays the position in the protocol stack, which executes the above procedures.
c) Status Windows (Master and Slave)
The status windows display the status of the Inquiring and Inquiry Scanning Devices. The Devices swap status windows after the Master-Slave Switch.
d) Display Area
The interaction between the Inquiring and Inquiry Scanning Devices is displayed here.
1.1.5.4. Theory and Description
For the control of Multi- Slot packets, the Master’s imposes a maximum packet size on the Slave by sending an LMP_max_slot command.
The Slave cannot refuse, so there is no need for an LMP)_accepted reply (the baseband acknowledgement scheme ensures that the LMP message is reliably transmitted).
If the Slave wishes to change the maximum packet size, it can send the Master an LMP_max_slot_req. if the Masteris willing to allow the Slave to use this packet size, it replies with an LMP_accepted; otherwise, it sends an LMP_not_accepted and the Slave must stick to the previous maximum packet size.
1.1.6. Power Control
1.1.6.1. Introduction
The transmit power emitted by the radio should be kept to a minimum to extend battery life, as well as to minimize interference.
If the Bluetooth piconets operate close to each other, their radio transmission will tend to interfere. The lower the power the lesser the interference there will be with adjacent piconets, so using minimal power allows more piconets to exists in a given space.
There are limits to the radio power allowed for Bluetooth Devices, so eventually there comes a point where the power cannot be increased any more, no matter how bad reception is. To avoid repeatedly making request that the far end cant satisfy, the LMP provides reply messages to tell a device requesting an increase in power when the power cannot be changed as requested.
1.1.6.2. Demo Interface
1.1.6.3. Output Description
The snapshot of the screen shown above displays the ACL Link Establishment between the Master and Slave devices. The display aspects of the demonstration are:
a) Speed Buttons (Increase and Decrease)
They are responsible for Decreasing or Increasing the speed of the display.
b) Protocol Stack
The Protocol Stack displays the position in the protocol stack, which executes the above procedures.
c) Status Windows (Master and Slave)
The status windows display the status of the Inquiring and Inquiry Scanning Devices. The Devices swap status windows after the Master-Slave Switch.
d) Display Area
The interaction between the Inquiring and Inquiry Scanning Devices is displayed here.
1.1.6.4. Theory and Description
1. Successfully changing Power levels
Whenever a device wishes to change power levels at the far end of the link simply sends an LMP_incr_power_req to increase power or an LMP_decr_power_req to decrease power.
There is no need for an LMP_accepted response to these requests, because if the request is not received, the request is not received, the requesting device will detect that the power is still at the wrong value and re-issue the request.
2. Failing to change Power levels
When the LMP fails to change power levels, the
a) LMP_max_power is returned if a device requests an increase in power is at maximum
b) LMP_min_power is returned if a device request a decrease in power when a power is at minimum.
1.1.7. Name Request
1.1.7.1. Introduction
Every Bluetooth device has a user-friendly name which can be up to 248 bytes long. LMP provides the LMP_name_req message to request a user friendly name and the LMP_name_res message to respond with the name.
All the LMP messages are carried in DM 1 packets, and the data payload in a DM1 packet is only 17 bytes. One byte is used to identify the LMP message, so this only leaves 16 bytes, not enough to carry a 248 bytes.
However, LMP solves this problemby using a series of a message to pass fragments of the user friendly name as delineated in the demonstration.
1.1.7.2. Demo Interface
1.1.7.3. Output Description
The snapshot of the screen shown above displays the ACL Link Establishment between the Master and Slave devices. The display aspects of the demonstration are:
a) Speed Buttons (Increase and Decrease)
They are responsible for Decreasing or Increasing the speed of the display.
b) Protocol Stack
The Protocol Stack displays the position in the protocol stack, which executes the above procedures.
c) Status Windows (Master and Slave)
The status windows display the status of the Inquiring and Inquiry Scanning Devices. The Devices swap status windows after the Master-Slave Switch.
d) Display Area
The interaction between the Inquiring and Inquiry Scanning Devices is displayed here.
1.1.7.4. Theory and Description
In the demonstration we have discussed the example that can be described as follows.
If a host has a name “My Bluetooth Device” the sequence that is used is as follows:
a) In the first LMP_name_req, the name offset is 0, so the first 14 bytes of the name are retrieved.
b) The requesting device keeps adding 14 to the offset until it has retrieved the whole name.