[DESIGN RFC v3] AP Architecture for Wi-Fi-8 Multi-AP Coordination (MAPC)
Abhishek Rajkapur Suryawanshi
abhishek.suryawanshi at oss.qualcomm.com
Sat Feb 28 09:34:14 PST 2026
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
More information about the Hostap
mailing list