ICN-IoT and its Evaluation Sugang Li, Yanyong Zhang, Dipankar - - PowerPoint PPT Presentation

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

Internet

Smart Homes

Publishing Subscribing

Sensors Routers IoT Server IoT Applications IoT Gateway

Publishing

Smart Grid Sensors IoT Gateway Smart Healthcare Sensors IoT Gateway

API API API

Publishing

Bottleneck Point

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

ICN

Smart Home

Home -1

Home -2 D2D Smart Transport Smart Healthcare

App

ICN

IoT Smart Home Management IoT Smart Transport Management IoT Smart Healthcare Management

App

ICN

App

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.
• Resource Discovery
• Service Context and

Policies

• Communication

Reliability

• Scalable Name

Resolution System

• Mobility
• Multihoming
• Multicast
• Caching/Storage
• Multicasting
• In-network Computing
• Architecture Functional Components:

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

IP Hop-by-Hop Block Transfer

Link Layer 1 (802.11) Link Layer 2 (LTE) Link Layer 3 (Ethernet) Link Layer 4 (SONET) Link Layer 5 (etc.)

GSTAR Routing MF Inter-Domain E2E TP1 E2E TP2 E2E TP3 E2E TP4 App 1 App 2 App 3 App 4 GUID Service Layer

Narrow Waist

GNRS MF Routing Control Protocol NCS

Name Certification & Assignment Service Global Name Resolution Service

Data Plane Control Plane

Socket API

Switching Option

Optional Compute Layer Plug-In A

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

Service GUID 67890

Environment Sensing

Sensor GUID 12345 …………… Router GUID 1122

Router 1@room1

Attached GUID …………… 67890 12345 …………… Configuration Service GNRS Server

Environment Sensing: 67890 router@room1: 1122

3.Lookup

Sink/Env. Sensing

S S S

1.Add New Sensor

12345

MF Router

2.Insert

Mapping After Insert

Device Discovery- MobilityFirst

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

MF

Sink

123 789

Send To Subscription GUID 456

App IoT Server

Routing Table 789 … 456

S

Source GUID Subscription GUID App GUID 123 456 789

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

a Network MF/NDN Control Service Environment Monitoring Occupancy Monitoring

Fixture /Interface Thermostat /Interface

…........ Sensor Sink a Sensor Sink …………………… Web Portal

BMS-Evaluation

Sink Router Actuator

13 14 15 16 17

BMS server

• 1. Based on MF-sim and NDN-sim
• 2. Based on campus building floor plan

BMS-Evaluation

1.Average Data Report Delay On Server

• 2. Average delay from sink to actuator

4 . Goodput at the server

• 3. Total PIT size in the network

School Bus

• Vehicle to infrastructure (V2I)
• Update sensor data on bus to the server
• Receive notification from the administrator
• Handling Mobility

GPS

Peer Bus(e.g. Route A) Mobile Data Terminal(MDT)

web School Bus Server AP

Location/Seat Sensor data

School Bus Evaluation

• 1. Packet success rate against

speed

• 2. Control overhead

Phase III: Several IoT Systems/Applications at Winlab

OWL

Owl Application: Status and notification

Application: Laboratory Animal Monitoring

2014/12/16 Huawei project

Existing MobilityFirst Platform

33

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)

WiMAX BTS WiFi AP

Native, user-level implementation

• n Android

runtime

MF Router

MF Router MF Router

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

M2M Sequence

Sensor Gateway

M2M Server GNRS Server MF Router 1 APP

Request for dst GUID Dst GUID

MF Hoststack MF Hoststack

Attach to the router Insert the GUID of the Hoststack

MF Router 2

Insert the GUID of the Hoststack Attach to the router MF Send ( Sensor Data ) Message forward Message forward Message forward MF Receive (Sensor Data)

37

Questions & Answers