One document matched: draft-ietf-6lowpan-usecases-02.xml
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY RFC2119 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY RFC4861 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4861.xml">
<!ENTITY RFC4944 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4944.xml">
<!ENTITY RFC4919 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4919.xml">
]>
<!-- IPR changed, Mar 5,2009 -->
<rfc ipr="trust200902" docName="draft-ietf-6lowpan-usecases-02">
<?rfc toc="yes"?>
<?rfc sortrefs="yes"?>
<?rfc symrefs="no"?>
<front>
<title abbrev="6LoWPAN Design and Applications">Design and Application Spaces for 6LoWPANs</title>
<author initials="E." surname="Kim" fullname="Eunsook Kim">
<organization>ETRI</organization>
<address>
<postal>
<street>161 Gajeong-dong</street>
<street>Yuseong-gu</street>
<city>Daejeon</city>
<code>305-700</code>
<country>Korea</country>
</postal>
<phone>+82-42-860-6124</phone>
<email>eunah.ietf@gmail.com</email>
</address>
</author>
<author initials="N.G." surname="Chevrollier" fullname="Nicolas G. Chevrollier">
<organization>TNO</organization>
<address>
<postal>
<street>Brassersplein 2</street>
<street>P.O. Box 5050</street>
<city>Delft</city>
<code>2600</code>
<country>The Netherlands</country>
</postal>
<phone>+31-15-285-7354</phone>
<email>nicolas.chevrollier@tno.nl</email>
</address>
</author>
<author initials="D." surname="Kaspar" fullname="Dominik Kaspar">
<organization>Simula Research Laboratory</organization>
<address>
<postal>
<street>Martin Linges v 17</street>
<city>Snaroya</city>
<code>1367</code>
<country>Norway</country>
</postal>
<phone>+47-4748-9307</phone>
<email>dokaspar.ietf@gmail.com</email>
</address>
</author>
<author initials="JP" surname="Vasseur" fullname="JP Vasseur">
<organization>Cisco Systems, Inc</organization>
<address>
<postal>
<street> 1414 Massachusetts Avenue </street>
<street></street>
<city>Boxborough</city>
<code>MA 01719</code>
<country>USA</country>
</postal>
<phone></phone>
<email>jpv@cisco.com</email>
</address>
</author>
<date year="2009" />
<area>General</area>
<workgroup>6LoWPAN Working Group</workgroup>
<keyword>Internet-Draft</keyword>
<abstract>
<t>
This document investigates potential application scenarios and use cases
for low-power wireless personal area networks (LoWPANs).
After describing the characteristics of a LoWPAN,
this document provides a list of use cases and market domains that may benefit
and motivate the work currently done in the 6LoWPAN WG.
A complete list of practical use cases is not the goal of this document.
<!-- The intention is to define a minimal set of LoWPAN
configurations to which any other scenario can be abstracted to. --> <!-- DK090305 -->
</t>
</abstract>
</front>
<!----------------------------------------------------------------------->
<!----------------------------------------------------------------------->
<!----------------------------------------------------------------------->
<middle>
<section anchor="intro" title="Introduction">
<t>
LoWPANs are inexpensive, low-performance, wireless communication networks, and are formed by devices complying with the IEEE
802.15.4 standard <xref target="refs.ieee802.15.4"/>. Their typical characteristics can be summarized as follows:
</t>
<list style="symbols">
<t>
Low power: depending on country regulations and used frequency band, the maximum transmit power levels can be up to
1000 mW <xref target="refs.ieee802.15.4"/>. However, typical wireless radios for LoWPANs are battery-operated and
consume between 10 mW and 20 mW <xref target="refs.bulusu"/>.
</t>
<t>
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 <xref target="refs.bulusu"/>.
</t>
<t>
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).
</t>
<t>
Small memory capacity: common RAM sizes for LoWPAN devices consist of a few kilobytes, such as 4 KB.
</t>
<t>
Limited processing capability: current LoWPAN nodes usually have 8-bit processors with clock rates around 10 MHz.
</t>
</list>
<t>
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.
</t>
<t>
A LoWPAN network can be seen as a network of small star-networks, each consisting of a single LoWPAN node connected to zero or more nodes,
or a network with mesh topology as shown in <xref target="fig.lowpan"/>.
It is noted that it is out of scope of this document to define how mesh topologies could be obtained and maintained.
<list style="hanging">
<t>
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. However, 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.
</t>
</list>
</t>
<figure title="Examples of LoWPAN topologies" anchor="fig.lowpan">
<preamble> </preamble>
<artwork>
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
</artwork>
<postamble></postamble>
</figure>
<t>
Communication to corresponding nodes outside of the LoWPAN is becoming increasingly important.
The intermediate LoWPAN nodes act as packet forwarders or 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
(named as PAN coordinator in the link layer) who is responsible for link-layer short address allocation.
However, this link-layer coordinator function is out of the scope of this document. The term coordinator
in this document does not refer to the PAN coordinator,
but is used for a node with special roles to coordinate neighboring nodes or relay traffic.
</t>
<t>
A LoWPAN can be configured as Mesh Under or Route Over. 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 or routing mechanisms at the link layer or in an
adapatation layer (see <xref target="fig.lowpan"/>). In a Route Over configuration,
the link-local scope is only one radio hop range and includes those nodes which are reachable over a single radio transmission.
Multihop transmission is achieved using IP routing (see <xref target="fig.lowpan"/>).
</t>
<figure title="Example of a small Mesh Under LoWPAN" anchor="fig.mlowpan">
<preamble></preamble>
<artwork>
h h
| | ER: LoWPAN Edge Router
ER --- m --- m --- h m: LoWPAN Node running Mesh Under
/ \ \ forwarding/routing
h h h
</artwork>
<postamble></postamble>
</figure>
<figure title="Example of a small Route Over LoWPAN" anchor="fig.rlowpan">
<preamble></preamble>
<artwork>
h h
| | ER: LoWPAN Edge Router
ER --- r --- r --- h r: LoWPAN Router
/ \ \ h: LoWPAN Host
h h h
</artwork>
<postamble></postamble>
</figure>
<t>
After defining common terminology in <xref target="terminology"/> and describing
the characteristics of LoWPANs in <xref target="designspace"/>, this document
provides a list of use cases and market domains that may benefit
and motivate the work currently done in the 6LoWPAN WG.
</t>
</section>
<!---------------------------------------------------------->
<!--------------------------------------------------------->
<!--------------------------------------------------------->
<vspace blankLines='1' />
<section anchor="terminology" title="Terminology">
<t>
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 <xref target="RFC2119"/>.
</t>
<t>
Readers are expected to be familiar with all the terms and concepts
that are discussed in <xref target="RFC4919">"IPv6 over Low-Power
Wireless Personal Area Networks (6LoWPANs): Overview, Assumptions,
Problem Statement, and Goals"</xref>, and
<xref target="RFC4944">" Transmission of IPv6 Packets over IEEE 802.15.4 Networks"</xref>.
</t>
<t>
This document defines additional terms:
<list style="hanging">
<t hangText="LoWPAN Coordinator Node"></t>
<t>
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 Coordinator Node does not need to coincide with a link-layer PAN coordinator
and there may be multiple instance in a LoWPAN.
</t>
<t hangText="LoWPAN Mesh Node"></t>
<t>
A LoWPAN node that forwards data between arbitrary source-destination pairs
in 6LoWPAN adaptation layer using link address (and thus only exist in Mesh Under LoWPANs).
A Mesh Node may also serve as a LoWPAN Host.
</t>
</list>
</t>
<t>
Additionally, in alignment with all other 6LoWPAN drafts, this document uses the same
terms and definitions as provided by the 6LoWPAN ND draft <xref target="refs.6lowpan.nd"/>:
<!-- ?rfc include='../6lowpan/6lowpan-terminology.xml'?-->
<list style="hanging">
<t hangText="LoWPAN Host"></t>
<t>A node that only sources or sinks IPv6
datagrams. Referred to as a host in this document. The term
node (see LoWPAN Node) is used when the differentiation between host and router
is not important.</t>
<t hangText="LoWPAN Edge Router"></t>
<t>An IPv6 router that interconnects the LoWPAN to another network. Referred to as an edge router in this document.
</t>
<t hangText="LoWPAN Router"></t>
<t>A node that forwards datagrams between arbitrary source-destination pairs using a single
6LoWPAN interface performing IP routing (and thus only exist in route over LoWPANs). A LoWPAN Router may also serve as a LoWPAN Host - both sourcing and sinking IPv6
datagrams. Referred to as a router in 6LoWPAN documents. All LoWPAN Routers
perform ND message relay on behalf of other nodes.
</t>
<t hangText="LoWPAN Node"></t>
<t>A node that composes a LoWPAN.
In mesh under, each intermediate node performs multi-hop forwarding at L2.
In route over, each intermediate node serves as a LoWPAN router performing IP routing.
</t>
<t hangText="Mesh Under"></t>
<t>A LoWPAN configuration where the link-local
scope is defined by the boundaries of the LoWPAN and
includes all nodes within. Forwarding and multihop routing functions are achieved at L2
between mesh nodes.
</t>
<t hangText="Route Over"></t>
<t>A LoWPAN configuration where the link-local
scope is defined by those nodes reachable over a single
radio transmission. Due to the time-varying
characteristics of wireless communication, the neighbor
set may change over time even when nodes maintain the
same physical locations. Multihop is achieved using IP routing.
</t>
<t hangText="Backbone Link"></t>
<t>This is an IPv6 link that interconnects two or more edge routers.
It is expected to be deployed as a high speed backbone in order to
federate a potentially large set of LoWPANs.
</t>
<t hangText="Extended LoWPAN"></t>
<t>This is the aggregation of multiple LoWPANs as defined in <xref target="RFC4919"/> interconnected
by a backbone link via Edge Routers and forming a single subnet.
</t>
<t hangText="LoWPAN Link"></t>
<t>
A low-power wireless link which is shared by a link-local scope in a LoWPAN.
In a LoWPAN, a link can be a very instable set of nodes, for
instance the set of nodes that can receive a packet that is broadcast
over the air in a route over LoWPAN, or the set of nodes currently reachable in an L2 mesh
in a mesh under LoWPAN. Such a set may vary from one packet to the next as the
nodes move or as the radio propagation conditions change.
</t>
<t hangText="LoWPAN Subnet"></t>
<t>
A subnet including a LoWPAN or an Extended LoWPAN, together with the backbone link
with the same subnet prefix and prefix length.
</t>
</list>
</t>
</section> <!-- end of terminology definitions -->
<!------------------------------------------------------------->
<!------------------------------------------------------------>
<!-------------------------------------------------------------->
<vspace blankLines='1' />
<section anchor="designspace" title="Design Space">
<t>
Inspired by <xref target="refs.roemer"/>, 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 LoWPAN (e.g., low-power, short range, low-bit rate) as described
in <xref target="RFC4919"/>. The possible dimensions for scenario categorization used in this document
are described as follows:
</t>
<list style="symbols">
<t>
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.
</t>
<t>
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).
</t>
<t>
Power Source: The power source of nodes, 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 is mains-powered.
</t>
<t>
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).
</t>
<t>
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 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 when referring to the routing categorization.
</t>
<t>
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).
</t>
<t>
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.
</t>
<t>
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).
</t>
<t>
Quality of Service (QoS): for mission-critical applications, support of QoS is mandatory in resource-constrained LoWPANs.
</t>
</list>
</section>
<!-------------------------------------------------------------------->
<!------------------------------------------------------------------->
<!------------------------------------------------------------------->
<vspace blankLines='1' />
<section anchor="scenarios" title="Application Scenarios">
<t>
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 document.
<!-- The intention is to define a minimal set of LoWPAN
configurations to which any other scenario can be abstracted to. --> <!-- DK090305 -->
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).
</t>
<!------------------------------------------------------------------->
<!------------------------------------------------------------------->
<section title="Industrial Monitoring">
<t>
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.
Wireless sensor networks can be inexpensively installed and provide more frequent and more reliable data.
The deployment of wireless sensor networks can reduce equipment downtime and eliminate
manual equipment monitoring that is costly to be carried out.
Additionally, data analysis functionality can be placed into the network,
eliminating the need for manual data transfer and analysis.
</t>
<t>
Industrial monitoring can be largely split into the following application fields:
<list style="symbols">
<t>
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.
<vspace blankLines='1' />
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.
<vspace blankLines='1' />
Greater access to process parameters gives engineers better visibility and ultimately better decision making
power. Various 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.
<vspace blankLines='1' />
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.
</t>
<t>
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 <xref target="scenario1"/>).
</t>
<t>
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.
<vspace blankLines='1' />
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.
<vspace blankLines='1' />
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
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.
<vspace blankLines='1' />
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.
</t>
<t>
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.
</t>
</list>
</t>
<!------------------------------------------------------------------->
<section title="A Use Case and its Requirements">
<t>
Example: Storage Monitoring (Hospital Storage Rooms)
</t>
<t>
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.
</t>
<t>
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.
</t>
<t>
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 routing tables are not changed in the storage room unless node failure occurs.
</t>
<t>
This type of application works based on both periodic and event-driven notifications.
Periodic data is used for monitoring the right 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.
</t>
<t>
Dominant parameters in industrial monitoring scenarios:
<list style='symbols'>
<t>Deployment: pre-planned, manually attached</t>
<t>Mobility: no (except for the asset tracking case)</t>
<t>Network Size: medium to large size, high node density</t>
<t>Power Source: all battery-operated</t>
<t>Security Level: business-critical. Secure and reliable transmission must be guaranteed. An extra key mechanism can be used.</t>
<t>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. </t>
<t>Connectivity: always on for crucial processes, otherwise intermittent</t>
<t>QoS: important for time-critical event-driven data</t>
<t>Traffic Pattern: P2P (actuator control), MP2P (data collection)</t>
<t>Other Issues: Sensor network management</t>
</list>
</t>
</section>
<!------------------------------------------------------------------->
<section title="6LoWPAN Applicability">
<t>
The network configuration of the above use-case can differ substantially
by system design. As illustrated in <xref target="fig.storage"/>,
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 LoWPAN Coordinator Nodes (CNs) play role in aggregation of the
sensed data at each storage room and transmit the data.
It is noted that the LoWPAN CN is a logical entity so that it can
be implemented together with an LoWPAN Edge Router
or a LoWPAN Node. In case data from an individual node is important,
such as urgent event-driven data, it will not be accumulated
(and further delayed) by the LoWPAN CN but immediately relayed.
In Mesh under, link-layer addresses in mesh-header defined in
RFC 4944<xref target="RFC4944"/> are used for transmission,
and in Route Over, IP forwarding is used.
</t>
<t>
Based on the layout and size of the storage room, the LoWPAN can be configured
in mesh topology as shown in <xref target="fig.Ext-storage"/>.
More than one LoWPAN CNs can be installed in a storage room, and
CNs collect data and become relay points to send it to the LoWPAN ERs.
LoWPAN Nodes need to build a multi-hop connection to reach the CNs and ER by ether Mesh Under or Route Over.
In Mesh Under, more than one CNs can be installed in the LoWPAN
and the nodes play role in transmission multi-point traffic (multicast) to unicast method,
not only role in data collection.
In Route Over, LoWPAN Routers will handle multicast traffic to their LoWPAN Link.
</t>
<t>
Each LoWPAN node configures its link-local address and may get
a prefix from its default router by an 6LoWPAN ND procedure (ND optimization is
on-going work in the WG <xref target="refs.6lowpan.nd"/>).
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 <xref target="RFC4944"/>.
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.
</t>
<t>
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.
</t>
<t>
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.
</t>
<t>
When a 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 new LoWPAN. 6LoWPAN ND<xref target="refs.6lowpan.nd"/> will support this procedure.
In case that it is moved by an ambulance, it will be connected to an edge router in vehicle.
</t>
<figure title="Storage rooms with simple star topology" anchor="fig.storage">
<preamble></preamble>
<artwork><![CDATA[
ER
| ER: LoWPAN Edge Router
CN----------CN----------CN CN: Coordinator Node
/ | \ / | \ / | \ n: LoWPAN Node
n n n n n n n n n
]]></artwork>
<postamble></postamble>
</figure>
<figure title="Storage rooms with mesh topology" anchor="fig.Ext-storage">
<preamble></preamble>
<artwork><![CDATA[
GW
+------------+-----------+ GW: Gateway
| | | ER: LoWPAN Edge Router
ER ER ER(CN) CN: Coordinator Node
| | | (Data Aggregator)
n -- CN -- n CN -- n n n: LoWPAN Node
/ | \ | /|\
n CN n n -- n --CN n n n
/ | \ /|\
n n n -- n n n n
]]></artwork>
<postamble></postamble>
</figure>
</section>
</section>
<!------------------------------------------------------------------->
<!------------------------------------------------------------------->
<vspace blankLines='1' />
<section anchor="scenario1" title="Structural Monitoring">
<t>
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.
</t>
<!------------------------------------------------------------------->
<section title="A Use Case and its Requirements">
<t>
Example: Bridge Safety Monitoring
</t>
<t>
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.
</t>
<t>
The network configuration and routing tables are changed only in case of node failure.
On the top part of each pillar, an "infrastructure" sink node is placed to collect the sensed data.
The sink nodes of each pillar become data gathering point of the sensor nodes at the pillar.
</t>
<t>
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 <xref target="fig.star"/>),
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.
</t>
<t>
Dominant parameters in structural monitoring applications:
<list style='symbols'>
<t>Deployment: static, organized, pre-planned</t>
<t>Mobility: none</t>
<t>Network Size: small (dozens of nodes) to large </t>
<t>Power Source: mains-powered nodes are mixed with battery powered
(mains-power nodes will be used for coordinators or relays)</t>
<t>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.</t>
<t>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.</t>
<t>Connectivity: always connected or intermittent by sleeping mode scheduling.</t>
<t>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.</t>
<t>Traffic Pattern: MP2P (data collection), P2P (localized querying)</t>
<t>Other Issues: accurate sensing and reliable transmission are important.
In addition, sensor status reports may be needed to maintain a reliable monitoring system.</t>
</list>
</t>
</section>
<!------------------------------------------------------------------->
<section title="6LoWPAN Applicability">
<t>
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.
</t>
<t>
Each LoWPAN node configures its link-local address and may get a prefix
from its default router by an 6LoWPAN ND procedure <xref target="refs.6lowpan.nd"/>).
Each pillar may have one LoWPAN Coordinator Node(CN) 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 LoWPAN CN 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 <xref target="refs.6lowpan.IPHC"/>.
Globally unique addresses MAY be allocated depending on the purpose of the system.
</t>
<t>
The LoWPAN Nodes are installed on the place after manual optimization of their location.
Static data paths to the data gathering point can be set <!-- by an installer--> in the commissioning phase.
If the network does not use a Route Over mechanism, the 6LoWPAN mesh-header
described in RFC 4944 <xref target="RFC4944"/> is used for static data forwarding.
In Mesh Under, a IPv6 link is shared by all nodes in the LoWPAN,
but for Route Over, an IPv6 link is only shared by nodes that lie in radio transmission range.
</t>
<t>
A logical entity of data gathering can be implemented in each LoWPAN CN.
Communication schedules must be set up between leaf nodes and their CN 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.
</t>
<t>
Due to the safety-critical data of the structure,
authentication and security are important issues here. Only authenticated users
should be allowed to access the data. Additional security should be provided at the LoWPAN ER
for restricting the access from outside of the LoWPAN. The LoWPAN ER may take charge of
authentication of LoWPAN nodes. Reliable and secure data transmission SHOULD be guaranteed.
</t>
<figure title="A LoWPAN with a simple star topology." anchor="fig.star">
<preamble></preamble>
<artwork><![CDATA[
n n n
\ | / ER: LoWPAN Edge Router
n ---CN --- ER --- n CN: LoWPAN Coordinator Node
/ | \ and Data Aggregator
n n n n: LoWPAN Node
]]></artwork>
<postamble></postamble>
</figure>
<figure title="A LoWPAN with a mesh topology" anchor="fig.mesh">
<preamble></preamble>
<artwork><![CDATA[
ER ---CN ------CN -------CN ER: Edge Router
/| / | \ | C: LoWPAN Coordinator Node
h r(m) h r(m) h r(m)-r(m)-h r: LoWPAN Router (Route Over)
/\ | | m: Mesh Node (Mesh Under)
h h h r(m) -- h h: LoWPAN Host
]]></artwork>
<postamble></postamble>
</figure>
</section>
</section>
<!------------------------------------------------------------------->
<!--------------------------------------------------------------------->
<vspace blankLines='1' />
<section title="Healthcare">
<t>
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.
</t>
<t>
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 <xref target="refs.hartog"/> using the concept of Personal Networks.
</t>
<!------------------------------------------------------->
<section title="A Use Case and its Requirements">
<t>
Example: Healthcare at Home by Tele-Assistance
</t>
<t>
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 Edge Router 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.
</t>
<t>
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.
</t>
<t>
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.
</t>
<t>
Privacy also becomes an issue in this case, as the sensing data is very personal.
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.
</t>
<t>
Dominant parameters in healthcare applications:
<list style='symbols'>
<t>Deployment: pre-planned</t>
<t>Mobility: moderate (patient's mobility)</t>
<t>Network Size: small, high node density </t>
<t>Power Source: hybrid</t>
<t>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</t>
<t>Routing: multihop for homecare devices, star topology on patients body.
Multipath interference due to walls and obstacles at home must be considered.</t>
<t>Connectivity: always on</t>
<t>QoS: high level of support (life and death implication), role-based </t>
<t>Traffic Pattern: MP2P/P2MP (data collection), P2P (local diagnostic)</t>
<t>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.</t>
</list>
</t>
</section>
<!------------------------------------------------------->
<section title="6LoWPAN Applicability">
<t>
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 <xref target="RFC4944"/>. 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 <xref target="refs.6lowpan.nd"/> and new header format in
<xref target="refs.6lowpan.IPHC"/>. An example topology is provided in <xref target="fig.healthcare"/>.
</t>
<t>
Multi-hop communication can be achieved by either Mesh Under or Route Over routing
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 <xref target="refs.6lowpan.nd"/> 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 CNs 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.
</t>
<t>
The patient’s body network can be simply configured as a star topology with a LoWPAN Coordinator Node(CN) 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.
</t>
<t>
It should be maintained the sensed information with the identification of the patient
wherever 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.
</t>
<t>
The connection with the LoWPAN Edge Router at home and the ER at Hospital must provide reliable and secure transmission,
as the data is privacy-critical. To achieve this, additional policy for security is recommended between the two LoWPAN.
</t>
<figure title="A mobile healthcare scenario." anchor="fig.healthcare">
<preamble></preamble>
<artwork><![CDATA[
n --- n I: Internet
| | ER: Edge Router
ER --- I --- ER --- n --- n --- CN CN: Coordinator Node
/|\ | | /|\ n: LoWPAN Node
.. . .. n --- n h h h h: LoWPAN Host
(hospital) (home system) (patient)
]]></artwork>
<postamble></postamble>
</figure>
</section>
<!------------------------------------------------------->
</section>
<!------------------------------------------------------->
<!------------------------------------------------------->
<vspace blankLines='1' />
<section title="Connected Home">
<t>
The "Connected" Home or "Smart" home is with no doubt an area where LoWPANs
can be used to support an increasing number of services:
</t>
<t>
<list style='symbols'>
<t>Home safety/security</t>
<t>Home Automation and Control</t>
<t>Healthcare (see above section)</t>
<t>Smart appliances and home entertainment systems</t>
</list>
</t>
<t>
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.
</t>
<!------------------------------------------------------->
<section title="A Use Case and its Requirements">
<t>
Example: Home Automation
</t>
<t>
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 security (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.
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.
</t>
<t>
The home automation and control system LoWPAN offers a wide range of services: local
or remote access from the Internet (via a secured edge router) to monitor the home (temperature,
humidity, activation of remote video surveillance, status of the doors (locked or open), ...) but also for
home control (activate the air conditioning/heating, door locks, sprinkler systems, ...). Fairly
sophisticated systems can also optimize the level of energy consumption thanks to a wide range
of input from various sensors connected to the LoWPAN: light sensors, presence detection,
temperature, ... in order to control electric window shades, chillers, air flow control, air conditioning
and heating with the objective to optimize energy consumption.
</t>
<t>
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). 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).
</t>
<t>
Dominant parameters for home automation applications:
<list style='symbols'>
<t>Deployment: multi-hop topologies</t>
<t>Mobility: small degree of mobility</t>
<t>Network Size: medium number of nodes, potentially high density</t>
<t>Power Source: mix of battery and AC powered devices</t>
<t>Security Level: authentication and encryption required</t>
<t>Routing: no requirement for multi-topology or QoS routing</t>
<t>Connectivity: intermittent (usage-dependent sleep modes)</t>
<t>QoS: support of limited QoS (small number of Class of Service)</t>
<t>Traffic Pattern: P2P (inter-device), P2MP and MP2P (polling)</t>
</list>
</t>
</section>
<!------------------------------------------------------->
<section title="6LoWPAN Applicability">
<t>
(TBD)
</t>
</section>
<!------------------------------------------------------->
</section>
<!------------------------------------------------------->
<!------------------------------------------------------->
<vspace blankLines='1' />
<section title="Vehicle Telematics">
<t>
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.
</t>
<!------------------------------------------------------->
<section title="A Use Case and its Requirements">
<t>
Example: Telematics
</t>
<t>
As shown in <xref target="fig.telematics"/>, 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. Sinks placed at the road side are mains-powered, LoWPAN Nodes in the roads
run on battery. Power savings schemes might intermittently disconnect the LoWPAN Nodes. A rough estimate
of 4 nodes per square meter is needed. Other applications may involve car-to-car communication for increased road safety.
</t>
<t>
Dominant parameters in vehicle telematics applications:
<list style='symbols'>
<t>Deployment: scattered, pre-planned</t>
<t>Mobility: none (road infrastructure), high(vehicle)</t>
<t>Network Size: large (road infrastructure), small (vehicle)</t>
<t>Power Source: mostly battery powered</t>
<t>Security Level: low</t>
<t>Routing: multi-hop, especially ad-hoc</t>
<t>Connectivity: intermittent</t>
<t>QoS: support of limited QoS</t>
<t>Traffic Pattern: mostly Point-to-Point (P2P), Point-to-Multi-Point (P2MP)</t>
</list>
</t>
</section>
<!------------------------------------------------------->
<section title="6LoWPAN Applicability">
<t>
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 LoWPAN Coordinator
Nodes (CNs) as data sinks for a number of LoWPAN
Nodes inserted in the tarmac of the road.
</t>
<t>
<!--Except LoWPAN ERs, LoWPAN Nodes generally can operate with link-local IPv6 addresses
as no direct access from outside of the LoWPAN will make to the LoWPAN Nodes. -->
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. <!-- DK090306 -->
Based on the purpose of the service, globally unique IPv6 address can be allocated during the network
setup procedure described in RFC 4944<xref target="RFC4944"/>
and 6LoWPAN ND <xref target="refs.6lowpan.nd"/>.
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 <xref="refs.6lowpan.nd"/>.
</t>
<t>
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-header
described in RFC 4944 <xref target="RFC4944"/> is used for static data forwarding.
Routing tables are not changed unless a node failure occurs.
</t>
<figure title="Multi-hop LoWPAN combined with mobile star LoWPAN." anchor="fig.telematics">
<preamble></preamble>
<artwork><![CDATA[
+----+
| 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)
--------------------------------------
]]></artwork>
<postamble></postamble>
</figure>
</section>
<!------------------------------------------------------->
</section>
<!------------------------------------------------------->
<!------------------------------------------------------->
<vspace blankLines='1' />
<section anchor="scenario2" title="Agricultural Monitoring">
<t>
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.
</t>
<!------------------------------------------------------------>
<section title="A Use Case and its Requirements">
<t>
Example: Automated Vineyard
</t>
<t>
In a vineyard with medium to large geographical size, a number of 50 to 100 LoWPAN Coordinator 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 LoWPAN CNs
in local wireless star topologies, periodically reporting measurements to the associated
LoWPAN CNs. 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 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 sinks to the main gateway.
</t>
<t>
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.
</t>
<t>
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.
</t>
<t>
Dominant parameters in agricultural monitoring:
<list style='symbols'>
<t>
Deployment: pre-planned
<vspace blankLines='1' />
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.
</t>
<t>Mobility: all static</t>
<t>Network Size: medium to large, low to medium density</t>
<t>Power Source: all nodes are battery-powered, except the sink</t>
<t>Security Level: business-critical. Light-weight security or a global key management can be used depending on the business purpose.</t>
<t>Routing: mesh topology with local star connections. Routing table is merely changed after configuration.
Node failure or indoor obstacles will cause the changes.</t>
<t>Connectivity: intermittent (many sleeping nodes)</t>
<t>QoS: not critical</t>
<t>Traffic Pattern: Mainly MP2P/P2MP. P2P for Gateway communication or actuator triggering.</t>
<t>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).</t>
</list>
</t>
</section>
<!------------------------------------------------------------>
<section title="6LoWPAN Applicability">
<t>
The network configuration in this use case might, in the most simple case, look like
illustrated in <xref target="fig.vineyard"/>. This static scenario consists of one or more fixed edge
routers 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 Edge Routers are strategically
located at the border of vineyard parcels, acting as data sinks. A number LoWPAN Coordinator Nodes are
placed along a row of plants with individual LoWPAN Hosts spread around them.
</t>
<t>
While the LoWPAN ERs implement the IPv6 Neighbor Discovery protocol (RFC 4861), the LoWPAN
Nodes need a more energy-efficient mechanism. They instead follow LoWPAN
Neighbor Discovery as described in <xref target="refs.6lowpan.nd"/>, 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.
</t>
<t>
The intermediate nodes must implement a multi-hop routing protocol (Mesh Under or Route Over) and they are
responsible for forwarding measurement data of the LoWPAN hosts towards the LoWPAN ERs. In this simplest case,
the LoWPAN Routers (not edge routers) or Mesh Nodes can build static routing (or forwarding) paths, and all end-nodes can
be placed in one radio hop distance from its forwarder. Packets can be forwarded to each router or mesh node and relayed
to the LoWPAN ER by link-layer forwarding using the 6LoWPAN mesh-header or Route Over routing.
</t>
<t>
LoWPAN nodes may send event-driven notifications when readings exceed certain thresholds, such as low soil
humidity; which may automatically trigger a water sprinkler in the local environment. For increased energy
efficiency, all LoWPAN Nodes are in periodic sleep state. However, the LoWPAN CNs 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.
</t>
<t>
Also, the result of data collection may activate actuators. Context-awareness, node identification and
data collection on the application level are necessary.
</t>
<figure title="An aligned multi-hop LoWPAN." anchor="fig.vineyard">
<preamble></preamble>
<artwork><![CDATA[
+----+
| GW | GW: Gateway
+----+ ER: LoWPAN Edge Router
| h h h h h h h h h CN: LoWPAN Coordinator Node
| \|/ \|/ \|/ r: Route Over (LoWPAN Router)
ER----CN(r,m)--CN(r,m)--CN(r,m) m: Mesh Under(forwarding node)
| /|\ /|\ /|\ h: LoWPAN Host
| h h h h h h h h h
ER
... ]]></artwork>
<postamble></postamble>
</figure>
</section>
<!------------------------------------------------------------>
</section>
<!------------------------------------------------------------>
<!------------------------------------------------------------>
<!------------------------------------------------------------>
</section> <!-- end of main section "Application Scenarios" -->
<!------------------------------------------------------------>
<!------------------------------------------------------------>
<!------------------------------------------------------------>
<vspace blankLines='1' />
<section title="Security Considerations">
<t>
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.
</t>
</section>
<!------------------------------------------------------------>
<!------------------------------------------------------------>
<!------------------------------------------------------------>
<vspace blankLines='1' />
<section title="Acknowledgements">
<t>
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.
</t>
</section>
</middle>
<!------------------------------------------------------------>
<!------------------------------------------------------------>
<!------------------------------------------------------------>
<back>
<references title='Normative References'>&RFC2119;&RFC4861;&RFC4919;&RFC4944;
<reference anchor="refs.ieee802.15.4">
<front>
<title>IEEE Std. 802.15.4-2006 (as amended)</title>
<author><organization>IEEE Computer Society</organization></author>
<date month="" year="2007"/>
</front>
</reference>
</references>
<references title='Informative References'>
<reference anchor="refs.bulusu">
<front>
<title>Wireless Sensor Networks</title>
<author initials="N." surname="Bulusu" fullname="Nirupama Bulusu"></author>
<author initials="S." surname="Jha" fullname="Sanjay Jha"></author>
<date month="July" year="2005"/>
</front>
</reference>
<reference anchor="refs.roemer">
<front>
<title>The Design Space of Wireless Sensor Networks</title>
<author initials="K." surname="Roemer" fullname="Kay Roemer"></author>
<author initials="F." surname="Mattern" fullname="Friedemann Mattern"></author>
<date month="December" year="2004"/>
</front>
</reference>
<reference anchor="refs.hartog">
<front>
<title>On the Potential of Personal Networks for Hospitals</title>
<author initials="F." surname="den Hartog" fullname="Frank den Hartog"></author>
<author initials="J." surname="Schmidt" fullname="J. Schmidt"></author>
<author initials="A." surname="de Vries" fullname="Arnoud de Vries"></author>
<date month="May" year="2006"/>
</front>
</reference>
<reference anchor="refs.6lowpan.nd">
<front>
<title>Neighbor Discovery for 6LoWPAN, draft-shelby-6lowpan-nd-00 (work in progress)</title>
<author initials="Z." surname="Shelby" fullname="Zach Shelby"></author>
<author initials="P." surname="Thubert" fullname="Pascal Thubert"></author>
<author initials="C. W." surname="Hui" fullname="Jonathan W. Hui"></author>
<author initials="S." surname="Chakrabarti" fullname="Samita Chakrabarti"></author>
<author initials="E." surname="Nordmark" fullname="Erik Nordmark"></author>
<date month="October" year="2008"/>
</front>
</reference>
<reference anchor="refs.6lowpan.IPHC">
<front>
<title>Compression Format for IPv6 Datagrams in 6LoWPAN Networks, draft-ietf-6lowpan-hc-04 (work in progress)</title>
<author initials="J." surname="Hui" fullname=""></author>
<author initials="P." surname="Thubert" fullname=""></author>
<date month="December" year="2008"/>
</front>
</reference>
</references>
<!-- The old ND-reference we used (previous to draft-ietf-6lowpan-usecases-01)
<reference anchor="refs.6lowpan.nd">
<front>
<title>LoWPAN Neighbor Discovery Extensions, draft-chakrabarti-6lowpan-ipv6-nd-04 (work in progress)</title>
<author initials="S." surname="Chakrabarti" fullname=""></author>
<author initials="E." surname="Nordmark" fullname=""></author>
<date month="November" year="2007"/>
</front>
</reference>
</references>
-->
</back>
</rfc>| PAFTECH AB 2003-2026 | 2026-04-24 01:20:49 |