The nRF System-on-Chip supports multiple radio protocols. Applications running on the nRF SoC can use several radio protocols, but only one at a time. You can implement concurrency as either switched multiprotocol or dynamic multiprotocol.
The switched multiprotocol solution is the simplest one. This method requires disabling the currently used protocol before enabling the other one. In this way, you achieve non-concurrent radio access.
During the initialization procedure, the switched multiprotocol application switches on one selected protocol (for example, BLE). Before enabling the other protocol (for example, Thread), the application switches off the previously enabled protocol.
The drawback of this solution is breaking all BLE connections when enabling Thread, and breaking all Thread connections when enabling BLE. In addition, the switching period is significantly higher than in the dynamic multiprotocol method, since it involves uninitialization of the current protocol and initialization of the other one from scratch.
When a node enables the Thread protocol, it attaches to the Thread mesh network. The attachment procedure can take between 0.2 and 5 seconds (the time difference cannot be fully determined, as it results from protocol specification, and depends on the network topology and randomly chosen delays). When a node attaches to the network, it can immediately start transmitting or receiving data to other nodes or from them. In the other direction, for example when a node enables BLE protocol and operates as a BLE Peripheral, it must start advertising and wait for the BLE connection.
In the switched multiprotocol method, switching between different protocols is usually performed by an application in appropriate user-defined moments. For example, a node may advertise on BLE and wait for the connection. After the connection is established and the node receives some application data, for example over GATT, it may uninitialize the BLE stack and enable the Thread stack. After the attachment to a mesh network is successful, the node can push previously obtained data into the cloud by using native IPv6 protocols and switch back to BLE.
Switched multiprotocol examples are provided in this release of nRF5 SDK for Thread.
The overall switching timings between BLE and Thread may vary in different applications. The figure below presents the switching timings measured on the BLE UART and Thread MTD CoAP Client Example.
The procedure of switching from BLE to Thread and back to BLE consists of the steps listed in the following table. Timing values were measured for the nRF5 SDK for Thread and Zigbee v0.9.0 release. These values can be different in the later releases.
# | Step name | Description | Timing measurements |
---|---|---|---|
1 | BLE transactions | Device operates on BLE protocol. | Application-specific. |
2 | BLE stack disable | Device disables SoftDevice. | 233-260 [us] softdevice_handler_sd_disable() |
3 | Thread stack enable | Device enables OpenThread stack. | ~33 [ms] PlatformInit() otInstanceInitSingle() otIp6SetEnabled() otThreadSetEnabled() |
4 | Thread attaching | Device attaches to the Thread network. | 0.2 – 5 [s] Time is highly non-deterministic and may depend on the current network role, air traffic, random jitters, or other non-deterministic factors defined in the Thread protocol. |
5 | Thread transactions | Device operates on Thread protocol. | Application-specific. |
6 | Thread stack disable | Device disables OpenThread stack. | 490 – 530 [us] otInstanceFinalize() PlatformDeinit() |
7 | BLE stack enable | Device enables SoftDevice. | ~251 [ms] SOFTDEVICE_HANDLER_INIT() sd_ble_cfg_set() softdevice_enable() softdevice_ble_evt_handler_set() softdevice_sys_evt_handler_set() |
8 | BLE initialization | For example, GATT services initialization. | Application-specific. |
9 | BLE transactions | Device operates on the BLE protocol. | Application-specific. |
The dynamic multiprotocol solution allows for running several radio protocols simultaneously without the time-expensive uninitialization and initialization in-between the switching. Switching between protocols requires only a reinitialization of the radio peripheral, since protocols may operate on different frequencies, modulations etc. Therefore, the time of switching is much shorter than in the Switched multiprotocol (Thread only) method.
In the dynamic multiprotocol solution, radio hardware is time-sliced between all protocols. Each radio protocol (BLE and Thread or Zigbee) requests a timeslot prior to any radio operation. This solution allows for keeping established connections in a few protocols at the same time. Transmitting and receiving data does not break connections from any of the radio protocols used, and therefore both connections on Thread and BLE or Zigbee and BLE may be maintained without disconnecting the other one. This method requires concurrent (time-multiplex) radio access. Due to the nature of this solution, when using the BLE Central role, the scanning interval and scanning period must be set as small as possible, to ensure that Thread or Zigbee data traffic is not blocked.
The figure below shows how Thread and BLE protocols operate in the dynamic multiprotocol mode.
The time-multiplexed radio access is achieved by utilizing a radio arbiter. The SoftDevice (Nordic’s BLE stack) includes Radio Event Manager (REM) that manages radio arbitration and exposes Timeslot API for any other radio driver. The 802.15.4 radio driver for the nRF platform, used in OpenThread in case of Thread, includes a radio arbiter client that uses Timeslot API to manage its radio transactions and requests timeslots prior to any radio activity.
In the dynamic multiprotocol method, switching between different protocols is done automatically in the background of the currently running application and therefore is transparent for a user. A user writes the Bluetooth part of a multiprotocol application as it was a Bluetooth-only application, and a Thread part of the multiprotocol application as it was Thread-only application.
In this solution, BLE always has priority over Thread. Because of the BLE protocol nature (TDMA), without any external interference, Bluetooth packet error rate should be 0%. Note that in case of the Thread protocol, some Thread devices, for example Thread Routers, should constantly receive, except when transmitting packets (when the channel is idle, frames can be sent to them asynchronously at any time). Because of this, some Thread radio packets may be lost due to BLE activity. However, if Thread transmission occurs while the node operates on BLE, Thread will treat that just like any other dropped packet. Dropped packets are common in wireless networks and Thread provides resilience to that. To mitigate the number of packets lost on Thread, prolong BLE timing parameters such as advertising interval or connection interval.
The current solution allows to implement a set of BLE/Thread features, including the following use cases:
The dynamic multiprotocol solution allows a device to participate in a Thread or a Zigbee network while, at the same time, functioning as a Bluetooth LE peripheral device. Bluetooth low energy radio usage is complementary to both Thread and Zigbee. It uses short periods of radio activity in regular intervals, while Thread or Zigbee uses all remaining time for its operations.
From both the Thread and the Zigbee protocol perspective, the time required for Bluetooth LE operations and switching between protocols decreases the overall time spent on performing 802.15.4 operations (for example, receiving or transmitting frames). The following table shows approximate percentages of time spent on Thread (duty cycle) during different concurrent BLE operations and the percentage value for the probability of receiving the longest 127 B IEEE 802.15.4 frame and responding with ACK.
Concurrent BLE operation | Thread timeslot | Probability |
---|---|---|
Connection Interval – 300 ms | 99,5% | 97,8% |
Connection Interval – 200 ms | 99,2% | 96% |
Connection Interval – 100 ms | 98,5% | 93% |
Connection Interval – 50 ms | 97% | 87% |
Connection Interval – 15 ms | 90% | 53% |
Advertising Interval¹ – 1000 ms | 99,5% | 99% |
Advertising Interval¹ – 200 ms | 97,7% | 95% |
Advertising Interval¹ – 100 ms | 95,5% | 90% |
Advertising Interval¹ – 50 ms | 91,6% | 83% |
¹ Advertising 7 bytes of data (only one UUID advertised – no Scan Request and Scan Response).
The duty cycle depends on several factors, for example:
BLE_COMMON_OPT_CONN_EVT_EXT
), because then the Bluetooth LE traffic might block Thread from accessing the radio peripheral.Given the nature of the dynamic multiprotocol solution, take into account the following considerations when developing your Thread or Zigbee application:
((smallest_timeslot_time + op_flash_write_time) * n_of_flash_ops)
.smallest_timeslot_time
is the smallest timeslot that the radio requests. In the default configuration, it equals 6.4 ms.op_flash_write_time
is the time required to perform a flash operation.n_of_frames
is the number of flash operations to be performed in a sequence.MAC_TRANSACTION_OVERFLOW (== 241)
status code.ZB_BDB_SIGNAL_DEVICE_FIRST_START
or ZB_BDB_SIGNAL_DEVICE_REBOOT
signal is received.Thread and Zigbee stacks keep all the radio timeslot handling process in the nRF IEEE 802.15.4 Radio Driver internally. nRF IEEE 802.15.4 Radio Driver automatically requests new radio timeslots when needed. One of the parameters that must be specified is the timeslot timeout. It is defined as the longest acceptable delay until the start of the requested timeslot.
Due to a limitation of the SoftDevice, depending on the configured timeout, two different behaviors may be observed:
Timeslot timeout is smaller than BLE activity requested by the SoftDevice
The default timeslot timeout configured by the nRF IEEE 802.15.4 Radio Driver has a value of 4.5 ms. For default GAP Event Length of 3.75 ms, the BLE activity time requested by the SoftDevice for connection is larger than 4.5 ms. If this configuration is used, the radio driver acquires radio time as soon as BLE activity is finished. For example, when only empty TX/RX frames are exchanged during a BLE connection event (which takes less than 1 ms – less than requested time), the SoftDevice releases the radio as soon as the BLE timeslot has ended. This allows for achieving the fastest switching between BLE and 802.15.4. The drawback of this configuration is that during the BLE timeslot, the application does not have the CPU – which is blocked by the SoftDevice.
Note that in case of long BLE GAP Event Length or Scanning Window, BLE activity is typically longer than the default timeslot timeout.
Timeslot timeout is larger than BLE activity requested by the SoftDevice
In case the timeslot timeout is set to the maximum allowed value, all BLE timeslots requested by the SoftDevice have smaller activity time. If this configuration is used, the SoftDevice does not block the CPU which can be utilized by the application during BLE activity. The drawback of this configuration is the increase of switching times between BLE and 802.15.4.
This SDK delivers a function to choose the proper configuration, depending on the application use case. Refer to the multiprotocol_802154_mode_set function. This function allows the application to configure one of the following mode:
MULTIPROTOCOL_802154_MODE_FAST_SWITCHING_TIMES
- This mode allows for the fastest switching times between 802.15.4 and BLE.MULTIPROTOCOL_802154_MODE_LOW_CPU_UTILIZATION
- This mode allows for the lower CPU utilization during the BLE timeslot.This SDK provides examples that demonstrate how BLE coexists with both protocols. See the following pages: