FlockHocNet: A Flocking-Inspired Reactive Routing Protocol with Adaptive Relay Selection and Predictive Route Maintenance for Vehicular Ad Hoc Networks (VANETs)

1. Introduction

Vehicular Ad-hoc Networks (VANETs) are a communication substrate for cooperative intelligent transportation systems (ITS), enabling direct vehicle-to-vehicle (V2V) and, where infrastructure is present, vehicle-to-infrastructure (V2I) exchange for safety, traffic coordination, sensing, and infotainment services [1,2]. The networking problem differs fundamentally from comparatively slower mobile ad hoc settings: vehicles move rapidly along constrained road structures, relative velocities can be large, neighborhood membership changes quickly, and wireless links may disappear before a route discovered only moments earlier has delivered useful traffic. Routing therefore has to balance path reachability, delay, route lifetime, signaling cost, and adaptation speed rather than optimize only shortest paths.

Classic topology-based Mobile Ad-Hoc Network (MANET) protocols provide important baselines. Ad hoc On-demand Distance Vector (AODV) creates routes on demand through route-request (RREQ) flooding and sequence-number-based freshness [3]; Dynamic Source Routing (DSR) carries source routes and relies heavily on route caching [4]; and Optimized Link State Routing (OLSR) proactively maintains topology information through optimized relay dissemination [5]. In rapidly changing vehicular topologies, these design choices create different liabilities: reactive discovery can be repeated after link breaks, cached paths can become stale, and proactive dissemination can consume control capacity even when many destinations are inactive. Geographic forwarding reduces global state by using local position information, as exemplified by Greedy Perimeter Stateless Routing (GPSR) [6], while urban schemes such as Greedy Traffic-Aware Routing (GyTAR) incorporate traffic and road-junction structure [7]. Nevertheless, a relay that is geographically attractive at the current instant can still be a poor choice if it is moving rapidly away, crossing the trajectory, or residing near the edge of the useful local neighborhood. Recent direction-aware work confirms that motion compatibility remains a central source of routing stability in highly dynamic VANETs [8].

A second line of research uses multi-criteria, learning, or bio-inspired optimization to turn local observations into more adaptive routing decisions. Recent work has explored junction stability with Intelligent Water Drops [9], ant-colony optimization for multi-junction or clustered routing [10,11], link-stability optimization inspired by sticky bacteria [12], fuzzy mobility-aware route selection [13], and learning-assisted AODV variants [14]. Bio-inspired VANET routing is not new as a general paradigm [15]; however, many swarm-inspired designs perform global or path-level optimization, and not all mechanisms labelled “flocking” implement explicit local analogues of the canonical flock rules.

FlockHocNet takes a different approach. It starts from Reynolds’ distributed flocking model [16], in which coherent collective behavior emerges from local rules, and translates the three rules into network relay suitability: cohesion favors useful local proximity, alignment favors velocity compatibility, and separation avoids excessively short, redundant relays. Vehicles are never steered by the routing protocol; their trajectories remain externally determined. The resulting local flocking quality influences whether a node relays an RREQ, when it rebroadcasts, and how complete candidate routes are scored. Independent networking mechanisms then address route latency and continuity: a distance-based link-quality proxy, a neighbor-density contention proxy, guarded standby routes, link-layer failure feedback, constant-velocity link-expiration prediction, and local two-hop repair.

The research question is therefore: Can explicit local flocking compatibility improve the robustness of reactive VANET routing across changing node density without requiring global topology or infrastructure? This paper addresses that question at the integrated-protocol level through an implementation-grounded specification and a paired AODV comparison.

The main contributions are:

• an explicit and independently parameterized mapping of cohesion, alignment, and separation to one-hop relay quality, including a bottleneck flocking metric carried by RREQs;
• a reactive route-discovery and selection process that combines flocking eligibility, flocking-ranked RREQ delay, quality-of-service (QoS)-aware candidate scoring, provisional fast route replies (RREPs), and guarded risk-aware backups;
• a predictive maintenance design that clearly separates the biological mapping from non-biological engineering mechanisms, notably constant-velocity Link Expiration Time (LET), link degradation tests, link-layer feedback, and two-hop repair;
• an ns-3.46.1 scalability evaluation comprising 600 paired AODV/FlockHocNet runs over two Montreal OpenStreetMap road graphs with mobility generated by Simulation of Urban MObility (SUMO) and five network sizes, with paired bootstrap confidence intervals, Wilcoxon signed-rank tests, Holm correction, and paired effect sizes.

The remainder of the paper is organized as follows. Section 2 critically reviews recent VANET routing and identifies the research gap. Section 3 presents the flocking mapping, assumptions, and notation. Section 4 specifies the complete FlockHocNet protocol and algorithms. Section 5 provides a worked analytical example and the experimental methodology. Section 6 reports the results and discusses complexity, trade-offs, and limitations. Section 7 concludes the paper and outlines future work.

2. Related Work and Research Gap

This section positions FlockHocNet within the main VANET routing families relevant to its design. It first reviews topology-based, geographic, and mobility-aware approaches, then considers learning, clustering, software-defined, and bio-inspired routing before synthesizing the comparison and identifying the specific research gap addressed by FlockHocNet.

2.1. Topology-Based, Geographic, and Mobility-Aware Routing

Topology-based routing remains relevant because it provides mature mechanisms for route freshness, loop avoidance, and path repair. AODV’s reactive behavior avoids maintaining unused end-to-end paths, yet route-request flooding and rediscovery can become costly under repeated topology changes [3]. DSR reduces periodic control traffic but source-route caches are vulnerable to mobility-induced staleness [4]. OLSR reduces flooding redundancy through multipoint relays but still pays a proactive state-maintenance cost [5]. A recent comparative VANET study of AODV, OLSR, and Destination-Sequenced Distance-Vector (DSDV) routing again illustrates that no single topology-based strategy dominates all throughput, delay, jitter, and overhead conditions [17].

Position-based protocols avoid maintaining complete end-to-end topology. GPSR forwards greedily toward a destination and uses perimeter recovery when greedy progress is impossible [6]. Urban geographic protocols introduced road and intersection awareness; GyTAR, for example, combines geographic progress with traffic density and dynamic junction selection [7]. The cross-layer position-based design of Katsaros et al. later demonstrated a multi-metric approach combining predicted position, road information, link-quality indicators, and utilization [18]. More recent designs continue this trend. Kumar and Raw proposed a location-aware hybrid architecture assisted by roadside units (RSUs) and cloud infrastructure for software-defined VANETs [19], while Nabil et al. used cross-layer link-quality prediction and virtual multibackbones for highway forwarding [20]. Xu et al. combine message priority, free-node selection, and movement direction [21]; Zhang and Ye isolate direction-awareness as a lightweight mechanism in VANET-GPSR+ [8]. These works support the importance of mobility context, but most are geographic, infrastructure-assisted, or optimized around a different forwarding model than on-demand multi-route discovery.

2.2. Learning, QoS, Clustering, and Software-Defined Routing

Learning-based and multi-objective methods can adapt routing to more complex state. Ul Hassan et al. augment AODV with artificial neural network (ANN) methods and security mechanisms [14], while Swamynathan et al. combine driver-behavior prediction with an enhanced AODV/location-aided strategy [22]. Abdullah proposes fuzzy aggregation of bandwidth, delay, hop count, and mobility prediction to improve route stability [13]. These approaches can capture nonlinear relationships, but inference, training, or rule calibration may add complexity and may require state beyond a strictly local neighbor view.

Clustering and centralized or hierarchical control improve scalability by reducing the number of nodes participating directly in global decisions. Kaur et al. evaluate RSU-assisted clustering for emergency dissemination [23]; Behura et al. combine multi-objective cluster-head selection with secure routing and attack classification [24]; and Darabkh et al. integrate clustering, SDN, fog computing, and an AODV fallback [25]. The broader software-defined networking (SDN)-VANET literature highlights programmability and global network awareness, but also introduces controller reachability, infrastructure, and control-plane design questions [26]. FlockHocNet instead targets infrastructure-free distributed V2V routing, where each relay can compute its decision from local beacons plus information accumulated in a route request.

2.3. Bio-Inspired and Swarm-Intelligence Routing

Bio-inspired routing uses decentralized adaptation, population-based search, or stigmergic principles to handle network dynamics; a comprehensive survey by Bitam et al. identifies ant, bee, and other nature-inspired families and their VANET-specific strengths and costs [15]. Recent work demonstrates continued interest. Azzoug and Boukra apply Intelligent Water Drops to junction-based route-stability estimation [9]. Lee et al. use ant-colony optimization (ACO) for multi-junction traffic-aware routing [10]; Ramamoorthy combines location assistance and ant-colony routing for secure VANET communication [27]; and Pidy Pidy et al. integrate adaptive clustering with ACO for stable data delivery [11]. Zhang et al. use a sticky-bacteria algorithm together with link-stability criteria [12], while Sumit et al. employ chaotic multi-verse optimization for secure routing in smart-city VANETs [28]. These protocols show that swarm intelligence can improve search or stability, but their biological mechanisms are typically metaheuristic optimizers rather than a direct, per-neighbor implementation of flocking rules.

Reynolds’ original flocking model is distinct because global coherence emerges from three local behaviors—cohesion, alignment, and separation—without a centralized planner [16]. This structure is attractive for VANET routing: forwarding is also a sequence of local decisions under incomplete information. The key design challenge is to map these behavioral rules to networking quantities without claiming that the protocol controls physical motion. FlockHocNet therefore interprets them only as relay-selection preferences and keeps engineering predictors, such as LET, conceptually separate. Table 1 summarizes how these representative approaches differ from FlockHocNet in routing model, mobility awareness, link-stability treatment, and biological mechanism.

2.4. Research Gap and Motivation

The literature reveals three persistent gaps. First, mobility-aware forwarding often uses one or two instantaneous quantities—distance, direction, or estimated lifetime—without representing the competing local effects of proximity, velocity compatibility, and excessively short/redundant forwarding. Second, swarm-based VANET routing frequently employs a metaheuristic to optimize junctions, clusters, or complete paths; comparatively less attention has been given to an explicit Reynolds-style mapping that acts at every local relay decision. Third, many proposals combine biological terminology with engineering predictors without separating what is biologically inspired from what is simply a networking mechanism. FlockHocNet addresses these gaps by (i) defining three normalized, independently switchable local flocking terms; (ii) propagating their bottleneck value within a reactive RREQ so that path selection remains sensitive to the weakest mobility-compatible hop; and (iii) explicitly labeling LET, backup management, and repair as non-biological engineering components. The novelty is therefore not “bio-inspired routing” in general, but the integration of explicit local flocking-rule analogues into reactive discovery, relay timing, candidate scoring, and route-stability assessment.

3. FlockHocNet Design Principles and System Model

This section establishes the conceptual and mathematical foundations of FlockHocNet. It defines the flocking-to-routing analogy, states the network and local-state assumptions, summarizes the protocol parameters, and introduces the link-quality and contention proxies used by the routing mechanisms developed in the next section.

3.1. Biological Inspiration as a Routing Analogy

FlockHocNet uses Reynolds’ flocking rules as a design analogy [16]. The mapping is intentionally narrow. A vehicle’s physical trajectory is not changed by the protocol. Instead, a forwarding node evaluates whether a one-hop neighbor resembles a locally compatible flock member. Cohesion rewards neighbors that remain within a useful interaction region; alignment rewards similar movement direction and speed; and separation penalizes extremely short hops that provide little forwarding diversification. The three effects are combined into a dimensionless relay-quality score.

Consider node i and neighbor j. Let ${\mathbf{p}}_i,{\mathbf{p}}_j\in {\mathbb{R}}^3$ be their positions, ${\mathbf{v}}_i,{\mathbf{v}}_j\in {\mathbb{R}}^3$ their velocities, and

$$d_{ij}={\parallel {\mathbf{p}}_j-{\mathbf{p}}_i\parallel }_2.$$

(1)

The cohesion analogue is

$$C_{ij}=\mathrm{clip}\left(1-{\displaystyle \frac{d_{ij}}{R_c}},0,1\right),$$

(2)

where $R_c=150$ m by default. Unlike a binary distance gate, (2) decays continuously to zero at the interaction radius.

The separation analogue is

$$S_{ij}=min\left(1,{\displaystyle \frac{d_{ij}}{d_{\mathrm{sep}}}}\right),$$

(3)

with $d_{\mathrm{sep}}=12$ m. Hence only very short candidate hops are penalized; a candidate at or beyond 12 m receives the maximum separation term.

For the alignment analogue, define speed magnitudes $s_i=\parallel {\mathbf{v}}_i\parallel$ and $s_j=\parallel {\mathbf{v}}_j\parallel$. When both exceed a small implementation threshold ${ϵ}_v=0.25$ m/s,

$$D_{ij}={\displaystyle \frac{1+cos{\theta }_{ij}}{2}},cos{\theta }_{ij}={\displaystyle \frac{{\mathbf{v}}_i·{\mathbf{v}}_j}{s_i{s}_j}}.$$

(4)

If both are effectively stopped, $D_{ij}=1$; if only one is stopped, $D_{ij}=0.5$. Speed similarity is

$$V_{ij}=exp\left(-{\displaystyle \frac{|s_i-s_j|}{v_s}}\right),$$

(5)

where $v_s=10$ m/s by default, and

$$A_{ij}=D_{ij}{V}_{ij}.$$

(6)

Finally,

$$F_{ij}={\displaystyle \frac{w_c{C}_{ij}+w_a{A}_{ij}+w_s{S}_{ij}}{w_c+w_a+w_s}},$$

(7)

with $(w_c,w_a,w_s)=(0.35,0.45,0.20)$. Each term and the final score lie in $[0,1]$. If kinematics are unavailable, the implementation assigns a neutral $F_{ij}=0.5$ rather than falsely assuming perfect compatibility. If the biological layer is disabled, the flocking contribution is removed from routing decisions.

3.2. Network Assumptions and Local State

The protocol assumes an Internet Protocol version 4 (IPv4) multi-hop V2V ad hoc network. Every vehicle runs the same routing logic and has a mobility model that exposes current position and velocity; the Global Positioning System (GPS), inertial sensing, or simulator-provided kinematics are possible sources. No central controller, global topology database, or RSU is required for routing. V2I can coexist at the system level, but the FlockHocNet mechanisms specified here are decentralized V2V mechanisms.

Vehicles periodically broadcast HELLO packets every $T_H=1$ s with a 0–20 ms random jitter. The HELLO payload contains the origin IPv4 address, timestamp, position $(x,y,z)$, and velocity $(v_x,v_y,v_z)$. Position and velocity components are serialized in centimeters as signed 32-bit integers. The HELLO payload is 36 bytes; including the one-byte FlockHocNet type field yields 37 bytes before User Datagram Protocol (UDP), Internet Protocol (IP), and medium access control (MAC) headers. A neighbor is considered stale after $T_N=3$ s without a HELLO. The neighbor table is therefore a one-hop kinematic cache from which $d_{ij}$, $F_{ij}$, link proxies, and LET can be computed. The symbols and default parameter values used throughout the protocol specification are summarized in Table 2.

3.3. Networking Quality Proxies

FlockHocNet uses a normalized distance-based link-quality proxy rather than claiming direct received signal strength indicator (RSSI) or signal-to-interference-plus-noise ratio (SINR) measurement. For separation d,

$$Q_L\left(d\right)=\left\{\begin{array}{cc}1-{\left(d/R_t\right)}^{\eta },\hfill & 0\le d<R_t,\hfill \\ 0,\hfill & d\ge R_t,\hfill \end{array}\right.$$

(8)

clipped to $[0,1]$, with $R_t=300$ m and $\eta =2$. If a neighbor measurement is unavailable, $Q_L=0.5$ is used as a neutral value.

A second quantity estimates contention rather than measured residual bandwidth. If $N_i$ is the number of alive neighbors of node i,

$$Q_B(i,j)=Q_L(i,j){\displaystyle \frac{1}{1+N_i/K_B}},$$

(9)

with $K_B=10$. This term is called a contention/neighbor-density proxy; it should not be interpreted as a physical-layer bandwidth measurement.

4. Proposed FlockHocNet Routing Protocol

Building on the local metrics defined above, this section specifies the complete FlockHocNet routing workflow. It describes control-message exchange and neighbor maintenance, flocking-aware route discovery, candidate scoring and guarded backup selection, and predictive failure recovery with local two-hop repair.

4.1. Control Messages and Neighbor Maintenance

FlockHocNet defines seven control types: route request (RREQ), route reply (RREP), route error (RERR), route-reply acknowledgment (RREP_ACK), HELLO, REPAIR, and repair acknowledgment (REPAIR_ACK). In the current implementation, an RREQ carries hop count, request identifier, destination, origin, origin timestamp, and three 16-bit normalized bottleneck fields: minimum link quality, minimum contention/bandwidth quality, and minimum flocking quality. These fields permit a destination to compare multiple requests without storing the complete path at every relay. The RREQ payload is 27 bytes (28 bytes including the type field), the RREP payload is 20 bytes (21 with type), RERR is 4 bytes (5 with type), and REPAIR is 23 bytes (24 with type).

Each HELLO reception refreshes the sender’s neighbor-table entry. Neighbor expiry and link-layer retry-limit feedback can invoke link-failure handling. This dual detection mechanism is important because a missing HELLO detects longer-lived disappearance, while MAC retry failure can expose a forwarding failure earlier.

4.2. Flocking-Aware Route Discovery

When a source needs a route, it initializes the three RREQ path bottlenecks to one. At a receiver, the sender’s cached kinematics are used to compute $F_{ij}$. A non-destination relay suppresses the RREQ copy if

$$F_{ij}<F_{min},F_{min}=0.25.$$

(10)

The destination is exempt from this local suppression so that reachable destination copies can still be collected.

For an eligible relay, the path values are updated by a weakest-hop rule:

$$\begin{array}{cc}\hfill Q_{L,p}^{\prime }& =min(Q_{L,p},Q_L(i,j)),\hfill \end{array}$$

(11)

$$\begin{array}{cc}\hfill Q_{B,p}^{\prime }& =min(Q_{B,p},Q_B(i,j)),\hfill \end{array}$$

(12)

$$\begin{array}{cc}\hfill F_p^{\prime }& =min(F_p,F_{ij}).\hfill \end{array}$$

(13)

The use of $F_p=min{F}_{ij}$ makes the route sensitive to a single strongly incompatible mobility transition instead of allowing good hops to average away a weak one. Forwarders suppress duplicate RREQs, while the destination intentionally accepts multiple copies during a candidate-collection interval.

Flocking quality also controls RREQ timing. Instead of assigning the same random jitter to all eligible relays, the forwarding delay is

$$T_{\mathrm{fwd}}=(1-F_{ij})8\mathrm{ms}+U(0,2\mathrm{ms}),$$

(14)

so locally compatible relays tend to rebroadcast earlier. The random term breaks ties and reduces synchronized retransmission. This mechanism is a networking analogue of decentralized local response; it is not a claim that routing changes vehicle motion. Algorithm 1 summarizes the resulting RREQ processing logic executed at an intermediate relay.

Algorithm 1:Flocking-Aware RREQ Processing at Relay i

Require:  RREQ r, previous hop j, local neighbor table 1: $F\leftarrow ComputeFlockingQuality(i,j)$ 2: if$i\ne r.\mathrm{dst}\wedge \mathrm{BioEnabled}\wedge F<F_{min}$then  3:     discard this RREQ copy 4:     return  5: end if  6: if$i\ne r.\mathrm{dst}\wedge IsDuplicate\left(r\right)$then  7:     discard 8:     return  9: end if  10: $q\leftarrow Q_L(i,j)$ 11: $b\leftarrow Q_B(i,j)$ 12: $r.\mathrm{minLink}\leftarrow min(r.\mathrm{minLink},q)$ 13: $r.\mathrm{minBandwidth}\leftarrow min(r.\mathrm{minBandwidth},b)$ 14: $r.\mathrm{minFlock}\leftarrow min(r.\mathrm{minFlock},F)$ 15: install or refresh reverse route to $r.\mathrm{origin}$ through j  16: if$i=r.\mathrm{dst}$then  17:     append candidate 18:     schedule fast/final selection 19:     return  20: end if  21: increment hop count 22: schedule rebroadcast after 22:      $(1-F)8\mathrm{ms}+U(0,2\mathrm{ms})$

4.3. Candidate Collection and Route Scoring

The destination collects candidates for $T_C=50$ ms. A provisional fast RREP can be sent after $T_F=2$ ms using the best candidate seen so far, while collection continues for optimized primary and backup selection. The source retries an unanswered discovery after $T_{RREQ}=200$ ms, with at most two retries by default.

For each candidate path, latency quality and hop quality are normalized as

$$Q_T=1-\mathrm{clip}\left({\displaystyle \frac{D}{D_{max}}},0,1\right),Q_H=\left\{\begin{array}{cc}1/H,\hfill & H>0,\hfill \\ 1,\hfill & H=0.\hfill \end{array}\right.$$

(15)

The primary non-biological QoS score is

$$Q_{\mathrm{QoS}}=w_1{Q}_{L,p}+w_2{Q}_T+w_3{Q}_H,$$

(16)

with $(w_1,w_2,w_3)=(0.5,0.3,0.2)$. The final route score is

$$Q_R=(1-w_f)Q_{\mathrm{QoS}}+w_f{F}_p,w_f=0.35.$$

(17)

The weights are normalized in the implementation if modified, so they remain interpretable as relative contributions. Increasing $w_f$ makes the route more conservative with respect to the weakest flocking-compatible hop; decreasing it approaches the non-biological QoS scorer. Within $F_{ij}$, increasing $w_a$ strengthens velocity alignment preference, increasing $w_c$ favors closer membership in the interaction region, and increasing $w_s$ more strongly penalizes ultra-short candidates.

Backup routes use

$$Q_{\mathrm{bak}}=\alpha Q_{L,p}+\beta Q_{B,p}+\gamma Q_T,$$

(18)

with $(\alpha ,\beta ,\gamma )=(0.4,0.4,0.2)$, followed by the same $w_f$ flocking blend. A guarded backup must have a distinct previous hop, score at least 0.50, no more than one extra hop relative to the primary, and a primary-score deficit no greater than 0.12. Risk-aware advertisement is enabled: if the primary bottleneck link quality is at or below 0.75, the alternate should provide at least 0.05 additional bottleneck quality. Backup lifetime is capped at 3 s. These constraints reduce stale or nearly redundant standby routes. Algorithm 2 formalizes the primary-route ranking and guarded-backup selection procedure applied to the collected candidate set.

Algorithm 2:Primary and Guarded Backup Selection

Require:  candidate set $\mathcal{C}$ collected during $T_C$ 1: for all$c\in \mathcal{C}$do  2:     compute $Q_R\left(c\right)$ using (17) 3:     compute flocking-blended backup score $Q_R^{\mathrm{bak}}\left(c\right)$ 4: end for  5: sort candidates by descending $Q_R$ 6: $p\leftarrow$ highest-scoring candidate 7: send or install primary RREP for p  8: for all$c\in \mathcal{C}\setminus \left\{p\right\}$ in descending score order do  9:     if $DifferentPreviousHop(c,p)\wedge Q_R^{\mathrm{bak}}\left(c\right)\ge 0.50\wedge HopStretch(c,p)\le 1$ then  10:         if $Q_R^{\mathrm{bak}}\left(p\right)-Q_R^{\mathrm{bak}}\left(c\right)\le 0.12\wedge RiskConditionsSatisfied\left(c\right)$ then  11:            select c as dormant backup 12:            break  13:         end if  14:     end if  15: end for  16: advertise selected backup, if any

4.4. Predictive Link Assessment and Route Maintenance

FlockHocNet deliberately separates flocking from mobility prediction. The constant-velocity Link Expiration Time (LET) is an engineering predictor, not a biological rule. Let

$$\mathbf{r}={\mathbf{p}}_j-{\mathbf{p}}_i,\mathbf{u}={\mathbf{v}}_j-{\mathbf{v}}_i.$$

(19)

The predicted exit from radio range $R_t$ satisfies

$${\parallel \mathbf{r}+t\mathbf{u}\parallel }^2=R_t^2.$$

(20)

With $a=\mathbf{u}·\mathbf{u}$, $b=2\mathbf{r}·\mathbf{u}$, and $c=\mathbf{r}·\mathbf{r}-R_t^2$, the positive future root for a currently connected pair is

$$T_{\mathrm{LET}}={\displaystyle \frac{-b+\sqrt{b^2-4ac}}{2a}},$$

(21)

when $a>0$, $c<0$, and the discriminant is nonnegative.

The implementation derives a default link-quality stability threshold from the cohesion radius when no explicit value is set:

$$Q_{\mathrm{coh}}=1-{\left({\displaystyle \frac{R_c}{R_t}}\right)}^{\eta }.$$

(22)

For $R_c=150$ m, $R_t=300$ m, and $\eta =2$, $Q_{\mathrm{coh}}=0.75$. A link is marked unstable if at least one of the following holds: it is already outside $R_t$; $Q_L<Q_{\mathrm{coh}}$; bio-flocking is enabled and $F_{ij}<0.25$; the observed link proxy drops by at least 0.20; distance grows by at least 50 m between observations; or $T_{\mathrm{LET}}\le 5$ s. Proactive repair exists as an exposed attribute but is disabled in the Full configuration used here; instability information still supports route validity and recovery logic.

When a forwarding failure occurs, recovery proceeds locally when possible. A directly reachable destination can be used immediately. Otherwise, a valid guarded backup may be promoted. If no suitable backup exists and two-hop repair is enabled, the node searches alive neighbors for a bridge around the broken next hop. The local candidate must satisfy the cohesion-derived quality threshold on both local legs and achieve an estimated route score of at least 0.35. A REPAIR message is sent and must be acknowledged within 25 ms. Failure of repair or backup activation leads to RERR propagation and, if demand remains active, a fresh RREQ. Data awaiting discovery/repair are queued for at most 30 s, with a default maximum queue length of 64 packets. Algorithm 3 summarizes the ordered recovery procedure, from direct reuse and backup promotion to two-hop repair and final rediscovery.

Algorithm 3:Failure Recovery and Two-Hop Repair

Require:  destination d, broken next hop b  1: if$IsAliveNeighbor\left(d\right)\wedge IsLinkUsable\left(d\right)$then  2:     install direct local route to d  3:     return  4: end if  5: if$ValidGuardedBackupExists\left(d\right)\wedge IsBackupUsable\left(d\right)$then  6:     promote guarded backup 7:     return  8: end if  9: if$TwoHopRepairEnabled$then  10:     for all alive bridge neighbors k do  11:         test local $Q_L(i,k)$ and bridge-side reachability to d  12:         estimate bottleneck link quality $Q_L^{\mathrm{rep}}\left(k\right)$ 13:         compute local flocking quality $F_{ik}$ 14:         compute repair score $Q_{\mathrm{rep}}\left(k\right)$ 15:     end for  16:     $k^{*}\leftarrow BestBridge\left(Q_{\mathrm{rep}}\right)$ 17:     if $k^{*}\ne ⌀\wedge Q_{\mathrm{rep}}\left(k^{*}\right)\ge 0.35$ then  18:         send REPAIR message through $k^{*}$ 19:         wait up to $25\mathrm{ms}$ for REPAIR_ACK 20:         if $RepairAcknowledged(k^{*},d)$ then  21:            install repaired route through $k^{*}$ 22:            return  23:         end if  24:     end if  25: end if  26: if$ValidGuardedBackupExists\left(d\right)\wedge IsBackupUsable\left(d\right)$then  27:     promote guarded backup 28:     return  29: end if  30: invalidate route to d  31: send RERR toward affected upstream nodes 32: initiate route rediscovery on demand

5. Analytical Illustration and Experimental Methodology

This section connects the protocol equations to both an illustrative routing decision and the empirical evaluation. It first provides a worked relay-selection example, then details the ns-3/SUMO implementation and paired simulation design, and finally defines the evaluation metrics and statistical analysis.

5.1. Worked Relay-Selection Example

Consider a forwarding vehicle $V_0$ at $(0,0)$ m moving east at 20 m/s. Three one-hop candidates are available, as illustrated in Figure 1. Vehicle $V_1$ is located 100 m east of $V_0$ and moves east at 21 m/s, $V_2$ is located 60 m to the north and moves north at 20 m/s, while $V_3$ is located 145 m away and moves west at 20 m/s. The destination D lies east of the candidate-relay region.

For $V_1$, $d=100$ m gives $C=1-100/150=0.333$. Since both velocities point east, $D=1$; their speed difference is 1 m/s, so $V=e^{-0.1}=0.905$ and $A=0.905$. Because $d>12$ m, $S=1$. Equation (7) yields

$$F_{01}=0.35\left(0.333\right)+0.45\left(0.905\right)+0.20\left(1\right)=0.724.$$

(23)

For perpendicular $V_2$ at 60 m, $C=0.6$, $D=0.5$, $V=1$, $A=0.5$, and $F_{02}=0.635$. For opposite-moving $V_3$ at 145 m, $C=0.033$, $D=0$, $A=0$, $S=1$, giving $F_{03}=0.212$. Because $F_{03}<0.25$, $V_3$ does not relay this RREQ copy. Between $V_1$ and $V_2$, $V_1$ rebroadcasts earlier on average because its flocking quality is higher.

The route-level blend can also alter a seemingly attractive shortest-path decision. Suppose candidate route $R_1$ has $Q_{L,p}=0.75$, discovery delay 20 ms, three hops, and $F_p=0.72$. Then $Q_T=0.8$, $Q_H=1/3$, $Q_{\mathrm{QoS}}=0.682$, and $Q_R=0.695$. Route $R_2$ has stronger bottleneck link quality $0.85$, 35 ms delay, two hops, but a weaker flocking bottleneck $F_p=0.40$. Its $Q_{\mathrm{QoS}}=0.720$ but its final score falls to $Q_R=0.608$. FlockHocNet therefore selects $R_1$: the extra hop is accepted because the route avoids a mobility-incompatible weak point. An AODV decision under equal freshness would generally favor hop count rather than this explicit motion-compatibility bottleneck, illustrating the conceptual distinction without treating the example as an experimental result.

5.2. Implementation and Evaluation Design

FlockHocNet is implemented as an ns-3 IPv4 routing protocol and evaluated with ns-3.46.1 [29]. Vehicular mobility is generated by Simulation of Urban MObility (SUMO) [30] on two real road graphs extracted from OpenStreetMap (OSM) in Montreal. The resulting mobility traces are synthetic SUMO trajectories constrained by real road geometry; they are not measurements of observed Montreal traffic. This distinction is important because road-topology realism does not by itself imply empirical traffic realism.

The first environment is a downtown/Ville-Marie graph covering approximately longitude $[-73.5900,-73.5525]$ and latitude $[45.4925,45.5205]$. The second is a Decarie/A-15/A-40 corridor graph covering approximately longitude $[-73.6750,-73.6150]$ and latitude $[45.4820,45.5350]$. Frozen OSM snapshots are used to construct repeatable SUMO networks. Figure 2 shows the two simulation road graphs. SUMO applies a 30-s warm-up before the exported 300-s networking interval, a 0.2-s microscopic simulation step, and 0.5-s mobility-trace sampling. Three vehicle-behavior profiles vary speed factor, acceleration, deceleration, and driver imperfection so that the traffic population is not governed by a single homogeneous driving model.

Five fixed vehicle populations are evaluated, $N\in \{20,40,60,80,100\}$. For each road environment and population, 30 mobility seeds are generated. AODV and FlockHocNet receive the same mobility trace, source-destination pair file, ns-3 seed, and run number for each paired observation. With two road environments, five populations, 30 paired mobility realizations, and two routing protocols, the campaign contains

$$2\times 5\times 30\times 2=600$$

(24)

network simulations.

Eight endpoint-disjoint UDP source-destination pairs are selected near application start using a connected-multihop-first policy followed by a farthest-disjoint fallback when necessary. Both protocols receive identical pairs in each paired run. Each source sends 512-byte application packets at 64 kbit/s, giving a nominal aggregate offered application load of $8\times 64=512$ kbit/s, excluding routing and lower-layer overhead. Sources start with small random jitter in the interval 20–21 s and stop at 295 s; the networking simulation ends at 300 s.

The physical-layer (PHY) and medium access control (MAC) configuration uses the Institute of Electrical and Electronics Engineers (IEEE) 802.11p standard in ad hoc mode, a 10-MHz channel, channel 178 at approximately 5.89 GHz, a constant orthogonal frequency-division multiplexing (OFDM) rate of 6 Mbit/s for data and control, and transmit power of 20 dBm. Propagation uses YansWifiChannel with constant-speed delay and Two-Ray Ground loss. No small-scale fading, building obstruction, or shadowing process is added. The present evaluation therefore isolates routing behavior under deterministic distance-dependent propagation more than it represents the full variability of an urban vehicular radio channel. The complete simulation configuration is summarized in Table 3.

The Full FlockHocNet configuration enables the biological layer, cohesion, alignment, separation, fast RREP, guarded backup routes, adaptive scoring, link-layer feedback, and two-hop repair. Proactive repair is disabled. The evaluation measures the integrated Full protocol against AODV; the 600-run campaign does not contain biological-rule ablations, so the experiment cannot causally assign the measured gain to any single flocking term.

5.3. Metrics and Statistical Analysis

The principal reliability metric is packet delivery ratio (PDR)

$$\mathrm{PDR}={\displaystyle \frac{N_{rx}}{N_{tx}}}.$$

(25)

Payload goodput is computed from received application payload over the measurement duration. Mean end-to-end delay and jitter are computed over delivered application packets. Routing cost is characterized primarily by normalized routing load (NRL), i.e., routing-control transmissions relative to delivered data traffic, together with routing-control bytes and routing overhead rate recorded by the campaign.

For each scenario, density, and metric, the 30 FlockHocNet observations are paired with the corresponding 30 AODV observations. Let $x_i^F$ and $x_i^A$ be the two measurements for run i and ${\Delta }_i=x_i^F-x_i^A$. We report mean values, paired bootstrap 95% confidence intervals for the mean difference, two-sided Wilcoxon signed-rank tests, and paired Cohen effect size

$$d_z={\displaystyle \frac{\overline{\Delta }}{s_{\Delta }}}.$$

(26)

Holm correction is applied across the five density comparisons within each scenario/metric family. Statistical significance is assessed at adjusted $p<0.05$. Because delay is defined only for packets that arrive, very low-PDR cases are interpreted cautiously to avoid survivor bias.

6. Results, Complexity, and Discussion

This section reports the paired simulation results and interprets them in relation to FlockHocNet’s design objectives. It examines delivery reliability, routing overhead, delay and goodput, then analyzes computational complexity and discusses the principal design trade-offs and limitations.

6.1. Packet Delivery Ratio and Density Scaling

Figure 3 shows the central result. In the Decarie/highway scenario, FlockHocNet is essentially indistinguishable from AODV at 20 and 40 vehicles: mean PDR changes from 0.01208 to 0.01170 ($-3.16\%$ relative) and from 0.06668 to 0.06646 ($-0.33\%$), respectively, with no significant paired difference after Holm correction. At 60 vehicles, FlockHocNet reaches 0.21416 versus 0.20272 for AODV ($+5.64\%$), but the adjusted test remains non-significant. The advantage becomes significant at 80 vehicles (0.40998 versus 0.38715, $+5.90\%$, adjusted $p=0.0111$, $d_z=0.640$) and at 100 vehicles (0.52908 versus 0.48969, $+8.04\%$, adjusted $p=6.17\times {10}^{-4}$, $d_z=0.855$).

The downtown/urban scenario exhibits a stronger density transition. At 20 and 40 vehicles, the relative gains are modest ($+3.21\%$ and $+3.77\%$) and do not reach the adjusted 0.05 threshold. At 60 vehicles, mean PDR rises from 0.77601 to 0.86291 ($+11.20\%$, adjusted $p=1.10\times {10}^{-5}$, $d_z=1.127$). At 80 vehicles it rises from 0.80125 to 0.88081 ($+9.93\%$, adjusted $p=6.27\times {10}^{-4}$), and at 100 vehicles from 0.75677 to 0.89286 ($+17.98\%$, adjusted $p=8.42\times {10}^{-6}$, $d_z=1.341$). The paired confidence intervals are entirely positive for these three dense urban cases.

The density dependence is consistent with FlockHocNet’s mechanism. When few relays exist, filtering RREQs by $F_{ij}$ and exchanging periodic HELLOs cannot create connectivity that is physically absent; the protocol may instead spend additional control effort while searching for a compatible relay. As density grows, the candidate set becomes richer, allowing flocking-based eligibility and path scoring to reject unstable transitions without eliminating all useful alternatives. The urban results suggest that this relay diversity is particularly valuable when local motion directions are heterogeneous.

6.2. Routing Overhead and the Reliability–Cost Trade-Off

Figure 4 shows that reliability improvement is not free. In the Decarie/highway scenario, FlockHocNet’s mean NRL is higher than AODV at every density: approximately $+643\%$, $+251\%$, $+207\%$, $+174\%$, and $+131\%$ from 20 to 100 vehicles, with statistically significant paired differences. This is attributable to HELLO-based kinematic state, multi-candidate discovery, backup signaling, and recovery functions operating in a topology where delivered application traffic is low at sparse densities. Because NRL normalizes by delivered data, extremely low PDR also magnifies the ratio.

In the downtown/urban scenario, the overhead penalty contracts as density increases. FlockHocNet NRL is $+382\%$ at 20 vehicles, $+205\%$ at 40, and $+24.1\%$ at 60. At 80 vehicles, the mean difference becomes negative ($-13.85\%$), although the paired bootstrap interval for the mean difference crosses zero and should therefore be treated cautiously despite the Wilcoxon/Holm result. At 100 vehicles, the reduction is unambiguous: NRL decreases from 8.087 for AODV to 3.374 for FlockHocNet ($-58.28\%$), the paired bootstrap interval is entirely negative, adjusted $p=3.07\times {10}^{-7}$, and $d_z=-2.03$. In this dense urban regime, the cost of FlockHocNet’s periodic and candidate-selection control is more than compensated by fewer unsuccessful deliveries and rediscovery-related transmissions per delivered packet.

6.3. Delay, Goodput, and Interpretation

Payload goodput follows PDR closely because the offered application rate is fixed across protocols. Consequently, PDR is the more informative primary reliability figure and goodput is treated as a corroborating outcome rather than an independent mechanism-level finding. Delay results require more care. In highway cases with very low delivery, FlockHocNet reports much lower mean delay than AODV; however, a mean over the small subset of packets that survive does not represent delay for the many lost packets. The same caution applies to the 20-vehicle urban case. At denser urban settings (60–100 vehicles), paired delay differences are not consistently significant after correction, indicating that the principal robust advantage in this campaign is delivery reliability rather than universal latency reduction.

Figure 5 directly visualizes the run-paired PDR effect. The transition from near-zero or uncertain differences at low density to clearly positive differences at high density is especially visible in the urban scenario. This plot is useful because it emphasizes that the statistical unit is the matched run, not an unpaired comparison of aggregate means.

The numerical values underlying the principal density-dependent PDR comparisons are consolidated in Table 4, including paired confidence intervals, Holm-adjusted significance levels, and paired effect sizes.

6.4. Complexity Analysis

Let ${\delta }_i$ denote the alive one-hop degree at node i, N the number of vehicles, E the current communication links, and K the number of RREQ candidates received at a destination. HELLO processing and each individual flocking-score computation are $O\left(1\right)$. Evaluating all local neighbors for repair is $O\left({\delta }_i\right)$. Routing-table and queue operations depend on implementation containers but remain local to stored routes and queued packets.

A route discovery preserves the worst-case broadcast nature of a reactive protocol: in a connected graph, RREQ dissemination is $O\left(E\right)$ receptions and $O\left(N\right)$ broadcasts in the worst case. Flocking suppression and ranked rebroadcast timing reduce the practical number and ordering of forwarders but do not change that asymptotic bound. Candidate scoring is $O\left(K\right)$ and sorting is $O(KlogK)$. Guarded-backup scanning is $O\left(K\right)$. Two-hop repair in the implementation iterates local bridge candidates and performs constant-time geometric checks per candidate, giving $O\left({\delta }_i\right)$ relative to current local state.

Per-node state is $O({\delta }_i+R_i+Q_i)$ for neighbor entries, active/backup routing entries, and queued packets. Communication overhead has three components: periodic HELLO traffic proportional to $N/T_H$ network-wide, on-demand RREQ/RREP/RERR signaling, and conditional backup/repair traffic. The results in Figure 4 show that the constant cost of richer local state is substantial when delivery is sparse but can be amortized when density provides many viable relays.

6.5. Design Trade-offs and Limitations

The first trade-off is eligibility versus reachability. A high $F_{min}$ or $w_f$ can reject motion-incompatible relays and improve path stability when alternatives exist, but can over-prune sparse networks. The second is stability versus signaling: 1-s HELLOs and multiple RREQ candidates improve local knowledge but increase control traffic. The third is latency versus optimization: the 2-ms provisional RREP reduces initial wait, while the 50-ms collection window allows the destination to find a better primary and backup. The fourth is local robustness versus stale alternatives: guarded backup lifetime and score/hop constraints intentionally limit how long a standby route is trusted.

Several limitations bound the claims of this paper. First, the experimental campaign evaluates the integrated Full FlockHocNet against AODV, but does not contain the biological and engineering ablations exposed by the implementation. Therefore, the observed improvements cannot yet be causally decomposed into cohesion, alignment, separation, fast RREP, backup, and two-hop-repair contributions. Second, the mobility traces are synthetic SUMO trajectories on real OSM road graphs. This improves road-topology realism and repeatability but does not constitute validation on observed Montreal traffic trajectories; the heterogeneous driver profiles remain simulator-generated. Third, the campaign uses Two-Ray Ground without additional fading, building blockage, or shadowing, so measured V2V channel dynamics may alter the relative benefit of the distance-based link proxy. Fourth, AODV is a strong conventional baseline but does not span the full contemporary design space represented by geographic, fuzzy, clustering, and swarm-based protocols in Table 1. Finally, the current parameter values are implementation defaults rather than globally optimized constants. Their use is reproducible, but sensitivity analysis is necessary before claiming scenario-independent optimality.

These limitations do not invalidate the central result: under matched conditions, the integrated protocol has a clear density-dependent PDR advantage over AODV, especially in the downtown/urban scenario. They do constrain the interpretation to protocol-level effectiveness rather than proof that every individual biological rule independently contributes to that gain.

7. Conclusion and Future Work

This paper introduced FlockHocNet, a reactive VANET routing protocol that translates local flocking principles into relay-selection quality. Cohesion, alignment, and separation are defined as normalized one-hop metrics derived from vehicle position and velocity, combined into $F_{ij}$, propagated as a weakest-hop path quantity, and incorporated into both RREQ forwarding priority and candidate route scoring. The routing design complements this biological layer with QoS scoring, provisional fast replies, guarded risk-aware backups, link-layer failure feedback, constant-velocity LET prediction, and two-hop repair. A key methodological distinction is maintained throughout: LET and route-repair logic are predictive networking mechanisms and are not presented as biological rules.

Across 600 paired ns-3.46.1 runs using SUMO-generated mobility on two Montreal OSM road graphs, FlockHocNet’s benefit increases with network density. In the 100-vehicle Decarie/highway case, mean PDR improves by 8.04% relative to AODV; in the 100-vehicle downtown/urban case, the improvement is 17.98%. At the same urban density, normalized routing load decreases by 58.28%, suggesting that better route continuity can eventually compensate for the protocol’s richer control plane. Conversely, sparse cases show little or no PDR advantage and markedly higher NRL. FlockHocNet should therefore be viewed as an adaptive stability-oriented protocol whose value depends on having sufficient local relay diversity, not as a universally superior replacement for AODV under all connectivity regimes.

Future work should first perform the already supported ablations: Full versus no-bio, no-cohesion, no-alignment, no-separation, no-fast-RREP, no-backup, and no-two-hop-repair, using exactly paired mobility and application conditions. The current SUMO/OSM methodology should then be broadened to additional urban, highway, and mixed road graphs, wider density and speed ranges, varying offered loads, larger populations, and empirical vehicle trajectories where available. Propagation should include fading, shadowing, blockage, and direct PHY/MAC link-quality measurements. Comparisons should include at least one current geographic or mobility/stability-aware baseline in addition to AODV. Finally, route lifetime, route-discovery frequency, link-break frequency, backup promotion, repair success, and route-switch frequency should be instrumented directly so that improvements in application PDR can be linked quantitatively to the protocol mechanisms that produce them.