Upload
vuongcong
View
218
Download
0
Embed Size (px)
Citation preview
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
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
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
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
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