Configure the SCHC Template

What is a SCHC Template?

A SCHC template contains the predefined translation rules to apply to devices. It is the generic description of a device: purpose or type, supported stack, how data will be processed (fragmentation, compression, YOUPI, among others).

Click SCHC Templates to display the list of available templates.

• Name: The name of the SCHC template as defined by the user.
• SCHC Template ID: The ID specified at creation time.
• Nb Device Profiles: The number of device profiles included in the template.
• Nb Rules: The number of rules defined in the template. This includes both fragmentation and compression rules.
• Organization: The name of the organization, if specified when creating the template.
• Created by: The user's slug generated when creating the template.
• Last update: The time passed since the last update.

Create a SCHC Template Manually

Roles

Only users with "Administrator" or "Multi-organization operator" are allowed to create SCHC Templates. Operators can only view templates
See Platform Management & Multi-Organization.

The process of creating a template is long and divided into several step-pages. First click the Create button, then:

1. Specify the Details tab. Additional fields appear depending on your choices.
2. Specify the Rules.

Details Tab

• Name : Specify a name.
• SCHC Template ID: Specify an ID.
• Description: This field is not mandatory.
• Enable TCP: Check the box to enable TCP over LPWAN then, specify the TCP port you want to listen. The transaction is supported by our technology named SCM.
• LoRaWAN (Payload with Rule ID): Select this option if your device send the Rule ID along with the payload but not in FPort as specified in the SCHC-LoRaWAN draft.
• Legacy: Select this option if your device just sends raw data. The template can have only one compression rule, and of course no fragmentation rule.

Rules Tab

Then, click the "Rules" tab to create a first rule.

The rule will define how packets will be fragmented/compressed on the device and then reassemblied and decompressed on the application.

• Non-matching Rule ID: Specify an ID to use when the packet cannot be compressed.

Click Add to expand the Rules area.

• Rule ID: This number is generated automatically and incremented each time you create a rule.
• Rule Type: Click the drop-down list to select either "Fragmentation" or "Compression". The content of the next fields (and their number) depends on this choice.

Rule Type: Fragmentation

Selecting Fragmentation in the Rule Type drop-down lists displays additional fields to define specific information such as the direction and the mode.

Standard

SCHC-LoRaWAN RFC recommends to use the ACK-on-Error mode for uplink and Ack-Always mode for downlink.

• Direction: Select the direction – uplink or downlink – to which the mode will apply.
• Rule ID size: The size is specified by default but you can modify the value.
• DTag field size: The size is specified by default but you can modify the value.
• Window size: Specify the maximum number of windows for the Ack-On-Error and Ack-Always mode.
• MIC algorithm type: Specify the type of algorithm used for MIC (e.g., CRC32_IEEE).
• Inactivity timer: Enter the maximum period of inactivity.
• Fragmentation modes: Click to select one of the three possible modes – No-Ack, Ack-Always, and Ack-On-Error – in the drop-down list. The number of fileds below depends on the selected mode.

Fragmention Mode is "Ack-On-Error"

• W field size: Enter the size of a window for the Ack-On-Error and Ack-Always mode.
• Retransmission timer: Specify the minimum delay before retransmitting a fragmentation if an error occured, in milliseconds.
• All-1 retransmission timer: Specify the minimum delay before retransmitting all fragmentations if an error occured, in milliseconds.
• DTag Release timer: Specify the minimum delay before releasing a device Tag, in seconds.
• Max ACK: Specify the maxium acknoledgements for a device.
• Tile size: Enter the maxium size for a fragment.
• Disable All-1 payload: Select this option to disable the all-1 payload for AoEs.
• Send ACK every window: Select this option to send acknoledgements to every window for AoEs.

Fragmentation Mode is "Ack-Always"

• W field size: Enter the size of a window for the Ack-On-Error and Ack-Always mode.
• Retransmission timer: Specify the minimum delay before retransmitting a fragmentation if an error occured, in milliseconds.
• All-1 retransmission timer: Specify the minimum delay before retransmitting all fragmentations if an error occured, in milliseconds.
• DTag Release timer: Specify the minimum delay before releasing a device Tag, in seconds.
• Max ACK: Specify the maxium acknoledgements for a device.
• Short Session Retransmission Time: Select this option to enable short sessions.

Fragmentation Mode is "No-Ack"

No additional fields.

Rule Type: Compression

Standard

SCHC-Compression draft defines that the compression with SCHC is based on using a set of Rules, called the Context, to compress or decompress headers. The Contexts MUST be stored at both ends, and they can be learned by a provisioning protocol (...) or they can be pre-provisioned.

Selecting Compression in the Rule Type drop-down lists displays additional fields to define the stack.

Stack and compression example

If you choose IP6/UDP/CoAP to IP6/UDP/CoAP, the packet composed of 3 layers (IPv6|UDP|CoAP from bottom to top) will be compressed then sent to another endpoint.
When receiving the message, this endpoint will decompress and reconstruct it to a completed IPv6/UDP/CoAP packet.

Start by selecting one of the IPv4/xx or IPv6/xx stacks in the Stack drop-down list. This choice will impact the fields below this list.

The, specify the appropriate variables (template variables and dynamic variables) for the device and the application, knowing that:

• Dynamic variables such as a prefix or a IID are introduced by a $. They are handled dynamically in Acklio IPCore.
  For example, $GetDeviceIP6Prefix() avoids specifying an exact value in the context since it provides a function to dynamically get the IPv6 device while processing compression/decompression.

• Template variables are defined when creating a device profile, but can be edited if you rather use a constant/fix value.They must follow the syntax {{.variable-name}}.

info

You can create as many rules as needed except for legacy devices (i.e. sending raw data) since they do not support SCHC compression.

Click Submit when you have specified all the rules for the template.

View the Rules

The new rule is added to the list on the SCHC Templates page. Click a line in the list to display all the information on the SCHC template and have a detailed view on the rules.

The Rules tab lists all the parameters for each rule. In the illustration above:

• Clicking the fragmentation Rule #20 will display the definition for the uplink, while clicking Rule #21 will display the definition for the downlink.
• Clicking the compression Rule #28 will display two drop-down areas because of the two layers of the stack: one for the IPv6 specifications, the other for the UDP specifications. In the case of a 3-layer stack (e.g., IPv6/UDP/CoAP), there would be three areas.

Create a SCHC Template by Upload

An alternative to the manual creation is uploading JSON files.

You can define as many templates as you want in the JSON file as long as they respect the following format.

{
    "templates": [
        {template-1-content},
        {template-2-content}  
    ]
}

Click the JSON button to upload an example of a JSON SCHC template. Or click the CBOR Package button to upload an example of a CBOR package.

View Details

Click the template in the list of SCHC templates to display details on it and check your settings. If need be, you can edit or even delete it.

The detail page provides two types of information:

• General information: A summary of the SCHC template such as the name and the SCHC template ID.
• Settings: A summary of the settings in the form of a bullet list. A summary of the rules is available in the Rules tab.