ICN Wireless Sensor and Actor Network BaseLine Scenarios
Author(s): Ngoc-Thanh Dinh, Young-Han Kim
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...
ICNRG N.T. Dinh Internet Draft Y. Kim Intended status: Standards Track Soongsil University Expires: December 24, 2013 June 24, 2013 ICN Wireless Sensor and Actor Network BaseLine Scenarios draft-dinh-icn-sensor-scenarios-01 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 December 24, 2013. 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 December 24, 2013 [Page 1] Internet-Draft ICN Sensor and Actor Network Scenarios June 2013 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. Security Considerations........................................9 10. IANA Considerations...........................................9 11. Acknowledgments...............................................9 12. References....................................................9 12.1. Normative References........................................9 12.2.Informative References.......................................9 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 December 24, 2013 [Page 2] Internet-Draft ICN Sensor and Actor Network Scenarios June 2013 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 December 24, 2013 [Page 3] Internet-Draft ICN Sensor and Actor Network Scenarios June 2013 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 December 24, 2013 [Page 4] Internet-Draft ICN Sensor and Actor Network Scenarios June 2013 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 December 24, 2013 [Page 5] Internet-Draft ICN Sensor and Actor Network Scenarios June 2013 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 neighbor 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 neighbors update its neighbor table with the new ranked neighbor 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 December 24, 2013 [Page 6] Internet-Draft ICN Sensor and Actor Network Scenarios June 2013 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 neighbor 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 December 24, 2013 [Page 7] Internet-Draft ICN Sensor and Actor Network Scenarios June 2013 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 December 24, 2013 [Page 8] Internet-Draft ICN Sensor and Actor Network Scenarios June 2013 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 neighbor nodes; in other hand, a node also could disseminate its sensing information to be cached in its neighbors 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. Scenarios in this category include opened topics which are also discussed for future works. 9. Security Considerations 10. IANA Considerations 11. Acknowledgments 12. References 12.1. Normative References 12.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. Dinh & Kim Expires December 24, 2013 [Page 9] Internet-Draft ICN Sensor and Actor Network Scenarios June 2013 [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. Authors' Addresses Ngoc-Thanh Dinh Soongsil University HuyngnamEnginerring Building 424,SoongsilUniv,Sangdo-do,Dongjak-Gu, Seoul, Korea 156-743 Phone: 00828200841 Email: email@example.com Younghan Kim Soongsil University HuyngnamEnginerring Building 424,SoongsilUniv,Sangdo-do,Dongjak-Gu, Seoul, Korea 156-743 Phone: 00828200841 Email: firstname.lastname@example.org Dinh & Kim Expires December 24, 2013 [Page 10]