| Thread Links | Date Links | ||||
|---|---|---|---|---|---|
| Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
|
Dear Yunsong, For ease of discussion, I have pulled out your suggest text below:
6.3.4.2 MLME-JOIN.request 6.3.4.2.4 Effect of receipt If the MLME of a WUR STA receives an MLME-JOIN.request primitive with a SelectedBSS parameter containing a BSSDescription with a WUR Operating
Class field in the WUR Operation element that contains an unsupported band as indicated by the Supported Band field in the WUR Capabilties parameter, the MLME response in the resulting MLME-JOIN.confirm primitive shall contain a ResultCode parameter that is
not set to the value SUCCESS. I understand your intention, however I believe that rejecting the JOIN.request based on WUR capabilities (e.g. supported bands) may not be appropriate at this stage since the STA may or may not proceed to negotiate WUR mode with the AP.
If the STA does not intend to use the WUR Service, the STA should be allowed to JOIN. In my opinion, such check is better done during the WUR mode negotiation. However, I do not find any text in D2.0 that deals with this (unsupported band); perhaps a new denial
reason needs to be added for WUR mode setup (e.g. Denied. Unsupported band). However that is beyond the scope of this document. Regards, Rojan From: Yangyunsong <yangyunsong@xxxxxxxxxx> Hi Rojan, Thank you for your response. Now, I am OK with the WUR Capabilities being in the JOIN.request and not in the ASSOCIATE.request. Attached please see my further comments and one suggested change (as
highlighted). Thanks, Yunsong Yang Futurewei Technologies 10180 Telesis Court, STE 400 San Diego, CA 92121 Phone: +1-858-754-3638 From:
rojan.chitrakar@xxxxxxxxxxxxxxxx [mailto:rojan.chitrakar@xxxxxxxxxxxxxxxx]
Dear Yunsong, Appreciate your detailed review. Please find my responses in the attached.
With regards to the passing of WUR Capabilities in the Associate.request primitive, I think we have followed the baseline convention. I remember Mark himself clarified during last F2F meeting (during Minyoung’s presentation on clause 6.3)
as to why some capabilities are not passed down in the Associate.request. Reason being that they are already passed down in the JOIN.request and need not be passed down again. Regards, Rojan From: Yangyunsong <yangyunsong@xxxxxxxxxx>
Hi Rojan, Thank you for preparing these resolutions. Attached please see my comments on doc. 0327. Thanks, Yunsong Yang Futurewei Technologies 10180 Telesis Court, STE 400 San Diego, CA 92121 Phone: +1-858-754-3638 From: *** 802.11 TGba - WUR- Wake-up Radio Operation *** [mailto:STDS-802-11-TGBA@xxxxxxxxxxxxxxxxx]
On Behalf Of Rojan Chitrakar Dear Minyoung, Please help to add the following 4 contributions to the agenda: 19/0327, CRs for clause 6.3 MLME SAP CIDs, Rojan Chitrakar (Panasonic) 19/0328, CRs for clause 9.4.2.293 WUR Discovery element CIDs, Rojan Chitrakar (Panasonic) 19/0329, CRs for clause 30.11 WUR Discovery CIDs, Rojan Chitrakar (Panasonic) 19/0352, CRs for clause 30.9.2 and 30.9.3 Protected WUR frames, Rojan Chitrakar (Panasonic) Regards, Rojan From: *** 802.11 TGba - WUR- Wake-up Radio Operation *** <STDS-802-11-TGBA@xxxxxxxxxxxxxxxxx>
On Behalf Of Minyoung Park Dear all, Please send me the following information if you plan to present contributions on the comment resolution on D2.0 (LB237): 1. DCN, Title, Presenter, Affiliation As we did last time, submissions on the comment resolution will be given higher priority. Regards, Minyoung 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 |