IoT(Internet Of Things)

 

 

 

WPAN - 6LoWPAN

 

What is 6LoWPAN ? You may find various definition from various source. With whatever question it is, everybody wants to have short one line/one sentence answer. What is the one sentence definition for 6LoPAN ? I like the definition from 6LoPAN Seminar (Reference [1]). It was stated as '6LoPAN is an IPv6 technology designed for Low Power Wireless Communications'.

Whenever you have one line definition, your next question would almost always be 'what does it mean ? what does it practically mean ?'. Then you have to go through the whole book to figure it out. It means you need to read a lot of other writings or watch a lot of videos. I will be trying to write this page as a kind of cheatsheets or big dots for this subject to help you with connecting the dots when you read/watch further details.

Based on IETF RFC 4944 : Transmission of IPv6 Packets over IEEE 802.15.4 Networks. The title of the document would tell you a good big picture.

As you may know, 802.15.4 is mostly about MAC layer protocol based on a small MAC frame (127 Bytes). The RFC 4944 is mostly about how to form the large IPv6 packets into small 802.15.4 MAC frame. Main issue of this topic is to form IPv6 link-local address into autoconfigured 802.15.4 address. This involves a special header compression process.

Keep the direction of that address mapping in mind, because it goes from the link to IP. RFC 4944 builds the IPv6 interface identifier, and so the link-local address, from the 802.15.4 address the node already has. Also note that RFC 4944 is no longer the whole story. RFC 6282 replaced its header compression in 2011, RFC 6775 optimized IPv6 Neighbor Discovery for 6LoWPAN, and RFC 8025 added a Paging Dispatch. All three update RFC 4944, and the Packet Structure section shows where they change the picture.

6LoWPAN and Other Technologies

Like any other technolgies, I also started reading a lot of documents and watching a lot of videos about IoT at the beginning. However the more I read/watch, the more I get confused. There are a lot of technologies with different names.. but all of them sounds like same thing. It would be because all those technologies has its own unique feature but at the same time they have some commonalities. So when they are talking about their own unique feature, it would sound like they are all different. but when they are talking on commonalities they all sound like same thing.. and you may talk to yourself "Are all these same thing ? or different ?"

As I was struggling with this confusion, I got following single diagram from reference [1], [2]. This single diagram cleared a lot of my confusion (it worked great at least for me).

As you see here, 6LoWPAN is the core part of the IoT protocol stack and 6 LoWPAN is based on IPv6 in terms of structure and basic Neighbor Discovery and on ROLL in terms of routing protocol. IEEE 802.15.4 is under the umbrella of 6LoWPAN. You may say "6LoWPAN is IP and routing protocol (Network Layer Protocol) and 802.15.4 is more for MAC / PHY protocol. In case of ZigBee, it is on top of 802.15.4 MAC layer, but it is based on its own PHY layer which is a little bit different from 802.15.4 PHY. The most unique feature of ZigBee would be its network layer protocol. It used its own Network layer protocol, but now they introduced ZigBee IP which is similar to 6LoWPAN.

 

6LoWPAN, ROLL and IPv6 inside an IETF circle, linked to IEEE 802.15.4, ZigBee, ISA SP100.11a, ETSI M2M, OGC, IPSO Alliance and IP500 Alliance

6LoWPAN among the IoT standards. IEEE 802.15.4 sits under 6LoWPAN, ZigBee and ISA SP100.11a alike.

One correction to the ZigBee sentence above. ZigBee uses the 802.15.4 PHY as well as the 802.15.4 MAC, and the drawing shows it attached to IEEE 802.15.4 for that reason. What ZigBee adds is its own network layer and the layers above it. So ZigBee and 6LoWPAN differ at the network layer, and they share the same radio below it.

6LoWPAN in Full Stack Architecture

If you compare the most common IoT full stack architecture with ordinary network prtocol stack, you may understand the difference between the ordinary IP stack and IoT stack and understand the relationship between 6LoWPAN and 802.15.4 more clearly. Just look into the following diagram and I think this diagram would explain almost everything at high level. Also, it would tell you what you need to study if you want to get into IoT technology.

 

OSI IP stack next to the 6LoWPAN stack, with IPv6 with LoWPAN over IEEE 802.15.4 MAC and PHY, and MQTT, CoAP, XMPP and HTTP/Web Socket as application protocols

The OSI IP stack and the 6LoWPAN stack layer by layer. The 6LoWPAN stack changes the network layer and everything below it, and it carries UDP and ICMP but no TCP at the transport layer.

Following diagram would show you the relationship between 802.15.4 and 6LoWPAN more clearly. In this diagram, MAC/PHY is based on 802.15.4 and Upper Layer is based on 6LoWPAN.

 

LoWPAN header and payload carried in the 802.15.4 MAC payload, which is carried in the PHY payload, next to the upper layer, MAC and PHY blocks joined by the MCPS, MLME, PD and PLME SAPs

The LoWPAN header and payload are carried inside the 802.15.4 MAC payload. The three RFC 4944 header types at the top are the subject of the Packet Structure section.

  • The PHY frame is a Sync Header (SHR), a PHY Header and a PHY Payload (PSDU). The drawing labels the PHY Header as MHR, but 802.15.4 calls it the PHR. MHR is the MAC header one layer up.
  • The MAC frame is a MAC Header (MHR), a MAC Payload and a MAC Footer (MFR), and it fills the PSDU.
  • The LoWPAN header and payload fill the MAC Payload.
  • On the right, the MAC talks to the upper layers through the MCPS SAP for data and the MLME SAP for management. The PHY does the same through the PD SAP and the PLME SAP.

The numbers explain why this adaptation layer has to exist at all. IPv6 requires a link MTU of 1280 octets. An 802.15.4 PHY packet is at most 127 octets. After the maximum MAC frame overhead of 25 octets, 102 octets are left for the MAC payload. With link-layer security in the maximum case, only 81 octets are left.

Now let's put an uncompressed IPv6 header into those 81 octets. The IPv6 header takes 40 octets, which leaves 41 octets. A UDP header takes another 8 octets, which leaves 33 octets for application data. So RFC 4944 needs two tools. Header compression shrinks the 40 octet IPv6 header, and fragmentation carries a 1280 octet packet across many small frames.

  • 802.15.4 is the link, 6LoWPAN is the adaptation : 6LoWPAN sits between IPv6 and the 802.15.4 MAC, inside the MAC payload.
  • The frame is tiny : 127 octets at the PHY, 102 octets of MAC payload, and 81 octets with maximum security.
  • IPv6 needs 1280 octets : the gap between 1280 and 81 is what fragmentation closes.
  • Uncompressed headers leave little room : IPv6 and UDP together leave 33 octets for data, which is why compression matters.

6LoWPAN Packet Structure

Like most other Network Layer protocol, the most important part of 6LoWPAN study is to understand its packet structure. There are so many different types of packet structure being used in various situations. It may not be possible to show you all the different packet structure and its operating mechanism in this single post. You would need to the related specification to figure out all the details. In this page, I will try to illustrate the big picture of the packet structure and interrelationships among different packets.

The first big picture that I want to show you is following diagram. In this picture, you may instantly figure out followings

  • There is Physical Layer frame at the bottom (This is 802.15.4 PHY frame and the details of this frame varies as well depending on the implementation)
  • The Payload part of 802.15.4 PHY frame is 802.15.4 MAC frame.
  • The Payload part of the MAC frame is 6LoWPAN packet.
  • There are several categories of 6LoWPAN packet is determined by the first two bits of the packet as illustrated below.
  • Depending on the categories specified by the first 2 bits of 6LoWPAN and the following 6 bits (called as Dispatch field) the details of the remaining structure varies.

 

The first two bits of the 6LoWPAN packet select Not a LoWPAN frame, IPv6 addressing header, mesh header or fragmentation header, followed by a 6 bit Dispatch, the network header and the payload

 

< Dispatch Type and Header >

 

RFC 4944 dispatch value table from NALP, IPv6, LOWPAN_HC1 and LOWPAN_BC0 to ESC, MESH, FRAG1 and FRAGN, with the reserved ranges between them

The dispatch table above is the RFC 4944 table, and RFC 6282 has changed part of it. RFC 6282 defines LOWPAN_IPHC, a new IPv6 header compression, and gives it 32 dispatch values, 01 100000 through 01 111111. It makes the LOWPAN_HC1 compression of RFC 4944 NOT RECOMMENDED. A new implementation may still decompress LOWPAN_HC1, but it should not send it. RFC 6282 also takes over the ESC value, and it reserves 01 000000 as the replacement for ESC.

The gain is large. In the best case, with link-local communication, LOWPAN_IPHC compresses the 40 octet IPv6 header down to two octets: the dispatch octet and one more LOWPAN_IPHC octet. When the packet is routed over several IP hops, the header is still only 7 octets.

RFC 8025 extends the table in another direction. It uses the bit pattern 11 11xxxx as a Paging Dispatch, where xxxx is a page number from 0 to 15. The dispatch values of RFC 4944 belong to Page 0, which is the default. A Paging Dispatch switches the parser to another page, where the same dispatch bits can mean something new.

< Mesh Addressing Type and Header >

 

Mesh addressing header: the 10 pattern, the V and F bits selecting a 64 bit or 16 bit originator and final address, a 4 bit Hops Left field, then the originator and final addresses

The mesh header lets a node forward a frame at the link layer, below IP. The V bit and the F bit each choose between an EUI-64 address and a 16 bit short address, for the originator and for the final destination. Every forwarding node decrements Hops Left, and a frame whose Hops Left reaches zero is not forwarded any further.

< Fragmentation Type and Header >

 

First fragment header with a 5 bit pattern, 11 bit datagram size and 16 bit datagram tag, and subsequent fragment header that adds an 8 bit datagram offset

Check one label in the fragmentation drawing against the dispatch table above it. The drawing starts both headers with 11000. That is right for the first fragment, which is FRAG1. RFC 4944 starts a subsequent fragment with 11100, which is FRAGN in the dispatch table. A receiver reads those five bits to decide whether a datagram_offset field follows, so the difference matters.

The three other fields work together during reassembly. The datagram_size field is the size of the whole IP packet before link-layer fragmentation, and it is the same in every fragment. The datagram_tag field is also the same in every fragment of one datagram, and the sender increments it for the next fragmented datagram. The datagram_offset field counts in units of 8 octets, and the first fragment leaves it out because its offset is always zero. A receiver groups fragments by the source address, the destination address, datagram_size and datagram_tag.

  • Two bits pick the header family : 00 is not a LoWPAN frame, 01 is a dispatch header, 10 is a mesh header and 11 is a fragmentation header.
  • LOWPAN_HC1 is out of date : RFC 6282 replaced it with LOWPAN_IPHC, on dispatch values 01 100000 through 01 111111.
  • LOWPAN_IPHC can shrink the IPv6 header to two octets : that is the best case, with link-local communication.
  • A subsequent fragment starts with 11100 : only the first fragment starts with 11000, and only a subsequent fragment carries datagram_offset.
  • The offset counts in 8 octet units : an 8 bit field is therefore enough for a 1280 octet packet.

Reference

[1] 6LoWPAN Seminar

[2] 6LoWPAN - The Wireless Embedded Internet by Zach Shelby, Carsten Bormann

[3] Embedded Internet and the Internet of Things WS 12/13

[4] RFC 4944 : Transmission of IPv6 Packets over IEEE 802.15.4 Networks, section 5 and the frame size figures in section 4

[5] RFC 6282 : Compression Format for IPv6 Datagrams over IEEE 802.15.4-Based Networks

[6] RFC 6775 : Neighbor Discovery Optimization for IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs), abstract only

[7] RFC 8025 : IPv6 over Low-Power Wireless Personal Area Network (6LoWPAN) Paging Dispatch