ICN-IoT and its Evaluation

Sugang Li, Yanyong Zhang, DipankarRaychaudhuri (WINLAB, Rutgers University)

Ravishankar Ravindran, GQ Wang (Huawei Research Center)

Phase I: ICN-IoT Architecture

IoT Architectural RequirementsNaming

• 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 ArtWeaknesses 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

ICNApp

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 IoTPlatform

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 IoTPlatform

Data StorageEnables Edge Computing/Multicasting

Security and privacy Flexible Security (User/Device/Service/Content Level)

Communication reliabilityAdaptable to Best Effort to DTN

Ad hoc and infrastructure modeDe-coupling of Application from Transport Layer

Proposed ICN-Centric Unified IoTPlatform

• 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 IoTPlatform

• The ICN-IoT Service Middleware Layers:

Proposed ICN-Centric Unified IoTPlatform

• 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 WaistGNRS

MF RoutingControl Protocol

NCSNameCertification& AssignmentService

Global NameResolutionService

Data PlaneControl Plane

Socket API

SwitchingOption

Optional ComputeLayer

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

ServiceGUID

67890Environment Sensing

SensorGUID

12345

……………

Router GUID

1122Router 1@room1

Attached GUID

……………

67890

12345

……………

ConfigurationService

GNRS Server

Environment Sensing:67890

router@room1:1122

3.Lookup

Sink/Env. Sensing

S

S

S

1.Add New Sensor12345

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

MFSink

123 789

Send To Subscription GUID 456 App

IoT Server

RoutingTable

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

NetworkMF/NDN

Control Service

Environment Monitoring

OccupancyMonitoring

Fixture/Interface

Thermostat/Interface

…........

Sensor

Sink

a

Sensor

Sink……………………

Web Portal

BMS-Evaluation

Sink

Router

Actuator

13 14

1516

17

BMS server

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

BMS-Evaluation

1.Average Data Report Delay On Server2. Average delay from sink to actuator

4 . Goodput at the server3. 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

SchoolBusServer

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 on Android runtime

MF Router

MF Router

MF Router

MF Router 1

MF Router 2

MF Router 2

M2M Server

GNRSServer

SensorGateway

MF Host Stack

App 2

MF Host Stack

App 1

MF Host Stack

M2M Sequence

Sensor Gateway

M2M Server GNRS ServerMF

Router 1APP

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