idnits 2.17.1 draft-ietf-lpwan-schc-over-lorawan-08.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 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 (July 12, 2020) is 1383 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC3385' is defined on line 890, but no explicit reference was found in the text == Unused Reference: 'RFC4944' is defined on line 904, but no explicit reference was found in the text == Unused Reference: 'RFC5795' is defined on line 909, but no explicit reference was found in the text == Unused Reference: 'RFC7136' is defined on line 914, 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: January 13, 2021 Acklio 6 July 12, 2020 8 Static Context Header Compression (SCHC) over LoRaWAN 9 draft-ietf-lpwan-schc-over-lorawan-08 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 January 13, 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 . . . . . . . . . . . . . . . . . . . 7 64 4.4. LoRaWAN MAC Frames . . . . . . . . . . . . . . . . . . . 8 65 4.5. LoRaWAN empty frame . . . . . . . . . . . . . . . . . . . 8 66 4.6. Unicast and multicast technology . . . . . . . . . . . . 8 67 5. SCHC-over-LoRaWAN . . . . . . . . . . . . . . . . . . . . . . 8 68 5.1. LoRaWAN FPort . . . . . . . . . . . . . . . . . . . . . . 8 69 5.2. Rule ID management . . . . . . . . . . . . . . . . . . . 9 70 5.3. IID computation . . . . . . . . . . . . . . . . . . . . . 10 71 5.4. Padding . . . . . . . . . . . . . . . . . . . . . . . . . 11 72 5.5. Decompression . . . . . . . . . . . . . . . . . . . . . . 11 73 5.6. Fragmentation . . . . . . . . . . . . . . . . . . . . . . 11 74 5.6.1. DTag . . . . . . . . . . . . . . . . . . . . . . . . 11 75 5.6.2. Uplink fragmentation: From device to SCHC gateway . . 12 76 5.6.3. Downlink fragmentation: From SCHC gateway to device . 15 77 5.7. SCHC Fragment Format . . . . . . . . . . . . . . . . . . 18 78 5.7.1. All-0 SCHC fragment . . . . . . . . . . . . . . . . . 18 79 5.7.2. All-1 SCHC fragment . . . . . . . . . . . . . . . . . 18 80 5.7.3. Delay after each message to respect local regulation 18 81 6. Security considerations . . . . . . . . . . . . . . . . . . . 18 82 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 19 83 Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 19 84 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 19 85 9.1. Normative References . . . . . . . . . . . . . . . . . . 20 86 9.2. Informative References . . . . . . . . . . . . . . . . . 21 87 Appendix A. Examples . . . . . . . . . . . . . . . . . . . . . . 21 88 A.1. Uplink - Compression example - No fragmentation . . . . . 21 89 A.2. Uplink - Compression and fragmentation example . . . . . 22 90 A.3. Downlink . . . . . . . . . . . . . . . . . . . . . . . . 24 91 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 25 93 1. Introduction 95 The Static Context Header Compression (SCHC) specification [RFC8724] 96 describes generic header compression and fragmentation techniques 97 that can be used on all LPWAN (Low Power Wide Area Networks) 98 technologies defined in [RFC8376]. Even though those technologies 99 share a great number of common features like star-oriented 100 topologies, network architecture, devices with mostly quite 101 predictable communications, etc; they do have some slight differences 102 in respect to payload sizes, reactiveness, etc. 104 SCHC provides a generic framework that enables those devices to 105 communicate with other Internet networks. However, for efficient 106 performance, some parameters and modes of operation need to be set 107 appropriately for each of the LPWAN technologies. 109 This document describes the efficient parameters and modes of 110 operation when SCHC is used over LoRaWAN networks. 112 2. Terminology 114 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 115 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 116 "OPTIONAL" in this document are to be interpreted as described in BCP 117 14 [RFC2119] [RFC8174] when, and only when, they appear in all 118 capitals, as shown here. 120 This section defines the terminology and acronyms used in this 121 document. For all other definitions, please look up the SCHC 122 specification [RFC8724]. 124 o DevEUI: an IEEE EUI-64 identifier used to identify the device 125 during the procedure while joining the network (Join Procedure) 127 o DevAddr: a 32-bit non-unique identifier assigned to a device 128 statically or dynamically after a Join Procedure (depending on the 129 activation mode) 131 o RCS: Reassembly Check Sequence. Used to verify the integrity of 132 the fragmentation-reassembly process 134 o OUI: Organisation Unique Identifier. IEEE assigned prefix for EUI 136 o SCHC gateway: It corresponds to the LoRaWAN Application Server. It 137 manages translation between IPv6 network and the Network Gateway 138 (LoRaWAN Network Server) 140 3. Static Context Header Compression Overview 142 This section contains a short overview of Static Context Header 143 Compression (SCHC). For a detailed description, refer to the full 144 specification [RFC8724]. 146 It defines: 148 1. Compression mechanisms to avoid transporting information known by 149 both sender and receiver over the air. Known information are 150 part of the "context" 152 2. Fragmentation mechanisms to allow SCHC Packet transportation on 153 small, and potentially variable, MTU 155 Context exchange or pre-provisioning is out of scope of this 156 document. 158 Device App 159 +----------------+ +----+ +----+ +----+ 160 | App1 App2 App3 | |App1| |App2| |App3| 161 | | | | | | | | 162 | UDP | |UDP | |UDP | |UDP | 163 | IPv6 | |IPv6| |IPv6| |IPv6| 164 | | | | | | | | 165 |SCHC C/D and F/R| | | | | | | 166 +--------+-------+ +----+ +----+ +----+ 167 | +---+ +----+ +----+ +----+ . . . 168 +~ |RGW| === |NGW | == |SCHC| == |SCHC|...... Internet .... 169 +---+ +----+ |F/R | |C/D | 170 +----+ +----+ 172 Figure 1: Architecture 174 Figure 1 represents the architecture for compression/decompression, 175 it is based on [RFC8376] terminology. The device is sending 176 applications flows using IPv6 or IPv6/UDP protocols. These flows 177 might be compressed by a Static Context Header Compression 178 Compressor/Decompressor (SCHC C/D) to reduce headers size and 179 fragmented (SCHC F/R). The resulting information is sent on a layer 180 two (L2) frame to an LPWAN Radio Gateway (RGW) that forwards the 181 frame to a Network Gateway (NGW). The NGW sends the data to a SCHC 182 F/R for reassembly, if required, then to SCHC C/D for decompression. 183 The C/D shares the same rules with the device. The SCHC F/R and C/D 184 can be located on the Network Gateway (NGW) or in another place as 185 long as a tunnel is established between the NGW and the SCHC F/R, 186 then SCHC F/R and SCHC C/D. The SCHC C/D in both sides MUST share 187 the same set of rules. After decompression, the packet can be sent 188 on the Internet to one or several LPWAN Application Servers (App). 190 The SCHC F/R and SCHC C/D process is bidirectional, so the same 191 principles can be applied in the other direction. 193 In a LoRaWAN network, the RG is called a Gateway, the NGW is Network 194 Server, and the SCHC C/D and SCHC F/R are an Application Server. It 195 can be provided by the Network Gateway or any third party software. 196 Figure 1 can be mapped in LoRaWAN terminology to: 198 End Device App 199 +--------------+ +----+ +----+ +----+ 200 |App1 App2 App3| |App1| |App2| |App3| 201 | | | | | | | | 202 | UDP | |UDP | |UDP | |UDP | 203 | IPv6 | |IPv6| |IPv6| |IPv6| 204 | | | | | | | | 205 |SCHC C/D & F/R| | | | | | | 206 +-------+------+ +----+ +----+ +----+ 207 | +-------+ +-------+ +-----------+ . . . 208 +~ |Gateway| === |Network| == |Application|..... Internet .... 209 +-------+ |server | |server | 210 +-------+ | F/R - C/D | 211 +-----------+ 213 Figure 2: SCHC Architecture mapped to LoRaWAN 215 4. LoRaWAN Architecture 217 An overview of LoRaWAN [lora-alliance-spec] protocol and architecture 218 is described in [RFC8376]. The mapping between the LPWAN 219 architecture entities as described in [RFC8724] and the ones in 220 [lora-alliance-spec] is as follows: 222 o Devices are LoRaWAN End Devices (e.g. sensors, actuators, etc.). 223 There can be a very high density of devices per radio gateway 224 (LoRaWAN gateway). This entity maps to the LoRaWAN end-device. 226 o The Radio Gateway (RGW), which is the endpoint of the constrained 227 link. This entity maps to the LoRaWAN Gateway. 229 o The Network Gateway (NGW) is the interconnection node between the 230 Radio Gateway and the Internet. This entity maps to the LoRaWAN 231 Network Server. 233 o SCHC F/R and SCHC C/D are LoRaWAN Application Server; ie the 234 LoRaWAN application server will do the C/D and F/R. 236 () () () | +------+ 237 () () () () / \ +---------+ | Join | 238 () () () () () / \======| ^ |===|Server| +-----------+ 239 () () () | | <--|--> | +------+ |Application| 240 () () () () / \==========| v |=============| Server | 241 () () () / \ +---------+ +-----------+ 242 End Devices Gateways Network Server 244 Figure 3: LPWAN Architecture 246 SCHC C/D (Compressor/Decompressor) and SCHC F/R (Fragmentation/ 247 Reassembly) are performed on the LoRaWAN end-device and the 248 Application Server (called SCHC gateway). While the point-to-point 249 link between the device and the Application Server constitutes single 250 IP hop, the ultimate end-point of the IP communication may be an 251 Internet node beyond the Application Server. In other words, the 252 LoRaWAN Application Server (SCHC gateway) acts as the first hop IP 253 router for the device. The Application Server and Network Server may 254 be co-located, which effectively turns the Network/Application Server 255 into the first hop IP router. 257 4.1. Device classes (A, B, C) and interactions 259 The LoRaWAN MAC layer supports 3 classes of devices named A, B and C. 260 All devices implement the Class A, some devices may implement Class B 261 or Class C. Class B and Class C are mutually exclusive. 263 o Class A: The Class A is the simplest class of devices. The device 264 is allowed to transmit at any time, randomly selecting a 265 communication channel. The Network Gateway may reply with a 266 downlink in one of the 2 receive windows immediately following the 267 uplinks. Therefore, the Network Gateway cannot initiate a 268 downlink, it has to wait for the next uplink from the device to 269 get a downlink opportunity. The Class A is the lowest power 270 device class. 272 o Class B: Class B devices implement all the functionalities of 273 Class A devices, but also schedule periodic listen windows. 274 Therefore, opposed to the Class A devices, Class B devices can 275 receive downlinks that are initiated by the Network Gateway and 276 not following an uplink. There is a trade-off between the 277 periodicity of those scheduled Class B listen windows and the 278 power consumption of the device. The lower the downlink latency, 279 the higher the power consumption. 281 o Class C: Class C devices implement all the functionalities of 282 Class A devices, but keep their receiver open whenever they are 283 not transmitting. Class C devices can receive downlinks at any 284 time at the expense of a higher power consumption. Battery- 285 powered devices can only operate in Class C for a limited amount 286 of time (for example for a firmware upgrade over-the-air). Most 287 of the Class C devices are grid powered (for example Smart Plugs). 289 4.2. Device addressing 291 LoRaWAN end-devices use a 32-bit network address (devAddr) to 292 communicate with the Network Gateway over-the-air, this address might 293 not be unique in a LoRaWAN network; devices using the same devAddr 294 are distinguished by the Network Gateway based on the cryptographic 295 signature appended to every LoRaWAN frame. 297 To communicate with the SCHC gateway the Network Gateway MUST 298 identify the devices by a unique 64-bit device identifier called the 299 DevEUI. 301 The DevEUI is assigned to the device during the manufacturing process 302 by the device's manufacturer. It is built like an Ethernet MAC 303 address by concatenating the manufacturer's IEEE OUI field with a 304 vendor unique number. e.g.: 24-bit OUI is concatenated with a 40-bit 305 serial number. The Network Gateway translates the devAddr into a 306 DevEUI in the uplink direction and reciprocally on the downlink 307 direction. 309 +--------+ +---------+ +---------+ +----------+ 310 | Device | <=====> | Network | <====> | SCHC | <========> | Internet | 311 | | devAddr | Gateway | DevEUI | Gateway | IPv6/UDP | | 312 +--------+ +---------+ +---------+ +----------+ 314 Figure 4: LoRaWAN addresses 316 4.3. General Frame Types 318 o LoRaWAN Confirmed message: The sender asks the receiver to 319 acknowledge the message. 321 o LoRaWAN Unconfirmed message: The sender does not ask the receiver 322 to acknowledge the message. 324 As SCHC defines its own acknowledgment mechanisms, SCHC does not 325 require to use LoRaWAN Confirmed messages. 327 4.4. LoRaWAN MAC Frames 329 o JoinRequest: This message is used by a device to join a network. 330 It contains the device's unique identifier DevEUI and a random 331 nonce that will be used for session key derivation. 333 o JoinAccept: To on-board a device, the Network Gateway responds to 334 the JoinRequest issued by a device with a JoinAccept message. 335 That message is encrypted with the device's AppKey and contains 336 (amongst other fields) the major network's settings and a random 337 nonce used to derive the session keys. 339 o Data: MAC and application data. Application data are protected 340 with AES-128 encryption, MAC related data are AES-128 encrypted 341 with another key. 343 4.5. LoRaWAN empty frame 345 A LoRaWAN empty frame is a LoRaWAN message without FPort and 346 FRMPayload. 348 4.6. Unicast and multicast technology 350 LoRaWAN technology supports unicast downlinks, but also multicast: a 351 packet send over LoRaWAN radio link can be received by several 352 devices. It is useful to address many devices with same content, 353 either a large binary file (firmware upgrade), or same command (e.g: 354 lighting control). As IPv6 is also a multicast technology this 355 feature can be used to address a group of devices. 357 _Note 1_: IPv6 multicast addresses must be defined as per [RFC4291]. 358 LoRaWAN multicast group definition in a Network Gateway and the 359 relation between those groups and IPv6 groupID are out of scope of 360 this document. 362 _Note 2_: LoRa Alliance defined [lora-alliance-remote-multicast-set] 363 as RECOMMENDED way to setup multicast groups on devices and create a 364 synchronized reception window. 366 5. SCHC-over-LoRaWAN 368 5.1. LoRaWAN FPort 370 The LoRaWAN MAC layer features a frame port field in all frames. 371 This field (FPort) is 8 bits long and the values from 1 to 223 can be 372 used. It allows LoRaWAN networks and applications to identify data. 374 The FPort field is part of the SCHC Message, as shown in Figure 5. 375 The SCHC C/D and the SCHC F/R SHALL concatenate the FPort field with 376 the LoRaWAN payload to retrieve their payload as it is used as a part 377 of the RuleID field. 379 | FPort | LoRaWAN payload | 380 + ------------------------ + 381 | SCHC packet | 383 Figure 5: SCHC Message in LoRaWAN 385 A fragmentation datagram with application payload transferred from 386 device to Network Gateway, is called uplink fragmentation datagram. 387 It uses an FPort for data uplink and its associated SCHC control 388 downlinks, named FPortUp in this document. The other way, a 389 fragmentation datagram with application payload transferred from 390 Network Gateway to device, is called downlink fragmentation datagram. 391 It uses another FPort for data downlink and its associated SCHC 392 control uplinks, named FPortDown in this document. 394 All RuleID can use arbitrary values inside the FPort range allowed by 395 LoRaWAN specification and MUST be shared by the device and SCHC 396 gateway prior to the communication with the selected rule. The 397 uplink and downlink fragmentation FPorts MUST be different. 399 5.2. Rule ID management 401 RuleID MUST be 8 bits, encoded in the LoRaWAN FPort as described in 402 Section 5.1. LoRaWAN supports up to 223 application FPorts in the 403 range [1;223] as defined in section 4.3.2 of [lora-alliance-spec], it 404 implies that RuleID MSB SHOULD be inside this range. An application 405 can send non SCHC traffic by using FPort values different from the 406 ones used for SCHC. 408 In order to improve interoperability RECOMMENDED fragmentation RuleID 409 values are: 411 o RuleID = 20 (8-bit) for uplink fragmentation, named FPortUp 413 o RuleID = 21 (8-bit) for downlink fragmentation, named FPortDown 415 o RuleID = 22 (8-bit) for which SCHC compression was not possible 416 (no matching rule was found) 418 The remaining RuleIDs are available for compression. RuleIDs are 419 shared between uplink and downlink sessions. A RuleID not in the 420 set(s) of FPortUp or FPortDown means that the fragmentation is not 421 used, thus, on reception, the SCHC Message MUST be sent to the C/D 422 layer. 424 The only uplink messages using the FPortDown port are the 425 fragmentation SCHC control messages of a downlink fragmentation 426 datagram (for example, SCHC ACKs). Similarly, the only downlink 427 messages using the FPortUp port are the fragmentation SCHC control 428 messages of an uplink fragmentation datagram. 430 An application can have multiple fragmentation datagrams between a 431 device and one or several SCHC gateways. A set of FPort values is 432 REQUIRED for each SCHC gateway instance the device is required to 433 communicate with. The application can use additional uplinks or 434 downlink fragmentation parameters but SHALL implement at least the 435 parameters defined in this document. 437 The mechanism for sharing those RuleID values is outside the scope of 438 this document. 440 5.3. IID computation 442 In order to mitigate risks described in [RFC8064] and [RFC8065] IID 443 MUST be created regarding the following algorithm: 445 1. key = LoRaWAN AppSKey 447 2. cmac = aes128_cmac(key, DevEUI) 449 3. IID = cmac[0..7] 451 aes128_cmac algorithm is described in [RFC4493]. It has been chosen 452 as it is already used by devices for LoRaWAN protocol. 454 As AppSKey is renewed each time a device joins or rejoins a LoRaWAN 455 network, the IID will change over time; this mitigates privacy, 456 location tracking and correlation over time risks. Join periodicity 457 is defined at the application level. 459 Address scan risk is mitigated thanks to AES-128, which provides 460 enough entropy bits of the IID. 462 Using this algorithm will also ensure that there is no correlation 463 between the hardware identifier (IEEE-64 DevEUI) and the IID, so an 464 attacker cannot use manufacturer OUI to target devices. 466 Example with: 468 o DevEUI: 0x1122334455667788 469 o appSKey: 0x00AABBCCDDEEFF00AABBCCDDEEFFAABB 471 1. key: 0x00AABBCCDDEEFF00AABBCCDDEEFFAABB 472 2. cmac: 0xBA59F4B196C6C3432D9383C145AD412A 473 3. IID: 0xBA59F4B196C6C343 475 Figure 6: Example of IID computation. 477 There is a small probability of IID collision in a LoRaWAN network, 478 if such event occurs the IID can be changed by rekeying the device on 479 L2 level (ie: trigger a LoRaWAN join). The way the device is rekeyed 480 is out of scope of this document and left to the implementation. 482 5.4. Padding 484 All padding bits MUST be 0. 486 5.5. Decompression 488 SCHC C/D MUST concatenate FPort and LoRaWAN payload to retrieve the 489 SCHC Packet as per Section 5.1. 491 RuleIDs matching FPortUp and FPortDown are reserved for SCHC 492 Fragmentation. 494 5.6. Fragmentation 496 The L2 Word Size used by LoRaWAN is 1 byte (8 bits). The SCHC 497 fragmentation over LoRaWAN uses the ACK-on-Error mode for uplink 498 fragmentation and Ack-Always mode for downlink fragmentation. A 499 LoRaWAN device cannot support simultaneous interleaved fragmentation 500 datagrams in the same direction (uplink or downlink). 502 The fragmentation parameters are different for uplink and downlink 503 fragmentation datagrams and are successively described in the next 504 sections. 506 5.6.1. DTag 508 A Device cannot interleave several fragmented SCHC datagrams on the 509 same FPort. This field is not used and its size is 0. 511 Note: The device can still have several parallel fragmentation 512 datagrams with one or more SCHC gateway(s) thanks to distinct sets of 513 FPorts, cf Section 5.2 515 5.6.2. Uplink fragmentation: From device to SCHC gateway 517 In that case the device is the fragmentation transmitter, and the 518 SCHC gateway the fragmentation receiver. A single fragmentation rule 519 is defined. SCHC F/R MUST concatenate FPort and LoRaWAN payload to 520 retrieve the SCHC Packet, as per Section 5.1. 522 o SCHC header size is two bytes (the FPort byte + 1 additional 523 byte). 525 o RuleID: 8 bits stored in LoRaWAN FPort. 527 o SCHC fragmentation reliability mode: "ACK-on-Error" 529 o DTag: Size is 0 bit, not used 531 o FCN: The FCN field is encoded on N = 6 bits, so WINDOW_SIZE = 63 532 tiles are allowed in a window 534 o Window index: encoded on W = 2 bits. So 4 windows are available. 536 o RCS: Use recommended calculation algorithm in [RFC8724]. 538 o MAX_ACK_REQUESTS: 8 540 o Tile: size is 10 bytes 542 o Retransmission timer: Set by the implementation depending on the 543 application requirements. 545 o Inactivity timer: The SCHC gateway implements an "inactivity 546 timer". The default RECOMMENDED duration of this timer is 12 547 hours; this value is mainly driven by application requirements and 548 MAY be changed by the application. 550 o Penultimate tile MUST be equal to the regular size. 552 o Last tile: it can be carried in a Regular SCHC Fragment, alone in 553 an All-1 SCHC Fragment or with any of these two methods. 554 Implementation must ensure that: 556 * The sender MUST ascertain that the receiver will not receive 557 the last tile through both a Regular SCHC Fragment and an All-1 558 SCHC Fragment. 560 * If last tile is in All-1 message: current L2 MTU MUST be big 561 enough to fit the All-1 and the last tile. 563 With this set of parameters, the SCHC fragment header is 16 bits, 564 including FPort; payload overhead will be 8 bits as FPort is already 565 a part of LoRaWAN payload. MTU is: _4 windows * 63 tiles * 10 bytes 566 per tile = 2520 bytes_ 568 For battery powered devices, it is RECOMMENDED to use the ACK 569 mechanism at the end of each window instead of waiting until the end 570 of all windows: 572 o SCHC receiver SHOULD send a SCHC ACK after every window even if 573 there is no missing tile. 575 o SCHC sender SHOULD wait for the SCHC ACK from the SCHC receiver 576 before sending tiles from the next window. If the SCHC ACK is not 577 received, it SHOULD send an SCHC ACK REQ up to MAX_ACK_REQUESTS, 578 time as described previously. 580 For non-battery powered devices, SCHC receiver MAY also choose to 581 send a SCHC ACK only at the end of all windows. It will reduce 582 downlink load on the LoRaWAN network, by reducing the number of 583 downlinks. 585 SCHC implementations MUST be compatible with both behavior, and 586 selection is a part of the rule context. 588 5.6.2.1. Regular fragments 590 | FPort | LoRaWAN payload | 591 + ------ + ------------------------- + 592 | RuleID | W | FCN | Payload | 593 + ------ + ------ + ------ + ------- + 594 | 8 bits | 2 bits | 6 bits | | 596 Figure 7: All fragments except the last one. SCHC header size is 16 597 bits, including LoRaWAN FPort. 599 5.6.2.2. Last fragment (All-1) 601 | FPort | LoRaWAN payload | 602 + ------ + ---------------------------- + 603 | RuleID | W | FCN=All-1 | RCS | 604 + ------ + ------ + --------- + ------- + 605 | 8 bits | 2 bits | 6 bits | 32 bits | 607 Figure 8: All-1 SCHC Message: the last fragment without last tile. 609 | FPort | LoRaWAN payload | 610 + ------ + ------------------------------------------- + 611 | RuleID | W | FCN=All-1 | RCS | Last tile | 612 + ------ + ------ + --------- + ------- + ------------ + 613 | 8 bits | 2 bits | 6 bits | 32 bits | 1 to 80 bits | 615 Figure 9: All-1 SCHC Message: the last fragment with last tile. 617 5.6.2.3. SCHC ACK 619 | FPort | LoRaWAN payload | 620 + ------ + -------------------------------------------------------------------- + 621 | RuleID | W | C | Compressed bitmap(C = 0) | Optional padding(b'0...0) | 622 + ------ + ----- + ----- + ------------------------ + ------------------------- + 623 | 8 bits | 2 bit | 1 bit | 5 to 63 bits | 0, 6 or 7 bits | 625 Figure 10: SCHC ACK format, failed RCS check. 627 Note: Because of the bitmap compression mechanism and L2 byte 628 alignment only few discrete values are possible: 5, 13, 21, 29, 37, 629 45, 53, 61, 62, 63. Bitmaps of 63 bits will require 6 bits of 630 padding. 632 5.6.2.4. Receiver-Abort 634 | FPort | LoRaWAN payload | 635 + ------ + -------------------------------------------- + 636 | RuleID | W = b'11 | C = 1 | b'11111 | 0xFF (all 1's) | 637 + ------ + -------- + ------+-------- + ----------------+ 638 | 8 bits | 2 bits | 1 bit | 5 bits | 8 bits | 639 next L2 Word boundary ->| <-- L2 Word --> | 641 Figure 11: Receiver-Abort format. 643 5.6.2.5. SCHC acknowledge request 645 | FPort | LoRaWAN payload | 646 +------- +------------------------- + 647 | RuleID | W | FCN = b'000000 | 648 + ------ + ------ + --------------- + 649 | 8 bits | 2 bits | 6 bits | 651 Figure 12: SCHC ACK REQ format. 653 5.6.3. Downlink fragmentation: From SCHC gateway to device 655 In that case the device is the fragmentation receiver, and the SCHC 656 gateway the fragmentation transmitter. The following fields are 657 common to all devices. SCHC F/R MUST concatenate FPort and LoRaWAN 658 payload to retrieve the SCHC Packet as described in Section 5.1. 660 o SCHC fragmentation reliability mode: 662 * Unicast downlinks: ACK-Always. 664 * Multicast downlinks: No-ACK, reliability has to be ensured by 665 the upper layer. This feature is OPTIONAL and may not be 666 implemented by SCHC gateway. 668 o RuleID: 8 bits stored in LoRaWAN FPort. 670 o Window index (unicast only): encoded on W=1 bit, as per [RFC8724]. 672 o DTag: Size is 0 bit, not used 674 o FCN: The FCN field is encoded on N=1 bit, so WINDOW_SIZE = 1 tile 676 o RCS: Use recommended calculation algorithm in [RFC8724]. 678 o MAX_ACK_REQUESTS: 8 680 o Retransmission timer: See Section 5.6.3.5 682 o Inactivity timer: The default RECOMMENDED duration of this timer 683 is 12 hours; this value is mainly driven by application 684 requirements and MAY be changed by the application. 686 As only 1 tile is used, its size can change for each downlink, and 687 will be maximum available MTU. 689 Class A devices can only receive during an RX slot, following the 690 transmission of an uplink. Therefore the SCHC gateway cannot 691 initiate communication (ex: new SCHC session); in order to create a 692 downlink opportunity it is RECOMMENDED for Class A devices to send an 693 uplink every 24 hours when no SCHC session is started, this is 694 application specific and can be disabled. RECOMMENDED uplink is a 695 LoRaWAN empty frame as defined Section 4.5. As this uplink is to 696 open an RX window any applicative uplink MAY reset this counter. 698 _Note_: The Fpending bit included in LoRaWAN protocol SHOULD NOT be 699 used for SCHC-over-LoRaWAN protocol. It might be set by the Network 700 Gateway for other purposes but not SCHC needs. 702 5.6.3.1. Regular fragments 704 | FPort | LoRaWAN payload | 705 + ------ + ------------------------------------ + 706 | RuleID | W | FCN = b'0 | Payload | 707 + ------ + ----- + --------- + ---------------- + 708 | 8 bits | 1 bit | 1 bit | X bytes + 6 bits | 710 Figure 13: All fragments but the last one. Header size 10 bits, 711 including LoraWAN FPort. 713 5.6.3.2. Last fragment (All-1) 715 | FPort | LoRaWAN payload | 716 + ------ + --------------------------- + ----------------- + 717 | RuleID | W | FCN = b'1 | RCS | Payload | 718 + ------ + ----- + --------- + ------- + ----------------- + 719 | 8 bits | 1 bit | 1 bit | 32 bits | 6 bits to X bytes | 721 Figure 14: All-1 SCHC Message: the last fragment. 723 5.6.3.3. SCHC ACK 725 | FPort | LoRaWAN payload | 726 + ------ + ---------------------------------- + 727 | RuleID | W | C = b'1 | Padding b'000000 | 728 + ------ + ----- + ------- + ---------------- + 729 | 8 bits | 1 bit | 1 bit | 6 bits | 731 Figure 15: SCHC ACK format, RCS is correct. 733 5.6.3.4. Receiver-Abort 735 | FPort | LoRaWAN payload | 736 + ------ + ---------------------------------------------- + 737 | RuleID | W = b'1 | C = b'1 | b'111111 | 0xFF (all 1's) | 738 + ------ + ------- + ------- + -------- + --------------- + 739 | 8 bits | 1 bit | 1 bits | 6 bits | 8 bits | 740 next L2 Word boundary ->| <-- L2 Word --> | 742 Figure 16: Receiver-Abort packet (following an All-1 SCHC Fragment 743 with incorrect RCS). 745 5.6.3.5. Downlink retransmission timer 747 Class A and Class B or Class C devices do not manage retransmissions 748 and timers in the same way. 750 5.6.3.5.1. Class A devices 752 Class A devices can only receive in an RX slot following the 753 transmission of an uplink. 755 The SCHC gateway implements an inactivity timer with a RECOMMENDED 756 duration of 36 hours. For devices with very low transmission rates 757 (example 1 packet a day in normal operation), that duration may be 758 extended: it is application specific. 760 RETRANSMISSION_TIMER is application specific and its RECOMMENDED 761 value is INACTIVITY_TIMER/(MAX_ACK_REQUESTS + 1). 763 *SCHC All-0 (FCN=0)* All fragment but the last have an FCN=0 (because 764 window size is 1). Following it the device MUST transmit the SCHC 765 ACK message. It MUST transmit up to MAX_ACK_REQUESTS SCHC ACK 766 messages before aborting. In order to progress the fragmentation 767 datagram, the SCHC layer should immediately queue for transmission 768 those SCHC ACK if no SCHC downlink have been received during RX1 and 769 RX2 window. LoRaWAN layer will respect the regulation if required. 771 _Note_: The ACK bitmap is 1 bit long and is always 1. 773 *SCHC All-1 (FCN=1)* SCHC All-1 is the last fragment of a datagram, 774 the corresponding SCHC ACK message might be lost; therefore the SCHC 775 gateway MUST request a retransmission of this ACK when the 776 retransmission timer expires. To open a downlink opportunity the 777 device MUST transmit an uplink every 778 RETRANSMISSION_TIMER/(MAX_ACK_REQUESTS * 779 SCHC_ACK_REQ_DN_OPPORTUNITY). The format of this uplink is 780 application specific. It is RECOMMENDED for a device to send an 781 empty frame (see Section 4.5) but it is application specific and will 782 be used by the NGW to transmit a potential SCHC ACK REQ. 783 SCHC_ACK_REQ_DN_OPPORTUNITY is application specific and its 784 recommended value is 2, it MUST be greater than 1. This allows to 785 open downlink opportunity to other eventual downlink with higher 786 priority than SCHC ACK REQ message. 788 _Note_: The device MUST keep this SCHC ACK message in memory until it 789 receives a downlink, on SCHC FPortDown different from an SCHC ACK 790 REQ: it indicates that the SCHC gateway has received the ACK message. 792 5.6.3.6. Class B or Class C devices 794 Class B devices can receive in scheduled RX slots or in RX slots 795 following the transmission of an uplink. Class C devices are almost 796 in constant reception. 798 RECOMMENDED retransmission timer value: 800 o Class B: 3 times the ping slot periodicity. 802 o Class C: 30 seconds 804 The RECOMMENDED inactivity timer value is 12 hours for both Class B 805 and Class C devices. 807 5.7. SCHC Fragment Format 809 5.7.1. All-0 SCHC fragment 811 *Uplink fragmentation (Ack-On-Error)*: 813 All-0 is distinguishable from a SCHC ACK REQ as [RFC8724] states 814 _This condition is also met if the SCHC Fragment Header is a multiple 815 of L2 Words_; this condition met: SCHC header is 2 bytes. 817 *Downlink fragmentation (Ack-always)*: 819 As per [RFC8724] the SCHC All-1 MUST contain the last tile, 820 implementation must ensure that All-0 message Payload will be at 821 least the size of an L2 Word. 823 5.7.2. All-1 SCHC fragment 825 All-1 is distinguishable from a SCHC Sender-Abort as [RFC8724] states 826 _This condition is met if the RCS is present and is at least the size 827 of an L2 Word_; this condition met: RCS is 4 bytes. 829 5.7.3. Delay after each message to respect local regulation 831 This profile does not define a delay to be added after each SCHC 832 message, local regulation compliance is expected to be enforced by 833 LoRaWAN stack. 835 6. Security considerations 837 This document is only providing parameters that are expected to be 838 best suited for LoRaWAN networks for [RFC8724]. IID security is 839 discussed in Section 5.3. As such, this document does not contribute 840 to any new security issues in addition to those identified in 841 [RFC8724]. Moreover, SCHC data (LoRaWAN payload) are protected on 842 LoRaWAN level by an AES-128 encryption with key shared by device and 843 SCHC gateway. Those keys are renewed at each LoRaWAN session (ie: 844 each join or rejoin to the LoRaWAN network) 846 Acknowledgements 848 Thanks to all those listed in the Contributors section for the 849 excellent text, insightful discussions, reviews and suggestions, and 850 also to (in alphabetical order) Dominique Barthel, Arunprabhu 851 Kandasamy, Rodrigo Munoz, Alexander Pelov, Pascal Thubert, Laurent 852 Toutain for useful design considerations, reviews and comments. 854 Contributors 856 Contributors ordered by family name. 858 Vincent Audebert 859 EDF R&D 860 Email: vincent.audebert@edf.fr 862 Julien Catalano 863 Kerlink 864 Email: j.catalano@kerlink.fr 866 Michael Coracin 867 Semtech 868 Email: mcoracin@semtech.com 870 Marc Le Gourrierec 871 Sagemcom 872 Email: marc.legourrierec@sagemcom.com 874 Nicolas Sornin 875 Semtech 876 Email: nsornin@semtech.com 878 Alper Yegin 879 Actility 880 Email: alper.yegin@actility.com 882 9. References 883 9.1. Normative References 885 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 886 Requirement Levels", BCP 14, RFC 2119, 887 DOI 10.17487/RFC2119, March 1997, 888 . 890 [RFC3385] Sheinwald, D., Satran, J., Thaler, P., and V. Cavanna, 891 "Internet Protocol Small Computer System Interface (iSCSI) 892 Cyclic Redundancy Check (CRC)/Checksum Considerations", 893 RFC 3385, DOI 10.17487/RFC3385, September 2002, 894 . 896 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 897 Architecture", RFC 4291, DOI 10.17487/RFC4291, February 898 2006, . 900 [RFC4493] Song, JH., Poovendran, R., Lee, J., and T. Iwata, "The 901 AES-CMAC Algorithm", RFC 4493, DOI 10.17487/RFC4493, June 902 2006, . 904 [RFC4944] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler, 905 "Transmission of IPv6 Packets over IEEE 802.15.4 906 Networks", RFC 4944, DOI 10.17487/RFC4944, September 2007, 907 . 909 [RFC5795] Sandlund, K., Pelletier, G., and L-E. Jonsson, "The RObust 910 Header Compression (ROHC) Framework", RFC 5795, 911 DOI 10.17487/RFC5795, March 2010, 912 . 914 [RFC7136] Carpenter, B. and S. Jiang, "Significance of IPv6 915 Interface Identifiers", RFC 7136, DOI 10.17487/RFC7136, 916 February 2014, . 918 [RFC8064] Gont, F., Cooper, A., Thaler, D., and W. Liu, 919 "Recommendation on Stable IPv6 Interface Identifiers", 920 RFC 8064, DOI 10.17487/RFC8064, February 2017, 921 . 923 [RFC8065] Thaler, D., "Privacy Considerations for IPv6 Adaptation- 924 Layer Mechanisms", RFC 8065, DOI 10.17487/RFC8065, 925 February 2017, . 927 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 928 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 929 May 2017, . 931 [RFC8376] Farrell, S., Ed., "Low-Power Wide Area Network (LPWAN) 932 Overview", RFC 8376, DOI 10.17487/RFC8376, May 2018, 933 . 935 [RFC8724] Minaburo, A., Toutain, L., Gomez, C., Barthel, D., and JC. 936 Zuniga, "SCHC: Generic Framework for Static Context Header 937 Compression and Fragmentation", RFC 8724, 938 DOI 10.17487/RFC8724, April 2020, 939 . 941 9.2. Informative References 943 [lora-alliance-remote-multicast-set] 944 Alliance, L., "LoRaWAN Remote Multicast Setup 945 Specification Version 1.0.0", . 949 [lora-alliance-spec] 950 Alliance, L., "LoRaWAN Specification Version V1.0.3", 951 . 954 Appendix A. Examples 956 A.1. Uplink - Compression example - No fragmentation 958 This example represents an applicative payload going through SCHC 959 over LoRaWAN, no fragmentation required 961 An applicative payload of 78 bytes is passed to SCHC compression 962 layer. Rule 1 is used by C/D layer, allowing to compress it to 40 963 bytes and 5 bits: 1 byte RuleID, 21 bits residue + 37 bytes payload. 965 | RuleID | Compression residue | Payload | Padding=b'000 | 966 + ------ + ------------------- + --------- + ------------- + 967 | 1 | 21 bits | 37 bytes | 3 bits | 969 Figure 17: Uplink example: SCHC Message 971 The current LoRaWAN MTU is 51 bytes, although 2 bytes FOpts are used 972 by LoRaWAN protocol: 49 bytes are available for SCHC payload; no need 973 for fragmentation. The payload will be transmitted through FPort = 974 1. 976 | LoRaWAN Header | LoRaWAN payload (40 bytes) | 977 + ------------------------- + --------------------------------------- + 978 | | FOpts | RuleID=1 | Compression | Payload | Padding=b'000 | 979 | | | | residue | | | 980 + ---- + ------- + -------- + ----------- + --------- + ------------- + 981 | XXXX | 2 bytes | 1 byte | 21 bits | 37 bytes | 3 bits | 983 Figure 18: Uplink example: LoRaWAN packet 985 A.2. Uplink - Compression and fragmentation example 987 This example represents an applicative payload going through SCHC, 988 with fragmentation. 990 An applicative payload of 478 bytes is passed to SCHC compression 991 layer. Rule 1 is used by C/D layer, allowing to compress it to 282 992 bytes and 5 bits: 1 byte RuleID, 21 bits residue + 279 bytes payload. 994 | RuleID | Compression residue | Payload | 995 + ------ + ------------------- + --------- + 996 | 1 | 21 bits | 279 bytes | 998 Figure 19: Uplink example: SCHC Message 1000 The current LoRaWAN MTU is 11 bytes, 0 bytes FOpts are used by 1001 LoRaWAN protocol: 11 bytes are available for SCHC payload + 1 byte 1002 FPort field. SCHC header is 2 bytes (including FPort) so 1 tile is 1003 sent in first fragment. 1005 | LoRaWAN Header | LoRaWAN payload (11 bytes) | 1006 + -------------------------- + -------------------------- + 1007 | | RuleID=20 | W | FCN | 1 tile | 1008 + -------------- + --------- + ----- + ------ + --------- + 1009 | XXXX | 1 byte | 0 0 | 62 | 10 bytes | 1011 Figure 20: Uplink example: LoRaWAN packet 1 1013 Content of the tile is: 1014 | RuleID | Compression residue | Payload | 1015 + ------ + ------------------- + ----------------- + 1016 | 1 | 21 bits | 6 byte + 3 bits | 1018 Figure 21: Uplink example: LoRaWAN packet 1 - Tile content 1020 Next transmission MTU is 11 bytes, although 2 bytes FOpts are used by 1021 LoRaWAN protocol: 9 bytes are available for SCHC payload + 1 byte 1022 FPort field, a tile does not fit inside so LoRaWAN stack will send 1023 only FOpts. 1025 Next transmission MTU is 242 bytes, 4 bytes FOpts. 23 tiles are 1026 transmitted: 1028 | LoRaWAN Header | LoRaWAN payload (231 bytes) | 1029 + --------------------------------------+ --------------------------- + 1030 | | FOpts | RuleID=20 | W | FCN | 23 tiles | 1031 + -------------- + ------- + ---------- + ----- + ----- + ----------- + 1032 | XXXX | 4 bytes | 1 byte | 0 0 | 61 | 230 bytes | 1034 Figure 22: Uplink example: LoRaWAN packet 2 1036 Next transmission MTU is 242 bytes, no FOpts. All 5 remaining tiles 1037 are transmitted, the last tile is only 2 bytes + 5 bits. Padding is 1038 added for the remaining 3 bits. 1040 | LoRaWAN Header | LoRaWAN payload (44 bytes) | 1041 + ---- + -----------+ ------------------------------------------------- + 1042 | | RuleID=20 | W | FCN | 5 tiles | Padding=b'000 | 1043 + ---- + ---------- + ----- + ----- + ----------------- + ------------- + 1044 | XXXX | 1 byte | 0 0 | 38 | 42 bytes + 5 bits | 3 bits | 1046 Figure 23: Uplink example: LoRaWAN packet 3 1048 Then All-1 message can be transmitted: 1050 | LoRaWAN Header | LoRaWAN payload (44 bytes) | 1051 + ---- + -----------+ -------------------------- + 1052 | | RuleID=20 | W | FCN | RCS | 1053 + ---- + ---------- + ----- + ----- + ---------- + 1054 | XXXX | 1 byte | 0 0 | 63 | 4 bytes | 1056 Figure 24: Uplink example: LoRaWAN packet 4 - All-1 message 1058 All packets have been received by the SCHC gateway, computed RCS is 1059 correct so the following ACK is sent to the device by the SCHC 1060 receiver: 1062 | LoRaWAN Header | LoRaWAN payload | 1063 + -------------- + --------- + ------------------- + 1064 | | RuleID=20 | W | C | Padding | 1065 + -------------- + --------- + ----- + - + ------- + 1066 | XXXX | 1 byte | 0 0 | 1 | 5 bits | 1068 Figure 25: Uplink example: LoRaWAN packet 5 - SCHC ACK 1070 A.3. Downlink 1072 An applicative payload of 443 bytes is passed to SCHC compression 1073 layer. Rule 1 is used by C/D layer, allowing to compress it to 130 1074 bytes and 5 bits: 1 byte RuleID, 21 bits residue + 127 bytes payload. 1076 | RuleID | Compression residue | Payload | 1077 + ------ + ------------------- + --------- + 1078 | 1 | 21 bits | 127 bytes | 1080 Figure 26: Downlink example: SCHC Message 1082 The current LoRaWAN MTU is 51 bytes, no FOpts are used by LoRaWAN 1083 protocol: 51 bytes are available for SCHC payload + FPort field => it 1084 has to be fragmented. 1086 | LoRaWAN Header | LoRaWAN payload (51 bytes) | 1087 + ---- + ---------- + -------------------------------------- + 1088 | | RuleID=21 | W = 0 | FCN = 0 | 1 tile | 1089 + ---- + ---------- + ------ + ------- + ------------------- + 1090 | XXXX | 1 byte | 1 bit | 1 bit | 50 bytes and 6 bits | 1092 Figure 27: Downlink example: LoRaWAN packet 1 - SCHC Fragment 1 1094 Content of the tile is: 1096 | RuleID | Compression residue | Payload | 1097 + ------ + ------------------- + ------------------ + 1098 | 1 | 21 bits | 48 bytes and 1 bit | 1100 Figure 28: Downlink example: LoRaWAN packet 1: Tile content 1102 The receiver answers with a SCHC ACK: 1104 | LoRaWAN Header | LoRaWAN payload | 1105 + ---- + --------- + -------------------------------- + 1106 | | RuleID=21 | W = 0 | C = 1 | Padding=b'000000 | 1107 + ---- + --------- + ----- + ----- + ---------------- + 1108 | XXXX | 1 byte | 1 bit | 1 bit | 6 bits | 1110 Figure 29: Downlink example: LoRaWAN packet 2 - SCHC ACK 1112 The second downlink is sent, two FOpts: 1114 | LoRaWAN Header | LoRaWAN payload (49 bytes) | 1115 + --------------------------- + ------------------------------------- + 1116 | | FOpts | RuleID=21 | W = 1 | FCN = 0 | 1 tile | 1117 + ---- + ------- + ---------- + ----- + ------- + ------------------- + 1118 | XXXX | 2 bytes | 1 byte | 1 bit | 1 bit | 48 bytes and 6 bits | 1120 Figure 30: Downlink example: LoRaWAN packet 3 - SCHC Fragment 2 1122 The receiver answers with an SCHC ACK: 1124 | LoRaWAN Header | LoRaWAN payload | 1125 + ---- + --------- + -------------------------------- + 1126 | | RuleID=21 | W = 1 | C = 1 | Padding=b'000000 | 1127 + ---- + --------- + ----- + ----- + ---------------- + 1128 | XXXX | 1 byte | 1 bit | 1 bit | 6 bits | 1130 Figure 31: Downlink example: LoRaWAN packet 4 - SCHC ACK 1132 The last downlink is sent, no FOpts: 1134 | LoRaWAN Header | LoRaWAN payload (37 bytes) | 1135 + ---- + --------- + ----------------------------------------------------------------- + 1136 | | RuleID=21 | W = 0 | FCN = 1 | RCS | 1 tile | Padding=b'00000 | 1137 + ---- + --------- + ------- + ------- + ------- + ----------------- + --------------- + 1138 | XXXX | 1 byte | 1 bit | 1 bit | 4 bytes | 31 bytes + 1 bits | 5 bits | 1140 Figure 32: Downlink example: LoRaWAN packet 5 - All-1 message 1142 The receiver answers to the sender with an SCHC ACK: 1144 | LoRaWAN Header | LoRaWAN payload | 1145 + ---- + --------- + -------------------------------- + 1146 | | RuleID=21 | W = 0 | C = 1 | Padding=b'000000 | 1147 + ---- + --------- + ----- + ----- + ---------------- + 1148 | XXXX | 1 byte | 1 bit | 1 bit | 6 bits | 1150 Figure 33: Downlink example: LoRaWAN packet 6 - SCHC ACK 1152 Authors' Addresses 1154 Olivier Gimenez (editor) 1155 Semtech 1156 14 Chemin des Clos 1157 Meylan 1158 France 1160 Email: ogimenez@semtech.com 1161 Ivaylo Petrov (editor) 1162 Acklio 1163 1137A Avenue des Champs Blancs 1164 35510 Cesson-Sevigne Cedex 1165 France 1167 Email: ivaylo@ackl.io