MASTER THESIS SIMULATION-BASED PERFORMANCE COMPARISONS OF GEOCAST ROUTING PROTOCOLS. Hequn Zhang, Rui Wang

Transcription

1 Master's Programme in Embedded and Intelligent Systems, 120 credits MASTER THESIS SIMULATION-BASED PERFORMANCE COMPARISONS OF GEOCAST ROUTING PROTOCOLS Hequn Zhang, Rui Wang Embedded and Intelligent Systems, 30 credits Halmstad

2

3 Simulation-based Performance Comparisons of Geocast Routing Protocols Master Thesis in Embedded and Intelligent Systems IDE1410 School of Information Science, Computer and Electrical Engineering Halmstad University Box 823, S Halmstad, Sweden June 2014 c 2014 Hequn Zhang, Rui Wang All Rights Reserved

4 Simulation-based Performance Comparisons of Geocast Routing Protocols Cover page picture: 2

5 Preface This thesis is an important milestone in our studies. Many people have helped us in several ways to achieve it, but foremost we would like to thank our supervisor, Prof. Tony Larsson, for his constant support and guidance during the entire work of this thesis. We are indebted to him for his creative ideas about our research work and his kind help. Without his insight and ideas, this research work would not have come to accomplishment. We would also like to thank him for his extremely helpful and insightful discussion on this research work. Many thanks to Carl Bergenhem who works at qamcom company in Sweden. He gave us a lot of suggestions at the beginning of this thesis. We are also grateful to Dr. Marcus Larsson, for his agreement to be our opponent of our thesis defence and his very valuable suggestions and comments about our thesis work. A special thanks to Isabel Barradell, a British teacher, who gave lots of advices about the grammar issues of our thesis. Many thanks to Thomas Lithen. With his kind help, we get an office room in Halmstad university to finish our research work. We really appreciate his help. Thanks to our best friend, Fei Xu, who is also studying in Halmstad university. He is very interested in our thesis work. We discussed lots of aspects about this research work together. Finally, we would like to thanks all friends and our families for all support and patience. Hequn Zhang, Rui Wang Halmstad University, June 19,

6 Simulation-based Performance Comparisons of Geocast Routing Protocols Abstract Intelligent Transportation System (ITS) is the main research domain for making road transport safer and more comfortable. For the sake of increasing the benefits of ITS, projects about Inter-Vehicle Communication (IVC) system have been proposed to make communications among vehicles possible, to exchange traffic information and avoid accidents. In order to create communication network among vehicles or between vehicles and infrastructure, Vehicular Ad hoc Networks (VANETs) has been proposed. Many applications in VANETs need to send messages to vehicles within a specific geographic region. This behavior is called geocast and this specific geographic region is called the Zone of Relevance (ZOR). Some routing protocols which are related to Geocast have been proposed in literature for VANETs. So it is significant to evaluate and compare the performance of these known Geocast routing protocols. In this thesis, categories of the routing protocols, as well as communication forwarding schemes are introduced. The routing protocols in VANETs are also summarized and compared. In order to evaluate the performance of these protocols, the evaluation methods are proposed and then a Geocast routing simulator is designed and used to simulate the Geocast network environment and several Geocast routing protocols. 4

7 CONTENTS Contents Preface 3 Abstract 4 1 Introduction Background Motivation Research Contribution Thesis Organization Literature Review Categories of the Routing Protocols in VANETs Topology-based Routing Protocols Position-based Routing Protocols Cluster-based Routing Protocols Geocast-based Routing Protocols Broadcast-based Routing Protocols Infrastructure-based Routing Protocols Communication Forwarding Schemes Unicast Geocast Broadcast Geocast Routing Protocols in VANETs Position based Routing Protocols Region based Routing Protocols Comparison of Routing Protocols Basic Features Comparison of Position based Routing Protocols Basic Features Comparison of Region based Routing Protocols Comparison of Simulation Parameters and Performance metrics

8 Simulation-based Performance Comparisons of Geocast Routing Protocols 3 Methodology Road Traffic Environment City Model Vehicle Model Geocast Network Simulation Simulation Initialization Traffic State Management Event Management Geocast Routing Processing Data Collection Management Evaluation Methods Packet Delivery Time Packet Delivery Ratio Geocast Routing Simulator Road Traffic Environment Generator Geocast Network Simulation System Vehicle State Module Traffic State Management Module Collision Warning Application Module Vehicle Density Monitor Module Event Management Module Geocast Network Layer Module Data Collection Management Module Geocast Routing Protocols Statistical Analysis and Comparison Tools Performance Evaluation Simulation Environment Configurations Road Traffic Environment Configuration Geocast Network Simulation Configuration Simulation Scenario Planning Results Analysis Vehicle Density Zone of Relevance/Zone of Forwarding Building Distance

9 CONTENTS 6 Conclusions And Future Works Conclusions Future Works Bibliography 57 7

10 Simulation-based Performance Comparisons of Geocast Routing Protocols List of Figures 2.1 Unicast forwarding scheme [26] Geocast forwarding scheme [26] Broadcast forwarding scheme [26] Greedy forwarding [11] Restricted Greedy Routing in the area of a junction [17] Logical grids used to partition a physical space [3] The Side Length of Grids: d is determined by d = r 2 2 [3] Zone Route Request (ZRREQ) message (flooded from the originator (source) vehicle) [12] Zone Route Reply (ZRREP) message (unicasted the one-hop neighbors from where the ZRREQ was first received) [12] A straight road scenario with distance-based backoff System model [23] Geocast Routing Simulation Flowchart Road Network Topology Length and Type of Road An Example of Traffic Light at Intersection Length of Vehicle and MinimumGap An Example of Route Planning Geocast Network Simulation Flowchart Simulation Initialization Flowchart An Example of Signal Blocking Traffic State Management Flowchart Number of Vehicles in City vs. Simulation Time Event Triggering Model Event Management Flowchart Geocast Routing Processing ZOR/Zone of Forwarding (ZOF) in City Model ZOR/ZOF in Highway Model

11 LIST OF FIGURES 3.17 An Example of Geocast Network Data Collection Management Flowchart Geocast Routing Simulator Structure and Components of Vehicle State Module and Related as to Other Modules Structure and Components of Traffic State Management Module and Related as to Other Modules Structure and Components of Collision Warning Application Module and Related as to Other Modules Structure and Components of Vehicle Density Monitor Module and Related as to Other Modules Structure and Components of Event Management Module and Related as to Other Modules Structure and Components of Geocast Network Layer Module and Related as to Other Modules Structure and Components of Data Collection Management Module and Related as to Other Modules State Diagram of Distributed robust Geocasting (DRG) [9] State Diagram of RObust VEhicular Routing (ROVER) In ZOR [12] State Diagram of ROVER In ZOF [12] State Diagram of Dynamic Time-stable Geocast (DTSG) [23] The Srceenshot of City Model in Simulation of Urban MObility (SUMO) The Packet Delivery Time The Packet Delivery Ratio The Packet Delivery Time The Packet Delivery Ratio The Packet Delivery Time The Packet Delivery Ratio

12 Simulation-based Performance Comparisons of Geocast Routing Protocols List of Tables 2.1 The comparison of basic features in position based routing protocols The comparison of different algorithms in position based routing protocols The comparison of basic features in region based routing protocols The comparison of different algorithms in region based routing protocols Comparison of simulation parameters for position based routing protocols Comparison of simulation parameters for region based routing protocols Performance metrics of position based routing protocols Performance metrics of region based routing protocols Signals and Descriptions of Traffic Light [6] Vehicle Types Parameters of Vehicle Running Information and State The Collecting Parameters Event Parameters Setup Geocast Routing Protocols Parameters Setup The Simulation Scenarios and Values

13 Abbreviations Abbreviations A-STAR Anchor-Based Street and Traffic Aware Routing. 9, DGRP Directional Greedy Routing Protocol. 10, DRG Distributed robust Geocasting. ix, 13, 18 20, 42, 43, 49 51, 55 DTSG Dynamic Time-stable Geocast. ix, 15, 16, 18 20, 46, 47, 50, 51, 55 GPCR Greedy Perimeter Coordinator Routing. 9, GPGR Grid-based Predictive Geographical Routing. 10, 11, GPS Global Positioning System. 2, 17, 18 GPSR Greedy Perimeter Stateless Routing. 8, 10, GSR Geographic Source Routing. 8, ITS Intelligent Transportation System. iv, 1, 2 IVC Inter-Vehicle Communication. iv, 1, 2, 36 IVG Inter-Vehicle Geocast. 12, PDR Packet Delivery Ratio. 34, 35, 51, 52, 55 PDT Packet Delivery Time. 34, 35, 51 53, 55 PSC Potential Score Calculation. 10 RDGR Reliable Directional Greedy Routing. 10, RLS Reckoning Link Stability. 10 ROVER RObust VEhicular Routing. ix, 12, 18 20, 44 46, 49 51, 55 SUMO Simulation of Urban MObility. ix, 36 39, 48 TCP Transmission Control Protocol. 36 TE Time Efficiency. 35 TTL Time-To-Live. 39, V2I Vehicle-to-Infrastructure. 2 11

14 Simulation-based Performance Comparisons of Geocast Routing Protocols V2V Vehicle-to-Vehicle. 2, 21, 36 VANETs Vehicular Ad hoc Networks. iv, 2 6, 16, 26, 55 Veins Vehicles in Network Simulation. 36 VIN Vehicle Identification Number. 30, 32, 39 41, 44, 45 WAVE Wireless Access in Vehicular Environments. xiii WLAN Wireless Local Area Network. xiii XML Extensible Markup Language. 36, 47 ZOA Zone of Approaching. 15, 19 ZOF Zone of Forwarding. viii, ix, 4, 6, 12, 14, 15, 19, 26, 28, 32 34, 39 46, 49 51, 56 ZOR Zone of Relevance. iv, viii, ix, 3, 4, 6, 12 16, 19, 26, 28, 32 35, 39 46, 49 51, 56 ZRREP Zone Route Reply. viii, 12, 13, 19 ZRREQ Zone Route Request. viii, 12, 13, 19 12

15 Nomenclature Nomenclature D vi The distance between vehicle and intersection. 29 L road The length of road. 23 M axret x The maximum retransmission times. 44 N r The number of nodes that receive the packet. 35 N s The number of nodes that are supposed to receive the packet. 35 Speed max The maximum speed limitation. 23 T ype road The type of road. 23 W lane The Width of the lane. 23 NUM edge The number of edges. 23 NUM entrance/exit The number of entrance/exit nodes. 22 NUM hor The number of horizontal roads. 22, 23 NUM intersection The number of intersection nodes. 22 NUM lane The number of lanes. 23 NUM ver The number of vertical roads. 22, 23 Offset event The offset value of the triggering event. 29 r event The radius of the event area. 29 IEEE A IEEE standard for Wireless Access in Vehicular Environments (WAVE) Multi-channel Operation. 36 IEEE p A draft standard intended to support Wireless Local Area Network (WLAN). 36, 49 OMNeT++ A discrete event simulation environment

16 CHAPTER 1. INTRODUCTION 1 Introduction 1.1 Background In many countries, traffic conditions have become a large and growing problem because of the increasing number of vehicles. Road transport plays a vital role in society and has an important impact on the quality of human life, besides, people spend countless hours in car queues every day, it is hence understandable that the majority of research is concerned with making road transport safer and more comfortable. ITS have become the main domain of these researches which are designed to enhance transportation safety by using advanced communication technologies and facilities [9]. To increase the benefits of ITS, research projects about IVC systems have been focused on this subject for many years, and the objective of these projects is to make vehicles communicate with each other or with infrastructure along the road in order to exchange traffic information and avoid accidents. The applications areas of IVC include [9]: Safety Application: collision warning system, emergency vehicle notification. Traffic Control Application: traffic monitoring, traffic control, route planning. Driver Assistance: platoon formation and maintenance, merging assistance. Miscellaneous: localized advertisements, instant messaging, interactive gaming. The safety and traffic control applications are two categories that attract lots of attention, since they have considerable influence on road transport. When the sight of drivers is disturbed by other vehicles or by natural factors like sunlight or fog, a collision warning system can inform drivers in order to avoid accidents. When an emergency vehicle such as an ambulance needs a clear path to pass, an emergency vehicle notification application can warn other vehicles to give way to those emergency vehicles. A good traffic control and monitoring system can make drivers more comfortable by using real-time notification of traffic congestion to let drivers choose a better route in order to arrive at their destination. To achieve these applications, an IVC system should solve the following challenges [9]. Reliability: the system needs to be reliable enough to serve the safety applications. Low delay: the system needs to serve safety applications with low delay. Robust Architecture: the system needs to be robust enough to withstand high node mobility, frequent topology changes and temporary network fragmentation. High Throughput: traffic control, driver assistance and some other applications can generate considerable packet traffic requiring high throughput. 1

17 Simulation-based Performance Comparisons of Geocast Routing Protocols Scalability: the system needs to be able to scale for thousands of nodes and several square miles. Infrastructure Independence: the system: Vehicle-to-Vehicle (V2V) needs to try not to rely on external infrastructures for its operation. A couple of years ago, the term VANETs was introduced and attracted attention from the automotive industry and research community. It is basically formed by V2V communication and Vehicle-to-Infrastructure (V2I) communication [23]. V2I can offer real-time information on the road traffic conditions and other services which interest drivers, such as the weather, via communication with roadside infrastructure, while V2V can be used for providing information concerned with traffic conditions and vehicle accidents by wireless IVC. In V2V communication, vehicles build wireless connections through multihop communication without any fixed infrastructure [3]. VANETs has its unique characteristics such as high node velocity, a rapidly changing network topology and resources like location information from Global Positioning System (GPS), so creating high performance, highly scalable and secure VANETs technologies is an extraordinary challenge to the wireless research community [9]. The high speed of vehicles causes network fragmentation and changing network topology creates new challenges in VANETs, moreover, the density of vehicles and the connection of the network change quite often because of traffic conditions and environments [23]. With a growing development of technologies and facilities, wireless communication plays a considerably vital role in ITS and VANETs can improve systems which were used before, through the utility of the GPS [23] and achieve more services that satisfy the need of modern road transport in ITS. Among these services and applications mentioned above, such as safety and traffic control applications, messages are required to be sent to a certain number of vehicles within a specific geographic region, called Geocast [9] [23] [12]. The objective of Geocast is to achieve the transmission of messages to all vehicles within a predefined geographical area with high efficiency and low time consumption. Some Geocast applications are accident warnings or information about bad road conditions, like fog or black ice, while others are normal notification services, such as weather or free parking. For instance, when a car accident happens on the highway, all vehicles within the region close to this accident will be involved and therefore there should be a road transport application to inform drivers about this accident so that they can change their route to avoid the accident. 1.2 Motivation In the last decade, there were several researches on routing protocols used to support the Geocast network. Some of them are well used in highway scenarios, while others are suitable for city scenarios and besides, the application areas of Geocast routing protocols are also different. However, it is vital to investigate and evaluate these Geocast routing protocols and find out which of them have good performance, regardless of the difference of scenarios and applications. Previously, in order to evaluate these Geocast routing protocols, the simple Flooding method is used to separately compare with them and indicate that these protocols may 2

18 CHAPTER 1. INTRODUCTION have a good performance. However, only comparing with Flooding can not give enough evidence to point out that the performance of the Geocast routing protocol is good enough. Therefore, for the sake of obtaining convincing evidence concerned with the good performance of Geocast routing protocols, it is important to compare an adequate number of them together. To achieve this purpose, a Geocast routing simulator needs to be designed, which can provide a general road traffic and Geocast network environment. Besides, sometimes, the way of defining the performance metrics used to evaluate different Geocast routing protocols is different among the simulations of different protocols. The evaluation methods should be therefore defined according to different applications. Some applications require high the reliability of routing protocols, while others need the high time efficiency. Considering this aspect of evaluation methods, when designing the evaluation methods, both the reliability and time efficiency should be taken into account. Finally, there are numerous possible factors in the real world that can affect the performance of Geocast routing protocols. These factors may include the vehicle density of the whole city and the size of the region where vehicles need to receive messages. Except for these known factors that have been discussed in several previous works, this thesis assumes that buildings in the city could be a factor which has an influence on the performance of Geocast routing protocols because these buildings could be barriers among vehicles and lead to abortive communications among them. 1.3 Research Contribution The main purpose of this thesis is to design a Geocast routing simulator which can provide a general road traffic and Geocast network environment to evaluate the performance of different Geocast routing protocols by using some appropriate methods. Thus, these Geocast routing protocols can be easily implemented and simulated, based on this simulator. During the simulation, several major factors of protocol performances can be collected by this simulator. Besides, for the sake of finding out these important factors of evaluating routing protocols, this thesis also investigates, analyzes and summarizes different routing protocols in VANETs concerned with Geocast routing protocols which include both position based routing protocols and region based routing protocols. This thesis will introduce all categories of routing protocols in VANETs and Geocast routing protocol is one of them. This kind of routing protocol is used to send messages from a source to all vehicles within a predefined geographic region. In addition, this thesis represents three different kinds of communication forwarding schemes, which are Unicast routing, Geocast routing and Broadcast routing. Furthermore, this thesis summarizes some existing Geocast routing protocols in VANETs. Their basic features, the forwarding algorithms and the performance metrics are also briefly shown and compared in tables. In this thesis, Geocast routing protocols are focused in the simulation section. Several ZOR-based Geocast routing protocols are compared in the same simulation system known as the Geocast routing simulator. This simulation system is designed to create a general Geocast network environment to satisfy different ZOR-based Geocast routing protocols, which means different ZOR-based Geocast routing protocols can use this system to be compared with each other and be evaluated. In the simulation section, in order to test this Geocast routing simulator, different ZOR-based Geocast routing protocols 3

19 Simulation-based Performance Comparisons of Geocast Routing Protocols and a ZOR/ZOF limited flooding are selected to compare and evaluate their performance through using this system. The accuracy of a protocol is important. One of the goals of Geocast routing protocols is to deliver the message to all the vehicles within a geographic region, ZOR. The first performance metric defined in simulation section is hence the packet delivery ratio and the reliability of Geocast routing protocols can be measured by it. In order to measure and analyze the time efficiency of different Geocast routing protocols, the second performance metric is the packet delivery time. To measure the impact of the protocol performances on different situations, several scenarios are selected including vehicle density, size of ZOR/ZOF and the ratio of buildings distance and road length. 1.4 Thesis Organization This thesis consists of six chapters. Chapter 1 presents an introduction to this thesis, while the other chapters are organized as follows: Chapter 2 Literature Review: This chapter introduces the categories of the routing protocols and three different communication forwarding schemes in VANETs and then summarizes different Geocast routing protocols in VANETs. These routing protocols include both position based routing protocols and region based routing protocols in the past decade. After this, these protocols are compared according to their basic features, algorithms, performance metrics and their simulation parameters used before. Chapter 3 Methodology: In this chapter, some significant methods used for simulation will be designed and explained. These methods consist of the road traffic simulation and Geocast network simulation. In addition, the performance metrics are defined to evaluate the performance of Geocast routing protocols. Chapter 4 Geocast Routing Simulator: In this chapter, the Geocast Routing Simulator is introduced. And the design of functions and structures of each component is discussed here. Besides, some known Geocast routing protocols are selected to compare and their algorithms and state diagrams are shortly shown and explained. Chapter 5 Performance Evaluation: This chapter includes the configurations of the simulation environment, the plans of the simulation scenario and the results analysis. Chapter 6 Conclusions and Future Works: This chapter summarizes the conclusions about simulation results and briefly discusses the future works. 4

20 CHAPTER 2. LITERATURE REVIEW 2 Literature Review In this chapter, different categories of routing protocols used in VANETs and their communication forwarding schemes are presented. Some known Geocast routing protocols in VANETs are also investigated and summarized. These protocols consist of both position based routing protocols and region based routing protocols. In addition, some comparisons of these protocols are summarized according to previous works by other researchers. 2.1 Categories of the Routing Protocols in VANETs Topology-based Routing Protocols Topology-based routing protocols discover the route and send data packets from a source node to a destination node according to links information within the network. These routing protocols can be further classified into proactive(table-driven) and reactive(ondemand) [13] [20] [21]. Proactive routing protocols Proactive routing protocols maintain information of all connected nodes within the network in tables. The information in these tables is shared with neighbors. All these nodes periodically exchange the knowledge of the network topology and routing tables are updated by these nodes if any change happens in this network. The advantage of proactive routing protocols is that they do not need routing discovery, but the disadvantage is that lots of bandwidth for periodic updates of the topology are consumed [13] [20] [21] [10] [28]. Reactive routing protocols Reactive routing protocols need routing discovery phase in which query packets are flooded into the network for searching the route. This phase is accomplished when this route is found. These protocols do not need periodic flooding within the network when nodes update the routing table, however flooding is used when it is demanded [20] [21] [10] [28] Position-based Routing Protocols Position-based routing protocols select the next forwarding hops by using geographical information, so each vehicle needs to know its geographical position. Packets are sent to one hop neighbor which is closest to the destination without creating and maintaining a global route between source and destination [13] [21] [10] [28] [7]. 5

21 Simulation-based Performance Comparisons of Geocast Routing Protocols Cluster-based Routing Protocols In these kind of routing protocols, vehicles can group together to form a cluster because they are close to each other and perform similar features, such as driving in the same direction with almost the same velocity. Each cluster has a cluster-head which is responsible for intra and inter-cluster communication. Intra-cluster vehicles can communicate within each cluster by using direct links and the cluster-head can broadcast packets to this cluster, while inter-cluster communication is connected through the cluster-head [21] [10] [7] Geocast-based Routing Protocols Geocast-based routing protocols are used to send messages from a single source to all vehicles which belong to a predefined region known as the ZOR. Besides, there also exists a forwarding region known as the ZOF. This region is utilized to guarantee that forwarding messages can reach the ZOR [13] [21] [10] [7] Broadcast-based Routing Protocols These kind of protocols simply use flooding to reach all vehicles within the network. Broadcasting is usually used for informing traffic, emergency, road conditions among vehicles, sending advertisements and announcements such as the weather information [13] [21] [28] [7] Infrastructure-based Routing Protocols Infrastructure-based routing protocols use fixed infrastructure nodes as relays for routing. 2.2 Communication Forwarding Schemes In VANETs, according to the different purposes of sending messages from source to destination, routing protocols can be classified into three kinds of communication forwarding schemes, Unicast, Geocast and Broadcast [26] Unicast Unicast routing is a basic communication scenario to implement point to point communication. The forwarding scheme of the Unicast is that packets need to be relayed from one source point (TX in figure 2.1) to one destination point (RX in figure 2.1) through intermediate points, see figure

22 CHAPTER 2. LITERATURE REVIEW Figure 2.1: Unicast forwarding scheme [26] Geocast Geocast routing defines a geographic region of interest where vehicles within this area should receive packets delivered from a source point and then forward them. The source sender can be located outside this geographic region of interest or within it, see figure 2.2. Figure 2.2: Geocast forwarding scheme [26] Broadcast Broadcast protocol is point to multipoint communication, which indicates that a source point sends packets to more than one destination within the network, see figure 2.3. Figure 2.3: Broadcast forwarding scheme [26] 2.3 Geocast Routing Protocols in VANETs In the past decade, several Geocast routing protocols have been proposed which include both position based routing protocols and region based routing protocols. Position based routing protocols can be used for point to point communication, while region based routing protocols can be applied to inform vehicles within a specific region. In this section, some important and representative protocols of them will be introduced and summarized Position based Routing Protocols Position based routing protocols are very basic routing protocols to implement point to point communication. Their algorithms are also basic methods which can be used and 7

23 Simulation-based Performance Comparisons of Geocast Routing Protocols extended for more complicated algorithms, so some basic and significant algorithms of them need to be discussed and summarized. Greedy Perimeter Stateless Routing (GPSR) for Wireless Networks GPSR protocol [11] is a position based routing protocol. It uses positions of routers and the destination of packets to perform packet forwarding. In order to forward packets to the destination node, this protocol only uses information pertaining to the immediate neighbors of a router. The forwarding mechanism of this protocol consists of two methods. One is known as greedy forwarding which is used wherever possible and it works by choosing a neighbor geographically closest to the destination as relay, until the destination is reached. For example, see figure 2.4, source vehicle S finds neighbor A, who is the closer to destination D, so S forwards packets to A. Figure 2.4: Greedy forwarding [11] 8 The other method, known as perimeter forwarding, is involved when greedy forwarding fails. This method makes nodes forward packets through using the long-known right hand rule, which always picks the next anticlockwise edge to traverse until the nodes return to greedy mode and forward packets to destination. The performance metrics used to evaluate this protocol are packet delivery ratio, overhead and path lengths. The definitions of them are explained as follows: Packet Delivery Success Rate: The number of application packets GPSR successfully delivers for varying values of beaconing intervals. Routing Protocol Overhead: The routing protocol overhead, measured in total number of routing protocol packets sent network-wide during the entire simulation. Optimality of path lengths taken by data packets: The number of hops beyond the ideal true shortest path length in which GPSR deliver all successfully delivered packets. Geographic Source Routing (GSR) GSR [16] is a position based routing protocol which is mainly proposed for a city environment. GSR is supported by a map of the city. In order to learn the current position of neighbors, the querying node broadcasts a position request packet. When the receiving node receives this position request, it sends back a position reply to the querying node. According to this information, the sending node can calculate a shortest path to the destination by applying Dijkstra s algorithm.

24 CHAPTER 2. LITERATURE REVIEW The performance metrics used to evaluate this protocol contain achieved packet delivery rate, bandwidth consumption, latency and number of hops, which respectively measure: Achieved packet delivery rate versus the distance between the two communication partners. Average Total Bandwidth consumption per second versus the distance. Latency for the first packet per connection versus the distance. Average number of hops depending on distance. Anchor-Based Street and Traffic Aware Routing (A-STAR) A-STAR [24] designed for a city environment is a kind of position based routing scheme. Two related works are involved in this protocol, Anchor-Based Routing and Spatial Aware Routing. A-STAR protocol combines these two works and uses a street map in order to compute a series of conjunctions where a packet must pass to reach its destination. This protocol also uses the information of city bus routes to identify an anchor path. This anchor path can be calculated through Dijkstra s algorithm. Besides, A-STAR also provides an efficient local recovery algorithm for overcoming network fragmentation. When network fragmentation happens, a new anchor path is calculated and the packet is forwarded via this new anchor path. The key performance metrics used in this protocol are Packet delivery ratio and End-to-end delay, which are defined as follows: Packet delivery ratio: The ratio of packets delivered to the destinations to those generated by sources. End-to-end delay: The average time consumed by a packet to traverse the network from its source to destination. Greedy Perimeter Coordinator Routing (GPCR) GPCR protocol [17] is a position based routing protocol and it consists of two parts, limited greedy forwarding and repair strategy. The former indicates that packets should be transmitted to a node on a junction, since junctions are the only places where actual routing decisions are made. Nodes located on a junction are called coordinators. This is illustrated in figure 2.5, where a source node S will forward packets to node A which is a coordinator on the junction. The node close to the destination is selected to forward packets if it is not a coordinator. When network fragmentation happens, the forwarding strategy is switched to the repair strategy and packets are forwarded along the street until they reach the first coordinator on the junction. This coordinator then decides the street where packets should be forwarded by using the right hand rule which means a street is chosen counterclockwise from the street on which the packets originally arrived. The performance metrics used to measure in this protocol are the achieved packet delivery rate and the number of hops, which measure: The achieved packet delivery rate versus the distance between the two communication partners. 9

25 Simulation-based Performance Comparisons of Geocast Routing Protocols Figure 2.5: Restricted Greedy Routing in the area of a junction [17] 10 The number of hops versus the distance between the two communication partners. Directional Greedy Routing Protocol (DGRP) DGRP [14] uses the position of neighbors with their velocities and directions of their movements to choose the most appropriate node as relay. The forwarding strategies of this protocol consist of greedy forwarding and perimeter forwarding, like GPSR mentioned earlier. However, this protocol uses a location prediction method to predict the position of neighbors within the beacon interval in order to get a better choice to select the next forwarding node. This protocol uses packet delivery ratio, routing overhead and throughput under different speeds and acceleration as its performance metrics. Reliable Directional Greedy Routing (RDGR) RDGR [22] is a reliable position based routing protocol. This protocol uses the movement information of vehicles, such as position, direction and speed, to compute link stability between neighbor nodes in order to select the most proper node as a relay. The strategies of this protocol contain two portions. One is called Reckoning Link Stability (RLS) which is used to identify path stability. The other is Potential Score Calculation (PSC) which is used to identify three things, the closeness of the next hop to destination, the direction of the motion of nodes and the reliability of neighbor nodes. The node with the largest PS score will be selected as relay and forward packets to the destination, since it has a higher potential to reach the destination node. The performance metric used to evaluate this protocol is packet delivery ratio and it is defined as the number of correctly received packets at the destination over the number of packets sent by the source. Grid-based Predictive Geographical Routing (GPGR) GPGR [3] uses a two-dimensional logical grid to partition the geographic area. Grids are numbered by (x,y) and each grid is a sequence square with side d, shown in figure 2.6. Each vehicle can obtain its location by GPS and has a digital street map for road information, so after it is given any geographical location, each vehicle can perform a predefined mapping from its geographical location to its grid coordinates. A vehicle

26 CHAPTER 2. LITERATURE REVIEW Figure 2.6: Logical grids used to partition a physical space [3] located in its grid can transmit data to any vehicle within its eight neighboring grids. Besides, each vehicle uses its transmission range to represent the maximum value of d, shown in figure 2.7. Figure 2.7: The Side Length of Grids: d is determined by d = r 2 2 [3] Each vehicle knows its own position, so it can compute its current grid coordinate. All these grid coordinates are stored in beacon messages. In GPGR, when a source vehicle (Vs) wants to send a message to a destination vehicle (Vd), Vs should choose the node closest to Vd as a relay node if this node is within the transmission range r of Vs. Vs can find all neighbors by a beacon message in its transmission range r and calculate the distance (D) from different neighbors to itself. Finally, it selects the node whose D is maximal as a relay. This procedure of selecting a relay vehicle is based on the future vehicle position. This future vehicle position can be calculated according to velocities and directions of vehicles. In order to evaluate this protocol, three performance metrics are used which are Local maximum rate, Packet delivery rate and Link breakage rate. 11

27 Simulation-based Performance Comparisons of Geocast Routing Protocols Region based Routing Protocols Region based routing protocols require a source vehicle to send messages to other vehicles within a specific region, however, their algorithms are quite different. For example, some of them need to send a beacon message to exchange the information of neighbors, while others do not need to; some of them need to build a multicast tree in order to send a data message, while others need to design a distance-backoff time to select relays. In this thesis, region based routing protocols are mainly focused, so it is important to summarize their algorithms here in order to select some of them to compare in the simulation section. 12 A Multicast Protocol in Ad hoc Networks Inter-Vehicle Geocast (IVG) IVG routing protocol [1] is used to inform all vehicles on the highway about any unsafe situation, such as an accident. By using this protocol, a Geocast message used for warning can be disseminated to vehicles within a specific region. The strategy for the routing of the IVG begins when an accident happens, such as a broken-down vehicle. This event vehicle, also known as the source, begins to broadcast a Geocast message in order to warn those vehicles behind it on the highway. Vehicles within the transmission range of the source receive the message and accept it if this is the first time they received it. Each receiving vehicle has to wait some time before they rebroadcast this message. This waiting time is known as defer time. If this defer time expires and if the receiving vehicle does not receive the same message from another vehicle, this receiving vehicle becomes a relay node and rebroadcasts this message to inform the vehicles behind it. The performance metric used in this protocol is multicast success, which is the percentage of informed vehicles in risk areas to the total number of vehicles in the risk areas. Reliable geographical multicast routing in Vehicular Ad hoc Networks: ROVER ROVER protocol [12] offers reliable geographical multicast. It only floods control packets within network and unicasts data packets. In this way, the efficiency and reliability can be increased potentially. With ROVER, the intention of this protocol is to transmit a message to all other vehicles within an area known as the ZOR which is defined as a rectangle. A vehicle accepts this message when it receives it, this message at the same time if this vehicle is within ZOR. However, this protocol also defined an area known as the ZOF which includes both the source and ZOR. ROVER uses two kinds of strategies to forward messages. One is Routing Discovery used to build a multicast tree from source by flooding; another is Data Transfer which forwards data through the entire multicast tree by unicast from source. The Routing Discovery process begins when an originator vehicle floods a message known as the ZRREQ message throughout the ZOF, see figure 2.8. Each vehicle accepts this ZRREQ message if it is within the ZOF and replies to the one-hop vehicle with the ZRREP message if this accepting vehicle is also within the ZOR, see figure 2.9. After replying to the ZRREP message, this vehicle rebroadcasts the ZRREQ message. If the ZRREP message is sent to the source vehicle, the mulitcast tree is accomplished and data can be transmitted in this tree by the Data Transfer process. In the Data Transfer process, data can be forwarded through this tree since each vehicle stores next-hop(s) local information by the Routing Discovery process.

28 CHAPTER 2. LITERATURE REVIEW Figure 2.8: ZRREQ message (flooded from the originator (source) vehicle) [12] Figure 2.9: ZRREP message (unicasted the one-hop neighbors from where the ZRREQ was first received) [12] Two performance metrics used to evaluate this protocol are defined as follows: Packet Delivery Ratio: The percentage of vehicles that are within ZOR when the message is sent and received. The average packet delivery time Td: The packet delivery time, Td, shows the average time it takes for a message to reach all cars within the ZOR. DRG protocol DRG protocol [9] uses a distance-based backoff for the directed and restricted flooding. It does not need neighbor information for a forwarding decision and therefore does not need to exchange periodic beacons. A simple Flooding can cause redundant transmissions which lead to lots of contention and collisions, the redundancy, however, can be abated by only choosing vehicles closest proximity to destination as relay node. A backoff scheme therefore is used to select a relay node. This 13

29 Simulation-based Performance Comparisons of Geocast Routing Protocols backoff scheme will be favored which selects vehicles at the edge of the transmission range as a relay node. Upon receiving a Geocast message, each vehicle calculates a transmission time of this Geocast message. This transmission time is known as distance-based backoff time, which is based on the distance between the sender vehicle and other vehicles. After this distance-based backoff time expires, each vehicle will broadcast a Geocast message. However, any vehicle which fails backoff contention to a vehicle closer to the destination will annul its transmission. Therefore, the farthest vehicle will be the winner of the contention and hence the first one to transmit the Geocast message. An example of distance-based backoff is shown in figure Assume that node B faces an incident and generates a Geocast message 14 Figure 2.10: A straight road scenario with distance-based backoff to inform vehicles behind it. The right direction of the road where the incident happens to B is the region known as the ZOR. Both directions of the roads, right and left, are the region called the ZOF. Both ZOR and ZOF are shown as rectangles in this figure. Transmission from B is received by nodes A, C and D. Since A is out of ZOR, it ignores the message. Node D is closest to the edge of coverage area and it should relay the message, because with the backoff time, the node closest to the edge of the coverage area indeed transmits the message first. Node C cancels its transmission plan when it receives a message from D. The message spreads toward the destination and node G wins the contention because of the same reason with node D. To evaluate the performance of this protocol, the following performance metrics are used: Packet Delivery Ratio: The Packet delivery ratio is the ratio, as percentage, of the number of nodes receiving the packet and the number of nodes that were supposed to receive the packet. This performance metric can give a measure of the reliability of routing protocols through showing its effectiveness. End-to-End Delay: The End-to-End Delay is the average time delay from the time a geocast message is sent by an application at source node to the time the application running on the receiver node receives the message. This average end-to-end delay indicates a measure of time efficiency of the routing protocol caused by the network layer. Overhead: The Overhead is the ratio of the number of network layer bytes transmitted to the number of bytes sent by the application layer for a unique

30 CHAPTER 2. LITERATURE REVIEW message. The overhead provides a measure of efficiency in reducing redundant transmission. A Mobicast routing protocol for Vehicular Ad hoc Networks: Mobicast Mobicast [4] is a spatiotemporal multicast used to forward Geocast messages to vehicles located in some specific geographic regions, known as the ZOR, at time t. In addition, in order to successfully forward messages to all vehicles within the ZOR, this protocol also defined a geographic zone called the ZOF where vehicles in this region should forward messages to other vehicles within the ZOR. Additionally, this protocol proposes an approach to overcome the issue of the temporal network fragmentation by using the appropriate Zone of Approaching (ZOA) to compose dynamically flexible ZOF with ZOR together. The system model of the Mobicast adopts a dynamic forwarding zone to propagate the message. This message is initiated from an event vehicle to apprise nearby vehicles in order to avoid an accident. To achieve this intention, the event vehicle creates an elliptic region as the ZORt at time t. This vehicle is located at the center of this ellipse. This ellipse moves at the same speed as the event vehicle and toward the same direction. Each vehicle placed in the ZORt is supposed to receive the message from the event vehicle at time t. Three performance metrics used to evaluate this protocol are defined as follows: Dissemination Success Rate: The Dissemination Success Rate is the number of vehicles located in ZORt which can successfully receive messages from the event vehicle, divided by the total number of vehicles in the ZORt. Packet Overhead Multiplication: The Packet Overhead Multiplication is the total number of packets that all vehicles transmitted used in the protocol, divided by the total number of packets that all vehicles transmit not used in protocol. Packet Delivery Delay: The Packet Delivery Delay is the average time that a mobicast message is sent from event vehicle to other vehicles in ZORt. DTSG routing in VANETs DTSG [23] aims to help vehicles to forward a Geocast message within a specific region on the highway for a specific time span. All vehicles should be informed by this Geocast message as soon as they enter this specific region. This Geocast message should be maintained within a specific time span. This protocol therefore is known as the dynamic time-stable Geocast routing protocol and it defines two phases. The first is the pre-stable period that the Geocast message is disseminated within the specific region with the help of vehicles moving in the opposite lane, until the message reaches the end of the region. The second is stable-period which maintains the Geocast message alive during the time span within the specific region. DTSG defines four divergent vehicles which are: Source vehicle (S), Intended vehicles(i), Helping vehicles(h) and Leader vehicle. Source vehicle (S) is the node sending the original Geocast message concerned with the event it faces and is involved in. Intended vehicles (I) coming toward this event should be informed in proper time before they meet the incident. Helping vehicles (H) moving in the opposite lane which are not interested in the Geocast message but used to relay and 15

31 Simulation-based Performance Comparisons of Geocast Routing Protocols maintain this message within the region. Leader vehicle moves in front of a cluster which is a group where the vehicles are located in each other s broadcast range. All these four different vehicles perform together in order to construct a system model, shown in figure Figure 2.11: System model [23] The performance metrics used to evaluate DTSG consist of the packet delivery ratio and cost of broadcast. Sharing and exchanging road traffic information using peer to peer vehicular communication: Geocache Geocache [15] adopts a peer-to-peer application in VANETs to detect and avoid road traffic congestion. This application can exchange and share cooperatively information related to road traffic congestion through employing a collection and dissemination protocol known as pull-based Geocast protocol. Mobile vehicles use this information to dynamically and proactively determine the optimal routes to the final destination by the congestion state of the road. Besides, a caching mechanism is incorporated with this pull-based Geocast protocol to abate the amount of broadcasts when data disseminates. The intention of the pull-based Geocast protocol is to obtain the current congestion level information of the road sections from the vehicles traveling in these sections currently. For the purpose of limiting the amount of messages disseminated among vehicles, Geocast protocol adopts ZOR to restrain the scale of the broadcast to a restricted zone. To further limit time and frequency, a cache mechanism will be drawn in, which allows a vehicle to use the information stored in cache instead of obtaining it through another round of broadcasts. The following performance metrics are designed to assess the benefit of this protocol: Number of Broadcast: The Number of Broadcast is the number of messages sent out by the requesting vehicle and the intermediary vehicles during a single broadcast. These messages include those reaching outside the ZOR. Response Time: The Response Time is the delay between the request issued by the requesting vehicle and the reply received. Information Accuracy: The Information Accuracy is the level of accuracy of the information received by the requesting vehicle.

32 CHAPTER 2. LITERATURE REVIEW 2.4 Comparison of Routing Protocols In this section, the comparisons of Geocast routing protocols are discussed. Position based routing protocols and region based routing protocols are presented respectively according to different parameters and their basic features. Also, in order to accomplish simulation in this thesis, the values of some parameters are summarized according to different routing protocols. These values are derived from previous simulation works by other researchers in their thesis and can be used as references when designing a simulation Basic Features Comparison of Position based Routing Protocols The comparison of basic features in different position based routing protocols is shown in table 2.1. These basic features indicate that some routing protocols are only suitable for highway scenarios, while others are only used for urban scenarios. Some conditions needed in these protocols, such as GPS and Beacon messages, are also shown in table 2.1. Table 2.1: The comparison of basic features in position based routing protocols Protocols Scenario GPS Periodic Beacons GPSR Highway Yes Yes GSR Urban Yes Yes A-STAR Urban Yes Yes GPCR Urban Yes Yes DGRP Urban Yes Yes RDGR Urban Yes Yes GPGR Urban Yes Yes The comparison of algorithms in different position based routing protocols is shown in table 2.2. Most algorithms include forwarding strategies and recovery strategies, but some protocols do not have recovery strategies. Additionally, the message used for these protocols is also investigated and shown in this table Basic Features Comparison of Region based Routing Protocols The comparison of basic features in different region based routing protocols is shown in table 2.3. The comparison of algorithms in different region based routing protocols is shown in table Comparison of Simulation Parameters and Performance metrics In order to accomplish simulation in this thesis, the comparison of simulation parameters is illustrated in table 2.5 and 2.6. These values of different simulation parameters are derived from previous simulation works by other researchers in their thesis. These values are summarized here in order to be used as references and to be adjusted to satisfy researchers own simulation situations when designing their simulation. The performance 17

33 Simulation-based Performance Comparisons of Geocast Routing Protocols Table 2.2: The comparison of different algorithms in position based routing protocols Protocols Forwarding Recovery Strategy Strategy Message GPSR Greedy forward 1.Perimeter forward Beacon message 2.Planarized Graphs (position and identifier) GSR 1.Greedy forward Beacon message 2.Dijkstra algorithm (position and identifier) A-STAR 1.Anchor-based routing 2.Dijkstra algorithm Local recovery Beacon message GPCR 1.Restricted Greedy Routing Beacon message Repair Strategy 2.Detecting Junctions (position and identifier) DGRP 1.Greedy forward Beacon message Perimeter forward 2.Location prediction (position,speed and direction) RDGR Reckoning Link Stability Beacon message Potential Score calculation (position,speed and direction) Selecting a relay vehicle GPGR among all relay candidates by calculation the next position of the relay candidates Beacon message Table 2.3: The comparison of basic features in region based routing protocols Protocols Scenario GPS Periodic Beacons IVG Highway Yes No ROVER Highway Yes Yes DRG Urban/Highway Yes No Mobicast Urban/Highway Yes Yes DTSG Highway Yes No Geocache Urban Yes Yes metrics, shown in table 2.7 and 2.8, summarize most evaluation methods used for different protocols according to previous simulation works by other researchers in their thesis. When designing a simulation, these performance metrics can be used as references and selected to evaluate the performance of routing protocols. 18

34 CHAPTER 2. LITERATURE REVIEW Table 2.4: The comparison of different algorithms in region based routing protocols Protocols Forwarding Recovery ZOR/ZOF Message Strategy Strategy IVG Defer time ZOR:rectangle Geocast message 1.Routing Discovery ZOR:rectangle 1.ZRREQ ROVER 2.Data Transfer ZOF:rectangle 2.ZRREP 3.Data message DRG Distance-based Periodic ZOR:rectangle backoff time scheme Retransmission ZOF:rectangle Geocast message 1.ZORt create phase ZOAt growing ZOR:ellipse 1.Hello message Mobicast 2.Message phase ZOF:ZOR&ZOA 2.control packet dissemination phase 3.growing packet 1.Pre-stable phase Helping vehicle ZOR:rectangle DTSG 2.Stable periods from opposite ZOF:rectangle Geocast message lane. 1.Pull-based Geocast Geocache 2.Least-congested 1.Request message ZOR:rectangle itinerary algorithm 2.Response message 3:Caching Table 2.5: Comparison of simulation parameters for position based routing protocols Vehicle Density Protocols Types Scenario (city:v/km 2 ) Velocity Transmission (highway:v/km) (km/h) range(m) GPSR Position based Highway GSR Position based Real city A-STAR Position based Manhattan city bus:50 car: GPCR Position based Real city DGRP Position based Manhattan city RDGR Position based Manhattan city GPGR Position based Manhattan city Table 2.6: Comparison of simulation parameters for region based routing protocols Vehicle Density Protocols Types Scenario (city:v/km 2 ) Velocity Transmission (highway:v/km) (km/h) range(m) IVG Region based Highway 20(Urban Highway) 10(Rural Highway) ROVER Region based Highway 10,45,272, ,200,300,400 DRG Region based Highway 10,45,272, ,200,300,400 City 20,75,100, ,150,200,250 Mobicast Region based Highway DTSG Region based Highway 1,5,10,50, ,250,400 Geocache Region based City

35 Simulation-based Performance Comparisons of Geocast Routing Protocols Table 2.7: Performance metrics of position based routing protocols Protocols Performance metrics 1.Packet Delivery Ratio GPSR 2.Overhead 3.Path lengths 1.Packet Delivery Ratio 2.Bandwidth consumption GSR 3.Latency 4.Number of hops 1.Packet Delivery Ratio A-STAR 2.End-to-end delay 1.Packet Delivery Ratio GPCR 2.Number of hops 1.Packet Delivery Ratio DGRP 2.Overhead 3.Throughput RDGR 1.Packet Delivery Ratio 1.Local maximum rate GPGR 2.Packet Delivery Ratio 3.Link breakage rate Table 2.8: Performance metrics of region based routing protocols Protocols Performance metrics IVG 1.Multicast success 1.Packet Delivery Ratio ROVER 2.Packet delivery time Td 1.Packet Delivery Ratio DRG 2.End-to-end delay 3.Overhead 1.Dissemination Success Rate Mobicast 2.Packet Overhead Multiplication 3.Packet Delivery Delay 1.Packet Delivery Ratio DTSG 2.Cost of broadcast 1.Number of broadcast Geocache 2.Response time 20

36 CHAPTER 3. METHODOLOGY 3 Methodology In the real world, the efficiency of V2V communication is generally affected by road and communication environment. For the sake of the evaluation of Geocast routing protocols used for V2V communication, a processing of the Geocast routing simulation is designed to achieve the road traffic environment, the Geocast network environment and analyze data. The figure 3.1 shows the whole processing designed for simulation. This processing consists of four portions and it begins from generating a road traffic environment. The Road traffic environment includes several models such as nodes, edges, buildings, vehicles and routes. After this, during road traffic simulation, the simulator loads those models to generate the road traffic environment and then the road information and the states of vehicles are both supplied to the Geocast network simulation. During the Geocast network simulation, the states of vehicles are managed, the Geocast networks are generated and communication among vehicles is achieved. Finally, after obtaining measured data through the Geocast network simulation, the data analysis section is used to analyze them and show the results. Figure 3.1: Geocast Routing Simulation Flowchart In this chapter, the methods used to design the road traffic environment and the Geocast network simulation are discussed. These methods contain the design of the city model and vehicle model, vehicle state management, event management, message scheduling and processing, data collection, etc. After that, the evaluation methods are presented at the end of this chapter, which includes both definitions and explanations. 3.1 Road Traffic Environment The road traffic environment in other theses is mainly classified into highway scenarios and city scenarios. However, this thesis only focuses on city scenarios which have higher vehicle density, more complex traffic conditions and intensive distributed buildings. In order to achieve city scenarios, a road traffic environment generator is designed to generate relevant models. 21

37 Simulation-based Performance Comparisons of Geocast Routing Protocols City Model The city model is based on the Manhattan Mobility Model which allows the mobile node to move along the horizontal or vertical roads [2]. According to Graph Theory [25, p. 154], this road network topology of this city model can be sketched as nodes and edges. The figure 3.2 below illustrates the details of this road network topology and the nodes are classified to two types, according to the position where they located. One type of node is known as an intersection node, which is located at the intersection. The other type of nodes are entrance/exit nodes, which are located at the end of each road. In this figure, the double-headed arrows and the four way arrows represent the entrance/exit nodes and intersection nodes separately. The little boxes between roads are buildings. The buildings are one of major features in urban areas, thus they also need to be considered in this city model. Figure 3.2: Road Network Topology Nodes and Edges This city model is composed by horizontal and vertical roads and the number of them is defined as NUM hor and NUM ver separately. The intersection nodes are placed at each cross point and the number of them is NUM intersection = NUM hor NUM ver. The entrance/exit nodes are located at the two endpoints of each road and the number of them is calculated as NUM entrance/exit = 2( NUM hor + NUM ver ). The horizontal roads all run west-east, while the vertical roads run north-south. Each intersection node can connect in all four directions and each entrance/exit node can only connect in one direction. There must therefore exist an edge from the intersection node to each of four directions. The easier way to calculate the number of edges is that each horizontal road is divided by vertical roads to NUM ver +1 road sections and each road section consists of two edges in opposite directions, which means there are 2( NUM ver +1) edges for one horizontal road. 22

38 CHAPTER 3. METHODOLOGY Since the total number of horizontal roads is equal to NUM hor, the total number of edges for all horizontal roads is equal to 2NUM hor (NUM ver +1). However, for all vertical roads, there are 2NUM ver (NUM hor +1) edges. Finally, the total number of edges in city model is NUM edge = 2[NUM hor (NUM ver +1)+NUM ver (NUM hor +1)]. Each intersection node can be connected to its neighbor nodes by edges in four directions and these neighbor nodes can be either other intersection nodes or entrance/exit nodes. Once all the nodes are connected by edges, the entire grid road network topology is constituted. Roads In the city model, the edges are regarded as roads, which have some major properties that affect the road traffic environment. The Length of road L road : The length of road decides the size of each grid; The Type of road T ype road : The type of road is defined according to the number of lanes for each road, the width of each lane and the maximum speed limitation; In this city model, the Single Two-Way Carriageway is selected as the road type. In this type of road, each direction consists of two 3.75m wide lanes (on rough terrain and when the design speed is 80km/h, the traffic lane width may be reduced from 3.75m to 3.50m), flanked by shoulders at least 3.00m wide each, of which at least 2.50m would be paved or stabilized to permit emergency stops [19, p. 5]. In figure 3.3, the NUM lane is defined as the number of lanes for each direction, the W lane is the width of the lane and Speed max is the maximum speed limitation. Figure 3.3: Length and Type of Road Intersections The figure 3.4 shows an example of an intersection with traffic lights. At each intersection, the mobile nodes can turn left, turn right, go straight or turn back, so the traffic light is an indispensable signaling device to control competing traffic flows [18]. The rules of traffic light can be programmed by two attributes. One is the duration time of each signal and the other is the traffic light states. The table 3.1 shows the colors of signals and explanations. 23

39 Simulation-based Performance Comparisons of Geocast Routing Protocols Figure 3.4: An Example of Traffic Light at Intersection Signal r y g G Table 3.1: Signals and Descriptions of Traffic Light [6] Description red light for a signal - vehicles must stop; amber (yellow) light for a signal - vehicles will start to decelerate if far away from the junction, otherwise they pass; green light for a signal, means traffic may flow, however, priority is given to emergency vehicles and other road users must decelerate/stop to let these priority vehicles pass; green light for a signal, priority - vehicles may pass the junction; Buildings In city areas, buildings may affect the quality of wireless signals because they can obstruct the communicating signals of vehicles and make them fail to communicate. In this thesis, a certain number of buildings are created to simulate a real city and are put into the city model in order to evaluate their influence resulting from their different distances between each building which are distributed along both sides of roads. If the distance increases, buildings are less likely to block the signals of communication. On the contrary, if the distance decreases, buildings are more likely to block the signals of communication Vehicle Model In the real world, vehicles vary greatly and have different types of behavior, thus some basic types of vehicles and a method of route planning are designed to simulate real vehicles in city. Vehicle Types In this city model, vehicles have three types, passenger, transport and emergency. Each of them has different sizes, acceleration and deceleration which may affect the behavior of vehicles. The details are shown in table 3.2. The length of the vehicle and minimum gap is shown in figure 3.5. The Length describes the length of the vehicle itself. The MinimumGap describes the offset to the front vehicle 24

40 CHAPTER 3. METHODOLOGY Table 3.2: Vehicle Types Vehicle Type Length (m) Minimum Gap (m) Acceleration (m/s 2 ) Deceleration (m/s 2 ) Passenger Transport Emergency when standing in a jam [5]. To avoid crashing, vehicles need to keep a safe gap from the vehicle in front. If the front vehicle stops, the vehicle behind it reduces its speed and stops at a place where the distance behind this front vehicle is equal to the MinimumGap. In simulation, vehicles can calculate a distance used to reduce the speed by itself through the Length and M inimumgap. Besides, different types of vehicles can have distinct behaviors which result from the different acceleration and deceleration used. Figure 3.5: Length of Vehicle and M inimumgap Routes The route of each vehicle is randomly selected from the horizontal and vertical roads. Firstly, one of entrance/exit nodes can be randomly selected by vehicles as an entrance of the city and this node is connected to an intersection node. Since any intersection node has four different directions which are left, right, straight and back, one of these directions can be randomly chosen to access the next node. This step is repeated until another entrance/exit node is accessed. Finally, all roads between nodes are combined together to form a route. An example shown in figure 3.6 is adduced to explain the method to form a route. The directions of arrows and dot lines can illustrate a formed route. 3.2 Geocast Network Simulation The design of the Geocast network simulation is described in this section. First of all, some information of the road traffic environment needs to be obtained, such as the number of vehicles, road information, building information and the states of each vehicle, etc. This information needs to be managed. Secondly, a collision warning application is used as a representative for the safety application. In this application, if a vehicle is involved in a collision event, it will send a collision warning message to other vehicles which are in 25

41 Simulation-based Performance Comparisons of Geocast Routing Protocols Figure 3.6: An Example of Route Planning two specific areas known as the ZOR and ZOF. An event management therefore needs to be designed to assign, control and process these collision events. After a collision event happens, the Geocast network should be created in ZOR/ZOF. Based on the VANETs, a Geocast network layer is proposed and designed to achieve the network among vehicles. In the end, the data of Geocast routing protocols needs to be collected and measured. The simulation processing expatiated above is shown in the figure 3.7. It can be divided into five steps after the simulation starts. Figure 3.7: Geocast Network Simulation Flowchart 26 Simulation Initialization: Loading road traffic environment and initializing all components before using them; Traffic State Management: Updating vehicle states and controlling the vehicle density;

42 CHAPTER 3. METHODOLOGY Event Management: Assigning and triggering events; Geocast Routing Processing: Scheduling and processing messages by Geocast routing protocols; Data Collection Management: data. Collecting information and printing out raw Simulation Initialization After simulation started, the first thing is to initialize the road traffic environment and all management components. The figure 3.8 shows the processing of the initialization. Figure 3.8: Simulation Initialization Flowchart Road Traffic Environment Initialization The necessary parameters which need to be considered include the size of the city, the information of buildings, the range of the wireless communication and carrier frequency. After that, the parameters of connection of the road traffic environment also need to be set up. Obstacle Controller Initialization In the real world, the signal can be blocked by the buildings and large vehicles. It also probably bounces in the buildings. To keep simulation simple, the signal is assumed that it can only be blocked by the buildings and no bounce between them. So a model used to block signals is set up here. According to this model, if signals are sent from one vehicle to another and bump a building during transmission, the power of signals can be reduced to zero. Then the vehicle can not receive these signals. An example is shown in figure

43 Simulation-based Performance Comparisons of Geocast Routing Protocols Figure 3.9: An Example of Signal Blocking The vehicle A tries to send a message to the vehicle B, but because of the building, the vehicle B can not receive it in this situation. Traffic State Management Initialization In order to make the vehicle density controllable in the city, the number of vehicles needs to be considered. The maximum number of vehicles in the city has to be set up here at the beginning. When the number reaches its maximum, the vehicle density is regarded as a stable state. This stable state guarantees that the vehicle density is consistent, when each protocol is measured. Event Management Initialization In the simulation, the number, range, probability of triggering and duration of events can be set up here to control the frequency of the occurrence and the position of the collision warning application. By this way, the relevant vehicles and their communication situations in each event are different. Geocast Routing Processing Initialization In this part, the parameters of each layer are configured. The parameters for the network layer depend on different Geocast routing protocols. For the application layer, the collision warning application is set up and it includes the message types and the sizes and types of ZOR/ZOF. Data Collection Initialization The data structures and print-out files are defined here Traffic State Management As shown in figure 3.10, the Traffic State Management mainly has two functions. One is obtaining and managing the state of vehicles and their running information which are 28

44 CHAPTER 3. METHODOLOGY described in table 3.3. The other is vehicle density controlling. In order to control vehicle density and make it stable, first of all, the total number of vehicles in the city is predefined, for example, 400 vehicles. After that, the number of vehicles which move out of the city are checked after every simulation time step. In the meantime, extra vehicles are added into the city and the number of them is the same as those leaving the city. Finally, when the number of vehicles reaches 400, a state, known as Stable State, will be set. A measuring result of the vehicle density is shown in figure Figure 3.10: Traffic State Management Flowchart Event Management When the state of the vehicle density is stable, the Event Management starts to assign events. The number of events is predefined and every event is allocated a probability when it happens. This probability is selected from 0.5 to 0.8 randomly. In addition, at each intersection of the city, there exists a circle event area and the center of this circle is also the center of the intersection. Furthermore, all vehicles are randomly allocated a probability for triggering events from 0 to 0.5. After they enter the event area, this probability increases when moving close to the intersection. The value of this increased probability can be calculated according to the distance from the intersection to vehicles themselves. An equation 3.1 is used to compute this value known as the event triggering offset : Offset event = 0.5(1 D vi r event ) (3.1) Where, Offset event is the offset value of the triggering event, D vi is the distance between vehicle and intersection and r event is the radius of the event area. The figure 3.12 shows an 29

45 Simulation-based Performance Comparisons of Geocast Routing Protocols Table 3.3: Parameters of Vehicle Running Information and State Parameter Description Vehicle State Four states are defined, including Normal, Event Occurred, Event Handling and Out of City. The state is Normal when the vehicle is running in the city normally. Once the event occurs, the vehicle is stopped and its state is changed to Event Occurred. After that, the vehicle sends the message and its state is changed to Event Handling. The vehicle resumes going to its destination as soon as the event is finished and the state goes back to Normal. If the vehicle goes out of the city, the state will be Out of City. Vehicle Identification Number VIN is defined as the unique vehicle identifier instead (VIN) of IP address. Current Location These parameters are retrieved from the road traffic simulator at every simulation time. Current Speed Current Direction Maximum Speed Event Id The Maximum Speed is defined by the maximum speed limitation of each lane from road traffic simulator. The Event Id is set up by Event Management when the event takes place. Figure 3.11: Number of Vehicles in City vs. Simulation Time example of the triggering event. In the event area, there are two vehicles, Vehicle A and Vehicle B. Assuming these vehicles have the same probabilities to trigger an event, but Vehicle A is closer to the center of an event area and hence has a larger Event Triggering 30

46 CHAPTER 3. METHODOLOGY Offset. If the probability of Vehicle A plus its Event Triggering Offset is larger than the probability of the event itself in this event area, the event takes place at Vehicle A and the location of this event is its current location. In addition, to avoid too many vehicles queuing at the event area, there is only one event which occurred at each area. If an event has already happened here, other events will not be assigned. The flowchart of Event Management is shown in figure Figure 3.12: Event Triggering Model Figure 3.13: Event Management Flowchart 31

47 Simulation-based Performance Comparisons of Geocast Routing Protocols Geocast Routing Processing As shown in figure 3.14, the Geocast Routing Processing repeatedly checks whether the event takes place. Once it happens, a Geocast message is created which includes some important information of this vehicle, such as VIN, geographical information, event information and ZOR/ZOF information. The message is then scheduled and processed by the Geocast routing protocols. After a specific waiting time, this message is transmitted. If the message is received by a vehicle, the destination VIN of this message needs to be checked and this vehicle also needs to be located within the ZOR or ZOF. After that, this message can be scheduled and processed. Figure 3.14: Geocast Routing Processing The ZOR is defined as a geographic region of interest where vehicles are located so that the Geocast message is relevant to these vehicles. The ZOF is defined as a geographic region of interest where vehicles are located in order to forward the Geocast message. Two different shapes of ZOR/ZOF are defined and generated according to the position where the events take place, city or highway. City Model In the City Model, the shape of ZOR/ZOF is square, which is generated when an event happens. The center of this square is located at the place of this event shown in figure In this situation, all directions of vehicles are relevant, which means the size of ZOF equals the size of ZOR and the width of ZOR equals the length of it. Highway Model In the Highway Model, the shape of ZOR/ZOF is a rectangle and generated if an event happens. This kind of ZOR can cover the event side road and ZOF can cover the event side road and opposite road precisely. As shown in figure 3.16, ZOR covers two lanes and ZOF contains the opposite road and ZOR. 32

48 CHAPTER 3. METHODOLOGY Figure 3.15: ZOR/ZOF in City Model Figure 3.16: ZOR/ZOF in Highway Model Data Collection Management For each event which has occurred, there should be only one ZOR/ZOF tied together with this event in this city and the Geocast network can be created in this ZOR/ZOF area for communication among vehicles. Besides, for the sake of gauging the performance of different Geocast routing protocols in this network, some parameters need to be collected and calculated which are shown in table 3.4. Table 3.4: The Collecting Parameters Parameter Description Number of Received Vehicles in ZOR/ZOF sage in ZOR/ZOF, when the Geocast network expires. Describes the number of vehicles that receive the mes- Number of Vehicles Passing Describes the number of vehicles passing through the Through ZOR/ZOF ZOR/ZOF, which includes both receiving vehicles and not receiving ones. Maximum Hops Describes the maximum number of hops between the event occurred vehicle and other vehicles. Maximum Delay Time Describes the time consumed from the vehicle involved in the event, to the vehicle which has the maximum hops. 33

49 Simulation-based Performance Comparisons of Geocast Routing Protocols According to the definition of those paramaters in table 3.4, an example, shown in the figure 3.17, is used to explain the method of obtaining the values of them. In this figure, the node A represents the vehicle involved in the event which has two children nodes. These two children nodes also have their own children nodes which have received the messages from their parent nodes. The node B is the last node receiving the message before the Geocast network expires. Meanwhile, there is one node, node C, which does not receive a message. In this Geocast network topology, all connected nodes build up a tree and the node A is its root, so the number of received vehicles in this ZOR/ZOF can be calculated by traversing the tree and the number should be seven in here. The maximum hops, which is equal to three, is the depth of the tree. The maximum delay time can be calculated by using the time of the node B receiving the message minus the time of the node A sending this message. The number of vehicles passing through the ZOR/ZOF can be calculated by adding the number of received vehicles and other vehicles, which is seven plus one in this example. Figure 3.17: An Example of Geocast Network After collecting and calculating, the data should be printed-out into files which can be read for statistical analysis and shown in charts. The flowchart of the Data Collection Management is shown in the figure Evaluation Methods In this theses, two factors are often considered as performance metrics, which are Packet Delivery Ratio (PDR) and Packet Delivery Time (PDT). First of all, the PDR is the ratio of the number of nodes receiving the packet and the number of nodes supposed to receive the packet within the ZOR and it provides a measure of reliability of routing protocols. Secondly, PDT means the consumed time from the first packet leaving the application layer in source node until the application layer in the last node receiving the packet within 34

50 CHAPTER 3. METHODOLOGY Figure 3.18: Data Collection Management Flowchart the ZOR. Since the processing time in application, mac and physical layers is small and constant for all nodes, the delay in delivery caused by the network layer can be used as a measure of Time Efficiency (TE) of the routing protocol. In this chapter, the PDT is therefore defined as a basic measure of the delay time in network layer. The lower the PDT is, the better the TE will be Packet Delivery Time A packet transmitted from source node to the last node may pass several hops and each hop is a vehicle. The PDT is therefore defined as the time consumed from the source node sending the message from the application layer to the last node where the message can reach within the ZOR. This PDT are needed to be recorded through the simulation. The PDT can provide the measure of the time efficiency of the region based Geocast routing protocol Packet Delivery Ratio PDR is determined by two factors. One is the number of nodes that receive the packet within the ZOR. The other is the number of node supposed to receive the packet within the ZOR. Its formula 3.2 is shown as follows: P DR = N r N s (3.2) where, PDR is Packet Delivery Success Ratio, N r is the number of nodes that receive the packet and N s is the number of nodes that are supposed to receive the packet. When the event happens, The vehicles within the ZOR become the node that is supposed to receive the packet. 35

51 Simulation-based Performance Comparisons of Geocast Routing Protocols 4 Geocast Routing Simulator In this chapter, a simulation system known as the Geocast Routing Simulator is built to simulate V2V communication and measure the performances of Geocast routing protocols. This system is based on Vehicles in Network Simulation (Veins), an open source framework for running vehicular network simulations. To offer a comprehensive suite of models for IVC simulation, Veins combines two distinct simulators. One is known as OM- NeT++ which is used for network simulation. The other is SUMO used for road traffic simulation. These two simulators running in parallel are connected via a Transmission Control Protocol (TCP) socket [27]. The Geocast Routing Simulator includes three parts, the Road Traffic Environment Generator, the Geocast Network Simulation System and the Statistical Analysis and Comparison Tools, shown in figure 4.1. These three different parts are executed separately. First of all, the road traffic environment is built and its full information is also exported into Extensible Markup Language (XML) files by the Road Traffic Environment Generator. This road traffic environment information in XML files is then loaded by SUMO. In the meantime, this information is transmitted to the Geocast Network Simulation System which is used to create and manage the Geocast network environment. The Geocast Network Simulation System obtains vehicles states from SUMO by the Mobility Module provided by Veins. The vehicles states are maintained by the Traffic State Management module. Moreover, this module controls the number of vehicles and their behaviour. For example, when a vehicle detects a collision event has occurred, the Collision Warning Application module will notify the Traffic State Management module to stop this vehicle. Meanwhile, the Collision Warning Application module will create a message and send to the Geocast Network Layer module. The Geocast Network Layer is used to schedule and process this message. After that, the message is sent to Mac and Physical layer, which is using IEEE p and IEEE separately. These two protocols are provided by Veins. Whether the messages are sent or received by vehicles, the communication data is recorded by the Data Collection Management module. This data will be exported, when the Geocast Network simulation is done. The Vehicle Density Monitor module is used to detect the number of vehicles in a city or in a specific region. This module is mainly used to control vehicle density and detect the traffic in some regions. After simulation, the Statistical Analysis and Comparison Tools loads and processes the communication data by using statistical methods and also compares and displays the results. 4.1 Road Traffic Environment Generator As mentioned in chapter 3, the road traffic environment consists of intersections, roads, buildings, vehicles, etc. The models of them are created by the Road Traffic Environment Generator and the information of these models can be exported into XML files which can be read by SUMO. Some functions are provided to generate these models. 36

52 CHAPTER 4. GEOCAST ROUTING SIMULATOR Figure 4.1: Geocast Routing Simulator City Generating Function The City Generating Function is used to create intersection, entrances/exits, traffic lights and roads. The input parameters of this function include the number of rows and columns, the length of each road and the road types. The number of rows and columns of this grid city determines the number of intersections and entrances/exits and their distribution relationship. The intersections and entrances/exits are connected by roads and the length of each road can determine the distance between them. The size of this city can be calculated by the positions of intersections and entrances/exits and the length of each road. The environment of each road is defined by different road types. The traffic lights and the default rules of them are created automatically by SUMO itself. Building Generating Function The Building Generating Function is responsible for creating buildings and the input parameters of this function include the number of buildings, the shape of each building and the building distance. Route Planning Function The Route Planning Function is used to pick a route for each vehicle. The route planning, based on the generated city environment, can always start from an entrance/exit and end at another entrance/exit. Each route can at least access to one intersection and go through it. Vehicle Generating Function The Vehicle Generating Function generates vehicles by setting the number of them. The vehicle type will be randomly selected from three different types mentioned in chapter 3. After this, each vehicle can obtain its route through calling the Route Planning Function. 37

53 Simulation-based Performance Comparisons of Geocast Routing Protocols Printout Function The Printout Function is used to export the data of different models into formatted XML files which are readable by SUMO. 4.2 Geocast Network Simulation System The Geocast network environment is built by the vehicles which communicate with each other in a specific area. The communication of these vehicles is based on the Geocast routing protocols, so the main purpose of this system is to build a general Geocastbased network simulation environment. This general Geocast-based network simulation environment can simulate different Geocast routing protocols in different conditions and collect the information of their performance metrics. According to the requirement of the Geocast network simulation mentioned in the chapter 3, this system includes seven parts, Vehicle State module, Traffic State Management module, Event Management Module, Collision Warning Application Module, Geocast Network Layer module, Vehicle Density Monitor module and Data Collection Management Module. The following sections will introduce the design and implementation of each module Vehicle State Module The Vehicle State module shown in figure 4.2 is used to provide functions for communicating with SUMO by the Mobility module. This Vehicle State module includes obtaining vehicle state information and control vehicles. The vehicle state information includes vehicle ID, current speed, current direction, current location, maximum speed, etc. The functions of vehicles controlling is used to set vehicle speed and generate new vehicles. The generating new vehicles is used to add new vehicle into the city during simulation. In this function, two parameters need to be set which are the vehicle type and route and they are selected randomly here, just like generating a vehicle in a road traffic environment mentioned in chapter 3. Figure 4.2: Structure and Components of Vehicle State Module and Related as to Other Modules Traffic State Management Module The Traffic State Management module is used to maintain vehicle states, control vehicle behavior and number of vehicles in the city. The structure and components of it are shown 38

54 CHAPTER 4. GEOCAST ROUTING SIMULATOR in figure 4.3. The states of vehicles are obtained from the Vehicle State module and stored in the Vehicle States Buffer which is maintained by Buffer Maintainer. Any operation for the Vehicle State Buffer needs to be done by Buffer Maintainer which provides searching, updating and deleting for this buffer. To control vehicle behavior, the Collision Warning Application just provides VIN and the value of vehicle speed. To locate this vehicle in SUMO, the vehicle ID needs to be obtained from Vehicle State Buffer. The function of the Vehicle State is then invoked to set a new speed for the specific vehicle. At each simulation time step, this module checks the number of vehicles which are out of the city. At the next time step, it adds the same amount of new vehicles into city. Additionally, there also exists a function of getting vehicle state and this function can be invoked by the Collision Warning Application modules in order to get the state information of the vehicle. Figure 4.3: Structure and Components of Traffic State Management Module and Related as to Other Modules Collision Warning Application Module The Collision Warning Application is used as a representative for the safety applications in this simulation system. This module is shown in figure 4.4. The collision warning application is triggered when a vehicle is involved in a collision event. When a collision event happens, this module will stop this vehicle and then a collision warning message will be sent to the nearby vehicles within a specific region, known as ZOR/ZOF, in order to notify them to avoid collision. This collision warning message contains some necessary information. Firstly, the VIN, the current location and the current speed obtained from Traffic State Management module are contained in the message. Moreover, some information in the message is used for describing ZOR/ZOF. Finally, the rest of the information is used to depict the state of the message itself which contains Time-To-Live (TTL) of the message and the timestamp of creating the message. When this collision event is ended, this module will restart the vehicle and make it keep running to its destination. 39

55 Simulation-based Performance Comparisons of Geocast Routing Protocols Figure 4.4: Structure and Components of Collision Warning Application Module and Related as to Other Modules Vehicle Density Monitor Module The Vehicle Density Monitor module is shown in figure 4.5. This module is used to count the number of vehicles in the city or in ZOR/ZOF and return the list of VIN to the Data Collection Management module and the Event Management module. Figure 4.5: Structure and Components of Vehicle Density Monitor Module and Related as to Other Modules Event Management Module The Event Management Module is used to assign and manage events. The structure and components are shown in figure 4.6. This module checks whether an event can be assigned to a vehicle at this moment or not. The judging conditions are described in chapter 3. If the vehicle density which is obtained from the Vehicle Density module is stable and the other conditions are satisfied, an event will be initialized which includes the event ID, event area, an event duration time and the VIN of this vehicle. After that, this module notifies the Collision Warning Application module that an event has happened. When 40

56 CHAPTER 4. GEOCAST ROUTING SIMULATOR the event is ended, it will notify the Collision Warning Application module to restart the vehicle. Figure 4.6: Structure and Components of Event Management Module and Related as to Other Modules Geocast Network Layer Module The Geocast Network Layer module is designed to create a Geocast-based network layer framework which is suitable for the Geocast routing protocols compared in this thesis. According to investigating these protocols in chapter 2, it is well known that most of Geocast routing protocols are based on a specific geographical area and the differences between them are scheduling strategies. Based on this idea, most components and functions can be used for all these protocols and only scheduling and processing need to be written for each protocol respectively The structure and components of this module are shown in figure 4.7. When an event happens, the Collision Warning Application model will send a message to the Geocast Network Layer. Firstly, this message needs to be encapsulated as a Geocast message. After that, a task is created to contain this message which has some extra information used for scheduling and processing depending on different protocols. After scheduling and processing, the task will be pushed into a message buffer and wait to be sent. At each simulation time step, this module checks the waiting time of all tasks once. Before the waiting time of some tasks expires, the messages of these tasks will be updated, which includes forwarding VIN, forwarding vehicle location, forwarding vehicle speed and forwarding time. After that, these messages are sent to a lower layer. If a message is received from a lower layer, the message will be decapsulated. According to the destination VIN and information of ZOR/ZOF of this message, this module can determine whether this message can be discarded or not. If not, this message will be put into a task and be scheduled and processed like the message from the Collision Warning Application. The communication information of all messages will be recorded to the Data Collection Management module whether these messages are from the upper layer or lower layer. 41

57 Simulation-based Performance Comparisons of Geocast Routing Protocols Figure 4.7: Structure and Components of Geocast Network Layer Module and Related as to Other Modules Data Collection Management Module The Data Collection Management module shown in figure 4.8 is used to collect the communication data of each network. When an event happens, the vehicle involved in the collision event will send a message to vehicles in a specific area. So the Geocast network is generated, when the involved vehicle sends the first message. This vehicle is considered as the root node of the network, while other vehicles are the children nodes which receive the message from other vehicles. Thus the data structure of each network communication data is like a tree and stored in the data buffer. At each simulation time step, this module checks the vehicles passing through the network area by invoking the function of Vehicle Density Monitor module. When an event is ended which means a network also expires, this module will collect all communication data of this network and print it out Geocast Routing Protocols All Geocast routing protocols discussed in this section are implemented based on the Geocast Network Layer module and here only shows their state diagram. ZOR/ZOF limited Flooding The Flooding algorithm is used to compare with other protocols. For the implementation of it in the Geocast network, ZOR/ZOF is used to restrict flooding to the relevant vehicles. In addition, each vehicle continues to broadcast a message until it receives a same version of this message which is an acknowledgement from other vehicles. Besides, a random backoff time is used to avoid collisions caused by all receiving nodes rebroadcasting at the same time. DRG DRG uses a distance-based backoff algorithm to select relay and also restrict flooding. 42

58 CHAPTER 4. GEOCAST ROUTING SIMULATOR Figure 4.8: Structure and Components of Data Collection Management Module and Related as to Other Modules This protocol does not need to send Hello Message to know the state information of neighbor vehicles. It therefore belongs to a beaconless protocol. The message used in DRG is the collision warning message. A state diagram for protocol DRG is shown in figure 4.9. Figure 4.9: State Diagram of DRG [9] 1. On receiving a message, a node examines and checks if it belongs to either the ZOR or ZOF. If not, the node just discards the message. If the message has been received 43

59 Simulation-based Performance Comparisons of Geocast Routing Protocols for the first time and the node is in ZOR, the message is pushed up to the higher layer and added into a message buffer. Since each received message is recorded in the message buffer, if the same message is received, it is marked as an implicit acknowledgement in this message buffer and then any future reception of the message is ignored. 2. At the time of transmission of the message, a retransmission is scheduled after the maximum backoff time. The message is regularly retransmitted at maximum backoff time and the number of retransmission is counted. 3. If an implicit acknowledgement message is received before the scheduled transmission time, the transmission is canceled. 4. When the number of the retransmission reaches the maximum retransmission M axret x, the retransmission counter is reset and the protocol enters sleep state. 5. The next retransmission is scheduled after the long backoff time. 6. When the protocol is in sleep state, if an implicit acknowledgement message is received before the scheduled transmission time, this transmission is canceled. 7. At the expiry of the persistence timer, a node just transmits the message once, without expecting an acknowledgement. 8. A message is discarded if its TTL has expired, any scheduled transmission is canceled and the message details are dropped from the message buffer. ROVER ROVER is a more complex routing protocol and it is a beacon based protocol which broadcasts three types of message. The requesting message and replying message are used to build a multicast tree within ZOR firstly and then the data message is sent from source vehicle by unicast. The collision warning message is used for these three messages marked by three different message types which include request, reply and data, respectively. The situation of ROVER in ZOR and ZOF are different, so two state machines concerned with ZOR and ZOF are respectively shown in figure 4.10 and figure However, in simulation, the state diagram in ZOR is used since the shapes of ZOR and ZOF are equal and they overlap together in the city model. There exist six states in ZOR: On receiving a request message, a node checks if it is within the ZOR. If not, the node checks if it is within ZOF, if the answer is also negative, the message is abandoned. If the message is received for the first time and the node is in ZOR, this message is pushed up to the higher layer and its VIN is recorded. 2. The node that receives a request message transmits a reply message and this transmission is scheduled after a backoff time, so the message is usually retransmitted at the expiry of the backoff time. 3. If the node receives a data message, this data message is added to the Message Buffer. 4. After receiving the data message, the node transmits a request message and this transmission is also scheduled a backoff time. This message is retransmitted at the expiry of the backoff time.

60 CHAPTER 4. GEOCAST ROUTING SIMULATOR Figure 4.10: State Diagram of ROVER In ZOR [12] 5. If the node receives a reply message when it is retransmitting a request message, it transmits the data packet by using unicast. 6. A message is discarded if its TTL has expired and any scheduled transmission is canceled, besides, the message details are removed from the Message Buffer. There exist six states in ZOF: 1. If the node in the ZOF receives a request message, it checks if it is within the ZOF. If not, the node just discards the message. However, if the message is received for the first time and the node is in the ZOF, this message is pushed up to the higher layer and its VIN. 2. The node which has received a request message transmits a request message and this transmission is scheduled after a backoff time, so the message is retransmitted at the expiry of the backoff time. 3. If the node receives a reply message when it transmits a request message, it becomes a reply node. 4. After the node receives a reply message, it transmits a reply message and this transmission is also scheduled after a backoff time, so the message is also retransmitted at the expiry of the backoff time. 5. After the node obtains the data message, it adds this data message to the Message Buffer and transmits it. 6. The message is abandoned if its TTL has expired and any scheduled transmission is canceled, besides, the message details are removed from the Message buffer. 45

61 Simulation-based Performance Comparisons of Geocast Routing Protocols Figure 4.11: State Diagram of ROVER In ZOF [12] DTSG DTSG has been implemented in highway scenarios before. However, according to the future work section of [23], this protocol can also be applied in city scenarios. For this reason, this protocol is chosen to compare with other protocols by using a manhattan city scenario in our simulation. Apart from the collision warning message for DTSG, some extra information is also included in this message. This extra information is the range of extra region, message version and pre-stable flag. A state diagram for the DTSG is shown in the figure On receiving a message, a node checks if it is within ZOR/ZOF, if not, this node just abandons the message, otherwise, if the message is received for the first time and this node is in ZOR/ZOF, this message is added to the Message Buffer and pushed up to the higher layer. 2. The node that receives a message transmits this message after the expiry of the backoff time. 3. If this node receives an acknowledgement message from other nodes when it transmits, it cancels its transmission and enters a sleep state. 4. When the node enters extra area it changes the message flag to the stable period. 5. After the node enters the extra area and changes the message s pre-stable flag, it transmits the message after the backoff time until it receives an acknowledgement message from other nodes. 6. If the node receives an acknowledgement message from other nodes, it cancels its transmission and enters waiting TTL state to wait for TTL expiry.

62 CHAPTER 4. GEOCAST ROUTING SIMULATOR Figure 4.12: State Diagram of DTSG [23] 7. The message is dropped if its TTL has expired and any scheduled transmission is cancelled, furthermore, the message details are removed from the message buffer. 4.3 Statistical Analysis and Comparison Tools The Statistical Analysis and Comparison Tools are responsible for reading raw data from XML files exported by the Geocast Network Simulation System, analyzing this data by using statistical methods and displaying results. These tools consist of three parts, loading data, evaluating results and displaying results. The results are analyzed by the evaluation methods defined in chapter 3 and these evaluated results can be displayed in diagrams. 47

63 Simulation-based Performance Comparisons of Geocast Routing Protocols 5 Performance Evaluation In this chapter, the configurations of the road traffic environment and Geocast network simulation will be discussed in the Simulation Environment Configurations section. In the Simulation Scenario Planning section, some simulation scenarios are set up to evaluate the influence of various values of scenarios for each protocol. In the Result Analysis section, the performances analysis of Geocast routing protocols will be shown and discussed. 5.1 Simulation Environment Configurations Road Traffic Environment Configuration As mentioned in chapter 3, the Manhattan Mobility Model is considered as the city model in this road traffic environment. The city model loaded by SUMO is shown in figure 5.1. The entire size of city is 1000m 1000m separated to 5 5 grids and the size of each grid is 200m 200m. The roads are placed 200m apart and perpendicular each other and each of them has two directions. In each road direction, there exist two lanes and the breadth of each lane is 3.25m. The number of vehicles and the building distance are set in section 5.2. Figure 5.1: The Srceenshot of City Model in SUMO 48

64 CHAPTER 5. PERFORMANCE EVALUATION Geocast Network Simulation Configuration In this section, the parameters of events and protocols need to be set up. As shown in table 5.1, the event type in the table is used to choose the kind of the event application and the collision event is selected here. The number of events means that the total number of events will be triggered when simulating one protocol and this number is set to 30. As mentioned in chapter 3, the intersections in Manhattan city are selected as the center of event areas where the events will more probably happen. These event areas are some circle regions. Since the length of each road section is 200m, the range of each event area is chosen as 200m. In order to make events happen randomly, the maximum event occurred ratio is set to 80% and the maximum probability for triggering an event is 50% to each vehicle. The event duration time is set from 0.1s to 0.5s. The model of ZOR/ZOF is selected as a city model in order to cover the event road, opposite road and intersection. Table 5.1: Event Parameters Setup Parameters Values Event Type Collision Event Number of Events 30 Range of Event Area 200m Maximum Event Probability 80% Minimum Event Duration Time 0.1s Maximum Event Duration Time 0.5s Maximum Event Triggering Probability 50% ZOR/ZOF Model City Model For each Geocast routing protocol, some parameters are set in table 5.2. The parameters of ZOR/ZOF limited Flooding and ROVER are the maximum collision window and the fixed slot time which are used to calculate a random slot based backoff to avoid collision [9]. For protocol DRG, the maximum backoff time allowed, distance sensitivity factor and wireless transmission range are used to calculate the distance-based backoff time [9]. The long backoff time is the backoff time used when the number of retransmissions is larger than maximum retransmission times. The sensitivity factor is used to calculate the persistence time. The maximum criterion angle is an angle used as a threshold to accept a packet as an acknowledgement in order to stop retransmissions [9]. Finally, the wireless transmission range and the carrier frequency are set up for all protocols. The value of them are chosen based on the IEEE p standard [8]. 5.2 Simulation Scenario Planning The performance of different protocols is evaluated according to various simulation scenarios including vehicle density, size of ZOR/ZOF and building distance. The selected values of these scenarios are shown in table 5.3. About the scenarios, the default values in brackets are used as basic case. The default value of the vehicle density is chosen from [9]. The default value of ZOR/ZOF is selected according to the length of each road in the city, because in this city model, each ZOR/ZOF has to cover one intersection at least. Through measuring the real Manhattan in New 49

65 Simulation-based Performance Comparisons of Geocast Routing Protocols Table 5.2: Geocast Routing Protocols Parameters Setup Protocols Parameters Values Maximum Collision Window 0.01s ZOR/ZOF Fixed Slot Time 1.0 limited Flooding Wireless Transmission Range 300m Carrier Frequency 5.9 GHz Maximum Backoff Time Allowed 0.01s Long Backoff Time 2.5s Maximum Retransmit Times 2 DRG Maximum Collision Window Distance Sensitivity Factor 1.0 Sensitivity Factor 0.5s Maximum Criterion Angle 135 Wireless Transmission Range 300m Carrier Frequency 5.9 GHz Maximum Collision Window 0.01s ROVER Fixed Slot Time 1.0 Wireless Transmission Range 300m Carrier Frequency 5.9 GHz DTSG Wireless Transmission Range 300m Carrier Frequency 5.9 GHz York by Google map, 40m is selected as the default value of building distance, however the shorter distance between buildings means that the city model has the crowded building distribution, and higher probability to block signals at intersections. Table 5.3: The Simulation Scenarios and Values Scenarios Values Vehicle Density 50, 100, 150, (200), 250, 300 vehicles/km 2 ZOR/ZOF Range , , , ( ), , m 2 Building Distance 10, 20, 30,(40),50, 60 m Note: The values in parentheses are default values. When the performances of the protocols are compared with each other by using different values of vehicle density, the values of ZOR/ZOF and building distance use default values, m 2 and 40m, respectively. Similarly, when the performances are compared by using different values of ZOR/ZOF, the other two scenarios use their default values. The same as the previous way, the different values of building distance are used and the default values of other scenarios are selected. 5.3 Results Analysis This section shows the results of the performance of different simulated Geocast routing protocols which are mentioned in chapter 4. The performances of them are evaluated by 50

66 CHAPTER 5. PERFORMANCE EVALUATION evaluation methods defined in chapter 3 and the results are analyzed according to different scenarios defined in section Vehicle Density The effect of the vehicle density on the performances of protocols is shown in figure 5.2 and 5.3. In figure 5.2, ROVER has the longest PDT, since it needs to send the beacon messages to discover routes before sending the collision warning message. However, DRG, DTSG and Flooding do not need to sent the beacon messages, so their PDT are much shorter than ROVER. In 50 vehicle density, only vehicles nearby the event can receive the message, as for the others far from the event can not receive it. The results of the PDT and the PDR of all protocols in this situation are therefore relatively low. The results of PDR of most protocols increase, when the vehicle density reaches 100. It is because that more vehicles can help forwarding to other distant vehicles. However, along with the growing of the number of forwarding vehicles, the results of the PDT of different protocols also increase. When the vehicle density is higher than 100, the protocols which have better forwarding strategies can select a more appropriate vehicle as relay node to forward the message, which can lead to the decreasing of the PDT. However, the protocols, such as Flooding, without the forwarding strategy may have a longer PDT result. The reason for this is that with the growing of the number of vehicles, packet collisions and backoff time increases at lower layer. The PDT of ROVER increases, when the vehicle density is higher than 200. It is because the routing strategy of ROVER is similar to Flooding. Therefore, the more vehicles are, the more packet collisions will be. In high vehicle density situations, the PDR of DRG and ROVER are very high and almost all vehicles can receive the message. However, the PDR of DTSG is very low, because the algorithm of it, used to calculate the backoff time, may only be suitable for highway scenarios. In city scenarios, its backoff time is too long, which causes that the message can only be forwarded finite times and most vehicles can not receive it Zone of Relevance/Zone of Forwarding The effect of ZOR/ZOF range on the performances of protocols is shown in figure 5.4 and 5.5. The PDT of ROVER and Flooding are increasing with range of ZOR/ZOF increasing. It is because that more vehicles are covered by ZOR/ZOF and therefore the PDT increases. DRG keeps the PDT very low, because it always chooses the farthest vehicle as relay node and thus it can cover the whole ZOR/ZOF by using few vehicles. Besides, since expanding the range of ZOR/ZOF may increase the number of vehicles in this area, some vehicles far away from the event location may not easily be connected. ROVER and DRG have better strategies to overcome the network fragmentation situation and make most vehicles to receive the messages successfully. However DTSG and Flooding do not have these strategies, so their results of the PDR decrease in most situations Building Distance The effect of building distance is shown in figure 5.6 and 5.7. As mentioned in chapter 3, the buildings should block the signals at the intersections and this situation may have an 51

67 Simulation-based Performance Comparisons of Geocast Routing Protocols Figure 5.2: The Packet Delivery Time Figure 5.3: The Packet Delivery Ratio influence on the performance of protocols. For this reason, all protocols have the lower PDR when building distance is short. However, as the growing of the building distance, the PDR of all protocols also increase. The tendency of PDT of each protocol is similar to 5.2. It is because that only few vehicles can receive the message in short building distance 52

68 CHAPTER 5. PERFORMANCE EVALUATION Figure 5.4: The Packet Delivery Time Figure 5.5: The Packet Delivery Ratio situation due to the blocking of the signals caused by crowded buildings. This situation can be considered as the low vehicle density. When the building distance increase, more vehicles can receive the message, so this situation can be considered as the high vehicle density. Therefore, the tendencies of PDT of all protocols are caused by the same reason 53

69 Simulation-based Performance Comparisons of Geocast Routing Protocols discussed in subsection Figure 5.6: The Packet Delivery Time Figure 5.7: The Packet Delivery Ratio 54

70 CHAPTER 6. CONCLUSIONS AND FUTURE WORKS 6 Conclusions And Future Works 6.1 Conclusions At the beginning sections of this thesis, different categories of routing protocols in VANETs and communication forwarding schemes have been presented. Some known routing protocols in VANETs have been investigated, which include both position based routing protocols and region based routing protocols. The comparisons of these routing protocols has also been summarized. In this thesis, two evaluation methods is defined in order to evaluate the performance of region based Geocast routing protocols. One is the Packet Delivery Ratio(PDR); The Other is the Packet Delivery Time(PDT). The PDR is used to evaluate the reliability of the region based Geocast routing protocols; The PDT can provide the measure of the time efficiency of different region based Geocast routing protocls. These evaluation methods have been used to evaluate the performance of several Geocast routing protocols. This thesis also designs several important methods. These methods have beed used effectively to design a general Geocast routing simulator, Another main purpose of this thesis is to evaluate and compare the performances of different Geocast routing protocols by the help of performance metrics defined in this thesis. For the sake of this goal, some methods concerned with the road traffic environment and the Geocast network simulation have been designed in the Methodology section and effectively used to design the Geocast routing simulator in this thesis. This simulator has been used to simulate different Geocast routing protocols and evaluate and compare the performances of them. It can provide both road traffic environment and Geocast network simulations. One of the important characteristics of this Geocast routing simulator is the Geocast network layer module and the Geocast-based network layer framework is also designed in this module. This framework is designed to achieve the comparison of different Geocast routing protocols which are based on a specific geographical region. In this thesis, some region based Geocast routing protocols are chosen to be compared by using this Geocast routing simulator and their simulations indicate that this simulator is effective for comparing and analyzing this kind of Geocast routing protocols. In the Result Analysis section, the results point out that DRG has both good PDR and PDT in most scenarios. ROVER also has high results of PDR in most scenarios, but its PDT is longer than other protocols because it needs to send the beacon messages to discover routes before sending the collision warning message. The PDR of DTSG is very low, because the forwarding strategies of DTSG used to decide the broadcast period and to select relay vehicles is not quite appropriate for the city model. The PDR of Flooding is worse than DRG and ROVER, but the PDT is better than ROVER in all scenarios. 55

71 Simulation-based Performance Comparisons of Geocast Routing Protocols 6.2 Future Works In this thesis, only the Manhattan city model is chosen as a simulation environment and tested by using the Geocast Routing Simulator designed in this thesis. However the highway environment also needs to be tested by using this Geocast Routing Simulator and analyzed by the evaluation methods defined in this thesis. Besides, when the highway environment is tested, the Highway Model of ZOR/ZOF defined in the Methodology section also needs to be tested. The accident event application is selected in this thesis to be simulated, but other applications such as emergency event application can also be simulated. The ZOR/ZOF needs to be generated in front of emergency vehicles in this emergency event application, since the emergency vehicles like police or ambulance cars need to notify the front vehicles. Vehicle platooning, also called road train, needs to be simulated by the Geocast Routing Simulator and analyzed by the evaluation methods which are both designed in this thesis. In the Simulation Scenario Planning section, several simulation scenarios and their values are selected, however, for the sake of accuracy and precision, more values of different simulation scenarios need to be chosen in order to design more simulation plans. 56

72 BIBLIOGRAPHY Bibliography [1] A. Bachir and A. Benslimane. A multicast protocol in ad hoc networks inter-vehicle geocast. In Vehicular Technology Conference, VTC 2003-Spring. The 57th IEEE Semiannual, volume 4, pages vol.4, April [2] S. Buruhanudeen, M. Othman, M. Othman, and B.M. Ali. Mobility models, broadcasting methods and factors contributing towards the efficiency of the manet routing protocols: Overview. In Telecommunications and Malaysia International Conference on Communications, ICT-MICC IEEE International Conference on, pages , May [3] Si-Ho Cha, Keun-Wang Lee, and Hyun-Seob Cho. Grid-based predictive geographical routing for inter-vehicle communication in urban areas. International Journal of Distributed Sensor Networks, 2012, [4] Yuh-Shyan Chen, Yun-Wei Lin, and Sing-Ling Lee. A mobicast routing protocol in vehicular ad-hoc networks. In Global Telecommunications Conference, GLOBE- COM IEEE, pages 1 6, Nov [5] Institute of Transportation Systems German Aerospace Center. Definition of vehicles, vehicle types, and routes, November [6] Institute of Transportation Systems German Aerospace Center. Simulation/traffic lights, November [7] H. Ghafoor and K. Aziz. Position-based and geocast routing protocols in vanets. In Emerging Technologies (ICET), th International Conference on, pages 1 5, Sept [8] Chong Han, M. Dianati, R. Tafazolli, R. Kernchen, and Xuemin Shen. Analytical study of the ieee p mac sublayer in vehicular networks. Intelligent Transportation Systems, IEEE Transactions on, 13(2): , June [9] Harshvardhan P Joshi, Mihail L Sichitiu, and Maria Kihl. Distributed robust geocast multicast routing for inter-vehicle communication. In Proceedings of WEIRD Workshop on WiMax, Wireless and Mobility, pages 9 21, [10] Jagadeesh Kakarla, S Siva Sathya, B Govinda Laxmi, and B Ramesh Babu. A survey on routing protocols and its issues in vanet. International Journal of Computer Applications, 28, [11] Brad Karp and Hsiang-Tsung Kung. Gpsr: Greedy perimeter stateless routing for wireless networks. In Proceedings of the 6th annual international conference on Mobile computing and networking, pages ACM,

73 Simulation-based Performance Comparisons of Geocast Routing Protocols [12] Maria Kihl, Mihail Sichitiu, Ted Ekeroth, and Michael Rozenberg. Reliable geographical multicast routing in vehicular ad-hoc networks. In Wired/Wireless Internet Communications, pages Springer, [13] Sandhaya Kohli, Bandanjot Kaur, and Sabina Bindra. A comparative study of routing protocols in vanet. Proceedings of ISCET, [14] R. Kumar and S. V. Rao. Directional greedy routing protocol (dgrp) in mobile ad-hoc networks. In Information Technology, ICIT 08. International Conference on, pages , Dec [15] A. Lakas and M. Shaqfa. Geocache: Sharing and exchanging road traffic information using peer-to-peer vehicular communication. In Vehicular Technology Conference (VTC Spring), 2011 IEEE 73rd, pages 1 7, May [16] C. Lochert, H. Hartenstein, J. Tian, H. Fussler, D. Hermann, and M. Mauve. A routing strategy for vehicular ad hoc networks in city environments. In Intelligent Vehicles Symposium, Proceedings. IEEE, pages , June [17] Christian Lochert, Martin Mauve, Holger Füßler, and Hannes Hartenstein. Geographic routing in city scenarios. ACM SIGMOBILE Mobile Computing and Communications Review, 9(1):69 72, [18] Clay McShane. The origins and globalization of traffic control signals. Journal of Urban History, 25(3): , [19] TEM Project Central Office. TEM STANDARDS AND RECOMMENDED PRAC- TICE Third Edition [20] Bijan Paul, Md Ibrahim, Md Bikas, and Abu Naser. Vanet routing protocols: Pros and cons. International Journal of Computer Applications, 20, [21] Bijan Paul and Mohammed J Islam. Survey over vanet routing protocols for vehicle to vehicle communication. IOSR Journal of Computer Engineering (IOSRJCE), pages [22] K Prasanth, K Duraiswamy, K Jayasudha, and C Chandrasekar. Improved packet forwarding approach in vehicular ad hoc networks using rdgr algorithm. International Journal of Next-Generation Networks, 2(1), [23] H. Rahbar, K. Naik, and A. Nayak. Dtsg: Dynamic time-stable geocast routing in vehicular ad hoc networks. In Ad Hoc Networking Workshop (Med-Hoc-Net), 2010 The 9th IFIP Annual Mediterranean, pages 1 7, June [24] Boon-Chong Seet, Genping Liu, Bu-Sung Lee, Chuan-Heng Foh, Kai-Juan Wong, and Keok-Kee Lee. A-star: A mobile ad hoc routing strategy for metropolis vehicular communications. In NETWORKING Networking Technologies, Services, and Protocols; Performance of Computer and Communication Networks; Mobile and Wireless Communications, pages Springer, [25] Lipschutz Seymour and Lipson Marc. Schaum s Outline of Discrete Mathematics, Revised Third Edition. McGraw-Hill,

74 BIBLIOGRAPHY [26] Katrin Sjöberg. Medium access control for vehicular ad hoc networks. Chalmers University of Technology, [27] C. Sommer, R. German, and F. Dressler. Bidirectionally coupled network and road traffic simulation for improved ivc analysis. Mobile Computing, IEEE Transactions on, 10(1):3 15, Jan [28] S Sujatha and P Soundeswari. Comparative and behavioral study on vanet routing protocols. 59

75 Hequn Zhang is from Ningbo, China. He has achieved Bachelor degree from Hefei University of Technology in Currently, he is focusing on the v2v communication simulation within this thesis. The areas of his expertise are Real Time Systems and Intelligent Vehicle Systems. Rui Wang is from Tianjin, China. He was admitted to Halmstad University in Now, he is studying in Embedded and Intelligent System. In this thesis, he summarized different routing protocols, compared them, and designed performance metrics, methods and scenario planning. PO Box 823, SE Halmstad Phone: