Zebras look like horses, but they are not the same... Zebras, despite man's best efforts, cannot be tamed. The Wi-Fi we have engineered today remains fundamentally a collection of autonomous, uncoordinated things—zebras that simply cannot be harnessed.

Fi-Wi is architected from the ground up to be controllable, coordinated, and directed — the horse we need for in-building communications and sensing. As latency demands tighten and building densities increase, Fi-Wi isn't just a better future; it's the future we can build today.

1. Motivation and Problem Statement

"Perfection is achieved, not when there is nothing more to add, but when there is nothing left to take away." — Antoine de Saint-Exupéry

"Everything should be made as simple as possible, but not simpler." — Albert Einstein

With 23.3 billion Wi-Fi devices in use worldwide and 5.5 billion people depending on internet connectivity, and growing, Wi-Fi has become the primary way we access the internet. So much so many people think Wi-Fi is the internet. It's how a home healthcare worker video-calls to check on a patient, or a cancer patient connects to their support group. It’s how a parent works remotely while their child attends school online, and how lifelong learners access the information they need to grow. It’s how a grandmother monitors her heart condition through a telehealth app. It’s how a family member finds their next job, or how a neighbor orders a meal.

Running quietly in the background are autonomous systems we've come to depend on: security cameras that alert us to threats, medical monitors that track vital signs, smart home systems that manage climate and safety, IoT sensors that detect water leaks or carbon monoxide. These systems don't wait for us to notice problems—they operate continuously, silently, keeping people safe.

We've moved far beyond entertainment and convenience. Wi-Fi now carries the infrastructure of daily survival. When it breaks down under density or congestion, it's not just buffering that fails. It's jobs, healthcare access, human connection, and the life-safety systems we trust to work when we're not watching. The $4.9 trillion Wi-Fi contributes to the global economy isn't an abstract number. It's the cumulative value of billions of human activities and critical systems that simply stop working when the network fails.

Why Traditional Wi-Fi Cannot Support L4S

The infrastructure supporting all of this is failing at scale, and it must be addressed for all. The industry is moving toward L4S and ECN-based control to eliminate bufferbloat, but traditional Wi-Fi makes this impossible. Legacy congestion-control loops fail by design once a single flow saturates the bottleneck queue, and even modern ECN-based systems such as L4S cannot converge when Wi-Fi hides queue depth, induces collision storms, injects firmware-created delays that look like queues, and constantly shifts transmission (PHY) rates through its rate-control and aggregation machinery. Mesh networks and more APs catalyze intolerable user experiences by injecting more uncoordinated radios into an already chaotic RF environment. And because the AP industry understands these limits, it is no surprise that even major vendors publicly state that L4S cannot operate correctly over the products they sell.

Adding more Ethernet-attached APs makes it worse by creating more overlapping contention domains. Hidden queues in SoCs, rate-control firmware, and aggregation pipelines obscure the true bottleneck. In control-theory terms: the bottleneck queue cannot expose its state, the PHY rate is not stationary, and the closed loop cannot stabilize. This is why user experience fails in many apartments and homes, in hotels, MDUs, stadiums, and high-density buildings long before “capacity” is reached.

QoS cannot rescue this architecture. Because the bottleneck queue inside a Wi-Fi AP has no information about actual flow urgency or priority, no QoS mechanism can operate meaningfully. The only real solution is to avoid congestion altogether — which is exactly what L4S researchers have designed for and exactly what Fi-Wi supports.

Why Copper Infrastructure Has Reached Its Limits

While the protocol fails in the air, the physical infrastructure fails in the walls - the industry’s traditional answer of running copper Ethernet to APs — simply extends the lifetime of an architecture that has reached its limits. Copper requires periodic rip-and-replace cycles: Cat5 becomes Cat6, then Cat7, then Cat8. A home builder has no idea what communications wiring to install. The RJ45 connector and its plastic tab is fragile, outdated and end of life. And at 25G, 40G, or 100G, physics takes over: copper loses signal in dB per inch. Data centers have abandoned structured cabling (long-run copper) for core transport, restricting copper only to short-reach intra-rack DACs. Fi-Wi applies this same logic to the building: Fiber for the long haul (halls/walls), radio for the short hop.

How Fi-Wi Breaks Both Cycles

Fi-Wi breaks the cycle. Install fiber once — and never revisit behind walls or ceilings again. The glass is permanent; only the optics evolve. Fiber is already the universal medium for 100G/400G data centers, DWDM long-haul transport, and now PCIe throughout a building with Fi-Wi. Remote Radio Heads simply convert between fiber and 802.11, eliminating embedded routing, rate-control SoCs, switching silicon, and the security-patch treadmill they require. When Wi-Fi standards evolve, you replace the small radio module(s) — that's all.

Fi-Wi turns fiber combined with 802.11 into the permanent, predictable, control-theory-friendly transport that the L4S control loop requires, and treats 802.11 radio heads as the small, disposable, last-meters, connector-free interface where the in-building network behaves deterministically. And because fiber increases the long-term value of a building, the investment is not just technically durable — it is financially durable.

The Opportunity Is Here

There is no law of physics that says Wi-Fi cannot work at scale. The collapse we're seeing in apartments, hotels, and high-density buildings isn't inevitable. The researchers have shown engineers how to proceed. We know how to build stable control loops. We know how to coordinate radios. We know how to deploy permanent infrastructure.

The conditions for solving this are here, now. Engineering talent exists across our industry. The market has already validated the foundation: China's FTTR deployments have installed fiber to millions of rooms, proving that permanent infrastructure at this scale is not just feasible—it's already happening at volume. What's missing is capital directed at the right architecture. Investors are essential to this challenge. Their capital will enable the engineering to serve the market. And, once proven, market signals will sustain the development, directing human resources toward building what humanity needs for continued advancement.

Fi-Wi is Umber's answer, but the underlying challenge belongs to all of us. The 5.5 billion people depending on this infrastructure deserve better than a system designed for convenience that we've repurposed for survival. This is solvable engineering—the talent is ready, the manufacturing exists, and the market is waiting. It's time we came together and fixed this.

2. The Wi-Fi Crisis: Why Evolution Failed and Control Was Lost

The failure of modern Wi-Fi to support low-latency applications (L4S) is not a failure of bandwidth; it is a failure of control. With 23.5 billion Wi-Fi devices deployed globally, the protocol has hit an asymptotic limit where adding complexity yields diminishing returns.

As density rises, autonomous contention scales super-linearly—effectively operating as the inverse of Metcalfe's Law. The result is a rising noise floor and media access collisions that render unlicensed spectrum unusable for the deterministic performance required by next-generation applications.

2.1 The Evolutionary Trap: Why Incremental Improvements Failed

Evolutionary engineering is powerful; it gave us twenty-five years of Wi-Fi speed improvements. But every evolutionary curve eventually hits an asymptote—a point where adding more complexity yields diminishing returns. We have reached that point.

"The IEEE 802.11 working group behaves like a composer writing a symphony that effectively cannot be played. They continually add instruments—4096-QAM, Puncturing, MLO—without considering that the musician (the silicon) has only microseconds to react."

The decision matrix for a Wi-Fi chip has exploded combinatorially. We can trace this through the Modulation and Coding Scheme (MCS) Table:

• 1999 (802.11b): 4 choices (1, 2, 5.5, 11 Mbps). A simple if/else ladder.
• 2003 (802.11g): 12 choices with OFDM.
• 2009 (802.11n): 77 choices with MIMO and Channel Bonding.
• 2013 (802.11ac): 80+ choices with 256-QAM and wider channels.
• 2024 (802.11be / Wi-Fi 7): Thousands of permutations involving 4096-QAM, 320 MHz channels, 16 Spatial Streams, and Puncturing patterns.

The Physical Trap: When the firmware engineer fails to optimize the radio, can we simply redesign the chip? No, because of RTL (Register Transfer Level) Accretion. In software, engineers "refactor" unwieldy code. In hardware, refactoring is economically forbidden. A complex SoC takes 18–24 months to validate; removing "dead" logic risks breaking obscure corner cases. Consequently, vendors only add; they never subtract. 802.11be logic wraps around 802.11ax logic, which wraps around 802.11ac logic—twenty-five years of accumulated technical debt consuming area and leakage power.

The Market Signal: The ultimate proof that the standard has reached gridlock is the behavior of market leaders like Samsung and Apple. They no longer rush to support every new feature—they aggressively whitelist features and blacklist others because complexity drains battery and destabilizes connections. When the two largest consumers of wireless silicon effectively stop buying the complexity argument, the evolutionary roadmap is broken.

2.2 The Density Paradox: More Capacity, Less Performance

The fundamental instability of 802.11 stems from the Birthday Paradox applied to media access. In an autonomous system, as the number of contending stations (n) increases linearly, the probability of collision increases combinatorially:

Simulation data confirms that even with moderate client density, collision probability quickly exceeds 50%, forcing the network into a state of "Drift" where latency becomes unbounded. Under these conditions, the network is no longer constrained by PHY capacity, but by the probability of successful media access.

This is Metcalfe's Law in reverse: instead of each new node increasing the value of the network, each new node increases the chance of interference and reduces usable capacity.

2.3 The Three Technical Failure Modes

The collapse of the operator model is driven by three distinct architectural failures inherent to the 802.11 standard.

2.3.1 Protocol Tax: The Hidden Node Penalty

Standard Wi-Fi relies on Carrier Sense Multiple Access (CSMA), which assumes that all stations can hear each other. In real-world MDU (Multi-Dwelling Unit) environments, this assumption fails catastrophically.

Field measurements using ESP32-based sensors reveal that hidden node contention consumes 30-50% of available airtime in typical MDU deployments—airtime paid for in spectrum acquisition costs but lost to protocol overhead invisible to traditional monitoring. This represents a massive protocol tax where significant airtime is consumed by retries and backoff slots rather than payload delivery.

2.3.2 The MCS Matrix: Un-Engineerable Complexity

The most critical failure for a network operator is the loss of state control. Modern 802.11ax supports 12 MCS indices × 4 bandwidth options × 8 spatial stream configurations × 3 guard intervals = >1,000 valid PHY states. Autonomous rate selection must navigate this space at sub-millisecond timescales under non-stationary noise.

This creates a Non-Stationary System:

• Non-Stationary Chaos (Wi-Fi): The noise profile is time-variant and driven by unbounded interference (neighbors). This results in an unpredictable latency tail that cannot be engineered away.
• Stationary Stochasticity (Wired Networks): By contrast, cable and fiber networks operate on shielded media with known thermal noise profiles. The distribution is time-invariant, allowing for engineerable reliability (99.999%).

Because Wi-Fi is non-stationary, autonomous rate selection under contention has no bounded outcome. The IEEE 802.11 standard has allowed the MCS table to explode into hundreds of valid permutations—a chaotic state space that firmware must navigate in microseconds with incomplete information.

2.3.3 The Spatial Contention Cascade

As load increases, the spatial precision of the network degrades. Mathematical modeling shows that the condition number (κ)—a measure of how well-conditioned the MIMO channel matrix is—degrades from 6 dB (excellent spatial separation) to >12 dB (severe interference) under load. This collapse means that 4×4 MIMO effectively degrades to 2×2 or worse, turning additional spatial streams into self-interference rather than capacity.

This degradation collapses the theoretical gains of Mu-MIMO, transforming high-order spatial streams into interference rather than usable capacity. The "Efficiency Paradox" emerges: Wi-Fi evolution has focused on shrinking Payload Duration (faster PHY rates like 4096-QAM) while MAC Overhead (LBT, Backoff, Preamble) remains constant. To amortize the overhead, chips must build massive Aggregates (A-MPDUs). This destroys latency. We have engineered a Ferrari engine (the PHY) inside a garbage truck (the MAC).

2.4 The Operator's Dilemma

For network operators—whether cable MSOs, telcos, or fiber providers—this architectural chaos presents a fundamental business risk: You own the customer experience, but not the air interface.

• Wasted Infrastructure Investment: Investments in L4S congestion control, low-latency transport, and multi-gigabit access are negated if the final 10 meters are non-deterministic. The bottleneck shifts from the core to the customer premise, and operators lose visibility into the failure point.
• The Silicon Trap: Vendors market 4096-QAM (Wi-Fi 7), which requires ~40 dB SNR—physically impossible to sustain in dense environments. Operators pay for silicon logic that creates marketing value but zero operational value. The promised performance exists only in anechoic chambers, not in apartments with 30+ interfering networks.
• Operational Drag: The "un-engineerable gap" drives OPEX through support calls, truck rolls, and customer churn. When a subscriber's video call freezes, they call their ISP—even though the failure is in the Wi-Fi AP, not the WAN link.
• Competitive Vulnerability: Fiber-to-the-home providers market deterministic performance as a premium feature. Operators relying on legacy Wi-Fi CPE risk commoditization if they cannot match these latency and reliability guarantees.

2.5 Why Conventional Solutions Don't Scale

Traditional attempts to solve Wi-Fi density problems fail because they address symptoms rather than the underlying architectural failure:

• More APs: Adding APs increases the number of contending radios, exacerbating the Birthday Paradox. Collision probability grows combinatorially. More APs simply create more independent collision domains with the same per-domain collapse behavior.
• DFS (Dynamic Frequency Selection): Regulatory limitations and radar evacuation requirements make DFS unreliable for latency-sensitive applications. When a radar is detected, the AP must vacate the channel within seconds, causing multi-second outages.
• 6 GHz Spectrum: Additional spectrum doesn't solve density—it just shifts the collision problem to a new band. The fundamental CSMA/CA contention mechanism remains unchanged.
• Wi-Fi 7 / MLO (Multi-Link Operation): More MCS states = MORE chaos. Multi-Link Operation adds link diversity but doesn't eliminate autonomous contention. Each link still suffers from the same collision storms and hidden queue problems.
• Mesh Networks: Mesh adds relay hops, multiplying latency and cutting effective throughput by 50% per hop. Multi-hop mesh in dense environments becomes a latency disaster.

The Trillion-Dollar Context: The mobile industry spent $600 billion building 5G to get scheduled, deterministic performance outdoors. They understand that unlicensed spectrum + autonomous contention = chaos. The genius of 5G is its architecture; its Achilles heel is its cost. In recent auctions, 20 MHz of licensed mid-band spectrum sold for over $17 billion for U.S. rights alone.

Fi-Wi applies the cellular C-RAN architecture indoors—but on unlicensed spectrum that costs nothing. This is the arbitrage opportunity.

2.6 The Client Side: L4S and the End of Uplink Contention

The architectural reset is not limited to the infrastructure; it fundamentally alters the behavior of the Station (STA). In legacy Wi-Fi, the STA is an autonomous agent that fights for upstream airtime using EDCA (Enhanced Distributed Channel Access). It maintains its own local WMM queues and blindly transmits whenever it wins a contention window, often oblivious to the fact that the AP's receive buffer is already full.

The L4S Inversion: With L4S, the "Quality of Service" decision moves from the Wi-Fi card's firmware to the application's congestion control algorithm. We replace the rigid, static categories of WMM with the dynamic, adaptive responsiveness of TCP Prague and other L4S-compliant congestion controls.

• Legacy Behavior (Push): The STA pushes packets into the air as fast as the PHY allows. If the AP is congested, the STA doesn't know until packets drop or layer 2 retries spike. Latency accumulates in the STA's own driver queue because the "pipe" is smaller than the "faucet."
• Fi-Wi Behavior (Pull/Signal): The Fi-Wi Concentrator detects congestion at the ingress of the air interface. It marks packets (specifically ACKs going back to the STA) with the CE (Congestion Experienced) bit. When the STA receives this mark, TCP Prague immediately reduces its send window. The STA voluntarily throttles itself.

Eliminating the "Uplink Queue": This effectively virtualizes the queue. Instead of a deep buffer sitting on the Wi-Fi chip waiting to be transmitted, the packets are held in user-space memory on the client device, waiting for the "go" signal (or rather, the absence of a "stop" signal). The traffic never enters the contention domain until there is guaranteed capacity to service it. The STA no longer needs complex internal QoS schedulers because it is no longer trying to force more data than the pipe can hold.

2.7 The Strategic Reset: Splitting the Graph

Solving this requires a "Subtractive Architecture." Instead of adding more features to the radio, we must remove them. The architectural breakthrough of Fi-Wi is decoupling the MCS State Graph described in Section 2.3.2 into its constituent parts:

• The Concentrator Owns the Edges (Navigation): The computational complexity of Wi-Fi lies in the transitions—deciding when to move from one state to another based on interference, queue depth, and CSI. By moving this logic to a workstation-class processor, the Concentrator can traverse the graph in software, evaluating the cost of every edge in real-time. These edge costs are computed from CSI vectors (channel quality), queue sojourn time (congestion), and spatial correlation matrices (interference), allowing the Concentrator to choose the lowest-cost path through the MCS state space for each packet.
• The Radio Head Owns the Nodes (Execution): The Radio Head is reduced to a simple instrument that owns the physical states (the nodes). It does not decide which node to occupy; it acts as a stateless executor, converting the Concentrator's command (MCS_INDEX, N_SS, TXOP_DURATION) into the precise RF waveform without autonomous deliberation.
• The Graph Is Not Static: Unlike traditional rate adaptation (e.g., Minstrel), the Concentrator's graph is continuously recomputed based on global state. The edge costs reflect not just per-client SNR, but cross-client interference, queue depth across all flows, and spatial correlation between RRHs. This global visibility is impossible in autonomous APs, where each device sees only its own local channel state.

This architectural shift—from distributed chaos to centralized control—mirrors the evolution from analog transmission systems (noise-prone, operator-invisible) to digital QAM (deterministic, monitorable). Fi-Wi completes this transformation for the last 10 meters, moving the network from a model of probabilistic negotiation to one of deterministic execution.

Section 13 describes the Concentrator's scheduling algorithm that implements this graph traversal, while Appendix C details the RRH's scatter-gather DMA mechanism that executes the chosen state transitions at microsecond timescales.

2.8 Interactive Visualization: The MCS Collapse Under Load

The following interactive simulation demonstrates the architectural differences between Fi-Wi, autonomous APs, and mesh networks under varying load conditions. It visualizes the MCS State Graph discussed in Section 2.7, showing how autonomous systems fail to navigate this state space under density.

Each "room" represents a device with a 4 × 12 grid of MCS states (4 spatial streams × 12 MCS indices). The ghost node (dashed) shows the ideal state based on channel quality, while the active node shows the actual state selected by the rate control algorithm.

Technical Details: Understanding the Visualization

MCS Grid: Each 4×12 grid shows all possible MCS states. Top rows = Mu-MIMO (multi-user), bottom rows = standard 2×2 MIMO. Columns = MCS index (0-11, higher = faster but needs better SNR).

Eigenvalues (λ₁, λ₂): Strength of spatial modes in the MIMO channel. As density increases in autonomous mode, λ₂ collapses → spatial interference.

Condition Number (κ): Ratio λ₁/λ₂ in dB. Low (~6 dB) = good. High (>12 dB) = Mu-MIMO degraded to single-stream. This directly demonstrates the "Spatial Contention Cascade" from Section 2.3.3.

Collision Probability: Computed using Birthday Paradox formula: n(n-1)/2 collision pairs. When this exceeds 50%, the network enters "Drift" state with unbounded latency.

Why This Matters for Network Operators

This visualization proves the loss of control described in Section 2.4. In autonomous mode, operators cannot engineer performance because the system navigates a 1,000+ state MCS graph with no global coordination.

In Fi-Wi mode, the Concentrator's global state visibility allows it to:

• Choose optimal MCS/SS combinations based on current cross-room interference
• Coordinate spatial reuse to prevent Mu-MIMO collapse (maintain κ < 12 dB)
• Eliminate collisions through centralized scheduling (Birthday Paradox solved)
• Apply accurate L4S ECN marking with full queue visibility

The result: predictable, engineerable performance that scales with density instead of collapsing. The difference becomes visceral when you watch autonomous mode turn red under the same load that Fi-Wi handles in green.

3. System Picture

                        ┌────────────────────────────────────────────┐
                        │              Fi-Wi Concentrator            │
                        │────────────────────────────────────────────│
   L4S/ECN-aware        │                                            │
   traffic from LAN/    │   ┌────────────────────────────────────┐   │
   WAN (IP/802.3)  ─────┼─▶│    Central Packet Memory & Queues  │   │
                        │   │  • Per-flow / per-tenant queues    │   │
                        │   │  • Per-airtime-domain queues       │   │
                        │   │  • Enqueue timestamps (µs)         │   │
                        │   └───────────────┬────────────────────┘   │
                        │                   │                        │
                        │   ┌───────────────▼────────────────────┐   │
                        │   │   L4S/AQM & Scheduler              │   │
                        │   │  • Sojourn-time based ECN marking  │   │
                        │   │  • TXOP length control (≈250 µs)   │   │
                        │   │  • RF grouping & spatial streams   │   │
                        │   └───────────────┬────────────────────┘   │
                        │                   │ PCIe over fiber        │
                        └───────────────────┼────────────────────────┘
                                            │
        ┌───────────────────────────────────┼───────────────────────────────────┐
        │                                   │                                   │
        │                                   │                                   │
┌───────▼─────────┐                ┌────────▼─────────┐                ┌────────▼─────────┐
│   RRH #1        │                │   RRH #2         │                │   RRH #3         │
│ (Thin MAC/PHY)  │                │ (Thin MAC/PHY)   │                │ (Thin MAC/PHY)   │
│  • RF front end │                │  • RF front end  │                │  • RF front end  │
│  • DFE + FFT    │                │  • DFE + FFT     │                │  • DFE + FFT     │
│  • Minimal MAC  │                │  • Minimal MAC   │                │  • Minimal MAC   │
│  • DMA engine   │                │  • DMA engine    │                │  • DMA engine    │
│  • PTP sync     │                │  • PTP sync      │                │  • PTP sync      │
└───────┬─────────┘                └────────┬─────────┘                └────────┬─────────┘
        │                                   │                                   │
        │                                   │                                   │
        │                 PCIe-over-fiber links (no deep queues in RRHs)        │
        │                                   │                                   │
        │                                   │                                   │
┌───────▼─────────┐                ┌────────▼────────┐                 ┌────────▼─────────┐
│   RRH #4        │     ...        │   RRH #N        │                 │   Wi-Fi STAs     │
│ (Thin MAC/PHY)  │                │ (Thin MAC/PHY)  │     (Rooms, AP-like cells, clients)│
│  • RF front end │                │  • RF front end │                 │  • Phones        │
│  • DFE + FFT    │                │  • DFE + FFT    │                 │  • Laptops       │
│  • Minimal MAC  │                │  • Minimal MAC  │                 │  • IoT devices   │
│  • DMA engine   │                │  • DMA engine   │                 │                  │
│  • PTP sync     │                │  • PTP sync     │                 │                  │
└─────────────────┘                └─────────────────┘                 └──────────────────┘
  

3.1 Classical Stack vs. Fi-Wi (The C-RAN Shift)

To understand Fi-Wi, we must first unlearn the definition of an "Access Point."

In a typical controller-managed enterprise Wi-Fi deployment, a centralized controller (e.g., Cisco WLC, Aruba Mobility Controller, Ubiquiti UniFi Controller) coordinates AP configuration: channel assignment, transmit power, client steering recommendations, and SSID management. However, each AP remains autonomous at the data plane:

• Each AP maintains its own queues and packet buffers
• Each AP makes its own MAC scheduling, aggregation, and TXOP decisions
• APs have no visibility into other APs' per-packet state, queue depths, or precise timing
• CSI (Channel State Information) remains local to each AP
• There is no shared timestamp reference or coordinated DMA across APs

These systems are loosely-coupled: the controller manages the control plane (configuration, policy) but the data plane — queuing, MAC scheduling, aggregation, and packet forwarding — remains distributed and autonomous across individual APs.

In Umber Fi-Wi (C-RAN for Wi-Fi), we split the AP and cellularize the RF domain, down to room-level. The concentrator sees all flows, all queues, and all RRHs. The RRHs handle 802.11 MAC/PHY but are tightly time-synchronized and behave as DMA-driven PHY/MAC endpoints rather than autonomous APs. A set of RRHs and their shared queues form a cellularized Wi-Fi domain within the building, often at “cell per room” granularity.

Fi-Wi centralizes both control plane AND data plane with shared state across all RRHs. The concentrator doesn't just configure RRHs; it directly manages their queues, schedules their TXOPs, and maintains unified timestamp-synchronized state across the entire cellularized RF domain.

3.2 Dual-Loop Control Model

Conceptually, Fi-Wi decouples the system into two nested feedback loops, separated by timescale:

The Outer Loop manages congestion and end-to-end latency (Internet speed). The Inner Loop manages MAC efficiency and radio timing (Airtime).

The Problem with Legacy Wi-Fi: Traditional APs couple these loops unpredictably, creating "sawtooth" latency patterns that confuse TCP.

The Fi-Wi Solution: By centralizing both loops in the Concentrator, Fi-Wi enforces a strict Time-Scale Separation. The Inner Loop runs so fast (3–5 kHz) that it appears as "constant service" to the slower Outer Loop (10–20 Hz), allowing L4S to stabilize perfectly.

(See Section 5: Control Architecture for the rigorous control-theoretic analysis and stability criteria.)

4. Key Fi-Wi Mechanisms

4.1 Time Synchronization

Fi-Wi operates across two distinct time domains simultaneously. The first is the concentrator's internal master clock, disciplined via PTP/802.1AS over the PCIe fronthaul (detailed in Section 4.7). The second is the 802.11 TSF (Target Sync Function) domain that 802.11 clients use to coordinate with the MAC layer. In a traditional AP these two clocks are decoupled — the AP runs one TSF and one clock. In Fi-Wi, with 24 RRHs each presenting a TSF-aware BSS, managing the relationship between them is a foundational architectural responsibility of the concentrator.

4.1.1 The Fronthaul Clock: PTP/802.1AS

The concentrator synchronizes its master clock to all attached RRHs on the order of microseconds (and substantially tighter when using PCIe-native timing mechanisms such as PTM — see Section 4.7 for the full hardware chain). This master clock gives every packet:

• A meaningful ingress timestamp when it is enqueued in central memory
• A meaningful service timestamp when the RRH actually transmits it over the air
• A consistent time base for measuring queue sojourn time and service behavior per RRH or per RF group

This clock lives entirely inside the Fi-Wi domain. Clients never see it directly. It is the coordinate system in which shim header timestamps (Section 4.2), AQM marking decisions (Section 4.3), and the ML training corpus (Section 15) are all expressed. Because all packet timestamps, service events, and queue measurements are expressed in this single master time domain, Fi-Wi can compute precise per-packet sojourn times independent of the TSF domain, enabling stable ECN marking and L4S control across the system.

4.1.2 The 802.11 TSF Domain

The 802.11 TSF is a 64-bit microsecond counter that every client associates with a BSS. Clients set their local TSF from beacons. They use it to wake from power save at the right moment, to interpret TBTT (Target Beacon Transmission Time), and to coordinate TXOP timing. The TSF is the only MAC-visible clock the 802.11 standard exposes at the MAC layer.

In a traditional single-AP deployment this is trivial: one AP, one TSF, one beacon stream. In Fi-Wi it is not. Consider a client in a room served by two RRHs in the same airtime domain. That client will receive beacons from both RRHs. If those beacons carry inconsistent TSF values, even small inconsistencies can lead to misaligned power-save wakeups, ambiguous TBTT interpretation, and in some implementations degraded performance or reassociation. The coherence of the TSF domain across all RRHs in a BSS is not optional; it is a hard correctness requirement.

Fi-Wi satisfies this requirement by construction: the concentrator generates all beacon frames. No RRH constructs its own beacon. The concentrator writes the TSF value into every beacon before dispatching it to the appropriate RRH for transmission. Because all TSF values originate from the same source and are derived from the same master clock, they are consistent by design rather than by coordination protocol. Within a given BSS, TSF values are identical across all participating RRHs; multiple TSF domains arise only when multiple BSS instances are present.

4.1.3 The Concentrator as Time Origin

The concentrator maintains 25 simultaneous time references: its own PTP-disciplined master clock and one 802.11 TSF per RRH. Each TSF has its own epoch (established at BSS creation) and its own drift correction term, derived from periodic synchronization updates over the fronthaul (PTP/802.1AS or PCIe PTM), which bound long-term drift. The concentrator knows the exact affine mapping between the master clock and every client-visible TSF domain at all times:

TSF_i(t) = (t_master - epoch_i) + drift_correction_i(t)

Any event — a packet enqueue, an ECN mark, a TXOP start, a beacon transmission — can be expressed in any of the 25 frames without loss of precision. This is the time-domain analog of a coordinate transformation: the concentrator is the origin from which all other reference frames are derived, and any event timestamp can be mapped between frames via a known, invertible affine transform, updated continuously via the fronthaul synchronization loop.

Concentrator master clock (PTP-disciplined)
  │
  ├─ Master frame: all shim timestamps, sojourn times, AQM marks, ML labels
  │
  ├─ TSF_1:  epoch_1, drift_1(t)  →  beacon stream for RRH 1  ┐
  ├─ TSF_2:  epoch_2, drift_2(t)  →  beacon stream for RRH 2  │ identical within
  ├─ TSF_3:  epoch_3, drift_3(t)  →  beacon stream for RRH 3  │ a given BSS
  │   ...                                                       ┘
  └─ TSF_24: epoch_24, drift_24(t) → beacon stream for RRH 24

Any event E has coordinates in all 25 frames simultaneously.
Mapping between any two frames: affine transform, known at the concentrator,
updated continuously via the fronthaul sync loop.
    

This unified time model also enables the concentrator to schedule transmissions across RRHs against a single global timeline, rather than relying on independent per-RRH contention processes. TSF continuity across RRH handoffs is a direct consequence of centralized beacon generation, and it is what makes Fi-Wi's active redundancy claims in Section 8 operationally credible: per-packet steering between RRHs is transparent to clients because the client's MAC-layer time reference never changes. This unified time model enables not only precise measurement, but coordinated control of transmission behavior across RRHs, as described in Section 4.1.4.

4.1.4 Time-Driven EDCA Orchestration

The unified time model described above is not only a measurement framework; it is the foundation for Fi-Wi's centralized MAC scheduling. In conventional 802.11 deployments, EDCA (Enhanced Distributed Channel Access) operates as a stochastic contention mechanism: each AP independently selects random backoff values within its CWmin/CWmax range, and medium access emerges probabilistically.

In Fi-Wi, EDCA is not treated as a distributed random process. It is treated as a centrally orchestrated actuation layer, driven by the concentrator's master time reference.

Because the concentrator maintains:

• A global view of all per-RRH transmit queues
• Precise enqueue and service timestamps in the master clock domain
• A coherent TSF domain across all RRHs participating in a BSS

it can shape medium access behavior across RRHs by dynamically controlling EDCA parameters on a per-radio basis. The key parameters are:

• CWmin / CWmax: control the distribution of backoff intervals
• AIFS: offsets contention start times between RRHs
• TXOP: defines the service quantum once access is obtained

By assigning narrowly bounded contention windows and staggered AIFS values across RRHs, the concentrator can bias contention outcomes such that one RRH is overwhelmingly likely to win access at a given moment. Rotating these parameters over time creates a soft time-division multiplexing (TDM) effect using standard EDCA semantics.

This transformation is only possible because all RRHs share a common time reference. The concentrator can schedule EDCA parameter updates relative to the master clock and ensure that all RRHs apply them in a coordinated manner. Without this shared time base, independent EDCA processes would quickly decorrelate and revert to stochastic contention.

Conceptually, the concentrator executes a scheduling loop:

for each scheduling interval:
  observe queue state across RRHs        // centralized visibility
  select next RRH (or RF group) to serve // queue-aware decision
  assign EDCA parameters (CWmin, CWmax, AIFS, TXOP)
  enforce timing relative to master clock // coordinated application

The result is not strict TDMA — 802.11 contention semantics are preserved and the system remains compliant with standard client behavior — but the distribution of outcomes is shaped by the concentrator. Over short time horizons, access becomes highly predictable and service intervals can be bounded. This has two critical consequences:

• Deterministic service timing: Packets experience bounded and observable delay between enqueue and transmission, enabling stable AQM and ECN marking.
• Queue-aware scheduling: RRHs with pending traffic can be prioritized immediately, while idle RRHs do not contend unnecessarily for airtime.

Because TSF values are consistent across RRHs, these scheduling decisions are MAC-transparent to clients. From the client's perspective, the network behaves as a single, coherent AP with stable timing characteristics, even as transmissions are steered across multiple physical radios.

This time-driven EDCA orchestration is the mechanism by which Fi-Wi converts the inherently stochastic 802.11 MAC into a predictable, centrally scheduled system — completing the chain from time synchronization through queue observability to stable L4S control.

4.2 Fi-Wi Shim Header

Between 802.3/IP and the fronthaul link we add a small internal metadata header. Conceptual form:

struct FiWiMeta {
  uint64_t seq;          // fronthaul sequence number
  uint64_t t_ingress_us; // time packet enqueued into group queue (central DRAM)
  uint32_t txop_id;      // TXOP this MSDU is in
  uint8_t  mpdu_idx;     // index within aggregate
  uint8_t  mpdu_cnt;     // total MSDUs in this TXOP
  uint8_t  ecn_flags;    // CE applied? which queue? reason bits
  uint32_t qlen_pkts;    // queue depth snapshot at TXOP start
};

This header is visible only inside the Fi-Wi domain. It lets us:

• Record timestamps and queue snapshots at enqueue and dequeue
• Mark ECN based on central queue state at the moment of service
• Reconstruct at the concentrator exactly when a packet was queued and actually transmitted
• Compute a real feedback delay Td = now - t_mark per flow or per RF group

4.3 AQM / L4S Marking Placement

We choose the group queues in the concentrator—each corresponding to a cellularized airtime domain shared by one RRH or by multiple interfering RRHs—as the only places where deep queues are allowed and where we apply ECN:

• Downlink: group queues feeding downlink RRHs
• Uplink: group queues collecting uplink traffic from RRHs

Other queues (within RRH hardware, on the fiber/fronthaul link) are kept shallow via pacing and controlled descriptor posting. The group queues become the single bottlenecks in each cellularized airtime domain, which is exactly what L4S wants: a small number of stable, well-behaved bottlenecks with known behavior. The control policy is explicitly tuned to keep both average and tail queueing delay low.

4.4 Centralized Packet Memory and DMA

In Fi-Wi, packet memory is centralized in the concentrator:

• Each RF airtime domain has one or more group queues implemented in concentrator DRAM.
• RRHs act as DMA engines that push/pull frames to/from those central queues.
• On-chip RRH buffers are deliberately small and just-in-time filled, to avoid hidden queues.

This design:

• Makes all meaningful queues fully visible to the control plane
• Lets AQM / ECN marking run exactly where the integrator (queue) lives
• Ensures there are no uncontrolled “mystery buffers” in the RF domain

4.5 RRH Edge Control via Beacon Power Shaping

Because the Fi-Wi concentrator maintains shared state for the entire RF domain, it can directly control the RF footprint of each RRH by adjusting per-RRH beacon transmit power. This alters:

• Coverage footprint – how far each RRH is visible as a candidate AP
• Cell edge location – which STA sees which RRH as the dominant beacon source
• Interference domains – how many RRHs mutually interfere for a given channel
• Candidate RRHs for grouping – beacon shaping influences which RRHs should share a queue

Beacon power is one of the most effective tools for dynamic RF cell shaping because it affects STA association and roaming decisions without modifying data-plane PHY rates. By lowering beacon power at certain RRHs and raising it at others, the concentrator can:

• Steer a STA toward a preferred RRH or RF group
• Increase isolation between RRHs to allow more independent airtime domains
• Reduce unnecessary overlap that causes hidden-node problems or collapses spatial reuse
• Stabilize spatial-stream structure by improving per-RRH dominance or diversity in the CSI

Traditional controller+AP systems attempt similar behavior but lack true shared state because each AP maintains its own queueing and PHY decisions. In Fi-Wi, beacon shaping is coordinated with:

• Current queue group assignments
• CSI-driven spatial-stream and eigenvector analysis
• Predicted load and collapse risk

This makes beacon power a first-class control variable in defining and stabilizing the boundaries of each cellularized RF domain.

4.6 Fronthaul Requirements and Feasibility

The Fi-Wi architecture requires deterministic, low-latency fronthaul links between the concentrator and RRHs. Because RRHs function as DMA engines accessing centralized packet memory (Section 4.4), Umber's implementation uses PCIe (PCI Express) over fiber rather than Ethernet. This section quantifies bandwidth, latency, and jitter requirements, and demonstrates that PCIe over fiber not only meets these requirements but provides superior performance compared to network-based alternatives.

4.6.1 Why PCIe Over Fiber?

The choice of PCIe over fiber instead of Ethernet is driven by the Fi-Wi architectural model:

RRHs as DMA engines: Each RRH directly reads packet descriptors from concentrator DRAM, fetches packet data, and writes received packets back to memory. This is native PCIe behavior—exactly how a network card or storage controller operates.

Latency advantage: PCIe avoids the network stack entirely:

• No TCP/IP processing
• No Ethernet framing/deframing
• No switch store-and-forward
• Direct memory-to-memory transfers

Determinism: PCIe provides guaranteed bandwidth allocation and predictable latency through:

• Hardware-enforced QoS
• Credit-based flow control (no packet drops)
• Transaction-level ordering guarantees

Simplicity: The RRH sees the concentrator's memory space directly. No protocol translation, no socket APIs, no network configuration.

4.6.2 PCIe Bandwidth Requirements

Each RRH requires bandwidth for:

1. Downlink packet DMA (concentrator → RRH)

For an RRH serving one or more STAs with aggregate capacity C_eff:

BWDL = Ceff · (1 + OHdesc)                    (4.1)

where OH_desc accounts for DMA descriptors, metadata, and PCIe TLP (Transaction Layer Packet) overhead (typically 10-20%).

Example: For C_eff = 600 Mbps (typical 802.11ax 2×2 MIMO) with OH_desc = 0.15:

BWDL = 600 · 1.15 = 690 Mbps

2. Uplink packet DMA (RRH → concentrator)

Typically symmetric or slightly higher than downlink due to ACKs and control frames:

BWUL ≈ BWDL · 1.1 ≈ 760 Mbps                   (4.2)

3. CSI and status updates

Channel State Information and MAC statistics are written to concentrator memory via PCIe:

BWCSI = Nsta · Nsc · Ntx · Nrx · Bsample · fCSI    (4.3)

For N_sta=4, N_sc=234, N_tx=2, N_rx=2, B_sample=24 bits, f_CSI=50 Hz:

BWCSI = 4.49 Mbps per RRH

4. Control and command traffic (concentrator → RRH)

Configuration updates, timing sync corrections, power/channel commands:

BWcontrol ≈ 1-5 Mbps per RRH                         (4.4)

Total bidirectional bandwidth per RRH:

BWtotal = BWDL + BWUL + BWCSI + BWcontrol           (4.5)
BWtotal ≈ 690 + 760 + 4.5 + 2 = 1456 Mbps ≈ 1.5 Gbps

4.6.3 PCIe Link Configuration

PCIe bandwidth is determined by generation and lane count:

Note: Effective bandwidth accounts for 128b/130b encoding (Gen 3+) and protocol overhead.

RRH link sizing: For 1.5 Gbps per RRH requirement:

• PCIe Gen 3 x1: 7.88 Gbps available → 5.2× margin per RRH ✓
• PCIe Gen 4 x1: 15.75 Gbps available → 10.5× margin per RRH ✓✓

A single PCIe Gen 3 x1 lane is sufficient per RRH with substantial headroom.

4.6.4 Concentrator PCIe Topology

The concentrator must aggregate multiple RRH connections. Consider a 50-RRH deployment:

Total aggregate bandwidth requirement:

BWaggregate = NRRH · BWtotal                      (4.6)
BWaggregate = 50 · 1.5 Gbps = 75 Gbps (peak)

With 40% average utilization (typical for building-wide traffic):

BWtypical = 75 · 0.40 = 30 Gbps

Architecture Options:

Option 1: PCIe switch fabric

• Use external PCIe switches (e.g., Broadcom PEX, Microchip Switchtec) to fan out.
• Pros: High port density.
• Cons: Adds a "hop" of latency (100-200ns); introduces head-of-line blocking if the uplink to CPU is oversubscribed.

Option 2: Multi-host server (Dual Socket)

• Standard dual-CPU server (e.g., Dual Xeon/EPYC).
• Pros: Massive lane count (128+ lanes).
• Cons: NUMA (Non-Uniform Memory Access). If a packet arrives on CPU1 but the processing queue is on CPU2's memory, the cross-socket traversal adds significant latency and jitter, violating L4S requirements.

4.6.5 PCIe Over Fiber: Physical Layer

Standard PCIe uses copper traces on motherboards (limited to ~30cm at Gen 3/4 speeds). To reach RRHs distributed throughout a building, PCIe signals are carried over fiber using optical transceivers.

Technologies:

1. Active Optical Cables (AOC)

• Integrated fiber + transceivers in cable assembly
• Plug directly into PCIe card slots
• Lengths: 5-100 meters typical
• Cost: $100-300 per cable depending on length/gen
• Latency: <1 µs additional vs. copper

2. Optical PCIe adapter cards

• PCIe card with optical SFP/QSFP cages
• Use standard single-mode or multi-mode fiber
• Lengths: up to 10km (SM fiber), 300m (MM fiber)
• Cost: $200-500 per endpoint card + $50-100 per transceiver + fiber
• More flexible for custom topologies

3. PCIe fabric extenders

• Protocol conversion (PCIe ↔ proprietary optical)
• Examples: Dolphin IXS600, One Stop Systems
• Support longer distances and more complex topologies
• Cost: $500-2000 per endpoint

Recommended approach for Fi-Wi: Optical PCIe adapter cards with standard fiber infrastructure, providing flexibility and leveraging commodity fiber installation.

4.6.6 Latency Analysis

PCIe over fiber latency components:

Comparison to Ethernet:

PCIe over fiber provides 5-10× lower latency than even optimized Ethernet, which is critical for the inner control loop (Section B) operating at 200-500 µs timescales.

4.6.7 Jitter and Determinism

PCIe's credit-based flow control eliminates congestion drops and provides deterministic latency:

• No packet loss: Sender only transmits when receiver has buffer credits
• No queuing jitter: Fixed transaction ordering
• Predictable latency: TLP latency = propagation + fixed processing

Measured jitter: PCIe over fiber typically exhibits <50 ns jitter, well under the 200 ns budget for 1 µs time synchronization (Section 4.1).

This determinism is impossible to achieve with Ethernet without time-sensitive networking (TSN) extensions, which add complexity and cost.

4.6.8 Distance Limitations

PCIe over fiber distance depends on optical budget and signal integrity:

Fi-Wi requirement: Building-scale deployments require ≤100 m reach, easily achieved with Gen 3/4 over multi-mode fiber or any generation over single-mode fiber.

4.6.9 Cost Analysis

PCIe over fiber cost per RRH:

Comparison to network alternatives:

PCIe over fiber costs moderately more than standard Ethernet but delivers 5-10× better latency and superior determinism. For Fi-Wi's DMA-based architecture, this cost is justified by the performance and architectural simplicity gains.

For context: a typical enterprise AP costs $500-2000, and a cellular small cell costs $1000-5000. The fronthaul cost is comparable to or less than the radio cost difference, making it economically viable.

4.6.10 Alternative: Hybrid PCIe + Ethernet

For deployments where PCIe over fiber infrastructure is unavailable, a hybrid approach is possible:

• Time-critical path: Use PCIe over fiber for DMA packet transfers
• Control plane: Use standard Ethernet for CSI, statistics, configuration

This reduces PCIe bandwidth requirements (only packet data, not CSI/control) and allows leveraging existing Ethernet infrastructure for non-latency-critical traffic.

However, the pure PCIe approach is architecturally cleaner and avoids the complexity of dual-protocol RRH implementation.

4.6.11 Comparison to Cellular Fronthaul Standards

For context, cellular systems use:

CPRI (Common Public Radio Interface):

• Carries digitized I/Q samples
• Bandwidth: 614 Mbps to 24 Gbps per radio
• Latency: <5 µs typical
• Protocol: Line-coded serial (not PCIe or Ethernet)

eCPRI (Enhanced CPRI) / Fronthaul Gateway:

• Functional split moves some PHY to RRH
• Bandwidth: 1-10 Gbps typical (10-20× less than CPRI)
• Transport: Ethernet-based
• Latency: 10-100 µs

Fi-Wi (PCIe over fiber):

• Full MAC/PHY at RRH (only Ethernet frames on fronthaul)
• Bandwidth: 1-2 Gbps per RRH (comparable to eCPRI)
• Transport: PCIe (native DMA)
• Latency: 2-5 µs (between CPRI and eCPRI, but with packet-level split)

Fi-Wi's functional split and PCIe transport provides a unique balance: lower bandwidth than CPRI, lower latency than eCPRI, and native integration with the DMA-based architecture.

4.6.12 Summary: PCIe Over Fiber Enables Fi-Wi Architecture

Why PCIe over fiber is the right choice for Fi-Wi:

1. Native DMA model: RRHs are DMA engines—PCIe is the natural transport
2. Lowest latency: 2-5 µs vs. 10-100 µs for Ethernet
3. Perfect determinism: Credit-based flow control eliminates jitter and drops
4. Architectural simplicity: No network stack, no protocol translation
5. Proven technology: Used in HPC, storage (NVMe-oF), and telecom

The deterministic, sub-5-microsecond fronthaul is what enables Fi-Wi's centralized control, time synchronization, and single-bottleneck queueing architecture. Unlike Wi-Fi mesh, controller-based systems with over-the-air backhaul, or even Ethernet-based approaches, PCIe over fiber provides the predictable substrate needed for the control loops described in Appendices A and B to operate with the precision required for sub-millisecond tail latency control.

          External Reference (Optional GPS/GNSS)
                       │
                       ▼
    ┌──────────────────────────────────────────────┐
    │            Fi-Wi Concentrator                │
    │     [ High-Stability Ocillator (OCXO) ]     │ ◄── Grandmaster (GM)
    │           (System Timebase t0)               │
    └──────────────────┬───────────────────────────┘
                       │ PCIe PTM / Hardware Sync
                       │ (Compensates for fiber flight time)
          ┌────────────┼─────────────┐
          ▼            ▼             ▼
    ┌───────────┐ ┌───────────┐ ┌───────────┐
    │   RRH 1   │ │   RRH 2   │ │   RRH 3   │      ◄── Slaves
    │ [LocalOsc]│ │ [LocalOsc]│ │ [LocalOsc]│
    │  Locked   │ │  Locked   │ │  Locked   │
    └─────┬─────┘ └─────┬─────┘ └─────┬─────┘
          │             │             │
          ▼             ▼             ▼
     Frequency-Coordinated Operation
    

┌──────────────────────────────────────────────────────────────────────────────┐
│                        RRH CLOCK DISTRIBUTION ARCHITECTURE                   │
└──────────────────────────────────────────────────────────────────────────────┘

        [ PCIe Over Fiber ]
                 │
                 │ (1) PTM Timestamps (Implicit Clock)
                 ▼
   ┌─────────────────────────────┐
   │      RRH FPGA / Retimer     │
   │   (Clock Recovery Circuit)  │
   └─────────────┬───────────────┘
                 │
                 │ (2) "Dirty" Recovered Clock (High Jitter)
                 ▼
   ┌─────────────────────────────┐           ┌─────────────────────────────┐
   │    JITTER ATTENUATOR IC     │           │    WI-FI 7 SOC (Client)     │
   │    (e.g., Si5395 / LMK05)   │           │                             │
   │                             │           │                             │
   │   ┌─────────────────────┐   │           │    ┌───────────────────┐    │
   │   │  Digital Servo Loop │   │ (3) Clean │    │   Internal PLL    │    │
   │   │      (DSPLL)        │───┼───────────┼───►│ (RF Synthesizer)  │    │
   │   └─────────────────────┘   │ 40 MHz    │    └─────────┬─────────┘    │
   │                             │ Reference │              │              │
   └─────────────────────────────┘           └──────────────┼──────────────┘
                                                            │
                                                            ▼
                                                   [ 5 GHz / 6 GHz ]
                                                   [ RF Carrier    ]
                                                   (Independent phase per RRH)
    

5. Control Architecture: The Dual-Integrator System

A rigorous control-theoretic analysis of Wi-Fi reveals a fundamental challenge: there are not one, but two distinct integrators in the transmit path. In traditional autonomous APs, these integrators are coupled in undefined ways, leading to instability (bufferbloat) and poor interaction with TCP congestion control. Fi-Wi explicitly separates these integrators, applies distinct control laws to each, and enforces a strict Time-Scale Separation to guarantee system stability.

5.1 The Two Integrators

To achieve stability, we must model and control two distinct accumulation processes:

1. The Outer Integrator (Group Queue): Located in the Concentrator. This accumulates packets based on the mismatch between arriving traffic (internet speed) and the wireless link capacity. It operates on the RTT timescale (milliseconds).
2. The Inner Integrator (Aggregation Buffer): Located logically between the Concentrator and RRH. This accumulates packets to build 802.11 A-MPDU aggregates for PHY efficiency. It operates on the TXOP timescale (hundreds of microseconds).

5.2 The Outer Loop: L4S and Group Queue Dynamics

The primary bottleneck managed by the AQM (Active Queue Management) is the Group Queue. This loop drives the end-to-end congestion control (L4S/TCP).

5.2.1 Queue Dynamics

The queue depth Q(t) evolves based on the mismatch between the arrival rate λ(t) and the effective service rate μ(t):

dQ/dt = λ(t - τ_fwd) - μ(t)

5.2.2 The PI² Control Law

Fi-Wi uses a PI² controller to calculate a marking probability \( p(t) \), targeting a shallow queue reference \( Q_{ref} \) (typically 200 µs). This provides a coherent signal to L4S senders:

p(t) = K_alpha * (Q(t) - Q_ref) + K_beta * ∫ (Q(t) - Q_ref) dt

5.3 The Inner Loop: MAC Aggregation and TXOPs

The Inner Loop manages the trade-off between PHY efficiency (large aggregates) and latency (small aggregates). In traditional APs, this integrator is effectively unbounded to maximize benchmark scores, creating a "sawtooth" latency pattern that confuses TCP.

Fi-Wi bounds this integrator via two mechanisms:

• Bounded TXOP Duration: Limiting TXOPs to ≈250 µs forces the aggregation integrator to discharge frequently (3–5 kHz).
• Bounded Aggregate Size: Limiting \( A_{max} \) ensures the "sawtooth" amplitude never exceeds the L4S latency budget.

5.4 System Integration: Time-Scale Separation

For the nested loops to remain stable, the Inner Loop must look like "constant service" to the Outer Loop. This requires the Inner Loop bandwidth (ω_mac) to be significantly higher than the Outer Loop bandwidth (ω_tcp):

ω_mac >> ω_tcp   (typically > 20:1 ratio)

5.4.1 Frequency Domain Constraint

By forcing the MAC to operate at a frequency of 3–5 kHz (via 250 µs TXOPs), the aggregation noise is pushed high enough that it is naturally filtered out by the TCP loop (which operates at 10–20 Hz).

5.4.2 A-MPDU Aggregation Coherence and ECN Marking Precision

The 250 µs TXOP constraint serves a dual purpose: it maintains time-scale separation and ensures L4S receives coherent ECN feedback. Traditional Wi-Fi's massive A-MPDU aggregation creates a fundamental mismatch between Layer 2 efficiency and Layer 3 control precision.

The Aggregation-Feedback Mismatch

In wide-channel deployments (160 MHz), APs build large A-MPDU aggregates containing dozens of IP packets to amortize MAC overhead. This creates three control-loop pathologies:

• Binary ECN Feedback: Instead of smooth, per-packet congestion signals, the sender receives bursts of marks (when the aggregate transmits) or extended silence (during assembly), violating the PI² controller's assumption of sub-RTT feedback granularity.
• Buffering-Induced Latency: Building efficient aggregates requires multi-millisecond buffering. This artificial delay appears as congestion to L4S senders, causing premature rate reduction even when the medium is idle.
• Sojourn Time Measurement Loss: Once packets enter hardware aggregation pipelines, per-packet queueing delay becomes invisible, preventing accurate ECN marking per RFC 9332.

Fi-Wi's Coherence Strategy

Fi-Wi resolves this through coordinated design:

1. 40 MHz Channel Width: Narrower channels require smaller aggregates, naturally increasing MAC service frequency. More frequent transmissions with smaller payloads ensure sojourn time measurement occurs at packet granularity.
2. Concentrator-Level ECN Marking: The Concentrator performs sojourn time measurement and ECN marking before handing packets to RRHs for PHY transmission, preserving microsecond-level queueing visibility.
3. Bounded TXOP Duration: The 250 µs maximum ensures MAC service frequency remains >10× higher than L4S control frequency (~1 RTT), enabling senders to interpret ECN marks as smooth probability signals rather than discrete bursts.

This approach maintains the benefits of A-MPDU efficiency while preserving the feedback coherence L4S requires. The result: DualQ can sustain its ~1ms target drain time without artificial inflation from aggregate assembly delays. For detailed analysis, see Appendix I.7.

5.4.3 Design Parameters for Stability

Fi-Wi uses these parameters to ensure the system remains critically damped:

6. Airtime Domains and Dynamic Queue Grouping

In Fi-Wi, the core rule is: there is one deep queue per independent airtime resource. The physical queue lives in concentrator memory, but it represents the airtime of one RRH or a dynamic group of RRHs whose RF signals are coupled strongly enough to behave like a single cell.

If two RRHs can interfere, they cannot transmit simultaneously and therefore must share a single logical queue. If RRHs are RF-isolated, each receives its own queue. This preserves the “one bottleneck per control loop” structure required by L4S.

6.1 Why airtime determines queue structure

Service at each queue corresponds to over-the-air transmission. Any RRHs that share RF space must share a service process and therefore share a queue. RRHs that do not interfere have independent airtime and get independent queues.

6.2 Forming airtime groups dynamically

Crucially, these RF groups and their queues are not static. The concentrator forms and maintains airtime domains dynamically using:

• Static provisioning from building layout / installer input as an initial guess
• Passive RF discovery (RSSI correlation, channel utilization, beacon strength)
• Runtime adaptation (retry bursts, rate shifts, noise-floor correlation, airtime logs, CSI)

Beyond simple interference, Fi-Wi’s groupings also consider the spatial structure of the channels:

• CSI reveals the dominant MIMO eigenvectors and eigenvalues between a set of RRHs and a set of STAs.
• Groups can be chosen so that RRHs in the same domain not only share airtime, but can jointly form useful spatial streams and nulls when coordinated.
• RRHs whose channels are nearly parallel for a given STA might be grouped differently from RRHs whose channels provide orthogonal eigenmodes.

Over time, the Fi-Wi system continuously adjusts:

• Which RRHs belong to the same airtime domain
• Which RRHs can be treated as isolated cells
• How much capacity is budgeted per domain, including how many effective spatial streams it can carry

Groups may merge if interference appears or split if RRHs become effectively isolated (e.g., after a channel change or power adjustment, including beacon power shaping). The AQM and ECN marking logic always runs at the current group queue, so L4S always sees a single, well-defined bottleneck per cellularized domain.

Because all RRHs expose real-time CSI, queue metrics, retry statistics, airtime usage, and beacon reports into the concentrator’s shared state, Fi-Wi can form RF groups that are tuned not just for coverage but for:

• Interference minimization
• Maximum usable spatial streams (eigenvector structure)
• Tail-latency behavior under L4S marking

6.3 Room-Level RRH Density (FTTR-Class Deployment)

Fi-Wi is not designed around a small number of big AP cells per floor. The architecture assumes something much closer to Fiber-to-the-Room (FTTR): one cell per room, with fiber or equivalent deterministic fronthaul feeding small RRHs in each room.

In higher-end deployments, each room can contain multiple RRHs (e.g., 2–4 per room) to support:

• Location services, using multi-angle phase and RSSI measurements across RRHs
• Multi-static sensing for occupancy, motion, and other sensing applications
• Increased spatial-stream or eigenmode diversity, enabling higher-rank MIMO than a single AP could offer
• Robust redundancy — automatic handovers or multipath transmission without STA involvement

This density dramatically improves RF control. With RRHs separated by just a few meters, the concentrator sees:

• Sharper CSI contrasts between RRHs
• More stable eigenvectors for multi-RRH coordination
• Finer-grained airtime-group detection
• Better prediction of collapse risk or interference coupling at the room level

Traditional AP-based architectures cannot achieve this cleanly because they lack shared state and maintain separate, isolated queues and PHY/MAC processes in each AP. Even with a central controller, they are limited to heuristic steering and static power/channel tweaks.

Fi-Wi, by contrast:

• Places the queues and packet memory in the concentrator, not in room APs
• Makes every RRH part of a shared state space driven by centralized timing, CSI, queueing, and scheduling
• Uses dynamic RF grouping to decide which RRHs are in the same airtime domain and which are isolated cells
• Treats multi-RRH-per-room deployments as an opportunity for richer spatial streams and sensing, not as a management headache

A cell-per-room architecture makes Fi-Wi fundamentally different from controller-based Wi-Fi: it behaves more like cellular small cells with centralized coordination than like a set of autonomous APs.

7. Queue Architecture for Fi-Wi

Fi-Wi centralizes packet memory, queueing, AQM, and TXOP scheduling inside the concentrator. Because the concentrator is the true bottleneck for all wireless transmissions, Fi-Wi can use a clean, minimal queue structure that behaves predictably under load and exposes stable delay semantics to L4S congestion controllers. This stands in contrast to traditional APs, where dozens of hidden queues (per-station, per-TID, firmware rings, retry/BA windows, PS-poll buffers, rate-control queues) produce variable and unobservable queueing delay.

This section describes Fi-Wi’s queue architecture, why WMM priority becomes largely unnecessary, and how centralized TXOP scheduling eliminates the stochastic contention that drives Wi-Fi collapse in legacy systems. The goal is simple: a minimal number of queues, explicit queue semantics, and predictable latency for all traffic classes.

7.1 Why queue architecture matters

Because all packets live in the concentrator’s memory until the moment they are transmitted over the air, Fi-Wi can explicitly control:

• exact queue depths per airtime domain,
• sojourn-time measurement for L4S AQM,
• TXOP length and pacing (typically 200–250 µs),
• which RRH transmits each TXOP, based on grouping and CSI.

This allows Fi-Wi to do what distributed APs cannot: construct a consistent, visible bottleneck queue that L4S congestion controllers can lock onto with stable behavior.

7.2 The theoretical case: L4S makes most priority obsolete

If queue delay is capped around 500 µs, legacy WMM categories provide little additional value. For example, consider a voice stream:

Voice codec: 80 bytes every 20 ms  (64 kbps)
Transmit time at 1 Gbps: ~0.64 µs
L4S queue target:        500 µs
Voice latency budget:    ~150,000 µs

Queue share: 500 / 150,000 = 0.3%

If L4S keeps queueing delay under ~500 µs, then all traffic — including voice — stays far inside its latency budget. WMM’s role in combatting bufferbloat disappears when bufferbloat itself is removed.

7.3 Practical complications

Three real-world issues motivate a cautious design:

• UDP does not respond to ECN

Voice and video often use UDP. They:

• do not slow down when marked with ECN,
• can starve TCP/QUIC if left unchecked,
• may need guardrails even when queue delay is low.

Fi-Wi can mitigate this using per-flow fair queuing inside the L4S queue, keeping UDP in check without needing a separate WMM hierarchy.

• Airtime vs. queue time

Total latency = Queue delay + Contention delay + TX delay + Retry delay
                    ^^^^^^^^^^^^
             L4S controls this

WMM historically manipulates AIFS, CW, and TXOP to reduce contention delay. Fi-Wi eliminates contention entirely using centralized TXOP scheduling, so WMM’s airtime hacks lose relevance.

• Failure modes and defense-in-depth

Even L4S can fail under:

• broken ECN in sender stacks,
• paths that zero or strip ECN bits,
• AQM or scheduler bugs during early rollout,
• extreme bursts that exceed control-loop bandwidth.

Hence, Fi-Wi benefits from a small amount of priority separation, at least in early deployments.

7.4 Minimal 3-queue structure

The theoretically sufficient minimal queue architecture for Fi-Wi is three queues:

• Management/Control Queue (Q_mgmt)
  Strict priority; beacons, probe responses, authentication, association, RTS/CTS, BA frames. Small, bounded, and never ECN-marked.
• L4S Queue (Q_L4S)
  ECT(1) traffic with dual-queue AQM; may use per-flow fair queuing internally.
• Classic Queue (Q_classic)
  ECT(0) and legacy traffic; part of the coupled AQM but with classic behavior.

                    ┌──────────────────────────────────────────┐
                    │               Concentrator               │
                    │ (Central Packet Memory • AQM • TXOP)     │
                    └──────────────────────────────────────────┘
                                   ▲
                                   │
                     ┌─────────────┼──────────────────┐
                     │             │                  │
                     │             │                  │
            ┌────────┴───┐   ┌─────┴─────┐    ┌───────┴──────┐
            │ Q_mgmt     │   │ Q_L4S      │    │ Q_classic     │
            │ (Strict    │   │ (ECT(1),   │    │ (ECT(0),      │
            │  priority) │   │  dual-Q)   │    │  classic)     │
            └──────┬─────┘   └─────┬─────┘    └──────┬────────┘
                   │               │                  │
                   └───────────────┼──────────────────┘
                                   │
                          TXOP Scheduler
                  (Build AMPDU • Select RRH • 200–250µs)
                                   │
         ┌─────────────────────────┼──────────────────────────┐
         │                         │                          │
     ┌───▼───┐               ┌─────▼─────┐              ┌─────▼─────┐
     │  RRH1 │               │   RRH2    │              │   RRH3    │
     │ (PHY) │               │  (PHY)    │              │  (PHY)    │
     └───────┘               └───────────┘              └───────────┘

In this design, WMM is unnecessary at the wireless bottleneck. All data traffic benefits from the same controlled queue delay, and fairness is enforced by per-flow scheduling rather than EDCA.

7.5 Pragmatic 5-queue structure

A more conservative deployment uses five queues per airtime domain:

1. Q_mgmt — Management & control (strict priority)
2. Q_L4S-hi — High-priority L4S (voice, control)
3. Q_classic-hi — High-priority classic (legacy VoIP)
4. Q_L4S-be — L4S best-effort (bulk QUIC/TCP)
5. Q_classic-be — Classic best-effort (legacy devices)

                       ┌───────────────────────────────────────────┐
                       │                Concentrator                │
                       │  (Central Packet Memory • AQM • TXOP)      │
                       └───────────────────────────────────────────┘
                                   ▲
                                   │
          ┌─────────────── Five Logical Queues Per Airtime Domain ────────────────┐
          │                                                                        │
    ┌─────┴─────┐   ┌─────────┬──────────┬──────────┬──────────┬─────────┬────────┘
    │ Q_mgmt     │   │ Q_L4S-hi│ Q_classic-hi│ Q_L4S-be │ Q_classic-be │
    │ (priority) │   │ (Voice) │ (Legacy VoIP) │ (Bulk TCP/QUIC) │ (Legacy bulk) │
    └─────┬──────┘   └──────┬──────────────┬──────────────┬──────┘
          │                 │              │              │
          └─────────────────┼──────────────┼──────────────┘
                            │
                      TXOP Scheduler
                (Build AMPDU • Select RRH • Delay Targets)
                            │
      ┌─────────────────────┼──────────────────────────┐
      │                     │                          │
   ┌──▼───┐            ┌────▼────┐                 ┌────▼────┐
   │ RRH1 │            │ RRH2    │                 │ RRH3    │
   │ (PHY)│            │ (PHY)   │                 │ (PHY)   │
   └──────┘            └─────────┘                 └─────────┘

7.6 Numerical examples

Consider 10 simultaneous HD video calls (~20 Mbps total) plus a saturating background TCP flow:

Legacy WMM:

• Voice/video in AC_VI or AC_VO.
• Bulk traffic in AC_BE.
• Queues: video ~10 ms, best-effort ~100 ms under load.

Fi-Wi with L4S + fair queuing:

• 20 Mbps / 1 Gbps ≈ 2% of airtime.
• Queue held near 500 µs.
• Voice/video see ≈10–20 µs queue contribution after fair-share weighting.

This is roughly 1000× lower queueing latency than legacy WMM systems, and it applies to all traffic, not only traffic in a “priority” AC.

7.7 Deployment strategy

Fi-Wi can phase its queue structure over time:

• Phase 1 (Conservative): 5-queue system for operator comfort and defense-in-depth.
• Phase 2 (Aggressive): collapse to the minimal 3-queue system once production evidence confirms L4S stability across real workloads.

Metrics to monitor include:

• Voice MOS under background load,
• p99/p999 latency for all flows,
• video stall rates,
• behavior under intentional overload tests.

7.8 WMM support in Fi-Wi

WMM exists to correct three historical problems in distributed Wi-Fi:

• Bufferbloat (queues growing into tens or hundreds of milliseconds),
• UDP starving TCP due to non-responsive senders, and
• stochastic EDCA contention that produces unfair and unpredictable airtime.

Fi-Wi removes the root causes of these behaviors:

• Queueing lives exclusively in the concentrator, tightly bounded (200–500 µs).
• Per-flow fair queuing inside the L4S queue prevents UDP starvation.
• Centralized TXOP scheduling eliminates EDCA contention entirely.

Because of this, full WMM support at the air bottleneck is not necessary. However, Fi-Wi does support WMM semantics for:

• policy compatibility with existing enterprise QoS frameworks,
• client expectations (e.g., phones marking DSCP=EF),
• defense-in-depth during overload or L4S misbehavior.

Fi-Wi handles WMM as an admission-time mapping:

• WMM voice/video → high-priority L4S or Classic queues, depending on ECN capability.
• WMM best-effort → Q_L4S-be or Q_classic-be.
• WMM background → Classic best-effort.

This preserves compatibility while avoiding the complexity and unpredictability of EDCA-based priority systems. Over time, Fi-Wi deployments can rely on pure L4S semantics and collapse WMM to a compatibility shim, not a required scheduling mechanism.

7.9 Summary

Fi-Wi’s centralized queue architecture enables:

• a minimal 3-queue design (management, L4S, classic),
• a pragmatic 5-queue variant for early deployment,
• predictable delay semantics compatible with L4S,
• elimination of WMM’s complexity and EDCA’s stochastic behavior,
• clean integration with centralized TXOP scheduling.

Traditional Wi-Fi uses WMM to work around bufferbloat and contention. Fi-Wi removes those problems entirely through tight queue control, shared state, and central scheduling. Priority becomes a policy choice — not a crutch for an unstable MAC.

In Fi-Wi, the Carve-Out ensures the voice packet (L4S) bypasses the accumulated Classic bulk data completely. The file download continues to saturate the link, but the latency of the L4S flow is decoupled from the load of the Classic flow.

• Classic View: "I am getting 950 Mbps, and my ping is 20ms."
• L4S View: "I am getting 50 Mbps, and my ping is 1ms."
• Result: Both flows coexist on the same RF channel without the bulk flow destroying the real-time flow.

8. RRH-Level Active Redundancy

Fi-Wi’s centralized shared state across RRHs makes it natural to treat multiple radios as an active redundant set for the same STA or room. This is analogous in spirit to 802.11be’s Multi-Link Operation (MLO), where a single multi-link device (MLD) can use multiple links for reliability and capacity. In Fi-Wi, the concentrator is the coordination point leveraging shared state, and the RRHs are the distributed radios providing multiple RF paths.

8.1 Uplink: Duplicate Reception & Diversity

In many deployments, a client STA will be audible at more than one RRH (overlapping coverage). On the uplink, Fi-Wi exploits this spatial diversity to improve reliability without requiring changes to the client.

1. Multi-Point Reception: Multiple RRHs may receive the same MPDU from a transmitting STA, potentially at different SNR/MCS levels.
2. Forwarding: Each RRH decodes the frame locally. If the Frame Check Sequence (FCS) passes, the RRH timestamps the frame (using the shared global timebase), attaches metadata (RSSI, SNR, Channel State Information), and forwards it to the Concentrator via the PCIe-over-Fiber link.
3. Post-Detection Selection: Effectively, the Concentrator acts as a Post-Detection Selection Diversity combiner:
   • Identification: The Concentrator buffers incoming frames for a defined window (e.g., 100 µs) and identifies duplicates by matching the Source MAC and 802.11 Sequence Control fields (Sequence Number + Fragment Number).
   • Selection: If multiple RRHs capture the same frame successfully, the Concentrator compares their metadata and forwards only the single copy with the highest SNR, discarding the others.

This approach leverages the spatial diversity of distributed RRHs to mitigate shadowing and multipath fading. Because the selection logic operates on valid MAC frames (after FCS verification) rather than raw I/Q samples, this architecture maintains compatibility with standard COTS Wi-Fi silicon at the Radio Head.

8.2 Downlink: per-packet steering

On the downlink, the concentrator can treat multiple RRHs as candidate transmitters for a given STA or room:

• Each downlink packet is enqueued once in the group queue for that airtime domain.
• The scheduler assigns the corresponding TXOP to one RRH (or occasionally duplicates across two RRHs) based on:
  • Recent CSI and SNR from each RRH to that STA
  • Per-RRH load and airtime usage
  • Policy (reliability vs. capacity vs. isolation)

This gives Fi-Wi:

• Per-packet (or per-TXOP) steering between RRHs, with the group queue as the single source of truth for the flow.
• Fast failover: if one RRH degrades (noise, hardware issue), the scheduler can switch the STA’s downlink traffic to another RRH in the same cellularized domain without changing IP or transport state.

8.2.1 Listen-Before-Talk (LBT) and RRH Eligibility for Downlink Scheduling

In a multi-RRH Fi-Wi deployment, each radio head operates on the same BSSID and channel but sits in a different physical location with its own RF conditions. While Fi-Wi centralizes all queueing and scheduling decisions, every RRH must still obey the fundamental 802.11 rule: listen-before-talk (LBT).

This is where Fi-Wi diverges sharply from classical multi-AP systems. In UniFi, Ruckus, Aruba, and all controller-based Wi-Fi architectures, each AP queue is blind to the RF medium state until it attempts to transmit. The AP commits a packet to the hardware queue, and if the medium is busy, the packet waits (Head-of-Line blocking) while the AP performs backoff.

Fi-Wi inverts this. RRHs continuously report their LBT Eligibility Status (Clear/Busy) to the Concentrator via the high-speed telemetry path. RRHs report LBT eligibility status via PCIe telemetry with update intervals of 100–500 µs, well-matched to inter-TXOP scheduling decisions. While the Concentrator cannot react within a single 9µs backoff slot, it operates on the Inter-TXOP timescale (200–500 µs¹).

Before posting a new DMA descriptor to an RRH, the Scheduler checks this eligibility:

• Eligible: The RRH reports the medium is statistically idle. The Concentrator posts the descriptor, "priming" that RRH for immediate transmission.
• Ineligible: The RRH reports heavy interference or high Energy Detect (ED). The Scheduler skips this RRH and routes the descriptor to an alternative RRH in the same airtime domain that reports clear air.

This prevents Head-of-Line Blocking where a packet sits in a hardware queue on a jammed radio. When multiple RRHs report clear airtime, Fi-Wi selects among them based on link quality (CSI) and predicted airtime efficiency. Conversely, if all RRHs report medium-busy, no RRH is primed; the scheduler pauses the flow to prevent backpressure from accumulating in the RRH hardware, keeping the queue depth visible in the Concentrator where L4S can measure it.

The result is a form of Centralized Selection based on LBT Eligibility. Multi-AP systems coordinate configuration (channels, power), but they cannot coordinate transmit starts because they lack the real-time feedback loop to steer packets away from busy radios before they are queued.

¹ Representative scheduling interval for mixed traffic workloads; actual TXOP durations range from tens of microseconds (small frames) to several milliseconds (large aggregates). ↩

                        (Shared RF / Airtime Domain)

       +----------------------+                 +----------------------+
       |      RRH-A           |                 |      RRH-B           |
       |  (Room / Zone A)     |                 |  (Room / Zone B)     |
       +----------------------+                 +----------------------+
       |  LBT: Clear          |                 |  LBT: Busy (ED high) |
       |  Eligible = YES      |                 |  Eligible = NO       |
       +----------+-----------+                 +-----------+----------+
                  |                                           |
                  |  Fiber fronthaul (low latency)            |
                  |                                           |
                  v                                           v

                     +-----------------------------------+
                     |  Fi-Wi Concentrator / Scheduler   |
                     +-----------------------------------+
                     |  Centralized queue for building   |
                     |  L4S feedback / congestion state  |
                     |                                   |
                     |  Decision: Post Descriptor to A   |
                     |  (RRH-B flagged as jammed/ineligible|
                     |   prevents HoL blocking)          |
                     +----------------+------------------+
                                      |
                                      | Downlink frames / aggregates
                                      v

                               +--------------+
                               |   Client(s)  |
                               +--------------+
  

Time →
------------------------------------------------------------------------------------------------->

RRH-A (Room A):        [ Sense medium ]  [ Idle ]  [ Clear ]  [  Transmit TXOP  ]  [ Idle ... ]
                       |<-- DIFS --->|   |<---- contention window (few slots) ---->|

RRH-B (Room B):        [ Sense medium ]  [  ED high: medium busy  ]  [ Backoff ... ]
                       |<---- busy ---->|

RRH LBT → Scheduler:       A: "Clear"                  B: "Busy"

Scheduler View:        [ Receive LBT states from A, B ]
                       [ Mark A = eligible, B = ineligible ]
                       [ Dequeue next packets from central queue ]
                       [ Post descriptor to RRH-A only ]

Downlink Action:       RRH-A receives descriptor, enters backoff, wins, transmits.
                       RRH-B remains silent (no descriptor posted).

Effect:                • No packet trapped in RRH-B's buffer
                       • No exponential backoff storm
                       • Deterministic selection of the RRH with clear airtime
  

8.3 Analogy to Wi-Fi 7 MLO

802.11be MLO allows a multi-link device (AP/STA) to use multiple links (e.g., 2.4G, 5G, 6G bands or channels) under a single MAC entity. Features include:

• Link aggregation: parallel links for higher throughput.
• Link redundancy: multi-link duplication for reliability.
• Per-packet steering: send each frame on the “best” link.

Fi-Wi provides a similar effect at the building scale, but with important differences:

• The coordination point is the Fi-Wi concentrator using shared state, not co-located with any single AP.
• The “links” are RRHs connected by deterministic fiber (or similar fronthaul) to the concentrator.
• The same centralized queues and L4S/AQM logic govern all RRHs in a cellularized domain.

Because the RRHs are spatially distributed around rooms and hallways, Fi-Wi gains advantages that co-located antennas cannot provide:

• More selection options: The Concentrator can choose from multiple spatially separated RRHs, each seeing different channel conditions to any given client
• Macro-diversity: Uplink transmissions received by multiple RRHs provide selection diversity that improves reliability at cell edges
• Spatial reuse opportunities: RRHs in different rooms can reuse the same channel when spatial isolation is sufficient (>25 dB attenuation)
• Better coverage uniformity: Multiple distributed RRHs eliminate dead zones and coverage gaps that single APs create

These advantages come from intelligent packet routing and dynamic RRH selection, not from RF phase coordination or simultaneous beamforming across RRHs.

8.3.1 Fi-Wi vs Wi-Fi 7 MLO: Compliance and Control

Fi-Wi strictly adheres to local regulatory compliance. The Concentrator manages the queue and the schedule, but the RRH manages the compliance.

When the Scheduler assigns a TXOP to an RRH, it posts a descriptor. The RRH hardware then performs standard 802.11 EDCA:

1. It senses the medium.
2. It draws a random backoff counter.
3. It counts down only when the medium is idle.
4. It transmits when the counter reaches zero.

The Architectural Difference:

In MLO or Mesh: If an AP commits a packet to a radio and that radio hits congestion, the packet is trapped in the local buffer. The backoff might take 50ms. During this time, the AP's other radios (or other APs in the mesh) might be idle, but they cannot help because the packet is already "owned" by the busy MAC.

In Fi-Wi: The packet remains in the Concentrator's central memory until the last possible moment (see Appendix F). If the Concentrator sees an RRH entering deep backoff (via real-time telemetry) or reporting "Busy," it stops posting new descriptors to that RRH and steers subsequent traffic to a free RRH. The backoff engine remains local (compliance), but the queue feeding it is steered globally (performance).

This allows Fi-Wi to scale airtime domains across an entire building while preventing the multi-node contention collapse that plagues traditional Wi-Fi networks.

Wi-Fi 7 MLO: per-radio queues and MAC logic           Fi-Wi: one centralized queue per airtime-domain
================================================      ===============================================

   Airtime-domain                                    Airtime-domain
   --------------                                    --------------

   +-------------+   +-------------+                +-------------------------+
   |  Radio 1    |   |  Radio 2    |                |   Fi-Wi Concentrator    |
   | MAC engine  |   | MAC engine  |                |  (per airtime-domain)   |
   | Backoff     |   | Backoff     |                +-------------------------+
   | DMA queues  |   | DMA queues  |                |  Centralized queue      |
   +------+------+   +------+------+                |  AQM / L4S feedback     |
          |                 |                       |  Scheduler              |
          |                 |                       +-----------+-------------+
          v                 v                                   |
   Packet trapped          Packet trapped                       |
   in local queue          in local queue                       |
   during backoff          during backoff                       v

                                                     +--------+-------+    +--------+-------+
                                                     |   RRH A        |    |   RRH B        |
                                                     | RF front-end   |    | RF front-end   |
                                                     | LBT + backoff  |    | LBT + backoff  |
                                                     +--------+-------+    +--------+-------+
                                                              ^                    ^
                                                              |                    |
                                                   Scheduler posts descriptor only to
                                                   the RRH that is clear and eligible.

  

8.4 Preserving the "single bottleneck" L4S view

To keep L4S happy, Fi-Wi needs to preserve a single bottleneck queue per flow even while using multiple RRHs:

• If two RRHs are in the same RF airtime group, they share the same group queue and marking logic. Uplink redundancy and downlink dynamic point selection do not create multiple bottlenecks — they just add spatial diversity and selection options within the same queue.
• If two RRHs are in different airtime domains (e.g., different channels or sufficiently isolated), the concentrator typically designates one domain as the primary bottleneck for that flow and uses the other only for failover or low-rate redundancy, to avoid creating competing bottlenecks for the same traffic.

In other words:

• Redundancy and spatial diversity are RF-level; queuing discipline remains centralized and unique per flow/domain.
• L4S still sees a single marking point (the group queue) for each path its packets traverse.

9. Dynamic Point Selection and Intelligent Frequency Reuse

Traditional Wi-Fi deployments suffer from two fundamental problems in high-density environments: (1) clients are statically associated to a single AP based on initial connection, leading to suboptimal performance as they move, and (2) autonomous APs compete for airtime through CSMA/CA contention, creating interference. Fi-Wi inverts this paradigm through Dynamic Point Selection—continuously choosing the optimal RRH per packet—and Intelligent Frequency Reuse—leveraging spatial isolation to maximize capacity.

9.1 Dynamic Point Selection: The Core Capability

Unlike traditional Wi-Fi where clients are physically and logically tied to a single Access Point (AP), Fi-Wi treats the entire building as a single Virtual Cell. The Concentrator maintains real-time Channel State Information (CSI) from all RRHs and dynamically selects the optimal transmission point for each individual packet.

9.1.1 The Roaming Paradigm Shift: Negotiation vs. Execution

To understand the magnitude of this shift, we must compare the standard "Fast BSS Transition" (802.11r) with the Fi-Wi approach. In standard Wi-Fi, mobility is a negotiation. In Fi-Wi, it is an execution.

While 802.11r is sufficient for buffered video (Netflix), it typically breaks real-time applications like Voice over Wi-Fi (VoWiFi) and VR/XR, where a 50ms gap causes audio dropouts or visual artifacts. Fi-Wi's sub-millisecond switching ensures true continuity.

9.1.2 How It Works

• Continuous CSI Ingestion: The Concentrator constantly reads memory-mapped uplink metadata (RSSI, SNR) from all RRHs. This is not a periodic report, but a real-time stream of the physical environment.
• Per-Packet Decision: For each downlink packet, the Scheduler examines current conditions and selects the RRH with the best channel to that specific client.
• Instant Routing: The packet is DMA-transferred via fiber to the selected RRH, which performs standard CSMA/CA and transmits.
• Seamless Adaptation: As the client moves or RF conditions change (e.g., a door closes), the Concentrator automatically switches to a different RRH.

9.1.3 Example Scenario

Consider "Alice" on a VR headset walking down a hallway:

1. Alice starts a session in Room 304 (near RRH-A: RSSI -40 dBm). The Concentrator routes packets via RRH-A.
2. Alice walks toward the doorway. RRH-A degrades (-55 dBm) while the hallway unit, RRH-B, improves (-45 dBm).
3. The Concentrator detects this crossing point in the CSI data.
4. For the very next packet, the pointer switches to RRH-B.
5. Result: Alice's VR stream continues without a single dropped frame or latency spike. She is unaware that the transmission point changed.

9.3 Intelligent Frequency Reuse

In traditional Wi-Fi, neighboring APs on the same channel create co-channel interference. The standard solution is to assign different channels (e.g., AP-A uses Channel 36, AP-B uses Channel 48), but this wastes spectrum. Fi-Wi enables intelligent frequency reuse—using the same channel across multiple RRHs when spatial conditions allow.

When Frequency Reuse Works

Frequency reuse is viable when clients are in spatially separated locations with significant isolation (typically >25-30 dB attenuation due to walls, floors, or distance).

Example: Adjacent Rooms

• Client A in Room 304 (served by RRH-A, RSSI: -42 dBm)
• Client B in Room 305 (served by RRH-B, RSSI: -45 dBm)
• Cross-coupling: RRH-A → Client B = -75 dBm, RRH-B → Client A = -78 dBm
• Isolation: ~30-33 dB (wall attenuation)

The Fi-Wi Decision:

1. Concentrator detects >30 dB spatial isolation via CSI measurements
2. Configures both RRH-A and RRH-B to operate on Channel 36
3. Each RRH performs independent CSMA/CA in its local environment
4. Cross-interference is minimal due to spatial isolation
5. Result: Effective channel capacity is doubled without requiring additional spectrum

Dynamic Adaptation

The key advantage over static channel planning is real-time adaptation:

• Movement Detection: If Client A moves toward doorway, cross-coupling increases (e.g., -75 dBm → -55 dBm)
• Automatic Response: Concentrator detects degraded isolation via updated CSI
• Mitigation Options:
  • Switch one RRH to different channel (Channel 36 → Channel 48)
  • Use time-division: Alternate which RRH transmits in each TXOP window
  • Apply dynamic point selection: Route all traffic through whichever RRH provides best path to both clients

Why Autonomous APs Cannot Do This

9.4 Transparent Integration with L4S

The complexity of dynamic point selection and frequency reuse is hidden from the L4S congestion control loop. Traffic still lives in per-airtime-domain group queues. When the Concentrator enables frequency reuse or optimizes RRH selection, it simply affects the effective service rate μ(t) of the queue.

The PI² controller in the outer loop (see Section 5) sees the queue draining faster and naturally reduces ECN marking. This allows L4S senders (TCP Prague) to ramp up their congestion windows to fill the expanded capacity. The system automatically discovers and exploits available spatial capacity without requiring changes to congestion control algorithms or application awareness.

Level 1: Deterministic (Hard)
   [ 802.11ax Trigger Frames ] ──▶ STA must wait for Schedule
                                    (Zero contention)

Level 2: Transport (Adaptive)
   [ L4S / ECN Marking ] ────────▶ OS Kernel throttles pacing
                                    (Reduces MAC load before enqueue)

Level 3: RF Physics (Steering)
   [ Beacon Power Shaping ] ─────▶ STA firmware seeks new cell
                                    (Moves demand to different domain)

Level 4: Statistical (Soft)
   [ WMM / AIFS Parameters ] ────▶ STA adjusts backoff aggression
                                    (Statistical deprioritization)
    

9.6 What Dynamic Point Selection Does NOT Enable

To maintain technical accuracy, it is important to clarify what Fi-Wi's dynamic point selection does not provide:

• Not Distributed MIMO: Fi-Wi does not perform simultaneous coherent transmission from multiple RRHs. Each transmission originates from a single selected RRH.
• Not Beamforming: While the Concentrator selects the optimal RRH, it does not control RF phase or perform spatial multiplexing across RRHs. Each RRH operates independently.
• Not Coordinated Simultaneous Transmission: When using frequency reuse, each RRH performs independent CSMA/CA. There is no explicit scheduling or coordination of transmission timing—the coordination comes from routing decisions and channel assignments.

These capabilities would require either:

• Custom ASIC development with externally-controllable RF synthesizers (for phase-coherent MIMO)
• Or extensive firmware modification to enable TSF-scheduled transmission (regulatory challenges in unlicensed spectrum)

Fi-Wi's architecture deliberately focuses on capabilities achievable with COTS Wi-Fi chips, providing 2-3x capacity improvement through intelligent management rather than pursuing 4-6x gains that would require custom silicon development.

9.7 Performance Expectations

Based on the capabilities described above, Fi-Wi provides the following performance improvements over traditional autonomous AP deployments:

• 2-3x Capacity Increase: Through intelligent frequency reuse and reduced CSMA/CA contention
• 50-80% Latency Reduction: Via dynamic point selection eliminating handoff delays
• 90%+ Cell Edge Reliability: Through selection diversity on uplink
• Zero Handoff Delay: Seamless mobility without 802.11 reassociation

These gains are achieved through centralized intelligence and microsecond-latency fronthaul, not through RF phase control or coordinated transmission. The architecture remains fully compliant with unlicensed spectrum regulations and works with commodity Wi-Fi chipsets.

9.8 Summary

Fi-Wi transforms the problem of wireless density by treating it as a routing and scheduling problem rather than an RF coordination problem. By centralizing packet memory and MAC scheduling, Fi-Wi converts adjacent radios from interferers into dynamically selected access points, allowing the network to scale capacity through intelligent management rather than collapsing under interference.

The key insight is that most Wi-Fi performance problems stem from poor decisions (wrong AP, wrong channel, wrong timing) rather than fundamental RF limitations. Fi-Wi solves this by providing the Concentrator with complete visibility and control, enabling microsecond-granularity optimization that autonomous APs cannot match.

10. Fi-Wi value vs. Traditional Distributed APs

Modern enterprise Wi-Fi deployments use centralized controllers (Cisco WLC, Aruba Mobility Controller, Ubiquiti UniFi, Ruckus SmartZone, etc.) to manage multiple APs. These controllers coordinate the control plane: channel assignment, transmit power, client association hints, roaming policies, and security. However, these remain loosely-coupled systems where the data plane — queueing, MAC scheduling, aggregation, and packet memory — remains distributed inside individual APs.

A traditional AP is not just “running EDCA.” It is running EDCA after juggling dozens or hundreds of logical MAC queues and state machines:

• Per-station queues (one or more per associated STA)
• Per-TID / per-WMM-class queues (4–8 AC/TIDs per station)
• Firmware queues for rate control, reordering, and AMPDU assembly
• Internal MAC hardware ring buffers for TX/RX DMA
• Rate-control queues tracking MCS and retry history
• PS-poll / U-APSD buffered-traffic queues for sleeping stations
• BAR/BA state (BlockAck windows of outstanding MPDUs)

With N stations, an AP can easily have on the order of N × (4–8) logical queues behind a single RF channel. Every AP in the same RF domain runs this large, isolated, queue-filled state machine independently. No AP has a global view; controllers see only coarse statistics.

The result:

• The bottleneck is smeared across many hidden queues, so L4S cannot see or control it.
• APs make inconsistent decisions, so collapse emerges at different times across APs.
• AP-side buffering encourages long TXOPs when an AP finally wins the medium, driving multi-millisecond bursts.

Fi-Wi is fundamentally different: it centralizes both control plane and data plane with shared state across all RRHs. The concentrator does not just configure RRHs; it directly manages their queues, schedules their TXOPs, maintains unified CSI and airtime state, and applies coordinated ECN marking for each airtime domain. This architectural difference — not just improved control-plane coordination — is what enables Fi-Wi’s latency, L4S, and spatial multiplexing advantages.

┌──────────────────────────── Traditional Distributed AP ───────────────────────────┐
│                                                                                   │
│  Many MAC queues hidden inside each AP:                                           │
│                                                                                   │
│    ┌─────────────┐  ┌─────────────┐  ┌─────────────┐                              │
│    │ STA 1 TID   │  │ STA 2 TID   │  │ STA N TID   │   ... (N stations × 4–8 TIDs)│
│    │ Queues      │  │ Queues      │  │ Queues      │                              │
│    └─────┬───────┘  └─────┬───────┘  └─────┬───────┘                              │
│          │                │                │                                      │
│   ┌──────▼────────────────▼────────────────▼──────────┐                           │
│   │   Firmware Queues (Aggregation, Reorder, BAR/BA)  │                           │
│   └───────────┬───────────────────────────────────────┘                           │
│               │                                                                   │
│   ┌───────────▼──────────────┐                                                    │
│   │ Hardware MAC Ring Buffers│   (TX/RX DMA)                                      │
│   └───────────┬──────────────┘                                                    │
│               │                                                                   │
│   ┌───────────▼──────────────┐                                                    │
│   │ EDCA / CSMA-CA Contention│   (Per-AP, no coordination)                        │
│   └───────────┬──────────────┘                                                    │
│               │                                                                   │
│        Long, multi-ms TXOP bursts, inconsistent ECN, early collapse               │
│                                                                                   │
└───────────────────────────────────────────────────────────────────────────────────┘
  

The following subsections detail specific benefits of Fi-Wi’s cellularized, tightly-coupled architecture compared to controller-managed, loosely-coupled AP systems.

10.1 Deterministic low latency

Traditional APs:

Each AP builds its own local queues. Under load, large aggregates, retries, and hidden buffering produce multi-millisecond queueing and service delays. Tail latency is largely uncontrolled, and varies across APs sharing the same channel.

Fi-Wi (cellularized Wi-Fi, cell-per-room):

• There is exactly one deep queue per airtime domain (RF group of interfering RRHs), not per AP.
• That queue is fully visible and centrally controlled in the concentrator.
• Sojourn-time or PI2-style control targets sub-millisecond delay (e.g., 200–400 µs) including tails.
• Concentrator pacing prevents upstream buffers from filling while respecting L4S behavior.

10.2 Stable L4S behavior

Traditional APs:

L4S flows traverse multiple hidden queues: wired bottlenecks, AP-local queues, firmware queues, and EDCA contention. ECN marking (if it exists at all) is inconsistent and not tied to a single bottleneck. Collapse produces noisy, bursty marking or loss, and the L4S control loop becomes oscillatory or falls back toward classic congestion behavior, especially in the tails that matter to users.

Fi-Wi:

• There is exactly one main marking point per airtime domain — the centralized group queue.
• ECN marks are proportional to queue delay (sojourn time / PI2) in that queue.
• The control loop sees a small number of well-behaved bottlenecks, which is precisely the design assumption behind L4S.

10.3 Aggregation without losing visibility

Traditional APs:

Aggregation improves PHY efficiency but hides individual packet timing from the congestion controller. The controller does not know which MSDUs were grouped into a TXOP, what the queue state was when the TXOP started, or how long each device has been waiting.

Fi-Wi:

• Aggregation is retained for efficiency, but the concentrator knows which MSDUs shared a TXOP.
• The queue state at TXOP start is known for each cellularized domain.
• ECN marks can be assigned within aggregates in a controlled way, preserving fine-grained congestion information.

This combination yields high PHY efficiency and transport-layer visibility into congestion, instead of having to choose one or the other.

10.4 Building-scale coordination

Controller-managed loosely-coupled APs:

The controller can adjust channels, power, and send steering hints (e.g., 802.11v), but it cannot see or control:

• Per-packet queue states across APs — each AP's queue depth, sojourn times, and retries remain opaque to the controller.
• MAC aggregation and TXOP decisions — each AP independently decides when to send aggregates and how long TXOPs last.
• Real-time CSI or spatial stream structure — CSI stays local to each AP's antenna array; the controller sees only coarse stats ("MCS 9, 80 MHz").
• Cross-AP packet routing — the controller cannot dynamically route individual packets to different APs based on instantaneous RF conditions.
• Coordinated frequency reuse — APs cannot adapt channel usage in real-time based on spatial isolation measurements.

As a result, these systems rely on heuristic, reactive policies: channel reassignment after interference is observed, power adjustments based on neighbor reports, and client steering using RSSI or airtime snapshots. These help, but they operate on coarse time scales (seconds to minutes) and cannot fix the fundamental data-plane issues of distributed queues, MAC contention, and tail latency under load.

Fi-Wi cellularized architecture:

The concentrator maintains true shared state across all RRHs in the building:

• Centralized queues per airtime domain — every packet's enqueue time, queue depth, and marking state is visible.
• Unified timestamp reference — µs-accurate synchronization enables precise sojourn-time measurement and coordinated scheduling.
• Aggregated CSI from all RRHs — the concentrator sees channel quality from every RRH to every active STA, enabling dynamic point selection.
• Coordinated MAC scheduling — TXOP timing, aggregation policies, and RRH selection are decided centrally with full visibility.
• Dynamic RF grouping — RRH-to-queue assignments adapt in real time based on measured interference, CSI, and load conditions.
• Dynamic point selection — each packet is routed to the optimal RRH based on current channel conditions, providing seamless mobility and selection diversity.

Because RRHs are distributed in space (often 2–4 per room in high-density deployments), Fi-Wi can leverage spatial separation for intelligent frequency reuse. The concentrator sees CSI from all RRHs and can make microsecond-granularity decisions about which RRH should transmit each packet — all while preserving the "single bottleneck queue per airtime domain" discipline required for stable L4S behavior.

┌─────────────────────────── Fi-Wi Cellularized Architecture ────────────────────────────┐
│                                                                                        │
│     One deep queue per airtime domain                     Shared CSI + µs timestamps   │
│                                                                                        │
│          ┌───────────────────────────────────────────┐                                 │
│          │ Centralized Airtime-Domain Queue (ECN AQM)│◄──────────┐                     │
│          └───────────────────┬──────────────────────┘            │                     │
│                              │                                   │                     │
│   ┌──────────────────────────▼──────────────────────────┐        │                     │
│   │   Concentrator Scheduler (L4S, TXOP, RF Grouping)   │◄───────┘                     │
│   │        Dynamic Point Selection per Packet           │                              │
│   └───────────────┬─────────────────────────┬───────────┘                              │
│                   │                         │                                          │
│       PCIe/Fiber  │                         │   PCIe/Fiber                             │
│                   │                         │                                          │
│   ┌───────────────▼─────────────┐  ┌────────▼──────────────┐  ...                      │
│   │    RRH 1 (Thin MAC/PHY)     │  │   RRH 2 (Thin MAC/PHY)│                           │
│   └───────────────┬─────────────┘  └────────┬──────────────┘                           │
│                   │                         │                                          │
│             Selected RRH transmits; others silent in this TXOP                         │
│                                                                                        │
└────────────────────────────────────────────────────────────────────────────────────────┘
  

10.5 Control Plane vs. Data Plane

The table below summarizes the architectural differences between controller-managed, loosely-coupled APs and Fi-Wi's cellularized, tightly-coupled architecture:

10.6 Operational and lifecycle advantages

Controller-managed loosely-coupled APs:

• Complex distributed software updates: each AP runs its own firmware image. Updating a building with 50+ APs requires orchestrated rollouts, version compatibility checks, and managing multi-version fleets.
• Per-AP troubleshooting: queue states, retries, and airtime stats are scattered across devices with limited visibility.
• Hardware scaling complexity: each new AP adds another autonomous system with its own memory, CPU, queue management, and potential firmware bugs.
• Failure diagnosis: hard to distinguish AP hardware failure from configuration or RF environment issues; local state is often incomplete.
• Massive Security Surface: Each AP runs a full Linux OS with millions of lines of code, open ports, and local services. A vulnerability in the kernel or a driver compromises the edge device.

Fi-Wi cellularized architecture:

• Simplified RRH hardware: RRHs are thin RF endpoints: RF front end, DMA engine, PTP sync, and a minimal control shim. No complex queue management, routing, or control logic.
• Centralized software complexity: the concentrator contains control logic, shared-state machinery, AQM, scheduling, and learning models. Software updates and new features happen at the concentrator, not across dozens of RRHs.
• Unified diagnostics and visibility: all queues, timestamps, CSI, and per-packet metadata flow through the concentrator:
  • View real-time queue depths and sojourn times per airtime domain.
  • See per-STA, per-RRH, or per-flow latency histograms (median, p95, p99).
  • Trace individual packets from ingress to air transmission with µs-accurate timestamps.
  • Identify which RRH, spatial stream, or MCS is causing retries or collapse.
• Scaling simplicity: adding RRHs to increase density (e.g., 2–4 per room) does not add new control complexity. The concentrator’s logic remains the same; only RF groupings change.
• Predictable failure modes:
  • RRH failure: the concentrator detects loss of DMA/PTP, removes that RRH from its airtime group, and redistributes its STAs to other RRHs in the same domain; queues and flow state remain intact.
  • Concentrator failure: in HA deployments, a standby concentrator with synchronized state can take over; RRHs remain thin endpoints.
• Installation and provisioning: RRHs are auto-configured by the concentrator (channel, power, beacon content, group membership, and policies). Installers mount RRHs, connect fiber, and the concentrator handles the rest—no per-RRH SSH or web UI.
• Cost structure advantages: RRH hardware is simpler and cheaper than full APs; software development and testing concentrate on one platform; support and diagnostics are centralized.
• Zero Security Surface at the Edge: RRHs run **zero lines of Linux**. They have no shell, no open network ports, and no OS to exploit. They are fixed-function hardware micro-bridges.

12. PCIe Fronthaul (Gen3 x1 over Fiber)

12.1 Why PCIe as the RRH interface

A central hardware design choice is to make the RRH look like a PCIe endpoint to the Fi-Wi concentrator. This leverages the fact that:

• All modern Wi-Fi chips speak PCIe already, especially mobile / laptop-class devices.
• The Wi-Fi silicon is validated with PCIe as its primary host interface.

Benefits of this choice:

• No need to invent a new device-side PHY or host interface.
• Reuse of commodity controller logic, driver models, and test infrastructure.
• Natural mapping to our DMA-based RRH model:
  • RRH presents DMA queues for Tx/Rx over PCIe.
  • Concentrator holds packet memory and group queues in DRAM.

We start with PCIe Gen3, one lane (x1), carried over fiber via a retimer + optical interface. Higher generations or widths (Gen4, x2/x4) are possible later but not required for the initial Fi-Wi performance targets.

12.2 Gen3 x1 throughput

PCIe Gen3 provides:

• Raw signaling rate: 8.0 GT/s per lane.
• 128b/130b encoding → effective line rate ≈ 7.88 Gb/s.

After protocol overhead (TLP headers, DLLPs, flow control), the sustained payload throughput for Gen3 x1 is in the rough range of 6–7 Gb/s for large transfers. This is more than sufficient for:

• Feeding a single RRH with:
  • Multi-Gbps Wi-Fi PHY peaks and realistic MAC efficiency.
  • CSI export and control traffic.
• Supporting the expected 2.4 GHz + 5/6 GHz bands per RRH with headroom.

If a future RRH design must exceed this, the same architecture scales to:

• Gen4 x1 (doubles per-lane throughput), or
• Multi-lane links (x2, x4) for very high-end RRHs.

For our initial Fi-Wi deployment assumptions, Gen3 x1 over fiber is a sensible and sufficient starting point.

12.3 Latency characteristics and budget

PCIe Gen3 latency has several components:

• Transaction layer and data link layer processing.
• PHY serialization / deserialization.
• Retimer pipeline delay.
• Fiber propagation.

Order-of-magnitude:

• PCIe controller + retimer pipeline: microsecond-scale latency per transaction (a handful of µs).
• Fiber propagation: ~5 µs/km, so tens to a few hundred meters of in-building fiber adds only tens to hundreds of nanoseconds.

Compared to:

• L4S RTTs (tens of ms, WAN) or a few ms (LAN).
• MAC TXOP durations (hundreds of µs).
• Queue sojourn-time targets (200–400 µs at group queues).

the PCIe-over-fiber latency is effectively negligible. It comfortably fits within the microsecond-level time base used for:

• t_ingress_us timestamps in FiWiMeta.
• RRH transmit time stamps.
• Queue-delay computation and ECN marking.

12.4 Mapping queues and metadata

The PCIe model fits naturally with the Fi-Wi queueing and metadata scheme. Each RRH behaves like a PCIe endpoint with:

• Downlink DMA rings: concentrator → RRH descriptors, pointing to packets in central DRAM.
• Uplink DMA rings: RRH → concentrator descriptors, carrying received frames and CSI/stats.

The FiWiMeta header lives in host memory adjacent to packet payloads and is referenced by these descriptors.

Downlink flow:

1. Concentrator enqueues IP/Ethernet packets into a group queue in DRAM, allocates or updates FiWiMeta (including t_ingress_us and queue snapshot).
2. Scheduler posts PCIe descriptors to the RRH for the next TXOP, selecting which MSDUs and which RF group/airtime domain.
3. RRH DMA-fetches the MSDUs via Gen3 x1, builds an aggregate (A-MPDU), transmits over the air, and reports:
   • Success / retry / PER data
   • CSI and MCS used
   • TX time / TXOP info

Uplink flow:

1. RRH receives 802.11 frames from STAs, decodes them, and attaches CSI and MAC status.
2. RRH DMA-writes the frames + metadata into concentrator DRAM via PCIe.
3. Concentrator:
   • Inserts packets into the appropriate group queues.
   • Updates per-flow and per-domain control state.
   • Feeds CSI and MAC outcomes into the learning model (Appendix B).

In both directions, the PCIe fronthaul:

• Provides more than enough throughput for RRH traffic and control.
• Provides low and stable latency consistent with microsecond-level timing.
• Aligns perfectly with the central group-queue and FiWiMeta assumptions of the control-plane design.

12.5 PCIe Hot Swap

A critical operational requirement for Fi-Wi is the ability to service, replace, or add RRHs without bringing down the entire building's wireless network. PCIe provides native support for this through hot-plug capability, which is standard in enterprise server platforms and can be leveraged for Fi-Wi deployments.

12.5.1 Hot-plug fundamentals

PCIe hot-plug allows physical insertion and removal of endpoint devices (RRHs) while the system is running:

• Hardware signaling: Hot-plug controllers detect physical presence via dedicated signals (PRSNT# pins) or through link training state changes.
• Surprise removal: Modern PCIe supports surprise removal where endpoints disappear without software notification—critical for field environments where RRHs may lose power or have cable disconnections.
• Software enumeration: The concentrator's PCIe root complex can dynamically enumerate new RRHs when they appear and gracefully handle removal of existing RRHs.

12.5.2 RRH insertion flow

When a new RRH is connected or powered on:

1. Physical detection: PCIe hot-plug controller detects the new device via link training.
2. Enumeration: Concentrator OS (Linux) enumerates the new PCIe endpoint:
   • Reads device configuration space
   • Assigns bus/device/function (BDF) identifier
   • Allocates BAR (Base Address Register) resources for DMA rings and control registers
3. Driver initialization: Fi-Wi driver:
   • Initializes DMA rings for this RRH
   • Establishes time synchronization (PTP)
   • Reads RRH capabilities (bands, spatial streams, MAC features)
   • Configures initial RF parameters (channel, power, SSID)
4. RF group integration: Concentrator control plane:
   • Determines which airtime domain this RRH should join (Section 6)
   • Updates queue group assignments
   • Begins CSI collection and spatial stream analysis
   • Steers traffic to/from the new RRH as appropriate

Time from physical insertion to active traffic forwarding: typically 1–5 seconds, depending on link training, driver initialization, and RF group discovery.

12.5.3 RRH removal flow

When an RRH is removed (planned maintenance, failure, or surprise disconnection):

1. Detection: PCIe hot-plug event or surprise removal detected:
   • Link training failure indicates physical disconnection
   • Transaction timeouts indicate unresponsive endpoint
   • Software-initiated removal for planned maintenance
2. Traffic rerouting: Concentrator immediately:
   • Stops scheduling TXOPs to the removed RRH
   • Redirects downlink traffic to other RRHs in the same airtime domain (Section 8)
   • Continues receiving uplink traffic from remaining RRHs in the domain
3. Queue cleanup: Driver:
   • Flushes any outstanding DMA transactions
   • Returns in-flight packets to group queues for retransmission via other RRHs
   • Releases DMA ring memory and BAR resources
4. RF group adjustment: Control plane:
   • Removes RRH from airtime domain membership
   • Recomputes spatial stream structure without this RRH
   • Adjusts beacon power and grouping for remaining RRHs if needed
   • Updates capacity estimates for the affected domain

Impact on active connections: minimal to none for STAs served by multi-RRH domains. Traffic seamlessly fails over to remaining RRHs within the same RF group. For isolated single-RRH cells, removal causes brief disconnection until STAs reassociate with neighboring cells.

12.5.4 Operational advantages

Hot-plug capability provides critical operational benefits:

• Zero-downtime maintenance: Individual RRHs can be serviced, upgraded, or replaced without affecting other RRHs or requiring a maintenance window.
• Gradual deployment: Buildings can be brought online room-by-room as RRHs are installed, rather than requiring all hardware to be in place before service begins.
• Failure resilience: Hardware failures are automatically detected and isolated. The concentrator continues serving the building with reduced capacity rather than failing entirely.
• Capacity scaling: New RRHs can be added to increase coverage or capacity in high-demand areas without disrupting existing service.
• Troubleshooting: Suspect RRHs can be temporarily removed for testing or swapped to isolate problems without taking the network offline.

12.5.5 Design considerations

To fully support hot-swap in production deployments:

• PCIe root complex requirements: The concentrator must use a PCIe root complex with hot-plug controller support (standard in server-class platforms).
• Driver state management: The Fi-Wi driver must handle surprise removal gracefully:
  • No kernel panics or resource leaks on sudden RRH disconnection
  • Proper cleanup of DMA mappings and IOMMU entries
  • Idempotent initialization for re-inserted RRHs
• Power delivery: RRHs should support Power-over-Ethernet (PoE) or similar remote power so they can be powered on/off without physical access to the device.
• Fiber link quality: Optical transceivers must reliably signal link state changes for accurate hot-plug detection. Poor fiber connections can cause spurious removal/insertion events.
• Testing: Hot-plug paths must be tested under realistic failure scenarios:
  • Power loss during active traffic
  • Fiber disconnection mid-TXOP
  • Rapid insertion/removal cycles
  • Multiple simultaneous RRH failures

12.5.6 Contrast with traditional APs

Traditional distributed APs handle failures differently:

• Independent failure domains: Each AP is autonomous. When one fails, only its coverage area is affected, but STAs must reassociate and rebuild transport-layer connections.
• No graceful failover: Distributed APs cannot seamlessly redirect traffic to neighbors because they lack shared state and centralized control. STA reassociation takes hundreds of milliseconds to seconds and disrupts active connections.
• Controller-managed systems: Even with controllers, AP failures are detected via keepalive timeout (seconds), not microsecond-scale PCIe events. Recovery is slow and disruptive.

Fi-Wi's PCIe hot-plug, combined with multi-RRH airtime domains and centralized queues, enables sub-second failover with minimal packet loss—a qualitative improvement over traditional Wi-Fi high-availability approaches.

12.5.7 Integration with L4S and queue management

Hot-swap events interact cleanly with Fi-Wi's L4S and queueing architecture:

• Group queue preservation: When an RRH is removed, its airtime domain's group queue remains intact. Packets simply drain via remaining RRHs instead of the removed one.
• ECN marking continuity: L4S marking continues uninterrupted because it happens at the group queue, not at individual RRHs. Transport-layer congestion control sees no disruption.
• Capacity adjustment: The concentrator dynamically adjusts capacity estimates for the affected domain, which naturally influences L4S control loop behavior without requiring special handling.
• Timestamp coherence: Even during RRH insertion/removal, timestamp-based sojourn time measurements remain valid because they reference the concentrator's PTP time base, not per-RRH clocks.

This separation—queues and control in the concentrator, timing-critical MAC in hot-swappable RRHs—is precisely what enables graceful hardware lifecycle management while maintaining the control-theoretic cleanliness that L4S requires (Appendix A).

13. Hardware Architecture: The Workstation Concentrator vs. The Legacy AP

To understand why Fi-Wi achieves deterministic latency where traditional Wi-Fi fails, we must look beyond the protocol and into the physical architecture of the devices. The feasibility of the "Cut-Through" RRH design relies on the upstream link being non-blocking. Fi-Wi achieves this by replacing the internal switching fabric of legacy APs with the massive PCIe lane overprovisioning of a workstation-class Concentrator.

13.1 The Legacy Bottleneck: Anatomy of a Traditional AP

A traditional Enterprise Access Point is functionally a "Router-on-a-Stick." It forces high-speed wireless traffic through a series of internal serialization bottlenecks before the software ever sees the packet.

Architectural Flaws in Legacy APs:

1. The GMII Choke: The interface between the internal Switch and the CPU is a serialized bottleneck (typically GMII/SGMII). High-speed bursts from Wi-Fi 6E/7 radios can saturate this single link, causing invisible backpressure inside the SoC.
2. Triple Buffering: A packet is buffered at the Switch (Point A), then in system RAM (Point B), and finally in the Hardware DMA Ring (Point C). This "Store-and-Forward" chain destroys the precise timing required for L4S.
3. Opaque Switching: The internal switch operates autonomously. The CPU has no visibility into the depth of the switch's internal buffers, meaning latency accumulates invisibly before the OS can measure it.

13.2 The Fi-Wi Solution: The 92-Lane Fabric

Fi-Wi eliminates the internal switch, the GMII link, and the autonomous CPU. By utilizing high-end workstation silicon (e.g., AMD Threadripper Pro or Intel Xeon W-3400 series), the Concentrator provides 92 to 128 native PCIe lanes directly from a CPU with 24 to 96 high-performance cores.

The 92+ lanes of PCIe eliminate the need for an internal ethernet switch anywhere in the datapath.

13.3 Dedicated Resources and Determinism

By mapping each RRH (or small groups of RRHs) to dedicated root ports on the CPU, Fi-Wi achieves a Non-Blocking Architecture:

• Zero Switching Contention: A read request from RRH #1 does not compete with RRH #2 for switch buffer credits. They travel on separate physical copper traces all the way to the CPU's I/O die.
• Massive Bandwidth Headroom: 92 lanes of PCIe Gen4/5 offer >150 GB/s of aggregate bandwidth. Even if all 50 RRHs retry simultaneously (a "Synchronized Collapse" event), the aggregate demand (~10 GB/s) consumes less than 7% of the host's I/O capacity.

This guarantees that the host DRAM behaves like Deterministic Ultra-Low Latency Memory rather than a shared network resource. This stability is the physical foundation that allows the software-defined queues (Section 14) to operate with microsecond precision.

14. Hardware Queues and the Software Advantage

14.1 The Hardware Queue Problem

Traditional Wi-Fi APs use hardware DMA (Direct Memory Access) rings to meet strict 802.11 MAC timing requirements—SIFS and DIFS deadlines measured in microseconds. While this solves the timing problem, it creates a cascade of architectural constraints that Fi-Wi explicitly avoids.

Hardware queues are expensive to implement in silicon. Each queue requires dedicated SRAM for descriptor storage, control logic for pointer management and overflow handling, and power even when idle. Current chip design limits traditional APs to hardware queues at L2 or MAC—typically the four WMM access categories (AC_VO, AC_VI, AC_BE, AC_BK) per radio * N stations.

While sufficient for basic priority handling, this fundamental constraint prevents the sophisticated per-flow scheduling that modern high-density networks require:

14.2 The DMA Ownership Constraint

An equally significant problem is that once packets are enqueued to hardware DMA rings, the CPU cannot access them without causing race conditions. This "ownership transfer" creates fundamental limitations:

This prevents:

• Real-time ECN marking: Must mark speculatively at enqueue time based on guessed future queue depth, not actual sojourn time at transmission. This leads to oscillation and poor L4S performance.
• Adaptive packet inspection: Cannot implement policies like "inspect deeply when queue exceeds threshold" because packets in queue are inaccessible. All inspection must happen in the fast path, adding latency or requiring expensive hardware DPI engines.
• Dynamic flow reclassification: If a flow's characteristics change (HTTP connection becomes video stream), packets already in hardware queues cannot be moved. Only future packets can be reclassified.
• Queue debugging: Network operators cannot see which flows are filling queues, packet ages, or causes of head-of-line blocking. Only aggregate counters are visible.

14.3 Compensating Hardware

Because hardware queues are limited and packets become inaccessible after DMA, traditional AP vendors must add compensating hardware functionality to address these fundamental architectural limitations:

This compensating hardware represents substantial additional silicon area, design complexity, and verification effort. More critically, hardware-based solutions are fundamentally limited to fixed thresholds and simple policies that were designed into the chip. They cannot implement sophisticated algorithms like CoDel, PIE, or adaptive per-flow policies that require complex state and frequent updates.

14.4 Fi-Wi's Architectural Solution

Fi-Wi escapes these constraints through architectural separation:

RRH: Timing without queuing

RRH silicon implements only timing-critical functions (MAC/PHY, synchronization) with zero hardware queues. Packets arrive from the concentrator milliseconds before transmission, stay in simple descriptor rings briefly, then transmit. No autonomous queuing or scheduling logic.

Concentrator: Unlimited software queues

All queues live in concentrator DRAM. Because the concentrator operates at TXOP granularity (~600 µs) rather than SIFS granularity (16 µs), it has time for software scheduling. Queue structures are simple data structures in memory— vastly cheaper than dedicated silicon:

Packet ownership until last moment

The critical difference: packets remain in concentrator DRAM (software-accessible) until milliseconds before transmission. The scheduler can:

• Compute sojourn time at TXOP instant: now() - pkt->enqueue_time
• Mark ECN based on actual delay, not speculation
• Inspect packet contents and apply adaptive policies
• Reclassify flows by moving packets between queues
• Export queue state to monitoring tools

RRH only owns packets for ~1 ms while transmitting a TXOP—too brief to constrain the system.

14.5 Economic and Strategic Impact

Beyond the direct silicon cost advantages, Fi-Wi gains strategic advantages that compound over time:

• Continuous improvement: Deploy new AQM algorithms, better classifiers, or ML-based scheduling via software updates—no hardware changes required.
• Operational excellence: Full queue visibility enables root-cause analysis, capacity planning, and identification of misbehaving clients—impossible with opaque hardware queues.
• Research integration: As networking research advances, Fi-Wi deployments benefit immediately through software deployment, not years-long silicon redesign cycles.

14.6 Architectural Principle

Fi-Wi's approach follows a clear design principle:

This separation is not arbitrary. It's driven by fundamental constraints: hardware is expensive, inflexible, and opaque; software is cheap, updatable, and inspectable. By placing intelligence in software and only timing-critical functions in hardware, Fi-Wi achieves both the performance of hardware-accelerated systems and the flexibility of software-defined networking—advantages that traditional distributed-AP architectures cannot replicate due to their need for autonomous per-AP decision-making at microsecond timescales.

15. Adaptive Control via Machine Learning

The Fi-Wi architecture's centralized observability enables machine learning to optimize MCS transition dynamics on a per-site basis. Unlike autonomous APs that operate on partial, local state, the Concentrator observes the complete state-transition graph for all RRHs under a single clock. This section describes how Fi-Wi combines physics-based models with adaptive learning to optimize performance.

15.1 The MCS State Graph as a Probability Current Network

The MCS state graph from Section 2.7 can be formalized as a probability current network, where each node represents a PHY configuration state (MCS index, spatial stream count) and edges represent transitions between states. The system's behavior follows probability flow dynamics:

15.2 What Gets Learned: The Transition Rate Matrix

Machine learning in Fi-Wi optimizes the transition rate matrix W based on telemetry that is only observable in a centralized architecture. For each potential transition from state i (MCS_i, SS_i) to state j (MCS_j, SS_j), the learned rate depends on:

The learned transition rate function takes the form:

This learned function answers: "Given the current state and observed conditions, what is the optimal next MCS/SS configuration to meet the L4S latency target while maximizing achievable throughput?"

15.3 Physics-Informed Learning

Fi-Wi uses physics-informed machine learning that combines Shannon capacity theory with learned corrections. This hybrid approach provides explainability, sample efficiency, and principled generalization.

The transition rate decomposes into two components:

W_physics: The physics baseline uses Shannon capacity to establish theoretical bounds. For each MCS index, the required SNR is known from 802.11 specifications (e.g., MCS 11 requires ~30 dB). The base transition rate is the probability that current SNR exceeds the threshold given measured CSI.

W_learned: The learned correction factor captures deviations from ideal conditions on a per-station basis, as different spatial stream capabilities and local RF environments require station-specific adaptation:

• Building attenuation: Concrete walls vs drywall, multipath reflections
• Interference patterns: Neighboring networks, non-Wi-Fi devices (Bluetooth, microwave)
• Temporal dynamics: Rush hour density vs overnight, seasonal changes
• Client behavior: Application mix (VoIP vs bulk), protocol compliance variations

This approach uses residual learning: the physics model W_physics provides the coarse steering (the "prior"), while the ML model learns the residual error Δ specific to the site. This guarantees the system never performs worse than a standard physics-based model, even before site-specific training converges. The ML correction is additive (or multiplicative) to a known-good baseline.

This decomposition provides three advantages:

1. Explainability: When W_learned deviates significantly from 1.0, the system can flag anomalies and explain why performance differs from theory.
2. Sample Efficiency: The physics prior means the ML model only needs to learn corrections rather than the full mapping from scratch.
3. Generalization: The base model W_physics is universal. Site-specific W_learned factors can be initialized from similar deployments and fine-tuned with site-specific data.

15.4 Training Data from Centralized Observability

The Concentrator's complete state visibility provides labeled training examples that are impossible to obtain in distributed AP systems. Each scheduling decision creates a training tuple:

Over time, the Concentrator accumulates thousands of these labeled examples across varying conditions. The ML model learns patterns such as:

• "When queue sojourn exceeds 700 µs AND client density > 10, stepping down from MCS 9→7 reduces latency by 40%"
• "In specific rooms at certain times, interference spikes require proactive MCS reduction to maintain PER < 5%"
• "4-stream Mu-MIMO (SS=4) only succeeds when κ < 10 dB; above this threshold, SS=2 is optimal"

This supervised learning is only possible with centralized observability. As detailed in Appendix H, autonomous APs lack:

• Global CSI: Each AP sees only its own channel, not cross-RRH interference
• Cross-AP operational state: Cannot observe other APs' band selection, power levels, or scheduling decisions, leading to conflicting local optimizations
• Queue visibility: Queue depth and sojourn time are hidden in firmware
• Deterministic replay: Cannot reproduce exact conditions to verify decisions
• Causal observability: High inference distance between PHY decisions and transport-layer effects

It's worth noting that supervised learning doesn't require perfect ground truth labels to be effective—even relative quality assessments ("better" vs "worse") can drive learning. However, Fi-Wi's complete observability provides significantly richer training signals: precise measurements of queue impact, throughput changes, and latency effects that enable more efficient learning compared to the partial observability available to autonomous systems.

15.5 Transfer Learning Across Sites

Fi-Wi's ML strategy uses transfer learning to balance generalization across sites with site-specific optimization:

Base Model (Cross-Site Training):

A foundational model is trained across multiple deployment sites to learn universal patterns:

Site-Specific Adaptation:

When deployed to a new site, the base model is augmented with learned corrections:

Continuous Adaptation:

The system continues to adapt using online learning with safety constraints:

• Conservative exploration: Only explore new MCS transitions when queue depth is low
• Immediate rollback: If a transition causes PER spike or latency increase, revert and mark as high-risk
• Periodic retraining: Update W_learned based on accumulated telemetry
• Anomaly detection: Alert when learned corrections deviate significantly from baseline

15.6 The Learning Feedback Loop

Fi-Wi's ML capability creates a feedback loop that improves system performance over time:

This loop is unique to centralized architectures. Autonomous APs cannot generate ground truth labels without queue observability. Coordinated AP systems (where APs share summaries via a controller) see effects (latency, ECN) but not causes (queue growth, retry timing, aggregation depth) due to high inference distance.

Fi-Wi's centralized state graph provides the causal observability that machine learning requires. The probability current framework gives this learning a rigorous mathematical foundation: we are learning the transition rate matrix of a physical system governed by conservation laws.

15.7 The Multi-RRH Advantage: Learning the Spatial Network

The presence of multiple concurrent Radio Heads (RRHs) serves as the primary multiplier for the Fi-Wi machine learning capability. It transforms the learning problem from optimizing a single isolated link into optimizing a spatially coupled network. While a traditional AP optimizes a local objective function (its own throughput), the Fi-Wi Concentrator utilizes concurrent RRHs to construct a global view of the RF environment.

This multi-RRH architecture impacts the learning model in three critical ways:

1. Global RF State Visibility ("The Super-Eye")

In traditional systems, an AP is blind to the interference seen by its neighbors. In Fi-Wi, the Concentrator aggregates real-time telemetry from all RRHs simultaneously.

This creates a Global RF State Matrix composed of:

• Cross-RRH RSSI/SNR: Seeing how a client's signal is received across multiple rooms.
• Beamforming Feedback: Aggregating the standard 802.11ax/be compressed V-matrices (CSI) from sounding frames.
• Interference Maps: Correlating noise floor spikes across the floorplan.

This state matrix is sparse, time-aliased, and derived from standards-compliant telemetry rather than continuous per-packet baseband capture.

The model learns not just that "Client A has a weak signal," but specifically that "Client A is weak on RRH 1, strong on RRH 2, and creates -80 dBm interference on RRH 3." This global observability enables the prediction of building-wide interference patterns invisible to single-cell learners.

2. Expanded Action Space (Selection & Redundancy)

Because Fi-Wi treats multiple RRHs as an active redundant set, the ML engine has a broader action space than a standard rate-control algorithm. It learns not only how to transmit (MCS and scheduling decisions) but which RRHs are eligible transmitters for a given packet.

• Downlink Path Selection: The model predicts which RRH is most likely to deliver a packet successfully to a specific client location at a specific time of day, minimizing retries.
• Uplink Diversity Optimization: The system learns which set of RRHs provides the best Selection Diversity for a given client location, optimizing the receive path to maximize SNR.

3. Phase 2 Capability: Eigenstructure & Rank Expansion

Note: This capability requires the hardware-synchronized FPGA architecture (Phase 2).

With sub-nanosecond synchronization, the ML engine will be able to resolve the true distributed Eigenstructure of the environment—the "shape" of available RF paths across distributed radios. This allows for Rank Expansion, where the system resolves more spatial streams (Eigenvectors) than a single physical AP could support, scaling capacity approximately with the number of RRHs, subject to channel rank and geometry.

15.8 Operational Calibration: Zero-Occupancy Sounding

To ensure the physics-informed model converges accurately, Fi-Wi employs a specific operational strategy: Zero-Occupancy Sounding.

As described in Section 15.5, the site-specific transfer function is composed of static building characteristics (H_static) and dynamic temporal variations (Δ_temporal). To disentangle these variables, the system schedules automated channel sounding during hours of minimum occupancy.

• Schedule: Configurable based on vertical (e.g., 03:00–04:00 for hospitality, weekends for office).
• Frequency: Typically runs nightly, or triggers automatically if the system detects significant performance drift (e.g., after a renovation).

This establishes a stable baseline "Zero State" for the learning model, ensuring that subsequent online learning is optimizing for dynamic changes rather than relearning the static environment. This separation dramatically improves offline RL dataset conditioning by preventing the model from relearning static structure while adapting to temporal dynamics.

15.9 Bounded Model Validation During Idle Periods

While the primary learning mode is offline (using historical data), the centralized Concentrator architecture enables a hybrid approach: opportunistic, bounded model validation during predicted idle periods.

Idle Period Detection

Because the Concentrator has global visibility of queue states across all RRHs in an Airtime Domain, it can predict when the RF channel will be underutilized—a capability fundamentally unavailable to autonomous APs that see only their local queues.

• Queue Monitoring: When all per-client queues fall below threshold and no new flows are active
• Traffic Pattern Learning: Historical data reveals predictable idle periods (e.g., 2-4 AM, lunch hours in office buildings)
• Duration Estimation: The system predicts how long the idle period will last based on queue derivative trends

Safe Validation Protocol

During high-confidence idle predictions, the system can perform controlled validation and calibration—not arbitrary exploration:

• Model Validation: Test the next-best admissible action within the model's confidence bounds to validate prediction accuracy
• MCS Probing: Send synthetic frames at alternative MCS values to clients with stale channel estimates
• Calibration Updates: Perform extended channel sounding to refresh H_static estimates

These activities refine the offline model without introducing risk to production traffic.

Production Traffic Protection

Validation is strictly bounded to prevent interference with real traffic:

• Immediate Abort: If real packets arrive during validation, the system immediately reverts to production mode
• Time Budget: Validation limited to maximum 5% of channel time per domain
• Confidence Gating: Only validate when >90% confident of idle duration (based on queue derivative trends)
• Domain Isolation: Validation in one Airtime Domain does not affect others
• Flow Exclusion: No validation is performed on flows marked latency-critical or L4S-sensitive

This hybrid approach provides the safety of offline learning with the adaptability of continuous refinement, exploiting natural traffic lulls that autonomous APs cannot collectively identify.

15.10 Architectural Comparison: Why Autonomous APs Cannot Learn

Machine learning for MCS optimization is fundamentally enabled by Fi-Wi's centralized architecture and impossible in distributed AP systems:

This observability gap is not a vendor implementation issue—it is an architectural limitation. Autonomous APs cannot generate high-quality training labels without queue observability.

16. Concentrator Fast Path: DPDK, DMA, and Queue Determinism

The preceding sections established the architecture of the Fi-Wi concentrator: centralized packet memory (Section 4.4), group queues as the sole AQM bottleneck (Section 4.3), microsecond timestamps written into the Fi-Wi shim header (Section 4.2), and ML-driven MCS selection running continuously against that centralized data (Section 15). This section explains how the concentrator executes that pipeline with the determinism the architecture requires — maintaining a single observable bottleneck per airtime domain, applying ECN marks at the right moment, and keeping the RRH free of scheduling logic.

16.1 Why a Kernel-Bypass Data Plane

The Fi-Wi concentrator's latency and determinism targets strongly favor a kernel-bypass data plane. A conventional interrupt-driven kernel path would reintroduce jitter at exactly the point where the architecture is trying to remove it.

L4S requires ECN marks to be applied at the group queue on the same time scale as a single 802.11 TXOP. The Linux kernel's softirq-based packet path introduces interrupt coalescing and scheduler contention that accumulates across bursts. More fundamentally: every packet that transits the kernel stack competes with arbitrary OS activity for CPU time. The queue depth is not directly visible to userspace without a syscall; the marking decision cannot be co-located with the queue measurement in the same cache line.

Fi-Wi's concentrator data plane therefore runs via DPDK (Data Plane Development Kit): tight busy-poll loops on dedicated cores, with no interrupt-driven jitter. All packet operations — receive, classify, AQM mark, forward — execute in a cache-resident loop that preserves the single-bottleneck, fully-observable queue structure that the rest of the architecture depends on.

16.2 The Memory Model: IOMMU, VFIO, and Hugepages

DPDK allocates all packet buffers (mbufs) from hugepages, eliminating TLB misses during packet processing. Each airtime domain's group queue is a logically contiguous region within this space. The pool is allocated once at startup; no per-packet memory allocation occurs on the fast path.

Each SFP+ NIC is bound to the vfio-pci driver. The system IOMMU enforces DMA isolation: a card can only reach the memory regions explicitly registered with it at startup. This gives the concentrator two properties simultaneously:

• Safety: A malfunctioning RRH cannot issue PCIe DMA transactions to arbitrary concentrator memory. The IOMMU enforces the boundary in hardware.
• Performance: IOMMU mappings are established once when the mbuf pool is created. From that point, rx_burst and tx_burst are zero-copy: the NIC DMA engine writes received frames directly into pre-registered mbuf space and reads transmit frames from the same space, with no per-packet kernel involvement.

16.3 Airtime Domains as Hardware Queue Partitions

DPDK exposes each NIC's hardware receive queues independently. Fi-Wi uses this to achieve a direct, lockless mapping from PCIe port and queue index to airtime domain — the same logical grouping described in Section 6. Each lcore owns a fixed set of (port, queue) pairs. Because ownership is exclusive, there are no locks on the fast path and no shared state between lcores during steady-state forwarding.

16.4 The L4S Marking Loop

The AQM marking step is deliberately minimal. The DPDK data plane does not run a full queue scheduler — that is the outer control loop's responsibility (Section 5). The inner loop does one thing: read sojourn time from the shim header (Section 4.2) and set the ECN CE codepoint if the threshold is exceeded.

// Per-packet in the rx → tx burst loop:
uint64_t sojourn_ns = now_tsc() - pkt->t_ingress;
if (sojourn_ns > THRESHOLD_NS) {
    rte_ipv4_l4s_mark(pkt);                       // in-place, no copy
    fiwi_meta(pkt)->ecn_flags |= ECN_CE_APPLIED;
}
rte_eth_tx_burst(out_port, queue_id, &pkt, 1);

Because t_ingress is written by the same lcore at enqueue, no cross-core communication is needed to compute sojourn time at dequeue. The marking decision is local to the polling thread. This is what Section 4.3 means when it says AQM runs "exactly where the integrator lives": the integrator is the group queue, the group queue is an mbuf ring in hugepage memory, and the marking loop touches that ring on every poll cadence with no additional indirection.

16.5 Fault Isolation via IOMMU Groups

In a multi-card concentrator, each SFP+ card appears in its own IOMMU group, which means each card can be bound to VFIO independently and the IOMMU enforces that one card's DMA cannot reach another card's memory regions. In a deployment with multiple SFP+ cards, the IOMMU topology provides natural fault isolation at the card boundary: a PCIe error or runaway DMA event from one RRH is contained within its card's group and cannot corrupt the packet memory of an adjacent airtime domain. This is a hardware guarantee, not a software policy.

16.6 What DPDK Does and Does Not Solve

The kernel-bypass data plane is not a complexity cost — it is the mechanism that justifies the RRH's simplicity. Because the concentrator runs a deterministic, observable pipeline that applies AQM, tracks sojourn time, and manages all descriptor posting without OS intervention, the RRH never needs to make a queuing or scheduling decision. It remains a pure DMA client, exactly as the silicon cost argument in Section 4.4 requires.

Incumbent distributed APs have no equivalent. Because each AP operates autonomously, it must run its own Linux network stack, its own qdisc, and its own firmware scheduler. The CPU carrying that stack is the dominant gate cost per RRH (Section 4.4, silicon cost table). A centralized DPDK pipeline eliminates that requirement across every RRH simultaneously — not by optimizing the AP implementation, but by removing the architectural condition that forces the CPU to exist there in the first place.

That said, DPDK solves a specific problem: it gives the concentrator a deterministic, observable, zero-copy execution path in which queue state, ECN marking, and packet steering remain under unified software control. It does not solve the radio-side interface. Per-packet MCS selection, EDCA parameter control, and TX-outcome metadata from the Wi-Fi silicon remain the next required interface boundary — the point at which concentrator intelligence must reach into the RRH to close the control loop. DPDK is the precondition; radio-side per-packet programmability is what completes it.

16.7 DualPI2 Baseline: Control Law and Queue Structure

Section 16.4 described the minimal ECN marking step — reading queue state and applying a CE mark in the fast path. That sketch is sufficient to illustrate where marking occurs, but it elides the control structure that makes L4S coexistence with legacy traffic work: the dual-queue coupled AQM defined in RFC 9332.

This section defines the baseline DualPI2 control law as it would be realized inside the DPDK polling loop. Fi-Wi preserves this dual-queue topology, coupling mechanism, and PI-based control structure, but Section 17 replaces the underlying congestion signal with Airtime Debt (D_i), grounding the controller in predicted wireless service time rather than raw queue occupancy.

16.7.1 The Two Queues

Each airtime domain maintains two logically independent mbuf rings in the concentrator's hugepage pool: an L4S queue for scalable congestion-control flows (senders marking with ECT(1)), and a Classic queue for legacy RFC 3168 flows and unmarked traffic. Classification happens at ingress on the fast path, before the packet is enqueued, and costs a single bitfield check on the IP ECN field:

// Ingress classification — per-packet, inline in the rx burst loop
uint8_t ecn = (pkt_ip->type_of_service & 0x03);
bool is_l4s = (ecn == 0x01 || ecn == 0x03);   // ECT(1) or CE — scalable sender

fiwi_meta(pkt)->queue_class = is_l4s ? QUEUE_L4S : QUEUE_CLASSIC;
enqueue_to_domain(pkt, domain_id, fiwi_meta(pkt)->queue_class);

Both queues drain toward the same transmit burst for that airtime domain. The scheduler services the L4S queue with a strict low-latency budget and the Classic queue at a rate that saturates the domain's aggregate share, matching the DualPI2 service model from RFC 9332.

16.7.2 The Coupling Mechanism

The key property of DualPI2 is that the two queues are not independent. The Classic queue's drop probability pc — computed by a PI controller from a congestion signal representing pressure at the shared bottleneck — also governs the L4S queue's ECN marking probability via a coupling factor k (default 2 in the Linux sch_dualpi2 reference implementation).

// Outer control loop — runs on a slow timer cadence (~16 ms), same lcore,
// non-preemptive. Not per-packet.
double signal_classic = ewma_update(&domain->classic_signal,
                                    ring_depth(QUEUE_CLASSIC));
double p_c = max(0.0, K_PI * (signal_classic - TARGET_CLASSIC));  // PI controller

double p_l = COUPLING_K * p_c;   // Coupled L4S marking probability

// Applied per-packet in the L4S dequeue path:
double p_l_step = (sojourn_L4S_ns > THRESHOLD_L4S_NS) ? 1.0 : p_l;
if (rte_rand_u64() < (uint64_t)(p_l_step * (double)UINT64_MAX))
    rte_ipv4_l4s_mark(pkt);      // Set ECN CE in-place, no copy

In a conventional queue-based implementation, signal_classic would be an EWMA of Classic queue depth. In Fi-Wi, that queue-derived signal is replaced as the PI controller input by Airtime Debt (D_i), a forward estimate of wireless service time. The DualPI2 control law, coupling mechanism, and dual-queue topology remain unchanged; only the input signal changes.

Queue depth is a lagging indicator in Wi-Fi because contention, retries, and variable PHY rates consume airtime without necessarily appearing in buffer occupancy. Airtime Debt provides a forward-looking signal that better matches the true wireless bottleneck while preserving the DualPI2 coexistence structure required for L4S and Classic traffic to share the medium.

16.7.3 Per-Domain State and the fiwi_update Interface

Each airtime domain carries its own DualPI2 state alongside the fiwi_rrh_state struct (Section 17.5). Because each lcore owns a fixed set of domains exclusively (Section 16.8), this state is never shared across cores — no locks, no atomics, no cache-line bouncing on the fast path.

The telemetry path (Section 17.8) delivers ground-truth airtime measurements back to the lcore via a lockless ring carrying fiwi_update objects. The struct is defined here because it originates in the DPDK fast-path layer and is consumed by it; Section 17.8 populates it from Netlink/vendor telemetry events:

/**
 * fiwi_update — telemetry record posted by the Netlink callback,
 * consumed by the DPDK lcore during its scheduling loop.
 * Allocated from fiwi_update_pool (rte_mempool); returned after use.
 */
struct fiwi_update {
    uint8_t  type;          /* AIRTIME_RECONCILE (only type currently defined) */
    uint32_t rrh_id;        /* RRH index, validated < FIWI_MAX_RRHS before enqueue */
    uint64_t actual_us;     /* Hardware-path-to-status interval (ground truth) */
    uint64_t expected_us;   /* Forward estimate: T_phy + T_agg at enqueue time */
    uint32_t retry_us;      /* Observed retry airtime from telemetry metadata */
};

16.8 Multi-RRH lcore Topology and Control Ownership

The Umber concentrator runs on a workstation-class host with a Threadripper PRO processor and multiple PCIe-connected RRHs. This section describes how DPDK lcore assignments map onto that hardware topology to preserve cache locality, single-writer semantics, and deterministic fast-path execution.

Each lcore owns both the DualPI2 control state (Section 16.7) and the Airtime Debt estimator (Section 17) for its assigned RRHs. This ensures that congestion estimation, scheduling, and ECN marking operate within a single execution context.

16.8.1 RRH Assignment

16.8.2 Control and Data Flow

Each RRH lcore applies its per-domain DualPI2 loop as described in Section 16.7, with Airtime Debt (D_i) serving as the PI controller input in place of queue depth. This presents a single, airtime-grounded congestion signal per domain to the L4S control loop.

Downlink traffic is classified at ingress and directed to the appropriate airtime domain. The owning lcore performs scheduling, ECN marking, and transmission. Uplink traffic follows the reverse path toward the WAN interface.

Because each lcore exclusively owns its RRHs and associated Airtime Debt state, congestion estimation, scheduling, and ECN marking operate without cross-core coordination. This preserves deterministic fast-path behavior.

17. Airtime-Assisted ECN: Airtime Debt as the Congestion Signal

Fi-Wi does not infer congestion from queue depth alone. The bottleneck is the wireless medium, and the relevant state variable is the time required to successfully transmit packets over that medium. The system replaces the queue sojourn-time inputs of traditional PI² controllers with Airtime Debt (D_i), converting a stochastic medium into a controlled service process.

17.1 The Bottleneck is Airtime, Not a Queue

In traditional L4S systems, ECN marking is derived from queue sojourn time, which assumes a stationary service rate. These assumptions fail in Wi-Fi because service time varies per client based on PHY rates, contention, and retries. Fi-Wi replaces backward-looking buffer metrics with a forward model of wireless service time. The Concentrator maintains this model continuously and makes scheduling decisions on predicted service outcomes, not observed queue growth. This approach provides the AQM with a signal that has a more stationary distribution than raw queue depth over a variable-rate medium, improving marking coherence and L4S stability.

17.2 Airtime Debt Model (Per RRH)

For each RRH (i), the Concentrator maintains a real-time Airtime Debt (Di):

D_i = A_i + C_i + R_i

• A_i (Backlog Airtime): Predicted transmit duration for staged and in-flight packets.
• C_i (Contention Penalty): Predicted medium access delay (µs), informed by driver telemetry and controlled via EDCA scheduling (Section 4.1.4).
• R_i (Retry Penalty): Predicted retransmission overhead (µs) derived from recent PER history (Section 15.4).

17.3 Measuring Ground Truth (Hardware-Path-to-Status)

The "Ground Truth" for airtime consumption is measured as the interval from descriptor posting into the hardware transmit path to TX Status (hardware completion signal via driver/vendor-specific telemetry events such as mt76 TX status reports). This interval captures the full service duration, including the full wait for TXOP eligibility (AIFS + backoff), aggregation delay, and all hardware-level retransmission attempts.

17.4 Predicted Sojourn Time (S_i)

For any packet, the Predicted Sojourn Time (S_i) is a forward estimate of delivery time:

S_i(packet) = D_i + T_service(packet)

The Tservice calculation is decomposed into: Tagg (aggregation hold time) + Tphy (modulation time at current MCS) + Tretry (statistical retry overhead). This estimate is packet- and client-specific; it is not a constant service quantum.

17.5 Implementation: DPDK Fast Path State

The Concentrator tracks RRH state in hugepage-backed memory. The DPDK lcore is the sole writer of fiwi_rrh_state; telemetry updates are applied via per-RRH lockless ring buffers to preserve single-writer semantics and microsecond-level determinism.

struct __rte_cache_aligned fiwi_rrh_state {
    uint32_t rrh_id;
    uint64_t D_i;            /* Total airtime debt (A+C+R) */
    
    /* Component Estimates (microseconds) */
    uint64_t A_i;            /* Total scheduled airtime (queued + in-flight) */
    uint32_t C_i;            /* Estimated contention delay */
    uint32_t R_i;            /* Estimated retry penalty */

    /* Feedback & Synchronization */
    uint64_t last_update_us;     /* Timestamp of last lcore application */
    uint64_t last_tx_status_us;  /* TSC of last hardware completion */
    uint32_t moving_avg_per;     /* Recent PER (Section 15.4) */
};
    

Di is recomputed in the DPDK fast path after each update to Ai, Ci, or Ri. The loop updates Ai when packets are assigned to an RRH and decrements it upon TX completion using telemetry feedback.

17.6 Authoritative Congestion Signaling

Airtime Debt replaces physical queue depth as the authoritative input for the Dual-Queue AQM, providing a single, authoritative congestion signal across all RRHs without relying on a shared physical buffer.

• L4S Marking: Applied if Si > Tlow. This bypasses traditional sojourn measurements to signal congestion at the true wireless bottleneck.
• Classic Drop: Airtime Debt (Di) replaces queue depth as the input to the PI controller defined in Section 16.7. This preserves the Dual-Queue AQM structure while grounding the control signal in predicted wireless service time rather than buffer occupancy.

17.7 Slow-Path Observability

While Di provides fast-path control, the system monitors Airtime Utilization (U_air = ΔTX_DURATION / Δt) as a slow-path observability metric. This metric is used to identify external interference patterns and long-term capacity shifts in the airtime domain, calibrating the confidence weights applied to the Ci and Ri estimators.

17.8 Telemetry Feedback: Netlink Calibration

The following logic processes TX_STATUS events from the mt76 driver. Completion data is retrieved from a pre-allocated mempool and posted to a per-RRH lockless ring to reconcile state without lcore contention.

/* Telemetry Path (Netlink Callback) */
static int fiwi_handle_mt76_telemetry(struct nl_msg *msg, void *arg) {
    struct nlattr *attrs[MT76_ATTR_MAX + 1];
    nla_parse(attrs, MT76_ATTR_MAX, genlmsg_attrdata(nlmsg_data(nlmsg_hdr(msg)), 0),
              genlmsg_attrlen(nlmsg_data(nlmsg_hdr(msg)), 0), NULL);

    if (!attrs[MT76_ATTR_TX_DURATION] || !attrs[MT76_ATTR_RRH_ID])
        return NL_SKIP;

    uint32_t rrh_id = nla_get_u32(attrs[MT76_ATTR_RRH_ID]);
    if (rrh_id >= FIWI_MAX_RRHS) return NL_SKIP;

    struct fiwi_update *update;
    if (rte_mempool_get(fiwi_update_pool, (void**)&update) < 0) return NL_SKIP;

    update->type = AIRTIME_RECONCILE;
    update->rrh_id = rrh_id;
    update->actual_us = nla_get_u64(attrs[MT76_ATTR_TX_DURATION]);
    update->retry_us = nla_get_u32(attrs[MT76_ATTR_RETRY_DURATION]);
    update->expected_us = estimate_service_time(msg); 

    rte_ring_enqueue(rrh_update_rings[rrh_id], update);
    return NL_PROCEED;
}
    

17.8.1 Telemetry Application (DPDK lcore)

The DPDK lcore closes the control loop by draining the update ring. It decrements the backlog and calibrates penalties to ensure the Airtime Debt remains an accurate representation of physical medium pressure.

/* DPDK lcore: apply telemetry updates */
static inline void
fiwi_apply_updates(struct fiwi_rrh_state *rrh, struct rte_ring *ring)
{
    struct fiwi_update *upd;
    while (rte_ring_dequeue(ring, (void**)&upd) == 0) {
        /* 1. Discharge processed backlog */
        rrh->A_i = (rrh->A_i > upd->actual_us) ? (rrh->A_i - upd->actual_us) : 0;

        /* 2. Update contention estimate (drift from expected modulation time) */
        uint32_t drift = (upd->actual_us > (upd->expected_us + upd->retry_us)) ? 
                         (upd->actual_us - upd->expected_us - upd->retry_us) : 0;
        rrh->C_i = (rrh->C_i * 7 + drift) >> 3;

        /* 3. Update retry penalty */
        rrh->R_i = (rrh->R_i * 7 + upd->retry_us) >> 3;

        /* 4. Recompute total Airtime Debt (D_i) */
        rrh->D_i = rrh->A_i + rrh->C_i + rrh->R_i;

        rrh->last_tx_status_us = rte_get_tsc_cycles();
        rte_mempool_put(fiwi_update_pool, upd);
    }
}
    

17.9 Visualization: The Airtime Debt Control Loop

Figure 17-1: The Fi-Wi recursive control loop for stabilizing stochastic wireless service.

Diagram Overview: Closing the Feedback Loop

Figure 17-1 synthesizes the technical components of the Airtime Debt model into a continuous functional loop. The architecture separates the Speculative Forward Path (Fast Path) from the Calibrated Feedback Path (Telemetry Path).

1. Forward Service Model (Prediction): Every ingress packet triggers a per-STA calculation of Tservice. This is not a global constant; it is a client-specific sum of aggregation hold time (Tagg), PHY modulation time (Tphy), and predicted retry overhead (Tretry) based on that STA's specific RF context.

2. Debt Update & Marking Decision: The predicted Tservice is added to the RRH's Ai (Backlog). If the resulting Predicted Sojourn Time (Si) exceeds Tlow, an ECN CE mark is applied immediately in the DPDK fast path. This provides the "Virtual Backpressure" that stabilizes L4S senders.

3. Ground Truth Calibration (Correction): As the packet is dispatched via DMA, the hardware records the precise interval from descriptor posting into the hardware transmit path to TX Status completion. The Telemetry Path calculates the Drift—the delta between the forward prediction and physical reality.

4. Estimator Refinement: This drift is fed back into the EWMA filters for Ci (Contention) and Ri (Retries). This ensures that subsequent predictions for the same STA or RRH domain are corrected for changing medium pressure, effectively regularizing the stochastic nature of the 802.11 medium.

18. Summary

The core idea of Umber’s Fi-Wi architecture is to make a building full of Wi-Fi radios behave like a large number of predictable, low-latency, cellularized bottlenecks (often cell-per-room) that integrate cleanly with L4S, and to avoid Wi-Fi collapse in the regime that matters most for users: tail latency.

We do that by:

• Time-synchronizing RRHs and concentrator to microsecond accuracy
• Centralizing packet memory and queues in the concentrator
• Adding a Fi-Wi shim header with timestamps and queue metadata
• Doing all L4S AQM/ECN marking at group queues, where the wireless delay is actually created
• Using shared state to dynamically group RRHs into airtime domains (cells), considering both interference and spatial-stream / eigenvector structure
• Using multiple RRHs per room and per STA as an active redundant RF set, analogous to MLO but building-wide
• Leveraging CSI and learning to predict capacity, interference, and collapse risk
• Enabling, where appropriate, coordinated multi-RRH operation and dynamic point selection (Section 9)
• Keeping RRHs within a strict power/thermal envelope, while using PCIe Gen3 x1 over fiber to connect them as low-latency DMA clients of central packet memory

Compared to a building filled with independent APs, Fi-Wi provides:

• Lower and more predictable latency, especially in the tails
• More stable and effective L4S behavior
• A better aggregation–latency tradeoff
• Centralized, cellularized control with shared state that scales across many RRHs and rooms
• RF-layer redundancy, richer spatial streams, and fast failover with a clean single-bottleneck view for L4S
• A practical path to cell-per-room density with manageable power, thermals, and hardware complexity

---

Appendix A: 802.11 Backoff Timing & Collapse Dynamics

This appendix explains the precise behavior of the 802.11 CSMA/CA backoff algorithm, why the freeze/resume mechanics create strong nonlinearities under load, and how this drives the collapse behavior discussed in Sections 2 and 6. We also include reference diagrams, accurate pseudocode, and probability scaling that shows why birthday-paradox collisions appear long before PHY saturation.

A.1 Overview

The 802.11 MAC is built around two core mechanisms:

• Carrier Sensing (CSMA/CA) — sense-before-transmit.
• Random Backoff — avoid collisions by randomized slot countdown.

These mechanisms interact in a way that works beautifully for light to moderate station counts, but begins to break down sharply once multiple stations become backlogged. Collapse is not a "bug"; it is the mathematically expected outcome under high concurrency.

A.2 Backoff Decrements Only During Idle SlotTime

When a station has a frame to send, it chooses a random integer:

B ← Uniform[0, CW]

where CW is the contention window. The counter decrements only when:

• The PHY senses the channel idle for the entire SlotTime (9 µs typical).
• NAV = 0 (no virtual carrier-sense in effect).
• The station has already observed one full AIFS interval.

If any of these conditions break during a SlotTime boundary, backoff does not decrement.

Diagram A-A — Backoff Countdown with Idle Slots and Freezes

Time →  ───────────────────────────────────────────────────────────────────────→

Channel:    Busy TXOP      Idle slot     Idle slot     Busy TXOP      Idle ...
           ────────────┐  ┌─────────┐   ┌─────────┐  ┌───────────┐
                       │  │ slot OK │   │ slot OK │  │collision  │
                       └──┘         └───┘         └──────────────┘

Backoff B:   [frozen]        B:=B-1       B:=B-2        [frozen]       B:=B-3

This "idle-slot-only" decrement rule is the source of nonlinear timing behavior.

A.3 Freeze Conditions: Physical Busy + NAV Busy

The backoff counter freezes immediately under either condition:

• PHY busy: Energy detect (ED) threshold exceeded — another station is transmitting.
• NAV busy: The local station believes a scheduled TXOP is ongoing (Duration field).

NAV counts down in microseconds, not slot units, so a NAV may span dozens or hundreds of SlotTimes, creating long frozen periods.

Diagram A-B — NAV Freezes Backoff for Entire Duration

Frame overheard with Duration=480µs
     NAV := 480 µs  ─────────────────────────────────────────────▶ 0 µs

Backoff:
   Frozen until NAV==0
   Then: AIFS idle interval → first idle SlotTime → resume B countdown

A.4 Full Backoff State Machine

The following pseudocode describes the real 802.11 backoff and retry machine:

# Variables
B   = random integer in [0, CW]
CW  = CWmin initially, doubled on failures
NAV = virtual carrier sense (µs timer)
Slot = 9 microseconds (typical)
AIFS = access category-specific inter-frame space

while True:

    wait_until( medium_idle() and NAV == 0 )
    wait(AIFS)  # must see idle for entire AIFS

    # Backoff countdown
    while B > 0:

        if medium_idle() and NAV == 0:
            wait(Slot)
            if medium_idle() and NAV == 0:
                B -= 1      # decrement only if entire slot was idle
        else:
            # Freeze B until another idle AIFS appears
            wait_until( medium_idle() and NAV == 0 )
            wait(AIFS)

    # Backoff fully expired, attempt TX
    transmit()

    if ack_received():
        CW = CWmin
        B = random(0, CW)
    else:
        CW = min(2 * CW, CWmax)
        B = random(0, CW)

The critical detail: multiple stations freeze and resume their counters in lock-step after every long TXOP or NAV, making collisions statistically inevitable as station count grows.

A.5 Collision Probability and the Birthday Paradox

Each station independently picks a backoff slot in [0, CW]. The probability that no two stations choose the same slot is:

P(no collision) = (CW+1)! / [(CW+1 - n)! · (CW+1)^n]

where n = number of active contenders. Therefore:

• Even with CW=15 (CWmin for AC_BE), collisions explode once n > 6–8.
• Increasing CW reduces collisions but explodes delay variance.
• Freeze/resume sync makes large groups of stations “compete” on the same few idle slots.

Diagram A-C — Collision Probability vs. Number of Stations

Stations (n) →   4     6      8      10     12     16
--------------------------------------------------------
P(collision)   ~12%   30%    48%    65%    78%    >90%

(CWmin = 15)

This is the MAC-level reason collapse begins long before PHY capacity is reached.

A.6 Why Collapse Appears as 2–3 ms TXOP Tails

Once collisions become frequent:

• Stations reach retry limits and enlarge CW exponentially.
• Longer CW → longer idle-time waits → bigger aggregates formed.
• Bigger aggregates → longer TXOPs (1.5–3 ms typical in collapse).
• Long TXOPs → other stations see multi-ms starvation → tail latency balloons.

Diagram A-D — TXOP Length as Collapse Indicator

Healthy:    T50 ≈ 200–500 µs,   T95 < 0.8 ms,    T99 < 1.2 ms
Degraded:   T95 = 1–2 ms,       T99 = 2–3 ms
Collapsed:  T95 > 2 ms AND      T99 ≥ 3 ms (dominant channel monopolization)

A single 3 ms TXOP already violates the bottleneck-delay budget required by L4S (≈250–300 µs). With multiple stations taking such TXOPs, service gaps can reach 10–50 ms for unlucky flows.

A.7 Multi-Station Synchronization Example

The following diagram illustrates how multiple stations become phase-aligned:

Time →  ────────────────────────────────────────────────────────────────→

TXOP1 by STA-A:   ────────────────
NAV for others:   ──────────────── (all B frozen)

After NAV expires:
All stations wait AIFS → begin countdown
Slot 1:  B_A=2, B_B=4, B_C=2
Slot 2:  B_A=1, B_C=1
Slot 3:  B_A=0  ,  B_C=0   → simultaneous transmit → collision

This synchronization is why the birthday paradox applies so strongly in Wi-Fi.

A.8 Why Fi-Wi Breaks the Cycle

Fi-Wi removes the “every station fends for itself” randomness by:

• Centralizing queueing and airtime allocation.
• Eliminating station-driven EDCA decisions.
• Coordinating RRH TXOP lengths and schedules.
• Ensuring no two RRHs “race” via random backoff.
• Driving TXOPs toward safe, L4S-friendly durations (≈250 µs).

Thus Fi-Wi converts Wi-Fi from a chaotic CSMA/CA system into a scheduled, low-latency cellular MAC.

---

Appendix B: Channel State Information (CSI) and Learning-Enhanced Fi-Wi

This appendix describes how Fi-Wi can use Channel State Information (CSI) from each RRH, together with learning models (e.g. LSTM or TCN), to improve grouping, scheduling, redundancy, and control beyond what is possible with queue-based feedback alone.

B.1 What CSI provides in a Fi-Wi context

Concept: What is CSI?
Imagine shouting in a complex room. You hear echoes bouncing off walls, furniture, and people. If you analyze those echoes, you can map the environment.

In Wi-Fi, Channel State Information (CSI) is that map. It describes exactly how the radio wave traveled from the transmitter to the receiver—including all the bounces (multipath), fading, and phase shifts caused by the physical environment.

• RSSI (Signal Strength): Tells you how loud the signal is. (One number).
• CSI (Channel State): Tells you the shape of the signal distortion. (A matrix of complex numbers).

Traditional APs throw this data away after decoding the packet. Fi-Wi sends it to the Concentrator, allowing the system to "see" the RF environment and mathematically calculate how to steer beams or combine signals.

Wi-Fi Sensing: Because physical objects reflect radio waves, any movement in the room changes the CSI pattern. By monitoring these changes over time, Fi-Wi can detect presence—such as a person walking or a pet breathing—turning the network into a ubiquitous sensor without cameras.

Modern 802.11 chipsets can export CSI per subcarrier or per resource unit: complex-valued estimates of the channel between an RRH and a station (STA). In a Fi-Wi deployment, each RRH periodically reports:

• Per-subcarrier CSI magnitude/phase (or compressed variants)
• Signal-to-noise ratio (SNR), RSSI, and noise floor estimates
• Selected MCS, PHY rate, and per-TXOP success / retry / PER statistics
• Spatial-stream usage and beamforming feedback (if applicable)

Thanks to centralized time synchronization and packet memory, the concentrator can align CSI reports with:

• Specific flows and STAs
• Specific group queues and airtime domains
• Queue states and ECN marking decisions at those times

This gives Fi-Wi a rich per-domain, per-STA time series:

• CSI(t) — the RF channel state (including spatial eigenstructure)
• MAC(t) — TXOP, MCS, retries, aggregation size, spatial-stream usage
• Queue(t) — group queue depth, marking probability p_k
• Outcome(t) — achieved throughput, delay, PER, “collapse events”

B.2 What we want to predict

Using this data, Fi-Wi can learn models to help answer questions such as:

• Short-horizon capacity prediction: Given recent CSI + MAC statistics, what is the effective service rate C_eff for this RRH or airtime group in the next Δt?
• Interference and grouping: Which RRHs are likely to interfere strongly in the next Δt (e.g. due to mobility, reflections, or external interferers)? Which ones share useful eigenmodes?
• Scheduling decisions: For a given flow/STA, which RRH (or band/channel) and which spatial-stream configuration is likely to give the best service (throughput vs. delay) in the next window?
• Collapse risk: Are we heading into a region where adding more load will cause retries, PER, and tail latency to spike?

These predictions can feed directly into:

• Queue grouping and re-grouping (airtime domains)
• Per-group AQM parameter adaptation (e.g., queue target, gains)
• RRH selection, channel selection, and per-STA scheduling
• Active redundancy policies (which RRHs should listen or transmit in parallel)
• Spatial-stream / eigenmode choices within each airtime domain

B.3 Example model: LSTM / TCN

One reasonable approach is to use a sequence model such as an LSTM or Temporal Convolutional Network (TCN) per airtime domain:

Input features (per timestep):
  - queue depth q_k
  - marking probability p_k
  - throughput, PER, retries
  - per-RRH CSI summary (e.g. dominant eigenvalues/eigenvectors)
  - beacon power settings, channel, bandwidth

Outputs:
  - predicted effective capacity C_eff,k+1
  - predicted collapse risk score
  - recommended group reconfiguration / beacon adjustments (optional)

A higher-level policy layer then uses these predictions to:

• Re-balance load across domains
• Merge or split airtime domains
• Adjust beacon powers to reshape cell edges
• Tweak PI2 / L4S parameters per domain

The key point is that Fi-Wi has access to the joint state across all RRHs—queues, CSI, MAC outcomes, and beacon configuration—so learning can be done on a true building-scale view rather than a per-AP snippet.

B.4 The Non-Linear Control Policy (Feature Vectors)

While the PI² controller (Section 5.2) provides a robust baseline using linear control theory, the wireless medium is inherently non-linear. A small drop in SNR can cause a discrete, non-linear step-down in MCS, cutting capacity by half in microseconds. A linear controller often reacts too slowly to these step-changes.

Because the Concentrator terminates both the MAC (Inner Loop) and L4S (Outer Loop), it possesses a complete, global view of the system state. This allows Fi-Wi to implement a Non-Linear Marking Signal derived from a rich real-time feature vector:

Feature Vector x(t) = [
   MCS_t,          // Current Modulation (Capacity potential)
   PHY_Rate_t,     // Raw drain rate
   RTT_outer,      // End-to-end latency (Sojourn + Flight)
   Q_depth_t,      // Current backlog
   d_arrival/dt    // Arrival rate gradient (ARM Policer)
]
  

Optimization Objective: Efficiency vs. Latency
The system uses this vector to solve the fundamental Wi-Fi trade-off: Aggregation Efficiency vs. Serialized Latency.

• The Physics: PHY efficiency increases with aggregation size (amortizing the preamble/SIFS overhead). However, larger aggregates typically imply deeper queues and higher latency.
• The Logic: By correlating MCS with Arrival Rate, the control policy can dynamically adjust the marking threshold.
  • High MCS Scenario: The policy knows the "pipe" is wide. It relaxes the marking threshold, allowing the "Inner Integrator" (Section 5.3) to accumulate more packets. This naturally builds larger, more efficient aggregates (e.g., 64 MPDUs) without violating the L4S latency budget because they drain instantly.
  • Low MCS Scenario: The policy knows the "pipe" is narrow. It aggressively marks via the ARM Policer, forcing the sender to slow down. This keeps the aggregate size small (e.g., 4 MPDUs), preventing the massive "sawtooth" latency spikes that occur when sending large aggregates at low data rates.

This creates a Non-Linear Marking Signal that optimizes Throughput per Microsecond of Latency, rather than simply targeting a fixed queue depth.

---

Appendix C: Latency Hiding via Scatter-Gather DMA

Early architectural models of C-RAN often assumed a "Store-and-Forward" approach, where full packets must be buffered at the edge to meet timing. Fi-Wi eliminates this inefficiency by leveraging the natural physics of the 802.11 air interface. We utilize a Scatter-Gather DMA engine with Preamble Hiding to enable a "Thin RRH" design with minimal local SRAM.

C.1 The "Preamble Shield" Physics

The critical timing constraint in Wi-Fi is the transition from "Decision to Transmit" to "Energy on Air." However, the 802.11 PHY does not transmit user data immediately. Every transmission begins with a PHY Preamble (PLCP) and MAC Headers.

Time-Domain View of a Transmission Start: T=0 µs T=5 µs T=24 µs (approx) | TX Trigger | | | | Preamble & Headers | Payload Data Starts... [ MAC Logic ]->[/////////////////////////][......................] ^ ^ | | Source: Local RRH SRAM Source: Host Concentrator DRAM (Instant Access) (Fetched via Fiber)

The Insight: The transmission of the Preamble and Headers takes roughly 20–40 µs (depending on PHY generation). The round-trip time to fetch payload data over 100m of PCIe-over-Fiber is roughly 2–5 µs.

Consequently, the fetch latency is completely "hidden" behind the transmission of the headers. The payload data arrives at the RRH's small FIFO well before the PHY is ready to modulate it.

C.2 Scatter-Gather Architecture

Instead of a large packet buffer, the Fi-Wi RRH implements a Scatter-Gather DMA engine that composes frames on the fly from two distinct memory regions:

1. Template RAM (Local RRH SRAM): Stores 802.11 MAC headers, PLCP headers, and delimiter signatures. This memory is small (< 16 KB), fast, and populated by the Concentrator during the descriptor posting phase.
2. Payload Buffer (Remote Concentrator DRAM): Stores the actual 802.3 Ethernet payloads. These remain in the host server's memory until the exact moment of transmission.

C.3 The Transmit Sequence

1. Descriptor Posting: The Concentrator posts a descriptor to the RRH. This descriptor points to the header in Local RAM and the payload in Remote DRAM.
2. Contention: The RRH MAC performs EDCA backoff. No data is moved during this phase.
3. TX Trigger: When backoff reaches zero, the MAC immediately begins transmitting the Preamble from Local RAM.
4. Just-in-Time Fetch: Simultaneously with the Preamble start, the DMA engine issues a read request to the Concentrator for the payload data.
5. Cut-Through: Data returns from the fiber, flows into a small speed-matching FIFO (e.g., 4 KB), and flows directly into the PHY serialization path immediately following the header.

C.4 Solving the Retry Timing (SIFS)

A common objection to C-RAN is the SIFS deadline (16 µs) required for retries. If a transmission fails, the station must retransmit immediately.

With Scatter-Gather, the RRH does not need to buffer the packet for retries. If a NACK occurs, the MAC simply resets the Scatter-Gather engine. It re-transmits the Preamble (from Local RAM) while re-issuing the DMA fetch (from Remote RAM). Because the fiber latency (5 µs) is significantly shorter than the SIFS + Preamble duration, the data again arrives in time.

C.5 Architectural Benefits

• Zero Copy: Packets are never copied CPU-to-Buffer or Buffer-to-Buffer. They move from Host DRAM to Air.
• Minimal SRAM: The RRH does not need MBs of RAM to buffer aggregates. It only needs KB for headers and FIFOs. This significantly reduces leakage power and die cost.
• Infinite Retries: The system is not limited by local buffer size for retries; it relies on the massive capacity of Host DRAM.

---

Appendix D: 802.11ax/be Features and Fi-Wi Integration

Modern Wi-Fi standards — particularly 802.11ax (Wi-Fi 6/6E) and 802.11be (Wi-Fi 7) — introduce features that appear to address some of the same problems as Fi-Wi: uplink scheduling, spatial reuse, and multi-AP coordination. This appendix clarifies how these features relate to Fi-Wi's architecture, where they're complementary, and why they don't eliminate the need for Fi-Wi's centralized data-plane approach.

Key takeaway: 802.11ax/be features like trigger frames and multi-AP coordination are valuable enhancements that Fi-Wi can leverage when client support is available, but they operate at a different architectural level (per-AP MAC features vs. building-scale data-plane unification) and cannot replace Fi-Wi's core innovations: centralized queues, shared state, L4S marking coordination, and dynamic RF grouping across the entire building.

D.1 Trigger Frames and Uplink Scheduling

802.11ax introduced trigger frames (TF) to enable centralized uplink scheduling. Instead of clients contending for the channel using stochastic EDCA backoff, the AP sends a trigger frame that grants specific clients permission to transmit on specific OFDMA resource units (RUs) or spatial streams at a specific time.

What trigger frames provide:

• Uplink OFDMA: Multiple clients can transmit simultaneously on different frequency resource units within the same channel, controlled by the AP's trigger frame.
• Uplink MU-MIMO: Multiple clients can transmit simultaneously on different spatial streams, again coordinated by the AP.
• Deterministic uplink airtime: The AP controls which clients transmit when, reducing contention and collision probability on the uplink.

How trigger frames align with Fi-Wi:

Trigger frames match Fi-Wi's philosophy of centralized scheduling rather than distributed contention. In a Fi-Wi deployment where RRHs support 802.11ax and clients support uplink OFDMA/MU-MIMO, the concentrator can:

• Generate trigger frames via RRHs to schedule uplink transmissions from multiple STAs
• Coordinate uplink RU allocation across an airtime domain to minimize collision and maximize spatial reuse
• Use shared state (CSI, queue levels, traffic patterns) to make smarter trigger scheduling decisions than an isolated AP could
• Treat uplink trigger-based transmissions as part of the same controlled airtime resource managed by the group queue

Reality check — client support in 2025:

While 802.11ax was ratified in 2019, uplink OFDMA support remains inconsistent. Crucially, trigger frames only control 802.11ax/be clients; legacy devices (iPhone 11, older IoT) are invisible to this schedule. These legacy clients cannot parse the trigger, so they continue to contend via random EDCA, acting as unmanaged interference sources. In contrast, Fi-Wi's reception diversity (Section 8.1) enhances uplink reliability for all clients, regardless of generation, by combining signals from multiple RRHs.

D.2 Why Trigger Frames Don't Eliminate the Need for Fi-Wi

A natural question: "If 802.11ax APs can use trigger frames for uplink scheduling, why do we need Fi-Wi's centralized architecture?"

Answer: Trigger frames address only a small subset of the problems Fi-Wi solves, and even for uplink scheduling, they provide per-AP control, not building-scale coordination.

What trigger frames do NOT provide:

1. Centralized queues across APs: Even with trigger frames, each AP maintains its own independent downlink and uplink queues. There's no shared queue state, no unified bottleneck, and no coordinated ECN marking across APs.
2. Shared state: Trigger-capable APs still operate autonomously. They don't share CSI, retry statistics, airtime usage, or queue metrics. Each AP makes trigger scheduling decisions based only on its local view.
3. Coordinated L4S marking: There's no mechanism in 802.11ax for multiple APs to coordinate ECN marking or present a single logical bottleneck to L4S. Each AP marks (or doesn't mark) independently.
4. Dynamic RF grouping: 802.11ax APs don't dynamically reconfigure which radios share airtime resources based on interference, CSI structure, or collapse risk. They're fixed islands.
5. Tail latency control: Trigger frames help with uplink efficiency, but they don't address the fundamental problem of hidden queues, uncontrolled aggregation, and tail latency blowup under load across a multi-AP building.

D.3 OFDMA Resource Units and Airtime Domains

802.11ax OFDMA subdivides a channel into resource units (RUs). In Fi-Wi, an airtime domain is a logical entity representing a shared RF resource. OFDMA RUs provide finer-grained subdivision of that airtime resource.

Conceptually:

• Without OFDMA: An airtime domain on channel 36 has one resource: the full 80 MHz channel. Only one transmission can occur at a time within that domain.
• With OFDMA: The same airtime domain can be subdivided into RUs. The concentrator's scheduler can allocate RU1 to STA-A, RU2 to STA-B simultaneously.

This does not change the fact that all RRHs in that airtime domain share a single group queue and marking point. It simply allows the service process to be more efficient.

D.4 BSS Coloring and Spatial Reuse

802.11ax BSS coloring allows STAs to distinguish between intra-BSS frames (same color) and inter-BSS frames (different color), enabling more aggressive spatial reuse.

Relationship to Fi-Wi RF grouping: Fi-Wi's dynamic RF grouping (Section 6) serves a similar but more sophisticated purpose. Fi-Wi uses richer information (CSI, retry statistics, airtime) to decide grouping, not just RSSI thresholds. In a Fi-Wi deployment, the concentrator can assign BSS colors to RRHs strategically: RRHs in the same airtime domain get the same color, while isolated domains get different colors.

D.5 802.11be (Wi-Fi 7) Multi-AP Coordination

802.11be (Wi-Fi 7) introduces multi-AP coordination features that appear to move in Fi-Wi's direction:

• Coordinated Spatial Reuse (C-SR): Multiple APs coordinate their transmissions to reduce mutual interference.
• Coordinated Beamforming (C-BF): APs share CSI and coordinate beamforming weights to improve SINR.
• Joint Transmission (JT): Multiple APs transmit the same data to a client simultaneously, providing diversity or increased SNR.

How these relate to Fi-Wi: These features acknowledge the problem of autonomous APs but approach it incrementally. 802.11be uses distributed AP-to-AP messaging, which limits scale and speed. Fi-Wi centralizes the data plane, enabling deeper coordination than distributed messaging can achieve.

D.6 Deployment Strategy: Mixed Client Populations

A key advantage of Fi-Wi's architecture is that it degrades gracefully with mixed client populations and doesn't require forklift client upgrades.

Client capability tiers in a 2025 deployment:

1. Legacy 802.11ac and earlier: No trigger frame support, no OFDMA, no BSS coloring.
   • Fi-Wi provides: centralized downlink queuing, L4S marking, reception diversity on uplink, beacon shaping to reduce contention.
   • Result: Significantly better latency and stability than traditional multi-AP, even without 802.11ax features.
2. 802.11ax with partial features: May support downlink OFDMA, BSS coloring, some power save enhancements, but not uplink OFDMA or uplink MU-MIMO.
   • Fi-Wi provides: All of the above, plus downlink MU-OFDMA where beneficial, coordinated BSS coloring across RRH groups.
   • Result: Better spatial reuse and efficiency, still robust to clients that don't support full 802.11ax.
3. 802.11ax with full features: Supports uplink OFDMA and uplink MU-MIMO via trigger frames.
   • Fi-Wi provides: All of the above, plus trigger-based uplink scheduling, uplink MU-OFDMA for small packets, coordinated uplink/downlink airtime management.
   • Result: Bidirectional sub-millisecond latency control, maximum airtime efficiency.
4. 802.11be (Wi-Fi 7): Adds MLO, 320 MHz channels, 4096-QAM, possibly multi-AP coordination support.
   • Fi-Wi provides: Can leverage MLO via concentrator coordination (Section 13.3), wider channels for capacity, and potentially integrate with 802.11be multi-AP features while maintaining superior shared-state coordination.
   • Result: Cutting-edge performance while maintaining backward compatibility.

Deployment strategy:

• Day 1: Fi-Wi delivers core benefits (low latency, L4S, collapse avoidance) with whatever client mix exists, including large populations of 802.11ac and partial-802.11ax devices.
• Ongoing: As clients are naturally refreshed, Fi-Wi automatically takes advantage of newer capabilities without requiring RRH hardware changes.

D.7 Summary: 802.11ax/be as Enhancements, Not Replacements

802.11ax and 802.11be introduce valuable features — trigger frames, OFDMA, BSS coloring, multi-AP coordination — that align with Fi-Wi's centralized control philosophy and can enhance Fi-Wi deployments when clients support them. However:

1. These features do not eliminate the need for Fi-Wi's architecture. They provide per-AP enhancements and limited inter-AP coordination, but they cannot create the unified data plane, shared state, and building-scale control that Fi-Wi provides.
2. Fi-Wi is designed to work with or without them. Core benefits (centralized queues, L4S marking, tail latency control) are independent of client 802.11ax/be support.
3. Fi-Wi leverages them when available. As client capabilities improve, Fi-Wi automatically benefits from trigger-based uplink scheduling, OFDMA efficiency, and other enhancements without requiring architectural changes.

In short: 802.11ax/be features make Fi-Wi better, but Fi-Wi solves problems these standards cannot address within the constraints of the distributed-AP model. Fi-Wi is not "better APs" — it's a different architecture that happens to integrate well with modern Wi-Fi standards as they evolve.

---

Appendix E: ASIC Evolution to Complexity

E.1 Why ASICs accumulate legacy complexity

Unlike software, ASICs cannot easily “refactor away” unused features. Removing blocks typically requires re-verifying entire subsystems, while adding blocks often requires verifying only the new logic. This asymmetry encourages accumulation:

• Removal risk > addition risk: removing a feature may impact existing customers in hard-to-observe ways; adding a feature does not threaten prior deployments.
• Career incentives favor addition: “I added feature X” is a visible win; “I removed 50K gates” is nearly invisible but carries blame if anything breaks.

Over many product generations, this leads to RTL codebases that only grow. Legacy modulation modes, preambles, power-save FSMs, calibration paths, and debug hooks persist long after their practical value has disappeared.

E.2 Real costs of legacy bloat

This accumulated complexity has tangible costs:

• Die area: more logic means a larger die, lower yield per wafer, and higher unit cost.
• Power: unused or rarely used blocks still consume leakage and often dynamic power.
• Verification: more RTL means more corner cases, more regressions, and longer bring-up.
• Timing closure: deep, interdependent datapaths make timing more difficult and fragile.

E.3 How Fi-Wi changes the design equation

Fi-Wi’s architecture separates the system into:

• Concentrator: complex, software-defined control plane and data plane intelligence.
• RRH: thin, timing-critical RF endpoint with minimal state.

This separation dictates where complexity must live. RRHs implement only what must be fast and deterministic: RF front end, PHY processing, minimal MAC TX/RX, DMA, PTP synchronization, and PCIe-over-fiber transport. All high-level behavior (queueing, L4S policy, aggregation strategy) lives in the concentrator.

E.4 Economic and engineering leverage

For a modern Wi-Fi chip at an advanced node, even a modest reduction in unnecessary logic can translate into significant savings: smaller die, lower power, simpler verification, and faster time to market.

E.5 Design principle for Fi-Wi RRH silicon

The guiding principle for Fi-Wi RRH design is:

Complexity belongs in the concentrator; only latency-critical functions belong in RRH silicon.

Concretely, this means: no autonomous AP queueing/scheduling logic, no legacy PHY/MAC support beyond what Fi-Wi needs, and no embedded firmware CPU managing per-station behavior at the edge.

---

Appendix F: A Day in the Life of a Packet (The "Preamble Shield" in Action)

To truly understand Fi-Wi, we must follow a single packet through the system at the microsecond scale. This narrative illustrates how the Workstation Concentrator (Section 13) and the Scatter-Gather RRH (Appendix C) collaborate to trick the physics of latency.

F.1 The Scenario

The Setting: Room 304 (Served by RRH-A and RRH-B). The Flow: A 4K Video Frame (Downlink) destined for "Alice's Laptop." The Constraint: L4S requires <1ms tail latency. The Challenge: The packet is currently 200 meters away in the Concentrator's DRAM.

F.2 The Downlink Race (The "Preamble Shield")

T = 0 µs (Arrival): The video packet arrives at the Concentrator's NIC. The CPU timestamps it immediately.

T = 2 µs (The Decision): The Concentrator's software scheduler inspects the packet.

• Queue Check: It places the packet in the "Room 304 Airtime" queue.
• L4S Check: Current sojourn time is low (50 µs). No ECN mark applied.
• RF Check: Recent CSI shows RRH-A has the best vector to Alice.

T = 10 µs (The Setup): The scheduler posts a DMA Descriptor to RRH-A via PCIe.
Note: The payload data (1500 bytes) stays in the Concentrator. Only a 16-byte pointer moves to the edge.

T = 50 µs (The Trigger): RRH-A's LBT logic sees the airtime is clear. It begins the transmission sequence. This is where the magic happens:

The Race Against the PHY:
Action 1: RRH-A starts transmitting the 802.11 Preamble (PLCP) from its local SRAM. This takes 20 µs of airtime.
Action 2: Simultaneously, RRH-A issues a PCIe Read Request to fetch the payload from the Concentrator.

The payload must travel 200m up the fiber and back before the Preamble finishes transmitting.

T = 52 µs (The Fetch): The Read Request hits the Concentrator's PCIe controller. Because of the 92-lane non-blocking fabric (Section 13), there is zero switching delay.

T = 55 µs (The Return): The payload data flies back down the fiber.

T = 58 µs (The Handover): The payload data arrives at RRH-A's FIFO. The PHY is just finishing the last symbol of the Preamble.

T = 59 µs (Seamless Serialization): The PHY seamlessly switches from transmitting the Preamble to transmitting the payload. To the air, it looks like one continuous stream. The 200-meter fiber latency effectively vanished because it was hidden behind the mandatory PHY training sequence.

F.3 The Uplink Journey (Diversity & Sensing)

T = 200 µs: Alice sends a TCP ACK.

T = 204 µs (The Multi-Stat): Both RRH-A and RRH-B hear the ACK.

• RRH-A sees a strong signal (-45 dBm).
• RRH-B sees a weak reflection (-72 dBm).

T = 210 µs (The Race Up): Both RRHs push the packet + CSI metadata to the Concentrator.

T = 215 µs (The Deduplication): The Concentrator sees two copies of Sequence #104. It discards the weak one from RRH-B but keeps the CSI data to update the "Sensing Model" (detecting that someone is standing near RRH-B, blocking the line of sight).

F.4 Contrast with Legacy Wi-Fi

If this were a traditional AP:

• Downlink: The packet would be buffered in a per-TID queue inside the AP hardware. It might wait behind a large aggregate for another user (Head-of-Line blocking). ECN marking would be speculative (based on enqueue time), likely missing actual congestion events. The "Preamble Shield" trick is impossible because the AP CPU can't fetch data reactively—it must buffer it proactively.
• Uplink: Only the associated AP would hear the ACK. If Alice moved slightly and blocked the signal, the packet might be lost, requiring a MAC-level retry (adding 2-5ms latency). Fi-Wi's diversity combining prevents this retry.

F.5 Edge Cases and Advanced Scenarios

RRH Failure: If RRH-A fails during the prefetch (e.g., power loss), the concentrator detects the link loss immediately via PCIe link state. Because the packet payload never left Concentrator DRAM, the scheduler simply re-posts the descriptor to RRH-B. No packet is lost, and TCP does not see a drop.

Congestion: The scatter-gather pipeline depth allows the Concentrator to queue up the next descriptor while the current one is transmitting. This allows back-to-back TXOPs (SIFS spacing) without idle gaps on the air, even with the fiber latency.

Coordinated Transmission: The Concentrator can schedule RRH-A and RRH-B to transmit concurrently to spatially separated clients. It analyzes the CSI matrix to determine if spatial isolation is sufficient (>25 dB cross-coupling attenuation). If yes, both RRHs transmit simultaneously using standard 802.11 frames. If interference is detected, the Concentrator schedules sequential TXOPs. This dynamic decision happens per-packet based on real-time CSI.

F.6 Summary: The Packet's Perspective

From the packet's view, Fi-Wi provides uplink diversity, per-flow fair queuing, accurate ECN marking, and speculative DMA that hides PCIe latency. The packet experiences the network as a transparent, zero-wait pipe.

F.7 The Critical Insight: Timing vs. Intelligence

Fi-Wi separates timing (RRH hardware) from intelligence (Concentrator software), bridged by the speculative DMA prefetch pipeline. This allows the hardware to meet strict microsecond deadlines while the software retains the flexibility to run complex scheduling, L4S, and spatial multiplexing logic.

---

Appendix G: The Strategic Case for Fiber Infrastructure

The upfront cost of installing fiber is often the primary friction point for C-RAN adoption ("The Fiber Tax"). However, this framing ignores the physics of modern signaling and the macroeconomics of construction. Fi-Wi's reliance on fiber is not a tax; it is a strategic asset conversion.

G.1 The Physics of 100G (The Copper Wall)

We are hitting a hard physical limit with copper cabling. At modern data center speeds (100Gb/s), signal loss in copper is so high it is characterized in dB per inch.

• High-Frequency Attenuation: 100Gb/s signaling requires Nyquist frequencies of 25-50 GHz. At these frequencies, skin effect and dielectric loss in twisted-pair copper make long-distance transmission physically impossible.
• The Reach Limit: In the data center, 100G copper DAC cables are limited to 1-3 meters. To run 100G+ speeds through a building's walls (50-100m), copper is effectively dead.
• Future-Proofing: Fiber defies this gravity. It carries 100G, 400G, or 800G over hundreds of meters. Installing Cat6A today guarantees a "rip-and-replace" expense tomorrow.

G.2 Labor Rate Hedging (Inflation Proofing)

In low-voltage construction, the cost of cabling is dominated by labor (often 70-80%), not material.

• The Inflation Trap: Construction labor rates rise over time. Relying on copper commits the owner to re-cabling cycles at future, higher rates.
• The Fiber Hedge: Installing fiber today locks in today's labor rates for a permanent infrastructure asset.

G.3 Asset vs. Consumable

Unlike HDMI or Copper Ethernet—which are purpose-built cables engineered for a single generation—fiber is a raw transport medium. It is a "pipe for light" that supports Ethernet, DWDM, and PCIe-over-Fiber simultaneously.

While cable standards have cycled (Cat5e → Cat6 → Cat6A), they remain tethered to the legacy RJ45 connector. This physical interface is rapidly becoming obsolete. Fi-Wi recognizes that the connection is what matters, not the physical port. In this architecture, the 802.11 wireless interface becomes the new connector. By installing fiber once as a permanent asset and treating Wi-Fi as the universal 'plug' inside the room, the building infrastructure is 'one and done'. This finally breaks the cycle of physical obsolescence.

Appendix H: Centralized Observability and the ML Advantage

Fi-Wi's centralized architecture provides observability that is difficult or impractical to achieve in distributed AP systems. This appendix presents the Observability Matrix—a systematic comparison of what telemetry is directly observable, partially observable, or hidden across different measurement approaches. This complete visibility is the prerequisite for effective machine learning (Section 15) and deterministic L4S control.

The Observability Gap

Traditional Wi-Fi deployments rely on tools that provide only partial visibility into system state. Operators attempt to infer problems from symptoms (latency spikes, ECN marks, throughput degradation) without directly observing root causes (queue growth, retry timing, MCS selection under interference). This inference distance—the number of steps between observable effects and hidden causes—makes control systems less stable and limits the effectiveness of machine learning.

The table below compares observability across six measurement approaches. The legend indicates:

Direct: Directly measurable with microsecond-resolution timestamps

Partial: Partially observable or requires inference

Not Observable: Hidden or cannot be reliably measured

Observability Matrix

Telemetry / Metric	ESP32-C5 RF sensor	RPi 5 Monitor mode	RPi 5 L4S node	tcpdump Packet capture	iperf2 L4S	Fi-Wi Concentrator
Energy detect / CCA
Channel busy time
NAV / medium reservation
CSI / channel matrix
MCS / GI / NSS
PER / retry counts
RSSI / SNR
Queue depth
Sojourn time
ECN marks
One-way delay (OWD)
Responsiveness
Throughput / goodput
Deterministic playback

Critical Observations

Queue Depth and Sojourn Time (highlighted rows):

These metrics are essential for L4S congestion control and machine learning. Traditional tools (tcpdump, Wi-Fi packet capture) cannot directly observe queue state because it exists inside firmware or kernel layers. While synchronized ingress and egress packet captures could theoretically infer queue depth through timing correlation, this approach requires nanosecond-precise time synchronization across physically separated capture points, perfect packet correlation despite potential losses, and still cannot observe firmware-internal retry queues, aggregation buffer states, or PHY scheduling decisions. External sniffers see the explosion (the packet hitting the air), but they cannot see the fuse burning (the packet sitting in the driver queue). Only centralized queueing architectures expose these values with direct microsecond-resolution timestamps.

MCS / GI / NSS (PHY Configuration):

Monitor-mode packet capture can partially infer MCS from radiotap headers, but this only shows what was transmitted—not the decision process, CSI data, or PER history that informed the choice. The Fi-Wi Concentrator has direct access to the complete decision state.

Deterministic Playback (bottom row):

This capability enables machine learning. Deterministic playback means the Concentrator can reproduce its own decision sequence from a log file: packet arrivals, queue transitions, scheduling decisions, MCS selections, and RRH transmission commands. While actual RF outcomes depend on station behavior and channel conditions that may vary, the Concentrator can replay its control decisions under the logged RF environment to evaluate alternative strategies offline and verify whether different MCS/scheduling choices would have improved performance. This is only possible when all Concentrator-controlled components operate under a single clock with complete state visibility. Distributed systems cannot reconstruct this causal chain from partial packet traces because they lack visibility into queue state, retry logic, and the decision-making process itself.

Why This Enables More Effective Machine Learning

Section 15 describes how Fi-Wi uses machine learning to optimize MCS transition rates. The observability matrix demonstrates significant practical advantages that Fi-Wi's centralized architecture provides for ML training:

• Direct Queue Observability: Can label training examples based on actual queue impact and sojourn time measurements
• Global CSI Visibility: Can learn cross-RRH interference patterns from centralized measurements
• Deterministic Replay Capability: Can evaluate whether alternative decisions would improve outcomes under the same conditions
• Low Inference Distance: 1-2 steps between PHY decisions and observable transport-layer effects versus 5-10 steps in distributed systems

Fi-Wi's centralized architecture provides these observability advantages. The Concentrator's event log becomes a high-quality training dataset where every state transition is labeled with measured outcomes under consistent instrumentation. While autonomous AP systems could attempt ML-based rate adaptation using the partial observability available to them, Fi-Wi's richer telemetry—particularly queue visibility, global CSI, and deterministic replay—enables significantly more effective learning and optimization.

Coordination Shares Outcomes; Fi-Wi Centralizes Causes

Coordinated AP systems can share summaries (throughput, ECN marks, interference reports) but cannot share hidden internal state (queue depth, firmware retry logic, aggregation decisions). This creates inference distance—the controller sees effects but not causes. Fi-Wi eliminates inference distance by removing autonomous decision-making from the edge. Queues, scheduling, and PHY selection are centralized under a single clock, producing an observable state graph where causes are explicit, replayable, and directly controllable. This architectural difference translates to measurably better ML training data quality.

Appendix I: Channel Width Orchestration and Service Time Variance

The Fi-Wi architecture treats channel width as a dynamic control parameter managed by the Concentrator. While 802.11be (Wi-Fi 7) emphasizes 320 MHz peak PHY rates, Fi-Wi's orchestration engine strategically selects 40 MHz channel widths in high-density environments to ensure Service Time Stationarity and the stability of the L4S control loop.

I.1 The Contention-Domain Collapse of Wideband Channels

In shared-spectrum MDUs (Multi-Dwelling Units), the theoretical gain of wider channels is often negated by contention-domain collapse. In a CSMA/CA environment, a transmission opportunity (TXOP) requires the entire bonded channel to be idle. In a 6-AP overlapping scenario with 50% aggregate airtime occupancy, the probability of finding all sub-bands simultaneously idle drops exponentially with bandwidth.

Under a simplified independent-sub-band occupancy assumption, a basic model suggests P(160 MHz idle) ≈ (P(40 MHz idle))^4, resulting in 4–16× fewer transmission opportunities. In practice, partial correlation between sub-bands moderates the exponent but does not eliminate the super-linear decline in idle probability. This leads to:

• Effective Airtime Utilization: 160 MHz utilization often falls below 10% due to fragmented TXOPs and CCA (Clear Channel Assessment) busy deferrals.
• NAV Extensions: A significantly higher probability of virtual carrier-sense freezes from neighboring uncoordinated cells occupying any portion of the wideband mask.

I.2 Queueing Theory and L4S Stability

From an M/G/1 queueing perspective, the performance of the L4S control loop depends on the stability of the service rate (μ). L4S stability requires frequent service opportunities and low variance in service time to prevent the decoupling of the sender's congestion window from the actual queue state.

• Service Time Variance (σ²): Wide channels in dense environments increase the variance of service time due to heavy-tailed CCA deferrals.
• Feedback Coherence: When a 160 MHz channel freezes for 100ms, it represents 2.5–20 RTTs of stale feedback for typical broadband RTTs (5–40 ms). Typical PI² parameterizations (Section 5.1) assume feedback coherence within a small number of RTTs; exceeding this threshold leads to oscillatory behavior.
• The 40 MHz Advantage: By providing a stationary service rate, 40 MHz ensures continuous ECN marking and stable RTT sampling, allowing the L4S loop to remain synchronized with the physical medium.

I.3 Link Adaptation and Spectral Robustness

Narrower channels reduce the probability that partial-band interference (e.g., unmanaged IoT bursts) forces a full MCS downgrade across the entire bonded width. This allows the Concentrator to maintain stable link adaptation and a predictable drain rate, avoiding the chaotic rate-shifting common in 160 MHz deployments.

I.4 Orchestration: Width as a Control Variable

Fi-Wi is not anti-wideband; channel width is an orchestrated variable. The system expands width opportunistically when contention is low to leverage PHY gains and contracts it to 40 MHz when deterministic latency is required. This prioritizes spatial reuse and airtime isolation over maximum burst rate—the fundamental technical unlock for Fi-Wi’s cell-per-room model.

I.5 Capacity Density: Throughput Under a Latency SLO

Fi-Wi optimizes Capacity Density under a Latency SLO, rather than peak PHY on a single link. In dense OBSS environments, wide channels reduce spatial reuse; narrower channels increase the number of bounded contention domains. Consequently, aggregate goodput per area increases even if per-link PHY decreases.

Metric Definition: Low-Latency Goodput Density (ρ_LL)

ρ_LL [Mbps / 1,000 sq ft] = (Σ Goodput_i) / Area | subject to p95 OWD ≤ 20ms

Where Goodput_i is the application-layer payload throughput delivered while maintaining the p95 one-way delay (OWD) constraint. The 20ms threshold reflects the target for interactive L4S applications.

Example Calculation (1,000 sq ft section of a 10,000 sq ft floor):

Assumptions: 50% aggregate offered load per BSS, default EDCA parameters, and no explicit inter-AP coordination in the autonomous case.

• 160 MHz Autonomous: 1 AP (Wide coverage) × 1.2 Gbps peak × 10% airtime efficiency ≈ 120 Mbps aggregate. Under heavy-tailed service intervals, a large fraction of packets violate the 20ms p95 constraint. When filtered by the latency SLO (ρ_LL definition), usable goodput is reduced to ~12 Mbps in this model.
• 40 MHz Fi-Wi: 8 RRHs (Cell-per-room) × 400 Mbps peak × 40% airtime efficiency ≈ 1,280 Mbps aggregate. Bounded service intervals allow nearly all traffic to meet the latency SLO, resulting in ~128 Mbps.

I.6 Application: Aligning Wireless Capacity to Gigabit WAN Service

To align with a Gigabit-class WAN service, the wireless architecture must match the aggregate wireline supply to orchestrated spatial demand. In a dense MDU, Contention Delay is 10–100× larger than serialization time. A single 160 MHz AP attempting to serve a Gigabit load creates a "fast but flaky" link that collapses under co-channel interference, delivering only a fraction of the ISP's provided capacity to real-time applications.

Fi-Wi resolves this by using 40 MHz orchestration to spread the Gigabit load across N coordinated spatial domains. This ensures that the building-wide wireless fabric can actually saturate a 1 Gbps WAN link with deterministic, multi-user goodput, rather than relying on single-device peak bursts that starve other users and destabilize shared airtime.

I.7 Aggregation Quantization and L4S Feedback Mismatch

L4S signals congestion at Layer 3 (IP ECN), but wideband Wi-Fi operates via massive Layer 2 A-MPDU aggregation to maintain PHY efficiency. This creates a fundamental control-loop mismatch:

• Feedback Sparsity: Massive 160 MHz aggregates transmit dozens of packets in a single burst. This results in "binary" feedback—either a massive burst of ECN marks or none at all—which prevents the PI² controller from calculating the smooth probability signal required for precise rate pacing.
• The Sawtooth Latency Trap: Wide channels induce a "fast but infrequent" cadence; the AP must buffer data longer to build efficient aggregates. This creates multi-millisecond stalls that look like random network noise to L4S senders, causing congestion window oscillation.
• Timing Incoherence: Traditional APs lose microsecond-level visibility once packets enter hardware aggregation pipelines. Fi-Wi's 40 MHz orchestration enforces smaller, frequent TXOPs (~250 µs), ensuring the MAC service frequency is significantly higher than the L4S control frequency, enabling accurate sojourn-time measurement and coherent ECN marking at the IP layer.

The Fi-Wi architecture addresses these challenges through its DualQ implementation (Section 5.2), which maintains separate queues for L4S and Classic traffic and performs per-packet sojourn time measurements at the Concentrator before entering the A-MPDU aggregation pipeline.

---

Comparison of Service Metrics (Dense MDU Contention Model)

Scenario: 2x2 MIMO, 6+ overlapping BSSIDs, shared unlicensed spectrum (5/6 GHz), 50% aggregate offered load, autonomous EDCA parameters. See Appendix J for full simulation parameters.

Metric	160 MHz (Autonomous CSMA)	40 MHz (Fi-Wi Orchestrated)
Peak PHY Rate (2x2, MCS 11)	~1.2 Gbps	~300-400 Mbps
Effective Airtime Utilization	<10% (Fragmented TXOPs)	30–50% (Planned reuse / Bounded domain)
Service Time Variance (σ²)	High (Heavy-tailed)	Low (Near-stationary)
Queue Service Interval (median)	Tens to >100 ms	5–15 ms (Stationary)
DualQ ECN Feedback Coherence	Sparse / Burst-marked	Continuous / Stable marking
Goodput Density (ρ_LL) (Mbps per 1,000 sq ft)	~12 Mbps (Overlapping contention domains)	~128 Mbps (8 RRHs, orthogonal 40 MHz channels)

Economic Conclusion: Under realistic dense MDU conditions, Fi-Wi's orchestrated 40 MHz architecture delivers ~10× higher usable goodput density compared to autonomous wide-channel deployments. This is the fundamental advantage of Fi-Wi: capacity scales with RRH density and spatial reuse, not channel width alone.

See Appendix J for detailed contention modeling and simulation methodology.

Appendix J: 10-Node MDU Simulation Methodology

This appendix details the Monte Carlo simulation and analytical models used to derive the Low-Latency Goodput Density (ρ_LL) metrics. The framework evaluates Fi-Wi's spatial capacity gains under realistic Multi-Dwelling Unit (MDU) contention scenarios.

J.1 Spatial and RF Environment Model

The simulation contrasts traditional wide-area coverage with Fi-Wi's localized orchestration.

Building & RF Assumptions:

• Geometry: 10,000 sq ft floor divided into 8 units (~1,250 sq ft each). Metrics are normalized to "per 1,000 sq ft" for comparative analysis.
• Path Loss Model: PL(d) = PL(d₀) + 10n log₁₀(d/d₀) + Xσ with n = 2.8.
• OBSS Overlap: Autonomous case assumes 6 neighboring BSSIDs audible at ≥ -62 dBm.
• Fi-Wi Isolation: 8 RRHs achieving >25 dB co-channel isolation through planned orthogonal reuse.

J.2 Contention and Backoff Logic

The simulation models 20 active stations (STAs) distributed across the 8-unit floor (average 2.5 STAs per unit). Service Time Variance (σ²) is calculated by observing the delay between TX_START and ACK_END across 10⁶ simulated TXOPs.

• Autonomous Case (160 MHz): All 20 STAs compete for the shared 160 MHz channel. Probability of transmission is modeled as: P(TX) = [1 - p_occ]^4, where p_occ is aggregate occupancy from overlapping neighbors.
• Fi-Wi Case (40 MHz): STAs are partitioned into 8 isolated airtime domains. P(TX) = 1 - p_local_occ, restricted to immediate room-level neighbors.

J.3 The ρ_LL Filtration Process

The Goodput Density is derived by filtering raw throughput through the 20ms p95 OWD constraint.

// Derivation for ρ_LL Calculation
for each packet i:
    delay_i = contention_delay + serialization_delay + retry_overhead
    if delay_i <= 20ms:
        accepted_payload += size_i
    else:
        dropped_from_goodput_metric++

ρ_LL = (accepted_payload) / (total_time * area)
  

J.3.1 Numerical Results and Derivation

The simulation produces the following goodput derivation for a 1,000 sq ft sections:

• 160 MHz Autonomous: 120 Mbps raw aggregate throughput. However, heavy-tail contention spikes cause 90% of packets to exceed the 20ms SLO. 120 Mbps * 0.10 = 12 Mbps ρ_LL.
• 40 MHz Fi-Wi: 1,280 Mbps raw aggregate throughput (across 8 orthogonal domains). Stationary service rate allows 99.8% of packets to meet the 20ms SLO. 1,280 Mbps * 0.998 = ~128 Mbps ρ_LL.

J.4 Traffic Model and Payload Composition

Traffic Type	% of Load	Constraint
Interactive (L4S/Gaming)	20%	Strict SLO subject
Streaming (4K Video)	50%	Freeze sensitive
Bulk (Background)	30%	Throughput focused

↑ Contents