* [DESIGN RFC v3] AP Architecture for Wi-Fi-8 Multi-AP Coordination (MAPC)
@ 2026-01-12 18:52 Abhishek Rajkapur Suryawanshi
2026-01-12 19:12 ` Johannes Berg
0 siblings, 1 reply; 8+ messages in thread
From: Abhishek Rajkapur Suryawanshi @ 2026-01-12 18:52 UTC (permalink / raw)
To: ath12k, hostap, johannes; +Cc: linux-wireless
Hello Everyone,
This RFC presents a high-level design proposal for Multi-AP Coordination
framework in IEEE 802.11bn (Wi-Fi 8).
The design is based on IEEE 802.11bn-D1.1 (as of Dec 2025) and may be
updated based on future draft updates.
We hope to gather feedback on the proposed architecture and subsystem
integration strategy. This document does not include implementation
patches or code and is intended solely for design-level discussion.
==============================
Table of Contents
==============================
(1) Introduction & Scope
(2) Background
(3) Proposal
(3.1) Control Path
==============================
(1) Introduction & Scope
==============================
The IEEE 802.11bn specification has introduced the concept of
Multi-AP Coordination (MAPC) framework which includes set of
schemes (such as Co-BF, Co-SR, Co-TDMA, Co-RTWT and Co-CR) and
procedure in which APs operating their BSSs on the same primary
20 MHz channel coordinate to reduce interference and to improve
network performance, such as medium utilization efficiency,
communication reliability, and latency.
The scope of this RFC is as follows:
1. Enable MAPC framework support across hostapd, mac80211,
cfg80211 and WLAN-drivers up to 802.11bn-D1.1
2. Focus on AP-side support
- Capability exchange
- Feature-specific negotiation
- MAPC context management
3. Focus on WiFi based inter-AP coordination
Multi-AP coordination over wired connections will be
added later, based on specification updates
The following sub-features of the MAPC framework will be deferred
to subsequent versions of this RFC, as the specification is still
evaluating options for MAPC frame handling in multi-cohosted VAP
and MBSSID scenarios:
- MAPC security
Patches will be proposed in the subsequent version of the RFC once
we have achieved general consensus on the architecture.
==============================
(2) Background
==============================
The MAPC framework operates in three phases:
- Phase 1 Discovery
AP advertise MAPC capabilities and common parameters using
Public Action MAPC Discovery Request/Response frames
(Ref.IEEE 802.11bn-D1.1, 9.6.7.65 to 9.6.7.66).
- Phase 2 Negotiation
AP establish, update, or teardown scheme-specific agreements
(e.g., Co-BF, Co-SR, Co-TDMA, Co-RTWT, Co-CR) using individually
addressed MAPC Negotiation Request/Response frames
(Ref. IEEE 802.11bn-D1.1, 9.6.7.68 to 9.6.7.69).
- APID Assignment
When establishing the first MAPC agreement the AP assigns
an APID to the peer AP (Ref. IEEE 802.11bn-D1.1, 9.4.1.8).
APIDs share the AID pool(1 to 2006) with non-AP STAs.
APIDs remain valid while any agreement exists.
- Phase 3 Operations
Feature specific frame exchange with peer AP for the established
agreement.
=============================
(3) Proposal
=============================
(3.1) Control Path (MAPC)
The MAPC control path is handled in user space by hostapd. The kernel
layers (cfg80211 and mac80211) pass the required information to the
WLAN driver.
Figure 1: Proposed Subsystem Integration for MAPC
-----------------------------------------------------
+---------------------------------------------------------------+
| hostapd |
| |
| +----------------------+ +----------------------+ |
| | MAPC Discovery | | MAPC Negotiation | |
| +----------------------+ +----------------------+ |
| |
| +----------------------+ +----------------------+ |
| | MAPC Peer Mgmt | | MAPC Security | |
| +----------------------+ +----------------------+ |
| |
| +----------------------+ |
| | NL80211 | |
| +----------------------+ |
+---------------------------------------------------------------+
+---------------------------------------------------------------+
| cfg80211 |
| |
| +----------------------+ |
| | NL80211 | |
| +----------------------+ |
+---------------------------------------------------------------+
+---------------------------------------------------------------+
| mac80211 |
| |
| +----------------------+ |
| | MAPC Peer Mgmt | |
| +----------------------+ |
+---------------------------------------------------------------+
+---------------------------------------------------------------+
| WLAN Driver (e.g., ath12k) |
| |
| +----------------------+ +---------------------------+ |
| | MAPC Peer Mgmt | | MAPC Policy Config Mgmt | |
| +----------------------+ +---------------------------+ |
| |
| +---------------------------+ |
| | MAPC Event Gen/Notify | |
| +---------------------------+ |
+---------------------------------------------------------------+
(A) Hostapd
- Protocol Parsing & MAPC context management:
hostapd handles the transmission and reception of MAPC
Discovery and MAPC Negotiation public action frames with
neighboring APs.
- MAPC discovery:
- After BSS setup, hostapd may initiate MAPC Discovery
exchanges with neighboring APs.
- On receiving a MAPC Discovery frame from a peer AP,
hostapd:
- Extracts MAPC capabilities, common parameters and
(if present) Per Scheme Profiles.
- Creates a MAPC peer in hostapd and triggers peer
creation in the kernel using NL80211_CMD_NEW_STATION
with NL80211_ATTR_MAPC_PEER, marking the station as a
MAPC peer.
Figure 2: MAPC Discovery Sequence
-----------------------------------------------------
+--------------------------------------------------------------------+
| UHR AP-1 |
| +---------+ +---------+ +---------+ +---------+ | +---------+
| | | | | | | | | | | |
| | hostapd | | cfg80211| | mac80211| | wlan | | | UHR |
| | | | | | | | driver | | | AP-2 |
| +----+----+ +----+----+ +----+----+ +----+----+ | +----+----+
| | | | | | |
| +----+---------------+ | | | | |
| | init hostapd & HW | | | | | |
| | MAPC support update| | | | | |
| +----+---------------+ | MAPC Discovery | | | |
| | | Request | | | |
| | |(MAPC capability)| | | |
| +-----------------+-----------------+-----------------+------|------>
| | | MAPC Discovery | | | |
| | | Response | | | |
| | |(MAPC capability)| | | |
| <-----------------+-----------------+-----------------+------|------+
| | | | | | |
| +----+---------------+ | | | | |
| |alloc sta_info store| | | | | |
| |MAPC capa & params | | | | | |
| +----+---------------+ | | | | |
| | | | | | |
| nl80211_new_station() | | | |
| +-----------------> | | | |
| |(attr MAPC_PEER) | | | | |
| | | | | | |
| | |rdev_add_station() | | |
| | +-----------------> | | |
| | | | | | |
| | | +-----------------+ | | |
| | | | alloc mapc sta | | | |
| | | | object | | | |
| | | +-----------------+ | | |
| | | | | | |
| | | +-----------------> | |
| | | | | | |
| | | | +-----------------+| |
| | | | | alloc mapc sta || |
| | | | | object || |
| | | | +-----------------+| |
| | | | | | |
| v v v v | v
+--------------------------------------------------------------------+
- MAPC Negotiation:
- hostapd initiates and responds to MAPC Negotiation
exchanges for one or more schemes. When a negotiation
completes successfully:
- hostapd programs the APID and per-scheme parameters
into the kernel via NL80211_CMD_SET_STATION.
- When all MAPC agreements with a peer AP are removed,
hostapd deletes the MAPC peer from the kernel using
NL80211_CMD_DEL_STATION
Figure 3: MAPC Negotiation Sequence (ESTABLISHMENT/UPDATE)
---------------------------------------------------------
+--------------------------------------------------------------------+
| UHR AP-1 |
| +---------+ +---------+ +---------+ +---------+ | +---------+
| | | | | | | | | | | |
| | hostapd | | cfg80211| | mac80211| | wlan | | | UHR |
| | | | | | | | driver | | | AP-2 |
| +----+----+ +----+----+ +----+----+ +----+----+ | +----+----+
| | | | | | |
| | | | +--------------+-----+| |
| | | | | Notify hostapd to || |
| | | | | Trigger MAPC || |
| | | | | Negotiation || |
| | | | +--------------+-----+| |
| | NL80211_CMD_MAPC_NEGOTIATION_TRIGGER(scheme-id,action) | |
| <-----------------+-----------------+-----------------+ | |
| +----+---------------+ | | | | |
| |parse scheme-id & | | | | | |
| |action. Init MAPC | |MAPC Negotiation | | | |
| | Negotiation | | Request | | | |
| +----+---------------+(scheme params & APID1 | | |
| | Optype:ESTABLISHMENT/UPDATE) | | |
| +-----------------+-----------------+-----------------+------+------>
| | |MAPC Negotiation | | | |
| | | Response | | | |
| | (scheme params & APID2 | | |
| | Optype:ACCEPT/REJECT/ALTERNATE) | | |
| <-----------------+-----------------+-----------------+------+------+
| +----+---------------+ | | | | |
| |store APID & scheme | | | | | |
| |params. | | | | | |
| +----+---------------+ | | | | |
| | | | | | |
| nl80211_set_station() | | | |
| +-----------------> | | | |
| | (MAPC scheme | | | | |
| | info & APID) |rdev_set_station() | | |
| | +-----------------> | | |
| | | +-----------------> | |
| | | | | | |
| | | | +--------------+| |
| | | | | MAPC Policy || |
| | | | | config set || |
| | | | +--------------+| |
| | | | | | |
| v v v v | v
+--------------------------------------------------------------------+
[NOTE] MAPC Negotiation AGREEMENT_UPDATE does not modify
the APID assigned during AGRREMENT_ESTABLISHMENT
Figure 4: MAPC Negotiation Sequence (TEARDOWN)
-----------------------------------------------------
+--------------------------------------------------------------------+
| UHR AP-1 |
| +---------+ +---------+ +---------+ +---------+ | +---------+
| | | | | | | | | | | |
| | hostapd | | cfg80211| | mac80211| | wlan | | | UHR |
| | | | | | | | driver | | | AP-2 |
| +----+----+ +----+----+ +----+----+ +----+----+ | +----+----+
| | | | | | |
| | | | +---------------+-----+| |
| | | | |Notify hostapd to || |
| | | | |Trigger MAPC || |
| | | | |Negotiation(Teardown)|| |
| | | | +---------------+-----+| |
| | NL80211_CMD_MAPC_NEGOTIATION_TRIGGER(scheme-id,action) | |
| <-----------------+-----------------+-----------------+ | |
| +----+----------------+| | | | |
| |parse scheme-id & || | | | |
| |action. Init MAPC || | | | |
| |Negotiation(Teardown)|| | | | |
| +----+----------------+|MAPC Negotiation | | | |
| | | Request | | | |
| | |(Optype:TEARDOWN)| | | |
| +-----------------+-----------------+-----------------+------+------>
| | |MAPC Negotiation | | | |
| | | Response | | | |
| | | (Optype:ACCEPT) | | | |
| <-----------------+-----------------+-----------------+------+------+
| +----+----------------+| | | | |
| |If agreement count || | | | |
| |is zero for MAPC peer|| | | | |
| |then initiate MAPC || | | | |
| |peer delete || | | | |
| +----+----------------+| | | | |
| | | | | | |
| nl80211_del_station() | | | |
| +-----------------> | | | |
| | | | | | |
| | |rdev_del_station() | | |
| | +-----------------> | | |
| | | +-----------------> | |
| | | | | | |
| | | | +--------------+| |
| | | | | MAPC peer || |
| | | | | clean-up || |
| | | | +--------+-----+| |
| | | | | | |
| | | | | | |
| | | | | | |
+-------v-----------------v-----------------v-----------------v------+ v
[NOTE] The MAPC peer concept is necessary because the
specification defines protected-dual variants of
the MAPC Negotiation Request and Response frames.
When secured MAPC negotiation is required, each
coordinating AP must maintain a separate MPASN derived
security context for every neighboring AP.
(B) cfg80211
cfg80211 handles the following commands and notifications for MAPC
- NL80211_CMD_NEW_STATION: to create a MAPC station for an MAPC
peer, marked by NL80211_ATTR_MAPC_PEER.
- NL80211_CMD_SET_STATION: to set APID and per scheme parameters.
- NL80211_CMD_DEL_STATION: to delete MAPC stations
- NL80211_CMD_GET_STATION: to retrieve MAPC station information
New notifications from cfg80211 to user space:
- NL80211_CMD_MAPC_NEGOTIATION_TRIGGER
Direction: kernel to user space.
Source: cfg80211 on behalf of the WLAN driver/firmware.
Purpose: Provide a hint to hostapd that MAPC Negotiation
Request should be triggered on this interface. For each
MAPC scheme, the driver/firmware may request establishment,
update, or teardown of an agreement. hostapd is expected
to apply policy and iterate over the locally known MAPC
peers for this interface.
Attributes:
- NL80211_ATTR_MAPC_SCHEMES (nested)
Contains one or more per-scheme MAPC negotiation hints. Each
nested entry includes:
- NL80211_ATTR_MAPC_SCHEME_TYPE
Identifies the MAPC scheme (e.g., Co-BF, Co-SR, Co-TDMA,
Co-RTWT, Co-CR).
- NL80211_ATTR_MAPC_ACTION
Requested negotiation action for this scheme:
- NL80211_MAPC_ACTION_ESTABLISH: establish new agreement(s).
- NL80211_MAPC_ACTION_UPDATE: update existing agreement(s).
- NL80211_MAPC_ACTION_TEARDOWN: teardown existing agreement(s).
(C) mac80211
Two design options are considered for representing MAPC peers in
mac80211:
Option-A(Preferred): Reuse existing station management infra
- Allocate standard station objects (struct sta_info / struct
ieee80211_sta) to represent MAPC peers, and call the WLAN driver.
- Use a subset of the existing mac80211 station states (NOTEXIST,
NONE, AUTH) to represent a MAPC stations.
- Receive MAPC parameters from cfg80211 and forward them to the
WLAN driver (for example, via existing station update paths).
- Use NL80211_ATTR_MAPC_PEER to mark a station as a MAPC station,
so that data path features (e.g., rate control, aggregation,
buffering) can be bypassed.
Pros:
- Minimal changes to existing mac80211 data structures and state
machine.
- Reuses existing add_station / sta_state transitions and driver
callbacks.
Cons:
- Overloads the full station infra for control only usage.
Option-B: Define lightweight MAPC peer/station management
infra
In this option, mac80211 defines a lightweight MAPC station
management infra, decoupled from normal data-path stations:
- MAPC requesting and responding APs exchange only management/control
frames. Most datapath related fields in the existing sta_info/
ieee80211_sta structures are not applicable.
- Defines a lightweight MAPC station object
(e.g., struct ieee80211_mapc_sta)to hold MAPC peer context,
including:
- Peer MAC address (BSSID), APID, MAPC security context. MAPC
capabilities and common parameters.
- A separate MAPC station list is maintained in mac80211 to track
all MAPC stations.
New mac80211 to driver callbacks to be introduced, for example:
- add_mapc_station() create a MAPC peer/station in the
driver.
- change_mapc_station() update APID and scheme parameters for an
existing MAPC peer/station.
- del_mapc_station() delete a MAPC peer/station in the driver
Pros:
- Clean separation between datapath stations and MAPC control only
stations.
Cons:
- Requires new data structures and callbacks in mac80211 and WLAN
driver.
- Slightly larger implementation versus Option A.
(D) WLAN Driver
- The WLAN driver maps MAPC stations from mac80211 into driver
peers and programs scheme specific parameters for Phase 3
operations.
- MAPC station/peer creation and deletion:
For Option A:
- Reuse standard station callbacks (add_station, change_station,
remove_station) and treat the MAPC peers as control-only
(no data-path handling).
For Option B:
- Implement the new MAPC-specific callbacks (add_mapc_station,
change_mapc_station, del_mapc_station) to manage MAPC peers.
- Event reporting:
- Inform mac80211/cfg80211 that MAPC negotiation should be
establish, update or torn down with
NL80211_CMD_MAPC_NEGOTIATION_TRIGGER.
Regards,
Abhishek
^ permalink raw reply [flat|nested] 8+ messages in thread* Re: [DESIGN RFC v3] AP Architecture for Wi-Fi-8 Multi-AP Coordination (MAPC)
2026-01-12 18:52 [DESIGN RFC v3] AP Architecture for Wi-Fi-8 Multi-AP Coordination (MAPC) Abhishek Rajkapur Suryawanshi
@ 2026-01-12 19:12 ` Johannes Berg
2026-01-12 19:18 ` Johannes Berg
0 siblings, 1 reply; 8+ messages in thread
From: Johannes Berg @ 2026-01-12 19:12 UTC (permalink / raw)
To: Abhishek Rajkapur Suryawanshi, ath12k, hostap; +Cc: linux-wireless
Hi,
I wish you guys (generally Qualcomm, not you personally) could finish
one thing before opening yet another ;-)
Couple of quick comments:
> +---------------------------------------------------------------+
> > WLAN Driver (e.g., ath12k) |
> > |
> > +----------------------+ +---------------------------+ |
> > | MAPC Peer Mgmt | | MAPC Policy Config Mgmt | |
> > +----------------------+ +---------------------------+ |
> > |
> > +---------------------------+ |
> > | MAPC Event Gen/Notify | |
> > +---------------------------+ |
> +---------------------------------------------------------------+
I think you need to do a lot more to explain why this is in firmware?
> +--------------------------------------------------------------------+
> > UHR AP-1 |
> > +---------+ +---------+ +---------+ +---------+ | +---------+
> > | | | | | | | | | | |
> > | hostapd | | cfg80211| | mac80211| | wlan | | | UHR |
> > | | | | | | | driver | | | AP-2 |
> > +----+----+ +----+----+ +----+----+ +----+----+ | +----+----+
> > | | | | | |
> > +----+---------------+ | | | | |
> > | init hostapd & HW | | | | | |
> > | MAPC support update| | | | | |
> > +----+---------------+ | MAPC Discovery | | | |
> > | | Request | | | |
> > | |(MAPC capability)| | | |
> > +-----------------+-----------------+-----------------+------|------>
> > | | MAPC Discovery | | | |
> > | | Response | | | |
> > | |(MAPC capability)| | | |
> > <-----------------+-----------------+-----------------+------|------+
Those are action frames just going between the hostapd instances (or
similar), why does the firmware need to create an event to hostapd
itself?
> +--------------------------------------------------------------------+
> > UHR AP-1 |
> > +---------+ +---------+ +---------+ +---------+ | +---------+
> > | | | | | | | | | | |
> > | hostapd | | cfg80211| | mac80211| | wlan | | | UHR |
> > | | | | | | | driver | | | AP-2 |
> > +----+----+ +----+----+ +----+----+ +----+----+ | +----+----+
> > | | | | | |
> > | | | +--------------+-----+| |
> > | | | | Notify hostapd to || |
> > | | | | Trigger MAPC || |
> > | | | | Negotiation || |
> > | | | +--------------+-----+| |
> > | NL80211_CMD_MAPC_NEGOTIATION_TRIGGER(scheme-id,action) | |
> > <-----------------+-----------------+-----------------+ | |
Here, why? What does this do in FW?
> >
> > +----+---------------+ | | | | |
> > |parse scheme-id & | | | | | |
> > |action. Init MAPC | |MAPC Negotiation | | | |
> > | Negotiation | | Request | | | |
> > +----+---------------+(scheme params & APID1 | | |
> > | Optype:ESTABLISHMENT/UPDATE) | | |
> > +-----------------+-----------------+-----------------+------+------>
Hostapd parses something the ... FW gave it? That seems odd. We should
give it in a decent data structure format, if this is at all sensible, I
have no idea.
> New notifications from cfg80211 to user space:
> - NL80211_CMD_MAPC_NEGOTIATION_TRIGGER
> Direction: kernel to user space.
> Source: cfg80211 on behalf of the WLAN driver/firmware.
> Purpose: Provide a hint to hostapd that MAPC Negotiation
> Request should be triggered on this interface. For each
> MAPC scheme, the driver/firmware may request establishment,
> update, or teardown of an agreement. hostapd is expected
> to apply policy and iterate over the locally known MAPC
> peers for this interface.
>
> Attributes:
> - NL80211_ATTR_MAPC_SCHEMES (nested)
> Contains one or more per-scheme MAPC negotiation hints. Each
> nested entry includes:
> - NL80211_ATTR_MAPC_SCHEME_TYPE
> Identifies the MAPC scheme (e.g., Co-BF, Co-SR, Co-TDMA,
> Co-RTWT, Co-CR).
> - NL80211_ATTR_MAPC_ACTION
> Requested negotiation action for this scheme:
> - NL80211_MAPC_ACTION_ESTABLISH: establish new agreement(s).
> - NL80211_MAPC_ACTION_UPDATE: update existing agreement(s).
> - NL80211_MAPC_ACTION_TEARDOWN: teardown existing agreement(s).
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?
> (C) mac80211
> Two design options are considered for representing MAPC peers in
> mac80211:
>
> Option-A(Preferred): Reuse existing station management infra
> - Allocate standard station objects (struct sta_info / struct
> ieee80211_sta) to represent MAPC peers, and call the WLAN driver.
> - Use a subset of the existing mac80211 station states (NOTEXIST,
> NONE, AUTH) to represent a MAPC stations.
I'd say AUTH doesn't work, for purposes of key management etc. you
really want this to be in AUTHORIZED state.
> Option-B: Define lightweight MAPC peer/station management
> infra
But that doesn't seem better either really.
johannes
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [DESIGN RFC v3] AP Architecture for Wi-Fi-8 Multi-AP Coordination (MAPC)
2026-01-12 19:12 ` Johannes Berg
@ 2026-01-12 19:18 ` Johannes Berg
2026-01-14 19:15 ` Jeff Johnson
0 siblings, 1 reply; 8+ messages in thread
From: Johannes Berg @ 2026-01-12 19:18 UTC (permalink / raw)
To: Abhishek Rajkapur Suryawanshi, ath12k, hostap; +Cc: linux-wireless
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?
johannes
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [DESIGN RFC v3] AP Architecture for Wi-Fi-8 Multi-AP Coordination (MAPC)
2026-01-12 19:18 ` Johannes Berg
@ 2026-01-14 19:15 ` Jeff Johnson
2026-01-15 14:17 ` Johannes Berg
0 siblings, 1 reply; 8+ messages in thread
From: Jeff Johnson @ 2026-01-14 19:15 UTC (permalink / raw)
To: Johannes Berg, Abhishek Rajkapur Suryawanshi, ath12k, hostap
Cc: linux-wireless
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.
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.
/jeff
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [DESIGN RFC v3] AP Architecture for Wi-Fi-8 Multi-AP Coordination (MAPC)
2026-01-14 19:15 ` Jeff Johnson
@ 2026-01-15 14:17 ` Johannes Berg
2026-01-22 8:42 ` Abhishek Rajkapur Suryawanshi
0 siblings, 1 reply; 8+ messages in thread
From: Johannes Berg @ 2026-01-15 14:17 UTC (permalink / raw)
To: Jeff Johnson, Abhishek Rajkapur Suryawanshi, ath12k, hostap
Cc: linux-wireless
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."
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 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.
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.
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.
> 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
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [DESIGN RFC v3] AP Architecture for Wi-Fi-8 Multi-AP Coordination (MAPC)
2026-01-15 14:17 ` Johannes Berg
@ 2026-01-22 8:42 ` Abhishek Rajkapur Suryawanshi
2026-01-27 13:57 ` Johannes Berg
0 siblings, 1 reply; 8+ messages in thread
From: Abhishek Rajkapur Suryawanshi @ 2026-01-22 8:42 UTC (permalink / raw)
To: Johannes Berg, Jeff Johnson, ath12k, hostap; +Cc: linux-wireless
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
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [DESIGN RFC v3] AP Architecture for Wi-Fi-8 Multi-AP Coordination (MAPC)
2026-01-22 8:42 ` Abhishek Rajkapur Suryawanshi
@ 2026-01-27 13:57 ` Johannes Berg
2026-02-28 17:34 ` Abhishek Rajkapur Suryawanshi
0 siblings, 1 reply; 8+ messages in thread
From: Johannes Berg @ 2026-01-27 13:57 UTC (permalink / raw)
To: Abhishek Rajkapur Suryawanshi, Jeff Johnson, ath12k, hostap
Cc: linux-wireless
On Thu, 2026-01-22 at 00:42 -0800, Abhishek Rajkapur Suryawanshi wrote:
> > 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.
Seems to me you're splitting hairs. Clearly you have the *negotiation*
trigger (NL80211_CMD_MAPC_NEGOTIATION_TRIGGER) prominently featured in
the diagrams etc. Sure, it maybe that doesn't explicitly trigger
*discovery*, but if hostapd doesn't already know about the station that
the FW/driver is requesting a negotiation with, it probably also has to
do discovery...
Anyway. I went to write a long email replying to some of your individual
points but deleted it again, I feel it's not worth your and my time.
Clearly, you have already decided on the architecture, and aren't
sharing all of it, based on reasons you aren't really sharing either.
Which is fine, I can't claim that we always share the full reasoning
behind architecture decisions.
We should all still make it transparent _how_ it's intended to work, but
that could also be just part of the documentation added to the kernel
when adding the necessary APIs.
Which then means that really in all the hundreds of lines of text you
just wanted to ask whether or not "Option-A" or "Option-B" for handling
the MAPC peers should be used, and I'd agree that duplicating APIs isn't
good, i.e. taking "Option-A". Note we did something similar for NAN
stations, even if they have different sets of attributes than regular AP
client stations or mesh peers etc.
johannes
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [DESIGN RFC v3] AP Architecture for Wi-Fi-8 Multi-AP Coordination (MAPC)
2026-01-27 13:57 ` Johannes Berg
@ 2026-02-28 17:34 ` Abhishek Rajkapur Suryawanshi
0 siblings, 0 replies; 8+ messages in thread
From: Abhishek Rajkapur Suryawanshi @ 2026-02-28 17:34 UTC (permalink / raw)
To: Johannes Berg, Jeff Johnson, ath12k, hostap; +Cc: linux-wireless
On 1/27/2026 5:57 AM, Johannes Berg wrote:
> On Thu, 2026-01-22 at 00:42 -0800, Abhishek Rajkapur Suryawanshi wrote:
>>> 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.
>
> Seems to me you're splitting hairs. Clearly you have the *negotiation*
> trigger (NL80211_CMD_MAPC_NEGOTIATION_TRIGGER) prominently featured in
> the diagrams etc. Sure, it maybe that doesn't explicitly trigger
> *discovery*, but if hostapd doesn't already know about the station that
> the FW/driver is requesting a negotiation with, it probably also has to
> do discovery...
>
> Anyway. I went to write a long email replying to some of your individual
> points but deleted it again, I feel it's not worth your and my time.
>
>
> Clearly, you have already decided on the architecture, and aren't
> sharing all of it, based on reasons you aren't really sharing either.
> Which is fine, I can't claim that we always share the full reasoning
> behind architecture decisions.
>
> We should all still make it transparent _how_ it's intended to work, but
> that could also be just part of the documentation added to the kernel
> when adding the necessary APIs.
>
>
> Which then means that really in all the hundreds of lines of text you
> just wanted to ask whether or not "Option-A" or "Option-B" for handling
> the MAPC peers should be used, and I'd agree that duplicating APIs isn't
> good, i.e. taking "Option-A". Note we did something similar for NAN
> stations, even if they have different sets of attributes than regular AP
> client stations or mesh peers etc.
>
> johannes
Based on your feedback, we re-evaluated and modified the architecture.
Here hostapd along with MAPC discovery, will initiate MAPC negotiation
with discovered APs based on programmed rules(hostapd.conf / hostapd_cli)
& the criteria specified in IEEE P802.11bn/D1.3, sections 37.14.1.3 and 37.14.2.
Additionally, a hostapd CLI command will be added to trigger MAPC negotiation
for controller-managed APs.
Figure 1: MAPC Negotiation Sequence (ESTABLISHMENT/UPDATE)
---------------------------------------------------------
+----------------------------------------------------------------------+
| UHR AP-1 |
| +---------+ +---------+ +---------+ +---------+ | +---------+
| | | | | | | | | | | |
| | hostapd | | cfg80211| | mac80211| | wlan | | | UHR |
| | | | | | | | driver | | | AP-2 |
| +----+----+ +----+----+ +----+----+ +----+----+ | +----+----+
| | | | | | |
| +----+---------------+ | | | | |
| | init hostapd & HW | | | | | |
| | MAPC support update| | | | | |
| +----+---------------+ | MAPC Discovery | | | |
| | | Request | | | |
| | |(MAPC capability)| | | |
| +-----------------+-----------------+-----------------+--------|------>
| | | MAPC Discovery | | | |
| | | Response | | | |
| | |(MAPC capability)| | | |
| <-----------------+-----------------+-----------------+--------|------+
| | | | | | |
| +----+---------------+ | | | | |
| |alloc sta_info store| | | | | |
| |MAPC capa & params | | | | | |
| +----+---------------+ | | | | |
| | | | | | |
| +--+-----------------+-----------------+-----------------+---+ | |
| | MAPC PEER CREATE | | |
| +--+-----------------------------------+-----------------+---+ | |
| | | | | | |
| +----+---------------+ | | | | |
| | Based on configs | | | | | |
| | and spec criteria | | | | | |
| | Initiate MAPC | | | | | |
| | Negotiation | | | | | |
| +----+---------------+ | | | | |
| | |MAPC Negotiation | | | |
| | | Request | | | |
| | (scheme params & APID1) | | |
| +-----------------+-----------------+-----------------+--------|------>
| | | | | | |
| | |MAPC Negotiation | | | |
| | | Response | | | |
| | (scheme params & APID2) | | |
| <-----------------+-----------------+-----------------+--------|------+
| | | | | | |
| +--+-----------------+-----------------+-----------------+---+ | |
| | MAPC PEER UPDATE | | |
| +--+-----------------+-----------------+-----------------+---+ | |
| | | | | | |
| | | | | | |
| | | | | | |
| v v v v | v
+----------------------------------------------------------------------+
Figure 2: MAPC Negotiation Sequence (TEARDOWN)
-----------------------------------------------------
+----------------------------------------------------------------------+
| UHR AP-1 |
| +---------+ +---------+ +---------+ +---------+ | +---------+
| | | | | | | | | | | |
| | hostapd | | cfg80211| | mac80211| | wlan | | | UHR |
| | | | | | | | driver | | | AP2 |
| +---+-----+ +---+-----+ +---+-----+ +---+-----+ | +----+----+
| | | | | | |
| | | | | | |
| | | | | | |
| +----+---------------+ | | | | |
| | Based on configs | | | | | |
| | and spec criteria | | | | | |
| | Initiate MAPC | | | | | |
| | Negotiation | | | | | |
| +----+---------------+ | | | | |
| | |MAPC Negotiation | | | |
| | | Request | | | |
| | | (TEARDOWN) | | | |
| +-----------------+-----------------+-----------------+---------+------>
| | | | | | |
| | |MAPC Negotiation | | | |
| | | Response | | | |
| | | (ACCEPT) | | | |
| <-----------------+-----------------+-----------------+---------+------+
| | | | | | |
| +----+----------------+| | | | |
| |If agreement count || | | | |
| |is zero for MAPC peer|| | | | |
| |then initiate MAPC || | | | |
| |peer delete || | | | |
| +----+----------------+| | | | |
| | | | | | |
| +--+-----------------+-----------------+-----------------+---+ | |
| | MAPC PEER DELETE | | |
| +--+-----------------+-----------------+-----------------+---+ | |
| | | | | | |
| | | | | | |
| | | | | | |
| v v v v | v
| |
+----------------------------------------------------------------------+
Abhishek
^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~2026-02-28 17:34 UTC | newest]
Thread overview: 8+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2026-01-12 18:52 [DESIGN RFC v3] AP Architecture for Wi-Fi-8 Multi-AP Coordination (MAPC) Abhishek Rajkapur Suryawanshi
2026-01-12 19:12 ` Johannes Berg
2026-01-12 19:18 ` Johannes Berg
2026-01-14 19:15 ` Jeff Johnson
2026-01-15 14:17 ` Johannes Berg
2026-01-22 8:42 ` Abhishek Rajkapur Suryawanshi
2026-01-27 13:57 ` Johannes Berg
2026-02-28 17:34 ` Abhishek Rajkapur Suryawanshi
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox