ICN-IoT and its Evaluation Sugang Li, Yanyong Zhang, Dipankar Raychaudhuri (WINLAB, Rutgers University) Ravishankar Ravindran, GQ Wang (Huawei Research Center)
Phase I: ICN-IoT Architecture
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-to- many (multicasting/anycasting) Contextual Communication • Key to create several meaningful IoT services Handling Mobility • Fundamental Design Criteria
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.
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
State of the Art • Overlay Based Unified IoT Solutions • Coupled control/data functions • Centralized and limits innovation Bottleneck Point Subscribing Publishing IoT Server Publishing IoT IoT Applications Publishing Gateway Internet API IoT Smart Homes Routers Gateway API IoT Smart Healthcare Sensors Gateway API Smart Grid Sensors Sensors
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)
Proposed ICN-Centric Unified IoT Platform IoT Smart IoT Smart IoT Smart Home Transport Healthcare Management Management Management ICN App Smart Smart Healthcare Home ICN Smart Transport Home -2 App Home -1 App ICN D2D 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 ]
Proposed ICN-Centric Unified IoT Platform Strengths of ICN-IoT Naming Ease to aggregate, self-certifying Scalability 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)
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
Proposed ICN-Centric Unified IoT Platform • Name space mgmt. • Architecture Functional Components: • Resource Discovery • Service Context and Policies • Communication Reliability • Scalable Name Resolution System • Mobility • Multihoming • Multicast • Caching/Storage • Multicasting • In-network Computing
Proposed ICN-Centric Unified IoT Platform • The ICN-IoT Service Middleware Layers:
Proposed ICN-Centric Unified IoT Platform • ICN-IoT Data and Services Realization
Phase II: A Simulation Based Comparison of NDN-IoT and MF-IoT
NDN Overview • Two types of packet – - Interest & Data • Three data structure – -Forwarding Information Base (FIB) - Pending Interest Table (PIT) -Content Store (CS)
MobilityFirst Overview App 1 App 2 App 3 App 4 Socket API Name NCS Certification & Assignment E2E TP1 E2E TP2 E2E TP3 E2E TP4 Service Optional Compute Layer Plug-In A Global Name GNRS Resolution GUID Service Layer Service Narrow Waist MF Routing GSTAR Routing MF Inter-Domain IP Control Protocol Switching Hop-by-Hop Block Transfer Option Link Layer 1 Link Layer 2 Link Layer 3 Link Layer 4 Link Layer 5 (802.11) (LTE) (Ethernet) (SONET) (etc.) Control Plane Data Plane
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
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-of- band : /<root>/<building>/<room>/<lights>/<fixture_path> /ndn/ucla.edu/melnitz/1471/lights/west_wall/wash_down
Device Discovery- MobilityFirst 1.Add MF Router S New Sink/Env. S Sensor Sensing 12345 2.Insert S 3.Lookup Environment Sensing: 67890 Configuration router@room1: 1122 Service GNRS Server Mapping After Insert Attached Sensor GUID GUID Router Service GUID GUID …………… 12345 Environment Router 67890 1122 67890 Sensing …………… 1@room1 12345 ……………
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.
Data Pub/Sub -- MF • Centralized server for administrative purpose • Data transport via MF router only IoT Server Send To Subscription MF App GUID 456 Sink S 789 123 Routing Table 789 Source GUID Subscription GUID App GUID … 123 456 789 456
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
Building Management System Sensor Sensor a a …………………… Sink Sink Control Service Fixture /Interface Environment …........ Network Monitoring MF/NDN Thermostat Occupancy /Interface Monitoring Web Portal
BMS-Evaluation 1. Based on MF-sim and NDN-sim 2. Based on campus building floor plan Sink Router Actuator 13 14 15 16 17 BMS server
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
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 School Bus(e.g. Bus Route A) Server web
School Bus Evaluation 1. Packet success rate against 2. Control overhead speed
Phase III: Several IoT Systems/Applications at Winlab
OWL
Owl Application: Status and notification
Application: Laboratory Animal Monitoring
Existing MobilityFirst Platform Click-based MF Router Android/Linux MF Protocol Stack - Storage-aware routing (GSTAR) - Network API - Hop - Name resolution server (GNRS) - Dual homing (WiFi/WiMAX) - Reliable hop-by-hop link transport (Hop) Native, user-level implementation on Android runtime WiFi AP MF Router MF Router MF Router 2014/12/16 Huawei project 33 WiMAX BTS
M2M GNRS Server Server App 1 MF Host MF Router 2 Stack MF Router 1 Sensor Gateway MF Host Stack App 2 MF Router 2 MF Host Stack
M2M Sequence
Sensor MF MF MF MF M2M Server GNRS Server APP Gateway Hoststack Router 1 Router 2 Hoststack Attach to the router Attach to the router Insert the GUID of the Insert the GUID of the Hoststack Hoststack Request for dst GUID Dst GUID MF Send ( Message forward Sensor Data ) Message forward MF Receive (Sensor Message forward Data)
Questions & Answers 37
Recommend
More recommend
