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