# SCHC over LoRaWAN, a Framework for Interoperable, Energy Efficient and Scalable Networks

Hussein Al Haj Hassan, Ali Krayem, Ivan Marino Martinez Bolivar, Laurent

Toutain, Alexander Pelov

► To cite this version:

Hussein Al Haj Hassan, Ali Krayem, Ivan Marino Martinez Bolivar, Laurent Toutain, Alexander Pelov. SCHC over LoRaWAN, a Framework for Interoperable, Energy Efficient and Scalable Networks. WF-IoT 2023: IEEE 9th World Forum on Internet of Things, IEEE, Oct 2023, Aveiro, Portugal. 10.1109/WF-IoT58464.2023.10539394. hal-04244739

HAL Id: hal-04244739

https://hal.science/hal-04244739v1

Submitted on 16 Oct 2023

HAL is a multi-disciplinary open access
archive for the deposit and dissemination of sci-
entific research documents, whether they are pub-
lished or not. The documents may come from
teaching and research institutions in France or
abroad, or from public or private research centers.

L'archive ouverte pluridisciplinaire HAL, est
destinée au dépôt et à la diffusion de documents
scientifiques de niveau recherche, publiés ou non,
émanant des établissements d'enseignement et de
recherche français ou étrangers, des laboratoires
publics ou privés.

<figure><img src="image_1.png" /></figure>

Distributed under a Creative Commons CC BY 4.0 - Attribution - International License
SCHC over LoRaWAN, a Framework for Interoperable,
Energy Efficient and Scalable Networks

Hussein Al Haj Hassan¹, Ali Krayem², Ivan Martinez³, Laurent Toutain⁴, Alexander Pelov¹

¹Acklio, 1137A Av. des Champs Blancs, 35510 Cesson-Sévigné, France

²American University of Science and Technology, Beirut, Lebanon

³NOKIA Bell Labs, Massy, France,

⁴IMT Atlantique, Rennes, France

Email: hussein.alhajhassan@ackl.io

*Abstract*—Low Power Wide Area Networks, or simply LPWANs, are expected to be among the main wireless technologies to connect the massive number of constrained devices with the Internet of Things. However, the limitation of the devices and the restrictive nature of LPWANs challenge the use of the Internet protocol, and thus sacrifice the network layer interoperability. To address this challenge, the IETF standardized Static Context Header compression and Fragmentation (SCHC) as an adaptation layer. SCHC compresses structured data, such as headers, and divides long messages over several fragments thus enabling IPv6 packets. In this paper, we evaluate the impact of using SCHC on the energy consumption of a LoRaWAN device and the capacity of a LoRaWAN network in terms of the number of served users. Results show that up to 81% of energy reduction can be achieved while increasing the capacity of the network more than 4 times.

*Index Terms*—LPWAN, LoRaWAN, Internet, SCHC, Energy efficiency,

I. INTRODUCTION

The Internet of things (IoT) is a new paradigm that is
shifting industries into smart and connected ones. Based on
Cisco [1], 500 billion devices are expected to be connected
to the Internet by 2030. Furthermore, it is forecasted that
the IoT industry will generate a revenue of USD 4.3 billion
by 2024 [2]. This is triggered by the evolution of many IoT
technologies such as LTE-M, NB-IoT, LoRaWAN, Sigfox and
others [3, 4].

Motivated by its low power consumption, wide coverage,
simplicity and ease of management due to its star topology,
LoRaWAN offers many advantages compared with other tech-
nologies. LoRaWAN is an open-source platform that enables
the deployment of both private and public networks [5]. This
leverages LoRaWAN as a strong candidate for diverse IoT
applications including but not limited to smart cities, smart
buildings, smart metering and intelligent agriculture.

Nevertheless, among the key challenges for LoRaWAN
technology are the packet size and the possibility to be
integrated within the IP world. For example, the smallest MTU
of LoRaWAN is 11 bytes in the US and 51 bytes in Europe
[6]. This puts restrictions on applications with large payloads.
Furthermore, protocols with huge header (e.g. IPv6 takes 40
bytes) would take a significant portion of the available MTU,
if it can be actually transfered.

To overcome these restrictions, The IPv6 over Low Power
Wide-Area Networks Working Group at the IETF has already
produced several documents as follows:

* RFC 8376 provides an overview of the baseline LPWAN technologies [7].

* RFC 8724 describes a Generic Framework for Static Con-text Header Compression and Fragmentation (SCHC), which provides header compression and three fragmen-tation mechanisms [8].

* RFC 9011 specifies the operation of SCHC over Lo-RaWAN networks [9].

* RFC 9391 specifies the operation of SCHC over NB-IoT networks [10].

In addition, the LoRa Alliance has adopted SCHC as
the adaptation layer for IPv6 [11]. With SCHC, LoRaWAN
devices can send IPv6 packets with sizes more than the
LoRaWAN MTU, thanks to its fragmentation mechanisms
that allow decomposing the message over several fragments.
Furthermore, SCHC's compression framework allows reducing
the packet header (and possibly payload) to avoid wasting the
bandwidth on static content, which is common in LPWANs
use cases.

There exist many studies that investigate and evaluate SCHC
performance. To the best of the author's knowledge, none
of the work have investigated the possible gains of SCHC
on the energy consumption of the device and the capacity
of the network, which we tackle in this paper. The paper is
organized as follows. Section II presents essential background
and existing work on SCHC over LoRaWAN. Section II
describes the energy model of LoRaWAN device with SCHC.
The gain of SCHC at the levels of device and network is
discussed and quantified in Section IV. Section V concludes
the paper.

II. BACKGROUND AND RELATED WORK

A. LoRaWAN

Long Range (LoRa) is a radio modulation that is based on
Chirp Spread Spectrum (CSS) [12, 13]. While LoRa defines
the physical layer, LoRaWAN defines the upper layer protocol.
This LPWAN technology is used for long range, low power
and low datarate applications [7]. The LoRa Alliance specifies
and maintain the LoRaWAN protocol.
<figure><img src="image_2.png" /><figcaption>Fig. 1. LoRaWAN Architecture [7].</figcaption></figure>

LoRaWAN networks follows a star topology as shown in Figure 1. Multiple gateways can receive an end-device transmissions, and relay it to a Network Server via standard IP connections. Although uplink communication, i.e. from an end-device to a Network Server, is expected to be the dominant, LoRaWAN allows bi-directional exchange of messages.

LoRaWAN distinguishes between a basic LoRaWAN (Class A) end-devices and optional devices with optional features (Class B, Class C) [14]:

* In Class A, an uplink transmission is followed by two short downlink receive windows. As such, downlink communications, i.e. from the network server to end-device, will have to wait an uplink communication initiated by the end-device.

* Class B end-devices allow more receiving slots. In addition to Class A receive windows, these end-devices open extra receive windows at scheduled times.

* Class C end-devices allow nearly continuously open receive windows, which are closed only when transmitting.

While Class A end-devices operation is the lowest power demanding, Class C end-devices use more power to operate than Class A or Class B end-devices. However, Class C end-devices experience the lowest latency. Refer to [14] for the full LoRaWAN L2 specifications.

As a companion to the LoRaWAN MAC Layer Protocol specification [14], the LoRaWAN Regional Parameters specification document [6] defines the adaptation of the LoRaWAN Link Layer to comply with the regulations enforced throughout the world on the use of various frequency bands of the unlicensed spectrum.

## B. SCHC over LoRaWAN

The general framework of SCHC is defined in [8], while the operation of SCHC over LoRaWAN is defined in [9]. In LoRaWAN, SCHC operates between two SCHC entities: 1) application layer of the end-device and 2) SCHC gateway (network side). Compression and fragmentation are applied by the sender, while decompression and applied by the receiving entity.

1. **Compression/decompression:** SCHC compression is based on using a set of rules that are defined in advance to communication. They describe the context to compress or decompress headers. Since the content of LPWAN packets is usually highly predictable, static contexts can be derived and stored. Indeed, the context must be stored ahead in both the sender (compressor) and receiver (decompressor). Note that the way context is provisioned and shared is not yet standardized.
Once the context is shared by the two sides of communication, the sender transmits a RuleID, which describes the rule used to compress the packet, followed by the compression residue, which consist of the reminder of bits after compression. Note that every rule contains a list of field Descriptors composed of a Field Identifier (FID), a Field Length (FL), a Field Position (FP), a Direction Indicator (DI), a Target Value (TV), a Matching Operator (MO), and a Compression/Decompression Action (CDA). At the other side of communication, the receiver uses the RuleID and residue to retrieve the original packet. For more information on SCHC compression, please refer to [8].

In LoRaWAN, SCHC compression uses RuleID of 1 byte. The RuleID is placed in the FPort field of LoRaWAN when fragmentation is not applied. Otherwise, it is placed in the beginning of first fragment [9].

2. **Fragmentation:** Three SCHC fragmentation modes are defined in [8], each with different reliability level and retransmission behavior:

* **No-ack:** The receiver does not provide any feedback to the sender, thus providing no reliability mechanisms.

* **Ack-Always:** The receiver provides the sender with feedback (positive or negative), thus providing high reliability at the cost of sending acknowledgments.

* **Ack-on-error:** The receiver provides the sender with feedback of only missing parts to be retransmitted.

In a SCHC fragmentation session, the packet is fragmented into pieces called tiles. A certain number of successive tiles are handled as a group, which is called a window. Each fragmentation mode defines the way tiles and windows are used. In SCHC over LoRaWAN, Ack-always is used for downlink unicast, Ack-on-error for uplink unicast and No-ack for downlink multicast. Please refer to [8, 9] for further details on the fragmentation parameters and specifications in LoRaWAN.

## C. Existing work on SCHC over LoRaWAN

Although standards of SCHC have been recently published [8, 9], several studies started to investigate its applications and performance. For example, SCHC is leveraged to enable autoconfiguring the LPWAN IoT devices to provide an interface with the internet in [15]. Two solutions for IPv6 configuration and Neighbor Discovery are proposed and evaluated. The work in [16] uses SCHC to enable IPv6 connectivity between a moving and an Internet node for vehicular IoT solution. In [17], the authors proposed a cloud-based virtual network operator architecture for multi-modal LPWANs and devices
leveraging SCHC. The study demonstrates that SCHC is a viable choice for achieving unified communication in the proposed architecture. In [18], a multimodal IoT network architecture is proposed to employ different wireless communications. In this context, SCHC is proposed to overcome the limitation of several technologies (Sigfox, LoRaWAN) in supporting IPv6. [19] presents a vehicular monitoring platform enabled by LoRaWAN and data compression by using SCHC. By testing the platform in a university campus, high level of reliability in the transmission link is shown, with packet delivery ratios over 95%. Based on SCHC, a solution to support roaming of devices during mobility between different LoRaWAN operators is proposed in [20]. The authors define a server to manage the context between operators. Results show that the proposed solution decreases the time delay to handle the transmitted messages before registration.

The above mentioned studies explore the usage and possible applications of SCHC. Other studies focus on tuning the parameters of SCHC and evaluating its performance. For example, the authors of [21] present an implementation and evaluation of SCHC. They found that SCHC is very effective when the network flows are known in advance. [22] addresses the SCHC standard and its performance in terms of latency and delivery ratio improvements and useful payload sent over fragment. The considered SCHC fragmentation reliability in this work is No-ACK, and thus reliability is based on re-transmissions of LoRaWAN L2 layer. As such, a re-evaluation is needed so that the results are consistent with the standard in [9]. In [23], the authors develop a mathematical model to compute the most critical performance parameters for SCHC ACK-on-Error mode. The model is used to tune the main parameters used over LoRaWAN and Sigfox. [24] proposes a dummy mapping technique to compress/decompress some header fields of unknown flows using SCHC. The impact of the dummy mapping size, the request arrival rate and the LPWAN link layer parameters on the compression are explored. [25] study the trade-offs of SCHC fragmentation/reassembly modes over LoRaWAN. Results show that No-ACK mode yields the lowest channel occupancy, highest goodput and lower total delay. However, it lacks reliability. ACK-Always and ACK-on-Error modes leads to the same total delay, and similar total channel occupancy, but ACK-on-Error offers greater goodput than Ack-Always.

[26] discusses several solutions in order to run IPv6 over IoT. The applicability over LoRaWAN, DASH7 and NB-IoT is investigated. The authors concluded that CoAP and SCHC provide the best approach for LPWANs technologies. In [27], the authors present SCHC as a proposed IPv6 adaptation layer for LPWANs. The efficiency of SCHC is presented by comparing the residue of compressing the IPv6 protocol in comparison with RoHC and 6LoWPAN. Similarly in [28], the authors shows through simulations with ns3 that SCHC protocol solution is better in term of header compression compared to 6LoWPA, as SCHC leads to lower header size. In [29], the authors study the benefits of using SCHC for multimodal LPWAN solutions. By comparing SCHC's overhead

and number of packet exchanges to achieve CoAP block-wise transfer and 6LoWPAN compression and fragmentation, the authors concluded that SCHC is the only protocol that is able to support end-to-end IPv6 connectivity for a multimodal device in LPWAN. Furthermore, the study also showed that SCHC has relative small footprint and is suitable for an embedded device as it requires low-memory needs. In [30], the authors shows that SCHC's compression and fragmentation mechanism can be used to enable interoperable and secure communication over constrained IoT networks such as sigfox, LoRaWAN and NB-IoT. While security based internet protocol adds relatively large over-head, SCHC compression is able to significantly reduce it. The study in [31] evaluated the effectiveness of SCHC in compression considering LWM2M for LoRaWAN devices. Results show that the compression can bring significant benefits with up to 75% compression ratio. A model for determining the efficiency of channel usage of SCHC on LoRaWAN is presented in [32]. Results showed that the efficiency decreases when the probability of error increases, and that there is no linear relationship between the spreading factor and efficiency. The end-to-end latency of IPv6 packets is evaluated for a real world deployment of SCHC in [33], where the authors evaluated Acklio's implementation for a class C LoRaWAN device and Acklio SCHC gateway (IP Core). Results showed a latency of less than 1 sec for small packets in uplink.

## D. Contribution

As presented above, existing studies showed that SCHC is the most efficient solution in providing IPv6 connectivity for LPWAN's device. SCHC compression provides the lowest compression residue, and its fragmentation is able to provide high reliability. Moreover, existing studies show that SCHC can be adopted for wide range of frameworks and applications. Nevertheless, the gain of using SCHC is not fully investigated. For example none of the studies investigated the impact of using SCHC on the energy consumption of a LoRaWAN device. Moreover, none of the studies explored the impact of using SCHC on the network's level such as capacity. In this paper, we aim at exploring possible gains of using SCHC on both the device and network level. At the level of device, we compute the gain of SCHC compression by calculating the overall energy consumption reduction for a real traffic pattern. At the level of the network, we study the percentage of packet delivery with respect to the number of devices. We then emphasize the gain in terms of capacity of a network with devices using SCHC compression.

## III. ENERGY MODEL OF LORAWAN DEVICE

Inspired by [34] and [35], we develop the energy model of the LoRaWAN device with SCHC implementation. Figure 2 presents the different states of the device. After waking-up, a device (sensor or meter) goes into the process of sensing/measuring. Then, the device processes the input signal before transferring it to transmission. Note that processing also includes SCHC compression and preparing the fragments
in case of fragmentation. After the wake-up of transmission chain, the device transmits the data and start preparing for receiving the data in case of downlink. If no more data (fragments) is to be sent, the device goes back into sleep mode. Otherwise, preparing the new fragment is required before the new transmission. Indeed, the device should wait certain time in idle state depending on the spectrum restriction (e.g. duty cycle). Based on the described model, the energy consumption of the device is as follows:

$$E_{TOT} = E_{SLP} + E_{SENS} + E_{PRO} + E_{TX} + E_{RX} + E_{IDLE}$$

where $E_{SLP}$ represents the energy consumption of the device during sleep mode. It depends on the duration the device is in sleep mode. $E_{SENS}$ represents the energy required by the device to wake-up from sleep and to sense. $E_{PRO}$ represents the energy consumed by the microcontroller unit (MCU). It includes the energy required by the device to process the measurement and perform the compression and fragmentation when SCHC is used. Note that the energy required for processing depends on the measured/sensed parameter(s), type of compression used (e.g. rules used to compress/decompress) the headers in case of SCHC and type of fragmentation and size of data (number of fragments). $E_{TX}$ is the energy needed to transmit the data. It includes energy needed for waking up and switching-off the transmission chain respectively. This value depends on several parameters such as the size of data to be sent, the transmitted power, regional parameters and the selected data rate. $E_{RX}$ is the energy needed to receive a frame. It includes the energy needed to turn-on and turn-off the receiving chain respectively. Indeed, the amount of energy depends on several factors such as the used receiving window (RX1 or RX2) and size of the frames. $E_{IDLE}$ is the energy consumed when the device is idle. This corresponds to the time between transmission of fragments. All of the above values of energy consumption are device dependent. For example, the frequency of the MCU affects the processing time and the power amplifier affects the consumed energy for a specific transmitted power. For more details on calculating the energy consumed by a LoRaWAN device refer to [34, 35].

## IV. SIMULATION AND RESULTS

For both device and network levels, we consider that SCHC compression and fragmentation is applied. While fragmentation profiles follow the profile defined in RFC 9011 [9], we consider three different compression profiles as shown in Figure 3 and Table I:

* UDP/IPv6 Compression: Compression of UDP/IP following the example of RFC 8724 [8] with perfect header compression.

* Comp.1: Includes UDP/IPv6 header compression plus Application-level header compression from structured application data from smart metering applications.

* Comp.2: Includes UDP/IPv6/Application header compression plus application payload compression from structured application data from smart metering applications.

<figure><img src="image_3.png" /><figcaption>Fig. 2. Device States.</figcaption></figure>

<figure><img src="image_4.png" /><figcaption>Fig. 3. Compression Types.</figcaption></figure>

In this work, we consider a real traffic for electricity meter. An example of the message sizes for different compression types/rules is summarized in Table I.

### A. Energy Gain of SCHC on the device level

At this level, we focus on energy consumption as the main parameter. This is because we study the device without taking into consideration the network conditions, which is considered in the following section.

The calculations consider Nucleo F070RB board with an SX1272 LoRa shield. The parameters used in calculation of energy are presented in Table II [34, 35]. To evaluate the gain of SCHC without the effect of network conditions, we consider that there is no loss of packets. This means that the transmitted packets does not suffer from collisions. We also consider that the downlink happens on RX1 (Reception window 1) and that each fragment is processed before sending. The device goes in sleep mode during idle time.

SCHC Compression leads to reducing the energy consumption as follows:

* Reduce the transmitted data and thus the time on air

<table><caption>TABLE I
TRAFFIC GENERATED BY EACH DEVICE.</caption><thead><tr><td>Compression type</td><td>No comp</td><td>UDP/IP Compression</td><td>Comp 1</td><td>Comp 2</td></tr></thead><tbody><tr><td>Message size</td><td>107</td><td>59</td><td>26</td><td>15</td></tr></tbody></table>

The size includes header and payload in bytes.
<table><caption>TABLE II
PARAMETERS USED FOR CALCULATION OF ENERGY CONSUMPTION.</caption><thead><tr><th>Parameter</th><th>Duration (ms)</th><th>Current (mA)</th></tr></thead><tbody><tr><td>Sensing</td><td>25</td><td>5.2</td></tr><tr><td>Processing</td><td>35</td><td>0.6</td></tr><tr><td>TX wake-up</td><td>1.722</td><td>2.268</td></tr><tr><td>TX switch-off</td><td>0.3</td><td>2.072</td></tr><tr><td>TX</td><td>varies</td><td>39.43 (14 dBm), 21.86 (3 dBm)</td></tr><tr><td>Sleep</td><td>varies</td><td>0.001</td></tr><tr><td>Idle</td><td>varies</td><td>0.0015</td></tr><tr><td>RX wake-up</td><td>9</td><td>1.996</td></tr><tr><td>RX switch-off</td><td>0.3</td><td>2.033</td></tr><tr><td>RX</td><td>varies</td><td>10.5</td></tr></tbody></table>

* The results of compression can fit the LoRaWAN payload and thus remove/reduce the need for fragmentation and its corresponding header. Note that when fragmentation is applied the device needs to enter different states before each transmission (wake up, tx wake up...)

* Reduce collision probability which leads to reducing re-transmissions. The impact of SCHC in collision is shown in the following section.

Figure 4 shows the energy reduction ratio for different compression types/rules with respect to no-compression case when the transmission power is 14 dBm. The figure shows that the energy reduction ranges between 30% and 81% depending on the radio conditions (considered datarate) and compression rule/type. Obviously, the compression rule that covers bigger part of the packet (and thus higher compression ratio) leads to higher energy reduction. The figure also shows that the highest gain is achieved when the lowest datarate is used. Based on the results, it is possible to extend the battery life up to 5 times when using SCHC compression.

To illustrate the impact of transmitted power, we present in Figure 5 the percentage of energy savings for different types of compression while considering two different transmitted power for the case highest spreading factor (i.e. SF12). The figure shows that using the simplest rule (UDP/IPv6 header only compression) will achieve significant energy savings (25%) even if the lowest transmitted power is used (3 dBm), which might not be applicable. Intuitively, increasing the transmit power will lead to higher energy consumption but also higher gain when SCHC is used.

## B. Network level

We consider a LoRaWAN network composed of a single gateway, a LoRaWAN network server and an application server. The gateway is serving a number of devices that are distributed randomly with a uniform distribution spreading factor amongst devices. We consider a simple propagation model between the gateway and the device as in [34]. We consider that the collision model takes into account the capture

<figure><img src="image_5.png" /><figcaption>Fig. 4. Percentage of energy reduction when using SCHC compression for different types of compression.</figcaption></figure>

<figure><img src="image_6.png" /><figcaption>Fig. 5. Impact of transmitted power on the energy reduction due to SCHC compression for different types of compression.</figcaption></figure>

effect [36]. When a packet is not received, this will be due to: i) collisions with other packets, ii) no more receiver paths, which is limited by the hardware of the receiver, iii) under sensitivity, i.e. the received power is less than the receiver's sensitivity and iv) out of coverage.

We differentiate between packet delivery and data delivery, where the former corresponds to the probability of successful reception of individual transmitted frames (fragments), while all fragments of the same message should be received in order to have successful data delivery.

We consider real traffic pattern corresponding to a real deployment of SCHC over LoRaWAN for electricity metering.
<figure><img src="image_7.png" /><figcaption>Fig. 6. Percentage of packet delivery with respect to the number of devices for different compression types.</figcaption></figure>

<figure><img src="image_8.png" /><figcaption>Fig. 7. Percentage of data delivery with respect to the number of devices for different compression types.</figcaption></figure>

where a packet is sent every 15 minutes. We use the model developed in [37] to simulate the network behavior in ns3. We consider a gateway with 8 channels. The gateway is covering a radius of 7 km. We consider that the network operates in the EU868 band as described in the LoRa Alliance regional parameters [6]. We simulate the network for different number of devices with same behavior. For fragments of the same message, the delay between fragments is calculated depending on the duty cycle. A random delay before transmission (up 1 sec) is considered to avoid all the devices sending at the same time. In order to achieve a confidence level of 99% percent, the number of iterations is selected.

Figure 6 presents the probability of packet delivery with respect to the number of devices in the network. The figure shows that using compression increases significantly the number of devices a gateway can serve. This is due to the fact that compression leads to lower message size and thus lower vulnerable time where collisions may occur. For example, if we consider 90% packet delivery, the number of devices that can be supported by the network is around 900 for both Comp. 1 and Comp. 2, while employing no compression limits it to less than 200 devices. This multiplies by more than 4 times the network capacity. The figure also shows that the packet delivery significantly increases for a specific number of devices. For example, if we consider 900 devices, no compression achieves 65% packet delivery. This percentage increases to 74% and 90% when using UDP/IP Compression and Comp. 1 respectively.

Figure 7 shows the percentage of data delivery with respect to the number of devices for different compression types. In data delivery, a successful transmission of a SCHC packet means that all fragments have been received.

By comparing Figure 7 and Figure 6, we see an important difference between data delivery and packet delivery for the no compression case. The difference is less important for UPD/IP compression and almost negligible for Comp. 1 and

Comp 2. The difference is due to the impact of compression in reducing the message size, and thus reducing the need for fragmentation (less number of fragments or even no fragmentation at all). For example, when UDP/IP compression is employed, the packet is compressed to 59 bytes, which still requires fragmentation in some spreading factors (e.g. SF 12) while Comp. 1 significantly reduces the size of the message.

## V. CONCLUSION

In this paper, we study the impact of using SCHC on a LoRaWAN device and a LoRaWAN Network. SCHC significantly reduces the packet size by compressing headers and structure data, which leads to much lower time-on-air for transmitting messages. On the level of device, this would reduce the energy consumption and thus extend the lifetime of a LoRaWAN device with battery unit. On the level of network, this leads to lower collision rate and thus larger number of served devices. Simulations showed that the energy consumption of the device can be reduced up to 81% while the capacity of the network can be increased more than 4 times.

## ACKNOWLEDGMENT

This research has been partially funded by French ANR project DiNS under contract ANR19-CE25-0009-01.

## REFERENCES

[1] Cisco, "Internet of Things at a Glance," https://www.cisco.com/c/en/us/products/collateral/se/internet-of-things/at-a-glance-c45-731471.pdf, 2008, [Online; accessed 10-January-2021].

[2] E. Berthelsen, "The global iot market opportunity will reach usd 4.3 trillion by 2024." https://machinaresearch.com/news/the-global-iot-market-opportunity-will-reach-usd43-trillion-by-2024/, 2015.

[3] L. Chettri and R. Bera, "A comprehensive survey on internet of things (iot) toward 5g wireless systems," IEEE Internet of Things Journal, vol. 7, no. 1, pp. 16-32, 2019.

[4] B. S. Chaudhari and M. Zennaro, LPWAN Technologies for IoT and M2M Applications. Academic Press, 2020.

[5] C. Milarokostas, D. Tsolkas, N. Passas, and L. Merakos, "A comprehensive study on lpwans with a focus on the potential of lora/lorawan systems," IEEE Communications Surveys & Tutorials, 2022.
[6] "LoRaWAN Regional Parameters," RP002-1.0.2, 2020.

[7] S. Farrell, "Low-Power Wide Area Network (LPWAN) Overview," RFC 8376, May 2018. [Online]. Available: https://www.rfc-editor.org/info/rfc8376

[8] C. G. D. B. J. Z. A. Minaburo, L. Toutain, "Schc: Generic framework for static context header compression and fragmentation," IETF, 2020.

[9] E. Gimenez, O. and E. I. Petrov, "Static context header compression and fragmentation (schc) over lorawan," IETF, 2021.

[10] E. Ramos and A. Minaburo, "Static Context Header Compression over Narrowband Internet of Things," RFC 9391, Apr. 2023. [Online]. Available: https://www.rfc-editor.org/info/rfc9391

[11] "LoRaWAN IPv6 Adaptation Layer Specification," TS010-1.0.0, May 2022.

[12] H. Mroue, A. Nasser, B. Parrein, S. Hamrioui, E. Mona-Cruz, and G. Rouyer, "Analytical and simulation study for lora modulation," in 2018 25th International conference on telecommunications (ICT). IEEE, 2018, pp. 655-659.

[13] M. Chiani and A. Elzanaty, "On the lora modulation for iot: Waveform properties and spectral analysis," IEEE Internet of Things Journal, vol. 6, no. 5, pp. 8463-8470, 2019.

[14] "LoRaWAN L2 1.0.4 Specification," TS001-1.0.4, 2020.

[15] B. Moons, E. De Poorter, and J. Hoebeke, "Device discovery and context registration in static context header compression networks," Information, vol. 12, no. 2, p. 83, 2021.

[16] R. Sanchez-Iborra, J. Sánchez-Gómez, J. Santa, P. J. Fernández, and A. F. Skarmeta, "IPv6 communications over lora for future iov services," in 2018 IEEE 4th World Forum on Internet of Things (WF-IoT). IEEE, 2018, pp. 92-97.

[17] J. Hoebeke, J. Haxhibeqiri, B. Moons, M. Van Eeghem, J. Rossey, A. Karagaac, and J. Famaey, "A cloud-based virtual network operator for managing multimodal lpwa networks and devices," in 2018 3rd Cloudification of the Internet of Things (CIoT). IEEE, 2018, pp. 1-8.

[18] J. Famaey, R. Berkvens, G. Ergeerts, E. De Poorter, F. Van den Abeele, T. Bolckmans, J. Hoebeke, and M. Weyn, "Flexible multimodal subgigahertz communication for heterogeneous internet of things applications," IEEE Communications Magazine, vol. 56, no. 7, pp. 146-153, 2018.

[19] J. Santa, R. Sanchez-Iborra, P. Rodriguez-Rey, L. Bernal-Escobedo, and A. F. Skarmeta, "Lpwan-based vehicular monitoring platform with a generic ip network interface," Sensors, vol. 19, no. 2, p. 264, 2019.

[20] W. Ayoub, M. Mroue, A. E. Samhat, F. Nouvel, and J.-C. Prévotet, "Schc-based solution for roaming in lorawan," in International Conference on Broadband and Wireless Computing, Communication and Applications. Springer, 2019, pp. 162-172.

[21] K. Q. Abdelfadeel, V. Cionca, and D. Pesch, "Lschc: Layered static context header compression for lpwans," in Proceedings of the 12th Workshop on Challenged Networks, 2017, pp. 13-18.

[22] J. Sanchez-Gomez, J. Gallego-Madrid, R. Sanchez-Iborra, J. Santa, and A. F. Skarmeta, "Impact of schc compression and fragmentation in lpwan: A case study with lorawan," Sensors, vol. 20, no. 1, p. 280, 2020.

[23] S. Aguilar, P. Maille, L. Toutain, C. Gomez, R. Vidal, N. Montavont, and G. Z. Papadopoulos, "Performance analysis and optimal tuning of ietf lpwan schc ack-on-error mode," IEEE Sensors Journal, vol. 20, no. 23, pp. 14534-14547, 2020.

[24] K. Q. Abdelfadeel, V. Cionca, and D. Pesch, "Dynamic context for static context header compression in lpwans," in 2018 14th International Conference on Distributed Computing in Sensor Systems (DCOSS). IEEE, 2018, pp. 35-42.

[25] S. Aguilar, A. Marquet, L. Toutain, C. Gomez, R. Vidal, N. Montavont, and G. Z. Papadopoulos, "Lorawan schc fragmentation demystified," in International Conference on Ad-Hoc Networks and Wireless. Springer, 2019, pp. 213-227.

[26] W. Ayoub, M. Mroue, F. Nouvel, A. E. Samhat, and J.-C. Prévotet, "Towards ip over lpwans technologies: Lorawan, dash7, nb-iot," in 2018 sixth international conference on digital information, networking, and wireless communications (dinwc). IEEE, 2018, pp. 43-47.

[27] C. Gomez, A. Minaburo, L. Toutain, D. Barthel, and J. C. Zuniga, "IPv6 over lpwans: Connecting low power wide area networks to the internet (of things)," IEEE Wireless Communications, vol. 27, no. 1, pp. 206-213, 2020.

[28] W. Ayoub, F. Nouvel, S. Hmede, A. E. Samhat, M. Mroue, and J.-C. Prévotet, "Implementation of schc in ns-3 and comparison with 6low-

pan," in 2019 26th International Conference on Telecommunications (ICT). IEEE, 2019, pp. 432-436.

[29] B. Moons, A. Karaagac, J. Haxhibeqiri, E. De Poorter, and J. Hoebeke, "Using schc for an optimized protocol stack in multimodal lpwan solutions," in 2019 IEEE 5th World Forum on Internet of Things (WF-IoT). IEEE, 2019, pp. 430-435.

[30] M. Dumay, D. Barthel, L. Toutain, and J. Lecoeuvre, "Effective interoperability and security support for constrained iot networks," in 2021 IEEE Global Communications Conference (GLOBECOM). IEEE, 2021, pp. 1-6.

[31] M. Pappalardo et al., "Device management at the network edge to support ros-aware iot services," 2023.

[32] R. Muñoz, J. Saez Hidalgo, F. Canales, D. Dujovne, and S. Céspedes, "Schc over lorawan efficiency: Evaluation and experimental performance of packet fragmentation," Sensors, vol. 22, no. 4, 2022. [Online]. Available: https://www.mdpi.com/1424-8220/22/4/1531

[33] E. Sisinni, D. Fernandes Carvalho, A. Depari, P. Bellagente, A. Flammini, M. Pasetti, S. Rinaldi, and P. Ferrari, "Assessing a methodology for evaluating the latency of ipv6 with schc compression in lorawan deployments," Sensors, vol. 23, no. 5, p. 2407, 2023.

[34] S. Maudet, G. Andrieux, R. Chevillon, and J.-F. Diouris, "Refined node energy consumption modeling in a lorawan network," Sensors, vol. 21, no. 19, p. 6398, 2021.

[35] T. Bouguera, J.-F. Diouris, J.-J. Chaillout, R. Jaouadi, and G. Andrieux, "Energy consumption model for sensor nodes based on lora and lorawan," Sensors, vol. 18, no. 7, p. 2104, 2018.

[36] M. Heusse, T. Attia, C. Caillouet, F. Rousseau, and A. Duda, "Capacity of a lorawan cell," in Proceedings of the 23rd International ACM Conference on Modeling, Analysis and Simulation of Wireless and Mobile Systems, 2020, pp. 131-140.

[37] M. Capuzzo, D. Magrin, and A. Zanella, "Confirmed traffic in lorawan: Pitfalls and countermeasures," in 2018 17th Annual Mediterranean Ad Hoc Networking Workshop (Med-Hoc-Net). IEEE, 2018, pp. 1-7.