MetalOne of the projects we’re currently working on is a battery powered sensor that needs to send small amounts of data, infrequently, and have a battery-life measured in years. We spent quite a bit of time researching LoRa for this, but have recently settled on Narrowband IoT (NB-Iot) instead.
Narrowband IoT (NB-IoT) is a Low Power Wide Area Network (LPWAN) radio technology standard developed by 3GPP to enable a wide range of cellular devices and services. The specification was frozen in 3GPP Release 13 (LTE Advanced Pro), in June 2016. Other 3GPP IoT technologies include eMTC (enhanced Machine-Type Communication) and EC-GSM-IoT.
NB-IoT focuses specifically on indoor coverage, low cost, long battery life, and high connection density. NB-IoT uses a subset of the LTE standard, but limits the bandwidth to a single narrow-band of 200kHz. It uses OFDM modulation for downlink communication and SC-FDMA for uplink communications.
We managed to source a Quectel LTE BC68 NB-IoT Module and started to work on data integration, soon realizing that these Neul (which is a company Huawei acquired in 2014) based NB-Iot modems require you to use special AT commands to communicate with the outside world (as opposed to “normal” modems which would require the host to call in using PPP).
Okay, let’s scan the Quectel BC95-G&BC68 AT Commands Manual. There’s a command for creating UDP sockets, great. Another one for TCP sockets, too. Awesome! And then there’s something mysteriously referred to as the “Huawei IoT Platform”. Wait, what?!?
In TELCO speech it’s called a CDP (which stands for Connected Device Platform). It’s a fancy way to describe a gateway that accepts messages from a mobile device and routes them to your application server. There are a few flavours around, such as:
But what if we want to use our own server? There are a few reasons one would do this, including cost and efficiency, or the fact that the Huawei partner signup website was broken for two weeks. (Actually turns out it just can’t accept Ü as a character in the company name. But I digress.) Nokia CDP on the other hand is only available in the U.S.
Scanning the manual further, there are hints as to what the protocol might be. To set the ip address of the CDP platform, there’s a specific AT command for it.
6.1. AT+NCDP Configure and Query CDP Server Settings
The command is used to set and query the server IP address and port for the CDP server. It is used when there is a HiSilicon CDP or Huawei’s IoT platform acting as gateway to network server applications. The values assigned are persistent across reboots.
And the default port for it is 5683. That’s the port for CoAP:
Constrained Application Protocol (CoAP) is a specialized Internet Application Protocol for constrained devices, as defined in RFC 7252. It enables those constrained devices called “nodes” to communicate with the wider Internet using similar protocols. CoAP is designed for use between devices on the same constrained network (e.g., low-power, lossy networks), between devices and general nodes on the Internet, and between devices on different constrained networks both joined by an internet. CoAP is also being used via other mechanisms, such as SMS on mobile communication networks.
Furthermore, another command confirms CoAP and adds OMA LwM2M:
6.5. AT+QLWULDATA Send Data
The command is used to send data to Huawei’s IoT platform with LWM2M protocol. It will give ancode and description as an intermediate message if the message cannot be sent. Before the module registered to the IoT platform, executing the command will trigger register operation and discard the data. Please refer to Chapter 7 for possible values.
OMA LwM2M is a protocol that builds on top of CoAP
OMA Lightweight M2M is a protocol from the Open Mobile Alliance for M2M or IoT device management. Lightweight M2M enabler defines the application layer communication protocol between a LWM2M Server and a LWM2M Client, which is located in a LWM2M Device. The OMA Lightweight M2M enabler includes device management and service enablement for LWM2M Devices. The target LWM2M Devices for this enabler are mainly resource constrained devices. Therefore, this enabler makes use of a light and compact protocol as well as an efficient resource data model. It provides a choice for the M2M Service Provider to deploy a M2M system to provide service to the M2M User. It is frequently used with CoAP
With this we’re ready for experimentation. Let’s fire up the modem, attach it to the network, make it use our own server as the CDP and connect it to Eclipse Wakaama running on the server.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 | |
Once the modem boots up, we
- disable the radio
AT+CFUN=0 - set the CDP to our server
AT+NCDP=198.51.100.1 - re-enable the radio again
AT+CFUN=1 - configure the APN (value depends on your provider)
AT+CGDCONT=1,"IP","APN" - enable
AT+CSCON=1andAT+CEREG=1to monitor network connection and registration status - attach to the network
AT+CGATT=1 - once we see
+CSCON:1and+CEREG:1we can send a test ping withAT+NPING=198.51.100.1
1 2 3 4 | |
Sending AT+QLWSREGIND=0 initiates the registration process and receiving +QLWEVTIND:0 means registration was successful. We can observe this with tcpdump and lwm2mserver included in wakaama.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 | |
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 | |
Great! We’ve registered the modem. Let’s try sending data with AT+QLWULDATA
1 2 3 4 | |
This is a failure. Not only does it error out, it actually triggers a new registration process. Something is missing. Scanning the docs again, there’s a reference to +QLWEVTIND:3 being sent when:
//IoT platform has observed the data object 19. When the module reports this message, the customer can send data to the IoT platform.
This took me a while to figure out, but became clear after reading more about OMA LwM2M. More specifically, object 19 as specified in OMA LightweightM2M (LwM2M) Object and Resource Registry means LwM2M APPDATA:
This LwM2M object provides the application service data related to a LwM2M Server, eg. Water meter data.
This is further specified in Lightweight M2M – Binary App Data Container.
Things are getting clearer now. For the modem to send out data, it tunnels the data inside object 19 and the server has to subscribe to receiving messages on that object. In lwm2mserver there’s a command for it:
1 2 | |
Observe request and ACK in tcpdump:
1 2 3 4 5 6 7 8 | |
Meanwhile on the modem side, we’ve received the +QLWEVTIND:3 message and can send data now:
1 2 3 4 | |
On the lwm2mserver side we can see data coming in:
1 2 | |
Yay! We can now successfully receive data from the modem. In follow-up posts, we’ll try to figure out the differences between AT+QLWULDATA and AT+NMGS, look at receiving data from the server, and maybe write our own LwM2M server to forward data to MQTT.