Joint Congestion Control Strategy During V2V Communication Among Authentic Vehicles in VANET

Wireless Pers CommunDOI 10.1007/s11277-014-1840-x

Joint Congestion Control Strategy During V2VCommunication Among Authentic Vehicles in VANET

Sulata Mitra · Atanu Mondal

© Springer Science+Business Media New York 2014

Abstract The wireless access in vehicular environment system is developed for enhancingthe driving safety and comfort of automotive users. However, such system suffers fromquality of service degradation for safety applications caused by the channel congestion inscenarios with high vehicle density. In the present work channel congestion is controlledjointly by road side unit, and vehicle. The present work supports vehicle to vehicle commu-nication of authentic safe messages among authentic vehicles only. The road side unit reduceschannel congestion by allowing only the authentic vehicles to participate in vehicle to vehiclecommunication, and by discarding unauthentic messages from the network. It revokes vehi-cles which are not authentic, and vehicles which are communicating unauthentic messages.Each vehicle also participates in the reduction of channel congestion by varying the sizeof beacon message dynamically, by removing the duplicate messages from message queue,and also by controlling the transmission power, and transmission range of a message duringtransmission. It further reduces the channel congestion by controlling the message generationrate using message generation rate control algorithm. Two different message generation ratecontrol algorithm are proposed in the present work. In the first approach it maintains thechannel load to an estimated initial value whereas the second approach increases the channelload till the percentage of message loss lies below a predefined threshold. The performanceof the proposed scheme is studied on the basis of percentage of successful message reception,and percentage of message loss. The performance of the two message generation rate controlalgorithms are also compared in the present work.

Keywords Authentication · V2V communication · Congestion control

S. Mitra (B)Department of Computer Science and Technology, Indian Institute of Engineering Scienceand Technology, Shibpur, Indiae-mail: [email protected]

A. MondalDepartment of Computer Science and Engineering, Camellia Institute of Technology, Kolkata, Indiae-mail: [email protected]

123

S. Mitra, A. Mondal

1 Introduction

Congestion control is an important research issue to ensure safe and reliable vehicle to vehicle(V2V) communication by using the limited resource available in vehicular ad hoc network(VANET). Each vehicle in VANET is able to transmit its own message and can receivemessages from other vehicles.

The proposed scheme supports V2V communication of safe messages such as emergencymessage, warning message and beacon message among vehicles using control channel inVANET. The VANET in the proposed scheme is a hierarchy having certifying authority(CA) at the root level, road side units (RSUs) at the intermediate level and vehicles at the leaflevel. Each vehicle is equipped with global positioning system to know its current locationand has an electronic license plate (ELP) in which its encrypted vehicle identification number(VIN) is embedded by the vehicle manufacturer.

The objective of the proposed scheme is to reduce channel congestion. Both RSU andvehicle participate in the reduction of channel congestion. The ELP of a vehicle broadcasts(as per IEEE P1609 and IEEE 802.11p) the encrypted VIN after entering into the coveragearea of a new RSU. The new RSU verifies the authentication of the vehicle and assigns adigital signature to the vehicle as a valid key if it is authentic. Each authentic vehicle includesits digital signature in the message format as its identity. Hence the proposed scheme supportsV2V communication among authentic vehicles only. It helps to reduce the number of vehiclesin VANET as well as channel congestion. Each RSU further reduces channel congestion byverifying the message integrity during V2V communication, by detecting and revoking themisbehaving vehicles from VANET in a timely fashion to prevent them from causing moredamage to the network.

Each vehicle participates in the reduction of channel congestion by varying the length ofbeacon message and by removing the duplicate messages from the message queue. The trans-mission power and transmission range of message during V2V communication dependingupon the local density of vehicles and network conditions are also controlled dynamicallyby the vehicle. It helps to reduce the channel congestion mainly in dense traffic conditionwhich in turn reduces collision and increases communication reliability. Moreover a vehicleaccepts an emergency message and a warning message if it is behind the sender in the samelane which helps to reduce the total number of messages at a vehicle. The channel congestionis reduced further by controlling the message generation rate at each vehicle dynamically.Two approaches are proposed in the present work for dynamic control of message generationrate. In the first approach (APPR_I) initially a channel load is calculated depending upon themessage generation rate of different vehicles and finally it tries to maintain the channel load toits initial value by varying the message generation rate from different vehicles dynamically.So in APPR_I the maximum possible channel load remains fixed to its initial value. TheAPPR_I is made more realistic in the second approach (APPR_II) by considering the factthat the actual channel load is required to decide dynamically for utilizing the channel in amore efficient way. APPR_II increases the initial value of the channel load till the percentageof message loss lies below a predefined threshold.

2 Previous Work

Several congestion control schemes have been proposed so far. A novel concept for utilitybased congestion control and packet forwarding in VANET is proposed in [1]. The congestioncontrol algorithm uses an application specific utility function and encodes the quantitative

123

Joint Congestion Control Strategy During V2V Communication

utility information of each transmitted data packet in a transparent way for all users withina local environment. A decentralized algorithm then calculates the average utility value ofeach individual vehicle based on the utility of its data packets and assigns a share of theavailable data rate proportional to the relative priority. The evaluation of message prioritybased on utility and packet size reduces the performance of disseminating event driven safetymessages.

Zhang et al. propose congestion control in wireless networks for vehicular safety applica-tions [2]. The event driven congestion control is triggered reactively whenever a high prioritysafety message arrives to the system. It helps to guarantee quality of service for safetyapplications. The measurement based congestion detection measures the channel usage andcompares it with a defined threshold. But the effective transmission of the safety messagesis not guaranteed as the authors did not consider the neighborhood context and the effectivebandwidth sharing. Moreover the delay in event driven safety message is found experimen-tally as 50 ms. But for safety application such message need to disseminate among adjacentvehicles within 20 ms.

A congestion control approach is proposed in [3]. It considers dynamic priority basedscheduling. The service messages are scheduled in control channel if it is free. But theauthors have not suggested the message format. Moreover the performance analysis is notpresented graphically in [3].

A congestion control for safety messages in VANET is proposed in [4]. The algorithmoperates only vehicles on the same lane. The vehicles forward the event driven safety messagesafter receiving it successfully from front vehicles. But in real scenarios an accident in a lanealso affects other lanes.

A cooperative scheme for service channel (SCH) reservation is proposed in [5]. Accordingto Wireless Access Vehicular Environment standard, the safety messages are carried over adedicated control channel (CCH) while non-safety messages are delivered over one of a setof available SCH [5]. But in [5] there is a possibility of bandwidth wastage when the SCH isoverloaded and CCH is idle.

A cooperative congestion control approach is proposed in [6]. The priority of the messagesis determined dynamically depending upon their types, network context and the neighbor-ing vehicles configuration. In [6] the cooperation in message transmission is achieved bydynamically distributing the available bandwidth among vehicles. A vehicle having the highpriority message can use the available bandwidth only. If the two vehicles have to send twomessages with the same priority, the available bandwidth is given to the first vehicle whonotifies the priority of its message. Each vehicle specifies the time of first notification in itsbeacon message. But in [6] the available bandwidth at each vehicle is independent on thecongestion level of vehicles.

An adaptive congestion control for dedicated short range communication vehicle networksis proposed in [7]. In this scheme each device periodically senses the channel based on thechannel occupancy time. If the channel occupancy time measured at a vehicle in CCH exceedsthe predefined threshold, all beacon messages will be blocked immediately.

A scalable congestion control for event driven safety messages in VANET is proposedin [8]. The congestion is detected by scanning the message in the queue and by monitoringthe channel communication based on predefined threshold. A priority based earliest deadlinefirst algorithm is used to schedule the packets having the same high priority for communica-tion using control channel. But they consider only the event driven safety messages havingidentical priorities.

The authors in [9] propose a new congestion control approach for beacon transmission. Adistributed beacon frequency control for VANETs is proposed for the beacon safety message

123

S. Mitra, A. Mondal

transmission. It mitigates the terrible channel condition in dense network by adaptivelyadjusting the transmission frequency for beacons according to the network context, whileconsidering the accuracy of updating status information.

A congestion control algorithm is proposed in [10,11] to ensure high reliability and timelydelivery of disseminating event-driven safety messages. It is the combination of event-drivendetection and measurement-based detection. The measurement-based congestion detectionmonitors CCH. The CCH is congested if the number of packets in the control queue exceedsa defined threshold and the algorithm starts to discard the incoming beacon messages. Theevent-driven detection method monitors the event-driven safety message and decides to startthe congestion control algorithm whenever event-driven safety message is detected or gener-ated. But it considers only the event driven safety messages. Moreover a node may not havethe up to date information about its neighbors due to the loss of beacon messages in case ofCCH congestion.

3 Present Work

In this section the type of messages that are supported by the proposed scheme and theirformats are considered for discussion. The vehicle authentication and revocation mechanismof RSU are elaborated. The congestion control mechanism of ith vehicle (Ni, 1 ≤ i ≤ N,N − 1 is the number of neighboring vehicles of Ni) in the coverage area of Bth RSU (RSUB)

is discussed.

3.1 Message Format

The proposed scheme supports V2V communication of emergency message (Type_I mes-sage), warning message (Type_II message) and beacon message (Type_III message). TheType_III message is broadcast type while the Type_I and Type_II messages are multicasttype.

The format of Type_I message is shown below. Such message is generated by an abnormalvehicle (AV). AV is a vehicle which behaves abnormally like declaration exceeds a certainthreshold, dramatic change of moving direction, major mechanical failure etc. Here it isassumed that the computation power of AV is not affected and its speed is almost zero. Itsends emergency message to all its neighboring vehicles. Such message needs at least twohop communications for informing the surrounding vehicles about the location of AV.

Type D_Sig X_Coor Y_Coor Direction Lane_id Data_EM

The format of Type_II message is shown below. Such message is generated by a vehi-cle (Source_node) which detects traffic signal breakdown, jamming information etc. TheSource_node sends this message to the vehicles behind it i.e. to the vehicles which are mov-ing towards the jam location. In such a case it is required to prevent the other vehicles fromentering into this lane to improve its traffic condition. So such message needs the commu-nication up to the end of the lane whose identification (Lane_id) is specified in the messageformat.

Type D_Sig X_Coor Y_Coor Direction Lane_id Data_WM

The format of Type_III message is shown below. Such message is generated by all thevehicles periodically.

Type D_Sig X_Coor Y_Coor Direction Lane_id BM_GR WM_GR EM_GR

123


Table 1 Example of phrase

Situation/purpose Phrase used in WM_EVENT/EM_EVENT

Dangerous road features “Curve speed warning”, “Low bridge warning”,“Warning about violated traffic lights or stop signals”

Danger of collision “Lane change warning”, “Intersection collisionwarning”, “Forward/rear collision warning”,“Emergency electronic brake lights”, “Rail collisionwarning”, “Warning about pedestrian crossing”

Crash imminent “Pre-crash sensing”

Incident occurred “Post-crash sensing”, “Traffic signal breakdown”, “Traffic jam”

The header of each message includes priority and hops fields as shown below.

Priority Hops

The Type field in the message format includes the type of the message. The proposedscheme supports three types of messages. So the size of this field is 2 bits. The D_Sigfield in the message format indicates the identity of the vehicle who is the owner of themessage and the size of this field (Size_D_Sig) is 160 bits [12]. X_Coor and Y_Coorfields in message format represent the current location of the vehicle. The size of X_Coorand Y_Coor field is assumed as 16 bits. The Direction field in message format specifiesthe direction of movement of a vehicle. As a vehicle can move in one of two directions(up and down) the size of this field is assumed as 1 bit. The simulation experiment iscarried out in a highway having three lanes. So the size of Lane_id field is assumed as2 bits.

Data_EM field in Type_I message format and Data_WM field in Type_II messageformat contain the data of emergency message and warning message respectively. Theformat of Data_EM field in Type_I and Data_WM field in Type_II message is shownbelow.

EM_EVENT D_Sig Region

WM_EVENT D_Sig Region

EM_EVENT field contains the event for which the emergency message is created. Forexample, in case of crash the EM_EVENT is “Pre-crash sensing”, in case of major mechanicalfailure the EM_EVENT is “Major mechanical failure” etc.

WM_EVENT field contains the event for which the warning message is created. Forexample, in case of traffic jam the WM_EVENT is “Traffic jam”, in case of traffic signalbreakdown WM_EVENT is “Traffic signal breakdown” etc.

The EM_EVENT and WM_EVENT field will be same for every vehicle facing sameemergency and warning event respectively. A few example of such phrase is shown in Table 1.

The size of EM_EVENT and WM_EVENT is assumed as 32 bits. The D_Sig fieldin Data_EM and Data_WM indicates the identification of the vehicle that is first fac-ing the event and creating the message. During simulation each lane is divided into fewregions so that each vehicle can determine the location of occurrence of an event in alane more accurately. The Region field in Data_EM and Data_WM field contains thenumber of the region where the event has taken place. The number of region in a lanedepends upon its length. The size of Data_EM (Size_Data_EM) field and Data_WM

123

S. Mitra, A. Mondal

(Size_Data_WM) field is assumed as Size_D_Sig+log2R+32 bits where R is the numberof regions in a lane. The BM_GR, WM_GR and EM_GR fields in Type_III message arethe beacon message, warning message and emergency message generation rate in num-ber of messages per second respectively. The size of these three fields is assumed as 8bits.

A priority is assigned to each message depending upon its type. The priority of Type_I,Type_II and Type_III messages are assumed as Prio_I, Prio_II and Prio_III respectivelywhere Prio_I > Prio_III > Prio_II. The priority value of a message is specified in its header.As the proposed scheme considers three types of messages, the size of this field is assumedas 2 bits.

The hop field in the message header indicates the life time of a message in the networkin terms of number of hops. So it is 2 for Type_I message, K for Type_II message and 1 forType_III message. The value of K is computed by the Source_node as the ratio of its distancefrom the end point of the lane behind it to the inter vehicle space. So the size of hop fieldin Type_I message is 2 bits, in Type_II message is log2K bits and in Type_III message is 1bit.

Hence the size of Type_I message (SizeE), Type_II message (SizeW) and Type_III message(SizeB) is Size_D_Sig+41+Size_Data_EM bits, Size_D_Sig+39+log2K+Size_Data_WMbits and Size_D_Sig+64 bits respectively.

3.2 Authentication and Revocation Mechanism of RSU

The CA maintains a VIN database (VIN_CA) to store the VINs of the vehicles that arealready manufactured. The VIN_CA is updated when a new vehicle is manufactured. TheCA gathers knowledge about the available pattern of each character in VIN of the vehicleswhich are already manufactured by consulting with VIN_CA after updating it. Each RSUmaintains a VIN database (VIN_RSU) to store the encrypted VIN and digital signature pairof all the authentic vehicles in VANET. A revocation list is maintained by each RSU to storethe digital signature of the misbehaving vehicles.

Each RSU has an authentication module to verify the authentication of a vehicle withinits coverage area and to assign a digital signature to each authentic vehicle. The function ofthe authentication module is the combination of authentication function [12] at RSU, verifi-cation function [12] at CA, insertion function at RSU [12] and signature assignment functionat RSU. The signature assignment function assigns the digital signature to an authenticvehicle.

The message processing module (MP_M) at RSU maintains the traffic condition of thelanes which are within its coverage area. It receives messages from the vehicles whichare within its coverage area, verifies them for validity and allows them to process if valid.The function of this module for jth message (Mj) is elaborated in this section. It veri-fies the validity of the digital signature in the D_Sig field of Mj (DS1j) for all the threetypes of messages. It also verifies the validity of the digital signature in the Data_EMfield of Mj (DS2j) if Mj is Type_I type and in the Data_WM field of Mj (DS2j) if Mj isType_II type. Moreover it consults with the traffic condition information available with itfor verifying the validity of (EM_EVENT, Region) information in Data_EM field if Mj isType_I type and (WM_EVENT, Region) information in Data_WM field if Mj is Type_IItype.

123


Table 2 Neighbor table

D_Sig X_Coor Y_Coor Direction Lane_id BM_GR WM_GR EM_GR

D_Sig1 X1 Y1 D1 L1 BM_GR1 WM_GR1 EM_GR1

D_Sig2 X2 Y2 D2 L2 BM_GR2 WM_GR2 EM_GR2

– – – – – – – –

D_Sigi Xi Yi Di Li BM_GRi WM_GRi EM_GRi

– – – – – – – –

D_SigN XN YN DN LN BM_GRN WM_GRN EM_GRN

/*Function of MP_M*/ ER: (EM_EVENT, Region) in Data_EM field of Mj if Mj is Type_I type WR: (WM_EVENT, Region) in Data_WM field of Mj if Mj is Type_II type XR: ER for Type_I and WR for Type_II message {Searches VIN_RSU for DS1j and for DS2j

If (DS1j or DS2j or both are invalid) {Inserts invalid digital signature(s) in the revocation list Go to L1} Else {Verifies XR of Mj for validity If valid Allows processing of Mj

Else {Inserts DS2j of Mj in the revocation list Go to L1}}}

L1: Broadcasts the invalid digital signature(s) among vehicles within its coverage area

3.3 Congestion Control Mechanism of Ni

A beacon queue (B_Queuei), a warning queue (W_Queuei) and an emergency queue(E_Queuei ) are maintained by Ni to store the beacon messages, warning messages andemergency messages respectively. A neighbor table is also maintained by Ni to store the bea-con message of the neighboring vehicles. The function of Ni is divided into four modules.G_Modulei generates message, estimates the channel load and controls the generation rateof Type_II message dynamically due to its low priority for reducing the channel congestion.R_Modulei receives messages from the neighboring vehicles. D_Modulei discards dupli-cate messages from E_Queuei and W_Queuei, T_Modulei controls the power and range oftransmission. The function of all these modules at Ni is also elaborated in this section.

3.3.1 Maintenance of Neighbor Table

The neighbor table (Table 2) contains N number of records. G_Modulei updates this table aftersending a new beacon message and R_Modulei updates this table after receiving a new beaconmessage. The value of the D_Sig attribute, X_Coor attribute, Y_Coor attribute, Directionattribute, Lane_id attribute, BM_GR attribute, WM_GR attribute and EM_GR attribute areD_Sigi, Xi, Yi, Di, Li, BM_GRi, WM_GRi and EM_GRi in the ith record corresponding toNi in the neighbor table.

123

S. Mitra, A. Mondal

3.3.2 Function of R_Modulei

R_Modulei maintains an incoming queue (IQ) to store the received messages from neighbor-ing vehicles of Ni. It transfers the Type_I messages from IQ to E_Queuei, Type_II messagesfrom IQ to W_Queuei, Type_III messages from IQ to B_Queuei using monitor IQ function.

Monitor IQ Function for Mj

{If (Mj = Type_I message) {Call FUNC(Mj) Extracts information from Mj

If (hop count ==0) /* hop count = Hops in message header*/ Discards Mj

Else {Places Mj in E_Queuei

Triggers D_Modulei

/*To discard Mj if duplicate from E_Queuei*/}} If (Mj =Type_II message) { Call FUNC(Mj) Extracts information from Mj

If (Ni = last vehicle of lane) Discards Mj

Else {Places Mj in W_Queuei

Triggers D_Modulei}} If (Mj = Type_III message) {Updates the neighbor table Triggers G_Modulei

/*To estimate the new channel load*/ }}

FUNC(Mj) /*Verify whether Ni is behind the message sender in the same lane*/

{ Lane_ids: Lane_id of message sender Lane_idr: Lane_id of message receiver X_Coors: X-coordinate of the current location of message sender X_Coorr: X-coordinate of the current location of message receiver If ((Lane_ids≠Lane_idr) or (X_Coorr≥X_Coors)) Rejects Mj

If ((Lane_ids=Lane_idr) and (X_Coorr<X_Coors)) {Accepts Mj

Return}}

3.3.3 Function of G_Modulei

This module generates Type_I and Type_II messages, places them in E_Queuei andW_Queuei respectively. It generates Type_III message periodically, places it in B_Queuei

and updates the neighbor table. The Lane_id field and Direction field are added in Type_IIImessage only if Ni changes lane and direction during its movement. Accordingly SizeB

varies dynamically which helps to minimize the channel load at Ni. This module estimatesthe channel load in terms of the number of messages per second and controls the rate ofgeneration of Type_II type of message at Ni dynamically for reducing channel congestion.

Estimation of Channel LoadG_Modulei generates the first beacon message of Ni and inserts it in the neighbor table.R_Modulei inserts the first set of beacon messages in neighbor table after receiving themfrom all the N − 1 number of neighboring vehicles and triggers G_Modulei.

123


G_Modulei reads the value of BM_GR, WM_GR and EM_GR attribute from all theN number of records in neighbor table and estimates the initial value of the channel load(CH_LOADi_i).

The beacon message is generated by all the N number of vehicles and so the initial channelload due to the generation of beacon message (CH_LOAD_Bi_i) is

∑Ni=1 (B M_G Ri)

∗ TB

seconds.Let the P (P≤N) number of records in the neighbor table has nonzero value of the

WM_GR attribute and Q (Q≤N) number of records in the neighbor table has nonzerovalue of the EM_GR attribute. So the warning message and emergency message are gen-erated by P and Q number of vehicles in VANET respectively. G_Modulei estimates theinitial channel load due to the generation of warning messages (CH_LOAD_Wi_i) and dueto the generation of emergency messages (CH_LOAD_Ei_i) as

∑Pi=1 (W M_G Ri)

∗ TW sec-

onds and∑Q

i=1 (E M_G Ri)∗ TE seconds respectively. Here TB, TW, TE are the time required

to transmit a Type_III, Type_II and Type_I message using the channel respectively. TB isSizeB/Data_TR, TW is SizeW/Data_TR, TE is SizeE/Data_TR and Data_TR is data rate inbits/sec.

CH_LOADi_i = CH_LOAD_Bi_i +CH_LOAD_Wi_i + CH_LOAD_Ei_iseconds (1)

R_Modulei updates the neighbor table as soon as it receives the next set of beacon messagefrom neighbors and triggers G_Modulei. G_Modulei estimates the new value of the channelload (CH_LOADn_i) using the same procedure as used for the estimation of CH_LOADi_i

and triggers the message generation rate control (MGRC) algorithm at Ni.

MGRC Algorithm for APPR_I

This algorithm uses three fractions FRAC1, FRAC2 and FRAC3. The value of these three frac-tions is determined as 0.7, 0.9 and 0.3 respectively during simulation as discussed in Sect. 4.

If CH_LOADn_i > FRAC1*CH_LOADi_i

{ EX_LOADi: Extra channel load as estimated by MGRC algorithm at Ni in number of messages EX_LOADi=CH_LOADn_i – FRAC1*CH_LOADi_i

Generates Type_I and Type_III messages t1 = Call FUNC_t1(EX_LOADi) Stops the generation of Type_II messages at Ni for t1 duration of time }


{ EX_LOADi = CH_LOADn_i – FRAC2*CH_LOADi_i

t2 = Call FUNC_t2(EX_LOADi) Stops the generation of all the three types of messages at Ni for t2 duration of time }


Increases BM_GRi, WM_GRi, EM_GRi till CH_LOADn_i = CH_LOADi_i

FUNC_t1(EX_LOADi) /*Determine the value of t1*/ { M_Sizeavg: Average message size in bits M_Sizeavg = (SizeB+SizeW+SizeE)/3 EX_LOAD_Bi: Value of EX_LOADi in bits EX_LOAD_Bi = EX_LOADi * M_Sizeavg

t1 = (EX_LOAD_Bi/(P*WM_GRi*SizeW)) seconds Return t1

}

123

S. Mitra, A. Mondal

Calculation of t1

EX_LOAD_Bi bits of excess channel load are to be reduced to 0 by all the P number of vehi-cles which are generating Type_II messages. So in average (EX_LOAD_Bi/P) bits of excesschannel load is to be reduced by each vehicle. Each vehicle does this by not generating anyType_II messages for t1 duration of time where t1 is the time to generate (EX_LOAD_Bi/P)bits of Type_II messages. Again the Type_II message generation rate of Ni is WM_GRi

number of message per second. So the time required to generate (EX_LOAD_Bi/P) bits ofType_II message at a rate WM_GRi is (EX_LOAD_Bi/(P*WM_GRi*SizeW)) seconds.

t1 = (EX_LOAD_Bi/

(P∗WM_GR∗

i SizeW))

seconds (2)

FUNC_t2(EX_LOADi) /*Determine the value of t2*/{ t2 = (EX_LOAD_Bi/N*(BM_GRi*SizeB+WM_GRi*SizeW+EM_GRi*SizeE)) seconds Return t2

}

Calculation of t2

EX_LOAD_Bi is to be reduced to 0 by all the N number of vehicles. So in average(EX_LOAD_Bi/N) bits of excess channel load is to be reduced by each vehicle. Each vehicledoes this by not generating all the three types of messages for t2 duration of time.

Now G_Modulei generates BM_GRi *SizeB*t2 bits of Type_III message, WM_GRi

*SizeW*t2 bits of Type_II message and EM_GRi*SizeE*t2 bits of Type_I message int2 interval of time. So (EX_LOAD_Bi/N) bits of excess channel load is equivalent to(BM_GRi*SizeB+WM_GRi*SizeW+EM_GRi*SizeE)*t2 bits.

t2 = (EX_LOAD_Bi/N∗ (

BM_GR∗i SizeB + WM_GR∗

i SizeW + EM_GR∗i SizeE

))seconds

(3)

MGRC Algorithm for APPR_II

The MGRC algorithm controls the generation rate of Type_II type of messages at Ni dynami-cally for maintaining the percentage of safe message loss (PSML) below a predefined thresh-old. This algorithm computes PSML at Ni as the ratio of the number of loss of message tothe number of sent message for each new value of CH_LOADn_i. It stops the generationof Type_II message for t3 duration of time if PSML at Ni exceeds a predefined threshold(LOSSth/N), where LOSSth is the threshold value of PSML at the channel.

123


{/*Computation of t3*/ MLP_i: Percentage of message loss at Ni

Msent_i: Number of message sent at Ni

/*Reduces CH_LOADn_i so that MLp_i ≤LOSSth/N*/ EX_MLi: Extra message loss as estimated by MGRC algorithm at Ni in number of messages EX_MLi = (MLP_i- (LOSSth/N)) * Msent_i

Generates Type_I and Type_III messages t3 = Call FUNC_t3(EX_MLi) Stops the generation of Type_II messages at Ni for t3 duration of time}

FUNC_ t3(EX_MLi) /*Compute t3*/ { EX_ML_Bi: Value of EX_MLi in bits EX_ML_Bi= EX_MLi * M_Sizeavg

t3 = (EX_ML_Bi/(WM_GRi*SizeW)) seconds Return t3

}

Calculation of t3

EX_ML_Bi bits of message are to be dropped by not generating Type_II message. TheType_II message generation rate of Ni is WM_GRi messages per second. So the time(t3) required to generate EX_ML_Bi bits of Type_II message at a rate WM_GRi is(EX_ML_Bi/(WM_GRi*SizeW)) seconds.

t3 = (EX_ML_Bi/

(WM_GR∗

i SizeW))

seconds (4)

3.3.4 Function of D_Modulei

This module uses duplicate message truncation (DMT) algorithm to discard the duplicateType_I and Type_II messages from E_Queuei and W_Queuei respectively at Ni. The functionof this module for Mj is discussed in this section. The DMT algorithm compares the Data_EMfield of Mj with the Data_EM field of the existing messages in E_Queuei if Mj is Type_Itype and the Data_WM field of Mj with the Data_WM field of the existing messages inW_Queuei if Mj is Type_II type. The comparison of Mj with the vth (Mv) message in thequeue is discussed in this section.

DMT Algorithm

123

S. Mitra, A. Mondal

Mj: Received message If (Mj = Type_I type) { MESSj: Data_EM field of Mj

Ej: EM_EVENT field in MESSj

Dj: D_Sig field in MESSj

Rj: Region field in MESSj

v=1 /*First Type_I message in E_Queuei */ Mv: v

th Type_I message in E_Queuei

MESSv: Data_EM field of Mv

Ev: EM_EVENT field in MESSv

Dv: D_Sig field in MESSv

Rv: Region field in MESSv

Go to LOOP} Else

{ Mj =Type_II type MESSj: Data_WM field of Mj

Ej: WM_EVENT field in MESSj

Dj: D_Sig field in MESSj

Rj: Region field in MESSj

v=1 /*First Type_II message in W_Queuei*/ Mv: v

th Type_II message in W_Queuei

MESSv: Data_WM field of Mv

Ev: WM_EVENT field in MESSv

Dv: D_Sig field in MESSv

Rv: Region field in MESSv

Go to LOOP}

LOOP: { If ((Ej Ev) or ((Ej=Ev) and (Dj=Dv) and (Rj Rv)) or ((Ej=Ev) and (Dj Dv) and (Rj Rv))) {Accepts Mj

Exit} If (((Ej=Ev) and (Dj=Dv) and (Rj=Rv)) or ((Ej=Ev) and (Dj Dv) and (Rj=Rv))) {Discards Mj

Exit}}

3.3.5 Function of T_Modulei

The transmission power determines the transmission range of a node. The increase in trans-mission power causes an increase in transmission range of a node which is useful in sparsetraffic condition for increasing the duration of the communication links in VANET. On theother hand, the increase in transmission range may generate high levels of disruptive inter-ference and high channel load in dense traffic condition.

T_Modulei uses power transmission control (PTC) algorithm to determine the trans-mission power and transmission range of Ni dynamically depending upon the local den-sity of nodes and network conditions. It calculates the transmission range of Ni (TRi)as min {Length_RS (1-Local_ND),

√((Length_RS)* ln (Length_RS/Length_ND)) +

α*Length_RS} [13] where α = 0.25, Length_RS is the length of the lane segment associ-ated with Ni, Local_ND is the local node density which is calculated by T_Modulei as theratio of the actual number of nodes that are present to the total number of nodes that can bepresent within the transmission range of Ni. The PTC algorithm at T_Modulei determinesthe transmission power of Ni depending upon the estimated value of TRi and the look uptable (Table 3) [14].

123


Table 3 Lookup table fortransmission power

Transmission range (m) Transmission power (dBm)

0–9 −20

10–49 −12

50–100 −5

100–125 −3

126–149 1

150–209 4

210–299 6

300–349 10

350–379 12

380–449 14

450–549 17

550–649 20

750–849 24

850–929 27

930–970 29

971–1,000 31

>1,000 32

Table 4 Simulation parametersDistance between 2 vehicles 2m

Vehicle velocity 22 m/s

Highway length 1,000 m

Vehicle length 4 m

Vehicle width 2 m

Lane width 5 m

Simulation time 100 s

Bandwidth 10 MHz

Number of vehicles 17–150

Propagation loss model Nakagami

Data rate (Data_TR) 6 Mbps [17]

Average message generation rate 10–100 messages/s

Mobility model IDM [18]

4 Simulation

The simulation experiment is conducted in a highway having three lanes using NS3. Thesimulation parameters are shown in Table 4. The performance of the proposed scheme isevaluated on the basis of the percentage of successful message reception (PSMR) and PSML.It is compared with the existing schemes [15,16]. The performance of APPR_I and APPR_IIare also compared during simulation.

123

S. Mitra, A. Mondal

Fig. 1 PSMR versus number ofvehicles in APPR_I

Fig. 2 PSMR versus number of vehicles in APPR_II

Percentage of Successful Message Reception

The simulation experiment is conducted to observe the variation of PSMR versus the numberof vehicles in VANET. The successful message reception at each vehicle is computed as theratio of the received messages to the sum of received and dropped messages.

Figures 1 and 2 show the plot of PSMR versus the number of vehicles for APPR_I andAPPR_II respectively. It can be observed from Figs. 1 and 2 that PSMR reduces slowly than[15] both for APPR_I and APPR_II when the number of vehicles exceeds 100.

Percentage of Safety Message Loss

The simulation experiment is conducted to observe the variation of PSML versus the averagemessage generation rate for N = 50 in VANET. The safety message loss at each vehicle iscomputed as the ratio of the number of dropped messages to the number of sent messages.The number of dropped and sent messages is determined during simulation.

Figures 3 and 4 show the plot of PSML versus the message generation rate for APPR_Iand APPR_II respectively. PSML both in Figs. 3 and 4 increases slowly than [16] when the

123


Fig. 3 PSML versus message generation rate in APPR_I

Fig. 4 PSML versus message generation rate in APPR_II

message generation rate exceeds 50. Moreover in Fig. 4 PSML becomes constant to LOSSth

(2 %) when the message generation rate exceeds 85.

Comparison of APPR_I and APPR_II

The performance of APPR_I and APPR_II are compared on the basis of PSMR and PSML.Figure 5 shows the plot of PSMR versus the number of vehicles in VANET for APPR_Iand APPR_II. It can be observed from Fig. 5 that PSMR is almost identical in APPR_I andAPPR_II.

Figure 6 shows the plot of PSML versus the message generation rate for N = 50 in VANETfor APPR_I and APPR_II. It can be observed from Fig. 6 that both for APPR_I and APPR_II

123

S. Mitra, A. Mondal

Fig. 5 PSMR versus number of vehicles for APPR_I

Fig. 6 PSML versus message generation rate for APPR_II

PSML starts to increase when the message generation rate exceeds 50. Moreover PSMLbecomes constant (2 %) when the message generation rate exceeds 80 for APPR_II.

Determination of the values of FRAC1, FRAC2 and FRAC3

The MGRC algorithm in APPR_I uses three fractions FRAC1, FRAC2 and FRAC3. Theirvalues are determined for N equal to 120, 150, 180 during simulation and are shown in Tables5, 6, 7 respectively in Appendix.

As per the discussion in Sect. 3.3.3 EX_LOADi = CH_LOADn_i - FRAC1*CH_LOADi_i.So the increase of FRAC1 reduces EX_LOADi which in turn reduces the possibility of theloss of Type_II message due to the delay t1. It can be observed from Tables 5, 6 and 7 thatfor FRAC1 ≤ 0.7 and FRAC2 = 0.9 PSMR becomes constant to the value 88.31, 84.12 and80.89 respectively. So the value of FRAC1 is assumed as 0.7 and of FRAC2 is assumed as0.9.

Again for FRAC1 = 0.7 and FRAC2 = 0.9 the percentage of Type_II message loss isminimum for FRAC3 = 0.3 which can be observed from Tables 5, 6 and 7. So the value ofFRAC3 is assumed as 0.3.

123


5 Conclusion

The present work is a secure V2V communication in VANET. The RSU and each vehicleparticipate in the reduction of channel congestion during V2V communication. The RSUdetects misbehaving vehicles and revokes them from VANET.

Each vehicle may share its own transmission power level with other vehicles and mayestimate its own transmission power level before sending a message based on the sharedinformation. The detection and revocation of misbehaving vehicles may be done in a distrib-uted way by vehicles.

Appendix

Table 5 For N = 120 FRAC2 FRAC1 FRAC3 PSMR (%) PSML (%)

0.1 0.05 0.01 98.87 85.89

0.2 0.1 0.05 98.33 85.99

0.3 0.2 0.1 97.45 85.90

0.1 0.05 98.49 86.12

0.4 0.3 0.2 97.67 85.45

0.1 98.65 85.34

0.2 0.1 98.34 86.64

0.1 0.05 98.54 87.90

0.5 0.4 0.3 96.54 85.98

0.2 95.56 85.98

0.1 95.76 85.99

0.3 0.2 95.00 86.48

0.1 95.51 86.47

0.2 0.1 95.95 86.98

0.1 0.05 95.90 87.00

0.6 0.5 0.4 95.64 76.00

0.3 95.76 76.98

0.2 94.65 76.98

0.1 95.98 76.87

0.4 0.3 95.12 77.98

0.2 95.00 77.23

0.1 94.65 77.23

0.3 0.2 93.76 77.99

0.1 93.89 78.01

0.2 0.1 93.45 79.10

0.1 0.05 92.56 79.88

0.7 0.6 0.5 93.12 60.55

0.4 93.45 60.98

123

S. Mitra, A. Mondal

Table 5 continued FRAC2 FRAC1 FRAC3 PSMR (%) PSML (%)

0.3 93.76 60.34

0.2 93.35 60.65

0.1 92.57 60.13

0.5 0.4 93.12 61.78

0.3 92.15 61.54

0.2 92.16 61.99

0.1 92.15 61.34

0.4 0.3 91.99 62.00

0.2 91.88 62.16

0.1 91.00 62.76

0.3 0.2 91.78 63.54

0.1 92.65 63.88

0.1 0.05 90.67 64.07

0.8 0.7 0.6 90.55 50.89

0.5 90.54 51.98

0.4 90.99 51.88

0.3 91.01 51.99

0.2 90.45 50.65

0.1 90.66 50.12

0.6 0.5 90.54 51.88

0.4 91.67 51.56

0.3 90.26 51.08

0.2 90.54 50.98

0.1 90.23 50.87

0.5 0.4 89.77 52.35

0.3 89.77 52.98

0.2 89.77 52.34

0.1 89.77 52.24

0.4 0.3 89.56 53.98

0.2 89.87 53.46

0.1 89.56 53.89

0.3 0.2 89.99 54.89

0.1 89.99 54.89

0.2 0.1 88.98 55.10

0.1 0.05 88.97 55.99

0.9 0.8 0.7 88.46 24.78

0.6 88.67 24.65

0.5 88.56 24.87

0.4 88.25 24.98

0.3 88.88 24.57

0.2 88.63 24.98

0.1 88.87 24.56

0.7 0.6 88.31 25.87

123



0.5 88.31 25.98

0.4 88.31 25.98

0.3 88.31 25.16

0.2 88.31 25.16

0.1 88.31 26.16

0.6 0.5 88.31 26.88

0.4 88.31 26.76

0.3 88.31 26.65

0.2 88.31 26.45

0.1 88.31 26.87

0.5 0.4 88.31 26.99

0.3 88.31 27.45

0.2 88.31 27.98

0.1 88.31 27.12

0.4 0.3 88.31 28.98

0.2 88.31 28.98

0.1 88.31 28.98

0.3 0.2 88.31 29.92

0.1 88.31 29.78

0.2 0.1 88.31 29.45

0.1 0.05 88.31 29.99

Table 6 N = 150 FRAC2 FRAC1 FRAC3 PSMR (%) PSML (%)

0.1 0.05 0.01 96.13 89.01

0.2 0.1 0.05 95.56 88.12

0.3 0.2 0.1 94.98 86.28

0.1 0.05 94.87 87.49

0.4 0.3 0.2 93.99 80.24

0.1 92.45 80.24

0.2 0.1 93.67 82.56

0.1 0.05 93.89 82.99

0.5 0.4 0.3 91.56 79.45

0.2 91.56 79.90

0.1 91.56 79.76

0.3 0.2 92.01 80.46

0.1 91.51 80.46

0.2 0.1 91.75 82.98

0.1 0.05 91.90 83.34

123

S. Mitra, A. Mondal


0.6 0.5 0.4 89.47 65.89

0.3 89.65 65.23

0.2 89.23 65.89

0.1 90.46 65.00

0.4 0.3 88.45 66.12

0.2 90.29 66.78

0.1 90.00 66.98

0.3 0.2 88.43 66.99

0.1 88.49 71.65

0.2 0.1 88.32 71.98

0.1 0.05 88.47 72.01

0.7 0.6 0.5 88.12 55.32

0.4 87.12 55.98

0.3 87.45 55.87

0.2 87.09 55.32

0.1 87.34 55.78

0.5 0.4 87.35 57.67

0.3 87.43 57.98

0.2 86.43 57.98

0.1 85.09 57.24

0.4 0.3 86.98 59.12

0.2 87.43 59.87

0.1 87.65 59.17

0.3 0.2 88.76 59.98

0.1 86.43 59.12

0.1 0.05 85.87 60.07

0.8 0.7 0.6 86.65 30.43

0.5 86.96 30.45

0.4 87.01 31.38

0.3 86.98 30.65

0.2 86.34 30.65

0.1 86.43 30.54

0.6 0.5 86.12 31.45

0.4 86.12 31.98

0.3 86.12 31.98

0.2 86.12 31.98

0.1 86.12 31.34

0.5 0.4 85.23 33.45

0.3 85.87 33.98

0.2 85.98 32.86

0.1 85.34 33.76

123



0.4 0.3 86.05 34.01

0.2 86.02 34.54

0.1 85.99 34.67

0.3 0.2 85.90 35.65

0.1 85.45 36.65

0.2 0.1 85.32 36.98

0.1 0.05 85.09 37.76

0.9 0.8 0.7 84.98 20.13

0.6 84.94 20.13

0.5 85.00 20.13

0.4 84.67 20.13

0.3 84.65 20.34

0.2 84.23 20.32

0.1 84.23 20.43

0.7 0.6 84.12 21.98

0.5 84.12 21.98

0.4 84.12 21.87

0.3 84.12 21.81

0.2 84.12 21.86

0.1 84.12 21.99

0.6 0.5 84.12 22.09

0.4 84.12 22.78

0.3 84.12 22.65

0.2 84.12 22.45

0.1 84.12 22.87

0.5 0.4 84.12 22.99

0.3 84.12 24.56

0.2 84.12 24.98

0.1 84.12 24.65

0.4 0.3 84.12 24.98

0.2 84.12 24.98

0.1 84.12 24.98

0.3 0.2 84.12 25.92

0.1 84.12 25.78

0.2 0.1 84.12 26.45

0.1 0.05 84.12 27.99

Table 7 For N = 180 FRAC2 FRAC1 FRAC3 PSMR (%) PSML (%)

0.1 0.05 0.01 91.45 92.00

0.2 0.1 0.05 91.20 90.88

0.3 0.2 0.1 91.43 90.03

0.1 0.05 91.45 91.78

123

S. Mitra, A. Mondal


0.4 0.3 0.2 91.67 87.98

0.1 90.45 87.99

0.2 0.1 90.45 88.45

0.1 0.05 90.65 88.88

0.5 0.4 0.3 90.00 82.99

0.2 90.35 82.54

0.1 90.56 82.34

0.3 0.2 90.76 83.90

0.1 91.56 83.77

0.2 0.1 91.98 83.98

0.1 0.05 91.45 84.45

0.6 0.5 0.4 90.86 70.88

0.3 88.90 70.77

0.2 89.98 71.09

0.1 90.87 71.44

0.4 0.3 89.05 71.65

0.2 89.29 71.45

0.1 90.00 71.34

0.3 0.2 88.43 72.99

0.1 88.43 72.45

0.2 0.1 88.43 73.88

0.1 0.05 88.43 73.88

0.7 0.6 0.5 87.55 67.00

0.4 88.90 66.45

0.3 88.56 66.66

0.2 88.09 66.98

0.1 87.23 66.12

0.5 0.4 88.55 67.09

0.3 87.39 67.05

0.2 86.89 67.88

0.1 85.99 67.32

0.4 0.3 85.65 68.09

0.2 85.09 68.88

0.1 85.09 68.33

0.3 0.2 85.09 68.98

0.1 85.09 69.09

0.1 0.05 85.32 69.99

0.8 0.7 0.6 86.45 58.09

0.5 86.98 59.09

0.4 86.65 59.00

0.3 85.92 60.65

0.2 85.92 60.33

123



0.1 85.92 60.09

0.6 0.5 85.92 60.87

0.4 85.92 60.77

0.3 84.89 60.98

0.2 84.90 61.09

0.1 84.90 61.45

0.5 0.4 84.87 61.99

0.3 84.99 61.99

0.2 84.23 61.99

0.1 83.56 61.99

0.4 0.3 83.98 62.09

0.2 83.98 62.07

0.1 83.76 62.77

0.3 0.2 83.86 63.45

0.1 83.98 64.09

0.2 0.1 83.77 64.98

0.1 0.05 82.77 64.99

0.9 0.8 0.7 81.66 30.98

0.6 81.98 30.98

0.5 81.23 30.98

0.4 81.65 30.87

0.3 81.65 30.98

0.2 81.65 30.67

0.1 81.98 30.09

0.7 0.6 80.89 31.44

0.5 80.89 31.44

0.4 80.89 31.04

0.3 80.89 31.00

0.2 80.89 31.55

0.1 80.89 32.33

0.6 0.5 80.89 32.44

0.4 80.89 32.78

0.3 80.89 32.65

0.2 80.89 32.45

0.1 80.89 32.87

0.5 0.4 80.89 33.94

0.3 80.89 33.54

0.2 80.89 33.58

0.1 80.89 33.75

0.4 0.3 80.89 34.38

123

S. Mitra, A. Mondal


0.2 80.89 34.95

0.1 80.89 36.44

0.3 0.2 80.89 36.92

0.1 80.89 36.78

0.2 0.1 80.89 37.45

0.1 0.05 80.89 37.99

References

1. Wischhof, L., & Rohling, H. (2005). Congestion control in vehicular ad hoc networks. In IEEE Interna-tional conference on vehicular electronics and safety, Germany, pp. 58–63.

2. Zang, Y., Stibor, L., Cheng, X., Reumerman, H.-J., Paruzel, A., & Barroso, A. (2007). Congestion controlin wireless networks for vehicular safety applications. 8th European wireless conference, p. 7. Paris,France.

3. Bouassida, M. S., & Shawky, M. (2008). On the congestion control within VANET. Wireless days, WD’08 1st IFIP digital object identifier, (pp. 1–5). doi:10.1109/WD.2008.4812915.

4. Zhang, W., Festag, A., Baldessari, R., & Le, L. (2008). Congestion control for safety messages in VANETs:Concepts and framework. Proceedings 8th conference on ITS telecommunications, pp. 199–203.

5. Campolo, C., Cortese, A., & Molinaro, A. (2009). CRaSCH: A cooperative scheme for service channelreservation in 802.11p/WAVE vehicular ad hoc networks. Proceedings of international conference onultra modern telecommunications and workshops, pp. 1–8.

6. Bouassida, M. S., & Showky, M. (2010). A cooperative congestion control approach within VANETs:Formal verification and performance evaluation. Hindawi Publishing Corporation, Eurasip Journal onWireless Communications and Networking, pp. 1–26, article no. 11.

7. He, J., Chen, H.-H., Chen, T. M., & Cheng, W. (2010). Adaptive congestion control for DSRC vehiclenetworks. IEEE Communication Letters, 14(2), 127–129.

8. Darus, M. Y. B., & Bakar, K. A. (2011). Congestion control framework for disseminating safety messagesin vehicular ad-hoc networks. International Journal of Digital Content Technology and its Applications,5(2).

9. Humeng, L., Xuemei, Y., Li, A., & Yuan, W. (2012). Distributed beacon frequency control algorithm forVANETs (DBFC). International conference on intelligent systems design and engineering application,pp. 243–246.

10. Darus, M. Y., & Bakar, K. A. (2013). Formal verification of congestion control algorithm in VANETs.International Journal of Computer Network and Information Security, 4, 1–7.

11. Darus, M. Y., & Bakar, K. A. (2013). Congestion control algorithm in VANETs. World Applied SciencesJournal, 21(7), 1057–1061.

12. Mondal, A., & Mitra, S. (2012). Identification, authentication and tracking algorithm for vehicles usingVIN in centralized VANET. International conference on advances in communication, network, and com-puting, LNICST 108, pp. 115–120.

13. Artimy, M. M. (2007). Assignment of dynamic transmission range based on estimation of vehicle density.In IEEE Transactions on Intelligent Transportation Systems, 8(3), 400–412.

14. Rawat, D. B. (2011). Enhancing VANET performance by joint adaptation of transmission power andcontention window size. In IEEE Transaction on Parallel and Distributed Systems, 22(9), 1528–1535.

15. Batsuuri, T., Bril, R. J., & Lukkien, J. (2010). Application level phase adjustment for maximizing thefairness in VANET. IEEE 7th international conference on mobile adhoc and sensor systems, MASS 2010,8–12 November 2010.

16. Konur, S., & Fisher, M. (2011) Formal analysis of a VANET congestion control protocol through proba-bilistic verification. Proceedings of 73rd IEEE vehicular technology conference, Budapest, Hungary.

17. Towards Effective Vehicle Identification. (2004). The NMVTRC’s strategic framework for improving theidentification of vehicles and components.

18. http://en.wikipedia.org/wiki/Intelligent_driver_model

123

http://dx.doi.org/10.1109/WD.2008.4812915

http://en.wikipedia.org/wiki/Intelligent_driver_model


Sulata Mitra received B.E. degree from Bengal Engineering College(India) in 1986 and Ph.D. degree in Mobile Computing from BengalEngineering College (D.U.), Shibpur (India) in 2005. She joined theIndian Institute of Technology, Kharagpur in 1989 as Senior ResearchAssistant and moved to the Regional Institute of Technology, Jamshed-pur (India) in 1991 as Lecturer. Dr. Mitra has published 50 technicalpapers in journal and international conference proceedings. Her cur-rent research interest is QoS issues in 3G/4G cellular network, VANET,Multihomed mobile network. She is currently with the Computer Sci-ence and Technology Department of Bengal Engineering and ScienceUniversity, Shibpur (India) as Associate Professor.

Atanu Mondal received M. Tech (CSE) degree from Calcutta Uni-versity (India) in 2008 and currently pursuing his Ph.D. in differentsecurity aspects in VANET from Computer Science and TechnologyDepartment of Indian Institute of Engineering, Science and Technol-ogy, Shibpur. He is currently with the Computer Science and Engineer-ing Department of Camellia Institute of Technology, Kolkata as Assis-tant Professor.

123

Documents

Joint Congestion Control Strategy During V2V Communication Among Authentic Vehicles in VANET