Channel Map Update

The host might have information about the local channel usage and wish to communicate this information to the controller. For example, it might be co-located with a Wi-Fi radio that is connected to an access point on a given channel and therefore communicating that the low energy channels in the same part of the band would reduce the possibility of the two radios from directly interfering with one another.

There is no way to directly instruct the controller to send a Link Layer channel map request to the peer (for more information about this, go to Chapter 7, Section 7.10.2).

However, the host can send the LE Set Host Channel Classification command to the

controller, as illustrated in Figure 8–21. This includes a bit field that denotes each Link Layer data channel as either bad or unknown. It is obviously not possible to denote a data channel as good from the point of view of the host because the controller might be measuring the packet error rates by channel already and noticed that some channels denoted as unknown by the host are actually bad.

Figure 8–21. Updating the channel map

The LE Set Host Channel Classification command causes a Command Complete event to be immediately sent to the host. The controller can use the Link Layer control procedures to change the channel map at any time it wants. It is possible for the host to monitor the channel map on a given connection by using the LE Read Channel Map command. This command returns whether each Link Layer data channel is used or unused at this time.

8.7.3. Feature Exchange

It is possible for the host to discover the features that are available on a connection. For example, even if the local controller supports encryption, encryption can only be used if the peer controller also supports it.

Figure 8–22 shows how the master’s host can ask for the remote used features by sending the LE Read Remote Used Features command. This causes a Command Status event to be returned, and the Link Layer feature request (LL_FEATURE_REQ) and response

(LL_FEATURE_RSP) to be exchanged (for more information about this, go to Chapter 7, Section 7.10.6). The controller then sends the feature response Link Layer message

information to the host in the LE Read Remote Used Features Complete event.

Figure 8–22. Exposing connection features 8.7.4. Version Exchange

When debugging devices, especially those that you do not directly control, it is sometimes useful to find the Link layer version information. This information can then be used to help contact the company that manufactured this device so that you can fix the problem. This information can be requested by either the master or slave host, allowing both devices to debug the link if necessary.

To exchange the version information, the host sends the LE Read Remote Version Information command to the controller, as shown in Figure 8–23. The controller responds with a Command Status event and starts the Link Layer version exchange (for more

information about this, go to Chapter 7, Section 7.10.5).

Figure 8–23. Obtaining version information

Once the version information has been exchanged, the controller sends the LE Read Remote Version Information Complete event to the host with the peer device’s version

information.

Note that if the LE Read Remote Version Information command is sent a second time, the same sequence of events is returned, but no Link Layer procedure will be performed because the version information is static information and is cached in the controller. This is also true if the remote device has already exchanged version information before the local host sent the command to the controller. Because the controller already has the version information from the remote device, it immediately sends the completion event after the status event.

8.7.5. Starting Encryption

It is possible for the host to enable the encryption of data packets while in a connection, as long as both sides have a shared secret. This shared secret is set up by the Security Manager, either during the initial paring process or through key distribution during bonding.

Two sequences of commands and events must be considered: one from the master’s point of view and one from the slave’s point of view.

The master’s host can ask for the Link Layer to start encryption by sending the LE Start Encryption command that includes the key used to encrypt the connection (see Figure 8–24).

The controller returns a Command Status event while encryption is started. The Link Layer then starts encryption (for more information about this, go to Chapter 7, Section 7.10.3).

Once encryption has started, the controller sends the Encryption Change event to the

master’s host to notify it as to whether encryption is now on or if there was a problem with encryption.

Figure 8–24. HCI master starting encryption

From the point of view of the slave’s host, the sequence of events and commands is slightly different. As depicted in Figure 8–25, the first event that warns the slave’s host that encryption is being enabled is the LE Long Term Key Request event. This event needs to be

responded to, by the host, by sending the LE Long Term Key Request Reply command that includes the key to be used for encrypting the connection. Because this is a command, a Command Complete event is used to complete it. After the connection is encrypted, the Encryption Change event is sent to the slave’s host to notify it of the new encryption state.

Figure 8–25. HCI slave starting encryption 8.7.6. Restarting Encryption

Sometimes, it is necessary for the host to restart encryption, either by using a new encryption key or just to refresh the initialization vector that is generated as part of the starting of

encryption.

As is illustrated in Figure 8–26, from the point of view of the master’s host, the sequence of commands and events are identical to the starting of encryption. The Link Layer has to send more packets, first to pause encryption and then to restart it.

Figure 8–26. HCI master restarting encryption

From the point of view of the slave’s host, the events and commands are also identical, as shown in Figure 8–27.

Figure 8–27. HCI Slave Restarting Encryption

It should be noted that it is not possible to turn off encryption in low energy and then send application or host data. Therefore, it is not necessary to send an Encryption Key Refresh Complete as soon as encryption is paused.

This is because of a problem discovered in early versions of Bluetooth classic. Hosts that desired maximum security would try to refresh keys regularly to make them more difficult to crack. However, refreshing keys required turning off encryption, but while encryption was off, data could still be sent. The host couldn’t get around this by simply pausing its flow of data to the controller because there might be data in the controller’s buffers awaiting

transmission. This meant that in early versions of Bluetooth classic, hosts trying to increase security ended up actually decreasing security and causing the controller to send unencrypted data. This was fixed in a later version of Bluetooth classic.

Once a host has requested encryption on a connection, there is usually no reason to disable it. So when encryption is paused, data transmission is also paused, closing the security hole that existed in early Bluetooth specifications.