<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE article PUBLIC "-//NLM//DTD JATS (Z39.96) Journal Publishing DTD v1.1 20151215//EN" "http://jats.nlm.nih.gov/publishing/1.1/JATS-journalpublishing1.dtd">
<article xmlns:xlink="http://www.w3.org/1999/xlink" xmlns:mml="http://www.w3.org/1998/Math/MathML" xml:lang="en" article-type="research-article" dtd-version="1.1">
<front>
<journal-meta>
<journal-id journal-id-type="pmc">CMC</journal-id>
<journal-id journal-id-type="nlm-ta">CMC</journal-id>
<journal-id journal-id-type="publisher-id">CMC</journal-id>
<journal-title-group>
<journal-title>Computers, Materials &#x0026; Continua</journal-title>
</journal-title-group>
<issn pub-type="epub">1546-2226</issn>
<issn pub-type="ppub">1546-2218</issn>
<publisher>
<publisher-name>Tech Science Press</publisher-name>
<publisher-loc>USA</publisher-loc>
</publisher>
</journal-meta>
<article-meta>
<article-id pub-id-type="publisher-id">66304</article-id>
<article-id pub-id-type="doi">10.32604/cmc.2025.066304</article-id>
<article-categories>
<subj-group subj-group-type="heading">
<subject>Article</subject>
</subj-group>
</article-categories>
<title-group>
<article-title>Efficient One-Way Time Synchronization for VANET with MLE-Based Multi-Stage Update</article-title>
<alt-title alt-title-type="left-running-head">Efficient One-Way Time Synchronization for VANET with MLE-Based Multi-Stage Update</alt-title>
<alt-title alt-title-type="right-running-head">Efficient One-Way Time Synchronization for VANET with MLE-Based Multi-Stage Update</alt-title>
</title-group>
<contrib-group>
<contrib id="author-1" contrib-type="author">
<name name-style="western"><surname>Joo</surname><given-names>Hyeontae</given-names></name></contrib>
<contrib id="author-2" contrib-type="author">
<name name-style="western"><surname>Lee</surname><given-names>Sangmin</given-names></name></contrib>
<contrib id="author-3" contrib-type="author">
<name name-style="western"><surname>Kim</surname><given-names>Kiseok</given-names></name></contrib>
<contrib id="author-4" contrib-type="author" corresp="yes">
<name name-style="western"><surname>Kim</surname><given-names>Hwangnam</given-names></name><email>hnkim@korea.ac.kr</email></contrib>
<aff id="aff-1"><institution>School of Electrical Engineering, Korea University</institution>, <addr-line>Seoul, 02841</addr-line>, <country>Republic of Korea</country></aff>
</contrib-group>
<author-notes>
<corresp id="cor1"><label>&#x002A;</label>Corresponding Author: Hwangnam Kim. Email: <email>hnkim@korea.ac.kr</email></corresp>
</author-notes>
<pub-date date-type="collection" publication-format="electronic">
<year>2025</year>
</pub-date>
<pub-date date-type="pub" publication-format="electronic">
<day>03</day><month>07</month><year>2025</year>
</pub-date>
<volume>84</volume>
<issue>2</issue>
<fpage>2789</fpage>
<lpage>2804</lpage>
<history>
<date date-type="received">
<day>04</day>
<month>4</month>
<year>2025</year>
</date>
<date date-type="accepted">
<day>19</day>
<month>5</month>
<year>2025</year>
</date>
</history>
<permissions>
<copyright-statement>&#x00A9; 2025 The Authors.</copyright-statement>
<copyright-year>2025</copyright-year>
<copyright-holder>Published by Tech Science Press.</copyright-holder>
<license xlink:href="https://creativecommons.org/licenses/by/4.0/">
<license-p>This work is licensed under a <ext-link ext-link-type="uri" xlink:type="simple" xlink:href="https://creativecommons.org/licenses/by/4.0/">Creative Commons Attribution 4.0 International License</ext-link>, which permits unrestricted use, distribution, and reproduction in any medium, provided the original work is properly cited.</license-p>
</license>
</permissions>
<self-uri content-type="pdf" xlink:href="TSP_CMC_66304.pdf"></self-uri>
<abstract>
<p>As vehicular networks become increasingly pervasive, enhancing connectivity and reliability has emerged as a critical objective. Among the enabling technologies for advanced wireless communication, particularly those targeting low latency and high reliability, time synchronization is critical, especially in vehicular networks. However, due to the inherent mobility of vehicular environments, consistently exchanging synchronization packets with a fixed base station or access point is challenging. This issue is further exacerbated in signal shadowed areas such as urban canyons, tunnels, or large-scale indoor halls where other technologies, such as global navigation satellite system (GNSS), are unavailable. One-way synchronization techniques offer a feasible approach under such transient connectivity conditions. One-way schemes still suffer from long convergence times to reach the required synchronization accuracy in these circumstances. In this paper, we propose a WLAN-based multi-stage clock synchronization scheme (WMC) tailored for vehicular networks. The proposed method comprises an initial hard update stage to rapidly achieve synchronization, followed by a high-precision stable stage based on Maximum Likelihood Estimation (MLE). By implementing the scheme directly at the network driver, we address key limitations of hard update mechanisms. Our approach significantly reduces the initial period to collect high-quality samples and offset estimation time to reach sub-50 <inline-formula id="ieqn-1"><mml:math id="mml-ieqn-1"><mml:mrow><mml:mi mathvariant="normal">&#x0B5;</mml:mi></mml:mrow></mml:math></inline-formula>s accuracy, and subsequently transitions to a refined MLE-based synchronization stage, achieving stable accuracy at approximately 30 <inline-formula id="ieqn-2"><mml:math id="mml-ieqn-2"><mml:mrow><mml:mi mathvariant="normal">&#x0B5;</mml:mi></mml:mrow></mml:math></inline-formula>s. The windowed moving average stabilized (reaching 90% of the baseline) in approximately 35 s, which corresponds to just 5.1% of the baseline time accuracy. Finally, the impact of synchronization performance on the localization model was validated using the Simulation of Urban Mobility (SUMO). The results demonstrate that more accurate conditions for position estimation can be supported, with an improvement about 38.5% in the mean error.</p>
</abstract>
<kwd-group kwd-group-type="author">
<kwd>One-way time synchronization</kwd>
<kwd>maximum likelihood estimation</kwd>
<kwd>hybrid clock update</kwd>
</kwd-group>
<funding-group>
<award-group id="awg1">
<funding-source>Korea Institute of Energy Technology Evaluation and Planning</funding-source>
<award-id>20224B10300090</award-id>
</award-group>
<award-group id="awg2">
<funding-source>Information Technology Research Center) support program</funding-source>
<award-id>IITP-2025-RS-2021-II211835</award-id>
</award-group></funding-group>
</article-meta>
</front>
<body>
<sec id="s1">
<label>1</label>
<title>Introduction</title>
<p>Time synchronization is an indispensable requirement in Vehicular Ad hoc Networks (VANETs) to ensure reliable and low-latency communication. As networking performance demands continue to increase, maintaining precise synchronization has become a fundamental necessity for guaranteeing key metrics such as low-latency data transmission and high reliability [<xref ref-type="bibr" rid="ref-1">1</xref>,<xref ref-type="bibr" rid="ref-2">2</xref>]. Despite the effectiveness of two-way synchronization techniques in achieving high precision in VANETs with wireless local area networks (WLANs) and wireless sensor networks (WSNs), these methods heavily rely on frequent packet exchanges and persistent, stable connectivity with higher-stratum time sources [<xref ref-type="bibr" rid="ref-1">1</xref>,<xref ref-type="bibr" rid="ref-3">3</xref>]. Therefore, in environments where power constraints limit packet transmission, such as IoT networks, or VANETs where wireless connectivity fluctuates unpredictably due to physical obstructions like tunnels, urban canyons, or indoor environments, packet delivery can be severely restricted [<xref ref-type="bibr" rid="ref-4">4</xref>,<xref ref-type="bibr" rid="ref-5">5</xref>]. Maintaining accurate synchronization presents significant challenges (the position estimation transmission of vehicles is validated through simulation, as detailed in <xref ref-type="sec" rid="s4">Section 4</xref>). To maintain stable time synchronization, a persistent connection with a higher-stratum source, typically an access point (AP), is required. However, in vehicular networks where maintaining continuous connectivity with a specific AP is challenging, this limitation introduces potential synchronization instabilities. Additionally, in VANETs, mission-critical control data, state information, odometry, position data, and sensor data from cameras and other sources must be transmitted and received in a timely manner [<xref ref-type="bibr" rid="ref-6">6</xref>]. As a result, synchronization should not impose additional bandwidth overhead. Similarly, in IoT networks, which primarily consist of low-power devices, two-way synchronization may be impractical due to energy constraints [<xref ref-type="bibr" rid="ref-7">7</xref>]. Under these conditions, one-way synchronization can be considered as a practical and resource-efficient solution that mitigates these constraints [<xref ref-type="bibr" rid="ref-8">8</xref>]. Unlike two-way synchronization, which requires bidirectional communication with access points (APs) or dedicated time servers, one-way synchronization operates passively, allowing nodes to receive timing information without inducing additional network overhead. This makes it particularly suitable for resource-limited IoT deployments and dynamic vehicular networks where sustained infrastructure connectivity cannot be guaranteed.</p>
<p>The latest one-way synchronization methods leverage Maximum Likelihood Estimation (MLE)-based clock skew estimation using the Cram&#x00E9;r-Rao Lower Bound (CRLB) to achieve highly precise synchronization, outperforming traditional approaches [<xref ref-type="bibr" rid="ref-9">9</xref>]. This method optimally estimates clock skew in a controlled environment where key variables such as device clock precision, network channel characteristics, and AP clock stability remain consistent. The primary advantage of this approach is that it can achieve highly accurate synchronization using only a few broadcast packets, significantly reducing network load and synchronization overhead. In MLE-based one-way synchronization, timestamps are extracted from received beacon frames, and an estimation model is applied to minimize the impact of transmission delays and jitter. The Gaussian delay model is typically employed to model variable delays, ensuring robustness against network fluctuations. The effectiveness of this method has been widely recognized, particularly in environments where precise synchronization is necessary but bidirectional communication is costly or impractical.</p>
<p>Given these challenges, one-way synchronization is often adopted as a practical alternative; however, it also has inherent limitations. While MLE-based estimation provides gradual and stable clock updates, achieving an accurate clock skew estimation requires multiple synchronization cycles. This issue becomes even more pronounced in the presence of unstable clock sources affected by power constraints, channel conditions, and mobility, further delaying the synchronization process. In particular, when the clock source is unreliable due to fluctuations in power availability, network congestion, or frequent handovers between APs, synchronization becomes less responsive and more prone to errors. To address these challenges, we propose an aggressive clock update strategy during the initial synchronization stage. This approach is inspired by network time protocol (NTP)&#x2019;s polling interval, where frequent updates occur in the early stages to achieve rapid convergence before transitioning to longer intervals for stability [<xref ref-type="bibr" rid="ref-10">10</xref>]. By introducing an additional synchronization stage before MLE-based estimation, we aim to improve synchronization efficiency in dynamic environments. We analyze the causes of beacon frame reception instability from unreliable clock sources and introduce a multi-stage synchronization approach. Specifically, we propose a multi-stage WLAN-based synchronization scheme that integrates a hard update-based smooth landing mechanism with adaptive sampling and filtering techniques. This method is designed to optimize synchronization performance in highly dynamic wireless environments. Our proposed scheme consists of an initial hard update for clock correction, followed by gradual adjustments using MLE-based filtering. (1) We analyze the problem of heterogeneous beacon frame reception in one-way time synchronization during the initial access stage under intermittent connectivity. (2) The system first applies an initial hard update by directly setting the system clock to the minimum offset value observed from received beacon frames, rather than conservatively updating clock differences through skew or drift estimation. This ensures a rapid initial correction, reducing the time required for synchronization convergence. (3) Once the initial correction is applied, WMC seamlessly carries forward the samples collected during the initial stage into the MLE-based estimation, which then gradually refines clock skew to maintain stability while Gaussian modeling of delay minimizes synchronization errors over time. Additionally, the synchronization rate is dynamically adjusted based on network conditions, ensuring robustness in environments with intermittent connectivity. By implementing this multi-stage approach, synchronization performance is significantly improved, particularly in vehicular networks, where maintaining stable AP access is challenging. Our method enhances both short-term and long-term synchronization accuracy while also minimizing computational and network overhead.</p>
<p>The rest of this paper is organized as follows. In <xref ref-type="sec" rid="s2">Section 2</xref>, we review typical studies of clock synchronization and those specifically for vehicular networks. <xref ref-type="sec" rid="s3">Section 3</xref> describes the architecture of the proposed clock synchronization method and presents a problem with sample freshness. In <xref ref-type="sec" rid="s4">Section 4</xref>, we evaluate the performance of the proposed system. Finally, the conclusion is given in <xref ref-type="sec" rid="s5">Section 5</xref>.</p>
</sec>
<sec id="s2">
<label>2</label>
<title>Related Work</title>
<p>This section describes time synchronization methods and the related work on message-based exchanges in wireless networks. Additionally, it discusses previous works on one-way time synchronization and their limitations associated with the proposed study.</p>
<p>Message-based time synchronization in wireless networks is primarily achieved through either one-way or two-way message exchanges [<xref ref-type="bibr" rid="ref-11">11</xref>,<xref ref-type="bibr" rid="ref-12">12</xref>]. This approaches are commonly adopted in hierarchical classifications, divided by stratum (a hierarchically lower stratum serves as the reference clock), where synchronization occurs between servers and clients at different levels. As illustrated in <xref ref-type="fig" rid="fig-1">Fig. 1</xref>, a server (<inline-formula id="ieqn-3"><mml:math id="mml-ieqn-3"><mml:mi>s</mml:mi></mml:math></inline-formula>) sends a timing message at the <inline-formula id="ieqn-4"><mml:math id="mml-ieqn-4"><mml:mi>i</mml:mi></mml:math></inline-formula>-th instance, and the client (<inline-formula id="ieqn-5"><mml:math id="mml-ieqn-5"><mml:mi>c</mml:mi></mml:math></inline-formula>) receives it. The relationship between the transmission time <inline-formula id="ieqn-6"><mml:math id="mml-ieqn-6"><mml:msubsup><mml:mi>t</mml:mi><mml:mi>i</mml:mi><mml:mrow><mml:mi>t</mml:mi><mml:mi>x</mml:mi><mml:mo>,</mml:mo><mml:mi>s</mml:mi></mml:mrow></mml:msubsup></mml:math></inline-formula> and the reception time <inline-formula id="ieqn-7"><mml:math id="mml-ieqn-7"><mml:msubsup><mml:mi>t</mml:mi><mml:mi>i</mml:mi><mml:mrow><mml:mi>r</mml:mi><mml:mi>x</mml:mi><mml:mo>,</mml:mo><mml:mi>c</mml:mi></mml:mrow></mml:msubsup></mml:math></inline-formula> allows the client to estimate the server&#x2019;s original transmission time, denoted as <inline-formula id="ieqn-8"><mml:math id="mml-ieqn-8"><mml:msubsup><mml:mi>t</mml:mi><mml:mi>i</mml:mi><mml:mrow><mml:mi>t</mml:mi><mml:mi>x</mml:mi><mml:mo>,</mml:mo><mml:mi>c</mml:mi></mml:mrow></mml:msubsup></mml:math></inline-formula>. The superscripts <inline-formula id="ieqn-9"><mml:math id="mml-ieqn-9"><mml:mi>t</mml:mi><mml:mi>x</mml:mi></mml:math></inline-formula> and <inline-formula id="ieqn-10"><mml:math id="mml-ieqn-10"><mml:mi>r</mml:mi><mml:mi>x</mml:mi></mml:math></inline-formula> denote transmission and reception times, respectively. The discrepancy between <inline-formula id="ieqn-11"><mml:math id="mml-ieqn-11"><mml:msubsup><mml:mi>t</mml:mi><mml:mi>i</mml:mi><mml:mrow><mml:mi>t</mml:mi><mml:mi>x</mml:mi><mml:mo>,</mml:mo><mml:mi>c</mml:mi></mml:mrow></mml:msubsup></mml:math></inline-formula> and <inline-formula id="ieqn-12"><mml:math id="mml-ieqn-12"><mml:msubsup><mml:mi>t</mml:mi><mml:mi>i</mml:mi><mml:mrow><mml:mi>r</mml:mi><mml:mi>x</mml:mi><mml:mo>,</mml:mo><mml:mi>c</mml:mi></mml:mrow></mml:msubsup></mml:math></inline-formula>, denoted as <inline-formula id="ieqn-13"><mml:math id="mml-ieqn-13"><mml:msub><mml:mi>&#x03B4;</mml:mi><mml:mi>i</mml:mi></mml:msub></mml:math></inline-formula>, is predominantly influenced by the end-to-end delay between the server and the client. This delay due to frequency difference is a dominant factor and is redefined as clock skew.</p>
<fig id="fig-1">
<label>Figure 1</label>
<caption>
<title>One-way time synchronization process</title>
</caption>
<graphic mimetype="image" mime-subtype="tif" xlink:href="CMC_66304-fig-1.tif"/>
</fig>
<p>Meanwhile, the server and client inherently maintain independent clocks, differing in resolution and performance. This discrepancy leads to the phenomenon known as <italic>clock drift</italic>. Clock drift arises due to frequency differences between the client and server clocks (<inline-formula id="ieqn-14"><mml:math id="mml-ieqn-14"><mml:msub><mml:mi>C</mml:mi><mml:mi>c</mml:mi></mml:msub><mml:mo stretchy="false">(</mml:mo><mml:mi>t</mml:mi><mml:mo stretchy="false">)</mml:mo><mml:mo>=</mml:mo><mml:mo stretchy="false">(</mml:mo><mml:mn>1</mml:mn><mml:mo>+</mml:mo><mml:mo>&#x003F5;</mml:mo><mml:mo stretchy="false">)</mml:mo><mml:msub><mml:mi>C</mml:mi><mml:mi>s</mml:mi></mml:msub><mml:mo stretchy="false">(</mml:mo><mml:mi>t</mml:mi><mml:mo stretchy="false">)</mml:mo></mml:math></inline-formula>), which represents the ideal server clock value, <inline-formula id="ieqn-15"><mml:math id="mml-ieqn-15"><mml:msub><mml:mi>C</mml:mi><mml:mi>c</mml:mi></mml:msub><mml:mo stretchy="false">(</mml:mo><mml:mi>t</mml:mi><mml:mo stretchy="false">)</mml:mo></mml:math></inline-formula> denotes the actual client clock value, and <inline-formula id="ieqn-16"><mml:math id="mml-ieqn-16"><mml:mo>&#x003F5;</mml:mo></mml:math></inline-formula> is the drift rate of the client clock. The drift rate <inline-formula id="ieqn-17"><mml:math id="mml-ieqn-17"><mml:mo>&#x003F5;</mml:mo></mml:math></inline-formula> quantifies the rate at which the client clock deviates from the server clock over time. Typically, clock drift occurs in the range of several parts per million (ppm) per second. Over extended periods, synchronization errors accumulate if left uncorrected. Therefore, without compensation for clock drift in message-based synchronization, the client clock increasingly deviates from the server clock. To mitigate this, synchronization in WLANs is performed through the transmission of timing messages via packets.</p>
<p>There are several motivations for applying one-way synchronization in real-world systems. Huan et al. [<xref ref-type="bibr" rid="ref-7">7</xref>] target low-power IoT networks with a looped sample-mean (LSM) broadcast scheme but do not evaluate convergence behavior. Shim et al. [<xref ref-type="bibr" rid="ref-13">13</xref>] apply a lightweight NTP-based method for UAV networks, yet likewise omit any analysis of synchronization convergence time. Shi et al. [<xref ref-type="bibr" rid="ref-8">8</xref>] proposed a one-way synchronization technique based on broadcast messages from edge nodes connected to wired infrastructures (e.g., base stations or APs). Wang et al. [<xref ref-type="bibr" rid="ref-14">14</xref>] later introduced the Best Linear Unbiased Estimator (BLUE) as a lightweight alternative to MLE, but noted that its initial convergence speed is slower than that of MLE. Nonetheless, neither work provides a concrete strategy for optimizing convergence speed until the clock is stably adjusted. Maximum Likelihood Estimation (MLE) is a well-established technique whose convergence behavior can be indirectly inferred from the number of iterations required [<xref ref-type="bibr" rid="ref-15">15</xref>]. Guchhait and Karthik. [<xref ref-type="bibr" rid="ref-16">16</xref>] model the network delay as a Gaussian random variable and derive the corresponding Cram&#x00E9;r&#x2013;Rao lower bound (CRLB) to quantify the minimum estimation error; they demonstrate this bound in simulation by varying the number of message iterations. Wang et al. [<xref ref-type="bibr" rid="ref-9">9</xref>] present a hybrid one-way scheme that includes reverse-direction messaging&#x2014;allowing convergence to be assessed via synchronization accuracy over iterations&#x2014;but this approach still does not yield a direct measure of absolute convergence time. By contrast, consensus-based time synchronization protocols have begun to address convergence speed explicitly. Shi et al. [<xref ref-type="bibr" rid="ref-17">17</xref>] propose an iterative message exchange method that accelerates convergence in wireless sensor networks, and Wang et al. [<xref ref-type="bibr" rid="ref-18">18</xref>] most recently present a two-way packet exchange scheme that improves convergence speed under high-delay conditions. However, comparable strategies for rapid convergence in one-way MLE-based synchronization remain unexplored. The related works mentioned above are summarized in <xref ref-type="table" rid="table-1">Table 1</xref>.</p>
<table-wrap id="table-1">
<label>Table 1</label>
<caption>
<title>Comparison of related work</title>
</caption>
<table>
<colgroup>
<col/>
<col/>
<col/>
<col/>
<col/>
</colgroup>
<thead>
<tr>
<th>Reference</th>
<th>Mode</th>
<th>Environment</th>
<th>Convergence</th>
<th>Base algorithm (Technology)</th>
</tr>
</thead>
<tbody>
<tr>
<td>[<xref ref-type="bibr" rid="ref-7">7</xref>]</td>
<td>One-way</td>
<td>IoT network</td>
<td>No</td>
<td>LSM (w reverse)</td>
</tr>
<tr>
<td>[<xref ref-type="bibr" rid="ref-13">13</xref>]</td>
<td>One-way</td>
<td>UAV network</td>
<td>No</td>
<td>NTP</td>
</tr>
<tr>
<td>[<xref ref-type="bibr" rid="ref-8">8</xref>]</td>
<td>One-way</td>
<td>Sensor network</td>
<td>No</td>
<td>MLE</td>
</tr>
<tr>
<td>[<xref ref-type="bibr" rid="ref-14">14</xref>]</td>
<td>One-way</td>
<td>Simulation</td>
<td>Yes</td>
<td>MLE</td>
</tr>
<tr>
<td>[<xref ref-type="bibr" rid="ref-15">15</xref>]</td>
<td>Two-way</td>
<td>Simulation</td>
<td>Iterations</td>
<td>MLE</td>
</tr>
<tr>
<td>[<xref ref-type="bibr" rid="ref-16">16</xref>]</td>
<td>One-way</td>
<td>Simulation</td>
<td>Iterations</td>
<td>MLE</td>
</tr>
<tr>
<td>[<xref ref-type="bibr" rid="ref-9">9</xref>]</td>
<td>One-way</td>
<td>Simulation</td>
<td>Iterations</td>
<td>MLE</td>
</tr>
<tr>
<td>[<xref ref-type="bibr" rid="ref-17">17</xref>]</td>
<td>Two-way</td>
<td>Sensor network</td>
<td>Yes</td>
<td>Consensus-based</td>
</tr>
<tr>
<td>[<xref ref-type="bibr" rid="ref-18">18</xref>]</td>
<td>Two-way</td>
<td>Simulation</td>
<td>Yes</td>
<td>Consensus-based</td>
</tr>
</tbody>
</table>
</table-wrap>
</sec>
<sec id="s3">
<label>3</label>
<title>WMC: Proposed Time Synchronization Model</title>
<p>This section presents the design methodology of WMC, a multi-stage one-way time synchronization approach that enables fast convergence in the initial stage and long-term stability in the stable stage under dynamic wireless environments. In <xref ref-type="sec" rid="s3_2">Sections 3.2</xref> and <xref ref-type="sec" rid="s3_3">3.3</xref>, we describe the stage&#x2013;specific methodologies for the initial and stabilization phases, respectively, each tailored to its objectives and connected through a cohesive, seamlessly integrated process. We first discuss how beacon sequence omissions and stochastic reception delays across nodes introduce heterogeneity in the initial stage, leading to instability in early offset estimation. To address this, we describe a hard update-based sampling and filtering method that quickly stabilizes offset samples by rejecting outliers and applying median-based filtering. In the subsequent stabilization stage, we introduce a procedure to estimate clock offset and skew using maximum likelihood estimation (MLE), and then perform adaptive clock compensation. The section concludes by explaining how a smooth transition from the initial stage to the MLE-based stable stage ensures both synchronization precision and robustness against transient network fluctuations.</p>
<sec id="s3_1">
<label>3.1</label>
<title>Heterogeneity in Beacon Reception Timing</title>
<p>In wireless environments, beacon frames are periodically broadcast from the access point (AP) to multiple receiving nodes for one-way synchronization. However, due to the inherent nature of wireless propagation, several challenges arise in how these beacons are received across different nodes. Despite being transmitted simultaneously from the same AP, nodes may receive different beacon sequence numbers or, in many cases, even when the same sequence number is received, they experience heterogeneous delays caused by varying channel conditions, interference, or hardware-specific reception timing. This phenomenon is illustrated in <xref ref-type="fig" rid="fig-2">Fig. 2</xref>, where the perceived beacon timing at each node differs from the reference due to stochastic transmission delay and reception offset. Such heterogeneity in beacon reception leads to inconsistencies in estimating the timing offset (<inline-formula id="ieqn-18"><mml:math id="mml-ieqn-18"><mml:msub><mml:mi>D</mml:mi><mml:mrow><mml:mtext>OFFSET</mml:mtext></mml:mrow></mml:msub></mml:math></inline-formula>) between each node&#x2019;s local clock (<inline-formula id="ieqn-19"><mml:math id="mml-ieqn-19"><mml:msub><mml:mi>T</mml:mi><mml:mrow><mml:mtext>LOCAL</mml:mtext></mml:mrow></mml:msub></mml:math></inline-formula>) and the AP&#x2019;s reference time (<inline-formula id="ieqn-20"><mml:math id="mml-ieqn-20"><mml:msub><mml:mi>T</mml:mi><mml:mrow><mml:mtext>AP</mml:mtext></mml:mrow></mml:msub></mml:math></inline-formula>). Without effective handling, these inconsistencies degrade synchronization performance and result in unstable system clock updates. Therefore, a robust preprocessing strategy is required to manage this temporal uncertainty prior to applying high-precision estimation techniques such as Maximum Likelihood Estimation (MLE).</p>
<fig id="fig-2">
<label>Figure 2</label>
<caption>
<title>Heterogeneity in beacon frame arrival</title>
</caption>
<graphic mimetype="image" mime-subtype="tif" xlink:href="CMC_66304-fig-2.tif"/>
</fig>
<p>This heterogeneity affects synchronization accuracy in two critical ways. First, when different nodes receive different beacon sequence numbers, each node references a different AP timestamp <inline-formula id="ieqn-21"><mml:math id="mml-ieqn-21"><mml:msub><mml:mi>T</mml:mi><mml:mrow><mml:mtext>AP</mml:mtext><mml:mo>,</mml:mo><mml:mi>i</mml:mi></mml:mrow></mml:msub></mml:math></inline-formula>, resulting in offset values computed as <inline-formula id="ieqn-22"><mml:math id="mml-ieqn-22"><mml:msub><mml:mi>D</mml:mi><mml:mrow><mml:mtext>OFFSET</mml:mtext><mml:mo>,</mml:mo><mml:mi>i</mml:mi></mml:mrow></mml:msub><mml:mo>=</mml:mo><mml:msub><mml:mi>T</mml:mi><mml:mrow><mml:mtext>LOCAL</mml:mtext><mml:mo>,</mml:mo><mml:mi>i</mml:mi></mml:mrow></mml:msub><mml:mo>&#x2212;</mml:mo><mml:msub><mml:mi>T</mml:mi><mml:mrow><mml:mtext>AP</mml:mtext><mml:mo>,</mml:mo><mml:mi>i</mml:mi></mml:mrow></mml:msub></mml:math></inline-formula> that correspond to different reference points in time. Since each transmission from the AP may involve different transmission-side delays, these offsets do not align to a common clock model. Especially during the initial synchronization phase, before any statistical filtering is applied, this misalignment leads to increased uncertainty and wider offset variance across nodes, hindering early convergence of synchronization. Second, even when nodes receive the same beacon sequence number, the local reception timestamp <inline-formula id="ieqn-23"><mml:math id="mml-ieqn-23"><mml:msub><mml:mi>T</mml:mi><mml:mrow><mml:mtext>LOCAL</mml:mtext><mml:mo>,</mml:mo><mml:mi>i</mml:mi></mml:mrow></mml:msub></mml:math></inline-formula> can still vary significantly due to diverse wireless channel conditions, hardware interrupt latencies, and kernel-level processing delays. In such cases, the computed offset can be more accurately expressed as <inline-formula id="ieqn-24"><mml:math id="mml-ieqn-24"><mml:msub><mml:mi>D</mml:mi><mml:mrow><mml:mtext>OFFSET</mml:mtext><mml:mo>,</mml:mo><mml:mi>i</mml:mi></mml:mrow></mml:msub><mml:mo>=</mml:mo><mml:mo stretchy="false">(</mml:mo><mml:msub><mml:mi>T</mml:mi><mml:mrow><mml:mtext>LOCAL</mml:mtext><mml:mo>,</mml:mo><mml:mi>i</mml:mi></mml:mrow></mml:msub><mml:mo>+</mml:mo><mml:msub><mml:mi>&#x03B4;</mml:mi><mml:mi>i</mml:mi></mml:msub><mml:mo stretchy="false">)</mml:mo><mml:mo>&#x2212;</mml:mo><mml:msub><mml:mi>T</mml:mi><mml:mrow><mml:mtext>AP</mml:mtext><mml:mo>,</mml:mo><mml:mi>i</mml:mi></mml:mrow></mml:msub></mml:math></inline-formula>, where <inline-formula id="ieqn-25"><mml:math id="mml-ieqn-25"><mml:msub><mml:mi>&#x03B4;</mml:mi><mml:mi>i</mml:mi></mml:msub></mml:math></inline-formula> represents a stochastic delay term caused by reception-side variability. This <inline-formula id="ieqn-26"><mml:math id="mml-ieqn-26"><mml:msub><mml:mi>&#x03B4;</mml:mi><mml:mi>i</mml:mi></mml:msub></mml:math></inline-formula> is typically modeled as a zero-mean Gaussian random variable, introducing unpredictable noise into the offset measurement even under identical beacon conditions. The combination of these two issues&#x2014;sequence misalignment and stochastic delay variation&#x2014;leads to large offset dispersion during the early synchronization stage. This makes the system vulnerable to unreliable or unstable clock updates. To address this, a mechanism capable of absorbing such uncertainty and refining offset samples is essential prior to applying precise synchronization techniques.</p>
</sec>
<sec id="s3_2">
<label>3.2</label>
<title>Hard Update-Based Sampling and Filtering Algorithm</title>
<p>The process of sampling and filtering this temporal data is implemented as shown in Algorithm 1. First, <inline-formula id="ieqn-27"><mml:math id="mml-ieqn-27"><mml:msub><mml:mi>T</mml:mi><mml:mrow><mml:mi>L</mml:mi><mml:mi>O</mml:mi><mml:mi>C</mml:mi><mml:mi>A</mml:mi><mml:mi>L</mml:mi><mml:mo>,</mml:mo><mml:mi>i</mml:mi></mml:mrow></mml:msub></mml:math></inline-formula> is obtained from the local time of the Linux kernel, while <inline-formula id="ieqn-28"><mml:math id="mml-ieqn-28"><mml:msub><mml:mi>T</mml:mi><mml:mrow><mml:mi>A</mml:mi><mml:mi>P</mml:mi><mml:mo>,</mml:mo><mml:mi>i</mml:mi></mml:mrow></mml:msub></mml:math></inline-formula> is extracted from the received BF. By computing the difference between these timestamps as <inline-formula id="ieqn-29"><mml:math id="mml-ieqn-29"><mml:msub><mml:mi>D</mml:mi><mml:mrow><mml:mi>O</mml:mi><mml:mi>F</mml:mi><mml:mi>F</mml:mi><mml:mi>S</mml:mi><mml:mi>E</mml:mi><mml:mi>T</mml:mi><mml:mo>,</mml:mo><mml:mi>i</mml:mi></mml:mrow></mml:msub></mml:math></inline-formula>, the kernel system time deviation from the AP, which serves as a reference clock, is estimated. A sample is added to <inline-formula id="ieqn-30"><mml:math id="mml-ieqn-30"><mml:msub><mml:mrow><mml:mtext mathvariant="bold">D</mml:mtext></mml:mrow><mml:mrow><mml:mi>O</mml:mi><mml:mi>F</mml:mi><mml:mi>F</mml:mi><mml:mi>S</mml:mi><mml:mi>E</mml:mi><mml:mi>T</mml:mi><mml:mo>,</mml:mo><mml:mi>i</mml:mi></mml:mrow></mml:msub></mml:math></inline-formula> only if it is valid, ensuring that outlier samples do not introduce significant errors in the synchronization process. To maintain efficiency, a moving average characteristic is incorporated by replacing the oldest sample when a new one is added. Unlike a fixed sampling period, this algorithm dynamically determines the period length by calculating the period length every time a sample is added. Once <inline-formula id="ieqn-31"><mml:math id="mml-ieqn-31"><mml:msub><mml:mrow><mml:mtext mathvariant="bold">D</mml:mtext></mml:mrow><mml:mrow><mml:mi>O</mml:mi><mml:mi>F</mml:mi><mml:mi>F</mml:mi><mml:mi>S</mml:mi><mml:mi>E</mml:mi><mml:mi>T</mml:mi><mml:mo>,</mml:mo><mml:mi>i</mml:mi></mml:mrow></mml:msub></mml:math></inline-formula> accumulates <italic>period_size</italic> samples, a filtering process is applied to derive a robust time correction value. The filtering approach consists of two key steps (outlier sampling and median estimation). Outlier rejection is performed based on statistical thresholds to eliminate abnormal values. In particular, the greatest obstacle to synchronizing multiple clients is the common low&#x2014;quality frames (i.e., heterogeneous receptions). Moreover, clients do not exchange information to confirm whether they have received the same sequence or to compare and evaluate each other&#x2019;s sequence data. Because the client cannot assess frame quality immediately upon initial reception, we proactively discard any sample whose <inline-formula id="ieqn-32"><mml:math id="mml-ieqn-32"><mml:msub><mml:mi>D</mml:mi><mml:mrow><mml:mrow><mml:mi mathvariant="normal">O</mml:mi><mml:mi mathvariant="normal">F</mml:mi><mml:mi mathvariant="normal">F</mml:mi><mml:mi mathvariant="normal">S</mml:mi><mml:mi mathvariant="normal">E</mml:mi><mml:mi mathvariant="normal">T</mml:mi></mml:mrow><mml:mo>,</mml:mo><mml:mi>i</mml:mi></mml:mrow></mml:msub></mml:math></inline-formula> deviates from the running median by more than <inline-formula id="ieqn-33"><mml:math id="mml-ieqn-33"><mml:mrow><mml:mi mathvariant="normal">&#x03BB;</mml:mi></mml:mrow><mml:mo>&#x22C5;</mml:mo><mml:msub><mml:mi>&#x03C3;</mml:mi><mml:mrow><mml:mi>D</mml:mi></mml:mrow></mml:msub></mml:math></inline-formula>, thereby suppressing abrupt fluctuations caused by stochastic delays and mitigating heterogeneous arrival effects. For median estimation, rather than performing a full sort operation, we employ Quickselect, an efficient selection algorithm that finds the median with lower computational overhead. This ensures that the filtering step remains stable under varying network conditions. By selecting the median from <inline-formula id="ieqn-34"><mml:math id="mml-ieqn-34"><mml:msub><mml:mrow><mml:mtext mathvariant="bold">D</mml:mtext></mml:mrow><mml:mrow><mml:mi>O</mml:mi><mml:mi>F</mml:mi><mml:mi>F</mml:mi><mml:mi>S</mml:mi><mml:mi>E</mml:mi><mml:mi>T</mml:mi><mml:mo>,</mml:mo><mml:mi>i</mml:mi></mml:mrow></mml:msub></mml:math></inline-formula>, the algorithm ensures that the time offset correction, denoted as <inline-formula id="ieqn-35"><mml:math id="mml-ieqn-35"><mml:msub><mml:mi>D</mml:mi><mml:mrow><mml:mi>M</mml:mi><mml:mi>I</mml:mi><mml:mi>N</mml:mi></mml:mrow></mml:msub></mml:math></inline-formula>, remains robust against extreme deviations. The system clock is then updated based on <inline-formula id="ieqn-36"><mml:math id="mml-ieqn-36"><mml:msub><mml:mi>D</mml:mi><mml:mrow><mml:mi>M</mml:mi><mml:mi>I</mml:mi><mml:mi>N</mml:mi></mml:mrow></mml:msub></mml:math></inline-formula> through <italic>update_clock</italic>, and the process is repeated continuously. This approach accelerates the synchronization process by directly applying the offset-based <inline-formula id="ieqn-37"><mml:math id="mml-ieqn-37"><mml:msub><mml:mi>D</mml:mi><mml:mrow><mml:mi>M</mml:mi><mml:mi>I</mml:mi><mml:mi>N</mml:mi></mml:mrow></mml:msub></mml:math></inline-formula> to the system clock rather than indirectly updating through skew or drift estimation.</p>
<fig id="fig-9">
<graphic mimetype="image" mime-subtype="tif" xlink:href="CMC_66304-fig-9.tif"/>
</fig>
<p>To quantitatively evaluate the effectiveness of the proposed time synchronization method in reducing the time difference between two nodes, we compared it to a pure hard update approach. The analysis consists of three steps: first, we define the time model of the beacon frame transmitted from the AP; second, we construct a mathematical model of direct BF-based time updating, which serves as a baseline approach; and third, we analyze how the proposed method improves synchronization stability and precision. We define a random variable for the <inline-formula id="ieqn-51"><mml:math id="mml-ieqn-51"><mml:mi>i</mml:mi></mml:math></inline-formula>-th beacon frame reception time from the AP as <inline-formula id="ieqn-52"><mml:math id="mml-ieqn-52"><mml:msub><mml:mi>X</mml:mi><mml:mi>i</mml:mi></mml:msub></mml:math></inline-formula>. The node&#x2019;s reception outcome is represented as a binary random variable <inline-formula id="ieqn-53"><mml:math id="mml-ieqn-53"><mml:msub><mml:mi>W</mml:mi><mml:mi>i</mml:mi></mml:msub></mml:math></inline-formula>, where reception failure and success are defined as <inline-formula id="ieqn-54"><mml:math id="mml-ieqn-54"><mml:mi>P</mml:mi><mml:mo stretchy="false">(</mml:mo><mml:mi>W</mml:mi><mml:mo>=</mml:mo><mml:mn>0</mml:mn><mml:mo stretchy="false">)</mml:mo><mml:mo>=</mml:mo><mml:mi>p</mml:mi></mml:math></inline-formula> and <inline-formula id="ieqn-55"><mml:math id="mml-ieqn-55"><mml:mi>P</mml:mi><mml:mo stretchy="false">(</mml:mo><mml:mi>W</mml:mi><mml:mo>=</mml:mo><mml:mn>1</mml:mn><mml:mo stretchy="false">)</mml:mo><mml:mo>=</mml:mo><mml:mi>q</mml:mi></mml:math></inline-formula>, respectively. The received time is modeled as:
<disp-formula id="eqn-1"><label>(1)</label><mml:math id="mml-eqn-1" display="block"><mml:mtable columnalign="right left right left right left right left right left right left" rowspacing="3pt" columnspacing="0em 2em 0em 2em 0em 2em 0em 2em 0em 2em 0em" displaystyle="true"><mml:mtr><mml:mtd><mml:msub><mml:mi mathvariant="normal">&#x03A5;</mml:mi><mml:mrow><mml:mi>i</mml:mi></mml:mrow></mml:msub><mml:mo>=</mml:mo><mml:msub><mml:mi>X</mml:mi><mml:mrow><mml:mi>i</mml:mi></mml:mrow></mml:msub><mml:mo>&#x2212;</mml:mo><mml:msub><mml:mi>t</mml:mi><mml:mi>i</mml:mi></mml:msub><mml:mo>.</mml:mo></mml:mtd></mml:mtr></mml:mtable></mml:math></disp-formula></p>
<p>The most recent valid received time at the node, incorporating reception success probability, is defined as:
<disp-formula id="eqn-2"><label>(2)</label><mml:math id="mml-eqn-2" display="block"><mml:mtable columnalign="right left right left right left right left right left right left" rowspacing="3pt" columnspacing="0em 2em 0em 2em 0em 2em 0em 2em 0em 2em 0em" displaystyle="true"><mml:mtr><mml:mtd><mml:msubsup><mml:mi mathvariant="normal">&#x03A5;</mml:mi><mml:mrow><mml:mi>i</mml:mi></mml:mrow><mml:mrow><mml:mo>&#x2217;</mml:mo></mml:mrow></mml:msubsup><mml:mo>=</mml:mo><mml:mi mathvariant="normal">&#x03A6;</mml:mi><mml:mo stretchy="false">(</mml:mo><mml:msub><mml:mi mathvariant="normal">&#x03A5;</mml:mi><mml:mrow><mml:mn>1</mml:mn></mml:mrow></mml:msub><mml:mo>,</mml:mo><mml:msub><mml:mi>W</mml:mi><mml:mrow><mml:mn>1</mml:mn></mml:mrow></mml:msub><mml:mo>,</mml:mo><mml:msub><mml:mi mathvariant="normal">&#x03A5;</mml:mi><mml:mrow><mml:mn>2</mml:mn></mml:mrow></mml:msub><mml:mo>,</mml:mo><mml:msub><mml:mi>W</mml:mi><mml:mrow><mml:mn>2</mml:mn></mml:mrow></mml:msub><mml:mo>,</mml:mo><mml:mo>&#x22EF;</mml:mo><mml:mo>,</mml:mo><mml:msub><mml:mi mathvariant="normal">&#x03A5;</mml:mi><mml:mrow><mml:mi>i</mml:mi></mml:mrow></mml:msub><mml:mo>,</mml:mo><mml:msub><mml:mi>W</mml:mi><mml:mrow><mml:mi>i</mml:mi></mml:mrow></mml:msub><mml:mo stretchy="false">)</mml:mo><mml:mo>.</mml:mo></mml:mtd></mml:mtr></mml:mtable></mml:math></disp-formula></p>
<p>For a given sequence of received time values, the expected latest valid time error is derived as:
<disp-formula id="eqn-3"><label>(3)</label><mml:math id="mml-eqn-3" display="block"><mml:mtable columnalign="right left right left right left right left right left right left" rowspacing="3pt" columnspacing="0em 2em 0em 2em 0em 2em 0em 2em 0em 2em 0em" displaystyle="true"><mml:mtr><mml:mtd><mml:mrow><mml:mi mathvariant="double-struck">E</mml:mi></mml:mrow><mml:mo stretchy="false">[</mml:mo><mml:msubsup><mml:mi mathvariant="normal">&#x03A5;</mml:mi><mml:mrow><mml:mi>i</mml:mi></mml:mrow><mml:mrow><mml:mo>&#x2217;</mml:mo></mml:mrow></mml:msubsup><mml:mo stretchy="false">]</mml:mo></mml:mtd><mml:mtd><mml:mi></mml:mi><mml:mo>=</mml:mo><mml:mi>p</mml:mi><mml:mo stretchy="false">(</mml:mo><mml:mrow><mml:mi mathvariant="double-struck">E</mml:mi></mml:mrow><mml:mo stretchy="false">[</mml:mo><mml:msub><mml:mi mathvariant="normal">&#x03A5;</mml:mi><mml:mrow><mml:mi>i</mml:mi></mml:mrow></mml:msub><mml:mo stretchy="false">]</mml:mo><mml:mo>+</mml:mo><mml:mi>q</mml:mi><mml:mrow><mml:mi mathvariant="double-struck">E</mml:mi></mml:mrow><mml:mo stretchy="false">[</mml:mo><mml:msub><mml:mi mathvariant="normal">&#x03A5;</mml:mi><mml:mrow><mml:mi>i</mml:mi><mml:mo>&#x2212;</mml:mo><mml:mn>1</mml:mn></mml:mrow></mml:msub><mml:mo stretchy="false">]</mml:mo><mml:mo>+</mml:mo><mml:msup><mml:mi>q</mml:mi><mml:mrow><mml:mn>2</mml:mn></mml:mrow></mml:msup><mml:mrow><mml:mi mathvariant="double-struck">E</mml:mi></mml:mrow><mml:mo stretchy="false">[</mml:mo><mml:msub><mml:mi mathvariant="normal">&#x03A5;</mml:mi><mml:mrow><mml:mi>i</mml:mi><mml:mo>&#x2212;</mml:mo><mml:mn>2</mml:mn></mml:mrow></mml:msub><mml:mo stretchy="false">]</mml:mo><mml:mo>+</mml:mo><mml:mo>&#x22EF;</mml:mo></mml:mtd></mml:mtr><mml:mtr><mml:mtd /><mml:mtd><mml:mi></mml:mi><mml:mspace width="1em" /><mml:mo>+</mml:mo><mml:msup><mml:mi>q</mml:mi><mml:mrow><mml:mi>i</mml:mi><mml:mo>&#x2212;</mml:mo><mml:mn>1</mml:mn></mml:mrow></mml:msup><mml:mrow><mml:mi mathvariant="double-struck">E</mml:mi></mml:mrow><mml:mo stretchy="false">[</mml:mo><mml:msub><mml:mi mathvariant="normal">&#x03A5;</mml:mi><mml:mrow><mml:mn>1</mml:mn></mml:mrow></mml:msub><mml:mo stretchy="false">]</mml:mo><mml:mo stretchy="false">)</mml:mo></mml:mtd></mml:mtr><mml:mtr><mml:mtd /><mml:mtd><mml:mi></mml:mi><mml:mo>=</mml:mo><mml:mi>p</mml:mi><mml:mrow><mml:mi mathvariant="double-struck">E</mml:mi></mml:mrow><mml:mo stretchy="false">[</mml:mo><mml:mi mathvariant="normal">&#x03A5;</mml:mi><mml:mo stretchy="false">]</mml:mo><mml:mo stretchy="false">(</mml:mo><mml:mn>1</mml:mn><mml:mo>+</mml:mo><mml:mi>q</mml:mi><mml:mo>+</mml:mo><mml:msup><mml:mi>q</mml:mi><mml:mn>2</mml:mn></mml:msup><mml:mo>+</mml:mo><mml:mo>&#x22EF;</mml:mo><mml:mo>+</mml:mo><mml:msup><mml:mi>q</mml:mi><mml:mrow><mml:mi>i</mml:mi><mml:mo>&#x2212;</mml:mo><mml:mn>1</mml:mn></mml:mrow></mml:msup><mml:mo stretchy="false">)</mml:mo></mml:mtd></mml:mtr><mml:mtr><mml:mtd /><mml:mtd><mml:mi></mml:mi><mml:mo>&#x2248;</mml:mo><mml:mi>p</mml:mi><mml:mstyle displaystyle="true" scriptlevel="0"><mml:mfrac><mml:mrow><mml:mn>1</mml:mn><mml:mo>&#x2212;</mml:mo><mml:msup><mml:mi>q</mml:mi><mml:mrow><mml:mi>i</mml:mi></mml:mrow></mml:msup></mml:mrow><mml:mrow><mml:mn>1</mml:mn><mml:mo>&#x2212;</mml:mo><mml:mi>q</mml:mi></mml:mrow></mml:mfrac></mml:mstyle><mml:mrow><mml:mi mathvariant="double-struck">E</mml:mi></mml:mrow><mml:mo stretchy="false">[</mml:mo><mml:mi mathvariant="normal">&#x03A5;</mml:mi><mml:mo stretchy="false">]</mml:mo></mml:mtd></mml:mtr><mml:mtr><mml:mtd /><mml:mtd><mml:mi></mml:mi><mml:mo>=</mml:mo><mml:mrow><mml:mi mathvariant="double-struck">E</mml:mi></mml:mrow><mml:mo stretchy="false">[</mml:mo><mml:mi mathvariant="normal">&#x03A5;</mml:mi><mml:mo stretchy="false">]</mml:mo><mml:mo>.</mml:mo></mml:mtd></mml:mtr></mml:mtable></mml:math></disp-formula></p>
<p>The inter-node time difference is then given by:
<disp-formula id="eqn-4"><label>(4)</label><mml:math id="mml-eqn-4" display="block"><mml:mtable columnalign="right left right left right left right left right left right left" rowspacing="3pt" columnspacing="0em 2em 0em 2em 0em 2em 0em 2em 0em 2em 0em" displaystyle="true"><mml:mtr><mml:mtd><mml:mi>Z</mml:mi></mml:mtd><mml:mtd><mml:mi></mml:mi><mml:mo>=</mml:mo><mml:msub><mml:mi>X</mml:mi><mml:mrow><mml:mi>n</mml:mi><mml:mi>o</mml:mi><mml:mi>d</mml:mi><mml:mi>e</mml:mi><mml:mn>1</mml:mn></mml:mrow></mml:msub><mml:mo>&#x2212;</mml:mo><mml:msub><mml:mi>X</mml:mi><mml:mrow><mml:mi>n</mml:mi><mml:mi>o</mml:mi><mml:mi>d</mml:mi><mml:mi>e</mml:mi><mml:mn>2</mml:mn></mml:mrow></mml:msub></mml:mtd></mml:mtr><mml:mtr><mml:mtd /><mml:mtd><mml:mi></mml:mi><mml:mo>=</mml:mo><mml:msub><mml:mi mathvariant="normal">&#x03A5;</mml:mi><mml:mrow><mml:mi>n</mml:mi><mml:mi>o</mml:mi><mml:mi>d</mml:mi><mml:mi>e</mml:mi><mml:mn>1</mml:mn></mml:mrow></mml:msub><mml:mo>&#x2212;</mml:mo><mml:msub><mml:mi mathvariant="normal">&#x03A5;</mml:mi><mml:mrow><mml:mi>n</mml:mi><mml:mi>o</mml:mi><mml:mi>d</mml:mi><mml:mi>e</mml:mi><mml:mn>2</mml:mn></mml:mrow></mml:msub><mml:mo>.</mml:mo></mml:mtd></mml:mtr></mml:mtable></mml:math></disp-formula></p>
<p>To compare the variance reduction effect of the proposed method, we analyze the median-based filtering process. The median estimation follows:
<disp-formula id="eqn-5"><label>(5)</label><mml:math id="mml-eqn-5" display="block"><mml:mtable columnalign="right left right left right left right left right left right left" rowspacing="3pt" columnspacing="0em 2em 0em 2em 0em 2em 0em 2em 0em 2em 0em" displaystyle="true"><mml:mtr><mml:mtd><mml:mrow><mml:mover><mml:mi>u</mml:mi><mml:mo stretchy="false">&#x00AF;</mml:mo></mml:mover></mml:mrow><mml:mo>=</mml:mo><mml:mrow><mml:mo>{</mml:mo><mml:mtable columnalign="left left" rowspacing=".2em" columnspacing="1em" displaystyle="false"><mml:mtr><mml:mtd><mml:msubsup><mml:mi mathvariant="normal">&#x03A5;</mml:mi><mml:mi>m</mml:mi><mml:mi mathvariant="normal">&#x2032;</mml:mi></mml:msubsup><mml:mo>,</mml:mo></mml:mtd><mml:mtd><mml:mrow><mml:mtext>if</mml:mtext></mml:mrow><mml:mtext>&#xA0;</mml:mtext><mml:mi>n</mml:mi><mml:mtext>&#xA0;</mml:mtext><mml:mrow><mml:mtext>is odd</mml:mtext></mml:mrow><mml:mo>,</mml:mo><mml:mi>n</mml:mi><mml:mo>=</mml:mo><mml:mn>2</mml:mn><mml:mi>m</mml:mi><mml:mo>+</mml:mo><mml:mn>1</mml:mn></mml:mtd></mml:mtr><mml:mtr><mml:mtd><mml:mstyle displaystyle="true" scriptlevel="0"><mml:mfrac><mml:mn>1</mml:mn><mml:mn>2</mml:mn></mml:mfrac></mml:mstyle><mml:mo stretchy="false">(</mml:mo><mml:msubsup><mml:mi mathvariant="normal">&#x03A5;</mml:mi><mml:mi>j</mml:mi><mml:mi mathvariant="normal">&#x2032;</mml:mi></mml:msubsup><mml:mo>+</mml:mo><mml:msubsup><mml:mi mathvariant="normal">&#x03A5;</mml:mi><mml:mrow><mml:mi>m</mml:mi><mml:mo>+</mml:mo><mml:mn>1</mml:mn></mml:mrow><mml:mi mathvariant="normal">&#x2032;</mml:mi></mml:msubsup><mml:mo stretchy="false">)</mml:mo><mml:mo>,</mml:mo></mml:mtd><mml:mtd><mml:mrow><mml:mtext>if</mml:mtext></mml:mrow><mml:mtext>&#xA0;</mml:mtext><mml:mi>n</mml:mi><mml:mtext>&#xA0;</mml:mtext><mml:mrow><mml:mtext>is even</mml:mtext></mml:mrow><mml:mo>,</mml:mo><mml:mi>n</mml:mi><mml:mo>=</mml:mo><mml:mn>2</mml:mn><mml:mi>m</mml:mi><mml:mo>,</mml:mo></mml:mtd></mml:mtr></mml:mtable><mml:mo fence="true" stretchy="true" symmetric="true"></mml:mo></mml:mrow></mml:mtd></mml:mtr></mml:mtable></mml:math></disp-formula>where <inline-formula id="ieqn-56"><mml:math id="mml-ieqn-56"><mml:msubsup><mml:mi mathvariant="normal">&#x03A5;</mml:mi><mml:mi>m</mml:mi><mml:mi mathvariant="normal">&#x2032;</mml:mi></mml:msubsup></mml:math></inline-formula> is target time to synchronize, and leads to:
<disp-formula id="eqn-6"><label>(6)</label><mml:math id="mml-eqn-6" display="block"><mml:mtable columnalign="right left right left right left right left right left right left" rowspacing="3pt" columnspacing="0em 2em 0em 2em 0em 2em 0em 2em 0em 2em 0em" displaystyle="true"><mml:mtr><mml:mtd><mml:mrow><mml:mi mathvariant="double-struck">E</mml:mi></mml:mrow><mml:mo stretchy="false">[</mml:mo><mml:msubsup><mml:mi mathvariant="normal">&#x03A5;</mml:mi><mml:mi>m</mml:mi><mml:mi mathvariant="normal">&#x2032;</mml:mi></mml:msubsup><mml:mo stretchy="false">]</mml:mo></mml:mtd><mml:mtd><mml:mi></mml:mi><mml:mo>=</mml:mo><mml:mfrac><mml:mn>1</mml:mn><mml:mn>2</mml:mn></mml:mfrac><mml:mrow><mml:mi mathvariant="double-struck">E</mml:mi></mml:mrow><mml:mo stretchy="false">[</mml:mo><mml:mo stretchy="false">(</mml:mo><mml:msubsup><mml:mi mathvariant="normal">&#x03A5;</mml:mi><mml:mi>m</mml:mi><mml:mi mathvariant="normal">&#x2032;</mml:mi></mml:msubsup><mml:mo>+</mml:mo><mml:msubsup><mml:mi mathvariant="normal">&#x03A5;</mml:mi><mml:mrow><mml:mi>m</mml:mi><mml:mo>+</mml:mo><mml:mn>1</mml:mn></mml:mrow><mml:mi mathvariant="normal">&#x2032;</mml:mi></mml:msubsup><mml:mo stretchy="false">)</mml:mo><mml:mo stretchy="false">]</mml:mo></mml:mtd></mml:mtr><mml:mtr><mml:mtd /><mml:mtd><mml:mi></mml:mi><mml:mo>=</mml:mo><mml:mfrac><mml:mn>1</mml:mn><mml:mn>2</mml:mn></mml:mfrac><mml:mo stretchy="false">(</mml:mo><mml:mrow><mml:mi mathvariant="double-struck">E</mml:mi></mml:mrow><mml:mo stretchy="false">[</mml:mo><mml:msubsup><mml:mi mathvariant="normal">&#x03A5;</mml:mi><mml:mi>m</mml:mi><mml:mi mathvariant="normal">&#x2032;</mml:mi></mml:msubsup><mml:mo stretchy="false">]</mml:mo><mml:mo>+</mml:mo><mml:mrow><mml:mi mathvariant="double-struck">E</mml:mi></mml:mrow><mml:mo stretchy="false">[</mml:mo><mml:msubsup><mml:mi mathvariant="normal">&#x03A5;</mml:mi><mml:mrow><mml:mi>m</mml:mi><mml:mo>+</mml:mo><mml:mn>1</mml:mn></mml:mrow><mml:mi mathvariant="normal">&#x2032;</mml:mi></mml:msubsup><mml:mo stretchy="false">]</mml:mo><mml:mo stretchy="false">)</mml:mo></mml:mtd></mml:mtr><mml:mtr><mml:mtd /><mml:mtd><mml:mi></mml:mi><mml:mo>=</mml:mo><mml:mrow><mml:mi mathvariant="double-struck">E</mml:mi></mml:mrow><mml:mo stretchy="false">[</mml:mo><mml:msubsup><mml:mi mathvariant="normal">&#x03A5;</mml:mi><mml:mi>m</mml:mi><mml:mi mathvariant="normal">&#x2032;</mml:mi></mml:msubsup><mml:mo stretchy="false">]</mml:mo><mml:mo>.</mml:mo></mml:mtd></mml:mtr></mml:mtable></mml:math></disp-formula></p>
<p>Given that the received time errors <inline-formula id="ieqn-57"><mml:math id="mml-ieqn-57"><mml:msub><mml:mi mathvariant="normal">&#x03A5;</mml:mi><mml:mi>i</mml:mi></mml:msub></mml:math></inline-formula> and <inline-formula id="ieqn-58"><mml:math id="mml-ieqn-58"><mml:msubsup><mml:mi mathvariant="normal">&#x03A5;</mml:mi><mml:mi>i</mml:mi><mml:mrow><mml:mi mathvariant="normal">&#x2032;</mml:mi></mml:mrow></mml:msubsup></mml:math></inline-formula> are assumed to follow a normal distribution, the variance <inline-formula id="ieqn-59"><mml:math id="mml-ieqn-59"><mml:msup><mml:mi>&#x03C3;</mml:mi><mml:mrow><mml:mi mathvariant="normal">&#x2032;</mml:mi></mml:mrow></mml:msup></mml:math></inline-formula> of the median-based filtering system is approximated as:
<disp-formula id="eqn-7"><label>(7)</label><mml:math id="mml-eqn-7" display="block"><mml:mtable columnalign="right left right left right left right left right left right left" rowspacing="3pt" columnspacing="0em 2em 0em 2em 0em 2em 0em 2em 0em 2em 0em" displaystyle="true"><mml:mtr><mml:mtd><mml:msup><mml:mi>&#x03C3;</mml:mi><mml:mrow><mml:mn>2</mml:mn><mml:mtext>&#xA0;</mml:mtext><mml:mi mathvariant="normal">&#x2032;</mml:mi></mml:mrow></mml:msup></mml:mtd><mml:mtd><mml:mi></mml:mi><mml:mo>=</mml:mo><mml:mstyle displaystyle="true" scriptlevel="0"><mml:mfrac><mml:mn>1</mml:mn><mml:mrow><mml:mn>8</mml:mn><mml:mi>m</mml:mi><mml:mi>f</mml:mi><mml:mo stretchy="false">(</mml:mo><mml:mrow><mml:mover><mml:mi>u</mml:mi><mml:mo stretchy="false">&#x00AF;</mml:mo></mml:mover></mml:mrow><mml:msup><mml:mo stretchy="false">)</mml:mo><mml:mn>2</mml:mn></mml:msup></mml:mrow></mml:mfrac></mml:mstyle></mml:mtd></mml:mtr><mml:mtr><mml:mtd /><mml:mtd><mml:mi></mml:mi><mml:mo>=</mml:mo><mml:mstyle displaystyle="true" scriptlevel="0"><mml:mfrac><mml:mrow><mml:mi>&#x03C0;</mml:mi><mml:msup><mml:mi>&#x03C3;</mml:mi><mml:mn>2</mml:mn></mml:msup></mml:mrow><mml:mrow><mml:mn>4</mml:mn><mml:mi>m</mml:mi></mml:mrow></mml:mfrac></mml:mstyle></mml:mtd></mml:mtr><mml:mtr><mml:mtd /><mml:mtd><mml:mi></mml:mi><mml:mo>&#x2248;</mml:mo><mml:mfrac><mml:mi>&#x03C0;</mml:mi><mml:mn>32</mml:mn></mml:mfrac><mml:msup><mml:mi>&#x03C3;</mml:mi><mml:mrow><mml:mn>2</mml:mn></mml:mrow></mml:msup><mml:mo>.</mml:mo></mml:mtd></mml:mtr></mml:mtable></mml:math></disp-formula></p>
<p>As a result, the proposed system reduces time error variance to about <inline-formula id="ieqn-60"><mml:math id="mml-ieqn-60"><mml:mi>f</mml:mi><mml:mi>r</mml:mi><mml:mi>a</mml:mi><mml:mi>c</mml:mi><mml:mrow><mml:mi>&#x03C0;</mml:mi></mml:mrow><mml:mrow><mml:mn>32</mml:mn></mml:mrow></mml:math></inline-formula> of the baseline hard update with <inline-formula id="ieqn-61"><mml:math id="mml-ieqn-61"><mml:mi>m</mml:mi><mml:mo>=</mml:mo><mml:mn>16</mml:mn></mml:math></inline-formula> sample size. Retaining the offset sample set <inline-formula id="ieqn-62"><mml:math id="mml-ieqn-62"><mml:mo fence="false" stretchy="false">{</mml:mo><mml:msub><mml:mi>D</mml:mi><mml:mrow><mml:mtext>OFFSET</mml:mtext><mml:mo>,</mml:mo><mml:mi>i</mml:mi></mml:mrow></mml:msub><mml:mo fence="false" stretchy="false">}</mml:mo></mml:math></inline-formula>, the median-based correction <inline-formula id="ieqn-63"><mml:math id="mml-ieqn-63"><mml:msub><mml:mi>D</mml:mi><mml:mrow><mml:mo movablelimits="true" form="prefix">min</mml:mo></mml:mrow></mml:msub></mml:math></inline-formula> (or <inline-formula id="ieqn-64"><mml:math id="mml-ieqn-64"><mml:mrow><mml:mover><mml:mi>u</mml:mi><mml:mo stretchy="false">&#x00AF;</mml:mo></mml:mover></mml:mrow></mml:math></inline-formula>), and the filtering window <inline-formula id="ieqn-65"><mml:math id="mml-ieqn-65"><mml:mi>m</mml:mi></mml:math></inline-formula> defined, we now incorporate these same filtered samples into our MLE approach for stable stage (<xref ref-type="sec" rid="s3_3">Section 3.3</xref>). The adoption of Quickselect enhances filtering efficiency by significantly reducing computational complexity. Instead of sorting the entire dataset, Quickselect finds the median in expected <inline-formula id="ieqn-66"><mml:math id="mml-ieqn-66"><mml:mi>O</mml:mi><mml:mo stretchy="false">(</mml:mo><mml:mi>N</mml:mi><mml:mo stretchy="false">)</mml:mo></mml:math></inline-formula> time, allowing fast convergence to a stable offset estimation. This approach ensures that unstable samples are quickly discarded while still achieving a precise clock. Although this method does not achieve the ultra-low error margins of MLE-based methods (e.g., 10 <inline-formula id="ieqn-67"><mml:math id="mml-ieqn-67"><mml:mrow><mml:mi mathvariant="normal">&#x0B5;</mml:mi></mml:mrow></mml:math></inline-formula>s error range), it provides a practical balance between fast synchronization and stability, typically achieving a 30 <inline-formula id="ieqn-68"><mml:math id="mml-ieqn-68"><mml:mrow><mml:mi mathvariant="normal">&#x0B5;</mml:mi></mml:mrow></mml:math></inline-formula>s error margin while maintaining real-time adaptability.</p>
</sec>
<sec id="s3_3">
<label>3.3</label>
<title>MLE-Based Estimation and Adaptive Clock Correction</title>
<p>To enhance synchronization accuracy in one-way communication environments, we apply Maximum Likelihood Estimation (MLE) to estimate both the clock offset and clock skew. In dynamic wireless networks, the observed timing offset between the access point (AP) and receiving node is influenced not only by the true clock difference but also by stochastic transmission delays, which vary due to channel conditions and system load.</p>
<p>Building on the median-filtered samples <inline-formula id="ieqn-69"><mml:math id="mml-ieqn-69"><mml:msub><mml:mi>D</mml:mi><mml:mrow><mml:mo movablelimits="true" form="prefix">min</mml:mo></mml:mrow></mml:msub></mml:math></inline-formula> and sample indices <inline-formula id="ieqn-70"><mml:math id="mml-ieqn-70"><mml:mi>i</mml:mi></mml:math></inline-formula> from <xref ref-type="sec" rid="s3_2">Section 3.2</xref>, we refine the offset representation by modeling the network delay <inline-formula id="ieqn-71"><mml:math id="mml-ieqn-71"><mml:msub><mml:mi>d</mml:mi><mml:mi>i</mml:mi></mml:msub></mml:math></inline-formula> as a Gaussian variable, ensuring a seamless transition to the MLE-based estimation stage. Let <inline-formula id="ieqn-72"><mml:math id="mml-ieqn-72"><mml:msub><mml:mi>T</mml:mi><mml:mrow><mml:mi>A</mml:mi><mml:mi>P</mml:mi><mml:mo>,</mml:mo><mml:mi>i</mml:mi></mml:mrow></mml:msub></mml:math></inline-formula> denote the timestamp embedded in the <inline-formula id="ieqn-73"><mml:math id="mml-ieqn-73"><mml:mi>i</mml:mi></mml:math></inline-formula>-th beacon frame from the AP, and <inline-formula id="ieqn-74"><mml:math id="mml-ieqn-74"><mml:msub><mml:mi>T</mml:mi><mml:mrow><mml:mi>L</mml:mi><mml:mi>O</mml:mi><mml:mi>C</mml:mi><mml:mi>A</mml:mi><mml:mi>L</mml:mi><mml:mo>,</mml:mo><mml:mi>i</mml:mi></mml:mrow></mml:msub></mml:math></inline-formula> the corresponding reception timestamp at the node. The observed offset is expressed as:
<disp-formula id="eqn-8"><label>(8)</label><mml:math id="mml-eqn-8" display="block"><mml:mtable columnalign="right left right left right left right left right left right left" rowspacing="3pt" columnspacing="0em 2em 0em 2em 0em 2em 0em 2em 0em 2em 0em" displaystyle="true"><mml:mtr><mml:mtd><mml:msub><mml:mi>D</mml:mi><mml:mrow><mml:mi>O</mml:mi><mml:mi>F</mml:mi><mml:mi>F</mml:mi><mml:mi>S</mml:mi><mml:mi>E</mml:mi><mml:mi>T</mml:mi><mml:mo>,</mml:mo><mml:mi>i</mml:mi></mml:mrow></mml:msub><mml:mo>=</mml:mo><mml:msub><mml:mi>T</mml:mi><mml:mrow><mml:mi>L</mml:mi><mml:mi>O</mml:mi><mml:mi>C</mml:mi><mml:mi>A</mml:mi><mml:mi>L</mml:mi><mml:mo>,</mml:mo><mml:mi>i</mml:mi></mml:mrow></mml:msub><mml:mo>&#x2212;</mml:mo><mml:msub><mml:mi>T</mml:mi><mml:mrow><mml:mi>A</mml:mi><mml:mi>P</mml:mi><mml:mo>,</mml:mo><mml:mi>i</mml:mi></mml:mrow></mml:msub><mml:mo>.</mml:mo></mml:mtd></mml:mtr></mml:mtable></mml:math></disp-formula></p>
<p>This offset includes both the actual clock offset <inline-formula id="ieqn-75"><mml:math id="mml-ieqn-75"><mml:mi>&#x03B8;</mml:mi></mml:math></inline-formula> and a variable network-induced delay <inline-formula id="ieqn-76"><mml:math id="mml-ieqn-76"><mml:msub><mml:mi>d</mml:mi><mml:mi>i</mml:mi></mml:msub></mml:math></inline-formula>, modeled as a Gaussian random variable:
<disp-formula id="eqn-9"><label>(9)</label><mml:math id="mml-eqn-9" display="block"><mml:mtable columnalign="right left right left right left right left right left right left" rowspacing="3pt" columnspacing="0em 2em 0em 2em 0em 2em 0em 2em 0em 2em 0em" displaystyle="true"><mml:mtr><mml:mtd><mml:msub><mml:mi>D</mml:mi><mml:mrow><mml:mi>O</mml:mi><mml:mi>F</mml:mi><mml:mi>F</mml:mi><mml:mi>S</mml:mi><mml:mi>E</mml:mi><mml:mi>T</mml:mi><mml:mo>,</mml:mo><mml:mi>i</mml:mi></mml:mrow></mml:msub><mml:mo>=</mml:mo><mml:mi>&#x03B8;</mml:mi><mml:mo>+</mml:mo><mml:msub><mml:mi>d</mml:mi><mml:mi>i</mml:mi></mml:msub><mml:mo>,</mml:mo><mml:mspace width="1em" /><mml:msub><mml:mi>d</mml:mi><mml:mi>i</mml:mi></mml:msub><mml:mo>&#x223C;</mml:mo><mml:mrow><mml:mi>&#x1D4A9;</mml:mi></mml:mrow><mml:mo stretchy="false">(</mml:mo><mml:msub><mml:mrow><mml:mi mathvariant="normal">&#x0B5;</mml:mi></mml:mrow><mml:mi>d</mml:mi></mml:msub><mml:mo>,</mml:mo><mml:msubsup><mml:mi>&#x03C3;</mml:mi><mml:mi>d</mml:mi><mml:mn>2</mml:mn></mml:msubsup><mml:mo stretchy="false">)</mml:mo><mml:mo>.</mml:mo></mml:mtd></mml:mtr></mml:mtable></mml:math></disp-formula></p>
<p>Given a collection of such samples, we estimate the optimal offset <inline-formula id="ieqn-77"><mml:math id="mml-ieqn-77"><mml:msub><mml:mrow><mml:mover><mml:mi>&#x03B8;</mml:mi><mml:mo stretchy="false">&#x005E;</mml:mo></mml:mover></mml:mrow><mml:mrow><mml:mi>M</mml:mi><mml:mi>L</mml:mi><mml:mi>E</mml:mi></mml:mrow></mml:msub></mml:math></inline-formula> by maximizing the likelihood function, which leads to the closed-form estimator:
<disp-formula id="eqn-10"><label>(10)</label><mml:math id="mml-eqn-10" display="block"><mml:mtable columnalign="right left right left right left right left right left right left" rowspacing="3pt" columnspacing="0em 2em 0em 2em 0em 2em 0em 2em 0em 2em 0em" displaystyle="true"><mml:mtr><mml:mtd><mml:msub><mml:mrow><mml:mover><mml:mi>&#x03B8;</mml:mi><mml:mo stretchy="false">&#x005E;</mml:mo></mml:mover></mml:mrow><mml:mrow><mml:mi>M</mml:mi><mml:mi>L</mml:mi><mml:mi>E</mml:mi></mml:mrow></mml:msub><mml:mo>=</mml:mo><mml:mfrac><mml:mn>1</mml:mn><mml:mi>N</mml:mi></mml:mfrac><mml:munderover><mml:mo>&#x2211;</mml:mo><mml:mrow><mml:mi>i</mml:mi><mml:mo>=</mml:mo><mml:mn>1</mml:mn></mml:mrow><mml:mrow><mml:mi>N</mml:mi></mml:mrow></mml:munderover><mml:msub><mml:mi>D</mml:mi><mml:mrow><mml:mi>O</mml:mi><mml:mi>F</mml:mi><mml:mi>F</mml:mi><mml:mi>S</mml:mi><mml:mi>E</mml:mi><mml:mi>T</mml:mi><mml:mo>,</mml:mo><mml:mi>i</mml:mi></mml:mrow></mml:msub><mml:mo>.</mml:mo></mml:mtd></mml:mtr></mml:mtable></mml:math></disp-formula></p>
<p>To further track the clock skew <inline-formula id="ieqn-78"><mml:math id="mml-ieqn-78"><mml:mi>&#x03D5;</mml:mi></mml:math></inline-formula>, we employ a time-differential method based on successive offset changes:
<disp-formula id="eqn-11"><label>(11)</label><mml:math id="mml-eqn-11" display="block"><mml:mtable columnalign="right left right left right left right left right left right left" rowspacing="3pt" columnspacing="0em 2em 0em 2em 0em 2em 0em 2em 0em 2em 0em" displaystyle="true"><mml:mtr><mml:mtd><mml:mrow><mml:mover><mml:mi>&#x03D5;</mml:mi><mml:mo stretchy="false">&#x005E;</mml:mo></mml:mover></mml:mrow><mml:mo>=</mml:mo><mml:mfrac><mml:mn>1</mml:mn><mml:mrow><mml:mi>N</mml:mi><mml:mo>&#x2212;</mml:mo><mml:mn>1</mml:mn></mml:mrow></mml:mfrac><mml:munderover><mml:mo>&#x2211;</mml:mo><mml:mrow><mml:mi>i</mml:mi><mml:mo>=</mml:mo><mml:mn>1</mml:mn></mml:mrow><mml:mrow><mml:mi>N</mml:mi><mml:mo>&#x2212;</mml:mo><mml:mn>1</mml:mn></mml:mrow></mml:munderover><mml:mfrac><mml:mrow><mml:msub><mml:mi>D</mml:mi><mml:mrow><mml:mi>O</mml:mi><mml:mi>F</mml:mi><mml:mi>F</mml:mi><mml:mi>S</mml:mi><mml:mi>E</mml:mi><mml:mi>T</mml:mi><mml:mo>,</mml:mo><mml:mi>i</mml:mi><mml:mo>+</mml:mo><mml:mn>1</mml:mn></mml:mrow></mml:msub><mml:mo>&#x2212;</mml:mo><mml:msub><mml:mi>D</mml:mi><mml:mrow><mml:mi>O</mml:mi><mml:mi>F</mml:mi><mml:mi>F</mml:mi><mml:mi>S</mml:mi><mml:mi>E</mml:mi><mml:mi>T</mml:mi><mml:mo>,</mml:mo><mml:mi>i</mml:mi></mml:mrow></mml:msub></mml:mrow><mml:mrow><mml:msub><mml:mi>T</mml:mi><mml:mrow><mml:mi>A</mml:mi><mml:mi>P</mml:mi><mml:mo>,</mml:mo><mml:mi>i</mml:mi><mml:mo>+</mml:mo><mml:mn>1</mml:mn></mml:mrow></mml:msub><mml:mo>&#x2212;</mml:mo><mml:msub><mml:mi>T</mml:mi><mml:mrow><mml:mi>A</mml:mi><mml:mi>P</mml:mi><mml:mo>,</mml:mo><mml:mi>i</mml:mi></mml:mrow></mml:msub></mml:mrow></mml:mfrac><mml:mo>.</mml:mo></mml:mtd></mml:mtr></mml:mtable></mml:math></disp-formula></p>
<p>Unlike static averaging, this method allows for continuous adaptation, making it suitable for environments with fluctuating delay and mobility. The estimated <inline-formula id="ieqn-79"><mml:math id="mml-ieqn-79"><mml:msub><mml:mrow><mml:mover><mml:mi>&#x03B8;</mml:mi><mml:mo stretchy="false">&#x005E;</mml:mo></mml:mover></mml:mrow><mml:mrow><mml:mi>M</mml:mi><mml:mi>L</mml:mi><mml:mi>E</mml:mi></mml:mrow></mml:msub></mml:math></inline-formula> and <inline-formula id="ieqn-80"><mml:math id="mml-ieqn-80"><mml:mrow><mml:mover><mml:mi>&#x03D5;</mml:mi><mml:mo stretchy="false">&#x005E;</mml:mo></mml:mover></mml:mrow></mml:math></inline-formula> are then used to correct the local system clock with high precision. In practice, the MLE-estimated offset <inline-formula id="ieqn-81"><mml:math id="mml-ieqn-81"><mml:msub><mml:mrow><mml:mover><mml:mi>&#x03B8;</mml:mi><mml:mo stretchy="false">&#x005E;</mml:mo></mml:mover></mml:mrow><mml:mrow><mml:mrow><mml:mi mathvariant="normal">M</mml:mi><mml:mi mathvariant="normal">L</mml:mi><mml:mi mathvariant="normal">E</mml:mi></mml:mrow></mml:mrow></mml:msub></mml:math></inline-formula> is applied in a single step or gradually as a slew correction with the estimated skew <inline-formula id="ieqn-82"><mml:math id="mml-ieqn-82"><mml:mrow><mml:mover><mml:mi>&#x03D5;</mml:mi><mml:mo stretchy="false">&#x005E;</mml:mo></mml:mover></mml:mrow></mml:math></inline-formula> to adjust the system clock.</p>
<p>Once a rapid convergence is achieved through the initial hard update mechanism described earlier, the synchronization process transitions into this MLE-based estimation stage. In this stage, adaptive sampling and lightweight filtering are applied to mitigate transient delay fluctuations, and clock correction is performed gradually to ensure smooth tracking of the reference time. This approach contributes to overall stability and robustness of the synchronization system under real-world wireless dynamics.</p>
</sec>
</sec>
<sec id="s4">
<label>4</label>
<title>Performance Evaluation</title>
<p>In this section, we compare the synchronization performance of WMC with two approaches; one based on a one-way synchronization method using an MLE-based hard update, and the other based on a two-way synchronization method implemented by Chrony. We employ a WLAN network interface card (NIC) attached to an access point (AP), serving as a low-quality clock source. Two single-board computers (SBCs), suitable for deployment on unmanned aerial vehicles (UAVs), are equipped with identical NICs and act as client nodes. The client devices are two <italic>Odroid XU4</italic> boards running <italic>Ubuntu 18.04</italic> with <italic>Linux kernel 4.14</italic>. The network driver is based on the <italic>RTL8812AU</italic> chipset. All synchronization schemes (WMC, MLE, and Chrony) are identically deployed on both devices. To evaluate timing accuracy, we measure the output pulses generated by the <italic>pps_gen_gpio</italic> driver and emitted through general purpose input/output (GPIO) pins, using a <italic>Tektronix TBS1102B-EDU</italic> digital oscilloscope, which provides a sample rate of <inline-formula id="ieqn-83"><mml:math id="mml-ieqn-83"><mml:mn>2</mml:mn><mml:mtext>&#xA0;</mml:mtext><mml:mi>G</mml:mi><mml:mi>S</mml:mi><mml:mrow><mml:mo>/</mml:mo></mml:mrow><mml:mi>s</mml:mi></mml:math></inline-formula> via two channels. The oscilloscope captures the pulses from the two clients after synchronization is applied. We analyze the offset data during the synchronization process and verify the timing error by comparing the output clock pulses between the two clients as observed on the oscilloscope.</p>
<p>Any packet transmission-based scheme inherently incurs overhead. Data rates must be considered for practical VANET deployment. Therefore, we present each estimated data rate in its formulated expression along with practical parameter ranges. The data rate of Chrony (<inline-formula id="ieqn-84"><mml:math id="mml-ieqn-84"><mml:msub><mml:mi>R</mml:mi><mml:mrow><mml:mi>C</mml:mi><mml:mi>h</mml:mi><mml:mi>r</mml:mi><mml:mi>o</mml:mi><mml:mi>n</mml:mi><mml:mi>y</mml:mi></mml:mrow></mml:msub></mml:math></inline-formula>) can be expressed as follows:
<disp-formula id="eqn-12"><label>(12)</label><mml:math id="mml-eqn-12" display="block"><mml:msub><mml:mi>R</mml:mi><mml:mrow><mml:mi>C</mml:mi><mml:mi>h</mml:mi><mml:mi>r</mml:mi><mml:mi>o</mml:mi><mml:mi>n</mml:mi><mml:mi>y</mml:mi></mml:mrow></mml:msub><mml:mo>=</mml:mo><mml:mfrac><mml:mrow><mml:mn>2</mml:mn><mml:mo>&#x22C5;</mml:mo><mml:msub><mml:mi>L</mml:mi><mml:mrow><mml:mi>n</mml:mi><mml:mi>t</mml:mi><mml:mi>p</mml:mi></mml:mrow></mml:msub></mml:mrow><mml:msub><mml:mi>T</mml:mi><mml:mrow><mml:mi>p</mml:mi><mml:mi>o</mml:mi><mml:mi>l</mml:mi><mml:mi>l</mml:mi><mml:mi>i</mml:mi><mml:mi>n</mml:mi><mml:mi>g</mml:mi></mml:mrow></mml:msub></mml:mfrac><mml:mo>,</mml:mo></mml:math></disp-formula>where <inline-formula id="ieqn-85"><mml:math id="mml-ieqn-85"><mml:mn>2</mml:mn><mml:mo>&#x22C5;</mml:mo><mml:msub><mml:mi>L</mml:mi><mml:mrow><mml:mi>n</mml:mi><mml:mi>t</mml:mi><mml:mi>p</mml:mi></mml:mrow></mml:msub></mml:math></inline-formula> is the packet size for two-way NTP exchanges and <inline-formula id="ieqn-86"><mml:math id="mml-ieqn-86"><mml:msub><mml:mi>T</mml:mi><mml:mrow><mml:mi>p</mml:mi><mml:mi>o</mml:mi><mml:mi>l</mml:mi><mml:mi>l</mml:mi><mml:mi>i</mml:mi><mml:mi>n</mml:mi><mml:mi>g</mml:mi></mml:mrow></mml:msub></mml:math></inline-formula> is the polling interval. Similarly, the data rate of WMC (<inline-formula id="ieqn-87"><mml:math id="mml-ieqn-87"><mml:msub><mml:mi>R</mml:mi><mml:mrow><mml:mi>W</mml:mi><mml:mi>M</mml:mi><mml:mi>C</mml:mi></mml:mrow></mml:msub></mml:math></inline-formula>) also can be written as follows:
<disp-formula id="eqn-13"><label>(13)</label><mml:math id="mml-eqn-13" display="block"><mml:msub><mml:mi>R</mml:mi><mml:mrow><mml:mi>W</mml:mi><mml:mi>M</mml:mi><mml:mi>C</mml:mi></mml:mrow></mml:msub><mml:mo>=</mml:mo><mml:mrow><mml:mi mathvariant="normal">&#x03B1;</mml:mi></mml:mrow><mml:mo>&#x22C5;</mml:mo><mml:mfrac><mml:msub><mml:mi>L</mml:mi><mml:mrow><mml:mi>b</mml:mi><mml:mi>e</mml:mi><mml:mi>a</mml:mi><mml:mi>c</mml:mi><mml:mi>o</mml:mi><mml:mi>n</mml:mi></mml:mrow></mml:msub><mml:msub><mml:mi>T</mml:mi><mml:mrow><mml:mi>b</mml:mi><mml:mi>e</mml:mi><mml:mi>a</mml:mi><mml:mi>c</mml:mi><mml:mi>o</mml:mi><mml:mi>n</mml:mi></mml:mrow></mml:msub></mml:mfrac><mml:mo>,</mml:mo></mml:math></disp-formula>where <inline-formula id="ieqn-88"><mml:math id="mml-ieqn-88"><mml:msub><mml:mi>L</mml:mi><mml:mrow><mml:mi>b</mml:mi><mml:mi>e</mml:mi><mml:mi>a</mml:mi><mml:mi>c</mml:mi><mml:mi>o</mml:mi><mml:mi>n</mml:mi></mml:mrow></mml:msub></mml:math></inline-formula> is the size of beacon frame for one-way synchronization, <inline-formula id="ieqn-89"><mml:math id="mml-ieqn-89"><mml:msub><mml:mi>T</mml:mi><mml:mrow><mml:mi>b</mml:mi><mml:mi>e</mml:mi><mml:mi>a</mml:mi><mml:mi>c</mml:mi><mml:mi>o</mml:mi><mml:mi>n</mml:mi></mml:mrow></mml:msub></mml:math></inline-formula> is beacon interval,and <inline-formula id="ieqn-90"><mml:math id="mml-ieqn-90"><mml:mrow><mml:mi mathvariant="normal">&#x03B1;</mml:mi></mml:mrow><mml:mo>&#x2208;</mml:mo><mml:mo stretchy="false">[</mml:mo><mml:mn>0</mml:mn><mml:mo>,</mml:mo><mml:mn>1</mml:mn><mml:mo stretchy="false">]</mml:mo></mml:math></inline-formula> is reception ratio. According to these parameters, the practical data rate is summarized in <xref ref-type="table" rid="table-2">Table 2</xref>, and the estimated data rate (at <inline-formula id="ieqn-91"><mml:math id="mml-ieqn-91"><mml:mrow><mml:mi mathvariant="normal">&#x03B1;</mml:mi></mml:mrow><mml:mo>=</mml:mo><mml:mn>0.5</mml:mn></mml:math></inline-formula>) is negligibly small.</p>
<table-wrap id="table-2">
<label>Table 2</label>
<caption>
<title>Estimated data rate</title>
</caption>
<table>
<colgroup>
<col/>
<col/>
<col/>
<col/>
</colgroup>
<thead>
<tr>
<th>Method</th>
<th>Packet size (bits)</th>
<th>Interval (sec)</th>
<th>Data rate (bps)</th>
</tr>
</thead>
<tbody>
<tr>
<td>Chrony</td>
<td><inline-formula id="ieqn-92"><mml:math id="mml-ieqn-92"><mml:msub><mml:mi>L</mml:mi><mml:mrow><mml:mrow><mml:mi mathvariant="normal">c</mml:mi><mml:mi mathvariant="normal">h</mml:mi><mml:mi mathvariant="normal">r</mml:mi><mml:mi mathvariant="normal">o</mml:mi><mml:mi mathvariant="normal">n</mml:mi><mml:mi mathvariant="normal">y</mml:mi></mml:mrow></mml:mrow></mml:msub><mml:mo>=</mml:mo><mml:mn>384</mml:mn></mml:math></inline-formula></td>
<td><inline-formula id="ieqn-93"><mml:math id="mml-ieqn-93"><mml:msub><mml:mi>T</mml:mi><mml:mrow><mml:mrow><mml:mi mathvariant="normal">c</mml:mi><mml:mi mathvariant="normal">h</mml:mi><mml:mi mathvariant="normal">r</mml:mi><mml:mi mathvariant="normal">o</mml:mi><mml:mi mathvariant="normal">n</mml:mi><mml:mi mathvariant="normal">y</mml:mi></mml:mrow></mml:mrow></mml:msub><mml:mo>&#x2208;</mml:mo><mml:mo stretchy="false">[</mml:mo><mml:mn>1</mml:mn><mml:mo>,</mml:mo><mml:mspace width="thinmathspace" /><mml:mn>64</mml:mn><mml:mo stretchy="false">]</mml:mo></mml:math></inline-formula></td>
<td><inline-formula id="ieqn-94"><mml:math id="mml-ieqn-94"><mml:msub><mml:mi>R</mml:mi><mml:mrow><mml:mi>W</mml:mi><mml:mi>M</mml:mi><mml:mi>C</mml:mi></mml:mrow></mml:msub><mml:mo>&#x2208;</mml:mo><mml:mo stretchy="false">[</mml:mo><mml:mn>12</mml:mn><mml:mo>,</mml:mo><mml:mtext>&#xA0;</mml:mtext><mml:mn>768</mml:mn><mml:mo stretchy="false">]</mml:mo></mml:math></inline-formula></td>
</tr>
<tr>
<td>WMC</td>
<td><inline-formula id="ieqn-95"><mml:math id="mml-ieqn-95"><mml:msub><mml:mi>L</mml:mi><mml:mrow><mml:mrow><mml:mi mathvariant="normal">W</mml:mi><mml:mi mathvariant="normal">M</mml:mi><mml:mi mathvariant="normal">C</mml:mi></mml:mrow></mml:mrow></mml:msub><mml:mo>=</mml:mo><mml:mn>64</mml:mn></mml:math></inline-formula></td>
<td><inline-formula id="ieqn-96"><mml:math id="mml-ieqn-96"><mml:msub><mml:mi>T</mml:mi><mml:mrow><mml:mrow><mml:mi mathvariant="normal">W</mml:mi><mml:mi mathvariant="normal">M</mml:mi><mml:mi mathvariant="normal">C</mml:mi></mml:mrow></mml:mrow></mml:msub><mml:mo>&#x2208;</mml:mo><mml:mo stretchy="false">[</mml:mo><mml:mn>0.1</mml:mn><mml:mo>,</mml:mo><mml:mspace width="thinmathspace" /><mml:mn>60</mml:mn><mml:mo stretchy="false">]</mml:mo></mml:math></inline-formula></td>
<td><inline-formula id="ieqn-97"><mml:math id="mml-ieqn-97"><mml:msub><mml:mi>R</mml:mi><mml:mrow><mml:mi>W</mml:mi><mml:mi>M</mml:mi><mml:mi>C</mml:mi></mml:mrow></mml:msub><mml:mo>&#x2208;</mml:mo><mml:mo stretchy="false">[</mml:mo><mml:mn>0.53</mml:mn><mml:mo>,</mml:mo><mml:mtext>&#xA0;</mml:mtext><mml:mn>320</mml:mn><mml:mo stretchy="false">]</mml:mo></mml:math></inline-formula></td>
</tr>
</tbody>
</table>
</table-wrap>
<sec id="s4_1">
<label>4.1</label>
<title>Clock Offset Analysis in the Synchronization Process</title>
<p>The clock offset refers to the time difference between two devices for the same nominal second, expressed as <inline-formula id="ieqn-98"><mml:math id="mml-ieqn-98"><mml:msub><mml:mi>C</mml:mi><mml:mi>c</mml:mi></mml:msub><mml:mo>&#x2212;</mml:mo><mml:msub><mml:mi>C</mml:mi><mml:mi>s</mml:mi></mml:msub></mml:math></inline-formula>. However, in synchronization processes such as NTP, PTP, or Chrony, it is the client that corrects the skew and drift. Thus, the offset can be more precisely defined as the difference between the reception time at the client <inline-formula id="ieqn-99"><mml:math id="mml-ieqn-99"><mml:msubsup><mml:mi>t</mml:mi><mml:mi>i</mml:mi><mml:mrow><mml:mi>r</mml:mi><mml:mi>x</mml:mi><mml:mo>,</mml:mo><mml:mi>c</mml:mi></mml:mrow></mml:msubsup></mml:math></inline-formula> and the transmission time at the server <inline-formula id="ieqn-100"><mml:math id="mml-ieqn-100"><mml:msubsup><mml:mi>t</mml:mi><mml:mi>i</mml:mi><mml:mrow><mml:mi>t</mml:mi><mml:mi>x</mml:mi><mml:mo>,</mml:mo><mml:mi>s</mml:mi></mml:mrow></mml:msubsup></mml:math></inline-formula>. Based on the timing messages received by the client, offset samples are collected and used as parameters to operate the schemes proposed in <xref ref-type="sec" rid="s3">Section 3</xref>. Accordingly, the variation of the offset becomes one of the most critical values in the synchronization process. We compare the offset pattern of WMC, a one-way synchronization method, with Chrony, a state-of-the-art two-way synchronization technique, as shown in <xref ref-type="fig" rid="fig-3">Fig. 3</xref>. We define the first 10 minutes after the execution of the synchronization driver as the initial stage, during which we log the offset values of both WMC and Chrony. Since each raw offset sample is discarded by filters or diluted into mean or variance, the tendency of offset is more informative than the raw values themselves. Thus, we apply logistic regression based on a sigmoid function to the offset pattern, as shown in <xref ref-type="fig" rid="fig-3">Fig. 3</xref>. The <italic>y</italic>-axis represents the normalized offset from the regression fit. The WMC scheme shows a normalized mean offset of 357.41 <inline-formula id="ieqn-101"><mml:math id="mml-ieqn-101"><mml:mrow><mml:mi mathvariant="normal">&#x0B5;</mml:mi></mml:mrow></mml:math></inline-formula>s, whereas Chrony yields a higher initial mean offset of 1558.92 <inline-formula id="ieqn-102"><mml:math id="mml-ieqn-102"><mml:mrow><mml:mi mathvariant="normal">&#x0B5;</mml:mi></mml:mrow></mml:math></inline-formula>s. A noteworthy observation is that the offset level reverses significantly between 400 to 500 s after the synchronization process begins. While WMC consistently maintains a lower offset level, Chrony initially exhibits unstable offset values but surpasses WMC in accuracy after 500 s. This behavior indicates that traditional two-way synchronization methods, like Chrony, adopt a conservative correction strategy that is effective not only for direct links but also via large scale network or backbone network. The use of adaptive polling intervals further reflects the design philosophy of NTP-based synchronization. Therefore, in scenarios with direct WLAN AP connections, WMC demonstrates superior performance over the initial stage.</p>
<fig id="fig-3">
<label>Figure 3</label>
<caption>
<title>Logistic regression of clock offset during the initial stage</title>
</caption>
<graphic mimetype="image" mime-subtype="tif" xlink:href="CMC_66304-fig-3.tif"/>
</fig>
</sec>
<sec id="s4_2">
<label>4.2</label>
<title>Clock Synchronization Error Analysis</title>
<p>This subsection analyzes how accurately the two clients were synchronized to the server. For a fair comparison, the proposed WMC scheme is evaluated alongside a one-way synchronization method based on MLE with hard updates and a two-way synchronization method implemented by Chrony. The difference between the clocks of the two clients, <inline-formula id="ieqn-103"><mml:math id="mml-ieqn-103"><mml:msub><mml:mi>C</mml:mi><mml:mrow><mml:mi>c</mml:mi><mml:mn>1</mml:mn></mml:mrow></mml:msub></mml:math></inline-formula> and <inline-formula id="ieqn-104"><mml:math id="mml-ieqn-104"><mml:msub><mml:mi>C</mml:mi><mml:mrow><mml:mi>c</mml:mi><mml:mn>2</mml:mn></mml:mrow></mml:msub></mml:math></inline-formula>, is defined as the synchronization error and is measured using an oscilloscope. The actual timing precision of the client clocks during the initial phase, corresponding to the offset trend analyzed in <xref ref-type="fig" rid="fig-3">Fig. 3</xref>, is shown in <xref ref-type="fig" rid="fig-4">Fig. 4</xref>. Similarly, the error observed among the stable stage is presented in <xref ref-type="fig" rid="fig-5">Fig. 5</xref>. The synchronization error between the two clients during the initial stage is presented in <xref ref-type="fig" rid="fig-4">Fig. 4</xref>. Due to the non-dynamic scale limitation of the oscilloscope, the maximum error values were capped at 1000 <inline-formula id="ieqn-105"><mml:math id="mml-ieqn-105"><mml:mrow><mml:mi mathvariant="normal">&#x0B5;</mml:mi></mml:mrow></mml:math></inline-formula>s for MLE and 2000 <inline-formula id="ieqn-106"><mml:math id="mml-ieqn-106"><mml:mrow><mml:mi mathvariant="normal">&#x0B5;</mml:mi></mml:mrow></mml:math></inline-formula>s for Chrony. As shown in <xref ref-type="fig" rid="fig-4">Fig. 4a</xref>, Chrony exhibits significantly higher error values in the early part of the initial stage, with a maximum windowed average of 15,190.00 <inline-formula id="ieqn-107"><mml:math id="mml-ieqn-107"><mml:mrow><mml:mi mathvariant="normal">&#x0B5;</mml:mi></mml:mrow></mml:math></inline-formula>s and a mean error of 2610.90 <inline-formula id="ieqn-108"><mml:math id="mml-ieqn-108"><mml:mrow><mml:mi mathvariant="normal">&#x0B5;</mml:mi></mml:mrow></mml:math></inline-formula>s. In contrast, WMC maintains a much lower error level, with a mean of 47.00 <inline-formula id="ieqn-109"><mml:math id="mml-ieqn-109"><mml:mrow><mml:mi mathvariant="normal">&#x0B5;</mml:mi></mml:mrow></mml:math></inline-formula>s and a maximum average of 65.64 <inline-formula id="ieqn-110"><mml:math id="mml-ieqn-110"><mml:mrow><mml:mi mathvariant="normal">&#x0B5;</mml:mi></mml:mrow></mml:math></inline-formula>s. MLE also outperforms Chrony, with a mean error of 341.75 <inline-formula id="ieqn-111"><mml:math id="mml-ieqn-111"><mml:mrow><mml:mi mathvariant="normal">&#x0B5;</mml:mi></mml:mrow></mml:math></inline-formula>s and a maximum average of 924.83 <inline-formula id="ieqn-112"><mml:math id="mml-ieqn-112"><mml:mrow><mml:mi mathvariant="normal">&#x0B5;</mml:mi></mml:mrow></mml:math></inline-formula>s. The corresponding cumulative distribution functions (CDF) in <xref ref-type="fig" rid="fig-4">Fig. 4b</xref> confirm that WMC achieves the most stable and consistent synchronization, followed by MLE. Chrony&#x2019;s error distribution is heavily skewed toward higher values, indicating less reliable synchronization during the initial stage. After 400 s, all three methods converge to a similar level of synchronization performance. During the entire experimental period, the clock error results are shown in <xref ref-type="fig" rid="fig-5">Fig. 5</xref>. The two methods maintain low error levels with reduced fluctuations. For the final 300 s, Chrony achieves a mean error of 46.07 <inline-formula id="ieqn-113"><mml:math id="mml-ieqn-113"><mml:mrow><mml:mi mathvariant="normal">&#x0B5;</mml:mi></mml:mrow></mml:math></inline-formula>s and a maximum windowed average of 86.73 <inline-formula id="ieqn-114"><mml:math id="mml-ieqn-114"><mml:mrow><mml:mi mathvariant="normal">&#x0B5;</mml:mi></mml:mrow></mml:math></inline-formula>s, while WMC shows the best performance with a mean error of 34.49 <inline-formula id="ieqn-115"><mml:math id="mml-ieqn-115"><mml:mrow><mml:mi mathvariant="normal">&#x0B5;</mml:mi></mml:mrow></mml:math></inline-formula>s and a lower maximum average of 48.17 <inline-formula id="ieqn-116"><mml:math id="mml-ieqn-116"><mml:mrow><mml:mi mathvariant="normal">&#x0B5;</mml:mi></mml:mrow></mml:math></inline-formula>s. Specifically, compared to Chrony&#x2019;s stabilization performance (690 s to reach 90% of the steady-state offset), WMC reaches the same 90% level in only 35 s, i.e., 5.1% of the baseline time. These results suggest that switching to an WMC mechanism is also more effective than Chrony in the stable stage.</p>
<fig id="fig-4">
<label>Figure 4</label>
<caption>
<title>Clock error during the initial stage</title>
</caption>
<graphic mimetype="image" mime-subtype="tif" xlink:href="CMC_66304-fig-4.tif"/>
</fig><fig id="fig-5">
<label>Figure 5</label>
<caption>
<title>Clock error between two clients</title>
</caption>
<graphic mimetype="image" mime-subtype="tif" xlink:href="CMC_66304-fig-5.tif"/>
</fig>
<p>Therefore, the results in <xref ref-type="fig" rid="fig-4">Figs. 4</xref> and <xref ref-type="fig" rid="fig-5">5</xref> demonstrate that, in vehicular networks where WLAN-based synchronization is often transient and unstable, a hard update-based multi-stage approach is effective in achieving rapid convergence toward operational synchronization accuracy.</p>

</sec>
<sec id="s4_3">
<label>4.3</label>
<title>Vehicle-Based Time Offset Effects on Localization</title>
<p>This subsection presents a simulation-based evaluation examining how time synchronization accuracy influences position estimation performance in vehicular communication systems. The experiment was conducted using the simulation of urban mobility (SUMO) simulator on an urban canyon map with dense building structures, as shown in <xref ref-type="fig" rid="fig-6">Fig. 6a</xref>. Six and sixty vehicles were deployed on a closed-loop road approximately <inline-formula id="ieqn-117"><mml:math id="mml-ieqn-117"><mml:mn>1</mml:mn><mml:mtext>&#xA0;</mml:mtext><mml:mrow><mml:mi mathvariant="normal">k</mml:mi><mml:mi mathvariant="normal">m</mml:mi></mml:mrow></mml:math></inline-formula> in length. The vehicles were allowed to accelerate up to <inline-formula id="ieqn-118"><mml:math id="mml-ieqn-118"><mml:mn>33.3</mml:mn><mml:mtext>&#xA0;</mml:mtext><mml:mrow><mml:mi mathvariant="normal">m</mml:mi><mml:mrow><mml:mo>/</mml:mo></mml:mrow><mml:mi mathvariant="normal">s</mml:mi></mml:mrow></mml:math></inline-formula>, and the loop path was repeated to maintain continuous motion, resulting in a consistent trajectory illustrated in <xref ref-type="fig" rid="fig-6">Fig. 6b</xref>. Within a general cooperative localization scenario [<xref ref-type="bibr" rid="ref-19">19</xref>,<xref ref-type="bibr" rid="ref-20">20</xref>], local position estimation is modeled as a Gaussian distribution such that <inline-formula id="ieqn-119"><mml:math id="mml-ieqn-119"><mml:mrow><mml:mi mathvariant="double-struck">P</mml:mi></mml:mrow><mml:mo stretchy="false">(</mml:mo><mml:mrow><mml:mo stretchy="false">|</mml:mo></mml:mrow><mml:mi>X</mml:mi><mml:mrow><mml:mo stretchy="false">|</mml:mo></mml:mrow><mml:mo>&gt;</mml:mo><mml:mn>0.1</mml:mn><mml:mtext>&#xA0;</mml:mtext><mml:mrow><mml:mi mathvariant="normal">m</mml:mi></mml:mrow><mml:mo stretchy="false">)</mml:mo><mml:mo>&#x003C;</mml:mo><mml:mn>0.01</mml:mn></mml:math></inline-formula>. Each vehicle&#x2019;s position was recorded using ground truth (GT) data, which were not available to the vehicle themselves, and distributed localization was modeled by assuming that the position of a reference vehicle (vehicle A) was shared with other vehicles as an input parameter for global estimation. In this context, we analyze the impact of time synchronization at the infrastructure level on the performance of vehicular localization systems. Two different clock offset correction methods were applied: Chrony and WMC (vehicles B and C). Localization accuracy was evaluated by computing the Fr&#x00E9;chet distance between the GT trajectory and the offset-corrected trajectories. As shown in <xref ref-type="fig" rid="fig-7">Fig. 7</xref>, Chrony resulted in a maximum error of <inline-formula id="ieqn-120"><mml:math id="mml-ieqn-120"><mml:mn>0.5870</mml:mn><mml:mtext>&#xA0;</mml:mtext><mml:mrow><mml:mi mathvariant="normal">m</mml:mi></mml:mrow></mml:math></inline-formula>, with a mean of <inline-formula id="ieqn-121"><mml:math id="mml-ieqn-121"><mml:mn>0.0697</mml:mn><mml:mtext>&#xA0;</mml:mtext><mml:mrow><mml:mi mathvariant="normal">m</mml:mi></mml:mrow></mml:math></inline-formula> and a standard deviation of <inline-formula id="ieqn-122"><mml:math id="mml-ieqn-122"><mml:mn>0.0854</mml:mn><mml:mtext>&#xA0;</mml:mtext><mml:mrow><mml:mi mathvariant="normal">m</mml:mi></mml:mrow></mml:math></inline-formula>. In contrast, WMC significantly improved the accuracy, achieving a maximum error of only <inline-formula id="ieqn-123"><mml:math id="mml-ieqn-123"><mml:mn>0.1516</mml:mn><mml:mtext>&#xA0;</mml:mtext><mml:mrow><mml:mi mathvariant="normal">m</mml:mi></mml:mrow></mml:math></inline-formula>, a mean of <inline-formula id="ieqn-124"><mml:math id="mml-ieqn-124"><mml:mn>0.0429</mml:mn><mml:mtext>&#xA0;</mml:mtext><mml:mrow><mml:mi mathvariant="normal">m</mml:mi></mml:mrow></mml:math></inline-formula>, and a standard deviation of <inline-formula id="ieqn-125"><mml:math id="mml-ieqn-125"><mml:mn>0.0235</mml:mn><mml:mtext>&#xA0;</mml:mtext><mml:mrow><mml:mi mathvariant="normal">m</mml:mi></mml:mrow></mml:math></inline-formula>. To illustrate the performance differences under various synchronization stages, two sample time windows were analyzed. In the early stage, shown in <xref ref-type="fig" rid="fig-8">Fig. 8a</xref>, the position error in Chrony exceeded <inline-formula id="ieqn-126"><mml:math id="mml-ieqn-126"><mml:mn>0.4</mml:mn><mml:mtext>&#xA0;</mml:mtext><mml:mrow><mml:mi mathvariant="normal">m</mml:mi></mml:mrow></mml:math></inline-formula>, while WMC reduced this to less than 10% of that error. During the stable stage (<xref ref-type="fig" rid="fig-8">Fig. 8b</xref>), however, the difference between the two methods became less dominant, suggesting that the benefit of WMC is most significant during initial synchronization periods. These results collectively confirm that time synchronization plays a critical role in high-precision distributed localization, particularly in the early phases of cooperative motion. Meanwhile, the case with 60 nodes is shown in <xref ref-type="fig" rid="fig-8">Fig. 8c</xref> and <xref ref-type="fig" rid="fig-8">8d</xref>. Chrony experienced a maximum localization error of <inline-formula id="ieqn-127"><mml:math id="mml-ieqn-127"><mml:mn>1.5483</mml:mn><mml:mtext>&#xA0;</mml:mtext><mml:mrow><mml:mi mathvariant="normal">m</mml:mi></mml:mrow></mml:math></inline-formula> due to the increased packet exchanges, whereas that of WMC remained low at <inline-formula id="ieqn-128"><mml:math id="mml-ieqn-128"><mml:mn>0.1282</mml:mn><mml:mtext>&#xA0;</mml:mtext><mml:mrow><mml:mi mathvariant="normal">m</mml:mi></mml:mrow></mml:math></inline-formula>.</p>
<fig id="fig-6">
<label>Figure 6</label>
<caption>
<title>Simulation environment (SUMO)</title>
</caption>
<graphic mimetype="image" mime-subtype="tif" xlink:href="CMC_66304-fig-6.tif"/>
</fig><fig id="fig-7">
<label>Figure 7</label>
<caption>
<title>Fr&#x00E9;chet distance between ground truth and offset trajectories</title>
</caption>
<graphic mimetype="image" mime-subtype="tif" xlink:href="CMC_66304-fig-7.tif"/>
</fig><fig id="fig-8">
<label>Figure 8</label>
<caption>
<title>Positional estimation under different synchronization stages (6/60 vehicles)</title>
</caption>
<graphic mimetype="image" mime-subtype="tif" xlink:href="CMC_66304-fig-8.tif"/>
</fig>
</sec>
</sec>
<sec id="s5">
<label>5</label>
<title>Conclusion</title>
<p>To provision emergency time synchronization in vehicular networks where primary clock sources may become unavailable, we proposed WMC, a one-way time synchronization method based on WLAN broadcasts. For the design of WMC, we analyzed the timing uncertainty caused by the departure of beacon frames from the server and their arrival at each individual client, dividing the process into an initial stage and a stable stage. In the initial stage, we proposed an approach that reflects the effects of beacon sequence omissions and reception delay variation. For the stable stage, we applied a hard update mechanism based on Maximum Likelihood Estimation (MLE), one of the most widely used techniques in time synchronization. Experimental results show that WMC reduces convergence time more effectively than Chrony and MLE-based hard updates under initial conditions. Furthermore, the transition to MLE in the stable stage achieves a synchronization accuracy of 34.49 <inline-formula id="ieqn-129"><mml:math id="mml-ieqn-129"><mml:mrow><mml:mi mathvariant="normal">&#x0B5;</mml:mi></mml:mrow></mml:math></inline-formula>s, demonstrating a <inline-formula id="ieqn-130"><mml:math id="mml-ieqn-130"><mml:mn>33.6</mml:mn><mml:mi mathvariant="normal">&#x0025;</mml:mi></mml:math></inline-formula> improvement over Chrony&#x2019;s 46.07 <inline-formula id="ieqn-131"><mml:math id="mml-ieqn-131"><mml:mrow><mml:mi mathvariant="normal">&#x0B5;</mml:mi></mml:mrow></mml:math></inline-formula>s. The results of the synchronization methods were applied to the localization application in the SUMO simulation, where synchronization was shared from a reference vehicle. Compared to Chrony, the proposed method achieved an average improvement of <inline-formula id="ieqn-132"><mml:math id="mml-ieqn-132"><mml:mn>38.5</mml:mn><mml:mi mathvariant="normal">&#x0025;</mml:mi></mml:math></inline-formula> and up to <inline-formula id="ieqn-133"><mml:math id="mml-ieqn-133"><mml:mn>74.2</mml:mn><mml:mi mathvariant="normal">&#x0025;</mml:mi></mml:math></inline-formula> at peak.</p>
<p>As future work, we plan to investigate how WMC can complement widely used synchronization protocols such as Chrony and the Precision Time Protocol (PTP) in a hybrid or cooperative synchronization framework.</p>
</sec>
</body>
<back>
<ack>
<p>We would like to extend our sincere appreciation to the editor and reviewers for their valuable feedback and constructive comments, which greatly improved the quality of this paper.</p>
</ack>
<sec>
<title>Funding Statement</title>
<p>This work was supported by Korea Institute of Energy Technology Evaluation and Planning (KETEP) grant funded by the Korea government (MOTIE) (No. 20224B10300090) and also supported by the MSIT (Ministry of Science and ICT), Republic of Korea, under the ITRC (Information Technology Research Center) support program (IITP-2025-RS-2021-II211835) supervised by the IITP (Institute of Information &#x0026; Communications Technology Planning &#x0026; Evaluation).</p>
</sec>
<sec>
<title>Author Contributions</title>
<p>The authors confirm contribution to the paper as follows: Conceptualization, Hyeontae Joo and Hwangnam Kim; methodology, Hyeontae Joo and Hwangnam Kim; software, Hyeontae Joo and Kiseok Kim; validation, Hyeontae Joo, Kiseok Kim and Hwangnam Kim; formal analysis, Hyeontae Joo and Sangmin Lee; investigation, Hyeontae Joo and Kiseok Kim; resources, Hyeontae Joo; data curation, Hyeontae Joo and Sangmin Lee; writing&#x2014;original draft preparation, Hyeontae Joo, Sangmin Lee, kiseok Kim and Hwangnam Kim; writing&#x2014;review and editing, Hyeontae Joo and Hwangnam Kim; visualization, Hyeontae Joo; supervision, Hwangnam Kim; project administration, Hwangnam Kim; funding acquisition, Hwangnam Kim. All authors reviewed the results and approved the final version of the manuscript.</p>
</sec>
<sec sec-type="data-availability">
<title>Availability of Data and Materials</title>
<p>Data sharing not applicable.</p>
</sec>
<sec>
<title>Ethics Approval</title>
<p>This study did not involve human participants or animal subjects. Ethical approval is not applicable.</p>
</sec>
<sec sec-type="COI-statement">
<title>Conflicts of Interest</title>
<p>The authors declare no conflicts of interest to report regarding the present study.</p>
</sec>
<ref-list content-type="authoryear">
<title>References</title>
<ref id="ref-1"><label>[1]</label><mixed-citation publication-type="journal"><person-group person-group-type="author"><string-name><surname>Romanov</surname> <given-names>AM</given-names></string-name>, <string-name><surname>Gringoli</surname> <given-names>F</given-names></string-name>, <string-name><surname>Sikora</surname> <given-names>A</given-names></string-name></person-group>. <article-title>A precise synchronization method for future wireless TSN networks</article-title>. <source>IEEE Trans Ind Inform</source>. <year>2020</year>;<volume>17</volume>(<issue>5</issue>):<fpage>3682</fpage>&#x2013;<lpage>92</lpage>. doi:<pub-id pub-id-type="doi">10.1109/tii.2020.3017016</pub-id>.</mixed-citation></ref>
<ref id="ref-2"><label>[2]</label><mixed-citation publication-type="journal"><person-group person-group-type="author"><string-name><surname>Seijo</surname> <given-names>O</given-names></string-name>, <string-name><surname>Lopez-Fernandez</surname> <given-names>JA</given-names></string-name>, <string-name><surname>Val</surname> <given-names>I</given-names></string-name></person-group>. <article-title>w-SHARP: implementation of a high-performance wireless time-sensitive network for low latency and ultra-low cycle time industrial applications</article-title>. <source>IEEE Trans Ind Inform</source>. <year>2020</year>;<volume>17</volume>(<issue>5</issue>):<fpage>3651</fpage>&#x2013;<lpage>62</lpage>. doi:<pub-id pub-id-type="doi">10.1109/tii.2020.3007323</pub-id>.</mixed-citation></ref>
<ref id="ref-3"><label>[3]</label><mixed-citation publication-type="journal"><person-group person-group-type="author"><string-name><surname>Mahmood</surname> <given-names>A</given-names></string-name>, <string-name><surname>Ashraf</surname> <given-names>MI</given-names></string-name>, <string-name><surname>Gidlund</surname> <given-names>M</given-names></string-name>, <string-name><surname>Torsner</surname> <given-names>J</given-names></string-name>, <string-name><surname>Sachs</surname> <given-names>J</given-names></string-name></person-group>. <article-title>Time synchronization in 5G wireless edge: requirements and solutions for critical-MTC</article-title>. <source>IEEE Commun Magaz</source>. <year>2019</year>;<volume>57</volume>(<issue>12</issue>):<fpage>45</fpage>&#x2013;<lpage>51</lpage>. doi:<pub-id pub-id-type="doi">10.1109/mcom.001.1900379</pub-id>.</mixed-citation></ref>
<ref id="ref-4"><label>[4]</label><mixed-citation publication-type="journal"><person-group person-group-type="author"><string-name><surname>Guo</surname> <given-names>X</given-names></string-name>, <string-name><surname>Liu</surname> <given-names>K</given-names></string-name>, <string-name><surname>Meng</surname> <given-names>Z</given-names></string-name>, <string-name><surname>Li</surname> <given-names>X</given-names></string-name>, <string-name><surname>Yang</surname> <given-names>J</given-names></string-name></person-group>. <article-title>Pseudolite-based lane-level vehicle positioning in highway tunnel</article-title>. <source>IEEE Trans Intell Transp Syst</source>. <year>2023</year>;<volume>25</volume>(<issue>2</issue>):<fpage>1612</fpage>&#x2013;<lpage>24</lpage>. doi:<pub-id pub-id-type="doi">10.1109/tits.2023.3314520</pub-id>.</mixed-citation></ref>
<ref id="ref-5"><label>[5]</label><mixed-citation publication-type="journal"><person-group person-group-type="author"><string-name><surname>Bozorgzadeh</surname> <given-names>E</given-names></string-name>, <string-name><surname>Barati</surname> <given-names>H</given-names></string-name>, <string-name><surname>Barati</surname> <given-names>A</given-names></string-name></person-group>. <article-title>3DEOR: an opportunity routing protocol using evidence theory appropriate for 3D urban environments in VANETs</article-title>. <source>IET Commun</source>. <year>2020</year>;<volume>14</volume>(<issue>22</issue>):<fpage>4022</fpage>&#x2013;<lpage>8</lpage>. doi:<pub-id pub-id-type="doi">10.1049/iet-com.2020.0473</pub-id>.</mixed-citation></ref>
<ref id="ref-6"><label>[6]</label><mixed-citation publication-type="journal"><person-group person-group-type="author"><string-name><surname>Azhdari</surname> <given-names>MS</given-names></string-name>, <string-name><surname>Barati</surname> <given-names>A</given-names></string-name>, <string-name><surname>Barati</surname> <given-names>H</given-names></string-name></person-group>. <article-title>A cluster-based routing method with authentication capability in Vehicular Ad hoc Networks (VANETs)</article-title>. <source>J Parallel Distrib Comput</source>. <year>2022</year>;<volume>169</volume>(<issue>12</issue>):<fpage>1</fpage>&#x2013;<lpage>23</lpage>. doi:<pub-id pub-id-type="doi">10.1016/j.jpdc.2022.06.009</pub-id>.</mixed-citation></ref>
<ref id="ref-7"><label>[7]</label><mixed-citation publication-type="journal"><person-group person-group-type="author"><string-name><surname>Huan</surname> <given-names>X</given-names></string-name>, <string-name><surname>Chen</surname> <given-names>W</given-names></string-name>, <string-name><surname>Wang</surname> <given-names>T</given-names></string-name>, <string-name><surname>Hu</surname> <given-names>H</given-names></string-name>, <string-name><surname>Zheng</surname> <given-names>Y</given-names></string-name></person-group>. <article-title>A one-way time synchronization scheme for practical energy-efficient lora network based on reverse asymmetric framework</article-title>. <source>IEEE Trans Commun</source>. <year>2023</year>;<volume>71</volume>(<issue>11</issue>):<fpage>6468</fpage>&#x2013;<lpage>81</lpage>. doi:<pub-id pub-id-type="doi">10.1109/tcomm.2023.3305515</pub-id>.</mixed-citation></ref>
<ref id="ref-8"><label>[8]</label><mixed-citation publication-type="journal"><person-group person-group-type="author"><string-name><surname>Shi</surname> <given-names>F</given-names></string-name>, <string-name><surname>Li</surname> <given-names>H</given-names></string-name>, <string-name><surname>Yang</surname> <given-names>SX</given-names></string-name>, <string-name><surname>Tuo</surname> <given-names>X</given-names></string-name>, <string-name><surname>Lin</surname> <given-names>M</given-names></string-name></person-group>. <article-title>Novel maximum likelihood estimation of clock skew in one-way broadcast time synchronization</article-title>. <source>IEEE Trans Ind Electron</source>. <year>2019</year>;<volume>67</volume>(<issue>11</issue>):<fpage>9948</fpage>&#x2013;<lpage>57</lpage>. doi:<pub-id pub-id-type="doi">10.1109/tie.2019.2955427</pub-id>.</mixed-citation></ref>
<ref id="ref-9"><label>[9]</label><mixed-citation publication-type="journal"><person-group person-group-type="author"><string-name><surname>Wang</surname> <given-names>H</given-names></string-name>, <string-name><surname>Gong</surname> <given-names>P</given-names></string-name>, <string-name><surname>Yu</surname> <given-names>F</given-names></string-name>, <string-name><surname>Li</surname> <given-names>M</given-names></string-name></person-group>. <article-title>Clock offset and skew estimation using hybrid one-way message dissemination and two-way timestamp free synchronization in wireless sensor networks</article-title>. <source>IEEE Commun Lett</source>. <year>2020</year>;<volume>24</volume>(<issue>12</issue>):<fpage>2893</fpage>&#x2013;<lpage>7</lpage>. doi:<pub-id pub-id-type="doi">10.1109/lcomm.2020.3019521</pub-id>.</mixed-citation></ref>
<ref id="ref-10"><label>[10]</label><mixed-citation publication-type="conf-proc"><person-group person-group-type="author"><string-name><surname>Durairajan</surname> <given-names>R</given-names></string-name>, <string-name><surname>Mani</surname> <given-names>SK</given-names></string-name>, <string-name><surname>Sommers</surname> <given-names>J</given-names></string-name>, <string-name><surname>Barford</surname> <given-names>P</given-names></string-name></person-group>. <article-title>Time&#x2019;s forgotten: using NTP to understand internet latency</article-title>. In: <conf-name>Proceedings of the 14th ACM Workshop on Hot Topics in Networks (HotNets-XIV)</conf-name>. <conf-loc>New York, NY, USA</conf-loc>: <publisher-name>Association for Computing Machinery</publisher-name>; <year>2015</year>. p. <fpage>1</fpage>&#x2013;<lpage>7</lpage>. doi:<pub-id pub-id-type="doi">10.1145/2834050.2834108</pub-id>.</mixed-citation></ref>
<ref id="ref-11"><label>[11]</label><mixed-citation publication-type="conf-proc"><person-group person-group-type="author"><string-name><surname>Shin</surname> <given-names>M</given-names></string-name>, <string-name><surname>Park</surname> <given-names>M</given-names></string-name>, <string-name><surname>Oh</surname> <given-names>D</given-names></string-name>, <string-name><surname>Kim</surname> <given-names>B</given-names></string-name>, <string-name><surname>Lee</surname> <given-names>J</given-names></string-name></person-group>. <article-title>Clock synchronization for one-way delay measurement: a survey</article-title>. In: <comment>Kim Th, Adeli H, Robles RJ, Balitanas M, editors</comment>. <conf-name>Advanced communication and networking. ACN 2011. Communications in computer and information science</conf-name>. <volume>Vol. 199</volume>. <conf-loc>Berlin/Heidelberg</conf-loc>: <publisher-name>Springer</publisher-name>; <year>2011</year>. p. <fpage>1</fpage>&#x2013;<lpage>10</lpage>. doi:<pub-id pub-id-type="doi">10.1007/978-3-642-23312-8_1</pub-id>.</mixed-citation></ref>
<ref id="ref-12"><label>[12]</label><mixed-citation publication-type="journal"><person-group person-group-type="author"><string-name><surname>L&#x00E9;vesque</surname> <given-names>M</given-names></string-name>, <string-name><surname>Tipper</surname> <given-names>D</given-names></string-name></person-group>. <article-title>A survey of clock synchronization over packet-switched networks</article-title>. <source>IEEE Commun Surveys Tutorials</source>. <year>2016</year>;<volume>18</volume>(<issue>4</issue>):<fpage>2926</fpage>&#x2013;<lpage>47</lpage>.</mixed-citation></ref>
<ref id="ref-13"><label>[13]</label><mixed-citation publication-type="journal"><person-group person-group-type="author"><string-name><surname>Shim</surname> <given-names>H</given-names></string-name>, <string-name><surname>Joo</surname> <given-names>H</given-names></string-name>, <string-name><surname>Kim</surname> <given-names>K</given-names></string-name>, <string-name><surname>Park</surname> <given-names>S</given-names></string-name>, <string-name><surname>Kim</surname> <given-names>H</given-names></string-name></person-group>. <article-title>Provisioning high-precision clock synchronization between UAVs for low latency networks</article-title>. <source>IEEE Access</source>. <year>2024</year>;<volume>12</volume>:<fpage>190025</fpage>&#x2013;<lpage>38</lpage>. doi:<pub-id pub-id-type="doi">10.1109/access.2024.3516856</pub-id>.</mixed-citation></ref>
<ref id="ref-14"><label>[14]</label><mixed-citation publication-type="journal"><person-group person-group-type="author"><string-name><surname>Wang</surname> <given-names>H</given-names></string-name>, <string-name><surname>Lu</surname> <given-names>R</given-names></string-name>, <string-name><surname>Peng</surname> <given-names>Z</given-names></string-name>, <string-name><surname>Li</surname> <given-names>M</given-names></string-name></person-group>. <article-title>Clock synchronization with partial timestamp information for wireless sensor networks</article-title>. <source>Signal Process</source>. <year>2023</year>;<volume>209</volume>(<issue>3</issue>):<fpage>109036</fpage>. doi:<pub-id pub-id-type="doi">10.1016/j.sigpro.2023.109036</pub-id>.</mixed-citation></ref>
<ref id="ref-15"><label>[15]</label><mixed-citation publication-type="journal"><person-group person-group-type="author"><string-name><surname>Leng</surname> <given-names>M</given-names></string-name>, <string-name><surname>Wu</surname> <given-names>YC</given-names></string-name></person-group>. <article-title>Low-complexity maximum-likelihood estimator for clock synchronization of wireless sensor nodes under exponential delays</article-title>. <source>IEEE Trans Signal Process</source>. <year>2011</year>;<volume>59</volume>(<issue>10</issue>):<fpage>4860</fpage>&#x2013;<lpage>70</lpage>. doi:<pub-id pub-id-type="doi">10.1109/tsp.2011.2160857</pub-id>.</mixed-citation></ref>
<ref id="ref-16"><label>[16]</label><mixed-citation publication-type="conf-proc"><person-group person-group-type="author"><string-name><surname>Guchhait</surname> <given-names>A</given-names></string-name>, <string-name><surname>Karthik</surname> <given-names>RM</given-names></string-name></person-group>. <article-title>Joint minimum variance unbiased and maximum likelihood estimation of clock offset and skew in one-way packet transmission</article-title>. In: <conf-name>2015 IEEE 81st Vehicular Technology Conference (VTC Spring)</conf-name>. <conf-loc>Glasgow, UK</conf-loc>: <publisher-name>IEEE</publisher-name>; <year>2015</year>. p. <fpage>1</fpage>&#x2013;<lpage>6</lpage>. doi:<pub-id pub-id-type="doi">10.1109/VTCSpring.2015.7145899</pub-id>.</mixed-citation></ref>
<ref id="ref-17"><label>[17]</label><mixed-citation publication-type="journal"><person-group person-group-type="author"><string-name><surname>Shi</surname> <given-names>F</given-names></string-name>, <string-name><surname>Tuo</surname> <given-names>X</given-names></string-name>, <string-name><surname>Ran</surname> <given-names>L</given-names></string-name>, <string-name><surname>Ren</surname> <given-names>Z</given-names></string-name>, <string-name><surname>Yang</surname> <given-names>SX</given-names></string-name></person-group>. <article-title>Fast convergence time synchronization in wireless sensor networks based on average consensus</article-title>. <source>IEEE Trans Ind Inform</source>. <year>2019</year>;<volume>16</volume>(<issue>2</issue>):<fpage>1120</fpage>&#x2013;<lpage>9</lpage>. doi:<pub-id pub-id-type="doi">10.1109/tii.2019.2936518</pub-id>.</mixed-citation></ref>
<ref id="ref-18"><label>[18]</label><mixed-citation publication-type="journal"><person-group person-group-type="author"><string-name><surname>Wang</surname> <given-names>H</given-names></string-name>, <string-name><surname>Zou</surname> <given-names>Y</given-names></string-name>, <string-name><surname>Liu</surname> <given-names>X</given-names></string-name>, <string-name><surname>Meng</surname> <given-names>Z</given-names></string-name></person-group>. <article-title>A rapid time synchronization scheme using virtual links and maximum consensus for wireless sensor networks</article-title>. <source>IEEE Internet Things J</source>. <year>2024</year>;<volume>12</volume>(<issue>3</issue>):<fpage>3318</fpage>&#x2013;<lpage>29</lpage>. doi:<pub-id pub-id-type="doi">10.1109/jiot.2024.3480331</pub-id>.</mixed-citation></ref>
<ref id="ref-19"><label>[19]</label><mixed-citation publication-type="journal"><person-group person-group-type="author"><string-name><surname>Yang</surname> <given-names>P</given-names></string-name>, <string-name><surname>Duan</surname> <given-names>D</given-names></string-name>, <string-name><surname>Chen</surname> <given-names>C</given-names></string-name>, <string-name><surname>Cheng</surname> <given-names>X</given-names></string-name>, <string-name><surname>Yang</surname> <given-names>L</given-names></string-name></person-group>. <article-title>Multi-sensor multi-vehicle (MSMV) localization and mobility tracking for autonomous driving</article-title>. <source>IEEE Trans Veh Technol</source>. <year>2020</year>;<volume>69</volume>(<issue>12</issue>):<fpage>14355</fpage>&#x2013;<lpage>64</lpage>. doi:<pub-id pub-id-type="doi">10.1109/tvt.2020.3031900</pub-id>.</mixed-citation></ref>
<ref id="ref-20"><label>[20]</label><mixed-citation publication-type="journal"><person-group person-group-type="author"><string-name><surname>Min</surname> <given-names>H</given-names></string-name>, <string-name><surname>Li</surname> <given-names>Y</given-names></string-name>, <string-name><surname>Wu</surname> <given-names>X</given-names></string-name>, <string-name><surname>Wang</surname> <given-names>W</given-names></string-name>, <string-name><surname>Chen</surname> <given-names>L</given-names></string-name>, <string-name><surname>Zhao</surname> <given-names>X</given-names></string-name></person-group>. <article-title>A measurement scheduling method for multi-vehicle cooperative localization considering state correlation</article-title>. <source>Veh Commun</source>. <year>2023</year>;<volume>44</volume>(<issue>8</issue>):<fpage>100682</fpage>. doi:<pub-id pub-id-type="doi">10.1016/j.vehcom.2023.100682</pub-id>.</mixed-citation></ref>
</ref-list>
</back></article>