2010 Ninth International Conference on Grid and Cloud Computing

An Improved Header Compression Scheme for

6LoWPAN Networks
Wang Huiqin, Dong Yongqiang
School of Computer Science and Engineering, Southeast University
Key Laboratory of Computer Network and Information Integration, Ministry of Education
Nanjing, China
whq.amy@gmail.com, dongyq@seu.edu.cn

Abstract—To apply IPv6 to IEEE 802.15.4-based low-power Application

wireless personal area networks, efficient packet header Transport
compression is essential to adapt to limited bandwidth, memory IPv6
and energy resources of such networks. While the existing header 6LoWPAN Adaptation
compression solutions are yet to be perfected, an improved 802.15.4 MAC
header compression scheme is proposed which has the capability 802.15.4 PHY
to better support the compression on IPv6 multicast address, Figure 2. 6LoWPAN Architecture
UDP, ICMP headers and routing extension headers as well.
The 6LoWPAN headers are identified by the first byte, as
Keywords—6LoWPAN, header compression, IPv6, multicast
shown in Table I. and appear in the order: Mesh header,
address, routing extention header
Broadcast header, Fragmentation header, Dispatch IPv6. The
I. INTRODUCTION IPv6 packets are encapsulated as that in Fig.3. The first three
6LoWPAN headers are carried optionally according to the
The traits of IPv6 large number of address and address actual demand and IPv6 header can be uncompressed or
auto-configuration are very suitable for LoWPAN (Low-power compressed according to different dispatch value.
Wireless Personal Area Network). Yet the application of IPv6
to LoWPAN brings great challenge to adaptation between IPv6 802.15.4 Mesh Broadcast Fragment Dispatch IPv6 Pay- FCS
and LoWPAN [1]. Hdr Hdr Hdr Hdr Hdr load

The 802.15.4 defines MTU 127 bytes while IPv6 requires Figure 3. Encapsulated IPv6 Packet
the link layer to support 1280 bytes packets. As shown in Fig.1,
the maximum 802.15.4 frame overhead is 25 bytes, resulting in TABLE I. 6LOWPAN HEADERS
the maximum frame size at MAC layer is 102 bytes. After
imposing 21 bytes link layer security header, there leaves only Dispatch Header Type
81 bytes space for IP packets. Besides, with 40 bytes IPv6 00 xxxxxx NALP Not a LoWPAN frame
header and 8 bytes UDP header, only 33 bytes are available for
01 000001 IPv6 Uncompressed IPv6 Addresses
upper-layer data [2]. The transmission efficiency for the upper-
layer data is less than 26%. Packet fragmentation and header 01 000010 LOWPAN_HC1 LOWPAN_HC1 compressed IPv6
compression is thus necessary for LoWPAN to reduce header 01 010000 LOWPAN_BCO LOWPAN_BC0 Broadcast
overhead and save space for upper-layer data. 01 111111 ESC Additional Dispatch byte follows
MTU 127B 10 Mesh header Mesh header
33B 11000 Frag1 The first Fragment
Frame Header AES-128 IPv6 Header UDP Payload
11100 FragN Subsequent Fragments
25B 21B 40B 8B
IPv6 Packet 81B
II. RELATED WORK ON 6LOWPAN HEADER COMPRESSION
Figure 1. IEEE 802.15.4 Frame
A. LOWPAN_HC1 and LOWPAN_HC2 in RFC4944
In order to smoothly transmit data packet between IPv6 and The first header compression mechanism, LOWPAN_HC1
802.15.4 networks, IETF 6LoWPAN working group proposes was brought forward in RFC4944. In this scheme, 6LoWPAN
an adaptation layer between 802.15.4 MAC layer and IPv6 nodes can compress packets headers without keeping any flow
layer, as illustrated in Fig.2. The adaptation layer fulfills state and compression context. The default values of IPv6
packets compression/decompression, fragmentation/reassembly header on 6LoWPAN networks are:
as well as mesh multi-hop forwarding. It has defined a
fragmentation header to achieve fragmentation function and a • Version: IPv6.
mesh header with source and ultimate destination address to • Traffic Class, Flow Label: All zero.
support multi-hop forwarding.

978-0-7695-4313-0/10 $26.00 © 2010 IEEE 350

DOI 10.1109/GCC.2010.74
 • Payload Length: Inferred either from link layer or the
fragment header.
• Next Header: 2bits to express TCP, UDP and ICMP.
• Source and destination Address: They are link-local
and the interface identifiers are inferred from link layer.
It always carries the full Hop Limit for IPv6 header. For
LOWPAN_HC2, it only defines the compression of UDP
header. The UDP Length field can be compressed and inferred
from IPv6 header. The source or destination port can be
reduced to 4 bits if it is based on 0xF0B0. The full port is
calculated by 0xF0B0 plus the 4 bits compressed port value.
The LOWPAN_HC1 and LOWPAN_HC2 encoding are as
shown in Fig.4.
S_Addr(2) D_Addr(2) TC_FL(1) NH(2) HC2(1)
LOWPAN_HC1 Encoding
S_Port(1) D_Port(1) Length(1) Reserved(5)
LOWPAN_HC2 Encoding for UDP
Figure 4. LOWPAN_HC1 and LOWPAN_HC2 for UDP
This header compression mechanism works very well in
link-local unicast communication. It can compress the 40 bytes
IPv6 header down to 3 bytes (Dispatch, Encoding and Hop
Limit). But it is insufficient for most practical uses of
6LoWPAN. For multicast and global communication, it has to
carry the full 128bits address. In addition, it uses 2bits to define
the next header type and LOWPAN_HC2 can only compress
UDP, TCP and ICMP which has poor extensibility. If there is
extension header between IP and UDP, the following UDP
header can’t be compressed, as the compressed headers must be
consecutive.
B. LOWPAN_HC1g
LoWPAN_HC1g [3] is an extension of LoWPAN_HC1.
The 6LoWPAN network is assigned a single compressible
global address prefix. When source or destination address
matches the default one, it can be compressed. The
LOWPAN_HC1g encoding is shown in Fig.5. It can compress
the global address down to 64, 16 and 0bit. The 6LoWPAN
network uses LoWPAN_HC1 to compress link-local
communication and LoWPAN_HC1g for global as illustrated
in Fig.6. To distinguish which compression scheme is used,
different dispatch value is assigned.
SC(2) DC(2) VTF (1) NH(2) L4C(1)
Figure 5. LOWPAN_HC1g Encoding
Upper Layer
LOWPAN_HC1 LOWPAN_HC1g
(Link-Local (Global
Communication) Communication)
6LoWPAN Mesh/Frag
802.15.4
Figure 6. LOWPAN_HC1g and LOWPAN_HC1
351
LoWPAN_HC1g can compress global unicast address
when communicate intra-6LoWPAN. But when devices
communicate with external 6LoWPAN or internet, the full
address must be carried in line. Furthermore, the multicast
address can’t be compressed yet by LOWPAN_HC1g.
C. LOWPAN_IPHC and LOWPAN_NHC
LOWPAN_IPHC and LOWPAN_NHC have been
proposed by IETF 6LoWPAN working group for IPv6 packet
header compression. The latest draft version is draft-ietf-
6lowpan-hc-07 [4]. LOWPAN_IPHC is based on context
compression and can compress global unicast and multicast
address. By taking the rightmost 5 bits of ESC dispatch
(reassign another dispatch value for ESC), the LoWPAN_IPHC
encoding becomes 2 bytes or 3 bytes with a byte of context
extension as shown in Fig.7.
011 TF NH HLIM CID SAC SAM M DAC DAM
(3) (2) (1) (2) (1) (1) (2) (1) (1) (2)
Figure 7. LOWPAN_IPHC Encoding
TF: Traffic class and Flow label.
NH: 0: 8 bits Next Header are carried in-line. 1: The Next
Header field is compressed and the next header is encoded
using LOWPAN_NHC.
HLIM: Hop limit can be compressed to some commonly-
used values.
CID: Context Identifier Extension. 1 bit to indicate whether
the 1 byte context extension field is followed or not. The
context extension field is composed of 4 bits SCI and 4 bits
DCI which can identify 16 contexts. CID set to 0 means no
extension byte follows.If context-based compression is
specified in either SAC or DAC, context 0 is used.
SAC/DAC: 0: stateless compression. 1: context-based
compression.
SAM: Source Address Mode. 2 bits to indicate the length of
source address carried in line.
M: 0: Destination address is unicast. 1: Multicast address.
DAM: Destination Address Mode. 2 bits to indicate the
length of destination address carried in line.
The multicast address can be statelessly compressed down
to 48,32 and 8 bits with the forms as following:
48bits: FFXX::00XX:XXXX:XXXX
32bits: FFXX::00XX:XXXX
8bits: FF02::00XX
LOWPAN_IPHC adopts 1 bit NH field to indicate whether
the next header is compressed or not. Instead of 2 bits in
RFC4944, LOWPAN_NHC uses variable length to identify the
header type (Fig.8) which makes it possible to compress
arbitrary next header. The draft describes UDP and IPv6
extension header encoding as shown in Fig.8.
 Var-len NHC ID Compressed NH
LOWPAN_NHC
11110 C(1) P(2)
UDP_Encoding
1110 EID(3) NH(1)
IPv6 Extension Header Encoding
Figure 8. LOWPAN_NHC Encoding
For UDP port compression, the 2 bits P field expresses
what to carry in line:
00: 16 bits source port and 16 bits destination port.
01: 16 bits source port and 8 bits destination port (port base
is 0xF0).
10: 8 bits source port and 16 bits destination port (port base
is 0xF0).
11: 4 bits source port and 4 bits destination port (port base
is 0xF0B0).
In the case of both source and destination ports can be
compressed to 8 bits, and one of the ports can be compressed to
8 bits when another to 4 bits, this compression scheme must
carry one of the ports in 16 bits as per the P field encoding.
There will be one byte redundancy.
For IPv6 extension header compression, most fields are
carried in order behind encoding field except Next Header and
Length. If NH in encoding is set to 1, which means the next
header is compressed using LOWPAN_NHC, the Next Header
can be elided as the header type can be got from the
LOWPAN_NHC variable length ID. The Length filed is
changed to indicate the length of the IPv6 extension header in
octets other than the definition in [5] in 8-octet units. Therefore
it uses 1 byte encoding to substitute 1 byte Next Header field
which doesn’t increase the overhead for compressing IPv6
extension headers.
In a word, LOWPAN_IPHC provides a mechanism to
compress link-local, global unicast and multicast address, while
both intra and external 6LoWPAN communication is context-
based compression. LOWPAN_NHC defines compression for
UDP and IPv6 extension header. However, the draft is still not
perfect for header compression in 6LoWPAN. The multicast
address and UDP port can be further compressed. UDP ports
not based on 0xF0 or 0xF0B0 have to be carried full 16 bits in-
line. Furthermore, if ICMP header is compressed, additional
benefit can be achieved.
III. IMPROVED HEADER COMPRESSION SCHEME
A. LOWPAN_IIPHC
In the common case, node address is formed using link-
local prefix or a global prefix assigned to the 6LoWPAN
network. Interface IDs are configured within a single
6LoWPAN network in a uniform matter, 16 bits or 64 bits.
When a node communicates with external networks, the
packets will be firstly sent to an ER (Edge Router) and then to
the destination network.
LOWPAN_IPHC can utilize 16 contexts at most. For intra
6LoWAPN communication, it can use default CID 0 and no
352
context extension field is carried in line. But for external
communication, the 4 bits DCI must be carried in line for
destination address and for octet alignment the 4 bits SCI also
must be carried although the prefix is the same between source
and ER. In this case, the SCI is redundancy actually. So, in
LOWPAN_IIPHC the context is extended to 8 bits which will
support more CID than LOWPAN_IPHC without increasing
header overhead. The LOWPAN_IIPHC encoding is shown in
Fig.9. The TF and NH fields have the same meanings with that
in LOWPAN_IPHC.
011 TF NH HLIM CID S_addr M D_Addr
(3) (2) (1) (1) (2) (3) (1) (3)
Figure 9. LOWPAN_IIPHC Encoding
HLIM: 0: The hop limit field is carried in line. 1: The hop
limit is compressed. This happens in mesh-under 6LoWPAN.
The compressed hop limit is 1 for intra 6LoWPAN
communication and 64 for outbound.
CID: Context Identifier Extension.
00: There is no context extension field. if context-based
compression is specified in either S_addr or D_addr, context 0
is used.
01: 1 byte SCI context extension field follows behind. if
D_addr indicates context-based compression, context 0 is used.
10: 1 byte DCI context extension field follows behind. if
S_addr indicates context-based compression, context 0 is used.
11: Both SCI and DCI are carried. This will not happen in
6LoWPAN networks with single global prefix.
S_addr/ M=0,D_Addr: Unicast address compression.
000: 128 bits address is carried in line.
001: 64 bits interface ID is carried in line. The prefix is link
local.
010: 16 bits interface ID is carried in line. The prefix is
link local.
011: Full address is elided. Interface ID is inferred from
link layer and the prefix is link local.
100: Full address is elided. The unspecified address :: is
used. The value is only effective for S_addr.
101: 64 bits interface ID is carried in line. The prefix is
inferred from context.
110: 16 bits interface ID is carried in line. The prefix is
inferred from context.
111: Full address is elided. Interface ID and the prefix are
inferred from link layer and context respectively.
M=1,D_addr: Multicast address commpression.
000: 120 bits multicast address is carried in line. The first
FF byte is elided.
001: 48 bits multicast address is carried in line. The address
takes the form of FFXX::00XX:XXXX:XXXX in which the X
nibbles are carried in line.
 010: 32 bits multicast address is carried in line.The address
takes the form of FFXX::00XX:XXXX.
011: 24 bits multicast address is carried in line. Solicited-
node multicast address FF02:: 1:FFXX:XXXX is used.
100：All-nodes multicast address FF02:: 1 is used.
101：All-routers multicast address FF02:: 2 is used.
110：8 bits multicast address is carried in line. The address
takes the form of FF02::00XX.
111：48 bits multicast address is carried in line. Context-
based compression is used. The multicast address takes the
form of FFXX:XXLL: PPPP:PPPP:PPPP:PPPP:XXXX:XXXX
in which P and L nibbles are inferred from context[6].
It can be seen that LOWPAN_IIPHC compression
mechanism extends the CID number and can better compress
mulitcast address down to 48,32,8 and 0 bit. The 6LoWPAN
link local all-routers and all-nodes mulitcast address can be
completely elided while LOWPAN_IPHC scheme must carry 8
bits. In addition the solicited-node multicast address can be
reduced to 24 bits while in LOWPAN_IPHC it occupies 48 bits.
B. UDP_IHC
UDP header compression defined in [4] can only compress
UDP port based on 0xF0 and 0xF0B0. It has to carry 24 bits
port even both source and destination ports are based on 0xF0.
UDP_IHC can achieve better compression by cutting short the
variable length UDP ID to 3 bits and separating the source port
encoding from the destination one. The UDP_IHC encoding is
shown in Fig.10.
110 C(1) S(2) D(2)
Figure 10. UDP_IHC Encoding
S/D: Source Port/Destination Port
00: 16 bits port is carried in line.
01: The first 8 bits of port is 0xF0 and elided. The
remaining 8 bits of port is carried in line.
10: The first 12 bits of port is 0xF0B and elided. The
remaining 4 bits of port is carried in line.
11: The first 8 bits of port is 0x00 and elided. The
remaining 8 bits of port is carried in line.
If only source or destination port can be compressed down
to 4 bits, for octet alignment the compressible port will be
carried in 8 bits. The UDP_IHC can better compress the well-
known port less than 255 besides ports based on 0xF0.
C. ICMP_IHC
All existing drafts for 6LoWPAN header compression did
not define compression for ICMP header. However ICMP
packets are often used to transmit information and control
packets in 6LoWPAN networks. More benefit can be achieved
if ICMP header is compressed. The ICMP_IHC encoding is
shown in Fig.11.
353
10 TC(6)
Figure 11. ICMP_IHC
The first 2 bits 10 are used to identify ICMP packet. The
TC field defines the mapping with Type and Code field as
following:
0: Type=128, Code=0, Echo Request Message
1: Type=129, Code=0, Echo Reply Message
2: Type=133, Code=0, Route Solicitation
3: Type=134, Code=0, Route Advertisement
4: Type=135, Code=0, Neighbor Solicitation
5: Type=136, Code=0, Neighbor Advertisement
6: Type=3, Code=0, Hop limit exceeded in transit
7: Type=3, Code=1, Fragment reassembly time exceeded
8~62: reserved
63: Extending 1 byte TC field
By ICMP_IHC, the header before ICMP can elide the Next
Header field. 2 bytes Type and Code fields can be compressed
into the encoding field. In all, the ICMP_IHC can save 2 bytes
space for every ICMP packet.
D. RH_IHC
Draft in [4] has defined a compression mechanism for IPv6
extension header as per chapter III. It substitutes Next Header
field with 1 byte encoding which will not increase the overhead
for compression IPv6 extension headers. This is helpful for the
compression of headers following behind the extension
headers.
In some 6LoWPAN applications, source routing technique
is needed to avoid large routing tables on memory constrained
nodes [7]. This will utilize the IPv6 routing header which has
been defined in RFC2460 with only one type RH0 as shown in
Fig.12. If RH0 is compressed according to mechanism in [4], it
must carry the full 128 bytes addresses. The resultant packets
can hardly be transmitted in 6LoWPAN networks.
Next Header Hdr Ext Len Type=0 Segments Left
Reserved
Address[1]
……
Address[n]
Figure 12. RH0 Format
Practically, if the routing header is used for intra
6LoWPAN communication, all nodes share the same CID and
link layer address type (16 bits or 64 bits). For communication
with external 6LoWPAN, only the destination address’s CID
and length may be different from the intra nodes. The source
node doesn’t specify the source routing for external 6LoWPAN
which will be done by the ER of it.
 The RH_IHC encoding, as shown in Fig.13, follows behind
LOWPAN_NHC in which the EID indicates it is an IPv6
routing extension header.

Type R Net CID Addr0 Addr1 Rsv

(1) (1) (1) (1) (1) (1) (2)

Figure 13. RH_IHC Encoding

Type: 0: Type field is carried in line. 1: Routing Type field

is elided. It’s RH0.
R: Reduced. 6LoWPAN wireless link is asymmetry. When Figure 14. 6LoWPAN Topology Scenario
node setups source routing, it may don’t want the middle or the
destination node to install reverse path. In this case R is set 1 Link-Local Multicast: FE80::64->FF02::1 (Route
indicating routers to remove the traversed nodes address from Advertisement----ICMP)
the routing extension header which can greatly reduce the
packet size. When R bit is set 1, Segments Left field is elided IIPHC ICMP_IHC Checksum Payload
as it can be inferred from Hdr Ext Len, Addr0 and Addr1. 2 1 2
Net: 0: All nodes in RH are intra 6LoWPAN. 1: The Link-Local Unicast: FE80::1->FE80::2 (UDP)
destination node is external 6LoWPAN.
IIPHC UDP_IHC S D Checksum Payload
CID: 0: No CID extension byte follows behind and CID 0 is
Port Port
used for intra 6LoWPAN nodes. 1: 1 byte CID extension field 2 1 1 2
is carried in line for intra 6LoWPAN nodes. If Net is 1, CID for Intra-PAN Global: 2000::1->2000::2 (UDP)
destination node must be always carried in line.
Addr0: It indicates the length of intra 6LoWPAN nodes IIP HL SA DA UDP_ S D Check Pay
HC IM IHC Port Port sum load
address carried in line. 0: 16 bits. 1: 64bits. 2 1 2 2 1 1 2
Addr1: This field is effective only when Net is set. It Inter-PAN Global： 2000::1->2001::2 (UDP)
indicates the length of destination node address carried in line.
0:16 bits. 1: 64 bits. IIP HL SA DA DCI UDP_ S D Check Pay
HC IM IHC Port Port sum load
When RH0 is used in intra 6LoWPAN communication, the 2 1 2 2 1 1 1 2
encoding and other fields are carried in the following order
(Suppose 6LoWPAN network uses 16 bits short address and In Table II., we compare the improved header compression
next header of RH0 is compressed. If next header is not scheme with the one in [4] in the best case. It can be seen that
compressed, the Next Header field must be carried behind the improved HC scheme extends the one in [4] providing
Enoding byte.): better support for compression of multicast address and ICMP
header. By extending the context to 1 byte, more contexts can
Encoding (11010000) + Hdr Ext Len (in octet) + Address[0] be supported without making any difference from the
(16 bits) +… + Address[n] compression effect. In addition, the improved HC further
When RH0 is used for external communication, suppose the optimizes the compression for UDP port. It also defines a
intra 6LoWPAN nodes do not use default CID 0 and both intra compression mechanism for RH0 which makes it possible to
and destination networks use 16 bits short address. The use source routing technique in 6LoWPAN networks.
encoding and other fields are in the following order:
TABLE II. COMPARISON
Encoding (11111000) + Hdr Ext Len (in octet) + CID Intra Communication Protocol Draft 07 HC Improved HC
6LoWPAN + CID Destination + Address[0] (16 bits) + … +
Address[n] Link-local unicast IP+UDP 6 (2+4) 6 (2+4)
IP+ICMP 7 (3+4) 5 (2+3)
By using RH_IHC, the routing header can carry Link-local Multicast IP+UDP 7 (3+4) 6 (2+4)
compressed addresses and the redundant information among IP+ICMP 8 (4+4） 5 (2+3）
addresses can be greatly reduced. This compression mechanism Intra-PAN Global IP+UDP 11 (7+4) 11 (7+4)
makes source routing technique usable in 6LoWPAN networks. IP+ICMP 12 (8+4) 10 (7+3)
Inter-PAN Global IP+UDP 12 (8+4) 12 (8+4)
IV. ANALYSIS AND CONCLUSION IP+ICMP 13 (9+4) 11 (8+3)
To analyze the performance of the improved header
compression scheme, we elaborate the compression instance By utilizing header compression, the packet size transmitted
for link local unicast, multicast and global communication as in networks can be greatly reduced while the computing power
per Fig.14 topology. of CPU will be increased to some extent. In [8] it has been

354
pointed that most energy of sensor node is consumed in
wireless communication while CPU takes only a very small
part of the power consumption. The improved header
compression scheme proposed in this paper can greatly
decrease the wireless communication and save nodes energy
which will extend the average lifetime of the entire network.
For further work, experiments will be taken on 6LoWPAN
sensor nodes to validate the enhancements of the improved
header compression.
ACKNOWLEDGMENT
This work is supported by the National Natural Science
Foundation of China under Grant No. 90604003 and Research
Fund for the Doctoral Program of Higher Education of China
under Grant No.20090092120029.
355
REFERENCES
[1] J. W. Hui and D. E. Culler, “IP is Dead, Long Live IP for Wireless
Sensor Networks”, In: the 6th ACM Conference on Embedded Network
Sensor Systems, July 2008
[2] G. Montenegro, N. Kushalnagar, J. Hui and D. Culler, “Transmission of
IPv6 Packets over IEEE 802.15.4 Networks”, RFC4944, Sep.2007
[3] J. Hui, D. Culler, “Stateless IPv6 Header Compression for Globally
Routable Packets in 6LoWPAN Subnetworks”, draft-hui-6lowpan-hc1g-
00, June 2007
[4] J. Hui, Ed, P. Thubert, “Compression Format for IPv6 Datagrams in
6LoWPAN Networks”, draft-ietf-6lowpan-hc-07, April 2010
[5] S. Deering and R. Hinden, “Internet Protocol, Version 6 (IPv6)
Specification”, RFC2460, Dec.1998
[6] B.Haberman and D.Thaler, “Unicast-Prefix-based IPv6 Multicast
Address”, RFC3306, Aug.2002
[7] T. Winter, Ed and P. Thubert, Ed, “RPL: IPv6 Routing Protocol for Low
power and Lossy Networks”, draft-ietf-roll-rpl-07, March 2010
[8] Deborah Estrin, “Sensor Network Protocols”, In: the 8th ACM
International Conference on Mobile Computing and Networking,
Sep.2002