Thread Links | Date Links | ||||
---|---|---|---|---|---|
Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
Hi Jay, Thanks for your further discussion. I see that you’re mixing a lot of points that are not necessarily dependent:
Hope it clarifies my points. Regards, Arik From: Jay Yang <yang.zhijie@xxxxxxxxxx> 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 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>
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 |