One document matched: draft-zhang-iot-icn-challenges-02.xml
<?xml version="1.0" encoding="US-ASCII"?>
<!-- This template is for creating an Internet Draft using xml2rfc,
which is available here: http://xml.resource.org. -->
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
]>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<!-- used by XSLT processors -->
<!-- For a complete list and description of processing instructions (PIs),
please see http://xml.resource.org/authoring/README.html. -->
<!-- Below are generally applicable Processing Instructions (PIs) that most I-Ds might want to use.
(Here they are set differently than their defaults in xml2rfc v1.32) -->
<?rfc strict="yes" ?>
<!-- give errors regarding ID-nits and DTD validation -->
<!-- control the table of contents (ToC) -->
<?rfc toc="yes"?>
<!-- generate a ToC -->
<?rfc tocdepth="4"?>
<!-- the number of levels of subsections in ToC. default: 3 -->
<!-- control references -->
<?rfc symrefs="no"?>
<!-- use symbolic references tags, i.e, [RFC2119] instead of [1] -->
<?rfc sortrefs="yes" ?>
<!-- sort the reference entries alphabetically -->
<!-- control vertical white space
(using these PIs as follows is recommended by the RFC Editor) -->
<?rfc compact="yes" ?>
<!-- do not start each main section on a new page -->
<?rfc subcompact="no" ?>
<!-- keep one blank line between list items -->
<!-- end of list of popular I-D processing instructions -->
<rfc category="info"
docName="draft-zhang-iot-icn-challenges-02"
ipr="trust200902">
<!-- category values: std, bcp, info, exp, and historic
ipr values: trust200902, noModificationTrust200902, noDerivativesTrust200902
pre5378Trust200902
you can add the attributes updates="NNNN" and obsoletes="NNNN"
they will automatically be output with "(if approved)" -->
<!-- ***** FRONT MATTER ***** -->
<front>
<!-- The abbreviated title is used in the page header - it is only necessary if the
full title is longer than 39 characters -->
<title abbrev="ICN based Architecture for IoT">ICN based Architecture for IoT - Requirements and Challenges</title>
<author fullname="Prof.Yanyong Zhang" initials="Y." surname="Zhang">
<organization>WINLAB, Rutgers University</organization>
<address>
<postal>
<street>671, U.S 1</street>
<!-- Reorder these if your country does things differently -->
<city>North Brunswick</city>
<region>NJ</region>
<code>08902</code>
<country>USA</country>
</postal>
<phone></phone>
<email>yyzhang@winlab.rutgers.edu</email>
<!-- uri and facsimile elements may also be added -->
</address>
</author>
<author fullname="Prof. Dipankar Raychadhuri" initials="D." surname="Raychadhuri">
<organization>WINLAB, Rutgers University</organization>
<address>
<postal>
<street>671, U.S 1</street>
<!-- Reorder these if your country does things differently -->
<city>North Brunswick</city>
<region>NJ</region>
<code>08902</code>
<country>USA</country>
</postal>
<phone></phone>
<email>ray@winlab.rutgers.edu</email>
<!-- uri and facsimile elements may also be added -->
</address>
</author>
<author fullname="Prof. Luigi Alfredo Grieco" initials="L." surname="Grieco">
<organization>Politecnico di Bari (DEI)</organization>
<address>
<postal>
<street>Via Orabona 4</street>
<!-- Reorder these if your country does things differently -->
<city>Bari</city>
<code>70125</code>
<country>Italy</country>
</postal>
<email>alfredo.grieco@poliba.it</email>
<!-- uri and facsimile elements may also be added -->
</address>
</author>
<author fullname="Prof. Emmanuel Baccelli" initials="E." surname="Baccelli">
<organization>INRIA</organization>
<address>
<postal>
<street>Room 148, Takustrasse 9</street>
<!-- Reorder these if your country does things differently -->
<city>Berlin</city>
<code>14195</code>
<country>France</country>
</postal>
<email>Emmanuel.Baccelli@inria.fr</email>
<!-- uri and facsimile elements may also be added -->
</address>
</author>
<author fullname="Jeff Burke" initials="J." surname="Burke">
<organization>UCLA REMAP</organization>
<address>
<postal>
<street>102 East Melnitz Hall</street>
<!-- Reorder these if your country does things differently -->
<city>Los Angeles</city>
<region>CA</region>
<code>90095</code>
<country>USA</country>
</postal>
<phone></phone>
<email>jburke@ucla.edu</email>
<!-- uri and facsimile elements may also be added -->
</address>
</author>
<author fullname="Ravishankar Ravindran" initials="R." surname="Ravindran (Ed)">
<organization>Huawei Technologies</organization>
<address>
<postal>
<street>2330 Central Expressway</street>
<!-- Reorder these if your country does things differently -->
<city>Santa Clara</city>
<region>CA</region>
<code>95050</code>
<country>USA</country>
</postal>
<phone></phone>
<email>ravi.ravindran@huawei.com</email>
<!-- uri and facsimile elements may also be added -->
</address>
</author>
<author fullname="Guoqiang Wang" initials="G." surname="Wang">
<organization>Huawei Technologies</organization>
<address>
<postal>
<street>2330 Central Expressway</street>
<!-- Reorder these if your country does things differently -->
<city>Santa Clara</city>
<region>CA</region>
<code>95050</code>
<country>USA</country>
</postal>
<phone></phone>
<email>gq.wang@huawei.com</email>
<!-- uri and facsimile elements may also be added -->
</address>
</author>
<date year="2015" />
<!-- If the month and year are both specified and are the current ones,
xml2rfc will fill in the current day for you. If only the current year is
specified, xml2rfc will fill in the current day and month for you. If the
year is not the current one, it is necessary to specify at least a month
(xml2rfc assumes day="1" if not specified for the purpose of calculating
the expiry date). With drafts it is normally sufficient to specify just
the year. -->
<!-- Meta-data Declarations -->
<area>General</area>
<!--workgroup>Network Working Group</workgroup> -->
<workgroup>ICN Research Group</workgroup>
<!-- WG name at the upperleft corner of the doc,
IETF is fine for individual submissions.
If this element is not present, the default is "Network Working Group",
which is used by the RFC Editor as a nod to the history of the IETF. -->
<keyword>Information-Centric Networking</keyword>
<!-- Keywords will be incorporated into HTML output
files in a meta tag but they have no effect on text or nroff
output. If you submit your draft to the RFC Editor, the
keywords will be used for the search engine. -->
<abstract>
<t> 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 host centric 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.
</t>
<t>
This draft describes representative 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. Though we see most of the IoT requirements can be met by ICN, we discuss specific challenges ICN has to address
to satisfy them. Then we discuss important and popular IoT scenarios including the
"smart" home, campus, grid, transportation infrastructure,
healthcare, Education, and Entertainment.
</t>
</abstract>
</front>
<middle>
<section anchor="intro" title="IoT Motivation">
<t>
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 <xref target="cisco" />, 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 IoT challenges from an ICN perspective and requirements posed towards its design. Final discussion focusses on IoT scenarios and their unique challenges.
</t>
</section>
<section anchor="requirement" title="IoT Architectural Requirements">
<t>
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.
</t>
<section anchor="namingrequirement" title="Naming">
<t>
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 lifetime, mobility or migration; second, names need to be secure based
on application requirements; third, names should provide advantages to
application authors in comparison with traditional host address based
schemes.
</t>
</section>
<section anchor="scalability" title="Scalability">
<t>
Cisco predicts there will be around 50 Billion IoT devices such as sensors,
RFID tags, and actuators, on the Internet by 2020 <xref target="cisco" />.
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 register/update/resolve up a name within a short latency. To satisfy this requirement, decentralization of the name resolution can be the key.
</t>
</section>
<section anchor="constraints" title="Resource Constraints">
<t>
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, bandwidth, and user interface.
</t>
<t>
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 the network edge,
hence it is important to balance local computation versus communication cost.
</t>
<t>
Storage constraints of the IoT devices limit the amount of data that
can be stored on the devices. This constraint means that unused
sensor data may need to be discarded or stored in aggregated compact form time to time. Bandwidth
constraints of the IoT devices limit the amount of communication.
Such devices will have the same implication on the
system architecture as with the power constraints; namely, we cannot
afford to collect single sensor data generated by the
device and/or use complex signaling protocols.
</t>
<t>
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.
</t>
</section>
<section anchor="charact" title="Traffic Characteristics">
<t>
IoT traffic can be broadly classified into local area traffic and
wide area traffic. Local area traffic is between nearby devices.
For example, neighboring cars may work together to detect potential
hazards on the highway, sensors deployed in the same room may
collaborate to determine how to adjust the heating level in the room.
These local area communications often involve data aggregation and
filtering, have real time constraints, and require fast device/data/
service discovery and association. At the same time, the IoT
platform has to also support wide area communications. For example, in Intelligent Transportation Systems, re-routing operations may require a broad knowledge of the status of the system, traffic load, availability of freights, whether forecasts and so on. Wide area communications
require efficient data/service discovery and resolution services.
</t>
<t>
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 <xref target="m2m" />, which means that we have to optimize the
bandwidth/energy consumption in both directions. Further, IoT traffic demonstrates certain
periodicity and burstiness <xref target="m2m" />. As a result, when provisioning the system, the shape of the traffic
volume has to be properly accounted for.
</t>
</section>
<section anchor="Contextual" title="Contextual Communication">
<t>
Many IoT applications shall rely on contextual information such as
social, relationships of owners, administrative groupings, 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 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.
</t>
<t>
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.
</t>
</section>
<section anchor="handling" title="Handling Mobility">
<t>
There are several degrees of mobility in a unified IoT platform,
ranging from static as in fixed assets to highly dynamic in vehicle-
to-vehicle environments.
</t>
<t>
Mobility in the IoT platform can mean 1) the data producer mobility
(i.e., location change), 2) the data consumer mobility, 3) IoT
Network mobility (e.g., a body-area network in motion as a person is walking); and 4) disconnection between the data source and
destination pair (e.g., due to unreliable wireless links). The
requirement on mobility support is to be able to deliver IoT data
below an application's acceptable delay constraint in all of the above
cases, and and if necessary to negotiate different connectivity or security constraints specific to each mobile context.
</t>
</section>
<section anchor="storage" title="Storage and Caching">
<t>
Storage and caching plays a very significant role depending on the
type of IoT ecosystem, also a function
subjected to privacy and security guidelines. In a unified IoT
platform, depending on application requirements, content caching may or may not be policy driven.
If caching is pervasive, intermediate nodes don't need to
always forward a content request to its original creator; rather,
locating and receiving a cached copy is sufficient for IoT
applications. This optimization can greatly reduce the content
access latencies.
</t>
<t>
Furthermore considering hierarchical nature of IoT systems, ICN architectures enable a more flexible, heterogeneous and potentially fault-tolerant approach to storage providing persistence
at multiple levels.
</t>
<t>
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.
</t>
</section>
<section anchor="security" title="Security and Privacy">
<t>
In addition to the fundamental challenge of trust management, a variety
of security and privacy concerns also exist in ICNs.
</t>
<t>
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 <xref target="secur"/>.
</t>
<t>
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.
</t>
</section>
<section anchor="reliability" title="Communication Reliability">
<t>
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, storage etc.).
</t>
</section>
<section anchor="organization" title="Self-Organization">
<t>
The unified IoT platform should be able to self-organize to meet
various application requirements, especially the capability to
quickly discover heterogeneous and relevant (local or global) devices/data/services
based on the context. This discovery can be achieved through an
efficient platform-wide publish-subscribe service, or through private
community grouping/clustering based upon trust and other security
requirements. In the former case, the publish-subscribe service must
be efficiently implemented, able to support seamless mobility, in-
network caching, name-based routing, etc. In the latter case, the
IoT platform needs to discover the private community groups/clusters
efficiently.
</t>
</section>
<section anchor="adhoc" title="Ad hoc and Infrastructure Mode">
<t>
Depending upon whether there is communication infrastructure, an IoT
system can operate either in ad-hoc or infrastructure mode.
</t>
<t>
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.
</t>
<t>
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.
</t>
</section>
<section anchor="openapi" title="Open API">
<t>
General IoT applications involve sensing, processing, and secure
content distribution occurring at various timescales and at multiple levels of hierarchy depending on the
application requirements. This requires open APIs to be generic
enough to support commonly used interactions
between consumers, content producer, and IoT services, as opposed to
proprietary APIs that are common in today's systems. Examples include
pull, push, and publish/subscribe mechanisms using common naming, payload,
encryption and signature schemes.
</t>
</section>
</section>
<section anchor="state" title="State of the Art">
<t>
Over the years, many stand-alone IoT systems have been deployed in
various domains. These systems usually adopt a vertical silo
architecture and support a small set of pre-designated applications.
A recent trend, however, is to move away from this approach, towards
a unified IoT platform in which the existing silo IoT systems, as
well as new systems that are rapidly deployed. This will make their data
and services accessible to general Internet applications (as in ETSI-
M2M and oneM2M standards). In such a unified platform, resources can be accessed over Internet and shared across the
physical boundaries of the enterprise. However, current
approaches to achieve this objective are based upon Internet
overlays, whose inherent inefficiencies due to IP protocol <xref target="mobilityfirst" /> hinders the platform from
satisfying the IoT requirements outlined earlier (particularly in
terms of scalability, security, mobility, and self-organization)
</t>
<section anchor="silo" title="Silo IoT Architecture">
<?rfc needLines="15" ?>
<figure>
<artwork>
<![CDATA[
[IoT Server]
|
|
______|_______
_______ { }
{ } { }
{IoT Dev}\ { Internet }---[IoT Application]
{_______} [IoTGW]---{ }
{ }
{______________}
Figure 1:Silo architecture of standalone IoT systems
]]>
</artwork>
</figure>
<t>
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.
</t>
<t>
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.
</t>
</section>
<section anchor="overlay" title="Overlay Based Unified IoT Solutions">
<t>
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<xref target="etsi" />, oneM2M<xref target="onem2m" />,and CORE<xref target="CORE" />. 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.
</t>
<t>
<?rfc needLines="16" ?>
<figure>
<artwork>
<![CDATA[
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
]]>
</artwork>
</figure>
</t>
<section anchor="weaknesses" title="Weaknesses of the Overlay-based Approach">
<t>
The above overlay-based approach can work with many different
protocols, but the system is built upon today's IP network,
which has inherent weaknesses towards supporting a unified IoT
system. As a result, it cannot satisfy some of the requirements we
outlined in Section 2:
<list style="symbols">
<t>
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.
</t>
<t>
Trust. Trust management schemes are still relatively weak, focusing
on securing communication channels rather than managing the data that
needs to be secured directly.
</t>
<t>
Mobility. 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 required to deploy current IoT solutions limit the scalability and management of these systems.
</t>
<t>
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, could seriously
limit the performance of this approach.
</t>
<t>
Traffic Characteristics. In this approach, applications are
written in a host-centric manner suitable for point-to-point
communication. IoT requires multicast support that is
challenging in overlay systems today.
</t>
<t>
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.
</t>
<t>
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 or name-based lookup.
<!--Also,"anywhere" storage requires de-coupling applications from the transport semantics.
applications are written in a host-centric manner, wherein network
requests are bound to a specific destination host/server instead
of at the granularity of a specific piece of content. -->
</t>
<t>
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. In addition to topological self-organization, IoT also requires data- and service-level self-organization <xref target="iotaid"/>, which is not supported by the overlay approach.
</t>
<t>
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.
</t>
</list>
</t>
</section>
</section>
</section>
<section anchor="icncha" title="ICN Challenges for IoT">
<t>
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 <xref target="ndniot"/>, data processing, and content
distribution models to meet specific application requirements which
we identify as challenges in this section. We also discuss scenario specific challenges discussed
in Section 5.
</t>
<section anchor="naming" title="Naming and Name Resolution">
<t>
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 <xref target="pubsubiot"/> <xref target="rnsa"/> <xref target="scalableiot"/> <xref target="icniot"/>. The objective is to achieve scalable
name resolution handling static and dynamic ICN entities with low
complexity and control overhead. In particular, the main
requirements/challenges of a name space (and the corresponding Name
Resolution System where necessary) are <xref target="dhtname"/> <xref target="cacheless"/>:
<list style="symbols">
<t>
Scalability: The first challenge faced by ICN-IoT name resolution system is its scalability. Firstly, the approach has to support billions of objects and devices that are connected to the Internet, many of which are crossing administrative domain boundaries. Second of all, in addition to objects/devices, the name resolution system is also responsible for mapping IoT services to their network addresses. Many of these services are based upon contexts, hence dynamically changing, as pointed out in <xref target="pubsubiot"/>. As a result, the name resolution should be able to scale gracefully to cover a large number of names/services with wide variations (e.g., hierarchical names, flat names, names with limited scope, etc.). Notice that, if hierarchical names are used, scalability can be also supported by leveraging the inherent aggregation capabilities of the hierarchy. Advanced techniques such as hyperbolic routing <xref target="sust"/> may offer further scalability and efficiency.
</t >
<t>
Trust: We need to ensure the name of a network element is issued by a trustworthy issuer in the context of the application, such as a trusted organization in [44]. Further the validity of each piece of data published by an authorized entity in the namespace should be verifiable - e.g., by following a hierarchical chain-of-trust to a root that is acceptable for the application. See <xref target="securebuild"/> for an example.
</t>
<t>
Deployability and interoperability: Graceful deployability and interoperability with existing platforms is a must to ensure a naming schema to gain success on the market <xref target="Enhance"/>. As a matter of fact, besides the need to ensure coexistence between IP-centric and ICN-IoT systems, it is required to make different ICN-IoT realms, each one based on a different ICN architecture, to interoperate.
</t>
<t>
Flexibility: Further challenges arise for hierarchical naming schema: referring to
requirements on "constructable names" and "on-demand publishing" <xref target="voccn"/><xref target="icscities"/>.
The former entails that each user is able to construct the name of a desired data item through specific algorithms and that it
is possible to retrieve information also using partially specified
names. The latter refers the possibility to request a content that
has not yet been published in the past, thus triggering its creation.
</t>
<t>
Latency: For real-time or delay sensitive M2M application, the name resolution should not affect the overall QoS. With reference to this issue
it becomes important to circumvent too centralized resolution schema (whatever the naming style, i.e, hierarchical or flat) by enforcing in-network
cooperation among the different entities of the ICN-IoT system, when possible <xref target="etsim2m"/>. In addition, fast name lookup are necessary to ensure soft/hard real
time services <xref target="scalablelookup"/><xref target="namefilter"/><xref target="towardfast"/>. This challenge is especially important for applications with stringent latency requirements, such as health monitoring,
emergency handling and smart transportation <xref target="namednetiot"/>.
</t>
<t>
Locality and network efficiency: During name resolution the named entities closer to the consumer should be easily accessible (subject to the application requirements).
This requirement is true in general because, whatever the network, if the edges are able to satisfy the requests of their consumers, the load of the core and content seek time
decrease, and the overall system scalability is improved. This facet gains further relevance in those domains where an actuation on the environment has to be executed, based
on the feedbacks of the ICN-IoT system, such as in robotics applications, smart grids, and industrial plants <xref target="iotaid"/>.
</t>
<t>
Agility: Some data items could disappear while some other ones are created so that the name resolution system should be able to effectively take care of these dynamic conditions.
In particular, this challenge applies to very dynamic scenarios (e.g., VANETs) in which data items can be tightly coupled to nodes that can appear and disappear
very frequently.
</t>
<t>
Control/scoping: Some information could be accessible only within a given scope. This challenge is very relevant for
smart home and health monitoring applications, where privacy issues play a key role and the local scope of a home or healthcare environment may be well-defined. However, perimeter- and channel-based access control is often violated in current networks to enable over-the-wire updates and cloud-based services, so scoping is unlikely to replace a need for data-centric security in ICN.
</t>
<t>
Confidentiality: As names can reveal information about the nature of the communication, mechanisms for name confidentiality should be available in the ICN-IoT architecture.
</t>
</list>
In addition to the above general requirements, we identify the following specific requirements for different IoT applications:
<list style="symbols">
<t>
Smart homes require names that can enable local and wide
area interactions; Also, security, privacy, and access control is
particularly important for smart homes.
</t>
<t>
Smart grids require names and name resolution system that can enable networked
control loops, real-time control, and security.
</t>
<t>
Smart transportation systems require names and name resolution system to be able
to handle extreme mobility, short latency and security. In addition, the mobility patterns of transportation systems increase the likelyhood that a user migrates from one network realm to another one during the journey. In this case, names and NRS should be designed in such a way to enable interoperability between different heterogeneous ICN realms and/or ICN and IP realms <xref target="BoyVoyage"/>.
</t>
<t>
Smart healthcare system requires names and name resolution system to enable real-
time interactions, dependability, and security.
</t>
<t>
Smart campus systems usually consist of hetereogeneous IoT
services, thus requring names and name resolution system to enable resource/
service ownership, and be application-centric.
</t>
</list>
</t>
</section>
<section anchor="cachestorage" title="Caching/Storage">
<t>
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.
</t>
<t>
Caching in ICN-IoT faces several challenges:
<list style="symbols">
<t>
The main challenge is to determine which nodes on the routing path should cache the data. According to <xref target="cacheless"/>, 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 <xref target="catt"/>, selecting a random router to cache data is as good as caching the content everywhere. In <xref target="lesspain"/>, the authors suggest that
edge caching provides most of the benefits of in-network caching typically discussed in NDN, with simpler deployment. However, it and other papers consider workloads
that are analogous to today's CDNs, not the IoT applications considered here. Further work is likely required to understand the appropriate caching approach for IoT applications.
</t>
<t>
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 <xref target="iotmf"/>, the authors suggest to cache IoT services on intermediate routers,
and in <xref target="pubsubiot"/>, the authors suggest to cache control information such as pub/sub lists on intermediate nodes. In addition, it is yet unclear what caching means
in the context of actuation in an IoT system. For example, it could mean caching the result of a previous actuation request (using other ICN mechanisms to suppress repeated
actuation requests within a given time period), or have little meaning at all if actuation uses authenticated requests as in <xref target="lighting"/>.
</t>
</list>
</t>
<t>
Next we use specific IoT systems to explain the caching challenge:
<list style="symbols">
<t>
Smart homes may use in-network caching at gateway to
enable efficient content access
</t>
<t>
Smart grids may use in-network caching to back up valuable data
</t>
<t>
Smart transportation may implement in-network caching on
vehicles for efficient information dissemination
</t>
<t>
Smart healthcare may use in-network caching for rapid information
dissemination
</t>
<t>
Smart campus systems may use in-network caching to enable
social interactions and efficient content access.
</t>
</list>
</t>
</section>
<section anchor="routingandforwarding" title="Routing and Forwarding">
<t>
Routing in ICN-IoT differs from routing in traditional IP networks in that ICN routing is based upon names instead of locators. Broadly speaking,
ICN routing can be categorized into the following two categories: direct name-based routing and indirect routing using a name resolution service (NRS).
<list style="symbols">
<t>
In direct name-based routing, packets are forwarded by the name of the data <xref target="icniot"/><xref target="ndniot"/><xref target="potential"/> or the name of the destination node <xref target="gstar"/>.
Here, the main challenge is to keep the ICN router state required to route/forward data low. This challenge becomes more serious when a flat naming scheme is used due to the lack of aggregation capabilities.
</t>
<t>
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.
</t>
</list>
</t>
<t>
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:
<list style="symbols">
<t>
When a consumer moves to a new location after sending out the request for Data, the Data may get lost, which requires the consumer
to simply resend the request, a technique used by direct routing approach. Indirect routing approach doesn't differentiate between consumer and producer mobility <xref target="icniot"/>, also network caching can improve data recovery for this approach. <!--Depending on the network topology and data availability, the new Interest might be forwarded to the same or a different data producer. -->
</t>
<t>
If the data producer itself has moved, the challenge is to control
the control overhead while searching for a new data producer (or for the same data producer in its new position).
To this end, flooding techniques could be used, but an intra-domain level only, otherwise the network stability
would be seriously impaired. For handling mobility across different domains, more sophisticated approaches could be used,
including the adoption of a SDN-based control plane.
</t>
</list>
</t>
<t>
Finally, in addition to the above requirements, specific IoT applications may
impose specific challenges on routing and forwarding:
<list style="symbols">
<t>
In smart homes, we need local, intra-domain and inter-domain
routing protocols.
</t>
<t>
In smart grids, we often require very timely data delivery. Therefore,
it is important to be able to locate the closest information. In
addition, routing/forwarding robustness and resilience is also
critical.
</t>
<t>
In smart transportation, vehicle-to-vehicle ad-hoc communication is
required for efficient information dissemination.
</t>
<t>
In smart healthcare, timely and dependable routing and information
forwarding is the key.
</t>
<t>
In smart campus, inter-domain routing protocols are required which
often need short latency.
</t>
</list>
</t>
</section>
<section anchor="contextcom" title="Contextual Communication ">
<t>
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 <xref target="iotmf"/>. 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. Alternatively, naming conventions could be used to allow applications to request content in namespaces related to their local context without requiring a specific service, such as /local/geo/mgrs/4QFJ/123/678 to retrieve objects published in the 100m grid area 4QFJ 123 678 of the military grid reference system (MGRS). In both cases, trust providers may emerge that can vouch for an application's local knowledge.
</t>
<t>
However, extracting contextual information on a real-time basis is very challenging:
<list style="symbols">
<t>
We need to have a fast context resolution service through which
the involved IoT devices can continuously update its contextual
information to the application (e.g., each taxi's location and
Jame's information in the above example). Or, in the namespace driven approach, mechanisms for continuous nearest neighbor queries in the namespace need to be developed.
</t>
<t>
The difficulty of this challenge grows rapidly when the number of
devices involved in a context as well as the number of contexts
increases.
</t>
</list>
</t>
<t>
Next, in addition to the above requirements, specific IoT services may
impose specific challenges on contextual communication:
<list style="symbols">
<t>
In smart homes many control loops and actions are depend heavily on the context, and the
contexts evolve with time, e.g., temperature, weather, number of
occupants, etc
</t>
<t>
In smart grids, contextual information such as location, time, voltage fluctuations, depending on the specific segment of the grid, can be used to optimize several power distribution objectives.
</t>
<t>
In smart transportation, many different contexts exist,
intertwined to each other and highly changing, which include
location - both geographical and jurisdictional, time - absolute and relative to a schedule, traffic, speed, etc.
</t>
<t>
In smart healthcare several contexts can be used to delineate between levels of care and urgency, for example delineating between chronic, everyday, urgent, and emergency situations. Such contexts can evolve rapidly with significant impact to individuals health. Hence
timely and accurate detection of contexts is critical.
</t>
<t>
In smart campus, due to the existence of many services, relevant contextual inputs can be used to improve the quality and efficiency of different services.
</t>
</list>
</t>
</section>
<section anchor="innetwork" title="In-network Computing">
<t>
In-network computing enables ICN routers to host heterogenous services catering to various network functions and applications needs. Contextual services for IoT networks require in-network computing, in which each sensor node or ICN router implements context reasoning <xref target="iotmf"/>.
Another major purpose of in-network computing is to filter and cleanse sensed data in IoT applications is critical as the data is noisy as is <xref target="miami"/>.
Named Function Networking <xref target="icncompute"/> describes an extension of the ICN concept to named functions processed in the network, which could be used to generate data flow processing applications well-suited to, for example, time series data processing in IoT sensing applications.
<list style="symbols">
<t>
In smart homes, local services can provide value-added contributions to a standardized home gateway network, through features such as reporting, context-based control, coordination with mobile devices, etc.
</t>
<t>
In smart grids, we often rely on in-network computing to increase
the scalability and efficiency of the system, putting computation closer to the data sources.
</t>
<t>
In smart transportation, in-network computing is very useful to make
vehicle become an active element of the system and to improve
response time and scalability.
</t>
<t>
In smart healthcare, in-network computing can help resolve
contexts and ensure security and dependability, as well as provide low-latency responses to urgent situations.
</t>
<t>
In smart campus, in-network computing services can be used to provide context for different applications.
</t>
</list>
</t>
</section>
<section anchor="cachestoragecha" title="Security and Privacy">
<t>
Security and privacy is crucial to all the IoT applications including the use cases discussed in Section 5. In one recent demonstration,
it was shown that passive tire pressure sensors in cars could be hacked and used as a gateway into the automotive system <xref target="tirepresure"/>.
Though ICN includes data-centric security features the mechanisms have to be generic enough to satisfy multiplicity of policy requirements
for different applications. Furthermore security and privacy concerns have to be dealt in a scenario-specific manner with respect to network function perspective spanning naming, name-resolution, routing, caching, and ICN-APIs. 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.
</t>
<t>
Implementing security and privacy methods faces different challenges in the constrained and infrastructure part of the network.
<list style="symbols">
<t>
In the resource-constrained nodes, 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 <xref target="physicalsec"/> <xref target="iotmf"/>.
</t>
<t>
In the infrastructure part, we have several new threats introduced by ICN-IoT <xref target="ncrs"/>:
<list style="numbers">
<t>
We need to ensure the name of a network element is issued by a trustworthy organization entity such as in <xref target="handle"/>, or by its trusted delegate.
</t>
<t>
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.
</t>
<t>
An intruder may mimic an authorized user or network process. As a result, the intruder may forge signatures, or impersonate a source address.
</t>
<t>
An adversary may manipulate the message exchange process between network entities. Such manipulation may involve replay, rerouting, mis-routing and deletion of messages.
</t>
<t>
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.
</t>
</list>
</t>
</list>
</t>
<t>
Finally, in addition to the above requirements, specific IoT applications may impose specific challenges on privacy that impact both applications and the ICN-IoT network:
<list style="symbols">
<t>
In smart homes, the access to networked information should be shielded to protect the privacy of
people, for example, cross-correlation of device activity patterns to infer higher-level activity information.
</t>
<t>
In smart grids, energy consumptions profiles should not been never
disclosed at a fine granularity since from them it is possible to violate
the privacy of users.
</t>
<t>
In smart transportation, the habits of users can be inferred by
looking at their movement patterns -- privacy protection is
essential.
</t>
<t>
In smart healthcare, personal medical data about patients should
remain shielded to protect their privacy, implementing both regulatory requirements and current industry best practices.
</t>
<t>
In smart campus, it is required to differentiate among different profiles
and to allocate different rights and protection levels to them.
</t>
</list>
</t>
</section>
<section anchor="energy" title="Energy Efficiency">
<t>
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 4.1-4.6 for challenges associated with energy efficiency for ICN-IoT.
</t>
</section>
</section>
<section anchor="scenarios" title="Popular Scenarios">
<t>
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.
</t>
<section anchor="homes" title="Homes">
<t>
The home <xref target="building"/> 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. In addition, several IoT-enabled homes could form a smart district where it becomes possible to bargain resources and trade with utility suppliers.
</t>
<t>
Homes <xref target="smarthome"/><xref target="iotgateway"/> 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
<xref target="contexthome"/>; (2) inter-operability: 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; (5) user interface / user experience: homes need to provide reasonable
interfaces to their highly heterogeneous IoT networks for users with a variety of skill levels, backgrounds, cultures, interests, etc.
</t>
</section>
<section anchor="enterprise" title="Enterprise">
<t>
Enterprise building deployments, from university campuses <xref target="smartcampus"/> <xref target="spark"/> <xref target="smartparking"/> <xref target="smartCamputIoT"/> 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.
</t>
<t>
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
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.
</t>
<t>
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) security: security for IoT applications in the enterprise should integrate with other enterprise-wide security components.
</t>
</section>
<section anchor="smartgridsec" title="Smart Grid">
<t>
Central to the so-called "smart grid"<xref target = "smartgrid"/> 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.
</t>
<t>
Deployment of the smart grid <xref target="researchgrid"/> <xref target="visiongrid"/> 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.
</t>
</section>
<section anchor="transportation" title="Transportation">
<t>
We are currently witnessing the increasing integration of sensors
into cars, other vehicles transportation systems <xref target="urbantransport"/>. 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),Vehicle-to-Roadside (V2R), 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.
</t>
<t>
Transportation <xref target="urbantransport"/><xref target="transportiot"/> 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; ; also, during the journey the user might cross several realms, each one implementing different stacks (whether ICN or IP); (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.
</t>
</section>
<section anchor="healthcare" title="Healthcare">
<t>
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 <xref target="living"/>. 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. In addition to this dimension, assistive robotics applications are gaining momentum to provide 24/24 7/7 assistance to patients <xref target="iotaid"/>.
</t>
<t>
Healthcare <xref target="living"/><xref target="ehealth"/> 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-operability: healthcare systems must operate with
heterogeneous devices 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; (4) privacy: user trust in healthcare systems is critical, and privacy considerations paramount to garner adoption and continued user; (5) user interface / user experience: the highly heterogeneous nature of real-world healthcare systems, which will continue to increase through the introduction of IoT devices, presents significant challenges in interface design that may have architectural implications.
</t>
</section>
<section anchor="education" title="Education">
<t>
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 micro-controller 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.
</t>
<t>
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; (5) programming interfaces must be carefully developed to expose important concepts clearly and in light of current best practices in education.
</t>
</section>
<section anchor="art" title="Entertainment, arts, and culture">
<t>
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).
</t>
<t>
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 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.
</t>
</section>
</section>
</middle>
<back>
<references title="Informative References">
<reference anchor="cisco">
<front>
<title>Cisco visual networking index: Global mobile data traffic forecast update.</title>
<author initials="CISCO" surname="Cisco System Inc." > </author>
<date year="2009-2014"/>
</front>
</reference>
<reference anchor="m2m">
<front>
<title>A first look at cellular machine-to-machine traffic: large scale measurement and
characterization.</title>
<author initials="M" surname="Shafig" fullname="M. Shafig">
</author>
<author initials="L" surname="Ji" fullname="L. Ji"></author>
<author initials="A." surname="Liu" fullname="A. Liu"></author>
<author initials="J" surname="Pang" fullname="J. Pang"></author>
<author initials="J" surname=" Wang" fullname="J. Wang"></author>
<date year="2012"/>
</front>
<seriesInfo name="Proceedings of the ACM Sigmetrics" value="" />
</reference>
<reference anchor="etsi">
<front>
<title>http://www.etsi.org/.</title>
<author initials="ETSI" surname="The European Telecommunications Standards Institute" fullname="ETSI">
</author>
<date year="1988"/>
</front>
</reference>
<reference anchor="onem2m">
<front>
<title>http://www.onem2m.org/.</title>
<author initials="oneM2M" surname="Global Intiative for M2M Standardization" fullname="oneM2M">
</author>
<date year="2012"/>
</front>
</reference>
<reference anchor="CORE">
<front>
<title>https://datatracker.ietf.org/wg/core/charter/.</title>
<author initials="CoRE" surname="Constrained RESTful Environments" fullname=" Constrained RESTful Environments (CORE)">
</author>
<date year="2013"></date>
</front>
</reference>
<reference anchor="TREES">
<front>
<title> Information-Centric Networking: Seeing the Forest of the Trees.</title>
<author initials="A." surname="Ghodsi" fullname="A. Ghodsi"></author>
<author initials="S" surname="Shenker" fullname="S.Shenker"></author>
<author initials="T" surname="Koponen" fullname="T. Koponen"></author>
<author initials="A" surname="Singla" fullname="A. Singla"></author>
<author initials="B" surname="Raghavan" fullname="B. Raghavan"></author>
<author initials="J" surname="Wilcox" fullname="J. Wilcox"></author>
<date year="2011"/>
</front>
<seriesInfo name="Hot Topics in Networking" value="" />
</reference>
<reference anchor="Enhance">
<front>
<title>Enhance Content Broadcast Efficiency in Routers with Integrated Caching.</title>
<author initials="L" surname="Dong" fullname="L.Dong">
</author>
<author initials="Y" surname="Zhang" fullname="Y.Zhang">
</author>
<author initials="D" surname="Raychaudhuri" fullname="D.Raychaudhuri">
</author>
<date year="2011"/>
</front>
<seriesInfo name="Proceedings of the IEEE Symposium on Computers and Communications (ISCC)" value="" />
</reference>
<reference anchor="mobilityfirst">
<front>
<title>http://www.nets-fia.net/</title>
<author initials="MobilityFirst" surname="NSF FIA project" fullname="MobilityFirst: NSF FIA project">
</author>
<date year="2010"/>
</front>
</reference>
<reference anchor="mobiiscape">
<front>
<title>Mobiiscape: Middleware Support for Scalable Mobility Pattern Monitoring of Moving Objects in a Large-Scale City.</title>
<author initials="B" surname="Kim" fullname="Byoungjip, Kim">
</author>
<author initials="S" surname="Lee" fullname="SangJeong, Lee">
</author>
<author initials="Y" surname="Lee" fullname="Youngki, Lee">
</author>
<author initials="I" surname="Hwang" fullname="Insoek, Hwang">
</author>
<author initials="Y" surname="Rhee" fullname="Yunseok, Rhee">
</author>
<date year="Journal of Systems and Software, Elsevier, 2011"></date>
</front>
</reference>
<reference anchor="building">
<front>
<title>Communication and Computation in Buildings: A Short Introduction and Overview</title>
<author initials="D" surname="Dietrich" fullname="Dietmar, Dietrich">
</author>
<author initials="D" surname="Bruckne" fullname="Dietmar, Bruckne">
</author>
<author initials="G" surname="Zucker" fullname="Gerhard, Zucker">
</author>
<author initials="P" surname="Palensky" fullname="Peter Palensky">
</author>
<date year="IEEE Transactions on Industrial Electronics, 2010"></date>
</front>
</reference>
<reference anchor="secur">
<front>
<title>Guide to Industrial Control Systems (ICS) Security</title>
<author initials="K" surname="Keith" fullname="Stouffer, Keith">
</author>
<author initials="F" surname="Falco" fullname="Joseph, Falco">
</author>
<author initials="K" surname="Scarfone" fullname="Karen, Scarfone">
</author>
<date year="NIST, Technical Report 800-82 Revision 1, 2013"></date>
</front>
</reference>
<reference anchor="smarthome">
<front>
<title>Smart home mobile RFID-based Internet-of-Things systems and services.</title>
<author initials="M" surname="Darianian" fullname="Mohsen Darianian">
</author>
<author initials="Martin" surname="Michael" fullname="Martin Peter Michael">
</author>
<date year="IEEE, ICACTE, 2008"></date>
</front>
</reference>
<reference anchor="iotgateway">
<front>
<title>IOT Gateway: Bridging Wireless Sensor Networks into Internet of Things</title>
<author initials="Q" surname="Zhu" fullname="Qian, Zhu">
</author>
<author initials="R" surname="Wang" fullname="Ruicong, Wang">
</author>
<author initials="Q" surname="Chen" fullname="Qi, Chen">
</author>
<author initials="Y" surname="Chen" fullname="Yan, Liu">
</author>
<author initials="W" surname="Qin" fullname="Weijun, Qin">
</author>
<date year="IEEE/IFIP, EUC, 2010"></date>
</front>
</reference>
<reference anchor="contexthome">
<front>
<title>Contextualized information-centric home network</title>
<author initials="T" surname="Biswas" fullname="Trisha, Biswas">
</author>
<author initials="A" surname="Chakrabort" fullname="Asit, Chakraborti">
</author>
<author initials="R" surname="Ravindran" fullname="Ravishankar, Ravindran">
</author>
<author initials="X" surname="Zhang" fullname="Xinwen, Zhang">
</author>
<author initials="G" surname="Wang" fullname="Guoqiang, Wang">
</author>
<date year="ACM, Siggcomm, 2013"></date>
</front>
</reference>
<reference anchor="smartcampus">
<front>
<title>Smart Campus: The Developing Trends of Digital Campus</title>
<author initials="R" surname="Huang" fullname="Ronghuai, Huang">
</author>
<author initials="J" surname="Zhang" fullname="Jinbao, Zhang">
</author>
<author initials="Y" surname="Hu" fullname="Yongbin, Hu">
</author>
<author initials="J" surname="Yang" fullname="Junfeng, Yang">
</author>
<date year="2012"></date>
</front>
</reference>
<reference anchor="smartgrid">
<front>
<title>A Survey on Smart Grid Communication Infrastructures: Motivations, Requirements and Challenges</title>
<author initials="Y" surname="Yan" fullname="Ye, Yan">
</author>
<author initials="Y" surname="Qian" fullname="Yi, Qian">
</author>
<author initials="Y" surname="Hu" fullname="Hamid, Sharif">
</author>
<author initials="J" surname="Yang" fullname="David, Tipper">
</author>
<date year="IEEE Communications Survey and Tutorials, 2013"></date>
</front>
</reference>
<reference anchor="researchgrid">
<front>
<title>Research on the Architecture and Key Technology of Internet of Things (loT) Applied on Smart Grid</title>
<author initials="Y" surname="Miao" fullname="Yun, Miao">
</author>
<author initials="Y" surname="Bu" fullname="Yuxin, Bu">
</author>
<date year="IEEE, ICAEE, 2010"></date>
</front>
</reference>
<reference anchor="visiongrid">
<front>
<title>Cognitive Machine-to-Machine Communications: Visions and Potentials for the Smart Grid</title>
<author initials="Y" surname="Zhang" fullname="Yan, Zhang">
</author>
<author initials="R" surname="Yu" fullname="Rong, Yu">
</author>
<author initials="M" surname="Nekovee" fullname="Maziar, Nekovee">
</author>
<author initials="Y" surname="Liu" fullname="Yi, Liu">
</author>
<author initials="S" surname="Xie" fullname=" Shengli, Xie">
</author>
<author initials="S" surname="Gjessing" fullname="Stein, Gjessing">
</author>
<date year="IEEE, Network, 2012"></date>
</front>
</reference>
<reference anchor="urbantransport">
<front>
<title>Design and Research of Urban Intelligent Transportation System Based on the Internet of Things</title>
<author initials="H" surname="Zhou" fullname="Hong, Zhou">
</author>
<author initials="B" surname="Liu" fullname="Bingwu, Liu">
</author>
<author initials="D" surname="Wang" fullname="Donghan, Wang">
</author>
<date year="Springer Link, 2012"></date>
</front>
</reference>
<reference anchor="transportiot">
<front>
<title>Smart Transport System Based on the Internet of Things</title>
<author initials="M" surname="Zhang" fullname="Min, Zhang">
</author>
<author initials="T" surname="Yu" fullname="Tao, Yu">
</author>
<author initials="G" surname="Zhai" fullname="Guofang, Zhai">
</author>
<date year="Applied Mechanics and Materials, 2012"></date>
</front>
</reference>
<reference anchor="living">
<front>
<title>The Internet of Things for Ambient Assisted Living</title>
<author initials="A" surname="Zhang" fullname="A, Dohr">
</author>
<author initials="R" surname="Yu" fullname=" Modre, Osprian">
</author>
<author initials="M" surname="Nekovee" fullname="M. Drobics">
</author>
<author initials="S" surname="Xie" fullname="G.Schreier">
</author>
<date year="IEEE, ITNG, 2010"></date>
</front>
</reference>
<reference anchor="ehealth">
<front>
<title>Towards metrics-driven adaptive security management in E-health IoT applications.</title>
<author initials="R" surname="Savola" fullname="Reijo M, Savola">
</author>
<author initials="H" surname="Abie" fullname=" Habtamu, Abie">
</author>
<author initials="M" surname="Sihvonen" fullname="Markus, Sihvonen">
</author>
<date year="ACM, BodyNets, 2012"></date>
</front>
</reference>
<reference anchor="voccn">
<front>
<title>VoCCN: Voice-over Content-Centric Networks</title>
<author initials="V" surname="Jacobson" fullname="Van Jacobson">
</author>
<author initials="D" surname="Smetters" fullname="Diana K. Smetters">
</author>
<author initials="M" surname="Plass" fullname="Michael F. Plass">
</author>
<author initials="P" surname="Stewart" fullname="Paul, Stewart">
</author>
<author initials="J" surname="Thornton" fullname="James D. Thornton">
</author>
<author initials="R" surname="Braynard" fullname="Rebecca L. Braynard">
</author>
<date year="ACM, ReArch, 2009"></date>
</front>
</reference>
<reference anchor="icscities">
<front>
<title>Information Centric Services in Smart Cities</title>
<author initials="G" surname="Piro" fullname="G, Piro">
</author>
<author initials="I" surname="Cianci" fullname="I, Cianci">
</author>
<author initials="L" surname="Grieco" fullname="L, Grieco">
</author>
<author initials="G" surname="Boggia" fullname="G, Boggia">
</author>
<author initials="P" surname="Camarda" fullname="P, Camarda">
</author>
<date year="ACM, Journal of Systems and Software, 2014"></date>
</front>
</reference>
<reference anchor="homenet">
<front>
<title>Information-centric Networking based Homenet</title>
<author initials="R" surname="Ravindran" fullname="Ravishankar, Ravindran">
</author>
<author initials="T" surname="Biswas" fullname="Trisha, Biswas">
</author>
<author initials="X" surname="Zhang" fullname="Xinwen, Zhang">
</author>
<author initials="A" surname="Chakrabort" fullname="Asit, Chakraborti">
</author>
<author initials="G" surname="Wang" fullname="Guoqiang, Wang">
</author>
<date year="IEEE/IFIP, 2013"></date>
</front>
</reference>
<reference anchor="dhtname">
<front>
<title>Hierarchical DHT-based name resolution for information-centric networks</title>
<author initials="C" surname="Dannewitz" fullname="Christian Dannewitz">
</author>
<author initials="M" surname="D' Ambrosio" fullname="Matteo D' Ambrosio">
</author>
<author initials="V" surname="Vercellone" fullname="Vinicio Vercellone">
</author>
<date year="2013"></date>
</front>
</reference>
<reference anchor="cacheless">
<front>
<title>Cache "less for more" in information-centric networks</title>
<author initials="W" surname="Chai" fullname="WeiKoong, Chai">
</author>
<author initials="D" surname="He" fullname="Diliang He">
</author>
<author initials="I" surname="Psaras" fullname="Ioannis Psaras">
</author>
<date year="ACM, IFIP, 2012"></date>
</front>
</reference>
<reference anchor="catt">
<front>
<title>Catt: potential based routing with content caching for icn</title>
<author initials="S" surname="Eum" fullname="Suyong, Eum">
</author>
<author initials="K" surname="Nakauchi" fullname="Kiyohide Nakauchi">
</author>
<author initials="M" surname="Murata" fullname="Masayuki, Murata">
</author>
<author initials="Yozo" surname="Shoji" fullname="Yozo, Shoji">
</author>
<author initials="N" surname="Nishinaga" fullname="Nozomu, Nishinaga">
</author>
<date year="IEEE Communication Magazine, 2012"></date>
</front>
</reference>
<reference anchor="iotmf">
<front>
<title>Enabling internet-of-things services in the mobilityfirst future internet architecture</title>
<author initials="S" surname="Eum" fullname="Jun, Li">
</author>
<author initials="Y" surname="Shvartzshnaider" fullname="Yan Shvartzshnaider">
</author>
<author initials="J" surname="Francisco" fullname="John-Austen, Francisco">
</author>
<author initials="R" surname="Martini" fullname="Richard P., Martini">
</author>
<author initials="D" surname="Raychaudhuri" fullname="Dipankar, Raychaudhuri">
</author>
<date year="IEEE, WoWMoM, 2012"></date>
</front>
</reference>
<reference anchor="pubsubiot">
<front>
<title>A low-delay, lightweight publish/subscribe architecture for delay-sensitive IOT services</title>
<author initials="Y" surname="Sun" fullname="Yunlei, Sun">
</author>
<author initials="X" surname="Qiao" fullname="Xiuquan, Qiao">
</author>
<author initials="B" surname="Cheng" fullname="Bo, Cheng">
</author>
<author initials="J" surname="Chen" fullname="Junliang, Chen">
</author>
<date year="IEEE, ICWS, 2013"></date>
</front>
</reference>
<reference anchor="ndniot">
<front>
<title>Information Centric Networking in the IoT:Experiments with NDN in the Wild</title>
<author initials="E" surname="Baccelli" fullname="Emmanuel, Baccelli">
</author>
<author initials="C" surname="Mehlis" fullname="Christian, Mehlis">
</author>
<author initials="O" surname="Hahm" fullname="Oliver, Hahm">
</author>
<author initials="T" surname="Schmidt" fullname="Thomas C., Schmidt">
</author>
<author initials="M" surname="Wahlisch" fullname="Matthias, Wahlisch">
</author>
<date year="ACM, ICN Siggcomm, 2014"></date>
</front>
</reference>
<reference anchor="archiot">
<front>
<title>Architecture for the Internet of Things (IoT): API and interconnect</title>
<author initials="I" surname="Gronbaek" fullname="I, Gronbaek">
</author>
<date year="IEEE, SENSORCOMM, 2008"></date>
</front>
</reference>
<reference anchor="rnsa">
<front>
<title>RNS-A Public Resource Name Service Platform for the Internet of Things</title>
<author initials="Y" surname="Tian" fullname="Ye, Tian">
</author>
<author initials="Y" surname="Liu" fullname="Yang, Liu">
</author>
<author initials="Z" surname="Yan" fullname="Zhiwei, Yan">
</author>
<author initials="S" surname="Wu" fullname="Shuangli, Wu">
</author>
<author initials="H" surname="Li" fullname="Hongyu, Li">
</author>
<date year="IEEE, GreenCom, 2012"></date>
</front>
</reference>
<reference anchor="scalableiot">
<front>
<title>Scalable id/locator resolution for the iot</title>
<author initials="G" surname="Roussos" fullname="George, Roussos">
</author>
<author initials="P" surname="Chartier" fullname="Paul, Chartier">
</author>
<date year="IEEE, iThings,CPSCom, 2011"></date>
</front>
</reference>
<reference anchor="potential">
<front>
<title>Potential of information-centric wireless sensor and actor networking</title>
<author initials="M" surname="Amadeo" fullname="Ngoc-Thanh, Dinh">
</author>
<author initials="C" surname="Campolo" fullname="Claudia Campolo">
</author>
<date year="IEEE, ComManTel, 2013"></date>
</front>
</reference>
<reference anchor="gstar">
<front>
<title>GSTAR: generalized storage-aware routing for mobilityfirst in the future mobile internet</title>
<author initials="S" surname="Nelson" fullname="Samuel C., Nelson">
</author>
<author initials="G" surname="Bhanage" fullname="Gautam, Bhanage">
</author>
<author initials="D" surname="Raychaudhuri" fullname="Dipankar, Raychaudhuri ">
</author>
<date year="ACM, MobiArch, 2011"></date>
</front>
</reference>
<reference anchor="miami">
<front>
<title>MIAMI: methods and infrastructure for the assurance of measurement information</title>
<author initials="W" surname="Trappe" fullname="Wade, Trappe">
</author>
<author initials="Y" surname="Zhang" fullname="Yanyong, Zhang">
</author>
<author initials="B" surname="Nath" fullname="Badri, Nath">
</author>
<date year="ACM, DMSN, 2005"></date>
</front>
</reference>
<reference anchor="tirepresure">
<front>
<title>Security and privacy vulnerabilities of in-car wireless networks: A tire pressure monitoring system case study</title>
<author initials="I" surname="Rouf" fullname="I. Rouf">
</author>
<author initials="H" surname="Mustafa" fullname="H. Mustafa">
</author>
<author initials="T" surname="Taylor" fullname="T. Taylor">
</author>
<author initials="S" surname="Oh" fullname="S. Oh">
</author>
<author initials="W" surname="Xu" fullname="W. Xu">
</author>
<author initials="M" surname="Gruteser" fullname="M. Gruteser">
</author>
<author initials="W" surname="Trappe" fullname="W. Trappe">
</author>
<author initials="I" surname="Seskar" fullname="I. Seskar">
</author>
<date year="USENIX, 2010"></date>
</front>
</reference>
<reference anchor="physicalsec">
<front>
<title>Securing Wireless Communications at the Physical Layer</title>
<author initials="R" surname="Liu" fullname="R, Liu">
</author>
<author initials="W" surname="Trappe" fullname="Wade, Trappe">
</author>
<date year="Springer, 2010"></date>
</front>
</reference>
<reference anchor="channel">
<front>
<title>Using the physical layer for wireless authentication in time-variant channels</title>
<author initials="L" surname="Xiao" fullname="Liang, Xiao">
</author>
<author initials="L" surname="Greenstein" fullname="Larry, Greenstein">
</author>
<author initials="N" surname="Mandayam" fullname="N, Mandayam">
</author>
<author initials="W" surname="Trappe" fullname="Wade, Trappe">
</author>
<date year="IEEE Transactions on Wireless Communications, 2008"></date>
</front>
</reference>
<reference anchor="handle">
<front>
<title>Handle system overview</title>
<author initials="S" surname="Sun" fullname="Sam, Sun">
</author>
<author initials="L" surname="Lannom" fullname="Larry Lannom">
</author>
<author initials="B" surname="Boesch" fullname="Brian Boesch">
</author>
<date year="IETF, RFC3650, 2003"></date>
</front>
</reference>
<reference anchor="ncrs">
<front>
<title>Secure Name Resolution for Identifier-to-Locator Mappings in the Global Internet</title>
<author initials="X" surname="Liu" fullname="Xiruo, Liu">
</author>
<author initials="W" surname="Trappe" fullname="Wade, Trappe">
</author>
<author initials="Y" surname="Zhang" fullname="Yanyong, Zhang">
</author>
<date year="IEEE, ICCCN, 2013"></date>
</front>
</reference>
<reference anchor="sust">
<front>
<title>Sustaining the internet with hyperbolic mapping</title>
<author initials="M" surname="Boguna" fullname="Boguna, Marian">
</author>
<author initials="P" surname="Fragkiskos" fullname="Fragkiskos Papadopoulos">
</author>
<author initials="K" surname="Dmitri" fullname="Dmitri Krioukov">
</author>
<date year="Nature Communications, 2010"></date>
</front>
</reference>
<reference anchor="securebuild">
<front>
<title>Securing building management systems using named data networking</title>
<author initials="W" surname="Shang" fullname="Shang, Wentao">
</author>
<date year="IEEE Network 2014"></date>
</front>
</reference>
<reference anchor="lesspain">
<front>
<title>Less pain, most of the gain: Incrementally deployable icn</title>
<author initials="S" surname="Fayazbakhsh" fullname="Fayazbakhsh, Seyed Kaveh">
</author>
<author initials="et al" surname="et al" fullname="">
</author>
<date year="ACM, Siggcomm, 2013"></date>
</front>
</reference>
<reference anchor="lighting">
<front>
<title>Securing instrumented environments over Content-Centric Networking: the case of lighting control</title>
<author initials="J" surname="Burke" fullname="Burke, Jeff">
</author>
<author initials="et al" surname="et al" fullname="">
</author>
<date year="INFOCOM, Computer Communications Workshop, 2013"></date>
</front>
</reference>
<reference anchor="icniot">
<front>
<title>A comparative study of MobilityFirst and NDN based ICN-IoT architectures</title>
<author initials="S" surname="Li" fullname="Li, Sugang">
</author>
<author initials="Y" surname="Zhang" fullname="Yanyong Zhang">
</author>
<author initials="R" surname="Dipankar" fullname="Dipankar Raychaudhuri">
</author>
<author initials="R" surname="Ravindran" fullname="Ravishankar Ravindran">
</author>
<date year="IEEE, QShine, 2014"></date>
</front>
</reference>
<reference anchor="etsim2m">
<front>
<title>Architecting Information Centric ETSI-M2M systems</title>
<author initials="L" surname="Grieco" fullname="Grieco, Luigi Alfredo">
</author>
<author initials="M" surname="Alaya" fullname="Mahdi Ben Alaya">
</author>
<author initials="K" surname="Drira" fullname="Khalil Drira">
</author>
<date year="IEEE, Pervasive and Computer Communications Workshop (PERCOM), 2014"></date>
</front>
</reference>
<reference anchor="iotaid">
<front>
<title>IoT-aided robotics applications: technological implications, target domains and open issues</title>
<author initials="L" surname="Grieco" fullname="Grieco, Luigi Alfredo">
</author>
<author initials="A" surname="Rizzo" fullname="A. Rizzo">
</author>
<author initials="R" surname="Colucci" fullname="S. Colucci">
</author>
<author initials="S" surname="Sicari" fullname="S. Sicari">
</author>
<author initials="G" surname="Piro" fullname="G. Piro">
</author>
<author initials="D" surname="Di Paola" fullname="D. Di Paola">
</author>
<author initials="G" surname="Boggia" fullname="G. Boggia">
</author>
<date year="Computer Communications, Volume 54, 1 December, 2014"></date>
</front>
</reference>
<reference anchor="scalablelookup">
<front>
<title>Scalable Name Lookup with Adaptive Prefix Bloom Filter for Named Data Networking</title>
<author initials="Wei" surname="Quan" fullname="Quan, Wei">
</author>
<author initials="C" surname="Xu" fullname="Changqiao Xu">
</author>
<author initials="J" surname="Guan" fullname="Jianfeng Guan">
</author>
<author initials="H" surname="Zhang" fullname="Hongke Zhang">
</author>
<author initials="L" surname="Grieco" fullname=" L. Grieco">
</author>
<date year="IEEE Communications Letters, 2014"></date>
</front>
</reference>
<reference anchor="namefilter">
<front>
<title>NameFilter: Achieving fast name lookup with low memory cost via applying two-stage Bloom filters</title>
<author initials="Yi" surname="Wang" fullname="Wang, Yi">
</author>
<author initials="T" surname="Pan" fullname="Tian Pan">
</author>
<author initials="Z" surname="Mi" fullname="Zhian Mi">
</author>
<author initials="H" surname="Dai" fullname="Huichen Dai">
</author>
<author initials="X" surname="Guo" fullname="Xiaoyu Guo">
</author>
<author initials="T" surname="Zhang" fullname="Ting Zhang">
</author>
<author initials="B" surname="Liu" fullname="Bin Liu">
</author>
<author initials="Q" surname="Dong" fullname="Qunfeng Dong">
</author>
<date year="INFOCOM, 2013"></date>
</front>
</reference>
<reference anchor="towardfast">
<front>
<title>Toward fast NDN software forwarding lookup engine based on Hash tables</title>
<author initials="W" surname="So" fullname="So, Won">
</author>
<author initials="A" surname="Narayanan" fullname="Ashok Narayanan">
</author>
<author initials="D" surname="Oran" fullname="Dave Oran">
</author>
<author initials="Y" surname="Wang" fullname="Yaogong Wang">
</author>
<date year="ACM, ANCS, 2012"></date>
</front>
</reference>
<reference anchor="namednetiot">
<front>
<title>Named data networking for IoT: An architectural perspective</title>
<author initials="M" surname="Amadeo" fullname="Amadeo, Marica">
</author>
<author initials="C" surname="Campolo" fullname="Claudia Campolo">
</author>
<author initials="A" surname="Iera" fullname="Antonio Iera">
</author>
<author initials="A" surname="Molinaro" fullname="Antonella Molinaro">
</author>
<date year="IEEE, EuCNC, 2014"></date>
</front>
</reference>
<reference anchor="icncompute">
<front>
<title>An information centric network for computing the distribution of computations</title>
<author initials="M" surname="Sifalakis" fullname="Sifalakis, Manolis">
</author>
<author initials="B" surname="Kohler" fullname="Basil Kohler">
</author>
<author initials="C" surname="Christopher" fullname="Christopher Christopher">
</author>
<author initials="C" surname="Tschudin" fullname="Christian Tschudin">
</author>
<date year="ACM, ICN Sigcomm, 2014"></date>
</front>
</reference>
<reference anchor="spark">
<front>
<title>SPARK: a new VANET-based smart parking scheme for large parking lots</title>
<author initials="R" surname="Lu" fullname="Lu R">
</author>
<author initials="X" surname="Lin" fullname="Lin X">
</author>
<author initials="H" surname="Zhu" fullname="Zhu H">
</author>
<author initials="X" surname="Shen" fullname="Shen X">
</author>
<date year="INFOCOM, 2009"></date>
</front>
</reference>
<reference anchor="smartparking">
<front>
<title>A reservation-based smart parking system</title>
<author initials="H" surname="Wang" fullname="Wang H">
</author>
<author initials="W" surname="He" fullname="He W">
</author>
<date year="The First International Workshop on Cyber-Physical Networking Systems, 2011"></date>
</front>
</reference>
<reference anchor="smartCamputIoT">
<front>
<title>Constructing Smart Campus Based on the Cloud Computing and the Internet of Things</title>
<author initials="L" surname="Qian" fullname="Qian L">
</author>
<date year="Computer Science 2011"></date>
</front>
</reference>
<reference anchor="BoyVoyage">
<front>
<title>From Bilbao to Oslo, intermodal mobility solutions, interfaces and applications for people and goods, supported by an innovative communication network</title>
<author initials="BonVoyage" surname="Project" fullname="Project BonVoyage">
</author>
<date year="Call H2020-MG-2014, 2015-2018"></date>
</front>
</reference>
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 12:10:43 |