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.
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.