ArticlePDF Available

IPv6 over LPWANs: connecting Low Power Wide Area Networks to the Internet (of Things)

Authors:

Abstract

LPWANs have recently emerged as a promising solution for enabling industrial IoT applications. To fully exploit their potential, LPWANs need to be connected to the Internet. However, the severe capacity constraints of LPWAN technologies challenge IPv6 support, and even 6LoWPAN-based adaptations are not sufficient. In this paper, we present Static Context Header Compression and Fragmentation (SCHC), an ultralightweight IPv6 adaptation layer designed for LPWANs, which is being standardized by the IETF.
1
IPv6 over LPWANs: connecting Low Power Wide Area Networks to
the Internet (of Things)
Carles Gomez1, Ana Minaburo2, Laurent Toutain3, Dominique Barthel4,
Juan Carlos Zuniga5
1Universitat Politècnica de Catalunya, 2Acklio, 3IMT-Atlantique, 4Orange Labs, 5Sigfox
E-mail: carlesgo@entel.upc.edu, ana@ackl.io, Laurent.Toutain@imt-atlantique.fr,
dominique.barthel@orange.com, juancarlos.zuniga@sigfox.com
Abstract
LPWANs have recently emerged as a promising solution for enabling industrial IoT
applications. To fully exploit their potential, LPWANs need to be connected to the
Internet. However, the severe capacity constraints of LPWAN technologies challenge
IPv6 support, and even 6LoWPAN-based adaptations are not sufficient. In this paper,
we present Static Context Header Compression and Fragmentation (SCHC), an
ultralightweight IPv6 adaptation layer designed for LPWANs, which is being
standardized by the IETF.
1. Introduction
The Internet of Things (IoT) is a networking paradigm whereby a vast number of
connected, typically resource-constrained devices (e.g. battery-enabled sensors and
actuators), sense or act upon the physical world to enable intelligent environments. This
vision constitutes a revolution that is expected to transform our society by substantially
enhancing productivity, sustainability, and human life quality.
The IoT is currently developing in several dimensions. As the number of connected IoT
devices grows steadily, the number of communications technologies for IoT devices
increases, too. Well-established IoT technologies, such as IEEE 802.15.4 and Bluetooth
Low Energy (BLE), are characterized by a rather short communication range, generally
in the order of tens or a few hundreds of meters. However, with such a reduced range, a
considerable amount of infrastructure (e.g. relay nodes and/or gateways) is needed to
ensure connectivity of IoT devices over a large area (e.g. a city). This approach requires
a potentially complex networking solution and leads to high network deployment,
maintenance and management cost.
In order to overcome the aforementioned issues, the category of wireless
communication technologies called Low Power Wide Area Networks (LPWANs) has
emerged. LPWAN technologies define star topology networks whereby a single base
station covers up to hundreds of thousands of IoT devices with a multiyear IoT device
battery lifetime, while supporting a multikilometer link range [1]. These characteristics
are achieved at the expense of extremely low data rates and small payloads, which are
sufficient to many common industrial IoT applications. In fact, LPWANs have quickly
attracted the interest of industry, academia and standards development organizations,
Author’s pre-print, accepted for publication in the IEEE Wireless Communications Magazine (2019-10-30).
copyright 2019 IEEE. Please refer to the final version once published.
Personal use of this material is permitted. Permission from IEEE must be obtained for all other users, including
reprinting/ republishing this material for advertising or promotional purposes, creating new collective works for
resale or redistribution to servers or lists, or reuse of any copyrighted components of this work in other works.
2
with 4 billion LPWAN devices predicted by 20251. Flagship LPWAN technologies
include LoRaWAN, Sigfox and Narrowband IoT (NB-IoT). Furthermore, the IEEE
802.15.4w task group has been recently chartered to optimize IEEE 802.15.4 for
LPWAN scenarios.
To fully exploit the potential of LPWANs, Internet connectivity support is required.
Therefore, LPWAN devices need to be able to run IP. In particular, IP version 6 (IPv6)
is assumed, since it offers a massive address space and self-configuration tools.
However, IPv6 was designed for resource-rich networking environments (e.g. Ethernet),
whereas typical IoT network scenarios offer significantly constrained energy,
computation, and communication capabilities. For over one decade, the IETF IPv6 over
Low-power Wireless Personal Area Networks (6LoWPAN) Working Group (WG) and
the IETF IPv6 over Networks of Resource-constrained Nodes (6Lo) WG have
developed adaptation layers to enable and optimize IPv6 over a wide range of IoT link-
layer technologies, hereafter called 6LoWPAN/6Lo technologies. These include IEEE
802.15.4, BLE, ITU-T G.9959 (Z-Wave), Digital Enhanced Cordless
Telecommunications – Ultra Low Energy (DECT-ULE) and Near Field Communication
(NFC), among others [2]. Nevertheless, 6LoWPAN/6Lo adaptation style would incur
unaffordable overhead over LPWANs, given the extremely restricted communication
resources of LPWAN technologies. For example, the sustained capacity of
6LoWPAN/6Lo technologies is of at least a few kbit/s, while some LPWAN
technologies are limited to as low as the mbit/s (i.e. millibit/s!) order.
In 2016 the IETF LPWAN WG was chartered to provide support of IPv6 and upper
layer Internet protocols over LPWANs [3]. This WG is now reaching completion of the
Static Context Header Compression and Fragmentation (SCHC) specification, of which
we are authors [4]. In this article, we motivate, present and evaluate SCHC.
The remainder of this article is organized as follows. Section 2 introduces the main
target LPWAN technologies considered by the IETF LPWAN WG. Section 3 presents
the IPv6-based protocol stack for LPWANs. Sections 4 and 5 describe and evaluate
SCHC, respectively. Open issues are overviewed in Section 6. Finally, Section 7
provides conclusions.
2. Target LPWAN technologies
This section briefly reviews the LPWAN technologies considered by the IETF LPWAN
WG in the design of SCHC, namely: LoRaWAN, Sigfox, NB-IoT and IEEE 802.15.4w.
These technologies are discussed and compared with 6LoWPAN/6Lo wireless
technologies.

1 https://www.abiresearch.com/press/4-billion-iot-devices-will-rely-lpwan-technologies (accessed on
August 22nd 2019)
3
2.1. LoRaWAN
LoRaWAN is a popular LPWAN technology that was first specified in 2015 by an
industry consortium called the LoRa Alliance. LoRaWAN defines a protocol
architecture that comprises a Physical (PHY) layer, a Medium Access Control (MAC)
layer and customer applications on top of the MAC layer [5].
At the PHY layer, LoRaWAN operates in unlicensed bands and uses the LoRa
modulation, which is based on Chirp Spread Spectrum (CSS). A range of Spreading
Factor (SF) options are supported, leading to different corresponding Data Rates (DRs)
and robustness levels. In order to save energy, a LoRaWAN IoT device typically only
turns its receiver on shortly after it transmits an uplink message, which is done
asynchronously.
2.2. Sigfox
Sigfox is a technology created by the eponymous company, which was founded in 2009.
Currently, Sigfox has been deployed in more than 60 countries. In Sigfox, IoT devices
asynchronously transmit messages by using Ultra Narrow Band (UNB) in unlicensed
spectrum. Each message sent by an IoT device is transmitted three times, using a
different frequency for each of the three transmission attempts. If a device is willing to
receive messages, it indicates so in the uplink message, after which the device opens a
receiving window. Otherwise, when the device is inactive, it keeps its radio interface off
[6].
2.3. NB-IoT
NB-IoT is specified in 3GPP Release 13, published in 2016. NB-IoT uses a subset of
the Long Term Evolution (LTE) standard, with the aim to meet IoT requirements, such
as low device cost and relaxed bandwidth requirements [7]. In contrast with LoRaWAN
and Sigfox, NB-IoT operates in licensed frequency bands. In NB-IoT, the IoT device
remains by default in low energy consumption states, except for the periodic
transmission of location reports and monitoring of a paging channel for incoming
downlink data. Uplink data transmission may be carried out after a successful, IoT
device-initiated, contention-based random access procedure. Downlink data may also be
received immediately after uplink data transmission [8].
2.4. IEEE 802.15.4w
IEEE 802.15.4w is an IEEE 802.15.4 amendment currently being developed, intended
to address LPWAN use cases, by enhancing the existing IEEE 802.15.4k specification.
The latter was designed for Low Energy Critical Infrastructure Monitoring (LECIM).
The proposed enhancements, still being discussed at the time of writing, comprise
improved Forward Error Correction (FEC) codes, sub-packet spreading in time and
frequency, and a scalable multiple access frame structure. The intended goals include
improving interference resilience, energy efficiency, and scalability.
4
2.5. Discussion
We now compare the communication capacity features of LoRaWAN, Sigfox and NB-
IoT with those of 6LoWPAN/6Lo technologies, focusing on the aspects that are relevant
for IPv6 support (Table 1). Overall, LoRaWAN and Sigfox are significantly more
constrained, whereas NB-IoT has similar characteristics to 6LoWPAN/6Lo
technologies, as discussed next.
In order to benefit link range, LoRaWAN and Sigfox use unlicensed sub-GHz bands
instead of higher ISM bands (e.g. the 2.4 GHz band). However, in some world regions,
the former are subject to spectrum access regulations, which both LoRaWAN and
Sigfox enforce by keeping the device radio duty cycle (RDC) below a given limit (e.g.
1% in the uplink, in some channels in Europe). As a result, message rates in these two
technologies may be extremely low, even down to a few messages per day. In contrast,
6LoWPAN/6Lo technologies either use bands that are not subject to such regulatory
constraints, or use alternative spectrum sharing techniques, therefore they do not suffer
the same issues. Note that, since NB-IoT uses licensed frequency bands, it is also free of
message rate limitations stemming from spectrum access regulations.
Also favoring a long link range, both LoRaWAN and Sigfox use PHY layer data rates
(102 to 104 bit/s) lower than those of 6LoWPAN/6Lo technologies (104 to 106 bit/s). In
consequence, their frame size needs to be small to limit device energy consumption due
to communication. The maximum frame payload size in Sigfox and in some LoRaWAN
scenarios is extremely short (of ~10 bytes), well below that of 6LoWPAN/6Lo
technologies. This feature also reduces the probability of collision and thus favors
network scalability. However, it also severely decreases sustained transmission
capacity. Furthermore, neither Sigfox nor LoRaWAN natively support fragmentation
and reassembly (hereinafter denoted fragmentation, for brevity), thus they do not allow
sending larger upper layer data units.
The extreme constraints exhibited by LoRaWAN and Sigfox motivated the
development of SCHC, a new adaptation layer specifically designed to support IPv6
over LPWANs, as detailed in the next section. While NB-IoT is not as limited as
LoRaWAN and Sigfox, it will also benefit from the high efficiency of SCHC.
5
LPWAN technologies 6LoWPAN/6Lo wireless technologies
LoRaWAN Sigfox NB-IoT IEEE 802.15.4 BLE ITU-T G.9959 DECT-ULE NFC
Frequency band(s)
(MHz)
868 (EU),
915 (US),
783 (China)
868 (EU),
915 (US),
923 (Japan)
Various:
416 (min),
2200 (max)
868 (EU),
915 (US),
2400 (worldwide)
2400 868 (EU),
915 (US)
1900 13.56
Type of band Unlicensed Unlicensed Licensed Unlicensed Unlicensed Unlicensed Dedicated Unlicensed
Modulation CSS
DBPSK (uplink),
GFSK (downlink)
π/2-BPSK or
π/4-QPSK (upl.),
QPSK (downlink)
BPSK (sub-GHz),
O-QPSK (2.4 GHz)
GFSK FSK/FSK/GFSK
(R1/R2/R3)
GFSK OOK, BPSK
Receiver sensitivity
(dBm)
-137
(typical)
-142
(typical)
-141
(typical)
-92 min. (sub-GHz),
-85 min. (2.4 GHz)
-70
(Bluetooth 4.0)
-95/-92/-89
(R1/R2/R3)
-86 N.A.
PHY layer data rate
(kbit/s)
0.25 ÷ 5.47 (EU),
50 (optional)
0.1/0.6 250 (uplink),
226.7 (downlink)
20/40/250 125/500/
1000/2000
9.6/40/100
(R1/R2/R3)
1152 106/212/424
Message rate
constraints
Duty cycle < 1%
(EU, China)
140/4 messages
per day
(uplink/downlink)
No No No No No No
Capacity per device
(order of magnitude,
in bit/s)
100 (DR0, EU),
102 (DR5, EU)
10-1 (uplink)
10-3 (down.)
104 103 (sub-GHz),
105 (2.4 GHz)
105
(at 1 Mbit/s)
103 (R1),
104 (R2/R3)
105 104
(at 424 kbit/s)
MAC mechanism Aloha-based
(optional ACKs +
retries)
Aloha-based
(3 transmissions)
Slotted Aloha
(random access) +
scheduling
CSMA/CA, TDMA TDMA CSMA/CA TDMA TDMA link
initialization
Maximum frame
payload size (bytes)
11 (DR0, USA) ÷
242 (worldwide)
12 (uplink),
8 (downlink)
1600 105 23 158 38 125
Fragmentation and
reassembly
No No Yes No Yes Yes Yes Yes
Network topology Star Star Star Star, mesh Star, mesh Mesh Star Point-to-point
Standards Developm.
Organization
LoRa Alliance ™ Sigfox
(company)
3GPP IEEE Bluetooth SIG ITU-T ETSI NFC Forum
Table 1. Main details of LoRaWAN, Sigfox and NB-IoT. IEEE 802.15.4w is excluded from this table, since, at the time of writing, its features are yet to be
determined.
6
3. IPv6-based protocol stack for LPWANs
Over more than a decade, the IETF has developed a lightweight, IPv6-based protocol
stack suitable for IoT devices (Fig. 1.a). Such protocol stack includes three components
that have been designed for IoT scenarios: a 6LoWPAN/6Lo adaptation layer, the IPv6
Routing protocol for Low-power and lossy networks (RPL) [9], and the Constrained
Application Protocol (CoAP) [10]. However, to provide the best fit for LPWAN
technologies, the IPv6-based protocol stack assumed by the IETF LPWAN WG
presents some particularities (Fig. 1.b). We now review the IoT-specific components of
the lightweight IPv6-based protocol stack and justify the protocol stack modifications
made for LPWANs.
The 6LoWPAN adaptation layer was developed to enable and optimize IPv6 over IEEE
802.15.4 networks [11]. 6LoWPAN provides IPv6 and UDP header compression (which
saves energy and bandwidth resources), fragmentation (which allows carrying 1280-
byte packets as required for IPv6 over the 127-byte maximum payload size of IEEE
802.15.4 frames), and an optimized version of the IPv6 neighbor discovery protocol
(which offers parameter and device discovery for constrained devices). Subsequently,
6Lo adaptation layers have reused 6LoWPAN components to support IPv6 over other
IoT technologies [2]. However, 6LoWPAN/6Lo-style of IPv6 adaptation is not suitable
for the extreme constraints of LPWANs. For this reason, the IETF LPWAN WG has
developed the SCHC adaptation layer, specifically designed for LPWAN technologies,
as explained in the next section.
At the network layer, a routing protocol is required for technologies that support the
mesh topology, such as IEEE 802.15.4 or Z-Wave. RPL is the routing protocol designed
by the IETF for IoT networks. RPL is optimized for data collection applications, while
minimizing IoT device memory and energy consumption. However, since LPWAN
technologies are based on the star topology, a routing protocol is not needed for
LPWANs, which simplifies the corresponding protocol stack.
Finally, CoAP is a lightweight request/response application-layer protocol, based on the
same architectural principles as HTTP, albeit with significantly lower complexity and
overhead (e.g. its base header, without options, has a size of 4 bytes). While CoAP was
originally designed to be transported over UDP (with optional end-to-end reliability and
congestion control supported by CoAP itself), issues with middleboxes, such as UDP-
unfriendly corporate firewalls, have led to the recent design and publication of a CoAP
specification over TCP [12]. However, the larger TCP header size and the connection
establishment overhead are inadequate for LPWANs, thus only UDP is assumed at the
transport layer for LPWANs.
7
Figure 1. a) 6LoWPAN/6Lo IPv6-based protocol stack, b) LPWAN IPv6-based protocol
stack
Figure 2. SCHC functionality overview: header compression and fragmentation
4. SCHC adaptation layer
This section describes the SCHC adaptation layer. SCHC is located between IPv6 and
an underlying LPWAN technology. SCHC comprises two sublayers: header
compression, and fragmentation (Fig. 2). The next two subsections present the main
design principles and features of these two sublayers, respectively.
4.1. Header compression
Without proper adaptation, IP-based protocols would introduce a large overhead over
LPWANs, since typical packet header sizes are significant when compared with the
extremely low LPWAN frame payload sizes. Several header compression mechanisms
have been developed in the past for efficient packet transmission over different
technologies. Work in this area has been carried out since the 90s, when Van Jacobson
BLE
RPL
IPv6
6Lo(WPAN)
G.9959
DULE
MS/TP
NFC
PLC
Other
802.15.4
UDP
CoAP
IPv6
UDP
CoAP
SCHC
LoRaWAN
Sigfox
NBIoT
15.4w
TCP
a) b)
Compressed
header
Fragmentation
header
IPv6
SCHC
Linklayer
(LPWANtechnology)
IPv6datagram
IPv6/UDP/CoAP
header
payload
frame
Fragmentation
Headercompression
8
proposed a mechanism based on exploiting intraflow packet header redundancy to
compress TCP/IP headers over slow serial links [13]. Subsequently, specialized header
compression mechanisms have been designed for the characteristics of different
constrained environments. The last such IP-based packet header compression efforts are
Robust Header Compression (ROHC) [14] and 6LoWPAN header compression. We
now review these two mechanisms, we highlight why they are not suitable for
LPWANs, and we then present SCHC header compression.
4.1.1. Use of ROHC over LPWANs
ROHC was designed to compress network- and transport-layer headers of multimedia
flows over low bitrate and high packet loss rate links, such as 3G cellular links. ROHC
exploits packet header redundancy within a packet flow. To this end, packets are
initially sent uncompressed, and subsequently only packet header differences are sent
(after being efficiently encoded). In ROHC, an IPv6/UDP header may typically be
compressed down to a minimum size of 3 bytes. Packet header information is
maintained in a context on both compressor and decompressor sides. ROHC defines
signaling that allows a decompressor to report to the other endpoint when context is
damaged, e.g. due to channel losses. Such event causes context desynchronization,
which is solved by transmitting an uncompressed header. However, this behavior is
unsuitable for the capacity constraints of LPWANs. Furthermore, ROHC has not been
defined to compress the CoAP header.
4.1.2. Use of 6LoWPAN header compression over LPWANs
6LoWPAN header compression was designed for efficient IPv6 (and UDP) packet
transmission over IEEE 802.15.4 networks. ROHC-style header compression was
considered too complex for the resource-constrained devices that characterize such
networks. In order to reduce context desynchronization problems, 6LoWPAN header
compression is partly based on stateless techniques. It leverages two 6LoWPAN
properties: i) the receiver ability to reconstruct some IPv6 header fields based on layer
two header fields, and ii) a statistical expectation that other IPv6 header fields will carry
values that are typical in 6LoWPAN. A bitmap at the start of the compressed header
format indicates what fields have been compressed and how they can be decompressed.
Stateless UDP header compression is also supported. Because stateless approaches
cannot compress global IPv6 addresses, a stateful, yet quasi-static mechanism based on
network-wide shared context is also used in 6LoWPAN. 6LoWPAN provides no
method to compress any application-layer protocol header (when 6LoWPAN was
designed, CoAP had not yet been created).
With 6LoWPAN header compression, a typical 48-byte IPv6/UDP header can be
compressed down to a 7-byte format. This result is suitable for the maximum payload
size in IEEE 802.15.4 frames, which is in the order of ~100 bytes. However, for an
underlying technology with a frame payload size of ~10 bytes, as occurs in many
LPWAN scenarios, a 6LoWPAN-compressed IPv6/UDP header would incur a too big
overhead.
9
4.1.3. SCHC header compression
SCHC header compression has been purposefully designed for LPWANs, and is
applicable to protocols such as IPv6, UDP and CoAP. SCHC relies on static context
shared between the compressor and the decompressor, which leverages a priori
knowledge of the traffic to be compressed. In fact, new applications are not expected to
be frequently installed on an LPWAN device over its lifetime. The static context
approach avoids the complexity of context resynchronization mechanisms and the need
for receiver feedback, while allowing ultralightweight header compression.
In SCHC, a context is defined as a set of Rules, each one provided with a Rule identifier
(Rule ID). A Rule comprises a set of descriptions of how each packet header field is to
be compressed (Fig. 3). A Rule may be used for the compression of one or more
protocol headers, e.g., an IPv6 header, the set of IPv6/UDP/CoAP headers, etc.
When a packet needs to be sent, the SCHC compressor first selects the Rule in the
context that best matches the header format and header field values of the packet being
handled. Then, the sender replaces the original packet header by the Rule ID
corresponding to this Rule. When a Rule ID cannot unambiguously represent a
complete packet header, a compression header residue is generated. The concatenation
of the Rule ID and the compression residue (if any) constitute the compressed header.
The Rule ID size is expected to be small, while still allowing the encoding of a large
number of Rules (e.g. a 1-byte Rule ID supports a Rule space of up to 256 different
Rules). When receiving a compressed packet, the decompressor reconstructs the original
packet header based on the received compressed header and on the stored context.
com
p
th
e
co
m
ac
Figure 3.
a
p
ressing I
P
e
correspo
n
m
ponents o
f
k
et header
w
a
) Example
P
v6 and U
D
n
din
g
p
ack
e
f
a field des
w
hose valu
e
of a SCH
C
P
header fi
e
t header fi
e
cription, th
e
e
s match th
no co
m
C
Rule (here
i
elds. Each
r
e
ld is to be
c
eir definiti
o
e TVs in
Ru
m
pression
r
after calle
d
r
ow in the
R
c
ompresse
d
o
n and rele
v
u
le 1 can b
e
r
esidue
d
Rule 1), d
e
R
ule is a de
s
d
or decom
p
v
ant details
.
fully comp
e
signed for
s
cription o
f
p
ressed. b)
T
.
An IPv6/
U
p
ressed,
y
ie
l
10
f
how
T
he
U
DP
l
ding
11
4.2. Fragmentation
IPv6 requires any underlying layer to support the transmission of packets of at least
1280 bytes. This measure was introduced in the IPv6 specification with the aim of
achieving high performance (e.g. throughput) for data transmission over a presumed
resource-rich Internet. However, LPWAN networking is fundamentally different, as it
has been designed for infrequent message exchanges of short-sized payloads. In fact,
some LPWAN technologies and scenarios offer an extremely short maximum frame
payload size, even down to ~10 bytes. Even after applying the highly efficient SCHC
header compression, many IPv6 packets will not fit into a single LPWAN frame.
Besides, neither LoRaWAN nor Sigfox mode supports fragmentation and reassembly
functionality. To overcome this issue, fragmentation is used at the SCHC adaptation
layer, in the form of a sublayer located below the header compression one (Fig. 2).
In order to provide a solution for fragmentation over LPWANs, 6LoWPAN
fragmentation was first considered as a possible basis. However, 6LoWPAN
fragmentation had been designed for IEEE 802.15.4 networks, which present significant
differences with LPWANs. First, IEEE 802.15.4 networks are often deployed as mesh
networks, which requires 6LoWPAN fragmentation to handle out-of-sequence fragment
delivery. Since LPWANs follow the star topology, fragmentation over LPWANs can
avoid the related complexity. Secondly, the maximum frame payload size in IEEE
802.15.4 is up to one order of magnitude greater than the LPWAN ones. Thus,
minimizing fragmentation header overhead is a considerably stronger requirement for
the latter. In fact, the 6LoWPAN fragmentation header yields an overhead of 4-5 bytes
per fragment, which is too high for ~10-byte LPWAN maximum frame payload sizes,
as it would exacerbate frame encapsulation overhead. Leveraging the star topology of
LPWANs, and using short-sized fragment identifiers, SCHC fragmentation supports a
variety of options and mechanisms with even a single-byte fragmentation header size.
Finally, a singular characteristic of LPWANs is the severe, even extreme, message rate
limitations in some technologies. Under such circumstances, each LPWAN frame
transmission becomes very expensive. However, any fragment loss (e.g. due to wireless
link corruption) would lead to unsuccessful delivery of the whole higher layer packet
being carried. In LPWANs, amortizing the scarce transmission resources consumed by
retransmitting only the lost fragments may be desirable. However, 6LoWPAN
fragmentation does not offer fragment retransmission, as of today. In order to provide
flexibility to satisfy the heterogeneous needs of different LPWAN technologies or
scenarios, SCHC fragmentation offers three fragment delivery reliability modes: No-
ACK, ACK-Always, and ACK-on-Error.
No-ACK is a best-effort mode whereby fragment retries are not supported, and the
fragment receiver does not inform the fragment sender regarding the transmission
outcome. Both ACK-Always and ACK-on-Error provide selective fragment
retransmission mechanisms (i.e. data integrity), based on Acknowledgments (ACKs)
issued by the fragment receiver. The fragment receiver sends an ACK only after a
window of fragments (i.e. a subset of the fragments carrying an IPv6 packet) has been
12
transmitted. An ACK reports whether each fragment of a window has been received or
not. For efficiency, this information is encoded by means of a bitmap, where the n-th
bitmap bit indicates whether the corresponding n-th fragment has been received or not.
In ACK-Always, the fragment receiver unconditionally sends an ACK after a window
of fragments. In contrast, in ACK-on-Error, the ACK is only sent when at least one
fragment in the window has been lost, except in the last window, where an ACK is
always sent to indicate whether the fragmented packet transmission has been successful.
In order to avoid low performance due to ACK losses, in ACK-on-Error, upon reception
of the last fragment of a packet, the receiver may send ACKs reporting missing
fragments from the whole packet. While the frequent feedback in ACK-Always allows
early detection of severe link problems, ACK-on-Error reduces message overhead.
Even though these fragmentation mechanisms have been designed to transport long
IPv6 packets, the mechanisms can equally be applied to non-IP data messages.
5. Performance evaluation
We next evaluate SCHC, focusing on both header compression and fragmentation
mechanisms.
5.1. Header compression
Fig. 4 illustrates the header compression performance of ROHC, 6LoWPAN, and
SCHC, when applied to an IPv6/UDP/CoAP header. For the sake of comparison, an
uncompressed header is also included in the figure. We assume the header uses IPv6
global addresses.
The main drawback of ROHC is that packets intended for context initialization or
resynchronization are sent uncompressed. In LPWANs, this would represent low
performance, further degraded by the need to apply fragmentation to such packets when
the underlying LPWAN technology maximum frame payload size is ~10 bytes. In
addition, such packets need to carry an additional ROHC header to describe their
content, yielding a negative compression gain for them. In addition, CoAP compression
is not supported by ROHC.
6LoWPAN-style header compression can reduce the size of the IPv6/UDP/CoAP
header by a factor close to 5. However, the resulting header size is still too large for the
frame payload sizes in many LPWAN scenarios.
In contrast with ROHC and 6LoWPAN, SCHC can yield a 3-byte IPv6/UDP/CoAP
compressed header, which is a much better fit for LPWANs. This result can be obtained
for a Rule optimized for a specific packet header (e.g. Rule 1 in Fig. 3), assuming a
1-byte Rule ID. For comparison purposes, Fig. 4 also includes the case of SCHC header
compression where the Rule used produces a 2-byte compression residue.
13
Figure 4. Comparison of header compression mechanisms applied to an
IPv6/UDP/CoAP header
5.2. Fragmentation
We next evaluate the performance of the three SCHC fragmentation modes (No-ACK,
ACK-Always, and ACK-on-Error), in terms of the average number of fragment
transmission attempts and the number of ACKs, for the range of packet sizes required
by IPv6, and for different Frame Loss Rate (FLR) values. We assume a 10-byte
maximum frame payload size, uncorrelated frame losses, and equal uplink and
downlink FLR values. For ACK-Always and ACK-on-Error, we also study the impact
of the window size. In order to investigate the upper bound of all performance
parameters considered, an infinite number of retries is used. Results are shown in Fig. 5.
Since No-ACK neither supports fragment retries nor receiver feedback, it yields the
lowest amount of transmitted frames, at the expense of low reliability. For large-sized or
critical-data packets, ACK-based modes are recommended. While ACK-Always
exhibits the highest overhead, both in number of fragment transmission attempts and in
number of ACKs, it yields the highest Packet Delivery Ratio (PDR). ACK-on-Error
behaves minimalistically, by sending ACKs only when fragments are lost (except for
the mandatory ACK sent at the end of the packet transmission).
For ACK-based modes, increasing the window size (W) decreases the number of ACKs.
However, it may also increase the fragment identifier size, and in turn, the fragment
header size (F). Fig. 5.a) depicts how F=2 tends to increase the number of fragments by
~12%.
0
10
20
30
40
50
60
No
compression
RoHC
(init./resync.)
RoHC
(lower
bound)
6LoWPAN
(lower
bound)
SCHC
(2byteresid.)
SCHC
(lower
bound)
IPv6/UDP/CoAPheadersize(bytes)
Headercompressionmechanism
CoAP
UDP
IPv6
14
Figure 5. Performance evaluation of fragmentation modes and settings: a) average
number of fragment transmissions, b) average number of ACKs
6. Open issues
At the time of writing, the design and standardization of SCHC is reaching completion.
However, areas of additional functionality development and potential performance
improvement have already been identified. This section reviews the main SCHC-related
open research issues and standardization items.
6.1. Optimizing SCHC for each LPWAN technology
SCHC has been designed with the aim to satisfy common requirements of LPWAN
technologies. Intentionally, SCHC offers generic functionality without specifying which
mechanisms (e.g. fragmentation modes) or parameter settings (e.g. Rule ID size,
fragmentation window size, etc.) need to be used over each specific LPWAN
technology. This approach allows optimizing SCHC for each LPWAN technology, but
requires specifications defining how SCHC is used over a given LPWAN technology.
Currently, initial draft versions of such specifications have already been produced for
0
20
40
60
80
100
120
140
160
180
200
0 200 400 600 800 1000 1200
Numberoffragments
Packetsize(bytes)
ACKAlways,F=2bytes,FLR=0.1
Anymode,F=2bytes,FLR=0
Anymode,F=1byte,FLR=0
0
5
10
15
20
25
30
35
0 200 400 600 800 1000 1200
NumberofACKs
Packetsize(bytes)
ACKAlways,W=7,FLR=0.1
ACKAlways,W=7,FLR=0
ACKAlways,W=15,FLR=0
ACKonError,W=7,FLR=0.1
ACKonError,W=15,FLR=0.1
ACKonError,anyW,FLR=0
a)
b)
15
LoRaWAN, Sigfox, NB-IoT and IEEE 802.15.4w. Nevertheless, design and research
work are still needed to complete, validate and evaluate the performance of SCHC over
each specific LPWAN technology.
6.2. Context provisioning
A currently open question on SCHC header compression is how the context can be
provided to the compressor and decompressor endpoints. Different alternatives include
using: i) preinstalled context, ii) out-of-band means, and iii) an in-band provisioning
protocol. Determining a suitable solution requires considering the crucial trade-off
between configuration flexibility and bandwidth demand, as well as the capacity of the
LPWAN technology in use.
6.3. Header compression for other protocols
SCHC header compression is based on a generic mechanism that needs to be applied in
a specific way to each target protocol. At the time of writing, SCHC header
compression has only been defined for IPv6, UDP and CoAP. However, further
protocols may be used in the future in LPWAN scenarios, and may therefore benefit
from SCHC header compression.
6.4. Packet-mode fragmentation
In the reliable fragment delivery modes offered by SCHC, an ACK is sent by the
fragment receiver (always or conditionally) after the transmission of a window of
fragments. An ideal reliable fragment delivery mechanism would be packet-oriented,
i.e., a single ACK would report on the delivery success of all the fragments that carry an
IP or non-IP data packet. However, fitting the fragment delivery report for a large
packet in a single ACK may be challenging, given the extreme frame payload size
constraints in some LPWAN technologies and scenarios. Different encoding techniques
may be used at the receiver to report any lost fragments. Alternatives to the bitmap used
in SCHC include using a list of lost fragment identifiers, and delta encoding applied to
the identifiers of lost fragments. The efficiency of each technique depends on the frame
error pattern. Determining the most suitable technique for each scenario needs to be
investigated.
6.5. Security
LoRaWAN, Sigfox and NB-IoT offer encryption and authentication services. However,
end-to-end security may also be needed in some IPv6-based LPWANs. There exist
different approaches for securing CoAP, including use of Datagram Transport Layer
Security (DTLS) and Object Security for Constrained RESTful Environments
(OSCORE). Only the latter protects CoAP messages across intermediary nodes such as
proxies, by transforming the messages into self-contained data structures with a header,
a potentially encrypted payload, and an authentication field. Currently, support for
compressing the OSCORE header by using SCHC is being developed.
16
Privacy is an open issue, as detection of (even encrypted) messages triggered by sensors
detecting certain events may be exploited. Mitigation techniques (e.g. sending fake
messages) are challenged by the capacity constraints of LPWAN technologies. The
latter also pose a problem for key management, as documents such as certificates are
usually bulky, and solutions are also needed in this space.
7. Conclusions
SCHC enables ultralightweight IPv6 support for LPWANs by providing specifically
designed header compression and fragmentation functionality. Developed under a
generic and flexible approach, SCHC can be configured for optimized operation over
various underlying technologies (e.g. LoRaWAN, Sigfox, NB-IoT or IEEE 802.15.4w).
SCHC is expected to become a fundamental contributor to the expansion of the Internet
(of Things).
Acknowledgments
Carles Gomez has been partially supported by ERDF and the Spanish Government
through project TEC2016-79988-P, AEI/FEDER, UE.
References
[1] U. Raza, P. Kulkarni, M. Sooriyabandara, “Low Power Wide Area Networks:
An Overview”, IEEE Communications Surveys & Tutorials, Vol. 19, Issue 2,
January 2017, pp. 855-873.
[2] C. Gomez, J. Paradells, C. Bormann, J. Crowcroft, "From 6LoWPAN to 6Lo:
Expanding the Universe of IPv6-Supported Technologies for the Internet of
Things", IEEE Communications Magazine, Vol. 55, Issue 12, pp. 148-155,
December 2017.
[3] P. Thubert, A. Pelov, S. Krishnan, "Low-Power Wide-Area Networks at the
IETF", IEEE Communications Standards, Vol. 1, Issue 1, March 2017, pp. 76-
79.
[4] A. Minaburo, L. Toutain, C. Gomez, D. Barthel, J.C. Zuniga, “Static Context
Header Compression (SCHC) and fragmentation for LPWAN,
application to UDP/IPv6”, draft-ietf-lpwan-ipv6-static-context-hc-21, Jul. 2019.
(Work in progress, available at https://tools.ietf.org/html/draft-ietf-lpwan-ipv6-
static-context-hc-21, accessed on August 22nd 2019.)
[5] J. Haxhibeqiri, E. De Poorter, I. Moerman, J. Hoebeke, “A Survey of LoRaWAN
for IoT: From Technology to Application”, Sensors, Vol. 18, 3995, November
2018.
[6] C. Gomez, J.C. Veras, R. Vidal, L. Casals, J. Paradells, “A Sigfox Energy
Consumption Model”, Sensors, Vol. 19, 681, February 2019.
[7] Y.-P. E. Wang, X. Lin, A. Adhikary, A. Grövlen, Y. Sui, Y. Blankenship,
J. Bergman, H.S. Razaghi, “A Primer on 3GPP Narrowband Internet of Things”,
IEEE Communications Magazine, Vol. 55, Issue 3, March 2017, pp. 117-123.
17
[8] L. Feltrin, G. Tsoukaneri, M. Condoluci, C. Buratti, T. Mahmoodi,
M. Dohler, R. Verdone, “Narrowband IoT: A Survey on Downlink and Uplink
Perspectives”, IEEE Wireless Communications, Vol. 26, Issue 1, February 2019,
pp. 78 – 86.
[9] H.-S. Kim, J. Ko. D.E. Culler, J. Paek, “Challenging the IPv6 Routing Protocol
for Low-Power and Lossy Networks (RPL): A Survey”, IEEE Communications
Surveys & Tutorials, Vol. 19, Issue 4, September 2017, pp. 2502 – 2525.
[10] C. Bormann, A.P. Castellani, Z. Shelby, “CoAP: An Application Protocol for
Billions of Tiny Internet Nodes”, IEEE Internet Computing, Vol. 16, Issue 2,
March 2012, pp. 62-67.
[11] Z. Shelby, C. Bormann, “6LoWPAN: The Wireless Embedded Internet”, Vol.
43. John Wiley & Sons, August 2011.
[12] C. Bormann, S. Lemay, H. Tschofenig, K. Hartke, B. Silverajan, B. Raymor,
“CoAP (Constrained Application Protocol) over TCP, TLS, and WebSockets”,
RFC 8323, February 2018. (Available at https://tools.ietf.org/html/rfc8323,
accessed on August 22nd 2019.)
[13] V. Jacobson, “Compressing TCP/IP Headers for Low-Speed Serial Links”,
RFC 1144, February 1990. (Available at https://tools.ietf.org/html/rfc1144,
accessed on August 22nd 2019.)
[14] K. Sandlund, G. Pelletier, L-E. Jonsson, “The RObust Header Compression
(ROHC) Framework”, RFC 5795, March 2010. (Available at
https://tools.ietf.org/html/rfc5795, accessed on August 22nd 2019.)
... 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]. ...
... 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. ...
... 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. ...
Article
Full-text available
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 PowerWide 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.
... We instead propose to reduce the packet size by applying a compression function, thus limiting the need for fragmentation. The compression function is based on the Static Context Header Compression (SCHC, [26,27]) framework and executed both on the Client and on the Proxy. SCHC compression relies on a common static context, i.e., a set of rules, stored both in the Proxy and in the Client. ...
... The former case occurs when the field value is known and hence it is not sent, or when the field value belongs to a known list of values and hence the index of the list is sent. In the latter case, instead, the compression residue is the bits resulting from applying the CDA to the field, preceded by the size of the compression residue itself, encoded as specified in [27]. If a variable-length field is not present in the packet header being compressed, a size 0 must be specified to indicate its absence. ...
... We refer the reader to [26][27][28] for further details on SCHC. ...
Article
Full-text available
The Internet of Things (IoT) brings Internet connectivity to devices and everyday objects. This huge volume of connected devices has to be managed taking into account the severe energy, memory, processing, and communication constraints of IoT devices and networks. In this context, the OMA LightweightM2M (LWM2M) protocol is designed for remote management of constrained devices, and related service enablement, through a management server usually deployed in a distant cloud data center. Following the Edge Computing paradigm, we propose in this work the introduction of a LWM2M Proxy that is deployed at the network edge, in between IoT devices and management servers. On one hand, the LWM2M Proxy improves various LWM2M management procedures whereas, on the other hand, it enables the support of QoS-aware services provided by IoT devices by allowing the implementation of advanced policies to efficiently use network, computing, and storage (i.e., cache) resources at the edge, thus providing benefits in terms of reduced and more predictable end-to-end latency. We evaluate the proposed solution both by simulation and experimentally, showing that it can strongly improve the LWM2M performance and the QoS of the system.
... Furthermore, LPWAN technologies were designed without native IP support, which limits Internet connectivity. In order to enable and optimize IPv6 and other applications support for LPWAN devices, the Internet Engineering Task Force (IETF) LPWAN working group (WG) has recently standardized the Static Context Header Compression and fragmentation (SCHC) framework [2], [3]. ...
... 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. ...
... ACKon-Error also reduces the number of ACKs when compared with the other reliable SCHC fragmentation mode (i.e. ACK-Always) [3], [22]. This is suitable considering that in Sigfox the downlink message rate is very limited (see section III-B). ...
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.
... The main product of the IETF LPWAN WG is the specification of an adaptation layer framework, called Static Context Header Compression and Fragmentation (SCHC) [10], [11]. The need for this solution is justified by the fact that prior efforts to support IPv6 over low-power wireless technologies, such as 6LoWPAN or 6Lo, yield a too high overhead in the light of the severe constraints of LPWAN technologies [4]. ...
... In this section, we review research works that focused on SCHC and fragmentation over LPWANs. Some of them investigated both SCHC compression and fragmentation mechanisms [11], [13]- [19], while others focused on fragmentation functionality alone [20], [21]. ...
... The authors in [11] provided an overview of SCHC. As a future work item, they proposed a reliable fragment delivery mechanism whereby a single ACK would report on the delivery success or failure of all the fragments that carry a large packet. ...
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.
... ONECompression (IPHC) techniques-LOWPAN_IPHC and LOWPAN_NHC, were used to compress the IPv6 header as well as the UDP header. The maximum transmission unit (MTU) of the IEEE 802.15.4 is 127 bytes of which 25 bytes is used for the MAC frame header, which leaves the payload with 102 bytes[31]. Of these 102 bytes, link-layer security (LLSEC) uses 21 bytes, IPv6 header uses 40 bytes and user datagram protocol (UDP) header uses 8 bytes. ...
Article
Full-text available
Routing Protocol for Low-power and Lossy Networks (RPL), the de facto standard routing protocol for the Internet of Things (IoT) administers the smooth transportation of data packets across the Wireless Sensor Network (WSN). However, the mechanism fails to address the heterogeneous nature of data packets traversing the network, as these packets may carry different classes of data with different priority statuses, some real-time (time-sensitive) while others non-real-time (delay-tolerant). The standard Objective Functions (OFs), used by RPL to create routing paths, treat all classes of data as the same, this practice is not only inefficient but results in poor network performance. In this article, the Prioritized Shortest Path Computation Mechanism (PSPCM) is proposed to resolve the data prioritization of heterogeneous data and inefficient power management issues. The mechanism prioritizes heterogeneous data streaming through the network into various priority classes, based on the priority conveyed by the data. The PSPCM mechanism routes the data through the shortest and power-efficient path from the source to the destination node. PSPCM generates routing paths that exactly meet the need of the prioritized data. It outperformed related mechanisms with an average of 91.49% PDR, and average power consumption of 1.37mW which translates to better battery saving and prolonged operational lifetime while accommodating data with varying priorities.
... Most IoT technologies rely on some form of terrestrial infrastructure, with a coverage range that may span from a few meters up to several kilometers, depending on the technology [2]. However, when such infrastructure is not available, satellite communication technologies provide an alternative connectivity solution for IoT devices. ...
Article
Full-text available
Most Internet of Things (IoT) communication technologies rely on terrestrial network infrastructure. When such infrastructure is not available or does not provide sufficient coverage, satellite communication offers an alternative IoT connectivity solution. Satellite-enabled IoT devices are typically powered by a limited energy source. However, as of this writing, and to our best knowledge, the energy performance of satellite IoT technology has not been investigated. In this paper, we model and evaluate the energy performance of Iridium satellite technology for IoT devices. Our work is based on real hardware measurements. We provide average current consumption, device lifetime, and energy cost of data delivery results as a function of different parameters. Results show, among others, that an Iridium-enabled IoT device, running on a 2400 mAh battery and sending a 100-byte message every 100 min, may achieve a lifetime of 0.95 years. However, Iridium device energy performance decreases significantly with message rate.
... Decreased consumption is paid by latency, resulting in engineering compromises [14]. Another approach is the selective retransmission of fragments of the entire message [15], which might also comprise aggregated packets [16,17]. Packet aggregation is a technique aiming for energy efficiency improvement and quality of service (QoS) enhancement, especially in low-power communications [16]. ...
Article
Full-text available
This paper proposes a code defined on a finite ring ℤpM, where pM = 2m−1 is a Mersenne prime, and m is a binary size of ring elements. The code is based on a splitting sequence (splitting set) S, defined for the given multiplier set ℰ={±20, ±21,…, ±2m−1}. The elements of ℰ correspond to the weights of binary error patterns that can be corrected, with the bidirectional single-bit error being the representative that occurs the most. The splitting set splits the code-word into sub-words, which inspired the name splitting code. Each sub-word, provided with auxiliary control symbols that are a byproduct of the coding procedure, corrects a single symbol error. The code can be defined, with some constraints, for general Mersenne numbers as well, while the multiplier set can be adjusted for adjacent binary errors correction. The application proposed for this code is a hybrid three-stage incremental ARQ procedure that transmits the code-word in the first stage, auxiliary control symbols in the second stage, and retransmits the sub-words detected as incorrect in the third stage. At each stage, error correction can be turned on or off, keeping both the retransmission rate and residual error rate at a low level.
... However, the advantages of LPWAN technologies come at the expense of challenging constraints in terms of message sizes, bit rates, and message rates. These unique features of LPWAN technologies have attracted the attention of industry, academia, and standards development organizations [1][2][3][4]. ...
Article
Full-text available
LoRaWAN has become a popular technology for the Internet of Things (IoT) device connectivity. One of the expected properties of LoRaWAN is high network scalability. However, LoRaWAN network performance may be compromised when even a relatively small number of devices use link-layer reliability. After failed frame delivery, such devices typically tend to reduce their physical layer bit rate by increasing their spreading factor (SF). This reaction increases channel utilization, which may further degrade network performance, even into congestion collapse. When this problem arises, all the devices performing reliable frame transmission end up using SF12 (i.e., the highest SF in LoRaWAN). In this paper, we identify and characterize the described network condition, which we call the SF12 Well, in a range of scenarios and by means of extensive simulations. The results show that by using alternative SF-management techniques it is possible to avoid the problem, while achieving a packet delivery ratio increase of up to a factor of 4.7.
Article
Internet of Things (IoT) has been a hot topic in both academia and industry for the last few years. There are many possible applications, in fields as smart cities, home automation, smart buildings, agriculture, automated metering, logistic, industrial automation, among others. Such a wide range of applications resulted in various technological solutions in order to enable Machine-to-Machine (M2M) communications, in which we highlight those for wide area networks. In that sense, two widely used sub-GHz protocols for Low Power Wide Area (LPWA) communications are: Long Range (LoRa), using the upper layers defined by Long Range Wide Area Network (LoRaWAN); and IEEE 802.15.4g, using the upper layers defined by IPv6 over the Time-Slotted Channel Hopping (TSCH) mode of IEEE 802.15.4e (6TiSCH). While LoRaWAN is a well-known and widespread protocol, 6TiSCH offers IPv6 connectivity to LPWA networks and is used in important standards such as Wireless Smart Ubiquitous Network (Wi-SUN). This paper aims at determining how well each protocol scales, analyzing different aspects such as packet loss, delay, and the maximum number of nodes per square area. In order to achieve such results, computer simulations are performed using open-source simulators. The obtained results demonstrate that the best scalability depends on which scenarios are considered. For scenarios with multiple gateways requiring low latency or low packet transmission rates, LoRaWAN demonstrates better results. However, in scenarios with high packet transmission rates and where the latency is not a major concern, 6TiSCH is more appropriate. Moreover, even in the best case, the latency associated with the LoRaWAN technology may be considerably smaller than associated with 6TiSCH. Such novelty results are obtained in a fair and realistic way and, noting that both technologies could be used to build LPWA networks, it can help system designers to decide between the two technologies.
Chapter
This chapter introduces some underlying core technologies of Industry 4.0 and Intelligent Manufacturing. It also introduces cloud computing, including its essentials, service models, and deployment models, as well as the concept of cloud manufacturing. A smart factory could adopt Internet of Things as its data collection and communication platform and use cloud computing which has abundant computing resources or edge computing which is near the data sources to perform big data analytics on a large amount of production‐related data. As cloud computing services became mature, several service models were introduced, including Infrastructure as a Service, Platform as a Service, and Software as a Service. The chapter presents big data infrastructure, including the application demands, and core software stack components. It also present two big data infrastructural services, that is, Hadoop data service and distributed R language computing service, based on Hadoop for a semiconductor manufacturing foundry in Taiwan, ROC.
Article
Full-text available
Sigfox has become one of the main Low-Power Wide Area Network (LPWAN) technologies, as it has attracted the attention of the industry, academy and standards development organizations in recent years. Sigfox devices, such as sensors or actuators, are expected to run on limited energy sources; therefore, it is crucial to investigate the energy consumption of Sigfox. However, the literature has only focused on this topic to a very limited extent. This paper presents an analytical model that characterizes device current consumption, device lifetime and energy cost of data delivery with Sigfox. In order to capture a realistic behavior, the model has been derived from measurements carried out on a real Sigfox hardware module. The model allows quantifying the impact of relevant Sigfox parameters and mechanisms, as well as frame losses, on Sigfox device energy performance. Among others, evaluation results show that the considered Sigfox device, powered by a 2400 mAh battery, can achieve a theoretical lifetime of 1.5 or 2.5 years while sending one message every 10 min at 100 bit/s or 600 bit/s, respectively, and an asymptotic lifetime of 14.6 years as the message transmission rate decreases.
Article
Full-text available
LoRaWAN is one of the low power wide area network (LPWAN) technologies that have received significant attention by the research community in the recent years. It offers low-power, low-data rate communication over a wide range of covered area. In the past years, the number of publications regarding LoRa and LoRaWAN has grown tremendously. This paper provides an overview of research work that has been published from 2015 to September 2018 and that is accessible via Google Scholar and IEEE Explore databases. First, a detailed description of the technology is given, including existing security and reliability mechanisms. This literature overview is structured by categorizing papers according to the following topics: (i) physical layer aspects; (ii) network layer aspects; (iii) possible improvements; and (iv) extensions to the standard. Finally, a strengths, weaknesses, opportunities and threats (SWOT) analysis is presented along with the challenges that LoRa and LoRaWAN still face.
Article
Full-text available
RPL is the IPv6 routing protocol for low-power and lossy networks (LLNs), standardized by IETF in 2012 as RFC6550. Specifically, RPL is designed to be a simple and inter-operable networking protocol for resource-constrained devices in industrial, home, and urban environments, intended to support the vision of the Internet of Things (IoT) with thousands of devices interconnected through multihop mesh networks. More than four-years have passed since the standardization of RPL, and we believe that it is time to examine and understand its current state. In this article, we review the history of research efforts in RPL; what aspects have been (and have not been) investigated and evaluated, how they have been studied, what was (and was not) implemented, and what remains for future investigation. We reviewed 97+ RPL-related academic research papers published by major academic publishers and present a topic-oriented survey for these research efforts. Our survey shows that only 40.2% of the papers evaluate RPL through experiments using implementations on real embedded devices, ContikiOS and TinyOS are the two most popular implementations (92.3%), and TelosB was the most frequently used hardware platform (69%) on testbeds that have average and median size of 49.4 and 30.5 nodes, respectively. Furthermore, unfortunately, despite it being approximately four years since its initial standardization, we are yet to see wide adoption of RPL as part of real-world systems and applications. We present our observations on the reasons behind this and suggest directions on which RPL should evolve.
Article
Full-text available
Leveraging 6LoWPAN, the IETF 6Lo working group has targeted adaptation of IPv6 over a new generation of communication technologies for the IoT. These comprise Bluetooth LE, ITU-T G.9959, DECT ULE, MS/TP, NFC, IEEE 1901.2, and IEEE 802.11ah. This paper comprehensively analyzes the 6Lo technologies and adaptation layers, giving the motivation for critical design decisions, highlighting crucial aspects for performance, and presenting main challenges.
Article
Narrowband-IoT (NB-IoT) is a radio access technology standardized by the 3GPP to support a large set of use cases for massive machine-type communications. Compared to human-oriented 4G technologies, NB-IoT has key design features in terms of increased coverage, enhanced power saving, and a reduced set of functionalities. These features allow for connectivity of devices in challenging positions, enabling long battery life and reducing device complexity. This article provides a detailed overview on NB-IoT, together with analysis and performance evaluation of the technology. Both uplink and downlink directions are presented, including recent updates on the support of multicast transmissions. The article summarizes the possible configurations of NB-IoT, discusses the procedures for data transmission and reception, and analyzes aspects such as latency and resource occupation. We present a performance evaluation focusing on both uplink and downlink, with the aim to understand the channel occupancy of NB-IoT for different real-life IoT use cases and cell deployments. Further analysis focuses on the impact of various radio access parameters on the capacity of NB-IoT. Finally, results focusing on a new use case for NB-IoT (i.e., firmware update of a group of devices) are presented in the form of a comparison between unicast and multicast transmission modes.
Article
A new breed of wireless technologies has emerged under the generic name of low-power, wide-area (LPWA), with a number of common characteristics that make these technologies uniquely suitable for Internet of Things (IoT) applications. These common characteristics include a power-optimized radio network, a simplified network topology, frame sizes in the order of tens of bytes transmitted a few times per day at ultralow speeds, and a mostly upstream transmission pattern that allows the devices to spend most of their time in low-energy deep-sleep mode. These characteristics enable a range of several kilometers and long battery lifetimes, possibly ten years of operation on a single coin-cell. It also enables simple and scalable deploymen
Article
Low Power Wide Area (LPWA) networks are attracting a lot of attention primarily because of their ability to offer affordable connectivity to the low-power devices distributed over very large geographical areas. In realizing the vision of the Internet of Things (IoT), LPWA technologies complement and sometimes supersede the conventional cellular and short range wireless technologies in performance for various emerging smart city and machine-to-machine (M2M) applications. This review paper presents the design goals and the techniques, which different LPWA technologies exploit to offer wide-area coverage to low-power devices at the expense of low data rates. We survey several emerging LPWA technologies and the standardization activities carried out by different standards development organizations (e.g., IEEE, IETF, 3GPP, ETSI) as well as the industrial consortia built around individual LPWA technologies (e.g., LORa Alliance,WEIGHTLESS-SIG, and DASH7 Alliance). We further note that LPWA technologies adopt similar approaches, thus sharing similar limitations and challenges. This paper expands on these research challenges and identifies potential directions to address them. While the proprietary LPWA technologies are already hitting the market with large nationwide roll-outs, this paper encourages an active engagement of the research community in solving problems that will shape the connectivity of tens of billions of devices in the next decade.
Article
Narrowband Internet of Things (NB-IoT) is a new cellular technology introduced in 3GPP Release 13 for providing wide-area coverage for the Internet of Things (IoT). This article provides an overview of the air interface of NB-IoT. We describe how NB-IoT addresses key IoT requirements such as deployment flexibility, low device complexity, long battery life time, support of massive number of devices in a cell, and significant coverage extension beyond existing cellular technologies. We also share the various design rationales during the standardization of NB-IoT in Release 13 and point out several open areas for future evolution of NB-IoT.
Article
"It is stunningly thorough and takes readers meticulously through the design, con?guration and operation of IPv6-based, low-power, potentially mobile radio-based networking." Vint Cerf, Vice President and Chief Internet Evangelist, Google This book provides a complete overview of IPv6 over Low Power Wireless Area Network (6LoWPAN) technology In this book, the authors provide an overview of the 6LoWPAN family of standards, architecture, and related wireless and Internet technology. Starting with an overview of the IPv6 'Internet of Things', readers are offered an insight into how these technologies fit together into a complete architecture. The 6LoWPAN format and related standards are then covered in detail. In addition, the authors discuss the building and operation of 6LoWPAN networks, including bootstrapping, routing, security, Internet ingration, mobility and application protocols. Furthermore, implementation aspects of 6LoWPAN are covered. Key Features: Demonstrates how the 6LoWPAN standard makes the latest Internet protocols available to even the most minimal embedded devices over low-rate wireless networks Provides an overview of the 6LoWPAN standard, architecture and related wireless and Internet technology, and explains the 6LoWPAN protocol format in detail Details operational topics such as bootstrapping, routing, security, Internet integration, mobility and application protocols Written by expert authors with vast experience in the field (industrial and academic) Includes an accompanying website containing tutorial slides, course material and open-source code with examples (http://6lowpan.net ) 6LoWPAN: The Wireless Embedded Internet is an invaluable reference for professionals working in fields such as telecommunications, control, and embedded systems. Advanced students and teachers in electrical engineering, information technology and computer science will also find this book useful.
Article
The Constrained Application Protocol (CoAP) is a transfer protocol for constrained nodes and networks, such as those that will form the Internet of Things. Much like its older and heavier cousin HTTP, CoAP uses the REST architectural style. Based on UDP and unencumbered by historical baggage, however, CoAP aims to achieve its modest goals with considerably less complexity.