TOC 
6LoWPAN Working GroupE. Kim
Internet-DraftETRI
Expires: January 10, 2010D. Kaspar
 Simula Research Laboratory
 N. Chevrollier
 TNO
 JP. Vasseur
 Cisco Systems, Inc
 July 09, 2009


Design and Application Spaces for 6LoWPANs
draft-ietf-6lowpan-usecases-03

Status of this Memo

This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79.

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts.

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as “work in progress.”

The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt.

The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html.

This Internet-Draft will expire on January 10, 2010.

Copyright Notice

Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved.

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, as they describe your rights and restrictions with respect to this document.

Abstract

This document investigates potential application scenarios and use cases for low-power wireless personal area networks (LoWPANs). This document provides dimensions of design space for LoWPAN applications. A list of use cases and market domains that may benefit and motivate the work currently done in the 6LoWPAN WG is provided with the characterisitcis of each dimention. A complete list of practical use cases is not the goal of this document.



Table of Contents

1.  Introduction
    1.1.  Basic network configuration
2.  Terminology
3.  Design Space
4.  Application Scenarios
    4.1.  Industrial Monitoring
        4.1.1.  A Use Case and its Requirements
        4.1.2.  6LoWPAN Applicability
    4.2.  Structural Monitoring
        4.2.1.  A Use Case and its Requirements
        4.2.2.  6LoWPAN Applicability
    4.3.  Healthcare
        4.3.1.  A Use Case and its Requirements
        4.3.2.  6LoWPAN Applicability
    4.4.  Connected Home
        4.4.1.  A Use Case and its Requirements
        4.4.2.  6LoWPAN Applicability
    4.5.  Vehicle Telematics
        4.5.1.  A Use Case and its Requirements
        4.5.2.  6LoWPAN Applicability
    4.6.  Agricultural Monitoring
        4.6.1.  A Use Case and its Requirements
        4.6.2.  6LoWPAN Applicability
5.  Security Considerations
6.  Acknowledgements
7.  References
    7.1.  Normative References
    7.2.  Informative References
§  Authors' Addresses




 TOC 

1.  Introduction

Low power and lossy networks (LLNs) is the term commonly used to refer to networks made of highly constrained nodes (limited CPU, memory, power) interconnected by a variety of “lossy” links (low power radio links or powerline communication (PLC)) characterized by low speed and relatively unstable. A particular instantiation of LLN is LoWPANs: LoWPANs are inexpensive, low-performance, wireless communication networks, and are formed by devices complying with the IEEE 802.15.4 standard [5] (IEEE Computer Society, “IEEE Std. 802.15.4-2006 (as amended),” 2007.). Their typical characteristics can be summarized as follows:

As any other LLNs, LoWPANs do not necessarily comprise of sensor nodes only, but may also consist of actuators. For instance, in an agricultural environment, sensor nodes might detect low soil humidity and then send commands to activate the sprinkler system.

After defining common terminology in Section 2 (Terminology) and describing the characteristics of LoWPANs in Section 3 (Design Space), this document provides a list of use cases and market domains that may benefit and motivate the work currently done in the 6LoWPAN WG.



 TOC 

1.1.  Basic network configuration

A LoWPAN network can be seen as a network of small star-networks, each consisting of a single LoWPAN node connected to zero or more nodes, or a network with mesh topology as shown in Figure 1 (Examples of LoWPAN topologies). It is noted that it is out of scope of this document to define how mesh topologies could be obtained and maintained.

Note: The IEEE 802.15.4 standard distinguishes between two types of nodes, reduced-function devices (RFDs) and full-function devices (FFDs). This document uses the term, LoWPAN node, which includes both type of devices. The two device types have different capabilities, so that the capability requirements of a LoWPAN node must be considered to choose the type of devices. Through their inability to transmit MAC layer beacons, RFDs can only communicate with FFDs in a resulting "master/slave" star topology. FFDs are able to communicate with peer FFDs and with RFDs in the aforementioned relation. FFDs can therefore assume arbitrary network topologies, such as multi-hop meshes.



A simple star topology                        A mesh topology

     n  n  n                                       n---n   n  n
      \ | /                                        |   |   | /
 ER --- n ---n     ER: LoWPAN Edge Router     ER---n---n---n---n
      / | \         n: LoWPAN Node                /|   |   |   |
     n  n  n                                     n n   n   n---n

 Figure 1: Examples of LoWPAN topologies 

Communication to corresponding nodes outside of the LoWPAN is becoming increasingly important. The intermediate LoWPAN nodes act as packet forwarders or LoWPAN routers and connect the entire LoWPAN in a multi-hop fashion. Edge Routers are used to interconnect a LoWPAN to other networks, or to form an Extended LoWPAN by connecting multiple LoWPANs. Before LoWPAN nodes obtain their IPv6 addresses and the network is configured, each LoWPAN executes a link-layer configuration using a single coordinator who is responsible for link-layer short address allocation. However, this link-layer coordinator function is out of the scope of this document.

A LoWPAN can be configured as Mesh Under or Route Over (see Terminology section Section 2 (Terminology)). In a Mesh Under configuration, the link-local scope reaches to the boundaries of the LoWPAN and all nodes in a LoWPAN are included in the scope. Multihop transmission is achieved by Mesh Under forwarding at the link layer or in an Adaptation layer (see Figure 1 (Examples of LoWPAN topologies)). In a Route Over configuration, Multihop transmission is achieved using IP routing (see Figure 1 (Examples of LoWPAN topologies)). More information about Mesh Under and Route Over is in 6LoWPAN ND [6] (Shelby, Z., Thubert, P., Hui, J., Chakrabarti, S., and E. Nordmark, “Neighbor Discovery for 6LoWPAN,” May 2009.) and 6LoWPAN Routing Requirements [8] (Kim, E., Kaspar, D., Gomez, C., and C. Bormann, “Problem Statement and Requirements for 6LoWPAN Routing,” March 2009.).



         h     h
         |     |           ER: LoWPAN Edge Router
  ER --- m --- m --- h      m: LoWPAN Mesh Node (mesh forwarding,Mac Address)
        / \     \           h: LoWPAN Host
       h   h     h

 Figure 2: Example of a Mesh Under LoWPAN 



         h     h
         |     |             ER: LoWPAN Edge Router
  ER --- r --- r --- h        r: LoWPAN Router (IP routing, IPv6 address)
        / \     \             h: LoWPAN Host
       h   h     h

 Figure 3: Example of a Route Over LoWPAN 





 TOC 

2.  Terminology

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [1] (Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,” March 1997.).

Readers are expected to be familiar with all the terms and concepts that are discussed in "IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs): Overview, Assumptions, Problem Statement, and Goals" (Kushalnagar, N., Montenegro, G., and C. Schumacher, “IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs): Overview, Assumptions, Problem Statement, and Goals,” August 2007.) [3], and " Transmission of IPv6 Packets over IEEE 802.15.4 Networks" (Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler, “Transmission of IPv6 Packets over IEEE 802.15.4 Networks,” September 2007.) [4].

Readers would benefit from reading 6LoWPAN ND [6] (Shelby, Z., Thubert, P., Hui, J., Chakrabarti, S., and E. Nordmark, “Neighbor Discovery for 6LoWPAN,” May 2009.), 6LoWPAN header compression [7] (Hui, J. and P. Thubert, “Compression Format for IPv6 Datagrams in 6LoWPAN Networks,” June 2009.), and 6LoWPAN Routing Requirements [8] (Kim, E., Kaspar, D., Gomez, C., and C. Bormann, “Problem Statement and Requirements for 6LoWPAN Routing,” March 2009.) for the details of the each 6LoWPAN work.

This specification makes extensive use of the same terminology defined in 6LoWPAN ND [6] (Shelby, Z., Thubert, P., Hui, J., Chakrabarti, S., and E. Nordmark, “Neighbor Discovery for 6LoWPAN,” May 2009.) unless otherwise redefined below.

This document defines an additional terms:

LC(local-coordinator) node
A logical functional entity that performs the special role of coordinating its child nodes for local data aggregation, status management of local nodes, etc. Thus, the local coordinator node does not need to coincide with a link-layer PAN coordinator and there may be multiple instance in a LoWPAN.





 TOC 

3.  Design Space

Inspired by [10] (Roemer, K. and F. Mattern, “The Design Space of Wireless Sensor Networks,” December 2004.), this section describes the potential dimensions that could be used to describe the design space of wireless sensor networks in the context of the 6LoWPAN Working Group. The design space is already limited by the unique characteristics of a LoWPAN (e.g., low-power, short range, low-bit rate) as described in [3] (Kushalnagar, N., Montenegro, G., and C. Schumacher, “IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs): Overview, Assumptions, Problem Statement, and Goals,” August 2007.). The possible dimensions for scenario categorization used in this document are described as follows:





 TOC 

4.  Application Scenarios

This section lists a fundamental set of LoWPAN application scenarios in terms of system design. A complete list of practical use cases is not the objective of this document.



 TOC 

4.1.  Industrial Monitoring

LoWPAN applications for industrial monitoring can be associated with a broad range of methods to increase productivity, energy efficiency, and safety of industrial operations in engineering facilities and manufacturing plants. Many companies currently use time-consuming and expensive manual monitoring to predict failures and to schedule maintenance or replacements in order to avoid costly manufacturing downtime. LoWPANs can be inexpensively installed and provide more frequent and more reliable data. The deployment of LoWPANs can reduce equipment downtime and eliminate manual equipment monitoring that is costy to be carried out. Additionally, data analysis functionality can be placed into the network, eliminating the need for manual data transfer and analysis.

Industrial monitoring can be largely split into the following application fields:



 TOC 

4.1.1.  A Use Case and its Requirements

Example: Storage Monitoring + Partical Supply chain (Hospital Storage Rooms)

In a hospital, maintenance of the right temperature in storage rooms is very critical. Red blood cells need to be stored at 2 to 6 degrees Celsius, blood platelets at 20 to 24 C, and blood plasma below -18 C. For anti-cancer medicine, maintaining a humidity of 45% to 55% is required. Storage rooms have temperature sensors and humidity sensors every 25m to 100m, based on the floor plan and the location of shelves, as indoor obstacles distort the radio signals. At each blood pack a sensor tag can be installed to track the temperature during delivery. A LoWPAN node is installed in each container of a set of blood packs. In this case, highly dense networks must be managed.

All nodes are statically deployed and manually configured with either a single- or multi-hop connection. Different types of LoWPAN nodes are configured based on the service and network requirements.

All LoWPAN nodes do not move unless the blood packs or a container of blood packs is moved. Moving nodes get connected by logical attachment to a new LoWPAN. The network configuration and forwarding/routing tables are not changed in the storage room unless node failure occurs. When containers of blood packs are transmitted to other place of the hospital or by ambulance, the LoWPAN nodes on the containers associate to a new LoWPAN, and forwarding/routing tables are changed.

This type of application works based on both periodic and event-driven notifications. Periodic data is used for monitoring the temperature and humidity in the storage rooms. The data over or under a pre-defined threshold is meaningful to report. Blood cannot be used if it is exposed to the wrong environment for about 30 minutes. Thus, event-driven data sensed on abnormal occurrences is time-critical and requires secure and reliable transmission. Due to the time-critical sensing data, reliable and secure data transmission is highly important.

LoWPANs must be provided with low installation and management costs, and for the case of transmission of boold containers, precise location tracking of containers are important. The Hospital network manager or staffs can be provided with an early warning of possible chain ruptures, for example by using conveniently accessing comprehensive on-line reports and data management systems.

Dominant parameters in industrial monitoring scenarios:



 TOC 

4.1.2.  6LoWPAN Applicability

The network configuration of the above use-case can differ substantially by system design. As illustrated in Figure 4 (Storage rooms with a simple star topology), the simplest way is to build up a star topology inside of one storage room, and connect the storage rooms with one link. Each LoWPAN node reaches the Edge Router (ER) by pre-defined routing/forwarding mechanism. the Local Coordinator nodes (LCs) play role in aggregation of the sensed data at each storage room and transmit the data. It is noted that the LoWPAN LC is a logical entity so that one can be implemented together with an LoWPAN Edge Router or a LoWPAN Node. In case that the sensed data from an individual node is important, such as urgent event-driven data, it will not be accumulated (and further delayed) by the LoWPAN LCs but immediately relayed. In Mesh under, link-layer addresses in mesh-header defined in RFC 4944 [4] (Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler, “Transmission of IPv6 Packets over IEEE 802.15.4 Networks,” September 2007.) are used for transmission, and in Route Over, IP forwarding is used.

Based on the layout and size of the storage room, the LoWPAN can be configured in mesh topology as shown in Figure 5 (Storage rooms with a mesh topology). More than one LoWPAN LCs can be installed in a storage room, and LCs collect data as relay points to transmitting the sensed data toward the LoWPAN ERs. LoWPAN Nodes need to build a multi-hop connection to reach the LCs and ER by ether Mesh Under or Route Over. In Mesh Under, more than one LCs can be installed in the LoWPAN and the nodes play role in transmission multi-point traffic (multicast) by unicast method, not only role in data collection. In Route Over, LoWPAN Routers will handle multicast traffic to their LoWPAN links.

Each LoWPAN node configures its link-local address and may get a prefix from its default router by an 6LoWPAN ND procedure [6] (Shelby, Z., Thubert, P., Hui, J., Chakrabarti, S., and E. Nordmark, “Neighbor Discovery for 6LoWPAN,” May 2009.). Inside of the storage room, each node does not need to get a globally unique IPv6 address. However, containers can be moved inside or outside of the hospital, so that globally unique addresses may be needed depending on the purpose of the system and service. Address auto-configuration is explained in Chapter 6 of RFC 4944 [4] (Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler, “Transmission of IPv6 Packets over IEEE 802.15.4 Networks,” September 2007.). When the system is only used within a link-local scope, 16-bit addresses can be utilized, but 64-bit addresses are recommended for globally unique addressing.

Packets are compressed by 6LoWPAN header compression mechanism [7] (Hui, J. and P. Thubert, “Compression Format for IPv6 Datagrams in 6LoWPAN Networks,” June 2009.). The data volume is usually not so big in this case, but it is sensitive for delay. Data aggregators can be installed for each storage room, or just one data aggregator can collect all data. To make a light transmission, UDP (encapsulated in 6LoWPAN header or as it is) will be chosen, but secure transmission and security mechanism should be added. To increase security, MAC layer mechanisms and/or additional security mechanisms can be used.

Because a failure of a LoWPAN node can critically affect the storage of the blood packs, network management is important in this use-case. SNMP-lite or other mechanism SHOULD be provided for the management.

When a container is moved out from the storage room, and connected to the other hospital system (if the hospital buildings are fully or partly covered with 6LoWPANs), it should rebind to a new parent node and a new LoWPAN. 6LoWPAN ND [6] (Shelby, Z., Thubert, P., Hui, J., Chakrabarti, S., and E. Nordmark, “Neighbor Discovery for 6LoWPAN,” May 2009.) will support this procedure. In case that it is moved by an ambulance, it will be connected to an edge router in the vehicle. LoWPANs must be provided with low installation and management costs, providing benefits such as reduced inventory, and precise location tracking of containers, and mobile equipment (moving beds at the hospital or ambulances).



                      ER
                      |                     ER: LoWPAN Edge Router
          LC----------LC----------LC        LC: Local Coordinator node
         / | \       / | \       / | \          (Data Aggregator)
        n  n  n     n  n  n     n  n  n      n: LoWPAN Node

 Figure 4: Storage rooms with a simple star topology 



                       GW
          +------------+-----------+         GW: Gateway
          |            |           |         ER: LoWPAN Edge Router
         ER           ER         ER(LC)      LC: Local Coordinator node
          |            |           |             (Data Aggregator)
    n -- LC -- n      LC -- n      n         n: LoWPAN Node
        / | \          |          /|\
       n LC  n    n -- n --LC    n n n
        / | \              /|\
       n  n  n -- n       n n n

 Figure 5: Storage rooms with a mesh topology 





 TOC 

4.2.  Structural Monitoring

Intelligent monitoring in facility management can make safety checks and periodic monitoring of the architecture status highly efficient. Mains-powered nodes can be included in the design phase of a construction or battery-equipped nodes can be added afterwards. All nodes are static and manually deployed. Some data is not critical for security protection (such as normal room temperature), but event-driven emergency data MUST be handled in very critical manner.



 TOC 

4.2.1.  A Use Case and its Requirements

Example: Bridge Safety Monitoring

A 1000m long bridge with 10 pillars is described. Each pillar and the bridge body contain 5 sensors to measure the water level, and 5 vibration sensors are used to monitor its structural health. The LoWPAN nodes are deployed to have 100m line-of-sight distance from each other. All nodes are placed statically and manually configured with a single-hop connection to the local coordinator. All LoWPAN nodes do not move while the service is provided. The network configuration and forwarding/routing tables are changed only in case of node failure. Except from the pillars, there are no special obstacles of attenuation to the node signals, but careful configuration is needed to prevent signal interference between LoWPAN nodes.

The network configuration and routing tables are changed only in case of node failure. On the top part of each pillar, an "infrastructured" sink node is placed to collect the sensed data. The sink nodes of each pillar become data gathering point of the LoWPAN hosts at the pillar as local coordinators.

This use case can be extended to medium or large size sensor networks to monitor a building or for instance the safety status of highways and tunnels. Larger networks of the same kind still have similar characteristics such as static nodes, manual deployment, and mostly star (or multi-level of star) topologies (see Figure 6 (A LoWPAN with a simple star topology.)), but dependent on the blue print of the structure, mesh topologies will be built with mains-powered relay points. Periodic and event-driven real-time data gathering is performed and the emergency event-driven data MUST be delivered without delay.

Dominant parameters in structural monitoring applications:



 TOC 

4.2.2.  6LoWPAN Applicability

The network configuration of this use case can be very simple, but there are many extended use-cases for more complex structures. The example bridge monitoring case may be the simplest case. Dependent on the bridge size, the network will be configured by multiple stars or a mesh topology.

Each LoWPAN node configures its link-local address and may get a prefix from its default router by an 6LoWPAN ND procedure [6] (Shelby, Z., Thubert, P., Hui, J., Chakrabarti, S., and E. Nordmark, “Neighbor Discovery for 6LoWPAN,” May 2009.). Each pillar may have one local coordinator node(LC) for data collection from each pillar. Each node does not need to get a globally unique IPv6 address, as the main communication is from/to the LCs of each pillar. In this manner, this system is likely to be built as a stub network, so that 16-bit addresses can be utilized, but 64-bit addresses are recommended for the new header format [7] (Hui, J. and P. Thubert, “Compression Format for IPv6 Datagrams in 6LoWPAN Networks,” June 2009.). Globally unique addresses MAY be allocated depending on the purpose of the system.

The LoWPAN Nodes are installed on the place after manual optimization of their location. Static data paths to the data gathering points can be set in the commissioning phase. If the network does not use a Route Over mechanism, the 6LoWPAN mesh-header described in RFC 4944 [4] (Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler, “Transmission of IPv6 Packets over IEEE 802.15.4 Networks,” September 2007.) may be used for static data forwarding, unless other mesh under mechanisms are provided.

A logical entity of data gathering can be implemented in each LC. Communication schedules must be set up between leaf nodes and their LC to efficiently gather the different types of sensed data. Each data packet may include meta-information about its data, or the type of sensors could be encoded in its address during the address allocation. The data gathering entity can be programmed to trigger actuators installed in the infrastructure, when a certain threshold value has been reached. This type of application works based on both periodic and event-driven notifications. The data over or under a pre-defined threshold is meaningful to report. Event-driven data sensed on abnormal occurrences is time-critical and requires secure and reliable transmission. For energy conservation, all nodes may have periodic and long sleep modes but wake up on certain events.

Packets are compressed by 6LoWPAN header compression mechanism [7] (Hui, J. and P. Thubert, “Compression Format for IPv6 Datagrams in 6LoWPAN Networks,” June 2009.). Due to the safety-critical data of the structure, authentication and security are important issues here. Only authenticated users should be allowed to access the data. Additional security should be provided at the LoWPAN ER for restricting the access from outside of the LoWPAN. The LoWPAN ER may take charge of authentication of LoWPAN nodes. Reliable and secure data transmission SHOULD be guaranteed.



           n  n  n
            \ | /                ER: LoWPAN Edge Router
        n ---LC --- ER --- n     LC: Local Coordinator node
            / | \                 n: LoWPAN Node
           n  n  n

 Figure 6: A LoWPAN with a simple star topology. 



ER ---LC ------LC -------LC           ER: Edge Router
      /|      / | \       |           LC: Local Coordinator node
     h n     h  n  h    n-n-h          r: LoWPAN Router (Route Over)
       /\       |         |            n: LoWPAN node
      h  h      h         n -- h          (Mesh node or LoWPAN Router)
				                    h: LoWPAN host

 Figure 7: A LoWPAN with a mesh topology 





 TOC 

4.3.  Healthcare

LoWPANs are envisioned to be heavily used in healthcare environments. They have a big potential to ease the deployment of new services by getting rid of cumbersome wires and simplify patient care in hospitals and for home care. In healthcare environments, delayed or lost information may be a matter of life or death.

Various systems, ranging from simple wearable remote controls for tele-assistance or intermediate systems with wearable sensor nodes monitoring various metrics to more complex systems for studying life dynamics, can be supported by LoWPANs. In the latter category, a large amount of data from various LoWPAN Nodes can be collected: movement pattern observation, checks that medicaments have been taken, object tracking, and more. An example of such a deployment is described in [11] (den Hartog, F., Schmidt, J., and A. de Vries, “On the Potential of Personal Networks for Hospitals,” May 2006.) using the concept of Personal Networks.



 TOC 

4.3.1.  A Use Case and its Requirements

Example: Healthcare at Home by Tele-Assistance

An old citizen who lives alone wears one to few wearable LoWPAN Nodes to measure heartbeat, pulse rate, etc. Dozens of LoWPAN Nodes are densely installed at home for movement detection. A LoWPAN ER at home will send the sensed information to a connected healthcare center. Portable base stations with LCDs may be used to check the data at home, as well. The different roles of devices have different duty-cycles, which affect node management.

Multipath interference may often occur due to the patients' mobility at home, where there are many walls and obstacles. Even during sleeping, the change of the body position may affect the radio propagation.

Data is gathered both periodically and event-driven. In this application, event-driven data can be very time-critical. Thus, real-time and reliable transmission must be guaranteed.

Privacy also becomes an issue in this case, as the sensed data is very personal. In addition, different data will be provided to the hospital system from what is given to a patient's family members. Role-based access control is needed to support such services, thus support of authorization and authentication is important.

Dominant parameters in healthcare applications:



 TOC 

4.3.2.  6LoWPAN Applicability

In this use case, the local network size is rather small (less than 10s of nodes). The home care system is statically configured with multi-hop paths and the patient’s body network can be built as a star topology. The LoWPAN Edge Router(ER) at home is the sink node in the routing path from sources on the patient's body. A plug-and-play configuration is required. Each home system node will get a link-local IPv6 address according to the auto-configuration described in RFC 4944 [4] (Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler, “Transmission of IPv6 Packets over IEEE 802.15.4 Networks,” September 2007.). As the communication of the system is limited to a home environment, both 16-bit and 64-bit can be used for IPv6 link-local addresses. However, 64-bit address is recommended to perform the 6LoWPAN ND [6] (Shelby, Z., Thubert, P., Hui, J., Chakrabarti, S., and E. Nordmark, “Neighbor Discovery for 6LoWPAN,” May 2009.) and new header format in [7] (Hui, J. and P. Thubert, “Compression Format for IPv6 Datagrams in 6LoWPAN Networks,” June 2009.). An example topology is provided in Figure 8 (A mobile healthcare scenario.).

Multi-hop communication can be achieved by either Mesh Under or Route Over mechanisms. In case the Mesh Under mechanism is implemented, the LoWPAN ER becomes the only router of the home network, and ND is done as 6LoWPAN ND [6] (Shelby, Z., Thubert, P., Hui, J., Chakrabarti, S., and E. Nordmark, “Neighbor Discovery for 6LoWPAN,” May 2009.) describes. When Route Over routing mechanism is used, the routers deployed in the home environment will form a mesh of IPv6 links. In Mesh Under, more than one LCs can be installed in the LoWPAN and the nodes play role in transmission multi-point traffic (multicast) to unicast method. In Route Over, LoWPAN Routers will handle multicast traffic to their LoWPAN Link.

The patient’s body network can be simply configured as a star topology with a LC dealing with data aggregation and dynamic network attachment when the patient moves around at home. As multipath interference may often occur due to the patients' mobility at home, the deployment of LoWPAN nodes and transmission paths should be well considered. At home, some nodes can be installed with power-affluence status, and those LoWPAN Nodes can be used for relaying points or data aggregation points.

The sensed information should be maintained with the identification of the patient no matter if the patient visits the connected hospital or stays at home. If the patient's LoWPAN uses globally unique IPv6 address, the address can be used for the identification, however, the home system itself does not require globally unique IPv6 address but could be run with link-local IPv6 address. In this case, the hospital LoWPAN needs to operate additional identification system.

The connection between the LoWPAN ER at home and the ER at Hospital must be reliable and secure, as the data is privacy-critical. To achieve this, additional policy for security is recommended between the two LoWPAN.



                       n --- n                I: Internet
                       |     |               ER: Edge Router
   ER --- I --- ER --- n --- n --- LC        LC: Local coordinator node
   /|\           |     |           /|\        n: LoWPAN Node
 .. . ..         n --- n          h h h       h: LoWPAN Host

(hospital)       (home system)  (patient)

 Figure 8: A mobile healthcare scenario. 





 TOC 

4.4.  Connected Home

The "Connected" Home or "Smart" home is with no doubt an area where LoWPANs can be used to support an increasing number of services:

In home environments LoWPAN networks typically comprise a few dozen and probably in the near future a few hundreds of nodes of various nature: sensors, actuators and connected objects.



 TOC 

4.4.1.  A Use Case and its Requirements

Example: Home Automation

The home automation and control system LoWPAN offers a wide range of services: local or remote access from the Internet (via a secured edge router) to monitor the home (temperature, humidity, activation of remote video surveillance, status of the doors (locked or open), ...) but also for home control (activate the air conditioning/heating, door locks, sprinkler systems, ...). Fairly sophisticated systems can also optimize the level of energy consumption thanks to a wide range of input from various sensors connected to the LoWPAN: light sensors, presence detection, temperature, ... in order to control electric window shades, chillers, air flow control, air conditioning and heating with the objective to optimize energy consumption.

With the emergence of “Smart Grid” applications, the LoWPAN may also have direct interactions with the Grid itself via the Internet of the Grid network to report the amount of KWatts that could be load shed (Home to Grid) and to receive dynamic load shedding information if/when required (Grid to home): this application is also referred to as Demand-Response application. Another service known as Demand Side Management (DSM) could be provided by utilities to monitor and report to the user its energy consumption with a fine granularity (on a per device basis). Other inputs such as dynamic pricing can also be received by the user from the utility that can then turn on and off some appliances according to its local policy in order to reduce its energy bill.

In terms of home safety and security, the LoWPAN is made of motion- and audio-sensors, sensors at doors and windows, and video cameras to which additional sensors can be added for safety (gas, water, CO, Radon, smoke detection). The LoWPAN typically comprises a few dozen of nodes forming an ad-hoc network with multi-hop routing since the nodes may not be in direct range. It is worth mentioning that the number of devices tends to grow considering the number of new applications for the home. In its most simple form, all nodes are static and communicate with a central control module but more sophisticated scenarios may also involve inter-device communication. For example, a motion/presence sensor may send a multicast message to a group of lights to be switched on, or a video camera will be activated sending a video stream to a gateway that can be received on a cell phone.

Ergonomics in Connected Homes is a key and the LoWPAN must be self-managed and easy to install. Traffic patterns may greatly vary depending on the applicability and so does the level of reliability and QoS expected from the LoWPAN. Humidity sensing is typically not critical and requires no immediate action whereas tele-assistance or gas leak detection is critical and requires a high degree of reliability. Furthermore, although some actions may not involve critical data, still the response time and network delays must be on the order of a few hundreds of milliseconds to preserve the user experience (e.g. use a remote control to switch a light on). A minority of nodes are mobile (with slow motion). With the emergence of energy related applications it becomes crucial to preserve data confidentiality. Connected Home LoWPAN usually do not require multi-topology or QoS routing and fairly simple QoS mechanisms must be supported by the LoWPAN (the number of Class of Services is usually limited).

Dominant parameters for home automation applications:



 TOC 

4.4.2.  6LoWPAN Applicability

In the home automation use case, the network topology is made of a mix a battery operated and main powered nodes that both communication with each other and to outside of the LoWPAN via the LoWPAN ERs. That being said it is expected that most LoPWAN nodes will communicate with a LC that will process the data and will communicate with outside after potential data processing, filtering, etc.

In home network, installation and management must as extremely simple for the user.

Link local IPv6 addresses can be used by nodes with no external communication whereas globally unique IPv6 address will be required for the node requiring communication with node outside of the LoWPAN. Even in the case of nodes that do not need to communicate with the outside world, it is recommended to make use of 64-bit addresses to handle new compression header (see [7] (Hui, J. and P. Thubert, “Compression Format for IPv6 Datagrams in 6LoWPAN Networks,” June 2009.)).




                           n --- n              I: Internet
                           |     |             ER: Edge Router
Internet/ ------- ER/LC -- n --- n ---- LC     LC: Local coordinator node
Utility network     |      |            /|\     n: LoWPAN Node
                    n ---- n           h h h    h: LoWPAN Host

   (outside)       (home automation system)

 Figure 9: Home Automation scenario 

In some scenarios, the traffic will be sent to a LC for processing that may in turn decide of local actions (switch a light on, …). In other scenarios, all devices will send their data to the LCs that may also act as the ER for data processing and potential relay of data to outside of the LoWPAN. For the sake of illustration, some of the data may be processed to trigger local action (e.g. switch off an appliance), simply store and sent once enough data has been accumulated (e.g. energy consumption for the past 6 hours for a set of appliances) or could trigger an alarm immediately sent to a datacenter (e.g. gas leak detection).

Although in the majority of cases nodes within the LoPWAN will be in direct range, some nodes will reach the ER/LC with a 2-3 hops path using Mesh Under or very likely a Route Over solution (with the emergence of several low power media such as low power PLC) in which case LoWPAN routers will be deployed in the home to interconnect the various IPv6 links.

The home LoWPAN must be able to provide extremely reliable communication in support of some specific application (e.g. fire, gas leak detection, health monitoring) whereas other application may not be critical at all (e.g humidity monitoring). Similarly some information may require the use of security mechanisms for authentication, confidentiality).





 TOC 

4.5.  Vehicle Telematics

LoWPANs play an important role in intelligent transportation systems. Incorporated in roads, vehicles, and traffic signals, they contribute to the improvement of safety of transporting systems. Through traffic or air-quality monitoring, they increase the possibilities in terms of traffic flow optimization and help reducing road congestion.



 TOC 

4.5.1.  A Use Case and its Requirements

Example: Telematics

As shown in Figure 10 (Multi-hop LoWPAN combined with mobile star LoWPAN.), scattered LoWPAN Nodes are included in roads during their construction for motion monitoring. When a car passes over of these nodes, the possibility is then given to track the trajectory and velocity of cars for safety purposes. The lifetime of the LoWPAN Nodes incorporated into roads is expected to be as long as the life time of the roads (10 years). Multihop communication is possible between LoWPAN Nodes, and the network should be able to cope with the deterioration over time of the node density due to power failures. Sink nodes placed at the road side are mains-powered, LoWPAN Nodes in the roads run on battery. Power savings schemes might intermittently disconnect the nodes. A rough estimate of 4 nodes per square meter is needed. Other applications may involve car-to-car communication for increased road safety.

Dominant parameters in vehicle telematics applications:



 TOC 

4.5.2.  6LoWPAN Applicability

For this use case, the network topology includes fixed LoWPAN Edge Routers that are mains-powered and have a connection to a gateway in order to reach the transportation control center. These LoWPAN ERs are logically combined with LC nodes as data sinks for a number of LoWPAN Nodes inserted in the tarmac of the road.

In contrast to the LoWPAN ERs, the LoWPAN Nodes can generally operate with link-local IPv6 addresses as no direct access from outside the LoWPAN is established to the LoWPAN Nodes. Based on the purpose of the service, globally unique IPv6 address can be allocated during the network setup procedure described in RFC 4944 [4] (Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler, “Transmission of IPv6 Packets over IEEE 802.15.4 Networks,” September 2007.) and 6LoWPAN ND [6] (Shelby, Z., Thubert, P., Hui, J., Chakrabarti, S., and E. Nordmark, “Neighbor Discovery for 6LoWPAN,” May 2009.). In Infrastructure LoWPANs, each ER is connected by a backbone link and additional registration procedures may be required for management of multiple LoWPANs. Details of this registration is described in 6LoWPAN ND .

In this topology, a LoWPAN with one LoWPAN ER forms a fixed network and the LoWPAN Nodes are installed by manual optimization of their location. Static data paths to the data gathering point can be set in the commissioning phase. If the network does not use a Route Over mechanism, the 6LoWPAN mesh under forwarding is used. Forwarding/Routing tables are not changed unless a node failure occurs.



	+----+
	| ER |----------------------------- ER ...
	+----+    (at the road side)
 -------|------------------------------
		|
   n -- n --- n --- n   +---|---+       ER: LoWPAN Edge Router
       / \          |   | h-n-h |        n: LoWPAN Node
      n  n          n   +---|---+        h: LoWPAN Host
                          (cars)
 --------------------------------------

 Figure 10: Multi-hop LoWPAN combined with mobile star LoWPAN. 





 TOC 

4.6.  Agricultural Monitoring

Accurate temporal and spatial monitoring can significantly increase agricultural productivity. Due to natural limitations, such as a farmers' inability to check the crop at all times of day or inadequate measurement tools, luck often plays a too large role in the success of harvests. Using a network of strategically placed sensors, indicators such as temperature, humidity, soil condition, can be automatically monitored without labor intensive field measurements. For example, sensor networks could provide precise information about crops in real time, enabling businesses to reduce water, energy, and pesticide usage and enhancing environment protection. The sensing data can be used to find optimal environments for the plants. In addition, the data on the planting condition can be saved by sensor tags, which can be used in supply chain management.



 TOC 

4.6.1.  A Use Case and its Requirements

Example: Automated Vineyard

In a vineyard with medium to large geographical size, a number of 50 to 100 LC nodes are manually deployed in order to provide full signal coverage over the study area. An additional number of 100 to 1000 leaf nodes with (possibly heterogeneous) specialized sensors (i.e., humidity, temperature, soil condition, sunlight) are attached to the LCs in local wireless star topologies, periodically reporting measurements to the associated LoWPAN LCs. For example, in a 20-acre vineyard with 8 parcels of land, 10 LoWPAN Nodes are placed within each parcel to provide readings on temperature and soil moisture. The LoWPAN Nodes are able to support a multi-hop forwarding/routing scheme to enable data forwarding to a sink node at the edge of the vineyard. Each of the 8 parcels contains one data aggregator to collect the sensed data. Ten intermediate nodes are used to connect the sink nodes to the main gateway.

Localization is important for geographical routing, for pinning down where an event occurred, and for combining gathered data with their actual position. Using manual deployment, device addresses can be used. For randomly deployed nodes, a localization algorithm needs to be applied.

There might be various types of sensor devices deployed in a single LoWPAN, each providing raw data with different semantics. Thus, an additional method is required to correctly interpret sensor readings. Each data packet may include meta-information about its data, or a type of a sensor could be encoded in its address during address allocation.

Dominant parameters in agricultural monitoring:



 TOC 

4.6.2.  6LoWPAN Applicability

The network configuration in this use case might, in the most simple case, look like illustrated in Figure 11 (An aligned multi-hop LoWPAN.). This static scenario consists of one or more fixed LoWPAN ER that are mains-powered and have a high-bandwidth connection to a gateway via a backbone link, which might be placed in a control center, or connect to the Internet. The LoWPAN ERs are strategically located at the border of vineyard parcels, acting as data sinks. A number of LC nodes are placed along a row of plants with individual LoWPAN Hosts spread around them.

While the LoWPAN ERs implement the IPv6 Neighbor Discovery protocol (RFC 4861), the LoWPAN Nodes operate a more energy-considering ND described in [6] (Shelby, Z., Thubert, P., Hui, J., Chakrabarti, S., and E. Nordmark, “Neighbor Discovery for 6LoWPAN,” May 2009.), which includes basic bootstrapping and address assignment. Link-local addresses are used for communication within the network. Each LoWPAN ER can have predefined forward management information, if necessary.

The intermediate nodes must implement a multi-hop forwarding/routing protocol (Mesh Under or Route Over) and they are responsible to transmit the measured data at the LoWPAN hosts to the LoWPAN ERs. In this simplest case, the LoWPAN Routers (not edge routers) or Mesh nodes can build static forwarding/routing paths, and all end-nodes can be placed in one radio hop distance from its forwarder. Packets are forwarded to each router or mesh node and relayed to the LoWPAN ER.

LoWPAN nodes may send event-driven notifications when readings exceed certain thresholds, such as low soil humidity; which may automatically trigger a water sprinkler in the local environment. For increased energy efficiency, all LoWPAN Nodes are in periodic sleep state. However, the LoWPAN LCs need to be aware of sudden events from the leaf nodes. Their sleep periods should therefore be set to shorter intervals. Communication schedules must be set up between master and leaf nodes, and global time synchronization is needed to account for clock drift.

Also, the result of data collection may activate actuators. Context-awareness, node identification and data collection on the application level are necessary.



  +----+
  | GW |
  +----+
     |    h h h   h h h   h h h       GW: Gateway
     |     \|/     \|/     \|/        ER: LoWPAN Edge Router
    ER---- LC-------LC------LC        CN: Local Coordinator node
     |     /|\     /|\     /|\         h: LoWPAN Host
     |    h h h   h h h   h h h
    ER
    ...

 Figure 11: An aligned multi-hop LoWPAN. 





 TOC 

5.  Security Considerations

Security requirements are differ by use-cases. For example, industry monitoring an structure monitoring applications are safety-critical. Secure transmission must be guaranteed, and only authenticated users should be able to access and handle the data. Lightweight key mechanisms can be used. In health care system, data privacy is an important issue. Encryption is required, and role based access control is required to be support by proper authentication mechanism.





 TOC 

6.  Acknowledgements

Thanks to David Cypher for giving more insight on the IEEE 802.15.4 standard and to Irene Fernandez for her review and valuable comments.



 TOC 

7.  References



 TOC 

7.1. Normative References

[1] Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,” BCP 14, RFC 2119, March 1997 (TXT, HTML, XML).
[2] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, “Neighbor Discovery for IP version 6 (IPv6),” RFC 4861, September 2007 (TXT).
[3] Kushalnagar, N., Montenegro, G., and C. Schumacher, “IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs): Overview, Assumptions, Problem Statement, and Goals,” RFC 4919, August 2007 (TXT).
[4] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler, “Transmission of IPv6 Packets over IEEE 802.15.4 Networks,” RFC 4944, September 2007 (TXT).
[5] IEEE Computer Society, “IEEE Std. 802.15.4-2006 (as amended),” 2007.


 TOC 

7.2. Informative References

[6] Shelby, Z., Thubert, P., Hui, J., Chakrabarti, S., and E. Nordmark, “Neighbor Discovery for 6LoWPAN,” draft-ietf-6lowpan-nd-03 (work in progress), May 2009 (TXT).
[7] Hui, J. and P. Thubert, “Compression Format for IPv6 Datagrams in 6LoWPAN Networks,” draft-ietf-6lowpan-hc-05 (work in progress), June 2009 (TXT).
[8] Kim, E., Kaspar, D., Gomez, C., and C. Bormann, “Problem Statement and Requirements for 6LoWPAN Routing,” draft-ietf-6lowpan-routing-requirements-02 (work in progress), March 2009 (TXT).
[9] Bulusu, N. and S. Jha, “Wireless Sensor Networks,” July 2005.
[10] Roemer, K. and F. Mattern, “The Design Space of Wireless Sensor Networks,” December 2004.
[11] den Hartog, F., Schmidt, J., and A. de Vries, “On the Potential of Personal Networks for Hospitals,” May 2006.


 TOC 

Authors' Addresses

  Eunsook Kim
  ETRI
  161 Gajeong-dong
  Yuseong-gu
  Daejeon 305-700
  Korea
Phone:  +82-42-860-6124
Email:  eunah.ietf@gmail.com
  
  Dominik Kaspar
  Simula Research Laboratory
  Martin Linges v 17
  Snaroya 1367
  Norway
Phone:  +47-4748-9307
Email:  dokaspar.ietf@gmail.com
  
  Nicolas G. Chevrollier
  TNO
  Brassersplein 2
  P.O. Box 5050
  Delft 2600
  The Netherlands
Phone:  +31-15-285-7354
Email:  nicolas.chevrollier@tno.nl
  
  JP Vasseur
  Cisco Systems, Inc
  1414 Massachusetts Avenue
  Boxborough MA 01719
  USA
Phone: 
Email:  jpv@cisco.com