idnits 2.17.00 (12 Aug 2021) /tmp/idnits25005/draft-ietf-lpwan-schc-over-lorawan-07.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** There are 14 instances of too long lines in the document, the longest one being 16 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (April 17, 2020) is 764 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC3385' is defined on line 849, but no explicit reference was found in the text == Unused Reference: 'RFC4944' is defined on line 863, but no explicit reference was found in the text == Unused Reference: 'RFC5795' is defined on line 868, but no explicit reference was found in the text == Unused Reference: 'RFC7136' is defined on line 873, but no explicit reference was found in the text Summary: 2 errors (**), 0 flaws (~~), 5 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 lpwan Working Group O. Gimenez, Ed. 3 Internet-Draft Semtech 4 Intended status: Informational I. Petrov, Ed. 5 Expires: October 19, 2020 Acklio 6 April 17, 2020 8 Static Context Header Compression (SCHC) over LoRaWAN 9 draft-ietf-lpwan-schc-over-lorawan-07 11 Abstract 13 The Static Context Header Compression (SCHC) specification describes 14 generic header compression and fragmentation techniques for LPWAN 15 (Low Power Wide Area Networks) technologies. SCHC is a generic 16 mechanism designed for great flexibility so that it can be adapted 17 for any of the LPWAN technologies. 19 This document provides the adaptation of SCHC for use in LoRaWAN 20 networks, and provides elements such as efficient parameterization 21 and modes of operation. This is called a profile. 23 Status of This Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at https://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on October 19, 2020. 40 Copyright Notice 42 Copyright (c) 2020 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (https://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the Simplified BSD License. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 58 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 59 3. Static Context Header Compression Overview . . . . . . . . . 3 60 4. LoRaWAN Architecture . . . . . . . . . . . . . . . . . . . . 5 61 4.1. End-Device classes (A, B, C) and interactions . . . . . . 6 62 4.2. End-Device addressing . . . . . . . . . . . . . . . . . . 7 63 4.3. General Message Types . . . . . . . . . . . . . . . . . . 7 64 4.4. LoRaWAN MAC Frames . . . . . . . . . . . . . . . . . . . 8 65 4.5. Unicast and multicast technology . . . . . . . . . . . . 8 66 5. SCHC-over-LoRaWAN . . . . . . . . . . . . . . . . . . . . . . 8 67 5.1. LoRaWAN FPort . . . . . . . . . . . . . . . . . . . . . . 8 68 5.2. Rule ID management . . . . . . . . . . . . . . . . . . . 9 69 5.3. IID computation . . . . . . . . . . . . . . . . . . . . . 10 70 5.4. Padding . . . . . . . . . . . . . . . . . . . . . . . . . 11 71 5.5. Decompression . . . . . . . . . . . . . . . . . . . . . . 11 72 5.6. Fragmentation . . . . . . . . . . . . . . . . . . . . . . 11 73 5.6.1. DTag . . . . . . . . . . . . . . . . . . . . . . . . 11 74 5.6.2. Uplink fragmentation: From device to SCHC gateway . . 12 75 5.6.3. Downlink fragmentation: From SCHC gateway to a device 15 76 6. Security considerations . . . . . . . . . . . . . . . . . . . 18 77 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 18 78 Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 18 79 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 19 80 9.1. Normative References . . . . . . . . . . . . . . . . . . 19 81 9.2. Informative References . . . . . . . . . . . . . . . . . 20 82 Appendix A. Examples . . . . . . . . . . . . . . . . . . . . . . 21 83 A.1. Uplink - Compression example - No fragmentation . . . . . 21 84 A.2. Uplink - Compression and fragmentation example . . . . . 21 85 A.3. Downlink . . . . . . . . . . . . . . . . . . . . . . . . 23 86 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 25 88 1. Introduction 90 The Static Context Header Compression (SCHC) specification [RFC8724] 91 describes generic header compression and fragmentation techniques 92 that can be used on all LPWAN (Low Power Wide Area Networks) 93 technologies defined in [RFC8376]. Even though those technologies 94 share a great number of common features like star-oriented 95 topologies, network architecture, devices with mostly quite 96 predictable communications, etc; they do have some slight differences 97 in respect of payload sizes, reactiveness, etc. 99 SCHC gives a generic framework that enables those devices to 100 communicate with other Internet networks. However, for efficient 101 performance, some parameters and modes of operation need to be set 102 appropriately for each of the LPWAN technologies. 104 This document describes the efficient parameters and modes of 105 operation when SCHC is used over LoRaWAN networks. 107 2. Terminology 109 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 110 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 111 "OPTIONAL" in this document are to be interpreted as described in BCP 112 14 [RFC2119] [RFC8174] when, and only when, they appear in all 113 capitals, as shown here. 115 This section defines the terminology and acronyms used in this 116 document. For all other definitions, please look up the SCHC 117 specification [RFC8724]. 119 o DevEUI: an IEEE EUI-64 identifier used to identify the end-device 120 during the procedure while joining the network (Join Procedure) 122 o DevAddr: a 32-bit non-unique identifier assigned to an end-device 123 statically or dynamically after a Join Procedure (depending on the 124 activation mode) 126 o RCS: Reassembly Check Sequence. Used to verify the integrity of 127 the fragmentation-reassembly process 129 o TBD: all significant LoRaWAN-related terms. 131 o OUI: Organisation Unique Identifier. IEEE assigned prefix for EUI 133 3. Static Context Header Compression Overview 135 This section contains a short overview of Static Context Header 136 Compression (SCHC). For a detailed description, refer to the full 137 specification [RFC8724]. 139 It defines: 141 1. Compression mechanisms to avoid transport of known data by both 142 sender and receiver over the air. Known data are part of the 143 "context" 145 2. Fragmentation mechanisms to allow SCHC Packet transportation on 146 small, and potentially variable, MTU 148 Context exchange or pre-provisioning is out of scope of this 149 document. 151 Dev App 152 +----------------+ +----+ +----+ +----+ 153 | App1 App2 App3 | |App1| |App2| |App3| 154 | | | | | | | | 155 | UDP | |UDP | |UDP | |UDP | 156 | IPv6 | |IPv6| |IPv6| |IPv6| 157 | | | | | | | | 158 |SCHC C/D and F/R| | | | | | | 159 +--------+-------+ +----+ +----+ +----+ 160 | +---+ +----+ +----+ +----+ . . . 161 +~ |RGW| === |NGW | == |SCHC| == |SCHC|...... Internet .... 162 +---+ +----+ |F/R | |C/D | 163 +----+ +----+ 165 Figure 1: Architecture 167 Figure 1 represents the architecture for compression/decompression, 168 it is based on [RFC8376] terminology. The Device is sending 169 applications flows using IPv6 or IPv6/UDP protocols. These flows 170 might be compressed by an Static Context Header Compression 171 Compressor/Decompressor (SCHC C/D) to reduce headers size and 172 fragmented (SCHC F/R). The resulting information is sent on a layer 173 two (L2) frame to an LPWAN Radio Gateway (RGW) that forwards the 174 frame to a Network Gateway (NGW). The NGW sends the data to a SCHC 175 F/R for defragmentation, if required, then C/D for decompression 176 which shares the same rules with the device. The SCHC F/R and C/D 177 can be located on the Network Gateway (NGW) or in another place as 178 long as a tunnel is established between the NGW and the SCHC F/R, 179 then SCHC F/R and SCHC C/D. The SCHC C/D in both sides MUST share 180 the same set of rules. After decompression, the packet can be sent 181 on the Internet to one or several LPWAN Application Servers (App). 183 The SCHC F/R and SCHC C/D process is bidirectional, so the same 184 principles can be applied in the other direction. 186 In a LoRaWAN network, the RG is called a Gateway, the NGW is Network 187 Server, and the SCHC C/D is an Application Server. It can be 188 provided by the Network Server or any third party software. Figure 1 189 can be mapped in LoRaWAN terminology to: 191 Dev App 192 +--------------+ +----+ +----+ +----+ 193 |App1 App2 App3| |App1| |App2| |App3| 194 | | | | | | | | 195 | UDP | |UDP | |UDP | |UDP | 196 | IPv6 | |IPv6| |IPv6| |IPv6| 197 | | | | | | | | 198 |SCHC C/D & F/R| | | | | | | 199 +-------+------+ +----+ +----+ +----+ 200 | +-------+ +-------+ +-----------+ . . . 201 +~ |Gateway| === |Network| == |Application|..... Internet .... 202 +-------+ |server | |server | 203 +-------+ | F/R - C/D | 204 +-----------+ 206 Figure 2: SCHC Architecture mapped to LoRaWAN 208 4. LoRaWAN Architecture 210 An overview of LoRaWAN [lora-alliance-spec] protocol and architecture 211 is described in [RFC8376]. The mapping between the LPWAN 212 architecture entities as described in [RFC8724] and the ones in 213 [lora-alliance-spec] is as follows: 215 o Devices (Dev) are the end-devices or hosts (e.g. sensors, 216 actuators, etc.). There can be a very high density of devices per 217 radio gateway (LoRaWAN gateway). This entity maps to the LoRaWAN 218 End-Device. 220 o The Radio Gateway (RGW), which is the endpoint of the constrained 221 link. This entity maps to the LoRaWAN Gateway. 223 o The Network Gateway (NGW) is the interconnection node between the 224 Radio Gateway and the Internet. This entity maps to the LoRaWAN 225 Network Server. 227 o Application Server (App). The same terminology is used in LoRaWAN. 228 In that case, the application server will be the SCHC gateway, doing 229 C/D and F/R. 231 () () () | +------+ 232 () () () () / \ +---------+ | Join | 233 () () () () () / \======| ^ |===|Server| +-----------+ 234 () () () | | <--|--> | +------+ |Application| 235 () () () () / \==========| v |=============| Server | 236 () () () / \ +---------+ +-----------+ 237 End-Devices Gateways Network Server 239 Figure 3: LPWAN Architecture 241 SCHC C/D (Compressor/Decompressor) and SCHC F/R (Fragmentation/ 242 Reassembly) are performed on the LoRaWAN End-Device and the 243 Application Server (called SCHC gateway). While the point-to-point 244 link between the End-Device and the Application Server constitutes 245 single IP hop, the ultimate end-point of the IP communication may be 246 an Internet node beyond the Application Server. In other words, the 247 LoRaWAN Application Server (SCHC gateway) acts as the first hop IP 248 router for the End-Device. The Application Server and Network Server 249 may be co-located, which effectively turns the Network/Application 250 Server into the first hop IP router. 252 4.1. End-Device classes (A, B, C) and interactions 254 The LoRaWAN MAC layer supports 3 classes of end-devices named A, B 255 and C. All end-devices implement the Class A, some end-devices may 256 implement Class B or Class C. Class B and Class C are mutually 257 exclusive. 259 o Class A: The Class A is the simplest class of end-devices. The 260 end-device is allowed to transmit at any time, randomly selecting 261 a communication channel. The network may reply with a downlink in 262 one of the 2 receive windows immediately following the uplinks. 263 Therefore, the network cannot initiate a downlink, it has to wait 264 for the next uplink from the end-device to get a downlink 265 opportunity. The Class A is the lowest power end-device class. 267 o Class B: Class B end-devices implement all the functionalities of 268 Class A end-devices, but also schedule periodic listen windows. 269 Therefore, opposed to the Class A end-devices, Class B end-devices 270 can receive downlinks that are initiated by the network and not 271 following an uplink. There is a trade-off between the periodicity 272 of those scheduled Class B listen windows and the power 273 consumption of the end-device. The lower the downlink latency, 274 the higher the power consumption. 276 o Class C: Class C end-devices implement all the functionalities of 277 Class A end-devices, but keep their receiver open whenever they 278 are not transmitting. Class C end-devices can receive downlinks 279 at any time at the expense of a higher power consumption. 280 Battery-powered end-devices can only operate in Class C for a 281 limited amount of time (for example for a firmware upgrade over- 282 the-air). Most of the Class C end-devices are grid powered (for 283 example Smart Plugs). 285 4.2. End-Device addressing 287 LoRaWAN end-devices use a 32-bit network address (devAddr) to 288 communicate with the network over-the-air, this address might not be 289 unique in a LoRaWAN network; end-devices using the same devAddr are 290 distinguished by the Network Server based on the cryptographic 291 signature appended to every LoRaWAN frame. 293 To communicate with the SCHC gateway the Network Server MUST identify 294 the end-devices by a unique 64-bit device identifier called the 295 devEUI. 297 The devEUI is assigned to the end-device during the manufacturing 298 process by the end-device's manufacturer. It is built like an 299 Ethernet MAC address by concatenating the manufacturer's IEEE OUI 300 field with a vendor unique number. e.g.: 24-bit OUI is concatenated 301 with a 40-bit serial number. The Network Server translates the 302 devAddr into a devEUI in the uplink direction and reciprocally on the 303 downlink direction. 305 +--------+ +----------+ +---------+ +----------+ 306 | End- | <=====> | Network | <====> | SCHC | <========> | Internet | 307 | Device | devAddr | Server | devEUI | Gateway | IPv6/UDP | | 308 +--------+ +----------+ +---------+ +----------+ 310 Figure 4: LoRaWAN addresses 312 4.3. General Message Types 314 o Confirmed messages: The sender asks the receiver to acknowledge 315 the message. 317 o Unconfirmed messages: The sender does not ask the receiver to 318 acknowledge the message. 320 As SCHC defines its own acknowledgment mechanisms, SCHC does not 321 require to use confirmed messages. 323 4.4. LoRaWAN MAC Frames 325 o JoinRequest: This message is used by an end-device to join a 326 network. It contains the end-device's unique identifier devEUI 327 and a random nonce that will be used for session key derivation. 329 o JoinAccept: To on-board an end-device, the Network Server responds 330 to the JoinRequest issued by an end-device with a JoinAccept 331 message. That message is encrypted with the end-device's AppKey 332 and contains (amongst other fields) the major network's settings 333 and a network random nonce used to derive the session keys. 335 o Data: MAC and application data. Application data are protected 336 with AES-128 encryption, MAC related data are AES-128 encrypted 337 with another key. 339 4.5. Unicast and multicast technology 341 LoRaWAN technology supports unicast downlinks, but also multicast: a 342 packet send over LoRaWAN radio link can be received by several 343 devices. It is useful to address many end-devices with same content, 344 either a large binary file (firmware upgrade), or same command (e.g: 345 lighting control). As IPv6 is also a multicast technology this 346 feature can be used to address a group of devices. 348 _Note 1_: IPv6 multicast addresses must be defined as per [RFC4291]. 349 LoRaWAN multicast group definition in a network server and the 350 relation between those groups and IPv6 groupID are out of scope of 351 this document. 353 _Note 2_: LoRa Alliance defined [lora-alliance-remote-multicast-set] 354 as RECOMMENDED way to setup multicast groups on devices and create a 355 synchronized reception window. 357 5. SCHC-over-LoRaWAN 359 5.1. LoRaWAN FPort 361 The LoRaWAN MAC layer features a frame port field in all frames. 362 This field (FPort) is 8 bits long and the values from 1 to 223 can be 363 used. It allows LoRaWAN networks and applications to identify data. 365 The FPort field is part of the SCHC Message, as shown in Figure 5. 366 The SCHC C/D and the SCHC F/R SHALL concatenate the FPort field with 367 the LoRaWAN payload to retrieve their payload as it is used as a part 368 of the RuleID field. 370 | FPort | LoRaWAN payload | 371 + ------------------------ + 372 | SCHC payload | 374 Figure 5: SCHC Message in LoRaWAN 376 A fragmentation session with application payload transferred from 377 device to server, is called uplink fragmentation session. It uses an 378 FPort for data uplink and its associated SCHC control downlinks, 379 named FPortUp in this document. The other way, a fragmentation 380 session with application payload transferred from server to device, 381 is called downlink fragmentation session. It uses another FPort for 382 data downlink and its associated SCHC control uplinks, named 383 FPortDown in this document. 385 All ruleId can use arbitrary values inside the FPort range allowed by 386 LoRaWAN specification and MUST be shared by the end-device and SCHC 387 gateway prior to the communication with the selected rule. The 388 uplink and downlink fragmentation FPorts MUST be different. 390 5.2. Rule ID management 392 RuleID MUST be 8 bits, encoded in the LoRaWAN FPort as described in 393 Section 5.1. LoRaWAN supports up to 223 application FPorts in the 394 range [1;223] as defined in section 4.3.2 of [lora-alliance-spec], it 395 implies that RuleID MSB SHOULD be inside this range. An application 396 can send non SCHC traffic by using FPort values different from the 397 ones used for SCHC. 399 In order to improve interoperability RECOMMENDED fragmentation RuleID 400 values are: 402 o RuleID = 20 (8-bit) for uplink fragmentation, named FPortUp 404 o RuleID = 21 (8-bit) for downlink fragmentation, named FPortDown 406 o RuleID = 22 (8-bit) for which SCHC compression was not possible 407 (no matching rule was found) 409 The remaining RuleIDs are available for compression. RuleIDs are 410 shared between uplink and downlink sessions. A RuleID not in the 411 set(s) of FPortUp or FPortDown means that the fragmentation is not 412 used, thus, on reception, the SCHC Message MUST be sent to the C/D 413 layer. 415 The only uplink messages using the FPortDown port are the 416 fragmentation SCHC control messages of a downlink fragmentation 417 session (for example, SCHC ACKs). Similarly, the only downlink 418 messages using the FPortUp port are the fragmentation SCHC control 419 messages of an uplink fragmentation session. 421 An application can have multiple fragmentation sessions between a 422 device and one or several SCHC gateways. A set of FPort values is 423 REQUIRED for each SCHC gateway instance the device is required to 424 communicate with. 426 The mechanism for sharing those RuleID values is outside the scope of 427 this document. 429 5.3. IID computation 431 In order to mitigate risks described in [RFC8064] and [RFC8065] IID 432 MUST be created regarding the following algorithm: 434 1. key = LoRaWAN AppSKey 436 2. cmac = aes128_cmac(key, devEui) 438 3. IID = cmac[0..7] 440 aes128_cmac algorithm is described in [RFC4493]. It has been chosen 441 as it is already used by devices for LoRaWAN protocol. 443 As AppSKey is renewed each time a device joins or rejoins a network, 444 the IID will change over time; this mitigates privacy, location 445 tracking and correlation over time risks. Join periodicity is 446 defined at the application level. 448 Address scan risk is mitigated thanks to AES-128, which provides 449 enough entropy bits of the IID. 451 Using this algorithm will also ensure that there is no correlation 452 between the hardware identifier (IEEE-64 devEUI) and the IID, so an 453 attacker cannot use manufacturer OUI to target devices. 455 Example with: 457 o devEui: 0x1122334455667788 459 o appSKey: 0x00AABBCCDDEEFF00AABBCCDDEEFFAABB 460 1. key: 0x00AABBCCDDEEFF00AABBCCDDEEFFAABB 461 2. cmac: 0x4E822D9775B2649928F82066AF804FEC 462 3. IID: 0x28F82066AF804FEC 464 Figure 6: Example of IID computation. 466 There is a small probability of IID collision in a network, if such 467 event occurs the IID can be changed by rekeying the device on L2 468 level (ie: trigger a LoRaWAN join). The way the device is rekeyed is 469 out of scope of this document and left to the implementation. 471 5.4. Padding 473 All padding bits MUST be 0. 475 5.5. Decompression 477 SCHC C/D MUST concatenate FPort and LoRaWAN payload to retrieve the 478 SCHC Packet as per Section 5.1. 480 RuleIDs matching FPortUp and FPortDown are reserved for SCHC 481 Fragmentation. 483 5.6. Fragmentation 485 The L2 Word Size used by LoRaWAN is 1 byte (8 bits). The SCHC 486 fragmentation over LoRaWAN uses the ACK-on-Error mode for uplink 487 fragmentation and Ack-Always mode for downlink fragmentation. A 488 LoRaWAN end-device cannot support simultaneous interleaved 489 fragmentation sessions in the same direction (uplink or downlink). 491 The fragmentation parameters are different for uplink and downlink 492 fragmentation sessions and are successively described in the next 493 sections. 495 5.6.1. DTag 497 A LoRaWAN device cannot interleave several fragmented SCHC datagrams 498 on the same FPort. This field is not used and its size is 0. 500 Note: The device can still have several parallel fragmentation 501 sessions with one or more SCHC gateway(s) thanks to distinct sets of 502 FPorts, cf Section 5.2 504 5.6.2. Uplink fragmentation: From device to SCHC gateway 506 In that case the device is the fragmentation transmitter, and the 507 SCHC gateway the fragmentation receiver. A single fragmentation rule 508 is defined. SCHC F/R MUST concatenate FPort and LoRaWAN payload to 509 retrieve the SCHC Packet, as per Section 5.1. 511 o SCHC header size is two bytes (the FPort byte + 1 additional 512 byte). 514 o RuleID: 8 bits stored in LoRaWAN FPort. 516 o SCHC fragmentation reliability mode: "ACK-on-Error" 518 o DTag: Size is 0 bit, not used 520 o FCN: The FCN field is encoded on N = 6 bits, so WINDOW_SIZE = 63 521 tiles are allowed in a window 523 o Window index: encoded on W = 2 bits. So 4 windows are available. 525 o RCS: Use recommended calculation algorithm in [RFC8724]. 527 o MAX_ACK_REQUESTS: 8 529 o Tile: size is 10 bytes 531 o Retransmission timer: LoRaWAN end-devices MUST NOT implement a 532 "retransmission timer", this changes the specification of 533 [RFC8724], see Section 5.6.3.5. It must transmit MAX_ACK_REQUESTS 534 time the SCHC ACK REQ at it own timing; ie the periodicity between 535 retransmission of SCHC ACK REQs is device specific and can vary 536 depending on other application uplinks and regulations. 538 o Inactivity timer: The SCHC gateway implements an "inactivity 539 timer". The default RECOMMENDED duration of this timer is 12 540 hours; this value is mainly driven by application requirements and 541 MAY be changed by the application. 543 o Penultimate tile MUST be equal to the regular size. 545 o Last tile: it can be carried in a Regular SCHC Fragment, alone in 546 an All-1 SCHC Fragment or with any of these two methods: 547 implementation must ensure that: 549 * The sender MUST ascertain that the receiver will not receive 550 the last tile through both a Regular SCHC Fragment and an All-1 551 SCHC Fragment. 553 * If last tile is in All-1 message: current L2 MTU MUST be big 554 enough to fit the All-1 and the last tile. 556 With this set of parameters, the SCHC fragment header is 16 bits, 557 including FPort; payload overhead will be 8 bits as FPort is already 558 a part of LoRaWAN payload. MTU is: _4 windows * 63 tiles * 10 bytes 559 per tile = 2520 bytes_ 561 For battery powered SCHC sender, it is RECOMMENDED to use ACK 562 mechanism at the end of each window instead of waiting the end of all 563 windows: 565 o SCHC receiver SHOULD send a SCHC ACK after every window even if 566 there is no missing tiles. 568 o SCHC sender SHOULD wait for the SCHC ACK from the SCHC receiver 569 before sending tiles from next window. If the SCHC ACK is not 570 received, it SHOULD send an SCHC ACK REQ up to MAX_ACK_REQUESTS 571 time as described previously. 573 For non-battery powered devices, SCHC receiver MAY also choose to 574 send a SCHC ACK only at the end of all windows. It will reduce 575 downlink load on the network, by reducing the number of downlinks. 577 SCHC implementations MUST be compatible with both behavior, and 578 selection is a part of the rule context. 580 5.6.2.1. Regular fragments 582 | FPort | LoRaWAN payload | 583 + ------ + ------------------------- + 584 | RuleID | W | FCN | Payload | 585 + ------ + ------ + ------ + ------- + 586 | 8 bits | 2 bits | 6 bits | | 588 Figure 7: All fragments except the last one. SCHC header size is 16 589 bits, including LoRaWAN FPort. 591 5.6.2.2. Last fragment (All-1) 592 | FPort | LoRaWAN payload | 593 + ------ + ---------------------------- + 594 | RuleID | W | FCN=All-1 | RCS | 595 + ------ + ------ + --------- + ------- + 596 | 8 bits | 2 bits | 6 bits | 32 bits | 598 Figure 8: All-1 fragment detailed format for the last fragment. 600 5.6.2.3. SCHC ACK 602 | FPort | LoRaWAN payload | 603 + ------ + ----------------------------------------- + 604 | RuleID | W | C | Encoded bitmap (if C = 0) | 605 + ------ + ----- + ----- + ------------------------- + 606 | 8 bits | 2 bit | 1 bit | 0 to 63 bits | 608 Figure 9: SCHC ACK format, failed RCS check. 610 5.6.2.4. Receiver-Abort 612 | FPort | LoRaWAN payload | 613 + ------ + -------------------------------------------- + 614 | RuleID | W = b'11 | C = 1 | b'11111 | 0xFF (all 1's) | 615 + ------ + -------- + ------+-------- + ----------------+ 616 | 8 bits | 2 bits | 1 bit | 5 bits | 8 bits | 617 next L2 Word boundary ->| <-- L2 Word --> | 619 Figure 10: Receiver-Abort format. 621 5.6.2.5. SCHC acknowledge request 623 | FPort | LoRaWAN payload | 624 +------- +------------------------- + 625 | RuleID | W | FCN = b'000000 | 626 + ------ + ------ + --------------- + 627 | 8 bits | 2 bits | 6 bits | 629 Figure 11: SCHC ACK REQ format. 631 5.6.3. Downlink fragmentation: From SCHC gateway to a device 633 In that case the device is the fragmentation receiver, and the SCHC 634 gateway the fragmentation transmitter. The following fields are 635 common to all devices. SCHC F/R MUST concatenate FPort and LoRaWAN 636 payload to retrieve the SCHC Packet as described in Section 5.1. 638 o SCHC fragmentation reliability mode: 640 * Unicast downlinks: ACK-Always. 642 * Multicast downlinks: No-ACK, reliability has to be ensured by 643 the upper layer. This feature is OPTIONAL and may not be 644 implemented by SCHC gateway. 646 o RuleID: 8 bits stored in LoRaWAN FPort. 648 o Window index (unicast only): encoded on W=1 bit, as per [RFC8724]. 650 o DTag: Size is 0 bit, not used 652 o FCN: The FCN field is encoded on N=1 bit, so WINDOW_SIZE = 1 tile 653 (FCN=All-1 is reserved for SCHC). 655 o RCS: Use recommended calculation algorithm in [RFC8724]. 657 o MAX_ACK_REQUESTS: 8 659 As only 1 tile is used, its size can change for each downlink, and 660 will be maximum available MTU. 662 _Note_: The Fpending bit included in LoRaWAN protocol SHOULD NOT be 663 used for SCHC-over-LoRaWAN protocol. It might be set by the Network 664 Server for other purposes but not SCHC needs. 666 5.6.3.1. Regular fragments 668 | FPort | LoRaWAN payload | 669 + ------ + ------------------------------------ + 670 | RuleID | W | FCN = b'0 | Payload | 671 + ------ + ----- + --------- + ---------------- + 672 | 8 bits | 1 bit | 1 bit | X bytes + 6 bits | 674 Figure 12: All fragments but the last one. Header size 10 bits, 675 including LoraWAN FPort. 677 5.6.3.2. Last fragment (All-1) 679 | FPort | LoRaWAN payload | 680 + ------ + --------------------------- + 681 | RuleID | W | FCN = b'1 | RCS | 682 + ------ + ----- + --------- + ------- + 683 | 8 bits | 1 bit | 1 bit | 32 bits | 685 Figure 13: All-1 SCHC Message: the last fragment. 687 5.6.3.3. SCHC acknowledge 689 | FPort | LoRaWAN payload | 690 + ------ + ---------------------------------- + 691 | RuleID | W | C = b'1 | Padding b'000000 | 692 + ------ + ----- + ------- + ---------------- + 693 | 8 bits | 1 bit | 1 bit | 6 bits | 695 Figure 14: SCHC ACK format, RCS is correct. 697 5.6.3.4. Receiver-Abort 699 | FPort | LoRaWAN payload | 700 + ------ + ---------------------------------------------- + 701 | RuleID | W = b'1 | C = b'1 | b'111111 | 0xFF (all 1's) | 702 + ------ + ------- + ------- + -------- + --------------- + 703 | 8 bits | 1 bit | 1 bits | 6 bits | 8 bits | 704 next L2 Word boundary ->| <-- L2 Word --> | 706 Figure 15: Receiver-Abort packet (following an All-1 SCHC Fragment 707 with incorrect RCS). 709 Class A and Class B or Class C end-devices do not manage 710 retransmissions and timers in the same way. 712 5.6.3.5. Class A end-devices 714 Class A end-devices can only receive in an RX slot following the 715 transmission of an uplink. Therefore there cannot be a concept of 716 "retransmission timer" for an SCHC gateway. The SCHC gateway cannot 717 initiate communication to a Class A end-device. 719 The device replies with an ACK message to every single fragment 720 received from the SCHC gateway (because the window size is 1). 722 Following the reception of a FCN=0 fragment (fragment that is not the 723 last fragment of the packet or SCHC ACK REQ, but the end of a 724 window), the device MUST transmit the SCHC ACK fragment until it 725 receives the fragment of the next window. The device SHALL transmit 726 up to MAX_ACK_REQUESTS ACK messages before aborting. The device 727 should transmit those ACK as soon as possible while taking into 728 consideration potential local radio regulation on duty-cycle, to 729 progress the fragmentation session as quickly as possible. The ACK 730 bitmap is 1 bit long and is always 1. 732 Following the reception of an FCN=All-1 fragment (the last fragment 733 of a datagram) and if the RCS is correct, the device SHALL transmit 734 the ACK with the "RCS is correct" indicator bit set (C=1). This 735 message might be lost therefore the SCHC gateway MAY request a 736 retransmission of this ACK in the next downlink. The device SHALL 737 keep this ACK message in memory until it receives a downlink, on SCHC 738 FPortDown from the SCHC gateway different from an SCHC ACK REQ: it 739 indicates that the SCHC gateway has received the ACK message. 741 The fragmentation sender (the SCHC gateway) implements an inactivity 742 timer with a default duration of 12 hours. Once a fragmentation 743 session is started, if the SCHC gateway has not received any ACK or 744 Receiver-Abort message 12 hours after the last message from the 745 device was received, the SCHC gateway MAY flush the fragmentation 746 context. For devices with very low transmission rates (example 1 747 packet a day in normal operation) , that duration may be extended, 748 but this is application specific. 750 5.6.3.6. Class B or Class C end-devices 752 Class B and Class C end-devices can receive in scheduled RX slots or 753 in RX slots following the transmission of an uplink. The device 754 replies with an ACK message to every single fragment received from 755 the SCHC gateway (because the window size is 1). Following the 756 reception of an FCN=0 fragment (fragment that is not the last 757 fragment of the packet or SCHC ACK REQ), the device MUST always 758 transmit the corresponding SCHC ACK message even if that fragment has 759 already been received. The ACK bitmap is 1 bit long and is always 1. 760 If the SCHC gateway receives this ACK, it proceeds to send the next 761 window fragment. If the retransmission timer elapses and the SCHC 762 gateway has not received the ACK of the current window it retransmits 763 the last fragment. The SCHC gateway tries retransmitting up to 764 MAX_ACK_REQUESTS times before aborting. 766 Following the reception of an FCN=All-1 fragment (the last fragment 767 of a datagram) and if the RCS is correct, the device SHALL transmit 768 the ACK with the "RCS is correct" indicator bit set. If the SCHC 769 gateway receives this ACK, the current fragmentation session has 770 succeeded and its context can be cleared. 772 If the retransmission timer elapses and the SCHC gateway has not 773 received the SCHC ACK it retransmits the last fragment with the 774 payload (not an SCHC ACK REQ without payload). The SCHC gateway 775 tries retransmitting up to MAX_ACK_REQUESTS times before aborting. 777 Following the reception of an FCN=All-1 fragment (the last fragment 778 of a datagram), if all fragments have been received and if the RCS is 779 NOT correct, the device SHALL transmit a Receiver-Abort fragment. 780 The retransmission timer is used by the SCHC gateway (the sender), 781 the optimal value is very much application specific but here are some 782 recommended default values. For Class B end-devices, this timer 783 trigger is a function of the periodicity of the Class B ping slots. 784 The RECOMMENDED value is equal to 3 times the Class B ping slot 785 periodicity. For Class C end-devices which are nearly constantly 786 receiving, the RECOMMENDED value is 30 seconds. This means that the 787 end-device shall try to transmit the ACK within 30 seconds of the 788 reception of each fragment. The inactivity timer is implemented by 789 the end-device to flush the context in case it receives nothing from 790 the SCHC gateway over an extended period of time. The RECOMMENDED 791 value is 12 hours for both Class B and Class C end-devices. 793 6. Security considerations 795 This document is only providing parameters that are expected to be 796 better suited for LoRaWAN networks for [RFC8724]. IID security is 797 discussed in Section 5.3. As such, this document does not contribute 798 to any new security issues in addition to those identified in 799 [RFC8724]. Moreover SCHC data (LoRaWAN payload) are protected on 800 LoRaWAN level by an AES-128 encryption with key shared by device and 801 SCHC gateway. Those keys are renew each LoRaWAN session (ie: each 802 join or rejoin to the network) 804 Acknowledgements 806 Thanks to all those listed in the Contributors section for the 807 excellent text, insightful discussions, reviews and suggestions, and 808 also to (in alphabetical order) Dominique Barthel, Arunprabhu 809 Kandasamy, Rodrigo Munoz, Alexander Pelov, Pascal Thubert, Laurent 810 Toutain for useful design considerations, reviews and comments. 812 Contributors 814 Contributors ordered by family name. 816 Vincent Audebert 817 EDF R&D 818 Email: vincent.audebert@edf.fr 820 Julien Catalano 821 Kerlink 822 Email: j.catalano@kerlink.fr 824 Michael Coracin 825 Semtech 826 Email: mcoracin@semtech.com 828 Marc Le Gourrierec 829 Sagemcom 830 Email: marc.legourrierec@sagemcom.com 832 Nicolas Sornin 833 Semtech 834 Email: nsornin@semtech.com 836 Alper Yegin 837 Actility 838 Email: alper.yegin@actility.com 840 9. References 842 9.1. Normative References 844 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 845 Requirement Levels", BCP 14, RFC 2119, 846 DOI 10.17487/RFC2119, March 1997, 847 . 849 [RFC3385] Sheinwald, D., Satran, J., Thaler, P., and V. Cavanna, 850 "Internet Protocol Small Computer System Interface (iSCSI) 851 Cyclic Redundancy Check (CRC)/Checksum Considerations", 852 RFC 3385, DOI 10.17487/RFC3385, September 2002, 853 . 855 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 856 Architecture", RFC 4291, DOI 10.17487/RFC4291, February 857 2006, . 859 [RFC4493] Song, JH., Poovendran, R., Lee, J., and T. Iwata, "The 860 AES-CMAC Algorithm", RFC 4493, DOI 10.17487/RFC4493, June 861 2006, . 863 [RFC4944] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler, 864 "Transmission of IPv6 Packets over IEEE 802.15.4 865 Networks", RFC 4944, DOI 10.17487/RFC4944, September 2007, 866 . 868 [RFC5795] Sandlund, K., Pelletier, G., and L-E. Jonsson, "The RObust 869 Header Compression (ROHC) Framework", RFC 5795, 870 DOI 10.17487/RFC5795, March 2010, 871 . 873 [RFC7136] Carpenter, B. and S. Jiang, "Significance of IPv6 874 Interface Identifiers", RFC 7136, DOI 10.17487/RFC7136, 875 February 2014, . 877 [RFC8064] Gont, F., Cooper, A., Thaler, D., and W. Liu, 878 "Recommendation on Stable IPv6 Interface Identifiers", 879 RFC 8064, DOI 10.17487/RFC8064, February 2017, 880 . 882 [RFC8065] Thaler, D., "Privacy Considerations for IPv6 Adaptation- 883 Layer Mechanisms", RFC 8065, DOI 10.17487/RFC8065, 884 February 2017, . 886 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 887 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 888 May 2017, . 890 [RFC8376] Farrell, S., Ed., "Low-Power Wide Area Network (LPWAN) 891 Overview", RFC 8376, DOI 10.17487/RFC8376, May 2018, 892 . 894 [RFC8724] Minaburo, A., Toutain, L., Gomez, C., Barthel, D., and JC. 895 Zuniga, "SCHC: Generic Framework for Static Context Header 896 Compression and Fragmentation", RFC 8724, 897 DOI 10.17487/RFC8724, April 2020, 898 . 900 9.2. Informative References 902 [lora-alliance-remote-multicast-set] 903 Alliance, L., "LoRaWAN Remote Multicast Setup 904 Specification Version 1.0.0", . 908 [lora-alliance-spec] 909 Alliance, L., "LoRaWAN Specification Version V1.0.3", 910 . 913 Appendix A. Examples 915 A.1. Uplink - Compression example - No fragmentation 917 This example represents an applicative payload going through SCHC 918 over LoRaWAN, no fragmentation required 920 An applicative payload of 78 bytes is passed to SCHC compression 921 layer. Rule 1 is used by C/D layer, allowing to compress it to 40 922 bytes and 5 bits: 1 byte RuleID, 21 bits residue + 37 bytes payload. 924 | RuleID | Compression residue | Payload | Padding=b'000 | 925 + ------ + ------------------- + --------- + ------------- + 926 | 1 | 21 bits | 37 bytes | 3 bits | 928 Figure 16: Uplink example: SCHC Message 930 The current LoRaWAN MTU is 51 bytes, although 2 bytes FOpts are used 931 by LoRaWAN protocol: 49 bytes are available for SCHC payload; no need 932 for fragmentation. The payload will be transmitted through FPort = 933 1. 935 | LoRaWAN Header | LoRaWAN payload (40 bytes) | 936 + ------------------------- + --------------------------------------- + 937 | | FOpts | RuleID=1 | Compression | Payload | Padding=b'000 | 938 | | | | residue | | | 939 + ---- + ------- + -------- + ----------- + --------- + ------------- + 940 | XXXX | 2 bytes | 1 byte | 21 bits | 37 bytes | 3 bits | 942 Figure 17: Uplink example: LoRaWAN packet 944 A.2. Uplink - Compression and fragmentation example 946 This example represents an applicative payload going through SCHC, 947 with fragmentation. 949 An applicative payload of 478 bytes is passed to SCHC compression 950 layer. Rule 1 is used by C/D layer, allowing to compress it to 282 951 bytes and 5 bits: 1 byte RuleID, 21 bits residue + 279 bytes payload. 953 | RuleID | Compression residue | Payload | 954 + ------ + ------------------- + --------- + 955 | 1 | 21 bits | 279 bytes | 957 Figure 18: Uplink example: SCHC Message 959 The current LoRaWAN MTU is 11 bytes, 0 bytes FOpts are used by 960 LoRaWAN protocol: 11 bytes are available for SCHC payload + 1 byte 961 FPort field. SCHC header is 2 bytes (including FPort) so 1 tile is 962 sent in first fragment. 964 | LoRaWAN Header | LoRaWAN payload (11 bytes) | 965 + -------------------------- + -------------------------- + 966 | | RuleID=20 | W | FCN | 1 tile | 967 + -------------- + --------- + ----- + ------ + --------- + 968 | XXXX | 1 byte | 0 0 | 62 | 10 bytes | 970 Figure 19: Uplink example: LoRaWAN packet 1 972 Content of the tile is: 973 | RuleID | Compression residue | Payload | 974 + ------ + ------------------- + ----------------- + 975 | 1 | 21 bits | 6 byte + 3 bits | 977 Figure 20: Uplink example: LoRaWAN packet 1 - Tile content 979 Next transmission MTU is 11 bytes, although 2 bytes FOpts are used by 980 LoRaWAN protocol: 9 bytes are available for SCHC payload + 1 byte 981 FPort field, a tile does not fit inside so LoRaWAN stack will send 982 only FOpts. 984 Next transmission MTU is 242 bytes, 4 bytes FOpts. 23 tiles are 985 transmitted: 987 | LoRaWAN Header | LoRaWAN payload (231 bytes) | 988 + --------------------------------------+ --------------------------- + 989 | | FOpts | RuleID=20 | W | FCN | 23 tiles | 990 + -------------- + ------- + ---------- + ----- + ----- + ----------- + 991 | XXXX | 4 bytes | 1 byte | 0 0 | 61 | 230 bytes | 993 Figure 21: Uplink example: LoRaWAN packet 2 995 Next transmission MTU is 242 bytes, no FOpts. All 5 remaining tiles 996 are transmitted, the last tile is only 2 bytes + 5 bits. Padding is 997 added for the remaining 3 bits. 999 | LoRaWAN Header | LoRaWAN payload (44 bytes) | 1000 + ---- + -----------+ ------------------------------------------------- + 1001 | | RuleID=20 | W | FCN | 5 tiles | Padding=b'000 | 1002 + ---- + ---------- + ----- + ----- + ----------------- + ------------- + 1003 | XXXX | 1 byte | 0 0 | 38 | 42 bytes + 5 bits | 3 bits | 1005 Figure 22: Uplink example: LoRaWAN packet 3 1007 Then All-1 message can be transmitted: 1009 | LoRaWAN Header | LoRaWAN payload (44 bytes) | 1010 + ---- + -----------+ -------------------------- + 1011 | | RuleID=20 | W | FCN | RCS | 1012 + ---- + ---------- + ----- + ----- + ---------- + 1013 | XXXX | 1 byte | 0 0 | 63 | 4 bytes | 1015 Figure 23: Uplink example: LoRaWAN packet 4 - All-1 message 1017 All packets have been received by the SCHC gateway, computed RCS is 1018 correct so the following ACK is sent to the device by the SCHC 1019 receiver: 1021 | LoRaWAN Header | LoRaWAN payload | 1022 + -------------- + --------- + ------------------- + 1023 | | RuleID=20 | W | C | Padding | 1024 + -------------- + --------- + ----- + - + ------- + 1025 | XXXX | 1 byte | 0 0 | 1 | 5 bits | 1027 Figure 24: Uplink example: LoRaWAN packet 5 - SCHC ACK 1029 A.3. Downlink 1031 An applicative payload of 443 bytes is passed to SCHC compression 1032 layer. Rule 1 is used by C/D layer, allowing to compress it to 130 1033 bytes and 5 bits: 1 byte RuleID, 21 bits residue + 127 bytes payload. 1035 | RuleID | Compression residue | Payload | 1036 + ------ + ------------------- + --------- + 1037 | 1 | 21 bits | 127 bytes | 1039 Figure 25: Downlink example: SCHC Message 1041 The current LoRaWAN MTU is 51 bytes, no FOpts are used by LoRaWAN 1042 protocol: 51 bytes are available for SCHC payload + FPort field => it 1043 has to be fragmented. 1045 | LoRaWAN Header | LoRaWAN payload (51 bytes) | 1046 + ---- + ---------- + -------------------------------------- + 1047 | | RuleID=21 | W = 0 | FCN = 0 | 1 tile | 1048 + ---- + ---------- + ------ + ------- + ------------------- + 1049 | XXXX | 1 byte | 1 bit | 1 bit | 50 bytes and 6 bits | 1051 Figure 26: Downlink example: LoRaWAN packet 1 - SCHC Fragment 1 1053 Content of the tile is: 1055 | RuleID | Compression residue | Payload | 1056 + ------ + ------------------- + ------------------ + 1057 | 1 | 21 bits | 48 bytes and 1 bit | 1059 Figure 27: Downlink example: LoRaWAN packet 1: Tile content 1061 The receiver answers with a SCHC ACK: 1063 | LoRaWAN Header | LoRaWAN payload | 1064 + ---- + --------- + -------------------------------- + 1065 | | RuleID=21 | W = 0 | C = 1 | Padding=b'000000 | 1066 + ---- + --------- + ----- + ----- + ---------------- + 1067 | XXXX | 1 byte | 1 bit | 1 bit | 6 bits | 1069 Figure 28: Downlink example: LoRaWAN packet 2 - SCHC ACK 1071 The second downlink is sent, two FOpts: 1073 | LoRaWAN Header | LoRaWAN payload (49 bytes) | 1074 + --------------------------- + ------------------------------------- + 1075 | | FOpts | RuleID=21 | W = 1 | FCN = 0 | 1 tile | 1076 + ---- + ------- + ---------- + ----- + ------- + ------------------- + 1077 | XXXX | 2 bytes | 1 byte | 1 bit | 1 bit | 48 bytes and 6 bits | 1079 Figure 29: Downlink example: LoRaWAN packet 3 - SCHC Fragment 2 1081 The receiver answers with an SCHC ACK: 1083 | LoRaWAN Header | LoRaWAN payload | 1084 + ---- + --------- + -------------------------------- + 1085 | | RuleID=21 | W = 1 | C = 1 | Padding=b'000000 | 1086 + ---- + --------- + ----- + ----- + ---------------- + 1087 | XXXX | 1 byte | 1 bit | 1 bit | 6 bits | 1089 Figure 30: Downlink example: LoRaWAN packet 4 - SCHC ACK 1091 The last downlink is sent, no FOpts: 1093 | LoRaWAN Header | LoRaWAN payload (37 bytes) | 1094 + ---- + --------- + ----------------------------------------------------------------- + 1095 | | RuleID=21 | W = 0 | FCN = 1 | RCS | 1 tile | Padding=b'00000 | 1096 + ---- + --------- + ------- + ------- + ------- + ----------------- + --------------- + 1097 | XXXX | 1 byte | 1 bit | 1 bit | 4 bytes | 31 bytes + 1 bits | 5 bits | 1099 Figure 31: Uplink example: LoRaWAN packet 5 - All-1 message 1101 The receiver answers to the sender with an SCHC ACK: 1103 | LoRaWAN Header | LoRaWAN payload | 1104 + ---- + --------- + -------------------------------- + 1105 | | RuleID=21 | W = 0 | C = 1 | Padding=b'000000 | 1106 + ---- + --------- + ----- + ----- + ---------------- + 1107 | XXXX | 1 byte | 1 bit | 1 bit | 6 bits | 1109 Figure 32: Uplink example: LoRaWAN packet 6 - SCHC ACK 1111 Authors' Addresses 1113 Olivier Gimenez (editor) 1114 Semtech 1115 14 Chemin des Clos 1116 Meylan 1117 France 1119 Email: ogimenez@semtech.com 1121 Ivaylo Petrov (editor) 1122 Acklio 1123 1137A Avenue des Champs Blancs 1124 35510 Cesson-Sevigne Cedex 1125 France 1127 Email: ivaylo@ackl.io