[DESIGN RFC v3] AP Architecture for Wi-Fi-8 Multi-AP Coordination (MAPC)

[Abhishek Rajkapur Suryawanshi]

On 1/15/2026 6:17 AM, Johannes Berg wrote:
> On Wed, 2026-01-14 at 11:15 -0800, Jeff Johnson wrote:
>> On 1/12/2026 11:18 AM, Johannes Berg wrote:
>>> On Mon, 2026-01-12 at 20:12 +0100, Johannes Berg wrote:
>>>>
>>>> Why do you always want to let firmware be in control of everything?
>>>> Seems at least for some of this you'd really want the upper layers to
>>>> control it for purposes of coordination? How does the FW even know which
>>>> other AP it can coordinate with, isn't that something a network
>>>> controller would determine?
>>>
>>> A less generous reading of this could be: you guys want everything to be
>>> controlled by FW, so you don't have to open-source it in hostapd. Now
>>> you realize oops, don't really want to do all the security handshake in
>>> FW, so we need to ask hostapd and then we need keys and stations and all
>>> this stuff. So let's build something nobody else can use, upstream it
>>> and we get the best of both worlds - others will maintain the mac80211
>>> code for us anyway.
>>>
>>> Am I wrong? Is there a technical reason for not simply doing MAPC
>>> discovery/agreement negotiation etc. in hostapd as well, based on
>>> driver/hw/fw capabilities, and then you don't need all these strange
>>> "triggered by firmware" flows?
>>
>> My perception is that Qualcomm would love for all the Wi-Fi 8 functionality to
>> be in userspace and nl/cfg/mac80211 since then there would be no code
>> maintenance overhead on our part -- just you and the userspace maintainers.
> 
> :)
> 
>> But there are concerns about latency, and internal consensus is that some
>> aspects of this functionality has to be handled in firmware (or even hardware)
>> in order to meet customer KPIs. This comes from our history of supporting
>> large-scale deployments of APs, and the expectations of how Wi-Fi 8 will make
>> things better. That is why we are posting design RFCs, so that you, as well as
>> engineers from other vendors, can review our proposals and give your feedback
>> and counter-proposals. We want to avoid developing what might be an
>> architecturally pure design that doesn't actually meet customer needs.
> 
> Sure, that's fair.
> 
> Maybe I can just ask folks to spell out the constraints and reasoning
> behind the design?
> 
> Taking this specific example, it basically says "FW sends a request to
> hostapd, hostapd does the handshake and installs the MAPC station. This
> is how we think we should handle the MAPC stations."

hostapd controls and manages all MAPC related discovery and MAPC peer 
creation part. No trigger from firmware for MAPC Discovery Phase.

> It never says _why_ and how any of this happens. What's the magic thing
> only the firmware can do to figure out it should start coordinating a
> given AP? (Clearly that operation can't be concerned much about latency
> if it asks hostapd.)

In our offload architecture, the firmware monitors various telemetry 
and controls all data‑path‑related scheduling. That's the primary reason 
why our design requires offload-based trigger for MAPC feature. Additionally, 
the offload-based design only signals intent or need; hostapd still owns 
MAPC peer selection to kick-start the MAPC negotiation. This trigger will 
be configurable (i.e could be enable/disable from user-space).

> In fact I'd have expected that in certain cases some controller
> infrastructure sitting *on top of hostapd* would decide which APs
> coordinate with each other, rather than the firmware. Although I guess
> if you hear the beacon on the same channel with a good enough RSSI then
> you can coordinate.

Offload based MAPC negotiation trigger is primarily intended for 
non‑controller-based AP deployments. In controller‑based AP configuration
& deployments, controller is fully responsible for triggering hostapd to 
initiate the MAPC Negotiation Request (e.g., via centralized telemetry and 
policy enforcement). In these deployments, the offload base MAPC negotiation 
trigger shall be disabled.

> I could keep guessing - maybe there's a limited space to do this in FW?
> But there's not even anything built into the design where the firmware
> can ask to _remove_ it again, as far as I can tell, unless there was an
> (unstated) assumption that it can just delete the MAPC station and send
> a DEL_STATION notification about it.

Like offload based MAPC trigger intent for adding MAPC neighbors, it would 
be extended for the MAPC teardown intent as well. hostapd will still controls 
MAPC peer deletion & MAPC tear down protocol

> The document even says that phase 1 is discovery, and then goes to
> completely ignore phase 1 (it's hidden in FW), and describes basically
> only phase 2.

Phase 1 discovery is completely handled by hostapd, as outlined under
section (A)hostapd

>> And apologies for the "firehose" of both design and code, but we have a desire
>> to ship Wi-Fi 8 products using upstream code. I've passed along information
>> that you want our engineering team to focus on the base NPCA patches so that
>> there is the appropriate foundation. But in parallel we do also hope there is
>> engagement from other vendors on the Design RFCs we are posting. Our goal is
>> to upstream as much AP functionality as you can absorb.
> 
> Sure, and I appreciate that this is coming. I'm a little overwhelmed by
> having so many parallel things going on right now, and all the parallel
> design documents don't help.
> 
> Maybe this is the point where we consider inviting everyone who wants to
> a room for a few days? Even a video room might be better ;-) List some
> topics first, present the design briefly, etc.? But I don't know if it's
> just the medium.
> 
> johannes

Abhishek