Previously, we discussed Contiki, an operating system (OS) for Internet Protocol (IP) based wireless sensor networks (WSNs) and embedded devices. In this blog we will examine the use of IP for smart objects and 'The Internet of Things' in more detail.

A smart object is a small computing device that will also have a sensor or actuator as well as a means of communication - mostly, but not always, wireless communication. Smarts objects are embedded in other larger objects and systems including industrial machinery, car engines and lighting and heating systems. Smart objects are the technical drivers behind the smart ecosystems that are emerging in many diverse environments and applications and are the enablers of innovations in monitoring and automation for homes and industrial plants as well as the smart grid and energy efficiency systems. The potential application domains for smart objects is vast - from ad-hoc emergency response systems to smart transport infrastructure for urban areas.

The key property of a smart object is its capacity for bidirectional communication. Diverse measurements can be taken of environmental characteristics such as humidity, temperature, wind speed, pressure, vibration and energy consumption. In addition to measurements, the sensors in smart objects can also perform detection of elements in an environment such as pollutants or the presence of a chemical.

Smart objects are generally low-powered battery operated devices and will have a CPU and memory. Their form factor is small and the goal is that their price should be low - this was not always the case with wireless sensors but prices have lowered in recent years.

There are many protocols available for enabling wireless communication in a network of smart objects. Zigbee (http://www.zigbee.org) is a low-cost and low-power radio communications protocol based on the 802.15.4 standard for Wireless Personal Area Networks (WPANs). 6LowPAN (http://www.6lowpan.org/) also uses the 802.15.4 standard but uses IP with the aim of achieving the wireless 'Internet of Things'. 6LoWPAN stands for IP version 6 (IPv6) over Low Power Wireless Personal Area Networks. The IPSO Alliance (http://www.ipso-alliance.org) promotes this use of IP for smart objects and, indeed, there are many good arguments for using the existing IP protocol.

IP is an well-established open standard and is media independent which means it can run over low-powered radios such as 802.11 WiFi, long range 3G (Third Generation) telephony as well as ethernet among others. Best effort or reliable transmission is available using UDP (User Datagram Protocol) or TCP (Transmission Control Protocol) respectively. Recent implementations such as uIP have shown that IP is a lightweight protocol and its versatility means it supports any type of application and in turn is supported by a diverse range of devices from high-end servers to smart phones. This versatility has led to IP's ubiquity and over its comparatively long life its has showm itself to be stable (after all, it is used for the Internet), manageable (using protocols such as Dynamic Host Configuration Protocols - DHCP, Domain Name System - DNS and Simple Network Management Protocol - SNMP) and provides end-to-end communication.  

These cogent arguments are made by the IPSO Alliance to advance the case for using IP in smart ecosystems. IPv6 is used in particular as it contains a number of optimisations for constrained devices, a category in which most smart objects will find themselves due to their unavoidable processing and memory limitations. Stateless compression of IPv6 headers is possible which means that smart objects can communicate with their neighbour in this compressed form. Packets can be fragmented and neighbouring smart object nodes can be discovered. The Internet Engineering Task Force (IETF) has defined these properties in the 6LoWPAN adaptation layer.

IPv6 was designed to counter the ever dwindling number of unallocated IP addresses. Its key feature is that it expands the IP address space from 32 to 128 bits. The development of IPv6 was vital as the number of computers will ultimately be far outstripped by networked devices and smart objects. A number of features has also been introduced to improve performance. The size of the Maximum Transmission Unit (MTU) has been increased from 576 to 1280 bytes and fragmentation is now implemented at the endpoints rather than in intermediate routers. A scoped multicast for broadcasting to all hosts with a multicast group is also included.

Despite these improvements, supporting IPv6 over LoWPAN networks is not a straightforward task as the frames used in LoWPAN are approximately one-tenth of the size of IPv6's minimum MTU which makes fragmentation and compression mandatory. Furthermore, the 802.15.4 standard upon which LoWPAN is based is low-power and low-throughput and is prone to failures and interference. Finally, a LoWPAN network is a mesh network of short-range connections which is contrary to the expected typical IPv6 architecture. It is for these reasons that the 6LoWPAN working group was established by the IETF. 6LoWPAN defines how IPv6 communication is transported in 802.15.4 frames. In addition to the optimisations in fragmentation and header compression described earlier, 6LoWPAN supports layer-2 forwarding between the link-level addresses of the end of an IP hop.

Despite the development of the 6LoWPAN format specification, implementation was not considered by the IETF working group. There are also a number of issues that must be considered for LoWPAN environments. There are typically a large number of devices that are embedded in the environment or infrastructure and so cannot be moved to improve communication. Multi-hop routing is therefore used to extend range and avoid the many obstacles that can be present in an environment. Link quality can also be variable due to interference and environmental factors. Effective routing is thus a necessity in such a situation. Moreover, certain applications may require device mobility. In many cases, the devices may not be moving a particularly long distance but do respresent a change in the LoWPAN's topology. Power management is not comprehensively defined in the 802.15.4 specification but must be considered for routing in commercial applications.

One issue to note when considering IPv6 over LoWPAN is Mesh-Under (Layer 2) and Route-Over (Layer 3) Forwarding.  With mesh-under the forwarding and routing of packets within the LoWPAN is carried out at the adaptation layer and no IP-routing takes place at the network layer.  Route-over performs routing at the IP layer and each smart object node serves as an IP router.

The number of smart objects in a LoWPAN is potentially vast. Each of these objects will require an address. Again, the IPSO Alliance argues that the easiest mechanism for doing this assignment and connecting these nodes to each other is to use IPv6.  IPv6's Neighbour Discovery (ND) Protocol is used to resolve and automatically configure addresses as well as to discover routers and determine the reachability of neighbours. The IETF 6LoWPAN working group is currently working on  ND optimisations for 6LoWPAN environments. The considerations the working group has to take into account include the continously changing wireless link. the often lengthy sleep mode of the networked devices, the battery and processing constraints of the devices and the often mobile nature of the nodes. In essence, the 6LoWPAN ND Protocol extends the standard IPv6 ND Protocol and has added functionality to take mobility and fault tolerance into account. The final protocol will support both Rroute-Over and Mesh-Under networks.

There are a number of alternatives to using 802.15.4 for smart object communications. The use of low-power Wi-Fi and Broadband over Powerlines are other possibilities.The latter is particularly attractive as it uses the existing electricity network which means that a computing device can be networked by plugging it into any electrical outlet. No matter the physical medium used for transmission, however, IP would appear to be the appropriate choice for carrying the data generated by smart objects. Otherwise, the consequent loss of standardisation between LoWPANs would necessitate protocol translation gateways to enable different networks to communicate with each other. Given the predicted explosion in smart objects and networks in the coming years, this is an expensive and unattractive proposition from both a technical and financial perspective.