Radio scheduling in dynamic multiprotocol IoT applications

Even within the same market segment, IoT devices are not necessarily interoperable. They may be part of different and isolated ecosystems and use different protocols to communicate. There are some efforts being made to consolidate existing protocols, but this is proving difficult for a number of reasons, mainly around the current install base and the different performance characteristics of the various protocols.

The existing installed base

Billions of IoT devices in the field use specific protocols predominantly because they were state-of-the-art at the time the devices entered the market. Another reason a manufacturer may have chosen a specific protocol might be that it was mandated by a branded device ecosystem they wanted to sell into. Either way, this installed base is not going to disappear in the short term and is unlikely to be upgraded to make use of a new protocol. Although feasible in some cases, updating a live consumer device to a new protocol tends to bring risk, including a large potential support burden.

Performance characteristics

Not all protocols used by IoT devices are truly competing. Many have a unique raison d’être, based on physical performance characteristics, such as battery life, data throughput, propagation range or latency. To address this, efforts are being made to standardise at least the higher layers, using common application languages, such as Dotdot introduced by the Zigbee Alliance. However, the requirement to switch between different physical protocols, such as IEEE 802.15.4, Bluetooth or WiFi, remains.

For an IoT device manufacturer, having to address multiple protocols can pose design challenges. In a worst-case scenario, targeting a single vertical means developing and marketing different devices or versions of devices, even within the same geographic region. This sounds like a recipe for trouble, which is why many manufacturers bet on which protocol will dominate the vertical and accept they may not gain market share in some fragments of it.

Multiprotocol: The different approaches

However, there are innovative techniques to support multiple protocols in a given device.

First is programmable multiprotocols, where the protocol is defined in the factory during production (see examples opposite). This enables a single hardware product to be marketed across multiple fragments of a vertical, but still requires different part numbers for devices with firmware variations.

It switched multi-protocol removes the need to differentiate by part number, because you can switch between protocols at run-time. However, switching typically involves bootloading a new application image. There are a number of use cases, including devices that, when factory-new, boot up as Bluetooth-only and can be commissioned via Bluetooth (using a smartphone) to join a Zigbee network. At that point, the devices switch to become Zigbee-only.

Dynamic multi-protocol enables a device to communicate using two protocols ‘at the same time’. This concept is based on a single radio, meaning a radio scheduler (or arbiter) is needed to optimise for best performance. In a dynamic multi-protocol environment, it’s expected that while servicing one protocol, there may be packet loss on the other. We explore dynamic multi-protocol further here.

A concurrent multiprotocol is a special case for protocols using the same physical layer, such as Zigbee and Thread. In this case, if it can be ensured that both networks use the same radio channel, both protocol stacks can access the radio in a truly concurrent way by sharing the respective message queues.

Finally, you can also use multiple physical radios to support multiple protocols in a truly simultaneous manner. However, measures must be taken to avoid collisions if both protocols use the same radio channel.

Dynamic multiprotocol architecture 

A common radio abstraction layer forms the basis of a dynamic multiprotocol application.

The individual protocol stacks involved in a dynamic multiprotocol application can be identical to the ones used in a single-protocol application. However, to manage execution of the different protocol stacks, an embedded operating system (OS) is a natural fit. The radio abstraction layer also hosts the radio scheduler as an entity that’s independent of the protocol stacks being used.

Above: Table 1. An outline of different multiprotocol definitions

The radio scheduler

The radio scheduler enables radio operations to be scheduled and prioritised. Different radio operations in each protocol may be more or less important or time-sensitive, depending on the situation. The scheduler can take these parameters into account when making decisions about how to resolve conflicts (Figure 1).

Every event in the scheduler is broken up into elements called radio operations, each associated with a radio configuration describing the physical part of the protocol and a priority. An operation is interrupted if the scheduler receives a higher-priority operation that overlaps it in time. Lower priority radio operations that cannot be run based on their schedule parameters will fail, and it’s up to the respective protocol stack to retry them. Once the scheduler actively runs a radio operation from a protocol stack, it can continue to send additional radio operations until it voluntarily yields, or until the scheduler receives a higher priority radio operation and preempts it. Each radio operation has four key parameters: start time, priority, slip time and transaction time (Figure 2).

Above: Figure 1. In this example, the Zigbee radio completes one transmission, followed by the Bluetooth radio’s receive. However, the second Zigbee transmission is interrupted by the Bluetooth radio as it has a higher priority. The second Zigbee transmission is retried once the higher priority operation is completed

Start time: This indicates at what point the particular radio operation will run. This could be ‘now’ or in the future.

Priority: Each radio operation has a priority, telling the scheduler which to execute if there’s a timing overlap between multiple operations. Priority 0 is the highest and 255 the lowest. The scheduler allows the task with the highest priority to access the physical radio hardware. With most tasks, control is returned to the scheduler only upon completion, but tasks such as background receive will be interrupted if a task with a higher priority becomes active. Each stack has a default set of priorities based on detailed analysis of how best to cooperate to maximise the duty cycle and avoid dropped connections in a generic use case. Specific use cases may have different needs, so priorities can be adjusted, even at runtime, to dynamically react to changes, such as prioritising reception of a critical firmware upgrade.

Slip time: Every radio operation must have a ‘slip time’ or maximum start time, meaning the furthest time into the future that the operation can be started if it cannot begin at the requested start time. This allows the scheduler to work around higher-priority events occurring at the same time, or higher-priority events that extend beyond their expected duration. The protocol generally dictates what the slip time can be, but the radio scheduler can handle this on a per-operation basis, allowing a stack to slip some events but not others. In general, IEEE 802.15.4 has a longer slip time, and Bluetooth Low Energy (LE) has a minimal slip time.

Transaction time: This is the approximate amount of time it takes to complete the transaction. The transaction times of transmit events are usually well-defined, while those of receive events are often unknown. This is used to help the radio scheduler determine whether an event can be run.

A scheduled radio operation may be interrupted if a higher priority operation conflicts with it. This can occur if a scheduled radio operation takes longer than expected, and the corresponding protocol stack doesn’t yield before the higher priority radio operation must start. It can also happen if a higher-priority radio operation has just been scheduled to occur in the future and conflicts with a lower priority operation already scheduled.

Above: Figure 2. This example shows that both transmit and receive operations are subject to priority. The second Zigbee RX operation is interrupted by the BLE radio, which has higher priority. The transmitting node retries and is successful once the BLE radio RX action is complete

Certain long-lived radio operations can have a disproportionate impact on the correct operation of the product. The application may need to coordinate these operations between the protocols. If the application doesn’t, then the radio scheduler priorities take precedence. For example, an IEEE 802.15.4 energy scan may require that the radio stays on to gather sufficient energy readings. If the application doesn’t properly coordinate the operations, the scan could be interrupted prematurely, due to a higher-priority Bluetooth operation.

The protocol stack defines these parameters appropriately, based on the operation being executed. For example, Bluetooth connection events are often scheduled in the future and have no allowed slip, whereas Zigbee transmit events can often be delayed a short time. From the perspective of the radio scheduler, scheduled transmit and scheduled receive are identical. They are both simply operations that require the use of the radio and thus cannot be executed simultaneously.

Let’s look briefly at an example of a dynamic multiprotocol application involving Bluetooth LE and Zigbee, the latter of which can be interchanged with Thread, which is also IEEE 802.15.4-based.

Radio scheduler examples

The scheduler starts out by having a low-priority Zigbee background receive operation. This represents an always-on router that may need to receive IEEE 802.15.4 packets at unknown times. A Bluetooth LE connection is also active and requires the stack to be ready to receive every 30ms. The Bluetooth LE stack may schedule this well in advance, due to the connection’s predictable nature.

In priority order, the four tasks are: Bluetooth LE scheduled transmit, Bluetooth LE scheduled receive, Zigbee scheduled transmit and Zigbee background receive.

Bluetooth LE radio events change their priorities dynamically - connections increase in priority the nearer they come to a supervision timeout. Compared to connections, advertisements have a lower priority. On the receive side, scanning for advertisements for the purpose of establishing a connection has a higher priority compared to general-purpose scanning. Silicon Labs look in more depth at priority settings in its user guide on dynamic multiprotocol.

Any of these priorities may be overridden or altered by the application, which can decide the circumstances under which this should happen.

Above: Table 2. Wireless Performance Comparison

Performance  

Using these priorities, we set up a test for a device running Bluetooth LE and Zigbee in a dynamic multiprotocol setup. The device was sending a BLE advertisement at 100ms intervals. It maintained up to four Bluetooth LE connections as a slave with two Android and two iOS smartphones. The test saw the device receive and acknowledge 1,000 Zigbee messages, either as fast as possible, or limited to five messages per second.

Table 2 shows the wireless performance outcomes. Please note that although they’re considered representative, results may vary depending on the underlying hardware and software versions of the protocol stacks.

Although Zigbee throughput is affected by the presence of Bluetooth LE advertisements and a single connection, the effect on latency and packet error rate is minimal. Only when increasing the Bluetooth LE connection count to four was there a minimal packet loss on the Zigbee side. What may be unacceptable for some applications, however, is the increased max turnaround time of 248ms for a Zigbee message. Cutting back the Zigbee traffic to a more realistic five messages per second, the packet error rate drops back to zero.

Recipe for success

A state-of-the-art radio scheduler, combined with the right priorities for the different radio operations of the involved protocols, is critical to the success of a dynamic multiprotocol application.

Application development that involves detailed testing for expected use cases delivers great benefits by enabling devices to fit into multiple ecosystems and serve a wider range of use cases, without the need for additional radio hardware or ecosystem-specific part numbers.