ICN-IoT and its Evaluation

Transcription

1 ICN-IoT and its Evaluation Sugang Li, Yanyong Zhang, Dipankar Raychaudhuri (WINLAB, Rutgers University) Ravishankar Ravindran, GQ Wang (Huawei Research Center)

2 Phase I: ICN-IoT Architecture

3 IoT Architectural Requirements Naming Device centric, persistent against mobility/contextual changes Scalability Scale to billions on devices, name/locator split, local/global services, resolution infrastructure, efficient context update Resource Constraints Compute/Storage/Bandwidth constrains, protocols being application/context aware, infrastructure support (edge computing, polling on demand) Traffic Characteristics Separate local versus wide area traffic based on application logic ; many-tomany (multicasting/anycasting) Contextual Communication Key to create several meaningful IoT services Handling Mobility Fundamental Design Criteria

4 IoT Architectural Requirements Storage and Caching Leverage caching as much as possible while being sensitive to application/service producer requirements Security and Privacy Takes precedence over any communication paradigm (ICN or not) Communication Reliability Application centric (e.g. Health) Self-Organization Ability to self-organize in ad-hoc/infrastructure setting to discover resources (services/content/users/devices) and Communicate. Ad hoc and Infrastructure Mode Seamless transitions between the two worlds, user/application driven.

5 Legacy IoT systems Silo IoT Architecture: (Fragmented, Proprietary), e.g. DF-1, MelsecNet, Honeywell SDS, BACnet, etc Fundamental Issues : Co-existence, Inter-operability, Service level interaction A small set of pre-designated applications. Moving towards Internet based service connectivity (ETSI, One M2M Standards). Vertically Integrated

6 State of the Art Overlay Based Unified IoT Solutions Coupled control/data functions Centralized and limits innovation Bottleneck Point IoT Gateway API Smart Homes Sensors Publishing Publishing Internet Routers IoT Server IoT Gateway API Smart Grid Publishing Subscribing IoT Applications IoT Gateway API Smart Healthcare Sensors Sensors

7 State of the Art Weaknesses of the Overlay-based Approach Naming: Resources visible at Layer 7 Mobility : Inherited by IP based communication Scalability: Merges control + forwarding path in central servers (bottleneck) Resource constraints : Network insensitive to device constraints. Traffic Characteristics : Overlaid support for Multicasting (in-efficient & complexity)

8 Proposed ICN-Centric Unified IoT Platform IoT Smart Home Management IoT Smart Transport Management IoT Smart Healthcare Management ICN App ICN Smart Home Smart Healthcare Home -1 Home -2 Smart Transport App D2D App ICN ICN ICN has a potential to influence this emerging area of IoT as a unified platform for interaction between Consumers, IoT ASPs, Network Operators. Potential ICN as Network layer in the edges? Potential technology to glue heterogeneous applications/services/devices (CIBUS) Contextualized-Information Centric Bus [SIGGCOMM, ICN-HomeNet demo 2013]

9 Proposed ICN-Centric Unified IoT Strengths of ICN-IoT Naming Ease to aggregate, self-certifying Scalability Platform Name-Location Split, Localizes Communication where required Resource Constraints Application aware network layer Context-aware communications Adaptation at Network Level (at all levels) Seamless mobility handling Flexible Name Resolution (Late Binding)

10 Proposed ICN-Centric Unified IoT Platform Data Storage Enables Edge Computing/Multicasting Security and privacy Flexible Security (User/Device/Service/Content Level) Communication reliability Adaptable to Best Effort to DTN Ad hoc and infrastructure mode De-coupling of Application from Transport Layer

11 Proposed ICN-Centric Unified IoT Platform Architecture Functional Components: Name space mgmt. Resource Discovery Service Context and Policies Communication Reliability Scalable Name Resolution System Mobility Multihoming Multicast Caching/Storage Multicasting In-network Computing

12 Proposed ICN-Centric Unified IoT Platform The ICN-IoT Service Middleware Layers:

13 Proposed ICN-Centric Unified IoT Platform ICN-IoT Data and Services Realization

14 Phase II: A Simulation Based Comparison of NDN-IoT and MF-IoT

15 Two types of packet - Interest & Data Three data structure -Forwarding Information Base (FIB) - Pending Interest Table (PIT) -Content Store (CS) NDN Overview

16 MobilityFirst Overview Name Certification & Assignment Service NCS App 1 App 2 App 3 App 4 Socket API E2E TP1 E2E TP2 E2E TP3 E2E TP4 Optional Compute Layer Plug-In A Global Name Resolution Service GNRS GUID Service Layer Narrow Waist MF Routing Control Protocol GSTAR Routing Hop-by-Hop Block Transfer MF Inter-Domain Switching Option IP Link Layer 1 (802.11) Link Layer 2 (LTE) Link Layer 3 (Ethernet) Link Layer 4 (SONET) Link Layer 5 (etc.) Control Plane Data Plane

17 Device Discovery-NDN Devices come pre-configured with 1) an NDN name following the well-knows convention for device discovery 2) A manufacturer-assigned public key with the key finger print like today s serial number 3) A shared secret that will be used to authorize initial configuration

18 Device Discovery-NDN Device bootstrap by registering names of a known form out of the box : /ndn/lighting/devices/<manufacturer>/<type_components>/<serial> Ex. /ndn/lighting/devices/philips/colorblast/00-16-eb-05-fb-48 The Configuration Manager periodically express discovery interests on a broadcast channel to which the devices are connected using a known convention: /ndn/lighting Using an authenticated interest application-specific names are then assigned by the CM, which authenticates with the fixture via a shared secret passed out-ofband : /<root>/<building>/<room>/<lights>/<fixture_path> /ndn/ucla.edu/melnitz/1471/lights/west_wall/wash_down

19 Device Discovery- MobilityFirst 1.Add New Sensor S S S Sink/Env. Sensing 2.Insert MF Router 3.Lookup Environment Sensing: router@room1: 1122 Configuration Service GNRS Server Mapping After Insert Environment Sensing Service GUID Sensor GUID Router 1@room1 Router GUID 1122 Attached GUID

20 Data Pub/Sub -- NDN Content-oriented Pub/Sub system (COPSS) - Push based multicast module with the pull based NDN architecture. - Rendezvous nodes - Content Descriptor COPSS is for video streaming, less efficient in IoT scenario.

21 Data Pub/Sub -- MF Centralized server for administrative purpose Data transport via MF router only IoT Server S Sink Send To Subscription GUID 456 MF App 123 Routing Table 789 Source GUID Subscription GUID App GUID

22 ICN-IoT Use Cases Smart Campus Stationary IoT : Building management system (BMS) Control complex ecosystems such as climate control, security monitoring, smoke detection, etc Heterogeneous communication protocols Complex middleware required Dynamic IoT : School Bus System

23 Building Management System Sensor Sensor a a Fixture /Interface... Sink Network MF/NDN Sink Control Service Environment Monitoring Thermostat /Interface Occupancy Monitoring Web Portal

24 BMS-Evaluation 1. Based on MF-sim and NDN-sim 2. Based on campus building floor plan Sink Router Actuator BMS server

25 BMS-Evaluation 1.Average Data Report Delay On Server 2. Average delay from sink to actuator 3. Total PIT size in the network 4. Goodput at the server

26 School Bus Vehicle to infrastructure (V2I) Update sensor data on bus to the server Receive notification from the administrator Handling Mobility GPS Mobile Data Terminal(MDT) AP Location/Seat Sensor data Peer Bus(e.g. Route A) School Bus Server web

27 School Bus Evaluation 1. Packet success rate against speed 2. Control overhead

28 Phase III: Several IoT Systems/Applications at Winlab

29 OWL

30 Owl Application: Status and notification

31 Application: Laboratory Animal Monitoring

32 Existing MobilityFirst Platform Click-based MF Router - Storage-aware routing (GSTAR) - Name resolution server (GNRS) - Reliable hop-by-hop link transport (Hop) Android/Linux MF Protocol Stack - Network API - Hop - Dual homing (WiFi/WiMAX) Native, user-level implementation on Android runtime MF Router WiFi AP MF Router MF Router 2014/12/16 Huawei project WiMAX BTS 33

33 M2M Server GNRS Server App 1 MF Router 2 MF Host Stack Sensor Gateway MF Router 1 MF Host Stack App 2 MF Router 2 MF Host Stack

34 M2M Sequence

35 Sensor Gateway MF Hoststack M2M Server MF Router 1 GNRS Server MF Router 2 MF Hoststack APP Attach to the router Insert the GUID of the Hoststack Insert the GUID of the Hoststack Attach to the router Request for dst GUID Dst GUID MF Send ( Sensor Data ) Message forward Message forward Message forward MF Receive (Sensor Data)

36 37 Questions & Answers