[RFC] Zephyr IoT Protocols
Flavio Santes <flavio.santes@...>
[RFC] Zephyr IoT Protocols
Currently, Zephyr does not support any machine-to-machine protocol
(M2M). These protocols were defined for inter-communication between
devices or nodes in a constrained networking environment .
Aim and scope
This document proposes the integration of M2M protocols to Zephyr.
Specifically, we are interested in the following protocols:
CoAP , LightweightM2M (LWM2M) , MQTT  and MQTT-SN .
State of the art
LWM2M is a device-management protocol frequently used on the top of
CoAP. CoAP requires UDP as a transport protocol. Optionally, CoAP may
use DTLS (on the top of UDP) for securing communications between
On the other hand, MQTT, a publish-subscribe messaging protocol,
requires TCP as a transport protocol and may use TLS to create a secure
A lightweight version of MQTT for sensor networks (MQTT-SN) can be
deployed in almost any kind of network and it doesn't require any
specific transport protocol. MQTT-SN was created with short-range
wireless networks in mind. However, MQTT-SN can be used with wired or
Support for short-range wireless communications in Zephyr is present
via Bluetooth. Furthermore, the Zephyr's TCP/IP stack only offers UDP.
So far, TCP is work in progress. Zephyr offers a networking security
layer by means of DTLS.
LWM2M + CoAP (wakaama)
A plain C BSD-licensed implementation of LWM2M is available at .
MQTT client library
A client-side plain C implementation, licensed under the Eclipse
Public License .
MQTT client full implementation
Project Paho provides a full implementation in C++ licensed under
the Eclipse Public License .
C library licensed under the Eclipse Public License .
Integrating M2M protocols with Zephyr
MQTT relies on TCP as a transport protocol, and this could be an
stopper. So far, there is no evidence of any other inconvenience for
integrating LWM2M, CoAP and MQTT-SN.
The integration of the M2M protocols could fit into the lib/m2m
directory (to be created), generating a directory per protocol:
MQTT-SN can be the first protocol added to Zephyr, given the few
dependencies involved in its development and testing. We can continue
with CoAP/LWM2M and finally with MQTT. However, it's not clear if the
Zephyr's licenses are compatible with the Eclipse Public License, so
this could be a stopper (we can always write the code from scratch if
this license is incompatible with Zephyr's).
 Terminology for Constrained-Node Networks
C. Bormann, et al.
 OMA Lightweight M2M (LWM2M) protocol
Open Mobile Alliance
 The Constrained Application Protocol (CoAP)
Z. Shelby, et al.
 MQTT Version 3.1.1
Andrew Banks and Rahul Gupta
 MQTT For Sensor Networks Protocol Specification Version 1.2
Andy Stanford-Clark and Hong Linh Truong
 LWM2M implementation - Wakaama Project
 MQTT C client - Eclipse Paho
 MQTT C/C++ Embedded clients - Eclipse Paho
 MQTT-SN - Eclipse Paho
I fully agree with your plan of implementing the IoT protocols but have a few questions related to thetoggle quoted messageShow quoted text
What is the minimal SoC required for the implementation of let’s say
DTLS + CoAP + LWM2M + Application (assumed to be small)?
There are a lot of SoC out there in real IoT products already that probably could replace
whatever codebase they currently run (Zigbee, or other 802.15.4, RIOT, Contiki, mbed OS, etc)
so this is very interesting for me at least.
In Contiki we have a stack that can run on STM32W108 which has 16 KB of RAM and 256 KB of
flash that we used for IPSO Interop last year and had the following:
- Full Yanzi Application Layer Stack
- DTLS + CoAP + LWM2M + IPSO Objects
Running in Yanzi LED Lamps and Yanzi Smart Plugs and they was interop tested with Wakaama
and Leshan plus other implementations at the event. This codebase is already in upstream Contiki.
Thread + Nest’s application layer seems to need more than Thread/6LoWPAN + LWM2M and therefore
requires larger devices - I am very interested in seeing which is your target for IoT devices that needs
connectivity and a full IP + Application stack.
Personally i would also vote for calling these IoT protocols rather than M2M protocols. All of them
are Internet protocols and M2M sounds more M-Bus, modbus, and the likes to me. So the title
“Zephyr IoT protocols” i do like, but I suggest having them in something that is IP-network related
rather than in a lib/m2m folder.
Also, there are plenty of reference implementations out there. I think you should at least also have
Leshan (LWM2M server/client library) in the list also, and possibly the Contiki implementations of
MQTT/LWM2M that might not be reference implementations but would match an implementation
that would fit constrained IoT devices (which will be a part of the future as long as RAM costs energy
to retain and money to buy).
— Joakim Eriksson, SICS
On 19 Apr 2016, at 23:22, Santes, Flavio <flavio.santes(a)intel.com> wrote:
Flavio Santes <flavio.santes@...>
Hello Joakim,toggle quoted messageShow quoted text
Your feedback is really appreciated.
-----Original Message-----Our target SoC's are the same as Zephyr's. This is a new feature to be
added to Zephyr.
Thank you for sharing the specs of your demos. It could be interesting
to compare your results with Zephyr. Can you describe your setup
(number or nodes, networking technology, average response time
node <-> server)?
Personally i would also vote for calling these IoT protocols rather than M2MRegarding the naming convention, I do prefer "IoT Protocols" than "M2M".
However, "m2m" is shorter than "iot_proto", perhaps just "iot" would
Let's see what others say in the coming days!
So far, we didn't consider Leshan because is written in Java. However,
we could use it in the server side during tests.
On Apr 20, 2016, at 9:04 PM, Santes, Flavio <flavio.santes(a)intel.com> wrote:What about lib/comms or lib/net ?
Also, there are plenty of reference implementations out there. I think you shouldSo far, we didn't consider Leshan because is written in Java. However,