[wakaama-dev] wakaama 2 design

[David Navarro - IoTerop <david.navarro@xxxxxxxxxxx>]

Hi everyone,

 

As stated in a previous email, adding the LwM2M 1.1 features to wakaama is not an easy process with the current design. Here I'm presenting my vision of the new design and from there, the roadmap.

 

Code Reorg

When looking at a LwM2M implementation, you can identify several areas or modules:

• Bootstrap Client-side
• Bootstrap Server-side
• Registration Client-side
• Registration Server-side
• Device Management operations Client-side
• Device Management operations Server-side
• Observations Client-side
• Observations Server-side
• Objects (only for the Client)
• Data encoding and parsing
• CoAP stack
• Client-side APIs
• Server-side APIs

 

Currently in wakaama, these areas are roughly organized by files. But there is not a clear distinction in the code. So the first step of the wakaama redesign is to have a clear separation of the various areas in the code.

 

When this is done, we simplify the logic of the various operations performed by the stack.

For instance when the Client receives a CoAP GET request from the Server, if it is an Observe operation, the resources' values are retrieved from the Object manager then past to the observation engine to be analyzed, then serialized. If it is a Read Operation, the Object manager returns the serialized data.

After the re-design, we will factorize the code: the Object manager would only returns the resources' values and the encoding module would serialize the data. This reduce the potential interactions and special handling.

 

Another benefit:

It would be easier to reuse external libraries already present in the system. Some devices may already feature a CoAP stack or a JSON parser. There would be an unique point in the code to replace.

 

Once the code reorg done, we can start implementing the LwM2M 1.1 features:

 

SenML JSON

• The JSON-based LwM2M 1.0 format is based on a work-in-progress version of the Sensor Markup Language of the IETF. Since then, the IETF finalized and released a final version.

 

Thanks to Scott, this will be part of wakaama soon.

 

SenML CBOR

• The binary version of SenML JSON.

 

Various open source implementations of CBOR are already available.  Wakaama will use one of these.

 

OSCORE

• Authentication and Encryption at the CoAP layer level providing end-to-end security.

 

I was contacted by security experts willing to open source an embedded C implementation and integrate it to wakaama. Given these people reputation and current employer, I am confident in the code quality and the long-term support.

I will come back soon with an ETA.

 

New Transports

- TCP/TLS

- LoRaWAN

- CIoT

 

TCP is low-hanging fruit. I already have it implemented.

 

LoRaWAN and CIoT are up for grabs.

 

Composite Operations

• Allow the LwM2M Server to address resources across several Objects. For instance, the LwM2M Server can read both the battery level (/3/0/9), the radio signal strength (/4/0/2), and the temperature (/3303/0/5700) in a single operation.

 

This features requires SenML JSON or CBOR.

With the new interface to Objects, this should be pretty straight-forward for the Client-side.

 

On the Server-side, we need to design new APIs (or update the current APIs).

 

Send Operation

• Allows the LwM2M Client to push data to the LwM2M Server without prior observation request from the LwM2M Server.

 

This also requires new APIs to be designed, one on the Client-side to send data, one on the Server-side to handle the data push.

 

Observation Attributes

• New observation attributes determining the frequency of measurement of the observed data.

 

On the Client-side, the new attributes need to be forwarded to the application. This will probably be done through an application callback.

 

Registration Retry Rules

• In LwM2M 1.0, a LwM2M Client tries to register only once to a LwM2M Server. In LwM2M 1.1, new resources attached to the LwM2M Server define the number of attempts for the LwM2M Client to register to a LwM2M Server and the delay between attempts.

 

Registration Priority

• When several LwM2M Servers are provisioned in the LwM2M Client, a priority can be assigned to each one. The LwM2M Client will try to register first to the highest-priority Servers before registering to the lowest -priority ones. Additionnaly, some Servers may be tagged as "blocking": if the registration to a tagged Server fails, the whole registration process is stopped and treated as failed.

 

BOOTSTRAP-READ

• Allows the Bootstrap Server to read the content of the LwM2M Server Object (/1) or the Access Control Object (/2).

 

Scott volunteered for this one.

 

 

Regards,

David Navarro