nRF5 SDK for Thread and Zigbee v4.0.0
 All Data Structures Functions Variables Typedefs Enumerations Enumerator Groups Pages
Multiprotocol support with BLE/Bluetooth

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 Switched 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:

  • Full Thread Device + BLE Beacon (combo Router)
  • Full Thread Device + BLE Connection (combo Router)
  • Minimal End Device + BLE Beacon (commonly, a line-powered end device)
  • Minimal End Device + BLE Connection (commonly, a line-powered end device)
  • Sleepy End Device + BLE Beacon (commonly, a battery-powered end device)
  • Sleepy End Device + BLE Connection (commonly, a battery-powered end device)

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:

  • Advertising and connection intervals
  • Advertising data length
  • Usage of scan request and scan response
  • Event length (duration of the communication during one connection interval)
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:

  • Any kind of application or Thread/Zigbee stack logic can be interrupted by the BLE activity. This is the primary difference between a Thread/Zigbee-only application and a multiprotocol one. As a result, it is acceptable that the node can sometimes miss a frame and not respond with a MAC-level acknowledgment.
  • BLE scanning requires a lot of time to process BLE traffic and thus blocks 802.15.4 traffic. When the scanning is used, it is recommended to use the Sleepy End Device role for Thread or Zigbee applications.
  • Be aware that flash operations require more time to complete. A flash operation may be performed only in a free timeslot, so it has to wait until the current timeslot finishes (it may be a 802.15.4 timeslot or a BLE one). Moreover, the Thread or Zigbee stacks cannot operate while the flash operation is being performed. Avoid an application design that involves a continuous series of small flash operations. The time the stack will be blocked by such a series of operations can be estimated using the following formula:
    • ((smallest_timeslot_time + op_flash_write_time) * n_of_flash_ops).
      • In this formula:
        • 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.
  • The Zigbee stack has a limited TX queue. This queue can get full in case of heavy application traffic and BLE activity. The application logic must take this into account by providing a callback for all crucial transmissions and handle the MAC_TRANSACTION_OVERFLOW (== 241) status code.
  • The most time-critical part of the Zigbee stack operation is the BDB commissioning process. Postpone time-consuming operations until the ZB_BDB_SIGNAL_DEVICE_FIRST_START or ZB_BDB_SIGNAL_DEVICE_REBOOT signal is received.

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:

  • 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.

Multiprotocol examples

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