idnits 2.17.1 draft-ietf-lpwan-schc-over-sigfox-07.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** There are 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 285: '...ntation mode, a DL opportunity MUST be...' RFC 2119 keyword, line 296: '...m All-0 or All-1 MUST NOT use the DL r...' RFC 2119 keyword, line 301: '... The RuleID MUST be included in the ...' RFC 2119 keyword, line 328: '...ss of a SCHC Packet MUST be checked at...' RFC 2119 keyword, line 338: '...eck Sequence (RCS) is NOT RECOMMENDED....' (36 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (July 9, 2021) is 1022 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) == Outdated reference: A later version (-17) exists of draft-ietf-lpwan-schc-compound-ack-00 ** Downref: Normative reference to an Informational RFC: RFC 8376 Summary: 4 errors (**), 0 flaws (~~), 2 warnings (==), 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: January 10, 2022 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 July 9, 2021 14 SCHC over Sigfox LPWAN 15 draft-ietf-lpwan-schc-over-sigfox-07 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 January 10, 2022. 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 over Sigfox . . . . . . . . . . . . . . . . . . . . . . 3 67 3.1. Network Architecture . . . . . . . . . . . . . . . . . . 3 68 3.2. Uplink . . . . . . . . . . . . . . . . . . . . . . . . . 5 69 3.3. Downlink . . . . . . . . . . . . . . . . . . . . . . . . 6 70 3.4. SCHC-ACK on Downlink . . . . . . . . . . . . . . . . . . 7 71 3.5. SCHC Rules . . . . . . . . . . . . . . . . . . . . . . . 7 72 3.6. Fragmentation . . . . . . . . . . . . . . . . . . . . . . 7 73 3.6.1. Uplink Fragmentation . . . . . . . . . . . . . . . . 8 74 3.6.2. Downlink Fragmentation . . . . . . . . . . . . . . . 11 75 3.7. SCHC-over-Sigfox F/R Message Formats . . . . . . . . . . 12 76 3.7.1. Uplink ACK-on-Error Mode: Single-byte SCHC Header . . 12 77 3.7.2. Uplink ACK-on-Error Mode: Two-byte SCHC Header . . . 16 78 3.8. Padding . . . . . . . . . . . . . . . . . . . . . . . . . 18 79 4. Fragmentation Sequence Examples . . . . . . . . . . . . . . . 19 80 4.1. Uplink No-ACK Examples . . . . . . . . . . . . . . . . . 19 81 4.2. Uplink ACK-on-Error Examples: Single-byte SCHC Header . . 20 82 4.3. SCHC Abort Examples . . . . . . . . . . . . . . . . . . . 27 83 5. Security considerations . . . . . . . . . . . . . . . . . . . 29 84 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 29 85 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 30 86 7.1. Normative References . . . . . . . . . . . . . . . . . . 30 87 7.2. Informative References . . . . . . . . . . . . . . . . . 30 88 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 30 90 1. Introduction 92 The Generic Framework for Static Context Header Compression and 93 Fragmentation (SCHC) specification [RFC8724] describes two 94 mechanisms: i) a frame fragmentation and loss recovery functionality, 95 and ii) an application header compression scheme. Either can be used 96 on top of all the four LWPAN technologies defined in [RFC8376]. 97 These LPWANs have similar characteristics such as star-oriented 98 topologies, network architecture, connected devices with built-in 99 applications, etc. 101 SCHC offers a great level of flexibility to accommodate all these 102 LPWAN technologies. Even though there are a great number of 103 similarities between them, some differences exist with respect to the 104 transmission characteristics, payload sizes, etc. Hence, there are 105 optimal parameters and modes of operation that can be used when SCHC 106 is used on top of a specific LPWAN technology. 108 This document describes the recommended parameters, settings, and 109 modes of operation to be used when SCHC is implemented over a Sigfox 110 LPWAN. This set of parameters are also known as a "SCHC over Sigfox 111 profile." 113 2. Terminology 115 It is assumed that the reader is familiar with the terms and 116 mechanisms defined in [RFC8376] and in [RFC8724]. 118 3. SCHC over Sigfox 120 The Generic SCHC Framework described in [RFC8724] takes advantage of 121 the predictability of data flows existing in LPWAN applications to 122 avoid context synchronization. 124 Contexts need to be stored and pre-configured on both ends. This can 125 be done either by using a provisioning protocol, by out of band 126 means, or by pre-provisioning them (e.g. at manufacturing time). The 127 way contexts are configured and stored on both ends is out of the 128 scope of this document. 130 3.1. Network Architecture 132 Figure 1 represents the architecture for compression/decompression 133 (C/D) and fragmentation/reassembly (F/R) based on the terminology 134 defined in [RFC8376], where the Radio Gateway (RG) is a Sigfox Base 135 Station and the Network Gateway (NGW) is the Sigfox cloud-based 136 Network. 138 Sigfox Device Application 139 +----------------+ +--------------+ 140 | APP1 APP2 APP3 | |APP1 APP2 APP3| 141 +----------------+ +--------------+ 142 | UDP | | | | UDP | 143 | IPv6 | | | | IPv6 | 144 +--------+ | | +--------+ 145 | SCHC C/D & F/R | | | 146 | | | | 147 +-------+--------+ +--------+-----+ 148 $ . 149 $ +---------+ +--------------+ +---------+ . 150 $ | | | | | Network | . 151 +~~ |Sigfox BS| |Sigfox Network| | SCHC | . 152 | (RG) | === | (NGW) | === |C/D & F/R|..... 153 +---------+ +--------------+ +---------+ 155 Figure 1: Network Architecture 157 In the case of the global Sigfox Network, RGs (or Base Stations) are 158 distributed over multiple countries wherever the Sigfox LPWAN service 159 is provided. The NGW (or cloud-based Sigfox Core Network) is a 160 single entity that connects to all Sigfox base stations in the world, 161 providing hence a global single star network topology. 163 The Device sends application flows that are compressed and/or 164 fragmented by a SCHC Compressor/Decompressor (SCHC C/D + F/R) to 165 reduce headers size and/or fragment the packet. The resulting SCHC 166 Message is sent over a layer two (L2) Sigfox frame to the Sigfox Base 167 Stations, which then forward the SCHC Message to the Network Gateway 168 (NGW). The NGW then delivers the SCHC Message and associated 169 gathered metadata to the Network SCHC C/D + F/R. 171 The Sigfox Network (NGW) communicates with the Network SCHC C/D + F/R 172 for compression/decompression and/or for fragmentation/reassembly. 173 The Network SCHC C/D + F/R shares the same set of rules as the Dev 174 SCHC C/D + F/R. The Network SCHC C/D + F/R can be collocated with 175 the NGW or it could be located in a different place, as long as a 176 tunnel or secured communication is established between the NGW and 177 the SCHC C/D + F/R functions. After decompression and/or reassembly, 178 the packet can be forwarded over the Internet to one (or several) 179 LPWAN Application Server(s) (App). 181 The SCHC C/D + F/R processes are bidirectional, so the same 182 principles are applicable on both uplink (UL) and downlink (DL). 184 3.2. Uplink 186 Uplink Sigfox transmissions occur in repetitions over different times 187 and frequencies. Besides time and frequency diversities, the Sigfox 188 network also provides space diversity, as potentially an uplink 189 message will be received by several base stations. 191 Since all messages are self-contained and base stations forward all 192 these messages back to the same Sigfox Network, multiple input copies 193 can be combined at the NGW providing for extra reliability based on 194 the triple diversity (i.e., time, space and frequency). 196 A detailed description of the Sigfox Radio Protocol can be found in 197 [sigfox-spec]. 199 Messages sent from the Device to the Network are delivered by the 200 Sigfox network (NGW) to the Network SCHC C/D + F/R through a 201 callback/API with the following information: 203 o Device ID 205 o Message Sequence Number 207 o Message Payload 209 o Message Timestamp 211 o Device Geolocation (optional) 213 o RSSI (optional) 215 o Device Temperature (optional) 217 o Device Battery Voltage (optional) 219 The Device ID is a globally unique identifier assigned to the Device, 220 which is included in the Sigfox header of every message. The Message 221 Sequence Number is a monotonically increasing number identifying the 222 specific transmission of this uplink message, and it is also part of 223 the Sigfox header. The Message Payload corresponds to the payload 224 that the Device has sent in the uplink transmission. 226 The Message Timestamp, Device Geolocation, RSSI, Device Temperature 227 and Device Battery Voltage are metadata parameters provided by the 228 Network. 230 A detailed description of the Sigfox callbacks/APIs can be found in 231 [sigfox-callbacks]. 233 Only messages that have passed the L2 Cyclic Redundancy Check (CRC) 234 at network reception are delivered by the Sigfox Network to the 235 Network SCHC C/D + F/R. 237 +---------------+-----------------+ 238 | Sigfox Header | Sigfox payload | 239 +---------------+---------------- + 240 | SCHC message | 241 +-----------------+ 243 Figure 2: SCHC Message in Sigfox 245 Figure 2 shows a SCHC Message sent over Sigfox, where the SCHC 246 Message could be a full SCHC Packet (e.g. compressed) or a SCHC 247 Fragment (e.g. a piece of a bigger SCHC Packet). 249 3.3. Downlink 251 Downlink transmissions are Device-driven and can only take place 252 following an uplink communication that so indicates. Hence, a Device 253 explicitly indicates its intention to receive a downlink message 254 using a donwlink request flag when sending the preceding uplink 255 message to the network. After completing the uplink transmission, 256 the Device opens a fixed window for downlink reception. The delay 257 and duration of the reception opportunity window have fixed values. 258 If there is a downlink message to be sent for this given Device (e.g. 259 either a response to the uplink message or queued information waiting 260 to be transmitted), the network transmits this message to the Device 261 during the reception window. If no message is received by the Device 262 after the reception opportunity window has elapsed, the Device closes 263 the reception window opportunity and gets back to the normal mode 264 (e.g., continue UL transmissions, sleep, stand-by, etc.) 266 When a downlink message is sent to a Device, a reception 267 acknowledgement is generated by the Device and sent back to the 268 Network through the Sigfox radio protocol and reported in the Sigfox 269 Network backend. 271 A detailed description of the Sigfox Radio Protocol can be found in 272 [sigfox-spec] and a detailed description of the Sigfox callbacks/APIs 273 can be found in [sigfox-callbacks]. 275 3.4. SCHC-ACK on Downlink 277 As explained previously, downlink transmissions are Device-driven and 278 can only take place following a specific uplink transmission that 279 indicates and allows a following downlink opportunity. For this 280 reason, when SCHC bi-directional services are used (e.g. Ack-on- 281 Error fragmentation mode) the SCHC protocol implementation needs to 282 consider the times when a downlink message (e.g. SCHC-ACK) can be 283 sent and/or received. 285 For the UL ACK-on-Error fragmentation mode, a DL opportunity MUST be 286 indicated by the last fragment of every window (i.e. FCN = All-0, or 287 FCN = All-1). The Device sends the fragments in sequence and, after 288 transmitting the FCN = All-0 or FCN = All-1, it opens up a reception 289 opportunity. The Network SCHC can then decide to respond at that 290 opportunity (or wait for a further one) with a SCHC-ACK indicating in 291 case there are missing fragments from the current or previous 292 windows. If there is no SCHC-ACK to be sent, or if the network 293 decides to wait for a further DL transmission opportunity, then no DL 294 transmission takes place at that opportunity and after a timeout the 295 UL transmissions continue. Intermediate SCHC fragments with FCN 296 different from All-0 or All-1 MUST NOT use the DL request flag to 297 request a SCHC-ACK. 299 3.5. SCHC Rules 301 The RuleID MUST be included in the SCHC header. The total number of 302 rules to be used affects directly the Rule ID field size, and 303 therefore the total size of the fragmentation header. For this 304 reason, it is recommended to keep the number of rules that are 305 defined for a specific device to the minimum possible. 307 RuleIDs can be used to differentiate data traffic classes (e.g. QoS, 308 control vs. data, etc.), and data sessions. They can also be used to 309 interleave simultaneous fragmentation sessions between a Device and 310 the Network. 312 3.6. Fragmentation 314 The SCHC specification [RFC8724] defines a generic fragmentation 315 functionality that allows sending data packets or files larger than 316 the maximum size of a Sigfox payload. The functionality also defines 317 a mechanism to send reliably multiple messages, by allowing to resend 318 selectively any lost fragments. 320 The SCHC fragmentation supports several modes of operation. These 321 modes have different advantages and disadvantages depending on the 322 specifics of the underlying LPWAN technology and application Use 323 Case. This section describes how the SCHC fragmentation 324 functionality should optimally be implemented when used over a Sigfox 325 LPWAN for the most typical Use Case applications. 327 As described in section 8.2.3 of [RFC8724], the integrity of the 328 fragmentation-reassembly process of a SCHC Packet MUST be checked at 329 the receive end. Since only UL messages/fragments that have passed 330 the CRC-check are delivered to the Network SCHC C/D + F/R, and each 331 one has an associated Sigfox Message Sequence Number (see 332 Section 3.2), integrity can be guaranteed when no consecutive 333 messages are missing from the sequence and all FCN bitmaps are 334 complete. In order to support multiple flows/RuleIDs (potentially 335 interleaved), the implementation of a central message sequence 336 counter at the Network SCHC C/D + F/R is required. With this 337 functionality and in order to save protocol overhead, the use of a 338 dedicated Reassembly Check Sequence (RCS) is NOT RECOMMENDED. 340 The L2 Word Size used by Sigfox is 1 byte (8 bits). 342 3.6.1. Uplink Fragmentation 344 Sigfox uplink transmissions are completely asynchronous and take 345 place in any random frequency of the allowed uplink bandwidth 346 allocation. In addition, devices may go to deep sleep mode, and then 347 wake up and transmit whenever there is a need to send information to 348 the network. Data packets are self-contained (aka "message in a 349 bottle") with all the required information for the network to process 350 them accordingly. Hence, there is no need to perform any network 351 attachment, synchronization, or other procedure before transmitting a 352 data packet. 354 Since uplink transmissions are asynchronous, a SCHC fragment can be 355 transmitted at any given time by the Device. Sigfox uplink messages 356 are fixed in size, and as described in [RFC8376] they can carry 0-12 357 bytes payload. Hence, a single SCHC Tile size per fragmentation mode 358 can be defined so that every Sigfox message always carries one SCHC 359 Tile. 361 When the ACK-on-Error mode is used for uplink fragmentation, the SCHC 362 Compound ACK defined in [I-D.ietf-lpwan-schc-compound-ack]) MUST be 363 used in the downlink responses. 365 3.6.1.1. Uplink No-ACK Mode 367 No-ACK is RECOMMENDED to be used for transmitting short, non-critical 368 packets that require fragmentation and do not require full 369 reliability. This mode can be used by uplink-only devices that do 370 not support downlink communications, or by bidirectional devices when 371 they send non-critical data. 373 Since there are no multiple windows in the No-ACK mode, the W bit is 374 not present. However it is RECOMMENDED to use the FCN field to 375 indicate the size of the data packet. In this sense, the data packet 376 would need to be splitted into X fragments and, similarly to the 377 other fragmentation modes, the first transmitted fragment would need 378 to be marked with FCN = X-1. Consecutive fragments MUST be marked 379 with decreasing FCN values, having the last fragment marked with FCN 380 = (All-1). Hence, even though the No-ACK mode does not allow 381 recovering missing fragments, it allows indicating implicitly the 382 size of the expected packet to the Network and hence detect at the 383 receiver side whether all fragments have been received or not. 385 The RECOMMENDED Fragmentation Header size is 8 bits, and it is 386 composed as follows: 388 o RuleID size: 4 bits 390 o DTag size (T): 0 bits 392 o Fragment Compressed Number (FCN) size (N): 4 bits 394 o As per [RFC8724], in the No-ACK mode the W (window) field is not 395 present. 397 o RCS size: 0 bits (Not used) 399 3.6.1.2. Uplink ACK-on-Error Mode: Single-byte SCHC Header 401 ACK-on-Error with single-byte header is RECOMMENDED for medium to 402 large size packets that need to be sent reliably. ACK-on-Error is 403 optimal for Sigfox transmissions, since it leads to a reduced number 404 of ACKs in the lower capacity downlink channel. Also, downlink 405 messages can be sent asynchronously and opportunistically. 407 Allowing transmission of packets/files up to 300 bytes long, the SCHC 408 uplink Fragmentation Header size is RECOMMENDED to be 8 bits in size 409 and is composed as follows: 411 o Rule ID size: 3 bits 413 o DTag size (T): 0 bits 415 o Window index (W) size (M): 2 bits 417 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) 422 o Tile size: 11 bytes 424 o Retransmission Timer: Application-dependent 426 o Inactivity Timer: Application-dependent 428 o RCS size: 0 bits (Not used) 430 The correspondent SCHC ACK in the downlink is 13 bits long, so 431 padding is needed to complete the required 64 bits of Sigfox payload. 433 3.6.1.3. Uplink ACK-on-Error Mode: Two-byte SCHC Header 435 ACK-on-Error with two-byte header is RECOMMENDED for very large size 436 packets that need to be sent reliably. ACK-on-Error is optimal for 437 Sigfox transmissions, since it leads to a reduced number of ACKs in 438 the lower capacity downlink channel. Also, downlink messages can be 439 sent asynchronously and opportunistically. 441 In order to allow transmission of very large packets/files up to 2250 442 bytes long, the SCHC uplink Fragmentation Header size is RECOMMENDED 443 to be 16 bits in size and composed as follows: 445 o Rule ID size is: 8 bits 447 o DTag size (T) is: 0 bits 449 o Window index (W) size (M): 3 bits 451 o Fragment Compressed Number (FCN) size (N): 5 bits. 453 o MAX_ACK_REQUESTS: 5 455 o WINDOW_SIZE: 31 (with a maximum value of FCN=0b11110) 457 o Tile size: 10 bytes 459 o Retransmission Timer: Application-dependent 461 o Inactivity Timer: Application-dependent 463 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 3.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 3.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 516 o Window index (W) size (M) is: 0 bits 518 o Fragment Compressed Number (FCN) size (N): 5 bits 520 o MAX_ACK_REQUESTS: 5 522 o WINDOW_SIZE: 31 (with a maximum value of FCN=0b11110) 524 o Tile size: 7 bytes 526 o Retransmission Timer: Application-dependent 528 o Inactivity Timer: Application-dependent 530 o RCS size: 0 bits (Not used) 532 3.7. SCHC-over-Sigfox F/R Message Formats 534 This section depicts the different formats of SCHC Fragment, SCHC ACK 535 (including the SCHC Compound ACK defined in 536 [I-D.ietf-lpwan-schc-compound-ack]), and SCHC Abort used in SCHC over 537 Sigfox. 539 3.7.1. Uplink ACK-on-Error Mode: Single-byte SCHC Header 541 3.7.1.1. Regular SCHC Fragment 543 Figure 3 shows an example of a regular SCHC fragment for all 544 fragments except the last one. As tiles are of 11 bytes, padding 545 MUST NOT be added. 547 |-- SCHC Fragment Header --| 548 + ------------------------ + ------- + 549 | RuleID | W | FCN | Payload | 550 + ------ + ------ + ------ + ------- + 551 | 3 bits | 2 bits | 3 bits | 88 bits | 553 Figure 3: Regular SCHC Fragment format for all fragments except the 554 last one 556 The use of SCHC ACK REQ is NOT RECOMMENDED, instead the All-1 SCHC 557 Fragment SHOULD be used to request a SCHC ACK from the receiver 558 (Network SCHC). As per [RFC8724], the All-0 message is 559 distinguishable from the SCHC ACK REQ (All-1 message). The 560 penultimate tile of a SCHC Packet is of regular size. 562 3.7.1.2. All-1 SCHC Fragment 564 Figure 4 shows an example of the All-1 message. The All-1 message 565 MUST contain the last tile of the SCHC Packet. The last tile MUST be 566 of at least 1 byte (one L2 word). Padding MUST NOT be added, as the 567 resulting size is L2-word-multiple. 569 |--- SCHC Fragment Header ---| 570 + --------------------------- + ------------ + 571 | RuleID | W | FCN=ALL-1 | Payload | 572 + ------ + ------ + --------- + ------------ + 573 | 3 bits | 2 bits | 3 bits | 8 to 88 bits | 575 Figure 4: All-1 SCHC Message format with last tile 577 As per [RFC8724] the All-1 must be distinguishable from a SCHC 578 Sender-Abort message (with same Rule ID, M, and N values). The All-1 579 MUST have the last tile of the SCHC Packet, which MUST be of at least 580 1 byte. The SCHC Sender-Abort message header size is of 1 byte, with 581 no padding bits. 583 For the All-1 message to be distinguishable from the Sender-Abort 584 message, the Sender-Abort message MUST be of 1 byte (only header with 585 no padding). This way, the minimum size of the All-1 is 2 bytes, and 586 the Sender-Abort message is 1 byte. 588 3.7.1.3. SCHC ACK Format 590 Figure 5 shows the SCHC ACK format when all fragments have been 591 correctly received (C=1). Padding MUST be added to complete the 592 64-bit Sigfox downlink frame payload size. 594 |---- SCHC ACK Header ----| 595 + ----------------------- + ------- + 596 | RuleID | W | C=b'1 | b'0-pad | 597 + ------ + ------ + ----- + ------- + 598 | 3 bits | 2 bits | 1 bit | 58 bits | 600 Figure 5: SCHC Success ACK message format 602 In case SCHC fragment losses are found in any of the windows of the 603 SCHC Packet (C=0), the SCHC Compound ACK defined in 604 [I-D.ietf-lpwan-schc-compound-ack] MUST be used. The SCHC Compound 605 ACK message format is shown in Figure 6. The window numbered 00, if 606 present in the SCHC Compound ACK, MUST be placed between the Rule ID 607 and the C bit to avoid confusion with padding bits. As padding is 608 needed for the SCHC Compound ACK, padding bits MUST be 0 to make 609 subsequent window numbers and bitmaps distinguishable. 611 |---- SCHC ACK Header ----|-W = x -|...| --- W = x + i ---| 612 + ----------------------- + ------ +...+ ------- + ------ + ------- + 613 | RuleID | W=b'x | C=b'0 | Bitmap |...| W=b'x+i | Bitmap | b'0-pad | 614 + ------ + ------ + ----- + ------ +...+ ------- + ------ + ------- + 615 | 3 bits | 2 bits | 1 bit | 7 bits | | 2 bits | 7 bits | 617 On top are noted the window number of the corresponding bitmap. 618 Losses are found in windows x,...,x+i. 620 Figure 6: SCHC Compound ACK message format 622 The following figures show examples of the SCHC Compound ACK message 623 format, when used on SCHC over Sigfox. 625 |---- SCHC ACK Header ----|- W=00 -|----- W=01 ------| 626 + ----------------------- + ------ + ------ + ------ + ------- + 627 | RuleID | W=b'00 | C=b'0 | Bitmap | W=b'01 | Bitmap | b'0-pad | 628 + ------ + ------ + ----- + ------ + ------ + ------ + ------- + 629 | 3 bits | 2 bits | 1 bit | 7 bits | 2 bits | 7 bits | 42 bits | 631 Losses are found in windows 00 and 01. 633 Figure 7: SCHC Compound ACK example 1 635 |---- SCHC ACK Header ----|- W=01 -|----- W=11 ------| 636 + ----------------------- + ------ + ------ + ------ + ------- + 637 | RuleID | W=b'01 | C=b'0 | Bitmap | W=b'11 | Bitmap | b'0-pad | 638 + ------ + ------ + ----- + ------ + ------ + ------ + ------- + 639 | 3 bits | 2 bits | 1 bit | 7 bits | 2 bits | 7 bits | 42 bits | 641 Losses are found in windows 01 and 11. 643 Figure 8: SCHC Compound ACK example 2 645 |---- SCHC ACK Header ----|- W=00 -|----- W=10 ------| 646 + ----------------------- + ------ + ------ + ------ + ------- + 647 | RuleID | W=b'00 | C=b'0 | Bitmap | W=b'10 | Bitmap | b'0-pad | 648 + ------ + ------ + ----- + ------ + ------ + ------ + ------- + 649 | 3 bits | 2 bits | 1 bit | 7 bits | 2 bits | 7 bits | 42 bits | 651 Losses are found in windows 00 and 10. 653 Figure 9: SCHC Compound ACK example 3 655 Figure 10 shows the SCHC Compound ACK message format when losses are 656 found in all windows. The window numbers and its corresponding 657 bitmaps are ordered from window numbered 00 to 11, notifying all four 658 possible windows. 660 |- SCHC ACK Header -|W=b'00|-- W=b'01 ---| 661 +-------------------+------+ ---- +------+ 662 |RuleID|W=b'00|C=b'0|Bitmap|W=b'01|Bitmap| ... 663 +------+------+-----+------+------+------+ 664 |3 bits|2 bits|1 bit|7 bits|2 bits|7 bits| 666 |--- W=b'10 --|--- W=b'11 --| 667 |------+------+------+------+-------+ 668 ... |W=b'10|Bitmap|W=b'11|Bitmap|b'0-pad| 669 |------+------+------+------+-------+ 670 |2 bits|7 bits|2 bits|7 bits|24 bits| 672 Losses are found in windows 00, 01, 10 and 11. 674 Figure 10: SCHC Compound ACK example 4 676 |- SCHC ACK Header -|W=b'00|-- W=b'01 ---|--- W=b'10 --| 677 +-------------------+------+------+------+------+------+-------+ 678 |RuleID|W=b'00|C=b'0|Bitmap|W=b'01|Bitmap|W=b'10|Bitmap|b'0-pad| 679 +------+------+-----+------+------+------+------+------+-------+ 680 |3 bits|2 bits|1 bit|7 bits|2 bits|7 bits|2 bits|7 bits|33 bits| 682 Losses are found in windows 00, 01 and 10. 684 Figure 11: SCHC Compound ACK example 5 686 3.7.1.4. SCHC Sender-Abort Message format 688 |---- Sender-Abort Header ----| 689 + --------------------------- + 690 | RuleID | W | FCN=ALL-1 | 691 + ------ + ------ + --------- + 692 | 3 bits | 2 bits | 3 bits | 694 Figure 12: SCHC Sender-Abort message format 696 3.7.1.5. SCHC Receiver-Abort Message format 698 |- Receiver-Abort Header -| 699 + ----------------------- + ------- + 700 | RuleID | W=b'11 | C=b'1 | b'1-pad | 701 + ------ + ------ + ----- + ------- + 702 | 3 bits | 2 bits | 1 bit | 58 bits | 704 Figure 13: SCHC Receiver-Abort message format 706 3.7.2. Uplink ACK-on-Error Mode: Two-byte SCHC Header 708 3.7.2.1. Regular SCHC Fragment 710 Figure 14 shows an example of a regular SCHC fragment for all 711 fragments except the last one. The penultimate tile of a SCHC Packet 712 is of the regular size. 714 |-- SCHC Fragment Header --| 715 + ------------------------ + ------- + 716 | RuleID | W | FCN | Payload | 717 + ------ + ------ + ------ + ------- + 718 | 8 bits | 3 bits | 5 bits | 80 bits | 720 Figure 14: Regular SCHC Fragment format for all fragments except the 721 last one 723 The use of SCHC ACK is NOT RECOMMENDED, instead the All-1 SCHC 724 Fragment SHOULD be used to request a SCHC ACK from the receiver 725 (Network SCHC). As per [RFC8724], the All-0 message is 726 distinguishable from the SCHC ACK REQ (All-1 message). 728 3.7.2.2. All-1 SCHC Fragment 730 Figure 15 shows an example of the All-1 message. The All-1 message 731 MUST contain the last tile of the SCHC Packet. 733 |--- SCHC Fragment Header ---| 734 + --------------------------- + ------------ + 735 | RuleID | W | FCN=ALL-1 | Payload | 736 + ------ + ------ + --------- + ------------ + 737 | 8 bits | 3 bits | 5 bits | 8 to 80 bits | 739 Figure 15: All-1 SCHC message format with last tile 741 As per [RFC8724] the All-1 must be distinguishable from the a SCHC 742 Sender-Abort message (with same Rule ID, M and N values). The All-1 743 MUST have the last tile of the SCHC Packet, that MUST be of at least 744 1 byte. The SCHC Sender-Abort message header size is of 2 byte, with 745 no padding bits. 747 For the All-1 message to be distinguishable from the Sender-Abort 748 message, the Sender-Abort message MUST be of 2 byte (only header with 749 no padding). This way, the minimum size of the All-1 is 3 bytes, and 750 the Sender-Abort message is 2 bytes. 752 3.7.2.3. SCHC ACK Format 754 Figure 16 shows the SCHC ACK format when all fragments have been 755 correctly received (C=1). Padding MUST be added to complete the 756 64-bit Sigfox downlink frame payload size. 758 |----- SCHC ACK Header ----| 759 + ------------------------ + ------ + 760 | RuleID | W | C=b'1 | b'0-pad | 761 + ------ + ------ + ----- + ------- + 762 | 8 bits | 3 bits | 1 bit | 52 bits | 764 Figure 16: SCHC Success ACK message format 766 The SCHC Compound ACK message MUST be used in case SCHC fragment 767 losses are found in any window of the SCHC Packet (C=0). The SCHC 768 Compound ACK message format is shown in Figure 17. The SCHC Compound 769 ACK can report up to 3 windows with losses. The window number (W) 770 and its corresponding bitmap MUST be ordered from the lowest-numbered 771 window number to the highest-numbered window. If window numbered 000 772 is present in the SCHC Compound ACK, the window number 000 MUST be 773 placed between the Rule ID and C bit to avoid confusion with padding 774 bits. The SCHC Compound ACK MUST be 0 padded (Padding bits must be 775 0). 777 |- SCHC ACK Header -| W=b'x |...|--- W=b'x+i ---| 778 +-------------------+-------+...+-------+-------+-------+ 779 |RuleID|W=b'x |C=b'0|Bitmap |...|W=b'x+i|Bitmap |b'0-pad| 780 +------+------+-----+-------+...|-------+-------+-------+ 781 |8 bits|3 bits|1 bit|31 bits| | 3 bits|31 bits| 783 On top are noted the window number 784 of the corresponding bitmap. 785 Losses are found in windows x,...,x+i. 787 Figure 17: SCHC Compound ACK message format 789 3.7.2.4. SCHC Sender-Abort Messages 791 |---- Sender-Abort Header ----| 792 + --------------------------- + 793 | RuleID | W | FCN=ALL-1 | 794 + ------ + ------ + --------- + 795 | 8 bits | 3 bits | 5 bits | 797 Figure 18: SCHC Sender-Abort message format 799 3.7.2.5. SCHC Receiver-Abort Message 801 |-- Receiver-Abort Header -| 802 + ------------------------ + ------- + 803 | RuleID | W=b'111 | C=b'1 | b'1-pad | 804 + ------ + ------- + ----- + ------- + 805 | 8 bits | 3 bits | 1 bit | 52 bits | 807 Figure 19: SCHC Receiver-Abort message format 809 3.8. Padding 811 The Sigfox payload fields have different characteristics in uplink 812 and downlink. 814 Uplink frames can contain a payload size from 0 to 12 bytes. The 815 Sigfox radio protocol allows sending zero bits, one single bit of 816 information for binary applications (e.g. status), or an integer 817 number of bytes. Therefore, for 2 or more bits of payload it is 818 required to add padding to the next integer number of bytes. The 819 reason for this flexibility is to optimize transmission time and 820 hence save battery consumption at the device. 822 Downlink frames on the other hand have a fixed length. The payload 823 length MUST be 64 bits (i.e. 8 bytes). Hence, if less information 824 bits are to be transmitted, padding MUST be used with bits equal to 825 0. 827 4. Fragmentation Sequence Examples 829 In this section, some sequence diagrams depicting messages exchanges 830 for different fragmentation modes and use cases are shown. In the 831 examples, 'Seq' indicates the Sigfox Sequence Number of the frame 832 carrying a fragment. 834 4.1. Uplink No-ACK Examples 836 The FCN field indicates the size of the data packet. The first 837 fragment is marked with FCN = X-1, where X is the number of fragments 838 the message is split into. All fragments are marked with decreasing 839 FCN values. Last packet fragment is marked with the FCN = All-1 840 (1111). 842 Case No losses - All fragments are sent and received successfully. 844 Sender Receiver 845 |-------FCN=6 (0110), Seq=1-------->| 846 |-------FCN=5 (0101), Seq=2-------->| 847 |-------FCN=4 (0100), Seq=3-------->| 848 |-------FCN=3 (0011), Seq=4-------->| 849 |-------FCN=2 (0010), Seq=5-------->| 850 |-------FCN=1 (0001), Seq=6-------->| 851 |-------FCN=15 (1111), Seq=7------->| All fragments received 852 (End) 854 Figure 20: UL No-ACK No-Losses 856 When the first SCHC fragment is received, the Receiver can calculate 857 the total number of SCHC fragments that the SCHC Packet is composed 858 of. For example, if the first fragment is numbered with FCN=6, the 859 receiver can expect six more messages/fragments (i.e., with FCN going 860 from 5 downwards, and the last fragment with a FCN equal to 15). 862 Case losses on any fragment except the first. 864 Sender Receiver 865 |-------FCN=6, Seq=1-------->| 866 |-------FCN=5, Seq=2----X--->| 867 |-------FCN=4, Seq=3-------->| 868 |-------FCN=3, Seq=4-------->| 869 |-------FCN=2, Seq=5-------->| 870 |-------FCN=1, Seq=6-------->| 871 |-------FCN=15, Seq=7------->| Missing Fragment - Unable to reassemble 872 (End) 874 Figure 21: UL No-ACK Losses (scenario 1) 876 4.2. Uplink ACK-on-Error Examples: Single-byte SCHC Header 878 The single-byte SCHC header ACK-on-Error mode allows sending up to 28 879 fragments and packet sizes up to 300 bytes. The SCHC fragments may 880 be delivered asynchronously and DL ACK can be sent opportunistically. 882 Case No losses 884 The downlink flag must be enabled in the sender UL message to allow a 885 DL message from the receiver. The DL Enable in the figures shows 886 where the sender should enable the downlink, and wait for an ACK. 888 Sender Receiver 889 |-----W=0, FCN=6, Seq=1----->| 890 |-----W=0, FCN=5, Seq=2----->| 891 |-----W=0, FCN=4, Seq=3----->| 892 |-----W=0, FCN=3, Seq=4----->| 893 |-----W=0, FCN=2, Seq=5----->| 894 |-----W=0, FCN=1, Seq=6----->| 895 DL Enable |-----W=0, FCN=0, Seq=7----->| 896 (no ACK) 897 |-----W=1, FCN=6, Seq=8----->| 898 |-----W=1, FCN=5, Seq=9----->| 899 |-----W=1, FCN=4, Seq=10---->| 900 DL Enable |-----W=1, FCN=7, Seq=11---->| All fragments received 901 |<------ ACK, W=1, C=1 ------| C=1 902 (End) 904 Figure 22: UL ACK-on-Error No-Losses 906 Case Fragments lost in first window 908 In this case, fragments are lost in the first window (W=0). After 909 the first All-0 message arrives, the Receiver leverages the 910 opportunity and sends an ACK with the corresponding bitmap and C=0. 912 After the missing fragments from the first window (W=0) are resent, 913 the sender continues transmitting the fragments of the following 914 window (W=1) without opening a reception opportunity. Finally, the 915 All-1 fragment is sent, the downlink is enabled, and the ACK is 916 received with C=1. 918 Sender Receiver 919 |-----W=0, FCN=6, Seq=1----->| 920 |-----W=0, FCN=5, Seq=2--X-->| 921 |-----W=0, FCN=4, Seq=3----->| 922 |-----W=0, FCN=3, Seq=4----->| 923 |-----W=0, FCN=2, Seq=5--X-->| 924 |-----W=0, FCN=1, Seq=6----->| 925 DL Enable |-----W=0, FCN=0, Seq=7----->| Missing Fragments W=0 => FCN=5, Seq=2 and FCN=2, Seq=5 926 |<------ ACK, W=0, C=0 ------| Bitmap:1011011 927 |-----W=0, FCN=5, Seq=8----->| 928 |-----W=0, FCN=2, Seq=9----->| 929 |-----W=1, FCN=6, Seq=10---->| 930 |-----W=1, FCN=5, Seq=11---->| 931 |-----W=1, FCN=4, Seq=12---->| 932 DL Enable |-----W=1, FCN=7, Seq=13---->| All fragments received 933 |<------ ACK, W=1, C=1 ------| C=1 934 (End) 936 Figure 23: UL ACK-on-Error Losses on First Window 938 Case Fragments All-0 lost in first window (W=0) 940 In this example, the All-0 of the first window (W=0) is lost. 941 Therefore, the Receiver waits for the next All-X message to generate 942 the corresponding ACK, notifying the absence of the All-0 of window 943 0. 945 The sender resends the missing All-0 messages (with any other missing 946 fragment from window 0). Note that this behaviour can take place in 947 any intermediate window if the All-0 message is lost. 949 Sender Receiver 950 |-----W=0, FCN=6, Seq=1----->| 951 |-----W=0, FCN=5, Seq=2----->| 952 |-----W=0, FCN=4, Seq=3----->| 953 |-----W=0, FCN=3, Seq=4----->| 954 |-----W=0, FCN=2, Seq=5----->| 955 |-----W=0, FCN=1, Seq=6----->| DL Enable 956 |-----W=0, FCN=0, Seq=7--X-->| 957 (no ACK) 958 |-----W=1, FCN=6, Seq=8----->| 959 |-----W=1, FCN=5, Seq=9----->| 960 |-----W=1, FCN=4, Seq=10---->| 961 DL Enable |-----W=1, FCN=7, Seq=11---->| Missing Fragment W=0, FCN=0, Seq=7 962 |<------ ACK, W=0, C=0 ------| Bitmap:1111110 963 |-----W=0, FCN=0, Seq=13---->| All fragments received 964 DL Enable |-----W=1, FCN=7, Seq=14---->| 965 |<------ ACK, W=1, C=1 ------| C=1 966 (End) 968 Figure 24: UL ACK-on-Error All-0 Lost on First Window 970 In the following diagram, besides the All-0 there are other lost 971 fragments in the first window (W=0). 973 Sender Receiver 974 |-----W=0, FCN=6, Seq=1----->| 975 |-----W=0, FCN=5, Seq=2--X-->| 976 |-----W=0, FCN=4, Seq=3----->| 977 |-----W=0, FCN=3, Seq=4--X-->| 978 |-----W=0, FCN=2, Seq=5----->| 979 |-----W=0, FCN=1, Seq=6----->| 980 DL Enable |-----W=0, FCN=0, Seq=7--X-->| 981 (no ACK) 982 |-----W=1, FCN=6, Seq=8----->| 983 |-----W=1, FCN=5, Seq=9----->| 984 |-----W=1, FCN=4, Seq=10---->| 985 DL Enable |-----W=1, FCN=7, Seq=11---->| Missing Fragment W=0 => FCN= 5, 3 and 0 986 |<------ ACK, W=0, C=0 ------| Bitmap:1010110 987 |-----W=0, FCN=5, Seq=13---->| 988 |-----W=0, FCN=3, Seq=14---->| 989 |-----W=0, FCN=0, Seq=15---->| All fragments received 990 DL Enable |-----W=1, FCN=7, Seq=16---->| 991 |<------ ACK, W=1, C=1 ------| C=1 992 (End) 994 Figure 25: UL ACK-on-Error All-0 and other Fragments Lost on First 995 Window 997 In the next examples, there are losses in both the first (W=0) and 998 second (W=1) windows. The retransmission cycles after the All-1 is 999 sent (i.e., not in intermediate windows) should always finish with an 1000 with an All-1. In case an intermediate All-0 is lost and then 1001 retransmitted, the All-1 is resent after, as it serves as an ACK 1002 Request message to confirm the correct reception of the retransmitted 1003 fragments. 1005 Sender Receiver 1006 |-----W=0, FCN=6 (110), Seq=1----->| 1007 |-----W=0, FCN=5 (101), Seq=2--X-->| 1008 |-----W=0, FCN=4 (100), Seq=3----->| 1009 |-----W=0, FCN=3 (011), Seq=4--X-->| 1010 |-----W=0, FCN=2 (010), Seq=5----->| 1011 |-----W=0, FCN=1 (001), Seq=6----->| 1012 DL enable |-----W=0, FCN=0 (000), Seq=7--X-->| 1013 (no ACK) 1014 |-----W=1, FCN=6 (110), Seq=8--X-->| 1015 |-----W=1, FCN=5 (101), Seq=9----->| 1016 |-----W=1, FCN=4 (011), Seq=10-X-->| 1017 DL enable |-----W=1, FCN=7 (111), Seq=11---->| Missing Fragment W=0 => FCN= 5, 3 and 0 1018 |<--------- ACK, W=0, C=0 ---------| Bitmap:1010110 1019 |-----W=0, FCN=5 (101), Seq=13---->| 1020 |-----W=0, FCN=3 (011), Seq=14---->| 1021 |-----W=0, FCN=0 (000), Seq=15---->| 1022 DL enable |-----W=1, FCN=7 (111), Seq=16---->| Missing Fragment W=1 => FCN= 6 and 4 1023 |<--------- ACK, W=1, C=0 ---------| Bitmap:0100001 1024 |-----W=1, FCN=6 (110), Seq=18---->| 1025 |-----W=1, FCN=4 (011), Seq=19---->| All fragments received 1026 DL enable |-----W=1, FCN=7 (111), Seq=20---->| 1027 |<--------- ACK, W=1, C=1 ---------| C=1 1028 (End) 1030 Figure 26: UL ACK-on-Error All-0 and other Fragments Lost on First 1031 and Second Windows (1) 1033 Similar case as above, but with less fragments in the second window 1034 (W=1) 1035 Sender Receiver 1036 |-----W=0, FCN=6 (110), Seq=1----->| 1037 |-----W=0, FCN=5 (101), Seq=2--X-->| 1038 |-----W=0, FCN=4 (100), Seq=3----->| 1039 |-----W=0, FCN=3 (011), Seq=4--X-->| 1040 |-----W=0, FCN=2 (010), Seq=5----->| 1041 |-----W=0, FCN=1 (001), Seq=6----->| 1042 DL enable |-----W=0, FCN=0 (000), Seq=7--X-->| 1043 (no ACK) 1044 |-----W=1, FCN=6 (110), Seq=8--X-->| 1045 DL enable |-----W=1, FCN=7 (111), Seq=9----->| Missing Fragment W=0 => FCN= 5, 3 and 0 1046 |<--------- ACK, W=0, C=0 ---------| Bitmap:1010110 1047 |-----W=0, FCN=5 (101), Seq=10---->| 1048 |-----W=0, FCN=3 (011), Seq=11---->| 1049 DL enable |-----W=0, FCN=0 (000), Seq=12---->| Missing Fragment W=1 => FCN= 6 and 4 1050 |<--------- ACK, W=1, C=0 ---------| Bitmap:0000001 1051 |-----W=1, FCN=6 (110), Seq=15---->| All fragments received 1052 DL enable |-----W=1, FCN=7 (111), Seq=17---->| 1053 |<--------- ACK, W=1, C=1 ---------| C=1 1054 (End) 1056 Figure 27: UL ACK-on-Error All-0 and other Fragments Lost on First 1057 and Second Windows (2) 1059 Case ACK is lost 1061 SCHC over Sigfox does not implement the SCHC ACK REQ message. 1062 Instead it uses the SCHC All-1 message to request an ACK, when 1063 required. 1065 Sender Receiver 1066 |-----W=0, FCN=6, Seq=1----->| 1067 |-----W=0, FCN=5, Seq=2----->| 1068 |-----W=0, FCN=4, Seq=3----->| 1069 |-----W=0, FCN=3, Seq=4----->| 1070 |-----W=0, FCN=2, Seq=5----->| 1071 |-----W=0, FCN=1, Seq=6----->| 1072 DL Enable |-----W=0, FCN=0, Seq=7----->| 1073 (no ACK) 1074 |-----W=1, FCN=6, Seq=8----->| 1075 |-----W=1, FCN=5, Seq=9----->| 1076 |-----W=1, FCN=4, Seq=10---->| 1077 DL Enable |-----W=1, FCN=7, Seq=11---->| All fragments received 1078 |<------ ACK, W=1, C=1 ---X--| C=1 1079 DL Enable |-----W=1, FCN=7, Seq=13---->| RESEND ACK 1080 |<------ ACK, W=1, C=1 ------| C=1 1081 (End) 1083 Figure 28: UL ACK-on-Error ACK Lost 1085 The number of times an ACK will be requested is determined by the 1086 MAX_ACK_REQUESTS. 1088 4.3. SCHC Abort Examples 1090 Case SCHC Sender-Abort 1092 The sender may need to send a Sender-Abort to stop the current 1093 communication. This may happen, for example, if the All-1 has been 1094 sent MAX_ACK_REQUESTS times. 1096 Sender Receiver 1097 |-----W=0, FCN=6, Seq=1----->| 1098 |-----W=0, FCN=5, Seq=2----->| 1099 |-----W=0, FCN=4, Seq=3----->| 1100 |-----W=0, FCN=3, Seq=4----->| 1101 |-----W=0, FCN=2, Seq=5----->| 1102 |-----W=0, FCN=1, Seq=6----->| 1103 DL Enable |-----W=0, FCN=0, Seq=7----->| 1104 (no ACK) 1105 |-----W=1, FCN=6, Seq=8----->| 1106 |-----W=1, FCN=5, Seq=9----->| 1107 |-----W=1, FCN=4, Seq=10---->| 1108 DL Enable |-----W=1, FCN=7, Seq=11---->| All fragments received 1109 |<------ ACK, W=1, C=1 ---X--| C=1 1110 DL Enable |-----W=1, FCN=7, Seq=14---->| RESEND ACK (1) 1111 |<------ ACK, W=1, C=1 ---X--| C=1 1112 DL Enable |-----W=1, FCN=7, Seq=15---->| RESEND ACK (2) 1113 |<------ ACK, W=1, C=1 ---X--| C=1 1114 DL Enable |-----W=1, FCN=7, Seq=16---->| RESEND ACK (3) 1115 |<------ ACK, W=1, C=1 ---X--| C=1 1116 DL Enable |-----W=1, FCN=7, Seq=17---->| RESEND ACK (4) 1117 |<------ ACK, W=1, C=1 ---X--| C=1 1118 DL Enable |-----W=1, FCN=7, Seq=18---->| RESEND ACK (5) 1119 |<------ ACK, W=1, C=1 ---X--| C=1 1120 DL Enable |----Sender-Abort, Seq=19--->| exit with error condition 1121 (End) 1123 Figure 29: UL ACK-on-Error Sender-Abort 1125 Case Receiver-Abort 1127 The reciever may need to send a Receiver-Abort to stop the current 1128 communication. This message can only be sent after a DL enable. 1130 Sender Receiver 1131 |-----W=0, FCN=6, Seq=1----->| 1132 |-----W=0, FCN=5, Seq=2----->| 1133 |-----W=0, FCN=4, Seq=3----->| 1134 |-----W=0, FCN=3, Seq=4----->| 1135 |-----W=0, FCN=2, Seq=5----->| 1136 |-----W=0, FCN=1, Seq=6----->| 1137 DL Enable |-----W=0, FCN=0, Seq=7----->| 1138 |<------- RECV ABORT -------| under-resourced 1139 (Error) 1141 Figure 30: UL ACK-on-Error Receiver-Abort 1143 5. Security considerations 1145 The radio protocol authenticates and ensures the integrity of each 1146 message. This is achieved by using a unique device ID and an AES-128 1147 based message authentication code, ensuring that the message has been 1148 generated and sent by the device with the ID claimed in the message. 1150 Application data can be encrypted at the application level or not, 1151 depending on the criticality of the use case. This flexibility 1152 allows providing a balance between cost and effort vs. risk. AES-128 1153 in counter mode is used for encryption. Cryptographic keys are 1154 independent for each device. These keys are associated with the 1155 device ID and separate integrity and confidentiality keys are pre- 1156 provisioned. A confidentiality key is only provisioned if 1157 confidentiality is to be used. 1159 The radio protocol has protections against reply attacks, and the 1160 cloud-based core network provides firewalling protection against 1161 undesired incoming communications. 1163 6. Acknowledgements 1165 Carles Gomez has been funded in part by the Spanish Government 1166 through the Jose Castillejo CAS15/00336 grant, the TEC2016-79988-P 1167 grant, and the PID2019-106808RA-I00 grant, and by Secretaria 1168 d'Universitats i Recerca del Departament d'Empresa i Coneixement de 1169 la Generalitat de Catalunya 2017 through grant SGR 376. 1171 Sergio Aguilar has been funded by the ERDF and the Spanish Government 1172 through project TEC2016-79988-P and project PID2019-106808RA-I00, 1173 AEI/FEDER, EU. 1175 Sandra Cespedes has been funded in part by the ANID Chile Project 1176 FONDECYT Regular 1201893 and Basal Project FB0008. 1178 Diego Wistuba has been funded by the ANID Chile Project FONDECYT 1179 Regular 1201893. 1181 The authors would like to thank Clement Mannequin, Rafael Vidal, 1182 Julien Boite, Renaud Marty, and Antonis Platis for their useful 1183 comments and implementation design considerations. 1185 7. References 1187 7.1. Normative References 1189 [I-D.ietf-lpwan-schc-compound-ack] 1190 Zuniga, JC., Gomez, C., Aguilar, S., Toutain, L., 1191 Cespedes, S., and D. Wistuba, "SCHC Compound ACK", draft- 1192 ietf-lpwan-schc-compound-ack-00 (work in progress), July 1193 2021. 1195 [RFC8376] Farrell, S., Ed., "Low-Power Wide Area Network (LPWAN) 1196 Overview", RFC 8376, DOI 10.17487/RFC8376, May 2018, 1197 . 1199 [RFC8724] Minaburo, A., Toutain, L., Gomez, C., Barthel, D., and JC. 1200 Zuniga, "SCHC: Generic Framework for Static Context Header 1201 Compression and Fragmentation", RFC 8724, 1202 DOI 10.17487/RFC8724, April 2020, 1203 . 1205 7.2. Informative References 1207 [sigfox-callbacks] 1208 Sigfox, "Sigfox Callbacks", 1209 . 1211 [sigfox-spec] 1212 Sigfox, "Sigfox Radio Specifications", 1213 . 1216 Authors' Addresses 1217 Juan Carlos Zuniga 1218 SIGFOX 1219 Montreal QC 1220 Canada 1222 Email: JuanCarlos.Zuniga@sigfox.com 1223 URI: http://www.sigfox.com/ 1225 Carles Gomez 1226 Universitat Politecnica de Catalunya 1227 C/Esteve Terradas, 7 1228 08860 Castelldefels 1229 Spain 1231 Email: carlesgo@entel.upc.edu 1233 Sergio Aguilar 1234 Universitat Politecnica de Catalunya 1235 C/Esteve Terradas, 7 1236 08860 Castelldefels 1237 Spain 1239 Email: sergio.aguilar.romero@upc.edu 1241 Laurent Toutain 1242 IMT-Atlantique 1243 2 rue de la Chataigneraie 1244 CS 17607 1245 35576 Cesson-Sevigne Cedex 1246 France 1248 Email: Laurent.Toutain@imt-atlantique.fr 1250 Sandra Cespedes 1251 NIC Labs, Universidad de Chile 1252 Av. Almte. Blanco Encalada 1975 1253 Santiago 1254 Chile 1256 Email: scespedes@niclabs.cl 1257 Diego Wistuba 1258 NIC Labs, Universidad de Chile 1259 Av. Almte. Blanco Encalada 1975 1260 Santiago 1261 Chile 1263 Email: wistuba@niclabs.cl