Hi Arik ,
Thanks for the further response.
For the MAP coordination between yours and your neighbor AP, I don't see any requirement to maintain multiple MAP pairs' information.
If you walk on that direction, you will encounter the overhead issue, extra mountainous job,internal fairness issue,schedule problem, etc. It will cause the system design becoming more complicated and no one use MAP scheme at all.
Insist on the spirit that the simpler, the better. Single MAP (set) pair will be more simple and attractive to AP vendors if you really want MAP scheme can be applied in Wi-Fi industry.
Besides you, I would like to see any other member is still in favor of multiple MAP pairs ideas based on our following discussion.
See the details response inline in blue font.
Thanks
Best Regards
Jay Yang (杨志杰)
Hi Jay,
Thanks for your further discussion.
I see that you’re mixing a lot of points that are not necessarily dependent:
An agreement can be set between an AP and one or more APs .
--><Jay> If you agree one AP can set up the agreement with another AP set(including more than one APs ), why you reject the ideas that one AP set can establish the agreement with another AP set? I'm can follow your logic.
This can be implemented via individual agreements between the initiating AP and each of the other individual APs or it can be one agreements for all APs (provided that one coordination scheme is used for all involved APs ) – need further discussion to decide which option is preferred.
--><Jay>That's true you can aggregate a number of agreement request/response frames to one frame, But if the initialing AP also have MBSSID or co-hosted APs , do you also agree that the initialing AP can also do some aggregation in the agreement request frame? If that's true, you already walk on the direction of AP set level agreement.
The agreement may include setting of many parameters that will not be changed along the lifetime of this agreement.
Obviously, an agreement can be torn-down by any of its involved APs (for any reason) – but the intention is to have an agreement for a long-time duration.
--><Jay> I think you agree that for individual AP agreement, the system should maintain the information for multiple MAP pairs, if there is any membership(like re-setup, torn-down) or parameter changes on each individual AP, a new signaling will be sent over-the-air to another side. You try to argue there is no frequently of such individual membership change, but it depends on the number of involved APs . In larger MAP coordination network, such issue will become more serious.
--><Jay>Also, once your AP maintain the information for multiple MAP pairs for your neighbor AP, how do you think the AP ID assignment, and AP-AP KEY exchange,etc. And the TXOP holder should be very carefully for the schedule if the responded APs belong to one single radio. All in all, the system will become more complicated. Actually, I doubt whether it really necessary to maintain multiple MAP pairs information for a single neighbor AP.
Besides the agreement, the involved APs can exchange further (dynamic) information between them during the operation (like: latency traffic, required traffic size etc.) – need to discuss what is the best way to exchange such information.
--><Jay> Thanks for think about such issue, one way is to report the whole AP set requirement, an alternative solution is to report a number of individual APs requirement to another side. Obviously, the former one is better.
Even if an agreement is set between an AP and one or more APs , does it mean that from that point onwards for every TXOP the TXOP owner has to share it with all involved APs under the same agreement? I do not think so, but it worth further discussion…..
--><Jay> I would say YES if you think more than one involved AP has LL traffics. But if we have the MAP set agreement, what we can do is to allow the TXOP owner share the TXOP to the AP set, and the implementer can well design how to allocate them to each involved AP. Again, the simpler, the better, just to meet Wi-Fi industry requirement.
A router is not a TXOP owner, but an AP does. Therefore (again), I do not see any problem if an AP from one router will have an agreement with one or more of the APs in another router – but the AP does not have to have an agreement with all of them……unless it wants to have an agreement with all of them.
--><Jay>That's why I propose the AP set concept, we can design the AP set has its own EDCA parameter, MAC address,etc. So that the AP set can be a TXOP owner. And the AP set only focus on MAP co-ordination scheme.
As to the fairness issue – I agree on that point, but this:
Has no connection to Co-hosted set or MBSSID set. It can be in any regular environment of APs that have a M-AP coordinated transmission.
It needs to be compensated – I’ll present our view on this issue at a later time.
In summary: there is some overhead that is added to the M-AP coordinated transmission, as part of the “coordination” that is needed before such a transmission occur. However:
I do not agree with your problem statement (M*N*K) – I think it is much less than this….
The agreement setting procedure should decrease the amount of frame exchange to the possible minimum.
The trade-off is always between the new suggested mechanism (with all its benefits) vs. the minimal overhead required to allow such a mechanism
--><Jay>Totally difference, this is the internal fairness issue on the same Radio, but you want to confuse it with external APs in the environment. If we want to walk on that way, we need further to think about the issue of internal fairness and external fairness, and make the system become more complicated.
--><Jay> Glad to see your contribution.
--><Jay> I'm not sure what your meaning of the MAP pair number is much less than M*N*K if you have two neighbor APs , do you mean most of APs in the co-hosted/MBSSID don't enjoy MAP scheme? What's the purpose for that?
--><Jay> Yes, you could do some aggregation to reduce the number of frame exchange, but how do you think the burden of maintain a number of AP pairs information for each individual neighbor APs ?
--><Jay> Hope you can think about all the issues from the whole system design perspective, if you walk on multiple MAP pairs direction, it will cause no one use it at all.
Hope it clarifies my points.
Regards,
Arik
From: Jay Yang <yang.zhijie@xxxxxxxxxx>
Sent: יום ב 24 יוני 2024 00:16
To: STDS-802-11-TGBN@xxxxxxxxxxxxxxxxx
Subject: Re: [STDS-802-11-TGBN] 24/719 MAP Set operation
Hi Arik ,
That's an interesting topic, see my response inline in blue font.
Thanks
Best Regards
Jay Yang (杨志杰)
Original
From: ArikKlein <0000177967a59511-dmarc-request@xxxxxxxxxxxxxxxxx>
Date: 2024年06月23日 23:47
Subject: Re: [STDS-802-11-TGBN] 24/719 MAP Set operation
Hi Jay,
Thanks for sharing your presentation.
You wrote: “ Take C-TDMA as example, If an AP(assume AP21 on Rounter1) obtains the TXOP and becomes the TXOP owner, it can grant the portion of TXOP to any APs (AP11, AP12,etc.) on Router2 via a Trigger frame, and the corresponding AP will schedule the DL/UL traffic for in-BSS traffic delivery. If we intend to have a agreement between the pair of AP before MAP co-ordination TX, then, in this case, AP21 should set up the agreement with all the APs on Rounter2. “
You argue that “If we intend to have a agreement between the pair of AP before MAP co-ordination TX, then, in this case, AP21 should set up the agreement with all the APs on Rounter2 “ and I think this is not correct: Any AP may have an agreement with any AP that it wants as long as the other/solicited AP is not on the same Co-hosted set or MBSSID set (where the 2 APs can’t share the same TXOP in all TXOP -based coordination schemes). Therefore, following your example, AP21 (Router 1) may set a M-AP agreement with one or more APs on Router 2 (or even with none of them at its own discretion) and it does not have to set an agreement with each of the APs in Router 2.
--><Jay>Based on the example you thought, e.g. AP21 set a M-AP agreement with one or more APs (assuming two AP2 here).After that, If AP21 decides to switch the operating channel or enter PS mode, AP21 should notify these update operation to both of the APs on Router2. Also, another example, Before the MAP co-ordniation TX, both of the APs on Router2 need to notify their resource requirement( like BSR ) to AP21, so that AP21 understands how to grant the TXOP in C-TDMA scheme. So you can see, the overhead issue will be twice once there are two pairs MAP between two rounters . Also, you know, in C-SR scheme,some contribution proposes more than two APs (assuming three APs ) can join C-SR scheme in parallel. So the agreement will be K*M*N times at the maximum if we walk on this direction.
--><Jay> It' true AP21 and AP22 on rounter2 can't send perform TX in parallel, but they can share the granted TXOP in series without the further signaling exchange with AP12 on Rounter1. Let's assume an example that AP12 set up the agreement with AP21 and AP22 respectively. When AP21 becomes a TXOP holder in C-TDMA scheme,the AP21 may become an arbitrator, to decide how long the TXOP shared to AP21 and AP22 respectively . Do we really want AP12 to become an addational scheduler for the APs on Rounter2? or we should leave such complicated schedule job to the Rounter2 itself. E.g. Rounter1 grants it's TXOP to Rounter2, and Rounter2 decides how to allocate such TXOP to its APs via internally schedule policy?
--><Jay> Last but not least, if there are 3 APs on rounter2, and AP12 on Rounter1 only set up the agreement with AP21 and AP22 on Rounter2 respectively. How to handle the case if AP23 on Rounter2 intends to enjoy the MAP scheme with AP12? Reject such requirement or accept it? If you reject the new MAP agreement between AP12 and AP23, there will be a fairness issue between the AP2 on rounter2 as only AP21 and AP22 can enjoy the benifit of MAP scheme. If you accept such agreement, the overhead issue mentioned in the first bullet will be three times definiately .
I agree that AP21 will share its TXOP only with one or more of those APs that he has set a M-AP agreement with (Note: I do think that in TXOP -based coordination schemes, such as C-TDMA , C-SR etc. the TXOP holder keeps its TXOP and does not grant it to any other AP, but rather share this TXOP with one or more APs it has set a M-AP agreement with, but we can further discuss it later).
--><Jay> OK, I agree with such precondidation . Let's focus on the MAP co-ordination TX beween the APs in co-hosed/MBSSID seneario , and see how to make the system become more simple under different directions.
Therefore, I do not see any “overhead problem” (as stated in the presentation) with Co-hosted set/ MBSSID set compared to a use case that does not involve Co-hosted set or MBSSID set, in the context of setting M-AP agreement between one or more APs .
--> In Summary. The proposed AP level co-ordination may cause the following issues. (And the proposed AP Set level MAP co-ordination can address all of them).
Firstly, multiple MAP pairs(I think you agree with multiple MAP paris may exist under co-hosted/MBSSID set senario ) will cause multiple times overhead issue. Secondly, the sharing AP will become an external scheduler for the APs on the same radio. thirdly, all the APs in the same radio has the equal status, it may cause the fairness issue if other APs can't set up M-AP agreement with the APs on other ronters . If we allow all APs enjoy the MAP scheme, the overhead issue in items1 become more seriously. Last but not least, the design of multiple MAP pairs will be more complicated than single pair in the implemention definitely.
Let's see how you thought these issues.
Regards,
Arik
From: Jay Yang <yang.zhijie@xxxxxxxxxx>
Sent: יום ו 21 יוני 2024 05:10
To: STDS-802-11-TGBN@xxxxxxxxxxxxxxxxx
Subject: [STDS-802-11-TGBN] 24/719 MAP Set operation
Hi All,
I present the contribution 24/719 this morning, a lot of members ask me to clarify why it's M*N times frame agreement exchange. I re-think about it, and make the following illustration.
First, let's see how the co-hosted BSSID and MBSSID work in a shared radio(we call "co-radio APs " below) in intrastucture network. Regardless any AP PS scheme, for TX, all the APs on the same radio access the channel in TDMA manner. For RX, all the APs are always "on" to receive the STAs UL traffic or other frames, and make the response with ACK or other frames. E.g. if a STA sends a broadcast probe request frame, all the APs in the same radio should respond with probe response frames. To reduce the overhead issue caused by probe response frames in co-located APs scheme, 802.11 involves MBSSID feature to "merge" a number of probe response frames to one many years ago.
If we agree on the above. Let's see how MAP TX co-ordination work.
Take C-TDMA as example, If an AP(assume AP21 on Rounter1) obtains the TXOP and becomes the TXOP owner, it can grant the portion of TXOP to any APs (AP11, AP12,etc.) on Router2 via a Trigger frame, and the corresponding AP will schedule the DL/UL traffic for in-BSS traffic delivery. If we intend to have a agreement between the pair of AP before MAP co-ordination TX, then, in this case, AP21 should set up the agreement with all the APs on Rounter2.
Back to the precondition, two APs shall have a overlapping time slot (and channel) in any MAP co-ordination scheme. For the co-radio APs case(regardless any AP PS scheme), as all the APs (on Rounter2) can hear the frame transmitted by any APs (on Rounter1) and make the response at any time, we could say the operation time always overlapping between any two APs on different Routers. That's, the number of AP pairs is equal to M*N in co-radio APs scenario(neither more nor less than).
Based on the explanation above, if we agree the direction to reduce the overhead issue in MAP scheme, the idea is to make some "external signaling" to become "internal signaling", E.g. Adding or deleting APs on Rounter1 won't cause any update signaling sending to the APs on Rounter2 if we have the MAP Set concept. Also, such concept also can reduce the overhead issues in Radio power/off and channel switch scenario.
Again, this contribution only provide some high level thought, if our group agree with this direction, we could have further study and discuss more in details.
,
Thanks
Best Regards
Jay Yang (杨志杰)
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
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
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
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