Institut MINES TELECOM; IMT Atlantique

2 rue de la Chataigneraie CS 17607 35576 Cesson-Sevigne Cedex France ivan-marino.martinez-bolivar@imt-atlantique.fr

Institut MINES TELECOM; IMT Atlantique

2 rue de la Chataigneraie CS 17607 35576 Cesson-Sevigne Cedex France Laurent.Toutain@imt-atlantique.fr

lpwan Working Group This document specifies how openSCHC handles the rule selection and how this process can be extended to a meshed environment.

This document specifies how openSCHC handles the rule selection and how this process can be extended to a meshed environment.

OpenSCHC imports rule in JSON, such has:

A specific device may have several rules, identified in the SoR (Set of Rules) key. The device is identified by a DeviceID. OpenSCHC allows to send SCHC packet over an udp tunnel. In that case, the device ID starts with the udp keyword, followed by the IP address and the port number. In that architecture, the core SCHC may contains several devices’ rules, idenfified by different ID. The device side contains only the SoR associated to the device. When a packet arrive to the SCHC core, a machting rule is searched among all the rule. The core SCHC uses the device ID to effectively send the SCHC packet to the device. The device answers back to the core SCHC, ignoring the device ID since this value identifies the device itself. So, we can name core a SCHC instance containing rules that does not contains its own ID and a device a SCHC instance containing rules that contains only its own ID. Communication from device to core is upstream and downstream in the reverse direction.

This example is defined for a star toplogy, and devices can send back their response in case of UDP tunnel or use the media in case of LPWAN. In a meshed network, several instances may coexist and use the same ruleID for a device but the rule itself can be different. The previous rule can be updated to add a CoreID:

The process for the core compression is the same. When the device receives the SCHC packet, it identifies the coreID and select only rules coming from this instance. When the devices sends a packet, instead of replying on the same port.

A device receives a SCHC packet on a single idendified SoR, keeps track of the sender to reply. This could be either the technology or the address of the core. Only one core is allowed in that case.

A device receiving a SCHC packet on a double identifie SoR, does not have to keep track of the core address. When a packet needs to be compressed, the selected rule indicates where to send the SCHC packet. The device may have several SoR corresponding to each core.

This document defines the Static Context Header Compression and fragmentation (SCHC) framework, which provides both a header compression mechanism and an optional fragmentation mechanism. SCHC has been designed with Low-Power Wide Area Networks (LPWANs) in mind.SCHC compression is based on a common static context stored both in the LPWAN device and in the network infrastructure side. This document defines a generic header compression mechanism and its application to compress IPv6/UDP headers.This document also specifies an optional fragmentation and reassembly mechanism. It can be used to support the IPv6 MTU requirement over the LPWAN technologies. Fragmentation is needed for IPv6 datagrams that, after SCHC compression or when such compression was not possible, still exceed the Layer 2 maximum payload size.The SCHC header compression and fragmentation mechanisms are independent of the specific LPWAN technology over which they are used. This document defines generic functionalities and offers flexibility with regard to parameter settings and mechanism choices. This document standardizes the exchange over the LPWAN between two SCHC entities. Settings and choices specific to a technology or a product are expected to be grouped into profiles, which are specified in other documents. Data models for the context and profiles are out of scope. This document defines how to compress Constrained Application Protocol (CoAP) headers using the Static Context Header Compression and fragmentation (SCHC) framework. SCHC defines a header compression mechanism adapted for Constrained Devices. SCHC uses a static description of the header to reduce the header's redundancy and size. While RFC 8724 describes the SCHC compression and fragmentation framework, and its application for IPv6/UDP headers, this document applies SCHC to CoAP headers. The CoAP header structure differs from IPv6 and UDP, since CoAP uses a flexible header with a variable number of options, themselves of variable length. The CoAP message format is asymmetric: the request messages have a header format different from the format in the response messages. This specification gives guidance on applying SCHC to flexible headers and how to leverage the asymmetry for more efficient compression Rules.