Kom8ndor: An IEEE 802.11bn-Oriented Simulator for Wi-Fi 8 and Beyond Francesc Wilhelmiπ , Sergio Barrachina-Muñoz⋆ , Boris Bellaltaπ π
arXiv:2606.25435v1 [cs.NI] 24 Jun 2026
⋆
Universitat Pompeu Fabra, Spain Centre Tecnològic de Telecomunicacions de Catalunya, Spain
between implementation speed and simulation fidelity that more comprehensive frameworks like ns-3 are less suited to provide for rapidly evolving standards. Moreover, Kom8ndor extends the Machine Learning (ML) modules from Komondor by introducing a Python wrapper, which is key to accelerating the experimentation of AI-native solutions for future Wi-Fi. The remainder of the paper is structured as follows: Section II depicts other Wi-Fi simulators. Section III outlines the architecture and design principles of Kom8ndor and Section IV, its new functionalities. Section V serves as a guide by providing how-to simulation examples, together with a performance showcase. Section VI concludes the paper.
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 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 (CoSR), and Coordinated Beamforming (Co-BF)—, Non-Primary Channel Access (NPCA), and Dynamic Subband Operation (DSO). Beyond Wi-Fi 8 implementations, 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. Kom8ndor is open-source (GNU GPLv3) and available at https://github.com/wn-upf/Komondor. Index Terms—IEEE 802.11bn, Wi-Fi 8, Network simulator, Ultra-High Reliability
II. R ELATED W ORK : W I -F I S IMULATION T OOLS
Developing and testing novel features in Wi-Fi is a longterm effort that involves conceptualization, prototyping, and evaluation. In this process, open-source simulation tools play a critical role, as they allow prototyping new mechanisms and ideas, quantifying trade-offs, and testing corner cases before I. I NTRODUCTION moving to silicon implementations. ns-3 [3] remains the most popular open-source network With the upcoming IEEE 802.11bn-2028 (Wi-Fi 8), Wireless Local Area Networks (WLANs) are set to go beyond supporting simulator in Wi-Fi research and education. ns-3 is a fullmere Internet access, and step toward communications-critical stack discrete-event simulator written in C++ that models Wiapplications such as industrial automation [1]. To meet Ultra Fi protocols (it also includes modules for 5G and satellite High Reliability (UHR) goals, 802.11bn will introduce new networks) with high fidelity. At the time of writing this functionalities, such as Non-Primary Channel Access (NPCA), paper, ns-3’s latest release (ns-3.48, released June 2, 2026) Dynamic Subband Operation (DSO), or Multi-Access Point includes a mature set of Wi-Fi 7 functionalities, with support for Multi-Link Operation (MLO), Multi-User (MU)-Resource Coordination (MAPC). Given the unprecedented enhancements and architectural Unit (RU) for Orthogonal Frequency-Division Multiple Access changes that 802.11bn proposes over 802.11, the need for open- (OFDMA), enhanced Physical (PHY), and Power Save Mode source simulation tools becomes critical. Such tools enable a (PSM) functionalities. In parallel, the research community is thorough evaluation of both standard functionalities and novel contributing to the implementation of other Wi-Fi features, extensions (e.g., beyond 802.11bn MAPC) in various scenarios such as Restricted Target Wake Time (R-TWT) [4], as well as and use cases. For this reason, we introduce Kom8ndor,a integrations with Artificial Intelligence (AI) tools [5], [6]. In addition to ns-3, OMNeT++/INET [7] and MATLAB’s C/C++ 802.11bn-oriented event-driven network simulator that substantially extends the original Komondor simulator [2] WLAN Toolbox [8] offer solid simulation tools. On the one (originally meant for Wi-Fi 6 simulations) to introduce Wi-Fi hand, OMNeT++/INET supports primitive WLAN functionali8 and beyond features. Komondor serves as a well-suited ties, which have been leveraged by the research community to simulation platform for Wi-Fi research, offering a balance provide open-source implementations of novel Wi-Fi features such as MLO [9]. Regarding MATLAB’s WLAN Toolbox, This work was supported by the following projects: TRUE Wi-Fi PID2024- its main strength is the simulation of link-level and PHY 155470NB-I00 (MICIU/AEI/10,13039/501100011033/FEDER,UE), MLDR operations, as it provides high-fidelity tools for waveform (Chist-ERA WAI 2022) PCI2023-145958-2 (MCIU/AEI/10.13039), ICREA Academia 2024 (00077 AGAUR), and MdM CEX2021-001195-M (MICI- generation and signal processing. Furthermore, it has recently U/AEI/10.13039/501100011033). added a system-level simulator, which supports up to 802.11be
1
TABLE I: High-level comparison of Wi-Fi simulation tools. Opensource
Main strength
Wi-Fi 8
Future Wi-Fi
ns-3
✓
Full-stack, wide adoption.
✗
✗
MATLAB’s WLAN Toolbox
✗
High-fidelity PHY modeling.
✓a
✗
OMNeT++/ INET
✓
High modularity, realistic emulation.
✗
✗
Fast event processing, rapid prototyping, AI/ML integration.
✓b
Tool
III. A RCHITECTURE AND D ESIGN Komondor was initially designed for cost-effective simulation of high-density Wi-Fi 6 scenarios, featuring novel features at that time, such as Overlapping Basic Service Set/Packet Detect (OBSS/PD)-based Spatial Reuse (SR) [16] or Dynamic Channel Bonding (DCB) [17]. Kom8ndor extends the original architecture to introduce Wi-Fi 8 and beyond features, higher modularity for forward extensions and integration of third-party ML tools, higher efficiency, and better usability.
A. Main simulation components Kom8ndor uses the C/C++ COST library [18], which allows a Includes Wi-Fi 8 PHY models (e.g., new MCSs), b Built explicitly to the creation of COST components and handles discrete-event evaluate MAPC and other Wi-Fi 8 features. interactions among them. The main file (komondor_main) inherits a CostSimEng singleton (a special type of component defined by COST) that is in charge of instantiating all the functionalities. Unlike ns-3 and OMNeT++/INET, MATLAB’s simulation components, creating the connections between them WLAN Toolbox is a proprietary commercial software product. via inport and outport methods, and running the simulation. COST components of TypeII are used to represent different While providing a solid implementation of Wi-Fi protocols, types of entities in a Wi-Fi network, including: tools like ns-3, OMNeT++, and MATLAB’s WLAN Toolbox • node: Characterizes the logic of either AP or Station follow a slow but necessary development pace. Considering the (STA) devices, including traffic management, MAC, and rapid research cycles, this represents a disadvantage, as novel PHY operations. features (e.g., Wi-Fi 8) cannot be easily prototyped. Based on • traffic_generator: Generates traffic based on a this, early Wi-Fi research efforts rely on their own simulation selected traffic model (e.g., Poisson traffic, burst traffic, tools [10]–[13], which are typically very narrow in scope (e.g., full-buffer). Every transmitting node is connected to a to focus on a single feature) and not open-sourced. dedicated traffic generator. In terms of Wi-Fi 8 (802.11bn), very few works have • agent: Provides in-simulation ML operations to optimize already provided simulation results due to the early status the performance of the network online. Agents are of the technology, which is currently at Draft 1.4 (D1.4). One connected to APs to exchange information and commands. example is [14], which introduced a multi-Access Point (AP) • central_controller: Orchestrates enrolled agents framework to show results on joint scheduling and Transmission (e.g., centralized decision-making), thus unlocking cenOpportunity (TXOP) allocation. Despite having been opentralized ML and non-ML solutions and algorithms. sourced, the tool from [14] is not 802.11bn-compliant (it The different components are flexibly instantiated based on follows the authors’ proposal for MAPC) and is tightly coupled a set of input files, comprising: to the scheduling mechanisms studied by the authors. Another • input_nodes: defines per-node capabilities (e.g., posiexample is the work in [15], where integrated mmWave (which tion, channel, transmission power). runs in parallel with 802.11bn) is studied and evaluated through • config_models: defines environment models (e.g., simulation results. However, the simulator is not open-sourced. path loss, co-channel interference model) applied to the To the best of our knowledge, no publicly available Wi-Fi simulated scenario. simulator currently provides Wi-Fi 8 and beyond functionali• agents (optional): defines ML-related implementations, ties and offers an extensible framework for experimentation. ranging from Reinforcement Learning (RL)-based dyKom8ndor builds upon Komondor [2], a validated tool that namic parameter configuration to custom models interactcovers novel features of Wi-Fi 6 at its time [16], [17], and ing with Kom8ndor through a Python server. introduces a new MAPC framework alongside other Wi• mapc (optional): defines coordination groups, MAPC Fi 8 and beyond functionalities such as DSO, NPCA, new schemes, and configurations to be used by the instantiated channel access methods and integration of ML functionalities. Wi-Fi nodes. Furthermore, Kom8ndor processes events at a very high rate, Kom8ndor outputs include simulation summaries (e.g., allowing for simulating large deployments quickly. Unlike per-Basic Service Set (BSS) performance, per-node statistics, traditional simulators (e.g., ns-3, MATLAB’s WLAN toolbox), collision counts), and detailed logs for nodes, agents, and the Kom8ndor provides a simplified (yet accurate) abstraction of central controller. Later, Section V provides specific examples Medium Access Control (MAC) and PHY layers, serving as a of inputs and outputs. The overall system is illustrated in Fig. 1. prominent alternative tool for the research and prototyping of B. Finite State Machine early Wi-Fi functionalities. Table I provides a high-level positioning of Kom8ndor Kom8ndor simulations are based on discrete events, folamong state-of-the-art Wi-Fi simulation tools. lowing a flexible Finite State Machine (FSM), where node Kom8ndor
✓
✓
2
Main modules Input
input_nodes
Optional modules
config_models
agents
Channel won (exhausted backoff)
komondor_main
No
agent 2 node 1 traffic generator
Output
node 2 traffic generator
System logs
...
node N traffic generator
Nodes logs
...
SENSING (IDLE)
central controller (CC)
agent M
Agent logs
Yes
NAV timeout
node.h
agent.h
traffic_generator.h
central_controller.h
No RECEIVE FRAME
Frame is for another node NAV
de)
WAIT REPLY
Timeout?
Transmission detected CC logs
Yes
no (restart
agent 1
Sim. core
Reply needed?
TRANSMIT FRAME
mapc
Yes
(resta rt
node)
Frame is for me
TXOP finished?
No
Set/Update NAV?
Fig. 1: Kom8ndor’s main components and simulation flow.
Fig. 2: Kom8ndor’s generic FSM.
states represent frame transmissions (e.g., TRANSMIT DATA), frame receptions (e.g., RECEIVE DATA), and other operations (e.g., WAIT DATA, NAV), and transitions between states follow operations such as channel contention, backoff counters, or inter-frame spacing. Figure 2 depicts the generic FSM, showing the basic behavior that nodes follow upon transmitting or receiving frames. In particular, when a traffic_generator pushes a payload to a node, the FSM transitions through frame preparation, medium sensing, and frame transmission, scheduling events for the exact microsecond each action is expected to be performed. Accordingly, if a node has a frame to transmit, it undergoes a backoff procedure, which can run as long as the medium is sensed as idle (the node is in SENSING state). Upon channel access, the node transitions to the TRANSMIT FRAME state, which triggers transmission detected events in other nodes that can eventually activate the Network Allocation Vector (NAV) procedure and make them transition to NAV state (depending on the spatial configuration of the scenario and the selected transmission parameters). Depending on the need for a reply or not (e.g., acknowledgment (ACK), Clear-to-Send (CTS)), the transmitting node transitions through WAIT REPLY and then RECEIVE FRAME, or goes back to SENSING upon finishing the transmission, respectively. This FSM design provides the necessary flexibility to realize various transmission modes, ranging from simple data and ACK exchanges to more complex MAPC frame sequences. This flexibility allows for seamless extensibility, so new transmission approaches and protocols can be easily developed. Figure 3 shows two examples of implemented frame sequences to realize Distributed Coordination Function (DCF) with Request-toSend (RTS)/CTS (Fig. 3a) and Coordinated Spatial Reuse (CoSR)/Coordinated Beamforming (Co-BF) (Fig. 3b), respectively. To support MAPC features, Kom8ndor includes new states and signaling that involve multiple nodes, including Initial Control Frame (ICF)/Initial Control Response (ICR) exchange
(to agree on a coordinated transmission), the transmission of a Trigger Frame (TF) (used by Co-SR and Co-BF to synchronize simultaneous data transmissions across multiple APs), or MURTS (used by Coordinated Time Division Multiple Access (Co-TDMA) to schedule time slots among coordinated APs). Depending on the selected MAPC scheme, the FSM is adapted accordingly, and new transient states are introduced to manage the chronological flow of the coordination protocols. For a detailed overview of the MAPC schemes, we refer the reader to the tutorial in [19]. IV. N EW F EATURES : F ROM 802.11 BN TO AI/ML A. Multi Access Point Coordination MAPC is a new feature in 802.11bn that allows a coordinating AP (the AP that wins the channel access) to share its TXOPs with other coordinated APs and, in some cases, perform simultaneous transmissions (see Fig. 4). Current MAPC schemes comprise Co-TDMA (schedules multiple transmissions within the same TXOP), Co-SR (enables simultaneous transmissions with limited transmit power), Co-BF (enables simultaneous transmissions using beamforming and nulling), Coordinated R-TWT (Co-RTWT) (coordinates R-TWT schedules), and Coordinated Channel Recommendation (Co-CR) (coordinates the channels used for device-to-device transmissions). Kom8ndor introduces a MAPC framework that builds upon the baseline established by 802.11bn while enabling extensions to anticipate beyond Wi-Fi 8 capabilities. For instance, while 802.11bn restricts MAPC agreements to a maximum of two APs, Kom8ndor facilitates the efficient evaluation of scalability beyond this limit. In terms of MAPC schemes, Kom8ndor includes those that operate on a perTXOP basis, i.e., Co-TDMA, Co-SR, and Co-BF. But once again, Kom8ndor’s MAPC framework allows the definition of new coordination schemes (e.g., leveraging coordination to share rewards in ML [20]).
3
AP
STA STAA
Channel access: DIFS + BO
RTS
APA
SIFS
CTS SIFS
BSSA
Channel access: DIFS + BO
TF (broadcast)
DATA (A-MPDU)
ICF ICR
ACK
(a) IEEE_802_11_RTS_CTS
BSSB
STAB
SIFS
TF
DATA (A-MPDU)
SIFS
ACK
SIFS
APB
DATA (A-MPDU) SIFS
ACK
SIFS
(b) IEEE_802_11_COBF_COSR
Fig. 3: Two examples of frame exchange sequences. (a) DCF with RTS/CTS, (b) Co-SR/Co-BF.
Co-TDMA TXOPmax − Toverhead , Tn = min Tnreq , |N |
STA 2
(1)
where Tnreq is the maximum time required by AP n (depending on its buffer status and transmission parameters), TXOPmax is the maximum TXOP duration (5484 µs), and AP 1 Co-TDMA AP 2 Toverhead denotes the duration of overheads in Co-TDMA (including control frames and Short Interframe Space (SIFS) Coordination agreement intervals). While not currently included, other policies, such as PPDU Quality of Service (QoS)-based scheduling or maximum-delay TX minimization, can be implemented. Null 2) Co-SR Operation: In Co-SR, coordinated APs agree on the transmit power to be used during a simultaneous STA 1 Aggregate MAC Protocol Data Unit (A-MPDU) downlink transmission. In the default implementation, the power to be Fig. 4: Scenario where two coordinated APs leverage Co-BF used by the coordinated AP is indicated by the user (indicated to perform simultaneous transmissions. in the mapc input file), while the coordinating AP employs its predefined transmit power (indicated in the nodes input file). However, other solutions can be implemented on top, including As described in Section III, Kom8ndor initializes the simula- a smart power assignment based on the maximum allowable tion environment using input files. For MAPC, agreements and interference at each communication end. parameters are informed in a newly introduced configuration 3) Co-BF Operation: In Co-BF, two APs transmit simultanefile (e.g., mapc.csv). This file is used to pre-establish the ously thanks to coordinated inter-BSS interference suppression, logical coordination groups and per-scheme parameters, which where each AP steers a beam toward its own associated STA depend on the scheme itself (e.g., the time-split approach in and places nulls in the directions of the recipient STAs of the Co-TDMA). During the simulation, Kom8ndor realizes the other BSS. Kom8ndor’s implementation of Co-BF is based on new handshakes needed to coordinate shared TXOPs, for which the Zero Forcing (ZF) precoding method, which simultaneously new control frames were defined (ICF, ICR, TF, MU-RTS). enforces unity gain toward the desired STA and exact nulls at Accordingly, the FSM is updated to support new states such all peer STAs. Each AP is modeled as a horizontal Uniform as TRANSMIT ICF, WAIT ICR, or WAIT MU-RTS. These Linear Array (ULA) of N isotropic elements with inter-element states ensure that participating nodes remain synchronized and spacing d (in wavelengths).1 The array response to a signal that non-participating STAs correctly update their NAV to defer at azimuth θ (measured in the horizontal plane from the array access until the end of the coordinated TXOP. axis) is described by the steering vector In what follows, we describe the specific details of each h iT 802.11bn MAPC scheme implemented in Kom8ndor. a(θ) = 1, ej2πd sin(θ) , . . . , ej2πd(N −1) sin(θ) ∈ CN . (2) 1) Co-TDMA Operation: The coordinating AP splits the Let θmain denote the azimuth from the transmitting AP TXOP into orthogonal time slots, assigned to different particito its own STA, and let θ1 , . . . , θK denote the azimuths pating APs. After the ICF-ICR exchange, a fair TXOP split is toward the K STAs of the peer BSS in which nulls must decided among coordinated APs, followed by the sequential be placed. Collecting all steering vectors into the constraint data transmissions. By default, Kom8ndor splits the resources equally among coordinated APs. In particular, the per-AP data 1 The ULA parameters (N , d, and nominal azimuth) are optionally informed duration Tn for each participating AP n ∈ N is capped equally: in the input_nodes file. Null
PPDU TX
4
matrix H = [a(θmain ), a(θ1 ), . . . , a(θK )] ∈ CN ×(K+1) , the ZF weight vector w is given by −1 w = H HH H e1 , (3)
must be preceded by an ICF/ICR exchange. Regardless of whether a transmission is performed or not on the NPCA primary channel, an NPCA trigger determines the time at which the node returns to its primary channel. The NPCA where e1 ∈ RK+1 is the first standard basis vector. By primary channel can be flexibly defined in Kom8ndor, but it construction, HH w = e1 , which simultaneously enforces unity defaults to the upper portion of the BSS bandwidth. 3) Preamble Puncturing: Based on the DCB implementation gain toward θmain and exact nulls at all K null directions. in Komondor, Kom8ndor adds preamble puncturing, which The (K + 1) × (K + 1) Gram system is solved via Gaussian omni was introduced in IEEE 802.11ax. In preamble puncturing, the elimination with partial pivoting. The received power Prx TXOP remains anchored to the primary subband, but spectrum under the default omnidirectional model is then scaled by the is aggregated more flexibly. In particular, any individual busy beam gain G(θ), where θ is the azimuth of the receiving node secondary 20 MHz channels are excluded from the set of as seen from the transmitter: channels bonded for a data transmission (achieved by marking Prx (θ) = Prxomni · G(θ) = Prxomni · |wH a(θ)|2 . (4) the busy basic channels in a puncturing bitmap), making the Beamforming gains are applied to data frames only, whereas most of the available bandwidth. all control frames (ICF/ICR, TF, RTS/CTS, ACK) are transC. Advanced Channel Access Methods mitted under the omnidirectional model. Channel access has traditionally been an object of discussion B. Flexible Spectrum Access: NPCA, DSO, and More in Wi-Fi. The standard DCF relies on Carrier Sense Multiple Following 802.11bn plans, Kom8ndor includes two new Wi- Access with Collision Avoidance (CSMA/CA) with Binary Fi 8 features for accessing the spectrum more flexibly: NPCA Exponential Backoff (BEB), whereby nodes initiate transmisand DSO. In addition, some enhancements were provided sions upon successfully decrementing a random backoff while on the Dynamic Channel Bonding (DCB) baseline from the channel is idle. Despite its simplicity and long adoption, DCF inefficiencies are well known, leading to unreliability and Komondor [17]. 1) Dynamic Subband Operation (DSO): DSO tries to fill the performance issues, especially when the number of coexisting increasing capability gap between AP and STA devices, where nodes increases. Apart from the baseline DCF, Kom8ndor APs might use wide channels (e.g., 160 MHz or 320 MHz), supports the alternative channel access methods described next. 1) Enhanced Distributed Channel Access (EDCA): EDCA while STAs might have more moderate capabilities (e.g., 20 MHz or 40 MHz). With DSO, narrow-band STAs can was introduced in IEEE 802.11e to extend DCF and provide be allocated to secondary subchannels during the same TXOP QoS differentiation across four Access Categorys (ACs), in a wide-band transmission, hence increasing efficiency. For namely Voice (VO), Video (VI), Best Effort (BE), and Backexample, without DSO, a 160 MHz AP serving four 40 MHz ground (BK) [21]. Today, it is the baseline channel access STAs would use only 40 MHz per TXOP, wasting 120 MHz mechanism. Kom8ndor supports EDCA and allows a flexible each time. With DSO, in contrast, the four STAs could be instantiation of its parameters—Arbitration Interframe Space scheduled in a single TXOP. Kom8ndor introduces DSO by (AIFS), maximum and minimum Contention Window (CW), simulating the mandatory ICF/ICR exchange before the data and TXOP limit—per node and AC. 2) Deterministic Backoff: To address large contention delays transmission begins. After that, all the scheduled STAs transmit on their assigned portion of the bandwidth. Currently, the set and lack of determinism, a deterministic backoff proposal was of scheduled STAs in a DSO transmission is decided using introduced in [22]. Through this mechanism, the backoff is round-robin, allocating in order the selected STAs based on fixed as BO = b+IPT, where b is a configurable base value and their declared bandwidth (specified as min_ch/max_ch in IPT is the number of backoff interruptions (due to neighboring transmissions) suffered during the previous countdown. The the input_nodes file). 2) Non-Primary Channel Access (NPCA): NPCA aims to deterministic backoff provides a consistent channel access delay overcome the contention aspects in an Overlapping Basic Ser- when transmissions are successful. In the event of collisions, vice Set (OBSS) by allowing an AP to temporarily translate its the mechanism reverts to random backoff selection. 3) It’s Your Turn (IYT): IYT is a proposal from [23] that operation to a different channel. When an NPCA node detects an inter-BSS transmission, it switches to a pre-configured aims at improving determinism in channel access (in line with NPCA primary channel that is within the total BSS bandwidth. deterministic backoff) while preserving the randomized nature There, the node can run a new backoff (as if it was the of it. In particular, IYT is based on a distributed round-robin primary) and eventually initiate a transmission. At the end channel access, which is achieved by maintaining a distributed of the TXOP, the node must return to the primary channel. list of a transmission order. Following this list, nodes maintain Kom8ndor implements NPCA by capturing its sequence of a logical token, which is passed to the next node in the list after events. First, the detection of an OBSS transmission triggers the each successful transmission (it is now its turn to transmit). NPCA channel switching (a fixed configurable radio switching 4) Other methods: Apart from the mechanisms mentioned delay can be added), where a new backoff is run. Then, a above, Kom8ndor includes other methods such as Enhanced transmission can occur on the NPCA primary channel, which Collision Avoidance (ECA) [24] (reuses the same backoff
5
TABLE II: Kom8ndor simulation flags.
value after every successful transmission), Repeat Backoff (uses the same backoff deterministically), or Synchronized Backoff (assigns every node the same fixed backoff, with no randomization and no adaptation). The introduction of new approaches and heuristic baselines is useful as an analytical reference and to study the limits of channel access in controlled experiments.
Flag
Arg
Description
Sim. params.
--nodes (-n) --time (-t) --seed (-s) --code (-c) --out (-o)
file float int str file
Path to nodes file Simulation duration in seconds Random seed Simulation code/ID Path to output file
Advanced
--mapc (-m) --agents (-a)
file file
Path to MAPC file Path to agents file
Logging
--logs-sys (-L) --logs-node (-l) --save-node (-S) --save-agent (-A)
0/1 0/1 0/1 0/1
Print system events to terminal Print per-node events to terminal Write per-node logs to file Write per-agent logs to file
D. Machine Learning Tools Since its first release in 2018, Komondor has included AI modules for studying next-generation WLANs. Specifically, agent and central_controller components were introduced to realize RL algorithms to dynamically optimize operations such as channel allocation, SR, or DCB. Now, Kom8ndor has improved this design and has added, on top, a seamless integration with Python, which is key to leveraging third-party ML packages such as PyTorch [25]. 1) Built-in Learning Algorithms: Kom8ndor includes builtin learning functions that allow the dynamic configuration of Wi-Fi PHY and MAC parameters during the simulation time. In particular, a single dispatch point handles all the agent decisions. Currently, a Multi-Armed Bandit (MAB) module is implemented to enable online decision-making, in which the agent maintains empirical reward estimates for each arm (e.g., a channel configuration) and selects among them via a configurable exploration strategy (e.g., ε-greedy). Other implementations are easily pluggable, since algorithmic differences between RL paradigms (e.g., model-based vs modelfree) are hidden from the rest of the simulator. With this architecture, Kom8ndor supports decentralized, coordinated, and centralized learning paradigms, which can be flexibly instantiated: • Decentralized learning: Agents are directly attached to a BSS, from which they continuously gather telemetry data (e.g., achieved throughput, collision rates, average delay, and observed interference). Individual decision-making is made based on local information only [26], [27]. • Coordinated learning: Multiple agents exchange information (e.g., rewards) to perform decision-making cooperatively [20]. • Centralized orchestration: Agents connect to a central controller, which gathers global state information and performs centralized decision-making, allowing the simulator to characterize cloud-based AI orchestrators. 2) External Python Integration: To run complex ML paradigms such as Deep Neural Networks (DNNs) and leverage existing libraries such as PyTorch, TensorFlow, or scikitlearn, Kom8ndor introduces a new agent mode that offloads decisions to an external Python process. With this, agents can send a feature vector at each step or iteration to inform about the played action index, the current configuration, or the observed reward (performance). While the current implementation remains simple, it can be easily extended to include richer state representations (e.g., channel measurements, queue status information). The communication between the simulator and the Python process uses a Portable Operating
System Interface (POSIX) Unix-domain socket. In particular, in each iteration, Kom8ndor sends a 32-bit integer header specifying the number of features, followed by a vector of 32-bit floats with the values of those features. The Python server returns a vector of 32-bit floats encoding the ML model output (e.g., next action). V. T UTORIAL & P ERFORMANCE S HOWCASE Kom8ndor is a command-line simulator that runs from the terminal or through multi-scenario shell scripts. Running Kom8ndor requires a C++ compiler (g++ with C++98 support) and a Linux or macOS environment (or WSL on Windows) to run the COST code-generation step. A Makefile is included in Kom8ndor to automatically build the source code (including the necessary COST libraries) and generate the binary komondor_main that runs the simulation. The Makefile also tracks all *.cc and *.h files as dependencies, so any change to any header (including the ones in Code/methods/) triggers a full rebuild. To build the code, one must run Build the code cd Code/main && make
Simulations are launched by invoking komondor_main with the necessary flags to specify the scenario and running features (--nodes, --mapc, --agents) together with simulation parameters (--time, --seed, --code). Log verbosity is controlled via --logs-sys and --logs-node, and output results are written to a generic .txt file (--out) and individual per-node and per-agent files (--save-node, --save-agent).2 The complete list of Kom8ndor flags is provided in Table II. A. Running MAPC Schemes We start by showing an example of a simulation involving MAPC schemes. In particular, we consider two overlapping BSSs (A and B) sharing the same 40 MHz channel (see Fig. 5a). We run four different cases: i) DCF, ii) Co-TDMA (an equal time split between APs is considered), iii) Co-SR (the coordinating AP uses full power while the coordinated AP 2 Saving logs entails high simulation times, particularly when simulating large deployments for a long time.
6
STAA1
0 Primary
STAB1
DL TX APA
DL TX
Primary
APB
0 1
MAPC agreem. BSS A
BSS A (DSO)
BSS B
STAB1
STAA1 APB
APA Primary
0 1 2 3
0 STAA2
Primary NPCA primary
(a) BSS A
BSS B
(a) 250
80
Throughput (Mbps)
Throughput (Mbps)
100
60 40 20 0 DCF
Co-TDMA
Co-SR
BSS B (NPCA)
Co-BF
(b)
200
STA A1
BSS A
STA A2
BSS B
STA B1
150 100 50 0 DCF
Fig. 5: MAPC example. (a) Scenario, (b) Throughput achieved per STA and scheme.
DSO / NPCA
(b)
Fig. 6: DSO & NPCA example. (a) Scenario, (b) Throughput achieved per STA, BSS, and scheme.
power is limited to 15 dBm), and iv) Co-BF (an 8-element ULA is considered for beamforming).3 The following commands are used to run these scenarios:
channel and has two associated 20-MHz STAs with DSO enabled. BSS B, instead, uses 80 MHz, with the first 40 MHz portion overlapping with BSS A’s bandwidth (see Fig. 6a). To run these scenarios, the following commands are used:
Running MAPC examples # DCF only ./komondor_main --n ../input/examples/mapc_ example/input_nodes_mapc_example.csv --t 100 --s 1
Running DSO and NPCA # DCF ./komondor_main --n ../input/examples/ dso_npca_example/input_nodes_dcf.csv --t 100 --s 1
# Scenario with MAPC (Co-TDMA example) ./komondor_main --n ../input/examples/mapc_ example/input_nodes_mapc_example.csv --m ../input/examples/mapc_example/mapc_cotdma_ example.csv --t 100 --s 1
# DSO and NPCA ./komondor_main --n ../input/examples/ dso_npca_example/input_nodes_dso_npca.csv --t 100 --s 1
The resulting throughput per BSS and scheme, which were extracted from Kom8ndor logs, are plotted in Fig. 5b. In this simple scenario, Co-TDMA leads to slightly lower throughput than DCF because of the overheads associated with the coordination. Co-SR increases the throughput further thanks to the geometric position of nodes in this deployment, which favors space reutilization. Finally, Co-BF shows the greatest improvement due to the Signal-to-Interference-plus-Noise Ratio (SINR) gains that result from coordinated nulling.
The resulting performance is shown in Fig. 6b. In this case, the two BSSs get the same aggregate throughput (which is equally split between the two STAs in BSS A). When adopting DSO (BSS A) and NPCA (BSS B), significant throughput gains are observed, which result from the higher flexibility of the two BSSs on accessing the medium. On one hand, STA A1 and A2 can be served simultaneously by AP A on channels #0 and #1, respectively. On the other hand, BSS B can access an unused portion of the spectrum (channels #2 and #3).
B. Running NPCA and DSO We consider a single deployment with two BSSs to show DSO and NPCA operation. In particular, BSS A uses a 40 MHz
C. Running ML Agents with Python We now focus on the newly added external ML model (set as learning mechanism=7 in the agents input
3 The different input files used across this section can be found in folder https://github.com/wn-upf/Komondor/tree/master/Code/input/examples.
7
file). When running this mode, the agent delegates arm selection (or other custom tasks) to an external Python application. As an example, we show a case on dynamic channel selection, for which we provide a server script (ml_server_random.py) that simply does random action selection. In addition, while not shown here, two other examples are provided in Code/learning_modules/: ml_server_passthrough.py (it simply echoes the current arm index back unchanged, to verify the socket connection) and ml_server_pytorch.py (loads a pre-trained model). In all the cases, the socket path is configured through the agents files and defaults to /tmp/komondor_ml.sock. To run our example, we use the following commands:
addition, beyond Wi-Fi 8 MAPC solutions will be progressively included and evaluated, such as a dynamic transmit power computation for Co-SR, QoS-based Co-TDMA scheduling, or smart MAPC scheme selection. R EFERENCES [1] G. Geraci et al., “Wi-Fi: 25 Years and Counting,” Proc. IEEE, 2026. [2] S. Barrachina-Munoz et al., “Komondor: A wireless network simulator for next-generation high-density WLANs,” in Wireless Days. IEEE, 2019, pp. 1–8. [3] G. F. Riley and T. R. Henderson, “The ns-3 network simulator,” in Modeling and tools for network simulation. Springer, 2010, pp. 15–34. [4] E. Mozaffariahrar et al., “R-TWT in Wi-Fi 7 and Beyond: Enabling Bounded Latency, Energy Efficiency, and Reliability,” in ETFA. IEEE, 2025, pp. 1–8. [5] P. Gawłowicz and A. Zubow, “Ns-3 meets openai gym: The playground for machine learning in networking research,” in MSWiM, 2019, pp. 113–120. [6] H. Yin et al., “ns3-ai: Fostering artificial intelligence algorithms for networking research,” in Workshop on ns-3, 2020, pp. 57–64. [7] A. Varga and R. Hornig, “An overview of the OMNeT++ simulation environment,” in SIMUtools, 2008, pp. 1–10. [8] MathWorks, “WLAN Toolbox,” R2026a. [Online]. Available: https: //www.mathworks.com/products/wlan.html [9] D. Ergenç and F. Dressler, “An Open Source Implementation of Wi-Fi 7 Multi-Link Operation in OMNeT++,” in WONS. IEEE, 2025, pp. 1–4. [10] M. Carrascosa-Zamacois et al., “Performance evaluation of MLO for XR streaming: Can Wi-Fi 7 meet the expectations?” in CAMAD. IEEE, 2024, pp. 1–6. [11] M. Alsakati et al., “Performance of 802.11 be Wi-Fi 7 with multi-link operation on AR applications,” in WCNC. IEEE, 2023, pp. 1–6. [12] A. Jeknić and E. Kočan, “Development steps that brought to Wi-Fi 7,” ETF Journal of Electrical Engineering, vol. 29, no. 1, pp. 65–79, 2023. [13] C. Chen et al., “Overview and performance evaluation of Wi-Fi 7,” IEEE Commun. Standards Mag., vol. 6, no. 2, pp. 12–18, 2022. [14] D. Nunez et al., “Enabling reliable latency in Wi-Fi 8 through multi-AP joint scheduling,” OJCOMS, 2025. [15] X. Liu et al., “Wi-Fi 8: Embracing the millimeter-wave era,” IEEE Commun. Mag., vol. 63, no. 3, pp. 69–75, 2024. [16] F. Wilhelmi Roca et al., “Spatial Reuse in IEEE 802.11 ax WLANs,” Comp. Comm. 2021, 170: 65-83, 2021. [17] S. Barrachina-Munoz, F. Wilhelmi, and B. Bellalta, “Dynamic channel bonding in spatially distributed high-density WLANs,” IEEE Trans. Mobile Comp., vol. 19, no. 4, pp. 821–835, 2019. [18] G. Chen and B. K. Szymanski, “Cost: A component-oriented discrete event simulator,” in Proc. of the Winter Simulation Conf., vol. 1. IEEE, 2002, pp. 776–782. [19] F. Wilhelmi et al., “A Tutorial on IEEE 802.11bn Multi-AP Coordination for Wi-Fi 8: From Standardization to Performance Evaluation,” arXiv preprint arXiv:2606.13759, 2026. [20] F. Wilhelmi et al., “Coordinated multi-armed bandits for improved spatial reuse in Wi-Fi,” in ICMLCN. IEEE, 2025, pp. 1–6. [21] B. Bellalta et al., “Modeling the IEEE 802.11 e EDCA for MAC parameter optimization,” in Het-Nets, 2006. [22] I. Tinnirello et al., “A Deterministic Backoff Approach for Wi-Fi and NR-U Coexistence in Shared Bands,” IEEE Trans. Mobile Comp., 2025. [23] F. Wilhelmi, L. Galati-Giordano, and G. Fontanesi, “It’s Your Turn: A Novel Channel Contention Mechanism for Improving Wi-Fi’s Reliability,” in WCNC. IEEE, 2025, pp. 1–6. [24] L. Sanabria-Russo et al., “A high efficiency MAC protocol for WLANs: Providing fairness in dense scenarios,” IEEE/ACM Trans. on Networking, vol. 25, no. 1, pp. 492–505, 2016. [25] A. Paszke et al., “Pytorch: An imperative style, high-performance deep learning library,” NeurIPS, vol. 32, 2019. [26] F. Wilhelmi et al., “Potential and pitfalls of multi-armed bandits for decentralized spatial reuse in WLANs,” JNCA, vol. 127, pp. 26–42, 2019. [27] F. Wilhelmi et al., “Decentralized Spatial Reuse Optimization in Wi-Fi: An Internal Regret Minimization Approach,” arXiv preprint arXiv:2602.08456, 2026.
Running ML with Python # Terminal 1: start the server first python3 Code/learning_modules/python_servers/ ml_server_random.py /tmp/komondor_ml.sock # Terminal 2: run the simulation (Code/main) ./komondor_main --n ../input/examples/ external_model_example/input_nodes.csv --a ../input/examples/external_model_example/ agents_external.csv --t 100 --s 1
On the server side, it is displayed the information of each interaction (current arm, reward, and next selected arm): [ml_server_random] Listening on /tmp/komondor_ml.sock ... [ml_server_random] Client #1 connected. [ml_server_random] Client #2 connected. recv: arm_ix=0 reward=0.4261 num_arms=2 next_arm=1 recv: arm_ix=0 reward=0.5351 num_arms=2 next_arm=0 recv: arm_ix=1 reward=0.0000 num_arms=2 next_arm=0 ...
On the Kom8ndor side, the simulation takes place, showing at the end the summary for each agent: ------- Agent A0 -----· External model: socket=/tmp/komondor_ml.sock · Cumulative reward per arm: 49.325949 0.000000 · Times each arm has been selected: 105 94 ------- Agent A1 -----· External model: socket=/tmp/komondor_ml.sock · Cumulative reward per arm: 47.210786 0.010393 · Times each arm has been selected: 99 100
Beyond MAB algorithms, the external server enables countless Python implementations (ml_server_pytorch.py uses a pre-trained DNN for inference). The same interface naturally supports algorithms like Deep Q-Network (DQN), turning Kom8ndor into an RL gym like [5]. VI. C ONCLUSIONS AND F UTURE W ORK Kom8ndor is a live project. It is the basis for simulationdriven research on Wi-Fi 8 and beyond in the Wireless Networking research group at Universitat Pompeu Fabra (UPF). In this paper, we present the first release of Wi-Fi 8, outlining its main features so far: MAPC, NPCA, DSO, and the integration of ML tools. However, this does not stop here, and more work is in the pipeline. First, relevant features from previous generations of Wi-Fi, e.g., MLO, OFDMA, or R-TWT, will be included to study their interplay with Wi-Fi 8 functionalities. In
8