Zainab Abbas Fadhil (1)
General Background Wireless Sensor Networks (WSNs) remain a foundational technology for Internet of Things (IoT) deployments, offering capabilities for distributed sensing, localized data collection, and multihop communication toward edge gateways or sinks. Specific Background Routing layers within WSN designs dictate packet delivery ratios, end-to-end delays, energy consumption, network congestion, and overall operational lifetimes. Knowledge Gap Traditional routing models often rely on minimum hop counts or simplistic shortest-path metrics, which can cause early battery depletion on near-sink relay nodes and ignore dynamic wireless link variability. Aims This study introduces a computer-engineering framework designed to optimize routing protocols for WSN-based IoT systems through a novel Energy and Link-Quality Aware Routing (ELQAR) model. Results Simulation experiments demonstrate that the ELQAR framework achieves higher packet delivery ratio stability under dense node distributions, mitigates delay growth during heavy traffic loads, and extends network lifetime markers compared to baseline protocols. Novelty The approach combines remaining energy, expected transmission quality, forward hop progress, queue load, and route freshness into a unified next-hop selection score without requiring global topological information. Implications This framework provides a reproducible design and simulation environment that can be integrated into resource-constrained embedded nodes and gateway architectures to balance reliability, energy efficiency, and latency.
Key Findings Highlights
The ELQAR routing model combines residual energy, link quality, forward progress, queue state, and stability into a single normalized score to select optimal next-hop parents.
Simulation results indicate that the optimized routing approach maintains superior packet delivery ratio stability as node densities increase from 25 to 150 nodes.
Network lifetime checkpoints show that the proposed framework extends operational rounds before initial node failure and total network depletion compared to shortest-hop, LEACH-style, and RPL-like routing approaches.
Keywords Wireless Sensor Networks, Internet Of Things, Routing Optimization, RPL, Energy-Aware Routing
This growing appetite for sensors has fueled significant demand for sensing networks that can sustain long operational lifetimes within a very restrictive operational space of small batteries, high node counts, and a volatile wireless link that offers only intermittent connectivity. Sensors are typically scattered over farms, industrial buildings, warehouses, bridges or natural environments. Each measures a physical variable and relays its resulting packet to a sink, typically either an on-premise gateway device, or cloud connectivity [1],[2],[3].
Routing is certainly not the second order component in WSNs. That is how we select the next hop that will transmit the data packet to the next relay. This also dictates the time spent in buffer, the number of transmissions and how much energy the network will spend transmitting packets.
In typical wired and infrastructure networks we are willing to optimize throughput or minimum path length. This should not be a consideration for the routing in WSNs since every forwarding decision alters the future state of the network. Energy, reliability, delay, and topological stability become primary constraints. Minimum hop routing sounds like a viable candidate since the shortest path from a given node to the sink, would be optimal, in many metrics. However, a route composed of a few close-to-sink nodes would cause early battery depletion.
These nodes would be working harder compared to their peers, thus a large portion of the WSN would suffer path loss even when nodes’ own batteries might not be depleted yet. Therefore, a route that has an increased number of hops may be more sustainable.
The IoT realm makes things more complicated still. We may encounter packets representing routine telemetry: for example, occasional readings of temperature or humidity. Other packets may be an alarm, an fault, anomalous vibration, or some abrupt change in the local conditions. It is therefore desirable for the routing protocol to facilitate both reliable, non-loss delivery for the regular traffic and non-intrusive delay-tolerant transport of the event driven packets, preserving all time stamps and sequence numbers so that late traffic does not cause false positive indications when it is delivered to the cloud dashboard.
In this document we present a model to apply routing optimization to IoT-WSNs. We consider our contribution to be a working and repeatable framework rather than a report on operational use. We present an example architecture, an example weighted metric for routing decisions, an example topology produced from the application of the model to that architecture, the specific assumptions that underpin the simulation, example performance metrics, steps towards validation of that simulation results, and consideration of implementation issues for embedded devices and the associated cloud connectivity.
An WSN-based IoT architecture is like a layered structure. The hardware that detects the signals is in the bottommost layer, with embedded controllers. Network routing and packet forward is in the second layer. This filtered and verified data is then collected and analyzed by the topmost layer where it is stored, displayed, trended, and converted into actionable alerts (see figure 1).
Figure 1.
Fig. 1. Layered IoT-WSN routing optimization architecture generated specifically for this study.
The diagram makes clear that routing sits between the physical work of detecting something, and the work at the application level of understanding what has been detected. If the routing layer breaks down, readings arrive at the dashboard as gaps, duplicates, delayed items or out of order things. Thus, a proper IoT-WSN system design must incorporate routing information as part of the quality chain.
Essential bits of routing metadata are parent, residual battery level, number of retransmits, when the route last changed, the size of the transmission queues, and the sequence number. A proper IoT system design needs to send the sequence number as part of every transmitted value to identify if some transmissions are missing.
The sink/gateway can’t just pass packets up to the cloud without processing them further. It must understand some bits of network health information too. For example, losing all readings from one section of a field could mean that something interesting happened, there was a problem with radio comms at that location, or one of the relay nodes is broken. The cloud layer needs information from routing in order to distinguish among these causes. Effective routing improves visibility.
Table 1. Main WSN routing families and their relevance to IoT environments.
Figure 2.
2.1. Routing Protocol Challenges
These are several difficulties encountered in routing over an IoT-WSN.1) Energy constraint: A typical sensor node consumes a lot of energy in transmission or reception of wireless signals. Several unnecessary retransmissions can have serious impact on node’s lifetime especially if that node is relaying traffic for some other nodes.2) Link variability: The performance of a low power wireless link is highly variable and depends on factors like distance, obstacles, orientation of antennae, interference, humidity and fading phenomena (like multipath fading). A node that has good link quality to one node at the moment can have weak link quality to the same neighbor a while later.
Thus, a routing protocol must rely on link quality estimation instead of assuming that the topology remains unchanged in a permanent basis.3) Congestion: When several nodes transmit data via a single relay, traffic becomes dense, delay becomes larger, and packet loss is increased.
Traffic usually converges to the sink, where the traffic density becomes highest and congestion becomes more severe. A sensible metric should then have some queue or load related metric.4) route stability: Frequent reconfigurations occur when the cost of a path becomes too high, due to frequent re-evaluation and switching of parent. Frequent changes increase the cost of overhead. They also increase reordering probability of received messages. Therefore a reliable routing protocol should change route only when the gain is big enough.
2.2. Baseline Protocols for Comparison
Table 2. Routing behaviours compared in the practical evaluation.
Protocol behaviourRouting principleStrengthWeakness
Shortest-hopChooses the path with the smallest number of hops.Low computational cost.May overload near-sink nodes and ignore weak links.
LEACH-styleForms clusters and rotates cluster-head responsibility.Improves aggregation and energy fairness.Cluster rotation may be unsuitable for all traffic patterns.
RPL-likeBuilds a destination-oriented graph using objective functions.Suitable for IPv6 low-power and lossy networks.Performance depends strongly on objective-function design.
Proposed ELQARUses energy, link quality, queue state, progress, and stability.Balances reliability, delay, and lifetime.Requires calibration and validation in the target deployment.
3.1. Design Objective
The proposed optimization scheme is named ELQAR, an acronym for Energy and Link-Quality Aware Routing. We want to find a next hop that is not just geographically close to the sink but also has high reliability, a reasonable amount of residual energy and is not congested at present. The criterion is kept simple to ensure that it can be executed on constrained micro-controllers without global topological information.
Every node holds a neighbor table which records, for each neighbor, a recent estimation of its link quality, its estimated transmission count, the estimated residual energy (if the neighbour advertises it), the current queue state of the neighbor, the number of hops progress towards the sink, and a value of stability of the neighbour's behavior over time. The scoring is updated at some regular intervals and upon receipt of link-quality indication messages.
3.2. Composite Routing Metric
The ELQAR score used in this study is expressed as a normalized weighted sum. The variables are scaled between 0 and 1 so that larger values indicate a better routing candidate:
RoutingScore(j) = 0.30Eres(j) + 0.25LQ(j) + 0.20Progress(j) + 0.15(1 - Queue(j)) + 0.10Stability(j)
In this equation, Eres is the residual-energy ratio for candidate neighbor j, LQ is the actual link quality measurement by the number of packet receptions over time, ETX, Progress is movement towards sink, Queue is normalized local queue pressure and Stability penalizes old unstable parents. The weights can be altered depending on different use-cases. A safe monitoring network will tend to favour delay whereas a long term farming network might favour the lifetime of the node energy.
Table 3. Variables used by the proposed routing metric.
Metric componentPractical meaningEngineering benefit
Residual energyRemaining battery capacity of the neighbor.Prevents early death of overloaded relay nodes.
Link quality / ETXObserved delivery and retransmission behaviour.Avoids weak links and repeated retransmissions.
Progress to sinkWhether the neighbor moves the packet closer to the gateway.Prevents unnecessary wandering paths.
Queue stateLocal congestion at the neighbor.Reduces delay and packet drop during bursts.
Route stabilityConsistency of recent parent behaviour.Reduces oscillation and control overhead.
3.3. Routing Decision Workflow
A real world routing decision loop is depicted in figure 2. The process is started with discovering neighbours, calculating the neighbour quality and sending the quality periodically to the neighbors. When this information is updated and received in the neighbour-table a composite-score can be calculated and after applying a switching threshold, a best-parent can be elected. When a route fails the packets are temporarily stored and a repair mechanism is triggered.
Figure 3.
Fig. 2. ELQAR routing decision workflow and composite score structure.
Parent choice also matters - in the absence of such constraint, a node would change its parent any time its second-best parent matches the first in terms of score. Such switching might cause oscillation, high overheads or packet reordering. This paper permits a parent change if the new candidate better meets current needs than the current one by over 8% or if the latter has been detected to be down.
3.4. Routing Metadata Packet
Table 4. Suggested routing metadata fields for gateway logging.
FieldExampleFunction
node_idN-042Identifies the source node.
parent_idN-011Shows the selected next hop.
seq_no18492Supports ordering and loss detection.
energy_ratio0.78Reports remaining energy estimate.
lq_score0.86Reports link quality toward the parent.
queue_level0.20Indicates local congestion pressure.
delay_flagfalseMarks buffered data delivered after outage.
payload_hashoptionalSupports integrity checking at gateway.
When bandwidth is extremely tight, these fields do not have to be transmitted in every application packet. These values, nevertheless, can be intermittently transmitted or included in packets intended for device diagnostic use. The gateway, dashboard can infer that these values were unavailable, transmitted with a latency or routed instability and that the reported issues represent quality problems, not measurement problems.
4.1. Simulation Scope
The experimental part of this study is simulated within a controlled simulation model The aim of the simulation experiment is to evaluate behaviors of routing schemes on the equal conditions, but it does not guarantee for being proven on the real experiment with some certain condition. In this study, one simulation field is constructed with an area 100 m 100 m, with a sink located at upper boundary of the area. And battery powered nodes are placed within this area with periodic reporting messages and a few times of packet jamming. All figures are produced for this work and synthetic data values are used for plots rather than from web browsing sites.
Table 5. Practical simulation assumptions used in this study.
Input variableAssumed valuePurpose / interpretation
Deployment area100 m × 100 mRepresents a small outdoor or industrial IoT field.
Node densities25 to 150 nodesTests sparse, moderate, and dense deployments.
Base topology72 nodesUsed for the main visual topology example.
Sink position(50 m, 106 m)Represents an edge gateway at the field boundary.
Initial energy0.55 to 1.0 JAllows non-identical battery states.
Radio range35 m nominalRepresents short-range low-power communication.
Traffic load1 to 10 packets/node/minTests normal and burst reporting conditions.
Queue size30 packetsModels local buffering during congestion.
Switch threshold8% score improvementPrevents unstable parent switching.
4.2. Generated Topology and Route Assignment
In Figure 3 we see the resulting topology with 72 nodes for base-case visualization. Standard nodes are displayed as dots, relay candidates are displayed as square marks, and the sink or gateway is shown as a star. The connecting lines display the relayed-optimized paths derived from the local score based selection algorithm.
Figure 4.
Fig. 3. Generated 72-node WSN deployment and optimized relay paths.
The topology is irregular, this makes it more like the actual placement of IoT. Most nodes are close to the sink node and some are on the boundary, which distributes the forwarder burden differently across nodes. Also, the routing metric is more significant in this case. If the nodes all have the same distance, same energy and the same link quality, it will be harder to observe routing performance.
Table 6. Representative generated node records from the practical topology.
Nodex (m)y (m)Energy (J)Assigned role / parent
N-00086.371.20.64N-055
N-00772.935.30.56N-002
N-01476.661.20.74N-055
N-02240.09.20.84N-042
N-03594.286.70.94N-055
N-04858.525.30.78N-002
N-0615.629.90.78N-058
N-07081.322.30.91N-002
4.3. Algorithm Sequence
Here is a summarized implementation algorithm. I’ve tried to implement the steps in an “embeddable way”, because the algorithm can be implemented in embedded firmware or in a simulator.
Table 7. Implementation-oriented ELQAR algorithm sequence.
StepOperation
1Initialize node identifier, energy estimate, sequence counter, and empty neighbor table.
2Broadcast a low-rate beacon containing node_id, hop estimate, energy ratio, and queue level.
3For each neighbor, update RSSI/LQI, delivery history, ETX estimate, and last-heard timestamp.
4Normalize energy, link quality, progress, queue, and stability values to the interval [0,1].
5Calculate RoutingScore for all valid neighbor candidates.
6Select the candidate with the highest score if it exceeds the current parent by the switch threshold.
7Forward telemetry packets with sequence number, parent_id, and delay flag.
8If acknowledgements fail, buffer packets, reduce candidate stability, and trigger local route repair.
9When connectivity returns, forward buffered packets while preserving original timestamps.
The performance analysis was measured through packet delivery ratio, energy behaviour, delay response, lifetime checkpoints and sensitivity analysis of the metrics, selected as to reflect the practical design trade-offs occurring in real IoT-WSN. The outcomes of these metrics were modelled based on the hypotheses set out in Table 5, providing an engineering basis.
5.1. Packet Delivery Ratio
Packet Delivery Ratio (PDR) refers to the ratio of the number of transmitted packets successfully delivered to the sink. At low density most of routing algorithms show satisfactory delivery ratio because of limited amount of concurrent transmissions. As density increases, issues such as contention, overload of relays and bad channels are apparent. The delivery ratio of optimized ELQAR algorithm shows its robust characteristics under dense situation as demonstrated in Figure 4.
Figure 5.
Fig. 4. Simulated PDR response under increasing node density.
The practical implication is that a routing metric cannot take shortcuts via unreliable nodes even when they result in a smaller path length. We observe the greatest loss of PDR on the shortest hop baseline that reuses central relays and poor short hops. The optimized approach retains greater connectivity by favouring parent nodes that are reliable, powered, and unburdened.
5.2. Residual Energy Behaviour
In WSN routing, the behavior of energy is a fundamental aspect. Protocols that perform well initially might be draining small number of important relay’s energy implicitly. In figure 5, the residual network energy profile during rounds of reporting is plotted. Optimized algorithm causes the energy to drain at a lower rate by judiciously allotting forwarding task to healthier paths.
Figure 6.
Fig. 5. Residual network energy during repeated reporting rounds.
We don't treat this as an accurate prediction of battery life. Energy consumed by a particular node depends on the radio module, power setting, sleep current, listening period, packet size, retransmission level, temperature, firmware efficiency, etc. Still, the result is important in terms of trend – it shows routing fairness helps avoid topology collapse at early stage.
5.3. Delay Response Under Traffic Load
End-to-end delay The time taken for a packet to be transmitted from its creation at a sensor node until it is delivered to the sink node or gateway. Most periodic telemetry can withstand delays of this magnitude; but for critical alarm data rapid arrival is essential. Figure 6 illustrates increasing end-to-end delay with increase in offered traffic rates between 1 and 10 packets per node per minute.
Figure 7.
Fig. 6. Delay growth under increased IoT reporting load.
Queue State Reduces Delay: The delay curve shows how useful it is to include the state of the queues in the routing metric. During peak loads, the shortest hop strategy would put too much traffic onto relays close to the sink. ELQAR’s mechanism for avoiding relays with high queue pressure causes the delay to rise less during a traffic spike. This is helpful for situations like those in IoT networks, where the normal load might be low, but there might be an event causing traffic to temporarily increase.
5.4. Network Lifetime Checkpoints
In our work, network lifetime is expressed by multiple checkpoints rather than one particular value. The first-node-death indicates that the first battery hole is generated. 50% node-death provides a wide view of degradation and the last-connectivity-round can roughly estimate that at what stage the network cannot serve any useful communication any more. Figure 7 illustrates the above three points for the examined routing behaviors.
Fig. 7. Simulated network-lifetime checkpoints.
Figure 8.
Table 8. Lifetime checkpoint comparison from the practical simulation.
Routing behaviourFirst node dies50% nodes dieLast connectivityInterpretation
Shortest-hop395625910Early relay exhaustion near sink.
LEACH-style5207651030Better energy spreading through clustering.
RPL-like5758451120Stable graph behaviour with objective-function support.
Optimized ELQAR71010101280Best lifetime due to energy and queue-aware parent selection.
5.5. Metric Sensitivity
As ELQAR is a weighted routing metric, the chosen weights play a significant role. We illustrate a synthetic surface of sensitivity with regard to PDR in which the weight of residual energy and weight of link-quality were varied, and all the other factors were kept at the base values in Figure 8. The chosen base-case value lies at the middle region rather than any extreme position.
Figure 9.
Fig. 8. Sensitivity of simulated PDR to energy and link-quality weights.
Sensitivity: The sensitivity outcome leads us to a simple, realistic design conclusion. There is not any one best weight or weighting to meet any deployment. If we had a long term deployment in a monitored environment we may need more emphasis on energy weight. We could be in a system where safety is paramount and we might want higher weighting for link quality and delay weight. Professional applications should provide weights as parameters settable via gateway or firm ware update.
Table 9. Consolidated performance summary under selected scenarios.
MetricShortest-hopLEACH-styleRPL-likeOptimized ELQAR
PDR at 75 nodes89.7%91.2%93.9%95.7%
Delay at 6 pkt/node/min128 ms106 ms99 ms82 ms
First node dies395 rounds520 rounds575 rounds710 rounds
50% nodes die625 rounds765 rounds845 rounds1010 rounds
Main weaknessEnergy holesCluster overheadMetric tuningCalibration needed
5.6. Routing Overhead and Maintenance Behaviour
However, even if the routing protocol provides optimal forwarding efficiency, it might still be unusable if the control overhead it imposes on the network is too high. In the case of a wireless sensor network, and even in general for low-power networks, any packet which is just a beacon, a control message, a routing update or a retransmission takes power and creates more contention on the channel. For these reasons, the model introduced herein imposes controls to limit the number of control messages.
The control messages of the model consist in neighbor beacons sent periodically, passive quality estimations coming from the acknowledgements of data packets and periodic parent changes determined from local observations.
Thus, the optimized model is not intended to reconstruct a global view of the network graph at every transmitted packet. Indeed, each node maintains a view only locally as a neighbor list, the value is incremented by the receipt of neighbor beacons, the loss of a packet for which an acknowledgement should have been received or when a significant change in the queue status is observed. The objective here is to be capable of running the routing logic in firmware of restricted size, but it is still adaptive enough to be functional in dynamic wireless conditions. Finally, the maintenance behavior of the network, recorded at the gateway, may serve as an indicator for the good wirelessness conditions.
A large number of parent changes may correspond to a unstable wireless state, an unsuitable threshold value for the parent changes or inappropriate position for intermediate nodes.
A high number of retransmissions might corresponds to a large number of faulty links and a high number of lost packets can correspond to a gateway shutdown or a high degree of congestion within the network itself. This information is valuable for any system administrator because it can give hints about how to proceed to a corrective intervention.
Table 10. Routing overhead sources and their practical control policy.
Overhead sourcePurposeControl policy
Neighbor beaconLow-rate advertisement of energy, hop estimate, and queue state.1 message per node every 30-60 s in stable mode.
Parent updateGenerated when a node changes its selected next hop.Only when score improvement exceeds threshold.
AcknowledgementConfirms packet reception and refreshes link-quality history.Used to estimate retransmission cost.
Route repairTriggered after repeated parent failures.Temporary increase in control traffic.
Gateway logStores routing events and delayed-packet indicators.Enables tuning and maintenance analysis.
6.1. Engineering Interpretation
The study reveals that optimum routing in IoT-WSNs is a coupled engineering problem. Reliability, energy consumption, delay, and stability are not independent. An increase in retransmissions might lead to better delivery but consumes significant energy, while a shorter path might reduce delay but may burden the central relays.
Prioritizing energy can select nodes with large battery power but may introduce long and unstable links.
The ELQAR approach tackles this coupled design window by aggregating local features into a single decision score, enabling it to be efficient for embedded execution while versatile enough for customized application settings. This method is beneficial because it does not need global network visibility which is usually challenging for low power consumption in a wireless network. In terms of IoT implementation, this should be also exposed to the gateway and cloud application. The route information associated with lost data or communication failures would enable maintenance to decide if sensor failure, battery exhaustion, link quality deterioration or congestion is to blame, thus, avoiding improper data interpretation or analysis.
6.2. Prototype Implementation Roadmap
How to implement in a real system There is the first step to prototype in small scale using few low power nodes to demonstrate beaconing, neighbour table management, sequence number and ACK. Second, build ELQAR score and threshold of parent switching. Third, link the sink to an MQTT / CoAP broker and routing metadata into a database.
The firmware should be designed modularity such as: • Sensor acquisition • packet formatting • Neighbours management • link quality estimations • routing score estimations • local buffering • radio transmitting • GW synchronizations The GW software should validate the incoming record, check the sequence gap, notice the late packet, and report routing status.
For professional usage, the Dashboard shows the network status besides application values, e.g.: Packet delivery trend, residual energy map, parent change counter, queue overflow counter, delayed packet counter, and availability status. That is helpful for maintenance and isolating sensing and communication problems.
6.3. Required Validation Tests
Table 11. Practical validation tests recommended before deployment.
Validation testProcedurePurpose
Radio-link testMeasure RSSI, LQI, PRR, and ETX at several distances and obstacle conditions.Calibrates link-quality thresholds.
Energy testMeasure current during sleep, listening, transmission, retransmission, and processing.Converts simulated energy trends to real battery estimates.
Congestion testGenerate bursts from many nodes and observe queue length and packet loss.Verifies queue-aware parent selection.
Route-failure testTurn off selected relays and observe route repair and buffering.Confirms resilience and delayed-data handling.
Security testInject abnormal metric advertisements in a controlled environment.Tests resistance to misleading routing information.
Cloud integration testStream routing metadata to broker, database, and dashboard.Validates operational observability.
6.4. Limitations
However, we acknowledge two limitations to the simulation results. Firstly, the results come from an transparent simulation model, not a real field deployment, hence they describe performance in a reproduceable design scenario, and not the guaranteed performance of such in all possible real worlds conditions. Secondly, the behaviours of protocols (LEACH, RPL and others) have been described as generic, while actual implementations will be sensitive to: MAC Layer, hardware, simulator configuration and protocol parameters.
Other limitations concern the simplified energy model of a device (not including power consumed while sleep, listen, process, transmit retransmit and synchronize); and the need for calibration on the weighting function. It was chosen a reasonable set of base-case weights for the current configuration, but different deployments may require a trade-off on the final weights for energy, quality, stability and delay criteria. The current limitations highlight the direction of our engineering effort: radio and energy measured data to validate the proposed framework and comparison to existing standard protocols implementations in the same test-bed environment, the final weights to choose for the actual system depending on the application requirements and the estimated environmental behaviour.
In this paper we outlined a practical design for enhancing Wireless Sensor Networks Routing in IoT. We show routing shouldn't just consider a simple hop count: since in IoT-WSNs limited battery lifetime, fickle link state, packet drops, traffic congestion and delays, as well as reporting requirements at the application layer need to be considered. Our lightweight multi-metric routing Elaboration of a lightweight quality based additive ranking routing protocol (ELQAR) computes a next hop selection score, which is derived from combining: node residual energy, link quality, route progress, queue status and route stability.
Simulation showed our approach reduces packet delivery loss at higher densities, limit delays under heavy traffic loads and delays network lifetime benchmarks in relation to some simplified schemes (shortest hop-hop counts, LEACH-based and RPL-based routes) Under these specific traffic loads and network densities, the core system engineering insight: an IoT routing optimization approach is inherently related to the globalIoT system design.
The node's firmware, radio behaviour, gate ways packet processing, broker's message ingestion, databases storage and dashboards presentation depend critically on managing delays, losses, energy constraints and ordered packets correctly. A next research task could be to embed ELQAR on a realtest bedand optimise its parameters based on collected link state, energy measures, and assess its effectiveness vs the existing standard protocols under the same conditions.
F. Akyildiz, W. Su, Y. Sankarasubramaniam, and E. Cayirci, "Wireless sensor networks: a survey," Computer Networks, vol. 38, no. 4, pp. 393–422, 2002, doi: 10.1016/S1389-1286(01)00302-4.
K. Akkaya and M. Younis, "A survey on routing protocols for wireless sensor networks," Ad Hoc Networks, vol. 3, no. 3, pp. 325–349, 2005, doi: 10.1016/j.adhoc.2003.09.010.
J. Yick, B. Mukherjee, and D. Ghosal, "Wireless sensor network survey," Computer Networks, vol. 52, no. 12, pp. 2292–2330, 2008, doi: 10.1016/j.comnet.2008.04.002.
W. R. Heinzelman, A. Chandrakasan, and H. Balakrishnan, "Energy-efficient communication protocol for wireless microsensor networks," in Proc. 33rd Hawaii International Conference on System Sciences, 2000, doi: 10.1109/HICSS.2000.926982.
O. Gnawali, R. Fonseca, K. Jamieson, D. Moss, and P. Levis, "Collection Tree Protocol," in Proc. ACM SenSys, 2009, pp. 1–14, doi: 10.1145/1644038.1644040.
C. E. Perkins and E. M. Royer, "Ad-hoc On-Demand Distance Vector Routing," in Proc. IEEE WMCSA, 1999, pp. 90–100, doi: 10.1109/MCSA.1999.749281.
D. B. Johnson and D. A. Maltz, "Dynamic source routing in ad hoc wireless networks," in Mobile Computing, Kluwer Academic Publishers, 1996, pp. 153–181.
T. Winter et al., RPL: IPv6 Routing Protocol for Low-Power and Lossy Networks, IETF RFC 6550, 2012.
P. Thubert, Objective Function Zero for the Routing Protocol for Low-Power and Lossy Networks (RPL), IETF RFC 6552, 2012.
Woo, T. Tong, and D. Culler, "Taming the underlying challenges of reliable multihop routing in sensor networks," in Proc. ACM SenSys, 2003, pp. 14–27, doi: 10.1145/958491.958494.
D. S. J. De Couto, D. Aguayo, J. Bicket, and R. Morris, "A high-throughput path metric for multi-hop wireless routing," in Proc. ACM MobiCom, 2003, pp. 134–146, doi: 10.1145/938985.939000.
R. C. Shah and J. M. Rabaey, "Energy aware routing for low energy ad hoc sensor networks," in Proc. IEEE WCNC, 2002, pp. 350–355, doi: 10.1109/WCNC.2002.993520.
M. Younis, M. Youssef, and K. Arisha, "Energy-aware routing in cluster-based sensor networks," in Proc. IEEE MASCOTS, 2002, pp. 129–136, doi: 10.1109/MASCOT.2002.1167069.
S. Lindsey and C. S. Raghavendra, "PEGASIS: Power-efficient gathering in sensor information systems," in Proc. IEEE Aerospace Conference, 2002, pp. 1125–1130, doi: 10.1109/AERO.2002.1035242.
Manjeshwar and D. P. Agrawal, "TEEN: A routing protocol for enhanced efficiency in wireless sensor networks," in Proc. IPDPS Workshops, 2001, pp. 2009–2015.
Dunkels, B. Gronvall, and T. Voigt, "Contiki - a lightweight and flexible operating system for tiny networked sensors," in Proc. IEEE LCN, 2004, pp. 455–462, doi: 10.1109/LCN.2004.38.
M. R. Palattella et al., "Standardized protocol stack for the Internet of Things," IEEE Communications Surveys & Tutorials, vol. 15, no. 3, pp. 1389–1406, 2013, doi: 10.1109/SURV.2012.111412.00158.
Al-Fuqaha, M. Guizani, M. Mohammadi, M. Aledhari, and M. Ayyash, "Internet of Things: A survey on enabling technologies, protocols, and applications," IEEE Communications Surveys & Tutorials, vol. 17, no. 4, pp. 2347–2376, 2015, doi: 10.1109/COMST.2015.2444095.
M. A. Razzaque, C. Bleakley, and S. Dobson, "Compression in wireless sensor networks: A survey and comparative evaluation," ACM Transactions on Sensor Networks, vol. 10, no. 1, pp. 1–44, 2013, doi: 10.1145/2528948.
M. A. Mahmood, W. K. G. Seah, and I. Welch, "Reliability in wireless sensor networks: A survey and challenges ahead," Computer Networks, vol. 79, pp. 166–187, 2015, doi: 10.1016/j.comnet.2014.12.016.
M. R. Senouci, A. Mellouk, H. Senouci, and A. Aissani, "Performance evaluation of network lifetime spatial-temporal distribution for WSN routing protocols," Journal of Network and Computer Applications, vol. 35, no. 4, pp. 1317–1328, 2012, doi: 10.1016/j.jnca.2012.01.017.
N. A. Pantazis, S. A. Nikolidakis, and D. D. Vergados, "Energy-efficient routing protocols in wireless sensor networks: A survey," IEEE Communications Surveys & Tutorials, vol. 15, no. 2, pp. 551–591, 2013, doi: 10.1109/SURV.2012.062612.00084.
H. Yetgin, K. T. K. Cheung, M. El-Hajjar, and L. Hanzo, "A survey of network lifetime maximization techniques in wireless sensor networks," IEEE Communications Surveys & Tutorials, vol. 19, no. 2, pp. 828–854, 2017, doi: 10.1109/COMST.2017.2650979.
OASIS, MQTT Version 5.0, OASIS Standard, 2019.