idnits 2.17.1 draft-ietf-lpwan-schc-over-sigfox-08.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 11 instances of too long lines in the document, the longest one being 35 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 287: '...ntation mode, a DL opportunity MUST be...' RFC 2119 keyword, line 298: '...m All-0 or All-1 MUST NOT use the DL r...' RFC 2119 keyword, line 303: '... The RuleID MUST be included in the ...' RFC 2119 keyword, line 330: '...ss of a SCHC Packet MUST be checked at...' RFC 2119 keyword, line 340: '...eck Sequence (RCS) is NOT RECOMMENDED....' (43 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 23, 2021) is 917 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: April 26, 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 October 23, 2021 14 SCHC over Sigfox LPWAN 15 draft-ietf-lpwan-schc-over-sigfox-08 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 April 26, 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 . . . . . . . . . . . . . . . . . . . . . . . . 3 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. SCHC-Sender Abort . . . . . . . . . . . . . . . . . . . . 18 79 3.9. SCHC-Receiver Abort . . . . . . . . . . . . . . . . . . . 19 80 3.10. Padding . . . . . . . . . . . . . . . . . . . . . . . . . 19 81 4. Fragmentation Sequence Examples . . . . . . . . . . . . . . . 20 82 4.1. Uplink No-ACK Examples . . . . . . . . . . . . . . . . . 20 83 4.2. Uplink ACK-on-Error Examples: Single-byte SCHC Header . . 21 84 4.3. SCHC Abort Examples . . . . . . . . . . . . . . . . . . . 28 85 5. Security considerations . . . . . . . . . . . . . . . . . . . 30 86 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 30 87 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 31 88 7.1. Normative References . . . . . . . . . . . . . . . . . . 31 89 7.2. Informative References . . . . . . . . . . . . . . . . . 31 90 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 31 92 1. Introduction 94 The Generic Framework for Static Context Header Compression and 95 Fragmentation (SCHC) specification [RFC8724] describes two 96 mechanisms: i) a frame fragmentation and loss recovery functionality, 97 and ii) an application header compression scheme. Either can be used 98 on top of all the four LWPAN technologies defined in [RFC8376]. 99 These LPWANs have similar characteristics such as star-oriented 100 topologies, network architecture, connected devices with built-in 101 applications, etc. 103 SCHC offers a great level of flexibility to accommodate all these 104 LPWAN technologies. Even though there are a great number of 105 similarities between them, some differences exist with respect to the 106 transmission characteristics, payload sizes, etc. Hence, there are 107 optimal parameters and modes of operation that can be used when SCHC 108 is used on top of a specific LPWAN technology. 110 This document describes the recommended parameters, settings, and 111 modes of operation to be used when SCHC is implemented over a Sigfox 112 LPWAN. This set of parameters are also known as a "SCHC over Sigfox 113 profile" or simply "SCHC/Sigfox." 115 2. Terminology 117 It is assumed that the reader is familiar with the terms and 118 mechanisms defined in [RFC8376] and in [RFC8724]. 120 3. SCHC over Sigfox 122 The Generic SCHC Framework described in [RFC8724] takes advantage of 123 the predictability of data flows existing in LPWAN applications to 124 avoid context synchronization. 126 Contexts need to be stored and pre-configured on both ends. This can 127 be done either by using a provisioning protocol, by out of band 128 means, or by pre-provisioning them (e.g. at manufacturing time). The 129 way contexts are configured and stored on both ends is out of the 130 scope of this document. 132 3.1. Network Architecture 134 Figure 1 represents the architecture for compression/decompression 135 (C/D) and fragmentation/reassembly (F/R) based on the terminology 136 defined in [RFC8376], where the Radio Gateway (RG) is a Sigfox Base 137 Station and the Network Gateway (NGW) is the Sigfox cloud-based 138 Network. 140 Sigfox Device Application 141 +----------------+ +--------------+ 142 | APP1 APP2 APP3 | |APP1 APP2 APP3| 143 +----------------+ +--------------+ 144 | UDP | | | | UDP | 145 | IPv6 | | | | IPv6 | 146 +--------+ | | +--------+ 147 | SCHC C/D & F/R | | | 148 | | | | 149 +-------+--------+ +--------+-----+ 150 $ . 151 $ +---------+ +--------------+ +---------+ . 152 $ | | | | | Network | . 153 +~~ |Sigfox BS| |Sigfox Network| | SCHC | . 154 | (RG) | === | (NGW) | === |C/D & F/R|..... 155 +---------+ +--------------+ +---------+ 157 Figure 1: Network Architecture 159 In the case of the global Sigfox Network, RGs (or Base Stations) are 160 distributed over multiple countries wherever the Sigfox LPWAN service 161 is provided. The NGW (or cloud-based Sigfox Core Network) is a 162 single entity that connects to all Sigfox base stations in the world, 163 providing hence a global single star network topology. 165 The Device sends application flows that are compressed and/or 166 fragmented by a SCHC Compressor/Decompressor (SCHC C/D + F/R) to 167 reduce headers size and/or fragment the packet. The resulting SCHC 168 Message is sent over a layer two (L2) Sigfox frame to the Sigfox Base 169 Stations, which then forward the SCHC Message to the Network Gateway 170 (NGW). The NGW then delivers the SCHC Message and associated 171 gathered metadata to the Network SCHC C/D + F/R. 173 The Sigfox Network (NGW) communicates with the Network SCHC C/D + F/R 174 for compression/decompression and/or for fragmentation/reassembly. 175 The Network SCHC C/D + F/R shares the same set of rules as the Dev 176 SCHC C/D + F/R. The Network SCHC C/D + F/R can be collocated with 177 the NGW or it could be located in a different place, as long as a 178 tunnel or secured communication is established between the NGW and 179 the SCHC C/D + F/R functions. After decompression and/or reassembly, 180 the packet can be forwarded over the Internet to one (or several) 181 LPWAN Application Server(s) (App). 183 The SCHC C/D + F/R processes are bidirectional, so the same 184 principles are applicable on both uplink (UL) and downlink (DL). 186 3.2. Uplink 188 Uplink Sigfox transmissions occur in repetitions over different times 189 and frequencies. Besides time and frequency diversities, the Sigfox 190 network also provides space diversity, as potentially an uplink 191 message will be received by several base stations. 193 Since all messages are self-contained and base stations forward all 194 these messages back to the same Sigfox Network, multiple input copies 195 can be combined at the NGW providing for extra reliability based on 196 the triple diversity (i.e., time, space and frequency). 198 A detailed description of the Sigfox Radio Protocol can be found in 199 [sigfox-spec]. 201 Messages sent from the Device to the Network are delivered by the 202 Sigfox network (NGW) to the Network SCHC C/D + F/R through a 203 callback/API with the following information: 205 o Device ID 207 o Message Sequence Number 209 o Message Payload 211 o Message Timestamp 213 o Device Geolocation (optional) 215 o RSSI (optional) 217 o Device Temperature (optional) 219 o Device Battery Voltage (optional) 221 The Device ID is a globally unique identifier assigned to the Device, 222 which is included in the Sigfox header of every message. The Message 223 Sequence Number is a monotonically increasing number identifying the 224 specific transmission of this uplink message, and it is also part of 225 the Sigfox header. The Message Payload corresponds to the payload 226 that the Device has sent in the uplink transmission. 228 The Message Timestamp, Device Geolocation, RSSI, Device Temperature 229 and Device Battery Voltage are metadata parameters provided by the 230 Network. 232 A detailed description of the Sigfox callbacks/APIs can be found in 233 [sigfox-callbacks]. 235 Only messages that have passed the L2 Cyclic Redundancy Check (CRC) 236 at network reception are delivered by the Sigfox Network to the 237 Network SCHC C/D + F/R. 239 +---------------+-----------------+ 240 | Sigfox Header | Sigfox payload | 241 +---------------+---------------- + 242 | SCHC message | 243 +-----------------+ 245 Figure 2: SCHC Message in Sigfox 247 Figure 2 shows a SCHC Message sent over Sigfox, where the SCHC 248 Message could be a full SCHC Packet (e.g. compressed) or a SCHC 249 Fragment (e.g. a piece of a bigger SCHC Packet). 251 3.3. Downlink 253 Downlink transmissions are Device-driven and can only take place 254 following an uplink communication that so indicates. Hence, a Device 255 explicitly indicates its intention to receive a downlink message 256 using a donwlink request flag when sending the preceding uplink 257 message to the network. After completing the uplink transmission, 258 the Device opens a fixed window for downlink reception. The delay 259 and duration of the reception opportunity window have fixed values. 260 If there is a downlink message to be sent for this given Device (e.g. 261 either a response to the uplink message or queued information waiting 262 to be transmitted), the network transmits this message to the Device 263 during the reception window. If no message is received by the Device 264 after the reception opportunity window has elapsed, the Device closes 265 the reception window opportunity and gets back to the normal mode 266 (e.g., continue UL transmissions, sleep, stand-by, etc.) 268 When a downlink message is sent to a Device, a reception 269 acknowledgement is generated by the Device and sent back to the 270 Network through the Sigfox radio protocol and reported in the Sigfox 271 Network backend. 273 A detailed description of the Sigfox Radio Protocol can be found in 274 [sigfox-spec] and a detailed description of the Sigfox callbacks/APIs 275 can be found in [sigfox-callbacks]. 277 3.4. SCHC-ACK on Downlink 279 As explained previously, downlink transmissions are Device-driven and 280 can only take place following a specific uplink transmission that 281 indicates and allows a following downlink opportunity. For this 282 reason, when SCHC bi-directional services are used (e.g. Ack-on- 283 Error fragmentation mode) the SCHC protocol implementation needs to 284 consider the times when a downlink message (e.g. SCHC-ACK) can be 285 sent and/or received. 287 For the UL ACK-on-Error fragmentation mode, a DL opportunity MUST be 288 indicated by the last fragment of every window (i.e. FCN = All-0, or 289 FCN = All-1). The Device sends the fragments in sequence and, after 290 transmitting the FCN = All-0 or FCN = All-1, it opens up a reception 291 opportunity. The Network SCHC can then decide to respond at that 292 opportunity (or wait for a further one) with a SCHC-ACK indicating in 293 case there are missing fragments from the current or previous 294 windows. If there is no SCHC-ACK to be sent, or if the network 295 decides to wait for a further DL transmission opportunity, then no DL 296 transmission takes place at that opportunity and after a timeout the 297 UL transmissions continue. Intermediate SCHC fragments with FCN 298 different from All-0 or All-1 MUST NOT use the DL request flag to 299 request a SCHC-ACK. 301 3.5. SCHC Rules 303 The RuleID MUST be included in the SCHC header. The total number of 304 rules to be used affects directly the Rule ID field size, and 305 therefore the total size of the fragmentation header. For this 306 reason, it is recommended to keep the number of rules that are 307 defined for a specific device to the minimum possible. 309 RuleIDs can be used to differentiate data traffic classes (e.g. QoS, 310 control vs. data, etc.), and data sessions. They can also be used to 311 interleave simultaneous fragmentation sessions between a Device and 312 the Network. 314 3.6. Fragmentation 316 The SCHC specification [RFC8724] defines a generic fragmentation 317 functionality that allows sending data packets or files larger than 318 the maximum size of a Sigfox payload. The functionality also defines 319 a mechanism to send reliably multiple messages, by allowing to resend 320 selectively any lost fragments. 322 The SCHC fragmentation supports several modes of operation. These 323 modes have different advantages and disadvantages depending on the 324 specifics of the underlying LPWAN technology and application Use 325 Case. This section describes how the SCHC fragmentation 326 functionality should optimally be implemented when used over a Sigfox 327 LPWAN for the most typical Use Case applications. 329 As described in section 8.2.3 of [RFC8724], the integrity of the 330 fragmentation-reassembly process of a SCHC Packet MUST be checked at 331 the receive end. Since only UL messages/fragments that have passed 332 the CRC-check are delivered to the Network SCHC C/D + F/R, and each 333 one has an associated Sigfox Message Sequence Number (see 334 Section 3.2), integrity can be guaranteed when no consecutive 335 messages are missing from the sequence and all FCN bitmaps are 336 complete. In order to support multiple flows/RuleIDs (potentially 337 interleaved), the implementation of a central message sequence 338 counter at the Network SCHC C/D + F/R is required. With this 339 functionality and in order to save protocol overhead, the use of a 340 dedicated Reassembly Check Sequence (RCS) is NOT RECOMMENDED. 342 The L2 Word Size used by Sigfox is 1 byte (8 bits). 344 3.6.1. Uplink Fragmentation 346 Sigfox uplink transmissions are completely asynchronous and take 347 place in any random frequency of the allowed uplink bandwidth 348 allocation. In addition, devices may go to deep sleep mode, and then 349 wake up and transmit whenever there is a need to send information to 350 the network. Data packets are self-contained (aka "message in a 351 bottle") with all the required information for the network to process 352 them accordingly. Hence, there is no need to perform any network 353 attachment, synchronization, or other procedure before transmitting a 354 data packet. 356 Since uplink transmissions are asynchronous, a SCHC fragment can be 357 transmitted at any given time by the Device. Sigfox uplink messages 358 are fixed in size, and as described in [RFC8376] they can carry 0-12 359 bytes payload. Hence, a single SCHC Tile size per fragmentation mode 360 can be defined so that every Sigfox message always carries one SCHC 361 Tile. 363 When the ACK-on-Error mode is used for uplink fragmentation, the SCHC 364 Compound ACK defined in [I-D.ietf-lpwan-schc-compound-ack]) MUST be 365 used in the downlink responses. 367 3.6.1.1. Uplink No-ACK Mode 369 No-ACK is RECOMMENDED to be used for transmitting short, non-critical 370 packets that require fragmentation and do not require full 371 reliability. This mode can be used by uplink-only devices that do 372 not support downlink communications, or by bidirectional devices when 373 they send non-critical data. 375 Since there are no multiple windows in the No-ACK mode, the W bit is 376 not present. However it is RECOMMENDED to use the FCN field to 377 indicate the size of the data packet. In this sense, the data packet 378 would need to be splitted into X fragments and, similarly to the 379 other fragmentation modes, the first transmitted fragment would need 380 to be marked with FCN = X-1. Consecutive fragments MUST be marked 381 with decreasing FCN values, having the last fragment marked with FCN 382 = (All-1). Hence, even though the No-ACK mode does not allow 383 recovering missing fragments, it allows indicating implicitly the 384 size of the expected packet to the Network and hence detect at the 385 receiver side whether all fragments have been received or not. 387 The RECOMMENDED Fragmentation Header size is 8 bits, and it is 388 composed as follows: 390 o RuleID size: 4 bits 392 o DTag size (T): 0 bits 394 o Fragment Compressed Number (FCN) size (N): 4 bits 396 o As per [RFC8724], in the No-ACK mode the W (window) field is not 397 present. 399 o RCS size: 0 bits (Not used) 401 3.6.1.2. Uplink ACK-on-Error Mode: Single-byte SCHC Header 403 ACK-on-Error with single-byte header is RECOMMENDED for medium to 404 large size packets that need to be sent reliably. ACK-on-Error is 405 optimal for Sigfox transmissions, since it leads to a reduced number 406 of ACKs in the lower capacity downlink channel. Also, downlink 407 messages can be sent asynchronously and opportunistically. 409 Allowing transmission of packets/files up to 300 bytes long, the SCHC 410 uplink Fragmentation Header size is RECOMMENDED to be 8 bits in size 411 and is composed as follows: 413 o Rule ID size: 3 bits 415 o DTag size (T): 0 bits 417 o Window index (W) size (M): 2 bits 419 o Fragment Compressed Number (FCN) size (N): 3 bits 420 o MAX_ACK_REQUESTS: 5 422 o WINDOW_SIZE: 7 (with a maximum value of FCN=0b110) 424 o Tile size: 11 bytes 426 o Retransmission Timer: Application-dependent 428 o Inactivity Timer: Application-dependent 430 o RCS size: 0 bits (Not used) 432 The correspondent SCHC ACK in the downlink is 13 bits long, so 433 padding is needed to complete the required 64 bits of Sigfox payload. 435 3.6.1.3. Uplink ACK-on-Error Mode: Two-byte SCHC Header 437 ACK-on-Error with two-byte header is RECOMMENDED for very large size 438 packets that need to be sent reliably. ACK-on-Error is optimal for 439 Sigfox transmissions, since it leads to a reduced number of ACKs in 440 the lower capacity downlink channel. Also, downlink messages can be 441 sent asynchronously and opportunistically. 443 In order to allow transmission of very large packets/files up to 2250 444 bytes long, the SCHC uplink Fragmentation Header size is RECOMMENDED 445 to be 16 bits in size and composed as follows: 447 o Rule ID size is: 8 bits 449 o DTag size (T) is: 0 bits 451 o Window index (W) size (M): 3 bits 453 o Fragment Compressed Number (FCN) size (N): 5 bits. 455 o MAX_ACK_REQUESTS: 5 457 o WINDOW_SIZE: 31 (with a maximum value of FCN=0b11110) 459 o Tile size: 10 bytes 461 o Retransmission Timer: Application-dependent 463 o Inactivity Timer: Application-dependent 465 o RCS size: 0 bits (Not used) 466 The correspondent SCHC ACK in the downlink is 43 bits long, so 467 padding is needed to complete the required 64 bits of Sigfox payload. 469 3.6.1.4. All-1 behaviour + Sigfox Sequence Number 471 For ACK-on-Error, as defined in [RFC8724], it is expected that the 472 last SCHC fragment of the last window will always be delivered with 473 an All-1 FCN. Since this last window may not be full (i.e. it may be 474 comprised of less than WINDOW_SIZE fragments), an All-1 fragment may 475 follow a value of FCN higher than 1 (0b01). In this case, the 476 receiver could not derive from the FCN values alone whether there are 477 any missing fragments right before the All-1 fragment or not. 479 However, since a Message Sequence Number is provided by the Sigfox 480 protocol together with the Sigfox Payload, the receiver can detect if 481 there are missing fragments before the All-1 and hence construct the 482 corresponding SCHC ACK Bitmap accordingly. 484 3.6.2. Downlink Fragmentation 486 In some LPWAN technologies, as part of energy-saving techniques, 487 downlink transmission is only possible immediately after an uplink 488 transmission. This allows the device to go in a very deep sleep mode 489 and preserve battery, without the need to listen to any information 490 from the network. This is the case for Sigfox-enabled devices, which 491 can only listen to downlink communications after performing an uplink 492 transmission and requesting a downlink. 494 When there are fragments to be transmitted in the downlink, an uplink 495 message is required to trigger the downlink communication. In order 496 to avoid potentially high delay for fragmented datagram transmission 497 in the downlink, the fragment receiver MAY perform an uplink 498 transmission as soon as possible after reception of a downlink 499 fragment that is not the last one. Such uplink transmission MAY be 500 triggered by sending a SCHC message, such as a SCHC ACK. However, 501 other data messages can equally be used to trigger DL communications. 503 Sigfox downlink messages are fixed in size, and as described in 504 [RFC8376] they can carry up to 8 bytes payload. Hence, a single SCHC 505 Tile size per mode can be defined so that every Sigfox message always 506 carries one SCHC Tile. 508 For reliable downlink fragment transmission, the ACK-Always mode is 509 RECOMMENDED. 511 The SCHC downlink Fragmentation Header size is RECOMMENDED to be 8 512 bits in size and is composed as follows: 514 o RuleID size: 3 bits 516 o DTag size (T): 0 bits 518 o Window index (W) size (M) is: 0 bits 520 o Fragment Compressed Number (FCN) size (N): 5 bits 522 o MAX_ACK_REQUESTS: 5 524 o WINDOW_SIZE: 31 (with a maximum value of FCN=0b11110) 526 o Tile size: 7 bytes 528 o Retransmission Timer: Application-dependent 530 o Inactivity Timer: Application-dependent 532 o RCS size: 0 bits (Not used) 534 3.7. SCHC-over-Sigfox F/R Message Formats 536 This section depicts the different formats of SCHC Fragment, SCHC ACK 537 (including the SCHC Compound ACK defined in 538 [I-D.ietf-lpwan-schc-compound-ack]), and SCHC Abort used in SCHC over 539 Sigfox. 541 3.7.1. Uplink ACK-on-Error Mode: Single-byte SCHC Header 543 3.7.1.1. Regular SCHC Fragment 545 Figure 3 shows an example of a regular SCHC fragment for all 546 fragments except the last one. As tiles are of 11 bytes, padding 547 MUST NOT be added. 549 |-- SCHC Fragment Header --| 550 + ------------------------ + ------- + 551 | RuleID | W | FCN | Payload | 552 + ------ + ------ + ------ + ------- + 553 | 3 bits | 2 bits | 3 bits | 88 bits | 555 Figure 3: Regular SCHC Fragment format for all fragments except the 556 last one 558 The use of SCHC ACK REQ is NOT RECOMMENDED, instead the All-1 SCHC 559 Fragment SHOULD be used to request a SCHC ACK from the receiver 560 (Network SCHC). As per [RFC8724], the All-0 message is 561 distinguishable from the SCHC ACK REQ (All-1 message). The 562 penultimate tile of a SCHC Packet is of regular size. 564 3.7.1.2. All-1 SCHC Fragment 566 Figure 4 shows an example of the All-1 message. The All-1 message 567 MUST contain the last tile of the SCHC Packet. The last tile MUST be 568 of at least 1 byte (one L2 word). Padding MUST NOT be added, as the 569 resulting size is L2-word-multiple. 571 |--- SCHC Fragment Header ---| 572 + --------------------------- + ------------ + 573 | RuleID | W | FCN=ALL-1 | Payload | 574 + ------ + ------ + --------- + ------------ + 575 | 3 bits | 2 bits | 3 bits | 8 to 88 bits | 577 Figure 4: All-1 SCHC Message format with last tile 579 As per [RFC8724] the All-1 must be distinguishable from a SCHC 580 Sender-Abort message (with same Rule ID, M, and N values). The All-1 581 MUST have the last tile of the SCHC Packet, which MUST be of at least 582 1 byte. The SCHC Sender-Abort message header size is of 1 byte, with 583 no padding bits. 585 For the All-1 message to be distinguishable from the Sender-Abort 586 message, the Sender-Abort message MUST be of 1 byte (only header with 587 no padding). This way, the minimum size of the All-1 is 2 bytes, and 588 the Sender-Abort message is 1 byte. 590 3.7.1.3. SCHC ACK Format 592 Figure 5 shows the SCHC ACK format when all fragments have been 593 correctly received (C=1). Padding MUST be added to complete the 594 64-bit Sigfox downlink frame payload size. 596 |---- SCHC ACK Header ----| 597 + ----------------------- + ------- + 598 | RuleID | W | C=b'1 | b'0-pad | 599 + ------ + ------ + ----- + ------- + 600 | 3 bits | 2 bits | 1 bit | 58 bits | 602 Figure 5: SCHC Success ACK message format 604 In case SCHC fragment losses are found in any of the windows of the 605 SCHC Packet (C=0), the SCHC Compound ACK defined in 606 [I-D.ietf-lpwan-schc-compound-ack] MUST be used. The SCHC Compound 607 ACK message format is shown in Figure 6. The window numbered 00, if 608 present in the SCHC Compound ACK, MUST be placed between the Rule ID 609 and the C bit to avoid confusion with padding bits. As padding is 610 needed for the SCHC Compound ACK, padding bits MUST be 0 to make 611 subsequent window numbers and bitmaps distinguishable. 613 |---- SCHC ACK Header ----|-W = x -|...| --- W = x + i ---| 614 + ----------------------- + ------ +...+ ------- + ------ + ------- + 615 | RuleID | W=b'x | C=b'0 | Bitmap |...| W=b'x+i | Bitmap | b'0-pad | 616 + ------ + ------ + ----- + ------ +...+ ------- + ------ + ------- + 617 | 3 bits | 2 bits | 1 bit | 7 bits | | 2 bits | 7 bits | 619 On top are noted the window number of the corresponding bitmap. 620 Losses are found in windows x,...,x+i. 622 Figure 6: SCHC Compound ACK message format 624 The following figures show examples of the SCHC Compound ACK message 625 format, when used on SCHC over Sigfox. 627 |---- SCHC ACK Header ----|- W=00 -|----- W=01 ------| 628 + ----------------------- + ------ + ------ + ------ + ------- + 629 | RuleID | W=b'00 | C=b'0 | Bitmap | W=b'01 | Bitmap | b'0-pad | 630 + ------ + ------ + ----- + ------ + ------ + ------ + ------- + 631 | 3 bits | 2 bits | 1 bit | 7 bits | 2 bits | 7 bits | 42 bits | 633 Losses are found in windows 00 and 01. 635 Figure 7: SCHC Compound ACK example 1 637 |---- SCHC ACK Header ----|- W=01 -|----- W=11 ------| 638 + ----------------------- + ------ + ------ + ------ + ------- + 639 | RuleID | W=b'01 | C=b'0 | Bitmap | W=b'11 | Bitmap | b'0-pad | 640 + ------ + ------ + ----- + ------ + ------ + ------ + ------- + 641 | 3 bits | 2 bits | 1 bit | 7 bits | 2 bits | 7 bits | 42 bits | 643 Losses are found in windows 01 and 11. 645 Figure 8: SCHC Compound ACK example 2 647 |---- SCHC ACK Header ----|- W=00 -|----- W=10 ------| 648 + ----------------------- + ------ + ------ + ------ + ------- + 649 | RuleID | W=b'00 | C=b'0 | Bitmap | W=b'10 | Bitmap | b'0-pad | 650 + ------ + ------ + ----- + ------ + ------ + ------ + ------- + 651 | 3 bits | 2 bits | 1 bit | 7 bits | 2 bits | 7 bits | 42 bits | 653 Losses are found in windows 00 and 10. 655 Figure 9: SCHC Compound ACK example 3 657 Figure 10 shows the SCHC Compound ACK message format when losses are 658 found in all windows. The window numbers and its corresponding 659 bitmaps are ordered from window numbered 00 to 11, notifying all four 660 possible windows. 662 |- SCHC ACK Header -|W=b'00|-- W=b'01 ---| 663 +-------------------+------+ ---- +------+ 664 |RuleID|W=b'00|C=b'0|Bitmap|W=b'01|Bitmap| ... 665 +------+------+-----+------+------+------+ 666 |3 bits|2 bits|1 bit|7 bits|2 bits|7 bits| 668 |--- W=b'10 --|--- W=b'11 --| 669 |------+------+------+------+-------+ 670 ... |W=b'10|Bitmap|W=b'11|Bitmap|b'0-pad| 671 |------+------+------+------+-------+ 672 |2 bits|7 bits|2 bits|7 bits|24 bits| 674 Losses are found in windows 00, 01, 10 and 11. 676 Figure 10: SCHC Compound ACK example 4 678 |- SCHC ACK Header -|W=b'00|-- W=b'01 ---|--- W=b'10 --| 679 +-------------------+------+------+------+------+------+-------+ 680 |RuleID|W=b'00|C=b'0|Bitmap|W=b'01|Bitmap|W=b'10|Bitmap|b'0-pad| 681 +------+------+-----+------+------+------+------+------+-------+ 682 |3 bits|2 bits|1 bit|7 bits|2 bits|7 bits|2 bits|7 bits|33 bits| 684 Losses are found in windows 00, 01 and 10. 686 Figure 11: SCHC Compound ACK example 5 688 3.7.1.4. SCHC Sender-Abort Message format 690 |---- Sender-Abort Header ----| 691 + --------------------------- + 692 | RuleID | W | FCN=ALL-1 | 693 + ------ + ------ + --------- + 694 | 3 bits | 2 bits | 3 bits | 696 Figure 12: SCHC Sender-Abort message format 698 3.7.1.5. SCHC Receiver-Abort Message format 700 |- Receiver-Abort Header -| 701 + ----------------------- + ------- + 702 | RuleID | W=b'11 | C=b'1 | b'1-pad | 703 + ------ + ------ + ----- + ------- + 704 | 3 bits | 2 bits | 1 bit | 58 bits | 706 Figure 13: SCHC Receiver-Abort message format 708 3.7.2. Uplink ACK-on-Error Mode: Two-byte SCHC Header 710 3.7.2.1. Regular SCHC Fragment 712 Figure 14 shows an example of a regular SCHC fragment for all 713 fragments except the last one. The penultimate tile of a SCHC Packet 714 is of the regular size. 716 |-- SCHC Fragment Header --| 717 + ------------------------ + ------- + 718 | RuleID | W | FCN | Payload | 719 + ------ + ------ + ------ + ------- + 720 | 8 bits | 3 bits | 5 bits | 80 bits | 722 Figure 14: Regular SCHC Fragment format for all fragments except the 723 last one 725 The use of SCHC ACK is NOT RECOMMENDED, instead the All-1 SCHC 726 Fragment SHOULD be used to request a SCHC ACK from the receiver 727 (Network SCHC). As per [RFC8724], the All-0 message is 728 distinguishable from the SCHC ACK REQ (All-1 message). 730 3.7.2.2. All-1 SCHC Fragment 732 Figure 15 shows an example of the All-1 message. The All-1 message 733 MUST contain the last tile of the SCHC Packet. 735 |--- SCHC Fragment Header ---| 736 + --------------------------- + ------------ + 737 | RuleID | W | FCN=ALL-1 | Payload | 738 + ------ + ------ + --------- + ------------ + 739 | 8 bits | 3 bits | 5 bits | 8 to 80 bits | 741 Figure 15: All-1 SCHC message format with last tile 743 As per [RFC8724] the All-1 must be distinguishable from the a SCHC 744 Sender-Abort message (with same Rule ID, M and N values). The All-1 745 MUST have the last tile of the SCHC Packet, that MUST be of at least 746 1 byte. The SCHC Sender-Abort message header size is of 2 byte, with 747 no padding bits. 749 For the All-1 message to be distinguishable from the Sender-Abort 750 message, the Sender-Abort message MUST be of 2 byte (only header with 751 no padding). This way, the minimum size of the All-1 is 3 bytes, and 752 the Sender-Abort message is 2 bytes. 754 3.7.2.3. SCHC ACK Format 756 Figure 16 shows the SCHC ACK format when all fragments have been 757 correctly received (C=1). Padding MUST be added to complete the 758 64-bit Sigfox downlink frame payload size. 760 |----- SCHC ACK Header ----| 761 + ------------------------ + ------ + 762 | RuleID | W | C=b'1 | b'0-pad | 763 + ------ + ------ + ----- + ------- + 764 | 8 bits | 3 bits | 1 bit | 52 bits | 766 Figure 16: SCHC Success ACK message format 768 The SCHC Compound ACK message MUST be used in case SCHC fragment 769 losses are found in any window of the SCHC Packet (C=0). The SCHC 770 Compound ACK message format is shown in Figure 17. The SCHC Compound 771 ACK can report up to 3 windows with losses. The window number (W) 772 and its corresponding bitmap MUST be ordered from the lowest-numbered 773 window number to the highest-numbered window. If window numbered 000 774 is present in the SCHC Compound ACK, the window number 000 MUST be 775 placed between the Rule ID and C bit to avoid confusion with padding 776 bits. The SCHC Compound ACK MUST be 0 padded (Padding bits must be 777 0). 779 |- SCHC ACK Header -| W=b'x |...|--- W=b'x+i ---| 780 +-------------------+-------+...+-------+-------+-------+ 781 |RuleID|W=b'x |C=b'0|Bitmap |...|W=b'x+i|Bitmap |b'0-pad| 782 +------+------+-----+-------+...|-------+-------+-------+ 783 |8 bits|3 bits|1 bit|31 bits| | 3 bits|31 bits| 785 On top are noted the window number 786 of the corresponding bitmap. 787 Losses are found in windows x,...,x+i. 789 Figure 17: SCHC Compound ACK message format 791 3.7.2.4. SCHC Sender-Abort Messages 793 |---- Sender-Abort Header ----| 794 + --------------------------- + 795 | RuleID | W | FCN=ALL-1 | 796 + ------ + ------ + --------- + 797 | 8 bits | 3 bits | 5 bits | 799 Figure 18: SCHC Sender-Abort message format 801 3.7.2.5. SCHC Receiver-Abort Message 803 |-- Receiver-Abort Header -| 804 + ------------------------ + ------- + 805 | RuleID | W=b'111 | C=b'1 | b'1-pad | 806 + ------ + ------- + ----- + ------- + 807 | 8 bits | 3 bits | 1 bit | 52 bits | 809 Figure 19: SCHC Receiver-Abort message format 811 3.8. SCHC-Sender Abort 813 o As defined in [RFC8724], a SCHC-Sender Abort can be triggered when 814 the number of SCHC ACK REQ attempts is greater than or equal to 815 MAX_ACK_REQUESTS. In the case of SCHC/Sigfox, a SCHC-Sender Abort 816 MUST be sent if the number of repeated All-1s sent in a row is 817 greater than or equal to MAX_ACK_REQUESTS. 819 o The MAX_ACK_REQUEST counter MUST be reset when a SCHC ACK is 820 successfully received. 822 3.9. SCHC-Receiver Abort 824 o As defined in [RFC8724], a SCHC-Receiver Abort is triggered when 825 the receiver has no RuleID and DTag pairs available for a new 826 session. In the case of SCHC/Sigfox a SCHC-Receiver Abort MUST be 827 sent if, for a single device, all the RuleIDs are being processed 828 by the receiver (i.e., have an active session) at a certain time, 829 or if the RuleID of the fragment is not valid. 831 o A SCHC-Receiver Abort MUST be triggered when the Inactivity Timer 832 expires. 834 o A SCHC-Receiver Abort can be triggered when the number of ACK 835 attempts is not strictly less than MAX_ACK_REQUESTS. In the case 836 of SCHC/Sigfox, a SCHC-Receiver Abort MUST be sent if the number 837 of repeated SCHC ACKs sent in a row (i.e., synchronized with the 838 ACK REQ case) is greater than or equal to MAX_ACK_REQUESTS. 840 o For SCHC/Sigfox implementations, the MAX_ACK_REQUESTS counter MUST 841 be reset when a SCHC ACK is successfully received. 843 o Although a SCHC-Receiver Abort can be triggered at any point in 844 time, a SCHC-Receiver Abort downlink message MUST only be sent 845 when there is a downlink transmission opportunity. 847 3.10. 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 4. 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 4.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 4.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 Fragment losses 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 a SCHC ACK with the corresponding bitmap and 949 C=0. 951 After the loss fragments from the first window (W=0) are resent, the 952 sender continues transmitting the fragments of the following window 953 (W=1) without opening a reception opportunity. Finally, the All-1 954 fragment is sent, the downlink is enabled, and the SCHC ACK is 955 received with C=1. 957 Sender Receiver 958 |-----W=0, FCN=6, Seq=1----->| 959 |-----W=0, FCN=5, Seq=2--X-->| 960 |-----W=0, FCN=4, Seq=3----->| 961 |-----W=0, FCN=3, Seq=4----->| 962 |-----W=0, FCN=2, Seq=5--X-->| 963 |-----W=0, FCN=1, Seq=6----->| 964 DL Enable |-----W=0, FCN=0, Seq=7----->| Missing Fragments W=0 => FCN=5, Seq=2 and FCN=2, Seq=5 965 |<------ ACK, W=0, C=0 ------| Bitmap:1011011 966 |-----W=0, FCN=5, Seq=8----->| 967 |-----W=0, FCN=2, Seq=9----->| 968 |-----W=1, FCN=6, Seq=10---->| 969 |-----W=1, FCN=5, Seq=11---->| 970 |-----W=1, FCN=4, Seq=12---->| 971 DL Enable |-----W=1, FCN=7, Seq=13---->| All fragments received 972 |<------ ACK, W=1, C=1 ------| C=1 973 (End) 975 Figure 23: UL ACK-on-Error Losses on First Window 977 Case Fragment All-0 lost in first window (W=0) 979 In this example, the All-0 of the first window (W=0) is lost. 980 Therefore, the Receiver waits for the next All-0 message of 981 intermediate windows, or All-1 message of last window to generate the 982 corresponding SCHC ACK, notifying the absence of the All-0 of window 983 0. 985 The sender resends the missing All-0 messages (with any other missing 986 fragment from window 0) without opening a reception opportunity. 988 Sender Receiver 989 |-----W=0, FCN=6, Seq=1----->| 990 |-----W=0, FCN=5, Seq=2----->| 991 |-----W=0, FCN=4, Seq=3----->| 992 |-----W=0, FCN=3, Seq=4----->| 993 |-----W=0, FCN=2, Seq=5----->| 994 |-----W=0, FCN=1, Seq=6----->| DL Enable 995 |-----W=0, FCN=0, Seq=7--X-->| 996 (no ACK) 997 |-----W=1, FCN=6, Seq=8----->| 998 |-----W=1, FCN=5, Seq=9----->| 999 |-----W=1, FCN=4, Seq=10---->| 1000 DL Enable |-----W=1, FCN=7, Seq=11---->| Missing Fragment W=0, FCN=0, Seq=7 1001 |<------ ACK, W=0, C=0 ------| Bitmap:1111110 1002 |-----W=0, FCN=0, Seq=13---->| All fragments received 1003 DL Enable |-----W=1, FCN=7, Seq=14---->| 1004 |<------ ACK, W=1, C=1 ------| C=1 1005 (End) 1007 Figure 24: UL ACK-on-Error All-0 Lost on First Window 1009 In the following diagram, besides the All-0 there are other fragment 1010 losses in the first window (W=0). 1012 Sender Receiver 1013 |-----W=0, FCN=6, Seq=1----->| 1014 |-----W=0, FCN=5, Seq=2--X-->| 1015 |-----W=0, FCN=4, Seq=3----->| 1016 |-----W=0, FCN=3, Seq=4--X-->| 1017 |-----W=0, FCN=2, Seq=5----->| 1018 |-----W=0, FCN=1, Seq=6----->| 1019 DL Enable |-----W=0, FCN=0, Seq=7--X-->| 1020 (no ACK) 1021 |-----W=1, FCN=6, Seq=8----->| 1022 |-----W=1, FCN=5, Seq=9----->| 1023 |-----W=1, FCN=4, Seq=10---->| 1024 DL Enable |-----W=1, FCN=7, Seq=11---->| Missing Fragment W=0 => FCN= 5, 3 and 0 1025 |<------ ACK, W=0, C=0 ------| Bitmap:1010110 1026 |-----W=0, FCN=5, Seq=13---->| 1027 |-----W=0, FCN=3, Seq=14---->| 1028 |-----W=0, FCN=0, Seq=15---->| All fragments received 1029 DL Enable |-----W=1, FCN=7, Seq=16---->| 1030 |<------ ACK, W=1, C=1 ------| C=1 1031 (End) 1033 Figure 25: UL ACK-on-Error All-0 and other Fragments Lost on First 1034 Window 1036 In the next examples, there are fragment losses in both the first 1037 (W=0) and second (W=1) windows. The retransmission cycles after the 1038 All-1 is sent (i.e., not in intermediate windows) should always 1039 finish with an with an All-1, as it serves as an ACK Request message 1040 to confirm the correct reception of the retransmitted fragments. 1042 Sender Receiver 1043 |-----W=0, FCN=6 (110), Seq=1----->| 1044 |-----W=0, FCN=5 (101), Seq=2--X-->| 1045 |-----W=0, FCN=4 (100), Seq=3----->| 1046 |-----W=0, FCN=3 (011), Seq=4--X-->| 1047 |-----W=0, FCN=2 (010), Seq=5----->| 1048 |-----W=0, FCN=1 (001), Seq=6----->| 1049 DL enable |-----W=0, FCN=0 (000), Seq=7--X-->| 1050 (no ACK) 1051 |-----W=1, FCN=6 (110), Seq=8--X-->| 1052 |-----W=1, FCN=5 (101), Seq=9----->| 1053 |-----W=1, FCN=4 (011), Seq=10-X-->| 1054 DL enable |-----W=1, FCN=7 (111), Seq=11---->| Missing Fragment W=0 => FCN= 5, 3 and 0, W=1 => FCN= 6 and 4 1055 |<--- Compound ACK, W=0,1, C=0 ----| Bitmap W=0:1010110, Bitmap W=1:0100001 1056 |-----W=0, FCN=5 (101), Seq=13---->| 1057 |-----W=0, FCN=3 (011), Seq=14---->| 1058 |-----W=0, FCN=0 (000), Seq=15---->| 1059 |-----W=1, FCN=6 (110), Seq=16---->| 1060 |-----W=1, FCN=4 (011), Seq=17---->| All fragments received 1061 DL enable |-----W=1, FCN=7 (111), Seq=18---->| 1062 |<--------- ACK, W=1, C=1 ---------| C=1 1063 (End) 1065 Figure 26: UL ACK-on-Error All-0 and other Fragments Lost on First 1066 and Second Windows (1) 1068 Similar case as above, but with less fragments in the second window 1069 (W=1) 1070 Sender Receiver 1071 |-----W=0, FCN=6 (110), Seq=1----->| 1072 |-----W=0, FCN=5 (101), Seq=2--X-->| 1073 |-----W=0, FCN=4 (100), Seq=3----->| 1074 |-----W=0, FCN=3 (011), Seq=4--X-->| 1075 |-----W=0, FCN=2 (010), Seq=5----->| 1076 |-----W=0, FCN=1 (001), Seq=6----->| 1077 DL enable |-----W=0, FCN=0 (000), Seq=7--X-->| 1078 (no ACK) 1079 |-----W=1, FCN=6 (110), Seq=8--X-->| 1080 DL enable |-----W=1, FCN=7 (111), Seq=9----->| Missing Fragment W=0 => FCN= 5, 3 and 0, W=1 => FCN= 6 and 4 1081 |<--- Compound ACK, W=0,1, C=0 ----| Bitmap W=0:1010110, Bitmap W=1:0000001 1082 |-----W=0, FCN=5 (101), Seq=10---->| 1083 |-----W=0, FCN=3 (011), Seq=11---->| 1084 |-----W=0, FCN=0 (000), Seq=12---->| 1085 |-----W=1, FCN=6 (110), Seq=13---->| All fragments received 1086 DL enable |-----W=1, FCN=7 (111), Seq=14---->| 1087 |<--------- ACK, W=1, C=1 ---------| C=1 1088 (End) 1090 Figure 27: UL ACK-on-Error All-0 and other Fragments Lost on First 1091 and Second Windows (2) 1093 Case SCHC ACK is lost 1095 SCHC over Sigfox does not implement the SCHC ACK REQ message. 1096 Instead it uses the SCHC All-1 message to request a SCHC ACK, when 1097 required. 1099 Sender Receiver 1100 |-----W=0, FCN=6, Seq=1----->| 1101 |-----W=0, FCN=5, Seq=2----->| 1102 |-----W=0, FCN=4, Seq=3----->| 1103 |-----W=0, FCN=3, Seq=4----->| 1104 |-----W=0, FCN=2, Seq=5----->| 1105 |-----W=0, FCN=1, Seq=6----->| 1106 DL Enable |-----W=0, FCN=0, Seq=7----->| 1107 (no ACK) 1108 |-----W=1, FCN=6, Seq=8----->| 1109 |-----W=1, FCN=5, Seq=9----->| 1110 |-----W=1, FCN=4, Seq=10---->| 1111 DL Enable |-----W=1, FCN=7, Seq=11---->| All fragments received 1112 |<------ ACK, W=1, C=1 ---X--| C=1 1113 DL Enable |-----W=1, FCN=7, Seq=13---->| RESEND ACK 1114 |<------ ACK, W=1, C=1 ------| C=1 1115 (End) 1117 Figure 28: UL ACK-on-Error ACK Lost 1119 Case SCHC Compound ACK at the end 1121 In this example, SCHC Fragment losses are found in both windows 0 and 1122 1. However, the sender does not send a SCHC ACK after the All-0 of 1123 window 0. Instead, it sends a SCHC Compound ACK notifying losses of 1124 both windows. 1126 Sender Receiver 1127 |-----W=0, FCN=6 (110), Seq=1----->| 1128 |-----W=0, FCN=5 (101), Seq=2--X-->| 1129 |-----W=0, FCN=4 (100), Seq=3----->| 1130 |-----W=0, FCN=3 (011), Seq=4--X-->| 1131 |-----W=0, FCN=2 (010), Seq=5----->| 1132 |-----W=0, FCN=1 (001), Seq=6----->| 1133 DL enable |-----W=0, FCN=0 (000), Seq=7----->| Waits for next DL opportunity 1134 (no ACK) 1135 |-----W=1, FCN=6 (110), Seq=8--X-->| 1136 DL enable |-----W=1, FCN=7 (111), Seq=9----->| Missing Fragment W=0 => FCN= 5, 3 and 0, W=1 => FCN= 6 and 4 1137 |<--- Compound ACK, W=0,1, C=0 ----| Bitmap W=0:1010110, Bitmap W=1:0000001 1138 |-----W=0, FCN=5 (101), Seq=10---->| 1139 |-----W=0, FCN=3 (011), Seq=11---->| 1140 |-----W=1, FCN=6 (110), Seq=12---->| All fragments received 1141 DL enable |-----W=1, FCN=7 (111), Seq=13---->| 1142 |<--------- ACK, W=1, C=1 ---------| C=1 1143 (End) 1145 Figure 29: UL ACK-on-Error Fragments Lost on First and Second Windows 1146 with one Compound ACK 1148 The number of times the same SCHC ACK message will be retransmitted 1149 is determined by the MAX_ACK_REQUESTS. 1151 4.3. SCHC Abort Examples 1153 Case SCHC Sender-Abort 1155 The sender may need to send a Sender-Abort to stop the current 1156 communication. This may happen, for example, if the All-1 has been 1157 sent MAX_ACK_REQUESTS times. 1159 Sender Receiver 1160 |-----W=0, FCN=6, Seq=1----->| 1161 |-----W=0, FCN=5, Seq=2----->| 1162 |-----W=0, FCN=4, Seq=3----->| 1163 |-----W=0, FCN=3, Seq=4----->| 1164 |-----W=0, FCN=2, Seq=5----->| 1165 |-----W=0, FCN=1, Seq=6----->| 1166 DL Enable |-----W=0, FCN=0, Seq=7----->| 1167 (no ACK) 1168 |-----W=1, FCN=6, Seq=8----->| 1169 |-----W=1, FCN=5, Seq=9----->| 1170 |-----W=1, FCN=4, Seq=10---->| 1171 DL Enable |-----W=1, FCN=7, Seq=11---->| All fragments received 1172 |<------ ACK, W=1, C=1 ---X--| C=1 1173 DL Enable |-----W=1, FCN=7, Seq=14---->| RESEND ACK (1) 1174 |<------ ACK, W=1, C=1 ---X--| C=1 1175 DL Enable |-----W=1, FCN=7, Seq=15---->| RESEND ACK (2) 1176 |<------ ACK, W=1, C=1 ---X--| C=1 1177 DL Enable |-----W=1, FCN=7, Seq=16---->| RESEND ACK (3) 1178 |<------ ACK, W=1, C=1 ---X--| C=1 1179 DL Enable |-----W=1, FCN=7, Seq=17---->| RESEND ACK (4) 1180 |<------ ACK, W=1, C=1 ---X--| C=1 1181 DL Enable |-----W=1, FCN=7, Seq=18---->| RESEND ACK (5) 1182 |<------ ACK, W=1, C=1 ---X--| C=1 1183 DL Enable |----Sender-Abort, Seq=19--->| exit with error condition 1184 (End) 1186 Figure 30: UL ACK-on-Error Sender-Abort 1188 Case Receiver-Abort 1190 The receiver may need to send a Receiver-Abort to stop the current 1191 communication. This message can only be sent after a DL enable. 1193 Sender Receiver 1194 |-----W=0, FCN=6, Seq=1----->| 1195 |-----W=0, FCN=5, Seq=2----->| 1196 |-----W=0, FCN=4, Seq=3----->| 1197 |-----W=0, FCN=3, Seq=4----->| 1198 |-----W=0, FCN=2, Seq=5----->| 1199 |-----W=0, FCN=1, Seq=6----->| 1200 DL Enable |-----W=0, FCN=0, Seq=7----->| 1201 |<------- RECV ABORT -------| under-resourced 1202 (Error) 1204 Figure 31: UL ACK-on-Error Receiver-Abort 1206 5. Security considerations 1208 The radio protocol authenticates and ensures the integrity of each 1209 message. This is achieved by using a unique device ID and an AES-128 1210 based message authentication code, ensuring that the message has been 1211 generated and sent by the device with the ID claimed in the message. 1213 Application data can be encrypted at the application level or not, 1214 depending on the criticality of the use case. This flexibility 1215 allows providing a balance between cost and effort vs. risk. AES-128 1216 in counter mode is used for encryption. Cryptographic keys are 1217 independent for each device. These keys are associated with the 1218 device ID and separate integrity and confidentiality keys are pre- 1219 provisioned. A confidentiality key is only provisioned if 1220 confidentiality is to be used. 1222 The radio protocol has protections against reply attacks, and the 1223 cloud-based core network provides firewalling protection against 1224 undesired incoming communications. 1226 6. Acknowledgements 1228 Carles Gomez has been funded in part by the Spanish Government 1229 through the Jose Castillejo CAS15/00336 grant, the TEC2016-79988-P 1230 grant, and the PID2019-106808RA-I00 grant, and by Secretaria 1231 d'Universitats i Recerca del Departament d'Empresa i Coneixement de 1232 la Generalitat de Catalunya 2017 through grant SGR 376. 1234 Sergio Aguilar has been funded by the ERDF and the Spanish Government 1235 through project TEC2016-79988-P and project PID2019-106808RA-I00, 1236 AEI/FEDER, EU. 1238 Sandra Cespedes has been funded in part by the ANID Chile Project 1239 FONDECYT Regular 1201893 and Basal Project FB0008. 1241 Diego Wistuba has been funded by the ANID Chile Project FONDECYT 1242 Regular 1201893. 1244 The authors would like to thank Clement Mannequin, Rafael Vidal, 1245 Julien Boite, Renaud Marty, and Antonis Platis for their useful 1246 comments and implementation design considerations. 1248 7. References 1250 7.1. Normative References 1252 [I-D.ietf-lpwan-schc-compound-ack] 1253 Zuniga, JC., Gomez, C., Aguilar, S., Toutain, L., 1254 Cespedes, S., and D. Wistuba, "SCHC Compound ACK", draft- 1255 ietf-lpwan-schc-compound-ack-00 (work in progress), July 1256 2021. 1258 [RFC8376] Farrell, S., Ed., "Low-Power Wide Area Network (LPWAN) 1259 Overview", RFC 8376, DOI 10.17487/RFC8376, May 2018, 1260 . 1262 [RFC8724] Minaburo, A., Toutain, L., Gomez, C., Barthel, D., and JC. 1263 Zuniga, "SCHC: Generic Framework for Static Context Header 1264 Compression and Fragmentation", RFC 8724, 1265 DOI 10.17487/RFC8724, April 2020, 1266 . 1268 7.2. Informative References 1270 [sigfox-callbacks] 1271 Sigfox, "Sigfox Callbacks", 1272 . 1274 [sigfox-spec] 1275 Sigfox, "Sigfox Radio Specifications", 1276 . 1279 Authors' Addresses 1280 Juan Carlos Zuniga 1281 SIGFOX 1282 Montreal QC 1283 Canada 1285 Email: JuanCarlos.Zuniga@sigfox.com 1286 URI: http://www.sigfox.com/ 1288 Carles Gomez 1289 Universitat Politecnica de Catalunya 1290 C/Esteve Terradas, 7 1291 08860 Castelldefels 1292 Spain 1294 Email: carlesgo@entel.upc.edu 1296 Sergio Aguilar 1297 Universitat Politecnica de Catalunya 1298 C/Esteve Terradas, 7 1299 08860 Castelldefels 1300 Spain 1302 Email: sergio.aguilar.romero@upc.edu 1304 Laurent Toutain 1305 IMT-Atlantique 1306 2 rue de la Chataigneraie 1307 CS 17607 1308 35576 Cesson-Sevigne Cedex 1309 France 1311 Email: Laurent.Toutain@imt-atlantique.fr 1313 Sandra Cespedes 1314 NIC Labs, Universidad de Chile 1315 Av. Almte. Blanco Encalada 1975 1316 Santiago 1317 Chile 1319 Email: scespedes@niclabs.cl 1320 Diego Wistuba 1321 NIC Labs, Universidad de Chile 1322 Av. Almte. Blanco Encalada 1975 1323 Santiago 1324 Chile 1326 Email: wistuba@niclabs.cl