idnits 2.17.1 draft-ietf-lpwan-schc-over-sigfox-05.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 8 instances of too long lines in the document, the longest one being 23 characters in excess of 72. ** 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 288: '...ntation mode, a DL opportunity MUST be...' RFC 2119 keyword, line 299: '...m All-0 or All-1 MUST NOT use the DL r...' RFC 2119 keyword, line 304: '... The RuleID MUST be included in the ...' RFC 2119 keyword, line 331: '...ss of a SCHC Packet MUST be checked at...' RFC 2119 keyword, line 341: '...eck Sequence (RCS) is NOT RECOMMENDED....' (12 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (February 22, 2021) is 1158 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 3 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: August 26, 2021 S. Aguilar 6 Universitat Politecnica de Catalunya 7 L. Toutain 8 IMT-Atlantique 9 S. Cespedes 10 D. Wistuba 11 NIC Labs, Universidad de Chile 12 February 22, 2021 14 SCHC over Sigfox LPWAN 15 draft-ietf-lpwan-schc-over-sigfox-05 17 Abstract 19 The Generic Framework for Static Context Header Compression and 20 Fragmentation (SCHC) specification describes two mechanisms: i) an 21 application header compression scheme, and ii) a frame fragmentation 22 and loss recovery functionality. SCHC offers a great level of 23 flexibility that can be tailored for different Low Power Wide Area 24 Network (LPWAN) technologies. 26 The present document provides the optimal parameters and modes of 27 operation when SCHC is implemented over a Sigfox LPWAN. This set of 28 parameters are also known as a "SCHC over Sigfox profile." 30 Status of This Memo 32 This Internet-Draft is submitted in full conformance with the 33 provisions of BCP 78 and BCP 79. 35 Internet-Drafts are working documents of the Internet Engineering 36 Task Force (IETF). Note that other groups may also distribute 37 working documents as Internet-Drafts. The list of current Internet- 38 Drafts is at https://datatracker.ietf.org/drafts/current/. 40 Internet-Drafts are draft documents valid for a maximum of six months 41 and may be updated, replaced, or obsoleted by other documents at any 42 time. It is inappropriate to use Internet-Drafts as reference 43 material or to cite them other than as "work in progress." 45 This Internet-Draft will expire on August 26, 2021. 47 Copyright Notice 49 Copyright (c) 2021 IETF Trust and the persons identified as the 50 document authors. All rights reserved. 52 This document is subject to BCP 78 and the IETF Trust's Legal 53 Provisions Relating to IETF Documents 54 (https://trustee.ietf.org/license-info) in effect on the date of 55 publication of this document. Please review these documents 56 carefully, as they describe your rights and restrictions with respect 57 to this document. Code Components extracted from this document must 58 include Simplified BSD License text as described in Section 4.e of 59 the Trust Legal Provisions and are provided without warranty as 60 described in the Simplified BSD License. 62 Table of Contents 64 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 65 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 66 3. SCHC: Generic Framework for Static Context Header Compression 67 and Fragmentation . . . . . . . . . . . . . . . . . . . . . . 3 68 4. SCHC over Sigfox . . . . . . . . . . . . . . . . . . . . . . 3 69 4.1. Network Architecture . . . . . . . . . . . . . . . . . . 3 70 4.2. Uplink . . . . . . . . . . . . . . . . . . . . . . . . . 5 71 4.3. Downlink . . . . . . . . . . . . . . . . . . . . . . . . 6 72 4.4. SCHC-ACK on Downlink . . . . . . . . . . . . . . . . . . 7 73 4.5. SCHC Rules . . . . . . . . . . . . . . . . . . . . . . . 7 74 4.6. Fragmentation . . . . . . . . . . . . . . . . . . . . . . 7 75 4.6.1. Uplink Fragmentation . . . . . . . . . . . . . . . . 8 76 4.6.2. Downlink Fragmentation . . . . . . . . . . . . . . . 11 77 4.7. Padding . . . . . . . . . . . . . . . . . . . . . . . . . 12 78 5. Fragmentation Sequence Examples . . . . . . . . . . . . . . . 12 79 5.1. Uplink No-ACK Examples . . . . . . . . . . . . . . . . . 12 80 5.2. Uplink ACK-on-Error Examples: Single-byte SCHC Header . . 13 81 5.3. SCHC Abort Examples . . . . . . . . . . . . . . . . . . . 19 82 6. Security considerations . . . . . . . . . . . . . . . . . . . 21 83 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 21 84 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 21 85 8.1. Normative References . . . . . . . . . . . . . . . . . . 21 86 8.2. Informative References . . . . . . . . . . . . . . . . . 22 87 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22 89 1. Introduction 91 The Generic Framework for Static Context Header Compression and 92 Fragmentation (SCHC) specification [RFC8724] describes two 93 mechanisms: i) an application header compression scheme, and ii) a 94 frame fragmentation and loss recovery functionality. Both can be 95 used on top of all the four LWPAN technologies defined in [RFC8376] . 96 These LPWANs have similar characteristics such as star-oriented 97 topologies, network architecture, connected devices with built-in 98 applications, etc. 100 SCHC offers a great level of flexibility to accommodate all these 101 LPWAN technologies. Even though there are a great number of 102 similarities between them, some differences exist with respect to the 103 transmission characteristics, payload sizes, etc. Hence, there are 104 optimal parameters and modes of operation that can be used when SCHC 105 is used on top of a specific LPWAN technology. 107 This document describes the recommended parameters, settings and 108 modes of operation to be used when SCHC is implemented over a Sigfox 109 LPWAN. This set of parameters are also known as a "SCHC over Sigfox 110 profile." 112 2. Terminology 114 It is assumed that the reader is familiar with the terms and 115 mechanisms defined in [RFC8376] and in [RFC8724]. 117 3. SCHC: Generic Framework for Static Context Header Compression and 118 Fragmentation 120 The Generic Framework for Static Context Header Compression and 121 Fragmentation (SCHC) described in [RFC8724] takes advantage of the 122 predictability of data flows existing in LPWAN applications to avoid 123 context synchronization. 125 Contexts must be stored and pre-configured on both ends. This can be 126 done either by using a provisioning protocol, by out of band means, 127 or by pre-provisioning them (e.g. at manufacturing time). The way 128 contexts are configured and stored on both ends is out of the scope 129 of this document. 131 4. SCHC over Sigfox 133 4.1. Network Architecture 135 Figure 1 represents the architecture for compression/decompression 136 (C/D) and fragmentation/reassembly (F/R) based on the terminology 137 defined in [RFC8376], where the Radio Gateway (RG) is a Sigfox Base 138 Station and the Network Gateway (NGW) is the Sigfox cloud-based 139 Network. 141 Device Application 142 +----------------+ +--------------+ 143 | APP1 APP2 APP3 | |APP1 APP2 APP3| 144 +----------------+ +--------------+ 145 | UDP | | | | UDP | 146 | IPv6 | | | | IPv6 | 147 +--------+ | | +--------+ 148 | SCHC C/D & F/R | | | 149 | | | | 150 +-------+--------+ +--------+-----+ 151 $ . 152 $ +---------+ +--------------+ +---------+ . 153 $ | | | | | Network | . 154 +~~ |Sigfox BS| |Sigfox Network| | SCHC | . 155 | (RG) | === | (NGW) | === |F/R & C/D|..... 156 +---------+ +--------------+ +---------+ 158 Figure 1: Network Architecture 160 In the case of the global Sigfox Network, RGs (or Base Stations) are 161 distributed over multiple countries wherever the Sigfox LPWAN service 162 is provided. The NGW (or cloud-based Sigfox Core Network) is a 163 single entity that connects to all Sigfox base stations in the world, 164 providing hence a global single star network topology. 166 The Device sends application flows that are compressed and/or 167 fragmented by a SCHC Compressor/Decompressor (SCHC C/D + F/R) to 168 reduce headers size and/or fragment the packet. The resulting SCHC 169 Message is sent over a layer two (L2) Sigfox frame to the Sigfox Base 170 Stations, which then forward the SCHC Message to the Network Gateway 171 (NGW). The NGW then delivers the SCHC Message and associated 172 gathered metadata to the Network SCHC C/D + F/R. 174 The Sigfox Network (NGW) communicates with the Network SCHC C/D + F/R 175 for compression/decompression and/or for fragmentation/reassembly. 176 The Network SCHC C/D + F/R share the same set of rules as the Dev 177 SCHC C/D + F/R. The Network SCHC C/D + F/R can be collocated with 178 the NGW or it could be located in a different place, as long as a 179 tunnel or secured communication is established between the NGW and 180 the SCHC C/D + F/R functions. After decompression and/or reassembly, 181 the packet can be forwarded over the Internet to one (or several) 182 LPWAN Application Server(s) (App). 184 The SCHC C/D + F/R processes are bidirectional, so the same 185 principles are applicable on both uplink (UL) and downlink (DL). 187 4.2. Uplink 189 Uplink Sigfox transmissions occur in repetitions over different times 190 and frequencies. Besides these time and frequency diversities, the 191 Sigfox network also provides space diversity, as potentially an 192 uplink message will be received by several base stations. 194 Since all messages are self-contained and base stations forward all 195 these messages back to the same Core Network, multiple input copies 196 can be combined at the NGW and hence provide for extra reliability 197 based on the triple diversity (i.e. time, space and frequency). 199 A detailed description of the Sigfox Radio Protocol can be found in 200 [sigfox-spec]. 202 Messages sent from the Device to the Network are delivered by the 203 Sigfox network (NGW) to the Network SCHC C/D + F/R through a 204 callback/API with the following information: 206 o Device ID 208 o Message Sequence Number 210 o Message Payload 212 o Message Timestamp 214 o Device Geolocation (optional) 216 o RSSI (optional) 218 o Device Temperature (optional) 220 o Device Battery Voltage (optional) 222 The Device ID is a globally unique identifier assigned to the Device, 223 which is included in the Sigfox header of every message. The Message 224 Sequence Number is a monotonically increasing number identifying the 225 specific transmission of this uplink message, and it is also part of 226 the Sigfox header. The Message Payload corresponds to the payload 227 that the Device has sent in the uplink transmission. 229 The Message Timestamp, Device Geolocation, RSSI, Device Temperature 230 and Device Battery Voltage are metadata parameters provided by the 231 Network. 233 A detailed description of the Sigfox callbacks/APIs can be found in 234 [sigfox-callbacks]. 236 Only messages that have passed the L2 Cyclic Redundancy Check (CRC) 237 at network reception are delivered by the Sigfox Network to the 238 Network SCHC C/D + F/R. 240 +---------------+-----------------+ 241 | Sigfox Header | Sigfox payload | 242 +---------------+---------------- + 243 | SCHC message | 244 +-----------------+ 246 Figure 2: SCHC Message in Sigfox 248 Figure 2 shows a SCHC Message sent over Sigfox, where the SCHC 249 Message could be a full SCHC Packet (e.g. compressed) or a SCHC 250 Fragment (e.g. a piece of a bigger SCHC Packet). 252 4.3. Downlink 254 Downlink transmissions are Device-driven and can only take place 255 following an uplink communication that so indicates. Hence, a Device 256 willing to receive a downlink message indicates explicitly its 257 intention to the network in the preceding uplink message with a 258 downlink request flag, and then it opens a fixed window for downlink 259 reception after completing the uplink transmission. The delay and 260 duration of the reception opportunity window have fixed values. If 261 there is a downlink message to be sent for this given Device (e.g. 262 either a response to the uplink message or queued information waiting 263 to be transmitted), the network transmits it to the Device during the 264 reception window. If no message is received by the Device after the 265 reception opportunity window has elapsed, the Device closes the 266 receiving opportunity and gets back to the normal mode (e.g. continue 267 UL transmissions, sleep, stand-by, etc.) 269 When a downlink message is sent to a Device, a reception 270 acknowledgement is generated by the Device back to the Network 271 through the Sigfox protocol and reported by the Sigfox Network. This 272 acknowledgement can be retrieved through callbacks by the customer. 274 A detailed description of the Sigfox Radio Protocol can be found in 275 [sigfox-spec] and a detailed description of the Sigfox callbacks/APIs 276 can be found in [sigfox-callbacks]. 278 4.4. SCHC-ACK on Downlink 280 As explained previously, downlink transmissions are Device-driven and 281 can only take place following a specific uplink transmission that 282 indicates and allows a following downlink opportunity. For this 283 reason, when SCHC bi-directional services are used (e.g. Ack-on- 284 Error fragmentation mode) the SCHC protocol implementation needs to 285 consider the times when a downlink message (e.g. SCHC-ACK) can be 286 sent and/or received. 288 For the UL ACK-on-Error fragmentation mode, a DL opportunity MUST be 289 indicated by the last fragment of every window (i.e. FCN = All-0, or 290 FCN = All-1). The Device sends the fragments in sequence and, after 291 transmitting the FCN = All-0 or FCN = All-1, it opens up a reception 292 opportunity. The Network SCHC can then decide to respond at that 293 opportunity (or wait for a further one) with a SCHC-ACK indicating in 294 case there are missing fragments from the current or previous 295 windows. If there is no SCHC-ACK to be sent, or if the network 296 decides to wait for a further DL transmission opportunity, then no DL 297 transmission takes place at that opportunity and after a timeout the 298 UL transmissions continue. Intermediate SCHC fragments with FCN 299 different from All-0 or All-1 MUST NOT use the DL request flag to 300 request a SCHC-ACK. 302 4.5. SCHC Rules 304 The RuleID MUST be included in the SCHC header. The total number of 305 rules to be used affects directly the Rule ID field size, and 306 therefore the total size of the fragmentation header. For this 307 reason, it is recommended to keep the number of rules that are 308 defined for a specific device to the minimum possible. 310 RuleIDs can be used to differentiate data traffic classes (e.g. QoS, 311 control vs. data, etc.), and data sessions. They can also be used to 312 interleave simultaneous fragmentation sessions between a Device and 313 the Network. 315 4.6. Fragmentation 317 The SCHC specification [RFC8724] defines a generic fragmentation 318 functionality that allows sending data packets or files larger than 319 the maximum size of a Sigfox data frame. The functionality also 320 defines a mechanism to send reliably multiple messages, by allowing 321 to resend selectively any lost fragments. 323 The SCHC fragmentation supports several modes of operation. These 324 modes have different advantages and disadvantages depending on the 325 specifics of the underlying LPWAN technology and application Use 326 Case. This section describes how the SCHC fragmentation 327 functionality should optimally be implemented when used over a Sigfox 328 LPWAN for the most typical Use Case applications. 330 As described in section 8.2.3 of [RFC8724], the integrity of the 331 fragmentation-reassembly process of a SCHC Packet MUST be checked at 332 the receive end. Since only UL messages/fragments that have passed 333 the CRC-check are delivered to the Network SCHC C/D + F/R, and each 334 one has an associated Sigfox Message Sequence Number (see 335 Section 4.2), integrity can be guaranteed when no consecutive 336 messages are missing from the sequence and all FCN bitmaps are 337 complete. In order to support multiple flows/RuleIDs (potentially 338 interleaved), the implementation of a central message sequence 339 counter at the Network SCHC C/D + F/R is required. With this 340 functionality and in order to save protocol overhead, the use of a 341 dedicated Reassembly Check Sequence (RCS) is NOT RECOMMENDED. 343 The L2 Word Size used by Sigfox is 1 byte (8 bits). 345 4.6.1. Uplink Fragmentation 347 Sigfox uplink transmissions are completely asynchronous and can take 348 place in any random frequency of the allowed uplink bandwidth 349 allocation. Hence, devices can go to deep sleep mode, and then wake 350 up and transmit whenever there is a need to send any information to 351 the network. In that way, there is no need to perform any network 352 attachment, synchronization, or other procedure before transmitting a 353 data packet. All data packets are self-contained (aka "message in a 354 bottle") with all the required information for the network to process 355 them accordingly. 357 Since uplink transmissions occur asynchronously, an SCHC fragment can 358 be transmitted at any given time by the Device. Sigfox uplink 359 messages are fixed in size, and as described in [RFC8376] they can 360 carry 0-12 bytes payload. Hence, a single SCHC Tile size per 361 fragmentation mode can be defined so that every Sigfox message always 362 carries one SCHC Tile. 364 4.6.1.1. Uplink No-ACK Mode 366 No-ACK is RECOMMENDED to be used for transmitting short, non-critical 367 packets that require fragmentation and do not require full 368 reliability. This mode can be used by uplink-only devices that do 369 not support downlink communications, or by bidirectional devices when 370 they send non-critical data. 372 Since there are no multiple windows in the No-ACK mode, the W bit is 373 not present. However it is RECOMMENDED to use the FCN field to 374 indicate the size of the data packet. In this sense, the data packet 375 would need to be splitted into X fragments and, similarly to the 376 other fragmentation modes, the first transmitted fragment would need 377 to be marked with FCN = X-1. Consecutive fragments MUST be marked 378 with decreasing FCN values, having the last fragment marked with FCN 379 = (All-1). Hence, even though the No-ACK mode does not allow 380 recovering missing fragments, it allows indicating implicitly the 381 size of the expected packet to the Network and hence detect at the 382 receiver side whether all fragments have been received or not. 384 The RECOMMENDED Fragmentation Header size is 8 bits, and it is 385 composed as follows: 387 o RuleID size: 4 bits 389 o DTag size (T): 0 bits 391 o Fragment Compressed Number (FCN) size (N): 4 bits 393 o As per [RFC8724], in the No-ACK mode the W (window) field is not 394 present. 396 o RCS size: 0 bits (Not used) 398 4.6.1.2. Uplink ACK-on-Error Mode: Single-byte SCHC Header 400 ACK-on-Error with single-byte header is RECOMMENDED for medium-large 401 size packets that need to be sent reliably. ACK-on-Error is optimal 402 for Sigfox transmissions, since it leads to a reduced number of ACKs 403 in the lower capacity downlink channel. Also, downlink messages can 404 be sent asynchronously and opportunistically. 406 Allowing transmission of packets/files up to 300 bytes long, the SCHC 407 uplink Fragmentation Header size is RECOMMENDED to be 8 bits in size 408 and is composed as follows: 410 o Rule ID size: 3 bits 412 o DTag size (T): 0 bits 414 o Window index (W) size (M): 2 bits 416 o Fragment Compressed Number (FCN) size (N): 3 bits 418 o MAX_ACK_REQUESTS: 5 420 o WINDOW_SIZE: 7 (with a maximum value of FCN=0b110) 421 o Tile size: 11 bytes 423 o Retransmission Timer: Application-dependent 425 o Inactivity Timer: Application-dependent 427 o RCS size: 0 bits (Not used) 429 The correspondent SCHC ACK in the downlink is 13 bits long, so 430 padding is needed to complete the required 64 bits of Sigfox payload. 432 4.6.1.3. Uplink ACK-on-Error Mode: Two-byte SCHC Header 434 ACK-on-Error with two-byte header is RECOMMENDED for very large size 435 packets that need to be sent reliably. ACK-on-Error is optimal for 436 Sigfox transmissions, since it leads to a reduced number of ACKs in 437 the lower capacity downlink channel. Also, downlink messages can be 438 sent asynchronously and opportunistically. 440 In order to allow transmission of very large packets/files up to 2250 441 bytes long, the SCHC uplink Fragmentation Header size is RECOMMENDED 442 to be 16 bits in size and composed as follows: 444 o Rule ID size is: 8 bits 446 o DTag size (T) is: 0 bits 448 o Window index (W) size (M): 3 bits 450 o Fragment Compressed Number (FCN) size (N): 5 bits. 452 o MAX_ACK_REQUESTS: 5 454 o WINDOW_SIZE: 31 (with a maximum value of FCN=0b11110) 456 o Tile size: 10 bytes 458 o Retransmission Timer: Application-dependent 460 o Inactivity Timer: Application-dependent 462 o RCS size: 0 bits (Not used) 464 The correspondent SCHC ACK in the downlink is 43 bits long, so 465 padding is needed to complete the required 64 bits of Sigfox payload. 467 4.6.1.4. All-1 behaviour + Sigfox Sequence Number 469 For ACK-on-Error, as defined in [RFC8724] it is expected that the 470 last SCHC fragment of the last window will always be delivered with 471 an All-1 FCN. Since this last window may not be full (i.e. it may be 472 comprised of less than WINDOW_SIZE fragments), an All-1 fragment may 473 follow a value of FCN higher than 1 (0b01). In this case, the 474 receiver could not derive from the FCN values alone whether there are 475 any missing fragments right before the All-1 fragment or not. 477 However, since a Message Sequence Number is provided by the Sigfox 478 protocol together with the Sigfox Payload, the receiver can detect if 479 there are missing fragments before the All-1 and hence construct the 480 corresponding SCHC ACK Bitmap accordingly. 482 4.6.2. Downlink Fragmentation 484 In some LPWAN technologies, as part of energy-saving techniques, 485 downlink transmission is only possible immediately after an uplink 486 transmission. This allows the device to go in a very deep sleep mode 487 and preserve battery, without the need to listen to any information 488 from the network. This is the case for Sigfox-enabled devices, which 489 can only listen to downlink communications after performing an uplink 490 transmission and requesting a downlink. 492 When there are fragments to be transmitted in the downlink, an uplink 493 message is required to trigger the downlink communication. In order 494 to avoid potentially high delay for fragmented datagram transmission 495 in the downlink, the fragment receiver MAY perform an uplink 496 transmission as soon as possible after reception of a downlink 497 fragment that is not the last one. Such uplink transmission MAY be 498 triggered by sending a SCHC message, such as a SCHC ACK. However, 499 other data messages can equally be used to trigger DL communications. 501 Sigfox downlink messages are fixed in size, and as described in 502 [RFC8376] they can carry up to 8 bytes payload. Hence, a single SCHC 503 Tile size per mode can be defined so that every Sigfox message always 504 carries one SCHC Tile. 506 For reliable downlink fragment transmission, the ACK-Always mode is 507 RECOMMENDED. 509 The SCHC downlink Fragmentation Header size is RECOMMENDED to be 8 510 bits in size and is composed as follows: 512 o RuleID size: 3 bits 514 o DTag size (T): 0 bits 515 o Window index (W) size (M) is: 0 bits 517 o Fragment Compressed Number (FCN) size (N): 5 bits 519 o MAX_ACK_REQUESTS: 5 521 o WINDOW_SIZE: 31 (with a maximum value of FCN=0b11110) 523 o Tile size: 7 bytes 525 o Retransmission Timer: Application-dependent 527 o Inactivity Timer: Application-dependent 529 o RCS size: 0 bits (Not used) 531 4.7. Padding 533 The Sigfox payload fields have different characteristics in uplink 534 and downlink. 536 Uplink frames can contain a payload size from 0 to 12 bytes. The 537 radio protocol allows sending zero bits, one single bit of 538 information for binary applications (e.g. status), or an integer 539 number of bytes. Therefore, for 2 or more bits of payload it is 540 required to add padding to the next integer number of bytes. The 541 reason for this flexibility is to optimize transmission time and 542 hence save battery consumption at the device. 544 Downlink frames on the other hand have a fixed length. The payload 545 length must be 64 bits (i.e. 8 bytes). Hence, if less information 546 bits are to be transmitted, padding would be necessary. 548 5. Fragmentation Sequence Examples 550 In this section, some sequence diagrams depicting messages exchanges 551 for different fragmentation modes and use cases are shown. In the 552 examples, 'Seq' indicates the Sigfox Sequence Number of the frame 553 carrying a fragment. 555 5.1. Uplink No-ACK Examples 557 The FCN field indicates the size of the data packet. The first 558 fragment is marked with FCN = X-1, where X is the number of fragments 559 the message is split into. All fragments are marked with decreasing 560 FCN values. Last packet fragment is marked with the FCN = All-1 561 (1111). 563 Case No losses - All fragments are sent and received successfully. 565 Sender Receiver 566 |-------FCN=6 (0110), Seq=1-------->| 567 |-------FCN=5 (0101), Seq=2-------->| 568 |-------FCN=4 (0100), Seq=3-------->| 569 |-------FCN=3 (0011), Seq=4-------->| 570 |-------FCN=2 (0010), Seq=5-------->| 571 |-------FCN=1 (0001), Seq=6-------->| 572 |-------FCN=15 (1111), Seq=7------->| All fragments received 573 (End) 575 Figure 3: UL No-ACK No-Losses 577 When the first SCHC fragment is received, the Receiver can calculate 578 the total number of SCHC fragments that the SCHC Packet is composed 579 of. For example, if the first fragment is numbered with FCN=6, the 580 receiver can expect more 6 messages (with FCN going from 5 downward, 581 and the last with a FCN equal to 15). 583 Case losses on any fragment except the first. 585 Sender Receiver 586 |-------FCN=6, Seq=1-------->| 587 |-------FCN=5, Seq=2----X--->| 588 |-------FCN=4, Seq=3-------->| 589 |-------FCN=3, Seq=4-------->| 590 |-------FCN=2, Seq=5-------->| 591 |-------FCN=1, Seq=6-------->| 592 |-------FCN=15, Seq=7------->| Missing Fragment - Unable to reassemble 593 (End) 595 Figure 4: UL No-ACK Losses (scenario 1) 597 5.2. Uplink ACK-on-Error Examples: Single-byte SCHC Header 599 The single-byte SCHC header ACK-on-Error mode allows sending up to 28 600 fragments and packet sizes up to 300 bytes. The SCHC fragments may 601 be delivered asynchronously and DL ACK can be sent opportunistically. 603 Case No losses 605 The downlink flag must be enabled in the sender UL message to allow a 606 DL message from the receiver. The DL Enable in the figures shows 607 where the sender should enable the downlink, and wait for an ACK. 609 Sender Receiver 610 |-----W=0, FCN=6, Seq=1----->| 611 |-----W=0, FCN=5, Seq=2----->| 612 |-----W=0, FCN=4, Seq=3----->| 613 |-----W=0, FCN=3, Seq=4----->| 614 |-----W=0, FCN=2, Seq=5----->| 615 |-----W=0, FCN=1, Seq=6----->| 616 DL Enable |-----W=0, FCN=0, Seq=7----->| 617 (no ACK) 618 |-----W=1, FCN=6, Seq=8----->| 619 |-----W=1, FCN=5, Seq=9----->| 620 |-----W=1, FCN=4, Seq=10---->| 621 DL Enable |-----W=1, FCN=7, Seq=11---->| All fragments received 622 |<------ ACK, W=1, C=1 ------| C=1 623 (End) 625 Figure 5: UL ACK-on-Error No-Losses 627 Case Fragments lost in first window 629 In this case, fragments are lost in the first window (W=0). After 630 the first All-0 message arrives, the Receiver leverages the 631 opportunity and sends an ACK with the corresponding bitmap and C=0. 633 After the missing fragments from the first window (W=0) are resent, 634 the sender without opening a reception window, continues transmitting 635 the following window. Finally, the All-1 fragment is sent, the 636 downlink is enabled and the ACK received with a C=1. 638 Sender Receiver 639 |-----W=0, FCN=6, Seq=1----->| 640 |-----W=0, FCN=5, Seq=2--X-->| 641 |-----W=0, FCN=4, Seq=3----->| 642 |-----W=0, FCN=3, Seq=4----->| 643 |-----W=0, FCN=2, Seq=5--X-->| 644 |-----W=0, FCN=1, Seq=6----->| 645 DL Enable |-----W=0, FCN=0, Seq=7----->| Missing Fragments W=0 => FCN=5, Seq=2 and FCN=2, Seq=5 646 |<------ ACK, W=0, C=0 ------| Bitmap:1011011 647 |-----W=0, FCN=5, Seq=8----->| 648 |-----W=0, FCN=2, Seq=9----->| 649 (no ACK) 650 |-----W=1, FCN=6, Seq=10---->| 651 |-----W=1, FCN=5, Seq=11---->| 652 |-----W=1, FCN=4, Seq=12---->| 653 DL Enable |-----W=1, FCN=7, Seq=13---->| All fragments received 654 |<------ ACK, W=1, C=1 ------| C=1 655 (End) 657 Figure 6: UL ACK-on-Error Losses on First Window 659 Case Fragments All-0 lost in first window (W=0) 661 In this example, the All-0 of the first window (W=0) is lost. 662 Therefore, the Receiver waits for the next All-X message to generate 663 the corresponding ACK, notifying the absence of the All-0 of window 664 0. 666 The sender resends the missing All-0 messages (with any other missing 667 fragment from window 0). Note that this behaviour can take place in 668 any intermediate window if the All-0 message is lost. 670 Sender Receiver 671 |-----W=0, FCN=6, Seq=1----->| 672 |-----W=0, FCN=5, Seq=2----->| 673 |-----W=0, FCN=4, Seq=3----->| 674 |-----W=0, FCN=3, Seq=4----->| 675 |-----W=0, FCN=2, Seq=5----->| 676 |-----W=0, FCN=1, Seq=6----->| 677 DL Enable |-----W=0, FCN=0, Seq=7--X-->| 678 (no ACK) 679 |-----W=1, FCN=6, Seq=8----->| 680 |-----W=1, FCN=5, Seq=9----->| 681 |-----W=1, FCN=4, Seq=10---->| 682 DL Enable |-----W=1, FCN=7, Seq=11---->| Missing Fragment W=0, FCN=0, Seq=7 683 |<------ ACK, W=0, C=0 ------| Bitmap:1111110 684 DL Enable |-----W=0, FCN=0, Seq=12---->| All fragments received 685 |<------ ACK, W=1, C=1 ------| C=1 686 (End) 688 Figure 7: UL ACK-on-Error All-0 Lost on First Window 690 In the following diagram, besides the All-0 there are other lost 691 fragments in the first window (W=0). 693 Sender Receiver 694 |-----W=0, FCN=6, Seq=1----->| 695 |-----W=0, FCN=5, Seq=2--X-->| 696 |-----W=0, FCN=4, Seq=3----->| 697 |-----W=0, FCN=3, Seq=4--X-->| 698 |-----W=0, FCN=2, Seq=5----->| 699 |-----W=0, FCN=1, Seq=6----->| 700 DL Enable |-----W=0, FCN=0, Seq=7--X-->| 701 (no ACK) 702 |-----W=1, FCN=6, Seq=8----->| 703 |-----W=1, FCN=5, Seq=9----->| 704 |-----W=1, FCN=4, Seq=10---->| 705 DL Enable |-----W=1, FCN=7, Seq=11---->| Missing Fragment W=0 => FCN= 5, 3 and 0 706 |<------ ACK, W=0, C=0 ------| Bitmap:1010110 707 |-----W=0, FCN=5, Seq=12---->| 708 |-----W=0, FCN=3, Seq=13---->| 709 DL Enable |-----W=0, FCN=0, Seq=14---->| All fragments received 710 |<------ ACK, W=1, C=1 ------| C=1 711 (End) 713 Figure 8: UL ACK-on-Error All-0 and other Fragments Lost on First 714 Window 716 In the following case, there are losses in both the first (W=0) and 717 second (W=1) window. The retransmission cycles (after the All-1 is 718 sent, not in intermediate windows) should always finish with an All-0 719 (if this message was lost) or with an All-1. This is required for 720 the sender to open a reception window so the receiver can send an 721 ACK. Else, there is no way for the Receiver to send an ACK, if All-1 722 message is lost, then an ACK timeout happen and an ACK is resent. 724 Sender Receiver 725 |-----W=0, FCN=6 (110), Seq=1----->| 726 |-----W=0, FCN=5 (101), Seq=2--X-->| 727 |-----W=0, FCN=4 (100), Seq=3----->| 728 |-----W=0, FCN=3 (011), Seq=4--X-->| 729 |-----W=0, FCN=2 (010), Seq=5----->| 730 |-----W=0, FCN=1 (001), Seq=6----->| 731 DL enable |-----W=0, FCN=0 (000), Seq=7--X-->| 732 (no ACK) 733 |-----W=1, FCN=6 (110), Seq=8--X-->| 734 |-----W=1, FCN=5 (101), Seq=9----->| 735 |-----W=1, FCN=4 (011), Seq=10-X-->| 736 DL enable |-----W=1, FCN=7 (111), Seq=11---->| Missing Fragment W=0 => FCN= 5, 3 and 0 737 |<--------- ACK, W=0, C=0 ---------| Bitmap:1010110 738 |-----W=0, FCN=5 (101), Seq=12---->| 739 |-----W=0, FCN=3 (011), Seq=13---->| 740 DL enable |-----W=0, FCN=0 (000), Seq=14---->| Missing Fragment W=1 => FCN= 6 and 4 741 |<--------- ACK, W=1, C=0 ---------| Bitmap:0100001 742 |-----W=1, FCN=6 (110), Seq=15---->| 743 |-----W=1, FCN=4 (011), Seq=16---->| All fragments received 744 DL enable |-----W=1, FCN=7 (111), Seq=17---->| 745 |<--------- ACK, W=1, C=1 ---------| C=1 746 (End) 748 Figure 9: UL ACK-on-Error All-0 and other Fragments Lost on First and 749 Second Windows (1) 751 Similar case as above, but with less fragments in the second window 752 (W=1) 753 Sender Receiver 754 |-----W=0, FCN=6 (110), Seq=1----->| 755 |-----W=0, FCN=5 (101), Seq=2--X-->| 756 |-----W=0, FCN=4 (100), Seq=3----->| 757 |-----W=0, FCN=3 (011), Seq=4--X-->| 758 |-----W=0, FCN=2 (010), Seq=5----->| 759 |-----W=0, FCN=1 (001), Seq=6----->| 760 DL enable |-----W=0, FCN=0 (000), Seq=7--X-->| 761 (no ACK) 762 |-----W=1, FCN=6 (110), Seq=8--X-->| 763 DL enable |-----W=1, FCN=7 (111), Seq=9----->| Missing Fragment W=0 => FCN= 5, 3 and 0 764 |<--------- ACK, W=0, C=0 ---------| Bitmap:1010110 765 |-----W=0, FCN=5 (101), Seq=10---->| 766 |-----W=0, FCN=3 (011), Seq=11---->| 767 DL enable |-----W=0, FCN=0 (000), Seq=12---->| Missing Fragment W=1 => FCN= 6 and 4 768 |<--------- ACK, W=1, C=0 ---------| Bitmap:0000001 769 |-----W=1, FCN=6 (110), Seq=15---->| All fragments received 770 DL enable |-----W=1, FCN=7 (111), Seq=17---->| 771 |<--------- ACK, W=1, C=1 ---------| C=1 772 (End) 774 Figure 10: UL ACK-on-Error All-0 and other Fragments Lost on First 775 and Second Windows (2) 777 Case ACK is lost 779 SCHC over Sigfox does not implement the SCHC ACK REQ message. 780 Instead it uses the SCHC All-1 message to request an ACK, when 781 required. 783 Sender Receiver 784 |-----W=0, FCN=6, Seq=1----->| 785 |-----W=0, FCN=5, Seq=2----->| 786 |-----W=0, FCN=4, Seq=3----->| 787 |-----W=0, FCN=3, Seq=4----->| 788 |-----W=0, FCN=2, Seq=5----->| 789 |-----W=0, FCN=1, Seq=6----->| 790 DL Enable |-----W=0, FCN=0, Seq=7----->| 791 (no ACK) 792 |-----W=1, FCN=6, Seq=8----->| 793 |-----W=1, FCN=5, Seq=9----->| 794 |-----W=1, FCN=4, Seq=10---->| 795 DL Enable |-----W=1, FCN=7, Seq=11---->| All fragments received 796 |<------ ACK, W=1, C=1 ---X--| C=1 797 DL Enable |-----W=1, FCN=7, Seq=13---->| RESEND ACK 798 |<------ ACK, W=1, C=1 ------| C=1 799 (End) 801 Figure 11: UL ACK-on-Error ACK Lost 803 The number of times an ACK will be requested is determined by the 804 MAX_ACK_REQUESTS. 806 5.3. SCHC Abort Examples 808 Case SCHC Sender-Abort 810 The sender may need to send a Sender-Abort to stop the current 811 communication. This may happen, for example, if the All-1 has been 812 sent MAX_ACK_REQUESTS times. 814 Sender Receiver 815 |-----W=0, FCN=6, Seq=1----->| 816 |-----W=0, FCN=5, Seq=2----->| 817 |-----W=0, FCN=4, Seq=3----->| 818 |-----W=0, FCN=3, Seq=4----->| 819 |-----W=0, FCN=2, Seq=5----->| 820 |-----W=0, FCN=1, Seq=6----->| 821 DL Enable |-----W=0, FCN=0, Seq=7----->| 822 (no ACK) 823 |-----W=1, FCN=6, Seq=8----->| 824 |-----W=1, FCN=5, Seq=9----->| 825 |-----W=1, FCN=4, Seq=10---->| 826 DL Enable |-----W=1, FCN=7, Seq=11---->| All fragments received 827 |<------ ACK, W=1, C=1 ---X--| C=1 828 DL Enable |-----W=1, FCN=7, Seq=14---->| RESEND ACK (1) 829 |<------ ACK, W=1, C=1 ---X--| C=1 830 DL Enable |-----W=1, FCN=7, Seq=15---->| RESEND ACK (2) 831 |<------ ACK, W=1, C=1 ---X--| C=1 832 DL Enable |-----W=1, FCN=7, Seq=16---->| RESEND ACK (3) 833 |<------ ACK, W=1, C=1 ---X--| C=1 834 DL Enable |-----W=1, FCN=7, Seq=17---->| RESEND ACK (4) 835 |<------ ACK, W=1, C=1 ---X--| C=1 836 DL Enable |-----W=1, FCN=7, Seq=18---->| RESEND ACK (5) 837 |<------ ACK, W=1, C=1 ---X--| C=1 838 DL Enable |----Sender-Abort, Seq=19--->| exit with error condition 839 (End) 841 Figure 12: UL ACK-on-Error Sender-Abort 843 Case Receiver-Abort 845 The reciever may need to send a Receiver-Abort to stop the current 846 communication. This message can only be sent after a DL enable. 848 Sender Receiver 849 |-----W=0, FCN=6, Seq=1----->| 850 |-----W=0, FCN=5, Seq=2----->| 851 |-----W=0, FCN=4, Seq=3----->| 852 |-----W=0, FCN=3, Seq=4----->| 853 |-----W=0, FCN=2, Seq=5----->| 854 |-----W=0, FCN=1, Seq=6----->| 855 DL Enable |-----W=0, FCN=0, Seq=7----->| 856 |<------- RECV ABORT -------| under-resourced 857 (Error) 859 Figure 13: UL ACK-on-Error Receiver-Abort 861 6. Security considerations 863 The radio protocol authenticates and ensures the integrity of each 864 message. This is achieved by using a unique device ID and an AES-128 865 based message authentication code, ensuring that the message has been 866 generated and sent by the device with the ID claimed in the message. 868 Application data can be encrypted at the application level or not, 869 depending on the criticality of the use case. This flexibility 870 allows providing a balance between cost and effort vs. risk. AES-128 871 in counter mode is used for encryption. Cryptographic keys are 872 independent for each device. These keys are associated with the 873 device ID and separate integrity and confidentiality keys are pre- 874 provisioned. A confidentiality key is only provisioned if 875 confidentiality is to be used. 877 The radio protocol has protections against reply attacks, and the 878 cloud-based core network provides firewalling protection against 879 undesired incoming communications. 881 7. Acknowledgements 883 Carles Gomez has been funded in part by the Spanish Government 884 through the Jose Castillejo CAS15/00336 grant, the TEC2016-79988-P 885 grant, and the PID2019-106808RA-I00 grant, and by Secretaria 886 d'Universitats i Recerca del Departament d'Empresa i Coneixement de 887 la Generalitat de Catalunya 2017 through grant SGR 376. 889 Sergio Aguilar has been funded by the ERDF and the Spanish Government 890 through project TEC2016-79988-P and project PID2019-106808RA-I00, 891 AEI/FEDER, EU. 893 The authors would like to thank Clement Mannequin, Rafael Vidal and 894 Antonis Platis for their useful comments and implementation design 895 considerations. 897 8. References 899 8.1. Normative References 901 [RFC8376] Farrell, S., Ed., "Low-Power Wide Area Network (LPWAN) 902 Overview", RFC 8376, DOI 10.17487/RFC8376, May 2018, 903 . 905 [RFC8724] Minaburo, A., Toutain, L., Gomez, C., Barthel, D., and JC. 906 Zuniga, "SCHC: Generic Framework for Static Context Header 907 Compression and Fragmentation", RFC 8724, 908 DOI 10.17487/RFC8724, April 2020, 909 . 911 8.2. Informative References 913 [sigfox-callbacks] 914 Sigfox, "Sigfox Callbacks", 915 . 917 [sigfox-spec] 918 Sigfox, "Sigfox Radio Specifications", 919 . 922 Authors' Addresses 924 Juan Carlos Zuniga 925 SIGFOX 926 Montreal QC 927 Canada 929 Email: JuanCarlos.Zuniga@sigfox.com 930 URI: http://www.sigfox.com/ 932 Carles Gomez 933 Universitat Politecnica de Catalunya 934 C/Esteve Terradas, 7 935 08860 Castelldefels 936 Spain 938 Email: carlesgo@entel.upc.edu 940 Sergio Aguilar 941 Universitat Politecnica de Catalunya 942 C/Esteve Terradas, 7 943 08860 Castelldefels 944 Spain 946 Email: sergio.aguilar.romero@upc.edu 947 Laurent Toutain 948 IMT-Atlantique 949 2 rue de la Chataigneraie 950 CS 17607 951 35576 Cesson-Sevigne Cedex 952 France 954 Email: Laurent.Toutain@imt-atlantique.fr 956 Sandra Cespedes 957 NIC Labs, Universidad de Chile 958 Av. Almte. Blanco Encalada 1975 959 Santiago 960 Chile 962 Email: scespedes@niclabs.cl 964 Diego Wistuba 965 NIC Labs, Universidad de Chile 966 Av. Almte. Blanco Encalada 1975 967 Santiago 968 Chile 970 Email: wistuba@niclabs.cl