Communication Sequences

🔤 Acronyms? See the Glossary

👤 System Integrator, Embedded Application Developer

info

Acklio FullSDK is platform agnostic. Therefore, tools and paradigms are up to the user.

One major structuring requirement for Acklio FullSDK is the ability to support low-power modes. Consequently, its implementation allows it to be fully integrated in an event-driven environment.

The application layer and Acklio FullSDK work together by exchanging callbacks and function calls when and only when an event concerning the SDK occurs (e.g., data reception, timeout, etc.).

The application layer decides when to let the SDK process the event, by calling a dedicated function. Once an event has been processed (function returned), Acklio FullSDK does nothing more.

The sequences between the application layer and Acklio FullSDK are the following:

1. Initialize and configure the interface.
2. Provision the SCHC Template and the associated parameters.
3. Send packet with fragmentation.
4. Receive packet without fragmentation.
5. Initialize the L2 layer.

Interface Initialization and Configuration

The diagram below illustrates the successive function calls that must be performed by the application layer to initialize and configure the interface that will be used (e.g., the Datagram or the Network interface), and the resulting callbacks from Acklio FullSDK on related events.

See Acklio FullSDK Reference Manual for detailed information.

1. The application initializes the management layer and its relating interface. As soon as the management layer is initialized, the callback signalling that Acklio FullSDK needs some processing can be called. The application layer replies by calling the management layer function that will perform the processing.

Step 2 presents a dialog for the use case of step 1. More may occur with other use cases.

2. The callback that requests for processing is called in an interruption context. The processing function should not be called from this callback because it may take some time to execute. Consequently, the application layer has to decouple the call to the processing function from the activation of the callback.

3. The SDK signals that the LPWAN connectivity is available: for a LoRaWAN network, this means that the join has been performed successfully. The application layer has to wait for connectivity before interacting with an interface.

4. The interface is configured.

Template Provisioning and Synchronization

The CBOR SCHC Template can be downloaded from the SCHC Template view page on Acklio IPCore by clicking the CBOR Package button.

The SCHC Template parameters correspond to the values defined in the Template parameters section of the Device Profile Details page.

Scenario 1 – Device SCHC Configuration on Bootstrap

The diagram below illustrates the successive function calls that must be performed by the application layer to provision the SCHC Template in Acklio FullSDK and configure the SCHC Template parameters using the bootstrap mechanism.

See Acklio FullSDK Reference Manual for detailed information.

1. The application layer provisions the SCHC Template in a CBOR Format in Acklio FullSDK.

2. The application layer requests Acklio FullSDK to fetch the missing parameters in the SCHC Templates from Acklio IPCore.
   Also, Acklio FullSDK signals that the execution environment must start a timer. A callback parameter provides the identifier and duration of the timer.

3. When receiving the SCHC Template parameters, the callback that requests for processing is called in an interruption context.
   The processing function should not be called from this callback because it may take some time to execute. Consequently, the application layer has to decouple the call to the processing function from the activation of the callback.

4. Acklio FullSDK signals that the execution environment must stop the timer. A callback parameter provides the timer identifier.
   Then, the Acklio FullSDK signals that the bootstrap action ended, which means that Acklio FullSDK is fully configured: the application layer can now transmit packets using the Datagram or Network layer.

Scenario 2 – IPCore SCHC Configuration

The diagram below illustrates the successive function calls that must be performed by the application layer to:

• Provision the SCHC Template and its associated parameters in Acklio FullSDK,
• Configure the template parameters in Acklio IPCore using the synchronization mechanism.

See Acklio FullSDK Reference Manual for detailed information.

1. The application layer provisions the SCHC Template in a CBOR Format in Acklio FullSDK.

2. The application layer provisions all the SCHC Template parameters in Acklio FullSDK.

3. The application layer can now send a packet using the Datagram or Network layer.
   When receiving the packet, Acklio IPCore requests the missing parameters to Acklio FullSDK using the synchronization. This operation is transparent from the application layer on Acklio FullSDK side.

DTLS Handshake

This Handshake sequence occurs only if the source is a native-DTLS one or if DTLS has been enabled.

The diagram below illustrates the hanshake sequence initiated by the application and the interaction between the DTLS layer and the L2A layer in Acklio FullSDK.

Once the application has initialized the DTLS layer parameters, then Acklio FullSDK:

1. The application layer initiates the DTLS hanshake by calling a dtls_handshake function.
2. The handshake is processed between the C/D layer and the F/R layer in a transparent way to the user since it works underneath the NET and DTG APIs.
3. The DTLS layer returns the status of the handshake.

Packet Transmission with Fragmentation

The diagram below illustrates the communication sequences when transmitting a packet that involves SCHC fragmentation.

1. The application layer requests for the transmission of a packet.
2. Acklio FullSDK signals that some processing is needed. The application layer replies by calling the associated processing function. This dialog will happen several times.
3. Fragmentation requires timers. At step 3, Acklio FullSDK signals that the execution environment must start a timer with id=1. The duration of the timer is provided by a parameter of the callback.

The timer must have been created by the application layer beforehand and associated with the SDK function to call when timer id=1 timeout occurs.

4. The timeout occurs and calls the associated SDK function. The timeout function may be called in an interruption context. Later on, timer id=1 must be started again.

5. The SDK requires to stop timer id=1.

6. The result of the transmission is returned. In this use case, a positive result means that the fragmentation process went well and the packet was successfully transmitted.

The timer functions are called because of the fragmentation.

Packet Reception Without Fragmentation

The diagram below illustrates the communication sequence when receiving a packet, without SCHC fragmentation.

1. Request for processing, as usual. Again, even if it is presented only once on the diagram, this dialog may happen several times.
2. The application layer receives the packet. The callback should save the data received in a safe place and then, return as soon as possible.

L2A Layer Initialization

The sequence diagram below illustrates the initialization of the L2A layer.

1. Acklio FullSDK calls the initialization function.
2. The L2A layer requests the Acklio FullSDK for processing. The FullSDK replies by calling the associated processing function. This dialog may happen several times.
3. The L2A layer signals that the connectivity is available: for a LoRaWAN layer, this means that the join request was successful. Acklio FullSDK will not try to use L2A layer for transmission or reception as long as the callback that informs of the availability of the connectivity is not called.

L2A Transmission

The sequence diagram below illustrates how a transmission request is processed.

1. Acklio FullSDK requests for the MTU (Maximum Transmission Unit) that will be used for the next transmission. This allows Acklio FullSDK to support Layers 2 with variable MTU, such as LoRaWAN.
2. Acklio FullSDK sends the packet to layer two for transmission. Soon afterward, layer two will start transmitting the packet.
3. L2A layer performs the usual request for processing, when required. This dialog may happen several times.
4. Layer 2 is back to idle state, ready to transmit again, unless there are some duty cycle restrictions. L2A must signal this event to Acklio FullSDK by calling the transmission result callback.
5. Acklio FullSDK requests for the time it has to wait before requesting a new transmission. This request allows Acklio FullSDK to support layers 2 with duty cycle restrictions.