In this section, a SDN-based routing scheme using ant colony optimization is presented, which can effectively improve the packet delivery rate. Additionally, a new neighbor RSU discovery protocol is proposed, which can find the neighbor RSUs for each RSU, and facilitates the transmission of ant packets between adjacent RSUs.
2.2. Neighbor RSU Discovery
We take the communication delay between the adjacent RSUs at both ends of the street segment as the external characteristic to evaluate the connectivity quality of the street segment, and calculate the evaluation value of the connectivity quality through the ant colony algorithm. Based on the connectivity quality of each street segment, the Dijkstra shortest path algorithm is used to calculate the optimal path.
A neighbor RSU of one RSU is the RSU in the same street segment and it does not exist with any additional RSU in the middle. For example, in
Figure 4, the neighbor RSUs of
are
and
, which are pointed out by the dotted arrow; the neighbor RSUs of
include
,
,
and
, which are indicated by the blue dashed arrows; and
,
, and
, which are identified by red solid line arrows, are neighbor RSUs of
.
To assess the packet-relaying quality of each street segment between two adjacent RSUs, each RSU at a street intersection needs to periodically send ant packets to its neighbor RSUs, so it is necessary for each RSU to know all its neighboring RSUs. For this purpose, a neighbor RSU discovery protocol is proposed in this paper.
Each RSU periodically broadcasts a neighbor discovery packet NDP, the format of which is shown in the following
Figure 5.
An NDP packet contains the following fields.
- (1)
SRC_RSU_ID: ID of the source RSU that issued the NDP packet.
- (2)
DST_RSU_ID: ID of the destination RSU that received the NDP packet.
- (3)
serial_Number: Every RSU assigns numbers sequentially to the NDP packet it creates.
- (4)
set_of_Street_ID: The set of ID of the street on which the neighbor RSUs have been found.
- (5)
SRC_CAR_ID: ID of the source vehicle that forwarded the NDP packet in each relay transmission.
- (6)
DST_CAR_ID: ID of the destination vehicle that received the NDP packet in each relay transmission.
- (7)
mode: The value of mode can be one of the three values of 0, 1 and 2, which, respectively, represent the three transmission modes of NDP data packets in this protocol, as shown in
Figure 6: from RSU to vehicle, from vehicle to vehicle, and from vehicle to RSU.
- (8)
new_Street_ID: ID of street associated with the newly discovered neighbor RSU.
The tuple values of and fields are used to uniquely identify an NDP broadcast packet, so that the vehicle node can ignore duplicate broadcast packets.
The global configuration parameters of each RSU include
and
, which are the time between launching successive NDP and the set of neighbor RSUs, respectively. In the initial configuration phase of the RSU, when the quality of the street segment connectivity is good, a timer may be set to run the neighbor RSU discovery protocol for a period of time to fully discover the neighbor RSUs, and store them in the configuration parameter
. RSU NDP broadcasting and receiving procedures are shown in Algorithms 1 and Algorithm 2, respectively.
Algorithm 1 RSU NDP broadcasting. |
- 1:
Set timer ←; - 2:
repeat - 3:
Generate a NDP broadcast packet ; - 4:
source RSU ID; - 5:
empty; - 6:
incrementing integer; - 7:
; - 8:
empty; - 9:
empty; - 10:
0; - 11:
empty; - 12:
if the timer reaches a beacon interval then - 13:
broadcast the packet ; - 14:
end if - 15:
until
|
Algorithm 2 RSU NDP receiving. |
- 1:
← NDP packet received - 2:
if this RSU ID then - 3:
if == 2 then - 4:
store the to the set ; - 5:
end if - 6:
end if
|
In order to avoid repeating the same NDP packet on the same street, after a certain RSU sends out a broadcast packet for discovering its RSU neighbors, vehicle nodes that receive this broadcast packet on newly detected streets do not immediately forward the packet, but keep silent for a period of random time before relaying the packet. If an NDP with the same and value as is received again during the silent period, it indicates that the some vehicle node on the same street has forwarded the packet , so the vehicle node cancels forwarding each of them, otherwise it forwards immediately after the silent period.
For example, as shown in
Figure 7, the dotted circle, the dashed circle, and the half-dashed circle are the signal coverage of
, vehicle node
A, and vehicle node
B, respectively.
A and
B on the street segment between
and
are within the signal coverage of
, so they can receive the broadcast packet sent by
. Suppose that
A and
B receive the packet
sent by
, they do not immediately forward it, but each keep silent for a random period of time. Suppose
A first ends the silent period and forwards
, and
B receives the
sent by
A during the silent period and cancels the forwarding of each of them.
The vehicle node forwarding packet will search the vehicle node on the same street, which is the farthest neighbor from the source RSU as the next hop. The operation continues until the packet is transmitted to the neighbor RSU. This procedure is shown in Algorithm 3, where the mode field of the NDP packet plays an important role, as explained from the following two aspects.
Algorithm 3 Vehicle forwarding the received NDP messages. |
- 1:
← NDP packet received - 2:
←this car’s street ID; - 3:
←this car’s ID; - 4:
if is not in the set then - 5:
if ==0 then - 6:
wait a random time; - 7:
if this car receives another NDP packet with the same value for and then - 8:
return; - 9:
end if - 10:
end if - 11:
end if - 12:
if ==1 and == or ==0 then - 13:
if a non-source RSU in the neighbor table then - 14:
←the ID of the non-source RSU; - 15:
←; - 16:
←; - 17:
← empty; - 18:
←; - 19:
← 2 - 20:
else - 21:
if a car that is in the neighbor table of this car, on the same street as this car, further away from the source RSU than this car, and farthest from the source RSU then - 22:
← empty; - 23:
the ID of ; - 24:
; - 25:
←; - 26:
← 1 - 27:
else - 28:
store to message buffer queue of this car, and check the buffer queue and resend periodically - 29:
end if - 30:
end if - 31:
end if
|
Firstly, when the source RSU starts to broadcast the NDP packet, the value of the mode field is set to 0. In this mode, the NDP packet will be broadcast from the RSU node to the nearby vehicle nodes, and the NDP packet has no determined forwarding target vehicle. There may be several vehicles receiving the NDP packets on the same street segment, and only one of them needs to forward it on the same street segment. Therefore, vehicle nodes will use a backoff algorithm to avoid repeating the forwarding of NDP packets on the same street segment. Assuming that the first vehicle selected for forwarding the NDP packet on a certain street segment is called , if there is a non-source RSU in the neighbor table of , it means that the distance between the two RSUs is very close, and the neighbor RSU can be reached by forwarding packets through only one vehicle (of course, it is very rare for these RSUs to be so close in actual deployment). If there is a non-source RSU in the neighbor table of the vehicle, it means that the neighbor RSU is found, the value of mode needs to be modified to 2, and then the NDP packet is sent from the vehicle to the destination RSU, and other vehicles will ignore the NDP packet with the value of mode of 2.
Second, when the value of mode is 1, it means that the NDP packet will be forwarded from vehicle to vehicle. The NDP packet will contain the ID of the next hop vehicle, so the backoff algorithm is no longer needed. In this mode, if the ID of the vehicle receiving the NDP packet is the same as in the NDP packet, the vehicle will accept the NDP and then try to forward it, otherwise it will ignore the packet. If the vehicle node receiving the NDP packet finds a non-source RSU in its neighbor table, it means that a neighbor RSU is found, so the mode in the NDP packet is set to 2, indicating that the NDP packet will be forwarded from the vehicle to the RSU node. If the vehicle node does not find the non-source RSU in its neighbor table, the vehicle node farthest from the source RSU on the same street segment needs to be searched in its neighbor table as the next hop vehicle node, and the mode value of this vehicle node is still 1. Through this NDP forwarding method, when approaching the destination RSU, the sender vehicle of the last hop to the destination RSU is not necessarily the closest to the destination RSU, but the destination RSU must be within the signal coverage of the sender vehicle, and the NDP packet successfully reaches the destination RSU.
In a word, according to the mode field in the NDP packet, Algorithm 3 can perform fine-grained control on NDP packet forwarding to ensure that the packet can be forwarded to the neighboring RSU node in the presence of an appropriate traffic flow.
2.3. Calculation of Ant Pheromone
The adjacent RSUs at both ends of a street segment send ant packets to each other periodically. The ant packets can reach the RSU at the other end through the greedy forwarding between vehicle nodes, and the pheromone value is calculated according to the delay of the ant packet. We optimize the update of the ant pheromone [
6] by adding a decay function over time and arithmetic mean. The pheromone value of the street segment from intersection
i to intersection
j will be updated using the following formula:
where
is
where
C is a constant less than 0.5.
and
are the time and minimum time it takes the ant packet to traverse the street segment from intersection
i to intersection
j, respectively.
To describe the reduction of the ant pheromone over time, i.e., pheromone evaporation, a decay function over time is defined as follows:
where
is the time decay constant ant
t is the delay between RSU receiving two ant packets. Each RSU decreases the ant pheromone of related street segments using the following formula:
The RSU is located near each road intersection, so it receives ant packets from different street segments, and calculates the pheromone values for different street segments. Then, the RSU needs to send the pheromone value of each street segment to the SDN server, and for this purpose, the RSU constructs a corresponding message for each street segment, which encapsulates the value of the pheromone, the generation time, and the two-tuple consisting of the sender RSU and receiver RSU. After that, the RSU sends to the SDN server.
The SDN server sets a
message buffer for each street segment, which can buffer at most
M messages closest to the current time. If the message is not eliminated in the message buffer for a time interval much larger than the transmission period of the ant packet, it indicates that the connectivity quality of the street segment is poor. The poor case can also cause the number of messages in the message buffer to be less than
M. The connectivity quality of the street segment from
to
is estimated as follows:
where
and
are the arithmetic average of the ant pheromone values and arithmetic average of the residence time of all messages in the message buffer corresponding to the street segment from intersection
i to intersection
j, respectively.
Assuming that the number of RSUs in the simulation area is
N, the evaluation values of the connectivity quality of all street segments can be stored in a
matrix
A as follows:
The initial value of each element in A is infinite, denoted as ∞. Since the adjacent RSUs send ant packets to each other, the two adjacent RSUs independently evaluate the connectivity quality of the same street segment according to the received ant packets from opposite directions, which may lead to inconsistent evaluation values, i.e., .
In the routing scheme proposed in this paper, the evaluation value of each street segment is unique. Therefore, to be conservative, the minimum value of the evaluation values in different directions of each street segment are taken as the evaluation value of this street segment. In (
6), assuming that the bolded matrix element value
is smaller than
, the matrix A is converted into
as shown below:
2.4. SDN-Based Routing
When the source vehicle needs to send a data packet to the target vehicle , the next hop of the packet must be found. For this purpose, it is necessary to determine whether the and the are on the same street segment. In the case of the same street segment, if the is just in the neighbor table of the , the next hop is the , otherwise, the next hop is calculated by the greedy forwarding algorithm, i.e., the next hop is the node that is closest to the on the same street segment in the neighbor table of the . Additionally, in the case where the and the are not on the same street segment, the next hop of the packet is calculated according to the shortest anchor path.
The shortest anchor path is an RSU sequence calculated by the SDN server according to the starting RSU and the ending RSU. The first RSU through which the forwards the packet is called the starting RSU, and the last RSU through which the packet arrives at the is named the ending RSU. The starting RSU and the ending RSU are the first and last elements of the shortest anchor path, respectively.
The starting RSU and ending RSU are elected based on their distance to the source vehicle and the target vehicle . First, the RSUs at both ends of the street segment where the is located are selected as candidate starting RSUs, of which the RSU closer to the is elected as the starting RSU. Similarly, the RSUs at both ends of the street where the is located are determined as the candidate ending RSUs, of which the RSU closer to the starting RSU is selected as the ending RSU.
After the starting RSU
and ending RSU
are determined, the source vehicle node
constructs a routing request (RREQ) packet with the control fields
and
, then sends the RREQ to the SDN server, which has global information of the streets’ connectivity. Then, SDN server calculates the shortest anchor path
from
to
by Dijkstra’s algorithm based on (
7). The
consists of a sequence of RSU from the starting RSU to the ending RSU. The SDN encapsulates the
in the routing reply (RREP) packet and returns it to the source vehicle
. After receiving the RREP, the source vehicle
reads the
in the RREP, encapsulates it in the header of the packet, and sent it to target vehicle
. The packet will be forwarded along the
until the target vehicle
. When transmitting data packets between two adjacent RSUs, the greedy forwarding algorithm between vehicles is used. The vehicle to vehicle/RSU packet forwarding strategy is shown in Algorithm 4, and the RSU to vehicle packet forwarding strategy is shown in Algorithm 5.
Algorithm 4 Vehicle to vehicle/RSU packet forwarding. |
- 1:
← empty; - 2:
if and are on the same street then - 3:
if is in the neighbor table of then - 4:
←; - 5:
else - 6:
choose with the greedy forwarding to ; - 7:
end if - 8:
else - 9:
← get next RSU from the ; - 10:
if is in the neighbor table of then - 11:
←; - 12:
else - 13:
choose with the greedy forwarding to ; - 14:
end if - 15:
end if - 16:
if ==empty then - 17:
store the packet to buffer queue of this node; - 18:
end if
|
Algorithm 5 RSU to vehicle packet forwarding. |
- 1:
← empty; - 2:
if this RSU is the ending RSU then - 3:
if is in the neighbor table of this RSU then - 4:
←; - 5:
else - 6:
choose with the greedy forwarding to ; - 7:
end if - 8:
else - 9:
← get next RSU from this RSU; - 10:
← ID of street between this RSU and ; - 11:
← the node closest to the on the street ; - 12:
end if - 13:
if ==empty then - 14:
store the packet to buffer queue of this RSU; - 15:
end if
|