idnits 2.17.1 draft-zhang-iot-icn-challenges-00.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 (September 22, 2014) is 3504 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Missing reference section? '1' on line 969 looks like a reference -- Missing reference section? '2' on line 972 looks like a reference -- Missing reference section? '12' on line 1013 looks like a reference -- Missing reference section? '9' on line 1002 looks like a reference -- Missing reference section? '3' on line 977 looks like a reference -- Missing reference section? '4' on line 980 looks like a reference -- Missing reference section? '5' on line 983 looks like a reference -- Missing reference section? 'IoTGW' on line 439 looks like a reference -- Missing reference section? '11' on line 1009 looks like a reference -- Missing reference section? '13' on line 1017 looks like a reference -- Missing reference section? '14' on line 1021 looks like a reference -- Missing reference section? '15' on line 1025 looks like a reference -- Missing reference section? '16' on line 1029 looks like a reference -- Missing reference section? '18' on line 1036 looks like a reference -- Missing reference section? '19' on line 1040 looks like a reference -- Missing reference section? '20' on line 1044 looks like a reference -- Missing reference section? '21' on line 1048 looks like a reference -- Missing reference section? '22' on line 1051 looks like a reference -- Missing reference section? '23' on line 1054 looks like a reference -- Missing reference section? '32' on line 1089 looks like a reference -- Missing reference section? '27' on line 1070 looks like a reference -- Missing reference section? '7' on line 991 looks like a reference -- Missing reference section? '24' on line 1058 looks like a reference -- Missing reference section? '25' on line 1062 looks like a reference -- Missing reference section? '28' on line 1074 looks like a reference -- Missing reference section? '29' on line 1077 looks like a reference -- Missing reference section? '30' on line 1081 looks like a reference -- Missing reference section? '31' on line 1085 looks like a reference -- Missing reference section? '1-4' on line 800 looks like a reference -- Missing reference section? '33' on line 1093 looks like a reference -- Missing reference section? '34' on line 1096 looks like a reference -- Missing reference section? '35' on line 1100 looks like a reference -- Missing reference section? '36' on line 1103 looks like a reference -- Missing reference section? '37' on line 1107 looks like a reference -- Missing reference section? '38' on line 1111 looks like a reference -- Missing reference section? '39' on line 1114 looks like a reference -- Missing reference section? '40' on line 1118 looks like a reference -- Missing reference section? '41' on line 1122 looks like a reference -- Missing reference section? '42' on line 1127 looks like a reference -- Missing reference section? '45' on line 1137 looks like a reference -- Missing reference section? '44' on line 1134 looks like a reference -- Missing reference section? '6' on line 986 looks like a reference -- Missing reference section? '8' on line 997 looks like a reference -- Missing reference section? '10' on line 1004 looks like a reference -- Missing reference section? '17' on line 1032 looks like a reference -- Missing reference section? '26' on line 1066 looks like a reference -- Missing reference section? '43' on line 1130 looks like a reference Summary: 3 errors (**), 0 flaws (~~), 1 warning (==), 48 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: March 26, 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 September 22, 2014 16 ICN based Architecture for IoT - Requirements and Challenges 17 draft-zhang-iot-icn-challenges-00 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 IoT platform as an overlay on top 28 of today's Internet. Such overlay solutions, however, are inadequate 29 to address the important challenges posed by a heterogeneous, global 30 scale deployment of IoT, especially in terms of mobility, 31 scalability, and communication reliability, due to the inherent 32 inefficiencies of the current Internet. To address this problem, we 33 propose to build a common set of protocols and services, which form 34 an IoT platform, based on the Information Centric Network (ICN) 35 architecture, which we call ICN-IoT. ICN-IoT leverages the salient 36 features of ICN, and thus provides seamless mobility support, 37 scalability, and efficient content and service delivery. 39 This draft sets the IoT requirements and ICN challenges to realize a 40 unified ICN-IoT framework. Towards this, we first identify a list of 41 important requirements which a unified IoT architecture should have 42 to support tens of billions of objects. Then we analyze the current 43 state of art deployment model and discuss important and popular IoT 44 scenarios including the "smart" home, campus, grid, transportation 45 infrastructure, healthcare, Education, and Entertainment. Though we 46 see most of these requirements are met by ICN, we discuss specific 47 challenges ICN has to address to satisfy them considering 48 heterogeneity in IoT environments and scenarios. 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 March 26, 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 . . . . . . . . . . . . . . . . 5 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 . . . . . . . . . . . . . . . . . . . . . 13 108 4.5. Healthcare . . . . . . . . . . . . . . . . . . . . . . . 14 109 4.6. Education . . . . . . . . . . . . . . . . . . . . . . . . 15 110 4.7. Entertainment, arts, and culture . . . . . . . . . . . . 15 111 5. ICN Challenges for IoT . . . . . . . . . . . . . . . . . . . 16 112 5.1. Naming . . . . . . . . . . . . . . . . . . . . . . . . . 16 113 5.2. Caching/Storage . . . . . . . . . . . . . . . . . . . . . 17 114 5.3. Name Resolution . . . . . . . . . . . . . . . . . . . . . 17 115 5.4. Contextual Communication . . . . . . . . . . . . . . . . 18 116 5.5. Routing and Forwarding . . . . . . . . . . . . . . . . . 18 117 5.6. In-network Computing . . . . . . . . . . . . . . . . . . 19 118 5.7. Security and Privacy . . . . . . . . . . . . . . . . . . 20 119 5.8. Energy Efficiency . . . . . . . . . . . . . . . . . . . . 21 120 6. Informative References . . . . . . . . . . . . . . . . . . . 21 121 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 25 123 1. IoT Motivation 125 During the past decade, many standalone Internet of Things (IoT) 126 systems have been developed and deployed in different domains. The 127 recent trend, however, is to evolve towards a globally unified IoT 128 platform, in which billions of objects connect to the Internet, 129 available for interactions among themselves, as well as interactions 130 with many different applications across boundaries of administration 131 and domains. Building a unified IoT platform, however, poses great 132 challenges on the underlying network and systems. To name a few, it 133 needs to support 50-100 Billion networked objects [1], many of which 134 are mobile. The objects will have extremely heterogeneous means of 135 connecting to the Internet, often with severe resource constraints. 136 Interactions between the applications and objects are often real-time 137 and dynamic, requiring strong security and privacy protections. In 138 addition, IoT applications are inherently information centric (e.g., 139 data consumers usually need data sensed from the environment without 140 any reference to the sub-set of motes that will provide the asked 141 information). Taking a general IoT perspective, we begin by 142 presenting IoT architectural requirements, then summarize how state- 143 of-art approaches address these requirements. We then discuss well 144 known IoT scenarios focusing on their unique challenges. The final 145 discussion focuses on IoT challenges from an ICN perspective and 146 requirements posed towards its design. 148 2. IoT Architectural Requirements 150 A unified IoT platform has to support interactions among a large 151 number of mobile devices across the boundaries of organizations and 152 domains. As a result, it naturally poses stringent requirements in 153 every aspect of the system design. Below, we outline a few important 154 requirements that a unified IoT platform has to address. 156 2.1. Naming 158 The first step towards realizing a unified IoT platform is the 159 ability to assign names that are unique within the scope and lifetime 160 of each device, data items generated by these devices, or a group of 161 devices towards a common objective. Naming has the following 162 requirements. First, names need to be persistent (within one or more 163 contexts) against dynamic features that are common in IoT systems, 164 such as mobility or migration; Second, names need to be secure based 165 on application requirements. 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 insert/update/look up a name within a short latency. To satisfy this 178 requirement, decentralization of the name resolution can be the 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, and 186 bandwidth. 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 commuters can find out real-time traffic and road information and 226 then decide which commuting route to take. Wide area communications 227 require efficient data/service discovery and resolution services. 229 While traffic characteristics for different IoT systems are expected 230 to be different, certain IoT systems have been analyzed and shown to 231 have comparable uplink and downlink traffic volume in some 232 applications such as [2], which means that we have to optimize the 233 bandwidth/energy consumption in both directions. Further, IoT 234 traffic demonstrates certain periodicity and burstiness [2]. As a 235 result, when provisioning the system, the shape of the traffic volume 236 has to be properly accounted for. 238 2.5. Contextual Communication 240 Many IoT applications shall rely on contextual information such as 241 social, grouping, location, type of ecosystem (home, grid, transport 242 etc.) of devices and data (which are referred to as contexts in this 243 document) to initiate dynamic relationship and communication. For 244 example, cars traveling on the highway may form a "cluster" based 245 upon their temporal physical proximity as well as the detection of 246 the same event. These temporary groups are referred to as contexts. 247 IoT applications need to support interactions among the members of a 248 context, as well as interactions across contexts. 250 Temporal context can be broadly categorized into two classes, long- 251 term contexts such as those that are based upon social contacts as 252 well as stationary physical locations (e.g., sensors in a car/ 253 building), and short-term contexts such as those that are based upon 254 temporary proximity (e.g., all taxicabs within half a mile of the 255 Time Square at noon on Oct 1, 2013). Between these two classes, 256 short-term contexts are more challenging to support, requiring fast 257 formation, update, lookup and association. 259 2.6. Handling Mobility 261 There are varying degrees of mobility in a unified IoT platform, 262 ranging from static as in fixed assets to highly dynamic in vehicle- 263 to-vehicle environments. 265 Mobility in the IoT platform can mean 1) the data producer mobility 266 (i.e., location change), 2) the data consumer mobility, 3) IoT 267 Network mobility; and 4) disconnection between the data source and 268 destination pair (e.g., due to unreliable wireless links). The 269 requirement on mobility support is to be able to deliver IoT data 270 below an application acceptable delay constraint in all of the above 271 cases. 273 2.7. Storage and Caching 275 Storage and caching plays a very significant role depending on the 276 type of IoT ecosystem with the fact that data generated is also 277 subjected to privacy and security guidelines. In a unified IoT 278 platform, depending on application requirements, content caching may 279 or may not be policy driven though the latter would be a more common 280 scenario. If caching is pervasive, intermediate nodes don't need to 281 always forward a content request to its original creator; rather, 282 locating and receiving a cached copy is sufficient for IoT 283 applications. This optimization can greatly reduce the content 284 access latencies. 286 Further, ICN architectures enable a more flexible, heterogeneous and 287 potentially fault-tolerant approach to storage, that provides 288 persistence at a variety of levels in a hierarchical network of 289 devices. 291 In network storage and caching, however, has the following 292 requirements on the IoT platform. The platform needs to support the 293 efficient resolution of cached copies. Further the platform should 294 strive for the balance between caching, content security/privacy, and 295 regulations. 297 2.8. Security and Privacy 299 In addition to the fundamental challenge of trust management, a 300 variety of security and privacy concerns also exist in ICNs. 302 The unified IoT platform makes physical objects accessible to 303 applications across organizations and domains. Further, it often 304 integrates with critical infrastructure and industrial systems with 305 life safety implications, bringing with it significant security 306 challenges and regulatory requirements [12]. 308 Security and privacy thus become a serious concern, as does the 309 flexibility and usability of the design approaches. Beyond the 310 overarching trust management challenge, security includes data 311 integrity, authentication, and access control at different layers of 312 the IoT platform. Privacy means that both the content and the 313 context around IoT data need to be protected. These requirements 314 will be driven by various stake holders such as industry, government, 315 consumers etc. 317 2.9. Communication Reliability 319 IoT applications can be broadly categorized into mission critical and 320 non-mission critical. For mission critical applications, reliable 321 communication is one of the most important features as these 322 applications have strong QoS requirements. Reliable communication 323 requires the following capabilities for the underlying system: (1) 324 seamless mobility support in the face of extreme disruptions (DTN), 325 (2) efficient routing in the presence of intermittent disconnection, 326 (3) QoS aware routing, (4) support for redundancy at all levels of a 327 system (device, service, network, etc.). 329 2.10. Self-Organization 331 The unified IoT platform should be able to self-organize to meet 332 various application requirements, especially the capability to 333 quickly discover heterogeneous and relevant devices/data/services 334 based on the context. This discovery can be achieved through an 335 efficient platform-wide publish-subscribe service, or through private 336 community grouping/clustering based upon trust and other security 337 requirements. In the former case, the publish-subscribe service must 338 be efficiently implemented, able to support seamless mobility, in- 339 network caching, name-based routing, etc. In the latter case, the 340 IoT platform needs to discover the private community groups/clusters 341 efficiently. 343 2.11. Ad hoc and Infrastructure Mode 345 Depending upon whether there is communication infrastructure, an IoT 346 system can operate either in ad-hoc or infrastructure mode. 348 For example, a vehicle may determine to report its location and 349 status information to a server periodically through cellular 350 connection, or, a group of vehicles may form an ad-hoc network that 351 collectively detect road conditions around them. In the cases where 352 infrastructure is unavailable, one of the participating nodes may 353 choose to become the temporary gateway. 355 The unified IoT platform needs to design a common protocol that 356 serves both modes. Such a protocol should be able to provide: (1) 357 energy-efficient topology discovery and data forwarding in the ad-hoc 358 mode, and (2) scalable name resolution in the infrastructure mode. 360 2.12. Open API 362 General IoT applications involve sensing, processing, and secure 363 content distribution occuring at various timescales depending on the 364 application requirements. This requires open APIs to be generic 365 enough to support Pull, Push, and support Pub/Sub mode of interaction 366 between consumers, content producer, and IoT services, as opposed to 367 proprietary APIs that are common in today's systems. 369 3. State of the Art 371 Over the years, many stand-alone IoT systems have been deployed in 372 various domains. These systems usually adopt a vertical silo 373 architecture and support a small set of pre-designated applications. 374 A recent trend, however, is to move away from this approach, towards 375 a unified IoT platform in which the existing silo IoT systems, as 376 well as new systems that are rapidly deployed, will make their data 377 and services accessible to general Internet applications (as in ETSI- 378 M2M and oneM2M standards). In such a unified platform, resources can 379 be accessed over Internet and shared across the physical boundaries 380 of the enterprise. However, current approaches to achieve this 381 objective are based upon Internet overlays, whose inherent 382 inefficiencies due to IP protocol [9] hinders the platform from 383 satisfying the IoT requirements outlined earlier (particularly in 384 terms of scalability, security, mobility, and self-organization) 386 3.1. Silo IoT Architecture 388 [IoT Server] 389 | 390 | 391 ______|_______ 392 _______ { } 393 { } { } 394 {IoT Dev}\ { Internet }---[IoT Application] 395 {_______} [IoTGW]---{ } 396 { } 397 {______________} 399 Figure 1:Silo architecture of standalone IoT systems 401 A typical standalone IoT system is illustrated in Figure 1, which 402 includes devices, a gateway, a server and applications. Many IoT 403 devices have limited power and computing resources, unable to 404 directly run normal IP access network (Ethernet, WIFI, 3G/LTE etc.) 405 protocols. Therefore they use the IoT gateway to the server. 406 Through the IoT server, applications can subscribe to data collected 407 by devices, or interact with devices. 409 There have been quite a few popular protocols for standalone IoT 410 systems, such as DF-1, MelsecNet, Honeywell SDS, BACnet, etc. 411 However, these protocols are operating at the device-level 412 abstraction, instead of information driven, leading to a highly 413 fragmented protocol space with limited interoperability. 415 3.2. Overlay Based Unified IoT Solutions 417 The current approach to a unified IoT platform is to make IoT 418 gateways and servers adopt standard APIs. IoT devices connect to the 419 Internet through the standard APIs and IoT applications subscribe and 420 receive data through standard control and data APIs. Building on top 421 of today's Internet as an overlay, this is the most practical 422 approach towards a unified IoT platform. There are ongoing 423 standardization efforts including ETSI[3], oneM2M[4],and CORE[5]. 424 Network operators can use standard API to build common IOT gateways 425 and servers for their customers. Figure 2 shows the architecture 426 adopted in this approach. 428 Publishing----[IoT Server]----Subscribing-- 429 | / | \ | 430 | / | \ | 431 | /______|_______ \ | 432 ___________ | /{ } publishing | 433 { } | | { } | | 434 {Smart Homes}\ | | { Internet }---------[IoT Application] 435 {___________} [IoTGW]---{ }\ | ________________ 436 | { } \ | { } 437 | {______________} [IoTGW]-{Smart Healthcare} 438 | | {________________} 439 Publishing [IoTGW] 440 | ____|_____ 441 | { } 442 ---{Smart Grid} 443 {__________} 445 Figure 2: Implementing an open IoT platform through standarized APIs 446 on the IoT gateways and the server 448 3.2.1. Weaknesses of the Overlay-based Approach 450 The above overlay-based approach can work with many different 451 protocols, but the system is not designed in a holistic manner to 452 inter-connect heterogeneous devices, services and infrastructure. 453 Another limiting factor is that it is built upon today's IP network, 454 which has inherent weaknesses towards supporting a unified IoT 455 system. As a result, it cannot satisfy some of the requirements we 456 outlined in Section 2: 458 o Naming. In current overlays for IoT systems the naming scheme is 459 host centric, i.e., the name of a given resource/service is linked 460 to the one of device that can provide it. In turn, device names 461 are coupled to IP addresses, which are not persistent in mobile 462 scenarios. On the other side, in IoT systems the same service/ 463 resource could be provided by many different devices thus 464 requiring a different design rationale. 466 o Trust. Trust management schemes are still relatively weak, 467 focusing on securing communication channels rather than managing 468 the data that needs to be secured directly. 470 o Scalability. The overlay-based approach uses IP addresses as 471 names at the network layer, which hinders the support for device/ 472 service mobility or flexible name resolution. Further the Layer 473 2/3 management, and application-layer addressing and forwarding 474 required to deploy current IoT solutions limit the scalability and 475 management of these systems. 477 o Resource constraints. The overlay-based approach requires every 478 device to send data to an aggregator or to the IoT server. 479 Resource constraints of the IoT devices, especially in power and 480 bandwidth, will seriously limit the performance of this approach. 482 o Traffic Characteristics. In this approach, applications are 483 written in a host-centric manner suitable for point-to-point 484 communication. IoT requires support for multicasting that is 485 challenging the underlying for overlay systems today. 487 o Contextual Communications. This overlay-based approach cannot 488 react to dynamic contextual changes in a timely fashion. The main 489 reason is that context lists are kept at the IoT server in this 490 approach, and they cannot help efficiently route requests/ 491 information at the network layer. 493 o Mobility. The overlay-based approach cannot seamlessly support 494 device mobility in terms of maintaining the session between data 495 producers and consumers. In this approach, lower-level 496 communications are typically IP driven, which is inefficient for 497 mobility support. 499 o Storage and Caching. The overlay-based approach supports 500 application-centric storage and caching but not what ICN envisions 501 at the network layer, or flexible storage enabled via name-based 502 routing. 504 o Self-Organization. The overlay-based approach is topology-based 505 as it is bound to IP semantics, and thus does not sufficiently 506 satisfy the self-organization requirement. 508 o Ad-hoc and infrastructure mode. As mentioned above, the overlay- 509 based approach lacks self-organization, and thus does not provide 510 efficient support for the ad-hoc mode. 512 4. Popular Scenarios 514 Several types of IoT applications exists, where the goal is efficient 515 and secure management and communication among objects in the system 516 and with the physical world through sensors, RFIDs and other devices. 517 Below we list a few popular IoT applications. We omit the often used 518 term "smart", though it applies to each IoT scenario below, and posit 519 that IoT-style interconnection of devices to make these environments 520 "smart" in today's terms will simply be the future norm. 522 4.1. Homes 524 The home [11] is a complex ecosystem of IoT devices and applications 525 including climate control, home security monitoring, smoke detection, 526 electrical metering, health/wellness, and entertainment systems. In 527 a unified IoT platform, we would inter-connect these systems through 528 the Internet, such that they can interact with each other and make 529 decisions at an aggregated level. Also, the systems can be accessed 530 and manipulated remotely. Challenges in the home include topology 531 independent service discovery, common protocol for heterogeneous 532 device/application/service interaction, policy based routing/ 533 forwarding, service mobility as well as privacy protection. Notably, 534 the ease-of-use expectations and training of both users and 535 installers also presents challenges in user interface and user 536 experience design that are impacted by the complexity of network 537 configuration, brittleness to change, configuration of trust 538 management, etc. Finally, it is unlikely that there will be a single 539 "home system", but rather a collection of moderately inter-operable 540 collaborating devices. 542 Homes [13][14] faces the following challenges that are hard to 543 address with IP-based overlay solutions: (1) context-aware control: 544 home systems must make decisions (e.g., on how to control, when to 545 collect data, where to carry out computation, when to interact with 546 end-users, etc.) based upon the contextual information [15]; (2) 547 inter-operatibility: home systems must operate with devices that 548 adopt heterogeneous naming, trust, communication, and control 549 systems; (3) mobility: home systems must deal with mobility caused by 550 the movement of sensors or data receivers; (4) security: a home 551 systems must be able to deal with foreign devices, handle a variety 552 of user permissions (occupants of various types, guests, device 553 manufacturers, installers and integrators, utility and infrastructure 554 providers) and involve users in important security decisions without 555 overwhelming them. 557 4.2. Enterprise 559 Enterprise building deployments, from university campuses [16] to 560 industrial facilities and retail complexes, drive an additional set 561 of scalability, security, and integration requirements beyond the 562 home, while requiring much of its ease of use and flexibility. 563 Additionally, they bring requirements for integration with business 564 IT systems, though often with the additional support of in-house 565 engineering support. 567 Increasing number of enterprises are equipped with sensing and 568 communication devices inside buildings, laboratories, and plants, at 569 stadiums, in parking lots, on school buses, etc. A unified IoT 570 platform must integrate many aspects of human interaction, H2M and 571 M2M communication, within the enterprise, and thus enable many IoT 572 applications that can benefit a large body of enterprise affiliates. 573 The challenges in smart enterprise include efficient and secure 574 device/data/resource discovery, inter-operability between different 575 control systems, throughput scaling with number of devices, and 576 unreliable communication due to mobility and telepresence. 578 Enterprises face the following challenges that are hard to address 579 with IP-based overlay solutions: (1) efficient device/data/ resource 580 discovery: enterprise devices must be able to quickly and securely 581 discover requested device, data, or resources; (2) scalability: a 582 enterprise system must be able to scale efficiently with the number 583 and type of sensors and devices across not only a single building but 584 multi-national corporations (for example); (3) mobility: a enterprise 585 system must be able to deal with mobility caused by movement of 586 devices. 588 4.3. Smart Grid 590 Central to the so-called "smart grid"[17] is data flow and 591 information management, achieved by using sensors and actuators, 592 which enables important capabilities such as substation and 593 distribution automation. In a unified IoT platform, data collected 594 from different smart grids can be integrated to reach more 595 significant optimizations. The challenges for smart grid include 596 reliability, real-time control, secure communications, and data 597 privacy. 599 Deployment of the smart grid [18] [19] faces the following issues 600 that are hard to address with IP-based overlay solutions: (1) 601 scalability: tomorrow's electrical grids must be able to scale 602 gracefully to manage a large number of heterogeneous devices; (2) 603 real time: grids must be able to perform real-time data collection, 604 data processing and control; (3) reliability: grids must be resilient 605 to hardware/software/networking failures; (4) security: grids and 606 associated systems are often considered critical infrastructure -- 607 they must be able to defend against malicious attacks, detect 608 intrusion, and route around disruption. 610 4.4. Transportation 612 We are currently witnessing the increasing integration of sensors 613 into cars, other vehicles transportation systems [20]. Current 614 production cars already carry many sensors ranging from rain gauges 615 and accelerometers over wheel rotation/traction sensors, to cameras. 616 While intended for internal vehicle functions, these could also be 617 networked and leveraged for applications such as monitoring external 618 traffic/road conditions. Further, we can build vehicle-to- 619 infrastructure (V2I) and vehicle-to-vehicle (V2V) communications that 620 enable many more applications for safety, convenience, entertainment, 621 etc. The challenges for transportation include fast data/device/ 622 service discovery and association, efficient communications with 623 mobility, trustworthy data collection and exchange. 625 Transportation [20][21] faces the following challenges that are hard 626 to address with IP-based overlay solutions: (1) mobility: a 627 transportation system must deal with a large number of mobile nodes 628 interacting through a combination of infrastructure and ad hoc 629 communication methods; (2) real-time and reliability: transportation 630 systems must be able to operate on real-time and remain resilient in 631 the presence of failures; (3) in-network computing/filtering: 632 transportation systems will benefit from in-network computing/ 633 filtering as such operations can reduce the end-to-end latency; (4) 634 inter-operatibility: transportation systems must operate with 635 heterogeneous device and protocols; (5) security: transportation 636 systems must be resilient to malicious physical and cyber attacks. 638 4.5. Healthcare 640 As more embedded medical devices, or devices that can monitor human 641 health become increasingly deployed, healthcare is becoming a viable 642 alternative to traditional healthcare solutions [15][22]. Further, 643 consumer applications for managing and interacting with health data 644 are a burgeoning area of research and commercial applications. For 645 future health applications, a unified IoT platform is critical for 646 improved patient care and consumer health support by sharing data 647 across systems, enabling timely actuations, and lowering the time to 648 innovation by simplifying interaction across devices from many 649 manufacturers. Challenges in healthcare include real-time 650 interactions, high reliability, short communication latencies, 651 trustworthy, security and privacy, and well as defining and meeting 652 the regulatory requirements that should impact new devices and their 653 interconnection. 655 Healthcare [22][23] faces the following challenges that are hard to 656 address with IP-based overlay solutions: (1) real-time and 657 reliability: healthcare systems must be able to operate on real-time 658 and remain resilient in the presence of failures; (2) inter- 659 operatibility: healthcare systems must operate with heterogeneous 660 device and protocols; (3) security: healthcare systems must be 661 resilient to malicious physical and cyber attacks and meet the 662 regulatory requirement for data security and interoperability. 664 4.6. Education 666 IoT technologies enable the instrumentation of a variety of 667 environments (from greenhouses to industrial plants, homes and 668 vehicles) to support not only their everyday operation but an 669 understanding of how they operate -- a fundamental contribution to 670 education. The diverse uses of hobbyist-oriented microcontroller 671 platforms (e.g., the Arduino) and embedded systems (e.g., the 672 Raspberry PI) point to a burgeoning community that should be 673 supported by the next generation IoT platform because of its 674 fundamental importance to formal and informal education. 676 Educational uses of IoT deployments include both learning about the 677 operation of the system itself as well as the systems being observed 678 and controlled. Such deployments face the following challenges that 679 are hard to address with IP-based overlay solutions: (1) relatively 680 simple communications patterns are obscured by many layers of 681 translation from the host-based addressing of IP (and layer 2 682 configuration below) to the name-oriented interfaces provided by 683 developers; (2) security considerations with overlay deployments and 684 channel-based limit access to systems where read-only use of data is 685 not a security risk; (3) real-time communication helps make the 686 relationship between physical phenomena and network messages easier 687 to understand in many simple cases; (4) integration of devices from a 688 variety of sources and manufacturers is currently quite difficult 689 because of varying standards for basic communication, and limits 690 experimentation. 692 4.7. Entertainment, arts, and culture 694 IoT technologies can contribute uniquely to both the worldwide 695 entertainment market and the fundamental human activity of creating 696 and sharing art and culture. By supporting new types of human- 697 computer interaction, IoT can enable new gaming, film/video, and 698 other "content" experiences, integrating them with, for example, the 699 lighting control of the smart home, presentation systems of the smart 700 enterprise, or even the incentive mechanisms of smart healthcare 701 systems (to, say, encourage and measure physical activity). 703 Entertainment, arts, and culture applications generate a variety of 704 challenges for IoT: (1) notably, the ability to securely "repurpose" 705 deployed smart systems (e.g., lighting) to create experiences; (2) 706 low-latency communication to enable end-user responsiveness; (3) 707 integration with infrastructure-based sensing (e.g., computer vision) 708 to create comprehensive interactive environments or to provide user 709 identity information; (4) time synchronization with audio/video 710 playback and rendering in 3D systems (5) simplicity of development 711 and experimentation, to enable the cost- and time-efficient 712 integration of IoT into experiences being designed without expert 713 engineers of IoT systems; (6) security, because of integration with 714 personal devices and smart environments, as well as billing systems. 716 5. ICN Challenges for IoT 718 ICN integrates content/service/host abstraction, name-based routing, 719 compute, caching/storage as part of the network infrastructure 720 connecting consumers and services which meets most of the 721 requirements discussed above; however IoT requires special 722 considerations given heterogeneity of devices and interfaces such as 723 for constrained networking [32], data processing, and content 724 distribution models to meet specific application requirements which 725 we identify as challenges in this section. 727 5.1. Naming 729 According to [27], the main requirement of a name space (and the 730 corresponding Name Resolution System) are: 732 o Scalability: with the IoT the number of data items would inflate 733 the Internet scale up to 2-3 order of magnitudes, thus making 734 scalability a primary requirement of the NRS. Notice that, if 735 hierarchical names are used, scalability can be also faced by 736 leveraging the inherent aggregation capabilities of the hierarchy. 738 o Latency: for real-time or delay sensitive M2M application, the 739 name resolution should not affect the overall QoS. 741 o Locality and network efficiency: in the name resolution process 742 the data items closer to the data consumer should be accesses 743 first (subject to the application requirements) 745 o Agility: some data items could disappear while some other ones are 746 created so that the NRS should be able to effectively take care of 747 these dynamic conditions. 749 o Control/scoping: some information could be accessible only within 750 a given scope so that the NRS shold be able to not disclose all 751 nodel locators to everyone. 753 o Deployability and interoperability: graceful deployability and 754 interoperability with existing platforms is a must to ensure a 755 naming schema to gain success on the market [7]. 757 Further challenges arise for hierarchical naming schema: referring to 758 requirements on "constructable names" and "on-demand publishing" [24] 759 [25]. The former entails that each user is able to construct the 760 name of a desired data item through specific algorithms and that it 761 is possible to retrieve information also using partially specified 762 names. The latter refers the possibility to request a content that 763 has not yet been published in the past, thus triggering its creation. 765 5.2. Caching/Storage 767 In-network caching helps bring data closer to consumers, but its 768 usage differs in constrained and infrastructure part of the IoT 769 network. Caching in constrained networks is limited to small amounts 770 in the order of 10KB, while caching in infrastructure part of the 771 network can allow much larger chunks. 773 Caching in ICN-IoT faces several challenges: 775 o The main challenge is to determine which nodes on the routing path 776 should cache the data. According to [28], caching the data on a 777 subset of nodes can achieve a better gain than caching on every 778 en-route routers. In particular, the authors propose a "selective 779 caching" scheme to locate those routers with better hit 780 probabilities to cache data. According to [29], selecting a 781 random router to cache data is as good as caching the content 782 everywhere. 784 o Another challenge in ICN-IoT caching is what to cache for IoT 785 applications. In many IoT applications, customers often access a 786 stream of sensor data, and as a result, caching a particular 787 sensor data item may not be beneficial. In [30], the authors 788 suggest to cache IoT services on intermediate routers, and in 789 [31], the authors suggest to cache control information such as 790 pub/sub lists on intermediate nodes. In addition, it is yet 791 unclear what caching means in the context of actuation in an IoT 792 system. 794 5.3. Name Resolution 796 Inter-connecting numerous IoT entities, as well as establishing 797 reachability to them, requires a scalable name resolution system 798 considering several dynamic factors like mobility of end points, 799 service replication, in-network caching, failure or migration 800 [1-4][33][34][35][30]. The objective is to achieve scalable name 801 resolution handling static and dynamic ICN entities with low 802 complexity and control overhead. 804 o The first challenge faced by ICN-IoT name resolution is its 805 scalability [35][30]. Firstly, the name resolution service has to 806 support billions of objects and devices that are connected to the 807 Internet, many of which are crossing administrative domain 808 boundaries. Second of all, in addition to objects/devices, the 809 name resolution service is also responsible for mapping IoT 810 services to their network addresses. Many of these services are 811 based upon contexts, hence dynamically changing, as pointed out in 812 [30]. As a result, the name resolution service should be able to 813 scale gracefully to cover a large number of names/services with 814 wide variations (e.g., hierarchical names, flat names, names with 815 limited scope, etc.) 817 o The second challenge is fast name resolution. This challenge is 818 especially important for applications with stringent latency 819 requirements, such as health monitoring, emergency handling and 820 smart transportation [36]. 822 5.4. Contextual Communication 824 Contextualization through metadata in ICN control or application 825 payload allows IoT applications to adapt to different environments. 826 This enables intelligent networks which are self-configurable and 827 enable intelligent networking among consumers and producers [30]. 828 For example, let us look at the following smart transportation 829 scenario: "James walks on NYC streets and wants to find an empty cab 830 closest to his location." In this example, the context is the 831 relative locations of James and taxi drivers. A context service, as 832 an IoT middleware, processes the contextual information and bridges 833 the gap between raw sensor information and application requirements. 835 However, extracting contextual information on a real-time basis is 836 very challenging: 838 o We need to have a fast context resolution service through which 839 the involved IoT devices can continuously update its contextual 840 information to the application (e.g., each taxi's location and 841 Jame's information in the above example). 843 o The difficulty of this challenge grows rapidly when the number of 844 devices involved in a context as well as the number of contexts 845 increases. 847 5.5. Routing and Forwarding 849 Routing in ICN-IoT differs from routing in traditional IP networks in 850 that ICN routing is based upon names instead of locators. Broadly 851 speaking, ICN routing can be categorized into the following two 852 categories: direct name-based routing and indirect routing through 853 name resolution. 855 o In direct name-based routing, packets are forwarded by the name of 856 the data [37][32][38] or the name of the destination node [39]. 857 Here, the main challenge is to keep the ICN router state required 858 to route/forward data low. This challenge becomes more serious 859 when a flat naming scheme is used. 861 o In indirect routing, packets are forwarded based upon the locator 862 of the destination node, and the locator is obtained through the 863 name resolution service. In particular, the name locator binding 864 can be done either before routing (i.e., static binding) or during 865 routing (i.e., dynamic binding). For static binding, the router 866 state is the same as that in traditional routers, and the main 867 challenge is the need to have fast name resolution, especially 868 when the IoT nodes are mobile. For dynamic binding, ICN routers 869 need to main a name-based routing table, hence the challenge of 870 keeping the state information low. At the same time, the need of 871 fast name resolution is also critical. Finally, another challenge 872 is to quantify the cost associated with mobility management, 873 especially static binding vs. dynamic binding. 875 During a network transaction, either the data producer or the 876 consumer may move away and thus we need to handle the mobility to 877 avoid information loss. ICN may differentiate mobility of a data 878 consumer from that of a producer: 880 o When a consumer moves to a new location after sending out an 881 Interest, the Data may get lost, which requires the consumer to 882 simply resend the Interest. Depending on the network topology and 883 data availability, the new Interest might be forwarded to the same 884 or a different data producer. 886 o If the data producer itself has moved, the challenge is to control 887 the control overhead while flooding it across the network. 889 5.6. In-network Computing 891 Contextual services for IoT networks require in-network computing, in 892 which each sensor node or ICN router implements context reasoning 893 [30]. Another major purpose of in-network computing is to filer and 894 cleanse sensed data in IoT applications is critical as the data is 895 noisy as is [40]. 897 In-network computing faces different challenges in the constrained 898 and infrastructure parts of the network. 900 o In the constrained part of the network, the challenge rises due to 901 serious resource limitations on IoT devices or sensors. As a 902 result, the consensus is to include very simple computing 903 functionalities on constrained nodes. 905 o In the infrastructure part of the IoT network, in-network 906 computing faces the challenge of breaking the computing task into 907 smaller pieces and assigning each task to one or more ICN routers 908 [30]. 910 5.7. Security and Privacy 912 Security and privacy is crucial to all the IoT applications including 913 the use cases discussed in Section 4. In one recent demonstration, 914 it was shown that passive tire pressure sensors in cars could be 915 hacked and used as a gateway into the automotive system [41]. Though 916 ICN includes data-centric security features the mechanisms have to be 917 generic enough to satisfy multiplicity of policy requirements for 918 different applications. In general, we feel that security and 919 privacy protection in IoT systems should mainly focus on the 920 following aspects: confidentiality, integrity, authentication and 921 non-repudiation, and availability. 923 Implementing security and privacy methods faces different challenges 924 in the constrained and infrastructure part of the network. 926 o In the constrained part, energy limitation is the biggest 927 challenge. As an example, let us look at a typical sensor tag. 928 Suppose the tag has a single 16-bit processor, often running at 6 929 MHz to save energy, with 512Bytes of RAM and 16KB of flash for 930 program storage. Moreover, it has to deliver its data over a 931 wireless link for at least 10,000 hours on a coin cell battery. 932 As a result, traditional security/privacy measures are impossible 933 to be implemented in the constrained part. In this case, one 934 possible solution might be utilizing the physical wireless signals 935 as security measures [42] [30]. 937 o In the infrastructure part, we have several new threats introduced 938 by ICN-IoT [45]: 940 1. We need to ensure the name of a network element is issued by a 941 trustworthy organization such as in [44]. 943 2. An intruder may gain access or gather information from a 944 resource it is not entitled to. As a consequence, an 945 adversary may examine, remove or even modify confidential 946 information. 948 3. An intruder may mimic an authorized user or network process. 949 As a result, the intruder may forge signatures, or impersonate 950 a source address. 952 4. An adversary may manipulate the message exchange process 953 between network entities. Such manipulation may involve 954 replay, rerouting, mis-routing and deletion of messages. 956 5. An intruder may insert fake/false sensor data into the 957 network. The consequence might be an increase in delay and 958 performance degradation for network services and applications. 960 5.8. Energy Efficiency 962 All the optimizations for other components of the ICN-IoT system 963 (described in earlier subsections) can lead to optimized energy 964 efficiency. As a result, we refer the readers to read sections 965 5.1-5.6 for challenges associated with energy efficiency for ICN-IoT. 967 6. Informative References 969 [1] Cisco System Inc., CISCO., "Cisco visual networking index: 970 Global mobile data traffic forecast update.", 2009-2014. 972 [2] Shafig, M., Ji, L., Liu, A., Pang, J., and J. Wang, "A 973 first look at cellular machine-to-machine traffic: large 974 scale measurement and characterization.", Proceedings of 975 the ACM Sigmetrics , 2012. 977 [3] The European Telecommunications Standards Institute, 978 ETSI., "http://www.etsi.org/.", 1988. 980 [4] Global Intiative for M2M Standardization, oneM2M., 981 "http://www.onem2m.org/.", 2012. 983 [5] Constrained RESTful Environments, CoRE., 984 "https://datatracker.ietf.org/wg/core/charter/.", 2013. 986 [6] Ghodsi, A., Shenker, S., Koponen, T., Singla, A., 987 Raghavan, B., and J. Wilcox, "Information-Centric 988 Networking: Seeing the Forest of the Trees.", Hot Topics 989 in Networking , 2011. 991 [7] Melazzi, N., Detti, A., Arumaithurai, M., and K. 992 Ramakrishnan, "Internames: A Name-to-Name Principle for 993 the Future Internet.", International Workshop on Quality, 994 Reliability, and Security in Information-Centric 995 Networking (Q-ICN) , 2014. 997 [8] Dong, L., Zhang, Y., and D. Raychaudhuri, "Enhance Content 998 Broadcast Efficiency in Routers with Integrated Caching.", 999 Proceedings of the IEEE Symposium on Computers and 1000 Communications (ISCC) , 2011. 1002 [9] FIA project, NSF., "http://www.nets-fia.net/", 2010. 1004 [10] Kim, B., Lee, S., Lee, Y., Hwang, I., and Y. Rhee, 1005 "Mobiiscape: Middleware Support for Scalable Mobility 1006 Pattern Monitoring of Moving Objects in a Large-Scale 1007 City.", 2011. 1009 [11] Dietrich, D., Bruckne, D., Zucker, G., and P. Palensky, 1010 "Communication and Computation in Buildings: A Short 1011 Introduction and Overview", 2010. 1013 [12] Keith, K., Falco, F., and K. Scarfone, "Guide to 1014 Industrial Control Systems (ICS) Security. Technical 1015 Report 800-82 Revision 1", 2013. 1017 [13] Darianian, M. and Martin. Michael, "Smart home mobile 1018 RFID-based Internet-of-Things systems and services.", 1019 2008. 1021 [14] Zhu, Q., Wang, R., Chen, Q., Chen, Y., and W. Qin, "IOT 1022 Gateway: Bridging Wireless Sensor Networks into Internet 1023 of Things", 2010. 1025 [15] Biswas, T., Chakrabort, A., Ravindran, R., Zhang, X., and 1026 G. Wang, "Contextualized information-centric home 1027 network", 2013. 1029 [16] Huang, R., Zhang, J., Hu, Y., and J. Yang, "Smart Campus: 1030 The Developing Trends of Digital Campus", 2012. 1032 [17] Yan, Y., Qian, Y., Hu, Y., and J. Yang, "A Survey on Smart 1033 Grid Communication Infrastructures: Motivations, 1034 Requirements and Challenges", 2013. 1036 [18] Miao, Y. and Y. Bu, "Research on the Architecture and Key 1037 Technology of Internet of Things (loT) Applied on Smart 1038 Grid", 2010. 1040 [19] Zhang, Y., Yu, R., Nekovee, M., Liu, Y., Xie, S., and S. 1041 Gjessing, "Cognitive Machine-to-Machine Communications: 1042 Visions and Potentials for the Smart Grid", 2012. 1044 [20] Zhou, H., Liu, B., and D. Wang, "Design and Research of 1045 Urban Intelligent Transportation System Based on the 1046 Internet of Things", 2012. 1048 [21] Zhang, M., Yu, T., and G. Zhai, "Smart Transport System 1049 Based on the Internet of Things", 2012. 1051 [22] Zhang, A., Yu, R., Nekovee, M., and S. Xie, "The Internet 1052 of Things for Ambient Assisted Living", 2010. 1054 [23] Savola, R., Abie, H., and M. Sihvonen, "Towards metrics- 1055 driven adaptive security management in E-health IoT 1056 applications.", 2012. 1058 [24] Jacobson, V., Smetters, D., Plass, M., Stewart, P., 1059 Thornton, J., and R. Braynard, "VoCCN: Voice-over Content- 1060 Centric Networks", 2009. 1062 [25] Piro, G., Cianci, I., Grieco, L., Boggia, G., and P. 1063 Camarda, "Information Centric Services in Smart Cities", 1064 2014. 1066 [26] Ravindran, R., Biswas, T., Zhang, X., Chakrabort, A., and 1067 G. Wang, "Information-centric Networking based Homenet", 1068 2014. 1070 [27] Dannewitz, C., D' Ambrosio, M., and V. Vercellone, 1071 "Hierarchical DHT-based name resolution for information- 1072 centric networks", 2013. 1074 [28] Chai, W., He, D., and I. Psaras, "Cache "less for more" in 1075 information-centric networks", 2012. 1077 [29] Eum, S., Nakauchi, K., Murata, M., Shoji, Yozo., and N. 1078 Nishinaga, "Catt: potential based routing with content 1079 caching for icn", 2012. 1081 [30] Eum, S., Shvartzshnaider, Y., Francisco, J., Martini, R., 1082 and D. Raychaudhuri, "Enabling internet-of-things services 1083 in the mobilityfirst future internet architecture", 2012. 1085 [31] Sun, Y., Qiao, X., Cheng, B., and J. Chen, "A low-delay, 1086 lightweight publish/subscribe architecture for delay- 1087 sensitive IOT services", 2013. 1089 [32] Baccelli, E., Mehlis, C., Hahm, O., Schmidt, T., and M. 1090 Wahlisch, "Information Centric Networking in the 1091 IoT:Experiments with NDN in the Wild", 2013. 1093 [33] Gronbaek, I., "Architecture for the Internet of Things 1094 (IoT): API and interconnect", 2008. 1096 [34] Tian, Y., Liu, Y., Yan, Z., Wu, S., and H. Li, "RNS-A 1097 Public Resource Name Service Platform for the Internet of 1098 Things", 2012. 1100 [35] Roussos, G. and P. Chartier, "Scalable id/locator 1101 resolution for the iot", 2011. 1103 [36] Li, S., Zhang, Y., Raychaudhuri, D., and R. Ravindran, "A 1104 Comparative Study of MobilityFirst and NDN based ICN-IoT 1105 Architectures", 2011. 1107 [37] Amadeo, M., Campolo, C., Iera, A., and A. Molinaro, "Named 1108 data networking for IoT: An architectural perspective", 1109 2014. 1111 [38] Amadeo, M. and C. Campolo, "Potential of information- 1112 centric wireless sensor and actor networking", 2014. 1114 [39] Nelson, S., Bhanage, G., and D. Raychaudhuri, "GSTAR: 1115 generalized storage-aware routing for mobilityfirst in the 1116 future mobile internet", 2014. 1118 [40] Trappe, W., Zhang, Y., and B. Nath, "MIAMI: methods and 1119 infrastructure for the assurance of measurement 1120 information", 2005. 1122 [41] Rouf, I., Mustafa, H., Taylor, T., Oh, S., Xu, W., 1123 Gruteser, M., Trappe, W., and I. Seskar, "Security and 1124 privacy vulnerabilities of in-car wireless networks: A 1125 tire pressure monitoring system case study", 2005. 1127 [42] Liu, R. and W. Trappe, "Securing Wireless Communications 1128 at the Physical Layer", 2010. 1130 [43] Xiao, L., Greenstein, L., Mandayam, N., and W. Trappe, 1131 "Using the physical layer for wireless authentication in 1132 time-variant channels", 2008. 1134 [44] Sun, S., Lannom, L., and B. Boesch, "Handle system 1135 overview", 2003. 1137 [45] Liu, X., Trappe, W., and Y. Zhang, "Secure Name Resolution 1138 for Identifier-to-Locator Mappings in the Global 1139 Internet", 2003. 1141 Authors' Addresses 1143 Prof.Yanyong Zhang 1144 WINLAB, Rutgers University 1145 671, U.S 1 1146 North Brunswick, NJ 08902 1147 USA 1149 Email: yyzhang@winlab.rutgers.edu 1151 Prof. Dipankar Raychadhuri 1152 WINLAB, Rutgers University 1153 671, U.S 1 1154 North Brunswick, NJ 08902 1155 USA 1157 Email: ray@winlab.rutgers.edu 1159 Prof. Luigi Alfredo Grieco 1160 Politecnico di Bari (DEI) 1161 Via Orabona 4 1162 Bari 70125 1163 Italy 1165 Email: alfredo.grieco@poliba.it 1167 Prof. Emmanuel Baccelli 1168 INRIA 1169 Room 148, Takustrasse 9 1170 Berlin 14195 1171 France 1173 Email: Emmanuel.Baccelli@inria.fr 1175 Jeff Burke 1176 UCLA REMAP 1177 102 East Melnitz Hall 1178 Los Angeles, CA 90095 1179 USA 1181 Email: jburke@ucla.edu 1182 Ravishankar Ravindran 1183 Huawei Technologies 1184 2330 Central Expressway 1185 Santa Clara, CA 95050 1186 USA 1188 Email: ravi.ravindran@huawei.com 1190 Guoqiang Wang 1191 Huawei Technologies 1192 2330 Central Expressway 1193 Santa Clara, CA 95050 1194 USA 1196 Email: gq.wang@huawei.com