Hi Jinjing,
Thanks for clarifications and responses! Please find my comments below inline.
Thanks,
Sharan
From: Jinjing Jiang [mailto:jinjing@xxxxxxxxx]
Sent: Tuesday, June 16, 2020 2:36 PM
To: Sharan Naribole <n.sharan@xxxxxxxxxxx>
Cc: STDS-802-11-TGBE@xxxxxxxxxxxxxxxxx
Subject: Re: [STDS-802-11-TGBE] Comments on "0755 Non-STR AP"
Sharan,
1, Our goal is simply not to rule out Non-STR AP operation in R1 by showing that making it work is truly not complicated compared with any Non-STR STA MLD operation. Currently, we are only interested in Soft AP operation, and our proposal
or any similar ones could serve the very basic rules for a Non-STR AP operation. The schemes that are more involved depend on the group’s decision. Terminology-wise, either we can define a Mobile/Soft AP MLD or we can limit the scope of Non-STR AP MLD with
descriptive or normative languages.
[SN]: Just the medium access protocol itself of non-STR AP seems more complicated,
more restrictive compared to STR AP operation. Surely, the performance is worse than that of STR AP operation. Hence, I don’t understand why regular AP MLD will actively choose to operate as a non-STR MLD. In contrast, Soft AP MLD may have simpler design and
smaller form factor so I do see motivation for that specific case. Also, the other aspects of multi-link BSS operation haven’t been addressed yet in any contribution. Therefore, it is not clear enough how much more additional complexity will be introduced
due to non-STR AP operation.
Apart from EHT single link STAs and legacy devices, a non-AP MLD intending to remain
active on a single link temporarily would be forced to operate on the basic link.
2, In our proposal, UL and DL use the same channel access rules.
3, I am not sure what the regulatory concern is. If you are pointing to SoftAP in 6GHz is now allowed by FCC yet, I would argue let us do not worry about that for now. When we did not have 6GHz approved by FCC yet, the group already worked
to define the HE 6GHz rules. Same thing here too. Based on our estimation, FCC rules should be ready when R1 is launched.
[SN]: Actually, I was referring to the PIFS-based TXOP aggregation presented in your
slides and not specific to 6 GHz. I would have to look up minutes from previous meetings for specific concerns.
4, In terms of fairness, I am not sure what exactly the problem is. If the same scenario already exists in today’s implementation/deployment, sure, it is debatable and worthy of criticism and further improvement, but it is subjective. Anyway,
please elaborate.
[SN]: In your proposal and in non-STR AP operation in general, the EHT single link
STA/legacy STA will be restricted to the basic link which might be on another band. For example, if we consider the PIFS-based aggregation from your slides i.e. conditional link backoff counter=0 and PIFS check on basic link, the mean backoff value for MLDs
will be lower on the basic link than that of the single link STAs on basic link. Perhaps, we can redefine 802.11 backoff rules for the aggregated link.
The alternative mechanisms of Request-to-Trigger add significant airtime overhead just
to enable synchronized transmissions and similarly impact medium access opportunity for devices operating only on the basic link.
Jinjing
Hi Jinjing,
Thanks for your contribution and discussion! I have a few questions:
1. Your contribution is targeting the Soft AP/Mobile AP operation. Do you plan to define Soft AP MLD in 802.11be spec? Your SP mentions non-STR AP MLD in general. I don't think that is your intention, correct?
2. Are the channel access rules in your contribution applying to only the non-STR Soft AP MLD or also the non-AP MLDs? As mentioned by others, it would be unfair for devices operating only on the basic link.
3. Due to the regulatory concerns and unfairness to legacy devices that have been raised previously in the group, any thoughts on placing restrictions (e.g. both basic link and conditional link operate on same band)?
Thanks,
Sharan
-----Original Message-----
From: Jinjing Jiang [mailto:000011624c1439f0-dmarc-request@xxxxxxxxxxxxxxxxx]
Sent: Monday, June 15, 2020 8:20 PM
To: STDS-802-11-TGBE@xxxxxxxxxxxxxxxxx
Subject: Re: [STDS-802-11-TGBE] Comments on "0755 Non-STR AP"
Hi, Dimitry,
Yes, your understanding on our proposal is correct.
Best regards,
Jinjing
Sent from my iPhone
On Jun 15, 2020, at 5:59 PM, Akhmetov, Dmitry <Dmitry.Akhmetov@xxxxxxxxx> wrote:
Hi Jinjing,
I have simple clarification question:
So essentially than mean in case of, for example of 5 and 6 Ghz links, an AP MLD will group all legacy devices on 5Ghz link leaving 6Ghz link as "extension" link for EHT devices.
Single radio EHT device in such case will be forced to operate in 5Ghz link (obviously more congested one) only.
Multi radio STR and non-STR EHT devices may be present AND contend on both 5 and 6Ghz links.
Both non-STR EHT AP and multi-radio EHT devices may contend on both channels, but
1) if win contention on basic link and conditional link is busy than TX only in basic link, otherwise you can transmit over two links in SYNC manner
2) if win contention on conditional link and basic link is busy
than DO NOT transmit. Transmission on conditional link can only be
initiated if TX includes basic link
Correct?
Dmitry
-----Original Message-----
From: Jinjing Jiang <000011624c1439f0-dmarc-request@xxxxxxxxxxxxxxxxx>
Sent: Monday, June 15, 2020 3:53 PM
To: STDS-802-11-TGBE@xxxxxxxxxxxxxxxxx
Subject: Re: [STDS-802-11-TGBE] Comments on "0755 Non-STR AP"
Hi, Dibakar,
If the EHT STA is a single-radio/link STA MLD, it is treated just like a legacy STA, and it will only operate in a basic link. So there is no way for such single-radio EHT STA to initiate channel access on the conditional link only. If there is really a use
case with conditional link channel access for a single-radio STA or enhanced version, further discussion is needed. For now, our current framework intentionally avoids it to not complicate things.
Best regards,
Jinjing
On Jun 15, 2020, at 3:41 PM, Das, Dibakar <dibakar.das@xxxxxxxxx> wrote:
Hi Jinjing,
Thanks for the response. Just have couple more follow up questions on your responses.
" BTW, we are mainly talking about multi-link EHT STAs who can do non-STR on both 5 and 6GHz links, rather than single-radio/link STAs"
-> Do you mean the non-AP STA associated to the soft AP is mainly non-STR and not single radio/single link ?
Regarding #2, if a single radio non-AP EHT STA is trying to send something to non-STR soft AP in a conditional link using EDCA, the AP may not be able to receive it if its busy transmitting to another legacy STA on the basic link.
Regards,
Dibakar
-----Original Message-----
From: Jinjing Jiang <jinjing@xxxxxxxxx>
Sent: Monday, June 15, 2020 2:59 PM
To: Das, Dibakar <dibakar.das@xxxxxxxxx>
Cc: George Cherian <gcherian@xxxxxxxxxxxxxxxx>; Zhou Lan
<zhou.lan@xxxxxxxxxxxx>;
liyunbo@xxxxxxxxxx; Cariou, Laurent
<laurent.cariou@xxxxxxxxx>; Srinivas Kandala <srini.k1@xxxxxxxxxxx>;
Yongho Seok <Yongho.Seok@xxxxxxxxxxxx>;
liwen.chu@xxxxxxx;
Rui.Yang@xxxxxxxxxxxxxxxx;
STDS-802-11-TGBE@xxxxxxxxxxxxxxxxx
Subject: Re: Comments on "0755 Non-STR AP"
Hi, Dibakar,
Thanks for the comments.
1, The main problem for Non-STR AP MLD is to devise a solution such that there won't be a case that a non-STR MLD will transmit and receive at the same time. In terms of the gain, every TXOP, if there is an additional data pipe that could be of use, we think
it is better. Similar analogy could be found on the channel puncture schemes.
BTW, we are mainly talking about multi-link EHT STAs who can do non-STR on both 5 and 6GHz links, rather than single-radio/link STAs.
2, Some companies are interested in Trigger-based access on the conditional link, we have no strong opinion on this. Our proposal works for both DL and UL without the assumption that Triggered channel access is supported. This simply reflects the reality that
most STA won’t be able to send Trigger frame for now.
3, There are 3 flavors in Non-STR STA MLD operation with the STR AP MLD discussed in the group, a) PIFS or some variants of PIFS based method, b) Receiver-assisted method using RTS/CTS-style exchange c) Receiver-decided method; in our opinion, at least a) and
b) could be suitable for Non-STR AP case.
Best regards,
Jinjing
On Jun 15, 2020, at 11:23 AM, Das, Dibakar <dibakar.das@xxxxxxxxx> wrote:
Hi Jinjing,
Thank you for the presentation. I just had few clarification questions:
1. Per this proposal, legacy STAs (that are more likely to be 5 GHz versus 6 GHz in short run) will be parked in basic links while EHT STAs on the conditional link. Now, assuming the 5 GHz link is more congested, the chances of winning channel access for 5
GHz link may be small. Since you are further constraining yourself to transmit on the conditional link only after winning the channel access on the basic link, this means the performance gain for the EHT STA is pretty limited. Looking at the proposal, I am
not sure why this constraint is even needed.
2. Is it assumed that UL for the EHT STA is only Trigger based ?
3. The proposal seems to be suggesting a PIFS-based channel access on conditional link after winning channel access on basic link. Is that correct ?
Regards,
Dibakar
-----Original Message-----
From: Jinjing Jiang <jinjing@xxxxxxxxx>
Sent: Thursday, June 11, 2020 5:17 PM
To: George Cherian <gcherian@xxxxxxxxxxxxxxxx>; Zhou Lan
<zhou.lan@xxxxxxxxxxxx>;
liyunbo@xxxxxxxxxx; Das, Dibakar
<dibakar.das@xxxxxxxxx>; Cariou, Laurent <laurent.cariou@xxxxxxxxx>;
Srinivas Kandala <srini.k1@xxxxxxxxxxx>; Yongho Seok
<Yongho.Seok@xxxxxxxxxxxx>;
liwen.chu@xxxxxxx;
Rui.Yang@xxxxxxxxxxxxxxxx
Cc: STDS-802-11-TGBE@xxxxxxxxxxxxxxxxx
Subject: Comments on "0755 Non-STR AP"
Dear all,
Due to the time constraints at the conference call, I was not able to collect all the comments and answer questions on the Non-STR AP contribution.
Please kindly share your thoughts through this thread, I will try to answer.
Thanks and best regards,
Jinjing
______________________________________________________________________
__ To unsubscribe from the STDS-802-11-TGBE list, click the following
link:
https://urldefense.proofpoint.com/v2/url?u=https-3A__listserv.ieee.org
_cgi-2Dbin_wa-3FSUBED1-3DSTDS-2D802-2D11-2DTGBE-26A-3D1&d=DwIFaQ&c=Jfe
WlBa6VbDyTXraMENjy_b_0yKWuqQ4qY-FPhxK4x8w-TfgRBDyeV4hVQQBEgL2&r=-NRnV4
P7LuK2s1vlWSLyS3b_nx6xPGNypsa1HsvkpsI&m=X7AjY2wqYltXSwJH3tJIfanatUruxq
lphB1ufuhL8KE&s=jdtd3Kkrt-Hv_WnijE-jvdn5iPTs7I9hWhovdpYyRBY&e=
________________________________________________________________________
To unsubscribe from the STDS-802-11-TGBE list, click the following link: https://urldefense.proofpoint.com/v2/url?u=https-3A__listserv.ieee.org_cgi-2Dbin_wa-3FSUBED1-3DSTDS-2D802-2D11-2DTGBE-26A-3D1&d=DwIFaQ&c=JfeWlBa6VbDyTXraMENjy_b_0yKWuqQ4qY-FPhxK4x8w-TfgRBDyeV4hVQQBEgL2&r=-NRnV4P7LuK2s1vlWSLyS3b_nx6xPGNypsa1HsvkpsI&m=X7AjY2wqYltXSwJH3tJIfanatUruxqlphB1ufuhL8KE&s=jdtd3Kkrt-Hv_WnijE-jvdn5iPTs7I9hWhovdpYyRBY&e=
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
|