idnits 2.17.1 draft-ietf-lpwan-schc-over-sigfox-03.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.) ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 265: '... The RuleID MUST be included in the ...' RFC 2119 keyword, line 313: '... No-ACK is RECOMMENDED to be used fo...' RFC 2119 keyword, line 320: '.... However it is RECOMMENDED to use FC...' RFC 2119 keyword, line 324: '...secutive fragments MUST be marked with...' RFC 2119 keyword, line 331: '... The RECOMMENDED Fragmentation Heade...' (8 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (July 13, 2020) is 1373 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 2 errors (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 lpwan Working Group JC. Zuniga 3 Internet-Draft SIGFOX 4 Intended status: Informational C. Gomez 5 Expires: January 14, 2021 Universitat Politecnica de Catalunya 6 L. Toutain 7 IMT-Atlantique 8 July 13, 2020 10 SCHC over Sigfox LPWAN 11 draft-ietf-lpwan-schc-over-sigfox-03 13 Abstract 15 The Generic Framework for Static Context Header Compression and 16 Fragmentation (SCHC) specification describes both, an application 17 header compression scheme, and a frame fragmentation and loss 18 recovery functionality for Low Power Wide Area Network (LPWAN) 19 technologies. SCHC offers a great level of flexibility that can be 20 tailored for different LPWAN technologies. 22 The present document provides the optimal parameters and modes of 23 operation when SCHC is implemented over a Sigfox LPWAN. This set of 24 parameters are also known as a "SCHC over Sigfox profile." 26 Status of This Memo 28 This Internet-Draft is submitted in full conformance with the 29 provisions of BCP 78 and BCP 79. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF). Note that other groups may also distribute 33 working documents as Internet-Drafts. The list of current Internet- 34 Drafts is at https://datatracker.ietf.org/drafts/current/. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 This Internet-Draft will expire on January 14, 2021. 43 Copyright Notice 45 Copyright (c) 2020 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents 50 (https://trustee.ietf.org/license-info) in effect on the date of 51 publication of this document. Please review these documents 52 carefully, as they describe your rights and restrictions with respect 53 to this document. Code Components extracted from this document must 54 include Simplified BSD License text as described in Section 4.e of 55 the Trust Legal Provisions and are provided without warranty as 56 described in the Simplified BSD License. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 61 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 62 3. SCHC: Generic Framework for Static Context Header Compression 63 and Fragmentation . . . . . . . . . . . . . . . . . . . . . . 3 64 4. SCHC over Sigfox . . . . . . . . . . . . . . . . . . . . . . 3 65 4.1. Network Architecture . . . . . . . . . . . . . . . . . . 3 66 4.2. Uplink . . . . . . . . . . . . . . . . . . . . . . . . . 5 67 4.3. Downlink . . . . . . . . . . . . . . . . . . . . . . . . 6 68 4.4. SCHC Rules . . . . . . . . . . . . . . . . . . . . . . . 6 69 4.5. Fragmentation . . . . . . . . . . . . . . . . . . . . . . 7 70 4.5.1. Uplink Fragmentation . . . . . . . . . . . . . . . . 7 71 4.5.2. Downlink Fragmentation . . . . . . . . . . . . . . . 10 72 4.6. Padding . . . . . . . . . . . . . . . . . . . . . . . . . 11 73 5. Security considerations . . . . . . . . . . . . . . . . . . . 11 74 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 12 75 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 76 7.1. Normative References . . . . . . . . . . . . . . . . . . 12 77 7.2. Informative References . . . . . . . . . . . . . . . . . 12 78 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 80 1. Introduction 82 The Generic Framework for Static Context Header Compression and 83 Fragmentation (SCHC) specification [RFC8724] defines both, a higher 84 layer header compression scheme and a fragmentation and loss recovery 85 functionality. Both can be used on top of all the LWPAN systems 86 defined in [RFC8376] . These LPWAN systems have similar 87 characteristics such as star-oriented topologies, network 88 architecture, connected devices with built-in applications, etc. 90 SCHC offers a great level of flexibility to accommodate all these 91 LPWAN systems. Even though there are a great number of similarities 92 between LPWAN technologies, some differences exist with respect to 93 the transmission characteristics, payload sizes, etc. Hence, there 94 are optimal parameters and modes of operation that can be used when 95 SCHC is used on top of a specific LPWAN. 97 This document describes the recommended parameters, settings and 98 modes of operation to be used when SCHC is implemented over a Sigfox 99 LPWAN. This set of parameters are also known as a "SCHC over Sigfox 100 profile." 102 2. Terminology 104 It is assumed that the reader is familiar with the terms and 105 mechanisms defined in [RFC8376] and in [RFC8724]. 107 3. SCHC: Generic Framework for Static Context Header Compression and 108 Fragmentation 110 The Generic Framework for Static Context Header Compression and 111 Fragmentation (SCHC) described in [RFC8724] takes advantage of the 112 predictability of data flows existing in LPWAN networks to avoid 113 context synchronization. 115 Contexts must be stored and pre-configured on both ends. This can be 116 done either by using a provisioning protocol, by out of band means, 117 or by pre-provisioning them (e.g. at manufacturing time). The way 118 contexts are configured and stored on both ends is out of the scope 119 of this document. 121 4. SCHC over Sigfox 123 4.1. Network Architecture 125 Figure 1 represents the architecture for compression/decompression 126 (C/D) and fragmentation/reassembly (F/R) based on the terminology 127 defined in [RFC8376], where the Radio Gateway (RG) is a Sigfox Base 128 Station and the Network Gateway (NGW) is the Sigfox cloud-based 129 Network. 131 Device Application 132 +----------------+ +--------------+ 133 | APP1 APP2 APP3 | |APP1 APP2 APP3| 134 +----------------+ +--------------+ 135 | UDP | | | | UDP | 136 | IPv6 | | | | IPv6 | 137 +--------+ | | +--------+ 138 | SCHC C/D & F/R | | | 139 | | | | 140 +-------+--------+ +--------+-----+ 141 $ . 142 $ +---------+ +--------------+ +---------+ . 143 +~~ |Sigfox BS| |Sigfox Network| | SCHC | . 144 | (RG) | === | (NGW) | === |F/R & C/D|..... 145 +---------+ +--------------+ +---------+ 147 Figure 1: Network Architecture 149 In the case of the global Sigfox Network, RGs (or Base Stations) are 150 distributed over multiple countries wherever the Sigfox LPWAN service 151 is provided. The NGW (or cloud-based Sigfox Core Network) is a 152 single entity that connects to all Sigfox base stations in the world, 153 providing hence a global single star network topology. 155 The Device is sending applications flows that are compressed and/or 156 fragmented by a SCHC Compressor/Decompressor (SCHC C/D + F/R) to 157 reduce headers size and/or fragment the packet. The resulting SCHC 158 Message is sent over a layer two (L2) Sigfox frame to the Sigfox Base 159 Stations, which then forward the SCHC Message to the Network Gateway 160 (NGW). The NGW then delivers the SCHC Message and associated 161 gathered metadata to the Network SCHC C/D + F/R. 163 The Sigfox Network (NGW) communicates with the Network SCHC C/D + F/R 164 for compression/decompression and/or for fragmentation/reassembly. 165 The Network SCHC C/D + F/R share the same set of rules as the Dev 166 SCHC C/D + F/R. The Network SCHC C/D + F/R can be collocated with 167 the NGW or it could be located in a different place, as long as a 168 tunnel or secured communication is established between the NGW and 169 the SCHC C/D + F/R functions. After decompression and/or reassembly, 170 the packet can be forwarded over the Internet to one (or several) 171 LPWAN Application Server(s) (App). 173 The SCHC C/D + F/R processes are bidirectional, so the same 174 principles are applicable on both uplink and downlink. 176 4.2. Uplink 178 Uplink Sigfox transmissions occur in repetitions over different times 179 and frequencies. Besides these time and frequency diversities, the 180 Sigfox network also provides space diversity, as potentially an 181 uplink message will be received by several base stations. 183 Since all messages are self-contained and base stations forward them 184 all back to the same Core Network, multiple input copies can be 185 combined at the NGW and hence provide for extra reliability based on 186 the triple diversity (i.e. time, space and frequency). 188 A detailed description of the Sigfox Radio Protocol can be found in 189 [sigfox-spec]. 191 Messages sent from the Device to the Network are delivered by the 192 Sigfox network (NGW) to the Network SCHC C/D + F/R through a 193 callback/API with the following information: 195 o Device ID 197 o Message Sequence Number 199 o Message Payload 201 o Message Timestamp 203 o Device Geolocation (optional) 205 o RSSI (optional) 207 o Device Temperature (optional) 209 o Device Battery Voltage (optional) 211 The Device ID is a globally unique identifier assigned to the Device, 212 which is included in the Sigfox header of every message. The Message 213 Sequence Number is a monotonically increasing number identifying the 214 specific transmission of this uplink message, and it is part of the 215 Sigfox header. The Message Payload corresponds to the payload that 216 the Device has sent in the uplink transmission. 218 The Message Timestamp, Device Geolocation, RSSI, Device Temperature 219 and Device Battery Voltage are metadata parameters provided by the 220 Network. 222 A detailed description of the Sigfox callbacks/APIs can be found in 223 [sigfox-callbacks]. 225 Only messages that have passed the L2 Cyclic Redundancy Check (CRC) 226 at network reception are delivered by the Sigfox Network to the 227 Network SCHC C/D + F/R. 229 +---------------+-----------------+ 230 | Sigfox Header | Sigfox payload | 231 +---------------+---------------- + 232 | SCHC message | 233 +-----------------+ 235 Figure 2: SCHC Message in Sigfox 237 Figure 2 shows a SCHC Message sent over Sigfox, where the SCHC 238 Message could be a full SCHC Packet (e.g. compressed) or a SCHC 239 Fragment (e.g. a piece of a bigger SCHC Packet). 241 4.3. Downlink 243 Downlink transmissions are Device-driven and can only take place 244 following an uplink communication. Hence, a Device willing to 245 receive downlink messages indicates so to the network in the 246 preceding uplink message with a downlink request flag, and then it 247 opens a fixed window for downlink reception after the uplink 248 transmission. The delay and duration of the reception window have 249 fixed values. If there is a downlink message to be sent for this 250 given Device (e.g. either a response to the uplink message or queued 251 information waiting to be transmitted), the network transmits it to 252 the Device during the reception window. 254 When a downlink message is sent to a Device, an acknowledgement is 255 generated by the Device through the Sigfox protocol and reported by 256 the Sigfox Network. This acknowledgement can be retrieved through 257 callbacks by the customer. 259 A detailed description of the Sigfox Radio Protocol can be found in 260 [sigfox-spec] and a detailed description of the Sigfox callbacks/APIs 261 can be found in [sigfox-callbacks]. 263 4.4. SCHC Rules 265 The RuleID MUST be included in the SCHC header. The total number of 266 rules to be used affects directly the Rule ID field size, and 267 therefore the total size of the fragmentation header. For this 268 reason, it is recommended to keep the number of rules that are 269 defined for a specific device to the minimum possible. 271 RuleIDs can be used to differenciate data traffic classes (e.g. QoS, 272 control vs. data, etc.), and data sessions. They can also be used to 273 interleave simultaneous fragmentation sessions between a Device and 274 the Network. 276 4.5. Fragmentation 278 The SCHC specification [RFC8724] defines a generic fragmentation 279 functionality that allows sending data packets or files larger than 280 the maximum size of a Sigfox data frame. The functionality also 281 defines a mechanism to send reliably multiple messages, by allowing 282 to resend selectively any lost fragments. 284 The SCHC fragmentation supports several modes of operation. These 285 modes have different advantages and disadvantages depending on the 286 specifics of the underlying LPWAN technology and application Use 287 Case. This section describes how the SCHC fragmentation 288 functionality should optimally be implemented when used over a Sigfox 289 LPWAN for the most typical Use Case applications. 291 The L2 Word Size used by Sigfox is 1 byte (8 bits). 293 4.5.1. Uplink Fragmentation 295 Sigfox uplink transmissions are completely asynchronous and can take 296 place in any random frequency of the allowed uplink bandwidth 297 allocation. Hence, devices can go to deep sleep mode, and then wake 298 up and transmit whenever there is a need to send any information to 299 the network. In that way, there is no need to perform any network 300 attachment, synchronization, or other procedure before transmitting a 301 data packet. All data packets are self-contained with all the 302 required information for the network to process them accordingly. 304 Since uplink transmissions occur asynchronously, an SCHC fragment can 305 be transmitted at any given time by the Device. Sigfox uplink 306 messages are fixed in size, and as described in [RFC8376] they can 307 carry 0-12 bytes payload. Hence, a single SCHC Tile size per mode 308 can be defined so that every Sigfox message always carries one SCHC 309 Tile. 311 4.5.1.1. Uplink No-ACK Mode 313 No-ACK is RECOMMENDED to be used for transmitting short, non-critical 314 packets that require fragmentation and do not require full 315 reliability. This mode can be used by uplink-only devices that do 316 not support downlink communications, or by bidirectional devices when 317 they send non-critical data. 319 Since there are no multiple windows in the No-ACK mode, the W bit is 320 not present. However it is RECOMMENDED to use FCN to indicate the 321 size of the data packet. In this sense, the data packet would need 322 to be splitted into X fragments and, similarly to the other 323 fragmentation modes, the first transmitted fragment would need to be 324 marked with FCN = X-1. Consecutive fragments MUST be marked with 325 decreasing FCN values, having the last fragment marked with FCN = 326 (All-1). Hence, even though the No-ACK mode does not allow 327 recovering missing fragments, it allows indicating implicitly to the 328 Network the size of the expected packet and whether all fragments 329 have been received or not. 331 The RECOMMENDED Fragmentation Header size is 8 bits, and it is 332 composed as follows: 334 o RuleID size: 4 bits 336 o DTag size (T): 0 bits 338 o Fragment Compressed Number (FCN) size (N): 4 bits 340 o As per [RFC8724], in the No-ACK mode the W (window) field is not 341 present. 343 o RCS: Not used 345 4.5.1.2. Uplink ACK-on-Error Mode: Single-byte SCHC Header 347 ACK-on-Error with single-byte header is RECOMMENDED for medium-large 348 size packets that need to be sent reliably. ACK-on-Error is optimal 349 for Sigfox transmissions, since it leads to a reduced number of ACKs 350 in the lower capacity downlink channel. Also, downlink messages can 351 be sent asynchronously and opportunistically. 353 Allowing transmission of packets/files up to 300 bytes long, the SCHC 354 uplink Fragmentation Header size is RECOMMENDED to be 8 bits in size 355 and is composed as follows: 357 o Rule ID size: 3 bits 359 o DTag size (T): 0 bits 361 o Window index (W) size (M): 2 bits 363 o Fragment Compressed Number (FCN) size (N): 3 bits 365 o MAX_ACK_REQUESTS: 5 366 o WINDOW_SIZE: 7 (with a maximum value of FCN=0b110) 368 o Tile size: 11 bytes 370 o Retransmission Timer: Application-dependent 372 o Inactivity Timer: Application-dependent 374 o RCS: Not used 376 The correspondent SCHC ACK in the downlink is 13 bits long, so 377 padding is needed to complete the required 64 bits of Sigfox payload. 379 4.5.1.3. Uplink ACK-on-Error Mode: Two-byte SCHC Header 381 ACK-on-Error with two-byte header is RECOMMENDED for very large size 382 packets that need to be sent reliably. ACK-on-Error is optimal for 383 Sigfox transmissions, since it leads to a reduced number of ACKs in 384 the lower capacity downlink channel. Also, downlink messages can be 385 sent asynchronously and opportunistically. 387 In order to allow transmission of very large packets/files up to 2250 388 bytes long, the SCHC uplink Fragmentation Header size is RECOMMENDED 389 to be 16 bits in size and composed as follows: 391 o Rule ID size is: 8 bits 393 o DTag size (T) is: 0 bits 395 o Window index (W) size (M): 3 bits 397 o Fragment Compressed Number (FCN) size (N): 5 bits. 399 o MAX_ACK_REQUESTS: 5 401 o WINDOW_SIZE: 31 (with a maximum value of FCN=0b11110) 403 o Tile size: 10 bytes 405 o Retransmission Timer: Application-dependent 407 o Inactivity Timer: Application-dependent 409 o RCS: Not used 411 The correspondent SCHC ACK in the downlink is 43 bits long, so 412 padding is needed to complete the required 64 bits of Sigfox payload. 414 4.5.1.4. All-1 behaviour + Sigfox Sequence Number 416 For ACK-on-Error, as defined in [RFC8724] it is expected that the 417 last SCHC fragment of the last window will always be delivered with 418 an All-1 FCN. Since this last window may not be full (i.e. it may be 419 comprised of less than WINDOW_SIZE fragments), an All-1 fragment may 420 follow a value of FCN higher than 1 (0b01). In this case, the 421 receiver could not derive from the FCN values alone whether there are 422 any missing fragments right before the All-1 fragment or not. 424 However, since a Message Sequence Number is provided by the Sigfox 425 protocol together with the Sigfox Payload, the receiver can detect if 426 there are missing fragments before the All-1 and hence construct the 427 corresponding SCHC ACK Bitmap accordingly. 429 4.5.2. Downlink Fragmentation 431 In some LPWAN technologies, as part of energy-saving techniques, 432 downlink transmission is only possible immediately after an uplink 433 transmission. This allows the device to go in a very deep sleep mode 434 and preserve battery, without the need to listen to any information 435 from the network. This is the case for Sigfox-enabled devices, which 436 can only listen to downlink communications after performing an uplink 437 transmission and requesting a downlink. 439 When there are fragments to be transmitted in the downlink, an uplink 440 message is required to trigger the downlink communication. In order 441 to avoid potentially high delay for fragmented datagram transmission 442 in the downlink, the fragment receiver MAY perform an uplink 443 transmission as soon as possible after reception of a downlink 444 fragment that is not the last one. Such uplink transmission MAY be 445 triggered by sending a SCHC message, such as a SCHC ACK. However, 446 other data messages can equally be used to trigger DL communications. 448 Sigfox downlink messages are fixed in size, and as described in 449 [RFC8376] they can carry up to 8 bytes payload. Hence, a single SCHC 450 Tile size per mode can be defined so that every Sigfox message always 451 carries one SCHC Tile. 453 For reliable downlink fragment transmission, the ACK-Always mode is 454 RECOMMENDED. 456 The SCHC downlink Fragmentation Header size is RECOMMENDED to be 8 457 bits in size and is composed as follows: 459 o RuleID size: 3 bits 461 o DTag size (T): 0 bits 462 o Window index (W) size (M) is: 0 bits 464 o Fragment Compressed Number (FCN) size (N): 5 bits 466 o MAX_ACK_REQUESTS: 5 468 o WINDOW_SIZE: 31 (with a maximum value of FCN=0b11110) 470 o Tile size: 7 bytes 472 o Retransmission Timer: Application-dependent 474 o Inactivity Timer: Application-dependent 476 o RCS: Not used 478 4.6. Padding 480 The Sigfox payload fields have different characteristics in uplink 481 and downlink. 483 Uplink frames can contain a payload size from 0 to 12 bytes. The 484 radio protocol allows sending zero bits, one single bit of 485 information for binary applications (e.g. status), or an integer 486 number of bytes. Therefore, for 2 or more bits of payload it is 487 required to add padding to the next integer number of bytes. The 488 reason for this flexibility is to optimize transmission time and 489 hence save battery consumption at the device. 491 Downlink frames on the other hand have a fixed length. The payload 492 length must be 64 bits (i.e. 8 bytes). Hence, if less information 493 bits are to be transmitted, padding would be necessary. 495 5. Security considerations 497 The radio protocol authenticates and ensures the integrity of each 498 message. This is achieved by using a unique device ID and an AES-128 499 based message authentication code, ensuring that the message has been 500 generated and sent by the device with the ID claimed in the message. 502 Application data can be encrypted at the application level or not, 503 depending on the criticality of the use case. This flexibility 504 allows providing a balance between cost and effort vs. risk. AES-128 505 in counter mode is used for encryption. Cryptographic keys are 506 independent for each device. These keys are associated with the 507 device ID and separate integrity and confidentiality keys are pre- 508 provisioned. A confidentiality key is only provisioned if 509 confidentiality is to be used. 511 The radio protocol has protections against reply attacks, and the 512 cloud-based core network provides firewalling protection against 513 undesired incoming communications. 515 6. Acknowledgements 517 Carles Gomez has been funded in part by the ERDF and the Spanish 518 Government through project TEC2016-79988-P. 520 The authors would like to thank Diego Wistuba, Clement Mannequin and 521 Sandra Cespedes for their useful comments and design considerations. 523 7. References 525 7.1. Normative References 527 [RFC8376] Farrell, S., Ed., "Low-Power Wide Area Network (LPWAN) 528 Overview", RFC 8376, DOI 10.17487/RFC8376, May 2018, 529 . 531 [RFC8724] Minaburo, A., Toutain, L., Gomez, C., Barthel, D., and JC. 532 Zuniga, "SCHC: Generic Framework for Static Context Header 533 Compression and Fragmentation", RFC 8724, 534 DOI 10.17487/RFC8724, April 2020, 535 . 537 7.2. Informative References 539 [sigfox-callbacks] 540 Sigfox, "Sigfox Callbacks", 541 . 543 [sigfox-spec] 544 Sigfox, "Sigfox Radio Specifications", 545 . 548 Authors' Addresses 550 Juan Carlos Zuniga 551 SIGFOX 552 425 rue Jean Rostand 553 Labege 31670 554 France 556 Email: JuanCarlos.Zuniga@sigfox.com 557 URI: http://www.sigfox.com/ 558 Carles Gomez 559 Universitat Politecnica de Catalunya 560 C/Esteve Terradas, 7 561 08860 Castelldefels 562 Spain 564 Email: carlesgo@entel.upc.edu 566 Laurent Toutain 567 IMT-Atlantique 568 2 rue de la Chataigneraie 569 CS 17607 570 35576 Cesson-Sevigne Cedex 571 France 573 Email: Laurent.Toutain@imt-atlantique.fr