| Thread Links | Date Links | ||||
|---|---|---|---|---|---|
| Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
Hi Rojan, Thanks for your comments. Regarding reusing of the ranging Trigger frame, please see the below response. I don’t know if you remember that in the previous CC, but, to define the sensing Trigger frame, I have suggested the two methods, i.e., op1: define new sensing Trigger frame by using the trigger type subfield, op2: reuse the ranging trigger frame variant by using the equal value of the trigger type subfield. As described in CR Doc., I remember that the majority of members prefer option 2 instead of option 1 when we discussed this issue because the sensing trigger frame used in the TB sensing measurement instance is very similar to the ranging Trigger frame. and also, some members don’t want to define the sensing Trigger frame by using a separate value of the trigger type subfield. So, based on the above assumption, I made a CR doc based on option 2. Best regards, Dongguk. From: Rojan Chitrakar [mailto:rojan.chitrakar@xxxxxxxxxxxxxxxx] Hi Dongguk and all, I have attached some comments in the attached. I have copied one comment here for easier discussion: Using a reserved bit (in 11az) to differentiate Sensing TF from Ranging TF seems very odd to me, esp. since it is so much more simpler and cleaner to use a new Trigger Type value (e.g., 9) for Sensing TF. There are 7 reserved Trigger Types left. Why are we taking this route (reusing Ranging TF type for sensing)? This design is sure to lead to many comments in future WG LBs. Regards, Rojan From: Ali Raissinia <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. 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. 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 |