idnits 2.17.00 (12 Aug 2021) /tmp/idnits39127/draft-ietf-lpwan-schc-over-sigfox-09.txt: -(6): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding 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: ---------------------------------------------------------------------------- == There are 4 instances of lines with non-ascii characters in the document. 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 289: '...ntation mode, a DL opportunity MUST be...' RFC 2119 keyword, line 300: '...m All-0 or All-1 MUST NOT use the DL r...' RFC 2119 keyword, line 305: '... The RuleID MUST be included in the ...' RFC 2119 keyword, line 332: '...ss of a SCHC Packet MUST be checked at...' RFC 2119 keyword, line 339: '... in Section 3.6.1.5 is RECOMMENDED....' (44 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- -- The document date (21 February 2022) is 82 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 (-04) 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 4 Intended status: Standards Track C. Gomez 5 Expires: 25 August 2022 S. Aguilar 6 Universitat Politècnica de Catalunya 7 L. Toutain 8 IMT-Atlantique 9 S. Cespedes 10 D. Wistuba 11 NIC Labs, Universidad de Chile 12 J. Boite 13 SIGFOX 14 21 February 2022 16 SCHC over Sigfox LPWAN 17 draft-ietf-lpwan-schc-over-sigfox-09 19 Abstract 21 The Generic Framework for Static Context Header Compression and 22 Fragmentation (SCHC) specification describes two mechanisms: i) an 23 application header compression scheme, and ii) a frame fragmentation 24 and loss recovery functionality. SCHC offers a great level of 25 flexibility that can be tailored for different Low Power Wide Area 26 Network (LPWAN) technologies. 28 The present document provides the optimal parameters and modes of 29 operation when SCHC is implemented over a Sigfox LPWAN. This set of 30 parameters are also known as a "SCHC over Sigfox profile." 32 Status of This Memo 34 This Internet-Draft is submitted in full conformance with the 35 provisions of BCP 78 and BCP 79. 37 Internet-Drafts are working documents of the Internet Engineering 38 Task Force (IETF). Note that other groups may also distribute 39 working documents as Internet-Drafts. The list of current Internet- 40 Drafts is at https://datatracker.ietf.org/drafts/current/. 42 Internet-Drafts are draft documents valid for a maximum of six months 43 and may be updated, replaced, or obsoleted by other documents at any 44 time. It is inappropriate to use Internet-Drafts as reference 45 material or to cite them other than as "work in progress." 47 This Internet-Draft will expire on 25 August 2022. 49 Copyright Notice 51 Copyright (c) 2022 IETF Trust and the persons identified as the 52 document authors. All rights reserved. 54 This document is subject to BCP 78 and the IETF Trust's Legal 55 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 56 license-info) in effect on the date of publication of this document. 57 Please review these documents carefully, as they describe your rights 58 and restrictions with respect to this document. Code Components 59 extracted from this document must include Revised BSD License text as 60 described in Section 4.e of the Trust Legal Provisions and are 61 provided without warranty as described in the Revised BSD License. 63 Table of Contents 65 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 66 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 67 3. SCHC over Sigfox . . . . . . . . . . . . . . . . . . . . . . 3 68 3.1. Network Architecture . . . . . . . . . . . . . . . . . . 3 69 3.2. Uplink . . . . . . . . . . . . . . . . . . . . . . . . . 5 70 3.3. Downlink . . . . . . . . . . . . . . . . . . . . . . . . 6 71 3.4. SCHC-ACK on Downlink . . . . . . . . . . . . . . . . . . 7 72 3.5. SCHC Rules . . . . . . . . . . . . . . . . . . . . . . . 7 73 3.6. Fragmentation . . . . . . . . . . . . . . . . . . . . . . 7 74 3.6.1. Uplink Fragmentation . . . . . . . . . . . . . . . . 8 75 3.6.2. Downlink Fragmentation . . . . . . . . . . . . . . . 11 76 3.7. SCHC-over-Sigfox F/R Message Formats . . . . . . . . . . 12 77 3.7.1. Uplink ACK-on-Error Mode: Single-byte SCHC Header . . 13 78 3.7.2. Uplink ACK-on-Error Mode: Two-byte SCHC Header Option 79 2 . . . . . . . . . . . . . . . . . . . . . . . . . . 16 80 3.8. SCHC-Sender Abort . . . . . . . . . . . . . . . . . . . . 18 81 3.9. SCHC-Receiver Abort . . . . . . . . . . . . . . . . . . . 19 82 3.10. Padding . . . . . . . . . . . . . . . . . . . . . . . . . 19 83 4. Fragmentation Sequence Examples . . . . . . . . . . . . . . . 20 84 4.1. Uplink No-ACK Examples . . . . . . . . . . . . . . . . . 20 85 4.2. Uplink ACK-on-Error Examples: Single-byte SCHC Header . . 21 86 4.3. SCHC Abort Examples . . . . . . . . . . . . . . . . . . . 27 87 5. Security considerations . . . . . . . . . . . . . . . . . . . 28 88 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 28 89 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 29 90 7.1. Normative References . . . . . . . . . . . . . . . . . . 29 91 7.2. Informative References . . . . . . . . . . . . . . . . . 29 92 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 29 94 1. Introduction 96 The Generic Framework for Static Context Header Compression and 97 Fragmentation (SCHC) specification [RFC8724] describes two 98 mechanisms: i) a frame fragmentation and loss recovery functionality, 99 and ii) an application header compression scheme. Either can be used 100 on top of all the four LWPAN technologies defined in [RFC8376]. 101 These LPWANs have similar characteristics such as star-oriented 102 topologies, network architecture, connected devices with built-in 103 applications, etc. 105 SCHC offers a great level of flexibility to accommodate all these 106 LPWAN technologies. Even though there are a great number of 107 similarities between them, some differences exist with respect to the 108 transmission characteristics, payload sizes, etc. Hence, there are 109 optimal parameters and modes of operation that can be used when SCHC 110 is used on top of a specific LPWAN technology. 112 This document describes the recommended parameters, settings, and 113 modes of operation to be used when SCHC is implemented over a Sigfox 114 LPWAN. This set of parameters are also known as a "SCHC over Sigfox 115 profile" or simply "SCHC/Sigfox." 117 2. Terminology 119 It is assumed that the reader is familiar with the terms and 120 mechanisms defined in [RFC8376] and in [RFC8724]. 122 3. SCHC over Sigfox 124 The Generic SCHC Framework described in [RFC8724] takes advantage of 125 the predictability of data flows existing in LPWAN applications to 126 avoid context synchronization. 128 Contexts need to be stored and pre-configured on both ends. This can 129 be done either by using a provisioning protocol, by out of band 130 means, or by pre-provisioning them (e.g. at manufacturing time). The 131 way contexts are configured and stored on both ends is out of the 132 scope of this document. 134 3.1. Network Architecture 136 Figure 1 represents the architecture for compression/decompression 137 (C/D) and fragmentation/reassembly (F/R) based on the terminology 138 defined in [RFC8376], where the Radio Gateway (RG) is a Sigfox Base 139 Station and the Network Gateway (NGW) is the Sigfox cloud-based 140 Network. 142 Sigfox Device Application 143 +----------------+ +--------------+ 144 | APP1 APP2 APP3 | |APP1 APP2 APP3| 145 +----------------+ +--------------+ 146 | UDP | | | | UDP | 147 | IPv6 | | | | IPv6 | 148 +--------+ | | +--------+ 149 | SCHC C/D & F/R | | | 150 | | | | 151 +-------+--------+ +--------+-----+ 152 $ . 153 $ +---------+ +--------------+ +---------+ . 154 $ | | | | | Network | . 155 +~~ |Sigfox BS| |Sigfox Network| | SCHC | . 156 | (RG) | === | (NGW) | === |C/D & F/R|..... 157 +---------+ +--------------+ +---------+ 159 Figure 1: Network Architecture 161 In the case of the global Sigfox Network, RGs (or Base Stations) are 162 distributed over multiple countries wherever the Sigfox LPWAN service 163 is provided. The NGW (or cloud-based Sigfox Core Network) is a 164 single entity that connects to all Sigfox base stations in the world, 165 providing hence a global single star network topology. 167 The Device sends application flows that are compressed and/or 168 fragmented by a SCHC Compressor/Decompressor (SCHC C/D + F/R) to 169 reduce headers size and/or fragment the packet. The resulting SCHC 170 Message is sent over a layer two (L2) Sigfox frame to the Sigfox Base 171 Stations, which then forward the SCHC Message to the Network Gateway 172 (NGW). The NGW then delivers the SCHC Message and associated 173 gathered metadata to the Network SCHC C/D + F/R. 175 The Sigfox Network (NGW) communicates with the Network SCHC C/D + F/R 176 for compression/decompression and/or for fragmentation/reassembly. 177 The Network SCHC C/D + F/R shares the same set of rules as the Dev 178 SCHC C/D + F/R. The Network SCHC C/D + F/R can be collocated with 179 the NGW or it could be located in a different place, as long as a 180 tunnel or secured communication is established between the NGW and 181 the SCHC C/D + F/R functions. After decompression and/or reassembly, 182 the packet can be forwarded over the Internet to one (or several) 183 LPWAN Application Server(s) (App). 185 The SCHC C/D + F/R processes are bidirectional, so the same 186 principles are applicable on both uplink (UL) and downlink (DL). 188 3.2. Uplink 190 Uplink Sigfox transmissions occur in repetitions over different times 191 and frequencies. Besides time and frequency diversities, the Sigfox 192 network also provides space diversity, as potentially an uplink 193 message will be received by several base stations. 195 Since all messages are self-contained and base stations forward all 196 these messages back to the same Sigfox Network, multiple input copies 197 can be combined at the NGW providing for extra reliability based on 198 the triple diversity (i.e., time, space and frequency). 200 A detailed description of the Sigfox Radio Protocol can be found in 201 [sigfox-spec]. 203 Messages sent from the Device to the Network are delivered by the 204 Sigfox network (NGW) to the Network SCHC C/D + F/R through a 205 callback/API with the following information: 207 * Device ID 209 * Message Sequence Number 211 * Message Payload 213 * Message Timestamp 215 * Device Geolocation (optional) 217 * RSSI (optional) 219 * Device Temperature (optional) 221 * Device Battery Voltage (optional) 223 The Device ID is a globally unique identifier assigned to the Device, 224 which is included in the Sigfox header of every message. The Message 225 Sequence Number is a monotonically increasing number identifying the 226 specific transmission of this uplink message, and it is also part of 227 the Sigfox header. The Message Payload corresponds to the payload 228 that the Device has sent in the uplink transmission. 230 The Message Timestamp, Device Geolocation, RSSI, Device Temperature 231 and Device Battery Voltage are metadata parameters provided by the 232 Network. 234 A detailed description of the Sigfox callbacks/APIs can be found in 235 [sigfox-callbacks]. 237 Only messages that have passed the L2 Cyclic Redundancy Check (CRC) 238 at network reception are delivered by the Sigfox Network to the 239 Network SCHC C/D + F/R. 241 +---------------+-----------------+ 242 | Sigfox Header | Sigfox payload | 243 +---------------+---------------- + 244 | SCHC message | 245 +-----------------+ 247 Figure 2: SCHC Message in Sigfox 249 Figure 2 shows a SCHC Message sent over Sigfox, where the SCHC 250 Message could be a full SCHC Packet (e.g. compressed) or a SCHC 251 Fragment (e.g. a piece of a bigger SCHC Packet). 253 3.3. Downlink 255 Downlink transmissions are Device-driven and can only take place 256 following an uplink communication that so indicates. Hence, a Device 257 explicitly indicates its intention to receive a downlink message 258 using a donwlink request flag when sending the preceding uplink 259 message to the network. After completing the uplink transmission, 260 the Device opens a fixed window for downlink reception. The delay 261 and duration of the reception opportunity window have fixed values. 262 If there is a downlink message to be sent for this given Device (e.g. 263 either a response to the uplink message or queued information waiting 264 to be transmitted), the network transmits this message to the Device 265 during the reception window. If no message is received by the Device 266 after the reception opportunity window has elapsed, the Device closes 267 the reception window opportunity and gets back to the normal mode 268 (e.g., continue UL transmissions, sleep, stand-by, etc.) 270 When a downlink message is sent to a Device, a reception 271 acknowledgement is generated by the Device and sent back to the 272 Network through the Sigfox radio protocol and reported in the Sigfox 273 Network backend. 275 A detailed description of the Sigfox Radio Protocol can be found in 276 [sigfox-spec] and a detailed description of the Sigfox callbacks/APIs 277 can be found in [sigfox-callbacks]. 279 3.4. SCHC-ACK on Downlink 281 As explained previously, downlink transmissions are Device-driven and 282 can only take place following a specific uplink transmission that 283 indicates and allows a following downlink opportunity. For this 284 reason, when SCHC bi-directional services are used (e.g. Ack-on- 285 Error fragmentation mode) the SCHC protocol implementation needs to 286 consider the times when a downlink message (e.g. SCHC-ACK) can be 287 sent and/or received. 289 For the UL ACK-on-Error fragmentation mode, a DL opportunity MUST be 290 indicated by the last fragment of every window (i.e. FCN = All-0, or 291 FCN = All-1). The Device sends the fragments in sequence and, after 292 transmitting the FCN = All-0 or FCN = All-1, it opens up a reception 293 opportunity. The Network SCHC can then decide to respond at that 294 opportunity (or wait for a further one) with a SCHC-ACK indicating in 295 case there are missing fragments from the current or previous 296 windows. If there is no SCHC-ACK to be sent, or if the network 297 decides to wait for a further DL transmission opportunity, then no DL 298 transmission takes place at that opportunity and after a timeout the 299 UL transmissions continue. Intermediate SCHC fragments with FCN 300 different from All-0 or All-1 MUST NOT use the DL request flag to 301 request a SCHC-ACK. 303 3.5. SCHC Rules 305 The RuleID MUST be included in the SCHC header. The total number of 306 rules to be used affects directly the Rule ID field size, and 307 therefore the total size of the fragmentation header. For this 308 reason, it is recommended to keep the number of rules that are 309 defined for a specific device to the minimum possible. 311 RuleIDs can be used to differentiate data traffic classes (e.g. QoS, 312 control vs. data, etc.), and data sessions. They can also be used to 313 interleave simultaneous fragmentation sessions between a Device and 314 the Network. 316 3.6. Fragmentation 318 The SCHC specification [RFC8724] defines a generic fragmentation 319 functionality that allows sending data packets or files larger than 320 the maximum size of a Sigfox payload. The functionality also defines 321 a mechanism to send reliably multiple messages, by allowing to resend 322 selectively any lost fragments. 324 The SCHC fragmentation supports several modes of operation. These 325 modes have different advantages and disadvantages depending on the 326 specifics of the underlying LPWAN technology and application Use 327 Case. This section describes how the SCHC fragmentation 328 functionality should optimally be implemented when used over a Sigfox 329 LPWAN for the most typical Use Case applications. 331 As described in section 8.2.3 of [RFC8724], the integrity of the 332 fragmentation-reassembly process of a SCHC Packet MUST be checked at 333 the receive end. Since only UL messages/fragments that have passed 334 the Sigfox CRC-check are delivered to the Network SCHC C/D + F/R, 335 integrity can be guaranteed when no consecutive messages are missing 336 from the sequence and all FCN bitmaps are complete. With this 337 functionality in mind, and in order to save protocol and processing 338 overhead, the use of a Reassembly Check Sequence (RCS) as described 339 in Section 3.6.1.5 is RECOMMENDED. 341 The L2 Word Size used by Sigfox is 1 byte (8 bits). 343 3.6.1. Uplink Fragmentation 345 Sigfox uplink transmissions are completely asynchronous and take 346 place in any random frequency of the allowed uplink bandwidth 347 allocation. In addition, devices may go to deep sleep mode, and then 348 wake up and transmit whenever there is a need to send information to 349 the network. Data packets are self-contained (aka "message in a 350 bottle") with all the required information for the network to process 351 them accordingly. Hence, there is no need to perform any network 352 attachment, synchronization, or other procedure before transmitting a 353 data packet. 355 Since uplink transmissions are asynchronous, a SCHC fragment can be 356 transmitted at any given time by the Device. Sigfox uplink messages 357 are fixed in size, and as described in [RFC8376] they can carry 0-12 358 bytes payload. Hence, a single SCHC Tile size per fragmentation mode 359 can be defined so that every Sigfox message always carries one SCHC 360 Tile. 362 When the ACK-on-Error mode is used for uplink fragmentation, the SCHC 363 Compound ACK defined in [I-D.ietf-lpwan-schc-compound-ack]) MUST be 364 used in the downlink responses. 366 3.6.1.1. Uplink No-ACK Mode 368 No-ACK is RECOMMENDED to be used for transmitting short, non-critical 369 packets that require fragmentation and do not require full 370 reliability. This mode can be used by uplink-only devices that do 371 not support downlink communications, or by bidirectional devices when 372 they send non-critical data. 374 Since there are no multiple windows in the No-ACK mode, the W bit is 375 not present. However it is RECOMMENDED to use the FCN field to 376 indicate the size of the data packet. In this sense, the data packet 377 would need to be splitted into X fragments and, similarly to the 378 other fragmentation modes, the first transmitted fragment would need 379 to be marked with FCN = X-1. Consecutive fragments MUST be marked 380 with decreasing FCN values, having the last fragment marked with FCN 381 = (All-1). Hence, even though the No-ACK mode does not allow 382 recovering missing fragments, it allows indicating implicitly the 383 size of the expected packet to the Network and hence detect at the 384 receiver side whether all fragments have been received or not. 386 The RECOMMENDED Fragmentation Header size is 8 bits, and it is 387 composed as follows: 389 * RuleID size: 4 bits 391 * DTag size (T): 0 bits 393 * Fragment Compressed Number (FCN) size (N): 4 bits 395 * As per [RFC8724], in the No-ACK mode the W (window) field is not 396 present. 398 * RCS size: 0 bits (Not used) 400 3.6.1.2. Uplink ACK-on-Error Mode: Single-byte SCHC Header 402 ACK-on-Error with single-byte header is RECOMMENDED for medium to 403 large size packets that need to be sent reliably. ACK-on-Error is 404 optimal for Sigfox transmissions, since it leads to a reduced number 405 of ACKs in the lower capacity downlink channel. Also, downlink 406 messages can be sent asynchronously and opportunistically. 408 Allowing transmission of packets/files up to 300 bytes long, the SCHC 409 uplink Fragmentation Header size is RECOMMENDED to be 8 bits in size 410 and is composed as follows: 412 * Rule ID size: 3 bits 414 * DTag size (T): 0 bits 416 * Window index (W) size (M): 2 bits 418 * Fragment Compressed Number (FCN) size (N): 3 bits 420 * MAX_ACK_REQUESTS: 5 421 * WINDOW_SIZE: 7 (with a maximum value of FCN=0b110) 423 * Tile size: 11 bytes 425 * Retransmission Timer: Application-dependent 427 * Inactivity Timer: Application-dependent 429 * RCS size: 3 bits 431 3.6.1.3. Uplink ACK-on-Error Mode: Two-byte SCHC Header Option 1 433 ACK-on-Error with two-byte header is RECOMMENDED for very large size 434 packets that need to be sent reliably. ACK-on-Error is optimal for 435 Sigfox transmissions, since it leads to a reduced number of ACKs in 436 the lower capacity downlink channel. Also, downlink messages can be 437 sent asynchronously and opportunistically. 439 In order to allow transmission of large packets/files up to 480 bytes 440 long, the SCHC uplink Fragmentation Header size is RECOMMENDED to be 441 16 bits in size and composed as follows: 443 * Rule ID size is: 6 bits 445 * DTag size (T) is: 0 bits 447 * Window index (W) size (M): 2 bits 449 * Fragment Compressed Number (FCN) size (N): 4 bits. 451 * MAX_ACK_REQUESTS: 5 453 * WINDOW_SIZE: 12 (with a maximum value of FCN=0b1011) 455 * Tile size: 10 bytes 457 * Retransmission Timer: Application-dependent 459 * Inactivity Timer: Application-dependent 461 * RCS size: 4 bits 463 3.6.1.4. Uplink ACK-on-Error Mode: Two-byte SCHC Header Option 2 465 In order to allow transmission of very large packets/files up to 2250 466 bytes long, the SCHC uplink Fragmentation Header size is RECOMMENDED 467 to be 16 bits in size and composed as follows: 469 * Rule ID size is: 8 bits 471 * DTag size (T) is: 0 bits 473 * Window index (W) size (M): 3 bits 475 * Fragment Compressed Number (FCN) size (N): 5 bits. 477 * MAX_ACK_REQUESTS: 5 479 * WINDOW_SIZE: 31 (with a maximum value of FCN=0b11110) 481 * Tile size: 10 bytes 483 * Retransmission Timer: Application-dependent 485 * Inactivity Timer: Application-dependent 487 * RCS size: 5 bits 489 3.6.1.5. All-1 and RCS behaviour 491 For ACK-on-Error, as defined in [RFC8724], it is expected that the 492 last SCHC fragment of the last window will always be delivered with 493 an All-1 FCN. Since this last window may not be full (i.e. it may be 494 comprised of less than WINDOW_SIZE fragments), an All-1 fragment may 495 follow a value of FCN higher than 1 (0b01). In this case, the 496 receiver could not derive from the FCN values alone whether there are 497 any missing fragments right before the All-1 fragment or not. 499 For Rules where the number of fragments in the last window is 500 unknown, an RCS field MUST be used, indicating the number of 501 fragments in the last window, including the All-1. With this RCS 502 value, the receiver can detect if there are missing fragments before 503 the All-1 and hence construct the corresponding SCHC ACK Bitmap 504 accordingly, and send it in response to the All-1. 506 3.6.2. Downlink Fragmentation 508 In some LPWAN technologies, as part of energy-saving techniques, 509 downlink transmission is only possible immediately after an uplink 510 transmission. This allows the device to go in a very deep sleep mode 511 and preserve battery, without the need to listen to any information 512 from the network. This is the case for Sigfox-enabled devices, which 513 can only listen to downlink communications after performing an uplink 514 transmission and requesting a downlink. 516 When there are fragments to be transmitted in the downlink, an uplink 517 message is required to trigger the downlink communication. In order 518 to avoid potentially high delay for fragmented datagram transmission 519 in the downlink, the fragment receiver MAY perform an uplink 520 transmission as soon as possible after reception of a downlink 521 fragment that is not the last one. Such uplink transmission MAY be 522 triggered by sending a SCHC message, such as a SCHC ACK. However, 523 other data messages can equally be used to trigger DL communications. 525 Sigfox downlink messages are fixed in size, and as described in 526 [RFC8376] they can carry up to 8 bytes payload. Hence, a single SCHC 527 Tile size per mode can be defined so that every Sigfox message always 528 carries one SCHC Tile. 530 For reliable downlink fragment transmission, the ACK-Always mode is 531 RECOMMENDED. 533 The SCHC downlink Fragmentation Header size is RECOMMENDED to be 8 534 bits in size and is composed as follows: 536 * RuleID size: 3 bits 538 * DTag size (T): 0 bits 540 * Window index (W) size (M) is: 0 bits 542 * Fragment Compressed Number (FCN) size (N): 5 bits 544 * MAX_ACK_REQUESTS: 5 546 * WINDOW_SIZE: 31 (with a maximum value of FCN=0b11110) 548 * Tile size: 7 bytes 550 * Retransmission Timer: Application-dependent 552 * Inactivity Timer: Application-dependent 554 * RCS size: 0 bits (Not used) 556 3.7. SCHC-over-Sigfox F/R Message Formats 558 This section depicts the different formats of SCHC Fragment, SCHC ACK 559 (including the SCHC Compound ACK defined in 560 [I-D.ietf-lpwan-schc-compound-ack]), and SCHC Abort used in SCHC over 561 Sigfox. 563 3.7.1. Uplink ACK-on-Error Mode: Single-byte SCHC Header 565 3.7.1.1. Regular SCHC Fragment 567 Figure 3 shows an example of a regular SCHC fragment for all 568 fragments except the last one. As tiles are of 11 bytes, padding 569 MUST NOT be added. 571 |-- SCHC Fragment Header --| 572 + ------------------------ + ------- + 573 | RuleID | W | FCN | Payload | 574 + ------ + ------ + ------ + ------- + 575 | 3 bits | 2 bits | 3 bits | 88 bits | 577 Figure 3: Regular SCHC Fragment format for all fragments except 578 the last one 580 The use of SCHC ACK REQ is NOT RECOMMENDED, instead the All-1 SCHC 581 Fragment SHOULD be used to request a SCHC ACK from the receiver 582 (Network SCHC). As per [RFC8724], the All-0 message is 583 distinguishable from the SCHC ACK REQ (All-1 message). The 584 penultimate tile of a SCHC Packet is of regular size. 586 3.7.1.2. All-1 SCHC Fragment 588 Figure 4 shows an example of the All-1 message. The All-1 message 589 MUST contain the last tile of the SCHC Packet. The last tile MUST be 590 of at least 1 byte (one L2 word). Padding MUST NOT be added, as the 591 resulting size is L2-word-multiple. 593 |--- SCHC Fragment Header ---| 594 + --------------------------- + ------------ + 595 | RuleID | W | FCN=ALL-1 | Payload | 596 + ------ + ------ + --------- + ------------ + 597 | 3 bits | 2 bits | 3 bits | 8 to 88 bits | 599 Figure 4: All-1 SCHC Message format with last tile 601 As per [RFC8724] the All-1 must be distinguishable from a SCHC 602 Sender-Abort message (with same Rule ID, M, and N values). The All-1 603 MUST have the last tile of the SCHC Packet, which MUST be of at least 604 1 byte. The SCHC Sender-Abort message header size is of 1 byte, with 605 no padding bits. 607 For the All-1 message to be distinguishable from the Sender-Abort 608 message, the Sender-Abort message MUST be of 1 byte (only header with 609 no padding). This way, the minimum size of the All-1 is 2 bytes, and 610 the Sender-Abort message is 1 byte. 612 3.7.1.3. SCHC ACK Format 614 Figure 5 shows the SCHC ACK format when all fragments have been 615 correctly received (C=1). Padding MUST be added to complete the 616 64-bit Sigfox downlink frame payload size. 618 |---- SCHC ACK Header ----| 619 + ----------------------- + ------- + 620 | RuleID | W | C=b'1 | b'0-pad | 621 + ------ + ------ + ----- + ------- + 622 | 3 bits | 2 bits | 1 bit | 58 bits | 624 Figure 5: SCHC Success ACK message format 626 In case SCHC fragment losses are found in any of the windows of the 627 SCHC Packet (C=0), the SCHC Compound ACK defined in 628 [I-D.ietf-lpwan-schc-compound-ack] MUST be used. The SCHC Compound 629 ACK message format is shown in Figure 6. The window numbered 00, if 630 present in the SCHC Compound ACK, MUST be placed between the Rule ID 631 and the C bit to avoid confusion with padding bits. As padding is 632 needed for the SCHC Compound ACK, padding bits MUST be 0 to make 633 subsequent window numbers and bitmaps distinguishable. 635 |---- SCHC ACK Header ----|-W = x -|...| --- W = x + i ---| 636 + ----------------------- + ------ +...+ ------- + ------ + ------- + 637 | RuleID | W=b'x | C=b'0 | Bitmap |...| W=b'x+i | Bitmap | b'0-pad | 638 + ------ + ------ + ----- + ------ +...+ ------- + ------ + ------- + 639 | 3 bits | 2 bits | 1 bit | 7 bits | | 2 bits | 7 bits | 641 On top are noted the window number of the corresponding bitmap. 642 Losses are found in windows x,...,x+i. 644 Figure 6: SCHC Compound ACK message format 646 The following figures show examples of the SCHC Compound ACK message 647 format, when used on SCHC over Sigfox. 649 |---- SCHC ACK Header ----|- W=00 -|----- W=01 ------| 650 + ----------------------- + ------ + ------ + ------ + ------- + 651 | RuleID | W=b'00 | C=b'0 | Bitmap | W=b'01 | Bitmap | b'0-pad | 652 + ------ + ------ + ----- + ------ + ------ + ------ + ------- + 653 | 3 bits | 2 bits | 1 bit | 7 bits | 2 bits | 7 bits | 42 bits | 655 Losses are found in windows 00 and 01. 657 Figure 7: SCHC Compound ACK example 1 659 |---- SCHC ACK Header ----|- W=01 -|----- W=11 ------| 660 + ----------------------- + ------ + ------ + ------ + ------- + 661 | RuleID | W=b'01 | C=b'0 | Bitmap | W=b'11 | Bitmap | b'0-pad | 662 + ------ + ------ + ----- + ------ + ------ + ------ + ------- + 663 | 3 bits | 2 bits | 1 bit | 7 bits | 2 bits | 7 bits | 42 bits | 665 Losses are found in windows 01 and 11. 667 Figure 8: SCHC Compound ACK example 2 669 |---- SCHC ACK Header ----|- W=00 -|----- W=10 ------| 670 + ----------------------- + ------ + ------ + ------ + ------- + 671 | RuleID | W=b'00 | C=b'0 | Bitmap | W=b'10 | Bitmap | b'0-pad | 672 + ------ + ------ + ----- + ------ + ------ + ------ + ------- + 673 | 3 bits | 2 bits | 1 bit | 7 bits | 2 bits | 7 bits | 42 bits | 675 Losses are found in windows 00 and 10. 677 Figure 9: SCHC Compound ACK example 3 679 Figure 10 shows the SCHC Compound ACK message format when losses are 680 found in all windows. The window numbers and its corresponding 681 bitmaps are ordered from window numbered 00 to 11, notifying all four 682 possible windows. 684 |- SCHC ACK Header -|W=b'00|-- W=b'01 ---| 685 +-------------------+------+ ---- +------+ 686 |RuleID|W=b'00|C=b'0|Bitmap|W=b'01|Bitmap| ... 687 +------+------+-----+------+------+------+ 688 |3 bits|2 bits|1 bit|7 bits|2 bits|7 bits| 690 |--- W=b'10 --|--- W=b'11 --| 691 |------+------+------+------+-------+ 692 ... |W=b'10|Bitmap|W=b'11|Bitmap|b'0-pad| 693 |------+------+------+------+-------+ 694 |2 bits|7 bits|2 bits|7 bits|24 bits| 696 Losses are found in windows 00, 01, 10 and 11. 698 Figure 10: SCHC Compound ACK example 4 700 |- SCHC ACK Header -|W=b'00|-- W=b'01 ---|--- W=b'10 --| 701 +-------------------+------+------+------+------+------+-------+ 702 |RuleID|W=b'00|C=b'0|Bitmap|W=b'01|Bitmap|W=b'10|Bitmap|b'0-pad| 703 +------+------+-----+------+------+------+------+------+-------+ 704 |3 bits|2 bits|1 bit|7 bits|2 bits|7 bits|2 bits|7 bits|33 bits| 706 Losses are found in windows 00, 01 and 10. 708 Figure 11: SCHC Compound ACK example 5 710 3.7.1.4. SCHC Sender-Abort Message format 712 |---- Sender-Abort Header ----| 713 + --------------------------- + 714 | RuleID | W | FCN=ALL-1 | 715 + ------ + ------ + --------- + 716 | 3 bits | 2 bits | 3 bits | 718 Figure 12: SCHC Sender-Abort message format 720 3.7.1.5. SCHC Receiver-Abort Message format 722 |- Receiver-Abort Header -| 723 + ----------------------- + ------- + 724 | RuleID | W=b'11 | C=b'1 | b'1-pad | 725 + ------ + ------ + ----- + ------- + 726 | 3 bits | 2 bits | 1 bit | 58 bits | 728 Figure 13: SCHC Receiver-Abort message format 730 3.7.2. Uplink ACK-on-Error Mode: Two-byte SCHC Header Option 2 732 3.7.2.1. Regular SCHC Fragment 734 Figure 14 shows an example of a regular SCHC fragment for all 735 fragments except the last one. The penultimate tile of a SCHC Packet 736 is of the regular size. 738 |-- SCHC Fragment Header --| 739 + ------------------------ + ------- + 740 | RuleID | W | FCN | Payload | 741 + ------ + ------ + ------ + ------- + 742 | 8 bits | 3 bits | 5 bits | 80 bits | 744 Figure 14: Regular SCHC Fragment format for all fragments except 745 the last one 747 The use of SCHC ACK is NOT RECOMMENDED, instead the All-1 SCHC 748 Fragment SHOULD be used to request a SCHC ACK from the receiver 749 (Network SCHC). As per [RFC8724], the All-0 message is 750 distinguishable from the SCHC ACK REQ (All-1 message). 752 3.7.2.2. All-1 SCHC Fragment 754 Figure 15 shows an example of the All-1 message. The All-1 message 755 MUST contain the last tile of the SCHC Packet. 757 |--- SCHC Fragment Header ---| 758 + --------------------------- + ------------ + 759 | RuleID | W | FCN=ALL-1 | Payload | 760 + ------ + ------ + --------- + ------------ + 761 | 8 bits | 3 bits | 5 bits | 8 to 80 bits | 763 Figure 15: All-1 SCHC message format with last tile 765 As per [RFC8724] the All-1 must be distinguishable from the a SCHC 766 Sender-Abort message (with same Rule ID, M and N values). The All-1 767 MUST have the last tile of the SCHC Packet, that MUST be of at least 768 1 byte. The SCHC Sender-Abort message header size is of 2 byte, with 769 no padding bits. 771 For the All-1 message to be distinguishable from the Sender-Abort 772 message, the Sender-Abort message MUST be of 2 byte (only header with 773 no padding). This way, the minimum size of the All-1 is 3 bytes, and 774 the Sender-Abort message is 2 bytes. 776 3.7.2.3. SCHC ACK Format 778 Figure 16 shows the SCHC ACK format when all fragments have been 779 correctly received (C=1). Padding MUST be added to complete the 780 64-bit Sigfox downlink frame payload size. 782 |----- SCHC ACK Header ----| 783 + ------------------------ + ------ + 784 | RuleID | W | C=b'1 | b'0-pad | 785 + ------ + ------ + ----- + ------- + 786 | 8 bits | 3 bits | 1 bit | 52 bits | 788 Figure 16: SCHC Success ACK message format 790 The SCHC Compound ACK message MUST be used in case SCHC fragment 791 losses are found in any window of the SCHC Packet (C=0). The SCHC 792 Compound ACK message format is shown in Figure 17. The SCHC Compound 793 ACK can report up to 3 windows with losses. The window number (W) 794 and its corresponding bitmap MUST be ordered from the lowest-numbered 795 window number to the highest-numbered window. If window numbered 000 796 is present in the SCHC Compound ACK, the window number 000 MUST be 797 placed between the Rule ID and C bit to avoid confusion with padding 798 bits. 800 When sent in the downlink, the SCHC Compound ACK MUST be 0 padded 801 (Padding bits must be 0) to complement the 64 bits required by the 802 Sigfox payload. 804 |- SCHC ACK Header -| W=b'x |...|--- W=b'x+i ---| 805 +-------------------+-------+...+-------+-------+-------+ 806 |RuleID|W=b'x |C=b'0|Bitmap |...|W=b'x+i|Bitmap |b'0-pad| 807 +------+------+-----+-------+...|-------+-------+-------+ 808 |8 bits|3 bits|1 bit|31 bits| | 3 bits|31 bits| 810 On top are noted the window number 811 of the corresponding bitmap. 812 Losses are found in windows x,...,x+i. 814 Figure 17: SCHC Compound ACK message format 816 3.7.2.4. SCHC Sender-Abort Messages 818 |---- Sender-Abort Header ----| 819 + --------------------------- + 820 | RuleID | W | FCN=ALL-1 | 821 + ------ + ------ + --------- + 822 | 8 bits | 3 bits | 5 bits | 824 Figure 18: SCHC Sender-Abort message format 826 3.7.2.5. SCHC Receiver-Abort Message 828 |-- Receiver-Abort Header -| 829 + ------------------------ + ------- + 830 | RuleID | W=b'111 | C=b'1 | b'1-pad | 831 + ------ + ------- + ----- + ------- + 832 | 8 bits | 3 bits | 1 bit | 52 bits | 834 Figure 19: SCHC Receiver-Abort message format 836 3.8. SCHC-Sender Abort 837 * As defined in [RFC8724], a SCHC-Sender Abort can be triggered when 838 the number of SCHC ACK REQ attempts is greater than or equal to 839 MAX_ACK_REQUESTS. In the case of SCHC/Sigfox, a SCHC-Sender Abort 840 MUST be sent if the number of repeated All-1s (i.e., with the same 841 bitmap) sent in sequence is greater than or equal to 842 MAX_ACK_REQUESTS. 844 * The MAX_ACK_REQUEST counter MUST be reset when a SCHC ACK is 845 successfully received. 847 3.9. SCHC-Receiver Abort 849 * As defined in [RFC8724], a SCHC-Receiver Abort is triggered when 850 the receiver has no RuleID and DTag pairs available for a new 851 session. In the case of SCHC/Sigfox a SCHC-Receiver Abort MUST be 852 sent if, for a single device, all the RuleIDs are being processed 853 by the receiver (i.e., have an active session) at a certain time 854 and a new one is requested, or if the RuleID of the fragment is 855 not valid. 857 * A SCHC-Receiver Abort MUST be triggered when the Inactivity Timer 858 expires. 860 * A SCHC-Receiver Abort can be triggered when the number of ACK 861 attempts is not strictly less than MAX_ACK_REQUESTS. In the case 862 of SCHC/Sigfox, a SCHC-Receiver Abort MUST be sent if the number 863 of repeated SCHC ACKs sent in a row (i.e., synchronized with the 864 ACK REQ case, and with identical bitmaps) is greater than or equal 865 to MAX_ACK_REQUESTS. 867 * Although a SCHC-Receiver Abort can be triggered at any point in 868 time, a SCHC-Receiver Abort downlink message MUST only be sent 869 when there is a downlink transmission opportunity. 871 3.10. Padding 873 The Sigfox payload fields have different characteristics in uplink 874 and downlink. 876 Uplink frames can contain a payload size from 0 to 12 bytes. The 877 Sigfox radio protocol allows sending zero bits, one single bit of 878 information for binary applications (e.g. status), or an integer 879 number of bytes. Therefore, for 2 or more bits of payload it is 880 required to add padding to the next integer number of bytes. The 881 reason for this flexibility is to optimize transmission time and 882 hence save battery consumption at the device. 884 Downlink frames on the other hand have a fixed length. The payload 885 length MUST be 64 bits (i.e. 8 bytes). Hence, if less information 886 bits are to be transmitted, padding MUST be used with bits equal to 887 0. 889 4. Fragmentation Sequence Examples 891 In this section, some sequence diagrams depicting messages exchanges 892 for different fragmentation modes and use cases are shown. In the 893 examples, 'Seq' indicates the Sigfox Sequence Number of the frame 894 carrying a fragment. 896 4.1. Uplink No-ACK Examples 898 The FCN field indicates the size of the data packet. The first 899 fragment is marked with FCN = X-1, where X is the number of fragments 900 the message is split into. All fragments are marked with decreasing 901 FCN values. Last packet fragment is marked with the FCN = All-1 902 (1111). 904 Case No losses - All fragments are sent and received successfully. 906 Sender Receiver 907 |-------FCN=6 (0110), Seq=1-------->| 908 |-------FCN=5 (0101), Seq=2-------->| 909 |-------FCN=4 (0100), Seq=3-------->| 910 |-------FCN=3 (0011), Seq=4-------->| 911 |-------FCN=2 (0010), Seq=5-------->| 912 |-------FCN=1 (0001), Seq=6-------->| 913 |-------FCN=15 (1111), Seq=7------->| All fragments received 914 (End) 916 Figure 20: UL No-ACK No-Losses 918 When the first SCHC fragment is received, the Receiver can calculate 919 the total number of SCHC fragments that the SCHC Packet is composed 920 of. For example, if the first fragment is numbered with FCN=6, the 921 receiver can expect six more messages/fragments (i.e., with FCN going 922 from 5 downwards, and the last fragment with a FCN equal to 15). 924 Case losses on any fragment except the first. 926 Sender Receiver 927 |-------FCN=6, Seq=1-------->| 928 |-------FCN=5, Seq=2----X--->| 929 |-------FCN=4, Seq=3-------->| 930 |-------FCN=3, Seq=4-------->| 931 |-------FCN=2, Seq=5-------->| 932 |-------FCN=1, Seq=6-------->| 933 |-------FCN=15, Seq=7------->| Missing Fragment - Unable to reassemble 934 (End) 936 Figure 21: UL No-ACK Losses (scenario 1) 938 4.2. Uplink ACK-on-Error Examples: Single-byte SCHC Header 940 The single-byte SCHC header ACK-on-Error mode allows sending up to 28 941 fragments and packet sizes up to 300 bytes. The SCHC fragments may 942 be delivered asynchronously and DL ACK can be sent opportunistically. 944 Case No losses 946 The downlink flag must be enabled in the sender UL message to allow a 947 DL message from the receiver. The DL Enable in the figures shows 948 where the sender should enable the downlink, and wait for an ACK. 950 Sender Receiver 951 |-----W=0, FCN=6, Seq=1----->| 952 |-----W=0, FCN=5, Seq=2----->| 953 |-----W=0, FCN=4, Seq=3----->| 954 |-----W=0, FCN=3, Seq=4----->| 955 |-----W=0, FCN=2, Seq=5----->| 956 |-----W=0, FCN=1, Seq=6----->| 957 DL Enable |-----W=0, FCN=0, Seq=7----->| 958 (no ACK) 959 |-----W=1, FCN=6, Seq=8----->| 960 |-----W=1, FCN=5, Seq=9----->| 961 |-----W=1, FCN=4, Seq=10---->| 962 DL Enable |-----W=1, FCN=7, Seq=11---->| All fragments received 963 |<------ ACK, W=1, C=1 ------| C=1 964 (End) 966 Figure 22: UL ACK-on-Error No-Losses 968 Case Fragment losses in first window 969 In this case, fragments are lost in the first window (W=0). After 970 the first All-0 message arrives, the Receiver leverages the 971 opportunity and sends a SCHC ACK with the corresponding bitmap and 972 C=0. 974 After the loss fragments from the first window (W=0) are resent, the 975 sender continues transmitting the fragments of the following window 976 (W=1) without opening a reception opportunity. Finally, the All-1 977 fragment is sent, the downlink is enabled, and the SCHC ACK is 978 received with C=1. 980 Sender Receiver 981 |-----W=0, FCN=6, Seq=1----->| 982 |-----W=0, FCN=5, Seq=2--X-->| 983 |-----W=0, FCN=4, Seq=3----->| 984 |-----W=0, FCN=3, Seq=4----->| 985 |-----W=0, FCN=2, Seq=5--X-->| 986 |-----W=0, FCN=1, Seq=6----->| 987 DL Enable |-----W=0, FCN=0, Seq=7----->| Missing Fragments W=0 => FCN=5, Seq=2 and FCN=2, Seq=5 988 |<------ ACK, W=0, C=0 ------| Bitmap:1011011 989 |-----W=0, FCN=5, Seq=8----->| 990 |-----W=0, FCN=2, Seq=9----->| 991 |-----W=1, FCN=6, Seq=10---->| 992 |-----W=1, FCN=5, Seq=11---->| 993 |-----W=1, FCN=4, Seq=12---->| 994 DL Enable |-----W=1, FCN=7, Seq=13---->| All fragments received 995 |<------ ACK, W=1, C=1 ------| C=1 996 (End) 998 Figure 23: UL ACK-on-Error Losses on First Window 1000 Case Fragment All-0 lost in first window (W=0) 1002 In this example, the All-0 of the first window (W=0) is lost. 1003 Therefore, the Receiver waits for the next All-0 message of 1004 intermediate windows, or All-1 message of last window to generate the 1005 corresponding SCHC ACK, notifying the absence of the All-0 of window 1006 0. 1008 The sender resends the missing All-0 messages (with any other missing 1009 fragment from window 0) without opening a reception opportunity. 1011 Sender Receiver 1012 |-----W=0, FCN=6, Seq=1----->| 1013 |-----W=0, FCN=5, Seq=2----->| 1014 |-----W=0, FCN=4, Seq=3----->| 1015 |-----W=0, FCN=3, Seq=4----->| 1016 |-----W=0, FCN=2, Seq=5----->| 1017 |-----W=0, FCN=1, Seq=6----->| DL Enable 1018 |-----W=0, FCN=0, Seq=7--X-->| 1019 (no ACK) 1020 |-----W=1, FCN=6, Seq=8----->| 1021 |-----W=1, FCN=5, Seq=9----->| 1022 |-----W=1, FCN=4, Seq=10---->| 1023 DL Enable |-----W=1, FCN=7, Seq=11---->| Missing Fragment W=0, FCN=0, Seq=7 1024 |<------ ACK, W=0, C=0 ------| Bitmap:1111110 1025 |-----W=0, FCN=0, Seq=13---->| All fragments received 1026 DL Enable |-----W=1, FCN=7, Seq=14---->| 1027 |<------ ACK, W=1, C=1 ------| C=1 1028 (End) 1030 Figure 24: UL ACK-on-Error All-0 Lost on First Window 1032 In the following diagram, besides the All-0 there are other fragment 1033 losses in the first window (W=0). 1035 Sender Receiver 1036 |-----W=0, FCN=6, Seq=1----->| 1037 |-----W=0, FCN=5, Seq=2--X-->| 1038 |-----W=0, FCN=4, Seq=3----->| 1039 |-----W=0, FCN=3, Seq=4--X-->| 1040 |-----W=0, FCN=2, Seq=5----->| 1041 |-----W=0, FCN=1, Seq=6----->| 1042 DL Enable |-----W=0, FCN=0, Seq=7--X-->| 1043 (no ACK) 1044 |-----W=1, FCN=6, Seq=8----->| 1045 |-----W=1, FCN=5, Seq=9----->| 1046 |-----W=1, FCN=4, Seq=10---->| 1047 DL Enable |-----W=1, FCN=7, Seq=11---->| Missing Fragment W=0 => FCN= 5, 3 and 0 1048 |<------ ACK, W=0, C=0 ------| Bitmap:1010110 1049 |-----W=0, FCN=5, Seq=13---->| 1050 |-----W=0, FCN=3, Seq=14---->| 1051 |-----W=0, FCN=0, Seq=15---->| All fragments received 1052 DL Enable |-----W=1, FCN=7, Seq=16---->| 1053 |<------ ACK, W=1, C=1 ------| C=1 1054 (End) 1056 Figure 25: UL ACK-on-Error All-0 and other Fragments Lost on 1057 First Window 1059 In the next examples, there are fragment losses in both the first 1060 (W=0) and second (W=1) windows. The retransmission cycles after the 1061 All-1 is sent (i.e., not in intermediate windows) should always 1062 finish with an with an All-1, as it serves as an ACK Request message 1063 to confirm the correct reception of the retransmitted fragments. 1065 Sender Receiver 1066 |-----W=0, FCN=6 (110), Seq=1----->| 1067 |-----W=0, FCN=5 (101), Seq=2--X-->| 1068 |-----W=0, FCN=4 (100), Seq=3----->| 1069 |-----W=0, FCN=3 (011), Seq=4--X-->| 1070 |-----W=0, FCN=2 (010), Seq=5----->| 1071 |-----W=0, FCN=1 (001), Seq=6----->| 1072 DL enable |-----W=0, FCN=0 (000), Seq=7--X-->| 1073 (no ACK) 1074 |-----W=1, FCN=6 (110), Seq=8--X-->| 1075 |-----W=1, FCN=5 (101), Seq=9----->| 1076 |-----W=1, FCN=4 (011), Seq=10-X-->| 1077 DL enable |-----W=1, FCN=7 (111), Seq=11---->| Missing Fragment W=0 => FCN= 5, 3 and 0, W=1 => FCN= 6 and 4 1078 |<--- Compound ACK, W=0,1, C=0 ----| Bitmap W=0:1010110, Bitmap W=1:0100001 1079 |-----W=0, FCN=5 (101), Seq=13---->| 1080 |-----W=0, FCN=3 (011), Seq=14---->| 1081 |-----W=0, FCN=0 (000), Seq=15---->| 1082 |-----W=1, FCN=6 (110), Seq=16---->| 1083 |-----W=1, FCN=4 (011), Seq=17---->| All fragments received 1084 DL enable |-----W=1, FCN=7 (111), Seq=18---->| 1085 |<--------- ACK, W=1, C=1 ---------| C=1 1086 (End) 1088 Figure 26: UL ACK-on-Error All-0 and other Fragments Lost on 1089 First and Second Windows (1) 1091 Similar case as above, but with less fragments in the second window 1092 (W=1) 1093 Sender Receiver 1094 |-----W=0, FCN=6 (110), Seq=1----->| 1095 |-----W=0, FCN=5 (101), Seq=2--X-->| 1096 |-----W=0, FCN=4 (100), Seq=3----->| 1097 |-----W=0, FCN=3 (011), Seq=4--X-->| 1098 |-----W=0, FCN=2 (010), Seq=5----->| 1099 |-----W=0, FCN=1 (001), Seq=6----->| 1100 DL enable |-----W=0, FCN=0 (000), Seq=7--X-->| 1101 (no ACK) 1102 |-----W=1, FCN=6 (110), Seq=8--X-->| 1103 DL enable |-----W=1, FCN=7 (111), Seq=9----->| Missing Fragment W=0 => FCN= 5, 3 and 0, W=1 => FCN= 6 and 4 1104 |<--- Compound ACK, W=0,1, C=0 ----| Bitmap W=0:1010110, Bitmap W=1:0000001 1105 |-----W=0, FCN=5 (101), Seq=10---->| 1106 |-----W=0, FCN=3 (011), Seq=11---->| 1107 |-----W=0, FCN=0 (000), Seq=12---->| 1108 |-----W=1, FCN=6 (110), Seq=13---->| All fragments received 1109 DL enable |-----W=1, FCN=7 (111), Seq=14---->| 1110 |<--------- ACK, W=1, C=1 ---------| C=1 1111 (End) 1113 Figure 27: UL ACK-on-Error All-0 and other Fragments Lost on 1114 First and Second Windows (2) 1116 Case SCHC ACK is lost 1118 SCHC over Sigfox does not implement the SCHC ACK REQ message. 1119 Instead it uses the SCHC All-1 message to request a SCHC ACK, when 1120 required. 1122 Sender Receiver 1123 |-----W=0, FCN=6, Seq=1----->| 1124 |-----W=0, FCN=5, Seq=2----->| 1125 |-----W=0, FCN=4, Seq=3----->| 1126 |-----W=0, FCN=3, Seq=4----->| 1127 |-----W=0, FCN=2, Seq=5----->| 1128 |-----W=0, FCN=1, Seq=6----->| 1129 DL Enable |-----W=0, FCN=0, Seq=7----->| 1130 (no ACK) 1131 |-----W=1, FCN=6, Seq=8----->| 1132 |-----W=1, FCN=5, Seq=9----->| 1133 |-----W=1, FCN=4, Seq=10---->| 1134 DL Enable |-----W=1, FCN=7, Seq=11---->| All fragments received 1135 |<------ ACK, W=1, C=1 ---X--| C=1 1136 DL Enable |-----W=1, FCN=7, Seq=13---->| RESEND ACK 1137 |<------ ACK, W=1, C=1 ------| C=1 1138 (End) 1140 Figure 28: UL ACK-on-Error ACK Lost 1142 Case SCHC Compound ACK at the end 1144 In this example, SCHC Fragment losses are found in both windows 0 and 1145 1. However, the sender does not send a SCHC ACK after the All-0 of 1146 window 0. Instead, it sends a SCHC Compound ACK notifying losses of 1147 both windows. 1149 Sender Receiver 1150 |-----W=0, FCN=6 (110), Seq=1----->| 1151 |-----W=0, FCN=5 (101), Seq=2--X-->| 1152 |-----W=0, FCN=4 (100), Seq=3----->| 1153 |-----W=0, FCN=3 (011), Seq=4--X-->| 1154 |-----W=0, FCN=2 (010), Seq=5----->| 1155 |-----W=0, FCN=1 (001), Seq=6----->| 1156 DL enable |-----W=0, FCN=0 (000), Seq=7----->| Waits for next DL opportunity 1157 (no ACK) 1158 |-----W=1, FCN=6 (110), Seq=8--X-->| 1159 DL enable |-----W=1, FCN=7 (111), Seq=9----->| Missing Fragment W=0 => FCN= 5, 3 and 0, W=1 => FCN= 6 and 4 1160 |<--- Compound ACK, W=0,1, C=0 ----| Bitmap W=0:1010110, Bitmap W=1:0000001 1161 |-----W=0, FCN=5 (101), Seq=10---->| 1162 |-----W=0, FCN=3 (011), Seq=11---->| 1163 |-----W=1, FCN=6 (110), Seq=12---->| All fragments received 1164 DL enable |-----W=1, FCN=7 (111), Seq=13---->| 1165 |<--------- ACK, W=1, C=1 ---------| C=1 1166 (End) 1168 Figure 29: UL ACK-on-Error Fragments Lost on First and Second 1169 Windows with one Compound ACK 1171 The number of times the same SCHC ACK message will be retransmitted 1172 is determined by the MAX_ACK_REQUESTS. 1174 4.3. SCHC Abort Examples 1176 Case SCHC Sender-Abort 1178 The sender may need to send a Sender-Abort to stop the current 1179 communication. This may happen, for example, if the All-1 has been 1180 sent MAX_ACK_REQUESTS times. 1182 Sender Receiver 1183 |-----W=0, FCN=6, Seq=1----->| 1184 |-----W=0, FCN=5, Seq=2----->| 1185 |-----W=0, FCN=4, Seq=3----->| 1186 |-----W=0, FCN=3, Seq=4----->| 1187 |-----W=0, FCN=2, Seq=5----->| 1188 |-----W=0, FCN=1, Seq=6----->| 1189 DL Enable |-----W=0, FCN=0, Seq=7----->| 1190 (no ACK) 1191 |-----W=1, FCN=6, Seq=8----->| 1192 |-----W=1, FCN=5, Seq=9----->| 1193 |-----W=1, FCN=4, Seq=10---->| 1194 DL Enable |-----W=1, FCN=7, Seq=11---->| All fragments received 1195 |<------ ACK, W=1, C=1 ---X--| C=1 1196 DL Enable |-----W=1, FCN=7, Seq=14---->| RESEND ACK (1) 1197 |<------ ACK, W=1, C=1 ---X--| C=1 1198 DL Enable |-----W=1, FCN=7, Seq=15---->| RESEND ACK (2) 1199 |<------ ACK, W=1, C=1 ---X--| C=1 1200 DL Enable |-----W=1, FCN=7, Seq=16---->| RESEND ACK (3) 1201 |<------ ACK, W=1, C=1 ---X--| C=1 1202 DL Enable |-----W=1, FCN=7, Seq=17---->| RESEND ACK (4) 1203 |<------ ACK, W=1, C=1 ---X--| C=1 1204 DL Enable |-----W=1, FCN=7, Seq=18---->| RESEND ACK (5) 1205 |<------ ACK, W=1, C=1 ---X--| C=1 1206 DL Enable |----Sender-Abort, Seq=19--->| exit with error condition 1207 (End) 1209 Figure 30: UL ACK-on-Error Sender-Abort 1211 Case Receiver-Abort 1213 The receiver may need to send a Receiver-Abort to stop the current 1214 communication. This message can only be sent after a DL enable. 1216 Sender Receiver 1217 |-----W=0, FCN=6, Seq=1----->| 1218 |-----W=0, FCN=5, Seq=2----->| 1219 |-----W=0, FCN=4, Seq=3----->| 1220 |-----W=0, FCN=3, Seq=4----->| 1221 |-----W=0, FCN=2, Seq=5----->| 1222 |-----W=0, FCN=1, Seq=6----->| 1223 DL Enable |-----W=0, FCN=0, Seq=7----->| 1224 |<------- RECV ABORT -------| under-resourced 1225 (Error) 1227 Figure 31: UL ACK-on-Error Receiver-Abort 1229 5. Security considerations 1231 The radio protocol authenticates and ensures the integrity of each 1232 message. This is achieved by using a unique device ID and an AES-128 1233 based message authentication code, ensuring that the message has been 1234 generated and sent by the device with the ID claimed in the message. 1236 Application data can be encrypted at the application level or not, 1237 depending on the criticality of the use case. This flexibility 1238 allows providing a balance between cost and effort vs. risk. AES-128 1239 in counter mode is used for encryption. Cryptographic keys are 1240 independent for each device. These keys are associated with the 1241 device ID and separate integrity and confidentiality keys are pre- 1242 provisioned. A confidentiality key is only provisioned if 1243 confidentiality is to be used. 1245 The radio protocol has protections against reply attacks, and the 1246 cloud-based core network provides firewalling protection against 1247 undesired incoming communications. 1249 6. Acknowledgements 1251 Carles Gomez has been funded in part by the Spanish Government 1252 through the Jose Castillejo CAS15/00336 grant, the TEC2016-79988-P 1253 grant, and the PID2019-106808RA-I00 grant, and by Secretaria 1254 d'Universitats i Recerca del Departament d'Empresa i Coneixement de 1255 la Generalitat de Catalunya 2017 through grant SGR 376. 1257 Sergio Aguilar has been funded by the ERDF and the Spanish Government 1258 through project TEC2016-79988-P and project PID2019-106808RA-I00, 1259 AEI/FEDER, EU. 1261 Sandra Cespedes has been funded in part by the ANID Chile Project 1262 FONDECYT Regular 1201893 and Basal Project FB0008. 1264 Diego Wistuba has been funded by the ANID Chile Project FONDECYT 1265 Regular 1201893. 1267 The authors would like to thank Clement Mannequin, Rafael Vidal, 1268 Julien Boite, Renaud Marty, and Antonis Platis for their useful 1269 comments and implementation design considerations. 1271 7. References 1273 7.1. Normative References 1275 [I-D.ietf-lpwan-schc-compound-ack] 1276 Zuniga, JC., Gomez, C., Aguilar, S., Toutain, L., 1277 Cespedes, S., and D. Wistuba, "SCHC Compound ACK", Work in 1278 Progress, Internet-Draft, draft-ietf-lpwan-schc-compound- 1279 ack-00, July 2021, . 1282 [RFC8376] Farrell, S., Ed., "Low-Power Wide Area Network (LPWAN) 1283 Overview", RFC 8376, DOI 10.17487/RFC8376, May 2018, 1284 . 1286 [RFC8724] Minaburo, A., Toutain, L., Gomez, C., Barthel, D., and JC. 1287 Zuniga, "SCHC: Generic Framework for Static Context Header 1288 Compression and Fragmentation", RFC 8724, 1289 DOI 10.17487/RFC8724, April 2020, 1290 . 1292 7.2. Informative References 1294 [sigfox-callbacks] 1295 Sigfox, "Sigfox Callbacks", 1296 . 1298 [sigfox-spec] 1299 Sigfox, "Sigfox Radio Specifications", 1300 . 1303 Authors' Addresses 1305 Juan Carlos Zúñiga 1306 Montreal QC 1307 Canada 1308 Email: j.c.zuniga@ieee.org 1309 Carles Gomez 1310 Universitat Politècnica de Catalunya 1311 C/Esteve Terradas, 7 1312 08860 Castelldefels 1313 Spain 1314 Email: carlesgo@entel.upc.edu 1316 Sergio Aguilar 1317 Universitat Politècnica de Catalunya 1318 C/Esteve Terradas, 7 1319 08860 Castelldefels 1320 Spain 1321 Email: sergio.aguilar.romero@upc.edu 1323 Laurent Toutain 1324 IMT-Atlantique 1325 2 rue de la Chataigneraie 1326 CS 17607 1327 35576 Cesson-Sevigne Cedex 1328 France 1329 Email: Laurent.Toutain@imt-atlantique.fr 1331 Sandra Cespedes 1332 NIC Labs, Universidad de Chile 1333 Av. Almte. Blanco Encalada 1975 1334 Santiago 1335 Chile 1336 Email: scespedes@niclabs.cl 1338 Diego Wistuba 1339 NIC Labs, Universidad de Chile 1340 Av. Almte. Blanco Encalada 1975 1341 Santiago 1342 Chile 1343 Email: wistuba@niclabs.cl 1345 Julien Boite 1346 SIGFOX 1347 Labege 1348 France 1349 Email: julien.boite@sigfox.com 1350 URI: http://www.sigfox.com/