idnits 2.17.1 draft-ietf-lpwan-schc-over-sigfox-06.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 291: '...ntation mode, a DL opportunity MUST be...' RFC 2119 keyword, line 302: '...m All-0 or All-1 MUST NOT use the DL r...' RFC 2119 keyword, line 307: '... The RuleID MUST be included in the ...' RFC 2119 keyword, line 334: '...ss of a SCHC Packet MUST be checked at...' RFC 2119 keyword, line 344: '...eck Sequence (RCS) is NOT RECOMMENDED....' (37 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (June 11, 2021) is 1050 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Downref: Normative reference to an Informational RFC: RFC 8376 Summary: 4 errors (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 lpwan Working Group JC. Zuniga 3 Internet-Draft SIGFOX 4 Intended status: Standards Track C. Gomez 5 Expires: December 13, 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 June 11, 2021 14 SCHC over Sigfox LPWAN 15 draft-ietf-lpwan-schc-over-sigfox-06 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 December 13, 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 . . . . . . . . . . . . . . . . . . . . . . . . 3 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 . . . . . . . . . . . . . . . . . . 4 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 . . . . . . . . . . . . . . . . . . . . . . 8 75 4.6.1. SCHC Compound ACK . . . . . . . . . . . . . . . . . . 8 76 4.6.2. Uplink Fragmentation . . . . . . . . . . . . . . . . 9 77 4.6.3. Downlink Fragmentation . . . . . . . . . . . . . . . 12 78 4.7. SCHC-over-Sigfox F/R Message Formats . . . . . . . . . . 13 79 4.7.1. Uplink ACK-on-Error Mode: Single-byte SCHC Header . . 13 80 4.7.2. Uplink ACK-on-Error Mode: Two-byte SCHC Header . . . 17 81 4.8. Padding . . . . . . . . . . . . . . . . . . . . . . . . . 19 82 5. Fragmentation Sequence Examples . . . . . . . . . . . . . . . 20 83 5.1. Uplink No-ACK Examples . . . . . . . . . . . . . . . . . 20 84 5.2. Uplink ACK-on-Error Examples: Single-byte SCHC Header . . 21 85 5.3. SCHC Abort Examples . . . . . . . . . . . . . . . . . . . 28 86 6. Security considerations . . . . . . . . . . . . . . . . . . . 30 87 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 30 88 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 31 89 8.1. Normative References . . . . . . . . . . . . . . . . . . 31 90 8.2. Informative References . . . . . . . . . . . . . . . . . 31 91 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 31 93 1. Introduction 95 The Generic Framework for Static Context Header Compression and 96 Fragmentation (SCHC) specification [RFC8724] describes two 97 mechanisms: i) an application header compression scheme, and ii) a 98 frame fragmentation and loss recovery functionality. Either can be 99 used on top of all the four LWPAN technologies defined in [RFC8376]. 100 These LPWANs have similar characteristics such as star-oriented 101 topologies, network architecture, connected devices with built-in 102 applications, etc. 104 SCHC offers a great level of flexibility to accommodate all these 105 LPWAN technologies. Even though there are a great number of 106 similarities between them, some differences exist with respect to the 107 transmission characteristics, payload sizes, etc. Hence, there are 108 optimal parameters and modes of operation that can be used when SCHC 109 is used on top of a specific LPWAN technology. 111 This document describes the recommended parameters, settings, and 112 modes of operation to be used when SCHC is implemented over a Sigfox 113 LPWAN. This set of parameters are also known as a "SCHC over Sigfox 114 profile." 116 2. Terminology 118 It is assumed that the reader is familiar with the terms and 119 mechanisms defined in [RFC8376] and in [RFC8724]. 121 3. SCHC: Generic Framework for Static Context Header Compression and 122 Fragmentation 124 The Generic Framework for Static Context Header Compression and 125 Fragmentation (SCHC) described in [RFC8724] takes advantage of the 126 predictability of data flows existing in LPWAN applications to avoid 127 context synchronization. 129 Contexts must be stored and pre-configured on both ends. This can be 130 done either by using a provisioning protocol, by out of band means, 131 or by pre-provisioning them (e.g. at manufacturing time). The way 132 contexts are configured and stored on both ends is out of the scope 133 of this document. 135 4. SCHC over Sigfox 136 4.1. Network Architecture 138 Figure 1 represents the architecture for compression/decompression 139 (C/D) and fragmentation/reassembly (F/R) based on the terminology 140 defined in [RFC8376], where the Radio Gateway (RG) is a Sigfox Base 141 Station and the Network Gateway (NGW) is the Sigfox cloud-based 142 Network. 144 Sigfox Device Application 145 +----------------+ +--------------+ 146 | APP1 APP2 APP3 | |APP1 APP2 APP3| 147 +----------------+ +--------------+ 148 | UDP | | | | UDP | 149 | IPv6 | | | | IPv6 | 150 +--------+ | | +--------+ 151 | SCHC C/D & F/R | | | 152 | | | | 153 +-------+--------+ +--------+-----+ 154 $ . 155 $ +---------+ +--------------+ +---------+ . 156 $ | | | | | Network | . 157 +~~ |Sigfox BS| |Sigfox Network| | SCHC | . 158 | (RG) | === | (NGW) | === |C/D & F/R|..... 159 +---------+ +--------------+ +---------+ 161 Figure 1: Network Architecture 163 In the case of the global Sigfox Network, RGs (or Base Stations) are 164 distributed over multiple countries wherever the Sigfox LPWAN service 165 is provided. The NGW (or cloud-based Sigfox Core Network) is a 166 single entity that connects to all Sigfox base stations in the world, 167 providing hence a global single star network topology. 169 The Device sends application flows that are compressed and/or 170 fragmented by a SCHC Compressor/Decompressor (SCHC C/D + F/R) to 171 reduce headers size and/or fragment the packet. The resulting SCHC 172 Message is sent over a layer two (L2) Sigfox frame to the Sigfox Base 173 Stations, which then forward the SCHC Message to the Network Gateway 174 (NGW). The NGW then delivers the SCHC Message and associated 175 gathered metadata to the Network SCHC C/D + F/R. 177 The Sigfox Network (NGW) communicates with the Network SCHC C/D + F/R 178 for compression/decompression and/or for fragmentation/reassembly. 179 The Network SCHC C/D + F/R shares the same set of rules as the Dev 180 SCHC C/D + F/R. The Network SCHC C/D + F/R can be collocated with 181 the NGW or it could be located in a different place, as long as a 182 tunnel or secured communication is established between the NGW and 183 the SCHC C/D + F/R functions. After decompression and/or reassembly, 184 the packet can be forwarded over the Internet to one (or several) 185 LPWAN Application Server(s) (App). 187 The SCHC C/D + F/R processes are bidirectional, so the same 188 principles are applicable on both uplink (UL) and downlink (DL). 190 4.2. Uplink 192 Uplink Sigfox transmissions occur in repetitions over different times 193 and frequencies. Besides time and frequency diversities, the Sigfox 194 network also provides space diversity, as potentially an uplink 195 message will be received by several base stations. 197 Since all messages are self-contained and base stations forward all 198 these messages back to the same Sigfox Network, multiple input copies 199 can be combined at the NGW providing for extra reliability based on 200 the triple diversity (i.e., time, space and frequency). 202 A detailed description of the Sigfox Radio Protocol can be found in 203 [sigfox-spec]. 205 Messages sent from the Device to the Network are delivered by the 206 Sigfox network (NGW) to the Network SCHC C/D + F/R through a 207 callback/API with the following information: 209 o Device ID 211 o Message Sequence Number 213 o Message Payload 215 o Message Timestamp 217 o Device Geolocation (optional) 219 o RSSI (optional) 221 o Device Temperature (optional) 223 o Device Battery Voltage (optional) 225 The Device ID is a globally unique identifier assigned to the Device, 226 which is included in the Sigfox header of every message. The Message 227 Sequence Number is a monotonically increasing number identifying the 228 specific transmission of this uplink message, and it is also part of 229 the Sigfox header. The Message Payload corresponds to the payload 230 that the Device has sent in the uplink transmission. 232 The Message Timestamp, Device Geolocation, RSSI, Device Temperature 233 and Device Battery Voltage are metadata parameters provided by the 234 Network. 236 A detailed description of the Sigfox callbacks/APIs can be found in 237 [sigfox-callbacks]. 239 Only messages that have passed the L2 Cyclic Redundancy Check (CRC) 240 at network reception are delivered by the Sigfox Network to the 241 Network SCHC C/D + F/R. 243 +---------------+-----------------+ 244 | Sigfox Header | Sigfox payload | 245 +---------------+---------------- + 246 | SCHC message | 247 +-----------------+ 249 Figure 2: SCHC Message in Sigfox 251 Figure 2 shows a SCHC Message sent over Sigfox, where the SCHC 252 Message could be a full SCHC Packet (e.g. compressed) or a SCHC 253 Fragment (e.g. a piece of a bigger SCHC Packet). 255 4.3. Downlink 257 Downlink transmissions are Device-driven and can only take place 258 following an uplink communication that so indicates. Hence, a Device 259 explicitly indicates its intention to receive a downlink message 260 using a donwlink request flag when sending the preceding uplink 261 message to the network. After completing the uplink transmission, 262 the Device opens a fixed window for downlink reception. The delay 263 and duration of the reception opportunity window have fixed values. 264 If there is a downlink message to be sent for this given Device (e.g. 265 either a response to the uplink message or queued information waiting 266 to be transmitted), the network transmits this message to the Device 267 during the reception window. If no message is received by the Device 268 after the reception opportunity window has elapsed, the Device closes 269 the reception window opportunity and gets back to the normal mode 270 (e.g., continue UL transmissions, sleep, stand-by, etc.) 272 When a downlink message is sent to a Device, a reception 273 acknowledgement is generated by the Device and sent back to the 274 Network through the Sigfox radio protocol and reported in the Sigfox 275 Network backend. 277 A detailed description of the Sigfox Radio Protocol can be found in 278 [sigfox-spec] and a detailed description of the Sigfox callbacks/APIs 279 can be found in [sigfox-callbacks]. 281 4.4. SCHC-ACK on Downlink 283 As explained previously, downlink transmissions are Device-driven and 284 can only take place following a specific uplink transmission that 285 indicates and allows a following downlink opportunity. For this 286 reason, when SCHC bi-directional services are used (e.g. Ack-on- 287 Error fragmentation mode) the SCHC protocol implementation needs to 288 consider the times when a downlink message (e.g. SCHC-ACK) can be 289 sent and/or received. 291 For the UL ACK-on-Error fragmentation mode, a DL opportunity MUST be 292 indicated by the last fragment of every window (i.e. FCN = All-0, or 293 FCN = All-1). The Device sends the fragments in sequence and, after 294 transmitting the FCN = All-0 or FCN = All-1, it opens up a reception 295 opportunity. The Network SCHC can then decide to respond at that 296 opportunity (or wait for a further one) with a SCHC-ACK indicating in 297 case there are missing fragments from the current or previous 298 windows. If there is no SCHC-ACK to be sent, or if the network 299 decides to wait for a further DL transmission opportunity, then no DL 300 transmission takes place at that opportunity and after a timeout the 301 UL transmissions continue. Intermediate SCHC fragments with FCN 302 different from All-0 or All-1 MUST NOT use the DL request flag to 303 request a SCHC-ACK. 305 4.5. SCHC Rules 307 The RuleID MUST be included in the SCHC header. The total number of 308 rules to be used affects directly the Rule ID field size, and 309 therefore the total size of the fragmentation header. For this 310 reason, it is recommended to keep the number of rules that are 311 defined for a specific device to the minimum possible. 313 RuleIDs can be used to differentiate data traffic classes (e.g. QoS, 314 control vs. data, etc.), and data sessions. They can also be used to 315 interleave simultaneous fragmentation sessions between a Device and 316 the Network. 318 4.6. Fragmentation 320 The SCHC specification [RFC8724] defines a generic fragmentation 321 functionality that allows sending data packets or files larger than 322 the maximum size of a Sigfox payload. The functionality also defines 323 a mechanism to send reliably multiple messages, by allowing to resend 324 selectively any lost fragments. 326 The SCHC fragmentation supports several modes of operation. These 327 modes have different advantages and disadvantages depending on the 328 specifics of the underlying LPWAN technology and application Use 329 Case. This section describes how the SCHC fragmentation 330 functionality should optimally be implemented when used over a Sigfox 331 LPWAN for the most typical Use Case applications. 333 As described in section 8.2.3 of [RFC8724], the integrity of the 334 fragmentation-reassembly process of a SCHC Packet MUST be checked at 335 the receive end. Since only UL messages/fragments that have passed 336 the CRC-check are delivered to the Network SCHC C/D + F/R, and each 337 one has an associated Sigfox Message Sequence Number (see 338 Section 4.2), integrity can be guaranteed when no consecutive 339 messages are missing from the sequence and all FCN bitmaps are 340 complete. In order to support multiple flows/RuleIDs (potentially 341 interleaved), the implementation of a central message sequence 342 counter at the Network SCHC C/D + F/R is required. With this 343 functionality and in order to save protocol overhead, the use of a 344 dedicated Reassembly Check Sequence (RCS) is NOT RECOMMENDED. 346 The L2 Word Size used by Sigfox is 1 byte (8 bits). 348 4.6.1. SCHC Compound ACK 350 The present SCHC over Sigfox specification extends SCHC ACK format 351 defined in [RFC8724] with the SCHC Compound ACK concept. 353 The SCHC Compound ACK is a SCHC ACK message that can contain several 354 bitmaps, each bitmap being identified by its corresponding window 355 number. The SCHC Compound ACK concept is meant to reduce the number 356 of downlink transmissions (i.e., SCHC ACKs) by including bitmaps of 357 several windows in a single SCHC message (i.e., the SCHC Compound 358 ACK), and hence making an efficient use of downlink channel 359 transmissions. 361 When the ACK-on-Error mode is used for uplink fragmentation, SCHC 362 Compound ACKs MUST be used in the downlink responses. 364 The SCHC Compound ACK: 366 o provides feedback only for windows with fragment losses, 368 o has a variable size that depends on the number of windows with 369 fragment losses being reported in the single Compound SCHC ACK, 371 o includes the window number (i.e., W) for each bitmap, 373 o has a format coincident with that of a SCHC ACK (RFC 8724) when 374 only one window with losses is reported, 376 o might not cover all windows with fragment losses of a SCHC Packet, 378 o is distinguishable from the SCHC Receiver-Abort. 380 The SCHC Compound ACK groups the window number (W) with its 381 corresponding bitmap. The included window numbers and corresponding 382 bitmap MUST be ordered from the lowest-numbered to the highest- 383 numbered window. 385 4.6.2. Uplink Fragmentation 387 Sigfox uplink transmissions are completely asynchronous and take 388 place in any random frequency of the allowed uplink bandwidth 389 allocation. In addition, devices may go to deep sleep mode, and then 390 wake up and transmit whenever there is a need to send information to 391 the network. Data packets are self-contained (aka "message in a 392 bottle") with all the required information for the network to process 393 them accordingly. Hence, there is no need to perform any network 394 attachment, synchronization, or other procedure before transmitting a 395 data packet. 397 Since uplink transmissions are asynchronous, a SCHC fragment can be 398 transmitted at any given time by the Device. Sigfox uplink messages 399 are fixed in size, and as described in [RFC8376] they can carry 0-12 400 bytes payload. Hence, a single SCHC Tile size per fragmentation mode 401 can be defined so that every Sigfox message always carries one SCHC 402 Tile. 404 4.6.2.1. Uplink No-ACK Mode 406 No-ACK is RECOMMENDED to be used for transmitting short, non-critical 407 packets that require fragmentation and do not require full 408 reliability. This mode can be used by uplink-only devices that do 409 not support downlink communications, or by bidirectional devices when 410 they send non-critical data. 412 Since there are no multiple windows in the No-ACK mode, the W bit is 413 not present. However it is RECOMMENDED to use the FCN field to 414 indicate the size of the data packet. In this sense, the data packet 415 would need to be splitted into X fragments and, similarly to the 416 other fragmentation modes, the first transmitted fragment would need 417 to be marked with FCN = X-1. Consecutive fragments MUST be marked 418 with decreasing FCN values, having the last fragment marked with FCN 419 = (All-1). Hence, even though the No-ACK mode does not allow 420 recovering missing fragments, it allows indicating implicitly the 421 size of the expected packet to the Network and hence detect at the 422 receiver side whether all fragments have been received or not. 424 The RECOMMENDED Fragmentation Header size is 8 bits, and it is 425 composed as follows: 427 o RuleID size: 4 bits 429 o DTag size (T): 0 bits 431 o Fragment Compressed Number (FCN) size (N): 4 bits 433 o As per [RFC8724], in the No-ACK mode the W (window) field is not 434 present. 436 o RCS size: 0 bits (Not used) 438 4.6.2.2. Uplink ACK-on-Error Mode: Single-byte SCHC Header 440 ACK-on-Error with single-byte header is RECOMMENDED for medium to 441 large size packets that need to be sent reliably. ACK-on-Error is 442 optimal for Sigfox transmissions, since it leads to a reduced number 443 of ACKs in the lower capacity downlink channel. Also, downlink 444 messages can be sent asynchronously and opportunistically. 446 Allowing transmission of packets/files up to 300 bytes long, the SCHC 447 uplink Fragmentation Header size is RECOMMENDED to be 8 bits in size 448 and is composed as follows: 450 o Rule ID size: 3 bits 452 o DTag size (T): 0 bits 454 o Window index (W) size (M): 2 bits 456 o Fragment Compressed Number (FCN) size (N): 3 bits 458 o MAX_ACK_REQUESTS: 5 460 o WINDOW_SIZE: 7 (with a maximum value of FCN=0b110) 461 o Tile size: 11 bytes 463 o Retransmission Timer: Application-dependent 465 o Inactivity Timer: Application-dependent 467 o RCS size: 0 bits (Not used) 469 The correspondent SCHC ACK in the downlink is 13 bits long, so 470 padding is needed to complete the required 64 bits of Sigfox payload. 472 4.6.2.3. Uplink ACK-on-Error Mode: Two-byte SCHC Header 474 ACK-on-Error with two-byte header is RECOMMENDED for very large size 475 packets that need to be sent reliably. ACK-on-Error is optimal for 476 Sigfox transmissions, since it leads to a reduced number of ACKs in 477 the lower capacity downlink channel. Also, downlink messages can be 478 sent asynchronously and opportunistically. 480 In order to allow transmission of very large packets/files up to 2250 481 bytes long, the SCHC uplink Fragmentation Header size is RECOMMENDED 482 to be 16 bits in size and composed as follows: 484 o Rule ID size is: 8 bits 486 o DTag size (T) is: 0 bits 488 o Window index (W) size (M): 3 bits 490 o Fragment Compressed Number (FCN) size (N): 5 bits. 492 o MAX_ACK_REQUESTS: 5 494 o WINDOW_SIZE: 31 (with a maximum value of FCN=0b11110) 496 o Tile size: 10 bytes 498 o Retransmission Timer: Application-dependent 500 o Inactivity Timer: Application-dependent 502 o RCS size: 0 bits (Not used) 504 The correspondent SCHC ACK in the downlink is 43 bits long, so 505 padding is needed to complete the required 64 bits of Sigfox payload. 507 4.6.2.4. All-1 behaviour + Sigfox Sequence Number 509 For ACK-on-Error, as defined in [RFC8724], it is expected that the 510 last SCHC fragment of the last window will always be delivered with 511 an All-1 FCN. Since this last window may not be full (i.e. it may be 512 comprised of less than WINDOW_SIZE fragments), an All-1 fragment may 513 follow a value of FCN higher than 1 (0b01). In this case, the 514 receiver could not derive from the FCN values alone whether there are 515 any missing fragments right before the All-1 fragment or not. 517 However, since a Message Sequence Number is provided by the Sigfox 518 protocol together with the Sigfox Payload, the receiver can detect if 519 there are missing fragments before the All-1 and hence construct the 520 corresponding SCHC ACK Bitmap accordingly. 522 4.6.3. Downlink Fragmentation 524 In some LPWAN technologies, as part of energy-saving techniques, 525 downlink transmission is only possible immediately after an uplink 526 transmission. This allows the device to go in a very deep sleep mode 527 and preserve battery, without the need to listen to any information 528 from the network. This is the case for Sigfox-enabled devices, which 529 can only listen to downlink communications after performing an uplink 530 transmission and requesting a downlink. 532 When there are fragments to be transmitted in the downlink, an uplink 533 message is required to trigger the downlink communication. In order 534 to avoid potentially high delay for fragmented datagram transmission 535 in the downlink, the fragment receiver MAY perform an uplink 536 transmission as soon as possible after reception of a downlink 537 fragment that is not the last one. Such uplink transmission MAY be 538 triggered by sending a SCHC message, such as a SCHC ACK. However, 539 other data messages can equally be used to trigger DL communications. 541 Sigfox downlink messages are fixed in size, and as described in 542 [RFC8376] they can carry up to 8 bytes payload. Hence, a single SCHC 543 Tile size per mode can be defined so that every Sigfox message always 544 carries one SCHC Tile. 546 For reliable downlink fragment transmission, the ACK-Always mode is 547 RECOMMENDED. 549 The SCHC downlink Fragmentation Header size is RECOMMENDED to be 8 550 bits in size and is composed as follows: 552 o RuleID size: 3 bits 554 o DTag size (T): 0 bits 555 o Window index (W) size (M) is: 0 bits 557 o Fragment Compressed Number (FCN) size (N): 5 bits 559 o MAX_ACK_REQUESTS: 5 561 o WINDOW_SIZE: 31 (with a maximum value of FCN=0b11110) 563 o Tile size: 7 bytes 565 o Retransmission Timer: Application-dependent 567 o Inactivity Timer: Application-dependent 569 o RCS size: 0 bits (Not used) 571 4.7. SCHC-over-Sigfox F/R Message Formats 573 This section depicts the different formats of SCHC Fragment, SCHC ACK 574 (including the SCHC Compound ACK defined in Section 4.6.1), and SCHC 575 Abort used in SCHC over Sigfox. 577 4.7.1. Uplink ACK-on-Error Mode: Single-byte SCHC Header 579 4.7.1.1. Regular SCHC Fragment 581 Figure 3 shows an example of a regular SCHC fragment for all 582 fragments except the last one. As tiles are of 11 bytes, padding 583 MUST NOT be added. 585 |-- SCHC Fragment Header --| 586 + ------------------------ + ------- + 587 | RuleID | W | FCN | Payload | 588 + ------ + ------ + ------ + ------- + 589 | 3 bits | 2 bits | 3 bits | 88 bits | 591 Figure 3: Regular SCHC Fragment format for all fragments except the 592 last one 594 The use of SCHC ACK REQ is NOT RECOMMENDED, instead the All-1 SCHC 595 Fragment SHOULD be used to request a SCHC ACK from the receiver 596 (Network SCHC). As per [RFC8724], the All-0 message is 597 distinguishable from the SCHC ACK REQ (All-1 message). The 598 penultimate tile of a SCHC Packet is of regular size. 600 4.7.1.2. All-1 SCHC Fragment 602 Figure 4 shows an example of the All-1 message. The All-1 message 603 MUST contain the last tile of the SCHC Packet. The last tile MUST be 604 of at least 1 byte (one L2 word). Padding MUST NOT be added, as the 605 resulting size is L2-word-multiple. 607 |--- SCHC Fragment Header ---| 608 + --------------------------- + ------------ + 609 | RuleID | W | FCN=ALL-1 | Payload | 610 + ------ + ------ + --------- + ------------ + 611 | 3 bits | 2 bits | 3 bits | 8 to 88 bits | 613 Figure 4: All-1 SCHC Message format with last tile 615 As per [RFC8724] the All-1 must be distinguishable from a SCHC 616 Sender-Abort message (with same Rule ID, M, and N values). The All-1 617 MUST have the last tile of the SCHC Packet, which MUST be of at least 618 1 byte. The SCHC Sender-Abort message header size is of 1 byte, with 619 no padding bits. 621 For the All-1 message to be distinguishable from the Sender-Abort 622 message, the Sender-Abort message MUST be of 1 byte (only header with 623 no padding). This way, the minimum size of the All-1 is 2 bytes, and 624 the Sender-Abort message is 1 byte. 626 4.7.1.3. SCHC ACK Format 628 Figure 5 shows the SCHC ACK format when all fragments have been 629 correctly received (C=1). Padding MUST be added to complete the 630 64-bit Sigfox downlink frame payload size. 632 |---- SCHC ACK Header ----| 633 + ----------------------- + ------- + 634 | RuleID | W | C=b'1 | b'0-pad | 635 + ------ + ------ + ----- + ------- + 636 | 3 bits | 2 bits | 1 bit | 58 bits | 638 Figure 5: SCHC Success ACK message format 640 In case SCHC fragment losses are found in any of the windows of the 641 SCHC Packet (C=0), the SCHC Compound ACK MUST be used. The SCHC 642 Compound ACK message format is shown in Figure 6. The window 643 numbered 00, if present in the SCHC Compound ACK, MUST be placed 644 between the Rule ID and the C bit to avoid confusion with padding 645 bits. If padding is needed for the SCHC Compound ACK, padding bits 646 MUST be 0 to make subsequent window numbers and bitmaps 647 distinguishable. 649 |---- SCHC ACK Header ----|-W = x -|...| --- W = x + i ---| 650 + ----------------------- + ------ +...+ ------- + ------ + ------- + 651 | RuleID | W=b'x | C=b'0 | Bitmap |...| W=b'x+i | Bitmap | b'0-pad | 652 + ------ + ------ + ----- + ------ +...+ ------- + ------ + ------- + 653 | 3 bits | 2 bits | 1 bit | 7 bits | | 2 bits | 7 bits | 655 On top are noted the window number of the corresponding bitmap. 656 Losses are found in windows x,...,x+i. 658 Figure 6: SCHC Compound ACK message format 660 The following figures show examples of the Compound ACK message 661 format. 663 |---- SCHC ACK Header ----|- W=00 -|----- W=01 ------| 664 + ----------------------- + ------ + ------ + ------ + ------- + 665 | RuleID | W=b'00 | C=b'0 | Bitmap | W=b'01 | Bitmap | b'0-pad | 666 + ------ + ------ + ----- + ------ + ------ + ------ + ------- + 667 | 3 bits | 2 bits | 1 bit | 7 bits | 2 bits | 7 bits | 42 bits | 669 Losses are found in windows 00 and 01. 671 Figure 7: SCHC Compound ACK example 1 673 |---- SCHC ACK Header ----|- W=01 -|----- W=11 ------| 674 + ----------------------- + ------ + ------ + ------ + ------- + 675 | RuleID | W=b'01 | C=b'0 | Bitmap | W=b'11 | Bitmap | b'0-pad | 676 + ------ + ------ + ----- + ------ + ------ + ------ + ------- + 677 | 3 bits | 2 bits | 1 bit | 7 bits | 2 bits | 7 bits | 42 bits | 679 Losses are found in windows 01 and 11. 681 Figure 8: SCHC Compound ACK example 2 683 |---- SCHC ACK Header ----|- W=00 -|----- W=10 ------| 684 + ----------------------- + ------ + ------ + ------ + ------- + 685 | RuleID | W=b'00 | C=b'0 | Bitmap | W=b'10 | Bitmap | b'0-pad | 686 + ------ + ------ + ----- + ------ + ------ + ------ + ------- + 687 | 3 bits | 2 bits | 1 bit | 7 bits | 2 bits | 7 bits | 42 bits | 689 Losses are found in windows 00 and 10. 691 Figure 9: SCHC Compound ACK example 3 693 Figure 10 shows the Compound ACK message format when losses are found 694 in all windows. The window numbers and its corresponding bitmaps are 695 ordered from window numbered 00 to 11, notifying all four possible 696 windows. 698 |- SCHC ACK Header -|W=b'00|-- W=b'01 ---| 699 +-------------------+------+ ---- +------+ 700 |RuleID|W=b'00|C=b'0|Bitmap|W=b'01|Bitmap| ... 701 +------+------+-----+------+------+------+ 702 |3 bits|2 bits|1 bit|7 bits|2 bits|7 bits| 704 |--- W=b'10 --|--- W=b'11 --| 705 |------+------+------+------+-------+ 706 ... |W=b'10|Bitmap|W=b'11|Bitmap|b'0-pad| 707 |------+------+------+------+-------+ 708 |2 bits|7 bits|2 bits|7 bits|24 bits| 710 Losses are found in windows 00, 01, 10 and 11. 712 Figure 10: SCHC Compound ACK example 4 714 |- SCHC ACK Header -|W=b'00|-- W=b'01 ---|--- W=b'10 --| 715 +-------------------+------+------+------+------+------+-------+ 716 |RuleID|W=b'00|C=b'0|Bitmap|W=b'01|Bitmap|W=b'10|Bitmap|b'0-pad| 717 +------+------+-----+------+------+------+------+------+-------+ 718 |3 bits|2 bits|1 bit|7 bits|2 bits|7 bits|2 bits|7 bits|33 bits| 720 Losses are found in windows 00, 01 and 10. 722 Figure 11: SCHC Compound ACK example 5 724 4.7.1.4. SCHC Sender-Abort Message format 726 |---- Sender-Abort Header ----| 727 + --------------------------- + 728 | RuleID | W | FCN=ALL-1 | 729 + ------ + ------ + --------- + 730 | 3 bits | 2 bits | 3 bits | 732 Figure 12: SCHC Sender-Abort message format 734 4.7.1.5. SCHC Receiver-Abort Message format 736 |- Receiver-Abort Header -| 737 + ----------------------- + ------- + 738 | RuleID | W=b'11 | C=b'1 | b'1-pad | 739 + ------ + ------ + ----- + ------- + 740 | 3 bits | 2 bits | 1 bit | 58 bits | 742 Figure 13: SCHC Receiver-Abort message format 744 4.7.2. Uplink ACK-on-Error Mode: Two-byte SCHC Header 746 4.7.2.1. Regular SCHC Fragment 748 Figure 14 shows an example of a regular SCHC fragment for all 749 fragments except the last one. The penultimate tile of a SCHC Packet 750 is of the regular size. 752 |-- SCHC Fragment Header --| 753 + ------------------------ + ------- + 754 | RuleID | W | FCN | Payload | 755 + ------ + ------ + ------ + ------- + 756 | 8 bits | 3 bits | 5 bits | 80 bits | 758 Figure 14: Regular SCHC Fragment format for all fragments except the 759 last one 761 The use of SCHC ACK is NOT RECOMMENDED, instead the All-1 SCHC 762 Fragment SHOULD be used to request a SCHC ACK from the receiver 763 (Network SCHC). As per [RFC8724], the All-0 message is 764 distinguishable from the SCHC ACK REQ (All-1 message). 766 4.7.2.2. All-1 SCHC Fragment 768 Figure 15 shows an example of the All-1 message. The All-1 message 769 MUST contain the last tile of the SCHC Packet. 771 |--- SCHC Fragment Header ---| 772 + --------------------------- + ------------ + 773 | RuleID | W | FCN=ALL-1 | Payload | 774 + ------ + ------ + --------- + ------------ + 775 | 8 bits | 3 bits | 5 bits | 8 to 80 bits | 777 Figure 15: All-1 SCHC message format with last tile 779 As per [RFC8724] the All-1 must be distinguishable from the a SCHC 780 Sender-Abort message (with same Rule ID, M and N values). The All-1 781 MUST have the last tile of the SCHC Packet, that MUST be of at least 782 1 byte. The SCHC Sender-Abort message header size is of 2 byte, with 783 no padding bits. 785 For the All-1 message to be distinguishable from the Sender-Abort 786 message, the Sender-Abort message MUST be of 2 byte (only header with 787 no padding). This way, the minimum size of the All-1 is 3 bytes, and 788 the Sender-Abort message is 2 bytes. 790 4.7.2.3. SCHC ACK Format 792 Figure 16 shows the SCHC ACK format when all fragments have been 793 correctly received (C=1). Padding MUST be added to complete the 794 64-bit Sigfox downlink frame payload size. 796 |----- SCHC ACK Header ----| 797 + ------------------------ + ------ + 798 | RuleID | W | C=b'1 | b'0-pad | 799 + ------ + ------ + ----- + ------- + 800 | 8 bits | 3 bits | 1 bit | 52 bits | 802 Figure 16: SCHC Success ACK message format 804 The SCHC Compound ACK message MUST be used in case SCHC fragment 805 losses are found in any window of the SCHC Packet (C=0). The SCHC 806 Compound ACK message format is shown in Figure 17. The SCHC Compound 807 ACK can report up to 3 windows with losses. The window number (W) 808 and its corresponding bitmap MUST be ordered from the lowest-numbered 809 window number to the highest-numbered window. If window numbered 000 810 is present in the SCHC Compound ACK, the window number 000 MUST be 811 placed between the Rule ID and C bit to avoid confusion with padding 812 bits. The SCHC Compound ACK MUST be 0 padded (Padding bits must be 813 0). 815 |- SCHC ACK Header -| W=b'x |...|--- W=b'x+i ---| 816 +-------------------+-------+...+-------+-------+-------+ 817 |RuleID|W=b'x |C=b'0|Bitmap |...|W=b'x+i|Bitmap |b'0-pad| 818 +------+------+-----+-------+...|-------+-------+-------+ 819 |8 bits|3 bits|1 bit|15 bits| | 3 bits|15 bits| 821 On top are noted the window number 822 of the corresponding bitmap. 823 Losses are found in windows x,...,x+i. 825 Figure 17: SCHC Compound ACK message format 827 4.7.2.4. SCHC Sender-Abort Messages 829 |---- Sender-Abort Header ----| 830 + --------------------------- + 831 | RuleID | W | FCN=ALL-1 | 832 + ------ + ------ + --------- + 833 | 8 bits | 3 bits | 5 bits | 835 Figure 18: SCHC Sender-Abort message format 837 4.7.2.5. SCHC Receiver-Abort Message 839 |-- Receiver-Abort Header -| 840 + ------------------------ + ------- + 841 | RuleID | W=b'111 | C=b'1 | b'1-pad | 842 + ------ + ------- + ----- + ------- + 843 | 8 bits | 3 bits | 1 bit | 52 bits | 845 Figure 19: SCHC Receiver-Abort message format 847 4.8. Padding 849 The Sigfox payload fields have different characteristics in uplink 850 and downlink. 852 Uplink frames can contain a payload size from 0 to 12 bytes. The 853 Sigfox radio protocol allows sending zero bits, one single bit of 854 information for binary applications (e.g. status), or an integer 855 number of bytes. Therefore, for 2 or more bits of payload it is 856 required to add padding to the next integer number of bytes. The 857 reason for this flexibility is to optimize transmission time and 858 hence save battery consumption at the device. 860 Downlink frames on the other hand have a fixed length. The payload 861 length MUST be 64 bits (i.e. 8 bytes). Hence, if less information 862 bits are to be transmitted, padding MUST be used with bits equal to 863 0. 865 5. Fragmentation Sequence Examples 867 In this section, some sequence diagrams depicting messages exchanges 868 for different fragmentation modes and use cases are shown. In the 869 examples, 'Seq' indicates the Sigfox Sequence Number of the frame 870 carrying a fragment. 872 5.1. Uplink No-ACK Examples 874 The FCN field indicates the size of the data packet. The first 875 fragment is marked with FCN = X-1, where X is the number of fragments 876 the message is split into. All fragments are marked with decreasing 877 FCN values. Last packet fragment is marked with the FCN = All-1 878 (1111). 880 Case No losses - All fragments are sent and received successfully. 882 Sender Receiver 883 |-------FCN=6 (0110), Seq=1-------->| 884 |-------FCN=5 (0101), Seq=2-------->| 885 |-------FCN=4 (0100), Seq=3-------->| 886 |-------FCN=3 (0011), Seq=4-------->| 887 |-------FCN=2 (0010), Seq=5-------->| 888 |-------FCN=1 (0001), Seq=6-------->| 889 |-------FCN=15 (1111), Seq=7------->| All fragments received 890 (End) 892 Figure 20: UL No-ACK No-Losses 894 When the first SCHC fragment is received, the Receiver can calculate 895 the total number of SCHC fragments that the SCHC Packet is composed 896 of. For example, if the first fragment is numbered with FCN=6, the 897 receiver can expect six more messages/fragments (i.e., with FCN going 898 from 5 downwards, and the last fragment with a FCN equal to 15). 900 Case losses on any fragment except the first. 902 Sender Receiver 903 |-------FCN=6, Seq=1-------->| 904 |-------FCN=5, Seq=2----X--->| 905 |-------FCN=4, Seq=3-------->| 906 |-------FCN=3, Seq=4-------->| 907 |-------FCN=2, Seq=5-------->| 908 |-------FCN=1, Seq=6-------->| 909 |-------FCN=15, Seq=7------->| Missing Fragment - Unable to reassemble 910 (End) 912 Figure 21: UL No-ACK Losses (scenario 1) 914 5.2. Uplink ACK-on-Error Examples: Single-byte SCHC Header 916 The single-byte SCHC header ACK-on-Error mode allows sending up to 28 917 fragments and packet sizes up to 300 bytes. The SCHC fragments may 918 be delivered asynchronously and DL ACK can be sent opportunistically. 920 Case No losses 922 The downlink flag must be enabled in the sender UL message to allow a 923 DL message from the receiver. The DL Enable in the figures shows 924 where the sender should enable the downlink, and wait for an ACK. 926 Sender Receiver 927 |-----W=0, FCN=6, Seq=1----->| 928 |-----W=0, FCN=5, Seq=2----->| 929 |-----W=0, FCN=4, Seq=3----->| 930 |-----W=0, FCN=3, Seq=4----->| 931 |-----W=0, FCN=2, Seq=5----->| 932 |-----W=0, FCN=1, Seq=6----->| 933 DL Enable |-----W=0, FCN=0, Seq=7----->| 934 (no ACK) 935 |-----W=1, FCN=6, Seq=8----->| 936 |-----W=1, FCN=5, Seq=9----->| 937 |-----W=1, FCN=4, Seq=10---->| 938 DL Enable |-----W=1, FCN=7, Seq=11---->| All fragments received 939 |<------ ACK, W=1, C=1 ------| C=1 940 (End) 942 Figure 22: UL ACK-on-Error No-Losses 944 Case Fragments lost in first window 946 In this case, fragments are lost in the first window (W=0). After 947 the first All-0 message arrives, the Receiver leverages the 948 opportunity and sends an ACK with the corresponding bitmap and C=0. 950 After the missing fragments from the first window (W=0) are resent, 951 the sender continues transmitting the fragments of the following 952 window (W=1) without opening a reception opportunity. Finally, the 953 All-1 fragment is sent, the downlink is enabled, and the ACK is 954 received with C=1. 956 Sender Receiver 957 |-----W=0, FCN=6, Seq=1----->| 958 |-----W=0, FCN=5, Seq=2--X-->| 959 |-----W=0, FCN=4, Seq=3----->| 960 |-----W=0, FCN=3, Seq=4----->| 961 |-----W=0, FCN=2, Seq=5--X-->| 962 |-----W=0, FCN=1, Seq=6----->| 963 DL Enable |-----W=0, FCN=0, Seq=7----->| Missing Fragments W=0 => FCN=5, Seq=2 and FCN=2, Seq=5 964 |<------ ACK, W=0, C=0 ------| Bitmap:1011011 965 |-----W=0, FCN=5, Seq=8----->| 966 |-----W=0, FCN=2, Seq=9----->| 967 |-----W=1, FCN=6, Seq=10---->| 968 |-----W=1, FCN=5, Seq=11---->| 969 |-----W=1, FCN=4, Seq=12---->| 970 DL Enable |-----W=1, FCN=7, Seq=13---->| All fragments received 971 |<------ ACK, W=1, C=1 ------| C=1 972 (End) 974 Figure 23: UL ACK-on-Error Losses on First Window 976 Case Fragments All-0 lost in first window (W=0) 978 In this example, the All-0 of the first window (W=0) is lost. 979 Therefore, the Receiver waits for the next All-X message to generate 980 the corresponding ACK, notifying the absence of the All-0 of window 981 0. 983 The sender resends the missing All-0 messages (with any other missing 984 fragment from window 0). Note that this behaviour can take place in 985 any intermediate window if the All-0 message is lost. 987 Sender Receiver 988 |-----W=0, FCN=6, Seq=1----->| 989 |-----W=0, FCN=5, Seq=2----->| 990 |-----W=0, FCN=4, Seq=3----->| 991 |-----W=0, FCN=3, Seq=4----->| 992 |-----W=0, FCN=2, Seq=5----->| 993 |-----W=0, FCN=1, Seq=6----->| DL Enable 994 |-----W=0, FCN=0, Seq=7--X-->| 995 (no ACK) 996 |-----W=1, FCN=6, Seq=8----->| 997 |-----W=1, FCN=5, Seq=9----->| 998 |-----W=1, FCN=4, Seq=10---->| 999 DL Enable |-----W=1, FCN=7, Seq=11---->| Missing Fragment W=0, FCN=0, Seq=7 1000 |<------ ACK, W=0, C=0 ------| Bitmap:1111110 1001 |-----W=0, FCN=0, Seq=13---->| All fragments received 1002 DL Enable |-----W=1, FCN=7, Seq=14---->| 1003 |<------ ACK, W=1, C=1 ------| C=1 1004 (End) 1006 Figure 24: UL ACK-on-Error All-0 Lost on First Window 1008 In the following diagram, besides the All-0 there are other lost 1009 fragments in the first window (W=0). 1011 Sender Receiver 1012 |-----W=0, FCN=6, Seq=1----->| 1013 |-----W=0, FCN=5, Seq=2--X-->| 1014 |-----W=0, FCN=4, Seq=3----->| 1015 |-----W=0, FCN=3, Seq=4--X-->| 1016 |-----W=0, FCN=2, Seq=5----->| 1017 |-----W=0, FCN=1, Seq=6----->| 1018 DL Enable |-----W=0, FCN=0, Seq=7--X-->| 1019 (no ACK) 1020 |-----W=1, FCN=6, Seq=8----->| 1021 |-----W=1, FCN=5, Seq=9----->| 1022 |-----W=1, FCN=4, Seq=10---->| 1023 DL Enable |-----W=1, FCN=7, Seq=11---->| Missing Fragment W=0 => FCN= 5, 3 and 0 1024 |<------ ACK, W=0, C=0 ------| Bitmap:1010110 1025 |-----W=0, FCN=5, Seq=13---->| 1026 |-----W=0, FCN=3, Seq=14---->| 1027 |-----W=0, FCN=0, Seq=15---->| All fragments received 1028 DL Enable |-----W=1, FCN=7, Seq=16---->| 1029 |<------ ACK, W=1, C=1 ------| C=1 1030 (End) 1032 Figure 25: UL ACK-on-Error All-0 and other Fragments Lost on First 1033 Window 1035 In the next examples, there are losses in both the first (W=0) and 1036 second (W=1) windows. The retransmission cycles after the All-1 is 1037 sent (i.e., not in intermediate windows) should always finish with an 1038 with an All-1. In case an intermediate All-0 is lost and then 1039 retransmitted, the All-1 is resent after, as it serves as an ACK 1040 Request message to confirm the correct reception of the retransmitted 1041 fragments. 1043 Sender Receiver 1044 |-----W=0, FCN=6 (110), Seq=1----->| 1045 |-----W=0, FCN=5 (101), Seq=2--X-->| 1046 |-----W=0, FCN=4 (100), Seq=3----->| 1047 |-----W=0, FCN=3 (011), Seq=4--X-->| 1048 |-----W=0, FCN=2 (010), Seq=5----->| 1049 |-----W=0, FCN=1 (001), Seq=6----->| 1050 DL enable |-----W=0, FCN=0 (000), Seq=7--X-->| 1051 (no ACK) 1052 |-----W=1, FCN=6 (110), Seq=8--X-->| 1053 |-----W=1, FCN=5 (101), Seq=9----->| 1054 |-----W=1, FCN=4 (011), Seq=10-X-->| 1055 DL enable |-----W=1, FCN=7 (111), Seq=11---->| Missing Fragment W=0 => FCN= 5, 3 and 0 1056 |<--------- ACK, W=0, C=0 ---------| Bitmap:1010110 1057 |-----W=0, FCN=5 (101), Seq=13---->| 1058 |-----W=0, FCN=3 (011), Seq=14---->| 1059 |-----W=0, FCN=0 (000), Seq=15---->| 1060 DL enable |-----W=1, FCN=7 (111), Seq=16---->| Missing Fragment W=1 => FCN= 6 and 4 1061 |<--------- ACK, W=1, C=0 ---------| Bitmap:0100001 1062 |-----W=1, FCN=6 (110), Seq=18---->| 1063 |-----W=1, FCN=4 (011), Seq=19---->| All fragments received 1064 DL enable |-----W=1, FCN=7 (111), Seq=20---->| 1065 |<--------- ACK, W=1, C=1 ---------| C=1 1066 (End) 1068 Figure 26: UL ACK-on-Error All-0 and other Fragments Lost on First 1069 and Second Windows (1) 1071 Similar case as above, but with less fragments in the second window 1072 (W=1) 1073 Sender Receiver 1074 |-----W=0, FCN=6 (110), Seq=1----->| 1075 |-----W=0, FCN=5 (101), Seq=2--X-->| 1076 |-----W=0, FCN=4 (100), Seq=3----->| 1077 |-----W=0, FCN=3 (011), Seq=4--X-->| 1078 |-----W=0, FCN=2 (010), Seq=5----->| 1079 |-----W=0, FCN=1 (001), Seq=6----->| 1080 DL enable |-----W=0, FCN=0 (000), Seq=7--X-->| 1081 (no ACK) 1082 |-----W=1, FCN=6 (110), Seq=8--X-->| 1083 DL enable |-----W=1, FCN=7 (111), Seq=9----->| Missing Fragment W=0 => FCN= 5, 3 and 0 1084 |<--------- ACK, W=0, C=0 ---------| Bitmap:1010110 1085 |-----W=0, FCN=5 (101), Seq=10---->| 1086 |-----W=0, FCN=3 (011), Seq=11---->| 1087 DL enable |-----W=0, FCN=0 (000), Seq=12---->| Missing Fragment W=1 => FCN= 6 and 4 1088 |<--------- ACK, W=1, C=0 ---------| Bitmap:0000001 1089 |-----W=1, FCN=6 (110), Seq=15---->| All fragments received 1090 DL enable |-----W=1, FCN=7 (111), Seq=17---->| 1091 |<--------- ACK, W=1, C=1 ---------| C=1 1092 (End) 1094 Figure 27: UL ACK-on-Error All-0 and other Fragments Lost on First 1095 and Second Windows (2) 1097 Case ACK is lost 1099 SCHC over Sigfox does not implement the SCHC ACK REQ message. 1100 Instead it uses the SCHC All-1 message to request an ACK, when 1101 required. 1103 Sender Receiver 1104 |-----W=0, FCN=6, Seq=1----->| 1105 |-----W=0, FCN=5, Seq=2----->| 1106 |-----W=0, FCN=4, Seq=3----->| 1107 |-----W=0, FCN=3, Seq=4----->| 1108 |-----W=0, FCN=2, Seq=5----->| 1109 |-----W=0, FCN=1, Seq=6----->| 1110 DL Enable |-----W=0, FCN=0, Seq=7----->| 1111 (no ACK) 1112 |-----W=1, FCN=6, Seq=8----->| 1113 |-----W=1, FCN=5, Seq=9----->| 1114 |-----W=1, FCN=4, Seq=10---->| 1115 DL Enable |-----W=1, FCN=7, Seq=11---->| All fragments received 1116 |<------ ACK, W=1, C=1 ---X--| C=1 1117 DL Enable |-----W=1, FCN=7, Seq=13---->| RESEND ACK 1118 |<------ ACK, W=1, C=1 ------| C=1 1119 (End) 1121 Figure 28: UL ACK-on-Error ACK Lost 1123 The number of times an ACK will be requested is determined by the 1124 MAX_ACK_REQUESTS. 1126 5.3. SCHC Abort Examples 1128 Case SCHC Sender-Abort 1130 The sender may need to send a Sender-Abort to stop the current 1131 communication. This may happen, for example, if the All-1 has been 1132 sent MAX_ACK_REQUESTS times. 1134 Sender Receiver 1135 |-----W=0, FCN=6, Seq=1----->| 1136 |-----W=0, FCN=5, Seq=2----->| 1137 |-----W=0, FCN=4, Seq=3----->| 1138 |-----W=0, FCN=3, Seq=4----->| 1139 |-----W=0, FCN=2, Seq=5----->| 1140 |-----W=0, FCN=1, Seq=6----->| 1141 DL Enable |-----W=0, FCN=0, Seq=7----->| 1142 (no ACK) 1143 |-----W=1, FCN=6, Seq=8----->| 1144 |-----W=1, FCN=5, Seq=9----->| 1145 |-----W=1, FCN=4, Seq=10---->| 1146 DL Enable |-----W=1, FCN=7, Seq=11---->| All fragments received 1147 |<------ ACK, W=1, C=1 ---X--| C=1 1148 DL Enable |-----W=1, FCN=7, Seq=14---->| RESEND ACK (1) 1149 |<------ ACK, W=1, C=1 ---X--| C=1 1150 DL Enable |-----W=1, FCN=7, Seq=15---->| RESEND ACK (2) 1151 |<------ ACK, W=1, C=1 ---X--| C=1 1152 DL Enable |-----W=1, FCN=7, Seq=16---->| RESEND ACK (3) 1153 |<------ ACK, W=1, C=1 ---X--| C=1 1154 DL Enable |-----W=1, FCN=7, Seq=17---->| RESEND ACK (4) 1155 |<------ ACK, W=1, C=1 ---X--| C=1 1156 DL Enable |-----W=1, FCN=7, Seq=18---->| RESEND ACK (5) 1157 |<------ ACK, W=1, C=1 ---X--| C=1 1158 DL Enable |----Sender-Abort, Seq=19--->| exit with error condition 1159 (End) 1161 Figure 29: UL ACK-on-Error Sender-Abort 1163 Case Receiver-Abort 1165 The reciever may need to send a Receiver-Abort to stop the current 1166 communication. This message can only be sent after a DL enable. 1168 Sender Receiver 1169 |-----W=0, FCN=6, Seq=1----->| 1170 |-----W=0, FCN=5, Seq=2----->| 1171 |-----W=0, FCN=4, Seq=3----->| 1172 |-----W=0, FCN=3, Seq=4----->| 1173 |-----W=0, FCN=2, Seq=5----->| 1174 |-----W=0, FCN=1, Seq=6----->| 1175 DL Enable |-----W=0, FCN=0, Seq=7----->| 1176 |<------- RECV ABORT -------| under-resourced 1177 (Error) 1179 Figure 30: UL ACK-on-Error Receiver-Abort 1181 6. Security considerations 1183 The radio protocol authenticates and ensures the integrity of each 1184 message. This is achieved by using a unique device ID and an AES-128 1185 based message authentication code, ensuring that the message has been 1186 generated and sent by the device with the ID claimed in the message. 1188 Application data can be encrypted at the application level or not, 1189 depending on the criticality of the use case. This flexibility 1190 allows providing a balance between cost and effort vs. risk. AES-128 1191 in counter mode is used for encryption. Cryptographic keys are 1192 independent for each device. These keys are associated with the 1193 device ID and separate integrity and confidentiality keys are pre- 1194 provisioned. A confidentiality key is only provisioned if 1195 confidentiality is to be used. 1197 The radio protocol has protections against reply attacks, and the 1198 cloud-based core network provides firewalling protection against 1199 undesired incoming communications. 1201 7. Acknowledgements 1203 Carles Gomez has been funded in part by the Spanish Government 1204 through the Jose Castillejo CAS15/00336 grant, the TEC2016-79988-P 1205 grant, and the PID2019-106808RA-I00 grant, and by Secretaria 1206 d'Universitats i Recerca del Departament d'Empresa i Coneixement de 1207 la Generalitat de Catalunya 2017 through grant SGR 376. 1209 Sergio Aguilar has been funded by the ERDF and the Spanish Government 1210 through project TEC2016-79988-P and project PID2019-106808RA-I00, 1211 AEI/FEDER, EU. 1213 Sandra Cespedes has been funded in part by the ANID Chile Project 1214 FONDECYT Regular 1201893 and Basal Project FB0008. 1216 Diego Wistuba has been funded by the ANID Chile Project FONDECYT 1217 Regular 1201893. 1219 The authors would like to thank Clement Mannequin, Rafael Vidal and 1220 Antonis Platis for their useful comments and implementation design 1221 considerations. 1223 8. References 1225 8.1. Normative References 1227 [RFC8376] Farrell, S., Ed., "Low-Power Wide Area Network (LPWAN) 1228 Overview", RFC 8376, DOI 10.17487/RFC8376, May 2018, 1229 . 1231 [RFC8724] Minaburo, A., Toutain, L., Gomez, C., Barthel, D., and JC. 1232 Zuniga, "SCHC: Generic Framework for Static Context Header 1233 Compression and Fragmentation", RFC 8724, 1234 DOI 10.17487/RFC8724, April 2020, 1235 . 1237 8.2. Informative References 1239 [sigfox-callbacks] 1240 Sigfox, "Sigfox Callbacks", 1241 . 1243 [sigfox-spec] 1244 Sigfox, "Sigfox Radio Specifications", 1245 . 1248 Authors' Addresses 1250 Juan Carlos Zuniga 1251 SIGFOX 1252 Montreal QC 1253 Canada 1255 Email: JuanCarlos.Zuniga@sigfox.com 1256 URI: http://www.sigfox.com/ 1257 Carles Gomez 1258 Universitat Politecnica de Catalunya 1259 C/Esteve Terradas, 7 1260 08860 Castelldefels 1261 Spain 1263 Email: carlesgo@entel.upc.edu 1265 Sergio Aguilar 1266 Universitat Politecnica de Catalunya 1267 C/Esteve Terradas, 7 1268 08860 Castelldefels 1269 Spain 1271 Email: sergio.aguilar.romero@upc.edu 1273 Laurent Toutain 1274 IMT-Atlantique 1275 2 rue de la Chataigneraie 1276 CS 17607 1277 35576 Cesson-Sevigne Cedex 1278 France 1280 Email: Laurent.Toutain@imt-atlantique.fr 1282 Sandra Cespedes 1283 NIC Labs, Universidad de Chile 1284 Av. Almte. Blanco Encalada 1975 1285 Santiago 1286 Chile 1288 Email: scespedes@niclabs.cl 1290 Diego Wistuba 1291 NIC Labs, Universidad de Chile 1292 Av. Almte. Blanco Encalada 1975 1293 Santiago 1294 Chile 1296 Email: wistuba@niclabs.cl