Goal

Through deep understanding of the interaction between IEEE802.15.4, IPv6 and UDP, 6LoWPAN removes fields which are redundant among those headers, thereby reducing the size of the packets being transmitted over the air.

Let's assume the simplest case of a point-to-point link in a wireless multi-hop network network (which is also the best case for 6LoWPAN). The figure below depicts the IEEE802.15.4, IPv6 and UDP headers commonly found in a packet. Alliances such as IP for Smart Objects (http://www.ipso-alliance.org/) provide a clear indication that this type of standard packet structure will become ubiquitous in tomorrow's networks of resource-constrained wireless devices.

RFC4944

6LoWPAN removes a number of fields in the IPv6 and UDP headers because they take well-known values, or because they can be inferred from fields in the IEEE802.15.4 header. In the IPv6 header, the version field is always 6 for IPv6, the traffic class and flow label are never used, the length field is always equal to the length field of IEEE802.15.4 minus the length of the IPv6 header. All these fields can hence be removed. Because Next Header typically point to either UDP or TCP, this 8-bit field can be replace by a 2-bit field as part of the the HC1 field of the 6LoWPAN header. Finally, RFC2464 defines how 128-bit IPv6 addresses can be recovered from 64-bit MAC addresses, such as the IEEE802.15.4's Source and Destination fields. This removes the IPv6 Source Address and Destination Address fields. In the end, only the Hop Limit field needs to be present in the 6LoWPAN header. Similarly for UDP, the Length can be calculated from the IEEE802.1.54's Length field; in the most common case, only a limited number of ports with be used, so 4-bits can be used to describe them, rather than 8 bit. The figure below shows the same packet as above, compressed using 6LoWPAN.

IPHC

RFC4944 is insufficient for most practical uses of 6LoWPAN networks. It is most effective for link-local unicast communication, where IPv6 addresses carry the link-local prefix and an Interface Identifier (IID) directly derived from IEEE802.15.4 addresses. In this case, both addresses may be completely elided. However, link-local addresses are usually not used for application-layer data traffic, so the actual value of this compression mechanism is limited.

Routable addresses must be used when communicating using a route-over configuration where IP forwarding occurs within the WSN (as in the case in this project). For routable addresses, RFC4944 requires both IPv6 source and destination addresses to carry the prefix in-line.

IPHC effectively compresses of Unique Local, Global, and multicast IPv6 Addresses based on shared state within contexts. In addition, it introduces a number of additional improvements over the header compression format defined in RFC4944. IPHC also defines NHC, an encoding format for arbitrary next headers. IPHC indicates whether the following header is encoded using NHC. If so, the bits immediately following the compressed IPv6 header start the NHC encoding. NHC adds the capability to elide the UDP checksum, which enables to save an additional pair of octets. NHC also enable compression of IPv6 Extension Headers.

Frame formats are presented in 6LoWPAN, using IPHC rather that RFC4944. Note that the format of the IPHC header is different when the next header is ICMPv6 (L3DIO and L3DAO, in which case the NHC can not be used) or UDP (L7data, in which case NHC is used). In L7data for example, IPHC compresses the IPv6 header down to 7 octets (1-octet dispatch, 1-octet IPHC, 1-octet Hop Limit, 2-octet Source Address, and 2-octet Destination Address). The Hop Limit may not be compressed because it needs to decremented at each hop and may take any value.