IoT Solution Developer Protocols Guide

NARROWBAND
IoT SOLUTION
DEVELOPER
PROTOCOLS
GUIDE
1
 IoT Solution Developer Protocols Guide

INTRODUCTION
To deliver on its massive transformative potential, the Internet of Things needs to interconnect
an enormous number of devices, services, and applications over data networks as efficiently
as possible. Given the ever-growing diversity of devices—from resource-constrained sensors
to sophisticated smart phones—broad range of environments, and myriad evolving use cases,
building viable IoT solutions would be practically impossible if not for the decades of groundwork
that have gone into creating messaging protocols for the web and mobile communications.

Built upon standards established by the For devices operating in remote locations, The Open Mobile Alliance (OMA) uses CoAP
3rd Generation Partnership Project (3GPP), Message Queuing Telemetry Transport in the lightweight machine-to-machine
Narrowband IoT (NB-IoT) cellular networks (MQTT) is often suggested as the preferred (LWM2M) IoT device management standard.
now provide cost-efficient access to a massive messaging protocol. MQTT, however, relies on LWM2M enables remote management and
number of resource-constrained IoT devices the TCP/IP stack as the underlying transport, control of IoT devices using a streamlined
via mobile radio access networks. To take full and TCP is suboptimal for connecting over managed objects model and provides
advantage of NB-IoT, IoT solution developers mobile networks. interfaces for securely monitoring and
need to understand the capabilities and administering devices.
constraints of the NB-IoT data communication. The Internet Engineering Task Force (IETF)
developed the Constrained Application In this document, we highlight the main
Most IoT solution providers have a Protocol (CoAP) as an extremely lightweight characteristics of IoT protocols and assess
background in designing web or enterprise communications protocol stack suitable their suitability for the deployment over NB-
applications and are intimately familiar for resource-constrained, remote devices. IoT mobile networks both over IP and without
with the web protocol stack. Optimized IoT CoAP evolves and streamlines the web IP using Non-IP Data Delivery (NIDD).
applications, however, require a specialized Representational State Transfer (REST)-ful
application-level data transport protocol model inherent in the HTTP to make it as
and an IoT-centric communications stack. efficient and lightweight as possible.

2
 IoT Solution Developer Protocols Guide

IoT DEVICES AND ECOSYSTEM

The Internet of Things is growing to and main characteristics of the related life and cost-efficiency. The constrained
encompass an enormous range of mobile data technologies. Successful IoT nature of NB-IoT devices and networks calls
applications and devices. It is critical for the solutions require that the correct devices are for careful planning of the communications
success of an IoT solution that not only the used with the appropriate communications patterns and higher-level application data
correct devices are used with the appropriate technologies, and that the characteristics and communication protocol.
communications technologies, but also that patterns of the device data reporting, such as
the characteristics and patterns of the device frequency and volume of data are accounted Fig. 2 presents characteristics of the NB-IoT
data reporting, such as frequency, volume of and planned for in the solution design phase. data communication and recommendations
data, and required upstream and downstream for appropriate use of devices,
bandwidth, are accounted for. Access to NB-IoT is a recent evolution of the 3GPP LTE communication patterns, and suitable
power and the amount of electricity consumed standard that provides efficient deployment classes of IoT applications. The rest of this
by devices are also crucial considerations. of resource-constrained, low-cost IoT devices paper explores the MQTT and CoAP/LWM2M
on contemporary mobile networks. NB-IoT messaging protocols and provides analysis
Fig. 1 presents an example of such defines communication channels with limited and recommendations on the appropriate
classification mapping the typical areas of IoT characteristics suitable for constrained, low- uses for each.
applications, 3GPP-defined device classes, maintenance devices that offer long battery

Throughput

Number of transactions for Cat-1 and above is already accounted for per current capacity calculations
Cat-4
DL:~150Mbps
UL:~50Mbps Connected vehicles Routers
VoLTE Video surveillance
Fleet management Smart watch

Low
Cat-1 to mid
DL:~10Mbps Asset trackers latency
UL:~5Mbps
VoLTE

Heart
Smart Connected Connected monitors
Cat-M1 meters elevators health care Activity
DL:~300Kbps trackers
UL:~375Kbps
VoLTE Industrial Bicycle Mid
Industrial monitoring sharing to high
sensors Smart Low latency latency
Cat-NB parking trackers
DL:~20Kbps
Transaction
UL:~60Kbps Up to 2/day Up to 1/hr; 24/day Up to 4/hr; 96/day Up to 10/hr; 240/day >240/day battery life
No voice Battery life: >10 years Battery life: 3-5 years Battery life: Months Battery life: Days Battery life: up to 1 day

Fig. 1: Emerging IoT solutions and devices

3
 IoT Solution Developer Protocols Guide

Functionality NB-IoT Non-IP/IP LTE

Peak Data Rates DN: 15-20 Kbps; Up: 20-25 Kbps ~ 300 Kbps
SMS Yes Yes
Mobility Idle mobility Yes
MQTT-Data No Yes
CoAP Yes Yes
LwM2M - Device Mgmt Non-IP: Device Management, IP: SW updates Yes
LwM2M - Data Yes Yes
Advantage Deeper in-building coverage Higher data rates, mobility voice
Device Profile Low Med High
Up to 48 (every 30
Connections per day Up to 2 Up to 240 (every 6 min) No limit
min)
Proj. Message size, bytes 50 150 350 1500
Size of user data 100 bytes per day 4800 bytes per day 36000 bytes per day
750,000
Per day (bytes) max 0.036 bytes per day 1.7 Mb per year ~13 Mb per year
Acceptable latency, s 20 to 60 10 to 20 < 10 Low
Location No Yes Yes Yes
Mobility Stationary Mobile Mobile Mobile
Sensors, Metering: Smart Infrastructure: Limited Trackers: Real Time Trackers: Kids, Pets
Typical Applications
Water, Gas. Air City Lighting, Parking Smart Bicycle, Livestock Wearables, Connected Transport

Fig. 2: Recommended bandwidth and payload characteristics for NB-IoT and LTE IoT devices

WHAT IS NB-IoT?
NB-IoT is a mobile access technology targeted data transmission protocols and minimize the Developers need to eliminate an unnecessary
at low-cost support for the massive deployment overhead of the data to be transmitted over overhead introduced by the IP, TCP, and TLS.
of lightweight and constrained IoT devices. cellular networks. The IoT device classes targeted by cellular
As such, it has the characteristics of the IoT and NB-IoT technologies will typically
constrained network; specifically, its effective The new OMA LWM2M 1.1 protocol provides transmit from a single byte to tens of bytes
bandwidth in one sector is limited to 226.7 the necessary transport binding for deploying in one payload. The devices will be in sleep
Kbps peak, and the overlaying protocols must over the NB-IoT access networks. It is based on mode most of the time, and there are strong
efficiently address the low-level fragmentation. the streamlined CoAP and contains necessary limitations imposed by the network on this
The protocol targets latency-insensitive semantics for performing device management highly streamlined data transmission channel.
applications. While NB-IoT is designed to and ensuring data transmission via the Typically, the bandwidth will be around 10
allow less than 10 sec latency, typical NB-IoT information-reporting interface. kbps, and the payload has to fit in the radio
devices and applications tolerate from 10 sec frame. Devices are supposed to transmit very
to more than 100 sec of latency. The NB-IoT The New NB-IoT Hourglass infrequently—at most, several times per hour,
devices suitable for applications that require NB-IoT presents developers with the and the transmission latency may be very
long battery life (e.g., 10+ years) and where the challenge of fitting the IoT communication high, from 10 sec. to 100 sec.
devices are expected to transmit an average from constrained devices into a constrained
200 bytes per day.1 communication channel with: These limitations are challenging for an
industry used to the relative freedom
NB-IoT can be used in both IP and NIDD modes. nn Narrow bandwidth of modern high-end communications
The data transmission cost is essentially the nn Low occurrence of data transactions channels. Cellular LTE networks deliver 10+
same as it is applied to gross transmitted nn Very small payloads Mbps bandwidth with latency measured in
data, not to the effective payload. Application nn High to very high latency milliseconds. Plus, reliable, long-lived TCP
developers need to be very efficient in their nn Devices in sleep mode most of the time connections are always available. With the

4
 IoT Solution Developer Protocols Guide

effective payload on the order of magnitude of completely. However, this poses a new effectively addresses those challenges and
bytes, the overhead introduced by the TCP/IP challenge for application developers, allows smooth transition to the constrained
stack becomes significant and can be 10x to requiring them to address the need to NB-IoT stack. Moreover, not only does it
100x relative to actual payload. manage payload fragmentation, in-order deliver data efficiently, but LWM2M’s device
delivery, and flow control. management functionality enables the
NB-IoT allows constrained devices to devices themselves to be managed remotely—
overcome this limitation by introducing The combination of NB-IoT with the allowing for low-maintenance, long-battery-
NIDD and eliminating the TCP/IP stack technologies in the LWM2M 1.1 stack life device deployments and solutions.

Web Model: 1000s of bytes Constrained IoT Model: 1s to 100s of bytes

WWW, LwM2M, IoT, ... Efficient Payload

LwM2M
SenML, CBOR ...
HTTP, WS, MQTT, CoAP
CoAP
TLS, DTLS
DTLS
TCP, UDP UDP NIDD
IP IP

Ethernet, WiFi, LTE NB-IoT

Copper, Fiber, Radio Cellular Radio

Fig. 3: Narrowband IoT hourglass model

In this model, the CoAP becomes the new spanning technology—the waist of the new NB-IoT hourglass model. With built-in congestion control,
block-wise transfer fragmentation handling mechanism, efficient coding of the headers (options) and payload, and the ability to effectively
transport agnostically, CoAP can be reused for both IP- and non-IP-based NB-IoT deployments.

IoT Application

MQTT

TLS

TCP

IP

Ethernet, WiFi, LTE

Copper, Fiber, Radio

Fig. 4: MQTT protocol stack and baseline sequence, QoS 1 and QoS 2 messages

5
 IoT Solution Developer Protocols Guide

DATA COMMUNICATION PROTOCOLS FOR THE

INTERNET OF THINGS
According to the Eclipse 2018 IoT Developer
Survey, MQTT today is the leading messaging TCP MQTT 62.61%
protocol in use today, followed by the group of
web protocols, including HTTP 1.1, HTTP/2, and HTTP 54.10%
WebSocket. CoAP is the only leading UDP-
TCP/
based protocol. WEB
WebSockets 34.95%
It is worth noting that the popularity of the
proprietary in-house protocol implementations HTTP/2 24.92%
is declining as developers realize that
standardized, reliable data protocols with UDP CoAP 22.49%
reasonable messaging or REST semantics are
required to deliver interoperable performance
for IoT solutions. AMQP (0.9 and/or 1.0) 18.24%

The web-based protocols are primarily used In-house/proprietary 12.77%

for communication on browser-based clients,
which typically run on relatively high-capability 0 0.1 0.2 0.3 0.4 0.5 0.6 0.7
devices, such as smartphones that use relatively
high-bandwidth communications channels
(e.g., LTE). However, the two protocols most Fig. 5: Popularity of IoT data transport protocols in 20182
suitable for mass IoT market are MQTT over
TCP and LWM2M and CoAP over UDP. For all
applications and devices deployed over NB- Even though CoAP requires that a single MQTT uses a topic-based, publish-subscribe
IoT, CoAP/LWM2M is recommended. CoAP/LWM2M packet must fit into a UDP model. Clients willing to transmit data connect
datagram, a mechanism has been developed to MQTT servers called message brokers
Both HTTP and MQTT require TCP/IP as the to handle fragmentation and transfer large by issuing the CONNECT command. If the
underlying transport and are not suitable for data on the application level.3 connection is accepted, an MQTT broker
NB-IoT NIDD communication channels. In replies with the CONNACK command. After
contrast, CoAP itself and CoAP-based LWM2M As we will demonstrate further in this the connection is established, data can flow in
use UDP and can be deployed over NIDD since document, MQTT protocol is most suitable both directions.
the only requirement is that the CoAP packets for relatively unconstrained applications
fit into a datagram. MQTT is the only protocol where long-standing connections and large Clients send data to servers in the PUBLISH
that fully supports the publish-subscribe data payloads on the order of magnitude of messages associated to a particular topic.
messaging model, whereas HTTP and CoAP hundreds to thousands of bytes are expected. Clients willing to receive messages from
are REST based. CoAP and LWM2M are better suited for message brokers indicate so by issuing a
resource-constrained IoT applications and SUBSCRIBE command to the MQTT message
CoAP can be seen as the evolution of HTTP for devices, where the payloads are very small. broker, indicating a particular topic. As soon
resource-constrained devices and networks, as publishing clients PUBLISH messages, all
and reuses some HTTP verbs, such as GET, MQTT subscribers to the same topic start receiving
POST, PUT, and DELETE. CoAP and LWM2M MQTT is the lightweight application layer notifications (PUBLISH messages) from the
allow developers to use the observe/notify messaging protocol designed for the relatively message broker.
pattern modeled after the software observer resource-constrained devices used for IoT
design pattern. MQTT does not specify the applications.2 It requires reliable, lossless,
payload format. While CoAP follows the in-order delivery of packets, and relies on the
web model similar to the HTTP content- TCP/IP-based reliability and ordered delivery.
type, LWM2M defines a specific format for However, MQTT requires much less overhead
representing objects and resources. than HTTP.

6
 IoT Solution Developer Protocols Guide

MQTT message reliability (on top of the TCP) is assured by the three quality-of-service (QoS) levels:

QoS Level Model Description

0 At most once Unreliable level – Message is delivered without duplication; no acknowledgment is required
1 At least once Reliable level – Message is delivered at least once with possible duplications; acknowledgment is required
Reliable without duplications – MQTT uses four-way handshake mechanism to ensure that the message is
2 Exactly once
delivered without duplications

Table 1: MQTT quality-of-service levels

CoAP Universal Resource Identifier (URI) instead lightweight with only 4-byte fixed header
CoAP has been specifically designed by of MQTT topics. However, there is a similarity encoding the GET, POST, PUT, DELETE
the IETF to meet the requirements of the between the CoAP URIs and MQTT topics. methods and response codes, type of
constrained devices and communications For example, sensor devices publishing message (confirmable or nonconfirmable),
channels. It is based on the REST their sensor information to a server could be and MessageID used to correlate requests with
architecture following the synchronous described in the following manner: responses (ACKs).
request-response HTTP model. CoAP uses
the GET, PUT, POST, and DELETE methods nn CoAP sensor publishing to CoAP
and response codes similar to, but not server: URI: coap://devices/sensors/
exactly like, HTTP. Therefore, it is easy to temperature
map CoAP traffic from devices to the RESTful
API logic. nn MQTT client publishing to a sensor
queue on the broker: topic: “/devices/
sensors/temperature”
CoAP uses the resource model mapped to the The CoAP message format is compact and Variable token is used for longer-term session

Request / Response Sub-layer: GET, POST, PUT, DELETE, URIs

RESTful interaction Internet Media Types: JSON, XML, octet-stream
CoAP
Message Sub-layer: Reliability De-duplication, retransmissions,
de-fragmentation

DTLS Non-IP Data

Delivery Any Datagram-based transport:
UDP UDP, NIDD, SMS

Fig. 6: CoAP messaging model and functional layers

Methods: GET, POST, PUT, DELETE

4 byte fixed header
Type: CON / NON, MessageID
CoAP
Headers Long term session ID for Observation /
0-8 bytes variable Token
Notifications

Payload variable: Options URI-Host, URI-Path, ..., Content-Format ...

Marker: 0xFF var. Payload ... Payload: JSON, XML, CBOR, octet-stream...

Fig. 7: CoAP message format

7
 IoT Solution Developer Protocols Guide

semantics (e.g., matching notifications to CoAP, on the other hand, runs on top of UDP resources change.
a particular observation request). Variable and provides its own reliability mechanism
options encode URI, content-format, and using confirmable and nonconfirmable CoAP provides its own reliability mechanism
information usually transmitted in the HTTP message types, and the block-wise transfer using confirmable messages and
headers, followed by the variable payload, fragmentation mechanism. nonconfirmable messages. Confirmable
which can be any internet format specified messages have the type “0” (CON), require
by the content-format options, e.g., JSON, Transport layer security for CoAP is an acknowledgment (message type 2 - ACK),
XML, or octet-stream. CoAP is extremely seamlessly provided in the Datagram and the client will continue resending it until
lightweight with only a 4-byte mandatory Transport Layer Security (DTLS) protocol. it receives the ACK message from the server
header. While MQTT specifies only 2 bytes CoAP provides its own reliability, flow control, or it times out. Nonconfirmable messages
for the fixed header, in reality, it has to always and fragmentation handling layers, and the have the type “v1” (NON) and the client will
carry another 2-byte MessageID for any MQTT only hard requirement is that a CoAP message not wait for the ACK. CoAP ACK messages
PUBLISH request. fits into an underlying protocol’s datagram, can carry useful payload data and themselves
meaning it can easily and seamlessly be do not require separate ACKs. The CoAP
CoAP’s request-response mode is deployed on any datagram-based transport, block-wise transfer mechanism ensures
asynchronous and nonblocking. A client does such as SMS or NB-IoT NIDD. reliable transmission of large-size payloads by
not have to wait for the response to initiate splitting it in chunks that are guaranteed to fit
another request, and CoAP responses can also Another remarkable feature of CoAP is into the lower-level datagrams (Fig. 9).
carry data so that no round trips are wasted. the ability to perform asynchronous push
observe/notify requests, which are modeled Whereas CoAP does not provide an explicit
The main difference between CoAP and after the observer software pattern. A server quality-of-service model (unlike MQTT), the
MQTT results from the MQTT requirement initiates a request to observe particular confirmable/nonconfirmable message types
to run on the reliable, lossless, in-order, resources on the CoAP client. The client allow it to loosely map to the MQTT QoS
byte-stream delivery transport, which remembers the request and notifies the semantics as follows:
effectively mandates the TCP/IP stack. server each time the state of the observed

Device Resource State

Device (CoAP Server)

GET Observe Notify Notify Retransmission Notify

X
Application (CoAP Client)

Reported Device Resource State

Fig. 8: CoAP resource observations with confirmable notifications. Illustration courtesy of K. Hartke, Universitaet Bremen TZI.

8
 IoT Solution Developer Protocols Guide

Fig. 9: CoAP fragmentation handling with block-wise transfer for large-size payload

CoAP message type MQTT QoS level Description

NON – Nonconfirmable 0 – At most once Unreliable delivery; messages may be lost
CON – Confirmable 1 – At least once Reliable delivery; messages will not be lost, but may be duplicated

Table 2: CoAP and MQTT QoS mapping

OMA Lightweight M2M (LWM2M)

Defined by the Open Mobile Alliance, LWM2M is built on the CoAP protocol, creates a specific CoAP profile, adds the object model for data
representation on devices, and enables efficient binary payload.

Methods: GET, POST, PUT, DELETE

4 byte fixed header
Type: CON / NON, MessageID
CoAP
Headers Long term session ID for Observation /
0-8 bytes variable Token
Notifications

LwM2M variable: Options URI-Path: 1/0/1, URI-Query: ep=2abf23...

Payload
Marker: 0xFF var. Payload ... Payload: application/vnd.oma.lwm2m+tlv

Fig 10: LWM2M fields mapped on CoAP message format

9
 IoT Solution Developer Protocols Guide

Fig. 10 shows how LWM2M reuses CoAP headers and maps all LWM2M-specific information into the LWM2M payload (URI parameters, specific
LWM2M content formats, etc.). Everything else is encoded in the payload in an efficient binary manner.

LWM2M 1.15 mandates plain text, opaque binary, and CoRE Link data formats for client implementations to ensure on-the-wire data transmission efficiency
and recommends implementing one of the two new data formats based on Sensor Markup Language (SenML) using either JSON or Concise Binary Object
Representation (CBOR). Previously mandatory in LWM2M 1.0 type-length-value (TLV) and optional, JSON is not recommended for use in LWM2M 1.1.

Data format IANA media type CoAP content-format Client mandatory

Plain text Text/plain 0 1.0 optional, 1.1 mandatory
CoRE Link Application/link-format 40 1.0 optional, 1.1 mandatory
Opaque Application/octet-stream 42 1.0 mandatory for firmware downloads, 1.1 mandatory
TLV Application/vnd.oma.lwn2m+tlv 11542 1.0 mandatory, 1.1 not recommended
JSON Application/vnd.oma.lwm2m+json 11543 1.0 optional, 1.1 not recommended
SenML JSON Application/senml+json 110 1.0 N/A, 1.1 recommended
SenML CBOR Application/senml+cbor 112 1.0 N/A, 1.1 recommended

Table 3: LWM2M 1.1 data formats

LWM2M uses a flat object/resource model to describe sensor/actuator model for devices, where a client device contains data structures mapped
to the device architecture and described by an object definition. Each object may have zero or more instances, and each instance contains
resources, which can contain values and be readable, writable, or executable. LWM2M defines a set of objects; however, the objects may be
defined outside of the LWM2M specification and used to model sensors and actuators of a device.

Below is a simple example of a smart lighting controller containing sensor and switch/dimmer objects:

ID Name Operations Type Range Units Description

5850 On/Off RW Boolean Turn the light on or off
5851 Dimmer RW Integer 0–100 % Light dimmer setting
5852 On Time RW Integer sec Time in seconds that the device has been on
5750 Application Type RW String Application type, e.g., “Smart Dimmer”

Table 4: Example of the definition of a smart switch actuator object and resources (object URN: urn:oma:lwm2m:ext:3306)

10
 IoT Solution Developer Protocols Guide

Related LWM2M/CoAP payload could then be:

Light dimmer actuator LWM2M payload example (human readable contents of the binary TLV):

[URI-Path: /3306/0] // CoAP Path-Identifier of the Actuator object with the ID 3306 and instance 0

[Lightweight M2M TLV]:

- 5850: 1 // Light is on - value of resource 5850

- 5851: 73 // Dimmer is at 73% setting - value of resource 5851

- 5852: 1800 // Light has been on for 30 minutes - value of resource 5852

- 5750: “Smart Dimmer” // Application “Smart Dimmer” - value of resource 5750

ID Name Operations Type Range Units Description

Defined by
5700 Sensor Value R Float Current value of the luminosity sensor
units resource
Min Measured
5601 R Float 0–100 % Minimum measured value since port ON or reset
Value
Max Measured
5602 R Float sec Maximum measured value since port ON or reset
Value
Reset Min and
5605 E Opaque Reset min and max measured values to current value
Max Values
5701 Sensor Units R String Type of sensor units, e.g., "lx" for Lux

Table 5: Example of the definition of a luminance sensor object and resources (object URN: urn:oma:lwm2m:ext:3301)

Light luminance sensor LWM2M payload example (human readable contents of the binary TLV):

[URI-Path: /3301/0] // CoAP Path-Identifier of the sensor object with the ID 3301 and instance 0

[Lightweight M2M TLV]:

- 5700: 250 // Luminance is 250 Lux - value of resource 5700

- 5601: 27 // Minimum value was 27 Lux - value of resource 5601

- 5602: 410 // Minimum value was 410 Lux - value of resource 5602

- 5701: “lx” // Measurement unit is Lux - value of resource 5701

11
 IoT Solution Developer Protocols Guide

The sensor/actuator LWM2M control flow (using the underlying CoAP protocol) may look like the following sequence:

Fig. 11: Example of a sensor/actuator communication sequence managing a smart light device via OMA LWM2M/CoAP

In summary, it can easily be seen that:

nn LWM2M does not introduce any header overhead to the underlying CoAP protocol.
nn LWM2M-specific header and payload values are very lightweight and usually coded as binary (JSON and text payloads are optional).

Therefore, in the overhead and traffic analysis, we do not need to specifically separate CoAP and LWM2M.

Note, however, that whereas LWM2M uses mostly binary payload and headers (options), even for text payloads such as JSON, the resources and values are
coded as integers. CoAP generally does not limit the formats, which can contain textual URI paths and text-based payloads, such as JSON and XML.
12
 IoT Solution Developer Protocols Guide

MQTT AND COAP TRAFFIC ANALYSIS

Packet overhead

The basic header structure and length for both MQTT and CoAP messages are very similar and lightweight. While CoAP requires a minimum of 4
bytes of headers, including the MessageID, the MQTT NOTIFY control packet also requires a minimum total of headers of 4 bytes (2 bytes for the
fixed header and 2 bytes for the Packet Identifier). For all protocols, MQTT topic and CoAP URIs are considered to belong to the payload.

MQTT requires an ordered lossless packet delivery and relies on the TCP as the underlying transport.2 User Datagram Protocol (UDP) and other
connectionless network transports, such as NB-IoT, are not suitable for MQTT due to the possibility of data loss and packet re-ordering. Therefore,
using MQTT creates packet overhead from both IP and TCP protocols.

CoAP, on the other hand, is designed to use UDP transport, does not require lossless and ordered delivery, and provides higher protocol level
fragmentation and flow controls. CoAP can be seamlessly deployed on any datagram transport, such as UDP, SMS, and NB-IoT (including NIDD).

MQTT Messaging Model CoAP Messaging Model LwM2M Messaging Model

Application Application LwM2M

Requests / Acks Requests / Responses LwM2M Operations

MQTT CoAP CoAP
MQTT Control Packets Messages Messages

TCP UDP UDP

NIDD NIDD
IP IP IP

Fig. 12: Comparison of MQTT and CoAP messaging models

MQTT involves complete packet overhead of TCP/IP packets (20 byte minimum for IPv4 headers and 40 bytes for IPv6). The TCP layer requires a
minimum of 24 bytes for the first two handshake messages and 20 bytes for the final ACK. Plus, teardown requires four messages with a minimum of
20 bytes each. Additionally, each TCP ACK will contribute an additional 20 bytes. In contrast, UDP packets only have a total of eight bytes each. When
CoAP/LWM2M is deployed over the NIDD transport, the UDP/IP stack is completely eliminated, providing more space for the payload data (Fig. 13).

Considering that in most cases each data transmission (e.g., MQTT NOTIFY control packet) requires a TCP ACK (20 bytes), the CoAP/LWM2M
savings will be even higher.

Start CoAP DATA CoAP over NIDD

+44 bytes

Start
CoAP over UDP/IP
IP CoAP DATA +16 bytes

Start
IP TCP MQTT DATA MQTT over TCP/IP

Padding CRC NB-IoT

Fig. 13: Header overhead forNAC RLC NAS
IoT protocols over NB-IoT Transport Block Layer

13
 IoT Solution Developer Protocols Guide

Transmission overhead minimum overhead will be 352 bytes message is followed by the CoAP ACK
(not counting MQTT PUBLISH/PUBACK message) for all LWM2M operations. It is not
Each TCP connection requires a three-way control packets), which would be more mandated for the Notify (LWM2M information
handshake with a total of three messages and than 700 percent higher relative to the 50 reporting interface) operations but is highly
approximately 130 bytes, whereas teardown byte payload. Clearly, this would be very recommended since NB-IoT does not prevent
requires four messages with a total of 160 expensive for applications where devices packet loss.
bytes. Additionally, each MQTT packet will sleep most of the time, then wake up to
be followed by a TCP ACK (20 bytes each). report small payload, and go to sleep again. This leads to a very light transmission
Additionally, MQTT provides a mechanism to overhead for the CoAP data, even accounting
MQTT initially requires the client to initiate keep the TCP connection alive. However, the for the registration and deregistration, for a
a connection to the MQTT broker with two keep-alive packets are to be initiated by the total of approximately 20 bytes. Additionally,
messages: PUBLISH and PUBACK. After the client, which will require the devices to wake the client is not required to deregister as
MQTT connection has been established, the up just for the sake of sending the keep-alive soon as it wakes up before the registration
client can publish data by sending PUBLISH packet. lifetime expires.
messages to the server. MQTT has three QoS
levels, and the most typical QoS1 (at least CoAP/LWM2M, on the other hand (Fig. 15), Experimental measurement of various
once delivery) for reliable transmission will does not require any connection or session application data transmission protocols over
acknowledge each data publication with the setup on the TCP/IP level. LWM2M provides a live NB-IoT network in various conditions
PUBACK MQTT control packet. registration interface that requires the device is presented in Fig. 16. For good network
client to register with the server. This will conditions with low latency and low packet
The overall sequence with the overhead only require two CoAP messages (i.e., UDP loss, all connectionless transports (raw
budget to send one piece of data is shown datagrams). In addition, the server needs to UDP and CoAP) require only one message
on Fig. 14. If data reporting is infrequent send the first request to start observations, transmission, and the payload overhead
and requires TCP and MQTT to reestablish after which the client starts sending is very low due to the CoAP headers. The
connections each time, then the relative notifications asynchronously. LWM2M also overhead for the MQTT/TCP/IP stack would
overhead becomes huge for small data mandates the acknowledgments (CoAP be approximately 10 times higher due to TCP
payload. For example, the estimated confirmable mode where a CoAP CON and MQTT handshakes and ACKs.

Fig. 14: MQTT/TCP single notification round-trip data, no TLS, no keep-alive, QoS1 messages: 312 bytes registration overhead

14
 IoT Solution Developer Protocols Guide

Fig. 15: CoAP single notification round-trip data, no TLS, CON messages: 20 bytes registration overhead

With degraded radio conditions and higher packet loss, connectionless transport overhead remains the same, but packets now start to get lost.
CoAP overhead increases due to the increased number of retransmissions; however, the data does not get lost due to the CoAP confirmable
message type mechanism. Overhead for MQTT/TCP would slightly increase due to the need to retransmit packets.

Overall, MQTT/TCP traffic requires approximately 10x more transactions and the data overhead is approximately 100x higher compared to the
CoAP/UDP traffic for the 5-byte payload (Fig. 16).

~10x transactions Protocol

CEO CEO CEO CE2
-90 -100 -110 -120 -127
NIDD
12.00 SMS
12
11.00 UDP
Average number of application layer Tx

COAP
10.00 10.00
10 TCP
9.00 9.00 9.00 MQTT
8.00
8

6.00
6
5.00 5.00

4
3.00
2.00 2.00 2.00 2.00 2.00
2
1.00 1.00 1.00 1.00 1.00 1.00 1.00 1.00 1.00 1.00 1.00 1.00 1.00
0

700 686.0 CoAP

638.0
retransmission
590.0
add to application
586.0
600 overhead
532.0
497.0
500 9.00

~100x payload 6.00

Average Tx

400

300 273.0 273.0 262.0

200
126.0
100
33.0 46.0 33.0 46.0 33.0 46.0 33.0 33.0
30.0 30.0 30.0 30.0 30.0
0 5.0 5.0 5.0 5.0 5.0
NIDD

SMS

UDP

COAP

TCP

MQTT

NIDD

SMS

UDP

COAP

TCP

MQTT

NIDD

SMS

UDP

COAP

TCP

MQTT

NIDD

SMS

UDP

COAP

TCP

MQTT

NIDD

SMS

UDP

COAP

TCP

MQTT

Fig. 16: Application-layer payload and transaction summary in live NB-IoT network – 5-byte payload

15
 IoT Solution Developer Protocol Guide

CONCLUSIONS AND RECOMMENDATIONS

Both NB-IoT and CoAP have been designed nn CoAP/LWM2M is the preferred nn We do not recommend using MQTT
to meet the requirements of resource- method for IP data transmission over over NB-IoT networks due to very high
constrained IoT devices communicating over NB-IoT networks. overhead and increased number of
constrained transmission channels. They nn CoAP/LWM2M over NIDD offers supe- data transactions.
seamlessly complement each other for both rior transmission performance for both
IP- and non-IP data delivery. network capacity and IoT solutions. It nn MQTT is appropriate for relatively
can provide from 224 to 1,157 percent long-standing MQTT/TCP/IP con-
LWM2M is based on CoAP and does not higher payload efficiency compared to nections that transmit relatively high
introduce significant overhead due to the the TCP/IP-based MQTT. volumes of data (e.g., telematics appli-
LWM2M interface and data models. LWM2M cations). For IoT solutions that require
inherits all the best characteristics of CoAP nn CoAP can be used as a standalone MQTT transport, other types of radio
while adding lightweight efficient binary transport over NB-IoT if the require- technologies, such as LTE, should be
payload and path representation. It is ideally ments for data transmission are signifi- considered.
suited for NB-IoT, especially for applications cantly different than the requirements
where both data transmission and device for data management, and the applica-
management functionalities are required. tion is trying to avoid the overhead of
additional LWM2M features.
We offer the following recommendations
when selecting application-level data
transport protocols for IoT solutions:

Contact information
For any questions or comments, please reach out to IoTDeviceManagement@T-Mobile.com.

References
1. Y. P. E. Wang et al., “A Primer on 3GPP Narrowband Internet of Things,” IEEE Communications Magazine, vol. 55, no. 3, pp. 117-123, Mar. 2017.
2. Eclipse IoT Developer Survey 2018.
3. IETF RFC 7959 – Block-Wise Transfers in the Constrained Application Protocol (CoAP), 2016.
4. MQTT version 3.1.1 OASIS Standard, Dec. 2015.
5. Lightweight Machine-to-Machine Technical Specification, Approved Version 1.1 – August 2018, Open Mobile Alliance.

Acknowledgments
Sergey Slovetskiy, Principal Engineer, Systems Design and Strategy
Jeff Ahmet, Principal Engineer, Technology Development & Strategy
Karthik Iyer, Principal Engineer, Device Technology

Battery life and cost savings compared to Cat-M modules and IoT plans. Coverage not available in some areas.