Derivative works

Defensive Disclosure: Derivatives of US Patent 10959123

This document outlines derivative variations of the technology disclosed in US Patent 10959123, "Low latency wireless messaging," for the purpose of defensive publishing. The aim is to establish prior art that renders future incremental improvements or alternative implementations of similar low-latency wireless messaging systems obvious or non-novel to a Person Having Ordinary Skill in the Art (PHOSITA). The focus remains on encoding messages for latency reduction, dynamically determining transmission parameters based on latency and channel bandwidth, and utilizing ionospheric High Frequency (HF) bands.

---

Derivative Variations

1. Material & Component Substitution

Derivative 1.1: Software-Defined Radio (SDR) with Gallium Nitride (GaN) Power Amplifiers

• Enabling Description: The transmitting device, instead of discrete hardware components, employs a fully Software-Defined Radio (SDR) architecture where the carrier signal generation, modulation, and filtering are implemented as software modules executing on a high-performance FPGA or ASIC. The RF front-end integrates Gallium Nitride (GaN) high-power amplifiers (HPAs) for increased power efficiency and linearity over the HF spectrum (3-30 MHz) while maintaining the determined transmission power. The antenna may be a configurable log-periodic dipole array or an active loop antenna, selected dynamically based on determined elevation angle and frequency. The controller's determinators (frequency, modulation, power) directly configure the SDR's digital signal processing (DSP) blocks and the GaN HPA bias and gain settings to achieve precise control over spectral emission, ensuring compliance with the predefined channel bandwidth (e.g., 2.8 KHz FCC limit). The encoding logic is implemented in the SDR's baseband processing unit.

graph TD
    A[Request for Action] --> B(SDR Baseband Processing)
    B -- Encoded Message --> C{SDR Controller - FPGA/ASIC}
    C -- Param. Determ. (Latency, Bandwidth) --> D[SDR Digital Front-End]
    D -- RF Signal --> E(GaN High Power Amplifier)
    E -- Amplified RF --> F[Configurable Antenna Array]
    F --> G[Ionosphere HF Transmission]
    C -- Control --> D
    C -- Control --> E
    C -- Control --> F

Derivative 1.2: Metamaterial Antennas and Silicon-Germanium (SiGe) Transceivers

• Enabling Description: The system incorporates reconfigurable metamaterial antennas whose radiation patterns and impedance characteristics can be dynamically altered to optimize gain and directivity for varying ionospheric conditions (e.g., different elevation angles, hop counts) determined by the frequency determinator. The transceiver unit utilizes Silicon-Germanium (SiGe) BiCMOS technology for the RF mixer and synthesizer stages, offering superior noise performance and higher integration density, thereby reducing latency associated with component interconnects and signal processing overhead. The buffer determinator specifically considers the reduced sampling and processing latency capabilities of the SiGe transceiver for real-time adjustment of message buffering.

graph TD
    A[Controller (Param. Determ.)] --> B{SiGe Transceiver}
    B -- Modulated Signal --> C[Reconfigurable Metamaterial Antenna]
    C --> D[Ionospheric HF Transmission]
    A -- Control --> C
    A -- Data --> B
    B -- Low Latency RF --> C

Derivative 1.3: Cryogenically Cooled Low-Noise Amplifiers (LNAs) with Superconducting Filters

• Enabling Description: For applications demanding extreme signal integrity and minimal noise contribution to maximize SNR with reduced transmission power (e.g., when foregoing error correction), the receiving device incorporates cryogenically cooled Low-Noise Amplifiers (LNAs) for the HF band. Furthermore, the receiver front-end integrates high-Q superconducting filters (e.g., using YBCO thin films) to provide extremely sharp bandpass characteristics within the predefined channel bandwidth, thereby improving selectivity and further reducing noise. The transmitter may also utilize cryogenically cooled components in its output stage to improve efficiency and reduce harmonic distortion, allowing for more aggressive modulation schemes within the bandwidth constraints. The power determinator accounts for the enhanced SNR characteristics afforded by these components, potentially allowing for even lower transmission power for a given reliability target, further minimizing spectral footprint.

graph TD
    A[RF Signal (Weak)] --> B(Superconducting Filter)
    B --> C(Cryogenic LNA)
    C --> D[Demodulator/Decoder]
    D --> E[Processed Message]
    F[Transmitting Device] --> G[Cryogenic HPA (Optional)]
    G --> H[Antenna]
    H --> A

2. Operational Parameter Expansion

Derivative 2.1: Ultra-Long-Haul, Multi-Hop Ionospheric Relay for Intercontinental HFT

• Enabling Description: The system is configured for transcontinental or intercontinental low-latency financial messaging, involving multiple ionospheric hops (n > 2) and intermediate relay stations. The frequency determinator, in conjunction with a sophisticated ionospheric propagation model (e.g., using real-time solar flux data and ionosonde measurements), dynamically selects optimal carrier frequencies and elevation angles for each hop to minimize aggregate time-of-flight (τ). The power determinator adjusts transmission power at each relay to ensure adequate Signal-to-Noise Ratio (SNR) over each segment, compensating for path loss variations, while the modulation determinator selects robust yet spectrally efficient modulation (e.g., coherent PSK with minimal symbol constellation) that remains within the predefined channel bandwidth across all hops, accounting for cumulative spectral spreading. Message encoding for latency is paramount, and each relay station performs rapid re-buffering and re-transmission with minimal processing delay.

graph TD
    A[Tx Device] -->|Hop 1| B[Relay 1]
    B -->|Hop 2| C[Relay 2]
    C -->|Hop 3| D[Rx Device]
    A -- Param. Determ. --> B
    B -- Param. Determ. --> C
    C -- Param. Determ. --> D
    subgraph Ionosphere
        I1(Ionospheric Layer)
        I2(Ionospheric Layer)
        I3(Ionospheric Layer)
    end
    A -- Via --> I1
    B -- Via --> I2
    C -- Via --> I3

Derivative 2.2: Hyperspectral Bandwidth Utilization with Dynamic Channel Bonding

• Enabling Description: To maximize effective data rate for latency-critical messages within a highly restrictive regulatory environment, the system employs hyperspectral analysis and dynamic channel bonding. Instead of a single predefined 2.8 KHz channel, the system identifies and utilizes multiple non-contiguous narrow sub-channels within a broader allocated HF band, dynamically bonding them to form a virtual wider channel. The frequency determinator, informed by real-time spectral occupancy sensors, identifies available sub-channels that meet predefined interference criteria. The modulation determinator then applies a spread spectrum technique (e.g., direct-sequence spread spectrum or frequency hopping spread spectrum) across these bonded sub-channels, ensuring the overall spectral emission of the combined transmission still adheres to the total allocated bandwidth, and the power determinator adjusts power per sub-channel. Message encoding is further optimized for parallel transmission across these bonded channels. This allows higher effective data rates than a single narrow channel, reducing message size latency.

graph TD
    A[Controller] --> B{Spectral Analyzer}
    B -- Available Sub-channels --> C[Frequency Determinator]
    C -- Channel Assignment --> D[Modulation Determinator]
    D -- Param. per Sub-channel --> E[Transmitter Array]
    E -- Sub-channel 1 --> F1(HF Tx 1)
    E -- Sub-channel 2 --> F2(HF Tx 2)
    E -- Sub-channel N --> FN(HF Tx N)
    F1 & F2 & FN --> G[Dynamic Channel Bonded Transmission]
    A -- Constraint --> C
    A -- Constraint --> D
    A -- Data --> E

Derivative 2.3: Extremely Low Data Rate, High-Reliability "Beacon" Mode

• Enabling Description: For scenarios where minimal latency is still critical but the message is exceptionally small (e.g., a single-bit "event" trigger) and reliability over vast distances is paramount under adverse ionospheric conditions (e.g., during solar flares), the system operates in an "extremely low data rate, high-reliability beacon" mode. The encoding scheme reduces the message to its absolute minimum (e.g., 1-2 bits representing a specific predefined event). The modulation determinator selects a highly robust, low-bandwidth modulation type (e.g., CW or very slow FSK), potentially with significant temporal redundancy (e.g., transmitting the same short sequence multiple times over an extended period) without explicit error correction bits, relying on comparison of redundant transmissions at the receiver. The power determinator maximizes transmission power within regulatory limits, compensating for lack of error correction. This mode prioritizes successful transmission of minimal information over achieving high throughput, with message latency being the time from event occurrence to first successful reception, not total message delivery.

graph TD
    A[Event Trigger] --> B(Encode 1-2 Bits)
    B --> C[Modulation Determinator (Slow FSK/CW)]
    C --> D[Power Determinator (Max Power)]
    D --> E[Repetitive Transmission Engine]
    E --> F[Ionosphere (Adverse Conditions)]
    F --> G[Remote Receiver (Compares Redundancies)]
    C -- Set Modulation --> E
    D -- Set Power --> E

3. Cross-Domain Application

Derivative 3.1: Disaster Relief and Emergency Communications Network

• Enabling Description: In the event of catastrophic failure of conventional communication infrastructure (e.g., after an earthquake or hurricane), this low-latency HF messaging system is repurposed to transmit critical, coded emergency alerts and essential command & control messages over damaged regions. Remote ground stations or mobile units receive requests (e.g., "send medical team to grid X," "status report Y"). The system encodes these high-priority messages into minimal bit sequences (e.g., "01001" for "medical team needed," where '010' is location code and '01' is resource type), known a priori by all deployed relief units. Transmission parameters are dynamically determined based on predicted ionospheric conditions for the affected area (derived from local sensor data or satellite imagery) to achieve the fastest possible message delivery (low latency) within emergency-band HF channel bandwidths, even if these are wider or more flexible during declared emergencies.

graph TD
    A[Emergency Request (Mobile Unit)] --> B(Encode Critical Message)
    B --> C[Controller (Disaster Mode)]
    C -- Param. Determ. (Emergency Bandwidth) --> D[HF Transmitter]
    D --> E[Damaged Area Ionosphere]
    E --> F[Remote Relief Units (A priori codes)]
    C -- Control --> D

Derivative 3.2: Remote Environmental Monitoring for Arctic/Antarctic Research

• Enabling Description: Autonomous sensor platforms deployed in remote Arctic or Antarctic regions collect critical environmental data (e.g., ice thickness, temperature, seismic activity). These platforms generate requests to transmit urgent anomaly alerts (e.g., "rapid ice melt detected," "seismic event"). The system encodes these specific alerts into ultra-low-latency messages, with predefined bit sequences for each anomaly type and location ID, known to central research stations thousands of kilometers away. The transmission parameters are determined based on prevailing polar ionospheric propagation conditions (which are highly dynamic due to geomagnetic activity) to minimize latency, balancing against the limited channel bandwidths available for scientific data transmission. The system dynamically adjusts frequency and power to penetrate auroral absorption zones or utilize optimal polar cap propagation paths.

graph TD
    A[Autonomous Sensor (Arctic/Antarctic)] --> B(Anomaly Detection)
    B --> C{Encode Alert (Low Latency)}
    C --> D[Controller (Polar HF Optimization)]
    D -- Param. Determ. (Polar Ionosphere) --> E[HF Transmitter (Robust)]
    E --> F[Polar Ionosphere / Aurora]
    F --> G[Central Research Station]
    D -- Control --> E

Derivative 3.3: Maritime Asset Tracking and Critical Status Reporting

• Enabling Description: For tracking commercial shipping fleets or remote naval assets operating globally, beyond satellite communication range or in regions with unreliable service, the system provides low-latency critical status updates. A vessel's onboard system receives a request to report an urgent status (e.g., "engine failure," "piracy threat," "man overboard"). This status and location are encoded into a compact, latency-optimized message (e.g., a few bits representing status, a few for coded location grid), known to shore-based operations centers. Transmission parameters are determined, taking into account the real-time ionospheric conditions over the vessel's current ocean region and the fixed HF maritime communication channel bandwidths (e.g., ITU-R bands). The system adjusts carrier frequency, modulation, and power to overcome sea-state clutter and achieve rapid, reliable transmission to the nearest shore station, minimizing the delay in critical incident response.

graph TD
    A[Vessel Onboard System] --> B(Critical Status Report)
    B --> C{Encode Status/Location}
    C --> D[Controller (Maritime HF)]
    D -- Param. Determ. (Oceanic Ionosphere, Maritime Band) --> E[HF Transceiver (Vessel)]
    E --> F[Oceanic Ionosphere]
    F --> G[Shore Operations Center]
    D -- Control --> E

4. Integration with Emerging Tech

Derivative 4.1: AI-Driven Predictive Ionospheric Optimization

• Enabling Description: The controller's determinators are augmented with an Artificial Intelligence (AI) module, specifically a deep learning neural network, trained on historical and real-time ionospheric data (solar activity, geomagnetic indices, ionosonde readings, past HF propagation successes/failures). This AI module continuously predicts optimal carrier frequencies, elevation angles, and expected hop counts with microsecond-level precision, minimizing propagation latency. It processes the message size and predefined channel bandwidth, then recommends a complete set of transmission parameters (modulation type, power, sample rate, buffer size) that collectively minimize total message latency. The AI system can adapt to rapidly changing space weather conditions, providing dynamic adjustments to the determinators, far exceeding human or simple algorithmic capabilities.

graph TD
    A[Real-time Ionospheric Data] --> B(AI Predictive Model)
    B -- Optimal HF Paths --> C[Controller Determinators]
    C -- Tuned Parameters --> D[HF Transmitter]
    D --> E[Ionospheric Transmission]
    F[Message for Tx] --> C
    G[Predefined Bandwidth] --> C
    C -- Control --> D

Derivative 4.2: IoT-Enabled Real-time Local Environmental Sensing for Adaptive HF

• Enabling Description: The transmitting device is integrated with or directly influences a local network of Internet of Things (IoT) sensors. These sensors provide hyper-local, real-time data on atmospheric conditions (temperature, humidity, pressure, ground conductivity, local RF interference) that significantly impact ground wave and near-field skywave propagation. The IoT sensor data is fed into the frequency and power determinators. This allows for fine-grained adjustments to the transmission parameters, optimizing for localized environmental effects, particularly for the first hop of an ionospheric transmission or for tropospheric transmissions. The IoT data helps refine the calculation of d (length of a hop) and Δ (elevation angle) in the time-of-flight equation, improving overall propagation latency estimation.

graph TD
    A[IoT Sensor Network (Local Env.)] --> B(Data Aggregation)
    B --> C[Controller Determinators]
    C -- Refined Parameters --> D[HF Transmitter]
    D --> E[Local Propagation Path (HF)]
    F[Message for Tx] --> C
    G[Predefined Bandwidth] --> C
    C -- Control --> D

Derivative 4.3: Blockchain for Secure, Authenticated Low-Latency Messaging

• Enabling Description: For financial transactions or other critical messages where integrity and authenticity are paramount, the encoded message is cryptographically signed and hash-chained onto a private or consortium blockchain before transmission. The "particular value" within the encoded message includes a transaction ID and a hash of the previous valid transaction block. The receiving device, which also participates in the blockchain, uses this information to quickly verify the message's authenticity and integrity upon reception without adding significant latency to the critical message content itself. The encoding scheme is extended to include a minimal, yet secure, blockchain validation element. The latency consideration includes the cryptographic overhead, which is minimized by using efficient hashing algorithms and concise block structures, ensuring the overall process remains low-latency within the predefined channel bandwidth. This provides a non-repudiable record of critical message transmission.

graph TD
    A[Request for Action] --> B(Encode Value + Crypto Sig)
    B --> C[Hash & Add to Blockchain]
    C --> D[Controller Determinators]
    D -- Tx Parameters --> E[HF Transmitter]
    E --> F[Ionospheric Tx]
    F --> G[Remote Receiver]
    G -- Verify Hash --> H[Validate Blockchain]
    H -- Authenticated Message --> I[Perform Action]

5. The "Inverse" or Failure Mode

Derivative 5.1: Low-Power, Data-Sparse "Survival" Mode

• Enabling Description: In situations of critically low power supply (e.g., remote battery-operated sensors) or extreme regulatory limitations on emission, the system enters a "survival" mode. The message encoding is reduced to its absolute minimum, potentially a single bit representing a "life sign" or critical alert. The power determinator reduces transmission power to the lowest possible level that allows for detection at the remote receiving device, potentially sacrificing message integrity for detectability. The modulation determinator selects the most power-efficient and robust modulation (e.g., CW or very slow FSK), even if it results in significantly increased propagation latency. The frequency determinator selects channels known for maximal atmospheric penetration at low power. The buffer determinator maximizes buffering to smooth out intermittent power availability or channel conditions, accepting higher message size latency to ensure eventual transmission.

graph TD
    A[Low Power Condition] --> B(Activate Survival Mode)
    B --> C[Encode Minimal Message]
    C --> D[Power Determinator (Min Power)]
    D --> E[Modulation Determinator (Robust/Slow)]
    E --> F[HF Transmitter (Intermittent)]
    F --> G[Ionosphere (Max Range Priority)]
    G --> H[Remote Receiver (Awaits Beacons)]
    D -- Set Power --> F
    E -- Set Modulation --> F

Derivative 5.2: Graceful Degradation with Tiered Latency & Functionality

• Enabling Description: When channel conditions degrade severely (e.g., high interference, poor ionospheric reflection) or internal system resources become constrained, the system transitions through predefined tiers of graceful degradation.
  • Tier 1 (Mild Degradation): Prioritizes message types; financial transaction requests (critical) are encoded with minimal latency, while informational messages (less critical) may include error correction at the cost of higher latency. Modulation determinator shifts to slightly more robust but less spectrally efficient schemes.
  • Tier 2 (Moderate Degradation): All messages are stripped of non-essential data; "particular values" are reduced to their absolute minimum bit representation. Transmission power is increased to compensate for channel loss. Acknowledge-back mechanisms (if present) are disabled to save latency.
  • Tier 3 (Severe Degradation): Only pre-defined "red alert" or "kill switch" messages are transmitted, potentially using the "survival mode" parameters described in Derivative 5.1.
    The controller continuously monitors real-time channel quality and resource availability, dynamically selecting the appropriate tier and adjusting all transmission parameters accordingly, always striving to meet minimum latency for critical data within the remaining operational bandwidth.

stateDiagram
    [*] --> Normal_Operation
    Normal_Operation --> Mild_Degradation: Channel_Degrades > Threshold_1
    Mild_Degradation --> Moderate_Degradation: Channel_Degrades > Threshold_2
    Moderate_Degradation --> Severe_Degradation: Channel_Degrades > Threshold_3
    Severe_Degradation --> Shutdown: Critical_Failure
    Mild_Degradation --> Normal_Operation: Channel_Recovers < Threshold_1
    Moderate_Degradation --> Mild_Degradation: Channel_Recovers < Threshold_2
    Severe_Degradation --> Moderate_Degradation: Channel_Recovers < Threshold_3

    state Normal_Operation {
        High_Throughput_Encoding
        Optimal_Parameters
    }
    state Mild_Degradation {
        Prioritize_Critical_Msgs
        Slightly_Robust_Modulation
    }
    state Moderate_Degradation {
        Minimal_Message_Encoding
        Increased_Tx_Power
        Disable_ACKs
    }
    state Severe_Degradation {
        Red_Alert_Only
        Survival_Mode_Parameters
    }

---

Combination Prior Art Scenarios

These scenarios describe how the inventive concepts of US10959123 can be combined with existing open-source standards, demonstrating their obviousness or lack of novelty when integrated into widely available frameworks.

Combination Prior Art 1: MQTT over HF-DL (Digital Link) with Dynamic Parameter Negotiation

• Scenario: A low-latency wireless messaging system, as described in US10959123 (e.g., encoding financial transaction data into compact messages, determining parameters based on latency and channel bandwidth, and transmitting via ionospheric HF), is implemented using the Message Queuing Telemetry Transport (MQTT) protocol for message structuring and payload delivery. For the underlying physical layer, the system leverages a High-Frequency Digital Link (HF-DL) standard, such as STANAG 5066 or MIL-STD-188-110B App. C, adapted for dynamic parameter negotiation.
• Enabling Description: The front-end unit receives a financial transaction request. Instead of a custom encoding format, it translates the request into a concise MQTT PUBLISH message (e.g., topic "HFT/IBM/BUY", payload "1000") with a Quality of Service (QoS) level 0 (fire-and-forget for lowest latency). This MQTT message acts as the "encoded message" where the topic structure and payload implicitly represent the "particular value known a priori." The controller's determinators (frequency, modulation, power, etc.) then dynamically configure the HF-DL modem's physical layer parameters (e.g., specific waveform from MIL-STD-188-110B, interleaving depth, coding rate) based on the calculated message latency (from MQTT message size and propagation delay) and the predefined HF channel bandwidth. The HF-DL modem, supporting flexible data rates and robust modes, is commanded to use parameters that prioritize the low-latency MQTT message over error correction or higher throughput, within the 2.8 KHz channel limit. The receiver performs standard HF-DL demodulation and then processes the MQTT message.

sequenceDiagram
    participant TxDevice as Transmitting Device
    participant Controller as Parameter Controller
    participant HFDLModem as HF-DL Modem (PHY)
    participant Ionosphere as Ionosphere
    participant RxDevice as Receiving Device

    TxDevice->>TxDevice: Receive Financial Request
    TxDevice->>HFDLModem: Encode as MQTT PUBLISH (Low QoS)
    Note over TxDevice, HFDLModem: "Encoded message" for latency
    HFDLModem->>Controller: Query for Tx Parameters (Msg Size, Latency, Bandwidth)
    Controller->>Controller: Determine optimal HF-DL settings (Freq, Mod, Power, Waveform)
    Controller->>HFDLModem: Set Tx Parameters
    HFDLModem->>Ionosphere: Transmit Encoded MQTT over HF-DL
    Ionosphere->>RxDevice: Propagate Signal
    RxDevice->>HFDLModem: Receive & Demodulate HF-DL
    HFDLModem->>RxDevice: Decode MQTT PUBLISH
    RxDevice->>RxDevice: Verify & Execute Action

Combination Prior Art 2: GNU Radio-based SDR with OpenStreetMap for Location-Aware Propagation Modeling

• Scenario: The system's "means for determining transmission parameters" and "means for transmitting" are implemented entirely within an open-source GNU Radio framework running on a Software-Defined Radio (SDR) platform (e.g., USRP). The propagation latency calculations (e.g., time-of-flight) are enhanced by integrating geographical data from OpenStreetMap (OSM) to precisely calculate hop distances (d) and elevation angles (Δ) over complex terrain, particularly for ground wave or mixed ground/skywave paths.
• Enabling Description: A computing device equipped with a USRP SDR and running GNU Radio receives an encoded message. The GNU Radio flowgraph includes custom blocks for message encoding (converting high-level requests into compact bit sequences). The controller functionality, including frequency, modulation, and power determinators, is implemented as Python or C++ blocks within GNU Radio. These blocks interface with external libraries that pull real-time ionospheric data and query an OSM database (or local OSM tile server) to obtain precise topographical data between the transmitter and receiver. This topographical data is crucial for refining the calculation of path loss and elevation angles, which directly impacts the time-of-flight estimation. The GNU Radio flowgraph then dynamically reconfigures the USRP's sampling rate, center frequency, and gain settings, selecting an optimal modulation scheme (e.g., OOK or MSK from GNU Radio's built-in modulators) to transmit the message with minimal latency, while strictly adhering to the user-defined channel bandwidth.

graph TD
    A[Request for Action] --> B(Encode Message - GNU Radio Block)
    B --> C{Controller Logic - GNU Radio Blocks (Python/C++)}
    C -- Real-time Ionosphere Data --> D[Propag. Model (ITU-R P.533-10 variant)]
    C -- OSM Geo-data --> D
    D -- Estimated Latency --> C
    C -- Tx Parameters --> E[USRP SDR (GNU Radio Driver)]
    E --> F[Antenna]
    F --> G[Ionosphere/Ground Wave]
    G --> H[Remote Receiver (SDR/GNU Radio)]
    C -- Channel Bandwidth Constraint --> C

Combination Prior Art 3: Network Time Protocol (NTP) Synchronized Messaging with High-Resolution Time-Slotting

• Scenario: In an HF environment where precise timing is critical for message interpretation (e.g., "time slot of transmission represents a trading symbol" as in FIG. 8 of US10959123) and for minimizing network latency, the transmitting and receiving devices maintain high-precision time synchronization using a hardened Network Time Protocol (NTP) client/server architecture, potentially augmented with a local GPS disciplined oscillator (GPSDO) for nanosecond accuracy.
• Enabling Description: Both the transmitting and receiving devices are disciplined by an NTP server, ensuring their clocks are synchronized to a common time source with minimal offset. The controller in the transmitting device, upon receiving a request for a financial transaction, encodes the message to include a transaction type and quantity, but the "trading symbol" is implicitly conveyed by the precise start time of the message transmission within a predefined, high-resolution time-slot grid. The frequency determinator, knowing the estimated time-of-flight (τ) for the current ionospheric path, calculates the exact UTC time the message should arrive at the receiver. The transmitting device then sends the message at a calculated UTC time such that its reception falls within the target time slot, compensating for propagation latency. The receiving device, synchronized via NTP, records the precise arrival time of the message and correlates it with its a priori knowledge of trading symbols assigned to time slots, implementing a "time out period" if the message arrives outside the expected window, thus preventing erroneous trades (as described in FIG. 8). This combination uses an open-source standard for crucial timing, enabling a latency-sensitive encoding mechanism.

sequenceDiagram
    participant GPSDO_NTP_Tx as GPSDO/NTP (Tx)
    participant TxDevice as Transmitting Device
    participant Controller as Parameter Controller
    participant Ionosphere as Ionosphere
    participant GPSDO_NTP_Rx as GPSDO/NTP (Rx)
    participant RxDevice as Receiving Device

    GPSDO_NTP_Tx->>TxDevice: Provide High-Precision UTC Time
    TxDevice->>TxDevice: Receive Request (Action, Quantity)
    TxDevice->>Controller: Encode (Action, Quantity), Tx Timing (Symbol)
    Controller->>Controller: Calculate Propagation Latency (tau)
    Controller->>Controller: Determine Target Tx Start Time (UTC) = Target Rx Time - tau
    Controller->>TxDevice: Issue "Transmit at Target Tx Start Time"
    TxDevice->>Ionosphere: Transmit Message at precise UTC
    Ionosphere->>RxDevice: Propagate Signal
    GPSDO_NTP_Rx->>RxDevice: Provide High-Precision UTC Time
    RxDevice->>RxDevice: Record Actual Rx Time
    RxDevice->>RxDevice: Correlate Rx Time to Trading Symbol (a priori)
    RxDevice->>RxDevice: Validate within Time-Out Window
    RxDevice->>RxDevice: Execute Action (if valid)