The lower transport protocols are optimized to deal with the hostility of the RF transmission medium, user requirements for low cost and power consumption, security concerns, regulatory issues, and so on. These design points have led to, among other things, selection of the TDD, polling-based medium access protocol at the baseband. While this approach is suitable for operation of Bluetooth systems in the 2.4 GHz ISM band, the small size of a BB_PDU does not fare so well with the much larger packet sizes typically encountered with Internet and other similar traffic.
It was thus recognized early on that an adaptation layer was needed to move larger upper-layer PDUs and smaller lower-layer PDUs back and forth among the protocol stack layers. This adaptation layer was originally called level 2 medium access control (MAC-2), at a time when MAC-1 represented the medium access control protocol at the baseband level. But the name MAC-1 never prevailed, and so MAC-2 did not apply either. It was therefore decided late in the summer of 1998 to change the name from MAC-2 to a more descriptive one, and the name logical link control and adaptation protocol (L2CAP) came into being. Incidentally, shortly after the first L2CAP draft specification was produced in September 1998, a portion of that specification was split out into its own independent document, spawning a brand-new activity in the SIG. Specifically, the Bluetooth discovery protocol (BDP) section of the MAC-2 and early L2CAP specifications grew in scope and resulted in the service discovery protocol (SDP) specification highlighted in the next chapter. This chapter describes L2CAP, which is certainly one of the most important layers in the stack.
In the reference implementation shown in Figure 6.1 in the previous chapter, the L2CAP layer[1] is a software component that resides within a host. To permit L2CAP and higher protocol layers and applications to transfer and receive control and application data to and from any vendor's Bluetooth module in a standardized way, the SIG has developed a protocol that allows the host to communicate to the module in an interoperable manner. This protocol is the host controller interface (HCI), supplemented with a series of HCI transport protocols, which are mechanisms used to transfer HCI data across various physical connectors, like USB ports, RS-232 ports, and so on. This chapter also discusses HCI and its transport protocols.
Figure 7.1 is a refinement of Figure 6.1 and depicts the placement of the transport protocols in a reference implementation of a Bluetooth device. Note that the link manager and host I/O block in Figure 6.1 has been separated into two logical components, which may nevertheless run on the same firmware platform. The host controller interacts with both the host and the Bluetooth module hardware and firmware components to transfer data between them. On the host side, the HCI layer executes the HCI communications protocol to carry data to and from the module (through the host controller) and the host itself.
The primary role of the L2CAP layer is to hide the peculiarities of the lower-layer transport protocols from the upper layers. By doing so, a large number of already developed higher-layer transport protocols and applications can be made to run over Bluetooth links with little, if any, modification.
The L2CAP layer concerns itself only with asynchronous information (ACL packet) transmission. Its packets, referred to as L2CAP_PDUs, are carried on ACL BB_PDUs whose L_CH field in the payload header has the value 'b10', denoting the start of an L2CAP_PDU, or 'b01', denoting the continuation of an L2CAP_PDU (see Table 6.5 in the previous chapter). Even though L2CAP_PDUs are closely associated with ACL BB_PDUs, the lower transport protocol concepts of master, slave, polling, frequency hopping sequences, native clocks, and so on are meaningless at the L2CAP layer. The lower transport layers provide the equivalent of a packet interface to L2CAP over which L2CAP sends and receives its data and control messages, but L2CAP and higher layers are otherwise insulated from the lower transport protocols.
The L2CAP layer supports higher-layer protocol multiplexing, compensating for the lack of such support at the lower transport layers. Furthermore, it facilitates the segmentation and reassembly of larger-size, higher-layer packets to and from the smaller baseband packets. Since no knowledge of BB_PDUs exists at the L2CAP layer, not to mention knowledge of their transmission size, the L2CAP layer itself does not perform segmentation and reassembly of lower-layer PDUs. However, it facilitates these operations by providing L2CAP_PDU length information in its PDUs, allowing a reassembly engine to verify that it has reconstructed the PDU correctly. Moreover, the L2CAP layer exports maximum-packet-size information to higher layers that informs them of the largest packet size that L2CAP layers in other devices can handle. It is the responsibility of the higher layer to fragment its information into packets that do not violate the L2CAP maximum packet size.
In addition, the L2CAP layer supports the exchange of quality-of-service (QoS) information, which aids in controlling the transmission resources in a way that supports the expected QoS. Finally, the L2CAP layer also provides a group abstraction to higher layers. This allows mapping groups of higher-layer protocol addresses into piconets without exposing the concept of a piconet to the higher layers.
The L2CAP layer assumes that the underlying transmission facilities (that is, the lower transport protocols) provide a full-duplex communication channel that delivers L2CAP_PDUs in an orderly manner. L2CAP itself does not provide any mechanisms for securing the reliable transmission of its PDUs. Instead, it relies upon the retransmission process at the baseband layer to support a sufficiently reliable communication channel for higher layers.
Communication between L2CAP layers is based on logical links, called channels, through which L2CAP traffic flows between endpoints within each device. Each endpoint of a channel is assigned a unique channel identifier (CID). A CID is a 16-bit identifier that is locally administered. An L2CAP layer assigns a different CID to every channel endpoint used therein.[2]
Figure 7.2. L2CAP channels; although not shown, every endpoint is associated with a payload recipient entity.
Figure 7.2 shows the L2CAP layers in three devices exchanging information using L2CAP channels. Each channel terminates at an endpoint within the L2CAP layer. Each L2CAP endpoint is uniquely associated with a payload recipient entity to which the payload of the L2CAP_PDU is directed for additional processing. The payload recipient entity may reside within the L2CAP layer itself and be used for signaling purposes between communicating L2CAP layers. The payload recipient entity may also reside above the L2CAP layer, in which case it represents the higher layer whose PDUs are transported across Bluetooth links by the L2CAP layer.
The figure identifies the various types of L2CAP channels currently defined. There are persistent connection-oriented (CO) channels that are used for bidirectional communications; these require a connection signaling exchange prior to being established. There are ephemeral connectionless (CL) channels that are unidirectional and can be used for broadcast transmissions to groups of devices. Since these channels are unidirectional, a device that needs to respond to a connectionless L2CAP transmission must use another channel to do so. Finally, there are signaling channels that are used primarily to exchange control information that is used to establish and configure CO channels. Signaling channels borrow features from both CO and CL channels. Just like CL channels, they do not require an explicit connection establishment prior to commencing communications over them, but they are persistent and bidirectional in that information flows in both directions over the same signaling channel.
A number of CIDs are reserved for well-defined, globally known channels, while the remaining CIDs are administered as needed. Table 7.1 summarizes the various CID types. Between two devices there can be many CO and many CL channels, but only one signaling channel, since there exists only one CID that can be assigned to both endpoints of the signaling channel. Owing to this restriction, each signaling channel can be viewed as a CO channel whose connection phase has been eliminated because the CID information defining that channel is already known to the devices; thus the channel is preconfigured with fixed parameters.
Table 7.1. The CID assignment types.
|
CID |
Comments |
|---|---|
|
'0x0000' |
null identifier, not to be assigned |
|
'0x0001' |
CID for both endpoints of an L2CAP signaling channel |
|
'0x0002' |
CID for the destination endpoint of a CL L2CAP channel |
|
'0x0003'–'0x003F' |
range of reserved CIDs |
|
'0x0040'–'0xFFFF' |
range of CIDs allocated on demand by a device to its local endpoints for either CL or CO L2CAP channels |
At the outset the MAC-2 protocol (L2CAP's predecessor) was to provide only connectionless services to the upper layers. Over time it was recognized that for this layer to be extensible and to remain relevant and amenable to future enhancements (such as support for quality of service), it needed to provide configurable traffic services. The latter need led to the development and inclusion of configurable connection-oriented services in the L2CAP layer. Today this connection-oriented service is the primary one provided by the L2CAP layer. In version 1.0, only the TCS-based telephony profiles (described in Chapter 13) require the use of CL L2CAP channels.
There are two types of L2CAP_PDUs: the first is used with CO channels and the second with CL channels. Signaling L2CAP_PDUs are formed according to the former type.
Table 7.2 summarizes the fields of a CL L2CAP_PDU in the order of transmission. Note that each header field uses a little-endian byte order with the least significant byte transmitted first; all fields in the L2CAP_PDU headers follow this little-endian transmission convention.
Table 7.2. The format of a connectionless L2CAP_PDU.
| field | size | comments |
|---|---|---|
|
|
L2CAP_PDU_CL_Header | |
|
Length |
2 bytes |
total length in bytes of this L2CAP_PDU excluding the Length and CID fields≥2) |
|
Destination_CID |
2 bytes |
indicates the CID of the destination endpoint of the L2CAP channel used for this transmission: has fixed value '0x0002' |
|
PSM |
≥2 bytes |
protocol and service multiplexer |
|
|
L2CAP_PDU_CL_Payload | |
|
Payload |
(Length – PSM_field_size) bytes |
CL L2CAP_PDU payload data; the maximum possible size is 65,535 bytes minus the size of the PSM field, which typically is 2 bytes |
The PSM field provides the means for identifying the higher-layer recipient of the payload of this connectionless L2CAP_PDU. It is discussed in more detail below along with the signaling L2CAP_PDUs for CO channels. The minimum supported value for maximum transmission unit (MTU) for payloads in CL L2CAP_PDUs is MTU CL = 670 bytes, unless explicitly stated otherwise, say, in a profile specification.[3]
Table 7.3 summarizes the fields of a CO L2CAP_PDU in the order of transmission. As mentioned earlier, each header field uses a little-endian byte order with the least significant byte transmitted first.
Table 7.3. The format of a connection-oriented L2CAP_PDU.
| field | size | comments |
|---|---|---|
|
|
L2CAP_PDU_CO_Header | |
|
Length |
2 bytes |
total length of this L2CAP_PDU excluding the L2CAP_header(≥ 0) |
|
Destination_CID |
2 bytes |
indicates the CID of the destination endpoint of the L2CAP channel used for this transmission |
|
|
L2CAP_PDU_CO_Payload | |
|
Payload |
Length bytes |
CO L2CAP_PDU payload data; the maximum possible size is 65,535 bytes |
Comparing the headers of the CL and CO L2CAP_PDUs, one may notice a subtle difference in the definition of the corresponding Length fields. The PSM field in a CL L2CAP_PDU is treated as if it were part of the payload, hence its size is accounted for when calculating the Length field. This difference is intended to maximize code reuse when processing L2CAP_PDUs of either type.
The MTU for payloads in CO L2CAP_PDUs, MTU CO, as well as other parameters of a CO channel, are negotiated during the connection establishment phase using the L2CAP signaling discussed in the following section.
Connection-oriented, point-to-point L2CAP channels use signaling to become established, to be configured, and to be terminated. During the connection establishment phase, the payload recipient entity in an upper layer of L2CAP_PDUs is identified and the endpoint CIDs for the newly formed channel are exchanged between the two communicating L2CAP layers. During the connection establishment phase, the properties for each direction of transmission on the channel are negotiated and agreed upon. These properties include the payload MTUs, the reliability level of transmissions between the involved devices, and QoS.
L2CAP signaling consists of request and response PDU transactions carried over the signaling channel whose endpoints both have the reserved CID value '0x0001'. A device, referred to as the local device, sends an L2CAP signaling request PDU (for example, to create or configure a channel) to a remote device, and the remote device responds to the local device's request with a corresponding L2CAP signaling response PDU. Each transaction is identified by a transactionID that matches a request from a local device with the subsequent response from the remote device. Contrary to other L2CAP_PDU transmissions, L2CAP signaling transactions are reliable in that a local device may retransmit a request if a response is not received within a timeout period. The decision about whether or not to retransmit a request, as well as the value of the timeout period, are implementation dependent. The timeout period is at least 1 second and can be up to 60 seconds. A local device may wait up to an additional 300 seconds to receive the final response if the remote device has responded indicating that it has received an initial request but needs additional time to complete its processing. For example, a request for connection may require a device authentication to occur first, which in turn, may require the device to enter a PIN as discussed in Chapter 6.
Figure 7.3. The management and data-exchange phases of a CO channel and the local/remote device roles.
Figure 7.3 shows a typical sequence of L2CAP signaling transactions between a local and a remote device. This sequence starts with the L2CAP layer of the local device transmitting a request for the creation of a channel between the devices. The remote device responds by either accepting or rejecting the request. Upon acceptance of the request and establishment of the channel, the local device initiates configuration of the channel for one direction of communication. The configuration parameters are dictated by the implementation limitations of the L2CAP layer, including the L2CAP MTU that can be used on this channel and the QoS requirements of the applications that will be using this channel. The remote device responds positively or negatively to the local device's configuration parameters. A negative response causes a configuration negotiation phase between the devices until they both agree upon the configuration parameters. Following the termination of configuration in one direction, the devices exchange their local and remote roles and the configuration process continues likewise in the opposite direction. Upon termination of the configuration phase, the channel is ready to receive and transport PDUs from higher layers over the newly established channel. Subsequent channel reconfiguration could happen at any time that the channel is active and could be initiated by either device. The L2CAP channel terminates when either device initiates the termination phase.
The header of the L2CAP signaling PDUs resembles that of a CO L2CAP_PDU, with the destination endpoint CID field having the reserved CID value '0x0001'. The payload of the signaling PDUs consists of a collection of signaling commands. All L2CAP implementations must be able to accept signaling PDUs with an MTU SIG of 48 bytes. Table 7.4 summarizes the fields of a signaling command.
Table 7.4. The format of an L2CAP signaling command.
| field | size | comments |
|---|---|---|
|
|
L2CAP_Signaling_Command_Header | |
|
Code |
1 byte |
identifies the command type |
|
Identifier |
1 byte |
identifies the signaling transaction, transactionID, for matching responses to corresponding requests; retransmitted commands use the same identifier |
|
Length |
2 bytes |
total length of the payload portion of this command (≥ 0) |
|
|
L2CAP_Signaling_Command_Payload | |
|
Payload |
Length bytes |
signaling command payload data (collection of signaling commands) |
Signaling commands with an unsupported code result in an L2CAP_Command_Reject command (Code = '0x01') being transmitted in the reverse direction.
When a local device wants to establish a CO L2CAP channel with a remote device, it forms and sends an L2CAP_Connection_Request signaling command (Code = '0x02') to the remote device. The significant fields of the command are summarized in Table 7.5; note that the table does not show all the fields of the command and must be interpreted with respect to the signaling-command format in Table 7.4.
Table 7.5. The L2CAP_Connection_Request signaling command.
| field | size | comments |
|---|---|---|
|
|
L2CAP_Connection_Request_Command_Payload | |
|
PSM |
≥ 2 bytes |
identifies the destination payload processing entity for the L2CAP_PDUs transmitted to the remote device over the requested channel |
|
Source_CID |
2 bytes |
the CID for the requested channel endpoint in the local device |
If and when the channel is established, the remote device will use the value in the Source_CID field as the Destination_CID (see Table 7.3) to send L2CAP_PDUs to the local device over this CO channel.
The PSM (protocol and service multiplexer) field is a variable-size field with a minimum (and typical) size of 2 bytes. It is used for multiplexing several protocols over the L2CAP layer. In particular, the local device uses the PSM field to inform the remote device about where to direct the payload of the L2CAP_PDU transmissions over this channel.
Although the PSM field is used for multiplexing middleware protocols that use L2CAP's transport services, like SDP, RFCOMM, TCS, and so on, it goes a step further. PSM could also identify one of many implementations of a protocol layer, or even an entire protocol stack, that reside above L2CAP. For example, a manufacturer could implement two independent RFCOMM layers within a single device. In this case, multiplexing simply on the name of the RFCOMM protocol would not be very helpful. The PSM field aids in distinguishing the two RFCOMM implementations by assigning a different PSM value to each of them.
The range of values for the PSM field is divided into two regions. The first region covers the PSM values up to '0x1000' and consists of reserved values that represent established, well-known protocols that directly use L2CAP, such as SDP (PSM = '0x0001') or RFCOMM (PSM = '0x0003').[4] The region of PSM values above '0x1000' is used to identify multiple implementations of a given protocol above L2CAP (as described above), protocols not yet standardized, experimental protocols under development, and so on. The PSM value for a given connection can be retrieved from service discovery records using SDP as described in the next chapter.
Originally, the PSM field was just a Protocol field, used to identify a specific protocol that could be multiplexed over the L2CAP layer. The L2CAP working group in the SIG realized that enhanced system security requires the ability to identify not just the protocol used but also the application associated with the connection request. In this respect, the L2CAP layer was recognized as the natural choice in which to add any security safeguards. But an L2CAP connection request using just the Protocol field could not identify the application that would ultimately use the connection. Thus, the PSM field was introduced to identify a protocol stack from the L2CAP layer all the way up to the service provided by the application that would use the newly formed channel. Eventually, the group consensus about security at the L2CAP layer took a more general path and is highlighted in [Muller99]. However, the PSM field did not revert back to the Protocol field. It was recognized that the added multiplexing flexibility that the PSM field introduced was too powerful to ignore. Thus, the use of the PSM field has persisted in the specification, although its name is now somewhat outdated, and it can be used to multiplex not only protocols, but multiple stack implementations as well. This feature is truly unique to the L2CAP layer.
Following the receipt of an L2CAP_Connection_Request command, the remote device returns an L2CAP_Connection_Response command (Code = '0x03') to inform the local device whether or not it accepts the connection request. The remote device could also return a connection pending response to inform the local device that the connection request has been received but no decision has been made yet; the remote L2CAP layer could, for example, await the result of an authentication procedure before deciding to accept or reject the connection. If a connection is refused, the remote device provides the reason(s) for doing so, which could include security issues, resources not available, or PSM value not supported. Finally, the remote device also returns the Destination_CID that identifies the CID of the channel endpoint located in the remote device. This CID is meaningful only if the connection is accepted, and it is used as the Destination_CID field of the CO L2CAP_PDUs that the local device subsequently sends to the remote device over this CO channel.
Following channel establishment, the channel needs to be configured. The channel configuration transaction is mandatory; however, empty configuration commands may be sent when nothing needs to be configured. Configuration transactions for a channel may occur again at a later time after normal communications have commenced for the channel. The key fields of the L2CAP_Configuration_Request command (Code = '0x04') are summarized in Table 7.6.
Table 7.6. The L2CAP_Configuration_Request signaling command.
| field | size | comments |
|---|---|---|
|
|
L2CAP_Configuration_Request_Command_Payload | |
|
Destination_CID |
2 bytes |
for the channel to be configured, identifies the CID of the channel endpoint in the device that receives this command (the remote device) |
|
Flags |
2 bytes |
in version 1.0, only the LSB is used to signify that additional configuration options are to follow in a subsequent configuration command from the local device |
|
Config_Options |
variable |
configuration options for the channel to be configured |
The LSB of the Flags field, referred to as the C bit, is used as a continuation flag for additional configuration options to follow in subsequent configuration commands. Segmentation of the configuration options in multiple configuration commands may be necessitated by the small MTU SIG value.
Before examining the configuration options, we discuss the corresponding response command from the remote device, which also contains a similar set of configuration options.
In the L2CAP_Configuration_Response command (Code = '0x05') that corresponds to an L2CAP_Configuration_Request command sent from a local device,[5] the responding (remote) device states whether or not it agrees with the values of the various configurable parameters in the L2CAP_Configuration_Request command. If a configuration option in an L2CAP_Configuration_Request command is not supported by the remote device, it rejects the request and includes in its response a copy of the unsupported option(s).
When an L2CAP_Configuration_Request command is rejected due to disagreement with the values of any of the configurable parameters, the remote device may either terminate the configuration process or provide the values of the parameters that could have been acceptable to it. In this case, the local device may submit a new L2CAP_Configuration_Request command with the configuration parameter values readjusted; the number of successive resubmissions of L2CAP_Configuration_Request commands is implementation dependent. If no agreement is reached between the local and remote devices, the current configuration parameters remain in effect, or the channel is terminated. The duration of configuration negotiations is implementation dependent, but the maximum time is 120 seconds.
Note that any response from the remote device regarding a configuration option is exclusively for the direction of traffic flow implied by the L2CAP_Configuration_Request command. For example, if the configurable parameter in an L2CAP_Configuration_Request command refers to traffic leaving the local device, an outgoing traffic parameter, any reference to this parameter by the remote device will refer to the same traffic parameter arriving at the remote device, an incoming traffic parameter. Following termination of configuration transactions in one direction, the role of the local and remote devices is reversed once and configuration of the channel parameters in the opposite direction may commence. This gives the other device (the former remote device) the opportunity to configure its traffic parameters as well.
Table 7.7 lists the communications parameters that can be adjusted through configuration. The interpretation of these parameters is relative to the local device—that is, the device that originates the L2CAP_Configuration_Request command and contains the configuration option related to these parameters.
Table 7.7. The configuration options.
| parameter | comments |
|---|---|
|
MTU CO |
identifies the maximum L2CAP_PDU payload, in bytes, that the local device can accept over this channel; minimum MTU CO = 48 bytes, default MTUCO = 672 bytes[1] |
|
Flush_Timeout |
identifies the amount of time, in multiples of 1.25 milliseconds, during which the link manager of the local device will continue attempting to transmit the baseband segments from an L2CAP_PDU, prior to discarding it; by default theFlush_Timeout value indicates a reliable channel where PDUs are retransmitted for as long as required, or until the link is declared lost |
|
QoS |
identifies the traffic-flow specification for the local device's traffic (outgoing direction) over this channel |
[1] While the minimum MTUCO was chosen to accommodate buffering capabilities of "simple" devices, such as headsets, the default value was chosen so that it can conveniently fit within two DH5 BB_PDUs. | |
The QoS option includes a Service_Type parameter that determines whether or not traffic will be sent in the outgoing direction by the local device. If yes, then the Service_Type further determines if the outgoing traffic will be treated by the local device as best effort or guaranteed. Best-effort traffic is the default and mandatory service type supported by any L2CAP-layer implementation. With the guaranteed service type, the local device provides the QoS parameters associated with its outgoing traffic flow. These QoS parameters consist of a subset of the ones specified in [IETF92] and include: Token_Rate, Token_Bucket_Size, Peak_Bandwidth, Latency, and Delay_Variation. All of these parameters have default values of "not specified." These values are ultimately communicated to the link manager of the local device, which then negotiates with the link manager of the remote device to determine an appropriate polling interval that supports the desired QoS.
The QoS parameters must be passed to the L2CAP layer from the upper layers. Following any configuration negotiation for these values, the L2CAP layer uses the resulting parameter values to control the admission of new connection requests initiated by upper layers of the stack. Based on their QoS requirements, the L2CAP layer may decide to reject any new connection requests if it concludes that establishing a new L2CAP channel with a remote device could compromise the QoS of any existing channel.
With the exception of MTU CO, the definition and use of the QoS parameters was a source of much debate within the SIG's L2CAP task force. The QoS discussions continued to the very day that the specification was finalized for publication in the summer of 1999. Debate centered around the meaning of the QoS parameters, their applicability, implementation effort required, the way they should be negotiated, and so on. No version 1.0 profile supports anything but best effort traffic; hence, the QoS parameters easily could have been omitted from the version 1.0 specification. While proposals to do just that were circulated, it was finally decided that including QoS parameters in the specification was preferable. Having a standardized set of QoS parameters enables experimentation with them; this could help software developers gain QoS experience such that whenever the need arises in any future profiles for the use of QoS guarantees, a solid foundation of knowledge and implementation experience will exist to efficiently address the problem. Inclusion of the QoS parameters is an example of the SIG addressing future flexibility of the specification rather than an immediate requirement of a version 1.0 usage model.
The most commonly used signaling transactions pertain to the L2CAP_Connection_Request and L2CAP_Configuration_Request signaling commands, together with their corresponding response commands, and a channel termination request and response transaction using the L2CAP_Disconnection_Request/_Response signaling commands. L2CAP signaling also provides two additional exchanges used for testing and information gathering.
The L2CAP_Echo_Request and L2CAP_Echo_Response command transaction is used to test the connection to a remote device, in a manner similar to the ping command in IP networks. The echo commands contain an optional payload portion, which could be used to pass information between the devices in a nonstandard, proprietary (vendor-specific) manner.
The L2CAP_Information_Request and L2CAP_Information_Re-sponse command transaction is used to request implementation-specific information. Currently, the only piece of information that can be requested in a standard manner is the value of the connectionless MTU, MTU CL, that the remote device supports. Nonstandard, vendor-specific information could also be requested with this transaction.
The Bluetooth transport protocols can be implemented in an integrated fashion, entirely on the same host (motherboard or processor) that runs the applications that use the transport protocols. On the other hand, they may be implemented independently of the host on a separate Bluetooth module that is then attached to the host as an add-on accessory attachment or a plug-in card, through some physical interface on the host (such as a USB port or an RS-232 serial port). When implemented separately, the module also contains a host controller unit whose responsibility is to interpret the information received from the host and direct it to the appropriate components of the module, like the link manger or the link controller. Likewise, the host controller collects data and hardware/firmware status from the module and passes it to the host as needed. In the reference implementation of a Bluetooth module considered by the SIG, the module contains the radio, the link controller, the link manager and host interfaces for attaching the module to a host, as depicted in Figure 7.1. This reference implementation does not preclude the possibility of other implementations built with different components of the stack.
To permit the interoperable use of nonintegrated modules from different manufacturers, the SIG has defined a standard interface to communicate with the module's host controller in a manner that is independent of the physical interface and transport mechanism used between the host and the host controller. The SIG has also defined a transaction-style communication protocol to carry information between the host and the host controller. This standardized interface between the host controller and the host, together with the corresponding communication protocol between them, is collectively referred to as the host controller interface (HCI).
The HCI portion of the specification is by far the largest one—nearly 300 pages including the HCI transport sections. The SIG's HCI e-mail list is also the most populated and busy one. This should come as no surprise; in a sense, the capabilities of the HCI define what can be accomplished with the Bluetooth technology. Since HCI defines the set of functions of a Bluetooth module that are accessible to the host and its applications, HCI is the gatekeeper of the services that this module can provide to its users. Any feature of the module that is not exposed (or that is not exposed properly) by the HCI limits the functionality of the module and ultimately the potential of Bluetooth wireless communications.
Figure 7.4 shows a protocol stack with an HCI. The HCI part contains a set of interfaces to the higher layers, which the specification defines through a long list of HCI_PDUs.[6] There is also a host driver, or HCI driver, which executes the communication protocol for exchanging the HCI_PDUs with the host controller. Finally, there is the transport protocol that carries the HCI_PDUs across the physical interface, or HCI transport. For the HCI transport, the SIG has not developed any new protocols; instead it has reused three existing ones: the Universal Serial Bus (USB) protocol, the RS-232 serial port protocol, and the universal asynchronous receiver and transmitter (UART) protocol, which is a proper subset of the RS-232 protocol and can be used if the module attaches directly to the UART of a serial port without the need for serial cables. The HCI transport has its own complementary driver components in both the host and module.
Implementation of the HCI is not mandatory and in fully integrated systems may not even be necessary. However, manufacturers of products, both OEMs and component integrators, must provide an HCI-like interface to test their product for compliance with the lower transport protocol test specification as described in the Test Control Interface part of the specification.
Three classes of HCI_PDUs are used to exchange information between the HCI layer[7] in the host and the host controller in the module, as shown in Figure 7.5. There are command-class HCI_PDUs that carry control and management information; these are sent from the HCI layer to the host controller. There are event-class HCI_PDUs that carry control and management information from the host controller to the HCI layer. Finally, there are data-class HCI_PDUs that carry fragments of L2CAP_PDUs and SCO data. The HCI specification splits the latter class into two categories, one for asynchronous L2CAP data and one for synchronous data, but in reality all data-class HCI_PDUs have the same number of fields and identical field delineation. As such, the two categories of data-class HCI_PDUs are better interpreted as two different modes of the same HCI_PDU class. Information in HCI_PDUs is encoded in little-endian format. The figure also includes the physical interface between the host and the module. Based on the type of this interface, a separate HCI transport protocol is used. The figure indicates the three HCI transports defined in the specification: RS-232, UART and USB.
For completeness, Figure 7.5 shows the possible active links that a device might have. Two devices may have at most one ACL link between them. A master may have up to seven active ACL links with its slaves (one per active slave). Also, there may be up to three SCO links between the master and all its slaves in a piconet. Note that an ACL link between two devices must exist prior to establishing any SCO links between those devices.
Table 7.8 shows the structure of a command HCI_PDU. It includes an OpCode field used to identify the command type. The payload section of the command consists of a number of parameters that vary by command type.
Table 7.8. The command HCI_PDU.
| field | size | comments |
|---|---|---|
|
|
HCI_Command_Header | |
|
OpCode |
2 bytes |
OpCode group subfield (OGF) (6 bits) identifies the group that the OpCode belongs to:
|
|
|
|
OpCode command subfield (OCF) (10 bits) identifies a specific HCI command within the particular OGF |
|
Payload_Length |
1 byte |
length of the payload of the command HCI_PDU in bytes |
|
|
HCI_Command_Payload | |
|
Payload |
Payload_Length bytes |
the payload of a command HCI_PDU is structured as a sequence of variable-size fields for the various parameters related to this command |
Table 7.9 shows the structure of an event HCI_PDU. Similarly to a command HCI_PDU, it consists of an Event_Code field used to identify the event and a payload section with a number of parameters which are relative to this event HCI_PDU.
Table 7.9. The event HCI_PDU.
| Field | size | comments |
|---|---|---|
|
|
HCI_Event_Header | |
|
Event_Code |
1 byte |
identifies the event
|
|
Payload_Length |
1 byte |
length of the payload of the event HCI_PDU in bytes |
|
|
HCI_Event_Payload | |
|
Payload |
Payload_Length bytes |
the payload of an event HCI_PDU is structured as a sequence of variable-size fields for the various parameters related to this event |
A host uses the command HCI_PDUs for things like:
setting operational parameters of the module, such as providing a link key for authentication;
configuring the module's operational status and related parameters, for instance causing it to activate and set the related parameters for a low power mode;
reading and writing register entries, like the number of broadcast packet repetitions, N BC, and so on.
Depending upon the command, module registers will be read or set, the link manager will execute an LMP transaction, the link controller will change state and execute, say, a page, and so on. The host controller notifies the host of the outcome of the command with an event HCI_PDU either soon after the command is sent from the host or at a later time when appropriate—for example, following the termination of an LMP transaction. The reason that host controller HCI_PDU transmissions to the host are called events and not responses is that the host controller may initiate its own request (for instance, requesting a missing link key from the host) or send a transmission to the host without the host's prior action (perhaps notifying it of a connection request coming from a remote device). Actually, some of the command HCI_PDUs sent from the host are simply responses to event HCI_PDUs that originated from the host controller. For example, the HCI_Accept_Connection_Request command is sent by the host to the host controller instructing the latter to accept an incoming connection request from a remote device. Before the host transmits the HCI_Accept_Connection_Request command, the host controller notifies the host of the incoming connection request with a Connection_Request event.
Table 7.10 shows the structure of a data HCI_PDU.
Table 7.10. The data HCI_PDU.
| field | size | comments |
|---|---|---|
|
|
HCI_Data_Header | |
|
Connection_Handle |
12 bits |
identifies the baseband link over which these data are transmitted or received; connection handles in the range '0xF00' to '0xFFF' are reserved for future use |
|
Flags |
4 bits |
ACL transmissions: composed of two subfields:
|
|
|
|
SCO transmissions: reserved field |
|
Payload_Length |
2 bytes |
length of the payload of the data HCI_PDU in bytes |
|
|
HCI_Data_Payload | |
|
Payload |
Payload_Length bytes |
data to be carried over the ACL or SCO baseband link identified by the contents of the Connection_Handle field |
Transmission of data HCI_PDUs across the physical interface is regulated by the buffer sizes available on the receiving side of the PDU. Both the host and the host controller inquire about the buffer size available for receiving data HCI_PDUs on the opposite side of the interface and adjust their transmissions accordingly. This implies that a large L2CAP_PDU may need to be fragmented within the HCI layer prior to sending it to the host controller. On the receiving side, the HCI layer could reconstruct L2CAP_PDUs based on the packet boundary flag information within the received data HCI_PDUs. Transmission of HCI_PDUs across the physical interface is in first-in-first-out order without preemption. Commands are processed by the host controller in their order of arrival, but they may complete out of order since each might take a different amount of time to execute. Similarly, events are processed by the host in order of arrival, but their processing may terminate out of order.
Note that none of the fields in any of the HCI_PDUs identifies the HCI_PDU class: command, event or data. Identification of the HCI_PDU class is left to the HCI transport protocol that actually carries the PDUs between the host and the host controller. Strictly speaking, this is a violation of protocol layering. However, it allows the HCI to take advantage of the capabilities of the underlying transport protocol, which may provide its own means for distinguishing the three HCI_PDU classes with minimal overhead. Purists may wish to consider that the HCI layer in the host and its complementary part in the host controller consist of a transport-independent sublayer, and a transport dependent convergence sublayer (which executes the HCI transport protocol) that adapts the HCI_PDUs to the particular transport method used to carry them across the physical interface.
There are many command HCI_PDUs organized into several groups identified by the OGF subfield in the header of the command HCI_PDU. For many of these command HCI_PDUs there exists a corresponding event HCI_PDU that carries the outcome and return parameters related to the command. For several commands, information related to their status and execution results is carried by two special events: Command_Status_Event and Command_Complete_Event. The former typically is sent immediately after a command is received by the host controller to indicate the status of the command, such as command pending execution, command not understood, and so on. This provides a sort of acknowledgement of the command along with an indication of its processing status. The latter is used to indicate the completion of execution of a command and to return related parameters, including whether or not the requested command was executed successfully. Observe that multiple events might be generated in response to a single command.
There are command HCI_PDUs related to link controller actions, policy-setting commands, the host controller itself, and many others. Command and event HCI_PDUs number over 100; some of these are highlighted in the following sections. These selected HCI_PDUs are illustrative of the type of information and the level of detail that is communicated between the host and the host controller. For the full set of HCI_PDUs, refer to the specification.
The commands in this group are identified via the OGF subfield with the value 'b000001'. This group contains commands that allow inquiries to be sent to discover other devices in the vicinity. There are commands to create and terminate ACL and SCO connections and to accept or reject incoming connection requests. There are commands for initiating authentication and encryption procedures as well as for transporting authentication keys and PINs from the host to the link controller. There are information commands in this group to request the user-friendly name of the remote device, the link manager options that it supports and the clock offset registered in the remote device.
Following are some examples of HCI_PDUs in this group. The HCI_Inquiry command PDU instructs the module to enter the inquiry mode, using a given inquiry access code, for a specified amount of time or until a specified number of responses is collected. This command is summarized in Table 7.11.
Table 7.11. The HCI_Inquiry command HCI_PDU.
|
Command_Name |
HCI_Inquiry | ||
|---|---|---|---|
|
OCF |
'b0000000001' | ||
|
Parameters |
LAP |
3 bytes |
lower address part used for generating the inquiry access code |
|
|
Inquiry_Length |
1 byte |
indicates the maximum duration for this inquiry: 1.28 sec - 61.44 sec |
|
|
Num_Responses |
1 byte |
indicates the maximum number of responses to be collected |
The inquiry mode originated by this command terminates either when Inquiry_Length time has elapsed or when the number of responding devices reaches Num_Responses, whichever occurs first.
The host controller returns information collected from inquiries to the host with the Inquiry_Result_Event [8] summarized in Table 7.12; the parameters of the event are derived from the FHS BB_PDUs (detailed in the previous chapter) that are received from the devices responding to the inquiries. A brief description of the parameters below is given in Table 7.13, which presents the command that uses these parameters.
Table 7.12. The Inquiry_Result_Event event HCI_PDU; the index i identifies each of the Num_Responses responding devices.
|
Event_Name |
Inquiry_Result_Event | |
|
Event_Code |
'0x02' | |
|
Parameters |
Num_Responses |
1 byte |
|
|
BD_ADDR[i] |
6*Num_Responses bytes |
|
|
Page_Scan_Repetition_Mode [i] |
1*Num_Responses byte(s) |
|
|
Page_Scan_Period_Mode[i] |
1*Num_Responses byte(s) |
|
|
Page_Scan_Mode[i] |
1*Num_Responses byte(s) |
|
|
Class_of_Device[i] |
3*Num_Responses bytes |
|
|
Clock_Offset[i] |
2*Num_Responses bytes |
The HCI_Create_Connection command PDU instructs the module to create a connection with a specified device, using a given set of BB_PDU types for the ACL link. Since the connection process requires that the "local" device page the "remote" device, this command also provides information used to accelerate the paging process. The paging information becomes available to the host of a local device via an earlier Inquiry_Result_Event PDU, shown in Table 7.12. The HCI_Create_Connection command is summarized in Table 7.13.
Table 7.13. The HCI_Create_Connection command HCI_PDU.
|
Command_Name |
HCI_Create_Connection | ||
|
OCF |
'b0000000101' | ||
|
Parameters |
BD_ADDR |
6 bytes |
identifies the remote device with which to establish a connection |
|
|
Packet_Type |
2 bytes |
indicates which BB_PDU types can be used by the link manager for the ACL link |
|
|
Page_Scan_Repetition_Mode |
1 byte |
indicates the page scan repetition mode, that is, how frequently the remote device enters the page scan mode, last reported by the remote device |
|
|
Page_Scan_Mode |
1 byte |
indicates the page scan mode supported by the device |
|
|
Clock_Offset |
2 bytes |
indicates the difference between the slave and master clocks, as calculated in the last communication between them |
|
|
Allow_Role_Switch |
1 byte |
indicates whether this (the paging) device will be the master or will allow the paged device to become the master if requested[1] |
[1] Master-slave role switching is described in the previous chapter. | |||
Upon successful creation of the connection, a Connection_Complete_Event is sent to the hosts on both sides of the connection. The events contain the Connection_Handles for identifying the connection. The connection handles are assigned by each host controller independently and their scope is limited to the local device only.
The commands in this group are identified via the OGF subfield with the value `b000010'. This group contains commands that allow a device to set a power-management policy through the hold, sniff, and park baseband modes and to define the parameters for those modes. Also, there are commands that pass QoS parameters from the L2CAP layer to the link manager, learn about the role (master or slave) that the device[9] plays for a particular connection and request a role switch if needed.
Table 7.14 summarizes the HCI_PDU command that requests the host controller to instruct the link manager and the baseband to enter hold mode with the parameters provided. Similar commands exist for sniff and park modes.
Table 7.14. The HCI_Hold_Mode command PDU.
|
Command_Name |
HCI_Hold_Mode | ||
|---|---|---|---|
|
OCF |
'b0000000001' | ||
|
Parameters |
Connection_Handle |
2 bytes |
identifies the connection (actually the ACL link) to be placed in hold mode; only the 12 LSBs are used |
|
|
Hold_Mode_Max_Interval |
2 bytes |
indicates the maximum negotiable hold interval (0.625 msec – 40.9 sec) |
|
|
Hold_Mode_Min_Interval |
2 bytes |
indicates the minimum negotiable hold interval (0.625 msec – 40.9 sec) |
The host controller notifies the host when hold mode is entered or is terminated using the Mode_Change_Event.
The commands in this group are identified via the OGF subfield with the value 'b000011'. This group contains commands that allow the host to access and configure various hardware registers that maintain operational parameters. Among the operations that can be performed are determining the types of events that the host controller can generate; reading, writing, and deleting stored keys; reading and writing the user-friendly device name; activating and deactivating inquiry and/or page scans; reading and writing the authentication and/or encryption activity flag for a link; reading and writing the inquiry access codes used to listen during inquiry scans; forcing the flushing of ACL packets for a connection handle; reading and writing the audio codec parameters and so on.
Table 7.15 summarizes the HCI_PDU command that sets the inquiry scan parameters; a similar command exists for page scans as well. Inquiry scans occur only when the host has already sent an HCI_Write_Scan_Enable command PDU to enable inquiry scans.
Table 7.15. The HCI_Write_Page_Scan_Activity command PDU.
|
Command_Name |
HCI_Write_Inquiry_Scan_Activity | ||
|---|---|---|---|
|
OCF |
'b0000011100' | ||
|
Parameters |
Inquiry_Scan_Interval |
2 bytes |
determines the interval between successive starts of inquiry scans11.25 msec – 2.56 sec (typically, 1.28 sec) |
|
|
Inquiry_Scan_Window |
2 bytes |
determines the duration of a single continuous scan operation11.25 msec – 2.56 sec (typically, 11.25 msec) |
When the host controller finishes updating the related registers it returns a Command_Complete_Event to the host.
The commands in this group are identified via the OGF subfield with the value 'b000100'. This group includes commands that request static information about the hardware and firmware that is electronically "engraved" on the device at manufacture time. There is a command to request the version of the various protocols (LMP, HCI, and so on) that the module supports; a command to request a list of features supported by the link manager; a command to request the country of operation of the module; a command to request the BD_ADDR of the module;[10] and a command to request the host controller buffer information for ACL and SCO packets, used to execute effective flow control at the host. The requested information is returned in a Command_Complete_Event.
The commands in this group are identified via the OGF subfield with the value 'b000101'. This group includes commands that request information that is dynamically updated, like the value of the contact counter that measures the number of successive instants during which the remote device does not respond to local transmissions, causing the local link manager to flush any PDUs waiting to be transmitted. There is also a command HCI_PDU to retrieve information related to the quality of the link and the RSSI (received signal strength indicator) value. The requested information is returned in a Command_Complete_Event.
In this chapter we have highlighted the upper two Bluetooth transport protocols: L2CAP and HCI. The latter is a transport protocol internal to a device, rather than an over-the-air protocol as are L2CAP and the other protocols discussed in Part 2 of the book. The primary purposes of these protocols are both to hide, in the case of L2CAP, and to expose, in the case of HCI, the internal operation of the lower transport protocols. L2CAP is used to multiplex and transport higher protocol layers while shielding them from the peculiarities of the lower transport protocols, like the baseband. The HCI provides a standardized interface to the services and capabilities provided by the lower transport protocols.
In this and the previous chapters we have presented the protocols that the SIG has developed for transporting data across Bluetooth devices. These protocols have been developed entirely by the SIG specifically for Bluetooth wireless communication. They reflect the SIG's objectives to develop simple, cost-effective communication systems that can operate at low power in noise-susceptible places. In the next chapter we introduce the middleware protocols that are used to take advantage of the data-transport services of the transport protocols to enable a plethora of applications, including legacy applications, to operate smoothly over Bluetooth links.
[1] This layer is more appropriately called "L2CA layer" or "L2CAL," but since L2CAP is phonetically more pleasing than either L2CA or L2CAL, the technically inappropriate usage of the term "L2CAP layer" or even just "L2CAP" has tacitly prevailed. Here, the use of the term "L2CAP" as a noun is reserved primarily for the protocol used to communicate between L2CAP layers in different devices.
[2] Strictly speaking, "local" CIDs assigned by an L2CAP layer need to be unique only within the set of channels that this L2CAP layer establishes with a single "remote" L2CAP layer.
[3] The various L2CAP MTUs discussed in this chapter apply only to the payload section of the corresponding L2CAP_PDUs. Thus, the MTU information is used by the payload recipient entities at the endpoints of an L2CAP channel, see Figure 7.2, to adjust the maximum size of PDUs that they can send or receive over this L2CAP channel.
[4] The values of the PSM field are always odd, thus providing a simple means for extending the PSM field beyond its typical size of 2 bytes.
[5] Recall that we have defined a local device to be the device that originates an L2CAP signaling transaction, which starts with the transmission of a request command. The responding device is the remote device.
[6] Once again, this is not the terminology used in the specification, but it is used here for consistency with the rest of the book.
[7] We collectively refer to the HCI and the HCI protocol driver as the HCI layer.
[8] This event is actually called "Inquiry Result" event. Once again we take liberty in the naming convention for consistency purposes with other PDUs.
[9] Recall that information regarding the role that a device plays in a particular connection does not propagate through the stack beyond the link manager layer. A host needs to explicitly request this information from the host controller.
[10] Recall that the BD_ADDR is hardwired and cannot be modified.