From: bob.mcmahon@umbernetworks.com
To: Frantisek Borsik <frantisek.borsik@gmail.com>
Cc: David Lang <david@lang.hm>,
Cake List <cake@lists.bufferbloat.net>,
Make-Wifi-fast <make-wifi-fast@lists.bufferbloat.net>,
bloat <bloat@lists.bufferbloat.net>,
Jeremy Austin via Rpm <rpm@lists.bufferbloat.net>,
codel@lists.bufferbloat.net
Subject: [Cake] Re: "Fi-Wi is a new forwarding plane for wireless" - Bob McMahon
Date: Thu, 14 May 2026 21:38:04 +0200 [thread overview]
Message-ID: <709dac7800ee7ad92aafd4eab1c761d9@umbernetworks.com> (raw)
In-Reply-To: <CAJUtOOhBhC_ZKW+MOtzEYXVhTY+uSdwreUXg+dUrunLUVqGyWA@mail.gmail.com>
David,
Thanks for your response. I do think you've actually made the case for
Fi-Wi and not against it,
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
next prev parent reply other threads:[~2026-05-14 19:38 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-05-14 16:46 [Cake] "Fi-Wi is a new forwarding plane for wireless" - Bob McMahon Frantisek Borsik
2026-05-14 17:08 ` [Cake] " David Lang
2026-05-14 17:26 ` Frantisek Borsik
2026-05-14 19:38 ` bob.mcmahon [this message]
2026-05-14 19:55 ` David Lang
2026-05-15 11:11 ` bob.mcmahon
2026-05-15 13:57 ` David Lang
2026-05-15 14:18 ` David Lang
2026-05-15 15:17 ` bob.mcmahon
2026-05-19 13:52 ` [Cake] Re: [Bloat] " Livingood, Jason
2026-05-19 18:59 ` David Lang
2026-05-19 22:45 ` bob.mcmahon
2026-05-21 19:42 ` Frantisek Borsik
2026-05-21 20:02 ` dan
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://lists.bufferbloat.net/postorius/lists/cake.lists.bufferbloat.net/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=709dac7800ee7ad92aafd4eab1c761d9@umbernetworks.com \
--to=bob.mcmahon@umbernetworks.com \
--cc=bloat@lists.bufferbloat.net \
--cc=cake@lists.bufferbloat.net \
--cc=codel@lists.bufferbloat.net \
--cc=david@lang.hm \
--cc=frantisek.borsik@gmail.com \
--cc=make-wifi-fast@lists.bufferbloat.net \
--cc=rpm@lists.bufferbloat.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox