idnits 2.17.1 draft-zhang-iot-icn-architecture-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. ** 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 (June 3, 2014) is 3614 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Missing reference section? '1' on line 948 looks like a reference -- Missing reference section? '2' on line 951 looks like a reference -- Missing reference section? '3' on line 956 looks like a reference -- Missing reference section? '4' on line 959 looks like a reference -- Missing reference section? 'IoTGW' on line 442 looks like a reference -- Missing reference section? '5' on line 962 looks like a reference -- Missing reference section? '6' on line 967 looks like a reference -- Missing reference section? 'Computing' on line 620 looks like a reference -- Missing reference section? '8' on line 975 looks like a reference -- Missing reference section? '7' on line 972 looks like a reference Summary: 3 errors (**), 0 flaws (~~), 1 warning (==), 11 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: December 5, 2014 R. Ravindran 6 G. Wang 7 Huawei Technologies 8 June 3, 2014 10 ICN based Architecture for IoT 11 draft-zhang-iot-icn-architecture-01 13 Abstract 15 Internet of Things (IoT) promises to connect billions of objects to 16 Internet. After deploying many stand-alone IoT systems in different 17 domains, the current trend is to develop a unified IoT platform so 18 that objects can be made accessible to applications across 19 organizations and domains. Towards this goal, quite a few proposals 20 have been made to build a unified IoT platform as an overlay on 21 today's Internet. Such an overlay solution, however, is inadequate 22 to address the important challenges posed by a unified IoT system, 23 especially in terms of mobility, scalability, and communication 24 reliability, due to the inherent inefficiencies of the current 25 Internet. To address this problem, we propose to build a unified IoT 26 platform based on the Information Centric Network (ICN) architecture, 27 which we call ICN-IoT. ICN-IoT leverages the salient features of 28 ICN, and thus provides seamless mobility support, scalability, and 29 efficient content and service delivery. 31 In this proposal, we first present a few popular IoT scenarios in 32 smart homes, smart grid, smart transportation, and smart healthcare. 33 Then we identify a list of important requirements with the unified 34 IoT architecture that promises to support tens of billions of 35 objects. After discussing the weaknesses of the current overlay- 36 based IoT solution, we propose an ICN-based solution, ICN-IoT, which 37 can sufficiently satisfy these requirements. We present an example 38 ICN-IoT architecture and discuss how it supports efficient data 39 discovery, data processing and data distribution. Finally, we show 40 that ICN-IoT efficiently supports context- based scenarios, which are 41 very common for many IoT applications. 43 Status of This Memo 45 This Internet-Draft is submitted in full conformance with the 46 provisions of BCP 78 and BCP 79. 48 Internet-Drafts are working documents of the Internet Engineering 49 Task Force (IETF). Note that other groups may also distribute 50 working documents as Internet-Drafts. The list of current Internet- 51 Drafts is at http://datatracker.ietf.org/drafts/current/. 53 Internet-Drafts are draft documents valid for a maximum of six months 54 and may be updated, replaced, or obsoleted by other documents at any 55 time. It is inappropriate to use Internet-Drafts as reference 56 material or to cite them other than as "work in progress." 58 This Internet-Draft will expire on December 5, 2014. 60 Copyright Notice 62 Copyright (c) 2014 IETF Trust and the persons identified as the 63 document authors. All rights reserved. 65 This document is subject to BCP 78 and the IETF Trust's Legal 66 Provisions Relating to IETF Documents 67 (http://trustee.ietf.org/license-info) in effect on the date of 68 publication of this document. Please review these documents 69 carefully, as they describe your rights and restrictions with respect 70 to this document. Code Components extracted from this document must 71 include Simplified BSD License text as described in Section 4.e of 72 the Trust Legal Provisions and are provided without warranty as 73 described in the Simplified BSD License. 75 Table of Contents 77 1. IoT Motivation and Challenges . . . . . . . . . . . . . . . . 3 78 1.1. Popular scenarios . . . . . . . . . . . . . . . . . . . . 3 79 1.1.1. Smart Homes . . . . . . . . . . . . . . . . . . . . . 3 80 1.1.2. Smart Grid . . . . . . . . . . . . . . . . . . . . . 4 81 1.1.3. Smart Transportation . . . . . . . . . . . . . . . . 4 82 1.1.4. Smart Healthcare . . . . . . . . . . . . . . . . . . 4 83 2. IoT Architectural Requirements . . . . . . . . . . . . . . . 4 84 2.1. Naming . . . . . . . . . . . . . . . . . . . . . . . . . 4 85 2.2. Scalability . . . . . . . . . . . . . . . . . . . . . . . 5 86 2.3. Resource Constraints . . . . . . . . . . . . . . . . . . 5 87 2.4. Traffic Characteristics . . . . . . . . . . . . . . . . . 6 88 2.5. Contextual Communication . . . . . . . . . . . . . . . . 6 89 2.6. Handling Mobility . . . . . . . . . . . . . . . . . . . . 7 90 2.7. Storage and Caching . . . . . . . . . . . . . . . . . . . 7 91 2.8. Security and Privacy . . . . . . . . . . . . . . . . . . 7 92 2.9. Communication Reliability . . . . . . . . . . . . . . . . 8 93 2.10. Self-Organization . . . . . . . . . . . . . . . . . . . . 8 94 2.11. Ad hoc and Infrastructure Mode . . . . . . . . . . . . . 8 95 3. State of the Art . . . . . . . . . . . . . . . . . . . . . . 8 96 3.1. Silo IoT Architecture . . . . . . . . . . . . . . . . . . 9 97 3.2. Overlay Based Unified IoT Solutions . . . . . . . . . . . 10 98 3.2.1. Weaknesses of the Overlay-based Approach . . . . . . 10 99 4. Proposed ICN-Centric Unified IoT Platform . . . . . . . . . . 12 100 4.1. Strengths of ICN-IoT . . . . . . . . . . . . . . . . . . 13 101 4.2. Example ICN-IoT Architecture . . . . . . . . . . . . . . 14 102 4.3. ICN-IoT Scenario . . . . . . . . . . . . . . . . . . . . 17 103 5. Informative References . . . . . . . . . . . . . . . . . . . 21 104 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22 106 1. IoT Motivation and Challenges 108 During the past decade, many standalone Internet of Things (IoT) 109 systems have been developed and deployed in different domains. The 110 recent trend, however, is to evolve towards a globally unified IoT 111 platform, in which billions of objects connect to the Internet, 112 available for interactions among themselves, as well as interactions 113 with many different applications across boundaries of administration 114 and domains. Building a unified IoT platform, however, poses great 115 challenges on the underlying network and systems. To name a few, it 116 needs to support 50-100 Billion networked objects [1], many of which 117 are mobile. The objects will have extremely heterogeneous means of 118 connecting to the Internet, often with severe resource constraints. 119 Interactions between the applications and objects are often real-time 120 and dynamic, requiring strong security and privacy protections.Before 121 we present our solution to such a unified platform, we first describe 122 a few popular IoT scenarios to motivate this proposal. 124 1.1. Popular scenarios 126 Several types of IoT applications exists, where the goal is efficient 127 and secure management and communication among objects in the system 128 and with the physical world through sensors, RFIDs and other devices. 129 Below we list a few popular IoT applications. 131 1.1.1. Smart Homes 133 Home is a complex ecosystem for smart systems such as climate 134 control, home security monitoring, smoke detection, or smart meters. 135 In a unified IoT platform, we would inter-connect these systems 136 through the Internet, such that they can interact with each other and 137 make decisions at an aggregated level. Also, the systems can be 138 accessed and manipulated remotely. The challenges for smart home 139 include topology independent service discovery, common protocol for 140 heterogeneous device/application/service interaction, policy based 141 routing/forwarding, service mobility as well as privacy protection. 143 1.1.2. Smart Grid 145 Central to smart grid is data flow and information management, 146 achieved by using sensors and actuators, which enables important 147 capabilities such as substation and distribution automation. In a 148 unified IoT platform, data collected from different smart grids can 149 be integrated to reach more significant optimizations. The 150 challenges for smart grid include reliability, real-time control, 151 secure communications, and data privacy. 153 1.1.3. Smart Transportation 155 We are currently witnessing the increasing integration of sensors 156 into cars. Current production cars already carry many sensors 157 ranging from rain gauges and accelerometers over wheel rotation/ 158 traction sensors, to cameras. While intended for internal vehicle 159 functions, these could also be networked and leveraged for 160 applications such as monitoring external traffic/road conditions. 161 Further, we can build vehicle-to-infrastructure (V2I) and vehicle-to- 162 vehicle (V2V) communications that enable many more applications for 163 safety, convenience, entertainment, etc. The challenges for smart 164 transportation include fast data/device/service discovery and 165 association, efficient communications with mobility, trustworthy data 166 collection and exchange. 168 1.1.4. Smart Healthcare 170 As more embedded medical devices, or devices that can monitor human 171 health become increasingly deployed, smart healthcare is becoming a 172 viable alternative to traditional healthcare solutions. For smart 173 health applications, a unified IoT platform is critical for sharing 174 data and enabling timely actuations. The challenges in smart 175 healthcare include real-time interactions, high reliability, short 176 communication latencies, trustworthy, security and privacy. 178 2. IoT Architectural Requirements 180 A unified IoT platform has to support interactions among a large 181 number of mobile devices across the boundaries of organizations and 182 domains. As a result, it naturally poses stringent requirements in 183 every aspect of the system design. Below, we outline a few important 184 requirements that a unified IoT platform has to address. 186 2.1. Naming 188 The first step towards realizing a unified IoT platform is the 189 ability to assign names that are unique within the scope/lifetime of 190 each device, data items generated by these devices, or a group of 191 devices. Naming has the following requirements. First, names need 192 to be application-centric, i.e., solely serving the purpose of an 193 application or service. Second, names need to be persistent against 194 dynamic attributes that are common in IoT systems, such as mobility 195 or migration. Third, names need to be secure based on application 196 requirement. 198 2.2. Scalability 200 Cisco predicts there will be around 50 Billion IoT devices such as 201 sensors, RFID tags, and actuators, on the Internet by 2020 [1]. As 202 mentioned above, a unified IoT platform needs to name every 203 informational entity such as data, devices, etc. To deal with 204 scalability, the name-locator separation is the basic requirement, 205 implying that it is necessary to have a name resolution service. The 206 requirement on such a resolution service is thus clear: the system 207 should be able to insert/update/look up a name within a short 208 latency. To satisfy this requirement, decentralization of the name 209 resolution is the key. 211 2.3. Resource Constraints 213 IoT devices can be broadly classified into two groups: resource- 214 sufficient and resource-constrained. In general, there are the 215 following types of resources: power, computing, storage, and 216 bandwidth. 218 Power constraints of the IoT devices limit how much data these 219 devices can communicate, as it has been shown that communications 220 consume more power than other activities for embedded devices. 221 Flexible techniques to collect the relevant information are required, 222 and uploading every single produced data to a central server is 223 undesirable. Computing constraints limit the type and amount of 224 processing these devices can perform, also information needs to be 225 available where it is more likely to be consumed. As a result, more 226 complex processing needs to be conducted elsewhere, example at the 227 network edge, which makes it important to balance local computation 228 versus communication. 230 Storage constraints of the IoT devices limit the amount of data that 231 can be stored on the devices. This constraint means that unused 232 sensor data may need to be discarded from time to time. Bandwidth 233 constraints of the IoT devices limit the amount of communication 234 these devices can have, which will have the same implication on the 235 system architecture as the power constraints; namely, we cannot 236 afford to communicate with every single sensor data generated by the 237 device. 239 2.4. Traffic Characteristics 241 IoT traffic can be broadly classified into local area traffic and 242 wide area traffic. Local area traffic is between nearby devices. 243 For example, neighboring cars may work together to detect potential 244 hazards on the highway, sensors deployed in the same room may 245 collaborate to determine how to adjust the heating level in the room. 246 These local area communications often involve data aggregation and 247 filtering, have real time constraints, and require fast device/data/ 248 service discovery and association. At the same time, the IoT 249 platform has to also support wide area communications. For example, 250 commuters can find out real-time traffic and road information and 251 then decide which commuting route to take. Wide area communications 252 require efficient data/service discovery and resolution services. 254 While traffic characteristics for different IoT systems are expected 255 to different, certain IoT systems have been analyzed and shown to 256 have comparable uplink and downlink traffic volume in some 257 applications such as [2], which means that we have to optimize the 258 bandwidth/energy consumption in both directions. Further, IoT 259 traffic demonstrates certain periodicity and burstiness [2]. As a 260 result, when provisioning the system, peak traffic volume has to be 261 considered. 263 2.5. Contextual Communication 265 Many IoT applications shall rely on contextual information such as 266 social, grouping, location, type of ecosystem (home, grid, transport 267 etc.) of devices and data (which are referred to as contexts in this 268 document) to initiate dynamic relationship and communication. For 269 example, cars travelling on the highway may form a "cluster" based 270 upon their temporal physical proximity as well as the detection of 271 the same event. These temporary groups are referred to as contexts. 272 IoT applications need to support interactions among the members of a 273 context, as well as interactions across contexts. 275 Temporal context can be broadly categorized into two classes, long- 276 term contexts such as those that are based upon social contacts as 277 well as stationary physical locations (e.g., sensors in a car/ 278 building), and short-term contexts such as those that are based upon 279 temporary proximity (e.g., all taxicabs within half a mile of the 280 Time Square at noon on Oct 1, 2013). Between these two classes, 281 short-term contexts are more challenging to support, requiring fast 282 formation, update, lookup and association of these contexts. 284 2.6. Handling Mobility 286 Mobility in the IoT platform can mean 1) the data producer mobility 287 (i.e., location change), 2) the data consumer mobility, 3) IoT 288 Network mobility; and 3) disconnection between the data source and 289 destination pair (e.g., due to unreliable wireless links). The 290 requirement on mobility support is to be able to deliver IoT data 291 below an application acceptable delay constraint in all of the above 292 three cases. 294 There are varying degrees of mobility in a unified IoT platform, 295 ranging from static as in fixed assets to highly dynamic in vehicle- 296 to-vehicle environments. 298 2.7. Storage and Caching 300 Storage and caching plays a very significant role depending on the 301 type of IoT ecosystem with the fact that data generated is also 302 subjected to privacy and security guidelines. In a unified IoT 303 platform, depending on content caching requirements can be cached at 304 will or at service authorized points, and thus we don't need to 305 always forward a content request to its original creator. Rather, 306 locating and receiving a cached copy is sufficient for IoT 307 applications. This optimization can greatly reduce the content 308 access latencies. 310 In network storage and caching, however, has the following 311 requirements on the IoT platform. First, the platform needs to 312 support the efficient resolution of cached copies. Second, certain 313 content should not be cached anywhere, and the service platform 314 should be able to enforce this. Third, the platform should strive 315 for the balance between caching, content security/privacy, and 316 regulations. 318 2.8. Security and Privacy 320 The unified IoT platform makes physical objects accessible to 321 applications across organizations and domains, and security and 322 privacy thus become a serious concern. Security includes data 323 integrity, authentication, trust management, and access control at 324 different layers of the IoT platform. Privacy means that both the 325 content and the context around IoT data need to be protected. These 326 requirements will be driven by various stake holders such as 327 industry, government, consumers etc. 329 2.9. Communication Reliability 331 IoT applications can be broadly categorized into mission critical and 332 non-mission critical. For mission critical applications, reliable 333 communication is one of the most important features as these 334 applications have strong QoS requirements. Reliable communication 335 requires the following capabilities for the underlying system: (1) 336 seamless mobility support to support for extreme disruptions (DTN), 337 (2) efficient routing in the presence of intermittent disconnection, 338 and (3) QoS aware routing. 340 2.10. Self-Organization 342 The unified IoT platform should be able to self-organize to meet 343 various application requirements, especially the capability to 344 quickly discover heterogeneous and relevant devices/data/services 345 based on the context. This discovery can be achieved through an 346 efficient platform-wide publish-subscribe service, or through private 347 community grouping/clustering based upon trust and other security 348 requirements. In the former case, the publish-subscribe service must 349 be efficiently implemented, able to support seamless mobility, in- 350 network caching, name-based routing, etc. In the latter case, the 351 IoT platform needs to discover the private community groups/clusters 352 efficiently. 354 2.11. Ad hoc and Infrastructure Mode 356 Depending upon whether there is communication infrastructure, an IoT 357 system can be classified as either ad-hoc or infrastructure mode. 358 For example, a vehicle may determine to report its location and 359 status information to a server periodically through cellular 360 connection, or, a group of vehicles may form an ad-hoc network that 361 collectively detect road conditions around them. In the cases where 362 infrastructure is unavailable, one of the participating nodes may 363 choose to become the temporary gateway. The open IoT platform needs 364 to be able to handle both situations. 366 The unified IoT platform needs to design a common protocol that 367 serves both modes. Such a protocol should be able to provide: (1) 368 energy-efficient topology discovery and data forwarding in the ad-hoc 369 mode, and (2) scalable name resolution in the infrastructure mode. 371 3. State of the Art 373 Over the years, many stand-alone IoT systems have been deployed in 374 various domains. These systems usually adopt a vertical silo 375 architecture and support a small set of pre-designated applications. 376 A recent trend, however, is to move away from this approach, towards 377 a unified IoT platform in which the existing silo IoT systems, as 378 well as new systems that are rapidly deployed, will make their data 379 and services accessible to general Internet applications. In such a 380 unified platform, physical world resources can be accessed over 381 Internet and shared across the boundaries of physical, enterprise and 382 application. However, current approaches to achieving this objective 383 are based upon Internet overlays, whose inherent inefficiencies 384 hinders the platform from satisfying the IoT requirements outlined 385 earlier (particularly in terms of scalability, security, mobility, 386 and self-organization) 388 3.1. Silo IoT Architecture 390 [IoT Server] 391 | 392 | 393 ______|_______ 394 _______ { } 395 { } { } 396 {IoT Dev}\ { Internet }---[IoT Application] 397 {_______} [IoTGW]---{ } 398 { } 399 {______________} 401 Figure 1:Silo architecture of standalone IoT systems 403 A typical standalone IoT system is illustrated in Figure 1, which 404 includes devices, a gateway, a server and applications. Many IoT 405 devices have limited power and computing resources, unable to 406 directly run normal IP access network (Ethernet, WIFI, 3G/LTE etc.) 407 protocols. Therefore, we use the IoT gateway to connect these 408 devices to the server. Through the IoT server, applications can 409 subscribe to the data collected by the devices, or interact with the 410 devices. 412 There have been quite a few popular protocols for standalone IoT 413 systems, such as DF-1, MelsecNet, Honeywell SDS, BACnet, etc. 414 However, these protocols are host-driven, instead of information 415 driven, leading to a highly fragmented protocol space with limited 416 interoperability. 418 3.2. Overlay Based Unified IoT Solutions 420 The current approach to a unified IoT platform is to make IoT 421 gateways and servers adopt standard APIs. IoT devices connect to the 422 Internet through the standard APIs and IoT applications subscribe and 423 receive data through standard control and data APIs. Building on top 424 of today's Internet as an overlay, this is the most practical 425 approach towards a unified IoT platform. There are ongoing 426 standardization efforts including ETSI[3], and CORE[4]. Network 427 operators can use standard API to build common IOT gateways and 428 servers for their customers. Figure 2 shows the architecture adopted 429 in this approach. 431 Publishing----[IoT Server]----Subscribing-- 432 | / | \ | 433 | / | \ | 434 | /______|_______ \ | 435 ___________ | /{ } publishing | 436 { } | | { } | | 437 {Smart Homes}\ | | { Internet }---------[IoT Application] 438 {___________} [IoTGW]---{ }\ | ________________ 439 | { } \ | { } 440 | {______________} [IoTGW]-{Smart Healthcare} 441 | | {________________} 442 Publishing [IoTGW] 443 | ____|_____ 444 | { } 445 ---{Smart Grid} 446 {__________} 448 Figure 2: Implementing an open IoT platform through standarized APIs 449 on the IoT gateways and the server 451 3.2.1. Weaknesses of the Overlay-based Approach 453 The above overlay-based approach can work with many different 454 protocols, but the system is not designed in a holistic manner. 455 Another limiting factor is that it is built upon today's IP network, 456 which has a few inherent weaknesses towards supporting a unified IoT 457 system. As a result, it cannot satisfy some of the requirements we 458 outlined in Section 3: 460 o Naming. The overlay-based approach uses IP addresses as names at 461 the network layer, which are not persistent for mobile devices/ 462 services. 464 o Scalability. The overlay-based approach uses IP addresses as 465 names at the network layer, which does not provide the scalability 466 needed to support device/service mobility or flexible name 467 resolution. 469 o Resource constraints. The overlay-based approach requires every 470 device to send data to the IoT server. Resource constraints of 471 the IoT devices, especially in power and bandwidth, will seriously 472 limit the performance of this approach. 474 o Traffic Characteristics. In this approach, applications are 475 written in a host-centric manner, instead of being information- 476 centric. As a result, it is challenging for the underlying system 477 to satisfy the communication patterns of the applications. 478 Further, characteristics of today's Internet, such as the lack of 479 multicast, will make the matters worse. 481 o Contextual Communications. This overlay-based approach cannot 482 react to dynamic contextual changes in a timely fashion. The main 483 reason is that context lists are kept at the IoT server in this 484 approach, and they cannot help efficiently route requests/ 485 information at the network layer. 487 o Mobility. The overlay-based approach cannot seamlessly support 488 device mobility. In this approach, communications are IP driven, 489 which is inefficient for mobility support. 491 o Storage and Caching. The overlay-based approach does not provide 492 efficient storage/caching support. Also, applications are written 493 in a host-centric manner, wherein network requests are bound to a 494 specific destination host/server instead of a specific piece of 495 content. 497 o Communication Reliability. The overlay-based approach offers 498 insufficient communication reliability when the devices/services/ 499 data are mobile. 501 o Self-Organization. The overlay-based approach is topology-based 502 as it is bound to IP semantics, and thus does not sufficiently 503 satisfy the self-organization requirement. 505 o Ad-hoc and infrastructure mode. As mentioned above, the overlay- 506 based approach lacks self-organization, and thus does not provide 507 efficient support for the ad-hoc mode. 509 4. Proposed ICN-Centric Unified IoT Platform 511 ______________ __________ __________ 512 |IoT Smart Home| |IoT Smart | |IoT Smart | 513 |Management | |Transport | |Healthcare| 514 |______________| |Management| |Management| 515 \ |__________| |__________| 516 \ | / 517 \ _____________|___________ / 518 { } 519 { } 520 { ICN } 521 { } 522 {_________________________} 523 / | \ 524 / | \ 525 _________/ ________|______ __\_____________ 526 { } { } { } 527 {Smart home} {Smart Transport} {Smart Healthcare} 528 {__________} {_______________} {________________} 529 | | | | | | 530 ___|__ __|___ __|__ __|__ ____|____ ____|____ 531 |Home-1||Home-2| |Car-1||Car-2| |Medical ||Medcical | 532 |______||______| |_____||_____| |Devices-1||Devices-2| 533 |_________||_________| 535 Figure 3: The proposed ICN-centric IoT unified platform. 537 In recent years, the current Internet has become inefficient in 538 supporting rapidly emerging Internet use cases, e.g., mobility, 539 content retrieval, IoT, context, etc. As a result, Information 540 Centric Network [5] has been proposed as a future Internet design to 541 address these inefficiencies. ICN has the following main features: 542 (1) it identifies a network object (including a mobile device, a 543 content, a service, or a context) by its name instead of its IP 544 address, (2) a hybrid name/address routing, and (3) a delay-tolerant 545 transport. These features make it easy to realize many in-network 546 functions, such as mobility support, multicasting, content caching, 547 cloud/edge computing and security. 549 Considering these salient features of ICN, we propose to build a 550 unified IoT platform using ICN, in which the overlay IoT services are 551 only needed for administrative purposes, while the publishing, 552 discovery, and delivery of the IoT data/services is directly 553 implemented within the ICN network. Figure 3 shows the proposed ICN- 554 centric IoT approach, which is centered around the ICN network 555 instead of today's Internet. 557 4.1. Strengths of ICN-IoT 559 Our proposed ICN-IoT is a network-layer IoT solution, which can 560 satisfy the requirements of the open IoT platform: 562 o Naming. In ICN-IoT, we assign a unique name to an IoT object, an 563 IoT service, or even a context. These names are persistent 564 throughout their scopes. 566 o Scalability. In ICN-IoT, the name resolution is performed at the 567 network layer, distributed within the entire network. Thus, it 568 can achieve high degree of scalability exploiting features like 569 content locality, local computing, and multicasting. 571 o Resource constraints. In ICN-IoT, mobile devices only need to 572 upload their data to the gateway when some applications subscribe 573 to the data. Thus, it offers a resource-efficient solution. 575 o Local traffic Pattern. In ICN-IoT, we can easily cache data/ 576 services in the network, facilitating local communications. 578 o Context-aware communications. In ICN-IoT, we assign unique names 579 to contexts, which are then mapped to the devices that are 580 involved in the context by the name resolution service. The 581 support of multicast can greatly ease the communications to these 582 devices. 584 o Seamless mobility handling. In ICN-IoT, ICN's name resolution 585 layer allows multiple levels of mobility relying on receiver- 586 oriented nature for self-recovery for consumers, to multi-casting 587 and late-binding techniques to realize seamless mobility support 588 of producing nodes. 590 o Data storage. In ICN-IoT, data are stored locally, either by the 591 mobile device or by the gateway nodes or at service points. We 592 also implement in-network storage/caching [6] to speed up data 593 delivery. 595 o Security and privacy. In ICN-IoT, secure binding between names 596 and content instead of IP addresses to identify devices/data/ 597 services, is inherently more secure allowing pervasive caching. 599 o Communication reliability. In ICN-IoT, we support seamless 600 mobility, which in turn guarantees reliable communications. 602 o Ad hoc and infrastructure mode. ICN-IoT support both ad-hoc and 603 infrastructure modes. 605 +-[Host]-[Sensors]-[Content]-[Context]-+ 606 |Name Assignment Service(Semantic->UID)| 607 +======================================+ 608 | Delay Tolerant Network(DTN)Transport |--+ 609 | (Storage-aware) | | 610 +======================================+ | 611 | Hybrid UID/Address Routing |--|--+ 612 +======================================+ | | 613 +---|Name Resolution Service(UID->Address) | | | 614 | +======================================+ | | 615 | _________ _________ | | 616 | [ Routing ]..................[ Routing ]--+ | 617 | +=========+..................+=========+ | 618 | [ Storage ]..................[ Storage ] | 619 | +=========+..................+=========+ | 620 | [Computing]..................[Computing] | 621 +---[ Plane ]..................[ Plane ]-----+ 622 +---------+ +---------+ 623 ICN Router ICN Router 625 Figure 4: An Example ICN-IoT Architecture 627 4.2. Example ICN-IoT Architecture 629 The design of ICN-IoT is to support a scalable, unified IoT 630 architecture with tens of billions of devices. The ICN-IoT 631 introduces a unique identifier (UID) for every network object, 632 separated from its dynamic access network locations represented by 633 network addresses. The separation of naming and addressing allows 634 ICN-IoT to support identity based routing, which provides seamless 635 mobility support. Multicast and anycast can then become a native 636 network capability since a UID can be bound to multiple addresses. 638 Figure 4 depicts the example ICN-IoT core network architecture. The 639 assumption is that ICN routers have a sizeable storage and a 640 computing plane in addition to the basic routing function. The 641 proposed ICN-IoT network includes the following three basic services: 643 o Name Resolution Service (NRS): A core ICN-IoT function that 644 maintains mappings between UID to network address (NA). This can 645 be a logically centralized service distributed on all ICN routers. 647 o Hybrid UID/network address routing: An ICN router makes routing 648 decisions for UID identified data blocks. It uses NRS to find the 649 network address(s) for a UID. In case an explicit network address 650 cannot be obtained from NRS, it may route based on intermediate 651 network address and use "late-biding" from UID to its actual 652 network address. 654 o Delay-tolerant network (DTN) transport: An ICN router can deliver 655 UID-only identified data blocks from/to a networked object. The 656 transport performs a cache and forward (CNF) style, hop-by-hop 657 delivery. The data block is cached in router storage and forward 658 to next hop based on routing decisions. 660 o In addition to baseline services, ICN-IoT assumes there is a name 661 assignment service (NAS) chosen by the owner of a networked 662 object. Through the NAS, the owner assigns and publishes a UID 663 with its semantic descriptions for his networked object to a 664 searchable space, such as google or semantic Linked-data space 665 [1]. 667 In Figure 5, we summarize the ICN-IoT milddleware into three service 668 categories: 1) Data Discovery Service, 2) Data Processing Service and 669 3) Data (Re)Distribution Service. These services span both in Ad hoc 670 and Infrastructure settings. 672 Data Discovery Service: Discovery service allows applications finding 673 things/services/data through certain semantic / syntactic resolution. 674 In ICN-IoT, each data/service has both a user-readable name with 675 certain semantic structures and unique identifiers (UID). Based on 676 the human readable names, the data discovery service can help 677 discover the requested data/services. 679 Data Processing Service: The data processing service generates new 680 knowledge or information through applying knowledge and/or rules on 681 existing data. Data processing can be distributed based on its scope 682 and relevance as in the local node, versus edge service routers, or 683 in data centers. Data processing procedures are often defined by the 684 applications/services. 686 _______________________________________________ 687 Things | IoT MIDDLEWARE | APPS/ 688 ________ | (Ad-hoc/Infrastructure) | Services 689 |Sensors || ___________________ | ________ 690 |--------|| +------|Discovery Service |-----+ ||APP1 | 691 |________|| _____|_____ |(Semantic/Syntactic| ____|______ ||--------| 692 | Tags |||Resource ||Resolution) ||Application|||________| 693 |--------|||Abstraction|+-------------------+|Abstraction|||APP2 | 694 |________||+-----------+|Data Analysis |+-----------+||--------| 695 |Feeds || | |Event Detection | | ||________| 696 |--------|| | |Context Reasoning | | ||Service1| 697 |________|| | |Security/privacy | | ||--------| 698 |Actuator|| | |control | | ||________| 699 |--------|| | |(Knowledge,Rules) | | ||Service2| 700 |________|| | +-------------------+ | ||--------| 701 |Database|| | |(Re)-distribution | | ||________| 702 +--------+| | |Service(CDN,Cloud) | | | | 703 | | | +-------------------+ | | | 704 | +-----+--------|-----------------|-------+------+ | 705 | | | | | | 706 | | | | | | 707 | +-----------------------------------------------+ | 708 +---| Information Centric Network(ICN) |-----+ 709 +-----------------------------------------------+ 711 Figure 5: The ICN-IoT Service Middleware 713 Data Re-distribution Service: The (re)distribution service delivers 714 data from their sources to different locations for better 715 accessibility. These services will be directly supported by the ICN. 716 Firstly, ICN can cache data/content on forwarding ICN routers, and 717 secondly, these routers will be added to the NRS service so that 718 requests for the cached data/content can be forwarded to them, thus 719 reducing the data/content retrieval latencies. 721 Figure 5 shows how the ICN-IoT middleware services (identified in 722 Figure 4) integrated into the ICN infrastructure. The components of 723 the IoT middleware can be described with respect the services 724 identified before. 726 o Realizing Data discovery Service. Two tasks are involved in 727 achieving this. First is a way to name services/content/devices 728 of interest within the IoT application scope. Each network entity 729 that is registered at the Name Assignment Service (NAS) has both a 730 human readable name and a unique identifier (UID). The human 731 readable name includes semantic key words that characterize the 732 entity. Once the entities are named, applications based on its 733 policy requirements make it accessible considering access control 734 policies. To enable accessibility a discovery function is 735 required, which is enabled through NAS. Figure 5 shows an example 736 with sensor SID and service CID. Both SID and CID are published 737 to the searchable name space through NAS, which can be efficiently 738 discovered later by the applications. 740 o Realizing Data processing Service. ICN-IoT uses the in-network 741 storage and computing capability to cache and execute data 742 processing service, such as a context reasoning service, 743 traditionally implemented on overlay servers. Having the context 744 reasoning service within the network, however, requires additional 745 computing capabilities offered by routers or separate computing 746 facilities in the network. In Figure 5, the service, identified 747 by CID, is cached and executed on an ICN router. 749 o Realizing Data (re)distribution Service. ICN-IoT performs 750 distribution or re-distribution of IoT data and service through 751 its native support of in-network caching and multicast based on 752 identity based routing. 754 4.3. ICN-IoT Scenario 756 We will use a context-aware IoT application as an example from 757 UbiCab[8] to demonstrate how IoT middleware service is enabled inside 758 the proposed ICN-IoT core network. This example is based on 759 MobilityFirst architecture [7] which is based on secured names and 760 off-path name resolution infrastructure. 762 The example is stated as: "James walks on NYC streets and wants to 763 find an empty cab closest to his location". In this example, we 764 assume that James and taxi drivers have sensors on their phones, 765 providing GPS location information as data. The context of this 766 application is the relative locations of James and taxi drivers. A 767 context service, as an IoT middleware, is needed to bridge sensors 768 (providing GPS location) and the application (phone call program) 769 automatically. 771 We use a linked-data inspired approach to implement the middleware 772 service for this location aware context. First, a company 773 GPSlocation.com offers this service at http://GPSlocation.com/ 774 nearbyCab, implemented in an RDF graph shown in Figure 7. This 775 context service has two attributes to describe itself, tagged as cab 776 and location. A taxi driver can query this RDF graph and joins as a 777 member of the service by adding a link to its own URI http://NYCcab 778 .com/cab1 in the RDF graph with a predicate "a:member". The sensor 779 data, taxi driver's GPS location, is linked to taxi driver's URI with 780 a predicate "a:location" and the value is updated by his phone 781 periodically. he database containing this RDF graph must be 782 searchable by users in a searchable space, which we refer as IoT 783 resource space in Figure 6. 785 ______________ ______ 786 { } +SID-(Sensor) 787 +--------------------->{IoT Name Space} | ------ 788 | +---------------->{______________}<--------------------+ 789 | | | | | 790 |Lookup _____________________|_____________________|_ | 791 |Service|Add-on Protocols(Name Assignment Service, | Publish 792 | | | Caching)) | (CID) 793 | __|__ +=============================================+ | 794 ||Apps ||Baseline ICN Protocols(Transport,Routing,Name| | 795 ||(ICN || Resolution) | | 796 ||Host)||_____________________________________________| ___|_______ 797 ||_____| | |Overlay IoT| 798 | | Get ____________|____________ |Middleware | 799 | +--CID-----{ } |Service | 800 | _______ { ICN Core Network }----CID------>|(ICN Host) | 801 | |Readers| {_________________________} |___________| 802 +---|(ICN | | | 803 |Host) | Send _____|_______ 804 +=======+ (SID) |Caching IoT | 805 {Local } | |Middleware | 806 {IoT }-------+ |Service | 807 {Network} |(ICN Storage)| 808 {_______} |_____________| 810 Figure 6: ICN-IoT Data and Services 812 |8438435780327523478532,4530| a:member---->|http://NYCcab.com/cab1| 813 UID | 814 | |a:member--->|http://NYCcab.com/cab2| 815 | || | | 816 |http://GPSLocation.com/nearbtCab| |UID_2| a:location 817 |Cab| | |Location|-a:attribute | 818 a:Pubkey | +---->|Cab| |GPSvalue| 819 | | | 820 | | | 821 |8438435780327523478532| a:attribute-->|Location|--->Linked-data 823 Figure 7: Location context service in RDF 825 In ICN-IoT, we also add an additional 3-tuple or triple in the RDF 826 graph with a predicate "UID". CID is assigned to the context service 827 and UID_2 is assigned to cab2. 829 This context service can also run as an overlay to the Internet. 830 Taxi drivers and passengers can directly call the URI of the context 831 service to join the membership and get a nearby cab, respectively. 832 As an Internet overlay, the location context service is subject to 833 longer delay due to demands are overloaded or unbalanced. 835 In this example, since the context service is implemented using an 836 RDF graph, it can be cached on ICN routers in a similar way to 837 caching content. This RDF graph can be updated by taxi drivers by 838 joining membership, current GPS location etc, since the context 839 service is UID identified it can be routed efficiently by the ICN 840 routers. The utility of such information is determined by specific 841 application requirements. 843 The application scenario is comprised of the following steps, 844 illustrated by Figure 8. 846 o Name Assignment. The owner of the context service publishes its 847 CID and the service description (RDF graph of Figure 7) through 848 ICN-IoT NAS function, running on both service host and routers, to 849 a searchable Link-data space. 851 o NRS Update. When the context service connects to the ICN network, 852 the access router calls NRS update to provide a UID to network 853 address mapping. 855 o Service Discovery. Taxi driver or James can find CID through an 856 RDF query requesting services with tags "location" and "cab". 858 o Service Request. Taxi driver makes a service request to CID with 859 an RDF query to join the service membership. 861 o Routing and GNRS Lookup. The service request toward CID is routed 862 to the NA_c, obtained from a NRS lookup. 864 o Service Request Redirection. James makes a service request to CID 865 with an RDF query to match GPS location to a nearby taxi. James' 866 request to CID is redirected to UID_2, the driver of cab2. 868 Note that in this example, no CDN overlay is needed to support multi- 869 homing, multicasting for a location context service because these are 870 embedded in the ICN core network. 872 As usual, the benefit of caching is more significant for location 873 dependent services. In our example, it is best to have the 874 middleware service being offered at a server close to taxi drivers 875 and passengers so that the traffic can be localized with lower 876 latency. 878 __________ _______ _______ 879 { } |Caching| |NRS | 880 {RDF graphs}-RDF query-|Service| |Service| 881 {__________} |_______| |_______| 882 ^ | 883 | NRS 884 Caching Lookup 885 +----------+ +-----+ 886 | | 887 | | Name Assignment 888 _______ Service _|________________| NRS _______________ 889 |Taxi |Discovery{ | } Update | | 890 |Drivers|-------->{ICN-IoT CoreNetwork}<------------|GPSLocation.com| 891 |_______|Request {_|_________________}-+ |_______________| 892 ^ | | 893 _________ Service | NAS | 894 |Passenger|Discovery| Discovery | 895 |James |---------+ | _______ |________________ 896 |_________| | |NAS | { } 897 +->|Service| {Linked-Data Space} 898 |_______| {_________________} 899 | ^ 900 | | 901 +---RDF Query--+ 903 Figure 8: Location context application scenario 905 Traditionally, a service provider has to buy edge computing service 906 from content distribution network (CDN); recently, cloud computing 907 offers another alternative to deploy a distributed service. The 908 native support of caching in ICN provides with the ability to 909 distribute a service directly through core network routers. This 910 option may not be suitable for heavyweight service requiring a high 911 end web server. Nevertheless, it could be particularly useful for 912 lightweight IoT middleware service. As shown in our example, when 913 the context service is implemented in an RDF graph, caching a service 914 is as simple as caching a data and service processing is as simple as 915 a database query. The algorithms behind cache replacement can also 916 be similar to what for data caching. 918 Once, for example, the service CID is cached, any request to CID is 919 intercepted by the ICN router. In our example, when it is a request 920 from taxi driver, it must contain an RDF query requesting either join 921 membership or an updated GPS location. The computing layer of ICN 922 router runs a SPARQL engine to interpret the RDF query and makes a 923 corresponding database operation. When it is a request from James, a 924 passenger, it must contain an RDF query containing its own GPS 925 location and looking for the ID of a taxi with a GPS location nearby. 927 Another benefit of ICN caching is that there is no need for end-to- 928 end connectivity between the requester and the location context 929 server, if the service is currently cached in an accessible ICN 930 router. This is especially useful for ad-hoc or DTN use cases, where 931 the application network can be dynamically formed and isolated for a 932 period of time. 934 This UbiCab example has low data rate. Next imagine a context 935 service requires high data rate, for example, a person wants to see 936 snapshots of the street nearby. And these snapshots are uploaded by 937 the people on the street. Assuming every access network can get 938 enough number of people uploading pictures, it is best for the 939 network operator to cache the pictures as close to edge as possible. 941 Through this location context service example, we can see ICN-IoT 942 offers significant native supports for IoT data and services to be 943 visible, routable, cacheable and executable in the core network of 944 future Internet architecture. 946 5. Informative References 948 [1] Cisco System Inc., CISCO., "Cisco visual networking index: 949 Global mobile data traffic forecast update.", 2009-2014. 951 [2] Shafig, M., Ji, L., Liu, A., Pang, J., and J. Wang, "A 952 first look at cellular machine-to-machine traffic: large 953 scale measurement and characterization.", Proceedings of 954 the ACM Sigmetrics , 2012. 956 [3] The European Telecommunications Standards InstituteS, 957 ETSI., "http://www.etsi.org/.", 1988. 959 [4] Constrained RESTful Environments, CoRE., 960 "https://datatracker.ietf.org/wg/core/charter/.", 2013. 962 [5] Ghodsi, A., Shenker, S., Koponen, T., Singla, A., 963 Raghavan, B., and J. Wilcox, "Information-Centric 964 Networking: Seeing the Forest of the Trees.", Hot Topics 965 in Networking , 2011. 967 [6] Dong, L., Zhang, Y., and D. Raychaudhuri, "Enhance Content 968 Broadcast Efficiency in Routers with Integrated Caching.", 969 Proceedings of the IEEE Symposium on Computers and 970 Communications (ISCC) , 2011. 972 [7] NSF FIA project, MobilityFirst., 973 "http://www.nets-fia.net/", 2010. 975 [8] Kim, B., Lee, S., Lee, Y., Hwang, I., and Y. Rhee, 976 "Mobiiscape: Middleware Support for Scalable Mobility 977 Pattern Monitoring of Moving Objects in a Large-Scale 978 City.", 2011. 980 Authors' Addresses 982 Prof.Yanyong Zhang 983 WINLAB, Rutgers University 984 671, U.S 1 985 North Brunswick, NJ 08902 986 USA 988 Email: yyzhang@winlab.rutgers.edu 990 Prof. Dipankar Raychadhuri 991 WINLAB, Rutgers University 992 671, U.S 1 993 North Brunswick, NJ 08902 994 USA 996 Email: ray@winlab.rutgers.edu 998 Ravi Ravindran 999 Huawei Technologies 1000 2330 Central Expressway 1001 Santa Clara, CA 95050 1002 USA 1004 Email: ravi.ravindran@huawei.com 1005 Guoqiang Wang 1006 Huawei Technologies 1007 2330 Central Expressway 1008 Santa Clara, CA 95050 1009 USA 1011 Email: gq.wang@huawei.com