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
The switched multiprotocol solution is the simplest one. This method requires disabling the currently used protocol before enabling the other one, and thus achieving non-concurrent radio access.
During the initialization procedure, a switched multiprotocol application switches on one selected protocol (e.g. BLE). Prior to enabling the other protocol (e.g. 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 (these numbers result from protocol specification, depend on the network topology, and randomly chosen delays, and thus cannot be fully determined). When a node attaches to the network, it can immediately start transmitting/receiving data to/from other nodes. In the other direction, when a node enables BLE protocol and operates e.g. as a BLE Peripheral, it has to start advertising and wait for a 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 a connection. After the connection is established and the node receives some application data e.g. over GATT, it may uninitialize the BLE stack and enable the Thread stack. After the attachment to a mesh network is successful, the node may push previously obtained data into the cloud using native IPv6 protocols and switch back to BLE.
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.
The procedure of switching from BLE to Thread and back to BLE consists of the following steps:
| # | Phase 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 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 method.
In the dynamic multiprotocol solution, radio hardware is time-sliced between all protocols. Each radio protocol (BLE or Thread) 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 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 should be set as small as possible, to ensure that Thread data traffic is not blocked.
The figure below shows how Thread and BLE protocols operate in the dynamic multiprotocol mode.
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, 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 e.g. Thread Routers, should constantly receive, except when transmitting packets (when the channel is idle, frames can be sent to them asynchronously at any time), thus 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:
- 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 network while, at the same time, functioning as a Bluetooth LE peripheral device. Bluetooth low energy radio usage is complementary to Thread. It uses short periods of radio activity in regular intervals, while Thread uses all remaining time for its operations.
From the Thread 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.
| Concurrent BLE operation | Thread timeslot | Probability of receiving the longest 127 B IEEE 802.15.4 frame and responding with ACK |
|---|---|---|
| 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:
- 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 examples
nRF5 SDK for Thread provides examples that demonstrate how BLE coexists with Thread. See Multiprotocol examples page.