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 for detailed information on roles.

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 tab.

Details Tab

• Name : Specify a name.
• SCHC Template ID: Specify an ID (must be unique).
• 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.
• Quality of Service: If the direction is "uplink" a QoS field appears. It is optional. Select what to measure and report between four possible values:
  • Undefined: QoS is not enabled. This is the default value.
  • No reliability: The uplink packets are never acknowledged.
  • Network Reliability: The uplink packets are only acknowledged in the case of packet loss detection.
  • Systematic Report: ll the uplink packets are acknowledged.
• Fragmentation modes: Click to select one of the four possible modes – No-Ack, Ack-Always Ack-On-Error and Optimized Ack – in the drop-down list. The number of fields below depends on the selected mode.
  See below for detailed information on the fragmentation modes.

Fragmentation Mode is "Ack-On-Error"

• W field size: Enter the size of a window for the (Optimized) 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 acknowledgements 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 acknowledgements to every window for AoEs.

Fragmentation Mode is "Optimized Ack"

• W field size: Enter the size of a window for the (Optimized) 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 maximum acknowledgements for a device.
• Short Session Retransmission Time: Select this option to enable short sessions.
• Tile size: Enter the maxium size for a fragment.
• Enable Implicit ACK: Select this option to enable Implicit ACK fragmentation mode to save downlink data.
• Send ACK every window: Select this option to send acknowledgements to every window for OAoEs.

Fragmentation Mode is "Ack-Always"

• W field size: Enter the size of a window for the (Optimized) 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 acknowledgements 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.

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.

Get the SCHC Template

The SCHC Template to deploy on the device can be downloaded either as a JSON file or as CBOR package from the SCHC Template details page.

JSON Template

The JSON template is the complete description of what has been specified through the Web interface.
See the Configure the SCHC Template (Advanced) page for detailed information.

CBOR Package

The CBOR (Concise Binary Object Representation) Package contains binary and ASCII files:

• Binary files to upload in the UDP Client Demo example (template.bin).
• ASCII files which content must be copied and pasted in the AT Memory command to set a compression template in the volatile memory.

The ZIP file contains:

	SCHC Compression Rules	SCHC Fragmentation Rules
Binary	compression_rules.bin	rule_fragmentation_<direction>_<rule_id>.bin
Ascii	compression_rules_debug.txt compression_rules_usage.txt	rule_fragmentation_<direction>_<rule_id>.txt

Payload Compression

Payload compression is only configurable in a JSON SCHC template. See Payload Compression Rules in the Configure the SCHC Template (Advanced) page.

Thus, CBOR payload compression rules are present in the ZIP file only if they are present in the JSON file.

Quality of Service

QoS files (quality_of_service) are presents when:

• The direction of the fragmentation rule is uplink
• The Quality of Service parameter is different than Undefined