[Docs] [txt|pdf] [Tracker] [Email] [Nits]

Versions: 00 01 02 03 draft-ietf-6lowpan-usecases

6LoWPAN Working Group                                             E. Kim
Internet-Draft                                                ETRI / PEC
Expires: December 13, 2007                                N. Chevrollier
                                                                     TNO
                                                               D. Kaspar
                                                              ETRI / PEC
                                                           June 11, 2007


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

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 December 13, 2007.

Copyright Notice

   Copyright (C) The IETF Trust (2007).











Kim, et al.             Expires December 13, 2007               [Page 1]


Internet-Draft       6LoWPAN Design and Applications           June 2007


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  . . . . . . . . . . . . . . . . . . . .  6
     3.1.  Structural Monitoring ('Intelligent Bridge') . . . . . . .  6
     3.2.  Agricultural Monitoring ('Vineyard') . . . . . . . . . . .  7
     3.3.  Patient Monitoring ('Hospital')  . . . . . . . . . . . . .  9
     3.4.  Vehicle Telematics ('Smart Roads') . . . . . . . . . . . .  9
   4.  6LoWPAN benefits . . . . . . . . . . . . . . . . . . . . . . . 11
   5.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12
   6.  Security Considerations  . . . . . . . . . . . . . . . . . . . 13
   7.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 14
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15
   Intellectual Property and Copyright Statements . . . . . . . . . . 16






























Kim, et al.             Expires December 13, 2007               [Page 2]


Internet-Draft       6LoWPAN Design and Applications           June 2007


1.  Introduction

   LoWPANs are inexpensive, low-performance, wireless communication
   networks, and are formed by devices complying with the IEEE 802.15.4
   standard [1].  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 [1].
      However, typical wireless radios for LoWPANs are battery-operated
      and consume between 10 mW and 20 mW [2].

   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 non line-of-sight situations
      [2].

   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.

   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
   responsible for address allocation.  One can note that a LoWPAN
   coordinator is responsible for a single LoWPAN.






Kim, et al.             Expires December 13, 2007               [Page 3]


Internet-Draft       6LoWPAN Design and Applications           June 2007


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

                        Figure 1: 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 December 13, 2007               [Page 4]


Internet-Draft       6LoWPAN Design and Applications           June 2007


2.  Design Space

   From [3], 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 characteristics of a 6LoWPAN (e.g., low-power, short range,
   low-bit rate) as described in [4].  Hence, this section highlights
   the dimensions that are inherent to the nature of LoWPANs.  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
      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: This number 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  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
      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 "intermittent"
      (i.e., regular disconnection) to "sporadic" (i.e., almost always
      disconnected network).



Kim, et al.             Expires December 13, 2007               [Page 5]


Internet-Draft       6LoWPAN Design and Applications           June 2007


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 use case (e.g., healthcare).

3.1.  Structural Monitoring ('Intelligent Bridge')

   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.

   Dominant parameters:

   o  static deployment

   o  small size of networks (dozens of nodes)

   o  star topology (potentialy with hierarchy)

   o  all battery-powered except LoWPAN coordinators


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

              Figure 2: A LoWPAN with a simple star topology.

   Example: A 1000m long bridge with 10 pillars.  Each pillar contains 5
   sensors to measure the water level, and 5 vibration sensors to
   monitor its structural health.  On the top part of each pillar, an
   "infrastructure" FFD sink node is placed to collect the sensor data.
   The FFD is the LoWPAN coordinator of the sensors for each pillar
   which can be FFD or RFD.  All nodes are static, 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 table are changed only in case of node
   failure.  Except from the pillar itself, there are no special
   obstacles of attenuation to the sensor signals, but careful
   configuration is needed to prevent signal interference between



Kim, et al.             Expires December 13, 2007               [Page 6]


Internet-Draft       6LoWPAN Design and Applications           June 2007


   sensors.

   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.  This type of
   application works based on event-driven notifications.  The data over
   or under a pre-defined threshold is meaningful to report.  The event-
   driven data sensed on abnormal occurances is time-critical and
   required secure and reliable transmission.  For energy saving, 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 a medium size sensor network to
   monitor a building for instance.  They still have similar
   characteristics such as static nodes, manually deployed networks, and
   mostly star (or multi-level of star) topology, and event-driven real-
   time data gathering.

3.2.  Agricultural Monitoring ('Vineyard')

   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.

   Dominant parameters:

   o  static mesh topology with local star topologies

   o  medium to large number of nodes

   o  all nodes are battery-powered, except sink




Kim, et al.             Expires December 13, 2007               [Page 7]


Internet-Draft       6LoWPAN Design and Applications           June 2007


                        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 3: An aligned multi-hop LoWPAN.

   Example: 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 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, 8
   parcels of land with each 10 sensors 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
   WPAN, 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.







Kim, et al.             Expires December 13, 2007               [Page 8]


Internet-Draft       6LoWPAN Design and Applications           June 2007


3.3.  Patient Monitoring ('Hospital')

   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.  In
   this environment, delay or lost information may be a matter of life
   or death, therefore LoWPANs have to reliably cope with a highly
   mobile environment.

   Dominant parameters:

   o  small star topologies in static infrastucture

   o  mobility

   o  always connected

   o  programmed deployment


         +-------+
         | Sinks | (in hospital walls)
         +-------+
             |
       +-----------+
       |     O     | (on patient's body)
       |    /|\    |
       |   X X X   |     O: FFD
       +-----------+     X: RFD (could be replaced with FFDs)

                  Figure 4: A mobile star-shaped LoWPAN.

   Example: a small number (e.g, less than 10) of sensors are deployed
   on a patient body for medical surveillance.  They monitor vital signs
   such as heart beats (electrocardiogram-ECG) or blood pressure, and
   provide localization information.  The patient is able to move in his
   room or within the hospital.  The collected data is sent to sinks
   placed onto hospital's walls.  Sinks in the hospital's walls are
   mains powered.  Devices carried by the patient run on battery.
   Localization-based services are provided in this scenario.
   Furthermore, the stringent requirements of medical applications imply
   highly reliable communications over a robust network.

3.4.  Vehicle Telematics ('Smart Roads')

   LoWPANs play an important role in intelligent transportation systems.
   Incorporated in roads or/and, they contribute to the improvement of
   safety of transporting systems.  Through traffic or air-quality



Kim, et al.             Expires December 13, 2007               [Page 9]


Internet-Draft       6LoWPAN Design and Applications           June 2007


   monitoring, they increase the possibilities in terms of traffic flow
   optimization and help reducing road congestion.

   Dominant parameters:

   o  static multi-hop topology

   o  large network

   o  scattered deployment

   o  intermittent connectivity


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

   Example: Scattered sensors are included in roads during their
   construction for motion monitoring.  When a car passes on top of
   these sensors, the possibility is then given to track the trajectory
   and velocity of the car for safety purpose.  The lifetime of sensors
   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 place at the road side are mains powered, sensor nodes in the
   roads run on battery.  Power savings schemes might disconnect
   intermittently sensors nodes.  A rough estimate of 4 sensors per
   square meter is needed.














Kim, et al.             Expires December 13, 2007              [Page 10]


Internet-Draft       6LoWPAN Design and Applications           June 2007


4.  6LoWPAN benefits

   Sensor networks have been implemented in various industrial fields
   and there are many application scenarios that can be listed [3].
   Thus, one could question the relevance of providing 6LoWPAN scenarios
   so many sensor application scenarios already exist using non-IP based
   communications, and proprietary routing or configuration mechanisms.
   While not a preliminary goal of this draft, we enumerate few
   motivations.

   First, 6LoWPAN will make pervasive internet communication with
   sensors, using standard IP protocols, without changing underling MAC/
   PHY which has been used for sensor networks.  Some emerging sensor
   network applications in health care or in intelligent transportation
   systems can benefit of the end-to-end communication paradigm of IP
   networks.  It is noted that 6LoWPAN sensors need light version of
   IPv6 that could be used in low-powered, low-cost LoWPANs, but it is
   out of the scope of this document.

   Second, 6LoWPAN will give interoperability capability to LoWPANs.  If
   company X is developing its own network stack for LoWPAN and company
   Y another one, thousand of different implementations will have to
   coexist.

   Third, using IP for LoWPANs will leverage existing protocols [5].
   Established security protocols, naming and addressing schemes, to
   name only a few, could be reused to some extend in the context of a
   LoWPAN.























Kim, et al.             Expires December 13, 2007              [Page 11]


Internet-Draft       6LoWPAN Design and Applications           June 2007


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 December 13, 2007              [Page 12]


Internet-Draft       6LoWPAN Design and Applications           June 2007


6.  Security Considerations

   Security issues are not within the scope of this document.
















































Kim, et al.             Expires December 13, 2007              [Page 13]


Internet-Draft       6LoWPAN Design and Applications           June 2007


7.  References

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

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

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

   [4]  Kushalnagar, N., Montenegro, G., and C. Schumacher, "6LoWPAN:
        Overview, Assumptions, Problem Statement and Goals,
        draft-ietf-6LoWPAN-problem-08 (work in progress)",
        February 2007.

   [5]  Culler, D. and J. Hui, "6lowPAN Tutorial: IP on IEEE 802.15.4
        Low Power Wireless Networks", May 2007.



































Kim, et al.             Expires December 13, 2007              [Page 14]


Internet-Draft       6LoWPAN Design and Applications           June 2007


Authors' Addresses

   Eunsook Kim
   ETRI / PEC
   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
   ETRI / PEC
   161 Gajeong-dong
   Yuseong-gu
   Daejeon  305-700
   Korea

   Phone: +82-42-860-1072
   Email: dominik.ietf@gmail.com


















Kim, et al.             Expires December 13, 2007              [Page 15]


Internet-Draft       6LoWPAN Design and Applications           June 2007


Full Copyright Statement

   Copyright (C) The IETF Trust (2007).

   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.


Acknowledgment

   Funding for the RFC Editor function is provided by the IETF
   Administrative Support Activity (IASA).





Kim, et al.             Expires December 13, 2007              [Page 16]


Html markup produced by rfcmarkup 1.129b, available from https://tools.ietf.org/tools/rfcmarkup/