A protocol stack for narrowband IoT (part 2)

While the first part of my blog series focused on the technology of NB-IoT, the second part will discuss the technical aspects of using it, as the advantages of transmitting data using narrowband IoT are quickly squandered if it is used incorrectly.

TCP or UDP – the choice of communication protocol

Traditional communication protocols in IoT such as MQTT or AMQP are based on the transmission control protocol (TCP) network protocol. One of the special features of TCP is that, unlike its connectionless counterpart user datagram protocol (UDP) – apart from the lack of support for broad and multicast messages – it allows individual TCP packets to be acknowledged.

The individual packets transmitted by the sender are acknowledged by the receiver, which leads to further messages being transmitted. If the sender does not receive a corresponding confirmation for a packet, it is sent again. The basic principle of UDP, on the other hand, can be described as ‘fire and forget’: data is transmitted to the recipient, but it is irrelevant for the sender whether the delivery was successful or not.

In contrast to UDP, TCP-based connections create an unwanted overhead at transmission protocol level due to the TCP handshake. This effect is negatively reinforced by the higher latencies to be expected in narrowband IoT. These can cause handshakes or packet transmissions to time out. Unfavourable operating environments such as basements or underground car parks further amplify this effect.

The resulting additional transmission attempts lead to increased energy consumption in battery-powered devices. Although some manufacturers promise a battery life of up to ten years for narrowband IoT devices, this is reduced to a few days if used improperly. This generates the need for more frequent maintenance work that may require technicians to be sent into the field, which ultimately leads to a further increase in operating costs.

For this reason, communication with the cloud should not take place via TCP, but via UDP. However, UDP is a connectionless protocol and has no protocol-side delivery guarantee. A sender therefore does not receive an ACK packet from the receiver confirming receipt (acknowledgement). This can be remedied by special UDP-based communication protocols such as MQTT for sensor networks (MQTT-SN) or CoAP. Since we have already had a lot of success with MQTT-SN in this area, this protocol will be presented in more detail below.

Confirming receipt of messages thanks to MQTT-SN

MQTT-SN is a modification of the widely used MQTT protocol, which usually relies on an MQTT-SN gateway. This gateway acts as a proxy between an MQTT SN client and the respective MQTT broker. It translates MQTT-SN into MQTT and vice versa. Gateways are available in aggregated or transparent form. With aggregating gateways, an MQTT connection to the broker is maintained for all connected MQTT SN clients. Transparent gateways, on the other hand, maintain an independent connection for each client in the direction of the broker and are thus indistinguishable from ‘normal’ clients for the broker.

The MQTT-SN protocol, like MQTT, has various mechanisms for acknowledging the receipt or delivery of messages. Quality of service (QoS) levels 1 and 2 are particularly relevant here. They can be used to ensure delivery through the recipient giving their acknowledgement.

The MQTT protocol offers the possibility to publish messages on topics (publish), which other clients can subscribe to (subscribe). For NB-IoT use cases, however, this is not a good option at first, as the frequent transmission of long topics in the respective messages leads to increased energy and data volume consumption. MQTT-SN offers an additional option here: REGISTER messages. These can be used to request a short topic from the gateway for a specific topic. It can be used in the further course of communication between client and gateway to keep the messages to be transmitted as short as possible.

As with MQTT, there is no restriction on the actual ‘payload’ of the PUBLISH messages with MQTT-SN. The payload of a message is the actual content without protocol-specific meta-information such as the topic on which a message is to be published or the message type. While JSON objects can be transmitted, it may make sense, especially in this specific case, to encode the data to be transmitted in a byte format so as to reduce the message and the overhead incurred by constants.

Here is an example to illustrate the effect:

The table above shows a PUBLISH message on a registered topic ID. The first line contains the following JSON payload:

	
	{"temperature":23,"humidity":55}
	

The second line contains the same readings – that is, the numbers 23 and 55. On the cloud side, a corresponding protocol handler must be used, which parses the respective readings to save them as temperature or humidity values.

This reduces the message size by 74 per cent. Doing this can both extend battery life and drastically reduce the volume of data required.

Another significant advantage of MQTT-SN is the possibility for clients to temporarily log off from the gateway and go into sleep state. The client announces that it is logging off with a DISCONNECT message that contains a freely selectable time interval for it to log in again by a certain time. If this does not happen, the client’s session is invalidated because the connection has been lost.

If messages from the cloud intended for the client have accumulated at the gateway in the meantime, they are delivered as soon as the client reports back.

In order to check the availability of active clients, pings – more precisely PINGREQ (ping request) and PINGRESP (ping response) messages – are periodically sent back and forth between the client and the gateway in the active state. Failure to receive these messages will result in a disconnection. By using the sleep state, both the connection to the gateway can be maintained and the number of messages to be transmitted can be reduced, which in turn benefits the battery life.

This eliminates the need to have a continuously present, active connection that triggers the frequent exchange of PINGREQ and PINGRESP messages.

Another challenge in using narrowband IoT, especially for battery-powered devices, is the implementation of security mechanisms. This applies both to authenticating devices and to the end-to-end encryption of the data traffic, which only allows senders and receivers to interpret the transmitted data.

I will take a closer look at this aspect of NB-IoT in the third and final part of my blog series.

Do you want to optimise production using data but not have to hunt for it in different software systems and databases? Do you not want to have to ask a specialist about every data query? Then check out our website and learn how Industrial Internet of Things platforms – IIoT platforms for short – can help.

You will find more exciting topics from the adesso world in our latest blog posts.