2000 character limit reached
Kom8ndor: An IEEE 802.11bn-Oriented Simulator for Wi-Fi 8 and Beyond
Published 24 Jun 2026 in cs.NI | (2606.25435v1)
Abstract: The upcoming IEEE 802.11bn amendment marks a paradigm shift in Wi-Fi, which will pose ambitious performance targets under the paradigm of Ultra-High Reliability (UHR). To understand the implications of such a new technology and to support early research and protocol design for Wi-Fi~8, we present \texttt{Kom8ndor}. This discrete-event network simulator extends the open-source Komondor platform (a simulator validated against ns-3 and other analytical tools) with 802.11bn features. Among the newly added functionalities, we highlight Multi-Access Point Coordination (MAPC) -- including Coordinated Time-Division Multiple Access (Co-TDMA), Coordinated Spatial Reuse (Co-SR), and Coordinated Beamforming (Co-BF) -- , Non-Primary Channel Access (NPCA), and Dynamic Subband Operation (DSO). Beyond Wi-Fi~8 implementations, \texttt{Kom8ndor} introduces novel functionalities (e.g., a machine learning wrapper for building AI-based protocols) and a modular design to boost the prototyping and research of future Wi-Fi technologies. \texttt{Kom8ndor} is open-source (GNU GPLv3) and available at https://github.com/wn-upf/Komondor.
Paper Prompts
Sign up for free to create and run prompts on this paper using GPT-5.
Top Community Prompts
Explain it Like I'm 14
What is this paper about?
This paper introduces Kom8ndor (said “commandor”), a new computer simulator that helps researchers test ideas for the next generation of Wi‑Fi, called Wi‑Fi 8 (officially IEEE 802.11bn). Wi‑Fi 8 aims for ultra‑high reliability so it can support things like factory robots and other critical tasks, not just web browsing. Kom8ndor lets people try out Wi‑Fi 8 features quickly and safely on a computer before building real devices.
What questions are the authors asking?
In simple terms, the authors ask:
- How can we build a fast, easy‑to‑use, open‑source simulator that models the big new ideas in Wi‑Fi 8?
- Can this simulator help test how multiple Wi‑Fi access points (APs) coordinate, how devices use radio channels more flexibly, and how AI could make smarter Wi‑Fi decisions?
- Do these new Wi‑Fi 8 tools actually improve network performance in example scenarios?
How did they study it? (Methods and approach)
A simulator built for speed and clarity
Think of a busy classroom where students raise hands to speak. A simulator is like a controlled “role‑play” of that class, where you can rewind, change the rules, and see what happens. Kom8ndor is a “discrete‑event” simulator, meaning it jumps from important moments (events) to the next (like “student starts talking” → “teacher replies”) rather than watching every single millisecond.
Inside, the simulator:
- Represents Wi‑Fi devices (APs and stations/phones) as “nodes.”
- Creates traffic (who wants to send data and when).
- Uses a step‑by‑step “state machine” so each device follows a clear script: wait, listen, back off, send, wait for reply, etc.
- Records results like speeds, delays, and collisions.
It’s built on C/C++ for speed, has simple input files to set up scenarios, and is open‑source so anyone can use or extend it.
New Wi‑Fi 8 tricks it can model
Here are the main Wi‑Fi 8 features Kom8ndor can simulate, explained with everyday analogies:
- Multi‑Access Point Coordination (MAPC): Neighboring APs plan together so the “conversation” goes more smoothly.
- Co‑TDMA: APs slice one “turn to talk” into mini‑turns, taking turns quickly and fairly.
- Co‑SR: APs talk at the same time but use “indoor voices” (lower power) to avoid bothering each other.
- Co‑BF: APs use “flashlights for sound” (beamforming) to aim their signal precisely at their own device and “dim” it toward others, so two APs can talk at once with less cross‑talk.
- Non‑Primary Channel Access (NPCA): If the main lane is jammed, an AP briefly moves to a side lane within its allowed road to get its message through, then comes back.
- Dynamic Subband Operation (DSO): If an AP has a super‑wide road (say 160 MHz) but its devices are small (say 20–40 MHz), it splits the big road into smaller lanes so it can serve multiple devices at once in a single turn, avoiding wasted space.
- Smarter channel access methods: Besides the usual “wait and randomly try” (classic Wi‑Fi), it includes options that aim for more predictable turns (like small, fair schedules) to reduce chaos in crowded networks.
How the simulator “plays out” a Wi‑Fi conversation
Each device moves through clear stages—listen, count down, transmit, wait for acknowledgment—like following a recipe. For MAPC, Kom8ndor adds special “handshake” messages (like ICF/ICR and triggers) so APs can agree on how to share a turn. It also models beamforming (aiming signals) with a standard math method under the hood, but you can picture it as pointing a flashlight at your friend while putting “shadows” in other directions to avoid blinding someone else.
Smarts and AI
Kom8ndor can plug into Python so you can attach a “brain” (like a machine‑learning model) that picks settings during the simulation—things like which channel to use. This makes it easy to test AI ideas without rewriting the simulator.
What did they find?
The authors show example scenarios to demonstrate the tool and illustrate how the new features help:
- Coordinated APs (MAPC):
- Co‑TDMA: Splitting a talking turn fairly can sometimes add a bit of overhead, so it may not always beat classic Wi‑Fi in simple cases.
- Co‑SR: Letting two APs talk at once at lower power can boost combined speeds if they’re placed well.
- Co‑BF: Using beamforming to aim signals gave the biggest speed gains in their example because it reduces interference the most.
- Flexible spectrum use (DSO and NPCA):
- With DSO, an AP used different sub‑lanes to serve multiple narrow‑band devices at the same time instead of one‑by‑one—more efficient use of the big channel.
- With NPCA, another AP hopped to a quieter sub‑lane when its main part was blocked, getting more done instead of waiting.
- Together, they significantly increased total throughput (combined data rate) in the example.
- AI integration:
- They show how a simple Python “server” can make decisions (even a random one) during the run, proving the simulator can act like a lab for more advanced AI later (e.g., deep learning).
These aren’t meant as final, universal performance claims—they’re clear, controlled examples showing that Kom8ndor can model and compare Wi‑Fi 8 features and that those features can deliver real benefits in the right settings.
Why does this matter?
- Wi‑Fi 8 is aiming for ultra‑reliable, predictable performance—important for factories, health devices, and other critical systems.
- Hardware and standards evolve slowly, but research needs to move fast. A flexible, open simulator helps test new ideas early, find trade‑offs, and avoid expensive mistakes.
- Kom8ndor balances speed and realism: it’s simpler than giant, heavy simulators but still accurate enough for early research, and it’s built specifically to explore Wi‑Fi 8’s headline features.
- The built‑in AI connection opens the door to “self‑tuning” Wi‑Fi that learns the best settings for different environments.
Big picture and future impact
This work gives the Wi‑Fi research community a shared, open tool to:
- Prototype and compare Wi‑Fi 8 features like AP coordination, smarter channel use, and deterministic access.
- Explore how older and newer features work together (the authors plan to add more, like multi‑link operation and OFDMA).
- Build and test AI‑powered strategies that could make future Wi‑Fi more reliable and efficient.
In short, Kom8ndor is a practical, open “wind tunnel” for Wi‑Fi 8: it helps engineers try ambitious ideas safely and quickly, so the real networks we’ll use in the future can be faster, fairer, and more dependable.
Knowledge Gaps
Knowledge gaps, limitations, and open questions
The paper leaves the following concrete gaps and open questions that future work could address:
- Validation of new 802.11bn features: no quantitative validation of Kom8ndor’s bn-specific implementations (MAPC, NPCA, DSO, new channel access) against high-fidelity references (e.g., ns-3 prototypes, analytical models, or measurements).
- PHY abstraction fidelity: unspecified SNR→PER/MCS mapping and link-to-system calibration for Wi‑Fi 8; lack of PER curves, coding gains, and aggregation/BLOCK-ACK effects validated against link-level tools (e.g., MATLAB WLAN Toolbox).
- Beamforming realism in Co-BF: assumes perfect ZF with ideal CSI and isotropic ULAs; missing CSI acquisition/feedback mechanisms, training/NDP overheads, quantization errors, synchronization errors (timing/CFO), side-lobes, wideband effects, and multipath/3D patterns.
- Control-frame modeling in coordinated modes: all control frames are omnidirectional; no study of beamformed control/sounding, its overhead, or its impact on NAV/protection and legacy coexistence.
- MAPC coverage gaps: only Co‑TDMA/Co‑SR/Co‑BF are implemented; Co‑RTWT and Co‑CR are not, and their interactions with bn features remain unstudied.
- MAPC scalability: while the framework allows >2 APs, there is no scalability study of performance, overhead, synchronization, and fairness in dense, overlapping groups.
- MAPC group management: no mechanisms for dynamic discovery, negotiation, conflict resolution among overlapping coordination groups, or security/authentication for inter‑AP agreements.
- Co‑TDMA scheduling: only equal TXOP splitting is supported; no QoS-/deadline-aware, backlog-aware, or utility/fairness-optimized schedulers.
- Co‑SR power control: default fixed power for the coordinated AP; no algorithms for interference-budget–aware power assignment, closed-loop measurements, or per‑STA constraints.
- Uplink coordination: MAPC appears DL-centric; lack of UL MAPC support (UL triggers, simultaneous UL transmissions, mixed DL/UL within a coordinated TXOP).
- DSO scheduling policy: round-robin STA selection only; no QoS-aware, traffic-aware, or channel-aware subband assignment; no analysis of fairness or starvation under heterogeneous loads.
- DSO scope and directionality: unclear support for UL DSO and mixed DL/UL subband operation; fragmentation/aggregation overheads under DSO not modeled.
- NPCA control logic: NPCA uses a preconfigured secondary primary and a simple OBSS trigger; missing decision policies (switch thresholds, hysteresis, dwell times), return policies, and analysis of switching costs vs. gains.
- Cross-feature interactions: no systematic study of interactions and conflicts among NPCA, DSO, preamble puncturing, EDCA parameters, and MAPC (e.g., protection/NAV consistency across subbands).
- Legacy coexistence: behavior of non‑bn devices exposed to bn control frames (ICF/ICR/TF/MU‑RTS), protection mechanisms, and mixed deployments (Wi‑Fi 6/7/8) is not modeled or evaluated.
- Missing Wi‑Fi 7/8 features: MLO, OFDMA/RU scheduling, and (R‑)TWT are absent (not yet integrated), so their interplay with MAPC/NPCA/DSO and their joint impact on UHR remain unknown.
- UHR-centric KPIs: examples report throughput only; no support or evaluation of bounded latency, tail latency (e.g., 99.999th percentile), deadline‑miss ratios, or packet delivery guarantees central to UHR targets.
- Channel and interference models: limited to path loss and co‑channel interference; no time‑varying fading, shadowing, Doppler/mobility, blockage (esp. at 6/7 GHz and mmWave), or 3D antenna patterns/polarization.
- Hidden terminals and capture: no explicit modeling or validation of hidden-node effects, capture, and NAV accuracy under puncturing/NPCA/MAPC.
- Regulatory constraints: AFC, PSD limits, LPI/VLP device classes, DFS, and regional rules for 6 GHz are not represented; implications for feature feasibility are unexamined.
- Energy modeling: no power/energy models for AP/STA, including PSM, R‑TWT energy savings, NPCA switching energy cost, or beamforming training energy.
- Mobility and association dynamics: no support/evaluation of mobility, (re)association, handovers, or their impact on MAPC/NPCA/DSO stability and performance.
- Alternative backoff schemes: provided methods (deterministic/IYT/ECA) lack comprehensive evaluation of fairness, stability, collision recovery, and interactions with MAPC/NPCA/EDCA.
- Centralized/ML control plane: no modeling of control-plane latency, bandwidth overhead, failures, or security for centralized orchestration and coordinated learning in multi‑AP systems.
- ML interface breadth: Python socket exposes a minimal feature vector; missing standardized observation/action spaces, logging for reproducibility, synchronization semantics, and support for online training loops (beyond inference).
- Multi-agent learning at scale: no benchmarks or case studies on non‑stationarity, communication constraints, convergence, and sample efficiency for decentralized/coordinated learning in dense WLANs.
- Reward design for UHR: no guidance or built‑in reward formulations capturing reliability, deadlines, and risk/safety constraints critical for UHR‑compliant learning.
- Large-scale performance: no quantitative benchmarks of event rate, runtime, and memory vs. ns‑3/OMNeT++ for large topologies; no profiling/optimization guidance.
- Interoperability: no trace import/export or co-simulation hooks with ns‑3/OMNeT++/MATLAB for cross-validation and mixed‑fidelity studies.
- PER/aggregation realism: packet error models, A‑MPDU block ACK policies, and retransmission dynamics are not detailed or validated under bn MCS/PHY assumptions.
- Timing realism: absence of clock drift, SIFS variance, and hardware timing inaccuracies that influence coordinated exchanges and deterministic access claims.
- UL MU/OFDMA with DSO: lack of trigger-based UL MU and RU allocation algorithms in presence of DSO/NPCA, and their coordination under MAPC.
- Security and robustness: no threat model or mechanisms for misbehaving/compromised APs in coordination (e.g., MAPC abuse), spoofed frames, or ML adversaries.
- Documentation/testing: no mention of unit tests/CI, reference scenarios with expected outputs, or seeded determinism checks to ensure reproducibility across versions.
- Logging overhead impact: acknowledged performance hit from logging, but no quantified guidance or safe defaults for large experiments without distorting timing.
Practical Applications
Immediate Applications
Below are actionable use cases that can be deployed now using Kom8ndor’s features (MAPC, NPCA, DSO, advanced channel access, and ML integration), with sectors, workflows/products, and feasibility notes.
- Rapid prototyping of Wi‑Fi 8 MAPC (Co‑TDMA, Co‑SR, Co‑BF) algorithms
- Sector: networking hardware/software (AP/chipset vendors), telecom R&D
- What to do: Use Kom8ndor to design and compare coordination policies (e.g., TXOP splits, transmit‑power caps, ZF beam steering) across realistic multi‑AP scenarios; quantify throughput/latency trade‑offs and overheads
- Tools/workflows: Scenario templates + mapc.csv; automated sweeps via komondor_main; per‑node logs for KPIs; internal design reviews for standard contributions
- Assumptions/dependencies: Simplified MAC/PHY abstraction (not a full link‑level model); current 802.11bn draft may evolve; Co‑BF uses idealized ZF with omni control frames; GPLv3 limits redistribution in proprietary bundles (internal use is fine)
- Enterprise Wi‑Fi planning under OBSS using NPCA and DSO
- Sector: enterprise IT, managed Wi‑Fi, education, healthcare
- What to do: Evaluate when to enable NPCA to mitigate overlapping BSS contention and how to schedule narrow‑band STAs with DSO on wide channels to avoid spectrum waste
- Tools/workflows: Produce “what‑if” studies per site type (campus, hospital floors) by parameterizing input_nodes and config_models; generate reports for channel plans and AP configs
- Assumptions/dependencies: Real‑world gains depend on device support for NPCA/DSO, local propagation and density; path‑loss and interference models must be calibrated to target sites
- AI‑assisted WLAN control prototyping (channel selection, EDCA/CW tuning, SR/DCB policies)
- Sector: software (cloud controllers), telecom operations, enterprise networking
- What to do: Plug Python RL/Bandit models via the socket interface to learn online/offline policies for channel, power, NPCA triggers, or EDCA parameters; evaluate decentralized vs centralized control
- Tools/workflows: External Python servers (PyTorch/TensorFlow), reward engineering tied to throughput, delay, collision rate; training/evaluation loops over scenario sets
- Assumptions/dependencies: Sim‑to‑real transfer requires careful domain randomization and post‑deployment guardrails; telemetry available in production must match features used in training
- Deterministic and reliability‑oriented MAC experiments (Deterministic Backoff, IYT, ECA)
- Sector: industrial automation, robotics (AGVs/AMRs), healthcare (clinical telemetry)
- What to do: Compare bounded‑latency behavior of deterministic access proposals vs EDCA under load; test MAPC+deterministic access for UHR targets before lab trials
- Tools/workflows: Configure traffic (Poisson/bursty, full‑buffer) and contention parameters per AC; evaluate delay tails and deadline miss ratios
- Assumptions/dependencies: Some mechanisms are research proposals (not standardized nor supported by COTS devices); results guide feasibility and lab validation
- Curriculum and hands‑on labs for Wi‑Fi 8
- Sector: academia, professional training
- What to do: Teach DCF vs Co‑SR/Co‑BF; demonstrate NPCA/DSO gains; introduce RL for Wi‑Fi control using the Python wrapper
- Tools/workflows: Prebuilt examples from the repo; assignments around state machine tracing, MAPC handshake timing, and agent design
- Assumptions/dependencies: Linux/macOS build environment and basic C++/Python skills required; PHY details are abstracted (good for system‑level courses)
- Standards and regulatory input preparation (system‑level evidence)
- Sector: standards bodies, policy teams in vendors/operators
- What to do: Quantify overheads/benefits of emerging coordination handshakes, power limits for Co‑SR, and puncturing policies to inform contributions
- Tools/workflows: Reproducible input files and logs attached to contributions; sensitivity analyses across densities and traffic mixes
- Assumptions/dependencies: Complement with link‑level or ns‑3 studies and measurements for higher‑fidelity aspects; acceptance depends on cross‑validation
- DevOps for WLAN algorithm CI/CD
- Sector: vendor software engineering
- What to do: Integrate komondor_main into CI to regress MAC/ML algorithm changes against a library of scenarios; flag throughput/latency regressions
- Tools/workflows: Headless runs with seeds and codes; standardized KPIs parsed from logs; artifact storage per commit
- Assumptions/dependencies: Simulation runtime scales with log verbosity and scenario size; maintain deterministic seeds to control variance
- Enthusiast/SMB lab planning and education
- Sector: daily life, small business IT
- What to do: Explore channel bonding/puncturing and power strategies in small topologies; understand OBSS effects and benefits of future Wi‑Fi 8 features
- Tools/workflows: Small scenario files, simple metrics (per‑BSS throughput and collisions)
- Assumptions/dependencies: Translating results to home/SMB routers depends on vendor features and firmware access; advanced features may not yet exist in consumer gear
Long‑Term Applications
These are forward‑looking uses that require further research, scaling, standard maturation, or productization.
- Digital twins for enterprise Wi‑Fi 8 with AI “co‑pilot” control
- Sector: enterprise networking, cloud software
- What it enables: A controller integrates a Kom8ndor‑backed twin to test MAPC/NPCA/DSO and control policies on live telemetry mirrors before rollout; closed‑loop safe deployment (A/B or canary)
- Tools/products: “Wi‑Fi 8 Digital Twin” service; policy optimizers trained offline and validated online
- Dependencies: Robust data pipelines, model calibration to sites, APIs between controller and twin; additional features (MLO/OFDMA/R‑TWT) as they are implemented
- MAPC‑enabled cloud controllers and on‑prem coordinators
- Sector: AP vendors, MSPs
- What it enables: Orchestrate joint TXOPs and simultaneous transmissions across APs (Co‑TDMA/Co‑SR/Co‑BF) to meet UHR SLAs; dynamic scheme selection per traffic/load
- Tools/products: “Multi‑AP Coordination” modules validated in Kom8ndor; scheduler libraries; control‑plane extensions
- Dependencies: Standardized MAPC support in AP silicon/firmware and client interoperability; careful handling of overheads and backward compatibility
- Pre‑silicon and firmware validation for Wi‑Fi 8 chipsets
- Sector: semiconductors
- What it enables: Early MAC/PHY firmware evaluation for coordination handshakes, NPCA transitions, and beamforming interactions under scale
- Tools/products: Internal harnesses linking Kom8ndor scenarios to firmware stubs; stress‑test libraries
- Dependencies: For PHY‑critical behavior, couple with link‑level simulators or hardware‑in‑the‑loop; align abstraction levels
- UHR network design for safety‑critical operations
- Sector: manufacturing, logistics robotics, healthcare
- What it enables: Validate that a chosen mix of Co‑TDMA/Co‑BF, deterministic access, and DSO meets bounded latency/reliability targets for AGVs, cobots, or clinical devices before site deployment
- Tools/products: “Industrial Wi‑Fi UHR planner” workflow; scenario libraries per factory/hospital archetype
- Dependencies: Compliance with regulatory and safety standards; onsite RF surveys and pilot trials; vendor support for required features
- Spectrum policy and coexistence stress‑testing (e.g., 6 GHz)
- Sector: regulators, policy think‑tanks, industry alliances
- What it enables: Assess system‑level impacts of NPCA, MAPC, and puncturing on OBSS coexistence and incumbents; explore LPI/VLP policy options
- Tools/products: Public, reproducible study packs with scenarios and scripts
- Dependencies: Acceptance requires rigorous calibration and triangulation with higher‑fidelity tools and measurements; evolving draft text may change behavior
- Deep RL for autonomous Wi‑Fi resource management
- Sector: AI/software, networking vendors
- What it enables: Train DQN/actor‑critic agents for channel/power/EDCA/MAPC scheme selection using Kom8ndor as an RL gym; deploy policies to controllers/APs
- Tools/products: Pretrained policy packs; safety filters; simulation‑to‑production toolchains
- Dependencies: Compute/resources for large‑scale training; generalization across environments; safe exploration constraints in production
- Cross‑technology network planning (Wi‑Fi 8 with mmWave or future features)
- Sector: telecom, advanced R&D
- What it enables: Plan heterogeneous deployments combining 802.11bn with parallel mmWave or upcoming features (MLO/OFDMA/R‑TWT) once implemented in the simulator
- Tools/products: Multi‑band planners; joint schedulers
- Dependencies: Simulator extensions to cover additional PHY/MAC; validated propagation models for new bands
- Certification and interoperability test design
- Sector: industry consortia, test labs
- What it enables: Derive representative certification scenarios for MAPC/NPCA/DSO from large‑scale simulation campaigns before building OTA testbeds
- Tools/products: Scenario blueprints and traffic patterns; pass/fail KPI thresholds
- Dependencies: Alignment with Wi‑Fi Alliance test plans; consistent mapping from simulated to lab conditions
- Vendor‑neutral benchmarks and competitions
- Sector: academia/industry collaboration
- What it enables: Open leaderboards for MAPC scheduling, coexistence strategies, and AI controllers using shared Kom8ndor scenarios and metrics
- Tools/products: Benchmark suites; standardized parsers; competition infrastructure
- Dependencies: Community governance; ensuring reproducibility and fairness across submissions
Each application’s feasibility depends on accurately parameterizing environments (path loss, interference), the maturity of 802.11bn features in real hardware, and acceptance of Kom8ndor’s simplified yet validated MAC/PHY abstractions. Where deployment decisions are critical (e.g., safety‑critical UHR, policy), combine Kom8ndor with higher‑fidelity tools, lab tests, and field measurements.
Glossary
- A-MPDU (Aggregate MAC Protocol Data Unit): A PHY/MAC aggregation format that bundles multiple MAC frames into a single transmission to improve efficiency. "In Co-SR, coordinated APs agree on the transmit power to be used during a simultaneous Aggregate MAC Protocol Data Unit (A-MPDU) downlink transmission."
- Access Category (AC): A QoS class in EDCA that assigns different contention parameters to traffic types (voice, video, best effort, background). "EDCA was introduced in IEEE 802.11e to extend DCF and provide QoS differentiation across four Access Categorys (ACs), namely Voice (VO), Video (VI), Best Effort (BE), and Back- ground (BK) [21]."
- Arbitration Interframe Space (AIFS): A QoS-dependent interframe spacing in EDCA that governs how long a node waits before backoff. "Kom8ndor supports EDCA and allows a flexible instantiation of its parameters-Arbitration Interframe Space (AIFS), maximum and minimum Contention Window (CW), and TXOP limit-per node and AC."
- Basic Service Set (BSS): The fundamental building block of a Wi‑Fi network consisting of an AP and its associated stations. "Kom8ndor outputs include simulation summaries (e.g., per-Basic Service Set (BSS) performance, per-node statistics, collision counts)"
- Binary Exponential Backoff (BEB): A contention algorithm that doubles the contention window after collisions to reduce repeated collisions. "The standard DCF relies on Carrier Sense Multiple Access with Collision Avoidance (CSMA/CA) with Binary Exponential Backoff (BEB)"
- Carrier Sense Multiple Access with Collision Avoidance (CSMA/CA): A listen-before-talk MAC method where nodes sense the channel and use backoff to avoid collisions. "The standard DCF relies on Carrier Sense Multiple Access with Collision Avoidance (CSMA/CA) with Binary Exponential Backoff (BEB)"
- Clear-to-Send (CTS): A control frame used with RTS/CTS to reserve the channel and mitigate collisions/hidden nodes. "e.g., acknowledgment (ACK), Clear-to-Send (CTS))"
- Coordinated Beamforming (Co-BF): A MAPC scheme enabling simultaneous transmissions by steering beams toward desired STAs and nulling interference to others. "In Co-BF, two APs transmit simultane- ously thanks to coordinated inter-BSS interference suppression"
- Coordinated Channel Recommendation (Co-CR): A MAPC scheme for coordinating channel choices for device-to-device links. "Coordinated Channel Recommendation (Co-CR) (coordinates the channels used for device-to-device transmissions)."
- Coordinated R-TWT (Co-RTWT): A MAPC scheme that coordinates Restricted Target Wake Time schedules across BSSs. "Coordinated R-TWT (Co-RTWT) (coordinates R-TWT schedules)"
- Coordinated Spatial Reuse (Co-SR): A MAPC scheme allowing simultaneous transmissions under controlled power to manage interference. "Coordinated Spatial Reuse (Co-SR)"
- Coordinated Time Division Multiple Access (Co-TDMA): A MAPC scheme that partitions a TXOP into time slots for multiple APs. "Co-TDMA Operation: The coordinating AP splits the TXOP into orthogonal time slots, assigned to different partici- pating APs."
- Contention Window (CW): The range from which a random backoff is drawn; increases/decreases based on contention outcomes. "maximum and minimum Contention Window (CW)"
- COST library: A component‑oriented C/C++ discrete‑event simulation framework used by Kom8ndor. "Kom8ndor uses the C/C++ COST library [18]"
- Deep Neural Network (DNN): A multi-layer machine learning model used for complex function approximation in RL/control. "To run complex ML paradigms such as Deep Neural Networks (DNNs) and leverage existing libraries such as PyTorch"
- Deep Q-Network (DQN): A value‑based deep RL algorithm that approximates Q‑values with a neural network. "The same interface naturally supports algorithms like Deep Q-Network (DQN), turning Kom8ndor into an RL gym like [5]."
- Deterministic Backoff: A channel access approach that uses a fixed backoff function to improve determinism and reduce collisions. "To address large contention delays and lack of determinism, a deterministic backoff proposal was introduced in [22]."
- Dynamic Channel Bonding (DCB): A mechanism that adapts the set of bonded channels per transmission based on instantaneous occupancy. "Based on the DCB implementation in Komondor, Kom8ndor adds preamble puncturing"
- Dynamic Subband Operation (DSO): A Wi‑Fi 8 feature allowing an AP to schedule multiple narrower STAs on different subbands within one wide TXOP. "Dynamic Subband Operation (DSO): DSO tries to fill the increasing capability gap between AP and STA devices"
- Distributed Coordination Function (DCF): The legacy CSMA/CA-based MAC protocol for channel access in Wi‑Fi. "Figure 1 shows two examples of implemented frame sequences to realize Distributed Coordination Function (DCF) with Request-to- Send (RTS)/CTS (Fig. 3a)"
- Distributed Interframe Space (DIFS): The interframe spacing used by DCF before backoff countdown. "DIFS + BO"
- Enhanced Collision Avoidance (ECA): A MAC variant that reuses the same backoff after successful transmissions to reduce collisions. "Enhanced Collision Avoidance (ECA) 24"
- Enhanced Distributed Channel Access (EDCA): The QoS-enabled extension of DCF defining four traffic classes with different contention parameters. "Enhanced Distributed Channel Access (EDCA): EDCA was introduced in IEEE 802.11e to extend DCF and provide QoS differentiation across four Access Categorys (ACs)"
- Gaussian elimination with partial pivoting: A numerically stable linear algebra method to solve systems, used here for beamforming weights. "The (K +1) x (K +1) Gram system is solved via Gaussian elimination with partial pivoting."
- Initial Control Frame (ICF): A MAPC control frame initiating coordination for shared TXOPs. "To support MAPC features, Kom8ndor includes new states and signaling that involve multiple nodes, including Initial Control Frame (ICF)/Initial Control Response (ICR) exchange"
- Initial Control Response (ICR): The response control frame in the ICF/ICR handshake for MAPC coordination. "new control frames were defined (ICF, ICR, TF, MU-RTS)."
- It's Your Turn (IYT): A distributed, token-like channel access proposal that orders transmitters to improve determinism. "It's Your Turn (IYT) is a proposal from [23] that aims at improving determinism in channel access"
- Multi-Access Point Coordination (MAPC): A Wi‑Fi 8 feature where a coordinating AP shares its TXOP or enables simultaneous transmissions with other APs. "MAPC is a new feature in 802.11bn that allows a coordinat- ing AP (the AP that wins the channel access) to share its TXOPs with other coordinated APs"
- Multi-Armed Bandit (MAB): A sequential decision-making framework balancing exploration and exploitation over discrete actions. "a Multi-Armed Bandit (MAB) module is implemented to enable online decision-making"
- Multi-Link Operation (MLO): A Wi‑Fi 7 feature enabling devices to use multiple links simultaneously for throughput/latency gains. "with support for Multi-Link Operation (MLO), Multi-User (MU)-Resource Unit (RU) for Orthogonal Frequency-Division Multiple Access (OFDMA)"
- MU-RTS: A multi-user RTS control frame used to schedule coordinated transmissions across APs. "MU-RTS (used by Coordinated Time Division Multiple Access (Co-TDMA) to schedule time slots among coordinated APs)."
- Network Allocation Vector (NAV): A virtual carrier-sense timer indicating when the medium is reserved by others. "that can eventually activate the Network Allocation Vector (NAV) procedure and make them transition to NAV state"
- Non-Primary Channel Access (NPCA): A Wi‑Fi 8 feature allowing an AP to temporarily contend and transmit on a non-primary channel within its bandwidth. "Non-Primary Channel Access (NPCA) aims to overcome the contention aspects in an Overlapping Basic Ser- vice Set (OBSS) by allowing an AP to temporarily translate its operation to a different channel."
- OBSS/Packet Detect (OBSS/PD): A spatial reuse mechanism adjusting detection thresholds in overlapping BSSs to improve concurrency. "Overlapping Basic Service Set/Packet Detect (OBSS/PD)-based Spatial Reuse (SR) [16]"
- Overlapping Basic Service Set (OBSS): The condition when multiple BSSs operate on overlapping channels, causing contention/interference. "Non-Primary Channel Access (NPCA) aims to overcome the contention aspects in an Overlapping Basic Ser- vice Set (OBSS)"
- Orthogonal Frequency-Division Multiple Access (OFDMA): A multi-user PHY technique allocating orthogonal subcarriers (RUs) among users. "Multi-User (MU)-Resource Unit (RU) for Orthogonal Frequency-Division Multiple Access (OFDMA)"
- Portable Operating System Interface (POSIX) Unix-domain socket: A local IPC mechanism using file system–addressed sockets. "The communication between the simulator and the Python process uses a Portable Operating System Interface (POSIX) Unix-domain socket."
- Power Save Mode (PSM): Mechanisms allowing devices to save energy by sleeping and scheduling wake-ups. "enhanced Physical (PHY), and Power Save Mode (PSM) functionalities."
- Preamble Puncturing: A bonding technique that excludes busy 20 MHz subchannels during a TX to maximize usable bandwidth. "Kom8ndor adds preamble puncturing, which was introduced in IEEE 802.11ax."
- Repeat Backoff: A MAC variant that deterministically reuses the same backoff value regardless of success/collision pattern. "Repeat Backoff (uses the same backoff deterministically)"
- Request-to-Send (RTS): A control frame used to reserve the medium before data, mitigating hidden-node collisions. "Figure 1 shows two examples of implemented frame sequences to realize Distributed Coordination Function (DCF) with Request-to- Send (RTS)/CTS (Fig. 3a)"
- Resource Unit (RU): The smallest allocatable OFDMA subchannel resource assigned to a user. "Multi-User (MU)-Resource Unit (RU) for Orthogonal Frequency-Division Multiple Access (OFDMA)"
- Restricted Target Wake Time (R-TWT): A scheduling mechanism that reserves periodic service times to bound latency/energy. "such as Restricted Target Wake Time (R-TWT) [4]"
- Short Interframe Space (SIFS): A short guard interval between frames (e.g., data–ACK) giving priority to ongoing exchanges. "including control frames and Short Interframe Space (SIFS) intervals"
- Signal-to-Interference-plus-Noise Ratio (SINR): A link-quality metric comparing desired signal power to interference plus noise. "due to the Signal-to-Interference-plus-Noise Ratio (SINR) gains that result from coordinated nulling."
- Spatial Reuse (SR): Techniques enabling concurrent transmissions by managing interference thresholds/power. "Overlapping Basic Service Set/Packet Detect (OBSS/PD)-based Spatial Reuse (SR) [16]"
- Steering vector: The array response vector describing phase shifts across antenna elements for a given direction. "The array response to a signal at azimuth 0 (measured in the horizontal plane from the array axis) is described by the steering vector"
- Trigger Frame (TF): A control frame used to synchronize and trigger simultaneous transmissions by multiple devices/APs. "the transmission of a Trigger Frame (TF) (used by Co-SR and Co-BF to synchronize simultaneous data transmissions across multiple APs)"
- Transmission Opportunity (TXOP): A time interval during which a transmitter can send one or multiple frames without recontention. "joint scheduling and Transmission Opportunity (TXOP) allocation."
- Uniform Linear Array (ULA): A linear antenna array model used for beamforming/nulling with defined element spacing. "Each AP is modeled as a horizontal Uniform Linear Array (ULA) of N isotropic elements with inter-element spacing d (in wavelengths)."
- Ultra-High Reliability (UHR): A stringent reliability target in Wi‑Fi 8 aimed at mission‑critical applications. "The upcoming IEEE 802.11bn amendment marks a paradigm shift in Wi-Fi, which will pose ambitious performance targets under the paradigm of Ultra-High Reliability (UHR)."
- Zero Forcing (ZF) precoding: A beamforming technique that inverts the channel to create gain toward the target and nulls toward interfered nodes. "Kom8ndor's implementation of Co-BF is based on the Zero Forcing (ZF) precoding method"
- Synchronized Backoff: A baseline MAC variant assigning the same fixed backoff to all nodes to study deterministic access. "Synchronized Backoff (assigns every node the same fixed backoff, with no randomization and no adaptation)"
Collections
Sign up for free to add this paper to one or more collections.