idnits 2.17.1 draft-ietf-lpwan-schc-over-lorawan-06.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 (March 31, 2020) is 1485 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC3385' is defined on line 862, but no explicit reference was found in the text == Unused Reference: 'RFC4944' is defined on line 876, but no explicit reference was found in the text == Unused Reference: 'RFC5795' is defined on line 881, but no explicit reference was found in the text == Unused Reference: 'RFC7136' is defined on line 886, 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: October 2, 2020 Acklio 6 March 31, 2020 8 Static Context Header Compression (SCHC) over LoRaWAN 9 draft-ietf-lpwan-schc-over-lorawan-06 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 October 2, 2020. 40 Copyright Notice 42 Copyright (c) 2020 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 . . 12 75 5.6.3. Downlink fragmentation: From SCHC gateway to a device 15 76 6. Security considerations . . . . . . . . . . . . . . . . . . . 18 77 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 18 78 Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 19 79 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 19 80 9.1. Normative References . . . . . . . . . . . . . . . . . . 19 81 9.2. Informative References . . . . . . . . . . . . . . . . . 21 82 Appendix A. Examples . . . . . . . . . . . . . . . . . . . . . . 21 83 A.1. Uplink - Compression example - No fragmentation . . . . . 21 84 A.2. Uplink - Compression and fragmentation example . . . . . 22 85 A.3. Downlink . . . . . . . . . . . . . . . . . . . . . . . . 23 86 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 25 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 flows 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) that 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 issued by end-device's message with a 333 JoinAccept message. That message is encrypted with the end- 334 device's AppKey and contains (amongst other fields) the major 335 network's settings and a network random nonce used to derive the 336 session keys. 338 o Data: MAC and application data. Application data are protected 339 with AES-128 encryption, MAC related data are AES-128 encrypted 340 with another key. 342 4.5. Unicast and multicast technology 344 LoRaWAN technology supports unicast downlinks, but also multicast: a 345 packet send over LoRaWAN radio link can be received by several 346 devices. It is useful to address many end-devices with same content, 347 either a large binary file (firmware upgrade), or same command (e.g: 348 lighting control). As IPv6 is also a multicast technology this 349 feature can be used to address a group of devices. 351 _Note 1_: IPv6 multicast addresses must be defined as per [RFC4291]. 352 LoRaWAN multicast group definition in a network server and the 353 relation between those groups and IPv6 groupID are out of scope of 354 this document. 356 _Note 2_: LoRa Alliance defined [lora-alliance-remote-multicast-set] 357 as RECOMMENDED way to setup multicast groups on devices and create a 358 synchronized reception window. 360 5. SCHC-over-LoRaWAN 362 5.1. LoRaWAN FPort 364 The LoRaWAN MAC layer features a frame port field in all frames. 365 This field (FPort) is 8 bits long and the values from 1 to 223 can be 366 used. It allows LoRaWAN networks and applications to identify data. 368 The FPort field is part of the SCHC Message, as shown in Figure 5. 369 The SCHC C/D and the SCHC F/R SHALL concatenate the FPort field with 370 the LoRaWAN payload to retrieve their payload as it is used as a part 371 of the RuleID field. 373 | FPort | LoRaWAN payload | 374 + ------------------------ + 375 | SCHC payload | 377 Figure 5: SCHC Message in LoRaWAN 379 A fragmentation session with application payload transferred from 380 device to server, is called uplink fragmentation session. It uses an 381 FPort for data uplink and its associated SCHC control downlinks, 382 named FPortUp in this document. The other way, a fragmentation 383 session with application payload transferred from server to device, 384 is called downlink fragmentation session. It uses another FPort for 385 data downlink and its associated SCHC control uplinks, named 386 FPortDown in this document. 388 All ruleId can use arbitrary values inside the FPort range allowed by 389 LoRaWAN specification and MUST be shared by the end-device and SCHC 390 gateway prior to the communication with the selected rule. The 391 uplink and downlink fragmentation FPorts MUST be different. 393 5.2. Rule ID management 395 RuleID MUST be 8 bits, encoded in the LoRaWAN FPort as described in 396 Section 5.1. LoRaWAN supports up to 223 application FPorts in the 397 range [1;223] as defined in section 4.3.2 of [lora-alliance-spec], it 398 implies that RuleID MSB SHOULD be inside this range. An application 399 can send non SCHC traffic by using FPort values different from the 400 ones used for SCHC. 402 In order to improve interoperability RECOMMENDED fragmentation RuleID 403 values are: 405 o RuleID = 20 (8-bit) for uplink fragmentation, named FPortUp 407 o RuleID = 21 (8-bit) for downlink fragmentation, named FPortDown 409 o RuleID = 22 (8-bit) for which SCHC compression was not possible 410 (no matching rule was found) 412 The remaining RuleIDs are available for compression. RuleIDs are 413 shared between uplink and downlink sessions. A RuleID not in the 414 set(s) of FPortUp or FPortDown means that the fragmentation is not 415 used, thus, on reception, the SCHC Message MUST be sent to the C/D 416 layer. 418 The only uplink messages using the FPortDown port are the 419 fragmentation SCHC control messages of a downlink fragmentation 420 session (for example, SCHC ACKs). Similarly, the only downlink 421 messages using the FPortUp port are the fragmentation SCHC control 422 messages of an uplink fragmentation session. 424 An application can have multiple fragmentation sessions between a 425 device and one or several SCHC gateways. A set of FPort values is 426 REQUIRED for each SCHC gateway instance the device is required to 427 communicate with. 429 The mechanism for sharing those RuleID values is outside the scope of 430 this document. 432 5.3. IID computation 434 In order to mitigate risks described in [RFC8064] and [RFC8065] IID 435 MUST be created regarding the following algorithm: 437 1. key = LoRaWAN AppSKey 439 2. cmac = aes128_cmac(key, devEui) 441 3. IID = cmac[0..7] 443 aes128_cmac algorithm is described in [RFC4493]. It has been chosen 444 as it is already used by devices for LoRaWAN procotol. 446 As AppSKey is renewed each time a device joins or rejoins a network, 447 the IID will change over time; this mitigates privacy, location 448 tracking and correlation over time risks. Join periodicity is 449 defined at the application level. 451 Address scan risk is mitigated thanks to AES-128, which provides 452 enough entropy bits of the IID. 454 Using this algorithm will also ensure that there is no correlation 455 between the hardware identifier (IEEE-64 devEUI) and the IID, so an 456 attacker cannot use manufacturer OUI to target devices. 458 Example with: 460 o devEui: 0x1122334455667788 462 o appSKey: 0x00AABBCCDDEEFF00AABBCCDDEEFFAABB 463 1. key: 0x00AABBCCDDEEFF00AABBCCDDEEFFAABB 464 2. cmac: 0x4E822D9775B2649928F82066AF804FEC 465 3. IID: 0x28F82066AF804FEC 467 Figure 6: Example of IID computation. 469 There is a small probability of IID collision in a network, if such 470 event occurs the IID can be changed by rekeying the device on L2 471 level (ie: trigger a LoRaWAN join). The way the device is rekeyed is 472 out of scope of this document and left to the implementation. 474 5.4. Padding 476 All padding bits MUST be 0. 478 5.5. Decompression 480 SCHC C/D MUST concatenate FPort and LoRaWAN payload to retrieve the 481 SCHC Packet as per Section 5.1. 483 RuleIDs matching FPortUp and FPortDown are reserved for SCHC 484 Fragmentation. 486 5.6. Fragmentation 488 The L2 Word Size used by LoRaWAN is 1 byte (8 bits). The SCHC 489 fragmentation over LoRaWAN uses the ACK-on-Error mode for uplink 490 fragmentation and Ack-Always mode for downlink fragmentation. A 491 LoRaWAN end-device cannot support simultaneous interleaved 492 fragmentation sessions in the same direction (uplink or downlink). 494 The fragmentation parameters are different for uplink and downlink 495 fragmentation sessions and are successively described in the next 496 sections. 498 5.6.1. DTag 500 A LoRaWAN device cannot interleave several fragmented SCHC datagrams 501 on the same FPort. This field is not used and its size is 0. 503 Note: The device can still have several parallel fragmentation 504 sessions with one or more SCHC gateway(s) thanks to distinct sets of 505 FPorts, cf Section 5.2 507 5.6.2. Uplink fragmentation: From device to SCHC gateway 509 In that case the device is the fragmentation transmitter, and the 510 SCHC gateway the fragmentation receiver. A single fragmentation rule 511 is defined. SCHC F/R MUST concatenate FPort and LoRaWAN payload to 512 retrieve the SCHC Packet, as per Section 5.1. 514 o SCHC header size is two bytes (the FPort byte + 1 additional 515 byte). 517 o RuleID: 8 bits stored in LoRaWAN FPort. 519 o SCHC fragmentation reliability mode: "ACK-on-Error" 521 o DTag: Size is 0 bit, not used 523 o FCN: The FCN field is encoded on N = 6 bits, so WINDOW_SIZE = 63 524 tiles are allowed in a window 526 o Window index: encoded on W = 2 bits. So 4 windows are available. 528 o RCS: Use recommended calculation algorithm in 529 [I-D.ietf-lpwan-ipv6-static-context-hc]. 531 o MAX_ACK_REQUESTS: 8 533 o Tile: size is 10 bytes 535 o Retransmission timer: LoRaWAN end-devices MUST NOT implement a 536 "retransmission timer", this changes the specification of 537 [I-D.ietf-lpwan-ipv6-static-context-hc], see Section 5.6.3.5. It 538 must transmit MAX_ACK_REQUESTS time the SCHC ACK REQ at it own 539 timing; ie the periodicity between retransmission of SCHC ACK REQs 540 is device specific and can vary depending on other application 541 uplinks and regulations. 543 o Inactivity timer: The SCHC gateway implements an "inactivity 544 timer". The default RECOMMENDED duration of this timer is 12 545 hours; this value is mainly driven by application requirements and 546 MAY be changed by the application. 548 o Penultimate tile MUST be equal to the regular size. 550 o Last tile: it can be carried in a Regular SCHC Fragment, alone in 551 an All-1 SCHC Fragment or with any of these two methods: 552 implementation must ensure that: 554 * The sender MUST ascertain that the receiver will not receive 555 the last tile through both a Regular SCHC Fragment and an All-1 556 SCHC Fragment. 558 * If last tile is in All-1 message: current L2 MTU MUST be big 559 enough to fit the All-1 and the last tile. 561 With this set of parameters, the SCHC fragment header is 16 bits, 562 including FPort; payload overhead will be 8 bits as FPort is already 563 a part of LoRaWAN payload. MTU is: _4 windows * 63 tiles * 10 bytes 564 per tile = 2520 bytes_ 566 _Note_: As LoRaWAN is a radio communication, it is RECOMMENDED for an 567 implementation to use ACK mechanism at the end of each window: 569 o SCHC receiver sends an SCHC ACK after every window even if there 570 is no missing tiles. 572 o SCHC sender waits for the SCHC ACK from the SCHC receiver before 573 sending tiles from next window. If the SCHC ACK is not received, 574 it should send an SCHC ACK REQ up to MAX_ACK_REQUESTS time as 575 described previously. 577 This OPTIONAL feature allows the implementation to select between: * 578 SCHC ACK after every window: Save battery life by preventing a device 579 to transmit full payload if the network cannot be reached * 580 Otherwise: Reduce downlink load on the network by reducing the number 581 of downlinks 583 5.6.2.1. Regular fragments 585 | FPort | LoRaWAN payload | 586 + ------ + ------------------------- + 587 | RuleID | W | FCN | Payload | 588 + ------ + ------ + ------ + ------- + 589 | 8 bits | 2 bits | 6 bits | | 591 Figure 7: All fragments except the last one. SCHC header size is 16 592 bits, including LoRaWAN FPort. 594 5.6.2.2. Last fragment (All-1) 595 | FPort | LoRaWAN payload | 596 + ------ + ---------------------------- + 597 | RuleID | W | FCN=All-1 | RCS | 598 + ------ + ------ + --------- + ------- + 599 | 8 bits | 2 bits | 6 bits | 32 bits | 601 Figure 8: All-1 fragment detailed format for the last fragment. 603 5.6.2.3. SCHC ACK 605 | FPort | LoRaWAN payload | 606 + ------ + ----------------------------------------- + 607 | RuleID | W | C | Encoded bitmap (if C = 0) | 608 + ------ + ----- + ----- + ------------------------- + 609 | 8 bits | 2 bit | 1 bit | 0 to 63 bits | 611 Figure 9: SCHC ACK format, failed RCS check. 613 5.6.2.4. Receiver-Abort 615 | FPort | LoRaWAN payload | 616 + ------ + -------------------------------------------- + 617 | RuleID | W = b'11 | C = 1 | b'11111 | 0xFF (all 1's) | 618 + ------ + -------- + ------+-------- + ----------------+ 619 | 8 bits | 2 bits | 1 bit | 5 bits | 8 bits | 620 next L2 Word boundary ->| <-- L2 Word --> | 622 Figure 10: Receiver-Abort format. 624 5.6.2.5. SCHC acknowledge request 626 | FPort | LoRaWAN payload | 627 +------- +------------------------- + 628 | RuleID | W | FCN = b'000000 | 629 + ------ + ------ + --------------- + 630 | 8 bits | 2 bits | 6 bits | 632 Figure 11: SCHC ACK REQ format. 634 5.6.3. Downlink fragmentation: From SCHC gateway to a device 636 In that case the device is the fragmentation receiver, and the SCHC 637 gateway the fragmentation transmitter. The following fields are 638 common to all devices. SCHC F/R MUST concatenate FPort and LoRaWAN 639 payload to retrieve the SCHC Packet as described in Section 5.1. 641 o SCHC fragmentation reliability mode: 643 * Unicast downlinks: ACK-Always. 645 * Multicast downlinks: No-ACK, reliability has to be ensured by 646 the upper layer. This feature is OPTIONAL and may not be 647 implemented by SCHC gateway. 649 o RuleID: 8 bits stored in LoRaWAN FPort. 651 o Window index (unicast only): encoded on W=1 bit, as per 652 [I-D.ietf-lpwan-ipv6-static-context-hc]. 654 o DTag: Size is 0 bit, not used 656 o FCN: The FCN field is encoded on N=1 bit, so WINDOW_SIZE = 1 tile 657 (FCN=All-1 is reserved for SCHC). 659 o RCS: Use recommended calculation algorithm in 660 [I-D.ietf-lpwan-ipv6-static-context-hc]. 662 o MAX_ACK_REQUESTS: 8 664 As only 1 tile is used, its size can change for each downlink, and 665 will be maximum available MTU. 667 _Note_: The Fpending bit included in LoRaWAN protocol SHOULD NOT be 668 used for SCHC-over-LoRaWAN protocol. It might be set by the Network 669 Server for other purposes but not SCHC needs. 671 5.6.3.1. Regular fragments 673 | FPort | LoRaWAN payload | 674 + ------ + ------------------------------------ + 675 | RuleID | W | FCN = b'0 | Payload | 676 + ------ + ----- + --------- + ---------------- + 677 | 8 bits | 1 bit | 1 bit | X bytes + 6 bits | 679 Figure 12: All fragments but the last one. Header size 10 bits, 680 including LoraWAN FPort. 682 5.6.3.2. Last fragment (All-1) 684 | FPort | LoRaWAN payload | 685 + ------ + --------------------------- + 686 | RuleID | W | FCN = b'1 | RCS | 687 + ------ + ----- + --------- + ------- + 688 | 8 bits | 1 bit | 1 bit | 32 bits | 690 Figure 13: All-1 SCHC Message: the last fragment. 692 5.6.3.3. SCHC acknowledge 694 | FPort | LoRaWAN payload | 695 + ------ + ---------------------------------- + 696 | RuleID | W | C = b'1 | Padding b'000000 | 697 + ------ + ----- + ------- + ---------------- + 698 | 8 bits | 1 bit | 1 bit | 6 bits | 700 Figure 14: SCHC ACK format, RCS is correct. 702 5.6.3.4. Receiver-Abort 704 | FPort | LoRaWAN payload | 705 + ------ + ---------------------------------------------- + 706 | RuleID | W = b'1 | C = b'1 | b'111111 | 0xFF (all 1's) | 707 + ------ + ------- + ------- + -------- + --------------- + 708 | 8 bits | 1 bit | 1 bits | 6 bits | 8 bits | 709 next L2 Word boundary ->| <-- L2 Word --> | 711 Figure 15: Receiver-Abort packet (following an All-1 SCHC Fragment 712 with incorrect RCS). 714 Class A and Class B or Class C end-devices do not manage 715 retransmissions and timers in the same way. 717 5.6.3.5. Class A end-devices 719 Class A end-devices can only receive in an RX slot following the 720 transmission of an uplink. Therefore there cannot be a concept of 721 "retransmission timer" for an SCHC gateway. The SCHC gateway cannot 722 initiate communication to a Class A end-device. 724 The device replies with an ACK message to every single fragment 725 received from the SCHC gateway (because the window size is 1). 727 Following the reception of a FCN=0 fragment (fragment that is not the 728 last fragment of the packet or SCHC ACK REQ, but the end of a 729 window), the device MUST transmit the SCHC ACK fragment until it 730 receives the fragment of the next window. The device SHALL transmit 731 up to MAX_ACK_REQUESTS ACK messages before aborting. The device 732 should transmit those ACK as soon as possible while taking into 733 consideration potential local radio regulation on duty-cycle, to 734 progress the fragmentation session as quickly as possible. The ACK 735 bitmap is 1 bit long and is always 1. 737 Following the reception of an FCN=All-1 fragment (the last fragment 738 of a datagram) and if the RCS is correct, the device SHALL transmit 739 the ACK with the "RCS is correct" indicator bit set (C=1). This 740 message might be lost therefore the SCHC gateway MAY request a 741 retransmission of this ACK in the next downlink. The device SHALL 742 keep this ACK message in memory until it receives a downlink, on SCHC 743 FPortDown from the SCHC gateway different from an SCHC ACK REQ: it 744 indicates that the SCHC gateway has received the ACK message. 746 The fragmentation sender (the SCHC gateway) implements an inactivity 747 timer with a default duration of 12 hours. Once a fragmentation 748 session is started, if the SCHC gateway has not received any ACK or 749 Receiver-Abort message 12 hours after the last message from the 750 device was received, the SCHC gateway MAY flush the fragmentation 751 context. For devices with very low transmission rates (example 1 752 packet a day in normal operation) , that duration may be extended, 753 but this is application specific. 755 5.6.3.6. Class B or Class C end-devices 757 Class B and Class C end-devices can receive in scheduled RX slots or 758 in RX slots following the transmission of an uplink. The device 759 replies with an ACK message to every single fragment received from 760 the SCHC gateway (because the window size is 1). Following the 761 reception of an FCN=0 fragment (fragment that is not the last 762 fragment of the packet or SCHC ACK REQ), the device MUST always 763 transmit the corresponding SCHC ACK message even if that fragment has 764 already been received. The ACK bitmap is 1 bit long and is always 1. 765 If the SCHC gateway receives this ACK, it proceeds to send the next 766 window fragment. If the retransmission timer elapses and the SCHC 767 gateway has not received the ACK of the current window it retransmits 768 the last fragment. The SCHC gateway tries retransmitting up to 769 MAX_ACK_REQUESTS times before aborting. 771 Following the reception of an FCN=All-1 fragment (the last fragment 772 of a datagram) and if the RCS is correct, the device SHALL transmit 773 the ACK with the "RCS is correct" indicator bit set. If the SCHC 774 gateway receives this ACK, the current fragmentation session has 775 succeeded and its context can be cleared. 777 If the retransmission timer elapses and the SCHC gateway has not 778 received the SCHC ACK it retransmits the last fragment with the 779 payload (not an SCHC ACK REQ without payload). The SCHC gateway 780 tries retransmitting up to MAX_ACK_REQUESTS times before aborting. 782 Following the reception of an FCN=All-1 fragment (the last fragment 783 of a datagram), if all fragments have been received and if the RCS is 784 NOT correct, the device SHALL transmit a Receiver-Abort fragment. 785 The retransmission timer is used by the SCHC gateway (the sender), 786 the optimal value is very much application specific but here are some 787 recommended default values. For Class B end-devices, this timer 788 trigger is a function of the periodicity of the Class B ping slots. 789 The RECOMMENDED value is equal to 3 times the Class B ping slot 790 periodicity. For Class C end-devices which are nearly constantly 791 receiving, the RECOMMENDED value is 30 seconds. This means that the 792 end-device shall try to transmit the ACK within 30 seconds of the 793 reception of each fragment. The inactivity timer is implemented by 794 the end-device to flush the context in case it receives nothing from 795 the SCHC gateway over an extended period of time. The RECOMMENDED 796 value is 12 hours for both Class B and Class C end-devices. 798 6. Security considerations 800 This document is only providing parameters that are expected to be 801 better suited for LoRaWAN networks for 802 [I-D.ietf-lpwan-ipv6-static-context-hc]. IID security is discussed 803 in Section 5.3. As such, this document does not contribute to any 804 new security issues in addition to those identified in 805 [I-D.ietf-lpwan-ipv6-static-context-hc]. Moreover SCHC data (LoRaWAN 806 payload) are protected on LoRaWAN level by an AES-128 encryption with 807 key shared by device and SCHC gateway. Those keys are renew each 808 LoRaWAN session (ie: each join or rejoin to the network) 810 Acknowledgements 812 Thanks to all those listed in the Contributors section for the 813 excellent text, insightful discussions, reviews and suggestions, and 814 also to (in alphabetical order) Dominique Barthel, Arunprabhu 815 Kandasamy, Rodrigo Munoz, Alexander Pelov, Pascal Thubert, Laurent 816 Toutain for useful design considerations, reviews and comments. 818 Contributors 820 Contributors ordered by family name. 822 Vincent Audebert 823 EDF R&D 824 Email: vincent.audebert@edf.fr 826 Julien Catalano 827 Kerlink 828 Email: j.catalano@kerlink.fr 830 Michael Coracin 831 Semtech 832 Email: mcoracin@semtech.com 834 Marc Le Gourrierec 835 Sagemcom 836 Email: marc.legourrierec@sagemcom.com 838 Nicolas Sornin 839 Semtech 840 Email: nsornin@semtech.com 842 Alper Yegin 843 Actility 844 Email: alper.yegin@actility.com 846 9. References 848 9.1. Normative References 850 [I-D.ietf-lpwan-ipv6-static-context-hc] 851 Minaburo, A., Toutain, L., Gomez, C., Barthel, D., and J. 852 Zuniga, "Static Context Header Compression (SCHC) and 853 fragmentation for LPWAN, application to UDP/IPv6", draft- 854 ietf-lpwan-ipv6-static-context-hc-24 (work in progress), 855 December 2019. 857 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 858 Requirement Levels", BCP 14, RFC 2119, 859 DOI 10.17487/RFC2119, March 1997, 860 . 862 [RFC3385] Sheinwald, D., Satran, J., Thaler, P., and V. Cavanna, 863 "Internet Protocol Small Computer System Interface (iSCSI) 864 Cyclic Redundancy Check (CRC)/Checksum Considerations", 865 RFC 3385, DOI 10.17487/RFC3385, September 2002, 866 . 868 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 869 Architecture", RFC 4291, DOI 10.17487/RFC4291, February 870 2006, . 872 [RFC4493] Song, JH., Poovendran, R., Lee, J., and T. Iwata, "The 873 AES-CMAC Algorithm", RFC 4493, DOI 10.17487/RFC4493, June 874 2006, . 876 [RFC4944] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler, 877 "Transmission of IPv6 Packets over IEEE 802.15.4 878 Networks", RFC 4944, DOI 10.17487/RFC4944, September 2007, 879 . 881 [RFC5795] Sandlund, K., Pelletier, G., and L-E. Jonsson, "The RObust 882 Header Compression (ROHC) Framework", RFC 5795, 883 DOI 10.17487/RFC5795, March 2010, 884 . 886 [RFC7136] Carpenter, B. and S. Jiang, "Significance of IPv6 887 Interface Identifiers", RFC 7136, DOI 10.17487/RFC7136, 888 February 2014, . 890 [RFC8064] Gont, F., Cooper, A., Thaler, D., and W. Liu, 891 "Recommendation on Stable IPv6 Interface Identifiers", 892 RFC 8064, DOI 10.17487/RFC8064, February 2017, 893 . 895 [RFC8065] Thaler, D., "Privacy Considerations for IPv6 Adaptation- 896 Layer Mechanisms", RFC 8065, DOI 10.17487/RFC8065, 897 February 2017, . 899 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 900 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 901 May 2017, . 903 [RFC8376] Farrell, S., Ed., "Low-Power Wide Area Network (LPWAN) 904 Overview", RFC 8376, DOI 10.17487/RFC8376, May 2018, 905 . 907 9.2. Informative References 909 [lora-alliance-remote-multicast-set] 910 Alliance, L., "LoRaWAN Remote Multicast Setup 911 Specification Version 1.0.0", . 915 [lora-alliance-spec] 916 Alliance, L., "LoRaWAN Specification Version V1.0.3", 917 . 920 Appendix A. Examples 922 A.1. Uplink - Compression example - No fragmentation 924 This example represents an applicative payload going through SCHC 925 over LoRaWAN, no fragmentation required 927 An applicative payload of 78 bytes is passed to SCHC compression 928 layer. Rule 1 is used by C/D layer, allowing to compress it to 40 929 bytes and 5 bits: 1 byte RuleID, 21 bits residue + 37 bytes payload. 931 | RuleID | Compression residue | Payload | Padding=b'000 | 932 + ------ + ------------------- + --------- + ------------- + 933 | 1 | 21 bits | 37 bytes | 3 bits | 935 Figure 16: Uplink example: SCHC Message 937 The current LoRaWAN MTU is 51 bytes, although 2 bytes FOpts are used 938 by LoRaWAN protocol: 49 bytes are available for SCHC payload; no need 939 for fragmentation. The payload will be transmitted through FPort = 940 1. 942 | LoRaWAN Header | LoRaWAN payload (40 bytes) | 943 + ------------------------- + --------------------------------------- + 944 | | FOpts | RuleID=1 | Compression | Payload | Padding=b'000 | 945 | | | | residue | | | 946 + ---- + ------- + -------- + ----------- + --------- + ------------- + 947 | XXXX | 2 bytes | 1 byte | 21 bits | 37 bytes | 3 bits | 949 Figure 17: Uplink example: LoRaWAN packet 951 A.2. Uplink - Compression and fragmentation example 953 This example represents an applicative payload going through SCHC, 954 with fragmentation. 956 An applicative payload of 478 bytes is passed to SCHC compression 957 layer. Rule 1 is used by C/D layer, allowing to compress it to 282 958 bytes and 5 bits: 1 byte RuleID, 21 bits residue + 279 bytes payload. 960 | RuleID | Compression residue | Payload | 961 + ------ + ------------------- + --------- + 962 | 1 | 21 bits | 279 bytes | 964 Figure 18: Uplink example: SCHC Message 966 The current LoRaWAN MTU is 11 bytes, 0 bytes FOpts are used by 967 LoRaWAN protocol: 11 bytes are available for SCHC payload + 1 byte 968 FPort field. SCHC header is 2 bytes (including FPort) so 1 tile is 969 sent in first fragment. 971 | LoRaWAN Header | LoRaWAN payload (11 bytes) | 972 + -------------------------- + -------------------------- + 973 | | RuleID=20 | W | FCN | 1 tile | 974 + -------------- + --------- + ----- + ------ + --------- + 975 | XXXX | 1 byte | 0 0 | 62 | 10 bytes | 977 Figure 19: Uplink example: LoRaWAN packet 1 979 Content of the tile is: 980 | RuleID | Compression residue | Payload | 981 + ------ + ------------------- + ----------------- + 982 | 1 | 21 bits | 6 byte + 3 bits | 984 Figure 20: Uplink example: LoRaWAN packet 1 - Tile content 986 Next transmission MTU is 11 bytes, although 2 bytes FOpts are used by 987 LoRaWAN protocol: 9 bytes are available for SCHC payload + 1 byte 988 FPort field, a tile does not fit inside so LoRaWAN stack will send 989 only FOpts. 991 Next transmission MTU is 242 bytes, 4 bytes FOpts. 23 tiles are 992 transmitted: 994 | LoRaWAN Header | LoRaWAN payload (231 bytes) | 995 + --------------------------------------+ --------------------------- + 996 | | FOpts | RuleID=20 | W | FCN | 23 tiles | 997 + -------------- + ------- + ---------- + ----- + ----- + ----------- + 998 | XXXX | 4 bytes | 1 byte | 0 0 | 61 | 230 bytes | 1000 Figure 21: Uplink example: LoRaWAN packet 2 1002 Next transmission MTU is 242 bytes, no FOpts. All 5 remaining tiles 1003 are transmitted, the last tile is only 2 bytes + 5 bits. Padding is 1004 added for the remaining 3 bits. 1006 | LoRaWAN Header | LoRaWAN payload (44 bytes) | 1007 + ---- + -----------+ ------------------------------------------------- + 1008 | | RuleID=20 | W | FCN | 5 tiles | Padding=b'000 | 1009 + ---- + ---------- + ----- + ----- + ----------------- + ------------- + 1010 | XXXX | 1 byte | 0 0 | 38 | 42 bytes + 5 bits | 3 bits | 1012 Figure 22: Uplink example: LoRaWAN packet 3 1014 Then All-1 message can be transmitted: 1016 | LoRaWAN Header | LoRaWAN payload (44 bytes) | 1017 + ---- + -----------+ -------------------------- + 1018 | | RuleID=20 | W | FCN | RCS | 1019 + ---- + ---------- + ----- + ----- + ---------- + 1020 | XXXX | 1 byte | 0 0 | 63 | 4 bytes | 1022 Figure 23: Uplink example: LoRaWAN packet 4 - All-1 message 1024 All packets have been received by the SCHC gateway, computed RCS is 1025 correct so the following ACK is sent to the device by the SCHC 1026 receiver: 1028 | LoRaWAN Header | LoRaWAN payload | 1029 + -------------- + --------- + ------------------- + 1030 | | RuleID=20 | W | C | Padding | 1031 + -------------- + --------- + ----- + - + ------- + 1032 | XXXX | 1 byte | 0 0 | 1 | 5 bits | 1034 Figure 24: Uplink example: LoRaWAN packet 5 - SCHC ACK 1036 A.3. Downlink 1038 An applicative payload of 443 bytes is passed to SCHC compression 1039 layer. Rule 1 is used by C/D layer, allowing to compress it to 130 1040 bytes and 5 bits: 1 byte RuleID, 21 bits residue + 127 bytes payload. 1042 | RuleID | Compression residue | Payload | 1043 + ------ + ------------------- + --------- + 1044 | 1 | 21 bits | 127 bytes | 1046 Figure 25: Downlink example: SCHC Message 1048 The current LoRaWAN MTU is 51 bytes, no FOpts are used by LoRaWAN 1049 protocol: 51 bytes are available for SCHC payload + FPort field => it 1050 has to be fragmented. 1052 | LoRaWAN Header | LoRaWAN payload (51 bytes) | 1053 + ---- + ---------- + -------------------------------------- + 1054 | | RuleID=21 | W = 0 | FCN = 0 | 1 tile | 1055 + ---- + ---------- + ------ + ------- + ------------------- + 1056 | XXXX | 1 byte | 1 bit | 1 bit | 50 bytes and 6 bits | 1058 Figure 26: Downlink example: LoRaWAN packet 1 - SCHC Fragment 1 1060 Content of the tile is: 1062 | RuleID | Compression residue | Payload | 1063 + ------ + ------------------- + ------------------ + 1064 | 1 | 21 bits | 48 bytes and 1 bit | 1066 Figure 27: Downlink example: LoRaWAN packet 1: Tile content 1068 The receiver answers with a SCHC ACK: 1070 | LoRaWAN Header | LoRaWAN payload | 1071 + ---- + --------- + -------------------------------- + 1072 | | RuleID=21 | W = 0 | C = 1 | Padding=b'000000 | 1073 + ---- + --------- + ----- + ----- + ---------------- + 1074 | XXXX | 1 byte | 1 bit | 1 bit | 6 bits | 1076 Figure 28: Downlink example: LoRaWAN packet 2 - SCHC ACK 1078 The second downlink is sent, two FOpts: 1080 | LoRaWAN Header | LoRaWAN payload (49 bytes) | 1081 + --------------------------- + ------------------------------------- + 1082 | | FOpts | RuleID=21 | W = 1 | FCN = 0 | 1 tile | 1083 + ---- + ------- + ---------- + ----- + ------- + ------------------- + 1084 | XXXX | 2 bytes | 1 byte | 1 bit | 1 bit | 48 bytes and 6 bits | 1086 Figure 29: Downlink example: LoRaWAN packet 3 - SCHC Fragment 2 1088 The receiver answers with an SCHC ACK: 1090 | LoRaWAN Header | LoRaWAN payload | 1091 + ---- + --------- + -------------------------------- + 1092 | | RuleID=21 | W = 1 | C = 1 | Padding=b'000000 | 1093 + ---- + --------- + ----- + ----- + ---------------- + 1094 | XXXX | 1 byte | 1 bit | 1 bit | 6 bits | 1096 Figure 30: Downlink example: LoRaWAN packet 4 - SCHC ACK 1098 The last downlink is sent, no FOpts: 1100 | LoRaWAN Header | LoRaWAN payload (37 bytes) | 1101 + ---- + --------- + ----------------------------------------------------------------- + 1102 | | RuleID=21 | W = 0 | FCN = 1 | RCS | 1 tile | Padding=b'00000 | 1103 + ---- + --------- + ------- + ------- + ------- + ----------------- + --------------- + 1104 | XXXX | 1 byte | 1 bit | 1 bit | 4 bytes | 31 bytes + 1 bits | 5 bits | 1106 Figure 31: Uplink example: LoRaWAN packet 5 - All-1 message 1108 The receiver answers to the sender with an SCHC ACK: 1110 | LoRaWAN Header | LoRaWAN payload | 1111 + ---- + --------- + -------------------------------- + 1112 | | RuleID=21 | W = 0 | C = 1 | Padding=b'000000 | 1113 + ---- + --------- + ----- + ----- + ---------------- + 1114 | XXXX | 1 byte | 1 bit | 1 bit | 6 bits | 1116 Figure 32: Uplink example: LoRaWAN packet 6 - SCHC ACK 1118 Authors' Addresses 1120 Olivier Gimenez (editor) 1121 Semtech 1122 14 Chemin des Clos 1123 Meylan 1124 France 1126 Email: ogimenez@semtech.com 1128 Ivaylo Petrov (editor) 1129 Acklio 1130 1137A Avenue des Champs Blancs 1131 35510 Cesson-Sevigne Cedex 1132 France 1134 Email: ivaylo@ackl.io