6LoWPAN

Thread

Thread is a standard from a group of more than fifty companies for a protocol running over 6LoWPAN to enable home automation. The specification is available at no cost as of 24 June 2022^[update], but paid membership is required to implement the protocol.^[5][6] Version 1.0 of the specification was published on 2015-10-29.^[5] The protocol most directly competes with Z-Wave and Zigbee IP.^[7] In IoT device communications using the Matter standard, Thread is one of two possible wireless transport layers.

Adapting the packet sizes of the two networks

IPv6 requires the link maximum transmission unit (MTU) to be at least 1280 octets.^[8] In contrast, IEEE 802.15.4's standard frame size is 127 octets. A maximum frame overhead of 25 octets and an optional but highly recommended security feature at the link layer poses an additional overhead of up to 21 octets are for AES-CCM-128. This leaves only 81 octets for the upper layers. Since this is so much less than 1280, 6LoWPAN defines a fragmentation and reassembly layer. Further, the standard IPv6 Header is 40 octets long, so header compression is defined as well.

Address resolution

IPv6 nodes are assigned 128 bit IP addresses in a hierarchical manner, through an arbitrary length network prefix. IEEE 802.15.4 devices may use either of IEEE 64 bit extended addresses or, after an association event, 16 bit addresses that are unique within a PAN. There is also a PAN-ID for a group of physically collocated IEEE 802.15.4 devices.

Differing device designs

IEEE 802.15.4 devices are intentionally constrained in form factor to reduce costs (allowing for large-scale network of many devices), reduce power consumption (allowing battery powered devices) and allow flexibility of installation (e.g. small devices for body-worn networks). On the other hand, wired nodes in the IP domain are not constrained in this way; they can be larger and make use of mains power supplies.

Differing focus on parameter optimization

IPv6 nodes are geared towards attaining high speeds. Algorithms and protocols implemented at the higher layers such as TCP kernel of the TCP/IP are optimized to handle typical network problems such as congestion. In IEEE 802.15.4-compliant devices, energy conservation and code-size optimization remain at the top of the agenda.

Adaptation layer for interoperability and packet formats

An adaptation mechanism to allow interoperability between IPv6 domain and the IEEE 802.15.4 can best be viewed as a layer problem. Identifying the functionality of this layer and defining newer packet formats, if needed, is an enticing research area. RFC 4944 proposes an adaptation layer to allow the transmission of IPv6 datagrams over IEEE 802.15.4 networks.

Addressing management mechanisms

The management of addresses for devices that communicate across the two dissimilar domains of IPv6 and IEEE 802.15.4 is cumbersome, if not exhaustingly complex.

Routing considerations and protocols for mesh topologies in 6LoWPAN

Routing per se is a two phased problem that is being considered for low-power IP networking:

• Mesh routing in the personal area network (PAN) space.
• The routability of packets between the IPv6 domain and the PAN domain.

Several routing protocols have been proposed by the 6LoWPAN community such as LOAD,^[9] DYMO-LOW,^[10] HI-LOW.^[11] However, only two routing protocols are currently legitimate for large-scale deployments: LOADng^[12] standardized by the ITU under the recommendation ITU-T G.9903 and RPL^[13] standardized by the IETF ROLL working group.^[14]

Routing

The 6LoWPAN routing scheme can be carried out in two different ways: mesh-under and route-over.

Mesh-under consists of implementing routing at the adaptation layer (which takes place between the link layer and the network layer of the model OSI), while route-over performs this implementation at the network layer (see 6LoWPAN routing scheme). In route-over, the IPv6 packet is reconstituted on each intermediate device in order to make the routing decision. Conversely, in mesh-under, the routing decision is made at the 6LoWPAN level and therefore only with fragments of the IPv6 packet. In this case, the IPv6 packet is only reconstituted on the recipient equipment. Therefore :

• mesh-under allows for a shorter transmission time;
• route-over is more effective in degraded conditions (packet loss).

Improved versions of mesh-under and route-over have been proposed :

• Controlled mesh under : By analyzing the contents of the header of the first fragment, equipment can know which fragments are expected next. If the next fragment received does not correspond to the expected fragment, the equipment requests its reissue;
• Enhanced route over A virtual circuit is created by associating the IPv6 address and the field datagram_tag from the header of the first fragment. The virtual circuit is then taken by all the fragments having the same datagram_tag.

Initially, several routing protocols were developed by the 6LoWPAN community, such as LOAD, DYMO-LOW , HI-LOW .

Today, only two protocols are legitimate for large deployments:

• LOADng (Lightweight On-demand Ad hoc distance-vector routing protocol – next generation), the successor to LOAD, a protocol mesh-under, standardized to the ITU within the recommendation ITU-T G.9903. This standard is used in particular within the program Linky communicating electricity meters.
• RPL (Routing Protocol for Low power and Lossy Networks, "routing protocol for LLN"), a protocol route-over, standardized within the ROLL working group from the IETF responsible for defining routing mechanisms for LLNs (Low Power and Lossy Network, "low power and lossy networks").

Device and service discovery

Since IP-enabled devices may require the formation of ad hoc networks, the current state of neighboring devices and the services hosted by such devices will need to be known. IPv6 neighbour discovery extensions is an internet draft proposed as a contribution in this area.

Security

IEEE 802.15.4 nodes can operate in either secure mode or non-secure mode. Two security modes are defined in the specification in order to achieve different security objectives: Access Control List (ACL) and Secure mode^[15]

Header compression

There RFC 4944 defines the IPv6 header compression mechanism for LowPAN: LOWPAN_HC1. It also includes compression of the UDP header over 4 bytes, but does not allow compression of the Checksum. Additionally, it restricts the range of UDP ports from 61616 to 61631 in order to compress this value to 4 bits.

This IPv6 header compression can only be applied to local link addresses. To overcome this problem, an IETF LOWPAN_HC1g draft was published. LOWPAN_HC1g applies to global addresses for IP multi-hop communications. These two compression mechanisms (LOWPAN_HC1 and LOWPAN_HC1g) are complementary. It is therefore necessary to implement both.

Today the proposal of the 6LoWPAN group is to use LOWPAN_IPHC. It replaces LOWPAN_HC1 and LOWPAN_HC1g. IPHC bytes result from compression of the IPv6 header. They mainly integrate information from quality of service (DSCP and ECN), next headers, number of hops and compressed source/destination addresses.

With LOWPAN_IPHC the compression rate depends on the type of communication :

• For communications over a local link, the IPv6 header can be reduced to 2 bytes (1-byte Dispatch and 1-byte LOWPAN_IPHC).
• For communications requiring multiple IP hops, the header can be compressed to 7 bytes (1-byte Dispatch, 1-byte LOWPAN_IPHC, 1-byte Hop Limit, 2-byte Source Address, and 2-byte Destination Address).

The example below shows the increase in payload compared to the original problem (see 1^re figure). This payload is in the best case 70 to 75 bytes. Indeed, if we add the fragmentation information as indicated in the paragraph above, it will decrease to 65-70 bytes for this scenario.