diff --git a/draft-ietf-lpwan-schc-over-lorawan.md b/draft-ietf-lpwan-schc-over-lorawan.md index c5097ba..08b3e28 100644 --- a/draft-ietf-lpwan-schc-over-lorawan.md +++ b/draft-ietf-lpwan-schc-over-lorawan.md @@ -33,18 +33,18 @@ normative: RFC2119: RFC8174: RFC4291: - RFC8064: - RFC8724: -informative: RFC4493: - RFC8065: - RFC8376: + RFC8724: lora-alliance-spec: - title: LoRaWAN Specification Version V1.0.3 + title: LoRaWAN Specification Version V1.0.4 author: name: LoRa Alliance - date: 07.2018 - target: https://lora-alliance.org/sites/default/files/2018-07/lorawan1.0.3.pdf + date: 10.2020 + target: https://lora-alliance.org/resource_hub/lorawan-104-specification-package/ +informative: + RFC8064: + RFC8065: + RFC8376: lora-alliance-remote-multicast-set: title: LoRaWAN Remote Multicast Setup Specification Version 1.0.0 author: @@ -59,7 +59,7 @@ header compression and fragmentation techniques for Low Power Wide Area Networks (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 specifies a profile of RFC8724 to use SCHC in LoRaWAN networks, +This document specifies a profile of RFC8724 to use SCHC in LoRaWAN® networks, and provides elements such as efficient parameterization and modes of operation. @@ -69,7 +69,7 @@ operation. SCHC specification [RFC8724] describes generic header compression and fragmentation techniques that can be used on all -LPWAN technologies defined in +Low Power Wide Area Networks (LPWAN) technologies defined in {{RFC8376}}. Even though those technologies share a great number of common features like star-oriented topologies, network architecture, devices with mostly quite predictable communications, etc; they do have some @@ -81,7 +81,8 @@ 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. +SCHC is used over LoRaWAN networks. LoRaWAN protocol is specified by the +LoRa® Alliance in {{lora-alliance-spec}} # Terminology @@ -94,7 +95,8 @@ This section defines the terminology and acronyms used in this document. For all other definitions, please look up the SCHC specification [RFC8724]. -- DevEUI: an IEEE EUI-64 identifier used to identify the device during the +- 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. - DevAddr: a 32-bit non-unique identifier assigned to a device either: @@ -106,6 +108,11 @@ all other definitions, please look up the SCHC specification - Downlink: LoRaWAN term for a frame transmitted by the network and received by the device. +- EUI: Extended Unique 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](https://www.lora-alliance.org). - FRMPayload: Application data in a LoRaWAN frame. - MSB: Most Significant Byte - OUI: Organisation Unique Identifier. IEEE assigned prefix for EUI. @@ -114,8 +121,8 @@ all other definitions, please look up the SCHC specification - RX: Device's reception window. - RX1/RX2: LoRaWAN class A devices open two RX windows following an uplink, called RX1 and RX2. -- SCHC gateway: It corresponds to the LoRaWAN Application Server. It manages - translation between IPv6 network and the Network Gateway (LoRaWAN Network +- SCHC gateway: The LoRaWAN Application Server that manages translation + between IPv6 network and the Network Gateway (LoRaWAN Network Server). - Tile: Piece of a fragmented packet as described in [RFC8724] section 8.2.2.1 - Uplink: LoRaWAN term for a frame transmitted by the device and received @@ -151,6 +158,7 @@ Context exchange or pre-provisioning is out of scope of this document. +~ |RGW| === |NGW | == |SCHC| == |SCHC|...... Internet .... +---+ +----+ |F/R | |C/D | +----+ +----+ +|<- - - - LoRaWAN - - ->| ~~~~ {: #Fig-archi title='Architecture'} @@ -192,6 +200,7 @@ LoRaWAN terminology to: +-------+ |server | |server | +-------+ | F/R - C/D | +-----------+ +|<- - - - - LoRaWAN - - - ->| ~~~~ {: #Fig-archi-lorawan title='SCHC Architecture mapped to LoRaWAN'} @@ -277,7 +286,7 @@ Class C. Class B and Class C are mutually exclusive. 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 +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 @@ -309,8 +318,9 @@ LoRaWAN implements the possibility to send confirmed or unconfirmed frames: * Unconfirmed frame: The sender does not ask the receiver to acknowledge the frame. -As SCHC defines its own acknowledgment mechanisms, SCHC does not require to use -LoRaWAN Confirmed frames. +As SCHC defines its own acknowledgment mechanisms, SCHC does not require +the use of LoRaWAN Confirmed frames (MType=0b100 as per +{{lora-alliance-spec}}) ## LoRaWAN MAC Frames @@ -329,7 +339,7 @@ frame types, which are used by a device to join a network: keys. * Data: MAC and application data. Application data are protected with AES-128 - encryption, MAC related data are AES-128 encrypted with another key. + encryption. MAC related data are AES-128 encrypted with another key. ## LoRaWAN FPort @@ -379,7 +389,7 @@ the FPort field with the LoRaWAN payload to recompose the SCHC Message. Note: SCHC Message is any datagram sent by SCHC C/D or F/R layers. A fragmented datagram with application payload transferred from device to -Network Gateway, is called uplink fragmented datagram. It uses an FPort for data uplink +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 downlink fragmented datagram. It uses another @@ -428,8 +438,8 @@ outside the scope of this document. ## Interface IDentifier (IID) computation {#IID} -In order to mitigate the risks described in [rfc8064] and [rfc8065], IID MUST be -created regarding the following algorithm: +In order to mitigate the risks described in [rfc8064] and [rfc8065], +implementation MUST implement the following algorithm and SHOULD use it. 1. key = LoRaWAN AppSKey 2. cmac = aes128_cmac(key, DevEUI) @@ -468,6 +478,10 @@ join). The way the device is rekeyed is out of scope of this document and left to the implementation. +Note: Implementation 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. + ## Padding All padding bits MUST be 0. @@ -490,7 +504,7 @@ 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. -### DTag +### DTag {#DTag} [RFC8724] section 8.2.4 describes the possibility to interleave several fragmented SCHC datagrams for the same RuleID. This is not used in SCHC over @@ -507,22 +521,13 @@ the fragment receiver. A single fragmentation rule is defined. SCHC F/R MUST concatenate FPort and LoRaWAN payload to retrieve the SCHC Packet, as per {{lorawan-schc-payload}}. -* SCHC header size is two bytes (the FPort byte + 1 additional byte). -* RuleID: 8 bits stored in LoRaWAN FPort. * SCHC fragmentation reliability mode: `ACK-on-Error`. -* DTag: Size is 0 bit, not used. +* SCHC header size is two bytes (the FPort byte + 1 additional byte). +* RuleID: 8 bits stored in LoRaWAN FPort. cf {{rule-id-management}} +* DTag: Size T=0 bit, not used. cf {{DTag}} +* 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. -* Window index: encoded on W = 2 bits. So 4 windows are available. -* RCS: Use recommended calculation algorithm in [RFC8724]. -* MAX_ACK_REQUESTS: 8. -* Tile: size is 10 bytes. -* Retransmission timer: Set by the implementation depending on the application - requirements. -* 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. -* Penultimate tile MUST be equal to the regular size. * 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. Implementation must ensure that: * The sender MUST ascertain that the receiver will not receive @@ -530,17 +535,30 @@ Packet, as per {{lorawan-schc-payload}}. Fragment during the same session. * If the last tile is in All-1 SCHC message: 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 recommended calculation algorithm in [RFC8724] (§8.2.3. 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 +* 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 +* 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. @@ -553,7 +571,6 @@ network, by reducing the number of downlinks. SCHC implementations MUST be compatible with both behaviors, and this selection is part of the rule context. - #### Regular fragments ~~~~ @@ -664,17 +681,20 @@ Packet as described in {{lorawan-schc-payload}}. * Unicast downlinks: ACK-Always. * Multicast downlinks: No-ACK, reliability has to be ensured by the upper layer. This feature is OPTIONAL and may not be implemented by SCHC gateway. -* RuleID: 8 bits stored in LoRaWAN FPort. -* Window index (unicast only): encoded on W=1 bit, as per [RFC8724]. -* DTag: Size is 0 bit, not used. +* RuleID: 8 bits stored in LoRaWAN FPort. cf {{rule-id-management}} +* DTag: Size T=0 bit, not used. cf {{DTag}} * FCN: The FCN field is encoded on N=1 bit, so WINDOW_SIZE = 1 tile. -* RCS: Use recommended calculation algorithm in [RFC8724]. -* MAX_ACK_REQUESTS: 8. -* Retransmission timer: See {{downlink-retransmission-timer}}. +* RCS: Use recommended calculation algorithm in [RFC8724] (§8.2.3. 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 {{downlink-retransmission-timer}}. +* MAX_ACK_REQUESTS: 8. +* Window index (unicast only): encoded on M=1 bit, as per [RFC8724]. + As only 1 tile is used, its size can change for each downlink, and will be the currently available MTU. @@ -777,6 +797,7 @@ 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 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 @@ -787,6 +808,7 @@ 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, 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 @@ -899,14 +921,15 @@ Email: alper.yegin@actility.com # Examples -In following examples "applicative payload" refers to the IPv6 payload sent by the +In following examples "applicative data" refers to the IPv6 payload sent by the application to the SCHC layer. ## Uplink - Compression example - No fragmentation -This example represents an applicative payload going through SCHC over LoRaWAN, + +This example represents an applicative data going through SCHC over LoRaWAN, no fragmentation required -An applicative payload of 78 bytes is passed to SCHC compression layer. Rule 1 +An applicative data of 78 bytes is passed to SCHC compression layer. Rule 1 is used by SCHC C/D layer, allowing to compress it to 40 bytes and 5 bits: 1 byte RuleID, 21 bits residue + 37 bytes payload. @@ -933,10 +956,10 @@ fragmentation. The payload will be transmitted through FPort = 1. ## Uplink - Compression and fragmentation example -This example represents an applicative payload going through SCHC, with +This example represents an applicative data going through SCHC, with fragmentation. -An applicative payload of 478 bytes is passed to SCHC compression layer. Rule 1 +An applicative data of 300 bytes is passed to SCHC compression layer. Rule 1 is used by SCHC C/D layer, allowing to compress it to 282 bytes and 5 bits: 1 byte RuleID, 21 bits residue + 279 bytes payload. @@ -1022,7 +1045,7 @@ correct so the following ACK is sent to the device by the SCHC receiver: ## Downlink -An applicative payload of 443 bytes is passed to SCHC compression layer. Rule 1 +An applicative data of 155 bytes is passed to SCHC compression layer. Rule 1 is used by SCHC C/D layer, allowing to compress it to 130 bytes and 5 bits: 1 byte RuleID, 21 bits residue + 127 bytes payload.