Re: [STDS-802-11-TGAI] [STDS-802-11-TGM] Rewrite of probe-response text
Hello Adrian,
I have not had yet a chance to actually look at your document in detail. I will look at the document in detail on my way to LA; we will have some time in the ad-hoc on Sunday to talk about in in TGai.
Best,
Marc
On 16 Jan 2014, at 16:26, Stephens, Adrian P wrote:
> Hello Marc,
>
> You are right to highlight the interest of this to your group. I should have seen that earlier.
>
> As you are dependent on this text, and you are heavily modifying it, you should have an interest
> in this activity. Hopefully the proof of the rewrite is that the changes you want to make in TGai
> (which are often additional reasons not to send a probe response) will fit more easily into this new
> structure.
>
> I’m happy to meet with those interested to look meeting TGai’s future needs. Or I’m happy to pass
> ownership of this comment resolution to others with a bigger interest than I in its outcome.
>
>
> Best Regards,
>
> Adrian P STEPHENS
>
> Tel: +44 (1793) 404825 (office)
> Tel: +44 (7920) 084 900 (mobile, UK)
> Tel: +1 (408) 2397485 (mobile, USA)
>
> ----------------------------------------------
> Intel Corporation (UK) Limited
> Registered No. 1134945 (England)
> Registered Office: Pipers Way, Swindon SN3 1RJ
> VAT No: 860 2173 47
>
> From: *** 802.11 TGai - Fast Initial Link Set-Up *** [mailto:STDS-802-11-TGAI@xxxxxxxx] On Behalf Of Marc Emmelmann
> Sent: 16 January 2014 15:14
> To: STDS-802-11-TGAI@xxxxxxxxxxxxxxxxx
> Subject: [STDS-802-11-TGAI] Fwd: [STDS-802-11-TGM] Rewrite of probe-response text
>
> Dear TGai folks,
>
> in case you are not on the REVmc mailing list, please take notice of the following mail.
>
> Best,
>
> Marc
>
> Begin forwarded message:
>
>
> From: "Stephens, Adrian P" <Adrian.P.Stephens@xxxxxxxxx>
> Subject: [STDS-802-11-TGM] Rewrite of probe-response text
> Date: 16 January 2014 16:07:56 CET
> To: STDS-802-11-TGM@xxxxxxxxxxxxxxxxx
> Reply-To: "Stephens, Adrian P" <Adrian.P.Stephens@xxxxxxxxx>
>
> --- This message came from the IEEE 802.11 Task Group M Technical Reflector ---
> Dear TGmc folks,
>
> I presented a re-write of the Probe Response text at a TGmc telecon last year, and picked up an action to pull that into a separate document
> and circulate for discussion.
>
> I have done this. The submission is: https://mentor.ieee.org/802.11/dcn/14/11-14-0057-00-000m-cid2129-rewrite-of-probe-response-text.doc
> This needs multiple folks to go through it and determine that I haven’t broken anything. So I’m looking for volunteers to scrutinize this text
> and work with me to address any issue discovered.
>
> The replacement text follows:
>
> A STA that receives a Probe Request frame shall respond as follows:
> 1. If the STA does not match any of the following criteria, and the procedure terminates without sending a response.
> a. A DMG STA that is not a member of a PBSS and that is performing active scan as defined in 10.1.4.3.2 (Active scanning procedure)
> b. A Multi-band capable non-AP STA for which the last received probe request included a Multi-band element[aps1]
> c. The STA is an AP
> d. The STA is a PCP
> e. The STA is in an IBSS
> f. The STA is in an MBSS
> g. The STA is a non-DMG STA in an infrastructure BSS[aps2]
> 2. If the Address 1 field of the Probe Request frame contains an individual address that is not the MAC address of the STA, the procedure terminates without sending a response.
> 3. If the STA is a non-AP STA in an infrastructure BSS and the Address 1 field of the Probe Request frame contains the broadcast address, the procedure terminates without sending a response.[aps3]
> 4. If the STA is in an IBSS, the STA did not transmit a Beacon or DMG Beacon frame since the last TBTT, and the Address 1 field of the Probe Request frame contains the broadcast address, the procedure terminates without sending a response.
> 5. If the STA is a mesh STA and the Mesh ID in the Probe Request frame is not the wildcard Mesh ID and does not match specific Mesh ID of the STA, the procedures terminates without sending a response.
> 6. If the STA is not a mesh STA:
> a. If none of the following apply the procedures terminates without sending a response,
> i. The SSID in the Probe Request frame is the wildcard SSID,
> ii. The SSID in the Probe Request frame matches the SSID of the STA,
> iii. The SSID List element is present and includes the SSID of the STA.
> b. If the Address 3 field of the Probe Request frame does not contain a wildcard BSSID and does not match the BSSID of the STA, the procedures terminates without sending a response.
> 7. A STA that has dot11InterworkingServiceActivated equal to true and receives a Probe Request frame containing the Interworking field in the Extended Capabilities element equal to 1 and an Interworking element terminates the procedure without sending a response unless both the following criteria are met:
> a. The HESSID field of the Interworking element is absent or is present and contains the wildcard HESSID or matches the HESSID of the STA, and
> b. The Access Network Type field of the Interworking element contains the wildcard Access Network Type or matches the Access Network Type of the STA.
> 8. A STA that has dot11RadioMeasurementActivated equal to true and receives a Probe Request frame containing a DSSS Parameter Set element in which the Current Channel field contains a value that is not the same as dot11CurrentChannel terminates without sending a response.
> 9. A DMG STA terminates the procedure without sending a response if the transmit antenna of the DMG STA is not trained to transmit to the STA from which a probe request was received.
> 10. The STA transmits a Probe Response frame as follows:
> a. The Probe Response frame is individually addressed to the STA that generated the Probe Request frame.
> b. Requested Element IDs in the Request element shall be included in the Probe Response if the responding STA supports it. In an improperly formed Request element, a STA may ignore the first element requested that is not ordered properly and all subsequent elements requested. In the Probe Response frame, the STA shall return the requested elements in the same order as requested in the Request element.
> c. If dot11RadioMeasurementActivated is true and if the Request element of the Probe Request includes the RCPI element ID, the STA shall include in the Probe Response an RCPI element containing the measured RCPI value of the received Probe Request frame. If no measurement result is available, the RCPI value shall be set to indicate that a measurement is not available.
>
> A result of the procedures defined in this subclause is that in each non-DMG(11ad)(Ed) infrastructure BSS, and in each IBSS there is at least one STA that is awake at any given time to receive and respond to probe requests. In an MBSS, STAs might not be awake at any given time to respond to probe requests. In an infrastructure BSS or in an IBSS, a STA that sent a Beacon frame shall remain in the Awake state and shall respond to probe requests, subject to criteria in the next paragraph, until a Beacon frame with the current BSSID is received. If the STA is contained within an AP, it shall remain in the Awake state and always respond to probe requests, subject to criteria in the next paragraph. There may be more than one STA in an IBSS that responds to any given probe request, particularly in cases where more than one STA transmitted a Beacon or DMG Beacon(11ad)(Ed) frame following the most recent TBTT, either due to not receiving successfully a previous Beacon or DMG Beacon!
(11ad)(Ed) frame or due to collisions between beacon transmissions.
>
>
> [aps1]This seems really odd.
> [aps2]This was missing from the original “only a STA” list
> [aps3]I think this is correct, but it is an extrapolation from existing rules.
>
>
> Best Regards,
>
> Adrian P STEPHENS
>
> Tel: +44 (1793) 404825 (office)
> Tel: +44 (7920) 084 900 (mobile, UK)
> Tel: +1 (408) 2397485 (mobile, USA)
>
> ----------------------------------------------
> Intel Corporation (UK) Limited
> Registered No. 1134945 (England)
> Registered Office: Pipers Way, Swindon SN3 1RJ
> VAT No: 860 2173 47
>
> _______________________________________________________________________________
> IF YOU WISH to be Removed from this reflector, PLEASE DO NOT send your request to this CLOSED reflector. We use this valuable tool to communicate on the issues at hand.
>
> SELF SERVICE OPTION: Point your Browser to - http://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGM and then amend your subscription on the form provided. If you require removal from the reflector press the LEAVE button.
>
> Further information can be found at: http://www.ieee802.org/11/Email_Subscribe.html_______________________________________________________________________________
>
>
> -----------------------------------------------------------------------------------------
> Marc Emmelmann
> e-mail: emmelmann@xxxxxxxx web: http://www.emmelmann.org
>
> IEEE 802.11 TGai Vice-Chair
>
> Google Scholar: http://scholar.google.de/citations?user=_EfkmxcAAAAJ
>
>
>
>
>
> _______________________________________________________________________________
> IF YOU WISH to be Removed from this reflector, PLEASE DO NOT send your request to this CLOSED reflector. We use this valuable tool to communicate on the issues at hand.
>
> SELF SERVICE OPTION: Point your Browser to - http://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGAI and then amend your subscription on the form provided. If you require removal from the reflector press the LEAVE button.
>
> Further information can be found at: http://www.ieee802.org/11/Email_Subscribe.html_______________________________________________________________________________
>
> _______________________________________________________________________________
> IF YOU WISH to be Removed from this reflector, PLEASE DO NOT send your request to this CLOSED reflector. We use this valuable tool to communicate on the issues at hand.
>
> SELF SERVICE OPTION: Point your Browser to - http://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGAI and then amend your subscription on the form provided. If you require removal from the reflector press the LEAVE button.
>
> Further information can be found at: http://www.ieee802.org/11/Email_Subscribe.html_______________________________________________________________________________
>
-----------------------------------------------------------------------------------------
Marc Emmelmann
e-mail: emmelmann@xxxxxxxx web: http://www.emmelmann.org
IEEE 802.11 TGai Vice-Chair
Google Scholar: http://scholar.google.de/citations?user=_EfkmxcAAAAJ
_______________________________________________________________________________
IF YOU WISH to be Removed from this reflector, PLEASE DO NOT send your request to this
CLOSED reflector. We use this valuable tool to communicate on the issues at hand.
SELF SERVICE OPTION:
Point your Browser to - http://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGAI and
then amend your subscription on the form provided. If you require removal from the reflector
press the LEAVE button.
Further information can be found at: http://www.ieee802.org/11/Email_Subscribe.html
_______________________________________________________________________________