Channel Selection Algorithm #2

Summary

Channel Selection Algorithm #2 (CSA #2) is a more complex and harder to track algorithm for obtaining the channel index for the next connection event. It is more effective at avoiding interference and multi-path fading effects than Channel Selection Algorithm #1, especially in high-throughput use cases.

See Volume 6, Part B, Section 4.5.8.2 of the Bluetooth Core Specifications Version 5.2 for a detailed description of the algorithm.

Here are samples of what the algorithm would like over 100 events for 37 and 9 used channels:

../_images/CSA2.png

Figure 96. Channel Selection Algorithm #2 Example

Default Configuration

The stack includes support for CSA #2 by default and it is also enabled by default. That is, as a Central, the device will attempt to establish a connection using CSA #2 and, as a Peripheral, the device will accept CSA #2 connections requests. At a lower level, this means that, as a Central, the device will send connection requests with the ChSel field set to 1 and, as a Peripheral, the device will advertise with the ChSel field set to 1.

Whether or not CSA #2 is used for the connection depends on what is supported on the peer device. The Bluetooth Core Specifications Version 5.2 states that

“If the initiator sent a CONNECT_IND PDU in response to an ADV_IND or AD_DIRECT_IND PDU and either or both device’s PDU had the ChSel field set to 0, then Channel Selection Algorithm #1 shall be used on the connection. Otherwise, Channel Selection Algorithm #2 shall be used.”

See Volume 6, Part B, Section 4.5 of the Bluetooth Core Specifications Version 5.2 for more details.

Disabling CSA #2

CSA #2 can be disabled by clearing the respective supported features bit.

First, use HCI_LE_ReadLocalSupportedFeaturesCmd() to get the currently set local supported LE features.

Then, after receiving the corresponding HCI_LE_READ_LOCAL_SUPPORTED_FEATURES event (see Host Controller Interface (HCI) for more details on how to receive events), clear the LL_FEATURE_CHAN_ALGO_2 bit (bit 6 of byte 1) and update the modified features with HCI_EXT_SetLocalSupportedFeaturesCmd() :

 1 case HCI_LE_READ_LOCAL_SUPPORTED_FEATURES:
 2 {
 3     uint8_t featSet[8];
 4
 5     // get current feature set from received event (bits 1-9 of
 6     // the returned data
 7     memcpy( featSet, &pMsg->pReturnParam[1], 8 );
 8
 9     // clear the CSA#2 feature bit
10     CLR_FEATURE_FLAG( featSet[1], LL_FEATURE_CHAN_ALGO_2 );
11
12     // Update controller with modified features
13     HCI_EXT_SetLocalSupportedFeaturesCmd( featSet );
14 }

Note

This must be done before advertising (for the Peripheral) or before initiating (for the Central).