6LoWPAN Working Group                                             E. Kim
Internet-Draft                                                      ETRI
Expires: January 15, 2009                                 N. Chevrollier
                                                                     TNO
                                                               D. Kaspar
                                              Simula Research Laboratory
                                                             JP. Vasseur
                                                      Cisco Systems, Inc
                                                           July 14, 2008


               Design and Application Spaces for 6LoWPANs
                    draft-ekim-6lowpan-scenarios-03

Status of this Memo

   By submitting this Internet-Draft, each author represents that any
   applicable patent or other IPR claims of which he or she is aware
   have been or will be disclosed, and any of which he or she becomes
   aware will be disclosed, in accordance with Section 6 of 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 15, 2009.













Kim, et al.             Expires January 15, 2009                [Page 1]


Internet-Draft       6LoWPAN Design and Applications           July 2008


Abstract

   This document investigates potential application scenarios and use
   cases for low-power wireless personal area networks (LoWPANs).


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Design Space . . . . . . . . . . . . . . . . . . . . . . . . .  5
   3.  Application Scenarios  . . . . . . . . . . . . . . . . . . . .  7
     3.1.  Industrial Monitoring  . . . . . . . . . . . . . . . . . .  7
       3.1.1.  Application Features . . . . . . . . . . . . . . . . .  7
       3.1.2.  A Use Case and its Requirements  . . . . . . . . . . .  9
       3.1.3.  6LoWPAN Applicability  . . . . . . . . . . . . . . . . 10
     3.2.  Structural Monitoring  . . . . . . . . . . . . . . . . . . 11
       3.2.1.  Application Features . . . . . . . . . . . . . . . . . 11
       3.2.2.  A Use Case and its Requirements  . . . . . . . . . . . 12
       3.2.3.  6LoWPAN Applicability  . . . . . . . . . . . . . . . . 13
     3.3.  Healthcare . . . . . . . . . . . . . . . . . . . . . . . . 14
       3.3.1.  Application Features . . . . . . . . . . . . . . . . . 14
       3.3.2.  A Use Case and its Requirements  . . . . . . . . . . . 14
       3.3.3.  6LoWPAN Applicability  . . . . . . . . . . . . . . . . 15
     3.4.  Connected Home . . . . . . . . . . . . . . . . . . . . . . 16
     3.5.  Vehicle Telematics . . . . . . . . . . . . . . . . . . . . 18
     3.6.  Agricultural Monitoring  . . . . . . . . . . . . . . . . . 19
   4.  Security Considerations  . . . . . . . . . . . . . . . . . . . 22
   5.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 23
   6.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 24
     6.1.  Normative References . . . . . . . . . . . . . . . . . . . 24
     6.2.  Informative References . . . . . . . . . . . . . . . . . . 24
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 25
   Intellectual Property and Copyright Statements . . . . . . . . . . 26


















Kim, et al.             Expires January 15, 2009                [Page 2]


Internet-Draft       6LoWPAN Design and Applications           July 2008


1.  Introduction

   LoWPANs are inexpensive, low-performance, wireless communication
   networks, and are formed by devices complying with the IEEE 802.15.4
   standard [3].  Their typical characteristics can be summarized as
   follows:

   o  Low power: depending on country regulations and used frequency
      band, the maximum transmit power levels can be up to 1000 mW [3].
      However, typical wireless radios for LoWPANs are battery-operated
      and consume between 10 mW and 20 mW [4].

   o  Short range: The Personal Operating Space (POS) defined by IEEE
      802.15.4 implies a range of 10 meters.  For real implementations,
      the range of LoWPAN radios is typically measured in tens of
      meters, but can go far beyond that in line-of-sight situations
      [4].

   o  Low bit rate: the IEEE 802.15.4 standard defines a maximum over-
      the-air rate of 250 kb/s, as well as lower data rates of 40 kb/s
      and 20 kb/s for each of the currently defined physical layers (2.4
      GHz, 915 MHz and 868 MHz, respectively).

   o  Small memory capacity: common RAM sizes for LoWPAN devices consist
      of a few kilobytes, such as 4 KB.

   o  Limited processing capability: current LoWPAN nodes usually have
      8-bit processors with clock rates around 10 MHz.

   The IEEE 802.15.4 standard distinguishes between two types of nodes,
   reduced-function devices (RFDs) and full-function devices (FFDs).
   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.

   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.

   A LoWPAN network can be seen as a network of small star-networks,
   each consisting of a single FFD connected to zero or more RFDs.  The
   FFDs themselves act as packet forwarders or routers and connect the
   entire LoWPAN in a multi-hop fashion.  A LoWPAN domain is defined by
   the number of devices controlled by the LoWPAN coordinator.  Each
   LoWPAN has a single coordinator, which must be of FFD type and it is



Kim, et al.             Expires January 15, 2009                [Page 3]


Internet-Draft       6LoWPAN Design and Applications           July 2008


   responsible for address allocation.  A LoWPAN coordinator is
   responsible for a single LoWPAN.


                   O     X
                   |     |              C: Coordinator
             C --- O --- O --- X        O: FFD
                  / \     \             X: RFD
                 X   X     X

                   Figure 1: Example of a simple LoWPAN

   Furthermore, communication to corresponding nodes outside of the
   LoWPAN is becoming increasingly important.  The distinction between
   RFDs and FFDs and the introduction of additional functional elements,
   such as gateways or border routers, increase the complexity on how
   basic network functionality (e.g., routing and mobility) can be
   designed for LoWPANs.

   After describing the characteristics of a LoWPAN, this draft provides
   a list of use cases and market domains that may benefit and motivate
   the work currently done in the 6LoWPAN WG.





























Kim, et al.             Expires January 15, 2009                [Page 4]


Internet-Draft       6LoWPAN Design and Applications           July 2008


2.  Design Space

   Inspired by [5], 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 WG.  The design space is
   already limited by the unique characteristics of a 6LoWPAN (e.g.,
   low-power, short range, low-bit rate) as described in [2].  The
   possible dimensions for scenario categorization used in this draft
   are described as follows:

   o  Deployment: In a LoWPAN, sensor nodes can be scattered randomly or
      they may be deployed in an organized manner.  The deployment can
      occur at once, or as an iterative process.  The selected type of
      deployment has an impact on node density and location.  This
      feature affects how to organize (manually or automatically) the
      sensor network, and how to allocate addresses in the network.

   o  Mobility: Inherent to the wireless characteristics of LoWPANs,
      sensor nodes could move or be moved around.  Mobility can be an
      induced factor (e.g., sensors in an automobile), hence not
      predictable, or a controlled characteristic (e.g., pre-planned
      movement in a supply chain).

   o  Network Size: The network size takes into account nodes that
      provide the intended network capability (i.e., FFD).  The number
      of nodes involved in a LoWPAN could be small (10 nodes), moderate
      (several 100s), or large (over a 1000).

   o  Power Source: Whether the sensor nodes are battery-powered or
      mains-powered influences the network design.  A hybrid solution is
      also possible where only part of the network (e.g., FFDs) is
      mains-powered.

   o  Security Level: sensor networks may carry sensitive information
      and require high-level security support where the availability,
      integrity, and confidentiality of the information are primordial.
      This high level of security may be needed in case of structural
      monitoring of key infrastructure or health monitoring of patients.

   o  Routing: The routing factor highlights the number of hops that has
      to be traversed to reach the edge of the network or a destination
      node within it.  A single hop may be needed for simple star-
      topologies or a multi-hop communication scheme for more elaborate
      topologies, such as meshes or trees.  From previous work on
      LoWPANs from academia and industry, various routing mechanisms
      have been introduced, such as data-centric, event-driven, address-
      centric, localization-based, or geographical routing.  We do not
      use such a fine granularity in our draft but rather use topologies



Kim, et al.             Expires January 15, 2009                [Page 5]


Internet-Draft       6LoWPAN Design and Applications           July 2008


      and single/multi-hop communication when referring to the routing
      categorization.

   o  Connectivity: Nodes within a LoWPAN are considered "always
      connected" when there is a network connection between any two
      given nodes.  However, due to external factors (e.g., extreme
      environment, mobility) or programmed disconnections (e.g.,
      sleeping mode), the network connectivity can be from
      "intermittent" (i.e., regular disconnection) to "sporadic" (i.e.,
      almost always disconnected network).

   o  Quality of Service (QoS): for mission-critical applications,
      support of QoS is mandatory in resource-constrained LoWPANs.

   o  Traffic Pattern: several traffic patterns may be used in sensor
      networks.  To name a few, Point-to-Multi-Point (P2MP), Multi-
      Point-to-Point (MP2P) and Point-to-Point (P2P).


































Kim, et al.             Expires January 15, 2009                [Page 6]


Internet-Draft       6LoWPAN Design and Applications           July 2008


3.  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 goal of this draft.  The intention is to define a minimal set
   of LoWPAN configurations to which any other scenario can be
   abstracted to.  Also, the characteristics of the scenarios described
   in this section do not reflect the characteristics that every LoWPAN
   must have in a particular environment (e.g., healthcare).

3.1.  Industrial Monitoring

3.1.1.  Application Features

   Sensor network 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.  Deploying wireless sensor networks, which
   can be installed inexpensively and provide more frequent and more
   reliable data, can reduce equipment downtime and eliminate costly
   manual equipment monitoring.  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:

   o  Process Monitoring and Control: combining advanced energy metering
      and sub-metering technologies with wireless sensor networking in
      order to optimize factory operations, reduce peak demand, and
      ultimately lower costs for energy.

      Manufacturing plants and engineering facilities, such as product
      assembly lines and engine rooms, can be drastically optimized
      using wireless sensor technology in order to ensure product
      quality, control energy consumption, avoid machine downtimes, and
      increase operation safety.  In industrial settings, sensors such
      as vibration detectors can be used to continuously monitor
      equipment and predict equipment failure and to detect the need for
      maintenance, with far greater precision.  This allows companies to
      avoid costly equipment failures or shutdowns of production lines
      and therefore increase their productivity.

      Greater access to process parameters gives engineers better
      visibility and ultimately better decision making power.  Various



Kim, et al.             Expires January 15, 2009                [Page 7]


Internet-Draft       6LoWPAN Design and Applications           July 2008


      sensor measurements, such as gas pressure, the flow of liquids and
      gases, room temperature and humidity, or tank charging levels may
      be used together with controllers and actuators to improve a
      plant's productivity in a continuous self-controlling loop, in
      which instruments can be upgraded, calibrated, and reconfigured as
      needed via the wireless channel.

      A plant's monitoring boundary often does not cover the entire
      facility but only those areas considered critical to the process.
      Easy to install wireless connectivity extends this line to include
      peripheral areas and process measurements that were previously
      infeasible or impractical to reach with wired connections.

   o  Machine Surveillance: ensuring product quality and efficient and
      safe equipment operation.  Critical equipment parameters such as
      vibration, temperature, and electrical signature are analyzed for
      abnormalities that are suggestive of impending equipment failure
      (see Section 3.2).

   o  Supply Chain Management and Asset Tracking: with the retail
      industry being legally responsible for the quality of sold goods,
      early detection of inadequate storage conditions with respect to
      temperature will reduce risk and cost to remove products from the
      sales channel.  Examples include container shipping, product
      identification, cargo monitoring, distribution and logistics.

      Global supply chain and transportation applications increasingly
      require real-time sensor and location information about their
      supplies and assets.  Wireless sensor networks meet these
      requirements efficiently with low installation and management
      costs, providing benefits such as reduced inventory, increased
      asset utilization, and precise location tracking of containers,
      goods, and mobile equipment.  Clients can be provided with an
      early warning of possible chain ruptures, for example by using
      call centers or conveniently accessing comprehensive on-line
      reports and data management systems.  Such reports could include
      monitoring of current states, the history of goods with critical
      conservation conditions, and in critical areas the monitoring
      status of oil containers, or verification of chemical gas
      substance concentration.

      For instance, thousands of cargo ships loaded with millions of
      containers are sailing the oceans today.  However, supply and
      demand are not equally distributed around the world, which results
      in high costs for shipping empty containers.  Sophisticated IT
      systems try to circumnavigate this problem and precision planning
      is critical in any case: the customer always expects containers to
      arrive just in time.  Wireless sensor networks have a great



Kim, et al.             Expires January 15, 2009                [Page 8]


Internet-Draft       6LoWPAN Design and Applications           July 2008


      potential of making this growing market even more efficient by
      allowing more reliable tracking and identification of containers,
      and cargo monitoring for hazardous freight detection or
      identification of illegal shipment.

      Also, the process of loading and unloading can be implemented more
      efficiently.  For example, after a crane operator has lifted a
      container from the deck, its content is identified and taken to
      the corresponding warehouse -- on a driverless truck whose
      movements are controlled at centimeter precision by transponders
      under the asphalt.

   o  Storage Monitoring: sensory systems designed to prevent releases
      of regulated substances to ground water, surface water and soil.
      This application field may also include theft/tampering prevention
      systems for storage facilities or other infrastructure, such as
      pipelines.

3.1.2.  A Use Case and its Requirements

   Storage Monitoring (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 sensor 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 to the coordinator.  FFD and RFD
   nodes are configured based on the topology.

   All sensor nodes do not move unless the blood packs or a container of
   block packs is moved.  Moving nodes get connected by logical
   attachment to a new coordinator.  Placement of coordinators differs
   between various service scenarios.

   The network configuration and routing tables are not changed in the
   storage room unless node failure occurs.

   This type of application works based on both periodic and event-
   driven notifications.  Periodic data is used for monitoring the right



Kim, et al.             Expires January 15, 2009                [Page 9]


Internet-Draft       6LoWPAN Design and Applications           July 2008


   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.

   Dominant parameters in industrial monitoring scenarios:

   o  Deployment: pre-planned, manually attached

   o  Mobility: no (except for the asset tracking case)

   o  Network Size: medium to large size, high node density

   o  Power Source: all battery-operated

   o  Security Level: business-critical.  Secure and reliable
      transmission must be guaranteed.  An extra key mechanism can be
      used.

   o  Routing: single- to multi-hop.  Routing tables are merely changed
      after configuration, except in the asset tracking case.  Node
      failure or indoor obstacles will cause the changes.

   o  Connectivity: always on for crucial processes, otherwise
      intermittent

   o  QoS: important for time-critical event-driven data

   o  Traffic Pattern: P2P (actuator control), MP2P (data collection)

   o  Other Issues: Sensor network management

3.1.3.  6LoWPAN Applicability

   The network configuration of the above use-case can differ
   substantially by system design.  The simplest way is to build up a
   star topology inside of the storage rooms, and connect the storage
   rooms with one link.  In this case the sensor nodes in the container
   can be either FFDs or RFDs.

   The PAN coordinators, C1, C2 and C3 are also 6LoWPAN routers.  Each
   sensor node builds up its link-local address and may get a prefix
   from its default router by ND procedure (Mesh-under based ND
   optimization is on-going work in the WG [7], and route-over based ND



Kim, et al.             Expires January 15, 2009               [Page 10]


Internet-Draft       6LoWPAN Design and Applications           July 2008


   optimization will be handled as well).  Inside of the storage room,
   the each node does not need to get a globally unique IPv6 address.
   However, the container can be moved inside or outside of the
   hospital, so that globally unique addresses may be needed depending
   on the purpose of the system.  Address auto-configuration is
   explained in Chapter 6 of RFC 4944.  When the system only uses link-
   local scope, 16-bit addresses can be utilized, but 64-bit addresses
   are recommended for globally unique addressing.


         X  X  X     X  X  X     X  X  X
          \ | /       \ | /       \ | /
           C1 -------- C2 -------- C3        C: LoWPAN coordinator (FFD)
          / | \       / | \       / | \         (Data Aggregator)
         X  X  X     X  X  X     X  X  X     X: FFD or RFD

             Figure 2: Storage rooms with simple star topology

   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 or
   additional security mechanisms can be used.

   Because a failure of a sensor node can critically affect the storage
   of the blood packs, network management is important here.  SNMP-lite
   should be provided for the management.

   When the container is moved out from the storage room, and connected
   to the hospital system (if the hospital buildings are fully or partly
   covered with 6LoWPANs), it should rebind to a new parent and a
   6LoWPAN router.  ND will support this procedure.  In case that it is
   moved by an ambulance, it will be connected to the vehicle gateway or
   router.


3.2.  Structural Monitoring

3.2.1.  Application Features

   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.





Kim, et al.             Expires January 15, 2009               [Page 11]


Internet-Draft       6LoWPAN Design and Applications           July 2008


3.2.2.  A Use Case and its Requirements

   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
   sensor 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 coordinator.  All sensor nodes do
   not move while the service is provided.  The network configuration
   and routing tables are changed only in case of node failure.  Except
   from the pillars, there are no special obstacles of attenuation to
   the sensor signals, but careful configuration is needed to prevent
   signal interference between sensors.

   The network configuration and routing tables are changed only in case
   of node failure.  On the top part of each pillar, an "infrastructure"
   FFD sink node is placed to collect the sensed data.  The FFD is the
   LoWPAN coordinator of the sensors for each pillar which can be either
   FFDs or RFDs.

   A logical entity of data gathering can lie with each LoWPAN
   coordinator.  Communication schedules must be set up between leaf
   nodes and their LoWPAN coordinator 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.  The event-driven data sensed on abnormal
   occurrences is time-critical and requires secure and reliable
   transmission.  For energy conservation, all sensors could have
   periodic and long sleep modes but wake up on certain events.

   The LoWPAN coordinators can play the role of a gateway, so that a
   third party with internet access can check the status of the specific
   pillar.  Due to the contents of the data, only authenticated users
   should be allowed to access the data.

   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, and periodic and event-
   driven real-time data gathering.



Kim, et al.             Expires January 15, 2009               [Page 12]


Internet-Draft       6LoWPAN Design and Applications           July 2008


   Dominant parameters in structural monitoring applications:

   o  Deployment: static, organized, pre-planned

   o  Mobility: none

   o  Network Size: small (dozens of nodes) to large, low density

   o  Power Source: mostly battery powered (except LoWPAN coordinators)

   o  Security Level: safety-critical.  Secure transmission must be
      guaranteed.  Only authenticated users should be able to access and
      handle the data.  Lightweight key mechanisms can be used.

   o  Routing: star-topology (potentially hierarchical) In case of
      hierarchical case, reorganization of routing tree may be the
      issue.  However, routing table may merely be changed after
      configuration.  Node failure or indoor obstacles will cause the
      changes.

   o  Connectivity: always connected or intermittent by sleeping mode
      scheduling.

   o  QoS: Emergency notification (fire, over-threshold vibrations,
      water level, etc) is required to have priority of delivery and
      must be transmitted in a highly reliable manner.

   o  Traffic Pattern: MP2P (data collection), P2P (localized querying)

   o  Other Issues: accurate sensing and reliable transmission are
      important.  In addition, sensor status reports may be needed to
      maintain a reliable monitoring system.


                            X  X  X
                             \ | /
                         X --- O --- X
                             / | \        O: LoWPAN coordinator (FFD)
                            X  X  X       X: FFD or RFD

              Figure 3: A LoWPAN with a simple star topology.

3.2.3.  6LoWPAN Applicability








Kim, et al.             Expires January 15, 2009               [Page 13]


Internet-Draft       6LoWPAN Design and Applications           July 2008


3.3.  Healthcare

3.3.1.  Application Features

   LoWPANs are envisioned to be heavily used in healthcare environments.
   They would ease the deployment of new services by getting rid of
   cumbersome wires and ease the patient care and life in hospitals and
   for home care.  In this environment, delay 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 sensors
   monitoring various metrics to more complex systems for studying life
   dynamics can be supported by the LoWPAN.  In this latter category, a
   large amount of data from various sensors 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
   [6] using the concept of Personal Networks.

3.3.2.  A Use Case and its Requirements

   Healthcare at Home by Tele-Assistance

   An old citizen who lives alone wears one to few wearable sensors to
   measure heartbeat, pulse rate, etc.  Dozens of sensor nodes are
   densely installed at home for movement detection.  A LoWPAN home
   gateway will send the sensing data to the 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 will 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 sensing data is
   very personal data.  In addition, different data will be provided to
   the hospital system than 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 here.

   Dominant parameters in healthcare applications:




Kim, et al.             Expires January 15, 2009               [Page 14]


Internet-Draft       6LoWPAN Design and Applications           July 2008


   o  Deployment: pre-planned

   o  Mobility: moderate (patient's mobility)

   o  Network Size: small, high node density

   o  Power Source: hybrid

   o  Security Level: Data privacy and security must be provided.
      Encryption is required.  Role based access control is required to
      be support by proper authentication mechanism

   o  Routing: multihop for homecare devices, star topology on patients
      body.  Multipath interference due to walls and obstacles at home
      must be considered.

   o  Connectivity: always on

   o  QoS: high level of support (life and death implication), role-
      based

   o  Traffic Pattern: MP2P/P2MP (data collection), P2P (local
      diagnostic)

   o  Other issues: Plug-and-play configuration is required for mainly
      non-technical end-users.  Real-time data acquisition and analysis
      are important.  Efficient data management is needed for various
      devices which have different duty-cycles, and for role-based data
      control.  Reliability and robustness of the network are also
      essential.

3.3.3.  6LoWPAN Applicability

   In this use-case, the network size is rather small (less than 10s of
   nodes).  The home system is static with multi-hop paths, and the
   patient's body network can be built on single-hop.  The home gateway
   will be the sink node in the routing path.  A 6LoWPAN router is
   logically or physically combined with it.  A plug-and-play
   configuration is required.  Each home system node will get a link-
   local IPv6 address following the auto-configuration described in RFC
   4944.  As the communication of the system is limited to the home,
   both 16-bit and 64-bit can be used to create their IPv6 link-local
   addresses.

   Multi-hop communication can be achieved by either mesh-under or
   route-over routing mechanisms.  In case the mesh-under mechanism is
   provided, the 6LoWPAN router becomes the only router, and ND is done
   as [7] describes.  The mesh-under based ND is still on-going work,



Kim, et al.             Expires January 15, 2009               [Page 15]


Internet-Draft       6LoWPAN Design and Applications           July 2008


   and the routing mechanism is in study.  When route-over is used, some
   FFDs will play role in 6lowpan routers and the network will build up
   one IPv6 link.  IP-based routing is now chartered at the ROLL WG.

   The patient's body network can be simply configured by a single-hop.
   [7] is used in there, but RA may need to be optimized as it is sent
   to the FFD (or in other name, coordinator) by unicast, and the
   coordinator forward it to his neighbor nodes.

   The mobility of the patient's body area network is caused by the
   patient's movement within the home.  If there are not many obstacles
   to block or distort the signal, it may not need additional mobility
   support.  If not, additional mobility support must be provided.
   Currently there is no mobility work is handled by the 6LoWPAN WG.


     +-------+      +--------------+      +----------+      +----------+
     | Sinks | ---- | Home Gateway | ---- | Backbone | ---- | Hospital |
     +-------+      +--------------+      +----------+      +----------+
         |
         | ------------------------
         |                        |
         O             O -- O --- O --- X            O: FFD
        /|\            |          |\                 X: RFD (or FFD)
       X X X           X          X X

     (patient)            (home system)

                  Figure 4: A mobile healthcare scenario.


3.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:

   o  Home safety/security

   o  Home Automation and Control

   o  Healthcare (see above section)

   o  Smart appliances and home entertainment systems

   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.




Kim, et al.             Expires January 15, 2009               [Page 16]


Internet-Draft       6LoWPAN Design and Applications           July 2008


   [Example]: Home Automation

   In terms of home safety and security, the LoWPAN is made of motion,
   audio, door/window sensors, video cameras to which additional sensors
   can be added for security (gas, water, CO, Radon, smoke detection).
   The LoWPAN typically comprises a few dozen of nodes forming a ad-hoc
   network with multi-hop routing since the nodes may not be in direct
   range.  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, a video camera will be activated sending a video
   stream to a gateway that can be received on a cell phone.

   The Home automation and control system LoWPAN offers a wide range of
   services: local or remote access from the Internet (via a secured
   gateway) to monitor the home (temperature, humidity, activation of
   remote video surveillance, status of the doors (locked),...) 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.

   Ergonomics in Connected Homes is 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).  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:

   o  Deployment: multi-hop topologies

   o  Mobility: small degree of mobility





Kim, et al.             Expires January 15, 2009               [Page 17]


Internet-Draft       6LoWPAN Design and Applications           July 2008


   o  Network Size: medium number of nodes, potentially high density

   o  Power Source: mix of battery and AC powered devices

   o  Security Level: authentication and encryption required

   o  Routing: no requirement for multi-topology or QoS routing

   o  Connectivity: intermittent (usage-dependent sleep modes)

   o  QoS: support of limited QoS (small number of Class of Service)

   o  Traffic Pattern: P2P (inter-device), P2MP and MP2P (polling)


3.5.  Vehicle Telematics

   LoWPANs play an important role in intelligent transportation systems.
   Incorporated in roads and/or, 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.

   [Example]: Telematics

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

   Dominant parameters in vehicle telematics applications:

   o  Deployment: scattered, pre-planned

   o  Mobility: high

   o  Network Size: large





Kim, et al.             Expires January 15, 2009               [Page 18]


Internet-Draft       6LoWPAN Design and Applications           July 2008


   o  Power Source: mostly battery powered

   o  Security Level: low

   o  Routing: multi-hop

   o  Connectivity: intermittent

   o  QoS: support of limited QoS

   o  Traffic Pattern: mostly Multi-Point-to-Point (MP2P)


           +-------+
           | Sinks | (at the road side)
           +-------+
        -------|------------------------------
               |
         O --- O --- O ----- O   +---|---+
              /       \      |   | X-O-X | (cars)
             O         O --- O   +---|---+          O: FFD
                                                    X: RFD
        --------------------------------------

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


3.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.

   [Example]: Automated Vineyard

   In a vineyard with medium to large geographical size, a number of 50
   to 100 FFDs nodes are manually deployed in order to provide full



Kim, et al.             Expires January 15, 2009               [Page 19]


Internet-Draft       6LoWPAN Design and Applications           July 2008


   signal coverage over the study area.  These FFD nodes support a
   multi-hop routing scheme to enable data forwarding to a sink node at
   the edge of the vineyard.  An additional number of 100 to 1000
   (possibly different) specialized RFD sensors (i.e., humidity,
   temperature, soil condition, sunlight) are attached to the FFDs in
   local wireless star topologies, periodically reporting measurements
   to the associated master FFD.  For example, in a 20-acres vineyard
   with 8 parcels of land, 10 sensors are placed within each parcel to
   provide readings on temperature and soil moisture.  Each of the 8
   parcels contains 1 FFD sink to collect the sensor data. 10
   intermediate FFD "routers" are used to connect the sinks to the main
   gateway.

   Sensor 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 sensors are in periodic sleep
   state.  However, FDD nodes need to be aware of sudden events from
   RFDs.  Their sleep periods should therefore be set to shorter
   intervals.  Communication schedules must be set up between RFDs and
   FFDs and global time synchronization is needed to account for clock
   drift.

   Sensor 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:

   o  Deployment: pre-planned

      The sensor nodes are installed outdoors or in a greenhouse with
      high exposure to water, soil, dust, in dynamic environments of
      moving people and machinery, with growing crop and foliage.
      Sensor nodes can be deployed in a pre-defined manner, considering
      the harsh environment.

   o  Mobility: all static




Kim, et al.             Expires January 15, 2009               [Page 20]


Internet-Draft       6LoWPAN Design and Applications           July 2008


   o  Network Size: medium to large, low to medium density

   o  Power Source: all nodes are battery-powered, except the sink

   o  Security Level: business-critical.  Light-weight security or a
      global key management can be used depending on the business
      purpose.

   o  Routing: mesh topology with local star connections.  Routing table
      is merely changed after configuration.  Node failure or indoor
      obstacles will cause the changes.

   o  Connectivity: intermittent (many sleeping nodes)

   o  QoS: not critical

   o  Traffic Pattern: Mainly MP2P/P2MP.  P2P for Gateway communication
      or actuator triggering.

   o  Other issues: Time synchronization among sensors are required, but
      the traffic interval may not be frequent (e.g. once in 30 minutes
      to 1 hour).


                        X X X  X X X  X X X  X X X
         +---------+     \|/    \|/    \|/    \|/
         | Gateway | ---- O ---- O ---- O ---- O
         +---------+     /|\    /|\    /|\    /|\     X: RFD
                        X X X  X X X  X X X  X X X    O: FFD

                  Figure 6: An aligned multi-hop LoWPAN.




















Kim, et al.             Expires January 15, 2009               [Page 21]


Internet-Draft       6LoWPAN Design and Applications           July 2008


4.  Security Considerations

   To be defined.
















































Kim, et al.             Expires January 15, 2009               [Page 22]


Internet-Draft       6LoWPAN Design and Applications           July 2008


5.  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.















































Kim, et al.             Expires January 15, 2009               [Page 23]


Internet-Draft       6LoWPAN Design and Applications           July 2008


6.  References

6.1.  Normative References

   [1]  Bradner, S., "Key words for use in RFCs to Indicate Requirement
        Levels", BCP 14, RFC 2119, March 1997.

   [2]  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.

   [3]  IEEE Computer Society, "IEEE Std. 802.15.4-2006", October 2003.

6.2.  Informative References

   [4]  Bulusu, N. and S. Jha, "Wireless Sensor Networks", July 2005.

   [5]  Roemer, K. and F. Mattern, "The Design Space of Wireless Sensor
        Networks", December 2004.

   [6]  den Hartog, F., Schmidt, J., and A. de Vries, "On the Potential
        of Personal Networks for Hospitals", May 2006.

   [7]  Chakrabarti, S. and E. Nordmark, "LoWPAN Neighbor Discovery
        Extensions, draft-chakrabarti-6lowpan-ipv6-nd-04 (work in
        progress)", November 2007.
























Kim, et al.             Expires January 15, 2009               [Page 24]


Internet-Draft       6LoWPAN Design and Applications           July 2008


Authors' Addresses

   Eunsook Kim
   ETRI
   161 Gajeong-dong
   Yuseong-gu
   Daejeon  305-700
   Korea

   Phone: +82-42-860-6124
   Email: eunah.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


   Dominik Kaspar
   Simula Research Laboratory
   Martin Linges v 17
   Snaroya  1367
   Norway

   Phone: +47-4748-9307
   Email: dokaspar.ietf@gmail.com


   JP Vasseur
   Cisco Systems, Inc
   1414 Massachusetts Avenue
   Boxborough  MA 01719
   USA

   Phone:
   Email: jpv@cisco.com









Kim, et al.             Expires January 15, 2009               [Page 25]


Internet-Draft       6LoWPAN Design and Applications           July 2008


Full Copyright Statement

   Copyright (C) The IETF Trust (2008).

   This document is subject to the rights, licenses and restrictions
   contained in BCP 78, and except as set forth therein, the authors
   retain all their rights.

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
   THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
   OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
   THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.


Intellectual Property

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at
   ietf-ipr@ietf.org.











Kim, et al.             Expires January 15, 2009               [Page 26]