| Thread Links | Date Links | ||||
|---|---|---|---|---|---|
| Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
|
Thanks Dongguk, I might be wrong but I thought we could use 11az as baseline for 11bf as we’re still discussing to use Ranging NDPA and NDP format for instance (Claudio
can keep me honest on this?) and if not then it makes sense to introduce a new section. As you can imagine a lot of the texts are redundant. Regards, Ali
From: Dongguk Lim <dongguk.lim@xxxxxxx>
WARNING:
This email originated from outside of Qualcomm. Please be wary of any links or attachments, and do not enable macros. Hi Ali, Thanks for your comments.
I added my response inline below. Please find it and I hope it will be helpful to solve your comments. Thanks, BR, Dongguk.
From: Ali Raissinia [mailto:alirezar@xxxxxxxxxxxxxxxx]
I tend to agree with Dibakar that we should integrate Sensing into the ranging text so that we don’t miss any of the exiting
signaling/behavior. Alternatively, if you choose to take your approach of creating a new subclause for sensing, my suggestion is to include all the other signaling/behavior (more bit, MBSSID TA, HE-LTF Rep, etc.) as an Editor note (Do we need to include this?)
so that we can debate & agree before merging it in. [Dongguk Lim] As I mentioned to Dibakar, I think that it is not a good way to merge the things for the sensing Trigger frame to the ranging trigger frame
described in the 11az because we define the sensing Trigger frame variant. even though it is indicated by using the equal value of trigger type subfield, it is a different trigger frame. Again, since the based drafts for 11bf do not include the 11az, I think
first we have to describe the sensing Trigger frame regardless of overlapping with 11az spec. regarding some fields, I agree with your opinion that we should include some fields where, that can be used differently in 11bf, however, since we don’t
have any discussion for that, I think that after the discussion and making a decision, we can simply add those fields in the sensing trigger frame.
I would think integrating the two would be much easier in terms of new text and figures/diagrams. We would probably Trigger Sound R2R and perhaps what Mengshi suggested, Trigger CSI-threshold Report as new subvariants. [Dongguk Lim] I agree that we can define the new sub-variant for the specific process or operation and a related sub-variant will be added simply by using
the reserved value if we define the new subvariant. Regards, Ali
From: Das, Dibakar <dibakar.das@xxxxxxxxx>
WARNING:
This email originated from outside of Qualcomm. Please be wary of any links or attachments, and do not enable macros. Hi Dongguk,
Thanks for sharing the document. Few comments:
Regards, Dibakar
From: Dongguk Lim <dongguk.lim@xxxxxxx>
Dear TTT members,
I would like to share the CR document for the resolution of CIDs related to the
“Tigger” topic. Attached please find and take look at it.
Your comments and questions will be appreciated. Thanks,
Best regards, Dongguk.
From: Dongguk Lim [mailto:dongguk.lim@xxxxxxx]
Dear TTT members,
Thanks for your interest in the topic
“ Trigger “ After requesting CIDs related to Trigger, Two CIDs (129, 561 ) were reassigned from
“Threshold” to “Trigger”
Please check it in the DCN820r3. and since I didn't receive any request for CIDs, so, as I mentioned in the previous email, to resolve those CIDs and to discuss the sensing Trigger frame,
all CIDs were assigned to me. Therefore, I will prepare the initial document for that and if the drafting is finished, I will share it with you first. Thanks, Best regards, Dongguk.
From: Dongguk Lim [mailto:dongguk.lim@xxxxxxx]
Dear All. I am sending out this email to call for volunteers for comment resolution for Topic Trigger as described in DCN820r1. Currently, 14 comments are submitted and all comments mentioned that the Sensing trigger frame should be defined.
So, for the consistent resolution of the above CIDs, I would like to make an initial resolution document to resolve all CIDs.
If you have a different opinion and if you would like to volunteer to resolve the CID, please let me know..
Thanks a lot and should you have any questions, please feel free to ask. Best regards, Dongguk. ________________________________________________________________________________________
Dongguk Lim
Chief Technology Officer IoT Connectivity Standard Task/Professional
LG Electronics Inc
19, Yangjae-daero 11-gil, Seocho-gu, Seoul, Korea
M.82-10-8996-4690
E.dongguk.lim@xxxxxxx
___________________________________________________________________ To unsubscribe from the STDS-802-11-TGBF list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGBF&A=1 |