Design Considerations for Applying ICN to IoT
draft-zhang-icnrg-icniot-00
The information below is for an old version of the document.
| Document | Type |
This is an older version of an Internet-Draft whose latest revision state is "Replaced".
|
|
|---|---|---|---|
| Authors | Yanyong Zhang , Dipankar Raychadhuri , Luigi Alfredo Grieco , Emmanuel Baccelli , Jeff Burke , Ravi Ravindran , Guoqiang Wang , Bengt Ahlgren , Olov Schelen | ||
| Last updated | 2017-03-28 | ||
| Replaced by | draft-irtf-icnrg-icniot | ||
| RFC stream | (None) | ||
| Formats | |||
| Additional resources | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-zhang-icnrg-icniot-00
ICN Research Group Y. Zhang
Internet-Draft D. Raychadhuri
Intended status: Informational WINLAB, Rutgers University
Expires: September 29, 2017 L. Grieco
Politecnico di Bari (DEI)
E. Baccelli
INRIA
J. Burke
UCLA REMAP
R. Ravindran
G. Wang
Huawei Technologies
A. Lindren
B. Ahlgren
RISE SICS
O. Schelen
Lulea University of Technology
March 28, 2017
Design Considerations for Applying ICN to IoT
draft-zhang-icnrg-icniot-00
Abstract
The Internet of Things (IoT) promises to connect billions of objects
to the Internet. After deploying many stand-alone IoT systems in
different domains, the current trend is to develop a common, "thin
waist" of protocols forming a horizontal unified, defragmented IoT
platform. Such a platform will make objects accessible to
applications across organizations and domains. Towards this goal,
quite a few proposals have been made to build an application-layer
based unified IoT platform on top of today's host-centric Internet.
However, there is a fundamental mismatch between the host-centric
nature of todays Internet and the information-centric nature of the
IoT system. To address this mismatch, we propose to build a common
set of protocols and services, which form an IoT platform, based on
the Information Centric Network (ICN) architecture, which we call
ICN-IoT. ICN-IoT leverages the salient features of ICN, and thus
provides naming, security, seamless mobility support, scalability,
and efficient content and service delivery.
This draft describes representative IoT requirements, ICN challenges
and design considerations to realize a unified ICN-IoT framework.
Towards this, we first motivate ICN for IoT using specific use case
scenarios. Then taking a general IoT perspective, we discuss the IoT
requirements generally applicable to many well known scenarios. We
then discuss how the current application layer unified IoT
Zhang, et al. Expires September 29, 2017 [Page 1]
Internet-Draft ICN based Architecture for IoT March 2017
architecture fails to meet these requirements, followed by discussion
on suitability of ICN for IoT. Though we see most of the IoT
requirements can be met by ICN, we discuss specific design challenges
ICN has to address to satisfy them.
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). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
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."
This Internet-Draft will expire on September 29, 2017.
Copyright Notice
Copyright (c) 2017 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
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.
Table of Contents
1. IoT Motivation . . . . . . . . . . . . . . . . . . . . . . . 3
2. Motivating ICN for IoT . . . . . . . . . . . . . . . . . . . 4
3. IoT Architectural Requirements . . . . . . . . . . . . . . . 8
3.1. Naming . . . . . . . . . . . . . . . . . . . . . . . . . 8
3.2. Security and Privacy . . . . . . . . . . . . . . . . . . 8
3.3. Scalability . . . . . . . . . . . . . . . . . . . . . . . 9
3.4. Resource Constraints . . . . . . . . . . . . . . . . . . 9
3.5. Traffic Characteristics . . . . . . . . . . . . . . . . . 10
3.6. Contextual Communication . . . . . . . . . . . . . . . . 11
Zhang, et al. Expires September 29, 2017 [Page 2]
Internet-Draft ICN based Architecture for IoT March 2017
3.7. Handling Mobility . . . . . . . . . . . . . . . . . . . . 11
3.8. Storage and Caching . . . . . . . . . . . . . . . . . . . 11
3.9. Communication Reliability . . . . . . . . . . . . . . . . 12
3.10. Self-Organization . . . . . . . . . . . . . . . . . . . . 12
3.11. Ad hoc and Infrastructure Mode . . . . . . . . . . . . . 13
3.12. Unified Architecture . . . . . . . . . . . . . . . . . . 13
3.13. IoT Platform Management . . . . . . . . . . . . . . . . . 13
4. State of the Art . . . . . . . . . . . . . . . . . . . . . . 14
4.1. Silo IoT Architecture . . . . . . . . . . . . . . . . . . 14
4.2. Application-Layer Unified IoT Solutions . . . . . . . . . 15
4.2.1. Weaknesses of the Application-Layer Approach . . . . 16
4.2.2. Suitability of Delay Tolerant Networking(DTN) . . . . 18
5. Advantages of using ICN for IoT . . . . . . . . . . . . . . . 18
6. ICN Design Considerations for IoT . . . . . . . . . . . . . . 20
6.1. Naming Devices, Data, and Services . . . . . . . . . . . 20
6.2. Name Resolution . . . . . . . . . . . . . . . . . . . . . 22
6.3. Security and Privacy . . . . . . . . . . . . . . . . . . 23
6.4. Caching/Storage . . . . . . . . . . . . . . . . . . . . . 25
6.5. Routing and Forwarding . . . . . . . . . . . . . . . . . 26
6.6. Mobility Management . . . . . . . . . . . . . . . . . . . 27
6.7. Contextual Communication . . . . . . . . . . . . . . . . 27
6.8. In-network Computing . . . . . . . . . . . . . . . . . . 28
6.9. Self-Orgnization . . . . . . . . . . . . . . . . . . . . 29
6.10. Communications Reliability . . . . . . . . . . . . . . . 29
6.11. Resource Constraints and Heterogeneity . . . . . . . . . 30
7. Informative References . . . . . . . . . . . . . . . . . . . 30
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 39
1. IoT Motivation
During the past decade, many standalone Internet of Things (IoT)
systems have been developed and deployed in different domains. The
recent trend, however, is to evolve towards a globally unified IoT
platform, in which billions of objects connect to the Internet,
available for interactions among themselves, as well as interactions
with many different applications across boundaries of administration
and domains. Building a unified IoT platform, however, poses great
challenges on the underlying network and systems. To name a few, it
needs to support 50-100 Billion networked objects [1], many of which
are mobile. The objects will have extremely heterogeneous means of
connecting to the Internet, often with severe resource constraints.
Interactions between the applications and objects are often real-time
and dynamic, requiring strong security and privacy protections. In
addition, IoT applications are inherently information centric (e.g.,
data consumers usually need data sensed from the environment without
any reference to the sub-set of motes that will provide the asked
information). Taking a general IoT perspective, we first motivate
the discussion of ICN for IoT using well known scenarios. Then we
Zhang, et al. Expires September 29, 2017 [Page 3]
Internet-Draft ICN based Architecture for IoT March 2017
discuss the IoT requirements generally applicable to many well known
IoT scenarios. We then discuss how the current application-layer
unified IoT architectures fail to meet these requirements. We follow
this by key ICN features that makes it a better candidate to realize
an unified IoT framework. We then discuss IoT design challenges from
an ICN perspective and requirements posed towards its design.
2. Motivating ICN for IoT
ICN offers many features including name-based networking,content
object level security, caching, computing and storage, mobility,
contextual networking and support for ad hoc networking features, all
of which have to be realized in an application-specific means in the
context of IP-IoT. These compelling features enable a distributed
and intelligent data distribution platform to support heterogeneous
IoT services with features like device bootstrapping with minimal
configuration, simpler protocols to aid self-organizing among the IoT
elements, natural support for compute and caching logic at strategic
points in the network. We discuss these features through the
following scenarios that are difficult to realize over IP today, and
whose requirements match the features offered by ICN.
o Smart Mobility: It is well known that IoT technologies can play a
pivotal role in Intelligent Transportation Systems (ITS) [33][34].
In particular, Traffic Management Systems (TMS) aided by IoT
technologies are creating novel approaches to traffic modeling
[37]. Moreover, such features enable advanced design paradigms
(e.g., Mobility as a Service (MaaS) [35]) with huge implications
in systems architectures [38]. It is worth to note that ITS
services are information centric by design [88]. As a
consequence, smart mobility support can be a killer domain of ICN-
IoT [37][38][35]. Moreover, the experimental evidence
demonstrates that ICN can significantly magnify the effectiveness
of IoT deployments, in terms of: energy efficiency and bandwidth
usage [48] [70][71]; scalability [72]; and flexibility of the name
scheme [82][83]. In the ITS use case, we expect multi-modal
transportation means that embrace public and private municipal,
regional, national, trans-national fleets. This rich eco-system
of transportation means is made available to users and citizens
through advanced services that are able to fulfill user
requirements while pursuing system level objectives, including the
reduction of the CO2 footprint, the real-time delivery of some
goods, the reduction of traffic within urban areas, the
provisioning of pleasant journeys to tourists, and the general
commitment of satisfactory travel time and experience [88]. From
a technological perspective, the challenges to face are: (i)
interoperability across different IoT technologies; (ii) design of
a namespace that is able to harmonize ITS standards; (iii)
Zhang, et al. Expires September 29, 2017 [Page 4]
Internet-Draft ICN based Architecture for IoT March 2017
provisioning of a scalable data-sharing model across real-time
(and non real-time) traffic sources; (iv) definition of travel-
centric services based on ICN-IoT; (v) seamless support to
mobility; (vi) content authentication and cryptography.
o Smart Building: Smart Building is a complex ecosystem in which
many different IoT devices manufacturers, protocols and
applications are collaborating to manage domestic environment in
an efficient and safe way [74], minimizing the number of
intervention requested. Buildings account for a very relevant
quota of energy consumption; if not optimized, such a quantity
might become even higher than that used in industrial field. The
use of renewable energy sources can only mitigate the problem.
Efficient resources management is a rising task for Industrial IoT
applications. Many industrial companies have been working on the
topic. Anyway, this is leading to a highly fragmented market,
with many vertical solutions designed independently for different
applications, which unavoidably hinder a large-scale M2M
deployment [75]. Both academic and industrial research has
produced some standards (namely, ETSI M2M [76] and oneM2M [77])
built as an overlay and application-layer networks of the current
Internet, exploiting the functionalities offered by M2M
technologies intensively. The current version of these
architectures is strongly centralized [73], thus requiring new
enhancements to grant its scalability, fault tolerance, and
flexibility. This results in overhead due to impaired and network
inefficiencies. A unified ICN-IoT platform would inter-connect
these systems through the Internet, thus enabling interaction with
and between each other and taking decisions at an aggregated level
efficiently, thanks to the embedded capability of ICN paradigm,
such as native multicast, data-centric security, and data in-
network aggregation and caching. The main research challenges aim
at defining a generic and incremental ICN-based platform
supporting data collection and edge-cloud services. From a
technological perspective, in fact, this requires some
intermediate steps: (i) design of a scalable namespace for
uniquely identifying the information of interest, (ii) data-
sharing model across heterogeneous systems, (iii) self-organizing
functionalities for improving network connections between end-
nodes, utilities and the control center, (iv) authentication
procedures to grant data confidentiality and integrity.
o Smart Grid: Smart Grids are increasingly deployed cyber-physical
systems [16] that have the capabilities such as substation and
distribution automation. Data flow and information management is
also very important to smart grids. In a unified IoT platform,
data collected from different smart grids can be integrated to
achieve more optimizations that include reliability, real-time
Zhang, et al. Expires September 29, 2017 [Page 5]
Internet-Draft ICN based Architecture for IoT March 2017
control, secure communications, and data privacy. Deployment of
the smart grid [20] [24] faces the following issues that are hard
to address with IP-based overlay solutions: (1) scalability:
future electrical grids must be able to scale gracefully to manage
a large number of heterogeneous devices; (2) real time: grids must
be able to perform real-time data collection, data processing and
control; (3) reliability: grids must be resilient to
hardware/software/networking failures; (4) security: grids and
associated systems are often considered critical infrastructure --
they must be able to defend against malicious attacks, detect
intrusion, and route around disruption. Smart grids have the
following specific requirements for the underlying IoT
architecture:
* Smart grids require names and name resolution system that can
enable networked control loops, real-time control, and
security.
* Smart grids may use in-network caching to back up valuable data
improving reliability.
* In smart grids, we often require very timely data delivery.
Therefore, it is important to be able to locate the closest
information. In addition, routing/forwarding robustness and
resilience is also critical.
* In smart grids, contextual information such as location, time,
voltage fluctuations, depending on the specific segment of the
grid, can be used to optimize several power distribution
objectives.
* In smart grids, we often rely on in-network computing to
increase the scalability and efficiency of the system, putting
computation closer to the data sources.
* In smart grids, energy consumptions profiles should never be
disclosed at a fine granularity as it can be used to violate
user privacy.
o Smart Industry: In a Smart Industry/Industry 4.0 environment,
there is a multitude of equipment with sensors that generate large
volumes of data during normal operation. This range from highly
time-critical data for real-time control of production processes,
to less time-critical data that is collected to central cloud
environment for control room monitoring, to pure log data without
latency requirements that is mainly kept for a posteriori
analysis. Industrial wireless networks are harsh environments
with lots of potential interference at the same time as hard
Zhang, et al. Expires September 29, 2017 [Page 6]
Internet-Draft ICN based Architecture for IoT March 2017
reliability and real-time requirements are placed by many
applications. This means that available network capacity is not
always high, so congestion is likely to be experienced by traffic
with less stringent timing requirements. The network need to
support a mobile workforce in a smart industry automation scenario
where users get access to data flows based on their physical
location and task requirements. Usually in an automation scenario
the mobile workforce will locally perform diagnostics or
maintenance and they rely on the information from the production
system both for safety and to solve any issues in the plant. The
mobile workforce relies on both historical data in order to
pinpoint the root cause of the problems, as well as the current
data flows in order to assess the present state of the equipment
under control. High resolution measurements are generated close
to the mobile workforce while the historic data has to be
retrieved from the historian servers. Furthermore, even if the
mobile workforce is located next to the equipment under control,
the data generated is usually transmitted to different control
systems due to availability reasons as well as for capacity
reasons due to the high traffic demands close to the processes.
To realize this in current IP based systems require an excessive
amount of traffic to and from the central control system for both
data and coordination messages, which can have an adverse effect
on the operational requirements of the factory. Most importantly
the additional traffic introduced by the mobile workforce should
not interfere with the control traffic making the situation worse.
Introducing ICN functionality into the system can introduce
several benefits that will enhance the working experience and
productivity for the mobile workforce.
* When using ICN, naming of data is simpler than knowing the
address of the node that stores that data.
* ICN provides the possibility to get newest data without knowing
the location of the caches or whether a particular piece of
data is available locally or in a central repository.
* Possibility to get either local high-resolution data or remote
low-resolution data (no need to store all data centrally, which
is maybe not even possible due to large data volumes).
* Workforce mobility between different access points in the
factory is inherently supported without the need to maintain
connection state.
* Removing tedious configurations in clients since that is
provided by the infrastructure.
Zhang, et al. Expires September 29, 2017 [Page 7]
Internet-Draft ICN based Architecture for IoT March 2017
* Allow sharing of large data volumes between users that are in
physical proximity without introducing additional traffic on
the backbone.
* Caching of data means avoiding database accesses to a
distributed redundant database in the central infrastructure
with consistency requirements.
3. IoT Architectural Requirements
A unified IoT platform has to support interactions among a large
number of mobile devices across the boundaries of organizations and
domains. As a result, it naturally poses stringent requirements in
every aspect of the system design. Below, we outline a few important
requirements that a unified IoT platform has to address.
3.1. Naming
The first step towards realizing a unified IoT platform is the
ability to assign names that are unique to each device, data items
generated by these devices, or a group of devices towards a common
objective. Naming has the following requirements: first, names need
to be persistent against dynamic features that are common in IoT
systems, such as lifetime, mobility or migration; second, names need
to be secure based on application requirements; third, names should
offer semantic meanings to applications in comparison with
traditional host address based schemes; finally, names should be able
to help realize scalable IoT system architecture and high performance
network platform.
3.2. Security and Privacy
In addition to the fundamental challenge of trust management, a
variety of security and privacy concerns also exist in ICNs.
The unified IoT platform makes physical objects accessible to
applications across organizations and domains. Further, it often
integrates with critical infrastructure and industrial systems with
life safety implications, bringing with it significant security
challenges and regulatory requirements [11].
Security and privacy thus become a serious concern, as does the
flexibility and usability of the design approaches. Beyond the
overarching trust management challenge, security includes data
integrity, authentication, and access control at different layers of
the IoT platform. Privacy means that both the content and the
context around IoT data need to be protected. These requirements
Zhang, et al. Expires September 29, 2017 [Page 8]
Internet-Draft ICN based Architecture for IoT March 2017
will be driven by various stake holders such as industry, government,
consumers etc.
In order to ensure the trustworthiness of the names, a name
certificate service (NCS) needs to be considered. Such a service
acts as a certificate authority in assigning names, which are
themselves public keys or appropriately bound to the name for
verification at the consumer's end. In short, the NCS must provide
services analogous to those provided by a Public Key Infrastructure
(PKI). In ICN, users may either generate their own public keys and
submit them to the NCS for registration, or may contact the NCS to
acquire public keys. Consequently, the NCS publishes approved
cryptographic suites, object categories and object description
formats, as well as allows users to self-certify themselves
themselves when public keys are used as names.
3.3. Scalability
Cisco predicts there will be around 50 Billion IoT devices such as
sensors, RFID tags, and actuators, on the Internet by 2020 [1]. As
mentioned above, a unified IoT platform needs to name every entity
such as data, device, service etc. Scalability has to be addressed
at multiple levels of the IoT architecture including naming,
security, name resolution, routing and forwarding level. In
addition, mobility adds further challenge in terms of scalability.
Particularly with respect to name resolution the system should be
able to register/update/resolve a name within a short latency.
3.4. Resource Constraints
IoT devices can be broadly classified as type 1, type 2, and type 3
devices, with type 1 the most resource-constrained and type 3 the
most resource-rich [36]. In general, there are the following types
of resources: power, computing, storage, bandwidth, and user
interface.
Power constraints of IoT devices limit how much data these devices
can communicate, as it has been shown that communications consume
more power than other activities for embedded devices. Flexible
techniques to collect the relevant information are required, and
uploading every single produced data to a central server is
undesirable. Computing constraints limit the type and amount of
processing these devices can perform. As a result, more complex
processing needs to be conducted in cloud servers or at opportunistic
points, example at the network edge, hence it is important to balance
local computation versus communication cost.
Zhang, et al. Expires September 29, 2017 [Page 9]
Internet-Draft ICN based Architecture for IoT March 2017
Storage constraints of the IoT devices limit the amount of data that
can be stored on the devices. This constraint means that unused
sensor data may need to be discarded or stored in aggregated compact
form time to time. Bandwidth constraints of the IoT devices limit
the amount of communication. Such devices will have the same
implication on the system architecture as with the power constraints;
namely, we cannot afford to collect single sensor data generated by
the device and/or use complex signaling protocols.
User interface constraints refer to whether the device is itself
capable of directly interacting with a user should the need arise
(e.g., via a display and keypad or LED indicators) or requires the
network connectivity, either global or local, to interact with
humans.
The above discussed device constraints also affect application
performance with respect to latency and jitter. This in particular
applies to satellite or other space based devices.
3.5. Traffic Characteristics
IoT traffic can be broadly classified into local area traffic and
wide area traffic. Local area traffic is between nearby devices.
For example, neighboring cars may work together to detect potential
hazards on the highway, sensors deployed in the same room may
collaborate to determine how to adjust the heating level in the room.
These local area communications often involve data aggregation and
filtering, have real time constraints, and require fast device/data/
service discovery and association. At the same time, the IoT
platform has to also support wide area communications. For example,
in Intelligent Transportation Systems, re-routing operations may
require a broad knowledge of the status of the system, traffic load,
availability of freights, whether forecasts and so on. Wide area
communications require efficient data/service discovery and
resolution services.
While traffic characteristics for different IoT systems are expected
to be different, certain IoT systems have been analyzed and shown to
have comparable uplink and downlink traffic volume in some
applications such as [2], which means that we have to optimize the
bandwidth/energy consumption in both directions. Further, IoT
traffic demonstrates certain periodicity and burstiness [2]. As a
result, when provisioning the system, the shape of the traffic volume
has to be properly accounted for.
Zhang, et al. Expires September 29, 2017 [Page 10]
Internet-Draft ICN based Architecture for IoT March 2017
3.6. Contextual Communication
Many IoT applications shall rely on dynamic contexts in the IoT
system to initiate communication between IoT devices. Here, we refer
to a context as attributes applicable to a group of devices that
share some common features, such as their owners may have a certain
social relationship or belong to the same administrative group, or
the devices may be present in the same location. For example, cars
traveling on the highway may form a "cluster" based upon their
temporal physical proximity as well as the detection of the same
event. These temporary groups are referred to as contexts. IoT
applications need to support interactions among the members of a
context, as well as interactions across contexts.
Temporal context can be broadly categorized into two classes, long-
term contexts such as those that are based upon social contacts as
well as stationary physical locations (e.g., sensors in a car/
building), and short-term contexts such as those that are based upon
temporary proximity (e.g., all taxicabs within half a mile of the
Time Square at noon on Oct 1, 2013). Between these two classes,
short-term contexts are more challenging to support, requiring fast
formation, update, lookup and association.
3.7. Handling Mobility
There are several degrees of mobility in a unified IoT platform,
ranging from static as in fixed assets to highly dynamic in vehicle-
to-vehicle environments.
Mobility in the IoT platform can mean 1) the data producer mobility
(i.e., location change), 2) the data consumer mobility, 3) IoT
Network mobility (e.g., a body-area network in motion as a person is
walking); and 4) disconnection between the data source and
destination pair (e.g., due to unreliable wireless links). The
requirement on mobility support is to be able to deliver IoT data
below an application's acceptable delay constraint in all of the
above cases, and if necessary to negotiate different connectivity or
security constraints specific to each mobile context.
3.8. Storage and Caching
Storage and caching plays a very significant role depending on the
type of IoT ecosystem, also a function subjected to privacy and
security guidelines. In a unified IoT platform, depending on
application requirements, content caching may or may not be policy
driven. If caching is pervasive, intermediate nodes don't need to
always forward a content request to its original creator; rather,
locating and receiving a cached copy is sufficient for IoT
Zhang, et al. Expires September 29, 2017 [Page 11]
Internet-Draft ICN based Architecture for IoT March 2017
applications. This optimization can greatly reduce the content
access latencies.
Furthermore considering hierarchical nature of IoT systems, ICN
architectures enable flexible heterogeneous and potentially fault-
tolerant approach to storage providing persistence at multiple
levels.
Hence in the context of IoT while ICN allows resolution to replicated
cached copies, it should also strive for the balance between content
security/privacy and regulations considering application
requirements.
3.9. Communication Reliability
IoT applications can be broadly categorized into mission critical and
non-mission critical. For mission critical applications, reliable
communication is one of the most important features as these
applications have strong QoS requirements such as low latency and
probability of error during information transfer. To summarize,
reliable communication requires the following capabilities for the
underlying system: (1) seamless mobility support in the face of
extreme disruptions, (2) efficient routing in the presence of
intermittent disconnection, (3) QoS aware routing, (4) support for
redundancy at all levels of a system (device, service, network,
storage etc.), and (5) support for rich and diverse communication
patterns, including both communications within an IoT domain and
communications cross different domains.
3.10. Self-Organization
The unified IoT platform should be able to self-organize to meet
various application requirements, especially the capability to
quickly discover heterogeneous and relevant (local or global)
devices/data/services based on the context. This discovery can be
achieved through an efficient platform-wide publish-subscribe
service, or through private community grouping/clustering based upon
trust and other security requirements. In the former case, the
publish-subscribe service must be efficiently implemented, able to
support seamless mobility, in- network caching, name-based routing,
etc. In the latter case, the IoT platform needs to discover the
private community groups/clusters efficiently.
Another aspect of self-organization is decoupling the sensing
Infrastructure from applications. In a unified IoT platform, various
applications run on top of a vast number of IoT devices. Upgrading
the firmware of the IoT devices is a difficult work. It is also not
practical to reprogram the IoT devices to accommodate every change of
Zhang, et al. Expires September 29, 2017 [Page 12]
Internet-Draft ICN based Architecture for IoT March 2017
the applications. The infrastructure and the application specific
logics need to be decoupled. A common interface is required to
dynamically configure the interactions between the IoT devices and
easily modify the application logics on top of the sensing
infrastructure [26] [27].
3.11. Ad hoc and Infrastructure Mode
Depending upon whether there is communication infrastructure, an IoT
system can operate either in ad-hoc or infrastructure mode.
For example, a vehicle may determine to report its location and
status information to a server periodically through cellular
connection, or, a group of vehicles may form an ad-hoc network that
collectively detect road conditions around them. In the cases where
infrastructure is unavailable, one of the participating nodes may
choose to become the temporary gateway.
The unified IoT platform needs to design a common protocol that
serves both modes. Such a protocol should address the challenges
that arise in these two modes: (1) scalability and low latency for
the infrastructure mode and (2) efficient neighbor discovery and ad-
hoc communication for the ad-hoc mode. Finally we note that hybrid
modes are very common in realistic IoT systems.
3.12. Unified Architecture
General IoT applications involve sensing, processing, and secure
content distribution occurring at various timescales and at multiple
levels of hierarchy depending on the application requirements. This
requires the system to adopt a unified architecture providing pull,
push and publish/subscribe mechanisms using application abstractions,
common naming, payload, encryption and signature schemes. This
requires open APIs to be generic enough to support commonly used
interactions between consumers, content producer, and IoT services,
as opposed to proprietary APIs that are common in today's systems.
3.13. IoT Platform Management
An IoT platforms' service, control and data plane will be governed by
its own management infrastructure which includes distributed and
centralized middleware, discovery, naming, self-configuring, analytic
functions, and information dissemination to achieve specific IoT
system objectives [21][22][23]. Towards this new IoT management
mechanisms and service metrics need to be developed to measure the
success of an IoTdeployment. Considering an IoT systems' defining
characteristics such as, its potential large number of IoT devices,
ephemeral nature to save power, mobility, and ad hoc communication,
Zhang, et al. Expires September 29, 2017 [Page 13]
Internet-Draft ICN based Architecture for IoT March 2017
autonomic self-management mechanisms become very critical. Further
considering its hierarchical information processing deployment model,
the platform needs to orchestrate computational tasks according to
the involved sensors and the available computation resources which
may change over time. An efficient computation resource discovery
and management protocol is required to facilitate this process. The
trade-off between information transmission and processing is another
challenge.
4. State of the Art
Over the years, many stand-alone IoT systems have been deployed in
various domains. These systems usually adopt a vertical silo
architecture and support a small set of pre-designated applications.
A recent trend, however, is to move away from this approach, towards
a unified IoT platform in which the existing silo IoT systems, as
well as new systems that are rapidly deployed. This will make their
data and services accessible to general Internet applications (as in
ETSI- M2M and oneM2M standards). In such a unified platform,
resources can be accessed over Internet and shared across the
physical boundaries of the enterprise. However, current approaches
to achieve this objective are based upon Internet overlays, whose
inherent inefficiencies due to IP protocol [8] hinders the platform
from satisfying the IoT requirements outlined earlier (particularly
in terms of scalability, security, mobility, and self-organization)
4.1. Silo IoT Architecture
[IoT Server]
|
|
______|_______
_______ { }
{ } { }
{IoT Dev}\ { Internet }---[IoT Application]
{_______} [IoTGW]---{ }
{ }
{______________}
Figure 1:Silo architecture of standalone IoT systems
A typical standalone IoT system is illustrated in Figure 1, which
includes devices, a gateway, a server and applications. Many IoT
devices have limited power and computing resources, unable to
directly run normal IP access network (Ethernet, WIFI, 3G/LTE etc.)
Zhang, et al. Expires September 29, 2017 [Page 14]
Internet-Draft ICN based Architecture for IoT March 2017
protocols. Therefore they use the IoT gateway to the server.
Through the IoT server, applications can subscribe to data collected
by devices, or interact with devices.
There have been quite a few popular protocols for standalone IoT
systems, such as DF-1, MelsecNet, Honeywell SDS, BACnet, etc.
However, these protocols are operating at the device-level
abstraction, instead of information driven, leading to a highly
fragmented protocol space with limited interoperability.
4.2. Application-Layer Unified IoT Solutions
The current approach to a unified IoT platform is to make IoT
gateways and servers adopt standard APIs. IoT devices connect to the
Internet through the standard APIs and IoT applications subscribe and
receive data through standard control and data APIs. Building on top
of today's Internet this application-layer unified IoT architecture
is the most practical approach towards a unified IoT platform.
Towards this, there are ongoing standardization efforts including
ETSI[3], oneM2M[4]. Network operators can use frameworks to build
common IOT gateways and servers for their customers. In addition,
IETF's CORE working group [5] is developing a set of protocols like
CoAP (Constrained Application Protocol) [59], that is a lightweight
protocol modeled after HTTP [60] and adapted specifically for the
Internet of Things (IoT). CoAP adopts the Representational State
Transfer (REST) architecture with Client-Server interactions. It
uses UDP as the underlying transport protocol with reliability and
multicast support. Both CoAP and HTTP are considered as the suitable
application level protocols for Machine-to-Machine communications, as
well as IoT. For example, oneM2M (which is one of leading standards
for unified M2M platform) has both the protocol bindings to HTTP and
CoAP for its primitives. Figure 2 shows the architecture adopted in
this approach.
Zhang, et al. Expires September 29, 2017 [Page 15]
Internet-Draft ICN based Architecture for IoT March 2017
Publishing----[IoT Server]----Subscribing--
| / | \ |
| / | \ |
| /______|_______ \ |
___________ | /{ } publishing |
{ } | | { } | |
{Smart Homes}\ | | { Internet }---------[IoT Application]
{___________} [IoTGW]---{ }\ | ________________
| { } \ | { }
| {______________} [IoTGW]-{Smart Healthcare}
| | {________________}
Publishing [IoTGW]
| ____|_____
| { }
---{Smart Grid}
{__________}
Figure 2: Implementing an open IoT platform through standarized APIs
on the IoT gateways and the server
4.2.1. Weaknesses of the Application-Layer Approach
The above application-layer approach can work with many different
protocols, but the system is built upon today's IP network, which has
inherent weaknesses towards supporting a unified IoT system. As a
result, it cannot satisfy some of the requirements we outlined in
Section 2:
o Naming. In current application-layer IoT systems the naming
scheme is host centric, i.e., the name of a given resource/service
is linked to the device that can provide it. In turn, device
names are coupled to IP addresses, which are not persistent in
mobile scenarios. On the other side, in IoT systems the same
service/ resource could be provided by many different devices thus
requiring a different design rationale.
o Security and Trust. In IP, the security and trust model is based
on session established between two hosts. Session-based protocols
rely on the exchange of several messages before a secure session
is established. Use of such protocols in constrained IoT devices
can have serious consequences in terms of energy efficiency
because transmission and reception of messages is often more
costly than the cryptographic operations. The problem is
amplified with the number of nodes the constrained device has to
interact with because a secure session would have to be
established with every node. Also the trust management schemes
Zhang, et al. Expires September 29, 2017 [Page 16]
Internet-Draft ICN based Architecture for IoT March 2017
are still relatively weak, focusing on securing communication
channels rather than managing the data that needs to be secured
directly.
o Mobility. The application-layer approach uses IP addresses as
names at the network layer, which hinders the support for device/
service mobility or flexible name resolution. Further the Layer
2/3 management, and application-layer addressing and forwarding
required to deploy current IoT solutions limit the scalability and
management of these systems.
o Resource constraints. The application-layer approach requires
every device to send data to an aggregator, gateway or to the IoT
server. Resource constraints of the IoT devices, especially in
power and bandwidth, could seriously limit the performance of this
approach.
o Traffic Characteristics. In this approach, applications are
written in a host-centric manner suitable for point-to-point
communication. IoT requires multicast support that is challenging
the application-layer based IoT systems today.
o Contextual Communications. This application-layer based IoT
approach may not react to dynamic contextual changes in a timely
fashion. The main reason is that context lists are usually kept
at the IoT server in this approach, and they cannot help
efficiently route requests information at the network layer.
o Storage and Caching. The application-layer approach supports
application-centric storage and caching but not what ICN envisions
at the network layer, or flexible storage enabled via name-based
routing or name-based lookup.
o Self-Organization. The application-layer approach is topology-
based as it is bound to IP semantics, and thus does not
sufficiently satisfy the self-organization requirement. In
addition to topological self-organization, IoT also requires data-
and service-level self-organization [74], which is not supported
by this approach.
o Ad-hoc and infrastructure mode. As mentioned above, the overlay-
based approach lacks self-organization, and thus does not provide
efficient support for the ad-hoc mode of communication.
Zhang, et al. Expires September 29, 2017 [Page 17]
Internet-Draft ICN based Architecture for IoT March 2017
4.2.2. Suitability of Delay Tolerant Networking(DTN)
In [17][18], delay-tolerant networking (DTN) has been considered to
support future IoT architecture. DTN was created to support
information delivery in the presence of network disruptions and
disconnections, which has been extended to support heterogeneous
networks and name-based routing. The DTN Bundle Protocol is able to
achieve some of these same advantages and could be beneficially used
in an IoT network to, for example, decouple sender and receiver. The
DTN architecture is however still host centric and is mainly a way to
transport data, while ICN provides a different paradigm centered
around named data that addresses additional issues for IoT
applications [19] through features such as information naming,
information discovery, information request and dissemination. Hence,
in the rest of this draft, we focus on an ICN-based network-layer
unified IoT architecture for IoT, i.e., ICN-IoT.
5. Advantages of using ICN for IoT
A key concept of ICN is the ability to name data independently from
the current location at which it is stored, which simplifies caching
and enables decoupling of sender and receiver. Using ICN to design
an architecture for IoT data potentially provides many such
advantages compared to using traditional host-centric networks and
other new architectures. This section highlights general benefits
that ICN could provide to IoT networks.
o Naming of Devices, Data and Services. The heterogeneity of both
network equipment deployed and services offered by IoT networks
leads to a large variety of data, services and devices. While
using a traditional host-centric architecture, only devices or
their network interfaces are named at the network level, leaving
to the application layer the task to name data and services. In
many common applications of IoT networks, data and services are
the main goal, and specific communication between two devices is
secondary. The network distributes content and provides a
service, instead of establishing a communication link between two
devices. In this context, data content and services can be
provided by several devices, or group of devices, hence naming
data and services is often more important than naming the devices.
This naming mechanism also enables self-configuration of the IoT
system.
o Security and privacy. ICN advocates the model of trust in content
rather than trust in network hosts. This brings in the concept of
Object Security which is based on the idea of securing information
objects unlike session-based security mechanisms which secure the
communication channel between a pair of nodes. ICN provides data
Zhang, et al. Expires September 29, 2017 [Page 18]
Internet-Draft ICN based Architecture for IoT March 2017
integrity through Name-Data Integrity, i.e., the guarantee that
the given data corresponds to the name with which it was
addressed. Signature-based schemes can additionally provide data
authenticity, meaning establishing the origin, or provenance, of
the data, for example, by cryptographically linking a data object
to the identity of a publisher. Confidentiality can be handled on
a per object basis based on keys established at the application
level. In an ICN network, an IoT client expects the network to
deliver the requested content without concerning itself with the
location of the content. This could potentially mean that each
individual object within a stream of immutable objects is
retrieved from a different location. Having a trust relationship
with each of these different sources is not realistic. Through
Name-Data Integrity, ICN automatically guarantees data integrity
to the requester regardless of the source from where it is
delivered. The Object Security model also ensures that the
content is readily available in a secure state in the network.
IoT devices producing data can secure it with regard to all the
intended consumers and start transmitting it right away. If the
device constraints are severe enough that it is not able to
perform the required cryptographic operations for Object Security,
it may be possible to offload this operation to a trusted gateway
to which only a single secure channel needs to be established.
ICN can also derive a name from a public key; cryptographic hash
of a public key also enables them to be self-certifying, i.e.,
authenticating the resource object does not require an external
authority [21][22].
o Distributed Caching and Processing. While caching mechanisms are
already used by other types of overlay networks, IoT networks can
potentially benefit even more from caching and in-network
processing systems, because of their resource constraints.
Wireless bandwidth and power supply can be limited for multiple
devices sharing a communication channel, and for small mobile
devices powered by batteries. In this case, avoiding unnecessary
transmissions with IoT devices to retrieve and distribute IoT data
to multiple places is important, hence processing and storing such
content in the network can save wireless bandwidth and battery
power. Moreover, as for other types of networks, applications for
IoT networks requiring shorter delays can benefit from local
caches and services to reduce delays between content request and
delivery.
o Decoupling between Sender and Receiver. IoT devices may be mobile
and face intermittent network connectivity. When specific data is
requested, such data can often be delivered by ICN without any
consistent direct connectivity between devices. Apart from using
Zhang, et al. Expires September 29, 2017 [Page 19]
Internet-Draft ICN based Architecture for IoT March 2017
structured caching systems as described previously, information
can also be spread by forwarding data opportunistically.
6. ICN Design Considerations for IoT
This section outlines some of the ICN specific design considerations
and challenges that must be considered when defining an IoT framework
over ICN, and describes some of the trade offs that will be involved.
Though ICN integrates content/service/host abstraction, name-based
routing, compute, caching/storage as part of the network
infrastructure, IoT requires special considerations given
heterogeneity of devices and interfaces such as for constrained
networking [48][90][91], data processing, and content distribution
models to meet specific application requirements which we identify as
challenges in this section.
6.1. Naming Devices, Data, and Services
The ICN approach of named data and services (i.e., device independent
naming) is typically desirable when retrieving IoT data. However,
data centric naming may also pose challenges.
o Naming of devices: Naming devices is often important in an IoT
network. The presence of actuators requires clients to act
specifically on a device, e.g. to switch it on or off. Also,
managing and monitoring the devices for administration purposes
requires devices to have a specific name allowing to identify them
uniquely. There are multiple ways to achieve device naming, even
in systems that are data centric by nature. For example, in
systems that are addressable or searchable based on metadata or
sensor content, the device or service identifier can be included
as a special kind of metadata or sensor reading.
o Size of data/service name: In information centric applications,
the size of the data is typically larger than its name. For the
IoT, sensors and actuators are very common, and they can generate
or use data as small as a short integer containing a temperature
value, or a one-byte instruction to switch off an actuator. The
name of the content for each of these pieces of data has to
uniquely identify the content. For this reason, many existing
naming schemes have long names that are likely to be longer than
the actual data content for many types of IoT applications.
Furthermore, naming schemes that have self certifying properties
(e.g., by creating the name based on a hash of the content),
suffer from the problem that the object can only be requested when
the object has been created and the content is already known, thus
requiring some form of indexing service. While this is an
Zhang, et al. Expires September 29, 2017 [Page 20]
Internet-Draft ICN based Architecture for IoT March 2017
acceptable overhead for larger data objects, it is infeasible for
use when the object size is on the order of a few bytes.
o Hash-based content name: Hash algorithms are commonly used to name
content in order to verify that the content is the one requested.
This is only possible in contexts where the requested object is
already existing, and where there is a directory service to look
up names. This approach is suitable for systems with large data
objects where it is important to verify the content.
o Metadata-based content name: Relying on metadata allows to
generate a name for an object before it is created. However this
mechanism requires metadata matching semantics.
o Naming of services: Similarly to naming of devices or data,
services can be referred to with a unique identifier, provided by
a specific device or by someone assigned by a central authority as
the service provider. It can however also be a service provided
by anyone meeting some certain metadata conditions. Example of
services include content retrieval, that takes a content name/
description as input and returns the value of that content, and
actuation, that takes an actuation command as input and possibly
returns a status code afterwards.
o Trust: We need to ensure the name of a network element is issued
by a trustworthy issuer in the context of the application, such as
a trusted organization in [44]. Further the validity of each
piece of data published by an authorized entity in the namespace
should be verifiable - e.g., by following a hierarchical chain-of-
trust to a root that is acceptable for the application, as in
[65].
o Flexibility: Further challenges arise for hierarchical naming
schema: referring to requirements on "constructible names" and
"on-demand publishing" [31][32]. The former entails that each
user is able to construct the name of a desired data item through
specific algorithms and that it is possible to retrieve
information also using partially specified names. The latter
refers the possibility to request a content that has not yet been
published in the past, thus triggering its creation.
o Control/scoping : Some information could be accessible only within
a given scope. This challenge is very relevant for smart home and
health monitoring applications, where privacy issues play a key
role and the local scope of a home or healthcare environment may
be well-defined. However, perimeter- and channel-based access
control is often violated in current networks to enable over-the-
Zhang, et al. Expires September 29, 2017 [Page 21]
Internet-Draft ICN based Architecture for IoT March 2017
wire updates and cloud-based services, so scoping is unlikely to
replace a need for data-centric security in ICN.
o Confidentiality: As names can reveal information about the nature
of the communication, mechanisms for name confidentiality should
be available in the ICN-IoT architecture.
6.2. Name Resolution
Inter-connecting numerous IoT entities, as well as establishing
reachability to them, requires a scalable name resolution system
considering several dynamic factors like mobility of end points,
service replication, in-network caching, failure or migration [46]
[50] [51] [69]. The objective is to achieve scalable name resolution
handling static and dynamic ICN entities with low complexity and
control overhead. In particular, the main requirements/challenges of
a name space (and the corresponding Name Resolution System where
necessary) are [40] [42]:
o Scalability: The first challenge faced by ICN-IoT name resolution
system is its scalability. Firstly, the approach has to support
billions of objects and devices that are connected to the
Internet, many of which are crossing administrative domain
boundaries. Second of all, in addition to objects/devices, the
name resolution system is also responsible for mapping IoT
services to their network addresses. Many of these services are
based upon contexts, hence dynamically changing, as pointed out in
[46]. As a result, the name resolution should be able to scale
gracefully to cover a large number of names/services with wide
variations (e.g., hierarchical names, flat names, names with
limited scope, etc.). Notice that, if hierarchical names are
used, scalability can be also supported by leveraging the inherent
aggregation capabilities of the hierarchy. Advanced techniques
such as hyperbolic routing [64] may offer further scalability and
efficiency.
o Deployability and interoperability: Graceful deployability and
interoperability with existing platforms is a must to ensure a
naming schema to gain success on the market [7]. As a matter of
fact, besides the need to ensure coexistence between IP-centric
and ICN-IoT systems, it is required to make different ICN-IoT
realms, each one based on a different ICN architecture, to
interoperate.
o Latency: For real-time or delay sensitive M2M application, the
name resolution should not affect the overall QoS. With reference
to this issue it becomes important to circumvent too centralized
resolution schema (whatever the naming style, i.e, hierarchical or
Zhang, et al. Expires September 29, 2017 [Page 22]
Internet-Draft ICN based Architecture for IoT March 2017
flat) by enforcing in-network cooperation among the different
entities of the ICN-IoT system, when possible [73]. In addition,
fast name lookup are necessary to ensure soft/hard real time
services [78][79][80]. This challenge is especially important for
applications with stringent latency requirements, such as health
monitoring, emergency handling and smart transportation [81].
o Locality and network efficiency: During name resolution the named
entities closer to the consumer should be easily accessible
(subject to the application requirements). This requirement is
true in general because, whatever the network, if the edges are
able to satisfy the requests of their consumers, the load of the
core and content seek time decrease, and the overall system
scalability is improved. This facet gains further relevance in
those domains where an actuation on the environment has to be
executed, based on the feedbacks of the ICN-IoT system, such as in
robotics applications, smart grids, and industrial plants [74].
o Agility: Some data items could disappear while some other ones are
created so that the name resolution system should be able to
effectively take care of these dynamic conditions. In particular,
this challenge applies to very dynamic scenarios (e.g., VANETs) in
which data items can be tightly coupled to nodes that can appear
and disappear very frequently.
6.3. Security and Privacy
Security and privacy is crucial to all the IoT applications
applications including the use cases discussed in Section 5. In one
recent demonstration,it was shown that passive tire pressure sensors
in cars could be hacked and used as a gateway into the automotive
system [55]. The ICN paradigm is information-centric as opposed to
state-of-the-art host-centric internet. Besides aspects like naming,
content retrieval and caching this also has security implications.
ICN advocates the model of trust in content rather than trust in
network hosts. This brings in the concept of Object Security which
is contrary to session-based security mechanisms such as TLS/DTLS
prevalent in the current host-centric internet. Object Security is
based on the idea of securing information objects unlike session-
based security mechanisms which secure the communication channel
between a pair of nodes. This reinforces an inherent characteristic
of ICN networks i.e. to decouple senders and receivers. In the
context of IoT, the Object Security model has several concrete
advantages. Many IoT applications have data and services are the
main goal and specific communication between two devices is
secondary. Therefore, it makes more sense to secure IoT objects
instead of securing the session between communicating endpoints.
Though ICN includes data-centric security features the mechanisms
Zhang, et al. Expires September 29, 2017 [Page 23]
Internet-Draft ICN based Architecture for IoT March 2017
have to be generic enough to satisfy multiplicity of policy
requirements for different applications. Furthermore security and
privacy concerns have to be dealt in a scenario-specific manner with
respect to network function perspective spanning naming, name-
resolution, routing, caching, and ICN-APIs. The work by the JOSE WG
[61] provides solution approaches to address some of these concerns
for object security for constrained devices and should be considered
to see what can be applied to an ICN architecture. In general, we
feel that security and privacy protection in IoT systems should
mainly focus on the following aspects: confidentiality, integrity,
authentication and non-repudiation, and availability.
Implementing security and privacy methods faces different challenges
in the constrained and infrastructure part of the network.
o In the resource-constrained nodes, energy limitation is the
biggest challenge. Moreover, it has to deliver its data over a
wireless link for a reasonable period of time on a coin cell
battery. As a result, traditional security/privacy measures are
impossible to be implemented in the constrained part. In this
case, one possible solution might be utilizing the physical
wireless signals as security measures [56] [45].
o In the infrastructure part, we have several new threats introduced
by ICN-IoT [63]. Below we list several possible attacks to a name
resolution service that is critical to ICN-IoT:
1. Each IoT device is given an ICN name. The name spoofing
attack is a masquerading threat, where a malicious user A
claims another user B's name and attempts to associate it with
A's own network address NA-A, by announcing the mapping (ID-B,
NA-A). The consequence of this attack is a denial of service
as it can cause traffic directed for B to be directed to A's
network address.
2. The stale mapping attack is a message manipulation attack
involving a malicious name resolution server. In this attack,
if a device moves and issues an update, the malicious name
resolution server can purposely ignore the update and claim it
still has the most recent mapping. Perhaps worse, a name
resolution server can selectively choose which (possibly
stale) mapping to give out during queries. The result is a
denial of service.
3. The third potential attack, false announcement attack, is an
information modification attack that results in illegitimate
resource consumption. User A, which is in network NA1, claims
its ID-A binds to a different network address, (ID-A, NA2).
Zhang, et al. Expires September 29, 2017 [Page 24]
Internet-Draft ICN based Architecture for IoT March 2017
Thus A can direct its traffic to network NA2, which causes
NA2's network resources to be consumed.
4. The collusion attack is an example of an information
modification attack in which a malicious user, its network and
the location where the mapping is stored collude with each
other. The objective behind the malicious collusion is to
allow for a fake mapping involving a false network address to
pass the verification and become stored in the storage place.
5. An intruder may insert fake/false sensor data into the
network. The consequence might be an increase in delay and
performance degradation for network services and applications.
o As far as the IoT application server is concerned, data privacy is
one of the biggest concerns. IoT data is collected and stored on
such servers, which usually run learning algorithms to extract
patterns from such data. In this case, it is important to adopt a
framework that enables privacy-preserving learning techniques.
The framework defines how data is collected, modified (to satisfy
the privacy requirement), and transmitted to application
developers.
6.4. Caching/Storage
In-network caching helps bring data closer to consumers, but its
usage differs in constrained and infrastructure part of the IoT
network.
Caching in ICN-IoT faces several challenges:
o The main challenge is to determine which nodes on the routing path
should cache the data. According to [42], caching the data on a
subset of nodes can achieve a better gain than caching on every
en-route routers. In particular, the authors propose a "selective
caching" scheme to locate those routers with better hit
probabilities to cache data. According to [43], selecting a
random router to cache data is as good as caching the content
everywhere. In [66], the authors suggest that edge caching
provides most of the benefits of in-network caching typically
discussed in NDN, with simpler deployment. However, it and other
papers consider workloads that are analogous to today's CDNs, not
the IoT applications considered here. Further work is likely
required to understand the appropriate caching approach for IoT
applications.
o Another challenge in ICN-IoT caching is what to cache for IoT
applications. In many IoT applications, customers often access a
Zhang, et al. Expires September 29, 2017 [Page 25]
Internet-Draft ICN based Architecture for IoT March 2017
stream of sensor data, and as a result, caching a particular
sensor data item may not be beneficial. In [45], the authors
suggest to cache IoT services on intermediate routers, and in
[46], the authors suggest to cache control information such as
pub/sub lists on intermediate nodes. In addition, it is yet
unclear what caching means in the context of actuation in an IoT
system. For example, it could mean caching the result of a
previous actuation request (using other ICN mechanisms to suppress
repeated actuation requests within a given time period), or have
little meaning at all if actuation uses authenticated requests as
in [67].
o Another challenge is that the efficiency of distributed caching
may be application dependent. When content popularity is
heterogeneous, some content is often requested repeatedly. In
that case, the network can benefit from caching. Another case
where caching would be beneficial is when devices with low duty
cycle are present in the network and when access to the cloud
infrastructure is limited. In [68], it is also shown that there
are benefits to caching in the network when edge links are lossy,
in particular if losses occur close to the content producer, as is
common in wireless IoT networks. However, using distributed
caching mechanisms in the network is not useful when each object
is only requested at most once, as a cache hit can only occur for
the second request and later. It may also be less beneficial to
have caches distributed throughout ICN nodes in cases when there
are overlays of distributed repositories, e.g., a cloud or a
Content Distribution Network (CDN), from which all clients can
retrieve the data. Using ICN to retrieve data from such services
may add some efficiency, but in case of dense occurrence of
overlay CDN servers the additional benefit of caching in ICN nodes
would be lower. Another example is when the name refers to an
object with variable content/state. For example, when the last
value for a sensor reading is requested or desired, the returned
data should change every time the sensor reading is updated. In
that case, ICN caching may increase the risk that cache
inconsistencies result in old data being returned.
6.5. Routing and Forwarding
Routing in ICN-IoT differs from routing in traditional IP networks in
that ICN routing is based upon names instead of locators. Broadly
speaking, ICN routing can be categorized into the following two
categories: direct name-based routing and indirect routing using a
name resolution service (NRS).
o In direct name-based routing, packets are forwarded by the name of
the data [69][48][52] or the name of the destination node [53].
Zhang, et al. Expires September 29, 2017 [Page 26]
Internet-Draft ICN based Architecture for IoT March 2017
Here, the main challenge is to keep the ICN router state required
to route/forward data low. This challenge becomes more serious
when a flat naming scheme is used due to the lack of aggregation
capabilities.
o In indirect routing, packets are forwarded based upon the locater
of the destination node, and the locater is obtained through the
name resolution service. In particular, the name-locater binding
can be done either before routing (i.e., static binding) or during
routing (i.e., dynamic binding). For static binding, the router
state is the same as that in traditional routers, and the main
challenge is the need to have fast name resolution, especially
when the IoT nodes are mobile. For dynamic binding, ICN routers
need to main a name-based routing table, hence the challenge of
keeping the state information low. At the same time, the need of
fast name resolution is also critical.
6.6. Mobility Management
Related to this, the challenge is to quantify the cost associated
with mobility management, especially static binding vs. dynamic
binding.
During a network transaction, either the data producer or the
consumer may move away and thus we need to handle the mobility to
avoid information loss. ICN may differentiate mobility of a data
consumer from that of a producer:
o When a consumer moves to a new location after sending out the
request for Data, the Data may get lost, which requires the
consumer to simply resend the request, a technique used by direct
routing approach. Indirect routing approach doesn't differentiate
between consumer and producer mobility [69], also network caching
can improve data recovery for this approach.
o If the data producer itself has moved, the challenge is to control
the control overhead while searching for a new data producer (or
for the same data producer in its new position) [47]. To this
end, flooding techniques could be used, but an intra-domain level
only, otherwise the network stability would be seriously impaired.
6.7. Contextual Communication
Contextualization through metadata in ICN control or application
payload allows IoT applications to adapt to different environments.
This enables intelligent networks which are self-configurable and
enable intelligent networking among consumers and producers [45].
For example, let us look at the following smart transportation
Zhang, et al. Expires September 29, 2017 [Page 27]
Internet-Draft ICN based Architecture for IoT March 2017
scenario: "James walks on NYC streets and wants to find an empty cab
closest to his location." In this example, the context is the
relative locations of James and taxi drivers. A context service, as
an IoT middleware, processes the contextual information and bridges
the gap between raw sensor information and application requirements.
Alternatively, naming conventions could be used to allow applications
to request content in namespaces related to their local context
without requiring a specific service, such as /local/geo/
mgrs/4QFJ/123/678 to retrieve objects published in the 100m grid area
4QFJ 123 678 of the military grid reference system (MGRS). In both
cases, trust providers may emerge that can vouch for an application's
local knowledge.
However, extracting contextual information on a real-time basis is
very challenging:
o We need to have a fast context resolution service through which
the involved IoT devices can continuously update its contextual
information to the application (e.g., each taxi's location and
Jame's information in the above example). Or, in the namespace
driven approach, mechanisms for continuous nearest neighbor
queries in the namespace need to be developed.
o The difficulty of this challenge grows rapidly when the number of
devices involved in a context as well as the number of contexts
increases.
6.8. In-network Computing
In-network computing enables ICN routers to host heterogeneous
services catering to various network functions and applications
needs. Contextual services for IoT networks require in-network
computing, in which each sensor node or ICN router implements context
reasoning [45]. Another major purpose of in-network computing is to
filter and cleanse sensed data in IoT applications, that is critical
as the data is noisy as is [54].
Named Function Networking [84] describes an extension of the ICN
concept to named functions processed in the network, which could be
used to generate data flow processing applications well-suited to,
for example, time series data processing in IoT sensing applications.
Related to this, is the need to support efficient function naming.
Functions, input parameters, and the output result could be
encapsulated in the packet header, the packet body, or mixture of the
two (e.g. [27]). If functions are encapsulated in packet headers,
the naming scheme affects how a computation task is routed in the
network, which IoT devices are involved in the computation task (e.g.
Zhang, et al. Expires September 29, 2017 [Page 28]
Internet-Draft ICN based Architecture for IoT March 2017
[44]), and how a name is decomposed into smaller computation tasks
and deployed in the network for a better performance.
Another is challenge is related to support computing-aware routing.
Normal routing is for forwarding requests to the nearest source or
cache and return the data to the requester, whereas the routing for
in-network computation has a different purpose. If the computation
task is for aggregating sensed data, the routing strategy is to route
the data to achieve a better aggregation performance [41].
In-network computing also includes synchronization challenges. Some
computation tasks may need synchronizations between sub-tasks or IoT
devices, e.g. a device may not send data as soon as it is available
because waiting for data from the neighbours may lead to a better
aggregation result; some devices may choose to sleep to save energy
while waiting for the results from the neighbours; while aggregating
the computation results along the path, the intermediate IoT devices
may need to choose the results generated within a certain time
window.
6.9. Self-Orgnization
General IoT deployments involves heterogeneous IoT systems or
subsystems within a particular scenario. Here scope-based self-
organization is required to ensure logical isolation between the IoT
subsystems, which should be enabled at different levels -- device/
service discovery, naming, topology construction, routing over
logical ICN topologies, and caching [89]. These challenges are
extended to constrained devices as well and they should be energy and
device capability aware. In the infrastructure part, intelligent
name-based routing, caching, in-network computing techniques should
be studied to meet the scope-based self-configuration needs of ICN-
IoT.
6.10. Communications Reliability
ICN offers many ingredients for reliable communication such as multi-
home interest anycast over heterogeneous interfaces, caching, and
forwarding intelligence for multi-path routing leveraging state-
based forwarding in protocols like CCN/NDN. However these features
have not been analyzed from the QoS perspective when heterogeneous
traffic patterns are mixed in a router, in general QoS for ICN is an
open area of research [91]. In-network reliability comes at the cost
of a complex network layer; hence the research challenges here is to
build redundancy and reliability in the network layer to handle a
wide range of disruption scenarios such as congestion, short or long
term disconnection, or last mile wireless impairments. Also an ICN
network should allow features such as opportunistic store and forward
Zhang, et al. Expires September 29, 2017 [Page 29]
Internet-Draft ICN based Architecture for IoT March 2017
mechanism to be enabled only at certain points in the network, as
these mechanisms also entail overheads in the control and forwarding
plane overhead which will adversely affect application throughput.
6.11. Resource Constraints and Heterogeneity
Even though today's IoT devices are becoming increasingly more
powerful, their resource constraints remain a big issue. Many of the
embedded devices still have very limited computation, memory, and
communication capability. Moreover, embedded devices vary greatly in
their capability. As a result, an IoT architecture should take into
consideration these factors. Having globally unique IDs is a key
feature in ICN, which may consist of tens of bytes. Each device
would have a persistent and unique ID no matter when and where it
moves. It is also important for ICN-IoT to keep this feature.
However, always carrying the long ID in the packet header may not be
always feasible over a low-rate layer-2 protocol such as 802.15.4.
To solve this issue, ICN can operate using lighter-weight packet
header and a much shorter locally unique ID (LUID in short). In this
way, we map a device's long global ID to its short LUID when we reach
the local area IoT domain. To cope with collisions that may occur in
this mapping process, we let each domain have its own global ID to
LUID mapping which is managed by a gateway deployed at the edge of
the domain. Different from NAT and other existing domain-based or
gateway-based solutions, ICN-IoT does not change the identity the
application uses. The applications, either on constrained IoT
devices or on the infrastructure nodes, still use the long global IDs
to identify each other, while the network performs translation which
is transparent to these applications. An IoT node carries its global
ID no matter where it moves, even when it is relocated to another
local IoT domain and is assigned with a new LUID. This ensures the
global reach-ability and mobility handling yet still considers
resource constraints of embedded devices.
In addition, the optimizations for other components of the ICN-IoT
system (described in earlier subsections) can lead to optimized
energy efficiency. As a result, we refer the readers to read
sections 6.1-6.9 for challenges associated with energy efficiency for
ICN-IoT.
7. Informative References
[1] Cisco System Inc., CISCO., "Cisco visual networking index:
Global mobile data traffic forecast update.", 2009-2014.
Zhang, et al. Expires September 29, 2017 [Page 30]
Internet-Draft ICN based Architecture for IoT March 2017
[2] Shafig, M., Ji, L., Liu, A., Pang, J., and J. Wang, "A
first look at cellular machine-to-machine traffic: large
scale measurement and characterization.", Proceedings of
the ACM Sigmetrics , 2012.
[3] The European Telecommunications Standards Institute,
ETSI., "http://www.etsi.org/.", 1988.
[4] Global Intiative for M2M Standardization, oneM2M.,
"http://www.onem2m.org/.", 2012.
[5] Constrained RESTful Environments, CoRE.,
"https://datatracker.ietf.org/wg/core/charter/.", 2013.
[6] Ghodsi, A., Shenker, S., Koponen, T., Singla, A.,
Raghavan, B., and J. Wilcox, "Information-Centric
Networking: Seeing the Forest of the Trees.", Hot Topics
in Networking , 2011.
[7] Dong, L., Zhang, Y., and D. Raychaudhuri, "Enhance Content
Broadcast Efficiency in Routers with Integrated Caching.",
Proceedings of the IEEE Symposium on Computers and
Communications (ISCC) , 2011.
[8] NSF FIA project, MobilityFirst.,
"http://www.nets-fia.net/", 2010.
[9] Kim, B., Lee, S., Lee, Y., Hwang, I., and Y. Rhee,
"Mobiiscape: Middleware Support for Scalable Mobility
Pattern Monitoring of Moving Objects in a Large-Scale
City.", Journal of Systems and Software, Elsevier, 2011.
[10] Dietrich, D., Bruckne, D., Zucker, G., and P. Palensky,
"Communication and Computation in Buildings: A Short
Introduction and Overview", IEEE Transactions on
Industrial Electronics, 2010.
[11] Keith, K., Falco, F., and K. Scarfone, "Guide to
Industrial Control Systems (ICS) Security", NIST,
Technical Report 800-82 Revision 1, 2013.
[12] Darianian, M. and Martin. Michael, "Smart home mobile
RFID-based Internet-of-Things systems and services.",
IEEE, ICACTE, 2008.
[13] Zhu, Q., Wang, R., Chen, Q., Chen, Y., and W. Qin, "IOT
Gateway: Bridging Wireless Sensor Networks into Internet
of Things", IEEE/IFIP, EUC, 2010.
Zhang, et al. Expires September 29, 2017 [Page 31]
Internet-Draft ICN based Architecture for IoT March 2017
[14] Biswas, T., Chakrabort, A., Ravindran, R., Zhang, X., and
G. Wang, "Contextualized information-centric home
network", ACM, Sigcomm, 2013.
[15] Huang, R., Zhang, J., Hu, Y., and J. Yang, "Smart Campus:
The Developing Trends of Digital Campus", 2012.
[16] Yan, Y., Qian, Y., Hu, Y., and J. Yang, "A Survey on Smart
Grid Communication Infrastructures: Motivations,
Requirements and Challenges", IEEE Communications Survey
and Tutorials, 2013.
[17] Mael, A., Maheo, Y., and F. Raimbault, "CoAP over BP for a
delay-tolerant internet of things", Future Internet of
Things and Cloud (FiCloud), IEEE, 2015.
[18] Patrice, R. and H. Rivano, "Tests Scenario on DTN for IOT
III Urbanet collaboration", Dissertation, INRIA, 2015.
[19] Kevin, F., "Comparing Information-Centric and Delay-
Tolerant Networking", Local Computer Networks (LCN), 2012
IEEE 37th Conference on. IEEE, 2012..
[20] Miao, Y. and Y. Bu, "Research on the Architecture and Key
Technology of Internet of Things (loT) Applied on Smart
Grid", IEEE, ICAEE, 2010.
[21] Castro, M. and A. Jara, "An analysis of M2M platforms:
challenges and opportunities for the Internet of Things",
IMIS, 2012.
[22] Gubbi, J., Buyya, R., and S. Marusic, "Internet of Things
(IoT): A vision, architectural elements, and future
directions", Future Generation Computer Systems, 2013.
[23] Vandikas, K. and V. Tsiatsis, "Performance Evaluation of
an IoT Platform. In Next Generation Mobile Apps, Services
and Technologies(NGMAST)", Next Generation Mobile Apps,
Services and Technologies (NGMAST), 2014.
[24] Zhang, Y., Yu, R., Nekovee, M., Liu, Y., Xie, S., and S.
Gjessing, "Cognitive Machine-to-Machine Communications:
Visions and Potentials for the Smart Grid", IEEE, Network,
2012.
[25] Zhou, H., Liu, B., and D. Wang, "Design and Research of
Urban Intelligent Transportation System Based on the
Internet of Things", Springer Link, 2012.
Zhang, et al. Expires September 29, 2017 [Page 32]
Internet-Draft ICN based Architecture for IoT March 2017
[26] Alessandrelli, D., Petracca, M., and P. Pagano, "T-Res:
enabling reconfigurable in-network processing in IoT-based
WSNs.", International Conference on Distributed Computing
in Sensor Systems (DCOSS) , 2013.
[27] Kovatsch, M., Mayer, S., and B. Ostermaier, "Moving
application logic from the firmware to the Cloud: towards
the thin server architecture for the internet of things.",
in Proc. 6th Int. Conf. on Innovative Mobile and Internet
Services in Ubiquitous Computing (IMIS) , 2012.
[28] Zhang, M., Yu, T., and G. Zhai, "Smart Transport System
Based on the Internet of Things", Applied Mechanics and
Materials, 2012.
[29] Zhang, A., Yu, R., Nekovee, M., and S. Xie, "The Internet
of Things for Ambient Assisted Living", IEEE, ITNG, 2010.
[30] Savola, R., Abie, H., and M. Sihvonen, "Towards metrics-
driven adaptive security management in E-health IoT
applications.", ACM, BodyNets, 2012.
[31] Jacobson, V., Smetters, D., Plass, M., Stewart, P.,
Thornton, J., and R. Braynard, "VoCCN: Voice-over Content-
Centric Networks", ACM, ReArch, 2009.
[32] Piro, G., Cianci, I., Grieco, L., Boggia, G., and P.
Camarda, "Information Centric Services in Smart Cities",
ACM, Journal of Systems and Software, 2014.
[33] Gaur, A., Scotney, B., Parr, G., and S. McClean, "Smart
City Architecture and its Applications Based on IoT -
Smart City Architecture and its Applications Based on
IoT", Procedia Computer Science, Volume 52, 2015, Pages
1089-1094.
[34] Herrera-Quintero, L., Banse, K., Vega-Alfonso, J., and A.
Venegas-Sanchez, "Smart ITS sensor for the transportation
planning using the IoT and Bigdata approaches to produce
ITS cloud services", 8th Euro American Conference on
Telematics and Information Systems (EATIS), Cartagena,
2016, pp. 1-7.
[35] Melis, A., Pardini, M., Sartori, L., and F. Callegati,
"Public Transportation, IoT, Trust and Urban Habits",
Internet Science: Third International Conference, INSCI
2016, Florence, Italy, September 12-14, 2016, Proceedings.
Zhang, et al. Expires September 29, 2017 [Page 33]
Internet-Draft ICN based Architecture for IoT March 2017
[36] Mavromoustakis, C., Mastorakis, G., and J. Batalla,
"Internet of Things (IoT) in 5G Mobile Technologies",
ISBN,3319309137,Springer.
[37] Masek, P., Masek, J., Frantik, P., and R. Fujdiak, "A
Harmonized Perspective on Transportation Management in
Smart Cities: The Novel IoT-Driven Environment for Road
Traffic Modeling", Sensors, Volume 16, Issue 11, 2016.
[38] Abreu, D., Velasquez, K., Curado, M., and E. Monteiro, "A
resilient Internet of Things architecture for smart
cities", Annals of Telecommunications, Volume 72, Issue 1,
Pages 19-30, 2017.
[39] Ravindran, R., Biswas, T., Zhang, X., Chakrabort, A., and
G. Wang, "Information-centric Networking based Homenet",
IEEE/IFIP, 2013.
[40] Dannewitz, C., D' Ambrosio, M., and V. Vercellone,
"Hierarchical DHT-based name resolution for information-
centric networks", 2013.
[41] Fasoloy, E., Rossiy, M., and M. Zorziy, "In-network
Aggregation Techniques for Wireless Sensor Networks: A
Survey", IEEE Wireless Communications, 2007.
[42] Chai, W., He, D., and I. Psaras, "Cache "less for more" in
information-centric networks", ACM, IFIP, 2012.
[43] Eum, S., Nakauchi, K., Murata, M., Shoji, Yozo., and N.
Nishinaga, "Catt: potential based routing with content
caching for icn", IEEE Communication Magazine, 2012.
[44] Drira, W. and F. Filali, "Catt: An NDN Query Mechanism for
Efficient V2X Data Collection", Eleventh Annual IEEE
International Conference on Sensing, Communication, and
Networking Workshops (SECON Workshops), 2014.
[45] Eum, S., Shvartzshnaider, Y., Francisco, J., Martini, R.,
and D. Raychaudhuri, "Enabling internet-of-things services
in the mobilityfirst future internet architecture", IEEE,
WoWMoM, 2012.
[46] Sun, Y., Qiao, X., Cheng, B., and J. Chen, "A low-delay,
lightweight publish/subscribe architecture for delay-
sensitive IOT services", IEEE, ICWS, 2013.
Zhang, et al. Expires September 29, 2017 [Page 34]
Internet-Draft ICN based Architecture for IoT March 2017
[47] Azgin, A., Ravindran, R., and GQ. Wang, "Mobility study
for Named Data Networking in wireless access networks",
IEEE, ICC, 2014.
[48] Baccelli, E., Mehlis, C., Hahm, O., Schmidt, T., and M.
Wahlisch, "Information Centric Networking in the
IoT:Experiments with NDN in the Wild", ACM, ICN Siggcomm,
2014.
[49] Gronbaek, I., "Architecture for the Internet of Things
(IoT): API and interconnect", IEEE, SENSORCOMM, 2008.
[50] Tian, Y., Liu, Y., Yan, Z., Wu, S., and H. Li, "RNS-A
Public Resource Name Service Platform for the Internet of
Things", IEEE, GreenCom, 2012.
[51] Roussos, G. and P. Chartier, "Scalable id/locator
resolution for the iot", IEEE, iThings,CPSCom, 2011.
[52] Amadeo, M. and C. Campolo, "Potential of information-
centric wireless sensor and actuator networking", IEEE,
ComManTel, 2013.
[53] Nelson, S., Bhanage, G., and D. Raychaudhuri, "GSTAR:
generalized storage-aware routing for mobilityfirst in the
future mobile internet", ACM, MobiArch, 2011.
[54] Trappe, W., Zhang, Y., and B. Nath, "MIAMI: methods and
infrastructure for the assurance of measurement
information", ACM, DMSN, 2005.
[55] Rouf, I., Mustafa, H., Taylor, T., Oh, S., Xu, W.,
Gruteser, M., Trappe, W., and I. Seskar, "Security and
privacy vulnerabilities of in-car wireless networks: A
tire pressure monitoring system case study", USENIX, 2010.
[56] Liu, R. and W. Trappe, "Securing Wireless Communications
at the Physical Layer", Springer, 2010.
[57] Xiao, L., Greenstein, L., Mandayam, N., and W. Trappe,
"Using the physical layer for wireless authentication in
time-variant channels", IEEE Transactions on Wireless
Communications, 2008.
[58] Sun, S., Lannom, L., and B. Boesch, "Handle system
overview", IETF, RFC3650, 2003.
Zhang, et al. Expires September 29, 2017 [Page 35]
Internet-Draft ICN based Architecture for IoT March 2017
[59] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained
Application Protocol (CoAP)", RFC 7252,
DOI 10.17487/RFC7252, June 2014,
<http://www.rfc-editor.org/info/rfc7252>.
[60] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
Protocol (HTTP/1.1): Message Syntax and Routing",
RFC 7230, DOI 10.17487/RFC7230, June 2014,
<http://www.rfc-editor.org/info/rfc7230>.
[61] Barnes, R., "Use Cases and Requirements for JSON Object
Signing and Encryption (JOSE)", RFC 7165,
DOI 10.17487/RFC7165, April 2014,
<http://www.rfc-editor.org/info/rfc7165>.
[62] Sun, S., "Hypertext Transfer Protocol (HTTP/1.1): Message
Syntax and Routing", 2014.
[63] Liu, X., Trappe, W., and Y. Zhang, "Secure Name Resolution
for Identifier-to-Locator Mappings in the Global
Internet", IEEE, ICCCN, 2013.
[64] Boguna, M., Fragkiskos, P., and K. Dmitri, "Sustaining the
internet with hyperbolic mapping", Nature Communications,
2010.
[65] Shang, W., "Securing building management systems using
named data networking", IEEE Network 2014.
[66] Fayazbakhsh, S. and et. et al, "Less pain, most of the
gain: Incrementally deployable icn", ACM, Siggcomm, 2013.
[67] Burke, J. and et. et al, "Securing instrumented
environments over Content-Centric Networking: the case of
lighting control", INFOCOM, Computer Communications
Workshop, 2013.
[68] Rao, A., Schelen, O., and A. Lindgren, "Performance
Implications for IoT over Information Centric Networks",
Performance Implications for IoT over Information Centric
Networks, ACM CHANTS 2016.
[69] Li, S., Zhang, Y., Dipankar, R., and R. Ravindran, "A
comparative study of MobilityFirst and NDN based ICN-IoT
architectures", IEEE, QShine, 2014.
Zhang, et al. Expires September 29, 2017 [Page 36]
Internet-Draft ICN based Architecture for IoT March 2017
[70] Chen, J., Li, S., Yu, H., Zhang, Y., and R. Ravindran,
"Exploiting icn for realizing service-oriented
communication in iot", IEEE, Communication Magazine, 2016.
[71] Quevedo, J., Corujo, D., and R. Aguiar, "A Case for ICN
usage in IoT environments", Global Communications
Conference GLOBECOM, IEEE, Dec 2014, Pages 2770-2775.
[72] Lindgren, A., Ben Abdesslem, F., Ahlgren, B., and O.
Schelen, "Design Choices for the IoT in Information-
Centric Networks", IEEE Annual Consumer Communications and
Networking Conference (CCNC) 2016.
[73] Grieco, L., Alaya, M., and K. Drira, "Architecting
Information Centric ETSI-M2M systems", IEEE, Pervasive and
Computer Communications Workshop (PERCOM), 2014.
[74] Grieco, L., Rizzo, A., Colucci, R., Sicari, S., Piro, G.,
Di Paola, D., and G. Boggia, "IoT-aided robotics
applications: technological implications, target domains
and open issues", Elsevier Computer Communications, Volume
54, 1 December, 2014.
[75] InterDigital, WhitePaper., "Standardized M2M Software
Development Platform", 2011.
[76] Boswarthick, D., "M2M Communications: A Systems Approach",
2012.
[77] Swetina, J., Lu, G., Jacobs, P., Ennesser, F., and J.
Song, "Toward a standardized common M2M service layer
platform: Introduction to oneM2M", IEEE Wireless
Communications, Volume 21, Number 3, June 2014.
[78] Quan, Wei., Xu, C., Guan, J., Zhang, H., and L. Grieco,
"Scalable Name Lookup with Adaptive Prefix Bloom Filter
for Named Data Networking", IEEE Communications Letters,
2014.
[79] Wang, Yi., Pan, T., Mi, Z., Dai, H., Guo, X., Zhang, T.,
Liu, B., and Q. Dong, "NameFilter: Achieving fast name
lookup with low memory cost via applying two-stage Bloom
filters", INFOCOM, 2013.
[80] So, W., Narayanan, A., Oran, D., and Y. Wang, "Toward fast
NDN software forwarding lookup engine based on Hash
tables", ACM, ANCS, 2012.
Zhang, et al. Expires September 29, 2017 [Page 37]
Internet-Draft ICN based Architecture for IoT March 2017
[81] Amadeo, M., Campolo, C., Iera, A., and A. Molinaro, "Named
data networking for IoT: An architectural perspective",
IEEE, EuCNC, 2014.
[82] Amadeo, M., Campolo, C., Iera, A., and A. Molinaro,
"Information centric networking in iot scenarios: The case
of a smart home", IEEE ICC, June 2015.
[83] Blefari Melazzi, N., Detti, A., Arumaithurai, M., and K.
Ramakrishnan, "Internames: A name-to-name principle for
the future internet", QShine, August 2014.
[84] Sifalakis, M., Kohler, B., Christopher, C., and C.
Tschudin, "An information centric network for computing
the distribution of computations", ACM, ICN Sigcomm, 2014.
[85] Lu, R., Lin, X., Zhu, H., and X. Shen, "SPARK: a new
VANET-based smart parking scheme for large parking lots",
INFOCOM, 2009.
[86] Wang, H. and W. He, "A reservation-based smart parking
system", The First International Workshop on Cyber-
Physical Networking Systems, 2011.
[87] Qian, L., "Constructing Smart Campus Based on the Cloud
Computing and the Internet of Things", Computer Science
2011.
[88] Project, BonVoyage., "European Unions - Horizon 2020,
http://bonvoyage2020.eu/", 2016.
[89] Li, S., Zhang, Y., Raychaudhuri, D., Ravindran, R., Zheng,
Q., Wang, GQ., and L. Dong, "IoT Middleware over
Information-Centric Network", Global Communications
Conference (GLOBECOM) ICN Workshop, 2015.
[90] Li, S., Chen, J., Yu, H., Zhang, Y., Raychaudhuri, D.,
Ravindran, R., Gao, H., Dong, L., Wang, GQ., and H. Liu,
"MF-IoT: A MobilityFirst-Based Internet of Things
Architecture with Global Reachability and Communication
Diversity", IEEE International Conference on Internet-of-
Things Design and Implementation (IoTDI), 2016.
[91] Campolo, C., Corujo, D., Iera, A., and R. Aguiar,
"Information-centric Networking for Internet-of-things:
Challenges and Opportunities", IEEE Networks, Jan , 2015.
Zhang, et al. Expires September 29, 2017 [Page 38]
Internet-Draft ICN based Architecture for IoT March 2017
Authors' Addresses
Prof.Yanyong Zhang
WINLAB, Rutgers University
671, U.S 1
North Brunswick, NJ 08902
USA
Email: yyzhang@winlab.rutgers.edu
Prof. Dipankar Raychadhuri
WINLAB, Rutgers University
671, U.S 1
North Brunswick, NJ 08902
USA
Email: ray@winlab.rutgers.edu
Prof. Luigi Alfredo Grieco
Politecnico di Bari (DEI)
Via Orabona 4
Bari 70125
Italy
Email: alfredo.grieco@poliba.it
Prof. Emmanuel Baccelli
INRIA
Room 148, Takustrasse 9
Berlin 14195
France
Email: Emmanuel.Baccelli@inria.fr
Jeff Burke
UCLA REMAP
102 East Melnitz Hall
Los Angeles, CA 90095
USA
Email: jburke@ucla.edu
Zhang, et al. Expires September 29, 2017 [Page 39]
Internet-Draft ICN based Architecture for IoT March 2017
Ravishankar Ravindran
Huawei Technologies
2330 Central Expressway
Santa Clara, CA 95050
USA
Email: ravi.ravindran@huawei.com
Guoqiang Wang
Huawei Technologies
2330 Central Expressway
Santa Clara, CA 95050
USA
Email: gq.wang@huawei.com
Andres Lindgren
RISE SICS
Box 1263
Kista SE-164 29
SE
Email: andersl@sics.se
Bengt Ahlgren
RISE SICS
Box 1263
Kista, CA SE-164 29
SE
Email: bengta@sics.se
Olov Schelen
Lulea University of Technology
Lulea SE-971 87
SE
Email: lov.schelen@ltu.se
Zhang, et al. Expires September 29, 2017 [Page 40]