3.1. Network Architecture

Figure 1 represents the architecture for Compression/Decompression (C/D) and Fragmentation/Reassembly (F/R) based on the terminology defined in [RFC8376], where the Radio Gateway (RGW) is a Sigfox Base Station and the Network Gateway (NGW) is the Sigfox cloud-based Network.¶

  Sigfox Device                                           Application
+----------------+                                     +--------------+
| APP1 APP2 APP3 |                                     |APP1 APP2 APP3|
+----------------+                                     +--------------+
|   UDP  |       |                                     |     |  UDP   |
|  IPv6  |       |                                     |     | IPv6   |
+--------+       |                                     |     +--------+
| SCHC C/D & F/R |                                     |              |
|                |                                     |              |
+-------+--------+                                     +--------+-----+
        $                                                       .
        $   +---------+     +--------------+     +---------+    .
        $   |         |     |   Network    |     | Network |    .
        +~~ |Sigfox BS|     |   Gateway    |     |  SCHC   |    .
            |  (RGW)  | === |    (NGW)     | ... |C/D & F/R|.....
            |         |     | Sigfox Cloud |     |         |   IP-based
            +---------+     +--------------+     +---------+   Network
------- Uplink message ------>
                                       <------- Downlink message ------
Legend:
$, ~ : Radio link
= : Internal Sigfox Network
. : External IP-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, hence providing a global single star Network topology.¶

The Sigfox Device sends application packets that are compressed and/or fragmented by a SCHC C/D + F/R to reduce header 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 NGW. The NGW then delivers the SCHC message and associated gathered metadata to the Network SCHC C/D + F/R.¶

The Sigfox cloud-based Network 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 device 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(s)).¶

The SCHC C/D + F/R processes are bidirectional, so the same principles are applicable on both Uplink (UL) and Downlink (DL).¶

3.2. Uplink

Uplink Sigfox transmissions occur in repetitions over different times and frequencies. Besides time and frequency diversities, the Sigfox network also provides spatial diversity, as potentially an Uplink message will be received by several Base Stations. The Uplink message application payload size can be up to 12 bytes.¶

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 [sigfox-spec].¶

Messages sent from the device to the Network are delivered by the Sigfox cloud-based Network to the Network SCHC C/D + F/R through a callback/API with the following information:¶

• Device ID¶
• Message Sequence Number¶
• Message Payload¶
• Message Timestamp¶
• Device Geolocation (optional)¶
• Received Signal Strength Indicator (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. Battery Voltage, Device Temperature, and RSSI values are sent in the confirmation control message, which is mandatorily sent by the device after the successful reception of a Downlink message (see [sigfox-callbacks], Section 5.2).¶

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 [sigfox-callbacks].¶

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.¶

The L2 Word size used by Sigfox is 1 byte (8 bits).¶

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 Fragment (e.g., a piece of a bigger SCHC Packet).¶

| Sigfox Header | Sigfox Payload  |
+---------------+---------------- +
                |   SCHC Message  |

3.3. Downlink

Downlink transmissions are device-driven and can only take place following an Uplink communication that indicates Downlink communication can be performed. Hence, a Sigfox Device explicitly indicates its intention to receive a Downlink message (with a size of 8 bytes) 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, standby, etc.).¶

When a Downlink message is sent to a device, a reception acknowledgement is generated by the device, 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 [sigfox-spec], and a detailed description of the Sigfox callbacks/APIs can be found in [sigfox-callbacks]. A Downlink request flag can be included in the information exchange between the Sigfox network and Network SCHC.¶

3.4. SCHC Rules

The RuleID MUST be included in the SCHC header. The total number of Rules to be used directly affects the RuleID 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. Large RuleID sizes (and thus larger fragmentation headers) are acceptable for devices without significant energy constraints (e.g., a sensor that is powered by the electricity grid).¶

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.¶

3.5. Fragmentation

The SCHC specification [RFC8724] 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 reliably send multiple messages by allowing to selectively resend 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 [RFC8724], the integrity of the fragmentation-reassembly process of a SCHC Packet MUST be checked at the receiver end. Since only Uplink/Downlink messages/fragments that have passed the Sigfox CRC-check are delivered to the Network/Sigfox Device 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 Section 3.5.1.5, MUST be used.¶

3.6. SCHC over Sigfox F/R Message Formats

This section depicts the different formats of SCHC Fragment, SCHC ACK (including the SCHC Compound ACK defined in [RFC9441]), and SCHC Abort used in SCHC over Sigfox.¶

|- SCHC Fragment Header -|
+------------------------+---------+
|   RuleID   |    FCN    | Payload |
+------------+-----------+---------+
|   3 bits   |  5 bits   | 88 bits |

|--------  SCHC Fragment Header -------|
+--------------------------------------+--------------+
| RuleID | FCN=ALL-1 |  RCS   |  b'000 |   Payload    |
+--------+-----------+--------+--------+--------------+
| 3 bits |  5 bits   | 5 bits | 3 bits | 0 to 80 bits |

     Sender-Abort
|------ Header ------|
+--------------------+
| RuleID | FCN=ALL-1 |
+--------+-----------+
| 3 bits |  5 bits   |

|-- SCHC Fragment Header --|
+--------------------------+---------+
| RuleID |   W    |  FCN   | Payload |
+--------+--------+--------+---------+
| 3 bits | 2 bits | 3 bits | 88 bits |

|-------------  SCHC Fragment Header -----------|
+-----------------------------------------------+--------------+
| RuleID |   W    | FCN=ALL-1 |  RCS   |b'00000 |   Payload    |
+--------+--------+-----------+--------+--------+--------------+
| 3 bits | 2 bits |  3 bits   | 3 bits | 5 bits | 0 to 80 bits |

|---- SCHC ACK Header ----|
+-------------------------+---------+
| RuleID |    W   | C=b'1 | b'0-pad |
+--------+--------+-------+---------+
| 3 bits | 2 bits | 1 bit | 58 bits |

|--- SCHC ACK Header ---|- W=w1 -|...|----- W=wi ------|
+------+--------+-------+--------+...+--------+--------+------+-------+
|RuleID| W=b'w1 | C=b'0 | Bitmap |...| W=b'wi | Bitmap | b'00 |b'0-pad|
+------+--------+-------+--------+...+--------+--------+------+-------+
|3 bits| 2 bits | 1 bit | 7 bits |...| 2 bits | 7 bits |2 bits|

|---- Sender-Abort Header ----|
+-----------------------------+
| RuleID | W=b'11 | FCN=ALL-1 |
+--------+--------+-----------+
| 3 bits | 2 bits |  3 bits   |

|- Receiver-Abort Header -|
+---------------------------------+-----------------+---------+
| RuleID | W=b'11 | C=b'1 |  b'11 |  0xFF (all 1's) | b'0-pad |
+--------+--------+-------+-------+-----------------+---------+
| 3 bits | 2 bits | 1 bit | 2 bit |  8 bit          | 48 bits |
          next L2 Word boundary ->| <-- L2 Word --> |

|------- SCHC Fragment Header ------|
+-----------------------------------+---------+
| RuleID |    W   |  FCN   | b'0000 | Payload |
+--------+--------+--------+--------+---------+
| 6 bits | 2 bits | 4 bits | 4 bits | 80 bits |

|--------- SCHC Fragment Header -------|
+--------------------------------------+--------------+
| RuleID |    W   | FCN=ALL-1 |  RCS   |    Payload   |
+--------+--------+-----------+--------+--------------+
| 6 bits | 2 bits |  4 bits   | 4 bits | 8 to 80 bits |

|---- SCHC ACK Header ----|
+-------------------------+---------+
| RuleID |    W   | C=b'1 | b'0-pad |
+--------+--------+-------+---------+
| 6 bits | 2 bits | 1 bit | 55 bits |

|--- SCHC ACK Header ---|- W=w1 -|...|---- W=wi -----|
+--------+------+-------+--------+...+------+--------+------+-------+
| RuleID |W=b'w1| C=b'0 | Bitmap |...|W=b'wi| Bitmap | b'00 |b'0-pad|
+--------+------+-------+--------+...+------+--------+------+-------+
| 6 bits |2 bits| 1 bit | 12 bits|...|2 bits| 12 bits|2 bits|

|- SCHC ACK Header -|- W=0 -|      |- W=1 -|...
+------+------+-----+-------+------+-------+...
|RuleID|W=b'00|C=b'0|Bitmap |W=b'01|Bitmap |...
+------+------+-----+-------+------+-------+...
|6 bits|2 bits|1 bit|12 bits|2 bits|12 bits|...

            ...       |- W=2 -|      |- W=3 -|
            ...+------+-------+------+-------+---+
            ...|W=b'10|Bitmap |W=b'11|Bitmap |b'0|
            ...+------+-------+------+-------+---+
            ...|2 bits|12 bits|2 bits|12 bits|

|---- Sender-Abort Header ----|
+-----------------------------+
| RuleID |   W    | FCN=ALL-1 |
+--------+--------+-----------+
| 6 bits | 2 bits |  4 bits   |

|- Receiver-Abort Header -|
+---------------------------------+-----------------+---------+
| RuleID | W=b'11 | C=b'1 |  0x7F |  0xFF (all 1's) | b'0-pad |
+--------+--------+-------+-------+-----------------+---------+
| 6 bits | 2 bits | 1 bit | 7 bit |  8 bit          | 40 bits |
          next L2 Word boundary ->| <-- L2 Word --> |

|-- SCHC Fragment Header --|
+--------------------------+---------+
| RuleID |   W    | FCN    | Payload |
+--------+--------+--------+---------+
| 8 bits | 3 bits | 5 bits | 80 bits |

|-------------- SCHC Fragment Header -----------|
+-----------------------------------------------+--------------+
| RuleID |    W   | FCN=ALL-1 |  RCS   | b'000  |    Payload   |
+--------+--------+-----------+--------+--------+--------------+
| 8 bits | 3 bits |  5 bits   | 5 bits | 3 bits | 8 to 72 bits |

|---- SCHC ACK Header ----|
+-------------------------+---------+
| RuleID |    W   | C=b'1 | b'0-pad |
+--------+--------+-------+---------+
| 8 bits | 3 bits | 1 bit | 52 bits |

|-- SCHC ACK Header --|- W=w1 -|...|---- W=wi -----|
+------+------+-------+--------+...+------+--------+------+-------+
|RuleID|W=b'w1| C=b'0 | Bitmap |...|W=b'wi| Bitmap | 000  |b'0-pad|
+------+------+-------+--------+...+------+--------+------+-------+
|8 bits|3 bits| 1 bit | 31 bits|...|3 bits| 31 bits|3 bits|

|---- Sender-Abort Header ----|
+-----------------------------+
| RuleID |   W    | FCN=ALL-1 |
+--------+--------+-----------+
| 8 bits | 3 bits |  5 bits   |

|-- Receiver-Abort Header -|
+-----------------------------------+-----------------+---------+
| RuleID | W=b'111 | C=b'1 | b'1111 |  0xFF (all 1's) | b'0-pad |
+--------+---------+-------+--------+-----------------+---------+
| 8 bits |  3 bits | 1 bit | 4 bit  |  8 bit          | 40 bits |
            next L2 Word boundary ->| <-- L2 Word --> |

   SCHC Fragment
|--    Header   --|
+-----------------+---------+
| RuleID |  FCN   | Payload |
+--------+--------+---------+
| 3 bits | 5 bits | 56 bits |

|--------- SCHC Fragment Header -------|
+--------------------------------------+--------------+
| RuleID | FCN=ALL-1 |  RCS   | b'000  |    Payload   |
+--------+-----------+--------+--------+--------------+
| 3 bits |  5 bits   | 5 bits | 3 bits | 0 to 48 bits |

     SCHC ACK
|--   Header   --|
+----------------+---------+
| RuleID | C=b'1 | b'0-pad |
+--------+-------+---------+
| 3 bits | 1 bit |  4 bits |

|---- SCHC ACK Header ----|
+--------+-------+--------+---------+
| RuleID | C=b'0 | Bitmap | b'0-pad |
+--------+-------+--------+---------+
| 3 bits | 1 bit | 31 bits|  5 bits |

     Sender-Abort
|----   Header   ----|
+--------------------+
| RuleID | FCN=ALL-1 |
+--------+-----------+
| 3 bits |  5 bits   |

  Receiver-Abort
|---  Header  ---|
+----------------+--------+-----------------+
| RuleID | C=b'1 | b'1111 |  0xFF (all 1's) |
+--------+-------+--------+-----------------+
| 3 bits | 1 bit | 4 bit  |  8 bit          |

3.7. Padding

The Sigfox payload fields have different characteristics in Uplink and Downlink.¶

Uplink messages 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.¶

On the other hand, Downlink frames 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. The receiver MUST remove the added padding bits before the SCHC reassembly process.¶

4.1. Uplink Fragmentation Rules Examples

The RuleID field for Uplink F/R modes has different sizes depending on the header length. In order to identify the header length and then the value of the RuleID, the RuleID field is interpreted as follows:¶

• The RuleID field is the first one to be parsed in the SCHC header, starting from the leftmost bits.¶

• For Single-byte SCHC Header F/R modes, a RuleID field of 3 bits is expected:¶

  • If the first 3 leftmost bits have a value different than 0b'111, then it signals a Single-byte SCHC Header F/R mode.¶
  • If their value is 0b'111, then it signals a Two-byte SCHC Header F/R mode.¶

• For Single-byte SCHC Header F/R modes:¶

  • There are 7 RuleIDs available (with values from 0b'000-0b'110); the RuleID with value 0b'111 is reserved to indicate a Two-byte SCHC Header.¶
  • This set of Rules is called "standard rules", and it is used to implement Single-byte SCHC Header modes.¶
  • Each RuleID is associated with a set of properties defining if Uplink F/R is used and which Uplink F/R mode is used. As an example, the RuleID 0b'000 is mapped onto Uplink No-ACK Mode: Single-byte SCHC Header, and the RuleIDs 0b'001 and 0b'002 are mapped onto Uplink ACK-on-Error mode: Single-byte SCHC Header (2 RuleIDs to allow for SCHC Packet interleaving).¶

• For Two-byte SCHC Header F/R modes, at least 6 bits for the RuleID field are expected:¶

  • The 3 first leftmost bits are always 0b'111.¶

    • If the following 3 bits have a different value than 0b'111, then it signals the Two-byte SCHC Header Option 1.¶
    • If the following 3 bits are 0b'111, then it signals the Two-byte SCHC Header Option 2.¶
  • For the Two-byte SCHC Header Option 1, there are 7 RuleIDs available (0b'111000-0b'111110), 0b'111111 being reserved to indicate the Two-byte SCHC Header Option 2. This set of Rules is called "extended rules", and it is used to implement the Uplink ACK-on-Error mode: Two-byte SCHC Header Option 1.¶
  • For the Two-byte SCHC Header Option 2, there are 2 additional bits to parse as the RuleID, so 4 RuleIDs are available (0b'11111100-0b'11111111). This set of Rules is used to cover specific cases that previous RuleIDs do not cover. As an example, RuleID 0b'00111111 is used to transport uncompressed IPv6 packets using the Uplink ACK-on-Error mode: Two-byte SCHC Header Option 2.¶

4.2. Downlink Fragmentation Rules Example

For the Downlink ACK-Always Mode: Single-byte SCHC Header, RuleIDs can get values in ranges from 0b'000 to 0b'111.¶

5.1. Uplink No-ACK Examples

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. The last packet fragment is marked with FCN = All-1 (1111).¶

Case No Losses - All fragments are sent and received successfully.¶

Sender                     Receiver
  |-------FCN=6,Seq=1-------->|
  |-------FCN=5,Seq=2-------->|
  |-------FCN=4,Seq=3-------->|
  |-------FCN=3,Seq=4-------->|
  |-------FCN=2,Seq=5-------->|
  |-------FCN=1,Seq=6-------->|
  |-------FCN=15,Seq=7------->| All fragments received
(End)

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 an FCN equal to 15).¶

Case Losses on Any Fragment except the First¶

Sender                     Receiver
  |-------FCN=6,Seq=1-------->|
  |-------FCN=5,Seq=2----X    |
  |-------FCN=4,Seq=3-------->|
  |-------FCN=3,Seq=4-------->|
  |-------FCN=2,Seq=5-------->|
  |-------FCN=1,Seq=6-------->|
  |-------FCN=15,Seq=7------->| Missing Fragment Unable to reassemble
(End)

5.2. Uplink ACK-on-Error Examples: Single-Byte SCHC Header

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 Losses¶

The 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 MUST enable the Downlink and wait for an ACK.¶

        Sender                    Receiver
          |-----W=0,FCN=6,Seq=1----->|
          |-----W=0,FCN=5,Seq=2----->|
          |-----W=0,FCN=4,Seq=3----->|
          |-----W=0,FCN=3,Seq=4----->|
          |-----W=0,FCN=2,Seq=5----->|
          |-----W=0,FCN=1,Seq=6----->|
DL Enable |-----W=0,FCN=0,Seq=7----->|
      (no ACK)
          |-----W=1,FCN=6,Seq=8----->|
          |-----W=1,FCN=5,Seq=9----->|
          |-----W=1,FCN=4,Seq=10---->|
DL Enable |-----W=1,FCN=7,Seq=11---->| All fragments received
          |<- Compound ACK,W=1,C=1 --| C=1
        (End)

Case Fragment Losses in the First Window¶

In 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. Note that the SCHC Compound ACK also uses a Sequence Number.¶

        Sender                    Receiver
          |-----W=0,FCN=6,Seq=1----->|
          |-----W=0,FCN=5,Seq=2--X   |
          |-----W=0,FCN=4,Seq=3----->|
          |-----W=0,FCN=3,Seq=4----->|
          |-----W=0,FCN=2,Seq=5--X   |                    __
          |-----W=0,FCN=1,Seq=6----->|                   | W=0
DL Enable |-----W=0,FCN=0,Seq=7----->| Missing Fragments<- FCN=5,Seq=2
          |<- Compound ACK,W=0,C=0 --| Bitmap:1011011    | FCN=2,Seq=5
          |-----W=0,FCN=5,Seq=9----->|                    --
          |-----W=0,FCN=2,Seq=10---->|
          |-----W=1,FCN=6,Seq=11---->|
          |-----W=1,FCN=5,Seq=12---->|
          |-----W=1,FCN=4,Seq=13---->|
DL Enable |-----W=1,FCN=7,Seq=14---->| All fragments received
          |<-Compound ACK,W=1,C=1 ---| C=1
        (End)

Case Fragment All-0 Lost in the 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, which indicates that the All-0 of window 0 is absent.¶

The sender resends the missing All-0 messages (with any other missing fragment from window 0) without opening a reception opportunity.¶

        Sender                    Receiver
          |-----W=0,FCN=6,Seq=1----->|
          |-----W=0,FCN=5,Seq=2----->|
          |-----W=0,FCN=4,Seq=3----->|
          |-----W=0,FCN=3,Seq=4----->|
          |-----W=0,FCN=2,Seq=5----->|
          |-----W=0,FCN=1,Seq=6----->| DL Enable
          |-----W=0,FCN=0,Seq=7--X   |
      (no ACK)
          |-----W=1,FCN=6,Seq=8----->|
          |-----W=1,FCN=5,Seq=9----->|                    __
          |-----W=1,FCN=4,Seq=10---->|                   |W=0
DL Enable |-----W=1,FCN=7,Seq=11---->| Missing Fragment<- FCN=0,Seq=7
          |<-Compound ACK,W=0,C=0 ---| Bitmap:1111110    |__
          |-----W=0,FCN=0,Seq=13---->| All fragments received
DL Enable |-----W=1,FCN=7,Seq=14---->|
          |<-Compound ACK,W=1,C=1 ---| C=1
        (End)

In the following diagram, besides the All-0, there are other fragment losses in the first window (W=0).¶

        Sender                    Receiver
          |-----W=0,FCN=6,Seq=1----->|
          |-----W=0,FCN=5,Seq=2--X   |
          |-----W=0,FCN=4,Seq=3----->|
          |-----W=0,FCN=3,Seq=4--X   |
          |-----W=0,FCN=2,Seq=5----->|
          |-----W=0,FCN=1,Seq=6----->|
DL Enable |-----W=0,FCN=0,Seq=7--X   |
      (no ACK)
          |-----W=1,FCN=6,Seq=8----->|
          |-----W=1,FCN=5,Seq=9----->|                    __
          |-----W=1,FCN=4,Seq=10---->|                   |W=0
DL Enable |-----W=1,FCN=7,Seq=11---->| Missing Fragment<- FCN=5,Seq=2
          |<--Compound ACK,W=0,C=0 --| Bitmap:1010110    |FCN=3,Seq=4
          |-----W=0,FCN=5,Seq=13---->|                   |FCN=0,Seq=7
          |-----W=0,FCN=3,Seq=14---->|                    --
          |-----W=0,FCN=0,Seq=15---->| All fragments received
DL Enable |-----W=1,FCN=7,Seq=16---->|
          |<-Compound ACK,W=1,C=1 ---| C=1
        (End)

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) MUST always finish with an All-1, as it serves as an ACK Request message to confirm the correct reception of the retransmitted fragments.¶

        Sender                    Receiver
          |-----W=0,FCN=6,Seq=1----->|
          |-----W=0,FCN=5,Seq=2--X   |
          |-----W=0,FCN=4,Seq=3----->|
          |-----W=0,FCN=3,Seq=4--X   |                    __
          |-----W=0,FCN=2,Seq=5----->|                   |W=0
          |-----W=0,FCN=1,Seq=6----->|                   |FCN=5,Seq=2
DL Enable |-----W=0,FCN=0,Seq=7--X   |                   |FCN=3,Seq=4
     (no ACK)                                            |FCN=0,Seq=7
          |-----W=1,FCN=6,Seq=8--X   |                   |W=1
          |-----W=1,FCN=5,Seq=9----->|                   |FCN=6,Seq=8
          |-----W=1,FCN=4,Seq=10-X   |                   |FCN=4,Seq=10
DL Enable |-----W=1,FCN=7,Seq=11---->| Missing Fragment<-|__
          |<-Compound ACK,W=0,1,C=0--| Bitmap W=0:1010110
          |-----W=0,FCN=5,Seq=13---->|        W=1:0100001
          |-----W=0,FCN=3,Seq=14---->|
          |-----W=0,FCN=0,Seq=15---->|
          |-----W=1,FCN=6,Seq=16---->|
          |-----W=1,FCN=4,Seq=17---->| All fragments received
DL Enable |-----W=1,FCN=7,Seq=18---->|
          |<-Compound ACK,W=1,C=1----| C=1
        (End)

The figure below is a similar case as above but with fewer fragments in the second window (W=1).¶

        Sender                    Receiver
          |-----W=0,FCN=6,Seq=1----->|
          |-----W=0,FCN=5,Seq=2--X   |
          |-----W=0,FCN=4,Seq=3----->|
          |-----W=0,FCN=3,Seq=4--X   |
          |-----W=0,FCN=2,Seq=5----->|                     __
          |-----W=0,FCN=1,Seq=6----->|                    |W=0
DL Enable |-----W=0,FCN=0,Seq=7--X   |                    |FCN=5,Seq=2
       (no ACK)                                           |FCN=3,Seq=4
          |-----W=1,FCN=6,Seq=8--X   |                    |FCN=0,Seq=7
DL Enable |-----W=1,FCN=7,Seq=9----->| Missing Fragment--> W=1
          |<-Compound ACK,W=0,1, C=0-| Bitmap W=0:1010110,|FCN=6,Seq=8
          |-----W=0,FCN=5,Seq=11---->|        W=1:0000001 |__
          |-----W=0,FCN=3,Seq=12---->|
          |-----W=0,FCN=0,Seq=13---->|
          |-----W=1,FCN=6,Seq=14---->| All fragments received
DL Enable |-----W=1,FCN=7,Seq=15---->|
          |<-Compound ACK, W=1,C=1---| C=1
        (End)

Case SCHC ACK is Lost¶

SCHC 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.¶

       Sender                     Receiver
          |-----W=0,FCN=6,Seq=1----->|
          |-----W=0,FCN=5,Seq=2----->|
          |-----W=0,FCN=4,Seq=3----->|
          |-----W=0,FCN=3,Seq=4----->|
          |-----W=0,FCN=2,Seq=5----->|
          |-----W=0,FCN=1,Seq=6----->|
DL Enable |-----W=0,FCN=0,Seq=7----->|
      (no ACK)
          |-----W=1,FCN=6,Seq=8----->|
          |-----W=1,FCN=5,Seq=9----->|
          |-----W=1,FCN=4,Seq=10---->|
DL Enable |-----W=1,FCN=7,Seq=11---->| All fragments received
          | X--Compound ACK,W=1,C=1 -| C=1
DL Enable |-----W=1,FCN=7,Seq=13---->| RESEND ACK
          |<-Compound ACK,W=1,C=1 ---| C=1
        (End)

Case SCHC Compound ACK at the End¶

In this example, SCHC Fragment losses are found in both windows 0 and 1. However, the sender does not send a SCHC Compound ACK after the All-0 of window 0. Instead, it sends a SCHC Compound ACK indicating fragment losses on both windows.¶

        Sender                    Receiver
          |-----W=0,FCN=6,Seq=1----->|
          |-----W=0,FCN=5,Seq=2--X   |
          |-----W=0,FCN=4,Seq=3----->|
          |-----W=0,FCN=3,Seq=4--X   |
          |-----W=0,FCN=2,Seq=5----->|
          |-----W=0,FCN=1,Seq=6----->|                     __
DL Enable |-----W=0,FCN=0,Seq=7----->| Waits for          |W=0
       (no ACK)                       next DL opportunity |FCN=5,Seq=2
          |-----W=1,FCN=6,Seq=8--X   |                    |FCN=3,Seq=4
DL Enable |-----W=1,FCN=7,Seq=9----->| Missing Fragment<-- W=1
          |<-Compound ACK,W=0,1, C=0-| Bitmap W=0:1010110 |FCN=6,Seq=8
          |-----W=0,FCN=5,Seq=11---->|        W=1:0000001  --
          |-----W=0,FCN=3,Seq=12---->|
          |-----W=1,FCN=6,Seq=13---->| All fragments received
DL Enable |-----W=1,FCN=7,Seq=14---->|
          |<-Compound ACK, W=1, C=1 -| C=1
        (End)

The number of times the same SCHC ACK message will be retransmitted is determined by the MAX_ACK_REQUESTS.¶

5.3. SCHC Abort Examples

Case SCHC Sender-Abort¶

The sender may need to send a Sender-Abort to stop the current communication. For example, this may happen if the All-1 has been sent MAX_ACK_REQUESTS times.¶

        Sender                    Receiver
          |-----W=0,FCN=6,Seq=1----->|
          |-----W=0,FCN=5,Seq=2----->|
          |-----W=0,FCN=4,Seq=3----->|
          |-----W=0,FCN=3,Seq=4----->|
          |-----W=0,FCN=2,Seq=5----->|
          |-----W=0,FCN=1,Seq=6----->|
DL Enable |-----W=0,FCN=0,Seq=7----->|
      (no ACK)
          |-----W=1,FCN=6,Seq=8----->|
          |-----W=1,FCN=5,Seq=9----->|
          |-----W=1,FCN=4,Seq=10---->|
DL Enable |-----W=1,FCN=7,Seq=11---->| All fragments received
          | X--Compound ACK,W=1,C=1 -| C=1
DL Enable |-----W=1,FCN=7,Seq=13---->| RESEND ACK  (1)
          | X--Compound ACK,W=1,C=1 -| C=1
DL Enable |-----W=1,FCN=7,Seq=15---->| RESEND ACK  (2)
          | X--Compound ACK,W=1,C=1 -| C=1
DL Enable |-----W=1,FCN=7,Seq=17---->| RESEND ACK  (3)
          | X--Compound ACK,W=1,C=1 -| C=1
DL Enable |-----W=1,FCN=7,Seq=18---->| RESEND ACK  (4)
          | X--Compound ACK,W=1,C=1 -| C=1
DL Enable |-----W=1,FCN=7,Seq=19---->| RESEND ACK  (5)
          | X--Compound ACK,W=1,C=1 -| C=1
DL Enable |----Sender-Abort,Seq=20-->| exit with error condition
        (End)

Case Receiver-Abort¶

The receiver may need to send a Receiver-Abort to stop the current communication. This message can only be sent after a Downlink Enable.¶

        Sender                    Receiver
          |-----W=0,FCN=6,Seq=1----->|
          |-----W=0,FCN=5,Seq=2----->|
          |-----W=0,FCN=4,Seq=3----->|
          |-----W=0,FCN=3,Seq=4----->|
          |-----W=0,FCN=2,Seq=5----->|
          |-----W=0,FCN=1,Seq=6----->|
DL Enable |-----W=0,FCN=0,Seq=7----->|
          |<------  RECV ABORT ------| under-resourced
       (Error)