Managing Multi-Standard Connectivity Requirements in IoT Designs

As the Internet of Things (IoT) evolves, standards defining the optimum wireless connectivity scheme for the IoT remain elusive. For IoT device developers, this translates to significant risk as choosing the wrong standard will greatly reduce the market opportunity. Yet, attempting to cater to all possible standards results in overly complex designs, increased costs and delayed projects. With the emergence of multi-standard wireless MCUs from Texas Instruments and NXP, developers have viable options for efficiently meeting emerging IoT connectivity requirements.

For years, wireless system design has largely remained the exclusive domain of RF experts. For engineers new to RF design, the requirements for optimizing transmission power and receiver sensitivity typically add significant complexity to an application. This often leads to tradeoffs in overall functionality while extending project schedules.

The emergence of wireless MCUs has brought about dramatic change in the development of connected applications, and may even have catalyzed the vision of the IoT itself. By integrating a processor and RF transceiver on a single chip, these system-on-chip (SoC) devices have democratized wireless systems design. Rather than juggling the myriad issues related to RF design, engineers can take full advantage of optimized wireless communications functionality built into these devices by the semiconductor vendor's own RF experts. Instead of losing time optimizing this critical, yet non-differentiated part of their design, developers can focus on applying wireless connectivity in their own applications.

The Texas Instruments CC2650 MCU takes integrated support for connectivity even further, combining an ARM Cortex^®-M3-based host with a complete on-chip communications subsystem (Figure 1). Here, the host processor runs the primary application and the high-level protocol stack from its boot ROM and integrated flash. When the application requires a communications event, the host processor only needs to send high-level requests to the communications subsystem. In turn, that subsystem's dedicated ARM Cortex-M0 core converts those high-level requests into specific communications tasks and uses integrated RF functionality to execute the detailed transactions required to fulfill them.

Figure 1: Next-generation wireless MCUs, such as the TI CC2650; integrate a sophisticated communications subsystem comprising a dedicated processor and RF functionality. (Image courtesy of Texas Instruments)

Wireless MCUs such as the TI CC2650 have emerged as a cost-effective, near drop-in solution for a broad array of application requirements. RF engineers can take advantage of RF and antenna design that offer simplicity without compromising reliability or performance (CC2650 Dev Kit is available to evaluate the device). Application software developers can similarly take advantage of integrated features for security, sensor control, digital I/O and analog signal conditioning. Just as important, application software runs on the industry-standard ARM Cortex-M3, MCU architecture familiar to many developers. Indeed, software developers can speed development thanks to an extensive ecosystem of vendor-provided and third party software libraries, including fully tested communications protocol stacks.

Diverse connectivity requirements

For IoT designers, however, the hybrid nature of IoT communications has complicated the otherwise simplified development of connected applications based on these wireless MCUs. In developing a typical industrial application, for example, engineers would implement connectivity designed to take advantage of low-power IP networks used in that environment. In contrast, for a consumer application, engineers would focus more on peer-to-peer communications protocols used in smartphones and mobile products. Because the IoT typically shares common connectivity requirements with both industrial and consumer applications, IoT communications complexity can rise dramatically compared to other connected applications.

For consumer applications, Bluetooth's ubiquity has made it the preferred connectivity option: Every modern smartphone supports Bluetooth and particularly its low-power version, called Bluetooth Smart or Bluetooth Low Energy (BLE). Operating in the 2.4 GHz ISM band, BLE offers a high data rate (1 Mbps) and features a very short connection time of only a few milliseconds. After a connection event, a BLE transceiver can go into a low-power quiescent state until the next connection. As a result, designers can count on very-low power consumption in typical BLE-based applications.

For industrial applications, 802.15.4-based networking is the preferred approach with standards such as ZigBee^® typically serving as the high-level protocol. 802.15.4 transceivers can use the 2.4 GHz ISM band and can support data rates up to 250 Kbps. (802.15.4 also allows use of lower frequency ISM bands in different national regions but the 2.4 GHz band remains the international standard.)

Their common use of the 2.4 GHz ISM band is the only practical similarity between BLE and 802.15.4. For the 2.4 GHz band, the 802.15.4 standard specifies a physical (PHY) layer using offset-quadrature phase-shift keying (O-QPSK), a modulation approach that uses four different values of the phase. In contrast, BLE uses Gaussian frequency-shift keying (GFSK), a pulse-shaping technique designed to reduce interference. BLE uses 40 channels on 2 MHz spacing; 802.15.4 uses 16 channels on 5 MHz spacing. Beyond these fundamental differences, the differences between the two standards extend through the stacks for BLE (Figure 2, left) and a commonly used 802.15.4-based protocol such as ZigBee (Figure 2, right).

Figure 2: Along with their different modulation techniques, the BLE stack (left) and 802.15.4-based ZigBee stack present marked differences across their respective software layers. (Image courtesy of CSR/Qualcomm)

At the same time, the ebbs and shifts in connectivity standards present a further dilemma for developers. On one hand, the next version of Bluetooth (V4.2) promises BLE with mesh-networking capabilities, the lack of which has limited its utility in IoT applications. That said, corresponding hardware is only just emerging and the lack of IP-based connectivity remains a shortcoming. On the other hand, leading chip manufacturers including ARM, NXP, and Silicon Laboratories have joined with leading product makers to back an IP-based networking standard, called Thread, based on 6LoWPAN, which uses 802.15.4 for its underlying layers.

Multi-standard connectivity

Ultimately, BLE and 802.15.4 each present compelling connectivity options and the arguments for deploying either (or both) will remain valid. Until that argument changes, product developers will continue to face pressure to move easily between both communications worlds.

In the past, however, companies looking to support both 802.15-4- and BLE-based connectivity have needed to create and maintain separate designs for each. Indeed, designers can find a variety of wireless MCUs designed specifically to support BLE communications as well as those for 802.15.4-based communications.

In practical terms, however, the cost and complexity of building applications that incorporate both a BLE wireless MCU and an 802.15-4 wireless MCU would be simply prohibitive in highly competitive and cost-conscious IoT markets. A more effective approach would rely on a single hardware design able to support either BLE or 802.15.4-based connectivity.

With a single base hardware design, manufacturers could delay choosing a wireless connectivity protocol until late in the design cycle or respond more quickly to new opportunities with different communications requirements. This kind of deferred connectivity decision is behind comprehensive communications IC families such as the TI SimpleLink family, where designers can switch to another code-compatible SimpleLink wireless device. This allows them to switch the underlying communications protocol without impacting the application.

The TI CC2650 further simplifies the task of supporting multiple communications standards. The device integrates support for both BLE and 802.15.4 radios, allowing rapid retargeting to another protocol without a change in antenna design. As a result, designs built with the CC2650 can go to production without locking in a selection and be configured when deployed in the field. If the protocol needs to be changed later, the CC2650 can be reprogrammed in the field to support the required protocol.

The CC2650's multi-standard radio offers significant advantages as a single platform that can be easily retargeted. On the software side, however, retargeting requires a software reload. TI warns developers that a software build for the CC2650 can support only one protocol at a time. Furthermore, the device itself cannot hold images for both images simultaneously. Although the CC2650 includes portions of the BLE and 802.15.4 stack in on-chip ROM, the CC2650 on-chip 128 KB flash is not large enough to hold BLE and 802.15.4 protocols simultaneously: A BLE stack requires 90-120 KB and a ZigBee stack typically requires 48 KB or so. Even with highly optimized stacks or those stripped of extra features would leave little or no room for additional code required by the application.

In practice, however, designers can simply add external flash large enough to store both BLE and 802.15.4 images for applications that need the ability to reconfigure easily to support either protocol. In fact, TI itself uses this approach with its CC2650-based SensorTag reference design (Figure 3) and further leverages the additional storage to support over the air download (OAD) of new firmware images.

During an OAD transaction, the device downloads the new firmware to the external flash. After the new image is verified, it is copied into the on-chip flash, and the device is reset to start executing the new image. Of course, separate BLE and 802.15.4 images could be stored statically in this external flash and loaded when the IoT device needs to change communications protocol.

Figure 3: The CC2650 supports a simple interface to an external flash such as the Winbond Electronics W25X20C 2 Mb flash for storing complete images required for multi-standard connectivity. (Image courtesy of Texas Instruments)

The ability to switch an IoT device's communications protocols adds significant flexibility to a design. Yet, the design must ultimately sit in one world or the other, 802.15.4 or BLE. For applications that must maintain connectivity with networks using different protocols, the NXP KW40Z W-Series Kinetis MCU presents a unique solution.

The KW40Z SoC integrates an ARM Cortex-M0+ core, 160 KB of flash and 20 KB of SRAM with a 2.4 GHz transceiver and dedicated hardware for handling BLE and 802.15.4 communications. These are supported by hardware security and a full complement of digital and analog peripherals, including a 16-bit ADC. With its larger flash block, the KW40Z integrates sufficient on-chip memory to run both a BLE stack and an IEEE 8021.5.4 MAC/PHY for applications that need to run on multiple networks concurrently. Furthermore, NXP is upgrading memory with the next member of its W-Series family: The KW41Z, which is still in preproduction as of this writing, features 256 to 512 KB of on-chip flash and 64–128 KB of on-chip SRAM.

Within the KW40Z's sophisticated digital radio subsystem, the TX Digital Module (Figure 4) modulates transmission data according to the required communications protocol and presents data for transmission to the digital radio's phase lock loop (PLL), which in turn handles frequency selection and eventual transmission. The TX Digital Module can modulate transmission data from its GFSK, FSK, or DFT tone modulators, or even from user-supplied modulation schemes.

Figure 4: Part of the KW40Z digital radio subsystem, the TX Digital Module supports modulation required for separate communications standards including BLE and 802.15. It uses a rapid time-slicing approach to maintain concurrent communications across different protocols. (Image courtesy of NXP)

As illustrated in Figure 4, the communications signal path would seem to support only a single protocol at a time. In reality, the KW40Z uses a rapid time-slicing approach that is fast enough to alternate between BLE and 802.15.4 communications, all the while sustaining their respective communications channel. For both the application and communications layers, the KW40Z appears to communicating on both BLE and 802.15.4 networks.

Conclusion

IoT applications can levy connectivity demands that straddle industrial and consumer communications requirements. Although designers had a broad range of separate options for supporting industrial protocols such as 802.15.4 or consumer protocols such as BLE, few viable alternatives were available for supporting multiple protocols in the same design. With the emergence of multi-standard wireless MCUs, IoT developers can offer more flexible connectivity options, to the extent that they can now even support concurrent 802.15.4- and BLE-based communications in a single design.