Thread Links | Date Links | ||||
---|---|---|---|---|---|
Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
> the
sentence that you raised is giving an restriction when aggregating an
acknowledgement with a triggering frame. It is describing a constraint
under one condition.
> I don’t know if there is normative language that you are looking for in the spec.
Well, if there isn't, this needs to be fixed. In the end the issue is quite simple: what is
it that you are not allowed to do unless both sides support cascading?
> But the first sentence in 26.5.3 MU cascading sequence, where Ming is proposing
to modify below, is the definition of MU cascading.
So where is the normative text corresponding to that sentence? Language like
"shall not do xyz unless cascading supported".
Thanks,
Mark
--
Mark RISON, Standards Architect, WLAN English/Esperanto/Français
Samsung Cambridge Solution Centre Tel: +44 1223 434600
Innovation Park, Cambridge CB4 0DS Fax: +44 1223 434601
ROYAUME UNI WWW: http://www.samsung.com/uk
Hello Mark,
OK, then if this is just some kind of example (イメージ?), where is the normative
specification of what cascading is/requires (using normative language, e.g. "A STA
that supports cascading may/shall/shall not...")?
In other words, the sentence that you raised is giving an restriction when aggregating an acknowledgement with a triggering frame. It is describing a constraint under one condition.
I don’t know if there is normative language that you are looking for in the spec. But the first sentence in 26.5.3 MU cascading sequence, where Ming is proposing to modify below, is the definition of MU cascading.
Best regards,
tomo
From: Mark RISON <m.rison@xxxxxxxxxxx>
Sent: Thursday, April 30, 2020 3:14 PM
To: adachi tomoko(足立 朋子 ○RDC□IT研○WSL) <tomo.adachi@xxxxxxxxxxxxx>
Cc: STDS-802-11-TGAX@xxxxxxxxxxxxxxxxx
Subject: Re: [STDS-802-11-TGAX] 答复: [STDS-802-11-TGAX] CR-MU Cascading
> the sentence that you referred to is, from my understanding, just explaining one case when an AP needs to take care of when transmitting an A-MPDU to a non-AP STA and it’s not the definition.
OK, then if this is just some kind of example (イメージ?), where is the normative
specification of what cascading is/requires (using normative language, e.g. "A STA
that supports cascading may/shall/shall not...")?
Thanks,
Mark
--
Mark RISON, Standards Architect, WLAN English/Esperanto/Français
Samsung Cambridge Solution Centre Tel: +44 1223 434600
Innovation Park, Cambridge CB4 0DS Fax: +44 1223 434601
ROYAUME UNI WWW: http://www.samsung.com/uk
On Thu, 30 Apr 2020 at 02:33, Tomo Adachi <tomo.adachi@xxxxxxxxxxxxx> wrote:
Hello Ming and Mark,
Ming, thanks for considering the definition change. I’m mostly OK, but do we need “, and characterized by the exchange of Control, Data and/or Management frames in both directions”, then? I don’t think it is necessary and should be deleted to avoid confusion.
Mark, the sentence that you referred to is, from my understanding, just explaining one case when an AP needs to take care of when transmitting an A-MPDU to a non-AP STA and it’s not the definition. How I read is that, if an AP wants to transmit an Ack or BA together with a triggering frame to a non-AP STA, then the AP (of course) has the support for MU cascading and the AP also needs to confirm that the recipient has the support for MU cascading.
Best regards,
tomo
From: *** 802.11 TGax - HEW - High Efficiency WLAN *** <STDS-802-11-TGAX@xxxxxxxxxxxxxxxxx> On Behalf Of Mark RISON
Sent: Wednesday, April 29, 2020 3:42 PM
To: STDS-802-11-TGAX@xxxxxxxxxxxxxxxxx
Subject: Re: [STDS-802-11-TGAX] 答复: [STDS-802-11-TGAX] CR-MU Cascading
All these discussions are interesting, but the point is that the only normative
requirement ("shall") in 26.5.3 MU cascading sequence is:
An AP shall not transmit an A-MPDU to a non-AP STA that includes an Ack or BlockAck frame together
with a triggering frame unless both the AP and the non-AP STA have indicated support
This, to me, indicates that the definition of cascading is that there is an A-MPDU
transmission by the AP that contains both a triggering frame and an ack frame of
some kind. Hence my D6.0 comments and proposed changes. If the statement abovedoes not accurately capture the normative requirement(s) then of course an
alternative resolution would be to change it to do so.
Thanks,
Mark
--
Mark RISON, Standards Architect, WLAN English/Esperanto/Français
Samsung Cambridge Solution Centre Tel: +44 1223 434600
Innovation Park, Cambridge CB4 0DS Fax: +44 1223 434601
ROYAUME UNI WWW: http://www.samsung.com/uk
On Wed, 29 Apr 2020 at 02:27, Ganming (Ming) <ming.gan@xxxxxxxxxx> wrote:
Hello Tomo,
Thanks for your reply. In my example, it also contains Ack frames. But my point we do not emphasis the role of control frames, this sequence can be any normal sequence exchange.
Regarding a Trigger frame or a TRS Control subfield carried in a Data frame, we call them triggering PPDU. I make a modification based on your suggestion, how about the following definition.
An MU cascading sequence is a frame exchange sequence between an AP and one or more non-AP STAs carried in an HE MU PPDU in the downlink and HE TB PPDU in the uplink where the HE MU PPDU and the HE TB PPDU contain at least one data frame or management frame, and characterized by the exchange of Control, Data and/or Management frames in both directions. An example of an MU cascading sequence is shown in Figure 26-5 (An example of an MU cascading sequence).
Best wishes
Ming Gan
发件人: tomo.adachi@xxxxxxxxxxxxx [mailto:tomo.adachi@xxxxxxxxxxxxx]
发送时间: 2020年4月28日 12:18
收件人: Ganming (Ming) <ming.gan@xxxxxxxxxx>; STDS-802-11-TGAX@xxxxxxxxxxxxxxxxx
主题: RE: [STDS-802-11-TGAX] CR-MU Cascading
Hello Ming,
For the bad example that you showed below, UL OFDMA BA is a Control frame. So, by deleting Control frames from the definition, that exchange won’t apply.
And triggering non-AP STAs can be done through a Trigger frame or a TRS Control subfield carried in a Data frame. So, the AP doesn’t always need to transmit a Control frame.
How about saying that the MU Cascading is where an AP triggers one or more non-AP STAs to transmit UL Data/Management frames while the AP transmits DL Data/Management frames to those STAs?
Best regards,
tomo
From: Ganming (Ming) <ming.gan@xxxxxxxxxx>
Sent: Tuesday, April 28, 2020 12:27 PM
To: adachi tomoko(足立 朋子 ○RDC□IT研○WSL) <tomo.adachi@xxxxxxxxxxxxx>; STDS-802-11-TGAX@xxxxxxxxxxxxxxxxx
Subject: 答复: [STDS-802-11-TGAX] CR-MU Cascading
Hello Tomo,
Good interruption. Actually I also should have a discussion with you.
Regarding CID 24082, I understand the intension of MU cascading is to exchange data frames through DL MU PPDU and UL TB PPDU. However, if we delete control frames, such as trigger frame and Ack, this sentence will be broken and can be any sequence exchange, like DL MU PPDU (to one set of STAs) + UL OFDMA BA, DL MU PPDU (to another set of STAs) + UL OFDMA BA. It can not reflect the essence of MU cascading sequence. The essence of MU cascading sequence is trigger frame and acknowledgement frame will be multiplexd in HE MU PPDU and TB PPDU as mentioned in the proposal 15/0841r1.
Meanwhile I would like to hear further suggested modification on MU cascading definition.
Best wishes
Ming Gan
发件人: tomo.adachi@xxxxxxxxxxxxx [mailto:tomo.adachi@xxxxxxxxxxxxx]
发送时间: 2020年4月27日 9:51
收件人: Ganming (Ming) <ming.gan@xxxxxxxxxx>; STDS-802-11-TGAX@xxxxxxxxxxxxxxxxx
主题: RE: [STDS-802-11-TGAX] CR-MU Cascading
Hello Ming,
Let me jump in, as I submitted a related comment, CID 24082, the one you cited below.
I think the essential feature of MU cascading is that, both AP and non-AP STAs can exchange data or management frames mutually in a single TXOP that the AP acquired.
Transmitting acknowledgement frames at the AP is required only when the frames received solicited the acknowledgements, so it is a subsidiary behavior.
Best regards,
tomo
From: *** 802.11 TGax - HEW - High Efficiency WLAN *** <STDS-802-11-TGAX@xxxxxxxxxxxxxxxxx> On Behalf Of Ganming (Ming)
Sent: Sunday, April 26, 2020 11:56 AM
To: STDS-802-11-TGAX@xxxxxxxxxxxxxxxxx
Subject: [STDS-802-11-TGAX] CR-MU Cascading
Hello Mark Rison,
I see you have two resubmitted comments with same suggested change as follows, they are not the first round resubmission, at least more than two times. The following proposed changes were discussed in TGax F2F meeting several times while you were not in the room, and the group did not think they are clear.
I think your concern is that the definition of MU cascading in the spec is not clear. I would like to hear your further opinion and other people’s opinion
An MU cascading sequence is a frame exchange sequence between an AP and one or more non-AP STAs carried in an HE MU PPDU in the downlink and HE TB PPDU in the uplink and characterized by the exchange of Control, Data and/or Management frames in both directions. An example of an MU cascading sequence is shown in Figure 26-5 (An example of an MU cascading sequence).
Like CID 24328, you propose to add “In an MU cascading sequence at least one transmission by the AP is a triggering PPDU that contains an Ack or BlockAck frame.” It is not indeed true if we go through the original proposal 15/0841r1 on MU-cascading motion which was passed. In slide 13, it provides an example.
CID
Page
Clause
Comment
Proposed Change
24082
361.26
26.5.3
"An MU cascading sequence is a frame exchange sequence between an AP and one or more non-AP STAs carried in an HE MU PPDU in the downlink and HE TB PPDU in the uplink and characterized by the exchange of Control, Data and/or Management frames in both directions."
The key factor of the MU cascading is the exchange of Data and/or Management frames in both directions. Trigger frame that is a Control frame or A-Control that is not a Control frame can be both used to have the STAs transmit HE TB PPDU. And an Ack or a BlockAck frame that is a Control frame may not be transmitted at all if all the soliciting frames have No Ack policy.Delete "Control, " from the cited sentence.
Add a note as follows, if necessary.
"NOTE - Trigger frames in downlink and Control frames such as Ack or BlockAck frames in downlink and/or uplink may be present accordingly to achieve exchanging Data/Management frames in both directions. A frame that carries a TRS Control subfield may be used instead of a Trigger frame according to the rules specified in 26.5.2 (UL MU operation)"24328
361.25
26.5.3
"An MU cascading sequence is a frame exchange sequence between an AP and one or more non-AP STAs
carried in an HE MU PPDU in the downlink and HE TB PPDU in the uplink and characterized by the
exchange of Control, Data and/or Management frames in both directions." fails to capture the underlying requirementAfter the cited sentence add "In an MU cascading sequence at least one transmission by the AP is a triggering PPDU that contains an Ack or BlockAck frame."
24329
361.25
26.5.3
It is not clear that in an MU cascading sequence there have to be MU PPDUs. The definition just says "characterized by the
exchange of Control, Data and/or Management frames in both directions" and the only normative requirement is "transmit an A-MPDU to a non-AP STA that includes an Ack or BlockAck frame together
with a triggering frame"Delete "HE MU PPDU in the downlink and" and delete "MU " in Figure 26-5--An example of an MU cascading sequence
24427
26.5.3
[Resubmission of comment withdrawn on D5.0] CID 20732. The resolution is vague and not responsive to the comment "Re CID 16076: the comment was valid. The normative requirement is that cascading is defined by the use of "an A-MPDU to a non-AP STA that includes an Ack or BlockAck frame together with a Trigger frame or a frame carrying a TRS Control subfield." (342.33)"
Change the first sentence of the referenced subclause to "An MU cascading sequence is a frame exchange sequence between an AP and a non-AP STA where at least one transmission by the AP is a triggering PPDU that includes an acknowledgment."
Best wishes
Ming Gan
To unsubscribe from the STDS-802-11-TGAX list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGAX&A=1
To unsubscribe from the STDS-802-11-TGAX list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGAX&A=1
--Mark RISON, Standards Architect, WLAN English/Esperanto/Français
Samsung Cambridge Solution Centre Tel: +44 1223 434600
Innovation Park, Cambridge CB4 0DS Fax: +44 1223 434601
ROYAUME UNI WWW: http://www.samsung.com/uk
To unsubscribe from the STDS-802-11-TGAX list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGAX&A=1
To unsubscribe from the STDS-802-11-TGAX list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGAX&A=1
--Mark RISON, Standards Architect, WLAN English/Esperanto/Français
Samsung Cambridge Solution Centre Tel: +44 1223 434600
Innovation Park, Cambridge CB4 0DS Fax: +44 1223 434601
ROYAUME UNI WWW: http://www.samsung.com/uk
To unsubscribe from the STDS-802-11-TGAX list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGAX&A=1
To unsubscribe from the STDS-802-11-TGAX list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGAX&A=1