Three Design Aspects you shouldn't miss while building an NB-IoT Protocol Stack

By Nigel Dixon, T2M

Abstract

Low Power Wide Area Network (LPWAN) is critical in connecting long range IoT devices across all industries. NB-IoT from 3GPP has become a leading LPWAN connectivity protocol.

It is very important that the design aspects of the NB-IoT device protocol stack ensure low module cost and low energy consumption. This is required to match the industry expected module costs. This paper outlines some of the NB-IoT Protocol stack specification flexibilities and generic design aspects that are to be considered to meet the above requirements, especially with reference to LTE.

Introduction

NB-IoT from 3GPP, has become a leading LPWAN connectivity protocol compared to existing proprietary technologies, even though it is relatively new (the first specifications were ready only by June 2016). China and many European countries have started the commercial deployments already and the same is expected to grow many fold in 2018-2019. NB-IoT has a clear roadmap as part of 5G standardization and 5G networks are expected support to huge number NB-IoT devices.

NB-IoT Specification Flexibility

NB-IoT is simpler compared to LTE and the technology provides many options to make a simpler design. So if you have a LTE based modem design and are trying to optimize the same for NB-IoT, expect to make many design changes.

Waveform: NB-IoT has a much simpler waveform unlike LTE and will consume lesser power. A 200 kHz NB-IoT frontend and digitizer offers reduced complexity of analog-to-digital (A/D) and digital-to-analog (D/A) conversion, buffering, and channel estimation.

Fig1: Time Multiplexing between NB-IoT downlink Physical Channels and Signals

Source: https://arxiv.org/ftp/arxiv/papers/1606/1606.04171.pdf

Half Duplex: Since NB-IoT is half duplex, Unlike LTE, these NB-IoT physical channels and signals are primarily multiplexed in time. This means the same RF could be used for Tx and Rx. From a design perspective, this enables the baseband to have common signal chain for Rx and Tx at the baseband. The same buffers could be shared between Tx & Rx. There’s an upper limit on the duration of the continuous transmission imposed by the protocol, which allows to have a fixed pre-allocated TX buffer. It is suggested to let it have the same length as the RX buffer.

Downlink Data Reception Timings: In case of NB-IoT, Broadcast channel spacing is 10ms, Scheduling Delay from DCI decoding to Data decoding is ≥ 4 ms and from Data decoding to ACK/NACK transmission: ≥ 12 ms.
Uplink Data Reception Timings: Scheduling Delay from DCI decoding (UL Grant) to Data transmission: ≥ 8 ms and from Data transmission to DCI with ACK/NACK: ≥ 3 ms.

Fig2: Timing relationship

Source: https://arxiv.org/ftp/arxiv/papers/1606/1606.04171.pdf

All the physical layer procedures and transmission and reception of physical channels occur in sequential manner. Scheduling Timing intervals mentioned above, allow spreading out processing load over a number of consecutive subframes. This enables the MIB decoding to be spread over 10ms and the same is the case for SIB1 and SIB2. In the uplink for example, there are 11 ms to decode 4xDCI and modulate at least the first subframe of NPUSCH or 15 ms to decode 4xDCI and modulate all the scheduled NPUSCH subframes.

NPDCCH (Narrowband Physical Downlink Control Channel) used for DCI (Downlink Control Indicator) messages (carrying UL Grant, DL scheduling and acknowledge), responding to RACH requests, etc. may carry different messages, may appear in different OFDM symbols, may have different number of repetitions. During the attach procedure those parameters are not known to device, so it must try several hypotheses to find out the correct allocation. This makes NPDCCH decoding one of the most computation-intensive procedures (it does a lot of Viterbi decoding). So the platform (MCU/DSP) should have specific instruction sets or accelerators for the same. The other computational intensive process could be the FFTs (Fast Fourier Transforms). The platform is expected to have the have specific instruction sets or accelerators for FFTs too.

NB-IoT Design Aspects

• Low Foot Print: A low Binary Footprint can reduce the cost of NB-IoT Modules. Normally the LTE Architectures use a highly modular big framework and hence result in a big foot print. NB-IoT needs only a simple architecture without multiple threads. Multiple protocol layers could be implemented in a single module. This results in a Low foot print for Code and Data. It also reduces the processing power required.
• Low Processing Power: There is no need of synchronization between the Layers. Normally in LTE, L2 & L3 are synchronized to L1 based on TTI received from L1. In case of NB-IoT since the data rate is very less and there is good scheduling gap between the received and transmitted messages, L2 can work without TTI. The layers need to have a only synchronized clock and FN/SFN, to ensure that messages are sent and received on the right frames. Say in LTE, L2 should schedule all DL messages FN – 4 frames with L1, and L1 should schedule it FN-2 frames with RF. In case of NB IoT, however, since the singling and data rates are slow, L2 can send the message upfront and instruct L1 that it should be sent on FN. This makes the implementation simple and reduces the processing power required.
• Low Power consumption: Since the NB-IoT device will mostly be in sleep mode, the device can save power if it has very less leakage power in the sleep mode. The transition between different power modes (PSM, eDRX, Idle and Connected modes) and efficient ways of controlling the RF for the same (Stand by to RX, RX to TX transition, TX to RX transition, RX to standby, TX to standby& Power down) also will decide the power efficiency.

Solution Approaches

There are two solutions generally adopted for NB-IoT Protocol stack.

• Single SoC for RF, L1, L2 & L3
• DSP/HW implementation of RF & L1 and L2, L3 & Application on an MCU

MCUs with scalable architecture could be used to integrate RF and all the protocol layers on to the same MCU. This approach also provides the flexibility to enhance the protocol as it evolves.

The two-chip solution RF & L1 are implemented in DSP or Hardware while L2/L3 and the application will be implemented in a lighter MCU. This makes the solution more cost effective. The upgradeability for the new releases of this evolving technology could be a concern in case of a HW implementation, hence a DSP approach could be a better option till the technology reaches a mature level of deployment.

Our solution

We offer a low footprint Software solution keeping the above aspects in mind, where the L3/L2/L1 can be easily ported to any MCU/DSP with scalable architecture and can be integrated with Partner RF solutions.

In a two-chip solution, The L3/L2 could be on an MCU and the L1 can be integrated with RF on a DSP or HW. (The L1 protocol stack is also available in RTL so that it could be put into HW form). Even with the HW form, we still give L1 control and configuration from SW, so that there is flexibility.

Conclusion

With NB-IoT rapidly becoming a leading LPWAN connectivity protocol, its protocol stack design should make use of the flexibility provided by the specification as well as the optimizations provided by the platforms to ensure a Low Cost, Low Power NB-IoT Module. LTE based architectures may need to be adapted to provide the expected level of cost and power benefits to NB-IoT modules .