Vehicular ad hoc networking based on the incorporation of geographical information in the IPv6 header
© Vandenberghe et al; licensee Springer. 2012
Received: 19 December 2011
Accepted: 14 August 2012
Published: 19 October 2012
Several approaches can be identified in the domain of vehicular ad hoc networks (VANET). Internet Protocol version 6 (IPv6) networking and non-IP geographical networking can each fulfill a subset of the application requirements. In general, a combination of both techniques is proposed to meet all of the application requirements. In this case, packets of one VANET routing protocol are encapsulated inside packets of another. This tunneling, together with the position service required for non-IP geographical unicasting, makes such a combined solution rather complex, and hence more challenging to implement, debug, and maintain. In this article, a new VANET approach is presented that relies on the key assumptions that geo-anycast functionality is not required by the applications, and that geographic unicasting is not needed when IP-based unicasting is provided. This enables the adoption of an IPv6-only VANET solution, removing the need for tunneling and position services. New techniques are required to support IPv6-based geo-broadcasting. In this article, it is described how addresses should be assigned, how geographical data can be incorporated in the IPv6 address, how the other IPv6 header fields can be used to contain additional VANET information, and how routing should be handled to guarantee that no modifications are required to the application units. The implementation of the proposed techniques is described, and the correct functionality of the solutions is experimentally demonstrated. Finally, to prove the added value compared to current state-of-the-art propositions, the presented solution is stacked up against the recently released ETSI standards TS 102 636-4-1 (geographical addressing and forwarding) and TS 102 636-6-1 (transmission of IPv6 packets over GeoNetworking protocols).
Intelligent transport systems (ITS) are ICT systems that enable a more efficient and safer traffic through the use of diverse technologies. In the ITS domain, cooperative systems allow innovative applications that rely on vehicle-to-vehicle (V2V) and vehicle-to-infrastructure communication to increase the time horizon, the quality, and reliability of information available to the drivers about the road conditions and other vehicles in their immediate environment. To enable such forms of interaction, vehicles equipped with local wireless communication interfaces are interconnected in vehicular ad hoc networks (VANET).
Numerous research efforts have already been put into the VANET domain. Routing and broadcasting protocols have been developed in several initiatives, using Internet Protocol version 6 (IPv6) as well as non-IP-based geonetworking solutions, each providing different functionalities for data exchange and dissemination. To cover all communication requirements imposed by the applications, several efforts have focused on combining IPv6 and geonetworking into a common ITS communication system architecture. This is typically based on the encapsulation of packets from one VANET routing protocol inside packets of another. This tunneling, together with the position service required for non-IP geographical unicasting, makes current combined solution rather complex.
However, in the domain of software development, one of the rules of thumb is that simplicity should be a key goal in design, and that unnecessary complexity should be avoided. This design principle is often referred to with the famous acronym KISS (Keep it Simple, Stupid!). The advantage of this principle is that it strives to make code easier to implement, debug, and maintain. The result is a positive influence on both software quality and development cost. An example of a software system where the KISS principle is rigorously and successfully applied is the Unix operating system. Another example is the Internet, for which the architectural principles are described in RFC 1958. In that document, it is literally mentioned that a general design issue is to keep it simple. When in doubt during design, one should choose the simplest solution. Based on these two examples and previous experiences in design and development of ad hoc network protocols, the authors of this article firmly believe that the pursuit of simplicity in designs would be of great benefit in the domain of VANETs. This conviction is further strengthened by the observation that VANETs will be very heterogeneous, consisting of vehicles of many different brands, each possibly equipped with other implementations of the applicable VANET protocols and standards. For a satisfactory operation of the VANET, it is of the utter importance that each of these implementations is robust and unambiguous. Adoption of the KISS design principles facilitates this goal.
The goal of this article is to present an approach to VANET that fulfills all imposed application requirements in a simple yet effective manner. It is an evolution of previous study. Compared to this previous publication, the approach presented in this article is characterized by an overhauled mechanism to support delay tolerant networking and a novel approach to intra-station dissemination of VANET packets. Several other new elements were added, such as a detailed implementation description, an experimental validation of the functionality and a thorough comparison with the applicable European Telecommunications Standards Institute (ETSI) standardization efforts. These ETSI specifications regarding geographical addressing and forwarding and transmission of IPv6 packets over GeoNetworking protocols were released recently, and represent the current state-of-the-art in combined VANET networking solutions. The article is organized as follows: the “VANET networking techniques” section introduces the different available approaches to VANET networking. The “Communication requirements” section performs an analysis of the required data dissemination functionalities from an application point of view, and recites other design requirements imposed by the typical ITS architecture. The “Solution description” section describes the technical details of the proposed solution, and the “Implementation details” section presents the actual implementation. An evaluation of the proposed approach to VANET networking is performed in the “Evaluation” section. Finally, the article is concluded with a Conclusions section.
VANET networking techniques
The numerous VANET networking techniques that have been developed in the past research efforts can be divided in three classes: IPv6-based networking techniques, non-IP solutions, and combined approaches.
Applying IPv6 for VANET networking has some significant advantages[6, 7]. First of all, IP can support all types of ITS applications, while allowing developers to rely on established networking APIs. IP can also bring (legacy) Internet applications (web browsing, video streaming, peer-to-peer file sharing, online gaming, etc.) to the vehicles. Since it is the de facto standard for data exchange, IP ensures interoperability of ITS communication systems with other communication systems. Using IP, applications can run transparently over diverse underlying communication media.
The most important reason to adopt IPv6 in the VANET domain instead of the common IPv4 protocol is the fact that IPv4 does not provide a sufficient amount of available IP addresses. Because IPv4 addresses are 32-bits long, the size of the entire address space is 232 or approximately 4.3 billion, of which the major part has already been assigned. On a global level, the Internet Assigned Numbers Authority (IANA) allocated the last available addresses on February 3, 2011. On a regional level, the unallocated address pool is already exhausted for one regional Internet registries (APNIC which is responsible for example China and India) and it is estimated that the other regions will follow within a few years. IPv6 addresses have a length of 128 bits, resulting in an address space size of 2128, resolving the address exhaustion problem. Other advantages of IPv6 are the inherent auto-configuration capabilities and network mobility support.
A disadvantage of IPv6 is that it has no built-in notion of geographical information. This means that it does not support concepts such as geocasting where data are disseminated to vehicles within a given geographical area. Therefore, routing protocols have to rely on topology information instead of geographic information. Typically, IPv6 VANET routing protocols extend existing ad hoc protocols with techniques to improve performance and reliability. Several publications exist that focus on enhancing reactive ad hoc routing protocols such as the Ad Hoc On-Demand Distance Vector Routing protocol. The notion of link and route lifetime estimates has been introduced, based on velocity vectors and other movement information[9, 10]. Other studies focus on restricting the flooding of the route requests[11, 12]. Proactive ad hoc routing protocols such as the Optimized Link State Routing Protocol (OLSR) were also extended with VANET optimizations. The movement predication-based routing framework adjusted OLSR to prefer most stable paths instead of shortest paths, while the authors of proposes DHT-OLSR, combining OLSR with techniques from the domain of peer-to-peer networking: dynamic clustering and distributed hash table routing. The third class of existing ad hoc protocols, the hybrid routing protocols such as the Zone Routing Protocol (ZRP), have also been optimized for the VANET scenario. The adaptive ZRP enhances the performance of ZRP with the use of a variable zone radius for every node, based on a metric called route failure rate, while the Sharp Hybrid Adaptive Routing Protocol monitors traffic patterns and local network characteristics such as link failure rate and node degree to determine zone sizes.
Topology broadcast protocols disseminate packets from a source node to all nodes located at a specific distance, in terms of hops. WAVE Short Message Protocol (WSMP) and CALM FAST are the two most important topology broadcast protocols that aim to achieve higher repetitive broadcasting efficiency by substituting the IP protocol. WSMP is standardized by IEEE as part of the IEEE 1609.3 standard. It defines a short message header, containing information such as WSM length, version number, security info, application class, application data and transmission power, rate, and channel. The length of the packet is 9 bytes plus the variable byte size of the application context data. WSMP only supports single-hop broadcasting, not multi-hop. CALM FAST is a networking protocol currently being standardized by ISO, combining networking and protocol layer functionalities. It is based on a two-octet network header containing the source and destination address of the packet. The protocol is primarily designed for single-hop communications, although it supports n-hop broadcasts in the optional FAST transport protocol extension.
The basic idea behind geographic networking is that nodes can be addressed using geographic concepts such as locations and areas, and routing decisions can be based on inter-node distance, relative movement, etc. Depending on the destination type, several geo-routing schemes may be used. Geo-unicast routes data from a source node to a single destination node which is identified by its exact geographical location. Since this location will change over time due to the mobility inherent to VANET nodes, a position service is required that maintains a mapping in real-time between vehicle identity and exact location. Geo-anycasting refers to the situation where data are routed from a source node to one random node that is located within a defined geographical broadcasting area. Geo-broadcasting is used when data is routed from a source node to all nodes located within a defined geographical area.
The different publications in the domain of geographic networking can be classified in a set of common techniques. One of them that is applied by many is opportunistic broadcasting, where the probability that a node B will retransmit a broadcast message sent by node A is dependent of the distance between A and B: the greater the distance, the higher the probability that B will re-broadcast[19–21]. Another common technique is irresponsible forwarding, where the probability that node B will rebroadcast the broadcast message of A is dependent of the neighborhood density[22–24]. Greedy forwarding lets the sender node A itself select the next node B that has to rebroadcast the message, aiming to achieve a maximum traveling distance per rebroadcast[25–27]. In urban environments, intersection routing strategies are often utilized[28–30].
It is very likely that VANETs will have to support the different functionalities provided by both the IPv6 and the non-IP solutions for the actual deployment of cooperative applications. This vision was extensively researched in the GeoNet project. The project investigated how IPv6 connectivity can be provided in combination with the non-IP-based networking protocols CALM FAST and the C2C-CC geographic networking protocol. It was chosen to encapsulate IPv6 packets in C2CNet packets to transport them within the GeoNet domain. During the course of the project, this tunneling technique was implemented, validated, and evaluated. It could be concluded that based on this approach all requirements can indeed be met in a satisfactory fashion.
However, tunneling makes the solutions more complex compared to a single-protocol solution. As elaborated in the introductory section 2, unnecessary complexity makes designs more challenging to implement, debug, and maintain in future products. Higher levels of complexity can also raise interoperability issues. In the “Complexity analysis” section, this aspect is discussed in more detail.
The GeoNet work was continued in two different tracks. The first is the further implementation in the CarGeo6 initiative. This is a joint effort of the Tunisian school ESPRIT and the French institute of research in computer science, INRIA. In contradiction to the original proprietary GeoNet implementations, CarGeo6 is an open-source implementation of IPv6 GeoNetworking, conforming with GeoNet specifications. A validation of CarGeo6 can be found in. The second track is the standardization of the GeoNet specifications by the ETSI. In the following subsections, the two corresponding standards are introduced.
ETSI technical specification TS 102 636-4-1
ETSI technical specification TS 102 636-6-1
To support the transmission of IPv6 packets over the ETSI GeoNetworking protocols described in the previous subsection, the GeoNetworking to IPv6 Adaption Sub-Layer (GN6ASL) is proposed by ETSI in TS 102 636-6-1. It is an additional layer at the networking level that is positioned between the GeoNetworking layer and the IPv6 networking layer. It integrates the functionalities of the IPv6 and GeoNetworking implementations in a transparent way. This means that from the IPv6 point of view, GN6ASL is just a link-layer protocol which is responsible for the communication of an IPv6 packet between two IPv6 nodes connected to the same link. From the GeoNetworking point of view, GN6ASL is just a higher layer that produces data packets that have to be geo-unicasted or geo-broadcasted to a specific destination. No adaptations to any of the two implementations are required, both protocols are not even aware of each others existence.
The main concept behind GN6ASL is the virtual link. A virtual link can span multiple physical links. Two types are defined. A geographical virtual link (GVL) is a multicast-capable virtual link with geographically scoped boundaries. It is associated with one single GeoNetworking GeoBroadcast/GeoAnycast area (also called geoarea). A topological virtual link (TVL) is a non-broadcast multi-access virtual link with topologically scoped boundaries. IPv6 multicast traffic may not be exchanged through a TVL. Both types of virtual links are associated to physical interfaces in a slightly different manner: one physical interface can be associated to multiple GVLs but to only one TVL. The GN6ASL layer provides the virtual interfaces to IPv6 in the form of virtual network interfaces. Such virtual interfaces can be assigned to either GVLs or TVLs, but a single virtual interface can only be associated to one GVL or one TVL.
To configure the virtual links and the IPv6 network on top of them, standard IPv6 stateless address autoconfiguration (SLAAC) is applied. IPv6 routers broadcast Router Advertisements on their configured GVLs using the corresponding virtual interfaces. This is translated by GN6ASL to geo-broadcast ETSI GeoNetworking packets with a destination area equal to the corresponding GVL area. Upon the reception of such an advertisement by other nodes within that area, these nodes will check if they have already configured this GVL. If not, they will create it using the destination area of the GeoBroadcast packet, configure a new corresponding virtual interface, and forward the packet over that interface to the IPv6 layer for further SLAAC execution. This approach is most suitable in the situation where roadside units (RSUs) provide wireless coverage. In that case, each consecutive RSU is responsible for its own area, and will continuously broadcast Router Advertisements on the corresponding GVL. Vehicles will then continuously join and leave GVLs based on their current position. The overhead on the wireless medium is limited to the broadcasts of the RSUs. However, on roads where no such RSU coverage is available, vehicles are themselves responsible for creating GVLs that enable them to communicate with the surrounding vehicles. If all vehicles start defining a GVL around its own position, and hence continuously broadcast router advertisements, this will result in a significant load on the wireless medium. However, if too few nodes try to set up a GVL, this could lead to situations where vehicles are within each others’ communication range but fail to actually communicate IPv6 packets. A suitable protocol that takes these trade-offs into account is required, but not yet available.
Based on these virtual links, IPv6 packets can be encapsulated in GeoNetworking packets. In the case of traffic originating from the IPv6 layer (outbound traffic), the IPv6 layer selects the outgoing interface itself. If this interface is one of the virtual interfaces associated to a GVL or TVL, the packet is processed by the GN6ASL. The packet will be encapsulated in a GeoNetworking packet. In case of a multicast IPv6 packet, this will be a GeoBroadcast packet with a destination area equal to the GVL area that corresponds with the virtual interface that received the packet. In case of unicast traffic, this will be a GeoUnicast packet for which the destination address is directly derived from the interface identifier (IID, last 64 bits of the IPv6 address) of the destination IPv6 address. This kind of address resolution without neighbor discovery is possible because the TS 102 636-6-1 standard states that a compliant ITS station should use IPv6 addresses containing IIDs that directly resolve to its GeoNetworking address. Quite similar is the processing by GN6ASL of received GeoNetworking packets transporting IPv6 packets (inbound traffic). The main challenge there is the determination of the virtual link that the packet belongs to. In case of GeoBroadcast messages, a GVL is searched for which the GVL area matches the destination area of the GeoBroadcast packet. In case of a GeoUnicast header, a slightly more complex procedure takes link scope and the relation between the position of the source and the available GVLs into account.
An enumeration of common cooperative ITS applications is given by different standardization organizations such as the C2C-CC and ETSI[34, 35]. An analysis of their different requirements regarding supported networking techniques can result in a common list of requirements imposed on any generic VANET networking solution.
General capabilities for C2C-CC applications
V2V Cooperative awareness
V2V unicast exchange
V2V decentralized environmental notification
Infrastructure 2 vehicle (one-way)
Local RSU connection
Internet protocol roadside unit connection
Topology broadcast, Geo-broadcast
Topology broadcast, Geo-broadcast
Topology broadcast, Geo-broadcast
300 m to 1 km
0 m to 5 km
300 m to 20 km
300 m to 5 km
0 m to 1 km
0 m to full radio range
Not required but can assist
Vehicle must trust RSU
RSU/OBU must trust each other
Internet security (IPSec, appl. layer)
The European ITS Communication Architecture described in the COMeSafety project defined the ITS station as the core component in the four different instantiations (vehicle, personal, roadside, and central station). ITS Vehicle Stations and ITS Roadside Stations consist of a Communication & Control Unit (CCU) and one or more Application Units (AU). The CCU shall be equipped with at least a single ITS external communication interface to provide connectivity to external networks. This will typically be a short-range wireless network interface for VANET communication, often accompanied by a mobile data network interface for continuous Internet connectivity. Both the CCU and the AUs are also equipped with an ITS internal communication interface for data exchange between the different ITS Station components, typically an Ethernet interface. Important communication requirements for this architecture are given in:
It must remain as close to the IP standard as possible, no strong modifications to the IP stack of the involved components should be required.
Because of radio throughput limitations, the introduced overhead should be kept as low as possible.
No modifications should be required in the AUs, since these can be IP standard legacy devices.
In the previous sections an overview of possible VANET networking approaches was given. Based on an analysis of cooperative applications it was determined which of the networking techniques have to be supported by all VANET solutions. These requirements were supplemented with requirements imposed by the European ITS Communication Architecture. Based on this set of requirements, the VANET networking solution presented in this article was designed.
In the “Application requirements” section, it was determined that unicasting, topology broadcasting, and geo-broadcasting should be supported. However, no requirements are imposed on the unicast technique: as long as it is possible to address and route data from a source to one well-defined destination, it does not matter if this destination is defined on an IP basis, or on a geographical basis. Combined solutions based on packet encapsulation (section “Combined solutions”) support both, but introduce a complexity in the routing process that could be avoided. If a networking solution would choose to only support IPv6 unicasting, and not geographical unicasting, it would still fulfill the communication requirements, but it would not need to support the more complex tunneling. Another advantage is that the position service for geographical unicasting is not required in IP unicasting. In a similar manner, support for geo-anycasting can also be omitted without violating the application requirements, since only geo-broadcasting is demanded.
Based on these observations, the VANET networking solution presented in this article is designed as a pure IPv6 solution. This way, unicasting implementation is straightforward, and topology broadcasting can easily be supported by combining multicasting with correct usage of the Hop Limit header field. Geo-broadcasting however requires further refinement of the proposed solution. A mechanism is required to incorporate all required geographical data in the standard IPv6 header. In the following subsections our VANET networking solution is described in more detail.
Automatic address assignment
The main idea behind the chosen approach for automatic address assignment is the fact that the CCU receives a valid IPv6 address block from its operator or ISP (if the CCU has no mobile Internet uplink, this is performed once in a special configuration session at home, in the garage, etc.), divides this in smaller subnets, dedicates a subnet to every attached network (VANET, Internet uplink, internal station network, etc.) and correctly configures its own interfaces. Once these steps are performed, it starts broadcasting IPv6 router advertisements on its local network interfaces, just like any other IPv6 router would, enabling IPv6 SLAAC for all connected AUs.
The IETF recommends that mobile networks such as vehicles or mobile phones with an additional network interface (such as Bluetooth or 802.11) should receive a static/64 prefix to allow the connection of multiple devices through one subnet. However, this range is too small for modern vehicular networks where the CCU is a mobile router interconnecting multiple subnetworks over its different network interfaces. Since the IPv6 Addressing Architecture defines that all global unicast addresses other than those that start with binary 000 have a 64-bit IID field, the CCU cannot divide the received prefix in smaller subnets. Therefore, we propose that the CCU should follow the general case described in, and receive a /48 prefix. This way, the CCU can construct the global unicast address: the first 48 bits contain the received static prefix, the next 16 bits define the subnets for the different connected networks, and the last 64 bits are the IID which is constructed using standard stateless configuration mechanisms.
This simple approach needs no adjustments to the AUs. The addresses used for the VANET networking interface of the CCU are dependent on the static prefix assigned to the CCU, therefore guaranteed to be unique. This means that there is no need to support the Neighbor Discovery protocol within the VANET, which would require more complex techniques to be supported in the VANET domain. The only partial functionality of the Neighbor Discovery protocol that our solution does require on the VANET is address resolution to translates the next hop IPv6 address to the corresponding 802.11p MAC address. However, in an IPv6 ad hoc network, the next hop during multi-hop forwarding (which is determined by an active VANET routing protocol) will always be a node within communication range of the sender. This means that the neighbor solicitation and advertisement messages can be limited to single-hop broadcasts, which can directly be translated to MAC broadcast messages.
IPv6 geographical addressing scheme
This article defines a VANET networking solution based entirely on IPv6. Since geo-broadcasting is a crucial requirement for many cooperative applications, a mechanism that incorporates the necessary geographical data is indispensable. To define this mechanism, a more profound insight in the required geographical data is required. Kovacs defines a position vector containing the following data fields: MAC id, C2C NET ID, timestamp, position in latitude, longitude and altitude, and speed and heading. Similar data fields are defined in the long position vector defined in (see “Comparison with ETSI technical specification TS 102 636-4-1” section). Since this article chooses to work with IPv6 only, the MAC id and C2C NET ID can be dispensed. Position in latitude and longitude is absolutely required for geocasting. A timestamp allows delay tolerant nodes to destroy queued packets or to keep valid messages alive in the geographical destination area, without being aware of the applied upper layer protocols. Heading information can be used to limit rebroadcasting to certain areas, which could be a valuable mechanism to tackle the broadcast storm problem in dense networking conditions. Speed and altitude are considered by the authors of this article as less decisive parameters for the addressing of nodes in a VANET context, and will not be included in the proposed solution. This decision is motivated by the observation that the applications analyzed in the “Application requirements” section rarely include speed or altitude information when defining the destination for their messages. Hence, it makes no sense to incorporate these concepts on the networking level. In the exceptional case that such functionality would be required, a more suitable approach is to apply a filter mechanism on the application layer that takes speed and/or altitude into account.
Different techniques to include this geographical information in VANETs are introduced by Gordillo and Khaled. Besides the tunneling approach that we wish to avoid in this article, they proposed two other solutions. The first approach is to include it in the application layer, e.g., using an extended DNS that is capable of storing geographic information. This could easily be implemented, but it is not really adapted to a mobile environment, and the scalability of this approach is unclear. The second approach is to include all information in the IPv6 protocol. This can be done in three different ways: all information can be put in the IPv6 destination address using a special addressing scheme, it can be put in the existing IPv6 header fields by redefining their interpretation, or it can be encoded in a newly defined IPv6 Extension Header.
Geographical IPv6 addressing scheme
The last 24 bits are used as an expiration timestamp. They represent the least significant bits of the corresponding Unix time, a 32-bit value defining the number of seconds elapsed since midnight of January 1, 1970. To handle buffer overflows introduced by this reduction in bitsize (where the value of a timestamp in the future can become smaller than the current time), we define the maximum supported difference between current time and expiration time as half of the interval, or 223 s. Nodes will only consider a packet as expired when both of the following requirements are met (all time values are in the 24 bits format): the current system time is equal to or higher than the packet expiration timestamp and the absolute difference between the current time and the expiration timestamp is lower than the maximum supported difference. This way, timestamp overflow will not result in the unnecessary expiration of the packet. Hence, our solution supports a packet validity of up to 97 days, with a granularity of 1 s. To allow geo-broadcasting without limitations in the time domain, 0×0 is defined as a special value for the packet expiration timestamp field.
Interpretation of IPv6 header parameters
Interpretation of IPv6 header parameters
QoS class 802.11p
Topology broadcast: # hops
Global VANET unicast address
Topology broadcast: FF16::1
To support topology broadcasts, correct values need to be used in the Hop Limit field in combination with a special destination address equal to FF16::1. The traffic class value is used to signal the IEEE 802.11p (or ITS-G5A) MAC layer which priority to be used. The source of any (geo-)broadcast packet always has to be the global unicast IPv6 address of the sender, since multicast addresses may not be used as source addresses. This also allows unicast communication with nodes that were discovered through (geo-)broadcast announcement.
Addressing scheme for intra-station multicasting of VANET packets (based on RFC 4489)
IID of CCU interface on intra-station subnet
The CCU routing functionality requires some adjustments on the IP stack. It has to interpret the used geocast destination addresses, and has to know how to forward them on the VANET. The other way around, it has to be able to decide if it’s within the broadcast range of a geocast message received on the VANET interface, and to duplicate and forward it to the appropriate intra-station multicast groups. To decide when and how to rebroadcast or route messages, it can apply any desired broadcasting or ad hoc networking protocol. This flexibility is an important advantage of the proposed solution. It facilitates the fast adoption of novel VANET protocols which are regularly published in academic literature. Such protocols can be both VANET (geo)broadcasting schemes and IP-based networking protocols which are specifically optimized for the context of VANETs.
The example starts when the cooperative safety application running on the AU of ITS Station 1 generates a warning that has to be geographically broadcasted. It creates an UDP/IPv6 packet with its own IPv6 global unicast address (1:1:1:1::2) as source address. The destination address is constructed using the scheme presented in the “IPv6 geographical addressing scheme” section. To keep this example clear, the location of ITS Station 1 is defined as 0 degrees latitude and 0 degrees longitude. It is chosen to define a circular communication area (hence headings 1 and 2 are both 0×0), with a radius of 255 m (0xFF). The expiration time is 15 s (0xF). Hence, the destination address is FF16::FF:0:F. The UDP destination port of the packet is 1404. When this packet is transferred to the (standard) routing layer of the AU, it looks up the gateway for that packet, which is CCU 1, and forwards it to that CCU over the Ethernet interface. When CCU 1 receives this packet, its modified IPv6 routing layer recognizes this packet as a geo-broadcast IPv6 packet, and broadcasts it on the VANET 802.11p interface. This broadcasted packet is received by the CCU of ITS Station 2, which again recognizes it as a geo-broadcast packet. Based on its own location, it determines that it is positioned within the destination communication area. The CCU 2 networking stack multicasts a copy of the packet to every subnet within the ITS station. In this case, this is the Ethernet LAN. In the example, we use simplified IIDs, for the CCU 2 LAN interface this is ::1. Therefore, the multicast address for disseminating VANET packets on this LAN is FF32:FF::1:0:FF16. After delivery of a copy to all subnets, the packet is given to the VANET routing protocol for further relaying. The simple flooding of this example decides to rebroadcast the original packet through its VANET interface. This packet is then received by CCU 3. Based on its location, this CCU decides that it is outside of the destination area, and destroys the packet.
The above example focused on the geo-broadcasting aspect of the proposed VANET solution. However, support for the other required communication modes is quite similar. If AU 1 would have chosen to disseminate the message using topology broadcasting with a hop limit of 3, the difference would be that the destination address of the generated packet becomes FF16::1, as described in the “Interpretation of IPv6 header parameters” section. Then the packet is be given to CCU 1, which reduces the hop limit value with 1 (new value = 2) and then broadcasts it on the VANET interface. CCU 2 receives this packet, but performs no geographical filtering, it reduces the hop limit (new value = 1), forwards a copy to AU 2 and rebroadcasts the original on its VANET interface. This packet is then received by CCU 3, which will destroy the packet because any relay action by CCU 3 results in the value of hop limit becoming 0. In case of unicast traffic, the destination address of the packet becomes the global unicast address of the receiver. To support this form of communication, it is required that a unicast VANET ad hoc networking protocol is active on every CCU. This way, routes between the different CCUs are maintained. In the routing table of every AU, its CCU is configured as default gateway. This way, the created unicast packet will be forwarded by the (standard) routing layer of the AU to the CCU, which hands it over to the unicast ad hoc protocol which can deliver the packet of the VANET to the CCU which corresponds with the destination AU. This CCU will then forward the packet to the destination AU.
The approach to VANET networking presented in the previous sections was validated with an actual implementation. Two frameworks were applied: the Click Modular Router was used to implemented the networking stack, while the applications were developed in Java. The implementation of both the networking layer and the demonstrator applications could be performed within limited manpower constraints, while providing all required functionality. This illustrates the benefits of reducing the level of complexity in VANET design. In the next subsections, more details are given regarding both aspects of the implementation.
The starting point of our implementation was the configuration corresponding with a standard IPv6 router. As mentioned, all required elements and the corresponding configuration are part of the Click standard library. In our specific case, the router is connected to the Linux stack of the host, and three network interfaces: an intra-station Ethernet LAN and Wi-Fi WLAN, and the VANET IEEE 802.11p interface. To provide maximum control of all VANET transmission aspects, the VANET interface (which relies on the Madwifi wireless driver) was configured in a special mode called “monitor mode”. This mode requires the presence of some additional elements to perform error checks normally executed in the driver itself. Examples are the FilterPhyErr, FilterTx, and WifeDupeFilter elements.
Two adjustments were then made to the standard IPv6 router configuration. First of all, on the outgoing VANET interface, packets are classified according to their annotated QoS class and put in different queues. A priority scheduler is placed after them. As a result, every time that the VANET interface is ready to transmit a new packet, packets with the highest priority will be selected for transmission first. Only if the queue corresponding with the highest QoS class is empty, packets will be retrieved from the second highest QoS class queue. Only if that queue is also empty, packets can be retrieved from the third highest QoS class queue, and so on. The second adjustment was the introduction of a classifier in the forwarding chain of the router. If messages in the FF16::/16 domain pass this classifier, they do not flow into the standard lookup table of the router, but to the part on the right of the figure which provides all geo-networking functionality.
The entry point of this geo-networking implementation is the Geo dropper element. When it receives a packet, it investigates the IPv6 destination address of the packet. It also requests the current node location at the position info manager (an element that periodically polls the Linux daemon GPSD to retrieve the current position and GPS time). If the processed packet is a topology broadcast packet, it will forward it to the next element. If it is a geo-broadcast packet, it will checked if the current position of the node is part of the destination area. If so, the packet is passed to the next element, otherwise the packet is destroyed. The DTN dropper is the next element in the chain. It has a similar function as the Geo dropper element, but it focuses on time instead of location. It destroys expired geo-broadcast packets and forwards the other packets to the next element. This next element is a filter (based on the usage of a dedicated UDP port) for control messages of the Simplified Wireless Routing Protocol (SWRP). This protocol is a simplified version of the wireless routing protocol. It is a pro-active ad hoc routing protocol that exchanges routing tables between one-hop neighbors. It uses the topology broadcast address FF16::1 together with a hop limit of 1 to disseminate the routing table of a node to its peers. The SWRP element provides the core functionality of the protocol, it relies on other elements placed before and after it to add and remove network and transport headers and to assign highest priority to its messages.
Geo-networking packets not destined for the SWRP element are passed to the DecIP6HLIM element, which reduces the value in the IPv6 Hop Limit field by one. In contradiction to the similar element in the standard IPv6 section of the Click configuration, there is no connection to an element that sends ICMP6 error messages to the source network interface. On the VANET, such functionality would cause unnecessary capacity waste. The next element in the forwarding chain is the Simple flooder element. It maintains a list of all packets that it recently forwarded. As described in the “Interpretation of IPv6 header parameters” section, the triplet source address, destination address, and flow label are used to uniquely identify each packet. If the Simple flooder element receives a packet that is already included in its list, then the packet is destroyed. Else the corresponding ID is added to the list, and the packet is passed to the next element: the Multicast Tee. This element does nothing more then duplicating a message received on its input to all its outputs. This means that a copy of the geo-networking packet is forwarded to the Linux networking stack of the host, the intra-station LAN and WLAN, and the VANET interface. The check paint elements on the outgoing connections of the Multicast Tee make sure that the packet is not forwarded to the router input from which it originated (host, LAN, or WLAN). On the VANET interface such an inspection is not foreseen since in this context message relaying requires that packets can be forwarded on the same network interface as the one that they were received on. Before the packets are put in the outgoing queue of each network interface, the appropriate MAC headers are placed in front of the IPv6 geo-networking packet. This is carried out by the different multicast elements. In case of intra-station multicasting, the applied addresses correspond with the scheme described in the “Routing methodology” section. In case of VANET traffic, the destination MAC address always is the broadcast address FF:FF:FF:FF:FF:FF. On the VANET, a last check is also performed before handing the packet over to the VANET interface. The value of the Flow Label field is inspected, if no value has been set and the packet originated from this ITS station, the field is updated with the appropriate value.
The implementation of the networking layer was demonstrated on public roads with different common cooperative ITS applications: road works warning, emergency vehicle warning, bicycle collision alert, and broken down vehicle warning. For the interested reader, video footage of this demonstration can be found on YouTube. In the first application, a message was continuously broadcasted by a RSU which was temporary installed at a road works site. The onboard unit (OBU) of the demo vehicles received these messages and warned the driver when the hazardous location was approached. The emergency vehicle warning was an example of V2V communication, allowing the driver of the emergency vehicle to electronically notify the surrounding vehicles to give way. The bicycle collision alert demonstrated the value of ad hoc communication between vehicles and vulnerable road users. In case of limited visibility at a junction, the cooperative application warned the driver in case of a collision course with the bicycle. A similar use case was demonstrated with the last application: broken down vehicle warning. In this case the goal was again to inform the driver about hazards in case of limited visibility, but the communication pattern was V2V instead of vehicle-to-bicycle.
These applications were implemented in the regular Java SE Platform. No additional libraries were required except for one common Java class that can convert a desired geo-networking communication form into the corresponding IPv6 destination address. Such a class was straightforward to implement, and can be made publicly available if the need would arise from the VANET community. During application development, it was sufficient to configure the correct destination address, hop limit, and traffic class for a new packet based on the desired communication behavior. This can easily be done using the MulticastSocket class available in the Java SE SDK, in combination with the address generator introduced above. To illustrate this programming methodology, a coding example based on our own application code is shown below.//In this example, all required variables to define the communication behavior are//command line argumentsString myVanetAddress=args;String destinationVanetAddress=args; //unicast, FF16::1 or determined by the libraryint toPort=Integer.parseInt(args);int trafficClass=Integer.parseInt(args);int hopLimit=Integer.parseInt(args);//create the socketInetSocketAddress myAddress = new InetSocketAddress(myVanetAddress,0);MulticastSocket senderSocket = new MulticastSocket(myAddress);senderSocket.setTrafficClass(trafficClass);senderSocket.setTimeToLive(hopLimit);//create the messagetestMessage = new TestMessage(); //dummy object, implements the interface SerializableByteArrayOutputStream bos = new ByteArrayOutputStream();ObjectOutputStream oos = new ObjectOutputStream(bos);oos.writeObject(testMessage);//send the messageInetAddress toAddress = InetAddress.getByName (destinationVanetAddress);DatagramPacket msg = new DatagramPacket(bos.toByteArray(), bos. toByteArray().length, toAddress, toPort);senderSocket.send(msg);
The main goal of the VANET networking solution presented in this article is to fulfill all imposed requirements in a simple yet effective manner. In this section, it is evaluated to which degree this goal has been achieved.
In the “Communication requirements” section it was concluded that a VANET should support some form of unicasting, topology broadcasting, and geo-broadcasting. Since our solution supports IPv6 unicast, IPv6 topology broadcasting, and geo-broadcast using the standard IPv6 header, this indeed is the case. Another requirement was that the proposed solution should remain as close as possible to the IP stack, should limit the overhead and should not require modifications to the AUs. These requirements are also fulfilled. So, in theory, the solution presented in this article fulfills all imposed requirements. To justify this conclusion, an experiment was performed on the IBBT w-iLab.t wireless testbed. This experiment is presented in the “Experimental validation of the provided functionality” section.
Assuming that the support of all required functionality has been experimentally proven, it is still unclear how our solution holds up against the alternative VANET techniques introduced in the “VANET networking techniques” section. In almost all available publications processed in the corresponding literature study, no information was given about the practical details regarding the applied network header format, addressing scheme, and so on. In general, the publications focused on the defined routing or broadcasting schemes, assuming that a networking stack (being IP based or geographical networking based) is available to support their solutions. The main exceptions were all publications related to the GeoNet project. This project pioneered the domain of combined VANET solutions. During the course of the project, several publications focused on the different design and implementation issues, touching topics such as network headers, addressing schemes, and so on. No similar literature could be found anywhere else.
Since the work of the GeoNet project (which was executed between 2008 and 2010) was continued in the recently released ETSI standards, it seemed most appropriate to focus on these standards when evaluating our solution against the related state-of-the-art. Therefore, in the “Comparison with ETSI technical specification TS 102 636-4-1” and “Comparison with ETSI technical specification TS 102 636-6-1” sections our approach is compared with the corresponding ETSI standards for geographical networking and IPv6 encapsulation. To conclude the evaluation of our solution, the “Complexity analysis” section will focus on the bigger picture, evaluating the reduction in complexity of our solution compared to the tunneling approach.
Experimental validation of the provided functionality
Parameter values applied in the experimental functionality validation
Figure6 illustrates the reception of CAM messages. On the left part of the figure, every point corresponds with the tuple (sender node ID, receiver node ID). The color of the point indicates the percentage of CAM broadcast messages originating from the sender that were actually received by the receiver. It varies between blue (no communication possible) and red (perfect communication). On the diagonal the sender and receiver are the same. On this point the value corresponds with the number of messages that the node actually created during the experiment. This way it can easily be inspected if the request data load was generated during the experiment. If so, the entire diagonal should be dark red. It can be observed that for every sender node, the nodes that received the broadcasted CAM messages are situated around the diagonal. This corresponds with nodes that are in the vicinity of the sender. The diversity in the amount of receiver nodes per sender was nearly identical over several runs of the experiment, and can be explained by the fact that the w-iLab.t testbed is an indoor testbed. The nodes are spread around an entire floor of an office building. Due to the presence of obstacles with different propagation characteristics (wooden office partition walls, concrete elevator shaft, brick walls around kitchen, and toilets), communication properties of links can vary greatly based on the specific location of sender and receiver node. To indicate that the CAM messages were limited to single-hop communication, the right part of Figure6 depicts the average number of hops traveled before a CAM message was received. As desired, the value is 1 for all nodes. From the above, it can be concluded that the topology broadcast functionality is provided by our solution.
The left part of Figure7 illustrates the reception of the DENM and VOIP messages. The X-axis corresponds with the receiver node ID, the Y-axis with the PSR. Every series on the figure corresponds with a different sender node. So one series on the figure illustrates to which degree the messages created by a single source could be received by all other nodes. To avoid overloading the figure, only half of the DENM sources are depicted. When focusing on the DENM results, it should be mentioned that the length of the testbed grid topology is about 90 m. The destination address of the DENM applications where configured in such a way that they define a circular area around the position of the source node, with a radius of 45 m (see Table5). The source nodes 1–6 are all located at one end of the topology, close to each other. The used Hop Limit value is 255, allowing for multi-hop dissemination of the messages. As can be seen from Figure7, the desired communication characteristics are achieved: the DENM messages are only received by half of the nodes, corresponding with all nodes located within the geo-broadcast destination area. To indicate that the DENM messages were in fact relayed by intermediate nodes, the right part of Figure7 depicts the average number of hops traveled before a DENM message originating from node 1–6 was received. This value gradually increases from 1.2 to 3.4. When focusing on the VOIP results, again the desired behavior is observed on the left part of Figure7: only node 101 received the unicast messages sent out by node 99.
Comparison with ETSI technical specification TS 102 636-4-1
The comparison of the proposed solution with the ETSI TS 102 636-4-1 standard was approached both from a theoretical and an experimental point of view. In the following subsections both aspects are presented.
Theoretical comparison with TS 102 636-4-1
Differences between ETSI TS 102 636-4-1 and the approach presented in this article
ETSI TS 102 636-4-1
Vandenberghe et al.
Supported communication types
Unicast, topology broadcast, geo-broadcast
Unicast, topology broadcast, geo-broadcast
Number of packet header types
36–88 bytes, depending on type
Geographical information about network nodes
Latitude, longitude, speed, heading, altitude, accuracy indicators
Supported geo-broadcast area shape
Circle, rectangle, ellipse
Identification of network node
Station type + station subtype + station country + MAC derivative
Received global IPv6/48 prefix + MAC derivative
Requires GeoNetworking to IPv6 Adaption Sub-Layer (GN6ASL)
Another difference lies in the length of the header. In the ETSI solution, this varies between 36 and 88 bytes, while the IPv6 solution has a fixed header length of 40 bytes. Main reason for this difference lies in the fact that the ETSI header includes some more information than the IPv6-based proposition. Most of this information is included in the long position vectors for source and sender (the source is defined as the node that originates a packet, the sender as the node that has sent the packet, which will be different from the source during multi-hop forwarding). For both nodes, not only the coordinates but also speed, heading and altitude are always given, together with information regarding acquisition time and accuracy. In the proposed solution, no geographical information is given regarding source and sender nodes, since this is not required to provide all required communication forms. Similar to the remark regarding the location table, it can be stated that if an application needs to know location information regarding the source of a message, it is more convenient that the source application includes this information in the message payload. This approach is in line with the ETSI standards that describe message payload formats for cooperative applications (CAM and DENM). In both message types location information is included that describes the location of the event or source node. This information includes latitude and longitude, altitude, speed and heading.
This removal of redundant data leads to shorter header lengths, which is a valuable characteristic since VANETs can suffer from capacity problems under high vehicle densities[51, 52]. If we consider that the majority of cooperative ITS applications will rely on CAM and DENM messages to exchange information, it can be stated that the typical payload for a secure VANET packet will be 300 bytes. When taking the different header lengths into account (40 bytes IPv6, 36–88 bytes ETSI), it can be concluded that in case of the shortest ETSI header the medium occupation time for every message in our proposed solution is 1% longer than in the ETSI approach. However, in case of the longest ETSI header, the medium occupation time for of the ETSI approach becomes 14% longer than in our proposed solution. To evaluate the impact of this increase, an experiment using our implementation is presented in the “Experimental comparison with TS 102 636-4-1” section.
Some other small differences between the ETSI standard and the proposed solution can be observed. The shape of geo-broadcast areas is different: both techniques support the definition of circles, the ETSI standard also supports rectangles and ellipses, while the proposed solution also supports wedges. Both approaches allow the adequate definition of broadcast zones, and this difference can be classified as negligible. Regarding the unique identification of the network nodes, the ETSI standard combines station type, station subtype, country, and a unique identification derived from the MAC address. In the proposed solution, the unique global IPv6 unicast address is derived from the /48 prefix received from its operator or ISP (see “Automatic address assignment ” section), and an interface ID derived from the MAC address. The final difference between the ETSI standard and the proposed solution lies in the fact that the ETSI standard requires the GeoNetworking to IPv6 Adaption Sub-Layer (GN6ASL) for the communication of IPv6 packets over the VANET, while this is natively supported in the proposed solution. This is one of the most important differences in complexity between both solutions, and will therefore be more elaborated on in the “Comparison with ETSI technical specification TS 102 636-6-1” section.
It can be concluded that the ETSI technical specification TS 102 636-4-1, which describes a non-IP approach to geographical addressing and forwarding, and the solution proposed in this article are quite similar. They provide the same forms of communication towards the upper layers, but the proposed solution is characterized by a more straightforward header design. This design leads to a reduced complexity in packet processing. The consequence of this design is that less geographical information regarding events and neighboring nodes is available in the proposed solution compared to the ETSI standard. However, this information is not required at the networking layer since it is already available at the facility and application layers of the European ITS Communication Architecture. On the other hand, the removal of this redundant data could potentially improve network performance. This claim is experimentally investigated in the next section.
Experimental comparison with TS 102 636-4-1
In this section, we present an experiment that was designed to investigate the performance gain introduced by our solution. Compared to the ETSI standards, our packets are 4 bytes longer for CAM messages (single hop topology broadcast), but 44 bytes shorter for DENM messages (multi-hop geo-broadcast). This difference in size is the result of our specific header design and removal of unnecessary data redundancy. In the preceding section, it was mentioned that this is a valuable characteristic since VANETs can suffer from capacity problems under high vehicle densities. This experiment quantifies this statement.
Since the VANET scalability problem is only clearly noticeable in large networks, the experiment was not performed on the IBBT w-iLab.t testbed, but in the NS-2 network simulator. The same test application is used as the one described in the “Experimental validation of the provided functionality” section. To improve simulation accuracy, the overhauled PHY/MAC layer implementation (included in NS-2 since version 2.34) was applied. It introduces accumulative noise calculation during the entire packet transmission period. This greatly improves accuracy of the simulation in the context of the hidden node problem, one of the main drivers behind the VANET scalability issues. The simulated VANET interfaces were configured according to the IEEE 802.11p specifications. The simulation represents a 5-km long highway (6-lane) with a fixed average inter-vehicle distance. Three different distances were considered: 160 m (low traffic intensity), 80 m (normal traffic intensity), and 40 m (intense but flowing traffic). The experiment is divided in two simulations. The VANET solution presented in this article is deployed in both of them. In the first simulation, all CAM and DENM messages are 300 bytes long. In the second one the CAM messages are 296 bytes long and the DENM messages are 344 bytes long. All nodes create a CAM message every 100 ms, DENM messages are only created by the first six nodes occurring after the 1000-m mark. DENM generation interval is 100 ms, the destination area covers the entire simulated site.
The forwarding technique for geo-broadcasting is the same in both scenarios: opportunistic broadcasting. This technique expands the simple flooding technique (in which a node relays every unique packet once) with a mechanism to avoid redundant transmissions. As explained in the “Geographic networking” section, the probability that a node B will retransmit a broadcast message sent by node A is dependent of the distance between A and B: the greater the distance, the higher the probability that B will re-broadcast. This behavior is implemented by assigning different backoff times to the relaying nodes B. This time is proportional to the packet SNR value: the higher the SNR value, the longer the node has to wait before forwarding the packet. All chosen backoff times should have a value between 0 and 75 ms. If a node overhears the relaying of the message by another node during its own backoff time, it cancels its own forwarding of the packet. This approach results in a large geographical gain per message retransmission, while ensuring that in sparse networking conditions all neighbors get the opportunity to relay the message when necessary.
This distortion is the result of exceeding a critical channel congestion threshold when increasing the DENM message size with 44 bytes. As discussed by Ma and Chen, congested IEEE 802.11 ad hoc networks can suffer from a phenomenon called consecutive freeze process (CFP). This effect can be observed when a station that has just completed a transmission and that has a new packet to send chooses zero as its initial MAC backoff timer. It will start to transmit right after a DIFS, giving other stations no chances to back off. The impact of CFP is higher in case of broadcasting, leading to longer packet delays under network congestion. This longer delay causes more intermediate nodes to rebroadcast received DENM messages, since their backoff timer defined by the opportunistic forwarding scheme becomes empty before the nodes located further away get the opportunity to relay the message. This again leads to more load and hence congestion on the wireless channel, leading to longer CFP effects, leading to a further distortion of the opportunistic forwarding scheme, and so on.
To summarize, when comparing the solution presented in this article with the approach of the ETSI technical specification TS 102-636-4-1, no significant difference in performance could be observed in case of low and normal traffic intensity. However, in the case of intense (but flowing) traffic, a significant drop in DENM PSR and delay was noticed. After careful analysis, it could be concluded that this performance decrease is caused by the crossing of a critical network congestion threshold, activating a snowball effect that distorts the applied opportunistic forwarding scheme. To overcome this issue when applying the ETSI packet format, the DENM message generation rate has to be reduced from 10 to 6 Hz. Implementing additional VANET optimization techniques could be an alternative to overcome this issue without lowering the DENM generation rate, and will be investigated in future study.
Comparison with ETSI technical specification TS 102 636-6-1
Differences between ETSI TS 102 636-6-1 and the approach presented in this paper
ETSI TS 102 636-6-1
Vandenberghe et al.
Small adjustment to IPv6 stack
Changes to the IPv6 implementation
CCU: handover of FF16::/16 packets to VANET routing protocol
Reservation IPv6 prefix
Use of unassigned scope value 0×6 (allowed)
Management overhead on wireless medium
Creation and maintenance of GVL
Neighbor discovery address resolution (single hop)
It can be concluded that GN6ASL sub-layer and the VANET solution proposed in this article both provide all the required functionality to support the transmission of IPv6 packets over the VANET. No significant differences between both approaches could be identified, except the fact that our solution does not require the implementation of an entire sub-layer between the applied networking and transport layers.
It was shown in the previous sections that the solution presented in this article meets all imposed requirements. When compared to the most relevant state-of-the-art, it was concluded that our solution is quite similar to the alternatives, but our approach is considered to be less complex. This is important, since one of the main elements in this article is the adoption of the KISS principle. However, it is hard to quantify this characteristic objectively. If the focus would have been put on the comparison of specific algorithms, then asymptotic analysis techniques could be applied. If two different implementations of a single piece of software should be compared, cyclomatic complexity would be a suitable metric. However, the pure IPv6 solution presented in this article is a quite different networking paradigm than the alternative of communicating IPv6 packets as payload in a geographic network. They cannot be compared in terms of complexity based on any of the mentioned techniques. Hence, the complexity level of our solution cannot be experimentally determined. Therefore, to illustrate that the proposed solution indeed follows the KISS principle more closely, an elaborate argumentation is presented instead.
Implementations of the IPv6 networking stack are already available for many years. When it is assumed that the implementation of the geographic networking stack still has to be commenced by manufacturers of CCU nodes, our claim of reduced complexity is supported by the fact that our approach only needs a small adjustment to the available IPv6 stack. The alternative approach on the other hand requires the implementation of an entire geographic networking stack and of an additional sub-layer to be put between the stack and the transport layer.
However, although not as widespread as the IPv6 stack, some implementations of geonetworking protocols are already available (e.g., the CAR-2-X protocol stack implemented by NEC). When assuming that CCU manufacturers will build their products on top of such an existing geographical networking stack, at first sight it becomes less obvious that our solution still follows the KISS approach more closely. In this case, both approaches can start from an existing networking stack. In the solution presented in this article, an adjustment has to be made to the IPv6 stack of the CCU, while no changes are required to the available geographical networking stack in the alternative approach. On the other hand, the implementation of the GN6ASL sub-layer is required in the case of tunneling, which is not the case in our proposed solution. Based on this information, a clear distinction in terms of complexity cannot be made. However, when taking a closer look at the practical implications of the tunneling approach, it becomes clear that our approach is less complex than the tunneling approach.
As mentioned in the “Design requirements” section, no modifications may be required in the application units. This means that geographical networking will not be deployed on the AUs, and that except in the VANET itself, IPv6 will be applied (e.g., intra-station LAN and Internet backbone). Hence, in the case of geographical anycast or broadcast, some mechanism is required to allow these units and their applications to indicate to which geographical area their messages are targeted. The fundamental idea of our solution is that if you already provide such a mechanism, the KISS approach is to extend it to the VANET instead of translating it to another networking stack.
In our approach, a CCU can be implemented starting from the IPv6 networking stack in which only one adjustment has to be made: in case of forwarding packets in the FF16::/16 domain, packets have to be handed over to the geographic routing protocol instead of being processed by the standard IPv6 stack. This adjustment requires practically no implementation effort. In the case of the Click Modular Router platform that was used (see “Implementation details” section) this is only a matter of inserting one Classifier element which hands these packets over to the geographical routing protocols. In case a kernel space IPv6 stack in combination with user space geographic routing protocols (similar to CarGeo6), this is only a matter of connecting these protocols to a virtual interface and adding an entry to the routing table of the IPv6 router. This entry ensures that all FF16::/ traffic is forwarded to this virtual interface.
When implementing the tunneling approach, the required effort and complexity of the solution increases. At the starting point of the tunnel, some service is required that performs the translation between the IPv6 geographical annotation and the geonet destination. An example is the mechanism to configure GVLs as defined in ETSI TS 102 636-6-1, or the Geo-destination module of the CarGeo6 implementation presented by Toukabri et al.. The same publication also mentions that an IP Next Hop cache should be implemented, since in case of unicast traffic resolving the next IPv6 hop over the C2CNet leads to end-to-end performance degradation. As mentioned in the “Automatic address assignment ” section, such an additional element does not need to be implemented in our proposed solution. Since we rely on native IPv6 ad hoc protocols for unicast traffic, the next hop for a given destination will always be a node within transmission domain. Hence, we can rely on the standard IPv6 address resolution functionality. This will broadcast a single-hop neighbor solicitation message once on the VANET interface, when the first packet arrives for which the MAC address of the corresponding IP address is not yet known. A third element mentioned by Toukabri et al. is the fact that the Location Service mechanisms implemented at the C2CNet level causes high round-trip time and packet loss values in case of multi-hop tunneling of unicast traffic. It is suggested to implement a new multi-hop beaconing mechanism to counter this problem. Since our proposed solution does not require any Location Service mechanisms, it does also not require the implementation of such novel beaconing mechanisms.
In the above we compared the case where a geonetworking implementation is already available on the CCUs (and IPv6 tunneling has to be added) with the case where the standard IPv6 stack is available on the CCU (but should be modified to support the approach presented in this article). In both cases a mechanism has to be provided that allow IPv6 based applications to indicate the geographical area to which their multicast packets are addressed. In both cases, ad hoc routing and geo-broadcast protocols have to be provided on top of the used networking stacks to define the appropriate forwarding actions. Besides these common functionalities, the native IPv6 approach requires only the insertion of a filter in the standard IPv6 stack. However, in the case of tunneling the IPv6 packets as geonetworking data, this requires the implementation of a service to translate the IPv6 geographical annotation into the appropriate geonet destination, of an IP Next Hop Cache and of a new multi-hop beaconing mechanism to counter the introduced performance issues. Based on these observations, we conclude that the approach presented in this article more closely follows the KISS principle than the tunneling approach, even in the case that an existing geographical networking stack can be used as the starting point of the implementation.
In this article, an approach to VANET networking was presented that incorporates geographical data in the standard IPv6 header. Starting from an overview of possible networking techniques and the requirements imposed by the applications, it was shown that in a simple yet effective manner, a VANET networking solution can be constructed that is entirely based on IPv6 and supports all required communication forms and design requisites.
The strength of our approach is that it is based on a simpler design compared to the VANET approach which combines IPv6 and geographic networking solutions (as for instance adopted by ETSI). First of all there is no need to provide a non-IP geographic networking stack. Such a stack does not only define specific addressing mechanisms based on node location, it also requires additional functionality such as a position service. Only a few implementations of such networking stacks exist. Instead, our solution relies on the standard IPv6 stack, which is widely available for years now. Our solution also does not require additional protocol translation mechanisms for tunneling, nor required performance optimizations as identified during practical implementations of the combined approach. Such a reduction in complexity makes it easier to implement, debug en maintain (future) VANET networking stacks. The presented packet header is also more straightforward than in the corresponding ETSI standard. This leads not only to a reduction in processing complexity at the network layer, but also to a performance improvement in terms of PSR and latency for multi-hop broadcast messages.
The downside of our solution is that the combined approach has already gained quite a lot of momentum. Significant implementation efforts were made in the GeoNet project. Since then, these results have been standardized by ETSI and are made publicly available by the CarGeo6 open-source implementation. The solution presented in this article on the other hand has only been taken up by ourselves until now. Applying this work would require stepping back to a clean-slate implementation of the VANET networking stack. Although the straightforward design of our solution results in a manageable implementation effort, it seems unfeasible to expect that all extensive VANET standardization and implementation efforts of the past will be entirely abandoned. However, the goal of this publication is to introduce the concepts that allowed us to provide all required functionality while rigorously striving to follow the KISS principle. Ideally, this would inspire the VANET community to evaluate these concepts critically, and possible apply them in future iterations of VANET standards and mainstream implementations.
- Raymond ES: The Art of Unix programming. Boston: Addison-Wesley Professional; 2003.Google Scholar
- Carpenter (ed.) B: Architectural principles of the Internet. 1996.View ArticleGoogle Scholar
- Vandenberghe W, Carels D, Moerman I, Demeester P, Van de Velde E, Bergs J, Blondia C: VANET addressing scheme incorporating geographical information in standard IPV6 header. In Proceedings of the 10th international conference on ITS telecommunications (ITST),. Kyoto, Japan; 2010:1-6.Google Scholar
- ETSI ITS Working Group 3: Intelligent Transport Systems (ITS); Vehicular Communications; GeoNetworking; Part 4: Geographical addressing and forwarding for point-to-point and point-to-multipoint communications; Sub-part 1: Media independent functionalities. 2011.Google Scholar
- ETSI ITS Working Group 3: Intelligent Transport Systems (ITS); Vehicular Communications; GeoNetworking; Part 6: Internet Integration; Sub-part 1: Transmission of IPv6 Packets over GeoNetworking Protocols. 2011.Google Scholar
- Choi J, Khaled Y, Tsukada M, Ernst T: IPv6 support for VANET with geographical routing. In Proceedings of the 8th international conference on ITS telecommunications (ITST),. Phuket, Thailand; 2008:222-227.Google Scholar
- Ernst T: Why IPv6 Geonetworking is needed for ITS? Presentation given at GeoNet final workshop. 2010.http://www.geonet-project.eu/?download=GeoNet-IPv6_for_ITS.pdf Paris,. . Accessed 1 August 2011Google Scholar
- Huston G: IPv4 Address Report. 2011.http://www.potaroo.net/tools/ipv4/index.html . Accessed 2 AugustGoogle Scholar
- Namboodiri V, Gao L: Prediction-based routing for vehicular ad hoc networks. IEEE Trans. Veh. Technol 2007, 56(4):2332-2345.View ArticleGoogle Scholar
- Taleb T, Sakhaee E, Jamalipour A, Hashimoto K, Kato N, Nemoto Y: A stable routing protocol to support ITS services in VANET networks. IEEE Trans. Veh. Technol 2007, 56(6):3337-3347.View ArticleGoogle Scholar
- Ko Y-B, Vaidya NH: Location-aided routing (LAR) in mobile ad hoc networks. Wirel. Netw 2000, 6(4):307-321. 10.1023/A:1019106118419View ArticleGoogle Scholar
- Wang W, Xie F, Chatterjee M: Small-scale and large-scale routing in vehicular ad hoc networks. IEEE Trans. Veh. Technol 2009, 58(9):5200-5213.View ArticleGoogle Scholar
- Menouar H, Lenardi M, Filali F: Improving proactive routing in VANETs with the MOPR movement prediction framework. In Proceedings of the 7th International Conference on ITS Telecommunications (ITST),. Sophia Antipolis, France; 2007:1-6.Google Scholar
- Baccelli E, Schiller J: Towards scalable MANETs. In Proceedings of the 8th International Conference on ITS Telecommunications (ITST),. Phuket, Thailand; 2008:133-138.Google Scholar
- Giannuolis S, Katsanos C, Koubias S, Papadopoulos G: A hybrid adaptive routing protocol for ad hoc wireless networks. In Proceedings of the IEEE International Workshop on Factory Communication Systems (WCFS),. Vienna, Austria; 2004:287-290.Google Scholar
- Ramasubramanian V, Haas ZJ, Sirer EG: SHARP: a hybrid adaptive routing protocol for mobile ad hoc networks. In Proceedings of the Fourth ACM International Symposium on Mobile Ad Hoc Networking and Computing (MobiHoc),. Annapolis, USA; 2003:303-314.View ArticleGoogle Scholar
- IEEE Vehicular Technology Society: IEEE standard for wireless access in vehicular environments (WAVE)—networking services. 2010.Google Scholar
- International Organization for Standardization: Intelligent Transport Systems—Communications access for land mobiles (CALM)—Non-IP networking. 2009.Google Scholar
- Mariyasagayam N, Menouar H, Lenardi M: An adaptive forwarding mechanism for data dissemination in vehicular networks. In Proceedings of the Vehicular Networking Conference (VNC),. Tokyo, Japan; 2009:1-5.Google Scholar
- Laouiti A, Mühlethaler P, Toor Y: Reliable opportunistic broadcast VANETs (R-OB-VAN). In Proceedings of the 9th International Conference on ITS Telecommunications (ITST),. Lille, France; 2009:382-387.Google Scholar
- Torrent-Moreno M: Inter-vehicle communications: assessing information dissemination under safety constraints. In Proceedings of the 4th Annual IEEE/IFIP Conference on Wireless On Demand Network Systems and Services (WONS),. Obergurgl, Austria; 2007:59-64.Google Scholar
- Busanelli S, Ferrari G, Panichpapiboon S: Efficient broadcasting in IEEE 802.11 networks through irresponsible forwarding. In Proceedings of the Global Communications Conference (Globecom),. Hawaii, USA; 2009:1-6.Google Scholar
- Ibrahim K, Weigle MC, Abuelela M: p-IVG: probabilistic inter-vehicle geocast for dense vehicular networks. In Proceedings of the IEEE 69th Vehicular Technology Conference (VTC),. Barcelona, Spain; 2009:1-5.Google Scholar
- Tonguz OK, Wisitpongphan N, Bai F: DV-CAST: a distributed vehicular broadcast protocol for vehicular ad hoc networks. IEEE Wirel. Commun 2010, 17(2):47-56.View ArticleGoogle Scholar
- Rao SA, Pai M, Boussedjra M, Mouzna J: GPSR-L: greedy perimeter stateless routing with lifetime for VANETs. In Proceedings of the 8th International Conference on ITS Telecommunications (ITST),. Phuket, Thailand; 2008:299-304.Google Scholar
- Zhang M, Wolff RS: Routing protocols for vehicular ad hoc networks in rural areas. IEEE Commun. Mag 2008, 46(11):126-131.View ArticleGoogle Scholar
- Festag A, Baldessari R, Wang H: On power-aware greedy forwarding in highway scenarios. In Proceedings of the 5th International Workshop in Intelligent Transportation (WIT),. Hamburg, Germany; 2007:1-6.Google Scholar
- Korkmaz G, Eikici E, Ozgüner F: Black-burst-based multihop broadcast protocols for vehicular networks. IEEE Trans. Veh. Technol 2007, 56(5):3159-3167.View ArticleGoogle Scholar
- Zhao J, Cao G: VADD: vehicle-assited data delivery in vehicular ad hoc networks. IEEE Trans. Veh. Technol 2008, 57(3):1910-1922.MathSciNetView ArticleGoogle Scholar
- Ding Y, Xiao L: SADV: static-node-assisted adaptive data dissemination in vehicular networks. IEEE Trans. Veh. Technol 2010, 59(5):2445-2455.View ArticleGoogle Scholar
- Kovacs (ed.) A: D2.2 Final GeoNet Specification. 2010.http://www.geonet-project.eu Deliverable of the project GeoNet STREP No. 216269, . Accessed 5 August 2011Google Scholar
- Jemaa IB, Tsukada M, Menouar H, Ernst T: Validation and evaluation of, NEMO in VANET using geographic routing. In Proceedings of the 10th International Conference on ITS Telecommunications (ITST),. Kyoto, Japan; 2010:1-6.Google Scholar
- Toukabri T, Tsukada M, Ernst T, Bettaieb L: Experimental evaluation of an open source implementation of, IPv6 GeoNetworking in VANETs. In Proceedings of the 11th International Conference on ITS Telecommunications (ITST),. Saint-Petersburg, Russia; 2011:237-245.Google Scholar
- CAR-2-CAR Communication Consortium: CAR 2 CAR Communication Consortium Manifesto. 2007.Google Scholar
- ETSI ITS Working Group 1: Intelligent Transport Systems; Vehicular Communications; Basic set of applications; Definitions. 2009.Google Scholar
- ETSI ITS Working Group 1: Intelligent Transport Systems; Vehicular Communications; Basic Set of Applications; Part 2: Specification of Cooperative Awareness Basic Service. 2010.Google Scholar
- ETSI ITS Working Group 1: Intelligent Transport Systems; Vehicular Communications; Basic Set of Applications; Part 2: Specification of Decentralized Environment Notification Basic Service. 2010.Google Scholar
- Bechler (ed.) M: European ITS Communication Architecture; Overal Framework; Proof of Concept Implementation. 2010.http://www.comesafety.org Deliverable DEL31 of the COMeSafety project, . Accessed 4 July 2011Google Scholar
- Gordillo A, Calderon M, Bernardos CJ: Enabling, IP geomulticast services for vehicular networks. In Proceedings of the 9th international conference on ITS telecommunications (ITST),. Lille, France; 2009:292-297.Google Scholar
- Thomson S, Narten T, Jinmei T: IPv6 stateless address autoconfiguration. 2007.View ArticleGoogle Scholar
- Internet Architecture Board InternetEngineeringSteeringGroup: IAB/IESG recommendations on IPv6 address allocations to sites. 2001.Google Scholar
- Hinden R, Deering S: IP Version 6 Addressing Architecture. 2006.View ArticleGoogle Scholar
- Khaled Y, Tsukada M, Ernst T: Geographical information extension for, IPv6: application to VANET. In Proceedings of the 9th international conference on ITS telecommunications (ITST),. Lille, France; 2009:304-308.Google Scholar
- Khaled Y, Jemaa IB, Tsukada M, Ernst T: Application of, IPv6 multicast to VANET. In Proceedings of the 9th international conference on ITS telecommunications (ITST),. Lille, France; 2009:198-202.Google Scholar
- Park J-S, Shin M-K, Kim H-J: A method for generating link-scoped IPv6 multicast addresses. 2006.Google Scholar
- Kohler E: The Click modular router. PhD thesis, Massachusetts Institute of TechnologyGoogle Scholar
- Murthy S, Garcia-Luna-Aceves J: An efficient routing protocol for wireless networks. Mob. Netw. Appl 1996, 1(2):183-197. 10.1007/BF01193336View ArticleGoogle Scholar
- IBBT NextGenITS Demo—Cooperative Systems http://www.youtube.com/watch?v=cSP9xlTDY3o&fmt=22
- Vandenberghe W, Moerman I, Demeester P, Cappelle H: Suitability of the wireless testbed w-iLab.t for VANET research. In Proceedings of the 18th IEEE symposium on communications and vehicular technology in the Benelux (SCVT),. Gent, Belgium; 2011:1-6.Google Scholar
- Cano M-D, Cerdan F: Subjective QoE analysis of VoIP applications in a wireless campus environment. Telecommun. Syst 2012, 49(1):5-15. 10.1007/s11235-010-9348-5View ArticleGoogle Scholar
- Eichler S: Performance evaluation of the IEEE 802.11p WAVE communication standard. In Proceedings of the 66th IEEE Conference on Vehicular Technology (VTC-2007),. Baltimore, USA; 2007:2199-2203.View ArticleGoogle Scholar
- Wisitpongphan N, Tonguz OK, Parikh JS, Mudalige P, Bai F, Sadekar V: Broadcast storm mitigation techniques in vehicular ad hoc networks. IEEE Wirel. Commun 2007, 14(6):84-94.View ArticleGoogle Scholar
- Chen Q, Schmidt-Eisenlohr F, Jiang D, Torrent-Moreno M, Delgrossi L, Hartenstein H: Overhaul of IEEE 802.11 modeling and simulation in NS-2. In Proceedings of the 10th ACM Symposium on Modeling, analysis, and simulation of wireless and mobile systems (MSWiM),. Chania, Greece; 2007:159-168.View ArticleGoogle Scholar
- Ma X, Chen X: Performance analysis of IEEE 802.11 broadcast scheme in Ad Hoc Wireless LANs. IEEE Trans. Veh. Technol 2008, 57(6):3757-3768.View ArticleGoogle Scholar
- Festag A, Baldessari R, Zhang W, Le L: CAR-2-X communication SDK—a software toolkit for rapid application development and experimentations. In Proceedings of the IEEE Vehicular Networking and Applications Workshop - Future Wireless Technologies for Vehicle Infrastructure Integration (VII) Applications (VehiMobil 2009),. Dresden, Germany; 2009:1-5.Google Scholar
This article is published under license to BioMed Central Ltd. This is an Open Access article distributed under the terms of the Creative Commons Attribution License (http://creativecommons.org/licenses/by/2.0), which permits unrestricted use, distribution, and reproduction in any medium, provided the original work is properly cited.