iot2030 towards next generation smart internet of things · air pollution monitoring leakage det...

29
IoT2030 Towards Next Generation Smart Internet of Things Jiannong Cao Internet & Mobile Computing LabDepartment of Computing University Research Facility in Big Data Analytics Hong Kong Polytechnic University Email: [email protected] http://www.comp.polyu.edu.hk/~csjcao/

Upload: others

Post on 24-Mar-2020

0 views

Category:

Documents


0 download

TRANSCRIPT

Page 1: IoT2030 Towards Next Generation Smart Internet of Things · Air Pollution Monitoring Leakage Det ecting Environmental Monitoring S af ey nd cu r iA s T k g Condition Monitoring

IoT2030

Towards Next Generation

Smart Internet of Things

Jiannong CaoInternet & Mobile Computing Lab,Department of Computing

University Research Facility in Big Data Analytics

Hong Kong Polytechnic University

Email: [email protected]

http://www.comp.polyu.edu.hk/~csjcao/

Page 2: IoT2030 Towards Next Generation Smart Internet of Things · Air Pollution Monitoring Leakage Det ecting Environmental Monitoring S af ey nd cu r iA s T k g Condition Monitoring

Table of Contents

• Toward Smart IoT

- From Instrumentation and Interconnection to Intelligence

• What makes IoT Smart?

- Smart Objects

- Smart Sensing and Networking

- Smart Computing and Analytics

- Smart Control

• Remaining challenges

Page 3: IoT2030 Towards Next Generation Smart Internet of Things · Air Pollution Monitoring Leakage Det ecting Environmental Monitoring S af ey nd cu r iA s T k g Condition Monitoring

Interconnection of physical objects embedded with electronics, sensors, and software, enabling them to exchange collected data and knowledge

Internet Of Things

Page 4: IoT2030 Towards Next Generation Smart Internet of Things · Air Pollution Monitoring Leakage Det ecting Environmental Monitoring S af ey nd cu r iA s T k g Condition Monitoring

Instrumentation & Sensing

Computer vision

BarcodeMagnetic ink

Biometric information

Sensors

There are a bunch of

techniques for automatic

identification

Sink node

Server

Internet

WSN

RFID

Page 5: IoT2030 Towards Next Generation Smart Internet of Things · Air Pollution Monitoring Leakage Det ecting Environmental Monitoring S af ey nd cu r iA s T k g Condition Monitoring

Interconnection

Page 6: IoT2030 Towards Next Generation Smart Internet of Things · Air Pollution Monitoring Leakage Det ecting Environmental Monitoring S af ey nd cu r iA s T k g Condition Monitoring

Evolving IoT Scenarios and Requirements

Low Cost, Low Latency, Scalable connectivity

• Worker & occupant Safety

• Fault detection & diagnosis

• e-Energy

• Predictive maintenance

Mobile, Real-time & interactive performance,

Distributed / localized computations:

• Logistics and emergency management

• Road safety and traffic efficiency

• Cooperative data sharing and computation

Human as objects

Turning IoT big data into profit

Turning insight into action

Sensors 2016, 16, 215 2 of 19

Communications

Industrial Intelligent EcosystemAir Pollution

Monitoring

Leakage DetectingEnvironmental

Monitoring

Safety and Security Asset Tracking

Condition

Monitoring

Figure 1. An industrial intelligence ecosystem. In this ecosystem, different objects (e.g., humans and

machines) are working as an efficient whole with effective dynamic collaboration. The ecosystem

consists of two parts: (i) sensing of humans with smart devices; humans (workers) share information

with each other and with various sensors; and (ii) sensing of sensors embedded in machines. Through

the sensors that are embedded in different industrial equipment, a variety of status information (even

weather information) can be obtained and shared with other information sources.

• This study clearly answers why and how designing the CSI framework based on the IIoT can be

achieved. Thekey components of this framework aredescribed in detail. Moreover, two on-going

efforts about developing the framework are introduced and discussed. This CSI framework aims

to achieve the dynamic collaboration between different objects, and such a collaboration is based

on massive spatio-temporal data.

• We list and analyse the challenges and open research issues for developing and realizing the

CSI framework.

The remainder of this article is organized as follows. In Section 2, we clearly define the terms CI

and ISI and discuss their advances. Section 3 answers why and how we design the CSI framework,

with integrating CI into ISI. Moreover, this section also displays and describes the key components

of CSI framework. On this basis, two on-going efforts are introduced and discussed to provide the

details about how to achieve CSI in industrial applications. Section 4 presents what are the challenges

and open research issues for deploying this CSI framework to the dynamic environment of industry.

This article is concluded in Section 5.

2. Definitions and Advances

As the basis of the CSI framework, the terms CI and ISI are clearly defined, and their advances

are discussed in this section.

2.1. What is Collaborative Intelligence

In industrial production/ service, based on the IIoT: (i) What is intelligence? (ii) Why do we need

this intelligence? (ii i) What is and why do we need “ collaboration” ? Then, from the answers to these

questions, the term CI can be clearly defined.

The intelligence of industrial production/ service in the IIoT can be described as: industrial

production/ service includes a series of complex and dangerous processes, so how to minimize the

manual intervention in these processes is an important issue for improving the safety, efficiency and

eco-friendliness of production/ service. On this basis, automation becomes very important [11]. Then,

the intelligence can be defined as the ability to acquire information or knowledge based on the IIoT

Page 7: IoT2030 Towards Next Generation Smart Internet of Things · Air Pollution Monitoring Leakage Det ecting Environmental Monitoring S af ey nd cu r iA s T k g Condition Monitoring

Sense and monitor

the things

Evolving IoT

Connect the things and

Exchange the data.

Integrate resources,

Optimize systems,

Make smarter decisions,

Learn and adapt

Page 8: IoT2030 Towards Next Generation Smart Internet of Things · Air Pollution Monitoring Leakage Det ecting Environmental Monitoring S af ey nd cu r iA s T k g Condition Monitoring

What Makes IoT Smart?

Page 9: IoT2030 Towards Next Generation Smart Internet of Things · Air Pollution Monitoring Leakage Det ecting Environmental Monitoring S af ey nd cu r iA s T k g Condition Monitoring

Smart Objects

IDENTIFICATION SENSING NETWORKING

FUNCTIONS RELATIONSHIPSATTRIBUTES

UIO MODELLING

SEARCH ENGINE

CRAWLING Collection INDEXING Index

UIO WEB

UIO

Data

Off-line (periodically)

SEARCHING

On-line (on-request)

RANKING

RESULT

MODELLINGSEARCHED

UIO

UIO

RELATIONSHIPS

Rea

l-tim

e U

pdat

e

INTERFACESEARCH

QUERY INPUTSEARCH

RESULT

User

What Makes IoT Smart?

Page 10: IoT2030 Towards Next Generation Smart Internet of Things · Air Pollution Monitoring Leakage Det ecting Environmental Monitoring S af ey nd cu r iA s T k g Condition Monitoring

Smart Cushion

A cushion based on pressure sensors which is able to identify 10 common

sitting postures with high accuracy (84.7%) in a real-time manner

1. “Smart Cushion: A Practical System for Fine-grained Sitting Posture Recognition”, 2nd IEEE PERCOM Workshop on Pervasive

Health Technologies (PerHealth 2017), March 2017. Hawaii, USA.

2. Demo at ACM CHI-2014. Toronto, Canada.

Page 11: IoT2030 Towards Next Generation Smart Internet of Things · Air Pollution Monitoring Leakage Det ecting Environmental Monitoring S af ey nd cu r iA s T k g Condition Monitoring

Smart Helmet

A helmet with the ability to track locations of construction workers with high

accuracy (<2m error) in a real-time manner

“S-helmet: A Proactive Construction Safety Management System Based on Real-time Localization” The CIC Journal. May, 2014.

Page 12: IoT2030 Towards Next Generation Smart Internet of Things · Air Pollution Monitoring Leakage Det ecting Environmental Monitoring S af ey nd cu r iA s T k g Condition Monitoring

1. “Distributed Intelligent MEMS: A Survey and a Real-time Programming Framework”, ACM Computing Surveys. 9(4): 39:1-39:28 (March 2016).

2. “Programming Large-Scale Multi-Robot System with Timing Constraints”, ICCCN-2016, August 1-4, 2016. Hawaii

3. “An ensemble-level programming model with real-time support for multi-robot systems”, PERCOM-2016 Workshop, March 14-18, 2016.

Sydney, Australia.

4. “Uniform Circle Formation by Asynchronous Robots: A Fully-Distributed Approach”, ICCCN 2017. Vancouver

System Tasks Advanced Functions

Accel

Sensor

Compass

Sensor

Gyro

Sensor

Light

SensorEncoder

Motor

Driver

Ultra Sonic

Sensor

Hardware Abstract Layer

FreeRTOS

Movement Control Task

Wireless Communication Task

Sensor Reading Task

Application Task

Localization

Collision Avoidance

Path Finding

Leader Election

Wireless

Communication

Programming Model

dsMRS: Fully Distributed

Coordination

Smart Robots

Page 13: IoT2030 Towards Next Generation Smart Internet of Things · Air Pollution Monitoring Leakage Det ecting Environmental Monitoring S af ey nd cu r iA s T k g Condition Monitoring

Smart Objects: the UIO Abstraction

• Smart environments composed of

UIOs- Have attributes (identifier, size, mobility,

functionality)

- Sensing themselves and surrounding environment

- Detecting and adapting to different contexts

- Reacting to environmental changes

- Localized interactions, distributed coordination

• UIO Web- Extending cyberspace search to physical world

- Enabling user to search and browse objects and

navigate through their contextual relationships

IDENTIFICATION SENSING NETWORKING

FUNCTIONS RELATIONSHIPSATTRIBUTES

UIO MODELLING

SEARCH ENGINE

CRAWLING Collection INDEXING Index

UIO WEB

UIO

Data

Off-line (periodically)

SEARCHING

On-line (on-request)

RANKING

RESULT

MODELLINGSEARCHED

UIO

UIO

RELATIONSHIPS

Real-

time

Upda

te

INTERFACESEARCH

QUERY INPUTSEARCH

RESULT

User

“LASEC: A Localized Approach to Service Composition in Pervasive Computing

Environments”, IEEE TPDS. July 2015.

“UIO-based Testbed Augmentation for Simulating Cyber-Physical Systems " IEEE

Intelligent Systems , 2018.

Page 14: IoT2030 Towards Next Generation Smart Internet of Things · Air Pollution Monitoring Leakage Det ecting Environmental Monitoring S af ey nd cu r iA s T k g Condition Monitoring

Smart Sensing & Networking

4

A B C

D E F

G H M

A B

D E F

H M

J

K

A C

D

M

L

(a) Vehicle to Vehicle (b) Vehicle to RSU (c) Vehicle to Cellular

H

A B C

D E F

G H M

J

L

K

Network Controller Control Plane

Mobile Data Plane

Stationary Data Plane

(d) Overlay Network and System Architecture

Wired Network

Wi-Fi

DSRC

Celluar

Fig. 3. Vehicular networks and the overlay abstraction

initiates a sudden brake and sends broadcast to notify

the vehicles following it to avoid rear-end collisions.

Naturally, it is pointless for vehicles at the opposite side

of the road (Vehicle D and E) to receive the broadcast.

Similarly, the ambulance G sends a broadcast to request

other vehicles to give way. This broadcast should also

not be received by vehicles on the opposite side of the

road. In this case, SDN controller can simply slice the

network according to the vehicles’ driving directions.

Without network slicing, to prevent broadcast storming,

the broadcast protocol need to be carefully designed to

determine when to re-broadcast, which will increase the

complexity in design and implementation.

4 THE SDVN SYSTEM

4.1 System Architecture

Currently, the heterogeneity of existing network in-

frastructures have caused challenges in network man-

agement and integration. This situation is depicted in

Fig. 3. Furthermore, the highly dynamic mobility in-

creases the vulnerability of communication. Motivated

by the concept of network virtualization [12], we propose

to exploit SDN to tackle these challenges in vehicular

networks. First of all, we need to make abstraction of

the existing vehicular networks to adapt the concepts in

SDN.

Data Plane: Data plane includes all data transmission

network devices. In vehicular scenario, we construct

the data plane with an overlay network to eliminate

the heterogeneity of existing vehicular networks. A ll

vehicles, roadside units, and base stations are abstracted

as SDN switches. These SDN switches can be further

Data

Plane

Application

& Service

Control

Plane

Northbound

API

Southbound

API

Status Manager

Topology Manager

802.11p

(Vehicle)

Wi-Fi switch

(RSU)

3G/LTE

(Vehicle)

WiMAX

(Vehicle)

Wi-Fi

(Vehicle)

WiMAX switch

(RSU)

3G / LTE

(Base Station)

OpenFlow OpenFlow Extension

Forwarding

Customized API

Flow Table

Installation

Update Frequency

ManagerEvent DetectionTrajectory

Prediction

Topology

Estimation

Network Slicing

Adaptive

Protocol

Deployment

Topology

Prediction

Graph

Generation Service Mapping

Multi-hop

Routing

Broadcast Storm

Prevention

QoS

Security

Switch Status Query API

Fig. 4. SDVN System architecture

categorized into mobiledataplaneand stationary dataplane,

according to their mobility. Roadside units and base

stations belong to stationary data plane, while vehicles

are in mobile data plane. Different management policies

are applied to the two data planes.

Control Plane: Control plane maintains the status of

all the switches and is responsible for making packet

forwarding decisions based on it. Control plane is log-

ically centralized, and the control of the networks is

transferred from individual switches to the controller.

In vehicular scenario, the switch status includes vehicle

location, velocity, and network connectivity. Nowadays,

almost all the vehicles have been equipped with localiza-

tion devices like GPS that can provide such information.

Communication Interface: The control plane and data

plane can communicate with each other with a unified

interface (a.k.a., Southbound API), which includes some

predefined control and notification messages. In generic

SDN, OpenFlow is the dominating communication pro-

tocol. In vehicular scenario, standard OpenFlow need to

be extended to adapt vehicular requirements. Network

applications use northbound API to communicate with

control plane. Currently, there is no standardized inter-

face for northbound API. In our system, we also define

customized interface.

With unified management interface, all network in-

frastructures in vehicular networks can be managed

by the control plane equally. Thus, it is possible for

upper layer protocols to take advantage of multiple

physical networks for a single task. E.g., routing. Note

that “ unified interface” only means the same network

management protocol, like OpenFlow. Physically, two

peers still need to adopt the same physical standard to

reach each other.

Fig. 4 shows the architecture of all the functional

components of SDVN. They are divided into three lay-

ers. From bottom up, data plane, control plane, and

SDVN

What Makes IoT Smart?

Page 15: IoT2030 Towards Next Generation Smart Internet of Things · Air Pollution Monitoring Leakage Det ecting Environmental Monitoring S af ey nd cu r iA s T k g Condition Monitoring

Sensing Complex Event / System

1. “InfraSee: An Unobtrusive Alertness System for Pedestrian Mobile Phone Users”, IEEE Transactions on Mobile Computing (TMC). February 2017。

2. “Drive Now, Text Later: Nonintrusive Texting-While-Driving Detection using Smartphones”, IEEE Transactions on Mobile Computing (TMC). 6(1): 73-86 (January 2017).

3. “CROWD-PAN-360: Crowdsourcing based Context-aware Panoramic Map Generation for Smartphone Users” , IEEE Transactions on Parallel and Distributed Systems

(TPDS), 2016

4. “UbiTouch: Ubiquitous Smartphone Touchpads Using Built-in Proximity and Ambient Light Sensors”, ACM UbiComp-2016. September 2016

Page 16: IoT2030 Towards Next Generation Smart Internet of Things · Air Pollution Monitoring Leakage Det ecting Environmental Monitoring S af ey nd cu r iA s T k g Condition Monitoring

Distributed In-Network Processing

• Hong Kong ICT Awards 2013: Best Innovation & Research • 2011 IEEE WCNC Best Paper Award

Page 17: IoT2030 Towards Next Generation Smart Internet of Things · Air Pollution Monitoring Leakage Det ecting Environmental Monitoring S af ey nd cu r iA s T k g Condition Monitoring

1. “SDVN: Enabling Rapid Network Innovation for Heterogeneous Vehicular Communication” , IEEE Network Magazine, 30(4) July-Aug 2016.

2. “Providing Flexible Services for Heterogeneous Vehicles: An NFV-based Approach”, IEEE Network Magazine, 30(3) May-June 2016.

SDVN: Software-defied Vehicular Networks

4

A B C

D E F

G H M

A B

D E F

H M

J

K

A C

D

M

L

(a) Vehicle to Vehicle (b) Vehicle to RSU (c) Vehicle to Cellular

H

A B C

D E F

G H M

J

L

K

Network Controller Control Plane

Mobile Data Plane

Stationary Data Plane

(d) Overlay Network and System Architecture

Wired Network

Wi-Fi

DSRC

Celluar

Fig. 3. Vehicular networks and the overlay abstraction

initiates a sudden brake and sends broadcast to notify

the vehicles following it to avoid rear-end collisions.

Naturally, it is pointless for vehicles at the opposite side

of the road (Vehicle D and E) to receive the broadcast.

Similarly, the ambulance G sends a broadcast to request

other vehicles to give way. This broadcast should also

not be received by vehicles on the opposite side of the

road. In this case, SDN controller can simply slice the

network according to the vehicles’ driving directions.

Without network slicing, to prevent broadcast storming,

the broadcast protocol need to be carefully designed to

determine when to re-broadcast, which will increase the

complexity in design and implementation.

4 THE SDVN SYSTEM

4.1 System Architecture

Currently, the heterogeneity of existing network in-

frastructures have caused challenges in network man-

agement and integration. This situation is depicted in

Fig. 3. Furthermore, the highly dynamic mobility in-

creases the vulnerability of communication. Motivated

by the concept of network virtualization [12], we propose

to exploit SDN to tackle these challenges in vehicular

networks. First of all, we need to make abstraction of

the existing vehicular networks to adapt the concepts in

SDN.

Data Plane: Data plane includes all data transmission

network devices. In vehicular scenario, we construct

the data plane with an overlay network to eliminate

the heterogeneity of existing vehicular networks. A ll

vehicles, roadside units, and base stations are abstracted

as SDN switches. These SDN switches can be further

Data

Plane

Application

& Service

Control

Plane

Northbound

API

Southbound

API

Status Manager

Topology Manager

802.11p

(Vehicle)

Wi-Fi switch

(RSU)

3G/LTE

(Vehicle)

WiMAX

(Vehicle)

Wi-Fi

(Vehicle)

WiMAX switch

(RSU)

3G / LTE

(Base Station)

OpenFlow OpenFlow Extension

Forwarding

Customized API

Flow Table

Installation

Update Frequency

ManagerEvent DetectionTrajectory

Prediction

Topology

Estimation

Network Slicing

Adaptive

Protocol

Deployment

Topology

Prediction

Graph

Generation Service Mapping

Multi-hop

Routing

Broadcast Storm

Prevention

QoS

Security

Switch Status Query API

Fig. 4. SDVN System architecture

categorized into mobiledata planeand stationary dataplane,

according to their mobility. Roadside units and base

stations belong to stationary data plane, while vehicles

are in mobile data plane. Different management policies

are applied to the two data planes.

Control Plane: Control plane maintains the status of

all the switches and is responsible for making packet

forwarding decisions based on it. Control plane is log-

ically centralized, and the control of the networks is

transferred from individual switches to the controller.

In vehicular scenario, the switch status includes vehicle

location, velocity, and network connectivity. Nowadays,

almost all the vehicles have been equipped with localiza-

tion devices like GPS that can provide such information.

Communication Interface: The control plane and data

plane can communicate with each other with a unified

interface (a.k.a., Southbound API), which includes some

predefined control and notification messages. In generic

SDN, OpenFlow is the dominating communication pro-

tocol. In vehicular scenario, standard OpenFlow need to

be extended to adapt vehicular requirements. Network

applications use northbound API to communicate with

control plane. Currently, there is no standardized inter-

face for northbound API. In our system, we also define

customized interface.

With unified management interface, all network in-

frastructures in vehicular networks can be managed

by the control plane equally. Thus, it is possible for

upper layer protocols to take advantage of multiple

physical networks for a single task. E.g., routing. Note

that “ unified interface” only means the same network

management protocol, like OpenFlow. Physically, two

peers still need to adopt the same physical standard to

reach each other.

Fig. 4 shows the architecture of all the functional

components of SDVN. They are divided into three lay-

ers. From bottom up, data plane, control plane, and

Traffic Condition

Web Service

SDVN

Control Plane

Slow Speed Fast Speed

Traffic condition

collection

Traffic condition

query

Structure-base

routing protocol

Structure-free

routing protocol

A B C

D E F

G H I

(b) Vehicular Network

Topology

A B C(c) Network Slice 1:

Sudden brake warning

D E F

G H I

(d) Network Slice 2:

Emergency vehicle

passing request

(a) Physical Location

Driving direction

Driving direction

4

A B C

D E F

G H M

A B

D E F

H M

J

K

A C

D

M

L

(a) Vehicle to Vehicle (b) Vehicle to RSU (c) Vehicle to Cellular

H

A B C

D E F

G H M

J

L

K

Network Controller Control Plane

Mobile Data Plane

Stationary Data Plane

(d) Overlay Network and System Architecture

Wired Network

Wi-Fi

DSRC

Celluar

Fig. 3. Vehicular networks and the overlay abstraction

initiates a sudden brake and sends broadcast to notify

the vehicles following it to avoid rear-end collisions.

Naturally, it is pointless for vehicles at the opposite side

of the road (Vehicle D and E) to receive the broadcast.

Similarly, the ambulance G sends a broadcast to request

other vehicles to give way. This broadcast should also

not be received by vehicles on the opposite side of the

road. In this case, SDN controller can simply slice the

network according to the vehicles’ driving directions.

Without network slicing, to prevent broadcast storming,

the broadcast protocol need to be carefully designed to

determine when to re-broadcast, which will increase the

complexity in design and implementation.

4 THE SDVN SYSTEM

4.1 System Architecture

Currently, the heterogeneity of existing network in-

frastructures have caused challenges in network man-

agement and integration. This situation is depicted in

Fig. 3. Furthermore, the highly dynamic mobility in-

creases the vulnerability of communication. Motivated

by the concept of network virtualization [12], we propose

to exploit SDN to tackle these challenges in vehicular

networks. First of all, we need to make abstraction of

the existing vehicular networks to adapt the concepts in

SDN.

Data Plane: Data plane includes all data transmission

network devices. In vehicular scenario, we construct

the data plane with an overlay network to eliminate

the heterogeneity of existing vehicular networks. All

vehicles, roadside units, and base stations are abstracted

as SDN switches. These SDN switches can be further

Data

Plane

Application

& Service

Control

Plane

Northbound

API

Southbound

API

Status Manager

Topology Manager

802.11p

(Vehicle)

Wi-Fi switch

(RSU)

3G/LTE

(Vehicle)

WiMAX

(Vehicle)

Wi-Fi

(Vehicle)

WiMAX switch

(RSU)

3G / LTE

(Base Station)

OpenFlow OpenFlow Extension

Forwarding

Customized API

Flow Table

Installation

Update Frequency

ManagerEvent DetectionTrajectory

Prediction

Topology

Estimation

Network Slicing

Adaptive

Protocol

Deployment

Topology

Prediction

Graph

Generation Service Mapping

Multi-hop

Routing

Broadcast Storm

Prevention

QoS

Security

Switch Status Query API

Fig. 4. SDVN System architecture

categorized into mobiledataplaneand stationary data plane,

according to their mobility. Roadside units and base

stations belong to stationary data plane, while vehicles

are in mobile data plane. Different management policies

are applied to the two data planes.

Control Plane: Control plane maintains the status of

all the switches and is responsible for making packet

forwarding decisions based on it. Control plane is log-

ically centralized, and the control of the networks is

transferred from individual switches to the controller.

In vehicular scenario, the switch status includes vehicle

location, velocity, and network connectivity. Nowadays,

almost all the vehicles have been equipped with localiza-

tion devices like GPS that can provide such information.

Communication Interface: The control plane and data

plane can communicate with each other with a unified

interface (a.k.a., Southbound API), which includes some

predefined control and notification messages. In generic

SDN, OpenFlow is the dominating communication pro-

tocol. In vehicular scenario, standard OpenFlow need to

be extended to adapt vehicular requirements. Network

applications use northbound API to communicate with

control plane. Currently, there is no standardized inter-

face for northbound API. In our system, we also define

customized interface.

With unified management interface, all network in-

frastructures in vehicular networks can be managed

by the control plane equally. Thus, it is possible for

upper layer protocols to take advantage of multiple

physical networks for a single task. E.g., routing. Note

that “ unified interface” only means the same network

management protocol, like OpenFlow. Physically, two

peers still need to adopt the same physical standard to

reach each other.

Fig. 4 shows the architecture of all the functional

components of SDVN. They are divided into three lay-

ers. From bottom up, data plane, control plane, and

Construct an overlay network, and treat all wireless devices in VANET equally as SDN switches with

unified abstraction

Page 18: IoT2030 Towards Next Generation Smart Internet of Things · Air Pollution Monitoring Leakage Det ecting Environmental Monitoring S af ey nd cu r iA s T k g Condition Monitoring

Image courtesy of Qualcomm Technologies, Inc.

Erisson IoT 5G Big Data | Ericsson Confidential | © Ericsson AB 2015 | 2015-07-01 | Page 8

5G

1000x Mobile Data

Volumes 10x-100x Connected Devices 5x

Lower Latency

10x-100x End-user Data Rates

10x Battery Life for Low

Power Devices

Source: METIS

Ev o l u t io n To w a r d s 5G

4G 3G 2G

© Telefonaktiebolaget LM Ericsson 2015 | Ericsson June 2015

5G

Page 19: IoT2030 Towards Next Generation Smart Internet of Things · Air Pollution Monitoring Leakage Det ecting Environmental Monitoring S af ey nd cu r iA s T k g Condition Monitoring

Smart Computation & Analytics

Application Modeling Cost Profiling

Partitioning Optimization

Distributed Execution

What Makes IoT Smart?

Page 20: IoT2030 Towards Next Generation Smart Internet of Things · Air Pollution Monitoring Leakage Det ecting Environmental Monitoring S af ey nd cu r iA s T k g Condition Monitoring

IoT

Devices

Computation Partitioning & Offloading

“A framework for partitioning and execution of data stream applications in mobile cloud computing”. ACM SigMetrics Perf. Eval. Review 2013

“Run Time Application Repartitioning in Dynamic Mobile Cloud Environments”, IEEE Trans. on Cloud Computing, 4(3) 2016

“Multi-user computation partitioning for latency sensitive mobile applications”, IEEE Trans. On Computers, 64(8) 2015)

Cloud-assisted IoT Infrastructure

Page 21: IoT2030 Towards Next Generation Smart Internet of Things · Air Pollution Monitoring Leakage Det ecting Environmental Monitoring S af ey nd cu r iA s T k g Condition Monitoring

Edge Computing

Cloud

End Devices

Routers

Edge Mesh

Edge device + SDN controller

Edge device + SDN controller

Collaborative Edge: EdgeMesh

“Edge Mesh: A new paradigm to enable distributed intelligence in Internet of Things”. IEEE Access, 5, 16441-16458.

“Data-aware Task Allocation for Achieving Low Latency in Collaborative Edge Computing”, IEEE IoT Journal, 2018

Page 22: IoT2030 Towards Next Generation Smart Internet of Things · Air Pollution Monitoring Leakage Det ecting Environmental Monitoring S af ey nd cu r iA s T k g Condition Monitoring

IoT Big Data AnalyticsHuge amount of data generated from physical world

IDC

©2015 IBM Corporation 27 April 20163

“Internet-of-Things” generated data soon bigger than social and transactional data

~ 2x more data growth (currently @ 44EB/month) than social & computer generated data

Page 23: IoT2030 Towards Next Generation Smart Internet of Things · Air Pollution Monitoring Leakage Det ecting Environmental Monitoring S af ey nd cu r iA s T k g Condition Monitoring

IoT Big Data Analytics

Traffic congestion Logistics Shopping malls Industry IoT

Page 24: IoT2030 Towards Next Generation Smart Internet of Things · Air Pollution Monitoring Leakage Det ecting Environmental Monitoring S af ey nd cu r iA s T k g Condition Monitoring

Smart Sensing &

Networking

4

A B C

D E F

G H M

A B

D E F

H M

J

K

A C

D

M

L

(a) Vehicle to Vehicle (b) Vehicle to RSU (c) Vehicle to Cellular

H

A B C

D E F

G H M

J

L

K

Network Controller Control Plane

Mobile Data Plane

Stationary Data Plane

(d) Overlay Network and System Architecture

Wired Network

Wi-Fi

DSRC

Celluar

Fig. 3. Vehicular networks and the overlay abstraction

initiates a sudden brake and sends broadcast to notify

the vehicles following it to avoid rear-end collisions.

Naturally, it is pointless for vehicles at the opposite side

of the road (Vehicle D and E) to receive the broadcast.

Similarly, the ambulance G sends a broadcast to request

other vehicles to give way. This broadcast should also

not be received by vehicles on the opposite side of the

road. In this case, SDN controller can simply slice the

network according to the vehicles’ driving directions.

Without network slicing, to prevent broadcast storming,

the broadcast protocol need to be carefully designed to

determine when to re-broadcast, which will increase the

complexity in design and implementation.

4 THE SDVN SYSTEM

4.1 System Architecture

Currently, the heterogeneity of existing network in-

frastructures have caused challenges in network man-

agement and integration. This situation is depicted in

Fig. 3. Furthermore, the highly dynamic mobility in-

creases the vulnerability of communication. Motivated

by the concept of network virtualization [12], we propose

to exploit SDN to tackle these challenges in vehicular

networks. First of all, we need to make abstraction of

the existing vehicular networks to adapt the concepts in

SDN.

Data Plane: Data plane includes all data transmission

network devices. In vehicular scenario, we construct

the data plane with an overlay network to eliminate

the heterogeneity of existing vehicular networks. A ll

vehicles, roadside units, and base stations are abstracted

as SDN switches. These SDN switches can be further

Data

Plane

Application

& Service

Control

Plane

Northbound

API

Southbound

API

Status Manager

Topology Manager

802.11p

(Vehicle)

Wi-Fi switch

(RSU)

3G/LTE

(Vehicle)

WiMAX

(Vehicle)

Wi-Fi

(Vehicle)

WiMAX switch

(RSU)

3G / LTE

(Base Station)

OpenFlow OpenFlow Extension

Forwarding

Customized API

Flow Table

Installation

Update Frequency

ManagerEvent DetectionTrajectory

Prediction

Topology

Estimation

Network Slicing

Adaptive

Protocol

Deployment

Topology

Prediction

Graph

Generation Service Mapping

Multi-hop

Routing

Broadcast Storm

Prevention

QoS

Security

Switch Status Query API

Fig. 4. SDVN System architecture

categorized into mobiledataplaneand stationary dataplane,

according to their mobility. Roadside units and base

stations belong to stationary data plane, while vehicles

are in mobile data plane. Different management policies

are applied to the two data planes.

Control Plane: Control plane maintains the status of

all the switches and is responsible for making packet

forwarding decisions based on it. Control plane is log-

ically centralized, and the control of the networks is

transferred from individual switches to the controller.

In vehicular scenario, the switch status includes vehicle

location, velocity, and network connectivity. Nowadays,

almost all the vehicles have been equipped with localiza-

tion devices like GPS that can provide such information.

Communication Interface: The control plane and data

plane can communicate with each other with a unified

interface (a.k.a., Southbound API), which includes some

predefined control and notification messages. In generic

SDN, OpenFlow is the dominating communication pro-

tocol. In vehicular scenario, standard OpenFlow need to

be extended to adapt vehicular requirements. Network

applications use northbound API to communicate with

control plane. Currently, there is no standardized inter-

face for northbound API. In our system, we also define

customized interface.

With unified management interface, all network in-

frastructures in vehicular networks can be managed

by the control plane equally. Thus, it is possible for

upper layer protocols to take advantage of multiple

physical networks for a single task. E.g., routing. Note

that “ unified interface” only means the same network

management protocol, like OpenFlow. Physically, two

peers still need to adopt the same physical standard to

reach each other.

Fig. 4 shows the architecture of all the functional

components of SDVN. They are divided into three lay-

ers. From bottom up, data plane, control plane, and

SDVN

Smart Computation &

Analytics

Application Modeling Cost Profiling

Partitioning Optimization

Distributed Execution

Smart Control

Smart Objects

IDENTIFICATION SENSING NETWORKING

FUNCTIONS RELATIONSHIPSATTRIBUTES

UIO MODELLING

SEARCH ENGINE

CRAWLING Collection INDEXING Index

UIO WEB

UIO

Data

Off-line (periodically)

SEARCHING

On-line (on-request)

RANKING

RESULT

MODELLINGSEARCHED

UIO

UIO

RELATIONSHIPS

Real-

time

Upda

te

INTERFACESEARCH

QUERY INPUTSEARCH

RESULT

User

Towards Smart IoT

• Ubiquitous network connections;

• Non-intrusive sensing;

• 5G

• Cloud computing;

• Edge computing;

• Big data analytics;

• Cyber-Physical Systems;

• SD-Everything

• Blockchain

• Context-adaptation;

• Autonomous interactions;

• Distributed coordination

Page 25: IoT2030 Towards Next Generation Smart Internet of Things · Air Pollution Monitoring Leakage Det ecting Environmental Monitoring S af ey nd cu r iA s T k g Condition Monitoring

Toward Future Smart IoTFrom Connection to Benefit

Page 26: IoT2030 Towards Next Generation Smart Internet of Things · Air Pollution Monitoring Leakage Det ecting Environmental Monitoring S af ey nd cu r iA s T k g Condition Monitoring

Toward Future Smart IoT

Page 27: IoT2030 Towards Next Generation Smart Internet of Things · Air Pollution Monitoring Leakage Det ecting Environmental Monitoring S af ey nd cu r iA s T k g Condition Monitoring

Remaining Challenges

• Handling diversity of devices, networks and data

• Achieve scalable connectivity and communication

• Sensing in a complex environment

• Resolving complexity in big data analytics

- Multi-domain multi-source data correlations

- Multi-stage dependency

• Leveraging rich contexts

• Cognitive computing

• ……

Page 28: IoT2030 Towards Next Generation Smart Internet of Things · Air Pollution Monitoring Leakage Det ecting Environmental Monitoring S af ey nd cu r iA s T k g Condition Monitoring
Page 29: IoT2030 Towards Next Generation Smart Internet of Things · Air Pollution Monitoring Leakage Det ecting Environmental Monitoring S af ey nd cu r iA s T k g Condition Monitoring