Topics

[RFC] Zephyr IoT Protocols


Flavio Santes <flavio.santes@...>
 

[RFC] Zephyr IoT Protocols


Problem definition

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 [1].


Aim and scope

This document proposes the integration of M2M protocols to Zephyr. 
Specifically, we are interested in the following protocols: 
CoAP [3], LightweightM2M (LWM2M) [2], MQTT [4] and MQTT-SN [5].


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 
devices.

On the other hand, MQTT, a publish-subscribe messaging protocol, 
requires TCP as a transport protocol and may use TLS to create a secure
channel. 

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
wireless networks.

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.


Reference implementations 

  LWM2M + CoAP (wakaama)
    A plain C BSD-licensed implementation of LWM2M is available at [6].

  MQTT client library
    A client-side plain C implementation, licensed under the Eclipse
    Public License [7].

  MQTT client full implementation
    Project Paho provides a full implementation in C++ licensed under
    the Eclipse Public License [8].

  MQTT-SN
    C library licensed under the Eclipse Public License [9].


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.

Proposed roadmap

The integration of the M2M protocols could fit into the lib/m2m 
directory (to be created), generating a directory per protocol:

lib/
|-- m2m
    |-- coap
    |-- lwm2m
    |-- mqtt
    |-- mqtt_sn

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).

References

[1] Terminology for Constrained-Node Networks
    C. Bormann, et al.
    May, 2014
    <https://www.rfc-editor.org/rfc/rfc7228.txt>

[2] OMA Lightweight M2M (LWM2M) protocol
    Open Mobile Alliance
    December, 2013
    <http://openmobilealliance.hs-sites.com/
    lightweight-m2m-specification-from-oma>

[3] The Constrained Application Protocol (CoAP)
    Z. Shelby, et al.
    June, 2014
    <https://tools.ietf.org/html/rfc7252>

[4] MQTT Version 3.1.1 
    Andrew Banks and Rahul Gupta 
    October 2014
    <http://docs.oasis-open.org/mqtt/mqtt/v3.1.1/os/mqtt-v3.1.1-os.pdf>

[5] MQTT For Sensor Networks Protocol Specification Version 1.2
    Andy Stanford-Clark and Hong Linh Truong    
    November, 2014
    <http://mqtt.org/new/wp-content/uploads/2009/06/
    MQTT-SN_spec_v1.2.pdf>

[6] LWM2M implementation - Wakaama Project
    Eclipse Foundation
    <https://github.com/eclipse/wakaama>

[7] MQTT C client - Eclipse Paho
    Eclipse Foundation
    <https://www.eclipse.org/paho/clients/c/>
    GIT repo:
    <https://github.com/eclipse/paho.mqtt.c>

[8] MQTT C/C++ Embedded clients - Eclipse Paho
    Eclipse Foundation
    <https://www.eclipse.org/paho/clients/c/embedded/>
    GIT repo:
    <http://git.eclipse.org/c/paho/
    org.eclipse.paho.mqtt.embedded-c.git>

[9] MQTT-SN - Eclipse Paho
    Eclipse Foundation
    <https://www.eclipse.org/paho/clients/c/embedded-sn/>
    GIT repo:
    <http://git.eclipse.org/c/paho/
    org.eclipse.paho.mqtt-sn.embedded-c.git/>


Joakim Eriksson
 

I fully agree with your plan of implementing the IoT protocols but have a few questions related to the
planned implementation.

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).


Best regards,
— Joakim Eriksson, SICS

On 19 Apr 2016, at 23:22, Santes, Flavio <flavio.santes(a)intel.com> wrote:

[RFC] Zephyr IoT Protocols


Problem definition

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 [1].


Aim and scope

This document proposes the integration of M2M protocols to Zephyr.
Specifically, we are interested in the following protocols:
CoAP [3], LightweightM2M (LWM2M) [2], MQTT [4] and MQTT-SN [5].


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
devices.

On the other hand, MQTT, a publish-subscribe messaging protocol,
requires TCP as a transport protocol and may use TLS to create a secure
channel.

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
wireless networks.

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.


Reference implementations

LWM2M + CoAP (wakaama)
A plain C BSD-licensed implementation of LWM2M is available at [6].

MQTT client library
A client-side plain C implementation, licensed under the Eclipse
Public License [7].

MQTT client full implementation
Project Paho provides a full implementation in C++ licensed under
the Eclipse Public License [8].

MQTT-SN
C library licensed under the Eclipse Public License [9].


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.

Proposed roadmap

The integration of the M2M protocols could fit into the lib/m2m
directory (to be created), generating a directory per protocol:

lib/
|-- m2m
|-- coap
|-- lwm2m
|-- mqtt
|-- mqtt_sn

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).

References

[1] Terminology for Constrained-Node Networks
C. Bormann, et al.
May, 2014
<https://www.rfc-editor.org/rfc/rfc7228.txt>

[2] OMA Lightweight M2M (LWM2M) protocol
Open Mobile Alliance
December, 2013
<http://openmobilealliance.hs-sites.com/
lightweight-m2m-specification-from-oma>

[3] The Constrained Application Protocol (CoAP)
Z. Shelby, et al.
June, 2014
<https://tools.ietf.org/html/rfc7252>

[4] MQTT Version 3.1.1
Andrew Banks and Rahul Gupta
October 2014
<http://docs.oasis-open.org/mqtt/mqtt/v3.1.1/os/mqtt-v3.1.1-os.pdf>

[5] MQTT For Sensor Networks Protocol Specification Version 1.2
Andy Stanford-Clark and Hong Linh Truong
November, 2014
<http://mqtt.org/new/wp-content/uploads/2009/06/
MQTT-SN_spec_v1.2.pdf>

[6] LWM2M implementation - Wakaama Project
Eclipse Foundation
<https://github.com/eclipse/wakaama>

[7] MQTT C client - Eclipse Paho
Eclipse Foundation
<https://www.eclipse.org/paho/clients/c/>
GIT repo:
<https://github.com/eclipse/paho.mqtt.c>

[8] MQTT C/C++ Embedded clients - Eclipse Paho
Eclipse Foundation
<https://www.eclipse.org/paho/clients/c/embedded/>
GIT repo:
<http://git.eclipse.org/c/paho/
org.eclipse.paho.mqtt.embedded-c.git>

[9] MQTT-SN - Eclipse Paho
Eclipse Foundation
<https://www.eclipse.org/paho/clients/c/embedded-sn/>
GIT repo:
<http://git.eclipse.org/c/paho/
org.eclipse.paho.mqtt-sn.embedded-c.git/>


Flavio Santes <flavio.santes@...>
 

Hello Joakim,

Your feedback is really appreciated.

-----Original Message-----
From: Joakim Eriksson [mailto:joakime(a)sics.se]
Sent: Wednesday, April 20, 2016 2:01 AM
To: Santes, Flavio <flavio.santes(a)intel.com>
Cc: Joakim Eriksson <joakime(a)sics.se>; devel(a)lists.zephyrproject.org
Subject: Re: [devel] [RFC] Zephyr IoT Protocols

I fully agree with your plan of implementing the IoT protocols but have a few
questions related to the planned implementation.

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.
Our target SoC's are the same as Zephyr's. This is a new feature to be
added to Zephyr.


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.
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 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.
Regarding the naming convention, I do prefer "IoT Protocols" than "M2M".
However, "m2m" is shorter than "iot_proto", perhaps just "iot" would
also work.
Let's see what others say in the coming days!


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).
So far, we didn't consider Leshan because is written in Java. However,
we could use it in the server side during tests.

Cheers,
Flavio


Best regards,
— Joakim Eriksson, SICS


On 19 Apr 2016, at 23:22, Santes, Flavio <flavio.santes(a)intel.com> wrote:

[RFC] Zephyr IoT Protocols


Problem definition

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 [1].


Aim and scope

This document proposes the integration of M2M protocols to Zephyr.
Specifically, we are interested in the following protocols:
CoAP [3], LightweightM2M (LWM2M) [2], MQTT [4] and MQTT-SN [5].


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
devices.

On the other hand, MQTT, a publish-subscribe messaging protocol,
requires TCP as a transport protocol and may use TLS to create a secure
channel.

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
wireless networks.

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.


Reference implementations

LWM2M + CoAP (wakaama)
A plain C BSD-licensed implementation of LWM2M is available at [6].

MQTT client library
A client-side plain C implementation, licensed under the Eclipse
Public License [7].

MQTT client full implementation
Project Paho provides a full implementation in C++ licensed under
the Eclipse Public License [8].

MQTT-SN
C library licensed under the Eclipse Public License [9].


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.

Proposed roadmap

The integration of the M2M protocols could fit into the lib/m2m
directory (to be created), generating a directory per protocol:

lib/
|-- m2m
|-- coap
|-- lwm2m
|-- mqtt
|-- mqtt_sn

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).

References

[1] Terminology for Constrained-Node Networks
C. Bormann, et al.
May, 2014
<https://www.rfc-editor.org/rfc/rfc7228.txt>

[2] OMA Lightweight M2M (LWM2M) protocol
Open Mobile Alliance
December, 2013
<http://openmobilealliance.hs-sites.com/
lightweight-m2m-specification-from-oma>

[3] The Constrained Application Protocol (CoAP)
Z. Shelby, et al.
June, 2014
<https://tools.ietf.org/html/rfc7252>

[4] MQTT Version 3.1.1
Andrew Banks and Rahul Gupta
October 2014
<http://docs.oasis-open.org/mqtt/mqtt/v3.1.1/os/mqtt-v3.1.1-os.pdf>

[5] MQTT For Sensor Networks Protocol Specification Version 1.2
Andy Stanford-Clark and Hong Linh Truong
November, 2014
<http://mqtt.org/new/wp-content/uploads/2009/06/
MQTT-SN_spec_v1.2.pdf>

[6] LWM2M implementation - Wakaama Project
Eclipse Foundation
<https://github.com/eclipse/wakaama>

[7] MQTT C client - Eclipse Paho
Eclipse Foundation
<https://www.eclipse.org/paho/clients/c/>
GIT repo:
<https://github.com/eclipse/paho.mqtt.c>

[8] MQTT C/C++ Embedded clients - Eclipse Paho
Eclipse Foundation
<https://www.eclipse.org/paho/clients/c/embedded/>
GIT repo:
<http://git.eclipse.org/c/paho/
org.eclipse.paho.mqtt.embedded-c.git>

[9] MQTT-SN - Eclipse Paho
Eclipse Foundation
<https://www.eclipse.org/paho/clients/c/embedded-sn/>
GIT repo:
<http://git.eclipse.org/c/paho/
org.eclipse.paho.mqtt-sn.embedded-c.git/>


Kumar Gala
 

On Apr 20, 2016, at 9:04 PM, Santes, Flavio <flavio.santes(a)intel.com> wrote:

Hello Joakim,

Your feedback is really appreciated.

-----Original Message-----
From: Joakim Eriksson [mailto:joakime(a)sics.se]
Sent: Wednesday, April 20, 2016 2:01 AM
To: Santes, Flavio <flavio.santes(a)intel.com>
Cc: Joakim Eriksson <joakime(a)sics.se>; devel(a)lists.zephyrproject.org
Subject: Re: [devel] [RFC] Zephyr IoT Protocols

I fully agree with your plan of implementing the IoT protocols but have a few
questions related to the planned implementation.

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.
Our target SoC's are the same as Zephyr's. This is a new feature to be
added to Zephyr.


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.
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 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.
Regarding the naming convention, I do prefer "IoT Protocols" than "M2M".
However, "m2m" is shorter than "iot_proto", perhaps just "iot" would
also work.
Let's see what others say in the coming days!
What about lib/comms or lib/net ?

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).
So far, we didn't consider Leshan because is written in Java. However,
we could use it in the server side during tests.

Cheers,
Flavio


Best regards,
— Joakim Eriksson, SICS


On 19 Apr 2016, at 23:22, Santes, Flavio <flavio.santes(a)intel.com> wrote:

[RFC] Zephyr IoT Protocols


Problem definition

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 [1].


Aim and scope

This document proposes the integration of M2M protocols to Zephyr.
Specifically, we are interested in the following protocols:
CoAP [3], LightweightM2M (LWM2M) [2], MQTT [4] and MQTT-SN [5].


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
devices.

On the other hand, MQTT, a publish-subscribe messaging protocol,
requires TCP as a transport protocol and may use TLS to create a secure
channel.

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
wireless networks.

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.


Reference implementations

LWM2M + CoAP (wakaama)
A plain C BSD-licensed implementation of LWM2M is available at [6].

MQTT client library
A client-side plain C implementation, licensed under the Eclipse
Public License [7].

MQTT client full implementation
Project Paho provides a full implementation in C++ licensed under
the Eclipse Public License [8].

MQTT-SN
C library licensed under the Eclipse Public License [9].


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.

Proposed roadmap

The integration of the M2M protocols could fit into the lib/m2m
directory (to be created), generating a directory per protocol:

lib/
|-- m2m
|-- coap
|-- lwm2m
|-- mqtt
|-- mqtt_sn

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).

References

[1] Terminology for Constrained-Node Networks
C. Bormann, et al.
May, 2014
<https://www.rfc-editor.org/rfc/rfc7228.txt>

[2] OMA Lightweight M2M (LWM2M) protocol
Open Mobile Alliance
December, 2013
<http://openmobilealliance.hs-sites.com/
lightweight-m2m-specification-from-oma>

[3] The Constrained Application Protocol (CoAP)
Z. Shelby, et al.
June, 2014
<https://tools.ietf.org/html/rfc7252>

[4] MQTT Version 3.1.1
Andrew Banks and Rahul Gupta
October 2014
<http://docs.oasis-open.org/mqtt/mqtt/v3.1.1/os/mqtt-v3.1.1-os.pdf>

[5] MQTT For Sensor Networks Protocol Specification Version 1.2
Andy Stanford-Clark and Hong Linh Truong
November, 2014
<http://mqtt.org/new/wp-content/uploads/2009/06/
MQTT-SN_spec_v1.2.pdf>

[6] LWM2M implementation - Wakaama Project
Eclipse Foundation
<https://github.com/eclipse/wakaama>

[7] MQTT C client - Eclipse Paho
Eclipse Foundation
<https://www.eclipse.org/paho/clients/c/>
GIT repo:
<https://github.com/eclipse/paho.mqtt.c>

[8] MQTT C/C++ Embedded clients - Eclipse Paho
Eclipse Foundation
<https://www.eclipse.org/paho/clients/c/embedded/>
GIT repo:
<http://git.eclipse.org/c/paho/
org.eclipse.paho.mqtt.embedded-c.git>

[9] MQTT-SN - Eclipse Paho
Eclipse Foundation
<https://www.eclipse.org/paho/clients/c/embedded-sn/>
GIT repo:
<http://git.eclipse.org/c/paho/
org.eclipse.paho.mqtt-sn.embedded-c.git/>