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


   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-

   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

   The list of Internet-Draft Shadow Directories can be accessed at

   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

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

   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)

   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]