| Thread Links | Date Links | ||||
|---|---|---|---|---|---|
| Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
|
Hi Xiangxin, Thanks for your comment. I think you have some misunderstanding. AP doesn’t need to receive any PPDU exchange between P2P peers. The termination
signaling is carried in a frame from the scheduled STA to AP, the RA will be AP’s MAC address. Regards, Yunbo 发件人:
顾祥新 (Xiangxin Gu) [mailto:Xiangxin.Gu@xxxxxxxxxx]
Hi Yunbo, Thanks for the contribution. My concern is that there is possibility that the AP fails to receive the PPDU successfully exchanged on TDLS. Your design cannot work in this case. BR, Xiangxin Unisoc Technologies Co., Ltd. +86 21 20360600 3324 From: Liyunbo <liyunbo@xxxxxxxxxx>
Hi Alfred, Would you please add 21/552r6 into the MAC agenda, I would like to run a SP. Dear all, 21/552r6 updates the baseline from draft 0.4 to draft 1.0, no other changes from R5 which was used during the presentation. Below are some response
to the comments/questions, further comments/questions are welcome. Q1 : Typically, value 0 indicates that there are not more frames to be transmitted and value 1 indicates that there is more data. Why not use value
0 to indicate early termination? A1: Because currently More Data field is reserved and set to 0, it is much better to use 1 to carry the termination signaling. Otherwise if some
STA want to support Triggered SU, but don’t want to implement this termination mechanism. Use 0 to indicate termination will have trouble. In order to make it clear, I use a new field name with “termination”, so it will make people clearly know that 1 means
last PPDU. Q2: similar return mechanism is used in RDG, why not reuse the signaling in RDG? A2: that is also my first feeling, and I tried to reuse the signaling of RDG at the beginning, but some people concern that RDG is optional and seldom
been implemented, so strongly suggest to use other container for the signaling. Q3: Triggered SU mechanism may be extended to more scenarios in R2, why not define it in R2? A3: TXOP return is a signaling exchange between the AP and scheduled STA, not related to any other third party STAs. So don’t see a problem even
it extend to other scenarios., The new scenario should be a new TXOP Sharing mode, In case current proposed signaling can not cover this new mode, we can define the signaling separately. It will not mix with current existing modes. But if we define the return
signaling in R2, it will makes the basic TXOP Sharing mechanism incomplete, and R1 STA will never understand the signaling defined in R2. Regards, Yunbo 发件人: Alfred Asterjadhi [mailto:asterjadhi@xxxxxxxxx]
Hello all, I uploaded an updated version of the agendas, which contains the agenda for the next conference calls,
scheduled on Wednesday June 02 (Joint), 10:00-12:00 ET and Thursday June 03 (MAC/PHY), 10:00-12:00 ET. The agendas can be found here: https://mentor.ieee.org/802.11/dcn/21/11-21-0785-10-00be-may-july-tgbe-teleconference-agenda.docx Note for PHY: Currently there are no submissions in the agenda. If you have any explicit request for a presentation
please send at least 24-hours in advance. If no request is sent then the PHY ad-hoc call will be cancelled. Please refer to Guideline item below: PS 2: Guidelines for future scheduled PHY conf calls: · Every
time the agenda is sent the TG chair will ask if there are any submissions requests to be added to the PHY submissions queue. Requests can be regarding new submissions or regarding submissions with deferred SPs. · Requests may
explicitly indicate if the requestor prefers to discuss his/her submission at a particular PHY conf call. If there is no such explicit indication then the submission will be added by default to the PHY submissions queue and will be scheduled for presentation
in a subsequent PHY conference call during which there are at least 3 submissions available for discussion. · A
scheduled PHY conference call will be cancelled if the planned PHY agenda for that particular conference call does not have queued at least 3 presentations or at least one presentation with an explicit request. The cancellation notice
in this case will be sent at least 24 hours in advance. DIAL IN DETAILS FOR WEDNESDAY: Join the Joint meeting here: https://ieeesa.webex.com/ieeesa/j.php?MTID=m7889bcab5724fab60f0a3109c4f5298e
Meeting number: 173 040 8872 Meeting password: wireless (94735377 from phones and video systems)
DIAL IN DETAILS FOR THURSDAY: Join the MAC meeting here: https://ieeesa.webex.com/ieeesa/j.php?MTID=m9b52a7a253d0336d36859518aed664ef
Meeting number: 173 076 5440 Meeting password: wireless (94735377 from phones and video systems) Join the PHY meeting here (unless it is Cancelled):
https://ieeesa.webex.com/ieeesa/j.php?MTID=mea851d75965e72bd9b94e57cb474f737 Meeting number: 173 648 4417 Meeting password: wireless (94735377 from phones and video systems) Let me know if you have any questions and/or suggestions. Best Regards, -- 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
This email (including its attachments) is intended only for the person or entity to which it is addressed and may contain information that is privileged, confidential or otherwise protected from
disclosure. Unauthorized use, dissemination, distribution or copying of this email or the information herein or taking any action in reliance on the contents of this email or the information herein, by anyone other than the intended recipient, or an employee
or agent responsible for delivering the message to the intended recipient, is strictly prohibited. If you are not the intended recipient, please do not read, copy, use or disclose any part of this e-mail to others. Please notify the sender immediately and
permanently delete this e-mail and any attachments if you received it in error. Internet communications cannot be guaranteed to be timely, secure, error-free or virus-free. The sender does not accept liability for any errors or omissions.
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 |