Improving transportation safety for sustainable environments using vehicular networking technology

GEORGIA DOT RESEARCH PROJECT 13-02 Final Report
IMPROVING TRANSPORTATION SAFETY FOR SUSTAINABLE ENVIRONMENTS USING VEHICULAR
NETWORKING TECHNOLOGY
Office of Performance-based Management and Research 600 West Peachtree St. NW | Atlanta, GA 30308

1.Report No.: FHWA-GA-17-1302

2. Government Accession 3. Recipient's Catalog No.:

No.: N/A

N/A

4. Title and Subtitle: Improving Transportation Safety for Sustainable Environments Using Vehicular Networking Technology

5. Report Date: September 2016
6. Performing Organization Code: N/A

7. Author(s): Yusun Chang, Ph.D.; John A. Copeland, Ph.D.

8. Performing Organ. Report No.: 13-02

9. Performing Organization Name and Address:

10. Work Unit No.:

Kennesaw State University

Southern Polytechnic College of Engineering and Engineering Technology

11. Contract or Grant No.: PI# 0012666

1100 S. Marietta Parkway, Marietta, GA. 30060

12. Sponsoring Agency Name and Address:

13. Type of Report and Period Covered:

Georgia Department of Transportation

Final; March 2013 September 2016

Office of Performance-based Management and

Research 600 West Peachtree St. NW Atlanta, GA, 30308

14. Sponsoring Agency Code: N/A

15. Supplementary Notes:

16. Abstract:

In this modern era, improving transportation safety became one of the most critical problems as the human,

societal, environmental and economic losses from traffic accidents continue to grow rapidly in the recent years.

A key initiative toward improving transportation safety is the introduction of Intelligent Transport System

(ITS) whereby vital applications to spread safety messages on the road in real-time are being investigated to

ensure road safety. This research provides novel and feasible solutions to disseminate these safety messages

through connected Vehicle-to-Vehicle (V2V) and Vehicle-to-Infrastructure (V2I) communications to improve

the transportation safety. It also exploits the physical layer characteristics of the V2V safety messages in

providing collision avoidance services through accurate detection of vehicles, pedestrians and other threats. In

this research, novel algorithms and protocols enabling efficient and reliable communication between vehicles

have been developed, tested and verified through real-world experiments in Georgia. The research findings

and results presented in this report confirm the effectiveness of the proposed schemes in improving

transportation safety, and reinforce the importance of the deployment of connected vehicle technologies for

V2V and V2I communication in the state of Georgia.

17. Key Words:

18. Distribution Statement: No

Vehicular Networks, Intelligent Transportation System, Connected Vehicle, Restriction

Safety Message, Communication, Routing, Multi-Hop Broadcasting,

Wireless, Transportation Safety, V2V, V2X, Road Side Unit, On-board

Unit

19. Security Classification (of this report): 20. Security classification (of 21. Number 22. Price:

Unclassified

this page): Unclassified

of Pages: 143 Free

GDOT Research Project No. 13-02 Final Report
IMPROVING TRANSPORTATION SAFETY FOR SUSTAINABLE ENVIRONMENTS USING VEHICULAR
NETWORKING TECHNOLOGY
Submitted by
Yusun Chang, Ph.D. Associate Professor Kennesaw State University Electrical Engineering Southern Polytechnic College of Engineering and Engineering Technology 1100 S. Marietta Parkway, Marietta, GA. 30060 Phone: (678) 915-7836, Email: yusun@kennesaw.edu
John. A. Copeland, Ph.D. Professor
Georgia Institute of Technology School of Electrical & Computer Engineering Phone: (404) 894-5177, Email: jcopeland@ece.gatech.edu
Contract with Georgia Department of Transportation
In cooperation with U.S. Department of Transportation Federal Highway Administration
September 2016 The contents of this report reflect the views of the authors who are responsible for the facts and the accuracy of the data presented herein. The contents do not necessarily reflect the official views or policies of the Georgia Department of Transportation or the Federal Highway Administration. This report does not constitute a standard, specification, or regulation

ACKNOWLEDGMENT The author would like to thank the Georgia Department of Transportation (GDOT) for its generous support. The work conducted in this report was sponsored by GDOT (Research Project 13-02). The author would like to acknowledge the Connected Vehicle Research Group for their invaluable input and support during this work.
i

EXECUTIVE SUMMARY Over the past few years, the occurrence of enormous human, societal, environmental and economic losses due to traffic accidents has led to a search for highly innovative and practical solutions to improve safety on the roads. One such initiative is the introduction of Intelligent Transport System (ITS) area whereby a vital application is to ensure road safety by fast and reliable dissemination of safety/emergency messages. This research provides feasible solutions to disseminate these safety messages through connected Vehicle-to-Vehicle (V2V) and Vehicle-to-Infrastructure (V2I) communications to improve transportation safety. Through this research, a reliable platform/testbed has been developed. Novel algorithms have been designed, simulated, implemented and tested on Georgia highways as well as local roadways to verify the feasibility of the proposed methods. The research findings and results not only confirm the effectiveness of the proposed scheme in improving transportation safety but also reiterate the importance of the deployment of connected vehicle technologies for V2V and V2I communication in the state of Georgia. In addition, the proposed system also facilitates an efficient propagation and delivery of traffic-related information to the concerned authorities for real-time monitoring as well as for statistical analysis. Furthermore, many ITS applications for collision warning and avoidance can be also be readily incorporated into this system. As a result, this research provides a platform to dramatically reduce human causalities as well as lower the social, environmental and economical expenses.
ii

TABLE OF CONTENTS ACKNOWLEDGEMENT ................................................................................................... i EXECUTIVE SUMMARY ................................................................................................ ii TABLE OF CONTENTS................................................................................................... iii LIST OF FIGURES .............................................................................................................v LIST OF TABLES ........................................................................................................... viii 1. INTRODUCTION .........................................................................................................1 2. LITERATURE REVIEW ..............................................................................................5
2.1. BACKGROUND ....................................................................................................5 2.2. PROBLEM..............................................................................................................8 2.3. RELATED WORKS .............................................................................................11 3. PROTOCOL DESCRIPTION .....................................................................................22 3.1. MOTIVATION & CONTRIBUTION ..................................................................22 3.2. PROTOCOL DESIGN..........................................................................................23 3.3. SUMMARY OF THE PROPOSED PROTOCOL DESIGN................................29 3.4. COMPARISON OF PROPOSED PROTOCOL WITH A TRADITIONAL
MULTI-HOP ALGORITHM SB .........................................................................32 4. THEORETICAL ANALYSIS .....................................................................................35
4.1. THEORETICAL MODEL....................................................................................35 4.2. RESULTS & ANALYSIS ....................................................................................41 5. SIMULATION.............................................................................................................52 6. EXPERIMENTATION................................................................................................58 6.1. EQUIPMENT & TEST-BED IMPLEMENTATION...........................................58
iii

6.2. PROGRAMMING GUIDE...................................................................................59 6.3. FIELD TESTS IN STATIC AND DYNAMIC ENVIRONMENTS ....................66 6.4. FIELD TEST RESULTS ......................................................................................68 7. DEMO..........................................................................................................................82 8. RECOMMENDATIONS .............................................................................................86 8.1.ANTENNA PLACEMENT ...................................................................................86 8.2.ROADSIDE UNIT PLACEMENT........................................................................87 8.3.MANUFACTURER ..............................................................................................88 8.4.DEPLOYMENT REQUIREMENTS.....................................................................89 8.5.DATA COLLECTION ..........................................................................................91 8.6.COST .....................................................................................................................93 9. COLLISION AVOIDANCE........................................................................................95 9.1.INTRODUCTION .................................................................................................95 9.2.DOPPLER DOMAIN ANALYSIS FOR COLLISION AVOIDANCE ................96 9.3.RECEIVED SIGNAL STRENGTH BASED ON COLLISION AVOIDANCE 101 9.4.REDUCING FALSE ALARMS USING DOA ...................................................105 10. CONCLUSION..........................................................................................................109 REFERENCES ................................................................................................................110 APPENDICES .................................................................................................................114
APPENDIX A: SAMPLE LOG DATA FROM AN OBU DURING A MULTIHOP FIELD EXPERIMENTATION ..............................................................................114
APPENDIX B: AUTHOR'S RELATED PUBLICATIONS & POSTERS .......125
iv

LIST OF FIGURES
Figure 1 (A) V2V Communication, (B) V2I Communication........................................6 Figure 2 OFDM Sub-carrier Structure and IEEE 802.11p Frame ..................................7 Figure 3 (A) Multi-hop V2P Communication, (B) Multi-hop V2V & V2I
Communication ................................................................................................9 Figure 4 ESD Bitmap Construction ..............................................................................14 Figure 5 (A) Normal Rebroadcast Scenario, (B) ACK Decoupling and Recovery
Process. ...........................................................................................................24 Figure 6 ACK Decoupling and Recovery Mechanism .................................................27 Figure 7 Collision Resolution Mechanism (Not drawn to scale)..................................28 Figure 8 Flow Chart Describing Key Design Steps at Each i-th Node.........................31 Figure 9 Timing Diagram Normal Rebroadcast Scenario (Proposed Protocol vs. SB)
........................................................................................................................33 Figure 10 Timing Diagram Collision Scenario (Proposed Protocol vs. SB) ...............34 Figure 11 Highway Scenario ..........................................................................................36 Figure 12 Average Per-Hop Rebroadcast Latency (Theoretical vs. Simulation Results)
........................................................................................................................42 Figure 13 Average Distance Progressed Per-Hop (Theoretical vs. Simulation) ............44 Figure 14 Average Message Dissemination Speed (Theoretical vs. Simulation Results)
........................................................................................................................45 Figure 15 Effect of Changing Parameters on Per-Hop Delay ........................................47 Figure 16 Effect of Changing CWmax Range on Per-Hop Delay ...................................48 Figure 17 Effect of CWmax on Average Dissemination Speed .....................................50
v

Figure 18 Effect of CWbase on Average Per-Hop Delay................................................53 Figure 19 Comparison of Per-Hop Delay (Proposed Protocol vs. SB) ..........................55 Figure 20 Comparison of Max Throughput (Proposed Protocol vs. SB) .......................56 Figure 21 Snapshot of an Application being Developed in Eclipse IDE........................59 Figure 22 Eclipse Settings for Integrating Locomate in Eclipse Environment ..............60 Figure 23 List of Options for Parameter Setting in Multi-Hop EMD Application.........63 Figure 24 List of Options to Enable Different Printouts ................................................64 Figure 25 Snapshot of a Particular Transmitted Packet..................................................64 Figure 26 Snapshot of a Particular Received Packet ......................................................65 Figure 27 Single Hop: RSS vs. Distance ........................................................................69 Figure 28 Indoor Experimentation: SNR vs. Distance ...................................................70 Figure 29 Indoor Experimentation: CWmax vs Distance...............................................71 Figure 30 Indoor Experimentation: Per-hop Delay vs. Distance....................................72 Figure 31 Outdoor Static Experimentation: CWmax vs. Distance....................................74 Figure 32 Outdoor Static Experimentation: CWchosen vs. Distance.................................74 Figure 33 Outdoor Static Experimentation: Average Delay vs. Distance ......................75 Figure 34 Outdoor Multi-Hop Experimentation Topology ............................................76 Figure 35 Outdoor Multi-Hop Experimentation: Average CWmax vs. Distance.............77 Figure 36 Per-Hop Delay for Outdoor Multi-Hop Experimentation ..............................78 Figure 37 End-to-End Delay for Outdoor Multi-Hop Experimentation. ........................79 Figure 38 Distance Progressed by Various Safety Messages .........................................80 Figure 39 MYSQL Database Containing Safety Messages Related Data ......................83 Figure 40 Live Map showing Multiple Emergency Events ............................................84
vi

Figure 41 Single Emergency Event ................................................................................84 Figure 42 Attenuation due to Windshield Blockage.......................................................87 Figure 43 BSM Radar Map Development Simulation....................................................92 Figure 44 Tracking Doppler Shift for Several Scenarios ...............................................98 Figure 45 Estimating Collision Likelihood from: A) Initial Detection Far-Away and B)
At End of Decision Timer Duration ...............................................................99 Figure 46 System Performance Under Multiple-Combinations ...................................101 Figure 47 RSSI Trend between Two Cars for: Collision (Dashed, X's) and No-
Collision (Solid, Circles) Outcomes in Three Pre-Crash Scenarios.............103 Figure 48 RSSI trends as recorded by Car A among multiple nodes for Rear End pre-
crash scenario. If DOA is available, then RSSI values from Car C could be localized to the opposite lane to suppress a false-alarm and reduce prediction complexity among multiple nodes ...............................................................106 Figure 49 RSSI Collision Prediction System................................................................107 Figure 50 Performance Outcome for: A) LOS Rear End, and B) NLOS Straight Crossing Path (Intersection). ........................................................................108
vii

LIST OF TABLES Table 1 BSM Data Fields ..............................................................................................8 Table 2 Simulation Parameters....................................................................................41 Table 3 Di vs. SNRi (GLIMPSE FROM THE DATA-SET) .......................................46 Table 4 Simulation Parameters....................................................................................52 Table 5 Data Gathered through the Reception of Safety Messages. ...........................73
viii

1. Introduction According to US Department of Transportation (USDOT) statistics, the year 2011 alone recorded 5.3 million vehicular crashes resulting in 3.7 million property damage incidents, 2.2 million injuries, and 32,367 tragic fatalities [12] on top of an already massive $200 billion in societal damage annually [13]. This ever-increasing trend in societal, environmental and economic damages due to the enormous number of traffic accidents has resulted in the initiation of joint efforts by government, industry and academia to ensure road safety by exploiting innovative technologies. One such initiative is the introduction of Intelligent Transport System (ITS) [1], whereby one of the vital applications is to ensure road safety through efficient exchange of safety messages between the vehicles on the roads [2]. The Dedicated Short-Range Communications (DSRC) standards, developed for Vehicle-to-Vehicle (V2V), Vehicle-to-Infrastructure (V2I) and Vehicle-to-Pedestrian (V2P) communication, specify a dedicated channel for these time-sensitive safety messages [3]. This research project proposed a novel protocol that ensures fast and reliable dissemination of safety/emergency messages to the vehicles, infrastructure and pedestrians along the road. Such an exchange of messages will assist in preventing a significant proportion of crashes on the roadway, thereby reducing fatalities and injuries that occur each year.
Most existing research works exploit single-hop V2V or V2I communication. This kind of communication is easily established and provides many critical safety-related applications such as rear-end collision avoidance, head-on collision avoidance, and so on. However, several other applications require safety messages to be propagated well beyond the immediate transmission range to alert vehicles of hazardous driving situations. This
1

communication is known as multi-hop vehicular communication. Through multi-hop vehicular communication, the vehicles further beyond the transmission range of the message-originating vehicle can be alerted well ahead of time about any potential collision or any other dangerous and unsafe conditions on the road. This proactive approach can help prevent a significant number of accidents. Fast and reliable multi-hop vehicular communication can also propagate traffic information to an infrastructure, which will then deliver the information to a central transportation management center for transportation analysis, operation and management.
However, disseminating safety messages efficiently to all the vehicles on the road using multi-hop communication is a challenging problem. Since no central administrator exists, propagation of messages through multi-hop becomes highly complex as multi-hop increases the chances of a message collision. This problem becomes severe in dense urban areas where a higher traffic volume results in excessive communication failures. These failures deteriorate the reliability of reception and overall message dissemination speed. It is therefore critical to develop innovative ideas for message routing in vehicular networks.
The major objectives of this research are to design, analyze, implement and test a safety/emergency message dissemination system using multi-hop vehicular communications for transportation and pedestrian safety. Some key features of this research include:
Creating a reliable platform/test-bed to develop and experiment innovated networking technologies for V2V, V2I and V2P.
Supporting ITS applications for collision warning and avoidance, traffic information propagation through vehicular communications. 2

Performing statistical analysis of real-world data to optimize transportation traffic flows.
Researching the impact and benefit of using new ITS technologies in sustainable environments to reduce air pollution and fuel consumption.
The benefits achieved through the successful completion of this research work are multifold. Firstly, the novel ideas established through this research have opened a new paradigm in transportation safety as human casualties, environmental and social expenses resulting from car accidents can be dramatically reduced. Secondly, by using state-of-the-art ITS technologies, the performance and management of transportation systems will be significantly improved. This research has also resulted in the successful development of a reliable test-bed at Georgia Institute of Technology and Kennesaw State University to aid in the implementation and experimentation of innovative V2V technologies and applications. The authors strongly believe that the research findings from this project will also contribute toward maintaining sustainable environments by reducing congestion and air pollution. Some of the key contributions of the research work are as follows:
1. A novel multi-hop algorithm to successfully disseminate the safety/emergency messages to vehicles, pedestrians and infrastructure
2. A state-of-the-art V2V multi-hop test-bed 3. Statistics and optimizations related to the safety/emergency message propagation
process. 4. Recommendations for implementing V2V technology on Georgia highways.
3

The rest of the report is organized as follows: In Chapter 2, the background and related works are presented while Chapter 3 offers the protocol description. Chapter 4 presents the theoretical analysis and optimizations for the protocol, whereas simulation results are discussed in Chapter 5. Chapter 6, on the other hand, talks about the experimental setup, test-bed and results. In Chapter 7, a brief demo of the proposed protocol is shown. Chapter 8 offers some recommendations for implementing DSRC devices. In Chapter 9, a collisionavoidance scheme is described. Finally, the conclusion is presented toward the end.
4

2. Literature Review As Dedicated Short-Range Communications (DSRC) standards become finalized, countries around the world are preparing to embrace the introduction of Intelligent Transportation System (ITS) protocols--collectively known as Vehicle-to-Everything (V2X)--to improve safety on the roads. In the United States, a combined effort from top American car manufacturers, the U.S. Department of Transportation (USDOT), state departments of transportation, and academia are working together toward effective integration of V2X protocols into the society. In fact, leading automobile manufacturing companies have already started producing vehicles equipped with DSRC devices to provide connectivity with other vehicles and infrastructure. 2.1. Background All of the vehicles equipped with DSRC radios together would be able to form a Vehicular Ad-hoc Network (VANET). VANET--a specific type of mobile ad-hoc network (MANET)--is a group of vehicular nodes that spontaneously form a wireless network using 802.11p protocol for data exchange while moving on the road. Such networks have tremendous potential in enabling diverse applications related to traffic safety, traffic efficiency, and infotainment [25, 26 and 27].
In VANETs, communication can take place between the vehicular nodes as vehicleto-vehicle (V2V) communication or between vehicles and infrastructure as vehicle-toinfrastructure (V2I) communication. An illustration of V2V and V2I communication is presented in Figure 1.
5

FIGURE 1 (A) V2V Communication, (B) V2I Communication
To improve the transportation safety, VANETs utilize the licensed ITS band of 5.9 GHz (5.85-5.925 GHz) to exchange data between high-speed vehicles and between the vehicles and the roadside infrastructure. While safety is the main objective of this 75 MHz freely available bandwidth, it also supports various other types of traffic and applications. Since this bandwidth is related to transportation safety, several standards specify the rules and regulations. Specifically, IEEE 802.11p and IEEE 1609 define rules of operation.
The IEEE 802.11p standard deals with the low-layer operations, such as medium access control (MAC) and physical (PHY) layers, while the IEEE 1609 standard regulates the operation of upper layers, such as network, security, and application layers. IEEE 802.11p is an enhancement of the generic IEEE 802.11 standard with an emphasis on providing special support for the communication between high-speed moving vehicles and road-side infrastructures.
The IEEE 1609 standards involve the following four components: IEEE 1609.1 for resource management, IEEE 1609.2 for security, IEEE 1609.3 for network and transport area services, and IEEE 1609.4 for multi-channel operation. The frequency spectrum consists of seven different channels where each channel has 10 MHz bandwidth. A channel
6

specifically dedicated solely for safety purposes is known as a Control Channel (CCH). Six remaining channels, called Service Channels (SCH), are used for both safety and other applications, such as for infotainment and entertainment purposes. All V2X-enabled vehicles tune in to the CCH for 50 ms and then tune in to an SCH of choice for 50 ms. The cycle is continuously repeated.
The packets transmitted in V2X communication utilize Orthogonal Frequency Division Multiplexing (OFDM) that employs 48 sub-carriers to carry binary data through various modulation schemes. The IEEE 802.11p also outlines this OFDM frame structure with training symbols and guard intervals to precisely tune the received radio signal into the receiver of the V2X devices, as shown in Figure 2.
The CCH is primarily used for the periodic exchange of a basic safety message (BSM) containing real-time information about the transmitting vehicle's speed, steering wheel angle, Global Positioning Coordinates (GPS) and so on [4]. Table 1 describes the structure of a BSM, which generally ranges in size from 100 bytes to 800 bytes. The BSMs are exchanged at a frequency of 10 Hz, i.e. 10 messages/sec/node.
FIGURE 2 OFDM Sub-carrier Structure and IEEE 802.11p Frame
7

TABLE 1

BSM Data Fields

BSM Data Item

Type Bytes Part

Message ID

E

1

I

Message Count

E

1

I

Temporary ID

E

4

I

Time

E

2

I

Latitude

E

4

I

Longitude

E

4

I

Elevation

E

2

I

Positioning Accuracy

F

4

I

Transmission & Speed

F

2

I

Heading

E

2

I

Steering Wheel Angle

E

1

I

Accelerations

F

7

I

Brake System Status

F

2

I

Vehicle Size

F

3

I

Event Flags (opt)

E

2

II

Path History (opt)

F

Var. II

Path Prediction (opt)

F

3

II

RTCM Package (opt)

F

Var. II

Total Bytes

44

Vehicles exchange BSMs to warn each other of an impending collision or a hazardous

situation, and for preemptive safety measures. The operation of BSM exchange among

vehicles is defined in the following standards: IEEE 1609 [5] and IEEE 802.11p [6].

Furthermore, the CCH is also used for WAVE Service Announcements (WSA) to

announce the available services on the various SCH.

2.2. Problem

In VANETS, a lot of safety applications rely on sharing safety/emergency messages. This

process of exchanging such messages is often referred to as Emergency Message

Dissemination (EMD). Since the successful transmission of a safety message is often

directed for all nodes in the target region well beyond the one-hop communication range

8

of the source node, multi-hop communication is imminent. Figure 3 illustrates such critical multi-hop applications where safety messages are propagated along the road.
FIGURE 3 (A) Multi-hop V2P Communication, (B) Multi-hop V2V & V2I Communication
Among many interesting applications in transportation safety, EMD is especially essential when a driver in an emergency vehicle would want to warn all drivers in front of it so that a clear roadway is secured. Sometimes, the driver of a leading vehicle observing an obstacle or pedestrian in the middle of the road would want to transmit a notification message backward to warn the drivers of upcoming dangers. To better assist these critical applications of multi-hop safety message exchange, a DSRC Basic Safety Message (BSM) [1] is generally utilized to share traffic information such as the direction the vehicle is headed, its speed, the lane of traffic it is in, its GPS coordinates, a Time/Date stamp, the Original Sender ID, and the Retransmitted ID.
The DSRC standards have described a dedicated channel for the exchange of these time-sensitive safety messages [1]. For instance, an ambulance approaching a congested roadway needs to be able to notify the vehicles on the road of its location quickly so they can make space for the emergency vehicle. Currently, the US DOT has reviewed
9

Emergency Vehicle Preemption technologies deployed in several states that allow traffic lights to be adjusted to smooth the flow of traffic for ambulances to maneuver through RITA [2]. However, the concept of emergency vehicles being able to notify other vehicles will be more feasible once the DSRC radios are installed on the vehicles on a massive scale and all the required standards become finalized.
Considering the highly dynamic topology that VANETs could encounter, the common data transmission based on table routing and acknowledgments is highly inefficient and exhibits low throughput. Under normal networking connections, it would take a significant amount of time just to establish a stable connection among vehicles, build routing tables, and finish transmitting packets to their desired destinations. This entire process is highly infeasible for time critical safety message. While some non-emergency applications using DSRC radios may find this type of routing adequate, emergency message dissemination through Ad-hoc V2V connections in VANETs requires a more reactive packet delivery mechanism.
Hence, this problem of efficient routing and dissemination of safety/emergency messages in a VANET is indeed very challenging, and this research aims to address these challenges. To put it simply, the general way in which the emergency message can be propagated in the VANET is that the emergency message initiator broadcasts the message to everyone within its transmission range. Following this, one or more nodes within the transmission range are selected as forwarders, and they rebroadcast the safety message. This process is repeated until the safety message is disseminated in the entire VANET topology.
10

2.3. Related Works There are several protocols that have been researched and developed to ensure fast and reliable dissemination of safety messages in a VANET environment. In this section, we present a discussion of some of the key protocols in the literature. A. Urban Multi-Hop Broadcasting (UMB) One of the original broadcasting schemes that were developed for VANETS is called Urban Multi-Hop Broadcasting (UMB)[5]. It is based on a sectional division of the road dependent on the distance from the original sender. The original sender will send out a Request to Broadcast (RTB) message. Each node within range will then self-calculate what section the node is in and begin sending out a jamming signal. A jamming signal for UMB is a continuous transmission with the furthest node having the longest jamming signal. In other words, the jamming signal is shorter as the nodes get closer to the original sender. If the closer nodes stop transmitting a jamming signal and the sender continues to overhear a jamming signal, then they will know that another node exists farther than the closer nodes. When the farthest node stops transmission of the jamming signal, it will send a Clear to Broadcast (CTB) packet to the original sender. This CTB packet will alert the original sender that it is ready to receive the data packet to be forwarded. Afterward, an acknowledgment (ACK) will be transmitted to end the process. UMB further discusses the separation of sections if two nodes collide on the CTB. This allows the sections to be shorter and therefore reduces the risk that two nodes are colliding when forwarding the message.
UMB inherently contains several pitfalls that need to be addressed and corrected. 11

The first pitfall is that the jamming signal prevents any other nodes within range to continue normal data exchange between each other as the channel will be flooded. Secondly, in a high traffic zone, the further separation of nodes may prove to be useless if two vehicles are side by side. This would mean that both vehicles are always going to be in the same section. Lastly, there are several other minute issues, such as the transmission delay and throughput that would be degraded due to the nature of the protocol. Hence, another protocol that was developed to try and correct some of these issues is called Smart Broadcast.

B. Smart Broadcast (SB)

Smart Broadcast (SB)[2] is an enhancement of UMB with a similar sectional divide. The main difference between UMB and SB is that SB assigns contention windows time slots based on which "sector" each node is in, as opposed to the UMB's jamming signal. SB is designed to use a random backoff timer based on the maximum contention window time slots available for each sector. The nodes calculate a set to choose a random waiting time by using equation (2.1) to calculate the maximum amount of slots. Cw is the duration of each contention window, and r is the sector that each node is located in. It is important to note that r = 1 represents the outermost sector.

= {( - 1), ( - 1)+1, ... , - 1 }[2]

(2.1)

Additionally, SB has improved on the dynamics of the sectors by using additional sectors if traffic density is high. It is done with the periodic usage of heartbeat messages to gather information about traffic density; however, the main functionality of SB is similar to that of UMB. The sender uses an RTB message and will wait for a CTB message, at
12

which point it will send out the data message to be forwarded. In the case of a CTB collision, the process begins again, and the sectors are further divided. SB also requires the transmission of an overheard message, ACK. A few noticeable downsides to SB is that it continues to use CTB/RTB messages, similar to UMB. Additionally, if two vehicles are in the same sector, their maximum set is identical. SB adds a random choice to reduce the possibility of collision; however, this is done from the same maximum set. C. SNR based Linear Back-Off Protocol One of the first pieces of literature to include SNR-based forwarder selection is called "A Simple SNR Based Linear Back-Off to Propagate Multi-hop Emergency Messages on the Distributed VANETs."[9] The paper describes a timer backoff forwarder selection based on the SNR levels. From the literature, it is assumed, though not directly specified, that if the SNR level is lower, then it gets a lower backoff time and will forward the message first. Additionally, the paper discusses the removal of CTB/RTB packets. Furthermore, it also mentions that additional nodes waiting to rebroadcast would cancel the rebroadcast if the rebroadcast message is overheard. However, the paper does not give any indication of how a forwarder is selected or how long the backoff times would be for any of the nodes. Some inherent problems that were not covered are that SNR does not necessarily signify the furthest distance. Sometimes, a node reception can be blocked due to a larger vehicle being positioned between it and the sender. This would cause the SNR to drop significantly. This research does not discuss the possibility of collisions and how to resolve them, but it does provide insight into using a different standard beyond GPS. This is an important aspect when considering that a vehicle may encounter areas where GPS is not reachable, such as tunnels.
13

D. ROFF: RObust and Fast Forwarding in Vehicular Ad-Hoc Networks One unique and more recent publication called "Robust and Fast Forwarding in Vehicular Ad-Hoc Networks" (ROFF)[16] discusses the usage of Empty Space Distribution (ESD) bitmapping to reduce the wasted wait time caused by empty spaces between one node and another contending to be a forwarder. The construction of the bitmap is based on continuous knowledge of the neighboring nodes inserted in a "neighbor table," called NBT[6]. NBT provides continuous monitoring of a node's local view to the other nodes. The NBT allows nodes to be set as Potential Forwarder Candidates (PFC)[6]. In ROFF, PFCs are advertised as an ESD bitmap.
FIGURE 4 ESD Bitmap Construction. The ESD bitmap construction process is illustrated in Figure 4[6]. The first phase considers distance in meters from the forwarding node (fwd), whereas the second phase is
14

an actual bitmap divided into sectors with a bit set to 1 if the node is a PFC. The waiting

time is found by using equation (2.2). To avoid transmission collisions caused by the short

waiting time difference, minDiff is used, which denotes the minimum difference between

the waiting times of two neighboring vehicles.


() = (),(-1)( 2)
=2

(2.2)

ROFF is designed to reduce the waiting time wasted by vehicles that share no

information with each other. One assumption ROFF uses is that the continuous reception

of beacon messages can be used to build an ESD bitmap. Unfortunately, this does not

always happen, and if additional beacon messages are sent, network traffic congestion may

increase.

E. OppCast: Opportunistic Broadcast of Warning Messages in VANETs

OppCast[7] is a double-phased broadcasting protocol that attempts to resolve two main dilemmas. First, the fast forward dissemination is based on selecting the furthest forwarder in the "boundary range" (BR). This would allow further dissemination of the message. The literature does not cover the exact syntax as to how a forwarder is selected between other nodes next to it or how the actual message is transmitted.
The second phase, named "makeup-for-reliability," is based on a binary tree methodology of selecting other nodes within the one-hop range to provide the message to the nodes, which may have missed the opportunity to receive the message during forwarding. This is performed in parallel to the message transmission and, therefore, does not affect the message propagation speed. The main focus of performing the makeup-for-

15

reliability phase is to improve the packet reception rate (PRR). This means that all nodes would be able to receive all messages. A few limitations to this would be the fact that the forwarder selection is seemingly distance-based, and the parallel makeup-for-reliability phase may cause unnecessary network traffic, causing possible collisions. However, it does provide a good approach to removing the hidden node terminal problem in VANETs. F. Instant Broadcast (IB)

To compare the difference between handshaking protocols and non-handshaking protocols, the paper entitled "Handshaking vs. Instant Broadcast in VANET Safety Message Routing"[4] provides calculations and simulations of a modified version of Smart Broadcast that uses no handshaking mechanisms, such as RTC or CTB. Instant Broadcast uses a similar sectional divide of the road where vehicles pertaining to different sectors are given a different maximum slot time to choose from. The outermost sectors will provide the smallest amount of items in a set. This provides a higher probability of randomly choosing a smaller waiting period for rebroadcasting.

Instant broadcast uses equation (2.3) to calculate the delay used in comparing the

simulated results of UMB, SB, and IB. Where is the mean number of retransmission

attempts. is defined by equation (2.4). Let Ps be the probability of successfully

transmitting a message and Ptr be the probability that transmission occurs between

nodes[4].

[] = []

(2.3)

16

-1
= (1 - )
=0

(2.4)

The simulation was performed in Network Simulator, and the paper demonstrates a

significant improvement by simply removing the handshaking mechanism. This paper

demonstrates an improvement, but it is limited to distance-based forwarder selection.

Furthermore, it does not cover the possibility that the original sender may not overhear the

rebroadcasted message.

G. Routing in Sparse Vehicular Ad-Hoc Wireless Networks

To encourage research in the VANET community, literature such as "Routing in Sparse Vehicular Ad Hoc Wireless Networks"[17] was published to study past routing protocols using empirical traffic data collected on I-80 in California. The main focus of the publication is to calculate the time it would take to propagate a message to disconnected nodes called "re-healing time"[17]. Disconnected nodes are defined as nodes that are not within range due to the scarcity of traffic.
The average re-healing time is several seconds to a few minutes. This is an important discovery because new protocols would have to keep in mind a certain time to maintain data for forwarding. Other protocols may be able to use a multi-hop protocol to more quickly penetrate the environment, reducing the re-healing time. Unfortunately, without prior knowledge of nodes that are disconnected, there may be no other way but to define a certain time to keep data and retransmit when a disconnected node is detected.

H. Efficient Directional Broadcast

17

Efficient Directional Broadcast (EDB)[18] is an additional protocol that uses a distance-

based broadcasting scheme, and it was published in the article, "A Distance-based

Directional Broadcast Protocol for Urban Vehicular Ad Hoc Networks"[18]. It uses

equation (2.5) to determine the waiting period.

= (1 - )

(2.5)

It is a linear based equation that divides the node distance by the maximum distance. D is

the max range, whereas d is the node distance from the sender. This is multiplied by the

maximum waiting period allowable to determine how long each node will take to

rebroadcast.

The paper further describes the transmission of an ACK as a confirmation that a

node will further the message. This is done to remove any other nodes in a range from

contending to forward the message. Once this is done, the message will be forwarded, and

the process will be repeated. Additionally, this process removed the need for handshaking

by removing the need for RTB/CTB. Overall, the protocol improves on SB by removing

the concept of sectors, but it does not allow room for mistakes in experimentation if the

device range is not ideal. Furthermore, the additional ACK transmission reduces

performance a little, but it increases reliability by reducing possible collisions; however,

this does not mean ACK collisions are avoidable.

I. Weighted p-Persistence In addition to distance-based forwarder selection, the literature discusses the use of probability-based algorithms to have forwarders selected based on the probability they are

18

the most ideal. One of the most direct ways of doing this is by using the distance between

a node and the transmitter. Weighted p-Persistence[19] does this using a very similar

formula of distance divided by the total range. Based on this probability, the vehicles at the

outermost distance will have a higher probability of being picked. The formula Weighted

p-Persistence uses is equation (2.6), where D is the distance between node i and j, and R is

the range.



=



(2.6)

This is one method for forwarding a message, and it shows that several distance-based

protocols are similar in that the ratio of distance over the maximum range is used. Again,

some limitations are that the range may change in live experimentation, and the potential

for collision is increased as road traffic increases.

J. Optimized Adaptive Probabilistic Broadcast (OAPB)

Several other probability-based algorithms have been developed. An improved protocol of

Weighted p-Persistence is called Optimized Adaptive Probabilistic Broadcast (OAPB)[20].

The aim of OAPB is to provide a more in-depth forwarding probability based on the

surrounding node density. Based on equation (2.7), the protocol will use "HELLO"

packets, or regular packets, to calculate the forwarding probability.



=

0

+

1 3

+

2

(2.7)

P0, P1, P2 represent one-hop, two-hop, and a combination of two-hop neighboring nodes

through a one-hop neighbor. To further enhance and correct situations where vehicles have

the same probability to be forwarders, the protocol provides a delay, which is calculated

19

with equation (2.8). (t) is the maximum wait time, and is a randomly generated variable

in the order of milliseconds.

() = () (1 - ) +

(2.8)

OAPB is definitely an improvement over the Weighted p-Persistence because it gathers information about the surrounding environment, such as where nodes are in relation to each other. Additionally, it combines a probability-based algorithm with a delay-based algorithm to ensure fewer possibilities of collision. The pitfalls of the algorithm are that it is dependent on heartbeat messages to be transmitted periodically. Furthermore, it requires all surrounding nodes to maintain constant updates of their surrounding nodes and their probability factors. This could add significant overhead to the messages needed to be shared. K. Autocast

An additional probability-based algorithm is called Autocast[21]. Similarly, Autocast, is

based on the nodes in the vicinity. The probability is determined with equation (2.9), where

Nh is the one-hop nodes within range.

2 = 0.4

(2.9)

One difference between Autocast and OAPB is that it does not make use of a delay for

nodes with a similar rebroadcast probability. Therefore, the usage of periodic

rebroadcasting is necessary to make sure messages are propagating correctly. This is

something that would increase the network traffic and possibly cause an unnecessary

20

broadcasting storm. "Broadcasting storm" is the term used for continuous broadcast message flooding[19].
There are many more protocols developed to help assist in the rapid dynamics of VANET, but they are not listed here due to space constraints. In summary, due to the speeds at which vehicles travel and properties of VANETs, network communication has to be quick and reliable.
21

3. Protocol Description This chapter describes the key design principles of the proposed multi-hop broadcasting protocol [11], [30], [31]. The few main contributions of this algorithm, which will be explained further in this chapter, are to reduce the channel access time by removing the handshaking mechanisms (i.e., RTB/CTB) preceding the safety message transmission, to minimize the message propagation delay by either eliminating the ACK-ing process or at least decoupling the message propagation process from ACKs to the sender, and to quickly recover from collisions using a novel collision resolution mechanism. 3.1. Motivation and Contribution When considering safety messages, reliability and speed are by far the most important parameters. They are especially essential considering the highly dynamic nature of the VANET environment. Therefore, the rapid propagation of safety messages in a reliable manner is one of the biggest challenges for a multi-hop algorithm. As common broadcasting schemes use geographical information (i.e. GPS coordinates) in the forwarder selection process [5], [2], [6], [7], [8], [18], they are not very reliable and accurate as they don't consider terrain interference, signal characteristics, GPS errors, malicious nodes injecting false GPS values and so on. To counter this, the proposed approach employs the use of SNR together with GPS coordinates in the forwarder selection process. Additionally, traditional VANET broadcasting algorithms, such as UMB [5] and SB [2], use handshaking mechanisms (RTB/CTB) before broadcasting the safety message and ACKs afterward. This sequential process introduces overheads and, thus, reduces the message dissemination speed. Therefore, the proposed algorithm removes the need for these costly handshaking mechanisms as well as decouples ACKs from the message dissemination process. The
22

proposed protocol also suggests a novel and improved collision resolution mechanism.

3.2. Protocol Design

As discussed earlier, in the proposed multi-hop algorithm, the handshake process

(exchange of RTB/CTB packets) prior to broadcasting the safety message is entirely

removed. The original sender (safety message initiator) simply accesses the medium using

the standard 802.11 CSMA/CA technique and broadcasts the entire safety message. Each

neighboring node i in the vicinity of the sender (i.e. within the transmission range R of the

sender) calculates its corresponding SNR value (SNRi) as well as its Euclidean distance

(Di) from the sender by using the GPS coordinates. Each receiver then uses these

calculations to compute their specific maximum contention window sizes (CWmax)

according to the following formula:

,

=



(-)





(3.1)

In the equation (3.1), k is a scaling factor to contain CWmax values within a suitable range (the contention window range is typically [0, 1023] but could be optimized under different traffic conditions as explored later in the report), Dmax (or R) is the maximum transmission

range of the sender, SNRthresh is the minimum SNR threshold value for reliable

transmission, is the exponential scaling factor to effectively accommodate the effect of SNRi while determining CWmax , and CWbase is the contention window base value that can be optimized based on the density of the network. After each node calculates its CWmax, it randomly chooses a time slot in the range [0, CWmax] and waits for that amount of slot times. This randomly selected time slot is also
23

known as CWchosen. The node that chooses the earliest time slot wins the contention and is chosen as the forwarder, hence rebroadcasting the safety message. All other contending nodes, after hearing this rebroadcast message, drop out of the rebroadcasting race. The rebroadcast message from the forwarder serves the purpose of an implicit acknowledgment back to the original sender from the forwarder since the broadcast is omnidirectional. This mechanism of forwarder selection and rebroadcasting the safety message (which also acts as an implicit ACK to the sender as described above) is portrayed by Figure 5(A).
FIGURE 5 (A) Normal Rebroadcast Scenario, (B) ACK Decoupling and Recovery Process.
Note that nodes that are farther away from the sender (and thus have lower SNRi) will have a smaller waiting time on average before retransmission, and therefore, they will more likely be chosen as forwarders. This unique approach of selecting forwarders based
24

on nodes' GPS coordinates as well as SNR level helps counter the limitations of distancebased or SNR-based multi-hop broadcasting algorithms.

Algorithm 1

1. Procedure Forwarder Selection (SNR(i), GPS coordinates)

2. Choose , k, CWbase according to optimal parameter choice [Refer to: Section 3.2(B)]

3. Distance(i) = Calculate Distance (GPS coordinates);

4. CWmax = Calculate CWmax (, k, CWbase, SNR(i), Distance(i));

5. Calculate Wait Time = Slot Period * Random Number [0,CWmax]; 6. while (Wait Time != 0)

7.

Listen for Rebroadcast;

8. if (Rebroadcast Received = false)

9.

Rebroadcast Safety Message;

10. else Do Nothing;

11. End Procedure

Algorithm 1 presents simple pseudocode portraying the process of forwarder selection and how the safety message rebroadcast occurs.
As the algorithm proposes the use of both SNR and GPS together in the forwarder selection process, the original sender is almost always able to overhear the rebroadcasted message from the forwarder, thus eliminating the need for a costly ACK-ing process; therefore, the safety message can progress without having to specifically wait for the successful reception of ACKs as opposed to traditional multi-hop protocols, such as SB
25

[2]. Eliminating the ACK dependency yields a significant improvement of the proposed protocol over SB in terms of performance.
However, under certain rare circumstances in which the sender might be unable to overhear the rebroadcast message due to the backward communication channel being lossy or the forwarder node moving out of the vicinity of the sender, as depicted in Figure 5(B), the following ACK Decoupling and Recovery Mechanism has been proposed: If the source does not receive the rebroadcasted message within a timeout period, it will once again broadcast the safety message. Upon getting the same message twice from the source, a node in the vicinity of both the source and the forwarder will send an explicit ACK to the original sender to cancel any further retransmissions from the source. However, this ACKing process is totally decoupled from and independent of the message propagation progress and, thus, will not contribute toward message propagation delay at all.
Although, the ACK-ing process does slightly increase the chances of collision in the vicinity of sender, these collisions can be drastically reduced by choosing the node closest to the sender for sending ACK as well as by limiting the power with which the ACK is transmitted. In order to find the node closest to the sender for an ACK transmission, the exact opposite of the contention process proposed by equation (3.1) can be used, which will provide more opportunity to a node with a strong SNRi and shorter distance from the sender to send ACK.
Nevertheless, the best way to completely eliminate the need for ACKs is to select an SNRthreshold with extra power budget (more than 3 dB) so that the sender is always able to overhear the broadcasted messages from the forwarders, and the entire need for the ACK decoupling procedure is removed. Note that the additional power budget to add a few
26

more dB in SNR will only slightly reduce the distance between the sender and the chosen forwarder, since the receiving power in typical mobile environments is inversely proportional to the 4th power of distance.
FIGURE 6 ACK Decoupling and Recovery Mechanism Figure 6 is a graphical demonstration of Receiver 2 (R2) recovering the ACK while the message propagation process is continued in parallel by Receiver 1 (R1). This ACK recovery process occurs after both of the following events: 1) the forwarder R1 rebroadcasts the safety message at t1, and 2) the sender S retransmits the message again at t2 (which is the timeout period).
27

FIGURE 7 Collision Resolution Mechanism (Not drawn to scale)
In a typical VANET environment, even with a large number of broadcasting messages (usually 10/sec/node), only a few safety messages actually collide as safety messages are quite small in size and are randomly distributed over time. Once collision does occur, it can simply be resolved by the quicker of the following two mechanisms: 1) by selecting the next node (other than the two nodes that caused collision) which wins the contention
28

as the forwarder as shown in Figure 7(A), or 2) by repeating the contention resolution procedure between the colliding nodes until the message is rebroadcasted as depicted in Figure 7(B). Note that, in this case, the nodes use the same CWmax calculated as before, but a new randomly selected time slot (CWchosen) is used to rebroadcast. Out of the above two techniques, the one through which the forwarder is selected earliest is selected to resolve collisions.
To the best of our knowledge, this novel collision resolution mechanism, which tries to resolve the collisions in a VANET environment by selecting the quicker of the two aforementioned mechanisms, has been proposed for the first time. The improved collision resolution mechanism results in a significant reduction in the overall message propagation delay. 3.3. Summary of the Proposed Protocol Design The following summary briefly outlines the steps of operation of the proposed algorithm:
1. Source/Sender broadcasts a safety/emergency message without requiring any prior handshaking mechanisms.
2. All nodes within range receive the message, and a node is chosen as forwarder based on the contention resolution mechanism suggested by the proposed algorithm in Section 3.2.
3. The chosen forwarder node rebroadcasts the message further on. 4. If a collision occurs, the collision-resolution mechanism proposed in the previous
section is applied. 5. If the source receives the rebroadcast message, then this serves the purpose of an
29

acknowledgement (ACK). 6. If the source doesn't receive the rebroadcast message from the forwarder, the source
will rebroadcast the message once again after waiting for the timeout period. 7. Upon getting the same message from both the forwarder and the source node (after
timeout occurs), a node in the vicinity of both the source and the forwarder will perform the ACK decoupling and recovery process (as explained in the previous section) and handle the transmission of ACK to respond to the original source/sender to cancel any further message retransmissions. 8. If the source does not receive a message back within the timeout period due to unavailability of nodes in the transmission range, repeat from step 1. Figure 8 shows a flow chart describing the design procedures executed at each i-th node. As can be noted, the proposed protocol is a distributed algorithm where all nodes cooperate to help in safety message dissemination in VANETs. Due to many advancements and novelties as described in Section 3.2, the proposed algorithm significantly improves the rate at which the message is propagated along the VANET as compared to the traditional protocols. The results achieved by analysis, simulation and experimentation demonstrate this improvement as explained in later chapters.
30

FIGURE 8 Flow Chart Describing Key Design Steps at Each i-th Node.
31

3.4. Comparison of Proposed Protocol with a Traditional Multihop Algorithm SB In this section, we present a delay comparison of the proposed protocol to a handshaking protocol known as Smart Broadcast (SB) by the aid of timing diagrams.
In Figure 9, a detailed timing diagram is presented to illustrate message transmission and delay during a normal rebroadcast scenario in SB and the proposed protocol. In Figure 9(A), the sequence of packets being transmitted in SB is shown. Figure 10 depicts a scenario in which collision occurs while rebroadcasting the safety message in both SB and the proposed protocol. As shown in Figure 10(A), once a collision occurs in SB, the two nodes involved in collision remain in the contention phase, and the node with the next lowest minimum back off sends the CTB and is selected as a forwarder.
In the first mechanism, illustrated in Figure 10(B-1), the nodes involved in a collision once again back off for a random time slot (CWchosen) in the range [0, CWmax] to rebroadcast the message and repeat this cycle until the collision has been resolved. Figure 10(B-2) illustrates the second mechanism whereby a third node wins the contention and is selected as a forwarder before the two colliding nodes could recover from the collision. It is quite obvious from Figure 9 and Figure 10 that the proposed algorithm significantly improves the rate at which the message is propagated along the VANET as compared to the traditional SB protocol. These results can be verified by the simulation results presented in Chapter 5.
32

[A] S.B. (No Collision)

SIFS

SIFS

SIFS

RTB

Message (For Next Hop)

CTB

Sender User 1

ACK

TSB [B] Proposed Protocol(No Collision)
SIFS Message
Message

User 2 (Forwarder)
Sender User 1(Forwarder)

User 2
TProposed
FIGURE 9 Timing Diagram Normal Rebroadcast Scenario (Proposed Protocol vs. SB)
33

[A] S.B. (Collision)
SIFS RTB

SIFS

SIFS

SIFS

Message

Sender

CTB

CTB

User 1(Forwarder)

ACK

CTB

[Collision] TSB
[B-1] Proposed Mechanism 1 (Collision)

SIFS

SIFS

Message

Message

Message

[Collision] Message

User 2
Sender User 1(Forwarder)
User 2

[B-2] Proposed Mechanism 2 (Collision)

SIFS

SIFS

Message

Message

[Collision] Message

Sender User 1
User 2

Message

User 3(Forwarder)

FIGURE TProposed 10 Timing Diagram Collision Scenario (Proposed Protocol vs. SB)

34

4. Theoretical Analysis In this chapter, the theoretical model of the protocol is presented and analyzed in order to establish and validate the effectiveness, robustness and reliability of the proposed scheme [30], [31]. In section 4.1, the theoretical model of the proposed protocol is described, along with the assumptions and hypothesis. Section 4.2 presents the results and analysis, while also suggesting optimal parameters to improve protocol efficiency. 4.1 Theoretical Model In this section, the expressions that were constructed include per-hop rebroadcast latency (THOP), average distance progressed per-hop (DF), average message dissemination speed (s) and average throughput. For the remainder of Chapter 4, a vehicle equipped with DSRC device (i.e. having V2V and V2I communication capability) will be referred to as a node. A. Hypothesis and Assumptions Before presenting the expressions constructed for theoretical analysis, this subsection lays down some basic hypotheses and assumptions. The highway scenario has been analyzed, whereby a safety message is disseminated along a rectangular strip of the road whereby the length of the strip represents the typical transmission range R of a vehicle. Typically, the nodes within this range from the sender will be able to hear the broadcast message, considering good channel conditions. Figure 11 depicts the highway scenario being modeled:
35

- - - - - - - - - - - - - - - - - - - - - X FIGURE 11 Highway Scenario
The distribution of nodes along the road strip follows a bi-dimensional Poisson process with the parameter nodes per strip. It is important to mention here that the nodes moving in the direction of the message propagation have a comparatively small relative velocity with respect to the message broadcaster (approximately less than 10s of mph) and, therefore, it will take at least a few seconds before any node within the range R of the broadcaster is able to leave the boundary. On the other hand, the time taken for message propagation and successful rebroadcasting (typically a few milliseconds) is negligible compared to this time. Hence, it is assumed that nodes don't leave the transmission range R of the broadcaster during the contention period.
After the sender broadcasts the safety message, each i-th node within the range R calculates its corresponding CWmax,i value upon successfully receiving the message and chooses a random time slot (CWchosen,i) in the range [0, CWmax,i] as described in the previous chapter. It can be noted here that each node chooses its time slot independently of any other node. Let us denote Nx to be the total number of nodes that choose the x-th time slot to rebroadcast the message. Therefore, under the above assumptions, Nx are independent and identically distributed Poisson random variables with parameter = / [] where E [CWchosen] is the expected number of time slots that a node will have to wait, on average, before it can rebroadcast the message. It can be calculated as
36

[]

=

=0

[,

]

(4.1)



=0([, ] / 2)

As the message propagation time is almost negligible, and the nodes are within a relatively

short distance of each other (less than R), the time slots for all the nodes are assumed to be

synchronized. Therefore, at the x-th time slot, one of the events listed below occurs:

1. If Nx = 0: The channel remains Idle (I) as no node within the range R is able to win the contention to rebroadcast.
2. If Nx = 1: Only 1 node wins the contention in this time slot and, hence, rebroadcasts the message, resulting in a success (S).
3. If Nx > 1: Multiple nodes try to rebroadcast in the same time slot, which results in a collision event (C ).

Hence, based on the independent and identically distributed Poisson random variable

property of Nx, the above events occur with the following respective probabilities:

PI :

( = 0) =

( )0- 0!

= -

(4.2)

PS :

( = 1) =

()1- 1!

= -

PC : ( > 1) = 1- PI - PS = 1 - -( + 1)

(4.3) (4.4)

Where PI is the probability of having an idle time slot, PS is the probability of having a successful message rebroadcast in the time slot, while PC is the probability of having a
37

collision in the time slot.

B. Per-Hop Rebroadcast Latency (THOP)

In this subsection, the mean per-hop delay (THOP) is calculated. In other words, THOP is the

average time between a node receiving a safety message from the sender and

rebroadcasting it to the next forwarder.

First, let us denote TI to be the time taken for event I, TS for the event S and TC for

event C respectively. TI requires a single time slot. However, both TS as well as TC take

message transmission/reception time (including message propagation delay), followed by

SIFS.

Let us denote TF to be the average time taken in case of a failure event (i.e., either

the time slot is wasted (I) or a collision (C) occurs). Hence, TF can be expressed as follows:

=



+

+

+

(4.5)

Therefore, the average number of occurrences of these failure events (NF) before a

subsequent success event (successful rebroadcasting) is given by the following expression:

=

1 -

(4.6)

Additionally, let us denote TZ to be the time spent when no forwarding node (exactly zero

forwarders) is found within the range (R) of the sender. It can be calculated as

= .

(4.7)

38

where To is the time-out value and PZ is the probability of having no forwarding node within the range (R) and can be approximated as - (Note: = . [] ). Finally, the

expression for mean per-hop rebroadcast latency (THOP) is = + +

(4.8)

C. Average Throughput

The average throughput can be defined as the total amount of useful data that can be

successfully disseminated in the VANET per unit time. In our case, we can assume that a

safety message (of a certain size) can be rebroadcasted in a mean per-hop rebroadcast time

(THOP ). The following expression gives the mean throughput:



=



(4.9)

D. Average Distance Progressed Per-Hop (DAVG)

In this subsection, the mean distance traversed during each successful message rebroadcast

(DAVG) is measured. As the node intensity in the road strip increases, there are more nodes

per unit area resulting in increased chances of having some nodes closer to the border of

the range (R) as compared to cases when the node intensity in the road strip is lower.

Therefore, these furthest nodes within the transmission range (R) of the original sender

would most likely be chosen as forwarders as their CWchosen would likely be smaller due

to the increased distance from the sender. If the exact geographical location of each node

in the strip is known, the approximate distance between the sender and forwarder (DF) can

be constructed such that more weight is given to the farther nodes within range (R) during

the forwarder selection process:

39


= ()
=1

(4.10)

where Di is the distance between each i-th node and the original sender, Wi is the weight

assigned to each i-th node based on its CWmax,i (which is a function of the node's distance

and SNR values). Wi can be calculated as follows:

1 = , . =1 (1, )

(4.11)

Let us assume that the nodes are spatially placed along the road strip at a regular interval

in such a manner that each node except the sender and the last node is equidistant from two

other nodes and that the furthest node within the transmission range (R) is selected as the

forwarding node. Hence, the average distance progressed per hop (DAVG) can be given by

- 1 = .

(4.12)

E. Average Message Dissemination Speed (s)

Message dissemination speed (s) is defined as the average distance covered by the message

per unit time. In other words, s can be defined as the ratio between average distance

progressed per hop and average rebroadcast latency:

=



(4.13)

40

4.2 Results & Analysis This section presents the validation of the theoretical model and suggests an optimal parameter choice to improve protocol efficiency. The simulation has been performed in NS-3, a discrete-event network simulator. The parameters used in the simulation are carefully chosen with minimal assumptions in order to get accurate results. Table 2 lists some of the parameters used for simulation.

TABLE 2

Simulation Parameters

Attribute

Value

Data rate

6 Mbps (OFDM)

Transmission range (R)

300 meters

Fading model

Nakagami fading model

Mobility model

Constant velocity mobility

Road dimensions

4 km long (2 lanes)

Node density

25 250 nodes

Time slot

40 Sec

SIFS

10 Sec

SNRthresh

8dB

Safety Message Size

50 bytes

Simulation Time (per run) 100 seconds

41

FIGURE 12 Average Per-Hop Rebroadcast Latency (Theoretical vs. Simulation Results) A. Validation of Theoretical Analysis In this subsection, the theoretical results are compared with simulation results to validate the mathematical expressions constructed in section 4.1. In order to closely align the simulation environment with the theoretical model, there are no background messages, other than the safety message itself, in the simulation setup.
A key performance metric used to evaluate the robustness and effectiveness of the proposed protocol is mean per-hop rebroadcast latency (i.e., the average duration it takes for the safety message to travel across one hop). Figure 12 shows the average per-hop rebroadcast delay versus the node intensity in a 4 km long road strip. As can be noted from the figure, under sparse traffic conditions (e.g., around 25 nodes), the average per-hop
42

delay for both theoretical results as well as simulation results is much larger as compared to dense traffic conditions (>100 nodes). The reason is that when there are few nodes on the road strip, it is very probable that there is no node present within the transmission range (R) of the sender to rebroadcast the message, thus causing timeouts, which impact the delay values quite adversely. Another observation from Figure 12 is that simulation results generally depict higher delays as compared to theoretical results. This behavior can be attributed to the fact that simulation environments take into account many realistic limitations which the mathematical analysis tends to ignore, such as the signal fading model (Nakagami fading model), channel condition, medium characteristics and so on. These limiting factors have the negative effect of increasing the delay values of the simulations results. Moreover, under fairly dense traffic conditions (> 200 nodes), the delay decreases to a significantly lower value of less than 1 ms. This happens because, under such conditions, the chances of having a node closer to the boundary of the transmission range (with a small CWmax value) is quite likely, thus reducing the waiting time before a rebroadcast occurs.
Another interesting observation is that under very high traffic conditions (> 1000 nodes), the delay values start rising. This effect can be seen more clearly in Figure 16 and will be explained more toward the end of section 4.2. Overall, the results of theoretical analysis and simulation are conforming.
43

FIGURE 13 Average Distance Progressed Per-Hop (Theoretical vs. Simulation Results) Figure 13 depicts the average distance covered by the safety message during a single successful broadcast (single-hop progress). It can be noticed from Figure 13 that as the number of nodes increase, the average distance covered by the message across a hop also increases. The reason for this increase is that with more nodes, the chances of having a node closer to the edge of the sender's transmission range R increases. Therefore, the forwarder selected to rebroadcast the safety message will likely be farther away from the sender. Thus, the message will travel a greater distance on average; however, as the node intensity increases further, the distance growth steadies toward the maximum transmission range (300m). Once again, the simulation and theoretical results match.
44

FFIIGGUURREE144 AAvveerraaggee MDiesstsaangceeDPirsosgermeisnseadtioPnerS-Hpeoepd ((TThheeoorreettiiccaall vvss.. SSiimmuullaattionn RReessuultss.)
Figure 14 shows the message dissemination speeds obtained by the theoretical and simulated results. As can be observed, the speed is generally increasing for both environments with an increase in node intensity. This upward trend occurs because as the number of nodes increase toward 225 nodes, the average per- hop delay decreases, whereas the distance progressed per-hop increases (as explained previously). Again the slight difference between the theoretical results and the simulated results is due to the lack of consideration of channel characteristics and other physical attributes in the theoretical model. However, both the curves are relatively matching with a similar trend. B. Optimal Parameter Choice This subsection determines the optimal choice of parameters to maximize the efficiency of
45

the proposed protocol. Substituting the variables in equation (4.8) results in the following

expression for average per-hop rebroadcast latency (THOP):

where,



=

=0 , 22

(

+

)

+



+



,

=



( - )





(4.14)

It can be noted from equation (4.14) that the average per-hop latency (THOP) is mainly

dependent upon two varying parameters, which are CWmax and , the number of nodes

within the transmission range (R) of the sender that are contending to rebroadcast the safety

message). Therefore, it is necessary to study the values of these parameters to minimize

the THOP. It can be observed that CWmax can be optimized using k, , and CWbase. To

investigate the behavior of CWmax, repeated simulations (almost 100 runs) using the

Nakagami propagation loss model were conducted to see how the SNR values at the

receivers (SNRi) vary as the distance from the sender (Di) increases while keeping the

transmission power constant. Table 3 offers a glimpse from the dataset of the relationship

between SNRi and Di.

TABLE 3

Di vs. SNRi (GLIMPSE FROM THE DATA-SET)

Di (meters)

SNRi (dB)

10

35.95

50

23.25

100

17.48

150

15.48

200

14.20

250

13.06

300

11.00

46

FIGURE 15 Effect of Changing Parameters on Per-Hop Delay By using these (Di, SNRi) pairs, along FwIiGthUvRarEyi4ng k, , and CWbase, numerical analysis was caArrvieedraoguet Dtoisdteatnecrme PinreogthreesmseindimPeurm-Hvoaplu(eTfhoeromreetaicnapl evrs-.hSoipmduellaatyio(nTHROePs)u. Fltsig. ure 15 portrays a scenario in which the average per-hop delay (THOP) varies as a result of different combinations of k and , while CWbase = 2 and = 6. Under such sparse traffic conditions, THOP decreases to less than 1 ms by choosing values of >15 and k <20. However, it is to be noted here that there is no unique range for , k, and CWbase that would result in a minimum THOP under all traffic conditions and circumstances. For example, in cases of highly dense traffic conditions, smaller values of k and CWbase might result in more collisions as the CWmax range becomes significantly smaller, thus causing more delays due to message retransmission. On the other hand, very high values of k and CWbase would result in longer wait times before rebroadcasting as the CWmax range increases, hence increasing the delay. Therefore, figuring out a range of values of k, , and
47

FFIIGGUURREE146 Average DiEstfafenccteoPfrCohgraensgsiendgPCeWr-Hmoaxp R(TahnegoeroetnicPael rv-sH. SopimDuellaatyion Results. CWbase that take the prevailing traffic conditions into consideration would be more likely in incurring minimum delays. For extremely congested scenarios (such as traffic rush hours in urban areas), it is suggested to use higher values for k (above 30), while lower values for (less than 15). Under such conditions, CWbase size may also be increased to 3 or above to minimize message collisions. On the other hand, for light traffic conditions, choosing values of >15 and k <20 will result in minimum THOP, as described earlier. Figure 16 presents a comparison of the theoretical results of average per-hop delay (THOP) for a shorter CWmax range [0, 1024] versus a much longer range [0, 4096]. Figure 16 shows that when the CWmax range is increased under light traffic conditions ( 100
48

nodes in a 4 km long highway strip), there is a multifold increase in delay due to the likely occurrence of timeouts (timeout period is correlated to CWmax) which occur if no node is found within the transmission range (R) of the sender. Moreover, greater CWmax values mean forwarders have to wait much longer on average before rebroadcasting the message.
On the other hand, under heavy traffic conditions (> 2000 nodes), a larger CWmax range actually results in a better delay performance. This is due to the fact that under such dense traffic conditions, much fewer collisions will occur if a larger CWmax range is being used as opposed to a shorter CWmax range, resulting in lower delays. The sensitivity analysis of equation (4.8) shows that for lower node intensity, the timeout period (To) dictates the delay (THOP) values, whereas under higher node intensity, the number of collisions and time to recover from those collisions determine the THOP results.
49

FFIIGGUURREE147 Average DisEtafnfeccetPorfoCgWremssaedx PonerA-Hveorpag(TehDeiosrseetmicianlavtsio. nSiSmpueleadtion Results. Figure 17 illustrates the comparison of the theoretical results of message dissemination speed between a smaller CWmax range [0, 1024] versus a larger range [0, 4096]. Note that for lower traffic intensity, the message propagation speed is higher with a smaller CWmax range as opposed to a larger CWmax range. This happens because, on average, smaller CWmax values result in shorter waiting times for forwarders before rebroadcasting the message, resulting in higher speeds. However, under higher traffic intensity (> 2000 nodes), the larger CWmax actually results in higher propagation speed as much fewer collisions occur if the larger CWmax range is being used. Nevertheless, an interesting observation from the figure is that as the number of nodes keeps on increasing, over the long run, the message dissemination speed ultimately drops, regardless of CWmax range,
50

due to the increased occurrences of collisions. Therefore, in light of the observations from Figure 16 and Figure 17, under light traffic conditions (normal road scenario), lower CWmax ranges should be preferred throughout the network, whereas under high traffic conditions (such as during traffic congestion in multiple lane highways or during rush hours in urban areas), larger CWmax range should be used, as stated earlier. The optimal choice of parameters leads to a significant reduction in overall message propagation delays.
51

5. Simulation In order to evaluate the efficiency of the proposed algorithm, the simulation is performed in NS-3, a discrete-event network simulator. This simulation environment facilitates conditions close to the VANET environment, such as Rayleigh fading model, the two-ray ground path loss model, the constant velocity mobility model and so on. Table 4 presents the parameters used in the simulation. The parameters chosen for simulation purposes are practical with minimal assumptions in order to get accurate results. The simulation is run in the presence of periodic beacon messages at 10 Hz with 400 byte-long payloads.
To see the performance of the proposed algorithm as compared to the traditional VANET broadcasting algorithms, the proposed protocol along with the Smart Broadcast (SB) protocol is implemented and evaluated under the same conditions.

TABLE 4 Simulation Parameters

Attribute Data rate Transmission range Fading model Mobility model Node density Road dimensions Vehicular Speed Time slot
SIFS k, SNRthresh RTB, CTB, ACK Emergency Message Size Beacon Message Size Beacon Generation Rate SB (# of Sectors) Simulation Time (Per Run)

Value 6 Mbps (OFDM)
300 meters Rayleigh fading model Constant velocity mobility
525 nodes/km 4 km * 30 m (2 lanes)
70 mph 20 Sec 10 Sec 1, 8 dB 20, 14, 10 bytes 100 bytes 400 bytes 1 Packet / node / sec
10 100 seconds

52

Average Delay Per-Hop (ms)

1.6

1.4

CWbase=2

CWbase=4

CWbase=6

1.2

1

0.8 0.6

0.4

0.2

0

10

20

30

40

50

60

Node Intensity (Nodes/km)

FIGURE 18 Effect of CWbase on Average Per-Hop Delay In Figure 18, the average per-hop delay versus node density of the proposed protocol is displayed for different CWbase values of 2, 4 and 6. Note that for lower node intensity, the average per-hop delay is slightly higher for all CWbase values as compared to higher node intensity. Under sparse traffic conditions, such as 10 nodes/km, there is a high possibility that no node may fall within the 300-meter transmission range, and thus, the sender (message initiator) may have to wait for timeout value (which is greater than the maximum CWmax) before rebroadcasting the safety message. This increases the average delay values. However, toward the higher end of node intensity (more than 40 nodes/km), a slight increase in delay is observed. A possible explanation is that more nodes compete in

53

contention for rebroadcasting the message, which increases the chances of collisions among nodes, thus increasing delays.
An interesting observation from Figure 18 is that the overall difference between the delay values of different CWmax values tends to narrow down as the node intensity increases. As the node intensity increases, more nodes are competing to rebroadcast the safety message and hence, under higher CWbase values, the nodes have less chance of collision due to more time slots available, which reduces mean per-hop delay. This, in turn, reduces the gap between low and high CWbase values.
Another important finding in Figure 18 is that under mild message generation rates of about 1 emergency message/node/sec, a lower CWbase, such as 2, tends to have a lower average delay. This is obvious as under conditions with less chance of collision; a low CWbase leads to lower CWmax, which implies that forwarders have to wait for a shorter amount of time before rebroadcasting. However, under higher collision conditions (i.e. a higher message generation rate), a larger CWbase might prove to be more effective as a longer range of time slots (due to the bigger [0, CWmax] range) reduces the chances of collision and, thus, reduces delays.
For the rest of the simulations, mild message generation rates are considered. Hence, the optimal value of 2 has been chosen for CWbase for the remaining of simulation results.
54

FIGURE 19 Comparison of Per-Hop Delay (Proposed Protocol vs. SB) For an effective comparison of the proposed protocol against the SB protocol, two main performance metrics, per hop delay and throughput, are investigated. In Figure 19, the mean per hop delay for the proposed protocol versus SB is shown. The proposed algorithm performs up to 200% better than SB in terms of average per-hop delay. These results are expected from the two major design elements. First of all, while SB is highly dependent upon RTB/CTB for successful rebroadcasting, the proposed protocol broadcasts messages without prior handshaking mechanisms. Secondly, in SB, forwarders use ACKs before rebroadcasting the message, whereas the forwarder in the proposed algorithm uses the SNR and GPS to eliminate the ACK procedure or at least decouple it from the message propagation process.
55

6 Proposed Algorithm SB
5

Maximum Throughput (Mbps)

4

3

2

1

0 100

400

800

1200

Packet Size (bytes)

1600

FIGURE 20 Comparison of Max Throughput (Proposed Protocol vs. SB) In Figure 20, throughput is defined as the amount of useful information that can be exchanged between the nodes per unit time is portrayed. As shown in the plot, the proposed protocol achieves approximately twice the throughput compared to SB. In the SB protocol, a large amount of network resources is wasted in the mandatory exchange of RTB/CTB/ACK packets, which clearly is avoided by the proposed protocol, leading to an increased throughput. Secondly, in the proposed protocol, the mean per-hop delay is much smaller than SB, which also explains the throughput improvement. For all the variable payload sizes, the proposed algorithm consistently shows significant improvement over SB. An interesting observation from Figure 20 is that as the safety message packet size
56

increases, there is an improvement in the overall throughput. For the proposed algorithm, this improvement can be attributed to the fact that the time spent by the nodes in contention before rebroadcasting a message is almost the same regardless of whether it is a large or a small packet being rebroadcasted. Thus, for a larger packet, more data is transferred in similar latency, and thus, it results in a higher overall throughput. For SB, for each such successful packet rebroadcast, an RTB/CTB/ACK triplet must be exchanged along with the contention resolution.
57

6. Experimentation In this chapter, the test-bed implementation, equipment, experimental platform, test scenarios and results of the field trials are discussed in an effort to validate the effectiveness of this protocol. The field trials were carried out to test the proposed scheme and algorithm in real life situations to validate its performance. 6.1. Equipment & Test-bed Implementation The equipment used to establish V2V and V2I connectivity includes DSRC-equipped Arada Systems' LocoMate Classic On-Board Units (OBU) and the LocoMate Road-Side Units (RSU). Both the OBUs and RSUs operate at a frequency band of 5.9 GHz (5.855.925 GHz) and have a maximum power output of 23 dBm +/- 1dBm, which is equivalent to under 250 mW. The OBUs and RSUs also contain GPS modules with a claimed accuracy of less than 1 meter. However, during our experimental phase, the GPS error was discovered to be a bit larger, in the order of a few meters. Additionally, the OBUs are equipped with external USB Ports and Bluetooth and support a consistent 3 ms switch time at every 50 ms channel switching. The units fully support TCP/UDP, WAVE Short Messaging Protocol (WSMP), and WAVE Basic Service Set (WBSS). The main difference between the RSUs and OBUs is the antenna gain of 12 dBi in the RSUs and the weatherproofing capability of RSUs for outdoor conditions. The RSUs can be powered over Ethernet to remove the necessity of having a separate power line pulled to the device.
Through this project, we developed a test bed consisting of eight OBUs and 2 RSUs with the proposed multi-hop scheme implemented. The test bed can be used for safetyrelated as well as non-safety-related applications.
58

FIGURE 21 Snapshot of an Application being Developed in Eclipse IDE 6.2. Programming Guide Arada Systems offers a built-in library called Locomate to support the creation and usage of numerous applications for safety, infotainment and entertainment purposes for V2X technology. The Locomate library provides support for both Windows and Linux/Unixbased operating systems. The applications are compiled using make files to generate the binary files, which are then uploaded to the OBU/RSU and executed. The Locomate library can be integrated with IDEs like Eclipse or NetBeans for an easier programming experience. Figure 21 portrays a snapshot of a Locomate application being programmed in the Eclipse environment.
59

FIGURE 22 Eclipse Settings for Integrating Locomate in Eclipse Environment Figure 22 illustrates a series of settings in the Eclipse environment to integrate Locomate project files in Eclipse. Starting a new workspace while importing the Locomate project is recommended.
60

Once the programming environment is set up, any custom application can be developed, allowing algorithms to be implemented and evaluated through practical experiments. For the remainder of this report, the custom application developed for carrying out field trials is referred to "Multi-hop EMD Application," where EMD stands for Emergency/Safety Message Dissemination.
The Arada Systems devices (OBU/RSU) can be remotely controlled and accessed through Telnet. Generally, the following steps should be performed in interacting with the devices and executing Multi-hop EMD Application:
1) Set up a static IP address on the computer to match the OBU/RSU's default gateway IP address. Commonly, it will be in the form "192.168.0.XXX," with the computer's gateway IP address set as "192.168.0.1" and subnet mask as "255.255.255.0," where XXX is a number other than that particular OBU/RSU's IP address.
2) Plug in the device (OBU/RSU) and connect it to the Ethernet port of the computer. If data logging is required, plug a flash drive into the USB port of the device before powering on the device.
3) Use either a Command Prompt Window for Windows or Terminal for Linux/Unix based OS to connect to the device using "telnet 192.168.0.XXX," where XXX is that particular device's allocated IP Address. The default IP address of the devices is 192.168.0.40.
4) Enter the username and password credentials for the Arada Systems DSRC devices (OBU/RSU) when prompted.
61

5) Once connected, the configurations can be read and modified using the "cli" command. To show configurations such as the device's IP address, type in "show configuration."
6) To run a particular custom application, simply go to the "var" folder where the binary file will be stored and can be executed. To open any custom application, follow these steps: a. Enter "cd /var" b. Type "./application_name." The custom application developed for this research project, "Multi-hop EMD Application," has been named "localtxcustom." c. Once the application has been opened, follow the prompt instructions which appear and are self-explanatory. For help "?" can be entered, and a list of items will appear, explaining the components and purpose of the application.
7) While the Multi-hop EMD Application is running, entering "x" transmits a single packet. Type "p" to enter a custom message. Type "i" to change the device's name. To transmit continuous packets, type "z." a. To have a delay between packets, type "y"; otherwise, type "n." If "y" is entered, enter the number of packets to be sent and press "Enter," followed by the time interval between packets in milliseconds. b. To end a continuous transfer, enter "z"; then type "n" and press "Enter."
62

FIGURE 23 List of Options for Parameter Setting in Multi-Hop EMD Application 8) The application is designed in a manner such that parameters can be changed on the go as required during the field tests. Typing "?" lists all options. Figure 23 displays the list of different options that entering "?" generates.
63

FIGURE 24 List of Options to Enable Different Printouts 9) Enter "." to enable/disable different print outs of variables or data. Figure 24 presents the different options to enable/disable the console printout information. Figure 25 presents a snapshot of a transmitted packet in Multi-hop EMD Application, while a received packet printout will be in the form shown in Figure 26.
FIGURE 25 Snapshot of a Particular Transmitted Packet
64

FIGURE 26 Snapshot of a Particular Received Packet The Multi-hop EMD application captures logs which can be analyzed to gather results for testing the proposed protocol's efficiency. Some of the logs gathered during the field trails are available in the Appendix, while others are available online. The field trials and their results are discussed in great detail in the following sections.
65

6.3. Field Tests in Static and Dynamic Environments Single-Hop and Multi-Hop Experiments in Static Environment
Multi-Hop Field Test Experiments along I-75 Highway @ 60 mph
66

Single Hop Field Test Experiments along Northside Dr. in front of Georgia Dome 67

Multi-Hop Field Test Experiments in Local Roads at Lawrenceville
6.4. Field Test Results A. RSSI and Transmission Range Measurements of an OBU
68

In the initial experimentation phase, a single hop V2V communication was established between two OBU devices. A stationary OBU would broadcast the safety messages, while the other mobile OBU, which was receiving the packets at different distances from the sender, was used to analyze the Received Signal Strength (RSS) information and transmission range of the devices.
Figure 27 portrays the RSS of the receiver OBU at different distances from the sender. Note that as the distance between the two OBU devices increases, the RSS decreases as expected. Hence, as the distance goes beyond 200 meters and approaches 300 meters (which is the approximate maximum transmission range of OBU), the RSS drops to a minimum of -90 dBm. Therefore, after approximately 250-300 meters, the signal strength is insufficient to transmit a packet accurately. B. Indoor Experimentation

RSSI (dBm)

-50 -55 0 -60 -65 -70 -75 -80 -85 -90 -95

Distance (m)

100

200

300

400

FIGURE 27 Single Hop: RSS vs. Distance

69

In this phase of experimentation, the proposed multi-hop algorithm was implemented on the Arada Systems DSRC devices (OBU/RSU) and evaluated under real-world indoor conditions. As the distance between the sender and the receiver increases, the SNR level of the received signal is drastically reduced due to the presence of multiple obstructions and walls in the indoor environment. This behavior is depicted in Figure 28. As can be noted from the figure, the SNR reduces to less than 8 dB after a distance of 15 meters, and therefore, the signal is considered too weak to be decoded properly. Hence, in indoor conditions, the transmission range of OBU/RSU is significantly reduced, and the packet loss rate increases sharply.
SNR vs. Distance
35 30 25 20 15 10 5 0
Distance (m) Figure 28 Indoor Experimentation: SNR vs. Distance
70

SNR (dB)

CWmax Value

900 800 700 600 500 400 300 200 100
0 0

CWmax vs. Distance

10

20

30

40

50

60

70

Distance (m)

Figure 29 Indoor Experimentation: CWmax vs Distance The CWmax exhibits a sharp drop as shown in Figure 29 due to the above mentioned sudden drop in SNR when the distance between the sender and the receiver increases in an indoor setting. Hence, the CWmax reduces to a bare minimum of < 50 slots as the distance between the sender and receiver increases beyond 15 meters. Therefore, a forwarding node (to rebroadcast the message) will be chosen very close to the original sender. This behavior is expected due to the fact that in an indoor environment, the effective transmission range of the sender is significantly reduced, so a forwarder very close to the sender has to be chosen. For these experiments, the configuration was set up as follows: Packet size = 1300 Bytes, Transmission Power = 14, Rate = 6Mbps, GPS polling frequency = Every .2 seconds, and Time Slot period = 25 us.

71

Per-hop Delay (s)

Delay vs. Distance
0.08 0.07 0.06 0.05 0.04 0.03 0.02 0.01
0
Distance (m) Figure 30 Indoor Experimentation: Per-hop Delay vs. Distance Figure 30 presents the per-hop delay results for the indoor environment as the distance between the sender and forwarder varies. It can be noted that the delay values are high (around 40 ms). This occurs because for indoor environments, there are a lot of packet losses that cause timeouts, resulting in higher delays. Furthermore, as the effective transmission range of the sender in the indoor scenario is quite small, the waiting times for the forwarding nodes before rebroadcasting is significantly high (as dictated by the algorithm). One observation from Figure 30 is the lack of any particular trend in the delay
72

results (data points scattered everywhere). This can be attributed to irregularities in the indoor environments in terms of packet loss, multiple obstructions, walls, and so on. C. Outdoor Experimentation in Static Environment In the third phase, the outdoor field tests were conducted in a static environment at Lawrenceville, Georgia. The objective of this experiment was to evaluate the forwarder selection process based on the receiver's SNR level and distance from the sender.

For this experiment, vehicle 1 (sender) broadcasts the safety message, while

vehicles 2, 3 and 4, which are at a distance of 40 meters, 75 meters and 160 meters from

the sender, receive the safety message and contend to be the next forwarder. Table 5 shows

some of the values of different parameters collected by each vehicle while receiving safety

messages. Note that the farther the vehicle is from the sender and the lower its SNR value, TABLE 5
Data Gathered through the Reception of Safety Messages

Vehicle # 2 3 4

Distance (m) 40 40.6 40.3 39.8 39.4 40.1
76.259 75.238 75.61 75.729 75.52 75.694 163.549
162 164.199 163.38 163.45
163

SNR (dB) 19.5 14.5 14 19 14.5 15.5 12 11.5 11.5 11 14 13 13 12 13.5 11 13 14

CWmax 458 130 116 406 134 169 37 33 33 29 62 48 22 18 25 14 22 29

CWchosen 121 148 83 133 104 47 31 27 9 18 21 34 3 13 12 0 14 17

73

CWmax

500 450 400 350 300 250 200 150 100 50
0 0

B Cwmax C Cwmax D Cwmax

50

100

150

200

Distance (m)

Figure 31 Outdoor Static Experimentation: CWmax vs. Distance the shorter its waiting time will be before rebroadcasting the message; thus, such a vehicle will have a higher probability of being chosen as the forwarder. In the plots in Figure 31 and Figure 32, the proposed protocol's forwarder selection process is evaluated. Figure 31 shows the CWmax values that were calculated by each vehicle (within the transmission range, R, of the sender) when they receive the safety messages. Figure 32, on the other hand, depicts the variation in CWchosen versus distance.

CWchosen

160 140 120 100 80 60 40 20
0 0

B Chosen C Chosen D Chosen

50

100

150

200

Distance(m)

Figure 32

Outdoor Static Experimentation: CWchosen vs. Distance

74

It can be noted from Figure 31 and Figure 32 that the vehicles that are farther away from the sender (but within R) generally have a lower CWmax as well as CWchosen, and hence, there will be a lower waiting time before rebroadcasting the message. Such vehicles have a higher probability of being chosen as a message forwarder. The algorithm results were consistent with expectation.
Figure 33 presents the average delay it takes for a safety message to progress a certain distance. Note that the delay reduces until reaching a distance of about 300 meters and starts increasing afterwards. This can be attributed to the fact that until about 300 meters (which is the typical transmission range of an OBU), the waiting time of a forwarder before rebroadcasting the message is reduced as the distance increases, resulting in lower delays. On the other hand, above 300 meters, there is a high probability of more than one hop communication being required, which multiplies the delay. The average delay was

Average Delay (ms)

3.5 3
2.5 2
1.5 1
0.5 0 0

100 200 300 400 500 600 700 Distance (meters)

Figure 33 Outdoor Static Experimentation: Average Delay vs. Distance

75

measured to be 1.93 ms. It is to be noted that these delay values are significantly lower than indoor delay, due to having nodes present near the boundary of the transmission range of the sender and having less packet drop (thus fewer timeouts). D. Outdoor Multi-Hop Experimentation in Dynamic Environment In the final stage of experimentation, field trials of the proposed multi-hop algorithm were carried out using a fleet of moving vehicles. A convoy of six to seven vehicles equipped with OBUs were used to deliver the safety message in a Multi-hop manner to the RSU that was installed on the roadside. Figure 34 shows the formation of vehicles for the experiment.
Field experiments were carried out under different traffic scenarios, such as a highway scenario along I-75 as well as under a local road scenario in Lawrenceville. The multi-hop algorithm behaved as expected, and several interesting findings were discovered from the experimentation.
Figure 34 Outdoor Multi-Hop Experimentation Topology
76

10000

1000

Average CWmax

100

10

1

0

100

200

300

400

Distance (Meters)

Figure 35 Outdoor Multi-Hop Experimentation: Average CWmax versus Distance First, the proposed forwarder selection process was studied under the previously mentioned experimental settings. Figure 35 depicts the average CWmax values that are calculated by each vehicle (within the transmission range, R, of the sender) when they receive the safety messages. Note that the CWmax range in this case is almost between [0, 1023]. This range can be adjusted using parameters such as CWbase, k, . Note that the vehicles farther away from the sender (but within R) have a higher probability of being chosen as a message forwarder as they have a lower CWmax. An interesting observation from the field trials is that the transmission range of OBU goes well beyond 300 meters in case of availability of line of sight.

77

Delay Per Hop (ms)

16 14 12 10 8 6 4 2 0
0

100

200

300

400

Distance (m)

Figure 36 Per-Hop Delay for Outdoor Multi-Hop Experimentation One of the crucial parameters to evaluate the performance of the proposed multi-hop algorithm is a per-hop delay, i.e., the average time it takes the safety message to progress one hop. Figure 36 shows these delay timings as the distance between the sender and the forwarding node increases. It can be observed from Figure 36 that as the distance between the sender and the forwarding nodes increases, the delay decreases sharply to a couple of milliseconds. This happens because a node closer to the boundary of the transmission range of the sender (around 300 meters) having a small CWmax value will more likely result in reducing the wait time before a rebroadcast occurs. This, in turn, results in lower overall delays.

78

End-to-End Delay (ms)

35

32.5

30

27.5

25

22.5

20

17.5

15

12.5

10

7.5

5

2.5

0

0

1

2

3

4

Number Of Hops

Figure 37 End-to-End Delay for Outdoor Multi-Hop Experimentation On the other hand, Figure 37 shows the end-to-end delay across different numbers of hops as demonstrated in the topology shown in Figure 34. As expected, as the number of hops increases, the overall delay increases. This occurs because the delay across each hop gets aggregated as the number of hops increases. However, the increase in delay is not constant at each hop. This inconsistency at different hops is due to a variety of reasons, such as varying distances between the sender and forwarder, different traffic congestion and collision rates and so on.

79

Distance Progressed (meters)

1000

900

800

700

600 Packet A
500 Packet B
400 Packet C
300 Packet D
200

100

0

1

2

3

4

Number of Hops

Figure 38 Distance Progressed by Various Safety Messages Figure 38 presents the distance progressed by different safety messages/packets (i.e., A, B, C and D) across several hops before reaching an RSU during the field trials. An expected observation in this figure is that as the number of hops increases, the distance covered by the packets also increases as distance gets aggregated at each hop. Another interesting observation is that a packet (e.g., packet D) can cover a greater total distance than another packet (e.g., packet C) in fewer hops while in the same environment. This can be attributed to the difference in per-hop distance progressed by the safety messages at each hop. In this figure, some messages (A, B and D) travelled only three hops before reaching the RSU, while message C took four hops to reach the RSU. The data captured from the field trials and experimentation has been made available for use in the continuation of this project as well as any other related project. Specifically, these research findings can be used in transportation-safety-related projects such as
80

collision avoidance, application layer radar map development, BSM exploitation to improve communication efficiency and security and so on.
81

7. Demo As part of the demonstration, a practical and usable system was designed to test the protocol in real life. A website domain was registered with the name maphak.com (not to be confused with maphack). MapHak takes the safety-related data in real-time from the RSU (which receives multi-hop safety messages from vehicles that drive by) and stores the data in a MYSQL database. Figure 39 portrays a screenshot of the MYSQL database at a particular instance of time. The website not only displays the contents of the safety message but also draws the location of the safety message initiator (sender) on a Google map, using the Google map APIs in the form of a marker.
This system offers multifold benefits; A) First, it can be used as an instantaneous emergency notification system by the
emergency response units and traffic management agencies. This type of automatic notification system can help save lives, time and property. B) The system can be used to gather large amounts of data for conducting traffic statistics and analysis. C) The system provides a two-way communication platform for DSRC equipped vehicles. D) The system can be utilized to provide live traffic information, such as expected drive time and travel speeds to the approaching vehicles.
82

FIGURE 39 MYSQL Database Containing Safety Messages Related Data
Figure 40 presents a screenshot depicting the features of the website. The website maphak.com contains a live map to display the packets as they are received by the RSU. To differentiate between the message originator, middle-hop and RSU, each have been color coded differently. The blue markers signify the original sender, the red markers define the last forwarder before the RSU, and the green marker is the location of the RSU. The top section of the website contains the fields to aid in finding any particular packet by entering its packet id. This provides a filtering feature to show which emergency took place where and the specific details related to each emergency. Figure 41 portrays a specific emergency event that occurred.
83

Figure 40 Live Map showing Multiple Emergency Events
Figure 41 Single Emergency Event
84

Maphak.com is developed using HTML in combination with CSS and PHP. PHP is used for accessing the MYSQL database. Jscript is used to populate the maps by pulling the information from the database in combination with Google APIs to display the markers on the Google map.
A C# application is developed to get information from the Arada System's RSU. This is due to the limitations of having access to programming the lower layers that are locked by Arada Systems. This application can be omitted on a unified system and could potentially be integrated into the RSU application to submit the information to the MYSQL database directly through physical connections to the RSU. Similarly, the cellular network also can be used by connecting a cell phone to the OBUs to transmit information directly from an OBU to the MYSQL database.
Several hurdles had to be overcome for a system to be functional. A working prototype is completed, but it does contain some limitations due to the DSRC device programming limitations. Currently, the only programming access is at the application layer. However, both the protocol speed and the transmission ease could be improved significantly, if the protocol is implemented in the lower layer. Furthermore, additional features could be implemented, such as security and collision detection at a much lower level. Cross layering is another important aspect in VANETs as a standard five-layer TCP model may not be ideal as the best fit.
85

8. Recommendations In this chapter, some recommendations related to the deployment of V2V and V2I technology in the state of Georgia are presented. These include but are not limited to the equipment placement, the parameter configuration, distance between devices and environmental impact, as well as a brief cost analysis. Specifically, the following section will discuss the ideal setup for the DSRC devices, both the OBUs and RSUs. Some of the important aspects that are covered in this chapter are the significance of line of sight, barrier attenuation, road topology and limited broadcast flooding, as well as data collection and storage for statistical purposes.
8.1. Antenna Placement.
For experimentation, the antennas were tested by placing them inside and outside the vehicle. Due to the lack of moisture resistance, the Arada System's DSRC devices were tested outside only during dry weather. One of the first observations is that the attenuation of the signal due to penetrating glass windshields is significant as portrayed in Figure 42. Therefore, antenna placement was tested to achieve the best possible coverage range. Additionally, due to the necessity of broadcasting messages in both forward and backward directions, the antennas should be spatially placed in a manner that is ideal for both directions. Slightly raising the antennas above the vehicles while placing them close to the center of the vehicle would be the best position. It is important to mention here that if the antennas are placed very close to the FM/AM antenna, the signal would undergo twice as much attenuation as it will experience in penetrating through the vehicle's windshield.
86

RSSI(%)

RSSI (Placing Antenna in Open Air vs. Inside Vehicle) 70

60

Open Air 50

Inside

40

Vehicle

Log. (Open

30

Air)

20

10

0

0

200

400

600

Distance(m)

Figure 42 Attenuation due to Windshield Blockage.

Furthermore, antenna placement is even more important for some specific DSRC applications; e.g., "DSRC device as a radar" is one such application that would require specific antenna placements to extract the necessary information needed to detect objects or obstructions to avoid collisions. 8.2. RSU Placement The Arada Systems Road Side Units provide coverage of around 1Km. However, during experimental field testing, the maximum RSU range was measured at approximately 900 meters. This loss in the range is due to the difficulty in finding 1 km long straight road
87

stretches that offer a line of sight. The experiments were performed at Northside Parkway, Interstate 75 (I-75), Northside Drive, the roads around the Georgia Institute of Technology campus, as well as at Lawrenceville. It is often recommended that RSUs be placed every 1 km stretch along the highway road. However, if a multi-hop communication protocol such as the one presented in this report is utilized, RSUs can be deployed after every 1.6-1.8 km on busy highways without the need of maintaining a line of sight between RSUs. The OBU units in vehicles act as relays in this case. This significantly reduces the number of RSUs required to cover the whole stretch of highways without compromising the connectivity and reachability of RSUs.
On steep roads with continuously changing altitudes, the RSU is recommended to be deployed at a much higher altitude over the roads to have the best coverage. One interesting finding is that objects such as shrubs, trees and debris affect the signal propagation. Such objects can attenuate the signal by half its strength. Therefore, placing RSUs in zones where billboards or placards can block the propagation of signals should be avoided. The RSU should be placed around 20 to 30 feet above the ground to avoid the possibility of trucks, vehicles and other objects blocking the signals.
8.3. Manufacturer
There are several manufacturers available for DSRC-compatible OBUs and RSUs. Since the devices that were used in this field-testing experiment are from Arada Systems, the recommendations are mostly centered around them. Arada Systems has developed DSRCcompatible devices and a top layer SDK that allows for application layer apps to be developed and tested. The units are equipped with the capability of an external USB
88

Bluetooth module and runs a modified Linux kernel. Arada Systems does not allow access to the platform for programming lower layers, such as the MAC layer. This is important if an algorithm is necessary to be implemented at a lower level for better performance. Additionally, some of the experimentation requires access to the physical layer for signal analysis. Again, this is something that is restricted. Lastly, the backbone operating system of the Arada boxes are far from complete, but functional with several bugs. The devices would require severe modification if a complete system is to be implemented. Additionally, the hardware may need to be upgraded to allow better thread handling if multi-thread applications are to be developed.
Choda Wireless, Savari Networks, Kapsch and ITRI are several other manufacturers that are developing different kinds of devices for the DSRC based communication. Choda Wireless and Kapsch provide reliability through testing and integration in several pilots. ITRI is developing a DSRC card that is PCI-E based, which may allow lower-level control for DSRC innovations. Savari has developed a more unified system with video output and modular control. Depending on the application, testing out other manufacturers would be recommended for easier deployment.
8.4. Deployment Requirements
First, the software must be reprogrammed on the OBUs and RSUs as a complete system, which will exploit the standard usages of BSMs and implement additional features, such as collision avoidance and Bluetooth, in addition to the implementation of the proposed multi-hop algorithm and safety/emergency message dissemination application in the MAC layer. This process requires a programming team working in collaboration with the DSRC
89

device manufacturers to get access to the device's source code for the lower physical (PHY) and MAC layers. Additionally, the RSU must be reprogrammed to have a unified packet used for TCP transmission to a local server for data collection and display. Currently, the application developed extracts the data from the RSU and uploads it to the web server to display the results on the website by using an internet hotspot. Secondly, additional manufacturers' devices should be tested and programmed to find a better set of equipment with reduced limitations. Currently, Arada Systems devices have a few limitations as threads are not controllable. Due to the lack of underlying source code, it is difficult to determine why certain threads do not close as intended. This can cause the application to fail and would require restarting. Hence, there is an additional necessity to redevelop the application as a core system application that will run at all times in the RSU and OBU.
Furthermore, the method of device installation in the vehicles has to be determined, and an embedded system has to be developed to make use of the devices. In other words, a system in which the driver can interact with the onboard unit is necessary. This system may be as straightforward as a phone application connected via Bluetooth or, more specifically, an embedded system with functions set to make use of the communication devices.
In the test-bed, DSRC devices are chosen from a vendor, Arada Systems, and all the source codes are written in accordance with the vendor-specific libraries and applications. Therefore, it is required to work with the vendor to optimize the algorithm at the MAC level and remove some technical issues from their systems, if a large scale deployment is needed. In addition, collaboration with various DSRC vendors is necessary to implement the proposed protocols in their DSRC devices to deploy a large scale multi-
90

hop connected vehicle test bed in Georgia for unified complete connected vehicle systems. This next research step requires additional intensive labor, equipment and resources.
8.5.Data Collection
To improve transportation safety, efficient storage, retrieval and analysis of vehicle-related data, such as speed, is necessary. For example, suppose a sharp curve in a highway causes more than 80% of the drivers to slow down. Due to the real-time data from the vehicles, the relevant authorities could be alerted to this defect in the road, and thus, the error in the road can be corrected. This is a simple application, but other similarly innovative applications are possible through gathering sufficient statistical data. There are two methods of data collection in DSRC devices. One is through the collection of the BSM packets that are periodically transmitted by every vehicle. This can be a challenge as an OBU's range is around 300 meters on the road. In other words, to collect such data, several RSUs need to be placed close to each other, resulting in high costs. Alternatively, an application that takes the essential BSM data of the surrounding vehicles and propagates the data further within its own BSM is possible. This concept of a virtual radar map uses the BSMs to transmit the information that a vehicle obtains from other vehicles in a multihop type scenario by just using a few optional fields. Once this information reaches an RSU, the information can be transmitted and stored permanently. Simulation work was performed to see how fast a BSM would grow in size and how quickly it can propagate the information over a 1Km span based on the number of vehicles in the zone. Figure 43 demonstrated that it is possible to develop a system that can take information about other vehicles and store it and transmit it farther with very low delays. Additional work is
91

necessary to reduce the size of the BSM by taking only the necessary information and propagating it farther. However, this demonstrates that RSUs can be placed at 1.6-1.8 Km distance apart and can still be used to collect much data of the surrounding vehicles and traffic.
An additional form of data collection is having a specific service channel used for transmitting data about the vehicles' positions, speed, movements, braking, sensory data and more to the RSUs for developing systems that can analyze such data for corrections, traffic control, safety applications, and future expansions. This system can function alongside the current standards and can be used to collect data a BSM omits.

BSM Packet Size(Bytes)

BSM Growth Based On Number Of Nodes
2500

2000

1500 1000 500

Nodes=250 Nodes=125 Nodes=75

0

0

0.05

0.1

0.15

Time(s)

Figure 43 BSM Radar Map Development Simulation

92

8.6. Cost
Since the cost is a key aspect of having the overall system implemented, a study is required to determine the exact location, labor cost, material cost, installation and maintenance costs, as well as any other miscellaneous costs. This would determine both the location and method of installation of the roadside units (RSUs) and the exact height and direction, as well as any future maintenance needed to clear the line of sight. The typical cost of an OBU is around $1,500, while that of an RSU is $3,000. However, these devices would cost significantly lower once produced and deployed on a large scale.
Since the distance covered by one RSU is just above half a mile, placing the RSU devices every one mile would provide optimum coverage, especially for a road section such as Interstate 285. Interstate 285 would be an ideal location for a pilot test to gather vehicular data and for testing possible mass implementation everywhere. The road section contains beneficial line of sight, and it would help deploy a system used for information collection and safety measures, such as, but not limited to, the vehicular speeds, locations, zones of traffic congestions, lane usages, possible detection of dangerous zones, and zones that require improvement for better traffic control. Furthermore, it could provide analysis for travel time by tracking individual vehicles from point A to point B. The time it takes to travel such a distance can be recorded as well. This average across several vehicles can provide a more accurate and adaptive travel time. In addition, a cloud-based app could provide instantaneous tracking that would allow information about a specific zone to be acquired by everyone at all times. The next step would be a pilot implementation to further the possibility of intelligent transportation. The main recommendations mentioned in this
93

report are on the basis of the research performed in this project. There are several other applications that could be developed from the research, such as connecting DSRC devices to cellular networks, using DSRC devices as detection devices for security alertness and for locating and tracking certain vehicles. The bare minimum infrastructure would first have to be installed and prepared to accommodate such applications.
94

9. Collision Avoidance Part of the project's equipment and resources are allocated to develop a new method for providing collision avoidance services to drivers in the event that the information received in a BSM is erroneous. The existing Arada System's OBUs were used in addition to the purchase of vehicle-mounted antennas, a student MATLAB license, a software-defined radio, and a new laptop for developing the digital signal processing algorithms. 9.1.Introduction Collision avoidance from the physical layer perspective in V2V networks is currently not being investigated within V2V. Instead, V2V networks rely heavily on safety message passing and the contents contained within the safety messages. Based on existing V2V protocol standards and using the allocated spectrum for V2V, the proposed framework can add to the safety benefits of V2V networks in the event that other V2V devices are misbehaving. By observing the received signal characteristics of safety messages, a driver could be alerted of a collision. The periodic broadcast of a safety message at a known transmit power is leveraged to identify events indicative of a collision. Preliminary research was conducted, and it revealed that false-alarm rates need to be lowered and detection rates need to be increased; however, the work conducted will allow future projects to design their own methods to improve upon. Accidents could be reduced and V2V enhanced to provide collision avoidance not just at the application layer, but also from the physical layer of the communication stack. By enabling V2V devices to sense the whereabouts of other transmitters regardless of the authenticity or accuracy of the data within safety messages, the reliability of V2V networks can advance toward making connected transportation safer.
95

9.2.Doppler Domain Analysis for Collision Avoidance

A collision avoidance method using the Doppler shift, published by Kihei et al. [14],

focused on tracking the Doppler shift experienced at the receiver as the sender and receiver

moved relative to each other to predict if a collision was likely. In work, a creative

architecture is proposed that employs Doppler domain analysis to determine the threat of

collision, without suggesting any changes to existing DSRC protocols. Prior to this study,

tracking the Doppler shift changes over time had not been considered for DSRC collision

avoidance applications.

A. The Doppler Effect

The Doppler Effect is a phenomenon that signals either transmitted or received from a

moving vehicle experience. As vehicles move relative to each other, the received carrier

signal containing an SM is either compressed or expanded. The carrier frequency becomes

offset (known as the Doppler shift), hereafter referred to as . The Doppler shift for

two vehicles approaching each other on a two-lane highway is featured in the equation

below, where the carrier wavelength is , S is the speed, is the bearing angle, and is

the angle of off of the bearing angle.



=

cos( )

+

cos()

(9.1)

96

B. Tracking Doppler Shift Once carrier recovery is performed, the receiver can estimate the Doppler shift, denoted as . Tracking the Doppler shift over time can provide the system with an estimation of a collision likelihood as the sender approaches, as illustrated in Figure 44. During normal travel, when the receiving vehicle, and transmitting vehicle, are far away, the angle between them is very small for a typical highway; thus, is at the highest possible value for their speeds. As and approach, the angle between them increases, and decreases. If departs the lane and maintains a constant bearing on , will not change over time.
97

FIGURE 44

Tracking Doppler Shift for Several Scenarios

C. Likelihood Estimation

FIGURE 4

By tracAkvienrgagtheeDraistetaonfcechParnoggereosfstehdePDeor-pHploepr s(Thihfteourseintigcaal svlsi.dSinigmoublasteirovnatRioensuwltisn.dow, a

collision estimator was created to map the rate of change in the Doppler shift, Drate, to an angle off of the bearing angle between VRx and VTx, to estimate the angle that the heading of VTx makes with the collision line. A timeline of the collision likelihood estimation can be seen in Figure 45A.

98

FIGURE 45 Estimating Collision Likelihood from: A) Initial Detection Far-Away and B) At End
of Decision Timer Duration Decision Timer Duration: At the first few receptions of an SM, will tend not to change much, given large transmission ranges. With being positive, the system begins a decision timer that counts down how long is allowed to stay constant before an alert is given to the driver of . If stays on the collision line when the timer expires, will remain relatively the same as initially estimated; thus, a collision is likely to happen. Sliding Observation Window: The observation window captures measurements from successive receptions of SMs at the beaconing rate and is represented as . The observation window is how far back in sample time the system will go to estimate the rate of change of . The derivative of those samples over sample time estimates the slope and denoted as , which is then averaged to estimate the Doppler change rate, .
99

Mapping Function: The mapping function relates to the to the angle that the

heading is off from the collision line. The function is initially chosen as a side-parabola

that

ranges

from

0

to

2

,

because

of

preliminary

results

from

this

study

modeling

versus reveal a parabolic relationship.

Divergent Angle Threshold: After the Doppler change rate makes an estimate, the angle is

compared to a threshold, denoted as . sets the limit as to how far heading, denoted as , needs to be off the collision line to ensure a collision will not happen. When the decision timer reaches 0, if 0 , then is assumed to still be at a collision heading with , and the driver is alerted. If > , then it is assumed that is not on a collision course with , as depicted in Figure 45B. D. Expected Performance

The expected performance of the theoretical system in detecting a collision was analyzed

in a custom MATLAB simulation. Local oscillator and sampling offset errors were introduced to simulate the errors in the measurement of the bearing angle and . The decision from the system was compared against a real collision outcome. The best

achievable detection rate was 60.87%. As shown in Figure 46, the optimum and

observation window would be about .5236 radians and 7.82 to 8.911 seconds, respectively,

to obtain a probability of detection of 43.6% and the best probability of false alarm of

41.7%. Due to the close horizontal spacing between vehicles traveling on opposite lanes,

it will be difficult for the current mapping function, which was determined from

simulations of farther spaced vehicles, to properly map the Doppler change rate to the

100

FIGURE 46 System Performance Under Multiple-Combinations heading displacement angle correctly. If the proper mapping function is not used, the system could exhibit more false-alarms.
9.3.Received Signal Strength-based Collision Avoidance The received signal strength indication (RSSI) was investigated for its capability to provide collision avoidance to drivers in V2V networks and is currently pending publication by Kihei et al. [15]. Experimental observations of RSSI during collision and no-collision outcomes were analyzed to develop the system's prediction methodology. The system is not a misbehavior detection scheme (MDS), but could complement one by independently providing real-time collision avoidance from misbehaving nodes, even if the receiver is
101

also misbehaving. The system does not use traditional RSS distance estimation, fingerprinting, or cooperative methods, which depend heavily on prior knowledge of path loss conditions. Instead, the decentralized system identifies specific trends in RSSI indicative of a collision, which circumvents the need to know the path loss. The 802.11 standard specifies that RSSI is to be measured from the preamble of received packets, but does not specify how to interpret RSSI or the maximum value. Due to this open definition, RSSI functions as a proxy of the actual signal quality or strength. An RSSI value is typically a unit-less value from an arbitrary scale decided by the radio manufacturer. The key property of RSSI is that for both LOS and NLOS conditions, RSSI is inversely proportional to the separation distance between transmitter and receiver. A. Experimental Observations An RSSI measurement campaign was conducted in a suburban environment while performing pre-crash scenarios that could result in a collision or no-collision outcomes. Figure 47 reveals the RSSI logged only by one car for both collision and no-collision outcomes. The first observation is that using the raw RSSI value is not desirable for discerning between a collision and no-collision outcome. The curvature (or shape) of the RSSI trend line reveals a more discernable characteristic across the pre-crash scenarios. For each no-collision outcome, the dilemma zone captures the conservative driver behavior of the receiver as a slower rate of increase toward the maximum RSSI value, contrasted with the collision outcome in which the driver of the receiver maintains a constant velocity, causing a faster rate of increase toward the maximum RSSI value.
102

FIGURE 47

RSSI Trend between Two Cars for: Collision (Dashed, X's) and No-Collision

(Solid, Circles) Outcomes in Three Pre-Crash Scenarios.

B. Relating vehicle dynamics to RSSI

The study discovered that RSSI must be treated as a proxy for the received signal power,

, to understand how vehicle dynamics affect what is observed in the RSSI trend. The classic power law path loss model is

() = + + + ()

(9.2)

where is the transmit power in dBm, and are antenna gains in dBi, and () is the time-dependent path loss in dB modeled as

() =

0

+

10

(

40(0))

+

(), () 0

(9.3)

This study described the relationship between vehicle dynamics and the RSSI curvature

(i.e., RSSI trend "acceleration") by taking the 2nd derivative to obtain

103

()

=

10(()2 - ()()) ()2

(9.4)

As shown by the previous equation, the path loss exponent () acts as a gain factor for the

curvature, indicating that for high path loss environments, such as NLOS, the curvature

will increase or decrease faster for the same separation distance. At large separation distances, ()2 dominates to reduce the curvature to a small value. This is analogous to

the ambiguous zones from Figure 47, in which both collision and no-collision outcomes

appear similar. In the dilemma zone, where the distance between the vehicles is shorter, the sign of () is determined by the relative velocity between the vehicles, ()2, which dominates how fast the received signal power will increase to reveal either a positive

curvature, indicating a potential collision, or negative curvature, indicating no-collision. Higher speeds will increase (), but when vehicles brake as captured by the relative acceleration, (), the curvature will decrease.

A set of criteria to predict a potential collision was then developed. Any transmitter

moving away from the receiver at a faster rate than the receiver is approaching poses no threat, indicated by () < 0. If the curvature is observed to be () = 0, such as when vehicles convoy at the same speed, a collision will not occur. Another observation is that () > 0 does not always indicate that a collision will occur; for example, during vehicle braking, () will have decreasing positive values until ()2 = ()(). Therefore, an additional condition must be placed on () to correctly predict a collision: if () > 0 and is either increasing or remaining constant, a collision will occur. This concept is the relative "jerk" between the vehicles, ().

104

9.4.Reducing False Alarms Using DOA False alarms can arise in the ambiguous zone when a car first begins receiving packets where a collision is indistinguishable from a no-collision outcome. A false alarm can also occur during the Opposite Direction scenario, as seen in Figure 47B, in which the ambiguous zone is large and the dilemma zone is small. Because vehicles often travel in the opposite lane configuration, this particular source of false alarms was further investigated.
The RSSI measurement campaign was expanded past the two-vehicle study to observe RSSI for multiple vehicles transmitting. Four vehicles were equipped with either a dome (6dBi) or whip (9dBi) omnidirectional antenna. Figure 48A depicts the experiment for a no-collision outcome, and Figure 48B depicts the collision outcome. The Rear End pre-crash scenario between Car A and Car B is observed, with one non-threating vehicle, Car D, following behind Car A in a convoy formation, while another non-threating vehicle, Car C, travels in the opposite direction in the opposite lane at high speed.
Using the direction of arrival (DOA) to segment the region of reception reduces the prediction complexity from three to one, which would allow predicting an accident for a specific region of Car A. Under NLOS, the packet reception could come from any angle; therefore, an additional stream should consider the RSSI from all DOA regions to detect large spikes above the noise of RSSI from other non-threatening vehicles. The system block diagram is presented in Figure 49.
105

FIGURE 48 RSSI trends as recorded by Car A among multiple nodes for Rear End pre-crash scenario. If DOA is available, then RSSI values from Car C could be localized to the opposite lane to suppress a false-alarm and reduce prediction complexity among
multiple nodes.
106

FIGURE 49 RSSI Collision Prediction System
A. Expected Performance The theoretical system and RSS-distance method were evaluated under various channel conditions in a custom MATLAB script. The results are reported in Figure 50. For LOS and NLOS, the system sustains a detection rate above 45% across each speed test, outperforming the RSS-distance method by reliably predicting on average over 35% more collisions. In contrast, the RSS-distance method performs poorly in LOS with a very low detection rate. Though detection and false-alarm rates are low for higher speeds, this is attributed to the SM beacon rate () not providing enough RSSI samples, indicating that a higher would be needed to provide more accurate estimations. In NLOS, the RSSdistance method suffers from very poor detection rates and high false-alarm rates. This is expected because the variance in the path loss exponent is higher for NLOS than for LOS, which increases the estimation error.
107

FIGURE 50 Performance Outcome for: A) LOS Rear End, and B) NLOS Straight Crossing
Path (Intersection).
108

10. Conclusion The objective of this research is to provide feasible solutions to disseminate emergency messages through connected vehicle V2V and V2I communications to improve transportation safety on the road. To create a reliable platform/testbed to develop and experiment with innovative networking technologies, novel algorithms are designed, simulated, implemented and tested on Georgia highways and local roadways to verify the feasibility of the proposed methods. Through the rigorous analysis and field trials, it is shown that the implemented connected vehicle technologies for V2V and V2I are effective and feasible solutions that could be deployed on Georgia highways and local roadways. In typical scenarios, the placement of an RSU in each mile is sufficient to deliver emergency messages among the vehicles in the area. By integrating and processing the IEEE 802.11p DSRC physical layer signals in a novel way, V2V and V2I safety functionality could be even further improved to provide collision avoidance services to drivers or autonomous systems on the roads.
In addition, ITS applications for collision warning and avoidance can be easily incorporated into this system. Traffic information can be also propagated through V2V and V2I connected vehicle communications that can be used to perform statistical analysis of real-world data to optimize transportation traffic flows. Human causalities and social expenses will be dramatically reduced. USDOT expects to reduce vehicular collisions through the implementation of DSRC by 76%. Furthermore, over 415 million metric tons of carbon emissions could be eliminated. These innovative technologies will deliver realtime traffic information to optimize transportation traffic flows, which will contribute to sustainable environments.
109

References: 1) J. Zhu and S. Roy, "MAC for dedicated short-range communications in intelligent
transport system," Communications Magazine, IEEE, vol. 41, no. 12, pp. 6067, 2003. 2) E. Fasolo, A. Zanella, and M. Zorzi, "An effective broadcast scheme for alert message
propagation in vehicular ad hoc networks," in ICC'06. IEEE International Conference on Communications, 2006., vol. 9. IEEE, 2006, pp. 39603965. 3) J. B. Kenney, "Dedicated short-range communications (DSRC) standards in the United States," Proceedings of the IEEE, vol. 99, no. 7, pp. 11621182, 2011. 4) F. Khan, Y. Chang, S.J. Park, and J. Copeland, "Handshaking vs. instant broadcast in VANET safety message routing," in Personal Indoor and Mobile Radio Communications (PIMRC), 2011 IEEE 22nd International Symposium on. IEEE, 2011, pp. 724729. 5) G. Korkmaz, E. Ekici, F. Ozguner, and U. Ozguner, "Urban multi-hop broadcast protocol for inter-vehicle communication systems," in Proceedings of the 1st ACM international workshop on Vehicular ad hoc networks. ACM, 2004, pp. 7685. 6) S. Bai, Z. Huang, D. Kwak, S. W. Lee, H. Oh, and J. Jung, "Vehicular multi-hop broadcasting protocol for safety message dissemination in VANETs," in Vehicular Technology Conference (VTC 2009-Fall), 2009 IEEE 70th. IEEE, 2009, pp. 15. 7) M. Li, W. Lou, and K. Zeng, "Oppcast: Opportunistic broadcast of warning messages in VANETs with unreliable links," in Mobile Adhoc and Sensor Systems, 2009. MASS'09. IEEE 6th International Conference on. IEEE, 2009, pp. 534543. 8) M. Durresi, A. Durresi, and L. Barolli, "Emergency broadcast protocol for inter-vehicle communications," in Parallel and Distributed Systems, 2005. Proceedings. 11th
110

International Conference on, vol. 2. IEEE, 2005, pp. 402406. 9) M.-R. Park, D. Kim, and S.H. Kim, "A Simple SNR Based Linear Back-Off to
Propagate Multi-hop Emergency Messages on the Distributed VANETs," in Computer Applications for Modeling, Simulation, and Automobile. Springer, 2012, pp. 3441. 10) C. Jang and J. H. Lee, "Path selection algorithms for multi-hop VANETs," in Vehicular Technology Conference (VTC 2010-Fall), 2010 IEEE 72nd. IEEE, 2010, pp. 1-5. 11) R. Voicu, H. Abbasi, H. Fang, B. Kihei, J. Copeland, and Y. Chang, "Fast and Reliable Broadcasting in VANETs using SNR with ACK Decoupling," in Int'l Conference on Communications (ICC). IEEE, 2014.
12) National Highway Traffic Safety Administration, "2011 motor vehicle crashes: overview. Report no. DOT HS-811-701," US Department of Transportation, Washington, D.C., USA, 2012.
13) L. Blincoe, A. Seay, E. Zaloshnja, T. Miller, E. Romano, S. Luchter and a. Spicer, "The economic impact of motor vehicle crashes 2000. Report no. DOT HS-809-446," National Highway Traffic Safety Administration, Washington, D.C., USA, 2002.
14) Kihei, B.; Copeland, J.A.; Yusun Chang, "Doppler domain localization for collision avoidance in VANETs by using omnidirectional antennas," in Connected Vehicles and Expo (ICCVE), 2014 International Conference on, vol., no., pp.331-337, 3-7 Nov. 2014
15) Kihei, B.; Copeland, J.A.; Yusun Chang, "Predicting Accidents in VANETs with RSS", IEEE GlobeCom 2015, San Diego, CA, USA
16) H. Yoo and D. Kim, "ROFF: Robust and Fast Forwarding in vehicular ad-hoc networks," IEEE Trans. Mobile Computing, DOI:10.1109/TMC.2014.2359664, 2014.
111

17) N. Wisitpongphan , "Routing in sparse vehicular ad hoc wireless networks" , IEEE 1. Sel. Areas Commun. , vol. 25 , no. 8 , pp.1538 -1556 , 2007
18) D. Li, H. Huang, X. Li, M. Li, and F. Tang, "A distance-based directional broadcast protocol for urban vehicular ad hoc network," in Proc. IEEE Int'l Conf. on Wireless Comm., Networking and Mobile Computing (WiCom), Shanghai, China, Sep. 2007, pp. 15201523.
19) N. Wisitpongphan, O. K. Tonguz, J. S. Parikh, P. Mudalige, F. Bai, and V. Sadekar, "Broadcast storm mitigation techniques in vehicular ad hoc networks," IEEE Wireless Commun., vol. 14, no. 6, pp. 8494, Dec. 2007.
20) H. Alshaer and E. Horlait, "An optimized adaptive broadcast scheme for inter-vehicle communication," in Proc. IEEE Vehicular Technology Conf. (VTC), Stockholm, Sweden, May 2005, pp. 28402844.
21) A. Wegener, H. Hellbruck, S. Fischer, C. Schmidt, and S. Fekete, "AutoCast: An adaptive data dissemination protocol for traffic information systems," in Proc. IEEE Vehicular Technology Conf. (VTC), Baltimore, MD, Sep. 2007, pp. 19471951.
22) R. Ahlswede, N. Cai, S.-Y. R. Li, and R. W. Yeung, "Network information flow," IEEE Trans. Inf. Theory, vol. 46, no. 4, pp. 12041216, Jul. 2000.
23) R. W. Yeung, "Network coding: A historical perspective," Proc. IEEE, vol. 99, no. 3, pp. 366371, Mar. 2011.
24) Katti, H. Rahul, W. Hu, D. Katabi, M. Medrad, and J. Crowcroft, "XORs in the air: Practical wireless network coding," IEEE/ACM Trans. Netw., vol. 16, no. 3, pp. 497 510, Jun. 2008.
112

25) Georgios Karagiannis, Onur Altintas, Eylem Ekici, Geert Heijenk, Boangoat Jarupan, Kenneth Lin, and Timothy Weil, "Vehicular Networking: A Survey and Tutorial on Requirements, Architectures, Challenges, Standards and Solutions"
26) Sooksan Panichpapiboon, and Wasan Pattara-atikom, "A Review of Information Dissemination Protocols for Vehicular Ad Hoc Networks"
27) Rex Chen, Wen-Long Jin, and Amelia Regan, "Broadcasting Safety Information in Vehicular Networks: Issues and Approaches"
28) Arada Systems, "LocoMateTM ASD with Dual DSRC Radios | On-Board Unit" Part No. ASD 205 http://www.aradasystems.com/wpcontent/uploads/2014/05/Arada_datasheet_ASD_v2.05.pdf
29) Arada Systems, "LocoMateTM RSU | Road Side Unit with NEMA Enclosure" Rev. 2.0.6 http://www.aradasystems.com/pdfs/ARADA_LocoMate_RSU_Datasheet_v2.0.pdf
30) H. Abbasi, R. Voicu, J. Copeland, and Y. Chang, "Performance Analysis and Optimization of a Contention Window based Broadcasting Algorithm in VANETs," in Proceedings of IEEE Global Communication Conference (Globecom), San Diego, CA, Dec. 2015.
31) H. Abbasi, R. Voicu, J. Copeland, and Y. Chang, "Towards fast and reliable multi-hop routing in VANETs." IEEE Transactions on Mobile Computing. 2019 Jun 17.
113

APPENDICES: Appendix A: Sample Log Data from an OBU during a Multi-Hop Field Experimentation The following log was captured during an experimental run on Highway Interstate 75 N/S Between exits 254 to 258. The experiment was run from 3:30PM to 6:30PM on December 12, 2015. The following vehicles were equipped with OBU: Billy, Brian, Amanda, Andrew, Lucian and Hamza. One RSU was placed on the side of Interstate 75N approximately mid-way between exit 255 and 256. This allowed for sufficient visibility to the OBUs from the RSU. The RSU was set up with a vehicle labeled (Chris). Messages were exchanged during the driving tests to perform multi-hop transmissions for data collection and proof of concept. The following log presents the data that was captured on one OBU installed in the vehicle named "Hamza".
114

#

Sys Time

s

SID Ver Channel TX_Power

1 1449962014 741895

5

2

172

14

2 1449962014 744808

0

1

0

0

3 1449962017 819743

5

2

172

14

4 1449962017 825773

0

1

0

0

5 1449962023 419718

5

2

172

14

6 1449962023 422773

0

1

0

0

7 1449962046 256746

5

2

172

14

8 1449962046 283808

0

1

0

0

9 1449962150 16540

5

2

172

14

10 1449962150 51690

0

1

0

0

11 1449962164 16410

5

2

172

14

12 1449962164 30771

0

1

0

0

13 1449962164 360469

5

2

172

14

14 1449962166 823801

5

2

172

14

15 1449962166 837088

5

2

172

14

16 1449962179 951759

5

2

172

14

17 1449962179 968236

0

1

0

0

18 1449962180 17634

5

2

172

14

19 1449962182 766003

5

2

172

14

20 1449962182 785772

0

1

0

0

21 1449962182 817967

5

2

172

14

22 1449962182 820404

5

2

172

14

23 1449962186 316383

5

2

172

14

24 1449962186 324770

0

1

0

0

25 1449962186 343265

5

2

172

14

26 1449962189 148385

5

2

172

14

27 1449962189 176777

0

1

0

0

28 1449962189 247952

5

2

172

14

29 1449962196 319293

5

2

172

14

30 1449962196 324198

0

1

0

0

31 1449962196 331054

5

2

172

14

32 1449962202 555068

5

2

172

14

33 1449962202 598707

0

1

0

0

34 1449962222 220045

5

2

172

14

35 1449962222 223779

0

1

0

0

36 1449962222 434705

5

2

172

14

37 1449962229 927062

5

2

172

14

38 1449962229 931776

0

1

0

0

39 1449962232 258608

5

2

172

14

40 1449962232 265800

0

1

0

0

41 1449962234 416268

5

2

172

14

42 1449962234 417817

0

1

0

0

43 1449962261 116195

5

2

172

14

PKT ID 21237 21237 19814 19814 20051 20051 12292 12292
4879 4879 10845 10845 10845 12860 12860 1899 1899 1899 8827 8827 8827 8827 24685 24685 24685 16265 16265 16265 8789 8789 8789 31607 31607 10380 10380 10380 12245 12245 4028 4028 5390 5390 14350

Lat 33.848427 33.848085 33.848596 33.848068 33.848792 33.84805 33.848112 33.847637 33.846995 33.84668 33.846798 33.846303 33.846685 33.84672 33.846293 33.84685 33.847291 33.846351 33.846223 33.847643 33.847214 33.846589 33.846337 33.848228 33.846696 33.847344 33.84879 33.847983 33.847048 33.85027 33.848426 33.850439 33.851618 33.85093 33.856113 33.854721 33.853966 33.857714 33.854905 33.858064 33.85341 33.858513 33.862343

Long -84.429142 -84.429422 -84.429193
-84.42947 -84.429253 -84.429518 -84.429371
-84.42947 -84.429073 -84.428785 -84.428872
-84.42898 -84.428769 -84.428796 -84.428997 -84.430111 -84.430286 -84.429706
-84.42945 -84.430401 -84.430259 -84.429944 -84.429692 -84.430569
-84.43002 -84.430302 -84.430675
-84.4305 -84.4302 -84.430774 -84.430633 -84.430778 -84.430827 -84.430791 -84.432159 -84.431665 -84.431429 -84.433028 -84.431715 -84.433269 -84.431253 -84.433622 -84.436984

Alt 215.5 212.7 216.2 212.4 215.6 212.2 213.1 211.7 212.1 209.7 211.9 210.3
212 211.8 212.6 214.7 214.4 214.1 213.5 215.5 215.4 214.6 213.9
218 214.1 215.9 220.6 218.1 215.5 223.7 220.5 224.9 222.9 224.9 219.4 217.3 216.1 221.9 217.2 222.5 217.4 223.4
244

Date 121215 121215 121215 121215 121215 121215 121215 121215 121215 121215 121215 121215 121215 121215 121215 121215 121215 121215 121215 121215 121215 121215 121215 121215 121215 121215 121215 121215 121215 121215 121215 121215 121215 121215 121215 121215 121215 121215 121215 121215 121215 121215 121215

Sender billy3 billy3 billy3 billy3 billy3 billy3 billy3 billy3 billy3 billy3 billy3 billy3 billy3 billy3 billy3 billy3 billy3 billy3 billy3 billy3 billy3 billy3 billy3 billy3 billy3 billy3 billy3 billy3 billy3 billy3 billy3 billy3 billy3 billy3 billy3 billy3 billy3 billy3 billy3 billy3 billy3 billy3 billy3

Forwarder Message

Alt

Distance Cwmax CWChosen Type

lucian3

RANDOM 216.3 RSSI 32 45.958113

71

1

1

hamza3

RANDOM 216.3 Type 2

amanda3 RANDOM 215.9 RSSI 29 64.001526

46

5

1

hamza3

RANDOM 215.9 Type 2

N

RANDOM 215.6 RSSI 24 86.005522

29

2

1

hamza3

RANDOM 215.6 Type 2

lucian3

RANDOM 213.9 RSSI 36 53.569378

69

23

1

hamza3

RANDOM 213.9 Type 2

brian3

RANDOM 211.9 RSSI 31 43.952482

71

34

1

hamza3

RANDOM 211.9 Type 2

N

RANDOM 211.9 RSSI 33

55.90274

60

12

1

hamza3

RANDOM 211.9 Type 2

brian3

RANDOM 211.9 RSSI 22 50.753022

49

0

1

N

RANDOM 211.8 RSSI 28 69.213637

41

37

1

lucian3

RANDOM 211.8 RSSI 47 25.379719

212

8

1

lucian3

RANDOM

213 RSSI 47 51.599086

104

10

1

hamza3

RANDOM

213 Type 2

amanda3 RANDOM

213 RSSI 40 117.37473

36

15

1

N

RANDOM 213.5 RSSI 27 180.564993

15

14

1

hamza3

RANDOM 213.5 Type 2

lucian3

RANDOM 213.5 RSSI 47 49.441249

108

49

1

amanda3 RANDOM 213.5 RSSI 41 124.488637

35

1

1

N

RANDOM 213.9 RSSI 24 225.186882

11

6

1

hamza3

RANDOM 213.9 Type 2

brian3

RANDOM 213.9 RSSI 42 177.623721

25

12

1

amanda3 RANDOM 214.3 RSSI 30 164.333023

18

17

1

hamza3

RANDOM 214.3 Type 2

lucian3

RANDOM 214.3 RSSI 44 91.120745

53

8

1

N

RANDOM 215.5 RSSI 18 361.94287

6

3

1

hamza3

RANDOM 215.5 Type 2

amanda3 RANDOM 215.5 RSSI 30 205.327478

14

3

1

lucian3

RANDOM

218 RSSI 41 131.094527

33

29

1

hamza3

RANDOM

218 Type 2

N

RANDOM 224.9 RSSI 24

589.6353

5

2

1

hamza3

RANDOM 224.9 Type 2

lucian3

RANDOM 224.9 RSSI 39 161.263987

30

23

1

brian3

RANDOM

221 RSSI 25 441.863975

6

3

1

hamza3

RANDOM

221 Type 2

amanda3 RANDOM 218.8 RSSI 29 379.206427

9

4

1

hamza3

RANDOM 218.8 Type 2

N

RANDOM 217.4 RSSI 24 607.753128

5

0

1

hamza3

RANDOM 217.4 Type 2

lucian3

RANDOM 224.7 RSSI 47 69.265539

94

20

1

44 1449962261 137774

0

1

0

45 1449962267 925424

5

2

172

46 1449962267 933770

0

1

0

47 1449962272 23676

5

2

172

48 1449962272 202696

0

1

0

49 1449962293 545764

5

2

172

50 1449962293 580691

0

1

0

51 1449962294 829048

5

2

172

52 1449962294 835775

0

1

0

53 1449962294 847428

5

2

172

54 1449962296 343070

5

2

172

55 1449962296 349300

0

1

0

56 1449962302 732921

5

2

172

57 1449962302 734800

0

1

0

58 1449962302 816679

5

2

172

59 1449962305 316311

5

2

172

60 1449962305 319953

5

2

172

61 1449962306 616336

5

2

172

62 1449962306 624771

0

1

0

63 1449962308 827369

5

2

172

64 1449962308 831770

0

1

0

65 1449962310 350217

5

2

172

66 1449962310 355208

0

1

0

67 1449962310 416444

5

2

172

68 1449962313 26695

5

2

172

69 1449962313 28799

0

1

0

70 1449962322 816268

5

2

172

71 1449962322 817800

0

1

0

72 1449962322 916122

5

2

172

73 1449962329 789660

0

1

0

74 1449962329 825972

5

2

172

75 1449962331 73669

0

1

0

76 1449962333 256665

0

1

0

77 1449962334 949660

0

1

0

78 1449962335 676660

0

1

0

79 1449962337 217662

0

1

0

80 1449962338 847817

0

1

0

81 1449962341 137778

0

1

0

82 1449962341 159105

5

2

172

83 1449962341 216280

5

2

172

84 1449962341 218684

5

2

172

85 1449962350 334663

0

1

0

86 1449962350 350180

5

2

172

87 1449962350 416189

5

2

172

0 14350 33.862848 -84.437424 246.7 121215 billy3

hamza3

RANDOM 224.7 Type 2

14 28341 33.861828 -84.436513 241.6 121215 billy3

amanda3 RANDOM 230.3 RSSI 23 271.021559

11

0 28341 33.863791 -84.438256 250.6 121215 billy3

hamza3

RANDOM 230.3 Type 2

14 28780 33.864044 -84.438482 250.8 121215 billy3

lucian3

RANDOM 234.9 RSSI 47 35.740664

183

0

28780 33.864399 -84.438791

252 121215 billy3

hamza3

RANDOM 234.9 Type 2

14 28008 33.867415 -84.441374 245.4 121215 billy3

lucian3

RANDOM 252.1 RSSI 31 117.184911

32

0 28008 33.868333 -84.441999 240.7 121215 billy3

hamza3

RANDOM 252.1 Type 2

14 10319 33.866002 -84.440187 251.4 121215 billy3

brian3

RANDOM 252.5 RSSI 20 339.37129

9

0 10319 33.868582 -84.442155 239.5 121215 billy3

hamza3

RANDOM 252.5 Type 2

14 10319 33.866559 -84.440663 250.3 121215 billy3

amanda3 RANDOM 252.5 RSSI 24 263.609667

11

14 11084 33.866313 -84.440459 250.5 121215 billy3

brian3

RANDOM 252.9 RSSI 18 343.187632

8

0 11084 33.86896 -84.442375 237.5 121215 billy3

hamza3

RANDOM 252.9 Type 2

14 18043 33.867403 -84.441354 246.2 121215 billy3

brian3

RANDOM 252.5 RSSI 23 347.342234

8

0 18043 33.870196 -84.443044 231.5 121215 billy3

hamza3

RANDOM 252.5 Type 2

14 18043 33.867986 -84.441754 243.5 121215 billy3

amanda3 RANDOM 252.5 RSSI 28 272.910325

12

14 21707 33.867978 -84.441766 243.4 121215 billy3

brian3

RANDOM 251.6 RSSI 25 347.765028

9

14 21707 33.868426 -84.442046 241.3 121215 billy3

amanda3 RANDOM 251.6 RSSI 25 291.723857

10

14

5868 33.868215 -84.441922 242.3 121215 billy3

brian3

RANDOM

251 RSSI 28 347.670429

9

0

5868 33.871053 -84.443508

228 121215 billy3

hamza3

RANDOM

251 Type 2

14 15544 33.869159 -84.442463 237.7 121215 billy3

amanda3 RANDOM 249.4 RSSI 32 276.460637

14

0 15544 33.87142 -84.443713 226.4 121215 billy3

hamza3

RANDOM 249.4 Type 2

14 10184 33.86712 -84.441138 248.4 121215 billy3

N

RANDOM 248.4 RSSI 25 578.868937

5

0 10184 33.871782 -84.443937 224.9 121215 billy3

hamza3

RANDOM 248.4 Type 2

14 10184 33.86942 -84.442594 236.5 121215 billy3

amanda3 RANDOM 248.4 RSSI 29 290.257249

12

14 16074 33.871492 -84.44373 228.3 121215 billy3

lucian3

RANDOM 245.6 RSSI 44 98.198888

60

0 16074 33.872253 -84.444271 222.9 121215 billy3

hamza3

RANDOM 245.6 Type 2

14 21435 33.869712 -84.442736 235.7 121215 billy3

N

RANDOM 235.7 RSSI 24 593.699083

5

0 21435 33.874251 -84.44613 216.3 121215 billy3

hamza3

RANDOM 235.7 Type 2

14 21435 33.871549 -84.443752 228.2 121215 billy3

brian3

RANDOM 235.7 RSSI 24 371.879903

8

0

28239 33.875404 -84.447311

218 121215 hamza3 N

RANDOM

218 Type 0

14 28239 33.871018 -84.443435 230.4 121215 hamza3 billy3

RANDOM

218 RSSI 27 604.518661

5

0 27950 33.875601 -84.44751 218.2 121215 hamza3 N

RANDOM 218.2 Type 0

0 24941 33.875985 -84.447901 218.7 121215 hamza3 N

RANDOM 218.7 Type 0

0 29901 33.876268 -84.448175 219.1 121215 hamza3 N

RANDOM 219.1 Type 0

0 26593 33.876363 -84.448261 219.2 121215 hamza3 N

RANDOM 219.2 Type 0

0 19244 33.876553 -84.448431 219.4 121215 hamza3 N

RANDOM 219.4 Type 0

0 28547 33.87683 -84.448678 219.7 121215 hamza3 N

RANDOM 219.7 Type 0

0 23602 33.877186 -84.448995 220.2 121215 hamza3 N

RANDOM 220.2 Type 0

14

23602 33.875301 -84.447196

219 121215 hamza3 amanda3 RANDOM 220.2 RSSI 30 267.257397

13

14

23602 33.876511 -84.448406

220 121215 hamza3 lucian3

RANDOM 220.2 RSSI 45 92.625013

66

14

23602 33.874928 -84.446826

219 121215 hamza3 brian3

RANDOM 220.2 RSSI 24 320.946795

9

0 23555 33.878403 -84.450101 222.7 121215 hamza3 N

RANDOM 222.7 Type 0

14 23555 33.877004 -84.448822 221.1 121215 hamza3 amanda3 RANDOM 222.7 RSSI 37 195.174251

24

14 23555 33.878182 -84.449909 221.9 121215 hamza3 lucian3

RANDOM 222.7 RSSI 43 30.280378

189

6

1

172

1

29

1

5

1

7

1

4

1

1

1

2

1

1

1

5

1

6

1

2

1

0

1

6

1

1

1

0

1

3

1

4

1

5

1

22

1

3

1

14

1

142

1

88 1449962354 696672

0

1

0

89 1449962354 727954

5

2

172

90 1449962354 736586

5

2

172

91 1449962354 738992

5

2

172

92 1449962357 704764

0

1

0

93 1449962357 737071

5

2

172

94 1449962358 53660

0

1

0

95 1449962360 357830

0

1

0

96 1449962360 416134

5

2

172

97 1449962360 418784

5

2

172

98 1449962360 932670

0

1

0

99 1449962360 943933

5

2

172

100 1449962363 857813

0

1

0

101 1449962368 174674

0

1

0

102 1449962368 239981

5

2

172

103 1449962372 728026

5

2

172

104 1449962372 752301

5

2

172

105 1449962382 652744

5

2

172

106 1449962382 857709

0

1

0

107 1449962387 223418

5

2

172

108 1449962387 226816

5

2

172

109 1449962390 316253

5

2

172

110 1449962390 319874

5

2

172

111 1449962390 322578

5

2

172

112 1449962393 835073

5

2

172

113 1449962393 837776

0

1

0

114 1449962394 515681

5

2

172

115 1449962394 519250

5

2

172

116 1449962394 616455

5

2

172

117 1449962421 816214

5

2

172

118 1449962421 844923

5

2

172

119 1449962428 654922

5

2

172

120 1449962428 713842

0

1

0

121 1449962428 715611

5

2

172

122 1449962437 856736

5

2

172

123 1449962437 944817

5

2

172

124 1449962445 215892

5

2

172

125 1449962445 230667

5

2

172

126 1449962445 331370

5

2

172

127 1449962448 915636

5

2

172

128 1449962448 944689

0

1

0

129 1449962450 923715

5

2

172

130 1449962451 21703

0

1

0

131 1449962451 116028

5

2

172

0 25968 33.878919 -84.450598 226.1 121215 hamza3 N

RANDOM 226.1 Type 0

14 25968 33.875173 -84.447074 219.5 121215 hamza3 billy3

RANDOM 226.1 RSSI 26 528.195466

14 25968 33.877742 -84.449487 221.8 121215 hamza3 amanda3 RANDOM 226.1 RSSI 31 166.172367

14 25968 33.877339 -84.449142 221.5 121215 hamza3 brian3

RANDOM 226.1 RSSI 40 221.069617

0

10024 33.879273 -84.450949

229 121215 hamza3 N

RANDOM

229 Type 0

14

10024 33.878252 -84.449951 222.9 121215 hamza3 amanda3 RANDOM

229 RSSI 33 146.117914

0 14373 33.879346 -84.45102 229.7 121215 hamza3 N

RANDOM 229.7 Type 0

0 23042 33.879656 -84.451318 232.2 121215 hamza3 N

RANDOM 232.2 Type 0

14 23042 33.875956 -84.44787 220.5 121215 hamza3 billy3

RANDOM 232.2 RSSI 31 519.854561

14

23042 33.878638 -84.450319

225 121215 hamza3 amanda3 RANDOM 232.2 RSSI 28 145.917197

0 15445 33.879725 -84.451387 232.9 121215 hamza3 N

RANDOM 232.9 Type 0

14 15445 33.876039 -84.447953 220.6 121215 hamza3 billy3

RANDOM 232.9 RSSI 30 517.833545

0

1167 33.880071 -84.451703 235.8 121215 hamza3 N

RANDOM 235.8 Type 0

0 31922 33.880517 -84.452038 239.4 121215 hamza3 N

RANDOM 239.4 Type 0

14 31922 33.879397 -84.451086 231.3 121215 hamza3 brian3

RANDOM 239.4 RSSI 42 152.329177

14

7171 33.879872 -84.451546 235.3 121215 billy3

brian3

RANDOM 222.3 RSSI 43 130.711039

14

7171 33.880764 -84.452195 241.4 121215 billy3

lucian3

RANDOM 222.3 RSSI 56 15.001048

14

4837 33.88118 -84.452431 244.2 121215 billy3

lucian3

RANDOM

228 RSSI 56 14.869585

0

4837 33.881298 -84.452507 244.4 121215 billy3

hamza3

RANDOM

228 Type 2

14

3303 33.881208 -84.452437 244.7 121215 billy3

amanda3 RANDOM 232.5 RSSI 50 35.642079

14

3303 33.881389 -84.452584 245.4 121215 billy3

lucian3

RANDOM 232.5 RSSI 59 11.588257

14 19377 33.881475 -84.452735 246.2 121215 billy3

lucian3

RANDOM 235.8 RSSI 58

9.236226

14 19377 33.881214 -84.452447 244.7 121215 billy3

brian3

RANDOM 235.8 RSSI 33 46.351723

14 19377 33.881348 -84.452529 245.3 121215 billy3

amanda3 RANDOM 235.8 RSSI 50 31.762518

14 28170 33.881397 -84.452583 245.6 121215 billy3

brian3

RANDOM 239.6 RSSI 35 40.942244

0 28170 33.881343 -84.453022 246.5 121215 billy3

hamza3

RANDOM 239.6 Type 2

14 24097 33.881487 -84.452714 246.5 121215 billy3

amanda3 RANDOM 240.2 RSSI 45

36.52031

14 24097 33.88142 -84.452609 245.8 121215 billy3

brian3

RANDOM 240.2 RSSI 26 42.009182

14 24097 33.881405 -84.452985 246.3 121215 billy3

lucian3

RANDOM 240.2 RSSI 51 17.305002

14 27500 33.881171 -84.453101 246.2 121215 billy3

N

RANDOM 246.2 RSSI 46 40.762771

14 27500 33.880913 -84.453238 247.8 121215 billy3

lucian3

RANDOM 246.2 RSSI 56

9.431495

14 23223 33.88117 -84.453103 245.5 121215 billy3

N

RANDOM 245.5 RSSI 49 40.650806

0 23223 33.880835 -84.45328 247.9 121215 billy3

hamza3

RANDOM 245.5 Type 2

14 23223 33.881031 -84.453183 246.9 121215 billy3

amanda3 RANDOM 245.5 RSSI 43 23.547239

14 17558 33.881164 -84.453107 244.6 121215 billy3

N

RANDOM 244.6 RSSI 41 56.437376

14 17558 33.880777 -84.453315 247.9 121215 billy3

lucian3

RANDOM 244.6 RSSI 55

9.349876

14 25905 33.880859 -84.453278 245.1 121215 billy3

N

RANDOM 245.1 RSSI 43 68.342194

14 25905 33.880571 -84.453409 247.3 121215 billy3

amanda3 RANDOM 245.1 RSSI 46 43.798375

14 25905 33.880319 -84.453334 247.6 121215 billy3

lucian3

RANDOM 245.1 RSSI 56 15.587802

14

5476 33.880611 -84.453401 245.6 121215 billy3

N

RANDOM 245.6 RSSI 39 88.533421

0

5476 33.879915 -84.452934 244.7 121215 billy3

hamza3

RANDOM 245.6 Type 2

14

4877 33.879896

-84.4529 244.8 121215 billy3

lucian3

RANDOM 245.7 RSSI 51 23.077705

0

4877 33.879733 -84.452745

243 121215 billy3

hamza3

RANDOM 245.7 Type 2

14

4877 33.880235 -84.453274 246.7 121215 billy3

brian3

RANDOM 245.7 RSSI 38 74.119924

6 23 23
28
7 23
7
36 43 588 593
202 842 1021 88 227 107
167 77 431 155 936 172
243 94 913 83 144 566 56
323
65

5

1

3

1

22

1

17

1

4

1

4

1

6

1

13

1

40

1

253

1

195

1

71

1

166

1

693

1

58

1

187

1

1

1

165

1

53

1

370

1

104

1

305

1

52

1

232

1

82

1

285

1

65

1

35

1

154

1

28

1

90

1

54

1

132 1449962454 120744

5

2

172

133 1449962454 124775

0

1

0

134 1449962454 415915

5

2

172

135 1449962455 616048

5

2

172

136 1449962455 632093

5

2

172

137 1449962467 123723

5

2

172

138 1449962467 142794

0

1

0

139 1449962472 115795

5

2

172

140 1449962472 117800

0

1

0

141 1449962473 915651

5

2

172

142 1449962473 932775

0

1

0

143 1449962491 816071

5

2

172

144 1449962491 824771

0

1

0

145 1449962491 844238

5

2

172

146 1449962494 37048

5

2

172

147 1449962494 39522

0

1

0

148 1449962496 740114

5

2

172

149 1449962496 751231

0

1

0

150 1449962498 915699

5

2

172

151 1449962498 919000

5

2

172

152 1449962500 717731

5

2

172

153 1449962500 725792

0

1

0

154 1449962500 735942

5

2

172

155 1449962500 744268

5

2

172

156 1449962502 815947

5

2

172

157 1449962502 822774

0

1

0

158 1449962502 838953

5

2

172

159 1449962502 841345

5

2

172

160 1449962505 716012

5

2

172

161 1449962505 725778

0

1

0

162 1449962505 742330

5

2

172

163 1449962512 625111

5

2

172

164 1449962512 628638

0

1

0

165 1449962512 645867

5

2

172

166 1449962515 216314

5

2

172

167 1449962515 220775

0

1

0

168 1449962518 653719

5

2

172

169 1449962518 664800

0

1

0

170 1449962562 431113

5

2

172

171 1449962562 433638

0

1

0

172 1449962570 136383

5

2

172

173 1449962570 163801

0

1

0

174 1449962574 435752

5

2

172

175 1449962574 442776

0

1

0

14

5626 33.880204 -84.453249 245.2 121215 billy3

N

RANDOM 245.2 RSSI 32 122.64222

32

0

5626 33.879379 -84.452366 239.4 121215 billy3

hamza3

RANDOM 245.2 Type 2

14

5626 33.879515 -84.452505

241 121215 billy3

lucian3

RANDOM 245.2 RSSI 45 31.529167

194

14 28324 33.880059 -84.45309 244.4 121215 billy3

N

RANDOM 244.4 RSSI 30 136.784479

27

14 28324 33.879378 -84.452358 239.5 121215 billy3

lucian3

RANDOM 244.4 RSSI 47 35.357971

184

14 26818 33.878765 -84.451696 232.4 121215 billy3

N

RANDOM 232.4 RSSI 36 226.441839

20

0 26818 33.877281 -84.450014 221.3 121215 billy3

hamza3

RANDOM 232.4 Type 2

14 27174 33.878111 -84.45097 225.8 121215 billy3

N

RANDOM 225.8 RSSI 28 258.394683

13

0

27174 33.876415 -84.449054

220 121215 billy3

hamza3

RANDOM 225.8 Type 2

14 24814 33.877261 -84.449987 222.2 121215 billy3

brian3

RANDOM 223.7 RSSI 32 182.054908

21

0 24814 33.87605 -84.448658 219.5 121215 billy3

hamza3

RANDOM 223.7 Type 2

14

4127

33.875 -84.447496 218.6 121215 billy3

N

RANDOM 218.6 RSSI 29 343.268006

10

0

4127 33.872625 -84.445117

219 121215 billy3

hamza3

RANDOM 218.6 Type 2

14

4127 33.874285 -84.446766 218.3 121215 billy3

brian3

RANDOM 218.6 RSSI 32 239.114784

16

14 25623 33.873668 -84.446129 217.9 121215 billy3

amanda3 RANDOM

218 RSSI 28 200.284776

17

0 25623 33.872252 -84.444786 220.8 121215 billy3

hamza3

RANDOM

218 Type 2

14 29669 33.87346 -84.445921 218.5 121215 billy3

brian3

RANDOM 217.4 RSSI 32 256.67858

15

0

29669 33.871584 -84.444298

224 121215 billy3

hamza3

RANDOM 217.4 Type 2

14 11079 33.872882 -84.445339 219.6 121215 billy3

amanda3 RANDOM 217.5 RSSI 35 241.924177

18

14 11079 33.873063 -84.445522 219.3 121215 billy3

brian3

RANDOM 217.5 RSSI 29 267.951714

13

14 26081 33.873381 -84.445779 217.9 121215 billy3

N

RANDOM 217.9 RSSI 23 344.485558

8

0 26081 33.870616 -84.443714 228.6 121215 billy3

hamza3

RANDOM 217.9 Type 2

14 26081 33.872063 -84.444654 222.1 121215 billy3

lucian3

RANDOM 217.9 RSSI 33 182.696858

22

14 26081 33.872774 -84.445244 220.4 121215 billy3

brian3

RANDOM 217.9 RSSI 39 278.273088

18

14

64 33.872973 -84.445375 219.1 121215 billy3

N

RANDOM 219.1 RSSI 24 354.185062

8

0

64 33.870196 -84.443491 230.7 121215 billy3

hamza3

RANDOM 219.1 Type 2

14

64 33.871696 -84.444385 223.7 121215 billy3

lucian3

RANDOM 219.1 RSSI 32 185.980589

21

14

64 33.872203 -84.444751 222.9 121215 billy3

amanda3 RANDOM 219.1 RSSI 31 251.509245

15

14 17793 33.872458 -84.444908 221.5 121215 billy3

N

RANDOM 221.5 RSSI 28 367.676559

9

0 17793 33.869499 -84.443125 234.3 121215 billy3

hamza3

RANDOM 221.5 Type 2

14 17793 33.871801 -84.444447 224.8 121215 billy3

amanda3 RANDOM 221.5 RSSI 38 283.402764

17

14 31000 33.870562 -84.44368 230.3 121215 billy3

amanda3 RANDOM 226.4 RSSI 25 326.007158

9

0 31000

33.8679 -84.442195 242.5 121215 billy3

hamza3

RANDOM 226.4 Type 2

14 31000 33.869498 -84.44313 234.2 121215 billy3

lucian3

RANDOM 226.4 RSSI 35 197.425188

22

14 29699 33.870116 -84.443441 232.3 121215 billy3

amanda3 RANDOM 228.1 RSSI 21 356.239867

8

0 29699 33.867241 -84.441733 245.8 121215 billy3

hamza3

RANDOM 228.1 Type 2

14

31824 33.868342 -84.442482

240 121215 billy3

lucian3

RANDOM 230.8 RSSI 30 223.715753

16

0 31824 33.866614 -84.441238 248.9 121215 billy3

hamza3

RANDOM 230.8 Type 2

14 25478 33.862001 -84.437189 243.7 121215 billy3

brian3

RANDOM 249.6 RSSI 17 519.650757

5

0 25478 33.858216 -84.433882 221.7 121215 billy3

hamza3

RANDOM 249.6 Type 2

14

9135 33.858301 -84.43396 221.6 121215 billy3

lucian3

RANDOM

243 RSSI 33 227.402447

18

0

9135

33.8565 -84.43279 217.7 121215 billy3

hamza3

RANDOM

243 Type 2

14 12457 33.857396 -84.433304 219.8 121215 billy3

lucian3

RANDOM 238.8 RSSI 33 228.817106

17

0 12457 33.855493 -84.432357 216.2 121215 billy3

hamza3

RANDOM 238.8 Type 2

3

1

49

1

21

1

59

1

18

1

1

1

16

1

7

1

5

1

0

1

6

1

1

1

1

1

7

1

18

1

3

1

5

1

10

1

7

1

8

1

0

1

0

1

5

1

3

1

7

1

0

1

17

1

6

1

176 1449962578 831845

5

2

172

177 1449962578 837781

0

1

0

178 1449962604 437627

5

2

172

179 1449962604 474706

0

1

0

180 1449962606 549723

5

2

172

181 1449962606 551203

0

1

0

182 1449962696 343380

5

2

172

183 1449962696 358245

0

1

0

184 1449962699 224725

5

2

172

185 1449962699 490707

0

1

0

186 1449962705 954242

5

2

172

187 1449962706 543723

0

1

0

188 1449962708 231690

5

2

172

189 1449962708 235791

0

1

0

190 1449962708 315458

5

2

172

191 1449962710 351964

5

2

172

192 1449962710 376775

0

1

0

193 1449962710 416357

5

2

172

194 1449962710 418870

5

2

172

195 1449962710 454897

5

2

172

196 1449962713 15149

5

2

172

197 1449962713 51216

5

2

172

198 1449962715 115178

5

2

172

199 1449962715 125198

5

2

172

200 1449962717 541224

5

2

172

201 1449962717 604720

0

1

0

202 1449962717 616661

5

2

172

203 1449962717 619056

5

2

172

204 1449962717 621700

5

2

172

205 1449962719 747194

5

2

172

206 1449962719 946149

5

2

172

207 1449962722 215215

5

2

172

208 1449962722 246690

0

1

0

209 1449962722 315470

5

2

172

210 1449962724 615624

5

2

172

211 1449962724 619194

5

2

172

212 1449962724 621913

5

2

172

213 1449962726 815413

5

2

172

214 1449962726 884712

0

1

0

215 1449962727 15311

5

2

172

216 1449962728 519676

5

2

172

217 1449962728 588741

5

2

172

218 1449962730 315255

5

2

172

219 1449962730 325778

0

1

0

14 11178 33.856398 -84.43274 218.1 121215 billy3

0 11178 33.854462 -84.432018 215.1 121215 billy3

14 22379 33.850314 -84.431197 222.7 121215 billy3

0 22379 33.849057 -84.43117 220.3 121215 billy3

14 15785 33.849918 -84.431192 222.7 121215 billy3

0 15785 33.848582 -84.431119 219.1 121215 billy3

14

27387 33.833142 -84.427603

239 121215 billy3

0 27387 33.831385 -84.427512 239.2 121215 billy3

14

4553 33.831423 -84.427542 243.2 121215 billy3

0

4553 33.831253 -84.42728 240.5 121215 billy3

14

5397 33.831253 -84.427263 243.2 121215 billy3

0

5397 33.831205 -84.427196 243.3 121215 billy3

14 13632 33.832866 -84.427569 237.4 121215 billy3

0 13632 33.831204 -84.427196 243.7 121215 billy3

14 13632 33.831474 -84.427621 240.6 121215 billy3

14 23598 33.832608 -84.427608 237.1 121215 billy3

0

23598 33.831204 -84.427195

244 121215 billy3

14 23598 33.831395 -84.427499 241.2 121215 billy3

14 23598 33.83125 -84.427265 242.5 121215 billy3

14 23598 33.831574 -84.427738 239.4 121215 billy3

14 28862 33.832218 -84.427736 237.5 121215 billy3

14 28862 33.831447 -84.427593 240.2 121215 billy3

14 19442 33.83202 -84.427801 238.6 121215 billy3

14 19442 33.831251 -84.42727 242.5 121215 billy3

14

2472 33.831838 -84.427838 239.3 121215 billy3

0

2472 33.831202 -84.427194 244.7 121215 billy3

14

2472 33.831416 -84.427543 240.8 121215 billy3

14

2472 33.831378 -84.427482 241.7 121215 billy3

14

2472 33.831251 -84.427272 242.5 121215 billy3

14 32666 33.831251 -84.427275 242.8 121215 billy3

14 32666 33.831417 -84.42754 240.7 121215 billy3

14 18476 33.831622 -84.427781 240.5 121215 billy3

0 18476 33.831202 -84.427192 244.7 121215 billy3

14 18476 33.831418 -84.427537 241.1 121215 billy3

14

1421 33.831372 -84.427484 242.7 121215 billy3

14

1421 33.831252 -84.427277 242.8 121215 billy3

14

1421 33.831418 -84.427535 241.6 121215 billy3

14 21065 33.831554 -84.427722 241.2 121215 billy3

0 21065 33.831202 -84.427192 244.8 121215 billy3

14 21065 33.831419 -84.42753 242.2 121215 billy3

14 26496 33.831534

-84.4277 241.5 121215 billy3

14 26496 33.831419 -84.427527 242.9 121215 billy3

14

2741 33.831517 -84.427681 241.8 121215 billy3

0

2741 33.831202 -84.427191

245 121215 billy3

lucian3 hamza3 lucian3 hamza3 lucian3 hamza3 amanda3 hamza3 lucian3 hamza3 lucian3 hamza3 N hamza3 amanda3 N hamza3 amanda3 lucian3 brian3 N brian3 N lucian3 N hamza3 brian3 amanda3 lucian3 lucian3 brian3 N hamza3 brian3 amanda3 lucian3 brian3 N hamza3 brian3 N brian3 N hamza3

RANDOM 234.4 RSSI 31 225.219505

RANDOM 234.4 Type 2

RANDOM 219.4 RSSI 39 139.706492

RANDOM 219.4 Type 2

RANDOM 218.8 RSSI 42 148.615938

RANDOM 218.8 Type 2

RANDOM 246.4 RSSI 32 195.427438

RANDOM 246.4 Type 2

RANDOM 244.5 RSSI 53

30.68872

RANDOM 244.5 Type 2

RANDOM 238.8 RSSI 55

8.024723

RANDOM 238.8 Type 2

RANDOM 237.4 RSSI 23 187.762726

RANDOM 237.4 Type 2

RANDOM 237.4 RSSI 28 49.389651

RANDOM 237.1 RSSI 28 160.609894

RANDOM 237.1 Type 2

RANDOM 237.1 RSSI 39 35.184888

RANDOM 237.1 RSSI 53

8.239126

RANDOM 237.1 RSSI 27 64.830265

RANDOM 237.5 RSSI 41 123.390367

RANDOM 237.5 RSSI 30 45.735701

RANDOM 238.6 RSSI 41 106.782099

RANDOM 238.6 RSSI 53

8.880711

RANDOM 239.3 RSSI 45 92.352579

RANDOM 239.3 Type 2

RANDOM 239.3 RSSI 18 40.042424

RANDOM 239.3 RSSI 38

33.00432

RANDOM 239.3 RSSI 53

9.027265

RANDOM 239.6 RSSI 54

9.32443

RANDOM 239.6 RSSI 20 39.960381

RANDOM 240.5 RSSI 36 71.655044

RANDOM 240.5 Type 2

RANDOM 240.5 RSSI 22 39.879334

RANDOM

241 RSSI 33 32.915314

RANDOM

241 RSSI 53

9.614394

RANDOM

241 RSSI 22 39.732057

RANDOM 241.2 RSSI 37

62.6388

RANDOM 241.2 Type 2

RANDOM 241.2 RSSI 22 39.433098

RANDOM 241.5 RSSI 40 59.739168

RANDOM 241.5 RSSI 21 39.287185

RANDOM 241.8 RSSI 31 57.194464

RANDOM 241.8 Type 2

17
35
37
20
260
1064
16
70 21
142 969 51 43 81 50 899 66
76 146 885 885 76 63
76 124 830 76 74
77 86 77 67

5

1

34

1

0

1

8

1

255

1

560

1

3

1

26

1

16

1

57

1

572

1

29

1

31

1

34

1

16

1

345

1

55

1

0

1

99

1

583

1

714

1

9

1

30

1

26

1

61

1

285

1

10

1

64

1

9

1

43

1

24

1

9

1

220 1449962733 151409

5

2

172

221 1449962733 243262

5

2

172

222 1449962735 118683

5

2

172

223 1449962735 133326

5

2

172

224 1449962737 217686

5

2

172

225 1449962737 264063

5

2

172

226 1449962748 615283

5

2

172

227 1449962748 636776

0

1

0

228 1449962750 746369

5

2

172

229 1449962750 800692

0

1

0

230 1449962750 862765

5

2

172

231 1449962758 315149

5

2

172

232 1449962758 356728

0

1

0

233 1449962761 40702

5

2

172

234 1449962761 54148

5

2

172

235 1449962764 53726

5

2

172

236 1449962764 98701

0

1

0

237 1449962764 124838

5

2

172

238 1449962767 650377

5

2

172

239 1449962768 84707

0

1

0

240 1449962770 415289

5

2

172

241 1449962770 418960

5

2

172

242 1449962773 914981

5

2

172

243 1449962773 919773

0

1

0

244 1449962780 915583

5

2

172

245 1449962780 935761

5

2

172

246 1449962780 942158

5

2

172

247 1449962787 15060

5

2

172

248 1449962787 21774

0

1

0

249 1449962789 415124

5

2

172

250 1449962789 453700

0

1

0

251 1449962794 43675

5

2

172

252 1449962794 72706

0

1

0

253 1449962794 126879

5

2

172

254 1449962794 214966

5

2

172

255 1449962797 615204

5

2

172

256 1449962797 635779

0

1

0

257 1449962797 718655

5

2

172

258 1449962801 637660

5

2

172

259 1449962801 745171

5

2

172

260 1449962804 932631

5

2

172

261 1449962805 51815

5

2

172

262 1449962810 335175

5

2

172

263 1449962810 374709

0

1

0

14 18126 33.831512 -84.427674 242.1 121215 billy3

N

RANDOM 242.1 RSSI 35 56.421919

77

14

18126 33.831248 -84.427282

244 121215 billy3

lucian3

RANDOM 242.1 RSSI 52

9.935033

777

14

3681 33.831512 -84.427671 242.4 121215 billy3

N

RANDOM 242.4 RSSI 34 56.275539

75

14

3681 33.831371 -84.427489 243.3 121215 billy3

amanda3 RANDOM 242.4 RSSI 34 33.474571

126

14

14465 33.831513 -84.427669

243 121215 billy3

N

RANDOM

243 RSSI 31 56.343412

68

14 14465 33.831249 -84.427277 244.5 121215 billy3

lucian3

RANDOM

243 RSSI 53

9.833253

812

14 27838 33.831518 -84.427667 243.7 121215 billy3

N

RANDOM 243.7 RSSI 31 56.761776

67

0 27838 33.831204 -84.427182 245.7 121215 billy3

hamza3

RANDOM 243.7 Type 2

14 26430 33.831519 -84.427665 243.4 121215 billy3

N

RANDOM 243.4 RSSI 31 57.685802

66

0 26430

33.8312 -84.427172 245.6 121215 billy3

hamza3

RANDOM 243.4 Type 2

14 26430 33.831248 -84.427266 243.2 121215 billy3

lucian3

RANDOM 243.4 RSSI 52 10.185461

758

14 28518 33.831521 -84.427667 242.7 121215 billy3

N

RANDOM 242.7 RSSI 34 57.768727

73

0 28518 33.831204 -84.427171 244.4 121215 billy3

hamza3

RANDOM 242.7 Type 2

14

1560 33.83152 -84.427668 242.5 121215 billy3

N

RANDOM 242.5 RSSI 29 57.847635

62

14

1560 33.831245 -84.427267 243.6 121215 billy3

lucian3

RANDOM 242.5 RSSI 53 10.046536

795

14 24979 33.83152 -84.427668 242.5 121215 billy3

N

RANDOM 242.5 RSSI 27 58.349421

57

0 24979 33.831202 -84.427165 244.6 121215 billy3

hamza3

RANDOM 242.5 Type 2

14 24979 33.831246 -84.427266 243.6 121215 billy3

lucian3

RANDOM 242.5 RSSI 53 10.527607

758

14 15557 33.831247 -84.427264 243.4 121215 billy3

lucian3

RANDOM 242.7 RSSI 52 10.390679

743

0 15557 33.831201 -84.427165 244.8 121215 billy3

hamza3

RANDOM 242.7 Type 2

14

6469 33.831248 -84.427263 243.3 121215 billy3

lucian3

RANDOM 242.8 RSSI 52 10.581419

730

14

6469 33.83142 -84.427521 248.4 121215 billy3

brian3

RANDOM 242.8 RSSI 22 41.032655

74

14 30485 33.831518 -84.427672 242.8 121215 billy3

N

RANDOM 242.8 RSSI 34 59.072283

71

0 30485 33.831198 -84.427161 244.7 121215 billy3

hamza3

RANDOM 242.8 Type 2

14 25170 33.831491 -84.427638 242.9 121215 billy3

N

RANDOM 242.9 RSSI 31 77.751075

49

14 25170 33.831137 -84.427027 243.1 121215 billy3

lucian3

RANDOM 242.9 RSSI 59

12.61257

773

14 25170 33.831405 -84.427501 248.2 121215 billy3

brian3

RANDOM 242.9 RSSI 59

12.61257

773

14 13321 33.831443 -84.426671 242.1 121215 billy3

lucian3

RANDOM 243.7 RSSI 50 15.379773

470

0 13321 33.83156 -84.426582 243.2 121215 billy3

hamza3

RANDOM 243.7 Type 2

14

4630 33.831212 -84.427183

244 121215 billy3

N

RANDOM

244 RSSI 41 94.533129

56

0

4630 33.83177 -84.42641 242.4 121215 billy3

hamza3

RANDOM

244 Type 2

14 30423 33.831191 -84.426878 243.6 121215 billy3

N

RANDOM 243.6 RSSI 35 134.955352

32

0 30423 33.832197 -84.426059 241.4 121215 billy3

hamza3

RANDOM 243.6 Type 2

14 30423 33.831547 -84.426591 241.8 121215 billy3

amanda3 RANDOM 243.6 RSSI 41 87.344087

61

14 30423 33.832004 -84.426227 241.3 121215 billy3

lucian3

RANDOM 243.6 RSSI 50 26.466457

273

14

25497 33.831405 -84.426707

243 121215 billy3

N

RANDOM

243 RSSI 40 144.774167

35

0

25497 33.832476 -84.425814

241 121215 billy3

hamza3

RANDOM

243 Type 2

14

25497 33.832259 -84.426012

241 121215 billy3

lucian3

RANDOM

243 RSSI 44 30.257934

195

14

3529 33.832549 -84.425753

241 121215 billy3

lucian3

RANDOM 242.7 RSSI 60 14.320075

704

14

3529 33.831989 -84.42623 242.5 121215 billy3

brian3

RANDOM 242.7 RSSI 24 92.918151

32

14

1955 33.832712 -84.425691 241.2 121215 billy3

lucian3

RANDOM

242 RSSI 57 16.544858

551

14

1955 33.832293 -84.425986 239.8 121215 billy3

amanda3 RANDOM

242 RSSI 47 59.058623

110

14 20917 33.832253 -84.426016 241.1 121215 billy3

N

RANDOM 241.1 RSSI 30 100.283418

37

0

20917 33.833087 -84.426431

240 121215 billy3

hamza3

RANDOM 241.1 Type 2

53

1

237

1

68

1

47

1

42

1

453

1

20

1

42

1

585

1

39

1

57

1

351

1

41

1

141

1

408

1

297

1

49

1

3

1

36

1

726

1

686

1

5

1

37

1

25

1

51

1

241

1

19

1

156

1

376

1

28

1

323

1

99

1

30

1

264 1449962810 416086

5

2

172

265 1449962810 515031

5

2

172

266 1449962810 651970

5

2

172

267 1449962817 128728

5

2

172

268 1449962817 148914

0

1

0

269 1449962819 823847

5

2

172

270 1449962819 979702

0

1

0

271 1449962824 31575

5

2

172

272 1449962824 65707

0

1

0

273 1449962853 749368

5

2

172

274 1449962853 762969

0

1

0

275 1449962862 163835

5

2

172

276 1449962862 165796

0

1

0

277 1449962883 822317

5

2

172

278 1449962883 826118

5

2

172

279 1449962890 826386

5

2

172

280 1449962890 946744

0

1

0

281 1449962898 924668

5

2

172

282 1449962898 979693

0

1

0

283 1449962904 114848

5

2

172

284 1449962904 146333

5

2

172

285 1449962904 230742

5

2

172

286 1449962904 315113

5

2

172

287 1449962906 815120

5

2

172

288 1449962906 831773

0

1

0

289 1449962906 846012

5

2

172

290 1449962907 124552

5

2

172

291 1449962919 914661

5

2

172

292 1449962919 980693

0

1

0

293 1449962920 114880

5

2

172

294 1449962920 141431

5

2

172

295 1449962922 614998

5

2

172

296 1449962922 745330

5

2

172

297 1449962923 250751

5

2

172

298 1449962925 29644

5

2

172

299 1449962925 64705

0

1

0

300 1449962925 314801

5

2

172

301 1449962925 814968

5

2

172

302 1449962928 14668

5

2

172

303 1449962928 79593

5

2

172

304 1449962928 114585

5

2

172

305 1449962928 414721

5

2

172

306 1449962933 621656

5

2

172

307 1449962933 745424

5

2

172

14 20917 33.832654 -84.425691 239.6 121215 billy3

14 20917 33.832954 -84.426151 240.6 121215 billy3

14 20917 33.832532 -84.425768 240.9 121215 billy3

14 16166 33.833014 -84.42626 238.8 121215 billy3

0 16166 33.833701 -84.427103 241.7 121215 billy3

14

9709 33.833829 -84.427174 242.5 121215 billy3

0

9709 33.834084 -84.427302 243.4 121215 billy3

14 22484 33.834377 -84.427457 245.3 121215 billy3

0 22484 33.834674 -84.427606 245.8 121215 billy3

14 28619 33.837091 -84.428857 248.8 121215 billy3

0 28619 33.84012 -84.429794 239.3 121215 billy3

14 15966 33.840172 -84.429795 239.8 121215 billy3

0 15966 33.841971 -84.429815 230.7 121215 billy3

14 12861 33.845227 -84.42958 218.8 121215 billy3

14 12861 33.844517 -84.429567 220.9 121215 billy3

14

8649 33.845908 -84.429199 215.6 121215 billy3

0

8649 33.846133 -84.428966 212.8 121215 billy3

14 28370 33.846182 -84.428916 212.9 121215 billy3

0 28370 33.846444 -84.428618 212.5 121215 billy3

14 25119 33.846076 -84.429043 214.6 121215 billy3

14 25119 33.846383 -84.428677 214.6 121215 billy3

14 25119 33.846223 -84.42887 212.5 121215 billy3

14 25119 33.846308 -84.428774 212.3 121215 billy3

14 23297 33.846184 -84.428918 214.2 121215 billy3

0 23297 33.846439 -84.428614 211.1 121215 billy3

14 23297 33.846253 -84.428836 212.2 121215 billy3

14 23297 33.846309 -84.428775 212.2 121215 billy3

14

19134 33.846209

-84.42889

213 121215 billy3

0 19134 33.846434 -84.428607 210.7 121215 billy3

14 19134 33.846311 -84.428771 212.5 121215 billy3

14 19134 33.846249 -84.428838 212.6 121215 billy3

14 10849 33.846208 -84.42889 212.6 121215 billy3

14 10849 33.846384 -84.428686 215.6 121215 billy3

14 10849 33.846249 -84.428839 212.9 121215 billy3

14

5168 33.846208 -84.428889 212.4 121215 billy3

0

5168 33.846434 -84.428606

211 121215 billy3

14

5168 33.846312 -84.428767 212.6 121215 billy3

14

5168 33.84625 -84.428839 213.3 121215 billy3

14

599 33.846207 -84.428889 212.3 121215 billy3

14

599 33.846384 -84.428688 215.6 121215 billy3

14

599 33.846251 -84.428839 213.9 121215 billy3

14

599 33.846312 -84.428765 212.5 121215 billy3

14

7140 33.846204 -84.428887 211.6 121215 billy3

14

7140 33.846387 -84.428689

214 121215 billy3

amanda3 lucian3 brian3 amanda3 hamza3 lucian3 hamza3 lucian3 hamza3 N hamza3 amanda3 hamza3 lucian3 amanda3 lucian3 hamza3 amanda3 hamza3 N lucian3 brian3 amanda3 N hamza3 brian3 amanda3 N hamza3 amanda3 brian3 N lucian3 brian3 N hamza3 amanda3 brian3 N lucian3 brian3 amanda3 N lucian3

RANDOM 241.1 RSSI 31 83.553638

RANDOM 241.1 RSSI 47

29.77348

RANDOM 241.1 RSSI 18

86.88606

RANDOM 240.5 RSSI 30 109.011104

RANDOM 240.5 Type 2

RANDOM 240.6 RSSI 48 30.701467

RANDOM 240.6 Type 2

RANDOM 240.4 RSSI 53 24.958052

RANDOM 240.4 Type 2

RANDOM 248.8 RSSI 22 347.531465

RANDOM 248.8 Type 2

RANDOM 245.6 RSSI 31 199.922602

RANDOM 245.6 Type 2

RANDOM 228.2 RSSI 49 36.889038

RANDOM 228.2 RSSI 40 115.106168

RANDOM 222.5 RSSI 51 32.978732

RANDOM 222.5 Type 2

RANDOM 216.9 RSSI 38 40.051301

RANDOM 216.9 Type 2

RANDOM 214.6 RSSI 40 56.632878

RANDOM 214.6 RSSI 57

8.641858

RANDOM 214.6 RSSI 26 33.790682

RANDOM 214.6 RSSI 35

20.90644

RANDOM 214.2 RSSI 30 39.877106

RANDOM 214.2 Type 2

RANDOM 214.2 RSSI 33 29.103637

RANDOM 214.2 RSSI 38 20.724151

RANDOM

213 RSSI 42 36.157419

RANDOM

213 Type 2

RANDOM

213 RSSI 36

20.39426

RANDOM

213 RSSI 36 29.617028

RANDOM 212.6 RSSI 43 36.234352

RANDOM 212.6 RSSI 52

9.16695

RANDOM 212.6 RSSI 33 29.750178

RANDOM 212.4 RSSI 44 36.234352

RANDOM 212.4 Type 2

RANDOM 212.4 RSSI 38 20.114554

RANDOM 212.4 RSSI 34 29.673496

RANDOM 212.3 RSSI 43 36.311462

RANDOM 212.3 RSSI 55

9.388672

RANDOM 212.3 RSSI 31 29.597033

RANDOM 212.3 RSSI 37 19.978582

RANDOM 211.6 RSSI 42 36.477936

RANDOM 211.6 RSSI 53

9.347815

45 219 35 34
220
320
8
19
189 45 226
120
91 1056
96 209 93
140 233 153
222 153 157 842 137 163
240 142 157 909 129 234 151 854

10

1

212

1

4

1

19

1

145

1

29

1

4

1

1

1

142

1

16

1

112

1

51

1

43

1

508

1

15

1

152

1

15

1

41

1

164

1

62

1

204

1

84

1

150

1

239

1

125

1

31

1

33

1

52

1

62

1

763

1

58

1

131

1

107

1

495

1

308 1449962933 914446

5

2

172

309 1449962933 943465

5

2

172

310 1449962942 952454

5

2

172

311 1449962943 78603

5

2

172

312 1449962943 112567

5

2

172

313 1449962943 253927

5

2

172

314 1449962946 712983

5

2

172

315 1449962946 798691

0

1

0

316 1449962946 916617

5

2

172

317 1449962947 252047

5

2

172

318 1449962953 712903

5

2

172

319 1449962953 744810

0

1

0

320 1449962953 912789

5

2

172

321 1449962958 712861

5

2

172

322 1449962958 737824

0

1

0

323 1449962958 746045

5

2

172

324 1449962959 19733

5

2

172

325 1449962962 134612

5

2

172

326 1449962962 712705

0

1

0

327 1449962967 128666

5

2

172

328 1449962967 176688

0

1

0

329 1449962967 213877

5

2

172

330 1449962972 912455

5

2

172

331 1449962972 931781

0

1

0

332 1449962973 12751

5

2

172

333 1449962973 212421

5

2

172

334 1449962978 112689

5

2

172

335 1449962978 120026

5

2

172

336 1449962978 212674

5

2

172

337 1449962981 712894

5

2

172

338 1449962981 791702

0

1

0

339 1449962981 919211

5

2

172

340 1449962982 21689

5

2

172

341 1449962987 315881

5

2

172

342 1449962987 324120

5

2

172

343 1449962987 513074

5

2

172

344 1449962991 128672

5

2

172

345 1449962991 131225

0

1

0

346 1449962991 312814

5

2

172

347 1449962991 412605

5

2

172

348 1449962994 55545

5

2

172

349 1449962994 67774

0

1

0

350 1449962994 221711

5

2

172

351 1449962996 712824

5

2

172

14

7140 33.846314 -84.428763 212.5 121215 billy3

14

7140 33.846253 -84.428837 214.1 121215 billy3

14 21531 33.846199 -84.428888 210.7 121215 billy3

14 21531 33.846391 -84.428687 212.5 121215 billy3

14 21531 33.846318 -84.428766 213.1 121215 billy3

14 21531 33.846247 -84.428831 214.1 121215 billy3

14 25657 33.846199 -84.428888 210.5 121215 billy3

0 25657 33.846428 -84.428603 214.4 121215 billy3

14 25657 33.846321 -84.428766 213.4 121215 billy3

14 25657 33.846246 -84.428829 213.9 121215 billy3

14 22245 33.846234 -84.42885 210.6 121215 billy3

0

22245 33.846711 -84.428521

213 121215 billy3

14

22245 33.846442 -84.428627

213 121215 billy3

14

8596 33.846438 -84.428616 210.4 121215 billy3

0

8596 33.846986 -84.428798 212.3 121215 billy3

14

8596 33.84689 -84.428693 211.4 121215 billy3

14

8596 33.846558 -84.428508 212.3 121215 billy3

14 25081 33.847111 -84.428929 211.6 121215 billy3

0

25081 33.847241 -84.429046

212 121215 billy3

14

876 33.846912 -84.428729 210.2 121215 billy3

0

876 33.847586 -84.429329 211.9 121215 billy3

14

876 33.847453 -84.429231 211.8 121215 billy3

14 22375 33.847301 -84.429108 210.7 121215 billy3

0

22375 33.847963

-84.42956

212 121215 billy3

14 22375 33.847575 -84.429309 211.9 121215 billy3

14 22375 33.847469 -84.429235 211.8 121215 billy3

14

2492 33.848296 -84.429765 213.6 121215 billy3

14

2492 33.847868 -84.429492 212.2 121215 billy3

14

2492 33.84779 -84.429451

212 121215 billy3

14

6276 33.847816 -84.429484 211.3 121215 billy3

0

6276 33.848101 -84.429262 214.2 121215 billy3

14

6276 33.847928 -84.429536 212.2 121215 billy3

14

6276 33.848006 -84.429529 212.3 121215 billy3

14 21643 33.847977 -84.429551 211.6 121215 billy3

14 21643 33.848877 -84.429998 216.7 121215 billy3

14

21643 33.848089

-84.42932

214 121215 billy3

14 11105 33.848028 -84.429515 212.3 121215 billy3

0 11105 33.848217 -84.428847 216.3 121215 billy3

14 11105 33.848095 -84.429297 214.5 121215 billy3

14 11105 33.848131 -84.429178 214.8 121215 billy3

14

62 33.848871 -84.429984 217.6 121215 billy3

0

62 33.848249 -84.428696 216.7 121215 billy3

14

62 33.848172 -84.429084 215.1 121215 billy3

14 28396 33.848863 -84.429973 217.8 121215 billy3

amanda3 brian3 N lucian3 amanda3 brian3 N hamza3 amanda3 brian3 N hamza3 amanda3 N hamza3 lucian3 brian3 lucian3 hamza3 N hamza3 lucian3 N hamza3 amanda3 brian3 lucian3 amanda3 brian3 N hamza3 brian3 amanda3 N lucian3 amanda3 N hamza3 brian3 amanda3 lucian3 hamza3 amanda3 lucian3

RANDOM 211.6 RSSI 35 19.760231

RANDOM 211.6 RSSI 31 29.377433

RANDOM 210.7 RSSI 46 36.532372

RANDOM 210.7 RSSI 56

8.69403

RANDOM 210.7 RSSI 38 19.312368

RANDOM 210.7 RSSI 35 29.042808

RANDOM 210.5 RSSI 38 36.598647

RANDOM 210.5 Type 2

RANDOM 210.5 RSSI 40 19.175423

RANDOM 210.5 RSSI 22 29.628077

RANDOM 210.6 RSSI 39

58.6019

RANDOM 210.6 Type 2

RANDOM 210.6 RSSI 49 31.452806

RANDOM 210.4 RSSI 39 63.170723

RANDOM 210.4 Type 2

RANDOM 210.4 RSSI 52 14.412373

RANDOM 210.4 RSSI 36 54.575275

RANDOM 210.2 RSSI 55 12.142973

RANDOM 210.2 Type 2

RANDOM 210.2 RSSI 45 93.146055

RANDOM 210.2 Type 2

RANDOM 210.2 RSSI 51 17.327514

RANDOM 210.7 RSSI 46 84.569498

RANDOM 210.7 Type 2

RANDOM 210.7 RSSI 47 48.945514

RANDOM 210.7 RSSI 24 64.754716

RANDOM

211 RSSI 38 39.781047

RANDOM

211 RSSI 42 20.433164

RANDOM

211 RSSI 34 28.781996

RANDOM 211.3 RSSI 29 37.720254

RANDOM 211.3 Type 2

RANDOM 211.3 RSSI 22 31.765738

RANDOM 211.3 RSSI 42 26.807944

RANDOM 211.6 RSSI 44 49.332356

RANDOM 211.6 RSSI 29 117.382962

RANDOM 211.6 RSSI 43 24.909136

RANDOM 212.3 RSSI 33 61.436987

RANDOM 212.3 Type 2

RANDOM 212.3 RSSI 21 43.687855

RANDOM 212.3 RSSI 47 32.008379

RANDOM

213 RSSI 24

137.5055

RANDOM

213 Type 2

RANDOM

213 RSSI 45 39.754754

RANDOM 213.6 RSSI 23 143.821056

221 130 173 1015 250 150 132
270 102 85
222 79
536 83 703
65
431 74
133 46 121 270 147 95
96 206 119 30 229 66
69 204 22
153 21

120

1

91

1

122

1

798

1

99

1

101

1

81

1

163

1

38

1

31

1

119

1

24

1

69

1

20

1

538

1

44

1

227

1

17

1

38

1

28

1

67

1

247

1

112

1

72

1

13

1

64

1

11

1

21

1

159

1

1

1

31

1

100

1

8

1

42

1

16

1

352 1449962996 717355

5

2

172

353 1449962996 743303

5

2

172

354 1449963001 927636

5

2

172

355 1449963002

4693

0

1

0

356 1449963002 112732

5

2

172

357 1449963006 812897

5

2

172

358 1449963006 835836

0

1

0

359 1449963006 846682

5

2

172

360 1449963008 763964

5

2

172

361 1449963008 841948

5

2

172

362 1449963011 220678

5

2

172

363 1449963011 227773

0

1

0

364 1449963011 253820

5

2

172

365 1449963013 751234

5

2

172

366 1449963013 798688

0

1

0

367 1449963013 845743

5

2

172

368 1449963017 754419

5

2

172

369 1449963017 762236

0

1

0

370 1449963020 712765

5

2

172

371 1449963020 753777

0

1

0

372 1449963020 813022

5

2

172

373 1449963024 112392

5

2

172

374 1449963024 144813

0

1

0

375 1449963024 163828

5

2

172

376 1449963024 212385

5

2

172

377 1449963029 512630

5

2

172

378 1449963029 538771

0

1

0

379 1449963029 613694

5

2

172

380 1449963031 840767

5

2

172

381 1449963031 868721

0

1

0

382 1449963031 940287

5

2

172

383 1449963034 812828

5

2

172

384 1449963034 892705

0

1

0

385 1449963037 49457

5

2

172

386 1449963037 61795

0

1

0

387 1449963042 243682

5

2

172

388 1449963042 261800

0

1

0

389 1449963042 512619

5

2

172

390 1449963048 712705

5

2

172

391 1449963048 726116

5

2

172

392 1449963049 212350

5

2

172

393 1449963052 52630

5

2

172

394 1449963052 82697

0

1

0

395 1449963052 349292

5

2

172

14 28396 33.84817 -84.429085 215.3 121215 billy3

brian3

RANDOM 213.6 RSSI 41 47.454344

112

14 28396 33.848268 -84.429061 215.5 121215 billy3

amanda3 RANDOM 213.6 RSSI 41 43.841808

122

14

32313 33.848158 -84.429109

215 121215 billy3

N

RANDOM

215 RSSI 48 67.156714

100

0 32313 33.848318 -84.428386 217.3 121215 billy3

hamza3

RANDOM

215 Type 2

14 32313 33.848397 -84.429097 215.5 121215 billy3

brian3

RANDOM

215 RSSI 25 66.203567

47

14 19698 33.848296 -84.42906 215.8 121215 billy3

N

RANDOM 215.8 RSSI 41 68.930488

77

0 19698 33.848342 -84.42831 217.6 121215 billy3

hamza3

RANDOM 215.8 Type 2

14 19698 33.84886 -84.429994 217.8 121215 billy3

lucian3

RANDOM 215.8 RSSI 18 165.735109

18

14 13619 33.848352 -84.429082 215.7 121215 billy3

N

RANDOM 215.7 RSSI 41 72.817716

73

14 13619 33.848855 -84.429992 217.3 121215 billy3

lucian3

RANDOM 215.7 RSSI 17 166.429617

18

14 19895 33.848429 -84.429108 215.6 121215 billy3

N

RANDOM 215.6 RSSI 35 76.617007

57

0 19895 33.84836 -84.428282 218.1 121215 billy3

hamza3

RANDOM 215.6 Type 2

14 19895 33.848856 -84.42999 216.3 121215 billy3

lucian3

RANDOM 215.6 RSSI 21 166.991153

18

14 19045 33.848501 -84.429131 215.5 121215 billy3

N

RANDOM 215.5 RSSI 33

81.27068

50

0

19045 33.848373 -84.428264

218 121215 billy3

hamza3

RANDOM 215.5 Type 2

14 19045 33.848879 -84.429241 216.4 121215 billy3

amanda3 RANDOM 215.5 RSSI 34 106.263888

39

14

1121 33.848625 -84.429166 215.4 121215 billy3

N

RANDOM 215.4 RSSI 30 91.586468

40

0

1121 33.848451 -84.428196 218.2 121215 billy3

hamza3

RANDOM 215.4 Type 2

14 16498 33.84869 -84.429185 215.4 121215 billy3

N

RANDOM 215.4 RSSI 35 97.104609

45

0 16498 33.848524 -84.428152 218.3 121215 billy3

hamza3

RANDOM 215.4 Type 2

14 16498 33.849077 -84.42913 216.7 121215 billy3

amanda3 RANDOM 215.4 RSSI 29 109.193721

32

14

68 33.848757 -84.429206 215.4 121215 billy3

N

RANDOM 215.4 RSSI 36 101.186742

44

0

68 33.848566 -84.428134 218.5 121215 billy3

hamza3

RANDOM 215.4 Type 2

14

68 33.848874 -84.429944

218 121215 billy3

lucian3

RANDOM 215.4 RSSI 20 170.516404

17

14

68 33.849019 -84.429006 216.7 121215 billy3

amanda3 RANDOM 215.4 RSSI 38 94.924658

51

14 10211 33.848884 -84.429236 215.7 121215 billy3

N

RANDOM 215.7 RSSI 41 102.66043

52

0 10211 33.848731 -84.428139 218.9 121215 billy3

hamza3

RANDOM 215.7 Type 2

14 10211 33.848869 -84.429951 217.7 121215 billy3

lucian3

RANDOM 215.7 RSSI 18 167.932151

18

14

4445 33.848953 -84.429238 215.8 121215 billy3

N

RANDOM 215.8 RSSI 27 101.346171

33

0

4445 33.848788 -84.428158

219 121215 billy3

hamza3

RANDOM 215.8 Type 2

14

4445 33.849011 -84.428769 216.6 121215 billy3

amanda3 RANDOM 215.8 RSSI 31 61.594357

62

14 32512 33.849012 -84.428769 216.4 121215 billy3

amanda3 RANDOM 215.8 RSSI 41 55.709831

96

0 32512 33.848876 -84.428188 219.1 121215 billy3

hamza3

RANDOM 215.8 Type 2

14 11115 33.849012 -84.428771 216.2 121215 billy3

amanda3 RANDOM

216 RSSI 33 51.926301

78

0

11115 33.848946 -84.428214

219 121215 billy3

hamza3

RANDOM

216 Type 2

14

1943 33.849034 -84.429041 216.3 121215 billy3

N

RANDOM 216.3 RSSI 35 72.581355

60

0

1943 33.849056 -84.428255 218.9 121215 billy3

hamza3

RANDOM 216.3 Type 2

14

1943 33.849011 -84.428771 215.9 121215 billy3

amanda3 RANDOM 216.3 RSSI 49 47.492345

147

14 27454 33.849047 -84.428944 216.5 121215 billy3

N

RANDOM 216.5 RSSI 36 47.808436

94

14

27454 33.848875 -84.429944

217 121215 billy3

lucian3

RANDOM 216.5 RSSI 19 141.455397

21

14

27454 33.849011 -84.428774

217 121215 billy3

amanda3 RANDOM 216.5 RSSI 50 32.234015

224

14 28575 33.849048 -84.42894 216.4 121215 billy3

N

RANDOM 216.4 RSSI 32 47.534177

83

0 28575 33.849042 -84.428425 218.5 121215 billy3

hamza3

RANDOM 216.4 Type 2

14 28575 33.849012 -84.428773 216.7 121215 billy3

amanda3 RANDOM 216.4 RSSI 51 32.289587

231

11

1

93

1

74

1

29

1

20

1

2

1

55

1

15

1

6

1

17

1

38

1

33

1

0

1

40

1

20

1

30

1

13

1

48

1

25

1

11

1

25

1

11

1

77

1

8

1

15

1

141

1

56

1

17

1

90

1

27

1

96

1

396 1449963057 112380

5

2

172

397 1449963057 151735

0

1

0

398 1449963057 512614

5

2

172

399 1449963059 723671

5

2

172

400 1449963059 746824

0

1

0

401 1449963060 31452

5

2

172

14 16093 33.849048 -84.428942 216.4 121215 billy3

N

RANDOM 216.4 RSSI 31

47.8127

80

0 16093 33.849041 -84.428424 218.6 121215 billy3

hamza3

RANDOM 216.4 Type 2

14 16093 33.849013 -84.428773 216.6 121215 billy3

amanda3 RANDOM 216.4 RSSI 50

32.35926

223

14

5022 33.849047 -84.428943 216.3 121215 billy3

N

RANDOM 216.3 RSSI 32 47.997257

82

0

5022 33.84904 -84.428423 218.7 121215 billy3

hamza3

RANDOM 216.3 Type 2

14

5022 33.849013 -84.428772 216.5 121215 billy3

amanda3 RANDOM 216.3 RSSI 50 32.348764

223

37

1

139

1

21

1

81

1

Appendix B: Author's Related Publications & Posters 1. R. Voicu, H. Abbasi, H. Fang, B. Kihei, J. Copeland and Y. Chang, "Fast and Reliable
Broadcasting in VANETs using SNR with ACK Decoupling," IEEE International Conference on Communications (ICC), June 2014. 2. H. Abbasi, R. Voicu, J. Copeland, and Y. Chang, "Performance Analysis and Optimization of a Contention Window-based Broadcasting Algorithm in VANETs," in Proceedings of IEEE Global Communication Conference (Globecom), San Diego, CA, Dec. 2015. 3. B. Kihei, J. Copeland, and Y. Chang, "Improved 5.9GHz V2V Short Range Path Loss Model." the IEEE MASS (International Conference on Mobile Ad hoc and Sensor Systems), Dallas, TX, Oct. 2015. 4. B. Kihei, J. Copeland, and Y. Chang, "Design Considerations for Vehicle-to-Vehicle IEEE 802.11p Radar in Collision Avoidance," in Proceedings of IEEE Global Communication Conference (Globecom), San Diego, CA, Dec. 2015. 5. B. Kihei, J. Copeland, and Y. Chang, "Predicting Car Collisions using RSSI," in Proceedings of IEEE Global Communication Conference (Globecom), San Diego, CA, Dec. 2015. 6. B. Kihei, J. Copeland and Y. Chang, "Doppler Domain Localization for Collision Avoidance in VANETs by Using Omnidirectional Antennas," IEEE International Conference on Connected Vehicles and Expo (ICCVE), November 2014. 7. H. Abbasi, R. Voicu, J. Copeland, and Y. Chang, "Towards fast and reliable multi-hop routing in VANETs." IEEE Transactions on Mobile Computing. 2019 Jun 17.
125