Enhancing infotainment dissemination in vehicular ad-hoc networks: a simulation study

Facolt di Ingegneria Corso di Laurea in Ingegneria Informatica (LM), curriculum Reti di Calcolatori Cattedra di Network Infrastructures

Candidato Mario De Felice 1318627

Relatore Chiar.ma Prof.ssa Francesca Cuomo

Correlatore Ing. Pierpaolo Salvo

AA 2010/2011
1

Bisogna volere l'impossibile affinch l'impossibile si realizzi Eraclito

Content Index:

A General Overview

Chapter 1: An outline about Vehicular Ad-hoc Networks 1.1: 1.2: 1.3: 1.4: The WAVE architecture and general considerations WAVE communication patterns MAC layer and QoS Related standards and possible applications

9 12 16 19 22

Chapter 2: Routing protocols in VANETs 2.1: Topology-based routing protocols 2.1.1: Fisheye state routing (FSR) 2.2: Geographic routing in VANETs 2.2.1 Greedy Perimeter Stateless Routing (GPSR) 2.2.2 Geographic Source Routing (GSR)

27 29 30 30 32 34
3

2.2.3 Anchor-based Street and Traffic Aware Routing (A-STAR) 2.2.4 Vehicle-Assisted Data Delivery (VADD) 2.3: Dissemination routing 2.3.1 New forwarding algorithms: SAF and TAF

34 35 36 38

Chapter 3: The simulation stack created 3.1: Mobility models 3.2: SUMO (Simulation of Urban Mobility) 3.2.1 Protocol Features 3.2.2 The Simulation Model 3.3: MOVE (Mobility model generator for Vehicular networks) 3.3.1 The MOVE architecture 3.4: NS-2 (Network Simulator 2) 3.4.1: NS2 basic architecture 3.4.2: Implementation of Discrete-Event Simulation and Network Objects in NS-2

42 44 48 49 50 52 55 56 57 59

Chapter 4: New protocols in NS-2 and other implementations 4.1: Structure of NS-2 Inheritance and Major Challenges 4.2: NS-2 Protocols Implementation 4.2.1: The Flooding Protocol 4.2.2: The DBF Protocol 4.2.3: The SAF and TAF Protocols 4.3: AWK scripts for results evaluation

62 62 66 67 68 70 71

Chapter 5: Simulations and Results 5.1: The Simulation Scenario 5.2: Mobility Model 5.3: NS-2 Parameters and Specifications 5.3.1: The PHY Layer

74 77 80 82 83
4

5.3.2: 802.11p Specifications 5.3.3: The Propagation Model 5.3.4: Network Traffic Specifications 5.4: Parameters Summary 5.5: The Metrics Chosen for the Simulations 5.6: Scenario Snapshots 5.7: Simulation Results and Discussion 5.7.1: Information Coverage 5.7.2: Reached Nodes 5.7.3: Delay in delivering messages 5.7.4: Forwarding OBUs 5.7.5: Collisions 5.7.6: Copies 5.8: Compared Analysis and Future Improvements

84 85 88 89 92 93 95 95 96 98 99 100 102 103

Conclusion References Acknowledgements

104 106 110

A General Overview
Vehicular networks have a major role in increasing the extent of pervasive computing. With services and applications specially suited for vehicular communications which are on their way to be designed, also in Italy, it is necessary to ensure reliability, capability and security of the communications technology used. From a networking viewpoint, accommodating a wireless access technology for a highly mobile and insecure environment needs time and attention: an IEEE working group has started working since long on a draft amendment, IEEE 802.11p, to the legacy IEEE 802.11. In this scenario, two new simple dissemination protocols for VANET (Vehicular Ad-hoc NETwork) applications are proposed, with the aim to extend the space coverage of the RSUs (Road Side Unit) and also to support infotainment traffic: they're called SAF and TAF. Such protocols will be tested by using ns-2 (Network Simulator 2) together with SUMO (Simulation of Urban Mobility) and MOVE in order to get comparisons among other possible solutions. Such a software stack will provide an outstanding car movement simulation, together with the well-known reliability provided by the network simulator ns-2. The treatise will proceed as follows: in chapter 1 there will be an introduction about VANETs, their lower layers, their main features and protocols, together with their possible applications; in chapter 2, the most known routing protocol solutions will be analyzed, together with our new protocols; then in chapter 3 the software stack (SUMO+MOVE+NS-2)
7

which was put together for the analysis of such protocols will be detailed. In particular, in chapter 4, there will be details about the coding and the new modules implementation performed; all of the simulation stack's parameters chosen for the simulations will be outlined in chapter 5, where the author will also provide and analyze the results of the simulations. This work was created for a project issued by Telecom Italia Ricerca e Innovazione.

Chapter 1: An outline about Vehicular Ad-hoc Networks

Intelligent transportation systems (ITS) address the critical problem of traffic safety. Bodies (like IEEE, CALM and C2C-CC) under ITS made tremendous efforts for achieving this goal by making the road traffic management efficient through help of different applications and protocols. The ratio of road accidents can be reduced by using proper traffic management applications. ITS is working on such traffic management solutions to make our vehicular systems safe and better. ITS also discusses the security issues related to these safety applications. Organizations like, International Standard Organization (ISO), Institute of Electrical and Electronic Engineers (IEEE) and Car-to-Car Communication Consortium / GeoNet are working on ITS architecture proposals. IEEE introduced a complete protocol stack of 1609 protocol family and named it WAVE (Wireless Access in Vehicular Environment). The standard is divided in different sub standards to ensure a modular handling of the diverse issues at different layers. It supports dedicated short range communications (DSRC) and it enlists two modes of communication: safety applications (Non-IP), and non-safety applications. The approved frequency band is 5 GHz in Europe (5.9 GHz in the USA). The DSRC and WAVE standards have been the center of major attention in both research and industrial communities. In the last three years, WAVE standard was the third best seller standards in the history of the IEEE [1].
9

This attention reflects the potential of WAVE to facilitate much of the vehicular safety applications . Dedicated Short- Range Communications (DSRC) is a suite of standards at the heart of the communication of vehicular safety messages. The fast exchanging of safety messages, combined with knowledge about other moving vehicles that may not be visible to drivers in a timely manner extend the safety concepts beyond people's today imagination. Wireless Access in Vehicular Environment (WAVE) is a term used to describe the suite of IEEE P1609.x standards that are focused on MAC and network layers. WAVE is fairly complex and is built over the IEEE 802.11 standards by amending many tweaks to guarantee fast reliable exchange of safety messages. WAVE is the core part of DSRC . Since the early 1990s, the interest towards vehicular networks started to increase and after almost a decade of DSRC standards development, the IEEE 802.11p standards were created along with IEEE 1609.x. Both standards represent together the proposed DSRC suite of standards, also if the 802.11p is still under a form of consecutive amendments for the more general 802.11 suite, thus the full protocol is still not completely standardized. DSRC is currently considered the most promising wireless standard that can be used to connect infrastructure (like road- side) to vehicle (I2V) and vehicle-to-vehicle (V2V). It uses cheap, short-range, two-way Line-ofSight (LoS) communications with, sufficiently high bandwidth. DSRC applications lend themselves, naturally, to localized road communications which lead to a much desired distributed decentralized deployment. While the cellular or WiMax bandwidth may appear to provide higher bandwidth, sharing that bandwidth over geographically larger area brings down the effective bandwidth. The LoS constraint can also be mitigated by mounting DSRC devices at higher elevations. This standard is not expected to replace other wireless technologies, nor is it expected to uniquely serve all vehicular communication needs, rather DSRC is seen as the main candidate for safety, short-range applications, subscription free services, road toll services, and other similar localized applications [2]. DSRC is capable of delivering 27 Mbps data-rate by using a two way lineof-sight short-range radio which is significantly lower cost compared to cellular, WiMax or satellite communications as illustrated in Fig. 1. DSRC

Figure 1: DSRC versus other wireless technologies

10

Figure 2: A VANET scenario, with multi-hop communication among OBUs and RSUs

operates in stringent environment which requires; fast communications to maintain the connection with speeding vehicles at all times, strict QoS committed to predefined threshold delays for safety messages, minimal use of transmission power, and maintaining privacy and anonymity of roaming users in addition to many other environmental challenges. In order to understand the WAVE architecture and various WAVE elements, it is important to learn about the typical DSRC devices and components. The DSRC network is built over two basic units; Road-Side Unit (RSU) and On-Board Unit (OBU). The RSU is, typically, a stationary unit that connects roaming vehicles to the access network, which, intern, is connected to a larger infrastructure or to a core network. The OBU is, typically, a network device fixed in a roaming vehicle and is connected to both the DSRC wireless network and to an in-vehicle network. As OBUs move between communication zones, vehicles exchange information with the roadside; in addition, vehicles use the same WAVE media to communicate with each other. Examples of the functioning of these devices can be found in Fig. 2. To define different WAVE communication zones, think of the term WAVE Basic Service Set (WBSS) as a unique identifier for each communication zone. Vehicles must associate with only one WBSS at a time. When the communication takes place among two vehicles, then it's a V2V communication; if, instead, it's established among the vehicle and the RSU, then this is the case of an I2V. OBUs are expected to join the WBSS of the closest RSU, exchange information, and typically leave within limited time
11

Figure 3: The DSRC standard suite

(mean estimate 3.6 sec). DSRC networks use WAVE Short Messages Protocol (WSMP or WSM for short) to exchange safety information between vehicles and roadside or just between vehicles. WAVE devices employ an architecture that supports a predefined Control Channel (CCH) and multiple Service Channels (SCHs). The CCH is used to transmit WSM and to announce WAVE services, while a carefully selected SCH is used for commercial application interactions and data transmissions.

1.1 The Considerations

WAVE

Architecture

and

General

Wireless communication between DSRC devices uses IEEE 802.11 and 802.11p standards as a lower layer close to the physical layer. The DSRC MAC layer uses IEEE WAVE standards which follows IEEE 1609.x standards. Then the higher layers employ IPv6 and other common protocol stacks like TCP/UDP for instance. This structure is illustrated in Figure 3. Such a figure also represents, in a more generic fashion, the term DSRC, which is somehow used as an umbrella term for the whole stack of the
12

Figure 4: A channel division in the WAVE standard

figure. WAVE is a mode of operation used by IEEE 802.11 devices to operate in the DSRC band. It is based on the IEEE P1609 series of standards, which define the architecture, the communications model, the management structure, the security and physical access features for vehicular communications. The primary architectural components are the Road-Side Units (RSUs), the OnBoard Units (OBUs), and the WAVE interface. The IEEE P1609 series comprise of the following standards and each of them deals with a specific area : 1. IEEE P1609.1 [4] is about the WAVE Resource Manager. It describes the key components of the WAVE system architecture and defines data flows and resources as well as the command message formats and data storage formats. It also specifies the types of devices that may be supported by OBUs. 2. IEEE P1609.2 [5] deals with the Security Services for Applications and Management Messages. It defines the secure message formats and processing and the circumstances for using secure message exchanges. 3. IEEE P1609.3 [6] is about the Networking Services. It defines network and transport layer services, including addressing and routing, in support of secure WAVE data exchange. It also describes the WAVE Short Messages (WSM), providing an efficient WAVEspecific alternative to IP that can be directly supported by applications. It also deals with the Management Information Base (MIB) for WAVE protocol stack. 4. IEEE P1609.4 [7] describes the enhancements to 802.11 MAC to support WAVE. The WAVE standard, in general, is thought for a particular radio arrangement: like it is shown in Fig. 4, there are several sub-channels, each one of them for a particular aim. A typical WAVE device uses the Control Channel CCH and at least one Service Channel SCH as long as it remains connected to the same WBSS. The High Availability Low Latency (HALL) channel is being left for future use. In most current prototypes, channel 172
13

is unused. As a general rule, CCH (178) is exclusively used to communicate safety and control information while SCH is typically used to communicate IP-based services. Consequently, each communication zone must utilize channel 178 (CCH) as a CCH used for safety messages, then, it may utilize one or more SCH of the available four service channels. Devices initiating WBSS are encouraged to avoid using the same SCHs selected by immediate neighbors. WAVE relies on the IEEE 802.11a Orthogonal Frequency Division Multiplexing (OFDM) mechanism to provide data transmission rates of 9, 12, 18, 24, and 27 Mbps for 0- 60 Km/hr vehicle speed and 3, 4.5, 6, 9, and 12 Mbps for 60-120 Km/hr vehicle speed. The system comprises 52 subcarriers, modulated using BPSK, QPSK, 16-QAM, or 64- QAM. Convolution coding is used with a coding rate of 1/2, 2/3, or 3/4. The data rates are determined by coding rate and modulation type. The multi-channel operation in the WAVE mode is based on a combined FDMA/TDMA channel access scheme . A mobile/stationary station switches its channel between the control channel and a service channel every channel interval. The default value for the control/service channel interval is set to 50 ms in the standard. Time intervals within which all stations must stay on the CCH are mandatory, and then a station can stay on one of the four SCHs. The CCH is for delivering WAVE-mode management frames (e.g., WAVE service advertisement) and the SCHs are for delivering data frames. It's clear that during a CCH interval, no station can stay on any SCH. As such, if two stations would like to exchange a large volume of data with no interest in any services advertised on the CCH, they will be obliged to waste one half of the bandwidth of a SCH because they need to switch back and forth between the CCH and a SCH: this grants that they can receive important safety messages on the CCH in a timely manner, also if they're enjoying a particular service on a precise SCH (i.e. paying for a toll road or listening to free parking slots outside a mall). According to the multi-channel operation in the WAVE mode, a standard service is structured this way: when a station wants to provide a service to other stations, it first needs to form a WAVE basic service set (WBSS) to let other stations to join. The station forming the WBSS is called the provider and the one joining the WBSS is called the user. After a station joins a WBSS, it can start exchanging data frames with the provider. When the provider wants to form a WBSS, it broadcasts a WAVE service advertisement (WSA) frame on the CCH during the CCH interval. The WSA frame carries the information about which one of the four SCHs is chosen for the WBSS during the next SCH interval. The user joins the
14

WBSS after receiving the WSA frame. At the beginning of the next SCH interval, both the provider and the user switch their channels from the CCH to the same SCH specified in the WSA frame. Then, the provider starts sending data frames to the user during the SCH interval. Before ending the WBSS, the provider can send a WSA frame during each CCH interval to let other users detect and join the WBSS. On the other hand, during the CCH intervals, the user detects and receives the WSA frame to detect new WBSS or operational parameter updates of existing WBSSs. After sending out all data frames, the provider ends the WBSS and the user leaves the WBSS after it receives no more data frames during a whole SCH interval. There are some proposals to extend the SCH interval of 2-3 time intervals before returning to the CCH, in order to maximize the bitrate [8], since the nature of the network is highly unstable and a link that in a fraction of second exists, the next second could be no more available. Timing and synchronization are clearly very relevant subjects in this kind of communication structure. Among proposed synchronization mechanisms, two major approaches seem to gain popularity within the WAVE standards community. First approach allows WAVE devices to align their radio clock to the earliest clock signal the device receives. This distributed system has built-in robustness since roaming devices can adopt different clock reference as they move to newer communication zones. There are no concerns about nation-wide failure or fears of nation-wide attacks because any synchronization failure would be local to devices in a single communication zone. However, there is a little guarantee that WAVE devices cannot be led to follow invalid or malicious clock, which could be used to distribute obsolete security certificates. Furthermore the process of continuously drifting the clock results in lesser efficiency in terms of radio resource utilization. The second approach assumes the availability of global clock signal with sufficient accuracy (like UTC) . This kind of synchronization is perfectly presumable, since OBUs are to be mounted on cars, which most likely can access a GPS navigator (reasonable hypothesis since an OBU is active on the vehicle), which is able to provide an external and accurate synchronization. This second system is, nowadays, the one adopted by the current WAVE standards. It is important also to highlight the WAVE Short Message Protocol WSMP since it is unique to DSRC. WSMP packets may require special services like being transmitted using a particular power or data-rate. These unique requirements impose challenges to the WAVE-MAC layer and below. The MAC and PHY layers must test the contents of each packet to adjust radio power and data-rate before each packet transmission .
15

Another issue of major concern of this architecture is scalability. The expected size of DSRC network is high enough to raise scalability concerns. The, interference with non-DSRC devices magnifies scalability concerns even further. Up to this date, there have been almost no publications on the issue of DSRC scalability and load balancing. A problem with using and assigning IP addresses also arises.

1.2

WAVE Communication patterns

In this subsection there's a brief analysis of some communication operative patterns. The first pattern under exam is the one of the WBSS vs. non-WBSS operations , which can be mapped to vehicle-to-roadside vs. vehicle-tovehicle communications. In this subsection there's also the definition of WAVE communication service types and WBSS initiation, operation and termination. Finally, the management of changes to WBSS operations. The section ends with discussion of the main issues pertaining to WBSS and communication types. WAVE communication services provide data communications over two protocol stacks, namely; IPv6 and WAVE Short Message Protocol (WSMP). WSMP is unique to the WAVE standards and is designed for use by specialized applications like safety applications. Applications using WSMP may initiate a WBSS to configure the SCH for their use. It's important to notice that availability of SCH is optional since WSMP can be exchanged on the CCH even in the absence of WBSS (i.e. in a V2V scenario). While the use of WBSS is expected to be dominant in DSRC networks, it is not necessary the case. WAVE devices can communicate WSMP messages over WAVE networks without WBSS. A scenario involving WSMP use without WBSS goes like this: a source WSMP application registers with the WME, then, composes WSMP data for transmission, and addresses WSMP data to a broadcast MAC address. The MAC reads the required channel information (power level, data rate) from the packet header and sets the CCH for transmission using the channel parameters as requested (power level, data rate). Transmission
16

takes place based on both internal contention and media contention. Then, a receiving device accepts the packet and passes it up the communication stack. The WSMP stack delivers data to the locally registered application, based on the Provider Service Identifier (PSID) and on the Provider Service Context (PSC). At this point, the receiving application knows the availability and address of the transmitting application, and can continue the exchange on the CCH if desired, using either unicast or broadcast MAC addresses, as appropriate. When operating with a WBSS, a WAVE device initiates the WBSS at the request of any application running on (or through) the same device. The WAVE device initiates the WBSS on the CCH of the provider [6]. WAVE supports two types of communication services: persistent and nonpersistent ones. The distinction among them is that a persistent WBSS is announced each CCH interval, and a non-persistent WBSS is announced only on initiation (on a proactive and reactive behavior). A usage of the persistent WBSS would be to offer an ongoing service to any devices that gets in visibility like the case of a roaming OBU. A usage of the non-persistent WBSS would, typically, be to support an on demand service like the case of downloading files while waiting in a parking lot. A persistent WBSS is announced periodically, and could be used to support an ongoing service for indefinite duration, such as general Internet access or services announcement, like in a publish/subscribe system (or better, in our case, the usual service of parking lot finder outside a mall or services like short podcasts about the location, what there's to see around, restaurants and other services). Persistent WBSS communication service resembles the normal vehicle operations on the road. A nonpersistent WBSS is announced only on WBSS initiation, and might be used to support a WBSS with limited duration. Both Persistent and nonPersistent operations use repeat announcements, but only Persistent WBSS re-broadcast the repeats each CCH interval. A possible example of nonpersistent service is a gas station which provides a consistent service with the possibility of downloading more content from the web, like movies or navigators software updates (which are usually only performed at home). In WAVE communication services, WAVE devices may take the role of either provider or user on a given WBSS. This is determined by the role chosen by the application operating on the device. The provider device generates announcements to inform other devices of the existence of the WBSS, and the presence of the associated application services. The user role is assumed by devices that join the WBSS based on receipt of the announcement. A device may change its role when it participates on a different WBSS. The terms 'provider' and 'user' do not imply any particular
17

behavior of the applications once the WBSS is initiated or joined. A device can be a provider for one service and a user for another one. The initialization of a WBSS is done by the WME (WAVE Management Entity) when a provider application redefines some of the WBSS parameters (i.e. the persistence status). The announcing WAVE device forms the Provider Service Table PST. As soon as a user application starts on a WAVE device, it must register all services it might need from the local WME. Upon the receipt of a WAVE service announcement, the receiving WME checks whether the provider application, defined by the Provider Service Identifier (PSID) in the announcement, is of interest to any locally registered user applications. User applications have the option to be informed of announcement containing both PSID match. When a match is found, the WME takes one of two actions, depending on the user application registration parameter. In the simple case, the WME generates the necessary MAC primitives to cause the local device to join the announced WBSS, by tuning device to the correct SCH at the correct time, and by setting any other lower layer configuration parameters appropriately to support the communications. Alternately, the user application may choose to reconfirm before joining of the announced WBSS. This gives the user application an additional control leve, by allowing any application to decline participation in specific service if it has recently accomplished some other milestone objectives (I could no longer be interested in getting a Podcast about Caserta, if I already passed the Napoli Nord bareer, and thus the exits for Caserta, and I'm now approaching Napoli). Upon decision to join the announcing WBSS and as soon as the communication parameters are set successfully setted-up, the WME sends a notification to the local user application, which is ready for exchanging data. The WBSS stays in place at the local device until it is terminated. The termination is managed in a very easy way: when a WAVE device wants to end the communication, it simply leaves the channel without any further advice: this is a big difference with the Publish/Subscribe systems. There can be an exception and the device may decide to issue a request to its MAC layer to leave a WBSS and to inform all the affected applications through a notification (i.e. process WBSS termination) in any of the following situations: Priority: there's traffic with higher priority on another channel (i.e. safety broadcast traffic) Loss of signal: due to the volatile nature of the network, it may happen that the SCH remains inactive, most likely after the loss of the transmitting WBSS.
18

 Activity completion: all of the applications indicate they finished their activities and they change their status accordingly. Security failure: security credentials of the WBSS elapses and/or they're invalid, so the user cuts-off the service.

1.3

MAC layer and QoS

Among the greatest worries in a communication system, willing to support real-time communication is the medium access control (MAC). This method decides who has the right to transmit on the channel and when such a transmission can take place. In order to guarantee a timely delivery, such that time-critical communication tasks meet their deadlines, the MAC scheme must provide a finite worst case access time to the channel. Once channel access is a fact, different coding strategies, diversity techniques and retransmission schemes can be used to achieve a sufficiently reliable transmission. However, if the MAC scheme does not provide an upper bound on the maximum time before channel access, it is not possible to give any guarantees about meeting deadlines. In the vehicular communications standard IEEE 802.11p, a contentionbased MAC method, the carrier sense multiple access (CSMA), is used. This implies that it is not possible to provide a finite upper bound on the time to channel access. However, as long as the system load is not too heavy, CSMA usually behaves satisfactory. Great work within standardization for vehicle communication systems has, therefore, been devoted to enhance this MAC method by providing different quality of service (QoS) classes for traffic with different priorities [9], which grants a better balancing in the system load. However, the main problem of unpredictable delays in CSMA remains. The MAC schemes in the literature that are targeting VANETs are either based on CSMA or TDMA: CSMA has the drawback of not being deterministic and it is generally not possible to make adjustments or additionsin order to let it behave deterministically. However, there exist enhancements providing different priority levels (like in [10]), such that packets with higher priorities wait a shorter time period before channel access: this allows to always being able to grant a reasonable priority for
19

Figure 5: QoS architecture in the 802.11p standard

safety information and reducing and controlling the network load, too, with a reasonable traffic shaping. However, despite these enhancements collisions may still occur and when they do, a transmitter with higher priority data traffic will randomize a shorter backoff time than transmitters with lower priority traffic. This way, unbounded delays are reduced for higher priority data traffic, also if not completely removed. This type of priority mechanism can also be found in the IEEE 802.11e standard, which is being used by the IEEE 802.11p one. Also hypothesis on black bursts were made, but they aren't actually considered in the current 802.11p standard. If we consider using TDMA, there's a good example in [11], where the protocol uses time slots to achieve collision-free transmission of data. The time slots are assigned by also considering a SDM (space division multiplexing ), where the road is first divided into subspaces, and within each subspace a TDMA scheme is applied. Each vehicle will use different time slots depending on where it is currently situated. This assignation scheme, anyway, suffers from the need of a tight synchronization and of an exact space awareness, which are necessary elements for the correct behavior of the protocol, but which, at the same time, are something that is not easily obtained in a highly mobile VANET. At this level, it's very important to understand how to perform channel routing and channel selection and subsequently how to implement QoS.
20

WAVE QoS inherits the fundamental aspects of 802.11e and it actually extends it in order to cover two channel operations: the WAVE and 802.11p follows the 802.11e Enhanced Distributed Channel Access (EDCA) QoS paradigm and one of the major additions in WAVE networks, with respect to the standard 802.11e functions, is the transmission of WSMP packets. Every packet of this type should be transmitted with specific features directly included in the packet: data-rate, channel number and transmission power. The WAVE design extrapolates the 802.11e EDCA architecture, as illustrated in Figure 5, in order to service both IPv6 and WSMP packets. The WAVE MAC architecture is distinguished from the 802.11e one by implementing Access Category queues on a per-channel basis and by the addition of Channel Coordination Function (CCF). The CCF implements a Channel Router and a Channel Selector, like explained below. The Channel Router detects the arrival of a WSMP datagram by checking the Ether Type field in the header. Such a channel router thus forwards the WSMP datagram to the correct queue based on the channel which is identified in the WSMP header and on the packet priority. If the WSMP datagram is carrying an invalid channel number, the packet is dropped without forwarding any error to the sending application. Besides the WAVE mode, the IP datagram transmission is slightly different: before initializing IP data exchanges, the IP application registers the transmitter profile with the MLME (extended in 1609.4 [7]). The transmitter profile contains SCH number, power level, data rate and the adaptable status of these last 2 parameters. When an IPv6 datagram is passed from the LLC to the Channel Router, it routes the datagram to a data buffer that corresponds to the current SCH. At any given time, there is only one active transmitter profile in a WAVE device. If the transmitter profile indicates a specific SCH which is no longer valid, the IP packet is dropped and no error message is issued to the sender application. After the description of the channel router, the Channel Selector is now being examined: it carries out multiple decisions, like when to monitor a specific channel, what are the set of legal channels at a particular point in time and how long the WAVE device monitors and utilizes a specific channel. The Channel Selector also decides to drop data if it is supposed to be transmitted over an invalid channel like in the case of a channel which doesn't exist anymore. The set of policies enforced by Channel Selector can be fairly complex: such policies are defined and transmitted to the Channel Selector through the WME as outlined in fig. 5 and they're provided as Management Information Base (MIB) by the IEEE 1609.4 standard.
21

This document already anticipated the concept of priority: it can be used in several ways. Applications have their own priority level, which is specific for the applications and it is used by Networking Services in order to decide which application gets the preferred access to the communication services. A different concept is the priority assigned to network data traffic. The lower layers use a separate MAC transmission priority to prioritize packets for transmission over the wireless medium. IP packets are assigned the MAC priority associated with the traffic class of the generating application. The MAC priority for WSM packets is assigned by the generating application on a per packet basis. Upon the arrival of a datagram to the Channel Router, it forwards the datagram to the appropriate channel and data queue. Such a priority queue is selected by mapping the User Priority (UP as defined in transmitter profile) to an Access Category Index (ACI), as shown in fig. 5. The Channel Selector schedules data for external contention by managing priority queues based on their ACI. The Channel Selector also configures and confirms the media use of desired channel information. It's important to notice that the mechanisms analyzed until now only involve hop by hop priority. It is clear and desirable that QoS is also performed on a end-to-end way in order to optimize the process of selecting a particular data route to the destination. Most of the research and publications on 802.11e QoS cannot be applied here without major redesign, mainly because optimum queuing on one channel is suboptimal when we change channels. Also the requirement of having predefined delivery time for all safety messages requires the design of an algorithm that guarantees delivery in a deterministic, rather than statistic, manner. The 802.11p presents many tools for researchers to optimize channel utilization by tuning the policy parameters of the Channel Coordination MIB. An example of the kind of priority that is desired can be found in an urban scenario, with people acceding services provided by the RSU (like the previously hypothesized podcasts on the current location), which continues to be running, but without losing the information of a car crash not too far away from the vehicle. This means that safety messages (which are rare and not too heavy in terms of bytes or requested bitrate) should be routed before other kind of messages and cover a large area, no matter what. Concurrently, the users should be able to continue enjoying their service, by only experiencing a delay.

22

1.4

Related Standards and Possible Applications

Besides WAVE, it's appropriate to write about some related standards, too: ISO CALM and Car to Car Consortium (C2C-CC) . ISO CALM: It was designed in order to provide continuous V2V, V2I and V2O (Vehicle to Other interfaces) communication. The concept of CALM [12] is based on heterogeneous cooperative communication framework. Different projects like COOPERS and SAFESPOT included the main concept of CALM in their work. Even C2C-CC incorporated the CALM idea for use of multiple interfaces for vehicular communication networks. The ISO working group TC204 WG16 is working on seamless connectivity issues. CALM standard is also principally based on 5.9 GHz DSRC concept. This standard has been adopted in many countries including Australia, some countries in Asia and South America. For short and medium distances, CALM recommends Infrared, while for long distances, it prefers the use of UMTS/3G or any other technology available at PHY layer, since the use of satellite links, especially as the backbone, is costly, but CALM has kept the option open, anyway. A management entity (CCME) is defined in CALM [12] to provide flexibility and adaptability features. Basically CCME consist of three components: CALM Interface Manager: it monitors and stores the status of each communication interface (CI), along with its channel quality, thus providing an aid in making decisions. CALM Network Manager : it manages the process of handover to alternate media. It allows IPV6 nodes to move from one IP subnet to another. CALM Application Manager : it ensures application transmission requirements; it also interacts with interfaces to get information about the most suitable medium and instructs CALM Network Manager to establish the connection. ISO CALM is apparently very flexible in design, with less than 1ms link setup time. It's popular in its design as it provides combination of different technologies for communication as well as it has space in its design to incorporate future technologies: it's very flexible. However, researchers are still facing a lot of confusions for its implementation, since CALM is a combination of different technologies and then its implementation and provision of different interfaces is a tough job. There is still no support in any simulator for
23

complete CALM protocol stack. Car to Car Consortium (C2C-CC) : it aims to establish an open European industry standard, focused on the development of active safety applications. The C2C-CC is backed by European automobile industry and it's designing C2CNet protocol . This protocol differs from IP and it is destined to be used for both safety and non safety applications. Also, a single protocol is being considered for use with both the infrastructure and the ad-hoc modes. The routing is handled through position based algorithms and a dedicated bandwidth of 30 MHz will be available for safety applications in the 5.9 GHz band. In C2C-CC, Network Layer (C2CNet) provides multi-hop communication based on geographical addressing and routing. Such a network layer also provides beaconing for vehicle movement. Beaconing, location service and data forwarding are the main components of geographical routing. The features that will be provided by C2C-CC are the following: fast data transmission for V2V and V2I communications; support for the transmission of different types of messages including safety messages and infotainment; different short range wireless LAN technologies including IEEE 802.11p, traditional wireless LAN technologies (i.e. IEEE 802.11a/b/g/n) and other radio technologies (e.g. 3G or UMTS ). Unlike WAVE and CALM, safety applications are not restricted to use C2C-CC transport and network layer. Similarly, non-safety applications can use traditional TCP/IP to access wireless multi-hop communications in order to reach the OBUs and the RSUs; they can also use C2CNet below IP stack. After this brief screening of the standards this document is going to focus on some applications that can be used in VANETs. Safety applications have the ability to reduce traffic accidents and to improve general safety. These can be further categorized as safety-critical and safety-related applications. In the design of security, it's important to keep a focus on being sure safety messages are not forged. They divide into two main types: safety-related and non-safety-related. Safety-critical: These are used in the case of hazardous situations (e.g. collisions). The situations where the danger is high or danger is imminent are also included in this category (strong and fast braking of multiple cars, car or big object in the middle of the road, also after direct signalization of vehicles). Safety-critical applications involve communication between vehicles (V2V) or between vehicles and infrastructure/infrastructure and vehicles (V2I/I2V).
24

Other examples of this category are things like the wrong way driving warning: a vehicle detecting that it is driving in wrong way (i.e. wrong way on a highway, like sometimes happens with tragic consequences in terms of human lives and times of recover from the subsequent crash), signals this situation to the other vehicles and road side units. Safety-related: these include safety applications where the danger is either low (curve speed warning) or high (work zone warning), but still foreseeable [13]. In safety-related applications, the latency requirements are not as stringent as in the case of safety-critical ones, but still it's significantly relevant. Safety-related applications can be V2V or V2I/I2V. Some examples of such applications can be assisted vehicle overtaking: it aims to prevent collision among vehicles in an overtake situation, where one vehicle is willing to overtake another vehicle, while a third vehicle is already performing an overtaking maneuver; the collision among the vehicles can be this way prevented by informing the first vehicle to stop its overtaking procedure. Another example can be the emergency vehicle warning: an active emergency vehicle (i.e. ambulance, police car) informs other vehicles in its neighborhood to free an emergency corridor. This information can be re-broadcasted in the neighborhood by other vehicles and road side units. Besides the safety applications, non-safety ones can also be hypothesized, and in the author's opinion, here should lie the the greatest attention, because in an optic of building infrastructures (RSUs) and selling/equipping cars with network devices (OBUs), there should be a wider use of such devices, besides the simple safety matter, which is very important, but also quite rare (hopefully). In order to let government and private citizens buy this hardware there must be other reasons, linked to the application world: services also connected to traffic, like WAZE [14] or gmaps, which interconnect the human-usable systems (i.e. using a smart phone while in the car) with the automata of network signaling. An example lies in the possibility of receiving signaling when the road in front of the vehicle is going to be congested, in order to be able to re-route accordingly, besides the normal use of navigation systems (GPS). The reason for this application is that the GPS is not always on, like when the road to cover is well-known (i.e. road to work), but it is still useful to know if there will be a congestion problem, an accident or else, in front of the vehicle.
25

Scenarios with broadcast podcasts from ProLoco can be reasonably useful, like ads from the local restaurants, hotels or businesses in general. Other applications could be thought for this kind of network: payment services like electronic toll collection, parking management (i.e. knowing in advance if there are upcoming parking lots or if the mall's parking is full or where I can find some space, etc) can be putted-up. These applications should, of course, receive less priority with respect to the safety-related ones, but could push privates or government to build the necessary infrastructure.

26

Chapter 2: Routing protocols in VANETs

The design of routing protocols in VANETs is an important and necessary issue for support the smart ITS. The key difference among VANET and MANET is the special mobility pattern and the topology, which is varying in a very fast manner, so MANETs protocol are mainly too heavy or simply don't work effectively in a VANET scenario. This section will investigate some of the possible routing solution for this architecture: unicast protocols, multicast protocols, geocast protocols and broadcast (dissemination) protocols. Besides, the temporary network fragmentation problem and the broadcast storm problem should also be considered in order to design routing protocols in VANETs: it seriously affects the successful rate of message delivery in such kind of networks. It's vital to make an introduction point about what kind of routing protocols can be created and what's their aim. As a first candidate to be examined, the unicast routing protocols are taken in exam. Their main goal in VANETs is to transmit data from a single source to a single destination via wireless multi-hop transmission and/or carry-and-forward techniques. As a result, unicast routing is a fundamental operation for vehicles to construct a

27

Figure 6: Main categories and features of VANET routing protocols

source-to-destination routing in a VANET. On the other hand, broadcast protocols are used when a source vehicle sends broadcast messages to all of the other vehicles in the network (i.e. safety messages). As shown in Figure 6, there are two main categories of routing protocols: topology-based and geographic routing ones. The former uses the links information that exist in the network in order to perform packet forwarding; the latter, instead, uses neighboring location information to perform packet forwarding. Since link information changes on a regular basis, topologybased routing suffers from a too fast routes disconnection. It's clear that in such an environment, the routing protocols will be using the topology or the geographic position of the nodes, since the information related to their movement and to the topology are vital in an environment that, in few seconds, can change completely. Because of this, the analysis is going to be focused on the protocols in fig. 6 with a last citation of a new protocol which takes care of bounding the delay in the transmission. The main distinction among the routing protocols is their general behavior, which can be proactive (overhead data exchanged to build and maintain routing tables) or reactive (route discovery and construction only ondemand basis). It's clear that proactive protocols may have a faster response to the routes request, because they probably already keep in memory the right route to use, but the cost of the proactive behavior, if it's already too high in regular ad-hoc networks, thus usually declaring AODV as winning protocol, in VANETs becomes definitely unaffordable, since the routes vary too rapidly, thus making vane the process of routes discovery for all the existing routes
28

(which is how a proactive protocol normally behaves) and at the same time occupying most of the available bandwidth with protocol overhead traffic [18]. Reactive protocols, instead, create a route only when it is necessary for a node to communicate with another one. They only maintain the routes that are currently in use, thereby reducing the burden on the network. Reactive routings typically have a route discovery phase where query packets are flooded into the network in search of a path. The phase completes when a route is found, but such a broadcast traffic is only limited to this discovery phase. In the following sections, some VANET protocols will be briefly analyzed , divided in topology-based and in geographic ones.

2.1 Topology-based Routing Protocols

Node movement in VANETs is usually restricted in just bidirectional movements constrained along roads and streets. So routing strategies that use geographical location information obtained from street maps, traffic models or even more prevalent navigational systems on-board the vehicles make sense. This fact receives support from a number of studies that compare the performance of topology-based routing (such as AODV and DSR) against position-based routing strategies in urban as well highway traffic scenarios (like in [16] and [17]). Therefore, geographic routing (position-based routing) has been identified as a more promising routing paradigm for VANETs. Anyway, still one protocol, quite explicative of the category, will be analyzed.

29

2.1.1 Fisheye state routing (FSR)

In the FSR protocol [18], every node maintains a topology table (TT) based on the latest information received from neighboring and periodically exchange it with local neighbors. For large networks to reduce the size of messages, the FSR protocol uses different exchange periods for different entries in routing tables. Routing table entries for a given destination are updated preferably with the neighbors having low frequency, as the distance to destination increases (if a destination is very far from the vehicle containing the TT, then it's less likely and less frequent for him to broadcast this routing entry, with respect to a destination which is few hops away and thus it's better to disseminate this route to the neighbors, in order to propagate the near route as far as possible). The problem with the FSR routing is that with the increase in network size, the routing table also increases and so the overhead messages which are broadcasted to announce all of the routes. Moreover, as the mobility of the vehicles increases, routes to remote destinations become less accurate. It's also important to notice that if the target node lies out of scope of source node, then route discovery fails.

2.2 Geographic Routing in VANETs

This treatise already examined a methodology based on the topology. In this section, instead, methods based on the actual position of the nodes will be examined. As it's going to be clear, they're also better scalable with respect to the ones in sect 2.1 of this document. Here's the functioning: each node forwards packets basing only on local information, trying to minimize the remaining distance to the destination; such routing schemes are only feasible if the target is identified by a geographical reference and if there is a Location Service, which knows the node's geographic location in relation to its identity. Usually, vehicles can obtain position information from systems like GPS and Galileo. Hence, many protocol designers have
30

employed geographic routing as the basis for VANET specific solutions. Geographic routing (also called geo-routing or position-based routing) is thus a routing principle that relies on geographic position information. It finds the most suitable applications in wireless networks, with the basic idea that the source sends a message to the geographic location of the destination instead of using the network address, in an approach which is quite different with respect to the standard IP-centric approach usually adopted in routing protocols. This procedure requires that each node can determine its own location and that the source is aware of the location of the destination. With this information, a message can be routed to the destination without the knowledge of the network topology or without a prior route discovery phase, which is the best feature of this sort of protocols, because of the fast mobility of the nodes. The fundamental principle of this routing class is based on a greedy approach: a node forwards its packet to the neighbor that is the closest to the destination. Indeed, the forwarding decision, at every node, is primarily taken by basing on the position of the destination node and on the position of the one-hop neighbor nodes. Greedy forwarding tries to bring the message closer to the destination in each step by only using local information. Thus, each node forwards the message to the neighbor that is most suitable from a local point of view. There are various approaches proposed in literature in order to determine the most suitable neighbor to forward the packet to: it can be the one which minimizes the distance to the destination in each step (Greedy) or, alternatively, other approaches are proposed, like the minimum angle between neighbor and destination (Compass Routing), etc. Figure 4 shows these various possible algorithms usable by S to transmit data to D. In the following the routing protocols are classified on the basis of the assumptions taken into account, so we describe each routing protocol class first in general and then in a more detailed way by the description of specific routing protocols of the class. In these position-based routing protocols, the position of the destination is stored in the header of the packet by the source (with its position too) or in general, the coordinates are always included in the packet header. Such coordinates are quite easily retrievable, since in the VANET contest, it's clearly supposable that every car which mounts an OBU, always equips a GPS (Global Position System) navigator, too, that is able to provide the coordinates to the OBU. Since geographic routing protocols do not exchange link state information in order to setup a route and do not maintain established routes, like proactive and reactive topology-based routing protocols, they are more robust and better focused on the highly
31

dynamic environments like VANETs. As illustrated in fig. 6, Geographic routing protocols are divided into three main categories: non-Delay Tolerant Network (non-DTN), Delay Tolerant Network (DTN), and hybrid ones. The non-DTN geographic routing protocols do not consider intermittent connectivity and they perform at good levels only in VANETs with high vehicle density, whereas DTN geographic routing protocols take into account the intermittent connectivity and behave accordingly. Hybrid geographic routing protocols, instead, combine the non-DTN and DTN routing protocols to exploit partial network connectivity. By usually relying on greedy heuristics, the geographic routing protocols choose as next hop, the neighbor which provides the greater advance towards the destination position (i.e. the one which is physically closer to the destination).

2.2.1 Greedy Perimeter Stateless Routing (GPSR)

One of the first and well-known protocols implementing position-based routing is GPSR [19]. It combines greedy forwarding and face routing. The algorithm is based on two different routing methods. The first method is the Greedy Packet Forwarding method: a node A forwards a packet to its geographically closest neighbor with respect to the destination node. This method is used as long as possible, in some case until the destination is reached, but when a packet arrives on a node (called local maximum) where the Greedy Packet Forwarding algorithm is not able to find a neighbor which satisfies the best proximity criterion (because of obstructions or voids), then a recovery mode is used to forward the packet and the Greedy Packet Forwarding procedure is changed into Perimeter Mode. When a packet enters perimeter mode at x, GPSR forwards it along the face intersected by the line xD in fig. 7. x forwards the packet to the first edge counterclockwise about x from the line xD. This determines the first face over which to forward the packet. Thereafter, GPSR forwards the packet around that face using the right-hand rule.
32

Figure 7: A Perimeter Forwarding example

The perimeter mode has two components: one is the distributed planarization algorithm that makes local conversion of connectivity graph into planar graph by removing redundant edges. The second component is online routing algorithm that operates on planer graphs. The packet resumes forwarding in greedy mode when it reaches a node whose distance to the destination is smaller than the distance of the node at the local maximum to the destination. In the GPSR Protocol, all nodes in the network have a local table, in which all of their neighbors are listed by name (ID) and position. A proactive Broadcast (Beacon message) refreshes this table at a regular time interval. The source node gives the packet a destination address. This address will not be changed by the forwarding nodes. The Greedy Packet forwarding assumes the source (S) knows the geographic position of the destination (D). This position will be inserted in the packet. The node who has to forward such packet, looks in his local table (where the position of all in-visibility nodes is listed) for the nearest node to the destination. A node between source and destination will receive the packet. It repeats the search performed by the first node and forwards the packet to the nearest node with respect to D and so on until the data packet arrives to the destination. When a packet enters the perimeter mode, GPSR records in the packet the location Lp, indicating the site where greedy forwarding failed. This location is used at subsequent hops in order to determine whether the packet can be returned to greedy mode. The problem with this protocol is that it involves sending the message to intermediate neighbor instead of sending to the farthest node and this method introduces long delays due to greater number of hop counts. Due to rapid movement of vehicles, routing loops are introduced and this brings
33

the dissemination of messages to longer paths.

2.2.2 Geographic Source Routing (GSR)

Geographic Source Routing (GSR) assumes the aid of a street map in city environments. GSR essentially uses a Reactive Location Service (RLS) to get the destination position. The algorithm needs global knowledge of the city topology as it is provided by a static street map. Given this information, the sender determines the junctions that have to be traversed by the packet using the Dijkstras shortest path algorithm. Forwarding between junctions is then done in a position-based fashion. Packets are thus forwarded greedily between junctions. GSR does not consider the connectivity between two junctions; therefore, the route might not be connected through. Recovery when such a case happens is greedy forwarding. By combining the geographic routing and topological knowledge from street maps, GSR proposes a promising routing strategy for VANETs in city environments. The simulation results in [18] demonstrate that GSR has better average delivery rate, smaller total bandwidth consumption, similar latency of first delivered packet with DSR and AODV .

2.2.3 Anchor-based Street and Traffic Aware Routing (A-STAR)

Position-based routing for VANETs faces great challenges in a built-up city environment. Generally, vehicles are more unevenly distributed due to the fact that they tend to concentrate more on some roads ranter than other
34

ones. Their constrained mobility by the road patterns, along with more difficult signal reception due to radio obstacles (such as high-rise buildings) may lead to VANETs disconnected graphs. A new position-based routing technique called A-STAR (Anchor-based Street and Traffic Aware Routing) [22] has been proposed for such city environments. A-STAR uses the street map to compute the sequence of junctions (anchors) through which a packet must pass in order to reach its destination. But unlike GSR, A-STAR computes the anchor paths with traffic awareness. In fact, A-STAR differs from GSR and GPSR in two main aspects. Firstly, it incorporates traffic awareness by using statistically rated maps (counting the number of city bus routes on each street to identify anchor paths of maximum connectivity) or dynamically rated maps (dynamically monitoring the latest traffic condition to identify the best anchor paths) to find an anchor path with high connectivity for packet delivery. Secondly, A-STAR employs a new local recovery strategy for packets routed to a local minimum that is more suitable for a city environment than the greedy approach of GSR and the perimeter-mode of GPSR. In the local recovery state, the packet is salvaged by traversing the new anchor path. To prevent other packets from traversing through the same void area, the street at which local minimum occurred, is marked as out of service temporarily. The out of service streets are not used for anchor computation or recomputation during the out of service period and they resume as operational after the time out duration. With traffic awareness, A-STAR shows the best performance compared to GSR and GPSR, because it can select paths with higher connectivity for packet delivery.

2.2.4 Vehicle-Assisted Data Delivery (VADD)

VADD protocol adopted the idea of carry-and-forward for data delivery from a moving vehicle to a static destination. The most important issue is to select a forwarding path with the smallest packet delivery delay. In order to keep data transmission delay as low as possible, VADD protocol transmits packets through wireless channels as much as possible, and if the packet
35

Figure 8: VADD routing protocol forwarding process

has to be carried through roads, the road with higher speed is chosen as first. VADD protocol assumes that vehicles are equipped with pre-loaded digital maps, which provide street-level map and traffic statistics such as traffic density and vehicle speed on roads at different times of the day. According to the information provided by digital maps, VADD protocol proposed a delay model to estimate the data delivery delay in different roads. With such a delay model, VADD protocol estimates the best road with the lowest data delivery delay based on the current traffic patterns: roads with high densities are preferred, also if they don't satisfy the minimum hop count criterion. This preference is adopted in order to grant the connectivity of the traversed network, like it's illustrated in fig. 8.

2.3 Dissemination Routing

A particular attention is dedicated, in this document, to the routing protocols which take care of the dissemination process. The protocol that is going to be proposed in this document (see later in this chapter), belongs to this category, so in this section, the treatise will focus on some points which characterize the dissemination protocols, by adding some relevant examples. A key issue is reaching of OBUs in the service area while avoiding the broadcast storm problem that can arise, especially in dense urban scenarios.
36

Indeed this problem may become very significant if the VANET is used for sending not a single packet (as may happen in the safety case) but a flow of several packets at a given bit rate. In the VANET data dissemination framework several solutions have been proposed. The work in [24] is based on a simple but quite effective way for reducing the redundant rebroadcasts and the consequent medium contention and collisions. The Distance Defer Transmission (DDT) protocol in [24] consists in relaying messages only by the receiver that is the farthest from the sender. In order to do that, each vehicle that receives a message waits for a defer timer which is inversely proportional to the sender-receiver distance before retransmitting it. In this way, the farthest vehicle retransmits the message first. A problem that can arise in this kind of solution is that a vehicle that is quite close to the initial transmitter but is the only vehicle in an intersection point different from the farthest vehicle does not transmit and its intersection direction is not covered. To overcome this kind of problem different protocols have been proposed. The Road Oriented Dissemination (ROD) protocol [25] disseminates data separately in each direction, optimizes data dissemination in the intersection, and does not abandon dissemination if no relay is found. To fulfill the first two points ROD, as in DDT, uses the GPS position of the vehicle that is encoded in the header of the broadcast message. In addition, ROD encodes an extra information: the outgoing intersection position and the ingoing intersection one. The work in [26] on the basis of some geometrical rules classifies vehicles according to the way they move and by this classification the propagation effect to vehicles in same roads is limited. A different kind of solution is proposed in [27]. The authors propose the Urban Multi-Hop Broadcast (UMB) protocol that selects the node farthest from the transmitter to relay a message and uses repeaters at intersections to retransmit a message and overcome the problem of large buildings obstructing a message path's intersection. The protocol assumes that all vehicles will be equipped with GPS devices and digital maps. Multi-hop data delivery through vehicular ad hoc networks is made harder by the fact that vehicular networks are highly mobile and sometimes sparse. Mobility prediction is used in other works (like [28]), where neighbors of the broadcasting vehicle are divided into several sets according to the movement direction. With respect to these works in this treatise, in Chapter 4, a new family of algorithms based on a principle called triangle forwarding, is proposed.

37

2.3.1 New Forwarding Algorithms: SAF and TAF

In this section we present our algorithms for spreading messages originating from the RSU in a service area that is larger than the RSU coverage one. This fact means that only a fraction of vehicles can be reached directly in a single hop. Multi-hop, inter-vehicle communications is necessary to reach vehicles in the whole area. We assume vehicles to be equipped with wireless communication, computation and storage capability. Moreover, each vehicle can collect its position data by a GPS device. This tratise will propose an algorithm to realize an efficient broadcast transmission. This algorithm aims to maximize the number of the nodes reached by the messages of RSUs and minimizing the number of the transmitting nodes (nodes which forward the message). Each message carries a sequence number and the coordinates of the sending node. Node I, upon reception of message from node j, creates and maintains a state defined by the tuple , t i , i , zi , where ti is the time of first reception of message ; i is the time of the scheduled forwarding; zi is the forwarding state. At the first reception of the message , the state is created with zi = 0 and i = ti + i . the forwarding delay i is computed accordingly to the distance between the recipient node i and the sending node j, dji , namely i = T (1 dji /R). The time interval T is the maximum forwarding interval. It should be chosen larger than the message transmission time , yet the smallest possible, since delay to spread the message increases with T . This treatise will take T as the reference unit of time. The computation of the scheduling delay i requires that the incoming message carries the coordinates of the sending node j. Only that information is required, plus static information (R, T) and data locally known to the receiver (its position). An example of the delay for the transmission is showed in fig. 9: the more a vehicle is next to the sender, the more he will wait before retransmitting the packet and viceversa. Node i schedules the forwarding of the message at time i. The Actual forwarding of that message is conditioned on the value of the state variable zi. The decision whether forwarding message or not is taken at time i.

Figure 9: Delay before re-transmitting the packet

38

When node i eventually forwards or discards message at the schedule time i, it sets zi = 1 in order to avoid sending duplicate messages. At each reception of a copy of message , node i updates its internal state variable z i according to zi min{zi + 1, 2zi + 1}. So, if zi = 1, it remains unchanged; this is consistent with the fact that node i is done with message and no further forwarding action is to be taken for that message. Therefore, node i will discard any copy of message which is received when zi = 1. If instead zi 0, then it is incremented by one and it represents the number of copies of message that node i has received in the time interval (t i , ti +i ), before node i has itself completed its operations with that message. In fact, message forwarding by node i is conditioned on the value of z i at schedule time i . If at time i = ti + i it is zi = 0, message is forwarded: node i has not heard any other node in its proximity which is forwarding that same message, except node j. If instead it is zi > 0, then node i checks a so called triangle rule, detailed in the following subsection. The aim is to avoid redundant forwarding. Whatever the result of the rule, message is deleted and the state is set to zi = 1, that is to say, either node i forwards the mes sage or it gives up forwarding and disposes of the message . When a node receives the same message from two different sources, it is able to define a triangle with the three involved vehicles as vertexes (see Figure 10). It uses the following geographical information: its geographical position, according to the on-board GPS device, RX(x, y); the geographical position of the node that has transmitted the first received copy of the message, TX1(x, y); the geographical position of the node that has

Figure 10: Triangles formed by the first and the second transmitter with the receiver RX

39

transmitted the second received copy of the message, T X2(x, y). Similarly to DDT and DBF, in our algorithms when node Rx receives a packet from another node (e.g. TX1 in Figure 10), it schedules its transmission after a time interval , related to the distance TX1-RX. If, during , RX receives the same packet from another node (e.g. TX2), the forwarding state variable z will be greater than 0. In this case, DBF directly discards the packet setting z = 1, while in our three algorithms the node RX forwarding decision is updated on the basis of three different conditions, related to the triangle of vertexes RX, TX1 and TX2. If the triangle condition is verified for each new copy of the packet, received during the time interval , the packet is forwarded at the end of this one, otherwise node RX discards it, thus setting the forwarding decision value to z = 1. In the first version of the algorithm, called SAF (single angle forwarding), node RX calculates cos (see Figure 10) and compares it with a fixed threshold th . Node RX broadcasts the packet at time only if cos < th . For each new copy of the packet received before the scheduled forwarding time expiration , the node forwarding decision is based on the triangle formed by its position, the position of the new transmitting node and the position of the one that has transmitted the last packet copy. In the second version of the algorithm, called TAF (two angles forwarding), node RX calculates the cosines of the two angles e in Figure 10 and it forwards the message if both of them are lower than the threshold th . As with SAF, for each new copy of the packet received before the scheduled forwarding time expiration , the node calculates the two angles on the basis of the triangle formed by its position, the position of the new transmitting node and the position of the one that has transmitted the last packet copy. This particular logics are implemented in order to solve a possible DBF/DDT issue. Such a protocol was imagined for a highway scenario, like the one in fig. 11, where it's also possible to understand the delay system of the standard protocol. After the first transmission by TX1, RX receives the packet and so does TX2, but the former will have an higher delay to wait with respect to TX2, which will then be able to re-broadcast the packet before RX, thus minimizing the number of forwards (RX will then be inhibited).

Figure 11: A standard DBF forwarding scenario

40

This protocol, anyway, is going to fail in an urban scenario, like the one in packet from an external node, then it waits for its timer and then rebroadcasts it. Both TX2 and RX will receive the packet, but since RX is next to TX1 (the sender), then his delay will be too long, thus allowing TX2 to retransmit the packet. This scenario will spread the packet on the horizontal line, but not on the vertical street, because RX receives the packet, but it doesn't broadcast it anymore. The proposed protocols, with the triangle rule, want to solve this issue. Proofs of the effectiveness of these protocols are provided in Chapter 4.

Figure 12: An urban scenario in the DDT/DBF case, highlighting a problem which is solved by our SAF and TAF protocols

41

Chapter 3: The Simulation Stack Realized

In order to perform simulations on the desired protocols and to get results and realistic evaluations about them, the author putted together a simulation stack composed by 3 software products: SUMO (Simulation of Urban Mobility), MOVE (MObility model generator for VEhicular networks) and NS-2 (Network Simulator 2). These 3 instruments provide, respectively, the traffic model, the interface with extended functionalities and the network traffic simulator. This protocol stack was studied in order to get the most realistic simulation

NS-2

Move Sumo
Figure 13: The simulation stack used in this treatise

TCL

Converter

42

scenario, with respect to the mobility of the vehicles that, in a VANET becomes a very important factor. SUMO, is a well-known instrument which generates the vehicles traffic with a specific programming language. It manages single vehicles and their features. Its output is in a specific format which is auto-consistent, but it's not directly integrable with network simulation instruments. At this point, in fact, MOVE is used. Previously instead of this software, another one was used, named TRACI, whose development is now over, so the best choice to replace it is MOVE. It provides a graphical interface for this Java software and it connects SUMO with the upper levels, by providing a direct connection with the latter, which allows to use SUMO functionalities through this software, by making available several functions, which make our traffic model very flexible (the maps can be totally random, like Manhattan or spider grids, or chosen and designed by the user); also the traffic model can be random (user can decide flows of traffic from one point to another one of the map) or totally decided by the user. This instrument has also a high level of detail (semaphores, number of lanes, maximum speed, kind of streets, and so on). Vehicles movement is also very realistic, where, besides the start and end point of every vehicle, the user can also decide a random probability of turning (and thus changing his route to the destination) for the vehicles on the map. Also tram and bus lanes can be added. Then, as it's illustrated in figure 13, the MOVE software, after the scenario setup phase, generates the model by relying on SUMO and then converts its output in a .TCL file. This file is the input file for the ns-2 simulator. At this level of the simulation stack, finally a realistic model is present and converted in the TCL file (as a-periodic movement vectors related to the nodes). The ns-2 software can now take care of the network part, by simulating the network traffic which is going to be injected into the network. It simulates the nodes behavior at every level of the network protocol stack: physical layer, MAC with 802.11p parameters, routing protocols, transport protocols and application layer. The simulator itself has a low support for the mobility, but this aspect is completely managed by the MOVE+SUMO stack, so ns-2 has only to perform its network simulation. Before analyzing further the elements of this stack, the treatise will focus on the mobility model and on a brief analysis of what kind of models can be realized.

43

3.1 Mobility Models

The Mobility Model governs the set of rules that define movement pattern of nodes in an ad-hoc network. Network simulators can then, by using this information, create random topologies based on nodes position and perform some tasks between the nodes. Using VANET pose a challenge and that is how to separate a mobility model at Macroscopic and Microscopic level [29]. Mobility Model includes some constraints like streets, lights, roads, buildings, cars, vehicular movements and inter-vehicle behavior. These constraints are divided into two parts that are dealt with separately. The node mobility includes streets, lights, roads, buildings etc and is classified as Macroscopic, whereas the movement of vehicles and their behaviors are classified as Microscopic. We can also analyze mobility model as Traffic generator and Motion generator. Motion constraints are designed by car driver habits, cars and pedestrians and describe each vehicle movement. The Traffic generator creates random topologies from maps and defines the vehicular behavior under this environment. The mobility model is described by the framework, which includes topological maps like lanes, roads, streets, obstacles in mobility and communication model, car speeds, the attraction and repulsion points, based on traffic densities relating to how the simulation time could vary, vehicular distribution on roads and intelligent driving pattern. In order to come up with a real world simulation, a mobility model must be generated. One way of capturing a realistic model would be generating patterns from traces or using some realistic models. There are various kind of models, which can generate mobility patterns based on certain criteria. While it is hard to present real world traffic scenarios in a single simulation model, ways can be adopted to develop a protocol suite which can support the implementation. The mobility patterns can be generated from various models. The author's simulation stack relies on the Synthetic model, but for the sake of information, the treatise will briefly analyze the main features of the possible mobility models. Survey models: they represent realistic human behavior in urban mesh environments. The model relies on data collected through surveys performed on human activities. Observing this behavior and record it is not simple and only certain government branches or private authorized businesses can do so and they're not likely willing to share this information.
44

 Event driven models: also called trace models, they can be used to monitor the movement of human beings and vehicles, analyzing them and generating traces based on their locomotion. In [30], the author presented a WLAN mobility model, in which he observed the characteristics of WLAN users across the campus. In [31], the author observed how WLAN users connect with infrastructure network. There must be an actual map of the space; the traces could be gathered for the purpose of obtaining a probabilistic mobility model reflecting the real movement on the map. This helped in obtaining discrete event Markov chain, which considered the source, destination paths, and the current and previous location. The problem with this model was that the characteristics of mobile nodes with access points were considered only; no relationship between the nodes was considered. The problems in such models are co-relation of different traces that were developed for specific purpose and also that there are limited simulators available for such purposes e.g. ELDA (Event Driven Light-weight Distilled StateCharts-based Agents) model is an event driven mobility model based on MAO models (Mobile Active Object) and MAS models (Multi Agent Systems) deriving characteristics of behavioral, interaction and mobility models. Software Oriented Models : various simulators like VISIM, CORSIM and TRANSIM are able to generate the traces of urban microscopic traffic. VANETMobiSim uses TIGER database and Voronoi graphs to extract road topologies, maps, streets etc for the network simulators. The problems with such simulators are that they can only operate at traffic level and cannot generate realistic levels of details. Moreover the interoperability with network simulators and the generated level of details seems insufficient for network simulators . Synthetic Model : most of the work has been carried out in the area of synthetic modeling and the simulation stack putted together by the author bases on this kind of model.. All models in this category use mathematical equations to develop realistic mobility models. The strength of mathematical models is validated by comparing them with real mobility models. One way of comparison is to conduct a survey and gather results and then compare the results obtained from the survey and synthetic models. Synthetic models can be divided into 5 main categories: 1. Stochastic model: deals with totally random motion. 2. Traffic Stream model: examines the mechanical properties of
45

mobility model. 3. Car Following model: monitors the behavior of car-to-car interaction. 4. Queue model: considers cars as standing in queues and roads as queue buffers. 5. Behavioral models: examines how movement is influenced by social interaction. For example if we consider a mobile node in an area and observe its movement, it can either move in a fixed line or could follow a random path. The WWP (Weighted way point: Destination is chosen on the basis of current location and time) and RWP (Random way point: Destination is chosen randomly) mobility algorithm calculate mobility pattern of a node by defining certain mathematical equations. The synthetic model imposes certain limitations such as excluding a real human behavior model hence restricting its abilities to create random topologies. A greater level of detail is requested for these models, since they're quite relevant in a general fashion and in particular for this treatise, which uses one of these ones in order to model the traffic. The Synthetic mobility model is classified under the following criteria: 1. Traffic Level Criteria : The traffic level presents level of details that are concerned with streets, obstruction in communication paths, lights and vehicular densities. For the simulation to capture details at traffic level, it must include the following traces: Movement topologies : Movement topologies are key features for simulation and are used to calculate some

Figure 14: Some examples of mobility models

46

important factors like speed and distances etc. The topologies are represented with the help of graphs and are classified into the following three types: Custom graphs, where edges are connected by vertexes (Figure 14a); random graphs, generated by using algorithms (Figure 14b) and topologies from maps (graphs from GDF (Geographical Data Files) and TIGER database), as in Figure 14c. Start and end positions: the time a node starts its movement marks its initial position and it is referred to as repelling state, as the node traverses a certain path until it reaches its final position which can be referred to as its attracting point. These two points outline the start and end point for the vehicle. After the graphs are generated, the nodes source and destination points are defined for simulation. Trip Creation : during simulation, the vehicle navigates through different points. These different points are called trip for vehicle. Selection of Track : the algorithms define the track between paths. Speed of Vehicles : The speed of the vehicle depends on the road conditions and can be either smooth or arbitrary. 2. The Motion Level: After all the details at the traffic level have been captured, the motion level starts playing its part by creating topologies between the nodes and by analyzing their behavior based on the details gathered at traffic level e.g a car may change its lane and try to overtake. It also monitors the situation during heavy traffic flow or vehicles standing in queue following each other. Motion level feature also defines human behavior patterns through their movement which aids in finding vehicular behavior .Such models are commonly adopted from mathematical equations which produce all possible vehicular behavior patterns. There are various models that fall under this category .The most widely used model is the car following model. This model describes the process of vehicles following each other in the similar line. The car following model is one of the widely used model that presents details at motion level. It describes the process of cars following each other in the same
47

lane.

3.2 SUMO (Simulation of Urban MObility)

Figure 15: Level 1 of the simulation stack: SUMO (Simulation of Urban MObility)

SUMO (Simulation of Urban MObility) is a continuous, microscopic and multi-modal traffic simulation and is, in spite of its name, also capable of modeling traffic on networks which are larger than single cities, e.g. highway networks, without any changes. SUMO is conceived to simulate a traffic road network of the size of a city. As the simulation is multi-modal, which means that not only are car movements within the city modeled, but also public transport systems on the street network, including alternative train networks, the atomic part of the simulation is a single human being. This human being is described by a departure time and the route he/she takes which again is made up of subroutes that describe a single traffic modality. Thus, a simulated person may take his/her car to the nearest public transportation system station and continue his travel by other means of transport. Apart from movements using motorized vehicles, a person may also walk. Walking is not simulated at all but is modeled estimating the time the person needs to reach the destination. The traffic flow is simulated microscopically. This means, that every vehicle that moves within the simulated network is modeled individually and has a certain place and speed. In every time step which has a duration
48

of 1 second, these values are updated in dependence to the vehicle ahead and the street network the vehicle is moving on. The simulation of street vehicles is time-discrete and space-continuous. As our car-driver model is continuous, as the majority of car-driver models are , we decided to use this approach. When simulating traffic, the street attributes, such as maximum speed and right of way rules (street precedence), are regarded.

3.2.1 Protocol Features

The traffic simulator provides a good series of features which are listed below: Collision free vehicle movement Different vehicle types Multi-lane streets with lane changing Junction-based right-of-way rules (junctions with Streets having equal / different priorities, e.g. right-before-left) Lane-to-lane connections A XML-raw-output containing information about The state of the net for every time step Includes all applications needed to prepare and perform a traffic simulation (network and routes import, DUA, simulation) Simulation Space-continuous and time-discrete vehicle movement Different vehicle types Multi-lane streets with lane changing Different right-of-way rules, traffic lights A fast openGL graphical user interface Manages networks with several 10.000 edges (streets) Fast execution speed (up to 100.000 vehicle updates/s on a 1GHz machine) Interoperability with other application at run-time
49

 Network-wide, edge-based, vehicle-based, and detectorbased outputs Network Import Imports VISUM, Vissim, Shapefiles, OSM, RoboCup, MATsim, openDRIVE, and XML-Descriptions Missing values are determined via heuristics Routing Microscopic routes - each vehicle has an own one Different Dynamic User Assignment algorithms High portability Only standard c++ and portable libraries are used Packages for Windows main Linux distributions exist High interoperability through usage of XML-data only Open source (GPL)

3.2.2 The Simulation Model

The model used currently within SUMO is the Gipps model extension (invented and described in: Krau 1998, Janz 1998). It is capable of displaying main features of traffic like free and congested flow. In each time step the vehicles speed is adapted to the speed of the leading vehicle in a way that yields to a collision-free system behavior within the following simulation step(s). This velocity is called the safe velocity vsafe, and is computed using the following equation:

where vl(t) is the speed of the leading vehicle in time t ; g(t), the gap to the leading vehicle in time t ; , the drivers reaction time (usually 1s) ; b, the deceleration function ; To bind the acceleration to the vehicles physical abilities, the resulting
50

wished or desired speed is computed as the minimum of the vehicles possible maximum velocity, the vehicles speed plus the maximum acceleration with the safe velocity computed as shown above, therefore a vehicle will not drive or accelerate faster than is possible for it:

Further, the driver is simulated by assuming he is making errors and so fails to perfectly adapt to the desired velocity. This is done by subtracting a random human error from the desired speed:

As the vehicle must not drive backwards, once again, after the previous computations, the maximum of the computed speed and zero must be taken and will be the vehicles final speed for the current time step. This model is collision-free to allow simulations without any artifacts that arise from the imperfection of the underlying model (an impressive indepth description of the model and the underlying assumptions and rules may be found in Krau 1998 and Janz 1998). As illustrated in fig. 16, it's possible to also see the attention to the microscopic model, where the speed depends on the preceding vehicle speed. This is an attention which avoids collisions and makes the model closer to reality. Traffic lights are part of the model and they play an important role within the traffic management as they improve traffic flow. Apart from simple right-of-way rules, each simulated junction may also be a junction with traffic lights. As some junctions in Germany allow to ignore the red stoplight when turning right, an extension to the right-of-way rules regarding this is being implemented. By now, two different outputs are available. The first is a so-called raw output which contains all edges (streets) and all lanes along with the vehicles driving on them for every time step, where vehicles are described by their name, position and speed. This output is complete and may be used

Figure 16:Car following model: the speed of the following vehicle depends on the preceding one

51

as input to post-processing tools for evaluation. However, a large simulation produces a nearly unmanageable amount of data, so other outputs have been invented. The first processed output that may be generated by the simulation, is a log-file made by simulated detectors which may be positioned on a certain position of a certain lane. These detectors are a simulation of induct loops and are able to compute the flow, the average speed on the lane, and other values. The results of this computation are written into a file using the CSV or the GnuPlot format. Every detector has its own file. Being a tool for traffic researchers, SUMO is designed to be fast and exact instead of trying to be a software that is pleasant to look at. So, the main program is meant to be started from a command line and produce an output which must be post-processed when one wants visual results. This prevents data arising from the GUI from slowing down the system, giving more memory and system time to the simulation itself.

3.3 MOVE (MObility model generator for VEhicular networks)

Figure 17: Move is at level 2 of the simulation stack

MOVE is a software which allows the user to have a graphical interface and interact with the huge complexity of SUMO through a graphical JAVA editor (which is illustrated in fig. 17). MOVE can facilitate simulation by generating mobility traces from the TIGER database or Google earth. In addition to that, it also supports
52

Figure 18: The MOVE interface

custom graphs defined by user and random generated graphs. But with random generated graphs, it restricts the node movement to grid i.e. the node should only move on the grid. MOVE uses parser to extract topological maps from above mentioned tools. MOVE is composed of a Map editor and Vehicular Movement editor. The Map editor creates topological maps for network scenario discussed above.
53

The vehicular movement editor generates movement patterns automatically or can also be defined by the users in the editor. For manual generation, a trip must be defined on the basis of either attraction or repulsion point or randomly. After configuring start and end positions, MOVE can generate random or activity based trip. Path is the suitable way to the destination. MOVE calculate paths by the mean of Random Waypoint Mobility model or using Dijksta shortest path first algorithm. Node velocity in MOVE is either smooth or road-dependent. MOVE does not contain any network simulation capabilities but instead it parses the traces to be furthered processed by the network simulator. MOVE generates topological maps using parses provided with the map editor and the node parameters that are defined with the help of the vehicular movement editor. This data is then passed to the network simulator. This way they both benefit from interpreters and are able to perform network and traffic tuning. MOVE can also generate its own mobility model but the results obtained are not satisfactory as compared to that of standard mobility models. The problem accompanied with this mobility model is the lack of support for large networks i.e. its packet delivery ratio drops as the number of nodes increase, moreover multiple radio interfaces are not supported by larger networks. While generating mobility traces, MOVE takes micro-mobility into consideration. The micro- mobility feature does not include any Lanechanging or Obstacle mobility models. The intersection management follows simplistic stochastic model and therefore random movement of a node in the topology is not considered. The car behavior and interaction with human behavior follows only the car following model. MOVE utilizes the federated approach, in which they both communicate via parser. The traces from the traffic simulators is sent to parser for the translation and then processed by network simulator. The updated file from network simulator is passed to traffic simulator through parser. The problem rose with this approach was the interaction between the two simulators were not held in timely manner.

54

3.3.1 The MOVE Architecture

MOVE consists of two main components: the Map Editor and the Vehicle Movement Editor, as shown in Figure 17. The Map Editor is used to create the road topology. Currently there are three different ways to create the road map: the map can be manually created by users, generated automatically, or imported from existing real world maps such as publicly available TIGER (Topologically Integrated GEographic Encoding and Referencing) database from U.S. Census Bureau. The Vehicle Movement Editor allows user to specify the trips of vehicles and the route that each vehicle will take for one particular trip. The output of MOVE is a mobility trace, generated based on the information users input in the Map Editor and the Vehicle Movement Editor, which can be immediately used by a simulation tool such as ns-2 to simulate realistic vehicle movements. Users can also visualize the generated mobility trace by clicking on the Visualization button on the main menu. Manual generation of the map requires inputs of two types of information: nodes and edges. A node is one particular point on the map which can be either a junction or the dead end of the roads. Furthermore, the junction nodes can be either normal road junctions or traffic lights. The edge is the road that connects two points (nodes) on a map. The attributes associated with an edge include speed limit, number of lanes, the road priority and the road length. The map can also be generated automatically without any user input. Three types of random maps are currently available: grid, spider and random networks. There are some parameters associated with different types of random maps such as number of grids and the number of spider arms and circles. Finally, one can also generate a realistic map by importing real world maps from publicly available database.

Figure 19: Two possible maps handled by MOVE. A random grid and an imported TIGER map

55

Currently MOVE also supports the TIGER maps which are available from U.S. Census Bureau. Figure 18 show s a grid map generated from the random map generator and a street map in the Houston area based on a TIGER database file. The movements of vehicles can be generated automatically or manually using the Vehicle Movement Editor. The Vehicle Movement Editor allows users to specify several properties of vehicle routes including number of vehicles in a particular route, vehicle departure time, origin and destination of the vehicle, duration of the trip, vehicle speed (acceleration, deceleration, maximum speed), etc. In addition, user can define the probability of turning to different directions at each junction (e.g. 0.5 to turn left, 0.3 to turn right and 0.2 to go straight) in the editor.

3.4 NS-2 (Network Simulator 2)

Figure 20: NS-2 is at level 3 in the simulation stack created by the author

Network Simulator (Version 2), widely known as NS2, is simply an eventdriven simulation tool that has proved useful in studying the dynamic nature of communication networks. Simulation of wired as well as wireless network functions and protocols (e.g., routing algorithms, TCP, UDP) can be done by using NS2. In general, NS2 provides users with a way of specifying such network protocols and simulating their corresponding behaviors. The version used in this treatise is the 2.34. Due to its flexibility and modular nature, NS2 has gained constant
56

popularity in the networking research community since its birth in 1989. Ever since, several revolutions and revisions have marked the growing maturity of the tool, thanks to substantial contributions from the players in the field. Among these are the University of California and Cornell University who developed the REAL network simulator, the foundation which NS is based on. Since 1995 the Defense Advanced Research Projects Agency (DARPA) supported development of NS through the Virtual InterNetwork Testbed (VINT) project. Currently the National Science Foundation (NSF) has joined the ride in development. Last but not the least, the group of researchers and developers in the community are constantly working to keep NS2 strong and versatile. Again, the main objective of this book is to provide the readers with insights into the NS2 architecture. This chapter gives a brief introduction to NS2. NS2 Beginners are recommended to go thorough the detailed introductory online resources. For example, NS2 official website [32] provides NS2 source code as well as detailed installation instruction. The web pages in [33] and [34] are among highly recommended ones which provide tutorial and examples for setting up basic NS2 simulation. These introductory online resources would be helpful in understanding the material presented in this paragraph.

3.4.1 NS-2 Architecture

Figure 21 shows the basic architecture of NS2. It provides users with an executable command, ns, which takes on input argument, the name of a Tcl simulation scripting file. Users are feeding the name of a Tcl simulation script (which sets up a simulation) as an input argument of an NS2 executable command ns. In most cases, a simulation trace file is created, and is used to plot graph and/or to create animation. NS2 consists of two key languages: C++ and Object-oriented Tool Command Language (OTcl). While the C++ defines the internal mechanism (i.e., a backend) of the simulation objects, the OTcl sets up
57

Figure 21: NS-2 architecture overview

simulation by assembling and configuring the objects as well as scheduling discrete events (i.e., a frontend). The C++ and the OTcl are linked together using TclCL. Mapped to a C++ object, variables in the OTcl domains are sometimes referred to as handles. Conceptually, a handle (e.g., n as a Node handle) is just a string (e.g., _o10) in the OTcl domain, and does not contain any functionality. Instead, the functionality (e.g., receiving a packet) is defined in the mapped C++ object (e.g., of class Connector). In the OTcl domain, a handle acts as a frontend which interacts with users and other OTcl objects. It may defines its own procedures and variables to facilitate the interaction. Note that the member procedures and variables in the OTcl domain are called instance procedures (instprocs) and instance variables (instvars), respectively. Before proceeding further, the readers are encouraged to learn C++ and OTcl languages. The author refers the readers to [35] for the detail of C++, while a brief tutorial of Tcl and OTcl languages are provided through the already given references. NS2 provides a large number of built-in C++ objects. It is advisable to use these C++ objects to set up a simulation using a Tcl simulation script. However, advance users may find these objects insufficient. They need to develop their own C++ objects, and use a OTcl configuration interface to put together these objects. After simulation, NS2 outputs either text-based or animation-based simulation results. To interpret these results graphically and interactively, tools such as NAM (Network AniMator) and XGraph are used. To analyze a particular behavior of the network, users can extract a relevant subset of text-based data and transform it to a more conceivable presentation. In this treatise, as it will be explained in Chapter 4, several improvements are provided and new network protocols were written and integrated into this simulator, together with TCL specific files.
58

Figure 22: A sample chain of events in a discrete-event simulation. Each event contains execution time and a reference to the next event. In this figure, Event1 creates and inserts Event5 after Event2 (the execution time of Event 5 is at 3.7 second).

3.4.2 Implementation of Discrete-Event Simulation and Network Objects in NS-2

NS2 is a discrete-event simulator, where actions are associated with events rather than time. An event in a discrete-event simulator consists of execution time, a set of actions, and a reference to the next event. These events connect to each other and form a chain of events on the simulation timeline (e.g., that in Fig. 22). Unlike a time-driven simulator, in an eventdriven simulator, time between a pair of events does not need to be constant. When the simulation starts, events in the chain are executed from left to right (i.e., chronologically). NS2 simulation consists of two major phases: network configuration and Simulation phase . Phase I: Network Configuration Phase : in this phase, NS2 constructs a network and sets up an initial chain of events. The initial chain of events consists of events which are scheduled to occur at certain times (e.g., start FTP (File Transfer Protocol) traffic at 1 second). These events are called at-events. This phase corresponds to every line in a Tcl simulation script before executing instproc run{} of the Simulator object. Phase II: Simulation Phase : this part corresponds to a single line, which invokes instproc Simulator::run {}. Ironically, this single line
59

contributes to most of the simulation. In this part, NS2 moves along the chain of events and executes each event chronologically. Here, the instproc Simulator::run{} starts the simulation by dispatching the first event in the chain of events. In NS2, dispatching an event or firing an event means taking actions corresponding to that event. An action is, for example, starting FTP traffic or creating another event and inserting the created event into the chain of events. In Fig. 22, at 0.9 s, Event1 creates Event5 which will be dispatched at 3.7 s, and inserts Event5 after Event2. After dispatching an event, NS2 moves down the chain and dispatches the next event. This process repeats until the last event corresponding to instproc halt{} of OTcl class Simulator is dispatched, signifying the end of simulation. In a more general fashion, NS2 is a simulation tool designed specifically for communication networks. The main functionalities of NS2 are to set up a network of connecting nodes and to pass packets from one node (which is a network object) to another. A network object is one of the main NS2 components, which is responsible for packet forwarding. NS2 implements network objects by using the polymorphism concept in Object-Oriented Programming (OOP). Polymorphism allows network objects to take different actions ways under different contexts. For example, a Connector object immediately passes the received packet to the next network object, while a Queue1 object enques the received packets and forwards only the head of the line packet. There are four major classes of NS2 components, briefly illustrated hereafter: 1. Network objects: they are responsible for sending, receiving, creating, and destroying packet-related objects. Since these objects are those derived from class NsObject, they will be referred to hereafter as NsObjects. 2. Packet-related objects: such objects are various types of packets which are passed around a network. 3. Simulation-related objects: they control simulation timing, and supervise the entire simulation. Examples of simulation-related objects are events, handlers, the Scheduler, and the Simulator. 4. Helper objects: such objects do not explicitly participate in packet forwarding. However, they implicitly help to complete the simulation. For example, a routing module calculates routes from a source to a destination, while network address identifies each of the network objects.
60

The simulator, in general, manages all the levels of the simulation, from the PHY parameters, attenuation models, until the application level. Every level is simulated with all of the attached coherent processes (e.g. time for a packet to be passed up through the ISO/OSI stack levels): also every kind of overhead (in terms of time or space) is perfectly simulated, like the overhead introduced on every packet by the headers. When a simulated packet arrives at a node, it is processed like in the reality: every header is decapsulated and interpreted by the current level and then it proceeds to the upper levels. The same happens on sending, where such headers are compiled and inserted in the packet. Also propagation errors, collisions and more is simulated. Further details about this will be provided in the next chapter, where all of the selected parameters and models for the simulation will be analyzed.

61

Chapter 4: New protocols in implementations

NS-2

and

other

In this chapter there will be a description of the implementations performed and of the new coding work realized for providing the new dissemination protocols. In particular, there will be a brief overview about the NS-2 hierarchy, showing some of the major challenges of the implementation; then, the treatise will focus on the protocols implementation in NS-2, plus some needed code for the flooding protocol (which wasn't originally provided by NS-2). There will also be details about the AWK generation for the interpretation of the results which came out from NS-2 simulations.

4.1 Structure of NS-2 Inheritance and Major Challenges

Most of the implementation needed for this work was realized in the NS-2
62

Figure 23: A general high level class reference in NS-2

simulator. Although there are guides like [36], the NS-2 software is an open source one, so everybody contributes to its development and new versions are often released with new components that may or may not depend on the previous ones, but above all, freelance developers, like the author himself, can contribute with new pieces of code to the brand new release of the product. This brings to several problems and invalidates modularity, which is not completely granted, since when you start developing new protocols, you should use the other levels classes (e.g. implementing a routing protocol will require to interact and send commands to the second layer protocols and to the application protocols), which, also by themselves, interact with still other classes and stack levels. Clearly, this brings to the impossibility to use guides like [36], since they refer to old versions of the simulator, where things changed, especially in the way resources are managed and where or what class you should use in order to perform specific operations; thus, the author had to re-discover the whole process on his own and start the work by the scratch. As it's possible to see in fig. 23, besides the normal inheritance mechanism, there's a two-sided inheritance to keep under control, which is the one of the pure C++ objects (on the right in fig. 23) and the one of the TCL Objects (on the left), which are commanded by the logic in the right side. In general, the NSObject is the main class of the protocol: it represents the
63

Figure 24: An example of the class interaction diagram for the new agents implemented by the author

objects (like the 3-rd layer of a particular node) and then there's the Connector class, which represents the physical/logical connections that may be there at several layers (so, like objects, there's a connector for every layer of every node). Such classes are managed by the C++ logic, which is, by the Handler class, which handles the single events that occur in the simulation (e.g. a new node joins the network, a packet is sent from level 3 to level 2 of node A, etc). On the other side, the TclObject class takes care of the conversion of such logics at the TCL level, so in the specific simulation instantiation. When developing, you have to take care that every little piece falls in the right place and you have to be sure of using the right classes at the right time. In the author's implementation, for example, he had to insert new routing protocols, so he had to manage all the right calls for the other levels of the stack and make every piece of the code perfectly integrated with the rest of the software. Working at the routing level, like the author did, in order to implement the new routing algorithms, means to create a new agent, which is generically called myagent in fig. 24 and fig. 25. This agent will have to interact in the right way and at the right moment, with the classes that are illustrated in the figures, in order to get coherent traces when the simulation ends and in order to grant some modularity, so that such protocols will be able of being inserted in future releases of NS-2 in order to help the community. The inheritance diagram is in fig. 25 and it helps to understand where the author's agent collocates in the diagram of fig. 23 (which is on the right
64

Figure 25: Inheritance diagram of the agents created by the author

side of the picture, in the protocols logic). One question may arise: why one only diagram for many protocols implemented ? The answer is simple. The protocols implemented are all routing protocols, so they should perform similar operations on similar classes, the very same classes which cooperate to the global functioning of the protocol, so the interactions with the other classes are the same, also if they are performed in different ways and modes in the diverse routing protocols implemented by the author. Also the inheritance diagram of fig. 25 is the same for all of them, since a routing protocol must be handled (Handler Class), its network layer should be logically connected to other nodes (Connector Class) and, above all, the class to be implemented will be an agent (Agent Class), which is the generic object in NS-2 that actually does something: for this reason, the inheritance diagram is the same. The polymorphism will do the rest in the specific implementation of the various functions that can or cannot rely on the father's implementation of every specific method (which in the higher classes is mostly virtual). One last thing should be mentioned. Keeping left side of fig. 23 coherent
65

with the logics in the protocols, is something which is obtained by correctly addressing the TclObjects in the protocol itself (mostly through the command() function and through the constructor) and in the TCL file used by the simulation. The necessary modifications to the internal files of the simulator were also performed, in order to link the new protocols in the simulator and specifying the new structures created, which have to be included among the many modules of the software.

4.2 NS-2 Protocols implementation

In order to perform the desired simulations, the author had to implement several protocols. Clearly the new protocols proposed in this treatise, SAF and TAF (see Chapter 2) were implemented, but also some other protocols, already existing in literature or well-spread, had to be implemented, since they were not present in the simulator's last release. In fact, the DBF protocol (see sect. 2.3) was implemented by the scratch and so the flooding protocol, because it didn't existed a specific class implementing this logic, but there were only limited settings at TCL level to perform a flooding. Such settings didn't leave enough freedom to the author and didn't meet the complicate inputs that come out from the mobility simulators. For this reason, also the flooding algorithm has been implemented. Besides the algorithms quoted above, whose implementation will be detailed later on, also other algorithms were implemented by the author, by following similar logics with respect to TAF. For example, a TAF variant 1 algorithm, which only considers the last copy of a specific packet, in order to compute the triangle rule (instead of considering all of them), was implemented. Also the TAF variant 2, in which the logic on the triangle rule is inverse (the normal one is that if there's one packet that matches the triangle rule, then it forwards the packet after the scheduled delay; the variant 2, instead, is that if there's one packet that doesn't match the triangle rule, then the packet isn't forwarded after the delay), was implemented. Such variants were also implemented for the SAF protocol, but they're
66

essentially very similar to the basic protocols and in the preliminary tests they didn't perform as well as their basic implementations (SAF and TAF standard versions), so they were excluded from the analysis in Chapter 5. In general, the protocols are presented in a specific order (Flooding in sect 4.2.1, DBF in sect 4.2.2, SAF and TAF in sect 4.3.3), because most of the basic functionalities implemented in the protocols which are presented for first, are also there in the following protocols.

4.2.1 The Flooding Protocol

The implementation of the flooding algorithm is quite straight-forward. There's not really anything special, but since the author needed the logics of the protocol at the C++ level, then the implementation was made under the inheritance of the Handler class (see previous section). In particular, the Trace class, for tracing packets was made a friend class. The logic behind the protocol is pretty simple: when receiving a packet, which is broadcast because of the nature of the network, which only treats broadcast packets (VANET dissemination traffic), the node sends it up to the application level and then, if the TTL (Time To Live) is greater than zero, then the packet is modified in its header coherently with the new node that received it and then it's sent down to the lower layers that take care of the re-broadcast. It's clear that such a re-broadcast takes a while for the packet to pass through the layers, so every layer adds a jitter and in general, in order to avoid collisions, a little jitter (a random variable with values in [0 , 10ms]) is also added before the flooding re-broadcasting. A mechanism for an intelligent flooding was added, so the packet is re-transmitted only one time, after its first reception. This mechanism is added in order to get a more meaningful comparison among the protocols, thus giving more chances to the flooding protocol to get an acceptable result.

67

4.2.2 The DBF Protocol

For the creation of the DBF protocol, a timer class was added, in order to calculate the delay among the first reception and the re-broadcast of the packet. As it's possible to see from the above header code (DBF.h), there's a
#ifndef DBF_AGENT_H #define DBF_AGENT_H #include #include #include #include #include #include #include #include "agent.h" "ll.h" "trace.h" "classifier-port.h" "cmu-trace.h" //adds drops reasons in the trace file <iostream> "mobilenode.h" //to have node's declaration <timer-handler.h> //handles timer 0xff

#define ROUTER_PORT

class DBF; //forward declaration struct pktlist_entry { int nsaddr_t double double int bool Packet }; const int maxpkts = 500; struct pktlist_entry pktlist[maxpkts]; /* Timers Declaration*/ class DBF_PktTimer : public TimerHandler { public: DBF_PktTimer(DBF* agent) : TimerHandler() { agent_ = agent; } seqnum; src; //packet sender posx; //node's position on the x axis posy; //node's position on the y axis count; //heard counter expired; *pkt;

protected: DBF* agent_; virtual void expire(Event* e); };

structure called pktlist_entry which records the main features of the packets which every node receives. It's a light structure, which only records
68

the necessary parameters for the DBF to work. Every packet which is received is added to this list and then a timer (DFB_PktTimer) is started. The delay of re-transmission can be comfortably handled in the .cc file, where lies the implementation of methods and logics. When the timer expires, the packet retransmission is scheduled, unless the packet is already received. Since the re-broadcasting procedure is temporally ordered (in the sense that the first entries of the list are the first ones to be re-broadcasted), the list can be scrolled sequentially, thus allowing a faster computation of the algorithm, that will only have to perform a research on an ordered list, taking the first entry which is not expired (see the boolean flag in pktlist_entry). If a new packet arrives, which is already in the list, the timer won't start, and the counter count will be updated accordingly, so that when the timer expires, then if count is greater than 0, the packet won't be furthermost re-transmitted. It's also possible to notice the presence of posx and posy, responsible of recording in the data structure the position of the node who sent the packet. This is necessary in order to calculate the delay to re-transmit the packet, since a computation is performed with the distance between the receiver and the sender node. This parameter is not really mandatory to be recorded, but it was recorded in order to perform later analysis on the packets received by every node: its price is very low in terms of space and computational time (which is only the time of a write in RAM memory).
class DBF : public Agent { friend class Trace; friend class DBF_PktTimer; public: DBF(); virtual int command(int argc, const char*const* argv); virtual void recv(Packet*, Handler*); void trace(char* fmt, ...); void reset_DBF_pkt_timer(double delay); protected: Trace *tracetarget_; PortClassifier *dmux_; // This node; MobileNode *iNode; DBF_PktTimer pkt_timer_; pktlist_entry pktlist[maxpkts]; }; #endif // DBF_AGENT_H //Node pointer //Timer for sending packets. //packet list pointer

69

In the above code, instead, it's possible to see the declaration of the DBF class. The main methods are illustrated there. In particular, the recv function is worth of attention. Such a function, which ideally should only receive the packets, in a nutshell also sends them, because in this software, every protocol layer can receive packets from upside (e.g. application level) or downside (e.g. MAC level), so if it receives them from upside, it's a send operation because the upper layers wants to send a packet on the network; if from downside, it's a receive operation, because packet is arriving from the network and it's received by level 3. This is the reason why both receive and send operations are handled in one only function. This logic applies as a general rule in NS-2. There's a variable associated with the packet which tells the software if the packet is going up or down through the stack and this must be modified, for example, if you want to re-transmit a received packet (after, obviously, modifying the header).

4.2.3 The SAF and TAF Protocols

Both SAF and TAF protocols are very similar each other (see chapter 2, sect. 3), the only difference is that instead of performing the triangle rule on one only angle (like SAF), the TAF protocol performs it on 2 angles. This implies that the two protocols are very close each other in the implementation, too, since only the calculation of the second cosine is added in the forwarding condition.
struct pktlist_entry { int nsaddr_t double double int bool Packet }; seqnum; src; //packet sender posx; //node's position on the x axis posy; //node's position on the y axis count; //heard counter expired; *pkt;

By keeping an eye on the DBF implementation in the previous section, the

70

treatise will now focus on the TAF/SAF one. The whole header file won't be pasted again, since most of the differences with the DBF protocol rely in the logic and implementation of the protocol itself. The above code is the same of the DBF one, in fact pktlist_entry, also records the sender's position (which is retrieved through classes at PHY level, but that ideally is retrieved through the GPS, in the reality), but this memorization is now mandatory. By using this information, in fact, when the node has to decide if forwarding the packet or not, it can perform the triangle rule with the senders of the already received copies. Such a check is always performed with the last two nodes whose copies are received (the one whose copy has just arrived and it's still not memorized and the one whose position was memorized in the list, plus the position of the node who received these packets; after the check, a variable is set for the re-transmission, in case of positive match of the triangle rule). After the check, the previous information about that specific sequence number is substituted by the information of the node whose copy was just received (so there will be a new src, a new posx, posy, and the counter count will be updated). The list scrolling and the timer are the same of the DBF protocol, since the introduction of the new forwarding logic and of the localization information don't alter such pieces of code. As a general idea, it's important to remind that the quantity of data in these protocol is really high, so it's important that there can be fast computation on the packet lists, in order to make simulations end in a reasonable amount of time. Because of this, the optimization with the bool flag was realized, instead of searching on the sequence number (where the fact the list is ordered is not certain), that would certainly lead to a non-ordered research, whose computational complexity would thus begin to be greater than the log(n), granted by the ordered list.

4.3 AWK Scripts for Results Evaluation

The AWK utility is a data extraction and reporting tool that uses a datadriven scripting language consisting of a set of actions to be taken against
71

textual data (either in files or data streams) for the purpose of producing formatted reports. The language used by awk extensively uses the string datatype, associative arrays (that is, arrays indexed by key strings) and regular expressions. AWK is one of the early tools to appear in Version 7 Unix and gained popularity as a way to add computational features to a Unix pipeline. A version of the AWK language is a standard feature of nearly every modern Unix-like operating system available today. Besides the Bourne shell, AWK is the only other scripting language available in a standard Unix environment. Implementations of AWK exist as installed software for almost all other operating systems. AWK was created at Bell Labs in the 1970s, and its name is derived from the family names of its authors (Alfred Aho, Peter Weinberger, and Brian Kernighan). The power, terseness, and limitations of early AWK programs inspired Larry Wall to write Perl just as a new, more powerful POSIX AWK and gawk (GNU AWK) were being defined. Although AWK and sed were designed to support one-liner programs, even the early Bell Labs users of AWK often wrote well-structured large AWK programs. Despite its limited intended area of use, AWK is Turing-complete. AWK is substantially a language for processing files of text. A file is treated as a sequence of records, and by default each line is a record. Each line is broken up into a sequence of fields, so we can think of the first word in a line as the first field, the second word as the second field, and so on. An AWK program is made of a sequence of pattern-action statements. AWK reads the input a line at a time. A line is scanned for each pattern in the program, and for each pattern that matches, the associated action is executed. This programming language is used by the author to process the trace files that come out from the ns-2 simulator. Such trace files are many (because of the many simulations performed, with different vehicle densities and different network protocols) and they can be very large, so they must be parsed in a smart way, in order to make computations faster and, of course, exact. Computations are done on every line of the trace file, by realizing bidimensional arrays, which are created ad-hoc, since they aren't supported by the programming language as a default. In fact, the arrays are crated as standard mono-dimensional arrays, but with the escamotage of using a label which separates the 2 dimensions. As an example, array[node s seqnum], is in theory an array with one only dimension, which is nominally the one among the [ ]. In the practice, instead, there are 2 dimensions:
72

node and seqnum. This mechanism allows to perform operations on bi-dimensional arrays by addressing (with reference to the above example of array) a particular node and see its behavior with respect to the sequence numbers addressed by seqnum. The s is used as a text separator among the indexes, so that in practice, also if the array is mono-dimensional, it will result as bidimensional. The realized awk script is contained in one only file, so that the computations are reduced to the minimum and no already available code has been used, because of the particular needs and the particular metrics used. Such awk script can also be used when changing scenarios and vehicle density (thus it will be an auto-consistent pack together with the software stack realized, ready to be provided to our partner, Telecom Italia). The only needed setup to be done is changing, at the beginning of the script, the variables representing the total number of nodes in the scenario and the RSU ID. In general, performing such simulations is made easy by the presence of .sh scripts realized by the author, which were realized in order to launch the simulations for the various scenarios and the various protocols, also performing the subsequent data processing on traces (with the awk scripts). This work was made, together with the extensibility of the awk scripts, in order to release a product that can also be used by third party partners in quite of a user friendly way, despite the huge complexity of such a simulation stack, that is very rare in VANET literature.

73

Chapter 5: Simulations and Results

This chapter will deal with the simulations performed and the results obtained. In particular, there will be specifications about the mobility model and the traffic injection, then every parameter chosen for the simulation study will be explained and detailed, together with a precise explanation of the metrics that were chosen for the evaluation of the protocols. The simulation stack (see Chapter 3) grants a great complexity, together with accuracy and control over the simulation, so here every detail and every choice that was made, will be explained. Finally, graphic outputs will be provided and an interpretation about the obtained results will be discussed. It's important to remind that the big complexity which derives from the 3 levels of the realized software stack is handled in one final single .sh script, which realizes the many operations needed for the NS-2 part of the work with few clicks, after the model creation operated by using the MOVE software. In general, the creation of a scenario, of the mobility model and of the network simulation implies three macro-phases, divided further on in the following conceptual steps (that may, in practice, be more articulated, especially for the NS-2 part, better explained in the next sections), which are also illustrated in fig. 26: Node: this is the beginning of the process, where nodes must be setup. Nodes correspond to crossroads. In this section the nodes' co-

74

Figure 26: Utilization block scheme of the simulation stack created

-ordinates are decided and the semaphore lights are set-up. Edge: in this section, every edge of the network is decided. Edges are the connections among the nodes (or crossroads). Every edge correspond to a street's direction from one node to another (note that in order to have a two-way street, 2 different edges must be coded:
75

one from node A to node B and another one from node B to node A). In this section the type of street is also decided (highway, urban street); this type allows to create different default parameters for different kind of streets (e.g. different speed limits, see Type explanation below). Number of lanes per direction, maximum speed and priority rules are also decided at this stage. Type: this parameter is the specification of the previously quoted and homonymous one. In this section every edge can be characterized with a name (e.g. Via Eudossiana), specific priority rules (e.g. there's a stop at the end of the road which modifies the normal rules of precedence), number of lanes, speed, capacity (in terms of maximum weight allowed) and possibility of parking the car (since if a car's destination is in this street, the car starts looking for parking and if such a street doesn't allow possibility to park or there aren't sufficient parking slots available, the car will search for parking elsewhere). Map Configuration: here the map is configured, with the default parameters which are used where there's not a different and specific definition (e.g. speed limit, in general, is 50 km/h if not differently specified). Here the linking among the different files created is also performed, since every step of the ones described above, generates a separated file. Create Map: finally the map is generated. The build of the linked files is performed and there's a map file, which can be used and finally visualized through a tool from MOVE. Flow: this is the first step for the generation of the mobility model. Here the flows are decided. There's a starting point and an end point for the flows of traffic. Cars to be injected into the scenario aren't added one at a time, but only with this instrument, which, after the initialization of the starting and ending point, allows the decision about the number of vehicles to be generated for that flow every minute. Such flows are then routed through the Dijkstra algorithm (considering the weight of the arcs as the number of vehicles on that an arc). Turn: it is an optional step for deciding the turn percentage for every specific crossroad, in order to augment the randomness of the simulation (but in the author's simulation this parameter is not set, since it's not logical and rational that cars roam in the scenario too freely: if they don't come out of the map in a reasonable amount of time, there's the risk of congestion and above all, the number of vehicles in the scenario rises exponentially, since the cars hardly reach their exit point from the map, because of the forced turns
76

probability that modify their Dijkstra routing). Create Routing: at this point, most of the parameters are chosen and there's another link stage, like Map Configuration, before. In this phase, all the generated files are linked together, the duration of the simulation is chosen and you can also add a trip file, which allows to insert single vehicles moving in the scenario, if you want that a specific vehicle follows a specific path. There's also the possibility to add timetables for recurrent vehicles (e.g. bus, tram, train) that may travel through the scenario. Traffic generation for NS-2: the third macro-phase starts here. This is the traffic module macro-phase. In particular, the traffic generation for NS-2 is where you have to insert every parameter needed for the NS-2 simulator: channel type, PHY level, queue type, antenna type, routing protocol, radio propagation model, MAC layer, IFQ and link layer parameters. Then all of the kind of traces are to be decided here, like the network traffic to be injected in the network and the nodes where it is generated. Run NS-2: actually here the network simulations are performed Run NAM: here a graphic result, to get an idea of what's happening, is obtained. Obviously, this is a summary of what the steps the author performed are, but it gives an idea of what's happening and where, besides the fact that provides guidelines to replicate the experiments of this treatise and verify them elsewhere. Of course, more details will be provided in the following, especially about the NS-2 simulation part (network traffic module), which requires much more attention in the setup phase with respect to the operations listed in the above explanation.

5.1 The Simulation Scenario

The mobility model is something which is very important in order to get meaningful results out of the performed simulations. In this section, the street scenario will be explained in its details. In Fig. 27
77

such a scenario is illustrated. As it is possible to see, there are 5 horizontal streets and 5 vertical streets, for a total of 25 streets, each one of them providing 2 lanes (one per direction), thus realizing a Manhattan street block scenario. At every crossroad there's a semaphore, whose timings are illustrated in table 1, for a total of 25 semaphores. Since every street is 800m long (in total), the side of the Manhattan square is as long, thus leading to a total scenario area which is 0,64 km 2, including a straight road among 2 consecutive crossroads which is 200m long, providing a block area of 0,04 km2.

Scenario Definition Parameters Scenario side (m) Block street length (m) Scenario area (km2) Scenario layout Number of horizontal streets Number of vertical streets Number of lanes per street Drive direction of streets Adriveway (m )
2

Values 800 200 0,64 Manhattan street grid 5 5 2 Both 56000 25 30 60 15 45 right

Number of semaphores Max vehicle speed (km/h) Red light time (s) Yellow light time (s) Green light time (s) Precedence rule
Table 1: Scenario Definition parameters

The Scenario area is not the real space vehicles can roam by, since they're binded by the streets course. In order to get a more significant measure of the real space where vehicles can travel onto, a linear area has been calculated. Such a parameter is called Adriveway and it represents the area occupied by the solely streets in the scenario: this value is 56000 m2. The creation of this scenario implied the definition of the parameters connected to the rules and the limits of the streets. Since it's an urban
78

Figure 27: A screenshot of the Manhattan street grid of the scenario realized

scenario, the maximum speed allowed for vehicles ( which in the simulations is rarely reached, anyway) is 30 km/h and the rule of precedence is like in Italy, which is relying precedence to the vehicles coming from the right side. As illustrated in the screenshot of fig. 27, it's possible to notice the presence of the semaphores, whose color is represented at the beginning of every lane where the vehicles are supposed to stop.

79

5.2 Mobility Model

The mobility model chosen for the simulations will now be discussed. Most of the information about such mobility model and some of the specifications about the creation of such a model were provided at the beginning of this chapter, but here the specific parameters chosen for the simulations illustrated in this treatise will be illustrated.
Flow Definition Parameters Vehicle Generation Vehicle density: vehicles in the area, included non-driveway spaces (vehicles/km2) Vehicle linear density: vehicles in the street space (vehicles/km2) Average vehicle speed (km/h) Speed rule and distance among vehicles Vehicle routing Vehicles hit time: interval in which a generic car can potentially receive packets while crossing the scenario (average) (s)
Table 2: Flow definition parameters

Values Flows from every border to its opposite 89, 116, 139

1018, 1321, 1589 20, 15, 11 d(vl) + g d(vf) + vf Dijkstra algorithm 211, 280, 377

From table 2 is possible to read the interested parameters, decided for the simulations. In particular, flows of cars were injected from every entry point of the scenario with end point fixed at the exact opposite in the map. Further flows were added to cover peripheral vertical and horizontal roads with a density sufficient to reach 3 diverse traffic situations of interest for the simulations. In order to calculate such densities, 2 different metrics are used: vehicle density and vehicle linear density. The former is calculated as the number of vehicles in the whole scenario area. This number provides a general information about the vehicles that are present in the scenario. In the 3 cases created by the author such
80

densities are 89, 116 and 139 vehicles per km2. These numbers are obtained with a thick sampling of the number of vehicles in the scenario at different time instants, during the simulations. The latter measure, instead, is more meaningful, because, using Adriveway, this metric provides the number of vehicles that are actually there on the driveway space, which is, on the streets. In the three cases, such values are 1018, 1321 and 1589 vehicles per km2. This is a measure which allows the reader to understand the real situation, especially if compared to the vehicle density per km2 of a big city like Milano (1426,9) [37]. It's important to underline that the 3 vehicle densities which were chosen for this tests are very significant, in the sense that the middle density (1321 vehicles per km2) is a vehicle density such that there's enough traffic to significantly cover the whole network, but traffic jams are not so spreadout. The first density, instead, which is 1018 vehicles per km2 allows car to travel more freely in the network: this also brings pieces of the network which are disconnected from the rest. This could also sometimes happen in every scenario, because of the intrinsic dynamism of the diverse road trips and the presence of traffic lights in the scenario. In the end, the last density, nominally 1589 vehicles per km2, brings to serious traffic jams, especially in the central part of the network. Another important parameter is the average vehicle speed: with respect to the maximum one allowed (see sect 5.1), this vary with respect to the 3 traffic densities, because more traffic brings to lower speeds. In particular they are 20, 15 and 11 km/h in the three cases. Obviously, also the time a vehicle needs to cross the whole scenario vary with respect to the density of vehicles which are injected into it. This time is obtained by a sampling of the crossing time at different time intervals and it's equal to 211, 280 and 377 seconds, respectively. The routing of the vehicles through the scenario relies on the Dijkstra algorithms, which also takes into account the number of vehicles that occupy a particular street as a value which is proportional to the weight of the street/edge in the Dijkstra algorithm. As a final parameter, it's important to specify the law that regulates the speed of the cars and the distance they have between each other. These

Figure 28: Car Forwarding Model: the speed of the following vehicle depends on the preceding one

81

parameters are governed by the Car Forwarding Model (fig. 28). By checking the figure, it's easy to understand how the speeds of every vehicle are modelled: they must always respect the relation indicated in the figure, with: d(), a function which is proportional to the distance to the next obstacle g, the distance among the 2 vehicles vl, the speed of the leading vehicle vf, the speed of the following vehicle , the drivers reaction time (usually 1s) More details about the standard rules of the mobility model provided by Sumo are clarified in Chapter 3 of this document.

5.3 NS-2 Parameters and Specifications

It's important to remark and clarify the parameters and the specific choices made at the NS-2 level, since this is the part of the simulation which is about the network, so it requires more specifications than the ones regarding the scenario and the mobility model. This section will thus be about the PHY parameters, the propagation model, the 802.11p parameters and the traffic parameters (and its related values) regarding the packets injected into the network. Such a section goes to complete the introduction about the generation of the mobility model described at the beginning of the chapter, by introducing the steps needed by the network simulator.

82

5.3.1 The PHY Layer

There are many parameters which can be decided for the PHY layer (which, of course, is wireless). In this section the main ones will be outlined. The basic model used is a standard layout available in NS-2 (PHY/WirelessPHYExt), which is the most recent one. In order to make the simulation more realistic, specific parameters (that override the ones of the standard module) were declared for every simulation file. Such parameters are illustrated in table 3

PHY Parameters Parameters Carrier sense threshold (dBm) Pt (Transmitted Signal Power) (W) Frequency (GHz) Noise floor System loss factor (radio/circuit gain loss) Power monitor threshold (dBm) Header duration (s) SINR (Preamble capture) (dB) SINR (Data capture) (dB)
Table 3: PHY parameters overriding the standard NS-2 ones, in order to simulate the VANET hardware

Values -85 0,001 5,9 1,26 e-13 Default (1,0) -102 dBm 40 4 10

The parameters described in table 3 are closer to the ones which are typical of a VANET environment, since mobility and the type of used devices are factors that influence the results with respect to the normal behavior of a fixed wireless network. In particular, some parameters typical of the protocol stack to be simulated (1609.x/WAVE/802.11p) are outlined here, like the signal frequency of the standard and some PHY parameters that differ from the standard 802.11, like SINR soils (preamble and data capture).

83

5.3.2 The MAC Layer

Also in the MAC layer, some parameters which are different from the standard ones, are defined, to model the 802.11p standard, used in our simulations. In table 4 they are detailed with the chosen values.
802.11p MAC Parameters Parameters Minimum contention window Maximum contention window Slot time (s) SIFS (s) Short retry limit Long retry limit Header duration (s) RTS threshold (byte) Symbol duration (s) Air bitrate (Mbps) Nodes coverage radius (m)
Table 4: 802.11p MAC parameters chosen for the simulations in this treatise

Values 15 1023 0,000013 0,000032 x7 x4 0,000040 2346 0,000008 6 ~80

Some parameters need some explanations. First of all the SIFS is the Short Inter-Frame Space, then the node coverage radius is provided by the power of transmission and the propagation model (see next section). In particular, the bitrate is equal to 6 Mbps, because of the modulation scheme used, but it may vary from none, BPSK, QPSK, QAM16, and QAM64, with a maximum bitrate equal to 12 Mbps. After this soil, anyway, although the standard allows further pushing on the bitrate, the probability of reception becomes too low, since the SNR becomes too high to really receive something intelligible, like explained in [38]. Moreover, the 802.11p standard also allows other kind of modulations, but they're not supported by the NS-2 simulator. So, with the defined features, the resulting nodes coverage radius becomes equal to about 80m. Another important feature is the slot time, which is twice the time it takes for an electronic pulse to travel the length of the maximum theoretical
84

distance between two nodes and in the author's simulation it's equal to 13 s.

5.3.3 The Propagation Model

The propagation model used has great impact on wireless network performance. A model generally depends on various parameters. Some are easy to determine within simulations, like the distance between sender and receiver or the utilized frequency. But others must be represented as random functions or constant factors, like interferences or fading effects. To allow reasonable simulations within an acceptable amount of time, propagation models must simplify calculations and reduce the required computation to a minimum. The network simulator NS-2 allows three different propagation models to simulate wireless ad-hoc networks: the free space (FS) model, the two ray ground (TRG) model and the shadowing model. The underlying channel model in NS-2 is quite simple. The simulator calculates the receiving power Pr for every transmission between two nodes with the chosen propagation model. The channel model distinguishes primarily between three cases. In case Pr is greater than the receiving threshold RXThresh, the transmission has enough power to allow proper reception at the receiver side. Other simultaneous transmissions with reasonable transmission powers may certainly interfere with this transmission and make a correct reception impossible. If Pr is below RXThresh but greater than the carrier sense threshold CSThresh, then the receiving node must drop the packet. However, the receiving power of this transmission is still strong enough to interfere with other simultaneous transmissions. Consequently, these interfered packets are also invalid and nodes must drop them as well. Transmissions with receiving powers Pr smaller than CSThresh do not even obstruct other simultaneous transmissions at the same node. As NS-2 forwards all transmissions to all nodes, it is the most probable case. It is only necessary to improve simulation performance and to simplify packet processing during simulation.
85

The free space model is the simplest model. It only assumes the direct path between transmitter t and receiver r. The receiving power P r depends on the transmitted power Pt, the gain of the receiver and transmitter antenna (G t, Gr) the wavelength , the distance d between both nodes and a system loss coefficient L. All parameters, but the distance d, are system wide constant parameters. During a simulation run, the receiving power P r only changes with the distance between sender and receiver. As both receiving parameters RXThresh and CSThresh are also constant throughout simulations, receiving nodes must be inside a perfect disc, otherwise, they are unable to collect packets properly. The formula in the following helps to understand how the things really work in this model:

where: Pr,FS is the received power with the Free Space model; Pt is the transmission power; Gt is the transmission gain; Gr is the receiver gain; is the wavelength; d is the distance among the 2 nodes; L is the loss coefficient.

Figure 29: Two ray ground propagation model with its direct ray and the reflection.

86

Figure 30: Probability of packet reception with respect to the distance of the receiver node with respect to the sender

The TRG model, which is the model used in the author's simulations, is an improved version of the FS model. It considers the direct ray between sender and receiver, but also the ground reflection. As with the FS model, both nodes are assumed to be in LOS. The heights of both antennas over the ground are depicted with ht and hr and are constant during simulations. Up to the crossover distance dThresh = 4 ht hr , the TRG model is equal to the FS model. Beyond this distance, the ground reflection destructively interferes with the direct ray and further reduces the field strength. The receiving signal strength is then inverse proportional to d 4. Just like the FS model, TRG contains only the distance between sender and receiver as variable parameter. From fig. 29 it's possible to get an idea of the propagation model, which is further on described by the following formula:

87

where, the new parameters with respect to the Pr,FS formula are: Pr,TR is the received power with the Two Ray Ground model; Pr,FS is the received power with the Free Space model; ht is the height of the transmitter antenna; hr is the height of the receiver antenna; dThresh = 4 ht hr ; as defined above in this section. In order to get an idea about the probability of reception of a message with respect to the distance of the receiver node, fig. 30 can provide a visual help.

5.3.4 Network Traffic Specifications

This is a very important setup phase for the simulator, since the kind of traffic injected into the simulation is decided here. The traffic is broadcast and the solely RSU of the scenario is in the center of the map. Such a node broadcasts packets every 0,1 seconds. These packets have a payload of 1024 bytes and travel over the MAC and PHY layers specified in sections
Network Traffic Simulation Parameters Parameters Broadcast packet payload (bytes) Simulation duration (s) Addressing mode TForward: maximum forwarding time (s) TRSU: Packet sending period by RSU (s) Variance Cosine threshold (TAF) Number of RSUs Location of RSU
Table 5: Traffic parameters setup for NS-2

Values 1024 1000 Broadcast 0,1 0,1 0,05 0,5 1 Centre (400,400)

88

5.3.1 and 5.3.2. The network layer (also if it's not very appropriate to call it a network layer, since dissemination is not properly a routing protocol) relies on 3 different protocols: flooding, DBF and TAF (see Chapter 3 for more information). The only needed parameters to specify, besides the ones in Chapter 3, are the ones about flooding. This protocol, implemented by the author himself for NS-2, simply listens to the broadcast packets and then tries to re-broadcast them with a minimum jitter (a random variable that varies among 0 and 10 ms), until the hop count becomes zero. Obviously this behavior leads to the broadcast storm problem, which is the situation in which many nodes try to transmit all together, thus leading to collisions, and since the broadcast messages don't allow ACK packets, the spreading of the message is then compromised because no node can correctly receive the packets. These three protocols let us evaluate, with respect to the metrics in sect 5.5, the behavior of the new proposed protocol: TAF, whose cosine soil is set at 0,5. The last relevant parameter is TForward, which is the period of time that is multiplied times the distance in the delay calculation formula of both TAF and DBF: such a value is fixed to 0,1 seconds. The broadcast is performed with the PBC (Periodic Broadcast) TCL class from the NS-2 TCL's standard library with a variance of 0,05 seconds on the periodicity of the broadcast (so that TRSU will be 0,1+x, where x varies in [-0,05 ; 0,05] seconds).

5.4 Parameters Summary

In the following, a brief summary of all the main parameters of the whole simulation stack, is provided. Such a summary is very useful for keeping an eye on, while checking the simulation results of sect 5.7. There are the scenario definitions, the flow characteristics and the network simulator chosen parameters. These values are divided in 2 tables for the sake of clarity. For further details and for the meaning of every single parameter, please see sect. 3 of the present chapter.

89

Parameters Scenario Definition Scenario side (m) Block street length (m) Scenario area (km2) Scenario layout Number of horizontal streets Number of vertical streets Number of lanes per street Drive direction of streets Adriveway (m )
2

Values

800 200 0,64 Manhattan street grid 5 5 2 Both 56000 25 30 60 15 45 right Flow Definition

Number of semaphores Max vehicle speed (km/h) Red light time (s) Yellow light time (s) Green light time (s) Precedence rule

Vehicle Generation Vehicle density: vehicles in the area, included non-driveway spaces 2 (vehicles/km ) Vehicle linear density: vehicles in the street space (vehicles/km2) Average vehicle speed (km/h) Speed rule and distance among vehicles Vehicle routing Vehicles hit time: interval in which a generic car can potentially receive packets while crossing the scenario (average) (s)
Table 6: Mobility Model parameters used in the simulations

Flows from every border to its opposite 89, 116, 139

1018, 1321, 1589 20, 15, 11 d(vl) + g d(vf) + vf Dijkstra algorithm 211, 280, 377

90

PHY Parameters Carrier sense threshold (dBm) Pt (Transmitted Signal Power) (W) Frequency (GHz) Noise floor L (radio/circuit gain loss) Power monitor threshold (dBm) Header duration (s) SINR (Preamble capture) (dB) SINR (Data capture) (dB) Propagation Model Unlisted MAC, PHY parameters Minimum contention window Maximum contention window Slot time (s) SIFS (s) Short retry limit Long retry limit Header duration (s) RTS threshold (byte) Symbol duration (s) Air bitrate (Mbps) Nodes coverage radius (m) Network Traffic Parameters Broadcast packet payload (bytes) Simulation duration (s) Addressing mode TForward: maximum forwarding time (s) TRSU: Packet sending period by RSU (s) Cosine threshold (TAF) Number of RSUs Location of RSU
Table 7: Network simulation parameters for the involved layers and the injected traffic

-85 0,001 5,9 1,26 e-13 Default (1,0) -102 dBm 40 4 10 Two ray ground

802.11p MAC Parameters IEEE 802.11p defaults 15 1023 0,000013 0,000032 x7 x4 0,000040 2346 0,000008 6 ~80 1024 1000 Broadcast 0,1 0,1 0,5 1 Centre (400,400)

91

5.5 The Metrics Chosen for the Simulations

The simulation stack which was designed allows to perform various simulations and to vary some of the parameters as desired, with a minimum effort. It is easy, for example, to vary the number of vehicles in the scenario, but it could be less fast to operate on the scenario itself (adding streets and modifying the scenario implies that all of the traffic must be re-generated); this operation can be easily carried forward, anyway, but it takes more than just a few clicks. In the following, the metrics used in the simulations are illustrated. Such metrics are: 1) Information Coverage: given an OBU, tIN is the time a vehicle enters the urban scenario considered and tOUT the time it exits. During this time interval, RSU emits (tOUT-tIN)/TRSU messages; the information coverage is the fraction of these messages which are received by the OBU, for OBUs which have completed their trip in the simulation. The metric value is obtained by averaging over all OBUs that complete their trip in the simulation run. 2) Reached Nodes: This metric gives an information about the number of nodes that are reached by at least the 60% the flow. It provides information about the spreading of the messages through the network, with the different protocols and densities and it's especially meaningful is associated to Information Coverage metric. This metric is calculated as a percentage on the total of nodes crossing the scenario during the whole simulation. 3) Message spreading time: it provides the delay in delivering messages, defined as the time elapsed from the sending of the message by the RSU to the time it actually arrives to an OBU; the value of the metric is obtained by averaging over every message, for every OBU which receives the message. 4) Forwarding OBUs: percentage of OBUs which forward a message, obtained by averaging over all OBUs and all messages that realize a forward operation and, most important, only the first of such operations is considered in the count. 5) Collisions: This metric provides information on the number of collisions that occur in our scenario. It's obtained by an average on every OBU and every message. 6) Copies: number of copies of the same messages which are received
92

by the OBUs (average on every OBU and on every message).

5.6 Scenario Snapshots

The below figure (fig. 31) gives an idea of what is the traffic density during the simulation with the lower density (1018 vehicles per km2), then fig. 32 does the same with the average traffic density (1321 vehicles per km 2) and finally fig. 33 shows the vehicles collocation during the most populated scenario (1589 vehicles per km2). Such snapshots are taken in the middle of the simulation for providing a visual aid in understanding what really is the car situation inside the scenarios.

Figure 31: Density 1018 v/km2. Scenario snapshot during the simulation.

93

Figure 32: Density 1321 v/km2. Scenario snapshot during the simulation.

Figure 33: Density 1589 v/km2. Scenario snapshot during the simulation.

94

5.7 Simulation Results and Discussion

In this section the graphs obtained from the simulation will be provided, together with the discussion about their behavior and what is exactly happening. The graphics will be provided with respect to the metrics explained in section 5.5 of this treatise.

5.7.1 Information Coverage

In the graphic of fig. 34 it is possible to observe the percentage of packets received by the vehicles during the time they actually cross the scenario. As it's easy to see, the density of 1018 vehicles per km2, gives very similar results for the three protocols. This happens mainly because the density of vehicles is simply not sufficiently high to allow packets to spread significantly through the network, so the three protocols behave substantially in a very similar way, although the different logics.

100 90 80

Packets Received (%)

70 60 50 40 30 20 10 0 1018 1321 1589 FLOOD DBF TAF

Linear Density
Figure 34: Information Coverage: percentage of packets received by the vehicles during their crossing time

95

At the average density (1321 vehicles per km2), there's a significant snapshot of what really happens in the network, with TAF protocol that is able to grant a total reception of all of the packets transmitted by the RSU, since the propagation is sufficiently smart, while DBF still loses about the 9% of the packets, mostly for a wrong propagation. With the higher density, instead, the information coverage is almost the same for both TAF and DBF, and the former 's performance is slightly worst with respect to the average density, since the current density is very high: it's the ultimate condition for traffic density and also the smarter propagation logics can be tricked out by the heavy load on the network and the many cars which are there, too near one each other. The flooding protocol, both with the intermediate and the highest density, performs bad. It's clear that packets can't be spread-out after the first or second hop because of the collisions: but this is something that is going to be analyzed later.

5.7.2 Reached Nodes

This metric completes the one in sect 5.6.1, by providing a different perspective of the nodes which receive the flow of packets which is sent by
120

Nodes receiving packets (%)

100 80 60 40 20 0 1018 FLOOD DBF TAF

1321

1589

Linear Density
Figure 35: Linear Density graph. It represents the percentage of the nodes receiving at least 60% of the flow

96

the RSU. In fact, in the graph of fig. 35 it's possible to see the percentage of nodes which receive at least 60% of the whole flow. This is an indication of how far the protocols really spread-out their packets (while sect 5.6.1 focuses on the received packets, here the focus is on the nodes which receive the packets). The behavior of the curves is similar with respect to the one in sect 5.6.1, with curves that start from about the same point and end with a convergence trend. As anticipated, at the lowest density, the protocols behave almost the same, accordingly to the percentage of packets received by the nodes. At the average density (1321 vehicles/km2), instead, it's possible to see the real difference among the protocols. It's possible to see, in fact, that while TAF allows every node to receive the whole flow (in combination with the graph of fig. 34), DBF's spreading factor is less significant, thus leading to the explanation that the nodes that are too far from the RSU, most likely still receive parts of the flow, but not enough to reach at least the 60% of the total (during the time they cross the scenario), while the nodes which are in the central zone of the map most likely receive the whole flow without many problems, so the problem is in the spreading factor and that's faced by TAF, instead. The higher density, finally allows DBF to join TAF with 100% coverage: this means that, with higher densities, also DBF is able to cover the whole network. If said otherwise, DBF needs many more vehicles in order to reach the same results of the TAF protocol. Then, in the next sections, we'll also add other features to this conclusion, that for the moment, is partial. The flooding algorithm, performs in a poor way also in this metric, since there are really few nodes which receive the packets, although the broadcast storm problem is limited by the fact that the flooding algorithm only forwards the packet once; anyway it still applies, also if, with the highest density, the nodes which are reached by the majority of the packets of the flow, are an acceptable number (this means that, if the packets come

97

0,04 0,03

Packet delivery delay (s)

0,03 0,03 0,03 0,03 0,02 0,02 0,02 0,02 0,02 1018 1321 1589 FLOOD DBF TAF

Linea Density
Figure 36: Delay that occurs among the first transmission of a message by the RSU and the first reception of such message by every OBU able to receive it

5.7.3 Message Spreading Time

This metric is very important, since it gives information about the message spreading time, which is the time that occurs among the time at which transmission of a packet by the RSU is done and the time an OBU receives its first copy. The average is computed on every node and on every sequence number. Also here (see fig. 36), the results are very similar when the density is low, since the packets mostly can't reach the whole network, but they're limited to the central part of the scenario (like it also comes-out from the other metrics), because the scenario is mostly disconnected. At the average density, instead, the flooding algorithm experiences really high delays, although the average applies (it should lower the times, since there are many nodes in the central part of the network that, in theory, receive the packet in an instant). Also, DBF and TAF, whose packets reach far destinations, still can keep their delays low. The reason why flooding experiences such high delays is because of the back-off timer that has to be waited when collisions occur. It's clear that, these collisions here are very high in quantity, both for medium and high traffic density.
98

About DBF and TAF, instead, it's good to see that such a delay is lower for the latter at the medium density, because the spreading of this protocol is confirmed to be better also with this metric. When the traffic density becomes higher, instead, TAF and DBF get about the same results, since the less clever forwarding rule by DBF is balanced by the number of cars in the scenario. It's worth of attention, anyway, that at the average traffic density, TAF has times that are about 23 ms (average) to propagate the packet through the whole network, against the 37 ms (61% more) of flooding and the 26 ms (13% more) of DBF.

5.7.4 Forwarding OBUs

Figure 37 shows the percentage of OBUs which forward the packets in the different protocols. As expected, the flooding algorithm tries to perform many forwarding actions. Obviously this is the cause of the broadcast storm problem. The network is congested by those forwarding actions and only with lower densities, this logic can bring something acceptable (compared to the other 2 protocols), like we see at the lowest density in fig. 35.

80

OBUs forwarding packets (%)

70 60 50 40 30 20 10 0 1018 FLOOD DBF TAF

1321

1589

Linear Density
Figure 37: graph representing the percentage of OBUs that forward a packet (average on every OBU and every message)

99

TAF and DBF, instead, get almost the same results in terms of percentage of forwarding OBUs. This happens because the logics are similar, also if, in theory, DBF should perform less forwarding operations because TAF also forwards already heard packets, if the direction of the possible propagation is right after the triangle rule, while DBF does never forward an already heard packet. This reasoning let us understand, together with the figures in the other sections, that the TAF protocol chooses wisely the nodes that perform the forward operation, so that the crossroads are covered in the right manner and the propagation and the coverage are boosted (see also the times in fig. 36, which are lower), without boosting the number of forwarding actions, which remains similar to the DBF protocol.

5.7.5 Collisions
As expected, the number of collisions is very high for the flooding protocol. The broadcast storm problem here hits hardly and it's finally clear what's happening when the flooding protocol is used: all the nodes try to re-broadcast the packet, but their transmission eventually collide, so the backoff timer imposes a waiting time that rises the delay of the receptions
70 60 50

Collisions (%)

40 30 20 10 0 1018 FLOOD DBF TAF

1321

1589

Linear Density
Figure 38: Collision percentage with different traffic densities (average on every node, every sequence number)

100

for the nodes which are far away from the RSU. Clearly the situation becomes worst when the density rises, but at the highest density, the slope doesn't grow exponentially, because there are just less OBUs that really receive the packets, since the broadcast problem really hits the network, thus making the flow propagation impossible. About the TAF and the DBF protocols, again their behavior is quite similar, also if the differences can't be really appreciated because of the fact that the flooding protocol makes the granularity of the representation very low, since it pushes the graphic to represent too high results. Anyway, what's important is that still TAF and DBF protocols experience collisions. This is something they get over, since the percentage of received packet is, for TAF, 100% (like it's illustrated in fig. 34) and in any case, very high. Moreover in dissemination routing, the quantity of packets generated is still too high not to have collisions. In the practice of the facts, these collisions occur because the cars are too near one each other: this means that their delays for the retransmission of the packets will be very close, and sometimes, for very near cars (like cars stopped at the semaphore), it happens that packets are retransmitted by these nodes at the same time. This is because in our formula of the delay ( Delay = TForward (1- d/R) ), since d is almost the same among these 2-3 nodes, the re-transmit time will differ in 1 ms or less one node from another, thus bringing them not to hear the packet transmitted by the other node, before they already scheduled their re-transmission event. This happens because NS-2 also simulates the delays introduced by the various levels of the stack.

12

Number of received copies per node

10 8 6 4 2 0 1018

FLOOD DBF TAF

1321

1589

Linear Density
Figure 39: This graph displays the number of copies which are received (average on every node and every sequence number)

101

A solution to this problem of the very close nodes will be provided later in this treatise.

5.7.6 Copies
In fig. 39 it's possible to observe the number of copies which every node has received, with an average on every node and every sequence number. With the term copy, here it's meant every messages that a node receives for a specific sequence number, besides the first one (which is, actually, the useful one). As it's possible to observe, flooding, although there are many collisions, is able to deliver a high number of copies, especially for the lowest density. This happens because at the lowest density, the behavior of the flooding protocol can somehow still work, since the nodes that try to re-transmit the message are limited in number, so the transmission can take place, while when the density rises, then the nodes try to forward the packet, but the delivery of such a message is never finalized because of the collisions. DBF and TAF still have similar behaviors, but, as it's illustrated in fig. 39, the number of the received copies is slightly lower for the latter (1 copy less for the TAF protocol, which represents 50% more copies on the average produced for the DBF protocol). The fact that for the lowest density both the DBF and the TAF protocol produce more copies is justified by the fact that the lower density needs more copies to be produced in order to let the flow reach places which are more far away, while at the same time, the nodes hear less transmissions just because there are less nodes in the map (thus in the forwarding process), so, since the transmission is normally inhibited by the transmission of the neighbors, this happens a little bit less often in this case.

102

5.8 Compared Analysis and Future Improvements

The comparison was made during the analysis of the single graphs, as long as the new information was provided through new graphs, but in this section a sum about the results of this protocol will be provided, plus possible future modifications. As it's clear from the graphs provided, TAF performs well in every condition, by reaching a good coverage of the network, also with densities where DBF is unable to provide the right amount of coverage and also when the coverage is comparable (high density), this happens with usually slightly less delay and less copies produced for the TAF protocol, especially for the average density, which is the one which represents the normal situation of an Italian city, since it provides some car queues in the center of the scenario and then a regular traffic on the peripheral zones. In brief, DBF needs many more vehicles and more forwarding operations to get the same results of the TAF protocol. There aren't terms of paragon, instead, with the flooding algorithm, that obtains less than the TAF one with plenty of overhead in copies injected into the network, bigger delays and many collisions, although it was though to be smarter than a normal flood (it only forwards one copy of a packet). As a future development for the TAF protocol, since it was clear from sect. 5.7.6, a little jitter on the standard formula for the delay would be welcome for braking the symmetry and thus avoiding the collisions for the vehicles which are too near in a traffic queue. Or, which is similar, making bigger the constant TForward, so that also the nodes which are very near in the traffic would significantly delay their transmission one respect to the other one.

103

Conclusion
In this treatise, a new simulation stack was created to support and simulate a VANET environment, with a huge customizability and possibility to control the very little detail about the whole simulation, from the map, to the mobility model or the network traffic parameters, also the more specific ones. This instrument was used to realize a comparison among three different VANET dissemination protocols: flooding, DBF and the TAF. The last one was proposed in this treatise as a possible improvement for the DBF algorithm, in order to support and evaluate the possibility of loading the network with infotainment traffic, besides the normal safety application, whose bandwidths requirements aren't so highly demanding. The simulations performed by the author show that this improvement is reached, also if there's still margin to make things work still better. The simulation stack created and optimized for the treatise will be used again and its still fully unexploited potentialities, already provided and still will provide, in the future, a useful instrument for realistic VANET simulations, finally offering an instrument which is complete and closer to reality with respect to many other pieces of software used in literature. As a future matter of development, it will also be studied the possibility to perform a two-way communication by using variants of the TAF protocol which will allow a way to address the destination and a way to let the packet return to the sender, thus coupling the dissemination traffic in a
104

complete new protocol.

105

References
[1] Y. L. Morgan, Notes on DSRC & WAVE Standards Suite: Its Architecture, Design, and Characteristics, IEEE Communications surveys and Tutorials, Vol. 12, No. 4, Fourth quarter 2010 [2] J. G. Jordn, F. Soriano, D. Graullera, and G. Martn., A comparison of different technologies for EFC and other ITS applications", Proc. IEEE Intelligent Transportation Syst. Conf., pp. 1172-1177, Oakland USA, Aug. 2001 [3] IEEE 802.11p SWG et al, Draft amendment to standard for information technology - telecommunications and information exchange between systems - local and metropolitan networks - specific requirements - part 11: Wireless LAN medium access control (MAC) and physical layer (PHY) specifications: Ammendment: Wireless access in vehicular environments," IEEE 802.11p D6.0, June 2009. [4] IEEE P1609.1 SWG et al, IEEE P1609.1 trial-use standard for wireless access in vehicular environments (WAVE) resource manager ," IEEE P1609.1 D0.6, June 2009. [5] IEEE P1609.2 SWG et al, IEEE P1609.2 trial-use standard for wireless access in vehicular environments - security services for applications and menegement messages," IEEE P1609.2 D07, June 2009. [6] IEEE P1609.3 SWG et al, Wireless access in vehicular environments (WAVE) networking services," IEEE P1609.3 D1.2, June 2009. [7] IEEE P1609.4 SWG et al, IEEE P1609.4 trial-use standard for
106

wireless access in vehicular environments (WAVE) - multi-channel operation," IEEE P1609.4 D12, June 2009 [8] S.Y. Wang, C.L. Chou, K.C. Liu, T.W. Ho, W.J. Hung, C.F. Huang, M.S. Hsu, H.Y. Chen, and C.C. Lin , Improving the Channel Utilization of IEEE 802.11p/1609 Networks , WCNC 2009 proceedings [9] K. Bilstrup, A Survey Regarding Wireless Communication Standards Intended for a High-Speed Vehicle Environment, Technical Report IDE 0712, Halmstad University, Sweden, Feb. 2007. [10] S. Yang, H. H. Refai, and X. Ma, CSMA based inter-vehicle communication using distributed and polling coordination, in Proc. IEEE Int. Conf. on ITS, Vienna, Austria, Sept. 2005, pp. 167-171. [11] J. J. Blum and A. Eskandarian, A reliable link-layer protocol for robust and scalable intervehicle communication, IEEE Trans. on ITS, vol. 8, no. 1, pp. 4-13, Mar. 2007. [12] Olivia, B., Martin, K., et al., A Network Centric Simulation Environment for CALM-based Cooperative Vehicular Systems: SIMUTools, in: Proceedings of the 3rd International ICST; Conference on Simulation Tools and Techniques, Torremolinos, Malaga, Spain, March 15 19 (2010), ISBN 78-963-9799-87-5 [13] Elmar Schoch, Frank Kargl, Michael Weber, and Tim Leinmuller, Communication Patterns in VANETs, IEEE Communications Magazine, 46:119125, Nov 2008. [14] http://world.waze.com/ [15] TSITR102638, Intelligent Transport System (ITS); Vehicular Communications; Basic Set of Applications; Definition, ETSI Std. ETSI ITS Specification TR 102 638 version 1.1.1, June 2009. [16] G. Liu, B.-S. Lee, B.-C. Seet, C.H. Foh, K.J. Wong, and K.-K. Lee, A routing strategy for metropolis vehicular communications , in International Conference on Information Networking (ICOIN), pp. 134143, 2004. [17] H. Fler, M. Mauve, H. Hartenstein, M. Kasemann, and D. Vollmer, Location- based routing for vehicular ad-hoc networks, ACM SIGMOBILE Mobile Computing and Communications Review (MC2R), vol. 7, no. 1, pp. 4749, Jan. 2003. [18]Sandhaya Kohli, Bandanjot Kaur, Sabina Bindra, A comparative study of Routing Protocols in VANET , International Journal of Computer Science Issues (IJCSI), Vol. 8,Issue-4,No.-4,Jul 2011 [19] B. Karp and H.T. Kung, GPSR: Greedy perimeter stateless routing for wireless networks, in Proceedings of the ACM/IEEE International Conference on Mobile Computing and Networking (MobiCom), 2000. [20] Fan Li, Yu Wang , Routing in Vehicular Ad-hoc Networks: a survey , in IEEE VEHICULAR TECHNOLOGY MAGAZINE , June 2007
107

[21] Yun-Wei Lin, Yuh-Shyan Chen, Sing-Ling Lee, Routing Protocols in Vehicular Ad Hoc Networks : A Survey and Future Perspectives, in J. Inf. Sci. Eng., 2010, pp.913-932. [22] G. Liu, B.-S. Lee, B.-C. Seet, C.H. Foh, K.J. Wong, and K.-K. Lee, A routing strategy for metropolis vehicular communications , in International Conference on Information Networking (ICOIN), pp. 134143, 2004. [23] J. Zhao and G. Cao, VADD: Vehicle-assisted data delivery in vehicular ad hoc networks, in IEEE INFOCOM, 2006. [24] M.-T. Sun, W.-C. Feng, T.-H. Lai, K. Yamada, H. Okada, and K. Fujimura, GPS-based message broadcast for adaptive inter-vehicle communications, in Vehicular Technology Conference, 2000. IEEE VTSFall VTC 2000. 52nd, vol. 6, 2000, pp. 2685 2692 vol.6. [25] M. O. Cherif, S.-M. Senouci, and B. Ducourthial, Efficient data dissemination in cooperative vehicular networks, Wireless Communications and Mobile Computing, pp. n/an/a, 2011. [26] A. Nasri, M. Fathy, and R. Hajisheykhi, A cross layered scheme for broadcasting at intersections in vehicular ad hoc networks, in Future Networks, 2009 International Conference on, march 2009, pp. 13 17. [27] G. Korkmaz, E. Ekici, F. Ozg ner, and U. Ozg ner, Urban multihop broadcast protocol for inter-vehicle communication systems, in Proceedings of the 1st ACM international workshop on Vehicular ad hoc networks, ser. VANET 04, 2004, pp. 7685. [28] P. Lai, X. Wang, N. Lu, and F. Liu, A reliable broadcast routing scheme based on mobility prediction for VANET, in Intelligent Vehicles Symposium, 2009 IEEE, June 2009, pp. 1083 1087. [29] Fiore, M.; Harri, J.; Filali, F.; Bonnet, C. Vehicular Mobility Simulation for VANETs Simulation Symposium, 2007. ANSS apos;07. 40th Annual Volume, Issue , 26-28 March 2007 Page(s):301 - 309 [30] Cristian Tuduce and Thomas Gross, A Mobility Model Based on WLAN Traces and its Validation, in Proc. of the IEEE INFOCOM 2005, Miami, March 2005. [31] Jungkeun Yoon, Brian D. Noble, Mingyan Liu, Minkyong Kim, Building realistic mobility models from coarse-grained traces, in Proc. of the ACM International Conference On Mobile Systems, Applications And Services (MobiSys 06), pp. 177-190, 2006. [32] The Network Simulator ns-2. [Online]. Available: http://www.isi.edu/nsnam/ ns/ [33]M. Greis. Tutorial for the Network Simulator NS2. [Online]. Available: http:// www.isi.edu/nsnam/ns/tutorial/
108

[34] J. Chung and M. Claypool. Ns by example. [Online]. Available: http:// nile.wpi.edu/NS/ [35] H. Schildt, C++: The Complete Reference, 4th Edition (Kindle Edition), 4th ed. McGraw-Hill/Osborne Media, 2002. [36] Francisco L. Ros, Pedro M. Ruiz. Implementing a New Manet Unicast Routing Protocol in NS2. Dept. of Information and Communications Engineering University of Murcia. December, 2004 [37]http://tuttocamera.mb.camcom.it/upload/repos/stampa/0/401/smog.mi.p df [38] Daniel Jiang, Luca Delgrossi , IEEE 802.11p: Towards an International Standard for Wireless Access in Vehicular Environments , IEEE 2008

109

Acknowledgements

So che non ringrazier tutti quelli che avrei dovuto ringraziare, ma parimenti e che inevitabilmente dimenticher qualcuno. Chi mi stato vicino durante la preparazione di questa tesi, conosce i ritmi che ho dovuto sostenere nella scrittura della stessa e non se ne avr a male ! Ai miei genitori ed a mio fratello, che hanno avuto la forza di sostenermi durante questi anni, dandomi sempre il coraggio di andare avanti, insegnandomi che bisogna mettere sempre il massimo in qualsiasi cosa si faccia, senza per mai lasciare indietro il cuore. A Rita, che mi stata sempre vicina, nei momenti felici ed in quelli che lo sono stati di meno, ispirandomi costanza e fermezza: con te al mio fianco, sono capace di ottenere ogni cosa. Alla Prof.ssa Francesco Cuomo, al Prof. Baiocchi ed a Pierpaolo, per il sereno clima di lavoro e la possibilit di creare tanto, insieme.

110

Ai miei amici, vicini e lontani: ad Angela, Antonio, Carlotta, Emiliano, Enrico, Ersilia, Fulvio, Francesco, Fraska, Luca, Sara ed ai due desaparecidos Nicola e Stefania. Non c' bisogno di parole. Mi avete reso ci che sono. Ai miei coinquilini, Angelo e la Titti: non vi preoccupate, adesso uscir dalla mia cripta ! Il sole sta finalmente sorgendo di nuovo all'orizzonte ! Ai miei compagni d'avventura alla Sapienza: non riuscir mai ad inserirvi tutti, ma sappiate che questo mio ringraziamento va a voi, volti che ho conosciuto da un paio d'anni soltanto, eppure per molti di voi si tratta di persone con cui ho condiviso tanto. Lauretta, Fabio, Gaetano, Peppe e Valerio, avete portato un po' della mia citt qui a Roma, colori e sorrisi noti, quando ogni cosa intorno a me sapeva di nuovo. A Rosanna, che mi ha fatto compagnia durante la tediosa mia incombenza di scrittore, ricordandomi che se corri troppo, rischi di lasciarti indietro qualcosa. A Rori, che apprezzer il premio che il caso mi ha conferito: 111 pagine ! A tutti quelli che pensano di dover essere in questi ringraziamenti e che io ho dimenticato di inserire. A tutti coloro i quali mi hanno ostacolato, mi hanno sottovalutato; a tutti quelli che hanno cercato di schiacciarmi, o di affossarmi. Questa per voi.

111