Kom8ndor: IEEE 802.11bn Wi‑Fi 8 Simulator

• Kom8ndor is an open-source IEEE 802.11bn simulator that models Wi‑Fi 8 features with a focus on Multi-Access Point Coordination (MAPC) in dense WLANs.
• It provides a discrete-event simulation framework with modular MAC/PHY behavior, configurable traffic models, and ML integration for dynamic protocol evaluation.
• The simulator implements coordination schemes like Co-TDMA, Co-SR, and Co-BF, aiming to boost throughput, reduce latency, and lower MPDU loss by at least 25% compared to earlier standards.

Kom8ndor is an open-source IEEE 802.11bn-oriented simulator for Wi-Fi 8 research, introduced as a next-generation evolution of Komondor and positioned as a standards-aware framework for evaluating Multi-Access Point Coordination (MAPC) under the Ultra High Reliability (UHR) objectives of the emerging amendment. In the 802.11bn context, UHR is expected to increase throughput, reduce the 95th percentile of the latency distribution, and decrease MAC Protocol Data Unit (MPDU) loss, all by at least 25% relative to Extremely High Throughput operations defined in IEEE 802.11be. Kom8ndor is presented as the practical simulation vehicle for studying candidate coordination mechanisms before standardization is finalized, particularly in dense WLANs where AP cooperation is intended to improve reliability, latency, and spectrum efficiency (Wilhelmi et al., 11 Jun 2026, Wilhelmi et al., 24 Jun 2026).

1. Definition, scope, and lineage

Kom8ndor is described as “Kom8ndor: An IEEE 802.11bn Simulator” and, more broadly, as an IEEE 802.11bn-oriented discrete-event simulator for Wi-Fi 8 and beyond. It is released as open-source under GNU GPLv3 and made available through the Komondor repository at https://github.com/wn-upf/Komondor, while the tutorial paper also points to the development branch https://github.com/wn-upf/Komondor/tree/dev with a specific commit noted in the citation (Wilhelmi et al., 11 Jun 2026, Wilhelmi et al., 24 Jun 2026).

The simulator extends Komondor, which is identified as a predecessor developed for next-generation high-density WLANs and validated against ns-3 and analytical tools. Kom8ndor inherits that lineage but reorients the platform toward early 802.11bn features, including MAPC, Non-Primary Channel Access (NPCA), and Dynamic Subband Operation (DSO). The stated objective is not merely generic packet simulation; it is to provide a research framework for studying MAC-level coordination in dense WLANs, where multiple APs cooperate to improve latency, reliability, and efficiency (Wilhelmi et al., 24 Jun 2026).

The papers position Kom8ndor relative to ns-3, OMNeT++/INET, MATLAB WLAN Toolbox, and earlier standards-oriented scenario work such as TGax simulation scenarios. The comparison is not that those environments are unusable, but that they are generally slower to adapt to rapidly evolving standards and are less focused on quickly prototyping cutting-edge Wi-Fi mechanisms. Kom8ndor is therefore framed as a simplified but accurate abstraction of MAC and PHY behavior that prioritizes fast event processing, modular feature addition, and early-stage protocol exploration (Wilhelmi et al., 24 Jun 2026).

2. Standardization setting and research rationale

Kom8ndor is rooted in the standardization setting of IEEE 802.11bn, the Wi-Fi 8 amendment centered on UHR. In this setting, the emphasis shifts from peak throughput alone toward improved reliability, lower tail latency, smoother performance under dense deployment, and better operation for time-sensitive and real-time traffic. MAPC is presented as one of the main enablers of these goals because it allows APs to coordinate channel access and resource usage so as to reduce collisions and contention and to better serve dense deployments (Wilhelmi et al., 11 Jun 2026).

The rationale for creating Kom8ndor is explicitly methodological. The papers identify a need for a reproducible simulation environment, a way to compare candidate MAPC features, a tool to evaluate tradeoffs in throughput, latency, and reliability, and a bridge between standardization proposals and performance evidence. This is especially pertinent because many candidate Wi-Fi 8 mechanisms remain under discussion in IEEE 802.11bn working documents, while hardware prototyping of interacting multi-AP mechanisms is costly and analytical treatment is difficult (Wilhelmi et al., 11 Jun 2026).

Within that research program, Kom8ndor serves as the experimental engine for controlled evaluation. The tutorial associates it with candidate MAPC directions including Coordinated Spatial Reuse (CSR), coordinated TDMA or Co-TDMA-style scheduling, coordinated OFDMA, multi-link or multi-AP coordination, joint transmission and coordinated access strategies, restricted Target Wake Time interactions with coordination, and coordinated NPCA. The simulator’s role is thus to translate standards proposals into repeatable experiments that can quantify throughput, 95th-percentile latency, MPDU loss, and related tail-delay and reliability behavior (Wilhelmi et al., 11 Jun 2026).

3. Architecture, configuration, and execution model

Kom8ndor is implemented as a C/C++ event-driven network simulator built on top of the COST component-oriented simulation library. Its architecture is organized around COST components instantiated by a main simulation engine. The principal components are komondor_main, which inherits a CostSimEng singleton; node, which models AP or STA behavior including traffic, MAC, and PHY; traffic_generator, which creates offered traffic using configurable traffic models; agent, which runs in-simulation ML logic; and central_controller, which coordinates multiple agents for centralized AI decisions. Components are created and connected through inport and outport methods (Wilhelmi et al., 24 Jun 2026).

Configuration is input-driven. The simulator uses input_nodes for node capabilities such as position, channel, and transmit power; config_models for environment models such as path loss and interference; agents as an optional ML configuration file; and mapc as an optional file specifying MAPC groups and scheme-specific parameters. Outputs include simulation summaries, per-BSS metrics, per-node statistics, collision counts, and logs for nodes, agents, and the central controller. The paper also describes a system flow diagram in which these modular input files feed komondor_main, which instantiates the simulation core and produces logs as output (Wilhelmi et al., 24 Jun 2026).

A central design element is a flexible finite state machine for discrete-event MAC/PHY behavior. The FSM includes states such as SENSING, TRANSMIT FRAME, WAIT REPLY, RECEIVE FRAME, and NAV. When a traffic generator pushes a payload to a node, the node transitions through frame preparation, medium sensing, and transmission scheduling at microsecond granularity; backoff, channel access, NAV updates, and reply handling are modeled as explicit state transitions. The papers emphasize that this FSM is extensible and can represent both conventional frame exchanges and more complex multi-node coordination sequences. For MAPC, new states and signals such as TRANSMIT ICF, WAIT ICR, and WAIT MU-RTS are added to support synchronized multi-AP operation (Wilhelmi et al., 24 Jun 2026).

4. MAPC framework and implemented coordination schemes

MAPC is one of the defining 802.11bn features implemented in Kom8ndor. It enables the AP that wins channel access to share its transmission opportunity with other APs and, in some modes, to coordinate simultaneous transmissions. The papers identify Co-TDMA, Co-SR, and Co-BF as the main implemented MAPC subfeatures, while also noting Co-RTWT and Co-CR in the broader 802.11bn MAPC landscape. Kom8ndor’s MAPC framework is designed to go beyond the baseline standard, including scalability beyond the standard’s limit of two APs in MAPC agreements, through a mapc.csv file that defines coordination groups, scheme type, and scheme-specific parameters (Wilhelmi et al., 24 Jun 2026).

MAPC coordination relies on new control frames: Initial Control Frame (ICF), Initial Control Response (ICR), Trigger Frame (TF), and Multi-User RTS (MU-RTS). These are used to establish coordinated TXOP sharing or synchronous simultaneous transmission. In the Co-TDMA scheme, multiple AP transmissions are scheduled within the same TXOP using orthogonal time slots. After the ICF–ICR exchange, a fair TXOP split is decided among participating APs, with equal sharing across APs as the default policy. The duration assigned to AP $n$ is bounded by the time required by that AP’s buffer status and transmission parameters, the maximum TXOP duration $TXOP_{max}$, the Co-TDMA overhead, and the set of participating APs $N$; the paper gives $TXOP_{max}$ as $5484\ \mu s$. It also notes that QoS-based scheduling or delay minimization could be added later (Wilhelmi et al., 24 Jun 2026).

Co-SR enables simultaneous transmissions with limited transmit power so that APs can spatially reuse the channel. In Kom8ndor, the coordinating AP uses its predefined transmit power from input_nodes, whereas the coordinated AP uses a power value specified in the mapc file. The paper notes that more advanced power assignment strategies could later be added, such as transmit-power selection based on interference constraints at receivers (Wilhelmi et al., 24 Jun 2026).

Co-BF enables simultaneous transmissions using beamforming and nulling to suppress inter-BSS interference. Kom8ndor implements Co-BF using Zero Forcing precoding, modeling each AP as a horizontal Uniform Linear Array of $N$ isotropic elements with inter-element spacing $d$ wavelengths. The array response for azimuth $\theta$ is

$$a(\theta) = \left[1,\ e^{j2\pi d \sin(\theta)},\ \ldots,\ e^{j2\pi d (N-1)\sin(\theta)}\right]^T \in \mathbb{C}^N.$$

If $\theta_{main}$ denotes the azimuth from the transmitting AP to its own STA and $TXOP_{max}$0 the azimuths toward peer-BSS STAs where nulls are required, the steering vectors are collected into

$TXOP_{max}$1

and the Zero Forcing weight vector is

$TXOP_{max}$2

where $TXOP_{max}$3 is the first standard basis vector. By construction, $TXOP_{max}$4, yielding unity gain toward the desired STA and exact nulls in all $TXOP_{max}$5 null directions. The $TXOP_{max}$6 Gram system is solved using Gaussian elimination with partial pivoting, and the received power is scaled by beam gain as

$TXOP_{max}$7

An important implementation restriction is that beamforming gains are applied only to data frames; control frames such as ICF/ICR, TF, RTS/CTS, and ACK are transmitted omnidirectionally (Wilhelmi et al., 24 Jun 2026).

The tutorial also situates Kom8ndor within a wider MAPC agenda that includes coordinated OFDMA, multi-link or multi-AP coordination, and joint transmission or seamless roaming. A plausible implication is that the simulator’s implemented MAPC core is intended as a basis for future extensions across the broader 802.11bn coordination space, rather than as an exhaustive realization of all candidate mechanisms already under discussion (Wilhelmi et al., 11 Jun 2026).

5. Spectrum-access extensions and comparative MAC functionality

Beyond MAPC, Kom8ndor implements DSO, NPCA, and preamble puncturing. DSO addresses inefficiency arising when APs support wide channels but STAs support narrower channels. The paper gives the illustrative case of an AP with 160 MHz serving four 40 MHz STAs: without DSO, only one 40 MHz portion might be used per TXOP, whereas with DSO multiple narrowband STAs can be scheduled in the same TXOP on different subbands. In Kom8ndor, DSO is implemented by performing the mandatory ICF/ICR exchange and then scheduling STAs onto assigned bandwidth portions using a round-robin policy based on declared min_ch/max_ch requirements in input_nodes (Wilhelmi et al., 24 Jun 2026).

NPCA allows an AP to move away temporarily from the primary channel and contend on a different channel within the BSS bandwidth, which is intended to help with OBSS contention. Kom8ndor models NPCA through a specific sequence: the node detects an inter-BSS transmission, switches to a pre-configured NPCA primary channel, runs a new backoff there as if that channel were primary, transmits if access is granted, and then returns to its original primary channel at the end of the TXOP. The NPCA primary channel is flexible but defaults to the upper portion of the BSS bandwidth; a configurable radio switching delay may be added; an ICF/ICR exchange is required before any NPCA transmission on the NPCA primary channel; and an NPCA trigger defines when the node returns to its original primary channel (Wilhelmi et al., 24 Jun 2026).

Preamble puncturing is inherited from the DCB baseline and introduced in IEEE 802.11ax. In Kom8ndor, the TXOP remains anchored to the primary subband, busy secondary 20 MHz channels are excluded from the bonded set, and this is represented by a puncturing bitmap (Wilhelmi et al., 24 Jun 2026).

The simulator also supports multiple comparative channel-access methods beyond legacy DCF. These include DCF with CSMA/CA and binary exponential backoff, EDCA with AIFS, CWmin, CWmax, and TXOP limits per node and access category, deterministic backoff, It’s Your Turn, ECA, Repeat Backoff, and Synchronized Backoff. Deterministic backoff is defined as

$TXOP_{max}$8

where $TXOP_{max}$9 is a configurable base value and $N$0 is the number of interruptions caused by neighboring transmissions in the previous countdown. These methods function both as research baselines and as instruments for studying the limits of channel-access strategies (Wilhelmi et al., 24 Jun 2026).

6. AI integration, evaluation role, and present limits

A major extension beyond the original Komondor is stronger support for machine learning and AI-native protocols. Kom8ndor supports built-in learning algorithms, decentralized learning, coordinated learning, and centralized orchestration. Its built-in ML machinery includes a Multi-Armed Bandit module in which an agent tracks empirical rewards for each arm and chooses actions using strategies such as $N$1-greedy. The design goal is to abstract algorithmic differences between RL paradigms away from the rest of the simulator so that new methods can be integrated with limited disruption to the networking core (Wilhelmi et al., 24 Jun 2026).

For richer external models, Kom8ndor introduces a Python wrapper based on a POSIX Unix-domain socket. The communication protocol is specified explicitly: Kom8ndor sends a 32-bit integer header indicating the number of features, then a vector of 32-bit floats containing feature values, and the Python server returns a vector of 32-bit floats encoding the model output, such as the next action. The default socket path is /tmp/komondor_ml.sock, and the paper lists example scripts ml_server_random.py, ml_server_passthrough.py, and ml_server_pytorch.py (Wilhelmi et al., 24 Jun 2026).

The simulator’s evaluation role is central to both papers. The tutorial identifies a standard workflow: define a MAPC candidate feature from IEEE 802.11bn discussion material, configure a multi-AP topology and traffic scenario, simulate coordinated AP behavior in Kom8ndor, measure throughput, latency, and MPDU loss, and compare against uncoordinated or alternative coordination baselines. This workflow is especially useful for examining coordination gains versus control overhead, latency reduction versus throughput tradeoffs, and reliability improvements under dense deployment conditions (Wilhelmi et al., 11 Jun 2026).

At the same time, the current release is explicitly bounded. The Kom8ndor paper does not present a formal validation study against ns-3 or analytical models for the new Wi-Fi 8 features; instead, it relies on the earlier validation of Komondor and positions Kom8ndor as a pragmatic balance between fidelity and speed. Its showcase results are qualitative rather than universal: Co-TDMA may perform slightly worse than DCF in a small scenario because coordination overhead can outweigh benefits; Co-SR improves throughput when spatial reuse is favorable; Co-BF yields the largest improvement due to SINR gains from beam nulling; and DSO and NPCA increase throughput by enabling more flexible access to subbands and unused spectrum. Future work is stated to include MLO, OFDMA, R-TWT, interactions between those features and Wi-Fi 8 mechanisms, dynamic transmit-power computation for Co-SR, QoS-based Co-TDMA scheduling, and smart MAPC scheme selection. The project is described as a live platform and the basis for ongoing Wi-Fi 8 and beyond research at UPF (Wilhelmi et al., 24 Jun 2026).