traffic information system to deliver in-vehicle messages on pre-defined routes using dsrc based v2v...

TRAFFIC INFORMATION SYSTEM TO DELIVER IN-VEHICLE MESSAGES ON 1

PRE-DEFINED ROUTES USING DSRC BASED V2V COMMUNICATION 2

3

4

Attiq Uz Zaman, Corresponding Author 5

Graduate Research Assistant 6

Department of Electrical Engineering 7

University of Minnesota-Duluth, 8

271 Marshal –W.-Alworth-Hall, 1023 University Drive, 9

Duluth, MN 55812 10

Email: [email protected] 11

Tel: 218-213-1575 Fax: 218-726-7267; 12

13

M I Hayee 14

Professor 15

Department of Electrical Engineering 16

University of Minnesota-Duluth 17

271 Marshal –W.-Alworth-Hall, 1023 University Drive, 18

Duluth, MN, 55812 19


Tel 218 726 6743 21

22

Navin Katta 23

Research and Development Engineer 24

Savari Inc. 25

Address 2005, De la Cruz Blvd., Suite #131, Santa Clara, CA -95050 26


Tel 408-833-6369 28

29

Sean Mooney 30

Research and Development Engineer 31

Savari Inc. 32

Address 2005, De La Cruz Blvd., Suite # 131, Santa Clara, CA - 95050 33


Tel 408-833-6369 35

36

37

Number of words = (5,471 + 6 figures/tables @ 250) = 6971 Words + 21 References 38

Using 7000 words limit + References 39

40

41

42

43

Submission Date 44

8/01/201545

mailto:[email protected]




A. Zaman, Hayee, Katta and Mooney 2

ABSTRACT 1

This paper describes the architecture and functionality of a work zone traffic information system 2

using Dedicated Short Range Communication (DSRC) based vehicle to vehicle communication 3

and a newly designed hopping algorithm. The proposed hopping algorithm can deliver in-vehicle 4

messages transmitted by a roadside unit installed at work zone site to far away vehicles travelling 5

towards work zone on pre-defined routes. Our hopping algorithm uses rectangular regions to 6

define a hopping route and can hop messages to vehicles on multiple routes at the same time 7

without the risk of creating a broadcast storm. Although, the messages hopped by the proposed 8

hopping algorithm will generally be applicable to the vehicles on only one side of the road 9

(travelling towards work zone), the DSRC equipped vehicles present on both sides of the road will 10

participate in hopping to maximize the number of available hopping nodes in situations with lighter 11

traffic flow and/or low DSRC market penetration. Furthermore, our hopping algorithm increases 12

message security by not requiring any hopping nodes (i.e., DSRC equipped vehicles) to modify 13

the contents of the hopped message. We have also performed numerical simulations to evaluate 14

the performance of the proposed hopping algorithm. The simulation results show that the proposed 15

hopping algorithm works as expected and successfully disseminate DSRC messages along a pre-16

defined route. 17

18

19

Keywords: DSRC, V2V Communication, Work Zone, In-Vehicle Message, Hopping, Pre-20

Defined Routes 21

22


INTRODUCTION 1

One important application of Intelligent Transportation System (ITS) is to improve traffic mobility 2

in the area of work zones. Several research articles show that congestion in a work zone can grow 3

quickly and often results in accidents, especially in rush hours (1-2). Only in 2013, there were 579 4

fatalities due to vehicle crashes in work zones on US roadways (3). Studies have also shown that 5

most of the work zone crashes involve rear-ending collision, usually at the end of the traffic queue 6

(4) which necessitates the need of an intelligent traffic information system for work zones to 7

provide drivers with safety critical information in a timely manner (5,6). 8

Any work zone traffic information system has basically dual objectives; (i) gather dynamic 9

traffic parameters such as the back of queue location, congestion length and travel time (TT), and 10

(ii) disseminate these parameters to the vehicles approaching the congestion in a timely manner 11

using Vehicle to Infrastructure (V2I) communication, Vehicle to Vehicle (V2V) communication, 12

or a combination of both. Although, any wireless communication technology could be used for 13

V2V or V2I communication, Dedicated Short Range Communications (DSRC) has been a 14

preferred choice for ITS applications due to its high speed, low latency and highly secure wireless 15

communication protocol (7). 16

Several research studies have proposed systems and algorithms to accomplish these tasks 17

(8 to 17). One critical aspect of these proposed studies is to convey the information message from 18

a distance roadside unit or from another vehicle (usually event driven) to a remote vehicle of 19

concern. To accomplish this important task, some sort of Vehicular Ad-hoc Networks (VANETs) 20

protocol or hopping algorithm is needed. Any successful hopping algorithm for a work zone traffic 21

information system needs to have the following three features. 22

The traffic parameters should be disseminated to the vehicles on a specific path which 23

could potentially be affected by the work zone congestion. 24

While broadcasting the message via V2V communication, all vehicles or hopping nodes 25

should not broadcast blindly to avoid broadcast storm. (18) 26

The risk of any node or vehicle tampering with the messages to be hopped should be 27

minimized for security reasons. 28

The referenced research studies (8 to 17) if applied to work zone traffic information system 29

will have some limitations in terms of not incorporating all of the above mentioned features at the 30

same time. In most of these studies (8-14) hopping is performed via a probability based hopping 31

algorithm in which each vehicle needs to know the distance from its nearby one-hop neighbors to 32

determine if it should hop the message. However, none of these hopping algorithms is able to route 33

the message to a specific route. Our earlier proposed method (16, 17) suggests a hopping algorithm 34

using DSRC based V2V communication on a predefined route but that method will not be able to 35

keep the hopped message on a desired road if sharp turns are present on that route. Additionally, 36

that method required each vehicle or hopping node to modify the contents of the header of the 37

information message making it prone to security risks. 38

In this paper, we propose a work zone traffic information system which solves the problem 39

of propagating a message along one or more specific routes regardless of any sharp turns present 40

in any of the desired routes. Furthermore, proposed hopping algorithm keeps the message to be 41

hopped as “read only” for the vehicles which can potentially increase security as well as decrease 42

processing time, because none of the hopping nodes (vehicles) are required to change the contents 43

of the original message. This can result in enhanced security because only roadside unit will need 44

to use proper security certificates which has more processing power so any desired level of security 45

could be achieved at roadside unit. 46

We have performed simulations and preliminary field tests to evaluate our proposed 47


hopping algorithm using DSRC devices. The results suggest that the proposed hopping algorithm 1

can successfully convey an information message from a roadside unit to vehicles on one or more 2

specific predefined routes using DSRC based V2V communication. In future, we also plan to do 3

more field tests to demonstrate proposed hopping algorithm and traffic information system to carry 4

in-vehicle messages via V2V hopping. 5

The rest of the paper is organized as follows. An overview of the proposed information 6

system architecture is given in next section followed by detailed description of hopping algorithm 7

in section 3. The results of simulations and preliminary field tests are described in section 4 8

followed by conclusions and future work described in the last section. 9

10

SYSTEM ARCHITECTURE 11

A conceptual diagram of the proposed traffic information system to deliver in-vehicle messages 12

on a predefined route is given in Figure 1 in which a work zone is shown on a four-lane highway 13

(two lanes in each direction). Due to work zone related lane closure the congestion can build and 14

grow past the work zone as shown in Figure 1. 15

16

17 FIGURE 1 Conceptual architectural diagram of the developed information system for 18

work zone to deliver in-vehicle messages on a predefined route. 19

20

In the proposed system, one roadside unit is required and is placed near the end of the work 21

zone to disseminate the information message to vehicles on a predefined route. Roadside unit can 22

either acquire dynamic traffic parameters for the information message communicating with the 23

ongoing DSRC equipped vehicles or it can obtain the information message parameters by a traffic 24

control center. The position of the roadside unit is preferred to be at the end of the work zone 25

coinciding with the end of the queue which is usually known and fixed. However, the back of the 26

queue can vary with the traffic flow, especially in rush hours when it can grow well beyond the 27

beginning of the work zone. The traffic information message can contain work zone related 28

parameters e.g., lane closure, speed limit, travel time, back of the location etc. In addition to the 29

information useful to the driver of the vehicle approaching to the work zone, information message 30

will also carry the information about the predefined route for vehicles to determine if the message 31

is relevant to a particular vehicle and whether it needs to hop/re-broadcast that message. 32

In the proposed algorithm, hopping route can be defined using simple rectangular regions 33

as shown in figure 1. Each rectangle is represented by two mid points of shorter sides (longitudes 34

and latitudes) and its width. The width of the main rectangles is preferred to be selected at least 35

equal to the road width so that the vehicles moving in both directions can participate in hopping. 36

In actual practice, we have kept the width to be at least 10 meters more (5 meter on each side) to 37

accommodate GPS location error which is around 3-5 m for absolute position error (19). This will 38

Roadside Unit

Traffic control

center

Rect 1

Start of Work Zone

Back of queueRoadside unit’s wireless

range

Non-DSRC equipped Vehicles

DSRC equipped Vehicles

Shorter Rectangles due to curved road

Longer Rectangles for straight roads

End of work zone

Direction of traffic flow


ensure that a vehicle can successfully locate itself inside any rectangle based upon its GPS 1

coordinates. The maximum rectangle width should be restricted to exclude as many parallel roads 2

as possible or significant portions of crossing roads to avoid dissemination of the information 3

message to the vehicles on unwanted routes. Each DSRC equipped vehicle’s On-Board Unit 4

(OBU) contains a GPS receiver in addition to DSRC radio and a processing unit. The concatenated 5

set of rectangles inside the information message, represents a complete hopping route. The number 6

of concatenated rectangles in a given hopping route can vary depending upon the curvature of the 7

road with shorter rectangles for the curved part of the road and longer rectangles for the straight 8

part of the road as shown in Figure 1. Adjacent concatenated rectangles in a given hopping route 9

may slightly overlap each other for the curved part of the road (Figure 1). The rectangular regions 10

or rectangles constituting the hopping route can be drawn for any desired hopping route using a 11

web based application which is also being developed as part of our ongoing SBIR project and will 12

be described in a future work. Each hopping route in the form coordinates of concatenated 13

rectangles is encoded in the header of the information message by the roadside unit before 14

transmitting. 15

Information messages can be disseminated to more than one geographical routes at the 16

same time as long as all hopping routes are encoded in the header of the information message by 17

the roadside unit. Two such scenarios of multiple hopping routes are shown in Figure 2. First 18

scenario represents a highway merge junction where two highways merge to a single highway 19

having a work zone. The work zone related information messages will be applicable to both of 20

these highways because vehicles coming on both these highways towards work zone direction will 21

end up passing through the work zone. Therefore, there is a need to disseminate the message to the 22

vehicles on both highway routes. Similarly, the second scenario of Figure 2 represents a T-junction 23

intersection where there is a work zone on one leg of the T-junction. In case of multiple hopping 24

routes, each geographic route will be defined using a web based application and encoded in the 25

header of the information message, separately, by the roadside unit. Following the rectangle which 26

covers the highway merge junction or split of the hopping route, as shown in Figure 2 where there 27

are two distinct routes in each of the two scenarios represented by rectangles (1, 2, and 3a) and (1, 28

2, and 3b). 29

As mentioned earlier, traffic information message can either be dynamically acquired by 30

the roadside unit or it can be sent from a remote traffic information center. In this paper, for the 31

demonstration of hopping algorithm, we will assume that the traffic information message is being 32

provided to the roadside unit by a traffic control center. However, in our future field trials we will 33

use a dynamic traffic parameter acquisition algorithm which we have recently developed under 34

this project (to be described in a future work). 35


1

FIGURE 2 Two scenarios depicting the need of multiple predefined hopping routes. 2

3

Once a roadside unit is installed and provided with the information message as well as the 4

hopping route, it prepares the information message for hopping by encoding the hopping route in 5

the header of the information message. For this paper, we are assuming that information message 6

is in the form of DSRC based Traveler Information Message (TIM). The optional data fields of the 7

TIM are used to carry the hopping route information. We are also developing a web based TIM 8

configuration tool to accomplish this task which will be described in a future work. The roadside 9

unit will periodically transmit TIM which will be received by all the DSRC equipped vehicles’ 10

OBUs present on the road within the direct wireless access range of the roadside unit. After 11

receiving TIM from roadside unit, each vehicle first determines if it is on the desired route defined 12

in the TIM as well as it will compare its calculated direction of travel with the direction given in 13

the TIM to determine if the TIM is applicable to the vehicle. If so, the vehicle’s OBU will extract 14

relevant information from the TIM and present that information to the driver via an android based 15

audio-visual interface which is also under development. However, even if the information message 16

is not applicable to the vehicle because it is travelling in the direction opposite to the work zone 17

congestion but still present on the hopping route, it will participate in hopping by using our 18

proposed hopping algorithm to determine if it should hop or rebroadcast the received TIM for the 19

RSE Rect 1Rect 2

Junction region

Highway 3

Highway 2

(i)

RSE

T junction with or without a stop sign

Rect 1 Rect 2 Rect 3a

Rect 3b

(ii)


vehicles farther away on the hopping route. We will describe the hopping algorithm in more detail 1

in the following section. 2

3

HOPPING ALGORITHM 4

Our proposed hopping algorithm works in such a way that any vehicle which will hop the message 5

will not be required to make any changes in the original message before re-broadcasting that 6

message. This will have an additional benefit that less processing power will be used at each 7

hopping node (or DSRC equipped vehicle) as well as is less vulnerable to security risk by rogue 8

elements which could distort the contents of the original information message before broadcasting. 9

Furthermore, our hopping algorithm confines the message broadcast to a predefined hopping route 10

to ensure that only those vehicles receive the message which need the relevant information. Finally, 11

our algorithm will avoid broadcast storm (18) by ensuring that if more than one vehicle receives 12

an information message at the same time, only one of those vehicles rebroadcasts it. If multiple 13

vehicles compete to hop the message, our hop timing control procedure will resolve the contention, 14

making sure only one of those vehicles rebroadcasts the message. Next, we will describe following 15

three key features of our hopping algorithm to explain the functionality of our algorithm. 16

1) Predefined hopping route 17

2) Hop timing control 18

3) DSRC specific hop timing control limitation and solution 19

20

Predefined Hopping Route 21

As explained earlier, each hopping route consists of concatenated rectangular regions on a desired 22

road. Each rectangle is represented by longitude and latitude of mid points of two shorter sides 23

and its width which is selected as equal to the width of the road (considering both sides) plus an 24

additional 10 m or so to accommodate GPS location error whereas length of each main rectangle 25

is preferred to be kept as long as possible without skipping any curved path or adding too many 26

unintended parallel routes, so that less rectangles are required to define a specific route in the 27

header of information message, which will result in smaller information packet size to transmit 28

through the air. A hypothetical hopping route with corresponding rectangular regions is shown in 29

Figure 3. The hopping route shown in Figure 3 consists of only 4 main rectangles marked from M 30

= 1 to 4. The roadside unit will need to encode the coordinates of each of these 4 concatenated 31

rectangles in the header of the information message e.g., TIM to be hopped to that particular route. 32

Length of each main rectangle is assumed to be much larger than the wireless access range of 33

DSRC which means that generally more than one hop is needed in each main rectangle to carry 34

the information message through the rectangle. Therefore, when each vehicle or OBU receives an 35

information message to be hopped, it virtually divides each main rectangle into several sub-36

rectangles shown for main rectangle M = 2 in Figure 3(a) which are numbered from N = 1 to NM. 37

The rationale of dividing each main rectangle into virtual sub-rectangles will be discussed in the 38

next section of hop timing control. The length of each virtual sub-rectangle is determined by the 39

OBU in such a way that the distance from the beginning of any sub-rectangle to the end of the 40

following adjacent sub-rectangle does not exceed the practical wireless access range of DSRC. 41

Although, theoretical range of DSRC is 1 km (20), in most practical scenarios it turns out to be 42

around 500 m so our algorithm will keep the maximum length of each sub-rectangle to be no more 43

than 250 m. The minimum vehicle density required to successfully propagate TIM through the 44

hopping route will be at least one vehicle per 500 m covering at least 2 sub-rectangles or more 45

depending upon the calculated length of the sub- rectangles. Equations to calculate sub-rectangle 46

length are given in next section. 47


1 2

FIGURE 3 A typical hopping route with 4 main rectangles showing sub-rectangles of one 3

main rectangle with (a) an OBU in second main rectangle, and (b) multiple OBUs in first 4

main rectangle to illustrate message hopping. Note that in (b), the hopping route is shown 5

with solid arrows and dashed arrows (only shown in first three sub-rectangles) indicate 6

message was received but not hopped. 7

8

Hop Timing Control 9

Hop timing control mechanism is designed to avoid broadcast storm and minimize the number of 10

total hops to carry out the information message to the farthest end of the hopping route by ensuring 11

that only farthest vehicle or OBU in any sub-rectangle hops the received information message. 12

Once a vehicle or OBU receives an information message from roadside unit or a preceding vehicle, 13

it will determine which main rectangle it falls in using a simple geometrical calculation method 14

(not given in this paper). If the vehicle or OBU is not present in any of the main rectangles, then it 15

means that the information message was not meant for this vehicle and the vehicle just ignores the 16

information message. However, if an OBU can locate itself on one of the main rectangles and 17

determines the number of main rectangle (M) it falls in, then it will calculate the perpendicular 18

distance from its current position to the beginning of the main rectangle (DM) as shown in Figure 19

3a. Based upon DM and length of the main rectangle (LM), each OBU will divide the main rectangle 20

into virtual sub-rectangles and determine the total number of sub-rectangles (NM) in the main 21

rectangle M, as well as the number N of the sub-rectangle it falls in using equations 1 to 3. 22

23

250

MM

Lceil = N (1) 24

25

26

M

MSRM

N

L = L (2) 27

28

N = 1 N = 2 N = 3 N = 4

- - - - - - - - - - - - - - - - - - - - - - - - - -N = Nm

LSRM

0.1-0.2 0.2-0.3

N = 1 N = 2 N = 3 N = 7 N = 8 N = 9N = 4 N = 5 N = 6 N = 10

g

0.3-0.4 0.4-0.5 0.5-0.6 0.6-0.7 0.7-0.8 0.8-0.9 0.9-1.0 1.0-1.1

ih jf

d eca b k l m nRSU

Hopping windows(sec)

(a)

(b)


SRM

M

L

Dceil = N (3) 1

2

Where NM is number of sub-rectangle in a given rectangle, LM is the length of that given 3

main rectangle calculated as the straight line distance between the two mid points of the main 4

rectangle given in the hopping route, LSRM is the length of each sub-rectangle in Mth main rectangle, 5

N is the number of the sub-rectangle in which the vehicle’s OBU is located, and DM is the 6

perpendicular distance from the position of the vehicle to the beginning of the region. 7

The rationale of dividing each main rectangle in multiple sub-rectangles is to assign a 8

timing window defined by lower time limit (LTL) and upper time limit (UTL) to each sub-rectangle 9

in such a way that any vehicle or OBU will only be able to hop the message within its own timing 10

window to avoid broadcast storm. However, for any OBU to hop the message, it must receive the 11

message before the LTL of its timing window. For illustrative purposes, we have assigned a 100 12

msec timing window to each sub-rectangle so that any information message can be hopped through 13

one sub-rectangle in 100 msec as shown in Figure 3b. This timing window can be varied for various 14

applications, however, for DSRC applications, it seems to be a natural choice because one 15

complete cycle of DSRC service and control channel is 100 msec (21). 16

Once an OBU determines N and NM using equation 1 to 3 above, it will now calculate its 17

sub-rectangle’s LTL using equation 4. 18

19

))(1.0())1.0)(((__1

1NiN = LimitTimeLower

M

i M

(4) 20

21

After calculating LTL of the sub-rectangle N, the OBU will calculate a hopping wait time 22

(HWT) using equation 5 to determine when it will actually rebroadcast the message. 23

24

)1.0(250

250)1((1.0

NDLTL = HWT M

(5) 25

After calculating HWT, an OBU will wait for (HWT – Normalized Current Time) before 26

actually rebroadcasting the message, where the Normalized Current Time is the time difference 27

between the time when the information message or TIM was received by an OBU and the time 28

when it was transmitted first by the roadside unit. It should be noted that first transmission time is 29

also encoded by the roadside unit in the header of the information message i.e., TIM in this case. 30

HWT is calculated in such a way that the OBUs near the beginning of the sub-rectangle 31

have higher HWT values as compared to those OBUs which are farther away from the beginning 32

of the sub-rectangle. As a result, if multiple OBUs are located inside one sub-rectangle and receive 33

the same TIM at the same time, then the OBU farthest from the beginning of that sub-rectangle 34

will re-broadcast the message first. When the other OBUs in the same sub-rectangle which are still 35

waiting to hop, receive the same message again, they will come out of their waiting mode and will 36

not hop. The OBUs will recognize if the two messages are the same by comparing one of the 37

unique message field which in the case of TIM was its transmission time. 38

To illustrate the hopping algorithm’s functionality, Figure 3b shows multiple OBUs in a 39

given main rectangle (M = 1) along with virtual sub-rectangles and their corresponding hopping 40

windows. For the illustrative purposes, we have assumed that the number of sub-rectangles (NM) 41

in this main rectangle is 10 and length of each sub-rectangle is around 250 m which is maximum 42

possible length. Once an information message or TIM is transmitted by the roadside unit, assume 43


that it is received by OBUs “a” and “b” in the first sub-rectangle (N = 1) at almost the same time 1

because both are within the wireless access range of roadside unit. Both OBUs will wait for a 2

specific time (HWT – Normalized Current Time) before rebroadcasting. Due to it being farther 3

away, OBU “b” will have a smaller HWT as compared to HWT of OBU “a”. Therefore, OBU “b” 4

will hop the TIM first. Now the TIM hopped by OBU “b” will be received by all OBUs that are 5

within the wireless access range of OBU “b” (OBU “a”, “c” and “d”). Since OBU “a”, which is 6

waiting to hop that message, will receive the same TIM for the second time inside its hopping 7

window (0.1-0.2 s), it will recognize that this TIM has already been hopped by an OBU which is 8

in the same sub-rectangle and thus it will terminate its waiting process and will not hop. On the 9

other hand OBUs “c” and “d” will start waiting to hop this TIM according to their respective 10

calculated HWTs. Since HWT of OBU “c” will be smaller than that of OBU “d”, it will hop TIM 11

first. This process continues until the message reaches to OBU ‘n’ (Figure 3b). Please note that the 12

solid arrows in Figure 3b represent the actual hopping paths while the dashed arrows (shown only 13

in first two sub-rectangles) represent the TIM reception paths which do not end up hopping the 14

message. 15

16

DSRC Specific Hop Timing Control Limitation and Solution 17

If messages are transmitted according to any non-DSRC based protocol then the above mentioned 18

equations would work fine but according to DSRC based protocol, every 100 msec is divided into 19

50 msec of “control window” and 50 msec of “service window” (21). TIM can be 20

transmitted/received only inside the service time window by a DSRC device. Therefore equation 21

4 and 5 are modified to make sure that OBUs only transmit during the “service window”. The 22

modified equations 4 and 5 are given below as equations 6 and 7. 23

24

05.0))(1.0())1.0)(((__1

1

NiN = LimitTimeLower

M

i M (6) 25

26

)049.0(250

250)1((049.0

NDLTL = HWT M

(7) 27

28

To illustrate the difference between using a full 100 msec window as compared to using 29

only service window (50 msec) for hopping, a graphical timeline is shown in Figure 4 for first 4 30

sub-rectangles with OBUs ‘a’ to ‘d’ of Figure 3b. This comparative timeline explains the difference 31

between the calculated HWTs using original and modified equations. 32

The hopping windows are shrunk from 100 msec to 50 msec when we use only service 33

time window as seen in Figure 4. Initially both OBUs “a” and “b” receive information message or 34

TIM but OBU “b” will hop the message first because its HWT will be less than the HWT of OBU 35

“a”. To illustrate the difference in calculated HWTs in both cases, let’s assume that the HWT for 36

OBU “b” is around 125 msec using the full 100 msec hopping window. Since that hopping time 37

will occur in the middle of the control window (100-150 msec.), so OBU ‘b’ cannot hop the TIM 38

until control window expires at 150 msec timing mark and service time window starts. However, 39

by using our modified equations (6) and (7), the HWT of OBU “a” turns out to be 165 msec which 40

will enable the OBU “b” to rebroadcast within its “service window”. Similarly HWTs of OBU “c” 41

and “d” will be changed so that they always fall in “service window”. 42


1 2

Figure 4 Hopping timeline depicting the difference between using a full 100 msec timing 3

window and half of 100 msec window as in the case of DSRC where only 50 msec service 4

window is available for transmission. 4 OBUs (a to d) are shown in four sub-rectangles of 5

250 m each. 6

7

SIMULATIONS AND PRELIMINARY FIELD TESTS 8

For evaluation purposes we performed simulations in the lab and conducted preliminary field tests 9

to assess our proposed hopping algorithm. To perform the simulations, we chose the West 10

Arrowhead Road in Duluth, MN where we also performed our preliminary field test as shown in 11

Figure 5. The total road length in consideration is 2.5 km which is defined by two main rectangles 12

of lengths 1 and 1.5 km to represent the hopping route. The width of that specific portion of the 13

road at its widest point is about 21 m. Therefore, we selected the rectangle width to be 14

52 m (2×21+10). 15

The message is hopped from one end (left side in Figure 5) to the other end on this 16

predefined route using our hopping algorithm. To test our hopping algorithm timing, we have 17

purposely selected 11 potential locations on 2.5 km section of the road where hopping nodes or 18

OBUs could be present to conduct the hopping in such a way that at least there is one OBU in each 19

sub-rectangle. Furthermore, we also included one OBU potential location which is outside of the 20

main rectangles or the hopping route to demonstrate that it will not participate in hopping using 21

our algorithm. We obtained the actual longitude and latitude of all these 12 locations from Google 22

Maps and provided these as input to our hopping algorithm to calculate HWT, and to evaluate 23

which OBUs will hop the message. 24

The message is hopped from one end (left side in Figure 5) to the other end using proposed 25

hopping algorithm. To test hopping algorithm timing, we have purposely selected 11 potential 26

locations on 2.5 km section of the road where hopping nodes or OBUs could be present to conduct 27

the hopping in such a way that at least there is one OBU in each sub-rectangle. Furthermore, we 28

also included one OBU potential location which is outside of the main rectangles or the hopping 29

route to demonstrate that it will not participate in hopping using our algorithm. We obtained the 30

actual longitude and latitude of all these 12 locations from Google Maps and provided these as 31

Time (ms)

Dist (m)

Time (ms)

a c db250 m 750 m 500 m

200 ms 400 ms 300 ms

200 ms 400 ms 300 ms

Waiting time for c before hopping Waiting time for d before hopping

150 ms 250 ms 350 ms

Waiting time for c before hopping Waiting time for d before hopping

Full window available

Only service window available

Control window Control window Control window

b hops d hopsc hops

LTL

LTL

DRSC equipped vehicle

OBU’s hopping time using full window

OBU’s hopping time using service window

OBU’s projected hopping time but does not hop

OBU’s projected hopping time but does not hop in service window

100 ms

100 ms

0 m

a does not hop


input to our hopping algorithm to calculate HWT, and to evaluate which OBUs will hop the 1

message. 2

3

FIGURE 5 (a) Section of West Arrowhead Rd showing hopping route defined by two main 4

rectangles, and the location of 12 OBUs used for the simulations to demonstrate hopping 5

algorithm. (b) Section of West Arrowhead Rd used for preliminary road tests. 6

7

For simulation purposes, roadside unit is assumed to be at the far left edge of the first main 8

rectangle and transmits TIM at time 0.00 seconds. Also the direct wireless access range of each 9

OBU and the roadside unit is assumed to be 300 m so that the maximum sub-rectangle length 10

calculated by each OBU will be 250 m. The hopping algorithm code was written in C and run on 11

Savari OBU S103 which runs a Linux based Operating System. At each OBU location, calculated 12

parameters were logged and shown in Table 1. 13

The simulation results in Table 1 show that the OBUs in each sub-rectangle hop TIM in 14

accordance to hopping windows and expected HWT (4th and 5th columns of Table 1). There are 15

two important points to be noted here which are highlighted in the table and discussed below. 16

In 6th sub-rectangle (2nd sub-rectangle of main rectangle 2), there are 2 vehicles (OBUs # 17

6 and 7). Both received TIM messages at almost the same time. After receiving TIM 18

message both vehicles will calculate their respective HWT times. However, HWT of the 19

OBU #7 is smaller than that of OBU #6, therefore, it will hop the TIM first and upon 20

receiving the same TIM again within this hopping window, OBU #6 will stop its hopping 21

process. 22

OBU #8 is outside of both main-rectangles but is still in the wireless access range of its 23

neighboring OBUs on the hopping route. Therefore, it receives a TIM at 954 msec but it 24

will drop the TIM because it fails to determine which main rectangle it falls in. This 25

ensures that our hopping algorithm will confine the propagation of TIM to the vehicles on 26

a predefined hopping route. 27

OBU 6

OBU 7OBU 8

OBU 6

OBU 7

N = 1 N = 2 N = 3 N = 3 N = 4 N = 5N = 4 N = 1 N = 2 N = 6

OBU 1 OBU 2 OBU 3 OBU 4 OBU 5 OBU 9 OBU 10 OBU 12OBU 11

RSU OBU 2 OBU 3OBU 1

PCMS

https://maps.google.com/(a)

(b)


TABLE 1 Simulation Results 1

2

In preliminary field tests we successfully demonstrated hopping of a message across a 1.2 3

km section of West Arrowhead Road. We placed an RSU on one end and a Portable Changeable 4

Message Sign (PCMS) on the other end of this road section with three OBUs between the RSU 5

and the PCMS as shown in Figure 5b. In our preliminary tests, the RSU was programmed to 6

transmit TIM every one second. The three OBUs helped hopped the message to the PCMS which 7

displayed a message when hopped TIM was received successfully and displayed a different 8

message when hopped TIM was not received. We changed the spacing of three OBUs between the 9

RSU and PCMS to evaluate the range of RSU and OBUs for successful hopping. The range of 10

RSU was more than 500m while range of all OBUs was around 250 m. The hopping algorithm 11

worked as desired regardless of the positions of the OBUs as long as the maximum spacing 12

between any two was not more than the DSRC range. 13

14

CONCLUSIONS AND FUTURE WORK: 15

We have developed a hopping algorithm for a work zone traffic information system to deliver in-16

vehicle messages using DSRC based V2V communication. The developed hopping algorithm can 17

disseminate information messages on one or more pre-defined routes consisting of any kind of 18

highways or roads including merge and T-junctions. The proposed algorithm uses vehicles moving 19

in both directions on a particular route for hopping and minimizes the number of hops to carry the 20

message and avoids the broadcast storm at the same time. Our simulation and preliminary field 21

test results show that the proposed algorithm works as intended by successfully avoiding broadcast 22

storm and keeping the information message on the desired hopping route. We are also developing 23

a web based TIM configuration tool for roadside units and an ANDROID based audio-visual 24

interface for OBU to deliver traffic information message contents to the drivers. These components 25

of our full system will be described in a future work after we perform the final field tests to 26

demonstrate our hopping algorithm. 27

OBU

No.

Distance from

roadside unit

(m)

LTL-UTL

(msec)

TIME at

which TIM is

received

(msec)

TIME at which

TIM is supposed

to hop

(msec)

TIM hopped?

(Yes/No)

1 240 150-199 0.0 152 Yes

2 490 250-299 152 251 Yes

3 725 350-399 251 353 Yes

4 990 450-499 353 451 Yes

5 1200 550-599 451 558 Yes

6 1425

650-699

558

664

No (TIM hopped by

OBU #7 at 650 msec)

7 1495 650-699 558 650 Yes

8 Not Applicable Not

Applicable

650 Not Applicable No (OBU is not on

the predefined route)

9 1740 750-799 650 751 Yes

10 2000 850-899 751 850 Yes

11 2255 950-999 850 954 Yes

12 2500 1050-1099 954 1050 Yes


ACKNOWLEDGMENTS: 1

This paper is a result of an ongoing research project led by the partnership of University of 2

Minnesota Duluth and Savari Inc. funded by USDoT SBIR program. The research aims to 3

develop a cost effective mechanism to deploy DSRC based work zone notification systems. We 4

would like to thank the USDOT for this opportunity. 5


REFERENCES 1

1. Lajunen, T., D. Parker, and H. Summala. Does Traffic Congestion Increase Driver 2

Aggression? Transportation Research Part F: Traffic Psychology and Behavior, 3

Vol. 2, No. 4, 1999, pp. 225–236. 4

2. Van Eenennaam, E. M., and G. Heijenk. Providing Over-the-Horizon Awareness 5

to Driver Support Systems. Proc., 4th IEEE Workshop on Vehicle to Vehicle 6

Communications, 2008. 7

3. Fatalities in Motor Vehicle Traffic Crashes by State and Work Zone (2013). 8

https://www.workzonesafety.org/crash_data/workzone_fatalities/2013. Accessed 9

Aug. 1, 2015. 10

4. Gerald L. Ullman, Melisa D. Finley, James E. Bryden, Raghavan Srinivasan, Forrest M. 11

Council. Traffic Safety Evaluation of Nighttime and Daytime Work Zones. NCHRP 12

Report 627. Library of Congress Control Number 2008909444. Transportation Research 13

Board, 2008 14

5. Wegener, A., M. Piórkowski, M. Raya, H. Hellbrück, S. Fischer, and J. P. 15

Hubaux. TraCI: An Interface for Coupling Road Traffic and Network 16

Simulators. Proc., 11th Communications and Networking Simulation Symposium, 17

New York, 2008, pp. 155-163. 18

6. Marfia, G., and M. Roccetti. Vehicular Congestion Modeling and Estimation for 19

Advanced Traveler Information Systems. Proc., International Federation for 20

Information Processing Wireless Days, Venice, Italy, Oct. 20-22, 2010, pp. 1-5. 21

7. Intelligent Transportation Systems - Dedicated Short Range Communications. 22

http://www.its.dot.gov/DSRC/dsrc_faq.htm. Accessed Aug. 1, 2015. 23

8. Suriyapaiboonwattana, K., C. Pornavalai, and G. Chakraborty. An adaptive alert message 24

dissemination protocol for VANET to improve road safety. 2009 IEEE International 25

Conference on Fuzzy Systems, 2009. 26

9. O. Tonguz , N. Wisitpongphan , F. Bai , P. Mudalige and V. Sadeka "Broadcasting in 27

VANET", Proc. IEEE Mobile Network for Vehicular Environments (MOVE) 28

Workshop, 2007 29

10. N. Wisitpongphan O. Tonguz J. Parikh P. Mudalige F. Bai V. Sadekar "Broadcast storm 30

mitigation techniques in vehicular ad hoc networks" Wireless Communications IEEE 14 31

(6) (2007) 84-94. 32

11. W. Zhao , M. Ammar , E. Zegura, A message ferrying approach for data delivery in 33

sparse mobile ad hoc networks. Proceedings of the 5th ACM international symposium on 34

Mobile ad hoc networking and computing, May 24-26, 2004, Roppongi Hills, Tokyo, 35

Japan 36

12. J. Zhao and G. Cao. VADD: Vehicle-Assisted Data Delivery in Vehicular Ad Hoc 37

Networks. IEEE Trans. Vehicular Technology, vol. 57, no. 3, pp. 1910-1922, May 2008. 38

13. K. Suriyapaibonwattana and C. Pomavalai. An Effective Safety Alert Broadcast 39

Algorithm for VANET. In 2008 International Symposium on Communications and 40

Information Technologies, pages 247–250. IEEE, Oct. 2008 41

14. S. Sok-Ian, L. Yinman, "SCB: Store-carry-broadcast scheme for message dissemination 42

in sparse VANET," in Proc. of IEEE 75th Vehicular Technology Conference (VTC 43

Spring), Yokohama, May, 2012, pp. 1-5. 44

15. H. F¿¿ssler, J. Widmer, M. K¿¿semann and M. Mauve "Contention-based forwarding for 45

mobile ad-hoc networks", Ad Hoc Netw., vol. 1, no. 4, pp.351 -369 2003 46

https://www.workzonesafety.org/crash_data/workzone_

http://www.its.dot.gov/DSRC/dsrc_faq.htm


16. Buddhika Maitipe, U. Ibrahim, M. Hayee, Eil Kwon. Vehicle-to-Infrastructure and 1

Vehicle-to-Vehicle Information System in Work Zones. In Transportation Research 2

Record: Journal of the Transportation Research Board Dec 2012, Vol. 2324, pp. 125-3

132 4

17. U. Ibrahim, M. Hayee, Eil Kwon. Hybrid Work Zone Information System with 5

Portable Changeable Message Signs and Dedicated Short-Range Communication. 6

In Transportation Research Record: Journal of the Transportation Research 7

Board Dec 2013, Vol. 2380, pp. 29-35 8

18. L. M. M. M. Bani-Yassein, M. Ould-Khaoua, and S. Papanastasiou, “Performance 9

analysis of adjusted probabilistic broadcasting in mobile ad hoc networks,” In 10

International Journal of Wireless Information Networks, pp. 127-140, 2006. 11

19. D. Karsky, “Comparing Four Methods of Correcting GPS Data: DGPS, WAAS, L-Band, 12

and Post-processing”, Tech Tip 0471-2307-MTDC, Missoula, MT: U.S. Department of 13

Agriculture, Forest Service, Missoula Technology and Development Center, July 2004. 14

20. Li, Q., and T. Shih. Ubiquitous multimedia computing. CRC Press, Boca Raton, 2010. 15

21. Q. Chen , D. Jiang and L. Delgrossi "IEEE 16094 DSRC Multi-Channel Operations and 16

Its Implications on Vehicle Safety Communications", Proc. IEEE Vehicular Networking 17

Conf., pp.1 -8 2009 18

19

traffic information system to deliver in-vehicle messages on pre-defined routes using dsrc based v2v...

Documents