Page 484 - From GMS to LTE

470 From GSM to LTE-Advanced Pro and 5G

The following packet types can be sent over the HCI interface:
Command packets, which the host sends to the link manager in the Bluetooth chip.
●
Response packets, which the Bluetooth controller returns to the host. These packets
●
are also called events, which are either generated as a response to a command or sent
on their own, for example, to report that another Bluetooth device would like to
establish a connection.
User data packets to and from the Bluetooth chip.
●
On the UART interface, the different packet types are identified by a header, which is
inserted at the beginning of each packet. The first byte is used to indicate the packet
type to the receiver. If USB is used as a physical interface for the HCI, the different
packet types are sent to different USB endpoints. The USB polling rate of 1 millisecond
ensures that the user data and event packets which are transmitted from the Bluetooth
chip to the host are detected with only minimal delay.
Today, most Linux distributions for PCs include Bluetooth support and contain a num-
ber of shell commands to trace the standardized HCI interface. The ‘hcitool con’ com-
mand, for example, can be used to show the Bluetooth devices currently connected to the
PC. The ‘hcitool info <device address>’ command can be used to get further information
about a connected device, while the ‘hciconfig’ command executed with a number of dif-
ferent parameters gives further information about the capabilities of the Bluetooth chip in
the PC. Perhaps, the most useful command is ‘hcidump ‐X’, which allows tracing of all
messages and data traversing the HCI interface between the PC’s operating system (Linux)
and the Bluetooth chip. For further analysis, ‘hcidump ‐w dump‐filename’ can be used to
save all packets traversing the HCI interface into a file which can then be opened by packet
trace software such as Wireshark for further analysis.
Figure 7.10 shows how a Bluetooth module is instructed via the HCI interface to estab-
lish a connection with another Bluetooth device. This is done by sending an HCI_Create_
Connection command, which includes all necessary information for the Bluetooth
controller to establish the connection to the remote device. The most important param-
eter of the message is the device address of the remote Bluetooth device. The controller
confirms the proper reception of the command by returning an HCI_Command_Status
event message and then starts the search for the remote device. Figure 7.8 shows how
this search is performed. If the Bluetooth device address is known, the inquiry phase can
be skipped. If the controller was able to establish the connection, it returns an HCI_
Connection_Complete event message to the host. The most important parameter of this
message is the connection handle, which allows communication with several remote
devices over the HCI interface at the same time. In the Bluetooth controller, the connec-
tion handle is directly mapped to the L_CH parameter of an ACL or SCO packet.
Furthermore, there are a number of additional HCI commands and events to control
a connection and to configure the Bluetooth controller. A selection of these commands
is presented in Table 7.5.

7.4.5 The L2CAP Layer
In the next step of the overall connection establishment, an L2CAP connection is estab-
lished over the existing ACL link. The L2CAP protocol layer is located above the HCI
layer and allows the multiplexing of several logical connections to a single device via