Multi-source clock fusion end-to-end verification method, device, equipment, medium and product

Abstract

Embodiments of the present application provide a multi-source clock fusion end-to-end verification method, device, equipment, medium and product, and relate to the field of communication networks. The method comprises: acquiring multi-source clock data collected at a terminal side, generating a global reference time based on the multi-source clock data; based on the global reference time, generating and injecting a cross-domain time sequence fingerprint for each link measurement or service request; collecting events from each layer of the link, mapping network side event times corresponding to the events to a time axis of the global reference time, and generating a link measurement package; reporting the link measurement package to the cloud, and based on the time axis and the global reference time, aggregating and reconstructing an end-to-end event chain in the cloud, which is used for end-to-end verification. The method of the present application significantly improves the accuracy of end-to-end link indicators, can meet the strict verification requirements of high reliability and low latency scenarios, and significantly reduces errors; improves the packet loss positioning and abnormal diagnosis capability, and can automatically reconstruct each link event chain.

Description

Technical Field

[0001] This application relates to the field of communication networks, and in particular to a method, apparatus, device, medium and product for end-to-end verification of multi-source clock fusion. Background Technology

[0002] With the development of networks, existing network environments are gradually incorporating new network architectures such as ultra-low latency communication, distributed massive MIMO (Multiple-Input Multiple-Output), integrated space-ground access, and multi-link converged transmission. End-to-end service paths are no longer limited to a single terrestrial base station or a single wireless link, but instead present a complex structure involving multiple domains, multiple nodes, and multiple hops.

[0003] In existing network environments, end-to-end service paths may involve multiple heterogeneous network domains (such as terrestrial base stations, satellites, backhaul links, etc.) and multi-hop nodes, with each node potentially having a significantly different clock architecture and time base. Meanwhile, terminals, as critical user-side devices, have multiple built-in clock sources that vary in accuracy, stability, and synchronization, causing the timestamps of link events collected by the terminal to not be precisely aligned with the network-side timestamps. This inconsistency in multi-source time bases makes it difficult for existing testing tools to accurately measure key network metrics such as end-to-end latency, jitter, and packet loss rate, and also hinders the location of problematic nodes.

[0004] Therefore, in the end-to-end verification of complex network links, there is a technical problem that the inconsistency of multiple source time bases leads to the inability to align timing sequences. Summary of the Invention

[0005] This application provides a multi-source clock fusion end-to-end verification method, apparatus, device, medium, and product to solve the technical problem of timing misalignment caused by inconsistent time bases among multiple sources in the end-to-end verification of complex network links.

[0006] Firstly, this application provides a multi-source clock fusion end-to-end verification method, including:

[0007] Acquire multi-source clock data collected from the terminal side, and generate a global reference time based on the multi-source clock data;

[0008] Based on global reference time, a cross-domain time sequence fingerprint is generated and injected for each link measurement or business request;

[0009] Events are collected from each layer of the link, and the network-side event time corresponding to each event is mapped to the time axis of the global reference time to generate link measurement packets;

[0010] The link measurement packets are reported to the cloud. The end-to-end event chain is aggregated and reconstructed in the cloud based on the timeline and global reference time. The end-to-end event chain is used for end-to-end verification.

[0011] Secondly, this application provides a multi-source clock fusion end-to-end verification device, comprising:

[0012] The reference time generation module is used to acquire multi-source clock data collected by the terminal side and generate a global reference time based on the multi-source clock data.

[0013] The fingerprint injection module is used to generate and inject cross-domain time-series fingerprints for each link measurement or service request based on a global reference time.

[0014] The measurement packet generation module is used to collect events from each layer of the link, map the network-side event time corresponding to each event to the time axis of the global reference time, and generate link measurement packets.

[0015] The event chain aggregation module is used to report link measurement packets to the cloud. In the cloud, based on the timeline and global reference time, the end-to-end event chain is aggregated and reconstructed. The end-to-end event chain is used for end-to-end verification.

[0016] Thirdly, this application provides an electronic device, including: a processor and a memory communicatively connected to the processor;

[0017] The memory stores the instructions that the computer executes;

[0018] The processor executes computer-executable instructions stored in memory to implement any of the methods of the first aspect.

[0019] Fourthly, this application provides a computer-readable storage medium storing computer-executable instructions, which, when executed by a processor, are used to implement the method of any one of the first aspects.

[0020] Fifthly, this application provides a computer program product, including a computer program that, when executed by a processor, implements the method of any one of the first aspects.

[0021] This application provides a multi-source clock fusion end-to-end verification method, apparatus, equipment, medium, and product. By eliminating time drift differences between the terminal and network sides through a global reference time, it achieves precise alignment of cross-domain events, solving the error problem caused by clock inconsistency in traditional methods. In complex link end-to-end verification scenarios such as direct satellite connections, the global reference time and link measurement packets ensure sub-millisecond latency measurement, meeting the high real-time requirements of industrial control, remote surgery, and other applications, and supporting ultra-low latency verification. Through a unified timeline, packet loss nodes can be tracked and retransmission behavior analyzed, improving fault diagnosis efficiency and enhancing packet loss location and anomaly diagnosis capabilities. Cloud aggregation supports differentiated playback and regression testing, facilitating comparison of performance changes under different network configurations and optimizing 6G network deployment strategies. It achieves cross-layer event acquisition and time correction without relying on vendor internal interfaces, lowering the testing threshold. It significantly improves the accuracy of end-to-end link metrics. It supports 6G ultra-low latency scenario verification, meeting the stringent verification requirements of high-reliability, low-latency scenarios such as industrial control and direct satellite connections, with significantly lower errors than traditional solutions. It enhances packet loss location and anomaly diagnosis capabilities. The system can automatically reconstruct each link event chain, making it easy to compare link performance under different network configurations and mobile scenarios. Attached Figure Description

[0022] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with this application and, together with the description, serve to explain the principles of this application.

[0023] Figure 1 A schematic diagram of a solution for link testing;

[0024] Figure 2 A flowchart illustrating a multi-source clock fusion end-to-end verification method provided in an embodiment of this application;

[0025] Figure 3 A schematic diagram of the structure of a multi-source clock fusion end-to-end verification device provided in this application embodiment;

[0026] Figure 4 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application.

[0027] The accompanying drawings illustrate specific embodiments of this application, which will be described in more detail below. These drawings and descriptions are not intended to limit the scope of the concept in any way, but rather to illustrate the concept of this application to those skilled in the art through reference to particular embodiments. Detailed Implementation

[0028] Exemplary embodiments will now be described in detail, examples of which are illustrated in the accompanying drawings. When the following description relates to the drawings, unless otherwise indicated, the same numbers in different drawings denote the same or similar elements. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with this application. Rather, they are merely examples of apparatuses and methods consistent with some aspects of this application as detailed in the appended claims.

[0029] It should be noted that the user information (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data used for analysis, data stored, data displayed, etc.) involved in this application are all information and data authorized by the user or fully authorized by all parties. Furthermore, the collection, storage, use, processing, transmission, provision, disclosure, and application of the relevant data all comply with the relevant laws, regulations, and standards of the relevant countries and regions, have taken necessary confidentiality measures, do not violate public order and good morals, and provide corresponding operation access points for users to choose to authorize or refuse.

[0030] Furthermore, the technical solution involved in this application, which involves big data analysis of user information (including but not limited to personal biometrics, identity data, consumption data, asset data, electronic terminal operation data, etc.) and the use of artificial intelligence technology for automated decision-making, and makes decisions that have a significant impact on personal rights based on the results of automated decision-making, provides users with corresponding operation entry points for users to choose to agree to or reject the results of automated decision-making; if the user chooses to reject, the process will proceed to the expert decision-making process.

[0031] It should be noted that the multi-source clock fusion end-to-end verification method, apparatus, equipment, medium and product provided in this application can be used in the field of communication networks, or in any field other than communication networks. The application field of the multi-source clock fusion end-to-end verification method, apparatus, equipment, medium and product in this application is not limited.

[0032] This application specifically describes the use cases of novel network architectures in 6G networks, such as distributed massive MIMO (Multiple-Input Multiple-Output), integrated satellite-ground access, and multi-link converged transmission. 6G networks introduce innovative features like ultra-low latency communication, distributed massive MIMO, integrated satellite-ground access, and multi-link converged transmission, enabling the interaction path between terminal devices and the network to move beyond a single base station or link. Instead, it involves the collaboration of multiple network domains, including terrestrial base stations, satellite links, backhaul networks, and the core network. For example, in industrial automation control scenarios, terminal devices need to collaborate with terrestrial base stations via satellite links to complete real-time data transmission to meet sub-millisecond latency requirements. In vehicle-to-everything (V2X) scenarios, vehicle terminals need to simultaneously communicate with roadside units, cloud servers, and satellite networks via multiple hops to achieve highly reliable, low-latency path planning.

[0033] However, traditional terminal link testing methods rely on the independent collection of application layer trigger time, Socket API (a set of application programming interfaces for network communication that allows programs to exchange data over the network) return values, or Radio layer (wireless interface layer) events. Their timestamps come from the system local time, network time, or base station broadcast time, respectively. However, there is a lack of a unified benchmark among these time sources, and there are drift differences ranging from seconds to milliseconds, making it difficult to accurately align events at different levels.

[0034] Figure 1 A schematic diagram of a link testing solution, such as... Figure 1As shown, existing technologies mainly address link testing issues through the following methods: a) Application layer testing tools: These tools record the sending and receiving times of application layer requests and calculate end-to-end latency by combining this with server-side logs. This approach relies on system time (SystemClock) or timestamps provided by the application layer, but it cannot distinguish the latency contributions from the radio access layer, core network, transmission link, and cloud processing, providing only a coarse-grained total latency metric. b) Operating system log analysis: This involves post-event analysis to determine events such as RRC (Radio Resource Control) state transitions, PDCP (Packet Data Convergence Protocol) sequence intervals, and TCP (Transmission Control Protocol) congestion states. However, the timestamps of different logs originate from different clock systems, lacking strict synchronization and only enabling approximate analysis, which is insufficient to meet the millisecond-level precision requirements of 6G scenarios. c) Network-side driven testing: This relies on key event timestamps provided by base stations, satellite link nodes, and core network equipment, and then matches terminal logs with network-side logs. Because the clock difference between the terminal and network sides typically ranges from milliseconds to tens of milliseconds, and the drift is uncontrollable, such solutions rely on complex offline alignment algorithms, making it difficult to achieve high-precision event alignment. Furthermore, existing technologies generally lack a lightweight "cross-domain timing tagging" mechanism that can be implemented within the permissions of ordinary Android applications, making it impossible to attach independent time fingerprints to each measurement link and difficult to use multi-source clock fusion algorithms for unified calibration of various events. For 6G scenarios involving satellite links, traditional solutions struggle to accommodate the clock reference differences between satellite and terrestrial networks.

[0035] Current testing practices suffer from the following key issues: First, the clock systems used in different network domains (base stations, satellites, and backhaul links) are not synchronized, resulting in a lack of unified timing between key uplink / downlink events and an inability to accurately reflect end-to-end performance. Second, the clock sources available to terminals are inconsistent in terms of accuracy and stability, making it impossible to uniformly calibrate multi-source timestamps. Third, there is a lack of a method to embed end-side "timing fingerprints" into link test packages, making it impossible for cloud-based or test control platforms to accurately reproduce the true timeline of each link event. Fourth, the time alignment error of existing tools often exceeds several milliseconds, failing to support high-reliability verification requirements. Fifth, existing link testing tools can only output single-point metrics, unable to automatically reconstruct the complete link event chain or decompose and analyze latency components, leading to low efficiency in fault location and optimization.

[0036] The multi-source clock fusion end-to-end verification method, apparatus, equipment, medium, and product provided in this application construct a terminal 6G link end-to-end verification method and system based on collaborative multi-source timing tagging. Through mechanisms such as end-side multi-clock fusion, cross-domain timing fingerprint packet construction, link event collection and weighted correction, and cloud timing chain reproduction, it achieves accurate verification of key indicators such as end-to-end latency composition, jitter sources, and packet loss nodes, aiming to solve the above-mentioned technical problems of existing technologies.

[0037] The technical solution of this application and how the technical solution of this application solves the above-mentioned technical problems are described in detail below with specific embodiments. These specific embodiments can be combined with each other, and the same or similar concepts or processes may not be described again in some embodiments. The embodiments of this application will now be described with reference to the accompanying drawings.

[0038] Figure 2 This application provides a flowchart illustrating an end-to-end verification method for multi-source clock fusion, as shown in the embodiments below. Figure 2 As shown, the method includes:

[0039] S201. Obtain multi-source clock data collected by the terminal side, and generate a global reference time based on the multi-source clock data.

[0040] In one example, a high-precision Global Reference Time (GRT) is continuously established and maintained on the terminal for unified alignment of all subsequent events. The GRT achieves sub-millisecond / millisecond stability when available (depending on the hardware environment) and can report its confidence level.

[0041] The input multi-source clock data can include: SystemClock (actual elapsed time wall-clock, currentTimeMillis), Monotonic time (elapsedRealtime / uptimeMillis), NTP network time protocol time (from the test server), Cell / base station time, GNSS global navigation satellite system time (provided by LocationManager), historical drift statistics (locally persisted, data from the most recent few minutes), etc. Outputs include Global Reference Time (GRT) and offset vector. Weight of each clock source With confidence level Clock stability metrics (jitter, drift rate).

[0042] S202. Based on global reference time, generate and inject cross-domain time sequence fingerprints for each link measurement or business request.

[0043] In one example, based on global reference time, a unique cross-domain time-series fingerprint is generated for each link measurement or critical business request. The cross-domain time-series fingerprint is transmitted with business traffic and identified in cloud and network-side logs to accurately bind terminal events with network / server events.

[0044] The inputs are: the current GRT and the offset vector. The system outputs the following data: device identifier (which can be anonymized) and session ID; metadata for this measurement (service type, QoS service quality slice, uplink / downlink traffic pattern, etc.); and random entropy or incrementing sequence number. Outputs include: fingerprint structure (FP) of the cross-domain time-series fingerprint, serialized string or binary field, check hash (for tamper prevention), and fingerprint field injected into outbound traffic or control channels.

[0045] S203. Collect events from each layer of the link, map the network-side event time corresponding to each event to the time axis of the global reference time, and generate link measurement packets.

[0046] In one example, events are collected from the RF layer to the application layer of the link, ensuring that each event has its original timestamp, corrected time, and association with FP_ID, forming a complete event sequence (EventStream) locally on the terminal for reporting or offline export. Inputs: Modem / Radio logs (if available), Kernel network events (sockets are network communication endpoints / programming interfaces provided by the kernel, acting as a bridge between the application and the network protocol stack; send / recv timestamps indicate the time data is transmitted from the application layer to the kernel / the time data arrives at the application layer from the kernel), application layer events (service-side timing points), system events (foreground / background states, used to identify when the application is currently running in the foreground; CPU frequency, the processor's current operating frequency; higher frequencies represent high-performance mode and may affect packet processing latency; thermal state, the device's current temperature level; high temperatures may trigger frequency throttling, affecting link latency stability), FP_ID fingerprint structure number (within the same session). Outputs: Local event queue (sorted by GRT), local index (sharded by FP_ID, time window, and event type).

[0047] The original timestamps of events from each layer are mapped to a unified GRT timeline, outputting an event stream `calibrated_ts` (calibrated timestamps), along with confidence and uncertainty estimates for each calibration, enabling weighted fusion and error decomposition in the cloud. Inputs: `orig_timestamp` (original timestamp, the local time source used during initial event acquisition for each layer) and `onotonic_sample` (monotonic clock sample value, a time sample obtained using a monotonic clock), the current GRT, and the offset vector for each event. Drift models and confidence levels for each source. Outputs: calibrated_ts for each event (in GRT), sigma for each event (uncertainty estimate), and calibration method metadata (such as weights used and model version).

[0048] The event stream is packaged with cross-domain time-series fingerprints and environmental metadata to generate a link measurement package.

[0049] S204. Upload the link measurement packets to the cloud, and reconstruct the end-to-end event chain in the cloud based on the timeline and global reference time.

[0050] In this embodiment of the application, the end-to-end event chain is used for end-to-end verification.

[0051] In one example, link measurement packets are reliably reported to the cloud; both real-time and non-real-time (batch processing) reporting modes are supported; data integrity, traceability, and privacy compliance are guaranteed. Inputs include: calibrated event streams (including calibrated_ts), current cross-domain time sequence fingerprint (FP), terminal device environment information (including cell, frequency band, carrier, satellite ID, CPU / battery info), session ID, and reporting policy configuration. Outputs include: reporting packets (structured, including signatures), and reporting confirmation / receipts (the cloud returns matched FP_ID, etc.).

[0052] Reporting link measurement packets to the cloud specifically includes:

[0053] 1. The link measurement packet structure includes: top layer, ... where the events section can be layered: critical information (must be reported) and extended information (can be reported as needed).

[0054] 2. Real-time vs. Batch Reporting Strategy: Real-time reporting: Triggering conditions are critical events (fingerprint injection, RRC switching, access failure, etc.), using a reliable low-latency channel (TLS over TCP, or a dedicated control channel); real-time packet size is limited (e.g., < 8 KB).

[0055] Batch reporting: Periodically (e.g., 5s / session end) package and compress the most recent events before reporting, supporting breakpoint resumption.

[0056] Dynamic adjustments based on network status: When the cellular signal is weak, key information is reported first, and details are reported later; the information is supplemented after the network returns to a good state.

[0057] 3. Compression, Encryption, and Signature: Differential encoding and compression are applied to the event array to reduce bandwidth consumption. Sensitive fields are encrypted (symmetric key or public key encryption); the entire packet undergoes integrity verification, and signature verification is performed in the cloud. If required by the platform, end-to-end encryption is supported, with the decryption key held in the cloud or decryption performed at the edge.

[0058] 4. Reporting Protocols and Endpoints: Provide REST (Representational State Transfer) / gRPC (gRPC Remote Procedure Call) API interfaces; require the server to return packet processing status. For real-time streaming, WebSocket or QUIC (Quick UDP Internet Connections) can be used to reduce handshake latency.

[0059] 5. Retry and Failure Recovery: A reliable transmission mechanism is used: packet splitting, acknowledgment, and retries (exponential backoff + latency jitter), and the number of successful / failed reports is recorded. For devices that have been offline for a long time, a local queue is maintained and reported in batches when the network is restored; old and expired data (exceeding the retention period) can be discarded and recorded statistically.

[0060] 6. Reporting Rate Control and Flood Prevention: In high-concurrency testing environments, a large number of devices may report simultaneously. To avoid cloud overload, the terminal implements rate control. Rate quotas are negotiated with the cloud before reporting (the token quota is obtained through the control channel when the session is established).

[0061] 7. Cloud Receipts and Link Confirmation: The cloud returns the status of each packet. If the cloud detects missing key fields or low confidence levels, it will return a list of missing items, and the terminal will resend the packet as needed.

[0062] 8. Logging and Auditing: The client retains reporting logs (sending time, packet ID, return status) for offline auditing and troubleshooting. Reports must not contain raw user data (such as actual payload content) unless explicitly used for testing and enabled with user consent.

[0063] It also includes verification and performance testing: a stress test reporting module under different bandwidth and latency scenarios (number of concurrent devices, packet size, packet loss rate) to verify packet loss retransmission logic and bandwidth usage strategies. The cloud provides simulated ACK packets to verify the robustness of the end-user retry strategy (no infinite loops, no surges).

[0064] In the cloud, using FP_ID as the core, multiple data sources such as terminal reports, base station logs, satellite logs, and server logs are aggregated to reconstruct a unified end-to-end event timeline, and to perform latency segmentation, packet loss location, and anomaly cause determination. In the cloud, inputs include: Terminal-reported MeasurementPackage (including event flow and FP), base station / satellite / backhaul / server logs (timestamps, event types), network topology and routing information (for path mapping), and a clock alignment table (time compensation information from the network side, which can be provided by the base station or operations and maintenance system). Outputs include: the reconstructed end-to-end event chain (unified timeline), latency values ​​and confidence intervals for each segment, anomaly location results (packet loss nodes, congestion points, scheduling delays), and a replay script (capable of driving simulation playback).

[0065] In one implementation scenario, the Android-based 6G link end-to-end verification method based on collaborative multi-source timing labeling may include: Step 1: Reading SystemClock / Monotonic; obtaining NTP / GNSS / Cell time; calculating the offset vector Δt and saving the sample window; weighted fusion / drift prediction. Generate GRT (Global Reference Time); Terminal resident clock fusion module. Startup: Load test tasks and scenario parameters; Step 2: Construct FP (ID, GRT, Δt, hash) based on GRT; Serialize and select injection method; Insert HTTP Header / QUIC Frame / UDP Payload or probe packet; Time fingerprint generator; Application layer trigger: APP_SEND / APP_RECV; Kernel / Socket layer time sampling; Modem / Radio layer logs (if available). Step 3: Multi-layer event collection and labeling; Event standardization: Add orig_ts, monotonic, current GRT, FP_ID; Unified event collector starts; Select mapping function f_src according to source; Online fitting of offset / drift parameters. Step 4: Event timestamp weighted correction; Calculate calibrated_ts and uncertainty sigma; Event timestamp corrector; Assemble MeasurementPackage (FP, events, env) according to time series; Sign / compress / differential encoding. Step 5: Measurement packet construction, compression, and reporting; real-time or batch reporting → transmission reliability (ACK / retry); measurement packet construction and reporting module; indexing terminal / base station / core network / server logs based on FP_ID; loading network-side clock compensation table. Step 6: Cloud aggregation and time-series chain reconstruction; mapping multi-source events to a unified timeline → merging / deduplication; cloud reception and aggregation; calculating latency by segment: air interface / backhaul / core network / server side; packet loss and retransmission location → root cause candidates; generating replay scripts and executing differentiated replay; generating visual reports, regression baselines, and alarms; end-to-end verification and analysis; result archiving, reproduction triggering, or termination. Anomalies: high uncertainty or matching failure → end-side resampling or retransmission; verification grading: ordinary App / engineering permissions determine collection depth; privacy compliance: desensitization / encryption / user authorization.

[0066] In another implementation scenario, it may also include: Multi-source clock acquisition and fusion calibration: Acquiring multi-source clock data (SystemClock, NTP, GNSS, base station time, etc.) from the terminal side through Android system API, NTP server interaction, GNSS module, and Telephony interface. The processing includes: Sampling and filtering: Acquiring the raw time of each clock source at a 2-second interval, and removing abnormal samples (such as samples with NTP RTT exceeding 200ms) through sliding window statistics (e.g., robust estimation, EWMA). Weight calculation: Dynamically allocating weights based on the stability of the clock sources (e.g., drift rate, signal quality) (e.g., GNSS has the highest priority). Fusion algorithm: Generating a global reference time (GRT) using weighted least squares fitting (WLS) with confidence, and outputting an offset vector Δt. Generating the current GRT timestamp and offset vector. This provides a unified benchmark for subsequent event calibration.

[0067] Multi-source clock fusion involves fusing multiple independent clock sources (such as SystemClock, NTP, and GNSS) into a unified time reference using an algorithm. For example, a terminal simultaneously collects SystemClock and GNSS time and generates a GRT using a weighted algorithm. The offset vector represents the deviation between each clock source and the GRT (e.g., Δ_sys = SystemClock - GRT). Weighted least squares fitting is a mathematical fitting method that reduces the impact of noise by assigning weights. For example, GNSS time is given a high weight, while NTP time is given a low weight to generate a more accurate GRT.

[0068] Cross-domain temporal fingerprint generation and injection: This involves analyzing the aforementioned GRT timestamps and offset vectors. The process also includes processing of business metadata (such as session ID and QoS slice), provided by the GRT generation module in step 1 and application layer event triggers. The processing includes: fingerprint structure definition: the design includes GRT, Structured fields such as session ID and verification hash (e.g., FP_ID, FP_VER). Fingerprint injection strategy: Generate fingerprints before sending business requests and inject them into traffic via HTTP custom headers, QUIC transmission parameters, or independent probe packets. Anti-tampering verification: Sign the fingerprint fields using HMAC-SHA256, and verify the signature in the cloud to ensure data integrity. Generate a time-series fingerprint with GRT and offset vector, and inject it into the link measurement packet to form a cross-domain association identifier. The time-series fingerprint contains structured data including a GRT timestamp and offset vector, used for cross-domain event association. For example, FP_ID = UUID, GRT_TS = microsecond-level timestamp. HMAC-SHA256 is a key-based hash algorithm used to ensure the integrity of fingerprint data. For example, a device key is used to generate a signature for the fingerprint fields. Probe packets are periodically sent independent data packets used to associate business traffic in scenarios where fingerprint injection is not possible.

[0069] In another implementation scenario, in a direct satellite connection scenario, a satellite orbit model (such as the SGP4 model) and a relativistic correction algorithm are introduced to dynamically predict the clock drift between the satellite and the ground terminal. The relative velocity between the satellite and the ground terminal is calculated using satellite orbit parameters (such as orbital altitude and inclination), and the deviation between GNSS time and ground base station time is corrected by incorporating relativistic effects (time dilation and gravitational redshift). This algorithm serves as a supplementary module in the multi-source clock fusion step 1, adjusting the weight allocation of GNSS time in real time to reduce the impact of differences in clock references between the satellite and the ground network.

[0070] By introducing satellite orbit models and relativistic corrections, clock drift errors caused by relative motion in integrated space-ground scenarios can be significantly reduced. When satellites move at high speeds, the deviation between GNSS time and ground base station time may increase due to relativistic effects. Dynamic correction and compensation can further improve the alignment accuracy of cross-domain event timestamps, which is particularly suitable for 6G scenarios where high-orbit satellites and ground terminals collaborate.

[0071] In another implementation scenario, lightweight machine learning models (such as XGBoost or LSTM) are introduced into multi-source clock fusion to dynamically adjust the weights of each clock source based on historical drift data, signal quality (such as GNSS HDOP, NTP RTT), and environmental factors (such as device temperature and battery level). The model learns the optimal weight allocation strategy for different scenarios through offline training and is deployed as a lightweight inference module on the terminal side, outputting weight parameters in real time for use in weighted least squares fitting (WLS). Dynamically adjusting weights through machine learning makes the generation of the GRT time base more adaptive. When GNSS signals are lost, the model can automatically increase the weight of NTP or base station time to ensure the stability of the GRT, thereby maintaining high-precision time alignment capabilities in different scenarios.

[0072] In another implementation scenario, in temporal fingerprint injection, differential coding and variable precision compression techniques are used to reduce the amount of fingerprint data. Specifically, this includes: (1) adjusting the offset vector Differential coding (i.e., compared with the previous fingerprint) is used. (1) Store the difference value instead of the absolute value directly; (2) Adjust the precision of the GRT timestamp dynamically according to the needs of the scenario (e.g., retain nanosecond level in URLLC scenario and microsecond level in ordinary scenario); (3) Encode the fingerprint field in binary TLV (Type-Length-Value) to reduce redundant fields.

[0073] Differential compression and variable precision coding can significantly reduce the transmission overhead of fingerprint packets, making it particularly suitable for scenarios with large-scale concurrent reporting from terminals. In integrated space-ground networks, when tens of thousands of terminals report fingerprints simultaneously, bandwidth consumption can be reduced, cloud aggregation efficiency can be improved, and the accuracy of cross-domain event correlation can be maintained.

[0074] In another implementation scenario, a lightweight event acquisition module (based on Android's BPF or eBPF technology) is designed for multi-layer event acquisition. This module captures critical events (such as Socket send / recv and PDCP packet assembly) in real time via kernel-level hooks, rather than relying on log parsing. Simultaneously, an asynchronous triggering mechanism is introduced: when the terminal detects a high-priority event (such as RRC switching or HARQ exception), event acquisition and reporting are immediately triggered, rather than waiting for periodic batch processing.

[0075] By employing kernel-level hooks to capture low-latency events and combining this with an asynchronous triggering mechanism to prioritize the reporting of critical events, the real-time performance and completeness of event collection are significantly improved. In URLLC scenarios, events with microsecond-level latency can be captured and reported instantly, ensuring that the cloud can analyze network anomalies in a timely manner and improving fault diagnosis efficiency.

[0076] In another implementation scenario, edge computing nodes (such as 5G UPF or MEC) are introduced as local aggregators during event timestamp calibration. The edge nodes receive event streams reported by terminals and perform preliminary calibration and local aggregation of the events based on a local clock synchronization protocol (such as PTP). Only the calibrated key events (such as event chains associated with FP_ID) are uploaded to the cloud. The cloud only needs to process the events pre-processed by the edge nodes, not the original event stream.

[0077] By performing local calibration and aggregation at edge nodes, the processing pressure on the cloud can be significantly reduced, and the efficiency of event chain reconstruction can be improved. In the vehicle-to-everything (V2X) scenario, the event streams of tens of thousands of vehicle terminals can be preprocessed at edge nodes, and the cloud only needs to process the event chains related to specific FP_IDs, thereby accelerating anomaly localization and network optimization decisions.

[0078] The multi-source clock fusion end-to-end verification method provided in this embodiment eliminates time drift differences between the terminal and the network side through a global reference time, achieving precise alignment of cross-domain events and solving the error problem caused by clock inconsistency in traditional methods. In complex link end-to-end verification scenarios such as direct satellite connections, the global reference time and link measurement packets ensure sub-millisecond latency measurement, meeting the high real-time requirements of industrial control, remote surgery, etc., and supporting ultra-low latency verification. Through a unified timeline, packet loss nodes can be tracked and retransmission behavior can be analyzed, improving fault diagnosis efficiency and enhancing packet loss location and anomaly diagnosis capabilities. Cloud aggregation supports differentiated playback and regression testing, facilitating comparison of performance changes under different network configurations and optimizing 6G network deployment strategies. Cross-layer event collection and time correction are achieved without relying on vendor internal interfaces, lowering the testing threshold. The accuracy of end-to-end link indicators is significantly improved. It supports 6G ultra-low latency scenario verification, meeting the stringent verification requirements of high-reliability, low-latency scenarios such as industrial control and direct satellite connections, with significantly lower errors than traditional solutions. Packet loss location and anomaly diagnosis capabilities are enhanced. The system can automatically reconstruct each link event chain, making it easy to compare link performance under different network configurations and mobile scenarios.

[0079] Optionally, a global reference time can be generated based on multi-source clock data, including: performing weighted least squares fitting on the multi-source clock data based on a preset sampling period to generate a global reference time.

[0080] In one example, generating a global reference time may include: 1. Sampling period and sampling window design: Sampling period: Default 2 seconds (configurable; can be shortened to 200–500ms in test scenarios; extended to 5–10s in power-saving or low-speed scenarios). Collect times from each source once within each sampling period, and store the most recent N=30 sampling points in a memory circular buffer for statistical analysis and filtering. Record sampling times using monotonic time (to avoid the impact of system time rollback on historical samples).

[0081] 2. Time reading order and original data records: Reading order: monotonic system NTP gnss Cell (by priority / availability). For each data point, save: {source, raw_time, monotonic_ts, rtt_estimate, sample_quality_flag}. Here, rtt_estimate is used to record round-trip latency during NTP / Server acquisition.

[0082] 3. NTP Acquisition and RTT Estimation: Interact with one or more test NTP servers to record the monotonic time when the request is sent and the monotonic time when the response arrives, and calculate RTT / 2 as latency compensation. If using an HTTPS API to acquire UTC, record the TCP / TLS establishment time and request body round-trip time to estimate latency. When the RTT exceeds a threshold (e.g., 200 ms), the NTP sample is marked as low confidence.

[0083] 4. Cell Time Acquisition: Obtain the cell ID, system frame number, base station timestamp (if readable), and relevant signal quality metrics via Android Telephony APIs (CellInfo, SignalStrength, or modem diag). If the base station only provides a relative frame number, map the absolute cell time using SystemFrameNumber and the sampling monophonic time (wrap-around needs to be considered). Record base station change / reselection events and reset cell time stability statistics after such events occur.

[0084] 5. GNSS Time: When GNSS fix is ​​available, read the GNSS UTC and record satellite visibility, positioning accuracy (HDOP / VDOP), and GNSS clock bias. Reduce the weight when the GNSS positioning reliability is low or the number of satellites is less than a threshold (e.g., 5).

[0085] 6. Statistical Filtering and Outlier Removal: Maintain sliding window statistics (mean, standard deviation, maximum, minimum, and drift rate) for each source. Use robust estimation (Median + MAD) to remove aberration samples (e.g., those with a shift exceeding 3). samples of MAD). An Exponentially Weighted Moving Average (EWMA) is used to estimate the drift rate to predict the short-term trend.

[0086] 7. Weight calculation strategy: The initial weights are sorted according to source reliability: GNSS (if available) > Cell (when stable) > NTP (low RTT) > System. For each source, calculate score_i = f(jitter, rtt, availability, recent_drift), and normalize the score as the weight w_i. If a source is unavailable or score_i < threshold, its weight is set to zero.

[0087] 8. Fusion algorithm (generating GRT): Basic formula: , wherein offset_i is the correction term that maps the source time to monotonic (estimated based on the current window). In actual implementation, Weighted Least Squares (WLS) fitting with confidence is adopted to reduce the influence of noise on GRT. The output simultaneously (after normalization), which is used by the cloud to determine the alignment confidence.

[0088] 9. Drift model and prediction compensation: A sliding window is used to fit linear drift (drift = a t + b), and linear prediction is used to correct the clock in a short time to reduce the deviation during the transmission period. If a drift mutation is detected (e.g., base station handover), fast recalibration is triggered (shortening the sampling period and updating the weight immediately).

[0089] 10. Local persistence and recovery: The latest N samples and weights, drift model parameters, and the last GRT are persisted in a local database (e.g., SQLite), so that the state can be quickly restored after a process restart or device restart. The persistence frequency is low (e.g., writing every 30s or when GRT changes greatly) to reduce SSD write amplification.

[0090] 11. Performance and power saving strategies: When the device is in low power or background, the sampling frequency is reduced; for key test scenarios, sampling is forcibly increased and the user or test app is prompted to obtain foreground permissions. For long-term running tests, batch reporting and differential reporting are used to reduce network consumption: only the complete offset vector when the weight mutates or when a fingerprint packet is received is uploaded.

[0091] It also includes a verification and debugging process: a diagnostic interface is provided internally (only for engineering mode) to export the latest N sample curves (original time and corrected deviation of each source) for offline analysis. Self-check process: cross-verify the deviation of NTP / Cell when GNSS is available and report anomalies.

[0092] Weighted least squares fitting is used to eliminate drift differences from multiple clock sources, generating a highly stable global reference time. By dynamically adjusting the weight allocation, it adapts to the accuracy variations of different time sources, thereby improving the consistency of the time base on the terminal side and avoiding the accumulation of drift errors caused by the failure of a single clock source.

[0093] Optionally, based on the global reference time, a cross-domain time sequence fingerprint is generated and injected for each link measurement or business request, including: obtaining the metadata of the link measurement; before the business request is sent, reading the global reference time based on the preset fingerprint structure, encrypting and generating the cross-domain time sequence fingerprint, and injecting the cross-domain time sequence fingerprint into the business traffic corresponding to the link measurement or business request.

[0094] In one example, generating and injecting a cross-domain time-series fingerprint for each link measurement or business request can include: 1. Fingerprint field definition and version control: using structured fields with a version number FP_VER (for future expansion).

[0095] For example, the suggested fields may include:

[0096]

[0097] Minimize sensitive fields: If privacy is involved (IMSI, IMEI), only upload the hashed / de-identified identifier or only the session-level anonymous ID.

[0098] 2. Fingerprint generation timing: Before a business request is prepared to be sent (e.g., the application layer initiates an HTTP request or probe packet), the fingerprint generation module is called to: read the latest GRT and offset_vec; generate FP_ID (using device-level random seed and monotonic time to avoid collisions); calculate HASH (using device key or session key) so that the cloud can verify that it has not been tampered with.

[0099] 3. Fingerprint Injection Strategy: Prioritize injection using application-layer controllable fields (high compatibility): HTTP: Custom header (e.g., X-Time-Fingerprint) or JSON body; QUIC / TCP: Use QUIC transport parameters or TCP options (if controllable); UDP: Include a custom payload prefix. For restricted environments, use a separate "fingerprint probe" packet for periodic broadcasting, associated with the business packet via SESSION_ID. For fingerprints requiring network-side parsing, synchronization fields can also be embedded in the control plane protocol (or dedicated probe link) of the operational / test network.

[0100] 4. Fingerprint Length and Compression: To reduce bandwidth, binary serialization (TLV) is used, and the offset vector is differentially encoded (relative to the previous fingerprint). Optional compression (gzip / deflate) is enabled for large-volume reporting scenarios.

[0101] 5. Tamper-proof and verification: The fingerprint contains an HMAC-256 key (negotiated between the test platform and the device during registration). Cloud-based signature verification checks the fingerprint's consistency. Abnormal fingerprints (failed verification or missing key fields) are marked in the cloud and reverted to coarse-grained alignment.

[0102] 6. Injection failure and rollback mechanism: If the business flow cannot directly contain fingerprint (third-party traffic), the terminal should send a separate fingerprint detection packet within the same session and mark the associated information (such as 5-tuple, port, session_cookie) so that the server can associate it.

[0103] 7. Privacy and Compliance: All uploaded fingerprints must adhere to the privacy policy: Sensitive user identification information must be anonymized or encrypted, and the full identifier should only be enabled with user or project authorization. The fingerprint upload function can be disabled in settings (disabled by default or requiring user authorization in non-test license scenarios).

[0104] It also includes verification and testing: In a laboratory environment, a set of requests with known fingerprints is constructed to ensure that the cloud can correctly identify and match the fingerprints in multi-source logs (100% matching rate). For situations where network middleware (such as CDN, proxy) may remove or modify headers, a redundant probe packet method is used to ensure matching reliability.

[0105] By generating cross-domain time-series fingerprint packets, the cloud can match terminal and network-side logs through fingerprint packets, thereby achieving cross-domain association of terminal and network-side events. This solves the problem of missing cross-domain event association identifiers, enabling the cloud to automatically aggregate terminal and network-side logs and reconstruct a complete end-to-end event chain.

[0106] Optionally, events are collected from each layer of the link, and the network-side event times corresponding to each event are mapped to the time axis of the global reference time to generate a link measurement package. This includes: collecting events from each layer of the link, correcting the event timestamps, and constructing a local event sequence for the terminal; mapping the event timestamps to the time axis of the global reference time, obtaining the confidence and uncertainty of each event, correcting the event sequence based on the confidence and uncertainty to obtain an event stream; and packaging the event stream, cross-domain time sequence fingerprints, and metadata to generate a link measurement package.

[0107] In one example, collecting events from various layers of the link, correcting the event timestamps, and constructing a local event sequence on the terminal may include: 1. Event type definition and unified data model: uniformly defining event objects:

[0108]

[0109] It is recommended to use Protobuf / TLV for local serialization to enable efficient storage and reporting.

[0110] 2. Layered data collection implementation details: Application layer: Insert data points (through interceptors or framework layer) in key business paths (request initiation, data writing to socket, receiving response) to collect APP_SEND / APP_RECV events and record orig_timestamp (SystemClock) and monotonic.

[0111] Socket / Kernel Layer: Utilizes the Java / Android socket API to obtain the send / recv return time and reads SO_TIMESTAMPING (if available) provided by the kernel or uses tcp_info (obtained via nativebridge when authorized) to supplement TCP layer data.

[0112] Modem / Radio Layer: When engineering privileges or vendor interfaces are available, subscribe to modem diag, RIL, or telephony callbacks to obtain RRC / MAC / PHY events; under normal application privileges, try to obtain usable information (uplink / downlink rate estimation, signal quality, handover events) through TelephonyManager signaling / status callbacks and CellInfo. System Events: Record device load, CPU frequency, battery state, and thermodynamic events, as these can affect processing latency.

[0113] 3. Event Acquisition Channel and Buffer: Design an event bus (Producer-Consumer), with event collectors at each layer as producers and local serialization / reporting modules as consumers. Implement a priority strategy for event streams: critical time points (FP-related events, RRC switching, HARQ anomalies) are marked as high priority, prioritized for disk storage and real-time reporting; other events are buffered and reported in batches periodically.

[0114] 4. Event Deduplication and Merging Strategy: The network stack may generate duplicate or similar events (e.g., multiple socket callbacks). Deduplication is performed using event fingerprints (five-tuple + seq + timestamp window). Highly related small events (such as consecutive TCP ACKs) can be merged and summarized to reduce the amount of reporting (retaining the first and last timestamps and counts).

[0115] 5. Event Labeling and FP Association: Each event is automatically injected with the currently active FP_ID (if there is no active FP, it is labeled null and an attempt is made to associate it using session mapping during reporting). For events whose FP cannot be determined immediately (e.g., kernel-level callback lag), the monotonic timestamp is retained so that it can be mapped to the corresponding FP later using local GRT filtering.

[0116] 6. Local Storage Format and Lifecycle: Local event queues are written to a lightweight database (SQLite) or files (sharded by session). For high-frequency data collection, binary compressed files must be used. Storage Retention Policy: 24–72 hours for ordinary user scenarios; longer retention times (7–30 days) can be configured for test / engineering modes. Hierarchical encrypted storage is implemented for retained events (sensitive data is encrypted).

[0117] 7. Hierarchical Permission Implementation: Functions implemented under normal application permissions include: application-layer event tracking, Socket timekeeping, some system information, and CellInfo; under vendor / engineering permissions, modem logs, the dialog interface, and more granular physical layer event collection can be enabled. Two sets of capabilities are designed: a capability description layer declared when the app starts and the permission requirements explained in the UI.

[0118] 8. Anomaly and Rollback Handling: If a source is temporarily unavailable (e.g., GNSS is not visible or the modem interface fails), events are still collected but tagged as low confidence; different weighting strategies are used during cloud aggregation. For event reporting failures (network interruption), local persistence is used and retrying is performed according to priority when the network recovers; to avoid flooding, exponential backoff + random jitter is used.

[0119] It also includes verification recommendations: constructing synthetic traffic and verifying, under a known network topology, that the collected event sequences can be completely reconstructed from the transmitted data. physics The received link. Compare the kernel / application / module logs using a differential method to verify that the time mapping error is within an acceptable range (target: <1ms in engineering mode; <10ms in normal application scenarios).

[0120] The process maps the "raw timestamps" of events at each level to a unified GRT timeline, outputting `calibrated_ts` and providing confidence and uncertainty estimates for each calibration, enabling weighted fusion and error decomposition in the cloud. Specifically, this includes: 1. Establishing a mapping function from source to GRT: For each source (sys, ntp, gnss, cell, monotonic), a mapping `f_src(original_ts, monotonic_sample) -> GRT` is established. The mapping consists of two parts: a constant offset and time scaling. Among them, a_src is used to handle rate difference (drift rate), b_src is a fixed offset, and c_src is used to incorporate monotonic time into the correction (to cope with source time discontinuity).

[0121] 2. Online fitting parameter correction: Use the most recent M events (M is configurable, 30–200 recommended) to perform local least squares fitting to obtain a_src and b_src. If the fitting conditions are insufficient (small sample size or unstable source), revert to the last known parameters or use the default offset.

[0122] 3. Weighted Correction and Uncertainty Estimation: For a single event, a Bayesian update approach is used: the original uncertainty (sigma_src) from the source is combined with the fitted residual to obtain the event-level uncertainty. If an event contains multiple time information (e.g., an event has both kernel monotonic time and system time), use the covariance matrix to perform joint optimal estimation (BLUE or Kalman filter single-step fusion).

[0123] 4. Real-time Kalman Filtering (Optional): For high-precision scenarios, a one-dimensional Kalman filter is used to track the offset and drift rate (state vector [offset, drift]) of each source. Upon arrival of a new sample, a prediction-update step is performed, outputting the current optimal offset for mapping.

[0124] 5. Handling Network-induced Delay: For NTP or Server time samples, consider the uncertainty of RTT / 2 and incorporate it into sigma_ntp. For Cell time, consider the base station's internal processing delay (backhaul from the core to the base station) and add an estimated value to the offset vector (this step can be achieved by negotiating with the base station management to obtain higher quality data).

[0125] 6. Final Calculation and Labeling: Calculate `calibrated_ts` and add it to the event object: `event.calibrated_ts = f_src(event.orig_timestamp)`. Simultaneously, write `event.calibrated_sigma` and `event.calibrated_method` (labeling uses WLS / Kalman / SimpleOffset). If `calibrated_sigma` exceeds the threshold (e.g., >50 ms), mark the event as low confidence and notify the cloud in the report so that it is downweighted during aggregation.

[0126] 7. Error propagation and link-level uncertainty: When reconstructing the link in the cloud, the error propagation method is used to accumulate the uncertainty of each segment (variance superposition) for the final confidence interval report and error attribution.

[0127] 8. Anomaly Detection: If the number of drifts from a single source exceeds N times the historical average (e.g., 5...). This triggers an alarm and forces a resampling to confirm whether it is a base station handover or a hardware clock error.

[0128] It also includes verification and performance: using a laboratory-controlled base station and a known time reference (atomic clock or high-precision GNSS), the difference between the calibrated_ts of each event and the real time is statistically compared. The target error is <1ms in engineering mode and <10ms in ordinary application scenarios (depending on equipment and network conditions).

[0129] By mapping to the timeline and utilizing multi-source clock fusion to eliminate terminal-side time drift, the cloud-based aggregation algorithm uses a global reference time to align terminal and network-side events, significantly improving time alignment accuracy and meeting the requirements for 6G ultra-low latency verification. The cloud can accurately match terminal and network-side logs through fingerprint packets, achieving unified reconstruction of the event chain, thereby significantly improving time alignment accuracy and meeting the requirements for 6G ultra-low latency verification.

[0130] Optionally, in the cloud, based on the timeline and global reference time, the end-to-end event chain is aggregated and reconstructed, including: matching the global reference time and the network-side event time based on the link measurement packets, using the global reference time, and combining the error propagation model to quantify the uncertainty, and then aggregating and reconstructing the end-to-end event chain.

[0131] In one example, the aggregation and reconstruction of the end-to-end event chain may include: 1. Receiving layer and preprocessing: The cloud provides a high-throughput inbound interface (Kafka / gRPC streams) to receive MeasurementPackage and network logs.

[0132] Preliminary checks include: signature verification, decryption, and field integrity. If verification fails, the packet will be marked as abnormal and the terminal will be notified to resend it.

[0133] 2. Index and Route Matching: An index is built using FP_ID, the 5-tuple (srcIP, dstIP, srcPort, dstPort, proto), and session_id to associate terminal events with server logs. For base station and satellite logs, matching is performed using cell ID / satellite ID / time-window.

[0134] 3. Time Base Standardization: A "Time Offset Table" is maintained in the cloud to record the known offsets and uncertainties from various network nodes (base stations, UPFs, edges) to the cloud clock (provided by the network side or obtained through periodic probe measurements). Similar calibrated_ts calculations are also performed on the network-side logs, mapping them to a unified base in the cloud (usually cloud server UTC).

[0135] 4. Cross-Source Aggregation Algorithm: Based on FP_ID, events from multiple sources are merged into a multi-dimensional event chain according to calibrated_ts. Priority and confidence are used to fuse duplicate records of the same logical event (e.g., dedup is performed when the same PDCPSN appears in both terminal and base station logs). For events that cannot be directly matched (lacking FP_ID), probabilistic matching (maximum likelihood matching) is attempted using time windows and behavioral features (such as packet size and seq).

[0136] 5. Delay Segment Calculation: Divide the complete link into typical segments: UE_TX->eNodeB RX->eNodeBScheduler->Backhaul->UBF->AppServer RX / processing->Server TX->Backhaul->eNodeB TX->UE_RX. Calculate the delay for each segment: segment_delay = t_segment_end - t_segment_start, and provide a confidence interval using variance propagation.

[0137] 6. Packet Loss and Retransmission Location: Compare PDCP SN, TCP seq, and application-level seq to identify packet loss points. If a gap occurs in PDCP at a certain segment and the base station log shows no reception, it can be located as air interface packet loss; if the base station receives packets but the UPF is not seen, it indicates a backhaul link loss. HARQ retransmission counts, MAC retransmission flags, and TCP fast retransmission events are used to confirm the relationship between the physical layer and transport layer of packet loss.

[0138] 7. Anomaly Cause Determination: Based on rules and statistical models (threshold + pattern matching), the causes of anomalies are determined, such as weak signal (low RSRP), base station scheduling delay (high scheduler queue time), UPF processing timeout, server queue overflow, etc. For complex scenarios, decision trees or lightweight rule engines (non-machine learning explicit rules) can be used to provide preliminary causes and label confidence levels.

[0139] 8. Replay and Reproducibility: Based on the aggregated event chain, a replay script (sequence of timed actions) is generated. Replay can be executed in a cloud-based network simulator (such as Traffic Generator) or a laboratory environment. By generating similar arrival times and loads through replay, issues can be verified. Replay supports changing a single parameter (e.g., increasing return latency, decreasing signal strength) to conduct differentiated experiments to confirm causal relationships.

[0140] 9. Visualization and Reporting: Generates for each measurement: time series plot (Gantt), segmented delay table, packet loss heatmap, and anomaly diagnosis text report (with confidence level). Provides an API for upper-layer systems to query (GET / trace / {fp_id} returns the complete event chain and analysis results).

[0141] 10. Extension: Multi-device / multi-path aggregation: For multi-link or multi-antenna distributed scenarios (such as distributed antennas, satellite-to-ground fusion), it supports parallel aggregation of FPs from different UEs / antennas and performs merge analysis to determine which paths contribute to latency.

[0142] It also includes fault tolerance and security: for inconsistencies or conflicts, complete original data and conflict descriptions are recorded for manual review. Access control, auditing, and data anonymization are enabled when storing sensitive logs in the cloud.

[0143] This also includes validation and regression testing: injecting known latency and packet loss patterns into a sandbox environment to verify the recognition rate and positioning accuracy of cloud aggregation (target recognition rate >95%, positioning error <5ms at the segment level). Closed-loop testing of the playback mechanism is also conducted: the metrics generated by playback should be statistically reproducible to the original measurements.

[0144] Accurate correlation between terminal and network events is achieved through cross-domain time sequence fingerprinting packets. The global reference time and offset vector in the cross-domain time sequence fingerprinting are used to eliminate the inconsistency of cross-domain time bases, ensuring that the cloud can automatically aggregate terminal and network logs, and supporting latency segmentation analysis and anomaly localization.

[0145] Optionally, the method also includes: simulating link scenarios based on an end-to-end event chain using a pre-set replay script to verify the impact of network configuration changes on link performance and to perform automated regression testing.

[0146] In one example, differentiated replay (parameters are configurable) of any aggregated event chain is supported, along with automatic regression testing to verify the long-term impact of network changes or code / configuration adjustments on end-to-end performance. Inputs include: the aggregated event chain (including time points, load, and link status), replay parameters (latency amplification / reduction, packet loss rate, bandwidth adjustment, and signal quality modification), a test scenario description, and expected thresholds. Outputs include: replay results (time series plot, metric changes), and a regression test report (pass / fail status, regression difference points).

[0147] The specific implementation steps include: 1. Replay script generation: Converting the event chain into an executable action sequence (sendpacket at t, emulate HARQ loss at t', change CQI at t'', etc.). The script format supports multiple execution backends (traffic generator, network simulator, control API of real devices).

[0148] 2. Replay parameterization and differentiation: Provides parameter templates:

[0149]

[0150] During playback, single-dimensional or combined adjustments can be made to assess sensitivity (sensitivity analysis).

[0151] 3. Replay Execution and Data Acquisition: Execute the replay and collect complete logs during the replay using the same terminal data collector or cloud-side probe, performing the same alignment and analysis process as the actual measurement. During replay execution, generate intermediate replay checkpoints to identify nonlinear or unpredictable behavior.

[0152] 4. Automated Regression Testing: Compare replay results with the baseline (historically passed versions or the previous passed baseline): Compare whether key metrics (E2E latency, jitter, packet loss) are within the threshold; if they exceed the threshold, record the regression point and automatically create an issue ticket (including aggregated evidence and replay script). Supports triggering in CI / CD (e.g., performing a full regression before deploying a new network configuration) and sending the results back to the operations system via webhook.

[0153] 5. Reporting and Root Cause Support: Automatically generates reports with evidence chains (event chains, assertion failure points, replay scripts), including suggested troubleshooting steps (e.g., "The peak value of the UPF processing queue was located; it is recommended to increase the number of UPF instances or investigate server-side processing latency"). Supports exporting standardized log packages for in-depth analysis by vendors / operators.

[0154] 6. Operations / Alarm Integration: For high-priority requests (such as URLLC failure scenarios), trigger alarms when regressions are discovered during automatic playback, and automatically attach the playback script and raw data for the network management system to quickly reproduce the issue. Provide an API to the NOC / SON system to achieve automated rule triggering (e.g., automatically triggering playback and providing feedback when the frequency of a certain type of event exceeds a threshold).

[0155] It also includes verification: replaying common network adjustments (such as adding UPF instances or changing scheduling policies) to verify that the replay results can detect performance improvements or degradations.

[0156] By replaying scripts to simulate link scenarios, the system can automatically reconstruct each link event chain, making it easy to compare link performance under different network configurations and different mobile scenarios, and supporting cross-domain automated regression testing.

[0157] Figure 3 A schematic diagram of a multi-source clock fusion end-to-end verification device provided in this application embodiment is shown below. Figure 3 As shown, the multi-source clock fusion end-to-end verification device 40 provided in this embodiment includes:

[0158] The reference time generation module 301 is used to acquire multi-source clock data collected by the terminal side and generate a global reference time based on the multi-source clock data.

[0159] The fingerprint injection module 302 is used to generate and inject cross-domain time-series fingerprints for each link measurement or service request based on global reference time.

[0160] The measurement packet generation module 303 is used to collect events from each layer of the link, map the network-side event time corresponding to each event to the time axis of the global reference time, and generate link measurement packets.

[0161] The event chain aggregation module 304 is used to report link measurement packets to the cloud. In the cloud, based on the time axis and global reference time, the end-to-end event chain is aggregated and reconstructed. The end-to-end event chain is used for end-to-end verification.

[0162] In one possible implementation, the reference time generation module 301 is specifically used to: perform weighted least squares fitting on multi-source clock data based on a preset sampling period to generate a global reference time.

[0163] In one possible implementation, the fingerprint injection module 302 is specifically used to: obtain metadata of the link measurement; before the service request is sent, read the global reference time based on the preset fingerprint structure, encrypt and generate a cross-domain time sequence fingerprint, and inject the cross-domain time sequence fingerprint into the service traffic corresponding to the link measurement or service request.

[0164] In one possible implementation, the measurement package generation module 303 is specifically used to: collect events from each layer of the link, correct the event timestamps of the events, and construct the local event sequence of the terminal; map the event timestamps to the time axis of the global reference time, obtain the confidence and uncertainty of each event, correct the event sequence based on the confidence and uncertainty to obtain the event stream; and package the event stream, cross-domain time sequence fingerprint and metadata to generate a link measurement package.

[0165] In one possible implementation, the event chain aggregation module 304 is specifically used to: match the global reference time with the network-side event time based on the link measurement packet, use the global reference time, combine the error propagation model to quantify the uncertainty, and aggregate and reconstruct the end-to-end event chain.

[0166] In one possible implementation, the multi-source clock fusion end-to-end verification device is also specifically used to: simulate link scenarios based on an end-to-end event chain using a preset playback script to verify the impact of network configuration changes on link performance and perform automated regression testing.

[0167] The multi-source clock fusion end-to-end verification device provided in this embodiment can execute the method provided in the above method embodiment. Its implementation principle and technical effect are similar, and will not be described in detail here.

[0168] Figure 4 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. Figure 4As shown, the electronic device 40 may include a memory 401 and a processor 402. Optionally, the electronic device may also include a transceiver 403, wherein the memory 401 and the processor 402 communicate with each other; for example, the memory 401, the processor 402 and the transceiver 403 may communicate via a communication bus 404, the memory 401 is used to store a computer program, and the processor 402 executes the computer program to implement the method of the above embodiments.

[0169] Optionally, the aforementioned processor can be a Central Processing Unit (CPU), or other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), etc. The general-purpose processor can be a microprocessor or any conventional processor. The steps in the method embodiments disclosed in this application can be directly implemented by a hardware processor, or implemented by a combination of hardware and software modules within the processor.

[0170] This application also provides a computer-readable storage medium storing computer-executable instructions, which, when executed by a processor, implement the methods in any of the above method embodiments.

[0171] This application also provides a computer program product, including a computer program that, when executed by a processor, implements the methods in any of the above method embodiments.

[0172] All or part of the steps in the above method embodiments can be implemented by hardware related to program instructions. The aforementioned program can be stored in a readable memory. When the program is executed, it performs the steps of the above method embodiments; and the aforementioned memory (storage medium) includes: read-only memory (ROM), RAM, flash memory, hard disk, solid-state drive, magnetic tape, floppy disk, optical disk, and any combination thereof.

[0173] This application describes embodiments with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of this application. It should be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processing unit of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processing unit of the computer or other programmable data processing apparatus, generate instructions for implementing the flowchart illustrations. Figure 1 One or more processes and / or boxes Figure 1 A device that provides the functions specified in one or more boxes.

[0174] These computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing device to function in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means, which are implemented in a process Figure 1 One or more processes and / or boxes Figure 1 The function specified in one or more boxes.

[0175] These computer program instructions may also be loaded onto a computer or other programmable data processing equipment to cause a series of operational steps to be performed on the computer or other programmable equipment to produce a computer-implemented process, thereby providing instructions that execute on the computer or other programmable equipment for implementing the process. Figure 1 One or more processes and / or boxes Figure 1 The steps of the function specified in one or more boxes.

[0176] Obviously, those skilled in the art can make various modifications and variations to the embodiments of this application without departing from the spirit and scope of this application. Therefore, if these modifications and variations to the embodiments of this application fall within the scope of the claims of this application and their equivalents, this application also intends to include these modifications and variations.

[0177] In this application, the term "comprising" and its variations can refer to non-limiting inclusion; the term "or" and its variations can refer to "and / or". The terms "first", "second", etc., in this application are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. In this application, "multiple" refers to two or more. "And / or" describes the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent: A existing alone, A and B existing simultaneously, and B existing alone. The character " / " generally indicates that the preceding and following related objects have an "or" relationship.

[0178] It should be noted that, for the sake of simplicity, the foregoing method embodiments are all described as a series of actions. However, those skilled in the art should understand that this application is not limited to the described order of actions, as some steps may be performed in other orders or simultaneously according to this application. Furthermore, those skilled in the art should also understand that the embodiments described in the specification are all optional embodiments, and the actions and modules involved are not necessarily essential to this application.

[0179] It should be further noted that although the steps in the flowchart are shown sequentially according to the arrows, these steps are not necessarily executed in the order indicated by the arrows. Unless explicitly stated herein, there is no strict order restriction on the execution of these steps, and they can be executed in other orders. Moreover, at least some steps in the flowchart may include multiple sub-steps or multiple stages. These sub-steps or stages are not necessarily completed at the same time, but can be executed at different times. The execution order of these sub-steps or stages is not necessarily sequential, but can be performed alternately or in turn with other steps or at least some of the sub-steps or stages of other steps.

[0180] It should be understood that the above-described device embodiments are merely illustrative, and the device of this application can also be implemented in other ways. For example, the division of units / modules in the above embodiments is only a logical functional division, and there may be other division methods in actual implementation. For example, multiple units, modules, or components may be combined, or integrated into another system, or some features may be ignored or not executed.

[0181] Furthermore, unless otherwise specified, the functional units / modules in the various embodiments of this application can be integrated into one unit / module, or each unit / module can exist physically separately, or two or more units / modules can be integrated together. The integrated units / modules described above can be implemented in hardware or in the form of software program modules.

[0182] When integrated units / modules are implemented in hardware, the hardware can be digital circuits, analog circuits, etc. The physical implementation of the hardware structure includes, but is not limited to, transistors, memristors, etc. Unless otherwise specified, the processor can be any suitable hardware processor, such as a CPU, GPU, FPGA, DSP, and ASIC, etc. Unless otherwise specified, the storage unit can be any suitable magnetic or magneto-optical storage medium, such as Resistive Random Access Memory (RRAM), Dynamic Random Access Memory (DRAM), Static Random Access Memory (SRAM), Enhanced Dynamic Random Access Memory (EDRAM), High-Bandwidth Memory (HBM), Hybrid Memory Cube (HMC), etc.

[0183] If the integrated unit / module is implemented as a software program module and sold or used as an independent product, it can be stored in a computer-readable storage device (CMD). Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or all or part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a memory and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods of the various embodiments of this application. The aforementioned memory includes various media capable of storing program code, such as a USB flash drive, read-only memory (ROM), random access memory (RAM), portable hard drive, magnetic disk, or optical disk.

[0184] In the above embodiments, the descriptions of each embodiment have their own emphasis. For parts not described in detail in a certain embodiment, please refer to the relevant descriptions of other embodiments. The technical features of the above embodiments can be combined arbitrarily. For the sake of brevity, not all possible combinations of the technical features in the above embodiments are described. However, as long as the combination of these technical features does not contradict each other, it should be considered within the scope of this specification.

[0185] Other embodiments of this application will readily occur to those skilled in the art upon consideration of the specification and practice of the invention disclosed herein. This application is intended to cover any variations, uses, or adaptations of this application that follow the general principles of this application and include common knowledge or customary techniques in the art not disclosed herein. The specification and examples are to be considered exemplary only, and the true scope and spirit of this application are indicated by the following claims.

[0186] It should be understood that this application is not limited to the precise structure described above and shown in the accompanying drawings, and various modifications and changes can be made without departing from its scope. The scope of this application is limited only by the appended claims.

Claims

1. A multi-source clock fusion end-to-end verification method, characterized in that, The method includes: The system acquires multi-source clock data collected from the terminal side. Based on this multi-source clock data, a global reference time is generated. A lightweight machine learning model is introduced to dynamically adjust the weights of each clock source according to historical drift data, signal quality, and equipment environmental factors. The global reference time is then generated through weighted least squares fitting. The global reference time is maintained on the terminal side. The process of generating the global reference time includes: acquiring the global reference time and offset vector based on the terminal side's SystemClock, Monotonic monotonic time, NTP network time protocol time, Cell base station time, GNSS global navigation satellite system time, and historical drift statistics. Weight of each clock source With confidence level Clock stability metrics include jitter and drift rate; the offset vector represents the deviation between each clock source and the global reference time. Based on the global reference time, a cross-domain time-series fingerprint is generated and injected for each link measurement or service request, including: obtaining metadata of the link measurement; before the service request is sent, based on a preset fingerprint structure, reading the global reference time, encrypting and generating the cross-domain time-series fingerprint, and injecting the cross-domain time-series fingerprint into the service traffic corresponding to the link measurement or the service request; the global reference time is applied to the unified alignment of the link measurement or service request, and the cross-domain time-series fingerprint is used to bind the link measurement or service request with network / server events; enabling the cloud to automatically aggregate terminal and network-side logs and reconstruct a complete end-to-end event chain; the generation and injection of the cross-domain time-series fingerprint for each link measurement or service request includes: defining fingerprint fields; wherein, the fingerprint fields include the version number of the cross-domain time-series fingerprint, the ID of the cross-domain time-series fingerprint, the global reference time, the offset vector, SOURCE_MASK, FLAGS, session ID, and verification hash, the SOURCE_MASK is used to characterize the available clock, and the FLAGS is used to characterize whether it is a critical measurement or whether real-time aggregation is required; The process of collecting events from each layer of the link, mapping the network-side event timestamps corresponding to each event to the timeline of the global reference time, and generating a link measurement packet includes: collecting events from each layer of the link, correcting the event timestamps of the events, and constructing a local event sequence for the terminal; mapping the event timestamps to the timeline of the global reference time, obtaining the confidence and uncertainty of each event, correcting the event sequence based on the confidence and uncertainty to obtain an event stream; and packaging the event stream, the cross-domain time sequence fingerprint, and the metadata to generate the link measurement packet. The link measurement packets are reported to the cloud, where the end-to-end event chain is aggregated and reconstructed based on the time axis and the global reference time. The end-to-end event chain is used for end-to-end verification.

2. The method according to claim 1, characterized in that, The process of generating a global reference time based on the multi-source clock data includes: Based on a preset sampling period, the multi-source clock data is subjected to weighted least squares fitting to generate the global reference time.

3. The method according to claim 1, characterized in that, The process of aggregating and reconstructing the end-to-end event chain on the cloud based on the timeline and the global reference time includes: Based on the link measurement packet, the global reference time is matched with the network-side event time. Using the global reference time and the error propagation model, the uncertainty is quantified, and the end-to-end event chain is aggregated and reconstructed.

4. The method according to any one of claims 2 to 3, characterized in that, The method further includes: Based on the end-to-end event chain, a link scenario is simulated using a preset replay script to verify the impact of network configuration changes on the link performance and to perform automated regression testing.

5. A multi-source clock fusion end-to-end verification device, characterized in that, The device includes: The reference time generation module is used to acquire multi-source clock data collected by the terminal side and generate a global reference time based on the multi-source clock data. The fingerprint injection module is used to generate and inject cross-domain time-series fingerprints for each link measurement or service request based on the global reference time. The measurement packet generation module is used to collect events from each layer of the link, map the network-side event time corresponding to each event to the time axis of the global reference time, and generate link measurement packets. The event chain aggregation module is used to report the link measurement packets to the cloud, and on the cloud, based on the time axis and the global reference time, aggregate and reconstruct the end-to-end event chain, which is used for end-to-end verification. The device is further configured to introduce a lightweight machine learning model to dynamically adjust the weights of each clock source based on historical drift data, signal quality, and equipment environmental factors, and generate the global reference time through weighted least squares fitting; the global reference time is maintained on the terminal side; wherein, the process of generating the global reference time includes: obtaining the global reference time and offset vector based on the SystemClock system clock, Monotonic monotonic time, NTP network time protocol time, Cell base station time, GNSS global navigation satellite system time, and historical drift statistics on the terminal side. Weight of each clock source With confidence level Clock stability metrics include jitter and drift rate; the offset vector represents the deviation between each clock source and the global reference time. The device is further configured to acquire metadata of link measurements; before the service request is sent, based on a preset fingerprint structure, read the global reference time, encrypt and generate the cross-domain time-series fingerprint, and inject the cross-domain time-series fingerprint into the service traffic corresponding to the link measurement or the service request; the global reference time is applied to the unified alignment of the link measurement or the service request, and the cross-domain time-series fingerprint is used to bind the link measurement or the service request to network / server events; enabling the cloud to automatically aggregate the terminal and network-side logs and reconstruct a complete end-to-end event chain; generating and injecting a cross-domain time-series fingerprint for each link measurement or service request includes: defining fingerprint fields; wherein, the fingerprint fields include the version number of the cross-domain time-series fingerprint, the ID of the cross-domain time-series fingerprint, the global reference time, the offset vector, SOURCE_MASK, FLAGS, session ID, and verification hash, the SOURCE_MASK is used to characterize the available clock, and the FLAGS is used to characterize whether it is a critical measurement or whether real-time aggregation is required; The device is further configured to collect events from each layer of the link, correct the event timestamps of the events, and construct a local event sequence for the terminal; map the event timestamps to the time axis of the global reference time, obtain the confidence and uncertainty of each event, correct the event sequence based on the confidence and uncertainty to obtain an event stream; and package the event stream, the cross-domain time sequence fingerprint, and the metadata to generate the link measurement package.

6. An electronic device, characterized in that, include: A processor, and a memory communicatively connected to the processor; The memory stores computer-executed instructions; The processor executes computer execution instructions stored in the memory to implement the method as described in any one of claims 1 to 4.

7. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores computer-executable instructions, which, when executed by a processor, are used to implement the method as described in any one of claims 1 to 4.

8. A computer program product, characterized in that, Includes a computer program that, when executed by a processor, implements the method of any one of claims 1 to 4.

Images