Protocols for the Internet of Things & Serverless Architecture

About me

Markus Tacker

Senior R&D Engineer

Markus.Tacker@NordicSemi.no
Twitter: @coderbyheart
coderbyheart.com

1980: Born in Germany (Xennial)
1998: first business building websites
2003: Mediengestalter für Digital- und Printmedien, Fachrichtung Medienoperating nonprint
2012: B.Sc. Computer Science (Univ. Wiesbaden)
2017+: in Trondheim, at Nordic Semiconductor

My work at Nordic Semiconductor

2017

First full time cloud engineer working on nrfcloud.com building Software-as-a-service (Saas) offering.

2019

Application Group to work on on open-source end-to-end examples of real world IoT products.

Agenda

Protocols for the Internet of Things

Application data
Data protocols
Transport protocols
Wireless radio protocols
Summary

Serverless Architecture

Scenario overview
Amazon Web Services (AWS) implementation
Microsoft Azure

Protocols for the Internet of Things

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)
cloud side owns device state (because the device may lose power and state)

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.

Store past data in a database for retrieval

Store data on device until it can connect again
Send data batched to the cloud

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
- Protocol buffers
- 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

Protocol buffers

developers.google.com/protocol-buffers

send structured data in efficient binary format without overhead
message format can be changed (ammended) without breaking existing clients
small implementation for embedded devices exists: nanopb

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.

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

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 for embedded devices: 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

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

Summary

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

Serverless architecture

What is serverless?

Serverless computing allows me to focus on implementing the solution, and not spend time on maintaining the infrastructure needed to execute it.

More detailed analysis: martinfowler.com/articles/serverless.html

Why I like serverless

build globally scalable solutions with a small team
suprises are rare, allows me to go on vacation

Going serverless allows me and a rather small team of engineers to build a globally scalable software solution with a very high confidence in it’s scalability and an ease of mind during operations.

In the last years since I have been working fully serverless, I have not once experienced a surprising event that impacted our production system.

Yes, we experience issues which gradually become more serious over time, but in general it happens in a way that does not interfere with my vacation plans.

Serverless not only enables horizontal scalability, but allows to update each component of the solution individually: the code for a lambda function can be replaced without affecting other functions. This means no more waiting minutes for a monolithic container to come up again after a fix has been deployed.

Horizontal Scalablity

Serverless implementations depend on stateless, event-driven implementations.
This allows to process as many requests as needed, in parallel.
However, you have to deal with eventual consistency.

Updating individual components

Instead of restarting the instance,
I can update an individual function.

Downsides of serverless

Testing cloud-native solutions really is a challenge.
More ceremony involved, defining infrastructure as code is now your job.
Impossible to run it locally.
Huge mindset shift from the classical application server model (LAMP, Tomcat, Rails), to a serverless, stateless, eventual consistent application development model.

IoT <3 Serverless

Many, many devices, that don’t share global state
Needs to scale to billions of devices, connections, message per day
Many different operations with different business needs (processing) on small datasets, suits serverless microservice model very well

Architecture Example: store and retrieve temperature data

miro.com/app/board/o9J_llBJjJM=

AWS implementation

Azure implementation

Book recommendations

Thank you & happy connecting!

Please share your feedback!

Markus.Tacker@NordicSemi.no
Twitter: @coderbyheart

Latest version:
bit.ly/tek03iot