SCHC over Sigfox LPWAN
Montreal QCCanadaj.c.zuniga@ieee.orgUniversitat Politècnica de CatalunyaC/Esteve Terradas, 708860 CastelldefelsSpaincarlesgo@entel.upc.eduUniversitat Politècnica de CatalunyaC/Esteve Terradas, 708860 CastelldefelsSpainsergio.aguilar.romero@upc.eduIMT-Atlantique2 rue de la ChataigneraieCS 1760735576 Cesson-Sevigne CedexFranceLaurent.Toutain@imt-atlantique.frNIC Labs, Universidad de ChileAv. Almte. Blanco Encalada 1975SantiagoChilescespedes@niclabs.clNIC Labs, Universidad de ChileAv. Almte. Blanco Encalada 1975SantiagoChilewistuba@niclabs.cl
SIGFOX
LabegeFrancejulien.boite@sigfox.comhttp://www.sigfox.com/lpwan Working GroupThe Generic Framework for Static Context Header Compression and Fragmentation (SCHC) specification describes two mechanisms: i) an application header
compression scheme, and ii) a frame fragmentation and loss recovery functionality. SCHC offers a great level of flexibility that can be tailored for different
Low Power Wide Area Network (LPWAN) technologies.The present document provides the optimal parameters and modes of operation when SCHC is implemented over a Sigfox LPWAN. This set of parameters are also
known as a "SCHC over Sigfox profile."The Generic Framework for Static Context Header Compression and Fragmentation (SCHC) specification can be used on top of all the four LPWAN technologies
defined in . These LPWANs have similar characteristics such as star-oriented
topologies, network architecture, connected devices with built-in applications, etc.
SCHC offers a great level of flexibility to accommodate all these LPWAN technologies. Even though there are a great number of similarities between
them, some differences exist with respect to the transmission characteristics, payload sizes, etc. Hence, there are optimal parameters and modes of operation
that can be used when SCHC is used on top of a specific LPWAN technology.
This document describes the recommended parameters, settings, and 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 profile" or simply "SCHC/Sigfox."
It is assumed that the reader is familiar with the terms and mechanisms defined in and
in .
The Generic SCHC Framework described in takes advantage of previous knowledge of traffic flows existing in LPWAN applications to avoid context synchronization.Contexts need to be stored and pre-configured on both ends. This can be done either by using a provisioning protocol, by out of band means, 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 of this document. represents the architecture for compression/decompression (C/D) and fragmentation/reassembly (F/R) based
on the terminology defined in , where the Radio Gateway (RGW) is a Sigfox Base Station and the Network Gateway (NGW) is the
Sigfox cloud-based Network. In the case of the global Sigfox Network, RGWs (or Base Stations) are distributed over multiple countries wherever the Sigfox LPWAN service is provided.
The NGW (or cloud-based Sigfox Core Network) is a single entity that connects to all RGWs (Sigfox Base Stations) in the world, providing hence a global single star network topology.The Sigfox Device sends application packets that are compressed and/or fragmented by a SCHC Compressor/Decompressor (SCHC C/D + F/R) to 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 Stations, which then forward the SCHC Message to the Network Gateway (NGW).
The NGW then delivers the SCHC Message and associated gathered metadata to 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. The Network SCHC C/D + F/R shares the same set of rules
as the Dev 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 tunnel or secured communication is established between
the NGW and the SCHC C/D + F/R functions. After decompression and/or reassembly, the packet can be forwarded over the Internet to one (or several) LPWAN Application Server(s) (App).The SCHC C/D + F/R processes are bidirectional, so the same principles are applicable on both uplink (UL) and downlink (DL).Uplink Sigfox transmissions occur in repetitions over different times and frequencies.
Besides time and frequency diversities, the Sigfox network also provides space diversity, as potentially an uplink message will be received by several base stations. Since all messages are self-contained and base stations forward all these messages back to the same Sigfox Network, multiple input copies can be
combined at the NGW providing for extra reliability based on the triple diversity (i.e., time, space and frequency).
A detailed description of the Sigfox Radio Protocol can be found in .
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
callback/API with the following information:Device IDMessage Sequence NumberMessage PayloadMessage TimestampDevice Geolocation (optional)RSSI (optional)Device Temperature (optional)Device Battery Voltage (optional)The Device ID is a globally unique identifier assigned to the Device, which is included in the Sigfox header of every message. The Message Sequence Number is a monotonically
increasing number identifying the specific transmission of this uplink message, and it is also part of the Sigfox header. The Message Payload corresponds to the payload that the
Device has sent in the uplink transmission.The Message Timestamp, Device Geolocation, RSSI, Device Temperature and Device Battery Voltage are metadata parameters provided by the Network.A detailed description of the Sigfox callbacks/APIs can be found in .Only messages that have passed the L2 Cyclic Redundancy Check (CRC) at network reception are delivered by the Sigfox Network to the Network SCHC C/D + F/R. shows a SCHC Message sent over Sigfox, where the SCHC Message could be a full SCHC Packet (e.g. compressed)
or a SCHC Fragment (e.g. a piece of a bigger SCHC Packet).
Downlink transmissions are Device-driven and can only take place following an uplink communication that so indicates. Hence, a Sigfox Device explicitly indicates its intention to receive a downlink message
using a downlink request flag when sending the preceding uplink message to the network. The downlink request flag is part of the Sigfox protocol headers. After completing the uplink transmission, the Device opens a fixed window for downlink reception.
The delay and duration of the reception opportunity window have fixed values. If there is a downlink message to be sent for this given Device (e.g. either
a response to the uplink message or queued information waiting to be transmitted), the network transmits this message 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 reception window opportunity and gets back to the normal mode (e.g., continue Uplink transmissions, sleep, stand-by, etc.)
When a downlink message is sent to a Device, a reception acknowledgement is generated by the Device and sent back to the Network through the Sigfox radio protocol and reported in the Sigfox Network backend.
A detailed description of the Sigfox Radio Protocol can be found in and a detailed description of the Sigfox callbacks/APIs can be found in . Downlink request flag can be included in the information exchange between the Sigfox Network and Network SCHC.
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. SCHC-ACK) can be sent and/or received.
For the Uplink ACK-on-Error fragmentation mode, a downlink 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 downlink transmission opportunity, then no
downlink transmission takes place at that opportunity and after a timeout the Uplink transmissions continue. Intermediate SCHC fragments with FCN different from All-0 or All-1 MUST NOT use the downlink request flag
to request a SCHC-ACK.
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 therefore
the total size of the fragmentation header. For this reason, it is recommended to keep the number of rules that are defined for a specific device to the minimum possible.
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 interleave simultaneous fragmentation sessions between a Device and the Network.
The SCHC specification defines a generic fragmentation functionality that
allows sending data packets or files larger than the maximum size of a Sigfox payload. The functionality also defines a mechanism to send
reliably multiple messages, by allowing to resend selectively any lost fragments.
The SCHC fragmentation supports several modes of operation. These modes have different advantages and disadvantages depending
on the specifics of the underlying LPWAN technology and application Use Case. This section describes how the SCHC fragmentation functionality
should optimally be implemented when used over a Sigfox LPWAN for the most typical Use Case applications.As described in section 8.2.3 of , the integrity of the fragmentation-reassembly process of a SCHC Packet MUST be
checked at the receive end. Since only Uplink messages/fragments that have passed the Sigfox CRC-check are delivered to the Network SCHC C/D + F/R,
integrity can be guaranteed when no consecutive messages are missing from the sequence and all FCN bitmaps are complete. With this functionality
in mind, and in order to save protocol and processing overhead, the use of a Reassembly Check Sequence (RCS) as described in
is RECOMMENDED.The L2 Word Size used by Sigfox is 1 byte (8 bits). Sigfox uplink transmissions are completely asynchronous and take place in any random frequency of the allowed uplink bandwidth allocation.
In addition, devices may go to deep sleep mode, and then wake up and transmit whenever there is a need to send information to the network.
Data packets are self-contained (aka “message in a bottle”) with all the required information for the network to process them accordingly.
Hence, there is no need to perform any network attachment, synchronization, or other procedure before transmitting a data packet.
Since uplink transmissions are asynchronous, a SCHC fragment can be transmitted at any given time by the Device. Sigfox uplink messages
are fixed in size, and as described in they can carry 0-12 bytes payload. Hence, a single SCHC Tile size per fragmentation
mode can be defined so that every Sigfox message always carries one SCHC Tile.When the ACK-on-Error mode is used for uplink fragmentation, the SCHC Compound ACK defined in ) MUST be used in the downlink responses.Single-byte SCHC Header No-ACK mode is RECOMMENDED to be used for transmitting short, non-critical packets that require fragmentation and do not require full reliability.
This mode can be used by uplink-only devices that do not support downlink communications, or by bidirectional devices when they send non-critical
data.Since there are no multiple windows in the No-ACK mode, the W bit is not present. However, it is RECOMMENDED to use the FCN field to indicate the
size of the data packet. In this sense, the data packet would need to be splitted into X fragments and, similarly to the other fragmentation modes,
the first transmitted fragment would need to be marked with FCN = X-1. Consecutive fragments MUST be marked with decreasing FCN values, having the
last fragment marked with FCN = (All-1). Hence, even though the No-ACK mode does not allow recovering missing fragments, it allows indicating implicitly
the size of the expected packet to the Network and hence detect at the receiver side whether all fragments have been received or not.The RECOMMENDED Fragmentation Header size is 8 bits, and it is composed as follows:RuleID size: 3 bitsDTag size (T): 0 bitsFragment Compressed Number (FCN) size (N): 5 bitsAs per , in the No-ACK mode the W (window) field is not present. Regular tile size: 11 bytesAll-1 tile size: 0 to 10 bytesInactivity Timer: Application-dependent. The RECOMMENDED value is 12 hours.RCS size: 5 bits The maximum SCHC Packet size is of 340 bytes.ACK-on-Error with single-byte header is RECOMMENDED for short to medium 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
in the lower capacity downlink channel. Also, downlink messages can be sent asynchronously and opportunistically.
Allowing transmission of packets/files up to 300 bytes long, the SCHC uplink Fragmentation Header size is
RECOMMENDED to be 8 bits in size and is composed as follows:
Rule ID size: 3 bitsDTag size (T): 0 bitsWindow index (W) size (M): 2 bits Fragment Compressed Number (FCN) size (N): 3 bitsMAX_ACK_REQUESTS: 5WINDOW_SIZE: 7 (with a maximum value of FCN=0b110)Regular tile size: 11 bytesAll-1 tile size: 0 to 10 bytesRetransmission Timer: Application-dependent. The RECOMMENDED value is 12 hours.Inactivity Timer: Application-dependent. The RECOMMENDED value is 12 hours.RCS size: 3 bitsACK-on-Error with two-byte header is RECOMMENDED for medium-large 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 in the lower capacity downlink
channel. Also, downlink messages can be sent asynchronously and
opportunistically.
In order to allow transmission of medium-large packets/files up to 480 bytes long, the SCHC uplink Fragmentation Header size is
RECOMMENDED to be 16 bits in size and composed as follows:Rule ID size is: 6 bitsDTag size (T) is: 0 bitsWindow index (W) size (M): 2 bits Fragment Compressed Number (FCN) size (N): 4 bits.MAX_ACK_REQUESTS: 5WINDOW_SIZE: 12 (with a maximum value of FCN=0b1011)Regular tile size: 10 bytesAll-1 tile size: 1 to 10 bytesRetransmission Timer: Application-dependent. The RECOMMENDED value is 12 hours.Inactivity Timer: Application-dependent. The RECOMMENDED value is 12 hours.RCS size: 4 bitsNote that WINDOW_SIZE is limited to 12. This because, 4 windows (M = 2) with bitmaps of size 12 can be fitted in a
single SCHC Compound ACK.In order to allow transmission of very large packets/files up to 2400 bytes long, the SCHC uplink Fragmentation Header size is
RECOMMENDED to be 16 bits in size and composed as follows:Rule ID size is: 8 bitsDTag size (T) is: 0 bitsWindow index (W) size (M): 3 bits Fragment Compressed Number (FCN) size (N): 5 bits.MAX_ACK_REQUESTS: 5WINDOW_SIZE: 31 (with a maximum value of FCN=0b11110)Regular tile size: 10 bytesAll-1 tile size: 0 to 9 bytesRetransmission Timer: Application-dependent. The RECOMMENDED value is 12 hours.Inactivity Timer: Application-dependent. The RECOMMENDED value is 12 hours.RCS size: 5 bitsFor ACK-on-Error, as defined in , it is expected that the 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 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 receiver cannot determine from the FCN values alone
whether there are or not any missing fragments right before the All-1 fragment.
For Rules where the number of fragments in the last window is unknown, an RCS field MUST be used, indicating the number of fragments
in the last window, including the All-1. With this RCS value, the receiver can detect if there are missing fragments before the All-1 and hence
construct the corresponding SCHC ACK Bitmap accordingly, and send it in response to the All-1.
In some LPWAN technologies, as part of energy-saving techniques, downlink transmission is only possible immediately after an uplink
transmission. This allows the device to go in a very deep sleep mode and preserve battery, without the need to listen to any information
from the network. This is the case for Sigfox-enabled devices, which can only listen to downlink communications after performing an
uplink transmission and requesting a downlink.When there are fragments to be transmitted in the downlink, an uplink message is required to trigger the downlink communication.
In order to avoid potentially high delay for fragmented datagram transmission in the downlink, the fragment receiver MAY perform an
uplink transmission as soon as possible after reception of a downlink fragment that is not the last one. Such uplink transmission
MAY be triggered by sending a SCHC message, such as a SCHC ACK. However, other data messages can equally be used to trigger downlink
communications.
It is RECOMMENDED for the fragment receiver to send an uplink transmission (e.g., empty message) and request a downlink every 24 hours when no SCHC session is started. The use or not of this uplink transmission will depend on application specific requirements.
Sigfox downlink messages are fixed in size, and as described in they can carry up to 8 bytes payload. Hence, a
single SCHC Tile size per mode can be defined so that every Sigfox message always carries one SCHC Tile.
For reliable downlink fragment transmission, the ACK-Always mode is RECOMMENDED.The SCHC downlink Fragmentation Header size is RECOMMENDED to be 8 bits in size and is composed as follows:RuleID size: 3 bitsDTag size (T): 0 bitsWindow index (W) size (M) is: 0 bits Fragment Compressed Number (FCN) size (N): 5 bitsMAX_ACK_REQUESTS: 5WINDOW_SIZE: 31 (with a maximum value of FCN=0b11110)Regular tile size: 7 bytesAll-1 tile size: 0 to 6 bytesRetransmission Timer: Application-dependent. The RECOMMENDED value is 12 hours.Inactivity Timer: Application-dependent. The RECOMMENDED value is 12 hours.RCS size: 5 bits This section depicts the different formats of SCHC Fragment, SCHC ACK (including the SCHC Compound ACK
defined in ), and SCHC Abort used in SCHC over Sigfox. shows an example of a regular SCHC fragment for all fragments except the last one.
As tiles are of 11 bytes, padding MUST NOT be added.
The penultimate tile of a SCHC Packet is of regular size. shows an example of the All-1 message.
The All-1 message MAY contain the last tile of the SCHC Packet.
Padding MUST NOT be added, as the resulting size is L2-word-multiple.
The All-1 messages Fragment Header includes a 5-bit RCS, and 3 bits are added as padding to complete two bytes.
The payload size of the All-1 message ranges from 0 to 80 bits.
As per the All-1 must be distinguishable from a SCHC Sender-Abort message (with same Rule ID, and N values).
The All-1 MAY have the last tile of the SCHC Packet.
The SCHC Sender-Abort message header size is of 1 byte, with no padding bits.For the All-1 message to be distinguishable from the Sender-Abort message, the Sender-Abort message MUST be of 1 byte (only header with no padding).
This way, the minimum size of the All-1 is 2 bytes, and the Sender-Abort message is 1 byte. shows an example of a regular SCHC fragment for all fragments except the last one.
As tiles are of 11 bytes, padding MUST NOT be added.The use of SCHC ACK REQ is NOT RECOMMENDED, instead the All-1 SCHC Fragment SHOULD be used to request a SCHC ACK from the receiver (Network SCHC).
As per , the All-0 message is distinguishable from the SCHC ACK REQ (All-1 message).
The penultimate tile of a SCHC Packet is of regular size. shows an example of the All-1 message.
The All-1 message MAY contain the last tile of the SCHC Packet.
Padding MUST NOT be added, as the resulting size is L2-word-multiple.As per the All-1 must be distinguishable from a SCHC Sender-Abort message (with same Rule ID, M, and N values).
The All-1 MAY have the last tile of the SCHC Packet.
The SCHC Sender-Abort message header size is of 1 byte, with no padding bits.For the All-1 message to be distinguishable from the Sender-Abort message, the Sender-Abort message MUST be of 1 byte (only header with no padding).
This way, the minimum size of the All-1 is 2 bytes, and the Sender-Abort message is 1 byte. shows the SCHC ACK format when all fragments have been correctly received (C=1).
Padding MUST be added to complete the 64-bit Sigfox downlink frame payload size.In case SCHC fragment losses are found in any of the windows of the SCHC Packet (C=0), the SCHC Compound ACK defined in MUST be used.
The SCHC Compound ACK message format is shown in .
shows an example of a regular SCHC fragment for all fragments except the last one.
The penultimate tile of a SCHC Packet is of the regular size.The use of SCHC ACK REQ is NOT RECOMMENDED, instead the All-1 SCHC Fragment SHOULD be used to request a SCHC ACK from the receiver (Network SCHC).
As per , the All-0 message is distinguishable from the SCHC ACK REQ (All-1 message). shows an example of the All-1 message.
The All-1 message MUST contain the last tile of the SCHC Packet.The All-1 message Fragment Header contains a RCS of 4 bits to complete the two-byte size.
The size of the last tile ranges from 8 to 80 bits.As per the All-1 must be distinguishable from the a SCHC Sender-Abort message (with same Rule ID, M and N values).
The All-1 MUST have the last tile of the SCHC Packet, that MUST be of at least 1 byte.
The SCHC Sender-Abort message header size is of 2 byte, with no padding bits.For the All-1 message to be distinguishable from the Sender-Abort message, the Sender-Abort message MUST be of 2 byte (only header with no padding).
This way, the minimum size of the All-1 is 3 bytes, and the Sender-Abort message is 2 bytes. shows the SCHC ACK format when all fragments have been correctly received (C=1).
Padding MUST be added to complete the 64-bit Sigfox downlink frame payload size.The SCHC Compound ACK message MUST be used in case SCHC fragment losses are found in any window of the SCHC Packet (C=0).
The SCHC Compound ACK message format is shown in .
The SCHC Compound ACK can report up to 4 windows with losses. as shown in .When sent in the downlink, the SCHC Compound ACK MUST be 0 padded (Padding bits must be 0) to complement the 64 bits required by the Sigfox payload. shows an example of a regular SCHC fragment for all fragments except the last one.
The penultimate tile of a SCHC Packet is of the regular size.The use of SCHC ACK REQ is NOT RECOMMENDED, instead the All-1 SCHC Fragment SHOULD be used to request a SCHC ACK from the receiver (Network SCHC).
As per , the All-0 message is distinguishable from the SCHC ACK REQ (All-1 message). shows an example of the All-1 message.
The All-1 message MAY contain the last tile of the SCHC Packet.The All-1 message Fragment Header contains an RCS of 5 bits, and 3 padding bits to complete a 3-byte Fragment Header.
The size of the last tile, if present, ranges from 8 to 72 bits.As per the All-1 must be distinguishable from the a SCHC Sender-Abort message (with same Rule ID, M and N values).
The SCHC Sender-Abort message header size is of 2 byte, with no padding bits.For the All-1 message to be distinguishable from the Sender-Abort message, the Sender-Abort message MUST be of 2 byte (only header with no padding).
This way, the minimum size of the All-1 is 3 bytes, and the Sender-Abort message is 2 bytes. shows the SCHC ACK format when all fragments have been correctly received (C=1).
Padding MUST be added to complete the 64-bit Sigfox downlink frame payload size.The SCHC Compound ACK message MUST be used in case SCHC fragment losses are found in any window of the SCHC Packet (C=0).
The SCHC Compound ACK message format is shown in .
The SCHC Compound ACK can report up to 3 windows with losses.When sent in the downlink, the SCHC Compound ACK MUST be 0 padded (Padding bits must be 0) to complement the 64 bits required by
the Sigfox payload. shows an example of a regular SCHC fragment for all fragments except the last one.
The penultimate tile of a SCHC Packet is of the regular size.The use of SCHC ACK is NOT RECOMMENDED, instead the All-1 SCHC Fragment SHOULD be used to request a SCHC ACK from the receiver.
As per , the All-0 message is distinguishable from the SCHC ACK REQ (All-1 message). shows an example of the All-1 message.
The All-1 message MAY contain the last tile of the SCHC Packet.The All-1 message Fragment Header contains an RCS of 5 bits, and 3 padding bits to complete a 2-byte Fragment Header.
The size of the last tile, if present, ranges from 8 to 48 bits.As per the All-1 must be distinguishable from the a SCHC Sender-Abort message (with same Rule ID and N values).
The SCHC Sender-Abort message header size is of 1 byte, with no padding bits.For the All-1 message to be distinguishable from the Sender-Abort message, the Sender-Abort message MUST be of 1 byte (only header with no padding).
This way, the minimum size of the All-1 is 2 bytes, and the Sender-Abort message is 1 bytes. shows the SCHC ACK format when all fragments have been correctly received (C=1).
Padding MUST be added to complete 2 bytes.
The SCHC ACK message format is shown in .
As defined in , a SCHC-Sender Abort can be triggered when the number of SCHC ACK REQ attempts is greater than or equal to MAX_ACK_REQUESTS.
In the case of SCHC/Sigfox, a SCHC-Sender Abort MUST be sent if the number of repeated All-1s (i.e., with the same bitmap) sent in sequence is greater than or equal to MAX_ACK_REQUESTS. As defined in , a SCHC-Receiver Abort is triggered when the receiver has no RuleID and DTag pairs available for a new session.
In the case of SCHC/Sigfox a SCHC-Receiver Abort MUST be sent if, for a single device, all the RuleIDs are being processed by the receiver (i.e., have an active session)
at a certain time and a new one is requested, or if the RuleID of the fragment is not valid.A SCHC-Receiver Abort MUST be triggered when the Inactivity Timer expires. MAX_ACK_REQUESTS can be increase when facing high error rates. Although a SCHC-Receiver Abort can be triggered at any point in time, a SCHC-Receiver Abort downlink message MUST only be sent when there is a downlink transmission opportunity.The Sigfox payload fields have different characteristics in uplink and downlink.Uplink frames can contain a payload size from 0 to 12 bytes. The Sigfox radio protocol allows sending zero bits,
one single bit of information for binary applications (e.g. status), or an integer 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 reason for this
flexibility is to optimize transmission time and hence save battery consumption at the device.Downlink frames on the other hand have a fixed length. The payload length MUST be 64 bits (i.e. 8 bytes). Hence, if less
information bits are to be transmitted, padding MUST be used with bits equal to 0.In this section, some sequence diagrams depicting messages exchanges for different fragmentation modes and use cases are shown.
In the examples, 'Seq' indicates the Sigfox Sequence Number of the frame carrying a fragment.The FCN field indicates the size of the data packet.
The first fragment is marked with FCN = X-1, where X is the number of fragments the message is split into.
All fragments are marked with decreasing FCN values.
Last packet fragment is marked with the FCN = All-1 (1111). Case No losses - All fragments are sent and received successfully.When the first SCHC fragment is received, the Receiver can calculate the
total number of SCHC fragments that the SCHC Packet is composed of.
For example, if the first fragment is numbered with FCN=6, the receiver can
expect six more messages/fragments (i.e., with FCN going from 5 downwards, and the last fragment with a
FCN equal to 15).Case losses on any fragment except the first.The single-byte SCHC header ACK-on-Error mode allows sending up to 28 fragments and packet sizes up to
300 bytes. The SCHC fragments may be delivered asynchronously and downlink ACK can be sent opportunistically. Case No lossesThe downlink flag must be enabled in the sender Uplink message to allow a downlink message from the receiver.
The downlink Enable in the figures shows where the sender should enable the downlink, and
wait for an ACK.Case Fragment losses in first windowIn this case, fragments are lost in the first window (W=0).
After the first All-0 message arrives, the Receiver
leverages the opportunity and sends a SCHC ACK with the corresponding bitmap and C=0.After the loss fragments from the first window (W=0) are resent, the sender continues
transmitting the fragments of the following window (W=1) without opening a reception opportunity.
Finally, the All-1 fragment is sent, the downlink is enabled, and the SCHC ACK is received with C=1.Case Fragment All-0 lost in first window (W=0)In this example, the All-0 of the first window (W=0) is lost. Therefore,
the Receiver waits for the next All-0 message of intermediate windows, or All-1 message of last window to generate
the corresponding SCHC ACK, notifying the absence of the All-0 of window 0.The sender resends the missing All-0 messages (with any other missing
fragment from window 0) without opening a reception opportunity.In the following diagram, besides the All-0 there are other fragment losses in the first window (W=0).In the next examples, there are fragment losses in both the first (W=0) and second (W=1) windows.
The retransmission cycles after the All-1 is sent (i.e., not in intermediate windows) should
always finish with an All-1, as it serves as an ACK Request message to confirm the correct reception
of the retransmitted fragments. Similar case as above, but with fewer fragments in the second window (W=1)Case SCHC ACK is lostSCHC over Sigfox does not implement the SCHC ACK REQ message. Instead, it uses the SCHC All-1 message to request a SCHC ACK, when required.Case SCHC Compound ACK at the endIn this example, SCHC Fragment losses are found in both window 0 and 1. However, the sender does not send a
SCHC ACK after the All-0 of window 0. Instead, it sends a SCHC Compound ACK notifying losses of both
windows.
The number of times the same SCHC ACK message will be retransmitted is determined by the
MAX_ACK_REQUESTS.Case SCHC Sender-AbortThe sender may need to send a Sender-Abort to stop the current communication.
This may happen, for example, if the All-1 has been sent MAX_ACK_REQUESTS times.Case Receiver-AbortThe receiver may need to send a Receiver-Abort to stop the current communication.
This message can only be sent after a downlink enable.The radio protocol authenticates and ensures the integrity of each message. This is achieved by using a unique device ID and an AES-128 based message authentication code,
ensuring that the message has been generated and sent by the device with the ID claimed in the message.Application data can be encrypted at the application level or not, depending on the criticality of the use case.
This flexibility allows providing a balance between cost and effort vs. risk.
AES-128 in counter mode is used for encryption. Cryptographic keys are independent for each device. These keys are associated with the device ID and separate integrity and
confidentiality keys are pre-provisioned. A confidentiality key is only provisioned if confidentiality is to be used.The radio protocol has protections against reply attacks, and the cloud-based core network provides firewalling protection against undesired incoming communications.Carles Gomez has been funded in part by the Spanish Government
through the Jose Castillejo CAS15/00336 grant, the TEC2016-79988-P
grant, and the PID2019-106808RA-I00 grant, and by Secretaria
d'Universitats i Recerca del Departament d'Empresa i Coneixement de
la Generalitat de Catalunya 2017 through grant SGR 376.Sergio Aguilar has been funded by the ERDF and the Spanish Government through project TEC2016-79988-P and project PID2019-106808RA-I00, AEI/FEDER, EU.Sandra Céspedes has been funded in part by the ANID Chile Project FONDECYT Regular 1201893 and Basal Project FB0008.Diego Wistuba has been funded by the ANID Chile Project FONDECYT Regular 1201893.The authors would like to thank Clement Mannequin, Rafael Vidal, Julien Boite, Renaud Marty, and Antonis Platis for their useful comments and implementation design considerations.SCHC Compound ACKThe present document describes an extension to the SCHC (Static Header Compression and Fragmentation) protocol. It defines a SCHC Compound ACK message
format, which is intended to reduce the number of downlink transmissions (i.e., SCHC ACKs) by accumulating bitmaps of several windows in a single SCHC message
(i.e., the SCHC Compound ACK). The message format is generic, and can be used for instance by any the four LWPAN technologies defined in , being Sigfox, LoRaWAN, NB-IoT and IEEE 802.15.4w. Sigfox Radio SpecificationsSigfox Callbacks