|This article needs additional citations for verification. (January 2011)|
The 6LoWPAN concept originated from the idea that "the Internet Protocol could and should be applied even to the smallest devices," and that low-power devices with limited processing capabilities should be able to participate in the Internet of Things.
The 6LoWPAN group has defined encapsulation and header compression mechanisms that allow IPv6 packets to be sent and received over IEEE 802.15.4 based networks. IPv4 and IPv6 are the work horses for data delivery for local-area networks, metropolitan area networks, and wide-area networks such as the Internet. Likewise, IEEE 802.15.4 devices provide sensing communication-ability in the wireless domain. The inherent natures of the two networks though, are different.
The target for IP networking for low-power radio communication are applications that need wireless internet connectivity at lower data rates for devices with very limited form factor. Examples could include, but are not limited to: automation and entertainment applications in home, office and factory environments. The header compression mechanisms standardized in RFC6282 can be used to provide header compression of IPv6 packets over such networks.
IPv6 is also in use on the smart grid enabling smart meters and other devices to build a micro mesh network before sending the data back to the billing system using the IPv6 backbone. Some of these networks run over IEEE 802.15.4 radios, and therefore use the header compression and fragmentation as specified by RFC6282.
Thread is an effort of over 50 companies to standardize on a closed-source, royalty-free protocol running over 6LoWPAN to enable home automation. It is to be launched in the second half of 2015[update]. The protocol will most directly compete with Z-Wave and Zigbee IP.
As with all link-layer mappings of IP, RFC4944 provides a number of functions. Beyond the usual differences between L2 and L3 networks, mapping from the IPv6 network to the IEEE 802.15.4 network poses additional design challenges (see RFC 4919 for an overview).
- Adapting the packet sizes of the two networks
- IPv6 requires the maximum transmission unit (MTU) to be at least 1280 Bytes. In contrast, IEEE 802.15.4's standard packet size is 127 octets. A maximum frame overhead of 25 octets spares 102 octets at the media access control layer. An optional but highly recommended security feature at the link layer poses an additional overhead. For example, 21 octets are consumed for AES-CCM-128 leaving only 81 octets for upper layers.
- 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.
- 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.
- 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
- Interoperability of 6LoWPAN
- 6LoWPAN Ad Hoc On-Demand Distance Vector Routing (LOAD)
- Dynamic MANET On-demand for 6LoWPAN (DYMO-low) Routing
- Hierarchical Routing over 6LoWPAN (HiLow)
- LowPan Neighbor Discovery Extensions
- Serial forwarding approach to connecting TinyOS-based sensors to IPv6 Internet
- GLoWBAL IPv6: An adaptive and transparent IPv6 integration in the Internet of Things Download
- IETF Standardization in the Field of the Internet of Things (IoT): A Survey Download
- In 6LoWPAN: The Embedded Internet (Wiley, 2009), Shelby and Bormann redefine the 6LoWPAN acronym as "IPv6 over lowpower wireless area networks," arguing that "Personal" is no longer relevant to the technology.
- Mulligan, Geoff, "The 6LoWPAN architecture", EmNets '07: Proceedings of the 4th workshop on Embedded networked sensors, ACM, 2007
- Zach Shelby and Carsten Bormann, "6LoWPAN: The wireless embedded Internet - Part 1: Why 6LoWPAN?" EE Times, May 23, 2011
- Higginbotham, Stacey. "This week's podcast unravels the secrets of Thread and HomeKit". gigaom.com. gigaom. Retrieved 30 January 2015.
- Sullivan, Mark. "Nest, Samsung, ARM and others launch 'Thread' home automation network protocol". http://venturebeat.com. venture beat. Retrieved 30 January 2015.