< draft-ietf-lpwan-schc-over-sigfox-03.txt   draft-ietf-lpwan-schc-over-sigfox-04.txt >
lpwan Working Group JC. Zuniga lpwan Working Group JC. Zuniga
Internet-Draft SIGFOX Internet-Draft SIGFOX
Intended status: Informational C. Gomez Intended status: Informational C. Gomez
Expires: January 14, 2021 Universitat Politecnica de Catalunya Expires: May 4, 2021 Universitat Politecnica de Catalunya
L. Toutain L. Toutain
IMT-Atlantique IMT-Atlantique
July 13, 2020 October 31, 2020
SCHC over Sigfox LPWAN SCHC over Sigfox LPWAN
draft-ietf-lpwan-schc-over-sigfox-03 draft-ietf-lpwan-schc-over-sigfox-04
Abstract Abstract
The Generic Framework for Static Context Header Compression and The Generic Framework for Static Context Header Compression and
Fragmentation (SCHC) specification describes both, an application Fragmentation (SCHC) specification describes two mechanisms: i) an
header compression scheme, and a frame fragmentation and loss application header compression scheme, and ii) a frame fragmentation
recovery functionality for Low Power Wide Area Network (LPWAN) and loss recovery functionality. SCHC offers a great level of
technologies. SCHC offers a great level of flexibility that can be flexibility that can be tailored for different Low Power Wide Area
tailored for different LPWAN technologies. Network (LPWAN) technologies.
The present document provides the optimal parameters and modes of The present document provides the optimal parameters and modes of
operation when SCHC is implemented over a Sigfox LPWAN. This set of operation when SCHC is implemented over a Sigfox LPWAN. This set of
parameters are also known as a "SCHC over Sigfox profile." parameters are also known as a "SCHC over Sigfox profile."
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on January 14, 2021. This Internet-Draft will expire on May 4, 2021.
Copyright Notice Copyright Notice
Copyright (c) 2020 IETF Trust and the persons identified as the Copyright (c) 2020 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 25 skipping to change at page 2, line 25
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. SCHC: Generic Framework for Static Context Header Compression 3. SCHC: Generic Framework for Static Context Header Compression
and Fragmentation . . . . . . . . . . . . . . . . . . . . . . 3 and Fragmentation . . . . . . . . . . . . . . . . . . . . . . 3
4. SCHC over Sigfox . . . . . . . . . . . . . . . . . . . . . . 3 4. SCHC over Sigfox . . . . . . . . . . . . . . . . . . . . . . 3
4.1. Network Architecture . . . . . . . . . . . . . . . . . . 3 4.1. Network Architecture . . . . . . . . . . . . . . . . . . 3
4.2. Uplink . . . . . . . . . . . . . . . . . . . . . . . . . 5 4.2. Uplink . . . . . . . . . . . . . . . . . . . . . . . . . 5
4.3. Downlink . . . . . . . . . . . . . . . . . . . . . . . . 6 4.3. Downlink . . . . . . . . . . . . . . . . . . . . . . . . 6
4.4. SCHC Rules . . . . . . . . . . . . . . . . . . . . . . . 6 4.4. ACK on Downlink . . . . . . . . . . . . . . . . . . . . . 7
4.5. Fragmentation . . . . . . . . . . . . . . . . . . . . . . 7 4.5. SCHC Rules . . . . . . . . . . . . . . . . . . . . . . . 7
4.5.1. Uplink Fragmentation . . . . . . . . . . . . . . . . 7 4.6. Fragmentation . . . . . . . . . . . . . . . . . . . . . . 7
4.5.2. Downlink Fragmentation . . . . . . . . . . . . . . . 10 4.6.1. Uplink Fragmentation . . . . . . . . . . . . . . . . 8
4.6. Padding . . . . . . . . . . . . . . . . . . . . . . . . . 11 4.6.2. Downlink Fragmentation . . . . . . . . . . . . . . . 11
5. Security considerations . . . . . . . . . . . . . . . . . . . 11 4.7. Padding . . . . . . . . . . . . . . . . . . . . . . . . . 12
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 12 5. Security considerations . . . . . . . . . . . . . . . . . . . 12
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 13
7.1. Normative References . . . . . . . . . . . . . . . . . . 12 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 13
7.2. Informative References . . . . . . . . . . . . . . . . . 12 7.1. Normative References . . . . . . . . . . . . . . . . . . 13
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 7.2. Informative References . . . . . . . . . . . . . . . . . 13
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13
1. Introduction 1. Introduction
The Generic Framework for Static Context Header Compression and The Generic Framework for Static Context Header Compression and
Fragmentation (SCHC) specification [RFC8724] defines both, a higher Fragmentation (SCHC) specification [RFC8724] describes two
layer header compression scheme and a fragmentation and loss recovery mechanisms: i) an application header compression scheme, and ii) a
functionality. Both can be used on top of all the LWPAN systems frame fragmentation and loss recovery functionality. Both can be
defined in [RFC8376] . These LPWAN systems have similar used on top of all the four LWPAN technologies defined in [RFC8376] .
characteristics such as star-oriented topologies, network These LPWANs have similar characteristics such as star-oriented
architecture, connected devices with built-in applications, etc. topologies, network architecture, connected devices with built-in
applications, etc.
SCHC offers a great level of flexibility to accommodate all these SCHC offers a great level of flexibility to accommodate all these
LPWAN systems. Even though there are a great number of similarities LPWAN technologies. Even though there are a great number of
between LPWAN technologies, some differences exist with respect to similarities between them, some differences exist with respect to the
the transmission characteristics, payload sizes, etc. Hence, there transmission characteristics, payload sizes, etc. Hence, there are
are optimal parameters and modes of operation that can be used when optimal parameters and modes of operation that can be used when SCHC
SCHC is used on top of a specific LPWAN. is used on top of a specific LPWAN technology.
This document describes the recommended parameters, settings and This document describes the recommended parameters, settings and
modes of operation to be used when SCHC is implemented over a Sigfox modes of operation to be used when SCHC is implemented over a Sigfox
LPWAN. This set of parameters are also known as a "SCHC over Sigfox LPWAN. This set of parameters are also known as a "SCHC over Sigfox
profile." profile."
2. Terminology 2. Terminology
It is assumed that the reader is familiar with the terms and It is assumed that the reader is familiar with the terms and
mechanisms defined in [RFC8376] and in [RFC8724]. mechanisms defined in [RFC8376] and in [RFC8724].
3. SCHC: Generic Framework for Static Context Header Compression and 3. SCHC: Generic Framework for Static Context Header Compression and
Fragmentation Fragmentation
The Generic Framework for Static Context Header Compression and The Generic Framework for Static Context Header Compression and
Fragmentation (SCHC) described in [RFC8724] takes advantage of the Fragmentation (SCHC) described in [RFC8724] takes advantage of the
predictability of data flows existing in LPWAN networks to avoid predictability of data flows existing in LPWAN applications to avoid
context synchronization. context synchronization.
Contexts must be stored and pre-configured on both ends. This can be Contexts must be stored and pre-configured on both ends. This can be
done either by using a provisioning protocol, by out of band means, done either by using a provisioning protocol, by out of band means,
or by pre-provisioning them (e.g. at manufacturing time). The way or by pre-provisioning them (e.g. at manufacturing time). The way
contexts are configured and stored on both ends is out of the scope contexts are configured and stored on both ends is out of the scope
of this document. of this document.
4. SCHC over Sigfox 4. SCHC over Sigfox
skipping to change at page 4, line 17 skipping to change at page 4, line 17
| APP1 APP2 APP3 | |APP1 APP2 APP3| | APP1 APP2 APP3 | |APP1 APP2 APP3|
+----------------+ +--------------+ +----------------+ +--------------+
| UDP | | | | UDP | | UDP | | | | UDP |
| IPv6 | | | | IPv6 | | IPv6 | | | | IPv6 |
+--------+ | | +--------+ +--------+ | | +--------+
| SCHC C/D & F/R | | | | SCHC C/D & F/R | | |
| | | | | | | |
+-------+--------+ +--------+-----+ +-------+--------+ +--------+-----+
$ . $ .
$ +---------+ +--------------+ +---------+ . $ +---------+ +--------------+ +---------+ .
+~~ |Sigfox BS| |Sigfox Network| | SCHC | . $ | | | | | Network | .
+~~ |Sigfox BS| |Sigfox Network| | SCHC | .
| (RG) | === | (NGW) | === |F/R & C/D|..... | (RG) | === | (NGW) | === |F/R & C/D|.....
+---------+ +--------------+ +---------+ +---------+ +--------------+ +---------+
Figure 1: Network Architecture Figure 1: Network Architecture
In the case of the global Sigfox Network, RGs (or Base Stations) are In the case of the global Sigfox Network, RGs (or Base Stations) are
distributed over multiple countries wherever the Sigfox LPWAN service distributed over multiple countries wherever the Sigfox LPWAN service
is provided. The NGW (or cloud-based Sigfox Core Network) is a is provided. The NGW (or cloud-based Sigfox Core Network) is a
single entity that connects to all Sigfox base stations in the world, single entity that connects to all Sigfox base stations in the world,
providing hence a global single star network topology. providing hence a global single star network topology.
The Device is sending applications flows that are compressed and/or The Device sends application flows that are compressed and/or
fragmented by a SCHC Compressor/Decompressor (SCHC C/D + F/R) to fragmented by a SCHC Compressor/Decompressor (SCHC C/D + F/R) to
reduce headers size and/or fragment the packet. The resulting SCHC reduce headers size and/or fragment the packet. The resulting SCHC
Message is sent over a layer two (L2) Sigfox frame to the Sigfox Base Message is sent over a layer two (L2) Sigfox frame to the Sigfox Base
Stations, which then forward the SCHC Message to the Network Gateway Stations, which then forward the SCHC Message to the Network Gateway
(NGW). The NGW then delivers the SCHC Message and associated (NGW). The NGW then delivers the SCHC Message and associated
gathered metadata to the Network SCHC C/D + F/R. gathered metadata to the Network SCHC C/D + F/R.
The Sigfox Network (NGW) communicates with the Network SCHC C/D + F/R The Sigfox Network (NGW) communicates with the Network SCHC C/D + F/R
for compression/decompression and/or for fragmentation/reassembly. for compression/decompression and/or for fragmentation/reassembly.
The Network SCHC C/D + F/R share the same set of rules as the Dev The Network SCHC C/D + F/R share the same set of rules as the Dev
SCHC C/D + F/R. The Network SCHC C/D + F/R can be collocated with SCHC C/D + F/R. The Network SCHC C/D + F/R can be collocated with
the NGW or it could be located in a different place, as long as a the NGW or it could be located in a different place, as long as a
tunnel or secured communication is established between the NGW and tunnel or secured communication is established between the NGW and
the SCHC C/D + F/R functions. After decompression and/or reassembly, the SCHC C/D + F/R functions. After decompression and/or reassembly,
the packet can be forwarded over the Internet to one (or several) the packet can be forwarded over the Internet to one (or several)
LPWAN Application Server(s) (App). LPWAN Application Server(s) (App).
The SCHC C/D + F/R processes are bidirectional, so the same The SCHC C/D + F/R processes are bidirectional, so the same
principles are applicable on both uplink and downlink. principles are applicable on both uplink (UL) and downlink (DL).
4.2. Uplink 4.2. Uplink
Uplink Sigfox transmissions occur in repetitions over different times Uplink Sigfox transmissions occur in repetitions over different times
and frequencies. Besides these time and frequency diversities, the and frequencies. Besides these time and frequency diversities, the
Sigfox network also provides space diversity, as potentially an Sigfox network also provides space diversity, as potentially an
uplink message will be received by several base stations. uplink message will be received by several base stations.
Since all messages are self-contained and base stations forward them Since all messages are self-contained and base stations forward all
all back to the same Core Network, multiple input copies can be these messages back to the same Core Network, multiple input copies
combined at the NGW and hence provide for extra reliability based on can be combined at the NGW and hence provide for extra reliability
the triple diversity (i.e. time, space and frequency). based on the triple diversity (i.e. time, space and frequency).
A detailed description of the Sigfox Radio Protocol can be found in A detailed description of the Sigfox Radio Protocol can be found in
[sigfox-spec]. [sigfox-spec].
Messages sent from the Device to the Network are delivered by the Messages sent from the Device to the Network are delivered by the
Sigfox network (NGW) to the Network SCHC C/D + F/R through a Sigfox network (NGW) to the Network SCHC C/D + F/R through a
callback/API with the following information: callback/API with the following information:
o Device ID o Device ID
skipping to change at page 5, line 43 skipping to change at page 5, line 43
o RSSI (optional) o RSSI (optional)
o Device Temperature (optional) o Device Temperature (optional)
o Device Battery Voltage (optional) o Device Battery Voltage (optional)
The Device ID is a globally unique identifier assigned to the Device, The Device ID is a globally unique identifier assigned to the Device,
which is included in the Sigfox header of every message. The Message which is included in the Sigfox header of every message. The Message
Sequence Number is a monotonically increasing number identifying the Sequence Number is a monotonically increasing number identifying the
specific transmission of this uplink message, and it is part of the specific transmission of this uplink message, and it is also part of
Sigfox header. The Message Payload corresponds to the payload that the Sigfox header. The Message Payload corresponds to the payload
the Device has sent in the uplink transmission. that the Device has sent in the uplink transmission.
The Message Timestamp, Device Geolocation, RSSI, Device Temperature The Message Timestamp, Device Geolocation, RSSI, Device Temperature
and Device Battery Voltage are metadata parameters provided by the and Device Battery Voltage are metadata parameters provided by the
Network. Network.
A detailed description of the Sigfox callbacks/APIs can be found in A detailed description of the Sigfox callbacks/APIs can be found in
[sigfox-callbacks]. [sigfox-callbacks].
Only messages that have passed the L2 Cyclic Redundancy Check (CRC) Only messages that have passed the L2 Cyclic Redundancy Check (CRC)
at network reception are delivered by the Sigfox Network to the at network reception are delivered by the Sigfox Network to the
skipping to change at page 6, line 24 skipping to change at page 6, line 24
Figure 2: SCHC Message in Sigfox Figure 2: SCHC Message in Sigfox
Figure 2 shows a SCHC Message sent over Sigfox, where the SCHC Figure 2 shows a SCHC Message sent over Sigfox, where the SCHC
Message could be a full SCHC Packet (e.g. compressed) or a SCHC Message could be a full SCHC Packet (e.g. compressed) or a SCHC
Fragment (e.g. a piece of a bigger SCHC Packet). Fragment (e.g. a piece of a bigger SCHC Packet).
4.3. Downlink 4.3. Downlink
Downlink transmissions are Device-driven and can only take place Downlink transmissions are Device-driven and can only take place
following an uplink communication. Hence, a Device willing to following an uplink communication that so indicates. Hence, a Device
receive downlink messages indicates so to the network in the willing to receive a downlink message indicates explicitly its
preceding uplink message with a downlink request flag, and then it intention to the network in the preceding uplink message with a
opens a fixed window for downlink reception after the uplink downlink request flag, and then it opens a fixed window for downlink
transmission. The delay and duration of the reception window have reception after completing the uplink transmission. The delay and
fixed values. If there is a downlink message to be sent for this duration of the reception opportunity window have fixed values. If
given Device (e.g. either a response to the uplink message or queued there is a downlink message to be sent for this given Device (e.g.
information waiting to be transmitted), the network transmits it to either a response to the uplink message or queued information waiting
the Device during the reception window. to be transmitted), the network transmits it to the Device during the
reception window. If no message is received by the Device after the
reception opportunity window has elapsed, the Device closes the
receiving opportunity and gets back to the normal mode (e.g. continue
UL transmissions, sleep, stand-by, etc.)
When a downlink message is sent to a Device, an acknowledgement is When a downlink message is sent to a Device, a reception
generated by the Device through the Sigfox protocol and reported by acknowledgement is generated by the Device back to the Network
the Sigfox Network. This acknowledgement can be retrieved through through the Sigfox protocol and reported by the Sigfox Network. This
callbacks by the customer. acknowledgement can be retrieved through callbacks by the customer.
A detailed description of the Sigfox Radio Protocol can be found in A detailed description of the Sigfox Radio Protocol can be found in
[sigfox-spec] and a detailed description of the Sigfox callbacks/APIs [sigfox-spec] and a detailed description of the Sigfox callbacks/APIs
can be found in [sigfox-callbacks]. can be found in [sigfox-callbacks].
4.4. SCHC Rules 4.4. ACK on Downlink
As explained previously, downlink transmissions are Device-driven and
can only take place following a specific uplink transmission that
indicates and allows a following downlink opportunity. For this
reason, when SCHC bi-directional services are used (e.g. Ack-on-
Error fragmentation mode) the SCHC protocol implementation needs to
consider the times when a downlink message (e.g. ACK) can be sent
and/or received.
For the UL ACK-on-Error fragmentation mode, a DL opportunity MUST be
indicated by the last fragment of every window (i.e. FCN = All-0, or
FCN = All-1). The Device sends the fragments in sequence and, after
transmitting the FCN = All-0 or FCN = All-1, it opens up a reception
opportunity. The Network SCHC can then decide to respond at that
opportunity (or wait for a further one) with a SCHC-ACK indicating in
case there are missing fragments from the current or previous
windows. If there is no SCHC-ACK to be sent, or if the network
decides to wait for a further DL transmission opportunity, then no DL
transmission takes place at that opportunity and after a timeout the
UL transmissions continue. Intermediate SCHC fragments with FCN
different from All-0 or All-1 MUST NOT use the DL request flag to
request a SCHC-ACK.
4.5. SCHC Rules
The RuleID MUST be included in the SCHC header. The total number of The RuleID MUST be included in the SCHC header. The total number of
rules to be used affects directly the Rule ID field size, and rules to be used affects directly the Rule ID field size, and
therefore the total size of the fragmentation header. For this therefore the total size of the fragmentation header. For this
reason, it is recommended to keep the number of rules that are reason, it is recommended to keep the number of rules that are
defined for a specific device to the minimum possible. defined for a specific device to the minimum possible.
RuleIDs can be used to differenciate data traffic classes (e.g. QoS, RuleIDs can be used to differentiate data traffic classes (e.g. QoS,
control vs. data, etc.), and data sessions. They can also be used to control vs. data, etc.), and data sessions. They can also be used to
interleave simultaneous fragmentation sessions between a Device and interleave simultaneous fragmentation sessions between a Device and
the Network. the Network.
4.5. Fragmentation 4.6. Fragmentation
The SCHC specification [RFC8724] defines a generic fragmentation The SCHC specification [RFC8724] defines a generic fragmentation
functionality that allows sending data packets or files larger than functionality that allows sending data packets or files larger than
the maximum size of a Sigfox data frame. The functionality also the maximum size of a Sigfox data frame. The functionality also
defines a mechanism to send reliably multiple messages, by allowing defines a mechanism to send reliably multiple messages, by allowing
to resend selectively any lost fragments. to resend selectively any lost fragments.
The SCHC fragmentation supports several modes of operation. These The SCHC fragmentation supports several modes of operation. These
modes have different advantages and disadvantages depending on the modes have different advantages and disadvantages depending on the
specifics of the underlying LPWAN technology and application Use specifics of the underlying LPWAN technology and application Use
Case. This section describes how the SCHC fragmentation Case. This section describes how the SCHC fragmentation
functionality should optimally be implemented when used over a Sigfox functionality should optimally be implemented when used over a Sigfox
LPWAN for the most typical Use Case applications. LPWAN for the most typical Use Case applications.
As described in section 8.2.3 of [RFC8724], the integrity of the
fragmentation-reassembly process of a SCHC Packet MUST be checked at
the receive end. Since only UL messages/fragments that have passed
the CRC-check are delivered to the Network SCHC C/D + F/R, and each
one has an associated Sigfox Message Sequence Number (see
Section 4.2), integrity can be guaranteed when no consecutive
messages are missing from the sequence and all FCN bitmaps are
complete. In order to support multiple flows/RuleIDs (potentially
interleaved), the implementation of a central message sequence
counter at the Network SCHC C/D + F/R is required. With this
functionality and in order to save protocol overhead, the use of a
dedicated Reassembly Check Sequence (RCS) is NOT RECOMMENDED.
The L2 Word Size used by Sigfox is 1 byte (8 bits). The L2 Word Size used by Sigfox is 1 byte (8 bits).
4.5.1. Uplink Fragmentation 4.6.1. Uplink Fragmentation
Sigfox uplink transmissions are completely asynchronous and can take Sigfox uplink transmissions are completely asynchronous and can take
place in any random frequency of the allowed uplink bandwidth place in any random frequency of the allowed uplink bandwidth
allocation. Hence, devices can go to deep sleep mode, and then wake allocation. Hence, devices can go to deep sleep mode, and then wake
up and transmit whenever there is a need to send any information to up and transmit whenever there is a need to send any information to
the network. In that way, there is no need to perform any network the network. In that way, there is no need to perform any network
attachment, synchronization, or other procedure before transmitting a attachment, synchronization, or other procedure before transmitting a
data packet. All data packets are self-contained with all the data packet. All data packets are self-contained (aka "message in a
required information for the network to process them accordingly. bottle") with all the required information for the network to process
them accordingly.
Since uplink transmissions occur asynchronously, an SCHC fragment can Since uplink transmissions occur asynchronously, an SCHC fragment can
be transmitted at any given time by the Device. Sigfox uplink be transmitted at any given time by the Device. Sigfox uplink
messages are fixed in size, and as described in [RFC8376] they can messages are fixed in size, and as described in [RFC8376] they can
carry 0-12 bytes payload. Hence, a single SCHC Tile size per mode carry 0-12 bytes payload. Hence, a single SCHC Tile size per
can be defined so that every Sigfox message always carries one SCHC fragmentation mode can be defined so that every Sigfox message always
Tile. carries one SCHC Tile.
4.5.1.1. Uplink No-ACK Mode 4.6.1.1. Uplink No-ACK Mode
No-ACK is RECOMMENDED to be used for transmitting short, non-critical No-ACK is RECOMMENDED to be used for transmitting short, non-critical
packets that require fragmentation and do not require full packets that require fragmentation and do not require full
reliability. This mode can be used by uplink-only devices that do reliability. This mode can be used by uplink-only devices that do
not support downlink communications, or by bidirectional devices when not support downlink communications, or by bidirectional devices when
they send non-critical data. they send non-critical data.
Since there are no multiple windows in the No-ACK mode, the W bit is Since there are no multiple windows in the No-ACK mode, the W bit is
not present. However it is RECOMMENDED to use FCN to indicate the not present. However it is RECOMMENDED to use the FCN field to
size of the data packet. In this sense, the data packet would need indicate the size of the data packet. In this sense, the data packet
to be splitted into X fragments and, similarly to the other would need to be splitted into X fragments and, similarly to the
fragmentation modes, the first transmitted fragment would need to be other fragmentation modes, the first transmitted fragment would need
marked with FCN = X-1. Consecutive fragments MUST be marked with to be marked with FCN = X-1. Consecutive fragments MUST be marked
decreasing FCN values, having the last fragment marked with FCN = with decreasing FCN values, having the last fragment marked with FCN
(All-1). Hence, even though the No-ACK mode does not allow = (All-1). Hence, even though the No-ACK mode does not allow
recovering missing fragments, it allows indicating implicitly to the recovering missing fragments, it allows indicating implicitly the
Network the size of the expected packet and whether all fragments size of the expected packet to the Network and hence detect at the
have been received or not. receiver side whether all fragments have been received or not.
The RECOMMENDED Fragmentation Header size is 8 bits, and it is The RECOMMENDED Fragmentation Header size is 8 bits, and it is
composed as follows: composed as follows:
o RuleID size: 4 bits o RuleID size: 4 bits
o DTag size (T): 0 bits o DTag size (T): 0 bits
o Fragment Compressed Number (FCN) size (N): 4 bits o Fragment Compressed Number (FCN) size (N): 4 bits
o As per [RFC8724], in the No-ACK mode the W (window) field is not o As per [RFC8724], in the No-ACK mode the W (window) field is not
present. present.
o RCS: Not used o RCS size: 0 bits (Not used)
4.5.1.2. Uplink ACK-on-Error Mode: Single-byte SCHC Header 4.6.1.2. Uplink ACK-on-Error Mode: Single-byte SCHC Header
ACK-on-Error with single-byte header is RECOMMENDED for medium-large ACK-on-Error with single-byte header is RECOMMENDED for medium-large
size packets that need to be sent reliably. ACK-on-Error is optimal size packets that need to be sent reliably. ACK-on-Error is optimal
for Sigfox transmissions, since it leads to a reduced number of ACKs for Sigfox transmissions, since it leads to a reduced number of ACKs
in the lower capacity downlink channel. Also, downlink messages can in the lower capacity downlink channel. Also, downlink messages can
be sent asynchronously and opportunistically. be sent asynchronously and opportunistically.
Allowing transmission of packets/files up to 300 bytes long, the SCHC Allowing transmission of packets/files up to 300 bytes long, the SCHC
uplink Fragmentation Header size is RECOMMENDED to be 8 bits in size uplink Fragmentation Header size is RECOMMENDED to be 8 bits in size
and is composed as follows: and is composed as follows:
o Rule ID size: 3 bits o Rule ID size: 3 bits
o DTag size (T): 0 bits o DTag size (T): 0 bits
o Window index (W) size (M): 2 bits o Window index (W) size (M): 2 bits
o Fragment Compressed Number (FCN) size (N): 3 bits o Fragment Compressed Number (FCN) size (N): 3 bits
o MAX_ACK_REQUESTS: 5 o MAX_ACK_REQUESTS: 5
o WINDOW_SIZE: 7 (with a maximum value of FCN=0b110)
o WINDOW_SIZE: 7 (with a maximum value of FCN=0b110)
o Tile size: 11 bytes o Tile size: 11 bytes
o Retransmission Timer: Application-dependent o Retransmission Timer: Application-dependent
o Inactivity Timer: Application-dependent o Inactivity Timer: Application-dependent
o RCS: Not used o RCS size: 0 bits (Not used)
The correspondent SCHC ACK in the downlink is 13 bits long, so The correspondent SCHC ACK in the downlink is 13 bits long, so
padding is needed to complete the required 64 bits of Sigfox payload. padding is needed to complete the required 64 bits of Sigfox payload.
4.5.1.3. Uplink ACK-on-Error Mode: Two-byte SCHC Header 4.6.1.3. Uplink ACK-on-Error Mode: Two-byte SCHC Header
ACK-on-Error with two-byte header is RECOMMENDED for very large size ACK-on-Error with two-byte header is RECOMMENDED for very large size
packets that need to be sent reliably. ACK-on-Error is optimal for packets that need to be sent reliably. ACK-on-Error is optimal for
Sigfox transmissions, since it leads to a reduced number of ACKs in Sigfox transmissions, since it leads to a reduced number of ACKs in
the lower capacity downlink channel. Also, downlink messages can be the lower capacity downlink channel. Also, downlink messages can be
sent asynchronously and opportunistically. sent asynchronously and opportunistically.
In order to allow transmission of very large packets/files up to 2250 In order to allow transmission of very large packets/files up to 2250
bytes long, the SCHC uplink Fragmentation Header size is RECOMMENDED bytes long, the SCHC uplink Fragmentation Header size is RECOMMENDED
to be 16 bits in size and composed as follows: to be 16 bits in size and composed as follows:
skipping to change at page 9, line 47 skipping to change at page 10, line 45
o MAX_ACK_REQUESTS: 5 o MAX_ACK_REQUESTS: 5
o WINDOW_SIZE: 31 (with a maximum value of FCN=0b11110) o WINDOW_SIZE: 31 (with a maximum value of FCN=0b11110)
o Tile size: 10 bytes o Tile size: 10 bytes
o Retransmission Timer: Application-dependent o Retransmission Timer: Application-dependent
o Inactivity Timer: Application-dependent o Inactivity Timer: Application-dependent
o RCS: Not used o RCS size: 0 bits (Not used)
The correspondent SCHC ACK in the downlink is 43 bits long, so The correspondent SCHC ACK in the downlink is 43 bits long, so
padding is needed to complete the required 64 bits of Sigfox payload. padding is needed to complete the required 64 bits of Sigfox payload.
4.5.1.4. All-1 behaviour + Sigfox Sequence Number 4.6.1.4. All-1 behaviour + Sigfox Sequence Number
For ACK-on-Error, as defined in [RFC8724] it is expected that the For ACK-on-Error, as defined in [RFC8724] it is expected that the
last SCHC fragment of the last window will always be delivered with last SCHC fragment of the last window will always be delivered with
an All-1 FCN. Since this last window may not be full (i.e. it may be an All-1 FCN. Since this last window may not be full (i.e. it may be
comprised of less than WINDOW_SIZE fragments), an All-1 fragment may comprised of less than WINDOW_SIZE fragments), an All-1 fragment may
follow a value of FCN higher than 1 (0b01). In this case, the follow a value of FCN higher than 1 (0b01). In this case, the
receiver could not derive from the FCN values alone whether there are receiver could not derive from the FCN values alone whether there are
any missing fragments right before the All-1 fragment or not. any missing fragments right before the All-1 fragment or not.
However, since a Message Sequence Number is provided by the Sigfox However, since a Message Sequence Number is provided by the Sigfox
protocol together with the Sigfox Payload, the receiver can detect if protocol together with the Sigfox Payload, the receiver can detect if
there are missing fragments before the All-1 and hence construct the there are missing fragments before the All-1 and hence construct the
corresponding SCHC ACK Bitmap accordingly. corresponding SCHC ACK Bitmap accordingly.
4.5.2. Downlink Fragmentation 4.6.2. Downlink Fragmentation
In some LPWAN technologies, as part of energy-saving techniques, In some LPWAN technologies, as part of energy-saving techniques,
downlink transmission is only possible immediately after an uplink downlink transmission is only possible immediately after an uplink
transmission. This allows the device to go in a very deep sleep mode transmission. This allows the device to go in a very deep sleep mode
and preserve battery, without the need to listen to any information and preserve battery, without the need to listen to any information
from the network. This is the case for Sigfox-enabled devices, which from the network. This is the case for Sigfox-enabled devices, which
can only listen to downlink communications after performing an uplink can only listen to downlink communications after performing an uplink
transmission and requesting a downlink. transmission and requesting a downlink.
When there are fragments to be transmitted in the downlink, an uplink When there are fragments to be transmitted in the downlink, an uplink
skipping to change at page 11, line 18 skipping to change at page 12, line 18
o MAX_ACK_REQUESTS: 5 o MAX_ACK_REQUESTS: 5
o WINDOW_SIZE: 31 (with a maximum value of FCN=0b11110) o WINDOW_SIZE: 31 (with a maximum value of FCN=0b11110)
o Tile size: 7 bytes o Tile size: 7 bytes
o Retransmission Timer: Application-dependent o Retransmission Timer: Application-dependent
o Inactivity Timer: Application-dependent o Inactivity Timer: Application-dependent
o RCS: Not used o RCS size: 0 bits (Not used)
4.6. Padding 4.7. Padding
The Sigfox payload fields have different characteristics in uplink The Sigfox payload fields have different characteristics in uplink
and downlink. and downlink.
Uplink frames can contain a payload size from 0 to 12 bytes. The Uplink frames can contain a payload size from 0 to 12 bytes. The
radio protocol allows sending zero bits, one single bit of radio protocol allows sending zero bits, one single bit of
information for binary applications (e.g. status), or an integer information for binary applications (e.g. status), or an integer
number of bytes. Therefore, for 2 or more bits of payload it is number of bytes. Therefore, for 2 or more bits of payload it is
required to add padding to the next integer number of bytes. The required to add padding to the next integer number of bytes. The
reason for this flexibility is to optimize transmission time and reason for this flexibility is to optimize transmission time and
skipping to change at page 12, line 14 skipping to change at page 13, line 14
The radio protocol has protections against reply attacks, and the The radio protocol has protections against reply attacks, and the
cloud-based core network provides firewalling protection against cloud-based core network provides firewalling protection against
undesired incoming communications. undesired incoming communications.
6. Acknowledgements 6. Acknowledgements
Carles Gomez has been funded in part by the ERDF and the Spanish Carles Gomez has been funded in part by the ERDF and the Spanish
Government through project TEC2016-79988-P. Government through project TEC2016-79988-P.
The authors would like to thank Diego Wistuba, Clement Mannequin and The authors would like to thank Diego Wistuba, Sergio Aguilar,
Sandra Cespedes for their useful comments and design considerations. Clement Mannequin, Sandra Cespedes and Rafel Vidal for their useful
comments and implementation design considerations.
7. References 7. References
7.1. Normative References 7.1. Normative References
[RFC8376] Farrell, S., Ed., "Low-Power Wide Area Network (LPWAN) [RFC8376] Farrell, S., Ed., "Low-Power Wide Area Network (LPWAN)
Overview", RFC 8376, DOI 10.17487/RFC8376, May 2018, Overview", RFC 8376, DOI 10.17487/RFC8376, May 2018,
<https://www.rfc-editor.org/info/rfc8376>. <https://www.rfc-editor.org/info/rfc8376>.
[RFC8724] Minaburo, A., Toutain, L., Gomez, C., Barthel, D., and JC. [RFC8724] Minaburo, A., Toutain, L., Gomez, C., Barthel, D., and JC.
skipping to change at page 12, line 46 skipping to change at page 13, line 47
[sigfox-spec] [sigfox-spec]
Sigfox, "Sigfox Radio Specifications", Sigfox, "Sigfox Radio Specifications",
<https://build.sigfox.com/sigfox-device-radio- <https://build.sigfox.com/sigfox-device-radio-
specifications>. specifications>.
Authors' Addresses Authors' Addresses
Juan Carlos Zuniga Juan Carlos Zuniga
SIGFOX SIGFOX
425 rue Jean Rostand Montreal QC
Labege 31670 Canada
France
Email: JuanCarlos.Zuniga@sigfox.com Email: JuanCarlos.Zuniga@sigfox.com
URI: http://www.sigfox.com/ URI: http://www.sigfox.com/
Carles Gomez Carles Gomez
Universitat Politecnica de Catalunya Universitat Politecnica de Catalunya
C/Esteve Terradas, 7 C/Esteve Terradas, 7
08860 Castelldefels 08860 Castelldefels
Spain Spain
Email: carlesgo@entel.upc.edu Email: carlesgo@entel.upc.edu
 End of changes. 38 change blocks. 
90 lines changed or deleted 135 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/