idnits 2.17.1 draft-ietf-lpwan-schc-over-lorawan-05.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 14 instances of too long lines in the document, the longest one being 16 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 (December 20, 2019) is 1588 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC3385' is defined on line 840, but no explicit reference was found in the text == Unused Reference: 'RFC4944' is defined on line 854, but no explicit reference was found in the text == Unused Reference: 'RFC5795' is defined on line 859, but no explicit reference was found in the text == Unused Reference: 'RFC7136' is defined on line 864, but no explicit reference was found in the text 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: June 22, 2020 Acklio 6 December 20, 2019 8 Static Context Header Compression (SCHC) over LoRaWAN 9 draft-ietf-lpwan-schc-over-lorawan-05 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 June 22, 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 . . . . . . . . . . . . . . . . . . . . . . . . . 11 71 5.5. Decompression . . . . . . . . . . . . . . . . . . . . . . 11 72 5.6. Fragmentation . . . . . . . . . . . . . . . . . . . . . . 11 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 14 76 6. Security considerations . . . . . . . . . . . . . . . . . . . 17 77 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 18 78 Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 18 79 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 18 80 9.1. Normative References . . . . . . . . . . . . . . . . . . 18 81 9.2. Informative References . . . . . . . . . . . . . . . . . 20 82 Appendix A. Examples . . . . . . . . . . . . . . . . . . . . . . 20 83 A.1. Uplink - Compression example - No fragmentation . . . . . 20 84 A.2. Uplink - Compression and fragmentation example . . . . . 21 85 A.3. Downlink . . . . . . . . . . . . . . . . . . . . . . . . 22 86 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 24 88 1. Introduction 90 The Static Context Header Compression (SCHC) specification 91 [I-D.ietf-lpwan-ipv6-static-context-hc] describes generic header 92 compression and fragmentation techniques that can be used on all 93 LPWAN (Low Power Wide Area Networks) technologies defined in 94 [RFC8376]. Even though those technologies share a great number of 95 common features like star-oriented topologies, network architecture, 96 devices with mostly quite predictable communications, etc; they do 97 have some slight differences in respect of payload sizes, 98 reactiveness, etc. 100 SCHC gives a generic framework that enables those devices to 101 communicate with other Internet networks. However, for efficient 102 performance, some parameters and modes of operation need to be set 103 appropriately for each of the LPWAN technologies. 105 This document describes the efficient parameters and modes of 106 operation when SCHC is used over LoRaWAN networks. 108 2. Terminology 110 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 111 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 112 "OPTIONAL" in this document are to be interpreted as described in BCP 113 14 [RFC2119] [RFC8174] when, and only when, they appear in all 114 capitals, as shown here. 116 This section defines the terminology and acronyms used in this 117 document. For all other definitions, please look up the SCHC 118 specification [I-D.ietf-lpwan-ipv6-static-context-hc]. 120 o DevEUI: an IEEE EUI-64 identifier used to identify the end-device 121 during the procedure while joining the network (Join Procedure) 123 o DevAddr: a 32-bit non-unique identifier assigned to an end-device 124 statically or dynamically after a Join Procedure (depending on the 125 activation mode) 127 o RCS: Reassembly Check Sequence. Used to verify the integrity of 128 the fragmentation-reassembly process 130 o TBD: all significant LoRaWAN-related terms. 132 o OUI: Organisation Unique Identifier. IEEE assigned prefix for EUI 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 It defines: 142 1. Compression mechanisms to avoid transport of known data by both 143 sender and receiver over the air. Known data are part of the 144 "context" 146 2. Fragmentation mechanisms to allow SCHC Packet transportation on 147 small, and potentially variable, MTU 149 Context exchange or pre-provisioning is out of scope of this 150 document. 152 Dev App 153 +----------------+ +----+ +----+ +----+ 154 | App1 App2 App3 | |App1| |App2| |App3| 155 | | | | | | | | 156 | UDP | |UDP | |UDP | |UDP | 157 | IPv6 | |IPv6| |IPv6| |IPv6| 158 | | | | | | | | 159 |SCHC C/D and F/R| | | | | | | 160 +--------+-------+ +----+ +----+ +----+ 161 | +---+ +----+ +----+ +----+ . . . 162 +~ |RGW| === |NGW | == |SCHC| == |SCHC|...... Internet .... 163 +---+ +----+ |F/R | |C/D | 164 +----+ +----+ 166 Figure 1: Architecture 168 Figure 1 represents the architecture for compression/decompression, 169 it is based on [RFC8376] terminology. The Device is sending 170 applications flows using IPv6 or IPv6/UDP protocols. These flow 171 might be compressed by an Static Context Header Compression 172 Compressor/Decompressor (SCHC C/D) to reduce headers size and 173 fragmented (SCHC F/R). The resulting information is sent on a layer 174 two (L2) frame to an LPWAN Radio Gateway (RGW) which forwards the 175 frame to a Network Gateway (NGW). The NGW sends the data to a SCHC 176 F/R for defragmentation, if required, then C/D for decompression 177 which shares the same rules with the device. The SCHC F/R and C/D 178 can be located on the Network Gateway (NGW) or in another place as 179 long as a tunnel is established between the NGW and the SCHC F/R, 180 then SCHC F/R and SCHC C/D. The SCHC C/D in both sides MUST share 181 the same set of rules. After decompression, the packet can be sent 182 on the Internet to one or several LPWAN Application Servers (App). 184 The SCHC F/R and SCHC C/D process is bidirectional, so the same 185 principles can be applied in the other direction. 187 In a LoRaWAN network, the RG is called a Gateway, the NGW is Network 188 Server, and the SCHC C/D is an Application Server. It can be 189 provided by the Network Server or any third party software. Figure 1 190 can be mapped in LoRaWAN terminology to: 192 Dev App 193 +--------------+ +----+ +----+ +----+ 194 |App1 App2 App3| |App1| |App2| |App3| 195 | | | | | | | | 196 | UDP | |UDP | |UDP | |UDP | 197 | IPv6 | |IPv6| |IPv6| |IPv6| 198 | | | | | | | | 199 |SCHC C/D & F/R| | | | | | | 200 +-------+------+ +----+ +----+ +----+ 201 | +-------+ +-------+ +-----------+ . . . 202 +~ |Gateway| === |Network| == |Application|..... Internet .... 203 +-------+ |server | |server | 204 +-------+ | F/R - C/D | 205 +-----------+ 207 Figure 2: SCHC Architecture mapped to LoRaWAN 209 4. LoRaWAN Architecture 211 An overview of LoRaWAN [lora-alliance-spec] protocol and architecture 212 is described in [RFC8376]. The mapping between the LPWAN 213 architecture entities as described in 214 [I-D.ietf-lpwan-ipv6-static-context-hc] and the ones in 215 [lora-alliance-spec] is as follows: 217 o Devices (Dev) are the end-devices or hosts (e.g. sensors, 218 actuators, etc.). There can be a very high density of devices per 219 radio gateway (LoRaWAN gateway). This entity maps to the LoRaWAN 220 End-Device. 222 o The Radio Gateway (RGW), which is the endpoint of the constrained 223 link. This entity maps to the LoRaWAN Gateway. 225 o The Network Gateway (NGW) is the interconnection node between the 226 Radio Gateway and the Internet. This entity maps to the LoRaWAN 227 Network Server. 229 o Application Server (App). The same terminology is used in LoRaWAN. 230 In that case, the application server will be the SCHC gateway, doing 231 C/D and F/R. 233 () () () | +------+ 234 () () () () / \ +---------+ | Join | 235 () () () () () / \======| ^ |===|Server| +-----------+ 236 () () () | | <--|--> | +------+ |Application| 237 () () () () / \==========| v |=============| Server | 238 () () () / \ +---------+ +-----------+ 239 End-Devices Gateways Network Server 241 Figure 3: LPWAN Architecture 243 SCHC C/D (Compressor/Decompressor) and SCHC F/R (Fragmentation/ 244 Reassembly) are performed on the LoRaWAN End-Device and the 245 Application Server (called SCHC gateway). While the point-to-point 246 link between the End-Device and the Application Server constitutes 247 single IP hop, the ultimate end-point of the IP communication may be 248 an Internet node beyond the Application Server. In other words, the 249 LoRaWAN Application Server (SCHC gateway) acts as the first hop IP 250 router for the End-Device. The Application Server and Network Server 251 may be co-located, which effectively turns the Network/Application 252 Server into the first hop IP router. 254 4.1. End-Device classes (A, B, C) and interactions 256 The LoRaWAN MAC layer supports 3 classes of end-devices named A, B 257 and C. All end-devices implement the Class A, some end-devices may 258 implement Class B or Class C. Class B and Class C are mutually 259 exclusive. 261 o Class A: The Class A is the simplest class of end-devices. The 262 end-device is allowed to transmit at any time, randomly selecting 263 a communication channel. The network may reply with a downlink in 264 one of the 2 receive windows immediately following the uplinks. 265 Therefore, the network cannot initiate a downlink, it has to wait 266 for the next uplink from the end-device to get a downlink 267 opportunity. The Class A is the lowest power end-device class. 269 o Class B: Class B end-devices implement all the functionalities of 270 Class A end-devices, but also schedule periodic listen windows. 271 Therefore, opposed to the Class A end-devices, Class B end-devices 272 can receive downlinks that are initiated by the network and not 273 following an uplink. There is a trade-off between the periodicity 274 of those scheduled Class B listen windows and the power 275 consumption of the end-device. The lower the downlink latency, 276 the higher the power consumption. 278 o Class C: Class C end-devices implement all the functionalities of 279 Class A end-devices, but keep their receiver open whenever they 280 are not transmitting. Class C end-devices can receive downlinks 281 at any time at the expense of a higher power consumption. 282 Battery-powered end-devices can only operate in Class C for a 283 limited amount of time (for example for a firmware upgrade over- 284 the-air). Most of the Class C end-devices are grid powered (for 285 example Smart Plugs). 287 4.2. End-Device addressing 289 LoRaWAN end-devices use a 32-bit network address (devAddr) to 290 communicate with the network over-the-air, this address might not be 291 unique in a LoRaWAN network; end-devices using the same devAddr are 292 distinguished by the Network Server based on the cryptographic 293 signature appended to every LoRaWAN frame. 295 To communicate with the SCHC gateway the Network Server MUST identify 296 the end-devices by a unique 64-bit device identifier called the 297 devEUI. 299 The devEUI is assigned to the end-device during the manufacturing 300 process by the end-device's manufacturer. It is built like an 301 Ethernet MAC address by concatenating the manufacturer's IEEE OUI 302 field with a vendor unique number. e.g.: 24-bit OUI is concatenated 303 with a 40-bit serial number. The Network Server translates the 304 devAddr into a devEUI in the uplink direction and reciprocally on the 305 downlink direction. 307 +--------+ +----------+ +---------+ +----------+ 308 | End- | <=====> | Network | <====> | SCHC | <========> | Internet | 309 | Device | devAddr | Server | devEUI | Gateway | IPv6/UDP | | 310 +--------+ +----------+ +---------+ +----------+ 312 Figure 4: LoRaWAN addresses 314 4.3. General Message Types 316 o Confirmed messages: The sender asks the receiver to acknowledge 317 the message. 319 o Unconfirmed messages: The sender does not ask the receiver to 320 acknowledge the message. 322 As SCHC defines its own acknowledgment mechanisms, SCHC does not 323 require to use confirmed messages. 325 4.4. LoRaWAN MAC Frames 327 o JoinRequest: This message is used by an end-device to join a 328 network. It contains the end-device's unique identifier devEUI 329 and a random nonce that will be used for session key derivation. 331 o JoinAccept: To on-board an end-device, the Network Server responds 332 to the JoinRequest end-device's message with a JoinAccept message. 333 That message is encrypted with the end-device's AppKey and 334 contains (amongst other fields) the major network's settings and a 335 network random nonce used to derive the session keys. 337 o Data: MAC and application data. Application data are protected 338 with AES-128 encryption, MAC related data are AES-128 encrypted 339 with another key. 341 4.5. Unicast and multicast technology 343 LoRaWAN technology supports unicast downlinks, but also multicast: a 344 packet send over LoRaWAN radio link can be received by several 345 devices. It is useful to address many end-devices with same content, 346 either a large binary file (firmware upgrade), or same command (e.g: 347 lighting control). As IPv6 is also a multicast technology this 348 feature can be used to address a group of devices. 350 _Note 1_: IPv6 multicast addresses must be defined as per [RFC4291]. 351 LoRaWAN multicast group definition in a network server and the 352 relation between those groups and IPv6 groupID are out of scope of 353 this document. 355 _Note 2_: LoRa Alliance defined [lora-alliance-remote-multicast-set] 356 as RECOMMENDED way to setup multicast groups on devices and create a 357 synchronized reception window. 359 5. SCHC-over-LoRaWAN 361 5.1. LoRaWAN FPort 363 The LoRaWAN MAC layer features a frame port field in all frames. 364 This field (FPort) is 8 bits long and the values from 1 to 223 can be 365 used. It allows LoRaWAN networks and applications to identify data. 367 The FPort field is part of the SCHC Message, as shown in Figure 5. 368 The SCHC C/D and the SCHC F/R SHALL concatenate the FPort field with 369 the LoRaWAN payload to retrieve their payload as it is used as a part 370 of the RuleID field. 372 | FPort | LoRaWAN payload | 373 + ------------------------ + 374 | SCHC payload | 376 Figure 5: SCHC Message in LoRaWAN 378 A fragmentation session with application payload transferred from 379 device to server, is called uplink fragmentation session. It uses an 380 FPort for data uplink and its associated SCHC control downlinks, 381 named FPortUp in this document. The other way, a fragmentation 382 session with application payload transferred from server to device, 383 is called downlink fragmentation session. It uses another FPort for 384 data downlink and its associated SCHC control uplinks, named 385 FPortDown in this document. 387 All ruleId can use arbitrary values inside the FPort range allowed by 388 LoRaWAN specification and MUST be shared by the end-device and SCHC 389 gateway prior to the communication with the selected rule. The 390 uplink and downlink fragmentation FPorts MUST be different. 392 5.2. Rule ID management 394 RuleID MUST be 8 bits, encoded in the LoRaWAN FPort as described in 395 Section 5.1. LoRaWAN supports up to 223 application FPorts in the 396 range [1;223] as defined in section 4.3.2 of [lora-alliance-spec], it 397 implies that RuleID MSB SHOULD be inside this range. An application 398 can send non SCHC traffic by using FPort values differents from the 399 ones used for SCHC. 401 In order to improve interoperability RECOMMENDED fragmentation RuleID 402 values are: 404 o RuleID = 20 (8-bit) for uplink fragmentation, named FPortUp 406 o RuleID = 21 (8-bit) for downlink fragmentation, named FPortDown 408 o RuleID = 22 (8-bit) for which SCHC compression was not possible 409 (no matching rule was found) 411 The remaining RuleIDs are available for compression. RuleIDs are 412 shared between uplink and downlink sessions. A RuleID not in the 413 set(s) of FPortUp or FPortDown means that the fragmentation is not 414 used, thus, on reception, the SCHC Message MUST be sent to the C/D 415 layer. 417 The only uplink messages using the FPortDown port are the 418 fragmentation SCHC control messages of a downlink fragmentation 419 session (for example, SCHC ACKs). Similarly, the only downlink 420 messages using the FPortUp port are the fragmentation SCHC control 421 messages of an uplink fragmentation session. 423 An application can have multiple fragmentation sessions between a 424 device and one or several SCHC gateways. A set of FPort values is 425 REQUIRED for each SCHC gateway instance the device is required to 426 communicate with. 428 The mechanism for sharing those RuleID values is outside the scope of 429 this document. 431 5.3. IID computation 433 In order to mitigate risks described in [RFC8064] and [RFC8065] IID 434 MUST be created regarding the following algorithm: 436 1. key = LoRaWAN AppSKey 438 2. cmac = aes128_cmac(key, devEui) 440 3. IID = cmac[0..7] 442 aes128_cmac algorithm is described in [RFC4493]. It has been chosen 443 as it is already used by devices for LoRaWAN procotol. 445 As AppSKey is renewed each time a device joins or rejoins a network, 446 the IID will change over time; this mitigates privacy, location 447 tracking and correlation over time risks. Rejoin periodicity is 448 defined at the application level. 450 Address scan risk is mitigated thanks to AES-128, which provides 451 enough entropy bits of the IID. 453 Using this algorithm will also ensure that there is not correlation 454 between the hardware identifier (IEEE-64 devEUI) and the IID, so an 455 attacker can not use manufacturer OUI to target devices. 457 Exemple with: 459 o devEui: 0x1122334455667788 461 o appSKey: 0x00AABBCCDDEEFF00AABBCCDDEEFFAABB 463 1. key: 0x00AABBCCDDEEFF00AABBCCDDEEFFAABB 464 2. cmac: 0x4E822D9775B2649928F82066AF804FEC 465 3. IID: 0x28F82066AF804FEC 467 5.4. Padding 469 All padding bits MUST be 0. 471 5.5. Decompression 473 SCHC C/D MUST concatenate FPort and LoRaWAN payload to retrieve the 474 SCHC Packet as per Section 5.1. 476 RuleIDs matching FPortUp and FPortDown are reserved for SCHC 477 Fragmentation. 479 5.6. Fragmentation 481 The L2 Word Size used by LoRaWAN is 1 byte (8 bits). The SCHC 482 fragmentation over LoRaWAN uses the ACK-on-Error mode for uplink 483 fragmentation and Ack-Always mode for downlink fragmentation. A 484 LoRaWAN end-device cannot support simultaneous interleaved 485 fragmentation sessions in the same direction (uplink or downlink). 487 The fragmentation parameters are different for uplink and downlink 488 fragmentation sessions and are successively described in the next 489 sections. 491 5.6.1. DTag 493 A LoRaWAN device cannot interleave several fragmented SCHC datagrams 494 on the same FPort. This field is not used and its size is 0. 496 Note: The device can still have several parallel fragmentation 497 sessions with one or more SCHC gateway(s) thanks to distinct sets of 498 FPorts, cf Section 5.2 500 5.6.2. Uplink fragmentation: From device to SCHC gateway 502 In that case the device is the fragmentation transmitter, and the 503 SCHC gateway the fragmentation receiver. A single fragmentation rule 504 is defined. SCHC F/R MUST concatenate FPort and LoRaWAN payload to 505 retrieve the SCHC Packet, as per Section 5.1. 507 o SCHC header size is two bytes (the FPort byte + 1 additional 508 byte). 510 o RuleID: 8 bits stored in LoRaWAN FPort. 512 o SCHC fragmentation reliability mode: "ACK-on-Error" 514 o DTag: Size is 0 bit, not used 515 o FCN: The FCN field is encoded on N = 6 bits, so WINDOW_SIZE = 63 516 tiles are allowed in a window 518 o Window index: encoded on W = 2 bits. So 4 windows are available. 520 o RCS: Use recommended calculation algorithm in 521 [I-D.ietf-lpwan-ipv6-static-context-hc]. 523 o MAX_ACK_REQUESTS: 8 525 o Tile: size is 10 bytes 527 o Retransmission timer: LoRaWAN end-devices MUST NOT implement a 528 "retransmission timer", this changes the specification of 529 [I-D.ietf-lpwan-ipv6-static-context-hc], see Section 5.6.3.5. It 530 must transmit MAX_ACK_REQUESTS time the SCHC ACK REQ at it own 531 timing; ie the periodicity between retransmission of SCHC ACK REQs 532 is device specific and can vary depending on other application 533 uplinks and regulations. 535 o Inactivity timer: The SCHC gateway implements an "inactivity 536 timer". The default RECOMMENDED duration of this timer is 12 537 hours; this value is mainly driven by application requirements and 538 MAY be changed by the application. 540 o Last tile: The last tile MUST NOT be carried in the All-1 541 fragment. 543 o Penultimate tile MUST be equal to the regular size. 545 With this set of parameters, the SCHC fragment header is 16 bits, 546 including FPort; payload overhead will be 8 bits as FPort is already 547 a part of LoRaWAN payload. MTU is: _4 windows * 63 tiles * 10 bytes 548 per tile = 2520 bytes_ 550 _Note_: As LoRaWAN is a radio communication, it is RECOMMENDED for an 551 implementation to use ACK mechanism at the end of each window: 553 o SCHC receiver sends an SCHC ACK after every window even if there 554 is no missing tiles. 556 o SCHC sender waits for the SCHC ACK from the SCHC receiver before 557 sending tiles from next window. If the SCHC ACK is not received 558 it should send an SCHC ACK REQ up to MAX_ACK_REQUESTS time as 559 described previously. 561 This OPTIONAL feature will prevent a device to transmit full payload 562 if the network can not be reach, thus save battery life. 564 5.6.2.1. Regular fragments 566 | FPort | LoRaWAN payload | 567 + ------ + ------------------------- + 568 | RuleID | W | FCN | Payload | 569 + ------ + ------ + ------ + ------- + 570 | 8 bits | 2 bits | 6 bits | | 572 Figure 6: All fragments except the last one. SCHC header size is 16 573 bits, including LoRaWAN FPort. 575 5.6.2.2. Last fragment (All-1) 577 | FPort | LoRaWAN payload | 578 + ------ + ---------------------------- + 579 | RuleID | W | FCN=All-1 | RCS | 580 + ------ + ------ + --------- + ------- + 581 | 8 bits | 2 bits | 6 bits | 32 bits | 583 Figure 7: All-1 fragment detailed format for the last fragment. 585 5.6.2.3. SCHC ACK 587 | FPort | LoRaWAN payload | 588 + ------ + ----------------------------------------- + 589 | RuleID | W | C | Encoded bitmap (if C = 0) | 590 + ------ + ----- + ----- + ------------------------- + 591 | 8 bits | 2 bit | 1 bit | 0 to 63 bits | 593 Figure 8: SCHC ACK format, failed RCS check. 595 5.6.2.4. Receiver-Abort 597 | FPort | LoRaWAN payload | 598 + ------ + -------------------------------------------- + 599 | RuleID | W = b'11 | C = 1 | b'11111 | 0xFF (all 1's) | 600 + ------ + -------- + ------+-------- + ----------------+ 601 | 8 bits | 2 bits | 1 bit | 5 bits | 8 bits | 602 next L2 Word boundary ->| <-- L2 Word --> | 604 Figure 9: Receiver-Abort format. 606 5.6.2.5. SCHC acknowledge request 608 | FPort | LoRaWAN payload | 609 +------- +------------------------- + 610 | RuleID | W | FCN = b'000000 | 611 + ------ + ------ + --------------- + 612 | 8 bits | 2 bits | 6 bits | 614 Figure 10: SCHC ACK REQ format. 616 5.6.3. Downlink fragmentation: From SCHC gateway to a device 618 In that case the device is the fragmentation receiver, and the SCHC 619 gateway the fragmentation transmitter. The following fields are 620 common to all devices. SCHC F/R MUST concatenate FPort and LoRaWAN 621 payload to retrieve the SCHC Packet as described in Section 5.1. 623 o SCHC fragmentation reliability mode: 625 * Unicast downlinks: ACK-Always. 627 * Multicast downlinks: No-ACK, reliability has to be ensured by 628 the upper layer. This feature is OPTIONAL and may not be 629 implemented by SCHC gateway. 631 o RuleID: 8 bits stored in LoRaWAN FPort. 633 o Window index (unicast only): encoded on W=1 bit, as per 634 [I-D.ietf-lpwan-ipv6-static-context-hc]. 636 o DTag: Size is 0 bit, not used 638 o FCN: The FCN field is encoded on N=1 bit, so WINDOW_SIZE = 1 tile 639 (FCN=All-1 is reserved for SCHC). 641 o RCS: Use recommended calculation algorithm in 642 [I-D.ietf-lpwan-ipv6-static-context-hc]. 644 o MAX_ACK_REQUESTS: 8 646 As only 1 tile is used, its size can change for each downlink, and 647 will be maximum available MTU. 649 _Note_: The Fpending bit included in LoRaWAN protocol SHOULD NOT be 650 used for SCHC-over-LoRaWAN protocol. It might be set by the Network 651 Server for other purposes but not SCHC needs. 653 5.6.3.1. Regular fragments 655 | FPort | LoRaWAN payload | 656 + ------ + ------------------------------------ + 657 | RuleID | W | FCN = b'0 | Payload | 658 + ------ + ----- + --------- + ---------------- + 659 | 8 bits | 1 bit | 1 bit | X bytes + 6 bits | 661 Figure 11: All fragments but the last one. Header size 10 bits, 662 including LoraWAN FPort. 664 5.6.3.2. Last fragment (All-1) 666 | FPort | LoRaWAN payload | 667 + ------ + --------------------------- + 668 | RuleID | W | FCN = b'1 | RCS | 669 + ------ + ----- + --------- + ------- + 670 | 8 bits | 1 bit | 1 bit | 32 bits | 672 Figure 12: All-1 SCHC Message: the last fragment. 674 5.6.3.3. SCHC acknowledge 676 | FPort | LoRaWAN payload | 677 + ------ + ---------------------------------- + 678 | RuleID | W | C = b'1 | Padding b'000000 | 679 + ------ + ----- + ------- + ---------------- + 680 | 8 bits | 1 bit | 1 bit | 6 bits | 682 Figure 13: SCHC ACK format, RCS is correct. 684 5.6.3.4. Receiver-Abort 686 | FPort | LoRaWAN payload | 687 + ------ + ---------------------------------------------- + 688 | RuleID | W = b'1 | C = b'1 | b'111111 | 0xFF (all 1's) | 689 + ------ + ------- + ------- + -------- + --------------- + 690 | 8 bits | 1 bit | 1 bits | 6 bits | 8 bits | 691 next L2 Word boundary ->| <-- L2 Word --> | 693 Figure 14: Receiver-Abort packet (following an All-1 SCHC Fragment 694 with incorrect RCS). 696 Class A and Class B or Class C end-devices do not manage 697 retransmissions and timers in the same way. 699 5.6.3.5. Class A end-devices 701 Class A end-devices can only receive in an RX slot following the 702 transmission of an uplink. Therefore there cannot be a concept of 703 "retransmission timer" for an SCHC gateway. The SCHC gateway cannot 704 initiate communication to a Class A end-device. 706 The device replies with an ACK message to every single fragment 707 received from the SCHC gateway (because the window size is 1). 708 Following the reception of a FCN=0 fragment (fragment that is not the 709 last fragment of the packet or SCHC ACK REQ, but the end of a 710 window), the device MUST transmit the SCHC ACK fragment until it 711 receives the fragment of the next window. The device SHALL transmit 712 up to MAX_ACK_REQUESTS ACK messages before aborting. The device 713 should transmit those ACK as soon as possible while taking into 714 consideration potential local radio regulation on duty-cycle, to 715 progress the fragmentation session as quickly as possible. The ACK 716 bitmap is 1 bit long and is always 1. 718 Following the reception of an FCN=All-1 fragment (the last fragment 719 of a datagram) and if the RCS is correct, the device SHALL transmit 720 the ACK with the "RCS is correct" indicator bit set (C=1). This 721 message might be lost therefore the SCHC gateway MAY request a 722 retransmission of this ACK in the next downlink. The device SHALL 723 keep this ACK message in memory until it receives a downlink, on SCHC 724 FPortDown from the SCHC gateway different from an SCHC ACK REQ: it 725 indicates that the SCHC gateway has received the ACK message. 727 The fragmentation sender (the SCHC gateway) implements an inactivity 728 timer with a default duration of 12 hours. Once a fragmentation 729 session is started, if the SCHC gateway has not received any ACK or 730 Receiver-Abort message 12 hours after the last message from the 731 device was received, the SCHC gateway MAY flush the fragmentation 732 context. For devices with very low transmission rates (example 1 733 packet a day in normal operation) , that duration may be extended, 734 but this is application specific. 736 5.6.3.6. Class B or Class C end-devices 738 Class B and Class C end-devices can receive in scheduled RX slots or 739 in RX slots following the transmission of an uplink. The device 740 replies with an ACK message to every single fragment received from 741 the SCHC gateway (because the window size is 1). Following the 742 reception of an FCN=0 fragment (fragment that is not the last 743 fragment of the packet or SCHC ACK REQ), the device MUST always 744 transmit the corresponding SCHC ACK message even if that fragment has 745 already been received. The ACK bitmap is 1 bit long and is always 1. 746 If the SCHC gateway receives this ACK, it proceeds to send the next 747 window fragment. If the retransmission timer elapses and the SCHC 748 gateway has not received the ACK of the current window it retransmits 749 the last fragment. The SCHC gateway tries retransmitting up to 750 MAX_ACK_REQUESTS times before aborting. 752 Following the reception of an FCN=All-1 fragment (the last fragment 753 of a datagram) and if the RCS is correct, the device SHALL transmit 754 the ACK with the "RCS is correct" indicator bit set. If the SCHC 755 gateway receives this ACK, the current fragmentation session has 756 succeeded and its context can be cleared. 758 If the retransmission timer elapses and the SCHC gateway has not 759 received the SCHC ACK it retransmits the last fragment with the 760 payload (not an SCHC ACK REQ without payload). The SCHC gateway 761 tries retransmitting up to MAX_ACK_REQUESTS times before aborting. 763 Following the reception of an FCN=All-1 fragment (the last fragment 764 of a datagram), if all fragments have been received and if the RCS is 765 NOT correct, the device SHALL transmit a Receiver-Abort fragment. 766 The retransmission timer is used by the SCHC gateway (the sender), 767 the optimal value is very much application specific but here are some 768 recommended default values. For Class B end-devices, this timer 769 trigger is a function of the periodicity of the Class B ping slots. 770 The RECOMMENDED value is equal to 3 times the Class B ping slot 771 periodicity. For Class C end-devices which are nearly constantly 772 receiving, the RECOMMENDED value is 30 seconds. This means that the 773 end-device shall try to transmit the ACK within 30 seconds of the 774 reception of each fragment. The inactivity timer is implemented by 775 the end-device to flush the context in case it receives nothing from 776 the SCHC gateway over an extended period of time. The RECOMMENDED 777 value is 12 hours for both Class B and Class C end-devices. 779 6. Security considerations 781 This document is only providing parameters that are expected to be 782 better suited for LoRaWAN networks for 783 [I-D.ietf-lpwan-ipv6-static-context-hc]. IID security is discussed 784 in Section 5.3.As such, this document does not contribute to any new 785 security issues in addition to those identified in 786 [I-D.ietf-lpwan-ipv6-static-context-hc]. 788 Acknowledgements 790 Thanks to all those listed in the Contributors section for the 791 excellent text, insightful discussions, reviews and suggestions, and 792 also to (in alphabetical order) Dominique Barthel, Arunprabhu 793 Kandasamy, Rodrigo Munoz, Alexander Pelov, Pascal Thubert, Laurent 794 Toutain for useful design considerations, reviews and comments. 796 Contributors 798 Contributors ordered by family name. 800 Vincent Audebert 801 EDF R&D 802 Email: vincent.audebert@edf.fr 804 Julien Catalano 805 Kerlink 806 Email: j.catalano@kerlink.fr 808 Michael Coracin 809 Semtech 810 Email: mcoracin@semtech.com 812 Marc Le Gourrierec 813 Sagemcom 814 Email: marc.legourrierec@sagemcom.com 816 Nicolas Sornin 817 Semtech 818 Email: nsornin@semtech.com 820 Alper Yegin 821 Actility 822 Email: alper.yegin@actility.com 824 9. References 826 9.1. Normative References 828 [I-D.ietf-lpwan-ipv6-static-context-hc] 829 Minaburo, A., Toutain, L., Gomez, C., Barthel, D., and J. 830 Zuniga, "Static Context Header Compression (SCHC) and 831 fragmentation for LPWAN, application to UDP/IPv6", draft- 832 ietf-lpwan-ipv6-static-context-hc-24 (work in progress), 833 December 2019. 835 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 836 Requirement Levels", BCP 14, RFC 2119, 837 DOI 10.17487/RFC2119, March 1997, 838 . 840 [RFC3385] Sheinwald, D., Satran, J., Thaler, P., and V. Cavanna, 841 "Internet Protocol Small Computer System Interface (iSCSI) 842 Cyclic Redundancy Check (CRC)/Checksum Considerations", 843 RFC 3385, DOI 10.17487/RFC3385, September 2002, 844 . 846 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 847 Architecture", RFC 4291, DOI 10.17487/RFC4291, February 848 2006, . 850 [RFC4493] Song, JH., Poovendran, R., Lee, J., and T. Iwata, "The 851 AES-CMAC Algorithm", RFC 4493, DOI 10.17487/RFC4493, June 852 2006, . 854 [RFC4944] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler, 855 "Transmission of IPv6 Packets over IEEE 802.15.4 856 Networks", RFC 4944, DOI 10.17487/RFC4944, September 2007, 857 . 859 [RFC5795] Sandlund, K., Pelletier, G., and L-E. Jonsson, "The RObust 860 Header Compression (ROHC) Framework", RFC 5795, 861 DOI 10.17487/RFC5795, March 2010, 862 . 864 [RFC7136] Carpenter, B. and S. Jiang, "Significance of IPv6 865 Interface Identifiers", RFC 7136, DOI 10.17487/RFC7136, 866 February 2014, . 868 [RFC8064] Gont, F., Cooper, A., Thaler, D., and W. Liu, 869 "Recommendation on Stable IPv6 Interface Identifiers", 870 RFC 8064, DOI 10.17487/RFC8064, February 2017, 871 . 873 [RFC8065] Thaler, D., "Privacy Considerations for IPv6 Adaptation- 874 Layer Mechanisms", RFC 8065, DOI 10.17487/RFC8065, 875 February 2017, . 877 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 878 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 879 May 2017, . 881 [RFC8376] Farrell, S., Ed., "Low-Power Wide Area Network (LPWAN) 882 Overview", RFC 8376, DOI 10.17487/RFC8376, May 2018, 883 . 885 9.2. Informative References 887 [lora-alliance-remote-multicast-set] 888 Alliance, L., "LoRaWAN Remote Multicast Setup 889 Specification Version 1.0.0", . 893 [lora-alliance-spec] 894 Alliance, L., "LoRaWAN Specification Version V1.0.3", 895 . 898 Appendix A. Examples 900 A.1. Uplink - Compression example - No fragmentation 902 This example represents an applicative payload going through SCHC 903 over LoRaWAN, no fragmentation required 905 An applicative payload of 78 bytes is passed to SCHC compression 906 layer. Rule 1 is used by C/D layer, allowing to compress it to 40 907 bytes and 5 bits: 1 byte RuleID, 21 bits residue + 37 bytes payload. 909 | RuleID | Compression residue | Payload | Padding=b'000 | 910 + ------ + ------------------- + --------- + ------------- + 911 | 1 | 21 bits | 37 bytes | 3 bits | 913 Figure 15: Uplink example: SCHC Message 915 The current LoRaWAN MTU is 51 bytes, although 2 bytes FOpts are used 916 by LoRaWAN protocol: 49 bytes are available for SCHC payload; no need 917 for fragmentation. The payload will be transmitted through FPort = 918 1. 920 | LoRaWAN Header | LoRaWAN payload (40 bytes) | 921 + ------------------------- + --------------------------------------- + 922 | | FOpts | RuleID=1 | Compression | Payload | Padding=b'000 | 923 | | | | residue | | | 924 + ---- + ------- + -------- + ----------- + --------- + ------------- + 925 | XXXX | 2 bytes | 1 byte | 21 bits | 37 bytes | 3 bits | 927 Figure 16: Uplink example: LoRaWAN packet 929 A.2. Uplink - Compression and fragmentation example 931 This example represents an applicative payload going through SCHC, 932 with fragmentation. 934 An applicative payload of 478 bytes is passed to SCHC compression 935 layer. Rule 1 is used by C/D layer, allowing to compress it to 282 936 bytes and 5 bits: 1 byte RuleID, 21 bits residue + 279 bytes payload. 938 | RuleID | Compression residue | Payload | 939 + ------ + ------------------- + --------- + 940 | 1 | 21 bits | 279 bytes | 942 Figure 17: Uplink example: SCHC Message 944 The current LoRaWAN MTU is 11 bytes, 0 bytes FOpts are used by 945 LoRaWAN protocol: 11 bytes are available for SCHC payload + 1 byte 946 FPort field. SCHC header is 2 bytes (including FPort) so 1 tile is 947 sent in first fragment. 949 | LoRaWAN Header | LoRaWAN payload (11 bytes) | 950 + -------------------------- + -------------------------- + 951 | | RuleID=20 | W | FCN | 1 tile | 952 + -------------- + --------- + ----- + ------ + --------- + 953 | XXXX | 1 byte | 0 0 | 62 | 10 bytes | 955 Figure 18: Uplink example: LoRaWAN packet 1 957 Content of the tile is: 958 | RuleID | Compression residue | Payload | 959 + ------ + ------------------- + ----------------- + 960 | 1 | 21 bits | 6 byte + 3 bits | 962 Figure 19: Uplink example: LoRaWAN packet 1 - Tile content 964 Next transmission MTU is 11 bytes, although 2 bytes FOpts are used by 965 LoRaWAN protocol: 9 bytes are available for SCHC payload + 1 byte 966 FPort field, a tile does not fit inside so LoRaWAN stack will send 967 only FOpts. 969 Next transmission MTU is 242 bytes, 4 bytes FOpts. 23 tiles are 970 transmitted: 972 | LoRaWAN Header | LoRaWAN payload (231 bytes) | 973 + --------------------------------------+ --------------------------- + 974 | | FOpts | RuleID=20 | W | FCN | 23 tiles | 975 + -------------- + ------- + ---------- + ----- + ----- + ----------- + 976 | XXXX | 4 bytes | 1 byte | 0 0 | 61 | 230 bytes | 978 Figure 20: Uplink example: LoRaWAN packet 2 980 Next transmission MTU is 242 bytes, no FOpts. All 5 remaining tiles 981 are transmitted, the last tile is only 2 bytes + 5 bits. Padding is 982 added for the remaining 3 bits. 984 | LoRaWAN Header | LoRaWAN payload (44 bytes) | 985 + ---- + -----------+ ------------------------------------------------- + 986 | | RuleID=20 | W | FCN | 5 tiles | Padding=b'000 | 987 + ---- + ---------- + ----- + ----- + ----------------- + ------------- + 988 | XXXX | 1 byte | 0 0 | 38 | 42 bytes + 5 bits | 3 bits | 990 Figure 21: Uplink example: LoRaWAN packet 3 992 Then All-1 message can be transmitted: 994 | LoRaWAN Header | LoRaWAN payload (44 bytes) | 995 + ---- + -----------+ -------------------------- + 996 | | RuleID=20 | W | FCN | RCS | 997 + ---- + ---------- + ----- + ----- + ---------- + 998 | XXXX | 1 byte | 0 0 | 63 | 4 bytes | 1000 Figure 22: Uplink example: LoRaWAN packet 4 - All-1 message 1002 All packets have been received by the SCHC gateway, computed RCS is 1003 correct so the following ACK is sent to the device by the SCHC 1004 receiver: 1006 | LoRaWAN Header | LoRaWAN payload | 1007 + -------------- + --------- + ------------------- + 1008 | | RuleID=20 | W | C | Padding | 1009 + -------------- + --------- + ----- + - + ------- + 1010 | XXXX | 1 byte | 0 0 | 1 | 5 bits | 1012 Figure 23: Uplink example: LoRaWAN packet 5 - SCHC ACK 1014 A.3. Downlink 1016 An applicative payload of 443 bytes is passed to SCHC compression 1017 layer. Rule 1 is used by C/D layer, allowing to compress it to 130 1018 bytes and 5 bits: 1 byte RuleID, 21 bits residue + 127 bytes payload. 1020 | RuleID | Compression residue | Payload | 1021 + ------ + ------------------- + --------- + 1022 | 1 | 21 bits | 127 bytes | 1024 Figure 24: Downlink example: SCHC Message 1026 The current LoRaWAN MTU is 51 bytes, no FOpts are used by LoRaWAN 1027 protocol: 51 bytes are available for SCHC payload + FPort field => it 1028 has to be fragmented. 1030 | LoRaWAN Header | LoRaWAN payload (51 bytes) | 1031 + ---- + ---------- + -------------------------------------- + 1032 | | RuleID=21 | W = 0 | FCN = 0 | 1 tile | 1033 + ---- + ---------- + ------ + ------- + ------------------- + 1034 | XXXX | 1 byte | 1 bit | 1 bit | 50 bytes and 6 bits | 1036 Figure 25: Downlink example: LoRaWAN packet 1 - SCHC Fragment 1 1038 Content of the tile is: 1040 | RuleID | Compression residue | Payload | 1041 + ------ + ------------------- + ------------------ + 1042 | 1 | 21 bits | 48 bytes and 1 bit | 1044 Figure 26: Downlink example: LoRaWAN packet 1: Tile content 1046 The receiver answers with a SCHC ACK: 1048 | LoRaWAN Header | LoRaWAN payload | 1049 + ---- + --------- + -------------------------------- + 1050 | | RuleID=21 | W = 0 | C = 1 | Padding=b'000000 | 1051 + ---- + --------- + ----- + ----- + ---------------- + 1052 | XXXX | 1 byte | 1 bit | 1 bit | 6 bits | 1054 Figure 27: Downlink example: LoRaWAN packet 2 - SCHC ACK 1056 The second downlink is sent, two FOpts: 1058 | LoRaWAN Header | LoRaWAN payload (49 bytes) | 1059 + --------------------------- + ------------------------------------- + 1060 | | FOpts | RuleID=21 | W = 1 | FCN = 0 | 1 tile | 1061 + ---- + ------- + ---------- + ----- + ------- + ------------------- + 1062 | XXXX | 2 bytes | 1 byte | 1 bit | 1 bit | 48 bytes and 6 bits | 1064 Figure 28: Downlink example: LoRaWAN packet 3 - SCHC Fragment 2 1066 The receiver answers with an SCHC ACK: 1068 | LoRaWAN Header | LoRaWAN payload | 1069 + ---- + --------- + -------------------------------- + 1070 | | RuleID=21 | W = 1 | C = 1 | Padding=b'000000 | 1071 + ---- + --------- + ----- + ----- + ---------------- + 1072 | XXXX | 1 byte | 1 bit | 1 bit | 6 bits | 1074 Figure 29: Downlink example: LoRaWAN packet 4 - SCHC ACK 1076 The last downlink is sent, no FOpts: 1078 | LoRaWAN Header | LoRaWAN payload (37 bytes) | 1079 + ---- + --------- + ----------------------------------------------------------------- + 1080 | | RuleID=21 | W = 0 | FCN = 1 | RCS | 1 tile | Padding=b'00000 | 1081 + ---- + --------- + ------- + ------- + ------- + ----------------- + --------------- + 1082 | XXXX | 1 byte | 1 bit | 1 bit | 4 bytes | 31 bytes + 1 bits | 5 bits | 1084 Figure 30: Uplink example: LoRaWAN packet 5 - All-1 message 1086 The receiver answers to the sender with an SCHC ACK: 1088 | LoRaWAN Header | LoRaWAN payload | 1089 + ---- + --------- + -------------------------------- + 1090 | | RuleID=21 | W = 0 | C = 1 | Padding=b'000000 | 1091 + ---- + --------- + ----- + ----- + ---------------- + 1092 | XXXX | 1 byte | 1 bit | 1 bit | 6 bits | 1094 Figure 31: Uplink example: LoRaWAN packet 6 - SCHC ACK 1096 Authors' Addresses 1098 Olivier Gimenez (editor) 1099 Semtech 1100 14 Chemin des Clos 1101 Meylan 1102 France 1104 Email: ogimenez@semtech.com 1106 Ivaylo Petrov (editor) 1107 Acklio 1108 1137A Avenue des Champs Blancs 1109 35510 Cesson-Sevigne Cedex 1110 France 1112 Email: ivaylo@ackl.io