Re: [STDS-802-11-TGBN] PDT for motion 185 (related to over-the-DS MAPC a

Thread Links	Date Links
Thread Prev	Thread Next	Thread Index	Date Prev	Date Next	Date Index

Hi Yan Li

Many thanks for your thoughtful response. Also, I’m looking at 11me7.0 Figure 13-7—MLME interfaces for over-the-DS FT protocol messages as context.

“Since the SME of AP has got enough information intended to be transmitted over the DS, why the SME of AP need to send it to MLME?” – is a very good question. My answer is based on a few considerations:

MAPC will have two AP2AP variants: over-the-air and over-the-DS. The way I’ve arranged this, we can maximize design reuse between the variants, since only the transport of the AP2AP communications changes
Typically, I think of the SME as upper layers/OS/responsible for policy, but the detailed state and real-time behavior is orchestrated by the MLME (as well as formatting transmitted frames and validating received frames). The arrangement in my document retains that partitioning, since the MLME is always informed of everything that is going on

Conversely, if we just have SME-to-SME communications, when does the MLME get clued in?

For MAPC, we are being more explicit about the SME also offering a transport mechanism. Arguably that’s a different entity within the SME (the networking stack with tunnelling rather than the policy engine), and so having a separate primitive between SME and MLME will help the information be routed to the correct entity.

Best wishes

Brian

From: li.yan16@xxxxxxxxxx <li.yan16@xxxxxxxxxx>
Sent: Monday, January 13, 2025 6:10 AM
To: Brian Hart (brianh) <brianh@xxxxxxxxx>
Cc: STDS-802-11-TGBN@xxxxxxxxxxxxxxxxx; arik.klein@xxxxxxxxxx
Subject: Re: PDT for motion 185 (related to over-the-DS MAPC and MLME)

Hi Brian,

Thanks for your effort on this special MLME SAP. Basically it's quite a new type of form.

After checking the remote request broker(RRB) in FT, i'm wondering if we can get some inspiration from it:

In RRB, step 1: the SME of FTO issues MLME-REMOTE-REQUEST.request to MLME --> FTO transmits Action frame

step 2: MAC of current AP receives such Action frame --> MLME of current AP issues MLME-REMOTE-REQUEST.indication primitive to the SME

step 3 : the RRB within the SME of current AP acts as a forwarding agent to communicate with the RRB of the target AP over the DS

when it comes to MAP, the major difference is that the information intended to be transmitted over the DS is from the initiator AP itself instead of the FTO in FT, which means the SME of initiator AP can directly communicate the intended information with the peer AP without issuing any primitive to the MLME

Baically step1-2 are used to get all information intended to transmit over the DS. But for MAP, the initiator AP has all information and it can just perform the step 3

So my question is ：

Since the SME of AP has got enough information intended to be transmitted over the DS, why the SME of AP need to send it to MLME? If i understand correctly, the MLME is responsible for construct the MAC frame based on the information provided by the SME via the xxx. request primitive

Best Regards！

Yan Li

Original

From: BrianHart(brianh) <brianh@xxxxxxxxx>

To: STDS-802-11-TGBN@xxxxxxxxxxxxxxxxx <STDS-802-11-TGBN@xxxxxxxxxxxxxxxxx>;

Cc: Arik Klein <arik.klein@xxxxxxxxxx>;李炎10200040;

Date: 2025年01月13日 10:14

Subject: PDT for motion 185 (related to over-the-DS MAPC and MLME)

Hi all

Using this email:

to flag that 25/102, implementing motion 185 (related to over-the-DS aspects of MAPC and MLME; see below), is currently scheduled for presentation on Wednesday AM2 MAC; and
to flag that review is sought, and
to start an email thread where feedback on 25/102 can be provided, and subsequent discussion.

Motion 185 (MAC)

Move to add to the TGbn SFD the following:

Define a mechanism in 11bn that defines:

AP-to-AP frame formats to enable interoperable MAPC across APs and including MLME primitive(s) so that a pair of AP’s SMEs can orchestrate the over-the-air transmission and reception of these frames
MLME primitive(s) so that a pair of AP’s SMEs may send the content of the non-real-time instances of such AP-to-AP frames over-the-DS between peer AP-MLMEs (rather than over-the-air via peer AP MACs)

Move: Brian Hart Second: Steve Rodriguez

Discussion: None.

Result: Approved with unanimous consent.

(Arguably) related PoCs and TTTs are:

SFD Topic

POC (in alphabetical order of family name)

TTT

Multi-AP Coordination Framework

Arik Klein

arik.klein@xxxxxxxxxx

Shawn Kim, Jerome Gu, Gaurav Patwardhan Pascal Viger Gwangho Lee, Patrice Nezou John Wullert Jiayi Zhang, Yanjun Sun, Binita Gupta, Kaiying Lu, Insun Jang, Yelin Yoon, SunHee Baek, Gaius Wee, Yaoshen Cui, Yusuke Tanaka, Liuming Lu, Yunpeng Yang, Dana Ciochina, Leif Wilhelmsson, Taeyoung Ha, Kosuke Aio, Tong Bian, Minotani Jun, Abhishek Chaturvedi, Alfred Asterjadhi, Peshal Nayak, Abhishek Patil, Jonghoe Koo, Kaikai Huang, Lyutianyang Zhang, Massinissa Lalam, Rishabh Roy, Brian Hart, Yuxin Lu, Haorui Yang, Woojin Ahn, Kazuto Yano, Kyosuke Inoue, Brian Hart, Hirohiko INOHIZA, Dibakar Das, Lei Zhou, Gaurang Naik, Shuang Fan, Lili Hervieu, Peshal Nayak, Xiangxin Gu, Giovanni Chisci, GeonHwan Kim, Arik Klein, Yongho Seok, Rubayet Shafin, Yanjun Sun, Xiaofei Wang, Jay Yang, Pei Zhou, Vishnu Ratnam, Xiandong Dong, Muhammad Kumail Haider, Nima Namvar, Sanket Kalamkar, Ross Jian Yu, Yajun Chen, Zhenpeng Shi, Jason Yuchen Guo, Liwen Chu, Xuwen Zhao, Ke Zhong, Sungjin Park, Yuki Fujimori, Jeongki Kim, Leonardo Lanante, Sindhu Verma, Shubhodeep Adhikari, Yongsen Ma

MLME SAP (Clause 6)

Yan Li

li.yan16@xxxxxxxxxx

Alfred Asterjadhi, Brian Hart (MAPC), Binita Gupta (roaming, L4S), Lili Hervieu (L4S), Brian Hart (L4S), Pascal Viger (L4S), Osama Aboul-Magd, Rubayet Shafin, Ross Jian Yu, Liwen Chu, Jeongki Kim

Best wishes

Brian

To unsubscribe from the STDS-802-11-TGBN list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGBN&A=1

Re: [STDS-802-11-TGBN] PDT for motion 185 (related to over-the-DS MAPC and MLME)