Content uploaded by Viet Quoc Pham
Author content
All content in this area was uploaded by Viet Quoc Pham on Oct 01, 2021
Content may be subject to copyright.
1
Efficient RSU Selection Scheme for Fog-based
Vehicular Software-Defined Network
Lionel Nkenyereye, Lewis Nkenyereye, Quoc-Viet Pham, and JaeSeung Song
Abstract—Efficient traffic control center (TCC) management
requires roadside units (RSUs) to frequently update vehicles
with traffic messages (TMs). RSUs are costly to road operators
in terms of deployment and maintenance. Therefore, vehicular
users expect the TCC to deliver high-quality and rapid responses
to query requests on TMs through RSUs. This paper presents
a novel RSU selection scheme based on a software-defined
network (SDN) for traffic message transmission. In the proposed
scheme, the RSU selection is determined by comparing the utility
function calculated at the SDN controller. The SDN controller
discovers the network connectivity topology through a cluster
approach in which a cluster head (CH) is elected to report the
network topology to the SDN controller. Furthermore, the SDN
controller relies on the RSU selection manager to load existing
RSU deployment techniques. In addition, a distance vector hop
localization algorithm (DV-hop) is used to locate hidden RSUs to
control signaling between the SDN controller and local controllers
at RSUs. The proposed scheme achieves minimum latency and
appropriate RSU management within a higher packet reception
rate, which improves the selection of RSUs and traffic message
delivery.
Index Terms—RSU Selection, Software-Defined Networks, Ve-
hicular Networks, Traffic Message.
I. INTRODUCTION
Edge computing enables cloud systems deployed closer to
end devices to meet their processing and delay requirement
with the assistance of edge nodes [1]. With the development
of edge computing, new technologies have been introduced
to perform at the edge of the network, such as Cloudlet [2],
microdata centers [3], fog computing [4], and mobile edge
computing [5] (currently known as multiaccess edge com-
puting (MEC) [1], [6]). These edge computing technologies
have been considered as key enablers for Internet of Things
(IoT) applications [1]–[7]. Their common principle is the
deployment of a network architecture element known as edge
nodes between end devices and cloud computing by placing
computing capabilities and services either at the edge of
cellular networks (MEC) or through distributed computing
nodes that form a fully distributed multitier cloud computing
architecture. Furthermore, edge devices are becoming more
Lionel Nkenyereye, Lewis Nkenyereye, and JaeSeung Song (correspond-
ing author) are with Sejong University, Seoul 05006, Korea (e-mails: li-
onelnk82@gmail.com, nkenyele@sejong.ac.kr, jssong@sejong.ac.kr).
Quoc-Viet Pham is with Korean Southeast Center for the 4th Industrial
Revolution Leader Education, Pusan National University, Busan 46241, Korea
(e-mail: vietpq@pusan.ac.kr).
This work was financially supported by the ICT R&D program of
MSIT/IITP (IITP-2021-0-01816, A Research on Core Technology of Au-
tonomous Twins for Metaverse) and IITP-2019-0-00426 (Development of
active kill-switch and biomarker-based defence system for life-threatening IoT
medical devices)
important, and their capability to host computing services
could eventually replace the role of the cloud in some sce-
narios. In this paper, we divide edge devices into end devices
and edge nodes: the end devices are mobile edge devices
(smart vehicles, smartphones, etc.), and edge nodes include
cloudlets, roadside units (RSUs), fog nodes, and MEC servers;
edge nodes are generally deployed at the edge of the network.
Therefore, the connected vehicle could rely on edge nodes
like RSUs to download buffered files to intelligent transporta-
tion system (ITS) application servers from the cloud using
the network infrastructure (vehicle-to-infrastructure - V2I and
vehicle-to-vehicle - V2V) [8]. In addition, efficient traffic
control center (TCC) management requires edge nodes to
frequently update vehicles with traffic messages (TMs). The
edge nodes might be placed at different levels, ranging from
vehicles to dedicated servers in the radio access network or
core network [9]. However, the heterogeneity of vehicular
networks (VNs) with different access technologies restricts
the cooperation between the edge and cloud computing for
VN. Moreover, the selection of an appropriate edge node is
critical for scalable VN services. For example, with dense
traffic in an urban environment, the TCC needs to select the
appropriate edge node to enable rapid accident rescue and
improve emergency responsiveness. Therefore, the selection
of an appropriate edge infrastructure (RSU) is important
for VN services. This paper studies VN architecture based
on a software-defined network (SDN) and edge computing
technology, called the fog-enabled vehicular software-defined
network (VSDN) approach for VN services [10].
SDN is a networking concept that has attracted the attention
of academics and industries. SDN separates the control and
data plane entities [11]. It executes control plane software
on general-purpose hardware, known as the SDN controller.
The SDN controller presents an abstract view of transport
network resources to network operators using programming
interfaces. The SDN controller conveys routing paths and net-
work management policies to the data plane. The distributed
topology of the local controller at edge nodes alleviates the
computation of the global view of the VN [11]. VSDN
markedly enhances routing protocols, addresses the utilization
of network resources [12], and efficiently selects best routes
for traffic data dissemination [13].
A. Motivation and Contributions
The motivation of this study is to effectively select the
appropriate RSUs, such as edge nodes in fog-enabled VSDN,
by considering multicriteria utilities. As mentioned in [10],
2
vehicle mobility causes occasional connectivity, which can
threaten the availability of RSU resources. More importantly,
edge nodes upload a vehicle’s beacon messages along with
geographical data because the SDN controller in the cloud
requires this information to maintain the up-to-date network
topology of each vehicle. Moreover, edge nodes with appropri-
ate topology knowledge and sufficient resources can be used
to quickly upload real-time traffic and vehicle information for
VN services via the wireless vehicular network. For example,
when a vehicle accident occurs, the fog node is selected to
correctly manage dynamically changing connectivity during
the rescue operation and minimize the impact of reporting the
rescue events to the transportation platform in real time. In
addition, the SDN controller manages services distributed in
different edge nodes by dynamically updating vehicles with
new navigation routes via edge orchestration to avoid traffic
congestion. Through in-car terminal and V2I technology, the
vehicle uploads the surroundings information generated by the
in-car sensors (Lidar for Self-Driving Cars, for example) to the
edge nodes. The latter is selected if they have high resource
capability and stable connectivity to receive routing rules
from the SDN controller/edge orchestrator for managing the
efficient transmission of TMs. All these VN services need to
access edge nodes to deliver important TM data to vehicles. In
this paper, we investigate edge node selection for fog-enabled
VSDN. In such a case, the network topology is affected by
vehicle mobility. In this case, the VSDN architecture obtains
network topology information via RSUs so that the SDN
controller/edge orchestrator selects the appropriate RSUs to
convey routing decisions and other important information.
VSDN relies on a stable clustering algorithm to deal with vehi-
cle mobility [14]. As discussed in [3], RSUs have become an
important metric for VN services because the aim of the latter
is to move the processing and storage resources to the RSUs
as edge nodes, and the VSDN architecture is better suited
to supporting the integration of edge computing efficiently.
Therefore, in this study, we consider multicriteria utility in the
edge node selection process. In contrast to previous studies,
this makes our work more consistent with edge services. We
combine the packet loss ratio, vehicle coverage area, delay,
cost, and transmission range to establish an appropriate utility
function. In addition, a clustering algorithm is proposed to deal
with high mobility by grouping vehicles in a cluster where
the CH is selected to enhance the efficiency of information
dissemination. Additionally, edge nodes receive route-planning
requests and provide alternative routes for vehicles based on
their current position. In contrast, this study focuses on traffic
message dissemination in fog-enabled VSDN to provide route
planning.
In VNs, RSUs are crucial road facilities. The main role of
RSUs is to communicate with vehicles via wireless commu-
nication within their transmission range. In addition, RSUs
support drivers by providing information regarding traffic
or gathering vehicle information. It is costly to deploy and
maintain RSUs. Therefore, methods for reducing the number
of RSUs used while ensuring proper selection for TMs delivery
are discussed. To find the most appropriate locations, the
coverage and locations of intersections have been discussed
for deploying RSUs. Because RSU maintenance is expensive,
new RSUs must be deployed to ensure that all intersections are
covered. Emerging techniques for selecting deployed RSUs us-
ing a networking programmable approach could ensure better
QoS of VN services. SDN technology in networking proposes
decoupling the forwarding plane from the control plane using
software where the forwarding devices receive instructions
from a separate controller on how to treat incoming flows
in the network. Therefore, SDN relieves the complexity of
networking and then opens opportunities to new services in
VNs. The benefits of using the SDN for selecting RSUs
enabled the RSUs to be dynamically selected to gather or
transmit information to vehicles under different conditions of
the road network, vehicle density, and priority of TMs. The
algorithms to control the selection of RSUs are implemented
in a controller software instead of embedding them into RSU
devices. Therefore, the update of new algorithms would not
force to remove or change anything to the deployed RSUs
as well as the RSU deployment schemes. This simplifies the
deployment of RSUs because the algorithms tailored for that
are deployed as software modules into separate controller
hardware. Therefore, the implementation of new RSUs would
not affect the existing deployment schemes or the selection of
RSUs to deliver TMs. The other benefit is that the network
flows for selected RSUs are inserted; therefore, for the same
network flows in delivering TMs, the RSUs automatically
execute the VN service assignment without the need to run
once again routing algorithms designed to select the best
routing paths.
According to the analysis above, we consider multiple
decision factors to achieve in-time message delivery. In this
paper, we propose an RSU selection scheme based on SDN
(RSSD) for traffic message transmission in the fog-enabled
VSDN that enables reliable TM dissemination. RSSD divides
the road network into clusters and selects a CH vehicle with
the assistance of RSUs to collect road network topology
information as input to the VSDN control plane. Whenever the
TCC wants to send TMs, the controller can adaptively choose
the appropriate RSUs to carry out TMs with higher stable
connectivity based on road topology network information
collected from CH vehicles. In our approach, the controller
selects the RSUs from the cluster header vehicles based on
the input connectivity topology. In addition, the RSU selection
manager supports the SDN controller in making appropriate
RSU selections based on the road network performance and
the number of RSUs. First, the SDN controller computes the
multicriteria utility function and uses the output to select
the appropriate RSU as the edge node. Then, a DV-hop
localization algorithm is used to locate RSUs for control
signaling between the SDN controller and local controllers
at the RSU. The proposed scheme improves the selection of
RSUs because the SDN controller assigns the best routing
decisions under the RSU coverage to minimize latency and
optimize RSU management within a higher packet reception
rate.
The main contributions of this paper are as follows:
1) We propose a road cluster constitution using a signal
quality factor determined by the critical density and
3
jam density of road traffic flow. The cluster constitution
serves as an input to the connectivity topology of the
SDN controller to construct the network graph in a fog-
based vehicular software-defined network .
2) We model the RSU selection based on the multicriteria
utility function calculated using the road network param-
eters to select the appropriate RSU deployment scheme.
The SDN controller updates the routing rules on the
RSUs deployed according to the selected RSU deploy-
ment technique. The proposed RSU selection scheme
aims to satisfy the TCC requirements in delivering VN
services.
3) We compare the proposed scheme with the ex-
isting VSDN architectures for traffic dissemination,
namely hierarchical software-defined VANET (HSDV),
VSDN-based heterogeneous wireless interface, and Fog-
Assisted Cooperative Protocol (FACP). The simulation
results conducted by OMNeT++ illustrate that the pro-
posed RSSD scheme can achieve superior performance
in terms of packet delivery ratio (PDR), throughput, end-
to-end delay, and routing overhead.
B. Paper Organization
The remainder of the paper is organized as follows: Sec-
tion II presents the preliminaries of the DV-hop algorithm.
The system model is described in Section III. Section IV
presents an RSU selection scheme based on SDN for TM
transmission. Section V evaluates the proposed scheme and
simulation results. Finally, we draw conclusions and make
some remarks about future work in Section VI.
II. PRELIMINARIES
In this section, we first discuss the mathematical model of
the DV-hop localization algorithm theory and then provide a
short description of the VSDN.
A. Theoretical Background on DV-hop Localization Algorithm
The DV-hop localization algorithm is only used for locating
hidden RSU nodes among many localization algorithms.
Let us assume that some anchor nodes, called BeaconNodes,
are aware of their positions. Note that anchor nodes dispose
of the same competency as all the sensor nodes with unknown
positions, which are called unknownNode [15]. The DV-
hop localization algorithm originates from [16]. It can be
summarized as follows: 1) Finding the minimum HopCount,
2) calculation of the distance between BeaconNodes, and 3)
calculation of the estimated location.
1) Finding the Minimum Hop Count: All
BeaconNodes broadcast beacon messages to other nodes.
{id, xi, yi, HopCount}is the format of the beacon message.
xi, yiare coordinate positions of the beacon nodes i. Initially,
HopCount had a value of 0. In each instance, the nodes
preserve a BeaconNode information table which saves the
minimum hop count value from neighbor nodes. After a
specific period, all nodes have the minimum HopCount,
similar to other nodes in the network.
2) Calculation of the Distance between BeaconNodes and
UnknownNodes:In this step, the BeaconNode acknowledges
the minimum HopCount value issued by the first step and
known by all BeaconNodes in the networks. Then they can
estimate average HopSize to other BeaconNodes accordingly
to the minimum HopCount and the distance between Bea-
conNodes. Hence, the i0th BeaconNode’s average HopSize can
be obtained by
HopSizei=PN
j=1,j6=ip(xi−xj)2+ (yi−yj)2
PN
j=1,j6=ihij
,(1)
where (xi, yi)and (xj, yj)are coordinates of BeaconNodes i
and j,hij is the minimum HopCount value between BeaconN-
odes iand j,Nrepresents the total number of BeaconNodes
(smart vehicle for instance). Each BeaconNodes broadcasts its
average HopSize to an exclusive network. Then, UnknownN-
ode edge nodes, for instance,receive all the BeaconNode
average HopSize and select the HopSize of BeaconNodes
equals to the minimum HopCount value to this UnknownNode.
With the minimum HopCount value, the distance of every
unknownNode to BeaconNode is given by
dij =HopSizei∗HopC ountij ,(2)
where dij is the distance between the ith UnknownNode and
the jth BeaconNode.HopCountij indicates the minimum
HopCount between the ith BeaconNode.
3) Calculation of The Estimated Location: In this step, the
mathematical model of maximum likelihood (ML) estimation
or trilateration is applied to calculate and estimate the location
of the unknownNode as follows [17]:
di1=p(xi−x1)2+ (yi−y1)2,
di2=p(xi−x2)2+ (yi−y2)2,
.
.
.
diN =p(xi−xN)2+ (yi−yN)2,
(3)
where di1is the distance between the ith UnknownNode and
the first BeaconNode.(xi, yi)are the coordinates of the ith
UnknownNode. Thus, (x1, y1)and (x2, y2)· · · (xN, yN)are
the coordinates of BeaconNode. Then, (3) can be transformed
as follows:
AX =B, (4)
where A, B, and Xare given as
A=
2(x1−xN) 2(y1−yN)
2(x2−xN) 2(y2−yN)
.
.
..
.
.
2(x2−xN) 2(y2−yN)
,(5)
and
B=
x2
1−x2
N+y2
1−y2
N−d2
i1+d2
iN
x2
2−x2
N+y2
2−y2
N−d2
i2+d2
iN
.
.
.
x2
N−1−x2
N+y2
N−1−y2
N−d2
i(N−1) +d2
iN
.(6)
4
BS RSU
RSUC RSUC
SDNController
CentralCloud
CH
MECserver
MECserver
CH
CM
CM
CM CM
FOG FOG
RSU
BS
cellulardatapath
wirelessdata
path
CH:cluster
head
CM:cluster
member
RSUC:RSUcontroller(local
controller)
MEC:Mobileedge
computing
Control
link BS:Basestation
TrafficControl
center
Fig. 1: Software defined and Fog (edge) computing-based on next generation vehicular networks.
Based on the least squares method in (4), the location of
the unknownnode is given by (7) as follows:
b
X= (ATA)−1ATB, (7)
where ATrepresents the transpose of matrix A.
B. Vehicular Software-Defined Network
Fig. 1 abstracts the architecture of the fog-based VSDN. The
vehicles on the road were equipped with either IEEE802.11p
or C-V2X. The architecture includes vehicles, which are
considered as SDN devices and equipped with an OpenFlow-
enabled software switch such as Open vSwitch [18]. The
query- and response-type TMs are exchanged between vehicles
and RSUs. RSUs and other devices at the edge of the VSDN
are considered as either SDN devices or host SDN controllers
to, for instance, assist the main SDN controller in collecting
the global view of all fog-based VSDN network resources.
RSUs participate in edge computing to deliver TMs [1], [6],
[19].
III. SYS TE M MOD EL
We consider the fog-based VSDN model as shown in Fig.
1. The cluster-member vehicles are considered as peer clients
and the CH vehicle as a peer server because it would serve
other cluster member (CM) vehicles to gather connectivity
and mobility data for the VSDN controller. For simplicity,
the CH vehicle is located as closely as possible to the RSUs.
We assume that the SDN controller would forward TM data
communication after the form receives the computing value
of the multicriteria utility function implemented on the top
of the control layer. In addition, the system model uses 4 10
MHz frequency bands of dedicated short-range communication
technology known as service channels (SCHs). Further, these
frequency bands are designated by the SDN controller to
assign the SDN data plane to the query and response TMs,
as discussed in [18]. Furthermore, the controller is supported
by the application plane functions to abstract all decision-
making ability provided by the RSU selection scheme and
SDN devices in the form of RSUs acting as sender data plane
devices.
The clustering-based algorithm provides efficient commu-
nication between vehicles on the road. For this reason, it is
realistic to use the cluster-based algorithm to simplify the
collection of road network topology as an input for the SDN
controller [18]. The system model assumes that the road is
divided into clusters, and a cluster head (CH) is selected for
each cluster. The CH serves three purposes: collecting road
cluster topology (including location) information, communi-
cating with the RSU on behalf of the cluster, and collecting
traffic query request messages. The CH updates the RSUs
about the cluster position along with its network topology.
The topology connectivity helps the controller to select the
appropriate RSU to forward traffic messages (both query and
response) to the data plane efficiently.
A. System Perspective Based On SDN Architecture
RSUs are responsible for assisting the SDN controller to
access the input of the connectivity topology. The communi-
cation completeness and accuracy of connectivity information
5
RSU deployment criteria Road network
performance factors
•Coverage vehicle ratio
•Packet loss
•Cost
•Delay
•Transmission range
Performance parameters
•Packet loss
•Vehicle coverage
•Delay
•Number of RSU
RSU deployment techniques (e.g.)
•Connectivity-oriented maximum
Coverage
•Connectivity Intersection based
RSU allocation
•Budget sparse coverage RSU
deployment
Cluster Head selection
ü3 factors :position,
velocity , signal
quality
üCH selection
RSU announces input
cluster topology
connectivity
Topo lo gy Man ag er
RSU selection Manager
SDN controller
Select best RSUs
deployment
Update flow table on
RSU’s data plane
Routing Manager
Traf fic mess age
(Query/response)
dissemination
Input cluster topology
Fig. 2: Framework fort RSU selection scheme for traffic
message transmission in software-defined vehicular networks.
and decision making are the most important characteristics of
the SDN controller for better network management. fog-based
VSDN. The RSU’ SDN control plane gathers information
about the location, receives power, and relative speed from the
CH in the cluster. This information is sent by the cluster header
using standard safety message beacons in the DSRC control
channel (CCH). In addition, the RSU uses its SDN control
plane to send the input of the cluster connectivity topology to
the central SDN controller. In fact, communication between
RSUs and the SDN controller is based on the physical sidelink
control channels of C-V2X technology [20]. Moreover, RSUs
would also join TM dissemination by selecting a CH vehicle
control plane and updating their flow tables.
We assume that vehicles use the CCH [21] to exchange TM
data through the SDN data plane. The RSUs are equipped
with a C-V2X wireless data plane to capture connectivity
topology information and SDN control plane to convey this
information to the SDN controller. RSUs are like SDN devices
that have flow tables. The SDN controller updates RSU flow
tables through flow-mode packets of the RSU control plane.
Whenever the TCC processes a traffic information query and
sends it back to the RSU, the latter switches to the SDN
control plane to receive flow table updates from the SDN
controller. Afterward, it uses routing rules in its flow tables to
send traffic information to the CH vehicle. Similarly, the CH
vehicle switches to the SDN data plane communication over
the CCH channel whenever it is ready to receive the response
of the TMs.
The SDN controller updates the flow tables of the SDN
devices through their control plane. The flow tables in SDN
devices consist of a set of fields. One of the fields sets
up the matching rules for incoming TM packets along with
actions to be taken when the packet cannot be executed. In
a scenario where there are no matching rules for incoming
packets, the SDN device informs the SDN controller. The
flow table is frequently updated as soon as network topology
changes are reported on the SDN controller. Furthermore, the
RSU frequently downloads current flow table rules from the
Alg. 1 Localization of hidden RSU based on DV-hop algorithm
1: Input: List of reachable CH {CHi,1≤i≤n}with with
their coordinates and Hopsize.
2: output: Estimated position of hidden RSU node r.
3: while RSUi< i < n do
4: if hop count to CH using Eq. (1) == 1 then
5: Use RSSI information to estimate the distance.
6: Return distance using Eq. (2):
7: else
8: Use Maximum Likelihood (ML) for distance.
9: Return distance using Eq. (2):
10: end if
11: end while
SDN controller, allowing the CH vehicle to first switch to the
SDN control plane signaling channel and gather new flow table
updates from the central SDN controller.
B. Localisation of RSUC Using DV-hop Algorithm
Because this study considers a limited number of RSUs for
TM transmission, CHs may have difficulty locating the RSUs
to send the input connectivity topology to RSUs that act as
local controllers. An algorithm for locating hidden RSUs is
presented. Algorithm 1 is used to locate the position of the
RSUs. The localization of RSUs is completed based on the
DV-hop algorithm. The RSUs take the average Hopsize of
their closest CHs as their own average Hopsize. From [22],
experiments indicated that the DV-Hop assisted by RSSI
values is more accurate than the average distance per hop as
compared to the DV-Hop algorithm. In this paper, the RSSI
is used to weigh the number of hops between the CH and
RSU nodes [23]. If the average Hopsize from CH to RSUs is
equal to one, the algorithm utilizes the RSSI information. If the
average Hopsize from CH to RSU is more than three estimated
distances, the coordinates of the hidden RSUs are calculated
using the maximum likelihood to estimate their positions.
A source CH directly sends the request to the RSU, which
after computation stores it before replying to the CH. The
CH then sends beacon messages to the neighboring RSUs.
The CH algorithm 1 is used to locate RSUs. If the RSU
checks and determines that it is in the same radio coverage
range as the CH, it sends a reply message with preconfigured
routing rules in the RSU flow table. If the RSU does not find
a response to the traffic query, it is sent to the TCC, which in
turn processes the traffic query. The SDN controller assigns
routing rules along with an appropriate local controller at the
RSU. The RSU switches to its control plane to request the
SDN controller to update the RSU flow table with new routing
instructions.
IV. RS U SE LE CT IO N- BASED SOFTWARE-DEFINED
NET WORK (RSSD)
In this section, we will discuss the RSU selection for traffic
message transmission in fog-based VSDN.
6
A. RSU Selection
To allow TCC or the edge orchestrator integrated with the
VSDN to access the appropriate RSU, a complex mechanism
is required. The key idea is the CH selection to allows the SDN
controller to manage VSDN network resources and suggest the
appropriate RSUs closer to the CH and efficiently disseminate
TMs among CM vehicles.
For the TM dissemination case, it is important for the VSDN
controller through the edge orchestrator to select the appropri-
ate RSU. Therefore, RSU selection has an important impact
on the VN service quality. In this study, the framework for
the RSU selection scheme for TM transmission in fog-based
VSDNs is shown in Fig. 2, which includes the modules for
RSU deployment criteria, input cluster topology, routing per-
formance combined with road network performance factors,
and control plane management (SDN controller). First, the
RSU deployment criteria collect and provide all the parameters
that the RSU selection manager and SDN controller need to
compute the RSU selection algorithm. In our framework, the
TCC administrators decide on the QoS under different per-
formance parameters of each RSU deployment technique for
different RSU services (e.g., TM delivery, freeway-traffic flow
management, vehicle localization, and individual vehicle path
planning). Second, the topology manager collects information
on the vehicle cluster organization; the CHs are selected to
receive the flow tables for routing rules. Through the input
cluster topology, a set of available RSUs was built. Third, the
SDN controller module combines the information from the
routing module and road network performance requirements
for the calculation of the utility function that determines the
appropriate RSU among available RSUs according to the road
network parameter factors and RSU deployment techniques
that have been put in place by the TCC. To collect the
appropriate network cluster topology information, we propose
a clustering algorithm. In addition, the multicriteria utility is
calculated based on the correct selected weight for each road
network performance factor. Table I describes the notations
and meanings used in the proposed RSSD scheme.
B. CH Selection
1) Modeling CH Vehicle: There are two types of nodes
(vehicles) in the system model architecture: CH vehicle, and
CM This paper defines three (3) factors for selecting the cluster
header vehicle: position, velocity, and signal quality. The
position of each node is obtained from its location information
using a beacon message after a predefined interval (1 s by
default) [24]. The average distance Pibetween CH and CM
should be shorter, which is given by
Pi=1
nXn
j=1 q(xj−xi)2+ (yj−yi)2,(8)
where nis the number of neighboring vehicles ni,(xi, yi)and
(xj, yj)are coordinate values of two involved nodes.
The velocity of CH, Vi, is calculated as the difference
between the velocity of a candidate CM (vi) driving in the
TABLE I: Notation and their meaning.
Notation Meaning
PiAverage distance between the CH and CM
Vivelocity of CM
viVelocity for current road traffic flow
KNumber of vehicles per unit length of roadway
kcCritical density of road traffic flows
kmjam density for road traffic flows
σNumber of one-hop FNs without traffic congestion
SQiactual signal quality
rdmax Maximum vehicle coverage of the RNP with number of RSUs
δaMaximum vehicle coverage of the RSU deployment scheme
φaPacket loss with the RSU deployment scheme
φnpacket loss with RNP with number of RSUs
ζuTotal cost of the RSU deployment scheme
ζnTotal cost of RNP with number of RSUs
τaTransmission range of the RSU deployment scheme
τnTransmission range of the RNP with number of RSUs
ψaDelay with the RSU deployment scheme
ψndelay of RNP with number of RSUs
dDistance between two CMs
NiNumber of neighbor nodes
(x, y)Coordinate values of a node
LLength of roadway
tTime with density of vehicles
nlNumber of lanes
RtTransmission range
same direction and the average velocity for the current road
traffic flow and is given by [25] :
Vi=vi−1
nXn
j=1 vj,(9)
where vjis the velocity of the jth neighbor of the candidate
nodes.
To avoid traffic congestion, the network topology and con-
nectivity of the CM nodes are reflected by the delay of at
least two consecutive hello (standard) beacons received from
a CM to determine the approximate signal quality condition.
The number of CMs with a ddistance is Ni. The number of
vehicles per unit length of the roadway is defined by K. In
road traffic flow, the two considered densities are of two groups
[26]: the critical density kcand jam density kj. Therefore,
kmis the maximum density achieved during congestion. In
general, the traffic congestion density is seven times the critical
density of kc. The inverse of density is the spacing s[26],
which is the center-to-center distance between two vehicles.
The density Kwithin a roadway of length Lat a given time t
is calculated to be equal to the inverse of the average spacing
of Niand is given by
K(L, t) = Ni
L=1
s(t).(10)
The theoretical signal quality is denoted by σ, which repre-
sents the maximum number of CMs within one hop without
creating traffic congestion, and is given by:
σ= 2Rt×K(L, t)×nl/1000,(11)
where Rtis the transmission range, nlis the number of lanes.
The actual signal quality, SQi, measures how close Niis to
the ideal value σas follows:
SQi=|Ni−σ|.(12)
7
The weighting matrix includes the three factors discussed
above. After normalization [25] of the three measurements, as
described below:
a)P0
i=Pi
Pmax
i
, b)V0
i=Vi
Vmax
, c)SQ0
i=SQi
σ.(13)
the weighting matrix, is given as follows:
Ci=P0
i+V0
i+SQ0
i,(14)
where Pmax
idenotes the distance between the ith vehicle
and the possible farthest CM from the ith vehicle, and Vmax
is the limit speed recommended by the TCC on the road
traffic flow. Therefore, a smaller value of Cirepresents the
higher suitability of a CM being elected as a CH. When a
vehicle is free from any cluster, it sends a vehicle information
packet to its neighboring vehicles and allows it to calculate
its competency value (14), which is the basis of cluster head
selection. Each node calculates the competency level to be a
cluster header.
Each CM vehicle recapitulates its coordinates and velocity
in the standard beacon messages. Therefore, the selected CH
vehicle can determine the CM vehicle location and approxi-
mate the CM vehicle signal quality when the second beacon
message received from the CM vehicle. Similarly, the RSUs
gather and forward the cluster connectivity topology along
with its coordinates (RSU location) via the control plane to
the SDN controller through PSSCH. The cluster connectivity
topology information can be appended to PSSCH messages to
avoid additional messages.
After receiving the coordinates of the RSUs and the in-
put of the cluster connectivity topology, the SDN controller
constructs the directed cluster topology connectivity graph.
For simplicity, the signal quality of the cluster header is
assumed to be equal to the RSU closest to the selected CH.
In the graph, each edge represents a connection from one
RSU to another, whereas vertices represent the cluster head
and the member vehicles. For each edge, the SDN controller
queries the corresponding RSU signal quality values. The SDN
controller compares the CH signal quality with a threshold
(this value might be from the input topology module and
decided by the TCC authority) to determined if it is sufficient
to deliver a higher packet reception ratio (PDR). Based on the
coordinates of the RSUs and the signal quality of each edge in
the graph, the SDN controller also decides on the selection of
the RSUs, then computes the routes and updates the flow RSU
tables accordingly. The SDN controller effectively exploits the
management of RSUs to decrease the cost of deploying new
RSUs.
Once the network topology and connectivity model are
available, they can be used by the SDN controller to select
different RSU infrastructures for communicating over different
established clusters. The global view of the SDN controller
encapsulates a centralized role in selecting different RSUs to
serve CH vehicles and minimize the cost of deploying new
RSU infrastructure. The SDN controller assigns routing rules
to RSUs such that two neighbor CHs in formal communication
range use the the same RSU infrastructure. Therefore, the
allocation of RSU resources is highly improved in high vehicle
density situations. In addition, the SDN controller handles
side-to-side RSU by carefully choosing and assigning TM
services to RSUs for distant CHs. Hence, the relay to the
adjacent RSU will be similarly reduced.
C. Multicriteria Utility Function
The evaluation of RSU planning on three RSU assignment
schemes discussed in [27] was used in this study. The study
by [27] evaluates the connectivity-oriented maximum coverage
scheme against the intersection connectivity-based RSU allo-
cation scheme [28] and the latest budgeted sparse coverage
RSU deployment scheme [29]. Three performance parameters
were compared: packet loss ratio, vehicle coverage, and end-
to-end delay for a transmission range from 100 m to 500 m.
The results from [27] were used as input for the road network
performance with the number of RSUs for an urban road.
These performance parameters were used as criteria by the
SDN controller in selecting the appropriate RSU based on the
multicriteria utility function.
The proposed RSU selection scheme was managed on top of
the SDN controller at the application layer. The RSU selection
scheme is mainly based on the multicriteria utility function
that matches predefined decision factors. The multicriteria
utility function is designed for different decision factors of
road network performance (RNP) to select an appropriate RSU
deployment scheme. The decision of RSU selection is based
on different RNP parameters, such as the vehicle coverage
ratio, packet loss ratio, delay, and transmission range. In the
following, we describe the multicriteria utility function based
on the RNP factors already mentioned. The utility function
of the vehicle coverage and the RSU signal quality (Eq. (12))
are important because when the number of RSUs are less than
the maximum number of vehicles on the road, it causes lower
coverage and a higher packet loss ratio. Vehicle coverage is
expressed by the following equation:
µδ(δa) = (0,if δa> rdmax
1−e
γ1δ2
a
γ2+δa,otherwise (15)
where rdmax denotes the maximum vehicle coverage ratio of
the RSU deployment scheme, and δarepresents the vehicle
coverage of the RNP with the number of RSUs. For δa≤
rdmax, the utility function is calculated from [30]. As the
number of vehicles in the cluster increases, each new vehicle
in the cluster increases the utility of vehicle coverage by a
smaller amount, and it is assumed to have a lower perceived
value. TCC prefers an RSU deployment scheme to RNP with
the number of RSUs. For appropriate RSU selection with high
priority, a weight factor γin the utility function for vehicle
coverage and RSU signal quality is introduced. γ1and γ2
denote constant weights for each RSU deployment scheme.
The utility function of the packet loss is given as follows [31]:
µφ(φa) = 1 −e
γ3φ2
a
γ4+φa,(16)
where γ3and γ4are constants, and φais the packet loss for
the TMs.
8
TABLE II: Transmission range and road network performance with number of RSUs for an urban road.
Number of RSUs Transmission range (m) Cost (unit) Vehicle coverage ratio Delay (ms) Packet loss ratio
7 500 10 90 388.28 6.77
15 400 20 88 251.36 15.88
22 200 30 83.1 1271,94 39
31 100 40 59 3811.75 89
TABLE III: RSU deployment scheme and range in an urban road for a transmission range of 500 m.
RSU deployment scheme Packet loss ratio Vehicle coverage ratio Delay (ms) Number of RSUs
Connectivity-oriented Maximum Coverage Scheme 9.25 84.11 348.13 7
Intersection Connectivity based RSU allocation scheme 6.3 97.10 409.98 17
Budget sparse coverage RSU deployment scheme 8.94 97.60 635.93 9
This paper assumes that the number of covered vehicles and
the average signal quality SQ may have different measure-
ments. The cost of deploying an RSU depends on its priority
to deliver TMs, and the RSU priority is determined by the
following:
P rRSU (i) = γ5×fi,veh +γ6×fi,S Q,(17)
where fi,veh and fi,SQ =are the normalized values obtained
by the number of covered vehicles and the average signal
quality of an RSU, respectively. γ5and γ6are the corre-
sponding weights for each factor. From [32], the min—max
normalization is considered to transform data in different units
to obtain values between 0.0and 1.0according to Eq. (18):
fij =xij −min(Xj)
max(Xj)−min(Xj),(18)
where xij is the original value obtained by the jth factor at the
ith RSU. Xjis a set of xij for i= 1,2,3, ..., n containing all
the values obtained by the jth factor for all RSUs. The cost of
installing RSUs depends on the quality of the RSU device and
the costs from device to device. The total cost Cis determined
by the local government or the TCC authorities. It is difficult
to determine the cost of each RSU during the deployment
process because RSUs with different physical RSU devices
are priced differently. Without loss of generality, we allocate
each RSU with unified costs based on each priority [27]. For
RSUs with a priority of less than 0.25 at TCC authority, the
cost is set to 1 unit for each; for RSUs with a priority between
0.25 and 0.5, or between 0.5and 0.75, or between 0.75 and
1, the cost is set to 1.33 units, 1.66 units, or 2units for each,
respectively, [27].
The utility function of the cost is given by the following
equation:
µζ(ζu) = 0, ζn> ζu
ζu
ζu−ζn,0≤ζn≤ζu
(19)
where ζnis the cost of RNP, and ζuis the cost that an RSU
deployment scheme can support in general. The utility for the
transmission range and delay are, respectively, given as
µτ(τa) = 1 −e
γ7τ2
a
γ8+τa,(20)
µψ(ψa)=1−e
γ9ψ2
a
γ10+ψa,(21)
where γ7, γ8, γ9, γ10 are constants, and τaand ψaare the
maximum transmission range and delay for RNP based on
the RSU deployment scheme, respectively.
In this study, we assume that the RSU selection manager
exposed a list of RSU deployment schemes, and the SDN
controller had a global view of the RNP. We assume that the
SDN controller has the strategy for selecting the best RSU
deployment scheme and acts as a leader. Furthermore, the RSU
deployment schemes behave as follows. The utility function
for the SDN controller (leader) is calculated according to
the requirements of the RNP for delivering VN services,
whereas the utility function for the RSU deployment scheme
is calculated according to the parameters of the road networks.
Therefore, this study proposes a multicriteria function for the
SDN controller and RSU deployment schemes.
The utility function for SDN controller is given by
UController =µδ(δa)×µφ(φa)×µψ(ψa)
µτ(τa)×µζ(ζu).(22)
The utility function for RSU deployment scheme is given by
Ursu =µδ(rdmax )×µφ(φn)×µψ(ψn)
µτ(τn)×µζ(ζn).(23)
To provide an illustration for a better understanding of
the proposed RSU selection, we have taken an example of
three RSU deployment schemes [27]: connectivity-oriented
maximum coverage scheme, intersection connectivity-based
RSU allocation, and budget sparse coverage RSU deployment,
as shown in Table III. The utility function of each RSU deploy-
ment is computed using the packet loss ratio, vehicle coverage
ratio, delay, and transmission range. The RSU deployment
scheme is associated with several RSUs. Table II delineates
the RNP data after analyzing the evaluation of RSU planning
on three RSU assignment schemes from [27]. When the SDN
controller obtains the RSU deployment scheme suggested by
the RSU selection manager, the SDN controller computes
the utility function according to the RNP with the available
number of RSUs. The utility function of the SDN controller
was checked using the utility function of the RSU deployment
scheme. For example, if the RNP with 7 RSU has a higher
utility function, the connectivity-oriented maximum coverage
scheme is selected.
D. RSU Deployment Technique Based SDN Controller
The system model features an SDN controller collects
information from the application system, which includes the
following modules: routing manager, RSU selection manager,
and topology manager. First, the RSU selection manager
9
searches for RSUs under the logical control of the SDN
controller. The priority of RSUs to deliver TMs is decided
based on the number of available RSUs. The RSU deployment
with fewer RSUs and delay is set to top priority and RSU
deployment with a higher delay with an important number of
RSUs is deployed with low priority. Then, the SDN controller
selects only the RSU deployment scheme that can meet the
requirements of RNP for TM transmission. The RSU selection
module exposes a list of RSU deployment schemes to the SDN
controller, which chooses a minimum number of RSUs equal
to or less than the RSU deployment scheme. The appropriate
RSU selected based on the computation of the utility function
receives the TM and routing paths according to the routing
rules generated from the SDN controller. These routing rules
were installed in the flow table of the RSU switch. The
preference or alternative of selecting an RSU to assign the
task of TM transmission at a current time tis compared after
a given time (t−1). If the new computing utility function
value has more improvements than the previous computing
time, then the SDN controller selects or requests another RSU
deployment scheme.
E. Traffic Service Delivery
In this subsection, we propose a solution to select RSUs for
efficient traffic delivery that complies with the requirements of
the RSU deployment scheme of authority. We also describe an
algorithm for traffic delivery on the selected RSU. For traffic
service delivery, the SDN controller can follow several strate-
gies. When it is an individual traffic request raised by a CM
vehicle, such as an in-vehicle speed limit, the SDN controller
can route the traffic response directly to the interested vehicles
using the shortest path. When the traffic response should be
delivered in a cooperative manner or involves a large cluster,
the SDN controller can organize delivery by sending it directly
to the CHs. In each cluster, each CM vehicle receives part
of the traffic information, and then it disseminates the traffic
information to other CM vehicles.
The process of traffic message dissemination allows the
RSU to send back TMs to the query CM vehicles through
the CH vehicle. The data packet of the TM from the TCC is
forwarded to the destination using an RSU selection scheme
based on the SDN controller of the fog-based VSDN system
model. The SDN controller is responsible for maintaining a
table for carrying and modifying flow tables to provide stable
routing paths from TCC to CM vehicles or individual vehicles.
RSU acts as a local control to increase the robustness of the
SDN controller because it stands as a single and central point
to hold the global view of the road network.
A flow chart of traffic delivery is shown in Fig 3. If there
is no rule matching the incoming packets in the flow table of
the RSU control plane, then those packets are forwarded to
the SDN controller according to the unmatched packet action
configured in the flow entries of the RSU’s control plane.
V. RE SU LTS AND DISCUSSIONS
This section presents the simulation setup for evaluating the
proposed RSSD scheme with the main purpose of TM dissem-
ination with an appropriate RSU. The network simulation used
Start
Query vehicle send query
request
Get information of
neighbor RSU
No Locate hidden RSU
using Limit-DV-hop
algorithm
Does RSU
has
response ?
Send query request
to TRC
No
TRC process the
query response/
Yes
Send query request to RSU
yes
No
Yes
Send route to the cluster
head
TRC has warnings to
broadcast
B
A
RSU assi gnment
select best RSU
deployment
SDN controller
configure route for best
RSU perform ance
Cluster head send request
response to query ve hicle
Is CH in
communication
range with RSU?
Is RSU’s control
plane has route?
End
Fig. 3: The flow chart of traffic message transmission based
on the proposed RSU selection scheme.
in this study was based on the OMNeT++ simulator [33]. The
VeinsLTE [34] framework is also integrated into OMNeT++
to simplify the simulation of vehicular communication for
both DSRC and LTE. We imported the OpenFlow Module for
OMNeT++ 5.4+ and INET 3.6 [35] to integrate the OpenFlow
protocol and SDN technology in the simulation.
The network consisted of two parts. The first part is the SDN
controller node and has the task of establishing and holding
links within the local controllers, which are coupled with
switches in the network. The local controller helps register,
log nodes, allocate addresses, and process the flow table. The
second part is the TCC server nodes, which are responsible
for the network query packet reception and processing.
The simulation scenario and parameters are listed in Ta-
ble IV. Traffic simulators were used to simulate urban mobility
(SUMO) version 0.30 [36]. The traffic scenario was down-
loaded from the open street map (OSM) [37] of a portion of
the city of San Francisco, USA. The OSM file was converted
and processed using SUMO simulator tools to obtain trace
files. The latter was injected into OMNeT++ to perform the
simulations. The vehicle density was varied from 100 to 500
vehicles. The vehicle speed varied from to 15–40 km/s. The
RSU is distributed in numbers of 10 and is equipped with
both DSRC and cellular interfaces (LTE). The transmission
range to the cluster head was 500 m. The query and response
data traffic are UDP with packet sizes of 400 bytes and 1000
bytes, respectively. The fixed query transmission time and
10
TABLE IV: Main simulation parameters and settings.
Parameters values
Traffic information message
Reponse packet size 1000 bytes
Query packet size 400 bytes
Packet generate rate 2-5 packets/sec
Broadcast packet size rate 10 bytes
RSSD parameters
Cluster transmission range 500 m
Query processing time 10 ms
Channel information broadcast 10 ms
Sensitivity -89 dbm
IEEE 802.11 parameters
Transmission range 500 m
Carrier frequency 5.890e9 Mhz
Data rate 6 Mbps
Number of channels 1 CCH and 4 SCH
Propagation model
pathloss two-ray interference model
fading Nakagami m = 1.3
General parameters
Number of RSU 10
Simulation limit time 400 s
Simulation of repetition run 5
Mobility Model Freeway
simulation area 5000 m x 5000 m
information broadcast were set to 10 ms each. The packet
generation rate was set to 2–5 packets/s. The query processing
time at the RSU was set to 10 ms. The transmission power was
20 mW. For IEEE 802.11p, the transmission range was set to
500 m, the data rate was 6 Mbps, and the carrier frequency
was 5.890e9 MHz. A simulation time of 400 s was used and
the results are reported with an average of 5 realizations. d
We configured the freeway mobility model for the vehicle
movement.
A. Simulation Scenarios for RSSD Scheme
The main goal of this study is to deliver TMs (query vehicle
or traffic information from the TCC) using the proposed
protocol based on the RSU selection scheme and the DV-hop
localization algorithm to locate hidden RSUs, with or without
the local and central controller. The following three scenarios
are simulated to evaluate the proposed RSU selection scheme
based on SDN for traffic message transmission:
1) RSU Selection based SDN Controller: In the VSDN,
each RSU data plane is associated with specific flow entries
in the flow tables. Some RSUs may serve several requests
that affect the flow table size. An important request at the
flow table and the RSU switch received either from query
vehicles or TCC causes a longer processing time. Thus, this
issue affects the packet-delivery ratio. In the fog-based VSDN,
the selection of the RSU depends on the multicriteria utility
function; SDN control may assign traffic delivery according to
the best RSU deployment scheme. Thus, even when an RSU is
completely occupied, the traffic is assigned to the RSU based
on the network performance with the RSU. Therefore, the RSU
selection scheme improves the traffic information delivery.
2) Local Control Plane to Speed up the Global View of the
Network: The decision of routing paths in SDN may increase
the network load balancing (NLB) at the SDN controller [38].
This condition can lead to inaccurate path–route decisions. The
use of the RSU to act as a local controller in the proposed RSU
selection scheme minimizes the NLB. When local controllers
are used, the failure of the SDN controller cannot affect the
PDR.
3) Unknown Position of Local Controllers: An unknown
position of the local controller causes packet loss, which
leads to traffic query processing delays. To allow the CH to
locate the local controllers which are considered as RSUs,
Algorithm 1 is executed. Minimizing the delay in the collec-
tion of input topology at the SDN controller would speed up
the selection of the appropriate RSU for traffic delivery. The
localization of RSU based on the DV-hop algorithm allows
SDN to construct a topology graph and assign routing paths
for traffic delivery.
B. RSU-Selection Algorithm Comparison
The utility in the RSSD includes two parts: the use of
RSU deployment and the use of the SDN controller to update
the OpenFlow switches of the RSU data plane devices. To
design an effective RSU selection-based SDN technology,
some aspects should be considered. First, although the RSU
deployment scheme does not affect the RNP, in areas with
better RNP, vehicles may receive services from multiple
RSUs, and whether the routing tables using SDN technology
under the capacity of local OpenFlow switches constraints
are properly updated may affect the delivery delay. Second,
there are some (3) possible deployment schemes. For each
RSU deployment strategy, the SDN and RSU deployment
utilities are different. To obtain the optimal solution, all RSU
deployment schemes should be compared, and the complexity
requires a reliable task assignment of the TM delivery. Finally,
to maximize the total utility, there is a tradeoff between the TM
delivery and update of the RSU data plane flow tables using the
SDN controller. The proposed scheme should comprehensively
consider the relationship between utility maximization and TM
delivery delay requirement.
Our architecture based its TM delivery decisions on utility
functions, SDN, and RSU deployment scheme. It describes the
value of TM delivery to TCC based on RNP requirements. It is
intuitively useful to consider utility as the amount that a TCC
would pay for data delivery (e.g., $10); this is not strictly
correct, but we will treat utility as a quantitative measure
of satisfaction. Real-world utility functions are impractical
for capturing and using a system. Nevertheless, economics
and system architects have found utility functions to be an
applicable way to specify useful system operations.
The performance comparisons between the greedy algo-
rithm [39] and the proposed RSSD are presented in Fig. 4).
The benchmark for greedy algorithm considers RSU deploy-
ment and TM assignment. On the other hand, the proposed
RSSD assumes that RSU deployment is designed as a soft-
ware module running on separate hardware, and the SDN
controller conveys routing rules issued from the application
layer that hosts the RSU deployment control module. The
greedy algorithm seeks to maximize utility increase in each
selection step. This means that for each iteration, if there is
one unselected RSU that serves a particular road segment, the
11
Fig. 4: Algorithm comparison for RSU selection.
Fig. 5: Influence of SDN for RSU selection.
RSU is then selected to service a task of that road segment.
The simulation investigated the value of using utility functions
to guide TM delivery. We modeled one application by sending
traffic lights to their states. In this experiment, we specified
appropriate utility functions for TM delivery and compared
our utility–driven SDN controller and RSU deployment.
Fig. 4 compares our approach with the greedy algorithm.
The vertical axis is the amount of utility delivered, summed
over the TM application discussed (traffic lights sending their
state). Our RSSD has a higher TM delivery and utility than the
greedy algorithm. The RSSD scheme delivers a utility sum of
approximately 5.3×106, whereas the greedy algorithm delivers
only around 2.5×106. To deliver the same utility, the RSU
deployment cost and SDN controller computation cost would
increase in both approaches. Our approach does a better job
in utilizing SDN controller, low updates of flow entries at the
RSU, and delivers useful amounts of data.
C. Influence of the SDN Technology
To demonstrate the influence of the SDN approach on
RSSD, we increased the number of RSUs to approximately
10–60 RSUs. The number of flow entries on the RSU open-
Flow switch was set to 100, 500, 1000, 2000, and 3000 for
comparison. As shown in Fig. 5, the number of selected RSUs
decreased with the increase in flow entries. When the number
of flow entries at the RSU openFlow switch is low, the RSSD
prefers to deploy more RSUs to achieve better performance.
However, when the number of entries is relatively high, the
RSSD reduces the number of selected RSUs while satisfying
the RNP. When fewer RSUs are selected owing to the high
number of flow entries, the delivery ratio of TM delivery also
decreases.
D. Impact on Updating Traffic Messages
To evaluate the impact of updating TMs, we considered a
case called initiate-and-update TMs, referred to as“I&U”, but
the decision of which updates to load is randomized. Fig. 6a
shows the ratio between the delivered utilities via the I&U
approach for several network bandwidth settings. This ratio
is approximately five. This suggests that I&U can deliver far
more utility. This shows the advantages of using the SDN
technology for updating TMs; any updates of the flow entries
for routing paths when initiating the TMs are not required.
In practice, the update of TMs transmitted to vehicles may
change with RNP. Consequently, the estimation of the size
data of TMs based on the algorithm would have an impact
on the delay. To investigate the influence of the variation in
the size of the data for TMs due to updating the TMs, we
compare the performance with and without TM updates with
a variation in the size of the updated TMs in Fig. 6b). The
variations are set to ±10%,±20%, and ±30%, respectively,
which means that the size of the TMs varies within a given
range. As shown in Fig. 6c, even when TMs are updated,
the maximum average delays are within the range, and the
average delays vary slightly. From the above figures, there is
no evidence that the delivery delay will witness any changes
as the estimation variation increases. Thus, we can conclude
that the delay performance is not significantly affected by the
size variation of TMs.
E. Results Analysis in Comparison with Existing Works
The RSSD scheme is evaluated in comparison with two
SDN-based schemes, HSDV [40], and a VSDN-based hetero-
geneous wireless interface [41]. These existing schemes were
chosen because both schemes use the concept of local con-
trollers to reduce the signaling network traffic of the controller.
The VSDN architecture proposed in [41] proposes a network
selection and data dissemination protocol. Network selection
12
(a) Utility ratio of initial and Update TMs. (b) Utility and TMs service within variation of TMs. (c) Delay within the update of TMs.
Fig. 6: Impact on updating Traffic Messages.
is executed using utility functions and the game theory ap-
proach. In HSDV, the controller manages the dissemination
by selecting the next hop that is closest to the destination.
Furthermore, a fog-assisted cooperative protocol for traffic
message transmission in vehicular networks (FACP) [42],
which does not support the SDN controller, was compared
to evaluate the impact of the proposed scheme.
The average end-to-end (E2E) delay, packet delivery ratio
(PDR), routing overhead, and average throughput are the
performance metrics selected to compare the proposed scheme
with the existing scheme:
•E2E delay evaluates the average time taken by transmitted
packets to their respective destination nodes.
•PDR determines the ratio between packets successfully
delivered to the total number of packets transmitted.
•Routing overhead evaluates control packets being sent
through the network. The routing overhead defines the
ratio of the control packets sent to the total number of
packets.
•The average throughput supports the evaluation of the
average rate at which packets have been successfully
received by the destination node over the communication
channel.
1) Packet Delivery Ratio: Fig. 7a shows the packet delivery
function versus vehicle density. In the simulation, as the
number of vehicles increases, the PDR increases for both the
RSSD scheme assisted by one central controller and no-SDN-
based. The use of multiple local controllers at RSU reduces
the PDR of the RSSD scheme as the vehicle density increases.
When multiple controllers are used, a greater number of
queries from the vehicle are seemingly forwarded to the
TTC for processing. To disseminate TMs, the SDN controller
may select a different RSU than the one that was previously
selected and located close to the CH. This reduces the PDR.
In the case of cooperative dissemination of a warning query
from TTC, the central SDN controller assists the proposed
scheme by providing stable route information based on the
network performance measured by the number of RSU. In
this case, relying on the local controller is not required. The
RSSD scheme assisted with local controller outperforms the
one with only one central controller because the local control
has the query response and route to the query vehicles and
hence, does not need to forward the query request to the TCC,
which may trigger the RSU manager to provide the best RSU
deployment to the SDN controller. This reduces the number of
messages exchanged between RSU and TCC, which reduces
packet collision in the SDN controller to abstract the global
view of the network and incurs less PDR due to the number of
packet loss count from the approach of a relay on forwarding
nodes to reach the RSUs. At a vehicle density of 300, the
multicontroller has a PDR of 95.18, where the use of the
central controller has 94.45 and a PDR value of 90.09 of a
nonSDN based scheme.
Fig. 7b shows the PDR versus vehicle density. In general,
the low density of vehicles causes link unavailability. This
causes the uptick of PDR. The PDR for VSDN and HDSV
increases as the number of vehicle density increases, i.e.,
a smaller number of packets dropped. However, the PDR
of the proposed scheme reduces as the vehicle density in-
creases. Generally, with the proposed scheme, the PDR is
stable regardless of the density of nodes. The SDN controller
approach is used for the proposed scheme. VSDN features a
heterogeneous wireless interface and HSDV, except for the
FACP protocol. The proposed scheme enhances the PDR
because the topology manager reduces the loss of connectivity
through the global view of the network, which is known
in advance and updated frequently. The routing paths are
predefined in the OpenFlow switch, which reduces the flow
of messages exchanged between forwarding nodes, and then
decreases packet collision. Clustering nodes also reduces the
transmission loads between vehicles and RSU infrastructures.
If the routing is not regulated by an SDN controller as in
13
(a) Packet delivery ratio of the RSSD scheme.
(b) Packet delivery comparison of the RSSD scheme.
Fig. 7: Packet delivery versus vehicle density.
FACP, the PDR is lower because each node must select the
next RSU, which is sometimes hidden in the query vehicles.
The proposed scheme has a stable PDR in VSDN compared to
the three existing schemes when the vehicle density is small
or large. The RSU can keep updated route information for
previous query traffic messages from the cluster head because
the latter would also update the flow tables with routing rules
received from the local controller. At a vehicle density of 100,
the PDR of the proposed scheme is 94.82 %, whereas for
VSDN using a heterogeneous wireless interface, HSDV, and
FACP, it is 80.64 %, 68.04 %, and 97.47 %, respectively.
2) Average Throughput: Fig. 8a shows the average through-
put. For an increasing number of nodes, the average throughput
of the proposed RSSD scheme with the SDN controller in-
creases for all scenarios. As the number of vehicles increases,
the connectivity is stable between CMs; consequently, the
RSSD scheme fastens the transmission packets. However, the
RSU selection scheme based on the utility function provided
by the SDN controller outperforms the use of a local controller
to generate routes to the RSU and the nonSDN-based scheme.
The RSSD scheme uses the best RSU deployment scheme as
determined by the controller after the RSU selection manager
(a) Average throughput of the RSSD scheme.
(b) Average throughput comparison of the RSSD scheme.
Fig. 8: Average throughput versus vehicle density.
suggests a list of different RSU deployment options and based
on the performance of the RNP with the number of RSUs. The
RSSD scheme also uses the DV-hop localization algorithm to
allow the CHs to determine the position of RSUs. The SDN
controller uses the input topology and RSU selection managers
to provide the appropriate RSU to the controller to transmit
the traffic query or response query from TCC. Consequently,
the cost of deploying RSU is privileged, and the best routes to
query response through RSU are considered, which decreases
the collision rate and thus increases throughput. At vehicle
density 100, the average throughput using the RSSD scheme
assisted by the local controller is 94.57 kbps, whereas 93.14
kbps and 87.46 kbps are the average throughput of proposed
scheme assisted with a central SDN controller and nonSDN
based scheme, respectively.
Fig. 8b shows the average throughput with respect to the
vehicle density. The proposed scheme has a lower average
throughput compared to the existing SDN-based schemes.
This is because the query vehicles are transmitted from RSU
when they have the update route information in their RSU
14
(a) Average end-to-end delay of the RSSD scheme.
(b) Average end-to-end delay comparison of the RSSD scheme.
Fig. 9: Average end-to-end delay versus vehicle density.
control plane. VSDN using a heterogeneous wireless interface
provides more sustainable and better performance than the
proposed scheme, HSDV. The selection of the best routes
predicted by the SDN controller is critical to achieving higher
average throughput. At a vehicle density of 100, VSDN using a
heterogeneous wireless interface appears to have 131.51 kbps,
whereas 93.67 kbps and 111.45 kbps are the average through-
put of HSDV and the proposed scheme, respectively. There-
fore, on increasing the number of vehicle density, the average
throughput increases gradually for all discussed schemes.
3) Average End-to-End Delay: Fig. 9a shows the average
E2E delay as a function of delay versus vehicle density,
the number of vehicles is 500. In the proposed scheme, the
higher the number of vehicles, the larger the E2E delay. In
general, the connectivity is stable as the number of vehicles
increases. The results show that as the number of query
requests increases proportionally to the number of vehicles,
the RSU selection process at the SDN controller increases
with the number of RSUs available for forwarding the query
response to source nodes. In this paper, the forwarding nodes
are not considered, and the protocol uses a DV-hop localization
algorithm to find hidden RSUs to process the query from the
vehicle. The algorithm to find the hidden RSUs increases the
E2E delay as the number of nodes increases. However, the
proposed scheme assisted local controllers at RSU in selecting
reliable routing paths to deliver TMs. The presence of local
controllers allows the SDN controller to compute the utility
function for determining appropriate RSU deployment scheme
only for new CHs established. Hence, the proposed scheme
with multiple controllers has less delay and provides higher
packet reception of query with a minimum number of RSUs
than using one central SDN and nonSDN-based scheme. At
a vehicle density of 200, the E2E delay experienced by the
proposed protocol assisted with local controllers is 24.49 ms
which is lower than the 28 ms from relying on only the central
SDN controller and 31.87 ms in the nonSDN-based scheme.
Fig. 9b shows the average E2E delay. The proposed scheme
decreases the average E2E delay as the number of vehicles
increases. This is because when the CH vehicle is selected,
the cluster header has a high probability of selecting a group
of vehicles driving in the same direction. The delay is reduced
gradually because the path of transmitting traffic message is
established from the SDN controller based on the best RSU
assignment. The latter is determined after the computation
of a utility function based on the network performance with
the available number of RSU. The SDN controller configures
new path routing rules in case a traffic query response is
generated by the TTC; otherwise, the local controller holds
ideal routes information to the query vehicles grouped in their
respective cluster region, which is under RSU control. At a
vehicle density of 100, the proposed scheme has an E2E delay
of 23.27 ms, which is lower than 50,64 ms in VSDN using
a heterogeneous wireless interface, 66,87 ms in HDSV, and
84.14 ms in FACP. VSDN using a heterogeneous wireless
interface considers calculating the duration of the route be-
fore it is selected and injected to the local controller which
would increase processing latency. The proposed scheme uses
the assigned RSU based on the RSU deployment selected
according to network performance as soon as the input of
the topology is classified in the cluster. Thus, the DV-hop
localization algorithm fastens the RSU location because the
cost of deployment is important. VSDN using a heterogeneous
wireless interface performs better than HSDV and FACP.
4) Routing Overhead: Fig. 10a shows the routing overhead
with different values of vehicle density. In high traffic density,
the routing overhead of the proposed with local controllers
decreases, whereas the assistance of the central cloud and
nonSDN-based experiences an increase in routing overhead.
This is due to the establishment of a cluster head close
to the query vehicle, which reduces routing messages while
disseminating traffic response from the TCC. Hence, the input
topology is forwarded through cluster vehicle’s control plane
to RSU, implying that no beacon messages are exchanged
between the query vehicle and the RSU. However, the SDN-
based approach, assisted by local controllers and the central
controller, is the basis of the lower routing overhead when
compared to the proposed RSU assignment without the SDN
concept. This is based on the use of a logical controller
15
(a) Routing overhead of the RSSD scheme. (b) Routing overhead comparison of the RSSD scheme.
Fig. 10: Routing overhead versus vehicle density.
that reduces the number of controller messages using a local
controller, which communicates with the SDN controller only
if the query request is new and has often been assigned to
carry query response to RSU. In the nonSDN-based scheme,
the query vehicle uses beacon messages to construct the
routing to the RSU to allow the latter to process the query.
In addition, the localization of the hidden RSU using the DV-
hop localization algorithm allows the cluster header to locate
the hidden RSU. Thus, the faster the cluster head locates the
RSU, the more the local controllers use the input topology to
construct the route information, which consequently reduces
the link failure by decreasing the routing overhead. At vehicle
density 200, the routing overhead of the proposed scheme
assisted with multiple controllers is 20.95, whereas it is
21.54 and 23.17 for a central controller and nonSDN-based
scheme, respectively. Fig. 10b shows the routing overhead in
comparison to the proposed RSSD scheme and the existing
scheme. The proposed scheme has a lower routing overhead
compared with the existing scheme based on SDN. This is
because the SDN controller can keep selecting the same RSU
for a certain time, and there are unmatched packets sent to the
SDN controller. The flow tables of the RSU maintain route
information in their RSU control plane for a longer period.
VSDN using a heterogeneous wireless interface and HSDV
increases the routing overhead as the number of vehicles
increases. The RSU selection predicted by the SDN controller
is the key to achieving a lower routing overhead.
VI. CONCLUSION
In this article, we presented a novel RSU selection scheme
based on SDN for traffic message transmission. The proposed
scheme consists of three steps: cluster head selection, RSU
selection, and multicriteria utility functions based on road
network parameters. The CH selection allows the discovery
of the road network connectivity topology so that the SDN
controller can construct a network graph for better routing rule
decisions. The RSU selection steps are based on a comparison
of the utility function computed by the SDN controller based
on the road network performance against the utility function
performed by the RSU selection manager based on existing
RSU deployment schemes. Based on the RSU selection, we
formulate the traffic message delivery where the DV-hop lo-
calization algorithm is used to locate hidden RSUs for control
signaling between SDN controllers and local controllers at the
RSU. From the simulation results using OMNeT++ assisted
with the urban mobility simulator SUMO, VeinsLTE, and
OpenFlow, we found that the proposed scheme assisted by
local and central controllers outperforms the nonSDN-based
scheme, HSDV, and FACP with regard to routing overhead,
average end-to-end delay, and average throughput.
In future work, we will consider the use of LTE device-
to-device to disseminate TMs based on the proposed RSSD
scheme with the final objective of reducing traffic accidents
and improving traveling efficiency via fog computing and
VSDN. Additionally, we will investigate the optimization of
the placement of the SDN controller to further boost the
capability of traffic message transmission in VSDN.
REFERENCES
[1] Q.-V. Pham, F. Fang, V. N. Ha, M. J. Piran, M. Le, L. B. Le,
W. Hwang, and Z. Ding, “A survey of multi-access edge computing
in 5G and beyond: Fundamentals, technology integration, and state-of-
the-art,” IEEE Access, vol. 8, pp. 116974–117 017, Jun. 2020.
[2] M. Jia, J. Cao, and W. Liang, “Optimal cloudlet placement and user
to cloudlet allocation in wireless metropolitan area networks,” IEEE
Transactions on Cloud Computing, vol. 5, no. 4, pp. 725–737, Oct.-
Dec. 2015.
[3] M. A. Salahuddin, A. Al-Fuqaha, and M. Guizani, “Software-defined
networking for RSU clouds in support of the internet of vehicles,” IEEE
Internet of Things Journal, vol. 2, no. 2, pp. 133–144, Apr. 2015.
[4] H. Hong, P. Tsai, A. Cheng, M. Y. S. Uddin, N. Venkatasubramanian,
and C. Hsu, “Supporting internet-of-things analytics in a fog computing
platform,” in 2017 IEEE International Conference on Cloud Computing
Technology and Science (CloudCom), 2017, pp. 138–145.
[5] Q.-V. Pham, L. B. Le, S.-H. Chung, and W.-J. Hwang, “Mobile edge
computing with wireless backhaul: Joint task offloading and resource
allocation,” IEEE Access, vol. 7, pp. 16444–16 459, Jan. 2019.
16
[6] T. Taleb, K. Samdanis, B. Mada, H. Flinck, S. Dutta, and D. Sabella,
“On multi-access edge computing: A survey of the emerging 5G net-
work edge cloud architecture and orchestration,” IEEE Communications
Surveys & Tutorials, vol. 19, no. 3, pp. 1657–1681, Thirdquarter 2017.
[7] L. Nkenyereye, J. Y. Hwang, Q.-V. Pham, and J. S. Song, “Virtual IoT
service slice functions for multi-access edge computing platform,” IEEE
Internet of Things Journal, 2021.
[8] W. B. Jaballah, M. Conti, and C. Lal, “A survey on software-defined
VANETs: Benefits, challenges, and future directions,” arXiv preprint
arXiv:1904.04577, 2019.
[9] D. Ros´
ario, J. Camargo, J. Rochol, M. Gerla, C. Both, J. Nobre, and
M. Schimuneck, “Service migration from cloud to multi-tier fog nodes
for multimedia dissemination with QoE support,” Sensors, vol. 18, p.
329, Jan. 2018.
[10] J. C. Nobre, A. M. de Souza, D. Ros ´
ario, C. Both, L. A. Villas,
E. Cerqueira, T. Braun, and M. Gerla, “Vehicular software-defined
networking and fog computing: Integration and design principles,” Ad
Hoc Networks, vol. 82, pp. 172–181, Jan. 2019.
[11] A. Mahmood, W. E. Zhang, and Q. Z. Sheng, “Software-defined
heterogeneous vehicular networking: The architectural design and open
challenges,” Future Internet, vol. 11, no. 3, 2019.
[12] X. Ge, Z. Li, and S. Li, “5G software defined vehicular networks,” IEEE
Communications Magazine, vol. 55, no. 7, pp. 87–93, Jul.. 2017.
[13] D.-J. Deng, S.-Y. Lien, C.-C. Lin, S.-C. Hung, and W.-B. Chen, “Latency
control in software-defined mobile-edge vehicular networking,” IEEE
Communications Magazine, vol. 55, pp. 87–93, Aug. 2017.
[14] X. Cheng and B. Huang, “A center-based secure and stable clustering
algorithm for VANETs on highways,” Wireless Communications and
Mobile Computing, vol. 2019, pp. 1–10, Jan. 2019.
[15] G. Song and D. Tan, “Two novel DV-hop localization algorithms for
randomly deployed wireless sensor networks,” International Journal of
Distributed Sensor Networks, vol. 11, pp. 1–9, Jul. 2015.
[16] L. Girod and D. Estrin, “Robust range estimation using acoustic and
multimodal sensing,” in IEEE International Conference on Intelligent
Robots and Systems, vol. 3, Feb. 2001, pp. 1312 – 1320.
[17] X. Chuan, “Research on improved DV-HOP localization algorithm
based on weighted least square method,” in 2008 IEEE International
Symposium on Knowledge Acquisition and Modeling Workshop, Dec.
2008, pp. 773–776.
[18] M. Azizian, S. Cherkaoui, and A. S. Hafid, “Vehicle software updates
distribution with SDN and cloud computing,” IEEE Communications
Magazine, vol. 55, no. 8, pp. 74–79, Aug. 2017.
[19] R. Yu, Y. Zhang, S. Gjessing, W. Xia, and K. Yang, “Toward cloud-
based vehicular networks with efficient resource management,” IEEE
Network, vol. 27, no. 5, pp. 48–55, Sep. 2013.
[20] D. W. Griffith, F. J. Cintr´
on, and R. A. Rouil, “Physical sidelink control
channel (PSCCH) in mode 2: Performance analysis,” in 2017 IEEE
International Conference on Communications (ICC), May 2017, pp. 1–
7.
[21] K. A. Hafeez, A. Anpalagan, and L. Zhao, “Optimizing the control
channel interval of the DSRC for vehicular safety applications,” IEEE
Transactions on Vehicular Technology, vol. 65, no. 5, pp. 3377–3388,
May 2016.
[22] O. Cheikhrouhou, G. Bhatti, and R. Alroobaea, “A hybrid DV-Hop
algorithm using RSSI for localization in large-scale wireless sensor
networks,” Sensors, vol. 18, p. 1469, May 2018.
[23] S. Tian, X. Zhang, P. Liu, P. Sun, and X. Wang, “A RSSI-based DV-
Hop algorithm for wireless sensor networks,” in 2017 IEEE Pacific
Rim Conference on Communications, Computers and Signal Processing
(PACRIM), Oct 2007, pp. 2555 – 2558.
[24] C. Wu, T. Yoshinaga, X. Chen, L. Zhang, and Y. Ji, “Cluster-based
content distribution integrating LTE and IEEE 802.11p with fuzzy logic
and Q-learning,” IEEE Computational Intelligence Magazine, vol. 13,
pp. 41–50, Feb. 2018.
[25] S. Yongyue, P. Xiao-Hong, and B. Guangwei, “Efficient V2X data
dissemination in cluster-based vehicular networks,” in The Seventh In-
ternational Conference on Advances in Vehicular Systems, Technologies
and Applications, Feb. 2018, pp. 1–6.
[26] P. Kachroo and K. Ozbay, Traffic flow theory, ser. Advances in In-
dustrial Control. Springer International Publishing, Jan 2018, no.
9783319692296, pp. 57–87.
[27] L. Xue, Y. Yang, and D. Dong, “Roadside infrastructure planning scheme
for the urban vehicular networks,” Transportation Research Procedia,
vol. 25, pp. 1380–1396, Dec. 2017.
[28] J. Chi, Y. Jo, H. Park, T. Hwang, and S. Park, “An effective RSU
allocation strategy for maximizing vehicular network connectivity,”
International Journal of Control and Automation, vol. 6, pp. 259–270,
Jan. 2013.
[29] C. Silva, A. Aquino, and W. Meira Jr, “Deployment of roadside units
based on partial mobility information,” Computer Communications,
vol. 60, pp. 28–39, Feb. 2015.
[30] R. Fei, K. Yang, S. Ou, S. Zhong, and L. Gao, “A utility-based dynamic
bandwidth allocation algorithm with QoS guarantee for IEEE 802.16j-
enabled vehicular networks,” in 2009 International Conference on Scal-
able Computing and Communications; Eighth International Conference
on Embedded Computing, Jan. 2009, pp. 200–205.
[31] M. Chahal and S. Harit, “Network selection and data dissemination
in heterogeneous software-defined vehicular network,” Computer Net-
works, vol. 161, pp. 32–44, Oct. 2019.
[32] K. Gibert, M. S `
anchez-Marr`
e, and J. Izquierdo, “A survey on pre-
processing techniques: Relevant issues in the context of environmental
data mining,” AI Communications, vol. 29, pp. 1–37, Dec. 2016.
[33] A. Varga and R. Horing, “An overview of the OMNeT++ simulation
environment,” in 1st International Conference on Simulation tools and
techniques for communications, networks and systems workshops, 2008.
[34] F. Hagenauer, F. Dressler, and C. Sommer, “A simulator for heteroge-
neous vehicular networks,” in IEEE Vehicular Networking Conference,
VNC, vol. 2015, 12 2014, pp. 185–186.
[35] inet-framework. (2017) OpenFlow Module for OMNeT++ 5.4+ and
INET 3.6. https://github.com/inet-framework/openflow.
[36] Sumo-software. (2019) Inet framework. http://sumo.dlr.de/index.html.
[37] Openstreemap. (2019) Inet framework. https://www.openstreetmap.org/.
[38] J. Shaharam, B. Amin, and S. Mina Soltani, “On the use of the
genetic programming for balanced load distribution in software-defined
networks,” Digital Communications and Networks, vol. 05, pp. 288–296,
Nov. 2019.
[39] V. Chvatal, “A greedy heuristic for the set-covering problem,” Math.
Oper. Res., vol. 4, no. 3, p. 233–235, Aug. 1979. [Online]. Available:
https://doi.org/10.1287/moor.4.3.233
[40] S. Correia, A. Boukerche, and R. Meneguette, “An architecture for hi-
erarchical software-defined vehicular networks,” IEEE Communications
Magazine, vol. 55, pp. 80–86, Jan. 2017.
[41] M. Chahal and S. Harit, “Network selection and data dissemination
in heterogeneous software-defined vehicular network,” Computer Net-
works, vol. 161, pp. 32–44, Oct. 2019.
[42] M. A. Javed, N. S. Nafi, S. Basheer, M. Aysha Bivi, and A. K. Bashir,
“Fog-assisted cooperative protocol for traffic message transmission in
vehicular networks,” IEEE Access, vol. 7, pp. 166 148–166 156, Nov.
2019.
