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

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>
To: STDS-802-11-TGBN@xxxxxxxxxxxxxxxxx <STDS-802-11-TGBN@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 signalling 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