<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE article PUBLIC "-//NLM//DTD JATS (Z39.96) Journal Publishing DTD v1.4 20241031//EN" "JATS-journalpublishing1-4.dtd">
<article xmlns:mml="http://www.w3.org/1998/Math/MathML" xmlns:xlink="http://www.w3.org/1999/xlink" article-type="research-article" dtd-version="1.4" xml:lang="en">
  <front>
    <journal-meta>
      <journal-id journal-id-type="publisher-id">ait</journal-id>
      <journal-title-group>
        <journal-title>Advances in Internet of Things</journal-title>
      </journal-title-group>
      <issn pub-type="epub">2161-6825</issn>
      <issn pub-type="ppub">2161-6817</issn>
      <publisher>
        <publisher-name>Scientific Research Publishing</publisher-name>
      </publisher>
    </journal-meta>
    <article-meta>
      <article-id pub-id-type="doi">10.4236/ait.2026.164007</article-id>
      <article-id pub-id-type="publisher-id">ait-154738</article-id>
      <article-categories>
        <subj-group>
          <subject>Article</subject>
        </subj-group>
        <subj-group>
          <subject>Computer Science</subject>
          <subject>Communications</subject>
        </subj-group>
      </article-categories>
      <title-group>
        <article-title>Trust- and Residual-Energy-Aware Edge Scheduling for Intermittent Urban IoT Sensing</article-title>
      </title-group>
      <contrib-group>
        <contrib contrib-type="author" corresp="yes">
          <contrib-id contrib-id-type="orcid">0009-0004-0661-043X</contrib-id>
          <name name-style="western">
            <surname>Sethupathy</surname>
            <given-names>Utham Kumar Anugula</given-names>
          </name>
          <xref ref-type="aff" rid="aff1">1</xref>
        </contrib>
        <contrib contrib-type="author">
          <name name-style="western">
            <surname>Ananthanarayanan</surname>
            <given-names>Vijayanand</given-names>
          </name>
          <xref ref-type="aff" rid="aff1">1</xref>
        </contrib>
      </contrib-group>
      <aff id="aff1"><label>1</label> Independent Researcher, Atlanta, GA, USA </aff>
      <author-notes>
        <fn fn-type="conflict" id="fn-conflict">
          <p>The authors declare no conflicts of interest regarding the publication of this paper.</p>
        </fn>
      </author-notes>
      <pub-date pub-type="epub">
        <day>19</day>
        <month>10</month>
        <year>2026</year>
      </pub-date>
      <pub-date pub-type="collection">
        <month>10</month>
        <year>2026</year>
      </pub-date>
      <volume>16</volume>
      <issue>04</issue>
      <fpage>106</fpage>
      <lpage>123</lpage>
      <history>
        <date date-type="received">
          <day>10</day>
          <month>09</month>
          <year>2026</year>
        </date>
        <date date-type="accepted">
          <day>20</day>
          <month>10</month>
          <year>2026</year>
        </date>
        <date date-type="published">
          <day>23</day>
          <month>10</month>
          <year>2026</year>
        </date>
      </history>
      <permissions>
        <copyright-statement>© 2026 by the authors and Scientific Research Publishing Inc.</copyright-statement>
        <copyright-year>2026</copyright-year>
        <license license-type="open-access">
          <license-p> This article is an open access article distributed under the terms and conditions of the Creative Commons Attribution (CC BY) license ( <ext-link ext-link-type="uri" xlink:href="https://creativecommons.org/licenses/by/4.0/">https://creativecommons.org/licenses/by/4.0/</ext-link> ). </license-p>
        </license>
      </permissions>
      <self-uri content-type="doi" xlink:href="https://doi.org/10.4236/ait.2026.164007">https://doi.org/10.4236/ait.2026.164007</self-uri>
      <abstract>
        <p>Trust-aware Internet of Things scheduling requires reputation evidence that is observable and energy state that enters the scheduling decision explicitly. This study presents a joint trust-energy scheduler (JTES). Beta reputation updates only after known-answer challenges or redundant execution produces an imperfect validation label. The scheduler uses the exact 5th percentile of the Beta posterior at a documented controller refresh interval and includes both sensor residual battery and gateway residual energy. Twenty-four paired seeds, five compromise probabilities, seven schedulers, and three validator qualities produced 840 main and 72 sensitivity trials. Eight thousand task arrivals define one simulated day. At 15% compromise with moderate validation, full JTES achieved 94.80% clean timely completion (SD 3.21) and accepted 2.56% bad results (SD 3.17). Energy-only scheduling achieved 86.81% and accepted 11.32%. Posterior-mean scheduling achieved 97.01% clean timely completion, accepted 0.95% bad results, and consumed 138.98 mJ per completed task, yielding better values than the conservative-bound policy on these principal simulated metrics. Validator degradation changed accepted corruption from 2.26% to 3.64%. The simulation exposes integrity-energy and conservatism-efficiency trade-offs and does not claim production lifetime or security performance.</p>
      </abstract>
      <kwd-group kwd-group-type="author-generated" xml:lang="en">
        <kwd>Internet of Things</kwd>
        <kwd>Edge Scheduling</kwd>
        <kwd>Beta Reputation</kwd>
        <kwd>Validation</kwd>
        <kwd>Residual Energy</kwd>
      </kwd-group>
    </article-meta>
  </front>
  <body>
    <sec id="sec1">
      <title>1. Introduction</title>
      <p>Constrained nodes have limited memory, processing, communication, and energy resources [<xref ref-type="bibr" rid="B1">1</xref>]. IoT security baselines therefore emphasize observable device state and defined security capabilities [<xref ref-type="bibr" rid="B2">2</xref>], while consumer-IoT guidance requires lifecycle controls rather than implicit trust [<xref ref-type="bibr" rid="B3">3</xref>].</p>
      <p>Trust estimates can become overconfident if schedulers learn from outcomes that were never validated. Energy-aware scheduling is likewise incomplete when distance or queue length substitutes for residual battery and gateway energy. JTES therefore restricts trust updates to observable validation and represents both energy domains explicitly.</p>
      <p>The research question is whether observable validation evidence and explicit dual-resource energy state can improve clean timely delivery under intermittent and compromised gateways, and what integrity cost follows from weaker validation or reduced replication. <xref ref-type="fig" rid="fig1">Figure 1</xref> summarizes the architecture.</p>
      <fig id="fig1">
        <label>Figure 1</label>
        <graphic xlink:href="https://html.scirp.org/file/4000523-rId15.jpeg?20261023022103" />
      </fig>
      <p><bold>Figure 1.</bold> JTES architecture with observable validation, Beta evidence updates, and separate sensor and gateway energy states.</p>
    </sec>
    <sec id="sec2">
      <title>2. Related Work</title>
      <p>Edge computing places computation near data sources to reduce response time and backhaul dependence [<xref ref-type="bibr" rid="B4">4</xref>]. Edge and fog architectures expose resource-allocation and reliability trade-offs [<xref ref-type="bibr" rid="B5">5</xref>][<xref ref-type="bibr" rid="B6">6</xref>]. JTES studies a narrow scheduling layer within that broader architecture.</p>
      <p>Beta reputation represents favorable and unfavorable evidence with compact sufficient statistics [<xref ref-type="bibr" rid="B7">7</xref>]. EigenTrust aggregates repeated local experience [<xref ref-type="bibr" rid="B8">8</xref>], and sensor-network reputation systems use observations to support integrity [<xref ref-type="bibr" rid="B9">9</xref>]. JTES follows their evidence principle: an unvalidated task creates no reputation update.</p>
      <p>Radio-energy models for sensor networks relate electronic and amplifier cost to transmitted bits and distance [<xref ref-type="bibr" rid="B10">10</xref>]. Wireless-sensor surveys document how topology, duty cycling, and routing affect lifetime [<xref ref-type="bibr" rid="B11">11</xref>]. The present experiment maintains sensor joules and gateway joules separately instead of treating distance as residual energy.</p>
      <p>CoAP [<xref ref-type="bibr" rid="B12">12</xref>], object security [<xref ref-type="bibr" rid="B13">13</xref>], and constrained-device cryptography [<xref ref-type="bibr" rid="B14">14</xref>] illustrate mechanisms that could carry authenticated tasks and validation exchanges. Security and trust surveys [<xref ref-type="bibr" rid="B15">15</xref>] and IoT protocol surveys [<xref ref-type="bibr" rid="B16">16</xref>] emphasize that reputation does not replace identity or cryptographic protection. Simulation limitations remain substantial [<xref ref-type="bibr" rid="B17">17</xref>].</p>
      <p>Recent edge studies jointly consider trust and information freshness [<xref ref-type="bibr" rid="B18">18</xref>], trusted data scheduling [<xref ref-type="bibr" rid="B19">19</xref>], and energy-aware offloading with learned trust [<xref ref-type="bibr" rid="B20">20</xref>]. Task dependencies and unreliable volunteer servers motivate trust-aware placement [<xref ref-type="bibr" rid="B21">21</xref>], while cooperative IoT scheduling [<xref ref-type="bibr" rid="B22">22</xref>], device-specific communication-computation allocation [<xref ref-type="bibr" rid="B23">23</xref>], and delay-energy optimization [<xref ref-type="bibr" rid="B24">24</xref>] show that service and energy objectives are tightly coupled. Real-time trust-aware fog scheduling [<xref ref-type="bibr" rid="B25">25</xref>] further supports evaluating trust as an operational scheduling signal rather than an isolated reputation score.</p>
    </sec>
    <sec id="sec3">
      <title>3. Synthetic IoT Environment</title>
      <p><xref ref-type="fig" rid="fig2">Figure 2</xref> shows 400 sensors and six gateways in a 2 km by 2 km field. Gateway compromise is hidden from the scheduler. It affects only the generated result; the controller observes a noisy validation label when a challenge or redundant execution occurs.</p>
      <fig id="fig2">
        <label>Figure 2</label>
        <graphic xlink:href="https://html.scirp.org/file/4000523-rId16.jpeg?20261023022104" />
      </fig>
      <p><bold>Figure 2.</bold> Representative sensing field. Compromise coloring is evaluator-only ground truth.</p>
      <p><bold>Table 1</bold> defines the workload and physical units. Exactly 8000 arrivals represent one simulated day; the lifetime projection divides energy capacity by that day’s per-device consumption.</p>
      <p><bold>Table 1.</bold> Simulation environment.</p>
      <table-wrap id="tbl1">
        <label>Table 1</label>
        <table>
          <tbody>
            <tr>
              <td>
                <bold>Parameter</bold>
              </td>
              <td>
                <bold>Value</bold>
              </td>
            </tr>
            <tr>
              <td>Sensors and gateways</td>
              <td>400 and 6</td>
            </tr>
            <tr>
              <td>Area</td>
              <td>2 km × 2 km</td>
            </tr>
            <tr>
              <td>Arrivals</td>
              <td>8000 per simulated day</td>
            </tr>
            <tr>
              <td>Critical tasks</td>
              <td>22%</td>
            </tr>
            <tr>
              <td>Known-answer challenges</td>
              <td>3%</td>
            </tr>
            <tr>
              <td>Sensor battery</td>
              <td>18,000 J</td>
            </tr>
            <tr>
              <td>Gateway energy budget</td>
              <td>2,000,000 J</td>
            </tr>
            <tr>
              <td>Compromise probability</td>
              <td>0%, 5%, 10%, 15%, 20%</td>
            </tr>
          </tbody>
        </table>
      </table-wrap>
      <sec id="sec3dot1">
        <title>Task, Availability, and Execution Model</title>
        <p>The simulation represents one synthetic day as 8000 discrete task arrivals. One task arrives per simulation step; no Poisson or wall-clock interarrival process is assumed. For each arrival, the originating sensor is selected uniformly from the 400 sensors. A task is marked critical independently with probability 0.22 and as a known-answer challenge independently with probability 0.03. Computational workload is sampled uniformly from 25 to 65 million cycles.</p>
        <p>Task deadlines use a two-level distribution: 25% of tasks receive a 150 ms deadline and the remaining 75% receive a 220 ms deadline. Gateway availability is sampled independently for every task-gateway pair. The six gateway unavailability probabilities are 0.08, 0.12, 0.09, 0.14, 0.10, and 0.13, respectively; thus the corresponding availability probabilities are 0.92, 0.88, 0.91, 0.86, 0.90, and 0.87.</p>
        <p>Before each task is scheduled, every gateway queue is reduced by 0.55 task units, bounded below by zero. After an execution is assigned to gateway <inline-formula><mml:math><mml:mi> g </mml:mi></mml:math></inline-formula> , the queue is incremented by one. The execution-success probability depends on the resulting queue: </p>
        <disp-formula id="FD1">
          <mml:math>
            <mml:mrow>
              <mml:msub>
                <mml:mi>P</mml:mi>
                <mml:mrow>
                  <mml:mtext>fail</mml:mtext>
                  <mml:mo>,</mml:mo>
                  <mml:mi>g</mml:mi>
                </mml:mrow>
              </mml:msub>
              <mml:mo>=</mml:mo>
              <mml:mn>0.012</mml:mn>
              <mml:mo>+</mml:mo>
              <mml:mn>0.008</mml:mn>
              <mml:mi>min</mml:mi>
              <mml:mrow>
                <mml:mo>(</mml:mo>
                <mml:mrow>
                  <mml:mn>8</mml:mn>
                  <mml:mo>,</mml:mo>
                  <mml:msub>
                    <mml:mi>Q</mml:mi>
                    <mml:mi>g</mml:mi>
                  </mml:msub>
                </mml:mrow>
                <mml:mo>)</mml:mo>
              </mml:mrow>
              <mml:mo>,</mml:mo>
            </mml:mrow>
          </mml:math>
        </disp-formula>
        <p>so that</p>
        <disp-formula id="FD2">
          <mml:math>
            <mml:mrow>
              <mml:msub>
                <mml:mi>P</mml:mi>
                <mml:mrow>
                  <mml:mtext>succ</mml:mtext>
                  <mml:mo>,</mml:mo>
                  <mml:mi>g</mml:mi>
                </mml:mrow>
              </mml:msub>
              <mml:mo>=</mml:mo>
              <mml:mn>1</mml:mn>
              <mml:mo>−</mml:mo>
              <mml:msub>
                <mml:mi>P</mml:mi>
                <mml:mrow>
                  <mml:mtext>fail</mml:mtext>
                  <mml:mo>,</mml:mo>
                  <mml:mi>g</mml:mi>
                </mml:mrow>
              </mml:msub>
              <mml:mo>.</mml:mo>
            </mml:mrow>
          </mml:math>
        </disp-formula>
        <p>The execution latency of a successful task on gateway <inline-formula><mml:math><mml:mi> g </mml:mi></mml:math></inline-formula> is </p>
        <disp-formula id="FD3">
          <mml:math>
            <mml:mrow>
              <mml:msub>
                <mml:mi>L</mml:mi>
                <mml:mrow>
                  <mml:mi>i</mml:mi>
                  <mml:mo>,</mml:mo>
                  <mml:mi>g</mml:mi>
                </mml:mrow>
              </mml:msub>
              <mml:mo>=</mml:mo>
              <mml:mn>22</mml:mn>
              <mml:mo>+</mml:mo>
              <mml:mn>0.032</mml:mn>
              <mml:msub>
                <mml:mi>d</mml:mi>
                <mml:mrow>
                  <mml:mi>i</mml:mi>
                  <mml:mo>,</mml:mo>
                  <mml:mi>g</mml:mi>
                </mml:mrow>
              </mml:msub>
              <mml:mo>+</mml:mo>
              <mml:mn>6</mml:mn>
              <mml:msub>
                <mml:mi>Q</mml:mi>
                <mml:mi>g</mml:mi>
              </mml:msub>
              <mml:mo>+</mml:mo>
              <mml:msub>
                <mml:mi>η</mml:mi>
                <mml:mrow>
                  <mml:mi>i</mml:mi>
                  <mml:mo>,</mml:mo>
                  <mml:mi>g</mml:mi>
                </mml:mrow>
              </mml:msub>
              <mml:mo>,</mml:mo>
            </mml:mrow>
          </mml:math>
        </disp-formula>
        <p>where <inline-formula><mml:math><mml:mrow><mml:msub><mml:mi> d </mml:mi><mml:mrow><mml:mrow><mml:mo> { </mml:mo><mml:mrow><mml:mi> i </mml:mi><mml:mo> , </mml:mo><mml:mi> g </mml:mi></mml:mrow><mml:mo> } </mml:mo></mml:mrow></mml:mrow></mml:msub><mml:mo></mml:mo></mml:mrow></mml:math></inline-formula> is sensor-gateway distance in meters and </p>
        <disp-formula id="FD4">
          <mml:math>
            <mml:mrow>
              <mml:msub>
                <mml:mi>η</mml:mi>
                <mml:mrow>
                  <mml:mi>i</mml:mi>
                  <mml:mo>,</mml:mo>
                  <mml:mi>g</mml:mi>
                </mml:mrow>
              </mml:msub>
              <mml:mo>∼</mml:mo>
              <mml:mtext>Lognormal</mml:mtext>
              <mml:mrow>
                <mml:mo>(</mml:mo>
                <mml:mrow>
                  <mml:mn>2.0</mml:mn>
                  <mml:mo>,</mml:mo>
                  <mml:mn>0.27</mml:mn>
                </mml:mrow>
                <mml:mo>)</mml:mo>
              </mml:mrow>
              <mml:mo>.</mml:mo>
            </mml:mrow>
          </mml:math>
        </disp-formula>
        <p>A task is classified as timely only when its final accepted result is clean and its modeled task latency does not exceed that task’s assigned deadline. Gateway compromise status is sampled once at the start of a simulated day and remains fixed for that trial. Each gateway is independently marked compromised with the scenario probability <inline-formula><mml:math><mml:mrow><mml:msub><mml:mi> p </mml:mi><mml:mi> c </mml:mi></mml:msub></mml:mrow></mml:math></inline-formula> . A benign gateway never generates a corrupted result in the model. A compromised gateway corrupts each attempted execution independently with probability 0.68:</p>
        <disp-formula id="FD5">
          <mml:math>
            <mml:mrow>
              <mml:mi>P</mml:mi>
              <mml:mrow>
                <mml:mo>(</mml:mo>
                <mml:mrow>
                  <mml:mrow>
                    <mml:mrow>
                      <mml:mtext>bad</mml:mtext>
                    </mml:mrow>
                    <mml:mo>|</mml:mo>
                  </mml:mrow>
                  <mml:mtext>compromised</mml:mtext>
                </mml:mrow>
                <mml:mo>)</mml:mo>
              </mml:mrow>
              <mml:mo>=</mml:mo>
              <mml:mn>0.68</mml:mn>
              <mml:mo>,</mml:mo>
              <mml:mtext>
              </mml:mtext>
              <mml:mi>P</mml:mi>
              <mml:mrow>
                <mml:mo>(</mml:mo>
                <mml:mrow>
                  <mml:mrow>
                    <mml:mrow>
                      <mml:mtext>bad</mml:mtext>
                    </mml:mrow>
                    <mml:mo>|</mml:mo>
                  </mml:mrow>
                  <mml:mtext>benign</mml:mtext>
                </mml:mrow>
                <mml:mo>)</mml:mo>
              </mml:mrow>
              <mml:mo>=</mml:mo>
              <mml:mn>0.</mml:mn>
            </mml:mrow>
          </mml:math>
        </disp-formula>
        <p>The same corruption rule applies to primary executions, replicated executions, and known-answer challenge tasks. Corruption status affects the generated result but is never directly visible to the scheduler.</p>
      </sec>
    </sec>
    <sec id="sec4">
      <title>4. Observable Beta Reputation</title>
      <sec id="sec4dot1">
        <title>4.1. Evidence Sources</title>
        <p>A task updates reputation only when observable validation evidence is available. This occurs when a successful known-answer challenge returns a result or when redundant execution produces at least two successful gateway outcomes. Merely dispatching a replica does not guarantee a validation label, because one or both executions may fail. Validation is imperfect: in the moderate setting, a bad primary is labeled bad with 90% probability and a clean primary is falsely labeled bad with 3% probability. Unvalidated successes and failures do not change alpha or beta.</p>
        <p>Equation (1) defines the posterior and the conservative score. The implementation numerically inverts the regularized incomplete Beta function; it does not use a Wilson approximation.</p>
        <disp-formula id="FD6">
          <label>(1)</label>
          <mml:math>
            <mml:mrow>
              <mml:mrow>
                <mml:mrow>
                  <mml:msub>
                    <mml:mi>θ</mml:mi>
                    <mml:mi>g</mml:mi>
                  </mml:msub>
                </mml:mrow>
                <mml:mo>|</mml:mo>
              </mml:mrow>
              <mml:msub>
                <mml:mi>α</mml:mi>
                <mml:mi>g</mml:mi>
              </mml:msub>
              <mml:mo>,</mml:mo>
              <mml:msub>
                <mml:mi>β</mml:mi>
                <mml:mi>g</mml:mi>
              </mml:msub>
              <mml:mo>∼</mml:mo>
              <mml:mtext>Beta</mml:mtext>
              <mml:mrow>
                <mml:mo>(</mml:mo>
                <mml:mrow>
                  <mml:msub>
                    <mml:mi>α</mml:mi>
                    <mml:mi>g</mml:mi>
                  </mml:msub>
                  <mml:mo>,</mml:mo>
                  <mml:msub>
                    <mml:mi>β</mml:mi>
                    <mml:mi>g</mml:mi>
                  </mml:msub>
                </mml:mrow>
                <mml:mo>)</mml:mo>
              </mml:mrow>
              <mml:mo>,</mml:mo>
              <mml:mtext>
              </mml:mtext>
              <mml:msub>
                <mml:mi>q</mml:mi>
                <mml:mi>g</mml:mi>
              </mml:msub>
              <mml:mo>=</mml:mo>
              <mml:msubsup>
                <mml:mi>F</mml:mi>
                <mml:mrow>
                  <mml:mtext>Beta</mml:mtext>
                  <mml:mrow>
                    <mml:mo>(</mml:mo>
                    <mml:mrow>
                      <mml:msub>
                        <mml:mi>α</mml:mi>
                        <mml:mi>g</mml:mi>
                      </mml:msub>
                      <mml:mo>,</mml:mo>
                      <mml:msub>
                        <mml:mi>β</mml:mi>
                        <mml:mi>g</mml:mi>
                      </mml:msub>
                    </mml:mrow>
                    <mml:mo>)</mml:mo>
                  </mml:mrow>
                </mml:mrow>
                <mml:mrow>
                  <mml:mo>−</mml:mo>
                  <mml:mn>1</mml:mn>
                </mml:mrow>
              </mml:msubsup>
              <mml:mrow>
                <mml:mo>(</mml:mo>
                <mml:mrow>
                  <mml:mn>0.05</mml:mn>
                </mml:mrow>
                <mml:mo>)</mml:mo>
              </mml:mrow>
            </mml:mrow>
          </mml:math>
        </disp-formula>
        <p>The prior is Beta (2, 1). Alpha increments after an observed clean label and beta increments after an observed bad label. Because the validation labels are imperfect, this posterior should not be interpreted as a calibrated posterior probability of true gateway integrity. Rather, it estimates the probability that a validated gateway execution will receive a clean validation label under the configured validator error model. The true-positive and false-positive rates are not explicitly inverted or incorporated into the Bayesian likelihood, so the posterior reflects validated-label cleanliness rather than latent physical integrity.</p>
        <p>For controller efficiency, posterior counts update on every validation but <italic>q</italic><italic><sub>g</sub></italic> is refreshed after 50 new observations for that gateway. <xref ref-type="fig" rid="fig3">Figure 3</xref> shows posterior means and lower bounds in one fixed-seed run.</p>
      </sec>
      <sec id="sec4dot2">
        <title>4.2. Validation Sensitivity</title>
        <p><bold>Table 2</bold> lists the three validator scenarios. They are controlled error settings, not measured classifier performance.</p>
      </sec>
      <sec id="sec4dot3">
        <title>4.3. Selective Replication and Result Resolution</title>
        <p>Full JTES, Trust-only, and Posterior-mean scheduling use the same selective-replication trigger. After the primary gateway is selected, a second execution is dispatched only when the task is critical and the primary gateway’s current 5th-percentile trust bound is below 0.90. The second gateway is the next-lowest-cost currently active gateway under the same scheduling policy. Always replicate dispatches a second execution whenever a second eligible gateway is available.</p>
        <fig id="fig3">
          <label>Figure 3</label>
          <graphic xlink:href="https://html.scirp.org/file/4000523-rId37.jpeg?20261023022106" />
        </fig>
        <p><bold>Figure 3.</bold> Posterior means and 5th-percentile Beta credible bounds during one representative run.</p>
        <p><bold>Table 2.</bold> Validator quality scenarios.</p>
        <table-wrap id="tbl2">
          <label>Table 2</label>
          <table>
            <tbody>
              <tr>
                <td>
                  <bold>Quality</bold>
                </td>
                <td>
                  <bold>True-positive probability</bold>
                </td>
                <td>
                  <bold>False-positive probability</bold>
                </td>
              </tr>
              <tr>
                <td>Strong</td>
                <td>0.98</td>
                <td>0.01</td>
              </tr>
              <tr>
                <td>Moderate</td>
                <td>0.90</td>
                <td>0.03</td>
              </tr>
              <tr>
                <td>Weak</td>
                <td>0.75</td>
                <td>0.08</td>
              </tr>
            </tbody>
          </table>
        </table-wrap>
        <p>Replica executions are modeled as parallel copies on different gateways rather than as a serial retry. If both executions succeed, the task latency is taken as the larger of the successful execution latencies because resolution waits for the returned evidence. If only one copy succeeds, that successful outcome remains available but redundant execution alone does not produce a two-result validation event.</p>
        <p>Validation classifies the primary result. If the primary receives a bad label and a second successful result exists, the second result is accepted. Otherwise, the primary result is retained. Known-answer challenges update reputation but do not independently force task rejection or replacement. If no execution succeeds, the task is incomplete and produces no validation evidence.</p>
      </sec>
    </sec>
    <sec id="sec5">
      <title>5. Dual Resource Energy Model</title>
      <p>Equation (2) gives sensor transmit energy in joules, using packet length <italic>b</italic>, electronics cost <italic>E</italic><sub>elec</sub>, amplifier coefficient <inline-formula><mml:math><mml:mrow><mml:msub><mml:mi> ε </mml:mi><mml:mrow><mml:mtext> amp </mml:mtext></mml:mrow></mml:msub></mml:mrow></mml:math></inline-formula> , and sensor-gateway distance.</p>
      <disp-formula id="FD7">
        <label>(2)</label>
        <mml:math>
          <mml:mrow>
            <mml:msubsup>
              <mml:mi>E</mml:mi>
              <mml:mrow>
                <mml:mi>i</mml:mi>
                <mml:mo>,</mml:mo>
                <mml:mi>g</mml:mi>
              </mml:mrow>
              <mml:mrow>
                <mml:mi>t</mml:mi>
                <mml:mi>x</mml:mi>
              </mml:mrow>
            </mml:msubsup>
            <mml:mo>=</mml:mo>
            <mml:mi>b</mml:mi>
            <mml:msub>
              <mml:mi>E</mml:mi>
              <mml:mrow>
                <mml:mtext>elec</mml:mtext>
              </mml:mrow>
            </mml:msub>
            <mml:mo>+</mml:mo>
            <mml:mi>b</mml:mi>
            <mml:msub>
              <mml:mi>ε</mml:mi>
              <mml:mrow>
                <mml:mtext>amp</mml:mtext>
              </mml:mrow>
            </mml:msub>
            <mml:msubsup>
              <mml:mi>d</mml:mi>
              <mml:mrow>
                <mml:mi>i</mml:mi>
                <mml:mo>,</mml:mo>
                <mml:mi>g</mml:mi>
              </mml:mrow>
              <mml:mn>2</mml:mn>
            </mml:msubsup>
          </mml:mrow>
        </mml:math>
      </disp-formula>
      <p>The simulation uses <italic>b</italic> = 4096 bits, <italic>E</italic><sub>elec</sub> = 50 nJ/bit, and <inline-formula><mml:math><mml:mrow><mml:msub><mml:mi> ε </mml:mi><mml:mrow><mml:mtext> amp </mml:mtext></mml:mrow></mml:msub></mml:mrow></mml:math></inline-formula> = 100 pJ/bit/m<sup>2</sup>.</p>
      <p>Equation (3) defines gateway energy for idle execution time, computational work <italic>C</italic> in millions of cycles, and queue-dependent overhead.</p>
      <disp-formula id="FD8">
        <label>(3)</label>
        <mml:math>
          <mml:mrow>
            <mml:msubsup>
              <mml:mi>E</mml:mi>
              <mml:mrow>
                <mml:mi>g</mml:mi>
                <mml:mo>,</mml:mo>
                <mml:mi>t</mml:mi>
              </mml:mrow>
              <mml:mrow>
                <mml:mtext>gw</mml:mtext>
              </mml:mrow>
            </mml:msubsup>
            <mml:mo>=</mml:mo>
            <mml:msub>
              <mml:mi>P</mml:mi>
              <mml:mrow>
                <mml:mtext>idle</mml:mtext>
              </mml:mrow>
            </mml:msub>
            <mml:msub>
              <mml:mi>t</mml:mi>
              <mml:mrow>
                <mml:mtext>exec</mml:mtext>
              </mml:mrow>
            </mml:msub>
            <mml:mo>+</mml:mo>
            <mml:msub>
              <mml:mi>ε</mml:mi>
              <mml:mrow>
                <mml:mtext>cpu</mml:mtext>
              </mml:mrow>
            </mml:msub>
            <mml:msub>
              <mml:mi>C</mml:mi>
              <mml:mi>t</mml:mi>
            </mml:msub>
            <mml:mo>+</mml:mo>
            <mml:msub>
              <mml:mi>ε</mml:mi>
              <mml:mi>q</mml:mi>
            </mml:msub>
            <mml:msub>
              <mml:mi>Q</mml:mi>
              <mml:mi>g</mml:mi>
            </mml:msub>
            <mml:mrow>
              <mml:mo>(</mml:mo>
              <mml:mi>t</mml:mi>
              <mml:mo>)</mml:mo>
            </mml:mrow>
          </mml:mrow>
        </mml:math>
      </disp-formula>
      <p>where:</p>
      <p><inline-formula><mml:math><mml:mrow><mml:msub><mml:mi> P </mml:mi><mml:mrow><mml:mtext> idle </mml:mtext></mml:mrow></mml:msub><mml:mo> = </mml:mo><mml:mn> 40 </mml:mn><mml:mtext> W </mml:mtext></mml:mrow></mml:math></inline-formula> ;<inline-formula><mml:math><mml:mrow><mml:msub><mml:mi> t </mml:mi><mml:mrow><mml:mtext> exec </mml:mtext></mml:mrow></mml:msub><mml:mo> = </mml:mo><mml:mn> 0.020 </mml:mn><mml:mtext> s </mml:mtext></mml:mrow></mml:math></inline-formula> ;<inline-formula><mml:math><mml:mrow><mml:msub><mml:mi> ε </mml:mi><mml:mrow><mml:mtext> cpu </mml:mtext></mml:mrow></mml:msub><mml:mo> = </mml:mo><mml:mn> 0.46 </mml:mn><mml:mtext> J </mml:mtext></mml:mrow></mml:math></inline-formula> per million cycles;<inline-formula><mml:math><mml:mrow><mml:msub><mml:mi> ε </mml:mi><mml:mi> q </mml:mi></mml:msub><mml:mo> = </mml:mo><mml:mn> 0.16 </mml:mn><mml:mtext> J </mml:mtext></mml:mrow></mml:math></inline-formula> per queued task.</p>
      <p>Both costs are deducted after every attempted execution. The scheduler observes residual sensor battery <inline-formula><mml:math><mml:mrow><mml:msub><mml:mi> B </mml:mi><mml:mi> i </mml:mi></mml:msub></mml:mrow></mml:math></inline-formula> and residual gateway energy <inline-formula><mml:math><mml:mrow><mml:msub><mml:mi> G </mml:mi><mml:mi> g </mml:mi></mml:msub></mml:mrow></mml:math></inline-formula> . Equation (4) combines predicted latency, normalized energy burdens, and the conservative trust penalty.</p>
      <disp-formula id="FD9">
        <mml:math display="inline">
          <mml:mrow>
            <mml:msub>
              <mml:mover accent="true">
                <mml:mi>L</mml:mi>
                <mml:mo>^</mml:mo>
              </mml:mover>
              <mml:mrow>
                <mml:mi>i</mml:mi>
                <mml:mo>,</mml:mo>
                <mml:mi>g</mml:mi>
              </mml:mrow>
            </mml:msub>
            <mml:mo>=</mml:mo>
            <mml:mfrac>
              <mml:mrow>
                <mml:mn>22</mml:mn>
                <mml:mo>+</mml:mo>
                <mml:mn>0.032</mml:mn>
                <mml:msub>
                  <mml:mi>d</mml:mi>
                  <mml:mrow>
                    <mml:mi>i</mml:mi>
                    <mml:mo>,</mml:mo>
                    <mml:mi>g</mml:mi>
                  </mml:mrow>
                </mml:msub>
                <mml:mo>+</mml:mo>
                <mml:mn>6</mml:mn>
                <mml:msub>
                  <mml:mi>Q</mml:mi>
                  <mml:mi>g</mml:mi>
                </mml:msub>
              </mml:mrow>
              <mml:mrow>
                <mml:mn>120</mml:mn>
              </mml:mrow>
            </mml:mfrac>
          </mml:mrow>
        </mml:math>
      </disp-formula>
      <disp-formula id="FD10">
        <mml:math>
          <mml:mrow>
            <mml:msubsup>
              <mml:mover accent="true">
                <mml:mi>E</mml:mi>
                <mml:mo>˜</mml:mo>
              </mml:mover>
              <mml:mrow>
                <mml:mi>i</mml:mi>
                <mml:mo>,</mml:mo>
                <mml:mi>g</mml:mi>
              </mml:mrow>
              <mml:mi>s</mml:mi>
            </mml:msubsup>
            <mml:mo>=</mml:mo>
            <mml:mfrac>
              <mml:mrow>
                <mml:mrow>
                  <mml:mrow>
                    <mml:msubsup>
                      <mml:mi>E</mml:mi>
                      <mml:mrow>
                        <mml:mi>i</mml:mi>
                        <mml:mo>,</mml:mo>
                        <mml:mi>g</mml:mi>
                      </mml:mrow>
                      <mml:mrow>
                        <mml:mi>t</mml:mi>
                        <mml:mi>x</mml:mi>
                      </mml:mrow>
                    </mml:msubsup>
                  </mml:mrow>
                  <mml:mo>/</mml:mo>
                  <mml:mrow>
                    <mml:msub>
                      <mml:mi>B</mml:mi>
                      <mml:mi>i</mml:mi>
                    </mml:msub>
                  </mml:mrow>
                </mml:mrow>
              </mml:mrow>
              <mml:mrow>
                <mml:msub>
                  <mml:mrow>
                    <mml:mtext>median</mml:mtext>
                  </mml:mrow>
                  <mml:mi>h</mml:mi>
                </mml:msub>
                <mml:mrow>
                  <mml:mo>(</mml:mo>
                  <mml:mrow>
                    <mml:mrow>
                      <mml:mrow>
                        <mml:msubsup>
                          <mml:mi>E</mml:mi>
                          <mml:mrow>
                            <mml:mi>i</mml:mi>
                            <mml:mo>,</mml:mo>
                            <mml:mi>h</mml:mi>
                          </mml:mrow>
                          <mml:mrow>
                            <mml:mi>t</mml:mi>
                            <mml:mi>x</mml:mi>
                          </mml:mrow>
                        </mml:msubsup>
                      </mml:mrow>
                      <mml:mo>/</mml:mo>
                      <mml:mrow>
                        <mml:msub>
                          <mml:mi>B</mml:mi>
                          <mml:mi>i</mml:mi>
                        </mml:msub>
                      </mml:mrow>
                    </mml:mrow>
                  </mml:mrow>
                  <mml:mo>)</mml:mo>
                </mml:mrow>
              </mml:mrow>
            </mml:mfrac>
          </mml:mrow>
        </mml:math>
      </disp-formula>
      <disp-formula id="FD11">
        <mml:math>
          <mml:mrow>
            <mml:msubsup>
              <mml:mover accent="true">
                <mml:mi>E</mml:mi>
                <mml:mo>˜</mml:mo>
              </mml:mover>
              <mml:mi>g</mml:mi>
              <mml:mi>g</mml:mi>
            </mml:msubsup>
            <mml:mo>=</mml:mo>
            <mml:mfrac>
              <mml:mrow>
                <mml:mrow>
                  <mml:mrow>
                    <mml:msubsup>
                      <mml:mi>E</mml:mi>
                      <mml:mi>g</mml:mi>
                      <mml:mrow>
                        <mml:mi>g</mml:mi>
                        <mml:mi>w</mml:mi>
                      </mml:mrow>
                    </mml:msubsup>
                  </mml:mrow>
                  <mml:mo>/</mml:mo>
                  <mml:mrow>
                    <mml:msub>
                      <mml:mi>G</mml:mi>
                      <mml:mi>g</mml:mi>
                    </mml:msub>
                  </mml:mrow>
                </mml:mrow>
              </mml:mrow>
              <mml:mrow>
                <mml:msub>
                  <mml:mrow>
                    <mml:mtext>median</mml:mtext>
                  </mml:mrow>
                  <mml:mi>h</mml:mi>
                </mml:msub>
                <mml:mrow>
                  <mml:mo>(</mml:mo>
                  <mml:mrow>
                    <mml:mrow>
                      <mml:mrow>
                        <mml:msubsup>
                          <mml:mi>E</mml:mi>
                          <mml:mi>h</mml:mi>
                          <mml:mrow>
                            <mml:mi>g</mml:mi>
                            <mml:mi>w</mml:mi>
                          </mml:mrow>
                        </mml:msubsup>
                      </mml:mrow>
                      <mml:mo>/</mml:mo>
                      <mml:mrow>
                        <mml:msub>
                          <mml:mi>G</mml:mi>
                          <mml:mi>h</mml:mi>
                        </mml:msub>
                      </mml:mrow>
                    </mml:mrow>
                  </mml:mrow>
                  <mml:mo>)</mml:mo>
                </mml:mrow>
              </mml:mrow>
            </mml:mfrac>
          </mml:mrow>
        </mml:math>
      </disp-formula>
      <disp-formula id="FD12">
        <mml:math>
          <mml:mrow>
            <mml:msub>
              <mml:mi>E</mml:mi>
              <mml:mrow>
                <mml:mi>i</mml:mi>
                <mml:mo>,</mml:mo>
                <mml:mi>g</mml:mi>
              </mml:mrow>
            </mml:msub>
            <mml:mo>=</mml:mo>
            <mml:mn>0.55</mml:mn>
            <mml:msubsup>
              <mml:mover accent="true">
                <mml:mi>E</mml:mi>
                <mml:mo>˜</mml:mo>
              </mml:mover>
              <mml:mrow>
                <mml:mi>i</mml:mi>
                <mml:mo>,</mml:mo>
                <mml:mi>g</mml:mi>
              </mml:mrow>
              <mml:mi>s</mml:mi>
            </mml:msubsup>
            <mml:mo>+</mml:mo>
            <mml:mn>0.45</mml:mn>
            <mml:msubsup>
              <mml:mover accent="true">
                <mml:mi>E</mml:mi>
                <mml:mo>˜</mml:mo>
              </mml:mover>
              <mml:mi>g</mml:mi>
              <mml:mi>g</mml:mi>
            </mml:msubsup>
          </mml:mrow>
        </mml:math>
      </disp-formula>
      <disp-formula id="FD13">
        <label>(4)</label>
        <mml:math>
          <mml:mrow>
            <mml:mi>J</mml:mi>
            <mml:mrow>
              <mml:mo>(</mml:mo>
              <mml:mrow>
                <mml:mi>i</mml:mi>
                <mml:mo>,</mml:mo>
                <mml:mi>g</mml:mi>
              </mml:mrow>
              <mml:mo>)</mml:mo>
            </mml:mrow>
            <mml:mo>=</mml:mo>
            <mml:mn>0.34</mml:mn>
            <mml:msub>
              <mml:mover accent="true">
                <mml:mi>L</mml:mi>
                <mml:mo>^</mml:mo>
              </mml:mover>
              <mml:mrow>
                <mml:mi>i</mml:mi>
                <mml:mo>,</mml:mo>
                <mml:mi>g</mml:mi>
              </mml:mrow>
            </mml:msub>
            <mml:mo>+</mml:mo>
            <mml:mn>0.26</mml:mn>
            <mml:msub>
              <mml:mi>E</mml:mi>
              <mml:mrow>
                <mml:mi>i</mml:mi>
                <mml:mo>,</mml:mo>
                <mml:mi>g</mml:mi>
              </mml:mrow>
            </mml:msub>
            <mml:mo>+</mml:mo>
            <mml:mn>0.40</mml:mn>
            <mml:mrow>
              <mml:mo>(</mml:mo>
              <mml:mrow>
                <mml:mn>1</mml:mn>
                <mml:mo>−</mml:mo>
                <mml:msub>
                  <mml:mi>q</mml:mi>
                  <mml:mi>g</mml:mi>
                </mml:msub>
              </mml:mrow>
              <mml:mo>)</mml:mo>
            </mml:mrow>
          </mml:mrow>
        </mml:math>
      </disp-formula>
      <p>Full JTES uses weights 0.34 and 0.26 split across the two energy ratios, and 0.40 for trust after within-task normalization.</p>
      <p>The Energy-only baseline minimizes actual residual-energy burdens plus a small queue term. It no longer substitutes distance for residual energy. <bold>Table 3</bold> defines every ablation.</p>
    </sec>
    <sec id="sec6">
      <title>6. Experimental Design and Statistics</title>
      <p><bold>Table 4</bold> describes the executed design. Task identities, gateway availability, result corruption draws, work sizes, and validator draws are generated once for a seed-compromise scenario and reused across policies.</p>
      <p><bold>Table 3.</bold> Schedulers and ablations.</p>
      <table-wrap id="tbl3">
        <label>Table 3</label>
        <table>
          <tbody>
            <tr>
              <td>
                <bold>Scheduler</bold>
              </td>
              <td>
                <bold>Trust statistic</bold>
              </td>
              <td>
                <bold>Energy state</bold>
              </td>
              <td>
                <bold>Replication</bold>
              </td>
            </tr>
            <tr>
              <td>Nearest active</td>
              <td>None</td>
              <td>None</td>
              <td>None</td>
            </tr>
            <tr>
              <td>Energy only</td>
              <td>None</td>
              <td>Sensor and gateway</td>
              <td>None</td>
            </tr>
            <tr>
              <td>Trust only</td>
              <td>5th percentile</td>
              <td>None</td>
              <td>Selective</td>
            </tr>
            <tr>
              <td>Full JTES</td>
              <td>5th percentile</td>
              <td>Sensor and gateway</td>
              <td>Selective</td>
            </tr>
            <tr>
              <td>No selective validation</td>
              <td>5th percentile</td>
              <td>Sensor and gateway</td>
              <td>Challenges only</td>
            </tr>
            <tr>
              <td>Posterior mean</td>
              <td>Mean</td>
              <td>Sensor and gateway</td>
              <td>Selective</td>
            </tr>
            <tr>
              <td>Always replicate</td>
              <td>5th percentile</td>
              <td>Sensor and gateway</td>
              <td>Every task</td>
            </tr>
          </tbody>
        </table>
      </table-wrap>
      <p><bold>Table 4.</bold> Executed design.</p>
      <table-wrap id="tbl4">
        <label>Table 4</label>
        <table>
          <tbody>
            <tr>
              <td>
                <bold>Factor</bold>
              </td>
              <td>
                <bold>Values</bold>
              </td>
            </tr>
            <tr>
              <td>Seeds</td>
              <td>24, numbered 3001 - 3024</td>
            </tr>
            <tr>
              <td>Tasks</td>
              <td>8000 per simulated day</td>
            </tr>
            <tr>
              <td>Compromise probabilities</td>
              <td>0%, 5%, 10%, 15%, 20%</td>
            </tr>
            <tr>
              <td>Schedulers</td>
              <td>7</td>
            </tr>
            <tr>
              <td>Main records</td>
              <td>840</td>
            </tr>
            <tr>
              <td>Validator sensitivity</td>
              <td>72 records</td>
            </tr>
            <tr>
              <td>Primary outcomes</td>
              <td>Clean timely completion; accepted bad results; energy</td>
            </tr>
            <tr>
              <td>Task source</td>
              <td>Uniform random sensor among 400</td>
            </tr>
            <tr>
              <td>Critical-task probability</td>
              <td>22%</td>
            </tr>
            <tr>
              <td>Known-answer challenge probability</td>
              <td>3%</td>
            </tr>
            <tr>
              <td>Workload</td>
              <td>U(25, 65) million cycles</td>
            </tr>
            <tr>
              <td>Deadline</td>
              <td>150 ms with 25% probability; otherwise 220 ms</td>
            </tr>
            <tr>
              <td>Gateway availability</td>
              <td>Independent per arrival; active probabilities 0.92, 0.88, 0.91, 0.86, 0.90, 0.87</td>
            </tr>
            <tr>
              <td>Compromised-result probability</td>
              <td>68% per execution on a compromised gateway</td>
            </tr>
            <tr>
              <td>Selective replication</td>
              <td>
                Critical task and primary lower trust bound
                <italic>q</italic>
                <italic>
                  <sub>g</sub>
                </italic>
                &lt; 0.90
              </td>
            </tr>
            <tr>
              <td>Beta refresh</td>
              <td>After 50 new validations per gateway</td>
            </tr>
          </tbody>
        </table>
      </table-wrap>
      <sec id="sec6dot1">
        <title>Outcome Metric Definitions</title>
        <p>Clean timely completion is defined over all 8000 task arrivals:</p>
        <disp-formula id="FD14">
          <mml:math>
            <mml:mrow>
              <mml:msub>
                <mml:mi>R</mml:mi>
                <mml:mrow>
                  <mml:mtext>clean</mml:mtext>
                  <mml:mo>,</mml:mo>
                  <mml:mtext>timely</mml:mtext>
                </mml:mrow>
              </mml:msub>
              <mml:mo>=</mml:mo>
              <mml:mn>100</mml:mn>
              <mml:mfrac>
                <mml:mrow>
                  <mml:msub>
                    <mml:mi>N</mml:mi>
                    <mml:mrow>
                      <mml:mtext>clean</mml:mtext>
                      <mml:mo>,</mml:mo>
                      <mml:mtext>timely</mml:mtext>
                    </mml:mrow>
                  </mml:msub>
                </mml:mrow>
                <mml:mrow>
                  <mml:mn>8000</mml:mn>
                </mml:mrow>
              </mml:mfrac>
              <mml:mo>.</mml:mo>
            </mml:mrow>
          </mml:math>
        </disp-formula>
        <p>A task contributes to <inline-formula><mml:math><mml:mrow><mml:msub><mml:mi> N </mml:mi><mml:mrow><mml:mtext> clean </mml:mtext><mml:mo> , </mml:mo><mml:mtext> timely </mml:mtext></mml:mrow></mml:msub></mml:mrow></mml:math></inline-formula> only when at least one execution succeeds, the final accepted result is clean, and the modeled task latency does not exceed its assigned deadline. Tasks with no active gateway, no successful execution, an accepted corrupted result, or a missed deadline remain in the denominator and therefore count as non-clean-timely.</p>
        <p>Accepted bad results are defined only among completed tasks:</p>
        <disp-formula id="FD15">
          <mml:math>
            <mml:mrow>
              <mml:msub>
                <mml:mi>R</mml:mi>
                <mml:mrow>
                  <mml:mtext>bad</mml:mtext>
                </mml:mrow>
              </mml:msub>
              <mml:mo>=</mml:mo>
              <mml:mn>100</mml:mn>
              <mml:mfrac>
                <mml:mrow>
                  <mml:msub>
                    <mml:mi>N</mml:mi>
                    <mml:mrow>
                      <mml:mtext>accepted bad</mml:mtext>
                    </mml:mrow>
                  </mml:msub>
                </mml:mrow>
                <mml:mrow>
                  <mml:msub>
                    <mml:mi>N</mml:mi>
                    <mml:mrow>
                      <mml:mtext>completed</mml:mtext>
                    </mml:mrow>
                  </mml:msub>
                </mml:mrow>
              </mml:mfrac>
              <mml:mo>,</mml:mo>
            </mml:mrow>
          </mml:math>
        </disp-formula>
        <p>where a completed task is one for which at least one gateway execution succeeds. Tasks with no successful execution are excluded from the accepted-bad denominator because no result is accepted. Validation failures or missing replica results do not create a separate denominator; they affect reputation evidence and final-result resolution as described in Section 4.3.</p>
        <p>Paired 95% confidence intervals use seed-level differences. Paired comparisons use two-sided Student-<italic>t</italic> confidence intervals over the 24 seed-level paired differences, with <inline-formula><mml:math><mml:mrow><mml:mi> d </mml:mi><mml:mi> f </mml:mi><mml:mo> = </mml:mo><mml:mn> 23 </mml:mn></mml:mrow></mml:math></inline-formula> and <inline-formula><mml:math><mml:mrow><mml:msub><mml:mi> t </mml:mi><mml:mrow><mml:mn> 0.975 </mml:mn><mml:mo> , </mml:mo><mml:mn> 23 </mml:mn></mml:mrow></mml:msub><mml:mo> = </mml:mo><mml:mn> 2.069 </mml:mn></mml:mrow></mml:math></inline-formula> . Policy-level intervals likewise use the Student-<italic>t</italic> distribution across the 24 seed outcomes. Lifetime is computed by Equation (5) from one-day drain, then summarized using the tenth percentile across devices within each trial.</p>
        <disp-formula id="FD16">
          <label>(5)</label>
          <mml:math>
            <mml:mrow>
              <mml:msubsup>
                <mml:mi>T</mml:mi>
                <mml:mi>i</mml:mi>
                <mml:mrow>
                  <mml:mi>s</mml:mi>
                  <mml:mi>e</mml:mi>
                  <mml:mi>n</mml:mi>
                  <mml:mi>s</mml:mi>
                  <mml:mi>o</mml:mi>
                  <mml:mi>r</mml:mi>
                </mml:mrow>
              </mml:msubsup>
              <mml:mo>=</mml:mo>
              <mml:mfrac>
                <mml:mrow>
                  <mml:msub>
                    <mml:mi>B</mml:mi>
                    <mml:mrow>
                      <mml:mi>i</mml:mi>
                      <mml:mrow>
                        <mml:mo>(</mml:mo>
                        <mml:mn>0</mml:mn>
                        <mml:mo>)</mml:mo>
                      </mml:mrow>
                    </mml:mrow>
                  </mml:msub>
                </mml:mrow>
                <mml:mrow>
                  <mml:msub>
                    <mml:mi>B</mml:mi>
                    <mml:mrow>
                      <mml:mi>i</mml:mi>
                      <mml:mrow>
                        <mml:mo>(</mml:mo>
                        <mml:mn>0</mml:mn>
                        <mml:mo>)</mml:mo>
                      </mml:mrow>
                    </mml:mrow>
                  </mml:msub>
                  <mml:mo>−</mml:mo>
                  <mml:msub>
                    <mml:mi>B</mml:mi>
                    <mml:mrow>
                      <mml:mi>i</mml:mi>
                      <mml:mrow>
                        <mml:mo>(</mml:mo>
                        <mml:mrow>
                          <mml:mn>1</mml:mn>
                          <mml:mtext>day</mml:mtext>
                        </mml:mrow>
                        <mml:mo>)</mml:mo>
                      </mml:mrow>
                    </mml:mrow>
                  </mml:msub>
                </mml:mrow>
              </mml:mfrac>
              <mml:mo>;</mml:mo>
              <mml:mtext>
              </mml:mtext>
              <mml:msubsup>
                <mml:mi>T</mml:mi>
                <mml:mi>g</mml:mi>
                <mml:mrow>
                  <mml:mi>g</mml:mi>
                  <mml:mi>w</mml:mi>
                </mml:mrow>
              </mml:msubsup>
              <mml:mo>=</mml:mo>
              <mml:mfrac>
                <mml:mrow>
                  <mml:msub>
                    <mml:mi>G</mml:mi>
                    <mml:mrow>
                      <mml:mi>g</mml:mi>
                      <mml:mrow>
                        <mml:mo>(</mml:mo>
                        <mml:mn>0</mml:mn>
                        <mml:mo>)</mml:mo>
                      </mml:mrow>
                    </mml:mrow>
                  </mml:msub>
                </mml:mrow>
                <mml:mrow>
                  <mml:msub>
                    <mml:mi>G</mml:mi>
                    <mml:mrow>
                      <mml:mi>g</mml:mi>
                      <mml:mrow>
                        <mml:mo>(</mml:mo>
                        <mml:mn>0</mml:mn>
                        <mml:mo>)</mml:mo>
                      </mml:mrow>
                    </mml:mrow>
                  </mml:msub>
                  <mml:mo>−</mml:mo>
                  <mml:msub>
                    <mml:mi>G</mml:mi>
                    <mml:mrow>
                      <mml:mi>g</mml:mi>
                      <mml:mrow>
                        <mml:mo>(</mml:mo>
                        <mml:mrow>
                          <mml:mn>1</mml:mn>
                          <mml:mtext>day</mml:mtext>
                        </mml:mrow>
                        <mml:mo>)</mml:mo>
                      </mml:mrow>
                    </mml:mrow>
                  </mml:msub>
                </mml:mrow>
              </mml:mfrac>
              <mml:mo>.</mml:mo>
            </mml:mrow>
          </mml:math>
        </disp-formula>
        <p>The projection assumes that the simulated daily workload repeats unchanged. It is dimensionally in days but is not a warranty or battery-aging model.</p>
      </sec>
    </sec>
    <sec id="sec7">
      <title>7. Results</title>
      <sec id="sec7dot1">
        <title>7.1. Principal Integrity and Service Results</title>
        <p><xref ref-type="fig" rid="fig4">Figure 4</xref> compares all schedulers at 15% compromise. Full JTES achieved 94.80% clean timely completion (SD 3.21) and accepted 2.56% bad results (SD 3.17). Energy-only achieved 86.81% and accepted 11.32%.</p>
        <p>The paired full-minus-energy difference in clean timely completion was 7.99 points (95% paired <italic>t</italic>-CI 4.86 to 11.13); the accepted-bad difference was −8.76 points (95% paired <italic>t</italic>-CI −11.98 to −5.54).</p>
        <p><xref ref-type="fig" rid="fig5">Figure 5</xref> extends accepted corruption across the compromise sweep. The challenge-only ablation remains close to untrusted scheduling because sparse challenges cannot steer assignments quickly enough.</p>
      </sec>
      <sec id="sec7dot2">
        <title>7.2. Conservative Bound and Posterior Mean</title>
        <p>The Posterior Mean policy outperformed the 5th-percentile Full JTES policy on all three principal comparison metrics. Clean timely completion was 97.01% versus 94.80%, a full-minus-mean paired difference of −2.21 points (95% paired <italic>t</italic>-CI −3.01 to −1.41). Accepted bad results were 0.95% versus 2.56%, a difference of 1.61 points (95% paired <italic>t</italic>-CI 0.82 to 2.40). Sensor energy was 138.98 versus 199.34 mJ per completed task, a difference of 60.37 mJ (95% paired <italic>t</italic>-CI 48.76 to 71.97).</p>
        <fig id="fig4">
          <label>Figure 4</label>
          <graphic xlink:href="https://html.scirp.org/file/4000523-rId80.jpeg?20261023022109" />
        </fig>
        <p><bold>Figure 4.</bold> Clean timely completion and accepted bad results at 15% compromise with moderate validation.</p>
        <fig id="fig5">
          <label>Figure 5</label>
          <graphic xlink:href="https://html.scirp.org/file/4000523-rId81.jpeg?20261023022109" />
        </fig>
        <p><bold>Figure 5.</bold> Accepted bad results across all compromise probabilities.</p>
        <p>The conservative bound lowers scores for gateways with limited evidence and therefore encodes greater caution, but that caution did not provide a principal-scenario protection advantage after 8000 task arrivals. In this feedback-coupled scheduler, it increased exploration and validation cost and sometimes delayed concentration on reliable gateways. The 5th-percentile bound is therefore not universally superior; under sufficient accumulated evidence, it can sacrifice service, energy efficiency, and even observed integrity relative to posterior-mean ranking.</p>
      </sec>
      <sec id="sec7dot3">
        <title>7.3. Energy and Lifetime</title>
        <p><xref ref-type="fig" rid="fig6">Figure 6</xref> reports both energy domains. Full JTES used 199.34 mJ of sensor energy and 23.38 J of gateway energy per completed task. The paired sensor-energy difference from Energy-only was 111.03 mJ (95% paired <italic>t</italic>-CI 103.65 to 118.42).</p>
        <fig id="fig6">
          <label>Figure 6</label>
          <graphic xlink:href="https://html.scirp.org/file/4000523-rId82.jpeg?20261023022109" />
        </fig>
        <p><bold>Figure 6.</bold> Sensor and gateway energy per completed task in the principal scenario. Sensor bars are scaled in units of 100 mJ.</p>
        <p><xref ref-type="fig" rid="fig7">Figure 7</xref> applies the explicit one-day basis. Full JTES projected a sensor tenth-percentile lifetime of 2535.6 days and a gateway tenth-percentile lifetime of 29.5 days. These values assume identical daily repetition.</p>
      </sec>
      <sec id="sec7dot4">
        <title>7.4. Validator Sensitivity and Ablation</title>
        <p><xref ref-type="fig" rid="fig8">Figure 8</xref> shows validator sensitivity. Accepted bad results changed from 2.26% under strong validation to 3.64% under weak validation. The corresponding clean timely results were 95.00% and 93.96%.</p>
        <p><xref ref-type="fig" rid="fig9">Figure 9</xref> distinguishes attempted replication from realized validation evidence. The replication rate records tasks for which a second execution was dispatched, whereas the validation rate records tasks that produced observable validation evidence. Under Always Replicate, a second execution was dispatched for essentially every eligible task (99.99% on average), but only 93.32% of arrivals produced a validation event because some gateway executions failed and therefore did not yield two successful outcomes. Known-answer challenges can also create validation evidence when they produce a successful result. Thus, attempted replication and realized validation are intentionally different quantities.</p>
        <fig id="fig7">
          <label>Figure 7</label>
          <graphic xlink:href="https://html.scirp.org/file/4000523-rId83.jpeg?20261023022110" />
        </fig>
        <p><bold>Figure 7.</bold> Dimensionally calculated sensor and gateway lifetime projections from one simulated day of drain.</p>
        <fig id="fig8">
          <label>Figure 8</label>
          <graphic xlink:href="https://html.scirp.org/file/4000523-rId84.jpeg?20261023022110" />
        </fig>
        <p><bold>Figure 8.</bold> Full-JTES sensitivity to validator true-positive and false-positive error settings.</p>
        <fig id="fig9">
          <label>Figure 9</label>
          <graphic xlink:href="https://html.scirp.org/file/4000523-rId85.jpeg?20261023022109" />
        </fig>
        <p><bold>Figure 9.</bold> Validation and replication rates for all schedulers at 15% compromise.</p>
        <p><bold>Table 5</bold> consolidates the principal results and exposes the trade-off among integrity, service, energy, and projected lifetime.</p>
        <p><bold>Table 5.</bold> Principal scenario results.</p>
        <table-wrap id="tbl5">
          <label>Table 5</label>
          <table>
            <tbody>
              <tr>
                <td>
                  <bold>Policy</bold>
                </td>
                <td>
                  <bold>Clean timely mean ± SD (%)</bold>
                </td>
                <td>
                  <bold>Accepted bad (%)</bold>
                </td>
                <td>
                  <bold>Sensor</bold>
                  <bold>mJ</bold>
                  <bold>/task</bold>
                </td>
                <td>
                  <bold>Sensor P10 days</bold>
                </td>
              </tr>
              <tr>
                <td>Nearest active</td>
                <td>86.79 ± 10.23</td>
                <td>11.31 ± 10.50</td>
                <td>87.64 ± 2.73</td>
                <td>5658.4</td>
              </tr>
              <tr>
                <td>Energy only</td>
                <td>86.81 ± 10.20</td>
                <td>11.32 ± 10.46</td>
                <td>88.31 ± 2.73</td>
                <td>5624.7</td>
              </tr>
              <tr>
                <td>Trust only</td>
                <td>93.62 ± 4.12</td>
                <td>2.38 ± 3.16</td>
                <td>269.08 ± 62.87</td>
                <td>1876.6</td>
              </tr>
              <tr>
                <td>Full JTES</td>
                <td>94.80 ± 3.21</td>
                <td>2.56 ± 3.17</td>
                <td>199.34 ± 17.88</td>
                <td>2535.6</td>
              </tr>
              <tr>
                <td>No selective validation</td>
                <td>87.03 ± 9.76</td>
                <td>10.80 ± 10.04</td>
                <td>96.58 ± 8.91</td>
                <td>5227.8</td>
              </tr>
              <tr>
                <td>Posterior mean</td>
                <td>97.01 ± 1.38</td>
                <td>0.95 ± 1.38</td>
                <td>138.98 ± 35.57</td>
                <td>3749.9</td>
              </tr>
              <tr>
                <td>Always replicate</td>
                <td>99.16 ± 1.00</td>
                <td>0.69 ± 0.98</td>
                <td>504.60 ± 63.60</td>
                <td>1144.0</td>
              </tr>
            </tbody>
          </table>
        </table-wrap>
      </sec>
    </sec>
    <sec id="sec8">
      <title>8. Discussion</title>
      <p>The experiment supports an integrity-energy trade-off. Full JTES reduces accepted corruption relative to energy-only scheduling, but it uses more sensor energy because trust-aware placement often chooses a farther gateway and selective validation adds transmissions.</p>
      <p>Posterior-mean scheduling outperforms the conservative-bound variant on the reported principal service, integrity, and sensor-energy metrics. The lower bound discounts gateways with sparse evidence and can induce additional exploration and replication. Conservative ranking expresses epistemic caution, but the result shows that caution can sacrifice efficiency after sufficient reputation evidence accumulates and does not guarantee lower accepted corruption in a feedback-coupled scheduler.</p>
      <p>Always replication performs best on clean timely completion and accepted corruption but approximately doubles transmissions. Selective validation offers an intermediate operating point. Validator sensitivity confirms that trust quality is limited by the evidence mechanism, not only the Bayesian update.</p>
      <p>Robustness was examined along two independent axes already included in the experimental design. First, gateway compromise probability was varied from 0% to 20%, allowing the integrity trend to be evaluated as adversarial exposure increased. Second, validator quality was varied from strong to weak error settings. The resulting degradation in accepted corruption and clean-timely service shows that the qualitative trade-off is not confined to one validator setting. However, these sweeps remain bounded by the fixed workload, static daily compromise status, and simplified execution model, so they should be interpreted as simulation robustness rather than deployment robustness.</p>
      <p>From a deployment perspective, the results suggest that a conservative credible bound should not be selected automatically merely because it is statistically cautious. Posterior-mean ranking performed better after substantial evidence had accumulated, whereas conservative ranking imposed additional exploration and validation cost. A practical controller could therefore use more conservative trust treatment during cold start or high-consequence operation and transition toward posterior-mean ranking after sufficient validated evidence is available. The replication threshold, 50-observation trust-bound refresh interval, and validation intensity should be treated as operational control parameters whose values depend on available energy, gateway reliability, and application criticality.</p>
    </sec>
    <sec id="sec9">
      <title>9. Threats to Validity and Limitations</title>
      <p>The validator is represented by fixed true-positive and false-positive probabilities, gateway compromise is static within a day, and corrupted results are binary. Colluding gateways, targeted challenges, concept drift, and adversarial validators are not modeled.</p>
      <p>The radio and computational energy equations are simplified. Battery self-discharge, voltage effects, recharge, gateway cooling, and idle energy outside assigned tasks are excluded. Lifetime assumes daily repetition and should not be interpreted as a deployment forecast.</p>
      <p>The exact Beta lower bound is refreshed after 50 observed validations per gateway to limit controller cost. A shorter interval would react faster and require more computation. This interval should be evaluated on hardware.</p>
    </sec>
    <sec id="sec10">
      <title>10. Conclusion</title>
      <p>JTES updates trust only from imperfect observable validation and includes sensor and gateway residual energy in the scheduling score. At 15% compromise, the 5th-percentile Full JTES policy achieved 94.80% clean timely completion and accepted 2.56% bad results while consuming 199.34 mJ of sensor energy per completed task. Posterior-mean ranking performed better on these principal metrics, showing that conservative credible bounds can sacrifice efficiency after substantial evidence accumulates and are not universally superior. Validator degradation and the ablations show that evidence quality, replication, and trust-statistic choice jointly determine the operating point. These conclusions are limited to the simulated workload and validation model.</p>
    </sec>
    <sec id="sec11">
      <title>Data and Code Availability</title>
      <p>The study uses no proprietary or personal data. The complete simulation source, fixed random-seed ranges, seed-level result files, aggregated tables, and publication figures are included in the accompanying reproducibility package. The code regenerates all numerical results and figures reported in this manuscript.</p>
    </sec>
    <sec id="sec12">
      <title>Funding</title>
      <p>This research received no external funding.</p>
    </sec>
    <sec id="sec13">
      <title>Author Contributions</title>
      <p>Utham Kumar Anugula Sethupathy: Conceptualization, methodology, software, validation, formal analysis, investigation, data curation, writing of the original draft, review and editing, and visualization. Vijayanand Ananthanarayanan: Validation, formal analysis, and writing—review and editing.</p>
    </sec>
    <sec id="sec14">
      <title>Appendix: Reproduction Procedure</title>
      <p><bold>Table A1</bold> reports policy-level two-sided 95% Student-<italic>t</italic> confidence intervals across the 24 seeds for accepted corruption and both energy domains.</p>
      <p><bold>Table A1.</bold> Two-sided 95% confidence intervals across 24 seeds.</p>
      <table-wrap id="tbl6">
        <label>Table 6</label>
        <table>
          <tbody>
            <tr>
              <td>
                <bold>Policy</bold>
              </td>
              <td>
                <bold>Accepted bad (%)</bold>
              </td>
              <td>
                <bold>Sensor energy (</bold>
                <bold>mJ</bold>
                <bold>/task)</bold>
              </td>
              <td>
                <bold>Gateway energy (J/task)</bold>
              </td>
            </tr>
            <tr>
              <td>Nearest active</td>
              <td>6.87 - 15.74</td>
              <td>86.49 - 88.79</td>
              <td>21.96 - 22.01</td>
            </tr>
            <tr>
              <td>Energy only</td>
              <td>6.90 - 15.74</td>
              <td>87.15 - 89.46</td>
              <td>21.95 - 22.00</td>
            </tr>
            <tr>
              <td>Trust only</td>
              <td>1.04 - 3.71</td>
              <td>242.54 - 295.63</td>
              <td>23.31 - 23.71</td>
            </tr>
            <tr>
              <td>Full JTES</td>
              <td>1.22 - 3.90</td>
              <td>191.79 - 206.89</td>
              <td>23.20 - 23.55</td>
            </tr>
            <tr>
              <td>No selective validation</td>
              <td>6.56 - 15.04</td>
              <td>92.82 - 100.34</td>
              <td>22.08 - 22.16</td>
            </tr>
            <tr>
              <td>Posterior mean</td>
              <td>0.37 - 1.53</td>
              <td>123.96 - 154.00</td>
              <td>22.99 - 23.20</td>
            </tr>
            <tr>
              <td>Always replicate</td>
              <td>0.28 - 1.11</td>
              <td>477.74 - 531.46</td>
              <td>43.57 - 43.79</td>
            </tr>
          </tbody>
        </table>
      </table-wrap>
      <p>Run the supplied Python file using the following command: python run_experiments.py --study ait. The script writes all 840 main records, 72 validator-sensitivity records, summaries, figures, confidence intervals, and the experiment manifest; <bold>Table A2</bold> lists the expected checks.</p>
      <p><bold>Table A2</bold><bold>.</bold> Reproduction checks.</p>
      <table-wrap id="tbl7">
        <label>Table 7</label>
        <table>
          <tbody>
            <tr>
              <td>
                <bold>Check</bold>
              </td>
              <td>
                <bold>Expected value</bold>
              </td>
            </tr>
            <tr>
              <td>Seed range</td>
              <td>3001 - 3024</td>
            </tr>
            <tr>
              <td>Main records</td>
              <td>840</td>
            </tr>
            <tr>
              <td>Sensitivity records</td>
              <td>72</td>
            </tr>
            <tr>
              <td>Trust updates without validation</td>
              <td>Zero by construction</td>
            </tr>
            <tr>
              <td>Workload time basis</td>
              <td>8000 arrivals per day</td>
            </tr>
            <tr>
              <td>Beta statistic</td>
              <td>Numerical 5th percentile</td>
            </tr>
          </tbody>
        </table>
      </table-wrap>
    </sec>
  </body>
  <back>
    <ref-list>
      <title>References</title>
      <ref id="B1">
        <label>1.</label>
        <citation-alternatives>
          <mixed-citation publication-type="other">Bormann, C., Ersue, M. and Keranen, A. (2014) RFC 7228: Terminology for Constrained-Node Networks. https://doi.org/10.17487/RFC7228 <pub-id pub-id-type="doi">10.17487/RFC7228</pub-id><ext-link ext-link-type="uri" xlink:href="https://doi.org/10.17487/RFC7228">https://doi.org/10.17487/RFC7228</ext-link></mixed-citation>
          <element-citation publication-type="other">
            <person-group person-group-type="author">
              <string-name>Bormann, C.</string-name>
              <string-name>Ersue, M.</string-name>
              <string-name>Keranen, A.</string-name>
            </person-group>
            <year>2014</year>
            <article-title>RFC 7228: Terminology for Constrained-Node Networks</article-title>
            <pub-id pub-id-type="doi">10.17487/RFC7228</pub-id>
          </element-citation>
        </citation-alternatives>
      </ref>
      <ref id="B2">
        <label>2.</label>
        <citation-alternatives>
          <mixed-citation publication-type="other">Fagan, M., Megas, K.N., Scarfone, K. and Smith, M. (2020) NISTIR 8259A: IoT Device Cybersecurity Capability Core Baseline. https://doi.org/10.6028/NIST.IR.8259A <pub-id pub-id-type="doi">10.6028/NIST.IR.8259A</pub-id><ext-link ext-link-type="uri" xlink:href="https://doi.org/10.6028/NIST.IR.8259A">https://doi.org/10.6028/NIST.IR.8259A</ext-link></mixed-citation>
          <element-citation publication-type="other">
            <person-group person-group-type="author">
              <string-name>Fagan, M.</string-name>
              <string-name>Megas, K.N.</string-name>
              <string-name>Scarfone, K.</string-name>
              <string-name>Smith, M.</string-name>
            </person-group>
            <year>2020</year>
            <article-title>NISTIR 8259A: IoT Device Cybersecurity Capability Core Baseline</article-title>
            <pub-id pub-id-type="doi">10.6028/NIST.IR.8259A</pub-id>
          </element-citation>
        </citation-alternatives>
      </ref>
      <ref id="B3">
        <label>3.</label>
        <citation-alternatives>
          <mixed-citation publication-type="web">ETSI (2020) Cyber Security for Consumer Internet of Things: Baseline Requirements. ETSI EN 303 645 V2.1.1. https://www.etsi.org/deliver/etsi_en/303600_303699/303645/02.01.01_60/en_303645v020101p.pdf</mixed-citation>
          <element-citation publication-type="web">
            <year>2020</year>
            <article-title>Cyber Security for Consumer Internet of Things: Baseline Requirements</article-title>
          </element-citation>
        </citation-alternatives>
      </ref>
      <ref id="B4">
        <label>4.</label>
        <citation-alternatives>
          <mixed-citation publication-type="other">Satyanarayanan, M. (2017) The Emergence of Edge Computing. <italic>Computer</italic>, 50, 30-39. https://doi.org/10.1109/mc.2017.9 <pub-id pub-id-type="doi">10.1109/mc.2017.9</pub-id><ext-link ext-link-type="uri" xlink:href="https://doi.org/10.1109/mc.2017.9">https://doi.org/10.1109/mc.2017.9</ext-link></mixed-citation>
          <element-citation publication-type="other">
            <person-group person-group-type="author">
              <string-name>Satyanarayanan, M.</string-name>
            </person-group>
            <year>2017</year>
            <article-title>The Emergence of Edge Computing</article-title>
            <source>Computer</source>
            <volume>50</volume>
            <pub-id pub-id-type="doi">10.1109/mc.2017.9</pub-id>
          </element-citation>
        </citation-alternatives>
      </ref>
      <ref id="B5">
        <label>5.</label>
        <citation-alternatives>
          <mixed-citation publication-type="journal">Shi, W., Cao, J., Zhang, Q., Li, Y. and Xu, L. (2016) Edge Computing: Vision and Challenges. <italic>IEEE Internet of Things Journal</italic>, 3, 637-646. https://doi.org/10.1109/jiot.2016.2579198 <pub-id pub-id-type="doi">10.1109/jiot.2016.2579198</pub-id><ext-link ext-link-type="uri" xlink:href="https://doi.org/10.1109/jiot.2016.2579198">https://doi.org/10.1109/jiot.2016.2579198</ext-link></mixed-citation>
          <element-citation publication-type="journal">
            <person-group person-group-type="author">
              <string-name>Shi, W.</string-name>
              <string-name>Cao, J.</string-name>
              <string-name>Zhang, Q.</string-name>
              <string-name>Li, Y.</string-name>
              <string-name>Xu, L.</string-name>
            </person-group>
            <year>2016</year>
            <article-title>Edge Computing: Vision and Challenges</article-title>
            <source>IEEE Internet of Things Journal</source>
            <volume>3</volume>
            <pub-id pub-id-type="doi">10.1109/jiot.2016.2579198</pub-id>
          </element-citation>
        </citation-alternatives>
      </ref>
      <ref id="B6">
        <label>6.</label>
        <citation-alternatives>
          <mixed-citation publication-type="confproc">Bonomi, F., Milito, R., Zhu, J. and Addepalli, S. (2012) Fog Computing and Its Role in the Internet of Things. <italic>Proceedings of the First Edition of the MCC Workshop on Mobile Cloud Computing</italic>, Helsinki, 17 August 2012, 13-16. https://doi.org/10.1145/2342509.2342513 <pub-id pub-id-type="doi">10.1145/2342509.2342513</pub-id><ext-link ext-link-type="uri" xlink:href="https://doi.org/10.1145/2342509.2342513">https://doi.org/10.1145/2342509.2342513</ext-link></mixed-citation>
          <element-citation publication-type="confproc">
            <person-group person-group-type="author">
              <string-name>Bonomi, F.</string-name>
              <string-name>Milito, R.</string-name>
              <string-name>Zhu, J.</string-name>
              <string-name>Addepalli, S.</string-name>
              <string-name>Computing, H</string-name>
            </person-group>
            <year>2012</year>
            <article-title>Fog Computing and Its Role in the Internet of Things</article-title>
            <source>Proceedings of the First Edition of the MCC Workshop on Mobile Cloud Computing</source>
            <volume>17</volume>
            <pub-id pub-id-type="doi">10.1145/2342509.2342513</pub-id>
          </element-citation>
        </citation-alternatives>
      </ref>
      <ref id="B7">
        <label>7.</label>
        <citation-alternatives>
          <mixed-citation publication-type="confproc">Ismail, R. and Josang, A. (2002) The Beta Reputation System. <italic>BLED</italic> 2002 <italic>Proceedi</italic><italic>ngs</italic>, Bled, 17-19 June 2002, Article 41. https://aisel.aisnet.org/bled2002/41/</mixed-citation>
          <element-citation publication-type="confproc">
            <person-group person-group-type="author">
              <string-name>Ismail, R.</string-name>
              <string-name>Josang, A.</string-name>
              <string-name>Proceedings, B</string-name>
            </person-group>
            <year>2002</year>
            <article-title>The Beta Reputation System</article-title>
            <source>BLED 2002 Proceedings</source>
            <volume>17</volume>
            <elocation-id>41</elocation-id>
          </element-citation>
        </citation-alternatives>
      </ref>
      <ref id="B8">
        <label>8.</label>
        <citation-alternatives>
          <mixed-citation publication-type="confproc">Kamvar, S.D., Schlosser, M.T. and Garcia-Molina, H. (2003) The Eigentrust Algorithm for Reputation Management in P2P Networks. <italic>Proceedings of the Twelfth Internat</italic><italic>ional Conference on World Wide Web</italic>, Budapest, 20-24 May 2003, 640-651. https://doi.org/10.1145/775152.775242 <pub-id pub-id-type="doi">10.1145/775152.775242</pub-id><ext-link ext-link-type="uri" xlink:href="https://doi.org/10.1145/775152.775242">https://doi.org/10.1145/775152.775242</ext-link></mixed-citation>
          <element-citation publication-type="confproc">
            <person-group person-group-type="author">
              <string-name>Kamvar, S.D.</string-name>
              <string-name>Schlosser, M.T.</string-name>
              <string-name>Garcia-Molina, H.</string-name>
              <string-name>Web, B</string-name>
            </person-group>
            <year>2003</year>
            <article-title>The Eigentrust Algorithm for Reputation Management in P2P Networks</article-title>
            <source>Proceedings of the Twelfth International Conference on World Wide Web</source>
            <volume>20</volume>
            <pub-id pub-id-type="doi">10.1145/775152.775242</pub-id>
          </element-citation>
        </citation-alternatives>
      </ref>
      <ref id="B9">
        <label>9.</label>
        <citation-alternatives>
          <mixed-citation publication-type="other">Ganeriwal, S., Balzano, L.K. and Srivastava, M.B. (2008) Reputation-Based Framework for High Integrity Sensor Networks. <italic>ACM Transactions on Sensor Networks</italic>, 4, 1-37. https://doi.org/10.1145/1362542.1362546 <pub-id pub-id-type="doi">10.1145/1362542.1362546</pub-id><ext-link ext-link-type="uri" xlink:href="https://doi.org/10.1145/1362542.1362546">https://doi.org/10.1145/1362542.1362546</ext-link></mixed-citation>
          <element-citation publication-type="other">
            <person-group person-group-type="author">
              <string-name>Ganeriwal, S.</string-name>
              <string-name>Balzano, L.K.</string-name>
              <string-name>Srivastava, M.B.</string-name>
            </person-group>
            <year>2008</year>
            <article-title>Reputation-Based Framework for High Integrity Sensor Networks</article-title>
            <source>ACM Transactions on Sensor Networks</source>
            <volume>4</volume>
            <pub-id pub-id-type="doi">10.1145/1362542.1362546</pub-id>
          </element-citation>
        </citation-alternatives>
      </ref>
      <ref id="B10">
        <label>10.</label>
        <citation-alternatives>
          <mixed-citation publication-type="confproc">Heinzelman, W.R., Chandrakasan, A. and Balakrishnan, H. (2000) Energy-Efficient Communication Protocol for Wireless Microsensor Networks. <italic>Proceedings of t</italic><italic>he</italic> 33 <italic>rd Annual Hawaii International Conference on System Sciences</italic>, Maui, 7 January 2000, 10. https://doi.org/10.1109/hicss.2000.926982 <pub-id pub-id-type="doi">10.1109/hicss.2000.926982</pub-id><ext-link ext-link-type="uri" xlink:href="https://doi.org/10.1109/hicss.2000.926982">https://doi.org/10.1109/hicss.2000.926982</ext-link></mixed-citation>
          <element-citation publication-type="confproc">
            <person-group person-group-type="author">
              <string-name>Heinzelman, W.R.</string-name>
              <string-name>Chandrakasan, A.</string-name>
              <string-name>Balakrishnan, H.</string-name>
              <string-name>Sciences, M</string-name>
            </person-group>
            <year>2000</year>
            <article-title>Energy-Efficient Communication Protocol for Wireless Microsensor Networks</article-title>
            <source>Proceedings of the 33rd Annual Hawaii International Conference on System Sciences</source>
            <volume>7</volume>
            <pub-id pub-id-type="doi">10.1109/hicss.2000.926982</pub-id>
          </element-citation>
        </citation-alternatives>
      </ref>
      <ref id="B11">
        <label>11.</label>
        <citation-alternatives>
          <mixed-citation publication-type="other">Yick, J., Mukherjee, B. and Ghosal, D. (2008) Wireless Sensor Network Survey. <italic>Computer Networks</italic>, 52, 2292-2330. https://doi.org/10.1016/j.comnet.2008.04.002 <pub-id pub-id-type="doi">10.1016/j.comnet.2008.04.002</pub-id><ext-link ext-link-type="uri" xlink:href="https://doi.org/10.1016/j.comnet.2008.04.002">https://doi.org/10.1016/j.comnet.2008.04.002</ext-link></mixed-citation>
          <element-citation publication-type="other">
            <person-group person-group-type="author">
              <string-name>Yick, J.</string-name>
              <string-name>Mukherjee, B.</string-name>
              <string-name>Ghosal, D.</string-name>
            </person-group>
            <year>2008</year>
            <article-title>Wireless Sensor Network Survey</article-title>
            <source>Computer Networks</source>
            <volume>52</volume>
            <pub-id pub-id-type="doi">10.1016/j.comnet.2008.04.002</pub-id>
          </element-citation>
        </citation-alternatives>
      </ref>
      <ref id="B12">
        <label>12.</label>
        <citation-alternatives>
          <mixed-citation publication-type="other">Shelby, Z., Hartke, K. and Bormann, C. (2014) RFC 7252: The Constrained Application Protocol. https://doi.org/10.17487/RFC7252 <pub-id pub-id-type="doi">10.17487/RFC7252</pub-id><ext-link ext-link-type="uri" xlink:href="https://doi.org/10.17487/RFC7252">https://doi.org/10.17487/RFC7252</ext-link></mixed-citation>
          <element-citation publication-type="other">
            <person-group person-group-type="author">
              <string-name>Shelby, Z.</string-name>
              <string-name>Hartke, K.</string-name>
              <string-name>Bormann, C.</string-name>
            </person-group>
            <year>2014</year>
            <article-title>RFC 7252: The Constrained Application Protocol</article-title>
            <pub-id pub-id-type="doi">10.17487/RFC7252</pub-id>
          </element-citation>
        </citation-alternatives>
      </ref>
      <ref id="B13">
        <label>13.</label>
        <citation-alternatives>
          <mixed-citation publication-type="other">Selander, G., Mattsson, J.P., Palombini, F. and Seitz, L. (2019) RFC 8613: Object Security for Constrained RESTful Environments. https://doi.org/10.17487/RFC8613 <pub-id pub-id-type="doi">10.17487/RFC8613</pub-id><ext-link ext-link-type="uri" xlink:href="https://doi.org/10.17487/RFC8613">https://doi.org/10.17487/RFC8613</ext-link></mixed-citation>
          <element-citation publication-type="other">
            <person-group person-group-type="author">
              <string-name>Selander, G.</string-name>
              <string-name>Mattsson, J.P.</string-name>
              <string-name>Palombini, F.</string-name>
              <string-name>Seitz, L.</string-name>
            </person-group>
            <year>2019</year>
            <article-title>RFC 8613: Object Security for Constrained RESTful Environments</article-title>
            <pub-id pub-id-type="doi">10.17487/RFC8613</pub-id>
          </element-citation>
        </citation-alternatives>
      </ref>
      <ref id="B14">
        <label>14.</label>
        <citation-alternatives>
          <mixed-citation publication-type="confproc">Liu, A. and Ning, P. (2008) TinyECC: A Configurable Library for Elliptic Curve Cryptography in Wireless Sensor Networks. 2008 <italic>International Conference on Inform</italic><italic>ation Processing in Sensor Networks</italic> ( <italic>IPSN</italic>2008), St. Louis, 22-24 April 2008, 245-249. https://doi.org/10.1109/ipsn.2008.47 <pub-id pub-id-type="doi">10.1109/ipsn.2008.47</pub-id><ext-link ext-link-type="uri" xlink:href="https://doi.org/10.1109/ipsn.2008.47">https://doi.org/10.1109/ipsn.2008.47</ext-link></mixed-citation>
          <element-citation publication-type="confproc">
            <person-group person-group-type="author">
              <string-name>Liu, A.</string-name>
              <string-name>Ning, P.</string-name>
            </person-group>
            <year>2008</year>
            <article-title>TinyECC: A Configurable Library for Elliptic Curve Cryptography in Wireless Sensor Networks</article-title>
            <source>2008 International Conference on Information Processing in Sensor Networks (IPSN 2008)</source>
            <volume>22</volume>
            <pub-id pub-id-type="doi">10.1109/ipsn.2008.47</pub-id>
          </element-citation>
        </citation-alternatives>
      </ref>
      <ref id="B15">
        <label>15.</label>
        <citation-alternatives>
          <mixed-citation publication-type="other">Sicari, S., Rizzardi, A., Grieco, L.A. and Coen-Porisini, A. (2015) Security, Privacy and Trust in Internet of Things: The Road Ahead. <italic>Computer Networks</italic>, 76, 146-164. https://doi.org/10.1016/j.comnet.2014.11.008 <pub-id pub-id-type="doi">10.1016/j.comnet.2014.11.008</pub-id><ext-link ext-link-type="uri" xlink:href="https://doi.org/10.1016/j.comnet.2014.11.008">https://doi.org/10.1016/j.comnet.2014.11.008</ext-link></mixed-citation>
          <element-citation publication-type="other">
            <person-group person-group-type="author">
              <string-name>Sicari, S.</string-name>
              <string-name>Rizzardi, A.</string-name>
              <string-name>Grieco, L.A.</string-name>
              <string-name>Coen-Porisini, A.</string-name>
              <string-name>Security, P</string-name>
            </person-group>
            <year>2015</year>
            <article-title>Security, Privacy and Trust in Internet of Things: The Road Ahead</article-title>
            <source>Computer Networks</source>
            <volume>76</volume>
            <pub-id pub-id-type="doi">10.1016/j.comnet.2014.11.008</pub-id>
          </element-citation>
        </citation-alternatives>
      </ref>
      <ref id="B16">
        <label>16.</label>
        <citation-alternatives>
          <mixed-citation publication-type="other">Al-Fuqaha, A., Guizani, M., Mohammadi, M., Aledhari, M. and Ayyash, M. (2015) Internet of Things: A Survey on Enabling Technologies, Protocols, and Applications. <italic>IEEE Communications Surveys &amp; Tutorials</italic>, 17, 2347-2376. https://doi.org/10.1109/comst.2015.2444095 <pub-id pub-id-type="doi">10.1109/comst.2015.2444095</pub-id><ext-link ext-link-type="uri" xlink:href="https://doi.org/10.1109/comst.2015.2444095">https://doi.org/10.1109/comst.2015.2444095</ext-link></mixed-citation>
          <element-citation publication-type="other">
            <person-group person-group-type="author">
              <string-name>Al-Fuqaha, A.</string-name>
              <string-name>Guizani, M.</string-name>
              <string-name>Mohammadi, M.</string-name>
              <string-name>Aledhari, M.</string-name>
              <string-name>Ayyash, M.</string-name>
              <string-name>Technologies, P</string-name>
            </person-group>
            <year>2015</year>
            <article-title>Internet of Things: A Survey on Enabling Technologies, Protocols, and Applications</article-title>
            <source>IEEE Communications Surveys &amp; Tutorials</source>
            <volume>17</volume>
            <pub-id pub-id-type="doi">10.1109/comst.2015.2444095</pub-id>
          </element-citation>
        </citation-alternatives>
      </ref>
      <ref id="B17">
        <label>17.</label>
        <citation-alternatives>
          <mixed-citation publication-type="confproc">Paxson, V. and Floyd, S. (1997) Why We Don’t Know How to Simulate the Internet. <italic>Proceedings of the</italic> 29 <italic>th Conference on Winter Simulation</italic>, Atlanta, 7-10 December 1997, 1037-1044. https://doi.org/10.1145/268437.268737 <pub-id pub-id-type="doi">10.1145/268437.268737</pub-id><ext-link ext-link-type="uri" xlink:href="https://doi.org/10.1145/268437.268737">https://doi.org/10.1145/268437.268737</ext-link></mixed-citation>
          <element-citation publication-type="confproc">
            <person-group person-group-type="author">
              <string-name>Paxson, V.</string-name>
              <string-name>Floyd, S.</string-name>
              <string-name>Simulation, A</string-name>
            </person-group>
            <year>1997</year>
            <article-title>Why We Don’t Know How to Simulate the Internet</article-title>
            <source>Proceedings of the 29th Conference on Winter Simulation</source>
            <volume>7</volume>
            <pub-id pub-id-type="doi">10.1145/268437.268737</pub-id>
          </element-citation>
        </citation-alternatives>
      </ref>
      <ref id="B18">
        <label>18.</label>
        <citation-alternatives>
          <mixed-citation publication-type="other">Wang, X., Zhang, J., Chen, C., He, J., Ma, Y. and Guan, X. (2024) Trust-AoI-Aware Codesign of Scheduling and Control for Edge-Enabled IIoT Systems. <italic>IEEE Transactions on Industrial Informatics</italic>, 20, 2833-2842. https://doi.org/10.1109/tii.2023.3299040 <pub-id pub-id-type="doi">10.1109/tii.2023.3299040</pub-id><ext-link ext-link-type="uri" xlink:href="https://doi.org/10.1109/tii.2023.3299040">https://doi.org/10.1109/tii.2023.3299040</ext-link></mixed-citation>
          <element-citation publication-type="other">
            <person-group person-group-type="author">
              <string-name>Wang, X.</string-name>
              <string-name>Zhang, J.</string-name>
              <string-name>Chen, C.</string-name>
              <string-name>He, J.</string-name>
              <string-name>Ma, Y.</string-name>
              <string-name>Guan, X.</string-name>
            </person-group>
            <year>2024</year>
            <article-title>Trust-AoI-Aware Codesign of Scheduling and Control for Edge-Enabled IIoT Systems</article-title>
            <source>IEEE Transactions on Industrial Informatics</source>
            <volume>20</volume>
            <pub-id pub-id-type="doi">10.1109/tii.2023.3299040</pub-id>
          </element-citation>
        </citation-alternatives>
      </ref>
      <ref id="B19">
        <label>19.</label>
        <citation-alternatives>
          <mixed-citation publication-type="journal">Liu, T., Liu, J., Zhang, T., Wang, J., Yuan, Z., Xu, M., <italic>et al</italic>. (2024) Blockchain and Trusted Hardware-Enabled Data Scheduling for Edge Learning in Wireless IIoT. <italic>IEEE Internet of Things Journal</italic>, 11, 34229-34242. https://doi.org/10.1109/jiot.2024.3443642 <pub-id pub-id-type="doi">10.1109/jiot.2024.3443642</pub-id><ext-link ext-link-type="uri" xlink:href="https://doi.org/10.1109/jiot.2024.3443642">https://doi.org/10.1109/jiot.2024.3443642</ext-link></mixed-citation>
          <element-citation publication-type="journal">
            <person-group person-group-type="author">
              <string-name>Liu, T.</string-name>
              <string-name>Liu, J.</string-name>
              <string-name>Zhang, T.</string-name>
              <string-name>Wang, J.</string-name>
              <string-name>Yuan, Z.</string-name>
              <string-name>Xu, M.</string-name>
            </person-group>
            <year>2024</year>
            <article-title>Blockchain and Trusted Hardware-Enabled Data Scheduling for Edge Learning in Wireless IIoT</article-title>
            <source>IEEE Internet of Things Journal</source>
            <volume>11</volume>
            <pub-id pub-id-type="doi">10.1109/jiot.2024.3443642</pub-id>
          </element-citation>
        </citation-alternatives>
      </ref>
      <ref id="B20">
        <label>20.</label>
        <citation-alternatives>
          <mixed-citation publication-type="other">Baker, T., Al Aghbari, Z., Khedr, A.M., Ahmed, N. and Girija, S. (2024) EDITORS: Energy-Aware Dynamic Task Offloading Using Deep Reinforcement Transfer Learning in SDN-Enabled Edge Nodes. <italic>Internet of Things</italic>, 25, Article 101118. https://doi.org/10.1016/j.iot.2024.101118 <pub-id pub-id-type="doi">10.1016/j.iot.2024.101118</pub-id><ext-link ext-link-type="uri" xlink:href="https://doi.org/10.1016/j.iot.2024.101118">https://doi.org/10.1016/j.iot.2024.101118</ext-link></mixed-citation>
          <element-citation publication-type="other">
            <person-group person-group-type="author">
              <string-name>Baker, T.</string-name>
              <string-name>Aghbari, Z.</string-name>
              <string-name>Khedr, A.M.</string-name>
              <string-name>Ahmed, N.</string-name>
              <string-name>Girija, S.</string-name>
            </person-group>
            <year>2024</year>
            <article-title>EDITORS: Energy-Aware Dynamic Task Offloading Using Deep Reinforcement Transfer Learning in SDN-Enabled Edge Nodes</article-title>
            <source>Internet of Things</source>
            <volume>25</volume>
            <elocation-id>101118</elocation-id>
            <pub-id pub-id-type="doi">10.1016/j.iot.2024.101118</pub-id>
          </element-citation>
        </citation-alternatives>
      </ref>
      <ref id="B21">
        <label>21.</label>
        <citation-alternatives>
          <mixed-citation publication-type="other">Alsenani, Y. and Alnori, A.S. (2023) Trust-Aware Scheduling for Edge Computing with Task Dependencies and Unreliable Servers. <italic>IEEE Access</italic>, 11, 113514-113525. https://doi.org/10.1109/access.2023.3324178 <pub-id pub-id-type="doi">10.1109/access.2023.3324178</pub-id><ext-link ext-link-type="uri" xlink:href="https://doi.org/10.1109/access.2023.3324178">https://doi.org/10.1109/access.2023.3324178</ext-link></mixed-citation>
          <element-citation publication-type="other">
            <person-group person-group-type="author">
              <string-name>Alsenani, Y.</string-name>
              <string-name>Alnori, A.S.</string-name>
            </person-group>
            <year>2023</year>
            <article-title>Trust-Aware Scheduling for Edge Computing with Task Dependencies and Unreliable Servers</article-title>
            <source>IEEE Access</source>
            <volume>11</volume>
            <pub-id pub-id-type="doi">10.1109/access.2023.3324178</pub-id>
          </element-citation>
        </citation-alternatives>
      </ref>
      <ref id="B22">
        <label>22.</label>
        <citation-alternatives>
          <mixed-citation publication-type="other">Al-Masri, E., Souri, A., Mohamed, H., Yang, W., Olmsted, J. and Kotevska, O. (2023) Energy-Efficient Cooperative Resource Allocation and Task Scheduling for Internet of Things Environments. <italic>Internet of Things</italic>, 23, Article 100832. https://doi.org/10.1016/j.iot.2023.100832 <pub-id pub-id-type="doi">10.1016/j.iot.2023.100832</pub-id><ext-link ext-link-type="uri" xlink:href="https://doi.org/10.1016/j.iot.2023.100832">https://doi.org/10.1016/j.iot.2023.100832</ext-link></mixed-citation>
          <element-citation publication-type="other">
            <person-group person-group-type="author">
              <string-name>Al-Masri, E.</string-name>
              <string-name>Souri, A.</string-name>
              <string-name>Mohamed, H.</string-name>
              <string-name>Yang, W.</string-name>
              <string-name>Olmsted, J.</string-name>
              <string-name>Kotevska, O.</string-name>
            </person-group>
            <year>2023</year>
            <article-title>Energy-Efficient Cooperative Resource Allocation and Task Scheduling for Internet of Things Environments</article-title>
            <source>Internet of Things</source>
            <volume>23</volume>
            <elocation-id>100832</elocation-id>
            <pub-id pub-id-type="doi">10.1016/j.iot.2023.100832</pub-id>
          </element-citation>
        </citation-alternatives>
      </ref>
      <ref id="B23">
        <label>23.</label>
        <citation-alternatives>
          <mixed-citation publication-type="journal">Wang, Q., Wang, Q., Zhao, H., Zhang, H., Zhu, H. and Wang, X. (2024) Device-Specific QoE Enhancement through Joint Communication and Computation Resource Scheduling in Edge-Assisted IoT Systems. <italic>IEEE Internet of Things Journal</italic>, 11, 13257-13270. https://doi.org/10.1109/jiot.2023.3332401 <pub-id pub-id-type="doi">10.1109/jiot.2023.3332401</pub-id><ext-link ext-link-type="uri" xlink:href="https://doi.org/10.1109/jiot.2023.3332401">https://doi.org/10.1109/jiot.2023.3332401</ext-link></mixed-citation>
          <element-citation publication-type="journal">
            <person-group person-group-type="author">
              <string-name>Wang, Q.</string-name>
              <string-name>Wang, Q.</string-name>
              <string-name>Zhao, H.</string-name>
              <string-name>Zhang, H.</string-name>
              <string-name>Zhu, H.</string-name>
              <string-name>Wang, X.</string-name>
            </person-group>
            <year>2024</year>
            <article-title>Device-Specific QoE Enhancement through Joint Communication and Computation Resource Scheduling in Edge-Assisted IoT Systems</article-title>
            <source>IEEE Internet of Things Journal</source>
            <volume>11</volume>
            <pub-id pub-id-type="doi">10.1109/jiot.2023.3332401</pub-id>
          </element-citation>
        </citation-alternatives>
      </ref>
      <ref id="B24">
        <label>24.</label>
        <citation-alternatives>
          <mixed-citation publication-type="other">Xu, C., Lv, M., Zhang, K., Cao, K., Wang, G., Wei, M., <italic>et al</italic>. (2024) Energy Consumption and Time-Delay Optimization of Dependency-Aware Tasks Offloading for Industry 5.0 Applications. <italic>IEEE Transactions on Consumer Electronics</italic>, 70, 1590-1600. https://doi.org/10.1109/tce.2023.3338620 <pub-id pub-id-type="doi">10.1109/tce.2023.3338620</pub-id><ext-link ext-link-type="uri" xlink:href="https://doi.org/10.1109/tce.2023.3338620">https://doi.org/10.1109/tce.2023.3338620</ext-link></mixed-citation>
          <element-citation publication-type="other">
            <person-group person-group-type="author">
              <string-name>Xu, C.</string-name>
              <string-name>Lv, M.</string-name>
              <string-name>Zhang, K.</string-name>
              <string-name>Cao, K.</string-name>
              <string-name>Wang, G.</string-name>
              <string-name>Wei, M.</string-name>
            </person-group>
            <year>2024</year>
            <article-title>Energy Consumption and Time-Delay Optimization of Dependency-Aware Tasks Offloading for Industry 5</article-title>
            <source>0 Applications. IEEE Transactions on Consumer Electronics</source>
            <volume>70</volume>
            <pub-id pub-id-type="doi">10.1109/tce.2023.3338620</pub-id>
          </element-citation>
        </citation-alternatives>
      </ref>
      <ref id="B25">
        <label>25.</label>
        <citation-alternatives>
          <mixed-citation publication-type="other">Kaur, A. and Auluck, N. (2023) Real-Time Trust Aware Scheduling in Fog-Cloud Systems. <italic>Concurrency and Computation</italic>: <italic>Practice and Experience</italic>, 35, e7680. https://doi.org/10.1002/cpe.7680 <pub-id pub-id-type="doi">10.1002/cpe.7680</pub-id><ext-link ext-link-type="uri" xlink:href="https://doi.org/10.1002/cpe.7680">https://doi.org/10.1002/cpe.7680</ext-link></mixed-citation>
          <element-citation publication-type="other">
            <person-group person-group-type="author">
              <string-name>Kaur, A.</string-name>
              <string-name>Auluck, N.</string-name>
            </person-group>
            <year>2023</year>
            <article-title>Real-Time Trust Aware Scheduling in Fog-Cloud Systems</article-title>
            <source>Concurrency and Computation: Practice and Experience</source>
            <volume>35</volume>
            <pub-id pub-id-type="doi">10.1002/cpe.7680</pub-id>
          </element-citation>
        </citation-alternatives>
      </ref>
    </ref-list>
  </back>
</article>