Link Manager, HCI and L2CAP David Mackie

And how they relate to Bluetooth over IP May 2004

Link Manager, HCI & L2CAP

And how they relate to Bluetooth of IP

This is a report on the investigation of the three adjacent protocols/layers in the Bluetooth specification that show most promise of being related to my project.

  1. Link Manager (module)
  2. Host Controller Interface (interface, optional)
  3. L2CAP (host)

Link Manager (LM)

Link Manager (LM) can be seen as an interface to the Baseband layer, but shows some software characterises. As the name implies the LM “manages” communication links between different Bluetooth devices;

  1. Link configuration and information
  2. Piconet management
  3. Security management

The LM uses the Link Management Protocol (LMP) to communicate with remote LMs and is in the form of a simple command/response or request/response. The protocol is very primitive and Morrow compares it to an assembly like language with very simple primitives that need to be used together to accomplish simple tasks. Access to the LM by the application (or higher protocols such as L2CAP)would be done though the HCI where a simple HCI command will entail a number of LCP packets being sent.

Host Controller Interface (HCI)

Host Controller Interface (HCI) is not in fact a layer in the protocol stack but rather an optional interface between a host computer and a Bluetooth module such as in a USB dongle. This is especially non manufactory dependent so as to allow improbability between different modules and host software/drivers.

L2CAP

L2CAP acts as the middle manager between application and the Bluetooth link controller and once a connection has been established (by Link Manager) it handles the actual data communication between devices from the higher layers. Its main functions are:

  1. Protocol Multiplexing
  2. Segmentation and reassembly of packets
  3. Quality of Service
  4. Group Management

The L2CAP layer makes no reference to master-slave relationship within a Piconet and tries to make it as irrelevant as possible so communication would seem to be peer-to-peer. It is usually the first software layer in the stack and is found on the host computer. This is the main reason why it is the most interesting for this project as it the easiest layer to communicate with and modify. It acts as a conduct on an ACL link between Bluetooth devices. Since there is only one ACL link between any two devices it needs to multiplex a number of different higher protocols. This is done by creating virtual channels between devices such as with ATM networks. These can be connection-orientated (CO) channels such as between an application on one device to an application on another device. Or connectionless (CL) channels which are usually from one master to a number of slaves simultaneous. The endpoint of each of these channels is designated by a channel identifier (CID) with L2CAP and is determined locally and communicated to other devices wanting to talk to the local device. Multiple channels can be set up between different host applications but there is at least one channel called the signalling channel and is set-up by default when the ACL link was created. Though we do not use the terminology master and slave, all these communication channels are only form master to slave and slave to master as slaves cannot talk directly to each other.

L2CAP is similar to the LM in that it communicates with three different entities;

  1. vertically with the higher protocols (L2CA)
  2. horizontally with remote L2CAP layer (L2CAP)
  3. vertically to lower layers usually across the HCI (LP)

These communications are labelled using the prefixes L2CA, L2CAP and LP respectively. All incoming messages are called events and outgoing messages actions. There are a number of serve primitives that are used to simplify the identification of particular messages which are just mentioned here, requests (req), indications (ind), responses (rsp) and confirmations (cnf).

L2CAP for this project

Since L2CAP is a multiplexer of all the higher protocols, except for real-time voice, it is the logical place for initial investigation for this project. L2CAP has a large set of well defined service primitives defined in the specification, though how they are implemented is up to the developer. What is defined is the parameters required by the L2CAP layer for the creating any associated L2CAP command packets for transfer to remote L2CAP layers. It would be logical to place any packet forwarding/tunnelling services at this layer.

  1. well defined input and expected outputs
  2. layer is in software, easily modifiable
  3. multiplexer of protocols (handle one, handle all)
  4. able to communicate to LM for initial set up of channels

1

hell1.doc