Cloud connectivity and protocols for the Internet of Things

Speakers

Markus Tacker

Senior R&D Engineer
Nordic Semiconductor

Markus.Tacker@NordicSemi.no
Twitter: @coderbyheart

Carl Richard Fosse

Application Engineer
Nordic Semiconductor

Carl.Fosse@NordicSemi.no

#NordicTechWebinars

Agenda

Application data
Data protocols
Transport protocols
How to measure data usage
Wireless radio protocols
Energy consumption considerations
Summary
Ways to your first proof-of-concept

Application data

Typical IoT Data Protocol Configuration

The four kinds of data

Device State
Device Configuration
Past Data
Firmware Updates

1. Device State

sensor readings (like position, temperature)
information about its health (like battery level)

Because the latest state should be immediately visible: buffer data in a Digital Twin.

Update Device State only if needed

implement situational awareness on the device
only send relevant data
- did a sensor reach a critical threshold?
- has enough time passed since last update?
- is the connection good enough?

It is an important criterion for the robustness of any IoT product to gracefully handle situations in which the device is not connected to the internet. It might even not be favorable to be connected all the time—wireless communication is relatively expensive consumes a lot of energy and therefore increases the power consumption.

To optimize for ultra-low power consumption, we want to turn off the modem as quickly as possible and keep it off as long as possible.

This can be achieved by making the device smart and allowing it to decide based on the situation whether it should try to send data.

For example could an asset tracker use the motion sensor to decide whether to publish its state frequently or if it detects no movement for a while go into a passive mode, where it turns of the modem and waits until it detects movement again. It could also use the internal clock to wake up every hour to sent a heartbeat, after all we might want to know that the device is healthy, even it is not in motion.

2. Device Configuration

change behaviour of device in real time (e.g. sensor sensititiy, timeouts)
configure physical state (e.g. locked state of a door lock)

Depending on the product we might also want to change the device configuration. This could on the one hand be use during development to tweak the aforementioned behavior using variables instead of pushing a new firmware over the air to the device. We observe firmware sizes of around 250 KB which will, even when compressed, be expensive because it will take a device some time to download and apply the updated, not to mention the costs for transferring the firmware update over the cellular network. Especially in NB-IoT-only deployments is the data rate low. Updating a fleet of devices with a new firmware involves orchestrating the roll-out and observing for faults. All these challenges lead to the need to be able to configure the device, which allows to tweak the behavior of the device until the inflection point is reached: battery life vs. data granularity. Interesting configuration options are for example the sensitivity of the motion sensor: depending on the tracked subject what is considered “movement” can vary greatly. Various timeout settings have an important influence on power- and data-consumption: the time the device waits to acquire a GPS fix, or the time it waits between sending updates when in motion.

On the other hand is device configuration needed if the device controls something: imaging a smart lock which needs to manipulate the state of a physical lock. The backend needs a way to tell the device which state that lock should be in, and this setting needs to be persisted on the backend, since the device could lose power, crash or otherwise lose the information if the lock should be open or closed.

Here again is the digital twin used on the cloud side to store the latest desired configuration of the device immediately, so the application does not have to wait for the device to be connected to record the configuration change. The implementation of the digital twin then will take care of sending only the latest required changes to the device (all changes since the device did last request its configuration are combined into one change) thus also minimizing the amount of data which needs to be transferred to the device.

3. Past Data

Cellular IoT devices need to send data about past events: they will be offline most of the time.

Source

Imagine a reindeer tracker which tracks the position of a herd. If position updates are only collected when a cellular connection can be established there will be an interesting observation: the reindeers are only walking along ridges, but never in valleys. The reason is not because they don’t like the valley, but because the cellular signal does not reach deep down into remote valleys. The GPS signal however will be received there from the tracker because satellites are high on the horizon and can send their signal down into the valley.

There are many scenarios where cellular connection might not be available or unreliable but reading sensors work. Robust ultra-mobile IoT products therefore must make this a normal mode of operation: the absence of a cellular connection must be treated as a temporary condition which will eventually resolve and until then business as usual ensues. This means devices should keep measuring and storing these measures in a ring-buffer or employ other strategies to decide which data to discard once the memory limit is reached.

Once the device is successfully able to establish a connection it will then (after publishing its most recent measurements) publish past data in batch.

On a side note: the same is true for devices that control a system. They should have built-in decision rules and must not depend on an answer from a cloud backend to provide the action to execute based on the current condition.

4. Firmware Updates

2-3 magnitudes larger than a control message (~250 KB)
notification via control channel (MQTT)
download via data channel (HTTP): less overhead, supports resume

Summary: Application data

great potential for optimization
initiating and maintaining network connection is magnitudes more expensive compared to other device operations (for example reading a sensor value)
invest a substantial amount into optimizing these when developing an ultra-low power product

Data protocols

JSON
Alternatives to JSON
- Flatbuffers
- CBOR

JSON

{
  "v": {
    "lng": 10.414394,
    "lat": 63.430588,
    "acc": 17.127758,
    "alt": 221.639832,
    "spd": 0.320966,
    "hdg": 0
  },
  "ts": 1566042672382
}

“default” data protocol for IoT (AWS, Azure, Google Cloud)

👍 human readable
👍 schema-less (self-describing)

👎 overhead

Possible Optimizations

GPS location message

{
  "v": {
    "lng": 10.414394,
    "lat": 63.430588,
    "acc": 17.127758,
    "alt": 221.639832,
    "spd": 0.320966,
    "hdg": 0
  },
  "ts": 1566042672382
}

02 36 01 37 51 4b 73 2b
d4 24 40 09 68 06 f1 81
1d b7 4f 40 11 68 cd 8f
bf b4 20 31 40 19 e6 5d
f5 80 79 b4 6b 40 21 1a
30 48 fa b4 8a d4 3f 29
00 00 00 00 00 00 00 00
09 00 e0 cf ac f6 c9 76
42

JSON
114 bytes
without newlines

Protocol Buffers
65 bytes (-42%)
source

Flatbuffers

google.github.io/flatbuffers

evolution of Protocol Buffers
access a buffer without parsing
smaller library, C implementation exists
wire format size a little bigger compared to Protocol Buffers
schema-less (self-describing) messages are supported
NOT supported in Zephyr/NCS

In the comparison on the previous slide we showed how using Protocol Buffers can dramatically reduce the transferred data size, while keeping a typed message.

The implementation of Protocol Buffers is however quite big (for a resource constrained device like the nRF9160), and no official encoder/decoder implementation exists for C, inofficial does.

Flatbuffers is the best candidate with similar data savings.

Especially the ability to access members of a message directly in place makes it ideal for memory-constrained devices: no need to create a second copy of the received values.

It also offers flexibility during development is also supported because FlatBuffers offers a schema-less (self-describing) version.

Unfortunately there is no official support in the nRF Connect SDK or Zephyr as of now.

CBOR

cbor.io

maps JSON to binary structures
zero configuration needed between exchanging parties
support in Zephyr (tinycbor)

CBOR: example

GPS location message

{
  "v": {
    "lng": 10.414394,
    "lat": 63.430588,
    "acc": 17.127758,
    "alt": 221.639832,
    "spd": 0.320966,
    "hdg": 0
  },
  "ts": 1566042672382
}

A2 61 76 A6 63 6C 6E 67
FB 40 24 D4 2B 73 4B 51
37 63 6C 61 74 FB 40 4F
B7 1D 81 F1 06 68 63 61
63 63 FB 40 31 20 B4 BF
8F CD 68 63 61 6C 74 FB
40 6B B4 79 80 F5 5D E6
63 73 70 64 FB 3F D4 8A
B4 FA 48 30 1A 63 68 64
67 00 62 74 73 1B 00 00
01 6C 9F 6A CC FE

JSON
114 bytes
without newlines

CBOR
86 bytes (-24%)
source

Summary: Data protocols

Look into denser data protocols!
JSON is for Humans.

devices always™ send the same structure:
no need to transmit it
less data to send
- less money spent on data (grows linear with № of devices)
- less energy consumed = longer device lifetime
- lower chance of failed transmit

Transport protocols

MQTT+TLS
MQTT-SN+(D)TLS
CoAP/LWM2M+(D)TLS

MQTT+TLS

common protocol for “ecommerce” cloud vendors
(AWS, Azure, Google Cloud)

great fit for asynchronous, event oriented communication: MQTT is bidirectional pub/sub model
overhead:
- topic name in every MQTT package
  № of topics per device: ~3
- TLS handshake with AWS IoT broker: ~10 KB
Supported out of the box in nRF Connect SDK

MQTT-SN+(D)TLS

MQTT-SN 1.2 Specification

optimized version designed specifically IoT
supports UDP
use numeric IDs instead of strings for topic names
better offline support
not supported out of the box in nRF Connect SDK
not supported by cloud vendors: needs a (stateful) Gateway

CoAP/LWM2M+(D)TLS

common protocol in Telco clouds (Verizon’s Thingspace, AT&T’s IoT Platform)
typically used for device management (carrier library)
support in nRF Connect SDK (CoAP client sample, LwM2M client sample)
not supported by cloud vendors: needs a (stateful) Gateway.
Proof-of-concept AWS IoT-LwM2M Gateway: github.com/coderbyheart/leshan-aws

How to measure data usage

measure during development already: important input on picking the right connectivity partner
measuring at multiple endpoints tricky (MQTT + HTTP), does not measure failed transmits
nRF9160 modem provides connectivity statistics

One of the biggest cost factors when operating a cellular IoT product are data transfers. Not only are prices for IoT connectivity multiple magnitudes more expensive to what we are used from smartphone contracts, but transmitting data also requires a lot of energy. The longer the devices needs to transmit a payload the more likely it is also that the connection deteriorates (especially when the device is moving) and re-transmits need to happen. Therefore it is important to pay close attention to the amount of data your product is sending from the beginning. Having knowledge about the data usage profile of your application at hand also becomes important when picking the right connectivity partner.

While it is possible to infer a device’s data consumption on the terminating endpoint, this information is not accurate, because it can observe successfully incoming messages. It can also become challenging to cover all endpoints, for example Firmware over the Air updates are typically downloaded via HTTPs from a web server and not through MQTT.

Enable connectivity statistics

Use AT%XCONNSTAT=1 to tell the modem to start collecting connectivity statistics

#include <modem/at_cmd.h>

int err = at_cmd_write("AT%XCONNSTAT=1", NULL, 0, NULL);
if (err != 0) {
    printk("Could not enable connection statistics, error: %d\n", err);
}

Read current connectivity statistics

Use AT%XCONNSTAT? to read the current connectivity statistics

static struct k_delayed_work connstat_work;

static int query_modem(const char *cmd, char *buf, size_t buf_len) { ... }

static void connstat_work_fn(struct k_work *work)
{
    query_modem("AT%XCONNSTAT?", connStatBuffer, sizeof(connStatBuffer));
    // NOTE: k_uptime_get_32() cannot hold a system uptime time
    // larger than approximately 50 days
    printk("Connection stats: %s | Uptime: %d seconds\n",
        connStatBuffer, k_uptime_get_32() / 1000);
    // Schedule next run
    k_delayed_work_submit(&connstat_work, K_SECONDS(60));
}

k_delayed_work_init(&connstat_work, connstat_work_fn);
k_delayed_work_submit(&connstat_work, K_SECONDS(60));

You can see a full diff of how I added this to one of my applications here.

Connectivity statistics output

Connection stats: %XCONNSTAT: 0,0,14,16,748,134 | Uptime: 5041 seconds

Syntax

%XCONNSTAT: <SMS Tx>,<SMS Rx>,<Data Tx>,<Data Rx>,<Packet max>,<Packet average>

SMS Tx: total number of SMSs successfully transmitted
SMS Rx: total number of SMSs successfully received
Data Tx: total amount of data (in kilobytes) transmitted
Data Rx: total amount of data (in kilobytes) received
Packet max: maximum packet size (in bytes) used
Packet average: average packet size (in bytes) used

Caution

Do not use the connectivity statistics in applications which use the LwM2M carrier library.

This library manages the collection of connectivity statistics and will turn them on and off on its behalf. If your application interferes with this statistics collection it will result in incorrect measurements in the carrier’s device management solution.

Wireless radio protocols

375 kbps downlink, 300 kbps uplink
~100 kbps application throughput running IP
supports roaming (same as LTE)
typically uses frequency bands above 2 Ghz
ms-latency

60 kbps downlink, 30 kbps uplink
typically uses frequency bands below 2 Ghz
no roaming support (some Telcos do offer custom solution)
good indoor/underground penetration characteristics
long range

Comparison

LTE-m

for medium throughput applications requiring low power, low latency and/or mobility

asset tracking
wearables
medical
POS
home security

NB-IoT

for static, low throughput applications requiring low power and long range

smart metering
smart agriculture
smart city

Energy consumption considerations

Carl Richard Fosse

My master thesis research

“Power Consumption modeling of TCP and UDP over low power cellular networks for a constrained device”

TCP represented by MQTT
UDP represented by CoAP
Tested both protocols over NB-IoT and LTE-M, using the nRF9160.
Used the data to empirically model the power consumption of the device.

Experiment setup: Components

Hardware: nRF9160DK v0.8.5
SDK: v1.2.0
Measurement unit: Otii ARC
Network provider: Telenor LTE-M and NB-IoT
Power measurement setup will be more thoroughly covered in our webinar the 9th of December.

Experiment setup: Firmware

One application for MQTT and one for CoAP
(available on GitHub)
Long PSM interval with regular transmissions and increasing payload
Average sleep current ~200µA

Energy consumption factors: Application protocols

Establishment of connection
- Especially relevant for TCP
Acknowledgements
Payload size
Protocol defined limits
- Maximum transmission unit (MTU)
- Maximum segment size (MSS)

Energy consumption factors: Cellular network

Connection
RRC inactive timer
Reception quality
Additional parameters - see the Online Power Profiler

Time diagram

In reality

Some results

Transmission energy

Averaged out plots for energy used on transmission
Dashed line – with RRC inactive
Solid line – without RRC inactive energy
The RRC inactive energy is dependent on network provider and was therefore not considered
Notice how much it contributes to the total energy consumed
NB-IoT is linearly dependent on payload size.
LTE-M, with higher capacity, is not. Within the tested payload size range.
Some outliers for TCP over LTE-M resulting in energy consumption spikes. Restarting of RRC inactive timer due to activity
CoAP in general use less energy than MQTT.
Mentioned MSS earlier. These results evidently shows how this affects energy consumption
For MQTT on both LTE-M and NB-IoT there is an increase in consumed power after payload exceeds ~500 bytes
The base MSS is 536 bytes.

Note at last that there is a starting cost to every transmission.

Transmission energy

Transmission time

Transmission time variation

Important observations: Application protocols

MQTT
- TCP is not ideal for low power applications
- MQTT is a popular and well supported protocol
CoAP
- Less overhead compared to MQTT
- Enables reliable UDP
- Not that popular

Important observations: Cellular standards

LTE-M
- High speed, high capacity
- Power consumption not correlated with payload size
- More “spurious” energy consumption
NB-IoT
- Slow, low capacity
- Energy consumption is linearly dependent with payload size

Transfer large amounts of data rarely

rather than small amounts often.

Summary

no silver bullet - multiple conflicting dimensions need to be considered
highly depends on use case scenario
ultra-low power relevant in all scenarios

Ways to your first proof-of-concept

nRF Connect for Cloud
Bifravst

nRF Connect for Cloud

cloud resources (AWS) provided by us
our cellular IoT Development Kits are preconfigured to connect
you can focus on modifying the sample application
- Building NCS applications with Docker in ~2 minutes

nRF Connect for Cloud
nrfcloud.com

Bifravst

concrete end-to-end example for an ultra-low power cellular IoT product in the asset tracker space
end-to-end example: firmware 🡘 cloud 🡘 mobile web app
runs in your AWS account
Azure support in progress
fully open-source
3-clause BSD license (software) and the Nordic 5-clause BSD license (firmware)
firmware developed from ground up with power consumption in mind

bifravst.github.io

Bifravst aims to provide a concrete end-to-end example for an ultra-low power IoT product in the asset tracker space, namely a Cat Tracker.

Bifravst enables the developers to set up a real world IoT solution using the respective cloud provider and adapt the example firmware and software quickly for a specific use case.

Bifravst aims to provide answers and recommend best practices to the following questions :

How can you connect Nordic’s cellular IoT chips to your cloud provider?
How do devices send data into the cloud?
How can the data be sent to the devices?
How can users and other services interact with the devices?
How can you update the application firmware of your devices while they are deployed in the field?
How can you develop a cellular IoT product that maximizes battery life, minimizes data usage, and handles unreliable connectivity gracefully?

Thank you & happy connecting!

Please share your feedback!

Markus.Tacker@NordicSemi.no
Twitter: @coderbyheart

Carl.Fosse@NordicSemi.no

#NordicTechWebinars

Latest version: bit.ly/nwiotp