The proposed work is divided into five subsections first section explains the congestion and its detection process, second subsection explains congestion control process, the third subsection explain the algorithm followed by an example which shows the comparison between propose work and the existing approaches, the forth sub section describes the experimental setup and the fifth subsection describes the mathematical proof of the proposed approach.
3.1. Congestion Detection: -
If node’s receiving rate is higher than the forwarding or consumption rate, then the node get congested. Congestion avoidance is one of the biggest challenge for the VANET environment. In general, the approach used for congestion detection is acknowledgement-based congestion detection. In this approach a node send a packet to next node and if the next node send acknowledgement of the receipt of packet then there is no congestion and if it doesn’t send acknowledgement then the node is said congested.
Figure 1 shows that how a node process the data, when all the neighbouring nodes send data in the IN_Q of a node.If IN_Q does not discard the data due to congestion it will be treated as pass. Data is then processed in a multilevel queue than placed into OUT_Q. Priority based data will be directly putted into the output queue. If IN_Q is full, data will be discarded. Following Table 1 shows the notations used in proposed approach. All the packets that are discarded due to insufficient IN_Q will be treated as a fail and pushed into bucket. The priority based packet will be directly forwarded to the OUT_Q. Different priority levels are assigned to the packets according to the adaptive differential service of IP packet for providing QoS.
Table 1
Notations Used in Proposed Approach
Symbol
|
Description
|
Psiz
|
Packet size
|
Drec
|
Data received
|
Dsen
|
Data send
|
Pavg
|
average packet size
|
Ploss
|
Packet loss
|
IN_Q
|
In queue
|
OUT_Q
|
Out queue
|
Eth
|
Expected throughput
|
Ath
|
Actual throughput
|
Pproc
|
Processed packet.
|
3.2. Node-based Congestion control:
Our approach named node-based throughput computing (NBTH) approach is based on QoS policy named weighed random early delivery (WRED) Each node in VANET computes its throughput. As known to all, each node in VANET has its own input and output queues (named in our approach IN_Q and OUT_Q), see figure 2(a). The length of these two queues is fixed. For each node, we have fixed expected throughput (Etp) which is based on its priority. Nodes in the network compute their throughputs that is called actual throughput (Atp) of the node. Calculate the difference (diff) between Etp and Atp. This difference may be positive, negative or zero. If it is zero then no issue, the node is utilizing its full its capacity. If the diff is negative it means node is underutilize increase the priority of node so that it can receive more data from other nodes.And if the diff is positive it means the node is congested. This is the approach for congestion detection.
Now, next issue is how to handle network congestion. Cutting the traffic rate or packet rate is the only solution to deal with congestion. In proposed approach, whenever a node detects congestion it will broadcast a message (chock packet with highest priority) shown in Fig. 2(b), to its neighbouring nodes and neighbouring nodes will cut their packet sending rate by ¼ (see Fig. 4).
We have given highest priority to these messages because if the priority is not high there may be situation that the neighbouring node may also be congested and it will not listen to that message and keep forwarding packets to the congested node. Hence these messages are handled on priority bases. We have also assigned priorities to nodes in the network. Whenever a node want to transmit packet it will choose the highest priority node and if this node is congested then the sending node choose the next highest priority node to transmit the packet.
3.3. Congestion detection and control algorithm: -
Algorithmic description of the proposed approach is depicted in the following Figs. 3 and 4. Figure 3 shows congestion detection algorithm and Fig. 4 shows congestion control algorithm.
The proposed algorithm is compared with the Machine Learning – Congestion Control (ML-CC) algorithm proposed in [21], which is a cluster based approach to handle the congestion. For example, if we will compare proposed approach with the approach given in [21], which dynamically adjust the transmission range and transmission rate for the sender in a cluster using machine learning. In ML-CC the optimum results for throughput and average delay have been found when there are 4 clusters. For more than or less than 4 clusters the performance are being degraded. The proposed algorithm is based on the throughput of a node without any cluster so entire data will be considered and part of the network traffic. Thus there will be no rider like cluster or transmission range.
3.4. Experimental Setup: -
We have used NS-2.35, SUMO and MOVE to evaluate the purposed approach. In which MOVE, has been used to represent the road and vehicles in the network, SUMO is used to show the mobility pattern of the vehicles and NS-2.35 is used to simulate and analyze results through trace. For experimental setup, the different parameters used in the simulation and their brief description is shown in Table 2.
Table 2
Simulation parameters and their brief description.
Simulation Parameter
|
Value/ Range /Unit
|
Brief description
|
Number of vehicles
|
50, 100, 200, 300, 400
|
Density of the vehicles on the roads
|
Road Length
|
800m x 700m
|
Area for the vehicles to move in the road.
|
Number of lanes
|
4
|
2 lanes in each direction.
|
Maximum speed of a vehicle
|
20 m/s
|
Maximum speed of a vehicle could be 72 Kmph on an average
|
Simulation Time
|
500 Sec
|
Duration of a vehicle to move in the given setup.
|
Packet size
|
1024 bytes
|
Maximum payload of a data packet.
|
Sender data pattern
|
5 packets per sec
|
Packet rate for a vehicle to transmit.
|
Window Size
|
2048 bytes
|
Buffer available with a node.
|
Node placement type
|
Source of a Road
|
All vehicle start from the certain fixed point.
|
Traffic Light Time
|
60s
|
Traffic light duration at a junction.
|
MAC type
|
IEEE 802.11p
|
Wireless access in vehicular environment
|
Number of simulation
|
10
|
Number of experiment carried out per setup.
|
In a rage of 800 x 700 m2as shown in Fig. 5, the area in which vehicle can move is near about 15% to 30 % which is basically the road area. The approximate length of road is 4 Km in which vehicles can move. Simulation parameters are compared with the parameters given in [21, 24]. The propagation method used for the scenario is also Nakagami propagation model, which is one of the well-suited model for urban scenarios [21, 24]. The number of vehicle which we have simulated are in a range of 50 to 400 vehicles in a cross section scenario. The cross-section scenario is being chosen because at the diagonal points the density of vehicles would be high due to which any node can face a congestion as shown in Fig. 5 and Fig. 6.
The cross-section points in the scenario shown by Fig. 5 and Fig. 6 clearly shows that the maximum number of vehicles are placed at a time. The maximum amount of data traffic faced by the priority node or vehicle at the cross-section point due to traffic light [21] or other vehicle weighting reasons. Figure 7 clearly mention that the maximum amount of communication is going on at cross-section points.
3.5. Discussion:
In node-based throughput approach if a vehicle or a node Ni receives npi packets from its n neighbours than the total data received by the node per unit of time in its IN_Q and the total data send by the node per unit of time in the OUT_Q is given by the Eqs. (1) and (2) respectively. Where n1are the number of nodes from where Ni is receiving the data and n2 be the number of nodes to whom Ni is sending the data, where 0 < n1 ≤ n and 0 < n2 ≤ n.
Each node compute its actual throughput by computing the amount of data processed by the node per unit of time is given in Eq. (3). Ath is the amount of data processed by a node form IN_Q to OUT_Q. Where µ is average processing capacity of a node.
Each node will be assigned an expected throughput (Eth). The Eth is computed using the amount of buffer associated with each node and its processing capacity. The input and output buffer size is divided into the number of average packet length and the processing capacity of the node per unit time. Let µ is the processing capacity of a node per unit time thus the expected throughput for a ith node is given in Eq. 4.
A node will face a congestion if Ath > Eth or in other words if a difference of expected throughput and actual throughput is positive than the node will be treated as a congested node and congestion control algorithm will be invoked.