ICN based Architecture for IoT - Requirements and Challenges
draft-zhang-iot-icn-challenges-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 "Expired".
|
|
|---|---|---|---|
| Authors | Yanyong Zhang , Dipankar Raychadhuri , Luigi Alfredo Grieco , Emmanuel Baccelli , Jeff Burke , Ravi Ravindran , Guoqiang Wang | ||
| Last updated | 2014-09-22 | ||
| RFC stream | (None) | ||
| Formats | |||
| 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-iot-icn-challenges-00
ICN Research Group Y. Zhang
Internet-Draft D. Raychadhuri
Intended status: Informational WINLAB, Rutgers University
Expires: March 26, 2015 L. Grieco
Politecnico di Bari (DEI)
E. Baccelli
INRIA
J. Burke
UCLA REMAP
R. Ravindran (Ed)
G. Wang
Huawei Technologies
September 22, 2014
ICN based Architecture for IoT - Requirements and Challenges
draft-zhang-iot-icn-challenges-00
Abstract
The Internet of Things (IoT) promises to connect billions of objects
to 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 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 a unified IoT platform as an overlay on top
of today's Internet. Such overlay solutions, however, are inadequate
to address the important challenges posed by a heterogeneous, global
scale deployment of IoT, especially in terms of mobility,
scalability, and communication reliability, due to the inherent
inefficiencies of the current Internet. To address this problem, 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 seamless mobility support,
scalability, and efficient content and service delivery.
This draft sets the IoT requirements and ICN challenges to realize a
unified ICN-IoT framework. Towards this, we first identify a list of
important requirements which a unified IoT architecture should have
to support tens of billions of objects. Then we analyze the current
state of art deployment model and discuss important and popular IoT
scenarios including the "smart" home, campus, grid, transportation
infrastructure, healthcare, Education, and Entertainment. Though we
see most of these requirements are met by ICN, we discuss specific
challenges ICN has to address to satisfy them considering
heterogeneity in IoT environments and scenarios.
Zhang, et al. Expires March 26, 2015 [Page 1]
Internet-Draft ICN based Architecture for IoT September 2014
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 March 26, 2015.
Copyright Notice
Copyright (c) 2014 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. IoT Architectural Requirements . . . . . . . . . . . . . . . 4
2.1. Naming . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.2. Scalability . . . . . . . . . . . . . . . . . . . . . . . 4
2.3. Resource Constraints . . . . . . . . . . . . . . . . . . 4
2.4. Traffic Characteristics . . . . . . . . . . . . . . . . . 5
2.5. Contextual Communication . . . . . . . . . . . . . . . . 5
2.6. Handling Mobility . . . . . . . . . . . . . . . . . . . . 6
2.7. Storage and Caching . . . . . . . . . . . . . . . . . . . 6
2.8. Security and Privacy . . . . . . . . . . . . . . . . . . 7
2.9. Communication Reliability . . . . . . . . . . . . . . . . 7
2.10. Self-Organization . . . . . . . . . . . . . . . . . . . . 7
2.11. Ad hoc and Infrastructure Mode . . . . . . . . . . . . . 8
2.12. Open API . . . . . . . . . . . . . . . . . . . . . . . . 8
Zhang, et al. Expires March 26, 2015 [Page 2]
Internet-Draft ICN based Architecture for IoT September 2014
3. State of the Art . . . . . . . . . . . . . . . . . . . . . . 8
3.1. Silo IoT Architecture . . . . . . . . . . . . . . . . . . 9
3.2. Overlay Based Unified IoT Solutions . . . . . . . . . . . 9
3.2.1. Weaknesses of the Overlay-based Approach . . . . . . 10
4. Popular Scenarios . . . . . . . . . . . . . . . . . . . . . . 11
4.1. Homes . . . . . . . . . . . . . . . . . . . . . . . . . . 12
4.2. Enterprise . . . . . . . . . . . . . . . . . . . . . . . 12
4.3. Smart Grid . . . . . . . . . . . . . . . . . . . . . . . 13
4.4. Transportation . . . . . . . . . . . . . . . . . . . . . 13
4.5. Healthcare . . . . . . . . . . . . . . . . . . . . . . . 14
4.6. Education . . . . . . . . . . . . . . . . . . . . . . . . 15
4.7. Entertainment, arts, and culture . . . . . . . . . . . . 15
5. ICN Challenges for IoT . . . . . . . . . . . . . . . . . . . 16
5.1. Naming . . . . . . . . . . . . . . . . . . . . . . . . . 16
5.2. Caching/Storage . . . . . . . . . . . . . . . . . . . . . 17
5.3. Name Resolution . . . . . . . . . . . . . . . . . . . . . 17
5.4. Contextual Communication . . . . . . . . . . . . . . . . 18
5.5. Routing and Forwarding . . . . . . . . . . . . . . . . . 18
5.6. In-network Computing . . . . . . . . . . . . . . . . . . 19
5.7. Security and Privacy . . . . . . . . . . . . . . . . . . 20
5.8. Energy Efficiency . . . . . . . . . . . . . . . . . . . . 21
6. Informative References . . . . . . . . . . . . . . . . . . . 21
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 25
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 begin by
presenting IoT architectural requirements, then summarize how state-
of-art approaches address these requirements. We then discuss well
known IoT scenarios focusing on their unique challenges. The final
discussion focuses on IoT challenges from an ICN perspective and
requirements posed towards its design.
Zhang, et al. Expires March 26, 2015 [Page 3]
Internet-Draft ICN based Architecture for IoT September 2014
2. 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.
2.1. Naming
The first step towards realizing a unified IoT platform is the
ability to assign names that are unique within the scope and lifetime
of 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 (within one or more
contexts) against dynamic features that are common in IoT systems,
such as mobility or migration; Second, names need to be secure based
on application requirements.
2.2. 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 spanning 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
insert/update/look up a name within a short latency. To satisfy this
requirement, decentralization of the name resolution can be the the
key.
2.3. Resource Constraints
IoT devices can be broadly classified into two groups: resource-
sufficient and resource-constrained. In general, there are the
following types of resources: power, computing, storage, and
bandwidth.
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 at opportunistic points, example at
Zhang, et al. Expires March 26, 2015 [Page 4]
Internet-Draft ICN based Architecture for IoT September 2014
the network edge, hence it is important to balance local computation
versus communication cost.
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 from 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 communicate with every 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.
2.4. 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,
commuters can find out real-time traffic and road information and
then decide which commuting route to take. 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.
2.5. Contextual Communication
Many IoT applications shall rely on contextual information such as
social, grouping, location, type of ecosystem (home, grid, transport
etc.) of devices and data (which are referred to as contexts in this
document) to initiate dynamic relationship and communication. For
Zhang, et al. Expires March 26, 2015 [Page 5]
Internet-Draft ICN based Architecture for IoT September 2014
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.
2.6. Handling Mobility
There are varying 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; 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 acceptable delay constraint in all of the above
cases.
2.7. Storage and Caching
Storage and caching plays a very significant role depending on the
type of IoT ecosystem with the fact that data generated is also
subjected to privacy and security guidelines. In a unified IoT
platform, depending on application requirements, content caching may
or may not be policy driven though the latter would be a more common
scenario. 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
applications. This optimization can greatly reduce the content
access latencies.
Further, ICN architectures enable a more flexible, heterogeneous and
potentially fault-tolerant approach to storage, that provides
persistence at a variety of levels in a hierarchical network of
devices.
Zhang, et al. Expires March 26, 2015 [Page 6]
Internet-Draft ICN based Architecture for IoT September 2014
In network storage and caching, however, has the following
requirements on the IoT platform. The platform needs to support the
efficient resolution of cached copies. Further the platform should
strive for the balance between caching, content security/privacy, and
regulations.
2.8. 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 [12].
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
will be driven by various stake holders such as industry, government,
consumers etc.
2.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. Reliable communication
requires the following capabilities for the underlying system: (1)
seamless mobility support in the face of extreme disruptions (DTN),
(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, etc.).
2.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 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-
Zhang, et al. Expires March 26, 2015 [Page 7]
Internet-Draft ICN based Architecture for IoT September 2014
network caching, name-based routing, etc. In the latter case, the
IoT platform needs to discover the private community groups/clusters
efficiently.
2.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 be able to provide: (1)
energy-efficient topology discovery and data forwarding in the ad-hoc
mode, and (2) scalable name resolution in the infrastructure mode.
2.12. Open API
General IoT applications involve sensing, processing, and secure
content distribution occuring at various timescales depending on the
application requirements. This requires open APIs to be generic
enough to support Pull, Push, and support Pub/Sub mode of interaction
between consumers, content producer, and IoT services, as opposed to
proprietary APIs that are common in today's systems.
3. 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, 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 [9] hinders the platform from
satisfying the IoT requirements outlined earlier (particularly in
terms of scalability, security, mobility, and self-organization)
Zhang, et al. Expires March 26, 2015 [Page 8]
Internet-Draft ICN based Architecture for IoT September 2014
3.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.)
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.
3.2. Overlay Based 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 as an overlay, this is the most practical
approach towards a unified IoT platform. There are ongoing
standardization efforts including ETSI[3], oneM2M[4],and CORE[5].
Network operators can use standard API to build common IOT gateways
and servers for their customers. Figure 2 shows the architecture
adopted in this approach.
Zhang, et al. Expires March 26, 2015 [Page 9]
Internet-Draft ICN based Architecture for IoT September 2014
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
3.2.1. Weaknesses of the Overlay-based Approach
The above overlay-based approach can work with many different
protocols, but the system is not designed in a holistic manner to
inter-connect heterogeneous devices, services and infrastructure.
Another limiting factor is that it 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 overlays for IoT systems the naming scheme is
host centric, i.e., the name of a given resource/service is linked
to the one of 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 Trust. Trust management schemes are still relatively weak,
focusing on securing communication channels rather than managing
the data that needs to be secured directly.
o Scalability. The overlay-based 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
Zhang, et al. Expires March 26, 2015 [Page 10]
Internet-Draft ICN based Architecture for IoT September 2014
required to deploy current IoT solutions limit the scalability and
management of these systems.
o Resource constraints. The overlay-based approach requires every
device to send data to an aggregator or to the IoT server.
Resource constraints of the IoT devices, especially in power and
bandwidth, will 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 support for multicasting that is
challenging the underlying for overlay systems today.
o Contextual Communications. This overlay-based approach cannot
react to dynamic contextual changes in a timely fashion. The main
reason is that context lists are kept at the IoT server in this
approach, and they cannot help efficiently route requests/
information at the network layer.
o Mobility. The overlay-based approach cannot seamlessly support
device mobility in terms of maintaining the session between data
producers and consumers. In this approach, lower-level
communications are typically IP driven, which is inefficient for
mobility support.
o Storage and Caching. The overlay-based approach supports
application-centric storage and caching but not what ICN envisions
at the network layer, or flexible storage enabled via name-based
routing.
o Self-Organization. The overlay-based approach is topology-based
as it is bound to IP semantics, and thus does not sufficiently
satisfy the self-organization requirement.
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.
4. Popular Scenarios
Several types of IoT applications exists, where the goal is efficient
and secure management and communication among objects in the system
and with the physical world through sensors, RFIDs and other devices.
Below we list a few popular IoT applications. We omit the often used
term "smart", though it applies to each IoT scenario below, and posit
that IoT-style interconnection of devices to make these environments
"smart" in today's terms will simply be the future norm.
Zhang, et al. Expires March 26, 2015 [Page 11]
Internet-Draft ICN based Architecture for IoT September 2014
4.1. Homes
The home [11] is a complex ecosystem of IoT devices and applications
including climate control, home security monitoring, smoke detection,
electrical metering, health/wellness, and entertainment systems. In
a unified IoT platform, we would inter-connect these systems through
the Internet, such that they can interact with each other and make
decisions at an aggregated level. Also, the systems can be accessed
and manipulated remotely. Challenges in the home include topology
independent service discovery, common protocol for heterogeneous
device/application/service interaction, policy based routing/
forwarding, service mobility as well as privacy protection. Notably,
the ease-of-use expectations and training of both users and
installers also presents challenges in user interface and user
experience design that are impacted by the complexity of network
configuration, brittleness to change, configuration of trust
management, etc. Finally, it is unlikely that there will be a single
"home system", but rather a collection of moderately inter-operable
collaborating devices.
Homes [13][14] faces the following challenges that are hard to
address with IP-based overlay solutions: (1) context-aware control:
home systems must make decisions (e.g., on how to control, when to
collect data, where to carry out computation, when to interact with
end-users, etc.) based upon the contextual information [15]; (2)
inter-operatibility: home systems must operate with devices that
adopt heterogeneous naming, trust, communication, and control
systems; (3) mobility: home systems must deal with mobility caused by
the movement of sensors or data receivers; (4) security: a home
systems must be able to deal with foreign devices, handle a variety
of user permissions (occupants of various types, guests, device
manufacturers, installers and integrators, utility and infrastructure
providers) and involve users in important security decisions without
overwhelming them.
4.2. Enterprise
Enterprise building deployments, from university campuses [16] to
industrial facilities and retail complexes, drive an additional set
of scalability, security, and integration requirements beyond the
home, while requiring much of its ease of use and flexibility.
Additionally, they bring requirements for integration with business
IT systems, though often with the additional support of in-house
engineering support.
Increasing number of enterprises are equipped with sensing and
communication devices inside buildings, laboratories, and plants, at
stadiums, in parking lots, on school buses, etc. A unified IoT
Zhang, et al. Expires March 26, 2015 [Page 12]
Internet-Draft ICN based Architecture for IoT September 2014
platform must integrate many aspects of human interaction, H2M and
M2M communication, within the enterprise, and thus enable many IoT
applications that can benefit a large body of enterprise affiliates.
The challenges in smart enterprise include efficient and secure
device/data/resource discovery, inter-operability between different
control systems, throughput scaling with number of devices, and
unreliable communication due to mobility and telepresence.
Enterprises face the following challenges that are hard to address
with IP-based overlay solutions: (1) efficient device/data/ resource
discovery: enterprise devices must be able to quickly and securely
discover requested device, data, or resources; (2) scalability: a
enterprise system must be able to scale efficiently with the number
and type of sensors and devices across not only a single building but
multi-national corporations (for example); (3) mobility: a enterprise
system must be able to deal with mobility caused by movement of
devices.
4.3. Smart Grid
Central to the so-called "smart grid"[17] is data flow and
information management, achieved by using sensors and actuators,
which enables important capabilities such as substation and
distribution automation. In a unified IoT platform, data collected
from different smart grids can be integrated to reach more
significant optimizations. The challenges for smart grid include
reliability, real-time control, secure communications, and data
privacy.
Deployment of the smart grid [18] [19] faces the following issues
that are hard to address with IP-based overlay solutions: (1)
scalability: tomorrow's 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.
4.4. Transportation
We are currently witnessing the increasing integration of sensors
into cars, other vehicles transportation systems [20]. Current
production cars already carry many sensors ranging from rain gauges
and accelerometers over wheel rotation/traction sensors, to cameras.
While intended for internal vehicle functions, these could also be
networked and leveraged for applications such as monitoring external
Zhang, et al. Expires March 26, 2015 [Page 13]
Internet-Draft ICN based Architecture for IoT September 2014
traffic/road conditions. Further, we can build vehicle-to-
infrastructure (V2I) and vehicle-to-vehicle (V2V) communications that
enable many more applications for safety, convenience, entertainment,
etc. The challenges for transportation include fast data/device/
service discovery and association, efficient communications with
mobility, trustworthy data collection and exchange.
Transportation [20][21] faces the following challenges that are hard
to address with IP-based overlay solutions: (1) mobility: a
transportation system must deal with a large number of mobile nodes
interacting through a combination of infrastructure and ad hoc
communication methods; (2) real-time and reliability: transportation
systems must be able to operate on real-time and remain resilient in
the presence of failures; (3) in-network computing/filtering:
transportation systems will benefit from in-network computing/
filtering as such operations can reduce the end-to-end latency; (4)
inter-operatibility: transportation systems must operate with
heterogeneous device and protocols; (5) security: transportation
systems must be resilient to malicious physical and cyber attacks.
4.5. Healthcare
As more embedded medical devices, or devices that can monitor human
health become increasingly deployed, healthcare is becoming a viable
alternative to traditional healthcare solutions [15][22]. Further,
consumer applications for managing and interacting with health data
are a burgeoning area of research and commercial applications. For
future health applications, a unified IoT platform is critical for
improved patient care and consumer health support by sharing data
across systems, enabling timely actuations, and lowering the time to
innovation by simplifying interaction across devices from many
manufacturers. Challenges in healthcare include real-time
interactions, high reliability, short communication latencies,
trustworthy, security and privacy, and well as defining and meeting
the regulatory requirements that should impact new devices and their
interconnection.
Healthcare [22][23] faces the following challenges that are hard to
address with IP-based overlay solutions: (1) real-time and
reliability: healthcare systems must be able to operate on real-time
and remain resilient in the presence of failures; (2) inter-
operatibility: healthcare systems must operate with heterogeneous
device and protocols; (3) security: healthcare systems must be
resilient to malicious physical and cyber attacks and meet the
regulatory requirement for data security and interoperability.
Zhang, et al. Expires March 26, 2015 [Page 14]
Internet-Draft ICN based Architecture for IoT September 2014
4.6. Education
IoT technologies enable the instrumentation of a variety of
environments (from greenhouses to industrial plants, homes and
vehicles) to support not only their everyday operation but an
understanding of how they operate -- a fundamental contribution to
education. The diverse uses of hobbyist-oriented microcontroller
platforms (e.g., the Arduino) and embedded systems (e.g., the
Raspberry PI) point to a burgeoning community that should be
supported by the next generation IoT platform because of its
fundamental importance to formal and informal education.
Educational uses of IoT deployments include both learning about the
operation of the system itself as well as the systems being observed
and controlled. Such deployments face the following challenges that
are hard to address with IP-based overlay solutions: (1) relatively
simple communications patterns are obscured by many layers of
translation from the host-based addressing of IP (and layer 2
configuration below) to the name-oriented interfaces provided by
developers; (2) security considerations with overlay deployments and
channel-based limit access to systems where read-only use of data is
not a security risk; (3) real-time communication helps make the
relationship between physical phenomena and network messages easier
to understand in many simple cases; (4) integration of devices from a
variety of sources and manufacturers is currently quite difficult
because of varying standards for basic communication, and limits
experimentation.
4.7. Entertainment, arts, and culture
IoT technologies can contribute uniquely to both the worldwide
entertainment market and the fundamental human activity of creating
and sharing art and culture. By supporting new types of human-
computer interaction, IoT can enable new gaming, film/video, and
other "content" experiences, integrating them with, for example, the
lighting control of the smart home, presentation systems of the smart
enterprise, or even the incentive mechanisms of smart healthcare
systems (to, say, encourage and measure physical activity).
Entertainment, arts, and culture applications generate a variety of
challenges for IoT: (1) notably, the ability to securely "repurpose"
deployed smart systems (e.g., lighting) to create experiences; (2)
low-latency communication to enable end-user responsiveness; (3)
integration with infrastructure-based sensing (e.g., computer vision)
to create comprehensive interactive environments or to provide user
identity information; (4) time synchronization with audio/video
playback and rendering in 3D systems (5) simplicity of development
and experimentation, to enable the cost- and time-efficient
Zhang, et al. Expires March 26, 2015 [Page 15]
Internet-Draft ICN based Architecture for IoT September 2014
integration of IoT into experiences being designed without expert
engineers of IoT systems; (6) security, because of integration with
personal devices and smart environments, as well as billing systems.
5. ICN Challenges for IoT
ICN integrates content/service/host abstraction, name-based routing,
compute, caching/storage as part of the network infrastructure
connecting consumers and services which meets most of the
requirements discussed above; however IoT requires special
considerations given heterogeneity of devices and interfaces such as
for constrained networking [32], data processing, and content
distribution models to meet specific application requirements which
we identify as challenges in this section.
5.1. Naming
According to [27], the main requirement of a name space (and the
corresponding Name Resolution System) are:
o Scalability: with the IoT the number of data items would inflate
the Internet scale up to 2-3 order of magnitudes, thus making
scalability a primary requirement of the NRS. Notice that, if
hierarchical names are used, scalability can be also faced by
leveraging the inherent aggregation capabilities of the hierarchy.
o Latency: for real-time or delay sensitive M2M application, the
name resolution should not affect the overall QoS.
o Locality and network efficiency: in the name resolution process
the data items closer to the data consumer should be accesses
first (subject to the application requirements)
o Agility: some data items could disappear while some other ones are
created so that the NRS should be able to effectively take care of
these dynamic conditions.
o Control/scoping: some information could be accessible only within
a given scope so that the NRS shold be able to not disclose all
nodel locators to everyone.
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].
Further challenges arise for hierarchical naming schema: referring to
requirements on "constructable names" and "on-demand publishing" [24]
[25]. The former entails that each user is able to construct the
Zhang, et al. Expires March 26, 2015 [Page 16]
Internet-Draft ICN based Architecture for IoT September 2014
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.
5.2. 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 constrained networks is limited to small amounts
in the order of 10KB, while caching in infrastructure part of the
network can allow much larger chunks.
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 [28], 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 [29], selecting a
random router to cache data is as good as caching the content
everywhere.
o Another challenge in ICN-IoT caching is what to cache for IoT
applications. In many IoT applications, customers often access a
stream of sensor data, and as a result, caching a particular
sensor data item may not be beneficial. In [30], the authors
suggest to cache IoT services on intermediate routers, and in
[31], 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.
5.3. 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
[1-4][33][34][35][30]. The objective is to achieve scalable name
resolution handling static and dynamic ICN entities with low
complexity and control overhead.
o The first challenge faced by ICN-IoT name resolution is its
scalability [35][30]. Firstly, the name resolution service has to
support billions of objects and devices that are connected to the
Internet, many of which are crossing administrative domain
Zhang, et al. Expires March 26, 2015 [Page 17]
Internet-Draft ICN based Architecture for IoT September 2014
boundaries. Second of all, in addition to objects/devices, the
name resolution service 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
[30]. As a result, the name resolution service 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.)
o The second challenge is fast name resolution. This challenge is
especially important for applications with stringent latency
requirements, such as health monitoring, emergency handling and
smart transportation [36].
5.4. 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 [30].
For example, let us look at the following smart transportation
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.
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).
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.
5.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 through
name resolution.
Zhang, et al. Expires March 26, 2015 [Page 18]
Internet-Draft ICN based Architecture for IoT September 2014
o In direct name-based routing, packets are forwarded by the name of
the data [37][32][38] or the name of the destination node [39].
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.
o In indirect routing, packets are forwarded based upon the locator
of the destination node, and the locator is obtained through the
name resolution service. In particular, the name locator 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. Finally, another 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 an
Interest, the Data may get lost, which requires the consumer to
simply resend the Interest. Depending on the network topology and
data availability, the new Interest might be forwarded to the same
or a different data producer.
o If the data producer itself has moved, the challenge is to control
the control overhead while flooding it across the network.
5.6. In-network Computing
Contextual services for IoT networks require in-network computing, in
which each sensor node or ICN router implements context reasoning
[30]. Another major purpose of in-network computing is to filer and
cleanse sensed data in IoT applications is critical as the data is
noisy as is [40].
In-network computing faces different challenges in the constrained
and infrastructure parts of the network.
o In the constrained part of the network, the challenge rises due to
serious resource limitations on IoT devices or sensors. As a
Zhang, et al. Expires March 26, 2015 [Page 19]
Internet-Draft ICN based Architecture for IoT September 2014
result, the consensus is to include very simple computing
functionalities on constrained nodes.
o In the infrastructure part of the IoT network, in-network
computing faces the challenge of breaking the computing task into
smaller pieces and assigning each task to one or more ICN routers
[30].
5.7. Security and Privacy
Security and privacy is crucial to all the IoT applications including
the use cases discussed in Section 4. 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 [41]. Though
ICN includes data-centric security features the mechanisms have to be
generic enough to satisfy multiplicity of policy requirements for
different applications. 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 constrained part, energy limitation is the biggest
challenge. As an example, let us look at a typical sensor tag.
Suppose the tag has a single 16-bit processor, often running at 6
MHz to save energy, with 512Bytes of RAM and 16KB of flash for
program storage. Moreover, it has to deliver its data over a
wireless link for at least 10,000 hours 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 [42] [30].
o In the infrastructure part, we have several new threats introduced
by ICN-IoT [45]:
1. We need to ensure the name of a network element is issued by a
trustworthy organization such as in [44].
2. An intruder may gain access or gather information from a
resource it is not entitled to. As a consequence, an
adversary may examine, remove or even modify confidential
information.
Zhang, et al. Expires March 26, 2015 [Page 20]
Internet-Draft ICN based Architecture for IoT September 2014
3. An intruder may mimic an authorized user or network process.
As a result, the intruder may forge signatures, or impersonate
a source address.
4. An adversary may manipulate the message exchange process
between network entities. Such manipulation may involve
replay, rerouting, mis-routing and deletion of messages.
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.
5.8. Energy Efficiency
All 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
5.1-5.6 for challenges associated with energy efficiency for ICN-IoT.
6. Informative References
[1] Cisco System Inc., CISCO., "Cisco visual networking index:
Global mobile data traffic forecast update.", 2009-2014.
[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] Melazzi, N., Detti, A., Arumaithurai, M., and K.
Ramakrishnan, "Internames: A Name-to-Name Principle for
the Future Internet.", International Workshop on Quality,
Reliability, and Security in Information-Centric
Networking (Q-ICN) , 2014.
Zhang, et al. Expires March 26, 2015 [Page 21]
Internet-Draft ICN based Architecture for IoT September 2014
[8] 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.
[9] FIA project, NSF., "http://www.nets-fia.net/", 2010.
[10] 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.", 2011.
[11] Dietrich, D., Bruckne, D., Zucker, G., and P. Palensky,
"Communication and Computation in Buildings: A Short
Introduction and Overview", 2010.
[12] Keith, K., Falco, F., and K. Scarfone, "Guide to
Industrial Control Systems (ICS) Security. Technical
Report 800-82 Revision 1", 2013.
[13] Darianian, M. and Martin. Michael, "Smart home mobile
RFID-based Internet-of-Things systems and services.",
2008.
[14] Zhu, Q., Wang, R., Chen, Q., Chen, Y., and W. Qin, "IOT
Gateway: Bridging Wireless Sensor Networks into Internet
of Things", 2010.
[15] Biswas, T., Chakrabort, A., Ravindran, R., Zhang, X., and
G. Wang, "Contextualized information-centric home
network", 2013.
[16] Huang, R., Zhang, J., Hu, Y., and J. Yang, "Smart Campus:
The Developing Trends of Digital Campus", 2012.
[17] Yan, Y., Qian, Y., Hu, Y., and J. Yang, "A Survey on Smart
Grid Communication Infrastructures: Motivations,
Requirements and Challenges", 2013.
[18] Miao, Y. and Y. Bu, "Research on the Architecture and Key
Technology of Internet of Things (loT) Applied on Smart
Grid", 2010.
[19] 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", 2012.
Zhang, et al. Expires March 26, 2015 [Page 22]
Internet-Draft ICN based Architecture for IoT September 2014
[20] Zhou, H., Liu, B., and D. Wang, "Design and Research of
Urban Intelligent Transportation System Based on the
Internet of Things", 2012.
[21] Zhang, M., Yu, T., and G. Zhai, "Smart Transport System
Based on the Internet of Things", 2012.
[22] Zhang, A., Yu, R., Nekovee, M., and S. Xie, "The Internet
of Things for Ambient Assisted Living", 2010.
[23] Savola, R., Abie, H., and M. Sihvonen, "Towards metrics-
driven adaptive security management in E-health IoT
applications.", 2012.
[24] Jacobson, V., Smetters, D., Plass, M., Stewart, P.,
Thornton, J., and R. Braynard, "VoCCN: Voice-over Content-
Centric Networks", 2009.
[25] Piro, G., Cianci, I., Grieco, L., Boggia, G., and P.
Camarda, "Information Centric Services in Smart Cities",
2014.
[26] Ravindran, R., Biswas, T., Zhang, X., Chakrabort, A., and
G. Wang, "Information-centric Networking based Homenet",
2014.
[27] Dannewitz, C., D' Ambrosio, M., and V. Vercellone,
"Hierarchical DHT-based name resolution for information-
centric networks", 2013.
[28] Chai, W., He, D., and I. Psaras, "Cache "less for more" in
information-centric networks", 2012.
[29] Eum, S., Nakauchi, K., Murata, M., Shoji, Yozo., and N.
Nishinaga, "Catt: potential based routing with content
caching for icn", 2012.
[30] Eum, S., Shvartzshnaider, Y., Francisco, J., Martini, R.,
and D. Raychaudhuri, "Enabling internet-of-things services
in the mobilityfirst future internet architecture", 2012.
[31] Sun, Y., Qiao, X., Cheng, B., and J. Chen, "A low-delay,
lightweight publish/subscribe architecture for delay-
sensitive IOT services", 2013.
[32] Baccelli, E., Mehlis, C., Hahm, O., Schmidt, T., and M.
Wahlisch, "Information Centric Networking in the
IoT:Experiments with NDN in the Wild", 2013.
Zhang, et al. Expires March 26, 2015 [Page 23]
Internet-Draft ICN based Architecture for IoT September 2014
[33] Gronbaek, I., "Architecture for the Internet of Things
(IoT): API and interconnect", 2008.
[34] Tian, Y., Liu, Y., Yan, Z., Wu, S., and H. Li, "RNS-A
Public Resource Name Service Platform for the Internet of
Things", 2012.
[35] Roussos, G. and P. Chartier, "Scalable id/locator
resolution for the iot", 2011.
[36] Li, S., Zhang, Y., Raychaudhuri, D., and R. Ravindran, "A
Comparative Study of MobilityFirst and NDN based ICN-IoT
Architectures", 2011.
[37] Amadeo, M., Campolo, C., Iera, A., and A. Molinaro, "Named
data networking for IoT: An architectural perspective",
2014.
[38] Amadeo, M. and C. Campolo, "Potential of information-
centric wireless sensor and actor networking", 2014.
[39] Nelson, S., Bhanage, G., and D. Raychaudhuri, "GSTAR:
generalized storage-aware routing for mobilityfirst in the
future mobile internet", 2014.
[40] Trappe, W., Zhang, Y., and B. Nath, "MIAMI: methods and
infrastructure for the assurance of measurement
information", 2005.
[41] 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", 2005.
[42] Liu, R. and W. Trappe, "Securing Wireless Communications
at the Physical Layer", 2010.
[43] Xiao, L., Greenstein, L., Mandayam, N., and W. Trappe,
"Using the physical layer for wireless authentication in
time-variant channels", 2008.
[44] Sun, S., Lannom, L., and B. Boesch, "Handle system
overview", 2003.
[45] Liu, X., Trappe, W., and Y. Zhang, "Secure Name Resolution
for Identifier-to-Locator Mappings in the Global
Internet", 2003.
Zhang, et al. Expires March 26, 2015 [Page 24]
Internet-Draft ICN based Architecture for IoT September 2014
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 March 26, 2015 [Page 25]
Internet-Draft ICN based Architecture for IoT September 2014
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
Zhang, et al. Expires March 26, 2015 [Page 26]