nRF52 AFH

RE: nRF52 AFH

bjorn-spockeli — Mon, 03 Jun 2019 06:53:22 GMT

Hi Belenie,

[quote user="Belenie"]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[/quote]

You are correct, there is a typo. It should be: As far as I know most BLE stacks running on embedded devices do not perform channel monitoring [...]

Best regards

Bjørn

RE: nRF52 AFH

Belenie — Fri, 31 May 2019 20:50:03 GMT

Hi Bjorn,

Thanks for the response, I just want clarification on the last paragraph of your reply:

Did you mean to say Do perform channel monitoring and we do not?

Pasted below for quick review.

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,

Belenie

RE: nRF52 AFH

bjorn-spockeli — Fri, 31 May 2019 13:35:34 GMT

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

RE: nRF52 AFH

Belenie — Wed, 29 May 2019 15:55:10 GMT

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*****

RE: nRF52 AFH

bjorn-spockeli — Wed, 29 May 2019 11:37:11 GMT

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