Derivative works

Defensive Disclosure: US Patent 11116035 Derivatives

This document outlines derivative variations of the inventions described in US Patent 11116035, focusing on methods and apparatus for wireless communication using enhanced distributed channel access (EDCA), particularly concerning multi-user uplink (UL-MU) transmissions and backoff timer management. These disclosures are intended to serve as prior art, rendering future incremental improvements in these areas obvious or non-novel.

Core Claims Addressed:

• Claim 1 (Method): Wireless communication method involving channel access based on data priority, switching parameter sets for UL-MU, and transmitting data.
• Claim 7 (Apparatus - Terminal with Switching): Wireless communication terminal with a processor configured for channel access, data transmission, and parameter set switching for UL-MU.
• Claim 13 (Apparatus - Terminal with Backoff Timer Operation): Wireless communication terminal with a processor operating multiple queues for EDCA, performing backoff procedures, and managing empty queues with zero backoff timers.

---

Derivative Variations

Derivatives for Claim 1 (Wireless Communication Method)

D1.1: Material & Component Substitution - Acoustic Underwater Communication with EDCA

• Enabling Description: A wireless communication method adapted for underwater acoustic channels where "channel access" involves transmitting acoustic pulses. The "wireless communication terminal" and "base wireless communication terminal" are acoustic modems. The 'first parameter set' (e.g., long Contention Window (CW), high Arbitration Interframe Space (AIFS)) is designed for low-density, general data transmission, while the 'second parameter set' (e.g., shorter CW, reduced AIFS) is optimized for higher-priority, time-sensitive UL-MU sonar data or sensor readings triggered by a surface vessel (base station). Channel sensing is performed via passive listening for acoustic quiet periods, and "triggering multi-user uplink transmission" refers to a scheduled multi-node acoustic data upload sequence. The acoustic modem uses piezoelectric transducers for transmission and reception, operating at frequencies typically below 100 kHz.
• Mermaid Diagram:

  graph TD
      A[Underwater Acoustic Modem (Terminal)] --> B{Sense Channel (Acoustic)};
      B -- Channel Idle --> C{Determine Data Priority};
      C -- UL-MU Triggered --> D[Switch to Acoustic UL-MU EDCA Parameters];
      D -- Access Channel --> E[Transmit Acoustic Data Burst];
      D -- No UL-MU Trigger --> F[Use Standard Acoustic EDCA Parameters];
      F -- Access Channel --> E;
      E --> G[Acoustic Base Station (Base Terminal)];
  

D1.2: Operational Parameter Expansion - Terahertz (THz) Communication for High-Density Data Offloading

• Enabling Description: A method for wireless communication operating in the Terahertz (0.1 THz to 10 THz) frequency band, designed for ultra-high-speed, short-range data offloading in densely populated environments (e.g., smart factories, data centers). The EDCA parameter sets are dynamically scaled for THz propagation characteristics, including high path loss and sensitivity to blockages. The 'first parameter set' offers moderate access latency for bulk data, while the 'second parameter set' provides extremely low latency and tighter contention windows for critical sensor data or control signals in UL-MU scenarios. The "slot time" is reduced to picoseconds, and CW values are proportionally adjusted to manage contention among thousands of devices within a localized area. Triggering for UL-MU utilizes specialized THz beamforming for spatial multiplexing.
• Mermaid Diagram:

  graph TD
      A[THz Terminal] --> B{Sense THz Channel};
      B -- Channel Idle --> C{Data to Transmit (Priority)};
      C -- UL-MU Triggered --> D[Switch to THz UL-MU EDCA Parameters (pico-second slot, tiny CW)];
      D -- Access THz Channel --> E[Transmit Ultra-High-Speed THz Data];
      C -- No UL-MU Trigger --> F[Use Standard THz EDCA Parameters];
      F -- Access THz Channel --> E;
      E --> G[THz Base Station];
  

D1.3: Cross-Domain Application - Precision Agriculture Sensor Networks

• Enabling Description: A wireless communication method for precision agriculture, where autonomous field robots and distributed environmental sensors act as wireless communication terminals, and a central gateway on a drone or ground vehicle acts as the base wireless communication terminal. Channel access is prioritized for critical data, such as immediate pest alerts or urgent irrigation system failures (high priority), versus routine soil moisture readings (low priority). The EDCA parameter set switches to an 'optimized agricultural UL-MU set' when the drone/gateway triggers simultaneous uplink reports from multiple sensors or robots in a specific zone. This ensures that clustered event data, like sudden temperature drops detected by multiple sensors, is rapidly collected, overriding routine data uploads to prevent widespread crop damage.
• Mermaid Diagram:

  graph TD
      A[Agricultural Sensor/Robot (Terminal)] --> B{Check Data Buffer (Priority)};
      B -- Critical Alert --> C{Initiate EDCA (High Priority)};
      C -- UL-MU Trigger from Drone/Gateway --> D[Switch to Agri-UL-MU EDCA Parameters];
      D -- Access Channel --> E[Transmit Prioritized Agri-Data];
      C -- Routine Data, No Trigger --> F[Initiate EDCA (Low Priority)];
      F -- Access Channel --> E;
      E --> G[Drone/Gateway (Base Terminal)];
  

D1.4: Integration with Emerging Tech - AI-Driven Dynamic EDCA for Smart Home IoT

• Enabling Description: A wireless communication method for a smart home IoT network, where an AI-driven home hub (base wireless communication terminal) dynamically optimizes EDCA parameters. The method involves the home hub continuously monitoring network traffic patterns, device presence, and user activity via IoT sensors. The AI algorithm predicts future congestion and high-priority events (e.g., security alerts, voice commands) and proactively adjusts the 'first' and 'second' EDCA parameter sets for connected IoT devices (wireless communication terminals). When the AI determines an upcoming need for UL-MU (e.g., multiple smart cameras simultaneously uploading footage during a perceived intrusion, or multiple voice assistants responding to a command), it triggers the switch to a 'second parameter set' specifically tuned by the AI for that predicted multi-user scenario, minimizing latency for critical data while ensuring fairness for background tasks.
• Mermaid Diagram:

  graph TD
      A[Smart Home IoT Device (Terminal)] --> B{Sense Channel};
      B -- Channel Idle --> C{Prepare Data (IoT Priority)};
      C -- AI-Triggered UL-MU --> D[Switch to AI-Optimized UL-MU EDCA Params];
      D -- Access Channel --> E[Transmit IoT Data];
      C -- No AI Trigger --> F[Use Current AI-Managed EDCA Params];
      F -- Access Channel --> E;
      E --> G[AI-Driven Home Hub (Base Terminal)];
  

D1.5: The "Inverse" or Failure Mode - EDCA for Low-Power, Long-Range Disaster Relief Networks

• Enabling Description: A wireless communication method for emergency and disaster relief scenarios, where power conservation and robust, long-range communication are paramount over immediate high throughput. Terminals are battery-powered, low-cost mesh nodes. The 'first parameter set' is extremely conservative, with very long AIFS and large CWs, for infrequent, non-critical status updates to maximize battery life. When a critical event (e.g., trapped person detected, structural collapse) is locally sensed, a specialized "emergency UL-MU trigger" is broadcast by a nearby resilient node (base terminal), prompting all affected nodes to switch to a 'second parameter set'. This 'second parameter set' still prioritizes low power by using slower data rates but significantly reduces AIFS and CWs for critical alert messages, enabling rapid, multi-node reporting in a coordinated, energy-efficient burst without excessive retransmissions, ensuring the network can operate for extended periods under adverse conditions.
• Mermaid Diagram:

  graph TD
      A[Disaster Relief Node (Terminal)] --> B{Monitor Battery & Data Severity};
      B -- Low Battery, Low Severity --> C[Use Ultra-Conservative EDCA (Long Life)];
      C -- Access Channel (Infrequent) --> E[Transmit Low-Power Data];
      B -- Critical Event Detected --> F{Emergency UL-MU Trigger Received?};
      F -- Yes --> D[Switch to Emergency UL-MU EDCA (Prioritize Critical Data, Conserve Power)];
      D -- Access Channel --> E;
      F -- No --> C;
      E --> G[Resilient Gateway (Base Terminal)];
  

---

Derivatives for Claim 7 (Wireless Communication Terminal with Switching)

D7.1: Material & Component Substitution - Multi-Band Software-Defined Radio (SDR) Terminal

• Enabling Description: A wireless communication terminal implemented as a Software-Defined Radio (SDR) platform, capable of operating across disparate frequency bands (e.g., sub-GHz, 2.4 GHz, 5 GHz, mmWave) using reconfigurable RF front-ends. The "processor" is a high-performance FPGA or a DSP array specifically configured to implement the EDCA logic, including the dynamic switching of parameter sets. The "transceiver" consists of wideband RF converters and digitally controlled filters, allowing the terminal to adapt its physical layer characteristics (e.g., modulation, coding, bandwidth) in conjunction with EDCA parameter switching based on the operating band and UL-MU trigger. This enables flexible channel access prioritization across diverse spectrum allocations managed by a base station, e.g., switching from a 2.4 GHz general access parameter set to a 5 GHz dedicated UL-MU parameter set.
• Mermaid Diagram:

  classDiagram
      class WirelessCommunicationTerminal {
          +SDR_Processor_FPGA processor
          +Reconfigurable_RF_FrontEnd transceiver
          +EDCA_Logic edcaLogic
          +ParameterSet firstParamSet
          +ParameterSet secondParamSet
          +switchParameterSet()
          +accessChannel()
          +transmitData()
      }
      class SDR_Processor_FPGA {
          +configureEDCALogic()
          +manageMultipleQueues()
      }
      class Reconfigurable_RF_FrontEnd {
          +operateMultiBand()
          +adjustPHY()
      }
      class EDCA_Logic {
          +receiveTrigger(bool)
          +selectParameterSet()
          +runBackoffProcedure()
      }
      SDR_Processor_FPGA <|-- WirelessCommunicationTerminal
      Reconfigurable_RF_FrontEnd <|-- WirelessCommunicationTerminal
      EDCA_Logic <|-- SDR_Processor_FPGA
      ParameterSet <|-- EDCA_Logic
  

D7.2: Operational Parameter Expansion - Extreme Temperature Industrial IoT Gateway

• Enabling Description: A wireless communication terminal designed for industrial IoT environments operating in extreme temperatures (e.g., -50° C to +150° C). The processor is a ruggedized, industrial-grade microcontroller (e.g., ARM Cortex-M series with extended temperature ratings) with embedded EDCA logic. The transceiver components are similarly rated for extreme thermal cycles. The 'first parameter set' is optimized for standard industrial data logging under typical loads. The 'second parameter set' (switched upon UL-MU trigger from a central controller) is specifically characterized and calibrated for reliable operation at temperature extremes, potentially using larger guard intervals or reduced data rates to compensate for thermal noise and component drift, ensuring robust multi-user uplink of critical process control data even under harsh thermal stress.
• Mermaid Diagram:

  stateDiagram-v2
      state "Idle (Normal Temp)" as NormalIdle
      state "Backoff (Normal Temp)" as NormalBackoff
      state "Transmit (Normal Temp)" as NormalTransmit
      state "Idle (Extreme Temp)" as ExtremeIdle
      state "Backoff (Extreme Temp)" as ExtremeBackoff
      state "Transmit (Extreme Temp)" as ExtremeTransmit
  
      [*] --> NormalIdle
  
      NormalIdle --> NormalBackoff : Data Ready, Channel Idle
      NormalBackoff --> NormalTransmit : Backoff Timer = 0
      NormalTransmit --> NormalIdle : Transmission Complete
  
      NormalIdle --> ExtremeIdle : UL-MU Triggered OR Extreme Temp Detected
      NormalBackoff --> ExtremeBackoff : UL-MU Triggered OR Extreme Temp Detected
      NormalTransmit --> ExtremeTransmit : UL-MU Triggered OR Extreme Temp Detected
  
      ExtremeIdle --> ExtremeBackoff : Data Ready, Channel Idle (Extreme Params)
      ExtremeBackoff --> ExtremeTransmit : Backoff Timer = 0 (Extreme Params)
      ExtremeTransmit --> ExtremeIdle : Transmission Complete
  
      ExtremeIdle --> NormalIdle : UL-MU Concluded AND Normal Temp
  

D7.3: Cross-Domain Application - Autonomous Underwater Vehicle (AUV) Swarm Communication

• Enabling Description: An AUV acting as a wireless communication terminal within a swarm, communicating with a lead AUV or surface support vessel (base wireless communication terminal) via acoustic or optical (blue/green laser) links. The AUV's embedded processor manages EDCA for prioritizing navigation, sonar, and environmental sensing data. When the lead AUV initiates an "environmental mapping UL-MU trigger," the AUV switches its channel access parameters. The 'first parameter set' supports routine status updates. The 'second parameter set' is specifically tuned for synchronized, high-bandwidth data uploads from multiple AUVs, optimizing for the acoustic propagation delays and potential interference within a dense swarm, allowing for rapid aggregation of complex 3D mapping data.
• Mermaid Diagram:

  sequenceDiagram
      AUV_Lead_BS->>AUV_Sub_Terminal: Transmit UL-MU Trigger (Env. Mapping)
      AUV_Sub_Terminal->>AUV_Sub_Terminal: Processor switches EDCA parameters (1st to 2nd set)
      Note over AUV_Sub_Terminal: Second set optimized for swarm uplink, e.g., shorter AIFS, specific CW range.
      AUV_Sub_Terminal->>AUV_Sub_Terminal: Prepare environmental mapping data (priority=high)
      AUV_Sub_Terminal->>AUV_Sub_Terminal: Sense Acoustic/Optical Channel
      AUV_Sub_Terminal->>AUV_Sub_Terminal: Perform Backoff with 2nd EDCA parameters
      AUV_Sub_Terminal->>AUV_Lead_BS: Transmit Environmental Mapping Data
      AUV_Lead_BS->>AUV_Sub_Terminal: (Optional) Acknowledge/Confirm UL-MU data reception
      AUV_Sub_Terminal->>AUV_Sub_Terminal: Processor switches EDCA parameters (2nd to 1st set) or sets timer for expiration
  

D7.4: Integration with Emerging Tech - Secure Blockchain-Enabled EDCA for Shared Spectrum

• Enabling Description: A wireless communication terminal integrated with a blockchain module (e.g., secure element or dedicated processor) to ensure transparent and verifiable channel access in shared, unlicensed spectrum where multiple operators or entities co-exist. The "processor" not only manages EDCA parameter switching but also interacts with the blockchain. When a "multi-user uplink transmission participation trigger" is received from a base terminal (e.g., an access point or shared spectrum orchestrator), the terminal switches its EDCA parameter set. Critically, each successful channel access and transmission event is timestamped and cryptographically signed before being broadcast or committed to a local/distributed ledger (blockchain). This immutable record provides an auditable history of channel usage, ensuring fairness and preventing malicious hoarding of channel access, particularly for high-priority UL-MU allocations.
• Mermaid Diagram:

  flowchart TD
      A[Wireless Terminal] --> B{Receive UL-MU Trigger from Base};
      B -- Yes --> C[Processor Switches EDCA Params (1st to 2nd Set)];
      C --> D[Access Channel (Using 2nd Params)];
      D --> E[Transmit Data (UL-MU)];
      E --> F[Record Channel Access Event (Timestamp, TxID, Params Used)];
      F --> G[Cryptographically Sign Event];
      G --> H[Commit to Blockchain Ledger];
      H --> I[Base Terminal Verifies Blockchain Entry (Optional)];
      B -- No --> J[Use 1st EDCA Params];
      J --> D;
  

D7.5: The "Inverse" or Failure Mode - Adaptive Safety-Critical EDCA Degradation

• Enabling Description: A wireless communication terminal, such as a drone or industrial robot, equipped with a safety monitoring unit (part of the processor or a separate module). Under normal operation, the terminal uses standard EDCA parameter sets. If the safety monitoring unit detects a critical system malfunction (e.g., motor failure, sensor corruption, low battery below threshold), it automatically triggers a shift to a "safety-critical EDCA parameter set" (effectively a 'second parameter set'). This safety set is designed for minimal interference and maximum reachability for emergency beacons or distress signals, typically by:
  1. Maximizing AIFS for all non-safety traffic categories.
  2. Reducing CWmin/CWmax drastically for a dedicated "emergency beacon" access category to ensure highest priority and fastest access.
  3. Operating in a limited-functionality mode, transmitting only essential diagnostic or location data.
  4. The system can be triggered into this mode by an external "abort" command (UL-MU trigger from base) or internal fault detection, ensuring controlled, safe transmission behavior during failure.
• Mermaid Diagram:

  stateDiagram-v2
      state "Normal Operation" as Normal
      state "Safety Mode" as Safety
  
      Normal --> Normal_Channel_Access : Data ready
      Normal_Channel_Access --> Normal : Tx complete
  
      Normal --> Safety : Critical Malfunction Detected OR External Abort Trigger
      Safety --> Safety_Emergency_Tx : Emergency Data Ready
      Safety_Emergency_Tx --> Safety : Tx complete
      Safety --> Safety_Beacon_Tx : Regular Beacon Tx
      Safety_Beacon_Tx --> Safety : Tx complete
  
      state "Normal Channel Access" as Normal_Channel_Access {
          state "Apply 1st EDCA Set" as NormalEDCA
          NormalEDCA : Standard CW, AIFS
      }
  
      state "Safety Emergency Tx" as Safety_Emergency_Tx {
          state "Apply Safety EDCA Set" as SafetyEDCA
          SafetyEDCA : Minimized CW, AIFS for Emergency
      }
  
      state "Safety Beacon Tx" as Safety_Beacon_Tx {
          state "Apply Safety EDCA Set" as SafetyBeaconEDCA
          SafetyBeaconEDCA : Max AIFS for Non-Emergency, Reduced Rate
      }
  

---

Derivatives for Claim 13 (Wireless Communication Terminal with Backoff Timer Operation)

D13.1: Material & Component Substitution - Neuromorphic Processor for Adaptive Backoff

• Enabling Description: A wireless communication terminal utilizing a neuromorphic processor (e.g., Intel Loihi, IBM TrueNorth) for highly adaptive and energy-efficient backoff timer management. Instead of a traditional processor calculating a random integer, the neuromorphic processor learns optimal backoff behaviors (CW values, AIFS) for different access categories (ACs) and network load conditions by observing past channel access outcomes and traffic patterns. The "random integer value in a contention window (CW)" is replaced by a probabilistically derived value from the neuromorphic network's learned distribution, which dynamically adjusts based on real-time channel occupancy, detected collisions, and data priority. The "no operation at a slot boundary" for an empty queue with a zero backoff timer is handled by the neuromorphic chip going into a deep sleep state for that AC's processing thread, minimizing power consumption.
• Mermaid Diagram:

  classDiagram
      class WirelessCommunicationTerminal {
          +NeuromorphicProcessor processor
          +Transceiver transceiver
          +QueueManagementSystem queueManager
      }
      class NeuromorphicProcessor {
          +learnBackoffStrategies()
          +deriveBackoffValue(AC_ID) float
          +handleEmptyQueue(AC_ID)
          +adjustCW(AC_ID)
      }
      class QueueManagementSystem {
          +EDCAQueue queues[AC_COUNT]
          +monitorQueueStatus(AC_ID)
      }
      class EDCAQueue {
          +DataPacket data
          +BackoffTimer backoffTimer
          +ContentionWindow contentionWindow
          +isEmpty() boolean
      }
      WirelessCommunicationTerminal *-- NeuromorphicProcessor
      WirelessCommunicationTerminal *-- QueueManagementSystem
      QueueManagementSystem *-- EDCAQueue
      NeuromorphicProcessor ..> EDCAQueue : interacts_with
  

D13.2: Operational Parameter Expansion - Orbital Satellite Constellation with Dynamic Backoff

• Enabling Description: A wireless communication terminal forming part of a low Earth orbit (LEO) satellite constellation, communicating via inter-satellite links (ISLs) or ground links. The EDCA queues manage data for different service types (e.g., telemetry, high-bandwidth imaging, critical maneuvering commands). The backoff procedure is adapted for the unique characteristics of satellite communication, including long propagation delays and Doppler shifts. The "slot time" is dynamically adjusted based on orbital mechanics and link distances, potentially spanning multiple milliseconds. The "random integer value" generation considers potential interference from co-orbiting satellites. When a queue is empty and its backoff timer is zero, the satellite's processor enters a minimal processing state for that queue, conserving onboard computational resources and power, especially crucial for long-duration missions.
• Mermaid Diagram:

  graph TD
      A[LEO Satellite Terminal] --> B{Operate Multiple EDCA Queues};
      B -- Queue[Telemetry] --> C[Backoff Procedure (CW_Telemetry)];
      B -- Queue[Imaging] --> D[Backoff Procedure (CW_Imaging)];
      B -- Queue[Maneuver Cmd] --> E[Backoff Procedure (CW_Maneuver)];
      C -- Channel Idle for Slot --> F[Decrement Backoff Timer];
      D -- Channel Idle for Slot --> F;
      E -- Channel Idle for Slot --> F;
      F -- Timer = 0 & Queue Empty --> G[No Operation, Maintain Timer=0];
      F -- Timer = 0 & Data Ready --> H[Access Channel, Transmit Data];
      G -- New Data Arrives --> I[Recalculate Backoff (CW_Current)];
      I --> F;
  

D13.3: Cross-Domain Application - Smart Healthcare Wearable Device

• Enabling Description: A wireless communication terminal in the form of a smart wearable medical device (e.g., continuous glucose monitor, ECG patch) managing multiple EDCA queues for different types of patient data. For instance, AC_VO (Voice) for urgent alerts, AC_VI (Video) for real-time video consultation, AC_BE (Best Effort) for routine vitals, and AC_BK (Background) for historical data sync. The processor prioritizes critical alarms (e.g., cardiac arrest detection) over routine data uploads. The "backoff timer" is set for each queue based on its AC's CWmin/CWmax. Crucially, if a queue (e.g., for routine blood pressure logs) becomes empty and its backoff timer is zero, the wearable device's processor intelligently "pauses" the backoff for that AC, allowing other ACs with pending data to utilize channel resources more efficiently, and conserving the wearable's limited battery life by avoiding unnecessary channel sensing activities for empty queues.
• Mermaid Diagram:

  stateDiagram-v2
      state "Monitor Patient Vitals" as Monitor
      state "Queue Management" as Queues
      state "Backoff Procedure" as Backoff
      state "Transmit Data" as Transmit
  
      [*] --> Monitor
      Monitor --> Queues : Data Generated (AC_VO, AC_VI, AC_BE, AC_BK)
  
      Queues --> Backoff : Select Highest Priority AC with data
      Backoff --> Transmit : Backoff Timer = 0
      Transmit --> Queues : Data sent
  
      Backoff --> Backoff : Channel Idle (Decrement Timer)
      Backoff --> Queues : Channel Busy (Stop Timer)
  
      Queues --> Idle_Queue_Zero_Timer : If any AC_Queue is Empty AND BackoffTimer[AC]=0
      state "Idle Queue, Zero Timer" as Idle_Queue_Zero_Timer {
          state "No Operation (for this AC)" as NoOp
          NoOp : Maintain BackoffTimer[AC]=0
          NoOp --> Queues : New data arrives for AC
      }
  

D13.4: Integration with Emerging Tech - IoT Edge Node with Predictive Backoff Optimization

• Enabling Description: A wireless communication terminal functioning as an IoT edge node in a smart factory, equipped with an embedded AI/ML module (part of the processor or a co-processor). This module performs "predictive backoff optimization." For each EDCA queue, instead of purely random CW selection, the AI/ML module analyzes historical channel utilization, predicted factory production schedules, and real-time sensor data to forecast channel contention. It then dynamically "suggests" a pseudo-random integer value for the backoff timer within the current CW range, aiming to minimize collisions and optimize throughput for mission-critical tasks (e.g., robot arm control, emergency stop signals). When an EDCA queue is empty and its backoff timer reaches zero, the AI/ML module predicts when new data is likely to arrive for that AC (e.g., based on sensor sampling rates) and puts the associated backoff process into a low-power "pre-emptive idle" state until the predicted data arrival time, rather than performing no operation, ensuring faster ramp-up once data becomes available.
• Mermaid Diagram:

  flowchart TD
      A[IoT Edge Node Terminal] --> B{Operate EDCA Queues (ACs)};
      B -- For Each AC --> C[Monitor Queue Status];
      C --> D[AI/ML Module (Predictive Backoff)];
      D -- Input: Channel State, Traffic Pattern, AC Priority --> E[Generate Optimized Backoff Value];
      E --> F[Set Backoff Timer (based on CW & Optimized Value)];
      F -- Channel Idle for Slot --> G[Decrement Timer];
      G -- Timer = 0 AND Queue Empty --> H[AI/ML Predicts Next Data Arrival];
      H -- Predictive Idle Until New Data --> I[Maintain Timer=0, Low Power];
      G -- Timer = 0 AND Data Ready --> J[Access Channel, Transmit Data];
      I --> F : New Data Arrives / Prediction Active
  

D13.5: The "Inverse" or Failure Mode - Self-Healing EDCA Queue with Redundant Backoff States

• Enabling Description: A wireless communication terminal designed for critical infrastructure (e.g., power grid monitoring, nuclear facility sensors) where EDCA queue integrity is paramount. The processor manages multiple EDCA queues, but for each queue, it maintains not only a "current" backoff timer state but also a "redundant" or "shadow" backoff timer state. In the event of a software crash or transient error affecting the primary EDCA logic (detected by a watchdog timer or CRC checks on state variables), the system automatically reverts to the last known good "redundant backoff state" for each queue. If a queue is empty and its primary backoff timer incorrectly remains at zero due to a fault, the self-healing mechanism detects this anomaly (e.g., no data for extended period but timer stuck at zero) and either resets the timer to a default CWmin-based value or, more sophisticatedly, forces a recalculation from the redundant state, preventing a "stuck" channel access priority or resource starvation in a critical operational environment.
• Mermaid Diagram:

  stateDiagram-v2
      state "Normal EDCA Operation" as Normal
      state "Fault Detected" as Fault
      state "Self-Healing Recovery" as Recovery
      state "Backoff with Redundancy" as BackoffRedundant
  
      [*] --> Normal
      Normal --> BackoffRedundant : Data Ready
      BackoffRedundant --> Normal : Tx Complete
  
      Normal --> Fault : Watchdog Timeout / CRC Error
      BackoffRedundant --> Fault : Watchdog Timeout / CRC Error
  
      Fault --> Recovery : Trigger Recovery Protocol
      Recovery --> BackoffRedundant : Restore from Redundant State
  
      state "Backoff with Redundancy" {
          state "Primary Backoff" as Primary
          state "Redundant Shadow" as Shadow
          Primary --> Shadow : Sync State Updates
          Primary --> Primary : Timer Decrement
          Primary --> Fault : Internal Error
          Shadow --> Shadow : Mirror Primary State
          Shadow --> Primary : Restore on Fault
          Primary --> No_Op_Empty_Zero : Timer=0, Queue Empty
      }
  
      state "No_Op_Empty_Zero" {
          state "Monitor for Anomaly" as AnomalyCheck
          AnomalyCheck --> Recovery : Anomaly Detected (e.g., Stuck Timer)
          AnomalyCheck --> No_Op_Empty_Zero : No Anomaly
      }
  

---

Combination Prior Art Scenarios

These scenarios combine elements of US Patent 11116035 with existing open-source standards, demonstrating how the core concepts could be applied or rendered obvious in established frameworks.

1. US11116035 + IEEE 802.11be (Wi-Fi 7) for Multi-Link Operation (MLO) EDCA

• Description: The EDCA parameter switching mechanism described in US11116035, specifically for multi-user uplink (UL-MU) scenarios, would be obvious when integrated into the context of IEEE 802.11be Multi-Link Operation (MLO). In MLO, a Wi-Fi 7 client (wireless communication terminal) can simultaneously utilize multiple frequency bands (e.g., 2.4 GHz, 5 GHz, 6 GHz) to communicate with an Access Point (base wireless communication terminal). A natural extension of US11116035 would be to dynamically adjust EDCA parameter sets (AIFS, CWmin/max) for specific links or aggregated links when the AP triggers a multi-user uplink. For example, an AP could trigger an MLO UL-MU transmission, prompting the client to switch from a relaxed EDCA parameter set on a less congested 2.4 GHz link to a more aggressive parameter set on a 6 GHz link for the duration of the multi-user upload, to maximize throughput and minimize latency across the combined links, thereby adapting the UL-MU EDCA prioritization logic to the multi-link capabilities of 802.11be.
• Relevance: Makes the EDCA parameter switching based on UL-MU triggers obvious in the context of advanced Wi-Fi standards like 802.11be which already manage multiple links and dynamic resource allocation.

2. US11116035 + 3GPP Release 16 (NR-U) for Unlicensed Spectrum Access

• Description: The wireless communication method of US11116035, including accessing a channel based on data priority and switching EDCA parameters based on a base terminal's UL-MU trigger, would be obvious in the context of 3GPP Release 16's New Radio Unlicensed (NR-U) features. NR-U extends 5G capabilities into unlicensed spectrum (e.g., 5 GHz, 6 GHz bands), necessitating Listen-Before-Talk (LBT) mechanisms similar to EDCA for fair coexistence. A 5G gNB (base wireless communication terminal) operating in NR-U mode could trigger an NR-U UL-MU transmission for multiple User Equipments (UEs - wireless communication terminals). In response to this trigger, the UE would apply a dynamically assigned 'second EDCA parameter set' (e.g., specific LBT parameters like Channel Occupancy Time, energy detection thresholds, or backoff window sizes) tailored by the gNB for optimal multi-user uplink performance in the shared unlicensed channel, preventing collisions with other unlicensed users while ensuring efficient 5G UL-MU data transfer. This applies the EDCA concept to a 3GPP-defined unlicensed access scheme.
• Relevance: Extends the patent's EDCA concepts to cellular technologies using unlicensed spectrum, where channel access and prioritization are critical for performance and fair coexistence.

3. US11116035 + LoRaWAN for Adaptive Uplink Prioritization

• Description: The method of managing EDCA queues and handling empty queues with zero backoff timers, as described in US11116035 (Claim 13), could be combined with LoRaWAN (Long Range Wide Area Network) for enhanced uplink prioritization. LoRaWAN devices (wireless communication terminals) typically operate with infrequent, low-data-rate uplinks. However, in scenarios requiring differentiated services (e.g., critical alarm sensors vs. routine environmental monitors), a LoRaWAN gateway (base wireless communication terminal) could implement a pseudo-EDCA mechanism. When a LoRaWAN device has multiple types of data (classified by urgency), it could manage separate "logical" queues. If the gateway "triggers" a specific UL-MU schedule (e.g., for all urgent temperature sensors in a zone), the devices could dynamically adjust their channel access parameters (similar to AIFS/CW, but abstractly applied to LoRaWAN's random access scheme, e.g., duty cycle limits, next transmission window size). The rule regarding an empty queue with a zero backoff timer (maintaining zero and performing no operation) would be highly relevant for LoRaWAN, where devices should conserve energy by not attempting channel access when no data is buffered, even if a "slot" becomes available, thus optimizing battery life.
• Relevance: Applies the principles of EDCA queue management and efficient backoff handling for empty queues to low-power, wide-area network technologies, which prioritize energy efficiency and long range over high throughput, but can benefit from prioritization.