diff options
Diffstat (limited to 'doc/rfc/rfc9011.txt')
| -rw-r--r-- | doc/rfc/rfc9011.txt | 1330 |
1 files changed, 1330 insertions, 0 deletions
diff --git a/doc/rfc/rfc9011.txt b/doc/rfc/rfc9011.txt new file mode 100644 index 0000000..38f0dfa --- /dev/null +++ b/doc/rfc/rfc9011.txt @@ -0,0 +1,1330 @@ + + + + +Internet Engineering Task Force (IETF) O. Gimenez, Ed. +Request for Comments: 9011 Semtech +Category: Standards Track I. Petrov, Ed. +ISSN: 2070-1721 Acklio + April 2021 + + +Static Context Header Compression and Fragmentation (SCHC) over LoRaWAN + +Abstract + + The Static Context Header Compression and fragmentation (SCHC) + specification (RFC 8724) describes generic header compression and + fragmentation techniques for Low-Power Wide Area Network (LPWAN) + technologies. SCHC is a generic mechanism designed for great + flexibility so that it can be adapted for any of the LPWAN + technologies. + + This document defines a profile of SCHC (RFC 8724) for use in LoRaWAN + networks and provides elements such as efficient parameterization and + modes of operation. + +Status of This Memo + + This is an Internet Standards Track document. + + This document is a product of the Internet Engineering Task Force + (IETF). It represents the consensus of the IETF community. It has + received public review and has been approved for publication by the + Internet Engineering Steering Group (IESG). Further information on + Internet Standards is available in Section 2 of RFC 7841. + + Information about the current status of this document, any errata, + and how to provide feedback on it may be obtained at + https://www.rfc-editor.org/info/rfc9011. + +Copyright Notice + + Copyright (c) 2021 IETF Trust and the persons identified as the + document authors. All rights reserved. + + This document is subject to BCP 78 and the IETF Trust's Legal + Provisions Relating to IETF Documents + (https://trustee.ietf.org/license-info) in effect on the date of + publication of this document. Please review these documents + carefully, as they describe your rights and restrictions with respect + to this document. Code Components extracted from this document must + include Simplified BSD License text as described in Section 4.e of + the Trust Legal Provisions and are provided without warranty as + described in the Simplified BSD License. + +Table of Contents + + 1. Introduction + 2. Terminology + 3. SCHC Overview + 4. LoRaWAN Architecture + 4.1. Device Classes (A, B, C) and Interactions + 4.2. Device Addressing + 4.3. General Frame Types + 4.4. LoRaWAN MAC Frames + 4.5. LoRaWAN FPort + 4.6. LoRaWAN Empty Frame + 4.7. Unicast and Multicast Technology + 5. SCHC over LoRaWAN + 5.1. LoRaWAN FPort and RuleID + 5.2. RuleID Management + 5.3. Interface IDentifier (IID) Computation + 5.4. Padding + 5.5. Decompression + 5.6. Fragmentation + 5.6.1. DTag + 5.6.2. Uplink Fragmentation: From Device to SCHC Gateway + 5.6.3. Downlink Fragmentation: From SCHC Gateway to Device + 5.7. SCHC Fragment Format + 5.7.1. All-0 SCHC Fragment + 5.7.2. All-1 SCHC Fragment + 5.7.3. Delay after Each LoRaWAN Frame to Respect Local + Regulation + 6. Security Considerations + 7. IANA Considerations + 8. References + 8.1. Normative References + 8.2. Informative References + Appendix A. Examples + A.1. Uplink - Compression Example - No Fragmentation + A.2. Uplink - Compression and Fragmentation Example + A.3. Downlink + Acknowledgements + Contributors + Authors' Addresses + +1. Introduction + + The SCHC specification [RFC8724] describes generic header compression + and fragmentation techniques that can be used on all Low-Power Wide + Area Network (LPWAN) technologies defined in [RFC8376]. Even though + those technologies share a great number of common features like star- + oriented topologies, network architecture, devices with + communications that are mostly quite predictable, etc., they do have + some slight differences with respect to payload sizes, reactiveness, + etc. + + SCHC provides a generic framework that enables those devices to + communicate on IP networks. However, for efficient performance, some + parameters and modes of operation need to be set appropriately for + each of the LPWAN technologies. + + This document describes the parameters and modes of operation when + SCHC is used over LoRaWAN networks. The LoRaWAN protocol is + specified by the LoRa Alliance in [LORAWAN-SPEC]. + +2. Terminology + + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and + "OPTIONAL" in this document are to be interpreted as described in + BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all + capitals, as shown here. + + This section defines the terminology and abbreviations used in this + document. For all other definitions, please look up the SCHC + specification [RFC8724]. + + | Note: The SCHC acronym is pronounced like "sheek" in English + | (or "chic" in French). Therefore, this document writes "a SCHC + | Packet" instead of "an SCHC Packet". + + AppKey: Application Key. An AES-128 root key specific to each + device. + + AppSKey: Application Session Key. An AES-128 key derived from the + AppKey for each new session. It is used to encrypt the payload + field of a LoRaWAN applicative frame. + + DevAddr: A 32-bit non-unique identifier assigned to a device either: + + Statically: by the device manufacturer in "Activation-by- + Personalization" mode, or + + Dynamically: after a LoRaWAN "Join Procedure" by the Network + Gateway in "Over-the-Air-Activation" mode. + + DevEUI: Device Extended Unique Identifier, an IEEE EUI-64 identifier + used to identify the device during the procedure while joining the + network (Join Procedure). It is assigned by the manufacturer or + the device owner and provisioned on the Network Gateway. + + Downlink: A LoRaWAN term for a frame transmitted by the network and + received by the device. + + EUI: Extended Unique Identifier + + FRMPayload: Application data in a LoRaWAN frame + + IID: Interface Identifier + + LoRaWAN: LoRaWAN is a wireless technology based on Industrial, + Scientific, and Medical (ISM) radio bands that is used for long- + range, low-power, low-data-rate applications developed by the LoRa + Alliance, a membership consortium: <https://www.lora- + alliance.org>. + + MSB: Most Significant Byte + + NGW: Network Gateway + + OUI: Organizationally Unique Identifier. IEEE-assigned prefix for + EUI. + + RCS: Reassembly Check Sequence. Used to verify the integrity of the + fragmentation-reassembly process. + + RGW: Radio Gateway + + RX: A device's reception window. + + RX1/RX2: LoRaWAN class A devices open two RX windows following an + uplink, called "RX1" and "RX2". + + SCHC C/D: SCHC Compression/Decompression + + SCHC F/R: SCHC Fragmentation/Reassembly + + SCHC gateway: The LoRaWAN Application Server that manages + translation between an IPv6 network and the Network Gateway + (LoRaWAN Network Server). + + Tile: A piece of a fragmented packet as described in Section 8.2.2.1 + of [RFC8724]. + + Uplink: LoRaWAN term for a frame transmitted by the device and + received by the network. + +3. SCHC Overview + + This section contains a short overview of SCHC. For a detailed + description, refer to the full specification [RFC8724]. + + It defines: + + 1. Compression mechanisms to avoid transporting information known by + both sender and receiver over the air. Known information is part + of the "context". This component is called the "SCHC + Compression/Decompression" (SCHC C/D). + + 2. Fragmentation mechanisms to allow SCHC Packet transportation on a + small, and potentially variable, MTU. This component is called + the "SCHC Fragmentation/Reassembly" (SCHC F/R). + + Context exchange or pre-provisioning is out of scope of this + document. + + Device App + +----------------+ +----+ +----+ +----+ + | App1 App2 App3 | |App1| |App2| |App3| + | | | | | | | | + | UDP | |UDP | |UDP | |UDP | + | IPv6 | |IPv6| |IPv6| |IPv6| + | | | | | | | | + |SCHC C/D and F/R| | | | | | | + +--------+-------+ +----+ +----+ +----+ + | +---+ +----+ +----+ +----+ . . . + +~ |RGW| === |NGW | == |SCHC| == |SCHC|...... Internet .... + +---+ +----+ |F/R | |C/D | + +----+ +----+ + |<- - - - LoRaWAN - - ->| + + Figure 1: Architecture + + Figure 1 represents the architecture for compression/decompression; + it is based on the terminology from [RFC8376]. The device is sending + application flows using IPv6 or IPv6/UDP protocols. These flows + might be compressed by a SCHC C/D to reduce header size, and + fragmented by the SCHC F/R. The resulting information is sent on a + Layer 2 (L2) frame to an LPWAN Radio Gateway (RGW) that forwards the + frame to a Network Gateway (NGW). The NGW sends the data to a SCHC + F/R for reassembly, if required, then to a SCHC C/D for + decompression. The SCHC C/D shares the same rules with the device. + The SCHC C/D and SCHC F/R can be located on the NGW or in another + place as long as a communication is established between the NGW and + the SCHC F/R, then SCHC F/R and SCHC C/D. The SCHC C/D and SCHC F/R + in the device and the SCHC gateway MUST share the same set of rules. + After decompression, the packet can be sent on the Internet to one or + several LPWAN Application Servers (App). + + The SCHC C/D and SCHC F/R process is bidirectional, so the same + principles can be applied to the other direction. + + In a LoRaWAN network, the RGW is called a "Gateway", the NGW is a + "Network Server", and the SCHC C/D and SCHC F/R are one or more + "Application Servers". Application servers can be provided by the + NGW or any third-party software. Figure 1 can be mapped in LoRaWAN + terminology to: + + End Device App + +--------------+ +----+ +----+ +----+ + |App1 App2 App3| |App1| |App2| |App3| + | | | | | | | | + | UDP | |UDP | |UDP | |UDP | + | IPv6 | |IPv6| |IPv6| |IPv6| + | | | | | | | | + |SCHC C/D & F/R| | | | | | | + +-------+------+ +----+ +----+ +----+ + | +-------+ +-------+ +-----------+ . . . + +~ |Gateway| == |Network| == |Application|..... Internet .... + +-------+ |server | |server | + +-------+ | F/R - C/D | + +-----------+ + |<- - - - - LoRaWAN - - - ->| + + Figure 2: SCHC Architecture Mapped to LoRaWAN + +4. LoRaWAN Architecture + + An overview of the LoRaWAN protocol and architecture [LORAWAN-SPEC] + is described in [RFC8376]. The mapping between the LPWAN + architecture entities as described in [RFC8724] and the ones in + [LORAWAN-SPEC] is as follows: + + * Devices are LoRaWAN End Devices (e.g., sensors, actuators, etc.). + There can be a very high density of devices per radio gateway + (LoRaWAN gateway). This entity maps to the LoRaWAN end device. + + * The RGW is the endpoint of the constrained link. This entity maps + to the LoRaWAN Gateway. + + * The NGW is the interconnection node between the Radio Gateway and + the SCHC gateway (LoRaWAN Application Server). This entity maps + to the LoRaWAN Network Server. + + * The SCHC C/D and SCHC F/R are handled by the LoRaWAN Application + Server. + + * The LPWAN-AAA Server is the LoRaWAN Join Server. Its role is to + manage and deliver security keys in a secure way so that the + devices root key is never exposed. + + (LPWAN-AAA Server) + () () () | +------+ + () () () () / \ +---------+ | Join | + () () () () () / \======| ^ |===|Server| +-----------+ + () () () | | <--|--> | +------+ |Application| + () () () () / \==========| v |=============| Server | + () () () / \ +---------+ +-----------+ + End devices Gateways Network Server (SCHC C/D and F/R) + (devices) (RGW) (NGW) + + Figure 3: LPWAN Architecture + + | Note: Figure 3 terms are from LoRaWAN, with [RFC8376] + | terminology in brackets. + + The SCHC C/D and SCHC F/R are performed on the LoRaWAN end device and + the Application Server (called the SCHC gateway). While the point- + to-point link between the device and the Application Server + constitutes a single IP hop, the ultimate endpoint of the IP + communication may be an Internet node beyond the Application Server. + In other words, the LoRaWAN Application Server (SCHC gateway) acts as + the first-hop IP router for the device. The Application Server and + Network Server may be co-located, which effectively turns the + Network/Application Server into the first-hop IP router. + +4.1. Device Classes (A, B, C) and Interactions + + The LoRaWAN Medium Access Control (MAC) layer supports three classes + of devices named A, B, and C. All devices implement Class A, and + some devices may implement Class B or Class C. Class B and Class C + are mutually exclusive. + + Class A: Class A is the simplest class of devices. The device is + allowed to transmit at any time, randomly selecting a + communication channel. The Network Gateway may reply with a + downlink in one of the two receive windows immediately following + the uplinks. Therefore, the Network Gateway cannot initiate a + downlink; it has to wait for the next uplink from the device to + get a downlink opportunity. Class A is the lowest power + consumption class. + + Class B: Class B devices implement all the functionalities of Class + A devices but also schedule periodic listen windows. Therefore, + as opposed to Class A devices, Class B devices can receive + downlinks that are initiated by the Network Gateway and not + following an uplink. There is a trade-off between the periodicity + of those scheduled Class B listen windows and the power + consumption of the device: + + High periodicity: Downlinks from the NGW will be sent faster but + the device wakes up more often and power consumption is + increased. + + Low periodicity: Downlinks from the NGW will have higher latency + but lower power consumption. + + Class C: Class C devices implement all the functionalities of Class + A devices but keep their receiver open whenever they are not + transmitting. Class C devices can receive downlinks at any time + at the expense of a higher power consumption. Battery-powered + devices can only operate in Class C for a limited amount of time + (for example, for a firmware upgrade over-the-air). Most of the + Class C devices are grid powered (for example, Smart Plugs). + +4.2. Device Addressing + + LoRaWAN end devices use a 32-bit network address (DevAddr) to + communicate with the Network Gateway over the air; this address might + not be unique in a LoRaWAN network. Devices using the same DevAddr + are distinguished by the Network Gateway based on the cryptographic + signature appended to every LoRaWAN frame. + + To communicate with the SCHC gateway, the Network Gateway MUST + identify the devices by a unique 64-bit device identifier called the + "DevEUI". + + The DevEUI is assigned to the device during the manufacturing process + by the device's manufacturer. It is built like an Ethernet MAC + address by concatenating the manufacturer's IEEE OUI field with a + vendor unique number. For example, a 24-bit OUI is concatenated with + a 40-bit serial number. The Network Gateway translates the DevAddr + into a DevEUI in the uplink direction and reciprocally on the + downlink direction. + + +--------+ +---------+ +---------+ +----------+ + | Device | <=====> | Network | <====> | SCHC | <======> | Internet | + | | DevAddr | Gateway | DevEUI | Gateway | IPv6/UDP | | + +--------+ +---------+ +---------+ +----------+ + + Figure 4: LoRaWAN Addresses + +4.3. General Frame Types + + LoRaWAN implements the possibility to send confirmed or unconfirmed + frames: + + Confirmed frame: The sender asks the receiver to acknowledge the + frame. + + Unconfirmed frame: The sender does not ask the receiver to + acknowledge the frame. + + As SCHC defines its own acknowledgment mechanisms, SCHC does not + require the use of LoRaWAN Confirmed frames (FType = 0b100 as per + [LORAWAN-SPEC]). + +4.4. LoRaWAN MAC Frames + + In addition to regular data frames, LoRaWAN implements JoinRequest + and JoinAccept frame types, which are used by a device to join a + network: + + JoinRequest: This frame is used by a device to join a network. It + contains the device's unique identifier DevEUI and a random nonce + that will be used for session key derivation. + + JoinAccept: To onboard a device, the Network Gateway responds to the + JoinRequest issued by a device with a JoinAccept frame. That + frame is encrypted with the device's AppKey and contains (among + other fields) the network's major settings and a random nonce used + to derive the session keys. + + Data: This refers to MAC and application data. Application data is + protected with AES-128 encryption. MAC-related data is AES-128 + encrypted with another key. + +4.5. LoRaWAN FPort + + The LoRaWAN MAC layer features a frame port field in all frames. + This field (FPort) is 8 bits long and the values from 1 to 223 can be + used. It allows LoRaWAN networks and applications to identify data. + +4.6. LoRaWAN Empty Frame + + A LoRaWAN empty frame is a LoRaWAN frame without FPort (cf. + Section 5.1) and FRMPayload. + +4.7. Unicast and Multicast Technology + + LoRaWAN technology supports unicast downlinks but also multicast; a + multicast packet sent over a LoRaWAN radio link can be received by + several devices. It is useful to address many devices with the same + content: either a large binary file (firmware upgrade) or the same + command (e.g., lighting control). As IPv6 is also a multicast + technology, this feature can be used to address a group of devices. + + | Note 1: IPv6 multicast addresses must be defined as per + | [RFC4291]. The LoRaWAN multicast group definition in a Network + | Gateway and the relation between those groups and IPv6 groupID + | are out of scope of this document. + + | Note 2: The LoRa Alliance defined + | [LORAWAN-REMOTE-MULTICAST-SET] as the RECOMMENDED way to set up + | multicast groups on devices and create a synchronized reception + | window. + +5. SCHC over LoRaWAN + +5.1. LoRaWAN FPort and RuleID + + The FPort field is part of the SCHC Message, as shown in Figure 5. + The SCHC C/D and the SCHC F/R SHALL concatenate the FPort field with + the LoRaWAN payload to recompose the SCHC Message. + + | FPort | LoRaWAN payload | + + ------------------------ + + | SCHC Message | + + Figure 5: SCHC Message in LoRaWAN + + | Note: The SCHC Message is any datagram sent by the SCHC C/D or + | F/R layers. + + A fragmented datagram with application payload transferred from + device to Network Gateway is called an "uplink-fragmented datagram". + It uses an FPort for data uplink and its associated SCHC control + downlinks, named "FPortUp" in this document. The other way, a + fragmented datagram with application payload transferred from Network + Gateway to device is called a "downlink-fragmented datagram". It + uses another FPort for data downlink and its associated SCHC control + uplinks, named "FPortDown" in this document. + + All RuleIDs can use arbitrary values inside the FPort range allowed + by the LoRaWAN specification [LORAWAN-SPEC] and MUST be shared by the + device and SCHC gateway prior to the communication with the selected + rule. The uplink and downlink fragmentation FPorts MUST be + different. + +5.2. RuleID Management + + The RuleID MUST be 8 bits and encoded in the LoRaWAN FPort as + described in Section 5.1. LoRaWAN supports up to 223 application + FPorts in the range [1..223] as defined in Section 4.3.2 of + [LORAWAN-SPEC]; it implies that the RuleID MSB SHOULD be inside this + range. An application can send non-SCHC traffic by using FPort + values different from the ones used for SCHC. + + In order to improve interoperability, RECOMMENDED fragmentation + RuleID values are: + + * RuleID = 20 (8-bit) for uplink fragmentation, named FPortUp. + + * RuleID = 21 (8-bit) for downlink fragmentation, named FPortDown. + + * RuleID = 22 (8-bit) for which SCHC compression was not possible + (i.e., no matching compression Rule was found), as described in + Section 6 of [RFC8724]. + + The FPortUp value MUST be different from the FPortDown value. The + remaining RuleIDs are available for compression. RuleIDs are shared + between uplink and downlink sessions. A RuleID not in the set(s) of + FPortUp or FPortDown means that the fragmentation is not used; thus, + on reception, the SCHC Message MUST be sent to the SCHC C/D layer. + + The only uplink frames using the FPortDown port are the fragmentation + SCHC control messages of a downlink-fragmented datagram (for example, + SCHC ACKs). Similarly, the only downlink frames using the FPortUp + port are the fragmentation SCHC control messages of an uplink- + fragmented datagram. + + An application can have multiple fragmented datagrams between a + device and one or several SCHC gateways. A set of FPort values is + REQUIRED for each SCHC gateway instance the device is required to + communicate with. The application can use additional uplinks or + downlink-fragmented parameters but SHALL implement at least the + parameters defined in this document. + + The mechanism for context distribution across devices and gateways is + outside the scope of this document. + +5.3. Interface IDentifier (IID) Computation + + In order to mitigate the risks described in [RFC8064] and [RFC8065], + implementations MUST implement the following algorithm and SHOULD use + it. + + 1. key = LoRaWAN AppSKey + + 2. cmac = aes128_cmac(key, DevEUI) + + 3. IID = cmac[0..7] + + The aes128_cmac algorithm is described in [RFC4493]. It has been + chosen as it is already used by devices for the LoRaWAN protocol. + + As AppSKey is renewed each time a device joins or rejoins a LoRaWAN + network, the IID will change over time; this mitigates privacy + concerns, for example, location tracking or correlation over time. + Join periodicity is defined at the application level. + + Address-scan risk is mitigated thanks to the entropy added to the IID + by the inclusion of AppSKey. + + Using this algorithm will also ensure that there is no correlation + between the hardware identifier (DevEUI) and the IID, so an attacker + cannot use the manufacturer OUI to target devices. + + Example with: + + * DevEUI: 0x1122334455667788 + + * AppSKey: 0x00AABBCCDDEEFF00AABBCCDDEEFFAABB + + 1. key: 0x00AABBCCDDEEFF00AABBCCDDEEFFAABB + 2. cmac: 0x4E822D9775B2649928F82066AF804FEC + 3. IID: 0x4E822D9775B26499 + + Figure 6: Example of IID Computation + + There is a small probability of IID collision in a LoRaWAN network. + If this occurs, the IID can be changed by rekeying the device at the + L2 level (i.e., triggering a LoRaWAN join). The way the device is + rekeyed is out of scope of this document and left to the + implementation. + + | Note: Implementations also using another IID source MUST ensure + | that the same IID is shared between the device and the SCHC + | gateway in the compression and decompression of the IPv6 + | address of the device. + +5.4. Padding + + All padding bits MUST be 0. + +5.5. Decompression + + The SCHC C/D MUST concatenate FPort and LoRaWAN payload to retrieve + the SCHC Packet as per Section 5.1. + + RuleIDs matching FPortUp and FPortDown are reserved for SCHC + fragmentation. + +5.6. Fragmentation + + The L2 Word Size used by LoRaWAN is 1 byte (8 bits). The SCHC + fragmentation over LoRaWAN uses the ACK-on-Error mode for uplink + fragmentation and ACK-Always mode for downlink fragmentation. A + LoRaWAN device cannot support simultaneous interleaved fragmented + datagrams in the same direction (uplink or downlink). + + The fragmentation parameters are different for uplink- and downlink- + fragmented datagrams and are successively described in the next + sections. + +5.6.1. DTag + + Section 8.2.4 of [RFC8724] describes the possibility to interleave + several fragmented SCHC datagrams for the same RuleID. This is not + used in the SCHC-over-LoRaWAN profile. A device cannot interleave + several fragmented SCHC datagrams on the same FPort. This field is + not used, and its size is 0. + + | Note: The device can still have several parallel fragmented + | datagrams with more than one SCHC gateway thanks to distinct + | sets of FPorts, cf. Section 5.2. + +5.6.2. Uplink Fragmentation: From Device to SCHC Gateway + + In this case, the device is the fragment transmitter and the SCHC + gateway is the fragment receiver. A single fragmentation rule is + defined. The SCHC F/R MUST concatenate FPort and LoRaWAN payload to + retrieve the SCHC Packet, as per Section 5.1. + + SCHC fragmentation reliability mode: "ACK-on-Error". + + SCHC header size: 2 bytes (the FPort byte + 1 additional byte). + + RuleID: 8 bits stored in the LoRaWAN FPort (cf. Section 5.2). + + DTag: Size T = 0 bits, not used (cf. Section 5.6.1). + + Window index: 4 windows are used, encoded on M = 2 bits. + + FCN: The FCN field is encoded on N = 6 bits, so WINDOW_SIZE = 63 + tiles are allowed in a window. + + Last tile: It can be carried in a Regular SCHC Fragment, alone in an + All-1 SCHC Fragment, or with any of these two methods. + Implementations must ensure that: + + * The sender MUST ascertain that the receiver will not receive + the last tile through both a Regular SCHC Fragment and an All-1 + SCHC Fragment during the same session. + + * If the last tile is in an All-1 SCHC Message, the current L2 + MTU MUST be big enough to fit the All-1 header and the last + tile. + + Penultimate tile: MUST be equal to the regular size. + + RCS: Use the recommended calculation algorithm in Section 8.2.3 of + [RFC8724], Integrity Checking. + + Tile: Size is 10 bytes. + + Retransmission timer: Set by the implementation depending on the + application requirements. The default RECOMMENDED duration of + this timer is 12 hours; this value is mainly driven by application + requirements and MAY be changed by the application. + + Inactivity timer: The SCHC gateway implements an "inactivity timer". + The default RECOMMENDED duration of this timer is 12 hours; this + value is mainly driven by application requirements and MAY be + changed by the application. + + MAX_ACK_REQUESTS: 8. With this set of parameters, the SCHC Fragment + Header is 16 bits, including FPort; payload overhead will be 8 + bits as FPort is already a part of LoRaWAN payload. MTU is: 4 + windows * 63 tiles * 10 bytes per tile = 2520 bytes. + + In addition to the per-rule context parameters specified in + [RFC8724], for uplink rules, an additional context parameter is + added: whether or not to ack after each window. For battery powered + devices, it is RECOMMENDED to use the ACK mechanism at the end of + each window instead of waiting until the end of all windows: + + * The SCHC receiver SHOULD send a SCHC ACK after every window even + if there is no missing tile. + + * The SCHC sender SHOULD wait for the SCHC ACK from the SCHC + receiver before sending tiles from the next window. If the SCHC + ACK is not received, it SHOULD send a SCHC ACK REQ up to + MAX_ACK_REQUESTS times, as described previously. + + This will avoid useless uplinks if the device has lost network + coverage. + + For non-battery powered devices, the SCHC receiver MAY also choose to + send a SCHC ACK only at the end of all windows. This will reduce + downlink load on the LoRaWAN network by reducing the number of + downlinks. + + SCHC implementations MUST be compatible with both behaviors, and this + selection is part of the rule context. + +5.6.2.1. Regular Fragments + + Figure 7 is an example of a regular fragment for all fragments except + the last one. SCHC Header Size is 16 Bits, including the LoRaWAN + FPort. + + | FPort | LoRaWAN payload | + + ------ + ------------------------- + + | RuleID | W | FCN | Payload | + + ------ + ------ + ------ + ------- + + | 8 bits | 2 bits | 6 bits | | + + Figure 7: All Fragments Except the Last One. + +5.6.2.2. Last Fragment (All-1) + + Following figures are examples of All-1 messages. Figure 8 is + without the last tile, Figure 9 is with the last tile. + + | FPort | LoRaWAN payload | + + ------ + ---------------------------- + + | RuleID | W | FCN=All-1 | RCS | + + ------ + ------ + --------- + ------- + + | 8 bits | 2 bits | 6 bits | 32 bits | + + Figure 8: All-1 SCHC Message without Last Tile + + | FPort | LoRaWAN payload | + + ------ + ---------------------------------------------------------- + + | RuleID | W | FCN=All-1 | RCS | Last tile | Opt. padding | + + ------ + ------ + --------- + ------- + ------------ + ------------ + + | 8 bits | 2 bits | 6 bits | 32 bits | 1 to 80 bits | 0 to 7 bits | + + Figure 9: All-1 SCHC Message with Last Tile + +5.6.2.3. SCHC ACK + + | FPort | LoRaWAN payload | + + ------ + --------------------------+ + | RuleID | W | C = 1 | padding | + | | | | (b'00000) | + + ------ + ----- + ----- + --------- + + | 8 bits | 2 bit | 1 bit | 5 bits | + + Figure 10: SCHC ACK Format - Correct RCS Check + + | FPort | LoRaWAN payload | + + ------ + --------------------------------- + ---------------- + + | RuleID | W | C = 0 | Compressed bitmap | Optional padding | + | | | | (C = 0) | (b'0...0) | + + ------ + ----- + ----- + ----------------- + ---------------- + + | 8 bits | 2 bit | 1 bit | 5 to 63 bits | 0, 6, or 7 bits | + + Figure 11: SCHC ACK Format - Incorrect RCS Check + + | Note: Because of the bitmap compression mechanism and L2 byte + | alignment, only the following discrete values are possible for + | the compressed bitmap size: 5, 13, 21, 29, 37, 45, 53, 61, 62, + | and 63. Bitmaps of 63 bits will require 6 bits of padding. + +5.6.2.4. Receiver-Abort + + | FPort | LoRaWAN payload | + + ------ + -------------------------------------------- + + | RuleID | W = b'11 | C = 1 | b'11111 | 0xFF (all 1's) | + + ------ + -------- + ------+-------- + ----------------+ + | 8 bits | 2 bits | 1 bit | 5 bits | 8 bits | + next L2 Word boundary ->| <-- L2 Word --> | + + Figure 12: Receiver-Abort Format + +5.6.2.5. SCHC Acknowledge Request + + | FPort | LoRaWAN payload | + +------- +------------------------- + + | RuleID | W | FCN = b'000000 | + + ------ + ------ + --------------- + + | 8 bits | 2 bits | 6 bits | + + Figure 13: SCHC ACK REQ Format + +5.6.3. Downlink Fragmentation: From SCHC Gateway to Device + + In this case, the device is the fragmentation receiver and the SCHC + gateway is the fragmentation transmitter. The following fields are + common to all devices. The SCHC F/R MUST concatenate FPort and + LoRaWAN payload to retrieve the SCHC Packet as described in + Section 5.1. + + SCHC fragmentation reliability mode: + Unicast downlinks: ACK-Always. + + Multicast downlinks: No-ACK; reliability has to be ensured by + the upper layer. This feature is OPTIONAL for the SCHC + gateway and REQUIRED for the device. + + RuleID: 8 bits stored in the LoRaWAN FPort (cf. Section 5.2). + + DTag: Size T = 0 bit, not used (cf. Section 5.6.1). + + FCN: The FCN field is encoded on N = 1 bit, so WINDOW_SIZE = 1 tile. + + RCS: Use the recommended calculation algorithm in Section 8.2.3 of + [RFC8724], Integrity Checking. + + Inactivity timer: The default RECOMMENDED duration of this timer is + 12 hours; this value is mainly driven by application requirements + and MAY be changed by the application. + + The following parameters apply to ACK-Always (Unicast) only: + + Retransmission timer: See Section 5.6.3.5. + + MAX_ACK_REQUESTS: 8. + + Window index (unicast only): encoded on M = 1 bit, as per [RFC8724]. + + As only one tile is used, its size can change for each downlink and + will be the currently available MTU. + + Class A devices can only receive during an RX slot, following the + transmission of an uplink. Therefore, the SCHC gateway cannot + initiate communication (e.g., start a new SCHC session). In order to + create a downlink opportunity, it is RECOMMENDED for Class A devices + to send an uplink every 24 hours when no SCHC session is started; + this is application specific and can be disabled. The RECOMMENDED + uplink is a LoRaWAN empty frame as defined in Section 4.6. As this + uplink is sent only to open an RX window, any LoRaWAN uplink frame + from the device MAY reset this counter. + + | Note: The FPending bit included in the LoRaWAN protocol SHOULD + | NOT be used for the SCHC-over-LoRaWAN protocol. It might be + | set by the Network Gateway for other purposes but not SCHC + | needs. + +5.6.3.1. Regular Fragments + + Figure 14 is an example of a regular fragment for all fragments + except the last one. SCHC Header Size is 10 Bits, including the + LoRaWAN FPort. + + | FPort | LoRaWAN payload | + + ------ + ------------------------------------ + + | RuleID | W | FCN = b'0 | Payload | + + ------ + ----- + --------- + ---------------- + + | 8 bits | 1 bit | 1 bit | X bytes + 6 bits | + + Figure 14: All Fragments but the Last One. + +5.6.3.2. Last Fragment (All-1) + + | FPort | LoRaWAN payload | + + ------ + --------------------------- + ------------------------- + + | RuleID | W | FCN = b'1 | RCS | Payload | Opt padding | + + ------ + ----- + --------- + ------- + ----------- + ----------- + + | 8 bits | 1 bit | 1 bit | 32 bits | 6 to X bits | 0 to 7 bits | + + Figure 15: All-1 SCHC Message: The Last Fragment + +5.6.3.3. SCHC ACK + + | FPort | LoRaWAN payload | + + ------ + ---------------------------------- + + | RuleID | W | C = b'1 | Padding b'000000 | + + ------ + ----- + ------- + ---------------- + + | 8 bits | 1 bit | 1 bit | 6 bits | + + Figure 16: SCHC ACK Format - Correct RCS Check + + | FPort | LoRaWAN payload | + + ------ + ------------------------------------------------- + + | RuleID | W | C = b'0 | Bitmap = b'1 | Padding b'000000 | + + ------ + ----- + ------- + ------------ + ---------------- + + | 8 bits | 1 bit | 1 bit | 1 bit | 5 bits | + + Figure 17: SCHC ACK Format - Incorrect RCS Check + +5.6.3.4. Receiver-Abort + + Figure 18 is an example of a Receiver-Abort packet, following an + All-1 SCHC Fragment with incorrect RCS. + + | FPort | LoRaWAN payload | + + ------ + ---------------------------------------------- + + | RuleID | W = b'1 | C = b'1 | b'111111 | 0xFF (all 1's) | + + ------ + ------- + ------- + -------- + --------------- + + | 8 bits | 1 bit | 1 bits | 6 bits | 8 bits | + next L2 Word boundary ->| <-- L2 Word --> | + + Figure 18: Receiver-Abort Packet + +5.6.3.5. Downlink Retransmission Timer + + Class A, Class B, and Class C devices do not manage retransmissions + and timers the same way. + +5.6.3.5.1. Class A Devices + + Class A devices can only receive in an RX slot following the + transmission of an uplink. + + The SCHC gateway implements an inactivity timer with a RECOMMENDED + duration of 36 hours. For devices with very low transmission rates + (for example, 1 packet a day in normal operation), that duration may + be extended; it is application specific. + + RETRANSMISSION_TIMER is application specific and its RECOMMENDED + value is INACTIVITY_TIMER/(MAX_ACK_REQUESTS + 1). + + *SCHC All-0 (FCN = 0)* + + All fragments but the last have an FCN = 0 (because the window size + is 1). Following an All-0 SCHC Fragment, the device MUST transmit + the SCHC ACK message. It MUST transmit up to MAX_ACK_REQUESTS SCHC + ACK messages before aborting. In order to progress the fragmented + datagram, the SCHC layer should immediately queue for transmission + those SCHC ACK messages if no SCHC downlink has been received during + the RX1 and RX2 windows. The LoRaWAN layer will respect the + applicable local spectrum regulation. + + | Note: The ACK bitmap is 1 bit long and is always 1. + + *SCHC All-1 (FCN = 1)* + + SCHC All-1 is the last fragment of a datagram, and the corresponding + SCHC ACK message might be lost; therefore, the SCHC gateway MUST + request a retransmission of this ACK when the retransmission timer + expires. To open a downlink opportunity, the device MUST transmit an + uplink every interval of RETRANSMISSION_TIMER/(MAX_ACK_REQUESTS * + SCHC_ACK_REQ_DN_OPPORTUNITY). The format of this uplink is + application specific. It is RECOMMENDED for a device to send an + empty frame (see Section 4.6), but it is application specific and + will be used by the NGW to transmit a potential SCHC ACK REQ. + SCHC_ACK_REQ_DN_OPPORTUNITY is application specific and its + recommended value is 2. It MUST be greater than 1. This allows the + opening of a downlink opportunity to any downlink with higher + priority than the SCHC ACK REQ message. + + | Note: The device MUST keep this SCHC ACK message in memory + | until it receives a downlink SCHC Fragmentation Message (with + | FPort == FPortDown) that is not a SCHC ACK REQ; this indicates + | that the SCHC gateway has received the SCHC ACK message. + +5.6.3.6. Class B or Class C Devices + + Class B devices can receive in scheduled RX slots or in RX slots + following the transmission of an uplink. Class C devices are almost + in constant reception. + + RECOMMENDED retransmission timer values are: + + Class B: 3 times the ping slot periodicity. + + Class C: 30 seconds. + + The RECOMMENDED inactivity timer value is 12 hours for both Class B + and Class C devices. + +5.7. SCHC Fragment Format + +5.7.1. All-0 SCHC Fragment + + *Uplink Fragmentation (Ack-on-Error)*: + + All-0 is distinguishable from a SCHC ACK REQ, as [RFC8724] states + "This condition is also met if the SCHC Fragment Header is a multiple + of L2 Words", the following condition being met: SCHC header is 2 + bytes. + + *Downlink fragmentation (ACK-Always)*: + + As per [RFC8724], SCHC All-1 MUST contain the last tile, and + implementations MUST ensure that SCHC All-0 message Payload will be + at least the size of an L2 Word. + +5.7.2. All-1 SCHC Fragment + + All-1 is distinguishable from a SCHC Sender-Abort, as [RFC8724] + states "This condition is met if the RCS is present and is at least + the size of an L2 Word", the following condition being met: RCS is 4 + bytes. + +5.7.3. Delay after Each LoRaWAN Frame to Respect Local Regulation + + This profile does not define a delay to be added after each LoRaWAN + frame; local regulation compliance is expected to be enforced by the + LoRaWAN stack. + +6. Security Considerations + + This document is only providing parameters that are expected to be + best suited for LoRaWAN networks for [RFC8724]. IID security is + discussed in Section 5.3. As such, this document does not contribute + to any new security issues beyond those already identified in + [RFC8724]. Moreover, SCHC data (LoRaWAN payload) are protected at + the LoRaWAN level by an AES-128 encryption with a session key shared + by the device and the SCHC gateway. These session keys are renewed + at each LoRaWAN session (i.e., each join or rejoin to the LoRaWAN + network). + +7. IANA Considerations + + This document has no IANA actions. + +8. References + +8.1. Normative References + + [LORAWAN-SPEC] + LoRa Alliance, "LoRaWAN 1.0.4 Specification Package", + <https://lora-alliance.org/resource_hub/lorawan-104- + specification-package/>. + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, + DOI 10.17487/RFC2119, March 1997, + <https://www.rfc-editor.org/info/rfc2119>. + + [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing + Architecture", RFC 4291, DOI 10.17487/RFC4291, February + 2006, <https://www.rfc-editor.org/info/rfc4291>. + + [RFC4493] Song, JH., Poovendran, R., Lee, J., and T. Iwata, "The + AES-CMAC Algorithm", RFC 4493, DOI 10.17487/RFC4493, June + 2006, <https://www.rfc-editor.org/info/rfc4493>. + + [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC + 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, + May 2017, <https://www.rfc-editor.org/info/rfc8174>. + + [RFC8724] Minaburo, A., Toutain, L., Gomez, C., Barthel, D., and JC. + Zúñiga, "SCHC: Generic Framework for Static Context Header + Compression and Fragmentation", RFC 8724, + DOI 10.17487/RFC8724, April 2020, + <https://www.rfc-editor.org/info/rfc8724>. + +8.2. Informative References + + [LORAWAN-REMOTE-MULTICAST-SET] + LoRa Alliance, "LoRaWAN Remote Multicast Setup + Specification v1.0.0", <https://lora- + alliance.org/resource_hub/lorawan-remote-multicast-setup- + specification-v1-0-0/>. + + [RFC8064] Gont, F., Cooper, A., Thaler, D., and W. Liu, + "Recommendation on Stable IPv6 Interface Identifiers", + RFC 8064, DOI 10.17487/RFC8064, February 2017, + <https://www.rfc-editor.org/info/rfc8064>. + + [RFC8065] Thaler, D., "Privacy Considerations for IPv6 Adaptation- + Layer Mechanisms", RFC 8065, DOI 10.17487/RFC8065, + February 2017, <https://www.rfc-editor.org/info/rfc8065>. + + [RFC8376] Farrell, S., Ed., "Low-Power Wide Area Network (LPWAN) + Overview", RFC 8376, DOI 10.17487/RFC8376, May 2018, + <https://www.rfc-editor.org/info/rfc8376>. + +Appendix A. Examples + + In the following examples, "applicative data" refers to the IPv6 + payload sent by the application to the SCHC layer. + +A.1. Uplink - Compression Example - No Fragmentation + + This example represents an applicative data going through SCHC over + LoRaWAN; no fragmentation required. + + An applicative data of 78 bytes is passed to the SCHC compression + layer. Rule 1 is used by the SCHC C/D layer, allowing to compress it + to 40 bytes and 5 bits: 1 byte RuleID, 21 bits residue + 37 bytes + payload. + + | RuleID | Compression residue | Payload | Padding=b'000 | + + ------ + ------------------- + --------- + ------------- + + | 1 | 21 bits | 37 bytes | 3 bits | + + Figure 19: Uplink Example: SCHC Message + + The current LoRaWAN MTU is 51 bytes, although 2-byte FOpts are used + by the LoRaWAN protocol: 49 bytes are available for SCHC payload; no + need for fragmentation. The payload will be transmitted through + FPort = 1. + + | LoRaWAN Header | LoRaWAN payload (40 bytes) | + + ------------------------- + --------------------------------------- + + | | FOpts | RuleID=1 | Compression | Payload | Padding=b'000 | + | | | | residue | | | + + ---- + ------- + -------- + ----------- + --------- + ------------- + + | XXXX | 2 bytes | 1 byte | 21 bits | 37 bytes | 3 bits | + + Figure 20: Uplink Example: LoRaWAN Packet + +A.2. Uplink - Compression and Fragmentation Example + + This example represents an applicative data going through SCHC, with + fragmentation. + + An applicative data of 300 bytes is passed to the SCHC compression + layer. Rule 1 is used by the SCHC C/D layer, allowing to compress it + to 282 bytes and 5 bits: 1 byte RuleID, 21 bits residue + 279 bytes + payload. + + | RuleID | Compression residue | Payload | + + ------ + ------------------- + --------- + + | 1 | 21 bits | 279 bytes | + + Figure 21: Uplink Example: SCHC Message + + The current LoRaWAN MTU is 11 bytes; 0-byte FOpts are used by the + LoRaWAN protocol: 11 bytes are available for SCHC payload + 1 byte + FPort field. The SCHC header is 2 bytes (including FPort), so 1 tile + is sent in the first fragment. + + | LoRaWAN Header | LoRaWAN payload (11 bytes) | + + -------------------------- + -------------------------- + + | | RuleID=20 | W | FCN | 1 tile | + + -------------- + --------- + ----- + ------ + --------- + + | XXXX | 1 byte | 0 0 | 62 | 10 bytes | + + Figure 22: Uplink Example: LoRaWAN Packet 1 + + The tile content is described in Figure 23 + + Content of the tile is: + | RuleID | Compression residue | Payload | + + ------ + ------------------- + ----------------- + + | 1 | 21 bits | 6 bytes + 3 bits | + + Figure 23: Uplink Example: First Tile Content + + Next transmission MTU is 11 bytes, although 2-byte FOpts are used by + the LoRaWAN protocol: 9 bytes are available for SCHC payload + 1 byte + FPort field, a tile does not fit inside so the LoRaWAN stack will + send only FOpts. + + Next transmission MTU is 242 bytes, 4-byte FOpts. 23 tiles are + transmitted: + + | LoRaWAN Header | LoRaWAN payload (231 bytes) | + + --------------------------------------+ --------------------------- + + | | FOpts | RuleID=20 | W | FCN | 23 tiles | + + -------------- + ------- + ---------- + ----- + ----- + ----------- + + | XXXX | 4 bytes | 1 byte | 0 0 | 61 | 230 bytes | + + Figure 24: Uplink Example: LoRaWAN Packet 2 + + Next transmission MTU is 242 bytes, no FOpts. All 5 remaining tiles + are transmitted, the last tile is only 2 bytes + 5 bits. Padding is + added for the remaining 3 bits. + + | LoRaWAN Header | LoRaWAN payload (44 bytes) | + + ---- + ---------- + ----------------------------------------------- + + | | RuleID=20 | W | FCN | 5 tiles | Padding=b'000 | + + ---- + ---------- + ----- + ----- + --------------- + ------------- + + | XXXX | 1 byte | 0 0 | 38 | 42 bytes+5 bits | 3 bits | + + Figure 25: Uplink Example: LoRaWAN Packet 3 + + Then All-1 message can be transmitted: + + | LoRaWAN Header | LoRaWAN payload (44 bytes) | + + ---- + -----------+ -------------------------- + + | | RuleID=20 | W | FCN | RCS | + + ---- + ---------- + ----- + ----- + ---------- + + | XXXX | 1 byte | 0 0 | 63 | 4 bytes | + + Figure 26: Uplink Example: LoRaWAN Packet 4 - All-1 SCHC Message + + All packets have been received by the SCHC gateway, computed RCS is + correct so the following ACK is sent to the device by the SCHC + receiver: + + | LoRaWAN Header | LoRaWAN payload | + + -------------- + --------- + ------------------- + + | | RuleID=20 | W | C | Padding | + + -------------- + --------- + ----- + - + ------- + + | XXXX | 1 byte | 0 0 | 1 | 5 bits | + + Figure 27: Uplink Example: LoRaWAN Packet 5 - SCHC ACK + +A.3. Downlink + + An applicative data of 155 bytes is passed to the SCHC compression + layer. Rule 1 is used by the SCHC C/D layer, allowing to compress it + to 130 bytes and 5 bits: 1 byte RuleID, 21 bits residue + 127 bytes + payload. + + | RuleID | Compression residue | Payload | + + ------ + ------------------- + --------- + + | 1 | 21 bits | 127 bytes | + + Figure 28: Downlink Example: SCHC Message + + The current LoRaWAN MTU is 51 bytes; no FOpts are used by the LoRaWAN + protocol: 51 bytes are available for SCHC payload + FPort field; the + applicative data has to be fragmented. + + | LoRaWAN Header | LoRaWAN payload (51 bytes) | + + ---- + ---------- + -------------------------------------- + + | | RuleID=21 | W = 0 | FCN = 0 | 1 tile | + + ---- + ---------- + ------ + ------- + ------------------- + + | XXXX | 1 byte | 1 bit | 1 bit | 50 bytes and 6 bits | + + Figure 29: Downlink Example: LoRaWAN Packet 1 - SCHC Fragment 1 + + The tile content is described in Figure 30 + + | RuleID | Compression residue | Payload | + + ------ + ------------------- + ------------------ + + | 1 | 21 bits | 48 bytes and 1 bit | + + Figure 30: Downlink Example: First Tile Content + + The receiver answers with a SCHC ACK: + + | LoRaWAN Header | LoRaWAN payload | + + ---- + --------- + -------------------------------- + + | | RuleID=21 | W = 0 | C = 1 | Padding=b'000000 | + + ---- + --------- + ----- + ----- + ---------------- + + | XXXX | 1 byte | 1 bit | 1 bit | 6 bits | + + Figure 31: Downlink Example: LoRaWAN Packet 2 - SCHC ACK + + The second downlink is sent, two FOpts: + + | LoRaWAN Header | LoRaWAN payload (49 bytes) | + + --------------------------- + ------------------------------------- + + | | FOpts | RuleID=21 | W = 1 | FCN = 0 | 1 tile | + + ---- + ------- + ---------- + ----- + ------- + ------------------- + + | XXXX | 2 bytes | 1 byte | 1 bit | 1 bit | 48 bytes and 6 bits | + + Figure 32: Downlink Example: LoRaWAN Packet 3 - SCHC Fragment 2 + + The receiver answers with a SCHC ACK: + + | LoRaWAN Header | LoRaWAN payload | + + ---- + --------- + -------------------------------- + + | | RuleID=21 | W = 1 | C = 1 | Padding=b'000000 | + + ---- + --------- + ----- + ----- + ---------------- + + | XXXX | 1 byte | 1 bit | 1 bit | 6 bits | + + Figure 33: Downlink Example: LoRaWAN Packet 4 - SCHC ACK + + The last downlink is sent, no FOpts: + + | LoRaWAN Header | LoRaWAN payload (37 bytes) | + + ---- + ------- + -------------------------------------------------- + + | | RuleID | W | FCN | RCS | 1 tile | Padding | + | | 21 | 0 | 1 | | | b'00000 | + + ---- + ------- + ----- + ----- + ------- + -------------- + ------- + + | XXXX | 1 byte | 1 bit | 1 bit | 4 bytes | 31 bytes+1 bit | 5 bits | + + Figure 34: Downlink Example: LoRaWAN Packet 5 - All-1 SCHC Message + + The receiver answers to the sender with a SCHC ACK: + + | LoRaWAN Header | LoRaWAN payload | + + ---- + --------- + -------------------------------- + + | | RuleID=21 | W = 0 | C = 1 | Padding=b'000000 | + + ---- + --------- + ----- + ----- + ---------------- + + | XXXX | 1 byte | 1 bit | 1 bit | 6 bits | + + Figure 35: Downlink Example: LoRaWAN Packet 6 - SCHC ACK + +Acknowledgements + + Thanks to all those listed in the Contributors Section for the + excellent text, insightful discussions, reviews, and suggestions, and + also to (in alphabetical order) Dominique Barthel, Arunprabhu + Kandasamy, Rodrigo Munoz, Alexander Pelov, Pascal Thubert, and + Laurent Toutain for useful design considerations, reviews, and + comments. + + LoRaWAN is a registered trademark of the LoRa Alliance. + +Contributors + + Contributors ordered by family name. + + Vincent Audebert + EDF R&D + + Email: vincent.audebert@edf.fr + + + Julien Catalano + Kerlink + + Email: j.catalano@kerlink.fr + + + Michael Coracin + Semtech + + Email: mcoracin@semtech.com + + + Marc Le Gourrierec + Sagemcom + + Email: marc.legourrierec@sagemcom.com + + + Nicolas Sornin + Chirp Foundation + + Email: nicolas.sornin@chirpfoundation.org + + + Alper Yegin + Actility + + Email: alper.yegin@actility.com + + +Authors' Addresses + + Olivier Gimenez (editor) + Semtech + 14 Chemin des Clos + Meylan + France + + Email: ogimenez@semtech.com + + + Ivaylo Petrov (editor) + Acklio + 1137A Avenue des Champs Blancs + 35510 Cesson-Sévigné Cedex + France + + Email: ivaylo@ackl.io |