Conference PaperPDF Available

Implementation of SCHC in NS-3 Simulator and Comparison with 6LoWPAN

Authors:

Abstract and Figures

The rapid growth of IoT applications usage enables the Internet connectivity of a massive number of devices using different technologies. Most of these technologies, such as Low Power Wide Area Networks (LPWANs), are non-IP due to the difficulties of using IP on constrained devices. These nodes are characterized by more constraints with respect to other IoT technologies. According to [1], IPv6 offers many benefits for IoT, which motivated the IETF to form a Working Group (WG) to study and propose new solutions to run IPv6 on the new technologies of IoT [2], [3]. The key to solving this issue is header compression mechanisms. In this paper, we analyze the two IETF standardized solutions, SCHC and 6LoWPAN, to compress IPv6 over constrained nodes within LPWAN. Based on [3], we implement the SCHC mechanism [4] in the network simulator NS3 [5]. We also show that SCHC protocol solution as an adaptation layer between the network layer and the link layer is better in term of header compression by providing a smaller header size compared to 6LoWPAN.
Content may be subject to copyright.
HAL Id: hal-02051757
https://hal.archives-ouvertes.fr/hal-02051757
Submitted on 28 Feb 2019
HAL is a multi-disciplinary open access
archive for the deposit and dissemination of sci-
entic 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 diusion de documents
scientiques 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.
Implementation of SCHC in NS-3 Simulator and
Comparison with 6LoWPAN
Wael Ayoub, Fabienne Nouvel, Sarah Hmede, Abed Samhat, Mohamad
Mroue, Jean-Christophe Prévotet
To cite this version:
Wael Ayoub, Fabienne Nouvel, Sarah Hmede, Abed Samhat, Mohamad Mroue, et al.. Implementa-
tion of SCHC in NS-3 Simulator and Comparison with 6LoWPAN. 26th International Conference on
Telecommunications (ICT), Apr 2019, HA NOI, France. <hal-02051757>
Implementation of SCHC in NS-3 Simulator and Comparison with
6LoWPAN
Wael Ayoub∗†, Fabienne Nouvel, Sarah Hmede, Abed Ellatif Samhat, Mohamad Mroue
and Jean-christophe Pr´
evotet
Institut National des Sciences Appliqu´
ees de Rennes — IETR-INSA, Rennes, France.
Faculty of Engineering - CRSI, Lebanese University, Hadath Campus, Hadath, Lebanon
Email: firstname.lastname@insa-rennes.fr
Email: samhat@ul.edu.lb, mohamad.mroue@ul.edu.lb, sarah.hmede@outlook.com
Abstract—The rapid growth of IoT applications usage enables
the Internet connectivity of a massive number of devices using
different technologies. Most of these technologies, such as Low
Power Wide Area Networks (LPWANs), are non-IP due to the
difficulties of using IP on constrained devices. These nodes are
characterized by more constraints with respect to other IoT
technologies. According to [1], IPv6 offers many benefits for
IoT, which motivated the IETF to form a Working Group (WG)
to study and propose new solutions to run IPv6 on the new
technologies of IoT [2], [3]. The key to solving this issue is
the header compression mechanisms. In this paper, we analyze
the two IETF standardized solutions, SCHC and 6LoWPAN, to
compress IPv6 over constrained nodes within LPWAN. Based
on [3], we implement the SCHC mechanism [4] in the network
simulator NS3 [5]. We also show that SCHC protocol solution as
an adaptation layer between the network layer and the link layer
is better in term of header compression by providing a smaller
header size compared to 6LoWPAN.
Index Terms—IoT communication, LPWAN, IPv6, SCHC,
6LoWPAN, NS3, Long-Range, and Header Compression.
I. INTRODUCTION
In recent years, the Internet of Things (IoT) has attracted the
attention of industry and researchers. Arm declared in [6], [7]
that 100 billion chips had been shipped over 26 years between
1991 and 2017 to support connected devices, whereas the
same quantity has been shipped since 2017. To respond to the
exponential growth in the number of connected objects in the
coming years, creating a reliable and efficient network infras-
tructure is essential. Apart from exceptional cases, connected
objects transmit only a few data for long distances. In most
applications, there is a real need for autonomy and a lifespan
of several years. Existing networks, such as WIFI, Bluetooth,
cellular networks, etc., do not respond to this need. That led to
the emergence of new IoT communication networks developed
to adapt to these requirements known as LPWANs.
The emerging of LPWANs has received considerable at-
tention from the research community and industry. LPWANs
studies and developments have obtained momentum in many
domains such as smart city, traffic control, health care,
water/energy/waste management, agriculture, etc. This over-
growth led to the presence of heterogeneous architectures,
standards, middlewares, and a diversity of applications. Cur-
rently and for future, LPWAN technologies are required to
provide scalability, stability, and on wide areas, for End-
Devices (ED). Furthermore, this heterogeneity is an obstruc-
tion for industry and developments, that usually seek a homo-
geneous solution to support the diversity of technologies to
gain marketing and other purposes. Such technologies include
LoRaWAN, Sigfox, DASH7, etc.
Previously, heterogeneity of technologies was solved in sev-
eral ways. One of the most common solutions that researchers
adopted was to create a middleware that can be adapted and
be common between the different technologies. However, with
the presence of new types of technologies, i.e., LPWAN, these
middlewares are no more applicable and require a significant
update. The objective is to create a common solution for het-
erogeneity that can be easily adapted to any new technology.
In [1], authors show that IPv6 offers several features that make
it a successful solution for IoT developments. IPv6 provides
scalability, security, stateless address auto-configuration, and
a set of complementary solutions for the loT needs: e.g.,
6LoWPAN, 6TiSCH, etc. Furthermore, IPv6 may be a solution
for heterogeneity, and it supports mobility.
However, IPv6 solutions must consider the LPWANs con-
straints and challenges. These challenges can be summarized
as follows:
Large-scale constrained networks including a massive
number of ED.
Payload size support in the physical frame as low as 12
bytes, i.e., SigFox.
Limited rate of frames on air per data.
Low data rate and small bandwidth up to 250 kbps.
Frame loss increases as the number of ED increases.
Do not support fragmentation in case of large frames.
Power consumption and radio constraints
Among these complementary solutions that IPv6 provides, we
investigate in this paper two IPv6 mechanisms that consider
the LPWANs constraints: IPv6 over Low-Power Wireless
Personal Area Networks (6LoWPAN) [8] and Static Context
Header Compression (SCHC) [1]. These two solutions, stan-
dardized by IETF, are used to extend the protocol stack of
LPWAN technology with an adaptation layer. This layer con-
verges from non-IP to IPv6-based technology which enables
homogeneous access for applications and services. Based on
this study, we propose to use the SCHC protocol solution as an
adaptation layer between the network layer and the link layer
for the LPWAN technologies to reduce IPv6 header size.
This paper is structured as follows: In section II we illustrate
related work. In Section III, we present the SCHC mechanism,
explain the terms and fields followed by a brief, concen-
trated description of the header compression in 6LoWPAN.
In Section IV, we illustrate the implementation procedure of
the SCHC mechanism on the NS3 and explain the compres-
sion/decompression structure of the algorithm. In Section V,
we draw a scenario to compare between SCHC and 6LoWPAN
on NS3. Finally, Section VI provides a summary of the two
mechanisms and the requirements considered in SCHC with
the future work.
II. RE LATE D WO RK
A lot of studies have been carried out to compare the two
solutions, but to our best knowledge, they do not propose a
real implementation to compare them. In [9], authors propose
LSCHC mechanism based on SCHC standard for compress-
ing of IPv6. Also, authors address the memory constraint
generated by SCHC mechanism and propose the LSCHC
as a solution. The proposed mechanism solves the memory
constraint of the device but adds constraints on the radio
communication which is against the main goals of SCHC.
In [10], and [11], authors benefit from the use of 6LoWPAN
mechanism in compressing IPv6 for LoRaWAN technology
[12]. Moreover, in [13] authors propose Co-iOAM mechanism
for compression based on 6LoWPAN. In [14], authors com-
pare the 6LoWPAN with LPWANs layer by layer. A similar
comparison on the use of 6LoWPAN will be given in section
V. In [15], an adaptation layer is proposed based on the SCHC
mechanism for compression and decompression. This solution
deals with vehicular communication and moving devices. But
SCHC mechanism is developed for the static device, so update
and improvements on this mechanism are required to support
mobility.
III. HEA DE R COMPRESSION MECHANISMS
A. SCHC
The IETF has established an LPWAN WG to explore
a solution that adopts IPv6 over constrained networks in
LPWANs. The proposed solution is based on two conditions:
Solution for star topology networks that are characterized
by small bandwidth and low power, and support for
fragmentation.
Static predetermined flow of data.
This WG has proposed the Static Context Header Compression
(SCHC) [3] mechanism as a header compression scheme
that compresses IPv6 header into less than 1 byte. However,
and like its predecessor 6LoWPAN, SCHC is currently being
updated to cover the IPv6/UDP/CoAP (Constrained Applica-
tion Protocol) headers and to be adapted to other LPWANs
technologies. SCHC compression mechanism considers static
devices with predetermined context saved on the device and
server memory. This context does not change during packet
transmission. SCHC avoids the complexity of synchronization
mechanisms. These mechanisms are not required when dealing
with LPWANs. Moreover, SCHC is an adaptation layer that is
placed between the network and data link layer as 6LoWPAN.
SCHC compresses the IPv6/UDP/CoAP headers into ruleID
and sends the data to lower layers for transmission.
Fig. 1. SCHC Architecture.
The context saved on device and server consists of rules as
shown in Fig. 1. Each rule consists of several fields. Each field
corresponds to a parameter from the header. A rule holds the
information of the header. The ruleID is formed by:
Field ID (FID): A unique value used to represent the
header field.
Field Length (FL): Used to specify the header segment
length.
Field Position (FP): In case the field is an array, field
position is used to select a definite item in the array.
Direction Indicator (DI): Used to specify the direction of
the packet, whether uplink (Up); data are from device to
server, downlink (Dw); data are from the server to device,
or Bidirectional (Bi).
Target Value (TV): This field contains the value that ED
received to compare with the saved value.
Matching Operator (MO): This operator is applied in
comparing received TV with saved one.
Compression Decompression Action (CDA): It describes
the method used beside each field to compress and
decompress the TV.
B. 6LoWPAN
IPv6 over Low-Power Wireless Personal Area Networks
6LoWPAN [16] offers a lot of advantages for low power
wireless sensor networks and other forms of low power
wireless networks like LPWANs. In late 2004, 6LoWPAN WG
formed by the Internet Engineering Task Force, IETF [17]
to enable IPv6 over IEEE802.15.4 networks. The mission of
the 6LoWPAN WG was to build an adaptation layer under
the IPv6 protocol on the network layer and above the IEEE
802.15.4. This open standard was aimed to run for low power
wireless system that operates at the 2.4 GHz frequencies,
but now it is adapted and updated to run with many other
wireless technologies such as Bluetooth, Power Line Com-
munication, LoRaWAN, etc. In the 6LoWPAN standard, the
WG defined the compression/decompression mechanisms and
encapsulation/fragmentation that enable running IPv6 packet
data on constrained wireless networks. Currently, 6LoWPAN
is an adaptation layer that allows IPv6 packets to be carried
efficiently within small link layer frames. Moreover, this
adaptation layer defines one reduced header format for IPv6
and one reduced format for UDP packet headers. Today,
6LoWPAN is one of the most important technologies for
the integration of IPv6 in smart objects based on Wireless
Sensor Networks with low power, limited bandwidth, and
reduced memory capabilities. Furthermore, the 6LoWPAN
bridge translates the 6LoWPAN header of the packets received
via the WPAN interface to the IPv6/UDP headers. These
packets are transmitted through the MAC/PHY interface, and
vice versa, transparently.
Fig. 2. 6LoWPAN Communication Scenarios.
Fig. 2 shows three communication scenarios for 6LoWPAN:
In scenario 1, communication is within the 6LoWPAN
network between two devices. In this case, the devices
use the link-local addresses. 6LoWPAN can compress the
IPv6 header down to 2 bytes.
In scenario 2, communication is with a device outside
the 6LoWPAN network, but the prefix of the external
network is known. In this case, 6LoWPAN can compress
the IPv6 header down to 12 bytes.
In scenario 3, communication is similar to 2, but the
prefix of the external network is unknown. In this case,
6LoWPAN compresses the IPv6 header down to 20 bytes.
IV. IMPLEMENTATION OF SCHC MODULE
In order to compare the two mechanisms, SCHC and
6LoWPAN, we used Network Simulator 3 (NS3) [5]. NS3
is free popular software for discrete event simulation. The
6LoWPAN mechanism was already implemented on NS3 but
SCHC still not available. Based on [3], we created the SCHC
module [4] that implements the functions of compression and
decompression. Then, this module was integrated and tested
in NS3. In the following, we provide a brief description of the
compression and decompression mechanisms on SCHC. The
implementation, structure, and installation of the module on
NS3 can be found in [4].
Fig. 3. SCHC Module Structure.
The implementation of the SCHC algorithm on NS3 was
done using the C++ language. This choice was motivated
by the fact that a C++ compiler is usually present on most
available hardware platforms. SCHC has been structured and
implemented in several files found under the SCHC module
folder as shown in Fig. 3. A new module named SCHC was
created to model the behavior of the SCHC protocol. This
module is essentially a collection of classes that work together
to describe the compression and decompression functions used
in SCHC. The set of classes and files needed to simulate a
network formed by devices that use SCHC as an adaptation
layer are described in the following.
Fig. 4. Protocol Stack Installed in NetDevice.
A. helper
The helper file contains the SCHC-helper class that installs
an SCHC adaptation layer between IPV6 and L2 layer (Data
link layer). Furthermore, the SCHC-helper class was used to
install a protocol stack that contains the SCHC protocol on
the NetDevice as shown in Fig. 4.
B. Model
1) SCHC-rule: It specifies the rules contained in the SCHC
context that defines the structure of the algorithm of the
SCHC protocol. A rule will be of type structure formed by
a ruleID and an array of type SCHC Rule field (rule field)
containing the description of the different fields that make up
an IPV6/UDP packet as shown in Fig. 5. The ruleID is a binary
value and consists of a series of zeros and ones.
Fig. 5. SCHC Rule Structure.
2) Compression mechanism: The compression mechanism
compresses the headers of the packet received from the net-
work layer using the CompressSCHC function. This function
follows the flowchart structure represented in Fig. 6. Before
starting the SCHC compression algorithm, separation for the
IP and the UDP headers from the payload is done. The goal
of the compression is to find a ruleID, represented by a few
bits, to identify the contexts of the fields in the packet header
UDP/IP. To select a ruleID, the packet header fields will be
matched with the saved context in memory. The best ruleID
that matches the context of the packet header will be selected.
Then this ruleID is used to compress the packet header. As
shown in Fig. 6, the SCHC compression starts by loading all
the rules saved in memory in a ”for loop. The algorithm
iterates the rules one by one and checks for each iteration
if all the fields of the rule, are in agreement with the IP
and UDP header fields. In case of a mismatch, the algorithm
goes to the next rule. Then, the algorithm loads the fields
of each rule in a ”for loop.” In a first step, the algorithm
chooses the field description based on its direction, based on
the direction indicator (DI) parameter. Any field description
with no proper DI will be ignored, and the algorithm will
check the next field. The rule will be ignored if all the packet
fields do not have an appropriate field description with the
required DI. Then, the following rule will be checked. With
the successful match of DI, the algorithm recognizes the fields
regarding their Field Position (FP). The rule will be discarded
if the FP does not match. After successful matches of DI and
FP with the packet header context, the algorithm starts by
comparing each field of the packet header (example: as shown
in Fig. 2 of the IPv6) with the Target Value (TV) saved on the
rule. This comparison between received TV and saved one is
based on the rules specified by the received Matching Operator
(MO) as shown in Table I. After matching all the fields and
the packet header with the selected rule, the compression
starts based on the actions of the rule.After that, a new ”for
loop” is created to compress the packet header values. The
compression mechanism is performed by applying, for each
field, the compression action corresponding to the rule. Once
the compression operations are done, the algorithm returns the
ruleID. In case of more than one rule matches, the rule that
provides better header compression will be selected. If no rule
matches, the headers will be sent uncompressed in the field
specified by SCHC for transmitted headers. Depending on the
L2 layer of the technology and allowed frame size, SCHC
decides whether to fragment the packet or not.
3) Decompression mechanism: On the network side, de-
compression mechanism is different from the that on Device.
The network side holds rules that correspond to several
devices. A compressed packet received on the network side
needs the device address and ruleID. The SCHC decompres-
sor loads the ruleIDs corresponding to this device. These
ruleIDs are available in the database of the network under
the device identity. Otherwise, on the device side, only the
ruleID is needed, since each device holds its own rules.
The decompression algorithm is implemented in the schc-
net-device.cc file following the structure is shown in Fig.
6. In decompression, the input is the context containing the
”compression header” and the ”ruleID.” The method returns a
Boolean value, which will be true when the package has been
properly uncompressed, or false if an error has occurred. First,
the algorithm starts by separating the SCHC headers from the
payload and makes the first check to determine if the rule is
present in the context. Then, it starts the process of rebuilding
the original package. At this stage, the algorithm begins to
analyze all the fields described in the rule, check the direction
of the communication flow, apply CDA method to decompress
the value, and rebuild all the fields to obtain the IP/UDP packet
headers.
V. SIMULATION RESULTS
To evaluate the performance of the SCHC protocol, we
performed three simulation scenarios as shown in Fig. 7.
In the three scenarios, we sent a ping from the device to
server passing by the gateway. In scenario A, packets trans-
mitted without compression. In scenario B, packet headers
are compressed using 6LoWPAN compression. In scenario C,
the headers are compressed using the SCHC compression. In
SCHC, we consider the ruleID with the compression headers
space together as a header. The SCHC context header was
composed of a ruleID formed of 3 bits, and n bytes for the
header compress. Table II shows the compression gain in case
of normal transmission and when compressing the headers
Fig. 6. SCHC Algorithm Structure for Compression and Decompression.
using 6LoWPAN and SCHC. This table shows that SCHC
can reach a compression factor of 0.9 compared to 0.43 for
6LoWPAN. The compression ratio is calculated as follows:
C=Lorignal Lcompressed
Lorignal
%(1)
where C is the compression ratio, Lorignal represents the
packet header length, and Lcompressed is the header compres-
sion length.
In term of header compression, SCHC device starts by
sending a map for the UDP/IPv6 headers used by the server.
Consider the scenario where the ruleID was ”001” (3bits), and
the compression header fields contain the UDP/IPv6 header
values as shown in Table I. The first transmitting packet header
was 5 bytes, and all the following packets headers were only 3
bits as ruleID and 5 bits for padding. As shown in Table I, most
of the fields are known to the server. So device rule configura-
tion does not need to be sent.The only sent fields are the UDP
source and destination ports which are equal to 4 bytes. The 5
bytes header is composed of 3 bits for ruleID, 4 bytes data in
the ”compression headers” and 5 bits of padding. In the case
of mobility, SCHC mechanism does not support mobility and
only considers static devices. In the case of network topology,
SCHC only deals with star networks which make it successful
for LPWANs technologies but not for mesh IoT technologies
such as Zigbee, etc. SCHC has been a solution to IoT networks
with radio constraints, but as headers increase, the amount of
data saved in memory increases and the searching time for
the applicable rule will also increase. This requires better data
management mechanism and searching algorithm to manage
the stored data between device and server. In summary, SCHC
is a trade-off between radio constraints, memory usage, and
processing time.
Consider a static device communicating with a server. All
data transmitted from the device to server holds the same
header. Even with the use of header compression, we will show
Fig. 7. Testing Scenarios on NS3.
TABLE I
RUL E SENT
Rule 1
Field FP FL DL TV MO C/D
IPv6 Header Fields
Version 1 4 bi 6 equal not-sent
Traffic
Class 1 8 bi 0x00 equal not-sent
Flow
Label 1 20 bi 0x000000 ignore not-sent
Payload
Length 1 16 bi None ignore Compute-
Length
Next
Header 1 8 bi 17 equal not-sent
Hop
Limit 1 1 bi 30 ignore not-sent
Prefix
Source id 1 64 bi 2001:63:
80:8 equal not-sent
Source id 1 64 bi ::2 equal not-sent
Prefix id
Destination 1 64 bi 2001:63:
80:9 equal not-sent
Destination 1 64 bi ::2 equal not-sent
UDP Header Fields
Source
Port 1 2 bi 5682 ignore value-sent
Destination
Port 1 2 bi 5555 ignore value-sent
Length 1 2 bi None ignore Compute-
length
Checksum 1 2 bi None ignore Compute-
checksum
Fig. 8. Bytes of the headers generated from 10 packets.
TABLE II
THR EE SCE NAR IOS COMPARISON
Scenario A:IPv6 B:6LoWPAN C:SCHC
Data rate high medium low
Memory Usage low low High
Mobility support Yes Yes No
Interoperability Yes Yes Specific
technologies
Scalability Yes Yes No
Network topology Mesh Mesh/star Star
Header compression no
compression
>6 bytes
<37 bytes
>1 bit
<6 bytes
48 bytes header
compression 48 bytes 27 bytes
5 bytes
then
3 bits
Compression gain 0% 43% 90%
the number of bytes generated to send only ten packets by each
standard. During the transmission of the packets, the necessary
header fields hold unchangeable values such as IP and the
port of communication between the source and destination.
To show the amount of these bytes, we set at the gateway
a byte counter to count the headers size generated by each
standard after the transmission of 10 packets. As shown in Fig.
8, we compare one 6LoWPAN device with ten SCHC devices.
The results show that more than 600 bytes are consumed as
headers to transmit ten packets. While ten devices using SCHC
standard consume less than 150 bytes. Therefore, in the case
of radio constraints, SCHC standard is preferable.
VI. CONCLUSION
This work analyzed two header compression solutions used
to compress IPv6 protocol to run on constrained devices. The
mechanism of the SCHC protocol has been implemented on
NS3. The mechanism of 6LoWPAN was already implemented
and proposed on NS3. We simulated three scenarios, and the
results showed that SCHC is more efficient for the LPWAN
context. However, SCHC is a mechanism that is characterized
by a static context. Thus, SCHC could be considered as a
solution for only predetermined fixed flows which is the case
of most LPWANs technologies. Furthermore, SCHC uses a
single static context to save the different rules, and rules
can cover several layers of the network stack. In case we
have two IPv6/UDP flows to the same IPv6 host, then one
IPv6 header and two different UDP ports are considered. That
corresponds to the case of running two concurrent applications
on different UDP ports. SCHC mechanism would include
a rule for each flow, resulting in a similar context. In this
case, SCHC mechanism stores two similar versions of the
fields for the IPv6 header. That storage increases memory
usage in constrained devices with duplicate information. The
limitations mentioned above will be the subject of future work.
Our implemented module only deals with the compression of
IPv6/UDP packets. However, this work could be extended to
support the compression of application layer protocol CoAP.
REFERENCES
[1] W. Ayoub, M. Mroue, F. Nouvel, A. E. Samhat, and J. c. Prvotet,
“Towards ip over lpwans technologies: Lorawan, dash7, nb-iot,” in 2018
Sixth International Conference on Digital Information, Networking, and
Wireless Communications (DINWC), pp. 43–47, April 2018.
[2] Z. Sheng, S. Yang, Y. Yu, A. V. Vasilakos, J. A. Mccann, and K. K.
Leung, “A survey on the ietf protocol suite for the internet of things:
standards, challenges, and opportunities,” IEEE Wireless Communica-
tions, vol. 20, pp. 91–98, December 2013.
[3] C. G. D. B. J. Z. A. Minaburo, L. Toutain, “Lpwan static context header
compression (schc) and fragmentation for ipv6 and udp draft-ietf-lpwan-
ipv6-static-context-hc-17,” October 22, 2018.
[4] W. Ayoub and S. Hmede, “Schc mechanism module on ns3.”
https://gitlab.insa-rennes.fr/Wael.Ayoub/schc-module-ns3, October
2018.
[14] H. Al-Kashoash and A. Kemp, “Comparison of 6lowpan and lp-
wan for the internet of things,” Australian Journal of Electrical and
Electronics Engineering, vol. 13, pp. 268–274, December 2017. c
2017 Engineers Australia. This is an Accepted Manuscript of an
article published by Taylor & Francis in Australian Journal of Elec-
trical and Electronics Engineering on 1 December 2017, available
online: http://www.tandfonline.com/10.1080/1448837X.2017.1409920.
Uploaded in accordance with the publisher’s self-archiving policy.
[5] https://www.nsnam.org/releases/,September 4, 2018.
[6] C. Yanamadala and K. Marneweck, “Why silicon security may be cru-
cial for next design.” https://pages.arm.com/Webinar-recording-silicon-
security-crucial-for-iot-device-typ.html?aliId=42779824, October 2018.
[7] E. A. Kobus Marneweck, Senior Product Manager, “An
introduction to the arm cortex-m35p processor, white paper.”
https://pages.arm.com/rs/312-SAX-488/images/Whitepaper-ARM-
Cortex-M35P-Whitepaper.pdf, 2018.
[8] H. A. A. Al-Kashoash and A. H. Kemp, “Comparison of 6lowpan and
lpwan for the internet of things,” Australian Journal of Electrical and
Electronics Engineering, vol. 13, no. 4, pp. 268–274, 2016.
[9] 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, CHANTS ’17, (New York, NY,
USA), pp. 13–18, ACM, 2017.
[10] P. Weber, D. Jckle, D. Rahusen, and A. Sikora, “Ipv6 over lorawan,”
in 2016 3rd International Symposium on Wireless Systems within the
Conferences on Intelligent Data Acquisition and Advanced Computing
Systems (IDAACS-SWS), pp. 75–79, Sept 2016.
[11] S. Thielemans, M. Bezunartea, and K. Steenhaut, “Establishing trans-
parent ipv6 communication on lora based low power wide area networks
(lpwans),” in 2017 Wireless Telecommunications Symposium (WTS),
pp. 1–6, April 2017.
[12] W. Ayoub, A. E. Samhat, F. Nouvel, M. Mroue, and J. Prvotet,
“Internet of mobile things: Overview of lorawan, dash7, and nb-iot
in lpwans standards and supported mobility,IEEE Communications
Surveys Tutorials, pp. 1–1, 2018.
[13] R. Ballamajalu, S. V. R. Anand, and M. Hegde, “Co-ioam: In-situ
telemetry metadata transport for resource constrained networks within
ietf standards framework,” in 2018 10th International Conference on
Communication Systems Networks (COMSNETS), pp. 573–576, Jan
2018.
[15] R. Sanchez-Iborra, J. Snchez-Gmez, J. Santa, P. J. Fernndez, and A. F.
Skarmeta, “Ipv6 communications over lora for future iov services,” in
2018 IEEE 4th World Forum on Internet of Things (WF-IoT), pp. 92–97,
Feb 2018.
[16] D. Minoli, IPv6 Over LowPower WPAN (6Lowpan). Wiley, 2013.
[17] P. Thubert, “Compression Format for IPv6 Datagrams over IEEE
802.15.4-Based Networks.” RFC 6282, Sept. 2011.
... Furthermore, the maximum layer 2 MTU offered by several LPWAN technologies is significantly smaller than that of 6LoWPAN or 6Lo technologies. These are the main reasons why the IETF LPWAN working group is defining the SCHC protocol [9] in order to provide fragmentation [17][11] [3], and header compression [1] over LPWAN such as LoRAWAN. ...
... Recently, Moons et al. [11] and Ayoub et al. [3] studied the benefits of using SCHC or 6LoWPAN for LoRaWAN networks. They performed compute the overhead in terms of headers and number of packets, and proposed an implementation for the OSS-7 operating system in [11]. ...
... They showed that the overhead is twenty times smaller with SCHC than with 6LoWPAN. In [3] they described an interesting implementation using the network simulator ns-3, but do not provide a performance analysis on the acknowledgment mechanisms. ...
... Furthermore, the maximum layer 2 MTU offered by most LPWAN technologies is significantly smaller than that of 6LoWPAN or 6Lo technologies. These are the main reasons why the IETF LPWAN working group is defining the SCHC protocol [8] in order to provide fragmentation [3,10,17], and header compression [1] over LPWAN technologies such as LoRAWAN. ...
... Recently, Moons et al. [10] and Ayoub et al. [3] studied the benefits of using SCHC or 6LoWPAN for LoRaWAN networks. They performed the computation of the overhead in terms of headers and number of packets, and proposed an implementation for the OSS-7 operating system in [10]. ...
... They showed that the overhead is twenty times smaller with SCHC than with 6LoWPAN. In [3] they described an interesting implementation using the network simulator ns-3, but did not provide a performance analysis on the acknowledgment mechanisms. ...
Chapter
Low Power Wide Area Networks (LPWANs) have emerged as new networks for Internet of Things (IoT). LPWANs are characterized by long-range communications and low energy consumption. Furthermore, LPWAN technologies have a small data unit and do not provide a fragmentation mechanism. To enable these technologies to support IPv6 and, thus, be compliant with the IPv6 Maximum Transmission Unit (MTU) of 1280 bytes, the LPWAN Working Group (WG) of the Internet Engineering Task Force (IETF) has defined a new framework called Static Context Header Compression (SCHC). SCHC includes Fragmentation/Reassembly (F/R) functionality for transmitting larger packet sizes than the layer 2 MTU that the underlying LPWAN technology offers and a header compression mechanism. Moreover, SCHC defines three operational modes to perform the F/R process: No-ACK, ACK-Always and ACK-on-Error. Each mode provides different reliability levels and mechanisms. In this paper, we provide an overview of the SCHC F/R modes and evaluate their trade-offs over LoRaWAN by simulations. The analyzed parameters are the total channel occupancy, goodput and total delay at the SCHC layer. The results of our analysis show that No-ACK mode is the method with lowest total channel occupancy, highest goodput and lower total delay, but lacks a reliability mechanism. ACK-Always and ACK-on-Error modes offer the same total delay, and similar total channel occupancy, whereas ACK-on-Error offers greater goodput.
... Recently, SCHC has brought the attention of academia and industry as it enables IPv6 connectivity over LPWAN networks [2], [3], [5]- [7], [10]- [17]. With a standard network layer, the deployment of IoT applications, e.g., data transmission over CoAP, is expected to improve the interoperability of LPWAN technologies with existing Internet technologies. ...
... To compare SCHC performances to previous proposals of the IETF for different technologies, Ayoub et al. implemented a generic version of SCHC in the NS-3 simulator, focusing on the compression/decompression function [10]. In [12], [13], the performance of SCHC over LoRaWAN is modeled and validated with an experimental testbed limited to the ACK-on-Error mode for uplink traffic. ...
Article
Full-text available
The Static Context Header Compression and fragmentation (SCHC) framework has been recently designed by the IETF. SCHC provides adaptation layer functionality intended to efficiently support IPv6-based and other applications over LPWAN technologies. As of the writing, technology-specific profiles are being standardized in order to describe how SCHC can be tailored when used over a given underlying technology. In this paper, we provide the first performance evaluation of SCHC over Sigfox, a flagship LPWAN technology. We focus on the main SCHC over Sigfox fragmentation mode, called ACK-on-Error, which offers low overhead, reliability, and reassem-bly functionalities. We provide a theoretical analysis and an experimental evaluation in real environments that correspond to two geographical zones with different Sigfox radio settings: Barcelona (Spain) and Santiago (Chile). The study focuses on modeling and evaluating packet transfer times, and the required number of uplink and downlink messages. The results show that a small change in packet sizes may significantly affect the transfer times, especially when no duty-cycle restrictions are enforced. Also, we observe that, under certain conditions, an increase in the fragment loss rate may decrease the packet transfer time, and that the number of uplink and downlink messages is not proportional to such increase due to the fact that downlink messages are device-driven. The results provide useful insights for researchers, developers, implementers, and providers, with applicability to the application design, network planning, and resource management of IoT solutions.
... Other works analyzed the performance of IPv6 header compression [13]- [15] and/or fragmentation over LPWAN by using SCHC [16]- [19]. Abdelfadeel et al. [13], [14] and Ayoub et al. [15] focused only on SCHC header compression. ...
... Other works analyzed the performance of IPv6 header compression [13]- [15] and/or fragmentation over LPWAN by using SCHC [16]- [19]. Abdelfadeel et al. [13], [14] and Ayoub et al. [15] focused only on SCHC header compression. Moons et al. [16] compared the memory footprint of SCHC header compression and fragmentation with that of a 6LoWPANbased solution. ...
Article
Full-text available
The Internet Engineering Task Force (IETF) has standardized a new framework for IPv6 support over Low Power Wide Area Networks (LPWANs), called Static Context Header Compression and Fragmentation (SCHC). SCHC includes acknowledgment (ACK)-based mechanisms for reliable fragmented packet transmission. For the latter, SCHC defines a Receiver-Feedback Technique (RFT), called Compressed Bitmap (CB), by which a receiver reports to the sender whether the fragments carrying a packet have been received or not. Such information is carried as ACK payload. Considering the extraordinary frame size and message rate constraints of LPWANs, ACK payload size becomes crucial. In this paper, we compare the performance of CB with that of several alternative RFTs, namely List of Lost Fragments (LLF), List of Deltas (LoD), and Uncompressed Bitmap (UB), where the latter is used as a benchmark. We evaluate the considered RFTs in terms of ACK size, number of Layer 2 (L2) frames needed to carry an ACK, and ACK Time on Air. Our analysis shows that the use of RFTs different from CB offers significant performance improvement in many scenarios. Furthermore, we provide guidance on which RFT should be used for different packet sizes, error rates and error patterns.
... Static Context Header Compression started receiving increasing attention from the research community. In both [3] and [6], the compression mechanism is implemented and evaluated, in C and NS-3, respectively. The authors of [3] also implemented the fragmentation mechanism and made the library publicly available [7]. ...
... Both authors conclude that a novel adaptation standard is needed, as 6LoWPAN does not provide enough flexibility for LPWAN communication technologies. The authors of [6] continue their work in [8], where a central Administration Management Server (AMS) manages the context in order to support roaming of devices between different Long-Range Wide-Area Network (LoRaWAN) operators. While this approach allows devices to roam between multiple networks of different operators, the AMS, and consequently complex architectural components, are still required to keep track of the device rules. ...
Article
Full-text available
Due to the limited bandwidth of Low-Power Wide-Area Networks (LPWAN), the application layer is currently often tied straight above the link layer, limiting the evolution of sensor networks distributed over a large area. Consequently, the highly efficient Static Context Header Compression (SCHC) standard was introduced, where devices can compress the IPv6 and upper layer protocols down to a single byte. This approach, however, assumes that every compression context is distributed before deployment, again limiting the evolution of such networks. Therefore, this paper presents two context registration mechanisms leveraging on the SCHC adaptation layer. This is done by analyzing current registration solutions in order to find limitations and optimizations with regard to very constrained networks. Both solutions and the current State-of-The-Art (SoTA) are evaluated in a Lightweight Machine to Machine (LwM2M) environment. In such situation, both developed solutions decrease the energy consumption already after 25 transmissions, compared with the current SoTA. Furthermore, simulations show that Long Range (LoRa) devices still have a 80% chance to successfully complete the registration flow in a network with a 50% Packet Error Ratio. Briefly, the work presented in this paper delivers bootstrapping tools to constrained, SCHC-enabled networks while still being able to reduce energy consumption.
... Suciu et al [13] showed that fragmentation increases reliability, especially when sending several fragments instead of only one of the MTU size. Other works focus on IPv6 over LPWAN by means of using SCHC [8], [14][15][16][17][18]. Some of these propose enhancements to SCHC Header compression, but do not consider SCHC F/R [16], [17]. ...
... Their results show that SCHC has a smaller footprint, uses less memory and the header overhead is twenty times smaller when compared with 6LoWPAN. Ayoub et al. [15] present an implementation of SCHC using the ns-3 network simulator and also compare SCHC with 6LoWPAN, finding the same performance advantage for SCHC in terms of header overhead. The authors in [8] provided an overview of SCHC and a simple evaluation of the different F/R modes, but it is a superficial study due to its tutorial purpose. ...
Article
Full-text available
The Internet Engineering Task Force (IETF) Low Power Wide Area Network (LPWAN) Working Group has developed the Static Context Header Compression (SCHC) framework to enable IPv6 over LPWAN. In order to support 1280-byte packets, as required for IPv6, SCHC includes a fragmentation functionality, since relevant LPWAN technologies offer very short data unit sizes and do not provide native fragmentation mechanisms. SCHC offers 3 fragmentation modes: No-ACK, ACK-Always, and ACK-on-Error, the latter being especially promising due to its reliability and high efficiency. In this article, we develop a mathematical model to compute the most critical performance parameters for the SCHC ACK-on-Error mode, namely, the acknowledgment traffic incurred by a fragment receiver for the successful delivery of a fragmented packet. The model is used to evaluate the SCHC ACK-on-Error mode performance, as well as to optimally tune its main parameters when used over LoRaWAN and Sigfox, for different packet sizes. Additionally, we illustrate how our derived optimal settings allow to reduce the acknowledgment traffic in a number of scenarios.
... In addition, adaptation layer is used in packet fragmentation mechanism in networks that have small maximum transmission unit length. A well known adaption layer protocol is IPv6 over Low Power Wireless Personal Area Networks (6LoWPAN) [26], others exist such as RObust Header Compression (ROHC) [27] and Static Context Header Compression (SCHC) [28]. ...
Article
The Internet of Things (IoT) is a new emerging system of interconnected devices that experiences significant growth in a wide variety of applications. The rising communication technologies for IoT are the Low Power Wide Area Networks (LPWANs) having long range, low cost and low power characteristics. In this context, an important part of the applications requires the mobility of the end devices with secure communications. In this paper, we consider the mobility management solutions in LPWAN networks and we investigate how they ensure security. We first review the basic IoT security requirements and the typical IoT protocol stack. We then focus on the existing mobility management solutions in LPWAN and we highlight the mobility related security issues by checking the attacks that can be performed in case of mobility. Furthermore, we evaluate the security in each mobility solution by checking the aforementioned attacks and we draw a comparison study.
... In addition, for connectivity and mobility, the IPv6 protocol provides the IoT device with many functions and features, as detailed in the previous work [8]. The proposed mobility management solution, between different LPWAN technologies, uses the concept adopted in the standard Static Context Header Compression (SCHC) [9]. The SCHC standard has defined a mechanism to compress / decompress protocol headers in less than 2 bytes to limit the additional overhead on the radio frame. ...
Article
The integration of IoT communication technologies such as Low Power Wide Area Networks (LPWAN) is essential in today systems including supply chain, healthcare, autonomous vehicle, etc. In such environments there is an increase in IoT applications that require End Devices (EDs) mobility within similar or heterogeneous LPWAN technologies. Supporting mobility refers to ensure the delivery of data on demand and during movement. In this paper, we investigate the mobility of ED between different LPWAN technologies. We propose a new mobility management solution in LPWAN to achieve continuity of the communication after the link layer technology changes between the ED and the Application Server (AS). This solution is IPv6-based and supports switching between heterogeneous LPWAN networks and technologies. It results in reducing the time required to deliver the data by optimizing the communication routing and saving the bandwidth. The validation of the proposed solution is achieved through the scenarios of ED handovers between LoRaWAN and NB-IoT using simulations as well as experimentation.
Article
In this paper, we consider the mobility of an end device (ED) in low-power wide area networks (LPWAN) and we focus on the continuity of the ED session with the application server when this ED is moving from the coverage of one operator to that of another one. One of the methods to achieve the continuity of the session after roaming is the use of an IPv6-based scheme. As LPWAN is characterized by a fixed message rate and very small bandwidth as well as asymmetric communication, an efficient header compression scheme is required. Recently, the IETF LPWAN working group has proposed static context header compression (SCHC) to compress IPv6 into LPWAN through a rule-based mechanism. In this work, we first extend SCHC scheme to support session continuity and the new scheme is called MSCHC (Mobile SCHC). MSCHC consists of several contexts, instead of the static context for SCHC and we also improve the use of the memory by dividing the rules into layers. Then, we investigate the mobility of the ED to show how continuity of the session can be achieved while transmitting and receiving data when the ED is roaming between different operators. The proposed solution is based on the use of light mobile IPv6 messages compressed with MSCHC. Finally, the proposed mechanism is implemented in the popular LoRaWAN technology, evaluated and compared with the existing solutions provided by the LoRaWAN v1.1 standard.
Conference Paper
Full-text available
In this paper, we discuss a set of solutions that are proposed in order to run IPv6 over IoT and we investigate its applicability over the three Low Power Wide Area Networks (LPWANs) technologies: LoRaWAN, DASH7, NB-IoT. LPWANs are wireless technologies that are used to connect things to the Internet. These technologies are characterized by their large coverage area, long battery operation, low bandwidth, small frame payload size, and the use of asymmetric and non-synchronized communication. Based on this investigation, we highlight the schemes that can be adopted for IP-based LPWANs technologies.
Conference Paper
Full-text available
Supporting IPv6/UDP/CoAP protocols over Low Power Wide Area Networks (LPWANs) can bring open networking, interconnection, and cooperation to this new type of Internet of Things networks. However, accommodating these protocols over these very low bandwidth networks requires efficient header compression schemes to meet the limited frame size of these networks, where only one or two octets are available to transmit all headers. Recently, the Internet Engineering Task Force (IETF) LPWAN working group drafted the Static Context Header Compression (SCHC), a new header compression scheme for LPWANs, which can provide a good compression factor without complex synchronization. In this paper, we present an implementation and evaluation of SCHC. We compare SCHC with IPHC, which also targets constrained networks. Additionally, we propose an enhancement of SCHC, Layered SCHC (LSCHC). LSCHC is a layered context that reduces memory consumption and processing complexity, and adds flexibility when compressing packets. Finally, we perform calculations to show the impact of SCHC/LSCHC on an example LPWAN technology, e.g. LoRaWAN, from the point of view of transmission time and reliability.
Article
Full-text available
By 2020, 50 billion devices (things) are expected to be connected to the Internet to form the Internet of Things (IoT) world. In general, two main categories of networks are used in the IoT: short-range and long range low power networks. IPv6 over low power wireless personal area networks (6LoWPAN) are considered to be a crucial network in short-range low power networks where 6LoWPAN motes will account for the majority of short-range low power things. Instead, LoRaWAN and SigFox are two major networking landscapes and players in long-range, low power networks or oftentimes called low power wide area networks (LPWAN). This paper reviews and compares 6LoWPAN and LPWAN in terms of network architecture, protocol stack, applications and security. In general, LPWAN networks are more demanding in terms of node and link constraints than 6LoWPAN networks (e.g. very low payload size, very low data rate and very limited resources). Also, as yet, LPWAN networks do not have IPv6 addressing capabilities. Each network category has its unique characteristics and strengths and each category has its important role in the IoT world.
Conference Paper
New Long-Range radio technologies have recently appeared in the IoT landscape. Combining the existing protocols with these novel radio technologies could increase the potential opportunities and the diversity of use for Wireless Sensor Networks. In this paper, an implementation of a LoRa based sensor platform that uses the proposed, in order to enable standardized IPv6 LoRa communications. This development will allow to expand routing protocols for WSNs (e.g. RPL), and to take advantage of this newly available radio technology. The integration is demonstrated by presenting range measurements for a point-to-point link between two Contiki- motes.
Chapter
Developers make the case that the Institute of Electrical and Electronics Engineers (IEEE) 802.15.4-2003 standard is very promising for the lower layers. As for higher layer functions, the goal is to utilize internet protocol (IP) technology, specifically internet protocol version6 (IPv6), considering the v6 capabilities and benefits. The basic RFC makes 802.15.4 look like an IPv6 link; it provides basic encapsulation and efficient representation of packets smaller than 100 octets. Some highlights of this work are provided in this chapter. LoWPANs in general and IEEE 802.15.4-2003-based systems in particular have design constraints that need to be taken into consideration when developing a protocol stack. All Low-Power wireless personal area network (LoWPAN)-encapsulated datagrams transported over IEEE 802.15.4 are prefixed by an encapsulation header stack. Each header in the header stack contains a header type followed by zero or more header fields. data encapsulation; IEEE 802.15 Standards; wireless personal area networks
Article
Technologies to support the Internet of Things are becoming more important as the need to better understand our environments and make them smart increases. As a result it is predicted that intelligent devices and networks, such as WSNs, will not be isolated, but connected and integrated, composing computer networks. So far, the IP-based Internet is the largest network in the world; therefore, there are great strides to connect WSNs with the Internet. To this end, the IETF has developed a suite of protocols and open standards for accessing applications and services for wireless resource constrained networks. However, many open challenges remain, mostly due to the complex deployment characteristics of such systems and the stringent requirements imposed by various services wishing to make use of such complex systems. Thus, it becomes critically important to study how the current approaches to standardization in this area can be improved, and at the same time better understand the opportunities for the research community to contribute to the IoT field. To this end, this article presents an overview of current standards and research activities in both industry and academia.
Lpwan static context header compression (schc) and fragmentation for ipv6 and udp draft-ietf-lpwan-ipv6-static-context-hc-17
  • C G D B J Z A Minaburo
  • L Toutain
C. G. D. B. J. Z. A. Minaburo, L. Toutain, "Lpwan static context header compression (schc) and fragmentation for ipv6 and udp draft-ietf-lpwan-ipv6-static-context-hc-17," October 22, 2018.
Schc mechanism module on ns3
  • W Ayoub
  • S Hmede
W. Ayoub and S. Hmede, "Schc mechanism module on ns3." https://gitlab.insa-rennes.fr/Wael.Ayoub/schc-module-ns3, October 2018.