Logical Interface

Above the HCI physical transports is the logical interface. It is a logical interface because in the single-chip device, this interface doesn’t need to be implemented as a message-passing interface between components. For a system in which the controller and host are on separate chips connected by a physical interface, the HCI logical interface is represented as physical packets transferred over this physical interface.

There are three concepts to understand about the logical interface:

• Channels

• Packet formats

• Flow control 8.3.1. HCI Channels

Whenever a controller has a connection to another device, the controller’s lower HCI interface creates an HCI channel that is identified by using a connection handle. This

connection handle is used to identify all data that is sent from the host to the controller that is to be sent to a specific peer device as well as all data that is received from that peer device by the controller before it is sent to the host.

The connection handle is given to the host whenever the attempt to create a connection completes. The connection handle is valid until the connection is terminated, either locally, by the Link Layer termination procedure, or due to a link supervision timeout.

8.3.2. Command Packets

To command the controller to do something useful, command packets are sent by the host to the controller. These command packets typically are used to either configure the state of the controller or ask it to do something.

As illustrated in Figure 8–1, the HCI command packet contains an opcode that

determines the command that is being sent, a parameter length field, and the parameters for the command. Each command has its own unique set of parameters.

Figure 8–1. The HCI command packet format

There are three basic types of commands in Bluetooth low energy that perform the following functions:

• Configure the controller state

• Request a specific action

• Control a connection

8.3.2.1. Configuring the Controller State

The controller can be considered to be one big state machine that has a number of parameters which can be configured. For example, advertising can be considered to be a state that has the following state that can be configured by using the LE Set Advertising Parameters

command, LE Set Advertising Data command, LE Set Scan Response Data command, and the LE Set Advertise Enable command.

Typically, within Bluetooth low energy, the state used within a state machine cannot be changed while that state is being used. Therefore, it is impossible to change the advertising parameters while advertising is enabled. It is therefore necessary to disable advertising, change the advertising parameters, and then enable advertising again.

8.3.2.2. Requesting a Specific Action

Some commands request a specific action to occur without altering the state of the device or the state of a connection. For example, the LE Encrypt command takes a key and some plain-text data and requests the controller to generate some encrypted data based on these.

8.3.2.3. Controlling a Connection

When a connection has been created between two devices, commands can be sent to manage this connection. These commands always include the connection handle. For example, the LE Read Channel Map command is used to read the current adaptive frequency-hopping channel map for a given connection.

8.3.3. Event Packets

Event packets are used to send information from the controller to the host, typically in response to something that the host has previously commanded.

Figure 8–2 shows that the HCI event packet contains an event code that determines which event is being sent, a parameter length field, and the parameters for the event. Each event has its own unique set of parameters.

Figure 8–2. The HCI event packet format Three basic event types are used in Bluetooth low energy:

• Generic command complete events

• Generic command status events

• Command-specific completion events

8.3.3.1. Generic Command Complete Events

Whenever a command is sent to the controller that can be completed immediately, a generic command complete event is returned. This is the Command Complete event. This event is generic in that the event parameters include the command opcode that this event is

completing along with the return parameters that are specified by that command. The first parameter of all command return parameters is a status code that specifies whether the command was successful or had an error and couldn’t complete.

For example, the LE Rand command that is used to command the controller to return a random number has two return parameters: the status code and the requested random number.

The generic command complete event is used whenever the controller can complete a command without doing any over-the-air transactions. For example, the LE Encrypt command does not request any Link Layer packets to be transmitted, so the generic

command complete event is used, whereas the LE Create Connection command requires that at a minimum a Link Layer CONNECT_REQ packet is transmitted before the connection is established; therefore, the generic command complete event cannot be used.

8.3.3.2. Generic Command Status Events

For those commands that perform over-the-air transactions, such as creating the connection mentioned in the previous section, a generic command status event is normally followed some time later by a command-specific completion event. The generic command status event is the Command Status event.

8.3.3.3. Command-Specific Completion Events

Some commands require time to complete. These commands always have command-specific completion events. For all of these commands, there is just one command completion event.

For example, the LE Create Connection command will first have a Command Status event sent and then an LE Connection Complete event will be sent once the connection is created or the connection fails. It is not until this command-specific completion event is received that the command is considered to be finished.

8.3.4. Data Packets

Data packets are used to send application data from the host to the controller so that it can be transmitted to a peer device, and from the controller to the host that has been received from a peer device.

As illustrated in Figure 8–3, data packets are always labelled with a connection handle.

This is a 12-bit value that is provided to the host in the LE Connection Complete event. Until the event is received by the host, it cannot send any data to a peer device. However, once this event is received, the host can start to send data to the peer device, and it will start to receive data from the peer device.

Figure 8–3. The HCI data packet format

There are two flags in the HCI data packet: the Packet Boundary Flag and the Broadcast Flag. Because these packets are reused from Bluetooth classic, some of these flags don’t have any meaning in low energy. The Packet Boundary Flag determines if this packet is a start or continuation of a higher-layer (Logical Link Control and Adaptation Protocol)

message. This can be considered to be very similar to the LLID bits in a Data Channel PDU in the Link Layer (for more information, see Chapter 7, The Link Layer, Section 7.8.2).

The interesting thing is that from the host to the controller, this can contain the values 00 (start) and 01 (continuation), whereas from the controller to the host, this can contain the values 10 (start) and 01 (continuation). This is because in Bluetooth classic the value 10 from the host to the controller means that the data packet can be flushed if necessary; with

Bluetooth low energy, the concept of flushing doesn’t exist. Instead, it simply drops the link if the data cannot get through, so this value cannot be used. It is for this reason that the value used for the start indication from the host to the controller is 00 (instead of the LLID value 10 at the Link Layer) because this is used for unflushable data in Bluetooth classic.

8.3.5. Command Flow Control

The HCI interface has two forms of flow control: command flow control and data flow control. Command flow control is used to enable the controller to manage how many HCI commands it can process at the same time. The easiest way to consider how this works is to think of the controller as having enough memory to buffer a small number of commands. It communicates the number of these buffers to the host so that the host knows how many commands it can send to the controller at the same time.

There is no event flow control. It is assumed that the number of events that can be sent is limited by the number of commands that can be processed. It is also assumed that the host has more resources than the controller; therefore, it can buffer and process these events in sequence.

To enable command flow control, all Command Complete and Command Status events include a parameter called Num HCI Command Packets. This parameter indicates how many command packets can be buffered in the controller. Each time a command is sent, it uses one of these slots. Each time a Command Complete or Command Status event is sent to the host, it includes the number of slots that are currently free. It is also possible to send a Command Complete event for the opcode “No Operation” with a new Num HCI Command Packets at any time. This is most useful at the initial boot-up of the controller, when it might want to grant the controller more command buffer slots to speed up the initial configuration of the controller by the host.

8.3.6. Data Flow Control

Data flow control is performed in a similar manner. There are two flows of data: host to controller and controller to host. Host to controller data flow control must be used, but the flow control from the controller to the host can be ignored. Most hosts should be able to cope with the quantity of data being sent from the controller to the host, so flow control is not necessary.

For host to controller data flow control, the controller is considered to have a number of buffers, each a fixed size. Each time a data packet is sent from the host to the controller, it uses one of these buffers. Each time a data packet is successfully transmitted by the

controller to the peer device, the buffer that held that data packet is released back to the host to fill up with another data packet.

A slight complication with this flow control system is that a dual-mode controller can have two different buffers, one for basic rate data and one for low energy data. This means that there are two HCI commands to discover the buffers on a controller: Read Buffer Size command and LE Read Buffer Size command. Using these two commands, the host can therefore determine which buffers are available. For a low energy–only device, only the LE Read Buffer Size command will return non-zero length buffers.

After the host has discovered the number of buffers available, each time it sends a data packet to the controller, it uses one of these buffers. The buffers are released when a Number Of Completed Packets event is sent from the controller to the host. This has a list of

connection handles and the number of packets that was sent. This means that not only does the host know how many buffers have been released but also which data was sent to the peer devices.