Hi Yongho,
Thanks for response and updating the presentation. I think we completely on the same page now. That’s the reason I common that we need to consider
the RX/TX period during your presentation.
For the text statement, I still prefer calculate the offset base on the ending time of transmitted PPDU (instead of the difference between the ending
time of one transmit PPDU and the starting time of another receiving PPDU), actually they are the same in technical. It looks cleaner for the reader, because when PPDU doesn’t carry a Trigger frame, we calculate the offset base on the ending of PPDUs.
One more concern about your update proposed solution is that, if we leave a CCA time at the beginning of SIFS time, then after CCA time the channel
will switch to busy status because of cross link interference as showed in below figure. So it means that firstly we need to change current CCA rules.
Because currently, CCA may only need a minimum of about 4us to get a channel status result, but it will continue to perform ED CCA until the start point of Rx/TX period. Once the ED CCA result becomes busy at any time before Rx/Tx , the STA will treat channel
as busy. Secondly, if we ignore the channel status after CCA period and RX/TX period in below figure,
another new issue is STA don’t know whether the channel status switch to busy is only because of cross link interference, or may cause by other OBSS transmission.
It is risk to ignore the ED CCA result.
Anyway, because the time offset value is TBD in both of our SPs, I think our proposed solutions don’t conflict with each other at current value TBD
stage. We can further discuss more details when the group decide the what value it is.
Regards,
Yunbo
发件人: Yongho Seok [mailto:yongho.seok@xxxxxxxxx]
发送时间: 2020年4月20日
15:44
收件人: Liyunbo <liyunbo@xxxxxxxxxx>
抄送: STDS-802-11-TGBE@xxxxxxxxxxxxxxxxx
主题: Re: [STDS-802-11-TGBE] SP for PPDU alignment for non-STR ML: [STDS-802-11-TGBE] TGbe Teleconference [04/17/2020]: Agenda Updated
Hello Yunbo,
Thank for your explanation.
After having more thought, I just found why we have a different view.
I upload the updated document (11-20/188r2). Please check additional analysis from slide 12-17.
You assumed that T2 (in the below email) is less than 2us or 4us. But, depending on an implementation, it can be varied. You can understand what I mean from the slides. :)
BTW, let's talk on tomorrow call.
Regards,
Yongho
2020년 4월 16일 (목)
오후 8:09, Liyunbo <liyunbo@xxxxxxxxxx>님이 작성:
Hi Alfred,
Would you please add below 1 SP into the agenda? I through the topic of next teleconference is BA, and won’t run the SP about constrained ML.
- 11-20-0433-02-00be-ppdu-alignment-in-str-constrained-multi-link (1SP)
Dear all,
I reorganize the SPs and merged them into 1 SP. I think it cover all the case that discussed in doc 19/1305r2, 20/188r1 and 20/433r2, and the SP content doesn’t conflict with any of them. Please find the updated slide: https://mentor.ieee.org/802.11/dcn/20/11-20-0433-02-00be-ppdu-alignment-in-str-constrained-multi-link.pptx
During the teleconference discussion there is a main question that asked by several people, I try to clarify them here. Further comments are welcome.
Q: Try to use a unified rule for different case. Furtherly, there are two parameters are mentioned for PPDU alignment, one is SIFS- T1, the other is T2, should we just use the tighter one?
A: Based on analysis, different cases has different requirements for PPDU alignment, we’d better not tight them without a strong technical reason. My opinion is the spec should provide a guideline for PPDU alignment to solve the technical problems (STR constrain, and ED CS before TB PPDU). Other things can leave to the implementation. In the implementation, if someone want to further use one parameter (which should be the tighter one), it can just do it, it doesn’t conflict with the spec guideline. There are some drawbacks if we adopt a single tighter parameter in spec. Because base on my understanding SIFS-T1 is roughly 14.4 us, and T2 less than 2 or 4 us, they are quite different. The PPDU alignment offset may case by many factors as mentioned 19/1305r2 (different PPDU formats, different OFDM symbol duration, LTF, GI, different channel access timing), so force all PPDU alignment follows the tighter parameter which is not necessary will add burden to implementation.
In the previous discussion, they are discussed case by case, so it looks complex. In the new organized SP, all cases are summarized in a 2*2 table, which will looks clean, and easy for people to understand.
the offset of ending time of PPDU2 compare with ending time of PPDU1 should follows below table:
PPDU1 doesn’t carry Trigger or carry a Trigger with CS Required = 0
PPDU1 carries a Trigger with CS Required = 1
PPDU2 doesn’t carry Trigger or carry a Trigger with CS Required = 0
[-SIFS+T1, SIFS-T1]
[-T2, SIFS-T1]
PPDU2 carries a Trigger with CS Required = 1
[-SIFS+T1, T2]
[-T2, T2]
Regards,
Yunbo
发件人: Alfred Asterjadhi [mailto:asterjadhi@xxxxxxxxx]
发送时间: 2020年4月17日 8:30
收件人: STDS-802-11-TGBE@xxxxxxxxxxxxxxxxx
主题: Re: [STDS-802-11-TGBE] TGbe Teleconference [04/17/2020]: Agenda Updated
[Fixed date in header]
On Thu, Apr 16, 2020 at 5:29 PM Alfred Asterjadhi <asterjadhi@xxxxxxxxx> wrote:
Hello all,
A revised version of the agenda can be found below:
PS: During tomorrow's conference call any member can vote on the straw polls. However, please use the following format:
- Precede your name and affiliation with your voting status (V=Voter, N= Non Voter, P= Potential Voter, A= Aspirant Voter). Will use tomorrow's results to gather some statistics on member voting vs. any member voting.
Best Regards,
Alfred
On Thu, Apr 16, 2020 at 12:27 PM Alfred Asterjadhi <asterjadhi@xxxxxxxxx> wrote:
Hello all,
I uploaded an updated version of the agendas, which contains the agenda for the next conference call (which is a MAC call and starts on Friday 04/17/2020 at 10:00 ET) and can be found here:
The dial in details can be found below
· Bridge for MAC: Webex meeting : Join
Meeting number: 714 940 105
Meeting password: wireless
Please let me know if you have any questions and/or suggestions.
Best Regards,
Alfred
--
Alfred Asterjadhi, PhD
IEEE802.11 TGbe Chair,
Qualcomm Technologies Inc.
Cell #: +1 858 263 9445
Office #: +1 858 658 5302
--
Alfred Asterjadhi, PhD
IEEE802.11 TGbe Chair,
Qualcomm Technologies Inc.
Cell #: +1 858 263 9445
Office #: +1 858 658 5302
--
Alfred Asterjadhi, PhD
IEEE802.11 TGbe Chair,
Qualcomm Technologies Inc.
Cell #: +1 858 263 9445
Office #: +1 858 658 5302
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