The standard RPL protocol defines two primary objective functions: OF0 [15], which uses hop count as the sole routing metric, and MRHOF [13], which employs a rank-based approach combining hop count with link quality (ETX). While MRHOF represents an improvement over OF0 by incorporating link reliability, both approaches remain limited in their ability to address the multifaceted challenges of IoT routing. The first attempts to optimize RPL extended the simple hop count metric by adding energy considerations. For instance, Touzene et al. [16] suggested an energy-aware objective function that takes energy consumption into account during routing, which helps prolong the network lifetime in constrained environments. Their results indicated that even a single additional metric can improve performance compared to OF0, although such approaches are naturally limited by the trade-offs of optimizing only one extra factor.

Following this idea, Mishra et al. [17] proposed Eha-RPL, a system that combines energy, hop count, and link quality metrics in a composite objective function. This dual-metric approach performed better than single-metric methods, improving both reliability and efficiency. However, its effectiveness was hindered by the lack of systematic weight tuning and metric normalization. These early studies show that while combining metrics can help, balancing them without a structured framework remains a challenge.

It soon became clear that energy efficiency alone was not enough, especially for dense IoT networks. This led researchers to focus on load balancing and congestion control. Rana et al. [18] introduced the Enhanced Balancing Objective Function (EBOF), which aims to distribute traffic more evenly to reduce congestion and increase delivery rates. Similarly, Seyfollahi and Ghaffari [19] proposed a lightweight method that shortens routes while spreading the traffic load across nodes, thus saving energy and avoiding overused nodes.

Homaei et al. contributed two notable approaches in this area. Their LA-RPL method [2] uses Learning Automata to dynamically balance child nodes and reduce congestion through distributed data aggregation. Later, their CCFDM approach [10] applied a fuzzy decision system to 6LoWPAN protocols, controlling congestion by distributing traffic intelligently and using back-pressure mechanisms to detect problems quickly. Moving from static load balancing to these dynamic approaches was an important step forward, although these methods mostly react to congestion rather than anticipate it.

The use of AI and ML in RPL allows more adaptive routing. Homaei et al. [20] proposed DDSLA-RPL, using Learning Automata to select parents based on hop count, link quality, and energy. It can change the weight of these metrics dynamically, showing AI’s potential for flexible RPL optimization. Reinforcement learning is also applied. Zahedy et al. [21] developed RI-RPL with Q-learning in three steps: aligning routers, adapting parents, and improving performance with convergence adjustments, enhancing routing and stability. Similarly, Duenas Santos et al. [22] used Q-learning in Q-RPL for efficient smart grid routing.

However, AI methods have limits. They need more computation and data than small IoT devices provide and may fail in new networks with little past data.

As IoT applications expand into time-sensitive and mobile scenarios, RPL variants have increasingly focused on Quality of Service (QoS) requirements and mobility patterns. Hassani et al. [23] introduced FTC-OF, which uses traffic forwarding history to make more informed routing decisions, improving packet delivery ratios and reducing delays in latency-sensitive applications.

For high-traffic environments, Kaviani and Soltanaghaei [24] proposed CQARPL, a congestion- and QoS-aware RPL variant that integrates QoS metrics with congestion control tailored to dense traffic conditions. In mobile IoT networks, Jagir Hussain and Roopa [25] developed BE-RPL, combining energy efficiency with mobility awareness by monitoring RSSI and performing reactive parent selection. Idrees and Witwit [26] approached the problem from another angle, simultaneously focusing on energy efficiency and load balancing. Their method uses advanced load distribution to avoid network hotspots and ensure uniform energy consumption, while also incorporating link stability metrics to maintain consistent routing performance.

The latest trend in RPL research applies metaheuristic and nature-inspired algorithms to handle the multi-objective challenges of IoT routing. Prajapati et al. [27] proposed a Tabu Search-based parent selection strategy, integrating ETX, residual energy, and hop count. Although closely related to TABURPL, their method overlooks link stability and distance metrics, and it does not normalize different metrics, which can cause imbalance when metrics are on different scales.

Gurav et al. [28] introduced a Chimp Sine Cosine Algorithm for multi-objective optimization, using a four-phase process that jointly considers energy, link stability, and overall network performance. Similarly, Mokrani et al. [29] presented LEA-RPL, which combines energy-aware routing with lightweight mechanisms by leveraging Particle Swarm Optimization and enhancing parent selection through a hybrid of Long Short-Term Memory and Online Gradient Descent.

Recent research also explores RPL optimizations for domain-specific IoT scenarios. Tarif et al. [6] focused on underwater IoT networks, designing dynamic decision-making and fuzzy logic-based routing strategies. These studies highlight that specialized applications often require tailored optimization methods, as generic RPL variants may fail to meet the unique constraints of specific environments.

Despite significant progress in RPL optimization, as summarized in Table 1. First, many multi-metric approaches either lack systematic normalization [27] or fail to incorporate a complete set of metrics that account for both energy efficiency and link stability [17,26]. Second, AI-based solutions [20,21] often require considerable computational resources, making them impractical for resource-limited IoT nodes. Third, most metaheuristic techniques [28,29] rely on distributed optimization, which can increase both system complexity and communication overhead.

TABURPL is designed to address these limitations through four main innovations: 1.

A comprehensive six-metric composite cost function, with online min–max normalization to ensure balanced metric contribution;

Together, these features position TABURPL as the first metaheuristic-based RPL optimization approach that combines extensive metric coverage, systematic normalization, and practical applicability for resource-constrained IoT deployments.

The success of the optimisation mechanism that TABURPL adopts is based on the careful selection and definition of routing metrics that are able to capture the important characteristics of the performance of an Internet of Things (IoT) network. For the purpose of achieving a full evaluation of routing options, our technique incorporates a number of complementing measures that jointly address energy efficiency, connection dependability, and network connectivity characteristics. Each measure provides its own distinct information regarding the current status of the network, which enables the TS algorithm to make well-informed decisions regarding the selection of the most suitable parent nodes inside the DODAG structure. TABURPL relies on six link- or path-level metrics:

Residual Energy (Er)—remaining battery energy at the transmitting node.

Detailed definition of Ls: For every directed link e=(u→v) we keep an exponentially-weighted moving average (EWMA): (1)Ls(e,t)=αLs(e,t−Δt)+(1−α)ACKuv(t;W)TXuv(t;W),0≤Ls≤1where TXuv and ACKuv are, respectively, the numbers of data frames transmitted and MAC acknowledgments received during the latest sliding window of W=32 frames (RFC6550 guideline). We set α=0.75 (EWMA half-life ≈22 frames) and quantize the result in a single byte: (2)Lsbyte=⌊256Ls⌋

The metric is computed locally by each node; the only modification to the NS-2.34 RPL agent is a one-byte field added to each neighbor-table entry, so no extra timers or control logic are introduced.

The main idea of TABURPL is the use of a cost functional that can evaluate many routing factors at the same time. In most traditional RPL, only one or two metrics are used. This can give weak routing choices because it favors some factors but ignores others. In our method, we make a cost function with many dimensions. This function tries to keep balance between energy use, link reliability, network connectivity, and path quality in one single formula. With this wider view, the TS algorithm can search for routing solutions that give better performance in different IoT network settings.

We represent the network topology as a directed graph G=(V,E), where V is the set of nodes and E is the set of directed edges for communication links. For a routing path P⊂G, the optimality cost functional C(P) is written as a weighted sum of important metrics: (3)Craw(P)=∑e∈P(λ11Er(e)+λ2Et(e)+λ3d(e)+λ4h(e)+λ5ETX(e)+λ61Ls(e)) (4)Cnorm(P)=∑e∈P∑i=16λif~i(e)

here, e∈P is one edge on the path P, and each term is one routing metric. The weights λ1,…,λ6 give control over how important each metric is, so the function can be changed to match different network goals and application needs.

Metric Definitions:

Er(e): Residual energy at the sending node of edge e. This is used in inverse form so that paths with more energy are preferred. It helps share energy load and makes the network last longer.

The choice of weights is very important, since they decide which network features will be preferred. All weights are positive numbers, λi∈R+ for i=1,…,6. For example, in energy-sensitive networks, larger values can be given to λ1 and λ2. In delay-sensitive cases, higher values can be given to λ4 and λ6. To make sure the evaluation is fair across all metrics and no single one dominates, the weights are normalized. (5)∑i=16λi=1

The normalization constraint serves several important purposes. Primarily, it prevents any single metric from dominating the cost function C(P) simply due to its numerical scale, ensuring that all metrics contribute proportionally. It also provides a consistent reference scale, allowing performance to be evaluated reliably across different network setups and deployment scenarios. Moreover, normalization enables systematic tuning of the weights λ, making it possible to prioritize certain metrics when necessary while keeping the optimization process mathematically stable and easy to interpret.

Optimal Path Selection:

Selecting a routing path can be viewed as an optimization problem, where the objective is to identify the path P∗ that minimizes the cost function C(P) among all feasible paths: (6)P∗=arg⁡minP⊂GC(P)

In this formulation, P∗ represents the optimal path that achieves the lowest cost, reflecting the most energy-efficient, stable, and reliable routing choice according to the defined composite metrics. This framework naturally captures the trade-offs among multiple performance criteria, including energy consumption, link reliability, and hop count, which are closely interrelated in IoT networks. Furthermore, the multi-dimensional cost function C(P) can adapt to evolving network conditions and varying application requirements, allowing routing decisions to remain effective and flexible over time. The approach is based on multi-objective optimization, where the scalar cost C(P) combines several competing objectives using weighted sums. As a result, the selected path P∗ from Eq. (6) can be seen as a Pareto-optimal solution. This means there is no other feasible path that can improve one objective without making at least one other worse. This guarantees that the chosen route achieves a balanced trade-off among all metrics.

In practice, solving this optimization problem often requires heuristic or metaheuristic algorithms. Methods such as Tabu Search or Genetic Algorithms are suitable because they can explore complex, high-dimensional, and possibly non-convex solution spaces. These algorithms evaluate candidate paths using C(P) and use memory structures or evolutionary operations to avoid local minima and approach a global optimum. So, the proposed optimality cost functional provides a clear and flexible foundation for IoT routing. It allows dynamic route selection that balances multiple performance goals and adapts to network changes. This approach captures the essential trade-offs in IoT networks while ensuring that the chosen path is efficient, reliable, and resilient.

In a Low-power and Lossy Network (LLN), the routing choice is always discrete: a path P is an ordered subset of edges in the directed graph G=(V,E). Routing differs from continuous optimisation since decision variables can only take certain discrete values. Moreover, each path has a specific order of network links, resulting in a solution space that is finite but grows exponentially with the network size and connectivity.

The edge-level cost elements in Eq. (3) (e.g., Et(e),ETX(e),h(e)) are individually convex when considered in their own continuous domains. However, the aggregation of these metrics over complete multi-hop paths introduces complex interdependencies, making the overall search space combinatorial and generally non-convex. Consequently, classical convex-optimization guarantees (e.g., uniqueness of a global minimum) do not apply. Gradient-based and analytical methods relying on convexity become ineffective, necessitating alternative approaches. Therefore, the problem is reformulated as a multi-objective combinatorial optimisation problem, solved via a meta-heuristic TS to discover near-Pareto-optimal solutions.

The six metrics in the composite functional C(P) have different physical units (Joules, metres, dimensionless ratios), creating significant challenges for fair aggregation in the optimization process. To prevent a single metric from dominating the objective function and overshadowing the contributions of other equally important performance indicators, we apply min-max normalisation prior to weighting. This ensures that all metrics, regardless of their original scales or units, have a real impact on the routing decision. (7)f~i(e)=fi(e)−fiminfimax−fimin,i∈{1,…,6}where fimin and fimax are the minimum and maximum observed values of the metric fi in the current network topology snapshot. These boundary values are calculated dynamically according to the current network state. This allows the normalization to adapt to changing conditions and ensures that the full range [0,1] is effectively used across different operational scenarios.

After normalization, the raw metrics fi(e) are replaced by f~i(e) in the weighted sum given by Eq. (4). The normalisation process transforms metrics with vastly different ranges—such as energy consumption measured in millijoules and hop counts measured as integers—into a uniform scale that enables meaningful comparison and aggregation.

This scaling method ensures that each metric contributes to the cost function in a proportional manner on a 0 to 1 scale, preventing any single metric from dominating purely due to numeric range. The user-defined weight vector λ captures high-level policy preferences (e.g., reliability vs. energy efficiency), allowing network operators to express their strategic goals while ensuring these choices are implemented equitably across all normalised measures. The combination of normalisation and weighting provides both technical correctness in the mathematical aggregation and practical flexibility in expressing routing policies.

The weights λ were determined using a systematic two-stage procedure, designed to explore the weight space and identify configurations that provide the best multi-objective performance across different routing scenarios in LLNs.

Stage 1: Coarse Grid Search

Dirichlet sampling with parameter α=1 was used to generate 150 weight vectors on the 6-simplex. This ensured an even coverage of the possible weight space, without favoring any particular objective, while maintaining the constraint ∑i=16λi=1. From these, the ten vectors that maximized the hyper-volume of the Pareto front were selected for further analysis. The hyper-volume metric provides a robust measure of solution quality in multi-objective optimisation, reflecting both proximity to the true Pareto front and diversity across objectives.

Stage 2: Fine Tuning

The best vector from Stage 1 was perturbed with Gaussian noise (σ=0.03) in a controlled manner to explore the local neighbourhood while staying close to the original configuration. Each perturbed vector was re-normalised to satisfy the simplex constraint. A total of 50 candidate vectors were evaluated under identical test conditions, selecting the one with the highest geometric mean of normalised PDR and inverse Energy. The geometric mean provides a balanced assessment preventing either metric from dominating, while the inverse energy term emphasises energy efficiency—a critical concern in resource-constrained IoT environments.

The final weight vector: (8)λ∗=(0.18,0.22,0.12,0.08,0.25,0.15)represents the culmination of this systematic calibration process, prioritising the most impactful performance indicators while maintaining adequate representation for secondary objectives. This configuration is maintained fixed throughout all experiments to eliminate potential confounding effects from adaptive weight selection during performance evaluation.

Including both Euclidean distance d and Hop Count h has been criticised as redundant for static deployments because, under an ideal disc-radio model, the two are strictly monotone. However, real LLNs exhibit radio irregularity, anisotropic path loss, and obstacles, so a short physical link does not necessarily translate into a single hop, and vice versa. We therefore quantified the statistical dependence between the two metrics.

For the 50-node baseline topology, we logged ⟨d(e),h(e)⟩ for every edge over 100 snapshot periods (9000 samples). The Pearson correlation coefficient is ρd,h=0.63 (95% CI: 0.61–0.65)—moderate, but far from the ρ≈0.95 expected under an ideal model. When replayed with log-normal shadowing radio (σsh=4 dB), the correlation dropped to 0.41.

Ablation Experiment:

We re-optimized the weight vector λ in three settings (Table 3):

Removing either metric degrades at least one key KPI statistically significantly (p<0.01). The effect is small but systematic, confirming that d and h capture different aspects of link quality: distance relates to radio energy cost while hop count affects queuing and MAC back-off delay. Consequently, we keep both terms, with their relative impact balanced by the learned weights (λ3=0.12, λ4=0.08).

Practical Note:

Distance d is only known at the root from node coordinates or RSSI trilateration, so it does not increase on-mote storage. Hop Count h remains locally computable, introducing no additional control-plane bytes.

For each directed link e=(u,v), the Link–Stability Rate is defined as an exponentially-weighted moving average (EWMA): (11)Ls(e,t)=βLs(e,t−1)+(1−β)1ACK,β=0.75,Ls(e,0)=0.5where 1ACK=1 if the unicast transmission from u to v at time t is acknowledged at the MAC layer. With default NS2.34 queue length (8 frames), this β gives an effective window of ≈32 packets—close to the value recommended in RFC 6551 for the LL-LSP metric.

NS2.34 already computes the same EWMA internally to derive ETX. When the RPL stack is built with #define RPL_WITH_METRICS 1, the per-link statistic is periodically exported inside a Metric Container option of type 0x04 (Link-Layer Link Success Probability, LL-LSP) that is fully specified in RFC 6551 and thus ignored gracefully by OF0.

Piggy-back Mechanism:

One-byte fixed-point LL-LSP values (range 0–255) are attached to DAO messages; this adds exactly β× neighbours to each snapshot, already counted in Section 3.9. At the root, values are rescaled to Ls∈[0,1] and used in the composite cost. If the option is absent (legacy mote), the root falls back to ETX-derived success probability Ls≈1/ETX, ensuring backward compatibility.

Numerical Range:

Because Ls∈[0,1], we safely invert it in Eq. (4); to avoid division by zero we clamp Ls≥0.05, mirroring the Er safeguard used in Section 3.7.

Each snapshot message includes the tuple ⟨nbrID,ETX,Er,Ls⟩ for up to k=6 neighbors. The fixed header is 18 B, and each neighbor adds 6 B, so the total snapshot size is: (13)Bsnap=N(18+6k)=50×(18+6×6)=2400 B≈19,200 bits

The per-bit radio cost is based on CC2538 parameters used by the 802.15.4 PHY model in NS-2.34 (Table 4):

(14)Etx(bit)=ItxVbatRbit=24.0×10−3×3.0250×103≈288 nJ/bit (15)Erx(bit)=IrxVbatRbit=20.0×10−3×3.0250×103≈240 nJ/bit

Each node transmits one snapshot and receives k snapshots from its neighbors. The energy per node per snapshot is calculated as: (16)Ectrl=Bsnap⋅(Etx(bit)+k⋅Erx(bit))=19200⋅(288+6×240)×10−9 J≈33.2 mJ

With the initial battery set to E0=1000 J, this overhead corresponds to: (17)EctrlE0×100≈3.32% every 90 s

Post-Processing Methodology Justification:

NS-2.34’s energy model tracks battery consumption only when packets reach the MAC layer, requiring post-processing to account for control overhead. While this approach does not capture per-packet MAC retransmissions, it provides a methodologically sound and conservative lower bound estimate for three key reasons: 1.

Deterministic overhead: Control message size and transmission schedule are known a priori from protocol specifications, enabling accurate energy calculation using validated hardware parameters (Table 4).

Implementation Details:

In NS-2.34, battery energy is reduced only when a Packet object reaches the MAC layer. Therefore, DAO/DIO piggyback bytes are ignored by default. We account for this in post-processing to correctly inject the snapshot energy cost into the simulation trace.

After each simulation, the standard *.tr file is processed using the AWK script add_ctrl_energy.awk.

This calculation provides a lower bound estimate of control overhead, as the post-processing approach does not capture MAC-layer retransmissions due to collisions or channel contention. Based on empirical observations of 802.15.4behavior in dense networks (typically 10%–15% collision rate under moderate traffic [31]), the actual overhead may be 1.1–1.2× higher than the computed value. Nevertheless, even accounting for this factor, total control overhead remains below 0.09% of total energy consumption, which is negligible compared to data transmission costs and well within acceptable bounds for IoT deployments.

In Algorithm 1, we present the complete TABURPL procedure that systematically explores the solution space using TS to identify optimal parent-child relationships in the DODAG structure.

The generateneighbours function evaluates potential parent switches for each node i in the DODAG. For a node with current parent p, we consider all nodes j within transmission range that satisfy three critical constraints:

Loop prevention: Node j must be closer to the sink than i, measured by rank or hop count, ensuring acyclic routing topology.

Transmission range is determined by RSSI threshold of −85 dBm, typical for 802.15.4 radios. In practice, each node has 3–8 candidate parents, yielding |𝒩|≈150−400 routing configurations per iteration for a 50-node network. The tabu tenure L=30 was determined empirically: values L<20 caused cycling, while L>40 restricted exploration without improving convergence.

The diversity function measures solution dissimilarity using normalized Hamming distance:(18)diversity(S1,S2)=1N∑i=1N⊮[parenti(S1)≠parenti(S2)]where ⊮[⋅] is the indicator function and N is the number of nodes. A solution is considered sufficiently diverse if diversity(Scandidate,Srecent)>0.15 (i.e., at least 15% of parent assignments differ), preventing premature convergence to similar routing topologies.

To show how the proposed TS-based routing optimization works, consider a simple network with six nodes, where the source node (Node 1) has three possible paths to the sink node. The cost of each path is calculated using the composite cost functional 𝒞(P) defined in Eq. (4), which uses normalized metrics for energy, reliability, and network performance.

For example, available routing paths:

Path A: Node 1 → Node 2 → Node 3 → Sink, CA=15

At the start, Path A is chosen as the initial solution. In the first TS iteration, the algorithm evaluates all neighboring solutions, which are paths that differ by one edge. Path B has the lowest cost (CB=0.72), so it becomes the new current solution. Path A is added to the Tabu List with a tenure of L=30 iterations to prevent immediate cycling.

The search continues around Path B. The algorithm may accept Path C or other modifications if the aspiration criteria are met, for example, when the cost improves beyond a predefined threshold. Iterations continue until one of the convergence criteria is reached: maximum iterations (Imax), Istall consecutive iterations without improvement, or achieving the aspiration threshold. Finally, Path B is selected as the optimal route, showing how the TS algorithm balances energy efficiency, connection reliability, and hop count.

Table 6 shows the setup we used for our NS-2.34 simulations. We chose these characteristics to show what it’s really like to deploy IoT devices, with a focus on limited energy, spotty connectivity, and changing traffic loads. We wanted to see how well TABURPL worked in situations that are common in large sensor networks and compare it against five RPL-based protocols: OF0, MRHOF (RPL), DDSLA-RPL, FTC-OF, CQARPL, and Tabu-RPL.

We use eight key metrics to evaluate protocol behavior across multiple traffic levels and network sizes [33,34]:

Packet Delivery Ratio (PDR):(19)PDR=PreceivedPsentwhere Psent is the total number of packets transmitted by source nodes, and Preceived is the number of packets successfully received at the sink [31].

The PDR shows how many packets successfully reach their destination compared to the total packets sent (Eq. (19)). Fig. 2 shows PDR results for networks with 50, 100, and 200 nodes under different traffic loads.

TABURPL performs better than all other protocols in every test scenario. In the 50-node network (left), TABURPL achieves 95.7% PDR under low traffic and 92.0% under high traffic. The baseline OF0 protocol only reaches 81.2% and 75.3%, respectively, showing TABURPL improves performance by about 18% to 22%.

When we test larger networks with 100 nodes (middle), TABURPL maintains strong performance with 94.2% to 90.4% PDR. OF0 drops significantly to 72.8% under high traffic, while TABURPL stays consistently better by 19% to 24%.

The most challenging test uses 200 nodes (right). Even here, TABURPL delivers 92.1% to 88.2% PDR while OF0 falls to 69.9% under heavy traffic. TABURPL also outperforms other advanced protocols like DDSLA-RPL, FTC-OF, CQARPL, and Tabu-RPL. Paired t-tests confirm that TABURPL’s improvements over OF0 are statistically significant across all scenarios (p<0.001, 95% CI shown in error bars).

TABURPL works well because it uses Tabu Search to find the best routing paths. The algorithm considers link stability, energy efficiency, and transmission reliability together. This helps avoid congested or unreliable network areas. While all protocols perform worse as traffic increases, TABURPL handles the load much better and keeps PDR above 88% even in the hardest conditions. This makes it suitable for important IoT applications that need reliable data delivery.

This section analyzes how much energy different RPL protocols use across various network sizes and traffic loads. Fig. 3 shows the average energy consumed per node (measured in joules) under low (2 pkt/sec), medium (5 pkt/sec), and high (10 pkt/sec) traffic conditions.

TABURPL uses less energy than all other protocols in every test scenario. The Tabu Search optimization helps the protocol choose more efficient and stable paths, which reduces retransmissions and control message overhead. In the 50-node network (left), TABURPL consumes only 1.5 J under low traffic and 1.9 J under high traffic. The baseline OF0 protocol uses much more energy with 2.8 and 3.7 J, respectively. One-way ANOVA shows significant differences among protocols (F(6,203)=127.4, p<0.001), with post-hoc tests confirming TABURPL’s superiority (p<0.001 for all pairwise comparisons).

The same pattern continues as networks get larger. In the 100-node network (middle), TABURPL uses 1.7 to 2.1 J while OF0 consumes 3.1 to 4.0 J. For the largest 200-node network (right), TABURPL needs only 2.1 to 2.5 J compared to OF0’s 3.6 to 4.5 J. An important finding is how energy consumption changes with traffic load. TABURPL’s energy use increases by only 0.4 J from low to high traffic, while other protocols increase by 0.8 to 1.2 J. This shows TABURPL handles traffic growth much more efficiently.

Furthermore, the analysis of node-level energy distribution reveals that TABURPL prevents the formation of energy hotspots. In OF0 and MRHOF, nodes closer to the sink tend to deplete their battery 2.5× faster than leaf nodes due to the funneling effect. In contrast, TABURPL exhibits a more uniform energy drain across the network, with the standard deviation of residual energy being approximately 40% lower than that of the baseline protocols. This load-balancing capability ensures that the first-node-death event is significantly delayed, thereby extending the functional lifetime of the entire network.

Fig. 4 shows the average hop count that data packets need to reach the sink under different traffic loads (2, 5, and 10 pkt/sec) and network sizes (50, 100, and 200 nodes). TABURPL consistently achieves the shortest path lengths among all protocols, even when traffic increases.

In the 50-node network (left), TABURPL uses an average of 3.2 hops under low traffic and increases moderately to 4.1 hops under high traffic. The baseline OF0 protocol starts at 4.3 hops and reaches 5.2 hops under the same conditions. This pattern continues in larger networks: TABURPL maintains 3.4–4.3 hops in the 100-node network (middle) compared to OF0’s 4.5–5.5 hops, and 3.6–4.5 hops in the 200-node network (right) vs. OF0’s 4.7–5.8 hops.

TABURPL achieves these shorter paths through its Tabu Search mechanism, which finds efficient routes while avoiding congested and unstable links. Unlike traditional RPL protocols that sometimes choose longer paths to save energy, TABURPL does something interesting: it reduces both energy consumption and hop count at the same time. This shows the optimization algorithm effectively avoids unnecessary detours while selecting reliable forwarding nodes.

The results demonstrate that smarter routing doesn’t always mean longer paths. TABURPL’s ability to balance route length with stability and energy efficiency leads to better overall performance. This contributes to its superior results in both energy savings and packet delivery across all network conditions.

Routing control overhead measures how many control messages (like DIO, DAO, DIS) protocols exchange to establish routes, maintain connections, and select parent nodes. Fig. 5 shows the average control traffic generated per minute (in bytes) for each protocol under different network sizes and traffic loads. TABURPL consistently produces the lowest control overhead in all scenarios.

In the 50-node network (left), TABURPL reduces control traffic significantly compared to OF0. While OF0 generates 465–585 bytes/min, TABURPL only produces 310–380 bytes/min. This advantage continues in larger networks. For the 100-node network (middle), TABURPL generates 330 bytes/min under low traffic and increases modestly to 400 bytes/min under high traffic, compared to OF0’s 495–620 bytes/min. In the largest 200-node network (right), TABURPL maintains the most efficient performance with only 350–420 bytes/min vs. OF0’s 535–670 bytes/min.

The Tabu Search mechanism helps TABURPL achieve this reduction by quickly finding optimal or near-optimal paths. This means fewer route rediscoveries and less control packet generation. Other protocols like OF0 and DDSLA-RPL need more frequent route updates when links change, which creates higher overhead.

Lower control messaging helps TABURPL in several ways: it reduces network congestion, saves energy, and improves channel utilization. These benefits are particularly important for IoT deployments where bandwidth is limited and energy efficiency is crucial.

End-to-End Delay (E2ED) measures the average time (in milliseconds) for a data packet to travel from the source node to the sink. This is an important metric for time-sensitive IoT applications (see Eq. (23)). Fig. 6 presents the delay results across different traffic loads and network sizes. TABURPL consistently achieves the lowest E2ED in all scenarios.

In the 50-node network (left), TABURPL records delays ranging from 140 ms under low traffic to 185 ms under high traffic, while OF0 ranges from 235 to 295 ms. This pattern continues in the 100-node network (middle), where TABURPL maintains delays between 155 and 200 ms, significantly outperforming OF0, which reaches 320 ms under high traffic. The same trend appears in the 200-node network (right), where TABURPL reaches a maximum of 220 ms, much lower than OF0’s 350 ms.

The Tabu Search optimization at the DODAG root reduces delay by selecting low-congestion and stable routes that minimize retransmissions and MAC-layer back-offs. Compared to OF0, TABURPL lowers delay by about 25%–35% under all conditions. The improvement is statistically significant (paired t-test, p<0.001) with large effect sizes (d=1.89–2.15, Cohen’s d). Although some protocols reach similar path lengths, their higher delays reveal instability or congestion during route selection, which TABURPL avoids through its intelligent search strategy.

The per-hop delay is calculated as:(27)Thop=(TTx_End−TTx_Start)−Tairwhere Thop is the per-hop delay, TTx_Start and TTx_End denote the start and end of the transmission window, and Tair is the physical propagation delay.

These results show that TABURPL’s intelligent routing decisions lead to faster data delivery, making it suitable for IoT applications that require quick response times.

Packet Loss Ratio (PLR) measures network reliability by showing the percentage of packets that fail to reach their destination (see Eq. (24)). Fig. 7 illustrates the PLR for all evaluated protocols under different traffic loads and network sizes. TABURPL consistently achieves the lowest packet loss across all scenarios.

In the 50-node network (left), TABURPL reduces packet loss to 4.3% under low traffic and 8.0% under high traffic, while OF0 experiences much higher losses of 18.8% to 24.7% under the same conditions. At 100 nodes (middle), TABURPL maintains its advantage with packet loss ranging from 5.8% to 9.6%, compared to 21.1% to 27.2% for OF0. In the 200-node network (right), TABURPL achieves 7.9% loss under low traffic and 11.8% under high traffic, significantly outperforming all other protocols, including DDSLA-RPL and FTC-OF.

The Tabu Search optimization mechanism helps TABURPL avoid unstable or lossy links during parent selection. The protocol chooses routes that are both energy-efficient and reliable, which reduces retransmissions and improves delivery success rates. Overall, TABURPL reduces packet loss by more than 50% compared to the baseline OF0, making it highly suitable for critical IoT applications that require consistent data delivery.

Throughput measures the rate of successful data delivery in the network, expressed in kilobits per second (kbps) (see Eq. (25)). Fig. 8 illustrates the throughput performance of all evaluated protocols. TABURPL consistently achieves the highest throughput across all network sizes and traffic conditions.

In the 50-node network (left), TABURPL achieves throughput ranging from 41.97 kbps under low traffic to 43.93 kbps under high traffic, significantly outperforming OF0, which delivers only 31.52–33.28 kbps. This trend continues as networks get larger: in the 100-node scenario (middle), TABURPL reaches 42.18– 44.38 kbps compared to OF0’s 31.68–33.65 kbps. For the largest 200-node network (right), TABURPL achieves 42.63–44.72 kbps, while OF0 caps at 31.95–34.10 kbps.

TABURPL’s superior throughput comes from its ability to maintain stable, energy-efficient paths and minimize packet loss, as shown in the PLR and delay analyses. The Tabu Search mechanism improves performance by intelligently selecting optimal routes with minimal congestion and fewer retransmissions. These results demonstrate that TABURPL significantly improves network capacity and data delivery efficiency, making it highly suitable for bandwidth-sensitive and real-time IoT applications.

LSR measures how consistent and reliable data transmissions are between nodes, computed according to Eq. (26), with values ranging from 0 to 1. Fig. 9 shows how different traffic loads and network sizes affect LSR. TABURPL consistently outperforms all other protocols across all scenarios.

In the 50-node network under low traffic (left), TABURPL achieves the highest stability of 0.86, while the baseline OF0 reaches only 0.71. As networks get larger and traffic increases, all protocols show lower stability, but TABURPL maintains its advantage. In the 100-node network (middle), TABURPL achieves 0.82 to 0.70 compared to OF0’s 0.65 to 0.52. Even under the most challenging conditions with 200 nodes and high traffic (right), TABURPL maintains acceptable stability at 0.63, while OF0 drops significantly to 0.45.

This degradation pattern makes sense: as network density and traffic increase, nodes compete more for the wireless channel, leading to more collisions and reducing transmission reliability. However, TABURPL handles these challenges much better than other protocols.

TABURPL’s Tabu Search-driven parent selection helps by choosing routes with historically higher delivery rates and fewer retransmissions. The algorithm learns from past performance and avoids unstable links. These results show that TABURPL provides robust and adaptive routing that maintains high link stability even under challenging IoT conditions.

This section shows statistical validation of TABURPL performance using confidence intervals, significance testing, and sensitivity analysis. All experiments used 30 independent runs with different random seeds. Results are reported as mean ± 95% confidence interval. We used paired t-tests for comparing protocols and one-way ANOVA for multi-protocol analysis.

Table 7 summarizes the statistical results for key performance metrics in the 100-node, medium traffic scenario. The ANOVA F-statistic for PDR shows F(5,174)=89.23 with p<0.001, indicating significant differences among protocols. Post-hoc Tukey HSD confirms that TABURPL significantly outperforms all protocols (p<0.001).

We tested TABURPL’s robustness by changing each weight parameter by ±20% while keeping the total sum equal to 1. Table 8 shows the sensitivity analysis results. ETX (λ5) and Link Stability (λ6) show the highest sensitivity with indices of 0.160 and 0.135, respectively. Despite these changes, all configurations maintain PDR above 90%, showing the algorithm is robust. Performance changes stay within acceptable limits, less than 4% across all weight variations.

We tested TABURPL across different network layouts: random distribution, grid topology, and clustered topology. The protocol achieved PDR improvements of 16.7% ± 2.1%, 18.2% ± 2.3%, and 15.4% ± 2.5%, respectively, compared to OF0. We also tested different traffic patterns and found TABURPL maintains superior performance with low variation (coefficient of variation below 0.15).

Convergence analysis of 100 optimization runs shows average convergence time of 87.3 ± 12.4 iterations, with 94% converging before iteration 120. The algorithm produces consistent results with low variance (σ2=0.0031). Statistical power analysis shows we can detect 5% PDR differences with 95% confidence and 10% energy differences with 99% confidence.

Despite these advantages, the centralized nature of TABURPL introduces specific scalability and applicability limits. While the protocol performs robustly up to 200 nodes, in extremely large-scale networks (e.g., >1000 nodes), the computational time at the root may exceed the snapshot period, necessitating a hierarchical or distributed approach. Additionally, regarding dynamic topologies, the 90-s optimization cycle is designed for low-mobility scenarios (e.g., environmental monitoring). In highly dynamic environments where link quality changes rapidly (coherence time <10 s), the global optimization might lag behind the physical reality, leading to temporary suboptimal routing. For such cases, a hybrid mechanism combining global TS optimization with local reactive repair would be required.