nRF5 SDK for Thread and Zigbee v3.1.0
Multiprotocol support with BLE/Bluetooth

Table of Contents

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.

Switched multiprotocol (Thread only)

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.

Note
This solution is not supported by the nRF5 SDK for Zigbee.

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.

multiprotocol_switched.svg
Switched multiprotocol (example of Thread and BLE)

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.

multiprotocol_switched_impl.png
Switched multiprotocol implementation

Switched multiprotocol examples are provided in this release of nRF5 SDK for Thread.

Switched multiprotocol – timings

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.

ThreadBLETimemeasurements1.svg
BLE and Thread switching timings in switched multiprotocol method

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.

Dynamic multiprotocol

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.

multiprotocol_dynamic.svg
Dynamic multiprotocol (example of Thread and BLE)

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.

dynamic_multiprotocol_apps.svg
Thread/BLE dynamic multiprotocol application operation

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.

multiprotocol_dynamic_impl.png
Dynamic multiprotocol implementation

The current solution allows to implement a set of BLE/Thread features, including the following use cases:

Dynamic multiprotocol performance

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%
Time spent on Thread during different concurrent BLE operations

¹ Advertising 7 bytes of data (only one UUID advertised – no Scan Request and Scan Response).

The duty cycle depends on several factors, for example:

Note
In our solution, the Bluetooth LE packet error rate is 0 (without external disturbance).
If the Bluetooth LE application consumes too much time for its operations (for example, by constantly transmitting packets within the connection interval), the Thread protocol might fail to receive or transmit its frames.
Especially, the application should not enable extended connection events (BLE_COMMON_OPT_CONN_EVT_EXT), because then the Bluetooth LE traffic might block Thread from accessing the radio peripheral.

Multiprotocol considerations

Given the nature of the dynamic multiprotocol solution, take into account the following considerations when developing your Thread or Zigbee application:

Multiprotocol configuration

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:

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 examples

This SDK provides examples that demonstrate how BLE coexists with both protocols. See the following pages:


Documentation feedback | Developer Zone | Subscribe | Updated