Layers and Interfaces
🔤 Acronyms? See the Glossary
👤 System Integrator, Embedded Application Developer
The content of Acklio FullSDK can be described in its simplistic view as an adaptation layer with the SCHC mechanisms, and a set of interfaces.
Get in-depth information on SCHC standard RFC8724 by reading SCHC: Generic Framework for Static Context Header Compression and Fragmentation.
It integrates with the underlying technology and the application layer with the help of some development made by the System Integrator, as illustrated below.
To keep the diagram readable, the links between the different layers are not shown.
Layers​
From bottom to upper layer.
Layer | Description |
---|---|
Level 2, data link | Acklio FullSDK supports any LPWAN technology. A predefined interface is provided (see below) for an optimistic adaptation to the communication module/board that provides access to the LPWAN network. |
L2 Adaptation | The Level 2 adaptation layer is provided as a standardized interface with the multiplexing layer, regardless of the type of L2 layer. |
Multiplexing | This layer provides the multiplexing to handle uplink and downlink sessions in parallel, in order to comply with L2 layer. |
Fragmentation/Reassembly | This layer performs fragmentation then reassembly according to SCHC specifications. The fragmentation mode is preconfigured according to the L2 technology profile. |
Compression/Decompression | This layer performs compression then decompression according to SCHC specifications. Associated rules are preconfigured, in current version. |
Sync layer | The Synchronization layer is a private interface of Acklio FullSDK to synchronize SCHC template parameters between IPCore and the SDK. |
Application Interface | The Datagram API provides a datagram interface similar to Berkeley datagram socket. The Network and Extension APIs provide a raw network interface allowing to send raw IPv6 packets. |
Application | The application layer implements the embedded side of the business logic of the overall IoT system |
Acklio FullSDK is delivered as a position independent library, with C header files.
Device and Core Synchronization​
Sync layer on the diagram above.
Acklio FullSDK works with its compatible LPWAN network infrastructure: Acklio IPCore.
Together, Acklio FullSDK and Acklio IPCore implement compression/decompression and fragmentation/reassembly on both sides of the LPWAN.
These operations are performed in a fully transparent way for the device embedded applications and for the core applications thanks to the synchronization layer that allows to synchronize parameters between Acklio IPCore and Acklio FullSDK.
Interfaces​
The Acklio FullSDK library implements four interfaces: the management interface and the datagram, network and extension interfaces. The L2A interface must be implemented by the integrator since it depends on which layer 2 is used.
Management Interface​
The management interface is used to configure Acklio FullSDK at runtime, to provide some hardware resources (memory and timers) that have to be allocated by the execution environment, and to notify the application with some information about ongoing state.
Object | Management |
---|---|
Processing power | Whenever the SDK needs to perform processing, it signals it to the application layer that will call a dedicated function. |
Timers | Resolving a timer must be done in 1 ms. The execution environment must provide a callback that starts the time for n ms, and a callback that stops it. When the timeout is triggered, a dedicated function must be called. |
Volatile memory (RAM) | Acklio FullSDK is flexible in terms of memory management. The application must allocate, then provide memory to the SDK. The amount of memory required depends on both the MTU and the maximum payload the application expects to send and receive. |
Ongoing state | The connectivity state, i.e. whether layer 2 may send or receive data, is signaled to the application layer using a callback. The application layer should not request to send a packet before connectivity is reported as operational. |
All the callbacks are defined when initialiazing the layers.
Datagram and Network Interfaces​
Datagram and network interfaces have different purposes but a similar functioning.
The datagram interface is used to exchange data packets with a remote application, in a way similar to the steps required for a Berkeley datagram socket.
The network interface is used to send raw IPv6/UDP data packets to a remote application, and get data packets back from it.
The send
operation is non-blocking and asynchronous: it requests a transmission operation and returns immediately, while the result of the transmission (success or failure) is postponed and handled by a callback declared when initializing the interface.
Depending on packet size and LPWAN technology, a send
operation can be quite long. For example, if the size of the packet is greater than the LPWAN maximum transmission unit (MTU), it will be fragmented and sent in several fragments. Note that the duty cycle limitation may increase overall transmission time.
Level 2 Adaptation Interface​
The Level 2 adaptation layer depends on the underlying LPWAN technology, that's why it is usually provided by the integrator. However, to ensure the independence of Acklio FullSDK, it should comply with the L2 adaptation interface of Acklio's SDK, based on LoRaWAN technology.
Functions | Details |
---|---|
Callbacks | These functions must be called for precise events such as layer requiring processing, packet transmission (up or down), available connectivity (or not, in option). The callback signalling the end of a packet transmission must be called only when the communication module i.e. the board can switch again to transmission mode (regardless of duty cycle restrictions). |
L2 functions | Specific functions |
Warning | A function that will be called after the callback signals that the layer requires some processing. |
Device IID | A function that must provide the device IID. |
See the list of AT commands for each interface in the Demo Examples section.