idnits 2.17.1 draft-zhang-icnrg-icniot-requirements-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. (A line matching the expected section header was found, but with an unexpected indentation: ' overview", IETF, RFC3650, 2003.' ) ** The document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (April 22, 2016) is 2925 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Missing reference section? '1' on line 1446 looks like a reference -- Missing reference section? '2' on line 1449 looks like a reference -- Missing reference section? '11' on line 1486 looks like a reference -- Missing reference section? '23' on line 1536 looks like a reference -- Missing reference section? '24' on line 1541 looks like a reference -- Missing reference section? '18' on line 1514 looks like a reference -- Missing reference section? '19' on line 1518 looks like a reference -- Missing reference section? '20' on line 1522 looks like a reference -- Missing reference section? '8' on line 1473 looks like a reference -- Missing reference section? '3' on line 1454 looks like a reference -- Missing reference section? '4' on line 1457 looks like a reference -- Missing reference section? '5' on line 1460 looks like a reference -- Missing reference section? '49' on line 1642 looks like a reference -- Missing reference section? '50' on line 1647 looks like a reference -- Missing reference section? 'IoTGW' on line 506 looks like a reference -- Missing reference section? '59' on line 1682 looks like a reference -- Missing reference section? '71' on line 1739 looks like a reference -- Missing reference section? '38' on line 1599 looks like a reference -- Missing reference section? '70' on line 1732 looks like a reference -- Missing reference section? '44' on line 1622 looks like a reference -- Missing reference section? '28' on line 1558 looks like a reference -- Missing reference section? '29' on line 1562 looks like a reference -- Missing reference section? '37' on line 1595 looks like a reference -- Missing reference section? '40' on line 1607 looks like a reference -- Missing reference section? '41' on line 1611 looks like a reference -- Missing reference section? '57' on line 1674 looks like a reference -- Missing reference section? '31' on line 1570 looks like a reference -- Missing reference section? '33' on line 1578 looks like a reference -- Missing reference section? '53' on line 1659 looks like a reference -- Missing reference section? '7' on line 1468 looks like a reference -- Missing reference section? '58' on line 1678 looks like a reference -- Missing reference section? '60' on line 1688 looks like a reference -- Missing reference section? '61' on line 1693 looks like a reference -- Missing reference section? '62' on line 1698 looks like a reference -- Missing reference section? '63' on line 1702 looks like a reference -- Missing reference section? '34' on line 1581 looks like a reference -- Missing reference section? '55' on line 1666 looks like a reference -- Missing reference section? '36' on line 1590 looks like a reference -- Missing reference section? '56' on line 1669 looks like a reference -- Missing reference section? '42' on line 1614 looks like a reference -- Missing reference section? '43' on line 1618 looks like a reference -- Missing reference section? '64' on line 1706 looks like a reference -- Missing reference section? '35' on line 1585 looks like a reference -- Missing reference section? '32' on line 1574 looks like a reference -- Missing reference section? '46' on line 1631 looks like a reference -- Missing reference section? '52' on line 1655 looks like a reference -- Missing reference section? '48' on line 1639 looks like a reference -- Missing reference section? '69' on line 1727 looks like a reference -- Missing reference section? '10' on line 1481 looks like a reference -- Missing reference section? '12' on line 1490 looks like a reference -- Missing reference section? '13' on line 1494 looks like a reference -- Missing reference section? '14' on line 1498 looks like a reference -- Missing reference section? '15' on line 1502 looks like a reference -- Missing reference section? '65' on line 1710 looks like a reference -- Missing reference section? '66' on line 1714 looks like a reference -- Missing reference section? '67' on line 1718 looks like a reference -- Missing reference section? '17' on line 1510 looks like a reference -- Missing reference section? '21' on line 1527 looks like a reference -- Missing reference section? '22' on line 1532 looks like a reference -- Missing reference section? '25' on line 1547 looks like a reference -- Missing reference section? '68' on line 1722 looks like a reference -- Missing reference section? '26' on line 1551 looks like a reference -- Missing reference section? '27' on line 1554 looks like a reference -- Missing reference section? '6' on line 1463 looks like a reference -- Missing reference section? '9' on line 1476 looks like a reference -- Missing reference section? '16' on line 1505 looks like a reference -- Missing reference section? '30' on line 1566 looks like a reference -- Missing reference section? '39' on line 1604 looks like a reference -- Missing reference section? '45' on line 1626 looks like a reference -- Missing reference section? '47' on line 1634 looks like a reference -- Missing reference section? '51' on line 1652 looks like a reference -- Missing reference section? '54' on line 1663 looks like a reference Summary: 3 errors (**), 0 flaws (~~), 1 warning (==), 73 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 ICN Research Group Y. Zhang 3 Internet-Draft D. Raychadhuri 4 Intended status: Informational WINLAB, Rutgers University 5 Expires: October 24, 2016 L. Grieco 6 Politecnico di Bari (DEI) 7 E. Baccelli 8 INRIA 9 J. Burke 10 UCLA REMAP 11 R. Ravindran 12 G. Wang 13 Huawei Technologies 14 A. Lindren 15 B. Ahlgren 16 SICS Swedish ICT 17 O. Schelen 18 Lulea University of Technology 19 April 22, 2016 21 Requirements and Challenges for IoT over ICN 22 draft-zhang-icnrg-icniot-requirements-01 24 Abstract 26 The Internet of Things (IoT) promises to connect billions of objects 27 to the Internet. After deploying many stand-alone IoT systems in 28 different domains, the current trend is to develop a common, "thin 29 waist" of protocols forming a horizontal unified, defragmented IoT 30 platform. Such a platform will make objects accessible to 31 applications across organizations and domains. Towards this goal, 32 quite a few proposals have been made to build a unified host-centric 33 IoT platform as an overlay on top of today's host-centric Internet. 34 However, there is a fundamental mismatch between the host-centric 35 nature of todays Internet and the information-centric nature of the 36 IoT system. To address this mismatch, we propose to build a common 37 set of protocols and services, which form an IoT platform, based on 38 the Information Centric Network (ICN) architecture, which we call 39 ICN-IoT. ICN-IoT leverages the salient features of ICN, and thus 40 provides seamless mobility support, security, scalability, and 41 efficient content and service delivery. 43 This draft describes representative IoT requirements and ICN 44 challenges to realize a unified ICN-IoT framework. Towards this, we 45 first identify a list of important requirements which a unified IoT 46 architecture should have to support tens of billions of objects, then 47 we discuss how the current IP-IoT overlay fails to meet these 48 requirements, followed by discussion on suitability of ICN for IoT. 50 Though we see most of the IoT requirements can be met by ICN, we 51 discuss specific challenges ICN has to address to satisfy them. Then 52 we provide discussion of popular IoT scenarios including the "smart" 53 home, campus, grid, transportation infrastructure, healthcare, 54 Education, and Entertainment for completeness, as specific scenarios 55 requires appropriate design choices and architectural considerations 56 towards developing an ICN-IoT solution. 58 Status of This Memo 60 This Internet-Draft is submitted in full conformance with the 61 provisions of BCP 78 and BCP 79. 63 Internet-Drafts are working documents of the Internet Engineering 64 Task Force (IETF). Note that other groups may also distribute 65 working documents as Internet-Drafts. The list of current Internet- 66 Drafts is at http://datatracker.ietf.org/drafts/current/. 68 Internet-Drafts are draft documents valid for a maximum of six months 69 and may be updated, replaced, or obsoleted by other documents at any 70 time. It is inappropriate to use Internet-Drafts as reference 71 material or to cite them other than as "work in progress." 73 This Internet-Draft will expire on October 24, 2016. 75 Copyright Notice 77 Copyright (c) 2016 IETF Trust and the persons identified as the 78 document authors. All rights reserved. 80 This document is subject to BCP 78 and the IETF Trust's Legal 81 Provisions Relating to IETF Documents 82 (http://trustee.ietf.org/license-info) in effect on the date of 83 publication of this document. Please review these documents 84 carefully, as they describe your rights and restrictions with respect 85 to this document. Code Components extracted from this document must 86 include Simplified BSD License text as described in Section 4.e of 87 the Trust Legal Provisions and are provided without warranty as 88 described in the Simplified BSD License. 90 Table of Contents 92 1. IoT Motivation . . . . . . . . . . . . . . . . . . . . . . . 3 93 2. IoT Architectural Requirements . . . . . . . . . . . . . . . 4 94 2.1. Naming . . . . . . . . . . . . . . . . . . . . . . . . . 4 95 2.2. Scalability . . . . . . . . . . . . . . . . . . . . . . . 4 96 2.3. Resource Constraints . . . . . . . . . . . . . . . . . . 5 97 2.4. Traffic Characteristics . . . . . . . . . . . . . . . . . 5 98 2.5. Contextual Communication . . . . . . . . . . . . . . . . 6 99 2.6. Handling Mobility . . . . . . . . . . . . . . . . . . . . 6 100 2.7. Storage and Caching . . . . . . . . . . . . . . . . . . . 7 101 2.8. Security and Privacy . . . . . . . . . . . . . . . . . . 7 102 2.9. Communication Reliability . . . . . . . . . . . . . . . . 8 103 2.10. Self-Organization . . . . . . . . . . . . . . . . . . . . 8 104 2.11. Ad hoc and Infrastructure Mode . . . . . . . . . . . . . 8 105 2.12. Open API . . . . . . . . . . . . . . . . . . . . . . . . 9 106 2.13. IoT Platform Management . . . . . . . . . . . . . . . . . 9 107 3. State of the Art . . . . . . . . . . . . . . . . . . . . . . 9 108 3.1. Silo IoT Architecture . . . . . . . . . . . . . . . . . . 10 109 3.2. Overlay Based Unified IoT Solutions . . . . . . . . . . . 10 110 3.2.1. Weaknesses of the Overlay-based Approach . . . . . . 11 111 4. Advantages of using ICN for IoT . . . . . . . . . . . . . . . 13 112 5. ICN Challenges for IoT . . . . . . . . . . . . . . . . . . . 14 113 5.1. Naming Devices, Data, and Services . . . . . . . . . . . 14 114 5.2. Name Resolution . . . . . . . . . . . . . . . . . . . . . 16 115 5.3. Caching/Storage . . . . . . . . . . . . . . . . . . . . . 17 116 5.4. Routing and Forwarding . . . . . . . . . . . . . . . . . 18 117 5.5. Contextual Communication . . . . . . . . . . . . . . . . 19 118 5.6. In-network Computing . . . . . . . . . . . . . . . . . . 20 119 5.7. Security and Privacy . . . . . . . . . . . . . . . . . . 21 120 5.8. Self-Orgnization . . . . . . . . . . . . . . . . . . . . 22 121 5.9. Communications Reliability . . . . . . . . . . . . . . . 23 122 5.10. Energy Efficiency . . . . . . . . . . . . . . . . . . . . 23 123 6. Appendix . . . . . . . . . . . . . . . . . . . . . . . . . . 23 124 6.1. Homes . . . . . . . . . . . . . . . . . . . . . . . . . . 23 125 6.2. Enterprise . . . . . . . . . . . . . . . . . . . . . . . 25 126 6.3. Smart Grid . . . . . . . . . . . . . . . . . . . . . . . 26 127 6.4. Transportation . . . . . . . . . . . . . . . . . . . . . 27 128 6.5. Healthcare . . . . . . . . . . . . . . . . . . . . . . . 28 129 6.6. Education . . . . . . . . . . . . . . . . . . . . . . . . 29 130 6.7. Entertainment, arts, and culture . . . . . . . . . . . . 30 131 7. Informative References . . . . . . . . . . . . . . . . . . . 31 132 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 37 134 1. IoT Motivation 136 During the past decade, many standalone Internet of Things (IoT) 137 systems have been developed and deployed in different domains. The 138 recent trend, however, is to evolve towards a globally unified IoT 139 platform, in which billions of objects connect to the Internet, 140 available for interactions among themselves, as well as interactions 141 with many different applications across boundaries of administration 142 and domains. Building a unified IoT platform, however, poses great 143 challenges on the underlying network and systems. To name a few, it 144 needs to support 50-100 Billion networked objects [1], many of which 145 are mobile. The objects will have extremely heterogeneous means of 146 connecting to the Internet, often with severe resource constraints. 147 Interactions between the applications and objects are often real-time 148 and dynamic, requiring strong security and privacy protections. In 149 addition, IoT applications are inherently information centric (e.g., 150 data consumers usually need data sensed from the environment without 151 any reference to the sub-set of motes that will provide the asked 152 information). Taking a general IoT perspective, we first discuss the 153 IoT requirements generally applicable to many well known scenarios. 154 We then discuss how the current IP overlay models fail to meet these 155 requirements. We follow this by key ICN features that makes it a 156 better candidate to realize an unified IoT framework. We then 157 discuss IoT challenges from an ICN perspective and requirements posed 158 towards its design. Final discussion focuses on IoT scenarios and 159 their unique challenges. 161 2. IoT Architectural Requirements 163 A unified IoT platform has to support interactions among a large 164 number of mobile devices across the boundaries of organizations and 165 domains. As a result, it naturally poses stringent requirements in 166 every aspect of the system design. Below, we outline a few important 167 requirements that a unified IoT platform has to address. 169 2.1. Naming 171 The first step towards realizing a unified IoT platform is the 172 ability to assign names that are unique within the scope and lifetime 173 of each device, data items generated by these devices, or a group of 174 devices towards a common objective. Naming has the following 175 requirements: first, names need to be persistent (within one or more 176 contexts) against dynamic features that are common in IoT systems, 177 such as lifetime, mobility or migration; second, names need to be 178 secure based on application requirements; third, names should provide 179 advantages to application authors in comparison with traditional host 180 address based schemes. 182 2.2. Scalability 184 Cisco predicts there will be around 50 Billion IoT devices such as 185 sensors, RFID tags, and actuators, on the Internet by 2020 [1]. As 186 mentioned above, a unified IoT platform needs to name every entity 187 such as data, device, service etc. Scalability has to be addressed 188 at multiple levels of the IoT architecture including naming, 189 security, name resolution, routing and forwarding level. In 190 addition, mobility adds further challenge in terms of scalability. 191 Particularly with respect to name resolution the system should be 192 able to register/update/resolve a name within a short latency. 194 2.3. Resource Constraints 196 IoT devices can be broadly classified into two groups: resource- 197 sufficient and resource-constrained. In general, there are the 198 following types of resources: power, computing, storage, bandwidth, 199 and user interface. 201 Power constraints of IoT devices limit how much data these devices 202 can communicate, as it has been shown that communications consume 203 more power than other activities for embedded devices. Flexible 204 techniques to collect the relevant information are required, and 205 uploading every single produced data to a central server is 206 undesirable. Computing constraints limit the type and amount of 207 processing these devices can perform. As a result, more complex 208 processing needs to be conducted in cloud servers or at opportunistic 209 points, example at the network edge, hence it is important to balance 210 local computation versus communication cost. 212 Storage constraints of the IoT devices limit the amount of data that 213 can be stored on the devices. This constraint means that unused 214 sensor data may need to be discarded or stored in aggregated compact 215 form time to time. Bandwidth constraints of the IoT devices limit 216 the amount of communication. Such devices will have the same 217 implication on the system architecture as with the power constraints; 218 namely, we cannot afford to collect single sensor data generated by 219 the device and/or use complex signaling protocols. 221 User interface constraints refer to whether the device is itself 222 capable of directly interacting with a user should the need arise 223 (e.g., via a display and keypad or LED indicators) or requires the 224 network connectivity, either global or local, to interact with 225 humans. 227 The above discussed device constraints also affect application 228 performance with respect to latency and jitter. This in particular 229 applies to satellite or other space based devices. 231 2.4. Traffic Characteristics 233 IoT traffic can be broadly classified into local area traffic and 234 wide area traffic. Local area traffic is between nearby devices. 235 For example, neighboring cars may work together to detect potential 236 hazards on the highway, sensors deployed in the same room may 237 collaborate to determine how to adjust the heating level in the room. 238 These local area communications often involve data aggregation and 239 filtering, have real time constraints, and require fast device/data/ 240 service discovery and association. At the same time, the IoT 241 platform has to also support wide area communications. For example, 242 in Intelligent Transportation Systems, re-routing operations may 243 require a broad knowledge of the status of the system, traffic load, 244 availability of freights, whether forecasts and so on. Wide area 245 communications require efficient data/service discovery and 246 resolution services. 248 While traffic characteristics for different IoT systems are expected 249 to be different, certain IoT systems have been analyzed and shown to 250 have comparable uplink and downlink traffic volume in some 251 applications such as [2], which means that we have to optimize the 252 bandwidth/energy consumption in both directions. Further, IoT 253 traffic demonstrates certain periodicity and burstiness [2]. As a 254 result, when provisioning the system, the shape of the traffic volume 255 has to be properly accounted for. 257 2.5. Contextual Communication 259 Many IoT applications shall rely on dynamic contexts in the IoT 260 system to initiate communication between IoT devices. Here, we refer 261 to a context as attributes applicable to a group of devices that 262 share some common features, such as their owners may have a certain 263 social relationship or belong to the same administrative group, or 264 the devices may be present in the same location. For example, cars 265 traveling on the highway may form a "cluster" based upon their 266 temporal physical proximity as well as the detection of the same 267 event. These temporary groups are referred to as contexts. IoT 268 applications need to support interactions among the members of a 269 context, as well as interactions across contexts. 271 Temporal context can be broadly categorized into two classes, long- 272 term contexts such as those that are based upon social contacts as 273 well as stationary physical locations (e.g., sensors in a car/ 274 building), and short-term contexts such as those that are based upon 275 temporary proximity (e.g., all taxicabs within half a mile of the 276 Time Square at noon on Oct 1, 2013). Between these two classes, 277 short-term contexts are more challenging to support, requiring fast 278 formation, update, lookup and association. 280 2.6. Handling Mobility 282 There are several degrees of mobility in a unified IoT platform, 283 ranging from static as in fixed assets to highly dynamic in vehicle- 284 to-vehicle environments. 286 Mobility in the IoT platform can mean 1) the data producer mobility 287 (i.e., location change), 2) the data consumer mobility, 3) IoT 288 Network mobility (e.g., a body-area network in motion as a person is 289 walking); and 4) disconnection between the data source and 290 destination pair (e.g., due to unreliable wireless links). The 291 requirement on mobility support is to be able to deliver IoT data 292 below an application's acceptable delay constraint in all of the 293 above cases, and and if necessary to negotiate different connectivity 294 or security constraints specific to each mobile context. 296 2.7. Storage and Caching 298 Storage and caching plays a very significant role depending on the 299 type of IoT ecosystem, also a function subjected to privacy and 300 security guidelines. In a unified IoT platform, depending on 301 application requirements, content caching may or may not be policy 302 driven. If caching is pervasive, intermediate nodes don't need to 303 always forward a content request to its original creator; rather, 304 locating and receiving a cached copy is sufficient for IoT 305 applications. This optimization can greatly reduce the content 306 access latencies. 308 Furthermore considering hierarchical nature of IoT systems, ICN 309 architectures enable a more flexible, heterogeneous and potentially 310 fault-tolerant approach to storage providing persistence at multiple 311 levels. 313 In network storage and caching, however, has the following 314 requirements on the IoT platform. The platform needs to support the 315 efficient resolution of cached copies. Further the platform should 316 strive for the balance between caching, content security/privacy, and 317 regulations. 319 2.8. Security and Privacy 321 In addition to the fundamental challenge of trust management, a 322 variety of security and privacy concerns also exist in ICNs. 324 The unified IoT platform makes physical objects accessible to 325 applications across organizations and domains. Further, it often 326 integrates with critical infrastructure and industrial systems with 327 life safety implications, bringing with it significant security 328 challenges and regulatory requirements [11]. 330 Security and privacy thus become a serious concern, as does the 331 flexibility and usability of the design approaches. Beyond the 332 overarching trust management challenge, security includes data 333 integrity, authentication, and access control at different layers of 334 the IoT platform. Privacy means that both the content and the 335 context around IoT data need to be protected. These requirements 336 will be driven by various stake holders such as industry, government, 337 consumers etc. 339 2.9. Communication Reliability 341 IoT applications can be broadly categorized into mission critical and 342 non-mission critical. For mission critical applications, reliable 343 communication is one of the most important features as these 344 applications have strong QoS requirements. Reliable communication 345 requires the following capabilities for the underlying system: (1) 346 seamless mobility support in the face of extreme disruptions (DTN), 347 (2) efficient routing in the presence of intermittent disconnection, 348 (3) QoS aware routing, (4) support for redundancy at all levels of a 349 system (device, service, network, storage etc.), and (5) support for 350 rich communication patterns (unlike the tree-like routing structure 351 supported by RPL developed by ROLL WG). 353 2.10. Self-Organization 355 The unified IoT platform should be able to self-organize to meet 356 various application requirements, especially the capability to 357 quickly discover heterogeneous and relevant (local or global) 358 devices/data/services based on the context. This discovery can be 359 achieved through an efficient platform-wide publish-subscribe 360 service, or through private community grouping/clustering based upon 361 trust and other security requirements. In the former case, the 362 publish-subscribe service must be efficiently implemented, able to 363 support seamless mobility, in- network caching, name-based routing, 364 etc. In the latter case, the IoT platform needs to discover the 365 private community groups/clusters efficiently. 367 Another aspect of self-organization is decoupling the sensing 368 Infrastructure from applications. In a unified IoT platform, various 369 applications run on top of a vast number of IoT devices. Upgrading 370 the firmware of the IoT devices is a difficult work. It is also not 371 practical to reprogram the IoT devices to accommodate every change of 372 the applications. The infrastructure and the application specific 373 logics need to be decoupled. A common interface is required to 374 dynamically configure the interactions between the IoT devices and 375 easily modify the application logics on top of the sensing 376 infrastructure [23] [24]. 378 2.11. Ad hoc and Infrastructure Mode 380 Depending upon whether there is communication infrastructure, an IoT 381 system can operate either in ad-hoc or infrastructure mode. 383 For example, a vehicle may determine to report its location and 384 status information to a server periodically through cellular 385 connection, or, a group of vehicles may form an ad-hoc network that 386 collectively detect road conditions around them. In the cases where 387 infrastructure is unavailable, one of the participating nodes may 388 choose to become the temporary gateway. 390 The unified IoT platform needs to design a common protocol that 391 serves both modes. Such a protocol should be able to provide: (1) 392 energy-efficient topology discovery and data forwarding in the ad-hoc 393 mode, and (2) scalable name resolution in the infrastructure mode. 395 2.12. Open API 397 General IoT applications involve sensing, processing, and secure 398 content distribution occurring at various timescales and at multiple 399 levels of hierarchy depending on the application requirements. This 400 requires open APIs to be generic enough to support commonly used 401 interactions between consumers, content producer, and IoT services, 402 as opposed to proprietary APIs that are common in today's systems. 403 Examples include pull, push, and publish/subscribe mechanisms using 404 common naming, payload, encryption and signature schemes. 406 2.13. IoT Platform Management 408 An IoT platforms' service, control, and data plane will be governed 409 by its own management infrastructure which includes distributed and 410 centralized middleware, discovery, naming, self-configuring, analytic 411 functions, and information dissemination to achieve specific IoT 412 system objectives [18][19][20]. Towards this new IoT management 413 mechanisms and service metrics need to be developed to measure the 414 success of an IoTdeployment. Considering an IoT systems' defining 415 characteristics such as, its potential large number of IoT devices, 416 ephemeral nature to save power, mobility, and ad hoc communication, 417 autonomic self-management mechanisms become very critical. Further 418 considering its hierarchical information processing deployment model, 419 the platform needs to orchestrate computational tasks according to 420 the involved sensors and the available computation resources which 421 may change over time. An efficient computation resource discovery 422 and management protocol is required to facilitate this process. The 423 trade-off between information transmission and processing is another 424 challenge. 426 3. State of the Art 428 Over the years, many stand-alone IoT systems have been deployed in 429 various domains. These systems usually adopt a vertical silo 430 architecture and support a small set of pre-designated applications. 431 A recent trend, however, is to move away from this approach, towards 432 a unified IoT platform in which the existing silo IoT systems, as 433 well as new systems that are rapidly deployed. This will make their 434 data and services accessible to general Internet applications (as in 435 ETSI- M2M and oneM2M standards). In such a unified platform, 436 resources can be accessed over Internet and shared across the 437 physical boundaries of the enterprise. However, current approaches 438 to achieve this objective are based upon Internet overlays, whose 439 inherent inefficiencies due to IP protocol [8] hinders the platform 440 from satisfying the IoT requirements outlined earlier (particularly 441 in terms of scalability, security, mobility, and self-organization) 443 3.1. Silo IoT Architecture 445 [IoT Server] 446 | 447 | 448 ______|_______ 449 _______ { } 450 { } { } 451 {IoT Dev}\ { Internet }---[IoT Application] 452 {_______} [IoTGW]---{ } 453 { } 454 {______________} 456 Figure 1:Silo architecture of standalone IoT systems 458 A typical standalone IoT system is illustrated in Figure 1, which 459 includes devices, a gateway, a server and applications. Many IoT 460 devices have limited power and computing resources, unable to 461 directly run normal IP access network (Ethernet, WIFI, 3G/LTE etc.) 462 protocols. Therefore they use the IoT gateway to the server. 463 Through the IoT server, applications can subscribe to data collected 464 by devices, or interact with devices. 466 There have been quite a few popular protocols for standalone IoT 467 systems, such as DF-1, MelsecNet, Honeywell SDS, BACnet, etc. 468 However, these protocols are operating at the device-level 469 abstraction, instead of information driven, leading to a highly 470 fragmented protocol space with limited interoperability. 472 3.2. Overlay Based Unified IoT Solutions 474 The current approach to a unified IoT platform is to make IoT 475 gateways and servers adopt standard APIs. IoT devices connect to the 476 Internet through the standard APIs and IoT applications subscribe and 477 receive data through standard control and data APIs. Building on top 478 of today's Internet as an overlay, this is the most practical 479 approach towards a unified IoT platform. There are ongoing 480 standardization efforts including ETSI[3], oneM2M[4]. Network 481 operators can use frameworks to build common IOT gateways and servers 482 for their customers. In addition, IETF's CORE working group [5] is 483 developing a set of protocols like CoAP (Constrained Application 484 Protocol) [49], that is a lightweight protocol modeled after HTTP 485 [50] and adapted specifically for the Internet of Things (IoT). CoAP 486 adopts the Representational State Transfer (REST) architecture with 487 Client-Server interactions. It uses UDP as the underlying transport 488 protocol with reliability and multicast support. Both CoAP and HTTP 489 are considered as the suitable application level protocols for 490 Machine-to-Machine communications, as well as IoT. For example, 491 oneM2M (which is one of leading standards for unified M2M platform) 492 has both the protocol bindings to HTTP and CoAP for its primitives. 493 Figure 2 shows the architecture adopted in this approach. 495 Publishing----[IoT Server]----Subscribing-- 496 | / | \ | 497 | / | \ | 498 | /______|_______ \ | 499 ___________ | /{ } publishing | 500 { } | | { } | | 501 {Smart Homes}\ | | { Internet }---------[IoT Application] 502 {___________} [IoTGW]---{ }\ | ________________ 503 | { } \ | { } 504 | {______________} [IoTGW]-{Smart Healthcare} 505 | | {________________} 506 Publishing [IoTGW] 507 | ____|_____ 508 | { } 509 ---{Smart Grid} 510 {__________} 512 Figure 2: Implementing an open IoT platform through standarized APIs 513 on the IoT gateways and the server 515 3.2.1. Weaknesses of the Overlay-based Approach 517 The above overlay-based approach can work with many different 518 protocols, but the system is built upon today's IP network, which has 519 inherent weaknesses towards supporting a unified IoT system. As a 520 result, it cannot satisfy some of the requirements we outlined in 521 Section 2: 523 o Naming. In current overlays for IoT systems the naming scheme is 524 host centric, i.e., the name of a given resource/service is linked 525 to the one of device that can provide it. In turn, device names 526 are coupled to IP addresses, which are not persistent in mobile 527 scenarios. On the other side, in IoT systems the same service/ 528 resource could be provided by many different devices thus 529 requiring a different design rationale. 531 o Trust. Trust management schemes are still relatively weak, 532 focusing on securing communication channels rather than managing 533 the data that needs to be secured directly. 535 o Mobility. The overlay-based approach uses IP addresses as names 536 at the network layer, which hinders the support for device/service 537 mobility or flexible name resolution. Further the Layer 2/3 538 management, and application-layer addressing and forwarding 539 required to deploy current IoT solutions limit the scalability and 540 management of these systems. 542 o Resource constraints. The overlay-based approach requires every 543 device to send data to an aggregator or to the IoT server. 544 Resource constraints of the IoT devices, especially in power and 545 bandwidth, could seriously limit the performance of this approach. 547 o Traffic Characteristics. In this approach, applications are 548 written in a host-centric manner suitable for point-to-point 549 communication. IoT requires multicast support that is challenging 550 in overlay systems today. 552 o Contextual Communications. This overlay-based approach cannot 553 react to dynamic contextual changes in a timely fashion. The main 554 reason is that context lists are kept at the IoT server in this 555 approach, and they cannot help efficiently route requests 556 information at the network layer. 558 o Storage and Caching. The overlay-based approach supports 559 application-centric storage and caching but not what ICN envisions 560 at the network layer, or flexible storage enabled via name-based 561 routing or name-based lookup. 563 o Self-Organization. The overlay-based approach is topology-based 564 as it is bound to IP semantics, and thus does not sufficiently 565 satisfy the self-organization requirement. In addition to 566 topological self-organization, IoT also requires data- and 567 service-level self-organization [59], which is not supported by 568 the overlay approach. 570 o Ad-hoc and infrastructure mode. As mentioned above, the overlay- 571 based approach lacks self-organization, and thus does not provide 572 efficient support for the ad-hoc mode. 574 4. Advantages of using ICN for IoT 576 A key concept of ICN is the ability to name data independently from 577 the current location at which it is stored, which simplifies caching 578 and enables decoupling of sender and receiver. Using ICN to design 579 an architecture for IoT data potentially provides such advantages 580 compared to using traditional host-centric networks. This section 581 highlights general benefits that ICN could provide to IoT networks. 583 o Naming of Devices, Data and Services. The heterogeneity of both 584 network equipment deployed and services offered by IoT networks 585 leads to a large variety of data, services and devices. While 586 using a traditional host-centric architecture, only devices or 587 their network interfaces are named at the network level, leaving 588 to the application layer the task to name data and services. In 589 many common applications of IoT networks, data and services are 590 the main goal, and specific communication between two devices is 591 secondary. The network distributes content and provides a 592 service, instead of establishing a communication link between two 593 devices. In this context, data content and services can be 594 provided by several devices, or group of devices, hence naming 595 data and services is often more important than naming the devices. 596 This naming mechanism also enables self-configuration of the IoT 597 system. 599 o Distributed Caching and Processing. While caching mechanisms are 600 already used by other types of overlay networks, IoT networks can 601 potentially benefit even more from caching and in-network 602 processing systems, because of their resource constraints. 603 Wireless bandwidth and power supply can be limited for multiple 604 devices sharing a communication channel, and for small mobile 605 devices powered by batteries. In this case, avoiding unnecessary 606 transmissions with IoT devices to retrieve and distribute IoT data 607 to multiple places is important, hence processing and storing such 608 content in the network can save wireless bandwidth and battery 609 power. Moreover, as for other types of networks, applications for 610 IoT networks requiring shorter delays can benefit from local 611 caches and services to reduce delays between content request and 612 delivery. 614 o Decoupling between Sender and Receiver. IoT devices may be mobile 615 and face intermittent network connectivity. When specific data is 616 requested, such data can often be delivered by ICN without any 617 consistent direct connectivity between devices. Apart from using 618 structured caching systems as described previously, information 619 can also be spread by forwarding data opportunistically. 621 5. ICN Challenges for IoT 623 This section outlines some of the ICN specific challenges [71] that 624 must be considered when defining an IoT framework over ICN, and 625 describes some of the trade offs that will be involved. 627 ICN integrates content/service/host abstraction, name-based routing, 628 compute, caching/storage as part of the network infrastructure 629 connecting consumers and services which meets most of the 630 requirements discussed above; however IoT requires special 631 considerations given heterogeneity of devices and interfaces such as 632 for constrained networking [38][70], data processing, and content 633 distribution models to meet specific application requirements which 634 we identify as challenges in this section. 636 5.1. Naming Devices, Data, and Services 638 The ICN approach of named data and services (i.e., device independent 639 naming) is typically desirable when retrieving IoT data. However, 640 data centric naming may also pose challenges. 642 o Naming of devices: Naming devices is often important in an IoT 643 network. The presence of actuators requires clients to act 644 specifically on a device, e.g. to switch it on or off. Also, 645 managing and monitoring the devices for administration purposes 646 requires devices to have a specific name allowing to identify them 647 uniquely. There are multiple ways to achieve device naming, even 648 in systems that are data centric by nature. For example, in 649 systems that are addressable or searchable based on metadata or 650 sensor content, the device identifier can be included as a special 651 kind of metadata or sensor reading. 653 o Size of data/service name: In information centric applications, 654 the size of the data is typically larger than its name. For the 655 IoT, sensors and actuators are very common, and they can generate 656 or use data as small as a short integer containing a temperature 657 value, or a one-byte instruction to switch off an actuator. The 658 name of the content for each of these pieces of data has to 659 uniquely identify the content. For this reason, many existing 660 naming schemes have long names that are likely to be longer than 661 the actual data content for many types of IoT applications. 662 Furthermore, naming schemes that have self certifying properties 663 (e.g., by creating the name based on a hash of the content), 664 suffer from the problem that the object can only be requested when 665 the object has been created and the content is already known, thus 666 requiring some form of indexing service. While this is an 667 acceptable overhead for larger data objects, it is infeasible for 668 use when the object size is on the order of a few bytes. 670 o Hash-based content name: Hash algorithms are commonly used to name 671 content in order to verify that the content is the one requested. 672 This is only possible in contexts where the requested object is 673 already existing, and where there is a directory service to look 674 up names. This approach is suitable for systems with large data 675 objects where it is important to verify the content. 677 o Metadata-based content name: Relying on metadata allows to 678 generate a name for an object before it is created. However this 679 mechanism requires metadata matching semantics. 681 o Naming of services: Similarly to naming of devices or data, 682 services can be referred to with a unique identifier, provided by 683 a specific device or by someone assigned by a central authority as 684 the service provider. It can however also be a service provided 685 by anyone meeting some certain metadata conditions. Example of 686 services include content retrieval, that takes a content name/ 687 description as input and returns the value of that content, and 688 actuation, that takes an actuation command as input and possibly 689 returns a status code afterwards. 691 o Trust: We need to ensure the name of a network element is issued 692 by a trustworthy issuer in the context of the application, such as 693 a trusted organization in [44]. Further the validity of each 694 piece of data published by an authorized entity in the namespace 695 should be verifiable - e.g., by following a hierarchical chain-of- 696 trust to a root that is acceptable for the application. See [54]s 697 for an example. 699 o Flexibility: Further challenges arise for hierarchical naming 700 schema: referring to requirements on "constructible names" and 701 "on-demand publishing" [28][29]. The former entails that each 702 user is able to construct the name of a desired data item through 703 specific algorithms and that it is possible to retrieve 704 information also using partially specified names. The latter 705 refers the possibility to request a content that has not yet been 706 published in the past, thus triggering its creation. 708 o Control/scoping : Some information could be accessible only within 709 a given scope. This challenge is very relevant for smart home and 710 health monitoring applications, where privacy issues play a key 711 role and the local scope of a home or healthcare environment may 712 be well-defined. However, perimeter- and channel-based access 713 control is often violated in current networks to enable over-the- 714 wire updates and cloud-based services, so scoping is unlikely to 715 replace a need for data-centric security in ICN. 717 o Confidentiality: As names can reveal information about the nature 718 of the communication, mechanisms for name confidentiality should 719 be available in the ICN-IoT architecture. 721 5.2. Name Resolution 723 Inter-connecting numerous IoT entities, as well as establishing 724 reachability to them, requires a scalable name resolution system 725 considering several dynamic factors like mobility of end points, 726 service replication, in-network caching, failure or migration [37] 727 [40] [41] [57]. The objective is to achieve scalable name resolution 728 handling static and dynamic ICN entities with low complexity and 729 control overhead. In particular, the main requirements/challenges of 730 a name space (and the corresponding Name Resolution System where 731 necessary) are [31] [33]: 733 o Scalability: The first challenge faced by ICN-IoT name resolution 734 system is its scalability. Firstly, the approach has to support 735 billions of objects and devices that are connected to the 736 Internet, many of which are crossing administrative domain 737 boundaries. Second of all, in addition to objects/devices, the 738 name resolution system is also responsible for mapping IoT 739 services to their network addresses. Many of these services are 740 based upon contexts, hence dynamically changing, as pointed out in 741 [37]. As a result, the name resolution should be able to scale 742 gracefully to cover a large number of names/services with wide 743 variations (e.g., hierarchical names, flat names, names with 744 limited scope, etc.). Notice that, if hierarchical names are 745 used, scalability can be also supported by leveraging the inherent 746 aggregation capabilities of the hierarchy. Advanced techniques 747 such as hyperbolic routing [53] may offer further scalability and 748 efficiency. 750 o Deployability and interoperability: Graceful deployability and 751 interoperability with existing platforms is a must to ensure a 752 naming schema to gain success on the market [7]. As a matter of 753 fact, besides the need to ensure coexistence between IP-centric 754 and ICN-IoT systems, it is required to make different ICN-IoT 755 realms, each one based on a different ICN architecture, to 756 interoperate. 758 o Latency: For real-time or delay sensitive M2M application, the 759 name resolution should not affect the overall QoS. With reference 760 to this issue it becomes important to circumvent too centralized 761 resolution schema (whatever the naming style, i.e, hierarchical or 762 flat) by enforcing in-network cooperation among the different 763 entities of the ICN-IoT system, when possible [58]. In addition, 764 fast name lookup are necessary to ensure soft/hard real time 765 services [60][61][62]. This challenge is especially important for 766 applications with stringent latency requirements, such as health 767 monitoring, emergency handling and smart transportation [63]. 769 o Locality and network efficiency: During name resolution the named 770 entities closer to the consumer should be easily accessible 771 (subject to the application requirements). This requirement is 772 true in general because, whatever the network, if the edges are 773 able to satisfy the requests of their consumers, the load of the 774 core and content seek time decrease, and the overall system 775 scalability is improved. This facet gains further relevance in 776 those domains where an actuation on the environment has to be 777 executed, based on the feedbacks of the ICN-IoT system, such as in 778 robotics applications, smart grids, and industrial plants [59]. 780 o Agility: Some data items could disappear while some other ones are 781 created so that the name resolution system should be able to 782 effectively take care of these dynamic conditions. In particular, 783 this challenge applies to very dynamic scenarios (e.g., VANETs) in 784 which data items can be tightly coupled to nodes that can appear 785 and disappear very frequently. 787 5.3. Caching/Storage 789 In-network caching helps bring data closer to consumers, but its 790 usage differs in constrained and infrastructure part of the IoT 791 network. Caching in constrained networks is limited to small amounts 792 in the order of 10KB, while caching in infrastructure part of the 793 network can allow much larger chunks. 795 Caching in ICN-IoT faces several challenges: 797 o The main challenge is to determine which nodes on the routing path 798 should cache the data. According to [33], caching the data on a 799 subset of nodes can achieve a better gain than caching on every 800 en-route routers. In particular, the authors propose a "selective 801 caching" scheme to locate those routers with better hit 802 probabilities to cache data. According to [34], selecting a 803 random router to cache data is as good as caching the content 804 everywhere. In [55], the authors suggest that edge caching 805 provides most of the benefits of in-network caching typically 806 discussed in NDN, with simpler deployment. However, it and other 807 papers consider workloads that are analogous to today's CDNs, not 808 the IoT applications considered here. Further work is likely 809 required to understand the appropriate caching approach for IoT 810 applications. 812 o Another challenge in ICN-IoT caching is what to cache for IoT 813 applications. In many IoT applications, customers often access a 814 stream of sensor data, and as a result, caching a particular 815 sensor data item may not be beneficial. In [36], the authors 816 suggest to cache IoT services on intermediate routers, and in 817 [37], the authors suggest to cache control information such as 818 pub/sub lists on intermediate nodes. In addition, it is yet 819 unclear what caching means in the context of actuation in an IoT 820 system. For example, it could mean caching the result of a 821 previous actuation request (using other ICN mechanisms to suppress 822 repeated actuation requests within a given time period), or have 823 little meaning at all if actuation uses authenticated requests as 824 in [56]. 826 o Another challenge is that the efficiency of Distributed Caching 827 may be application dependent. When content popularity is 828 heterogeneous, some content is often requested repeatedly. In 829 that case, the network can benefit from caching. Another case 830 where caching would be beneficial is when devices with low duty 831 cycle are present in the network and when access to the cloud 832 infrastructure is limited. However, using distributed caching 833 mechanisms in the network is not useful when each object is only 834 requested at most once, as a cache hit can only occur for the 835 second request and later. It may also be less beneficial to have 836 caches distributed throughout ICN nodes in cases when there are 837 overlays of distributed repositories, e.g., a cloud or a Content 838 Distribution Network (CDN), from which all clients can retrieve 839 the data. Using ICN to retrieve data from such services may add 840 some efficiency, but in case of dense occurrence of overlay CDN 841 servers the additional benefit of caching in ICN nodes would be 842 lower. Another example is when the name refers to an object with 843 variable content/state. For example, when the last value for a 844 sensor reading is requested or desired, the returned data should 845 change every time the sensor reading is updated. In that case, 846 ICN caching may increase the risk that cache inconsistencies 847 result in old data being returned. 849 5.4. Routing and Forwarding 851 Routing in ICN-IoT differs from routing in traditional IP networks in 852 that ICN routing is based upon names instead of locators. Broadly 853 speaking, ICN routing can be categorized into the following two 854 categories: direct name-based routing and indirect routing using a 855 name resolution service (NRS). 857 o In direct name-based routing, packets are forwarded by the name of 858 the data [57][38][42] or the name of the destination node [43]. 859 Here, the main challenge is to keep the ICN router state required 860 to route/forward data low. This challenge becomes more serious 861 when a flat naming scheme is used due to the lack of aggregation 862 capabilities. 864 o In indirect routing, packets are forwarded based upon the locator 865 of the destination node, and the locator is obtained through the 866 name resolution service. In particular, the name-locator binding 867 can be done either before routing (i.e., static binding) or during 868 routing (i.e., dynamic binding). For static binding, the router 869 state is the same as that in traditional routers, and the main 870 challenge is the need to have fast name resolution, especially 871 when the IoT nodes are mobile. For dynamic binding, ICN routers 872 need to main a name-based routing table, hence the challenge of 873 keeping the state information low. At the same time, the need of 874 fast name resolution is also critical. Finally, another challenge 875 is to quantify the cost associated with mobility management, 876 especially static binding vs. dynamic binding. 878 During a network transaction, either the data producer or the 879 consumer may move away and thus we need to handle the mobility to 880 avoid information loss. ICN may differentiate mobility of a data 881 consumer from that of a producer: 883 o When a consumer moves to a new location after sending out the 884 request for Data, the Data may get lost, which requires the 885 consumer to simply resend the request, a technique used by direct 886 routing approach. Indirect routing approach doesn't differentiate 887 between consumer and producer mobility [57], also network caching 888 can improve data recovery for this approach. 890 o If the data producer itself has moved, the challenge is to control 891 the control overhead while searching for a new data producer (or 892 for the same data producer in its new position). To this end, 893 flooding techniques could be used, but an intra-domain level only, 894 otherwise the network stability would be seriously impaired. For 895 handling mobility across different domains, more sophisticated 896 approaches could be used, including the adoption of a SDN-based 897 control plane. 899 5.5. Contextual Communication 901 Contextualization through metadata in ICN control or application 902 payload allows IoT applications to adapt to different environments. 903 This enables intelligent networks which are self-configurable and 904 enable intelligent networking among consumers and producers [36]. 905 For example, let us look at the following smart transportation 906 scenario: "James walks on NYC streets and wants to find an empty cab 907 closest to his location." In this example, the context is the 908 relative locations of James and taxi drivers. A context service, as 909 an IoT middleware, processes the contextual information and bridges 910 the gap between raw sensor information and application requirements. 911 Alternatively, naming conventions could be used to allow applications 912 to request content in namespaces related to their local context 913 without requiring a specific service, such as /local/geo/ 914 mgrs/4QFJ/123/678 to retrieve objects published in the 100m grid area 915 4QFJ 123 678 of the military grid reference system (MGRS). In both 916 cases, trust providers may emerge that can vouch for an application's 917 local knowledge. 919 However, extracting contextual information on a real-time basis is 920 very challenging: 922 o We need to have a fast context resolution service through which 923 the involved IoT devices can continuously update its contextual 924 information to the application (e.g., each taxi's location and 925 Jame's information in the above example). Or, in the namespace 926 driven approach, mechanisms for continuous nearest neighbor 927 queries in the namespace need to be developed. 929 o The difficulty of this challenge grows rapidly when the number of 930 devices involved in a context as well as the number of contexts 931 increases. 933 5.6. In-network Computing 935 In-network computing enables ICN routers to host heterogeneous 936 services catering to various network functions and applications 937 needs. Contextual services for IoT networks require in-network 938 computing, in which each sensor node or ICN router implements context 939 reasoning [36]. Another major purpose of in-network computing is to 940 filter and cleanse sensed data in IoT applications, that is critical 941 as the data is noisy as is [44]. 943 Named Function Networking [64] describes an extension of the ICN 944 concept to named functions processed in the network, which could be 945 used to generate data flow processing applications well-suited to, 946 for example, time series data processing in IoT sensing applications. 947 Related to this, is the need to support efficient function naming. 948 Functions, input parameters, and the output result could be 949 encapsulated in the packet header, the packet body, or mixture of the 950 two (e.g. [24]). If functions are encapsulated in packet headers, 951 the naming scheme affects how a computation task is routed in the 952 network, which IoT devices are involved in the computation task (e.g. 953 [35]), and how a name is decomposed into smaller computation tasks 954 and deployed in the network for a better performance. 956 Another is challenge is related to support computing-aware routing. 957 Normal routing is for forwarding requests to the nearest source or 958 cache and return the data to the requester, whereas the routing for 959 in-network computation has a different purpose. If the computation 960 task is for aggregating sensed data, the routing strategy is to route 961 the data to achieve a better aggregation performance [32]. 963 In-network computing also includes synchronization challenges. Some 964 computation tasks may need synchronizations between sub-tasks or IoT 965 devices, e.g. a device may not send data as soon as it is available 966 because waiting for data from the neighbours may lead to a better 967 aggregation result; some devices may choose to sleep to save energy 968 while waiting for the results from the neighbours; while aggregating 969 the computation results along the path, the intermediate IoT devices 970 may need to choose the results generated within a certain time 971 window. 973 5.7. Security and Privacy 975 Security and privacy is crucial to all the IoT applications 976 applications including the use cases discussed in Section 5. In one 977 recent demonstration,it was shown that passive tire pressure sensors 978 in cars could be hacked and used as a gateway into the automotive 979 system [38]. The ICN paradigm is information-centric as opposed to 980 state-of-the-art host-centric internet. Besides aspects like naming, 981 content retrieval and caching this also has security implications. 982 ICN advocates the model of trust in content rather than trust in 983 network hosts. This brings in the concept of Object Security which 984 is contrary to session-based security mechanisms such as TLS/DTLS 985 prevalent in the current host-centric internet. Object Security is 986 based on the idea of securing information objects unlike session- 987 based security mechanisms which secure the communication channel 988 between a pair of nodes. This reinforces an inherent characteristic 989 of ICN networks i.e. to decouple senders and receivers. In the 990 context of IoT, the Object Security model has several concrete 991 advantages. Many IoT applications have data and services are the 992 main goal and specific communication between two devices is 993 secondary. Therefore, it makes more sense to secure IoT objects 994 instead of securing the session between communicating endpoints. 995 Though ICN includes data-centric security features the mechanisms 996 have to be generic enough to satisfy multiplicity of policy 997 requirements for different applications. Furthermore security and 998 privacy concerns have to be dealt in a scenario-specific manner with 999 respect to network function perspective spanning naming, name- 1000 resolution, routing, caching, and ICN-APIs. In general, we feel that 1001 security and privacy protection in IoT systems should mainly focus on 1002 the following aspects: confidentiality, integrity, authentication and 1003 non-repudiation, and availability. 1005 Implementing security and privacy methods faces different challenges 1006 in the constrained and infrastructure part of the network. 1008 o In the resource-constrained nodes, energy limitation is the 1009 biggest challenge. As an example, let us look at a typical sensor 1010 tag. Suppose the tag has a single 16-bit processor, often running 1011 at 6 MHz to save energy, with 512Bytes of RAM and 16KB of flash 1012 for program storage. Moreover, it has to deliver its data over a 1013 wireless link for at least 10,000 hours on a coin cell battery. 1014 As a result, traditional security/privacy measures are impossible 1015 to be implemented in the constrained part. In this case, one 1016 possible solution might be utilizing the physical wireless signals 1017 as security measures [46] [36]. 1019 o In the infrastructure part, we have several new threats introduced 1020 by ICN-IoT [52]: 1022 1. We need to ensure the name of a network element is issued by a 1023 trustworthy organization entity such as in [48], or by its 1024 trusted delegate. As name securely binds to data in ICN, 1025 security constraints of content that has not yet been 1026 published yet should also be taken into consideration. 1028 2. An intruder may gain access or gather information from a 1029 resource it is not entitled to. As a consequence, an 1030 adversary may examine, remove or even modify confidential 1031 information. 1033 3. An intruder may mimic an authorized user or network process. 1034 As a result, the intruder may forge signatures, or impersonate 1035 a source address. 1037 4. An adversary may manipulate the message exchange process 1038 between network entities. Such manipulation may involve 1039 replay, rerouting, mis-routing and deletion of messages. 1041 5. An intruder may insert fake/false sensor data into the 1042 network. The consequence might be an increase in delay and 1043 performance degradation for network services and applications. 1045 5.8. Self-Orgnization 1047 General IoT deployments involves heterogeneous IoT systems or 1048 subsystems within a particular scenario. Here scope-based self- 1049 organization is required to ensure logical isolation between the IoT 1050 subsystems, which should be enabled at different levels -- device/ 1051 service discovery, naming, topology construction, routing over 1052 logical ICN topologies, and caching [69]. These challenges are 1053 extended to constrained devices as well and they should be energy and 1054 device capability aware. In the infrastructure part, intelligent 1055 name-based routing, caching, in-network computing techniques should 1056 be studied to meet the scope-based self-configuration needs of ICN- 1057 IoT. 1059 5.9. Communications Reliability 1061 ICN offers many ingredients for reliable communication such as multi- 1062 home interest anycast over heterogeneous interfaces, caching, and 1063 forwarding intelligence for multi-path routing leveraging state- 1064 based forwarding in protocols like CCN/NDN. However these features 1065 have not been analyzed from the QoS perspective when heterogeneous 1066 traffic patterns are mixed in a router, in general QoS for ICN is an 1067 open area of research [71]. In-network reliability comes at the cost 1068 of a complex network layer; hence the research challenges here is to 1069 build redundancy and reliability in the network layer to handle a 1070 wide range of disruption scenarios such as congestion, short or long 1071 term disconnection, or last mile wireless impairments. Also an ICN 1072 network should allow features such as opportunistic store and forward 1073 mechanism to be enabled only at certain points in the network, as 1074 these mechanisms also entail overheads in the control and forwarding 1075 plane overhead which will adversely affect application throughput. 1077 5.10. Energy Efficiency 1079 All the optimizations for other components of the ICN-IoT system 1080 (described in earlier subsections) can lead to optimized energy 1081 efficiency. As a result, we refer the readers to read sections 1082 5.1-5.9 for challenges associated with energy efficiency for ICN-IoT. 1084 6. Appendix 1086 Several types of IoT applications exists, where the goal is efficient 1087 and secure management and communication among objects in the system 1088 and with the physical world through sensors, RFIDs and other devices. 1089 Below we list a few popular IoT applications. We omit the often used 1090 term "smart", though it applies to each IoT scenario below, and posit 1091 that IoT-style interconnection of devices to make these environments 1092 "smart" in today's terms will simply be the future norm. 1094 6.1. Homes 1096 The home [10] is a complex ecosystem of IoT devices and applications 1097 including climate control, home security monitoring, smoke detection, 1098 electrical metering, health/wellness, and entertainment systems. In 1099 a unified IoT platform, we would inter-connect these systems through 1100 the Internet, such that they can interact with each other and make 1101 decisions at an aggregated level. Also, the systems can be accessed 1102 and manipulated remotely. Challenges in the home include topology 1103 independent service discovery, common protocol for heterogeneous 1104 device/application/service interaction, policy based routing/ 1105 forwarding, service mobility as well as privacy protection. Notably, 1106 the ease-of-use expectations and training of both users and 1107 installers also presents challenges in user interface and user 1108 experience design that are impacted by the complexity of network 1109 configuration, brittleness to change, configuration of trust 1110 management, etc. Finally, it is unlikely that there will be a single 1111 "home system", but rather a collection of moderately inter-operable 1112 collaborating devices. In addition, several IoT-enabled homes could 1113 form a smart district where it becomes possible to bargain resources 1114 and trade with utility suppliers. 1116 Homes [12][13] faces the following challenges that are hard to 1117 address with IP-based overlay solutions: (1) context-aware control: 1118 home systems must make decisions (e.g., on how to control, when to 1119 collect data, where to carry out computation, when to interact with 1120 end-users, etc.) based upon the contextual information [14]; (2) 1121 inter-operability: home systems must operate with devices that adopt 1122 heterogeneous naming, trust, communication, and control systems; (3) 1123 mobility: home systems must deal with mobility caused by the movement 1124 of sensors or data receivers; (4) security: a home systems must be 1125 able to deal with foreign devices, handle a variety of user 1126 permissions (occupants of various types, guests, device 1127 manufacturers, installers and integrators, utility and infrastructure 1128 providers) and involve users in important security decisions without 1129 overwhelming them; (5) user interface / user experience: homes need 1130 to provide reasonable interfaces to their highly heterogeneous IoT 1131 networks for users with a variety of skill levels, backgrounds, 1132 cultures, interests, etc. 1134 Smart homes have the following specific requirement for the 1135 underlying architecture: 1137 o Smart homes require names that can enable local and wide area 1138 interactions; Also, security, privacy, and access control is 1139 particularly important for smart homes. 1141 o Smart homes may use in-network caching at gateway to enable 1142 efficient content access. 1144 o In smart homes, we need local, intra-domain and inter-domain 1145 routing protocols. 1147 o In smart homes many control loops and actions depend heavily on 1148 the context, and the contexts evolve with time, e.g., temperature, 1149 weather, number of occupants, etc. 1151 o In smart homes, local services can provide value-added 1152 contributions to a standardized home gateway network, through 1153 features such as reporting, context-based control, coordination 1154 with mobile devices, etc. 1156 o In smart homes, the access to networked information should be 1157 shielded to protect the privacy of people, for example, cross- 1158 correlation of device activity patterns to infer higher-level 1159 activity information. 1161 6.2. Enterprise 1163 Enterprise building deployments, from university campuses [15] [65] 1164 [66] [67] to industrial facilities and retail complexes, drive an 1165 additional set of scalability, security, and integration requirements 1166 beyond the home, while requiring much of its ease of use and 1167 flexibility. Additionally, they bring requirements for integration 1168 with business IT systems, though often with the additional support of 1169 in-house engineering support. 1171 Increasing number of enterprises are equipped with sensing and 1172 communication devices inside buildings, laboratories, and plants, at 1173 stadiums, in parking lots, on school buses, etc. A unified IoT 1174 platform must integrate many aspects of human interaction, H2M and 1175 M2M communication, within the enterprise, and thus enable many IoT 1176 applications that can benefit a large body of enterprise affiliates. 1177 The challenges in smart enterprise include efficient and secure 1178 device/data/resource discovery, inter-operability between different 1179 control systems, throughput scaling with number of devices, and 1180 unreliable communication due to mobility and telepresence. 1182 Enterprises face the following challenges that are hard to address 1183 with IP-based overlay solutions: (1) efficient device/data/ resource 1184 discovery: enterprise devices must be able to quickly and securely 1185 discover requested device, data, or resources; (2) scalability: a 1186 enterprise system must be able to scale efficiently with the number 1187 and type of sensors and devices across not only a single building but 1188 multi-national corporations (for example); (3) mobility: a enterprise 1189 system must be able to deal with mobility caused by movement of 1190 devices; (4) security: security for IoT applications in the 1191 enterprise should integrate with other enterprise-wide security 1192 components. 1194 6.3. Smart Grid 1196 Central to the so-called "smart grid"[16] is data flow and 1197 information management, achieved by using sensors and actuators, 1198 which enables important capabilities such as substation and 1199 distribution automation. In a unified IoT platform, data collected 1200 from different smart grids can be integrated to achieve more 1201 optimizations that include reliability, real-time control, secure 1202 communications, and data privacy. 1204 Deployment of the smart grid [17] [21] faces the following issues 1205 that are hard to address with IP-based overlay solutions: (1) 1206 scalability: future electrical grids must be able to scale gracefully 1207 to manage a large number of heterogeneous devices; (2) real time: 1208 grids must be able to perform real-time data collection, data 1209 processing and control; (3) reliability: grids must be resilient to 1210 hardware/software/networking failures; (4) security: grids and 1211 associated systems are often considered critical infrastructure -- 1212 they must be able to defend against malicious attacks, detect 1213 intrusion, and route around disruption. 1215 Smart grids have the following specific requirements for the 1216 underlying IoT architecture: 1218 o Smart grids require names and name resolution system that can 1219 enable networked control loops, real-time control, and security. 1221 o Smart grids may use in-network caching to back up valuable data 1222 improving reliability. 1224 o In smart grids, we often require very timely data delivery. 1225 Therefore, it is important to be able to locate the closest 1226 information. In addition, routing/forwarding robustness and 1227 resilience is also critical. 1229 o In smart grids, contextual information such as location, time, 1230 voltage fluctuations, depending on the specific segment of the 1231 grid, can be used to optimize several power distribution 1232 objectives. 1234 o In smart grids, we often rely on in-network computing to increase 1235 the scalability and efficiency of the system, putting computation 1236 closer to the data sources. 1238 o In smart grids, energy consumptions profiles should never be 1239 disclosed at a fine granularity as it can be used to violate user 1240 privacy. 1242 6.4. Transportation 1244 We are currently witnessing the increasing integration of sensors 1245 into cars, other vehicles transportation systems [22]. Current 1246 production cars already carry many sensors ranging from rain gauges 1247 and accelerometers over wheel rotation/traction sensors, to cameras. 1248 These sensors can not only be used for internal vehicle functions, 1249 but they could also be networked and leveraged for applications such 1250 as monitoring external traffic/road conditions. Further, we can 1251 build vehicle-to- infrastructure (V2I),Vehicle-to-Roadside (V2R), and 1252 vehicle-to- vehicle (V2V) communications that enable many more 1253 applications for safety, convenience, entertainment, etc. The 1254 challenges for transportation include fast data/device/service 1255 discovery and association, efficient communications with mobility, 1256 trustworthy data collection and exchange. 1258 Transportation [22][25] faces the following challenges that are hard 1259 to address with IP-based overlay solutions: (1) mobility: a 1260 transportation system must deal with a large number of mobile nodes 1261 interacting through a combination of infrastructure and ad hoc 1262 communication methods; ; also, during the journey the user might 1263 cross several realms, each one implementing different stacks (whether 1264 ICN or IP); (2) real-time and reliability: transportation systems 1265 must be able to operate in real-time and remain resilient in the 1266 presence of failures; (3) in-network computing/filtering: 1267 transportation systems will benefit from in-network computing/ 1268 filtering as such operations can reduce the end-to-end latency; (4) 1269 inter-operatibility: transportation systems must operate with 1270 heterogeneous device and protocols; (5) security: transportation 1271 systems must be resilient to malicious physical and cyber attacks. 1273 Smart transportation applications have the following specific 1274 requirements for the underlying IoT architecture: 1276 o Smart transportation systems require names and name resolution 1277 system to be able to handle extreme mobility, short latency and 1278 security. In addition, the mobility patterns of transportation 1279 systems increase the likelyhood that a user migrates from one 1280 network realm to another one during the journey. In this case, 1281 names and NRS should be designed in such a way to enable 1282 interoperability between different heterogeneous ICN realms and/or 1283 ICN and IP realms [68]. 1285 o Smart transportation may implement in-network caching on vehicles 1286 for efficient information dissemination 1288 o In smart transportation, vehicle-to-vehicle ad-hoc communication 1289 is required for efficient information dissemination. 1291 o In smart transportation, many different contexts exist, 1292 intertwined to each other and highly changing, which include 1293 location - both geographical and jurisdictional, time - absolute 1294 and relative to a schedule, traffic, speed, etc. 1296 o In smart transportation, in-network computing is very useful to 1297 make vehicle become an active element of the system and to improve 1298 response time and scalability. 1300 o In smart transportation, the habits of users can be inferred by 1301 looking at their movement patterns -- privacy protection is 1302 essential. 1304 6.5. Healthcare 1306 As more embedded medical devices, or devices that can monitor human 1307 health become increasingly deployed, healthcare is becoming a viable 1308 alternative to traditional healthcare solutions [26]. Further, 1309 consumer applications for managing and interacting with health data 1310 are a burgeoning area of research and commercial applications. For 1311 future health applications, a unified IoT platform is critical for 1312 improved patient care and consumer health support by sharing data 1313 across systems, enabling timely actuations, and lowering the time to 1314 innovation by simplifying interaction across devices from many 1315 manufacturers. Challenges in healthcare include real-time 1316 interactions, high reliability, short communication latencies, 1317 trustworthy, security and privacy, and well as defining and meeting 1318 the regulatory requirements that should impact new devices and their 1319 interconnection. In addition to this dimension, assistive robotics 1320 applications are gaining momentum to provide 24/24 7/7 assistance to 1321 patients [59]. 1323 Healthcare [26][27] faces the following challenges that are hard to 1324 address with IP-based overlay solutions: (1) real-time and 1325 reliability: healthcare systems must be able to operate on real-time 1326 and remain resilient in the presence of failures; (2) inter- 1327 operability: healthcare systems must operate with heterogeneous 1328 devices and protocols; (3) security: healthcare systems must be 1329 resilient to malicious physical and cyber attacks and meet the 1330 regulatory requirement for data security and interoperability; (4) 1331 privacy: user trust in healthcare systems is critical, and privacy 1332 considerations paramount to garner adoption and continued user; (5) 1333 user interface / user experience: the highly heterogeneous nature of 1334 real-world healthcare systems, which will continue to increase 1335 through the introduction of IoT devices, presents significant 1336 challenges in interface design that may have architectural 1337 implications. 1339 Smart healthcare applications have the following specific 1340 requirements for the underlying IoT architecture: 1342 o Smart healthcare system requires names and name resolution system 1343 to enable real- time interactions, dependability, and security. 1345 o Smart healthcare may use in-network caching for rapid information 1346 dissemination. 1348 o In smart healthcare, timely and dependable routing and information 1349 forwarding is the key. 1351 o In smart healthcare several contexts can be used to delineate 1352 between levels of care and urgency, for example delineating 1353 between chronic, everyday, urgent, and emergency situations. Such 1354 contexts can evolve rapidly with significant impact to individuals 1355 health. Hence timely and accurate detection of contexts is 1356 critical. 1358 o In smart healthcare, in-network computing can help resolve 1359 contexts and ensure security and dependability, as well as provide 1360 low-latency responses to urgent situations. 1362 o In smart healthcare, personal medical data about patients should 1363 remain shielded to protect their privacy, implementing both 1364 regulatory requirements and current industry best practices. 1366 6.6. Education 1368 IoT technologies enable the instrumentation of a variety of 1369 environments (from greenhouses to industrial plants, homes and 1370 vehicles) to support not only their everyday operation but an 1371 understanding of how they operate -- a fundamental contribution to 1372 education. The diverse uses of hobbyist-oriented micro-controller 1373 platforms (e.g., the Arduino) and embedded systems (e.g., the 1374 Raspberry PI) point to a burgeoning community that should be 1375 supported by the next generation IoT platform because of its 1376 fundamental importance to formal and informal education. 1378 Educational uses of IoT deployments include both learning about the 1379 operation of the system itself as well as the systems being observed 1380 and controlled. Such deployments face the following challenges that 1381 are hard to address with IP-based overlay solutions: (1) relatively 1382 simple communications patterns are obscured by many layers of 1383 translation from the host-based addressing of IP (and layer 2 1384 configuration below) to the name-oriented interfaces provided by 1385 developers; (2) security considerations with overlay deployments and 1386 channel-based limit access to systems where read-only use of data is 1387 not a security risk; (3) real-time communication helps make the 1388 relationship between physical phenomena and network messages easier 1389 to understand in many simple cases; (4) integration of devices from a 1390 variety of sources and manufacturers is currently quite difficult 1391 because of varying standards for basic communication, and limits 1392 experimentation; (5) programming interfaces must be carefully 1393 developed to expose important concepts clearly and in light of 1394 current best practices in education. 1396 Smart campus systems have the following specific requirements for the 1397 underlying IoT architecture: 1399 o Smart campus systems usually consist of heterogeneous IoT 1400 services, thus requiring names and name resolution system to 1401 enable resource/ service ownership, and be application-centric. 1403 o Smart campus systems may use in-network caching to enable social 1404 interactions and efficient content access. 1406 o In smart campus, inter-domain routing protocols are required which 1407 often need short latency. 1409 o In smart campus, due to the existence of many services, relevant 1410 contextual inputs can be used to improve the quality and 1411 efficiency of different services. 1413 o In smart campus, in-network computing services can be used to 1414 provide context for different applications. 1416 o In smart campus, it is required to differentiate among different 1417 profiles and to allocate different rights and protection levels to 1418 them. 1420 6.7. Entertainment, arts, and culture 1422 IoT technologies can contribute uniquely to both the worldwide 1423 entertainment market and the fundamental human activity of creating 1424 and sharing art and culture. By supporting new types of human- 1425 computer interaction, IoT can enable new gaming, film/video, and 1426 other "content" experiences, integrating them with, for example, the 1427 lighting control of the smart home, presentation systems of the smart 1428 enterprise, or even the incentive mechanisms of smart healthcare 1429 systems (to, say, encourage and measure physical activity). 1431 Entertainment, arts, and culture applications generate a variety of 1432 challenges for IoT: (1) notably, the ability to securely "repurpose" 1433 deployed smart systems (e.g., lighting) to create experiences; (2) 1434 low-latency communication to enable end-user responsiveness; (3) 1435 integration with infrastructure-based sensing (e.g., computer vision) 1436 to create comprehensive interactive environments or to provide user 1437 identity information; (4) time synchronization with audio/video 1438 playback and rendering in 3D systems (5) simplicity of development 1439 and experimentation, to enable the cost- and time-efficient 1440 integration of IoT into experiences being designed without expert 1441 engineers of IoT systems; (6) security, because of integration with 1442 personal devices and smart environments, as well as billing systems. 1444 7. Informative References 1446 [1] Cisco System Inc., CISCO., "Cisco visual networking index: 1447 Global mobile data traffic forecast update.", 2009-2014. 1449 [2] Shafig, M., Ji, L., Liu, A., Pang, J., and J. Wang, "A 1450 first look at cellular machine-to-machine traffic: large 1451 scale measurement and characterization.", Proceedings of 1452 the ACM Sigmetrics , 2012. 1454 [3] The European Telecommunications Standards Institute, 1455 ETSI., "http://www.etsi.org/.", 1988. 1457 [4] Global Intiative for M2M Standardization, oneM2M., 1458 "http://www.onem2m.org/.", 2012. 1460 [5] Constrained RESTful Environments, CoRE., 1461 "https://datatracker.ietf.org/wg/core/charter/.", 2013. 1463 [6] Ghodsi, A., Shenker, S., Koponen, T., Singla, A., 1464 Raghavan, B., and J. Wilcox, "Information-Centric 1465 Networking: Seeing the Forest of the Trees.", Hot Topics 1466 in Networking , 2011. 1468 [7] Dong, L., Zhang, Y., and D. Raychaudhuri, "Enhance Content 1469 Broadcast Efficiency in Routers with Integrated Caching.", 1470 Proceedings of the IEEE Symposium on Computers and 1471 Communications (ISCC) , 2011. 1473 [8] NSF FIA project, MobilityFirst., 1474 "http://www.nets-fia.net/", 2010. 1476 [9] Kim, B., Lee, S., Lee, Y., Hwang, I., and Y. Rhee, 1477 "Mobiiscape: Middleware Support for Scalable Mobility 1478 Pattern Monitoring of Moving Objects in a Large-Scale 1479 City.", Journal of Systems and Software, Elsevier, 2011. 1481 [10] Dietrich, D., Bruckne, D., Zucker, G., and P. Palensky, 1482 "Communication and Computation in Buildings: A Short 1483 Introduction and Overview", IEEE Transactions on 1484 Industrial Electronics, 2010. 1486 [11] Keith, K., Falco, F., and K. Scarfone, "Guide to 1487 Industrial Control Systems (ICS) Security", NIST, 1488 Technical Report 800-82 Revision 1, 2013. 1490 [12] Darianian, M. and Martin. Michael, "Smart home mobile 1491 RFID-based Internet-of-Things systems and services.", 1492 IEEE, ICACTE, 2008. 1494 [13] Zhu, Q., Wang, R., Chen, Q., Chen, Y., and W. Qin, "IOT 1495 Gateway: Bridging Wireless Sensor Networks into Internet 1496 of Things", IEEE/IFIP, EUC, 2010. 1498 [14] Biswas, T., Chakrabort, A., Ravindran, R., Zhang, X., and 1499 G. Wang, "Contextualized information-centric home 1500 network", ACM, Siggcomm, 2013. 1502 [15] Huang, R., Zhang, J., Hu, Y., and J. Yang, "Smart Campus: 1503 The Developing Trends of Digital Campus", 2012. 1505 [16] Yan, Y., Qian, Y., Hu, Y., and J. Yang, "A Survey on Smart 1506 Grid Communication Infrastructures: Motivations, 1507 Requirements and Challenges", IEEE Communications Survey 1508 and Tutorials, 2013. 1510 [17] Miao, Y. and Y. Bu, "Research on the Architecture and Key 1511 Technology of Internet of Things (loT) Applied on Smart 1512 Grid", IEEE, ICAEE, 2010. 1514 [18] Castro, M. and A. Jara, "An analysis of M2M platforms: 1515 challenges and opportunities for the Internet of Things", 1516 IMIS, 2012. 1518 [19] Gubbi, J., Buyya, R., and S. Marusic, "Internet of Things 1519 (IoT): A vision, architectural elements, and future 1520 directions", Future Generation Computer Systems, 2013. 1522 [20] Vandikas, K. and V. Tsiatsis, "Performance Evaluation of 1523 an IoT Platform. In Next Generation Mobile Apps, Services 1524 and Technologies(NGMAST)", Next Generation Mobile Apps, 1525 Services and Technologies (NGMAST), 2014. 1527 [21] Zhang, Y., Yu, R., Nekovee, M., Liu, Y., Xie, S., and S. 1528 Gjessing, "Cognitive Machine-to-Machine Communications: 1529 Visions and Potentials for the Smart Grid", IEEE, Network, 1530 2012. 1532 [22] Zhou, H., Liu, B., and D. Wang, "Design and Research of 1533 Urban Intelligent Transportation System Based on the 1534 Internet of Things", Springer Link, 2012. 1536 [23] Alessandrelli, D., Petracca, M., and P. Pagano, "T-Res: 1537 enabling reconfigurable in-network processing in IoT-based 1538 WSNs.", International Conference on Distributed Computing 1539 in Sensor Systems (DCOSS) , 2013. 1541 [24] Kovatsch, M., Mayer, S., and B. Ostermaier, "Moving 1542 application logic from the firmware to the Cloud: towards 1543 the thin server architecture for the internet of things.", 1544 in Proc. 6th Int. Conf. on Innovative Mobile and Internet 1545 Services in Ubiquitous Computing (IMIS) , 2012. 1547 [25] Zhang, M., Yu, T., and G. Zhai, "Smart Transport System 1548 Based on the Internet of Things", Applied Mechanics and 1549 Materials, 2012. 1551 [26] Zhang, A., Yu, R., Nekovee, M., and S. Xie, "The Internet 1552 of Things for Ambient Assisted Living", IEEE, ITNG, 2010. 1554 [27] Savola, R., Abie, H., and M. Sihvonen, "Towards metrics- 1555 driven adaptive security management in E-health IoT 1556 applications.", ACM, BodyNets, 2012. 1558 [28] Jacobson, V., Smetters, D., Plass, M., Stewart, P., 1559 Thornton, J., and R. Braynard, "VoCCN: Voice-over Content- 1560 Centric Networks", ACM, ReArch, 2009. 1562 [29] Piro, G., Cianci, I., Grieco, L., Boggia, G., and P. 1563 Camarda, "Information Centric Services in Smart Cities", 1564 ACM, Journal of Systems and Software, 2014. 1566 [30] Ravindran, R., Biswas, T., Zhang, X., Chakrabort, A., and 1567 G. Wang, "Information-centric Networking based Homenet", 1568 IEEE/IFIP, 2013. 1570 [31] Dannewitz, C., D' Ambrosio, M., and V. Vercellone, 1571 "Hierarchical DHT-based name resolution for information- 1572 centric networks", 2013. 1574 [32] Fasoloy, E., Rossiy, M., and M. Zorziy, "In-network 1575 Aggregation Techniques for Wireless Sensor Networks: A 1576 Survey", IEEE Wireless Communications, 2007. 1578 [33] Chai, W., He, D., and I. Psaras, "Cache "less for more" in 1579 information-centric networks", ACM, IFIP, 2012. 1581 [34] Eum, S., Nakauchi, K., Murata, M., Shoji, Yozo., and N. 1582 Nishinaga, "Catt: potential based routing with content 1583 caching for icn", IEEE Communication Magazine, 2012. 1585 [35] Drira, W. and F. Filali, "Catt: An NDN Query Mechanism for 1586 Efficient V2X Data Collection", Eleventh Annual IEEE 1587 International Conference on Sensing, Communication, and 1588 Networking Workshops (SECON Workshops), 2014. 1590 [36] Eum, S., Shvartzshnaider, Y., Francisco, J., Martini, R., 1591 and D. Raychaudhuri, "Enabling internet-of-things services 1592 in the mobilityfirst future internet architecture", IEEE, 1593 WoWMoM, 2012. 1595 [37] Sun, Y., Qiao, X., Cheng, B., and J. Chen, "A low-delay, 1596 lightweight publish/subscribe architecture for delay- 1597 sensitive IOT services", IEEE, ICWS, 2013. 1599 [38] Baccelli, E., Mehlis, C., Hahm, O., Schmidt, T., and M. 1600 Wahlisch, "Information Centric Networking in the 1601 IoT:Experiments with NDN in the Wild", ACM, ICN Siggcomm, 1602 2014. 1604 [39] Gronbaek, I., "Architecture for the Internet of Things 1605 (IoT): API and interconnect", IEEE, SENSORCOMM, 2008. 1607 [40] Tian, Y., Liu, Y., Yan, Z., Wu, S., and H. Li, "RNS-A 1608 Public Resource Name Service Platform for the Internet of 1609 Things", IEEE, GreenCom, 2012. 1611 [41] Roussos, G. and P. Chartier, "Scalable id/locator 1612 resolution for the iot", IEEE, iThings,CPSCom, 2011. 1614 [42] Amadeo, M. and C. Campolo, "Potential of information- 1615 centric wireless sensor and actor networking", IEEE, 1616 ComManTel, 2013. 1618 [43] Nelson, S., Bhanage, G., and D. Raychaudhuri, "GSTAR: 1619 generalized storage-aware routing for mobilityfirst in the 1620 future mobile internet", ACM, MobiArch, 2011. 1622 [44] Trappe, W., Zhang, Y., and B. Nath, "MIAMI: methods and 1623 infrastructure for the assurance of measurement 1624 information", ACM, DMSN, 2005. 1626 [45] Rouf, I., Mustafa, H., Taylor, T., Oh, S., Xu, W., 1627 Gruteser, M., Trappe, W., and I. Seskar, "Security and 1628 privacy vulnerabilities of in-car wireless networks: A 1629 tire pressure monitoring system case study", USENIX, 2010. 1631 [46] Liu, R. and W. Trappe, "Securing Wireless Communications 1632 at the Physical Layer", Springer, 2010. 1634 [47] Xiao, L., Greenstein, L., Mandayam, N., and W. Trappe, 1635 "Using the physical layer for wireless authentication in 1636 time-variant channels", IEEE Transactions on Wireless 1637 Communications, 2008. 1639 [48] Sun, S., Lannom, L., and B. Boesch, "Handle system 1640 overview", IETF, RFC3650, 2003. 1642 [49] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained 1643 Application Protocol (CoAP)", RFC 7252, 1644 DOI 10.17487/RFC7252, June 2014, 1645 . 1647 [50] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 1648 Protocol (HTTP/1.1): Message Syntax and Routing", 1649 RFC 7230, DOI 10.17487/RFC7230, June 2014, 1650 . 1652 [51] Sun, S., "Hypertext Transfer Protocol (HTTP/1.1): Message 1653 Syntax and Routing", 2014. 1655 [52] Liu, X., Trappe, W., and Y. Zhang, "Secure Name Resolution 1656 for Identifier-to-Locator Mappings in the Global 1657 Internet", IEEE, ICCCN, 2013. 1659 [53] Boguna, M., Fragkiskos, P., and K. Dmitri, "Sustaining the 1660 internet with hyperbolic mapping", Nature Communications, 1661 2010. 1663 [54] Shang, W., "Securing building management systems using 1664 named data networking", IEEE Network 2014. 1666 [55] Fayazbakhsh, S. and et. et al, "Less pain, most of the 1667 gain: Incrementally deployable icn", ACM, Siggcomm, 2013. 1669 [56] Burke, J. and et. et al, "Securing instrumented 1670 environments over Content-Centric Networking: the case of 1671 lighting control", INFOCOM, Computer Communications 1672 Workshop, 2013. 1674 [57] Li, S., Zhang, Y., Dipankar, R., and R. Ravindran, "A 1675 comparative study of MobilityFirst and NDN based ICN-IoT 1676 architectures", IEEE, QShine, 2014. 1678 [58] Grieco, L., Alaya, M., and K. Drira, "Architecting 1679 Information Centric ETSI-M2M systems", IEEE, Pervasive and 1680 Computer Communications Workshop (PERCOM), 2014. 1682 [59] Grieco, L., Rizzo, A., Colucci, R., Sicari, S., Piro, G., 1683 Di Paola, D., and G. Boggia, "IoT-aided robotics 1684 applications: technological implications, target domains 1685 and open issues", Computer Communications, Volume 54, 1 1686 December, 2014. 1688 [60] Quan, Wei., Xu, C., Guan, J., Zhang, H., and L. Grieco, 1689 "Scalable Name Lookup with Adaptive Prefix Bloom Filter 1690 for Named Data Networking", IEEE Communications Letters, 1691 2014. 1693 [61] Wang, Yi., Pan, T., Mi, Z., Dai, H., Guo, X., Zhang, T., 1694 Liu, B., and Q. Dong, "NameFilter: Achieving fast name 1695 lookup with low memory cost via applying two-stage Bloom 1696 filters", INFOCOM, 2013. 1698 [62] So, W., Narayanan, A., Oran, D., and Y. Wang, "Toward fast 1699 NDN software forwarding lookup engine based on Hash 1700 tables", ACM, ANCS, 2012. 1702 [63] Amadeo, M., Campolo, C., Iera, A., and A. Molinaro, "Named 1703 data networking for IoT: An architectural perspective", 1704 IEEE, EuCNC, 2014. 1706 [64] Sifalakis, M., Kohler, B., Christopher, C., and C. 1707 Tschudin, "An information centric network for computing 1708 the distribution of computations", ACM, ICN Sigcomm, 2014. 1710 [65] Lu, R., Lin, X., Zhu, H., and X. Shen, "SPARK: a new 1711 VANET-based smart parking scheme for large parking lots", 1712 INFOCOM, 2009. 1714 [66] Wang, H. and W. He, "A reservation-based smart parking 1715 system", The First International Workshop on Cyber- 1716 Physical Networking Systems, 2011. 1718 [67] Qian, L., "Constructing Smart Campus Based on the Cloud 1719 Computing and the Internet of Things", Computer Science 1720 2011. 1722 [68] Project, BonVoyage., "From Bilbao to Oslo, intermodal 1723 mobility solutions, interfaces and applications for people 1724 and goods, supported by an innovative communication 1725 network", Call H2020-MG-2014, 2015-2018. 1727 [69] Li, S., Zhang, Y., Raychaudhuri, D., Ravindran, R., Zheng, 1728 Q., Wang, GQ., and L. Dong, "IoT Middleware over 1729 Information-Centric Network", Global Communications 1730 Conference (GLOBECOM) ICN Workshop, 2015. 1732 [70] Li, S., Chen, J., Yu, H., Zhang, Y., Raychaudhuri, D., 1733 Ravindran, R., Gao, H., Dong, L., Wang, GQ., and H. Liu, 1734 "MF-IoT: A MobilityFirst-Based Internet of Things 1735 Architecture with Global Reachability and Communication 1736 Diversity", IEEE International Conference on Internet-of- 1737 Things Design and Implementation (IoTDI), 2016. 1739 [71] Campolo, C., Corujo, D., Iera, A., and R. Aguiar, 1740 "Information-centric Networking for Internet-of-things: 1741 Challenges and Opportunities", IEEE Networks, Jan , 2015. 1743 Authors' Addresses 1745 Prof.Yanyong Zhang 1746 WINLAB, Rutgers University 1747 671, U.S 1 1748 North Brunswick, NJ 08902 1749 USA 1751 Email: yyzhang@winlab.rutgers.edu 1753 Prof. Dipankar Raychadhuri 1754 WINLAB, Rutgers University 1755 671, U.S 1 1756 North Brunswick, NJ 08902 1757 USA 1759 Email: ray@winlab.rutgers.edu 1760 Prof. Luigi Alfredo Grieco 1761 Politecnico di Bari (DEI) 1762 Via Orabona 4 1763 Bari 70125 1764 Italy 1766 Email: alfredo.grieco@poliba.it 1768 Prof. Emmanuel Baccelli 1769 INRIA 1770 Room 148, Takustrasse 9 1771 Berlin 14195 1772 France 1774 Email: Emmanuel.Baccelli@inria.fr 1776 Jeff Burke 1777 UCLA REMAP 1778 102 East Melnitz Hall 1779 Los Angeles, CA 90095 1780 USA 1782 Email: jburke@ucla.edu 1784 Ravishankar Ravindran 1785 Huawei Technologies 1786 2330 Central Expressway 1787 Santa Clara, CA 95050 1788 USA 1790 Email: ravi.ravindran@huawei.com 1792 Guoqiang Wang 1793 Huawei Technologies 1794 2330 Central Expressway 1795 Santa Clara, CA 95050 1796 USA 1798 Email: gq.wang@huawei.com 1799 Andres Lindgren 1800 SICS Swedish ICT 1801 Box 1263 1802 Kista SE-164 29 1803 SE 1805 Email: andersl@sics.se 1807 Bengt Ahlgren 1808 SICS Swedish ICT 1809 Box 1263 1810 Kista, CA SE-164 29 1811 SE 1813 Email: bengta@sics.se 1815 Olov Schelen 1816 Lulea University of Technology 1817 Lulea SE-971 87 1818 SE 1820 Email: lov.schelen@ltu.se