Energy Consumption Model of SCHC Packet Fragmentation over Sigfox LPWAN

The Internet Engineering Task Force (IETF) has standardized a new framework, called Static Context Header Compression and fragmentation (SCHC), which offers adaptation layer functionality designed to support IPv6 over Low Power Wide Area Networks (LPWANs). The IETF is currently profiling SCHC, and in particular its packet fragmentation and reassembly functionality, for its optimal use over certain LPWAN technologies. Considering the energy constraints of LPWAN devices, it is crucial to determine the energy performance of SCHC packet transfer. In this paper, we present a current and energy consumption model of SCHC packet transfer over Sigfox, a flagship LPWAN technology. The model, which is based on real hardware measurements, allows to determine the impact of several parameters and fragment transmission strategies on the energy performance of SCHC packet transfer over Sigfox. Among other results, we have found that the lifetime of a device powered by a 2000 mAh battery, transmitting packets every 5 days, is 168 days for 2250-byte packets, while it increases to 1464 days for 77-byte packets.


Introduction
In the last years, Low Power Wide Area Network (LPWAN) technologies have gained significant momentum as solutions for providing connectivity to Internet of Things (IoT) devices. LPWANs typically offer unique characteristics, such as a simple star network topology, a link range in the order of several kilometers, and low energy consumption, which enables multiyear lifetimes for battery-operated IoT devices [1]. Relevant LPWAN technologies include Sigfox, LoRaWAN, NB-IoT, and IEEE 802.15.4 w [2].
LPWAN technologies typically support low bit rates, which contribute to achieving long link range. However, packet transmission at a low bit rate leads to high energy consumption due to a high packet transmission time. In order to limit the impact of this problem, many LPWAN technologies are characterized by a short Layer 2 (L2) frame size. On the other hand, LPWAN devices can benefit from Internet connectivity by supporting IPv6. However, IPv6 requires its underlying layer to support a Maximum Transmission Unit (MTU) of at least 1280 bytes [3]. If an LPWAN technology does not offer packet Fragmentation and Reassembly (F/R) functionality, such as Sigfox or LoRaWAN, an adaptation layer including F/R support is needed between IPv6 and the underlying LPWAN technology. To this end, the IETF has recently developed a standard called Static Context Header Compression and fragmentation (SCHC) [4].
SCHC provides adaptation layer functionality that includes F/R. SCHC F/R allows to transmit packets even if they have a size greater than the supported L2 MTU. SCHC has been purposefully specified following a generic approach, since it was envisioned that SCHC would be used on top of several technologies. For each LPWAN technology, a companion specification called a SCHC Profile determines which SCHC components need to be supported and how they are configured [5][6][7]. device battery lifetime for small daily throughputs than other LPWAN technologies. Their theoretical evaluation was based on the AX-Sigfox module. Similar results are presented in [25]. In [26], Lykov et al. studied Sigfox, using the AX-SIP-SFEU radio module. The authors found that, for a battery capacity of 2000 mAh, a payload size increase will reduce the device lifetime by up to 18 days, and that a daily message rate increase (up to 140 messages/day) can reduce the device lifetime down to 209 days. Table 1 presents a summary of published works that evaluate Sigfox energy performance. None of these studies modeled the energy consumption of packet fragmentation over Sigfox.

SCHC F/R
Authors in [8] showed that SCHC packet fragmentation can increase reliability, with a trade-off in terms of energy consumption and goodput. The same authors analyzed in [9] the use of SCHC packet fragmentation to reduce network congestion and increase network capacity. An overview and a simple evaluation showing the header and message overhead of SCHC F/R is presented in [2]. Other performance metrics, such as total channel occupancy, goodput and total delay were studied in [10], over an ideal channel. Optimal configuration values for SCHC F/R over LoRaWAN and Sigfox were provided in [11]. SCHC Receiver-Feedback Techniques (RFTs) and alternative RFTs were presented and evaluated in [12] over LoRaWAN, as part of a reliable fragmentation method. Results show that alternative RFTs may be optimal depending on the error rate and pattern, providing greater efficiency.
Since the publication of the base SCHC specification [4], the IETF LPWAN WG has been developing SCHC Profiles, which provide configurations of SCHC F/R functionality tailored to specific LPWAN technologies, such as Sigfox [6], LoRaWAN [5], and NB-IoT [7]. Sanchez-Gomez et al. [13] presented an evaluation of the LoRaWAN SCHC Profile in a real testbed. SCHC F/R provided benefits in terms packet delivery ratio, with a processing time overhead below 8 ms and a memory usage of only 609 bytes. Santa et al. [14] used SCHC to support IPv6 over LoRaWAN and NB-IoT for personal mobility vehicles. NB-IoT showed lower latency and low fragment error rate; however, it consumed more power than LoRaWAN. In [15], SCHC fragmentation over Sigfox was overviewed and evaluated theoretically and empirically by using a LoPy4 module, in terms of transfer time and number of Sigfox uplink and downlink messages. Muñoz et al. [16] evaluated SCHC over LoRaWAN and obtained a model to determine channel occupancy efficiency based on LoRaWAN and SCHC configuration parameters.  Table 2 summarizes the works related to SCHC F/R performance evaluation, along with the performance parameters and the method used. Together, these studies provide important insights into SCHC F/R. However, they neither provide a detailed model of, nor evaluate, the current consumption or the energy performance of SCHC Packet transfer. Table 2. List of references related to SCHC F/R performance evaluation.

Reference
Performance Parameters Method Energy Performance Evaluation [8] Overhead, throughput, goodput, end to end delay Simulation No [9] Goodput, application capacity, efficiency, header overhead Simulation No [2] Header compression, number of fragments, number of ACKs Theoretical No [10] Channel occupancy, goodput, total delay Simulation No [11] ACK message overhead, ACK bit overhead with and without L2 headers Theoretical No [12] Error rates and patterns Simulation No [13] Packet delivery ratio, goodput per ToA Experimental No [14] Network delay, SNR, power consumption Experimental No [15] Transfer time, number of uplink and downlink messages Theoretical, Experimental No [16] Channel occupancy efficiency Theoretical, Experimental No To the best of our knowledge, no previous work provides a current or energy consumption model nor evaluates the energy performance of fragmented packet transfer with SCHC.

Sigfox
This section overviews the Sigfox technology. The section is organized into four subsections that focus on the following features of Sigfox, respectively: network architecture, physical layer features, communication procedures, and frame formats. Figure 1 shows the main elements of the Sigfox network architecture. Sigfox is based on a star of stars topology composed of three main parts: the device (i.e., the IoT device such as a sensor or an actuator), the Sigfox Network (which comprises Base Stations and the Sigfox cloud), and the application server (where the end-user application is hosted). The device sends data that may be received by one or more Base Stations, which provides spatial diversity. Base Stations send the messages received to the Sigfox cloud over IP. The latter is in charge of message reconstruction and message duplication avoidance. Messages are then forwarded from the Sigfox cloud to the application server by using HTTP (e.g., an HTTP POST message with a JSON payload). The application server may respond after the receipt of a message with data to be sent to the device.

Physical Layer Features
Sigfox is a global network operator for IoT devices that uses unlicensed sub-GHz frequency bands, ranging from 862 MHz to 928 MHz. Due to local spectrum access regulations in different countries and world regions, Sigfox defines seven geographical zones, each one with a specific Radio Configuration (RC), called RC1 to RC7, respectively. An RC establishes a particular set of operation frequencies, output transmit power, spectrum access mechanism and Uplink (UL) bitrate. The UL bitrate may either be 100 bit/s or 600 bit/s, while the Downlink (DL) bitrate is 600 bits/s in all RCs.
In RC1 (which is defined for Europe, Middle East, and Africa), the operational frequencies are 868.130 MHz and 869.525 MHz for the UL and the DL, respectively. The system supports using different frequency channels over one 192 kHz band for UL transmission and over another 192 kHz band for DL transmission. Sigfox uses Ultra Narrow Band (UNB) transmission, which is intended to overcome noise and interference issues. The channel bandwidth is 100 Hz and 1.5 kHz for UL and DL channels, respectively. DBPSK and GPSK modulations are used for UL and DL transmission, respectively, for the sake of spectrum efficiency, base station sensitivity, and device cost.
In order to comply with spectrum access regulations, RC1 defines a duty cycle limitation of 1% and 10% in the UL and in the DL, respectively, that must be enforced in a per-hour basis. To this end, Sigfox allows a device in RC1 to send only up to 6 full-sized UL messages per hour.

Communication Procedures
Sigfox defines two communication procedures: the Uplink Procedure (U-Proc), which is used by the device to transmit data messages to the network, and the Bidirectional Procedure (B-Proc), which allows the device to transmit an UL message and enable an opportunity for a subsequent DL message. We next describe both communication procedures.

U-Proc
A U-Proc is carried out by a device in order to send an UL frame. The device can start a U-Proc at any moment, provided that spectrum access regulations of the corresponding RC are followed.
Sigfox UL transmission supports time and frequency diversity. The UL frame is transmitted three times, where each one of the three transmissions is performed over a different frequency channel. Figure 2 shows an example of a U-Proc.

Physical Layer Features
Sigfox is a global network operator for IoT devices that uses unlicensed sub-GHz frequency bands, ranging from 862 MHz to 928 MHz. Due to local spectrum access regulations in different countries and world regions, Sigfox defines seven geographical zones, each one with a specific Radio Configuration (RC), called RC1 to RC7, respectively. An RC establishes a particular set of operation frequencies, output transmit power, spectrum access mechanism and Uplink (UL) bitrate. The UL bitrate may either be 100 bit/s or 600 bit/s, while the Downlink (DL) bitrate is 600 bits/s in all RCs.
In RC1 (which is defined for Europe, Middle East, and Africa), the operational frequencies are 868.130 MHz and 869.525 MHz for the UL and the DL, respectively. The system supports using different frequency channels over one 192 kHz band for UL transmission and over another 192 kHz band for DL transmission. Sigfox uses Ultra Narrow Band (UNB) transmission, which is intended to overcome noise and interference issues. The channel bandwidth is 100 Hz and 1.5 kHz for UL and DL channels, respectively. DBPSK and GPSK modulations are used for UL and DL transmission, respectively, for the sake of spectrum efficiency, base station sensitivity, and device cost.
In order to comply with spectrum access regulations, RC1 defines a duty cycle limitation of 1% and 10% in the UL and in the DL, respectively, that must be enforced in a per-hour basis. To this end, Sigfox allows a device in RC1 to send only up to 6 full-sized UL messages per hour.

Communication Procedures
Sigfox defines two communication procedures: the Uplink Procedure (U-Proc), which is used by the device to transmit data messages to the network, and the Bidirectional Procedure (B-Proc), which allows the device to transmit an UL message and enable an opportunity for a subsequent DL message. We next describe both communication procedures.

U-Proc
A U-Proc is carried out by a device in order to send an UL frame. The device can start a U-Proc at any moment, provided that spectrum access regulations of the corresponding RC are followed.
Sigfox UL transmission supports time and frequency diversity. The UL frame is transmitted three times, where each one of the three transmissions is performed over a different frequency channel. Figure 2 shows an example of a U-Proc.

B-Proc
In Sigfox, DL transmission requires the device to perform a B-Proc, whereby the device first transmits an UL frame. The UL frame header carries a field that indicates that the device will allow a response from the network. The device opens a reception window, and the network or the application server may choose to send data, if available, or wait for another DL opportunity. If no message is received by the device, the reception window will be closed after T RX MAX (i.e., 25 s in RC1) time has passed. If a DL frame is received by Sensors 2022, 22, 2120 6 of 23 the device, the latter transmits an UL confirmation control frame. Figure 3a,b illustrates the B-Proc when a DL frame is received and when it is not received, respectively.

B-Proc
In Sigfox, DL transmission requires the device to perform a B-Proc, whereby the device first transmits an UL frame. The UL frame header carries a field that indicates that the device will allow a response from the network. The device opens a reception window, and the network or the application server may choose to send data, if available, or wait for another DL opportunity. If no message is received by the device, the reception window will be closed after TRX MAX (i.e., 25 s in RC1) time has passed. If a DL frame is received by the device, the latter transmits an UL confirmation control frame. Figure 3a,b illustrates the B-Proc when a DL frame is received and when it is not received, respectively.

Frame Formats
This section briefly describes the data frame formats supported in Sigfox, for both the UL and the DL.
The UL frame is composed of a UL frame payload, with a size that may vary from 0 to 96 bits. Additionally, the Sigfox protocol prepends an 81-bit header and appends between 32-bit to 56-bit tail bits to the UL frame payload. The Sigfox protocol header fields include a Preamble, a Frame Type, a Length Indicator, a Bidirectional Flag, a Repeated Flag, a Message Counter, and a Device ID. The Bidirectional Flag indicates if the UL frame corresponds to a U-Proc or a B-Proc. The tail includes Message Authentication and Cyclic Redundancy Check (CRC) fields.
The confirmation control frame shares the same format as the UL frame and carries information of the status of the MCU, such as the battery voltage value during and in the absence of radio transmissions, the MCU temperature and the signal strength estimated while receiving the DL frame.
The DL frame contains a fixed size 64-bit DL frame payload; therefore, padding bits must be added if a shorter data payload size needs to be transferred. A Sigfox protocol header of 136 bits is prepended to the DL frame payload, including a Preamble, a Field type, and an Error Correction Code (ECC). In a similar way to the UL frame, the tail of the DL frame includes Message Authentication and CRC fields. This tail has a size of 24 bits.

SCHC over Sigfox
In this section, we introduce the basic concepts of the SCHC over Sigfox Profile (in short, SCHC over Sigfox), focusing on how SCHC F/R is used over Sigfox radio links to enable reliable fragmented packet transfer.

B-Proc
In Sigfox, DL transmission requires the device to perform a B-Proc, whereby the device first transmits an UL frame. The UL frame header carries a field that indicates that the device will allow a response from the network. The device opens a reception window, and the network or the application server may choose to send data, if available, or wait for another DL opportunity. If no message is received by the device, the reception window will be closed after TRX MAX (i.e., 25 s in RC1) time has passed. If a DL frame is received by the device, the latter transmits an UL confirmation control frame. Figure 3a,b illustrates the B-Proc when a DL frame is received and when it is not received, respectively.

Frame Formats
This section briefly describes the data frame formats supported in Sigfox, for both the UL and the DL.
The UL frame is composed of a UL frame payload, with a size that may vary from 0 to 96 bits. Additionally, the Sigfox protocol prepends an 81-bit header and appends between 32-bit to 56-bit tail bits to the UL frame payload. The Sigfox protocol header fields include a Preamble, a Frame Type, a Length Indicator, a Bidirectional Flag, a Repeated Flag, a Message Counter, and a Device ID. The Bidirectional Flag indicates if the UL frame corresponds to a U-Proc or a B-Proc. The tail includes Message Authentication and Cyclic Redundancy Check (CRC) fields.
The confirmation control frame shares the same format as the UL frame and carries information of the status of the MCU, such as the battery voltage value during and in the absence of radio transmissions, the MCU temperature and the signal strength estimated while receiving the DL frame.
The DL frame contains a fixed size 64-bit DL frame payload; therefore, padding bits must be added if a shorter data payload size needs to be transferred. A Sigfox protocol header of 136 bits is prepended to the DL frame payload, including a Preamble, a Field type, and an Error Correction Code (ECC). In a similar way to the UL frame, the tail of the DL frame includes Message Authentication and CRC fields. This tail has a size of 24 bits.

SCHC over Sigfox
In this section, we introduce the basic concepts of the SCHC over Sigfox Profile (in short, SCHC over Sigfox), focusing on how SCHC F/R is used over Sigfox radio links to enable reliable fragmented packet transfer.

Frame Formats
This section briefly describes the data frame formats supported in Sigfox, for both the UL and the DL.
The UL frame is composed of a UL frame payload, with a size that may vary from 0 to 96 bits. Additionally, the Sigfox protocol prepends an 81-bit header and appends between 32-bit to 56-bit tail bits to the UL frame payload. The Sigfox protocol header fields include a Preamble, a Frame Type, a Length Indicator, a Bidirectional Flag, a Repeated Flag, a Message Counter, and a Device ID. The Bidirectional Flag indicates if the UL frame corresponds to a U-Proc or a B-Proc. The tail includes Message Authentication and Cyclic Redundancy Check (CRC) fields.
The confirmation control frame shares the same format as the UL frame and carries information of the status of the MCU, such as the battery voltage value during and in the absence of radio transmissions, the MCU temperature and the signal strength estimated while receiving the DL frame.
The DL frame contains a fixed size 64-bit DL frame payload; therefore, padding bits must be added if a shorter data payload size needs to be transferred. A Sigfox protocol header of 136 bits is prepended to the DL frame payload, including a Preamble, a Field type, and an Error Correction Code (ECC). In a similar way to the UL frame, the tail of the DL frame includes Message Authentication and CRC fields. This tail has a size of 24 bits.

SCHC over Sigfox
In this section, we introduce the basic concepts of the SCHC over Sigfox Profile (in short, SCHC over Sigfox), focusing on how SCHC F/R is used over Sigfox radio links to enable reliable fragmented packet transfer.
The current version of SCHC over Sigfox [6] includes a reliable F/R mode called ACK-on-Error. This mode supports selective fragment retransmission along with receiver feedback given by messages called SCHC ACKs, which report whether SCHC Fragments have been successfully received or not.
The next subsections describe the main tools used to support reliable packet fragmentation by means of ACK-on-Error, the functionality provided by this mode, and how it is configured when used over Sigfox.

Tiles, Windows and Bitmaps
In SCHC, the data unit to be transferred is called a SCHC Packet. If the SCHC Packet is larger than the L2 maximum payload size (e.g., 12 bytes), it is fragmented in smaller units called tiles (see Figure 4). In ACK-on-Error, tiles have a fixed size, except for the last one, which can be smaller (see Section 4.2 for further details). Tiles are carried as the payload of data units called SCHC Fragments. Tiles are numbered using an identifier called Fragment Compressed Number (FCN). A special FCN value with all bits set to 1 indicates the last tile of the SCHC Packet.
The current version of SCHC over Sigfox [6] includes a reliable F/R mode called ACKon-Error. This mode supports selective fragment retransmission along with receiver feedback given by messages called SCHC ACKs, which report whether SCHC Fragments have been successfully received or not.
The next subsections describe the main tools used to support reliable packet fragmentation by means of ACK-on-Error, the functionality provided by this mode, and how it is configured when used over Sigfox.

Tiles, Windows and Bitmaps
In SCHC, the data unit to be transferred is called a SCHC Packet. If the SCHC Packet is larger than the L2 maximum payload size (e.g., 12 bytes), it is fragmented in smaller units called tiles (see Figure 4). In ACK-on-Error, tiles have a fixed size, except for the last one, which can be smaller (see Section 4.2 for further details). Tiles are carried as the payload of data units called SCHC Fragments. Tiles are numbered using an identifier called Fragment Compressed Number (FCN). A special FCN value with all bits set to 1 indicates the last tile of the SCHC Packet. . SCHC Fragmentation process. The SCHC Packet is fragmented into tiles, which are numbered and grouped into windows. In this example, WINDOW_SIZE is equal to 7, and the FCN field has a size of 3 bits. The last FCN value, which corresponds to the last tile, has all bits set to 1 (i.e., the FCN is 7).
A group of WINDOW_SIZE tiles is called a window (see Figure 4). Each window required to transfer a SCHC Packet is sequentially numbered from 0 upwards. Tiles are numbered per window, sequentially, from WINDOW_SIZE-1 downwards. A specific combination of window number and FCN uniquely identifies each tile.
A SCHC ACK provides feedback to a fragment sender by means of an encapsulated bitmap. A bitmap is a sequence of bits, where each bit indicates whether a specific SCHC Fragment from a given window has been successfully received or not. The size of a bitmap is equal to WINDOW_SIZE. Bitmap bits are ordered from the most significant bit, corresponding to the tile with number WINDOW_SIZE-1, to the least significant bit, corresponding to tile 0 (for all windows except the last one) or the last fragment of the whole fragmented SCHC Packet (for the last window). If a bitmap bit is set to 1, it indicates successful reception of the corresponding SCHC Fragment, whereas value 0 indicates otherwise.

SCHC Messages
The SCHC over Sigfox specification adapts the message formats presented in the generic SCHC specification, which includes SCHC Fragments and SCHC ACK messages. The formats of these SCHC messages are shown in Figure 5. . SCHC Fragmentation process. The SCHC Packet is fragmented into tiles, which are numbered and grouped into windows. In this example, WINDOW_SIZE is equal to 7, and the FCN field has a size of 3 bits. The last FCN value, which corresponds to the last tile, has all bits set to 1 (i.e., the FCN is 7).
A group of WINDOW_SIZE tiles is called a window (see Figure 4). Each window required to transfer a SCHC Packet is sequentially numbered from 0 upwards. Tiles are numbered per window, sequentially, from WINDOW_SIZE-1 downwards. A specific combination of window number and FCN uniquely identifies each tile.
A SCHC ACK provides feedback to a fragment sender by means of an encapsulated bitmap. A bitmap is a sequence of bits, where each bit indicates whether a specific SCHC Fragment from a given window has been successfully received or not. The size of a bitmap is equal to WINDOW_SIZE. Bitmap bits are ordered from the most significant bit, corresponding to the tile with number WINDOW_SIZE-1, to the least significant bit, corresponding to tile 0 (for all windows except the last one) or the last fragment of the whole fragmented SCHC Packet (for the last window). If a bitmap bit is set to 1, it indicates successful reception of the corresponding SCHC Fragment, whereas value 0 indicates otherwise.

SCHC Messages
The SCHC over Sigfox specification adapts the message formats presented in the generic SCHC specification, which includes SCHC Fragments and SCHC ACK messages. The formats of these SCHC messages are shown in Figure 5.
A SCHC Fragment is composed of a SCHC Fragment Header and a payload. In SCHC over Sigfox, the payload carries exactly one tile, and the SCHC Fragment Header contains the window number (W) and the FCN for the tile carried by the SCHC Fragment. These fields are preceded by another field called the RuleID, which indicates the size of the SCHC Fragment Header for a given SCHC Packet transfer. There are two kinds of SCHC Fragments: (i) the Regular SCHC Fragments and (ii) the All-1 SCHC Fragments. Regular SCHC Fragments are used to carry any tile of a window, except for the last tile of the last window. The last tile of each window (except for the last window) is numbered with an FCN of 0, and it is carried by a so-called All-0 SCHC Fragment. The All-1 SCHC Fragment carries the last tile of the last window and signals the end of the SCHC Packet.  A SCHC Fragment is composed of a SCHC Fragment Header and a payload. In SCHC over Sigfox, the payload carries exactly one tile, and the SCHC Fragment Header contains the window number (W) and the FCN for the tile carried by the SCHC Fragment. These fields are preceded by another field called the RuleID, which indicates the size of the SCHC Fragment Header for a given SCHC Packet transfer. There are two kinds of SCHC Fragments: (i) the Regular SCHC Fragments and (ii) the All-1 SCHC Fragments. Regular SCHC Fragments are used to carry any tile of a window, except for the last tile of the last window. The last tile of each window (except for the last window) is numbered with an FCN of 0, and it is carried by a so-called All-0 SCHC Fragment. The All-1 SCHC Fragment carries the last tile of the last window and signals the end of the SCHC Packet.
The SCHC ACK message format has two parts: the SCHC ACK Header and the bitmap. The SCHC ACK Header comprises three fields: the RuleID, the window number (W), and an integrity check bit (C). The RuleID carries the same value as the SCHC Fragments for which receiver feedback is provided. The W field indicates the window number the SCHC ACK corresponds to. The C bit reports on the status of the received SCHC Packet. C = 1 indicates a successful SCHC Packet transfer, whereas C = 0 indicates otherwise. As an optimization, when C = 1, a bitmap is not included. If needed, padding is added to the SCHC ACK to align its size with the minimum data unit supported by the underlying L2. Figure 6 shows two SCHC Packet transfer examples, with and without SCHC Fragment losses. After receiving an All-0 SCHC Fragment, for the sake of efficiency, a SCHC ACK is only sent by the receiver if any SCHC Fragment from the corresponding window has been lost (see Figure 6b). A SCHC ACK is sent unconditionally at the end of the whole fragmented SCHC Packet transfer (i.e., after the All-1 SCHC Fragment). The SCHC ACK message format has two parts: the SCHC ACK Header and the bitmap. The SCHC ACK Header comprises three fields: the RuleID, the window number (W), and an integrity check bit (C). The RuleID carries the same value as the SCHC Fragments for which receiver feedback is provided. The W field indicates the window number the SCHC ACK corresponds to. The C bit reports on the status of the received SCHC Packet. C = 1 indicates a successful SCHC Packet transfer, whereas C = 0 indicates otherwise. As an optimization, when C = 1, a bitmap is not included. If needed, padding is added to the SCHC ACK to align its size with the minimum data unit supported by the underlying L2. Figure 6 shows two SCHC Packet transfer examples, with and without SCHC Fragment losses. After receiving an All-0 SCHC Fragment, for the sake of efficiency, a SCHC ACK is only sent by the receiver if any SCHC Fragment from the corresponding window has been lost (see Figure 6b). A SCHC ACK is sent unconditionally at the end of the whole fragmented SCHC Packet transfer (i.e., after the All-1 SCHC Fragment).

ACK-on-Error Configuration
To reliably transfer a SCHC Packet of a size up to 300 bytes, SCHC over Sigfox recommends the use of a single-byte SCHC Header. In that case, the SCHC Fragment header is composed of a 3-bit RuleID, a 2-bit W, a 3-bit FCN, and a fixed tile size (t) of 11 bytes. WINDOW_SIZE is 7.
For SCHC Packet sizes greater than 300 bytes, and up to 2250 bytes, SCHC over Sigfox recommends using a two-byte SCHC Header. In this case, the 16 SCHC Fragment header bits are distributed as follows: an 8-bit RuleID, a 3-bit W, a 5-bit FCN, and t equal to 10 bytes. In this case, WINDOW_SIZE is 31.

ACK-on-Error Configuration
To reliably transfer a SCHC Packet of a size up to 300 bytes, SCHC over Sigfox recommends the use of a single-byte SCHC Header. In that case, the SCHC Fragment header is composed of a 3-bit RuleID, a 2-bit W, a 3-bit FCN, and a fixed tile size (t) of 11 bytes. WINDOW_SIZE is 7.
For SCHC Packet sizes greater than 300 bytes, and up to 2250 bytes, SCHC over Sigfox recommends using a two-byte SCHC Header. In this case, the 16 SCHC Fragment header bits are distributed as follows: an 8-bit RuleID, a 3-bit W, a 5-bit FCN, and t equal to 10 bytes. In this case, WINDOW_SIZE is 31.

Modeling SCHC F/R over Sigfox Current Consumption
In this section, we present models of crucial energy performance parameters of SCHC F/R over Sigfox, such as device current consumption, device lifetime and energy cost. For the models, we assume a Sigfox device that sends SCHC Packets to the Sigfox network. Such behavior may correspond to an IoT device sending sensor readings.

Modeling SCHC F/R over Sigfox Current Consumption
In this section, we present models of crucial energy performance parameters of SCHC F/R over Sigfox, such as device current consumption, device lifetime and energy cost. For the models, we assume a Sigfox device that sends SCHC Packets to the Sigfox network. Such behavior may correspond to an IoT device sending sensor readings.
We first introduce the experimental setup used to perform current consumption measurements on a real device. Second, we identify the different states of a device that performs reliable SCHC Packet transfer by using ACK-on-Error over Sigfox, and we obtain their corresponding current and energy consumption profiles. Finally, we model the current and energy consumption of fragmented SCHC Packet transfers, considering single and periodic transfers. For the latter, we also model the lifetime of a battery-operated device.

Experimental Setup
Our models are derived from current consumption measurements on a real Sigfox device: a Pycom LoPy4 development board [27]. Figure 7 shows the experimental setup, which includes an Agilent N6750A power analyzer and the Sigfox device. The experiments were carried out in an indoor environment in the city of Castelldefels, in Spain. The Sigfox coverage in the scenario is near-ideal, with negligible frame loss rate.

Experimental Setup
Our models are derived from current consumption measurements on a real Sigfox device: a Pycom LoPy4 development board [27]. Figure 7 shows the experimental setup, which includes an Agilent N6750A power analyzer and the Sigfox device. The experiments were carried out in an indoor environment in the city of Castelldefels, in Spain. The Sigfox coverage in the scenario is near-ideal, with negligible frame loss rate. The LoPy4 module is based on the Espresiff ESP32 MCU. The latter includes a Wi-Fi and a Bluetooth interface, along with a Sigfox Semtech SX1276 radio module. Note that the LoPy4 module also has a built-in RGB LED. In our measurements, the LoPy4 board was programmed to enable the Sigfox radio interface and shut down other radio modules and peripherals (including the Wi-Fi and BLE interfaces and the RGB LED) on boot.
The LoPy4 has a voltage regulator, which supports input voltages between 3.5 V and 5.5 V. The output voltage of the regulator is 3.3 V. In all measurements performed, the supplied voltage is 3.5 V.
The Sigfox radio of the LoPy4 board is configured for RC1. Accordingly, the UL data rate is 100 bps, and the DL data rate is 600 bps. The transmit power is +14 dBm. The receiver sensitivity is −126 dBm.
The SCHC over Sigfox implementation used in our evaluation is based on the one presented in [15], which is publicly available.

SCHC Packet Transfer States
In order to comply with the duty cycle constraints in RC1, SCHC Fragments may be sent by using different approaches. In our model, we consider two possible options: (i) sending one SCHC Fragment per cycle of 10 min (and sleeping otherwise), and (ii) sending up to 6 SCHC Fragments back to back per cycle of 60 min (and sleeping otherwise). The LoPy4 module is based on the Espresiff ESP32 MCU. The latter includes a Wi-Fi and a Bluetooth interface, along with a Sigfox Semtech SX1276 radio module. Note that the LoPy4 module also has a built-in RGB LED. In our measurements, the LoPy4 board was programmed to enable the Sigfox radio interface and shut down other radio modules and peripherals (including the Wi-Fi and BLE interfaces and the RGB LED) on boot.
The LoPy4 has a voltage regulator, which supports input voltages between 3.5 V and 5.5 V. The output voltage of the regulator is 3.3 V. In all measurements performed, the supplied voltage is 3.5 V.
The Sigfox radio of the LoPy4 board is configured for RC1. Accordingly, the UL data rate is 100 bps, and the DL data rate is 600 bps. The transmit power is +14 dBm. The receiver sensitivity is −126 dBm.
The SCHC over Sigfox implementation used in our evaluation is based on the one presented in [15], which is publicly available.

SCHC Packet Transfer States
In order to comply with the duty cycle constraints in RC1, SCHC Fragments may be sent by using different approaches. In our model, we consider two possible options: (i) sending one SCHC Fragment per cycle of 10 min (and sleeping otherwise), and (ii) sending up to 6 SCHC Fragments back to back per cycle of 60 min (and sleeping otherwise).
Let N pC denote the number of SCHC Fragments that are sent back-to-back per cycle, where 1 ≤ N pC ≤ 6. Let N C denote the number of cycles required to complete a SCHC Packet transfer.
Each cycle comprises several states (see Figure 8). Initially, the device is sleeping (Sleep state), and then, the device wakes up (Wake-up state). If a new SCHC Packet needs to be sent, the device enters the Fragmenter state, where SCHC Packet fragmentation is performed. In this state, the device creates the SCHC Fragments from the SCHC Packet, which includes selecting the appropriate RuleID (according to the SCHC Packet size) and the corresponding FCN and W values for each SCHC Fragment.
After the Fragmenter state or after the Wake-up state if the device continues sending an already fragmented SCHC Packet, the device reaches the Frag Prep state, where it prepares the next SCHC Fragment to be sent and selects the Sigfox transmission procedure to be used for this SCHC Fragment. The prepared SCHC Fragment is then sent accordingly (the device is in the Sigfox transmission state). When more than one SCHC Fragment is sent per cycle N pC ≥ 2), the device enters the Inter Frag state to prepare the next SCHC Fragment to be transmitted or to process a SCHC ACK (when available).

Packet transfer.
Each cycle comprises several states (see Figure 8). Initially, the device is sleeping (Sleep state), and then, the device wakes up (Wake-up state). If a new SCHC Packet needs to be sent, the device enters the Fragmenter state, where SCHC Packet fragmentation is performed. In this state, the device creates the SCHC Fragments from the SCHC Packet, which includes selecting the appropriate RuleID (according to the SCHC Packet size) and the corresponding FCN and W values for each SCHC Fragment. After the Fragmenter state or after the Wake-up state if the device continues sending an already fragmented SCHC Packet, the device reaches the Frag Prep state, where it prepares the next SCHC Fragment to be sent and selects the Sigfox transmission procedure to be used for this SCHC Fragment. The prepared SCHC Fragment is then sent accordingly (the device is in the Sigfox transmission state). When more than one SCHC Fragment is sent per cycle 2), the device enters the Inter Frag state to prepare the next SCHC Fragment to be transmitted or to process a SCHC ACK (when available). Finally, after sending all the SCHC Fragments of a cycle, or after sending the last SCHC Fragment of a SCHC Packet, the device reaches the Post Frag state. In this state, the device processes a SCHC ACK (when available) and returns to the Sleep State. Sleep state time will depend on NpC. Next, we characterize the device current consumption in the states involved in each cycle.

Current Consumption Profile
In this section, we present the current consumption profile of all the states involved in a fragmented SCHC Packet transfer, which have been introduced in Section 5.2. These current consumption profiles are obtained by using the experimental setup shown in Section 5.1. All individual results provided correspond to the average of 10 individual experiments. For a given scenario and set of configuration parameters, we found negligible differences among the individual results obtained.

Sleep and Wake-up States Current Consumption Profile
Most Sigfox devices are battery-powered. Therefore, to improve battery lifetime, they must remain in Sleep state most of the time, and only wake up for communication. The LoPy4 supports two sleep modes: the light sleep mode and the deep sleep mode. In the light sleep mode, most peripherals and CPU are clock-gated, and voltage consumption is reduced, which allows for a reduced wake-up time. In the deep sleep mode, the CPU and Finally, after sending all the SCHC Fragments of a cycle, or after sending the last SCHC Fragment of a SCHC Packet, the device reaches the Post Frag state. In this state, the device processes a SCHC ACK (when available) and returns to the Sleep State. Sleep state time will depend on N pC . Next, we characterize the device current consumption in the states involved in each cycle.

Current Consumption Profile
In this section, we present the current consumption profile of all the states involved in a fragmented SCHC Packet transfer, which have been introduced in Section 5.2. These current consumption profiles are obtained by using the experimental setup shown in Section 5.1. All individual results provided correspond to the average of 10 individual experiments. For a given scenario and set of configuration parameters, we found negligible differences among the individual results obtained.

Sleep and Wake-Up States Current Consumption Profile
Most Sigfox devices are battery-powered. Therefore, to improve battery lifetime, they must remain in Sleep state most of the time, and only wake up for communication. The LoPy4 supports two sleep modes: the light sleep mode and the deep sleep mode. In the light sleep mode, most peripherals and CPU are clock-gated, and voltage consumption is reduced, which allows for a reduced wake-up time. In the deep sleep mode, the CPU and all peripherals are stopped, which reduces the current consumption to the minimum but increases wake-up time.
The Wake-up state current consumption and duration depends on the sleep mode used. Tables 1 and 2 present the Wake-up state duration and current consumption, and the Sleep state current consumption, for the light sleep mode and the deep sleep mode, respectively.
As shown in Tables 3 and 4, there is a large difference between Wake-up state and Sleep state time and current consumption for light and deep sleep modes. The light sleep mode has a shorter Wake-up state time but a greater sleep current. The corresponding average energy consumption is illustrated in Figure 9. For short sleep periods, light sleep is more efficient energywise, as the Wake-up state time is shorter. For long sleep intervals, deep sleep becomes more efficient, since the longer Wake-up state duration is compensated by the ultralow deep sleep current consumption in the Sleep state.  Tables 3 and 4, there is a large difference between Wake-up state and Sleep state time and current consumption for light and deep sleep modes. The light sleep mode has a shorter Wake-up state time but a greater sleep current. The corresponding average energy consumption is illustrated in Figure 9. For short sleep periods, light sleep is more efficient energywise, as the Wake-up state time is shorter. For long sleep intervals, deep sleep becomes more efficient, since the longer Wake-up state duration is compensated by the ultralow deep sleep current consumption in the Sleep state.   Table 5 presents the SCHC fragmentation states duration and their corresponding current consumption.  Table 5 presents the SCHC fragmentation states duration and their corresponding current consumption.

SCHC Fragmentation States Current Consumption Profile
In contrast with the durations of the Frag Prep, Inter Frag, and Post Frag states, which are constant, the Fragmenter state duration is proportional to the SCHC Packet size. Figure 10 illustrates the Fragmenter state duration, as a function of the SCHC Packet size, for SCHC Packet sizes between 1 and 2250 bytes. For small SCHC Packet sizes, the impact of the fragmentation process on time is negligible. However, as SCHC Packet size increases, the Fragmenter state duration becomes more significant (up to 3.54 s for a SCHC Packet size of 2250 bytes). Note that the Fragmenter state is only present once in each SCHC Packet transfer. are constant, the Fragmenter state duration is proportional to the SCHC Packet size. Figure 10 illustrates the Fragmenter state duration, as a function of the SCHC Packet size, for SCHC Packet sizes between 1 and 2250 bytes. For small SCHC Packet sizes, the impact of the fragmentation process on time is negligible. However, as SCHC Packet size increases, the Fragmenter state duration becomes more significant (up to 3.54 s for a SCHC Packet size of 2250 bytes). Note that the Fragmenter state is only present once in each SCHC Packet transfer.

U-Proc Current Consumption Profile
In the Frag Prep state or in the Inter Frag state, the following SCHC Fragment is prepared to be transmitted by using one of the two Sigfox procedures (i.e., U-Proc or B-Proc), depending on the SCHC Fragment type (i.e., Regular (not All-0), All-0 or All-1). If the SCHC Fragment is a Regular (not All-0) SCHC Fragment, the U-Proc is selected. Figure  11 shows the U-Proc current consumption profile, as measured on the LoPy4.

U-Proc Current Consumption Profile
In the Frag Prep state or in the Inter Frag state, the following SCHC Fragment is prepared to be transmitted by using one of the two Sigfox procedures (i.e., U-Proc or B-Proc), depending on the SCHC Fragment type (i.e., Regular (not All-0), All-0 or All-1). If the SCHC Fragment is a Regular (not All-0) SCHC Fragment, the U-Proc is selected. Figure 11 shows the U-Proc current consumption profile, as measured on the LoPy4. Figure 11. Current consumption profile of a LoPy4 device performing a measurement, the Sigfox UL frame payload size is 12 bytes, equivalent to a Regular ( Fragment carrying one tile.

Sensors 2022, 22, x FOR PEER REVIEW
The U-Proc comprises three substates: Transmission (Substate transmission (Substate 2), and Cooldown (Substate 3). Table 6 presents the current consumption of these substates along with their notations. Substat three times, as the UL frame is sent by using three different frequencies present twice, between two consecutive transmissions. After sending the Sigfox radio module enters Substate 3 before transiting to the Inter Frag or P or before handling other processes. Table 6. U-proc substates and their corresponding duration and current consumpt Figure 11. Current consumption profile of a LoPy4 device performing a U-Proc. In this measurement, the Sigfox UL frame payload size is 12 bytes, equivalent to a Regular (not All-0) SCHC Fragment carrying one tile.
The U-Proc comprises three substates: Transmission (Substate 1), Wait next transmission (Substate 2), and Cooldown (Substate 3). Table 6 presents the duration and current consumption of these substates along with their notations. Substate 1 is repeated three times, as the UL frame is sent by using three different frequencies. Substate 2 is present twice, between two consecutive transmissions. After sending the UL frame, the Sigfox radio module enters Substate 3 before transiting to the Inter Frag or Post Frag states, or before handling other processes. The transmission current measured value, denoted I Tx , is greater than the one presented in the LoPy4 datasheet [27], as it involves the MCU in addition to the Sigfox radio module, and the input voltage is different (our experiments are performed using 3.5 V, whereas datasheet values are provided for 5 V).
Let I U-Proc denote the average current consumption of a U-Proc. Using the notation of Table 6, I U-Proc can be calculated as follows: where T U-proc denotes the total U-Proc duration and can be calculated as follows:

B-Proc Current Consumption Profile
All-0 and All-1 SCHC Fragments need to open a DL reception window to offer the SCHC receiver the opportunity to transmit a SCHC ACK. To this end, the transmission of such fragments is performed by using a B-Proc. Figure 12 shows the B-Proc current consumption profile, as measured on the LoPy4 module. The B-Proc comprises six substates: Transmission (substate 1), Wait next transmission (substate 2), Wait for reception (substate 4), Reception (substate 5), Confirmation (substate 6), and Cooldown (substate 3). Table 7 presents the measured duration and current consumption for each substate of the B-Proc.
Sensors 2022, 22, x FOR PEER REVIEW Figure 12. Current consumption profile of a LoPy4 in a B-Proc, with an UL fram bytes, equivalent to an All-0 SCHC Fragment or an All-1 SCHC Fragment carryin frame is received by the device, which subsequently sends a confirmation control f Table 7. B-Proc substates and their corresponding duration and current consumpti Average Current A Figure 12. Current consumption profile of a LoPy4 in a B-Proc, with an UL frame payload of 12 bytes, equivalent to an All-0 SCHC Fragment or an All-1 SCHC Fragment carrying one tile. A DL frame is received by the device, which subsequently sends a confirmation control frame. In a similar way to a U-Proc, the UL frame in a B-Proc is transmitted by using 3 different frequency channels; therefore, substate 1 is present three times, and the substate 2 is present twice, between transmissions. After the third transmission for the UL frame, the Sigfox module waits for a fixed duration time interval in substate 4 and opens the reception window in substate 5. The duration of substate 5 depends on when the DL frame is received. After receiving the DL frame, the confirmation control frame is sent in substate 6. In substate 3, the device radio cools down before allowing the MCU to perform other operations. In case the Sigfox network and/or application does not send any DL frame to the device, or the device does not receive it, substate 6 is not present, and substate 5 duration is the maximum one (i.e., T RX MAX , which is equal to 25 s in RC1).
The average current consumption of a B-Proc when a DL frame is received by the device, denoted I B-Proc-DL , can be obtained as follows: where T B-Proc-DL can be calculated as follows: The average current consumption of a B-Proc when a DL frame is not received by the device, denoted I B-Proc-NO-DL , can be obtained as follows: where T B-Proc-NO-DL can be obtained as follows:

SCHC Packet Transfer Current and Energy Consumption Model
In this subsection, we model the SCHC Packet transfer current and energy consumption over Sigfox. To this end, we first calculate the number of U-Proc and B-Proc required to transfer a SCHC Packet. Then, we derive a current and energy consumption model of SCHC Packet transfer in two cases: (i) single and (ii) periodic SCHC Packet transfers.

Number of U-Proc and B-Proc
The number of U-Proc (N U-Proc ) required to transfer a SCHC Packet of size L SCHC can be obtained as follows: where L UL is the maximum Sigfox UL frame payload size of 12 bytes, and L Header is the size of the SCHC Fragment header. The number of B-Proc with a DL frame (N B-Proc-DL ) required to transfer a SCHC Packet without fragment losses is equal to 1. Under such conditions, the number of B-proc with no DL (N B-Proc-NO-DL ) can be obtained as follows:

Single SCHC Packet Transfer Model
The number of cycles required to transfer a single SCHC Packet (N C ) will depend on the fragment sending strategy, i.e., on the N pC value. Figure 13 illustrates the current consumption of (a) a 22-byte SCHC Packet transfer for N C = 1 and N pC = 2 and (b) the first transfer cycle of a 77-byte SCHC Packet for N C = 2 and N pC = 6. The figure shows that the number of Inter Frag states increases with N pC . model of SCHC Packet transfer in two cases: (i) single and (ii) periodic SCHC Packet transfers.

Number of U-Proc and B-Proc
The number of U-Proc (NU-Proc) required to transfer a SCHC Packet of size LSCHC can be obtained as follows: where LUL is the maximum Sigfox UL frame payload size of 12 bytes, and LHeader is the size of the SCHC Fragment header. The number of B-Proc with a DL frame (NB-Proc-DL) required to transfer a SCHC Packet without fragment losses is equal to 1. Under such conditions, the number of B-proc with no DL (NB-Proc-NO-DL) can be obtained as follows:

Single SCHC Packet Transfer Model
The number of cycles required to transfer a single SCHC Packet (NC) will depend on the fragment sending strategy, i.e., on the NpC value. Figure 13 illustrates the current consumption of (a) a 22-byte SCHC Packet transfer for NC = 1 and NpC = 2 and (b) the first transfer cycle of a 77-byte SCHC Packet for NC = 2 and NpC = 6. The figure shows that the number of Inter Frag states increases with NpC. Note that NC is related to the number of Wake-up and Frag Prep and Post Frag states required to complete the SCHC Packet transfer. By sending up to 6 SCHC Fragments backto-back (i.e., ≤ 6), the number of Wake-up, Frag Prep, and Post Frag states is minimized, when compared to = 1.
Once the sending strategy is selected, i.e., the NpC value is chosen, NC can be calculated as follows: Note that N C is related to the number of Wake-up and Frag Prep and Post Frag states required to complete the SCHC Packet transfer. By sending up to 6 SCHC Fragments back-to-back (i.e., N pC ≤ 6), the number of Wake-up, Frag Prep, and Post Frag states is minimized, when compared to N pC = 1.
Once the sending strategy is selected, i.e., the N pC value is chosen, N C can be calculated as follows: The number of Wake-up, Frag Prep, and Post Frag states (denoted N Wake-up , N Prep , and N Post ) is equal to N C , as each time the device transmits one or several back-to-back SCHC Fragments, it must wake up, prepare the next SCHC Fragment, and then do the SCHC Fragment post processing in the Post Frag state before returning to the Sleep state. We define the SCHC Packet active time (T act ) as the time the device is not in the Sleep state. T act can be obtained as follows: T act (s) = T Frag + N C * T wake-up + T Prep + T Post + T Inter * N pC − 1 + N U-Proc * T U-Proc + N B-Proc-NO-DL * T B-Proc-NO-DL +T B-Proc-DL .
The SCHC Packet active time current consumption (I act ) can be calculated as follows: I act (mA) = 1 T act (I Frag * T Frag + N C * I wake-up * T wake-up + I Prep * T Prep + I Post * T Post + I Inter * T Inter * N pC − 1 +N U-Proc * I U-Proc * T U-Proc + N B-Proc-NO-DL * I B-Proc-NO-DL * T B-Proc-NO-DL + I B-Proc-DL * T B-Proc-DL ) (11) As explained in Section 3.2, in RC1, a transmission procedure can only be started, at least, every 600 s, denoted T per Proc . Therefore, T act is only a small part of the total SCHC Packet transfer time (T SCHC ). The latter can be obtained as follows: Note that T SCHC is independent of N C , as the same total wait time has to be enforced, regardless of whether up to 6 messages are sent back-to-back per cycle (N pC ≤ 6) or one message is sent per cycle (N pC = 1). The differences in N C are reflected in T act . Therefore, the amount of time that the device is required to be in the Sleep state to comply with duty cycle restrictions for the transfer of a SCHC Packet, denoted T Sleep , can be calculated as follows: Finally, the average current consumption of a SCHC Packet transfer over Sigfox (I SCHC ) can be calculated as follows: In addition, the average energy consumed in a SCHC Packet transfer can be determined as follows: where V denotes the voltage supplied to the Sigfox device.

Periodic SCHC Packet Transfer Energy Performance Metrics
This subsection presents the metrics used to evaluate the energy performance of SCHC over Sigfox, for a device that transfers a SCHC Packet periodically. These metrics are (i) the average current consumption, (ii) the SCHC Packet transfer energy cost, and (iii) the device lifetime.
We assume that the device starts a SCHC Packet transfer (by sending the first fragment) every time period T p . Note that the minimum possible T p value, denoted T p_min , should be equal to T SCHC . After a SCHC Packet transfer, the device will wait in the Sleep state for T Wait until T p time has passed since the start of the previous SCHC Packet transfer. T p can be calculated as follows: During the wait period between SCHC Packet transfers, the device is in the Sleep state, consuming a current of I Sleep . Otherwise, the device transfers a SCHC Packet, with an average current consumption of I SCHC . In consequence, the average current consumption of periodic SCHC Packet transfers (I p ) can be obtained as follows: The energy consumed by a device performing periodic SCHC Packet transfers over an interval of duration T p can be obtained as follows: Sigfox devices are commonly battery-operated, and therefore, device lifetime calculation is crucial to the performance of SCHC Packet transfer over Sigfox. In order to calculate the device lifetime, the battery capacity must also be taken into consideration. Let C p denote the battery capacity (typically expressed in mAh). The device lifetime, LT, can be calculated as follows:

Evaluation
In this section, we evaluate energy-related performance parameters for single and periodic SCHC Packet transfers over Sigfox. First, we present the SCHC Packet current consumption and energy cost, for light and deep sleep modes, for different sending strategies. Then, we evaluate periodic SCHC Packet transfers, in terms of current consumption, energy cost and device lifetime. The energy consumed by a device performing periodic SCHC Packet transfers over an interval of duration Tp can be obtained as follows:

SCHC Packet Current and Energy Consumption
Sigfox devices are commonly battery-operated, and therefore, device lifetime calculation is crucial to the performance of SCHC Packet transfer over Sigfox. In order to calculate the device lifetime, the battery capacity must also be taken into consideration. Let Cp denote the battery capacity (typically expressed in mAh). The device lifetime, LT, can be calculated as follows: = . (19)

Evaluation
In this section, we evaluate energy-related performance parameters for single and periodic SCHC Packet transfers over Sigfox. First, we present the SCHC Packet current consumption and energy cost, for light and deep sleep modes, for different sending strategies. Then, we evaluate periodic SCHC Packet transfers, in terms of current consumption, energy cost and device lifetime.  Note that, for small SCHC Packet sizes, the sleep time versus active time ratio increases rapidly with SCHC Packet size. Such ratio is only 14 for an 11-byte SCHC Packet, while it increases to 52 for a 350-byte SCHC Packet. As the SCHC Packet size increases beyond 350 bytes, the same ratio tends asymptotically to a value of ~54. Therefore, ISCHC becomes stable between 1.36 mA and 1.32 mA, for the deep sleep mode, and equal to 3.44 mA for the light sleep mode. The ISCHC stepwise behavior that happens for small SCHC Packet sizes is due to each additional window needed to perform the SCHC Packet transfer (which increases current consumption due to the corresponding additional B-Proc). The larger step at a SCHC Packet size of 300 bytes is due to the change from a 1byte to a 2-byte SCHC header at that value. Note that, for small SCHC Packet sizes, the sleep time versus active time ratio increases rapidly with SCHC Packet size. Such ratio is only 14 for an 11-byte SCHC Packet, while it increases to 52 for a 350-byte SCHC Packet. As the SCHC Packet size increases beyond 350 bytes, the same ratio tends asymptotically to a value of~54. Therefore, I SCHC becomes stable between 1.36 mA and 1.32 mA, for the deep sleep mode, and equal to 3.44 mA for the light sleep mode. The I SCHC stepwise behavior that happens for small SCHC Packet sizes is due to each additional window needed to perform the SCHC Packet transfer (which increases current consumption due to the corresponding additional B-Proc). The larger step at a SCHC Packet size of 300 bytes is due to the change from a 1-byte to a 2-byte SCHC header at that value. Figure 15 illustrates the energy consumed by a device to perform a SCHC Packet transfer, for SCHC Packet sizes between 11 and 2250 bytes. The depicted values are obtained by using Equation (15). The energy consumption increases linearly with SCHC Packet size. Despite the fact that the average current consumption of a SCHC Packet transfer is relatively constant for SCHC Packet sizes beyond 350 bytes, the increase of SCHC Packet transfer duration with SCHC Packet size is reflected as a SCHC Packet transfer energy consumption increase. Figure 15 illustrates the energy consumed by a device to perform a SCHC Packet transfer, for SCHC Packet sizes between 11 and 2250 bytes. The depicted values are obtained by using Equation (15). The energy consumption increases linearly with SCHC Packet size. Despite the fact that the average current consumption of a SCHC Packet transfer is relatively constant for SCHC Packet sizes beyond 350 bytes, the increase of SCHC Packet transfer duration with SCHC Packet size is reflected as a SCHC Packet transfer energy consumption increase. Figure 15. Energy consumed by a device to perform a SCHC Packet transfer over Sigfox.  Table 8 also provides the Tp_min value for each SCHC Packet size, and the number of SCHC Packets per day that can be transferred with a SCHC Packet sending period equal to Tp_min. Table 8. SCHC Packet sizes used in the energy performance evaluation. Tp_min  77  6  0  1  1  70  20  154  12  1  1  2  140  10  275  21  3  1  4  250  5  510  49  1  1  2  510  2  2250  217  7  1  8  2250 0.64 * * Requires more than one day for a packet transfer. Figure 16 illustrates the average current consumption of a device that performs periodic SCHC Packet transfers, Ip, for different SCHC Packet sizes, NpC values of 1 and 6. We only consider the deep sleep mode, since it is more energy-efficient than the light sleep mode. The depicted values are obtained by using Equation (17). Note that all curves do not start at the same Tp value, since the minimum Tp (Tp_min) value is equal to TSCHC and depends on the SCHC Packet size (see Table 8). As Tp increases, Ip decreases for all SCHC Packet sizes, since Tsleep increases, reducing the average current consumption. As shown in Figure 16, for a given SCHC Packet size, NpC = 1 consumes a greater amount of current than NpC = 6, since with the latter, the number of Wake-up, Frag Prep, and Post Frag states (and thus, their contribution to current consumption) is minimized. As the SCHC Packet Figure 15. Energy consumed by a device to perform a SCHC Packet transfer over Sigfox. Table 8 presents the SCHC Packet sizes used for the periodic SCHC Packet transfer energy performance evaluation, along with the corresponding values of N U-Proc , N B-Proc-NO-DL , and the number of windows required for a single SCHC Packet transfer. The considered SCHC Packet sizes allow to test different values for N U-Proc , N B-Proc-NO-DL , and number of windows, for single-byte and two-byte SCHC header sizes. Moreover, Table 8 also provides the T p_min value for each SCHC Packet size, and the number of SCHC Packets per day that can be transferred with a SCHC Packet sending period equal to T p_min .  Figure 16 illustrates the average current consumption of a device that performs periodic SCHC Packet transfers, I p , for different SCHC Packet sizes, N pC values of 1 and 6. We only consider the deep sleep mode, since it is more energy-efficient than the light sleep mode. The depicted values are obtained by using Equation (17). Note that all curves do not start at the same T p value, since the minimum T p (T p_min ) value is equal to T SCHC and depends on the SCHC Packet size (see Table 8). As T p increases, I p decreases for all SCHC Packet sizes, since T sleep increases, reducing the average current consumption. As shown in Figure 16, for a given SCHC Packet size, N pC = 1 consumes a greater amount of current than N pC = 6, since with the latter, the number of Wake-up, Frag Prep, and Post Frag states (and thus, their contribution to current consumption) is minimized. As the SCHC Packet size increases, the average current consumption differences between the considered N pC values increase.  The depicted values are obtained by using Equation (18). This performance parameter increases linearly with Tp. This increase is small, since as Tp increases, the device remains in sleep mode for a greater amount of time, which increases energy consumption, albeit to a small extent. Finally, Figure 18 shows the results obtained by using Equation (19) regarding the lifetime of a device that performs periodic SCHC Packet transfers, for different SCHC Packet sizes, for NpC values of 1 and 6, and for the deep sleep mode. The battery capacity assumed in our calculation is of 2000 mAh. Recall that Tp min = TSCHC. Tp min ranges from 70 min for a 77-byte SCHC Packet to 2250 min for a 2250-byte SCHC Packet (see Table 8).  The depicted values are obtained by using Equation (18). This performance parameter increases linearly with T p . This increase is small, since as T p increases, the device remains in sleep mode for a greater amount of time, which increases energy consumption, albeit to a small extent.   The depicted values are obtained by using Equation (18). This performance parameter increases linearly with Tp. This increase is small, since as Tp increases, the device remains in sleep mode for a greater amount of time, which increases energy consumption, albeit to a small extent. Finally, Figure 18 shows the results obtained by using Equation (19) regarding the lifetime of a device that performs periodic SCHC Packet transfers, for different SCHC Packet sizes, for NpC values of 1 and 6, and for the deep sleep mode. The battery capacity assumed in our calculation is of 2000 mAh. Recall that Tp min = TSCHC. Tp min ranges from 70 min for a 77-byte SCHC Packet to 2250 min for a 2250-byte SCHC Packet (see Table 8). Finally, Figure 18 shows the results obtained by using Equation (19) regarding the lifetime of a device that performs periodic SCHC Packet transfers, for different SCHC Packet sizes, for N pC values of 1 and 6, and for the deep sleep mode. The battery capacity assumed in our calculation is of 2000 mAh. Recall that T p min = T SCHC . T p min ranges from 70 min for a 77-byte SCHC Packet to 2250 min for a 2250-byte SCHC Packet (see Table 8).

Periodic SCHC Packet Transfer Energy Performance
For the corresponding T p_min and N pC = 1, the device lifetime yields the smallest values, with a value of 42 days for a 77-byte SCHC Packet size, and 49 days for a 2250-byte SCHC Packet size. Note that there are large differences between the T p min value for specific SCHC Packet sizes, which in turn increase device lifetime, as the device spends more time in Sleep mode, and is involved in a lower number of Fragmenter states. Indeed, for a fixed T p value, as SCHC Packet size increases, more U-Proc and B-Proc are required, with the corresponding energy consumption increase and device lifetime decrease. For the corresponding Tp_min and NpC = 1, the device lifetime yields the smallest values, with a value of 42 days for a 77-byte SCHC Packet size, and 49 days for a 2250-byte SCHC Packet size. Note that there are large differences between the Tp min value for specific SCHC Packet sizes, which in turn increase device lifetime, as the device spends more time in Sleep mode, and is involved in a lower number of Fragmenter states. Indeed, for a fixed Tp value, as SCHC Packet size increases, more U-Proc and B-Proc are required, with the corresponding energy consumption increase and device lifetime decrease.
On the other hand, device lifetime increases asymptotically with Tp. For a Tp value of 5 days and for NpC = 6, and for a 77-byte SCHC Packet size, the device lifetime is 1464 days (i.e., more than 4 years). For the same Tp and NpC values, and for a 2250-byte SCHC Packet size, the device lifetime is 168 days.
The device lifetime differences for NpC = 1 and NpC = 6 decrease with SCHC Packet size, due to the consequent increase of sleep time during the SCHC Packet transfer, reducing the impact of the time spent in the Wake-up, Frag Prep, and Post Frag states. For the 77-byte SCHC Packet size, such difference ranges from 4 days (Tp_min = 70 min) to 42 days (Tp = 5 days), whereas for the 2250-byte SCHC Packet size, the differences range from 6 days (Tp_min = 2250 min) to 19 days (Tp = 5 days).

Conclusions
In this paper, we have presented a model and an evaluation of the device current and energy consumption of reliable packet fragmentation by using SCHC over Sigfox. We built our model by measuring the current consumption and duration of the states involved in a SCHC Packet transfer on a real Sigfox device.
The average current consumption of a single SCHC Packet transfer decreases as the SCHC Packet size increases since the device spends more time in the Sleep state, due to the need to conform to the RC1 duty cycle restrictions. For periodic SCHC Packet transfers, the average current consumption decreases with the SCHC Packet size and with the time between transfers. In contrast, the average energy consumption increases linearly with SCHC Packet size, due to the energy consumed while the device is in the Sleep state.
We analyzed two fragment transmission strategies, which are compliant with RC1 duty cycle restrictions: sending one or up to six back-to-back SCHC Fragments per cycle, respectively. The latter is more energy-efficient. In addition, we evaluated the light and deep sleep modes provided by the Sigfox device used.
Considering a 2000 mAh battery, and with only one SCHC Fragment sent per cycle, the minimum device lifetime (which corresponds to the smallest possible packet sending period) is 49 or 42 days, for SCHC Packet sizes of 2250 bytes or 77 bytes, with a period of On the other hand, device lifetime increases asymptotically with T p . For a T p value of 5 days and for N pC = 6, and for a 77-byte SCHC Packet size, the device lifetime is 1464 days (i.e., more than 4 years). For the same T p and N pC values, and for a 2250-byte SCHC Packet size, the device lifetime is 168 days.
The device lifetime differences for N pC = 1 and N pC = 6 decrease with SCHC Packet size, due to the consequent increase of sleep time during the SCHC Packet transfer, reducing the impact of the time spent in the Wake-up, Frag Prep, and Post Frag states. For the 77-byte SCHC Packet size, such difference ranges from 4 days (T p_min = 70 min) to 42 days (T p = 5 days), whereas for the 2250-byte SCHC Packet size, the differences range from 6 days (T p_min = 2250 min) to 19 days (T p = 5 days).

Conclusions
In this paper, we have presented a model and an evaluation of the device current and energy consumption of reliable packet fragmentation by using SCHC over Sigfox. We built our model by measuring the current consumption and duration of the states involved in a SCHC Packet transfer on a real Sigfox device.
The average current consumption of a single SCHC Packet transfer decreases as the SCHC Packet size increases since the device spends more time in the Sleep state, due to the need to conform to the RC1 duty cycle restrictions. For periodic SCHC Packet transfers, the average current consumption decreases with the SCHC Packet size and with the time between transfers. In contrast, the average energy consumption increases linearly with SCHC Packet size, due to the energy consumed while the device is in the Sleep state.
We analyzed two fragment transmission strategies, which are compliant with RC1 duty cycle restrictions: sending one or up to six back-to-back SCHC Fragments per cycle, respectively. The latter is more energy-efficient. In addition, we evaluated the light and deep sleep modes provided by the Sigfox device used.
Considering a 2000 mAh battery, and with only one SCHC Fragment sent per cycle, the minimum device lifetime (which corresponds to the smallest possible packet sending period) is 49 or 42 days, for SCHC Packet sizes of 2250 bytes or 77 bytes, with a period of 2250 min or 70 min, respectively. On the other hand, if SCHC Packets are sent every 5 days, and up to 6 SCHC Fragments are sent back-to-back per cycle, the device lifetime is 168 days or 1464 days, for SCHC Packet sizes of 2250 bytes or 77 bytes, respectively. The obtained results highlight that the SCHC Packet size, the packet sending period, and the number of SCHC Fragments per cycle have a significant impact on the device lifetime.
Funding: This work was supported in part by the Spanish Government through project TEC2016-79988-P funded by AEI/FSE/EU, and grant PID2019-106808RA-I00 funded by MCIN/AEI/10.13039/ 501100011033.