[Make-wifi-fast] Re: [Cake] "Fi-Wi is a new forwarding plane for wireless" - Bob McMahon

[bob.mcmahon@umbernetworks.com]

David,

Thanks for taking the time to collaborate. This kind of pushback helps.

The "why now" question is worth addressing directly because it changes 
the hardware economics argument.

The PCIe lane explosion in server and workstation class CPUs, driven 
entirely by AI and HPC demand, made the memory-domain architecture 
feasible without custom silicon today. Threadripper PRO, EPYC, Sapphire 
Rapids: 128+ lanes designed to feed GPU arrays. (Technologies like DPDK 
and IOMMUs also help.) The RRH silicon is commodity 802.11 (MediaTek 
MT7922/MT7925).

In semiconductors, costs are dominated by Non-Recurring Engineering 
(NRE), the up front investment in chip design, IP blocks, and mask sets, 
not the marginal cost to manufacture each unit. A mobile Wi-Fi chip 
costs $3-8 not because it's cheap to design, but because $40-50B in NRE 
was spread across two billion units a year. Umber gets access to that 
fully amortized NRE at commodity prices. The fiber optics ride the same 
dynamic via data center volumes. PCIe retimers are a more recent 
addition to this ecosystem, developed to extend high-speed PCIe signals 
across longer distances inside AI clusters and hyperscale data centers. 
Without them, PCIe-over-fiber at building scale would not be practical. 
Umber assembles components whose development costs were paid by other 
industries. That's the near-term hardware story.

The longer-term story for our industry is different. Following O-RAN's 
split 8, the functional split between RF and all digital processing, 
puts the z-domain (digital signal processing) and MAC for a building or 
complex entirely at the concentrator. That requires a new class of RRH 
silicon optimized for centralized architectures rather than autonomous 
AP operation. There is significant industry interest in winning that 
socket.

When fiber-to-the-room (FTTR) scales worldwide, the unit volumes for RRH 
silicon will exceed mobile. Every room in every building is a space to 
serve, with likely multiple RRHs per room. This is analogous to LED 
bulbs used for illumination. These worldwide volumes justify new NRE, 
and several silicon companies are watching this space closely. Those 
that engage early have a higher probability of becoming the primary 
supplier.

On your stepping-stone question: OpenWRT and dawn get us partway. The 
ceiling is the MAC still running autonomously inside each AP, making 
local decisions without global RF state. A shared memory-domain 
architecture makes globally scheduled transmission practical in ways 
autonomous AP architectures cannot. You can steer clients with dawn; you 
cannot schedule transmissions across RRHs. That distinction is the 
difference between optimizing a CSMA/CA system and replacing it.

On dawn/usteer and 802.11r/k: these are steering protocols layered on 
top of CSMA/CA. They help clients find a better AP but each AP still 
contends independently for the medium. No global scheduler, no 
coordinated transmission, no spatial stream coordination across RRHs. 
These systems improve client placement within a distributed contention 
architecture. Fi-Wi instead centralizes airtime scheduling itself.

On what improves first and is measurable: roaming latency drops to near 
zero because association never changes. Hidden node problems disappear 
because there is no contention. MU-MIMO utilization becomes a scheduling 
decision rather than a statistical outcome. Deterministic latency, which 
802.11 cannot guarantee by design, becomes a first-class deliverable. 
Those are the metrics we will be publishing from real building 
deployments through this year.

Bob

On 2026-05-14 21:55, David Lang wrote:
> bob.mcmahon@umbernetworks.com wrote:
> 
>> Thanks for your response. I do think you've actually made the case for 
>> Fi-Wi and not against it,
> 
> I took a quick look at the slide deck that was posted, and where there 
> is a little I quibble with (CDMA hasn't really been a thing on ethernet 
> since the migration to switches) there is a lot more here than the 
> email that I replied to was explining
> 
> I haven't gone through all of it by any means, but it may be that the 
> way to present this is more of a 'switching layer for wifi'. You talk 
> about new hardware designs, but that's going to be rather expensive to 
> do. what can be done with existing chips? Especially with OpenWRT 
> (including custom firmware for the wifi chipsets). If it's something 
> that can be deployed and experimented with under real-life conditions, 
> that can then justify the specialized chips.
> 
> I think that lot of the wifi chip design today is offloading complexity 
> so that the chips can be attached to very low-end CPUs, and that 
> carries over into the AP design as well (I really don't understand why 
> so many high-end devices put such puny CPUs in the center. I get that 
> the ASICs push the load out, but when you are talking about devices 
> that run thousands of dollars each, shaving tens of dollars to put a 
> very low-end cpu in the core doesn't seem like the best idea)
> 
> again, I haven't finished going through the slide deck, so apologies if 
> you have already covered this, but you also need to explain why this is 
> better than the current dawn/usteer 802.11r/k solutions
> 
> David Lang
> 
>> I completely agree with you that more distributed fixed radios improve 
>> RF performance. That's the architecture. Fi-Wi isn't one or a few 
>> routers. It's many RRHs distributed across the building, all connected 
>> via fiber to a single scheduler with full building RF state. The more 
>> RRHs, the better the channel geometry.
>> 
>> On mobility: Fi-Wi handles intra-building mobility, a client moves, 
>> the scheduler sees the channel state change across all RRHs and 
>> reassigns the client seamlessly, with no IP address change and no L3 
>> state machine involved. IP routing handles inter-building mobility. 
>> These aren't competing; they're different layers solving different 
>> scopes of the problem.
>> 
>> On aggregates: the groupings are entirely dynamic. The scheduler 
>> decides per interval, based on live queue state and live channel 
>> state, which clients aggregate together and on which RRH. Nothing is 
>> static.
>> 
>> The lab-vs-real-world concern is fair to raise. We have hardware 
>> deployed with 24 radio heads and will be taking measurements in real 
>> buildings through this year. A 48 radio head system should be 
>> available end of the year.
>> 
>> Bob
>> 
>> On 2026-05-14 19:26, Frantisek Borsik wrote:
>> 
>>> Thanks, David. Bob's latest slide deck can add more info on this: 
>>> https://www.umbernetworks.com/DPDK_WiFi_Stockholm_Pres.html
>>> 
>>> He is here, but I'm adding him directly.
>>> 
>>> All the best,
>>> 
>>> Frank
>>> 
>>> Frantisek (Frank) Borsik
>>> 
>>> In loving memory of Dave Täht: 1965-2025
>>> 
>>> https://libreqos.io/2025/04/01/in-loving-memory-of-dave/
>>> 
>>> https://www.linkedin.com/in/frantisekborsik
>>> 
>>> Signal, Telegram, WhatsApp: +421919416714
>>> 
>>> iMessage, mobile: +420775230885
>>> 
>>> Skype: casioa5302ca
>>> 
>>> frantisek.borsik@gmail.com
>>> 
>>> On Thu, May 14, 2026 at 7:09 PM David Lang <david@lang.hm> wrote:
>>> 
>>>> This approach seems like it would work when you have one or a small 
>>>> number of
>>>> fi-wi routers covering an area and the users are static
>>>> 
>>>> but that's bad RF engineering. having more different fixed stations 
>>>> really
>>>> improves your RF performance. Combine that with devices moving 
>>>> around and you
>>>> are not forwarding in the wifi layer, you need to forward based on 
>>>> where the
>>>> stations are. For that, the IP address (and trditional IP routing) 
>>>> would seem to
>>>> be the answer,
>>>> 
>>>> Even when looking at transmissions to multiple stations (I assume 
>>>> that's what is
>>>> meant by aggregates), that depends on both what stations are where 
>>>> and what data
>>>> there is to transmit. the groupings should not be even remotely 
>>>> static
>>>> 
>>>> Now, I may have misunderstood things, and I am alwasys aware of the 
>>>> concept that
>>>> the person saying that something can't be done shouldn't interfere 
>>>> with the
>>>> person doing it, but this sounds like something that would work well 
>>>> in a lab
>>>> and fail miserably outside of those very controlled conditions.
>>>> 
>>>> David Lang
>>>> 
>>>> On Thu, 14 May 2026, Frantisek Borsik wrote:
>>>> 
>>>>> Interesting food for though:
>>>>> 
>>>>> "Fi-Wi is a new forwarding plane for wireless.
>>>>> 
>>>>> IP routing maps destination prefix → next hop. Ethernet bridging 
>>>>> maps
>>>>> learned MAC → port. Fi-Wi maps 802.3 aggregates (A-MPDU) → (RRH, 
>>>>> orthogonal
>>>>> slot), where an orthogonal "slot" spans time, carrier frequencies, 
>>>>> and
>>>>> eigenspaces.
>>>>> 
>>>>> Current 802.11 needs a forwarding plane. CSMA/CA via APs is 
>>>>> collision
>>>>> avoidance -- delivery is emergent, no global state, no forwarding 
>>>>> decision.
>>>>> Fi-Wi replaces that with centralized decision-making running over
>>>>> distributed Remote Radio Heads, connected via PCIe-over-fiber as
>>>>> cache-coherent, switched DRAM. Every RRH's queue state, channel 
>>>>> state, and
>>>>> TSF clock visible to the scheduler in a single memory domain.
>>>>> 
>>>>> Same architectural leap that IP made for L3 and Ethernet made for 
>>>>> L2. A new
>>>>> industry serviced by routers. Another new industry serviced by 
>>>>> switches.
>>>>> Fi-Wi isn't a new product, it's a third forwarding plane, and an 
>>>>> industry
>>>>> yet to be built.
>>>>> 
>>>>> Umber Networks. The first company building Fi-Wi."
>>>>> 
>>>>> https://www.linkedin.com/feed/update/urn:li:activity:7460693793390968832/
>>>>> 
>>>>> All the best,
>>>>> 
>>>>> Frank
>>>>> 
>>>>> Frantisek (Frank) Borsik
>>>>> 
>>>>> 
>>>>> *In loving memory of Dave Täht: *1965-2025
>>>>> 
>>>>> https://libreqos.io/2025/04/01/in-loving-memory-of-dave/
>>>>> 
>>>>> 
>>>>> https://www.linkedin.com/in/frantisekborsik
>>>>> 
>>>>> Signal, Telegram, WhatsApp: +421919416714
>>>>> 
>>>>> iMessage, mobile: +420775230885
>>>>> 
>>>>> Skype: casioa5302ca
>>>>> 
>>>>> frantisek.borsik@gmail.com
>>>>> _______________________________________________
>>>>> Cake mailing list -- cake@lists.bufferbloat.net
>>>>> To unsubscribe send an email to cake-leave@lists.bufferbloat.net