NarrowBand IoT (NB-IoT) is a low-bandwidth, energy and cost saving mobile radio technology. Deutsche Telekom’s currently used protocol to connect devices to Cloud of Things via NB-IoT is MQTT-SN. MQTT-SN is derived from the widely used protocol MQTT and fits perfectly to the specifications of NB-IoT.
In this How-To we show you a simple process of sending measurement values to Cloud of Things.
Before using it, esnure that you meet the following requirements:
- Account/Tenant on Cloud of Things
- An NB-IoT Modem (preferably a u-blox SARA-N211 with firmware version 6.57)
- A Sim Card of Deutsche Telekom provisioned for the APN nb-cloud.ic.m2mportal.de and the credentials for MQTT-SN
- Basic understanding of how to attach to DT’s NB-IoT network (see Quick Start Guide)
The instructions here show real examples of AT-commands, which are modem specific and will only work for u-blox SARA-N211 modem with firmware version 6.57. Nevertheless, the shown MQTT-SN messages are generally valid.
When using another modem please refer to the corresponding AT-commands manual.
Step 1. Opening a Socket
Before opening a socket, ensure that your modem is attached to the network.
Command: at+nsocr=”[Type]”,[Protocol],[ListenPort] Response: [Socket] OK
Now messages can be sent and received.
|Type||DGRAM||Socket type, eg. DGRAM for Datagram|
|Protocol||17||Transport Protocol, eg. 17 for UDP|
|ListenPort||16666||Source port for outgoing packages|
Step 2. Sending a Message
To send a message use this command and note the response.
Command: at+nsost=[Socket],”[RemoteAddress]”,[RemotePort],[Length],”[Data]” Response: [Socket],[Length]
|Socket||0||Socket number is given by the modem after opening a socket (at+nsocr)|
|RemoteAddress||172.25.102.151||Unique destination address (MQTT-SN Gateway: 172.25.102.151)|
|RemotePort||1883||Destination Port (for MQTT-SN: 1883)|
|Length||2||Decimal length of Data in Bytes to be sent|
|Data||0218||Data in hexstring format|
Step 3. Reading a Received Message
When the modem receives an incoming message, it notifies the user with an indication (+NSONMI) also called an Unsolicited Result Code (URC). The URC specifies the socket on which the message was received and the number of available bytes, which can then be read as follows:
URC: +NSOMNI=[Socket],[AvailableBytes] Command: at+nsorf=[Socket],[Bytes] Response: [Socket],”[RemoteAddress]”,[RemotePort],[Length],”[Data]”,[AvailableBytes]
About MQTT-SN Messages
The following figure shows the basic message flow between the modem and the MQTT-SN Gateway when sending a measurement value to Cloud of Things.
First Message: CONNECT
The first message is CONNECT and is sent to setup an active connection.
The general syntax of a CONNECT message is given as follows:
|Length||0||1D||Number of bytes|
|Flags||2||04||See in the appendix|
|Duration||4,5||1388||Contains the value of the Keep Alive Timer in seconds|
|ClientID||6,n||*||DT uses IMSI+Password as ClientID|
*Imsi: “111111111112345” Password “abcdefgh” in hex: 3131313131313131313131323334356162636465666768
Note: The MQTT-SN messages are built up syntactically. The connect message in this example starts with "1D0428011388<IMSIPassword_hex>". Everything in the string prior to that point is derived from the Send message syntax, which was described earlier in this article.
Command: at+nsost=0,"172.25.102.151",1883,29,"1D0404011388<IMSIPassword_hex>” URC: +NSOMNI= 0,3 Command: at+nsorf=0,3 Response: 0, “172.25.102.151”,1883,3,”030500”,0
The returned message “030500” is a CONNACK and shows the successful setup of the connection.
Second Message: REGISTER
MQTT-SN is designed for low-bandwidth networks and therefore uses TopicIDs instead of Topicnames as in MQTT. Therefore, a TopicID has to be registered before messages can be published. The specific Topicnames for Cloud of Things are defined in [Developer Guide]. The Topicname for e.g. humidity is NBIoT/>IMSI>/MES/5 and will be used as an example in the following.
The general structure of a REGISTER message is given as follows:
|Length||0||33||Number of transmitted bytes|
|TopicID||2,3||0000||Set to 0x0000 in order to request a Topic ID|
|TopicName||6,n||4E42496F542F<IMSI_hex>2F4D45532F35||TopicName in hex, eg. NBIoT//MES/5|
Command: at+nsost=0,"172.25.102.151",1883,33,"210A000011224E42496F542F<IMSI_hex>2F4D45532F35” URC: +NSOMNI= 0,7 Command: at+nsorf=0,7 Response: 0,”172.25.102.151”,1883,7,”070B001F112200”,0
The response to a REGISTER message is a REGACK message which contains the TopicID (red).
Third Message: PUBLISH
The third message is a PUBLISH. It is used to publish data to the registered topic.
The general structure for a PUBLISH message is given as follows:
|Length||0||09||Number of transmitted bytes|
|Flags||2||20||Flags in hex|
|TopicID||3,4||001F||TopicID given by REGACK|
|Data||7,n||3231||Value in hex, eg. 21|
Command: at+nsost=0,"172.25.102.151",1883,09," 090C20001F11223231” URC: +NSOMNI= 0,7 Command: at+nsorf=0,7 Response: 0,”172.25.102.151”,1883,7,”070D001F112200”,0
As the Flags requested a QoS level of 1 in this case, a PUBACK (”0x070D001F112200”) is returned.
Updated about 4 years ago