Umber Networks · IETF 127 · San Francisco · November 14–20, 2026

A Forwarding Plane for In-Building Wireless
From Contended to Scheduled 802.11

The Umber Networks Fi-Wi Evaluation Platform is an operational Fi-Wi system and instrumented evaluation platform for advancing a new in-building 802.11 architecture based on centralized forwarding and scheduling, with calibrated RF conditions, independent ground truth, and end-to-end measurement.

At IETF 127, attendees will be able to exercise the over-the-air system, inspect the controlled conducted test rig, and participate in the discussion around Scheduling of a Contended In-Building 802.11 Network.

1. Core Platform Components

The Fi-Wi Evaluation Platform integrates seven primary hardware, software, and measurement elements:

The distributed radio head is not an autonomous AP

The radio head combines an Umber-designed PCB, COTS M.2 Wi-Fi silicon, and a PCIe-over-fiber fronthaul interface using standard SFP optical modules. It appears to the UAX-8 Concentrator as a PCIe device across the Axon fiber link.

This physical split is central to the Fi-Wi architecture: radio hardware can be distributed through the building while forwarding and scheduling move to the centralized system.

2. Planned Hackathon Experiments

Attendee tests use the over-the-air path above. The repeatable engineering experiments use the controlled conducted path; Appendices A through C give the detailed H-matrix, MAC-load, switching, and ground-truth signal paths.

3. What We Are Not Claiming at IETF 127

The system shown at the Hackathon is not a completed centralized scheduler and is not a finished IETF protocol implementation. The scheduling logic remains under development.

The purpose is to make the problem experimentally concrete before protocol semantics ossify: real hardware, real distributed radio heads, standard routed traffic through the UAX-8 platform, controlled contention, a calibrated RF path, independent ground truth, and endpoint measurements.

4. IETF 127 Scheduling Side Meeting

During the meeting week, Umber plans an informal side meeting (booked through the IETF side-meeting process, separate from any formal BoF request) around the proposed work “Scheduling of a Contended In-Building 802.11 Network.” The intent is to gather transport, wireless, congestion-control, timing, and systems review and identify people interested in continuing the work. Whether a formal BoF is worth requesting for a later meeting is one of the questions the side meeting should answer.

The protocol is the interface, not the scheduler. The standards question is at the interoperability boundary: what information must be exchanged so endpoints, remote senders, radio heads, and forwarding-plane implementations can work together. The scheduler can be openly described, evaluated, and compared, but its decision algorithm does not need to be part of the protocol standard. The protocol defines the interfaces and semantics; implementations remain free to use different scheduling algorithms.

Discussion topics

• How scheduled service or grants should be represented.
• What telemetry must cross the forwarding-plane boundary.
• Clock-discipline and timing exchanges needed for coordinated operation.
• Interaction between centrally allocated wireless service and end-to-end congestion control.
• Which interfaces need interoperable semantics and which mechanisms should remain implementation-specific.
• What experiments and measurements are required before any future chartering decision.

5. Desired Outcome from IETF 127

A successful IETF 127 produces the following; a completed scheduler and a chartered working group are both later milestones:

• a working, inspectable Fi-Wi experimental platform;
• a repeatable controlled-contention test environment;
• an A/B parity result that validates the evaluation rig before later architecture comparisons;
• an independent ground-truth measurement path for validating experiments;
• useful technical criticism of the architecture and interface boundaries;
• engineers willing to continue the discussion after San Francisco;
• a sharper problem statement and experiment plan for subsequent IETF work.

6. Background Documents

Appendices A through D give the system architecture, shielded load-generator design, conducted H-matrix and ground-truth path, and iperf2 Android client views.

Appendix A. Whole-System Architecture

The evaluation platform supports two distinct test environments. The attendee path is over the air and uses Android devices against a local iperf2 server. The controlled path is conducted and uses a dedicated Raspberry Pi 5 station, the programmable 2×2 RF channel, injected MAC contention, A/B switching, and an independent ground-truth tap. Attendee phones do not pass through the H-matrix.

The two environments serve different purposes. The over-the-air path gives attendees an immediate way to install iperf2, join the UAX-8 network, and measure a local routed path. The conducted path provides repeatability: a known station, programmable H-matrix, controlled 802.11 MAC contention, A/B switching, and an independent observation point at essentially the DUT reference plane.

Appendix B. Shielded 802.11 MAC Load Generator

The MAC-load subsystem is a black-box RF environment from the perspective of the conducted evaluation rig. The 45-node ESP32-C5 farm, USB infrastructure, control/logging host, and radiated contention environment live inside the RF shielded enclosure. Two fixed sampling dipoles sample that internal RF environment and feed the two conducted load paths.

Each dipole feed exits through an SMA bulkhead and then passes through its own external attenuation before becoming MAC load #1 or MAC load #2. Those are the two load inputs used by the 2×2 H-matrix combiners.

The coupling is bidirectional

The RF path between the farm and the conducted test system is reciprocal. Transmissions from the selected DUT and the conducted station can propagate back through the switch, divider, combiner, attenuator, and sampling dipole into the enclosure, where the 45 nodes sense them at a level set by the MAC-load attenuation. The attenuation settings therefore control both how strongly the farm is coupled into the DUT and how strongly the farm can sense the test system. Together with node traffic and geometry, this supports calibrated mutual-contention and hidden-node modes. The ground-truth monitor observes traffic in both directions at the same reference plane.

The enclosure has six SMA bulkheads and a six-channel fiber bulkhead. Two SMA penetrations carry the conducted load outputs used at IETF 127; the remaining SMA penetrations are spare for future instrumentation or alternate geometries.

Appendix C. 2×2 H-Matrix and Ground-Truth Signal Path

The conducted STA is a Raspberry Pi 5 using an AW7915 2×2 802.11ax interface and iperf2. Its two antenna ports feed the H-matrix. On the DUT side, the ganged switches select System A or System B while preserving the same programmed channel and injected-load conditions.

• STA antenna 1 produces H11 and H21.
• STA antenna 2 produces H12 and H22.
• DUT port 1 receives H11 + H12 + MAC load 1.
• DUT port 2 receives H21 + H22 + MAC load 2.

The off-diagonal terms H12 and H21 cross between the path-processing tier and the combiner tier. That crossing is what makes this a true 2×2 matrix instead of two independent RF channels. Each H element carries its own programmable attenuation and phase control, allowing the amplitude and phase of each matrix element to be set independently.

Why the ground-truth path matters

The independent monitor must observe the same composite RF node presented to the A/B DUT after desired-path attenuation and phase control and with the MAC-load path coupled in. In the Vaunix topology, the Raspberry Pi 5 monitor uses two RF inputs: one connects directly to a port on the upper 4-way combiner and the other to a port on the lower 4-way combiner.

Because each 4-way combiner is passive and reciprocal, the monitor input and the SPDT common share the same conducted RF node, subject to the known combiner insertion loss and any fixed padding used on the monitor input. This lets the monitor record packet captures with per-frame PHY metadata independently of System A or System B.

The combiner loss, cable loss, and fixed monitor-input padding are per-port calibration constants and belong in the evaluation platform's calibration record.

Appendix D. iperf2 Android Client

The iperf2 Android client will be available through Google Play. Attendees will be able to install it on their own Android phones or tablets, associate to a UAX-8 radio head, and point the client at a local iperf2 server on the Hackathon network. Keeping the test endpoint local removes Internet-path variability, so what the phone measures is the UAX-8 routed path and the air around it.

The client exposes more than a single throughput number. It provides live views of responsiveness under load, throughput, RTT, load delay, congestion signaling, window/in-flight behavior, and related transport metrics. That makes it useful as the participant-facing measurement tool for the evaluation platform.

Bounceback + Working Load

Responsiveness while the path is busy, including live RPS and request/reply distribution.

TCP Capacity

Live throughput, RTT/load delay, retries, write blocking, CWND, bytes in flight, and queued data.

UDP L4S Capacity

Throughput and latency together with CE marking, marking probability, loss, and L4S congestion-control state.

Full iperf2 Android client documentation: https://iperf2.fi-wi.com/

Appendix E. IETF 127 Logistics and Owners

The items below are the execution gates for bringing the Fi-Wi Evaluation Platform to IETF 127. Owners should be assigned early enough that venue, RF, software-release, and comparison-system dependencies do not become last-minute blockers.