2.4.  Infrastructure Sharing

   A key idea in ICN is that the network should secure information
   objects per se, not the communications channel that they are
   delivered over.  This means that hosts attached to an information-
   centric network can share resources on an unprecedented scale,
   especially when compared to what is possible in an IP network.  All
   devices with network access and storage capacity can contribute their
   resources thereby increasing the value of an information-centric

   network, although compensation schemes motivating users to contribute
   resources remain a research challenge primarily from a business
   perspective.

   For example, Jacobson et al. [CBIS] argue that in ICN the "where and
   how" of obtaining information are new degrees of freedom.  They
   illustrate this with a scenario involving a photo-sharing application
   that takes advantage of whichever access network connectivity is
   available at the moment (WLAN, Bluetooth, and even SMS) without
   requiring a centralized infrastructure to synchronize between
   numerous devices.  It is important to highlight that since the focus
   of communication changes, keep-alives in this scenario are simply
   unnecessary, as devices participating in the testbed network
   contribute resources in order to maintain user content consistency,
   not link state information as is the case in the host-centric
   paradigm.  This means that the notion of "infrastructure" may be
   completely different in the future.

   Muscariello et al. [SHARE], for instance, presented early work on an
   analytical framework that attempts to capture the storage/bandwidth
   tradeoffs that ICN enables and can be used as the foundation for a
   network planning tool.  In addition, Chai et al. [CL4M] explore the
   benefits of ubiquitous caching throughout an information-centric
   network and argue that "caching less can actually achieve more."
   These papers also sit alongside a variety of other studies that look
   at various scenarios such as caching HTTP-like traffic [CCNCT] and
   BitTorrent-like traffic [BTCACHE].  We observe that much more work is
   needed in order to understand how to make optimal use of all
   resources available in an information-centric network.  In real-world
   deployments, policy and commercial considerations are also likely to
   affect the use of particular resources, and more work is expected in
   this direction as well.

   In conclusion, scenarios in this category would cover the
   communication-computation-storage tradeoffs that an ICN deployment
   must consider.  This would exercise features relating to network
   planning, perhaps capitalizing on user-provided resources, as well as
   operational and economical aspects of ICN, and contrast them with
   other approaches.  An obvious baseline to compare against in this
   regard is existing federations of IP-based Content Distribution
   Networks (CDNs), such as the ones discussed in the IETF Content
   Delivery Networks Interconnection Working Group.

2.5.  Content Dissemination

   Content dissemination has attracted more attention than other aspects
   of ICN.  Scenarios in this category abound in the literature,
   including stored and streaming A/V distribution, file distribution,
   mirroring and bulk transfers, versioned content services (cf.
   Subversion-type revision control), as well as traffic aggregation.

   Decentralized content dissemination with on-the-fly aggregation of
   information sources was envisaged in [N-Scen], where information
   objects can be dynamically assembled based on hierarchically
   structured subcomponents.  For example, a video stream could be
   associated with different audio streams and subtitle sets, which can
   all be obtained from different sources.  Using the topology depicted
   in Figure 1 as an example, an application at C1 may end up obtaining,
   say, the video content from I1, but the user-selected subtitles from
   Px.  Semantics and content negotiation, on behalf of the user, were
   also considered, e.g., for the case of popular tunes that may be
   available in different encoding formats.  Effectively, this scenario
   has the information consumer issuing independent requests for content
   based on information identifiers, and stitching the pieces together
   irrespective of "where" or "how" they were obtained.

   A case in point for content dissemination are vehicular ad hoc
   networks (VANETs), as an ICN approach may address their needs for
   information dissemination between vehicles better than today's
   solutions, as discussed in the following section.  The critical part
   of information dissemination in a VANET scenario revolves around
   "where" and "when".  For instance, one may be interested in traffic
   conditions 2 km ahead while having no interest in similar information
   about the area around the path origin.  VANET scenarios may provide
   fertile ground for showcasing the ICN advantage with respect to
   content dissemination especially when compared with current host-
   centric approaches.  That said, information integrity and filtering
   are challenges that must be addressed.  As mentioned above, content
   dissemination scenarios in VANETs have a particular affinity to the
   mobility scenarios discussed in Section 2.3.

   Content dissemination scenarios, in general, have a large overlap
   with those described in the previous sections and are explored in
   several papers, such as [DONA], [PSI], [PSIMob], [NetInf], [CCN],
   [CBIS], and [CCR], just to name a few.  In addition, Chai et al.
   [CURLING] present a hop-by-hop hierarchical content resolution
   approach that employs receiver-driven multicast over multiple
   domains, advocating another content dissemination approach.  Yet,
   largely, work in this area did not address the issue of access
   authorization in detail.  Often, the distributed content is mostly
   assumed to be freely accessible by any consumer.  Distribution of

   paid-for or otherwise restricted content on a public ICN network
   requires more attention in the future.  Fotiou et al. [ACDICN]
   consider a scheme to this effect, but it still requires access to an
   authorization server to verify the user's status after the
   (encrypted) content has been obtained.  This may effectively negate
   the advantage of obtaining the content from any node, especially in a
   disruption-prone or mobile network.

   In summary, scenarios in this category aim to exercise primarily
   scalability and the cost and performance attributes of content
   dissemination.  Particularly, they should highlight the ability of an
   ICN to scale to billions of objects, while not exceeding the cost of
   existing content dissemination solutions (i.e., CDNs) and, ideally,
   increasing performance.  These should be shown in a holistic manner,
   improving content dissemination for both information consumers and
   publishers of all sizes.  We expect that in particular for content
   dissemination, in both extreme as well as typical scenarios, can be
   specified by drawing data from current CDN deployments.

2.6.  Vehicular Networking

   Users "on wheels" are interested in road safety, traffic efficiency,
   and infotainment applications that can be supported through vehicle-
   to-vehicle (V2V) and vehicle-to-infrastructure (V2I) wireless
   communications.  These applications exhibit unique features in terms
   of traffic generation patterns, delivery requirements, and spatial
   and temporal scope, which pose great challenges to traditional
   networking solutions.  VANETs, by their nature, are characterized by
   challenges such as fast-changing topology, intermittent connectivity,
   and high node mobility, but also by the opportunity to combine
   information from different sources as each vehicle does not care
   about "who" delivers the named data objects.

   ICN is an attractive candidate solution for vehicular networking, as
   it has several advantages.  First, ICN fits well to the nature of
   typical vehicular applications that are geography- and time-dependent
   (e.g., road traveler information, accident warning, point-of-interest
   advertisements) and usually target vehicles in a given area,
   regardless of their identity or IP address.  These applications are
   likely to benefit from in-network and decentralized data caching and
   replication mechanisms.  Second, content caching is particularly
   beneficial for intermittent on-the-road connectivity and can speed up
   data retrieval through content replication in several nodes.  Caching
   can usually be implemented at relatively low cost in vehicles, as the
   energy demands of the ICN device are likely to be a negligible
   fraction of the total vehicle energy consumption, thus allowing for
   sophisticated processing, continuous communication, and adequate
   storage in the vehicle.  Finally, ICN natively supports asynchronous

   data exchange between end-nodes.  By using (and redistributing)
   cached named information objects, a mobile node can serve as a link
   between disconnected areas.  In short, ICN can enable communication
   even under intermittent network connectivity, which is typical of
   vehicular environments with sparse roadside infrastructure and fast-
   moving nodes.

   The advantages of ICN in vehicular networks were preliminarily
   discussed in [EWC] and [DMND], and additionally investigated in
   [DNV2V], [RTIND], [CCNHV], [CCDIVN], [CCNVANET], and [CRoWN].  For
   example, Bai and Krishnamachari [EWC] take advantage of the localized
   and dynamic nature of a VANET to explore how a road congestion
   notification application can be implemented.  Wang et al. [DMND]
   consider data collection where Road-Side Units (RSUs) collect
   information from vehicles by broadcasting NDN-like Interest packets.
   The proposed architecture is evaluated using simulation in a grid
   topology and is compared against a host-centric alternative based on
   Mobile IP.  See Figure 3 for an indicative example of an urban VANET
   topology.  Their results indicate high efficiency for ICN even at
   high speeds.  That said, this work is a preliminary exploration of
   ICN in vehicular environments, so various issues remain for
   evaluation.  They include system scalability to large numbers of
   vehicles and the impact of vehicles that forward Interest packets or
   relay data to other vehicles.

      + - - _- - -_- - - -_- - _- - - +
      |    /_\   /_\     /_\  /_\     |
      |    o o   o o     o o  o o     |
      |    +-------+     +-------+ _  |
      |    |       |     |       |/_\ |
      |  _ |       |     |       |o o |
      | /_\|       |    |       |     |
      | o o+--_----+\===/+--_----+    |
      |      /_\    |RSU|  /_\        |
      |      o o    /===\  o o        |
      |    +-------+     +-------+ _  |
      |    |       |     |       |/_\ |
      | _  |       |     |       |o o |
      |/_\ |       |     |       |    |
      |o o +_-----_+     +_-----_+    |
      |    /_\   /_\     /_\   /_\    |
      +_ _ o_o_ _o_o_ _ _o_o_ _o_o_ _ +

   Figure 3.  Urban Grid VANET Topology

   As mentioned in the previous section, due to the short communication
   duration between a vehicle and the RSU, and the typically short time
   of sustained connectivity between vehicles, VANETs may be a good

   showcase for the ICN advantages with respect to content
   dissemination.  Wang et al. [DNV2V], for instance, analyze the
   advantages of hierarchical naming for vehicular traffic information
   dissemination.  Arnould et al. [CCNHV] apply ICN principles to safety
   information dissemination between vehicles with multiple radio
   interfaces.  In [CCDIVN], TalebiFard and Leung use network coding
   techniques to improve content dissemination over multiple ICN paths.
   Amadeo et al. [CCNVANET] [CRoWN] propose an application-independent
   ICN framework for content retrieval and distribution where the role
   of provider can be played equivalently by both vehicles and RSUs.
   ICN forwarding is extended through path-state information carried in
   Interest and Data packets, stored in a new data structure kept by
   vehicular nodes, and exploited also to cope with node mobility.

   Typical scenarios for testing content distribution in VANETs may be
   highways with vehicles moving in straight lines, with or without RSUs
   along the road, as shown in Figure 4.  With an NDN approach in mind,
   for example, RSUs may send Interest packets to collect data from
   vehicles [DMND], or vehicles may send Interest packets to collect
   data from other peers [RTIND] or from RSUs [CCNVANET].  Figure 2
   applies to content dissemination in VANET scenarios as well, where C0
   represents a vehicle that can obtain named information objects via
   multiple wireless peers and/or RSUs (I2 and I3 in the figure).  Grid
   topologies such as the one illustrated in Figure 3 should be
   considered in urban scenarios with RSUs at the crossroads or
   co-located with traffic lights as in [CRoWN].

        \___/                    \___/
        |RSU|                    |RSU|
      ================================
           _     _     _     _
          /_\   /_\   /_\   /_\
      _ _ o_o_ _o_o_ _o_o_ _o_o_ _ _ _
           _     _     _     _
          /_\   /_\   /_\   /_\
          o o   o o   o o   o o
      ================================

   Figure 4.  Highway VANET Topology

   To summarize, VANET scenarios aim to exercise ICN deployment from
   various perspectives, including scalability, caching, transport, and
   mobility issues.  There is a need for further investigation in (i)
   challenging scenarios (e.g., disconnected segments); (ii) scenarios
   involving both consumer and provider mobility; (iii) smart caching
   techniques that take into consideration node mobility patterns,
   spatial and temporal relevance, content popularity, and social
   relationships between users/vehicles; (iv) identification of new

   applications (beyond data dissemination and traffic monitoring) that
   could benefit from the adoption of an ICN paradigm in vehicular
   networks (e.g., mobile cloud, social networking).

2.7.  Delay- and Disruption-Tolerance

   Delay- and Disruption-Tolerant Networking (DTN) originated as a means
   to extend the Internet to interplanetary communications [DTN].
   However, it was subsequently found to be an appropriate architecture
   for many terrestrial situations as well.  Typically, this was where
   delays were greater than protocols such as TCP could handle, and
   where disruptions to communications were the norm rather than
   occasional annoyances, e.g., where an end-to-end path does not
   necessarily exist when communication is initiated.  DTN has now been
   applied to many situations, including opportunistic content sharing,
   handling infrastructural issues during emergency situations (e.g.,
   earthquakes) and providing connectivity to remote rural areas without
   existing Internet provision and little or no communications or power
   infrastructure.

   The DTN architecture [RFC4838] is based on a "store, carry, and
   forward" paradigm that has been applied extensively to situations
   where data is carried between network nodes by a "data mule", which
   carries bundles of data stored in some convenient storage medium
   (e.g., a USB memory stick).  With the advent of sensor and peer-to-
   peer (P2P) networks between mobile nodes, DTN is becoming a more
   commonplace type of networking than originally envisioned.  Since ICN
   also does not rely on the familiar end-to-end communications
   paradigm, there are clear synergies [DTNICN].  It could therefore be
   argued that many of the key principles embodied within DTN also exist
   in ICN, as we explain next.

   First, both approaches rely on in-network storage.  In the case of
   DTN, bundles are stored temporarily on devices on a hop-by-hop basis.
   In the case of ICN, information objects are also cached on devices in
   a similar fashion.  As such, both paradigms must provision storage
   within the network.

   Second, both approaches espouse late binding of names to locations
   due to the potentially large interval between request and response
   generation.  In the case of DTN, it is often impossible to predict
   the exact location (in a disconnected topology) where a node will be
   found.  Similarly, in the case of ICN, it is also often impossible to
   predict where an information object might be found.  As such, the
   binding of a request/bundle to a destination (or routing locator)
   must be performed as late as possible.

   Finally, both approaches treat data as a long-lived component that
   can exist in the network for extended periods of time.  In the case
   of DTN, bundles are carried by nodes until appropriate next hops are
   discovered.  In the case of ICN, information objects are typically
   cached until storage is exhausted.  As such, both paradigms require a
   direct shift in the way applications interact with the network.

   Through these similarities, it becomes possible to identify many DTN
   principles that are already in existence within ICN architectures.
   For example, ICN nodes will often retain information objects locally,
   making them accessible later on, much as DTN bundles are handled.
   Consequently, these synergies suggest strong potential for marrying
   the two technologies.  This could include, for instance, building new
   integrated Information-Centric Delay Tolerant Network (ICDTN)
   protocols or, alternatively, building ICN schemes over existing DTN
   protocols (and vice versa).

   The above similarities suggest that integration of the two principles
   would be feasible.  Beyond this, there are also a number of
   identifiable direct benefits.  Through caching and replication, ICN
   offers strong information resilience, whilst, through store-and-
   forward, DTN offers strong connectivity resilience.  As such, both
   architectures could benefit greatly from each other.  Initial steps
   have already been taken in the DTN community to integrate ICN
   principles, e.g., the Bundle Protocol Query Block [BPQ] has been
   proposed for the DTN Bundle Protocol [RFC5050].  Similarly, initial
   steps have also been taken in the ICN community, such as [SLINKY].
   In fact, the Scalable and Adaptive Internet Solutions (SAIL) project
   has developed a prototype implementation of NetInf running over the
   DTN Bundle Protocol.

   Of course, in many circumstances, information-centricity is not
   appropriate for use in delay- and disruption-tolerant environments.
   This is particularly the case when information is not the key
   communications atom transmitted.  Further, situations where a single
   sink is always used for receiving information may not warrant the
   identification and routing of independent information objects.
   However, there are a number of key scenarios where clear benefits
   could be gained by introducing information-centric principles into
   DTNs, two of which we describe later in this section.

   For the purpose of evaluating the use of ICNs in a DTN setting, two
   key scenarios are identified in this document.  (Note the rest of
   this section uses the term "ICDTN".)  These are both prominent use
   cases that are currently active in both the ICN and DTN communities.
   The first is opportunistic content sharing, whilst the second is the
   use of ad hoc networks during disaster recovery (e.g., earthquakes).
   We discuss both types of scenarios in the context of a simulation-

   based evaluation: due to the scale and mobility of DTN-like setups,
   this is the primary method of evaluation used.  Within the DTN
   community, the majority of simulations are performed using the
   Opportunistic Network Environment (ONE) simulator [ONE], which is
   referred to in this document.  Before exploring the two scenarios,
   the key shared components of their simulation are discussed.  This is
   separated into the two primary inputs that are required: the
   environment and the workload.

   In both types of scenarios the environment can be abstractly modeled
   by a time series of active connections between device pairs.  Unlike
   other scenarios in this document, an ICDTN scenario therefore does
   not depend on (relatively) static topologies but, rather, a set of
   time-varying disconnected topologies.  In opportunistic networks,
   these topologies are actually products of the mobility of users.  For
   example, if two users walk past each other, an opportunistic link can
   be created.  There are two methods used to generate these mobility
   patterns and, in turn, the time series of topologies.  The first is
   synthetic, whereby a (mathematical) model of user behavior is created
   in an agent-based fashion, e.g., random waypoint, Gauss-Markov.  The
   second is trace-driven, whereby the mobility of real users is
   recorded and used.  In both cases, the output is a sequence of time-
   stamped "contacts", i.e., periods of time in which two devices can
   communicate.  An important factor missing from typical mobility
   traces, however, is the capacity of these contacts: how much data can
   be transferred?  In both approaches to modeling mobility, links are
   usually configured as Bluetooth or Wi-Fi (ONE easily allows this,
   although lower-layer considerations are ignored, e.g., interference).
   This is motivated by the predominance of these technologies on mobile
   phones.

   The workload in an ICDTN is modeled much like the workload within the
   other scenarios.  It involves object creation/placement and object
   retrieval.  Object creation/placement can either be done statically
   at the beginning of the simulations or, alternatively, dynamically
   based on a model of user behavior.  In both cases, the latter is
   focused on, as it models far better the characteristics of the
   scenarios.

   Once the environment and workload have been configured, the next step
   is to decide the key metrics for the study.  Unlike traditional
   networking, the QoS expectation is typically far lower in an ICDTN,
   thereby moving away from metrics such as throughput.  At a high
   level, it is of clear interest to evaluate different ICN approaches
   with respect to both their delay- and disruption-tolerance (i.e., how
   effective is the approach when used in an environment subject to
   significant delay and/or disruption) and to their active support for
   operations in a DTN environment.

   The two most prominent metrics considered in a host-centric DTN are
   delivery probability and delivery delay.  The former relates to the
   probability by which a sent message will be received within a certain
   delay bound, whilst the latter captures the average length of time it
   takes for nodes to receive the message.  These metrics are similarly
   important in an ICDTN, although they are slightly different due to
   the request-response nature of ICN.  Therefore, the two most
   prominent evaluative metrics are satisfaction probability and
   satisfaction delay.  The former refers to the probability by which an
   information request (e.g., Interest) will be satisfied (i.e., how
   often a Data response will be received).  Satisfaction delay refers
   to the length of time it takes an information request to be
   satisfied.

   Note that the key difference between the host-centric and
   information-centric metrics is the need for a round-trip rather than
   a one-way communication.  Beyond this, depending on the focus of the
   work, other elements that may be investigated include name
   resolution, routing, and forwarding in disconnected parts of the
   network; support for unidirectional links; number of round trips
   needed to complete a data transfer; long-term content availability
   (or resilience); efficiency in the face of disruption; and so on.  It
   is also important to weigh these performance metrics against the
   necessary overheads.  In the case of an ICDTN, this is generally
   measured by the number of message replicas required to access
   content.  Note that routing in a DTN is often replication based,
   which leads to many copies of the same message.

2.7.1.  Opportunistic Content Sharing

   The first key baseline scenario in this context is opportunistic
   content sharing.  This occurs when mobile nodes create opportunistic
   links between each other to share content of interest.  For example,
   people riding on an underground train can pass news items between
   their mobile phones.  Equally, content generated on the phones (e.g.,
   tweets [TWIMIGHT]) could be stored for later forwarding (or even
   forwarded amongst interested passengers on the train).  Such
   scenarios, clearly, must be based around either the altruistic or
   incentivized interaction amongst users.  The latter is a particularly
   active area of research.  These networks are often termed "pocket-
   switched networks", as they are independently formed between the user
   devices.  Here, the evaluative scenario of ICDTN microblogging is
   proposed.  As previously discussed, the construction of such an
   evaluative scenario requires a formalization of its environment and
   workload.  Fortunately, there exist a number of datasets that offer
   exactly this information required for microblogging.

   In terms of the environment (i.e., mobility patterns), the Haggle
   project produced contact traces based on conference attendees using
   Bluetooth.  These traces are best targeted at application scenarios
   in which a small group of (50-100) people are in a relatively
   confined space.  In contrast, larger-scale traces are also available,
   most notably MIT's Reality Mining project.  These are better suited
   for cases where longer-term movement patterns are of interest.

   The second input, workload, relates to the creation and consumption
   of microblogs (e.g., tweets).  This can be effectively captured
   because subscriptions conveniently formalize who consumes what.  For
   bespoke purposes, specific data can be directly collected from
   Twitter for trace-driven simulations.  Several Twitter datasets are
   already available to the community containing a variety of data,
   ranging from Tweets to follower graphs.  See
   <http://www.tweetarchivist.com> and
   <http://socialcomputing.asu.edu/datasets/Twitter>.  These datasets
   can therefore be used to extract information production, placement,
   and consumption.

2.7.2.  Emergency Support and Disaster Recovery

   The second key baseline scenario in this context relates to the use
   of ICDTNs in emergency scenarios.  In these situations, it is typical
   for infrastructure to be damaged or destroyed, leading to the
   collapse of traditional forms of communications (e.g., cellular
   telephone networks).  This has been seen in the recent North Indian
   flooding, as well as the 2011 Tohoku earthquake and tsunami.  Power
   problems often exacerbate the issue, with communication failures
   lasting for days.  Therefore, in order to address this, DTNs have
   been used due to their high levels of resilience and independence
   from fixed infrastructure.  The most prominent use of DTNs in
   disaster areas would be the dissemination of information, e.g.,
   warnings and evacuation maps.  Unlike the previous scenario, it can
   be assumed that certain users (e.g., emergency responders) are highly
   altruistic.  However, it is likely many other users (e.g., endangered
   civilians) might become far more conservative in how they use their
   devices for battery-conserving purposes.  Here, we focus on the
   dissemination of standard broadcast information that should be
   received by all parties; generally, this is something led by
   emergency responders.

   For the environmental setup, there are no commonly used mobility
   traces for disaster zones, unlike in the previous scenario.  This is
   clearly due to the difficultly (near impossibility) of acquiring them
   in a real setting.  That said, various synthetic models are
   available.  The Post-Disaster Mobility Model [MODEL1] models
   civilians and emergency responders after a disaster has occurred,

   with people attempting to reach evacuation points (this has also been
   implemented in the ONE simulator).  Aschenbruck et al. [MODEL2] focus
   on emergency responders, featuring the removal of nodes from the
   disaster zone, as well as things like obstacles (e.g., collapsed
   buildings).  Cabrero et al. [MODEL3] also look at emergency
   responders but focus on patterns associated with common procedures.
   For example, command and control centers are typically set up with
   emergency responders periodically returning.  Clearly, the mobility
   of emergency responders is particularly important in this setting
   because they usually are the ones who will "carry" information into
   the disaster zone.  It is recommended that one of these emergency-
   specific models be used during any evaluations, due to the inaccuracy
   of alternate models used for "normal" behavior.

   The workload input in this evaluative scenario is far simpler than
   for the previous scenario.  In emergency cases, the dissemination of
   individual pieces of information to all parties is the norm.  This is
   often embodied using things like the Common Alert Protocol (CAP),
   which is an XML standard for describing warning message.  It is
   currently used by various systems, including the Integrated Public
   Alert & Warning System and Google Crisis Response.  As such, small
   objects (e.g., 512 KB to 2 MB) are usually generated containing text
   and images; note that the ONE simulator offers utilities to easily
   generate these.  These messages are also always generated by central
   authorities, therefore making the placement problem easier (they
   would be centrally generated and given to emergency responders to
   disseminate as they pass through the disaster zone).  The key
   variable is therefore the generation rate, which is synonymous with
   the rate that microblogs are written in the previous scenario.  This
   will largely be based on the type of disaster occurring; however,
   hourly updates would be an appropriate configuration.  Higher rates
   can also be tested, based on the rate at which situations change
   (landslides, for example, can exhibit highly dynamic properties).

   To summarize, this section has highlighted the applicability of ICN
   principles to existing DTN scenarios.  Two evaluative setups have
   been described in detail, namely, mobile opportunistic content
   sharing (microblogging) and emergency information dissemination.

2.8.  Internet of Things

   Advances in electronics miniaturization combined with low-power
   wireless access technologies (e.g., ZigBee, Near Field Communication
   (NFC), Bluetooth, and others) have enabled the coupling of
   interconnected digital services with everyday objects.  As devices
   with sensors and actuators connect into the network, they become
   "smart objects" and form the foundation for the so-called Internet of

   Things (IoT).  IoT is expected to increase significantly the amount
   of content carried by the network due to machine-to-machine (M2M)
   communication as well as novel user-interaction possibilities.

   Yet, the full potential of IoT does not lie in simple remote access
   to smart object data.  Instead, it is the intersection of Internet
   services with the physical world that will bring about the most
   dramatic changes.  Burke [IoTEx], for instance, makes a very good
   case for creating everyday experiences using interconnected things
   through participatory sensing applications.  In this case, inherent
   ICN capabilities for data discovery, caching, and trusted
   communication are leveraged to obtain sensor information and enable
   content exchange between mobile users, repositories, and
   applications.

   Kutscher and Farrell [IWMT] discuss the benefits that ICN can provide
   in these environments in terms of naming, caching, and optimized
   transport.  The Named Information URI scheme (ni) [RFC6920], for
   instance, could be used for globally unique smart object
   identification, although an actual implementation report is not
   currently available.  Access to information generated by smart
   objects can be of varied nature and often vital for the correct
   operation of large systems.  As such, supporting timestamping,
   security, scalability, and flexibility need to be taken into account.

   Ghodsi et al. [NCOA] examine hierarchical and self-certifying naming
   schemes and point out that ensuring reliable and secure content
   naming and retrieval may pose stringent requirements (e.g., the
   necessity for employing PKI), which can be too demanding for low-
   powered nodes, such as sensors.  That said, earlier work by Heidemann
   et al. [nWSN] shows that, for dense sensor network deployments,
   disassociating sensor naming from network topology and using named
   content at the lowest level of communication in combination with in-
   network processing of sensor data is feasible in practice and can be
   more efficient than employing a host-centric binding between node
   locator and the content existing therein.

   Burke et al. [NDNl] describe the implementation of a building
   automation system for lighting control where the security, naming,
   and device discovery NDN mechanisms are leveraged to provide
   configuration, installation, and management of residential and
   industrial lighting control systems.  The goal is an inherently
   resilient system, where even smartphones can be used for control.
   Naming reflects fixtures with evolved identification and node-
   reaching capabilities, thus simplifying bootstrapping, discovery, and
   user interaction with nodes.  The authors report that this ICN-based
   system requires less maintenance and troubleshooting than typical
   IP-based alternatives.

   Biswas et al. [CIBUS] visualize ICN as a contextualized information-
   centric bus (CIBUS) over which diverse sets of service producers and
   consumers coexist with different requirements.  ICN is leveraged to
   unify different platforms to serve consumer-producer interaction in
   both infrastructure and ad hoc settings.  Ravindran et al. [Homenet]
   show the application of this idea in the context of a home network,
   where consumers (residents) require policy-driven interactions with
   diverse services such as climate control, surveillance systems, and
   entertainment systems.  Name-based protocols are developed to enable
   zero-configuration node and service discovery, contextual service
   publishing and subscription, policy-based routing and forwarding with
   name-based firewall, and hoc device-to-device communication.

   IoT exposes ICN concepts to a stringent set of requirements that are
   exacerbated by the quantity of nodes, as well as by the type and
   volume of information that must be handled.  A way to address this is
   proposed in [IoTScope], which tackles the problem of mapping named
   information to an object, diverting from the currently typical
   centralized discovery of services and leveraging the intrinsic ICN
   scalability capabilities for naming.  It extends the base [PURSUIT]
   design with hierarchically based scopes, facilitating lookup, access,
   and modifications of only the part of the object information that the
   user is interested in.  Another important aspect is how to
   efficiently address resolution and location of the information
   objects, particularly when large numbers of nodes are connected, as
   in IoT deployments.  In [ICN-DHT], Katsaros et al. propose a
   Distributed Hash Table (DHT) that is compared with the Data-Oriented
   Network Architecture described in [DONA].  Their results show how
   topological routing information has a positive impact on resolution,
   at the expense of memory and processing overhead.

   The use of ICN mechanisms in IoT scenarios faces the most dynamic and
   heterogeneous type of challenges, when taking into consideration the
   requirements and objectives of such integration.  The disparity in
   technologies (not only in access technologies, but also in terms of
   end-node diversity such as sensors, actuators, and their
   characteristics) as well as in the information that is generated and
   consumed in such scenarios, will undoubtedly bring about many of the
   considerations presented in the previous sections.  For instance, IoT
   shares similarities with the constraints and requirements applicable
   to vehicular networking.  Here, a central problem is the deployment
   of mechanisms that can use opportunistic connectivity in unreliable
   networking environments (similar to the vehicular networking and DTN
   scenarios).

   However, one important concern in IoT scenarios, also motivated by
   this strongly heterogeneous environment, is how content dissemination
   will be affected by the different semantics of the disparate

   information and content being shared.  In fact, this is already a
   difficult problem that goes beyond the scope of ICN [SEMANT].  With
   the ability of the network nodes to cache forwarded information to
   improve future requests, a challenge arises regarding whether the ICN
   fabric should be involved in any kind of procedure (e.g., tagging)
   that facilitates the relationship or the interpretation of the
   different sources of information.

   Another issue lies with the need for having energy-efficiency
   mechanisms related to the networking capabilities of IoT
   infrastructures.  Often, the devices in IoT deployments have limited
   battery capabilities, and thus need low power consumption schemes
   working at multiple levels.  In principle, energy efficiency gains
   should be observed from the inherent in-network caching capability.
   However, this might not be the most usual case in IoT scenarios,
   where the information (particularly from sensors or controlling
   actuators) is more akin to real-time traffic, thus reducing the scale
   of potential savings due to ubiquitous in-network caching.

   ICN approaches, therefore, should be evaluated with respect to their
   capacity to handle the content produced and consumed by extremely
   large numbers of diverse devices.  IoT scenarios aim to exercise ICN
   deployment from different aspects, including ICN node design
   requirements, efficient naming, transport, and caching of time-
   restricted data.  Scalability is particularly important in this
   regard as the successful deployment of IoT principles could increase
   both device and content numbers dramatically beyond all current
   expectations.

2.9.  Smart City

   The rapid increase in urbanization sets the stage for the most
   compelling and challenging environments for networking.  By 2050 the
   global population will reach nine billion people, 75% of which will
   dwell in urban areas.  In order to cope with this influx, many cities
   around the world have started their transformation toward the "smart
   city" vision.  Smart cities will be based on the following innovation
   axes: smart mobility, smart environment, smart people, smart living,
   and smart governance.  In development terms, the core goal of a smart
   city is to become a business-competitive and attractive environment,
   while serving citizen well-being [CPG].

   In a smart city, ICT plays a leading role and acts as the glue
   bringing together all actors, services, resources (and their
   interrelationships) that the urban environment is willing to host and
   provide [MVM].  ICN appears particularly suitable for these
   scenarios.  Domains of interest include intelligent transportation
   systems, energy networks, health care, A/V communications, peer-to-

   peer and collaborative platforms for citizens, social inclusion,
   active participation in public life, e-government, safety and
   security, and sensor networks.  Clearly, this scenario has close ties
   to the vision of IoT, discussed in the previous section, as well as
   to vehicular networking.

   Nevertheless, the road to build a real information-centric digital
   ecosystem will be long, and more coordinated effort is required to
   drive innovation in this domain.  We argue that smart-city needs and
   ICN technologies can trigger a virtuous innovation cycle toward
   future ICT platforms.  Recent concrete ICN-based contributions have
   been formulated for home energy management [iHEMS], geo-localized
   services [ACC], smart-city services [IB], and traffic information
   dissemination in vehicular scenarios [RTIND].  Some of the proposed
   ICN-based solutions are implemented in real testbeds, while others
   are evaluated through simulation.

   Zhang et al. [iHEMS] propose a secure publish-subscribe architecture
   for handling the communication requirements of Home Energy Management
   Systems (HEMS).  The objective is to safely and effectively collect
   measurement and status information from household elements, aggregate
   and analyze the data, and ultimately enable intelligent control
   decisions for actuation.  They consider a simple experimental testbed
   for their proof-of-concept evaluation, exploiting open source code
   for the ICN implementation, and emulating some node functionality in
   order to facilitate system operation.

   A different scenario is considered in [ACC], where DHTs are employed
   for distributed, scalable, and geographically aware service lookup in
   a smart city.  Also in this case, the ICN application is validated by
   considering a small-scale testbed: a small number of nodes are
   emulated with simple embedded PCs or specific hardware boards (e.g.,
   for some sensor nodes); other nodes (which connect the principal
   actors of the tests) are emulated with workstations.  The proposal in
   [IB] draws from a smart-city scenario (mainly oriented towards waste
   collection management) comprising sensors and moving vehicles, as
   well as a cloud-computing system that supports data retrieval and
   storage operations.  The main aspects of this proposal are analyzed
   via simulation using open source code that is publicly available.
   Some software applications are designed on real systems (e.g., PCs
   and smartphones).

   With respect to evaluating ICN approaches in smart-city scenarios, it
   is necessary to consider generic metrics useful to track and monitor
   progress on services results and also for comparing localities
   between themselves and learn from the best [ISODIS].  In particular,
   it is possible to select a specific set of Key Performance Indicators
   (KPIs) for a given project in order to evaluate its success.  These

   KPIs may reflect the city's environmental and social goals, as well
   as its economic objectives, and they can be calculated at the global,
   regional, national, and local levels.  Therefore, it is not possible
   to define a unique set of interesting metrics, but in the context of
   smart cities, the KPIs should be characterized with respect to the
   developed set of services offered by using the ICN paradigm.

   To sum up, smart-city scenarios aim to exercise several ICN aspects
   in an urban environment.  In particular, they can be useful to (i)
   analyze the capacity of using ICN for managing extremely large data
   sets; (ii) study ICN performance in terms of scalability in
   distributed services; (iii) verify the feasibility of ICN in a very
   complex application like vehicular communication systems; and (iv)
   examine the possible drawbacks related to privacy and security issues
   in complex networked environments.