1. Introduction

Vehicular Ad-hoc Network (VANET) is an upcoming technology, widely being researched all over the world. It aims to revolutionize travelling at a very large scale through the implementation of road safety and management architectures ^[1]. The underlying concept is to convert each and every vehicle into a wireless communicating entity, hence increasing driver’s perception of horizon beyond human eye’s range. The most targeted and ultimate goal is to ensure safer travel by generating early warnings and timely response to the situations. However, to increase the market penetration, other classes of applications such as traffic control and provision of infotainment are also being considered ^[1]. These goals require backend Infrastructure connectivity to all nodes. The use of infrastructure may vary from architecture to architecture and from service to service.

Currently a large number of countries are working on VANET architectures and their implementations, either individually or in collaboration with regional regulatory authorities and car manufacturers. However most of the development is still in research phase with very limited practical deployment. Research standardization agencies, such as Institute of Electrical and Electronic Engineering (IEEE), International Standard Organization (ISO) and European Telecom Standardization Institute (ETSI) have proposed different VANET architectures. Countries like Japan, USA and Brazil are working on the standards according to their own need and infrastructure layout.

Researchers are in process to find more intelligent new services for VANET, such as involvement of pedestrians and amalgamation of trains in the communication architecture etc ^[2]. In this paper, we have discussed an implementation of VANET architecture, for large scale fleet operations and convoy management. Fleet and convoy management systems can be categorized under traffic control, load management and timely response to eventualities ^[3]. These services, if applied carefully, can not only enhance the overall efficiency of the network from vehicle management perspective, but can also improve the business model of these operators. We present a framework for building a VANET based Fleet/Convoy Management system and, as a proof of concept, discuss and provide results of a small scale implementation. We have also developed a test bed for the real-time implementation of the architecture according to available communication resources in Pakistan.

Rest of the paper is framed as follows. Section-2 defines and elaborates existing VANET architectures. Section-3&4 defines the recent efforts for VANET standardization and their implementation. In Section-5, we have discussed peculiar environment of any fleet or a convoy network. In Section-6, we present our design and discuss the functionalities of a fleet / convoy management system. Section-7 explains the prototype development and the problems faced during implementation. In the end, we present our conclusions and discuss possible future enhancements.

2. Existing VANET Architectures

The history of the use of radio and infrared communication for vehicle-to-roadside and vehicle-to-vehicle communication is strongly tied to the evolution of Intelligent Transportation System (ITS) ^{[1, 2, 4]}. The basic concepts of vehicular automation to make road traffic safe and efficient, through the use of communication were introduced in 1939. The proposed idea, named ‘Futurama’, expected practical utilization within next two decades. In 2004, the term ‘VANET’ was introduced during the first ACM International Workshop on Vehicular Ad Hoc Networks ^[5].

VANET offers traffic safety, traffic efficiency and value-added services ^[6] which involves different communication scenarios. The three basic scenario fields are supported by a number of application classes. For each of the class, three basic communication designs are as follows:

Table 1. Comparison of Access Layer Interfaces

Download as

PowerPoint Slide

Larger image(png format)

Tables index

Veiw figure

View current table in a new window

• Traffic safety includes driver awareness applications, e.g. head way management, lane departure warning, speed management, traffic queue detection, and hazard warning, etc.

• Traffic efficiency includes adaptive electronic traffic signs, e.g. event detection and management. Similarly, it includes traffic efficiency through traffic flow optimization, e.g. incident detection and management, etc.

• Value-added services include service applications and high speed internet access, infotainment, location / route guidance and multimedia services etc.

Each node of VANET architecture contains an ITS station (respectively Vehicle Station, Roadside Station, Central Station and Personal Station). Along with local design, nodes also contain a gateway connecting the ITS station to out of VANET systems (respectively Vehicle Gateway, and Roadside Gateway). An ITS station comprises a number of ITS-specific functions and a set of devices implementing these functions. The communication function is supported by a mobile router in charge of communication with outside the vehicle whereas applications are supported by a number of other dedicated nodes (vehicle). A unique node may support both the communication functions and the applications for simple implementations.

Using IP for the ITS brings a number of benefits, including the possibility to interoperability and global connectivity ^{[6, 7]}. Considering the following facts, all standardization agencies have considered the compulsory use of IPv6:

• The global connectivity support for all vehicles.

• IPv4 address depletion.

• Enhanced features supported by IPv6, e.g. network mobility, auto-configuration, etc.

VANET can also use a wide range of other communication technologies ^{[3, 8, 9, 10]}, especially those already deployed / in-practice among different countries. On the one hand this approach offers great flexibility, however this creates interoperability issues. Table 1 discussed technical comparison of different access layer technologies being considered for VANET. Large scale variations, e.g. frequency management and QoS support, etc, clearly highlights interoperability issues.

According to the Dedicated Short Range Communication (DSRC) Project ^[11], the United States Federal Communication Commission allocated 75MHz bandwidth of the 5.9GHz band to Dedicated Short-Range Communication in 1999 ^{[12, 13]}. In 2001, the American Society for Testing and Materials (ASTM) selected IEEE 802.11a as the underlying radio technology for DSRC. In 2004, the IEEE started the work on the 802.11p amendment and Wireless Access in Vehicular Environments (WAVE) ^[14] based on the ASTM.

3. Efforts for VANET Standardization and Implementation

According to ITS Communication Architectures, VANET is based on vehicle to vehicle (V2V), vehicle to infrastructure (V2I) and vehicle to vehicle to infrastructure (V2V2I) communications. Efficient use of VANET can increases the response time for the driver, according to the quality and the reliability of information available to the driver about its environment, the other vehicles and road users. It also offers more detailed information about overall network, location of other vehicles and the road and weather conditions in the entire network. This information availability allows optimized use of road capacity. In addition, this information develops and enhances the functionality of the autonomous and independent ITS, driver assistance systems, traffic management systems, etc ^{[1, 2]}.

Figure 1. The comparison of all three architectures with the perspective of layers

Download as

PowerPoint Slide

Larger image(png format)

Figures index

Veiw figure

View current figure in a new window

View next figure

VANET research has taken considerable momentum in the last few years. Different applications and protocols for VANETs have been proposed and discussed in literature. According to IEEE Task Group ‘P’ (WAVE) ^[14] standardization of vehicular communication is now being pushed by established work groups of major standardization bodies (e.g. ISO, IEEE, etc) and consortia such as, Car-to-Car Communication Consortium (C2C-CC) etc. The brief overview of the projects and organizations involved in the VANET architectures is as under.

Wireless Access in Vehicular Environment was introduced by IEEE ^[13] and targets safety as well as infotainment applications ^[15]. WAVE architecture is quite simple in design, but lacks flexibility in nature. It is based on DSRC standard and uses single IEEE 802.11p wireless interface as the communication link for all kind of communication. It includes both V2V and V2I communication. This architecture defines data exchange between high speed node based onboard unit (OBU) and static road side unit (RSU). The DSRC Implementation Guide defines two types of WAVE messages, namely wave short message (WSM) for emergency messages and IPv6 based datagram for all other kind of applications. The former used for broadcast (emergency) applications while the latter for point to point communication such as toll collection, infotainment, etc.

GeoNet ^[6] / C2C-CC ^[16] architecture is backed by European Union (EU) automobile industry and is developed under ETSI ^[17]. GeoNet specified and implemented the architecture design of VANET in coordination with ETSI, C2C-CC and industrial projects. This architecture is aimed to establish an open European industry standard, focused on development of active safety applications. The architecture is designed to be used for both safety and non safety applications, and for use with both the infrastructure based (e.g. V2I) and infrastructure less (V2V) communication modes ^[15].

GeoNet uses specific position based geographical addressing and routing algorithms for provision of multi-hop communication ^[6]. This project focused on amalgamation of geographical addressing with IPv6 for node access to roadside units. Beaconing service for vehicle movement is also provided by network layer. Along with beaconing, location service is also a main component of geographical routing.

GeoNet is considered to be more flexible than WAVE with a slightly more complicated architecture. Unlike WAVE, safety applications can use different transport and network layer protocols along with C2C-CC. Similarly, non-safety applications can use C2CNet below IP stack along with traditional TCP/IP stack to access wireless multi-hop communications.

From physical and MAC layer perspective, different short range wireless LAN technologies including IEEE 802.11p can be used for both V2V and V2I communication. These traditional wireless LAN technologies include IEEE 802.11a/b/g/n and other radio technologies e.g. GPRS or UMTS etc.

This architecture introduced the concept of local dynamic map (LDM) ^[6] for VANET. LDM provides layered map structure for different VANET applications and services.

The CALM architecture ^[18] was introduced by ISO and is available to member entities only. It is the most flexible but significantly complicated architecture. ISO CALM is designed to provide continuous V2V, V2I and vehicle to other interfaces (V2O) communication. Its concept is based on heterogeneous cooperative communication framework.

For maximum flexibility, ISO CALM has kept the option open for use of any available access layer interface ^[15]. A few development projects like COOPERS ^[19] and SAFESPOT ^[20] have included the main concept of CALM.

Figure 2. An example of a generic VANET layout

Download as

PowerPoint Slide

Larger image(png format)

Figures index

Veiw figure

View current figure in a new window

View previous figure

View next figure

4. Test Bed Implementation Projects

The broad level comparison of all three architectures, i.e. WAVE, C2C and CALM, from different layers perspective is shown in Figure 1. We can observe that all three architectures have different approaches to address the transport layer, network layer and MAC layer issues. WAVE supports single MAC layer protocol, whereas other two architectures offer flexibility with support to variety of protocols and interfaces. Similarly, at network layer, CALM offers highest flexibility in comparison with other two architectures. However, WAVE design and implementation is the simplest amongst all. Basing on the design of three VANET architectures, different implementation projects were conducted in different countries. In addition to these architectures, few modifications were also tested under different projects. Summary of few completed projects is as under.

CVIS Project ^[21], aimed to design, develop and test the VANET technologies using CALM architecture. Project used precise positioning, local dynamic maps through a secure and open framework. The project gathered and integrated monitoring data from moving vehicles and others roadside units for validation of IPv6 amalgamation with CALM standard for continuous mobile communication. It also shared results with other standardization agencies for improve interoperability.

The COMeSafety Project ^[22], targeted different types of V2V and V2I issues for the provision of cooperative intelligent road transport systems. It also provided an open platform for integration of the interests of different public and private stakeholders.

Co-operative Systems for Intelligent Road Safety (COOPERS) ^[19], targeted versatile and new applications for VANET architecture based on CALM. It also targeted co-operative traffic management between vehicle and infrastructure. In addition, it also targeted improvement of road side infrastructure and traffic control applications for efficient V2I communication.

Based on CALM architecture, SAFESPOT ^[20], targeted road safety applications especially for accident scenarios. It used the slogan of “smart vehicles on smart roads”. It developed a “safety margin assistant” for early warning and timely awareness of the drivers. This concept is based on IEEE 802.11p for an intelligent cooperative system utilizing V2V and V2I communication.

As the name suggests, SeVeCom project ^[23] targeted detailed implementation of security requirements for VANET. These requirements include the security and privacy of V2V and V2I communication. During the project, different possible attacks under VANET scenario were tested e.g. fake information, denial of service or identity cheating. Project also tested authentication, availability & privacy requirements.

5. Fleet / Convoy Environment

Since 2000, many VANET implementation projects have been completed. However, use of VANET for some specific vehicle topology, such as fleet or convoy management is rarely implemented.

Fleet refers to a group of vehicles belonging to a single transportation system, agency or any business group, but with vehicles moving independently and at far away locations from each other. Typical examples are car rental companies, taxicab companies, bus companies, police or military departments and cargo / mail delivery operators. Most of these operators are either running commercial business models or are based on public sector law enforcement agencies.

A convoy network, on the other hand refers to a group of vehicles, traveling together for mutual support and protection, mostly organized for military / defense purposes.

Figure 2 shows a generic lay out of the VANET scenario. According to fleet / convoy management, any node may be in range to other same kind of node and may or may not have a link to management server. Any node is required to be connected to management server, either directly or through RSU.

Both fleet and convoy networks have their considerable peculiarities. These differences separate these types of road networks from general road traffic scenarios. VANET architectures designed for normal road movement may not fulfill all the requirements of these specialized network operators.

In the cases of fleet management, the frequency of road movement and road presence is significantly high. For both models, i.e. commercial and law enforcement, timely arrival at destination is of high importance. Business economy demands reemployment of single vehicle to multiple sequential tasks. Resultantly delay in completion of one task ultimately affects many following tasks.

The vehicles for both types of networks generally start off their journey from specific fixed points and then move towards different destinations following different schedules. Several vehicles that are part of the same fleet may converge at some specific distant locations during the journey. These converging points may include rest areas, management points or refueling services, etc. These converging points may be owned by the fleet / convoy operator itself or by other public or private service providers.

Both Fleet and convoy networks involves two different type of road scenarios. In first case, vehicles move toward a predefined end destinations with rare change involved during move, e.g. bus service or cargo service. However, second case involves sudden change of destination or pre-defined path due to run time requirements, e.g. patrolling police or emergency response patrols.

In such an environment, management of vehicles and their navigation would not be limited to the typical V2V communication scenario of VANET. Architectures based on simple road safety services and applications will require add-on services, involving a management server at the backend.

For fleet based networks, the fleet nodes may be wide apart and out from communication range of other fleet nodes. In such cases, fleet nodes will be required to use a relaying entity for passage of critical information. The management server shall be responsible for relaying information amongst vehicles moving far away from each other. In addition to back link, the fleet nodes moving on the road may encounter presence of other fleet nodes at while crossing each other, in case of node halt or at convergence points etc. in such case, nodes will be required to share operator specific data to each other using V2V communication.

Similarly for convoy nodes, most of the nodes will be involved in V2V communication scenario. However, back end connectivity to management server can be of extreme significance due to involvement of remote areas etc. Provision of back end link to each node may not be feasible or viable due to secrecy or other administrative requirements of the convoy. In such case, convoy nodes will also be involved for both V2V and direct / relay link to management server.

Figure 3. Design Overview

Download as

PowerPoint Slide

Larger image(png format)

Figures index

Veiw figure

View current figure in a new window

View previous figure

View next figure

6. Test Bed Design

Considering the VANET architecture purely from fleet and convoy management perspective, we selected GeoNet as base line architecture. We dove tailed the overall design to make it simpler and generic according to ground needs. The concept of multi interface being used by CALM and GeoNet was considered as compulsion to provide backhaul link in the absence of large scale deployment of VANET. Resultantly, our nodes could communicate directly to management server over the internet using long range communication. V2V communication was made available using short range Wi-Fi links ^[9].

After detailed analysis of geometry and design requirements of fleet and convoy operators, we considered different services to be provided to the nodes. These services were considered over and above the road safety applications and services defined in the standard VANET designs, such as alarm for emergency brakes, accident alert etc. In the absence of a deployed architecture, a need was felt to provide route alerts, road and weather condition warnings, etc., through central server based on the concept of geographical tagging.

Four applications were short listed as the bare minimum requirement to provide optimum efficiency to the fleet / convoy management system. The significance of four targeted services namely, text chat, voice chat, location updates and situational alerts, is explained subsequently.

Any node equipped with VANET devices/software is the only source of data acquisition. The location and situational updates such as the node's own geographical location, weather and road condition updates can be obtained through onboard sensors. Collected data can subsequently be shared and disseminated to other nodes either through V2V or relay through management server. Hence, the said feature was considered as the basic necessity of any VANET based management system.

Using LDM ^[6], each node as well as the management server can graphically observe the location of each node and other selected information. Location of each node acquired through GPS could be shared after a periodic interval through V2V communication and management server.

The presence of each node location and other geographical based updates such as weather conditions in some specific area could help managers as well drivers to immediately respond to mobility scenarios. The facility could help the drivers to respond to eventualities, such as accidents, by approaching nearest nodes and vice versa.

During the movement of a node away from other nodes and the management server, each node requires remote alerts. The easiest way to provide these alerts are interactive text messages and visual map alerts. The significance of both these alerts is their availability even if any driver missed them in the first instance. By using this service, the vehicles could share collected data through their onboard sensors and communicate with each other and with the management server accordingly. The shared data could be traffic-management related such as congestion, road blockage, broken road or bad weather warnings. Similarly, vehicle-management related information, such as need of fuel or any hookups etc can also be shared through same service

The emergency alert service such as accident alert allows affected driver to broadcast emergency message over the air through single touch at the console screen. The feature is an add-on to the text chat feature, where all relevant data such as node location, type of node, etc is shared with management server and all nearby nodes through automated procedure. Multiple emergency messages could be pre-programmed and disseminated among the users according to priority. The service allows efficient emergency response even to an ill trained or injured driver. Many other counter actions, such as information sharing to ambulance, police or other departments could also be linked according to type of message.

We considered the need of voice chat for an advanced user node, where situation demands higher degree of data sharing among nodes and management server. The basic purpose of text and voice chat is the same i.e. emergency alerts, providing utility and infotainment. However, sending a text message and then waiting for an acknowledgement may sometimes be inconvenient for the driver. Moreover, a situation where a driver needing a longer data link such as emergency health advice or advice in case of vehicle breakdown could be shared using voice chat.

Figure 3 illustrates the basic design used for experimentation. We selected Wi-Fi for V2V communication and WiMAX for V2I (management server) communication. Although Wi-Fi has significantly short range of 100 meters, but it was selected only due to ease of availability and cost effectiveness. Our proposed design is not WiMAX or Wi-Fi dependent and any other available infrastructure could be used for both type of links such as 802.11P and HSDPA etc. The large scale deployment of WiMAX in Pakistan supported our design for backhaul connectivity.

Considering the limited number of nodes and to provide ready state routing, we selected Optimized Link State Routing (OLSR) as network layer routing protocol. The OLSR has shown quite impressive results for limited node scenario in VANETS in comparison to other routing protocols ^[24].

7. Prototype Development and Results

The proposed design was implemented on ARM-11 and Intel ATOM boards in Linux environment. Each OBU was equipped with following:-

• Embedded Linux based ARM-11 / Intel ATOM mother boards.

• Backend application and database.

• Front end GUI applications build on JAVA for LDM and chatting service.

• A Global Positioning System (GPS) Dongle

• OLSRD daemon

• Wi-Fi interface for short range V2V & V2I communication

• WiMAX for long range V2I communication

• Touch screen based display

The system was tested in two phases. In the first phase, the complete application (performing the mentioned four functions) was tested on three laptops. Two of these acted as OBU’s and were made dynamic with respect to their location. The third machine was demonstrated as a management server and hence remained static in its position.

Figure 4. Snapshot of Local Dynamic Map

Download as

PowerPoint Slide

Larger image(png format)

Figures index

Veiw figure

View current figure in a new window

View previous figure

View next figure

Figure 5. Snapshot of the hardware installed in a car

Download as

PowerPoint Slide

Larger image(png format)

Figures index

Veiw figure

View current figure in a new window

View previous figure

View next figure

The application was developed in QT (framework) and JAVA. Google maps were used for offline development of LDM as shown in Figure 4. C++ was used for text chat application and emergency alert module. The ‘asterisk’ server was used for both routing and establishment of calls. The registration information and the dialing plan were stored in asterisk configuration files. Registration numbers and sip numbers were assigned to all three vehicles exactly same as their vehicle identification (number plates), for easy recognition and maintaining practicality and scalability of the system. The asterisk server was required to be run only on the management server (a static IP) while the soft-phone (Linux based “twinkle”) was configured on every node.

In the second phase, the application was shifted to industry graded stand alone mother boards. The board served as a compact enough prototypes so as to be easily installed in a vehicle. It also had the privileges of pre-configured Wi-Fi interfaces, audio IN/OUT ports and could easily be interfaced to a GPS Device and also to a 7” car LCD Monitor. The system was installed in a car as show in Figure 5. The small antenna shown in top left segment is a combined Wi-Fi & WiMAX antenna for the OBU. The top right corner shows the touch screen installed on the dashboard of the car. The bottom portions of the figure show the complete hardware unit, including board, power supply unit, communication interfaces and GPS sensor. The car communicated successfully with other nodes for V2V communication and management server for V2I communication.

Figure 6 shows the frontend graphical user interface (GUI) of the VANET application at the node, whereas Figure 7 shows the GUI for the management server.

Right half of the GUI shows the LDM of the operator. In the GUI of the node, each node finds its own position in the centre of the map, whereas in the GUI of management server, deployment of all nodes can be seen in colored dots (red blue & green). Blue line in LDM of Figure 6 shows the direction to the nearest node or management server access point. The screen could be scrolled accordingly using touch feature.

Left half of the GUI shows the online client directory for voice and text chat as well as interface for emergency preconfigured alarms. The right half of the left portion shows the ongoing text chat. The black portion with green writing is used to display the emergency alarms received from management server or nearby vehicle nodes.

Figure 6. The front end Graphical User Interface at each node

Download as

PowerPoint Slide

Larger image(png format)

Figures index

Veiw figure

View current figure in a new window

View previous figure

View next figure

Figure 7. Graphical User Interface at the management server

Download as

PowerPoint Slide

Larger image(png format)

Figures index

Veiw figure

View current figure in a new window

View previous figure

The hardware independent development on two different types of mother boards made the design highly generic for implementation on any network. However, it was observed that development on ARM-11 board requires more expertise due to its peculiar nature.

Due the unavailability of DSRC modules at reasonable budgets, Wi-Fi was used as the communication mode and its range was observed up to maximum of 150 meters. However for voice chat, quality of voice started degrading after around 70m.

All nodes registered successfully with Asterisk and successful calls were established among all nodes using Wi-Fi and management server using WiMAX.

Initially location updates were shared with the periodic delay of 3 seconds which could be reduced to 1 second according to type of network. Considering the maximum speed of 120 kmph, a node actual position may vary to an acceptable limit of 30 meters only. The variation is not significant as the application on the nodes does not involve accident avoidance scenario. The provision of emergency response and other local updates may well be coordinated in advance according to 30 meters error limit.

8. Conclusions

Working under a typical VANET environment, the system was observed to be highly efficient for traffic load management and resource management. Communication to the management server was reliable (i.e. no data loss was observed) and efficient enough. The three node scenario was developed such that it is scalable enough to be extended to a number of nodes and additions and modifications in the functionality / application can be implemented in a generic manner.

A lot of future enhancements are possible. Data ranges may be extended by replacing the Wi-Fi module with DSRC. Noise observed during voice chat may be reduced by implementing any echo-reduction and noise reduction algorithms in asterisk software.

For constructing a better Fleet Management System, functionalities such as speed and fuel management may as well be implemented in future.

References

[1]	Moez Jerbi, Sidi Mohammed Senouci, Mohammed Cherif, Yacine Ghamri “Vehicular Communications Networks: Current Trends and Challenges” Book Chapter in “Next Generation Mobile Networks and Ubiquitous Computing” IGI Global, 2010.
	In article
[2]	Jeffrey Miller “Vehicle to Vehicle to Infrastructure (V2V2I) Intelligent Transportation System Architecture” IEEE Intelligent Vehicles Symposium, 2008.
	In article
[3]	Jose´ Santa, Antonio Moragon´ and Antonio F. Gomez-Skarmet “Experimental Evaluation of a Novel Vehicular Communication Paradigm Based on Cellular Networks” 2008 IEEE Intelligent Vehicles Symposium Eindhoven University of Technology Eindhoven, The Netherlands, June 4-6, 2008
	In article
[4]	Tamer Nadeem, Pravin Shankar, Liviu Iftode, “A comparative study of data dissemination models for VANETs”, in: Third Annual International Conference on Mobile and Ubiquitous Systems: Computing, Networking and Services, San Jose, 2006.
	In article
[5]	Böhm and M. Jonsson, “Handover in IEEE 802.11p-based Delay-Sensitive Vehicle-to-Infrastructure Communication”, Research Report IDE - 0924, School of Information Science, Computer and Electrical Engineering (IDE), Halmstad University, Sweden, 2009.
	In article
[6]	GeoNet. “Final GeoNet Specification”. GeoNet Deliverable D2.2, January 2010.
	In article
[7]	J. Choi, Y. Khaled, M. Tsukada, and T. Ernst. “IPv6 support for VANET with geographical routing“. In Proc. of the ITST, Pukhet, Thailand, 2008
	In article
[8]	V. Gonzalez, A. L. Santos, C. Pinart, and F. Milagro, “Experimental demonstration of the viability of IEEE 802.11b based inter-vehicle communications,” in TridentCom 2008, March 2008.
	In article
[9]	Chien-Ming Chou, Chen-Yuan Li, Wei-Min Chien, and Kun-Chan Lan “A Feasibility Study on Vehicle-to-Infrastructure Communication: Wi-Fi vs. WiMAX”. Mobile Data Management 2009: 397-398
	In article		PubMed
[10]	Toshiya Okabe, Takayuki Shizuno, Tsutomu Kitamura, Wireless LAN access network system for moving vehicles, in: 10th IEEE Symposium on Computers and Communications (ISCC05), La Manga del Mar Menor, 2005.
	In article
[11]	DSRC “The DSRC Project,”
	In article
[12]	https://www.leearmstrong.com/DSRC/DSRCHomeset.
	In article
[13]	Hannes Hartenstein and Kenneth P Laberteaux, Ed “VANET: Vehicular Applications and Inter-Networking Technologies” John Wiley & Sons, Ltd 2010.
	In article
[14]	Task Group p, IEEE P802.11p: Wireless Access in Vehicular Environments (WAVE), draft standard ed., IEEE Computer Society, 2006.
	In article
[15]	Committee SCC32, IEEE P1609.4 Standard for Wireless Access in Vehicular Environments (WAVE) - Multi-Channel Operation, draft standard ed., IEEE ITS Council, 2006.
	In article
[16]	Sajjad Akbar Mohammad, Asim Rasheed and Amir Qayyum, “VANET Architectures and Protocol Stacks: A Survey” Communication Technologies For Vehicles, Lecture Notes in Computer Science, 2011, Volume 6596/2011, 95-105
	In article
[17]	C2C “Car2Car Communication Consortium,”
	In article
[18]	https://www.car-to-car.org/
	In article
[19]	ETSI. “Intelligent Transport Systems (ITS); Vehicular Communications; GeoNetworking and Data Transport; Part 6: Transmission of IPv6 Packets over Geo-Networking Protocols”. ETSI, December 2009.
	In article
[20]	TC204 WG16. “Intelligent Transport Systems – Communication for Land Mobiles (CALM) – Architecture”. ISO FDIS specification 21217, ISO, October 2009. (www.calm.hu).
	In article
[21]	CO-OPerative SystEms for Intelligent Road Safety, 2006 (https://www.coopers-ip.eu).
	In article
[22]	SAFESPOT Integrated Project, 2006 (https://www.safespot-eu.org)
	In article
[23]	CVIS Project for Intelligent Co-operative System, 2006 (https://www.cvisproject.org).
	In article
[24]	European ITS Communication Architecture - Overall Framework - Proof of Concept Implementation. Draft Version 2.0, COMeSafety Specific Support Action, 2008.
	In article
[25]	SE-cure VE-hicle COM-munication, SEVECOM, 2006 (https://www.sevecom.org).
	In article
[26]	Imran Khan and Amir Qayyum, “Performance evaluation of AODV and OLSR in highly fading vehicular ad hoc network environments” 13th IEEE International Multi-topic Conference (2009).
	In article