Yunsong,
Thanks for your help. I posted a revised document with that resolution text.
Steve
From: Yangyunsong <yangyunsong@xxxxxxxxxx>
Sent: Tuesday, April 16, 2019 10:11 PM
To: Steve Shellhammer <sshellha@xxxxxxxxxxxxxxxx>; STDS-802-11-TGBA@xxxxxxxxxxxxxxxxx
Subject: RE: [STDS-802-11-TGBA] TGba ad-hoc meeting (4/17-18): call for submissions
CAUTION: This email originated from outside of the organization.
Hi Steve,
Your editing looks good to me.
Thanks,
Yunsong Yang
Futurewei Technologies
10180 Telesis Court, STE 400
San Diego, CA 92121
Phone: +1-858-754-3638
Yunsong,
I made a few edits on your suggestion. If this is good I can make a revision of the CR document with this resolution.
Regards,
Steve
------------------------
Rejected
First, the comment is invalid as the commenter didn’t identify any change so that the specific wording of the changes that will satisfy the commenter can be determined by the CRC.
Second, the CRC disagree with the commenter on the issue raised. The design is intended that the WUR-SYNC signal only carries the WUR data rate information, so as to simplify the WUR-SYNC detector and to strike a good balance between the
detectability and false alarm on the WUR-SYNC detection. After a WUR receiver detects the WUR-SYNC field it will process the WUR frame, which would indicate whether the WUR frame is intended for that STA. Trying to reduce scanning power consumption by moving
a BSS identifier information into the WUR-SYNC field, which the commenter seems to imply, would result in much higher miss detection rate and false alarm rate on the WUR-SYNC detection, and as a result, significantly comprise the overall performance. If extremely
low scanning power consumption is desired, one can consider using the WUR duty-cycle operation with a low duty ratio.”
CAUTION: This email originated from outside of the organization.
Hi Steve,
I agree with your conclusion that we should disagree with the comment. Maybe we can come up with something, such as the following:
“Rejected. First, the comment is invalid as the commenter didn’t identify any change so that the specific wording of the changes that will satisfy the commenter can be determined by the CRC. Second, the CRC disagree
with the commenter on the issue raised. The design is intended that the WUR-SYNC signal only carries the WUR data rate information, so as to simplify the WUR-SYNC detector and to strike a good balance between the detectability and false alarm on the WUR-SYNC
detection. Therefore, a WUR receiver, when it is on, has no choice but to detect for all WUR-SYNC signals before it can receive a WUR frame, which would indicate whether the WUR frame is intended for the WUR STA or not. Trying to reduce scanning power consumption
by moving a BSS identifier information into the WUR-SYNC, which the commenter seems to imply, would result in much higher miss rate and false alarm rate on the WUR-SYNC detection, and as a result, significantly comprise the overall performance. If extremely
low scanning power consumption is desired, one can consider using the WUR duty-cycle operation with a low duty ratio, instead.”
What do you think?
Thanks,
Yunsong Yang
Futurewei Technologies
10180 Telesis Court, STE 400
San Diego, CA 92121
Phone: +1-858-754-3638
Yunsong,
Thanks for taking a look at the comment resolution.
The issue raised in the comment is that “…multiple BSS sending the same WUR-SYNC signal would cause the WUR receivers listen to the wrong WUR wake-up messages and reduce their battery life.”
STAs may detect a WUR PPDU from another BSS. That is true even if we were to somehow change the preamble. The WUR receiver will check the address fields and then determine that the PPDU is not intended for this STA.
So it will not wake-up the main radio.
So in my personal opinion, this is not an issue.
When we discuss this at the Ad Hoc, maybe we will choose to add some comments like this into the resolution.
Regards,
Steve
CAUTION: This email originated from outside of the organization.
Hi Steve,
Thank you for preparing doc. 11-19-0651r0. For CID 2776, I agree that the comment is an invalid comment as the commenter didn’t identify changes in sufficient detail so that the specific wording of the changes
that will satisfy the commenter can be determined by the CRC.
However, comment resolution guideline (11-11-1625) suggests that
“Before rejecting any comment on the basis of its formal validity, the CRC should first consider whether there is, in fact, something that needs to be fixed. If there is(,) the CRC should consider fixing it, regardless of the formal validity
of the comment. Failure to do so might simply cause delay, with the issue remaining for the next ballot.”
So, the question is: do we agree that the issue raised by the commenter is an issue?
Thanks,
Yunsong Yang
Futurewei Technologies
10180 Telesis Court, STE 400
San Diego, CA 92121
Phone: +1-858-754-3638
Minyoung,
Here is one submission. I will work on some more.
802.11-19/651r1, CR on Sync Field Comments, Steve Shellhammer
Regards,
Steve
From: *** 802.11 TGba - WUR- Wake-up Radio Operation *** <STDS-802-11-TGBA@xxxxxxxxxxxxxxxxx>
On Behalf Of Minyoung Park
Sent: Thursday, April 11, 2019 10:57 PM
To: STDS-802-11-TGBA@xxxxxxxxxxxxxxxxx
Subject: [STDS-802-11-TGBA] TGba ad-hoc meeting (4/17-18): call for submissions
CAUTION: This email originated from outside of the organization.
TGba ad-hoc meeting is scheduled next week, 4/17 and 4/18 as shown below. If you plan to attend in f2f but haven't responded to the epoll, please respond to the epoll so that I have a correct count.
Please send me the following information if you have submissions on the comment resolution on LB237.
Dear all,
Please find the logistics for the ad-hoc meeting:
-
Dates: April 17-18, 2019
-
Location: Intel Santa Clara campus
-
Day 1 (April 17, Wednesday)
-
Start/End time: 10:00 – 18:00 PT
-
RNB building
-
Address: 2200 Mission College Boulevard, Santa Clara, CA, 95054
-
Day 2 (April 18, Thursday)
-
Start/End time: 9:00 – 18:00 PT
-
SC12 building
-
Address: 3600 Juliette Ln, Santa Clara, CA 95054
A conference call will be setup for the meetings.
To unsubscribe from the STDS-802-11-TGBA list, click the following link:
https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGBA&A=1
To unsubscribe from the STDS-802-11-TGBA list, click the following link:
https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGBA&A=1
To unsubscribe from the STDS-802-11-TGBA list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGBA&A=1