Protocol Design

Libertas OS is designed to be protocol agnostic. It can be used with several communication protocols. The underlying communication protocol can be either wireless or wired.

Communication Protocols

There are many existing IoT communication protocols. They are all quite different. Some protocols even cover more layers than others. For example, Zigbee defined the APS, ZDO, and ZCL layers above NWK (network layer); ZCL is equivalent to the application layer. Thread protocol doesn’t define the application layer at all.

Application Message Delivery

Libertas OS aims to design a framework that manages the delivery of application messages. IoT devices are remotely connected wirelessly or wired. Communication may fail. Out-of-order messages or duplicated messages may happen. Libertas OS shall manage the delivery, delivery retry, and failure notification through defined APIs.

It requires a higher level abstraction to make the message delivery and management APIs protocol agnostic. We need to construct a state machine that fits all communication protocols.

Transactions

In the application layer, an indivisible operation is called a transaction. Some transactions may involve exchanging application messages back and forth multiple times. It is usually the job of the application code to handle related transactions.

The simplest transaction is a round trip of message exchange, a request, and a response. Most application-level messages are designed in that way.

Some management features, such as binding management or remote Thing-App deployment, are fairly complicated transactions. Those transactions are usually managed on the central controller side (such as Libertas Hub), and the device side code is part of the Libertas OS code so that developers don’t need to do anything.

Data Model and Application Message Design

The sole purpose of communication protocol is to exchange data among devices. We also discussed the “commands and attributes” data model. There are some basic guidelines for designing application messages.

Application transaction shall transmit “states” instead of “history.”

IoT’s bandwidth, storage, and processing power can be very limited. Also, the communication is not guaranteed.

For example, the state of an on/off device changed from “off” to “on.” The device sends the “on” command to a bound device. It takes 500ms for the peer to respond to the command with an acknowledgment. During that 500ms, the device’s state changed five times and finally stayed “off.” Once the command is acknowledged, the device shall not send the history of 10 alternating “on” and “off” commands. Instead, it should only send one command with the final state, “off.”

IoT applications shall also only care about the “latest state.”

In the above example, what if there is a requirement to handle “double click of on button”? Instead of relying on the device to send the “on” command twice, the application shall detect a “double click” on the local device and send out a different command that represents “double click.”

If one application needs to communicate the history

The application shall be carefully designed to cache the data history somewhere in the device. An estimate of bandwidth and storage utilization shall be evaluated first to make sure that it is even possible to do so.

Libertas OS Attribute Cache

The Thing-App engine may maintain an attribute cache for each connected remote device. Attribute-related API calls may interact with the attribute cache instead of generating attribute commands immediately.

For example, An application code may make two calls to report two attributes. The Libertas OS may aggregate the data and only send one report with two attributes.

Another example is that the device may receive two “attribute report” messages, each reporting one different attribute. Libertas OS may generate one aggregated “attribute report” event to the Thing-App.

The reasons are below:

1. The bandwidth, CPU, and memory resources are limited. As we mentioned above, only the “last state” of an attribute is meaningful
2. The Thing-App is running in a low-priority thread different from the main thread that drives communication. The data transactions must be cached and handled asynchronously
3. There may be multiple Thing-App running on a device. Multiple running Thing-Apps may access the same remote device. Device access to one device must be notified to another device as a state change, and “concurrent” accesses to a device shall be aggregated