Thread Links | Date Links | ||||
---|---|---|---|---|---|
Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
Hi Wookbong, Thank you so much for your effort on harmonization. Let me ask a question for clarification on below SP regarding 80MHz segment; Would it mean excluding the case that for 160MHz capable STA, U-SIG in a certain 80MHz segment indicates the information of other 80MHz segment that isn’t overlapped with the 80MHz segment that SIG decoding happens for example, while larger RU like 2x996 can be indicated since it encompass its own 80MHz segment? One more question on another SP for RU allocation in MU; (sorry for bringing up different contribution 373 here) SP: Do you agree to use RU allocation subfield defined in 11ax to indicate RU to be assigned to each STA for MU PDDU when only one RU per a STA is assigned and the number of multiplexed users in each RU is up to 8? In 11ax, you know there is a case that the multiplexed users in a RU is not supported up to 8, when only two 106-RUs are assigned (with middle 26-RU hole) that the users in each RU are limited as 4. Would you intend to change this case up to 8 which requires the modification of current RU signaling table and not aligned with your current text I guess? Best regards, Jinsoo From: Wook Bong Lee [mailto:wookbong.lee@xxxxxxxxxxx] Hi Dongguk, I saw your e-mail to Alfred regarding 11-20-0524-00-00be-signaling-of-preamble-puncturing-in-su-transmission.(Dongguk Lim, LG Electronics), EHT-SIG. Do you want me to defer following SP after your presentation? • Do you support that U-SIG in each 80MHz shall carry puncturing channel info for at-least the specific 80MHz where it is transmitted? – Note1: Each STA needs to decode U-SIG in only one 80MHz segment – Note2: Within each 80MHz segment, U-SIG is duplicated in every non-punctured 20MHz – Whether BW/Puncturing info can be different for different 80MHz is TBD – Whether BW and puncturing info bits in U-SIG are carried as a combined or a separate field is TBD I think all of your options can support above high level concept. Please let me know your preference. Best regards, From: Oded Redlich (TRC) [mailto:oded.redlich@xxxxxxxxxx] Thanks Wookbong, My contribution is #483 BR, Oded From: Wook Bong Lee [mailto:wookbong.lee@xxxxxxxxxxx] Hi Oded, No problem. I can run this SP after your contribution. Please let me know your contribution number. Best regards, Wook Bong Lee From: Oded Redlich (TRC) [mailto:oded.redlich@xxxxxxxxxx] Hi Wookbong, By pointing out the 1x1x structure I was actually referring to the case where one of the content channel is missing (assuming 2 CC will be supported of course) . In this case limiting the reception of pre-EHT to 80MHz will degrade the channel utilization for devices that support BW>80MHz. I do have a contribution on that so I would appreciate if you defer the relevant SPs as you suggested. Thanks, Oded From: Junghoon Suh [mailto:Junghoon.Suh@xxxxxxxxxx] Wookbong. I do not have any plan for a counter proposal yet. It is your SP and if you want to run, go ahead. I already requested further discusdion on this topic, and if you insist on running your SP. I cannot support you at this moment. Regards -------------------------------------------------- From:Wook Bong Lee <wookbong.lee@xxxxxxxxxxx> To:STDS-802-11-TGBE <STDS-802-11-TGBE@xxxxxxxxxxxxxxxxx> Date:2020-03-20 12:25:15 Subject:Re: [STDS-802-11-TGBE] 答复: [PHY] SU SIG contents, 11-20/285 Hi Oded, Thanks for your response/comment. First of all, currently [1 x 1 x] is not agreed in 11be. During last conference call, Eunsung run SP to have [1 x 1 x] (SP#4), but it failed. I would like to repeat my response to Junghoon in here. If your intention is to have different requirement than 80MHz preamble processing, I am fine with waiting for your presentation before run this SP. I deferred these SPs once, but I can further wait if it depends on other presentation/contribution. Please let us know your plan for this. Best regards, Wook Bong Lee From: Oded Redlich (TRC) [mailto:oded.redlich@xxxxxxxxxx] Hi, Wookbong I would also like to thank you for trying to harmonize the SPs via the e-mail reflector. Regarding the 1st bullet, I think that if we insist on limiting any device to receiving the pre-EHT field on 80MHz we preserve a con of 802.11ax. There is a special case where the puncturing structure is 1x1x, where the BW is reduced to 20MHz even if there are available channels in other S80s. So although it is a non-issue for the 80MHz devices, what about devices that support higher BWs? These devices should not “suffer” from such limitation. Therefore I think we should not restrict the ability to receive pre-EHT on BW>80MHz. I know that there are concerns about power consumption but there should not be a problem with that due to the use of power-save mechanism (PS-Poll, TWT) Anyway, I think that further discussion about this issue is required. BR, Oded From: Wook Bong Lee [mailto:wookbong.lee@xxxxxxxxxxx] Hi Junghoon, First of all, I don’t know how to make progress if we don’t respect passed SP at this moment. As far as I know, we don’t have any means to run any motion. If your intention is to have different requirement than 80MHz preamble processing, I am fine with waiting for your presentation before run this SP. I deferred these SPs once, but I can further wait if it depends on other presentation/contribution. Please let us know your plan for this. Finally, as I recommended to Dongguk, since we are using e-mail reflector, we can always get feedback from our MAC colleagues. If there is a concern on particular SP text from your MAC colleague, please feel free to inform us. I am more than happy to address the issue and move forward. Thank you. Best regards, Wook Bong Lee From: Junghoon Suh [mailto:Junghoon.Suh@xxxxxxxxxx] For, the 1st bullet, we only saw the presentation 1st time in the last CC, and there were lots of abstains. We do not want to run any SP based on any other SP (without being fixed into the SFD). For how to decode, I do not see why it should be limited to 80 MHz clearly. Why not 40 MHz then. All I am saying is more time needed. We only saw this proposal once. It is not just PHY issue, as you commented in the last CC. We need to think further for any other issue which may take place by this proposal. The 2nd and 3rd bullet are dependent on the 1st bullet. Regards Junghoon From: Wook Bong Lee [mailto:wookbong.lee@xxxxxxxxxxx] Hi Junghoo, Thanks for your response. First of all, in my opinion, first two notes are purely PHY issue. Note 1 is saying nothing but non-AP STA to decode only 80MHz segment. If there is no such requirement, then non-AP STA needs to decode all BW or more than one 80MHz segment? If I recall correctly, Sameer already ran text in note 1, and result was more than 75% yes. Note 2 is same 11ax. I don’t see other way to do this. Please let me know if you have better idea. For the third bullet, as I respond to Ross, we can make it TBD for now. • Do you support that U-SIG in each 80MHz shall carry puncturing channel info for at-least the specific 80MHz where it is transmitted? – Note1: Each STA needs to decode U-SIG in only one 80MHz segment – Note2: Within each 80MHz segment, U-SIG is duplicated in every non-punctured 20MHz – Whether BW/Puncturing info can be different for different 80MHz is TBD – Whether BW and puncturing info bits in U-SIG are carried as a combined or a separate field is TBD Hope you are fine with modified SP above. Regarding second SP, yes, please let us know if you have a comment. Your support will be great. J Best regards, Wook Bong Lee From: Junghoon Suh [mailto:Junghoon.Suh@xxxxxxxxxx] Hi, Wookbong I echo with Ross. For SP1, especially for sub-bullet 1~3, I think we need more discussion in the Joint session, even though we ran a SP on this in the last CC, we have not run any motion about the 80MHz segment based processing,yet, and it is not in the SFD. We do not want to run any SP based on something we have not agreed in SFD. For SP2, I am also feeling the need to have the STA-ID info in the PHY header for SU-PPDU in the different perspective from your explanation, but I need more investigation. Regards Junghoon From: Wook Bong Lee [mailto:wookbong.lee@xxxxxxxxxxx] Thanks Dongguk. Best regards, Wook Bong Lee From: Dongguk Lim [mailto:dongguk.lim@xxxxxxx] Hi Wookbong, Thanks for the reply. Okay. I will also discuss these issues with our Mac people. Best regards, Dongguk From: Wook Bong Lee [mailto:wookbong.lee@xxxxxxxxxxx] Hi Dongguk, Thanks for response. Since we are anyway using e-mail reflector now, can you ask this to your MAC colleagues? If they have some concern, we can try to resolve that in here first. If we can’t reach a consensus, then certainly we can ask for slot to discuss it in joint session. Best regards, Wook Bong Lee From: Dongguk Lim [mailto:dongguk.lim@xxxxxxx] Hi Wookbong, Thanks for suggesting of harmonized SPs for the efficient processing. As you mentioned in the PHY CC, the operation in 80MHz which is not primary channel and the using of STA-ID of SU-PPDU in Multi link transmission are related with Mac operation. And, some issues related to above topic still being discussed or not discussed yet. Thus, I think that we need to discuss this topic with Mac guys in the joint session to avoid unnecessary arguments. Best regards, Dongguk From: Yujian (Ross Yu) [mailto:ross.yujian@xxxxxxxxxx] Hi Wookbong, Thanks for the replies and considering my suggestion. And your example is a good one. regards 于健 Ross Yu Huawei Technologies 发件人: Wook Bong Lee [mailto:wookbong.lee@xxxxxxxxxxx] Hi Ross, Thanks for question. For SP1, do you want to put something like “whether BW/Puncturing info can be different for different 80MHz is TBD?” We can run SP after Jianhan’s contribution. For second SP, whether we will have SU PPDU or not is TBD as Sameer mentioned. Personally I prefer having SU PPDU, but (partial) STA-ID in the EHT-SIG. (Please refer 11-20/285, especially slide 8) Rational for including STA-ID in PPDU is for non-STR MLD STA. Please find more explanation in below. I copied from contribution. • For certain conditions, non-STR STA resumes countdown on link B during busy state on link A • Similar to 802.11ax SRP-based spatial reuse backoff procedure • Inter-BSS PPDU (e.g. BSS Color) o Backoff countdown can be resumed as frame not for non-STR STA • Intra-BSS Uplink PPDU o Backoff countdown can be resumed, similar to above o UL/DL bit in HE-SIG-A for HE SU PPDU/ER SU PPDU o UL MU identified by HE TB PPDU • Intra-BSS Downlink PPDU o Backoff countdown can be resumed if PPDU identified to be not destined to itself o STA ID in HE-SIG-B for HE MU PPDU or unable to decode HE-SIG-B of HE MU PPDU o No STA ID info in PHY preamble for SU PPDU and MAC header decoding can take long o Proposal: STA ID info in EHT PHY preamble for SU PPDU Please let me know if this is still not clear. Thank you. Best regards, Wook Bong Lee From: Yujian (Ross Yu) [mailto:ross.yujian@xxxxxxxxxx] Hi Wookbong, Thanks for using the email reflectorJ and trying to harmonize the SPs to make the CC more efficient. For SP1, regarding the 3rd subbullet, BW/Puncturing info can be different for different 80MHz. I think this mechanism still needs to be fully discussed from both MAC/PHY point of view before we run the SP. Meantime, Jianhan’s contribution is still in the queue. For SP2, could you or people in the group share more info about the benefits of carrying STA ID for SU transmission? I don’t find a clear answer myself. The question actually also applies to using HE MU PPDU format for SU transmission back in 11ax. regards 于健 Ross Yu Huawei Technologies 发件人: Wook Bong Lee [mailto:wookbong.lee@xxxxxxxxxxx] Hi Sameer, Thanks for quick response and suggestions. I am fine with all of your suggestion. I will update SPs accordingly. Will wait for more discussion before upload revision 3. SP#1 • Do you support that U-SIG in each 80MHz shall carry puncturing channel info for at-least the specific 80MHz where it is transmitted? – Note1: Each STA needs to decode U-SIG in only one 80MHz segment – Note2: Within each 80MHz segment, U-SIG is duplicated in every non-punctured 20MHz – BW/Puncturing info can be different for different 80MHz – Whether BW and puncturing info bits in U-SIG are carried as a combined or a separate field is TBD SP#2 • Do you agree to have STA-ID related information in an EHT PPDU sent to a single user? Best regards, Wook Bong Lee From: Sameer Vermani [mailto:svverman@xxxxxxxxxxxxxxxx] Thanks Wook Bong for this harmonization attempt. I overall agree with the ideas in your straw-polls. I have two minor comments which you might want to consider:
Regards, Sameer From: Wook Bong Lee <wookbong.lee@xxxxxxxxxxx> CAUTION: This email originated from outside of the organization. Hi PHY fans, This is an email to discuss straw poll for SU SIG contents in 11-20/285. During 3/18 conference call, there was a request to discuss straw poll using e-mail reflector. If you are not interested in this topic, sorry for this e-mail.
First, Eunsung asked to defer the straw poll since he has some more puncturing pattern to propose, and it may impact the signaling design. Eunsung’s contribution was discussed 3/18 call, and there was no agreement to add more puncturing pattern. Second, after I review following two contributions, I agreed with some of ideas in those contributions, i.e. allowing a STA to know exact what is puncturing pattern for the 80MHz. I believe this is useful not only for a different STA to camp different 80MHz (note this feature itself needs more discussion in MAC Adhoc or in Joint group) but also for a non-associated STA to decode FILS or Unsolicited Probe Response frame in MU PPDU which is supported in 11ax for 6GHz operation. So, I modified SP accordingly. In addition to that, we want to propose to include STA-ID related information in SU PPDU as well to aid non-STR STA for MLD operation. Please refer 11-20/285 or 11-19/1405r7, “Multi-link Channel Access Discussion” for more discussion. These are proposed SPs in 11-20/285r2. Uploaded revision 2 in the server. SP#1 • Do you support that U-SIG in each 80MHz shall carry puncturing channel info for at-least the specific 80MHz where it is transmitted? – Note1: Each STA needs to decode U-SIG in only one 80MHz segment – Note2: Within each 80MHz segment, U-SIG is duplicated in every non-punctured 20MHz – BW/Puncturing info can be different for different 80MHz – TBD: separate BW and puncturing info bits in U-SIG SP#2 • Do you agree to have STA-ID related information for SU PPDU in EHT-SIG? If you have any question or any suggested modification, please let us know. Best regards, Wook Bong Lee To unsubscribe from the STDS-802-11-TGBE list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGBE&A=1 To unsubscribe from the STDS-802-11-TGBE list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGBE&A=1 To unsubscribe from the STDS-802-11-TGBE list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGBE&A=1 To unsubscribe from the STDS-802-11-TGBE list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGBE&A=1 To unsubscribe from the STDS-802-11-TGBE list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGBE&A=1 To unsubscribe from the STDS-802-11-TGBE list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGBE&A=1 To unsubscribe from the STDS-802-11-TGBE list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGBE&A=1 To unsubscribe from the STDS-802-11-TGBE list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGBE&A=1 To unsubscribe from the STDS-802-11-TGBE list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGBE&A=1 To unsubscribe from the STDS-802-11-TGBE list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGBE&A=1 To unsubscribe from the STDS-802-11-TGBE list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGBE&A=1 To unsubscribe from the STDS-802-11-TGBE list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGBE&A=1 To unsubscribe from the STDS-802-11-TGBE list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGBE&A=1 |