Internet DRAFT - draft-zhang-iot-icn-architecture
draft-zhang-iot-icn-architecture
ICN Research Group Y. Zhang
Internet-Draft D. Raychadhuri
Intended status: Informational WINLAB, Rutgers University
Expires: December 5, 2014 R. Ravindran
G. Wang
Huawei Technologies
June 3, 2014
ICN based Architecture for IoT
draft-zhang-iot-icn-architecture-01
Abstract
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 unified IoT platform so
that objects can be made 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
today's Internet. Such an overlay solution, however, is inadequate
to address the important challenges posed by a unified IoT system,
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 unified 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.
In this proposal, we first present a few popular IoT scenarios in
smart homes, smart grid, smart transportation, and smart healthcare.
Then we identify a list of important requirements with the unified
IoT architecture that promises to support tens of billions of
objects. After discussing the weaknesses of the current overlay-
based IoT solution, we propose an ICN-based solution, ICN-IoT, which
can sufficiently satisfy these requirements. We present an example
ICN-IoT architecture and discuss how it supports efficient data
discovery, data processing and data distribution. Finally, we show
that ICN-IoT efficiently supports context- based scenarios, which are
very common for many IoT applications.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Zhang, et al. Expires December 5, 2014 [Page 1]
Internet-Draft ICN based Architecture for IoT June 2014
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 December 5, 2014.
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 and Challenges . . . . . . . . . . . . . . . . 3
1.1. Popular scenarios . . . . . . . . . . . . . . . . . . . . 3
1.1.1. Smart Homes . . . . . . . . . . . . . . . . . . . . . 3
1.1.2. Smart Grid . . . . . . . . . . . . . . . . . . . . . 4
1.1.3. Smart Transportation . . . . . . . . . . . . . . . . 4
1.1.4. Smart Healthcare . . . . . . . . . . . . . . . . . . 4
2. IoT Architectural Requirements . . . . . . . . . . . . . . . 4
2.1. Naming . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.2. Scalability . . . . . . . . . . . . . . . . . . . . . . . 5
2.3. Resource Constraints . . . . . . . . . . . . . . . . . . 5
2.4. Traffic Characteristics . . . . . . . . . . . . . . . . . 6
2.5. Contextual Communication . . . . . . . . . . . . . . . . 6
2.6. Handling Mobility . . . . . . . . . . . . . . . . . . . . 7
2.7. Storage and Caching . . . . . . . . . . . . . . . . . . . 7
2.8. Security and Privacy . . . . . . . . . . . . . . . . . . 7
2.9. Communication Reliability . . . . . . . . . . . . . . . . 8
2.10. Self-Organization . . . . . . . . . . . . . . . . . . . . 8
2.11. Ad hoc and Infrastructure Mode . . . . . . . . . . . . . 8
3. State of the Art . . . . . . . . . . . . . . . . . . . . . . 8
Zhang, et al. Expires December 5, 2014 [Page 2]
Internet-Draft ICN based Architecture for IoT June 2014
3.1. Silo IoT Architecture . . . . . . . . . . . . . . . . . . 9
3.2. Overlay Based Unified IoT Solutions . . . . . . . . . . . 10
3.2.1. Weaknesses of the Overlay-based Approach . . . . . . 10
4. Proposed ICN-Centric Unified IoT Platform . . . . . . . . . . 12
4.1. Strengths of ICN-IoT . . . . . . . . . . . . . . . . . . 13
4.2. Example ICN-IoT Architecture . . . . . . . . . . . . . . 14
4.3. ICN-IoT Scenario . . . . . . . . . . . . . . . . . . . . 17
5. Informative References . . . . . . . . . . . . . . . . . . . 21
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22
1. IoT Motivation and Challenges
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.Before
we present our solution to such a unified platform, we first describe
a few popular IoT scenarios to motivate this proposal.
1.1. 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.
1.1.1. Smart Homes
Home is a complex ecosystem for smart systems such as climate
control, home security monitoring, smoke detection, or smart meters.
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. The challenges for smart 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.
Zhang, et al. Expires December 5, 2014 [Page 3]
Internet-Draft ICN based Architecture for IoT June 2014
1.1.2. Smart Grid
Central to smart grid 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.
1.1.3. Smart Transportation
We are currently witnessing the increasing integration of sensors
into cars. 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 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 smart
transportation include fast data/device/service discovery and
association, efficient communications with mobility, trustworthy data
collection and exchange.
1.1.4. Smart Healthcare
As more embedded medical devices, or devices that can monitor human
health become increasingly deployed, smart healthcare is becoming a
viable alternative to traditional healthcare solutions. For smart
health applications, a unified IoT platform is critical for sharing
data and enabling timely actuations. The challenges in smart
healthcare include real-time interactions, high reliability, short
communication latencies, trustworthy, security and privacy.
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/lifetime of
each device, data items generated by these devices, or a group of
Zhang, et al. Expires December 5, 2014 [Page 4]
Internet-Draft ICN based Architecture for IoT June 2014
devices. Naming has the following requirements. First, names need
to be application-centric, i.e., solely serving the purpose of an
application or service. Second, names need to be persistent against
dynamic attributes that are common in IoT systems, such as mobility
or migration. Third, names need to be secure based on application
requirement.
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
informational entity such as data, devices, etc. To deal with
scalability, the name-locator separation is the basic requirement,
implying that it is necessary to have a name resolution service. The
requirement on such a resolution service is thus clear: 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 is 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 the 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, also information needs to be
available where it is more likely to be consumed. As a result, more
complex processing needs to be conducted elsewhere, example at the
network edge, which makes it important to balance local computation
versus communication.
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
these devices can have, which will have the same implication on the
system architecture as the power constraints; namely, we cannot
afford to communicate with every single sensor data generated by the
device.
Zhang, et al. Expires December 5, 2014 [Page 5]
Internet-Draft ICN based Architecture for IoT June 2014
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 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, peak traffic volume has to be
considered.
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
example, cars travelling 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 of these contexts.
Zhang, et al. Expires December 5, 2014 [Page 6]
Internet-Draft ICN based Architecture for IoT June 2014
2.6. Handling Mobility
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 3) 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
three cases.
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.
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 content caching requirements can be cached at
will or at service authorized points, and thus we 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.
In network storage and caching, however, has the following
requirements on the IoT platform. First, the platform needs to
support the efficient resolution of cached copies. Second, certain
content should not be cached anywhere, and the service platform
should be able to enforce this. Third, the platform should strive
for the balance between caching, content security/privacy, and
regulations.
2.8. Security and Privacy
The unified IoT platform makes physical objects accessible to
applications across organizations and domains, and security and
privacy thus become a serious concern. Security includes data
integrity, authentication, trust management, 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.
Zhang, et al. Expires December 5, 2014 [Page 7]
Internet-Draft ICN based Architecture for IoT June 2014
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 to support for extreme disruptions (DTN),
(2) efficient routing in the presence of intermittent disconnection,
and (3) QoS aware routing.
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-
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 be classified as either 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 open IoT platform needs
to be able to handle both situations.
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.
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
Zhang, et al. Expires December 5, 2014 [Page 8]
Internet-Draft ICN based Architecture for IoT June 2014
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. In such a
unified platform, physical world resources can be accessed over
Internet and shared across the boundaries of physical, enterprise and
application. However, current approaches to achieving this objective
are based upon Internet overlays, whose inherent inefficiencies
hinders the platform from satisfying the IoT requirements outlined
earlier (particularly in terms of scalability, security, mobility,
and self-organization)
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, we use the IoT gateway to connect these
devices to the server. Through the IoT server, applications can
subscribe to the data collected by the devices, or interact with the
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 host-driven, instead of information
driven, leading to a highly fragmented protocol space with limited
interoperability.
Zhang, et al. Expires December 5, 2014 [Page 9]
Internet-Draft ICN based Architecture for IoT June 2014
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], and CORE[4]. 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.
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.
Another limiting factor is that it is built upon today's IP network,
which has a few inherent weaknesses towards supporting a unified IoT
system. As a result, it cannot satisfy some of the requirements we
outlined in Section 3:
o Naming. The overlay-based approach uses IP addresses as names at
the network layer, which are not persistent for mobile devices/
services.
Zhang, et al. Expires December 5, 2014 [Page 10]
Internet-Draft ICN based Architecture for IoT June 2014
o Scalability. The overlay-based approach uses IP addresses as
names at the network layer, which does not provide the scalability
needed to support device/service mobility or flexible name
resolution.
o Resource constraints. The overlay-based approach requires every
device to send data 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, instead of being information-
centric. As a result, it is challenging for the underlying system
to satisfy the communication patterns of the applications.
Further, characteristics of today's Internet, such as the lack of
multicast, will make the matters worse.
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 this approach, communications are IP driven,
which is inefficient for mobility support.
o Storage and Caching. The overlay-based approach does not provide
efficient storage/caching support. Also, applications are written
in a host-centric manner, wherein network requests are bound to a
specific destination host/server instead of a specific piece of
content.
o Communication Reliability. The overlay-based approach offers
insufficient communication reliability when the devices/services/
data are mobile.
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.
Zhang, et al. Expires December 5, 2014 [Page 11]
Internet-Draft ICN based Architecture for IoT June 2014
4. Proposed ICN-Centric Unified IoT Platform
______________ __________ __________
|IoT Smart Home| |IoT Smart | |IoT Smart |
|Management | |Transport | |Healthcare|
|______________| |Management| |Management|
\ |__________| |__________|
\ | /
\ _____________|___________ /
{ }
{ }
{ ICN }
{ }
{_________________________}
/ | \
/ | \
_________/ ________|______ __\_____________
{ } { } { }
{Smart home} {Smart Transport} {Smart Healthcare}
{__________} {_______________} {________________}
| | | | | |
___|__ __|___ __|__ __|__ ____|____ ____|____
|Home-1||Home-2| |Car-1||Car-2| |Medical ||Medcical |
|______||______| |_____||_____| |Devices-1||Devices-2|
|_________||_________|
Figure 3: The proposed ICN-centric IoT unified platform.
In recent years, the current Internet has become inefficient in
supporting rapidly emerging Internet use cases, e.g., mobility,
content retrieval, IoT, context, etc. As a result, Information
Centric Network [5] has been proposed as a future Internet design to
address these inefficiencies. ICN has the following main features:
(1) it identifies a network object (including a mobile device, a
content, a service, or a context) by its name instead of its IP
address, (2) a hybrid name/address routing, and (3) a delay-tolerant
transport. These features make it easy to realize many in-network
functions, such as mobility support, multicasting, content caching,
cloud/edge computing and security.
Considering these salient features of ICN, we propose to build a
unified IoT platform using ICN, in which the overlay IoT services are
only needed for administrative purposes, while the publishing,
discovery, and delivery of the IoT data/services is directly
implemented within the ICN network. Figure 3 shows the proposed ICN-
Zhang, et al. Expires December 5, 2014 [Page 12]
Internet-Draft ICN based Architecture for IoT June 2014
centric IoT approach, which is centered around the ICN network
instead of today's Internet.
4.1. Strengths of ICN-IoT
Our proposed ICN-IoT is a network-layer IoT solution, which can
satisfy the requirements of the open IoT platform:
o Naming. In ICN-IoT, we assign a unique name to an IoT object, an
IoT service, or even a context. These names are persistent
throughout their scopes.
o Scalability. In ICN-IoT, the name resolution is performed at the
network layer, distributed within the entire network. Thus, it
can achieve high degree of scalability exploiting features like
content locality, local computing, and multicasting.
o Resource constraints. In ICN-IoT, mobile devices only need to
upload their data to the gateway when some applications subscribe
to the data. Thus, it offers a resource-efficient solution.
o Local traffic Pattern. In ICN-IoT, we can easily cache data/
services in the network, facilitating local communications.
o Context-aware communications. In ICN-IoT, we assign unique names
to contexts, which are then mapped to the devices that are
involved in the context by the name resolution service. The
support of multicast can greatly ease the communications to these
devices.
o Seamless mobility handling. In ICN-IoT, ICN's name resolution
layer allows multiple levels of mobility relying on receiver-
oriented nature for self-recovery for consumers, to multi-casting
and late-binding techniques to realize seamless mobility support
of producing nodes.
o Data storage. In ICN-IoT, data are stored locally, either by the
mobile device or by the gateway nodes or at service points. We
also implement in-network storage/caching [6] to speed up data
delivery.
o Security and privacy. In ICN-IoT, secure binding between names
and content instead of IP addresses to identify devices/data/
services, is inherently more secure allowing pervasive caching.
o Communication reliability. In ICN-IoT, we support seamless
mobility, which in turn guarantees reliable communications.
Zhang, et al. Expires December 5, 2014 [Page 13]
Internet-Draft ICN based Architecture for IoT June 2014
o Ad hoc and infrastructure mode. ICN-IoT support both ad-hoc and
infrastructure modes.
+-[Host]-[Sensors]-[Content]-[Context]-+
|Name Assignment Service(Semantic->UID)|
+======================================+
| Delay Tolerant Network(DTN)Transport |--+
| (Storage-aware) | |
+======================================+ |
| Hybrid UID/Address Routing |--|--+
+======================================+ | |
+---|Name Resolution Service(UID->Address) | | |
| +======================================+ | |
| _________ _________ | |
| [ Routing ]..................[ Routing ]--+ |
| +=========+..................+=========+ |
| [ Storage ]..................[ Storage ] |
| +=========+..................+=========+ |
| [Computing]..................[Computing] |
+---[ Plane ]..................[ Plane ]-----+
+---------+ +---------+
ICN Router ICN Router
Figure 4: An Example ICN-IoT Architecture
4.2. Example ICN-IoT Architecture
The design of ICN-IoT is to support a scalable, unified IoT
architecture with tens of billions of devices. The ICN-IoT
introduces a unique identifier (UID) for every network object,
separated from its dynamic access network locations represented by
network addresses. The separation of naming and addressing allows
ICN-IoT to support identity based routing, which provides seamless
mobility support. Multicast and anycast can then become a native
network capability since a UID can be bound to multiple addresses.
Figure 4 depicts the example ICN-IoT core network architecture. The
assumption is that ICN routers have a sizeable storage and a
computing plane in addition to the basic routing function. The
proposed ICN-IoT network includes the following three basic services:
o Name Resolution Service (NRS): A core ICN-IoT function that
maintains mappings between UID to network address (NA). This can
be a logically centralized service distributed on all ICN routers.
Zhang, et al. Expires December 5, 2014 [Page 14]
Internet-Draft ICN based Architecture for IoT June 2014
o Hybrid UID/network address routing: An ICN router makes routing
decisions for UID identified data blocks. It uses NRS to find the
network address(s) for a UID. In case an explicit network address
cannot be obtained from NRS, it may route based on intermediate
network address and use "late-biding" from UID to its actual
network address.
o Delay-tolerant network (DTN) transport: An ICN router can deliver
UID-only identified data blocks from/to a networked object. The
transport performs a cache and forward (CNF) style, hop-by-hop
delivery. The data block is cached in router storage and forward
to next hop based on routing decisions.
o In addition to baseline services, ICN-IoT assumes there is a name
assignment service (NAS) chosen by the owner of a networked
object. Through the NAS, the owner assigns and publishes a UID
with its semantic descriptions for his networked object to a
searchable space, such as google or semantic Linked-data space
[1].
In Figure 5, we summarize the ICN-IoT milddleware into three service
categories: 1) Data Discovery Service, 2) Data Processing Service and
3) Data (Re)Distribution Service. These services span both in Ad hoc
and Infrastructure settings.
Data Discovery Service: Discovery service allows applications finding
things/services/data through certain semantic / syntactic resolution.
In ICN-IoT, each data/service has both a user-readable name with
certain semantic structures and unique identifiers (UID). Based on
the human readable names, the data discovery service can help
discover the requested data/services.
Data Processing Service: The data processing service generates new
knowledge or information through applying knowledge and/or rules on
existing data. Data processing can be distributed based on its scope
and relevance as in the local node, versus edge service routers, or
in data centers. Data processing procedures are often defined by the
applications/services.
Zhang, et al. Expires December 5, 2014 [Page 15]
Internet-Draft ICN based Architecture for IoT June 2014
_______________________________________________
Things | IoT MIDDLEWARE | APPS/
________ | (Ad-hoc/Infrastructure) | Services
|Sensors || ___________________ | ________
|--------|| +------|Discovery Service |-----+ ||APP1 |
|________|| _____|_____ |(Semantic/Syntactic| ____|______ ||--------|
| Tags |||Resource ||Resolution) ||Application|||________|
|--------|||Abstraction|+-------------------+|Abstraction|||APP2 |
|________||+-----------+|Data Analysis |+-----------+||--------|
|Feeds || | |Event Detection | | ||________|
|--------|| | |Context Reasoning | | ||Service1|
|________|| | |Security/privacy | | ||--------|
|Actuator|| | |control | | ||________|
|--------|| | |(Knowledge,Rules) | | ||Service2|
|________|| | +-------------------+ | ||--------|
|Database|| | |(Re)-distribution | | ||________|
+--------+| | |Service(CDN,Cloud) | | | |
| | | +-------------------+ | | |
| +-----+--------|-----------------|-------+------+ |
| | | | | |
| | | | | |
| +-----------------------------------------------+ |
+---| Information Centric Network(ICN) |-----+
+-----------------------------------------------+
Figure 5: The ICN-IoT Service Middleware
Data Re-distribution Service: The (re)distribution service delivers
data from their sources to different locations for better
accessibility. These services will be directly supported by the ICN.
Firstly, ICN can cache data/content on forwarding ICN routers, and
secondly, these routers will be added to the NRS service so that
requests for the cached data/content can be forwarded to them, thus
reducing the data/content retrieval latencies.
Figure 5 shows how the ICN-IoT middleware services (identified in
Figure 4) integrated into the ICN infrastructure. The components of
the IoT middleware can be described with respect the services
identified before.
o Realizing Data discovery Service. Two tasks are involved in
achieving this. First is a way to name services/content/devices
of interest within the IoT application scope. Each network entity
that is registered at the Name Assignment Service (NAS) has both a
human readable name and a unique identifier (UID). The human
readable name includes semantic key words that characterize the
entity. Once the entities are named, applications based on its
Zhang, et al. Expires December 5, 2014 [Page 16]
Internet-Draft ICN based Architecture for IoT June 2014
policy requirements make it accessible considering access control
policies. To enable accessibility a discovery function is
required, which is enabled through NAS. Figure 5 shows an example
with sensor SID and service CID. Both SID and CID are published
to the searchable name space through NAS, which can be efficiently
discovered later by the applications.
o Realizing Data processing Service. ICN-IoT uses the in-network
storage and computing capability to cache and execute data
processing service, such as a context reasoning service,
traditionally implemented on overlay servers. Having the context
reasoning service within the network, however, requires additional
computing capabilities offered by routers or separate computing
facilities in the network. In Figure 5, the service, identified
by CID, is cached and executed on an ICN router.
o Realizing Data (re)distribution Service. ICN-IoT performs
distribution or re-distribution of IoT data and service through
its native support of in-network caching and multicast based on
identity based routing.
4.3. ICN-IoT Scenario
We will use a context-aware IoT application as an example from
UbiCab[8] to demonstrate how IoT middleware service is enabled inside
the proposed ICN-IoT core network. This example is based on
MobilityFirst architecture [7] which is based on secured names and
off-path name resolution infrastructure.
The example is stated as: "James walks on NYC streets and wants to
find an empty cab closest to his location". In this example, we
assume that James and taxi drivers have sensors on their phones,
providing GPS location information as data. The context of this
application is the relative locations of James and taxi drivers. A
context service, as an IoT middleware, is needed to bridge sensors
(providing GPS location) and the application (phone call program)
automatically.
We use a linked-data inspired approach to implement the middleware
service for this location aware context. First, a company
GPSlocation.com offers this service at http://GPSlocation.com/
nearbyCab, implemented in an RDF graph shown in Figure 7. This
context service has two attributes to describe itself, tagged as cab
and location. A taxi driver can query this RDF graph and joins as a
member of the service by adding a link to its own URI http://NYCcab
.com/cab1 in the RDF graph with a predicate "a:member". The sensor
data, taxi driver's GPS location, is linked to taxi driver's URI with
a predicate "a:location" and the value is updated by his phone
Zhang, et al. Expires December 5, 2014 [Page 17]
Internet-Draft ICN based Architecture for IoT June 2014
periodically. he database containing this RDF graph must be
searchable by users in a searchable space, which we refer as IoT
resource space in Figure 6.
______________ ______
{ } +SID-(Sensor)
+--------------------->{IoT Name Space} | ------
| +---------------->{______________}<--------------------+
| | | | |
|Lookup _____________________|_____________________|_ |
|Service|Add-on Protocols(Name Assignment Service, | Publish
| | | Caching)) | (CID)
| __|__ +=============================================+ |
||Apps ||Baseline ICN Protocols(Transport,Routing,Name| |
||(ICN || Resolution) | |
||Host)||_____________________________________________| ___|_______
||_____| | |Overlay IoT|
| | Get ____________|____________ |Middleware |
| +--CID-----{ } |Service |
| _______ { ICN Core Network }----CID------>|(ICN Host) |
| |Readers| {_________________________} |___________|
+---|(ICN | | |
|Host) | Send _____|_______
+=======+ (SID) |Caching IoT |
{Local } | |Middleware |
{IoT }-------+ |Service |
{Network} |(ICN Storage)|
{_______} |_____________|
Figure 6: ICN-IoT Data and Services
|8438435780327523478532,4530| a:member---->|http://NYCcab.com/cab1|
UID |
| |a:member--->|http://NYCcab.com/cab2|
| || | |
|http://GPSLocation.com/nearbtCab| |UID_2| a:location
|Cab| | |Location|-a:attribute |
a:Pubkey | +---->|Cab| |GPSvalue|
| | |
| | |
|8438435780327523478532| a:attribute-->|Location|--->Linked-data
Figure 7: Location context service in RDF
Zhang, et al. Expires December 5, 2014 [Page 18]
Internet-Draft ICN based Architecture for IoT June 2014
In ICN-IoT, we also add an additional 3-tuple or triple in the RDF
graph with a predicate "UID". CID is assigned to the context service
and UID_2 is assigned to cab2.
This context service can also run as an overlay to the Internet.
Taxi drivers and passengers can directly call the URI of the context
service to join the membership and get a nearby cab, respectively.
As an Internet overlay, the location context service is subject to
longer delay due to demands are overloaded or unbalanced.
In this example, since the context service is implemented using an
RDF graph, it can be cached on ICN routers in a similar way to
caching content. This RDF graph can be updated by taxi drivers by
joining membership, current GPS location etc, since the context
service is UID identified it can be routed efficiently by the ICN
routers. The utility of such information is determined by specific
application requirements.
The application scenario is comprised of the following steps,
illustrated by Figure 8.
o Name Assignment. The owner of the context service publishes its
CID and the service description (RDF graph of Figure 7) through
ICN-IoT NAS function, running on both service host and routers, to
a searchable Link-data space.
o NRS Update. When the context service connects to the ICN network,
the access router calls NRS update to provide a UID to network
address mapping.
o Service Discovery. Taxi driver or James can find CID through an
RDF query requesting services with tags "location" and "cab".
o Service Request. Taxi driver makes a service request to CID with
an RDF query to join the service membership.
o Routing and GNRS Lookup. The service request toward CID is routed
to the NA_c, obtained from a NRS lookup.
o Service Request Redirection. James makes a service request to CID
with an RDF query to match GPS location to a nearby taxi. James'
request to CID is redirected to UID_2, the driver of cab2.
Note that in this example, no CDN overlay is needed to support multi-
homing, multicasting for a location context service because these are
embedded in the ICN core network.
Zhang, et al. Expires December 5, 2014 [Page 19]
Internet-Draft ICN based Architecture for IoT June 2014
As usual, the benefit of caching is more significant for location
dependent services. In our example, it is best to have the
middleware service being offered at a server close to taxi drivers
and passengers so that the traffic can be localized with lower
latency.
__________ _______ _______
{ } |Caching| |NRS |
{RDF graphs}-RDF query-|Service| |Service|
{__________} |_______| |_______|
^ |
| NRS
Caching Lookup
+----------+ +-----+
| |
| | Name Assignment
_______ Service _|________________| NRS _______________
|Taxi |Discovery{ | } Update | |
|Drivers|-------->{ICN-IoT CoreNetwork}<------------|GPSLocation.com|
|_______|Request {_|_________________}-+ |_______________|
^ | |
_________ Service | NAS |
|Passenger|Discovery| Discovery |
|James |---------+ | _______ |________________
|_________| | |NAS | { }
+->|Service| {Linked-Data Space}
|_______| {_________________}
| ^
| |
+---RDF Query--+
Figure 8: Location context application scenario
Traditionally, a service provider has to buy edge computing service
from content distribution network (CDN); recently, cloud computing
offers another alternative to deploy a distributed service. The
native support of caching in ICN provides with the ability to
distribute a service directly through core network routers. This
option may not be suitable for heavyweight service requiring a high
end web server. Nevertheless, it could be particularly useful for
lightweight IoT middleware service. As shown in our example, when
the context service is implemented in an RDF graph, caching a service
is as simple as caching a data and service processing is as simple as
Zhang, et al. Expires December 5, 2014 [Page 20]
Internet-Draft ICN based Architecture for IoT June 2014
a database query. The algorithms behind cache replacement can also
be similar to what for data caching.
Once, for example, the service CID is cached, any request to CID is
intercepted by the ICN router. In our example, when it is a request
from taxi driver, it must contain an RDF query requesting either join
membership or an updated GPS location. The computing layer of ICN
router runs a SPARQL engine to interpret the RDF query and makes a
corresponding database operation. When it is a request from James, a
passenger, it must contain an RDF query containing its own GPS
location and looking for the ID of a taxi with a GPS location nearby.
Another benefit of ICN caching is that there is no need for end-to-
end connectivity between the requester and the location context
server, if the service is currently cached in an accessible ICN
router. This is especially useful for ad-hoc or DTN use cases, where
the application network can be dynamically formed and isolated for a
period of time.
This UbiCab example has low data rate. Next imagine a context
service requires high data rate, for example, a person wants to see
snapshots of the street nearby. And these snapshots are uploaded by
the people on the street. Assuming every access network can get
enough number of people uploading pictures, it is best for the
network operator to cache the pictures as close to edge as possible.
Through this location context service example, we can see ICN-IoT
offers significant native supports for IoT data and services to be
visible, routable, cacheable and executable in the core network of
future Internet architecture.
5. 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 InstituteS,
ETSI., "http://www.etsi.org/.", 1988.
[4] Constrained RESTful Environments, CoRE.,
"https://datatracker.ietf.org/wg/core/charter/.", 2013.
Zhang, et al. Expires December 5, 2014 [Page 21]
Internet-Draft ICN based Architecture for IoT June 2014
[5] 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.
[6] 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.
[7] NSF FIA project, MobilityFirst.,
"http://www.nets-fia.net/", 2010.
[8] 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.
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
Ravi Ravindran
Huawei Technologies
2330 Central Expressway
Santa Clara, CA 95050
USA
Email: ravi.ravindran@huawei.com
Zhang, et al. Expires December 5, 2014 [Page 22]
Internet-Draft ICN based Architecture for IoT June 2014
Guoqiang Wang
Huawei Technologies
2330 Central Expressway
Santa Clara, CA 95050
USA
Email: gq.wang@huawei.com
Zhang, et al. Expires December 5, 2014 [Page 23]
