iot2030 towards next generation smart internet of things · air pollution monitoring leakage det...
TRANSCRIPT
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/
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
Interconnection of physical objects embedded with electronics, sensors, and software, enabling them to exchange collected data and knowledge
Internet Of Things
Instrumentation & Sensing
Computer vision
BarcodeMagnetic ink
Biometric information
Sensors
There are a bunch of
techniques for automatic
identification
Sink node
Server
Internet
WSN
RFID
Interconnection
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
Sense and monitor
the things
Evolving IoT
Connect the things and
Exchange the data.
Integrate resources,
Optimize systems,
Make smarter decisions,
Learn and adapt
What Makes IoT Smart?
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?
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.
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.
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
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.
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?
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
Distributed In-Network Processing
• Hong Kong ICT Awards 2013: Best Innovation & Research • 2011 IEEE WCNC Best Paper Award
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
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
Smart Computation & Analytics
Application Modeling Cost Profiling
Partitioning Optimization
Distributed Execution
What Makes IoT Smart?
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
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
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
IoT Big Data Analytics
Traffic congestion Logistics Shopping malls Industry IoT
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
Toward Future Smart IoTFrom Connection to Benefit
Toward Future Smart IoT
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
• ……