6LoWPAN Working Group E. Kim
Internet-Draft ETRI
Expires: January 10, 2010 D. Kaspar
Simula Research Laboratory
N. Chevrollier
TNO
JP. Vasseur
Cisco Systems, Inc
July 9, 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.
Kim, et al. Expires January 10, 2010 [Page 1]
Internet-Draft 6LoWPAN Design and Applications July 2009
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 . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Basic network configuration . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6
3. Design Space . . . . . . . . . . . . . . . . . . . . . . . . . 7
4. Application Scenarios . . . . . . . . . . . . . . . . . . . . 9
4.1. Industrial Monitoring . . . . . . . . . . . . . . . . . . 9
4.1.1. A Use Case and its Requirements . . . . . . . . . . . 10
4.1.2. 6LoWPAN Applicability . . . . . . . . . . . . . . . . 11
4.2. Structural Monitoring . . . . . . . . . . . . . . . . . . 13
4.2.1. A Use Case and its Requirements . . . . . . . . . . . 13
4.2.2. 6LoWPAN Applicability . . . . . . . . . . . . . . . . 15
4.3. Healthcare . . . . . . . . . . . . . . . . . . . . . . . . 16
4.3.1. A Use Case and its Requirements . . . . . . . . . . . 16
4.3.2. 6LoWPAN Applicability . . . . . . . . . . . . . . . . 18
4.4. Connected Home . . . . . . . . . . . . . . . . . . . . . . 19
4.4.1. A Use Case and its Requirements . . . . . . . . . . . 19
4.4.2. 6LoWPAN Applicability . . . . . . . . . . . . . . . . 21
4.5. Vehicle Telematics . . . . . . . . . . . . . . . . . . . . 22
4.5.1. A Use Case and its Requirements . . . . . . . . . . . 22
4.5.2. 6LoWPAN Applicability . . . . . . . . . . . . . . . . 23
4.6. Agricultural Monitoring . . . . . . . . . . . . . . . . . 24
4.6.1. A Use Case and its Requirements . . . . . . . . . . . 24
4.6.2. 6LoWPAN Applicability . . . . . . . . . . . . . . . . 26
5. Security Considerations . . . . . . . . . . . . . . . . . . . 28
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 29
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 30
7.1. Normative References . . . . . . . . . . . . . . . . . . . 30
7.2. Informative References . . . . . . . . . . . . . . . . . . 30
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 31
Kim, et al. Expires January 10, 2010 [Page 2]
Internet-Draft 6LoWPAN Design and Applications July 2009
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]. 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 [5].
However, typical wireless radios for LoWPANs are battery-operated
and consume between 10 mW and 20 mW [9].
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
[9].
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.
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 and describing the
characteristics of LoWPANs in Section 3, this document provides a
list of use cases and market domains that may benefit and motivate
the work currently done in the 6LoWPAN WG.
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
Kim, et al. Expires January 10, 2010 [Page 3]
Internet-Draft 6LoWPAN Design and Applications July 2009
nodes, or a network with mesh topology as shown in Figure 1. 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). 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). In a Route Over configuration,
Multihop transmission is achieved using IP routing (see Figure 1).
More information about Mesh Under and Route Over is in 6LoWPAN ND [6]
and 6LoWPAN Routing Requirements [8].
Kim, et al. Expires January 10, 2010 [Page 4]
Internet-Draft 6LoWPAN Design and Applications July 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
Kim, et al. Expires January 10, 2010 [Page 5]
Internet-Draft 6LoWPAN Design and Applications July 2009
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].
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" [3], and " Transmission of IPv6 Packets over IEEE 802.15.4
Networks" [4].
Readers would benefit from reading 6LoWPAN ND [6], 6LoWPAN header
compression [7], and 6LoWPAN Routing Requirements [8] for the details
of the each 6LoWPAN work.
This specification makes extensive use of the same terminology
defined in 6LoWPAN ND [6] 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.
Kim, et al. Expires January 10, 2010 [Page 6]
Internet-Draft 6LoWPAN Design and Applications July 2009
3. Design Space
Inspired by [10], 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].
The possible dimensions for scenario categorization used in this
document are described as follows:
o Deployment: LoWPAN nodes can be scattered randomly or they may be
deployed in an organized manner in a LoWPAN. 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
LoWPAN and how to allocate addresses in the network.
o Network Size: The network size takes into account nodes that
provide the intended network capability. The number of nodes
involved in a LoWPAN could be small (10 nodes), moderate (several
100s), or large (over a 1000).
o Power Source: The power source of nodes, whether the nodes are
battery-powered or mains-powered, influences the network design.
A hybrid solution is also possible where only part of the network
is mains-powered.
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 because of nodes in
sleep mode) to "sporadic" (i.e., almost always disconnected
network).
o Multi-hop communication: The multi-hop communication 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 by academia and industry on LoWPANs,
various routing mechanisms have been introduced, such as data-
centric, event-driven, address-centric, localization-based,
geographical routing, etc. This document does not make use of
such a fine granularity but rather uses topologies and single/
multi-hop communication.
Kim, et al. Expires January 10, 2010 [Page 7]
Internet-Draft 6LoWPAN Design and Applications July 2009
o Traffic Pattern: several traffic patterns may be overused in
LoWPANs. To name a few, Point-to-Multi-Point (P2MP), Multi-Point-
to-Point (MP2P) and Point-to-Point (P2P).
o Security Level: LoWPANs 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 Mobility: Inherent to the wireless characteristics of LoWPANs,
LoWPAN 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 Quality of Service (QoS): for mission-critical applications,
support of QoS is mandatory in resource-constrained LoWPANs.
Kim, et al. Expires January 10, 2010 [Page 8]
Internet-Draft 6LoWPAN Design and Applications July 2009
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.
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:
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,
ultimately lower costs for energy, avoid machine downtimes, and
increase operation safety.
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 4.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.
Kim, et al. Expires January 10, 2010 [Page 9]
Internet-Draft 6LoWPAN Design and Applications July 2009
o Storage Monitoring: sensor 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.
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
Kim, et al. Expires January 10, 2010 [Page 10]
Internet-Draft 6LoWPAN Design and Applications July 2009
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:
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: most of the time battery-operated
o Security Level: business-critical. Secure and reliable
transmission must be guaranteed. An extra key mechanism can be
used.
o Multi-hop communication: single- to multi-hop. Forwarding/Routing
tables are merely changed after configuration, except in the asset
tracking case. Node failure or indoor obstacles will cause the
changes. Reliability must be supported for 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, location tracking, real-
time early warning
4.1.2. 6LoWPAN Applicability
The network configuration of the above use-case can differ
substantially by system design. As illustrated in Figure 4, 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,
Kim, et al. Expires January 10, 2010 [Page 11]
Internet-Draft 6LoWPAN Design and Applications July 2009
link-layer addresses in mesh-header defined in RFC 4944 [4] 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. 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].
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]. 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].
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] 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).
Kim, et al. Expires January 10, 2010 [Page 12]
Internet-Draft 6LoWPAN Design and Applications July 2009
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
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.
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
Kim, et al. Expires January 10, 2010 [Page 13]
Internet-Draft 6LoWPAN Design and Applications July 2009
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), 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:
o Deployment: static, organized, pre-planned
o Mobility: none
o Network Size: small (dozens of nodes) to large
o Power Source: mains-powered nodes are mixed with battery powered
(mains-power nodes will be used for coordinators or relays)
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 is recommended to be
used.
o Multi-hop communication: star-topology (potentially hierarchical)
In case of hierarchical case, reorganization of routing tree may
be the issue. However, forwarding/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.
Kim, et al. Expires January 10, 2010 [Page 14]
Internet-Draft 6LoWPAN Design and Applications July 2009
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.
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]. 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]. 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] 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].
Due to the safety-critical data of the structure, authentication and
Kim, et al. Expires January 10, 2010 [Page 15]
Internet-Draft 6LoWPAN Design and Applications July 2009
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
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] using the concept of Personal Networks.
4.3.1. A Use Case and its Requirements
Example: Healthcare at Home by Tele-Assistance
Kim, et al. Expires January 10, 2010 [Page 16]
Internet-Draft 6LoWPAN Design and Applications July 2009
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:
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 Multi-hop communicaton: multi-hop 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)
Kim, et al. Expires January 10, 2010 [Page 17]
Internet-Draft 6LoWPAN Design and Applications July 2009
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.
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]. 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] and new header format in [7]. An example topology
is provided in Figure 8.
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] 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.
Kim, et al. Expires January 10, 2010 [Page 18]
Internet-Draft 6LoWPAN Design and Applications July 2009
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.
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:
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.
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
Kim, et al. Expires January 10, 2010 [Page 19]
Internet-Draft 6LoWPAN Design and Applications July 2009
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).
Kim, et al. Expires January 10, 2010 [Page 20]
Internet-Draft 6LoWPAN Design and Applications July 2009
Dominant parameters for home automation applications:
o Deployment: multi-hop topologies
o Mobility: some degree of mobility
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 Multi-hop communication: 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)
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]).
Kim, et al. Expires January 10, 2010 [Page 21]
Internet-Draft 6LoWPAN Design and Applications July 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).
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.
4.5.1. A Use Case and its Requirements
Example: Telematics
Kim, et al. Expires January 10, 2010 [Page 22]
Internet-Draft 6LoWPAN Design and Applications July 2009
As shown in Figure 10, 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:
o Deployment: scattered, pre-planned
o Mobility: none (road infrastructure), high(vehicle)
o Network Size: large (road infrastructure), small (vehicle)
o Power Source: mostly battery powered
o Security Level: low
o Multi-hop communication: multi-hop, especially ad-hoc
o Connectivity: intermittent
o QoS: support of limited QoS
o Traffic Pattern: mostly Point-to-Point (P2P), Point-to-Multi-Point
(P2MP)
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] and 6LoWPAN ND [6].
Kim, et al. Expires January 10, 2010 [Page 23]
Internet-Draft 6LoWPAN Design and Applications July 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.
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.
4.6.1. A Use Case and its Requirements
Example: Automated Vineyard
Kim, et al. Expires January 10, 2010 [Page 24]
Internet-Draft 6LoWPAN Design and Applications July 2009
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:
o Deployment: pre-planned
The 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. LoWPAN nodes
can be deployed in a pre-defined manner, considering the harsh
environment.
o Mobility: all static
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.
Kim, et al. Expires January 10, 2010 [Page 25]
Internet-Draft 6LoWPAN Design and Applications July 2009
o Mutli-hop communication: mesh topology with local star
connections. Forwarding/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).
4.6.2. 6LoWPAN Applicability
The network configuration in this use case might, in the most simple
case, look like illustrated in Figure 11. 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], 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
Kim, et al. Expires January 10, 2010 [Page 26]
Internet-Draft 6LoWPAN Design and Applications July 2009
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.
Kim, et al. Expires January 10, 2010 [Page 27]
Internet-Draft 6LoWPAN Design and Applications July 2009
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.
Kim, et al. Expires January 10, 2010 [Page 28]
Internet-Draft 6LoWPAN Design and Applications July 2009
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.
Kim, et al. Expires January 10, 2010 [Page 29]
Internet-Draft 6LoWPAN Design and Applications July 2009
7. References
7.1. Normative References
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[2] Narten, T., Nordmark, E., Simpson, W., and H. Soliman,
"Neighbor Discovery for IP version 6 (IPv6)", RFC 4861,
September 2007.
[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.
[4] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler,
"Transmission of IPv6 Packets over IEEE 802.15.4 Networks",
RFC 4944, September 2007.
[5] IEEE Computer Society, "IEEE Std. 802.15.4-2006 (as amended)",
2007.
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.
[7] Hui, J. and P. Thubert, "Compression Format for IPv6 Datagrams
in 6LoWPAN Networks", draft-ietf-6lowpan-hc-05 (work in
progress), June 2009.
[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.
[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.
Kim, et al. Expires January 10, 2010 [Page 30]
Internet-Draft 6LoWPAN Design and Applications July 2009
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
Kim, et al. Expires January 10, 2010 [Page 31]
