Internet DRAFT - draft-dinh-icn-sensor-scenarios
draft-dinh-icn-sensor-scenarios
ICNRG N.T. Dinh
Internet Draft Y. Kim
Intended status: Standards Track Truong-xuan Do
Expires: Dec 30, 2014 Hyunsik Yang
Soongsil University
June 30, 2014
ICN Wireless Sensor and Actor Network BaseLine Scenarios
draft-dinh-icn-sensor-scenarios-03
Abstract
This document presents scenarios for information centric wireless
sensor and actor networks. The scenarios selected for inclusion in
this first draft aim to exercise a variety of aspects in wireless
sensor and actor network that an ICN solution could address.
Status of this Memo
This Internet-Draft is submitted 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 Dec 30, 2014.
Copyright Notice
Copyright (c) 2013 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
(http://trustee.ietf.org/license-info) in effect on the date of
Dinh & Kim Expires Dec 30, 2014 [Page 1]
Internet-Draft ICN Sensor and Actor Network Scenarios June 2014
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with
respect to this document. Code Components extracted from this
document must include Simplified BSD License text as described in
Section 4.e of the Trust Legal Provisions and are provided without
warranty as described in the Simplified BSD License.
Redistribution and use in source and binary forms, with or without
modification, is permitted pursuant to, and subject to the license
terms contained in, the Simplified BSD License set forth in Section
4.c of the IETF Trust's Legal Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info).
Table of Contents
1. Introduction...................................................2
2. Problem Statement..............................................3
3. Naming Scheme..................................................3
4. In-network Auto-configuration..................................6
5. Distributed Information Sharing Model..........................7
6. Distributed Network-level Information Filter...................7
7. Information centric routing and Aggregation....................7
8. Semantic Coordination and Collaboration........................8
9. In-network Caching.............................................9
10. Security Considerations......................................10
11. IANA Considerations..........................................10
12. Acknowledgements.............................................10
13. References...................................................10
13.1. Normative References.......................................10
13.2.Informative References......................................10
1. Introduction
Wireless sensor and actor networks (WSANs) consist of resource-
constrained nodes which operate in low power and lossy network
environment. Therefore, resource optimization is a very important
factor in design of WSANs' operations. Current TCP/IP model does not
fit well in this environment, so a need of 6LoWPAN is highlighted in
[RFC4919]. This draft exploits ICN approach in WSANs (ICWSANs) and
illustrates the obtained benefits.
For example, Dinh and Kim [ICWSAN] consider a functional oriented
naming scheme for information objects (IO)/entities and illustrate
the ICN benefits through scenarios in this category, including an
in-network auto-configuration, a distributed virtual information
Dinh & Kim Expires Dec 30, 2014 [Page 2]
Internet-Draft ICN Sensor and Actor Network Scenarios June 2014
sharing model, a content-based distributed information filter, a
content-based routing and data aggregation, and a semantic
cooperative distributed approach for WSANs.
2. Problem Statement
The usage models in WSANs are mostly information-based. The
information consumers exploited the network in information centric
way. Particularly, they are only interested in the fact that they
can get what they want. In contrast, the current IP approach is
address-centric, indicating where information has to be taken.
Moreover, the IP model requires an end-to-end connection between
source and destination, which may be not available all the time in
WSAN. Therefore, there are inconsistency between the information
usage model and the IP addressing style.
In IP paradigm, the network forwards bits equally and
indistinguishably. In the other hand, the bits should be exactly
flow from a source to a destination which is normally occurs in real
time. However, in WSAN, the network connectivity may be not always
available for end-to-end communication. Moreover, sensors may sleep
to reduce the energy consumption. The energy consumption is a
critical issue in WSAN where data aggregation is a good method to
reduce number of transmission, thus saving energy. Data aggregation
may require a deeper packet inspection, directly contradicting the
current model where the bits are indistinguishable. It remains a
challenge to recognize the information in the network layer in order
to achieve a better network performance. Therefore, information
centric network approach is potentially fit into the WSANs.
3. Naming Scheme
The naming scheme is a very important part. In comparison to the
Internet, a WSAN node produces and needs a few types of information.
For example, a temperature sensor may produce only temperature
sensing data or notifications about an over-threshold temperature
event. Types of information have a closely relationship with their
producers' functions (e.g. temperature data or temperature event in
a relationship with the temperature sensor). In this way, naming
schemes applied for each piece of information in Internet-ICN
approach [CCN] and other ICN proposals are not efficient in WSANs.
The basic idea of ICN is to change focus from network hosts to the
information objects (IOs) themselves while ICWSANs move focus from
separately device IDs to the composed denotation between the
information objects (IOs) and smart objects (e.g. sensors). The
reason is that there is a closed relationship between the produced
Dinh & Kim Expires Dec 30, 2014 [Page 3]
Internet-Draft ICN Sensor and Actor Network Scenarios June 2014
information objects and the functionality of the producers. For
example, the temperature sensor should produce the temperature
sensing data. Smart objects are categorized based on its
functionality (e.g. temperature sensor, humidity sensor, light
sensor). These category names are used to represent the type of
sensors and the type of sensing data produced by the corresponding
types of sensor. The category prefix is created by selecting brief
representative symbols for each category name (e.g. temperature may
be presented in a reduced form as "temp"). The brief form of the
category prefix helps reduce the packet overhead. The category
prefix is used to name smart objects and information objects
produced by them. Each smart object's name or information objects'
name will start with a corresponding category prefix name. The
sensor data are transformed into IOs with the name corresponding to
their producers' name. By this way, the smart object type and the
information object type could be recognized by the network, thus
easier for discovery and interaction. Based on the information based
name, IOs could be recognized and reused for multiple requests from
multiple consumers without a must to reach to the producers. The IOs
could be retrieved from any content holder or cache. This thus
reflects a separation in time between source and destination which
promises an efficient approach to improve the network serving
performance of the sleep/wake-up model for energy saving in WSAN
(i.e. while a sensor sleeps, its sensing data could be retrieved
elsewhere closer the consumer).
Particularly, a functional-oriented naming scheme is proposed in
ICWSANs. A name in ICWSANs includes an information category prefix
and information ID. The first part expresses a real-world functional
category name of a type of sensor or actor. The naming scheme is
proposed for both information naming and node's naming, which are
associated in the relationship with node's function. For example, a
temperature sensor could be named as tempSen:xxx and its temperature
information could be named as temp:xxx, or a temperature sink node
could also be named as tempSink:xxx ("temp" is a category prefix for
multiple types of sensor, actor, and sink nodes which are related to
the temperature category). By this way, the scalability issue of the
naming scheme in ICWSANs may not be as critical as other Internet's
ICN proposals. In the other hand, by exploiting the functional
category-certifying, ICWSANs could improve the network performance
and reduce communication overhead in WSANs, especially in group
communication. The sensing data is transformed into an IO with the
name corresponding to its producer and stored in the producer or
published to other information holders.
In the sensing data query model, consumers are normally not
interested an individual sensing data, but the sensing data in a
Dinh & Kim Expires Dec 30, 2014 [Page 4]
Internet-Draft ICN Sensor and Actor Network Scenarios June 2014
location. Thus, the smart objects could not separate from their
location. In other words, the value of IOs depends on their location.
Therefore, spatial information is also a key element of the IOs/SOs.
An example of ID generation related to the spatial information is
given below. The location mentioned here does not mean the IP
address, but the area of interest (AoI). Consumers may not be
interested in all IOs or SOs in an AoI, but Entities of Interest
(EoI) or Information Object of Interest (IoI) in an AoI. The design
of ICWSAN is to support consumers to express their interests on
EoI/IoI on an AoI and an efficient approach for serving such
interests.
In ICWSAN, the latter part of the name expresses the detail
information (e.g. ID, security code) which makes the name persistent
and unique. An example of ID generation based on the object's
ranking is given. The rank of a node in ICWSANs expresses the
position relative to other nodes. Nodes form a ranked tree topology
which is similar to the multibit-trie [MULTIBIT-TRIE] using in the
router table indexing. The purpose of the ranking-based ID is to
make routing become easier and more efficient by minimizing the
communication for route discovery. The object function (OF) is used
to generate the ranking of a node follow a rule as presented below.
Ranking of ith child node = ranking parent + i/15*'0' + HEX [I (mod)
15].
Maximum number of children max_child for a node means that each node
could receive maximum max_child nodes. Each node allocates and
manages the ordered slots for children nodes. A node allocates an
ordered slot for only one child node at a time. The child node keeps
its ordered slot if there is no change in the network. Because the
parent ID is assumed to be unique and each child node receives a
unique ordered slot, thus the generated ID is also unique. The ID
generation is executed from the sink downward to children nodes. The
sink node initiates a unique ID automatically or is assigned by some
mechanism to guarantee that its ID is unique among sink nodes in the
network. It configures the rank as its ID to set up the full name
for the sink node. The sink node becomes a ranked node. When a node
turns on, it sends a ranking request (RRQ) message to its one hop
neighbors. As far as the network startups, each node, when turns on
the first time without sensing any ranked neighbor, puts itself in
listening mode for a random backoff periods and then request again.
On the contrary, ranked neighbor nodes check if they have any
available slot for a child node (its children number is smaller than
max_child), it then returns a ranking reply (RRP) message contain
its full name and allocate a valid ordered slot number (no child
node takes this number) to the requester. The requester may receive
Dinh & Kim Expires Dec 30, 2014 [Page 5]
Internet-Draft ICN Sensor and Actor Network Scenarios June 2014
multiple RRP from different ranked nodes. It then selects a node
with the shortest ID-length to be its parent. If several nodes have
the same shortest ID-length value, it selects the nearest node to be
its parent. The requester then runs OF with two parameters (parent
ID, ordered slot) to generate the rank. The requester then sets its
ID with the calculated rank and becomes a ranked node. After a
waiting time, it then sends a neighbour advertisement(NA) message to
its one hop neighbors containing its information and parent ID. When
the parent node receives the NA message, it stores the child full
name with the corresponding ordered slot for management. Other
neighbours update its neighbour table with the new ranked neighbour
node with upstream or downstream category. The process is executed
continuously until all nodes are ranked and participate to the
ranked tree network.
The value of IOs also has the temporal constraint which limits the
value of IOs in a period of time. This is a specific characteristic
of IOs, not SOs. In ICN, metadata is included to denote such
information. The ICN metadata may denote the ownership, various
timestamps, and usage or access policy constraints. These types of
information should be tied to IOs instead of nodes as in the
traditional host centric network. Therefore, the IOs could be
replicated reuse for multiple applications, thus saving a number of
requests to sensor nodes. An efficient storing method for metadata
is still an opened research topic. In WSANs, a wide range of
alternative security levels (fully public, confidentiality by
private name resolution system, or cryptographic) could be accepted
depending on specific applications. A simple method is required for
constrained nodes.
Multiple potentialities of ICWSAN are discussed below.
4. In-network Auto-configuration
In low power and lossy environment as WSANs, the WSAN system
dynamically adapts to change in network topology due to node
failures, environmental condition change, and new deployed nodes.
Therefore, auto-configuration design is important for such a large
scale network with limited resource nodes. Furthermore, the
connectivity from a node to the sink node could not guarantee all
the time because of sleep/wakeup intermediate node and low link
quality. In ICWSAN, an in-network auto-configuration is proposed to
reduce the configuration overhead. In particularly, when a new node
is deployed, configuration information could be retrieved from the
previously deployed nodes (with cached configuration information)
without a need to send a configuration information request to sink
node, or manually by user (e.g. a new temperature deployed node may
Dinh & Kim Expires Dec 30, 2014 [Page 6]
Internet-Draft ICN Sensor and Actor Network Scenarios June 2014
retrieve configuration information from the nearest temperature node
which is deployed previously). The new node then processes the
configuration information for all the information needed to fully
join to the existing network and start its operation. The in-network
auto-configuration requires only one alive neighbour node is enough
to execute auto-configuration for the newly deployed node while
optimizing number of forwarding requests to minimize the
configuration overhead by sharing information.
5. Distributed Information Sharing Model
The information sharing model also could execute in a distributed
virtual way; particularly, in a heterogeneous WSANs with multiple
types of sensors and actors, multiple separately virtual groups
could be created semantically to support inter-operate among nodes
without a requirement of a complex group's member addresses
management or centralized control(e.g. temperature sensors with the
same name prefix "temp" in an area could form a virtual group while
fired actors with the name prefix "fire-xxx" also form as another
group). The sharing rules could be determined based on the category
prefix of the information. The distributed virtual model is very
useful in case of configuration, data collection, and inter-
operation; for example, an interest request could be sent to collect
only temperature sensing information (only ) or a configuration
message is sent to only humidity sensors (only humidity sensors
should process this message).
6. Distributed Network-level Information Filter
An information-based distributed information filter approach is
proposed to support the distributed sharing model where a node
receives and processes an IO only if it is interested in this
information; if not, it could forward or simply discard messages,
even broadcast messages. ICWSAN could enable this technique because
the network layer could understand what information is carried, what
that means and distributes the information to nodes that need this
information. The network level could support fault-tolerance.
Uninterested information objects are discarded from the network
layer where disallows the communication/processing, hence the error
is never propagated to application level. In contrast, TCP/IP
network layer delivers all the indistinguishable packets equally.
Therefore, the information-based distributed filer is desired to
reduce failure in resource-constrained nodes like sensors.
Dinh & Kim Expires Dec 30, 2014 [Page 7]
Internet-Draft ICN Sensor and Actor Network Scenarios June 2014
7. Information-centric routing and Aggregation
Routing in WSANs is tightly coupled to the requirement of sensing
task as well as application. ICWSAN designs a content-based routing
which is closer to the application semantics to optimize the data
transport and information aggregation. The content becomes
transparently from the view point of clients, service discovery and
routing, thus reduce overhead in HTTP-CoAP translation process at
proxy node. In ICWSAN, the information can be recognized in the
network layer which is valuable to implement a content-based
prioritized routing policy to meet different requirements of
information dissemination (e.g. an emergency event type or a
periodic sensing report). Same type (ST) nodes could be organized in
a ST tree to serve the requests. ICWSAN strongly supports anycast
and multicast requests/commands to a specific EoI in an AoI.
The data aggregation could be executed along the ST trees. Sensing
data from children nodes are aggregated together to reduce redundant
or summary. A large number of transmission could be reduced, thus
save energy. For upstream direction, the content based aggregation
helps improve the quality of information while minimizing the
communication (e.g. temperature data could be recognized and
aggregated together before sending to a temperature sink node or an
actor node). In general, data aggregation in WSANs is to reduce
redundancy (e.g. summarize data), which has been widely studied.
However, data aggregation in heterogeneous WSANs is a challenge in
traditional approaches, which has not or little studied in the
literature. There are many types of information are generated and
transmitted from different types of sensors and actors. Different
types of information may not allow aggregating together and they
could be forwarded to different receivers. Mixed aggregation may
results in errors (e.g. temperature data is summarized with a
humidity data) because the node could not know the content inside
the packets until it is forwarded to the application layer. By
enabling information at the network layer through the naming scheme,
IOs in heterogeneous ICWSANs could be classified and aggregated in
data flows or at any nodes. By reducing a large number of IOs
forwarded to the sink node, it thus reduces congested links around
the sink node.
8. Semantic Coordination and Collaboration
One of the main ideas of ICWSAN is to base sensors/actors
collaboration decision on content which is to build cooperative
distributed WSAN environments where autonomous objects (including
information objects and network entities) can be discovered,
queried, coordinated automatically without a need of a central
Dinh & Kim Expires Dec 30, 2014 [Page 8]
Internet-Draft ICN Sensor and Actor Network Scenarios June 2014
control. ICWSAN implements a high-level abstraction for integration
of sensor networks with actors (e.g. mobile robots, vehicles).
Sensors could execute cooperative sensing, processing, and
organizing themselves to produce and retrieve the information
required by sink/actor node while minimizing the number of
transmitted messages. For example, in a heterogeneous wireless
sensor and actor network environment with multiple types of sensor,
actor and sink nodes existing in the same space, a temperature
sensor could self-coordinates to report its sensing data to a
temperature sink node (not another type of sink node) without a need
of sink node discovery; or a fire fighter (e.g. actors or robots)
could express its interest with a key word "temp-xxx" to collect
temperature data from any or all temperature in a fired area without
caring specific address of each node; the actors could also self-
coordinate and collaborate together to extinguish fires. In
addition, cooperative caching ensures sharing sensing information
among nodes to not only reduce number of communications but also
support indirect query in case of sleeping node; for instant, when a
node wakes up, it could retrieve configuration/notification message
cached in neighbour nodes; in other hand, a node also could
disseminate its sensing information to be cached in its neighbours
and fall to a sleep mode; a request for the sensing data from this
node could be retrieved indirectly from a cache holder or
asynchronously by interest message caching.
9. In-network caching
One of the main benefits from the ICN concept is the support of
in-network caching. The in-network caching feature can improve the
performance of the dissemination of information generated by sensor
nodes. The sensing data from a source node can be cached along
the intermediate sensor nodes that will improve bandwidth of whole
network. For example, according to industrial routing requirements
in low-power and lossy networks [RFC 5673], one characteristic in
the industrial environment is periodic data. The data is sent
periodically and causes bandwidth problem. The in-network caching
allows the intermediate nodes to cache these periodically generated
data. In this situation, the bandwidth of whole sensor network will
be improved for the future requests to the same kind of data.
In-network caching can be useful in the case of incorrect data
detection or over-threshold detection. In the information-centric
sensor network, by putting caching functions at the border sensor
node, the border node can cache most of the sensing data from a
specific area. Some tasks, such as incorrect data detection or
calculation can be done at the border nodes instead of the control
center. For examples, the border node can calculate the average
temperature of a specific area by using temperature data from its
cache as well as requesting temperature data from sensors which the
border node doesn't have. This can reduce bandwidth cost of the
sensor network.
Dinh & Kim Expires Dec 30, 2014 [Page 9]
Internet-Draft ICN Sensor and Actor Network Scenarios June 2014
10. Security Considerations
11. IANA Considerations
12. Acknowledgments
13. References
13.1. Normative References
13.2. Informative References
[RFC4919] N., Kushalnagar., Montenegro, G., and C. Schumacher," IPv6
over Low-Power Wireless Personal Area Networks
(6LoWPANs):Overview, Assumptions, Problem Statement, and
Goals", RFC4919, February 2007.
[RFC 5673] K. Pister et al., "Industrial Routing requirements in
Low-power and Lossy networks", RFC 5673, Oct 2009
[ICWSAN] Ngoc-Thanh Dinh and Younghan Kim, "Potential of
Information-Centric Wireless Sensor and Actor Networking,"
Proc. Of COMMANTEL, January 2013
[CCN] Jacobson, V. et al., "Networking Named Content," Proc. Of ACM
CoNEXT, 2009.
[MULTIBIT-TRIE] Kun Suk Kim and Sartaj Sahni, "Efficient
Construction of Piplined Multibit-Trie Router Tables," IEEE
Trans. On Computers, Vol. 6, No. 1,pp. 32-43, 2007.
Dinh & Kim Expires Dec 30, 2014 [Page 10]
Internet-Draft ICN Sensor and Actor Network Scenarios June 2014
Authors' Addresses
Ngoc-Thanh Dinh
Soongsil University
Sangdo-do,Dongjak-Gu,Seoul, Korea 156-743
Email: ngocthanhdinh@dcn.ssu.ac.kr
Younghan Kim
Soongsil University
Sangdo-do,Dongjak-Gu,Seoul, Korea 156-743
Email: younghak@ssu.ac.kr
Truong-xuan Do
Soongsil University
Sangdo-do,Dongjak-Gu,Seoul, Korea 156-743
Email: xuan@dcn.ssu.ac.kr
Hyunsik Yang
Soongsil University
Sangdo-do,Dongjak-Gu,Seoul, Korea 156-743
Email: yangun@dcn.ssu.ac.kr
Dinh & Kim Expires Dec 30, 2014 [Page 11]
