Wireless protocols that are widely used in the IoT have a lot of common attributes. Multiprotocol SoCs able to run them all can simplify many kinds of wireless designs.

TOM PANNELL, Senior Marketing Director, IoT Products| SILICON LABS

We have many innate expectations for controlling the myriad devices and systems in our lives. When I enter a room in my home or office, I expect to be able to control the lights with a switch. When I leave home, I expect to set my security alarm and lock the door. Many of these systems are already installed and part of a well-established infrastructure.

The promise of the Internet of Things (IoT) is changing our expectations. Now, I expect to be able to monitor and control the temperature of my home remotely through my smartphone. I expect my office building to inherently conserve energy by turning off lights when no one is present. I expect the building to “know” when I am there and make sure my surroundings are comfortable and safe.

To enable our increasingly connected world, countless IoT devices and systems have been deployed that we barely notice. Wireless security systems, access cards, occupancy sensors, remote temperature sensors, and many other connected devices are omnipresent in our homes, offices, factories, and urban infrastructure.

The complex network of wired and wireless sensors that underpins the IoT has been developed and deployed over decades. To replace these sensor networks would be an expensive proposition. The promise of the IoT is raising the bar. New wireless-sensor-node deployments are now much easier with the advent of multiprotocol technology. This technology includes hardware and software that enables a single system-on-chip (SoC) device to support multiple wireless protocols such as Bluetooth low energy, zigbee and Thread. And it spans multiple frequencies scaling from sub-gigahertz bands to 2.4 GHz.

However, because IoT infrastructure is built on legacy systems, we must also consider the challenge of adding new 802.15.4 wireless technologies to existing infrastructure deployed in the early days of the IoT. The support of legacy systems is not the only challenge. In addition, there is a complexity that arises out of the competing protocol standards often used to solve similar connectivity challenges.

A TYPICAL IoT NODE

The first thing to understand about the vast web of sensor networks around us is that they are based on microcontroller (MCU) technology coupled with some sort of sensing element. Together they convert the analog surroundings to digital packets. Once quantized, data often must go to the cloud for further processing. The transport method of choice in many cases is wireless. The wireless sensor data packets are generally small, and the wireless nodes themselves must make efficient use of size, cost and power.

To accomplish this connectivity in the past, many suppliers used sub-gigahertz radio frequencies as well as lightweight wireless protocols optimized for battery life. They were forced to create their own protocols out of necessity because existing options were too power hungry or didn’t extend to the desired range. Now, however, there are many robust, power-efficient, standards-based options available to developers including Zigbee, Thread and Bluetooth low energy (BLE).

IoT device designers often face a dilemma in designing a single product able to work with all these wireless standards while minimizing BOM cost and complexity. Few device makers have the resources or time to create special designs supporting every possible wireless standard used in the IoT.

Multiprotocol, multiband SoCs free developers from this design dilemma by supporting sub-gigahertz proprietary frequencies as well as standards-based protocols in the 2.4-GHz band – all within one highly integrated device. Ideally, a multiprotocol, multiband SoC features a wireless transceiver with two radio paths: one for sub-gigahertz and one for 2.4 GHz transmissions. This integrated radio architecture gives IoT developers a lot of leeway for fielding diverse applications.

Consider the signal chain of a typical multiband transceiver integrated into a wireless SoC. Some elements of the radio transceiver are shared and some are separate. For example, the RF portion must have separate elements to handle the different frequency requirements. But the modem — which consists of a modulator, demodulator and some of the encryption hardware — can be shared across both radio front-ends.

This radio architecture creates a highly optimized, consistent and economical approach to multiprotocol, multiband SoC design. Different protocol stacks can share the modem to implement various communications standards. The modem is also multiplexed between RF portions to receive and transmit packets. This shared architecture is also well suited to software development because it provides a common interface to the radio functions. So it allows developers to create a radio configuration layer that can be shared between different protocol stacks.

The software necessary to implement a multiprotocol, multiband system is complex. Wireless protocol stacks must be efficient and must work across a broad set of hardware products. They must also work in multithreaded environments with real-time operating systems (RTOS). In a multiprotocol application, the stacks must work seamlessly together or independently without adding bloat or inefficiency. When two stacks run on the same SoC with shared hardware, the implementation must take place in a way that maintains the integrity of the network. This is an intricate task.

Multiprotocol/multiband systems are proving to be useful in a wide variety of uses. Programmable multiprotocol connectivity is the easiest use to explain and implement. Engineering managers recognize a lot of code reuse and efficiency can be gained when a single device can be deployed across many end products. Engineers can specify a single SoC part number that can run zigbee, Thread, BLE, or proprietary protocols. They can then decide at the time of production whether the product will run Bluetooth or operate as a sub-gigahertz product. This approach enables manufacturers to minimize financial exposure while maintaining maximum flexibility in production.

Switched multiprotocol has a strong value proposition for the end consumer. This technology, for example, enables installers on job sites to provision and calibrate products via smartphone apps. This feature is particularly useful when deploying a
Thread or zigbee node.

Provisioning across a wide range of networks can be difficult. Switched multiprotocol technology simplifies this task by enabling an IoT product to start its life using BLE and then be provisioned and switched to some other protocol for mesh networking. The advantage of switched multiprotocol over dynamic multiprotocol is that fewer device resources are required because there is no need to physically store and run multiple protocols among multiple wireless devices.

With dynamic multiprotocol, it is possible to support two protocols (or more) with one SoC by time-sharing physical resources. Dynamic multiprotocol generally uses more device resources, such as flash memory, and has a more complex software architecture. It also requires careful radio design to dynamically share radio resources among dissimilar protocols.

Although dynamic multiprotocol schemes use more hardware resources, this tends to be a small, incremental tradeoff considering the value this approach brings. In many cases, dynamic multiprotocol techniques reduce design complexity and overall system cost by at least 50%. These savings come from using only one SoC device instead of two or more ICs with a distributed rules engine and dissimilar stack architectures. A single multiprotocol SoC coupled with a robust RTOS, well-designed wireless stacks, and the local application can easily implement an IoT design requiring multiple modes of connectivity.

Concurrent multiprotocol is particularly useful in a gateway design deploying Thread and zigbee networks. Here, many software and hardware resources can be reused as-is because of the similarities among protocols and radio configurations. For example, Thread and zigbee share the same PHY and MAC layers, minimizing the need to reconfigure the transceiver. In addition, Thread and zigbee share some common elements higher in the communication stack, which makes resource sharing more efficient and straightforward to manage. Consequently, devices can use a smaller memory footprint, which can help reduce cost in the end product.

PUTTING IT ALL TOGETHER

Only a handful of SoC suppliers currently deliver multiprotocol products based on highly integrated SoCs and optimized software. Even fewer offer the development tools necessary to simplify the complexities of multiprotocol wireless design. It can be challenging to field a system in which the stacks work seamlessly with each other.
What can make things difficult is that sometimes wireless design teams are spread around the world, have different design goals, or may be part of different business units. When multiple stacks come from different companies or community sources, it can be tough to fashion a reliable system out of them that is power- and memory-constrained.

Protocols must use hardware efficiently in a constrained system to avoid wasting CPU cycles and memory resources. It is particularly important that the switch between protocol stacks be handled efficiently. Otherwise, conflicts arise and/or energy is wasted. Wasted CPU cycles can have a devastating effect on battery life. Inefficiency in the stacks can also result in a need for more memory, which drives up system cost. To ensure successful applications, developers must carefully consider each component such as the device hardware (SoC or module), radio schedulers, stacks, and RTOS.

The need for multiprotocol, multiband solutions will continue to proliferate because no single wireless protocol is perfect for every IoT application. In a more connected world, we will continue to see connected devices and embedded software growing ever more complex to serve the diverse needs of the IoT.
RESOURCES
Silicon Labs, www.Silabs.com