For US patent 11516879, the following defensive disclosure document outlines derivative variations and combination prior art scenarios to establish prior art and potentially render future incremental improvements obvious or non-novel.

The authoritative text for US11516879 has been accessed and forms the basis for the following derivations.

---

Defensive Disclosure for US Patent 11516879

Combination Prior Art Scenarios

The core inventive concepts of US Patent 11516879, revolving around enhanced distributed channel access (EDCA) parameter switching and timer-based termination in response to multi-user uplink (UL MU) transmissions, can be combined with various existing open-source standards to establish obviousness or lack of novelty for future incremental improvements.

1. Integration with IEEE 802.11ax (Wi-Fi 6) Open-Source Drivers:

   • Scenario: Implement the dynamic EDCA parameter set switching and timer-based termination mechanisms described in US11516879 within an open-source IEEE 802.11ax Wi-Fi driver, such as ath11k for Qualcomm chipsets in the Linux kernel.
   • Enabling Description: An ath11k driver module, running on a Wi-Fi 6 capable station (STA), intercepts trigger frames for UL MU-MIMO or UL OFDMA transmissions. Upon detection of a trigger frame indicating the STA's participation in UL MU transmission, the driver's MAC layer logic, specifically the EDCA function (EDCAF) block, dynamically loads an alternative EDCA parameter set (e.g., adjusted AIFS, CWmin, CWmax values) stored in its configuration space. Following the transmission of the trigger-based PPDU and reception of an immediate block acknowledgment (BA) frame, a k_timer (Linux kernel timer) is initiated. This timer, named mu_edca_expiration_timer, runs for a predefined duration (e.g., aSIFSTime + aRxPHYStartDelay + 2*aSlotTime, or a configurable value obtained from beacon frames as per the patent). Upon expiration of mu_edca_expiration_timer, the EDCA parameters for the relevant access categories (ACs) are reverted to their default or previously active non-MU EDCA parameter set. This real-time parameter adjustment and termination are directly handled by the driver's low-level MAC implementation interacting with the hardware.

2. Application within OpenWrt Firmware for Access Points (APs):

   • Scenario: Configure an OpenWrt-enabled access point (AP) to implement the base wireless communication terminal's triggering mechanism and signaling of MU EDCA parameter sets, while also managing associated stations (STAs) that implement the client-side logic from US11516879.
   • Enabling Description: An OpenWrt AP, utilizing hostapd for AP functionality, is extended with a custom kernel module or user-space daemon. This daemon monitors network load, buffer status reports (BSRs) from STAs, and dynamically determines when to schedule UL MU transmissions. When a UL MU transmission is scheduled, the daemon constructs and transmits trigger frames, incorporating specific user information fields (User Info field) to indicate participating STAs and their allocated resource units (RUs). Simultaneously, the AP can embed MU EDCA parameter set information within beacon frames or action frames, as described in the patent, which are broadcast via the mac80211 subsystem. The AP's internal logic then expects STAs to adjust their channel access behavior accordingly. This ensures the AP correctly interprets and manages UL MU transmissions from STAs operating with the dynamically adjusted EDCA parameters.

3. Dynamic EDCA Policy Management via Software-Defined Networking (SDN) using ONOS:

   • Scenario: An ONOS (Open Network Operating System) SDN controller manages a wireless local area network (WLAN) and dynamically pushes EDCA parameter policies to APs, which in turn signal these to STAs, incorporating the trigger-based parameter switching of US11516879.
   • Enabling Description: An ONOS controller, operating as the central network orchestrator, employs a custom application to monitor real-time QoS metrics, traffic patterns, and UL MU scheduling opportunities across the WLAN. When the SDN application identifies a need for enhanced UL MU efficiency (e.g., due to high uplink congestion on specific ACs), it uses OpenFlow or a similar southbound API to push updated MU EDCA parameter sets (e.g., specifying new AIFS, CWmin, CWmax values for VO, VI, BE, BK access categories) to managed APs. These APs (which could be OpenWrt-enabled as in scenario 2) then broadcast this information in beacon frames or specific action frames. Upon a STA being triggered for UL MU transmission by the AP, and receiving the immediate response for its PPDU, the STA (implementing the logic from US11516879) locally switches to the signaled MU EDCA parameters. The ONOS controller's continuous monitoring allows for adaptive policy adjustments, ensuring that the EDCA parameter sets are optimized network-wide, with the dynamic switching at the STA being a controlled response to AP triggers, all managed within the SDN framework.

---

Derivative Variations for US Patent 11516879

For the core claims, which describe a wireless communication method and terminal for accessing a channel using enhanced distributed channel access (EDCA), switching parameter sets based on a multi-user uplink (UL MU) trigger, and terminating the new parameter set's application via a timer, the following derivative variations are disclosed:

1. Material & Component Substitution

Derivative 1.1: FPGA-Accelerated MAC Layer with Reconfigurable EDCA Engine

• Enabling Description: Instead of a fixed-function hardware MAC or a software-defined MAC on a general-purpose processor, the wireless communication terminal (Claim 6) and its method (Claim 1) are implemented with a field-programmable gate array (FPGA) containing a reconfigurable EDCA engine. The processor (110) programs the FPGA to define the first and second parameter sets (CWmin, CWmax, AIFS values). Upon receiving a UL MU trigger frame via the transceiver (120), the processor signals the FPGA. The FPGA's reconfigurable logic instantly switches the active EDCA parameter set by loading a pre-synthesized configuration from its internal memory (160) into dedicated EDCA state machines. The timer (second parameter set timer) is implemented as a high-precision hardware counter within the FPGA, triggered by a PHY-TXEND.confirm primitive for the trigger-based PPDU transmission and an M-BA reception event, allowing for sub-microsecond precision in timer-based parameter set termination, bypassing software overhead. This hardware acceleration minimizes latency in parameter switching and ensures deterministic timing for timer expiration, crucial for highly dynamic wireless environments.

graph TD
    A[Wireless Comm Terminal] --> B(Transceiver 120);
    B --> C{Receive Trigger Frame};
    C -- YES --> D[Processor 110];
    D --> E(Signal FPGA);
    E --> F[FPGA - Reconfigurable EDCA Engine];
    F -- Load Pre-synthesized Config --> G{Switch EDCA Param Set};
    G --> H(Transmit Trigger-based PPDU);
    H --> I{Receive Immediate Response (M-BA)};
    I -- YES --> J[FPGA - Hardware Timer];
    J -- Start Timer --> K{Timer Running};
    K -- Expires --> L{Terminate Second Param Set};
    L --> M(Revert to First Param Set);

Derivative 1.2: Optically-Interconnected Processing Units for Distributed EDCA Logic

• Enabling Description: The wireless communication terminal incorporates a main processor (110) for high-level MAC management and multiple specialized co-processors, each dedicated to managing a specific access category (AC) queue and its associated EDCA function (EDCAF) states. These co-processors (e.g., RISC-V microcontrollers with integrated MAC logic) are interconnected via a low-latency optical interconnect fabric (e.g., using VCSELs and photodiodes for inter-chip communication) instead of traditional electrical buses. When the main processor detects a UL MU trigger for certain ACs, it broadcasts the command and the second parameter set values over the optical fabric to the relevant AC co-processors. Each co-processor then independently applies the new EDCA parameters, manages its local backoff timer, and handles its own state transitions (e.g., from IDLE to DECREMENTING_BACKOFF). The "second parameter set timer" is a distributed timer; the main processor orchestrates its start based on aggregated immediate response acknowledgements from the co-processors for their respective MPDUs. Termination of the second parameter set then triggers each co-processor to revert its locally stored parameters. This architecture reduces contention for shared resources and improves responsiveness for individual AC queue management.

graph TD
    A[Main Processor 110] --> B{Detect UL MU Trigger};
    B -- Broadcast Command & Params --> C[Optical Interconnect Fabric];
    C --> D1[AC VO Co-processor];
    C --> D2[AC VI Co-processor];
    C --> D3[AC BE Co-processor];
    C --> D4[AC BK Co-processor];
    D1 -- Apply New Params --> E1{Manage VO Queue};
    D2 -- Apply New Params --> E2{Manage VI Queue};
    D3 -- Apply New Params --> E3{Manage BE Queue};
    D4 -- Apply New Params --> E4{Manage BK Queue};
    E1 -- Report Acknowledgment --> A;
    E2 -- Report Acknowledgment --> A;
    E3 -- Report Acknowledgment --> A;
    E4 -- Report Acknowledgment --> A;
    A -- Orchestrate Timer Start --> F[Distributed Timer Logic];
    F -- Expiration --> G{Revert Local Params};

2. Operational Parameter Expansion

Derivative 2.1: Millimeter-Wave (mmWave) Communication with Ultra-Low Latency EDCA

• Enabling Description: The wireless communication method is adapted for operation in the millimeter-wave (mmWave) frequency bands (e.g., 60 GHz, 70 GHz, 80 GHz, as per IEEE 802.11ad/ay), where symbol durations and slot times are significantly shorter (e.g., in nanoseconds) compared to sub-6 GHz Wi-Fi. The "predetermined slot time" for backoff procedures is scaled down proportionally. The "second parameter set" is characterized by extremely aggressive CWmin and AIFS values (e.g., CWmin=1, AIFS=1 for very high-priority traffic) to minimize channel access delay in sparse mmWave environments, where contention might be lower due to narrower beams. The "second parameter set timer" would operate with nanosecond-level resolution, terminating the aggressive parameters swiftly to avoid unnecessary channel hogging in case of a failed or partial UL MU transmission. This requires specialized PHY and MAC hardware (e.g., custom ASIC for time-critical MAC functions) capable of handling such high-speed operations, as general-purpose CPUs cannot meet the timing requirements. The trigger frames would include explicit time-of-flight (ToF) compensation for accurate immediate response windows.

sequenceDiagram
    participant STA as Wireless Terminal (mmWave)
    participant AP as Base Terminal (mmWave)
    AP->>STA: Trigger Frame (UL MU, mmWave)
    activate STA
    STA->>STA: Switch to Second Param Set (ns AIFS, CWmin=1)
    STA->>AP: Trigger-based PPDU (mmWave)
    activate AP
    AP->>STA: Immediate Response (M-BA, mmWave)
    deactivate AP
    STA->>STA: Set ns-resolution Timer
    loop Channel Access attempts
        STA->>STA: Perform EDCA with Second Param Set
    end
    STA->>STA: Timer Expires
    STA->>STA: Terminate Second Param Set
    deactivate STA

Derivative 2.2: Extreme-Scale Industrial IoT (IIoT) Sensor Networks with Prioritized Data Offloading

• Enabling Description: The wireless communication method is applied to an IIoT network with tens of thousands of low-power sensor nodes (wireless communication terminals) and a central gateway (base wireless communication terminal) for data aggregation. Sensor data includes both routine telemetry (low priority) and critical event alerts (high priority, requiring UL MU transmission). The "first parameter set" uses large CW values and AIFS to conserve power and reduce contention for routine data. The "second parameter set" for critical event alerts significantly reduces CWmin and AIFS, enabling rapid channel access. The "trigger" for multi-user uplink transmission participation is specifically for aggregated critical alerts from a cluster of sensors within a narrow time window. The "second parameter set timer" duration is dynamically determined by the gateway based on the expected volume of critical data and the number of participating sensors, preventing the network from being overwhelmed by a single type of traffic. The terminals would operate at low power consumption profiles, with their MAC layer EDCA logic implemented in ultra-low-power microcontrollers, only activating the "second parameter set" when a critical event dictates.

graph TD
    A[IIoT Gateway (Base Terminal)] --> B{Detect Critical Event Need};
    B -- Send Trigger Frame (Multicast) --> C[IIoT Sensor Terminal 1];
    B -- Send Trigger Frame (Multicast) --> D[IIoT Sensor Terminal N];
    C -- Detect Trigger --> E[Switch to Second Param Set (High Priority)];
    D -- Detect Trigger --> F[Switch to Second Param Set (High Priority)];
    E -- Transmit Critical Data PPDU --> A;
    F -- Transmit Critical Data PPDU --> A;
    A -- Send Immediate Response --> E;
    A -- Send Immediate Response --> F;
    E -- Set Timer --> G{Timer Active};
    F -- Set Timer --> H{Timer Active};
    G -- Timer Expires --> I{Terminate Second Param Set};
    H -- Timer Expires --> J{Terminate Second Param Set};

3. Cross-Domain Application

Derivative 3.1: Autonomous Vehicle-to-Infrastructure (V2I) Communication for Intersection Management

• Enabling Description: The method is applied in a V2I communication system where autonomous vehicles (wireless communication terminals) communicate with smart traffic infrastructure (base wireless communication terminals) for dynamic intersection management. During periods of high traffic or emergency vehicle preemption, the intersection controller (base terminal) triggers multiple vehicles for coordinated uplink transmission of their kinematic data (speed, position, trajectory). The "first parameter set" represents standard channel access for routine vehicle telemetry. The "second parameter set," activated by the trigger, uses aggressive EDCA parameters to ensure low-latency data transmission for critical path planning and collision avoidance at the intersection. The "second parameter set timer" is set to expire after a safe coordination interval, ensuring that vehicles revert to less aggressive channel access once the immediate intersection traversal risk is mitigated, preventing sustained channel monopolization. This ensures fairness and prevents a single vehicle from dominating channel access.

stateDiagram
    state "Default V2I Access" as Default
    state "Aggressive Intersection Coordination" as Coordinated

    Default --> Coordinated: Trigger Frame Received (from Intersection Controller)
    Coordinated --> Default: Second Param Set Timer Expires
    Coordinated --> Default: UL MU Transmission Complete & Acknowledged

    Default : EDCA with First Parameter Set
    Default : Routine Telemetry Data
    Coordinated : EDCA with Second Parameter Set (Lower AIFS, CWmin)
    Coordinated : Critical Kinematic Data
    Coordinated : Transmit Trigger-based PPDU
    Coordinated : Set Timer on Immediate Response

Derivative 3.2: Remote Surgery and Haptic Feedback Control in Telemedicine

• Enabling Description: In a tele-robotic surgery system, the surgical robot (wireless communication terminal) communicates with a remote surgeon's console (base wireless communication terminal) over a wireless link. The "first parameter set" manages general diagnostic data and low-priority system status updates. During critical surgical maneuvers requiring precise haptic feedback and real-time control, the surgeon's console triggers the robot for multi-user uplink transmission of high-fidelity sensor data (e.g., force, torque, position feedback from multiple joints simultaneously). The "second parameter set" utilizes highly prioritized EDCA parameters (e.g., minimum AIFS, small CWmin for guaranteed low-latency access) to ensure control stability and safety. The "second parameter set timer" is set by the robot upon receiving immediate acknowledgements for its control and feedback packets, expiring when the critical maneuver is completed or a safety timeout is reached. This mechanism guarantees that high-priority control data has precedence during critical phases, minimizing jitter and latency for stable remote operation.

flowchart TD
    SC[Surgeon Console (Base)] -- High-Priority Command --> SR{Surgical Robot (Terminal)};
    SR -- Current State: First Param Set --> SC;
    SC -- Trigger UL MU for Haptic Feedback --> SR;
    SR -- Switch to Second Param Set --> SR_ACTIVE[Robot with Aggressive EDCA];
    SR_ACTIVE -- Transmit Trigger-based PPDU (High-Fidelity Feedback) --> SC;
    SC -- Immediate Response (ACK/BA) --> SR_ACTIVE;
    SR_ACTIVE -- Set Timer --> SR_TIMER[Timer Running];
    SR_TIMER -- Haptic Feedback Continues --> SR_ACTIVE;
    SR_TIMER -- Timer Expires / Maneuver Complete --> SR_REVERT[Revert to First Param Set];
    SR_REVERT --> SR;

Derivative 3.3: Underwater Acoustic Networking for Autonomous Underwater Vehicles (AUVs)

• Enabling Description: The wireless communication method is adapted for acoustic communication between multiple Autonomous Underwater Vehicles (AUVs) acting as wireless terminals and a mother ship or a fixed underwater buoy acting as the base terminal. Due to the very slow propagation speed of sound in water, channel access procedures are vastly different, involving much longer slot times and interframe spaces (eIFS, aIFS). The "first parameter set" supports routine data collection and low-bandwidth status updates. When a critical event occurs (e.g., detection of a geological anomaly, unexpected obstacle), the base terminal triggers a coordinated UL MU transmission from a swarm of AUVs for rapid, synchronized sharing of high-resolution sonar or environmental data. The "second parameter set" would apply significantly shorter (though still long by RF standards) AIFS and CWmin values, alongside spread spectrum techniques to improve robustness against multipath. The "second parameter set timer" is set to account for acoustic propagation delays and expected response times, ensuring that the AUVs revert to less intrusive channel access methods once the burst of critical data is transmitted and acknowledged, preventing acoustic channel saturation.

sequenceDiagram
    participant AUV1 as AUV Terminal 1
    participant AUV2 as AUV Terminal 2
    participant MS as Mother Ship (Base Terminal)
    MS->>AUV1: Trigger (Acoustic UL MU)
    MS->>AUV2: Trigger (Acoustic UL MU)
    AUV1->>AUV1: Switch to Second Param Set (Acoustic Optimized)
    AUV2->>AUV2: Switch to Second Param Set (Acoustic Optimized)
    AUV1->>MS: Trigger-based PPDU (Sonar Data)
    AUV2->>MS: Trigger-based PPDU (Env Data)
    MS->>AUV1: Immediate Response (Acoustic BA)
    MS->>AUV2: Immediate Response (Acoustic BA)
    AUV1->>AUV1: Set Second Param Set Timer (Acoustic Scaled)
    AUV2->>AUV2: Set Second Param Set Timer (Acoustic Scaled)
    AUV1->>AUV1: Timer Expires -> Terminate
    AUV2->>AUV2: Timer Expires -> Terminate

4. Integration with Emerging Tech

Derivative 4.1: AI-Driven Optimization of EDCA Parameter Sets

• Enabling Description: The selection of the "second parameter set" (CWmin, CWmax, AIFS) and the duration of the "second parameter set timer" are not static but are dynamically optimized by an on-device Artificial Intelligence (AI) agent residing in the wireless communication terminal's processor (110). This AI agent, a reinforcement learning (RL) model, continuously observes channel conditions (e.g., interference levels, number of contending stations, packet error rates, buffer occupancy) and the success/failure rate of UL MU transmissions. When a base terminal triggers a UL MU transmission, the AI agent selects the optimal "second parameter set" from a predefined policy space (or generates a new one within constraints) to maximize throughput and minimize latency for the triggered ACs. It also calculates an optimal "second parameter set timer" duration to balance fast termination with sufficient time for retransmissions if needed. This optimization happens in milliseconds, leveraging specialized neural processing units (NPUs) or dedicated AI accelerators integrated within the SoC. The AI also determines the "type of responding requested by the MPDU" to inform timer setting.

graph TD
    A[Wireless Terminal (Processor 110)] --> B(Transceiver 120);
    B --> C{Receive Trigger Frame};
    C -- YES --> D[AI Agent (RL Model)];
    D -- Observe Channel State --> D;
    D -- Inputs: Channel Params, PER, Buffer State --> D;
    D -- Outputs: Optimal Second Param Set, Timer Duration --> E[EDCA Controller];
    E -- Apply Params --> F{Transmit Trigger-based PPDU};
    F --> G{Receive Immediate Response};
    G -- Feedback to AI Agent --> D;
    G -- Start Timer (AI-determined) --> H{Timer Running};
    H -- Expires --> I{Terminate Second Param Set};

Derivative 4.2: IoT Sensor-Triggered EDCA with Real-time Monitoring and Adjustments

• Enabling Description: The wireless communication terminal is an IoT sensor device equipped with various physical sensors (e.g., accelerometers, temperature, humidity, light) whose data is monitored by an integrated IoT sensor management module. The "multi-user uplink transmission participation" is not solely triggered by the base terminal but can also be initiated by local anomaly detection from the IoT sensors. For example, a sudden vibration detected by the accelerometer (indicating an urgent event) can locally trigger the device to request UL MU participation and, if granted by the base terminal, immediately switch to its "second parameter set." The "second parameter set timer" is tied to real-time feedback from the IoT sensors; if the anomaly persists or intensifies post-transmission, the timer may be extended or re-initiated, or the parameter set adjusted further. Conversely, if the anomaly resolves, the timer terminates the aggressive EDCA parameters. This closed-loop system uses real-time local environmental data to inform network access behavior, ensuring that EDCA parameters dynamically align with urgent physical events.

stateDiagram
    state "Normal Sensing (First Params)" as Normal
    state "Urgent Data Transmission (Second Params)" as Urgent

    Normal --> Urgent: Local Anomaly Detected (IoT Sensors)
    Normal --> Urgent: Trigger Frame Received (from Base)

    Urgent --> Normal: Second Param Set Timer Expires
    Urgent --> Normal: Anomaly Resolved (IoT Sensors)

    Normal : EDCA with First Parameter Set (Low Power)
    Urgent : EDCA with Second Parameter Set (Aggressive)
    Urgent : Transmit Trigger-based PPDU
    Urgent : Set/Adjust Timer based on Immediate Response AND IoT Sensor Feedback

Derivative 4.3: Blockchain-Verified EDCA Parameter Set Auditing for Trustworthy Networks

• Enabling Description: The entire process of EDCA parameter set negotiation, switching, and termination for UL MU transmissions is subject to a blockchain-based auditing mechanism to ensure network fairness, security, and compliance in critical infrastructure deployments. Each "second parameter set" definition (CWmin, CWmax, AIFS), the trigger event, the transmission of the trigger-based PPDU, the reception of the immediate response, and the setting/expiration of the "second parameter set timer" are recorded as cryptographic hashes and committed to a distributed ledger. Wireless communication terminals (nodes in the blockchain network) include a tamper-proof hardware security module (HSM) that signs these events before they are added to a private consortium blockchain. This allows network administrators (or regulators) to audit the channel access behavior of individual devices and the base terminal retrospectively, verifying that EDCA parameters were applied correctly, timers were managed appropriately, and no malicious channel monopolization occurred. Smart contracts on the blockchain can define the rules for valid EDCA parameter sets and trigger automated alerts or penalties for deviations.

sequenceDiagram
    participant STA as Wireless Terminal
    participant AP as Base Terminal
    participant BCN as Blockchain Network
    AP->>STA: Trigger Frame + Second Param Set (signed)
    STA->>STA: Verify Signature (HSM)
    STA->>BCN: Record Trigger Event Hash (signed by HSM)
    STA->>AP: Trigger-based PPDU
    AP->>STA: Immediate Response (signed)
    STA->>BCN: Record Immediate Response Hash (signed by HSM)
    STA->>STA: Set Second Param Set Timer
    STA->>BCN: Record Timer Start Hash (signed by HSM)
    STA->>STA: Timer Expires
    STA->>BCN: Record Timer Expiration Hash (signed by HSM)
    BCN->>BCN: Validate Event Sequence (Smart Contract)

5. The "Inverse" or Failure Mode

Derivative 5.1: Safe-Failure EDCA for Critical Communication Loss

• Enabling Description: The wireless communication terminal is designed with a "safe-failure" EDCA mode to ensure graceful degradation and minimize network disruption upon loss of critical communication with the base terminal or failure to receive an immediate response to a trigger-based PPDU. If the terminal fails to receive an immediate response for its trigger-based PPDU, the "second parameter set timer" immediately triggers a transition to a third parameter set. This third parameter set is designed to be highly unaggressive (e.g., very large CWmax, maximum AIFS values, or even a complete cessation of transmission attempts for that AC) to prevent congestion, rather than an aggressive one. This "third parameter set" is explicitly for failure scenarios. If the base terminal is no longer detected (e.g., multiple beacon frame omissions), the terminal immediately reverts all ACs to the highly unaggressive "third parameter set" and initiates a predefined recovery procedure, such as scanning for an alternative base terminal or entering a low-power hibernation state. The failure detection logic is implemented in a watchdog timer circuit separate from the main processor.

stateDiagram
    state "First Param Set (Default)" as Default
    state "Second Param Set (UL MU Active)" as Active
    state "Third Param Set (Safe-Failure/Inactive)" as FailSafe

    Default --> Active: Trigger Received + Immediate Response
    Active --> Default: Second Param Set Timer Expires
    Active --> FailSafe: Immediate Response Missed for PPDU
    Active --> FailSafe: Base Terminal Link Lost (Beacon Omission)
    Default --> FailSafe: Base Terminal Link Lost (Beacon Omission)

    Default : Normal EDCA
    Active : Aggressive EDCA
    FailSafe : Highly Unaggressive EDCA / Halt Transmission

Derivative 5.2: Low-Power/Limited-Functionality EDCA for Extended Battery Life

• Enabling Description: For wireless communication terminals that are battery-powered and operate in resource-constrained environments (e.g., remote environmental sensors), an adaptive EDCA mechanism is implemented to prioritize battery life. The "first parameter set" is a low-power configuration with very large contention windows and extended AIFS durations, minimizing active radio time and channel access attempts. When the base wireless communication terminal triggers a multi-user uplink transmission for a burst of high-priority data (e.g., critical sensor readings), the terminal switches to the "second parameter set," which provides moderately aggressive EDCA parameters to ensure timely data delivery but is still optimized for a balance between performance and power consumption (e.g., CWmin and AIFS values are reduced but not to the absolute minimum). Crucially, the "second parameter set timer" has a maximum allowable duration. Even if the immediate response implies a prolonged UL MU session, the terminal automatically terminates the "second parameter set" and reverts to the "first parameter set" if this maximum timer is reached, or if the remaining battery capacity falls below a predetermined threshold, thereby preventing excessive power drain at the cost of immediate throughput.

flowchart TD
    S[Start: Idle / Low Power Mode] --> A{Battery Threshold OK?};
    A -- NO --> P[Power-Save Mode (Halt Tx)];
    A -- YES --> B[First Param Set (Default, Low-Power EDCA)];

    B --> C{Receive Trigger Frame?};
    C -- YES --> D[Second Param Set (Moderately Aggressive EDCA)];

    D --> E{Transmit Trigger-based PPDU};
    E --> F{Receive Immediate Response?};
    F -- YES --> G[Set Second Param Set Timer (Max Duration/Battery Check)];
    G -- Timer Expires OR Low Battery --> B;
    G -- Timer Active & Battery OK --> E;
    F -- NO --> B;