Re: [DESIGN RFC v3] AP Architecture for Wi-Fi-8 Multi-AP Coordination (MAPC)
Abhishek Rajkapur Suryawanshi <[email protected]> Sat, 28 Feb 2026 09:34:14 -0800
| Newsgroups | gmane.linux.kernel.wireless.general,gmane.linux.drivers.hostap |
|---|---|
| Message-ID | <[email protected]> |
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