1

NGMN Verticals Meeting

IoT Requirements & Architecture

Feb 29, 2016

Rutgers, The State University of New Jersey

www.winlab.rutgers.edu

Contact: Professor D. Raychaudhuri, Director

ray@winlab.rutgers.edu

WINLAB

2

IoT Devices &

Applications

WINLAB 3

Ultra-Low Power Active RFID (WINLAB, 2010)

Micro controller

Radio

Battery

Antenna

Transmit-Only TO-PIP(2013)

Classic TelosB (2004)

• Low-Power “Transmit-Only” Active RFID Technology for IoT applications

WINLAB

Augmented Reality Tags (WINLAB, 2014) • RFID tag + optical detector for head-mounted AR/VR applications

WINLAB

Wireless Smart Meters (Privacy Study, WINLAB 2012)

Analyzed existing

meters with USRP

software radio

Meters broadcast every 30s

Significant privacy/security weaknesses as deployed

WINLAB

Pedestrian Safety Services (WINLAB prototype 2015)

• Warning for distracted pedestrians to look up as

they walk off from a sidewalk to street

• Profiles surface gradient using shoe mounted

inertial sensors

• Uses the ground profiles to detect transitions from

sidewalk to street via ramps and curbs Researchers at Rutgers University made an

Android app that senses when a texting

pedestrian steps into a street,

warning the person to look up. Photo:

Geoffrey A. Fowler/The Wall Street Journal

WINLAB

OWL Platform & Pipsqueak Sensor (WINLAB/InPoint prototype, 2012)

10+ year ultra-low

energy wireless sensor

Reliable delivery in

challenging radio

environments

Multiple sensing

capabilities

Owl Platform Software Stack

Scalable, distributed

software architecture

IoT software stack

targeting data streams

from wireless sensors

WINLAB

Lab Animal Monitoring Application (Rutgers deployment, 2014)

9-month installation

Improved staff

workflow

Reduced problem

response times

Supportive CMR

management and

faculty

Product

requirements

developed

WINLAB

OWL User Interface for Building

Monitoring Application (WINLAB, 2014)

2015 Huawei Strategy and Technology

Workshop

10

IoT Requirements

WINLAB

IoT Architectural Requirements

Next-Generation Network

Related Icons:

Sensors & Actuators IoT End-Users

IoT Application Providers

Device Naming,

Device to Service

Binding

Service

Subscriptions

Context Query (Pull)

(e.g. device type,

function, location,

other attributes)

Pub-Sub Data

Dynamic Name

Resolution Multicast Query

to specified group

Service

Discovery

Service Name

Advertisements

Future mobile networks should be designed to natively

support anticipated IoT communication modes

http://uxrepo.com/icon/home-by-dripiconshttps://www.iconexperience.com/o_collection/icons/?icon=industrial_robot&color_style=green_dark_greyhttps://www.iconexperience.com/o_collection/icons/?icon=industrial_robot&color_style=green_dark_greyhttps://www.iconexperience.com/o_collection/icons/?icon=industrial_robot&color_style=green_dark_greyhttps://www.iconexperience.com/o_collection/icons/?icon=industrial_robot&color_style=green_dark_greyhttps://www.fitbit.com/storehttp://uxrepo.com/icon/home-by-dripicons

WINLAB

IoT Architectural Requirements

Scalability Scale to billions of devices; low control overhead

Access Technology Neutral Wireless access (WiFi, 6LoWPAN, LTE, 5G..) as “plug-in”

Mobility Device and cloud service mobility

Device Limitations Power/BW limited; sleep modes/disconnected operation

Performance Low or bounded latency

Reference: IETF Draft, Feb 2016, Zhang et al, ICN Based Architecture for IoT

WINLAB

IoT Architectural Requirements

(cont.)

Naming, Dynamic Name Resolution Device/application centric, persistent during mobility

Multicast/Gathercast Modes Efficient multicast query and aggregated “gathercast” response

Contextual Message Delivery IoT devices addressable by context (location, state, etc.)

Pub/Sub Modes Support for both push and pull modes for IoT data/control

Reference: IETF Draft, Feb 2016, Zhang et al, ICN Based Architecture for IoT

WINLAB

IoT Architectural Requirements

(cont.)

Security and Privacy Including support for low-end IoT devices

Communication Reliability Application specific (e.g. Health, Transportation)

Storage and Caching In-network storage for DTN and content cache services

Self-Organization & Discovery Ability to self-organize and discover resources (services/devices) and

communicate

Ad hoc and Infrastructure Modes Seamless transitions between the two worlds

Reference: IETF Draft, Feb 2016, Zhang et al, ICN Based Architecture for IoT

15

IoT Architecture

Considerations

WINLAB

Legacy IoT Systems

Silo IoT Architecture (Fragmented, Proprietary):

e.g. DF-1, MelsecNet (Mitsubishi Electric), SDS (Honeywell), BACnet,

Bluetooth Low Energy, etc

Vertically Integrated

WINLAB

State of the Art in IoT Networks Overlay Based Unified IoT Solutions (i.e., OpenIoT, AllJoyn)

Disadvantages

Lack of naming transparency between systems which hinders efficient data/service

discovery

No general purpose network-layer support for essential services such as pub/sub,

multicast, mobility and context-aware delivery

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

WINLAB

Next-Gen Network as 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

• Next-Gen (Mobile) Network has the potential to enable “flat” IoT solution which

works across multiple applications, services & access technologies

• Solutions such as information-centric networks (ICN) have been proposed and

are currently under evaluation

NGN

NGN

NGN

NGN

WINLAB

A Typical ICN-IoT System

…

…...

IoT Aggregator (e.g. Raspberry Pi, Smart Phone, nest thermostat) Hardware information for attached sensors

Service types of the attached sensors

Sensor names for ICN-enabled sensors

Information about sensors attached to peer

aggregators

Local Service Gateway (e.g., AP, local gateway) Full information of IoT resources in

the local networks (including sensor

service types)

ICN Network

APP—Website, Mobile APP:

MF Data Consumer

Radio-specific Interface Adaptation

ICN

Adaptor

ZigBee, TO,

6LoWPAN,

BLE,etc

ICN Non-

ICN

ICN

Edge Service

Router Service Controller

Edge Service

Router

Service

Provider

ICN-NNI

ICN/

Non-ICN

Data

Center

Sensors (e.g., RFID, temperature sensors) Sensor hardware information

Sensor names for ICN-enabled sensors

IoT Server Names and the service types that are

exposed to the server

Subscription memberships

Reference: IETF Draft, Feb 2016, Zhang et al, ICN Based Architecture for IoT

20

MobilityFirst “Named-Object”

Architecture for 5G/IoT

WINLAB

MobilityFirst Architecture: Key Features

Routers with Integrated

Storage & Computing Heterogeneous

Wireless Access

End-Point mobility

with multi-homing In-network

content cache

Network Mobility &

Disconnected Mode

Hop-by-hop

file transport Edge-aware

Inter-domain

routing

Named devices, content,

and context

11001101011100100…0011

Public Key Based

Global Identifier (GUID)

Storage-aware

Intra-domain

routing

Service API with

unicast, multi-homing,

mcast, anycast, content

query, etc.

Strong authentication, privacy

Ad-hoc p2p

mode

Human-readable

name

Connectionless Packet Switched Network

with hybrid name/address routing

http://www.radiolabs.com/images/products/wireless-laptop-antenna.jpg

WINLAB

MF Architecture: GUIDs & Name Resolution

Globally unique identifiers

(GUID) used to define all

network-attached objects

Key design choice: flat

identifier vs. hierarchical

semantic identifier….

MobilityFirst uses a flat public

key as the GUID

NDN uses a hierarchical

content descriptor

Globally Unique Flat Identifiers

Global Name Resolution Service

Host Naming

Service

Content

Naming

Service

IoT

Naming

Service

Integrated

storage and

computing

Routers with

integrated storage

and computing

Hop-by-hop

transport

Media file M

IoT Object

John’s

laptop Sue’s phone

WINLAB

MobilityFirst Protocol Stack

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

WINLAB

Network Routing on GUID

(MobilityFirst)

Sensing Functionality

(temperature)

Actuating Functionality

(air conditioning)

Sensing Service

GUID

Actuating Service

GUID

Application

Application Service (subscribe, publish, …)

GUID

Application Service (subscribe, publish, …)

GUID

Name Assignment &

Certification Services

Global Name Resolution Service

Dynamic binding

Of GUID network address

Human Readable Names

global identifier

IoT Services over Named-Object Network

WINLAB

MF Example 1: Service Migration

GUID-Based Network

Subscribe to temperature service G1

Query current temperature via G1 Listen to G1

Notify/Respond

Listen to G1

Notify/Respond

WINLAB

MF Example 2: Service Caching (Power

Saving)

GUID-Based Network

Subscribe to temperature service G1

Query current temperature via G1

Listen to G1

Respond

Wake up periodically

Publish to G1, update sink

Sink node

WINLAB

MF Example 3: Pub/Sub & Multicast

GUID-Based Network

Subscribe to G1

Notify user

Subscribe to G1

Control air conditioning

Subscribe to G1

Analyze data

Publish temp to G1

Notify everyone who is interested

WINLAB

GUID-Based Network

Example: Send message to “Yellow Cabs in New Brunswick”

1. Messages sent to the end-networks that maintain context mappings

2. At end-network, message is late-bound to destinations

Global Name Service

N1

Nk

N2

GUIDc {N1, N2, …, Nk} GUIDc @Nk {t1, t2, …, tk}

MF Example 4: Supporting Context

WINLAB

MF Example 5: Sensor Data Aggregation

GUID-Based Network GUID-Based Network

Listen to G1

Respond

Get the average temperature

Multicast query with G1

Listen to G1

Respond

Listen to G1

Respond

Listen to G1

Respond

Listen to G1

Respond

MF compute layer for

Data aggregation

Aggregated response packet

with average temp

Individual sensor

Data packets

WINLAB

MF IoT Use Case Summary

IoT: S1 data is picked up by Mobile GW and sent to MF network for A1 that subscribes

Context: T1, first_responders@NJ, is subscribed by P1 …P4; A2 sends a file to T1 reaches P1..P4 via GUID-based MF routing

IoT/Context server updates MF-GNRS for mappings: S1 A1 and T1 P1…P4

GNRS: Global Name Resolution Service

Internet (MobilityFirst)

Sensor S1

(temperature)

IoT / Context (Naming)

Server, GUID

Assign & Publish

(S1, S2, C1, T1)

S1 -> A1

C1 -> NA1

Sensor S2

(location)

Actuator C1

(air conditioning)

Application A1

SmartGrid App

Application A2

Presentation

Context T1

First responders

NJ

Subscriber P1 P2

P3

Lookup Context T1 Lookup S2, T1 &

Subscribe T1

UPDATE

S2T1, T1P1..P4

P1 -> NA2, P2->NA2

P3 -> NA2, P4->NA3

NA1

NA4

NA2

NA3

GNRS Entries:

UPDATE

A1 -> NA4

DATA

IoT

GateWay

Lookup S1

Lookup S1, C1, subscribe S1

P4

DATA

WINLAB

MobilityFirst/IoT: Prototype Components

31

WSN Gateway (Android) - MF Client Protocol Stack - WSN Access Point Stack - WSN to MF GW processing

IoT/Context (naming) Server - Definitions and descriptions - GUID assignment & GNRS update - Subscription management

Native MF Client Stack

mySQL DBApache Server

GW Module

(GUID lookup)

GUI (Sensor/Context on Map)

Naming Mod

(GUID

assignment)

Service Mod

(GUID lookup ,

Subscription)

TCP/IP

GNRS Module

(GUID update)

Sensor / Context Management

(add/remove resources)

Web services

Downloadable User-level App for Android

Applications (PC) - Lookup a GUID - Subscribe to GUID - Send/Rcv data of GUID

Native MF Client Stack

Context App

(File transport)

GUID lookup & subscription

TCP/IP

Sensor/Actuator

App (smartGrid)

Browser /

HTTPclientJava Wrapper

GNRS - Sensor GUID -> App GUID

MF Router Stack

GNRS Caching Computing

Click Router

Native MF

Client Stack

WiFi or 3G/LTESensor Radio

(Proprietary now)

Java USB Driver

for Wireless

Sensor AP

Java wrap up APIRaw data

processing

MF formatting

& delivery

Lookup Sensor

GUIDs &

description XMLSensor Data

Parsing &

Collection

GUI/settings

TCP

/IP

Gateway

http://www.radiolabs.com/images/products/wireless-laptop-antenna.jpg

WINLAB Police Station

Global Name Resolution

Service

MF Context Service

For Alerts

Sends alert to multicast GUID

Nearby Users (by geographical distance)

In specified context group

Insert multicast group and GUID of

devices belonging to it

Request GUID corresponding to alert

multicast group

MF Proof-of-Concept Demo: Emergency

Response Services (US Ignite Conference, 2015)

MF Router

WINLAB

BMS-Evaluation

Sink

Router

Actuator

1

3

1

4

1

5 1

6

1

7

BMS

server

1. Based on MF-sim and NDN-sim

2. Based on campus building floor plan

WINLAB

Building Management System (BMS)

a

NGN Network

(NDN or MF)

Control Service

Environment

Monitoring

Occupancy

Monitoring

Fixture

/Interface

Thermostat

/Interface

…........

Sensor

Sink

a

Sensor

Sink ……………………

Web Portal

WINLAB

BMS-Evaluation – NDN vs. MF

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

Reference: Sugang Li et al, “A Comparative Study of ICN-IoT Architectures”, IEEE QShine 2014

WINLAB 36

Web Sites for More Information:

WINLAB: www.winlab.rutgers.edu

ORBIT: www.orbit-lab.org

MobilityFirst:

http://mobilityfirst.winlab.rutgers.edu

http://www.winlab.rutgers.edu/http://www.orbit-lab.org/http://www.orbit-lab.org/http://www.orbit-lab.org/http://mobilityfirst.winlab.rutgers.edu/