idnits 2.17.1 draft-ietf-lpwan-schc-over-lorawan-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** There are 9 instances of too long lines in the document, the longest one being 4 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (November 04, 2019) is 1636 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC4944' is defined on line 806, but no explicit reference was found in the text == Unused Reference: 'RFC5795' is defined on line 811, but no explicit reference was found in the text == Unused Reference: 'RFC7136' is defined on line 816, but no explicit reference was found in the text == Outdated reference: A later version (-24) exists of draft-ietf-lpwan-ipv6-static-context-hc-22 Summary: 2 errors (**), 0 flaws (~~), 5 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 lpwan Working Group O. Gimenez, Ed. 3 Internet-Draft Semtech 4 Intended status: Informational I. Petrov, Ed. 5 Expires: May 7, 2020 Acklio 6 November 04, 2019 8 Static Context Header Compression (SCHC) over LoRaWAN 9 draft-ietf-lpwan-schc-over-lorawan-04 11 Abstract 13 The Static Context Header Compression (SCHC) specification describes 14 generic header compression and fragmentation techniques for LPWAN 15 (Low Power Wide Area Networks) technologies. SCHC is a generic 16 mechanism designed for great flexibility so that it can be adapted 17 for any of the LPWAN technologies. 19 This document provides the adaptation of SCHC for use in LoRaWAN 20 networks, and provides elements such as efficient parameterization 21 and modes of operation. This is called a profile. 23 Status of This Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at https://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on May 7, 2020. 40 Copyright Notice 42 Copyright (c) 2019 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (https://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the Simplified BSD License. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 58 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 59 3. Static Context Header Compression Overview . . . . . . . . . 3 60 4. LoRaWAN Architecture . . . . . . . . . . . . . . . . . . . . 5 61 4.1. End-Device classes (A, B, C) and interactions . . . . . . 6 62 4.2. End-Device addressing . . . . . . . . . . . . . . . . . . 7 63 4.3. General Message Types . . . . . . . . . . . . . . . . . . 7 64 4.4. LoRaWAN MAC Frames . . . . . . . . . . . . . . . . . . . 8 65 4.5. Unicast and multicast technology . . . . . . . . . . . . 8 66 5. SCHC-over-LoRaWAN . . . . . . . . . . . . . . . . . . . . . . 8 67 5.1. LoRaWAN FPort . . . . . . . . . . . . . . . . . . . . . . 8 68 5.2. Rule ID management . . . . . . . . . . . . . . . . . . . 9 69 5.3. IID computation . . . . . . . . . . . . . . . . . . . . . 10 70 5.4. Padding . . . . . . . . . . . . . . . . . . . . . . . . . 10 71 5.5. Compression . . . . . . . . . . . . . . . . . . . . . . . 10 72 5.6. Fragmentation . . . . . . . . . . . . . . . . . . . . . . 10 73 5.6.1. DTag . . . . . . . . . . . . . . . . . . . . . . . . 11 74 5.6.2. Uplink fragmentation: From device to SCHC gateway . . 11 75 5.6.3. Downlink fragmentation: From SCHC gateway to a device 13 76 6. Security considerations . . . . . . . . . . . . . . . . . . . 17 77 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 17 78 Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 17 79 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 18 80 9.1. Normative References . . . . . . . . . . . . . . . . . . 18 81 9.2. Informative References . . . . . . . . . . . . . . . . . 19 82 Appendix A. Examples . . . . . . . . . . . . . . . . . . . . . . 19 83 A.1. Uplink - Compression example - No fragmentation . . . . . 19 84 A.2. Uplink - Compression and fragmentation example . . . . . 20 85 A.3. Downlink . . . . . . . . . . . . . . . . . . . . . . . . 22 86 Appendix B. Note . . . . . . . . . . . . . . . . . . . . . . . . 23 87 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 23 89 1. Introduction 91 The Static Context Header Compression (SCHC) specification 92 [I-D.ietf-lpwan-ipv6-static-context-hc] describes generic header 93 compression and fragmentation techniques that can be used on all 94 LPWAN (Low Power Wide Area Networks) technologies defined in 95 [RFC8376]. Even though those technologies share a great number of 96 common features like star-oriented topologies, network architecture, 97 devices with mostly quite predictable communications, etc; they do 98 have some slight differences in respect of payload sizes, 99 reactiveness, etc. 101 SCHC gives a generic framework that enables those devices to 102 communicate with other Internet networks. However, for efficient 103 performance, some parameters and modes of operation need to be set 104 appropriately for each of the LPWAN technologies. 106 This document describes the efficient parameters and modes of 107 operation when SCHC is used over LoRaWAN networks. 109 2. Terminology 111 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 112 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 113 "OPTIONAL" in this document are to be interpreted as described in BCP 114 14 [RFC2119] [RFC8174] when, and only when, they appear in all 115 capitals, as shown here. 117 This section defines the terminology and acronyms used in this 118 document. For all other definitions, please look up the SCHC 119 specification [I-D.ietf-lpwan-ipv6-static-context-hc]. 121 o DevEUI: an IEEE EUI-64 identifier used to identify the end-device 122 during the procedure while joining the network (Join Procedure) 124 o DevAddr: a 32-bit non-unique identifier assigned to an end-device 125 statically or dynamically after a Join Procedure (depending on the 126 activation mode) 128 o RCS: Reassembly Check Sequence. Used to verify the integrity of 129 the fragmentation-reassembly process 131 o TBD: all significant LoRaWAN-related terms. 133 3. Static Context Header Compression Overview 135 This section contains a short overview of Static Context Header 136 Compression (SCHC). For a detailed description, refer to the full 137 specification [I-D.ietf-lpwan-ipv6-static-context-hc]. 139 Static Context Header Compression (SCHC) avoids context 140 synchronization, based on the fact that the nature of data flows is 141 highly predictable in LPWAN networks, some static contexts may be 142 stored on the Device (Dev). The context MUST be stored in both ends, 143 and it can either be learned by a provisioning protocol or by out-of- 144 band means or it can be pre-provisioned, etc. The way the context is 145 learned on both sides is outside the scope of this document. 147 Dev App 148 +----------------+ +----+ +----+ +----+ 149 | App1 App2 App3 | |App1| |App2| |App3| 150 | | | | | | | | 151 | UDP | |UDP | |UDP | |UDP | 152 | IPv6 | |IPv6| |IPv6| |IPv6| 153 | | | | | | | | 154 |SCHC C/D and F/R| | | | | | | 155 +--------+-------+ +----+ +----+ +----+ 156 | +---+ +----+ +----+ +----+ . . . 157 +~ |RGW| === |NGW | == |SCHC| == |SCHC|...... Internet .... 158 +---+ +----+ |F/R | |C/D | 159 +----+ +----+ 161 Figure 1: Architecture 163 Figure 1 represents the architecture for compression/decompression, 164 it is based on [RFC8376] terminology. The Device is sending 165 applications flows using IPv6 or IPv6/UDP protocols. These flow 166 might be compressed by an Static Context Header Compression 167 Compressor/Decompressor (SCHC C/D) to reduce headers size and 168 fragmented (SCHC F/R). The resulting information is sent on a layer 169 two (L2) frame to an LPWAN Radio Gateway (RGW) which forwards the 170 frame to a Network Gateway (NGW). The NGW sends the data to a SCHC 171 F/R for defragmentation, if required, then C/D for decompression 172 which shares the same rules with the device. The SCHC F/R and C/D 173 can be located on the Network Gateway (NGW) or in another place as 174 long as a tunnel is established between the NGW and the SCHC F/R, 175 then SCHC F/R and SCHC C/D. The SCHC C/D in both sides MUST share 176 the same set of rules. After decompression, the packet can be sent 177 on the Internet to one or several LPWAN Application Servers (App). 179 The SCHC F/R and SCHC C/D process is bidirectional, so the same 180 principles can be applied in the other direction. 182 In a LoRaWAN network, the RG is called a Gateway, the NGW is Network 183 Server, and the SCHC C/D is an Application Server. It can be 184 provided by the Network Server or any third party software. Figure 1 185 can be mapped in LoRaWAN terminology to: 187 Dev App 188 +--------------+ +----+ +----+ +----+ 189 |App1 App2 App3| |App1| |App2| |App3| 190 | | | | | | | | 191 | UDP | |UDP | |UDP | |UDP | 192 | IPv6 | |IPv6| |IPv6| |IPv6| 193 | | | | | | | | 194 |SCHC C/D & F/R| | | | | | | 195 +-------+------+ +----+ +----+ +----+ 196 | +-------+ +-------+ +-----------+ . . . 197 +~ |Gateway| === |Network| == |Application|..... Internet .... 198 +-------+ |server | |server | 199 +-------+ | F/R - C/D | 200 +-----------+ 202 Figure 2: SCHC Architecture mapped to LoRaWAN 204 4. LoRaWAN Architecture 206 An overview of LoRaWAN [lora-alliance-spec] protocol and architecture 207 is described in [RFC8376]. The mapping between the LPWAN 208 architecture entities as described in 209 [I-D.ietf-lpwan-ipv6-static-context-hc] and the ones in 210 [lora-alliance-spec] is as follows: 212 o Devices (Dev) are the end-devices or hosts (e.g. sensors, 213 actuators, etc.). There can be a very high density of devices per 214 radio gateway (LoRaWAN gateway). This entity maps to the LoRaWAN 215 End-Device. 217 o The Radio Gateway (RGW), which is the endpoint of the constrained 218 link. This entity maps to the LoRaWAN Gateway. 220 o The Network Gateway (NGW) is the interconnection node between the 221 Radio Gateway and the Internet. This entity maps to the LoRaWAN 222 Network Server. 224 o LPWAN-AAA Server, which controls the user authentication and the 225 applications. This entity maps to the LoRaWAN Join Server. 227 o Application Server (App). The same terminology is used in LoRaWAN. 228 In that case, the application server will be the SCHC gateway, doing 229 C/D and F/R. 231 () () () | +------+ 232 () () () () / \ +---------+ | Join | 233 () () () () () / \======| ^ |===|Server| +-----------+ 234 () () () | | <--|--> | +------+ |Application| 235 () () () () / \==========| v |=============| Server | 236 () () () / \ +---------+ +-----------+ 237 End-Devices Gateways Network Server 239 Figure 3: LPWAN Architecture 241 SCHC C/D (Compressor/Decompressor) and SCHC F/R (Fragmentation/ 242 Reassembly) are performed on the LoRaWAN End-Device and the 243 Application Server (called SCHC gateway). While the point-to-point 244 link between the End-Device and the Application Server constitutes 245 single IP hop, the ultimate end-point of the IP communication may be 246 an Internet node beyond the Application Server. In other words, the 247 LoRaWAN Application Server (SCHC gateway) acts as the first hop IP 248 router for the End-Device. The Application Server and Network Server 249 may be co-located, which effectively turns the Network/Application 250 Server into the first hop IP router. 252 4.1. End-Device classes (A, B, C) and interactions 254 The LoRaWAN MAC layer supports 3 classes of end-devices named A, B 255 and C. All end-devices implement the Class A, some end-devices may 256 implement Class B or Class C. Class B and Class C are mutually 257 exclusive. 259 o Class A: The Class A is the simplest class of end-devices. The 260 end-device is allowed to transmit at any time, randomly selecting 261 a communication channel. The network may reply with a downlink in 262 one of the 2 receive windows immediately following the uplinks. 263 Therefore, the network cannot initiate a downlink, it has to wait 264 for the next uplink from the end-device to get a downlink 265 opportunity. The Class A is the lowest power end-device class. 267 o Class B: Class B end-devices implement all the functionalities of 268 Class A end-devices, but also schedule periodic listen windows. 269 Therefore, opposed to the Class A end-devices, Class B end-devices 270 can receive downlinks that are initiated by the network and not 271 following an uplink. There is a trade-off between the periodicity 272 of those scheduled Class B listen windows and the power 273 consumption of the end-device. The lower the downlink latency, 274 the higher the power consumption. 276 o Class C: Class C end-devices implement all the functionalities of 277 Class A end-devices, but keep their receiver open whenever they 278 are not transmitting. Class C end-devices can receive downlinks 279 at any time at the expense of a higher power consumption. 280 Battery-powered end-devices can only operate in Class C for a 281 limited amount of time (for example for a firmware upgrade over- 282 the-air). Most of the Class C end-devices are grid powered (for 283 example Smart Plugs). 285 4.2. End-Device addressing 287 LoRaWAN end-devices use a 32-bit network address (devAddr) to 288 communicate with the network over-the-air. However, that address 289 might be reused several times on the same network at the same time 290 for different end-devices. End-devices using the same devAddr are 291 distinguished by the Network Server based on the cryptographic 292 signature appended to every single LoRaWAN MAC frame, as all end- 293 devices use different security keys. To communicate with the SCHC 294 gateway the Network Server MUST identify the end-devices by a unique 295 64-bit device identifier called the devEUI. Unlike devAddr, devEUI 296 is guaranteed to be unique for every single end-device across all 297 networks. The devEUI is assigned to the end-device during the 298 manufacturing process by the end-device's manufacturer. It is built 299 like an Ethernet MAC address by concatenating the manufacturer's IEEE 300 OUI field with a vendor unique number. e.g.: 24-bit OUI is 301 concatenated with a 40-bit serial number. The Network Server 302 translates the devAddr into a devEUI in the uplink direction and 303 reciprocally on the downlink direction. 305 +--------+ +----------+ +---------+ +----------+ 306 | End- | <=====> | Network | <====> | SCHC | <========> | Internet | 307 | Device | devAddr | Server | devEUI | Gateway | IPv6/UDP | | 308 +--------+ +----------+ +---------+ +----------+ 310 Figure 4: LoRaWAN addresses 312 4.3. General Message Types 314 o Confirmed messages: The sender asks the receiver to acknowledge 315 the message. 317 o Unconfirmed messages: The sender does not ask the receiver to 318 acknowledge the message. 320 As SCHC defines its own acknowledgment mechanisms, SCHC does not 321 require to use confirmed messages. 323 4.4. LoRaWAN MAC Frames 325 o JoinRequest: This message is used by an end-device to join a 326 network. It contains the end-device's unique identifier devEUI 327 and a random nonce that will be used for session key derivation. 329 o JoinAccept: To on-board an end-device, the Network Server responds 330 to the JoinRequest end-device's message with a JoinAccept message. 331 That message is encrypted with the end-device's AppKey and 332 contains (amongst other fields) the major network's settings and a 333 network random nonce used to derive the session keys. 335 o Data 337 4.5. Unicast and multicast technology 339 LoRaWAN technology supports unicast downlinks, but also multicast: a 340 packet send over LoRaWAN radio link can be received by several 341 devices. It is useful to address many end-devices with same content, 342 either a large binary file (firmware upgrade), or same command (e.g: 343 lighting control). As IPv6 is also a multicast technology this 344 feature MAY be used to address a group of devices. 346 _Note 1_: IPv6 multicast addresses must be defined as per [RFC4291]. 347 LoRaWAN multicast group definition in a network server and the 348 relation between those groups and IPv6 groupID are out of scope of 349 this document. 351 _Note 2_: LoRa Alliance defined [lora-alliance-remote-multicast-set] 352 as RECOMMENDED way to setup multicast groups on devices and create a 353 synchronized reception window. 355 5. SCHC-over-LoRaWAN 357 5.1. LoRaWAN FPort 359 The LoRaWAN MAC layer features a frame port field in all frames. 360 This field (FPort) is 8 bits long and the values from 1 to 223 can be 361 used. It allows LoRaWAN networks and applications to identify data. 363 The FPort field is part of the SCHC Packet or the SCHC Fragment, as 364 shown in Figure 5. The SCHC C/D and the SCHC F/R SHALL concatenate 365 the FPort field with the LoRaWAN payload to retrieve their payload as 366 it is used as a part of the ruleId field. 368 | FPort | LoRaWAN payload | 369 + ------------------------ + 370 | SCHC payload | 372 Figure 5: SCHC payload in LoRaWAN 374 A fragmentation session with application payload transferred from 375 device to server, is called uplink fragmentation session. It uses an 376 FPort for data uplink and its associated SCHC control downlinks, 377 named FPortUp in this document. The other way, a fragmentation 378 session with application payload transferred from server to device, 379 is called downlink fragmentation session. It uses another FPort for 380 data downlink and its associated SCHC control uplinks, named 381 FPortDown in this document. 383 FPorts can use arbitrary values inside the allowed FPort range and 384 MUST be shared by the end-device, the Network Server and SCHC gateway 385 prior to the communication. The uplink and downlink fragmentation 386 FPorts MUST be different. 388 5.2. Rule ID management 390 RuleID MUST be 8 bits, encoded in the LoRaWAN FPort as described in 391 Section 5.1. LoRaWAN supports up to 223 application FPorts in the 392 range [1;223] as defined in section 4.3.2 of [lora-alliance-spec], it 393 implies that RuleID MSB SHOULD be inside this range. An application 394 MAY reserve some FPort values for other needs as long as they don't 395 conflict with FPorts used for SCHC C/D and SCHC F/R. 397 In order to improve interoperability RECOMMENDED fragmentation RuleID 398 values are: 400 o RuleID = 20 (8-bit) for uplink fragmentation, named FPortUp 402 o RuleID = 21 (8-bit) for downlink fragmentation, named FPortDown 404 o RuleID = 22 (8-bit) for which SCHC compression was not possible 405 (no matching rule was found) 407 The remaining RuleIDs are available for compression. RuleIDs are 408 shared between uplink and downlink sessions. A RuleID different from 409 FPortUp or FPortDown means that the fragmentation is not used, thus 410 the packet SHOULD be sent to C/D layer. 412 The only uplink messages using the FPortDown port are the 413 fragmentation SCHC control messages of a downlink fragmentation 414 session (ex ACKs). Similarly, the only downlink messages using the 415 FPortUp port are the fragmentation SCHC control messages of an uplink 416 fragmentation session. 418 An application can have multiple fragmentation sessions between a 419 device and one or several SCHC gateways. A set of FPort values is 420 REQUIRED for each SCHC gateway instance the device is required to 421 communicate with. 423 The mechanism for sharing those RuleID values is outside the scope of 424 this document. 426 5.3. IID computation 428 As LoRaWAN network uses unique EUI-64 per end-device, the Interface 429 IDentifier is the LoRaWAN DevEUI. It is compliant with [RFC4291] and 430 IID starting with binary 000 must enforce the 64-bit rule. 432 TODO: Derive IID from DevEUI with privacy constraints ? Ask working 433 group ? 435 5.4. Padding 437 All padding bits MUST be 0. 439 5.5. Compression 441 SCHC C/D MUST concatenate FPort and LoRaWAN payload to retrieve the 442 SCHC packet as per Section 5.1. 444 RuleIDs matching FPortUp and FPortDown are reserved for SCHC 445 Fragmentation. 447 5.6. Fragmentation 449 The L2 word size used by LoRaWAN is 1 byte (8 bits). The SCHC 450 fragmentation over LoRaWAN uses the ACK-on-Error for uplink 451 fragmentation and Ack-Always for downlink fragmentation. A LoRaWAN 452 end-device cannot support simultaneous interleaved fragmentation 453 sessions in the same direction (uplink or downlink). This means that 454 only a single fragmented IPv6 datagram may be transmitted and/or 455 received by the end-device at a given moment. 457 The fragmentation parameters are different for uplink and downlink 458 fragmentation sessions and are successively described in the next 459 sections. 461 5.6.1. DTag 463 A LoRaWAN device cannot interleave several fragmented SCHC datagrams 464 on the same FPort. This field is not used and its size is 0. 466 Note: The device can still have several parallel fragmentation 467 sessions with one or more SCHC gateway(s) thanks to distinct sets of 468 FPorts, cf Section 5.2 470 5.6.2. Uplink fragmentation: From device to SCHC gateway 472 In that case the device is the fragmentation transmitter, and the 473 SCHC gateway the fragmentation receiver. A single fragmentation rule 474 is defined. SCHC F/R MUST concatenate FPort and LoRaWAN payload to 475 retrieve the SCHC fragment as per Section 5.1. 477 o SCHC header size is two bytes (the FPort byte + 1 additional 478 byte). 480 o RuleID: 8 bits stored in LoRaWAN FPort. 482 o SCHC fragmentation reliability mode: "ACK-on-Error" 484 o DTag: Size is 0 bit, not used 486 o FCN: The FCN field is encoded on N = 6 bits, so WINDOW_SIZE = 63 487 tiles are allowed in a window 489 o Window index: encoded on W = 2 bits. So 4 windows are available. 491 o RCS calculation algorithm: CRC32 using 0xEDB88320 (i.e. the 492 reverse representation of the polynomial used e.g. in the Ethernet 493 standard [RFC3385]) as suggested in 494 [I-D.ietf-lpwan-ipv6-static-context-hc]. 496 o MAX_ACK_REQUESTS: 8 498 o Tile: size is 10 bytes 500 o Retransmission and inactivity timers: LoRaWAN end-devices do not 501 implement a "retransmission timer". At the end of a window or a 502 fragmentation session, corresponding ACK(s) is (are) transmitted 503 by the network gateway (LoRaWAN application server) in the RX1 or 504 RX2 receive slot of end-device. If this ACK is not received by 505 the end-device at the end of its RX windows, it sends an all-0 (or 506 an all-1) fragment with no payload to request an SCHC ACK 507 retransmission. The periodicity between retransmission of the 508 all-0/all-1 fragments is device/application specific and MAY be 509 different for each device (not specified). The SCHC gateway 510 implements an "inactivity timer". The default RECOMMENDED 511 duration of this timer is 12 hours. This value is mainly driven 512 by application requirements and MAY be changed by the application. 514 o Last tile: The last tile can be carried in the All-1 fragment. 516 With this set of parameters, the SCHC fragment header is 16 bits, 517 including FPort; payload overhead will be 8 bits as FPort is already 518 a part of LoRaWAN payload. MTU is: _4 windows * 63 tiles * 10 bytes 519 per tile = 2520 bytes_ 521 5.6.2.1. Regular fragments 523 | FPort | LoRaWAN payload | 524 + ------ + ------------------------- + 525 | RuleID | W | FCN | Payload | 526 + ------ + ------ + ------ + ------- + 527 | 8 bits | 2 bits | 6 bits | | 529 Figure 6: All fragments except the last one. SCHC header size is 16 530 bits, including LoRaWAN FPort. 532 5.6.2.2. Last fragment (All-1) 534 | FPort | LoRaWAN payload | 535 + ------ + ------------------------------------------------ + 536 | RuleID | W | FCN=All-1 | RCS | Payload | 537 + ------ + ------ + --------- + ------- + ----------------- + 538 | 8 bits | 2 bits | 6 bits | 32 bits | Last tile, if any | 540 Figure 7: All-1 fragment detailed format for the last fragment. 542 5.6.2.3. SCHC ACK 544 | FPort | LoRaWAN payload | 545 + ------ + ----------------------------------------- + 546 | RuleID | W | C | Encoded bitmap (if C = 0) | 547 + ------ + ----- + ----- + ------------------------- + 548 | 8 bits | 2 bit | 1 bit | 0 to 127 bits | 550 Figure 8: SCHC formats, failed RCS check. 552 5.6.2.4. Receiver-Abort 554 | FPort | LoRaWAN payload | 555 + ------ + -------------------------------------------- + 556 | RuleID | W = b'11 | C = 1 | b'11111 | 0xFF (all 1's) | 557 + ------ + -------- + ------+-------- + ----------------+ 558 | 8 bits | 2 bits | 1 bit | 5 bits | 8 bits | 559 next L2 Word boundary ->| <-- L2 Word --> | 561 Figure 9: Receiver-Abort format. 563 5.6.2.5. SCHC acknowledge request 565 | FPort | LoRaWAN payload | 566 +------- +------------------------- + 567 | RuleID | W | FCN = b'000000 | 568 + ------ + ------ + --------------- + 569 | 8 bits | 2 bits | 6 bits | 571 Figure 10: SCHC ACK REQ format. 573 5.6.3. Downlink fragmentation: From SCHC gateway to a device 575 In that case the device is the fragmentation receiver, and the SCHC 576 gateway the fragmentation transmitter. The following fields are 577 common to all devices. SCHC F/R MUST concatenate FPort and LoRaWAN 578 payload to retrieve the SCHC fragment as described in Section 5.1. 580 o SCHC fragmentation reliability mode: 582 * Unicast downlinks: ACK-Always. 584 * Multicast downlinks: No-ACK, reliability has be be ensured by 585 the upper layer. This feature is OPTIONAL and may not be 586 implemented by SCHC gateway. 588 o RuleID: 8 bits stored in LoRaWAN FPort. 590 o Window index (unicast only): encoded on W=1 bit, as per 591 [I-D.ietf-lpwan-ipv6-static-context-hc]. 593 o DTag: Size is 0 bit, not used 595 o FCN: The FCN field is encoded on N=1 bit, so WINDOW_SIZE = 1 tile 596 (FCN=All-1 is reserved for SCHC). 598 o RCS calculation algorithm: CRC32 using 0xEDB88320 (i.e. the 599 reverse representation of the polynomial used e.g. in the Ethernet 600 standard [RFC3385]), as per 601 [I-D.ietf-lpwan-ipv6-static-context-hc]. 603 o MAX_ACK_REQUESTS: 8 605 As only 1 tile is used, its size can change for each downlink, and 606 will be maximum available MTU. 608 _Note_: The Fpending bit included in LoRaWAN protocol SHOULD NOT be 609 used for SCHC-over-LoRaWAN protocol. It might be set by the Network 610 Server for other purposes but not SCHC needs. 612 5.6.3.1. Regular fragments 614 | FPort | LoRaWAN payload | 615 + ------ + ----------------------------------- + 616 | RuleID | W | FCN = b'0 | Payload | 617 + ------ + ----- + --------- + --------------- + 618 | 8 bits | 1 bit | 1 bit | X bytes | 620 Figure 11: All fragments but the last one. Header size 10 bits, 621 including LoraWAN FPort. 623 5.6.3.2. Last fragment (All-1) 625 | FPort | LoRaWAN payload | 626 + ------ + ----------------------------------------------- + 627 | RuleID | W | FCN = b'1 | RCS | Payload | 628 + ------ + ----- + --------- + ------- + ----------------- + 629 | 8 bits | 1 bit | 1 bit | 32 bits | Last tile, if any | 631 Figure 12: All-1 SCHC ACK detailed format for the last fragment. 633 5.6.3.3. SCHC acknowledge 635 | FPort | LoRaWAN payload | 636 + ------ + ---------------------------------- + 637 | RuleID | W | C = b'1 | Padding b'000000 | 638 + ------ + ----- + ------- + ---------------- + 639 | 8 bits | 1 bit | 1 bit | 6 bits | 641 Figure 13: SCHC ACK format, RCS is correct. 643 5.6.3.4. Receiver-Abort 645 | FPort | LoRaWAN payload | 646 + ------ + ---------------------------------------------- + 647 | RuleID | W = b'1 | C = b'1 | b'111111 | 0xFF (all 1's) | 648 + ------ + ------- + ------- + -------- + --------------- + 649 | 8 bits | 1 bit | 1 bits | 6 bits | 8 bits | 650 next L2 Word boundary ->| <-- L2 Word --> | 652 Figure 14: Receiver-Abort packet (following an all-1 packet with 653 incorrect RCS). 655 Class A and Class B or Class C end-devices do not manage 656 retransmissions and timers in the same way. 658 5.6.3.5. Class A end-devices 660 Class A end-devices can only receive in an RX slot following the 661 transmission of an uplink. Therefore there cannot be a concept of 662 "retransmission timer" for an SCHC gateway. The SCHC gateway cannot 663 initiate communication to a Class A end-device. 665 The device replies with an ACK message to every single fragment 666 received from the SCHC gateway (because the window size is 1). 667 Following the reception of a FCN=0 fragment (fragment that is not the 668 last fragment of the packet or ACK-request, but the end of a window), 669 the device MUST transmit the SCHC ACK fragment until it receives the 670 fragment of the next window. The device SHALL transmit up to 671 MAX_ACK_REQUESTS ACK messages before aborting. The device should 672 transmit those ACK as soon as possible while taking into 673 consideration potential local radio regulation on duty-cycle, to 674 progress the fragmentation session as quickly as possible. The ACK 675 bitmap is 1 bit long and is always 1. 677 Following the reception of an FCN=All-1 fragment (the last fragment 678 of a datagram) and if the RCS is correct, the device SHALL transmit 679 the ACK with the "RCS is correct" indicator bit set (C=1). This 680 message might be lost therefore the SCHC gateway MAY request a 681 retransmission of this ACK in the next downlink. The device SHALL 682 keep this ACK message in memory until it receives a downlink, on SCHC 683 FPortDown from the SCHC gateway different from an ACK-request: it 684 indicates that the SCHC gateway has received the ACK message. 686 Following the reception of a FCN=All-1 fragment (the last fragment of 687 a datagram), if all fragments have been received and the RCS is not 688 correct, the device SHALL transmit a Receiver-Abort fragment. The 689 device SHALL keep this Abort message in memory until it receives a 690 downlink, on SCHC FPortDown, from the SCHC gateway different from an 691 ACK-request indicating that the SCHC gateway has received the Abort 692 message. The fragmentation receiver (device) does not implement 693 retransmission timer and inactivity timer. 695 The fragmentation sender (the SCHC gateway) implements an inactivity 696 timer with a default duration of 12 hours. Once a fragmentation 697 session is started, if the SCHC gateway has not received any ACK or 698 Receiver-Abort message 12 hours after the last message from the 699 device was received, the SCHC gateway MAY flush the fragmentation 700 context. For devices with very low transmission rates (example 1 701 packet a day in normal operation) , that duration may be extended, 702 but this is application specific. 704 5.6.3.6. Class B or Class C end-devices 706 Class B and Class C end-devices can receive in scheduled RX slots or 707 in RX slots following the transmission of an uplink. The device 708 replies with an ACK message to every single fragment received from 709 the SCHC gateway (because the window size is 1). Following the 710 reception of an FCN=0 fragment (fragment that is not the last 711 fragment of the packet or ACK-request), the device MUST always 712 transmit the corresponding SCHC ACK message even if that fragment has 713 already been received. The ACK bitmap is 1 bit long and is always 1. 714 If the SCHC gateway receives this ACK, it proceeds to send the next 715 window fragment. If the retransmission timer elapses and the SCHC 716 gateway has not received the ACK of the current window it retransmits 717 the last fragment. The SCHC gateway tries retransmitting up to 718 MAX_ACK_REQUESTS times before aborting. 720 Following the reception of an FCN=All-1 fragment (the last fragment 721 of a datagram) and if the RCS is correct, the device SHALL transmit 722 the ACK with the "RCS is correct" indicator bit set. If the SCHC 723 gateway receives this ACK, the current fragmentation session has 724 succeeded and its context can be cleared. 726 If the retransmission timer elapses and the SCHC gateway has not 727 received the SCHC ACK it retransmits the last fragment with the 728 payload (not an ACK-request without payload). The SCHC gateway tries 729 retransmitting up to MAX_ACK_REQUESTS times before aborting. 731 Following the reception of an FCN=All-1 fragment (the last fragment 732 of a datagram), if all fragments have been received and if the RCS is 733 NOT correct, the device SHALL transmit a Receiver-Abort fragment. 734 The retransmission timer is used by the SCHC gateway (the sender), 735 the optimal value is very much application specific but here are some 736 recommended default values. For Class B end-devices, this timer 737 trigger is a function of the periodicity of the Class B ping slots. 738 The RECOMMENDED value is equal to 3 times the Class B ping slot 739 periodicity. For Class C end-devices which are nearly constantly 740 receiving, the RECOMMENDED value is 30 seconds. This means that the 741 end-device shall try to transmit the ACK within 30 seconds of the 742 reception of each fragment. The inactivity timer is implemented by 743 the end-device to flush the context in-case it receives nothing from 744 the SCHC gateway over an extended period of time. The RECOMMENDED 745 value is 12 hours for both Class B and Class C end-devices. 747 6. Security considerations 749 This document is only providing parameters that are expected to be 750 better suited for LoRaWAN networks for 751 [I-D.ietf-lpwan-ipv6-static-context-hc]. As such, this document does 752 not contribute to any new security issues in addition to those 753 identified in [I-D.ietf-lpwan-ipv6-static-context-hc]. 755 Acknowledgements 757 Thanks to all those listed in the Contributors section for the 758 excellent text, insightful discussions, reviews and suggestions. 760 Contributors 762 Contributors ordered by family name. 764 o ins: V. Audebert name: Vincent AUDEBERT org: EDF R&D street: 7 bd 765 Gaspard Monge city: 91120 PALAISEAU country: FRANCE email: 766 vincent.audebert@edf.fr 768 o ins: J. Catalano name: Julien Catalano org: Kerlink street: 1 rue 769 Jacqueline Auriol city: 35235 Thorigne-Fouillard country: France 770 email: j.catalano@kerlink.fr 772 o ins: M. Coracin name: Michael Coracin org: Semtech street: 14 773 Chemin des Clos city: Meylan country: France email: 774 mcoracin@semtech.com 776 o ins: M. Le Gourrierec name: Marc Le Gourrierec org: SagemCom 777 street: 250 Route de l'Empereur city: 92500 Rueil Malmaison 778 country: FRANCE email: marc.legourrierec@sagemcom.com 780 o ins: N. Sornin name: Nicolas Sornin org: Semtech street: 14 781 Chemin des Clos city: Meylan country: France email: 782 nsornin@semtech.com 784 o ins: A. Yegin name: Alper Yegin org: Actility street: . city: 785 Paris, Paris country: France email: alper.yegin@actility.com 787 9. References 789 9.1. Normative References 791 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 792 Requirement Levels", BCP 14, RFC 2119, 793 DOI 10.17487/RFC2119, March 1997, 794 . 796 [RFC3385] Sheinwald, D., Satran, J., Thaler, P., and V. Cavanna, 797 "Internet Protocol Small Computer System Interface (iSCSI) 798 Cyclic Redundancy Check (CRC)/Checksum Considerations", 799 RFC 3385, DOI 10.17487/RFC3385, September 2002, 800 . 802 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 803 Architecture", RFC 4291, DOI 10.17487/RFC4291, February 804 2006, . 806 [RFC4944] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler, 807 "Transmission of IPv6 Packets over IEEE 802.15.4 808 Networks", RFC 4944, DOI 10.17487/RFC4944, September 2007, 809 . 811 [RFC5795] Sandlund, K., Pelletier, G., and L-E. Jonsson, "The RObust 812 Header Compression (ROHC) Framework", RFC 5795, 813 DOI 10.17487/RFC5795, March 2010, 814 . 816 [RFC7136] Carpenter, B. and S. Jiang, "Significance of IPv6 817 Interface Identifiers", RFC 7136, DOI 10.17487/RFC7136, 818 February 2014, . 820 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 821 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 822 May 2017, . 824 [RFC8376] Farrell, S., Ed., "Low-Power Wide Area Network (LPWAN) 825 Overview", RFC 8376, DOI 10.17487/RFC8376, May 2018, 826 . 828 9.2. Informative References 830 [I-D.ietf-lpwan-ipv6-static-context-hc] 831 Minaburo, A., Toutain, L., Gomez, C., Barthel, D., and J. 832 Zuniga, "Static Context Header Compression (SCHC) and 833 fragmentation for LPWAN, application to UDP/IPv6", draft- 834 ietf-lpwan-ipv6-static-context-hc-22 (work in progress), 835 October 2019. 837 [lora-alliance-remote-multicast-set] 838 Alliance, L., "LoRaWAN Remote Multicast Setup 839 Specification Version 1.0.0", . 843 [lora-alliance-spec] 844 Alliance, L., "LoRaWAN Specification Version V1.0.3", 845 . 848 Appendix A. Examples 850 A.1. Uplink - Compression example - No fragmentation 852 Figure 15 is representing an applicative payload going through SCHC, 853 no fragmentation required 855 An applicative payload of 78 bytes is passed to SCHC compression layer 856 using rule 1, allowing to compress it to 40 bytes and 5 bits: 1 byte 857 ruleID, 21 bits residue + 37 bytes payload. 859 | RuleID | Compression residue | Payload | Padding=b'000 | 860 + ------ + ------------------- + --------- + ------------- + 861 | 1 | 21 bits | 38 bytes | 3 bits | 863 The current LoRaWAN MTU is 51 bytes, although 2 bytes FOpts are used by 864 LoRaWAN protocol: 49 bytes are available for SCHC payload; no need for 865 fragmentation. The payload will be transmitted through FPort = 1 867 | LoRaWAN Header | LoRaWAN payload (40 bytes) | 868 + ------------------------- + --------------------------------------- + 869 | | FOpts | RuleID=1 | Compression | Payload | Padding=b'000 | 870 | | | | residue | | | 871 + ---- + ------- + -------- + ----------- + --------- + ------------- + 872 | XXXX | 2 bytes | 1 byte | 21 bits | 37 bytes | 3 bits | 874 Figure 15: Uplink example: compression without fragmentation 876 A.2. Uplink - Compression and fragmentation example 878 Figure 16 is representing an applicative payload going through SCHC, 879 with fragmentation. 881 An applicative payload of 478 bytes is passed to SCHC compression layer 882 using rule 1, allowing to compress it to 282 bytes and 5 bits: 1 byte 883 ruleID, 21 bits residue + 279 bytes payload. 885 | RuleID | Compression residue | Payload | 886 + ------ + ------------------- + --------- + 887 | 1 | 21 bits | 279 bytes | 889 The current LoRaWAN MTU is 11 bytes, 0 bytes FOpts are used by LoRaWAN 890 protocol: 11 bytes are available for SCHC payload + 1 byte FPort field. 891 SCHC header is 2 bytes (including FPort) so 1 tile is sent in first 892 fragment. 894 | LoRaWAN Header | LoRaWAN payload (11 bytes) | 895 + -------------------------- + -------------------------- + 896 | | RuleID=20 | W | FCN | 1 tile | 897 + -------------- + --------- + ----- + ------ + --------- + 898 | XXXX | 1 byte | 0 0 | 62 | 10 bytes | 900 Content of the tile is: 901 | RuleID | Compression residue | Payload | 902 + ------ + ------------------- + ----------------- + 903 | 1 | 21 bits | 6 byte + 3 bits | 905 Next transmission MTU is 11 bytes, although 2 bytes FOpts are used by 906 LoRaWAN protocol: 9 bytes are available for SCHC payload + 1 byte FPort 907 field, a tile does not fit inside so LoRaWAN stack will send only FOpts. 909 Next transmission MTU is 242 bytes, 4 bytes FOpts. 23 tiles are transmitted: 911 | LoRaWAN Header | LoRaWAN payload (231 bytes) | 912 + --------------------------------------+ --------------------------- + 913 | | FOpts | RuleID=20 | W | FCN | 23 tiles | 914 + -------------- + ------- + ---------- + ----- + ----- + ----------- + 915 | XXXX | 4 bytes | 1 byte | 0 0 | 61 | 230 bytes | 917 Next transmission MTU is 242 bytes, no FOpts. All 5 remaining tiles are 918 transmitted, the last tile is only 2 bytes + 5 bits. Padding is added for 919 the remaining 3 bits. 921 | LoRaWAN Header | LoRaWAN payload (44 bytes) | 922 + ---- + -----------+ ----------------------------------------------- + 923 | | RuleID=20 | W | FCN | 5 tiles | Padding=b'000 | 924 + ---- + ---------- + ----- + ----- + ----------------- + ------------- + 925 | XXXX | 1 byte | 0 0 | 38 | 42 bytes + 5 bits | 3 bits | 927 All packets have been received by the SCHC gateway, computed RCS is 928 correct so the following ACK is sent to the device: 930 | LoRaWAN Header | LoRaWAN payload | 931 + -------------- + --------- + ------------------- + 932 | | RuleID=20 | W | C | Padding | 933 + -------------- + --------- + ----- + - + ------- + 934 | XXXX | 1 byte | 0 0 | 1 | 5 bits | 936 Figure 16: Uplink example: compression and fragmentation 938 A.3. Downlink 940 An applicative payload of 443 bytes is passed to SCHC compression layer 941 using rule 1, allowing to compress it to 130 bytes and 5 bits: 1 byte 942 ruleId, 21 bits residue + 127 bytes payload. 944 | RuleID | Compression residue | Payload | 945 + ------ + ------------------- + --------- + 946 | 1 | 21 bits | 127 bytes | 948 The current LoRaWAN MTU is 51 bytes, no FOpts are used by LoRaWAN 949 protocol: 48 bytes are available for SCHC payload + FPort field => it 950 has to be fragmented. 952 | LoRaWAN Header | LoRaWAN payload (51 bytes) | 953 + ---- + ---------- + --------------------------------------------- + 954 | | RuleID=21 | W | FCN | 1 tile | Padding=b'000000 | 955 + ---- + ---------- + --- + --- + -------------- + ---------------- + 956 | XXXX | 1 byte | 0 | 0 | 50 bytes | 6 bits | 958 Content of the tile is: 959 | RuleID | Compression residue | Payload | 960 + ------ + ------------------- + ------------------ + 961 | 1 | 21 bits | 46 bytes + 3 bits | 963 The receiver answers with an SCHC ACK 965 | FPortDown | LoRaWAN payload | 966 + --------- + ---------------------------------- + 967 | RuleID | W = 0 | C = b'1 | Padding=b'000000 | 968 + --------- + ----- + ------- + ---------------- + 969 | 1 byte | 1 bit | 1 bit | 6 bits | 971 The second downlink is sent, two FOpts: 973 | LoRaWAN Header | LoRaWAN payload (49 bytes) | 974 + --------------------------- + ------------------ + ---------------- + 975 | | FOpts | RuleID=21 | W | FCN | 1 tile | Padding=b'000000 | 976 + ---- + ------- + ---------- + - + --- + -------- + ---------------- + 977 | XXXX | 2 bytes | 1 byte | 1 | 0 | 48 bytes | 6 bits | 978 The receiver answers with an SCHC ACK 980 | FPortDown | LoRaWAN payload | 981 + --------- + ---------------------------------- + 982 | RuleID | W = 1 | C = b'1 | Padding=b'000000 | 983 + --------- + ----- + ------- + ---------------- + 984 | 1 byte | 1 bit | 1 bit | 6 bits | 986 The last downlink is sent, no FOpts: 988 | LoRaWAN Header | LoRaWAN payload (33 bytes) | 989 + ---- + ---------- + ----------------------------------------------- + 990 | | RuleID=21 | W | FCN | 1 tile | Padding=b'0 | 991 + ---- + ---------- + --- + --- + --------------------- + ----------- + 992 | XXXX | 1 byte | 0 | 1 | 32 bytes + 5 bits | 1 bit | 994 The receiver answers with an SCHC ACK 996 | FPortDown | LoRaWAN payload | 997 + --------- + ---------------------------------- + 998 | RuleID | W = 0 | C = b'1 | Padding=b'000000 | 999 + --------- + ----- + ------- + ---------------- + 1000 | 1 byte | 1 bit | 1 bit | 6 bits | 1002 Figure 17: Downlink example: compression and fragmentation 1004 Appendix B. Note 1006 Authors' Addresses 1008 Olivier Gimenez (editor) 1009 Semtech 1010 14 Chemin des Clos 1011 Meylan 1012 France 1014 Email: ogimenez@semtech.com 1015 Ivaylo Petrov (editor) 1016 Acklio 1017 1137A Avenue des Champs Blancs 1018 35510 Cesson-Sevigne Cedex 1019 France 1021 Email: ivaylo@ackl.io