A Comparison of Backbone and Mesh Clustering Strategies for Collaborative Management of 6G Vehicle-to-Vehicle Exchanges

Abstract

Sixth-generation (6G) announcements promise the best performance not only for latency but also for the number of connected objects. These characteristics particularly suit intelligent transport system (ITS) applications involving a large number of moving vehicles with stringent latency constraints. Moreover, in the 6G era, these applications will often operate while relying on direct cooperation and exchanges between vehicles, in addition to centralized services through a telecommunication infrastructure. Therefore, addressing collaborative intelligence for ad hoc routing protocols that ensure efficient management of multihop vehicle-to-vehicle communications is mandatory. Among the numerous organization models proposed in the literature, the chain–branch–leaf (CBL), a virtual backbone-like model, has demonstrated best performance regarding latency against the state-of-the-art approaches. However, its structure, which lacks redundancy, may lead to higher data loss in the case of the failure of one of the relaying branch nodes. This study investigated how the multipoint relay (MPR) technique—which is intrinsically redundant—used in the optimized link state routing (OLSR) protocol can be efficiently adapted to the road traffic context, especially by restricting MPR selection to a single traffic flow direction (TFD-OLSR). The simulation results confirmed that CBL-OLSR obtains the least end-to-end delay for various types of application traffic due to its efficient reduction in the number of relays and the amount of routing traffic. However, despite higher routing traffic, TFD-OLSR improves the delivery rate, especially for more than two-hop communications, thus demonstrating the benefits of its redundancy property.

1. Introduction

Intelligent transport systems (ITSs) aim to reduce the number of accidents and deaths occurring on the roads every year. Such systems are advanced driver-assistance systems or autonomous vehicles equipped with sensors and actuators owing to which they can sense their environment and react accordingly. Communication networks are being studied as a way to propagate events between vehicle and roadside units (RSUs) and to support security or comfort applications. Sample applications include cooperative collision avoidance, platooning, and video streaming. Machine-to-machine (M2M) communications, in the form of vehicle-to-vehicle (V2V) and vehicle-to-infrastructure (V2I), grouped under the term vehicular ad hoc networks (VANETs), will benefit from 6G [1] to allow lower latencies and massively connected vehicles. The communication technologies envisioned for the future deployment of 6G, especially in ITSs, are still under development. Related reviews can be found in [2,3]. In this study, we focused on current technologies and used them to evaluate proposed clustering strategies for these future communications. Researchers and industry have been working toward standardizing vehicular communication technologies supporting dedicated short-range communication (DSRC) [4] such as IEEE 802.11p [5] and IEEE 802.11bd [6]. However, these technological solutions need to be supplemented with organizational models adapted to vehicle communication constraints.

Indeed, vehicles can move freely along the road at various speeds, which causes frequent link failures and bandwidth degradation. In this context, the provision of quality of service (QoS) applications is expected to be challenging [7]. This has been an open research question, leading to the design of numerous network protocols on every layer of the Open Systems Interconnection (OSI) model. This study entirely focused on routing at the network layer, which is mainly in charge of routing and addressing functions.

Several protocols for the network layer have been proposed in the literature to try to overcome network connectivity problems. One of the main approaches is clustering [8], for which nodes gather in virtual groups, thus allowing network functions such as routing [9] or transmission scheduling [10] to be centralized to an extent and reducing routing traffic overhead. This study assumed that the numerous clustering strategies [11] proposed in the literature can actually be divided into two groups:

• Clustering strategies that lead to the formation of single-headed clusters connected through a backbone. The chain–branch–leaf (CBL) [12] clustering scheme is based on such a strategy.
• Clustering strategies that consist, for each node, of selecting several relays in order to reach their k-hop neighborhood, thus leading to a mesh network that covers every single node through several relays. The multipoint relaying (MPR) [13] technique is part of this group.

Recent evaluations [14] showed that CBL—a backbone-like clustering scheme—outperforms most ad hoc routing protocols from the different approaches, namely, a reactive one such as the ad hoc on-demand distance vector (AODV) protocol, a proactive one such as the optimized link state routing (OLSR) [15] protocol, and a geographic one such as the geographic routing protocol (GRP). In addition to considerably reducing routing traffic overhead, the results showed that CBL achieves the lowest latency. However, the same work underlined that the single-headed clusters in CBL lead to a backbone structure that lacks redundancy, thus impeding alternative routes for V2V multihop communications in the case of link failure. The researchers also pointed out that CBL performance partly comes from its strategy, which consists of organizing V2V multihop communications per road traffic direction. These observations suggest that the OLSR protocol, which resorts to the intrinsically redundant MPR technique, could achieve a better delivery ratio than CBL thanks to its redundant MPRs if it was modified so as to organize V2V multihop communications per traffic flow direction. Therefore, this study aimed to evaluate whether redundancy achieved through MPRs in the resulting structure of OLSR is preferable to a backbone-like clustering solution such as CBL in the context of multihop V2V communications. This was achieved by evaluating both solutions as part of one-way traffic scenarios. In particular, the impact of the chosen strategy on packet delivery ratio and latency was studied.

The rest of this paper is organized as follows: First, the related work concerning clustering strategies and redundancy is reviewed in Section 2. Then, vehicle network and mobility scenarios as well as the evaluated protocols are presented in Section 3, along with the description of the simulation scenarios. The results are compared and analyzed in Section 4, before our conclusions and the perspectives on our future work are provided, in Section 5.

2. Related Work

Routing packets in a vehicular ad hoc network is a task that can be formalized as routing in an undirected graph, in which graph nodes are stations, and edges are virtual communication links between two stations. In static ad hoc networks, network architectures are defined by minimizing the number of nodes relaying application data traffic. One approach consists of computing a network backbone, a minimal set of nodes and links required to enable communications between any couple of nodes in the network. In graph theory, two problems are analogous: the identification of a spanning tree [16] and that of a connected dominating set (CDS) [17].

In mobile ad hoc networks (MANETs), network protocols need to dynamically update changes in the network topology in a distributed manner [18], with each wireless station having its own local view of the rest of the network. In a centralized approach, network changes need to be propagated toward a central node, which compute routing tables and send them back to every node. However, this could quickly become impossible due to the network splitting resulting from link failures, notably because of nodes becoming too far from each other to exchange information. In a perfect environment with no time constraints, in which all nodes are static and able to transmit all packets without any failure, the optimal CDS structure could be an efficient and viable centralized solution. However, the mobility observed in VANETs causes links to be short-lived, thus leading the network graph to be highly dynamic. The lack of redundancy of the minimal CDS structure can create bottlenecks at crossing nodes, which cannot be circumvented to forward packets throughout the network. Such crossing nodes then become points of failure when node mobility creates the risk of link failure.

Both the time-critical and time-constrained communications usually encountered in VANETs have a maximum validity period beyond which the shared information is stale. If a path to a node is lost, the route must be recomputed, resulting in transmission delays. In multihop communications, such delays can happen at every node relaying packets, adding up to and exceeding the applications’ time requirements. One solution to improve network resiliency is structural redundancy: multiple (joined or disjoined) paths exist to reach the destination, thus mitigating the impact of one link’s failure on the delivery of the transmitted packets.

Concerning the OLSR protocol [15], a global CDS is computed in a decentralized way, with every node computing a dominating set (DS) to cover its two-hop neighborhood. By means of periodical HELLO messages (i.e., beacons) broadcast and received, any node running OLSR can be sensed by its one-hop neighbors and discover them. Each HELLO message contains the IP identifier of its source node and the link state to the one-hop neighbors it has detected, thus enabling any receiving node to update its local perception of both its one-hop neighbors and the two-hop neighbors that it can reach through the HELLO originator (Figure 1a). After updating its table of one- and two-hop neighbors, an OLSR node then computes an optimal set of its one-hop neighbors, which are called multipoint relays (Figure 1b), so as to cover all of its two-hop neighbors. Next, every MPR node broadcasts, throughout the network, information about its links with the nodes that selected it (its selectors) through a topology control (TC) message. In order to optimize the flooding of such broadcast messages, the OLSR protocol only allows MPR nodes to forward TC messages, which reduces control packet overhead compared to blind flooding. By using only the links between MPR nodes and their selectors for packet routing, OLSR creates a mesh network, which is actually a CDS composed of all MPR nodes in the VANET (Figure 1c). Each node can select multiple MPRs and be selected as the MPR by several other nodes, thus leading to the accumulation of MPR coverage areas and the availability of multiple paths.

Such redundancy is not observed in backbone-like clustering schemes. In these, no node can be part of two clusters at the same time. Precisely, chain–branch–leaf [14] is a clustering scheme designed for VANETs, which specifies the roles the CBL nodes can endorse in order to create a virtual communication infrastructure. Each cluster member (leaf node) elects its cluster head (branch node), and the latter serves as the gateway nodes to connect the clusters. CBL nodes rely on two metrics to select branch nodes: connection time and chain time, both computed from mobility information such as position, speed, and steering angle. The nodes that remain close together and whose relative speed and steering angle difference are low are favored, which leads to covering each direction of travel with an independent backbone, as shown in Figure 2. The resulting structure of CBL connects each cluster in a linear way, forming what is called a “chain”. Simulations have shown that managing vehicle-to-vehicle communications with CBL results in stable clusters and chains in medium- and high-density highway scenarios [14]. Its functioning only depends on the periodic sharing of node state through HELLO messages, which encouraged the authors to implement it into the OLSR protocol (CBL-OLSR). Previous simulations comparing its performance to that of other popular protocols in the literature, namely, OLSR, ad hoc on-demand distance vector (AODV) [19] and the geographic routing protocol (GRP) [20], showed its superiority in terms of end-to-end packet delay and routing traffic overhead [14]. However, the evaluations did not consider the case where a mesh-like clustering scheme such as MPR would operate only using road traffic direction.

In low-mobility MANETs (up to 10 m/s), the authors of [21] showed that an OLSR-based clustering approach, even with overlapping clusters, can help reduce end-to-end delay and routing traffic overhead. The authors did not conduct any comparison with a backbone-like clustering scheme.

Other papers focus on cluster stability metrics (such as cluster duration or number of cluster head changes). In [22], the authors propose a clustering algorithm with two cluster heads: one main cluster head is active; the second is passive and takes over the main cluster head when the connection is lost. This mechanism also integrates cluster merging. Assessed via simulation for a medium- to high-speed VANET, it was shown to reduce the number of clusters in the network and increase their lifetime as well as routing traffic overhead. However, the results do not state its performance regarding end-to-end delay and packet delivery ratio for application traffic, and the authors did not conduct any comparison with a mesh-like clustering solution.

Other authors [23] used the angle between vehicle velocity vectors and the speed limit on the road in order to cluster nodes. The protocol was evaluated against other clustering protocols in the literature regarding cluster lifetime and number of cluster head changes. Their angle-based clustering algorithm (ACA) approach is shown to perform better in highway scenarios regarding both stability metrics. However, they did not analyze its performance regarding the end-to-end delay of application traffic and packet delivery ratio.

In [24], the authors reduced the total number of MPR nodes. Network nodes called “cooperative nodes” execute a modified version of the OLSR. By exploiting adjacent nodes’ MPR information to select already-elected MPRs, routing traffic overhead is reduced by 15% in static scenarios and from 8 to 14% in mobile scenarios. However, the authors did not analyze the performance regarding end-to-end delay or packet delivery ratio of application traffic, and they did not conduct any comparison with a backbone-like clustering approach.

A recent work [25] focused on clustering performance for application traffic proposes interesting results regarding end-to-end delay and packet delivery ratio up to seven hops. However, the authors did not particularly investigate the contribution of the clustering strategy to the observed performance.

3. Comparison of Backbone-like and Mesh-like Clustering Strategies

A recent book [26] outlines a detailed analysis of clustering strategies for vehicular ad hoc networks, mainly regarding their routing performance in comparison with other nonclustering routing approaches. In this study, we focused on the comparison of backbone-like and mesh-like clustering regarding the performance they offer to application traffic in various VANET scenarios.

CBL scheme implemented in OLSR (CBL-OLSR) was chosen as the backbone-like clustering protocol since it has already demonstrated its performance in comparison with other routing protocols and because it already works in one road-traffic direction. In order to represent mesh-like clustering, we applied to the multipoint relaying technique used in OLSR. In order to offer an accurate comparison, we propose providing both protocols representing one of the different approaches with the same conditions regarding network nodes and road traffic conditions. Thus, OLSR was adapted to obtain OLSR with one traffic flow direction (TFD-OLSR) in order to benefit from the same evaluation conditions than CBL-OLSR, concretely, to be evaluated for only one traffic direction at a time.

3.1. Presentation of TFD-OLSR

TFD-OLSR was developedx by restricting the operation of OLSR so that each node selects its MPRs from the nodes traveling in the same traffic direction as itself. Using the position and direction information, a TFD-OLSR node notes the fact that a neighbor is moving on the same road and in the same direction. Two vehicles are considered as being in the same traffic flow direction if the difference between their steering angle is inferior to 120 degrees.

Figure 3 presents the flow chart of the algorithm before selecting the MPRs. New direction information is added to HELLO messages that specifies a. the position of the source node; b. a flag added to the “advertised neighbors” fields to indicate whether these neighbors move in the same direction. Using this information, TFD-OLSR filters the OLSR local topology, then computes, at the node level, the MPR set on a subgraph that contains both 1-hop nodes traveling in the same direction and those of its 1-hop nodes.

3.2. Modeling Parameters and Scenario Definition

The comparisons of TFD-OLSR and CBL-OLSR were performed using the OPNET Riverbed Modeler simulator, which provides basic models for every network component. The next paragraphs first present the wireless communication nodes and their parameters, then the mobility scenarios, and finally the three simulated application traffic models. The most important parameters are summarized in Table 1, Table 2 and Table 3.

3.2.1. Wireless Node Model

The OPNET Riverbed Modeler node models used are WLAN (Wireless Local Area Network) workstation, with 802.11p interface as the radio technology, and OLSR-based protocol (TFD-OLSR or CBL-OLSR) as the routing protocol above the UDP/IP stack. Each one of the routing protocols TFD-OLSR and CBL-OLSR have been implemented in a copy of the native OLSR code provided by Riverbed Modeler. An identical configuration of 802.11p interfaces and OLSR parameters has been adopted for TFD-OLSR and CBL-OLSR nodes. These parameters are reported into Table 1. According to OPNET modeler, WLAN parameters will result in a communication range of 500 m between any pair of vehicles in the road traffic.

Table 1. WLAN and OLSR parameters.

WLAN Parameters		OLSR Parameters
Parameter	Value	Parameter	Value
Standard	802.11p	Hello Interval	1 s
Transmission Frequency	5 GHz	TC Interval	2.5 s
Data rate	13 Mbps	Neighbor Hold Time	3.0 s
Receiver sensitivity	−95 dBm	Topology Hold Time	7.5 s
		Duplicate Message Hold Time	15 s

Table 1. WLAN and OLSR parameters.

WLAN Parameters		OLSR Parameters
Parameter	Value	Parameter	Value
Standard	802.11p	Hello Interval	1 s
Transmission Frequency	5 GHz	TC Interval	2.5 s
Data rate	13 Mbps	Neighbor Hold Time	3.0 s
Receiver sensitivity	−95 dBm	Topology Hold Time	7.5 s
		Duplicate Message Hold Time	15 s

3.2.2. Mobility Scenarios

The mobility scenarios used were designed for previous work with the Simulator of Urban Mobility (SUMO), and SUMO traces were ported to the OPNET Riverbed Modeler trajectory format [26]. SUMO traces were generated for medium (S2) and high (S3) road density scenarios (Table 2) on a straight, three-lane, one-way road, 5 km in length, with no junctions; with maximum vehicle speeds in compliance with the French freeway legislation, being 130 km/h for cars and 110 km/h for light trucks; and a speed distribution in which 95% of the vehicles drive at a speed ranging from 80% to 120% of the legal speed limit. Freeway scenarios were chosen because the CBL scheme was designed to meet the needs of highway safety applications. One-way road traffic scenarios were chosen to isolate a single traffic direction.

Table 2. Mobility scenarios parameters in SUMO.

Scenario	Car Traffic (veh/h/Direction)	Truck Traffic (veh/h/Direction)
S2	2000	400
S3	4000	800

Table 2. Mobility scenarios parameters in SUMO.

Scenario	Car Traffic (veh/h/Direction)	Truck Traffic (veh/h/Direction)
S2	2000	400
S3	4000	800

Figure 4 shows the average number of vehicles for S2 (Figure 4a) and S3 (Figure 4b) scenarios. As the number of vehicles on the road section increased gradually over the first 150 s, metrics were only measured after this time elapsed, when both the number of vehicles and VANET routing traffic stabilized, so that simulation results (Section 4) were obtained in conditions that were representative of road densities S2 and S3.

3.2.3. Application Traffic Models

Three applications were modeled in order to evaluate both protocols, which were chosen to allow representing any kind of vehicular application traffic.

Bidirectional Videoconference Application—${\mathrm{A}}_{Vd}\mathrm{B}\mathrm{I}$

Using the OPNET application definition module, a videoconference application using UDP was deployed between two nodes for which the distance in IP hops is known and constant when the application is active. The application initiator node first sends a control packet to the destination, which replies with another control packet. Upon reception, both nodes exchange a stream of application packets of constant format during 50 s and explicitly close the transmission with a control packet. Application packets are 6000 bytes long and are transmitted at the rate of 10 packets per second. Such application can be used to model any vehicular application that involves an explicit start of exchanges, and where the two nodes send each other the same amount of data subject to delivery rate, end-to-end delay, and jitter constraints. It could be used in a platooning application in which each vehicle gives access to what it senses through its camera and microphone sensors to the other members of the platoon.

Monodirectional Videoconference Application—${\mathrm{A}}_{Vd}\mathrm{M}\mathrm{O}$

The videoconference application is now monodirectional: a single node sends a stream of application packets to the other node. In order to maintain the same level of traffic load, the stream carries twice as many bytes in application packets (12,000 bytes long). For exactly the same distance in IP hops and road scenario, the source and destination nodes are the same as those chosen for the ${\mathrm{A}}_{Vd}\mathrm{B}\mathrm{I}$ application, as are the application start time and duration. Such application can be used to model an application in which a remotely controlled vehicle sends live data from its camera and microphone sensors to a controller vehicle.

Monodirectional Packet Stream Application—${\mathrm{A}}_{St}\mathrm{M}\mathrm{O}$

Using the OPNET application demand module, a stream of packets is specified between two nodes, for which transmission requires no control packets before it starts and after it stops. For exactly the same distance in IP hops and road scenario, the source and destination nodes are the same as previously chosen. The packet size and frequency are defined to match those of the monodirectional videoconference application (Table 3). Such application allows performing the same kind of comparisons as with previous applications, except that the delivery rate, end-to-end delay, and jitter constraints do not apply. It can be used to model any vehicular application in which an amount of data is sent freely in a best effort by any vehicle to another.

Table 3. Synthesis of evaluation scenarios parameters.

Road network	5 km straight, one-way, three lanes
Vehicle speed distribution	95% of vehicle speed ranges from 80% to 120%
	of 130 km/h for cars and 110 km/h for light trucks
Physical and MAC Layer	IEEE 802.11p
Routing protocol	TFD-OLSR, CBL-OLSR
Application traffic type	Bidirectional videoconference application (${\mathrm{A}}_{Vd}\mathrm{B}\mathrm{I}$)
	(6000-byte frames every 0.1 s)
	Monodirectional videoconference application (${\mathrm{A}}_{Vd}\mathrm{M}\mathrm{O}$)
	(12,000-byte frames every 0.1 s)
	Monodirectional packet stream (${\mathrm{A}}_{St}\mathrm{M}\mathrm{O}$)
	(12,000-byte application packets every 0.1 s)
Application traffic duration	50 s
IP Hop distance estimation	1 to 4 hops

Table 3. Synthesis of evaluation scenarios parameters.

Road network	5 km straight, one-way, three lanes
Vehicle speed distribution	95% of vehicle speed ranges from 80% to 120%
	of 130 km/h for cars and 110 km/h for light trucks
Physical and MAC Layer	IEEE 802.11p
Routing protocol	TFD-OLSR, CBL-OLSR
Application traffic type	Bidirectional videoconference application (${\mathrm{A}}_{Vd}\mathrm{B}\mathrm{I}$)
	(6000-byte frames every 0.1 s)
	Monodirectional videoconference application (${\mathrm{A}}_{Vd}\mathrm{M}\mathrm{O}$)
	(12,000-byte frames every 0.1 s)
	Monodirectional packet stream (${\mathrm{A}}_{St}\mathrm{M}\mathrm{O}$)
	(12,000-byte application packets every 0.1 s)
Application traffic duration	50 s
IP Hop distance estimation	1 to 4 hops

4. Results

4.1. Simulation and Measurement Process

The duration of each scenario simulation was set to 300 s. Measurements were collected once the network stabilized (Section 3.2.2) and the source–destination node pairs were within the road section. The source–destination node pairs, spaced 1–4 hops apart (Figure 5, Figure 6, Figure 7, Figure 8, Figure 9, Figure 10 and Figure 11), 5–6 hops apart (Figure 12) and 7 hops apart (Figure 13), were chosen to be spaced by the same number of IP hops for the duration of their exchanges.

Each result presented is the mean of the results obtained from six simulations, each carried out with a different seed value to avoid the influence of random number generation. The results collected could be entirely obtained upon request. However, due to the content limits of this paper, we focused on the results allowing us to conduct our analysis.

4.2. Evolution of Simulation Results with the Number of Hops

This section presents the results obtained for the three applications: bi- and monodirectional videoconference applications (${\mathrm{A}}_{Vd}\mathrm{B}\mathrm{I}$ and ${\mathrm{A}}_{Vd}\mathrm{M}\mathrm{O}$, respectively) and a monodirectional packet stream application (${\mathrm{A}}_{St}\mathrm{M}\mathrm{O}$). Except for jitter, the results for ${\mathrm{A}}_{St}\mathrm{M}\mathrm{O}$ are not plotted as they are generally similar to those of ${\mathrm{A}}_{Vd}\mathrm{M}\mathrm{O}$ in terms of trends and metric values. In this section, the results are reported as an evolution of mean and median values according to the number of hops observed between the source and destination during the exchanges. The median value informs whether the distribution of the six average values used to compute the mean value is symmetrical. The distribution is symmetric when the mean and median values are superimposed. In an asymmetrical distribution, a median value lower than the mean value means that the higher values in the distribution influence the resulting mean value. Conversely, a median value higher than the mean value means that the lower values in the distribution influence it.

Figure 5. Mean routing traffic in medium (S2) and high (S3) node density scenarios.

Figure 5. Mean routing traffic in medium (S2) and high (S3) node density scenarios.

Figure 6. Mean end-to-end delay in medium (S2) and high (S3) node density scenarios.

Figure 6. Mean end-to-end delay in medium (S2) and high (S3) node density scenarios.

As previously shown [14], CBL-OLSR produces less routing traffic than TFD-OLSR, even when restricted to a single traffic direction (Figure 5). Such traffic is mainly induced by HELLO and TC messages. Since HELLO messages are generated by every node, the difference comes from the TC messages that are produced by elected nodes (TFD-OLSR multipoint relays and CBL-OLSR branch nodes). By reducing the number of nodes producing TC messages, CBL-OLSR greatly lowers induced routing traffic. This reduction is even greater as the density of network nodes increases from S2 (Figure 5a,c) to S3 (Figure 5b,d).

Regarding the performance of both routing protocols for application traffic, it is clear that there is almost no difference when the exchanges occur directly between a source node and a destination node when they are oen hop apart or via a single relay node when they are two hops apart. Indeed, the exchanging nodes are too close, which limits the possibility of alternative routes and probably often leads to the same or similar two-hop routes.

Figure 6 and Figure 7 describe end-to-end packet delay and packet delay variation (i.e., jitter), respectively; end-to-end packet delays for ${\mathrm{A}}_{St}\mathrm{M}\mathrm{O}$ are not shown as they are similar to those for ${\mathrm{A}}_{Vd}\mathrm{M}\mathrm{O}$ (Figure 6b,c). The figures show that TFD-OLSR leads to longer delays than CBL-OLSR when the exchanging nodes are three hops away and beyond. Two explanations can be proposed for these results.

Figure 7. Mean jitter in medium (S2) and high (S3) node density scenarios.

Figure 7. Mean jitter in medium (S2) and high (S3) node density scenarios.

The first one is that the branch node selection criteria in CBL-OLSR, which take into account the relative mobility of the nodes, often lead to shorter hops and therefore better link quality between the relays and their selectors (leaf–branch and branch–branch links). Figure 8 shows the mean distance between a node and its relays. Because of the branch selection criteria implemented by CBL, the node-to-relay distance is greatly reduced for the CBL-OLSR clustering protocol. It can also be observed that while a higher-density scenario increases this distance in the case of TFD-OLSR, CBL-OLSR does the opposite and uses even closer relays.

The second reason for observing better end-to-end delay through CBL-OLSR is the reduced amount of routing traffic, which leaves more resources available for the benefit of application traffic.

Figure 8. Mean node-to-relay distances in medium (S2) and high (S3) node density scenarios.

Figure 8. Mean node-to-relay distances in medium (S2) and high (S3) node density scenarios.

However, when the exchanging nodes are three hops away or more, depending on the network density, a diversity may appear in the choice of routes from the source to the destination. In this case, Figure 9 shows that a mesh-like clustering strategy adopted in TFD-OLSR actually achieves a better packet delivery ratio than a backbone-like clustering such as in CBL-OLSR. Indeed, the latter mainly relies on the backbone through branch–branch links, which become single points of failure in the resulting longitudinal structure; in TFD-OLSR, the mesh structure built offers alternative routes. Another explanation relates to a structural problem that is resolved better by TFD-OLSR than by CBL-OLSR. With the latter, when an elected branch node exits the radio range, its leaf nodes must quickly reconnect to an existing branch node or elect one from scratch. Meanwhile, they all miss their single relay. With TFD-OLSR, an MPR node that exits the one-hop neighborhood of a node does not necessarily let all the two-hop neighbors of that node uncovered since multiple MPR nodes can cover them. This result illustrates the redundancy contribution to performance enhancement brought by mesh-like clustering to application traffic.

Therefore, these results establish that backbone-like clustering leads to better end-to-end delay and routing traffic overhead, while mesh-like clustering maintains a better packet delivery ratio by increasing both node density and route length in number of IP hops. None of these solutions actually outperforms the other. One way to try to deal with the latter issue is to consider a new metric which we refer to as the “bit-delay”. The bit-delay is obtained by dividing the amount of the application traffic received by the related end-to-end delay. In this way, the end-to-end delay achieved by each protocol is considered, along with the total amount of application traffic actually delivered within this delay. In medium node density scenarios, TFD-OLSR bit delay is lower than that of CBL-OLSR (Figure 10a), whereas in higher-density CBL-OLSR bit-delay is lower (Figure 10b). This can be interpreted as follows: when a clustering scheme achieves the least bit-delay, its advantage regarding the metric on which it is the best is superior to the advantage of the other protocol on the metric on which the latter is the best. Therefore, the advantage of TFD-OLSR in terms of packet delivery ratio is superior to the end-to-end delay offered by CBL-OLSR in the S2 medium node density scenario, while CBL-OLSR clearly offers an advantage for the end-to-end delay that is superior to the packet delivery ratio offered by TFD-OLSR in high node density scenarios (S3). In this case, for example, if an application requires packets to be delivered at a constant rate, CBL-OLSR could be a better choice since more units of data could be received in less time.

Figure 9. Delivery ratio in medium (S2) and high (S3) node density.

Figure 9. Delivery ratio in medium (S2) and high (S3) node density.

Figure 10. Mean bit-delay in medium (S2) and high (S3) node density scenarios.

Figure 10. Mean bit-delay in medium (S2) and high (S3) node density scenarios.

4.3. Simulation Results as a Function of Time

In the previous section, the figures provided an aggregation of the simulation results observed in time for each value of the number of hops for communicating pairs of nodes one to four hops apart, respectively. Those results are interesting, showing the evolution of the different metrics with the increasing distance between the communicating nodes. The results presented in this section provide a detailed description of the evolution of the metrics’ values in time for a communicating pair of nodes located four hops apart. Figure 11 shows these metrics values for the bidirectional videoconference application (${\mathrm{A}}_{Vd}\mathrm{B}\mathrm{I}$). It can be seen in Figure 11a,b that even if the source and destination nodes are estimated to be fourf hops apart, TFD-OLSR uses, more often than CBL, a higher number of hops to reach the destination. Though the mean node-to-relay distance (Figure 8), which is higher for TFD-OLSR than for CBL-OLSR, suggests fewer IP hops with TFD-OLSR to reach a given destination, the results show that CBL-OLSR achieves a better organization to optimize this metric. Concerning the end-to-end delay, Figure 11c,d show that the CBL-OLSR results are, most of the time, better than those of TFD-OLSR, probably due to a lower number of hops in the communications.

Figure 11. Mean number of hops, end-to-end delay, and percentage of received packets in medium (S2) and high (S3) node density scenarios for bidirectional videoconference and two communicating nodes spaced 4 hops apart.

Figure 11. Mean number of hops, end-to-end delay, and percentage of received packets in medium (S2) and high (S3) node density scenarios for bidirectional videoconference and two communicating nodes spaced 4 hops apart.

4.4. Simulation Result Limitations

4.4.1. Limitation on the Number of Hops

In this paper, simulations of communicating nodes above four hops away are not presented, as the delivery rate for such communications decreases dramatically. This is illustrated in Figure 12, which reports the packet delivery ratio results for communicating pairs of nodes located about about five to six hops apart. It can be seen that at the end of the transmission period, both S2 and S3 delivery rates were lower than 70%, with those of CBL-OLSR being up to 50%.

Figure 12. Mean number of IP hops and packet delivery ratio for the monodirectional packet flow application and two communicating nodes approximately 6 hops apart.

Figure 12. Mean number of IP hops and packet delivery ratio for the monodirectional packet flow application and two communicating nodes approximately 6 hops apart.

4.4.2. Limitation on the Benchmark of Compared Approaches

This paper focuses on the comparison between TFD-OLSR, a mesh-like approach, and CBL-OLSR, a backbone-like approach. However, some evaluations performed in a scenario involving two communicating nodes seven hops apart but also a reactive protocol, dynamic source routing (DSR), and a geographic routing protocol (GRP) confirmed that TFD-OLSR and CBL-OLSR still achieved a higher delivery rate (Figure 13a) and a lower end-to-end delay (Figure 13b), respectively. The end-to-end delay for DSR exceeds 1 s every time.

Figure 13. Mean delivery ratio and end-to-end delay for the monodirectional videoconference application and two communicating nodes approximately 7 hops apart.

Figure 13. Mean delivery ratio and end-to-end delay for the monodirectional videoconference application and two communicating nodes approximately 7 hops apart.

5. Conclusions and Future Work

In this study, we investigated the potential of both backbone-like and mesh-like clustering approaches to support low-latency communications through vehicle-to-vehicle exchanges for massively connected vehicles in the 6G era. In order to conduct a fair and accurate comparison between both approaches, we relied on two promising protocols. The first one is CBL-OLSR, a backbone-like clustering solution that has recently been shown to outperform most ad hoc routing protocol approaches. The other is TFD-OLSR, a variant of the well-known OLSR protocol, which is still widely referenced in the design of ad hoc routing protocols for vehicles. That OLSR variant was modified to perform in a single road traffic flow direction so that it could be compared fairly with CBL-OLSR on the basis of the same network node density and topology. Simulations conducted in medium and high node density networks and for various types of application traffic with different constraints showed that the CBL-OLSR backbone-like clustering solution always offers the best latency, while the TFD-OLSR mesh-like clustering always achieves the best packet delivery ratio. However, through a new metric introduced as the packet bit-delay, we observed that in medium node density networks, the global advantage is obtained withg the mesh-like approach, whereas high node density scenarios favor the global performance offered by backbone-like clustering. Since real-world vehicular networks may involve both time-constrained applications and various node density scenarios, the best solution is probably a combination of both clustering approaches or at least an adaptation of one approach in order to reduce the gap on the metrics for which the other approach still offers better performance. In our future work, we plan to investigate the latency reduction in mesh-like clustering approaches. Another interesting direction could focus on the combination of backbone-like clustering in the nearest neighborhood, where time-constraint applications are more likely to be necessary, with a mesh-like clustering approach at the level of branch nodes where redundancy may bring alternative routes and improve packet delivery ratio in more than two-hop exchanges.