Best Practices for Deploying NB-IoT for Smart Meters
NB-IoT is a modern Low Power Wide Area Network (LPWAN) used by carriers to support enterprise customers.
Some of the biggest use-cases for NB-IoT are in the area of Advanced Metering Infrastructure (AMI), with smart water meters representing the first large-scale deployment of NB-IoT.
NB-IoT has now entered the mainstream for smart water metering and smart gas metering. For Smart electric metering, NB-IoT is also a very good choice but has remained on the “edge” of electric meter AMI until now.
Comparing Water & Gas Metering
Electric metering AMI is much more bandwidth-intensive than AMI for water meters or gas meters. Water meters and gas meters typically only measure the amount of water/gas used, whereas electric meters provide a whole range of detailed information such as voltage, current, impedance variance, and temperature.
Water meters come in the traditional mechanical style (which are cheaper, but only report consumption data), and ultrasonic, which report other data items such as water temperature, pressure, and clarity. Typically water/gas meters uplink their data once every 6 to 24 hours, with a total bandwidth of approximately 100 Bytes per meter per day. There’s typically very little downlink requirements for water/gas meters.
Some water/gas meters may have a shut-off valve that can be remotely controlled via the downlink, and firmware updates can be broadcast via the downlink. Other than that, there is very little downlink traffic in water/gas meters. Typically water meters use proprietary defined data structures to uplink their information. In some case the simple protocol standard Modbus is used. Gas meters are traditionally more focused to using Modbus protocol, but current trends are drifting towards using Distribution Line Message Specification (DLMS).
Types of Electric Meters
Electric meters have much more aggressive bandwidth requirements. Electric meters primarily come in single-phase residential meter and 3-phase Commercial & Industrial (C&I) meter types, and can be differentiated by form-factor. IEC type meters are used in most of the world, ANSI type meters are used in North America and parts of LATAM.
Electric meters for utility use are typically running the very “chatty” DLMS protocol known. DLMS was originally designed for wire-line communications and requires “connection-oriented” communication using TLS security and it runs over TCP. Each DLMS message is at the lowest level of meter hardware known as a “register”. So, a high-level instruction such as “Read Meter Usage Data” might be de-constructed into 10, 20, or even more, low-level DLMS messages, such as “read register22, read register 34, read register 27, and so on” each one with a send/acknowledgement TCP protocol overhead. Due to this low-level, connection-oriented style of communication, DLMS is not suited to scalable transmission over NB-IoT (or any other wireless) network.
Cutting Bandwidth & Sent Messages
The solution to this is to use a form of Edge Computing at the meter communication module. The on-board CPU for the meter communication module can handle direct low-level DLMS message communication with the electric meter, and then combine and compress this data into “upper layer” format messages for transmission over the NB-IoT Radio network.
This greatly reduces the overall bandwidth of information, and the number of messages sent over the NB-IoT network. Additionally, the “upper layer” messages are sent using CoApp over UDP with Huawei Datagram Transport Layer Security (DTLS+) encryption. DTLS+ is a way to reduce the number of overhead messages in setting up secure communications, and is a Best Practice for NB-IoT (and other cellular) networks.
Channel Coding (Reed-Solomon)
Channel Coding, such as Reed-Solomon coding (detailed description outside the scope of this article), can also be added to reduce the number of bit errors when sending the “upper layer” messages over the Radio network. In the very rare cases where upper layer messages are received with errors, a re-try can be issued from the back-office application layer.
Bringing it together—System Level view
By following this Edge Computing, two-tier messaging architecture, the electric utility requirement of DLMS messages can be supported, while still adapting to a more efficient message format for upper layer transmission over the NB-IoT Radio interface. (This methodology also applies to other RF communication types such as GPRS, 2G/3G/4G, LoRA, and RF-Mesh.)
As seen in the diagram above, the electric meter acts as a DLMS server, providing register-level DLMS responses when queried by a DLMS client (the Meter communications board). The Meter Communications board acts as a DLMS client, and converts DLMS messages into the appropriately formulated upper-layer message, then compresses, encrypts, and adds channel coding (Reed Solomon). The result is a meter that can efficiently send upper-level messages over LPWA NB-IOT network to back office data center systems for processing.
Back-office Systems Overview
Back-office systems typically include Head-End System (HES) (which act in a manner similar to IoT platforms). HES is able to harmonize data from different meter models and vendors, and support upper-layer communications to meters on different types of communications networks (e.g. NB-IoT and PLC). Meter Data Management Systems (MDMS) connect to the HES and provide management interfaces for IT department OAM, billing systems, CRM systems, and more.
Until now, NB-IoT has not taken a major position in the deployment of electric utility AMI. To a large degree this is due to misunderstandings in some of the key architectural issues described above, especially the need for edge computing to convert low-layer DLMS messaging to upper-layer messaging, and the need to use best-effort CoAPP / UDP rather than connection oriented TCP transport.
The future for NB-IoT in the electric utility is quite bright, since 2G and 3G networks are being phased out, and a replacement will be needed for the cellular-IoT portion of the electric utility grid (around 5% of connections). As AMI becomes more ubiquitously rolled out, increasing coverage from 85%–>90%–>95%–>99.9% becomes exponentially more difficult with traditional first-generation AMI communications networks such as PLC or RF-Mesh. NB-IoT networks offer a low-cost and efficient way to provide gap-filling, and hard-to-reach meter connectivity.