12.1 Introduction

IPv6 over Low‐Power Wireless Personal Area Networks (6LoWPAN) is a protocol defining flow of Internet Protocol Version 6 (IPv6) packets over a resource‐constrained, low‐power, and short‐range wireless network. Low‐power wireless personal area networks are based on the IEEE 802.15.4 standard. IEEE 802.15.4‐compliant devices have short communication range and limited bandwidth, memory, processing power, and energy requirements. Based on these restrictions, it is generally assumed that 6LoWPAN transmits a small amount of data, but the protocol has no restriction on the amount of data that it can transmit [1]. These networks are also referred to as low‐power and lossy networks (LLNs), as the nodes are highly constrained and the characteristics of the network, radio links, and nodes lead to unstable connectivity [2]. 6LoWPAN aims at extreme network scalability and providing IP‐based connectivity even to the smallest of sensors and actuators that have a requirement to communicate among each other or with the external world over the Internet.

12.1.4 ZigBee vs 6LoWPAN

A few major differences between Zigbee and 6LoWPAN are listed below:

• 6LoWPAN is an alternative to ZigBee and is an open network based on Internet Protocol. 6LoWPAN already has an open‐source version and provides easily implementable models for Internet connectivity [19].
• ZigBee standardizes application profiles but still has a few drawbacks in networking, while 6LoWPAN has better networking with IPv6, but lacks application standard interoperability [8].
• The network header in 6LoWPAN comprises dispatch and header compression HC1 and HC2, followed by hop count and UDP header, while the ZigBee APDU frame format [5] comprises frame control bit fields, destination endpoint, cluster identifier, profile identifier, source endpoint, and APS counter in its network header.
• As reported in a survey [8], among the shipped IEEE 802.15.4 chips, about 55% support 6LoWPAN, while only 30% support ZigBee.

Figure 12.1 shows the difference between the ZigBee and 6LoWPAN stacks.

12.2 6LoWPAN Fundamentals

6LoWPAN has attractive features of autoconfiguration, IPv6 fragmentation, mesh forwarding, mobility support, and up to 80% header compression. It can support various types of radio link, such as IEEE 802.15.4, IEEE 802.15.4a, and even a low‐bandwidth powerline [8]. The major characteristics of LoWPAN are its small packet size, provision for 16 bit as well as 64 bit MAC address, low bandwidth as defined in ZigBee radio, support of star and mesh topology, low power consumption, low cost, tremendous scalability, mobile and random deployment, and secured network connectivity even with non‐cooperative and compromised devices. As the physical layer can support a maximum packet size of 127 bytes, this leads to a maximum frame size of 102 bytes in the MAC layer. The security protocols available in IEEE 802.15.4 are AES‐CCM‐32, AES‐CCM‐64, and AES‐CCM‐128, which have headers of 9, 13, and 21 bytes respectively. This finally leaves 81 bytes for the data [1]. IEEE 802.15.4 supports two types of addressing – 64 bit and 16 bit addressing. The 16 bit address is allocated to a device only after its association with a PAN coordinator [20] or other nodes in the PAN, and the address is unique only within that particular PAN.

The design space of 6LoWPAN is varied [2]. The nodes can be deployed in an organized manner or scattered, and they can be deployed all at one time or incrementally, making it highly scalable. The network may comprise a few nodes to several thousand nodes. This leads to varying density of nodes and change in their locations. The nodes in the 6LoWPAN are ‘always connected’, but certain nodes may be under hibernation while others may come in the transmission range or leave the signal availability region owing to their mobility. This leads to difficulty in determining the active nodes in the network. It supports star as well as mesh topology. A single hop may be sufficient for communication in a star topology, while multihop data transmission with routing capabilities is required for a mesh or hierarchical topology. Researchers have reported various routing mechanisms suitable for LoWPAN, some of which are localization based, reputation based, topographical, data centric, address centric or event driven. The data transmission pattern may be point to point (P2P), point to multipoint (P2MP), or multipoint to point (MP2P), depending on the usage, architecture, and routing pattern. If the LoWPAN is assigned for a strategic application, security considerations and QoS have to be ensured in the resource‐constrained lossy network.

12.2.1 Architecture

IEEE 802.15.4 defines two types of node – FFD and the RFD. However, in the case of LoWPAN the nodes are distinguished as LoWPAN hosts, LoWPAN routers, and LoWPAN mesh nodes [2]. The LoWPAN hosts are the end nodes, which are the source or sink nodes for IPv6 datagrams and can comprise FFDs or RFDs. The LoWPAN routers and the LoWPAN mesh nodes are FFDs and help in data transmission between the source and destination nodes by appropriate forwarding of data in multihop mode. The LoWPAN routers operate in the IP layer and perform routing. The edge routers connect the LoWPAN to other IP‐based networks or other LoWPAN networks. The mesh nodes operate on top of the link layer for the forwarding of data using link addresses. The 6LoWPAN stack [21] has the 6LoWPAN‐specific applications at the top, using the socket interfaces to connect to the TCP/UDP at the next layer, followed by IPv6 and the adaptation layer just below it, which makes 6LoWPAN utilize the IP over IEEE 802.15.4. The last two layers are those defined in IEEE 802.15.4 and are its link layer and physical layer.

Gateways are devices that have the IPv6 network and the IEEE 802.15.4 network at their two ends. Each PAN can have its own gateway or multiple PANs can have a common gateway [20]. The gateway implements the adaptation layer function [22]. The gateways also perform address translation between IPv6 and the 16 bit/64 bit address to make the addresses compliant with the IPv6 network and the IEEE 802.15.4 network. A typical network diagram showing the network connectivity of a 6LoWPAN with the Internet through a gateway is shown in Figure 12.2.

12.2.4 Neighbor Discovery

The 6LoWPAN has lossy, short‐range, low‐bandwidth, and low‐power links with sleeping nodes, and thus multicasting cannot be used for neighbor discovery as in the case of IPv6. The process of neighbor discovery in IPv6 has been described in RFC 4861 [25], along with the process of router advertisement and discovery, neighbor advertisement and solicitation, redirection, address resolution, and duplicate address detection. However, this cannot be used for 6LoWPAN as it has two types of addressing scheme – 16 bit addressing and 64 bit addressing, the network does not have multicast capability at the link layer, the sleeping nodes do not respond to signaling messages, a node may periodically change its parent for routing, and the datagram requires fragmentation and header compression.

Various optimizations have to be made to IPv6 neighbor discovery to make it suitable for 6LoWPAN [26]. It avoids multicast flooding, minimizes link‐local multicast frequency, uses whiteboard in edge routers for duplicate address detection, duplicate address detection is across the entire 6LoWPAN, and next‐hop determination is simplified, but neighbor unreachability detection is not performed, address resolution is not performed, and node registration and whiteboard resolution have to be introduced afresh. Contextual‐information‐transformation‐based service discovery architecture for a 6LoWPAN can be used to locate a service in the proximity of the node [27]. The mechanism works even in a 6LoWPAN Internetworked with an external IP network and can discover user‐defined services from within the 6LoWPAN as well as outside it.

When a node comes in an LoWPAN, it listens to the router advertisements from the routers in the network or broadcasts a router solicitation expecting a response from any local router. On receiving the router advertisement, the node gets an address by stateless address autoconfiguration and selects its default router. Thereafter the node sends a unicast node registration message to the edge router directly or through intermediate routers to register itself with the edge router, to which the edge router replies with a node confirmation either directly or through the intermediate routers and makes an entry of it in its whiteboard. This makes the node a part of the 6LoWPAN and ready for communication [17, 26] to any IPv6 node either within the LoWPAN or outside it. However, intermediate routers are not available in ‘mesh under’ configuration.

In addition to the process of the router transmitting periodic advertisements of node discovery, there are two other modes of node and service discovery supported by 6LoWPAN. In the second mode of node discovery, a sensor, after coming into the PAN, sends beacons to which a sink node may listen and perform the registration of the node, and the docking node receives a TTL from the sink node and becomes a part of the network. In this case the sink node has information about all the nodes in the network and does not require a method for node removal as it uses TTL. However, it is difficult to calculate an optimal TTL. Alternatively to these two modes, RFID may be used for neighbor discovery as it saves all broadcast messages, but requires integration of RFID with 6LoWPAN. These three types of node and service discovery are described as the YouCatchMe, ICatchYou, and Some1CatchMe approaches respectively [28] and are depicted in Figure 12.3.

12.3 Interoperability of 6LoWPAN

With increase in the applications of 6LoWPAN, the requirement for mobility of nodes among various PANs and the interoperability of 6LoWPAN is increasing. A sensor mode may move from one 6LoWPAN network [39] to another, but as the related devices are energy constrained, it is challenging to support such mobility as it involves handoff techniques, authentication, and information exchange and storage. The mobility‐related tasks should be delegated to the PAN coordinator or some other FFD in the network, depending on the resources available to the device. The mechanism for supporting mobility should be incorporated in the adaptation layer and not the IP layer, as it reduces the number of bits transmitted over the radio channel by the 6LoWPAN device. The inter‐PAN handover time should be minimum, and it should have awareness about the surrounding PANs to enhance the reliability of the visiting node.

A few major research studies reported in the field of 6LoWPAN interoperability are as follows:

• A model for interoperability between NEMO [40] and 6LoWPAN has been suggested with a routing scheme to support the network mobility [9, 41].
• Internetworking between ZigBee and 6LoWPAN [42] using IPv6 prefix delegation, IPv6 multicast, and extended IP switching.
• Use of 6LoWPAN in IPv4 networks [43] by adding two more values in the prototype tag in the adaptation layer for IPv4 and compressed IPv4 and adding for IPv4 and IPv6 a dual stack in the gateway. NAT is incorporated to support IPv4 for the huge number of sensors.

An inter‐PAN mobility support mechanism has been suggested [20] by providing a distributed version of the inter‐PAN mobility scheme [44]. It assumes that each PAN has a unique PAN ID, and has different communication frequency ranges and a separate gateway that connects it to the external IP network. Gateways are responsible for fragmentation and reassembly of IP packets to make them IEEE 802.15.4 frame size compliant. When a mobile node enters a 6LoWPAN, it detects the frequency range of the PAN and associates itself with any node (parent) in the network, and this information is sent by the parent to the gateway with the 16 bit address of its parent and the fixed ID of the mobile node. The gateway maintains binding information of all the mobile nodes and their parents and updates this information to the other gateways in the domain, including the parent gateway of the mobile node.

The mobile node may disassociate from its parent and may associate with some other node (parent) within the same PAN, thus changing the binding information in its gateway, but such types of update occurring within a PAN are not updated with the other gateways. The mechanism has provision for inter‐PAN communication where two mobile nodes in different PANs communicate with each other, as well as interdomain communication, which is used to forward a data packet received at the home network of the PAN to the mobile node where it is presently available. HMIPv6 [45], FMIPv6, and MIPv6 [46] are a few tunnel‐based mobility protocols that prevent packet losses during mobility and help in continuity of communication with the outer world during mobility [20]. These are host‐based protocols in which the IP layer carries the mobility‐related packets [47].

The gateway architecture of 6LoWPAN routing [35] supports interoperability between 6LoWPAN and external IPv6 networks. This is achieved through compressing or decompressing the IPv6 packets and mapping the IEEE 802.15.4 16 bit addresses with the IPv6 address [9].

12.4 Applications

There is an increasing market demand for IEEE 802.15.4 chips. Millions of IEEE 802.15.4 chips are being manufactured and shipped annually, and this value is expected to rise with a growth rate of 20–30% [8]. The 6LoWPAN Working Group has set out in detail in its Internet Draft on Design and Application Spaces for 6LoWPAN its various application domains in the field of industrial monitoring [19], structural monitoring, healthcare, networked home [21, 48], childcare [9], vehicular telematics, agricultural monitoring [2], energy metering [8, 49], situational awareness and precision asset tracking for defense or firefighting [50], and environmental monitoring and sensing [20]. A sequence diagram depicting the data communication between a smart soldier and a smart weapon system fitted with a variety of sensors is depicted in Figure 12.4. These communications are in very short range and require much less data transmission. The actual data is not transmitted over the network, rather trigger signals are transmitted on threshold values, and hence it can be supported well by a 6LowPAN. Some of the other applications of 6LoWPAN are discussed below.

1. Industrial automation. There are a number of application fields in industrial monitoring to reduce the downtime of machinery and automate the process of equipment monitoring and data transfer and analysis. Industrial monitoring involves various requirements such as process control and monitoring, equipment surveillance, asset tracking, and monitoring of the storage environment for temperature, humidity, and pressure critical stocking requirement.
2. Strength and security of structures. Structural monitoring using 6LoWPAN provides real‐time monitoring of critical infrastructure or of structures under extreme temperature, pressure, or radiation effects leading to deterioration of the strength of the material and fatigue. Such networks provide efficient, routine, and reliable monitoring of structures. The network can also be used for security monitoring of structures.
3. Wireless patient and hospital monitoring. In the case of health care management, it can be effective in patient monitoring as well as hospital management. Patients may be fitted with various sensors forming a wireless body sensor network (WBSN) [20] to track their health status in a non‐invasive manner (to track motion, temperature, heart beat, or pulse rate) or in an invasive manner (to track blood content or nervous, digestive, or respiratory system) [51]. This leads to a wireless patient monitoring environment in an intensive care unit of the hospital. In hospital management, it can be used to maintain the temperature and humidity of the storage for blood and medicine. It can alert about depleting pressure in oxygen cylinders, increase in suspended material in the hospital environment as a result of pollution, which can effect patient health, tracking of hospital equipment, and timely consumption of medicine by patients.
4. Convenient homes. Smart and convenient homes [9] deploy the technology to integrate smart devices in the home and connect them to the Internet for information exchange. It is used for the surveillance and safety of houses, maintenance of gardens, health monitoring of occupants, and control of home appliances, light and temperature, and entertainment systems.
5. Agricultural support. Sensors can be fitted on farms to monitor the temperature, water level, humidity, and soil condition of farmland. Humidity sensors can activate sprinkler actuators to manage the sprinklers to maintain the water level on the farm. The soil sensors can generate an alarm on depletion of minerals in the soil that are specifically required for a particular crop, thus making it easier to decide on the type of fertilizer and its area of spread. The crop condition can also be forwarded to a centralized data processing center, which can analyze the data to predict the crop yield and arrange for its market accordingly.
6. Management of transportation system. The sensors can be incorporated in vehicles to track the health of the vehicle. They can be fitted in traffic lights, roadside base stations, highway patrol vehicles, emergency service vehicles such as tow vehicles or ambulances, and approaching petrol pumps. The network provides a variety of safety and entertainment services along with traffic flow optimization and path guidance for traffic and accident avoidance.
7. Real‐time meter reading. Automated meter reading (AMR) provides real‐time meter reading to the consumer and can be utilized to device intelligent applications for real‐time consumer information, demand response, and building automation. 6LoWPAN can be used to provide an end‐to‐end IP‐based communication infrastructure between the meter and the power station and the automation system. 6LoWPAN is made available at the meters with gateway routers connecting it to a backbone Ethernet or cellular network [49]. The technology can be used for electric, water, or gas meters for domestic usage or in vehicle meters for vehicular telematics applications.

The home automation network may not have a very critical data transmission requirement demanding a QoS, but the security and surveillance system should ensure authentication, availability, and secrecy. Moreover, when the home grid gets connected to the Internet for data exchange through a 6LoWPAN edge router, which acts as a gateway to the Internet, security considerations become critical, and security protocols should be used at various levels, such as PKI and IPSec, in addition to the AES provided by IEEE 802.15.4. The 6LoWPAN also has a promising role to play in vehicular networks.

12.5 Security Considerations and Research Areas

The applications running over 6LoWPAN should ensure integrity, confidentiality, and authentication. The network should be free from malicious nodes and from active as well as passive attacks, such as denial of service, spoofing, and man‐in‐the‐middle attacks. These network security features can be provided at various layers of the network, starting from the application layer to the physical layer. 6LoWPAN utilizes the AES‐based link layer security of IEEE 802.15.4. However, the protocol does not specify any details about key management or security in higher layers. Although IEEE 802.15.4 provides link layer security to 6LoWPAN, it should also address other security aspects such as secured bootstrapping of a node in the network, key establishment, key exchange, and key management [1]. It should also adopt scaled‐down versions of TLS, IPSec, SSL, and WEP to make it IP‐based sensor network compliant [8]. Various crypto suites should also be scaled down and tested for their suitability in 6LoWPAN.

The security requirement differs with the type of 6LoWPAN application [2]. In safety‐critical use, such as structural monitoring, QoS has to be ensured along with secured transmission. The integrity of the data is critical in such cases, as a change in the data can lead to a wrong diagnostic of the strength of the building. In the case of secured home or hospital networks connected to the Internet, data exchange about depleting products and online ordering on the Internet require authentication and non‐repudiation. A lighter version of PKI can be used in such cases. Patient monitoring systems should ensure privacy of the patient data and role‐based access to the data.

The interface identifier obtained from the MAC address is used to provide a unique identification, but it has no mechanism to prevent its duplication by an attacker. The LoWPAN hosts used in sensing and security applications have more RFDs than FFDs, and these RFDs are resource constrained, implement the minimum security features, and rely on AES encryption and authentication. The issue of secure configuration and management [22] during field installations should be addressed, along with end‐to‐end security in the case of communication with IPv6 peers.

As 6LoWPAN transmits through radio links, it is vulnerable to spoofing, altered routing, and other attacks faced by a wireless network [35, 52]. The nodes are deployed in the field and are susceptible to tampering, capture, or cloning. As the 6LoWPAN forms a multihop network with lossy links and slow transmission, this leads to delay in detection of attacks. In order to ensure confidentiality, authentication, integrity, and time stamping, time synchronization, authenticated broadcasts, link verification, and secure self‐organization of the multihop routing are required, in addition to the MAC layer AES cryptography.

A list of goals that should be accomplished to incorporate the best practice for transmitting IP packets and the related protocols of the upper layers has been documented by IETF in its RFC 4919 [1]. Although advances have been made with respect to some of the goals, the majority of them still require further research:

• A fragmentation and reassembly layer below the IP layer can be developed to synchronize the mismatch in the packet size of IEEE 802.15.4 and IPv6 [53]. The existing protocol leaves far fewer bytes for data transmission and calls for excessive fragmentation and reassembly even in the case of a small data packet.
• The header compression techniques can be more standardized with respect to 6LoWPAN, and if the existing header compression techniques do not meet the requirements, fresh specifications can be framed.
• An interface identifier can be generated for each IEEE 802.15.4 device so as to make stateless address autoconfiguration simpler.
• Routing protocols should be tailor made for 6LoWPAN so as to enable the routing packet to be of an appropriate size to fit in a IEEE 802.15.4 frame [52].
• Network management protocols should be developed that have less overhead but can support a densely populated network. SNMPv3 or a mutation of it should be rigorously tested for its effectiveness of usage in 6LoWPAN.
• The heavyweight application protocols, such as SOAP, HTML, HTTP, XML, and REST, can be compactly encoded [54] to make them suitable for transmission over 6LoWPAN.

References

1. 1 N. Kushalnagar, G. Montenegro, and C. Schumacher. IPv6 over low‐power Wireless Personal Area Networks (6LoWPANs): overview, assumptions, problem statement, and goals, Request for Comments: 4919.
2. 2 E. Kim, N. Chevrollier, D. Kaspar, and J. P. Vasseur. 6LoWPAN Working Group Internet‐draft, Design and Application Spaces for 6LoWPANs, Version 4, 1 October 2012.
3. 3 A. Dunkels and J. P. Vasseur. White Paper No. 1: IP for smart objects, Internet Protocol for Smart Objects (IPSO) Alliance, September 2008. www.ipso‐alliance.org.
4. 4 D. Culler. Secure, low‐power, IP‐based connectivity with IEEE 802.15.4 wireless networks, industrial embedded systems, 2007. http://www.archrock.com/downloads/resources/ArchRock.Sum07.pdf
5. 5 D. E. Culler and J. Hui. IP on IEEE 802.15.4 low‐power wireless networks. http://www.cs.berkeley.edu/~jwhui/6lowpan/6LoWPAN‐tutorial.pdf.
6. 6 J. W. Hui and D. E. Culler. Extending IP to low‐power, wireless personal area networks. IEEE Internet Computing, 12(4):37–45, 2008.
7. 7 R. Braden. Requirements for Internet Hosts – Communication Layers, 1989, RFC 1122.
8. 8 Z. Shelby. What future for 6LoWPAN?, October 2008, ftp://ftp.cordis.europa.eu/pub/fp7/ict/docs/necs/20081022‐wsnnco‐04‐zshelby_en.pdf.
9. 9 C. S. Hong. Interworking between sensor networks and IPv6 network. http://ngn.cnu.ac.kr/core2006/core_2006_ppt/ChoongseonHong.pdf.
10. 10 S. C. Ergen. ZigBee/IEEE 802.15.4 summary, 2004. http://www.sinemergen.com/zigbee.pdf.
11. 11 ZigBee Alliance. www.ZigBee.org.
12. 12 M. Othman. Principles of Mobile Computing and Communication, pp. 83–106, Auerbach Publications, New York, 2007.
13. 13 LAN‐MAN Standards Committee of the IEEE Computer Society, Wireless medium access control (MAC) and physical layer (PHY) specifications for low‐rate wireless personal area networks (LR‐WPANs), IEEE, 2003.
14. 14 R. Poor. Information on the IEEE 802.15.4‐2006 revised standard. http://grouper.ieee.org/groups/802/15/pub/TG4b.html.
15. 15 D. E. Culler. Embedded web services and industrial instrumentation standards. http://www.eecs.berkeley.edu/~culler/WEI/lectures/L11‐embedded‐web.ppt.
16. 16 X. Ma and W. Luo. The analysis of 6LoWPAN technology. IEEE Pacific‐Asia Workshop on Computational Intelligence and Industrial Application, PACIIA, volume 1, pp. 963–966, 2008.
17. 17 G. Mulligan and C. Bormann. IPv6 over low power WPAN WG (6LoWPAN), July 2009. http://tools.ietf.org/agenda/75/slides/6lowpan‐0.pdf.
18. 18 N. Krichene and N. Boudriga. Mesh networking in wireless PANs, LANs, MANs, and WANs, in Y. Zhang, J. Zheng, and H. Hu (eds). Security in Wireless Mesh Networks, Auerbach, 2007.
19. 19 W. Webb. Move over ZigBee, make room for 6LoWPAN, 2 August 2007. http://www.edn.com/blog/1710000171/post/640012664.html.
20. 20 G. Bag, H. Mukhtar, S.M. Saif Shams, K.H. Kim, and S. Yoo. Inter‐PAN mobility support for 6LoWPAN. Third International Conference on Convergence and Hybrid Information Technology, ICCIT 2008, volume 1, pp. 787–792, 2008.
21. 21 6LoWPAN technical overview. http://www.mindteck.com/images/6LoWPAN_overview.pdf.
22. 22 G. Montenegro, N. Kushalnagar, J. Hui, and D. Culler. Transmission of IPv6 packets over IEEE 802.15.4 networks, RFC 4944.
23. 23 P. Karn, C. Bormann, G. Fairhurst, D. Grossman, R. Ludwig, J. Mahdavi, G. Montenegro, J. Touch, and L. Wood. Advice for Internet subnetwork designers, RFC 3819, 2004.
24. 24 S. Deering and R. Hinden. Internet Protocol, Version 6 (IPv6) specification, RFC 2460, 1998.
25. 25 T. Narten, E. Nordmark, W. Simpson, and H. Soliman. Neighbor Discovery for IP Version 6 (IPv6), RFC 4861, 2007.
26. 26 Z. Shelby (ed.), P. Thubert, J. Hui, S. Chakrabarti, C. Bormann, and E. Nordmark. Internet‐draft, 6LoWPAN neighbor discovery, draft‐ietf‐6LoWPAN‐nd‐06, 6LoWPAN Working Group, 22 September 2009.
27. 27 S. H. Chauhdary, M. Cui, J. H. Kim, A. K. Bashir, and M. Park. A context‐aware service discovery consideration in 6LoWPAN. Proceedings of the 2008 Third International Conference on Convergence and Hybrid Information Technology, Volume 1, 11–13 November 2008, ICCIT, pp. 21–26, IEEE Computer Society, Washington, DC, 2008.
28. 28 R. Mendão Silva. Wireless sensor networks – node discovery and mobility. http://rtcm.inescn.pt/fileadmin/rtcm/Workshop_23_Jun_09/s2p2.pdf.
29. 29 M. Dohler, T. Watteyne, T. Winter, and D. Barthel. Routing requirements for urban low‐power and lossy networks, RFC 5548, 2009.
30. 30 B. Chen, K. Muniswamy‐Reddy, and M. Welsh. Ad‐hoc multicast routing on resource‐limited sensor nodes. Proceedings of the 2nd International Workshop on Multi‐Hop Ad Hoc Networks: from Theory To Reality, REALMAN ’06, Florence, Italy, 26 May 2006, pp. 87–94, ACM, New York, NY.
31. 31 J. Martocci, N. Riou, P. Mil, and W. Vermeylen. Building automation routing requirements in low power and lossy networks. http://tools.ietf.org/html/draft‐ietf‐roll‐building‐routing‐reqs‐07.
32. 32 D. Networks, P. Thubert, S. Dwars, and T. Phinney. Industrial routing requirements in low power and lossy networks. http://tools.ietf.org/html/draft‐ietf‐roll‐indus‐routing‐reqs‐06.
33. 33 G. Porcu. Home automation routing requirements in low power and lossy networks, draft‐ietf‐roll‐home‐routing‐reqs‐06. http://www.ietf.org/id/draft‐ietf‐roll‐home‐routing‐reqs‐08.txt.
34. 34 S. Lee, E. Belding‐Royer, and C. Perkins. Scalability study of the Ad Hoc On‐Demand Distance‐Vector Routing Protocol. ACM/Wiley International Journal of Network Management, March 2003.
35. 35 E. Kim, D. Kaspar, C. Gomez, and C. Bormann. Internet‐draft: Problem statement and requirements for 6LoWPAN routing, 6LoWPAN Working Group, 28 July 2009. http://tools.ietf.org/html/draft‐ietf‐6lowpan‐routing‐requirements‐04.
36. 36 P. Nikander, J. Kempf, and E. Nordmark. IPv6 neighbor discovery (ND) trust models and threats, RFC 3756, 2004.
37. 37 K. Kim, S. Daniel Park, and J. Lee. Hierarchical routing over 6LoWPAN (HiLow). http://tools.ietf.org/html/draft‐daniel‐6lowpan‐hilow‐hierarchical‐routing‐01.
38. 38 C. Nam, H. Jeong, and D. Shin. Extended hierarchical routing over 6LoWPAN. Proceedings of the 2008 Fourth International Conference on Networked Computing and Advanced information Management – NCM 2008, Volume 1, Washington, DC, pp. 403–405, 2008.
39. 39 M. Durvy, J. Abeillé, P. Wetterwald, C. O’Flynn, B. Leverett, E. Gnoske, M. Vidales, G. Mulligan, N. Tsiftes, N. Finne, and A. Dunkels. Making sensor networks IPv6 ready. Proceedings of the 6th ACM Conference on Embedded Network Sensor Systems, Raleigh, NC, USA, 2008.
40. 40 V. Devarapalli, R. Wakikawa, A. Petrescu, and P. Thubert. Network Mobility (NEMO) LoWMob Support Protocol, RFC 3936, January 2005.
41. 41 J. H. Kim, C. S. Hong, and K. Okamura. A routing scheme for supporting network mobility of sensor network based on 6LoWPAN. Proceedings of the 10th Asia‐Pacific Network Operations and Management Symposium on Managing Next Generation Networks and Services, Sapporo, Japan, 10–12 October 2007, in S. Ata and C. S. Hong (eds), Lecture Notes in Computer Science, volume 4773, pp. 155–164, Springer‐Verlag, Berlin/Heidelberg, 2007.
42. 42 R. Wang, R. Chang, and H. Chao. Internetworking between ZigBee/802.15.4 and IPv6/802.3 network. Proceedings of ACM SIGCOMM 2007 Workshops, Kyoto, Japan, 27–31 August, pp. 362–367, 2007.
43. 43 C. Y. Yum, Y. S. Beun, S. Kang, Y. R. Lee, and J. S. Song. Methods to use 6LoWPAN in IPv4 network, The 9th International Conference on Advanced Communication Technology, Volume 2, Gangwon‐Do, pp. 969–972, 2007.
44. 44 G. Bag, M. T. Raza, K. H. Kim, and S. W. Yoo. LoWMob: intra‐PAN mobility support schemes for 6LoWPAN. Sensors 9(7):5844–5877, 2009.
45. 45 H. Soliman, C. Castelluccia, K. E. Malki, and L. Bellier. Hierarchical MIPv6 mobility management, RFC 4140, August 2005.
46. 46 D. Saha, A. Mukherjee, I. S. Misra, and M. Chakraborty. Mobility support in IP: a survey of related protocols. IEEE Network 18:34–40, 2004.
47. 47 I. F. Akyildiz, J. Xie, and S. Mohanty. A survey of mobility management in next‐generation all‐IP based wireless systems. IEEE Wireless Communications, 11:16–28, 2004.
48. 48 M. Alam, S. Dixit, and R. Prasad. Introduction to Networked Home, Technologies for Home Networking, ed. by Sudhir Dixit and Ramjee Prasad, pp. 1–25, John Wiley & Sons, 2008.
49. 49 Z. Shelby. IP‐based 6LoWPAN networks for AMI. http://whitepapers.techrepublic.com.com/abstract.aspx?docid=951609.
50. 50 J. Zheng and M. Lee. Will IEEE 802.15.4 make ubiquitous networking a reality? A discussion on a potential low power, low bit rate standard. IEEE Communications Magazine, 42(6):140–146, 2004.
51. 51 R. Istepanian, E. Jovanov, and Y. Zhang. Beyond seamless mobility and global wireless health‐care connectivity. IEEE Transactions on Information Technology in Biomedicine, 8:405–414, 2004.
52. 52 N. Kushalnagar and G. Montenegro, 6LoWPAN. Overview, assumptions, problem statement and goals. http://www.ietf.org/old/2009/proceedings/05mar/slides/6lowpan‐3/6lowpan‐4.ppt.
53. 53 S. Deering and R. Hinden. Internet Protocol, Version 6 (IPv6) specification, RFC 2460.
54. 54 M. T. Raza, R. Jeatek, S. Yoo, K. Kim, S. Joo, and W. Jeong, An architectural framework for Web portal in ubiquitous pervasive environment. Seventh Annual Communication Networks and Services Research Conference, CNSR, pp. 102–109, 2009.

Abbreviations/Terminologies

AES

Advanced Encryption Scheme

AMR

Automated Meter Reading

APDU

Application Protocol Data Units

CBC‐MAC

Cipher Block Chaining – Message Authentication Code

CCM

CBC‐MAC mode

CSMA‐CA

Carrier Sense Multiple Access with Collision Avoidance

FFD

Full Function Device

FMIPv6

Fast Mobile IPv6

HC

Header Compression

HMIPv6

Hierarchical Mobile IPv6

HTML

HyperText Markup Language

HTTP

Hypertext Transfer Protocol

ICMP

Internet Control Message Protocol

IEEE

Institute of Electrical and Electronics Engineers

IETF

Internet Engineering Task Force

IP

Internet Protocol

IPSec

IP Security

IPSO

Internet Protocol for Smart Objects

IPv4

Internet Protocol Version 4

IPv6

Internet Protocol Version 6

LAN

Local Area Network

LLN

Low‐Power and Lossy Network

LR‐PAN

Low‐Range Wireless Personal Area Network

LR‐WPAN

Low‐Rate Wireless Personal Area Network

MAC

Media Access Control

MIPv6

Mobile IPv6

MP2P

Multipoint to Point

MTU

Maximum Transmission Unit

NALP

Not a LoWPAN Frame

NAC

Neighbor Added Child

NAT

Network Address Translation

NEMO

Network Mobility

NRP

Neighbor Replace Parent

PAN

Personal Area Network

PC

Personal Computer

PDA

Personal Digital Assistant

PHY

Physical Layer

PKI

Public Key Infrastructure

P2MP

Point to Multipoint

P2P

Point to Point

QoS

Quality of Service

REST

Representational State Transfer

RFC

Request For Comment

RFD

Reduced Function Device

RFID

Radio‐Frequency Identification

SNMP

Simple Network Management Protocol

SOAP

Simple Object Access Protocol

SSL

Secure Sockets Layer

TCP

Transmission Control Protocol

TLS

Transport Layer Security

TTL

Time to Live

UDP

User Datagram Protocol

WAN

Wide Area Network

WBSN

Wireless Body Sensor Network

WEP

Wired Equivalent Privacy

WPAN

Wireless Personal Area Network

XML

Extensible Markup Language

6LoWPAN

IPv6 over Low‐Power Wireless Personal Area Networks

Questions

1. Identify the benefits of using IP in sensor networks.
2. What are the advantages of 6LoWPAN over wired networks as well as other wireless networks?
3. State five applications of 6LoWPAN.
4. Draw a 6LoWPAN stack and explain its various layers.
5. Differentiate between ZigBee and 6LoWPAN.
6. Write the names of different types of node in a LoWPAN and their characteristics.
7. Explain with a diagram the network topology of IEEE 802.15.4.
8. How is a 6LoWPAN datagram transmitted over IEEE 802.16.4 radio?
9. Describe the process of neighbor discovery in 6LoWPAN.
10. Explain the ‘route over’ approach and the ‘mesh under’ approach of routing.
11. Explain with a diagram how 6LoWPAN can be used for an application in your surroundings.
12. State whether the following statements are true or false and give reasons for the answer:
    1. 6LoWPAN networks are known as low‐power and lossy networks.
    2. Smart objects are those that are small in size and accurate in operations.
    3. Communication in a sensor network can only be unidirectional.
    4. IP‐based applications are memory and bandwidth intensive and cannot be used for sensor networks.
    5. 6LoWPAN can connect to the Internet through a gateway.
    6. If an FFD fails, an RFD can take over the role of PAN coordinator.
    7. IEEE 802.15.4 provides confidentiality to 6LoWPAN transmissions.
    8. 6LoWPAN provides the network backbone for the Internet of Things (IoT).
13. For the following, mark all options that are true:
    1. IEEE 802.15.4 defines the following types of node:
       • full function device,
       • partial function device,
       • reduced function device,
       • remote function device.
    2. Which is not a type of node and service discovery in 6LoWPAN:
       • Some1CatchMe,
       • Every1CatchMe,
       • ICatchYou,
       • YouCatchMe.
    3. The frames supported by IEEE 802.15.4 are:
       • data frame,
       • beacon frame,
       • MAC command frame,
       • acknowledgement frame.
    4. IEEE 802.15.4 provides security‐related functionality to:
       • 6LoWPAN,
       • secured bootstrapping,
       • key management,
       • link layer security,
       • digital certificates.
    5. IEEE 802.15.4 devices have the following characteristics:
       • short communication range,
       • low bandwidth requirement,
       • low memory requirement,
       • low battery life.

Exercises

1. 2 MB of restricted data has to be transferred from one node to other in a 6LoWPAN network using AES‐CCM‐128 security. How many MAC layer frames have to be formed?
2. Draw a state diagram of a 6LoWPAN node.
3. A 6LoWPAN network has a very high number of nodes ‘N’ in it. The spread of the network is also very wide, mobile, and random. It has been stated that, to save on energy and time, the maximum permissible hops for data communication between any two nodes even in the worst‐case deployment should not be more than log N. What is the worst‐case deployment? What topology should be used in this 6LoWPAN network to ensure maximum log N hops even in the worst case?
4. Identify in Figure 12.2 the sensor nodes that have to be RFDs or FFDs, and those sensor nodes that can be either RFDs or FFDs in terms of IEEE 802.15.4.
5. Draw a sequence diagram to depict the communication between nodes in a 6LoWPAN in terms of exchange of frames.