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