nRF52 AFH

[Belenie]

Hello,

Would like to understand more on Adaptive Frequency Hopping(AFH) behavior. We understand that AFH comes into play when lower layers detect noisy channels, blacklists them and accordingly updates the channel list in use.

What is the criteria of deciding whether a channel is good enough for use or not?

How many failures on a particular channel trigger the system to blacklist the channel?

Thank you,

Belenie

[bjorn-spockeli]

Hi Belenie, 

is this related to Bluetooth Low Energy or 802.15.4 protocols(i.e. Zigbee or Thread)?

Bluetooth Low Energy uses Frequency hopping, but it is not adaptive, i.e. the channels are not monitored and hence not whitelisted/blacklisted.  

Thread and Zigbee uses the CSMA-CA (Carrier Sense Multiple Access with Collision Avoidance) protocol. The nRF52840 or the nRF52811 can perform Energy detection (ED) and 

Clear channel assessment (CCA) to check if a channel is in use and if its free, respectively. This is configurable through the 802.15.4 Radio driver which is used by both the Zigbee and Thread stacks on our devices, see  CCA configuration management and CSMA-CA procedure
 

Best regards

Bjørn

[Belenie]

Hi Bjorn,

 The information provided is completely counter to everything I’ve been told about BLE, according to every source I can find it uses Adaptive Frequency Hopping, this is why the Client sends out a Channel Map and why the Channel Map gets updated/changed.

 

https://www.eecs.umich.edu/courses/eecs589/papers/06215496.pdf

 

Excerpt from the BT5 Core Spec:

 

7.2 ADAPTIVE FREQUENCY HOPPING

Adaptive Frequency Hopping (AFH) allows Bluetooth devices to improve their

immunity to interference from and avoid causing interference to other devices

in the 2.4 GHz ISM band. The basic principle is that Bluetooth channels are

classified into two categories, used and unused, where used channels are part

of the hopping sequence and unused channels are replaced in the hopping

sequence by used channels in a pseudo-random way. This classification

mechanism allows for the Bluetooth device to use either all or fewer than the

79 channels required in the Core Specification v1.1. The minimum number of

channels allowed by the Bluetooth specification is 20.

The Core Specification defines the aspects of AFH necessary to ensure

interoperability, including the hopping kernel, Baseband behavior, Link

Manager Protocol (LMP) commands, and Host Controller Interface (HCI)

commands and events required to change and configure hopping sequences.

The Bluetooth Specification also defines a mechanism that allows for a slave to

report channel classification information to the master.

Adaptive Frequency Hopping utilizes metrics obtained through many sources.

These metrics are analyzed and then the resulting Channel_Map is used by

the adaptive frequency hopping kernel. The metrics may come from over-theair

measurements, data supplied by the Host (via the

HCI_set_AFH_Channel_Classification command), or reports by the slave or

from other hardware coexistence interfaces.

While AFH is a critical element in coexistence, it is not enough in some

circumstances.

 

Here is a section from the spec that specifically talks about BLE in relation to Adaptive Frequency Hopping:

 

4.2.2.6 Connected Mode

After a successful connection procedure, the devices are physically connected

to each other within a piconet. This means that there is a piconet physical

channel to which they are both connected, there is a physical link between the

devices, and there are default LE-C and LE-U logical links. When in the

connected mode it is possible to change the properties of the physical and

logical links while remaining connected to the piconet physical channel, such

as changing the adaptive frequency hopping sequence or changing the length

of data packets. It is also possible for the device to carry out advertising,

scanning or discovery procedures without needing to disconnect from the

original piconet physical channel.

Additional logical links are created using the Link Manager that exchanges LL

Protocol messages with the remote Bluetooth device to negotiate the creation

and settings for these links. One of these links (LE-C) transports the LL control

protocol and is invisible to the layers above the Link Manager. The other link

(LE-U) transports the L2CAP signaling protocol and any multiplexed L2CAP

best-effort channels. It is common to refer to a default LE ACL logical transport,

which can be resolved by context, but typically refers to the default LE-U logical

link. Also note that these two logical links share a logical transport.

During the time that a slave device is actively connected to a piconet there is

always a default LE ACL logical transport between the slave and the master

device. The method of deleting the default LE ACL logical transport is to detach

the device from the piconet physical channel, at which time the entire hierarchy

of L2CAP channels, logical links, and logical transports between the devices is

deleted.

*****Please note new email address*****

 

[bjorn-spockeli]

You are correct that the channel map used in  BLE link can be updated by the Link master (i.e  BLE Central). From my understanding this is mostly used by devices that use both BLE and WiFi to remove the BLE channels that overlap with the WiFi channel used from the Bluetooth channel map.

However, to be truly adaptive the device would have to sweep all the used channels periodically and monitor the received power level and/or keep track of the number of lost packets/ re-transmissions per channel. The BLE protocol stacks from Nordic do not monitor the link performance and hence do not blacklist or whitelist channels. 

As far as I know most BLE stacks running on embedded devices do perform channel monitoring his as it adds on complexity as well as increase the current consumption. The performance of using the default channel map is usually good enough for most cases. 

Best regards

Bjørn