idnits 2.17.1 draft-ietf-lpwan-schc-over-lorawan-10.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 : ---------------------------------------------------------------------------- ** There are 19 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 (September 18, 2020) is 1315 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Downref: Normative reference to an Informational RFC: RFC 4493 ** Downref: Normative reference to an Informational RFC: RFC 8065 ** Downref: Normative reference to an Informational RFC: RFC 8376 Summary: 4 errors (**), 0 flaws (~~), 1 warning (==), 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: Standards Track I. Petrov, Ed. 5 Expires: March 22, 2021 Acklio 6 September 18, 2020 8 Static Context Header Compression (SCHC) over LoRaWAN 9 draft-ietf-lpwan-schc-over-lorawan-10 11 Abstract 13 The Static Context Header Compression (SCHC) specification describes 14 generic header compression and fragmentation techniques for Low Power 15 Wide Area Networks (LPWAN) technologies. SCHC is a generic mechanism 16 designed for great flexibility so that it can be adapted for any of 17 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 March 22, 2021. 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 . . . . . . . . . . . . . . . . . . . . . . . . 3 58 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 59 3. Static Context Header Compression Overview . . . . . . . . . 4 60 4. LoRaWAN Architecture . . . . . . . . . . . . . . . . . . . . 5 61 4.1. Device classes (A, B, C) and interactions . . . . . . . . 6 62 4.2. Device addressing . . . . . . . . . . . . . . . . . . . . 7 63 4.3. General Frame Types . . . . . . . . . . . . . . . . . . . 8 64 4.4. LoRaWAN MAC Frames . . . . . . . . . . . . . . . . . . . 8 65 4.5. LoRaWAN FPort . . . . . . . . . . . . . . . . . . . . . . 8 66 4.6. LoRaWAN empty frame . . . . . . . . . . . . . . . . . . . 9 67 4.7. Unicast and multicast technology . . . . . . . . . . . . 9 68 5. SCHC-over-LoRaWAN . . . . . . . . . . . . . . . . . . . . . . 9 69 5.1. LoRaWAN FPort and RuleID . . . . . . . . . . . . . . . . 9 70 5.2. Rule ID management . . . . . . . . . . . . . . . . . . . 10 71 5.3. Interface IDentifier (IID) computation . . . . . . . . . 11 72 5.4. Padding . . . . . . . . . . . . . . . . . . . . . . . . . 11 73 5.5. Decompression . . . . . . . . . . . . . . . . . . . . . . 12 74 5.6. Fragmentation . . . . . . . . . . . . . . . . . . . . . . 12 75 5.6.1. DTag . . . . . . . . . . . . . . . . . . . . . . . . 12 76 5.6.2. Uplink fragmentation: From device to SCHC gateway . . 12 77 5.6.3. Downlink fragmentation: From SCHC gateway to device . 15 78 5.7. SCHC Fragment Format . . . . . . . . . . . . . . . . . . 19 79 5.7.1. All-0 SCHC fragment . . . . . . . . . . . . . . . . . 19 80 5.7.2. All-1 SCHC fragment . . . . . . . . . . . . . . . . . 19 81 5.7.3. Delay after each message to respect local regulation 19 82 6. Security considerations . . . . . . . . . . . . . . . . . . . 19 83 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 84 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 19 85 Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 20 86 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 20 87 10.1. Normative References . . . . . . . . . . . . . . . . . . 20 88 10.2. Informative References . . . . . . . . . . . . . . . . . 21 89 Appendix A. Examples . . . . . . . . . . . . . . . . . . . . . . 21 90 A.1. Uplink - Compression example - No fragmentation . . . . . 21 91 A.2. Uplink - Compression and fragmentation example . . . . . 22 92 A.3. Downlink . . . . . . . . . . . . . . . . . . . . . . . . 24 93 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 26 95 1. Introduction 97 SCHC specification [RFC8724] describes generic header compression and 98 fragmentation techniques that can be used on all LPWAN technologies 99 defined in [RFC8376]. Even though those technologies share a great 100 number of common features like star-oriented topologies, network 101 architecture, devices with mostly quite predictable communications, 102 etc; they do have some slight differences in respect to payload 103 sizes, reactiveness, etc. 105 SCHC provides a generic framework that enables those devices to 106 communicate with other Internet networks. However, for efficient 107 performance, some parameters and modes of operation need to be set 108 appropriately for each of the LPWAN technologies. 110 This document describes the efficient parameters and modes of 111 operation when SCHC is used over LoRaWAN networks. 113 2. Terminology 115 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 116 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 117 "OPTIONAL" in this document are to be interpreted as described in BCP 118 14 [RFC2119] [RFC8174] when, and only when, they appear in all 119 capitals, as shown here. 121 This section defines the terminology and acronyms used in this 122 document. For all other definitions, please look up the SCHC 123 specification [RFC8724]. 125 o DevEUI: an IEEE EUI-64 identifier used to identify the device 126 during the procedure while joining the network (Join Procedure). 127 It is assigned by the manufacturer or the device owner and 128 provisioned on the Network Gateway. 130 o DevAddr: a 32-bit non-unique identifier assigned to a device 131 either: 133 * Statically: by the device manufacturer in _Activation by 134 Personalization_ mode. 136 * Dynamically: after a Join Procedure by the Network Gateway in 137 _Over The Air Activation_ mode. 139 o Downlink: LoRaWAN term for a message transmitted by the network 140 and received by the device. 142 o OUI: Organisation Unique Identifier. IEEE assigned prefix for 143 EUI. 145 o RCS: Reassembly Check Sequence. Used to verify the integrity of 146 the fragmentation-reassembly process. 148 o SCHC gateway: It corresponds to the LoRaWAN Application Server. 149 It manages translation between IPv6 network and the Network 150 Gateway (LoRaWAN Network Server). 152 o Uplink: LoRaWAN term for a message transmitted by the device and 153 received by the network. 155 3. Static Context Header Compression Overview 157 This section contains a short overview of SCHC. For a detailed 158 description, refer to the full specification [RFC8724]. 160 It defines: 162 1. Compression mechanisms to avoid transporting information known by 163 both sender and receiver over the air. Known information are 164 part of the "context". This component is called SCHC Compressor/ 165 Decompressor (SCHC C/D) 167 2. Fragmentation mechanisms to allow SCHC Packet transportation on 168 small, and potentially variable, MTU. This component called SCHC 169 Fragmentation/Reassembly (SCHC F/R) 171 Context exchange or pre-provisioning is out of scope of this 172 document. 174 Device App 175 +----------------+ +----+ +----+ +----+ 176 | App1 App2 App3 | |App1| |App2| |App3| 177 | | | | | | | | 178 | UDP | |UDP | |UDP | |UDP | 179 | IPv6 | |IPv6| |IPv6| |IPv6| 180 | | | | | | | | 181 |SCHC C/D and F/R| | | | | | | 182 +--------+-------+ +----+ +----+ +----+ 183 | +---+ +----+ +----+ +----+ . . . 184 +~ |RGW| === |NGW | == |SCHC| == |SCHC|...... Internet .... 185 +---+ +----+ |F/R | |C/D | 186 +----+ +----+ 188 Figure 1: Architecture 190 Figure 1 represents the architecture for compression/decompression, 191 it is based on [RFC8376] terminology. The device is sending 192 applications flows using IPv6 or IPv6/UDP protocols. These flows 193 might be compressed by a Static Context Header Compression 194 Compressor/Decompressor (SCHC C/D) to reduce headers size and 195 fragmented by the SCHC Fragmentation/Reassembly (SCHC F/R). The 196 resulting information is sent on a layer two (L2) frame to an LPWAN 197 Radio Gateway (RGW) that forwards the frame to a Network Gateway 198 (NGW). The NGW sends the data to a SCHC F/R for reassembly, if 199 required, then to SCHC C/D for decompression. The SCHC C/D shares 200 the same rules with the device. The SCHC C/D and F/R can be located 201 on the Network Gateway (NGW) or in another place as long as a 202 communication is established between the NGW and the SCHC F/R, then 203 SCHC F/R and C/D. The SCHC C/D and F/R in the device and the SCHC 204 gateway MUST share the same set of rules. After decompression, the 205 packet can be sent on the Internet to one or several LPWAN 206 Application Servers (App). 208 The SCHC C/D and F/R process is bidirectional, so the same principles 209 can be applied in the other direction. 211 In a LoRaWAN network, the RG is called a Gateway, the NGW is Network 212 Server, and the SCHC C/D and F/R are an Application Server. It can 213 be provided by the Network Gateway or any third party software. 214 Figure 1 can be mapped in LoRaWAN terminology to: 216 End Device App 217 +--------------+ +----+ +----+ +----+ 218 |App1 App2 App3| |App1| |App2| |App3| 219 | | | | | | | | 220 | UDP | |UDP | |UDP | |UDP | 221 | IPv6 | |IPv6| |IPv6| |IPv6| 222 | | | | | | | | 223 |SCHC C/D & F/R| | | | | | | 224 +-------+------+ +----+ +----+ +----+ 225 | +-------+ +-------+ +-----------+ . . . 226 +~ |Gateway| === |Network| == |Application|..... Internet .... 227 +-------+ |server | |server | 228 +-------+ | F/R - C/D | 229 +-----------+ 231 Figure 2: SCHC Architecture mapped to LoRaWAN 233 4. LoRaWAN Architecture 235 An overview of LoRaWAN [lora-alliance-spec] protocol and architecture 236 is described in [RFC8376]. The mapping between the LPWAN 237 architecture entities as described in [RFC8724] and the ones in 238 [lora-alliance-spec] is as follows: 240 o Devices are LoRaWAN End Devices (e.g. sensors, actuators, etc.). 241 There can be a very high density of devices per radio gateway 242 (LoRaWAN gateway). This entity maps to the LoRaWAN end-device. 244 o The Radio Gateway (RGW), which is the endpoint of the constrained 245 link. This entity maps to the LoRaWAN Gateway. 247 o The Network Gateway (NGW) is the interconnection node between the 248 Radio Gateway and the Internet. This entity maps to the LoRaWAN 249 Network Server. 251 o SCHC C/D and F/R are LoRaWAN Application Server; ie the LoRaWAN 252 application server will do the SCHC C/D and F/R. 254 () () () | +------+ 255 () () () () / \ +---------+ | Join | 256 () () () () () / \======| ^ |===|Server| +-----------+ 257 () () () | | <--|--> | +------+ |Application| 258 () () () () / \==========| v |=============| Server | 259 () () () / \ +---------+ +-----------+ 260 End Devices Gateways Network Server 262 Figure 3: LPWAN Architecture 264 SCHC Compressor/Decompressor (SCHC C/D) and SCHC Fragmentation/ 265 Reassembly (SCHC F/R) are performed on the LoRaWAN end-device and the 266 Application Server (called SCHC gateway). While the point-to-point 267 link between the device and the Application Server constitutes single 268 IP hop, the ultimate end-point of the IP communication may be an 269 Internet node beyond the Application Server. In other words, the 270 LoRaWAN Application Server (SCHC gateway) acts as the first hop IP 271 router for the device. The Application Server and Network Server may 272 be co-located, which effectively turns the Network/Application Server 273 into the first hop IP router. 275 4.1. Device classes (A, B, C) and interactions 277 The LoRaWAN MAC layer supports 3 classes of devices named A, B and C. 278 All devices implement the Class A, some devices may implement Class B 279 or Class C. Class B and Class C are mutually exclusive. 281 o Class A: The Class A is the simplest class of devices. The device 282 is allowed to transmit at any time, randomly selecting a 283 communication channel. The Network Gateway may reply with a 284 downlink in one of the 2 receive windows immediately following the 285 uplinks. Therefore, the Network Gateway cannot initiate a 286 downlink, it has to wait for the next uplink from the device to 287 get a downlink opportunity. The Class A is the lowest power 288 consumption class. 290 o Class B: Class B devices implement all the functionalities of 291 Class A devices, but also schedule periodic listen windows. 292 Therefore, opposed to the Class A devices, Class B devices can 293 receive downlinks that are initiated by the Network Gateway and 294 not following an uplink. There is a trade-off between the 295 periodicity of those scheduled Class B listen windows and the 296 power consumption of the device. The lower the downlink latency, 297 the higher the power consumption. 299 o Class C: Class C devices implement all the functionalities of 300 Class A devices, but keep their receiver open whenever they are 301 not transmitting. Class C devices can receive downlinks at any 302 time at the expense of a higher power consumption. Battery- 303 powered devices can only operate in Class C for a limited amount 304 of time (for example for a firmware upgrade over-the-air). Most 305 of the Class C devices are grid powered (for example Smart Plugs). 307 4.2. Device addressing 309 LoRaWAN end-devices use a 32-bit network address (devAddr) to 310 communicate with the Network Gateway over-the-air, this address might 311 not be unique in a LoRaWAN network; devices using the same devAddr 312 are distinguished by the Network Gateway based on the cryptographic 313 signature appended to every LoRaWAN frame. 315 To communicate with the SCHC gateway the Network Gateway MUST 316 identify the devices by a unique 64-bit device identifier called the 317 DevEUI. 319 The DevEUI is assigned to the device during the manufacturing process 320 by the device's manufacturer. It is built like an Ethernet MAC 321 address by concatenating the manufacturer's IEEE OUI field with a 322 vendor unique number. e.g.: 24-bit OUI is concatenated with a 40-bit 323 serial number. The Network Gateway translates the devAddr into a 324 DevEUI in the uplink direction and reciprocally on the downlink 325 direction. 327 +--------+ +---------+ +---------+ +----------+ 328 | Device | <=====> | Network | <====> | SCHC | <========> | Internet | 329 | | devAddr | Gateway | DevEUI | Gateway | IPv6/UDP | | 330 +--------+ +---------+ +---------+ +----------+ 332 Figure 4: LoRaWAN addresses 334 4.3. General Frame Types 336 LoRaWAN implements the possibility to send confirmed or unconfirmed 337 messages: 339 o Confirmed message: The sender asks the receiver to acknowledge the 340 message. 342 o Unconfirmed message: The sender does not ask the receiver to 343 acknowledge the message. 345 As SCHC defines its own acknowledgment mechanisms, SCHC does not 346 require to use LoRaWAN Confirmed messages. 348 4.4. LoRaWAN MAC Frames 350 In addition to regular data frames LoRaWAN implements JoinRequest and 351 JoinAccept frame types, used by a device to join a network: 353 o JoinRequest: This message is used by a device to join a network. 354 It contains the device's unique identifier DevEUI and a random 355 nonce that will be used for session key derivation. 357 o JoinAccept: To on-board a device, the Network Gateway responds to 358 the JoinRequest issued by a device with a JoinAccept message. 359 That message is encrypted with the device's AppKey and contains 360 (amongst other fields) the major network's settings and a random 361 nonce used to derive the session keys. 363 o Data: MAC and application data. Application data are protected 364 with AES-128 encryption, MAC related data are AES-128 encrypted 365 with another key. 367 4.5. LoRaWAN FPort 369 The LoRaWAN MAC layer features a frame port field in all frames. 370 This field (FPort) is 8 bits long and the values from 1 to 223 can be 371 used. It allows LoRaWAN networks and applications to identify data. 373 4.6. LoRaWAN empty frame 375 A LoRaWAN empty frame is a LoRaWAN message without FPort (cf 376 Section 5.1) and FRMPayload. 378 4.7. Unicast and multicast technology 380 LoRaWAN technology supports unicast downlinks, but also multicast: a 381 packet send over LoRaWAN radio link can be received by several 382 devices. It is useful to address many devices with same content, 383 either a large binary file (firmware upgrade), or same command (e.g: 384 lighting control). As IPv6 is also a multicast technology this 385 feature can be used to address a group of devices. 387 _Note 1_: IPv6 multicast addresses must be defined as per [RFC4291]. 388 LoRaWAN multicast group definition in a Network Gateway and the 389 relation between those groups and IPv6 groupID are out of scope of 390 this document. 392 _Note 2_: LoRa Alliance defined [lora-alliance-remote-multicast-set] 393 as RECOMMENDED way to setup multicast groups on devices and create a 394 synchronized reception window. 396 5. SCHC-over-LoRaWAN 398 5.1. LoRaWAN FPort and RuleID 400 The FPort field is part of the SCHC Message, as shown in Figure 5. 401 The SCHC C/D and the SCHC F/R SHALL concatenate the FPort field with 402 the LoRaWAN payload to retrieve their payload as it is used as a part 403 of the RuleID field. 405 | FPort | LoRaWAN payload | 406 + ------------------------ + 407 | SCHC packet | 409 Figure 5: SCHC Message in LoRaWAN 411 A fragmentation datagram with application payload transferred from 412 device to Network Gateway, is called uplink fragmentation datagram. 413 It uses an FPort for data uplink and its associated SCHC control 414 downlinks, named FPortUp in this document. The other way, a 415 fragmentation datagram with application payload transferred from 416 Network Gateway to device, is called downlink fragmentation datagram. 417 It uses another FPort for data downlink and its associated SCHC 418 control uplinks, named FPortDown in this document. 420 All RuleID can use arbitrary values inside the FPort range allowed by 421 LoRaWAN specification and MUST be shared by the device and SCHC 422 gateway prior to the communication with the selected rule. The 423 uplink and downlink fragmentation FPorts MUST be different. 425 5.2. Rule ID management 427 RuleID MUST be 8 bits, encoded in the LoRaWAN FPort as described in 428 Section 5.1. LoRaWAN supports up to 223 application FPorts in the 429 range [1;223] as defined in section 4.3.2 of [lora-alliance-spec], it 430 implies that RuleID MSB SHOULD be inside this range. An application 431 can send non SCHC traffic by using FPort values different from the 432 ones used for SCHC. 434 In order to improve interoperability RECOMMENDED fragmentation RuleID 435 values are: 437 o RuleID = 20 (8-bit) for uplink fragmentation, named FPortUp. 439 o RuleID = 21 (8-bit) for downlink fragmentation, named FPortDown. 441 o RuleID = 22 (8-bit) for which SCHC compression was not possible 442 (no matching rule was found). 444 The remaining RuleIDs are available for compression. RuleIDs are 445 shared between uplink and downlink sessions. A RuleID not in the 446 set(s) of FPortUp or FPortDown means that the fragmentation is not 447 used, thus, on reception, the SCHC Message MUST be sent to the SCHC 448 C/D layer. 450 The only uplink messages using the FPortDown port are the 451 fragmentation SCHC control messages of a downlink fragmentation 452 datagram (for example, SCHC ACKs). Similarly, the only downlink 453 messages using the FPortUp port are the fragmentation SCHC control 454 messages of an uplink fragmentation datagram. 456 An application can have multiple fragmentation datagrams between a 457 device and one or several SCHC gateways. A set of FPort values is 458 REQUIRED for each SCHC gateway instance the device is required to 459 communicate with. The application can use additional uplinks or 460 downlink fragmentation parameters but SHALL implement at least the 461 parameters defined in this document. 463 The mechanism for sharing those RuleID values is outside the scope of 464 this document. 466 5.3. Interface IDentifier (IID) computation 468 In order to mitigate risks described in [RFC8064] and [RFC8065] IID 469 MUST be created regarding the following algorithm: 471 1. key = LoRaWAN AppSKey 473 2. cmac = aes128_cmac(key, DevEUI) 475 3. IID = cmac[0..7] 477 aes128_cmac algorithm is described in [RFC4493]. It has been chosen 478 as it is already used by devices for LoRaWAN protocol. 480 As AppSKey is renewed each time a device joins or rejoins a LoRaWAN 481 network, the IID will change over time; this mitigates privacy, 482 location tracking and correlation over time risks. Join periodicity 483 is defined at the application level. 485 Address scan risk is mitigated thanks to AES-128, which provides 486 enough entropy bits of the IID. 488 Using this algorithm will also ensure that there is no correlation 489 between the hardware identifier (IEEE-64 DevEUI) and the IID, so an 490 attacker cannot use manufacturer OUI to target devices. 492 Example with: 494 o DevEUI: 0x1122334455667788 496 o appSKey: 0x00AABBCCDDEEFF00AABBCCDDEEFFAABB 498 1. key: 0x00AABBCCDDEEFF00AABBCCDDEEFFAABB 499 2. cmac: 0xBA59F4B196C6C3432D9383C145AD412A 500 3. IID: 0xBA59F4B196C6C343 502 Figure 6: Example of IID computation. 504 There is a small probability of IID collision in a LoRaWAN network, 505 if such event occurs the IID can be changed by rekeying the device on 506 L2 level (ie: trigger a LoRaWAN join). The way the device is rekeyed 507 is out of scope of this document and left to the implementation. 509 5.4. Padding 511 All padding bits MUST be 0. 513 5.5. Decompression 515 SCHC C/D MUST concatenate FPort and LoRaWAN payload to retrieve the 516 SCHC Packet as per Section 5.1. 518 RuleIDs matching FPortUp and FPortDown are reserved for SCHC 519 Fragmentation. 521 5.6. Fragmentation 523 The L2 Word Size used by LoRaWAN is 1 byte (8 bits). The SCHC 524 fragmentation over LoRaWAN uses the ACK-on-Error mode for uplink 525 fragmentation and Ack-Always mode for downlink fragmentation. A 526 LoRaWAN device cannot support simultaneous interleaved fragmentation 527 datagrams in the same direction (uplink or downlink). 529 The fragmentation parameters are different for uplink and downlink 530 fragmentation datagrams and are successively described in the next 531 sections. 533 5.6.1. DTag 535 A Device cannot interleave several fragmented SCHC datagrams on the 536 same FPort. This field is not used and its size is 0. 538 Note: The device can still have several parallel fragmentation 539 datagrams with one or more SCHC gateway(s) thanks to distinct sets of 540 FPorts, cf Section 5.2 542 5.6.2. Uplink fragmentation: From device to SCHC gateway 544 In that case the device is the fragmentation transmitter, and the 545 SCHC gateway the fragmentation receiver. A single fragmentation rule 546 is defined. SCHC F/R MUST concatenate FPort and LoRaWAN payload to 547 retrieve the SCHC Packet, as per Section 5.1. 549 o SCHC header size is two bytes (the FPort byte + 1 additional 550 byte). 552 o RuleID: 8 bits stored in LoRaWAN FPort. 554 o SCHC fragmentation reliability mode: "ACK-on-Error". 556 o DTag: Size is 0 bit, not used. 558 o FCN: The FCN field is encoded on N = 6 bits, so WINDOW_SIZE = 63 559 tiles are allowed in a window. 561 o Window index: encoded on W = 2 bits. So 4 windows are available. 563 o RCS: Use recommended calculation algorithm in [RFC8724]. 565 o MAX_ACK_REQUESTS: 8. 567 o Tile: size is 10 bytes. 569 o Retransmission timer: Set by the implementation depending on the 570 application requirements. 572 o Inactivity timer: The SCHC gateway implements an "inactivity 573 timer". The default RECOMMENDED duration of this timer is 12 574 hours; this value is mainly driven by application requirements and 575 MAY be changed by the application. 577 o Penultimate tile MUST be equal to the regular size. 579 o Last tile: it can be carried in a Regular SCHC Fragment, alone in 580 an All-1 SCHC Fragment or with any of these two methods. 581 Implementation must ensure that: 583 * The sender MUST ascertain that the receiver will not receive 584 the last tile through both a Regular SCHC Fragment and an All-1 585 SCHC Fragment. 587 * If last tile is in All-1 message: current L2 MTU MUST be big 588 enough to fit the All-1 and the last tile. 590 With this set of parameters, the SCHC fragment header is 16 bits, 591 including FPort; payload overhead will be 8 bits as FPort is already 592 a part of LoRaWAN payload. MTU is: _4 windows * 63 tiles * 10 bytes 593 per tile = 2520 bytes_ 595 For battery powered devices, it is RECOMMENDED to use the ACK 596 mechanism at the end of each window instead of waiting until the end 597 of all windows: 599 o SCHC receiver SHOULD send a SCHC ACK after every window even if 600 there is no missing tile. 602 o SCHC sender SHOULD wait for the SCHC ACK from the SCHC receiver 603 before sending tiles from the next window. If the SCHC ACK is not 604 received, it SHOULD send an SCHC ACK REQ up to MAX_ACK_REQUESTS, 605 time as described previously. 607 For non-battery powered devices, SCHC receiver MAY also choose to 608 send a SCHC ACK only at the end of all windows. It will reduce 609 downlink load on the LoRaWAN network, by reducing the number of 610 downlinks. 612 SCHC implementations MUST be compatible with both behavior, and 613 selection is a part of the rule context. 615 5.6.2.1. Regular fragments 617 | FPort | LoRaWAN payload | 618 + ------ + ------------------------- + 619 | RuleID | W | FCN | Payload | 620 + ------ + ------ + ------ + ------- + 621 | 8 bits | 2 bits | 6 bits | | 623 Figure 7: All fragments except the last one. SCHC header size is 16 624 bits, including LoRaWAN FPort. 626 5.6.2.2. Last fragment (All-1) 628 | FPort | LoRaWAN payload | 629 + ------ + ---------------------------- + 630 | RuleID | W | FCN=All-1 | RCS | 631 + ------ + ------ + --------- + ------- + 632 | 8 bits | 2 bits | 6 bits | 32 bits | 634 Figure 8: All-1 SCHC Message: the last fragment without last tile. 636 | FPort | LoRaWAN payload | 637 + ------ + ------------------------------------------- + 638 | RuleID | W | FCN=All-1 | RCS | Last tile | 639 + ------ + ------ + --------- + ------- + ------------ + 640 | 8 bits | 2 bits | 6 bits | 32 bits | 1 to 80 bits | 642 Figure 9: All-1 SCHC Message: the last fragment with last tile. 644 5.6.2.3. SCHC ACK 646 | FPort | LoRaWAN payload | 647 + ------ + -------------------------------------------------------------------- + 648 | RuleID | W | C | Compressed bitmap(C = 0) | Optional padding(b'0...0) | 649 + ------ + ----- + ----- + ------------------------ + ------------------------- + 650 | 8 bits | 2 bit | 1 bit | 5 to 63 bits | 0, 6 or 7 bits | 652 Figure 10: SCHC ACK format, failed RCS check. 654 Note: Because of the bitmap compression mechanism and L2 byte 655 alignment only few discrete values are possible: 5, 13, 21, 29, 37, 656 45, 53, 61, 62, 63. Bitmaps of 63 bits will require 6 bits of 657 padding. 659 5.6.2.4. Receiver-Abort 661 | FPort | LoRaWAN payload | 662 + ------ + -------------------------------------------- + 663 | RuleID | W = b'11 | C = 1 | b'11111 | 0xFF (all 1's) | 664 + ------ + -------- + ------+-------- + ----------------+ 665 | 8 bits | 2 bits | 1 bit | 5 bits | 8 bits | 666 next L2 Word boundary ->| <-- L2 Word --> | 668 Figure 11: Receiver-Abort format. 670 5.6.2.5. SCHC acknowledge request 672 | FPort | LoRaWAN payload | 673 +------- +------------------------- + 674 | RuleID | W | FCN = b'000000 | 675 + ------ + ------ + --------------- + 676 | 8 bits | 2 bits | 6 bits | 678 Figure 12: SCHC ACK REQ format. 680 5.6.3. Downlink fragmentation: From SCHC gateway to device 682 In that case the device is the fragmentation receiver, and the SCHC 683 gateway the fragmentation transmitter. The following fields are 684 common to all devices. SCHC F/R MUST concatenate FPort and LoRaWAN 685 payload to retrieve the SCHC Packet as described in Section 5.1. 687 o SCHC fragmentation reliability mode: 689 * Unicast downlinks: ACK-Always. 691 * Multicast downlinks: No-ACK, reliability has to be ensured by 692 the upper layer. This feature is OPTIONAL and may not be 693 implemented by SCHC gateway. 695 o RuleID: 8 bits stored in LoRaWAN FPort. 697 o Window index (unicast only): encoded on W=1 bit, as per [RFC8724]. 699 o DTag: Size is 0 bit, not used. 701 o FCN: The FCN field is encoded on N=1 bit, so WINDOW_SIZE = 1 tile. 703 o RCS: Use recommended calculation algorithm in [RFC8724]. 705 o MAX_ACK_REQUESTS: 8. 707 o Retransmission timer: See Section 5.6.3.5. 709 o Inactivity timer: The default RECOMMENDED duration of this timer 710 is 12 hours; this value is mainly driven by application 711 requirements and MAY be changed by the application. 713 As only 1 tile is used, its size can change for each downlink, and 714 will be maximum available MTU. 716 Class A devices can only receive during an RX slot, following the 717 transmission of an uplink. Therefore the SCHC gateway cannot 718 initiate communication (ex: new SCHC session); in order to create a 719 downlink opportunity it is RECOMMENDED for Class A devices to send an 720 uplink every 24 hours when no SCHC session is started, this is 721 application specific and can be disabled. RECOMMENDED uplink is a 722 LoRaWAN empty frame as defined Section 4.6. As this uplink is to 723 open an RX window any applicative uplink MAY reset this counter. 725 _Note_: The Fpending bit included in LoRaWAN protocol SHOULD NOT be 726 used for SCHC-over-LoRaWAN protocol. It might be set by the Network 727 Gateway for other purposes but not SCHC needs. 729 5.6.3.1. Regular fragments 731 | FPort | LoRaWAN payload | 732 + ------ + ------------------------------------ + 733 | RuleID | W | FCN = b'0 | Payload | 734 + ------ + ----- + --------- + ---------------- + 735 | 8 bits | 1 bit | 1 bit | X bytes + 6 bits | 737 Figure 13: All fragments but the last one. Header size 10 bits, 738 including LoraWAN FPort. 740 5.6.3.2. Last fragment (All-1) 741 | FPort | LoRaWAN payload | 742 + ------ + --------------------------- + ----------------- + 743 | RuleID | W | FCN = b'1 | RCS | Payload | 744 + ------ + ----- + --------- + ------- + ----------------- + 745 | 8 bits | 1 bit | 1 bit | 32 bits | 6 bits to X bytes | 747 Figure 14: All-1 SCHC Message: the last fragment. 749 5.6.3.3. SCHC ACK 751 | FPort | LoRaWAN payload | 752 + ------ + ---------------------------------- + 753 | RuleID | W | C = b'1 | Padding b'000000 | 754 + ------ + ----- + ------- + ---------------- + 755 | 8 bits | 1 bit | 1 bit | 6 bits | 757 Figure 15: SCHC ACK format, RCS is correct. 759 5.6.3.4. Receiver-Abort 761 | FPort | LoRaWAN payload | 762 + ------ + ---------------------------------------------- + 763 | RuleID | W = b'1 | C = b'1 | b'111111 | 0xFF (all 1's) | 764 + ------ + ------- + ------- + -------- + --------------- + 765 | 8 bits | 1 bit | 1 bits | 6 bits | 8 bits | 766 next L2 Word boundary ->| <-- L2 Word --> | 768 Figure 16: Receiver-Abort packet (following an All-1 SCHC Fragment 769 with incorrect RCS). 771 5.6.3.5. Downlink retransmission timer 773 Class A and Class B or Class C devices do not manage retransmissions 774 and timers in the same way. 776 5.6.3.5.1. Class A devices 778 Class A devices can only receive in an RX slot following the 779 transmission of an uplink. 781 The SCHC gateway implements an inactivity timer with a RECOMMENDED 782 duration of 36 hours. For devices with very low transmission rates 783 (example 1 packet a day in normal operation), that duration may be 784 extended: it is application specific. 786 RETRANSMISSION_TIMER is application specific and its RECOMMENDED 787 value is INACTIVITY_TIMER/(MAX_ACK_REQUESTS + 1). 789 *SCHC All-0 (FCN=0)* All fragments but the last have an FCN=0 790 (because window size is 1). Following it the device MUST transmit 791 the SCHC ACK message. It MUST transmit up to MAX_ACK_REQUESTS SCHC 792 ACK messages before aborting. In order to progress the fragmentation 793 datagram, the SCHC layer should immediately queue for transmission 794 those SCHC ACK if no SCHC downlink have been received during RX1 and 795 RX2 window. LoRaWAN layer will respect the regulation if required. 797 _Note_: The ACK bitmap is 1 bit long and is always 1. 799 *SCHC All-1 (FCN=1)* SCHC All-1 is the last fragment of a datagram, 800 the corresponding SCHC ACK message might be lost; therefore the SCHC 801 gateway MUST request a retransmission of this ACK when the 802 retransmission timer expires. To open a downlink opportunity the 803 device MUST transmit an uplink every 804 RETRANSMISSION_TIMER/(MAX_ACK_REQUESTS * 805 SCHC_ACK_REQ_DN_OPPORTUNITY). The format of this uplink is 806 application specific. It is RECOMMENDED for a device to send an 807 empty frame (see Section 4.6) but it is application specific and will 808 be used by the NGW to transmit a potential SCHC ACK REQ. 809 SCHC_ACK_REQ_DN_OPPORTUNITY is application specific and its 810 recommended value is 2, it MUST be greater than 1. This allows to 811 open downlink opportunity to other eventual downlink with higher 812 priority than SCHC ACK REQ message. 814 _Note_: The device MUST keep this SCHC ACK message in memory until it 815 receives a downlink, on SCHC FPortDown different from an SCHC ACK 816 REQ: it indicates that the SCHC gateway has received the ACK message. 818 5.6.3.6. Class B or Class C devices 820 Class B devices can receive in scheduled RX slots or in RX slots 821 following the transmission of an uplink. Class C devices are almost 822 in constant reception. 824 RECOMMENDED retransmission timer value: 826 o Class B: 3 times the ping slot periodicity. 828 o Class C: 30 seconds. 830 The RECOMMENDED inactivity timer value is 12 hours for both Class B 831 and Class C devices. 833 5.7. SCHC Fragment Format 835 5.7.1. All-0 SCHC fragment 837 *Uplink fragmentation (Ack-On-Error)*: 839 All-0 is distinguishable from a SCHC ACK REQ as [RFC8724] states 840 _This condition is also met if the SCHC Fragment Header is a multiple 841 of L2 Words_; this condition met: SCHC header is 2 bytes. 843 *Downlink fragmentation (Ack-always)*: 845 As per [RFC8724] the SCHC All-1 MUST contain the last tile, 846 implementation must ensure that All-0 message Payload will be at 847 least the size of an L2 Word. 849 5.7.2. All-1 SCHC fragment 851 All-1 is distinguishable from a SCHC Sender-Abort as [RFC8724] states 852 _This condition is met if the RCS is present and is at least the size 853 of an L2 Word_; this condition met: RCS is 4 bytes. 855 5.7.3. Delay after each message to respect local regulation 857 This profile does not define a delay to be added after each SCHC 858 message, local regulation compliance is expected to be enforced by 859 LoRaWAN stack. 861 6. Security considerations 863 This document is only providing parameters that are expected to be 864 best suited for LoRaWAN networks for [RFC8724]. IID security is 865 discussed in Section 5.3. As such, this document does not contribute 866 to any new security issues in addition to those identified in 867 [RFC8724]. Moreover, SCHC data (LoRaWAN payload) are protected on 868 LoRaWAN level by an AES-128 encryption with key shared by device and 869 SCHC gateway. Those keys are renewed at each LoRaWAN session (ie: 870 each join or rejoin to the LoRaWAN network) 872 7. IANA Considerations 874 This document has no IANA actions. 876 Acknowledgements 878 Thanks to all those listed in the Contributors section for the 879 excellent text, insightful discussions, reviews and suggestions, and 880 also to (in alphabetical order) Dominique Barthel, Arunprabhu 881 Kandasamy, Rodrigo Munoz, Alexander Pelov, Pascal Thubert, Laurent 882 Toutain for useful design considerations, reviews and comments. 884 Contributors 886 Contributors ordered by family name. 888 Vincent Audebert 889 EDF R&D 890 Email: vincent.audebert@edf.fr 892 Julien Catalano 893 Kerlink 894 Email: j.catalano@kerlink.fr 896 Michael Coracin 897 Semtech 898 Email: mcoracin@semtech.com 900 Marc Le Gourrierec 901 Sagemcom 902 Email: marc.legourrierec@sagemcom.com 904 Nicolas Sornin 905 Semtech 906 Email: nsornin@semtech.com 908 Alper Yegin 909 Actility 910 Email: alper.yegin@actility.com 912 10. References 914 10.1. Normative References 916 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 917 Requirement Levels", BCP 14, RFC 2119, 918 DOI 10.17487/RFC2119, March 1997, 919 . 921 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 922 Architecture", RFC 4291, DOI 10.17487/RFC4291, February 923 2006, . 925 [RFC4493] Song, JH., Poovendran, R., Lee, J., and T. Iwata, "The 926 AES-CMAC Algorithm", RFC 4493, DOI 10.17487/RFC4493, June 927 2006, . 929 [RFC8064] Gont, F., Cooper, A., Thaler, D., and W. Liu, 930 "Recommendation on Stable IPv6 Interface Identifiers", 931 RFC 8064, DOI 10.17487/RFC8064, February 2017, 932 . 934 [RFC8065] Thaler, D., "Privacy Considerations for IPv6 Adaptation- 935 Layer Mechanisms", RFC 8065, DOI 10.17487/RFC8065, 936 February 2017, . 938 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 939 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 940 May 2017, . 942 [RFC8376] Farrell, S., Ed., "Low-Power Wide Area Network (LPWAN) 943 Overview", RFC 8376, DOI 10.17487/RFC8376, May 2018, 944 . 946 [RFC8724] Minaburo, A., Toutain, L., Gomez, C., Barthel, D., and JC. 947 Zuniga, "SCHC: Generic Framework for Static Context Header 948 Compression and Fragmentation", RFC 8724, 949 DOI 10.17487/RFC8724, April 2020, 950 . 952 10.2. Informative References 954 [lora-alliance-remote-multicast-set] 955 Alliance, L., "LoRaWAN Remote Multicast Setup 956 Specification Version 1.0.0", . 960 [lora-alliance-spec] 961 Alliance, L., "LoRaWAN Specification Version V1.0.3", 962 . 965 Appendix A. Examples 967 A.1. Uplink - Compression example - No fragmentation 969 This example represents an applicative payload going through SCHC 970 over LoRaWAN, no fragmentation required 972 An applicative payload of 78 bytes is passed to SCHC compression 973 layer. Rule 1 is used by SCHC C/D layer, allowing to compress it to 974 40 bytes and 5 bits: 1 byte RuleID, 21 bits residue + 37 bytes 975 payload. 977 | RuleID | Compression residue | Payload | Padding=b'000 | 978 + ------ + ------------------- + --------- + ------------- + 979 | 1 | 21 bits | 37 bytes | 3 bits | 981 Figure 17: Uplink example: SCHC Message 983 The current LoRaWAN MTU is 51 bytes, although 2 bytes FOpts are used 984 by LoRaWAN protocol: 49 bytes are available for SCHC payload; no need 985 for fragmentation. The payload will be transmitted through FPort = 986 1. 988 | LoRaWAN Header | LoRaWAN payload (40 bytes) | 989 + ------------------------- + --------------------------------------- + 990 | | FOpts | RuleID=1 | Compression | Payload | Padding=b'000 | 991 | | | | residue | | | 992 + ---- + ------- + -------- + ----------- + --------- + ------------- + 993 | XXXX | 2 bytes | 1 byte | 21 bits | 37 bytes | 3 bits | 995 Figure 18: Uplink example: LoRaWAN packet 997 A.2. Uplink - Compression and fragmentation example 999 This example represents an applicative payload going through SCHC, 1000 with fragmentation. 1002 An applicative payload of 478 bytes is passed to SCHC compression 1003 layer. Rule 1 is used by SCHC C/D layer, allowing to compress it to 1004 282 bytes and 5 bits: 1 byte RuleID, 21 bits residue + 279 bytes 1005 payload. 1007 | RuleID | Compression residue | Payload | 1008 + ------ + ------------------- + --------- + 1009 | 1 | 21 bits | 279 bytes | 1011 Figure 19: Uplink example: SCHC Message 1013 The current LoRaWAN MTU is 11 bytes, 0 bytes FOpts are used by 1014 LoRaWAN protocol: 11 bytes are available for SCHC payload + 1 byte 1015 FPort field. SCHC header is 2 bytes (including FPort) so 1 tile is 1016 sent in first fragment. 1018 | LoRaWAN Header | LoRaWAN payload (11 bytes) | 1019 + -------------------------- + -------------------------- + 1020 | | RuleID=20 | W | FCN | 1 tile | 1021 + -------------- + --------- + ----- + ------ + --------- + 1022 | XXXX | 1 byte | 0 0 | 62 | 10 bytes | 1024 Figure 20: Uplink example: LoRaWAN packet 1 1026 Content of the tile is: 1027 | RuleID | Compression residue | Payload | 1028 + ------ + ------------------- + ----------------- + 1029 | 1 | 21 bits | 6 bytes + 3 bits | 1031 Figure 21: Uplink example: LoRaWAN packet 1 - Tile content 1033 Next transmission MTU is 11 bytes, although 2 bytes FOpts are used by 1034 LoRaWAN protocol: 9 bytes are available for SCHC payload + 1 byte 1035 FPort field, a tile does not fit inside so LoRaWAN stack will send 1036 only FOpts. 1038 Next transmission MTU is 242 bytes, 4 bytes FOpts. 23 tiles are 1039 transmitted: 1041 | LoRaWAN Header | LoRaWAN payload (231 bytes) | 1042 + --------------------------------------+ --------------------------- + 1043 | | FOpts | RuleID=20 | W | FCN | 23 tiles | 1044 + -------------- + ------- + ---------- + ----- + ----- + ----------- + 1045 | XXXX | 4 bytes | 1 byte | 0 0 | 61 | 230 bytes | 1047 Figure 22: Uplink example: LoRaWAN packet 2 1049 Next transmission MTU is 242 bytes, no FOpts. All 5 remaining tiles 1050 are transmitted, the last tile is only 2 bytes + 5 bits. Padding is 1051 added for the remaining 3 bits. 1053 | LoRaWAN Header | LoRaWAN payload (44 bytes) | 1054 + ---- + -----------+ ------------------------------------------------- + 1055 | | RuleID=20 | W | FCN | 5 tiles | Padding=b'000 | 1056 + ---- + ---------- + ----- + ----- + ----------------- + ------------- + 1057 | XXXX | 1 byte | 0 0 | 38 | 42 bytes + 5 bits | 3 bits | 1059 Figure 23: Uplink example: LoRaWAN packet 3 1061 Then All-1 message can be transmitted: 1063 | LoRaWAN Header | LoRaWAN payload (44 bytes) | 1064 + ---- + -----------+ -------------------------- + 1065 | | RuleID=20 | W | FCN | RCS | 1066 + ---- + ---------- + ----- + ----- + ---------- + 1067 | XXXX | 1 byte | 0 0 | 63 | 4 bytes | 1069 Figure 24: Uplink example: LoRaWAN packet 4 - All-1 message 1071 All packets have been received by the SCHC gateway, computed RCS is 1072 correct so the following ACK is sent to the device by the SCHC 1073 receiver: 1075 | LoRaWAN Header | LoRaWAN payload | 1076 + -------------- + --------- + ------------------- + 1077 | | RuleID=20 | W | C | Padding | 1078 + -------------- + --------- + ----- + - + ------- + 1079 | XXXX | 1 byte | 0 0 | 1 | 5 bits | 1081 Figure 25: Uplink example: LoRaWAN packet 5 - SCHC ACK 1083 A.3. Downlink 1085 An applicative payload of 443 bytes is passed to SCHC compression 1086 layer. Rule 1 is used by SCHC C/D layer, allowing to compress it to 1087 130 bytes and 5 bits: 1 byte RuleID, 21 bits residue + 127 bytes 1088 payload. 1090 | RuleID | Compression residue | Payload | 1091 + ------ + ------------------- + --------- + 1092 | 1 | 21 bits | 127 bytes | 1094 Figure 26: Downlink example: SCHC Message 1096 The current LoRaWAN MTU is 51 bytes, no FOpts are used by LoRaWAN 1097 protocol: 51 bytes are available for SCHC payload + FPort field => it 1098 has to be fragmented. 1100 | LoRaWAN Header | LoRaWAN payload (51 bytes) | 1101 + ---- + ---------- + -------------------------------------- + 1102 | | RuleID=21 | W = 0 | FCN = 0 | 1 tile | 1103 + ---- + ---------- + ------ + ------- + ------------------- + 1104 | XXXX | 1 byte | 1 bit | 1 bit | 50 bytes and 6 bits | 1106 Figure 27: Downlink example: LoRaWAN packet 1 - SCHC Fragment 1 1108 Content of the tile is: 1110 | RuleID | Compression residue | Payload | 1111 + ------ + ------------------- + ------------------ + 1112 | 1 | 21 bits | 48 bytes and 1 bit | 1114 Figure 28: Downlink example: LoRaWAN packet 1: Tile content 1116 The receiver answers with a SCHC ACK: 1118 | LoRaWAN Header | LoRaWAN payload | 1119 + ---- + --------- + -------------------------------- + 1120 | | RuleID=21 | W = 0 | C = 1 | Padding=b'000000 | 1121 + ---- + --------- + ----- + ----- + ---------------- + 1122 | XXXX | 1 byte | 1 bit | 1 bit | 6 bits | 1124 Figure 29: Downlink example: LoRaWAN packet 2 - SCHC ACK 1126 The second downlink is sent, two FOpts: 1128 | LoRaWAN Header | LoRaWAN payload (49 bytes) | 1129 + --------------------------- + ------------------------------------- + 1130 | | FOpts | RuleID=21 | W = 1 | FCN = 0 | 1 tile | 1131 + ---- + ------- + ---------- + ----- + ------- + ------------------- + 1132 | XXXX | 2 bytes | 1 byte | 1 bit | 1 bit | 48 bytes and 6 bits | 1134 Figure 30: Downlink example: LoRaWAN packet 3 - SCHC Fragment 2 1136 The receiver answers with an SCHC ACK: 1138 | LoRaWAN Header | LoRaWAN payload | 1139 + ---- + --------- + -------------------------------- + 1140 | | RuleID=21 | W = 1 | C = 1 | Padding=b'000000 | 1141 + ---- + --------- + ----- + ----- + ---------------- + 1142 | XXXX | 1 byte | 1 bit | 1 bit | 6 bits | 1144 Figure 31: Downlink example: LoRaWAN packet 4 - SCHC ACK 1146 The last downlink is sent, no FOpts: 1148 | LoRaWAN Header | LoRaWAN payload (37 bytes) | 1149 + ---- + --------- + ----------------------------------------------------------------- + 1150 | | RuleID=21 | W = 0 | FCN = 1 | RCS | 1 tile | Padding=b'00000 | 1151 + ---- + --------- + ------- + ------- + ------- + ----------------- + --------------- + 1152 | XXXX | 1 byte | 1 bit | 1 bit | 4 bytes | 31 bytes + 1 bits | 5 bits | 1154 Figure 32: Downlink example: LoRaWAN packet 5 - All-1 message 1156 The receiver answers to the sender with an SCHC ACK: 1158 | LoRaWAN Header | LoRaWAN payload | 1159 + ---- + --------- + -------------------------------- + 1160 | | RuleID=21 | W = 0 | C = 1 | Padding=b'000000 | 1161 + ---- + --------- + ----- + ----- + ---------------- + 1162 | XXXX | 1 byte | 1 bit | 1 bit | 6 bits | 1164 Figure 33: Downlink example: LoRaWAN packet 6 - SCHC ACK 1166 Authors' Addresses 1168 Olivier Gimenez (editor) 1169 Semtech 1170 14 Chemin des Clos 1171 Meylan 1172 France 1174 Email: ogimenez@semtech.com 1176 Ivaylo Petrov (editor) 1177 Acklio 1178 1137A Avenue des Champs Blancs 1179 35510 Cesson-Sevigne Cedex 1180 France 1182 Email: ivaylo@ackl.io