ANQP-SD Response When Service Mismatches

1. ANQP-SD Response When Service Mismatches Authors: Date: 2015-11-09 Yunsong Yang, Huawei

2. Abstract This contribution addresses the issue raised by the LB216 CID #2384 and provides a couple of options to consider for resolving the issue. Yunsong Yang, Huawei

3. Issue raised by CID #2384 • In P802.11aq D3.0, clause 10.26.2 (Unsolicited PAD procedure), the last paragraph states that if a STA finds a matching service (from the Beacon), the STA may proceed with ANQP-SD procedure. • However, as we know, there is a non-zero probability of false positive. • Thus, in clause 10.26.4 (ANQP-SD procedure), an AP (actually, the proxy server), after receiving an ANQP-SD request, needs to verify that each service requested (in the Service Information Request ANQP-element) indeed matches a service offered, in a similar way as the AP verifies the matching in clause 10.26.3 (Solicited PAD procedure).

4. Discussions • Discussion point #1: • Regarding that the AP needs to verify the service matching, the proposed resolution is to add some text similar to that used in clause 10.26.3. • Discussion point #2: • If the service indeed matches, the existing text in the second paragraph under 10.26.4 in D3.0 is still OK. The proposed resolution is to reuse the existing text. • Discussion point #3: • If the service doesn't match, TGaq needs to consider how the AP/proxy server should respond. • A couple of options are listed in the next few slides for considerations.

5. Option 1 if a service doesn’t match • The AP/proxy server doesn’t provide the (ANQP-SD) response to a (ANQP-SD) requested service if it doesn’t match any service offered. • When there are multiple Tuples in a Service Information Request ANQP-element, the AP/proxy server only provide response(s) for the matched service(s). If all requested services are not matched, the AP/proxy server doesn’t send an ANQP-SD response at all. • If the AP/proxy server doesn’t send an ANQP-SD response, the GAS query containing the ANQP-SD request eventually times out (after QueryFailureTimeout) and the requesting STA terminates the GAS query, and along with it, the ANQP-SD request. • A requesting STA shouldn’t immediately repeat the ANQP-SD request for the same service of which the GAS query has been timed out or of which the response Tuple is missing in the ANQP-SD response received. • Pro: no change to Service Information Response ANQP-element format • Con: the requesting STA may not know that the service mismatches and may repeat the same request later.

6. Option 2 if a service doesn’t match • Add a 1-octet Reason Result Code field (similar to the one in 11af RLQP-elements) in the Service Information Response ANQP-element as below • The Reason Result Code field values: • 1: SUCCESS in answering all requests. • 2: REFUSED answering some or all requests due to mismatch of service(s). • Other values: reserved. • The requesting STA shall not repeat ANQP-SD request for a mismatched service. [Note: this Reason Result Code field is different from the Status Code field at the GAS frame level (or the ResultCode in MLME-GAS.confirm/response), and should be treated as a part of the ResponseInfo in MLME-GAS.confirm/response. For example, the Reason Result Code field may be REFUSED while the Status Code field in the GAS frame is SUCCESS. Otherwise, there may be significant amount of text changes related to GAS (e.g., MLME, Status Code field, and GAS protocol).] • Pro: the STA knows that the service mismatches and won’t repeat the request. • Con: more text changes, e.g., Service Information Response ANQP-element format, ANQP-SD procedure (hopefully no change to the GAS protocol).

7. November 2015 Straw Poll • Which option do you prefer that the AP/proxy server reacts when a service in an ANQP-SD request received doesn’t match any service offered? • Option 1 as described: • Option 2 as described: • Abstain: Yunsong Yang, Huawei