Reducing the implementation complexity of low-cost, low-power wide-area communications for embedded IoT devices.
As the concept of the internet-of-things (IoT) was taking shape, the communications industry started addressing the anticipated need to connect these “billions of IoT devices” (Figure 1). Since these devices are meant to address low-cost, low-power (battery operated) applications, cellular technology trends to increase bandwidth – driven largely by mobile phones – needed to be revisited. New approaches for wide-area communications needed to be developed to facilitate massive deployment of these IoT devices.
Figure 1 – Global NB-IoT Market Growth
Low-power, wide-area network protocols such as LoRa and SigFox have been deployed over the last few years with varying levels of successful adoption. More recently, the 3GPP standards organization has defined a cellular standard for wide-area IoT networking called Narrowband IoT (NB-IoT). This standard has been optimized for machine-to-machine types of communication. The initial version, referred to as Cat-NB1, was defined as part of the 3GPP Release 13 standard. A more enhanced version, entitled Cat-NB2 was published as part of 3GPP Release 14 and added new features such as positioning and multicast.
Bundling the NB-IoT protocol as part of the standard mobile 3GPP rollouts has served to accelerate adoption as many mobile network operators (MNOs) make modifications to their existing infrastructure, supporting features of the new releases. This accelerated rollout will also rapidly grow the silicon chipsets needed to support the NB-IoT adoption rates. Growth estimates vary, but a 40+% annual CAGR is not an unreasonable estimate over the next ten years.
As seen in Figure 2, the global deployment is primarily being led by MNOs in China, the US and Europe. China and Europe are largely deploying NB-IoT alone (Cat-NB1, Cat-NB2), while US operators are rolling out both NB-IoT and LTE-M, a higher bandwidth protocol that supports voice as well as data.
Figure 2 – Global Cellular IoT Communications Deployment
Traditional cellular implementations typically consume more power and target different silicon process technology nodes than many of the SoCs and MCUs that leverage the communications devices. This has largely kept the communications ICs separate from the applications devices – especially when looking at the RF transceiver implementations.
Traditional LTE modem hardware and software architectures incorporate multiple DSPs, several hardware accelerators, RISC cores, multiple OS’s, stacks, etc., to manage the compute-intensive protocols and high data rate requirements of wideband LTE modems. Attempting to simply scale down this type of implementation to support NB-IoT will not yield a power- and area-efficient solution. The simplified feature set and significantly lower bandwidth requirements lend themselves to a new approach.
A flexible NB-IoT modem can be created based on a small, low-power CPU/DSP processor, a few targeted hardware accelerators, dedicated power management hardware and tight integration between the baseband and RF transceiver (Figure 3).
The processor must offer excellent code density and an efficient implementation of the software stack, so that memory sizes can be small. The use of off-chip DRAM can then be avoided, which helps keep system costs down. Small code size is also important for achieving low power consumption, specifically by reducing accesses to instruction memory.
Figure 3 – Integrated IoT Communications Solution (including iSIM)
Leveraging similar concepts used in other DesignWare ARC processor-based subsystems, Synopsys has developed an IP subsystem focused on providing efficient processing for low-bandwidth communications. The ARC IoT Communications IP Subsystem (Figure 4) was architected to specifically provide a drop-in hardware and software baseband solution for embedded designers to easily add 3GPP Release 14 (Cat-NB1/NB2) support to their SoCs.
Figure 4 – Synopsys DesignWare IoT Communications IP Subsystem
The fully configurable IP subsystem is built around the Synopsys ARC EM11D processor, perfectly adapted for running both control code and DSP code required to simultaneously run IoT applications and the NB-IoT protocol stack. Many of the architectural features of the EM11D core such as zero-overhead loops, 16+16 complex arithmetic and butterfly support, wide accumulators, and support for fixed point arithmetic (with saturation and rounding) enable efficient execution of the NB-IoT modem functions. The EM11D processor’s XY memory with advanced address generation (AGU) provides three logical memories that the processor can access simultaneously, enabling the core to execute one (1) multiply-accumulate (MAC) per cycle – a critical metric for communication stacks.
One of the most computationally intensive parts of the NB-IoT modem is the decoding of downlink data, which leverages the Viterbi algorithm and is often a bottleneck in modem design. A software implementation of the Viterbi algorithm on a generic CPU/DSP processor can provide only limited performance improvement. The IoT Communications IP Subsystem provides hardware acceleration using ARC Processor EXtension (APEX) instructions to significantly reduce the MHz requirements of Viterbi decoding along with a simple API, enabling drop-in replacement for software implementations.
The subsystem also includes an integrated digital radio front-end (DFE) which implements the I/Q data interface between the protocol stack and the RF transceiver. The RF transceiver itself, available through multiple 3rd party partners, is relatively simple, allowing on-chip integration with the baseband processing. One such RF transceiver diagram from Synopsys partner, Palma Ceia SemiDesign, is shown in Figure 5. PHY protocol layer software, and a simplified interface reduces complexity and facilitates the RF/subsystem integration effort.
Figure 5 – Palma Ceia’s NB-IoT RF Transceiver
The integrated power management and clock control unit (PMU) provides critical support for devices to meet stringent battery lifetime requirements set forth by the 3GPP. Many of these battery-operated devices are intended for “set-and-forget” applications where human interaction is limited. The 3GPP standard defines several use cases based on frequency of communication (every 2 hours / once daily) and data bandwidth (50 bytes / 200 bytes). The expectation with a 5Wh battery is ten (10) years of battery lifetime for all use case combinations. In order to help SoC design teams meet these goals, the subsystem provides several programmable power domains within the ARC EM11D processor as well as within the rest of the IoT Communications Subsystem logic. Aside from the always-on logic (AON), which is needed for data retention, clocking, power management, etc., the remaining domains can be controlled as needed to meet power requirements. The subsystem power domains are shown in Figure 6.
Figure 6 – IoT Communications Subsystem Power Domains
Use cases for power management can be seen in Table 1 highlighting recommend states for the ARC EM11D processor, RF transceiver, and subsystem logic to minimize power consumption in active, sleep (memory retention, RF idle), and standby modes (RF powered OFF, only AON logic active).
Table 1 – IoT Communications Subsystem Power Modes & Power Domains
Support for low-cost, low-power wide-area communications are increasingly important for embedded IoT devices addressing a broad range of emerging smart applications. The NB-IoT standard – defined by 3GPP – reduces implementation complexity by supporting a more limited data rate and feature set compared with legacy LTE protocols. A simplified hardware / software architecture can then be leveraged to build and deploy low-cost, battery-operated devices that consume very little power.
The integrated hardware and software features of the Synopsys DesignWare ARC IoT Communications IP Subsystem provide a complete IoT solution for all “always-on” functions such sensor fusion, voice triggering, face and gesture recognition, as well as the critical narrowband communications link to connect IoT processing to the cloud.
 |
 |
 |
 |
 |
 |
 |
 |
 |
Leave a Reply