Implementation_and_Analysis_of_the_6LoWPAN.pdf

Implementation and Analysis of the 6LoWPAN for
the Internet of Things Applications: Future Networks
Khalid Mohamed
Department of Electrical & Electronics Engineering
International University of Africa
Khartoum, Sudan
Kha.omer@hotmail.com
Ate Abdelrahim
Department of Computer Engineering
Al-Neelain University
Khartoum, Sudan
wadalroob@gmail.com
Abstract— Internet of things (IoT) is a new networks paradigm,
that billions of internet things can be connected at anytime and
anyplace, and it’s expected to include billions of smart devices,
these devices characterized by small memory, low transfer rate
and low energy, internet protocol version 6 (IPv6) it was
introduced to offer huge address space, however it doesn’t
compatible with capabilities of the constrained device, therefore
IPv6 over low power Wireless Personal Area network
(6LoWPAN) adaptation layer was introduced to carry IPv6
datagram over constrained links, in this paper, we first provide
intensive analysis of 6LoWPAN specifications that includes IPv6
encapsulation, frame format, 6LoWPAN header compression,
fragmentation of the payload datagram and encoding of user
datagram protocol UDP, in addition to the implementation of the
6LoWPAN in the NS-3 using different payload size, then we
evaluate the following metrics throughput, packets loss, delay
and jitter, the results showed that the fragmentation effects the
network throughput and increase the delay and the number of
lost packets, moreover, when payload fit within a single frame the
network show better performance , there are no packets lost as
well as minimum values of the delay and the jitter, and in the
two cases 6LoWPAN shows reasonable packets delivery ratio.
Keywords-IoT; IPv6; 6LoWPAN; encapsulation;
fragmentation; compression.
I. INTRODUCTION
The IPv6 over low power Wireless Personal Area networks
(6LoWPAN) adaptation layer was introduced to carry internet
protocol version 6 (IPv6) datagram over constrained links, that
are expected in internet of things (IoT) application such as
wireless sensor networks, which it has distinctly limited
bandwidth, energy resources and memory requirements
aspect[1], [7] .
The internet has benefited from well designed internet
protocol version 4 (IPv4) [14], however the capacity of the
IPv4 about 4 billion addresses(fewer in practice), progressively
growing allocation of public address started to cause concerns,
leading to many allocation policies for user to share public
internet addresses with others, the opening of the internet for
commercial use prompted the IETF to design a new protocol
with larger addressing standardized as internet protocol
version 6 (IPv6) [3], the IPv6 protocol is based on an
addressing scheme of 2^128 addresses are available , and now
it’s globally deployed, consequently IPv6 overcome the
scarcity issues of IPv4 and catering thereby for the exploding
needs of the IoT, the emerging of the IPv6 with highly scalable
addressing led to the emergence of IoT requirements as well
as several IPv6-related standards emerged such as 6LoWPAN
for constrained nodes and networks [15].
6LoWPAN is a developing standard from the Internet
Engineering Task Force (IETF) to easily fit into 32K flash
memory parts (much smaller than Zigbee or other protocols)
and it was designed from the start to be used in small / pico
sensor networks, the fears around the 40 byte IPv6 header can
be allayed by implementing a unique stateless header
compression mechanism that allows the transmission of IPv6
packets in as few as 6 bytes, the working group has written a
problem statement document which defines the specific header
encoding and header compression mechanisms used in
adapting IPv6 into 802.15.4 frames [9].
Low-Rate Wireless Personal Area networks (LR-WPAN)
provides for ultra low complexity, cost, and low data rate
wireless connectivity among inexpensive devices with limited
power consumption and relaxed throughput requirements, the
raw data rate is high enough (250 kb/s) to satisfy a set of
applications but is also scalable down to the needs of sensor
and automation needs (20 kb/s or below) for wireless
communications, wireless personal area networks (WPANs)
are used to convey information over relatively short distances.
Unlike wireless local area networks (WLANs), WPANs has
may features like ease of installation, reliable data transfer,
extremely low cost, and a reasonable battery life, while
maintaining a simple and flexible protocol as well as
inexpensive solutions to be implemented for a wide range of
devices [4].
Today most of the internet traffic carry at the application
layer by Hypertext Transfer Protocol (HTTP) over
Transmission Control Protocol (TCP), however TCP doesn’t
scale well on constrained devices, [6] reveals the impact of the
flow and congestion control of the TCP in the internet found
that it provides reliable stream communication between TCP
hosts by implementing different congestion control algorithms,
however in the IoT environment the devices has limited
bandwidth and low power as well as small memory properties,
therefore with this IoT restrictions and TCP operating
procedures TCP can’t perform well due to overhead , buffering
at sender and receiver and flow control mechanism.
International Journal of Computer Science and Information Security (IJCSIS),
Vol. 17, No. 4, April 2019
91 https://sites.google.com/site/ijcsis/
ISSN 1947-5500

The main strength of the IoT idea is the high impact it will
have on several aspects of everyday-life and behavior of
potential users, in this context, assisted living, e-health,
enhanced learning are only a few examples of possible
application scenarios in which the new paradigm will play a
leading role in the near future, by 2025 Internet nodes may
reside in everyday things for example in food packages,
furniture, paper documents, and more, however the IoT idea
poses several new problems concerning the networking
aspects. In fact, the things composing the IoT will be
characterized by low resources in terms of both computation
and energy capacity. Accordingly, the proposed solutions need
to pay special attention to resource efficiency besides the
obvious scalability problems; several industrial, standardization
and research bodies are currently involved in the activity of
development of solutions to fulfill the highlighted
technological requirements [13].
The potential of the next-to-come fifth generation (5G)
cellular network and the challenges to support IoT is explained
in [16] and [17], in order to fulfill of IoT requirements
through 5G wireless systems the efforts of academic,
industrial and standardization bodies should pushing
towards to satisfy exacting requirements.
The rest of this paper is structured as follows. Section II
overviews and analyses of the 6LoWPAN specifications that
are commonly use to perform 6LoWPAN encapsulation,
compression, and fragmentation. Section III provides a general
overview of the constrained nodes protocol stacks and detailed
description of the simulation topology that is used to
implement 6LoWPAN. In section IV we analyze the
simulations results and discuss the specifications that are
related to 6LoWPAN. Finally section V concludes this paper.
II. SPECIFICATIONS OF 6LOWPANS
A. IEEE 802.15.4 LR-WPAN
An IEEE 802.15.4 LR-WPAN is a simple, low-cost
communication network that involves little or no infrastructure,
this feature allows fixed, portable, and moving devices with no
battery or very limited battery consumption requirements
typically operating in short distances the personal operating
space (POS) of 10m [4].
The 802.15.4 defines physical layer (PHY) and medium
access control (MAC) sublayer specifications, the MAC
protocol can operate on both beacon enabled and non-beacon
enabled modes, in non-beacon the protocol is essentially a
simple CSMA-CA protocol [5].
Fig. 1 figure out the 802.15.4 frame format the data
payload is passed to the MAC sublayer and is referred to as the
MAC service data unit (MSDU), MAC protocol data unit
(MPDU) contains the MAC header (MHR), MSDU, and MAC
footer (MFR) The MSDU is prefixed with a MHR(contains the
frame control, sequence number, and addressing information
fields) and appended with a MFR(contains a 16 bit frame check
sequence (FCS)), then the MPDU is passed to the PHY service
data unit (PSDU), and it’s prefixed with a synchronization
header (SHR), containing the preamble sequence and start-of-
frame delimiter (SFD) fields, and a PHY header (PHR)
containing the length of the PSDU in octets, The SHR, PHR,
and PSDU together form PHY protocol data unit( PPDU).
Figure 1. 802.15.4 frame format.
B. Overview of Internet Protocol (IP)
IoT networks are expected to include billions of nodes
uniquely addressable , IANA international organization that
assigns internet protocol (IP) addresses at a global level
announced the exhaustion of version IPv4 address, the new
version IPv6 designed as successor to IPv4, it has a 128-bit
address field which it make it possible to assign a unique
address to any nod in the IoT network [2], the header format of
IPv6 in Fig. 2 occupies 40 bytes , 8-bit use by traffic class to
distinguish between different classes or priorities of IPv6
packets, the flow label used by the source to label sequence of
packets which it requests special handling by the IPv6 routers,
the Hop Limit its 8-bit and it decremented by one by each node
that forwards the packet, and the packet is discarded if Hop
Limit is decremented to zero [3].
Figure 2. Header format of IPv6.
However IPv6 introduces overhead that are not compatible
with the capabilities of constrained nodes, a solution to this
problem is offered by adopting 6LoWPAN.
C. Adaptation Layer and Frame Format
The LoWPAN payload is an IPv6 packet follows the
encapsulation header, the LoWPAN encapsulation it’s the
payload in the IEEE 802.15.4 MAC protocol data unit (PDU)
Fig. 3 shows a LoWPAN encapsulated IPv6 datagram and
Fig. 4 shows a LoWPAN encapsulated LoWPAN-HC1
compressed IPv6 datagram.
Figure 3. A LoWPAN encapsulated IPv6 datagram.
Vol. 17, No. 4, April 2019
ISSN 1947-5500

Figure 4. A LoWPAN encapsulated LoWPAN-HC1 compressed IPv6
datagram.
D. 6lowpan Header Compression
1) Dispatch Type and Header: They are use to identify the
type header immediately following the dispatch header Fig. 5
shows dispatch value, type and header.
Figure 5. Dispatch value, type and header.
6LoWPAN header compression depend on information
pertaining to the entire link and does not keep any flow state in
HC1 header construction the only field in IPv6 header that
must be carried full it’s the Hop Limit (8-bits) and the Traffic
Class and the Flow Label in fig. 2 are set to zero, so IPv6 can
be compressed to two octets instead of 40 octets, one octet use
for HC1 encoding and the other one use for the Hop Limit, and
the next header field is UDP, Internet Control Message
Protocol (ICMP) or TCP.
LoWPAN-HC1 format is using to compress a packet by
adding a dispatch value of LoWPAN-HC1 followed by
LoWPAN-HC1 header field 8-bits (HC1 encoding) as shown
below in Fig. 6 to encode the different combinations; it may be
preceded by fragmentation header, which may be preceded by
a mesh header.
The packet length inferred from layer two frame length in
the IEEE 802.15.4 PPDU, or from datagram-size field (if
present) in the fragment header.
Figure 6. Compressed and uncompressed IPv6 header.
E. Fragmentation in 6LoWPAN
The fragmentation header add to the payload datagram
when the datagram does not fit within a single IEEE 802.15.4
frame as a result it broken into link fragments, however if it fit
within a single IEEE 802.15.4 frame it’s not fragmented and
encapsulation not contain fragmentation header.
1) Datagram_offset: Fig. 7 shows the first fragment header
it defined by the pattern 11000, the second and subsequent
fragment header defined by the pattern 11100 the frame
format shown in Fig. 8 it include 8-bits additional field
(datagram_offset), however the first octet of the datagram has
an implicit value of datagram_offset equal to zero.
2) Datagram_tag: its 16 bits long, it has the same value
for all link fragments of a payload datagram, it also
incremented for successive, fragmented datagram.
3) Datagram_size: The field defines the entire IP packet
before link-layer fragmentation, its 11-bit filed; it has the same
value for all link-layer fragments of an IP packet [1].
Figure 7. First fragment.
Figure 8. Saubsequent fragments.
F. Encoding of UDP Header
The next header field in the IPv6 header it can be use for
compressing UDP, TCP or ICMP protocols, bits 5 and 6 of the
6LoWPAN-HC1 it well be use to defines the type of the next
header the header that follow the IPv6 header, so the HC2
encoding it become HC-UDP encoding by applying 0 and 1 in
bits 5 and 6, and consequently the following field in the UDP
header well be compressed the service port, destination port
and length, the UDP header check sum field it’s carried in full,
hence the UDP header it compressed from the original size 8
octets to 4 octets, Fig. 9 and Fig. 10 represents the HC-UDP
encoding.
Figure 9. Compressed UDP header.
Figure 10. HC-UDP encoding.
 Bit 0 it uses to define the source port.
 Bit 1 defines UDP destination por.
 Bit 2 define length.
 Bit 3 through 7 reserved.
Vol. 17, No. 4, April 2019
ISSN 1947-5500

G. IP Performance Metrics (IPPM)
1) one-way packet loss: Some applications do not perform
well (or at all) if end-to-end loss between hosts is large
relative to some threshold value, also for real-time
applications excessive packet loss make it difficult to support
certain application, for transport layer protocols the larger
value of packet loss, make it more difficult to sustain high
bandwidths[10].
2) one-way delay: applications do not perform well (or at
all) if end-to-end delay between hosts is large relative to some
threshold value, also the larger value of delay, make it difficult
for transport layer protocols to sustain high bandwidths, the
large value provide an indication of the congestion present in
the path [11].
3) IP Packet Delay Variation (ipdv): The Jitter of a pair
of packets within a stream of packets is defined for a selected
pair of packets in the stream going from measurement point
MP1 to measurement point MP2, one important use of delay
variation is the sizing of play-out buffers for applications
requiring the regular delivery of packets, for example, voice or
video play-out [12].
III. 6LOWPAN PROTOCOL STACKS AND SIMULATION
We implement the simulation in the ns-3 a discrete-event
network simulator, in which the simulation core and models are
implemented in C++ [8]. Two simulation scenario were
performed with different payload size, the Fig. 11 below
depicts the simulation topology, it’s consist of IoT node
communicate through IoT router with server node the transport
layer used UDP with the application layer data rate equal to
20Kbps, in the first scenario the payload is 200bytes, and in
second one the payload is 20 bytes, we use IPv6 at the network
layer and 6LoWPAN at adaptation layer to perform the
6LoWPAN compression, decompression and fragmentations
operations, the layer two MTU is 150 bytes and channel delay
is 2ms with error rate equal to 0.0001, table I represents the
simulation parameters values.
Figure 11. Protocol stacks for IoT nodes and simulation topology.
TABLE I. SIMULATION PARAMETERS VALUES
Parameter Values
Transport layer UDP
Application layer data rate 20Kbps
Payload size 200,20bytes
Network layer IPv6
MAC device CSMA
Error rate 0.0001
Delay 2ms
MTU 150byte
Data rate of the channel 5Mbps
IV. RESULT AND ANALYSIS
Table II Shows the simulations results, in first scenario
when transport layer payload size = 200 bytes the number of
packets sent (Tx) including 6LoWPAN header is 3733.000
packets, and the number of packets received (Rx) is 3678.000
packets, and the total numbers of lost packets is 55 packets, 33
packets of this packets were lost due to 6LoWPAN device
operation, that is the fragmentation procedures because the
payload doesn’t fit within a single frame, and the drop reason
is fragment timeout exceeded (60 seconds) thereupon the
timeout is expires and the fragment cleared from the buffer, in
contrast with the second simulation scenario the number of
packets sent (Tx) including 6LoWPAN header is 18633
packets, and the number of packets received (Rx) is 18485
packets, there is a large increase in the numbers of sent and
received packets, as long as the payload fit within a single
frame (no fragmentation), and the total numbers of lost packets
is 148 packets, and the 6LoWPAN device doesn’t drop any
packet, and all of the lost packets they are dropped by the
MAC device due to other network conditions.
TABLE II. SIMULATION RESULTS
Simulation Results
Transport
Layer Payload
Size = 200bytes
Transport
Layer Payload
Size = 20bytes
Number of packets sent(Tx) 3733.000 18633
Number of packets received(Rx) 3678.000 18485
Number of
packets
lost(Drop)
SixLowPan
device
33 0
MAC device 55 148
Throughput 24.28 58.16
Average delay 0.00245 0.00207
Packet delivery ratio 98.50 99.20
Vol. 17, No. 4, April 2019
ISSN 1947-5500

The second simulation scenario has higher throughput
than the first one, and minimum delay about 0.00207, and all of
the two simulations scenarios show reasonable packet delivery
ratios.
The packet byte count versus time in Fig. 12 below explains
the size of the transmitted packets to path through the layer two
frame, in first scenario the payload fragmented to fragments
between 100 bytes to 150 bytes, however in the second
simulation scenario the payload has a fixed size about 60 bytes
including 6LoWPAN header.
Figure 12. SixLowPan packet byte count vs. time.
Fig. 13 represents the packets loss ratio, if we consider the
packets when payload size equal to 200 bytes we find that the
datagram doesn’t fit within a single frame, it broke into
fragments to be transmitted, all 33 packets that it dropped by
6LoWPAN device due to fragment timeout exceeded, and the
other packets dropped by MAC device, in contrast with the
other simulation scenario when the payload equal to 20 bytes ,
all the packets fits within a single frame as a result it didn’t
fragmented, and therefore the packets didn’t drop by
6LoWPAN adaptation layer, and the 148 packets dropped by
MAC device.
Figure 13. Number of lost packets vs. time.
Fig. 14 shows throughput when payload size equal 200
bytes the throughput value about 24Kbps in contrast with the
second scenario the second scenario show better performance
and it has maximum values about 58Kbps.
Figure 14. SixLowPan throughput vs. time.
Fig. 15 below depicts the delay values versus the time, the
first scenario shows the highest values of the delay between
0.0045ms and 0.0055ms than the second scenario (the highest
value of the delay reaches 0.00212ms), the first scenario at
some points register minimum values of delay because the
MAC device drops the second part of the fragmented
6LoWPAN payload, after t = 100 second the two scenarios
show stable performance.
Figure 15. SixLowPan delay vs. time.
Vol. 17, No. 4, April 2019
ISSN 1947-5500

Fig. 16 shows delay variation also the first scenario shows
the highest jitter values, and the lost fragments effect the jitter,
and also it can reduce the quality of the real-time applications,
the 6LoWPAN will reject all the fragments belong to the lost
fragment after timeout timer expire.
Figure 16. SixLowPan jitter vs. time.
V. CONCLUSION
In this paper we studied the 6LoWPAN adaptation layer
protocol that is used in the constrained links to carry IPv6
datagram payload over 802.15.4 standard in the internet of
things (IoT) environment devices, IoT it’s consider as future
networks that is expected to involve in many different domains,
such as smart city, smart farm, industrial automation, home
automation, intelligent energy management, smart grids,
automotive, health, learning and so on. Therefore we address
the challenges ahead of internet protocol (IP), such as
addressing issues in IPv4 and overheads problem in IPv6, as
well as highlight the 802.15.4 standard specifications and the
fifth generation (5G) technology that can be use to realize IoT,
also perform an analysis to the different methods used in the
adaptation layer to perform compression, decompression and
fragmentations operations. Based on NS-3 simulations, we
implement 6LoWPAN and evaluate the performance of two
different scenarios. The obtained results showed that the
fragmentations procedures has an effect in the network
throughput, number of packets loss and delay variation, and
whenever the payload has minimum size, in other words it can
fit within a single frame the network shows stable and better
performance.
VI. REFERENCES
[1] G. Montenegro, N. Kushalnagar, J. Hui, and D. Culler, “Transmission of
IPv6 Packets over IEEE 802.15.4 Networks”, RFC 4944, September
2007.
[2] A. Zanella, L. Vangelista, N. Bui, A. Castellani, M. Zorzi, “Internet of
Things for Smart Cities”, IEEE Internet Of Things Journal, Vol. 1,
No. 1, February 2014.
[3] S. Deering and R. Hinden, “Internet Protocol Version 6 (IPv6)
Specification”, RFC 2460, IETF Dec. 1998. [Online]. Available:
https://www.ietf.org/rfc/rfc2460.txt.
[4] 802.15.4-2011 IEEE Standard for Local and metropolitan area networks
Part 15.4: Low-Rate Wireless Personal Area Networks (LR-WPANs),
2011.
[5] G. Lu, B. Krishnamachari, C. S. Raghavendra, “Performance
Evaluation of IEEE 802.15.4 MAC
for Low Rate Low Power Wireless networks”, 2004.
[6] K. Mohamed, S. Hussein, A. Abdi, A. El Seddiq, “Studying the TCP
Flow and Congestion Control Mechanisms Impact on Internet
Environment”, IJCSIS, Vol. 16, No. 11, November 2018.
[7] J. Hui and P. Thubert, “Compression format for IPv6 datagrams over
IEEE 802.15.4-Based Networks”, RFC6282, Sep. 2011. [Online].
Available: http://tools.ietf.org/html/rfc6282.
[8] ns-3, http://www.nsnam.org, Jan 08, 2019.
[9] G. Mulligan, “The 6LowP AN architecture”, ACM, June 2007.
[10] S. Kalidindi, M. Zekauskas, A. Morton, “A One-Way Loss Metric for IP
Performance Metrics (IPPM),” RFC 7680, January 2016.
[11] S. Kalidindi, M. Zekauskas, A. Morton, “A One-Way Delay Metric for
IP Performance Metrics (IPPM),” RFC 7679, January 2016.
[12] C. Demichelis, P. Chimento, “IP Packet Delay Variation Metric for IP
Performance Metrics (IPPM),” RFC 3393, November 2002.
[13] L. Atzori, A. Iera, and G. Morabito, “The internet of things: A survey,”
Comput. Netw., vol. 54, no. 15, pp. 2787–2805, 2010.
[14] Postel, J., "Internet Protocol", RFC 791, September 1981.
[15] S.Ziegler, M. rita, L. Ladid, S. Krco, A. Skarmeta, “Scalable Integration
Framework for Heterogeneous Smart Objects, Applications and
Serices”, River Publishers, 2014.
[16] A. Gupta and R. K. Jha, “A Survey of 5G Network: Architecture and
Emerging Technologies,” IEEE Access, 2015.
[17] L. Militano, G. Araniti, M. Condoluci, I. Farris, A. Iera, “Device-to-
Device Communications for 5G Internet of Things”, EAI Endorsed
Transactions on Internet of Things, October 2015.
Vol. 17, No. 4, April 2019
ISSN 1947-5500

Implementation_and_Analysis_of_the_6LoWPAN.pdf

Recommended

Recommended

More Related Content

What's hot

What's hot (17)

Similar to Implementation_and_Analysis_of_the_6LoWPAN.pdf

Similar to Implementation_and_Analysis_of_the_6LoWPAN.pdf (20)

Recently uploaded

Recently uploaded (20)

Implementation_and_Analysis_of_the_6LoWPAN.pdf