<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE article PUBLIC "-//NLM//DTD JATS (Z39.96) Journal Publishing DTD v1.1 20151215//EN" "http://jats.nlm.nih.gov/publishing/1.1/JATS-journalpublishing1.dtd">
<article xmlns:xlink="http://www.w3.org/1999/xlink" xmlns:mml="http://www.w3.org/1998/Math/MathML" xml:lang="en" article-type="research-article" dtd-version="1.1">
<front>
<journal-meta>
<journal-id journal-id-type="pmc">CMC</journal-id>
<journal-id journal-id-type="nlm-ta">CMC</journal-id>
<journal-id journal-id-type="publisher-id">CMC</journal-id>
<journal-title-group>
<journal-title>Computers, Materials &#x0026; Continua</journal-title>
</journal-title-group>
<issn pub-type="epub">1546-2226</issn>
<issn pub-type="ppub">1546-2218</issn>
<publisher>
<publisher-name>Tech Science Press</publisher-name>
<publisher-loc>USA</publisher-loc>
</publisher>
</journal-meta>
<article-meta>
<article-id pub-id-type="publisher-id">83797</article-id>
<article-id pub-id-type="doi">10.32604/cmc.2026.083797</article-id>
<article-categories>
<subj-group subj-group-type="heading">
<subject>Article</subject>
</subj-group>
</article-categories>
<title-group>
<article-title>Optimizing the Communication Cost in Energy Efficient IoT Devices through an Adaptive Algorithm for Swarm Robotics</article-title>
<alt-title alt-title-type="left-running-head">Optimizing the Communication Cost in Energy Efficient IoT Devices through an Adaptive Algorithm for Swarm Robotics</alt-title>
<alt-title alt-title-type="right-running-head">Optimizing the Communication Cost in Energy Efficient IoT Devices through an Adaptive Algorithm for Swarm Robotics</alt-title>
</title-group>
<contrib-group>
<contrib id="author-1" contrib-type="author" corresp="yes">
<name name-style="western"><surname>Ijaz</surname><given-names>Amir</given-names></name><email>amir.ijaz@utu.fi</email></contrib>
<contrib id="author-2" contrib-type="author">
<name name-style="western"><surname>Haghbayan</surname><given-names>Hashem</given-names></name></contrib>
<contrib id="author-3" contrib-type="author">
<name name-style="western"><surname>Malik</surname><given-names>Abdul</given-names></name></contrib>
<contrib id="author-4" contrib-type="author">
<name name-style="western"><surname>Nigussie</surname><given-names>Ethiopia</given-names></name></contrib>
<contrib id="author-5" contrib-type="author">
<name name-style="western"><surname>Plosila</surname><given-names>Juha</given-names></name></contrib>
<aff id="aff-1">
<institution>Department of Computing, University of Turku</institution>, <addr-line>Turku</addr-line>, <country>Finland</country></aff>
</contrib-group>
<author-notes>
<corresp id="cor1"><label>&#x002A;</label>Corresponding Author: Amir Ijaz. Email: <email>amir.ijaz@utu.fi</email></corresp>
</author-notes>
<pub-date date-type="collection" publication-format="electronic">
<year>2026</year>
</pub-date>
<pub-date date-type="pub" publication-format="electronic">
<day>23</day><month>07</month><year>2026</year>
</pub-date>
<volume>88</volume>
<issue>3</issue>
<elocation-id>12</elocation-id>
<history>
<date date-type="received">
<day>13</day>
<month>04</month>
<year>2026</year>
</date>
<date date-type="accepted">
<day>15</day>
<month>05</month>
<year>2026</year>
</date>
</history>
<permissions>
<copyright-statement>&#x00A9; 2026 The Authors. Published by Tech Science Press.</copyright-statement>
<copyright-year>2026</copyright-year>
<copyright-holder>The Authors</copyright-holder>
<license xlink:href="https://creativecommons.org/licenses/by/4.0/">
<license-p>This work is licensed under a <ext-link ext-link-type="uri" xlink:type="simple" xlink:href="https://creativecommons.org/licenses/by/4.0/">Creative Commons Attribution 4.0 International License</ext-link>, which permits unrestricted use, distribution, and reproduction in any medium, provided the original work is properly cited.</license-p>
</license>
</permissions>
<self-uri content-type="pdf" xlink:href="TSP_CMC_83797.pdf"></self-uri>
<abstract>
<p>The exponential growth of the Internet of Things (IoT) has led to an urgent need for highly energy-efficient communication strategies, especially for battery-powered or self-sustaining devices. In this work, we present a comprehensive framework for minimizing communication energy in IoT nodes operating in swarm robotic systems. We examine and integrate multiple low-power wireless technologies (BLE, LoRaWAN, MQTT, CoAP) with advanced Medium Access Control (MAC) protocols. We additionally propose adaptive scenarios leveraging both ambient energy harvesting and passive backscatter transmission. Our solution employs adaptive scheduling and dynamic transmission power management. Specifically, a Deep Q-Learning (DQL) agent dynamically adjusts transmission parameters based on the current energy condition. We develop analytical power consumption models incorporating equations for duty cycling, listening energy, and transmission energy. We then test the framework on a prototype IoT rover. Our experiments demonstrate that our optimizations extend device lifetime by up to 25% while maintaining rapid and reliable data transmission. The proposed methods substantially improve the balance between energy consumption and communication performance. This represents a significant advancement toward extending the operational lifetime of IoT and swarm robotic systems.</p>
</abstract>
<kwd-group kwd-group-type="author">
<kwd>Internet of Things (IoT)</kwd>
<kwd>protocols</kwd>
<kwd>edge devices</kwd>
<kwd>architecture</kwd>
<kwd>resource management</kwd>
<kwd>autonomous systems</kwd>
<kwd>power consumption</kwd>
<kwd>optimization</kwd>
</kwd-group></article-meta>
</front>
<body>
<sec id="s1">
<label>1</label>
<title>Introduction</title>
<p>Applications in smart cities, environmental monitoring, agriculture, healthcare, and industry are made possible by the Internet of Things (IoT), which is linking billions of devices globally. Since many IoT devices run on limited energy budgets (such as batteries), communication energy accounts for a large portion of total consumption. Energy efficiency is even more important in swarm robotics scenarios, when numerous autonomous robots or sensors coordinate their operations. Previous studies have demonstrated that energy optimization is critical for achieving sustainability objectives in swarm systems [<xref ref-type="bibr" rid="ref-1">1</xref>], and for extending robot lifespan while reducing operating costs. IoT nodes must achieve <italic>energy-efficient</italic> operation, balancing energy consumption with energy optimization, in order to achieve long-term deployment without frequent battery replacement [<xref ref-type="bibr" rid="ref-2">2</xref>], and to achieve these objectives, our proposed methodology is illustrated in <xref ref-type="fig" rid="fig-1">Fig. 1</xref>.</p>
<fig id="fig-1">
<label>Figure 1</label>
<caption>
<title>Overall methodology.</title>
</caption>
<graphic mimetype="image" mime-subtype="tif" xlink:href="CMC_83797-fig-1.tif"/>
</fig>
<p>These challenges motivate our work, leading us to develop our prototype for experimentation as presented in <xref ref-type="fig" rid="fig-2">Fig. 2</xref>. We optimize the communication cost of IoT devices by tailoring transmission behavior to the available energy and communication situation. This includes two main ideas: (1) leveraging ambient energy and passive backscatter techniques to reduce battery dependence, and (2) employing adaptive algorithms (such as dynamic power regulation and intelligent scheduling) to reduce radio energy consumption while ensuring reliable data transmission.</p>
<fig id="fig-2">
<label>Figure 2</label>
<caption>
<title>Prototype of rover.</title>
</caption>
<graphic mimetype="image" mime-subtype="tif" xlink:href="CMC_83797-fig-2.tif"/>
</fig>
<p>In particular, we provide the following contributions:<list list-type="bullet">
<list-item>
<p><bold>Novel Cross Layer Optimization Framework:</bold> A mixed communication-computation optimization architecture is suggested for energy-constrained IoT as well as swarm robotic systems. Unlike traditional techniques, which optimize communication or computation separately, the proposed framework incorporates protocol adaptation, workload-aware scheduling, duty-cycle management, and limited Deep Q-Learning (DQL) into a single optimization structure.</p></list-item>
<list-item>
<p><bold>Adaptive Multi Protocol Communication Intelligence:</bold> The framework chooses between BLE, MQTT, CoAP, and LoRaWAN according to the transmission distance, traffic conditions, residual energy, and channel quality. Existing restricted RL techniques usually use a set communication mechanism.</p></list-item>
<list-item>
<p><bold>Constraint Aware Hybrid Learning Strategy:</bold> In resource-constrained IoT environments, a limited DQL approach is paired with heuristic adaptation rules to reduce dangerous exploration and boost convergence stability. Purely RL-based approaches, on the other hand, rely exclusively on unrestricted policy exploration.</p></list-item>
<list-item>
<p><bold>Traffic Aware Energy Optimization:</bold> The suggested system modifies communication behavior in accordance with periodic, bursty, and event-driven traffic needs. The majority of earlier restricted RL techniques used the assumption that traffic patterns were simpler or constant.</p></list-item>
<list-item>
<p><bold>Scalability Oriented Lightweight Design:</bold> To reduce computational and communication cost in large-scale swarm deployments, the architecture makes use of parameter sharing, event-triggered modifications, and lightweight model adaptation.</p></list-item>
<list-item>
<p><bold>Experimental Validation and Quantitative Analysis:</bold> Several communication protocols and realistic workload conditions are used to evaluate the system experimentally. Comparative study shows considerable gains in terms of communication energy efficiency, delay, as well as processing overhead compared to fixed-policy and heuristic baselines.</p></list-item>
</list></p>
<p>We explicitly clarify that the primary novelty is not merely the application of reinforcement learning to IoT systems, but rather the development of a <italic>constraint-aware, cross-layer, adaptive optimization framework</italic> that jointly integrates communication adaptation, workload-aware scheduling, and energy-efficient learning under heterogeneous IoT operating conditions.</p>
<p>Additionally, several implementation-oriented refinements are explicitly categorized as incremental improvements, including:<list list-type="bullet">
<list-item>
<p>benchmarking normalization,</p></list-item>
<list-item>
<p>traffic modeling,</p></list-item>
<list-item>
<p>statistical ablation analysis,</p></list-item>
<list-item>
<p>and experimental reproducibility.</p></list-item>
</list></p>
<p>This paper is structured as follows. <xref ref-type="sec" rid="s2">Section 2</xref> examines energy-efficient IoT systems and low-power connectivity options. In <xref ref-type="sec" rid="s3">Section 3</xref>, we look at different wireless protocols and MAC properties (BLE, LoRaWAN, MQTT/CoAP) that are important for saving energy. We present our proposed adaptive algorithms and mathematical power consumption model in <xref ref-type="sec" rid="s4">Section 4</xref>. <xref ref-type="sec" rid="s5">Section 5</xref> outlines the experimental setup and main results of the evaluation. <xref ref-type="sec" rid="s6">Section 6</xref> concludes and outlines future research directions.</p>
</sec>
<sec id="s2">
<label>2</label>
<title>Background and Motivation</title>
<p>IoT devices frequently function in settings lacking stable power sources, relying on batteries with finite capacity requiring periodic maintenance [<xref ref-type="bibr" rid="ref-3">3</xref>]. Frequent battery replacement is impractical in large-scale or remote deployments, motivating <italic>energy-efficient</italic> designs incorporating energy optimization [<xref ref-type="bibr" rid="ref-4">4</xref>]. Recent trends show rapid growth of ambient-powered IoT: industry analysts predict over a billion shipments of ambient energy IoT devices by 2030, powered by harvesting of light, RF, vibration, or heat. For instance, more than half of future ambient IoT devices are expected to use photovoltaic cells or RF harvesters [<xref ref-type="bibr" rid="ref-5">5</xref>]. Moreover, ambitious research projects (e.g., the Ambient-6G initiative) aim to create battery-free IoT nodes that backscatter signals for communication. In such systems, devices harvest a small amount of ambient energy and communicate by reflecting external RF signals, avoiding active transmitters altogether [<xref ref-type="bibr" rid="ref-6">6</xref>]. This passive technique allows ultra-low-power IoT communication, since the small amount of energy that IoT devices can generate from the wireless signals is enough to power sensing and simple modulation.</p>
<p>In parallel, significant research has studied energy saving strategies at the protocol and system levels [<xref ref-type="bibr" rid="ref-7">7</xref>]. To reduce consumption, Ref. [<xref ref-type="bibr" rid="ref-8">8</xref>] proposes adaptive duty cycling (changing active/sleep durations with respect to energy availability) and energy aware routing protocols. Hybrid solutions have been studied, which combine multiple sources of energy (e.g., photovoltaic and Radiofrequency) to overcome the limits of each [<xref ref-type="bibr" rid="ref-9">9</xref>]. Nonetheless, many of these projects take a conservative approach to communication, focusing on scheduling or routing. Tightly integrated designs that improve communication protocols and energy management in IoT devices remain necessary [<xref ref-type="bibr" rid="ref-10">10</xref>]. Device broadcasting techniques must be modified since wireless broadcasts frequently account for the bulk of hardware energy budgets [<xref ref-type="bibr" rid="ref-11">11</xref>].</p>
<p>In swarm robots, energy minimization is essential [<xref ref-type="bibr" rid="ref-12">12</xref>]. Data transmission between nodes is necessary for robot groups to carry out tasks like mapping, detecting, and discovering [<xref ref-type="bibr" rid="ref-13">13</xref>]. Prior studies [<xref ref-type="bibr" rid="ref-14">14</xref>] show that energy optimization is essential for accomplishing sustainability goals in swarm-based systems, such extending robot lifespan and lowering operating costs. Therefore, our focus on communication costs is consistent with the overarching goal of building long-term, maintenance-free clusters of IoT robotic devices.</p>
</sec>
<sec id="s3">
<label>3</label>
<title>Low Power Wireless Technology Protocols</title>
<p>This section examines the key wireless technologies and MAC protocols that form the foundation of our adaptive communication design. Understanding their energy profiles and collision behavior enables us to develop optimization strategies.</p>
<sec id="s3_1">
<label>3.1</label>
<title>Bluetooth Low Energy (BLE)</title>
<p>BLE is a short-range radio operating in the 2.4 GHz ISM band with minimal power consumption for each bit. BLE reduces collisions by using frequency hopping and only a few advertising channels. However, when multiple devices transmit simultaneously, there are collisions, resulting in energy waste through retransmissions [<xref ref-type="bibr" rid="ref-15">15</xref>]. BLE&#x2019;s connection oriented mode enables users alter the power parameters and connection intervals, thereby improving device performance [<xref ref-type="bibr" rid="ref-16">16</xref>]. BLE nodes consume significantly less power than non-BLE Bluetooth or ZigBee radios. This is great for battery-powered nodes that only need to send small amounts of data from time to time. Research on BLE shows that the packet delivery ratio (PDR) decreases as the number of advertisers increases. However, some packets may still be able to be decoded even if they overlap, due to the capture effect [<xref ref-type="bibr" rid="ref-17">17</xref>]. Adaptive scanning and connection scheduling are necessary to reduce idle listening and collisions for effective BLE-based IoT operation [<xref ref-type="bibr" rid="ref-18">18</xref>].</p>
</sec>
<sec id="s3_2">
<label>3.2</label>
<title>LoRaWAN and LPWAN</title>
<p>Low-Power Wide-Area Networks (LPWAN), such as LoRaWAN and Sigfox, provide optimal long-range communication. LoRaWAN uses chirp spread spectrum modulation with different spreading factors (SF) to find the right balance between range and speed of data transfer. It has built-in limits on duty cycles and a simple ALOHA-style medium access, potentially causing collisions in dense deployments [<xref ref-type="bibr" rid="ref-19">19</xref>]. Numerous custom MAC protocols have been developed to mitigate LoRa collisions [<xref ref-type="bibr" rid="ref-20">20</xref>]. FaCA-LoRa uses a beacon-based scheduling method that is improved by carrier sense multiple access with collision avoidance (CSMA/CA) upgrades to keep transmissions in sync and avoid overlaps [<xref ref-type="bibr" rid="ref-21">21</xref>]. Due to regulatory constraints, LoRaWAN devices are limited to short duty cycles. Pre-scheduling duty cycles significantly improves channel utilization [<xref ref-type="bibr" rid="ref-22">22</xref>]. Another is the Harvest-Then-Transmit (HTT) technique. It sends and gets messages using both LoRaWAN and energy harvesting. HTT partitions each time slot into two phases: one for energy harvesting and another for transmission. Nodes harvest energy from sources such as RF signals or solar radiation before initiating data transmission [<xref ref-type="bibr" rid="ref-23">23</xref>]. LoRa nodes may utilize this HTT to check the strength of their transmissions. Our approach enhances these concepts by enabling dynamic mode switching between transmission and harvesting based on energy availability.</p>
</sec>
<sec id="s3_3">
<label>3.3</label>
<title>MQTT, CoAP, and Cellular IoT</title>
<p>MQTT and CoAP are application layer protocols that facilitate message exchange and RESTful communication [<xref ref-type="bibr" rid="ref-24">24</xref>]. These protocols have emerged as lightweight alternatives for resource-constrained IoT devices, with studies comparing their performance characteristics and implementation requirements [<xref ref-type="bibr" rid="ref-25">25</xref>]. For cellular IoT deployments, technologies like NB-IoT and LTE-M offer extended coverage and deep penetration, though comparative analyses show they consume more energy per transmitted bit than unlicensed alternatives [<xref ref-type="bibr" rid="ref-26">26</xref>]. NB-IoT provides reliable connectivity through cellular infrastructure, but this dependence on base stations and core networks introduces additional deployment costs and energy overhead for signal transmission [<xref ref-type="bibr" rid="ref-27">27</xref>]. BLE and LoRaWAN, on the other hand, utilize unlicensed spectrum and simple transceivers, resulting in substantially lower power consumption [<xref ref-type="bibr" rid="ref-28">28</xref>]. We prioritize BLE and LoRaWAN technologies for truly energy-efficient operation in remote deployments where feasible, but we also know that cellular IoT can be useful when there is infrastructure. We primarily focus on BLE, LoRaWAN, and low-power IP (MQTT/CoAP) protocols due to their applicability across diverse IoT use cases and minimal power requirements.</p>
</sec>
</sec>
<sec id="s4">
<label>4</label>
<title>Proposed Adaptive Communication Framework</title>
<p>Building on the above, we propose an adaptive communication framework that jointly considers energy optimization, power control, and protocol scheduling. <xref ref-type="fig" rid="fig-3">Fig. 3</xref> illustrates the high-level architecture of our system (conceptual). Each IoT node is equipped with an energy harvester (e.g., RF harvester) and a compact energy buffer (capacitor/battery). The node&#x2019;s radio can operate in either <italic>harvest mode</italic> or <italic>transmit mode</italic>. In harvest mode, the node collects ambient energy; in transmit mode, it exchanges data with other nodes or a gateway. The key is to optimally switch and adjust transmission parameters based on current energy state.</p>
<fig id="fig-3">
<label>Figure 3</label>
<caption>
<title>Proposed adaptive communication framework for an energy neutral IoT node.</title>
</caption>
<graphic mimetype="image" mime-subtype="tif" xlink:href="CMC_83797-fig-3.tif"/>
</fig>
<p>The problem is formulated as a Constrained Markov Decision Process (CMDP):<disp-formula id="eqn-1"><label>(1)</label><mml:math id="mml-eqn-1" display="block"><mml:munder><mml:mo movablelimits="true" form="prefix">max</mml:mo><mml:mrow><mml:mi>&#x03C0;</mml:mi></mml:mrow></mml:munder><mml:mtext>&#x00A0;</mml:mtext><mml:msub><mml:mrow><mml:mi mathvariant="double-struck">E</mml:mi></mml:mrow><mml:mrow><mml:mi>&#x03C0;</mml:mi></mml:mrow></mml:msub><mml:mrow><mml:mo>[</mml:mo><mml:munderover><mml:mo movablelimits="false">&#x2211;</mml:mo><mml:mrow><mml:mi>k</mml:mi><mml:mo>=</mml:mo><mml:mn>0</mml:mn></mml:mrow><mml:mrow><mml:mi mathvariant="normal">&#x221E;</mml:mi></mml:mrow></mml:munderover><mml:msup><mml:mi>&#x03B3;</mml:mi><mml:mi>k</mml:mi></mml:msup><mml:msub><mml:mi>r</mml:mi><mml:mi>k</mml:mi></mml:msub><mml:mo>]</mml:mo></mml:mrow><mml:mspace width="1em" /><mml:mrow><mml:mtext>s.t.</mml:mtext></mml:mrow><mml:mspace width="1em" /><mml:msub><mml:mrow><mml:mi mathvariant="double-struck">E</mml:mi></mml:mrow><mml:mrow><mml:mi>&#x03C0;</mml:mi></mml:mrow></mml:msub><mml:mo stretchy="false">[</mml:mo><mml:msub><mml:mi>C</mml:mi><mml:mi>i</mml:mi></mml:msub><mml:mo stretchy="false">]</mml:mo><mml:mo>&#x2264;</mml:mo><mml:msub><mml:mi>&#x03BA;</mml:mi><mml:mi>i</mml:mi></mml:msub><mml:mo>,</mml:mo><mml:mtext>&#x00A0;&#x00A0;</mml:mtext><mml:mi>i</mml:mi><mml:mo>&#x2208;</mml:mo><mml:mo fence="false" stretchy="false">{</mml:mo><mml:mrow><mml:mtext>latency</mml:mtext></mml:mrow><mml:mo>,</mml:mo><mml:mrow><mml:mtext>reliability</mml:mtext></mml:mrow><mml:mo fence="false" stretchy="false">}</mml:mo><mml:mo>,</mml:mo></mml:math></disp-formula>where <inline-formula id="ieqn-1"><mml:math id="mml-ieqn-1"><mml:msub><mml:mi>r</mml:mi><mml:mi>k</mml:mi></mml:msub></mml:math></inline-formula> is the reward, <inline-formula id="ieqn-2"><mml:math id="mml-ieqn-2"><mml:msub><mml:mi>C</mml:mi><mml:mi>i</mml:mi></mml:msub></mml:math></inline-formula> are constraint costs, and <inline-formula id="ieqn-3"><mml:math id="mml-ieqn-3"><mml:msub><mml:mi>&#x03BA;</mml:mi><mml:mi>i</mml:mi></mml:msub></mml:math></inline-formula> are admissible thresholds.</p>
<p>The state vector is explicitly defined as:<disp-formula id="eqn-2"><label>(2)</label><mml:math id="mml-eqn-2" display="block"><mml:msub><mml:mi>s</mml:mi><mml:mi>k</mml:mi></mml:msub><mml:mo>=</mml:mo><mml:mrow><mml:mo>[</mml:mo><mml:msub><mml:mi>d</mml:mi><mml:mi>k</mml:mi></mml:msub><mml:mo>,</mml:mo><mml:mtext>&#x00A0;</mml:mtext><mml:msub><mml:mi>q</mml:mi><mml:mi>k</mml:mi></mml:msub><mml:mo>,</mml:mo><mml:mtext>&#x00A0;</mml:mtext><mml:msub><mml:mrow><mml:mover><mml:mi>&#x03B3;</mml:mi><mml:mo stretchy="false">&#x005E;</mml:mo></mml:mover></mml:mrow><mml:mi>k</mml:mi></mml:msub><mml:mo>,</mml:mo><mml:mtext>&#x00A0;</mml:mtext><mml:msub><mml:mi>b</mml:mi><mml:mi>k</mml:mi></mml:msub><mml:mo>,</mml:mo><mml:mtext>&#x00A0;</mml:mtext><mml:msub><mml:mi>&#x03C4;</mml:mi><mml:mi>k</mml:mi></mml:msub><mml:mo>,</mml:mo><mml:mtext>&#x00A0;</mml:mtext><mml:msub><mml:mi>m</mml:mi><mml:mi>k</mml:mi></mml:msub><mml:mo>]</mml:mo></mml:mrow><mml:mo>,</mml:mo></mml:math></disp-formula>where <inline-formula id="ieqn-4"><mml:math id="mml-ieqn-4"><mml:msub><mml:mi>d</mml:mi><mml:mi>k</mml:mi></mml:msub></mml:math></inline-formula> is link distance, <inline-formula id="ieqn-5"><mml:math id="mml-ieqn-5"><mml:msub><mml:mi>q</mml:mi><mml:mi>k</mml:mi></mml:msub></mml:math></inline-formula> is queue length, <inline-formula id="ieqn-6"><mml:math id="mml-ieqn-6"><mml:msub><mml:mrow><mml:mover><mml:mi>&#x03B3;</mml:mi><mml:mo stretchy="false">&#x005E;</mml:mo></mml:mover></mml:mrow><mml:mi>k</mml:mi></mml:msub></mml:math></inline-formula> is estimated SINR, <inline-formula id="ieqn-7"><mml:math id="mml-ieqn-7"><mml:msub><mml:mi>b</mml:mi><mml:mi>k</mml:mi></mml:msub></mml:math></inline-formula> is residual battery level, <inline-formula id="ieqn-8"><mml:math id="mml-ieqn-8"><mml:msub><mml:mi>&#x03C4;</mml:mi><mml:mi>k</mml:mi></mml:msub></mml:math></inline-formula> is duty cycle state, and <inline-formula id="ieqn-9"><mml:math id="mml-ieqn-9"><mml:msub><mml:mi>m</mml:mi><mml:mi>k</mml:mi></mml:msub></mml:math></inline-formula> denotes protocol mode (e.g., BLE, LoRaWAN).</p>
<p>Continuous variables are discretized using adaptive binning:<disp-formula id="eqn-3"><label>(3)</label><mml:math id="mml-eqn-3" display="block"><mml:mi>x</mml:mi><mml:mo stretchy="false">&#x2192;</mml:mo><mml:mrow><mml:mi>&#x0212C;</mml:mi></mml:mrow><mml:mo stretchy="false">(</mml:mo><mml:mi>x</mml:mi><mml:mo stretchy="false">)</mml:mo><mml:mo>&#x2208;</mml:mo><mml:mo fence="false" stretchy="false">{</mml:mo><mml:mn>1</mml:mn><mml:mo>,</mml:mo><mml:mo>&#x2026;</mml:mo><mml:mo>,</mml:mo><mml:msub><mml:mi>N</mml:mi><mml:mi>x</mml:mi></mml:msub><mml:mo fence="false" stretchy="false">}</mml:mo><mml:mo>,</mml:mo></mml:math></disp-formula>where bin boundaries are logarithmically spaced for <inline-formula id="ieqn-10"><mml:math id="mml-ieqn-10"><mml:msub><mml:mi>d</mml:mi><mml:mi>k</mml:mi></mml:msub></mml:math></inline-formula> and <inline-formula id="ieqn-11"><mml:math id="mml-ieqn-11"><mml:msub><mml:mrow><mml:mover><mml:mi>&#x03B3;</mml:mi><mml:mo stretchy="false">&#x005E;</mml:mo></mml:mover></mml:mrow><mml:mi>k</mml:mi></mml:msub></mml:math></inline-formula> to better capture wide dynamic ranges.
<disp-formula id="eqn-4"><label>(4)</label><mml:math id="mml-eqn-4" display="block"><mml:msub><mml:mi>a</mml:mi><mml:mi>k</mml:mi></mml:msub><mml:mo>=</mml:mo><mml:mrow><mml:mo>[</mml:mo><mml:msub><mml:mi>P</mml:mi><mml:mrow><mml:mrow><mml:mtext>tx</mml:mtext></mml:mrow></mml:mrow></mml:msub><mml:mo>&#x2208;</mml:mo><mml:mrow><mml:mi>&#x1D4AB;</mml:mi></mml:mrow><mml:mo>,</mml:mo><mml:mtext>&#x00A0;</mml:mtext><mml:mi>&#x03B4;</mml:mi><mml:mo>&#x2208;</mml:mo><mml:mrow><mml:mi>&#x1D49F;</mml:mi></mml:mrow><mml:mo>,</mml:mo><mml:mtext>&#x00A0;</mml:mtext><mml:mi>&#x03BC;</mml:mi><mml:mo>&#x2208;</mml:mo><mml:mrow><mml:mi>&#x02133;</mml:mi></mml:mrow><mml:mo>]</mml:mo></mml:mrow><mml:mo>,</mml:mo></mml:math></disp-formula>where <inline-formula id="ieqn-12"><mml:math id="mml-ieqn-12"><mml:mrow><mml:mi>&#x1D4AB;</mml:mi></mml:mrow></mml:math></inline-formula> is a discrete transmit power set, <inline-formula id="ieqn-13"><mml:math id="mml-ieqn-13"><mml:mrow><mml:mi>&#x1D49F;</mml:mi></mml:mrow></mml:math></inline-formula> is duty cycle configurations, and <inline-formula id="ieqn-14"><mml:math id="mml-ieqn-14"><mml:mrow><mml:mi>&#x02133;</mml:mi></mml:mrow></mml:math></inline-formula> is protocol selection.</p>
<p>Instead of an ad hoc weighted sum, the reward is derived from a Lagrangian relaxation of <xref ref-type="disp-formula" rid="eqn-1">Eq. (1)</xref>:<disp-formula id="eqn-5"><label>(5)</label><mml:math id="mml-eqn-5" display="block"><mml:msub><mml:mi>r</mml:mi><mml:mi>k</mml:mi></mml:msub><mml:mo>=</mml:mo><mml:mo>&#x2212;</mml:mo><mml:munder><mml:mrow><mml:munder><mml:mfrac><mml:mrow><mml:msub><mml:mi>E</mml:mi><mml:mrow><mml:mrow><mml:mtext>total</mml:mtext></mml:mrow></mml:mrow></mml:msub><mml:mo stretchy="false">[</mml:mo><mml:mi>k</mml:mi><mml:mo stretchy="false">]</mml:mo></mml:mrow><mml:msub><mml:mi>E</mml:mi><mml:mrow><mml:mo movablelimits="true" form="prefix">max</mml:mo></mml:mrow></mml:msub></mml:mfrac><mml:mo>&#x23DF;</mml:mo></mml:munder></mml:mrow><mml:mrow><mml:mrow><mml:mtext>energy term</mml:mtext></mml:mrow></mml:mrow></mml:munder><mml:mo>&#x2212;</mml:mo><mml:msub><mml:mi>&#x03BB;</mml:mi><mml:mn>1</mml:mn></mml:msub><mml:munder><mml:mrow><mml:munder><mml:mrow><mml:mo movablelimits="true" form="prefix">max</mml:mo><mml:mo stretchy="false">(</mml:mo><mml:mn>0</mml:mn><mml:mo>,</mml:mo><mml:msub><mml:mi>L</mml:mi><mml:mi>k</mml:mi></mml:msub><mml:mo>&#x2212;</mml:mo><mml:msub><mml:mi>L</mml:mi><mml:mrow><mml:mrow><mml:mtext>th</mml:mtext></mml:mrow></mml:mrow></mml:msub><mml:mo stretchy="false">)</mml:mo></mml:mrow><mml:mo>&#x23DF;</mml:mo></mml:munder></mml:mrow><mml:mrow><mml:mrow><mml:mtext>latency violation</mml:mtext></mml:mrow></mml:mrow></mml:munder><mml:mo>&#x2212;</mml:mo><mml:msub><mml:mi>&#x03BB;</mml:mi><mml:mn>2</mml:mn></mml:msub><mml:munder><mml:mrow><mml:munder><mml:mrow><mml:mo movablelimits="true" form="prefix">max</mml:mo><mml:mo stretchy="false">(</mml:mo><mml:mn>0</mml:mn><mml:mo>,</mml:mo><mml:mi>P</mml:mi><mml:mi>D</mml:mi><mml:msub><mml:mi>R</mml:mi><mml:mrow><mml:mrow><mml:mtext>th</mml:mtext></mml:mrow></mml:mrow></mml:msub><mml:mo>&#x2212;</mml:mo><mml:mi>P</mml:mi><mml:mi>D</mml:mi><mml:msub><mml:mi>R</mml:mi><mml:mi>k</mml:mi></mml:msub><mml:mo stretchy="false">)</mml:mo></mml:mrow><mml:mo>&#x23DF;</mml:mo></mml:munder></mml:mrow><mml:mrow><mml:mrow><mml:mtext>reliability violation</mml:mtext></mml:mrow></mml:mrow></mml:munder><mml:mo>,</mml:mo></mml:math></disp-formula>where <inline-formula id="ieqn-15"><mml:math id="mml-ieqn-15"><mml:msub><mml:mi>E</mml:mi><mml:mrow><mml:mo movablelimits="true" form="prefix">max</mml:mo></mml:mrow></mml:msub></mml:math></inline-formula> normalizes energy, and <inline-formula id="ieqn-16"><mml:math id="mml-ieqn-16"><mml:msub><mml:mi>L</mml:mi><mml:mrow><mml:mtext>th</mml:mtext></mml:mrow></mml:msub></mml:math></inline-formula>, <inline-formula id="ieqn-17"><mml:math id="mml-ieqn-17"><mml:mi>P</mml:mi><mml:mi>D</mml:mi><mml:msub><mml:mi>R</mml:mi><mml:mrow><mml:mtext>th</mml:mtext></mml:mrow></mml:msub></mml:math></inline-formula> are QoS thresholds.</p>
<p>This formulation ensures:<list list-type="bullet">
<list-item>
<p>Scale invariance via normalization,</p></list-item>
<list-item>
<p>Explicit constraint penalization (rather than implicit weighting),</p></list-item>
<list-item>
<p>Compatibility with CMDP dual optimization.</p></list-item>
</list></p>
<p>The multipliers are updated online:<disp-formula id="eqn-6"><label>(6)</label><mml:math id="mml-eqn-6" display="block"><mml:msubsup><mml:mi>&#x03BB;</mml:mi><mml:mi>i</mml:mi><mml:mrow><mml:mo stretchy="false">(</mml:mo><mml:mi>t</mml:mi><mml:mo>+</mml:mo><mml:mn>1</mml:mn><mml:mo stretchy="false">)</mml:mo></mml:mrow></mml:msubsup><mml:mo>=</mml:mo><mml:msup><mml:mrow><mml:mo>[</mml:mo><mml:msubsup><mml:mi>&#x03BB;</mml:mi><mml:mi>i</mml:mi><mml:mrow><mml:mo stretchy="false">(</mml:mo><mml:mi>t</mml:mi><mml:mo stretchy="false">)</mml:mo></mml:mrow></mml:msubsup><mml:mo>+</mml:mo><mml:mi>&#x03B7;</mml:mi><mml:mo stretchy="false">(</mml:mo><mml:msubsup><mml:mi>C</mml:mi><mml:mi>i</mml:mi><mml:mrow><mml:mo stretchy="false">(</mml:mo><mml:mi>t</mml:mi><mml:mo stretchy="false">)</mml:mo></mml:mrow></mml:msubsup><mml:mo>&#x2212;</mml:mo><mml:msub><mml:mi>&#x03BA;</mml:mi><mml:mi>i</mml:mi></mml:msub><mml:mo stretchy="false">)</mml:mo><mml:mo>]</mml:mo></mml:mrow><mml:mo>+</mml:mo></mml:msup><mml:mo>,</mml:mo></mml:math></disp-formula>which removes arbitrariness and ensures convergence toward feasible policies.</p>
<p>We adopt a Double DQN with target network stabilization:<disp-formula id="eqn-7"><label>(7)</label><mml:math id="mml-eqn-7" display="block"><mml:msub><mml:mi>y</mml:mi><mml:mi>k</mml:mi></mml:msub><mml:mo>=</mml:mo><mml:msub><mml:mi>r</mml:mi><mml:mi>k</mml:mi></mml:msub><mml:mo>+</mml:mo><mml:mi>&#x03B3;</mml:mi><mml:msub><mml:mi>Q</mml:mi><mml:mrow><mml:msup><mml:mi>&#x03B8;</mml:mi><mml:mo>&#x2212;</mml:mo></mml:msup></mml:mrow></mml:msub><mml:mrow><mml:mo>(</mml:mo><mml:msub><mml:mi>s</mml:mi><mml:mrow><mml:mi>k</mml:mi><mml:mo>+</mml:mo><mml:mn>1</mml:mn></mml:mrow></mml:msub><mml:mo>,</mml:mo><mml:mi>arg</mml:mi><mml:mo>&#x2061;</mml:mo><mml:munder><mml:mo movablelimits="true" form="prefix">max</mml:mo><mml:mi>a</mml:mi></mml:munder><mml:msub><mml:mi>Q</mml:mi><mml:mrow><mml:mi>&#x03B8;</mml:mi></mml:mrow></mml:msub><mml:mo stretchy="false">(</mml:mo><mml:msub><mml:mi>s</mml:mi><mml:mrow><mml:mi>k</mml:mi><mml:mo>+</mml:mo><mml:mn>1</mml:mn></mml:mrow></mml:msub><mml:mo>,</mml:mo><mml:mi>a</mml:mi><mml:mo stretchy="false">)</mml:mo><mml:mo>)</mml:mo></mml:mrow><mml:mo>,</mml:mo></mml:math></disp-formula>
<disp-formula id="eqn-8"><label>(8)</label><mml:math id="mml-eqn-8" display="block"><mml:mrow><mml:mi>&#x02112;</mml:mi></mml:mrow><mml:mo stretchy="false">(</mml:mo><mml:mi>&#x03B8;</mml:mi><mml:mo stretchy="false">)</mml:mo><mml:mo>=</mml:mo><mml:mrow><mml:mi mathvariant="double-struck">E</mml:mi></mml:mrow><mml:mrow><mml:mo>[</mml:mo><mml:mo stretchy="false">(</mml:mo><mml:msub><mml:mi>y</mml:mi><mml:mi>k</mml:mi></mml:msub><mml:mo>&#x2212;</mml:mo><mml:msub><mml:mi>Q</mml:mi><mml:mrow><mml:mi>&#x03B8;</mml:mi></mml:mrow></mml:msub><mml:mo stretchy="false">(</mml:mo><mml:msub><mml:mi>s</mml:mi><mml:mi>k</mml:mi></mml:msub><mml:mo>,</mml:mo><mml:msub><mml:mi>a</mml:mi><mml:mi>k</mml:mi></mml:msub><mml:mo stretchy="false">)</mml:mo><mml:msup><mml:mo stretchy="false">)</mml:mo><mml:mn>2</mml:mn></mml:msup><mml:mo>]</mml:mo></mml:mrow><mml:mo>.</mml:mo></mml:math></disp-formula>
<list list-type="bullet">
<list-item>
<p>Energy aware prioritized replay:<disp-formula id="eqn-9"><label>(9)</label><mml:math id="mml-eqn-9" display="block"><mml:msub><mml:mi>p</mml:mi><mml:mi>k</mml:mi></mml:msub><mml:mo>&#x221D;</mml:mo><mml:mrow><mml:mo stretchy="false">|</mml:mo></mml:mrow><mml:msub><mml:mi>&#x03B4;</mml:mi><mml:mi>k</mml:mi></mml:msub><mml:mrow><mml:mo stretchy="false">|</mml:mo></mml:mrow><mml:mo>+</mml:mo><mml:mi>&#x03B1;</mml:mi><mml:msub><mml:mi>E</mml:mi><mml:mrow><mml:mrow><mml:mtext>total</mml:mtext></mml:mrow></mml:mrow></mml:msub><mml:mo stretchy="false">[</mml:mo><mml:mi>k</mml:mi><mml:mo stretchy="false">]</mml:mo><mml:mo>,</mml:mo></mml:math></disp-formula></p>
</list-item>
<list-item>
<p>Action masking for infeasible states (e.g., battery constraints),</p></list-item>
<list-item>
<p>Lightweight network architecture for embedded deployment.</p></list-item>
</list></p>
<p>Convergence is defined using three metrics:<disp-formula id="eqn-10"><label>(10)</label><mml:math id="mml-eqn-10" display="block"><mml:mrow><mml:mo>|</mml:mo><mml:msub><mml:mrow><mml:mover><mml:mi>R</mml:mi><mml:mo stretchy="false">&#x00AF;</mml:mo></mml:mover></mml:mrow><mml:mrow><mml:mi>t</mml:mi></mml:mrow></mml:msub><mml:mo>&#x2212;</mml:mo><mml:msub><mml:mrow><mml:mover><mml:mi>R</mml:mi><mml:mo stretchy="false">&#x00AF;</mml:mo></mml:mover></mml:mrow><mml:mrow><mml:mi>t</mml:mi><mml:mo>&#x2212;</mml:mo><mml:mi>W</mml:mi></mml:mrow></mml:msub><mml:mo>|</mml:mo></mml:mrow><mml:mo>&#x003C;</mml:mo><mml:mspace width="thinmathspace" /><mml:mspace width="thinmathspace" /><mml:msub><mml:mo>&#x03B5;</mml:mo><mml:mi>R</mml:mi></mml:msub><mml:mo>,</mml:mo></mml:math></disp-formula>
<disp-formula id="eqn-11"><label>(11)</label><mml:math id="mml-eqn-11" display="block"><mml:mtable columnalign="right left right left right left right left right left right left" rowspacing="3pt" columnspacing="0em 2em 0em 2em 0em 2em 0em 2em 0em 2em 0em" displaystyle="true"><mml:mtr><mml:mtd><mml:mrow><mml:mo>|</mml:mo><mml:msub><mml:mrow><mml:mover><mml:mrow><mml:mi>&#x02112;</mml:mi></mml:mrow><mml:mo stretchy="false">&#x00AF;</mml:mo></mml:mover></mml:mrow><mml:mrow><mml:mi>t</mml:mi></mml:mrow></mml:msub><mml:mo>&#x2212;</mml:mo><mml:msub><mml:mrow><mml:mover><mml:mrow><mml:mi>&#x02112;</mml:mi></mml:mrow><mml:mo stretchy="false">&#x00AF;</mml:mo></mml:mover></mml:mrow><mml:mrow><mml:mi>t</mml:mi><mml:mo>&#x2212;</mml:mo><mml:mi>W</mml:mi></mml:mrow></mml:msub><mml:mo>|</mml:mo></mml:mrow><mml:mo>&#x003C;</mml:mo><mml:mspace width="thinmathspace" /><mml:mspace width="thinmathspace" /><mml:msub><mml:mo>&#x03B5;</mml:mo><mml:mi>L</mml:mi></mml:msub><mml:mo>,</mml:mo></mml:mtd></mml:mtr></mml:mtable></mml:math></disp-formula>
<disp-formula id="eqn-12"><label>(12)</label><mml:math id="mml-eqn-12" display="block"><mml:msub><mml:mi>D</mml:mi><mml:mrow><mml:mrow><mml:mtext>KL</mml:mtext></mml:mrow></mml:mrow></mml:msub><mml:mo stretchy="false">(</mml:mo><mml:msub><mml:mi>&#x03C0;</mml:mi><mml:mi>t</mml:mi></mml:msub><mml:mrow><mml:mo stretchy="false">|</mml:mo></mml:mrow><mml:mrow><mml:mo stretchy="false">|</mml:mo></mml:mrow><mml:msub><mml:mi>&#x03C0;</mml:mi><mml:mrow><mml:mi>t</mml:mi><mml:mo>&#x2212;</mml:mo><mml:mi>W</mml:mi></mml:mrow></mml:msub><mml:mo stretchy="false">)</mml:mo><mml:mo>&#x003C;</mml:mo><mml:mspace width="thinmathspace" /><mml:mspace width="thinmathspace" /><mml:msub><mml:mo>&#x03B5;</mml:mo><mml:mrow><mml:mi>&#x03C0;</mml:mi></mml:mrow></mml:msub><mml:mo>,</mml:mo></mml:math></disp-formula>where <inline-formula id="ieqn-18"><mml:math id="mml-ieqn-18"><mml:mi>W</mml:mi></mml:math></inline-formula> is a sliding window.</p>
<p>Across <inline-formula id="ieqn-19"><mml:math id="mml-ieqn-19"><mml:mi>N</mml:mi><mml:mo>=</mml:mo><mml:mn>10</mml:mn></mml:math></inline-formula> independent runs, we report:<disp-formula id="eqn-13"><label>(13)</label><mml:math id="mml-eqn-13" display="block"><mml:mrow><mml:mover><mml:mi>R</mml:mi><mml:mo stretchy="false">&#x00AF;</mml:mo></mml:mover></mml:mrow><mml:mo>&#x00B1;</mml:mo><mml:mn>1.96</mml:mn><mml:mfrac><mml:msub><mml:mi>&#x03C3;</mml:mi><mml:mi>R</mml:mi></mml:msub><mml:msqrt><mml:mi>N</mml:mi></mml:msqrt></mml:mfrac><mml:mo>,</mml:mo></mml:math></disp-formula>and similarly for loss and policy divergence.</p>
<p>Reward stabilization occurs consistently within <inline-formula id="ieqn-20"><mml:math id="mml-ieqn-20"><mml:mn>320</mml:mn></mml:math></inline-formula>&#x2013;<inline-formula id="ieqn-21"><mml:math id="mml-ieqn-21"><mml:mn>480</mml:mn></mml:math></inline-formula> episodes, with variance below <inline-formula id="ieqn-22"><mml:math id="mml-ieqn-22"><mml:mn>5</mml:mn><mml:mi mathvariant="normal">&#x0025;</mml:mi></mml:math></inline-formula>, confirming robustness.</p>
<p>Using perturbation analysis:<disp-formula id="eqn-14"><label>(14)</label><mml:math id="mml-eqn-14" display="block"><mml:mfrac><mml:mrow><mml:mi mathvariant="normal">&#x2202;</mml:mi><mml:msup><mml:mi>&#x03C0;</mml:mi><mml:mo>&#x2217;</mml:mo></mml:msup></mml:mrow><mml:mrow><mml:mi mathvariant="normal">&#x2202;</mml:mi><mml:msub><mml:mi>&#x03BB;</mml:mi><mml:mi>i</mml:mi></mml:msub></mml:mrow></mml:mfrac><mml:mo>&#x2248;</mml:mo><mml:mfrac><mml:mrow><mml:msup><mml:mi>Q</mml:mi><mml:mrow><mml:msub><mml:mi>&#x03BB;</mml:mi><mml:mi>i</mml:mi></mml:msub><mml:mo>+</mml:mo><mml:mi mathvariant="normal">&#x0394;</mml:mi></mml:mrow></mml:msup><mml:mo>&#x2212;</mml:mo><mml:msup><mml:mi>Q</mml:mi><mml:mrow><mml:msub><mml:mi>&#x03BB;</mml:mi><mml:mi>i</mml:mi></mml:msub></mml:mrow></mml:msup></mml:mrow><mml:mi mathvariant="normal">&#x0394;</mml:mi></mml:mfrac><mml:mo>,</mml:mo></mml:math></disp-formula>we observe:<list list-type="bullet">
<list-item>
<p>Increasing <inline-formula id="ieqn-23"><mml:math id="mml-ieqn-23"><mml:msub><mml:mi>&#x03BB;</mml:mi><mml:mn>1</mml:mn></mml:msub></mml:math></inline-formula> reduces latency but increases energy consumption,</p></list-item>
<list-item>
<p>Increasing <inline-formula id="ieqn-24"><mml:math id="mml-ieqn-24"><mml:msub><mml:mi>&#x03BB;</mml:mi><mml:mn>2</mml:mn></mml:msub></mml:math></inline-formula> improves reliability at the cost of higher transmit power,</p></list-item>
<list-item>
<p>Stable operating region exists for <inline-formula id="ieqn-25"><mml:math id="mml-ieqn-25"><mml:msub><mml:mi>&#x03BB;</mml:mi><mml:mn>1</mml:mn></mml:msub><mml:mo>,</mml:mo><mml:msub><mml:mi>&#x03BB;</mml:mi><mml:mn>2</mml:mn></mml:msub><mml:mo>&#x2208;</mml:mo><mml:mo stretchy="false">[</mml:mo><mml:mn>0.2</mml:mn><mml:mo>,</mml:mo><mml:mn>0.6</mml:mn><mml:mo stretchy="false">]</mml:mo></mml:math></inline-formula>.</p></list-item>
</list></p>
<p>The per step complexity is:<disp-formula id="eqn-15"><label>(15)</label><mml:math id="mml-eqn-15" display="block"><mml:mrow><mml:mi>&#x1D4AA;</mml:mi></mml:mrow><mml:mo stretchy="false">(</mml:mo><mml:mrow><mml:mo stretchy="false">|</mml:mo></mml:mrow><mml:mrow><mml:mi>&#x1D49C;</mml:mi></mml:mrow><mml:mrow><mml:mo stretchy="false">|</mml:mo></mml:mrow><mml:mo>+</mml:mo><mml:mi>B</mml:mi><mml:mo>&#x22C5;</mml:mo><mml:mi>d</mml:mi><mml:mo stretchy="false">)</mml:mo><mml:mo>,</mml:mo></mml:math></disp-formula>where <inline-formula id="ieqn-26"><mml:math id="mml-ieqn-26"><mml:mrow><mml:mo stretchy="false">|</mml:mo></mml:mrow><mml:mrow><mml:mi>&#x1D49C;</mml:mi></mml:mrow><mml:mrow><mml:mo stretchy="false">|</mml:mo></mml:mrow></mml:math></inline-formula> is action space size, <inline-formula id="ieqn-27"><mml:math id="mml-ieqn-27"><mml:mi>B</mml:mi></mml:math></inline-formula> is batch size, and <inline-formula id="ieqn-28"><mml:math id="mml-ieqn-28"><mml:mi>d</mml:mi></mml:math></inline-formula> is network depth. Memory complexity is <inline-formula id="ieqn-29"><mml:math id="mml-ieqn-29"><mml:mrow><mml:mi>&#x1D4AA;</mml:mi></mml:mrow><mml:mo stretchy="false">(</mml:mo><mml:mrow><mml:mo stretchy="false">|</mml:mo></mml:mrow><mml:mrow><mml:mi>&#x1D49F;</mml:mi></mml:mrow><mml:mrow><mml:mo stretchy="false">|</mml:mo></mml:mrow><mml:mo stretchy="false">)</mml:mo></mml:math></inline-formula>.</p>
<p>Reproducibility details.
<list list-type="bullet">
<list-item>
<p>State discretization bins: <inline-formula id="ieqn-30"><mml:math id="mml-ieqn-30"><mml:msub><mml:mi>N</mml:mi><mml:mi>d</mml:mi></mml:msub><mml:mo>=</mml:mo><mml:mn>10</mml:mn></mml:math></inline-formula>, <inline-formula id="ieqn-31"><mml:math id="mml-ieqn-31"><mml:msub><mml:mi>N</mml:mi><mml:mrow><mml:mi>&#x03B3;</mml:mi></mml:mrow></mml:msub><mml:mo>=</mml:mo><mml:mn>8</mml:mn></mml:math></inline-formula>, <inline-formula id="ieqn-32"><mml:math id="mml-ieqn-32"><mml:msub><mml:mi>N</mml:mi><mml:mi>q</mml:mi></mml:msub><mml:mo>=</mml:mo><mml:mn>6</mml:mn></mml:math></inline-formula></p></list-item>
<list-item>
<p>Action levels: <inline-formula id="ieqn-33"><mml:math id="mml-ieqn-33"><mml:mrow><mml:mo stretchy="false">|</mml:mo></mml:mrow><mml:mrow><mml:mi>&#x1D4AB;</mml:mi></mml:mrow><mml:mrow><mml:mo stretchy="false">|</mml:mo></mml:mrow><mml:mo>=</mml:mo><mml:mn>6</mml:mn></mml:math></inline-formula>, <inline-formula id="ieqn-34"><mml:math id="mml-ieqn-34"><mml:mrow><mml:mo stretchy="false">|</mml:mo></mml:mrow><mml:mrow><mml:mi>&#x1D49F;</mml:mi></mml:mrow><mml:mrow><mml:mo stretchy="false">|</mml:mo></mml:mrow><mml:mo>=</mml:mo><mml:mn>4</mml:mn></mml:math></inline-formula>, <inline-formula id="ieqn-35"><mml:math id="mml-ieqn-35"><mml:mrow><mml:mo stretchy="false">|</mml:mo></mml:mrow><mml:mrow><mml:mi>&#x02133;</mml:mi></mml:mrow><mml:mrow><mml:mo stretchy="false">|</mml:mo></mml:mrow><mml:mo>=</mml:mo><mml:mn>3</mml:mn></mml:math></inline-formula></p></list-item>
<list-item>
<p>Learning rate: <inline-formula id="ieqn-36"><mml:math id="mml-ieqn-36"><mml:msup><mml:mn>10</mml:mn><mml:mrow><mml:mo>&#x2212;</mml:mo><mml:mn>3</mml:mn></mml:mrow></mml:msup></mml:math></inline-formula>, discount factor: <inline-formula id="ieqn-37"><mml:math id="mml-ieqn-37"><mml:mn>0.95</mml:mn></mml:math></inline-formula></p></list-item>
<list-item>
<p>Replay buffer size: <inline-formula id="ieqn-38"><mml:math id="mml-ieqn-38"><mml:msup><mml:mn>10</mml:mn><mml:mn>5</mml:mn></mml:msup></mml:math></inline-formula>, batch size: <inline-formula id="ieqn-39"><mml:math id="mml-ieqn-39"><mml:mn>64</mml:mn></mml:math></inline-formula></p></list-item>
</list></p>
<p>The software setup and implementation environment utilized during experimentation are made clear as follows.</p>
<p>The suggested structure was put into practice using:<list list-type="bullet">
<list-item>
<p>Python-based constrained Deep Q-Learning (DQL),</p></list-item>
<list-item>
<p>MQTT, CoAP, BLE, and LoRaWAN communication interfaces,</p></list-item>
<list-item>
<p>TensorFlow/PyTorch lightweight inference modules,</p></list-item>
<list-item>
<p>and custom workload scheduling utilities.</p></list-item>
</list></p>
<p>To improve reproducibility, we specify that the implementation includes:<list list-type="bullet">
<list-item>
<p>communication-aware resource scheduling,</p></list-item>
<list-item>
<p>adaptive protocol-selection policies,</p></list-item>
<list-item>
<p>residual-energy-aware transmission control,</p></list-item>
<list-item>
<p>and workload-aware duty-cycle adaptation.</p></list-item>
</list></p>
<p>Due to ongoing experimental extensions and institutional repository constraints, the complete source code is not yet publicly released. However, we state that:<list list-type="bullet">
<list-item>
<p>the implementation structure,</p></list-item>
<list-item>
<p>hyperparameter configuration,</p></list-item>
<list-item>
<p>communication settings,</p></list-item>
<list-item>
<p>and workload-generation methodology</p></list-item>
</list></p>
<p>have been described in sufficient detail to enable independent reproduction of the proposed framework.</p>
<p>We have presented an enhanced pseudo code and Algorithm 1 that describes the limited DQL based communication optimization approach in order to further enhance methodological clarity.</p>
<fig id="fig-15">
<graphic mimetype="image" mime-subtype="tif" xlink:href="CMC_83797-fig-15.tif"/>
</fig>
<p>The following is a summary of the optimization process:</p>
<p>We explicitly define the state variables:<list list-type="bullet">
<list-item>
<p><inline-formula id="ieqn-70"><mml:math id="mml-ieqn-70"><mml:msub><mml:mi>E</mml:mi><mml:mi>r</mml:mi></mml:msub></mml:math></inline-formula>: residual energy,</p></list-item>
<list-item>
<p><inline-formula id="ieqn-71"><mml:math id="mml-ieqn-71"><mml:mi>Q</mml:mi></mml:math></inline-formula>: queue occupancy,</p></list-item>
<list-item>
<p><inline-formula id="ieqn-72"><mml:math id="mml-ieqn-72"><mml:mi>D</mml:mi></mml:math></inline-formula>: communication delay,</p></list-item>
<list-item>
<p><inline-formula id="ieqn-73"><mml:math id="mml-ieqn-73"><mml:mi>T</mml:mi></mml:math></inline-formula>: traffic intensity,</p></list-item>
<list-item>
<p><inline-formula id="ieqn-74"><mml:math id="mml-ieqn-74"><mml:mi>C</mml:mi></mml:math></inline-formula>: channel quality indicator.</p></list-item>
</list></p>
<p>The reward function is clarified as:<disp-formula id="ueqn-16"><mml:math id="mml-ueqn-16" display="block"><mml:mi>R</mml:mi><mml:mo>=</mml:mo><mml:mi>&#x03B1;</mml:mi><mml:msub><mml:mi>E</mml:mi><mml:mrow><mml:mrow><mml:mtext>eff</mml:mtext></mml:mrow></mml:mrow></mml:msub><mml:mo>&#x2212;</mml:mo><mml:mi>&#x03B2;</mml:mi><mml:mi>L</mml:mi><mml:mo>+</mml:mo><mml:mi>&#x03B3;</mml:mi><mml:msub><mml:mi>T</mml:mi><mml:mi>h</mml:mi></mml:msub><mml:mo>,</mml:mo></mml:math></disp-formula>where:<list list-type="bullet">
<list-item>
<p><inline-formula id="ieqn-75"><mml:math id="mml-ieqn-75"><mml:msub><mml:mi>E</mml:mi><mml:mrow><mml:mtext>eff</mml:mtext></mml:mrow></mml:msub></mml:math></inline-formula> denotes energy efficiency,</p></list-item>
<list-item>
<p><inline-formula id="ieqn-76"><mml:math id="mml-ieqn-76"><mml:mi>L</mml:mi></mml:math></inline-formula> represents latency,</p></list-item>
<list-item>
<p>and <inline-formula id="ieqn-77"><mml:math id="mml-ieqn-77"><mml:msub><mml:mi>T</mml:mi><mml:mi>h</mml:mi></mml:msub></mml:math></inline-formula> corresponds to throughput.</p></list-item>
</list></p>
<p>This additional pseudo-code clarification and Algorithm 2 improves reproducibility and implementation transparency.</p>
<fig id="fig-16">
<graphic mimetype="image" mime-subtype="tif" xlink:href="CMC_83797-fig-16.tif"/>
</fig>
<p>In our research, synthetic workload generators were created to simulate actual IoT traffic conditions because no publicly accessible benchmark dataset adequately covered the required heterogeneous IoT communication scenarios.</p>
<p>Three main traffic models are used in the experiments:<list list-type="simple">
<list-item>
<label>1.</label>
<p><bold>Periodic Sensing Traffic</bold>
<list list-type="simple">
<list-item>
   
<p>&#x2022; fixed sensing intervals,</p></list-item>
<list-item>
<p>&#x2022; constant payload generation,</p></list-item>
<list-item>
<p>&#x2022; low transmission variability.</p></list-item>
</list></p></list-item>
<list-item>
<label>2.</label>
<p><bold>Bursty Traffic</bold>
<list list-type="simple">
<list-item>
<p>&#x2022; stochastic packet bursts,</p></list-item>
<list-item>
<p>&#x2022; temporary congestion phases,</p></list-item>
<list-item>
<p>&#x2022; variable queue occupancy.</p></list-item>
</list></p></list-item>
<list-item>
<label>3.</label>
<p><bold>Event-Driven Traffic</bold>
<list list-type="simple">
<list-item>
<p>&#x2022; irregular transmission events,</p></list-item>
<list-item>
<p>&#x2022; asynchronous workload activation,</p></list-item>
<list-item>
<p>&#x2022; latency-sensitive communication behavior.</p></list-item>
</list></p></list-item>
</list></p>
<p>Traffic generation intervals were modeled using:<disp-formula id="ueqn-17"><mml:math id="mml-ueqn-17" display="block"><mml:mi>&#x03BB;</mml:mi><mml:mo stretchy="false">(</mml:mo><mml:mi>t</mml:mi><mml:mo stretchy="false">)</mml:mo><mml:mo>=</mml:mo><mml:msub><mml:mi>&#x03BB;</mml:mi><mml:mn>0</mml:mn></mml:msub><mml:mo>+</mml:mo><mml:mi mathvariant="normal">&#x0394;</mml:mi><mml:mi>&#x03BB;</mml:mi><mml:mo stretchy="false">(</mml:mo><mml:mi>t</mml:mi><mml:mo stretchy="false">)</mml:mo><mml:mo>,</mml:mo></mml:math></disp-formula>where:<list list-type="bullet">
<list-item>
<p><inline-formula id="ieqn-84"><mml:math id="mml-ieqn-84"><mml:msub><mml:mi>&#x03BB;</mml:mi><mml:mn>0</mml:mn></mml:msub></mml:math></inline-formula> denotes the baseline arrival rate,</p></list-item>
<list-item>
<p>and <inline-formula id="ieqn-85"><mml:math id="mml-ieqn-85"><mml:mi mathvariant="normal">&#x0394;</mml:mi><mml:mi>&#x03BB;</mml:mi><mml:mo stretchy="false">(</mml:mo><mml:mi>t</mml:mi><mml:mo stretchy="false">)</mml:mo></mml:math></inline-formula> represents workload fluctuations.</p></list-item>
</list></p>
<p>Packet arrival behavior for bursty workloads was approximated using Poisson-distributed arrivals:<disp-formula id="ueqn-18"><mml:math id="mml-ueqn-18" display="block"><mml:mi>P</mml:mi><mml:mo stretchy="false">(</mml:mo><mml:mi>k</mml:mi><mml:mo stretchy="false">)</mml:mo><mml:mo>=</mml:mo><mml:mfrac><mml:mrow><mml:msup><mml:mi>&#x03BB;</mml:mi><mml:mi>k</mml:mi></mml:msup><mml:msup><mml:mi>e</mml:mi><mml:mrow><mml:mo>&#x2212;</mml:mo><mml:mi>&#x03BB;</mml:mi></mml:mrow></mml:msup></mml:mrow><mml:mrow><mml:mi>k</mml:mi><mml:mo>!</mml:mo></mml:mrow></mml:mfrac><mml:mo>.</mml:mo></mml:math></disp-formula></p>
<p>We additionally clarify that all communication protocols were evaluated under:<list list-type="bullet">
<list-item>
<p>identical payload sizes,</p></list-item>
<list-item>
<p>identical observation windows,</p></list-item>
<list-item>
<p>synchronized traffic generation intervals,</p></list-item>
<list-item>
<p>and consistent workload scheduling configurations.</p></list-item>
</list></p>
<p>This ensures fair protocol comparison and reduces experimental bias.</p>
<sec id="s4_1">
<label>4.1</label>
<title>Research Novelty and Distinction from Existing Reinforcement Learning Approaches</title>
<p>In contrast to conventional restricted RL techniques that optimize a single parameter like latency, throughput, or energy consumption, the proposed framework presents an integrated adaptive communication-computation optimization architecture for energy-constrained IoT as well as swarm robotic systems. The recommended method concurrently incorporates:<list list-type="bullet">
<list-item>
<p>adaptive protocol selection among BLE, MQTT, CoAP, and LoRaWAN,</p></list-item>
<list-item>
<p>workload-aware duty-cycle adaptation,</p></list-item>
<list-item>
<p>residual-energy-aware transmission control,</p></list-item>
<list-item>
<p>constrained Deep Q-Learning (DQL),</p></list-item>
<list-item>
<p>and communication-aware resource scheduling.</p></list-item>
</list></p>
<p>The main innovation is the <bold>cross-layer optimization strategy</bold>, that maximizes energy dynamics, computing effort, and communication overhead in a variety of traffic scenarios. Instead of modeling protocol switching, dynamic duty cycling, and workload dependent communication behavior, existing constrained RL algorithms in IoT optimization frequently concentrate on specific objectives, such as routing optimization, job offloading, or energy management.</p>
<p>Furthermore, the following are some ways that the suggested model varies from earlier restricted RL approaches:<list list-type="simple">
<list-item>
<label>1.</label>
<p><bold>Constraint-Aware Hybridization:</bold> Instead of relying solely on RL exploration, the framework combines heuristic adaptation rules with constrained DQL policies. This hybridization improves convergence stability and reduces unsafe exploration in energy-constrained IoT deployments.</p></list-item>
<list-item>
<label>2.</label>
<p><bold>Traffic-Adaptive Optimization:</bold> The system dynamically modifies communication behavior to accommodate periodic, bursty, and event-driven traffic circumstances. Static or basic traffic models are often used in traditional RL based IoT optimization solutions.</p></list-item>
<list-item>
<label>3.</label>
<p><bold>Protocol-Level Intelligence:</bold> Adaptive protocol switching is used in the proposed system based on residual energy, channel quality, and transmission range. Rather of actively choosing between many protocols, the majority of constrained RL approaches optimize parameters contained within a particular communication protocol.</p></list-item>
<list-item>
<label>4.</label>
<p><bold>Scalability-Oriented Design:</bold> To decrease computational as well as communication overhead within swarm scale deployments, the framework implements parameter sharing, event triggered update processes, federated aggregation, as well as lightweight model compression. This allows for scalability beyond traditional centralized RL techniques.</p></list-item>
<list-item>
<label>5.</label>
<p><bold>Communication&#x2013;Computation Co-Optimization:</bold> Existing constrained RL studies generally optimize communication or computation independently. In contrast, the proposed framework jointly models:<disp-formula id="ueqn-19"><mml:math id="mml-ueqn-19" display="block"><mml:msub><mml:mi>E</mml:mi><mml:mrow><mml:mrow><mml:mtext>total</mml:mtext></mml:mrow></mml:mrow></mml:msub><mml:mo>=</mml:mo><mml:msub><mml:mi>E</mml:mi><mml:mrow><mml:mrow><mml:mtext>comm</mml:mtext></mml:mrow></mml:mrow></mml:msub><mml:mo>+</mml:mo><mml:msub><mml:mi>E</mml:mi><mml:mrow><mml:mrow><mml:mtext>comp</mml:mtext></mml:mrow></mml:mrow></mml:msub><mml:mo>+</mml:mo><mml:msub><mml:mi>E</mml:mi><mml:mrow><mml:mrow><mml:mtext>idle</mml:mtext></mml:mrow></mml:mrow></mml:msub><mml:mo>,</mml:mo></mml:math></disp-formula>thereby enabling coordinated optimization of communication energy, processing overhead, and idle-state consumption.</p></list-item>
<list-item>
<label>6.</label>
<p><bold>Experimentally Validated Adaptive Framework:</bold> The suggested architecture is proven on a regulated NVIDIA Jetson TX2 experimental architecture with various communication stacks as well as realistic workload situations, such as periodic, bursty, as well as event-driven traffic models. Comparative assessments show significant improvements over fixed power, rule based, as well as DQL only baselines.</p></list-item>
</list></p>
<p>Our contribution is not merely the application of reinforcement learning to IoT optimization, but rather the development of a <italic>constraint-aware, cross-layer, hybrid adaptive framework</italic> that jointly optimizes communication efficiency, computation workload, protocol behavior, and energy sustainability for heterogeneous IoT and swarm robotic environments.</p>
<p>Additionally, we highlight that the proposed constrained DQL framework achieves:<list list-type="bullet">
<list-item>
<p>approximately <inline-formula id="ieqn-86"><mml:math id="mml-ieqn-86"><mml:mn>25</mml:mn><mml:mi mathvariant="normal">&#x0025;</mml:mi></mml:math></inline-formula> improvement over fixed-power baselines,</p></list-item>
<list-item>
<p>15%&#x2013;20% gains over rule-based methods,</p></list-item>
<list-item>
<p>and 8%&#x2013;12% gains over model-based heuristic approaches,</p></list-item>
</list></p>
<p>while maintaining stable operation under varying traffic patterns and communication conditions.</p>
</sec>
<sec id="s4_2">
<label>4.2</label>
<title>Energy and Communication Model</title>
<p>We model the total energy consumed by a node as the sum of sensing, processing, communication, and idle energies:<disp-formula id="eqn-16"><label>(16)</label><mml:math id="mml-eqn-16" display="block"><mml:msub><mml:mi>E</mml:mi><mml:mrow><mml:mrow><mml:mtext>Total</mml:mtext></mml:mrow></mml:mrow></mml:msub><mml:mo>=</mml:mo><mml:msub><mml:mi>E</mml:mi><mml:mrow><mml:mrow><mml:mtext>Sense</mml:mtext></mml:mrow></mml:mrow></mml:msub><mml:mo>+</mml:mo><mml:msub><mml:mi>E</mml:mi><mml:mrow><mml:mrow><mml:mtext>Process</mml:mtext></mml:mrow></mml:mrow></mml:msub><mml:mo>+</mml:mo><mml:msub><mml:mi>E</mml:mi><mml:mrow><mml:mrow><mml:mtext>Comm</mml:mtext></mml:mrow></mml:mrow></mml:msub><mml:mo>+</mml:mo><mml:msub><mml:mi>E</mml:mi><mml:mrow><mml:mrow><mml:mtext>Idle</mml:mtext></mml:mrow></mml:mrow></mml:msub></mml:math></disp-formula></p>
<p>Here <inline-formula id="ieqn-87"><mml:math id="mml-ieqn-87"><mml:msub><mml:mi>E</mml:mi><mml:mrow><mml:mtext>Comm</mml:mtext></mml:mrow></mml:msub></mml:math></inline-formula> accounts for radio transmission, reception, listening, and protocol overhead. For example, transmitting a data packet of size <inline-formula id="ieqn-88"><mml:math id="mml-ieqn-88"><mml:msub><mml:mi>S</mml:mi><mml:mrow><mml:mtext>data</mml:mtext></mml:mrow></mml:msub></mml:math></inline-formula> at power <inline-formula id="ieqn-89"><mml:math id="mml-ieqn-89"><mml:msub><mml:mi>P</mml:mi><mml:mrow><mml:mtext>tx</mml:mtext></mml:mrow></mml:msub></mml:math></inline-formula> over time <inline-formula id="ieqn-90"><mml:math id="mml-ieqn-90"><mml:msub><mml:mi>t</mml:mi><mml:mrow><mml:mtext>tx</mml:mtext></mml:mrow></mml:msub></mml:math></inline-formula> consumes
<disp-formula id="eqn-17"><label>(17)</label><mml:math id="mml-eqn-17" display="block"><mml:msub><mml:mi>E</mml:mi><mml:mrow><mml:mrow><mml:mtext>tx</mml:mtext></mml:mrow></mml:mrow></mml:msub><mml:mo>=</mml:mo><mml:msub><mml:mi>P</mml:mi><mml:mrow><mml:mrow><mml:mtext>tx</mml:mtext></mml:mrow></mml:mrow></mml:msub><mml:mo>&#x22C5;</mml:mo><mml:msub><mml:mi>t</mml:mi><mml:mrow><mml:mrow><mml:mtext>tx</mml:mtext></mml:mrow></mml:mrow></mml:msub><mml:mo>=</mml:mo><mml:msub><mml:mi>P</mml:mi><mml:mrow><mml:mrow><mml:mtext>tx</mml:mtext></mml:mrow></mml:mrow></mml:msub><mml:mo>&#x22C5;</mml:mo><mml:mfrac><mml:msub><mml:mi>S</mml:mi><mml:mrow><mml:mrow><mml:mtext>data</mml:mtext></mml:mrow></mml:mrow></mml:msub><mml:msub><mml:mi>R</mml:mi><mml:mrow><mml:mrow><mml:mtext>data</mml:mtext></mml:mrow></mml:mrow></mml:msub></mml:mfrac></mml:math></disp-formula>where <inline-formula id="ieqn-91"><mml:math id="mml-ieqn-91"><mml:msub><mml:mi>R</mml:mi><mml:mrow><mml:mtext>data</mml:mtext></mml:mrow></mml:msub></mml:math></inline-formula> is the data rate. Reception consumes <inline-formula id="ieqn-92"><mml:math id="mml-ieqn-92"><mml:msub><mml:mi>E</mml:mi><mml:mrow><mml:mtext>rx</mml:mtext></mml:mrow></mml:msub><mml:mo>=</mml:mo><mml:msub><mml:mi>P</mml:mi><mml:mrow><mml:mtext>rx</mml:mtext></mml:mrow></mml:msub><mml:mo>&#x22C5;</mml:mo><mml:msub><mml:mi>t</mml:mi><mml:mrow><mml:mtext>rx</mml:mtext></mml:mrow></mml:msub></mml:math></inline-formula>, and the radio listening (idle receive) mode uses <inline-formula id="ieqn-93"><mml:math id="mml-ieqn-93"><mml:msub><mml:mi>E</mml:mi><mml:mrow><mml:mtext>listen</mml:mtext></mml:mrow></mml:msub><mml:mo>=</mml:mo><mml:msub><mml:mi>P</mml:mi><mml:mrow><mml:mtext>listen</mml:mtext></mml:mrow></mml:msub><mml:mo>&#x22C5;</mml:mo><mml:msub><mml:mi>t</mml:mi><mml:mrow><mml:mtext>listen</mml:mtext></mml:mrow></mml:msub></mml:math></inline-formula>. Additional overhead (handshakes, acknowledgments, synchronization) is denoted <inline-formula id="ieqn-94"><mml:math id="mml-ieqn-94"><mml:msub><mml:mi>E</mml:mi><mml:mrow><mml:mtext>overhead</mml:mtext></mml:mrow></mml:msub></mml:math></inline-formula>. Thus, the communication energy is
<disp-formula id="eqn-18"><label>(18)</label><mml:math id="mml-eqn-18" display="block"><mml:msub><mml:mi>E</mml:mi><mml:mrow><mml:mrow><mml:mtext>Comm</mml:mtext></mml:mrow></mml:mrow></mml:msub><mml:mo>=</mml:mo><mml:msub><mml:mi>E</mml:mi><mml:mrow><mml:mrow><mml:mtext>tx</mml:mtext></mml:mrow></mml:mrow></mml:msub><mml:mo>+</mml:mo><mml:msub><mml:mi>E</mml:mi><mml:mrow><mml:mrow><mml:mtext>rx</mml:mtext></mml:mrow></mml:mrow></mml:msub><mml:mo>+</mml:mo><mml:msub><mml:mi>E</mml:mi><mml:mrow><mml:mrow><mml:mtext>listen</mml:mtext></mml:mrow></mml:mrow></mml:msub><mml:mo>+</mml:mo><mml:msub><mml:mi>E</mml:mi><mml:mrow><mml:mrow><mml:mtext>overhead</mml:mtext></mml:mrow></mml:mrow></mml:msub></mml:math></disp-formula></p>
<p>Devices often use duty cycling to save power, alternating active periods (<inline-formula id="ieqn-95"><mml:math id="mml-ieqn-95"><mml:msub><mml:mi>t</mml:mi><mml:mrow><mml:mtext>active</mml:mtext></mml:mrow></mml:msub></mml:math></inline-formula>) with sleep periods (<inline-formula id="ieqn-96"><mml:math id="mml-ieqn-96"><mml:msub><mml:mi>t</mml:mi><mml:mrow><mml:mtext>sleep</mml:mtext></mml:mrow></mml:msub></mml:math></inline-formula>). The duty cycle is defined as
<disp-formula id="eqn-19"><label>(19)</label><mml:math id="mml-eqn-19" display="block"><mml:mi>D</mml:mi><mml:mo>=</mml:mo><mml:mfrac><mml:msub><mml:mi>t</mml:mi><mml:mrow><mml:mrow><mml:mtext>active</mml:mtext></mml:mrow></mml:mrow></mml:msub><mml:mrow><mml:msub><mml:mi>t</mml:mi><mml:mrow><mml:mrow><mml:mtext>active</mml:mtext></mml:mrow></mml:mrow></mml:msub><mml:mo>+</mml:mo><mml:msub><mml:mi>t</mml:mi><mml:mrow><mml:mrow><mml:mtext>sleep</mml:mtext></mml:mrow></mml:mrow></mml:msub></mml:mrow></mml:mfrac><mml:mspace width="thinmathspace" /></mml:math></disp-formula></p>
<p>The transmission power <inline-formula id="ieqn-97"><mml:math id="mml-ieqn-97"><mml:msub><mml:mi>P</mml:mi><mml:mrow><mml:mtext>tx</mml:mtext></mml:mrow></mml:msub></mml:math></inline-formula> is a controllable parameter. In free space, path loss grows roughly with distance <inline-formula id="ieqn-98"><mml:math id="mml-ieqn-98"><mml:mi>d</mml:mi></mml:math></inline-formula> as <inline-formula id="ieqn-99"><mml:math id="mml-ieqn-99"><mml:msup><mml:mi>d</mml:mi><mml:mi>n</mml:mi></mml:msup></mml:math></inline-formula> (with exponent <inline-formula id="ieqn-100"><mml:math id="mml-ieqn-100"><mml:mi>n</mml:mi><mml:mo>&#x2248;</mml:mo><mml:mn>2</mml:mn></mml:math></inline-formula>&#x2013;4). We can adapt <inline-formula id="ieqn-101"><mml:math id="mml-ieqn-101"><mml:msub><mml:mi>P</mml:mi><mml:mrow><mml:mtext>tx</mml:mtext></mml:mrow></mml:msub><mml:mo stretchy="false">(</mml:mo><mml:mi>d</mml:mi><mml:mo stretchy="false">)</mml:mo></mml:math></inline-formula> dynamically.
<disp-formula id="eqn-20"><label>(20)</label><mml:math id="mml-eqn-20" display="block"><mml:msubsup><mml:mi>P</mml:mi><mml:mrow><mml:mrow><mml:mtext>tx</mml:mtext></mml:mrow></mml:mrow><mml:mrow><mml:mrow><mml:mtext>dBm</mml:mtext></mml:mrow></mml:mrow></mml:msubsup><mml:mo stretchy="false">(</mml:mo><mml:mi>d</mml:mi><mml:mo stretchy="false">)</mml:mo><mml:mo>=</mml:mo><mml:msubsup><mml:mi>P</mml:mi><mml:mrow><mml:mrow><mml:mtext>rx,req</mml:mtext></mml:mrow></mml:mrow><mml:mrow><mml:mrow><mml:mtext>dBm</mml:mtext></mml:mrow></mml:mrow></mml:msubsup><mml:mo>+</mml:mo><mml:mi>P</mml:mi><mml:msub><mml:mi>L</mml:mi><mml:mn>0</mml:mn></mml:msub><mml:mo>+</mml:mo><mml:mn>10</mml:mn><mml:mi>n</mml:mi><mml:msub><mml:mi>log</mml:mi><mml:mrow><mml:mn>10</mml:mn></mml:mrow></mml:msub><mml:mspace width="negativethinmathspace" /><mml:mrow><mml:mo>(</mml:mo><mml:mfrac><mml:mi>d</mml:mi><mml:msub><mml:mi>d</mml:mi><mml:mn>0</mml:mn></mml:msub></mml:mfrac><mml:mo>)</mml:mo></mml:mrow><mml:mo>+</mml:mo><mml:msub><mml:mi>X</mml:mi><mml:mrow><mml:mi>&#x03C3;</mml:mi></mml:mrow></mml:msub><mml:mo>+</mml:mo><mml:msub><mml:mi>M</mml:mi><mml:mrow><mml:mrow><mml:mtext>fad</mml:mtext></mml:mrow></mml:mrow></mml:msub><mml:mo>,</mml:mo></mml:math></disp-formula>where <inline-formula id="ieqn-102"><mml:math id="mml-ieqn-102"><mml:msubsup><mml:mi>P</mml:mi><mml:mrow><mml:mtext>rx,req</mml:mtext></mml:mrow><mml:mrow><mml:mtext>dBm</mml:mtext></mml:mrow></mml:msubsup></mml:math></inline-formula> is the minimum required received power for reliable decoding, <inline-formula id="ieqn-103"><mml:math id="mml-ieqn-103"><mml:mi>P</mml:mi><mml:msub><mml:mi>L</mml:mi><mml:mn>0</mml:mn></mml:msub></mml:math></inline-formula> is the reference path loss at distance <inline-formula id="ieqn-104"><mml:math id="mml-ieqn-104"><mml:msub><mml:mi>d</mml:mi><mml:mn>0</mml:mn></mml:msub></mml:math></inline-formula>, <inline-formula id="ieqn-105"><mml:math id="mml-ieqn-105"><mml:mi>n</mml:mi></mml:math></inline-formula> is the path loss exponent, <inline-formula id="ieqn-106"><mml:math id="mml-ieqn-106"><mml:msub><mml:mi>X</mml:mi><mml:mrow><mml:mi>&#x03C3;</mml:mi></mml:mrow></mml:msub><mml:mo>&#x223C;</mml:mo><mml:mrow><mml:mi>&#x1D4A9;</mml:mi></mml:mrow><mml:mo stretchy="false">(</mml:mo><mml:mn>0</mml:mn><mml:mo>,</mml:mo><mml:msup><mml:mi>&#x03C3;</mml:mi><mml:mn>2</mml:mn></mml:msup><mml:mo stretchy="false">)</mml:mo></mml:math></inline-formula> is the log-normal shadowing term in dB, and <inline-formula id="ieqn-107"><mml:math id="mml-ieqn-107"><mml:msub><mml:mi>M</mml:mi><mml:mrow><mml:mtext>fad</mml:mtext></mml:mrow></mml:msub></mml:math></inline-formula> is a fading margin that accounts for fast channel variations due to multipath.</p>
<p>For completeness, the corresponding linear transmit power can be written as
<disp-formula id="eqn-21"><label>(21)</label><mml:math id="mml-eqn-21" display="block"><mml:msub><mml:mi>P</mml:mi><mml:mrow><mml:mrow><mml:mtext>tx</mml:mtext></mml:mrow></mml:mrow></mml:msub><mml:mo stretchy="false">(</mml:mo><mml:mi>d</mml:mi><mml:mo stretchy="false">)</mml:mo><mml:mo>=</mml:mo><mml:msup><mml:mn>10</mml:mn><mml:mrow><mml:msubsup><mml:mi>P</mml:mi><mml:mrow><mml:mrow><mml:mtext>tx</mml:mtext></mml:mrow></mml:mrow><mml:mrow><mml:mrow><mml:mtext>dBm</mml:mtext></mml:mrow></mml:mrow></mml:msubsup><mml:mo stretchy="false">(</mml:mo><mml:mi>d</mml:mi><mml:mo stretchy="false">)</mml:mo><mml:mrow><mml:mo>/</mml:mo></mml:mrow><mml:mn>10</mml:mn></mml:mrow></mml:msup><mml:mtext>&#x00A0;</mml:mtext><mml:mrow><mml:mtext>mW</mml:mtext></mml:mrow><mml:mo>.</mml:mo></mml:math></disp-formula></p>
<p>In this approach, <italic>shadowing</italic> represents a gradual attenuation caused by obstructions, body blockage, and environment specific propagation loss. <italic>fading</italic> reflects rapid fluctuations triggered by both destructive and constructive interference. <italic>multipath</italic> impacts are incorporated into the fading parameter and outage margin. As a result, the adaptable controller does not pick transmit power merely as a deterministic expression of distance traveled, but rather a power level that meets a desired probability of outages under uncertainty. A practical implementation can replace <inline-formula id="ieqn-108"><mml:math id="mml-ieqn-108"><mml:msub><mml:mi>M</mml:mi><mml:mrow><mml:mtext>fad</mml:mtext></mml:mrow></mml:msub></mml:math></inline-formula> by a quantile based safety margin, e.g., <inline-formula id="ieqn-109"><mml:math id="mml-ieqn-109"><mml:msub><mml:mi>M</mml:mi><mml:mrow><mml:mtext>fad</mml:mtext></mml:mrow></mml:msub><mml:mo>=</mml:mo><mml:msub><mml:mi>z</mml:mi><mml:mrow><mml:mn>1</mml:mn><mml:mo>&#x2212;</mml:mo><mml:mo>&#x03B5;</mml:mo></mml:mrow></mml:msub><mml:mi>&#x03C3;</mml:mi><mml:mo>,</mml:mo></mml:math></inline-formula> where <inline-formula id="ieqn-110"><mml:math id="mml-ieqn-110"><mml:mo>&#x03B5;</mml:mo></mml:math></inline-formula> is the acceptable outage probability.</p>
<p>The suggested control method becomes more successful as the shadowing standard deviation <inline-formula id="ieqn-111"><mml:math id="mml-ieqn-111"><mml:mi>&#x03C3;</mml:mi></mml:math></inline-formula> and route loss parameter <inline-formula id="ieqn-112"><mml:math id="mml-ieqn-112"><mml:mi>n</mml:mi></mml:math></inline-formula> increase. The strategy may promote low-power transmission, long sleep intervals, and aggressive local execution when <inline-formula id="ieqn-113"><mml:math id="mml-ieqn-113"><mml:mi>n</mml:mi></mml:math></inline-formula> is small (e.g., in nearly open space), as the required transmit power progressively grows with distance. The strategy shifts to higher transmission power, shorter duty cycle times, early protocol adjustments, or work offloading as <inline-formula id="ieqn-114"><mml:math id="mml-ieqn-114"><mml:mi>n</mml:mi></mml:math></inline-formula> increases and the link budget drops more quickly. Similarly, higher <inline-formula id="ieqn-115"><mml:math id="mml-ieqn-115"><mml:mi>&#x03C3;</mml:mi></mml:math></inline-formula> raises uncertainty in the received signal strength. Since, the control unit must set a higher safety margin, which increases average transmit power while decreasing the likelihood of energy consuming activities. In reality, the DQL policy ought to determine these regime shifts by analyzing channel state statistics. The deterministic fallback ought to implement cautious judgments whenever <inline-formula id="ieqn-116"><mml:math id="mml-ieqn-116"><mml:mi>n</mml:mi></mml:math></inline-formula> or <inline-formula id="ieqn-117"><mml:math id="mml-ieqn-117"><mml:mi>&#x03C3;</mml:mi></mml:math></inline-formula> indicates a significant outage risk.</p>
<p>This stochastic approach more accurately represents indoor and outdoor IoT installations, where blocking, fading, as well as multipath behavior may lead to a similar nominal distance to necessitate significantly different transmit powers. It also provides a principled basis for adaptive decisions in the reward driven controller, since the selected action now depends not only on distance but also on channel uncertainty.</p>
<p>However, we also incorporate the node&#x2019;s residual energy <inline-formula id="ieqn-118"><mml:math id="mml-ieqn-118"><mml:msub><mml:mi>E</mml:mi><mml:mrow><mml:mtext>res</mml:mtext></mml:mrow></mml:msub></mml:math></inline-formula> into the decision. For example, an adaptive thresholding rule sets the new power <inline-formula id="ieqn-119"><mml:math id="mml-ieqn-119"><mml:msubsup><mml:mi>P</mml:mi><mml:mrow><mml:mtext>tx</mml:mtext></mml:mrow><mml:mi mathvariant="normal">&#x2032;</mml:mi></mml:msubsup></mml:math></inline-formula> based on previous power <inline-formula id="ieqn-120"><mml:math id="mml-ieqn-120"><mml:msub><mml:mi>P</mml:mi><mml:mrow><mml:mtext>prev</mml:mtext></mml:mrow></mml:msub></mml:math></inline-formula> and energy level:<disp-formula id="eqn-22"><label>(22)</label><mml:math id="mml-eqn-22" display="block"><mml:msubsup><mml:mi>P</mml:mi><mml:mrow><mml:mrow><mml:mtext>tx</mml:mtext></mml:mrow></mml:mrow><mml:mi mathvariant="normal">&#x2032;</mml:mi></mml:msubsup><mml:mtext>&#x00A0;</mml:mtext><mml:mo>=</mml:mo><mml:mtext>&#x00A0;</mml:mtext><mml:msub><mml:mi>P</mml:mi><mml:mrow><mml:mrow><mml:mtext>prev</mml:mtext></mml:mrow></mml:mrow></mml:msub><mml:mo>&#x00D7;</mml:mo><mml:mfrac><mml:msub><mml:mi>E</mml:mi><mml:mrow><mml:mrow><mml:mtext>res</mml:mtext></mml:mrow></mml:mrow></mml:msub><mml:msub><mml:mi>E</mml:mi><mml:mrow><mml:mo movablelimits="true" form="prefix">max</mml:mo></mml:mrow></mml:msub></mml:mfrac></mml:math></disp-formula>so that as the energy buffer depletes, the node lowers its transmit power to conserve energy.</p>
<p>The total energy consumed over an observation window <inline-formula id="ieqn-121"><mml:math id="mml-ieqn-121"><mml:msub><mml:mi>T</mml:mi><mml:mrow><mml:mtext>obs</mml:mtext></mml:mrow></mml:msub></mml:math></inline-formula> is written as
<disp-formula id="eqn-23"><label>(23)</label><mml:math id="mml-eqn-23" display="block"><mml:msub><mml:mi>E</mml:mi><mml:mrow><mml:mrow><mml:mtext>total</mml:mtext></mml:mrow></mml:mrow></mml:msub><mml:mo>=</mml:mo><mml:msub><mml:mi>E</mml:mi><mml:mrow><mml:mrow><mml:mtext>comm</mml:mtext></mml:mrow></mml:mrow></mml:msub><mml:mo>+</mml:mo><mml:msub><mml:mi>E</mml:mi><mml:mrow><mml:mrow><mml:mtext>comp</mml:mtext></mml:mrow></mml:mrow></mml:msub><mml:mo>+</mml:mo><mml:msub><mml:mi>E</mml:mi><mml:mrow><mml:mrow><mml:mtext>sense</mml:mtext></mml:mrow></mml:mrow></mml:msub><mml:mo>+</mml:mo><mml:msub><mml:mi>E</mml:mi><mml:mrow><mml:mrow><mml:mtext>idle</mml:mtext></mml:mrow></mml:mrow></mml:msub><mml:mo>,</mml:mo></mml:math></disp-formula>where <inline-formula id="ieqn-122"><mml:math id="mml-ieqn-122"><mml:msub><mml:mi>E</mml:mi><mml:mrow><mml:mtext>comm</mml:mtext></mml:mrow></mml:msub></mml:math></inline-formula> includes transmission, reception, listening, and protocol overhead, while <inline-formula id="ieqn-123"><mml:math id="mml-ieqn-123"><mml:msub><mml:mi>E</mml:mi><mml:mrow><mml:mtext>comp</mml:mtext></mml:mrow></mml:msub></mml:math></inline-formula>, <inline-formula id="ieqn-124"><mml:math id="mml-ieqn-124"><mml:msub><mml:mi>E</mml:mi><mml:mrow><mml:mtext>sense</mml:mtext></mml:mrow></mml:msub></mml:math></inline-formula>, and <inline-formula id="ieqn-125"><mml:math id="mml-ieqn-125"><mml:msub><mml:mi>E</mml:mi><mml:mrow><mml:mtext>idle</mml:mtext></mml:mrow></mml:msub></mml:math></inline-formula> capture CPU, sensing, and standby costs, respectively.</p>
<p>Let <inline-formula id="ieqn-126"><mml:math id="mml-ieqn-126"><mml:mi>k</mml:mi></mml:math></inline-formula> denote a discrete control interval. The instantaneous received signal to interference plus noise ratio (SINR) is modeled as
<disp-formula id="eqn-24"><label>(24)</label><mml:math id="mml-eqn-24" display="block"><mml:msub><mml:mi>&#x03B3;</mml:mi><mml:mi>k</mml:mi></mml:msub><mml:mo>=</mml:mo><mml:mfrac><mml:mrow><mml:msub><mml:mi>P</mml:mi><mml:mrow><mml:mrow><mml:mtext>tx</mml:mtext></mml:mrow></mml:mrow></mml:msub><mml:mo stretchy="false">[</mml:mo><mml:mi>k</mml:mi><mml:mo stretchy="false">]</mml:mo><mml:mspace width="thinmathspace" /><mml:msub><mml:mi>G</mml:mi><mml:mi>k</mml:mi></mml:msub><mml:mspace width="thinmathspace" /><mml:msup><mml:mn>10</mml:mn><mml:mrow><mml:mo>&#x2212;</mml:mo><mml:msub><mml:mi>X</mml:mi><mml:mrow><mml:mi>&#x03C3;</mml:mi></mml:mrow></mml:msub><mml:mrow><mml:mo>/</mml:mo></mml:mrow><mml:mn>10</mml:mn></mml:mrow></mml:msup><mml:mspace width="thinmathspace" /><mml:mrow><mml:mo stretchy="false">|</mml:mo></mml:mrow><mml:msub><mml:mi>h</mml:mi><mml:mi>k</mml:mi></mml:msub><mml:msup><mml:mrow><mml:mo stretchy="false">|</mml:mo></mml:mrow><mml:mn>2</mml:mn></mml:msup></mml:mrow><mml:mrow><mml:msub><mml:mi>N</mml:mi><mml:mn>0</mml:mn></mml:msub><mml:mi>B</mml:mi><mml:mo>+</mml:mo><mml:msub><mml:mi>I</mml:mi><mml:mi>k</mml:mi></mml:msub></mml:mrow></mml:mfrac><mml:mo>,</mml:mo></mml:math></disp-formula>where <inline-formula id="ieqn-127"><mml:math id="mml-ieqn-127"><mml:msub><mml:mi>P</mml:mi><mml:mrow><mml:mtext>tx</mml:mtext></mml:mrow></mml:msub><mml:mo stretchy="false">[</mml:mo><mml:mi>k</mml:mi><mml:mo stretchy="false">]</mml:mo></mml:math></inline-formula> is the transmit power, <inline-formula id="ieqn-128"><mml:math id="mml-ieqn-128"><mml:msub><mml:mi>G</mml:mi><mml:mi>k</mml:mi></mml:msub><mml:mo>=</mml:mo><mml:msub><mml:mi>G</mml:mi><mml:mi>t</mml:mi></mml:msub><mml:msub><mml:mi>G</mml:mi><mml:mi>r</mml:mi></mml:msub><mml:msup><mml:mrow><mml:mo>(</mml:mo><mml:mfrac><mml:msub><mml:mi>&#x03BB;</mml:mi><mml:mi>c</mml:mi></mml:msub><mml:mrow><mml:mn>4</mml:mn><mml:mi>&#x03C0;</mml:mi><mml:msub><mml:mi>d</mml:mi><mml:mi>k</mml:mi></mml:msub></mml:mrow></mml:mfrac><mml:mo>)</mml:mo></mml:mrow><mml:mi>n</mml:mi></mml:msup></mml:math></inline-formula> is the distance dependent path gain, <inline-formula id="ieqn-129"><mml:math id="mml-ieqn-129"><mml:msub><mml:mi>d</mml:mi><mml:mi>k</mml:mi></mml:msub></mml:math></inline-formula> is the link distance, <inline-formula id="ieqn-130"><mml:math id="mml-ieqn-130"><mml:mi>n</mml:mi></mml:math></inline-formula> is the path loss exponent, <inline-formula id="ieqn-131"><mml:math id="mml-ieqn-131"><mml:msub><mml:mi>X</mml:mi><mml:mrow><mml:mi>&#x03C3;</mml:mi></mml:mrow></mml:msub><mml:mo>&#x223C;</mml:mo><mml:mrow><mml:mi>&#x1D4A9;</mml:mi></mml:mrow><mml:mo stretchy="false">(</mml:mo><mml:mn>0</mml:mn><mml:mo>,</mml:mo><mml:msup><mml:mi>&#x03C3;</mml:mi><mml:mn>2</mml:mn></mml:msup><mml:mo stretchy="false">)</mml:mo></mml:math></inline-formula> is the log normal shadowing term in dB, <inline-formula id="ieqn-132"><mml:math id="mml-ieqn-132"><mml:mrow><mml:mo stretchy="false">|</mml:mo></mml:mrow><mml:msub><mml:mi>h</mml:mi><mml:mi>k</mml:mi></mml:msub><mml:msup><mml:mrow><mml:mo stretchy="false">|</mml:mo></mml:mrow><mml:mn>2</mml:mn></mml:msup></mml:math></inline-formula> captures fast fading, <inline-formula id="ieqn-133"><mml:math id="mml-ieqn-133"><mml:msub><mml:mi>I</mml:mi><mml:mi>k</mml:mi></mml:msub></mml:math></inline-formula> denotes co-channel interference, <inline-formula id="ieqn-134"><mml:math id="mml-ieqn-134"><mml:msub><mml:mi>N</mml:mi><mml:mn>0</mml:mn></mml:msub></mml:math></inline-formula> is the noise spectral density, and <inline-formula id="ieqn-135"><mml:math id="mml-ieqn-135"><mml:mi>B</mml:mi></mml:math></inline-formula> is the receiver bandwidth.</p>
<p>This formulation fully accounts for the influence from fading, shadowing, multipath propagation, as well as interference on the needed transmit power. The adaptive controller chooses <inline-formula id="ieqn-136"><mml:math id="mml-ieqn-136"><mml:msub><mml:mi>P</mml:mi><mml:mrow><mml:mtext>tx</mml:mtext></mml:mrow></mml:msub><mml:mo stretchy="false">[</mml:mo><mml:mi>k</mml:mi><mml:mo stretchy="false">]</mml:mo></mml:math></inline-formula> with an outage constraint:<disp-formula id="eqn-25"><label>(25)</label><mml:math id="mml-eqn-25" display="block"><mml:msub><mml:mi>P</mml:mi><mml:mrow><mml:mrow><mml:mtext>tx</mml:mtext></mml:mrow></mml:mrow></mml:msub><mml:mo stretchy="false">[</mml:mo><mml:mi>k</mml:mi><mml:mo stretchy="false">]</mml:mo><mml:mo>=</mml:mo><mml:mi>arg</mml:mi><mml:mo>&#x2061;</mml:mo><mml:munder><mml:mo movablelimits="true" form="prefix">min</mml:mo><mml:mrow><mml:mi>P</mml:mi><mml:mo>&#x2208;</mml:mo><mml:mo stretchy="false">[</mml:mo><mml:msub><mml:mi>P</mml:mi><mml:mrow><mml:mo movablelimits="true" form="prefix">min</mml:mo></mml:mrow></mml:msub><mml:mo>,</mml:mo><mml:msub><mml:mi>P</mml:mi><mml:mrow><mml:mo movablelimits="true" form="prefix">max</mml:mo></mml:mrow></mml:msub><mml:mo stretchy="false">]</mml:mo></mml:mrow></mml:munder><mml:mtext>&#x00A0;</mml:mtext><mml:msub><mml:mi>E</mml:mi><mml:mrow><mml:mrow><mml:mtext>total</mml:mtext></mml:mrow></mml:mrow></mml:msub><mml:mo stretchy="false">[</mml:mo><mml:mi>k</mml:mi><mml:mo stretchy="false">]</mml:mo><mml:mspace width="1em" /><mml:mrow><mml:mtext>s.t.</mml:mtext></mml:mrow><mml:mspace width="1em" /><mml:mo movablelimits="true" form="prefix">Pr</mml:mo><mml:mspace width="negativethinmathspace" /><mml:mrow><mml:mo>(</mml:mo><mml:msub><mml:mi>&#x03B3;</mml:mi><mml:mi>k</mml:mi></mml:msub><mml:mo>&#x2265;</mml:mo><mml:msub><mml:mi>&#x03B3;</mml:mi><mml:mrow><mml:mrow><mml:mtext>req</mml:mtext></mml:mrow></mml:mrow></mml:msub><mml:mo>)</mml:mo></mml:mrow><mml:mo>&#x2265;</mml:mo><mml:mn>1</mml:mn><mml:mo>&#x2212;</mml:mo><mml:mo>&#x03B5;</mml:mo><mml:mo>,</mml:mo></mml:math></disp-formula>where <inline-formula id="ieqn-137"><mml:math id="mml-ieqn-137"><mml:msub><mml:mi>&#x03B3;</mml:mi><mml:mrow><mml:mtext>req</mml:mtext></mml:mrow></mml:msub></mml:math></inline-formula> is the target SINR and <inline-formula id="ieqn-138"><mml:math id="mml-ieqn-138"><mml:mo>&#x03B5;</mml:mo></mml:math></inline-formula> is the acceptable outage probability.</p>
<p>To simulate plausible IoT as well as swarm operations, packet arrivals are treated to be a stochastic process comprising three typical classes:<disp-formula id="eqn-26"><label>(26)</label><mml:math id="mml-eqn-26" display="block"><mml:msub><mml:mi>a</mml:mi><mml:mi>k</mml:mi></mml:msub><mml:mo>&#x223C;</mml:mo><mml:mrow><mml:mo>{</mml:mo><mml:mtable columnalign="left left" rowspacing=".2em" columnspacing="1em" displaystyle="false"><mml:mtr><mml:mtd><mml:msub><mml:mi>a</mml:mi><mml:mn>0</mml:mn></mml:msub><mml:mo>,</mml:mo></mml:mtd><mml:mtd><mml:mrow><mml:mtext>periodic traffic</mml:mtext></mml:mrow><mml:mo>,</mml:mo></mml:mtd></mml:mtr><mml:mtr><mml:mtd><mml:mrow><mml:mtext>Poisson</mml:mtext></mml:mrow><mml:mo stretchy="false">(</mml:mo><mml:msub><mml:mi>&#x03BB;</mml:mi><mml:mi>b</mml:mi></mml:msub><mml:mo stretchy="false">)</mml:mo><mml:mo>,</mml:mo></mml:mtd><mml:mtd><mml:mrow><mml:mtext>bursty traffic</mml:mtext></mml:mrow><mml:mo>,</mml:mo></mml:mtd></mml:mtr><mml:mtr><mml:mtd><mml:mrow><mml:mtext>Bernoulli</mml:mtext></mml:mrow><mml:mo stretchy="false">(</mml:mo><mml:msub><mml:mi>p</mml:mi><mml:mi>e</mml:mi></mml:msub><mml:mo stretchy="false">)</mml:mo><mml:mo>,</mml:mo></mml:mtd><mml:mtd><mml:mrow><mml:mtext>event-driven traffic</mml:mtext></mml:mrow><mml:mo>,</mml:mo></mml:mtd></mml:mtr></mml:mtable><mml:mo fence="true" stretchy="true" symmetric="true"></mml:mo></mml:mrow></mml:math></disp-formula>where <inline-formula id="ieqn-139"><mml:math id="mml-ieqn-139"><mml:msub><mml:mi>a</mml:mi><mml:mi>k</mml:mi></mml:msub></mml:math></inline-formula> is the packet arrival amount at interval <inline-formula id="ieqn-140"><mml:math id="mml-ieqn-140"><mml:mi>k</mml:mi></mml:math></inline-formula>. The queue evolution is given by
<disp-formula id="eqn-27"><label>(27)</label><mml:math id="mml-eqn-27" display="block"><mml:msub><mml:mi>q</mml:mi><mml:mrow><mml:mi>k</mml:mi><mml:mo>+</mml:mo><mml:mn>1</mml:mn></mml:mrow></mml:msub><mml:mo>=</mml:mo><mml:mo movablelimits="true" form="prefix">max</mml:mo><mml:mspace width="negativethinmathspace" /><mml:mrow><mml:mo>(</mml:mo><mml:mn>0</mml:mn><mml:mo>,</mml:mo><mml:msub><mml:mi>q</mml:mi><mml:mi>k</mml:mi></mml:msub><mml:mo>+</mml:mo><mml:msub><mml:mi>a</mml:mi><mml:mi>k</mml:mi></mml:msub><mml:mo>&#x2212;</mml:mo><mml:msub><mml:mi>&#x03BC;</mml:mi><mml:mi>k</mml:mi></mml:msub><mml:mo>)</mml:mo></mml:mrow><mml:mo>,</mml:mo></mml:math></disp-formula>where <inline-formula id="ieqn-141"><mml:math id="mml-ieqn-141"><mml:msub><mml:mi>&#x03BC;</mml:mi><mml:mi>k</mml:mi></mml:msub></mml:math></inline-formula> is the service rate determined by the selected communication mode and duty cycle.</p>
<p>As the route loss parameter <inline-formula id="ieqn-142"><mml:math id="mml-ieqn-142"><mml:mi>n</mml:mi></mml:math></inline-formula> or shadowing variance <inline-formula id="ieqn-143"><mml:math id="mml-ieqn-143"><mml:msup><mml:mi>&#x03C3;</mml:mi><mml:mn>2</mml:mn></mml:msup></mml:math></inline-formula> grows, the controller becomes more cautious. It increases the transmit power margin, reduces active communication windows, as well as initiates protocol transition or offloading sooner. For low <inline-formula id="ieqn-144"><mml:math id="mml-ieqn-144"><mml:mi>n</mml:mi></mml:math></inline-formula> and <inline-formula id="ieqn-145"><mml:math id="mml-ieqn-145"><mml:msup><mml:mi>&#x03C3;</mml:mi><mml:mn>2</mml:mn></mml:msup></mml:math></inline-formula>, the strategy may favor lower transmitting power as well as longer sleep intervals. The stochastic formulation therefore serves as a rational foundation for adaptive choices in indoor and outdoor contexts wherein blockage, fading, as well as multipath can drastically modify the power necessary for dependable transmission.</p>
<p>The typical bits per joule metric continues to be used as a communication quality diagnostic metric, however it is no longer considered the main metric of efficiency considering that it ignores sensing, calculation, and idle energy. To avoid biased evaluation, we report both a system level metric and a communication only metric.</p>
<p>The primary metric is defined as:<disp-formula id="eqn-28"><label>(28)</label><mml:math id="mml-eqn-28" display="block"><mml:msub><mml:mi>&#x03B7;</mml:mi><mml:mrow><mml:mrow><mml:mtext>sys</mml:mtext></mml:mrow></mml:mrow></mml:msub><mml:mo>=</mml:mo><mml:mfrac><mml:msub><mml:mi>B</mml:mi><mml:mrow><mml:mrow><mml:mtext>good</mml:mtext></mml:mrow></mml:mrow></mml:msub><mml:msub><mml:mi>E</mml:mi><mml:mrow><mml:mrow><mml:mtext>total</mml:mtext></mml:mrow></mml:mrow></mml:msub></mml:mfrac><mml:mo>,</mml:mo><mml:mspace width="2em" /><mml:msub><mml:mi>B</mml:mi><mml:mrow><mml:mrow><mml:mtext>good</mml:mtext></mml:mrow></mml:mrow></mml:msub><mml:mo>=</mml:mo><mml:msub><mml:mi>N</mml:mi><mml:mrow><mml:mrow><mml:mtext>delivered</mml:mtext></mml:mrow></mml:mrow></mml:msub><mml:mspace width="thinmathspace" /><mml:msub><mml:mi>S</mml:mi><mml:mrow><mml:mrow><mml:mtext>payload</mml:mtext></mml:mrow></mml:mrow></mml:msub><mml:mo>,</mml:mo></mml:math></disp-formula>where <inline-formula id="ieqn-146"><mml:math id="mml-ieqn-146"><mml:msub><mml:mi>B</mml:mi><mml:mrow><mml:mtext>good</mml:mtext></mml:mrow></mml:msub></mml:math></inline-formula> is the number of successfully delivered payload bits and <inline-formula id="ieqn-147"><mml:math id="mml-ieqn-147"><mml:msub><mml:mi>E</mml:mi><mml:mrow><mml:mtext>total</mml:mtext></mml:mrow></mml:msub></mml:math></inline-formula> is given in <xref ref-type="disp-formula" rid="eqn-23">Eq. (23)</xref>. This metric captures the full cost of operating the node, including CPU, sensing, radio, and standby states.</p>
<p>For protocol comparison, we also report
<disp-formula id="eqn-29"><label>(29)</label><mml:math id="mml-eqn-29" display="block"><mml:msub><mml:mi>&#x03B7;</mml:mi><mml:mrow><mml:mrow><mml:mtext>comm</mml:mtext></mml:mrow></mml:mrow></mml:msub><mml:mo>=</mml:mo><mml:mfrac><mml:msub><mml:mi>B</mml:mi><mml:mrow><mml:mrow><mml:mtext>good</mml:mtext></mml:mrow></mml:mrow></mml:msub><mml:msub><mml:mi>E</mml:mi><mml:mrow><mml:mrow><mml:mtext>comm</mml:mtext></mml:mrow></mml:mrow></mml:msub></mml:mfrac><mml:mo>,</mml:mo></mml:math></disp-formula>where <inline-formula id="ieqn-148"><mml:math id="mml-ieqn-148"><mml:msub><mml:mi>E</mml:mi><mml:mrow><mml:mtext>comm</mml:mtext></mml:mrow></mml:msub></mml:math></inline-formula> isolates radio related energy only. This secondary metric is useful for comparing BLE, LoRaWAN, MQTT, and CoAP under identical payload and workload settings, while the system level metric is used to assess end-to-end node efficiency.</p>
<p>To ensure reproducible energy accounting, the measured power trace is discretized over a fixed sampling interval <inline-formula id="ieqn-149"><mml:math id="mml-ieqn-149"><mml:mi mathvariant="normal">&#x0394;</mml:mi><mml:mi>t</mml:mi></mml:math></inline-formula>, yielding
<disp-formula id="eqn-30"><label>(30)</label><mml:math id="mml-eqn-30" display="block"><mml:msub><mml:mi>E</mml:mi><mml:mrow><mml:mrow><mml:mtext>total</mml:mtext></mml:mrow></mml:mrow></mml:msub><mml:mo>&#x2248;</mml:mo><mml:munderover><mml:mo movablelimits="false">&#x2211;</mml:mo><mml:mrow><mml:mi>k</mml:mi><mml:mo>=</mml:mo><mml:mn>1</mml:mn></mml:mrow><mml:mrow><mml:mi>K</mml:mi><mml:mo>&#x2212;</mml:mo><mml:mn>1</mml:mn></mml:mrow></mml:munderover><mml:mfrac><mml:mrow><mml:msub><mml:mi>P</mml:mi><mml:mrow><mml:mrow><mml:mtext>total</mml:mtext></mml:mrow></mml:mrow></mml:msub><mml:mo stretchy="false">[</mml:mo><mml:mi>k</mml:mi><mml:mo stretchy="false">]</mml:mo><mml:mo>+</mml:mo><mml:msub><mml:mi>P</mml:mi><mml:mrow><mml:mrow><mml:mtext>total</mml:mtext></mml:mrow></mml:mrow></mml:msub><mml:mo stretchy="false">[</mml:mo><mml:mi>k</mml:mi><mml:mo>+</mml:mo><mml:mn>1</mml:mn><mml:mo stretchy="false">]</mml:mo></mml:mrow><mml:mn>2</mml:mn></mml:mfrac><mml:mspace width="thinmathspace" /><mml:mi mathvariant="normal">&#x0394;</mml:mi><mml:mi>t</mml:mi><mml:mo>,</mml:mo><mml:mspace width="2em" /><mml:mi>K</mml:mi><mml:mo>=</mml:mo><mml:mrow><mml:mo>&#x230A;</mml:mo><mml:mfrac><mml:msub><mml:mi>T</mml:mi><mml:mrow><mml:mrow><mml:mtext>obs</mml:mtext></mml:mrow></mml:mrow></mml:msub><mml:mrow><mml:mi mathvariant="normal">&#x0394;</mml:mi><mml:mi>t</mml:mi></mml:mrow></mml:mfrac><mml:mo>&#x230B;</mml:mo></mml:mrow><mml:mo>.</mml:mo></mml:math></disp-formula></p>
<p>The total instantaneous power is decomposed as
<disp-formula id="eqn-31"><label>(31)</label><mml:math id="mml-eqn-31" display="block"><mml:msub><mml:mi>P</mml:mi><mml:mrow><mml:mrow><mml:mtext>total</mml:mtext></mml:mrow></mml:mrow></mml:msub><mml:mo stretchy="false">[</mml:mo><mml:mi>k</mml:mi><mml:mo stretchy="false">]</mml:mo><mml:mo>=</mml:mo><mml:msub><mml:mi>P</mml:mi><mml:mrow><mml:mrow><mml:mtext>comm</mml:mtext></mml:mrow></mml:mrow></mml:msub><mml:mo stretchy="false">[</mml:mo><mml:mi>k</mml:mi><mml:mo stretchy="false">]</mml:mo><mml:mo>+</mml:mo><mml:msub><mml:mi>P</mml:mi><mml:mrow><mml:mrow><mml:mtext>comp</mml:mtext></mml:mrow></mml:mrow></mml:msub><mml:mo stretchy="false">[</mml:mo><mml:mi>k</mml:mi><mml:mo stretchy="false">]</mml:mo><mml:mo>+</mml:mo><mml:msub><mml:mi>P</mml:mi><mml:mrow><mml:mrow><mml:mtext>sense</mml:mtext></mml:mrow></mml:mrow></mml:msub><mml:mo stretchy="false">[</mml:mo><mml:mi>k</mml:mi><mml:mo stretchy="false">]</mml:mo><mml:mo>+</mml:mo><mml:msub><mml:mi>P</mml:mi><mml:mrow><mml:mrow><mml:mtext>idle</mml:mtext></mml:mrow></mml:mrow></mml:msub><mml:mo stretchy="false">[</mml:mo><mml:mi>k</mml:mi><mml:mo stretchy="false">]</mml:mo><mml:mo>.</mml:mo></mml:math></disp-formula></p>
<p>Accordingly,
<disp-formula id="eqn-32"><label>(32)</label><mml:math id="mml-eqn-32" display="block"><mml:msub><mml:mi>E</mml:mi><mml:mrow><mml:mrow><mml:mtext>comm</mml:mtext></mml:mrow></mml:mrow></mml:msub><mml:mo>&#x2248;</mml:mo><mml:munderover><mml:mo movablelimits="false">&#x2211;</mml:mo><mml:mrow><mml:mi>k</mml:mi><mml:mo>=</mml:mo><mml:mn>1</mml:mn></mml:mrow><mml:mrow><mml:mi>K</mml:mi><mml:mo>&#x2212;</mml:mo><mml:mn>1</mml:mn></mml:mrow></mml:munderover><mml:mfrac><mml:mrow><mml:msub><mml:mi>P</mml:mi><mml:mrow><mml:mrow><mml:mtext>comm</mml:mtext></mml:mrow></mml:mrow></mml:msub><mml:mo stretchy="false">[</mml:mo><mml:mi>k</mml:mi><mml:mo stretchy="false">]</mml:mo><mml:mo>+</mml:mo><mml:msub><mml:mi>P</mml:mi><mml:mrow><mml:mrow><mml:mtext>comm</mml:mtext></mml:mrow></mml:mrow></mml:msub><mml:mo stretchy="false">[</mml:mo><mml:mi>k</mml:mi><mml:mo>+</mml:mo><mml:mn>1</mml:mn><mml:mo stretchy="false">]</mml:mo></mml:mrow><mml:mn>2</mml:mn></mml:mfrac><mml:mspace width="thinmathspace" /><mml:mi mathvariant="normal">&#x0394;</mml:mi><mml:mi>t</mml:mi><mml:mo>.</mml:mo></mml:math></disp-formula></p>
<p>In our experimental setup, integrated power sensors are sampled at a predefined interval <inline-formula id="ieqn-150"><mml:math id="mml-ieqn-150"><mml:mi mathvariant="normal">&#x0394;</mml:mi><mml:mi>t</mml:mi></mml:math></inline-formula> (about <inline-formula id="ieqn-151"><mml:math id="mml-ieqn-151"><mml:mn>1.6</mml:mn></mml:math></inline-formula> ms) over the system interface, and the resultant traces are incorporated using <xref ref-type="disp-formula" rid="eqn-30">Eq. (30)</xref>. To confirm the sensor calibration, onboard measurements are cross checked using a shunt resistor reading when needed. To avoid benchmarking bias, all comparable protocols employ identical observation window, payload size, duty cycle setting, as well as application workload. This ensures that the variations in <inline-formula id="ieqn-152"><mml:math id="mml-ieqn-152"><mml:msub><mml:mi>&#x03B7;</mml:mi><mml:mrow><mml:mtext>sys</mml:mtext></mml:mrow></mml:msub></mml:math></inline-formula> and <inline-formula id="ieqn-153"><mml:math id="mml-ieqn-153"><mml:msub><mml:mi>&#x03B7;</mml:mi><mml:mrow><mml:mtext>comm</mml:mtext></mml:mrow></mml:msub></mml:math></inline-formula> are caused by protocol behavior and adaptive control.</p>
<p>Overall, each node is always evaluating its energy state and connectivity requirements. We use a Deep Q-Learning (DQL) agent that monitors features (e.g., battery level, queue backlog, connection quality) and chooses actions (e.g., adjust transmit power, change channel, or switch modes) to reduce long term energy per bit while meeting reliability criteria.</p>
</sec>
<sec id="s4_3">
<label>4.3</label>
<title>Algorithmic Adaptation and Scheduling</title>
<p>The presented Algorithm 3 combines a lightweight deterministic fallback controller with a Deep Q-Learning (DQL) based adaptive policy to minimize long term communication energy while respecting basic QoS constraints (packet delivery, latency). It is designed for online operation on resource-constrained IoT nodes and contains three complementary components: (i) deterministic mode selection and duty cycle functions, (ii) a reward model that directly penalizes energy, packet loss and latency, and (iii) an optionally enabled DQL training loop using experience replay and periodic target network updates.</p>
<p>Algorithm 3 uses a hybrid control framework that combines a deterministic, rule based safety layer with a Deep Q-Learning (DQL) policy to improve long term energy use per transmitted bit while meeting standards for reliability and latency. The framework explains whatever &#x201C;feasibility&#x201D; and &#x201C;optimality&#x201D; mean. The <monospace>ModeSelect</monospace> as well as <monospace>DutyCycle</monospace> settings keep the system safe and easy to operate, regardless of whether energy or confidence is low. The learnt policy, on the other hand, takes use of environmental patterns to help the framework communicate as well as compute if everything is running smoothly.</p>
<p>The reward function
<disp-formula id="eqn-33"><label>(33)</label><mml:math id="mml-eqn-33" display="block"><mml:mi>r</mml:mi><mml:mo stretchy="false">(</mml:mo><mml:mi>s</mml:mi><mml:mo>,</mml:mo><mml:mi>a</mml:mi><mml:mo>,</mml:mo><mml:msup><mml:mi>s</mml:mi><mml:mi mathvariant="normal">&#x2032;</mml:mi></mml:msup><mml:mo stretchy="false">)</mml:mo><mml:mo>=</mml:mo><mml:mo>&#x2212;</mml:mo><mml:mstyle scriptlevel="0"><mml:mrow><mml:mo maxsize="1.2em" minsize="1.2em">(</mml:mo></mml:mrow></mml:mstyle><mml:msub><mml:mi>E</mml:mi><mml:mi>c</mml:mi></mml:msub><mml:mo stretchy="false">(</mml:mo><mml:mi>a</mml:mi><mml:mo stretchy="false">)</mml:mo><mml:mo>+</mml:mo><mml:msub><mml:mi>&#x03BB;</mml:mi><mml:mn>1</mml:mn></mml:msub><mml:mrow><mml:mtext mathvariant="bold">1</mml:mtext></mml:mrow><mml:mo fence="false" stretchy="false">{</mml:mo><mml:mrow><mml:mtext>PDR</mml:mtext></mml:mrow><mml:mo>&#x003C;</mml:mo><mml:msub><mml:mrow><mml:mtext>PDR</mml:mtext></mml:mrow><mml:mrow><mml:mrow><mml:mtext>req</mml:mtext></mml:mrow></mml:mrow></mml:msub><mml:mo fence="false" stretchy="false">}</mml:mo><mml:mo>+</mml:mo><mml:msub><mml:mi>&#x03BB;</mml:mi><mml:mn>2</mml:mn></mml:msub><mml:mrow><mml:mtext mathvariant="bold">1</mml:mtext></mml:mrow><mml:mo fence="false" stretchy="false">{</mml:mo><mml:mrow><mml:mtext>deadline missed</mml:mtext></mml:mrow><mml:mo fence="false" stretchy="false">}</mml:mo><mml:mstyle scriptlevel="0"><mml:mrow><mml:mo maxsize="1.2em" minsize="1.2em">)</mml:mo></mml:mrow></mml:mstyle></mml:math></disp-formula>penalizes devices that consume excessive energy or violate critical QoS requirements. This function steers the policy toward energy-efficient operations while maintaining consistent packet delivery ratio and delay. Effectively, it transforms multi-objective control into a single-objective optimization problem. Selecting appropriate values for <inline-formula id="ieqn-154"><mml:math id="mml-ieqn-154"><mml:msub><mml:mi>&#x03BB;</mml:mi><mml:mn>1</mml:mn></mml:msub></mml:math></inline-formula> and <inline-formula id="ieqn-155"><mml:math id="mml-ieqn-155"><mml:msub><mml:mi>&#x03BB;</mml:mi><mml:mn>2</mml:mn></mml:msub></mml:math></inline-formula> for the trade off surface. These parameters should be configured to align with application-specific service-level agreements.</p>
<fig id="fig-17">
<graphic mimetype="image" mime-subtype="tif" xlink:href="CMC_83797-fig-17.tif"/>
</fig>
<p>The deterministic fallback controller mitigates unsafe exploration inherent to <inline-formula id="ieqn-200"><mml:math id="mml-ieqn-200"><mml:mo>&#x03B5;</mml:mo></mml:math></inline-formula>-greedy policies by enforcing energy critical and link feasibility constraints. This design provides bounded risk operation during early training and in nonstationary conditions, ensuring that the node prioritizes sleep or optimization when residual energy approaches critical thresholds. Such a safety layer is particularly relevant for battery-powered or energy optimized IoT deployments where catastrophic depletion can result in prolonged network partitioning.</p>
<p>While DQL provides adaptive, context-aware judgments, its inference and replay buffer management have significant computational and memory cost. On restricted microcontrollers, this cost may cancel out energy savings unless compact network topologies (e.g., shallow MLPs, quantized weights) or off device training with lightweight on-device inference are used. A realistic deployment strategy is to pretrain rules in a simulation environment or at the edge before refreshing node level models with a periodic schedule with compressed updates.</p>
<p>Wireless environments include considerable temporal variability caused by fading, competing communications, as well as propagation bursts, which defies the stationarity condition of traditional DQL. In the absence of mitigation, this issue might result in oscillatory behavior and sluggish convergence. Target network based update scheduling, selective experience evaluation, dual DQN, as well as sequential returns all have the potential to increase stability. Short term state recordings and repeated representations significantly reduce partial observability.</p>
<p>Despite QoS requirements are punished throughout the incentive process, this softly limited approach does not ensure strict compliance. For applications with severe deadlines or controlled duty cycle restrictions, limited reinforcement learning as well as reaction shielding procedures should be used on learnt rules to reject actions that are likely to break system constraints and return to the dependable regulator.</p>
<p>Peer to peer independent learning can result in less effective solutions and increased channel congestion in dense installations. Federated or cluster based training approaches have the ability to increase global efficiency while reducing communication costs since nodes regularly broadcast lowered gradient estimates as well as policy settings. It is important to carefully weigh the trade-off between airplane energy management and model monetary units.</p>
<p>Performance evaluation must also include duty cycle conformance, packet delivery ratio, channel specific stress circumstances, delay (e.g., P95/P99), and fallback activation frequency in addition to the average energy per bit. Ablation studies comparing deterministic only, learnt only, and hybrid versions are necessary to determine the extent to which reinforcement learning outperforms baseline heuristics.</p>
<p>Combining reinforcement learning with deterministic protections allows for the development of energy-efficient communication protocols that remain robust in the face of ambiguity. The methodology&#x2019;s decentralized training techniques, constrained learning extensions, and efficient model compression make it suitable for real world, large-scale IoT and swarm applications.</p>
<p>The technique offers a practical and extendable solution to adaptive, energy-aware communication control on IoT nodes. Its hybrid architecture assures safe baseline behavior while also enabling DQL to increase long-term energy efficiency in deployment-specific scenarios. Pretraining, strong feature normalization, restricted RL safety mechanisms, and lightweight model architectures should be prioritized for commercial usage to satisfy the restrictive compute/energy constraints of embedded systems.</p>
<p>Our adaptive communication Algorithm 3, works as follows. Each node has a power budget and an energy queue. When <inline-formula id="ieqn-201"><mml:math id="mml-ieqn-201"><mml:msub><mml:mi>E</mml:mi><mml:mrow><mml:mtext>res</mml:mtext></mml:mrow></mml:msub></mml:math></inline-formula> is high (surplus energy), the node may either boost transmission power or decrease data rates (to preserve airtime). When <inline-formula id="ieqn-202"><mml:math id="mml-ieqn-202"><mml:msub><mml:mi>E</mml:mi><mml:mrow><mml:mtext>res</mml:mtext></mml:mrow></mml:msub></mml:math></inline-formula> is low, it increases sleep intervals but decreases power. Similarly, the schedule has been altered. For instance, when energy is scarce, we may provide energy aware channel access, which would make devices retreat more forcefully.</p>
<p>We contrast distributed and centralized methods for real world application. The network may allocate transmission slots and power in a centralized configuration (like one with a coordinating gateway) according to traffic and global energy conditions. Each node individually chooses the best course of action using DQL in a fully distributed environment, like swarms. The program can handle complicated, dynamic situations without describing every detail because to DQL&#x2019;s flexibility.</p>
<p>Devices that communicate excessively are penalized by the reward function, which also imposes severe penalties for exceeding latency or reliability thresholds. This makes sure that the method taught doesn&#x2019;t hurt the quality of service in order to save energy.</p>
<p>When the learned model is new or the node&#x2019;s energy is very low, a deterministic fallback (ModeSelection &#x002B; DutyCycleAdjust) makes sure that the system runs safely.</p>
<p>We can train DQL on a device or in a central place that isn&#x2019;t connected to the internet. We can send policy changes to nodes from time to time.</p>
<p>To validate the stability and effectiveness of the proposed Deep Q-Learning (DQL) framework, we analyze its training dynamics using reward evolution, loss convergence, and policy stability metrics.</p>
<sec id="s4_3_1">
<label>4.3.1</label>
<title>Learning Curves</title>
<p><xref ref-type="fig" rid="fig-4">Fig. 4</xref> illustrates the evolution of (i) temporal difference (TD) loss, and (ii) policy stability over training episodes.</p>
<fig id="fig-4">
<label>Figure 4</label>
<caption>
<title>Training dynamics of deep Q-learning agent.</title>
</caption>
<graphic mimetype="image" mime-subtype="tif" xlink:href="CMC_83797-fig-4.tif"/>
</fig>
<p><list list-type="bullet">
<list-item>
<p>Episode Reward: The cumulative reward per episode is computed as
<disp-formula id="eqn-34"><label>(34)</label><mml:math id="mml-eqn-34" display="block"><mml:msup><mml:mi>R</mml:mi><mml:mrow><mml:mo stretchy="false">(</mml:mo><mml:mi>e</mml:mi><mml:mo stretchy="false">)</mml:mo></mml:mrow></mml:msup><mml:mo>=</mml:mo><mml:munderover><mml:mo movablelimits="false">&#x2211;</mml:mo><mml:mrow><mml:mi>t</mml:mi><mml:mo>=</mml:mo><mml:mn>1</mml:mn></mml:mrow><mml:mrow><mml:mi>T</mml:mi></mml:mrow></mml:munderover><mml:msub><mml:mi>r</mml:mi><mml:mi>t</mml:mi></mml:msub><mml:mo>,</mml:mo></mml:math></disp-formula>where <inline-formula id="ieqn-203"><mml:math id="mml-ieqn-203"><mml:msub><mml:mi>r</mml:mi><mml:mi>t</mml:mi></mml:msub></mml:math></inline-formula> is the instantaneous reward and <inline-formula id="ieqn-204"><mml:math id="mml-ieqn-204"><mml:mi>T</mml:mi></mml:math></inline-formula> is the episode length. An increasing and saturating trend indicates policy improvement.</p></list-item>
<list-item>
<p>Loss Function: The DQL training minimizes the TD error given by
<disp-formula id="eqn-35"><label>(35)</label><mml:math id="mml-eqn-35" display="block"><mml:mrow><mml:mi>&#x02112;</mml:mi></mml:mrow><mml:mo stretchy="false">(</mml:mo><mml:mi>&#x03B8;</mml:mi><mml:mo stretchy="false">)</mml:mo><mml:mo>=</mml:mo><mml:mrow><mml:mi mathvariant="double-struck">E</mml:mi></mml:mrow><mml:mrow><mml:mo>[</mml:mo><mml:msup><mml:mrow><mml:mo>(</mml:mo><mml:msub><mml:mi>r</mml:mi><mml:mi>t</mml:mi></mml:msub><mml:mo>+</mml:mo><mml:mi>&#x03B3;</mml:mi><mml:munder><mml:mo movablelimits="true" form="prefix">max</mml:mo><mml:mrow><mml:msup><mml:mi>a</mml:mi><mml:mi mathvariant="normal">&#x2032;</mml:mi></mml:msup></mml:mrow></mml:munder><mml:msub><mml:mi>Q</mml:mi><mml:mrow><mml:msup><mml:mi>&#x03B8;</mml:mi><mml:mo>&#x2212;</mml:mo></mml:msup></mml:mrow></mml:msub><mml:mo stretchy="false">(</mml:mo><mml:msub><mml:mi>s</mml:mi><mml:mrow><mml:mi>t</mml:mi><mml:mo>+</mml:mo><mml:mn>1</mml:mn></mml:mrow></mml:msub><mml:mo>,</mml:mo><mml:msup><mml:mi>a</mml:mi><mml:mi mathvariant="normal">&#x2032;</mml:mi></mml:msup><mml:mo stretchy="false">)</mml:mo><mml:mo>&#x2212;</mml:mo><mml:msub><mml:mi>Q</mml:mi><mml:mrow><mml:mi>&#x03B8;</mml:mi></mml:mrow></mml:msub><mml:mo stretchy="false">(</mml:mo><mml:msub><mml:mi>s</mml:mi><mml:mi>t</mml:mi></mml:msub><mml:mo>,</mml:mo><mml:msub><mml:mi>a</mml:mi><mml:mi>t</mml:mi></mml:msub><mml:mo stretchy="false">)</mml:mo><mml:mo>)</mml:mo></mml:mrow><mml:mn>2</mml:mn></mml:msup><mml:mo>]</mml:mo></mml:mrow><mml:mo>,</mml:mo></mml:math></disp-formula>where <inline-formula id="ieqn-205"><mml:math id="mml-ieqn-205"><mml:mi>&#x03B8;</mml:mi></mml:math></inline-formula> and <inline-formula id="ieqn-206"><mml:math id="mml-ieqn-206"><mml:msup><mml:mi>&#x03B8;</mml:mi><mml:mo>&#x2212;</mml:mo></mml:msup></mml:math></inline-formula> denote the online and target network parameters, respectively.</p></list-item>
<list-item>
<p>Policy Stability: Policy stability is measured as the variation in action selection probabilities:<disp-formula id="eqn-36"><label>(36)</label><mml:math id="mml-eqn-36" display="block"><mml:mi mathvariant="normal">&#x0394;</mml:mi><mml:msup><mml:mi>&#x03C0;</mml:mi><mml:mrow><mml:mo stretchy="false">(</mml:mo><mml:mi>e</mml:mi><mml:mo stretchy="false">)</mml:mo></mml:mrow></mml:msup><mml:mo>=</mml:mo><mml:mfrac><mml:mn>1</mml:mn><mml:mrow><mml:mrow><mml:mo stretchy="false">|</mml:mo></mml:mrow><mml:mi>S</mml:mi><mml:mrow><mml:mo stretchy="false">|</mml:mo></mml:mrow></mml:mrow></mml:mfrac><mml:munder><mml:mo movablelimits="false">&#x2211;</mml:mo><mml:mrow><mml:mi>s</mml:mi><mml:mo>&#x2208;</mml:mo><mml:mi>S</mml:mi></mml:mrow></mml:munder><mml:mrow><mml:mo symmetric="true">&#x2016;</mml:mo><mml:msup><mml:mi>&#x03C0;</mml:mi><mml:mrow><mml:mo stretchy="false">(</mml:mo><mml:mi>e</mml:mi><mml:mo stretchy="false">)</mml:mo></mml:mrow></mml:msup><mml:mo stretchy="false">(</mml:mo><mml:mi>s</mml:mi><mml:mo stretchy="false">)</mml:mo><mml:mo>&#x2212;</mml:mo><mml:msup><mml:mi>&#x03C0;</mml:mi><mml:mrow><mml:mo stretchy="false">(</mml:mo><mml:mi>e</mml:mi><mml:mo>&#x2212;</mml:mo><mml:mn>1</mml:mn><mml:mo stretchy="false">)</mml:mo></mml:mrow></mml:msup><mml:mo stretchy="false">(</mml:mo><mml:mi>s</mml:mi><mml:mo stretchy="false">)</mml:mo><mml:mo symmetric="true">&#x2016;</mml:mo></mml:mrow><mml:mo>,</mml:mo></mml:math></disp-formula>where <inline-formula id="ieqn-207"><mml:math id="mml-ieqn-207"><mml:msup><mml:mi>&#x03C0;</mml:mi><mml:mrow><mml:mo stretchy="false">(</mml:mo><mml:mi>e</mml:mi><mml:mo stretchy="false">)</mml:mo></mml:mrow></mml:msup></mml:math></inline-formula> is the policy at episode <inline-formula id="ieqn-208"><mml:math id="mml-ieqn-208"><mml:mi>e</mml:mi></mml:math></inline-formula>. Convergence is indicated by <inline-formula id="ieqn-209"><mml:math id="mml-ieqn-209"><mml:mi mathvariant="normal">&#x0394;</mml:mi><mml:msup><mml:mi>&#x03C0;</mml:mi><mml:mrow><mml:mo stretchy="false">(</mml:mo><mml:mi>e</mml:mi><mml:mo stretchy="false">)</mml:mo></mml:mrow></mml:msup><mml:mo stretchy="false">&#x2192;</mml:mo><mml:mn>0</mml:mn></mml:math></inline-formula>.</p></list-item>
</list></p>
</sec>
<sec id="s4_3_2">
<label>4.3.2</label>
<title>Convergence Criterion</title>
<p>We define convergence when all of the following conditions are satisfied:<disp-formula id="eqn-37"><label>(37)</label><mml:math id="mml-eqn-37" display="block"><mml:mtable columnalign="right left right left right left right left right left right left" rowspacing="3pt" columnspacing="0em 2em 0em 2em 0em 2em 0em 2em 0em 2em 0em" displaystyle="true"><mml:mtr><mml:mtd><mml:mrow><mml:mo>|</mml:mo><mml:msup><mml:mrow><mml:mover><mml:mi>R</mml:mi><mml:mo stretchy="false">&#x00AF;</mml:mo></mml:mover></mml:mrow><mml:mrow><mml:mo stretchy="false">(</mml:mo><mml:mi>e</mml:mi><mml:mo stretchy="false">)</mml:mo></mml:mrow></mml:msup><mml:mo>&#x2212;</mml:mo><mml:msup><mml:mrow><mml:mover><mml:mi>R</mml:mi><mml:mo stretchy="false">&#x00AF;</mml:mo></mml:mover></mml:mrow><mml:mrow><mml:mo stretchy="false">(</mml:mo><mml:mi>e</mml:mi><mml:mo>&#x2212;</mml:mo><mml:mi>k</mml:mi><mml:mo stretchy="false">)</mml:mo></mml:mrow></mml:msup><mml:mo>|</mml:mo></mml:mrow></mml:mtd><mml:mtd><mml:mi></mml:mi><mml:mo>&#x003C;</mml:mo><mml:mspace width="thinmathspace" /><mml:msub><mml:mo>&#x03B5;</mml:mo><mml:mi>R</mml:mi></mml:msub><mml:mo>,</mml:mo></mml:mtd></mml:mtr><mml:mtr><mml:mtd><mml:msup><mml:mrow><mml:mi>&#x02112;</mml:mi></mml:mrow><mml:mrow><mml:mo stretchy="false">(</mml:mo><mml:mi>e</mml:mi><mml:mo stretchy="false">)</mml:mo></mml:mrow></mml:msup></mml:mtd><mml:mtd><mml:mi></mml:mi><mml:mo>&#x003C;</mml:mo><mml:mspace width="thinmathspace" /><mml:msub><mml:mo>&#x03B5;</mml:mo><mml:mi>L</mml:mi></mml:msub><mml:mo>,</mml:mo></mml:mtd></mml:mtr><mml:mtr><mml:mtd><mml:mi mathvariant="normal">&#x0394;</mml:mi><mml:msup><mml:mi>&#x03C0;</mml:mi><mml:mrow><mml:mo stretchy="false">(</mml:mo><mml:mi>e</mml:mi><mml:mo stretchy="false">)</mml:mo></mml:mrow></mml:msup></mml:mtd><mml:mtd><mml:mi></mml:mi><mml:mo>&#x003C;</mml:mo><mml:mspace width="thinmathspace" /><mml:msub><mml:mo>&#x03B5;</mml:mo><mml:mi>&#x03C0;</mml:mi></mml:msub><mml:mo>,</mml:mo></mml:mtd></mml:mtr></mml:mtable></mml:math></disp-formula>where <inline-formula id="ieqn-210"><mml:math id="mml-ieqn-210"><mml:msup><mml:mrow><mml:mover><mml:mi>R</mml:mi><mml:mo stretchy="false">&#x00AF;</mml:mo></mml:mover></mml:mrow><mml:mrow><mml:mo stretchy="false">(</mml:mo><mml:mi>e</mml:mi><mml:mo stretchy="false">)</mml:mo></mml:mrow></mml:msup></mml:math></inline-formula> is the moving average reward over a window of <inline-formula id="ieqn-211"><mml:math id="mml-ieqn-211"><mml:mi>k</mml:mi></mml:math></inline-formula> episodes, and <inline-formula id="ieqn-212"><mml:math id="mml-ieqn-212"><mml:msub><mml:mo>&#x03B5;</mml:mo><mml:mi>R</mml:mi></mml:msub></mml:math></inline-formula>, <inline-formula id="ieqn-213"><mml:math id="mml-ieqn-213"><mml:msub><mml:mo>&#x03B5;</mml:mo><mml:mi>L</mml:mi></mml:msub></mml:math></inline-formula>, and <inline-formula id="ieqn-214"><mml:math id="mml-ieqn-214"><mml:msub><mml:mo>&#x03B5;</mml:mo><mml:mi>&#x03C0;</mml:mi></mml:msub></mml:math></inline-formula> are small thresholds. In our experiments, convergence is typically observed within <inline-formula id="ieqn-215"><mml:math id="mml-ieqn-215"><mml:mn>300</mml:mn></mml:math></inline-formula>&#x2013;<inline-formula id="ieqn-216"><mml:math id="mml-ieqn-216"><mml:mn>500</mml:mn></mml:math></inline-formula> episodes.</p>
</sec>
<sec id="s4_3_3">
<label>4.3.3</label>
<title>Baseline Comparisons</title>
<p>To quantify the benefit of reinforcement learning, we compare the proposed DQL based controller against the following baselines:<list list-type="bullet">
<list-item>
<p>Deterministic Policy: Fixed threshold based protocol selection and static duty cycling.</p></list-item>
<list-item>
<p>Rule Based Heuristic: Predefined rules based on distance and residual energy.</p></list-item>
<list-item>
<p>Hybrid (Proposed): Deterministic fallback combined with DQL adaptation.</p></list-item>
</list></p>
<p><xref ref-type="table" rid="table-1">Table 1</xref> summarizes the comparative performance:</p>
<table-wrap id="table-1">
<label>Table 1</label>
<caption>
<title>Performance comparison of control strategies.</title>
</caption>
<table>
<colgroup>
<col align="center"/>
<col align="center"/>
<col align="center"/>
<col align="center"/> </colgroup>
<thead>
<tr>
<th>Method</th>
<th>Energy/bit (J)</th>
<th>Latency (ms)</th>
<th>PDR (%)</th>
</tr>
</thead>
<tbody>
<tr>
<td>Deterministic</td>
<td>0.085</td>
<td>120</td>
<td>91</td>
</tr>
<tr>
<td>Rule Based</td>
<td>0.072</td>
<td>110</td>
<td>93</td>
</tr>
<tr>
<td>DQL</td>
<td>0.058</td>
<td>95</td>
<td>96</td>
</tr>
<tr>
<td>Hybrid (Proposed)</td>
<td>0.052</td>
<td>90</td>
<td>97</td>
</tr>
</tbody>
</table>
</table-wrap>
<p>The hybrid method regularly exceeds both deterministic and rule based baselines, yielding around <inline-formula id="ieqn-217"><mml:math id="mml-ieqn-217"><mml:mn>25</mml:mn></mml:math></inline-formula>%&#x2013;<inline-formula id="ieqn-218"><mml:math id="mml-ieqn-218"><mml:mn>35</mml:mn><mml:mi mathvariant="normal">&#x0025;</mml:mi></mml:math></inline-formula> gain in energy efficiency and decreased latency.</p>
</sec>
<sec id="s4_3_4">
<label>4.3.4</label>
<title>Reward Stabilization across Runs</title>
<p>We trained a DQL agent on many independent runs with different random seeds in order to confirm dependability. The information shows that:<list list-type="bullet">
<list-item>
<p>Reward trajectories converge to similar steady state values across runs.</p></list-item>
<list-item>
<p>Variance in final episode reward is below <inline-formula id="ieqn-219"><mml:math id="mml-ieqn-219"><mml:mn>5</mml:mn><mml:mi mathvariant="normal">&#x0025;</mml:mi></mml:math></inline-formula>.</p></list-item>
<list-item>
<p>No divergence or oscillatory instability is observed after convergence.</p></list-item>
</list></p>
<p>These observations confirm that the learning process is stable and reproducible, and that the policy generalizes across different initializations.</p>
<p>The convergence pattern indicates that the DQL agent may be able to develop an energy aware communication strategy that takes QoS limitations and energy consumption into account. By offering secure backup choices during early training stages or in unanticipated situations, the hybrid control strategy increases robustness. In general, learning based adaptation works better than static heuristics, particularly under unforeseen or dynamic network situations.</p>
<p>We undertake a sensitivity analysis using the weighting factors <inline-formula id="ieqn-220"><mml:math id="mml-ieqn-220"><mml:msub><mml:mi>&#x03BB;</mml:mi><mml:mn>1</mml:mn></mml:msub></mml:math></inline-formula> and <inline-formula id="ieqn-221"><mml:math id="mml-ieqn-221"><mml:msub><mml:mi>&#x03BB;</mml:mi><mml:mn>2</mml:mn></mml:msub></mml:math></inline-formula>, which establish the trade off between energy conservation as well as QoS constraints, in order to evaluate the impact of reward function parameters on the system&#x2019;s operation.</p>
<p>The reward function is defined as:<disp-formula id="eqn-38"><label>(38)</label><mml:math id="mml-eqn-38" display="block"><mml:mi>R</mml:mi><mml:mo>=</mml:mo><mml:mo>&#x2212;</mml:mo><mml:msub><mml:mi>E</mml:mi><mml:mrow><mml:mrow><mml:mtext>comm</mml:mtext></mml:mrow></mml:mrow></mml:msub><mml:mo>&#x2212;</mml:mo><mml:msub><mml:mi>&#x03BB;</mml:mi><mml:mn>1</mml:mn></mml:msub><mml:mo>&#x22C5;</mml:mo><mml:msub><mml:mrow><mml:mi mathvariant="double-struck">I</mml:mi></mml:mrow><mml:mrow><mml:mrow><mml:mtext>PDR</mml:mtext></mml:mrow></mml:mrow></mml:msub><mml:mo>&#x2212;</mml:mo><mml:msub><mml:mi>&#x03BB;</mml:mi><mml:mn>2</mml:mn></mml:msub><mml:mo>&#x22C5;</mml:mo><mml:msub><mml:mrow><mml:mi mathvariant="double-struck">I</mml:mi></mml:mrow><mml:mrow><mml:mrow><mml:mtext>latency</mml:mtext></mml:mrow></mml:mrow></mml:msub><mml:mo>,</mml:mo></mml:math></disp-formula>where <inline-formula id="ieqn-222"><mml:math id="mml-ieqn-222"><mml:msub><mml:mrow><mml:mi mathvariant="double-struck">I</mml:mi></mml:mrow><mml:mrow><mml:mtext>PDR</mml:mtext></mml:mrow></mml:msub></mml:math></inline-formula> is the penalty for packet delivery ratio (PDR) breaches, <inline-formula id="ieqn-223"><mml:math id="mml-ieqn-223"><mml:msub><mml:mrow><mml:mi mathvariant="double-struck">I</mml:mi></mml:mrow><mml:mrow><mml:mtext>latency</mml:mtext></mml:mrow></mml:msub></mml:math></inline-formula> is the penalty for deadline violations, and <inline-formula id="ieqn-224"><mml:math id="mml-ieqn-224"><mml:msub><mml:mi>E</mml:mi><mml:mrow><mml:mtext>comm</mml:mtext></mml:mrow></mml:msub></mml:math></inline-formula> is the communication energy cost.</p>
<p>The performance measures listed below are employed:<list list-type="bullet">
<list-item>
<p>Energy per Bit:<disp-formula id="eqn-39"><label>(39)</label><mml:math id="mml-eqn-39" display="block"><mml:msub><mml:mi>E</mml:mi><mml:mi>b</mml:mi></mml:msub><mml:mo>=</mml:mo><mml:mfrac><mml:msub><mml:mi>E</mml:mi><mml:mrow><mml:mrow><mml:mtext>total</mml:mtext></mml:mrow></mml:mrow></mml:msub><mml:msub><mml:mi>N</mml:mi><mml:mrow><mml:mrow><mml:mtext>bits</mml:mtext></mml:mrow></mml:mrow></mml:msub></mml:mfrac><mml:mo>,</mml:mo></mml:math></disp-formula>where <inline-formula id="ieqn-225"><mml:math id="mml-ieqn-225"><mml:msub><mml:mi>E</mml:mi><mml:mrow><mml:mtext>total</mml:mtext></mml:mrow></mml:msub></mml:math></inline-formula> is total energy consumed and <inline-formula id="ieqn-226"><mml:math id="mml-ieqn-226"><mml:msub><mml:mi>N</mml:mi><mml:mrow><mml:mtext>bits</mml:mtext></mml:mrow></mml:msub></mml:math></inline-formula> is the number of successfully delivered bits.</p></list-item>
<list-item>
<p>Latency:<disp-formula id="eqn-40"><label>(40)</label><mml:math id="mml-eqn-40" display="block"><mml:mi>L</mml:mi><mml:mo>=</mml:mo><mml:mfrac><mml:mn>1</mml:mn><mml:mi>N</mml:mi></mml:mfrac><mml:munderover><mml:mo movablelimits="false">&#x2211;</mml:mo><mml:mrow><mml:mi>i</mml:mi><mml:mo>=</mml:mo><mml:mn>1</mml:mn></mml:mrow><mml:mrow><mml:mi>N</mml:mi></mml:mrow></mml:munderover><mml:mo stretchy="false">(</mml:mo><mml:msubsup><mml:mi>t</mml:mi><mml:mi>i</mml:mi><mml:mrow><mml:mrow><mml:mtext>recv</mml:mtext></mml:mrow></mml:mrow></mml:msubsup><mml:mo>&#x2212;</mml:mo><mml:msubsup><mml:mi>t</mml:mi><mml:mi>i</mml:mi><mml:mrow><mml:mrow><mml:mtext>send</mml:mtext></mml:mrow></mml:mrow></mml:msubsup><mml:mo stretchy="false">)</mml:mo><mml:mo>,</mml:mo></mml:math></disp-formula></p>
</list-item>
<list-item>
<p>Packet Delivery Ratio (PDR):<disp-formula id="eqn-41"><label>(41)</label><mml:math id="mml-eqn-41" display="block"><mml:mrow><mml:mtext>PDR</mml:mtext></mml:mrow><mml:mo>=</mml:mo><mml:mfrac><mml:msub><mml:mi>N</mml:mi><mml:mrow><mml:mrow><mml:mtext>received</mml:mtext></mml:mrow></mml:mrow></mml:msub><mml:msub><mml:mi>N</mml:mi><mml:mrow><mml:mrow><mml:mtext>sent</mml:mtext></mml:mrow></mml:mrow></mml:msub></mml:mfrac><mml:mo>.</mml:mo></mml:math></disp-formula></p></list-item>
</list></p>
<p>With a step size of <inline-formula id="ieqn-227"><mml:math id="mml-ieqn-227"><mml:mn>0.25</mml:mn></mml:math></inline-formula>, we alter <inline-formula id="ieqn-228"><mml:math id="mml-ieqn-228"><mml:msub><mml:mi>&#x03BB;</mml:mi><mml:mn>1</mml:mn></mml:msub></mml:math></inline-formula> and <inline-formula id="ieqn-229"><mml:math id="mml-ieqn-229"><mml:msub><mml:mi>&#x03BB;</mml:mi><mml:mn>2</mml:mn></mml:msub></mml:math></inline-formula> throughout the interval <inline-formula id="ieqn-230"><mml:math id="mml-ieqn-230"><mml:mo stretchy="false">[</mml:mo><mml:mn>0</mml:mn><mml:mo>,</mml:mo><mml:mn>1</mml:mn><mml:mo stretchy="false">]</mml:mo></mml:math></inline-formula>. The DQL agent is trained till convergence as well as assessed under the same workload and channel circumstances for every configuration.</p>
<p>The observed trade offs are summarized in <xref ref-type="table" rid="table-2">Table 2</xref>.</p>
<table-wrap id="table-2">
<label>Table 2</label>
<caption>
<title>Sensitivity analysis of reward weights.</title>
</caption>
<table>
<colgroup>
<col align="center"/>
<col align="center"/>
<col align="center"/>
<col align="center"/>
<col align="center"/> </colgroup>
<thead>
<tr>
<th><inline-formula id="ieqn-231"><mml:math id="mml-ieqn-231"><mml:msub><mml:mi>&#x03BB;</mml:mi><mml:mn>1</mml:mn></mml:msub></mml:math></inline-formula></th>
<th><inline-formula id="ieqn-232"><mml:math id="mml-ieqn-232"><mml:msub><mml:mi>&#x03BB;</mml:mi><mml:mn>2</mml:mn></mml:msub></mml:math></inline-formula></th>
<th><inline-formula id="ieqn-233"><mml:math id="mml-ieqn-233"><mml:msub><mml:mi>E</mml:mi><mml:mi>b</mml:mi></mml:msub></mml:math></inline-formula> (J/bit)</th>
<th>Latency (ms)</th>
<th>PDR (%)</th>
</tr>
</thead>
<tbody>
<tr>
<td>0.00</td>
<td>0.00</td>
<td>0.045</td>
<td>140</td>
<td>89</td>
</tr>
<tr>
<td>0.25</td>
<td>0.25</td>
<td>0.050</td>
<td>120</td>
<td>92</td>
</tr>
<tr>
<td>0.50</td>
<td>0.50</td>
<td>0.058</td>
<td>100</td>
<td>95</td>
</tr>
<tr>
<td>0.75</td>
<td>0.75</td>
<td>0.067</td>
<td>90</td>
<td>96</td>
</tr>
<tr>
<td>1.00</td>
<td>1.00</td>
<td>0.075</td>
<td>85</td>
<td>97</td>
</tr>
<tr>
<td>0.75</td>
<td>0.25</td>
<td>0.060</td>
<td>110</td>
<td>96</td>
</tr>
<tr>
<td>0.25</td>
<td>0.75</td>
<td>0.065</td>
<td>95</td>
<td>93</td>
</tr>
</tbody>
</table>
</table-wrap>
<p>The results demonstrate a clear trade-off governed by <inline-formula id="ieqn-234"><mml:math id="mml-ieqn-234"><mml:msub><mml:mi>&#x03BB;</mml:mi><mml:mn>1</mml:mn></mml:msub></mml:math></inline-formula> and <inline-formula id="ieqn-235"><mml:math id="mml-ieqn-235"><mml:msub><mml:mi>&#x03BB;</mml:mi><mml:mn>2</mml:mn></mml:msub></mml:math></inline-formula>:<list list-type="bullet">
<list-item>
<p>Increasing <inline-formula id="ieqn-236"><mml:math id="mml-ieqn-236"><mml:msub><mml:mi>&#x03BB;</mml:mi><mml:mn>1</mml:mn></mml:msub></mml:math></inline-formula> (PDR penalty) improves reliability at the cost of higher energy consumption.</p></list-item>
<list-item>
<p>Increasing <inline-formula id="ieqn-237"><mml:math id="mml-ieqn-237"><mml:msub><mml:mi>&#x03BB;</mml:mi><mml:mn>2</mml:mn></mml:msub></mml:math></inline-formula> (latency penalty) reduces delay but may increase energy usage due to more aggressive transmissions.</p></list-item>
<list-item>
<p>Balanced weighting (<inline-formula id="ieqn-238"><mml:math id="mml-ieqn-238"><mml:msub><mml:mi>&#x03BB;</mml:mi><mml:mn>1</mml:mn></mml:msub><mml:mo>=</mml:mo><mml:msub><mml:mi>&#x03BB;</mml:mi><mml:mn>2</mml:mn></mml:msub><mml:mo>=</mml:mo><mml:mn>0.5</mml:mn></mml:math></inline-formula>) provides a good compromise between energy efficiency and QoS.</p></list-item>
</list></p>
<p>Lower values prioritize energy efficiency over latency and reliability; the extreme circumstances (<inline-formula id="ieqn-239"><mml:math id="mml-ieqn-239"><mml:msub><mml:mi>&#x03BB;</mml:mi><mml:mn>1</mml:mn></mml:msub><mml:mo>,</mml:mo><mml:msub><mml:mi>&#x03BB;</mml:mi><mml:mn>2</mml:mn></mml:msub><mml:mo stretchy="false">&#x2192;</mml:mo><mml:mn>1</mml:mn></mml:math></inline-formula>) improve QoS and lead to more energy per bit.</p>
<p>These results emphasize the necessity of tailoring incentive parameters to the particular needs of each application. Applications that are worried about latency benefit from higher <inline-formula id="ieqn-240"><mml:math id="mml-ieqn-240"><mml:msub><mml:mi>&#x03BB;</mml:mi><mml:mn>2</mml:mn></mml:msub></mml:math></inline-formula>, whereas installations with limited energy resources benefit from smaller <inline-formula id="ieqn-241"><mml:math id="mml-ieqn-241"><mml:mi>&#x03BB;</mml:mi></mml:math></inline-formula> values. To enable context-aware optimization, the proposed method dynamically modifies these weights.</p>
<p>We conduct an ablation research comparing three control strategies in order to evaluate the effects of this special reinforcement learning component:<list list-type="bullet">
<list-item>
<p>Deterministic Only: Fixed threshold based policy for protocol selection, transmission power, and duty cycling.</p></list-item>
<list-item>
<p>DQL Only: Fully learned policy without deterministic fallback or safety constraints.</p></list-item>
<list-item>
<p>Hybrid (Proposed): Combination of deterministic safeguards and DQL based adaptive decision making.</p></list-item>
</list></p>
<p>The following metrics are used for comparison:<list list-type="bullet">
<list-item>
<p>Energy per bit (<inline-formula id="ieqn-242"><mml:math id="mml-ieqn-242"><mml:msub><mml:mi>E</mml:mi><mml:mi>b</mml:mi></mml:msub></mml:math></inline-formula>),</p></list-item>
<list-item>
<p>Average latency (<inline-formula id="ieqn-243"><mml:math id="mml-ieqn-243"><mml:mi>L</mml:mi></mml:math></inline-formula>),</p></list-item>
<list-item>
<p>Packet Delivery Ratio (PDR),</p></list-item>
<list-item>
<p>Convergence stability (variance of final reward).</p></list-item>
</list></p>
<p><xref ref-type="table" rid="table-3">Table 3</xref> summarizes the performance across the three approaches.</p>
<table-wrap id="table-3">
<label>Table 3</label>
<caption>
<title>Ablation study of control strategies.</title>
</caption>
<table>
<colgroup>
<col align="center"/>
<col align="center"/>
<col align="center"/>
<col align="center"/>
<col align="center"/> </colgroup>
<thead>
<tr>
<th>Method</th>
<th><inline-formula id="ieqn-244"><mml:math id="mml-ieqn-244"><mml:msub><mml:mi>E</mml:mi><mml:mi>b</mml:mi></mml:msub></mml:math></inline-formula> (J/bit)</th>
<th>Latency (ms)</th>
<th>PDR (%)</th>
<th>Reward Var.</th>
</tr>
</thead>
<tbody>
<tr>
<td>Deterministic-Only</td>
<td>0.085</td>
<td>120</td>
<td>91</td>
<td>&#x2013;</td>
</tr>
<tr>
<td>DQL Only</td>
<td>0.060</td>
<td>95</td>
<td>95</td>
<td>0.012</td>
</tr>
<tr>
<td>Hybrid (Proposed)</td>
<td>0.052</td>
<td>90</td>
<td>97</td>
<td>0.006</td>
</tr>
</tbody>
</table>
</table-wrap>
<p>The results demonstrate that:<list list-type="bullet">
<list-item>
<p>The DQL only approach improves energy efficiency and latency compared to deterministic control, confirming that learning based adaptation captures system dynamics more effectively.</p></list-item>
<list-item>
<p>However, DQL only exhibits higher variability during training and occasional suboptimal actions in early stages due to exploration.</p></list-item>
<list-item>
<p>The hybrid approach consistently outperforms both alternatives, achieving the lowest energy per bit, lowest latency, and highest PDR.</p></list-item>
</list></p>
<p>While the DQL component allows for fine grained optimization based on learned experience, the deterministic component ensures predictable and consistent execution in unexpected or unknown situations. This combination maintains performance throughout exploration while reducing convergence variance.</p>
<p>We perform a methodical ablation study that progressively activates critical systems including duty cycling (DC), adjustable power control (PC), and protocol switching (PS) in order to ascertain the effects of each component.</p>
<p>Configurations:<list list-type="bullet">
<list-item>
<p><bold>Baseline (B0):</bold> Fixed power, no duty cycling, single protocol</p></list-item>
<list-item>
<p><bold>B1 (DC):</bold> Duty cycling only</p></list-item>
<list-item>
<p><bold>B2 (PC):</bold> Power control only</p></list-item>
<list-item>
<p><bold>B3 (PS):</bold> Protocol switching only</p></list-item>
<list-item>
<p><bold>B4 (DC&#x002B;PC):</bold> Combined duty cycling and power control</p></list-item>
<list-item>
<p><bold>B5 (DC&#x002B;PS):</bold> Duty cycling with protocol switching</p></list-item>
<list-item>
<p><bold>B6 (PC&#x002B;PS):</bold> Power control with protocol switching</p></list-item>
<list-item>
<p><bold>Proposed (DC&#x002B;PC&#x002B;PS&#x002B;DQL):</bold> Full hybrid framework</p></list-item>
</list></p>
<p>Each configuration is evaluated using:<disp-formula id="eqn-42"><label>(42)</label><mml:math id="mml-eqn-42" display="block"><mml:mo fence="false" stretchy="false">{</mml:mo><mml:msub><mml:mi>E</mml:mi><mml:mrow><mml:mrow><mml:mtext>total</mml:mtext></mml:mrow></mml:mrow></mml:msub><mml:mo>,</mml:mo><mml:mtext>&#x00A0;</mml:mtext><mml:msub><mml:mi>&#x03B7;</mml:mi><mml:mrow><mml:mrow><mml:mtext>sys</mml:mtext></mml:mrow></mml:mrow></mml:msub><mml:mo>,</mml:mo><mml:mtext>&#x00A0;</mml:mtext><mml:mi>L</mml:mi><mml:mo>,</mml:mo><mml:mtext>&#x00A0;</mml:mtext><mml:mrow><mml:mtext>PDR</mml:mtext></mml:mrow><mml:mo fence="false" stretchy="false">}</mml:mo><mml:mo>.</mml:mo></mml:math></disp-formula></p>
<p>Results interpretation:</p>
<p>Let <inline-formula id="ieqn-245"><mml:math id="mml-ieqn-245"><mml:msub><mml:mi>&#x03B7;</mml:mi><mml:mi>i</mml:mi></mml:msub></mml:math></inline-formula> denote the efficiency of configuration <inline-formula id="ieqn-246"><mml:math id="mml-ieqn-246"><mml:mi>i</mml:mi></mml:math></inline-formula>. The marginal contribution of each component is quantified as:<disp-formula id="eqn-43"><label>(43)</label><mml:math id="mml-eqn-43" display="block"><mml:msub><mml:mi mathvariant="normal">&#x0394;</mml:mi><mml:mrow><mml:mrow><mml:mtext>DC</mml:mtext></mml:mrow></mml:mrow></mml:msub><mml:mo>=</mml:mo><mml:msub><mml:mi>&#x03B7;</mml:mi><mml:mrow><mml:mrow><mml:mtext>B1</mml:mtext></mml:mrow></mml:mrow></mml:msub><mml:mo>&#x2212;</mml:mo><mml:msub><mml:mi>&#x03B7;</mml:mi><mml:mrow><mml:mrow><mml:mtext>B0</mml:mtext></mml:mrow></mml:mrow></mml:msub><mml:mo>,</mml:mo><mml:mspace width="1em" /><mml:msub><mml:mi mathvariant="normal">&#x0394;</mml:mi><mml:mrow><mml:mrow><mml:mtext>PC</mml:mtext></mml:mrow></mml:mrow></mml:msub><mml:mo>=</mml:mo><mml:msub><mml:mi>&#x03B7;</mml:mi><mml:mrow><mml:mrow><mml:mtext>B2</mml:mtext></mml:mrow></mml:mrow></mml:msub><mml:mo>&#x2212;</mml:mo><mml:msub><mml:mi>&#x03B7;</mml:mi><mml:mrow><mml:mrow><mml:mtext>B0</mml:mtext></mml:mrow></mml:mrow></mml:msub><mml:mo>,</mml:mo><mml:mspace width="1em" /><mml:msub><mml:mi mathvariant="normal">&#x0394;</mml:mi><mml:mrow><mml:mrow><mml:mtext>PS</mml:mtext></mml:mrow></mml:mrow></mml:msub><mml:mo>=</mml:mo><mml:msub><mml:mi>&#x03B7;</mml:mi><mml:mrow><mml:mrow><mml:mtext>B3</mml:mtext></mml:mrow></mml:mrow></mml:msub><mml:mo>&#x2212;</mml:mo><mml:msub><mml:mi>&#x03B7;</mml:mi><mml:mrow><mml:mrow><mml:mtext>B0</mml:mtext></mml:mrow></mml:mrow></mml:msub><mml:mo>.</mml:mo></mml:math></disp-formula></p>
<p>We further analyze interaction effects:<disp-formula id="eqn-44"><label>(44)</label><mml:math id="mml-eqn-44" display="block"><mml:msub><mml:mi mathvariant="normal">&#x0394;</mml:mi><mml:mrow><mml:mrow><mml:mtext>interaction</mml:mtext></mml:mrow></mml:mrow></mml:msub><mml:mo>=</mml:mo><mml:msub><mml:mi>&#x03B7;</mml:mi><mml:mrow><mml:mrow><mml:mtext>B6</mml:mtext></mml:mrow></mml:mrow></mml:msub><mml:mo>&#x2212;</mml:mo><mml:mo stretchy="false">(</mml:mo><mml:msub><mml:mi>&#x03B7;</mml:mi><mml:mrow><mml:mrow><mml:mtext>B2</mml:mtext></mml:mrow></mml:mrow></mml:msub><mml:mo>+</mml:mo><mml:msub><mml:mi>&#x03B7;</mml:mi><mml:mrow><mml:mrow><mml:mtext>B3</mml:mtext></mml:mrow></mml:mrow></mml:msub><mml:mo>&#x2212;</mml:mo><mml:msub><mml:mi>&#x03B7;</mml:mi><mml:mrow><mml:mrow><mml:mtext>B0</mml:mtext></mml:mrow></mml:mrow></mml:msub><mml:mo stretchy="false">)</mml:mo><mml:mo>.</mml:mo></mml:math></disp-formula></p>
<p>Key findings:<list list-type="bullet">
<list-item>
<p>Duty cycling contributes the largest standalone energy reduction (<inline-formula id="ieqn-247"><mml:math id="mml-ieqn-247"><mml:mo>&#x223C;</mml:mo></mml:math></inline-formula>12%&#x2013;18%),</p></list-item>
<list-item>
<p>Power control improves efficiency under distance variability (<inline-formula id="ieqn-248"><mml:math id="mml-ieqn-248"><mml:mo>&#x223C;</mml:mo></mml:math></inline-formula>8%&#x2013;14%),</p></list-item>
<list-item>
<p>Protocol switching provides context-aware gains (<inline-formula id="ieqn-249"><mml:math id="mml-ieqn-249"><mml:mo>&#x223C;</mml:mo></mml:math></inline-formula>6%&#x2013;10%),</p></list-item>
<list-item>
<p>The full hybrid model yields super additive gains due to cross-layer interaction.</p></list-item>
</list></p>
<p>The assessment incorporates crucial real world factors to increase ecological credibility.</p>
<p>The likelihood of packet success is calculated as follows:<disp-formula id="eqn-45"><label>(45)</label><mml:math id="mml-eqn-45" display="block"><mml:msub><mml:mi>P</mml:mi><mml:mrow><mml:mrow><mml:mtext>succ</mml:mtext></mml:mrow></mml:mrow></mml:msub><mml:mo>=</mml:mo><mml:mi>exp</mml:mi><mml:mo>&#x2061;</mml:mo><mml:mrow><mml:mo>(</mml:mo><mml:mo>&#x2212;</mml:mo><mml:mfrac><mml:msub><mml:mi>&#x03B3;</mml:mi><mml:mrow><mml:mrow><mml:mtext>th</mml:mtext></mml:mrow></mml:mrow></mml:msub><mml:msub><mml:mi>&#x03B3;</mml:mi><mml:mi>k</mml:mi></mml:msub></mml:mfrac><mml:mo>)</mml:mo></mml:mrow><mml:mo>,</mml:mo></mml:math></disp-formula>where <inline-formula id="ieqn-250"><mml:math id="mml-ieqn-250"><mml:msub><mml:mi>&#x03B3;</mml:mi><mml:mi>k</mml:mi></mml:msub></mml:math></inline-formula> includes interference:<disp-formula id="eqn-46"><label>(46)</label><mml:math id="mml-eqn-46" display="block"><mml:msub><mml:mi>&#x03B3;</mml:mi><mml:mi>k</mml:mi></mml:msub><mml:mo>=</mml:mo><mml:mfrac><mml:mrow><mml:msub><mml:mi>P</mml:mi><mml:mrow><mml:mrow><mml:mtext>tx</mml:mtext></mml:mrow></mml:mrow></mml:msub><mml:msub><mml:mi>G</mml:mi><mml:mi>k</mml:mi></mml:msub><mml:mrow><mml:mo stretchy="false">|</mml:mo></mml:mrow><mml:msub><mml:mi>h</mml:mi><mml:mi>k</mml:mi></mml:msub><mml:msup><mml:mrow><mml:mo stretchy="false">|</mml:mo></mml:mrow><mml:mn>2</mml:mn></mml:msup></mml:mrow><mml:mrow><mml:msub><mml:mi>N</mml:mi><mml:mn>0</mml:mn></mml:msub><mml:mi>B</mml:mi><mml:mo>+</mml:mo><mml:msub><mml:mi>I</mml:mi><mml:mi>k</mml:mi></mml:msub></mml:mrow></mml:mfrac><mml:mo>.</mml:mo></mml:math></disp-formula></p>
<p>Node positions evolve according to a random waypoint model:<disp-formula id="eqn-47"><label>(47)</label><mml:math id="mml-eqn-47" display="block"><mml:msub><mml:mi>d</mml:mi><mml:mi>k</mml:mi></mml:msub><mml:mo>=</mml:mo><mml:mo fence="false" stretchy="false">&#x2016;</mml:mo><mml:msub><mml:mrow><mml:mtext mathvariant="bold">x</mml:mtext></mml:mrow><mml:mi>i</mml:mi></mml:msub><mml:mo stretchy="false">(</mml:mo><mml:mi>k</mml:mi><mml:mo stretchy="false">)</mml:mo><mml:mo>&#x2212;</mml:mo><mml:msub><mml:mrow><mml:mtext mathvariant="bold">x</mml:mtext></mml:mrow><mml:mi>j</mml:mi></mml:msub><mml:mo stretchy="false">(</mml:mo><mml:mi>k</mml:mi><mml:mo stretchy="false">)</mml:mo><mml:mo fence="false" stretchy="false">&#x2016;</mml:mo><mml:mo>,</mml:mo></mml:math></disp-formula>introducing connectivity quality that varies throughout time.</p>
<p>A time varying graph is used to illustrate network connectivity as follows:<disp-formula id="eqn-48"><label>(48)</label><mml:math id="mml-eqn-48" display="block"><mml:mrow><mml:mi>&#x1D4A2;</mml:mi></mml:mrow><mml:mo stretchy="false">(</mml:mo><mml:mi>k</mml:mi><mml:mo stretchy="false">)</mml:mo><mml:mo>=</mml:mo><mml:mo stretchy="false">(</mml:mo><mml:mrow><mml:mi>&#x1D4B1;</mml:mi></mml:mrow><mml:mo>,</mml:mo><mml:mrow><mml:mi>&#x2130;</mml:mi></mml:mrow><mml:mo stretchy="false">(</mml:mo><mml:mi>k</mml:mi><mml:mo stretchy="false">)</mml:mo><mml:mo stretchy="false">)</mml:mo><mml:mo>,</mml:mo></mml:math></disp-formula>where linkages develop and vanish according to channel conditions and distance.</p>
<p>In these circumstances:<list list-type="bullet">
<list-item>
<p>Duty cycling adapts to traffic bursts and link intermittency,</p></list-item>
<list-item>
<p>Power control compensates for fading and mobility,</p></list-item>
<list-item>
<p>Protocol switching reacts to topology density and link reliability.</p></list-item>
</list></p>
<p>Battery lifetime is estimated as:<disp-formula id="eqn-49"><label>(49)</label><mml:math id="mml-eqn-49" display="block"><mml:msub><mml:mi>T</mml:mi><mml:mrow><mml:mrow><mml:mtext>life</mml:mtext></mml:mrow></mml:mrow></mml:msub><mml:mo>=</mml:mo><mml:mfrac><mml:mrow><mml:msub><mml:mi>C</mml:mi><mml:mrow><mml:mrow><mml:mtext>bat</mml:mtext></mml:mrow></mml:mrow></mml:msub><mml:mo>&#x22C5;</mml:mo><mml:msub><mml:mi>V</mml:mi><mml:mrow><mml:mrow><mml:mtext>nom</mml:mtext></mml:mrow></mml:mrow></mml:msub></mml:mrow><mml:msub><mml:mrow><mml:mover><mml:mi>P</mml:mi><mml:mo stretchy="false">&#x00AF;</mml:mo></mml:mover></mml:mrow><mml:mrow><mml:mrow><mml:mtext>total</mml:mtext></mml:mrow></mml:mrow></mml:msub></mml:mfrac><mml:mo>,</mml:mo></mml:math></disp-formula>where <inline-formula id="ieqn-251"><mml:math id="mml-ieqn-251"><mml:msub><mml:mi>C</mml:mi><mml:mrow><mml:mtext>bat</mml:mtext></mml:mrow></mml:msub></mml:math></inline-formula> is capacity (Ah), <inline-formula id="ieqn-252"><mml:math id="mml-ieqn-252"><mml:msub><mml:mi>V</mml:mi><mml:mrow><mml:mtext>nom</mml:mtext></mml:mrow></mml:msub></mml:math></inline-formula> is nominal voltage, and <inline-formula id="ieqn-253"><mml:math id="mml-ieqn-253"><mml:msub><mml:mrow><mml:mover><mml:mi>P</mml:mi><mml:mo stretchy="false">&#x00AF;</mml:mo></mml:mover></mml:mrow><mml:mrow><mml:mtext>total</mml:mtext></mml:mrow></mml:msub></mml:math></inline-formula> is average power.</p>
<p>For each configuration:<disp-formula id="eqn-50"><label>(50)</label><mml:math id="mml-eqn-50" display="block"><mml:msub><mml:mrow><mml:mover><mml:mi>T</mml:mi><mml:mo stretchy="false">&#x00AF;</mml:mo></mml:mover></mml:mrow><mml:mrow><mml:mrow><mml:mtext>life</mml:mtext></mml:mrow></mml:mrow></mml:msub><mml:mo>&#x00B1;</mml:mo><mml:mn>1.96</mml:mn><mml:mfrac><mml:msub><mml:mi>&#x03C3;</mml:mi><mml:mi>T</mml:mi></mml:msub><mml:msqrt><mml:mi>N</mml:mi></mml:msqrt></mml:mfrac><mml:mo>,</mml:mo></mml:math></disp-formula>guaranteeing statistical assurance.</p>
<p>Improvements in battery longevity are assessed in comparison to the static power baseline:<disp-formula id="eqn-51"><label>(51)</label><mml:math id="mml-eqn-51" display="block"><mml:mi mathvariant="normal">&#x0394;</mml:mi><mml:mi>T</mml:mi><mml:mo>=</mml:mo><mml:msub><mml:mi>T</mml:mi><mml:mrow><mml:mrow><mml:mtext>proposed</mml:mtext></mml:mrow></mml:mrow></mml:msub><mml:mo>&#x2212;</mml:mo><mml:msub><mml:mi>T</mml:mi><mml:mrow><mml:mrow><mml:mtext>baseline</mml:mtext></mml:mrow></mml:mrow></mml:msub><mml:mo>.</mml:mo></mml:math></disp-formula></p>
<p>Across <inline-formula id="ieqn-254"><mml:math id="mml-ieqn-254"><mml:mi>N</mml:mi><mml:mo>=</mml:mo><mml:mn>10</mml:mn></mml:math></inline-formula> runs:<disp-formula id="eqn-52"><label>(52)</label><mml:math id="mml-eqn-52" display="block"><mml:mi mathvariant="normal">&#x0394;</mml:mi><mml:mi>T</mml:mi><mml:mo>=</mml:mo><mml:mn>16.4</mml:mn><mml:mo>&#x00B1;</mml:mo><mml:mn>1.8</mml:mn><mml:mtext>&#x00A0;</mml:mtext><mml:mrow><mml:mtext>hours</mml:mtext></mml:mrow><mml:mspace width="1em" /><mml:mo stretchy="false">(</mml:mo><mml:mn>95</mml:mn><mml:mi mathvariant="normal">&#x0025;</mml:mi><mml:mtext>&#x00A0;</mml:mtext><mml:mrow><mml:mtext>CI</mml:mtext></mml:mrow><mml:mo stretchy="false">)</mml:mo><mml:mo>,</mml:mo></mml:math></disp-formula>demonstrating consistent improvement.</p>
<p>To avoid platform bias, we also report:<disp-formula id="eqn-53"><label>(53)</label><mml:math id="mml-eqn-53" display="block"><mml:mfrac><mml:mrow><mml:mi mathvariant="normal">&#x0394;</mml:mi><mml:mi>T</mml:mi></mml:mrow><mml:msub><mml:mi>T</mml:mi><mml:mrow><mml:mrow><mml:mtext>baseline</mml:mtext></mml:mrow></mml:mrow></mml:msub></mml:mfrac><mml:mo>&#x2248;</mml:mo><mml:mn>25</mml:mn><mml:mi mathvariant="normal">&#x0025;</mml:mi><mml:mo>&#x00B1;</mml:mo><mml:mn>3</mml:mn><mml:mi mathvariant="normal">&#x0025;</mml:mi><mml:mo>.</mml:mo></mml:math></disp-formula></p>
<p>The improvement should be interpreted as:<list list-type="bullet">
<list-item>
<p>A <italic>relative gain</italic> under controlled workload conditions,</p></list-item>
<list-item>
<p>Dependent on traffic model and duty cycle,</p></list-item>
<list-item>
<p>Not directly transferable across hardware platforms without normalization.</p></list-item>
</list></p>
<p>Reinforcement learning provides significant advantages over heuristic control, according to the ablation experiment; nevertheless, its efficacy increases when deterministic protection is included. The hybrid approach is suitable for both energy-intensive and dynamic Internet of Things applications because it strikes a balance between resilience and high performance.</p>
</sec>
</sec>
<sec id="s4_4">
<label>4.4</label>
<title>Quantitative Ablation Analysis and Statistical Validation</title>
<p>The goal of the ablation study was to separate each major optimization component&#x2019;s impact on the suggested framework. Each of the above stated modules was looked at separately:<list list-type="bullet">
<list-item>
<p>adaptive protocol selection,</p></list-item>
<list-item>
<p>constrained Deep Q-Learning (DQL),</p></list-item>
<list-item>
<p>workload-aware duty-cycle adaptation,</p></list-item>
<list-item>
<p>residual-energy-aware transmission control,</p></list-item>
<list-item>
<p>and communication-aware scheduling.</p></list-item>
</list></p>
<p>While keeping the same traffic models, communication specifications, and workload circumstances, each component was gradually activated. The test was carried out in periodic, bursty, as well as event-driven traffic conditions in order to assure resilience in a variety of IoT operational environments.</p>
<sec id="s4_4_1">
<label>4.4.1</label>
<title>Component-Wise Contribution Analysis</title>
<p>To measure the relative influence of every single module, the normalised contribution ratio was developed:<disp-formula id="ueqn-58"><mml:math id="mml-ueqn-58" display="block"><mml:msub><mml:mi>R</mml:mi><mml:mi>i</mml:mi></mml:msub><mml:mo>=</mml:mo><mml:mfrac><mml:mrow><mml:msub><mml:mi>M</mml:mi><mml:mrow><mml:mrow><mml:mtext>baseline</mml:mtext></mml:mrow></mml:mrow></mml:msub><mml:mo>&#x2212;</mml:mo><mml:msub><mml:mi>M</mml:mi><mml:mi>i</mml:mi></mml:msub></mml:mrow><mml:msub><mml:mi>M</mml:mi><mml:mrow><mml:mrow><mml:mtext>baseline</mml:mtext></mml:mrow></mml:mrow></mml:msub></mml:mfrac><mml:mo>,</mml:mo></mml:math></disp-formula>where <inline-formula id="ieqn-255"><mml:math id="mml-ieqn-255"><mml:msub><mml:mi>R</mml:mi><mml:mi>i</mml:mi></mml:msub></mml:math></inline-formula> represents the contribution ratio of component <inline-formula id="ieqn-256"><mml:math id="mml-ieqn-256"><mml:mi>i</mml:mi></mml:math></inline-formula>, <inline-formula id="ieqn-257"><mml:math id="mml-ieqn-257"><mml:msub><mml:mi>M</mml:mi><mml:mrow><mml:mtext>baseline</mml:mtext></mml:mrow></mml:msub></mml:math></inline-formula> denotes the baseline system metric, and <inline-formula id="ieqn-258"><mml:math id="mml-ieqn-258"><mml:msub><mml:mi>M</mml:mi><mml:mi>i</mml:mi></mml:msub></mml:math></inline-formula> corresponds to the measured performance after enabling component <inline-formula id="ieqn-259"><mml:math id="mml-ieqn-259"><mml:mi>i</mml:mi></mml:math></inline-formula>.</p>
<p>We report contribution ratios for:<list list-type="bullet">
<list-item>
<p>communication energy reduction,</p></list-item>
<list-item>
<p>latency improvement,</p></list-item>
<list-item>
<p>throughput enhancement,</p></list-item>
<list-item>
<p>and computational efficiency.</p></list-item>
</list></p>
<p>The experimental analysis demonstrates that:<list list-type="bullet">
<list-item>
<p>adaptive protocol selection contributed approximately 11%&#x2013;14% energy reduction,</p></list-item>
<list-item>
<p>duty-cycle adaptation contributed 8%&#x2013;10%,</p></list-item>
<list-item>
<p>constrained DQL contributed 15%&#x2013;18%,</p></list-item>
<list-item>
<p>and communication-aware scheduling contributed 6%&#x2013;9%.</p></list-item>
</list></p>
<p>The combined hybrid framework achieved approximately 25%&#x2013;31% total energy improvement compared with the fixed-policy baseline.</p>
</sec>
<sec id="s4_4_2">
<label>4.4.2</label>
<title>Statistical Validation</title>
<p>To increase experimental rigor, all experiments were repeated in numerous independent runs with identical workload setups.</p>
<p>For each analyzed statistic, the sample average was calculated as follows:<disp-formula id="ueqn-59"><mml:math id="mml-ueqn-59" display="block"><mml:mi>&#x03BC;</mml:mi><mml:mo>=</mml:mo><mml:mfrac><mml:mn>1</mml:mn><mml:mi>N</mml:mi></mml:mfrac><mml:munderover><mml:mo movablelimits="false">&#x2211;</mml:mo><mml:mrow><mml:mi>i</mml:mi><mml:mo>=</mml:mo><mml:mn>1</mml:mn></mml:mrow><mml:mrow><mml:mi>N</mml:mi></mml:mrow></mml:munderover><mml:msub><mml:mi>x</mml:mi><mml:mi>i</mml:mi></mml:msub><mml:mo>,</mml:mo></mml:math></disp-formula>and the corresponding standard deviation was calculated using:<disp-formula id="ueqn-60"><mml:math id="mml-ueqn-60" display="block"><mml:mi>&#x03C3;</mml:mi><mml:mo>=</mml:mo><mml:msqrt><mml:mfrac><mml:mn>1</mml:mn><mml:mrow><mml:mi>N</mml:mi><mml:mo>&#x2212;</mml:mo><mml:mn>1</mml:mn></mml:mrow></mml:mfrac><mml:munderover><mml:mo movablelimits="false">&#x2211;</mml:mo><mml:mrow><mml:mi>i</mml:mi><mml:mo>=</mml:mo><mml:mn>1</mml:mn></mml:mrow><mml:mrow><mml:mi>N</mml:mi></mml:mrow></mml:munderover><mml:mo stretchy="false">(</mml:mo><mml:msub><mml:mi>x</mml:mi><mml:mi>i</mml:mi></mml:msub><mml:mo>&#x2212;</mml:mo><mml:mi>&#x03BC;</mml:mi><mml:msup><mml:mo stretchy="false">)</mml:mo><mml:mn>2</mml:mn></mml:msup></mml:msqrt><mml:mo>.</mml:mo></mml:math></disp-formula></p>
<p>Additionally, <inline-formula id="ieqn-260"><mml:math id="mml-ieqn-260"><mml:mn>95</mml:mn><mml:mi mathvariant="normal">&#x0025;</mml:mi></mml:math></inline-formula> confidence intervals were estimated according to:<disp-formula id="ueqn-61"><mml:math id="mml-ueqn-61" display="block"><mml:mi>C</mml:mi><mml:mi>I</mml:mi><mml:mo>=</mml:mo><mml:mi>&#x03BC;</mml:mi><mml:mo>&#x00B1;</mml:mo><mml:mn>1.96</mml:mn><mml:mfrac><mml:mi>&#x03C3;</mml:mi><mml:msqrt><mml:mi>N</mml:mi></mml:msqrt></mml:mfrac><mml:mo>.</mml:mo></mml:math></disp-formula></p>
<p>To confirm statistical significance among the proposed framework as well as baseline approaches, paired <inline-formula id="ieqn-261"><mml:math id="mml-ieqn-261"><mml:mi>t</mml:mi></mml:math></inline-formula>-tests were undertaken across numerous experimental trials. The null hypothesis suggested that there was no substantial difference in performance between the strategies being compared.</p>
<p>The experimental results show statistically significant improvement with:<disp-formula id="ueqn-62"><mml:math id="mml-ueqn-62" display="block"><mml:mi>p</mml:mi><mml:mo>&#x003C;</mml:mo><mml:mn>0.05</mml:mn><mml:mo>,</mml:mo></mml:math></disp-formula>for reducing communication energy, minimizing latency, and increasing throughput across all measured workload situations.</p>
</sec>
<sec id="s4_4_3">
<label>4.4.3</label>
<title>Robustness across Traffic Conditions</title>
<p>To improve the ablation analysis, component level assessments were performed under a variety of traffic intensities and network circumstances. Our findings show that the limited DQL as well as adaptive protocol selection modules retain consistent performance benefits under:<list list-type="bullet">
<list-item>
<p>low-load periodic sensing,</p></list-item>
<list-item>
<p>medium-load burst traffic,</p></list-item>
<list-item>
<p>and highly dynamic event-driven workloads.</p></list-item>
</list></p>
<p>The sensitivity of each optimization component was also evaluated by varying reward-weight coefficients:<disp-formula id="ueqn-63"><mml:math id="mml-ueqn-63" display="block"><mml:mi>R</mml:mi><mml:mo>=</mml:mo><mml:mi>&#x03B1;</mml:mi><mml:mi>E</mml:mi><mml:mo>+</mml:mo><mml:mi>&#x03B2;</mml:mi><mml:mi>L</mml:mi><mml:mo>+</mml:mo><mml:mi>&#x03B3;</mml:mi><mml:mi>T</mml:mi><mml:mo>,</mml:mo></mml:math></disp-formula>where <inline-formula id="ieqn-262"><mml:math id="mml-ieqn-262"><mml:mi>E</mml:mi></mml:math></inline-formula>, <inline-formula id="ieqn-263"><mml:math id="mml-ieqn-263"><mml:mi>L</mml:mi></mml:math></inline-formula>, and <inline-formula id="ieqn-264"><mml:math id="mml-ieqn-264"><mml:mi>T</mml:mi></mml:math></inline-formula> represent energy, latency, and throughput objectives, respectively.</p>
<p>The research shows that the suggested hybrid framework maintains steady convergence behavior over mild fluctuations in <inline-formula id="ieqn-265"><mml:math id="mml-ieqn-265"><mml:mi>&#x03B1;</mml:mi></mml:math></inline-formula>, <inline-formula id="ieqn-266"><mml:math id="mml-ieqn-266"><mml:mi>&#x03B2;</mml:mi></mml:math></inline-formula>, as well as <inline-formula id="ieqn-267"><mml:math id="mml-ieqn-267"><mml:mi>&#x03B3;</mml:mi></mml:math></inline-formula>, thereby increasing the resilience and repeatability of the optimization technique.</p>
<p>We clearly state that the measured performance increases are not due to a specific optimization method, but rather to the coordinated interplay of communication adaptability, restricted learning, as well as workload-aware scheduling.</p>
</sec>
</sec>
</sec>
<sec id="s5">
<label>5</label>
<title>Experimental Setup and Results</title>
<p>We built a test IoT robot on the NVIDIA Jetson TX2 platform to see how well the proposed methods worked. The TX2 had built in power sensors that measured the CPU, GPU, and system&#x2019;s voltage and current. We used a convolutional neural network (MobileNetV2) on the TX2 to simulate a vision based task while changing the settings for the network and hardware. We sent telemetry packets at set times to simulate communication with a base station over Wi-Fi or BLE.</p>
<p>The main experimental results include:<list list-type="simple">
<list-item>
<label>1.</label>
<p>Restricting the TX2 to a single CPU core yielded substantial energy savings. Operating on a single core rather than all cores reduced power consumption by approximately 45% with minimal inference latency increase. Reducing CPU frequency to an optimal level of approximately 307 MHz decreased power consumption by roughly 12% without affecting latency.</p></list-item>
<list-item>
<label>2.</label>
<p>Effect of Duty Cycle: Implementing strict sleep scheduling during idle periods (low duty cycle) achieved significant energy savings. For example, reducing duty cycle from 100% to 20% (active/sleep ratio) decreased average power consumption without data loss due to low sensor activity.</p></list-item>
<list-item>
<label>3.</label>
<p>We looked at how much energy it takes to convey a message and how far the connections could travel. For lengthy connections (more than 50 m) to operate, they require a greater <inline-formula id="ieqn-268"><mml:math id="mml-ieqn-268"><mml:msub><mml:mi>P</mml:mi><mml:mrow><mml:mtext>tx</mml:mtext></mml:mrow></mml:msub></mml:math></inline-formula>, which indicates that <inline-formula id="ieqn-269"><mml:math id="mml-ieqn-269"><mml:msub><mml:mi>E</mml:mi><mml:mrow><mml:mtext>tx</mml:mtext></mml:mrow></mml:msub></mml:math></inline-formula> goes up in a straight line with airtime. Sending and receiving data via BLE connections that are near by doesn&#x2019;t require as much power. These findings indicate how useful it is to move between tasks based on the range. We use BLE for distances of up to 10 m and LoRaWAN for distances longer than that.</p></list-item>
<list-item>
<label>4.</label>
<p>The dynamic power method, which used residual energy thresholding, led to measurable improvements in adaptive control. In a multi node test, nodes with adaptive power control had a 20%&#x2013;25% longer uptime (the time it took for the battery to run out) than nodes with fixed power settings. This is in line with the 25% longer battery life mentioned earlier.</p></list-item>
</list></p>
<p>Forward inference, replay sampling, as well as gradient updates are the most common processes for each decision step:<disp-formula id="eqn-54"><label>(54)</label><mml:math id="mml-eqn-54" display="block"><mml:msub><mml:mrow><mml:mi>&#x1D49E;</mml:mi></mml:mrow><mml:mrow><mml:mrow><mml:mtext>step</mml:mtext></mml:mrow></mml:mrow></mml:msub><mml:mo>=</mml:mo><mml:mrow><mml:mi>&#x1D4AA;</mml:mi></mml:mrow><mml:mo stretchy="false">(</mml:mo><mml:mrow><mml:mo stretchy="false">|</mml:mo></mml:mrow><mml:mrow><mml:mi>&#x1D49C;</mml:mi></mml:mrow><mml:mrow><mml:mo stretchy="false">|</mml:mo></mml:mrow><mml:mo stretchy="false">)</mml:mo><mml:mo>+</mml:mo><mml:mrow><mml:mi>&#x1D4AA;</mml:mi></mml:mrow><mml:mo stretchy="false">(</mml:mo><mml:mi>B</mml:mi><mml:mo>&#x22C5;</mml:mo><mml:mi>d</mml:mi><mml:mo stretchy="false">)</mml:mo><mml:mo>,</mml:mo></mml:math></disp-formula>where <inline-formula id="ieqn-270"><mml:math id="mml-ieqn-270"><mml:mrow><mml:mo stretchy="false">|</mml:mo></mml:mrow><mml:mrow><mml:mi>&#x1D49C;</mml:mi></mml:mrow><mml:mrow><mml:mo stretchy="false">|</mml:mo></mml:mrow></mml:math></inline-formula> is the discrete action space size, <inline-formula id="ieqn-271"><mml:math id="mml-ieqn-271"><mml:mi>B</mml:mi></mml:math></inline-formula> is the mini batch size, and <inline-formula id="ieqn-272"><mml:math id="mml-ieqn-272"><mml:mi>d</mml:mi></mml:math></inline-formula> is the number of network parameters.</p>
<p>For <inline-formula id="ieqn-273"><mml:math id="mml-ieqn-273"><mml:mi>K</mml:mi></mml:math></inline-formula> steps per episode:<disp-formula id="eqn-55"><label>(55)</label><mml:math id="mml-eqn-55" display="block"><mml:msub><mml:mrow><mml:mi>&#x1D49E;</mml:mi></mml:mrow><mml:mrow><mml:mrow><mml:mtext>episode</mml:mtext></mml:mrow></mml:mrow></mml:msub><mml:mo>=</mml:mo><mml:mrow><mml:mi>&#x1D4AA;</mml:mi></mml:mrow><mml:mrow><mml:mo>(</mml:mo><mml:mi>K</mml:mi><mml:mo stretchy="false">(</mml:mo><mml:mrow><mml:mo stretchy="false">|</mml:mo></mml:mrow><mml:mrow><mml:mi>&#x1D49C;</mml:mi></mml:mrow><mml:mrow><mml:mo stretchy="false">|</mml:mo></mml:mrow><mml:mo>+</mml:mo><mml:mi>B</mml:mi><mml:mo>&#x22C5;</mml:mo><mml:mi>d</mml:mi><mml:mo stretchy="false">)</mml:mo><mml:mo>)</mml:mo></mml:mrow><mml:mo>.</mml:mo></mml:math></disp-formula></p>
<p>For a swarm of <inline-formula id="ieqn-274"><mml:math id="mml-ieqn-274"><mml:mi>N</mml:mi></mml:math></inline-formula> nodes, two deployment regimes are considered:<list list-type="bullet">
<list-item>
<p><bold>Centralized training (parameter sharing):</bold>
<disp-formula id="eqn-56"><label>(56)</label><mml:math id="mml-eqn-56" display="block"><mml:msubsup><mml:mrow><mml:mi>&#x1D49E;</mml:mi></mml:mrow><mml:mrow><mml:mrow><mml:mtext>swarm</mml:mtext></mml:mrow></mml:mrow><mml:mrow><mml:mrow><mml:mtext>central</mml:mtext></mml:mrow></mml:mrow></mml:msubsup><mml:mo>=</mml:mo><mml:mrow><mml:mi>&#x1D4AA;</mml:mi></mml:mrow><mml:mrow><mml:mo>(</mml:mo><mml:mi>N</mml:mi><mml:mi>K</mml:mi><mml:mo>+</mml:mo><mml:mi>B</mml:mi><mml:mo>&#x22C5;</mml:mo><mml:mi>d</mml:mi><mml:mo>)</mml:mo></mml:mrow><mml:mo>,</mml:mo></mml:math></disp-formula>where experience is aggregated but a single shared model is trained.</p></list-item>
<list-item>
<p><bold>Fully decentralized learning:</bold>
<disp-formula id="eqn-57"><label>(57)</label><mml:math id="mml-eqn-57" display="block"><mml:msubsup><mml:mrow><mml:mi>&#x1D49E;</mml:mi></mml:mrow><mml:mrow><mml:mrow><mml:mtext>swarm</mml:mtext></mml:mrow></mml:mrow><mml:mrow><mml:mrow><mml:mtext>decentral</mml:mtext></mml:mrow></mml:mrow></mml:msubsup><mml:mo>=</mml:mo><mml:mrow><mml:mi>&#x1D4AA;</mml:mi></mml:mrow><mml:mrow><mml:mo>(</mml:mo><mml:mi>N</mml:mi><mml:mi>K</mml:mi><mml:mo stretchy="false">(</mml:mo><mml:mrow><mml:mo stretchy="false">|</mml:mo></mml:mrow><mml:mrow><mml:mi>&#x1D49C;</mml:mi></mml:mrow><mml:mrow><mml:mo stretchy="false">|</mml:mo></mml:mrow><mml:mo>+</mml:mo><mml:mi>B</mml:mi><mml:mo>&#x22C5;</mml:mo><mml:mi>d</mml:mi><mml:mo stretchy="false">)</mml:mo><mml:mo>)</mml:mo></mml:mrow><mml:mo>.</mml:mo></mml:math></disp-formula></p>
</list-item>
</list></p>
<p>To ensure scalability beyond <inline-formula id="ieqn-275"><mml:math id="mml-ieqn-275"><mml:msup><mml:mn>10</mml:mn><mml:mn>2</mml:mn></mml:msup></mml:math></inline-formula>&#x2013;<inline-formula id="ieqn-276"><mml:math id="mml-ieqn-276"><mml:msup><mml:mn>10</mml:mn><mml:mn>3</mml:mn></mml:msup></mml:math></inline-formula> nodes, we adopt:<list list-type="bullet">
<list-item>
<p>Parameter sharing across homogeneous agents,</p></list-item>
<list-item>
<p>Event triggered updates (reducing <inline-formula id="ieqn-277"><mml:math id="mml-ieqn-277"><mml:mi>K</mml:mi></mml:math></inline-formula>),</p></list-item>
<list-item>
<p>Model compression (pruning and quantization),</p></list-item>
<list-item>
<p>Federated aggregation to limit communication overhead.</p></list-item>
</list></p>
<p>The additional communication cost due to learning updates is:<disp-formula id="eqn-58"><label>(58)</label><mml:math id="mml-eqn-58" display="block"><mml:msub><mml:mi>E</mml:mi><mml:mrow><mml:mrow><mml:mtext>model</mml:mtext></mml:mrow></mml:mrow></mml:msub><mml:mo>&#x221D;</mml:mo><mml:msub><mml:mi>f</mml:mi><mml:mrow><mml:mrow><mml:mtext>update</mml:mtext></mml:mrow></mml:mrow></mml:msub><mml:mo>&#x22C5;</mml:mo><mml:msub><mml:mi>S</mml:mi><mml:mrow><mml:mrow><mml:mtext>model</mml:mtext></mml:mrow></mml:mrow></mml:msub><mml:mo>,</mml:mo></mml:math></disp-formula>where <inline-formula id="ieqn-278"><mml:math id="mml-ieqn-278"><mml:msub><mml:mi>S</mml:mi><mml:mrow><mml:mtext>model</mml:mtext></mml:mrow></mml:msub></mml:math></inline-formula> is the model size and <inline-formula id="ieqn-279"><mml:math id="mml-ieqn-279"><mml:msub><mml:mi>f</mml:mi><mml:mrow><mml:mtext>update</mml:mtext></mml:mrow></mml:msub></mml:math></inline-formula> is the update frequency. Our approach has very low overhead (&#x003C;5% of total communication energy) since updates happen less often than data transport.</p>
<p>Instead of imitating a typical IoT microcontroller, the NVIDIA Jetson TX2 architecture is designed to provide:<list list-type="bullet">
<list-item>
<p>Fine grained power measurement capability,</p></list-item>
<list-item>
<p>Sufficient compute resources for controlled DQL experimentation,</p></list-item>
<list-item>
<p>Repeatable profiling across heterogeneous protocol stacks.</p></list-item>
</list></p>
<p>The TX2 platform&#x2019;s absolute power consumption figures (in watts) should not be immediately extrapolated to sub 100 mW microcontroller based IoT devices.</p>
<p>Instead, the TX2 outcomes are used as a regulated proxy to capture:<list list-type="bullet">
<list-item>
<p>Relative energy trends across protocols,</p></list-item>
<list-item>
<p>Policy adaptation behavior,</p></list-item>
<list-item>
<p>Trade offs between energy, latency, and reliability.</p></list-item>
</list></p>
<p>To improve practical relevance, we additionally:<list list-type="bullet">
<list-item>
<p>Normalize results using energy per bit (J/bit),</p></list-item>
<list-item>
<p>Report duty cycle ratios and state transition frequencies,</p></list-item>
<list-item>
<p>Provide complexity bounds compatible with MCU deployment.</p></list-item>
</list></p>
<p>To eliminate experimental bias, all protocols are evaluated under identical conditions:<list list-type="bullet">
<list-item>
<p>Identical payload size (<inline-formula id="ieqn-280"><mml:math id="mml-ieqn-280"><mml:msub><mml:mi>S</mml:mi><mml:mrow><mml:mtext>payload</mml:mtext></mml:mrow></mml:msub></mml:math></inline-formula>),</p></list-item>
<list-item>
<p>Identical traffic workload (periodic, bursty, event driven),</p></list-item>
<list-item>
<p>Identical duty cycle configuration,</p></list-item>
<list-item>
<p>Identical observation window <inline-formula id="ieqn-281"><mml:math id="mml-ieqn-281"><mml:msub><mml:mi>T</mml:mi><mml:mrow><mml:mtext>obs</mml:mtext></mml:mrow></mml:msub></mml:math></inline-formula>.</p></list-item>
</list>
<disp-formula id="eqn-59"><label>(59)</label><mml:math id="mml-eqn-59" display="block"><mml:mi>&#x03B7;</mml:mi><mml:mo>=</mml:mo><mml:mfrac><mml:msub><mml:mi>B</mml:mi><mml:mrow><mml:mrow><mml:mtext>delivered</mml:mtext></mml:mrow></mml:mrow></mml:msub><mml:msub><mml:mi>E</mml:mi><mml:mrow><mml:mrow><mml:mtext>comm</mml:mtext></mml:mrow></mml:mrow></mml:msub></mml:mfrac><mml:mo>,</mml:mo></mml:math></disp-formula>where both numerator and denominator are measured over the same interval.</p>
<p>To strengthen reproducibility:<list list-type="bullet">
<list-item>
<p>Synthetic workloads are cross validated with standardized traffic models,</p></list-item>
<list-item>
<p>Results are compared against publicly reported protocol characteristics,</p></list-item>
<list-item>
<p>All hyperparameters and seeds are fixed and disclosed.</p></list-item>
</list></p>
<p>All results are averaged over <inline-formula id="ieqn-282"><mml:math id="mml-ieqn-282"><mml:mi>N</mml:mi><mml:mo>=</mml:mo><mml:mn>10</mml:mn></mml:math></inline-formula> runs:<disp-formula id="eqn-60"><label>(60)</label><mml:math id="mml-eqn-60" display="block"><mml:mi>&#x03BC;</mml:mi><mml:mo>&#x00B1;</mml:mo><mml:mn>1.96</mml:mn><mml:mfrac><mml:mi>&#x03C3;</mml:mi><mml:msqrt><mml:mi>N</mml:mi></mml:msqrt></mml:mfrac><mml:mo>,</mml:mo></mml:math></disp-formula>ensuring statistical confidence in reported improvements.</p>
<p>Let <inline-formula id="ieqn-283"><mml:math id="mml-ieqn-283"><mml:msub><mml:mi>&#x03B7;</mml:mi><mml:mi>i</mml:mi></mml:msub></mml:math></inline-formula> denote efficiency of method <inline-formula id="ieqn-284"><mml:math id="mml-ieqn-284"><mml:mi>i</mml:mi></mml:math></inline-formula>. The relative improvement is:<disp-formula id="eqn-61"><label>(61)</label><mml:math id="mml-eqn-61" display="block"><mml:msub><mml:mi mathvariant="normal">&#x0394;</mml:mi><mml:mi>i</mml:mi></mml:msub><mml:mo>=</mml:mo><mml:mfrac><mml:mrow><mml:msub><mml:mi>&#x03B7;</mml:mi><mml:mrow><mml:mrow><mml:mtext>proposed</mml:mtext></mml:mrow></mml:mrow></mml:msub><mml:mo>&#x2212;</mml:mo><mml:msub><mml:mi>&#x03B7;</mml:mi><mml:mi>i</mml:mi></mml:msub></mml:mrow><mml:msub><mml:mi>&#x03B7;</mml:mi><mml:mi>i</mml:mi></mml:msub></mml:mfrac><mml:mo>.</mml:mo></mml:math></disp-formula></p>
<p>The proposed hybrid approach achieves:<list list-type="bullet">
<list-item>
<p><inline-formula id="ieqn-285"><mml:math id="mml-ieqn-285"><mml:mn>25</mml:mn><mml:mi mathvariant="normal">&#x0025;</mml:mi></mml:math></inline-formula> improvement over fixed power baseline,</p></list-item>
<list-item>
<p><inline-formula id="ieqn-286"><mml:math id="mml-ieqn-286"><mml:mn>15</mml:mn></mml:math></inline-formula>%&#x2013;<inline-formula id="ieqn-287"><mml:math id="mml-ieqn-287"><mml:mn>20</mml:mn><mml:mi mathvariant="normal">&#x0025;</mml:mi></mml:math></inline-formula> over rule based methods,</p></list-item>
<list-item>
<p><inline-formula id="ieqn-288"><mml:math id="mml-ieqn-288"><mml:mn>8</mml:mn></mml:math></inline-formula>%&#x2013;<inline-formula id="ieqn-289"><mml:math id="mml-ieqn-289"><mml:mn>12</mml:mn><mml:mi mathvariant="normal">&#x0025;</mml:mi></mml:math></inline-formula> over model based heuristics,</p></list-item>
<list-item>
<p>consistent gains over DQL only due to constraint aware design.</p></list-item>
</list></p>
<p>These results indicate that:<list list-type="bullet">
<list-item>
<p>Improvements are not due to weak baselines,</p></list-item>
<list-item>
<p>The RL component contributes measurable gains beyond heuristics,</p></list-item>
<list-item>
<p>Hybridization is critical for stability and efficiency.</p></list-item>
</list></p>
<p>For large-scale deployments:<list list-type="bullet">
<list-item>
<p>Policy sharing reduces training cost from <inline-formula id="ieqn-290"><mml:math id="mml-ieqn-290"><mml:mrow><mml:mi>&#x1D4AA;</mml:mi></mml:mrow><mml:mo stretchy="false">(</mml:mo><mml:mi>N</mml:mi><mml:mo stretchy="false">)</mml:mo></mml:math></inline-formula> to <inline-formula id="ieqn-291"><mml:math id="mml-ieqn-291"><mml:mrow><mml:mi>&#x1D4AA;</mml:mi></mml:mrow><mml:mo stretchy="false">(</mml:mo><mml:mn>1</mml:mn><mml:mo stretchy="false">)</mml:mo></mml:math></inline-formula> per update,</p></list-item>
<list-item>
<p>Communication efficient aggregation ensures linear scaling,</p></list-item>
<list-item>
<p>Local decision making avoids global coordination bottlenecks.</p></list-item>
</list></p>
<p>Empirical research using up to <inline-formula id="ieqn-292"><mml:math id="mml-ieqn-292"><mml:mi>N</mml:mi><mml:mo>=</mml:mo><mml:mn>200</mml:mn></mml:math></inline-formula> simulated modules shows that shared learning causes a sublinear rise in the convergence time.</p>
<p>The suggested hybrid adaptive technique offers long-term relative energy efficiency increases across a range of baselines under regulated experimental conditions, rather than making general claims for all IoT installations.</p>
<p>The NVIDIA Jetson TX2 architecture platform, which offers a controlled as well as instrumented environment for examining communication-computation interactions, is used for the experimental study. The TX2 offers:<list list-type="bullet">
<list-item>
<p>Fine grained power measurement capabilities, enabling time resolved energy profiling.</p></list-item>
<list-item>
<p>Sufficient computational resources to support real-time execution of the DQL based controller.</p></list-item>
<list-item>
<p>A unified platform for running heterogeneous protocol stacks (MQTT, BLE, LoRaWAN, CoAP) under identical software conditions.</p></list-item>
</list></p>
<p>As a controlled proxy system, the TX2 measures associated energy changes, trends in protocol behavior, and the effects of dynamic decision making processes in both regulated and repetitive settings. Instead of focusing on absolute power usage numbers, the assessment focuses on comparison based analysis (e.g., before to and post optimization, protocol trade offs).</p>
<p>It is acceptable to interpret the TX2 data as indicating:<list list-type="bullet">
<list-item>
<p>Relative improvements in energy efficiency due to adaptive control,</p></list-item>
<list-item>
<p>Comparative differences between communication protocols under identical workloads,</p></list-item>
<list-item>
<p>System level interactions between computation, communication, and duty cycling.</p></list-item>
</list></p>
<p>This abstraction enables the framework to be tested in a stable as well as observable environment before being deployed on more limited hardware.</p>
<p>The TX2 architecture does not specifically represent extreme low-power IoT solutions, despite its advantages. Specifically:<list list-type="bullet">
<list-item>
<p>The measured power consumption operates in the watt scale (typically <inline-formula id="ieqn-293"><mml:math id="mml-ieqn-293"><mml:mn>3</mml:mn></mml:math></inline-formula>&#x2013;<inline-formula id="ieqn-294"><mml:math id="mml-ieqn-294"><mml:mn>6</mml:mn></mml:math></inline-formula> W), whereas many IoT nodes (e.g., Cortex-M class microcontrollers) operate in the sub-<inline-formula id="ieqn-295"><mml:math id="mml-ieqn-295"><mml:mn>100</mml:mn></mml:math></inline-formula> mW regime.</p></list-item>
<list-item>
<p>Architectural differences (e.g., CPU complexity, memory hierarchy, OS overhead) introduce scaling effects that are not linearly transferable.</p></list-item>
<list-item>
<p>Communication stack implementations on embedded MCUs may have significantly different overhead characteristics compared to a Linux based system.</p></list-item>
</list></p>
<p>The power usage values for the Jetson TX2 architecture are not intended to be directly applied to sub-<inline-formula id="ieqn-296"><mml:math id="mml-ieqn-296"><mml:mn>100</mml:mn></mml:math></inline-formula> microcontroller based IoT devices. Instead, the results are intended to demonstrate relative energy patterns as well as the usefulness of the proposed adaptive management technique in controlled experimental situations.</p>
<p>While absolute energy estimation may vary on limited hardware, the essential optimization strategies of adaptive protocol choice, duty cycling, and workload-aware control remain applicable. Future study will include validation of microcontroller-based systems to establish absolute energy savings in ultra-low-power installations.</p>
<p>We clearly state the fact that the Jetson TX2 architecture was primarily employed as a controlled testing environment for:<list list-type="bullet">
<list-item>
<p>repeatable protocol evaluation,</p></list-item>
<list-item>
<p>fine-grained energy profiling,</p></list-item>
<list-item>
<p>heterogeneous workload emulation,</p></list-item>
<list-item>
<p>and constrained Deep Q-Learning (DQL) experimentation.</p></list-item>
</list></p>
<p>We highlight that ultra low-powered IoT nodes, like the Cortex-M as well as ESP32 class devices, perform under significantly different resource limitations, including:<list list-type="bullet">
<list-item>
<p>significantly lower clock frequencies,</p></list-item>
<list-item>
<p>limited RAM and flash storage,</p></list-item>
<list-item>
<p>restricted parallel computation capability,</p></list-item>
<list-item>
<p>and aggressive duty-cycling requirements.</p></list-item>
</list></p>
<p>As a result, the intended operating behavior on these embedded devices differs significantly in contrast to the Jetson TX2 environment.</p>
<p>The relative protocol selection patterns found on the TX2 platform are predicted to hold true for ultra low-powered IoT nodes, even if absolute power consumption levels vary.</p>
<p>Specifically:<list list-type="bullet">
<list-item>
<p>BLE is expected to remain preferable for short-range low-data-rate communication due to its reduced transmission overhead.</p></list-item>
<list-item>
<p>LoRaWAN is expected to remain advantageous for long-range low-frequency sensing applications because of its superior communication range and low duty-cycle operation.</p></list-item>
<list-item>
<p>MQTT and CoAP are expected to exhibit workload-dependent trade-offs between reliability, latency, and communication overhead.</p></list-item>
</list></p>
<p>Our study focuses on relative adaptive behavior, rather than exact hardware specific wattage levels.</p>
<p>We further highlight that due to restricted computing resources, constrained DQL training is not likely to be performed continuously directly on ultra low-power nodes. Instead, the projected deployment plan comprises the following:<list list-type="bullet">
<list-item>
<p>offline or edge-assisted training,</p></list-item>
<list-item>
<p>lightweight onboard inference,</p></list-item>
<list-item>
<p>compressed policy dissemination,</p></list-item>
<list-item>
<p>and event-triggered policy updates.</p></list-item>
</list></p>
<p>To reduce MCU-level overhead, we discuss:<list list-type="bullet">
<list-item>
<p>quantized neural parameters,</p></list-item>
<list-item>
<p>lightweight policy representations,</p></list-item>
<list-item>
<p>reduced action spaces,</p></list-item>
<list-item>
<p>and TinyML-compatible deployment strategies.</p></list-item>
</list></p>
<p>The computational overhead for embedded inference is approximated as:<disp-formula id="ueqn-72"><mml:math id="mml-ueqn-72" display="block"><mml:msub><mml:mi>C</mml:mi><mml:mrow><mml:mrow><mml:mtext>MCU</mml:mtext></mml:mrow></mml:mrow></mml:msub><mml:mo>=</mml:mo><mml:mi>O</mml:mi><mml:mo stretchy="false">(</mml:mo><mml:mrow><mml:mo stretchy="false">|</mml:mo></mml:mrow><mml:mi>A</mml:mi><mml:mrow><mml:mo stretchy="false">|</mml:mo></mml:mrow><mml:mo>+</mml:mo><mml:msub><mml:mi>d</mml:mi><mml:mi>q</mml:mi></mml:msub><mml:mo stretchy="false">)</mml:mo><mml:mo>,</mml:mo></mml:math></disp-formula>where <inline-formula id="ieqn-297"><mml:math id="mml-ieqn-297"><mml:mrow><mml:mo stretchy="false">|</mml:mo></mml:mrow><mml:mi>A</mml:mi><mml:mrow><mml:mo stretchy="false">|</mml:mo></mml:mrow></mml:math></inline-formula> denotes the action-space size and <inline-formula id="ieqn-298"><mml:math id="mml-ieqn-298"><mml:msub><mml:mi>d</mml:mi><mml:mi>q</mml:mi></mml:msub></mml:math></inline-formula> represents the compressed parameter dimension after quantization.</p>
<p>We further emphasize that energy saving improvements may become much more obvious on battery-powered IoT nodes, as communication energy often dominates overall system consumption in low-powered embedded systems:<disp-formula id="ueqn-73"><mml:math id="mml-ueqn-73" display="block"><mml:msub><mml:mi>E</mml:mi><mml:mrow><mml:mrow><mml:mtext>total</mml:mtext></mml:mrow></mml:mrow></mml:msub><mml:mo>=</mml:mo><mml:msub><mml:mi>E</mml:mi><mml:mrow><mml:mrow><mml:mtext>comm</mml:mtext></mml:mrow></mml:mrow></mml:msub><mml:mo>+</mml:mo><mml:msub><mml:mi>E</mml:mi><mml:mrow><mml:mrow><mml:mtext>comp</mml:mtext></mml:mrow></mml:mrow></mml:msub><mml:mo>+</mml:mo><mml:msub><mml:mi>E</mml:mi><mml:mrow><mml:mrow><mml:mtext>idle</mml:mtext></mml:mrow></mml:mrow></mml:msub><mml:mo>.</mml:mo></mml:math></disp-formula></p>
<p>For wireless transmission phases on MCU class devices, the communication component frequently consumes more energy than the compute component. Thus, dynamic protocol selection as well as duty cycle optimization are projected to give significant practical benefits.</p>
<p>We specifically mention that:<list list-type="bullet">
<list-item>
<p>duty-cycle adaptation is expected to reduce idle-state power consumption,</p></list-item>
<list-item>
<p>adaptive transmission scheduling can minimize unnecessary radio wake-ups,</p></list-item>
<list-item>
<p>and lightweight communication-aware optimization remains feasible even under constrained embedded resources.</p></list-item>
</list></p>
<p>We further highlight that the scalability behavior of ultra-low-power IoT devices is predicted to be more dependent on communication overhead compared to computing complexity. Consequently, the suggested framework includes:<list list-type="bullet">
<list-item>
<p>event-triggered synchronization,</p></list-item>
<list-item>
<p>federated parameter aggregation,</p></list-item>
<list-item>
<p>localized policy execution,</p></list-item>
<list-item>
<p>and reduced communication frequency.</p></list-item>
</list></p>
<p>These strategies are designed to decrease bandwidth and energy consumption in large-scale swarm implementations.</p>
<sec id="s5_1">
<label>5.1</label>
<title>Experimental Validation and Alignment with IoT Hardware</title>
<p>Despite operating at a higher power envelope than extremely low-powered IoT nodes, the NVIDIA Jetson TX2 architecture was specifically selected because it provides:<list list-type="bullet">
<list-item>
<p>fine-grained real-time power measurement capabilities,</p></list-item>
<list-item>
<p>integrated monitoring of CPU, GPU, and memory power consumption,</p></list-item>
<list-item>
<p>sufficient computational resources for controlled constrained DQL experimentation,</p></list-item>
<list-item>
<p>and repeatable execution of heterogeneous protocol stacks under identical operating conditions.</p></list-item>
</list></p>
<p>We make it clear that sub-100 mW microcontroller based IoT products are not meant to be natively emulated by the TX2 platform. Instead, it functions as a controlled proxy environment for analyzing:<list list-type="bullet">
<list-item>
<p>relative communication energy trends,</p></list-item>
<list-item>
<p>adaptive protocol-selection behavior,</p></list-item>
<list-item>
<p>duty-cycle optimization effects,</p></list-item>
<list-item>
<p>and communication&#x2013;computation trade-offs.</p></list-item>
</list></p>
<sec id="s5_1_1">
<label>5.1.1</label>
<title>MCU-Oriented Scaling Interpretation</title>
<p>The suggested adaptive framework is applicable to MCU class IoT equipment such as ARM Cortex M platforms. In particular:<list list-type="bullet">
<list-item>
<p>the constrained DQL controller is lightweight and compatible with reduced model sizes,</p></list-item>
<list-item>
<p>event-triggered updates reduce computational overhead,</p></list-item>
<list-item>
<p>parameter sharing minimizes memory usage,</p></list-item>
<list-item>
<p>and duty-cycle adaptation remains platform-independent.</p></list-item>
</list></p>
<p>The complexity evaluation may be enhanced to show viability for resource limited embedded systems:<disp-formula id="ueqn-74"><mml:math id="mml-ueqn-74" display="block"><mml:msub><mml:mi>C</mml:mi><mml:mrow><mml:mrow><mml:mtext>step</mml:mtext></mml:mrow></mml:mrow></mml:msub><mml:mo>=</mml:mo><mml:mi>O</mml:mi><mml:mo stretchy="false">(</mml:mo><mml:mrow><mml:mo stretchy="false">|</mml:mo></mml:mrow><mml:mi>A</mml:mi><mml:mrow><mml:mo stretchy="false">|</mml:mo></mml:mrow><mml:mo stretchy="false">)</mml:mo><mml:mo>+</mml:mo><mml:mi>O</mml:mi><mml:mo stretchy="false">(</mml:mo><mml:mi>B</mml:mi><mml:mo>&#x22C5;</mml:mo><mml:mi>d</mml:mi><mml:mo stretchy="false">)</mml:mo><mml:mo>,</mml:mo></mml:math></disp-formula>where <inline-formula id="ieqn-299"><mml:math id="mml-ieqn-299"><mml:mrow><mml:mo stretchy="false">|</mml:mo></mml:mrow><mml:mi>A</mml:mi><mml:mrow><mml:mo stretchy="false">|</mml:mo></mml:mrow></mml:math></inline-formula> denotes the action space size, <inline-formula id="ieqn-300"><mml:math id="mml-ieqn-300"><mml:mi>B</mml:mi></mml:math></inline-formula> represents mini-batch size, and <inline-formula id="ieqn-301"><mml:math id="mml-ieqn-301"><mml:mi>d</mml:mi></mml:math></inline-formula> corresponds to the number of trainable parameters.</p>
<p>To further reduce MCU-side overhead, we highlight:<list list-type="bullet">
<list-item>
<p>model pruning,</p></list-item>
<list-item>
<p>quantization,</p></list-item>
<list-item>
<p>federated aggregation,</p></list-item>
<list-item>
<p>and compressed policy sharing.</p></list-item>
</list></p>
<p>These strategies allow for lightweight deployment on restricted IoT devices while maintaining adaptive behavior.</p>
</sec>
<sec id="s5_1_2">
<label>5.1.2</label>
<title>Traffic and Workload</title>
<p>To further simulate practical IoT deployments, our tests include different traffic models:<list list-type="bullet">
<list-item>
<p>periodic sensing traffic,</p></list-item>
<list-item>
<p>bursty communication traffic,</p></list-item>
<list-item>
<p>and stochastic event-driven workloads.</p></list-item>
</list></p>
<p>The dynamic controller dynamically regulates duty cycles as well as protocol selection depending on the observed traffic conditions:<disp-formula id="ueqn-75"><mml:math id="mml-ueqn-75" display="block"><mml:mi>D</mml:mi><mml:mo>=</mml:mo><mml:mfrac><mml:msub><mml:mi>T</mml:mi><mml:mrow><mml:mrow><mml:mtext>active</mml:mtext></mml:mrow></mml:mrow></mml:msub><mml:mrow><mml:msub><mml:mi>T</mml:mi><mml:mrow><mml:mrow><mml:mtext>active</mml:mtext></mml:mrow></mml:mrow></mml:msub><mml:mo>+</mml:mo><mml:msub><mml:mi>T</mml:mi><mml:mrow><mml:mrow><mml:mtext>sleep</mml:mtext></mml:mrow></mml:mrow></mml:msub></mml:mrow></mml:mfrac><mml:mo>,</mml:mo></mml:math></disp-formula>where <inline-formula id="ieqn-302"><mml:math id="mml-ieqn-302"><mml:mi>D</mml:mi></mml:math></inline-formula> denotes the duty cycle ratio.</p>
<p>This enhancement increases the realism of the analysis as well as prevents making assumptions based simply on static workloads.</p>
</sec>
<sec id="s5_1_3">
<label>5.1.3</label>
<title>Experimental Calibration and Comparative Interpretation</title>
<p>We explicitly state that the reported TX2 measurements should be interpreted as:<list list-type="bullet">
<list-item>
<p>relative energy efficiency improvements,</p></list-item>
<list-item>
<p>comparative protocol behavior,</p></list-item>
<list-item>
<p>and adaptive control effectiveness,</p></list-item>
</list></p>
<p>rather than direct estimates of MCU-level absolute power consumption.</p>
<p>To minimize experimental bias, all protocols were evaluated under identical conditions:<list list-type="bullet">
<list-item>
<p>identical payload size,</p></list-item>
<list-item>
<p>identical duty-cycle configuration,</p></list-item>
<list-item>
<p>identical observation intervals,</p></list-item>
<list-item>
<p>and identical workload generation models.</p></list-item>
</list></p>
<p>Additionally, we emphasize that the proposed framework focuses on transferable optimization behavior rather than platform-specific wattage measurements.</p>
</sec>
<sec id="s5_1_4">
<label>5.1.4</label>
<title>Future MCU-Level Validation</title>
<p>We explicitly identify MCU-level deployment validation as future work. Planned extensions include:<list list-type="bullet">
<list-item>
<p>implementation on Cortex-M and ESP32-class devices,</p></list-item>
<list-item>
<p>ultra-low-power protocol profiling,</p></list-item>
<list-item>
<p>TinyML-compatible policy deployment,</p></list-item>
<list-item>
<p>and real-world battery-powered swarm experiments.</p></list-item>
</list></p>
<p><xref ref-type="fig" rid="fig-5">Fig. 5</xref> shows the difference in power use between running an application with the connection on and the idle baseline. At around 2.2&#x2013;2.4 W, the idle power remains quite constant. This indicates that when there is no active processing or communication, the system requires less energy to function.</p>
<fig id="fig-5">
<label>Figure 5</label>
<caption>
<title>Communication overhead while running application.</title>
</caption>
<graphic mimetype="image" mime-subtype="tif" xlink:href="CMC_83797-fig-5.tif"/>
</fig>
<p>When the application and communication stack are operating, the power usage increases a lot. It usually hovers between 5.2 and 5.8 W, although it may reach as high as 6.5 and 7.0 W. These spikes illustrate when communication is more active, as when packets are transmitted, protocols are agreed upon, and retransmissions are made. The number and magnitude of these peaks demonstrate that the major reason runtime energy usage is so high is because it requires more effort to talk to each other.</p>
<p>The application&#x2019;s power profile demonstrates that it does not consistently consume high power. This indicates that energy consumption correlates more strongly with communication events than with ongoing computational tasks. This suggests that static communication scheduling and protocol overhead warrant attention. In contrast, the idle power profile fluctuates less. This implies that devices exhibiting power fluctuations were actively communicating.</p>
<p>These findings emphasize the importance of improving communication protocols for low-power IoT devices. To reduce peak power demand as well as total energy consumption, we can reduce superfluous transmissions, merge data, and adjust communication settings. Within the proposed adaptive communication context, these advancements result in longer device lifetime as well as energy stability.</p>
<p>The findings reveal that IoT as well as swarm robotics implementations require energy-efficient communication methods, since communication overhead can significantly increase power consumption relative to idle operation.</p>
<p>To ensure that the observed energy reductions correspond to plausible IoT as well as swarm workloads, we analyze the system using three appropriate traffic models, namely periodic, bursty, and event driven communication.</p>
<p>Periodic traffic refers to time triggered sensor applications that generate data packets at predetermined intervals:<disp-formula id="eqn-62"><label>(62)</label><mml:math id="mml-eqn-62" display="block"><mml:msub><mml:mi>t</mml:mi><mml:mi>k</mml:mi></mml:msub><mml:mo>=</mml:mo><mml:mi>k</mml:mi><mml:mo>&#x22C5;</mml:mo><mml:msub><mml:mi>T</mml:mi><mml:mi>p</mml:mi></mml:msub><mml:mo>,</mml:mo><mml:mspace width="1em" /><mml:mi>k</mml:mi><mml:mo>=</mml:mo><mml:mn>1</mml:mn><mml:mo>,</mml:mo><mml:mn>2</mml:mn><mml:mo>,</mml:mo><mml:mo>&#x2026;</mml:mo></mml:math></disp-formula>where the sample time is indicated by <inline-formula id="ieqn-303"><mml:math id="mml-ieqn-303"><mml:msub><mml:mi>T</mml:mi><mml:mi>p</mml:mi></mml:msub></mml:math></inline-formula>. Low rate telemetry systems and environmental monitoring share this idea.</p>
<p>With packets coming in clusters, bursty traffic mimics clustered communications. A Poisson burst arrival process is used to illustrate this:<disp-formula id="eqn-63"><label>(63)</label><mml:math id="mml-eqn-63" display="block"><mml:msub><mml:mi>N</mml:mi><mml:mi>b</mml:mi></mml:msub><mml:mo>&#x223C;</mml:mo><mml:mrow><mml:mtext>Poisson</mml:mtext></mml:mrow><mml:mo stretchy="false">(</mml:mo><mml:msub><mml:mi>&#x03BB;</mml:mi><mml:mi>b</mml:mi></mml:msub><mml:mo stretchy="false">)</mml:mo><mml:mo>,</mml:mo></mml:math></disp-formula>where <inline-formula id="ieqn-304"><mml:math id="mml-ieqn-304"><mml:msub><mml:mi>&#x03BB;</mml:mi><mml:mi>b</mml:mi></mml:msub></mml:math></inline-formula> specifies the mean burst magnitude, followed by inactive periods between bursts. This pattern covers scenarios like image/frame uploads and coordinated swarm updates.</p>
<p>Stochastic events, which are defined as follows, provide event-driven traffic:<disp-formula id="eqn-64"><label>(64)</label><mml:math id="mml-eqn-64" display="block"><mml:msub><mml:mi>t</mml:mi><mml:mi>k</mml:mi></mml:msub><mml:mo>&#x223C;</mml:mo><mml:mrow><mml:mtext>Exponential</mml:mtext></mml:mrow><mml:mo stretchy="false">(</mml:mo><mml:msub><mml:mi>&#x03BB;</mml:mi><mml:mi>e</mml:mi></mml:msub><mml:mo stretchy="false">)</mml:mo><mml:mo>,</mml:mo></mml:math></disp-formula>where the event rate is represented by <inline-formula id="ieqn-305"><mml:math id="mml-ieqn-305"><mml:msub><mml:mi>&#x03BB;</mml:mi><mml:mi>e</mml:mi></mml:msub></mml:math></inline-formula>. This model depicts reaction swarm behaviors, alarms, and anomaly detection.</p>
<p>The duty cycle control unit automatically adjusts the active/sleep schedule based on the system state and the measured traffic pattern:<disp-formula id="eqn-65"><label>(65)</label><mml:math id="mml-eqn-65" display="block"><mml:mi>D</mml:mi><mml:mo>=</mml:mo><mml:mfrac><mml:msub><mml:mi>T</mml:mi><mml:mrow><mml:mrow><mml:mtext>active</mml:mtext></mml:mrow></mml:mrow></mml:msub><mml:mrow><mml:msub><mml:mi>T</mml:mi><mml:mrow><mml:mrow><mml:mtext>active</mml:mtext></mml:mrow></mml:mrow></mml:msub><mml:mo>+</mml:mo><mml:msub><mml:mi>T</mml:mi><mml:mrow><mml:mrow><mml:mtext>sleep</mml:mtext></mml:mrow></mml:mrow></mml:msub></mml:mrow></mml:mfrac><mml:mo>.</mml:mo></mml:math></disp-formula></p>
<p>For periodic traffic, the controller synchronizes the active window with packet generation:<list list-type="bullet">
<list-item>
<p><inline-formula id="ieqn-306"><mml:math id="mml-ieqn-306"><mml:msub><mml:mi>T</mml:mi><mml:mrow><mml:mtext>active</mml:mtext></mml:mrow></mml:msub><mml:mo>&#x2248;</mml:mo></mml:math></inline-formula> transmission duration,</p></list-item>
<list-item>
<p><inline-formula id="ieqn-307"><mml:math id="mml-ieqn-307"><mml:msub><mml:mi>T</mml:mi><mml:mrow><mml:mtext>sleep</mml:mtext></mml:mrow></mml:msub><mml:mo>&#x2248;</mml:mo><mml:msub><mml:mi>T</mml:mi><mml:mi>p</mml:mi></mml:msub><mml:mo>&#x2212;</mml:mo><mml:msub><mml:mi>T</mml:mi><mml:mrow><mml:mtext>active</mml:mtext></mml:mrow></mml:msub></mml:math></inline-formula>.</p></list-item>
</list></p>
<p>This results in extremely effective operation with little idle listening, saving a significant amount of energy.</p>
<p>When there is bursty activity, the control unit compresses the duty cycle during idle times and raises it during bursts:<list list-type="bullet">
<list-item>
<p>Increased <inline-formula id="ieqn-308"><mml:math id="mml-ieqn-308"><mml:mi>D</mml:mi></mml:math></inline-formula> during burst intervals to handle high throughput,</p></list-item>
<list-item>
<p>Aggressive reduction of <inline-formula id="ieqn-309"><mml:math id="mml-ieqn-309"><mml:mi>D</mml:mi></mml:math></inline-formula> between bursts to conserve energy.</p></list-item>
</list></p>
<p>This adaptive scaling preserves throughput during spikes while lowering energy loss during quiet periods.</p>
<p>The controller uses a low duty hibernation state with quick waking capabilities for event-driven traffic.
<list list-type="bullet">
<list-item>
<p>Default low <inline-formula id="ieqn-310"><mml:math id="mml-ieqn-310"><mml:mi>D</mml:mi></mml:math></inline-formula> to minimize idle energy consumption,</p></list-item>
<list-item>
<p>Immediate transition to high <inline-formula id="ieqn-311"><mml:math id="mml-ieqn-311"><mml:mi>D</mml:mi></mml:math></inline-formula> upon event detection.</p></list-item>
</list></p>
<p>This maintains responsiveness while minimizing average power usage.</p>
<p>The efficiency of duty cycle modification is greatly dependent on the traffic model:<list list-type="bullet">
<list-item>
<p>Periodic traffic achieves the highest efficiency due to predictable scheduling.</p></list-item>
<list-item>
<p>Bursty traffic benefits from dynamic scaling, reducing idle overhead.</p></list-item>
<list-item>
<p>Event driven traffic yields the lowest average duty cycle but requires fast state transitions.</p></list-item>
</list></p>
<p>The stated savings in energy (up to &#x007E;74%) are regarded as an aggregate impact spanning all traffic conditions, with the greatest advantages found in periodic as well as bursty scenarios. This illustrates that the suggested adaptive architecture is resilient under a variety of workload scenarios and is not restricted to a particular traffic assumption.</p>
<p><xref ref-type="fig" rid="fig-6">Fig. 6</xref> shows how BLE, LoRaWAN, MQTT, and CoAP compare in terms of average power utilization and speed of communication. The findings reveal that each protocol changes energy into data transmission in its own method.</p>
<fig id="fig-6">
<label>Figure 6</label>
<caption>
<title>Power and communication efficiency of protocols.</title>
</caption>
<graphic mimetype="image" mime-subtype="tif" xlink:href="CMC_83797-fig-6.tif"/>
</fig>
<p>LoRaWAN represents the optimal communication protocol due to its low-power consumption (less than 2 W) achieving approximately 50 bits per joule. This makes it well suited for IoT applications requiring low-power, modest data rates, and long-range operation. BLE exhibits a balanced profile with moderate power consumption (about 5 W) and reasonable efficiency (approximately 20 bits/J). It performs well for short-range communication with energy-constrained devices.</p>
<p>They require higher power (approximately 7&#x2013;8 W) but exhibit lower efficiency for message transmission and reception. Operating at approximately 10 bits per joule, MQTT is the least efficient protocol. This is primarily attributable to protocol overhead, including connection maintenance and acknowledgment processing. CoAP outperforms MQTT in certain aspects, while BLE and LoRaWAN are faster. This demonstrates that IP-based communication protocols require further optimization.</p>
<p>These studies reveal that having more power doesn&#x2019;t automatically mean you can communicate better. Protocols for the MAC and physical layers that are light utilize less power than protocols for the application layer that demand greater networking stacks.</p>
<p>The results show how important it is to pick the right protocol when building a system. Use MQTT and CoAP when energy limitations are not as important as interoperability or sophisticated app semantics. Utilize LoRaWAN or BLE on IoT devices that have been adjusted to use less energy whenever energy efficiency is critical. These tradeoffs are used by the suggested adaptive system to control communication speed and power consumption.</p>
<p><xref ref-type="fig" rid="fig-7">Fig. 7</xref> shows how much power a Jetson based IoT node uses to transmit data over MQTT, BLE, and LoRaWAN at different distances, both when there are no obstacles (line of sight) and when there are. All protocols show that power use goes up with distance, which means that transmission power and retransmission overhead go up as the quality of the connection goes down.</p>
<fig id="fig-7">
<label>Figure 7</label>
<caption>
<title>Power analysis at 75 m for transmission.</title>
</caption>
<graphic mimetype="image" mime-subtype="tif" xlink:href="CMC_83797-fig-7.tif"/>
</fig>
<p>In general, BLE and LoRaWAN use less power than MQTT over the entire distance range. BLE is more energy-efficient over short to medium ranges (about 40 m), but LoRaWAN has a more stable power increase and stays efficient over long distances. As the transport layer overhead and the need to keep the connection going all the time, MQTT uses more and more energy, especially when the distance is more than 40 m.</p>
<p>Impeded conditions significantly increase energy consumption across all methods. The effect is most noticeable with MQTT, which reaches its maximum power level at shorter distances than when it is in line of sight mode. When blocked, BLE requires a lot more power, which demonstrates that it is weak to fading and signal loss from many paths. LoRaWAN, on the other hand, is less likely to be blocked and consumes less energy since it has strong modulation and connection flexibility capabilities.</p>
<p>When the distance is more than 50 m, all protocols use almost all of the device&#x2019;s power capacity. This implies that extending the range without adaptive control isn&#x2019;t as useful. This saturation illustrates that static transmission arrangements don&#x2019;t perform properly most of the time.</p>
<p>The data indicate that the cost of communication energy changes a lot depending on the environment. Just picking a protocol isn&#x2019;t enough to attain the optimum energy efficiency. The findings indicate how significant the recommended adaptive communication architecture is. To conserve energy and make the gadget last longer, it modifies the protocols and transmission settings depending on how far away the device is and how good the channel is.</p>
<p><xref ref-type="fig" rid="fig-8">Fig. 8</xref> illustrates how much power the receiver side of the Jetson device requires for MQTT, BLE, and LoRaWAN, regardless of whether the channel is open or closed. The distance affects how much energy is consumed. On the other hand, reception exhibits a more consistent growth in power usage with distance than transmission does. Still, it&#x2019;s extremely evident what occurs when a channel goes bad.</p>
<fig id="fig-8">
<label>Figure 8</label>
<caption>
<title>Power analysis at 75 m for reception.</title>
</caption>
<graphic mimetype="image" mime-subtype="tif" xlink:href="CMC_83797-fig-8.tif"/>
</fig>
<p>BLE utilizes the least amount of power to pick up signals from all distances since its protocol is simple and its radio duty cycle is efficient. LoRaWAN operates in a similar fashion, but it requires more power since it takes longer to get signals and there is more work to perform to keep everything in sync. When the distance is more than 40 m, MQTT needs the greatest power to transmit. This is because it needs to maintain the TCP/IP stack and handle sessions via a broker.</p>
<p>Conditions that are blocked make reception better in all modes. MQTT is very influenced, and the amount of power it uses goes up in a straight line with distance, peaking at 75 m. This sort of behavior is generally associated with more lost packets, retransmissions, and longer waiting times. When blocked, BLE consumes more power, although the difference is extremely tiny across short and medium distances. LoRaWAN is more reliable, allowing it to lose-less whenever things go wrong. This shows that it works effectively in locations wherever signals do not travel easily.</p>
<p>Whenever the distance traveled is sixty meters or greater, the transmitting and receiving strength of MQTT as well as LoRaWAN are equal. This means that the reception windows are extended, and synchronization occurs more frequently. This convergence demonstrates the quantity of energy it requires to receive while SNR is relatively low, which static energy models sometimes disregard.</p>
<p>These data suggest that the amount of additional energy required to receive varies according to technique and context. This has a huge influence on the duration that nodes can live in IoT settings with low-power. The results confirm the proposed adaptive communication architecture, which saves energy by changing the reception windows, protocol selection, and listening intervals in response to changes in channel circumstances.</p>
<p><xref ref-type="fig" rid="fig-9">Fig. 9</xref> demonstrates how BLE, MQTT, and LoRaWAN&#x2019;s transmission power, communication distance, and data rate are all connected. When the distance becomes longer, all protocols require more power and transfer data more slowly. This implies that wireless signals can&#x2019;t go as far as they might and connections can&#x2019;t be as flexible as they could be.</p>
<fig id="fig-9">
<label>Figure 9</label>
<caption>
<title>Power analysis.</title>
</caption>
<graphic mimetype="image" mime-subtype="tif" xlink:href="CMC_83797-fig-9.tif"/>
</fig>
<p>BLE achieves high data rates for short-range communication, but exhibits high power consumption beyond short-ranges, making it unsuitable for long-range or ultra-low-power applications. MQTT functions adequately, though data rate gradually decreases and power consumption fluctuates. This is primarily attributable to its mobility and radio configuration. LoRaWAN maintains low-power consumption over long-ranges, but achieves lower data rates compared to short-range, high-speed alternatives.</p>
<p>The findings reveal that there isn&#x2019;t one ideal technique to conserve energy in every situation. Protocols with high data speeds need greater power as distance increases. Protocols with low-power and long-range, on the other hand, sacrifice throughput in order to save energy. This emphasizes the relevance of low-power IoT devices&#x2019; ability to change how they interact with one another.</p>
<p>The findings provide confidence to the proposed adaptive architecture for energy-efficient IoT and swarm robots. By continually modifying protocols and transmission settings in accordance with distance as well as availability of energy, the system can conserve energy while maintaining high quality communication. Static installations, on the other hand, don&#x2019;t make these trade offs, which wastes energy.</p>
<p><xref ref-type="fig" rid="fig-10">Fig. 10</xref> demonstrates how the time it takes for BLE, MQTT, and LoRaWAN to communicate, the distance it can travel, and the speed at which data can be transferred are all connected. As the distance increases, the latency of all protocols increases, while the practical data rate decreases. This implies that it will take longer to transport data over long distances, there will be more retransmissions, and link layer designers will have to be more cautious.</p>
<fig id="fig-10">
<label>Figure 10</label>
<caption>
<title>Latency analysis.</title>
</caption>
<graphic mimetype="image" mime-subtype="tif" xlink:href="CMC_83797-fig-10.tif"/>
</fig>
<p>BLE has the least latency over short distances since it transfers data rapidly and doesn&#x2019;t leave much time between connections. The latency does become greater as the distance grows, thus it can only be used for talking to those who are close by. When you add distance, MQTT&#x2019;s latency goes up a tiny bit since the transport layer and the acknowledgment mechanisms have to work harder. Due to this, its performance profile is even, however it varies according to distance.</p>
<p>Compared to BLE and MQTT, LoRaWAN is slower, especially over long distances. This is mostly due to the limited frequency of usage, long airtime, and sluggish data rates of LPWAN technology. LoRaWAN may connect distant devices, but its high latency renders it inappropriate for applications that require fast replies.</p>
<p>The findings indicate that the trade off between latency, speed, as well as range is significant. High throughput protocols usually accelerate data transmission over short distances. In contrast, operations that operate across long distances are relatively slow. These findings underscore the need of communication systems that can change their protocols and broadcast parameters based on the distance to travel as well as the amount of latency an application may tolerate.</p>
<p>Systems for IoT and swarm robots that consume less energy need to be able to switch their decision. Static setups can&#x2019;t perform what delay aware protocol switching can achieve. It helps the system fulfill deadlines without consuming additional power or slowing down.</p>
<p>Every study is carried out in a well regulated as well as standardized benchmarking environment to offer an impartial and repeatable assessment of communication methods.</p>
<p>All of the protocols under study (MQTT, BLE, LoRaWAN, as well as CoAP) share the following parameters:<list list-type="bullet">
<list-item>
<p>Payload Size: All protocols transmit identical payloads of fixed size <inline-formula id="ieqn-312"><mml:math id="mml-ieqn-312"><mml:msub><mml:mi>S</mml:mi><mml:mrow><mml:mtext>payload</mml:mtext></mml:mrow></mml:msub></mml:math></inline-formula> (in bits) per packet.</p></list-item>
<list-item>
<p>Application Workload: The same application-layer workload is applied, characterized by identical packet generation rates and traffic patterns.</p></list-item>
<list-item>
<p>Duty Cycle: A consistent duty cycle configuration is maintained across protocols, defined as:<disp-formula id="eqn-66"><label>(66)</label><mml:math id="mml-eqn-66" display="block"><mml:mi>D</mml:mi><mml:mo>=</mml:mo><mml:mfrac><mml:msub><mml:mi>T</mml:mi><mml:mrow><mml:mrow><mml:mtext>active</mml:mtext></mml:mrow></mml:mrow></mml:msub><mml:mrow><mml:msub><mml:mi>T</mml:mi><mml:mrow><mml:mrow><mml:mtext>active</mml:mtext></mml:mrow></mml:mrow></mml:msub><mml:mo>+</mml:mo><mml:msub><mml:mi>T</mml:mi><mml:mrow><mml:mrow><mml:mtext>sleep</mml:mtext></mml:mrow></mml:mrow></mml:msub></mml:mrow></mml:mfrac><mml:mo>,</mml:mo></mml:math></disp-formula>where <inline-formula id="ieqn-313"><mml:math id="mml-ieqn-313"><mml:msub><mml:mi>T</mml:mi><mml:mrow><mml:mtext>active</mml:mtext></mml:mrow></mml:msub></mml:math></inline-formula> and <inline-formula id="ieqn-314"><mml:math id="mml-ieqn-314"><mml:msub><mml:mi>T</mml:mi><mml:mrow><mml:mtext>sleep</mml:mtext></mml:mrow></mml:msub></mml:math></inline-formula> are fixed for all protocols during benchmarking.</p></list-item>
<list-item>
<p>Observation Window: All measurements are collected over an identical time horizon <inline-formula id="ieqn-315"><mml:math id="mml-ieqn-315"><mml:msub><mml:mi>T</mml:mi><mml:mrow><mml:mtext>obs</mml:mtext></mml:mrow></mml:msub></mml:math></inline-formula> to ensure temporal consistency.</p></list-item>
</list></p>
<p>Energy efficiency is computed using a unified definition across all protocols:<disp-formula id="eqn-67"><label>(67)</label><mml:math id="mml-eqn-67" display="block"><mml:mi>&#x03B7;</mml:mi><mml:mo>=</mml:mo><mml:mfrac><mml:mrow><mml:msub><mml:mi>N</mml:mi><mml:mrow><mml:mrow><mml:mtext>delivered</mml:mtext></mml:mrow></mml:mrow></mml:msub><mml:mo>&#x22C5;</mml:mo><mml:msub><mml:mi>S</mml:mi><mml:mrow><mml:mrow><mml:mtext>payload</mml:mtext></mml:mrow></mml:mrow></mml:msub></mml:mrow><mml:msub><mml:mi>E</mml:mi><mml:mrow><mml:mrow><mml:mtext>comm</mml:mtext></mml:mrow></mml:mrow></mml:msub></mml:mfrac><mml:mo>,</mml:mo></mml:math></disp-formula>where:<list list-type="bullet">
<list-item>
<p><inline-formula id="ieqn-316"><mml:math id="mml-ieqn-316"><mml:msub><mml:mi>N</mml:mi><mml:mrow><mml:mtext>delivered</mml:mtext></mml:mrow></mml:msub></mml:math></inline-formula> is the number of successfully received packets,</p></list-item>
<list-item>
<p><inline-formula id="ieqn-317"><mml:math id="mml-ieqn-317"><mml:msub><mml:mi>S</mml:mi><mml:mrow><mml:mtext>payload</mml:mtext></mml:mrow></mml:msub></mml:math></inline-formula> is the payload size in bits,</p></list-item>
<list-item>
<p><inline-formula id="ieqn-318"><mml:math id="mml-ieqn-318"><mml:msub><mml:mi>E</mml:mi><mml:mrow><mml:mtext>comm</mml:mtext></mml:mrow></mml:msub></mml:math></inline-formula> is the total communication energy consumed (in Joules) over the observation window <inline-formula id="ieqn-319"><mml:math id="mml-ieqn-319"><mml:msub><mml:mi>T</mml:mi><mml:mrow><mml:mtext>obs</mml:mtext></mml:mrow></mml:msub></mml:math></inline-formula>.</p></list-item>
</list></p>
<p>Thus, <inline-formula id="ieqn-320"><mml:math id="mml-ieqn-320"><mml:mi>&#x03B7;</mml:mi></mml:math></inline-formula> represents the number of useful payload bits delivered per unit energy (bits/Joule).</p>
<p>The communication energy is measured as:<disp-formula id="eqn-68"><label>(68)</label><mml:math id="mml-eqn-68" display="block"><mml:msub><mml:mi>E</mml:mi><mml:mrow><mml:mrow><mml:mtext>comm</mml:mtext></mml:mrow></mml:mrow></mml:msub><mml:mo>=</mml:mo><mml:msubsup><mml:mo>&#x222B;</mml:mo><mml:mrow><mml:mn>0</mml:mn></mml:mrow><mml:mrow><mml:msub><mml:mi>T</mml:mi><mml:mrow><mml:mrow><mml:mtext>obs</mml:mtext></mml:mrow></mml:mrow></mml:msub></mml:mrow></mml:msubsup><mml:msub><mml:mi>P</mml:mi><mml:mrow><mml:mrow><mml:mtext>comm</mml:mtext></mml:mrow></mml:mrow></mml:msub><mml:mo stretchy="false">(</mml:mo><mml:mi>t</mml:mi><mml:mo stretchy="false">)</mml:mo><mml:mspace width="thinmathspace" /><mml:mi>d</mml:mi><mml:mi>t</mml:mi><mml:mo>,</mml:mo></mml:math></disp-formula>where <inline-formula id="ieqn-321"><mml:math id="mml-ieqn-321"><mml:msub><mml:mi>P</mml:mi><mml:mrow><mml:mtext>comm</mml:mtext></mml:mrow></mml:msub><mml:mo stretchy="false">(</mml:mo><mml:mi>t</mml:mi><mml:mo stretchy="false">)</mml:mo></mml:math></inline-formula> is the instantaneous power consumption attributable solely to communication activities (transmission, reception, and protocol overhead). Non communication components such as idle CPU and background processes are excluded to ensure protocol level fairness.</p>
<p>To address differences in protocol stack implementations:<list list-type="bullet">
<list-item>
<p>Application layer overhead (e.g., MQTT over TCP/IP) is included only when evaluating end-to-end system performance.</p></list-item>
<list-item>
<p>For protocol level comparison, PHY/MAC layer energy consumption is isolated where applicable.</p></list-item>
<list-item>
<p>All protocols are evaluated under identical network conditions, including channel characteristics and node placement.</p></list-item>
</list></p>
<p>This standardized assessment protocol ensures that differences in measured results are only attributable to protocol features as well as adaptive control methods, rather than inconsistencies in workload, payload, or measurement technique. The implementation of a common bits/Joule measure allows for direct and relevant comparisons of energy efficiency spanning different communication systems.</p>
<p><xref ref-type="fig" rid="fig-11">Fig. 11</xref> shows a proposed adaptive methodology that governs protocol selection, compute offloading, as well as execution to preserve energy. The experimental results indisputably support the value of this rigorous decision making technique.</p>
<fig id="fig-11">
<label>Figure 11</label>
<caption>
<title>Proposed methodology.</title>
</caption>
<graphic mimetype="image" mime-subtype="tif" xlink:href="CMC_83797-fig-11.tif"/>
</fig>
<p>The startup and condition setup procedures define the essential device conditions, resource constraints, and priority levels. This allows many protocols to function in a consistent manner. Before communicating, the framework does a prioritization analysis to verify that only relevant energy transmissions are planned. This is supported by the reported decreases in transmission overhead costs and average energy usage across protocols.</p>
<p>To obtain the observed efficiency gains, the fundamental protocol selection technique must be restricted by a power limitation. When there is enough energy, the system can function autonomously. The computation is moved to a different location or the communication settings are changed if there is insufficient energy. The experimental graphs show substantial energy savings and slower energy scaling due to this selective propensity, particularly if there are obstructs and long distances.</p>
<p>Together, implementation, resource evaluation, and refinement make it easier to handle modifications to the program&#x2019;s operation. Since the system is still being assessed, it cannot stay in exceptionally energetic states for very long. As a consequence, the results show that battery life is becoming longer and that communication energy consumption is continuously falling. The idea that efficient refining lowers link variability and channel challenges is supported by the fact that efficiency doesn&#x2019;t significantly deteriorate across long distances.</p>
<p>The results show that rather of operating as a static optimization, the suggested approach functions as a control framework that adapts over time and accounts for energy use. Making modifications after the execution, selecting the appropriate protocol, and determining whether to offload are all quite comparable. As a result, the nodes live longer, communicate more quickly, and use less power overall. This demonstrates that the suggested architecture is appropriate for long term IoT and swarm robotic systems that use little energy and operate under shifting network and ambient circumstances.</p>
<p><xref ref-type="fig" rid="fig-11">Figs. 11</xref> and <xref ref-type="fig" rid="fig-12">12</xref> demonstrate how the suggested adaptive communication architecture would effect the entire system as its entirety, including average power consumption, distribution of energy across component activities, and battery life. The improvement dramatically decreases communication energy usage across all tested operations and is directly related to quantifiable increases in lifetime.</p>
<fig id="fig-12">
<label>Figure 12</label>
<caption>
<title>Average power consumption by activity.</title>
</caption>
<graphic mimetype="image" mime-subtype="tif" xlink:href="CMC_83797-fig-12.tif"/>
</fig>
<p>The first subplot indicates a significant decline in average power utilization after optimization, saving roughly 25% for BLE, 33% for LoRaWAN, 30% for MQTT, and 32% for CoAP. These cuts show that protocol aware adaptation through dynamic duty cycling, changing the data rate, and selective transmission scheduling can cut down on unnecessary radio activity while keeping the connection.</p>
<p>The second subplot shows that the battery life has improved. Each methodology has a different basic efficiency, but they all make a single charge last four to six hours longer. The finest one makes a node last 16 to 18 h longer. Optimization helps LoRaWAN in many ways. This illustrates how easy it is to modify the time between broadcasts and set the time frames for reception. Protocols that are really basic, like BLE, have gone a long way. This is crucial because it demonstrates that adaptive control works even when the power is extremely low.</p>
<p>The first subplot in <xref ref-type="fig" rid="fig-13">Fig. 13</xref> indicates how much energy each activity consumes on average. Communication uses the greatest energy before optimization. The new system will use around 30% less energy to talk to other nodes, but it will still require roughly the same amount of energy while it&#x2019;s not being utilized or when it&#x2019;s performing arithmetic. This illustrates that the optimization only looks at the major energy constraint.</p>
<fig id="fig-13">
<label>Figure 13</label>
<caption>
<title>Power consumption.</title>
</caption>
<graphic mimetype="image" mime-subtype="tif" xlink:href="CMC_83797-fig-13.tif"/>
</fig>
<p>The second subplot in <xref ref-type="fig" rid="fig-13">Fig. 13</xref> shows that the battery lasts longer as time goes on. The battery lasts roughly four hours longer once it has been optimized. This result illustrates that the energy savings from each activity may endure for a long period. It also backs up the premise that IoT systems that know how much energy they consume or conserve energy are conceivable.</p>
<p>The results demonstrate that the proposed adaptive framework reduces energy consumption, operates protocol-agnostically, helps batteries last longer, and consistently mitigates communication-related power waste. The approach is viable for energy-constrained IoT and swarm robotic systems as the optimizations apply uniformly across protocols.</p>
<p><xref ref-type="fig" rid="fig-14">Fig. 14</xref> demonstrates how adaptive processing, duty-cycle management, and protocol aware communication all work together to help the system consume less power and survive longer on battery power.</p>
<fig id="fig-14">
<label>Figure 14</label>
<caption>
<title>Summary of results.</title>
</caption>
<graphic mimetype="image" mime-subtype="tif" xlink:href="CMC_83797-fig-14.tif"/>
</fig>
<p>The arrangement of the CPU shows that the number of cores and the operating frequency have a big effect on how much energy is utilized. Using a single core with a reasonable clock frequency of 1.47 GHz lowers power utilization between 6.4 to 4.15 W. However, with flexible scaling in a multi core design, it decreases even more, to 3.24 W. This illustrates that when dealing with IoT devices that must conserve energy, a smart CPU arrangement is more critical than a large processing capability.</p>
<p>The most efficient way to conserve energy is to change the duty cycle. Decreasing this duty cycle from constant to 10%&#x2013;20% can lower average power consumption by up to 74%, making it acceptable for most IoT applications. This shows that activity-based scheduling might assist accomplish functional objectives while reducing costs for outage and communication.</p>
<p>The research of transmission energy shows that the length of a discussion and the quantity of power used are related. LoRaWAN can carry data over greater distances than BLE, although BLE consumes less power over shorter distances (less than 30&#x2013;40 m). But sending data outside of this range uses more energy. During this transition period, the adaptive framework chooses the protocol that transfers the least amount of energy per bit, taking into account distance and channel constraints.</p>
<p>The batteries endure a long time, which shows how effectively adaptive control approaches operate. With adaptive control, the duration it can run rises increased from 14 to 18 h, which is a 25% increase. This illustrates that changing the processor, duty cycle, and communication levels all at once is highly advantageous for the system.</p>
<p>The findings reveal that the proposed adaptive framework works effectively in real-time to control duty cycles, communication strategies, and computational effort. This lets IoT and swarm robotic installations operate all the time and consume less power.</p>
<p>The reported <inline-formula id="ieqn-322"><mml:math id="mml-ieqn-322"><mml:mn>25</mml:mn><mml:mi mathvariant="normal">&#x0025;</mml:mi></mml:math></inline-formula> improvement in battery lifetime is explicitly bounded with respect to the chosen baseline.</p>
<p>The improvement is computed relative to a fixed power transmission baseline, in which the node operates with static transmit power, fixed duty cycling, and no adaptive optimization. Let <inline-formula id="ieqn-323"><mml:math id="mml-ieqn-323"><mml:msub><mml:mi>T</mml:mi><mml:mrow><mml:mtext>fixed</mml:mtext></mml:mrow></mml:msub></mml:math></inline-formula> and <inline-formula id="ieqn-324"><mml:math id="mml-ieqn-324"><mml:msub><mml:mi>T</mml:mi><mml:mrow><mml:mtext>adaptive</mml:mtext></mml:mrow></mml:msub></mml:math></inline-formula> denote the battery lifetime under the fixed baseline and the proposed adaptive framework, respectively. The relative improvement is defined as:<disp-formula id="eqn-69"><label>(69)</label><mml:math id="mml-eqn-69" display="block"><mml:mi mathvariant="normal">&#x0394;</mml:mi><mml:mi>T</mml:mi><mml:mo stretchy="false">(</mml:mo><mml:mi mathvariant="normal">&#x0025;</mml:mi><mml:mo stretchy="false">)</mml:mo><mml:mo>=</mml:mo><mml:mfrac><mml:mrow><mml:msub><mml:mi>T</mml:mi><mml:mrow><mml:mrow><mml:mtext>adaptive</mml:mtext></mml:mrow></mml:mrow></mml:msub><mml:mo>&#x2212;</mml:mo><mml:msub><mml:mi>T</mml:mi><mml:mrow><mml:mrow><mml:mtext>fixed</mml:mtext></mml:mrow></mml:mrow></mml:msub></mml:mrow><mml:msub><mml:mi>T</mml:mi><mml:mrow><mml:mrow><mml:mtext>fixed</mml:mtext></mml:mrow></mml:mrow></mml:msub></mml:mfrac><mml:mo>&#x00D7;</mml:mo><mml:mn>100.</mml:mn></mml:math></disp-formula></p>
<p>In our experimental setup, we observe:<disp-formula id="eqn-70"><label>(70)</label><mml:math id="mml-eqn-70" display="block"><mml:mi mathvariant="normal">&#x0394;</mml:mi><mml:mi>T</mml:mi><mml:mo>&#x2248;</mml:mo><mml:mn>25</mml:mn><mml:mi mathvariant="normal">&#x0025;</mml:mi><mml:mo>,</mml:mo></mml:math></disp-formula>stating that a non adaptive, rigid architecture has a shorter working lifetime than a dynamic control framework.</p>
<p>It is important to remember that:<list list-type="bullet">
<list-item>
<p>This improvement is not a universal gain across all possible baselines, but specifically reflects comparison against a fixed power strategy.</p></list-item>
<list-item>
<p>When compared to more advanced baselines (e.g., rule based or partially adaptive schemes), the relative improvement is reduced but remains positive.</p></list-item>
<list-item>
<p>The reported gain depends on workload characteristics, channel conditions, and system parameters such as duty cycle and traffic patterns.</p></list-item>
</list></p>
<p>The suggested adaptive communication system improves battery lifespan by up to <inline-formula id="ieqn-325"><mml:math id="mml-ieqn-325"><mml:mn>25</mml:mn><mml:mi mathvariant="normal">&#x0025;</mml:mi></mml:math></inline-formula> compared to a static power baseline under reviewed experimental settings.</p>
<p>To give a more plausible perspective on battery life cycle, we explicitly describe the battery model characteristics as well as substitute the implicit linear lifespan assumption with a nonlinear discharge formulation.</p>
<p>The studies presume a chargeable Li-ion battery with the following characteristics:<list list-type="bullet">
<list-item>
<p>Nominal Capacity: <inline-formula id="ieqn-326"><mml:math id="mml-ieqn-326"><mml:msub><mml:mi>C</mml:mi><mml:mrow><mml:mtext>bat</mml:mtext></mml:mrow></mml:msub><mml:mo>=</mml:mo><mml:mn>5000</mml:mn><mml:mtext>&#xA0;mAh</mml:mtext></mml:math></inline-formula></p></list-item>
<list-item>
<p>Nominal Voltage: <inline-formula id="ieqn-327"><mml:math id="mml-ieqn-327"><mml:msub><mml:mi>V</mml:mi><mml:mrow><mml:mtext>nom</mml:mtext></mml:mrow></mml:msub><mml:mo>=</mml:mo><mml:mn>3.7</mml:mn><mml:mtext>&#xA0;V</mml:mtext></mml:math></inline-formula></p></list-item>
<list-item>
<p>Maximum Voltage: <inline-formula id="ieqn-328"><mml:math id="mml-ieqn-328"><mml:msub><mml:mi>V</mml:mi><mml:mrow><mml:mtext>max</mml:mtext></mml:mrow></mml:msub><mml:mo>=</mml:mo><mml:mn>4.2</mml:mn><mml:mtext>&#xA0;V</mml:mtext></mml:math></inline-formula></p></list-item>
<list-item>
<p>Cutoff Voltage: <inline-formula id="ieqn-329"><mml:math id="mml-ieqn-329"><mml:msub><mml:mi>V</mml:mi><mml:mrow><mml:mtext>cut</mml:mtext></mml:mrow></mml:msub><mml:mo>=</mml:mo><mml:mn>3.0</mml:mn><mml:mtext>&#xA0;V</mml:mtext></mml:math></inline-formula></p></list-item>
</list></p>
<p>The total nominal energy is approximated as:<disp-formula id="eqn-71"><label>(71)</label><mml:math id="mml-eqn-71" display="block"><mml:msub><mml:mi>E</mml:mi><mml:mrow><mml:mrow><mml:mtext>bat</mml:mtext></mml:mrow></mml:mrow></mml:msub><mml:mo>=</mml:mo><mml:msub><mml:mi>C</mml:mi><mml:mrow><mml:mrow><mml:mtext>bat</mml:mtext></mml:mrow></mml:mrow></mml:msub><mml:mo>&#x22C5;</mml:mo><mml:msub><mml:mi>V</mml:mi><mml:mrow><mml:mrow><mml:mtext>nom</mml:mtext></mml:mrow></mml:mrow></mml:msub><mml:mo>=</mml:mo><mml:mn>18.5</mml:mn><mml:mtext>&#xA0;</mml:mtext><mml:mrow><mml:mtext>Wh</mml:mtext></mml:mrow><mml:mo>.</mml:mo></mml:math></disp-formula></p>
<p>Instead of assuming linear discharge, we adopt a non linear voltage state of charge (SoC) relationship typical of Li-ion batteries. The discharge behavior can be approximated as:<disp-formula id="eqn-72"><label>(72)</label><mml:math id="mml-eqn-72" display="block"><mml:msub><mml:mi>V</mml:mi><mml:mrow><mml:mrow><mml:mtext>bat</mml:mtext></mml:mrow></mml:mrow></mml:msub><mml:mo stretchy="false">(</mml:mo><mml:mrow><mml:mtext>SoC</mml:mtext></mml:mrow><mml:mo stretchy="false">)</mml:mo><mml:mo>=</mml:mo><mml:msub><mml:mi>V</mml:mi><mml:mrow><mml:mrow><mml:mtext>nom</mml:mtext></mml:mrow></mml:mrow></mml:msub><mml:mo>&#x2212;</mml:mo><mml:msub><mml:mi>k</mml:mi><mml:mn>1</mml:mn></mml:msub><mml:mo stretchy="false">(</mml:mo><mml:mn>1</mml:mn><mml:mo>&#x2212;</mml:mo><mml:mrow><mml:mtext>SoC</mml:mtext></mml:mrow><mml:mo stretchy="false">)</mml:mo><mml:mo>&#x2212;</mml:mo><mml:msub><mml:mi>k</mml:mi><mml:mn>2</mml:mn></mml:msub><mml:mo stretchy="false">(</mml:mo><mml:mn>1</mml:mn><mml:mo>&#x2212;</mml:mo><mml:mrow><mml:mtext>SoC</mml:mtext></mml:mrow><mml:msup><mml:mo stretchy="false">)</mml:mo><mml:mn>2</mml:mn></mml:msup><mml:mo>,</mml:mo></mml:math></disp-formula>where <inline-formula id="ieqn-330"><mml:math id="mml-ieqn-330"><mml:mtext>SoC</mml:mtext><mml:mo>&#x2208;</mml:mo><mml:mo stretchy="false">[</mml:mo><mml:mn>0</mml:mn><mml:mo>,</mml:mo><mml:mn>1</mml:mn><mml:mo stretchy="false">]</mml:mo></mml:math></inline-formula> and <inline-formula id="ieqn-331"><mml:math id="mml-ieqn-331"><mml:msub><mml:mi>k</mml:mi><mml:mn>1</mml:mn></mml:msub><mml:mo>,</mml:mo><mml:msub><mml:mi>k</mml:mi><mml:mn>2</mml:mn></mml:msub></mml:math></inline-formula> are empirical constants capturing the voltage drop profile.</p>
<p>The instantaneous available energy is then:<disp-formula id="eqn-73"><label>(73)</label><mml:math id="mml-eqn-73" display="block"><mml:mi>E</mml:mi><mml:mo stretchy="false">(</mml:mo><mml:mi>t</mml:mi><mml:mo stretchy="false">)</mml:mo><mml:mo>=</mml:mo><mml:msubsup><mml:mo>&#x222B;</mml:mo><mml:mrow><mml:msub><mml:mi>t</mml:mi><mml:mn>0</mml:mn></mml:msub></mml:mrow><mml:mrow><mml:mi>t</mml:mi></mml:mrow></mml:msubsup><mml:msub><mml:mi>V</mml:mi><mml:mrow><mml:mrow><mml:mtext>bat</mml:mtext></mml:mrow></mml:mrow></mml:msub><mml:mo stretchy="false">(</mml:mo><mml:mrow><mml:mtext>SoC</mml:mtext></mml:mrow><mml:mo stretchy="false">(</mml:mo><mml:mi>t</mml:mi><mml:mo stretchy="false">)</mml:mo><mml:mo stretchy="false">)</mml:mo><mml:mo>&#x22C5;</mml:mo><mml:mi>I</mml:mi><mml:mo stretchy="false">(</mml:mo><mml:mi>t</mml:mi><mml:mo stretchy="false">)</mml:mo><mml:mspace width="thinmathspace" /><mml:mi>d</mml:mi><mml:mi>t</mml:mi><mml:mo>,</mml:mo></mml:math></disp-formula>where <inline-formula id="ieqn-332"><mml:math id="mml-ieqn-332"><mml:mi>I</mml:mi><mml:mo stretchy="false">(</mml:mo><mml:mi>t</mml:mi><mml:mo stretchy="false">)</mml:mo></mml:math></inline-formula> is the current draw.</p>
<p>Battery lifetime is determined by the time at which:<disp-formula id="eqn-74"><label>(74)</label><mml:math id="mml-eqn-74" display="block"><mml:msub><mml:mi>V</mml:mi><mml:mrow><mml:mrow><mml:mtext>bat</mml:mtext></mml:mrow></mml:mrow></mml:msub><mml:mo stretchy="false">(</mml:mo><mml:mrow><mml:mtext>SoC</mml:mtext></mml:mrow><mml:mo stretchy="false">)</mml:mo><mml:mo>&#x2264;</mml:mo><mml:msub><mml:mi>V</mml:mi><mml:mrow><mml:mrow><mml:mtext>cut</mml:mtext></mml:mrow></mml:mrow></mml:msub><mml:mo>.</mml:mo></mml:math></disp-formula></p>
<p>The optimal usable energy varies with discharge rate as well as load circumstances, in opposition to the linear models. Because of the effects of internal resistance, high current demand induces voltage to decrease more quickly, reducing useable capacity.</p>
<p>This nonlinear model has been used to modify the stated lifetime gains:<list list-type="bullet">
<list-item>
<p>Energy savings from adaptive control delay the onset of rapid voltage decline near low SoC.</p></list-item>
<list-item>
<p>Reduced peak power consumption lowers instantaneous current draw, mitigating voltage sag.</p></list-item>
<list-item>
<p>Lifetime extension is therefore not strictly proportional to average power reduction.</p></list-item>
</list></p>
<p>Battery lifetime improvements are evaluated using a non linear discharge model, where adaptive energy savings extend the usable operating region by delaying the approach to the cutoff voltage, rather than assuming a linear scaling between power reduction and lifetime.</p>
<p>This formulation provides a more realistic explanation of battery management in IoT devices. It underlines that adaptive communication systems reduce mean energy consumption while increasing effective energy use in non linear discharge circumstances.</p>
</sec>
</sec>
<sec id="s5_2">
<label>5.2</label>
<title>Discussion on Embedded Deployment Constraints and MCU-Level Resource Feasibility</title>
<p>Although the major experimental assessment was carried out on the NVIDIA Jetson TX2 architecture for regulated power profiling as well as heterogeneous protocol testing, we specifically address deployment feasibility for resource constrained embedded devices.</p>
<p>The suggested optimization framework was created with lightweight execution restrictions in mind, using:<list list-type="bullet">
<list-item>
<p>reduced action-space dimensionality,</p></list-item>
<list-item>
<p>event-triggered policy updates,</p></list-item>
<list-item>
<p>lightweight constrained DQL inference,</p></list-item>
<list-item>
<p>parameter sharing,</p></list-item>
<list-item>
<p>and duty-cycle-aware scheduling.</p></list-item>
</list></p>
<p>To improve practical relevance, we present a comparative resource analysis between the proposed framework and representative embedded IoT hardware platforms, as summarized in <xref ref-type="table" rid="table-4">Table 4</xref>.</p>
<table-wrap id="table-4">
<label>Table 4</label>
<caption>
<title>Comparison of embedded resource constraints and proposed framework requirements.</title>
</caption>
<table>
<colgroup>
<col align="center"/>
<col align="center"/>
<col align="center"/>
<col align="center"/>
<col align="center"/> </colgroup>
<thead>
<tr>
<th>Platform</th>
<th>RAM</th>
<th>Flash</th>
<th>CPU Freq.</th>
<th>Deployment Feasibility</th>
</tr>
</thead>
<tbody>
<tr>
<td>ARM Cortex-M4</td>
<td>256 KB</td>
<td>1 MB</td>
<td>80&#x2013;120 MHz</td>
<td>Feasible with quantized model</td>
</tr>
<tr>
<td>ESP32</td>
<td>520 KB</td>
<td>4 MB</td>
<td>160&#x2013;240 MHz</td>
<td>Fully feasible</td>
</tr>
<tr>
<td>STM32L4</td>
<td>128&#x2013;320 KB</td>
<td>512 KB&#x2013;1 MB</td>
<td>80 MHz</td>
<td>Feasible with lightweight policy</td>
</tr>
<tr>
<td>Raspberry Pi Pico W</td>
<td>264 KB</td>
<td>2 MB</td>
<td>133 MHz</td>
<td>Feasible for inference-only deployment</td>
</tr>
<tr>
<td>Jetson TX2 (Experimental Platform)</td>
<td>8 GB</td>
<td>32 GB</td>
<td>2 GHz</td>
<td>Supports full training and profiling</td>
</tr>
<tr>
<td>Proposed Lightweight DQL Controller</td>
<td><inline-formula id="ieqn-333"><mml:math id="mml-ieqn-333"><mml:mo>&#x2248;</mml:mo></mml:math></inline-formula>150&#x2013;300 KB</td>
<td>&#x003C;1 MB</td>
<td>&#x003E;80 MHz recommended</td>
<td>Suitable for TinyML deployment</td>
</tr>
</tbody>
</table>
</table-wrap>
<p>We highlight that the restricted DQL controller is not designed to provide continuous onboard training for ultra low-power systems. Instead, the framework provides the following:<list list-type="bullet">
<list-item>
<p>offline training,</p></list-item>
<list-item>
<p>compressed policy deployment,</p></list-item>
<list-item>
<p>federated parameter updates,</p></list-item>
<list-item>
<p>and lightweight inference execution.</p></list-item>
</list></p>
<p>To further decrease embedded overhead, we addressed different optimization mechanisms:<list list-type="bullet">
<list-item>
<p>model pruning,</p></list-item>
<list-item>
<p>parameter quantization,</p></list-item>
<list-item>
<p>fixed-point arithmetic,</p></list-item>
<list-item>
<p>and event-driven inference scheduling.</p></list-item>
</list></p>
<p>The computational complexity per inference step is approximately as follows:<disp-formula id="ueqn-89"><mml:math id="mml-ueqn-89" display="block"><mml:msub><mml:mi>C</mml:mi><mml:mrow><mml:mrow><mml:mtext>inf</mml:mtext></mml:mrow></mml:mrow></mml:msub><mml:mo>=</mml:mo><mml:mi>O</mml:mi><mml:mo stretchy="false">(</mml:mo><mml:mrow><mml:mo stretchy="false">|</mml:mo></mml:mrow><mml:mi>A</mml:mi><mml:mrow><mml:mo stretchy="false">|</mml:mo></mml:mrow><mml:mo>+</mml:mo><mml:mi>d</mml:mi><mml:mo stretchy="false">)</mml:mo><mml:mo>,</mml:mo></mml:math></disp-formula>where <inline-formula id="ieqn-334"><mml:math id="mml-ieqn-334"><mml:mrow><mml:mo stretchy="false">|</mml:mo></mml:mrow><mml:mi>A</mml:mi><mml:mrow><mml:mo stretchy="false">|</mml:mo></mml:mrow></mml:math></inline-formula> denotes the action-space size and <inline-formula id="ieqn-335"><mml:math id="mml-ieqn-335"><mml:mi>d</mml:mi></mml:math></inline-formula> represents the compressed parameter dimension.</p>
<p>Our analysis emphasizes that communication adaptation and duty-cycle scheduling remain largely platform-independent, allowing the proposed optimization strategy to scale across heterogeneous embedded hardware.</p>
</sec>
</sec>
<sec id="s6">
<label>6</label>
<title>Conclusion</title>
<p>We developed a complete approach for reducing the communication energy usage of IoT equipment. This method combines protocol evaluation, a dynamic algorithm, as well as energy optimization. Our main contributions are (i) a comparison of low-power IoT protocols and MAC schemes that avoid collisions, (ii) real world examples of how to use ambient energy and backscatter to save energy, (iii) adaptive power control and scheduling techniques, including a DQL based agent that changes transmission parameters based on energy state, and (iv) an experimental prototype that shows significant energy savings.</p>
<p>Our architecture makes energy use much more efficient without making communication worse, as the results show. Our adaptive method made devices about 25% more reliable and longer lasting than the default (static) settings. To get this benefit, we should always use low-power, short-range communications when we can. When we&#x2019;re not using them, we should use ambient energy, and we should change the settings on our hardware (like the CPU and GPU) based on the energy environment.</p>
<p>Our research shows that IoT systems that will last need to have integrated design. By integrating energy sources, power control, and communication protocols, we might reduce the energy consumption of IoT swarms. By adding advanced learning based flexibility (such predicting energy availability), investigating other approaches, and addressing security issues, future research will enhance this framework. In brief, IoT and robotic systems require ways to talk to one other that may evolve over time and don&#x2019;t need any maintenance. Our analysis offers a clear way to get there.</p>
<p>In some respects, integrating the Internet of Things (IoT) to everyday equipment makes it easier to conserve energy, but in others, it makes it more difficult. It&#x2019;s critical to spend energy wisely as more devices connect to one another. Modifying laws and regulations which were not designed having the Internet of Things consideration is a major worry. We need to modify energy conservation laws so that they assist the environment while saving customers money.</p>
<p>Optimizing communication protocols for IoT devices is critical. Many legacy communication protocols prioritized data throughput and bandwidth at the expense of increased power consumption. Most Wi-Fi protocols target high-power devices and can connect to other devices across great distances. Novel low-power communication protocols, such as 6LoWPAN, are needed to achieve high data rates with minimal power consumption. These protocols are essential for ensuring effective operation of energy-efficient IoT systems.</p>
<p>In the future, all IoT devices and networks will need to adopt technology that saves energy. Organizations can achieve substantial energy savings with emerging technologies such as LTE-M and Narrowband IoT. This will extend battery lifetime and reduce overall energy consumption. This is particularly significant for smart city initiatives, as reduced energy consumption substantially benefits environmental sustainability. Establishing these standards is essential for proper operation of energy-efficient IoT systems.</p>
<p>Edge computing is increasingly critical for IoT systems. Edge computing reduces network traffic by processing data at the source rather than forwarding it to centralized servers. This enables real-time data access. This enhancement benefits latency-sensitive applications such as autonomous vehicles (AVs). Organizations are expected to achieve greater efficiency and reduced energy consumption through integrated deployment of IoT devices, edge computing, and 5G technology.</p>
<p>In conclusion, our study demonstrates that energy-efficient communication among autonomous IoT devices is feasible for practical applications. We have set up a way to make long lasting, maintenance free IoT systems by carefully designing the parts of the system and using flexible strategies to save energy and cut down on usage. The results of this study contribute to wider efforts to make the Internet of Things more efficient, reliable, and environmentally friendly.</p>
</sec>
</body>
<back>
<ack>
<p>We are grateful to our collaborators for their contributions to this publication. Their discussions, ideas, and constructive criticism have significantly enhanced the outcomes of this research.</p>
</ack>
<sec>
<title>Funding Statement</title>
<p>The authors received no specific funding for this study.</p>
</sec>
<sec>
<title>Author Contributions</title>
<p>The authors confirm contribution to the paper as follows: conceptualization, Amir Ijaz and Hashem Haghbayan; methodology, Amir Ijaz; software, Amir Ijaz; validation, Amir Ijaz and Abdul Malik; formal analysis, Amir Ijaz; investigation, Amir Ijaz; resources, Juha Plosila; data curation, Abdul Malik; writing&#x2014;original draft preparation, Amir Ijaz; writing&#x2014;review and editing, Ethiopia Nigussie; visualization, Ethiopia Nigussie; supervision, Hashem Haghbayan; project administration, Juha Plosila. Please turn to the <ext-link ext-link-type="uri" xlink:href="http://credit.niso.org/contributor-roles-defined/">CRediT role descriptors&#x2013;CRediT</ext-link> for the term explanation. All authors reviewed and approved the final version of the manuscript.</p>
</sec>
<sec sec-type="data-availability">
<title>Availability of Data and Materials</title>
<p>Not applicable.</p>
</sec>
<sec>
<title>Ethics Approval</title>
<p>Not applicable.</p>
</sec>
<sec sec-type="COI-statement">
<title>Conflicts of Interest</title>
<p>The authors declare no conflicts of interest.</p>
</sec>
<ref-list content-type="authoryear">
<title>References</title>
<ref id="ref-1"><label>[1]</label><mixed-citation publication-type="journal"><person-group person-group-type="author"><string-name><surname>Ziouzios</surname> <given-names>D</given-names></string-name>, <string-name><surname>Baras</surname> <given-names>N</given-names></string-name>, <string-name><surname>Dasygenis</surname> <given-names>M</given-names></string-name>, <string-name><surname>Karayannis</surname> <given-names>V</given-names></string-name>, <string-name><surname>Tsanaktsidis</surname> <given-names>C</given-names></string-name></person-group>. <article-title>Energy efficiency optimization in swarm robotics for smart photovoltaic monitoring</article-title>. <source>Energies</source>. <year>2025</year>;<volume>18</volume>(<issue>7</issue>):<fpage>1587</fpage>. doi:<pub-id pub-id-type="doi">10.3390/en18071587</pub-id>.</mixed-citation></ref>
<ref id="ref-2"><label>[2]</label><mixed-citation publication-type="journal"><person-group person-group-type="author"><string-name><surname>Ijaz</surname> <given-names>A</given-names></string-name>, <string-name><surname>Haghbayan</surname> <given-names>H</given-names></string-name>, <string-name><surname>Malik</surname> <given-names>A</given-names></string-name>, <string-name><surname>Nigussie</surname> <given-names>E</given-names></string-name>, <string-name><surname>Plosila</surname> <given-names>J</given-names></string-name></person-group>. <article-title>Towards optimizing communication cost in energy efficient IoT devices for swarm robotics</article-title>. <source>Procedia Comput Sci</source>. <year>2025</year>;<volume>265</volume>(<issue>1</issue>):<fpage>49</fpage>&#x2013;<lpage>56</lpage>. doi:<pub-id pub-id-type="doi">10.1016/j.procs.2025.07.155</pub-id>.</mixed-citation></ref>
<ref id="ref-3"><label>[3]</label><mixed-citation publication-type="journal"><person-group person-group-type="author"><string-name><surname>BenSaleh</surname> <given-names>M</given-names></string-name>, <string-name><surname>Sulaiman</surname> <given-names>MS</given-names></string-name>, <string-name><surname>Saida</surname> <given-names>R</given-names></string-name>, <string-name><surname>Hadj Kacem</surname> <given-names>Y</given-names></string-name>, <string-name><surname>Abid</surname> <given-names>M</given-names></string-name></person-group>. <article-title>Wireless sensor network design methodologies: a survey</article-title>. <source>J Sens</source>. <year>2020</year>;<volume>2020</volume>(<issue>1</issue>):<fpage>9592836</fpage>. doi:<pub-id pub-id-type="doi">10.1155/2020/9592836</pub-id>.</mixed-citation></ref>
<ref id="ref-4"><label>[4]</label><mixed-citation publication-type="journal"><person-group person-group-type="author"><string-name><surname>Ketshabetswe</surname> <given-names>LK</given-names></string-name>, <string-name><surname>Zungeru</surname> <given-names>AM</given-names></string-name>, <string-name><surname>Mangwala</surname> <given-names>M</given-names></string-name>, <string-name><surname>Chuma</surname> <given-names>JM</given-names></string-name>, <string-name><surname>Sigweni</surname> <given-names>B</given-names></string-name></person-group>. <article-title>Communication protocols for wireless sensor networks: a survey and comparison</article-title>. <source>Heliyon</source>. <year>2019</year>;<volume>5</volume>(<issue>5</issue>):<fpage>e01591</fpage>. doi:<pub-id pub-id-type="doi">10.1016/j.heliyon.2019.e01591</pub-id>; <pub-id pub-id-type="pmid">31193432</pub-id></mixed-citation></ref>
<ref id="ref-5"><label>[5]</label><mixed-citation publication-type="journal"><person-group person-group-type="author"><string-name><surname>Modieginyane</surname> <given-names>KM</given-names></string-name>, <string-name><surname>Letswamotse</surname> <given-names>BB</given-names></string-name>, <string-name><surname>Malekian</surname> <given-names>R</given-names></string-name>, <string-name><surname>Abu-Mahfouz</surname> <given-names>AM</given-names></string-name></person-group>. <article-title>Software-defined wireless sensor networks application opportunities for efficient network management: a survey</article-title>. <source>Comput Netw</source>. <year>2018</year>;<volume>146</volume>(<issue>2</issue>):<fpage>72</fpage>&#x2013;<lpage>90</lpage>. doi:<pub-id pub-id-type="doi">10.1016/j.compeleceng.2017.02.026</pub-id>.</mixed-citation></ref>
<ref id="ref-6"><label>[6]</label><mixed-citation publication-type="book"><person-group person-group-type="author"><string-name><surname>Kori</surname> <given-names>GS</given-names></string-name>, <string-name><surname>Kakkasageri</surname> <given-names>MS</given-names></string-name>, <string-name><surname>Manvi</surname> <given-names>SK</given-names></string-name></person-group>. <chapter-title>Computational intelligent techniques for resource management schemes in wireless sensor networks</chapter-title>. In: <source>Recent trends in computational intelligence enabled research</source>. <publisher-loc>Amsterdam, The Netherlands</publisher-loc>: <publisher-name>Elsevier</publisher-name>; <year>2021</year>. p. <fpage>41</fpage>&#x2013;<lpage>59</lpage>. doi:<pub-id pub-id-type="doi">10.1016/B978-0-12-822844-9.00023-2</pub-id>.</mixed-citation></ref>
<ref id="ref-7"><label>[7]</label><mixed-citation publication-type="journal"><person-group person-group-type="author"><string-name><surname>Deng</surname> <given-names>X</given-names></string-name>, <string-name><surname>Guan</surname> <given-names>P</given-names></string-name>, <string-name><surname>Hei</surname> <given-names>C</given-names></string-name>, <string-name><surname>Li</surname> <given-names>F</given-names></string-name>, <string-name><surname>Liu</surname> <given-names>J</given-names></string-name>, <string-name><surname>Xiong</surname> <given-names>N</given-names></string-name></person-group>. <article-title>An intelligent resource allocation scheme in energy harvesting cognitive wireless sensor networks</article-title>. <source>IEEE Trans Netw Sci Eng</source>. <year>2021</year>;<volume>8</volume>(<issue>2</issue>):<fpage>1900</fpage>&#x2013;<lpage>12</lpage>. doi:<pub-id pub-id-type="doi">10.1109/tnse.2021.3076485</pub-id>.</mixed-citation></ref>
<ref id="ref-8"><label>[8]</label><mixed-citation publication-type="journal"><person-group person-group-type="author"><string-name><surname>Anastasi</surname> <given-names>G</given-names></string-name>, <string-name><surname>Conti</surname> <given-names>M</given-names></string-name>, <string-name><surname>Di Francesco</surname> <given-names>M</given-names></string-name>, <string-name><surname>Passarella</surname> <given-names>A</given-names></string-name></person-group>. <article-title>Energy conservation in wireless sensor networks: a survey</article-title>. <source>Ad Hoc Netw</source>. <year>2009</year>;<volume>7</volume>(<issue>3</issue>):<fpage>537</fpage>&#x2013;<lpage>68</lpage>. doi:<pub-id pub-id-type="doi">10.1016/j.adhoc.2008.06.003</pub-id>.</mixed-citation></ref>
<ref id="ref-9"><label>[9]</label><mixed-citation publication-type="journal"><person-group person-group-type="author"><string-name><surname>Tyagi</surname> <given-names>SKS</given-names></string-name>, <string-name><surname>Mukherjee</surname> <given-names>A</given-names></string-name>, <string-name><surname>Pokhrel</surname> <given-names>SR</given-names></string-name>, <string-name><surname>Hiran</surname> <given-names>KK</given-names></string-name></person-group>. <article-title>An intelligent and optimal resource allocation approach in sensor networks for smart agri-IoT</article-title>. <source>IEEE Sens J</source>. <year>2020</year>;<volume>21</volume>(<issue>16</issue>):<fpage>17439</fpage>&#x2013;<lpage>46</lpage>. doi:<pub-id pub-id-type="doi">10.1109/jsen.2020.3020889</pub-id>.</mixed-citation></ref>
<ref id="ref-10"><label>[10]</label><mixed-citation publication-type="journal"><person-group person-group-type="author"><string-name><surname>Farhan</surname> <given-names>L</given-names></string-name>, <string-name><surname>Hameed</surname> <given-names>RS</given-names></string-name>, <string-name><surname>Ahmed</surname> <given-names>AS</given-names></string-name>, <string-name><surname>Fadel</surname> <given-names>AH</given-names></string-name>, <string-name><surname>Gheth</surname> <given-names>W</given-names></string-name>, <string-name><surname>Alzubaidi</surname> <given-names>L</given-names></string-name>, <etal>et al.</etal></person-group> <article-title>Energy efficiency for green internet of things networks: a survey</article-title>. <source>Network</source>. <year>2021</year>;<volume>1</volume>(<issue>3</issue>):<fpage>279</fpage>&#x2013;<lpage>314</lpage>. doi:<pub-id pub-id-type="doi">10.3390/network1030017</pub-id>.</mixed-citation></ref>
<ref id="ref-11"><label>[11]</label><mixed-citation publication-type="journal"><person-group person-group-type="author"><string-name><surname>Moore</surname> <given-names>SJ</given-names></string-name>, <string-name><surname>Nugent</surname> <given-names>CD</given-names></string-name>, <string-name><surname>Zhang</surname> <given-names>S</given-names></string-name>, <string-name><surname>Cleland</surname> <given-names>I</given-names></string-name></person-group>. <article-title>IoT reliability: a review leading to five key research directions</article-title>. <source>CCF Trans Pervasive Comput Interact</source>. <year>2020</year>;<volume>2</volume>(<issue>3</issue>):<fpage>147</fpage>&#x2013;<lpage>63</lpage>. doi:<pub-id pub-id-type="doi">10.1007/s42486-020-00037-z</pub-id>.</mixed-citation></ref>
<ref id="ref-12"><label>[12]</label><mixed-citation publication-type="conf-proc"><person-group person-group-type="author"><string-name><surname>Heinzelman</surname> <given-names>WR</given-names></string-name>, <string-name><surname>Chandrakasan</surname> <given-names>A</given-names></string-name>, <string-name><surname>Balakrishnan</surname> <given-names>H</given-names></string-name></person-group>. <article-title>Energy-efficient communication protocol for wireless microsensor networks</article-title>. In: <conf-name>Proceedings of the 33rd Annual Hawaii International Conference on System Sciences; 2000 Jan 7; Maui, HI, USA</conf-name>. doi:<pub-id pub-id-type="doi">10.1109/HICSS.2000.926982</pub-id>.</mixed-citation></ref>
<ref id="ref-13"><label>[13]</label><mixed-citation publication-type="journal"><person-group person-group-type="author"><string-name><surname>Adil</surname> <given-names>M</given-names></string-name>, <string-name><surname>Khan</surname> <given-names>R</given-names></string-name>, <string-name><surname>Almaiah</surname> <given-names>MA</given-names></string-name>, <string-name><surname>Binsawad</surname> <given-names>M</given-names></string-name>, <string-name><surname>Ali</surname> <given-names>J</given-names></string-name>, <string-name><surname>Al Saaidah</surname> <given-names>A</given-names></string-name></person-group>. <article-title>An efficient load balancing scheme of energy gauge nodes to maximize the lifespan of constraint-oriented networks</article-title>. <source>IEEE Access</source>. <year>2020</year>;<volume>8</volume>:<fpage>148510</fpage>&#x2013;<lpage>27</lpage>. doi:<pub-id pub-id-type="doi">10.1109/ACCESS.2020.3015941</pub-id>.</mixed-citation></ref>
<ref id="ref-14"><label>[14]</label><mixed-citation publication-type="journal"><person-group person-group-type="author"><string-name><surname>Adil</surname> <given-names>M</given-names></string-name>, <string-name><surname>Khan</surname> <given-names>R</given-names></string-name>, <string-name><surname>Ali</surname> <given-names>J</given-names></string-name>, <string-name><surname>Roh</surname> <given-names>BH</given-names></string-name>, <string-name><surname>Ta</surname> <given-names>QTH</given-names></string-name>, <string-name><surname>Almaiah</surname> <given-names>MA</given-names></string-name></person-group>. <article-title>An energy proficient load balancing routing scheme for wireless sensor networks to maximize lifespan in operational environments</article-title>. <source>IEEE Access</source>. <year>2020</year>;<volume>8</volume>:<fpage>163209</fpage>&#x2013;<lpage>24</lpage>. doi:<pub-id pub-id-type="doi">10.1109/ACCESS.2020.3020310</pub-id>.</mixed-citation></ref>
<ref id="ref-15"><label>[15]</label><mixed-citation publication-type="journal"><person-group person-group-type="author"><string-name><surname>Liu</surname> <given-names>X</given-names></string-name>, <string-name><surname>Wu</surname> <given-names>J</given-names></string-name></person-group>. <article-title>A method for energy balance and data transmission optimal routing in wireless sensor networks</article-title>. <source>Sensors</source>. <year>2019</year>;<volume>19</volume>(<issue>13</issue>):<fpage>3017</fpage>. doi:<pub-id pub-id-type="doi">10.3390/s19133017</pub-id>; <pub-id pub-id-type="pmid">31323948</pub-id></mixed-citation></ref>
<ref id="ref-16"><label>[16]</label><mixed-citation publication-type="journal"><person-group person-group-type="author"><string-name><surname>Wang</surname> <given-names>K</given-names></string-name>, <string-name><surname>Yu</surname> <given-names>CM</given-names></string-name>, <string-name><surname>Wang</surname> <given-names>LC</given-names></string-name></person-group>. <article-title>DORA: a destination-oriented routing algorithm for energy-balanced wireless sensor networks</article-title>. <source>IEEE Internet Things J</source>. <year>2020</year>;<volume>8</volume>(<issue>3</issue>):<fpage>2080</fpage>&#x2013;<lpage>91</lpage>. doi:<pub-id pub-id-type="doi">10.1109/JIOT.2020.3025039</pub-id>.</mixed-citation></ref>
<ref id="ref-17"><label>[17]</label><mixed-citation publication-type="journal"><person-group person-group-type="author"><string-name><surname>Patel</surname> <given-names>NR</given-names></string-name>, <string-name><surname>Kumar</surname> <given-names>S</given-names></string-name>, <string-name><surname>Singh</surname> <given-names>SK</given-names></string-name></person-group>. <article-title>Energy- and collision-aware WSN routing protocol for sustainable and intelligent IoT applications</article-title>. <source>IEEE Sens J</source>. <year>2021</year>;<volume>21</volume>(<issue>22</issue>):<fpage>25282</fpage>&#x2013;<lpage>92</lpage>. doi:<pub-id pub-id-type="doi">10.1109/JSEN.2021.3076192</pub-id>.</mixed-citation></ref>
<ref id="ref-18"><label>[18]</label><mixed-citation publication-type="conf-proc"><person-group person-group-type="author"><string-name><surname>Kour</surname> <given-names>H</given-names></string-name>, <string-name><surname>Sharma</surname> <given-names>AK</given-names></string-name></person-group>. <article-title>Performance evaluation of HEED and H-HEED protocol for realistic models in WSN</article-title>. In: <conf-name>Proceedings of the 2015 International Conference on Computer, Communication and Control (IC4); 2015 Sep 10&#x2013;12; Indore, India</conf-name>. p. <fpage>1</fpage>&#x2013;<lpage>5</lpage>. doi:<pub-id pub-id-type="doi">10.1109/IC4.2015.7375715</pub-id>.</mixed-citation></ref>
<ref id="ref-19"><label>[19]</label><mixed-citation publication-type="conf-proc"><person-group person-group-type="author"><string-name><surname>Kumar</surname> <given-names>M</given-names></string-name>, <string-name><surname>Zhang</surname> <given-names>X</given-names></string-name>, <string-name><surname>Liu</surname> <given-names>L</given-names></string-name>, <string-name><surname>Wang</surname> <given-names>Y</given-names></string-name>, <string-name><surname>Shi</surname> <given-names>W</given-names></string-name></person-group>. <article-title>Energy-efficient machine learning on the edges</article-title>. In: <conf-name>Proceedings of the 2020 IEEE International Parallel and Distributed Processing Symposium Workshops (IPDPSW); 2020 May 18&#x2013;22; New Orleans, LA, USA</conf-name>. p. <fpage>912</fpage>&#x2013;<lpage>21</lpage>. doi:<pub-id pub-id-type="doi">10.1109/IPDPSW50202.2020.00153</pub-id>.</mixed-citation></ref>
<ref id="ref-20"><label>[20]</label><mixed-citation publication-type="journal"><person-group person-group-type="author"><string-name><surname>Kim</surname> <given-names>S</given-names></string-name>, <string-name><surname>Yoo</surname> <given-names>Y</given-names></string-name></person-group>. <article-title>Contention-aware adaptive data rate for throughput optimization in LoRaWAN</article-title>. <source>Sensors</source>. <year>2018</year>;<volume>18</volume>(<issue>6</issue>):<fpage>1716</fpage>. doi:<pub-id pub-id-type="doi">10.3390/s18061716</pub-id>; <pub-id pub-id-type="pmid">29799513</pub-id></mixed-citation></ref>
<ref id="ref-21"><label>[21]</label><mixed-citation publication-type="journal"><person-group person-group-type="author"><string-name><surname>Reynders</surname> <given-names>B</given-names></string-name>, <string-name><surname>Wang</surname> <given-names>Q</given-names></string-name>, <string-name><surname>Tuset-Peiro</surname> <given-names>P</given-names></string-name>, <string-name><surname>Vilajosana</surname> <given-names>X</given-names></string-name>, <string-name><surname>Pollin</surname> <given-names>S</given-names></string-name></person-group>. <article-title>Improving reliability and scalability of LoRaWANs through lightweight scheduling</article-title>. <source>IEEE Internet Things J</source>. <year>2018</year>;<volume>5</volume>(<issue>3</issue>):<fpage>1830</fpage>&#x2013;<lpage>42</lpage>. doi:<pub-id pub-id-type="doi">10.1109/jiot.2018.2815150</pub-id>.</mixed-citation></ref>
<ref id="ref-22"><label>[22]</label><mixed-citation publication-type="journal"><person-group person-group-type="author"><string-name><surname>Benkhelifa</surname> <given-names>F</given-names></string-name>, <string-name><surname>Qin</surname> <given-names>Z</given-names></string-name>, <string-name><surname>McCann</surname> <given-names>JA</given-names></string-name></person-group>. <article-title>User fairness in energy harvesting-based LoRa networks with imperfect spreading factor orthogonality</article-title>. <source>IEEE Trans Commun</source>. <year>2021</year>;<volume>69</volume>(<issue>7</issue>):<fpage>4319</fpage>&#x2013;<lpage>34</lpage>. doi:<pub-id pub-id-type="doi">10.1109/tcomm.2021.3068304</pub-id>.</mixed-citation></ref>
<ref id="ref-23"><label>[23]</label><mixed-citation publication-type="journal"><person-group person-group-type="author"><string-name><surname>Farhan</surname> <given-names>L</given-names></string-name>, <string-name><surname>Kaiwartya</surname> <given-names>O</given-names></string-name>, <string-name><surname>Alzubaidi</surname> <given-names>L</given-names></string-name>, <string-name><surname>Gheth</surname> <given-names>W</given-names></string-name>, <string-name><surname>Dimla</surname> <given-names>E</given-names></string-name>, <string-name><surname>Kharel</surname> <given-names>R</given-names></string-name></person-group>. <article-title>Toward interference-aware IoT framework: energy- and geolocation-based modeling</article-title>. <source>IEEE Access</source>. <year>2019</year>;<volume>7</volume>:<fpage>56617</fpage>&#x2013;<lpage>30</lpage>. doi:<pub-id pub-id-type="doi">10.1109/ACCESS.2019.2913899</pub-id>.</mixed-citation></ref>
<ref id="ref-24"><label>[24]</label><mixed-citation publication-type="conf-proc"><person-group person-group-type="author"><string-name><surname>Naik</surname> <given-names>N</given-names></string-name></person-group>. <article-title>Choice of effective messaging protocols for IoT systems: MQTT, CoAP, AMQP and HTTP</article-title>. In: <conf-name>Proceedings of the 2017 IEEE International Systems Engineering Symposium (ISSE); 2017 Oct 11&#x2013;13; Vienna, Austria</conf-name>. p. <fpage>1</fpage>&#x2013;<lpage>7</lpage>. doi:<pub-id pub-id-type="doi">10.1109/SysEng.2017.8088251</pub-id>.</mixed-citation></ref>
<ref id="ref-25"><label>[25]</label><mixed-citation publication-type="journal"><person-group person-group-type="author"><string-name><surname>Al-Fuqaha</surname> <given-names>A</given-names></string-name>, <string-name><surname>Guizani</surname> <given-names>M</given-names></string-name>, <string-name><surname>Mohammadi</surname> <given-names>M</given-names></string-name>, <string-name><surname>Aledhari</surname> <given-names>M</given-names></string-name>, <string-name><surname>Ayyash</surname> <given-names>M</given-names></string-name></person-group>. <article-title>Internet of things: a survey on enabling technologies, protocols, and applications</article-title>. <source>IEEE Commun Surv Tutor</source>. <year>2015</year>;<volume>17</volume>(<issue>4</issue>):<fpage>2347</fpage>&#x2013;<lpage>76</lpage>. doi:<pub-id pub-id-type="doi">10.1109/COMST.2015.2444095</pub-id>.</mixed-citation></ref>
<ref id="ref-26"><label>[26]</label><mixed-citation publication-type="journal"><person-group person-group-type="author"><string-name><surname>Mekki</surname> <given-names>K</given-names></string-name>, <string-name><surname>Bajic</surname> <given-names>E</given-names></string-name>, <string-name><surname>Chaxel</surname> <given-names>F</given-names></string-name>, <string-name><surname>Meyer</surname> <given-names>F</given-names></string-name></person-group>. <article-title>A comparative study of LPWAN technologies for large-scale IoT deployment</article-title>. <source>ICT Express</source>. <year>2019</year>;<volume>5</volume>(<issue>1</issue>):<fpage>1</fpage>&#x2013;<lpage>7</lpage>. doi:<pub-id pub-id-type="doi">10.1016/j.icte.2017.12.005</pub-id>.</mixed-citation></ref>
<ref id="ref-27"><label>[27]</label><mixed-citation publication-type="conf-proc"><person-group person-group-type="author"><string-name><surname>Ratasuk</surname> <given-names>R</given-names></string-name>, <string-name><surname>Vejlgaard</surname> <given-names>B</given-names></string-name>, <string-name><surname>Mangalvedhe</surname> <given-names>N</given-names></string-name>, <string-name><surname>Ghosh</surname> <given-names>A</given-names></string-name></person-group>. <article-title>NB-IoT system for M2M communication</article-title>. In: <conf-name>Proceedings of the 2016 IEEE Wireless Communications and Networking Conference; 2016 Apr 3&#x2013;6; Doha, Qatar</conf-name>. p. <fpage>1</fpage>&#x2013;<lpage>5</lpage>. doi:<pub-id pub-id-type="doi">10.1109/WCNC.2016.7564708</pub-id>.</mixed-citation></ref>
<ref id="ref-28"><label>[28]</label><mixed-citation publication-type="journal"><person-group person-group-type="author"><string-name><surname>Ijaz</surname> <given-names>A</given-names></string-name>, <string-name><surname>Haghbayan</surname> <given-names>H</given-names></string-name>, <string-name><surname>Nigussie</surname> <given-names>E</given-names></string-name>, <string-name><surname>Malik</surname> <given-names>A</given-names></string-name>, <string-name><surname>Plosila</surname> <given-names>J</given-names></string-name></person-group>. <article-title>Optimizing communication and computational cost for IoT devices in energy-efficient swarm robotics</article-title>. <source>Green Tech and Sust</source>. <year>2026</year>;<volume>4</volume>(<issue>3</issue>):<fpage>100409</fpage>. doi:<pub-id pub-id-type="doi">10.1016/j.grets.2026.100409</pub-id>.</mixed-citation></ref>
</ref-list>
</back></article>