Re: [STDS-802-11-TGBE] Comments on "0755 Non-STR AP"
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