Thread Links | Date Links | ||||
---|---|---|---|---|---|
Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
Hi, Hanqing I think Laurent already clarified it below. - Additional punctured channel can be added in a transmission as long as it does not solicit a response from the receiver. * RxVector for Inactive_Subchannels is not present. So, I think the example you have shown in the previous email is not allowed. Regards Junghoon From: Hanqing Lou [mailto:Hanqing.Lou@xxxxxxxxxxxxxxxx]
Xiaogang and all, Based on Alfred’s request, I like to continue discussions in the TGbe reflector.
Below is an example Xiaogang mentioned in the joint meeting today and earlier email. I like to confirm the example is NOT allowed in non-TB sounding sequence. Do we have any agreement on that? Another related question
is if the below example valid for TB sounding sequence? “E.g. 160MHz BSS, Beacon indicate 20MHz is disallowed. BFer indicate 996+484 feedback (40MHz punctured in addition to the 20MHz indicated in Beacon) in NDPA of non-TB sounding. Then BFer is soliciting full BW feedback
and BFer indeed puncturing more than indicated in Beacon.” Best regards, Hanqing From: Wook Bong Lee <wookbong.lee@xxxxxxxxxxx>
Hi Xiaogang, Got it. It sounds fine. Thanks.
I didn’t carefully read those following sentences. Best regards, Wook Bong Lee From: Chen, Xiaogang C [mailto:xiaogang.c.chen@xxxxxxxxx]
Hi Wook Bong, I think the following two sub-bullets explains the available BW and address your concern? NDPA and NDP BW can be smaller than BFee’s operating BW from 1st sub-bullet. —If the EHT beamformee’s operating bandwidth is larger than or equal to the bandwidth of NDP frame, the available bandwidth is the entire PPDU bandwidth of the NDP frame when puncture is not applied
and is the entire occupied PPDU bandwidth of the NDP frame when puncture is applied. —If the EHT beamformee’s operating bandwidth is smaller than the bandwidth of NDP frame, the available bandwidth is the beamformee’s entire operating bandwidth when preamble puncturing is not
applied and is the entire occupied bandwidth within the beamformee’s operating bandwidth when preamble puncturing is applied. BRs, Xiaogang. From: Junghoon Suh <Junghoon.Suh@xxxxxxxxxx>
+Ross Yes, I think Full BW means the operating BW of BFee, which should be aligned with the BW of NDPA and NDP as well. Regards Junghoon From: Wook Bong Lee [mailto:wookbong.lee@xxxxxxxxxxx]
Hi Xiaogang, If full bandwidth is NDP BW, then following sentence is correct? Full bandwidth SU, MU or CQI feedback refers to the feedback mode where the feedback RU/MRU size indicated in the Partial BW Info subfield of the EHT NDP Announcement
frame spans all the available bandwidth
within an EHT beamformee’s operating bandwidth. All available bandwidth within operating bandwidth sounds like the NDP-A shall be same bandwidth of operating bandwidth to be full bandwidth. Best regards, Wook Bong Lee From: Chen, Xiaogang C [mailto:xiaogang.c.chen@xxxxxxxxx]
Hi Wook Bong. My understanding is the current definition on Full BW or Partial BW still hold since we always refer to NDP BW as the sounding BW. Are you concerning the case 160MHz BSS send 80MHz NDP? maybe you can clarify where it’s broken. Thanks. BRs, Xiaogang. From: Yanjun Sun <yanjuns@xxxxxxxxxxxxxxxx>
+Bin Xiaogang, please see some editorial
updates so that it’s aligned with the text in 35.14.3 better. In addition, the punctured subchannel(s) indicated by the BW field and Puncturing Channel Information field Thanks Yanjun From: Wook Bong Lee <wookbong.lee@xxxxxxxxxxx>
WARNING:
This email originated from outside of Qualcomm. Please be wary of any links or attachments, and do not enable macros. Hi Xiaogang, I am fine with the text.
Don’t we need to update below as well? Full bandwidth SU, MU or CQI feedback refers to the feedback mode where the feedback RU/MRU size indicated in the Partial BW Info subfield of the EHT NDP Announcement frame spans all the available
bandwidth within an EHT beamformee’s operating bandwidth. Partial bandwidth SU, MU or CQI feedback refers to the feedback mode where the feedback RU/MRU size indicated in the Partial BW Info subfield of the EHT NDP Announcement frame spans part of the available
bandwidth within an EHT beamformee’s operating bandwidth. —If the EHT beamformee’s operating bandwidth is larger than or equal to the bandwidth of NDP frame, the available bandwidth is the entire PPDU bandwidth of the NDP frame when puncture is not applied
and is the entire occupied PPDU bandwidth of the NDP frame when puncture is applied. —If the EHT beamformee’s operating bandwidth is smaller than the bandwidth of NDP frame, the available bandwidth is the beamformee’s entire operating bandwidth when preamble puncturing is not
applied and is the entire occupied bandwidth within the beamformee’s operating bandwidth when preamble puncturing is applied. NOTE 2—For example, if a 160 MHz EHT NDP has a 20 MHz puncturing•The available bandwidth is 140 MHz when the beamformee’s operating bandwidth is 160 MHz or 320 MHz. •The available bandwidth is 80 MHz when the beamformee’s operating bandwidth is 80 MHz and 20 MHz puncturing is not within the beamformee’s operating bandwidth. •The available bandwidth is 60 MHz when the beamformee’s operating bandwidth is 80 MHz and 20 MHz puncturing is within the beamformee’s operating bandwidth. Best regards, Wook Bong Lee From: Chen, Xiaogang C [mailto:xiaogang.c.chen@xxxxxxxxx]
how about change opt1 to (This is only for non-TB sounding), hope it covers the cases raised
on the call: In addition, the punctured subchannel(s) indicated by the BW field and Puncturing Channel Information fields in the U-SIG of NDP shall not include
additional punctured subchannel(s) than those indicated in the Disabled Subchannel Bitmap field in the EHT Operation element. BRs, Xiaogang. From: Zinan Lin <Zinan.Lin@xxxxxxxxxxxxxxxx>
Xiaogang, Thanks for your suggestions. Since some of people here prefer not to add the additional sentence and 11/2019r2 version was uploaded with no additional sentence, I will add your sentence as one
option and update the CR document to 11/2019r3. Please see my
comments inline below. Thanks, Zinan From: Chen, Xiaogang C <xiaogang.c.chen@xxxxxxxxx>
Hi Zinan Confirmed. Partial BW or full BW feedback refers to the NDPA BW (= NDP BW) instead of the occupied subchannels in Beacon. Otherwise, there will be a mess in TB sounding sequence when referring
to full or partial BW. [ZL] It seems to me that the definition you show above are not the same as the definitions of the specs (802.11be D1.3 P399L43). The quoted paragraph shows that
1)
Full BW feedback: feedback RU/MRU size (in the Partial BW Info subfield of the EHT NDPA) spans
ALL the available BW within an EHT beamfomee BW
2)
Partial BW feedback: feedback RU/MRU size (in the Partial BW Info subfield of the EHT NDPA) spans
PART of the available BW within an EHT beamfomee BW For the last sentence, how about this? “the occupied subchannel(s) indicated by the BW field and Puncturing Channel Information fields in the U-SIG (#5657) of NDP shall be the same as the requested subchannel(s) indicated in the Partial
BW Info subfield in the EHT NDP Announcement frame (#7793).
In addition, the requested subchannel(s) indicated in the Partial BW Info subfield in the EHT NDP Announcement frame shall be the same as the occupied subchannel(s) indicated in the Disabled Subchannel Bitmap field in the EHT Operation element.” [ZL] I am fine with adding this new sentence. BRs, Xiaogang. From: Zinan Lin <Zinan.Lin@xxxxxxxxxxxxxxxx>
Hi Xiaogang, Thanks for your prompt response. Please see my
comments/questions inline below. Thanks, Zinan From: Chen, Xiaogang C <xiaogang.c.chen@xxxxxxxxx>
IMO, the sentence below doesn’t really exclude all the cases. E.g. 160MHz BSS, Beacon indicate 20MHz is disallowed. BFer indicate 996+484 feedback (40MHz punctured in addition to the 20MHz indicated
in Beacon) in NDPA of non-TB sounding. Then BFer is soliciting full BW feedback (not violating the sentence below) and BFer indeed puncturing more than indicated in Beacon. “An SU beamformer
shall not solicit partial bandwidth SU feedback from an SU beamformee in an EHT non-TB sounding sequence”
[ZL] I just want to confirm with you ( you are one of the best persons to clarify it😊):
the above example (where the BFer punctures more subchannels than those indicated in the Disable Sunchannel Bitmap field in the EHT Operation element) is considered as a full bandwidth SU feedback but
NOT partial bandwidth SU feedback. If we already agreed, then I would suggest to make it explicit. E.g. “the occupied subchannel(s) indicated by the BW field and Puncturing Channel
Information fields in the U-SIG (#5657) of NDP shall be the same as the requested subchannel(s) indicated in the Partial BW Info subfield in the EHT NDP Announcement frame (#7793),
which is also the same as the disallowed subchannel indicated in the Beacon.”
[ZL] I am not sure if I understand the newly added sentence well.
BRs, Xiaogang. From: Zinan Lin <Zinan.Lin@xxxxxxxxxxxxxxxx>
Hi All, Thank you so much for your helpful discussions. It seems that we reach consensus that adding additional sentence to the paragraph is not needed. Therefore, I decided not to add any additional
sentence. Please take a look at the updated CR document. In addition, if anyone would like to coauthor the CR document, please feel free to let me know. Thank you once again for your discussions. Best, Zinan From: Cariou, Laurent
laurent.cariou@xxxxxxxxx Hi, Yes. For the scope for R1 as far as puncturing other channels than the ones indicated in the beacon. What we converged on is that:
-
Additional punctured channel can be added in a transmission as long as it does not solicit a response from the receiver.
o
RxVector for Inactive_Subchannels is not present.
-
If it solicits a response, the response has to be triggered so that the UL TB PPDU does not overlap with the extra puncturing. I think we should stick to this agreement. And the sentence Wook Bong has clarifies that point and can be used to resolve the CID. Thanks, Laurent From: Yanjun Sun <yanjuns@xxxxxxxxxxxxxxxx>
Thank you for sharing your thoughts. Wook Bong has brought up a good point that D1.3 has introduced the following rule that essentially disallows additional puncturing on top of the pattern indicated in beacons for non-TB sounding:
It looks that this rule has addressed my confusion from the old text in D1.0.
Junghoon, my understading is that NDPA is a MAC frame that can be sent in any PPDU. So Rui is right that it may be sent in EHT PPDU or non-HT dup PPDU. Hope
this helps. Thanks Yanjun From: Junghoon Suh <Junghoon.Suh@xxxxxxxxxx>
WARNING:
This email originated from outside of Qualcomm. Please be wary of any links or attachments, and do not enable macros. Hi, Wook Bong and Rui Let me try to clarify in one of your sentences. Correct me if I am wrong. I think the EHT NDPA is transmitted in a non-HT PPDU format (Puncturing Patterns are indicated in the SERVICE field – I am not sure this puncturing patterns in the SERVICE field is aligned with the
static Puncturing Patterns or aligned with the Partial BW Info subfield), while the NDP is transmitted in an EHT PPDU. However, you guys keep saying the EHT NDPA may be sent in an EHT PPDU. Could you clarify this? Thank you Regards Junghoon From: Wook Bong Lee [mailto:wookbong.lee@xxxxxxxxxxx]
Hi Zinan, I am not a native English speaker, but I am not sure the grammar is correct in below options. Option 1 says: The requested subchannel(s) shall not include punctured subchannel(s). Option 3 says: The subchannel(s) shall not include punctured subchannel(s).
Who includes the punctured subchannel(s)? Regarding CID 7993,
[Rui C] To address CID 7993, I believe we need a different discussion. If NDPA is sent in non-HT dup format, then we cannot puncture more subchannels than the static
puncturing, as there is no puncture information can be signaled in the dynamic bandwidth field. If NDPA is send out in EHT PPDU format, then it can potentially puncture more subchannels than the static puncturing. Group needs to make an agreement on this
one, and add corresponding sentences in the 35.14.3 (Preamble puncturing operation), and/or in the EHT sounding section.
[ZN] Yes, we may need more discussion on this topic. However, I think the above topic is out of scope of CID 7793. The added sentence is sufficient to
state the rule, i.e., the requested subchannels indicated in the Partial BW Info subfield of NDPA shall not include the static punctured subchannel After reading one more time, only full bandwidth SU feedback is allowed in non-TB sounding. No partial bandwidth SU feedback is allowed. An SU beamformer may solicit full bandwidth SU feedback from an SU beamformee in an EHT non-TB sounding sequence. An SU beamformer shall not solicit partial bandwidth
SU feedback from an SU beamformee in an EHT non-TB sounding sequence. In an EHT non-TB sounding sequence case, the occupied bandwidth indicated by the BW field and Puncturing Channel Information fields in the U-SIG field(#5657)
of NDP shall be the same as the feedback RU/MRU size indicated in Partial BW Info subfield in the EHT NDP Announcement frame. Here, if NDPA is sent out in EHT PPDU format and it is not Trigger frame, then what will be puncturing pattern of the PPDU carrying EHT Compressed Beamforming/CQI frame? In MAC spec, we have
35.14.3 Preamble puncturing operation … In an EHT MU PPDU or a non-HT duplicate PPDU, an EHT STA may puncture other subchannels in addition to those indicated in the Disabled Subchannel Bitmap field in the
EHT Operation element. In this case, the EHT STA shall assign an RU or MRU within the nonpunctured subchannel set to a responding EHT STA if the EHT STA uses a triggering frame to solicit a response in a TB PPDU from the responding EHT STA. NOTE—Since the parameter INACTIVE_SUBCHANNELS is not present in the RXVECTOR as defined in Table 36-1 (TXVECTOR and RXVECTOR parameters), a responding EHT STA cannot
learn the additionally punctured subchannels. But in PHY, puncturing other than static one is allowed even in non-OFDMA transmission. 36.3.12.11.3 Preamble puncturing for PPDUs in a non-OFDMA transmission Preamble puncturing in a non-OFDMA transmission is applied by using a single large size MRU that spans the entire bandwidth. The
supported MRUs for non-OFDMA transmission are defined in 36.3.2.2.3 (Large size MRUs(#2025)) and signaled in the U-SIG field(#7008)(#5657)
by setting the Punctured Channel Information field to the puncturing pattern of the large size MRU corresponding to the punctured subchannel (see Table 36-30 (5-bit punctured channel indication for the non-OFDMA case in an EHT MU PPDU(#2402)))(#2616).NOTE—Non-OFDMA
transmission includes PPDUs to a single user, PPDUs to multiple users using MU-MIMO, and EHT sounding NDP. In this case, do we need to include Puncturing Channel Information in the RXVECTOR in case of non-OFDMA EHT MU PPDU reception? Or we don’t allow additional puncturing? I think it
is same for normal data transmission as the recipient needs to determine puncturing pattern for BA. Best regards, Wook Bong Lee From: Zinan Lin [mailto:Zinan.Lin@xxxxxxxxxxxxxxxx]
Hi Rui C., Thanks for sharing your preference.
I discussed the comment with Yanjun when I generated the first version (11/2019r0) for this CID. He agreed with the resolution. Thanks, Zinan From: Rui Cao <rui.cao_2@xxxxxxx>
Hi Zinan, Sorry for the typo. I was referring to CID 7793.
Among existing options, I would prefer Option 0, as the suggested changes seem redundant.
We can wait for Yanjun to clarify his original intention of the comment to address more precisely. Thanks, Rui From: Zinan Lin <Zinan.Lin@xxxxxxxxxxxxxxxx>
Caution: EXT Email
Rui C. ,Thanks for your response! In your response, CID 7993 is discussed. Do you mean CID 7793 instead of CID 7993? We do not have CID 7993 in 11/2019r1. My comments are inline below. All, here is the updated SP including Junghoon’s suggestion: Best, Zinan From: Rui Cao <rui.cao_2@xxxxxxx>
Hi Zinan, Thanks for the clarification. @Yanjun Sun may clarify, I read CID 7993 is trying to clarify
whether extra puncturing is allowed other than the static puncture pattern for sounding. Otherwise, it is obvious that no EHT PPDU or non-HT dup should occupy the static punctured subchannels. However, the proposed resolution is clarifying that the Partial
BW Info field shall not include the subchannels indicated in static puncturing pattern. This information is clear from the sentence that I quoted, as NDPA/NDP cannot occupy the static punctured subchannels. [ZN] Per definition shown in Figure 9-80b (we have discussed this in our email thread before), Partial BW Info subfield indicates the subchannels on which the feedback is requested
(with the corresponding bit in the Feedback Bitmap subfield set to 1), but not subchannels
occupied by either NDPA frame or NDP frame. To address CID 7993, I believe we need a different discussion. If NDPA is sent in non-HT dup format, then we cannot puncture more subchannels than the static puncturing, as there is no puncture
information can be signaled in the dynamic bandwidth field. If NDPA is send out in EHT PPDU format, then it can potentially puncture more subchannels than the static puncturing. Group needs to make an agreement on this one, and add corresponding sentences
in the 35.14.3 (Preamble puncturing operation), and/or in the EHT sounding section.
[ZN] Yes, we may need more discussion on this topic. However, I think the above topic is out of scope of CID 7793. The added sentence is sufficient to state the rule, i.e., the requested
subchannels indicated in the Partial BW Info subfield of NDPA shall not include the static punctured subchannel Thanks, Rui From: Zinan Lin <Zinan.Lin@xxxxxxxxxxxxxxxx>
Caution: EXT Email
Rui
C., Thanks for your response. My response
is inline below. All, So far, there have been 3 options to solve CID7793 (see below). Since we can’t reach a consensus, I plan to run a SP in the coming Joint meeting and will use the most popular one to create
a new revision for this CR document. Hope it will work for all of you. Thanks, Zinan From: Rui Cao <rui.cao_2@xxxxxxx>
Thanks Wook Bong for adding me to the discussion. Hi Zinan and Junghoon, Likely I missed the discussion in last meeting.
If I understand correctly, the proposed change is trying to clarify that the requested feedback “subchannel” shall NOT include static punctured subchannels. In D1.3, there is a sentence right below the paragraph that you are modifying as below:
This rule make it very clear that the beamformer cannot request feedback on any punctured subchannels, including static punctured subchannels indicated in the Disabled Subchannel Bitmap field
in the EHT Operation element. [ZN] CID 7793 wants to clarify whether the non-TB sounding sequence may use a puncturing pattern which is different from the one indicated in beacons. The above sentence you
quoted does not specify the relationship between the requested subchannels which are indicated by the Partial BW Info subfield of the EHT NDP Announcement frame and the static punctured subchannels indicated in the Disabled Subchannel Bitmap field in the EHT
Operation element. That is why we need to add the proposed sentence to address CID 7793. The proposed sentence (either option 1 or option 2) seems redundant to me, and not directly relevant to the original comments in CID 5675 and 7793. Thanks, Rui From: Zinan Lin <Zinan.Lin@xxxxxxxxxxxxxxxx>
Caution: EXT Email
Hi Wookbong, Xiaogang, Thanks for your response. My responses (four places)
are inline below. Thanks, Zinan From: Wook Bong Lee <wookbong.lee@xxxxxxxxxxx>
+ Rui Cao, Yanjun Hi Junghoon, Xiaogang, and Zinan, Thanks for discussion.
First of all, I am sorry but I can’t understand following sentence clearly. “The subchannel(s) of the corresponding resolution bandwidth where the feedback is requested in the Partial
BW Info subfield of the EHT NDP Announcement frame shall not include punctured subchannel(s) indicated in the Disabled Subchannel Bitmap field in the EHT Operation element.” Resolution bandwidth is 20 or 40 MHz depending on bandwidth/resolution bit. What is the subchannels of the corresponding resolution bandwidth? Are you referring “Feedback Bitmap” rather than “resolution bandwidth”? [ZN1] My understanding is “The subchannel(s) of the corresponding resolution bandwidth” means the subchannel(s) could have 20MHz or 40MHz width depending on “resolution bandwidth”
bit value. I don’t think it is necessary either, but I am fine to include it here. Second, regarding Yanjun’s comment: “In case any static puncturing pattern is indicated in beacons, please clarify whether the non-TB sounding sequence may use a puncturing pattern
which is different from the one indicated in beacons” According to current specification, it is allowed. But I don’t think we need extra clarification than the existing sentence in below.
In an EHT non-TB sounding sequence case, the occupied bandwidth indicated by the BW field and Puncturing Channel Information fields in the U-SIG field(#5657)
of NDP shall be the same as the feedback RU/MRU size indicated in Partial BW Info subfield in the EHT NDP Announcement frame. [ZN2] As we have agreed on the last joint meeting and indicated in the discussion of 11/2019r2, the above sentence is not accurate because an occupied bandwidth does not correspond
a single pattern as shown in Table 9-42c. For example, when the occupied bandwidth indicated by the BW field and Puncturing Channel Information fields in the U-SIG field of NDP is 120MHz, there are 4 patterns of subchannels which are requested for feedback
in the case that Feedback RU/MR size is 996+484 and the BW of the EHT NDPA frame is 160MHz. Therefore, there is a need to specify “the occupied subchannel(s) indicated by the BW field and Puncturing Channel
Information fields in the U-SIG of NDP shall be the same as the requested subchannel(s) indicated in Partial BW Info subfield in the EHT NDP Announcement frame.” Obviously, beamformer can’t assign feedback tones in the Disabled Subchannel Bitmap. [ZN3] True. That is why we need to add the last sentence, e.g., “The subchannel(s) of the corresponding resolution bandwidth where
the feedback is requested in the Partial BW Info subfield of the EHT NDP Announcement frame shall not include punctured subchannel(s) indicated in the Disabled Subchannel Bitmap field in the EHT Operation element.” As you can see,
the way to write this sentence is being discussed in the email thread. Best regards, Wook Bong Lee From: Junghoon Suh [mailto:Junghoon.Suh@xxxxxxxxxx]
Xiaogang Where is the quoted sentence from? We sometimes have several redundant sentences across the entire spec to describe the same concept. Sometimes, it is ok to repeat to emphasize. But, I am also ok
to ignore Yanjun’s comment. Yanjun’s comment has pretty much reached a concensus already. Regards Junghoon From: Chen, Xiaogang C [mailto:xiaogang.c.chen@xxxxxxxxx]
Thanks Junghoon. I didn’t realize it can be interpreted that way… Also not sure why we need the last sentence…Commenter’s question was answered already by the text below.
No matter the punctured 20Mhz subchannels(in NDP) are the same as the ones indicated in the beacon or not, they shall not be included in the partial BW req.
[ZN4] True. It is mentioned here. However, this is different from the last sentence of the resolution in 11/2019r2.
BRs, Xiaogang. From: Junghoon Suh <Junghoon.Suh@xxxxxxxxxx>
Hi, Xiaogang As I explained in the previous email to Zinan, the “requested sub-channels” were not described before, so I interpreted the “requested sub-channels” in the original sentence as one of those indication
in the Partial BW Info subfield, which is the indication of RU/MRU. So, for example, for the case of the BW of the NDPA 160 MHz, and the Feedback RU/MRU size 996+484+242 with 011011111, then, this corresponding sentence describes only the sub-channels of 1
in the indication. However, the requested sub-channels can be interpreted as the entire indication, 011011111, without my suggested additional clarification.
So, “the sub-channel(s) of the corresponding resolution bandwidth where the feedback is requested in the Partial BW Info subfield of the EHT NDP Announcement frame” means only those sub-channel position
where “1” indicates. I hope this be clear to you. Hi, Zinan Yes, it was good to replace the acronym BW by “bandwidth”. Regards Junghoon From: Chen, Xiaogang C [mailto:xiaogang.c.chen@xxxxxxxxx]
Thanks Zinan. Hi Junghoon, Can you explain why option 1 is not correct? Maybe with an example? Thanks. The readability of option 1 seems better than the new text.
Option 1: The requested subchannel(s) in the Partial BW Info subfield in the EHT NDP Announcement frame shall not include punctured subchannel(s) indicated
in the Disabled Subchannel Bitmap field in the EHT Operation element (#7793). The subchannel(s) of the corresponding resolution
BRs, Xiaogang. From: Zinan Lin <Zinan.Lin@xxxxxxxxxxxxxxxx>
Hi Junghoon, Thanks for your confirmation. I noticed that “bandwidth” is written in the spec text instead of the acronym BW. So the change should be
The subchannel(s) of the corresponding resolution
Hi all, please let me know if you have any additional comment. I would greatly appreciate if you can send me your response by next Tuesday (01/11/2022) Thanks, Zinan From: Junghoon Suh <Junghoon.Suh@xxxxxxxxxx>
Zinan Yes, it is perfect. It was my mistake to add the CSI there. There can be CQI only feedback type so CSI is not appropriate there. The reason why I clarified by adding the resolution BW is we have description on “resolution BW which is requested” in the prior sentences, but do not have the prior description on requested sub-channels.
My suggestion is to provide an additional clarification between sub-channels and resolution BW. The requested resolution BW is clear to me, because the resolution BW is 20 MHz for the BW less than or equal to 160 MHz. But, when I read the requested sub-channels from your original sentence,
I felt it meant an RU/MRU indicated in the Partial BW subfield. If you take a look at the Partial BW subfield Table, it is nothing but the list of RU/MRU (mostly MRU). Hence, I think my suggested sentence looks clear in meaning just without the word “CSI”. Thank you for taking my suggestion. Regards Junghoon Suh From: Zinan Lin [mailto:Zinan.Lin@xxxxxxxxxxxxxxxx]
Junghoon, Thanks for your suggestion! I have the following comments on your suggestion “The subchannel(s) of the corresponding resolution BW where the CSI feedback is requested in the Partial BW Info subfield of the EHT NDP Announcement
frame shall not include punctured subchannel(s) indicated in the Disabled Subchannel Bitmap field in the EHT Operation element.”:
1.
Corresponding resolution BW is already indicated by the bit of Resolution in the Partial BW Info subfield. I am not sure if we need to add “the corresponding resolution BW”. However, I am fine with adding it
to have further clarification if everyone in the group agrees with it.
2.
I am not convinced why CSI feedback needs to be specified here. I think we can simply say “the feedback” instead of “the CSI feedback” as shown in the specs 802.11be D1.3 P110, the explanation of Partial BW
Info subfield format. Therefore, my suggested sentence is The subchannel(s) of the corresponding resolution BW where the
Thanks, Zinan From: Junghoon Suh <Junghoon.Suh@xxxxxxxxxx>
Zinan, I reviewed this again, and I think the Option 2 is not perfect as well. So, How about this using the “resolution bandwidth” in the highlighted sentences? The subchannel(s) of the corresponding resolution BW where the CSI feedback is requested in the Partial BW Info subfield of the EHT NDP Announcement frame shall not include punctured subchannel(s)
indicated in the Disabled Subchannel Bitmap field in the EHT Operation element. Regards Junghoon From: Zinan Lin [mailto:Zinan.Lin@xxxxxxxxxxxxxxxx]
Junghoon, Thank you for your prompt response and suggestions. I am adding Youhan, Jianhan, Alfred, Wookbong and other authors of this contribution to this email thread. The definition of Partial BW Infor subfield is given as follows (802.11be D1.3 P110L45): Per definition shown above, Partial BW Info subfield indicates the subchannels on which the feedback is requested (with the corresponding bit in the Feedback Bitmap subfield set to 1), but not
subchannels occupied by either NDPA frame or NDP frame. Therefore, considering your suggestion, I propose two options for the last sentence of the following paragraph:
Option 1: The requested subchannel(s) in the Partial BW Info subfield in the EHT NDP Announcement frame shall not include punctured subchannel(s) indicated
in the Disabled Subchannel Bitmap field in the EHT Operation element (#7793).
Option 2: The punctured subchannel(s) indicated in the Disabled Subchannel Bitmap field in the EHT Operation element shall not be requested in the Partial
BW Info subfield in the EHT NDP Announcement frame (#7793). Please let me know your opinion. Thanks, Zinan From: Junghoon Suh <Junghoon.Suh@xxxxxxxxxx>
Hi, Zinan I wonder if I included all the relevant people in this email. In the last resolution sentence you presented today, which is given below, “The requested subchannel(s) in the Partial BW Info subfield in the EHT NDP Announcement frame shall not include any punctured
subchannel indicated in the Disabled Subchannel Bitmap field in the EHT Operation element.” The requested subchannel(s) in the Partial BW Info subfield in the EHT NDP Announcement frame implies including the punctured subchannel(s) in itself. Therefore, “shall not include any punctured subchannel indicated in the Disabled Subchannel Bitmap field”
is not accurate. So, how about this change? “The occupied subchannel(s) in the Partial BW Info subfield in the EHT NDP Announcement frame shall not include any punctured
subchannel indicated in the Disabled Subchannel Bitmap field in the EHT Operation element.” Thank you Regards
This e-mail is intended only for the named recipient(s) and may contain information that is privileged, confidential to Huawei Technologies
Canada Co., Ltd. and/or exempt from disclosure under applicable law. No waiver of privilege, confidence or otherwise is intended by virtue of communication via the internet. Any unauthorized use, dissemination or copying is strictly prohibited. If you have
received this e-mail in error, or are not named as a recipient, please immediately notify the sender and
destroy all copies of this e-mail. --------------------------------------------------------------------- This e-mail and any attachments may contain confidential material for 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 |