How to: Send Measurement Values via NB-IoT to CoT

About NB-IoT

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.

Prerequisites
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.

Index

Example

Explanation

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]

Index

Example

Socket

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:

Index

Byte

Example

Explanation

Length

0

1D

Number of bytes

MessageType

1

04

CONNECT

Flags

2

04

See in the appendix

ProtocolID

3

01

Always 0x01

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:

Index

Byte

Example [hex]

Explanation

Length

0

33

Number of transmitted bytes

MessageType

1

0A

REGISTER

TopicID

2,3

0000

Set to 0x0000 in order to request a Topic ID

MessageID

4,5

1122

Message identifier

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:

Index

Byte

Example

Explanation

Length

0

09

Number of transmitted bytes

MessageType

1

0C

PUBLISH

Flags

2

20

Flags in hex

TopicID

3,4

001F

TopicID given by REGACK

MessageID

5,6

1122

Message identifier

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.


Did this page help you?