idnits 2.17.1 draft-zhang-iot-icn-challenges-02.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 (August 28, 2015) is 3165 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Missing reference section? '1' on line 1182 looks like a reference -- Missing reference section? '2' on line 1185 looks like a reference -- Missing reference section? '11' on line 1222 looks like a reference -- Missing reference section? '8' on line 1209 looks like a reference -- Missing reference section? '3' on line 1190 looks like a reference -- Missing reference section? '4' on line 1193 looks like a reference -- Missing reference section? '5' on line 1196 looks like a reference -- Missing reference section? 'IoTGW' on line 445 looks like a reference -- Missing reference section? '49' on line 1372 looks like a reference -- Missing reference section? '31' on line 1302 looks like a reference -- Missing reference section? '30' on line 1298 looks like a reference -- Missing reference section? '33' on line 1310 looks like a reference -- Missing reference section? '34' on line 1314 looks like a reference -- Missing reference section? '47' on line 1364 looks like a reference -- Missing reference section? '26' on line 1282 looks like a reference -- Missing reference section? '27' on line 1286 looks like a reference -- Missing reference section? '43' on line 1349 looks like a reference -- Missing reference section? '44' on line 1353 looks like a reference -- Missing reference section? '7' on line 1204 looks like a reference -- Missing reference section? '23' on line 1270 looks like a reference -- Missing reference section? '24' on line 1274 looks like a reference -- Missing reference section? '48' on line 1368 looks like a reference -- Missing reference section? '50' on line 1378 looks like a reference -- Missing reference section? '51' on line 1383 looks like a reference -- Missing reference section? '52' on line 1388 looks like a reference -- Missing reference section? '53' on line 1392 looks like a reference -- Missing reference section? '58' on line 1412 looks like a reference -- Missing reference section? '28' on line 1289 looks like a reference -- Missing reference section? '45' on line 1356 looks like a reference -- Missing reference section? '29' on line 1293 looks like a reference -- Missing reference section? '46' on line 1359 looks like a reference -- Missing reference section? '35' on line 1317 looks like a reference -- Missing reference section? '36' on line 1321 looks like a reference -- Missing reference section? '37' on line 1325 looks like a reference -- Missing reference section? '54' on line 1396 looks like a reference -- Missing reference section? '38' on line 1329 looks like a reference -- Missing reference section? '39' on line 1334 looks like a reference -- Missing reference section? '42' on line 1345 looks like a reference -- Missing reference section? '41' on line 1342 looks like a reference -- Missing reference section? '10' on line 1217 looks like a reference -- Missing reference section? '12' on line 1226 looks like a reference -- Missing reference section? '13' on line 1230 looks like a reference -- Missing reference section? '14' on line 1234 looks like a reference -- Missing reference section? '15' on line 1238 looks like a reference -- Missing reference section? '55' on line 1400 looks like a reference -- Missing reference section? '56' on line 1404 looks like a reference -- Missing reference section? '57' on line 1408 looks like a reference -- Missing reference section? '17' on line 1246 looks like a reference -- Missing reference section? '18' on line 1250 looks like a reference -- Missing reference section? '19' on line 1255 looks like a reference -- Missing reference section? '20' on line 1259 looks like a reference -- Missing reference section? '21' on line 1263 looks like a reference -- Missing reference section? '22' on line 1266 looks like a reference -- Missing reference section? '6' on line 1199 looks like a reference -- Missing reference section? '9' on line 1212 looks like a reference -- Missing reference section? '16' on line 1241 looks like a reference -- Missing reference section? '25' on line 1278 looks like a reference -- Missing reference section? '32' on line 1307 looks like a reference -- Missing reference section? '40' on line 1337 looks like a reference Summary: 3 errors (**), 0 flaws (~~), 1 warning (==), 60 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: February 29, 2016 L. Grieco 6 Politecnico di Bari (DEI) 7 E. Baccelli 8 INRIA 9 J. Burke 10 UCLA REMAP 11 R. Ravindran (Ed) 12 G. Wang 13 Huawei Technologies 14 August 28, 2015 16 ICN based Architecture for IoT - Requirements and Challenges 17 draft-zhang-iot-icn-challenges-02 19 Abstract 21 The Internet of Things (IoT) promises to connect billions of objects 22 to Internet. After deploying many stand-alone IoT systems in 23 different domains, the current trend is to develop a common, "thin 24 waist" of protocols forming a unified, defragmented IoT platform. 25 Such a platform will make objects accessible to applications across 26 organizations and domains. Towards this goal, quite a few proposals 27 have been made to build a unified host centric IoT platform as an 28 overlay on top of today's Internet. Such overlay solutions, however, 29 are inadequate to address the important challenges posed by a 30 heterogeneous, global scale deployment of IoT, especially in terms of 31 mobility, scalability, and communication reliability, due to the 32 inherent inefficiencies of the current Internet. To address this 33 problem, we propose to build a common set of protocols and services, 34 which form an IoT platform, based on the Information Centric Network 35 (ICN) architecture, which we call ICN-IoT. ICN-IoT leverages the 36 salient features of ICN, and thus provides seamless mobility support, 37 scalability, and efficient content and service delivery. 39 This draft describes representative IoT requirements and ICN 40 challenges to realize a unified ICN-IoT framework. Towards this, we 41 first identify a list of important requirements which a unified IoT 42 architecture should have to support tens of billions of objects. 43 Though we see most of the IoT requirements can be met by ICN, we 44 discuss specific challenges ICN has to address to satisfy them. Then 45 we discuss important and popular IoT scenarios including the "smart" 46 home, campus, grid, transportation infrastructure, healthcare, 47 Education, and Entertainment. 49 Status of This Memo 51 This Internet-Draft is submitted in full conformance with the 52 provisions of BCP 78 and BCP 79. 54 Internet-Drafts are working documents of the Internet Engineering 55 Task Force (IETF). Note that other groups may also distribute 56 working documents as Internet-Drafts. The list of current Internet- 57 Drafts is at http://datatracker.ietf.org/drafts/current/. 59 Internet-Drafts are draft documents valid for a maximum of six months 60 and may be updated, replaced, or obsoleted by other documents at any 61 time. It is inappropriate to use Internet-Drafts as reference 62 material or to cite them other than as "work in progress." 64 This Internet-Draft will expire on February 29, 2016. 66 Copyright Notice 68 Copyright (c) 2015 IETF Trust and the persons identified as the 69 document authors. All rights reserved. 71 This document is subject to BCP 78 and the IETF Trust's Legal 72 Provisions Relating to IETF Documents 73 (http://trustee.ietf.org/license-info) in effect on the date of 74 publication of this document. Please review these documents 75 carefully, as they describe your rights and restrictions with respect 76 to this document. Code Components extracted from this document must 77 include Simplified BSD License text as described in Section 4.e of 78 the Trust Legal Provisions and are provided without warranty as 79 described in the Simplified BSD License. 81 Table of Contents 83 1. IoT Motivation . . . . . . . . . . . . . . . . . . . . . . . 3 84 2. IoT Architectural Requirements . . . . . . . . . . . . . . . 4 85 2.1. Naming . . . . . . . . . . . . . . . . . . . . . . . . . 4 86 2.2. Scalability . . . . . . . . . . . . . . . . . . . . . . . 4 87 2.3. Resource Constraints . . . . . . . . . . . . . . . . . . 4 88 2.4. Traffic Characteristics . . . . . . . . . . . . . . . . . 5 89 2.5. Contextual Communication . . . . . . . . . . . . . . . . 6 90 2.6. Handling Mobility . . . . . . . . . . . . . . . . . . . . 6 91 2.7. Storage and Caching . . . . . . . . . . . . . . . . . . . 6 92 2.8. Security and Privacy . . . . . . . . . . . . . . . . . . 7 93 2.9. Communication Reliability . . . . . . . . . . . . . . . . 7 94 2.10. Self-Organization . . . . . . . . . . . . . . . . . . . . 8 95 2.11. Ad hoc and Infrastructure Mode . . . . . . . . . . . . . 8 96 2.12. Open API . . . . . . . . . . . . . . . . . . . . . . . . 8 98 3. State of the Art . . . . . . . . . . . . . . . . . . . . . . 8 99 3.1. Silo IoT Architecture . . . . . . . . . . . . . . . . . . 9 100 3.2. Overlay Based Unified IoT Solutions . . . . . . . . . . . 9 101 3.2.1. Weaknesses of the Overlay-based Approach . . . . . . 10 102 4. ICN Challenges for IoT . . . . . . . . . . . . . . . . . . . 11 103 4.1. Naming and Name Resolution . . . . . . . . . . . . . . . 12 104 4.2. Caching/Storage . . . . . . . . . . . . . . . . . . . . . 14 105 4.3. Routing and Forwarding . . . . . . . . . . . . . . . . . 15 106 4.4. Contextual Communication . . . . . . . . . . . . . . . . 17 107 4.5. In-network Computing . . . . . . . . . . . . . . . . . . 18 108 4.6. Security and Privacy . . . . . . . . . . . . . . . . . . 19 109 4.7. Energy Efficiency . . . . . . . . . . . . . . . . . . . . 21 110 5. Popular Scenarios . . . . . . . . . . . . . . . . . . . . . . 21 111 5.1. Homes . . . . . . . . . . . . . . . . . . . . . . . . . . 21 112 5.2. Enterprise . . . . . . . . . . . . . . . . . . . . . . . 22 113 5.3. Smart Grid . . . . . . . . . . . . . . . . . . . . . . . 22 114 5.4. Transportation . . . . . . . . . . . . . . . . . . . . . 23 115 5.5. Healthcare . . . . . . . . . . . . . . . . . . . . . . . 24 116 5.6. Education . . . . . . . . . . . . . . . . . . . . . . . . 24 117 5.7. Entertainment, arts, and culture . . . . . . . . . . . . 25 118 6. Informative References . . . . . . . . . . . . . . . . . . . 25 119 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 30 121 1. IoT Motivation 123 During the past decade, many standalone Internet of Things (IoT) 124 systems have been developed and deployed in different domains. The 125 recent trend, however, is to evolve towards a globally unified IoT 126 platform, in which billions of objects connect to the Internet, 127 available for interactions among themselves, as well as interactions 128 with many different applications across boundaries of administration 129 and domains. Building a unified IoT platform, however, poses great 130 challenges on the underlying network and systems. To name a few, it 131 needs to support 50-100 Billion networked objects [1], many of which 132 are mobile. The objects will have extremely heterogeneous means of 133 connecting to the Internet, often with severe resource constraints. 134 Interactions between the applications and objects are often real-time 135 and dynamic, requiring strong security and privacy protections. In 136 addition, IoT applications are inherently information centric (e.g., 137 data consumers usually need data sensed from the environment without 138 any reference to the sub-set of motes that will provide the asked 139 information). Taking a general IoT perspective, we begin by 140 presenting IoT architectural requirements, then summarize how state- 141 of-art approaches address these requirements. We then discuss IoT 142 challenges from an ICN perspective and requirements posed towards its 143 design. Final discussion focusses on IoT scenarios and their unique 144 challenges. 146 2. IoT Architectural Requirements 148 A unified IoT platform has to support interactions among a large 149 number of mobile devices across the boundaries of organizations and 150 domains. As a result, it naturally poses stringent requirements in 151 every aspect of the system design. Below, we outline a few important 152 requirements that a unified IoT platform has to address. 154 2.1. Naming 156 The first step towards realizing a unified IoT platform is the 157 ability to assign names that are unique within the scope and lifetime 158 of each device, data items generated by these devices, or a group of 159 devices towards a common objective. Naming has the following 160 requirements: first, names need to be persistent (within one or more 161 contexts) against dynamic features that are common in IoT systems, 162 such as lifetime, mobility or migration; second, names need to be 163 secure based on application requirements; third, names should provide 164 advantages to application authors in comparison with traditional host 165 address based schemes. 167 2.2. Scalability 169 Cisco predicts there will be around 50 Billion IoT devices such as 170 sensors, RFID tags, and actuators, on the Internet by 2020 [1]. As 171 mentioned above, a unified IoT platform needs to name every entity 172 such as data, device, service etc. Scalability has to be addressed 173 at multiple levels of the IoT architecture spanning naming, security, 174 name resolution, routing and forwarding level. In addition, mobility 175 adds further challenge in terms of scalability. Particularly with 176 respect to name resolution the system should be able to 177 register/update/resolve up a name within a short latency. To satisfy 178 this requirement, decentralization of the name resolution can be the 179 key. 181 2.3. Resource Constraints 183 IoT devices can be broadly classified into two groups: resource- 184 sufficient and resource-constrained. In general, there are the 185 following types of resources: power, computing, storage, bandwidth, 186 and user interface. 188 Power constraints of IoT devices limit how much data these devices 189 can communicate, as it has been shown that communications consume 190 more power than other activities for embedded devices. Flexible 191 techniques to collect the relevant information are required, and 192 uploading every single produced data to a central server is 193 undesirable. Computing constraints limit the type and amount of 194 processing these devices can perform. As a result, more complex 195 processing needs to be conducted at opportunistic points, example at 196 the network edge, hence it is important to balance local computation 197 versus communication cost. 199 Storage constraints of the IoT devices limit the amount of data that 200 can be stored on the devices. This constraint means that unused 201 sensor data may need to be discarded or stored in aggregated compact 202 form time to time. Bandwidth constraints of the IoT devices limit 203 the amount of communication. Such devices will have the same 204 implication on the system architecture as with the power constraints; 205 namely, we cannot afford to collect single sensor data generated by 206 the device and/or use complex signaling protocols. 208 User interface constraints refer to whether the device is itself 209 capable of directly interacting with a user should the need arise 210 (e.g., via a display and keypad or LED indicators) or requires the 211 network connectivity, either global or local, to interact with 212 humans. 214 2.4. Traffic Characteristics 216 IoT traffic can be broadly classified into local area traffic and 217 wide area traffic. Local area traffic is between nearby devices. 218 For example, neighboring cars may work together to detect potential 219 hazards on the highway, sensors deployed in the same room may 220 collaborate to determine how to adjust the heating level in the room. 221 These local area communications often involve data aggregation and 222 filtering, have real time constraints, and require fast device/data/ 223 service discovery and association. At the same time, the IoT 224 platform has to also support wide area communications. For example, 225 in Intelligent Transportation Systems, re-routing operations may 226 require a broad knowledge of the status of the system, traffic load, 227 availability of freights, whether forecasts and so on. Wide area 228 communications require efficient data/service discovery and 229 resolution services. 231 While traffic characteristics for different IoT systems are expected 232 to be different, certain IoT systems have been analyzed and shown to 233 have comparable uplink and downlink traffic volume in some 234 applications such as [2], which means that we have to optimize the 235 bandwidth/energy consumption in both directions. Further, IoT 236 traffic demonstrates certain periodicity and burstiness [2]. As a 237 result, when provisioning the system, the shape of the traffic volume 238 has to be properly accounted for. 240 2.5. Contextual Communication 242 Many IoT applications shall rely on contextual information such as 243 social, relationships of owners, administrative groupings, location, 244 type of ecosystem (home, grid, transport etc.) of devices and data 245 (which are referred to as contexts in this document) to initiate 246 dynamic relationship and communication. For example, cars traveling 247 on the highway may form a "cluster" based upon their temporal 248 physical proximity as well as the detection of the same event. These 249 temporary groups are referred to as contexts. IoT applications need 250 to support interactions among the members of a context, as well as 251 interactions across contexts. 253 Temporal context can be broadly categorized into two classes, long- 254 term contexts such as those that are based upon social contacts as 255 well as stationary physical locations (e.g., sensors in a car/ 256 building), and short-term contexts such as those that are based upon 257 temporary proximity (e.g., all taxicabs within half a mile of the 258 Time Square at noon on Oct 1, 2013). Between these two classes, 259 short-term contexts are more challenging to support, requiring fast 260 formation, update, lookup and association. 262 2.6. Handling Mobility 264 There are several degrees of mobility in a unified IoT platform, 265 ranging from static as in fixed assets to highly dynamic in vehicle- 266 to-vehicle environments. 268 Mobility in the IoT platform can mean 1) the data producer mobility 269 (i.e., location change), 2) the data consumer mobility, 3) IoT 270 Network mobility (e.g., a body-area network in motion as a person is 271 walking); and 4) disconnection between the data source and 272 destination pair (e.g., due to unreliable wireless links). The 273 requirement on mobility support is to be able to deliver IoT data 274 below an application's acceptable delay constraint in all of the 275 above cases, and and if necessary to negotiate different connectivity 276 or security constraints specific to each mobile context. 278 2.7. Storage and Caching 280 Storage and caching plays a very significant role depending on the 281 type of IoT ecosystem, also a function subjected to privacy and 282 security guidelines. In a unified IoT platform, depending on 283 application requirements, content caching may or may not be policy 284 driven. If caching is pervasive, intermediate nodes don't need to 285 always forward a content request to its original creator; rather, 286 locating and receiving a cached copy is sufficient for IoT 287 applications. This optimization can greatly reduce the content 288 access latencies. 290 Furthermore considering hierarchical nature of IoT systems, ICN 291 architectures enable a more flexible, heterogeneous and potentially 292 fault-tolerant approach to storage providing persistence at multiple 293 levels. 295 In network storage and caching, however, has the following 296 requirements on the IoT platform. The platform needs to support the 297 efficient resolution of cached copies. Further the platform should 298 strive for the balance between caching, content security/privacy, and 299 regulations. 301 2.8. Security and Privacy 303 In addition to the fundamental challenge of trust management, a 304 variety of security and privacy concerns also exist in ICNs. 306 The unified IoT platform makes physical objects accessible to 307 applications across organizations and domains. Further, it often 308 integrates with critical infrastructure and industrial systems with 309 life safety implications, bringing with it significant security 310 challenges and regulatory requirements [11]. 312 Security and privacy thus become a serious concern, as does the 313 flexibility and usability of the design approaches. Beyond the 314 overarching trust management challenge, security includes data 315 integrity, authentication, and access control at different layers of 316 the IoT platform. Privacy means that both the content and the 317 context around IoT data need to be protected. These requirements 318 will be driven by various stake holders such as industry, government, 319 consumers etc. 321 2.9. Communication Reliability 323 IoT applications can be broadly categorized into mission critical and 324 non-mission critical. For mission critical applications, reliable 325 communication is one of the most important features as these 326 applications have strong QoS requirements. Reliable communication 327 requires the following capabilities for the underlying system: (1) 328 seamless mobility support in the face of extreme disruptions (DTN), 329 (2) efficient routing in the presence of intermittent disconnection, 330 (3) QoS aware routing, (4) support for redundancy at all levels of a 331 system (device, service, network, storage etc.). 333 2.10. Self-Organization 335 The unified IoT platform should be able to self-organize to meet 336 various application requirements, especially the capability to 337 quickly discover heterogeneous and relevant (local or global) 338 devices/data/services based on the context. This discovery can be 339 achieved through an efficient platform-wide publish-subscribe 340 service, or through private community grouping/clustering based upon 341 trust and other security requirements. In the former case, the 342 publish-subscribe service must be efficiently implemented, able to 343 support seamless mobility, in- network caching, name-based routing, 344 etc. In the latter case, the IoT platform needs to discover the 345 private community groups/clusters efficiently. 347 2.11. Ad hoc and Infrastructure Mode 349 Depending upon whether there is communication infrastructure, an IoT 350 system can operate either in ad-hoc or infrastructure mode. 352 For example, a vehicle may determine to report its location and 353 status information to a server periodically through cellular 354 connection, or, a group of vehicles may form an ad-hoc network that 355 collectively detect road conditions around them. In the cases where 356 infrastructure is unavailable, one of the participating nodes may 357 choose to become the temporary gateway. 359 The unified IoT platform needs to design a common protocol that 360 serves both modes. Such a protocol should be able to provide: (1) 361 energy-efficient topology discovery and data forwarding in the ad-hoc 362 mode, and (2) scalable name resolution in the infrastructure mode. 364 2.12. Open API 366 General IoT applications involve sensing, processing, and secure 367 content distribution occurring at various timescales and at multiple 368 levels of hierarchy depending on the application requirements. This 369 requires open APIs to be generic enough to support commonly used 370 interactions between consumers, content producer, and IoT services, 371 as opposed to proprietary APIs that are common in today's systems. 372 Examples include pull, push, and publish/subscribe mechanisms using 373 common naming, payload, encryption and signature schemes. 375 3. State of the Art 377 Over the years, many stand-alone IoT systems have been deployed in 378 various domains. These systems usually adopt a vertical silo 379 architecture and support a small set of pre-designated applications. 380 A recent trend, however, is to move away from this approach, towards 381 a unified IoT platform in which the existing silo IoT systems, as 382 well as new systems that are rapidly deployed. This will make their 383 data and services accessible to general Internet applications (as in 384 ETSI- M2M and oneM2M standards). In such a unified platform, 385 resources can be accessed over Internet and shared across the 386 physical boundaries of the enterprise. However, current approaches 387 to achieve this objective are based upon Internet overlays, whose 388 inherent inefficiencies due to IP protocol [8] hinders the platform 389 from satisfying the IoT requirements outlined earlier (particularly 390 in terms of scalability, security, mobility, and self-organization) 392 3.1. Silo IoT Architecture 394 [IoT Server] 395 | 396 | 397 ______|_______ 398 _______ { } 399 { } { } 400 {IoT Dev}\ { Internet }---[IoT Application] 401 {_______} [IoTGW]---{ } 402 { } 403 {______________} 405 Figure 1:Silo architecture of standalone IoT systems 407 A typical standalone IoT system is illustrated in Figure 1, which 408 includes devices, a gateway, a server and applications. Many IoT 409 devices have limited power and computing resources, unable to 410 directly run normal IP access network (Ethernet, WIFI, 3G/LTE etc.) 411 protocols. Therefore they use the IoT gateway to the server. 412 Through the IoT server, applications can subscribe to data collected 413 by devices, or interact with devices. 415 There have been quite a few popular protocols for standalone IoT 416 systems, such as DF-1, MelsecNet, Honeywell SDS, BACnet, etc. 417 However, these protocols are operating at the device-level 418 abstraction, instead of information driven, leading to a highly 419 fragmented protocol space with limited interoperability. 421 3.2. Overlay Based Unified IoT Solutions 423 The current approach to a unified IoT platform is to make IoT 424 gateways and servers adopt standard APIs. IoT devices connect to the 425 Internet through the standard APIs and IoT applications subscribe and 426 receive data through standard control and data APIs. Building on top 427 of today's Internet as an overlay, this is the most practical 428 approach towards a unified IoT platform. There are ongoing 429 standardization efforts including ETSI[3], oneM2M[4],and CORE[5]. 430 Network operators can use standard API to build common IOT gateways 431 and servers for their customers. Figure 2 shows the architecture 432 adopted in this approach. 434 Publishing----[IoT Server]----Subscribing-- 435 | / | \ | 436 | / | \ | 437 | /______|_______ \ | 438 ___________ | /{ } publishing | 439 { } | | { } | | 440 {Smart Homes}\ | | { Internet }---------[IoT Application] 441 {___________} [IoTGW]---{ }\ | ________________ 442 | { } \ | { } 443 | {______________} [IoTGW]-{Smart Healthcare} 444 | | {________________} 445 Publishing [IoTGW] 446 | ____|_____ 447 | { } 448 ---{Smart Grid} 449 {__________} 451 Figure 2: Implementing an open IoT platform through standarized APIs 452 on the IoT gateways and the server 454 3.2.1. Weaknesses of the Overlay-based Approach 456 The above overlay-based approach can work with many different 457 protocols, but the system is built upon today's IP network, which has 458 inherent weaknesses towards supporting a unified IoT system. As a 459 result, it cannot satisfy some of the requirements we outlined in 460 Section 2: 462 o Naming. In current overlays for IoT systems the naming scheme is 463 host centric, i.e., the name of a given resource/service is linked 464 to the one of device that can provide it. In turn, device names 465 are coupled to IP addresses, which are not persistent in mobile 466 scenarios. On the other side, in IoT systems the same service/ 467 resource could be provided by many different devices thus 468 requiring a different design rationale. 470 o Trust. Trust management schemes are still relatively weak, 471 focusing on securing communication channels rather than managing 472 the data that needs to be secured directly. 474 o Mobility. The overlay-based approach uses IP addresses as names 475 at the network layer, which hinders the support for device/service 476 mobility or flexible name resolution. Further the Layer 2/3 477 management, and application-layer addressing and forwarding 478 required to deploy current IoT solutions limit the scalability and 479 management of these systems. 481 o Resource constraints. The overlay-based approach requires every 482 device to send data to an aggregator or to the IoT server. 483 Resource constraints of the IoT devices, especially in power and 484 bandwidth, could seriously limit the performance of this approach. 486 o Traffic Characteristics. In this approach, applications are 487 written in a host-centric manner suitable for point-to-point 488 communication. IoT requires multicast support that is challenging 489 in overlay systems today. 491 o Contextual Communications. This overlay-based approach cannot 492 react to dynamic contextual changes in a timely fashion. The main 493 reason is that context lists are kept at the IoT server in this 494 approach, and they cannot help efficiently route requests 495 information at the network layer. 497 o Storage and Caching. The overlay-based approach supports 498 application-centric storage and caching but not what ICN envisions 499 at the network layer, or flexible storage enabled via name-based 500 routing or name-based lookup. 502 o Self-Organization. The overlay-based approach is topology-based 503 as it is bound to IP semantics, and thus does not sufficiently 504 satisfy the self-organization requirement. In addition to 505 topological self-organization, IoT also requires data- and 506 service-level self-organization [49], which is not supported by 507 the overlay approach. 509 o Ad-hoc and infrastructure mode. As mentioned above, the overlay- 510 based approach lacks self-organization, and thus does not provide 511 efficient support for the ad-hoc mode. 513 4. ICN Challenges for IoT 515 ICN integrates content/service/host abstraction, name-based routing, 516 compute, caching/storage as part of the network infrastructure 517 connecting consumers and services which meets most of the 518 requirements discussed above; however IoT requires special 519 considerations given heterogeneity of devices and interfaces such as 520 for constrained networking [31], data processing, and content 521 distribution models to meet specific application requirements which 522 we identify as challenges in this section. We also discuss scenario 523 specific challenges discussed in Section 5. 525 4.1. Naming and Name Resolution 527 Inter-connecting numerous IoT entities, as well as establishing 528 reachability to them, requires a scalable name resolution system 529 considering several dynamic factors like mobility of end points, 530 service replication, in-network caching, failure or migration [30] 531 [33] [34] [47]. The objective is to achieve scalable name resolution 532 handling static and dynamic ICN entities with low complexity and 533 control overhead. In particular, the main requirements/challenges of 534 a name space (and the corresponding Name Resolution System where 535 necessary) are [26] [27]: 537 o Scalability: The first challenge faced by ICN-IoT name resolution 538 system is its scalability. Firstly, the approach has to support 539 billions of objects and devices that are connected to the 540 Internet, many of which are crossing administrative domain 541 boundaries. Second of all, in addition to objects/devices, the 542 name resolution system is also responsible for mapping IoT 543 services to their network addresses. Many of these services are 544 based upon contexts, hence dynamically changing, as pointed out in 545 [30]. As a result, the name resolution should be able to scale 546 gracefully to cover a large number of names/services with wide 547 variations (e.g., hierarchical names, flat names, names with 548 limited scope, etc.). Notice that, if hierarchical names are 549 used, scalability can be also supported by leveraging the inherent 550 aggregation capabilities of the hierarchy. Advanced techniques 551 such as hyperbolic routing [43] may offer further scalability and 552 efficiency. 554 o Trust: We need to ensure the name of a network element is issued 555 by a trustworthy issuer in the context of the application, such as 556 a trusted organization in [44]. Further the validity of each 557 piece of data published by an authorized entity in the namespace 558 should be verifiable - e.g., by following a hierarchical chain-of- 559 trust to a root that is acceptable for the application. See [44] 560 for an example. 562 o Deployability and interoperability: Graceful deployability and 563 interoperability with existing platforms is a must to ensure a 564 naming schema to gain success on the market [7]. As a matter of 565 fact, besides the need to ensure coexistence between IP-centric 566 and ICN-IoT systems, it is required to make different ICN-IoT 567 realms, each one based on a different ICN architecture, to 568 interoperate. 570 o Flexibility: Further challenges arise for hierarchical naming 571 schema: referring to requirements on "constructable names" and 572 "on-demand publishing" [23][24]. The former entails that each 573 user is able to construct the name of a desired data item through 574 specific algorithms and that it is possible to retrieve 575 information also using partially specified names. The latter 576 refers the possibility to request a content that has not yet been 577 published in the past, thus triggering its creation. 579 o Latency: For real-time or delay sensitive M2M application, the 580 name resolution should not affect the overall QoS. With reference 581 to this issue it becomes important to circumvent too centralized 582 resolution schema (whatever the naming style, i.e, hierarchical or 583 flat) by enforcing in-network cooperation among the different 584 entities of the ICN-IoT system, when possible [48]. In addition, 585 fast name lookup are necessary to ensure soft/hard real time 586 services [50][51][52]. This challenge is especially important for 587 applications with stringent latency requirements, such as health 588 monitoring, emergency handling and smart transportation [53]. 590 o Locality and network efficiency: During name resolution the named 591 entities closer to the consumer should be easily accessible 592 (subject to the application requirements). This requirement is 593 true in general because, whatever the network, if the edges are 594 able to satisfy the requests of their consumers, the load of the 595 core and content seek time decrease, and the overall system 596 scalability is improved. This facet gains further relevance in 597 those domains where an actuation on the environment has to be 598 executed, based on the feedbacks of the ICN-IoT system, such as in 599 robotics applications, smart grids, and industrial plants [49]. 601 o Agility: Some data items could disappear while some other ones are 602 created so that the name resolution system should be able to 603 effectively take care of these dynamic conditions. In particular, 604 this challenge applies to very dynamic scenarios (e.g., VANETs) in 605 which data items can be tightly coupled to nodes that can appear 606 and disappear very frequently. 608 o Control/scoping: Some information could be accessible only within 609 a given scope. This challenge is very relevant for smart home and 610 health monitoring applications, where privacy issues play a key 611 role and the local scope of a home or healthcare environment may 612 be well-defined. However, perimeter- and channel-based access 613 control is often violated in current networks to enable over-the- 614 wire updates and cloud-based services, so scoping is unlikely to 615 replace a need for data-centric security in ICN. 617 o Confidentiality: As names can reveal information about the nature 618 of the communication, mechanisms for name confidentiality should 619 be available in the ICN-IoT architecture. 621 In addition to the above general requirements, we identify the 622 following specific requirements for different IoT applications: 624 o Smart homes require names that can enable local and wide area 625 interactions; Also, security, privacy, and access control is 626 particularly important for smart homes. 628 o Smart grids require names and name resolution system that can 629 enable networked control loops, real-time control, and security. 631 o Smart transportation systems require names and name resolution 632 system to be able to handle extreme mobility, short latency and 633 security. In addition, the mobility patterns of transportation 634 systems increase the likelyhood that a user migrates from one 635 network realm to another one during the journey. In this case, 636 names and NRS should be designed in such a way to enable 637 interoperability between different heterogeneous ICN realms and/or 638 ICN and IP realms [58]. 640 o Smart healthcare system requires names and name resolution system 641 to enable real- time interactions, dependability, and security. 643 o Smart campus systems usually consist of hetereogeneous IoT 644 services, thus requring names and name resolution system to enable 645 resource/ service ownership, and be application-centric. 647 4.2. Caching/Storage 649 In-network caching helps bring data closer to consumers, but its 650 usage differs in constrained and infrastructure part of the IoT 651 network. Caching in constrained networks is limited to small amounts 652 in the order of 10KB, while caching in infrastructure part of the 653 network can allow much larger chunks. 655 Caching in ICN-IoT faces several challenges: 657 o The main challenge is to determine which nodes on the routing path 658 should cache the data. According to [27], caching the data on a 659 subset of nodes can achieve a better gain than caching on every 660 en-route routers. In particular, the authors propose a "selective 661 caching" scheme to locate those routers with better hit 662 probabilities to cache data. According to [28], selecting a 663 random router to cache data is as good as caching the content 664 everywhere. In [45], the authors suggest that edge caching 665 provides most of the benefits of in-network caching typically 666 discussed in NDN, with simpler deployment. However, it and other 667 papers consider workloads that are analogous to today's CDNs, not 668 the IoT applications considered here. Further work is likely 669 required to understand the appropriate caching approach for IoT 670 applications. 672 o Another challenge in ICN-IoT caching is what to cache for IoT 673 applications. In many IoT applications, customers often access a 674 stream of sensor data, and as a result, caching a particular 675 sensor data item may not be beneficial. In [29], the authors 676 suggest to cache IoT services on intermediate routers, and in 677 [30], the authors suggest to cache control information such as 678 pub/sub lists on intermediate nodes. In addition, it is yet 679 unclear what caching means in the context of actuation in an IoT 680 system. For example, it could mean caching the result of a 681 previous actuation request (using other ICN mechanisms to suppress 682 repeated actuation requests within a given time period), or have 683 little meaning at all if actuation uses authenticated requests as 684 in [46]. 686 Next we use specific IoT systems to explain the caching challenge: 688 o Smart homes may use in-network caching at gateway to enable 689 efficient content access 691 o Smart grids may use in-network caching to back up valuable data 693 o Smart transportation may implement in-network caching on vehicles 694 for efficient information dissemination 696 o Smart healthcare may use in-network caching for rapid information 697 dissemination 699 o Smart campus systems may use in-network caching to enable social 700 interactions and efficient content access. 702 4.3. Routing and Forwarding 704 Routing in ICN-IoT differs from routing in traditional IP networks in 705 that ICN routing is based upon names instead of locators. Broadly 706 speaking, ICN routing can be categorized into the following two 707 categories: direct name-based routing and indirect routing using a 708 name resolution service (NRS). 710 o In direct name-based routing, packets are forwarded by the name of 711 the data [47][31][35] or the name of the destination node [36]. 712 Here, the main challenge is to keep the ICN router state required 713 to route/forward data low. This challenge becomes more serious 714 when a flat naming scheme is used due to the lack of aggregation 715 capabilities. 717 o In indirect routing, packets are forwarded based upon the locator 718 of the destination node, and the locator is obtained through the 719 name resolution service. In particular, the name-locator binding 720 can be done either before routing (i.e., static binding) or during 721 routing (i.e., dynamic binding). For static binding, the router 722 state is the same as that in traditional routers, and the main 723 challenge is the need to have fast name resolution, especially 724 when the IoT nodes are mobile. For dynamic binding, ICN routers 725 need to main a name-based routing table, hence the challenge of 726 keeping the state information low. At the same time, the need of 727 fast name resolution is also critical. Finally, another challenge 728 is to quantify the cost associated with mobility management, 729 especially static binding vs. dynamic binding. 731 During a network transaction, either the data producer or the 732 consumer may move away and thus we need to handle the mobility to 733 avoid information loss. ICN may differentiate mobility of a data 734 consumer from that of a producer: 736 o When a consumer moves to a new location after sending out the 737 request for Data, the Data may get lost, which requires the 738 consumer to simply resend the request, a technique used by direct 739 routing approach. Indirect routing approach doesn't differentiate 740 between consumer and producer mobility [47], also network caching 741 can improve data recovery for this approach. 743 o If the data producer itself has moved, the challenge is to control 744 the control overhead while searching for a new data producer (or 745 for the same data producer in its new position). To this end, 746 flooding techniques could be used, but an intra-domain level only, 747 otherwise the network stability would be seriously impaired. For 748 handling mobility across different domains, more sophisticated 749 approaches could be used, including the adoption of a SDN-based 750 control plane. 752 Finally, in addition to the above requirements, specific IoT 753 applications may impose specific challenges on routing and 754 forwarding: 756 o In smart homes, we need local, intra-domain and inter-domain 757 routing protocols. 759 o In smart grids, we often require very timely data delivery. 760 Therefore, it is important to be able to locate the closest 761 information. In addition, routing/forwarding robustness and 762 resilience is also critical. 764 o In smart transportation, vehicle-to-vehicle ad-hoc communication 765 is required for efficient information dissemination. 767 o In smart healthcare, timely and dependable routing and information 768 forwarding is the key. 770 o In smart campus, inter-domain routing protocols are required which 771 often need short latency. 773 4.4. Contextual Communication 775 Contextualization through metadata in ICN control or application 776 payload allows IoT applications to adapt to different environments. 777 This enables intelligent networks which are self-configurable and 778 enable intelligent networking among consumers and producers [29]. 779 For example, let us look at the following smart transportation 780 scenario: "James walks on NYC streets and wants to find an empty cab 781 closest to his location." In this example, the context is the 782 relative locations of James and taxi drivers. A context service, as 783 an IoT middleware, processes the contextual information and bridges 784 the gap between raw sensor information and application requirements. 785 Alternatively, naming conventions could be used to allow applications 786 to request content in namespaces related to their local context 787 without requiring a specific service, such as /local/geo/ 788 mgrs/4QFJ/123/678 to retrieve objects published in the 100m grid area 789 4QFJ 123 678 of the military grid reference system (MGRS). In both 790 cases, trust providers may emerge that can vouch for an application's 791 local knowledge. 793 However, extracting contextual information on a real-time basis is 794 very challenging: 796 o We need to have a fast context resolution service through which 797 the involved IoT devices can continuously update its contextual 798 information to the application (e.g., each taxi's location and 799 Jame's information in the above example). Or, in the namespace 800 driven approach, mechanisms for continuous nearest neighbor 801 queries in the namespace need to be developed. 803 o The difficulty of this challenge grows rapidly when the number of 804 devices involved in a context as well as the number of contexts 805 increases. 807 Next, in addition to the above requirements, specific IoT services 808 may impose specific challenges on contextual communication: 810 o In smart homes many control loops and actions are depend heavily 811 on the context, and the contexts evolve with time, e.g., 812 temperature, weather, number of occupants, etc 814 o In smart grids, contextual information such as location, time, 815 voltage fluctuations, depending on the specific segment of the 816 grid, can be used to optimize several power distribution 817 objectives. 819 o In smart transportation, many different contexts exist, 820 intertwined to each other and highly changing, which include 821 location - both geographical and jurisdictional, time - absolute 822 and relative to a schedule, traffic, speed, etc. 824 o In smart healthcare several contexts can be used to delineate 825 between levels of care and urgency, for example delineating 826 between chronic, everyday, urgent, and emergency situations. Such 827 contexts can evolve rapidly with significant impact to individuals 828 health. Hence timely and accurate detection of contexts is 829 critical. 831 o In smart campus, due to the existence of many services, relevant 832 contextual inputs can be used to improve the quality and 833 efficiency of different services. 835 4.5. In-network Computing 837 In-network computing enables ICN routers to host heterogenous 838 services catering to various network functions and applications 839 needs. Contextual services for IoT networks require in-network 840 computing, in which each sensor node or ICN router implements context 841 reasoning [29]. Another major purpose of in-network computing is to 842 filter and cleanse sensed data in IoT applications is critical as the 843 data is noisy as is [37]. Named Function Networking [54] describes 844 an extension of the ICN concept to named functions processed in the 845 network, which could be used to generate data flow processing 846 applications well-suited to, for example, time series data processing 847 in IoT sensing applications. 849 o In smart homes, local services can provide value-added 850 contributions to a standardized home gateway network, through 851 features such as reporting, context-based control, coordination 852 with mobile devices, etc. 854 o In smart grids, we often rely on in-network computing to increase 855 the scalability and efficiency of the system, putting computation 856 closer to the data sources. 858 o In smart transportation, in-network computing is very useful to 859 make vehicle become an active element of the system and to improve 860 response time and scalability. 862 o In smart healthcare, in-network computing can help resolve 863 contexts and ensure security and dependability, as well as provide 864 low-latency responses to urgent situations. 866 o In smart campus, in-network computing services can be used to 867 provide context for different applications. 869 4.6. Security and Privacy 871 Security and privacy is crucial to all the IoT applications including 872 the use cases discussed in Section 5. In one recent demonstration, 873 it was shown that passive tire pressure sensors in cars could be 874 hacked and used as a gateway into the automotive system [38]. Though 875 ICN includes data-centric security features the mechanisms have to be 876 generic enough to satisfy multiplicity of policy requirements for 877 different applications. Furthermore security and privacy concerns 878 have to be dealt in a scenario-specific manner with respect to 879 network function perspective spanning naming, name-resolution, 880 routing, caching, and ICN-APIs. In general, we feel that security 881 and privacy protection in IoT systems should mainly focus on the 882 following aspects: confidentiality, integrity, authentication and 883 non-repudiation, and availability. 885 Implementing security and privacy methods faces different challenges 886 in the constrained and infrastructure part of the network. 888 o In the resource-constrained nodes, energy limitation is the 889 biggest challenge. As an example, let us look at a typical sensor 890 tag. Suppose the tag has a single 16-bit processor, often running 891 at 6 MHz to save energy, with 512Bytes of RAM and 16KB of flash 892 for program storage. Moreover, it has to deliver its data over a 893 wireless link for at least 10,000 hours on a coin cell battery. 894 As a result, traditional security/privacy measures are impossible 895 to be implemented in the constrained part. In this case, one 896 possible solution might be utilizing the physical wireless signals 897 as security measures [39] [29]. 899 o In the infrastructure part, we have several new threats introduced 900 by ICN-IoT [42]: 902 1. We need to ensure the name of a network element is issued by a 903 trustworthy organization entity such as in [41], or by its 904 trusted delegate. 906 2. An intruder may gain access or gather information from a 907 resource it is not entitled to. As a consequence, an 908 adversary may examine, remove or even modify confidential 909 information. 911 3. An intruder may mimic an authorized user or network process. 912 As a result, the intruder may forge signatures, or impersonate 913 a source address. 915 4. An adversary may manipulate the message exchange process 916 between network entities. Such manipulation may involve 917 replay, rerouting, mis-routing and deletion of messages. 919 5. An intruder may insert fake/false sensor data into the 920 network. The consequence might be an increase in delay and 921 performance degradation for network services and applications. 923 Finally, in addition to the above requirements, specific IoT 924 applications may impose specific challenges on privacy that impact 925 both applications and the ICN-IoT network: 927 o In smart homes, the access to networked information should be 928 shielded to protect the privacy of people, for example, cross- 929 correlation of device activity patterns to infer higher-level 930 activity information. 932 o In smart grids, energy consumptions profiles should not been never 933 disclosed at a fine granularity since from them it is possible to 934 violate the privacy of users. 936 o In smart transportation, the habits of users can be inferred by 937 looking at their movement patterns -- privacy protection is 938 essential. 940 o In smart healthcare, personal medical data about patients should 941 remain shielded to protect their privacy, implementing both 942 regulatory requirements and current industry best practices. 944 o In smart campus, it is required to differentiate among different 945 profiles and to allocate different rights and protection levels to 946 them. 948 4.7. Energy Efficiency 950 All the optimizations for other components of the ICN-IoT system 951 (described in earlier subsections) can lead to optimized energy 952 efficiency. As a result, we refer the readers to read sections 953 4.1-4.6 for challenges associated with energy efficiency for ICN-IoT. 955 5. Popular Scenarios 957 Several types of IoT applications exists, where the goal is efficient 958 and secure management and communication among objects in the system 959 and with the physical world through sensors, RFIDs and other devices. 960 Below we list a few popular IoT applications. We omit the often used 961 term "smart", though it applies to each IoT scenario below, and posit 962 that IoT-style interconnection of devices to make these environments 963 "smart" in today's terms will simply be the future norm. 965 5.1. Homes 967 The home [10] is a complex ecosystem of IoT devices and applications 968 including climate control, home security monitoring, smoke detection, 969 electrical metering, health/wellness, and entertainment systems. In 970 a unified IoT platform, we would inter-connect these systems through 971 the Internet, such that they can interact with each other and make 972 decisions at an aggregated level. Also, the systems can be accessed 973 and manipulated remotely. Challenges in the home include topology 974 independent service discovery, common protocol for heterogeneous 975 device/application/service interaction, policy based routing/ 976 forwarding, service mobility as well as privacy protection. Notably, 977 the ease-of-use expectations and training of both users and 978 installers also presents challenges in user interface and user 979 experience design that are impacted by the complexity of network 980 configuration, brittleness to change, configuration of trust 981 management, etc. Finally, it is unlikely that there will be a single 982 "home system", but rather a collection of moderately inter-operable 983 collaborating devices. In addition, several IoT-enabled homes could 984 form a smart district where it becomes possible to bargain resources 985 and trade with utility suppliers. 987 Homes [12][13] faces the following challenges that are hard to 988 address with IP-based overlay solutions: (1) context-aware control: 989 home systems must make decisions (e.g., on how to control, when to 990 collect data, where to carry out computation, when to interact with 991 end-users, etc.) based upon the contextual information [14]; (2) 992 inter-operability: home systems must operate with devices that adopt 993 heterogeneous naming, trust, communication, and control systems; (3) 994 mobility: home systems must deal with mobility caused by the movement 995 of sensors or data receivers; (4) security: a home systems must be 996 able to deal with foreign devices, handle a variety of user 997 permissions (occupants of various types, guests, device 998 manufacturers, installers and integrators, utility and infrastructure 999 providers) and involve users in important security decisions without 1000 overwhelming them; (5) user interface / user experience: homes need 1001 to provide reasonable interfaces to their highly heterogeneous IoT 1002 networks for users with a variety of skill levels, backgrounds, 1003 cultures, interests, etc. 1005 5.2. Enterprise 1007 Enterprise building deployments, from university campuses [15] [55] 1008 [56] [57] to industrial facilities and retail complexes, drive an 1009 additional set of scalability, security, and integration requirements 1010 beyond the home, while requiring much of its ease of use and 1011 flexibility. Additionally, they bring requirements for integration 1012 with business IT systems, though often with the additional support of 1013 in-house engineering support. 1015 Increasing number of enterprises are equipped with sensing and 1016 communication devices inside buildings, laboratories, and plants, at 1017 stadiums, in parking lots, on school buses, etc. A unified IoT 1018 platform must integrate many aspects of human interaction, H2M and 1019 M2M communication, within the enterprise, and thus enable many IoT 1020 applications that can benefit a large body of enterprise affiliates. 1021 The challenges in smart enterprise include efficient and secure 1022 device/data/resource discovery, inter-operability between different 1023 control systems, throughput scaling with number of devices, and 1024 unreliable communication due to mobility and telepresence. 1026 Enterprises face the following challenges that are hard to address 1027 with IP-based overlay solutions: (1) efficient device/data/ resource 1028 discovery: enterprise devices must be able to quickly and securely 1029 discover requested device, data, or resources; (2) scalability: a 1030 enterprise system must be able to scale efficiently with the number 1031 and type of sensors and devices across not only a single building but 1032 multi-national corporations (for example); (3) mobility: a enterprise 1033 system must be able to deal with mobility caused by movement of 1034 devices; (4) security: security for IoT applications in the 1035 enterprise should integrate with other enterprise-wide security 1036 components. 1038 5.3. Smart Grid 1040 Central to the so-called "smart grid"[16] is data flow and 1041 information management, achieved by using sensors and actuators, 1042 which enables important capabilities such as substation and 1043 distribution automation. In a unified IoT platform, data collected 1044 from different smart grids can be integrated to reach more 1045 significant optimizations. The challenges for smart grid include 1046 reliability, real-time control, secure communications, and data 1047 privacy. 1049 Deployment of the smart grid [17] [18] faces the following issues 1050 that are hard to address with IP-based overlay solutions: (1) 1051 scalability: tomorrow's electrical grids must be able to scale 1052 gracefully to manage a large number of heterogeneous devices; (2) 1053 real time: grids must be able to perform real-time data collection, 1054 data processing and control; (3) reliability: grids must be resilient 1055 to hardware/software/networking failures; (4) security: grids and 1056 associated systems are often considered critical infrastructure -- 1057 they must be able to defend against malicious attacks, detect 1058 intrusion, and route around disruption. 1060 5.4. Transportation 1062 We are currently witnessing the increasing integration of sensors 1063 into cars, other vehicles transportation systems [19]. Current 1064 production cars already carry many sensors ranging from rain gauges 1065 and accelerometers over wheel rotation/traction sensors, to cameras. 1066 While intended for internal vehicle functions, these could also be 1067 networked and leveraged for applications such as monitoring external 1068 traffic/road conditions. Further, we can build vehicle-to- 1069 infrastructure (V2I),Vehicle-to-Roadside (V2R), and vehicle-to- 1070 vehicle (V2V) communications that enable many more applications for 1071 safety, convenience, entertainment, etc. The challenges for 1072 transportation include fast data/device/service discovery and 1073 association, efficient communications with mobility, trustworthy data 1074 collection and exchange. 1076 Transportation [19][20] faces the following challenges that are hard 1077 to address with IP-based overlay solutions: (1) mobility: a 1078 transportation system must deal with a large number of mobile nodes 1079 interacting through a combination of infrastructure and ad hoc 1080 communication methods; ; also, during the journey the user might 1081 cross several realms, each one implementing different stacks (whether 1082 ICN or IP); (2) real-time and reliability: transportation systems 1083 must be able to operate on real-time and remain resilient in the 1084 presence of failures; (3) in-network computing/filtering: 1085 transportation systems will benefit from in-network computing/ 1086 filtering as such operations can reduce the end-to-end latency; (4) 1087 inter-operatibility: transportation systems must operate with 1088 heterogeneous device and protocols; (5) security: transportation 1089 systems must be resilient to malicious physical and cyber attacks. 1091 5.5. Healthcare 1093 As more embedded medical devices, or devices that can monitor human 1094 health become increasingly deployed, healthcare is becoming a viable 1095 alternative to traditional healthcare solutions [21]. Further, 1096 consumer applications for managing and interacting with health data 1097 are a burgeoning area of research and commercial applications. For 1098 future health applications, a unified IoT platform is critical for 1099 improved patient care and consumer health support by sharing data 1100 across systems, enabling timely actuations, and lowering the time to 1101 innovation by simplifying interaction across devices from many 1102 manufacturers. Challenges in healthcare include real-time 1103 interactions, high reliability, short communication latencies, 1104 trustworthy, security and privacy, and well as defining and meeting 1105 the regulatory requirements that should impact new devices and their 1106 interconnection. In addition to this dimension, assistive robotics 1107 applications are gaining momentum to provide 24/24 7/7 assistance to 1108 patients [49]. 1110 Healthcare [21][22] faces the following challenges that are hard to 1111 address with IP-based overlay solutions: (1) real-time and 1112 reliability: healthcare systems must be able to operate on real-time 1113 and remain resilient in the presence of failures; (2) inter- 1114 operability: healthcare systems must operate with heterogeneous 1115 devices and protocols; (3) security: healthcare systems must be 1116 resilient to malicious physical and cyber attacks and meet the 1117 regulatory requirement for data security and interoperability; (4) 1118 privacy: user trust in healthcare systems is critical, and privacy 1119 considerations paramount to garner adoption and continued user; (5) 1120 user interface / user experience: the highly heterogeneous nature of 1121 real-world healthcare systems, which will continue to increase 1122 through the introduction of IoT devices, presents significant 1123 challenges in interface design that may have architectural 1124 implications. 1126 5.6. Education 1128 IoT technologies enable the instrumentation of a variety of 1129 environments (from greenhouses to industrial plants, homes and 1130 vehicles) to support not only their everyday operation but an 1131 understanding of how they operate -- a fundamental contribution to 1132 education. The diverse uses of hobbyist-oriented micro-controller 1133 platforms (e.g., the Arduino) and embedded systems (e.g., the 1134 Raspberry PI) point to a burgeoning community that should be 1135 supported by the next generation IoT platform because of its 1136 fundamental importance to formal and informal education. 1138 Educational uses of IoT deployments include both learning about the 1139 operation of the system itself as well as the systems being observed 1140 and controlled. Such deployments face the following challenges that 1141 are hard to address with IP-based overlay solutions: (1) relatively 1142 simple communications patterns are obscured by many layers of 1143 translation from the host-based addressing of IP (and layer 2 1144 configuration below) to the name-oriented interfaces provided by 1145 developers; (2) security considerations with overlay deployments and 1146 channel-based limit access to systems where read-only use of data is 1147 not a security risk; (3) real-time communication helps make the 1148 relationship between physical phenomena and network messages easier 1149 to understand in many simple cases; (4) integration of devices from a 1150 variety of sources and manufacturers is currently quite difficult 1151 because of varying standards for basic communication, and limits 1152 experimentation; (5) programming interfaces must be carefully 1153 developed to expose important concepts clearly and in light of 1154 current best practices in education. 1156 5.7. Entertainment, arts, and culture 1158 IoT technologies can contribute uniquely to both the worldwide 1159 entertainment market and the fundamental human activity of creating 1160 and sharing art and culture. By supporting new types of human- 1161 computer interaction, IoT can enable new gaming, film/video, and 1162 other "content" experiences, integrating them with, for example, the 1163 lighting control of the smart home, presentation systems of the smart 1164 enterprise, or even the incentive mechanisms of smart healthcare 1165 systems (to, say, encourage and measure physical activity). 1167 Entertainment, arts, and culture applications generate a variety of 1168 challenges for IoT: (1) notably, the ability to securely "repurpose" 1169 deployed smart systems (e.g., lighting) to create experiences; (2) 1170 low-latency communication to enable end-user responsiveness; (3) 1171 integration with infrastructure-based sensing (e.g., computer vision) 1172 to create comprehensive interactive environments or to provide user 1173 identity information; (4) time synchronization with audio/video 1174 playback and rendering in 3D systems (5) simplicity of development 1175 and experimentation, to enable the cost- and time-efficient 1176 integration of IoT into experiences being designed without expert 1177 engineers of IoT systems; (6) security, because of integration with 1178 personal devices and smart environments, as well as billing systems. 1180 6. Informative References 1182 [1] Cisco System Inc., CISCO., "Cisco visual networking index: 1183 Global mobile data traffic forecast update.", 2009-2014. 1185 [2] Shafig, M., Ji, L., Liu, A., Pang, J., and J. Wang, "A 1186 first look at cellular machine-to-machine traffic: large 1187 scale measurement and characterization.", Proceedings of 1188 the ACM Sigmetrics , 2012. 1190 [3] The European Telecommunications Standards Institute, 1191 ETSI., "http://www.etsi.org/.", 1988. 1193 [4] Global Intiative for M2M Standardization, oneM2M., 1194 "http://www.onem2m.org/.", 2012. 1196 [5] Constrained RESTful Environments, CoRE., 1197 "https://datatracker.ietf.org/wg/core/charter/.", 2013. 1199 [6] Ghodsi, A., Shenker, S., Koponen, T., Singla, A., 1200 Raghavan, B., and J. Wilcox, "Information-Centric 1201 Networking: Seeing the Forest of the Trees.", Hot Topics 1202 in Networking , 2011. 1204 [7] Dong, L., Zhang, Y., and D. Raychaudhuri, "Enhance Content 1205 Broadcast Efficiency in Routers with Integrated Caching.", 1206 Proceedings of the IEEE Symposium on Computers and 1207 Communications (ISCC) , 2011. 1209 [8] NSF FIA project, MobilityFirst., 1210 "http://www.nets-fia.net/", 2010. 1212 [9] Kim, B., Lee, S., Lee, Y., Hwang, I., and Y. Rhee, 1213 "Mobiiscape: Middleware Support for Scalable Mobility 1214 Pattern Monitoring of Moving Objects in a Large-Scale 1215 City.", Journal of Systems and Software, Elsevier, 2011. 1217 [10] Dietrich, D., Bruckne, D., Zucker, G., and P. Palensky, 1218 "Communication and Computation in Buildings: A Short 1219 Introduction and Overview", IEEE Transactions on 1220 Industrial Electronics, 2010. 1222 [11] Keith, K., Falco, F., and K. Scarfone, "Guide to 1223 Industrial Control Systems (ICS) Security", NIST, 1224 Technical Report 800-82 Revision 1, 2013. 1226 [12] Darianian, M. and Martin. Michael, "Smart home mobile 1227 RFID-based Internet-of-Things systems and services.", 1228 IEEE, ICACTE, 2008. 1230 [13] Zhu, Q., Wang, R., Chen, Q., Chen, Y., and W. Qin, "IOT 1231 Gateway: Bridging Wireless Sensor Networks into Internet 1232 of Things", IEEE/IFIP, EUC, 2010. 1234 [14] Biswas, T., Chakrabort, A., Ravindran, R., Zhang, X., and 1235 G. Wang, "Contextualized information-centric home 1236 network", ACM, Siggcomm, 2013. 1238 [15] Huang, R., Zhang, J., Hu, Y., and J. Yang, "Smart Campus: 1239 The Developing Trends of Digital Campus", 2012. 1241 [16] Yan, Y., Qian, Y., Hu, Y., and J. Yang, "A Survey on Smart 1242 Grid Communication Infrastructures: Motivations, 1243 Requirements and Challenges", IEEE Communications Survey 1244 and Tutorials, 2013. 1246 [17] Miao, Y. and Y. Bu, "Research on the Architecture and Key 1247 Technology of Internet of Things (loT) Applied on Smart 1248 Grid", IEEE, ICAEE, 2010. 1250 [18] Zhang, Y., Yu, R., Nekovee, M., Liu, Y., Xie, S., and S. 1251 Gjessing, "Cognitive Machine-to-Machine Communications: 1252 Visions and Potentials for the Smart Grid", IEEE, Network, 1253 2012. 1255 [19] Zhou, H., Liu, B., and D. Wang, "Design and Research of 1256 Urban Intelligent Transportation System Based on the 1257 Internet of Things", Springer Link, 2012. 1259 [20] Zhang, M., Yu, T., and G. Zhai, "Smart Transport System 1260 Based on the Internet of Things", Applied Mechanics and 1261 Materials, 2012. 1263 [21] Zhang, A., Yu, R., Nekovee, M., and S. Xie, "The Internet 1264 of Things for Ambient Assisted Living", IEEE, ITNG, 2010. 1266 [22] Savola, R., Abie, H., and M. Sihvonen, "Towards metrics- 1267 driven adaptive security management in E-health IoT 1268 applications.", ACM, BodyNets, 2012. 1270 [23] Jacobson, V., Smetters, D., Plass, M., Stewart, P., 1271 Thornton, J., and R. Braynard, "VoCCN: Voice-over Content- 1272 Centric Networks", ACM, ReArch, 2009. 1274 [24] Piro, G., Cianci, I., Grieco, L., Boggia, G., and P. 1275 Camarda, "Information Centric Services in Smart Cities", 1276 ACM, Journal of Systems and Software, 2014. 1278 [25] Ravindran, R., Biswas, T., Zhang, X., Chakrabort, A., and 1279 G. Wang, "Information-centric Networking based Homenet", 1280 IEEE/IFIP, 2013. 1282 [26] Dannewitz, C., D' Ambrosio, M., and V. Vercellone, 1283 "Hierarchical DHT-based name resolution for information- 1284 centric networks", 2013. 1286 [27] Chai, W., He, D., and I. Psaras, "Cache "less for more" in 1287 information-centric networks", ACM, IFIP, 2012. 1289 [28] Eum, S., Nakauchi, K., Murata, M., Shoji, Yozo., and N. 1290 Nishinaga, "Catt: potential based routing with content 1291 caching for icn", IEEE Communication Magazine, 2012. 1293 [29] Eum, S., Shvartzshnaider, Y., Francisco, J., Martini, R., 1294 and D. Raychaudhuri, "Enabling internet-of-things services 1295 in the mobilityfirst future internet architecture", IEEE, 1296 WoWMoM, 2012. 1298 [30] Sun, Y., Qiao, X., Cheng, B., and J. Chen, "A low-delay, 1299 lightweight publish/subscribe architecture for delay- 1300 sensitive IOT services", IEEE, ICWS, 2013. 1302 [31] Baccelli, E., Mehlis, C., Hahm, O., Schmidt, T., and M. 1303 Wahlisch, "Information Centric Networking in the 1304 IoT:Experiments with NDN in the Wild", ACM, ICN Siggcomm, 1305 2014. 1307 [32] Gronbaek, I., "Architecture for the Internet of Things 1308 (IoT): API and interconnect", IEEE, SENSORCOMM, 2008. 1310 [33] Tian, Y., Liu, Y., Yan, Z., Wu, S., and H. Li, "RNS-A 1311 Public Resource Name Service Platform for the Internet of 1312 Things", IEEE, GreenCom, 2012. 1314 [34] Roussos, G. and P. Chartier, "Scalable id/locator 1315 resolution for the iot", IEEE, iThings,CPSCom, 2011. 1317 [35] Amadeo, M. and C. Campolo, "Potential of information- 1318 centric wireless sensor and actor networking", IEEE, 1319 ComManTel, 2013. 1321 [36] Nelson, S., Bhanage, G., and D. Raychaudhuri, "GSTAR: 1322 generalized storage-aware routing for mobilityfirst in the 1323 future mobile internet", ACM, MobiArch, 2011. 1325 [37] Trappe, W., Zhang, Y., and B. Nath, "MIAMI: methods and 1326 infrastructure for the assurance of measurement 1327 information", ACM, DMSN, 2005. 1329 [38] Rouf, I., Mustafa, H., Taylor, T., Oh, S., Xu, W., 1330 Gruteser, M., Trappe, W., and I. Seskar, "Security and 1331 privacy vulnerabilities of in-car wireless networks: A 1332 tire pressure monitoring system case study", USENIX, 2010. 1334 [39] Liu, R. and W. Trappe, "Securing Wireless Communications 1335 at the Physical Layer", Springer, 2010. 1337 [40] Xiao, L., Greenstein, L., Mandayam, N., and W. Trappe, 1338 "Using the physical layer for wireless authentication in 1339 time-variant channels", IEEE Transactions on Wireless 1340 Communications, 2008. 1342 [41] Sun, S., Lannom, L., and B. Boesch, "Handle system 1343 overview", IETF, RFC3650, 2003. 1345 [42] Liu, X., Trappe, W., and Y. Zhang, "Secure Name Resolution 1346 for Identifier-to-Locator Mappings in the Global 1347 Internet", IEEE, ICCCN, 2013. 1349 [43] Boguna, M., Fragkiskos, P., and K. Dmitri, "Sustaining the 1350 internet with hyperbolic mapping", Nature Communications, 1351 2010. 1353 [44] Shang, W., "Securing building management systems using 1354 named data networking", IEEE Network 2014. 1356 [45] Fayazbakhsh, S. and et. et al, "Less pain, most of the 1357 gain: Incrementally deployable icn", ACM, Siggcomm, 2013. 1359 [46] Burke, J. and et. et al, "Securing instrumented 1360 environments over Content-Centric Networking: the case of 1361 lighting control", INFOCOM, Computer Communications 1362 Workshop, 2013. 1364 [47] Li, S., Zhang, Y., Dipankar, R., and R. Ravindran, "A 1365 comparative study of MobilityFirst and NDN based ICN-IoT 1366 architectures", IEEE, QShine, 2014. 1368 [48] Grieco, L., Alaya, M., and K. Drira, "Architecting 1369 Information Centric ETSI-M2M systems", IEEE, Pervasive and 1370 Computer Communications Workshop (PERCOM), 2014. 1372 [49] Grieco, L., Rizzo, A., Colucci, R., Sicari, S., Piro, G., 1373 Di Paola, D., and G. Boggia, "IoT-aided robotics 1374 applications: technological implications, target domains 1375 and open issues", Computer Communications, Volume 54, 1 1376 December, 2014. 1378 [50] Quan, Wei., Xu, C., Guan, J., Zhang, H., and L. Grieco, 1379 "Scalable Name Lookup with Adaptive Prefix Bloom Filter 1380 for Named Data Networking", IEEE Communications Letters, 1381 2014. 1383 [51] Wang, Yi., Pan, T., Mi, Z., Dai, H., Guo, X., Zhang, T., 1384 Liu, B., and Q. Dong, "NameFilter: Achieving fast name 1385 lookup with low memory cost via applying two-stage Bloom 1386 filters", INFOCOM, 2013. 1388 [52] So, W., Narayanan, A., Oran, D., and Y. Wang, "Toward fast 1389 NDN software forwarding lookup engine based on Hash 1390 tables", ACM, ANCS, 2012. 1392 [53] Amadeo, M., Campolo, C., Iera, A., and A. Molinaro, "Named 1393 data networking for IoT: An architectural perspective", 1394 IEEE, EuCNC, 2014. 1396 [54] Sifalakis, M., Kohler, B., Christopher, C., and C. 1397 Tschudin, "An information centric network for computing 1398 the distribution of computations", ACM, ICN Sigcomm, 2014. 1400 [55] Lu, R., Lin, X., Zhu, H., and X. Shen, "SPARK: a new 1401 VANET-based smart parking scheme for large parking lots", 1402 INFOCOM, 2009. 1404 [56] Wang, H. and W. He, "A reservation-based smart parking 1405 system", The First International Workshop on Cyber- 1406 Physical Networking Systems, 2011. 1408 [57] Qian, L., "Constructing Smart Campus Based on the Cloud 1409 Computing and the Internet of Things", Computer Science 1410 2011. 1412 [58] Project, BonVoyage., "From Bilbao to Oslo, intermodal 1413 mobility solutions, interfaces and applications for people 1414 and goods, supported by an innovative communication 1415 network", Call H2020-MG-2014, 2015-2018. 1417 Authors' Addresses 1419 Prof.Yanyong Zhang 1420 WINLAB, Rutgers University 1421 671, U.S 1 1422 North Brunswick, NJ 08902 1423 USA 1425 Email: yyzhang@winlab.rutgers.edu 1426 Prof. Dipankar Raychadhuri 1427 WINLAB, Rutgers University 1428 671, U.S 1 1429 North Brunswick, NJ 08902 1430 USA 1432 Email: ray@winlab.rutgers.edu 1434 Prof. Luigi Alfredo Grieco 1435 Politecnico di Bari (DEI) 1436 Via Orabona 4 1437 Bari 70125 1438 Italy 1440 Email: alfredo.grieco@poliba.it 1442 Prof. Emmanuel Baccelli 1443 INRIA 1444 Room 148, Takustrasse 9 1445 Berlin 14195 1446 France 1448 Email: Emmanuel.Baccelli@inria.fr 1450 Jeff Burke 1451 UCLA REMAP 1452 102 East Melnitz Hall 1453 Los Angeles, CA 90095 1454 USA 1456 Email: jburke@ucla.edu 1458 Ravishankar Ravindran 1459 Huawei Technologies 1460 2330 Central Expressway 1461 Santa Clara, CA 95050 1462 USA 1464 Email: ravi.ravindran@huawei.com 1465 Guoqiang Wang 1466 Huawei Technologies 1467 2330 Central Expressway 1468 Santa Clara, CA 95050 1469 USA 1471 Email: gq.wang@huawei.com