zilongwang/ReadingBank huggingface dataset:
S1G Open-Loop Link Margin Index <ANA> No RPS <ANA> No Page Slice <ANA> No AID Request <ANA> No AID Response <ANA> No S1G Sector Operation <ANA> Yes S1G Beacon Compatibility <ANA> No Short Beacon Interval <ANA> No Change Sequence <ANA> No TWT <ANA> Yes S1G Capabilities <ANA> Yes Subchannel Selective Transmission <ANA> No Authentication Control <ANA> Yes TSF Timer Accuracy <ANA> No Relay <ANA> Yes Reachable Address <ANA> Yes Relay Discovery <ANA> No Probe Response Option <ANA> No AID Announcement <ANA> Yes Short Probe Response Option <ANA> No Activity Specification <ANA> No Sectorized Group ID List <ANA> Yes S1G Operation <ANA> No Header Compression <ANA> Yes SST Operation <ANA> No MAD <ANA> No Activation <ANA> Yes [CID 3159] Instruction to TGah editor: Please modify subclause 10.44d BSS) of TGah D2.1 as follows: (Will overwirte the approved resolution to CID 3509) 10.44d Sensor-only BSS 10.44c7 S1G BSS type and STA type S1G non-AP STAs are categorized into two types, sensor STAs and non-sensor STAs. A non-AP sensor STA shall set the STA Type Support subfield value in the S1G Capabilities Info field (Table of the S1G Capabilities Info field) to 1. A non-sensor STA shall set the STA Type Support subfield value in the S1G Capabilities Info field (Table of the S1G Capabilities Info field) to 2. There are three types of BSS that an S1G AP can set up: sensor BSS, non-sensor BSS, or mixed BSS. A sensor BSS only supports sensor STAs. A non-sensor
is for user u, where is defined in Table 24-6 (Frequently used parameters) is for user u, where is defined in Table 24-6 (Frequently used parameters) and are defined in 24-4 (Timing-related constants). The value of the PSDU_LENGTH parameter returned in the PLME-TXTIME.confirm primitive for an NDP is 0. TGah Editor: Please add the following highlighted row in Table 24-1 below to resolve CIDs 3527, 3528, 3529, 3530 TXVECTOR and RXVECTOR parameters LENGTH FORMAT is S1G and AGGREGATION is AGGREGATED Indicates the packet duration in number of symbols in the S1G PSDU. Y Y FORMAT is S1G_DUP_2M and AGGREGATION is AGGREGATED Indicates the packet duration in number of symbols in the S1G 2 MHz Duplicate PSDU. Y Y FORMAT is S1G_DUP_1M and AGGREGATION is AGGREGATED Indicates the packet duration in number of symbols in the S1G 1 MHz Duplicate PSDU. Y Y FORMAT is S1G and AGGREGATION is NOT_AGGREGATED Indicates the packet duration in number of octets in the S1G PSDU. Y Y FORMAT is S1G_DUP_2M and AGGREGATION is AGGREGATED Indicates the packet duration in number of symbols in the S1G 2 MHz Duplicate PSDU. Y Y FORMAT is S1G_DUP_1M and AGGREGATION is AGGREGATED Indicates the packet duration in number of symbols in the S1G 1 MHz Duplicate PSDU. Y Y Otherwise See corresponding entry in Table 20-1 and Table 22-1. APEP_LENGTH FORMAT is S1G If equal to 0, indicates a S1G NDP PPDU for both RXVECTOR and TXVECTOR. If greater than 0 in the TXVECTOR, indicates the number of octets in the range 1 to 1 048 575 in the A-MPDU pre-EOF padding (see 9.12.2) carried in the PSDU. This parameter is used to determine the number of OFDM symbols in the Data field that do not appear after a subframe with 1 in the EOF subfield. O Otherwise See corresponding entry in Table 20-1 and Table 22-1.
IEEE P802.11 Wireless LANs (LB203) TGah D2.0 MAC Comment Resolutions on Group Sectorization Date: 2014-09-03 Author(s): Name Affiliation Address Phone Email George Calcev Huawei Inc. George.Calcev@huawei.com This document provides resolutions for MAC CIDs on Sectorization. CID 3372, 3576, 3622, 3625, 3626, 3647, 3722, 3723, 3724, 3733 CID Clause Number(C) Comment Proposed Change 3622 Jerome Henry 8.4.2.170e 134 21 "by default all stations consider themselves as in grp 0". Some STAs may not support sectorization, and would not consider themselves in grp 0 Specify that "STAs supporting sectorization consider themselves in grp 0 by default". Revised 3576 Zhang 9.48 293 51 Why define two Sectorized Tx modes in parallel? Our experience with some optional 11n features proved that multiple modes of the same feature will eventually kill this feature, because of interop issues. Merge the two sectorization modes into one mode Reject. 3722 Liwen Chu 8.4.2.170e 133 1 How can you indicate Period in Beacon Intervals when Period is in of 10 milliseconds? Change to in 0.1 Beacon Interval Reject 3723 Liwen Chu 8.4.2.170e 133 11 How can you indicate Sector Duration in Beacon Intervals when Period is in units of 10 milliseconds? Change to in 0.1 Beacon Interval Reject 3724 Liwen Chu 8.4.2.170e 134 6 If the AP has sector zed antenna and each antenna's sector can't cover whole BSS in a sector zed beacon interval, allowing GrpID 0 STAs to transmit in any beacon interval makes no sense. Add an indication to indicate whether GrpID 0 STAs can transmit in a sectorized beacon interval. Reject 3372 Alfred 9.48.3 295 1 The group sectorization procedure is still not very clear. I think it also need to be clear how to differentiate sectorized Beacon Intervals and Omni Beacon intervals from non-AP STA point of view. As in comment. Revised
Access protocol parameters [EDCA with default EDCA Parameters set] Center frequency, BW and primary channels Frequency 1 is used. 5GHz all BSSs are using the same 80MHz channel [Same Primary channel] 2.4GHz All BSSs are 20MHz BSS on same channel Aggregation [A-MPDU / max aggregation size / BA window size, No A-MSDU, with immediate BA] Max # of retries 10 RTS/CTS Threshold [no RTS/CTS] Association X% of STAs are associated with the strongest AP, Y% of STAs are associated with the second-strongest AP, and Z% of STAs are associated with the third-strongest AP. Z% of STAs are not associated. Detailed distribution to be decided. [X=100, Y=0,Z=0] Management It is allowed to assume that all APs belong to the same management entity Traffic model (Per each BSS) - TBD # Source/Sink Name Traffic definition Flow specific parameters AC Downlink D1 AP/STA1 to Highly compressed (streaming) T2 D2 AP/STA11 to AP/STA20 Web browsing T4 D3 AP/STA21 to AP/STA25 file transfer T3 … … DN AP/STAN Uplink U1 AP/STA1 to AP/STA10 Highly compressed (streaming) – UL TCP ACKs… U2 AP/STA11 to AP/STA20 Web browsing: – UL TCP ACKs… U3 STA26/AP to STA30/AP Local file transfer T3 … … UN STAN/AP P2P
T3 Internet streaming video/audio T4 4k video streaming T5 Online game server T6 Management: Beacon T7 Management: Probe requests T8 Virtual desktop infrastructure T9 VoIP Reference traffic profile for Scenario 3 Traffic Model # Traffic model name Description Application traffic (Forward / Backward) Application Load (Mbps) (Forward / Backward) A-MPDU Size (B) (Forward / Backward) T1 Local file transfer FTP/TCP transfer of large file within local network FTP file transfer / FTP TCP ACK Full buffer / 0.1 Max / 64 T2 Lightly compressed T3 Internet streaming video/audio T4 4k video streaming T5 Online game server T6 Management: Beacon T7 Management: Probe requests T8 Multicast Video Streaming UDP/IP transfer of compressed video streaming UDP packet transfer/Nothing T8 Gaming T9 VoIP Reference traffic profile for Scenario 4 Traffic Model # Traffic model name Description Application traffic (Forward / Backward) Application Load (Mbps) A-MPDU Size (B)
Figure 1 - Residential building layout Parameter Value Environment description Multi-floor building 5 floors, 3 m height in each floor 2x10 apartments in each floor Apartment size:10m x 10m x 3m APs location In each apartment, AP in random xy-locations (uniform distribution) at z = 1.5 m above the floor level of the apartment. AP Type M APs in the building AP_1 to AP_M1: HEW to AP_M: non-HEW M = Number of Apartments = 100 M1 = [100] Non-HEW = 11b/g/n in 2.4GHz Non-HEW = 11ac in 5GHz STAs location In each apartment, STAs in
Management It is allowed to assume that all APs belong to the same management entity Traffic (per each BSS) - TBD # Source/Sink Name Traffic definition Flow specific parameters AC Downlink D1 AP/STA1 to AP/STA10 Highly compressed video (streaming) T2 D2 to AP/STA20 Web browsing T4 D3 AP/STA21 to AP/STA30 Local file transfer T3 D4 AP/STA31 to AP/STA 70 Multicast Streaming T8 Uplink U1 STA1/AP to Highly compressed video (streaming) – UL TCP ACKs… U2 STA11/AP to STA20/AP Web browsing: – UL TCP ACKs… U3 STA21/AP to STA30/AP Local file transfer T3 U4 STA/AP31 to STA/AP 70 - - P2P P1 NONE (see interfering scenarios) Idle / Management M1 AP Beacon TX M2 STA36 to STA TBD Probe Req. TY Interfering Scenario for Scenario 3 This scenario introduces and overlay of unmanaged P2P networks on top of Scenario 3. Parameter Value Topology
IEEE P802.11 Wireless LANs A Convention for naming the SHA family of Hash Functions Date: 2014-10-29 Author(s): Name Affiliation Address Phone email Dan Harkins Networks 1322 Crossman ave, Sunnyvale, CA 94089 United States of America +1 408 227 4500 dharkins at aruba networks dot com CID Comment Proposed Change Resolution 3426 "HMAC-SHA-256" (6 instances) is confusing as 256 is not the output length "HMAC-SHA256" Reject: yes, 256 is the output length. And there is no confusion as the convention is: [HMAC-]SHA-<name>[-n] 3247 "HMAC-SHA1-128" "Truncate128(HMAC SHA1-160" for consistency with other PMKIDs. Also at 1935.35 Revised: incorporate the text changes in 11-14/1357r1 3429 Is it SHA256 or is it Ditto Pick one (or two, if the answers for the hash name on its own and when combined to form a HMAC (e.g. are different, to avoid confusion between the hash name and the output length) Revised: incorporate the text changes in 11-14/1357r1 HMAC-
Result: Y/N/A = 114/40/30 Motion by Robert (Intel) Motion: Move to take the contents of 11-14/1453r2, adding a “6.1 Save” subclause and adopting it as the TG spec framework doc? Moved by Robert Stacy (Intel), Second by Lei Wang (Marvell) Result: Y/N/A = 109/25/15, motion passes. Discussions on the ad hoc group Erceg (Broadcom) presented “TGax Ad Hoc Structure Discussion”, based on the submission 14/1184r2. Summary The document is almost the same as the previous version except for the last slide which contains the motion to approve the proposed structure. The structure is 4 ad hocs and 3 co-chairs for each. Discussions time of the ad hoc discussed. Will have chair election in January. Start time of ad hoc needs to be decided. suggested election in January and start of the ad hoc in March. A member mentioned that he is confused by the names of ad hoc groups and the section titles in the SFD. Motion #1: Move to have the following 4 Ad Hoc Groups in TGax: MAC PHY Multiuser Spatial Reuse Moved by Al Petrick (J. P. and Associates), Seconded by Eldad Perahia (Intel) Discussions Result: Motion accepted by unanimous consent. Motion #2: Move to have 3 co-chairs per Ad Hoc Group in TGax: Moved by Eldad Perahia (Intel), Seconded by Sean Coffey (RealTek) Discussions Why each ad hoc should have the same number of chairs? Suggested the ad hoc group to decide it. Historically 2 or 3 co-chairs worked very well. Need someone to take the minutes, needs someone to take care of the database. Result: Motion accepted unanimously. Recess @ 9:59 AM until PM1 (13:30) today.
P802.11 Wireless LANs TGaq –Pre-association Service Discovery Protocol Date: 2014-03-14 Author(s): Name Company Address Phone email SK Yong Apple 3 Infinte Loop, Cupertino, CA skyong [at] apple.com Chris Hartman Apple Yong Liu Apple Eric Wong Pradboth Varshney Nokia James Yee MediaTek Chao Chun Wang MediaTek Jing-Rong HTC Ryu ETRI Carolyn Heide Ruckus Wireless Santosh Abraham Qualcomm George Cherian Qualcomm Rob Slater Motorola Mobility
P802.11 Wireless LANs TGaq –Pre-association Service Discovery Protocol Date: 2014-03-14 Author(s): Name Company Address Phone SK Yong 3 Infinte Loop, Cupertino, CA skyong [at] Chris Hartman Apple Yong Liu Apple Eric Wong Apple Pradboth Varshney Nokia Yee MediaTek Chao Chun Wang MediaTek Jing-Rong Hsieh HTC Cheol Ryu ETRI Carolyn Ruckus Wireless Santosh Abraham Qualcomm George Cherian Qualcomm Rob Slater Motorola Mobility
Participants At the time this draft trial-use standard was completed, the Task Group TGaq of Working Group 11 had the following membership: Stephen McCann, Chair Yunsong Yang, Vice Chair Participant1 Participant2 Participant3 Participant4 Participant5 Participant6 Participant7 Participant8 Participant9 The following members of the <individual/entity> balloting committee voted on this trial-use standard. Balloters may have voted for approval, disapproval, or abstention. [To be supplied by IEEE] Balloter1 Balloter2 Balloter3 Balloter4 Balloter5 Balloter6 Balloter7 Balloter8 Balloter9 When the IEEE-SA Standards Board approved this trial-use standard on <Date Approved>, it had the following membership: [To be supplied by IEEE] <Name>, <Name>, Vice Chair <Name>, Past Chair <Name>, Secretary SBMember1 SBMember2 SBMember3 SBMember4 SBMember5 SBMember6 SBMember7 SBMember8 SBMember9 *Member Emeritus Also included are the following nonvoting IEEE-SA Standards Board liaisons: <Name>, DOE Representative <Name>, NIST Representative <Name> IEEE Standards Program Manager, Document Development <Name> IEEE Standards Program Manager, Technical Program Development
Power Save Mechanism parameters Mechanism Parameter Definition/Values Pick one value from the suggested set of Simulation Values ** Power save mode (PSM) Beacon Interval (BI) 100 TU 100 TU DTIM Integer in unit of BI { 1, 3 } PSM timeout Length of time before STA goes to sleep { 50, 100, 200 } ms Power save polling (PSP) Beacon Interval 100 TU 100 TU DTIM Integer in unit of BI { 1, 3 } Unscheduled automatic power save delivery Beacon Interval 100 TU 100 TU DTIM Integer in unit of BI { 1, 3 } Max SP Length Indicate the maximum number of buffered MSDUs, A-MSDUs, and MMPDUs that AP may deliver per SP { 2, 4, 6, ∞ } AC Access Category All ACs are both delivery and trigger enabled ** Simulation results presented should clearly indicated what values are used in the generating the simulation results Test 5: Power Save Mechanism Test Goal: This test case is intended to verify the power save mechanisms implemented in MAC system simulator Assumptions: PER = 0 Power save test parameters for PSM and PSP •MSDU length: 1500 with CWmin=15 downlink every 200 ms
•RTS/CTS [ OFF ] •MCS = [ 0 ] •No A-MPDU aggregation •Power model = [ PSM, PSP ] •DTIM = [ 3 ] •PSM timeout = [ 100 ] ms Power save test parameters for U-APSD •MSDU length: [ 120 bytes with CWmin=15 uplink and downlink every 40ms ] •RTS/CTS [ OFF ] •MCS = [ 0 ] •No A-MPDU aggregation •Power model = U-APSD •DTIM = [ 3 ], STA may not receive Beacons for TIM •Max SP Length = [ 4 ] •All ACs are triggered and delivery enabled Output: MAC throughput Pie chart (breakdown) of time spent in each power state during the course of the simulation Pie chart (breakdown) of energy consumed in each power state during the course of the simulation
5009 135.29 Unit for PRAW Periodicity subfield is stated as short beacon interval, but what about the cases where short beacon interval is not in use? Please clarify what unit should be used when short beacon interval is not in use. Revised -TGah editor to make the changes shown in under the heading CID 5009, 5010. 5010 135.38 Unit for PRAW Start Offset subfield is stated as short beacon interval, but what about the cases where short beacon interval is not in use? Please clarify what unit should be used when short beacon interval is not in use. Revised -TGah editor to make the changes in under the heading CID 5009, 5010. 5169 132.45 "In the first RAW Assignment, the Start Time Indication equal to 0 indicates that the RAW starts immediately after the S1G Beacon or the (Short) Probe Response frame that includes the RPS element." The decoding of elements are in MAC software. It is difficult to predict the delay between the end of reception of the Beacon/Probe Response and the decodinf of RPS element. So the STAs may miss the allocated slot for them. Disallow immeidiate RAW after Beacon and Probe Response. Rejected - This feature is still useful. For example, the AP may allocate a non-TIM RAW that does not allow TIM STA to access immediately after the S1G beacon, possibly in a periodic manner. 5170 133.01 Actually in non-TIM RAW, RAW group doesn't include any STAs so that no TIM STAs will access the dedium during the non-TIM RAW. So the indication field name should not be "Same Group Indication". It should be "Group Presense Indication". In different RAW, "group not presense" has different meaning, e.g. same group as previous RAW or no STAs in the RAW. Change the RPS definition per the commment Revised -TGah editor to make the changes shown in under the heading CID 5170, 5171.
5171 133.04 Since in AP PM RAW, "Same Group Indication"actually indicates whether the RAW group include STAs or not, the indication field name should not be "Same Group Indication". It should be "Group Presense Indication". In different RAW, "group not presense" has different meaning, e.g. same group as previous RAW or no STAs in the RAW. Change the RPS definition per the commment Revised -TGah editor to make the changes shown in under the heading CID 5170, 5171. 5172 134.25 "The RAW Start Time subfield indicates the duration, in units of 2 TU, from the end of the S1G Beacon or the(Short) Probe Response frame transmission that includes the RPS element to the start time of the RAW." The time of transmission of Beacon/Probe Response is not predictable until the real transmission. This means that the AP doesn't exactly know the start time and the end time of the RAW until the transmission of the Beacon/Probe response. This makes the implementation of RAW complicated. Change the start time of RAW absolute time pre TSF time. Rejected -The AP only to know the RAW allocation within a beacon interval, and the relative indication of RAW start time with respect to Beacon/Probe Response in current form is sufficient.
The chair also reminded that the attendees to send e-mail to and to record the attendance in the minutes. Chair asked the attendees to state name and affiliation when speaking for the first time in the meeting. Agenda Item #4: Presentation Reza Hedayat (NEWRACOM) presented “Perspectives on Spatial Reuse in 11ax,” based on the submission 14/1580r0. Summary Summarized DSC and Adaptive/Dynamic CCA discussions presented in TGax. Reviewed current CCA rule in the 802.11 standard. Possible enhancement to the current CCA rule presented. Discussions No discussion. Discussions on the e-mail from Graham Smith (DSP Group) Osama introduced the email from Graham. The first part talks about the difference between the “CCA threshold variations” and “dynamic threshold”. The term of “DSC” needs to be used carefully. The second part says that the effect of DSC will be changed depending on the number of the channels and assignment/allocation of those channels. Discussion Needs for scenarios to evaluate the DSC will be needed. Importance of precise modeling of PHY and MAC is discussed, but it was pointed out that there are calibration works going on for this purpose. Agenda Item #5: Reminder: Nomination for Ad Hoc group chairs Current status: MAC PHY Multiuser Spatial Co-chair #1 Eric Wong (Apple) Bo Sun (ZTE) Sigurd Schelstraete (Quantenna) Laurent Cariou (Orange) Co-chair #2 Jianhan Liu (MediaTek) Kiseon Ryu (LG) Guido R. Hiertz (Ericsson) Co-chair #3 Yakun Sun (Marvell) Chair mentioned that election will take place on Tuesday during the January 2015 session. Ad hoc groups start their activities at the March 2015 session. Agenda Item #6: AOB
3692 1525.13 10.1.4.3.3 "perform the basic access procedure defined ... prior to the transmission": as if we didn't know the definition was prior to the transmission. It also is unclear whether this procedure is to be followed just once or each time a Probe Request frame is to be transmitted, and exactly why there may be more than one transmission of a Probe Request frame. Since "prior to the transmission" is not part of the procedure defined in 9.3.4.2, this really is a sentence. Replace "9.3.4.2 (Basic access) prior to the transmission of each of one or more Probe Request frames, each with an SSID indicated in the SSID List and the BSSID from the primitive." with "9.3.4.2 (Basic access). Perform this procedure prior to each transmission of a Probe Request frame. Each of these transmitted Probe Request frames shall contain an SSID that was included in the SSID List parameter and the BSSID from the BSSID parameter of the received primitive. One Probe Request frame shall be transmitted for
3499 1211.28 8.6.22.2 "Multiple elements can appear in this frame." Like what? Anything? This is underconstrained. List what can, and makes sense, to put here; or something Clarify what elements are sensible or expected in this frame. Proposed resolution: Revised Discussion: resolved as part of CID3232
3499 1211.28 8.6.22.2 "Multiple elements can appear in this frame." Like what? Anything? This is underconstrained. List what can, and makes sense, to put here; or something Clarify what elements are sensible or expected in this frame. Proposed resolution: Revised Discussion: resolved as part of CID3232
Appendix G– Candidate Rating Form 1 VCU School of Medicine L – low, no further interest Committee Candidate Pool Rating for Interview M – Hold; H – Interview Position: Date: Factors candidate name knowledge & technical skills solving communication personal effectiveness potential teamwork RANK L/M/H
The Beacon Health Group The Partnership of: Drs McAllister, Plate, Hunt, Frankel, Brock, Brasse, Mrs L Hunt Managing Partner Mrs S Young Correspondence to your usual branch DANBURY MEDICAL CENTRE 52 Maldon Road Danbury Chelmsford Essex CM3 4QL Tel: 221777 Fax: 01245 221779 Dispensary Fax: 01245 222638 MOUNTBATTEN HOUSE SURGERY 1 Montgomery Close Chelmsford Essex CM1 6FF Tel: 01245 467750 Fax: 01245 466192 Practice Code: F81100 Monday, 09 July 2018 Re: Patients aged 11 to 15 with access to Online Services and SMS Text Service If your child is currently registered for SMS messaging or online services via Patient Access that affords you access to one or both of the following services: booking appointments or requesting repeat medications there will be changes to our policy. Due to the new GDPR (General Data Protection Regulation) which came into force on 25th May 2018 this service has to cease for children aged 11 to 15 years of age inclusive. In the eyes of the law a child is a child until they reach their 18th birthday. For the purposes of medical treatment the boundaries are different and in some circumstances a child aged younger than 16 years could access medical services without the knowledge of their parents. In those cases the patient is entitled to retain their confidentiality. It is not for the practice to become embroiled in an ethical argument and so in all cases online access will be withdrawn once the patient reaches their 11th birthday. Text reminders of forthcoming appointments will also cease at that time as it is common for parents/guardians to list their mobile number on their child’s medical record so we have removed them. In some it may be appropriate for parents/guardians to continue to access their child’s medical record, in cases such as those involving learning disabilities or complex repeat medications for example. If you think you might have such a justification to continue to access your child’s record via Patient Access please contact the surgery for a telephone consultation with your child’s usual GP to discuss. In all other cases the patient will be entitled to request access in their own right and to restore text reminders once they reach the age of 16 years. There is additional guidance available online in this subject area, please ask if you need further assistance. Yours sincerely, Samantha Young Managing Partner, Head of Operations The Beacon Health Group
IEEE P802.11 Wireless LANs TGaq – ANQP Service Discovery Elements Alternative Date: 2015-01-13 Author(s): Name Company Address Phone email Stephen McCann BlackBerry Ltd 200 Bath Road, Slough, Berkshire, SL1 3XE, UK +44 1753 667099 Modify the following clause changes: 8.4.2.92 Advertisement Protocol element <Insert the following row (ignoring the header row) in , after the ‘Registered location query protocol (RLQP)’ table entry> Table 8-219 - Advertisement protocol ID definitions Name Value Registered location protocol (RLQR) 4 Reserved -220 {need to correct the in REVmc D3.3} <Insert dashed list item text after Registered location query protocol (RLQP, shown in red below)> — The RLQP supports information retrieval from a RLSS. RLQP is a protocol used by a requesting STA to another STA (i.e., the receiving STA can respond to queries with and without proxying the query to a server in an external network). See (WLAN interworking with external networks procedures) for information on RLQP procedures. —The supports service information retrieval. It is used by a requesting STA to query another STA (i.e., the receiving STA can respond to queries with and without proxying the query to a server in an external network). See 10.25 (WLAN interworking with external networks procedures) for information on procedures.
NAI Realm 263 8.4.4.9 (NAI Realm 3GPP Cellular Network 264 8.4.4.10 (3GPP Cellular Network AP Geospatial Location 265 8.4.4.11 (AP Geospatial Location AP Civic Location 266 8.4.4.12 (AP Civic Location AP Location Public Identifier URI 267 8.4.4.13 (AP Location Public Identifier URI Domain Name 268 8.4.4.14 (Domain Name Emergency Alert Identifier URI 269 8.4.4.15 (Emergency Alert URI TDLS Capability(#13018) 270 8.4.4.17 (TDLS Capability ANQP-element (#13018)) Emergency NAI 271 8.4.4.16 (Emergency NAI Neighbor Report 272 8.4.4.18 (Neighbor Report ANQP- element(11u))
ANQP-element Name ANQP-element (subclause)(Ed) Type AP Non-AP STA STA Query List 8.4.4.1 (Query List (11u)) Q T, R T, R T, R Capabililty List 8.4.4.2 (Capabililty List S T, R T, R T, R Venue Name 8.4.4.3 (Venue Name (11u)) S T R — Emergency Call Number 8.4.4.4 (Emergency Call Number ANQP-element (11u)) S T R — Network Authentication Type 8.4.4.5 (Network Authentication Type S T R — Roaming Consortium 8.4.4.6 (Roaming Consortium S T R — Vendor Specific 8.4.4.7 (Vendor Specific Q, S T, R T, R T, R IP Address Type Availability 8.4.4.8 (IP Address Type Availability ANQP-element (11u)) S T, R T, R T, R NAI Realm 8.4.4.9 (NAI Realm S T R T, R 3GPP Cellular Network 8.4.4.10 (3GPP Cellular Network S T R — AP Geospatial Location 8.4.4.11 (AP Geospatial Location S T R T, R
There is an Editor’s Note mentioning that there is no such thing as “Fine Timing Measurement Request trigger frames”. Actually, these should be “Fine Timing Measurement Request frames” that include a Trigger field. Editorial Instruction: TGmc Editors: Please apply the following changes on line 49, Page 1161: Replace “Fine Timing Measurement Request trigger frames” with “Fine Timing Measurement Request frames”.
corresponding bits of the TSF timer 6232 4 54 T It is not clear exactly what instant in time the PTT refers to, as regards the lsbs of the TSF Specify that the PTT shall always be considered to start at the time where the least significant 10 bits of the TSF are all zero 6778 4 E Fix the FTM figures to follow normal style (no colours, nice fonts, etc.) As it says in the comment 6781 4 E It says "Within the fine timing measurement procedure, a STA, to request the Location Civic a responding STA that advertises Fine Timing Measurement capability" Add "of" before "a responding STA" Comment 6780 6780 4 E "The first Fine Timing Measurement frame in the FTM session is called the initial Fine Timing Measurement frame. [...] This initial Fine Timing Measurement frame shall include the Fine Timing Measurement Parameters element." duplicates stuff just before it. Remove the duplication Discussion: The “stuff just before it” refers to the initial Fine Timing Measurement Request frame, not the initial Fine Timing Measurement frame. Proposed Resolution : Reject. Comment 6790 6790 4 T Does FTM format and bandwidth to FTM_1 when non-ASAP? Clarify
IEEE P802.11 Wireless LANs Further Clarifications to FTM Protocol Date: 2015-05-13 Author: Name Affiliation Address Phone Email Carlos Aldana Qualcomm Corporation Brian Hart Cisco Systems Revision history: v0 : Initial submission for PTSF value to avoid conflict between FTM trigger frame and initial Fine Timing Measurement frame. v1 : Addressing CIDs for SB v2 : Added Brian Hart as co-author. Pertinent Comments : CID Clause Number Type of Comment Proposed Change 5172 4 855 13 T no longer exists. Replace with 5173 4 24 T In ASAP=0 case, how do we ensure that the FTM trigger frame is not transmitted before the successful transmission of FTM_1? We could set a bound to the Partial TSF Timer that is greater or equal to K*Min Delta FTM + TXTIME(FTM_1) + aSIFSTime+ TXTIME(Ack), where K is the maximum number of FTM_1 retransmissions the responding STA will attempt. 5175 4 37 T The "No preference" field in Table 8-247 should only be allowed in the associated state. In the unassociated state, it is hard for the responding STA to know the initiating STA's capability. Fix as in comment and add corresponding language in 10.24.6
"The responding STA sets the ASAP Capable field to to indicate the STA's capability to send a Fine Timing Measurement frame as soon as possible : the STA is capable of capturing timestamps associated with an initial Fine Timing Measurement frame and sending them in the following Fine Timing Measurement frame" 5189 4 39 E We should clarify that an FTM retransmission has a new Sequence Number in MAC header. As in comment 6048 4 10 T the PTSF is a 16bit long field of bits 25:10 of the TSF which defines the start time of the burst instances. Since it is a TU granularity it is not well defines the lower 10bits of the TSF time at the start of the burst instance. Recommendation : define the lower 10bits of the TSF to be set to 0 for burst instances. Define the lower 10bits of the TSF to be set to 0 for burst instances. 6231 4 54 T It is not exactly what instant in time the PTT refers to, if the PTT is "lower" (modulo than the current corresponding bits of the TSF timer Specify that the PTT shall always be considered to be in the future 6232 4 54 T It is not clear exactly what instant in time the PTT refers to, as regards the lsbs of the TSF Specify that the PTT shall always be considered to start at the time where the least significant 10 bits of the TSF are all zero 1
IEEE P802.11 Wireless LANs Further Clarifications to FTM Protocol Date: 2015-05-13 Author: Name Affiliation Address Phone Email Carlos Aldana Qualcomm Corporation Brian Hart Cisco Systems Revision history: v0 : Initial submission for PTSF value to avoid conflict between FTM trigger frame and initial Fine Timing Measurement frame. v1 : Addressing CIDs for SB v2 : Added Brian Hart as co-author. Pertinent Comments : CID Clause Number Type of Comment Proposed Change 5172 4 855 13 T no longer exists. Replace with 5173 4 24 T In ASAP=0 case, how do we ensure that the FTM trigger frame is not transmitted before the successful transmission of FTM_1? We could set a bound to the Partial TSF Timer that is greater or equal to K*Min Delta FTM + TXTIME(FTM_1) + aSIFSTime+ TXTIME(Ack), where K is the maximum number of FTM_1 retransmissions the responding STA will attempt. 5175 4 37 T The "No preference" field in Table 8-247 should only be allowed in the associated state. In the unassociated Fix as in comment and add corresponding language in 10.24.6
following Fine Timing Measurement frame" to "The responding STA sets the ASAP Capable field to to indicate the STA's capability to send a Fine Timing Measurement frame as soon as possible : the STA is capable of capturing timestamps associated with an initial Fine Timing Measurement frame and sending them in the following Fine Timing Measurement frame" 5189 4 39 E We should clarify that an FTM retransmission has a new Sequence Number in MAC header. As in comment 6048 4 10 T the PTSF is a 16bit long field of bits 25:10 of the TSF which defines the start time of the burst instances. Since it is a TU granularity it is not well defines the lower 10bits of the TSF time at the start of the burst instance. Recommendation : define the lower 10bits of the TSF to be set to 0 for burst instances. Define the 10bits of the TSF to be set to 0 for burst instances. 6231 4 54 T It is not exactly what instant in time the PTT refers to, if the PTT is "lower" (modulo than the current corresponding bits of the TSF timer Specify that the PTT shall always be considered to be in the future 6232 4 54 T It is not exactly what instant in time the PTT refers to, as regards the lsbs of the TSF Specify that the PTT shall always be considered to start at the time where the least significant 10 bits of the TSF are all zero 1
Action Item: Author to include specific changes and revise the document Review document 11-15/254 – Solomon TRAININ (Intel) The document was presented to the group Question on page 3 for the diagram –the new text should be in the bubble. Transitions between the substrates Question on normative change on the transitions between substates The figure may need to be redrawn as it seemed to cause some confusion. Review document 11-15/255 – Solomon TRAININ (Intel) The document was presented to the group Question on the duty cycle of the sleep mode – page 2 The existing text does not have a periodicity The existing definition is used for the DMG in this proposal. The Wake-up schedule element is now expected to be applicable to DMG STA Review document 11-15/256 – Solomon TRAININ (Intel) The document was presented to the group Question on the wakeup schedule how to determine how to change the schedule The plan for these presentations is to have more review offline and then bring back updated documents for consideration at the 2015 May Interim. Review document 11-15/410 – Payam TORAB (Broadcom) Presentation of the document to the group Question on the change of to “may” Need to change the two “may” back to “Shall” This is to ensure that the MCS is from the set expected. The plan is to bring the updated presentation back to the May 2015 Interim Question on other presentations that were made, but a motion was not taken in the past A comment on Sponsor ballot should be made, or a request to put on agenda Comment Resolution: Review 11-13/233r55 LB206 for Discussion Tab – 7 comments left CID 4042 Review Comment Previous proposed resolution reviewed – Reject for insufficient detail Request to all the CIDs with the reject for insufficient detail be considered together after all the others. CID 4037, 4038 and 4039 Comments are similar Review comments Review proposed resolution: - Rejected – the text seemed clear Review context of the CIDs in Draft 4 Possible process options – make a motion to either make a change or to accept the proposed resolution and then process the debate.
10. MLME 10.25 WLAN interworking with external networks procedures 10.25.3 Interworking procedures: generic advertisement service (GAS) <insert the following (red) text in the beginning of section 10.25.3.2.1> 10.25.3.2 ANQP procedures 10.25.3.2.1 General(Ed) In this clause, ANQP refers to the Advertisement Protocols indicated by the Advertisement Protocol IDs 0 and 5. <add a new column and new elements in Table 10-16, as shown> Table 10-16 - ANQP usage (11u) BSS IBSS Protocol ID ANQP-element Name ANQP-element (subclause)(Ed) Type AP Non-AP STA STA List 8.4.4.2 (Query List ANQP-element) Q T, R T, R T, R 0 Capability List 8.4.4.3 (Capability List ANQP-element) S T, R T, R T, R 0 Venue Name 8.4.4.4 (Venue Name ANQP-element ) S T R — 0 Emergency Call Number 8.4.4.5 (Emergency Call Number ) S T R — 0 Network Authentication Type 8.4.4.6 (Network Authentication Type ANQP-element) S T R — 0 Roaming Consortium 8.4.4.7 (Roaming Consortium ANQP- element) S T R — 0
PAD3 Service Advertisement element 8.4.2.172 CFaq:TBD Yes □ No □ N/A □ PAD4 Service Hash element 8.4.2.173 CFaq:TBD Yes □ No □ N/A □ PAD5 Supported ULP element 8.4.2.174 CFaq:TBD Yes □ No □ N/A □ PAD6 Unsolicited PAD 10.25.3.4.2 CFaq:TBD Yes □ No □ N/A □ PAD7 Solicited PAD 10.25.3. 4.3 CFaq:TBD Yes □ No □ N/A □ PAD8 Encapsulation PAD 10.25.3. 4.4 CFaq:TBD Yes □ No □ N/A □
Table 8-– Supported ULP Bitmap ULP name ULP Abbreviation Bit DNS Service Discovery, part of Bonjour technology DNS-SD, Bonjour See: IETF, RFC 6763, DNS-Based Service Discovery, February, 2013 0 Service Location Protocol SLP See: IETF, RFC 2609, Service Location Protocol, June, 1999. 1 Simple Service Discovery Protocol (as used in Universal Plug and Play) SSDP, UPnP See: UPnP FORUM, UPnP Device Architecture 1.0, October, 2008. 2 Universal Description Discovery and Integration for web services UDDI See: OASIS, UDDI Version 3.0, October, 2004. 3 Jini for Java objects. JINI See: 4 Bluetooth Service Discovery Protocol SDP See: Bluetooth Special Interest Group, “Bluetooth Specification Version 4.1, Vol. 3: Core System Package, Part B: Service Discovery Protocol Specification,” December, 2013. 5 Salutation Salutation See: The Salutation Consortium, Salutation Architecture Specification Version 2.0c, June, 1999. 6 XMPP Service Discovery XEP-0030 See: XMPP Standard Foundation, XEP-0030: Service Discovery, Version 2.4, June, 2008. 7 Web Services Dynamic Discovery WS-Discovery See: OASIS, Web Service Dynamic Discovery Version 1.1, July, 2009. 8 multicast DHCP MDHCP See: IETF, RFC 2131, Dynamic Host Configuration Protocol, 1997. 9 Internet Storage Name Service iSNS See: IETF, RFC 4171, Internet Storage Name Service, September, 2005. 10 Web Proxy Autodiscovery Protocol WPAD See: See: IETF, Internet-draft, Web Proxy Auto-Discovery Protocol, December, 1999. 11 Dynamic Host Configuration Protocol DHCP See: IETF, RFC 2131, Dynamic Host Configuration Protocol, March, 1997. 12 eXtensible Resource Descriptor Sequence XRDS See: OASIS, Extensible Resource Descriptor (XRD) Version 1.0, November, 2010. 13 e911 (Emergency Service) e911 See: 14 Next Generation 911 (Emergency Service) NG911 See: 15 Location Service Location 16 17 Reserved Vendor-specific 31
PAD2 Service Hint element 8.4.2.171 CFaq:TBD Yes □ No □ N/A □ PAD3 Service Advertisement element 8.4.2.172 CFaq:TBD Yes □ No □ N/A □ PAD4 Service Hash element 8.4.2.173 CFaq:TBD Yes □ No □ N/A □ PAD5 Supported ULP element 8.4.2.174 CFaq:TBD Yes □ No □ N/A □ PAD6 Unsolicited PAD 10.25.3.4.2 CFaq:TBD Yes □ No □ N/A □ PAD7 Solicited PAD 10.25.3. 4.3 CFaq:TBD Yes □ No □ N/A □ PAD8 Encapsulation PAD 10.25.3. 4.4 CFaq:TBD Yes □ No □ N/A □
The variables p, n, m and k are related to each other with the following approximation, formula (1): (1) The optimal value of k, is given by: (2) Substituting k from (2) in (1) and reordering terms, the value of m, rounded to the nearest multiple of 8, is given by: (3) For example, for n=25 services and p=0.01, the size of the Bloom filter m is 240 bits and the required number of hash function is 7.
1.01 Several Regarding CID 3526 from LB203, there are two methods for defining the conformance requirements in the IEEE 802.11 standard. The first is the Protocol Implementation Conformance Statement (PICS) proforma, Annex B of IEEE 802.11-2012. The other is described in section 1.4 "Word Usage" of IEEE 802.11-2012. While there are some entries in the PICS in the TGah draft, there are large gaps where most of the draft has neither any entry in the PICS in Annex B, nor use of any of the conformance terms defined in section 1.4. These are far too numerous to inventory here in a single ballot comment or to file separate comments for each one. "Review the entire document and revise as appropriate to either include each section or feature described in this draft in the Annex B PICS, or else add the appropriate conformance terms as described in section 1.4. would prefer to see both, but I recognize that the logistics for this change are significant, so I'm willing to compromise. there have been instances where this practice has been ignored in past amendments, these gaps continue to cause problems in interpreting those clauses when incompatibilities are encountered. This makes it particularly difficult for implementors or the Wi-Fi Alliance to develop conformance test specifications. It also falls to the TGm to sort out the mess and clean up these poorly specified definitions. So there is a strong desire amongst many members to resolve these issues before a draft is approved in the first place, while TGm works through all of the legacy issues in the existing standard." Reject. All the features with conformance requirements are deemed to have been included in PICS, Annex B, together with the proper usages of normative words “shall”, “may”, and “should” etc. The assignee will be able to take actions should the commenter the feature that should be included in Annex B or there is any mis-usage of “shall”, “may” etc.
The value of the MAX-ACCESS clause for objects with a SYNTAX clause value of Counter32 is either "read-only" or "accessible-for-notify". In general, the SMI and SNMP RFCs seem to use the “ACCESS” (and “MAX-ACCESS” and clause in reference to the type of access provided by the “agent”, and the “agent” is generally the device (or that portion of the device) that provides SNMP access to the MIB.
DESCRIPTION – document 11-09/533 provides guidelines for general MIB attribute definition, including a discussion of the information that should be included. This document provides more specific guidelines specifically for TruthValue attribute patterns listed here. Each usage pattern also includes guidelines for using and referencing the MIB attribute elsewhere in the Standard. For the purposes of this document, the term “feature” applies to any identifiable unique feature of the Standard that be independently present or absent in a particular implementation, or a similar set of behaviors which might be operational as a group, or none of them are. Patterns Static implementation capability (“Pattern A”) A static implementation pattern is for a feature that is an inherent capability of a implementation. As an “inherent” capability, this pattern is for features that are permanently operational in an instantiation of an implementation that supports it – that is, it is not enabled or disabled dynamically during the lifetime of an instance of the implementation. are two forms of this pattern: internal use only, and externally accessible, as described below Internal use only This form of the static implementation pattern is for a feature that is an inherent capability of a given implementation, and which is not expected to be queried by an external entity. The purpose of such an attribute is really only internal to the 802.11 Standard; defining such an attribute makes it clear that the indication of this support is in fact only useful to the internal 802.11 entities, and in effect becomes just a shorthand formalism (and makes for easier searching, etc.) for “devices that implement XXX” for use elsewhere in the Standard. External access provided The intent of this form of the static implementation pattern is for a feature that is an inherent capability of a given implementation, and where it would be useful for this attribute to be queried (for support in the implementation) by an external entity. Such an attribute can be used within the Standard to control protocol or behaviors which are optional dependent on whether the implementation supports the feature, as well as to inform external management systems of support for the feature thus allowing such systems to manage aspects of the feature, or make other dynamic decisions within the management of the overall deployment. Form of definition and use Both forms of this pattern have similar definition, only the setting for MAX-ACCESS differs, and the use in the Standard is also similar. Name: dot11<XXX>Implemented MAX-ACCESS: none - access to external entity not allowed OR MAX-ACCESS: read-only - access to external entity allowed
•No A-MPDU aggregation •DTIM = [ 3 ] •PSM timeout = [ 100 ] ms PSP test: Figure 12 – Example of the frameflow in PSP scenario and non-AP STA Power States. •MSDU length: 1500 with CWmin=15 downlink every 200 ms •RTS/CTS [ OFF ] •AIFS=DIFS=34us •MCS = [ 0 ] •No A-MPDU aggregation •DTIM = [ 3 ] References: [1] 11-14/0980r06, “TGax Simulation Scenarios”, Simone Merlin (Qualcomm)
termionology / used wording is in line with text found in IEEE 802.11 REVmc. Based on this argument, the proposed change was rejected. TGah has added the text (respectively changed the paragraph of the baseline) that was commented on in the previous comment. Hence the comment was valid. The fact that 11mc used unspecific, unclear, or errorneous wording is not a justification for 11ah to repeat the text and claim that changes to this new text, added by 11ah, should be made in 11mc. Hence, the comment was not properbly addressed. - Discussion: the minimal frame format is copied from IEEE 802.11 Revmc draft. The commenter should raise the issue in 11mc. It looks like that awas misleading the meaning of the minimal frame format. TGah editor replaces “For PV1 the minimal frame format” with “”. 6018 The resolution for CID 5454 in document states that the termionology / used wording is in line with text found in IEEE 802.11 REVmc. Based on this argument, the proposed change was rejected. TGah has added the text (respectively changed the paragraph of the baseline) that was commented on in the previous comment. Hence the comment was valid. Accept the proposed change per previous comment Revised- I agree in principle. According to the 802.11 Editorial Style Guide, the use of of <field> field” is deprecated. So the following should not be used: “A STA that received an MPDU with the of the Retry subfield of the Frame Control field equal to 1 shall determine if the MPDU is a duplicate using the duplate cache.” As suggested by the commenter of CID 5454 in change the wording as the following. TGah editor On page 308 line 37 replace "An AP with a value of true for
Proposed resolution: Accept 5119 8.3.1.2 595 61 T Y The sentence "The TA field is the address of the STA transmitting the RTS frame or a bandwidth signaling TA" gives the impression that bandwidth signaling TA is also applicable for other types of STAs, such as DMG STA. The following sentence in the same paragraph does not help, because it makes no mention to other types of STAs. The same situation happens in 8.3.1.5, 8.3.1.8.1, 8.3.1.9.1 The sentence should be rewritten for clarity. Propose "The TA field is the address of the STA transmitting the RTS frame, except that for a VHT STA this field can be used as a bandwidth signaling TA". The other subclauses should also be clarified accordingly. Proposed resolution: Accept 5120 8.7.1 1231 1 T Y The definition of this MPDU Length (14 bits) in this para and next is only applicable to STAs. Insert "When transmitted by a non-DMG STA," at the start of the paragraph. Clarify the same in the next paragraph Proposed resolution: Accept
5122 9.2.7 1243 62 T Y The use of fragmentation in DMG is unnecessary given the larger MSDU sizes. Insert the following paragraph after the first paragraph: "An MSDU transmitted by a DMG STA shall not be fragmented." Proposed resolution: Accept
IEEE P802.11 Wireless LANs Some LB 199 Proposed Comment Resolutions Date: 2014-02-06 Author(s): Name Affiliation Address Phone Dorothy Stanley Aruba Networks 1322 Crossman ave, Sunnyvale, CA +1 408 227 4500 CIDs 2212, 2200 (GEN) 2212 20.06 3.1 "personal control point" also is a misnomer for the directional control point. That name should be "directional control point". Replace "personal" in "personal ... control point" with "directional", so "PCP" is replaced with "DCP" throughout the draft.. 2200 1.61 1.3 "Personal" is a use of a network, not a type of 802.11 network, and certainly is not an alternative to independent and infrastructure networks. On the other hand, the DMG network is a directional network, which is an alternative to independent and infrastructure networks. Replace "personal" here with "directional". Discussion: Discussion in LA (4.8.1.4 and 4.8.2) on similar comment 2210 resulted in REJECTED: Personal is a descriptive term that reflects the anticipated use cases. Proposed Resolution: Rejected Personal is a descriptive term that reflects the anticipated use cases. CID 2204