Dear all,
I did a quick search of REVmd and it appears that indeed there is precedence of using .indication for unsolicited responses from AP, with at least two examples of a separate request/indication primitive pair defined for unsolicited case.
Perhaps we can go with Mark’s second option to avoid any possible ambiguity?
6.3.66.7 MLME-GATS-TERM.indication
6.3.66.7.3 When generated
This primitive is generated when the STA receives an
unsolicited DMS Response frame from the AP or peer
mesh STA.
6.3.72.2 MLME-QOS-MAP.request
6.3.72.2.1 Function
This primitive is used by an AP to transmit an
unsolicited QoS Map Configure frame to a specified non-AP
STA MAC entity. The specified non-AP STA MAC address is an individual MAC address.
6.3.72.3 MLME-QOS-MAP.indication
6.3.72.3.3 When generated
This primitive is generated when the non-AP STA receives a QoS Map element in an
unsolicited QoS Map
Configure frame from the AP.
6.3.83.2 MLME-QMFPOLICY.request
6.3.83.2.1 Function
This primitive requests the transmission of an
unsolicited QMF Policy frame to a peer entity.
6.3.83.3 MLME-QMFPOLICY.indication
6.3.83.3.1 Function
This primitive indicates that an
unsolicited QMF Policy frame has been received from a peer entity.
Regards,
Rojan
From: *** 802.11 TGba - WUR- Wake-up Radio Operation *** <STDS-802-11-TGBA@xxxxxxxx>
On Behalf Of Xiaofei Wang
Sent: Monday, September 16, 2019 5:52 PM
To: STDS-802-11-TGBA@xxxxxxxxxxxxxxxxx
Subject: Re: [STDS-802-11-TGBA] Call for contributions for TGba F2F at Hanoi, Vietnam
Dear Mark & Yongho,
Thanks for the discussion. Prior to the September meeting, we had a very similar discussion on the 802.11ba reflector on which primitive should handle the unsolicited WUR Mode Setup frames. The reasoning for
not to use .indication primitive is indeed similar to what Mark described and are following:
- Currently the unsolicited WUR Mode Setup frames is generated by the AP by using .response primitive (the same for responding to a requesting WUR Mode Setup frame received from a non-AP STA)
- The .indication primitive would need additional parameters if it needs to handle the unsolicited WUR Mode Setup frames
- The unsolicited WUR Mode setup frame can only be transmitted to the non-AP STA if the non-AP STA has transmitted a WUR Mode Setup frame earlier to the AP requesting to set up WUR mode
My original comment is meant to clarify that the .confirm primitive is only generated if it has received a response WUR mode Setup frame. If it makes Yongho happier, I can remove the part on unsolicited WUR Mode
frames so that new primitives can be added to handle the unsolicited WUR Mode Setup frames. Though changes may be needed also to not to use the .
Best regards,
Xiaofei Clement Wang • Principal Engineer • InterDigital
2 Huntington Quadrangle, Melville, NY, 11801 • T: +1 631-622-4028
From: *** 802.11 TGba - WUR- Wake-up Radio Operation *** <STDS-802-11-TGBA@xxxxxxxx>
On Behalf Of Yongho Seok
Sent: Monday, September 16, 2019 06:32
To: STDS-802-11-TGBA@xxxxxxxxxxxxxxxxx
Subject: Re: [STDS-802-11-TGBA] Call for contributions for TGba F2F at Hanoi, Vietnam
Basically, I am curious if the MLME needs to cover all possible scenarios. -_-
BTW, if it is needed, Mark's second option can be more clear to me.
All,
Jumping into the middle of this discussion without much context, I realize…
I note that there is a difference between WUR Mode Setup frames sent by a non-AP STA and by an AP, specifically, the Action Type being set to a “… Request” or “… Response”. And,
the unsolicited WUR Mode Setup from an AP is explicit that it “includes an unsolicited WUR Mode Setup frame with the Action Type in WUR Mode element set to “Enter WUR Mode Response” “.
As such, I think it is reasonable to claim that the AP sending such a frame is, in effect, a response to an “Enter WUR Mode Request” that occurred some time in the past, so it’s
reasonable to think of this as a .response/.confirm. (But, yes, it is also happening some time after a prior “Enter WUR Mode Response” frame was sent, which adds some confusion about the nature of this.)
Plus, in the solicited case, there is a direct connection between a “Enter WUR Mode Request” coming from a .request and causing a .indication, and a “Enter WUR Mode Response” coming
from a .response and generating a .confirm.
To avoid considerable confusion in how we think about processing (primitive -> frame) and (frame -> primitive) transactions, I think we want to, either:
-
Use .response and .confirm for the unsolicited “Enter WUR Mode Response” just like the solicited “Enter WUR Mode Response” does
OR
-
Use a different primitive for the unsolicited case (such as MLME-WURMODEUPDATE or MLME-WURMODEUNSOLICITEDSETUP, or some such), so that it’s clear that this situation works differently, in which case this can be a .request/.indication pair without confusion.
Just a suggestion/food for thought.
Mark
From: *** 802.11 TGba - WUR- Wake-up Radio Operation *** <STDS-802-11-TGBA@xxxxxxxx>
On Behalf Of Yongho Seok
Sent: Monday, September 16, 2019 2:03 AM
To: STDS-802-11-TGBA@xxxxxxxxxxxxxxxxx
Subject: Re: [STDS-802-11-TGBA] Call for contributions for TGba F2F at Hanoi, Vietnam
The services provided by the MLME to the SME are specified in this subclause. These services are
described in an abstract way (following the model described in ITU-T Recommendation X.210 [B56]) and do not imply any particular implementation or exposed interface. MLME SAP primitives are of the general form ACTION.request primitive followed by ACTION.confirm
primitive (for an exchange initiated by the SAP client) and ACTION.indication primitive followed by ACTION.response primitive (for an exchange initiated by the MLME). The SME uses the services provided by the MLME through the MLME SAP.
3.3.9 request (primitive); requestor.submit (primitive): A submit primitive issued by a requestor.
3.3.10 indication (primitive); acceptor.deliver (primitive): A deliver primitive received by an acceptor.
3.3.11 response (primitive); acceptor.submit (primitive): A submit primitive issued by an acceptor.
3.3.12 confirm (primitive); requestor.deliver (primitive): A deliver primitive received by a requestor.
What you are saying is not a requester's action. Instead of the confirm primitive, I suggest to use the indication primitive.
Dear Rojan and all,
Please see an update CR document 11-19/1539r1.
In this revision, I have:
-
Added language to WURModesetup.confirm and WURModesetup.indication to clarify that an unsolicited WUR Mode Setup frame is handled by the WURModesetup.confirm primitive.
-
Added WURPNUpdate parameter for all WURModeSetup primitives (.request, .confirm, .indication and .response).
It is the question whether we want to remove the sentence “This
primitive is generated by the MLME as a result of an MLME-WURMODESETUP.request primitive and indicates the results of the request.”
from 6.3.122.3.3. personally, I am ok either way deleting or keeping it. It can be argued that even unsolicited WUR Mode Setup frame is an distant result of .request primitive, but it is not very relevant.
Please let me know of any comments or changes.
Best regards,
Xiaofei Clement Wang • Principal Engineer • InterDigital
2 Huntington Quadrangle, Melville, NY, 11801 • T: +1 631-622-4028
Hi Xiaofei,
Yunsong has a valid point regarding WUR Operation element missing in .indication if used for unsolicited responses. Either we should add it in .indication or
we should clarify that .confirm is used for unsolicited responses and not .indication.
On a related note, WUR Mode Setup frames can also carry the WUR PN Update element. We missed it last time. If it is not too much trouble, can I request you to
also add a WUR PN Update field in all four primitives (request, confirm, indication, response) with following suggested text:
Name: WUR PN UPdate
Type: WUR PN Update element
Valid range: One or more WUR PN Update elements as defined in 9.4.2.300 (WUR PN Update element)
Description: Provides information related to update of WUR PNs. The parameter is optionally present if dot11RSNAWURFrameProtectionActivated is true; otherwise
not present.
Thank you.
Best Regards,
Rojan
From: Yunsong Yang <yunsongyang1@xxxxxxxxx>
Sent: Thursday, 12 September 2019 3:58 AM
To: Xiaofei Wang <Xiaofei.Wang@xxxxxxxxxxxxxxxx>
Cc: STDS-802-11-TGBA@xxxxxxxxxxxxxxxxx; Rojan Chitrakar <rojan.chitrakar@xxxxxxxxxxxxxxxx>; Huang, Po-kai <po-kai.huang@xxxxxxxxx>;
Rui Yang <Rui.Yang@xxxxxxxxxxxxxxxx>; Joseph Levy <Joseph.Levy@xxxxxxxxxxxxxxxx>
Subject: Re: [STDS-802-11-TGBA] Call for contributions for TGba F2F at Hanoi, Vietnam
Hi Xiaofei,
Receiving an unsolicited WUR Mode Setup frame should be reported to the SME by using .confirm, but not .indication primitive, because the unsolicited WUR Mode
Setup may contain the WUR Mode element and WUR Operation element. The .indication primitive doesn't contain the WUR Operation parameter and therefore can not be used for conveying the WUR Operation element received, unless we add one.
I will not be in Hanoi. I recommend that you discuss with the group to first determine which primitive should be used from semantics PoV before deciding on whether
to add a WUR Operation parameter to the .indication primitive or not. I will be happy to follow this up via e-mail. Thanks.
Dear Yunsong,
Thank you for your review.
Originally I had “in response to a WUR Mode Setup frame transmitted by the STA, or that is an unsolicited WUR Mode Setup frame.” But I deleted the last
part before sending out because of the following reasoning:
From the reading of the .indication primitive, it seems that the unsolicited WUR Mode Setup frame is handled there. For example, for the .indication primitive, it says
“6.3.122.4.3 When generated
This primitive is generated by the MLME when a WUR Mode Setup frame is received.
6.3.122.4.4 Effect of receipt
On receipt of this primitive, the SME should operate according to the procedure in 29.8.2 (WUR mode setup).”
In addition, for the .comfirm primitive it says it is a result of a .request primitive and therefore it is probably not for unsolicited WUR Mode Setup frame.
But I think it is very important that we use precise language for the MLME primitives to differentiate the various primitives.
I plan to discuss this issue during the F2F meeting since there seems to be some confusion about the unsolicited WUR Mode Setup frame case.
Best regards,
Xiaofei Clement Wang • Principal Engineer • InterDigital
2 Huntington Quadrangle, Melville, NY, 11801 • T: +1 631-622-4028
From: *** 802.11 TGba - WUR- Wake-up Radio Operation *** <STDS-802-11-TGBA@xxxxxxxx>
On Behalf Of Yunsong Yang
Sent: Wednesday, September 11, 2019 13:06
To: STDS-802-11-TGBA@xxxxxxxxxxxxxxxxx
Subject: Re: [STDS-802-11-TGBA] Call for contributions for TGba F2F at Hanoi, Vietnam
Hi Xiaofei,
Thank you for preparing this CR. I think we should ensure tnat the amended text also covers the case of receiving unsolicited WUR Mode Setup frame. Therefore, attached please see
my comment and proposed modification on your text. Thanks.
Dear Minyoung,
I have one contribution:
11-19/1539 CR for CID 3356 Xiaofei Wang (InterDigital)
Best regards,
Xiaofei Clement Wang • Principal Engineer • InterDigital
2 Huntington Quadrangle, Melville, NY, 11801 • T: +1 631-622-4028
From: Minyoung Park <mpark.ieee@xxxxxxxxx>
Sent: Tuesday, September 10, 2019 18:00
To: STDS-802-11-TGBA@xxxxxxxxxxxxxxxxx
Cc: Yongho Seok <yongho.seok@xxxxxxxxx>; Alfred Aster <asterjadhi@xxxxxxxxx>; Steve Shellhammer <sshellha@xxxxxxxxxxxxxxxx>;
Suhwook Kim <suhwook.kim@xxxxxxx>; Xiaofei Wang <Xiaofei.Wang@xxxxxxxxxxxxxxxx>; Leif Wilhelmsson R <leif.r.wilhelmsson@xxxxxxxxxxxx>;
Woojin Ahn <woojin.ahn@xxxxxxxxxxxxxx>
Subject: Call for contributions for TGba F2F at Hanoi, Vietnam
Dear all,
If you have contributions on the comment resolution, please send me the following information:
DCN, Title, Author (affiliation)
The following table shows the unresolved CIDs and assignees. Currently we have total 28 unresolved CIDs. If you see your name in the table, please make sure you prepare resolutions
for the f2f meeting. If you cannot provide resolutions to the comments, please let me know so that we can reassign them to others you can resolve the comments.
|
Row Labels
|
Count of Assignee
|
|
Yongho
|
9
|
|
Woojin
|
4
|
|
Alfred
|
4
|
|
Steve
|
4
|
|
Po-Kai
|
2
|
|
Suhwook
|
2
|
|
Xiaofei
|
1
|
|
Leif
|
1
|
|
Minyoung
|
1
|
|
Grand Total
|
28
|
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
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
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
|