From: Abhishek Rajkapur Suryawanshi <abhishek.suryawanshi@oss.qualcomm.com>
To: Johannes Berg <johannes@sipsolutions.net>,
Jeff Johnson <jeff.johnson@oss.qualcomm.com>,
ath12k@lists.infradead.org, hostap@lists.infradead.org
Cc: linux-wireless@vger.kernel.org
Subject: Re: [DESIGN RFC v3] AP Architecture for Wi-Fi-8 Multi-AP Coordination (MAPC)
Date: Sat, 28 Feb 2026 09:34:14 -0800 [thread overview]
Message-ID: <e007da67-a92b-44a2-a5aa-89444fd087e2@oss.qualcomm.com> (raw)
In-Reply-To: <9ea4b65c3fa5750ef57e93dd04b70cc4ec5df445.camel@sipsolutions.net>
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
prev parent reply other threads:[~2026-02-28 17:34 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
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 message]
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
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=e007da67-a92b-44a2-a5aa-89444fd087e2@oss.qualcomm.com \
--to=abhishek.suryawanshi@oss.qualcomm.com \
--cc=ath12k@lists.infradead.org \
--cc=hostap@lists.infradead.org \
--cc=jeff.johnson@oss.qualcomm.com \
--cc=johannes@sipsolutions.net \
--cc=linux-wireless@vger.kernel.org \
/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