idnits 2.17.1 draft-ietf-lpwan-schc-over-sigfox-04.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.) ** 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 280: '...ntation mode, a DL opportunity MUST be...' RFC 2119 keyword, line 291: '...m All-0 or All-1 MUST NOT use the DL r...' RFC 2119 keyword, line 296: '... The RuleID MUST be included in the ...' RFC 2119 keyword, line 323: '...ss of a SCHC Packet MUST be checked at...' RFC 2119 keyword, line 333: '...eck Sequence (RCS) is NOT RECOMMENDED....' (12 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 31, 2020) is 1272 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 2 errors (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 lpwan Working Group JC. Zuniga 3 Internet-Draft SIGFOX 4 Intended status: Informational C. Gomez 5 Expires: May 4, 2021 Universitat Politecnica de Catalunya 6 L. Toutain 7 IMT-Atlantique 8 October 31, 2020 10 SCHC over Sigfox LPWAN 11 draft-ietf-lpwan-schc-over-sigfox-04 13 Abstract 15 The Generic Framework for Static Context Header Compression and 16 Fragmentation (SCHC) specification describes two mechanisms: i) an 17 application header compression scheme, and ii) a frame fragmentation 18 and loss recovery functionality. SCHC offers a great level of 19 flexibility that can be tailored for different Low Power Wide Area 20 Network (LPWAN) technologies. 22 The present document provides the optimal parameters and modes of 23 operation when SCHC is implemented over a Sigfox LPWAN. This set of 24 parameters are also known as a "SCHC over Sigfox profile." 26 Status of This Memo 28 This Internet-Draft is submitted in full conformance with the 29 provisions of BCP 78 and BCP 79. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF). Note that other groups may also distribute 33 working documents as Internet-Drafts. The list of current Internet- 34 Drafts is at https://datatracker.ietf.org/drafts/current/. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 This Internet-Draft will expire on May 4, 2021. 43 Copyright Notice 45 Copyright (c) 2020 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents 50 (https://trustee.ietf.org/license-info) in effect on the date of 51 publication of this document. Please review these documents 52 carefully, as they describe your rights and restrictions with respect 53 to this document. Code Components extracted from this document must 54 include Simplified BSD License text as described in Section 4.e of 55 the Trust Legal Provisions and are provided without warranty as 56 described in the Simplified BSD License. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 61 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 62 3. SCHC: Generic Framework for Static Context Header Compression 63 and Fragmentation . . . . . . . . . . . . . . . . . . . . . . 3 64 4. SCHC over Sigfox . . . . . . . . . . . . . . . . . . . . . . 3 65 4.1. Network Architecture . . . . . . . . . . . . . . . . . . 3 66 4.2. Uplink . . . . . . . . . . . . . . . . . . . . . . . . . 5 67 4.3. Downlink . . . . . . . . . . . . . . . . . . . . . . . . 6 68 4.4. ACK on Downlink . . . . . . . . . . . . . . . . . . . . . 7 69 4.5. SCHC Rules . . . . . . . . . . . . . . . . . . . . . . . 7 70 4.6. Fragmentation . . . . . . . . . . . . . . . . . . . . . . 7 71 4.6.1. Uplink Fragmentation . . . . . . . . . . . . . . . . 8 72 4.6.2. Downlink Fragmentation . . . . . . . . . . . . . . . 11 73 4.7. Padding . . . . . . . . . . . . . . . . . . . . . . . . . 12 74 5. Security considerations . . . . . . . . . . . . . . . . . . . 12 75 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 13 76 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 77 7.1. Normative References . . . . . . . . . . . . . . . . . . 13 78 7.2. Informative References . . . . . . . . . . . . . . . . . 13 79 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13 81 1. Introduction 83 The Generic Framework for Static Context Header Compression and 84 Fragmentation (SCHC) specification [RFC8724] describes two 85 mechanisms: i) an application header compression scheme, and ii) a 86 frame fragmentation and loss recovery functionality. Both can be 87 used on top of all the four LWPAN technologies defined in [RFC8376] . 88 These LPWANs have similar characteristics such as star-oriented 89 topologies, network architecture, connected devices with built-in 90 applications, etc. 92 SCHC offers a great level of flexibility to accommodate all these 93 LPWAN technologies. Even though there are a great number of 94 similarities between them, some differences exist with respect to the 95 transmission characteristics, payload sizes, etc. Hence, there are 96 optimal parameters and modes of operation that can be used when SCHC 97 is used on top of a specific LPWAN technology. 99 This document describes the recommended parameters, settings and 100 modes of operation to be used when SCHC is implemented over a Sigfox 101 LPWAN. This set of parameters are also known as a "SCHC over Sigfox 102 profile." 104 2. Terminology 106 It is assumed that the reader is familiar with the terms and 107 mechanisms defined in [RFC8376] and in [RFC8724]. 109 3. SCHC: Generic Framework for Static Context Header Compression and 110 Fragmentation 112 The Generic Framework for Static Context Header Compression and 113 Fragmentation (SCHC) described in [RFC8724] takes advantage of the 114 predictability of data flows existing in LPWAN applications to avoid 115 context synchronization. 117 Contexts must be stored and pre-configured on both ends. This can be 118 done either by using a provisioning protocol, by out of band means, 119 or by pre-provisioning them (e.g. at manufacturing time). The way 120 contexts are configured and stored on both ends is out of the scope 121 of this document. 123 4. SCHC over Sigfox 125 4.1. Network Architecture 127 Figure 1 represents the architecture for compression/decompression 128 (C/D) and fragmentation/reassembly (F/R) based on the terminology 129 defined in [RFC8376], where the Radio Gateway (RG) is a Sigfox Base 130 Station and the Network Gateway (NGW) is the Sigfox cloud-based 131 Network. 133 Device Application 134 +----------------+ +--------------+ 135 | APP1 APP2 APP3 | |APP1 APP2 APP3| 136 +----------------+ +--------------+ 137 | UDP | | | | UDP | 138 | IPv6 | | | | IPv6 | 139 +--------+ | | +--------+ 140 | SCHC C/D & F/R | | | 141 | | | | 142 +-------+--------+ +--------+-----+ 143 $ . 144 $ +---------+ +--------------+ +---------+ . 145 $ | | | | | Network | . 146 +~~ |Sigfox BS| |Sigfox Network| | SCHC | . 147 | (RG) | === | (NGW) | === |F/R & C/D|..... 148 +---------+ +--------------+ +---------+ 150 Figure 1: Network Architecture 152 In the case of the global Sigfox Network, RGs (or Base Stations) are 153 distributed over multiple countries wherever the Sigfox LPWAN service 154 is provided. The NGW (or cloud-based Sigfox Core Network) is a 155 single entity that connects to all Sigfox base stations in the world, 156 providing hence a global single star network topology. 158 The Device sends application flows that are compressed and/or 159 fragmented by a SCHC Compressor/Decompressor (SCHC C/D + F/R) to 160 reduce headers size and/or fragment the packet. The resulting SCHC 161 Message is sent over a layer two (L2) Sigfox frame to the Sigfox Base 162 Stations, which then forward the SCHC Message to the Network Gateway 163 (NGW). The NGW then delivers the SCHC Message and associated 164 gathered metadata to the Network SCHC C/D + F/R. 166 The Sigfox Network (NGW) communicates with the Network SCHC C/D + F/R 167 for compression/decompression and/or for fragmentation/reassembly. 168 The Network SCHC C/D + F/R share the same set of rules as the Dev 169 SCHC C/D + F/R. The Network SCHC C/D + F/R can be collocated with 170 the NGW or it could be located in a different place, as long as a 171 tunnel or secured communication is established between the NGW and 172 the SCHC C/D + F/R functions. After decompression and/or reassembly, 173 the packet can be forwarded over the Internet to one (or several) 174 LPWAN Application Server(s) (App). 176 The SCHC C/D + F/R processes are bidirectional, so the same 177 principles are applicable on both uplink (UL) and downlink (DL). 179 4.2. Uplink 181 Uplink Sigfox transmissions occur in repetitions over different times 182 and frequencies. Besides these time and frequency diversities, the 183 Sigfox network also provides space diversity, as potentially an 184 uplink message will be received by several base stations. 186 Since all messages are self-contained and base stations forward all 187 these messages back to the same Core Network, multiple input copies 188 can be combined at the NGW and hence provide for extra reliability 189 based on the triple diversity (i.e. time, space and frequency). 191 A detailed description of the Sigfox Radio Protocol can be found in 192 [sigfox-spec]. 194 Messages sent from the Device to the Network are delivered by the 195 Sigfox network (NGW) to the Network SCHC C/D + F/R through a 196 callback/API with the following information: 198 o Device ID 200 o Message Sequence Number 202 o Message Payload 204 o Message Timestamp 206 o Device Geolocation (optional) 208 o RSSI (optional) 210 o Device Temperature (optional) 212 o Device Battery Voltage (optional) 214 The Device ID is a globally unique identifier assigned to the Device, 215 which is included in the Sigfox header of every message. The Message 216 Sequence Number is a monotonically increasing number identifying the 217 specific transmission of this uplink message, and it is also part of 218 the Sigfox header. The Message Payload corresponds to the payload 219 that the Device has sent in the uplink transmission. 221 The Message Timestamp, Device Geolocation, RSSI, Device Temperature 222 and Device Battery Voltage are metadata parameters provided by the 223 Network. 225 A detailed description of the Sigfox callbacks/APIs can be found in 226 [sigfox-callbacks]. 228 Only messages that have passed the L2 Cyclic Redundancy Check (CRC) 229 at network reception are delivered by the Sigfox Network to the 230 Network SCHC C/D + F/R. 232 +---------------+-----------------+ 233 | Sigfox Header | Sigfox payload | 234 +---------------+---------------- + 235 | SCHC message | 236 +-----------------+ 238 Figure 2: SCHC Message in Sigfox 240 Figure 2 shows a SCHC Message sent over Sigfox, where the SCHC 241 Message could be a full SCHC Packet (e.g. compressed) or a SCHC 242 Fragment (e.g. a piece of a bigger SCHC Packet). 244 4.3. Downlink 246 Downlink transmissions are Device-driven and can only take place 247 following an uplink communication that so indicates. Hence, a Device 248 willing to receive a downlink message indicates explicitly its 249 intention to the network in the preceding uplink message with a 250 downlink request flag, and then it opens a fixed window for downlink 251 reception after completing the uplink transmission. The delay and 252 duration of the reception opportunity window have fixed values. If 253 there is a downlink message to be sent for this given Device (e.g. 254 either a response to the uplink message or queued information waiting 255 to be transmitted), the network transmits it to the Device during the 256 reception window. If no message is received by the Device after the 257 reception opportunity window has elapsed, the Device closes the 258 receiving opportunity and gets back to the normal mode (e.g. continue 259 UL transmissions, sleep, stand-by, etc.) 261 When a downlink message is sent to a Device, a reception 262 acknowledgement is generated by the Device back to the Network 263 through the Sigfox protocol and reported by the Sigfox Network. This 264 acknowledgement can be retrieved through callbacks by the customer. 266 A detailed description of the Sigfox Radio Protocol can be found in 267 [sigfox-spec] and a detailed description of the Sigfox callbacks/APIs 268 can be found in [sigfox-callbacks]. 270 4.4. ACK on Downlink 272 As explained previously, downlink transmissions are Device-driven and 273 can only take place following a specific uplink transmission that 274 indicates and allows a following downlink opportunity. For this 275 reason, when SCHC bi-directional services are used (e.g. Ack-on- 276 Error fragmentation mode) the SCHC protocol implementation needs to 277 consider the times when a downlink message (e.g. ACK) can be sent 278 and/or received. 280 For the UL ACK-on-Error fragmentation mode, a DL opportunity MUST be 281 indicated by the last fragment of every window (i.e. FCN = All-0, or 282 FCN = All-1). The Device sends the fragments in sequence and, after 283 transmitting the FCN = All-0 or FCN = All-1, it opens up a reception 284 opportunity. The Network SCHC can then decide to respond at that 285 opportunity (or wait for a further one) with a SCHC-ACK indicating in 286 case there are missing fragments from the current or previous 287 windows. If there is no SCHC-ACK to be sent, or if the network 288 decides to wait for a further DL transmission opportunity, then no DL 289 transmission takes place at that opportunity and after a timeout the 290 UL transmissions continue. Intermediate SCHC fragments with FCN 291 different from All-0 or All-1 MUST NOT use the DL request flag to 292 request a SCHC-ACK. 294 4.5. SCHC Rules 296 The RuleID MUST be included in the SCHC header. The total number of 297 rules to be used affects directly the Rule ID field size, and 298 therefore the total size of the fragmentation header. For this 299 reason, it is recommended to keep the number of rules that are 300 defined for a specific device to the minimum possible. 302 RuleIDs can be used to differentiate data traffic classes (e.g. QoS, 303 control vs. data, etc.), and data sessions. They can also be used to 304 interleave simultaneous fragmentation sessions between a Device and 305 the Network. 307 4.6. Fragmentation 309 The SCHC specification [RFC8724] defines a generic fragmentation 310 functionality that allows sending data packets or files larger than 311 the maximum size of a Sigfox data frame. The functionality also 312 defines a mechanism to send reliably multiple messages, by allowing 313 to resend selectively any lost fragments. 315 The SCHC fragmentation supports several modes of operation. These 316 modes have different advantages and disadvantages depending on the 317 specifics of the underlying LPWAN technology and application Use 318 Case. This section describes how the SCHC fragmentation 319 functionality should optimally be implemented when used over a Sigfox 320 LPWAN for the most typical Use Case applications. 322 As described in section 8.2.3 of [RFC8724], the integrity of the 323 fragmentation-reassembly process of a SCHC Packet MUST be checked at 324 the receive end. Since only UL messages/fragments that have passed 325 the CRC-check are delivered to the Network SCHC C/D + F/R, and each 326 one has an associated Sigfox Message Sequence Number (see 327 Section 4.2), integrity can be guaranteed when no consecutive 328 messages are missing from the sequence and all FCN bitmaps are 329 complete. In order to support multiple flows/RuleIDs (potentially 330 interleaved), the implementation of a central message sequence 331 counter at the Network SCHC C/D + F/R is required. With this 332 functionality and in order to save protocol overhead, the use of a 333 dedicated Reassembly Check Sequence (RCS) is NOT RECOMMENDED. 335 The L2 Word Size used by Sigfox is 1 byte (8 bits). 337 4.6.1. Uplink Fragmentation 339 Sigfox uplink transmissions are completely asynchronous and can take 340 place in any random frequency of the allowed uplink bandwidth 341 allocation. Hence, devices can go to deep sleep mode, and then wake 342 up and transmit whenever there is a need to send any information to 343 the network. In that way, there is no need to perform any network 344 attachment, synchronization, or other procedure before transmitting a 345 data packet. All data packets are self-contained (aka "message in a 346 bottle") with all the required information for the network to process 347 them accordingly. 349 Since uplink transmissions occur asynchronously, an SCHC fragment can 350 be transmitted at any given time by the Device. Sigfox uplink 351 messages are fixed in size, and as described in [RFC8376] they can 352 carry 0-12 bytes payload. Hence, a single SCHC Tile size per 353 fragmentation mode can be defined so that every Sigfox message always 354 carries one SCHC Tile. 356 4.6.1.1. Uplink No-ACK Mode 358 No-ACK is RECOMMENDED to be used for transmitting short, non-critical 359 packets that require fragmentation and do not require full 360 reliability. This mode can be used by uplink-only devices that do 361 not support downlink communications, or by bidirectional devices when 362 they send non-critical data. 364 Since there are no multiple windows in the No-ACK mode, the W bit is 365 not present. However it is RECOMMENDED to use the FCN field to 366 indicate the size of the data packet. In this sense, the data packet 367 would need to be splitted into X fragments and, similarly to the 368 other fragmentation modes, the first transmitted fragment would need 369 to be marked with FCN = X-1. Consecutive fragments MUST be marked 370 with decreasing FCN values, having the last fragment marked with FCN 371 = (All-1). Hence, even though the No-ACK mode does not allow 372 recovering missing fragments, it allows indicating implicitly the 373 size of the expected packet to the Network and hence detect at the 374 receiver side whether all fragments have been received or not. 376 The RECOMMENDED Fragmentation Header size is 8 bits, and it is 377 composed as follows: 379 o RuleID size: 4 bits 381 o DTag size (T): 0 bits 383 o Fragment Compressed Number (FCN) size (N): 4 bits 385 o As per [RFC8724], in the No-ACK mode the W (window) field is not 386 present. 388 o RCS size: 0 bits (Not used) 390 4.6.1.2. Uplink ACK-on-Error Mode: Single-byte SCHC Header 392 ACK-on-Error with single-byte header is RECOMMENDED for medium-large 393 size packets that need to be sent reliably. ACK-on-Error is optimal 394 for Sigfox transmissions, since it leads to a reduced number of ACKs 395 in the lower capacity downlink channel. Also, downlink messages can 396 be sent asynchronously and opportunistically. 398 Allowing transmission of packets/files up to 300 bytes long, the SCHC 399 uplink Fragmentation Header size is RECOMMENDED to be 8 bits in size 400 and is composed as follows: 402 o Rule ID size: 3 bits 404 o DTag size (T): 0 bits 406 o Window index (W) size (M): 2 bits 408 o Fragment Compressed Number (FCN) size (N): 3 bits 410 o MAX_ACK_REQUESTS: 5 412 o WINDOW_SIZE: 7 (with a maximum value of FCN=0b110) 413 o Tile size: 11 bytes 415 o Retransmission Timer: Application-dependent 417 o Inactivity Timer: Application-dependent 419 o RCS size: 0 bits (Not used) 421 The correspondent SCHC ACK in the downlink is 13 bits long, so 422 padding is needed to complete the required 64 bits of Sigfox payload. 424 4.6.1.3. Uplink ACK-on-Error Mode: Two-byte SCHC Header 426 ACK-on-Error with two-byte header is RECOMMENDED for very large size 427 packets that need to be sent reliably. ACK-on-Error is optimal for 428 Sigfox transmissions, since it leads to a reduced number of ACKs in 429 the lower capacity downlink channel. Also, downlink messages can be 430 sent asynchronously and opportunistically. 432 In order to allow transmission of very large packets/files up to 2250 433 bytes long, the SCHC uplink Fragmentation Header size is RECOMMENDED 434 to be 16 bits in size and composed as follows: 436 o Rule ID size is: 8 bits 438 o DTag size (T) is: 0 bits 440 o Window index (W) size (M): 3 bits 442 o Fragment Compressed Number (FCN) size (N): 5 bits. 444 o MAX_ACK_REQUESTS: 5 446 o WINDOW_SIZE: 31 (with a maximum value of FCN=0b11110) 448 o Tile size: 10 bytes 450 o Retransmission Timer: Application-dependent 452 o Inactivity Timer: Application-dependent 454 o RCS size: 0 bits (Not used) 456 The correspondent SCHC ACK in the downlink is 43 bits long, so 457 padding is needed to complete the required 64 bits of Sigfox payload. 459 4.6.1.4. All-1 behaviour + Sigfox Sequence Number 461 For ACK-on-Error, as defined in [RFC8724] it is expected that the 462 last SCHC fragment of the last window will always be delivered with 463 an All-1 FCN. Since this last window may not be full (i.e. it may be 464 comprised of less than WINDOW_SIZE fragments), an All-1 fragment may 465 follow a value of FCN higher than 1 (0b01). In this case, the 466 receiver could not derive from the FCN values alone whether there are 467 any missing fragments right before the All-1 fragment or not. 469 However, since a Message Sequence Number is provided by the Sigfox 470 protocol together with the Sigfox Payload, the receiver can detect if 471 there are missing fragments before the All-1 and hence construct the 472 corresponding SCHC ACK Bitmap accordingly. 474 4.6.2. Downlink Fragmentation 476 In some LPWAN technologies, as part of energy-saving techniques, 477 downlink transmission is only possible immediately after an uplink 478 transmission. This allows the device to go in a very deep sleep mode 479 and preserve battery, without the need to listen to any information 480 from the network. This is the case for Sigfox-enabled devices, which 481 can only listen to downlink communications after performing an uplink 482 transmission and requesting a downlink. 484 When there are fragments to be transmitted in the downlink, an uplink 485 message is required to trigger the downlink communication. In order 486 to avoid potentially high delay for fragmented datagram transmission 487 in the downlink, the fragment receiver MAY perform an uplink 488 transmission as soon as possible after reception of a downlink 489 fragment that is not the last one. Such uplink transmission MAY be 490 triggered by sending a SCHC message, such as a SCHC ACK. However, 491 other data messages can equally be used to trigger DL communications. 493 Sigfox downlink messages are fixed in size, and as described in 494 [RFC8376] they can carry up to 8 bytes payload. Hence, a single SCHC 495 Tile size per mode can be defined so that every Sigfox message always 496 carries one SCHC Tile. 498 For reliable downlink fragment transmission, the ACK-Always mode is 499 RECOMMENDED. 501 The SCHC downlink Fragmentation Header size is RECOMMENDED to be 8 502 bits in size and is composed as follows: 504 o RuleID size: 3 bits 506 o DTag size (T): 0 bits 507 o Window index (W) size (M) is: 0 bits 509 o Fragment Compressed Number (FCN) size (N): 5 bits 511 o MAX_ACK_REQUESTS: 5 513 o WINDOW_SIZE: 31 (with a maximum value of FCN=0b11110) 515 o Tile size: 7 bytes 517 o Retransmission Timer: Application-dependent 519 o Inactivity Timer: Application-dependent 521 o RCS size: 0 bits (Not used) 523 4.7. Padding 525 The Sigfox payload fields have different characteristics in uplink 526 and downlink. 528 Uplink frames can contain a payload size from 0 to 12 bytes. The 529 radio protocol allows sending zero bits, one single bit of 530 information for binary applications (e.g. status), or an integer 531 number of bytes. Therefore, for 2 or more bits of payload it is 532 required to add padding to the next integer number of bytes. The 533 reason for this flexibility is to optimize transmission time and 534 hence save battery consumption at the device. 536 Downlink frames on the other hand have a fixed length. The payload 537 length must be 64 bits (i.e. 8 bytes). Hence, if less information 538 bits are to be transmitted, padding would be necessary. 540 5. Security considerations 542 The radio protocol authenticates and ensures the integrity of each 543 message. This is achieved by using a unique device ID and an AES-128 544 based message authentication code, ensuring that the message has been 545 generated and sent by the device with the ID claimed in the message. 547 Application data can be encrypted at the application level or not, 548 depending on the criticality of the use case. This flexibility 549 allows providing a balance between cost and effort vs. risk. AES-128 550 in counter mode is used for encryption. Cryptographic keys are 551 independent for each device. These keys are associated with the 552 device ID and separate integrity and confidentiality keys are pre- 553 provisioned. A confidentiality key is only provisioned if 554 confidentiality is to be used. 556 The radio protocol has protections against reply attacks, and the 557 cloud-based core network provides firewalling protection against 558 undesired incoming communications. 560 6. Acknowledgements 562 Carles Gomez has been funded in part by the ERDF and the Spanish 563 Government through project TEC2016-79988-P. 565 The authors would like to thank Diego Wistuba, Sergio Aguilar, 566 Clement Mannequin, Sandra Cespedes and Rafel Vidal for their useful 567 comments and implementation design considerations. 569 7. References 571 7.1. Normative References 573 [RFC8376] Farrell, S., Ed., "Low-Power Wide Area Network (LPWAN) 574 Overview", RFC 8376, DOI 10.17487/RFC8376, May 2018, 575 . 577 [RFC8724] Minaburo, A., Toutain, L., Gomez, C., Barthel, D., and JC. 578 Zuniga, "SCHC: Generic Framework for Static Context Header 579 Compression and Fragmentation", RFC 8724, 580 DOI 10.17487/RFC8724, April 2020, 581 . 583 7.2. Informative References 585 [sigfox-callbacks] 586 Sigfox, "Sigfox Callbacks", 587 . 589 [sigfox-spec] 590 Sigfox, "Sigfox Radio Specifications", 591 . 594 Authors' Addresses 596 Juan Carlos Zuniga 597 SIGFOX 598 Montreal QC 599 Canada 601 Email: JuanCarlos.Zuniga@sigfox.com 602 URI: http://www.sigfox.com/ 603 Carles Gomez 604 Universitat Politecnica de Catalunya 605 C/Esteve Terradas, 7 606 08860 Castelldefels 607 Spain 609 Email: carlesgo@entel.upc.edu 611 Laurent Toutain 612 IMT-Atlantique 613 2 rue de la Chataigneraie 614 CS 17607 615 35576 Cesson-Sevigne Cedex 616 France 618 Email: Laurent.Toutain@imt-atlantique.fr