zilongwang/ReadingBank huggingface dataset:
DCF PCF Fragmentation Defragmentation Multirate support MSDU transmission restrictions HT Control operation Control Wrapper operation A-MSDU operation A-MPDU operation PPDU duration constraint DMG A-PPDU operation LDPC operation STBC operation Short GI operation Greenfield operation Group ID and partial AID in VHT PPDUs Operation across regulatory domains HCF Mesh coordination function (MCF) acknowledgement (block ack)
Throughput (HT) PHY specification multi-gigabit (DMG) PHY specification High Throughput IVHT) PHY Annex A, Bibliography Annex B, Protocol Implementation Conformance Statement (PICS) Need to do something about the PICS. Annex C, ASN.1 encoding of the MAC and PHY MIB Probably need to add more for “port” VLAN configuration. Add the following entry at the end of the dot11StationConfigEntry SEQUENCE: dot11GeneralLink TruthValue … P, Integration Function Note: More extensive changes in Annex P may be required. P.1 Introduction Replace the contents of P.1 with the following: The purpose of this is to guide the implementer of a non-GLK WLAN system that includes a portal that integrates the WLAN systems with a wired LAN. This annex does not apply to GLK WLAN systems. P.2 Ethernet V2.0/IEEE Std 802.3 LAN integration function P.3 Example Change the second paragraph as follows: In the tables below the rows that have a 81-00 Type/Length field value represent bridging between an Ethernet/IEEE Std 802.3 LAN and an IEEE Std 802.11 LAN. Both LANs are
Box 5 Box 5 should calibrate the system level performance in the scenario calibrated in box 1 and box 2 based on the MAC and PHY features listed in the following table based on the results of box 3 and box 4. 3: MAC and PHY features Feature MAC CCA Control frame, e.g. RTS/CTS/ACK/Block ACK EDCA Aggregation (A-MPDU in 11ac) Link Adaption PHY Beamforming MIMO with MMSE receiver PHY abstraction Test 1: full buffer traffic model assumption Test 2: real traffic model and traffic mix assumption defined in evaluation methodology and simulation scenario document. The output metrics are CDF of : Per-STA throughput Per-BSS Throughput Packet Loss Transmission Latency Traffic Models Full buffer model is baseline – users always have DATA to send and receive. A more realistic FTP traffic model may be used based on [15]. Specific parameters are TBD. A mix of small and large packets should be evaluated in order to test realistic assumptions on system performance. Traffic models for Video are described in Appendix 2. Management traffic model Management traffic for unassociated clients:
Figure 5: Traffic layering model Video traffic generation The video traffic from AP to STA is generated as follows. Step 1: At application layer, generate video frame size (bytes) according to Weibull distribution with the following PDF. Depending on the video bit rate, the parameters to use are specified in Table 5. Table 5: Lambda and k parameter for video bit rate Video bit rate lambda k 15.6 Mpbs 54210 0.8099 10Mbps 34750 0.8099 8Mbps 27800 0.8099 6Mbps 0.8099 4Mbps 13900 0.8099 2Mbps 6950 0.8099 Step 2: AT TCP set TCP segment as 1500 bytes and fragment video packet into TCP segments. Step 3: Add network latency to TCP/IP packets when these segments arrive at AP for transmission. The network latency is generated according to Gamma distribution whose PDF is shown below Where k=0.2463 theta=55.928 The mean of the latency with the above parameters is 14.834ms. To simulate longer or shorter network latency, scale theta linearly since mean of Gamma distribution is K*theta
DL UL DL UL Initial packet arrival (ms) Uniform Uniform a=0, b=20 a=0, b=20 Packet arrival time (ms) Exponential Exponential Packet size (Byte) Bimodal Normal Normal Evaluation metrics MAC throughput Latency VoIP Traffic Model VoIP service uses the internet protocols to delivery real-time voice packets across networks. The VoIP traffic comprises periods of active talking and silence, as shown in Figure 1. It can be considered as a simple 2-state noice activity Markov model as shown in Figure 2. Figure 1: VoIP traffic profile Figure 2: Two-state voice activeity model For VoIP traffic, the VoIP user will always be in either the silence state (State 0) or active talking state (State 1), assuming that the probability of transitioning from state 0 to state 1 is a, and the reciprocal transition from state 1 to state 0 is b. Hence, the probability of staying in state 0 is 1-a and in state 1 is 1-b. The state update is assumed to be done at the speech encoder frame rate R=1/T, where T is the encoder frame duration whose typical value is 20ms for active talking state and 160ms for silence state, respectively. VoIP packets are generated at time intervals iT+τ, where τ is the network packet arrival delay jitter, and i is the encoder frame index. During the active state, voice packets with fixed size are generated at these time intervals, while the model is updated at regular frame intervals [1]. The detailed parameters of the VoIP traffic model are specified in Table 1. The rate of voice source assumes 12.2 kbps with a 50% voice activity factor. The payload size of active talking state and silence state are 33 byte and 7
JO. Rose, “ Statistical properties of MPEG video traffic and their impact on traffic modeling in ATM systems ”, Tech report, Institute of CS in University of Wurzburg Savery Tanwir., “A survey of VBR traffic models”, IEEE communication surveys and tutorials, Jan 2013 Aggelos Lazaris et al., “A new model for video traffic originating from multiplexed MPEG-4 videoconferencing streams”, International journal on performance evaluation, 2007 A. Golaup et al., “Modeling of MPEG4 traffic at GOP level using autoregressive process”, IEEE VTC, 2002 K. Park et al., “Self-Similar network traffic and performance evaluation”, John Wiley&Son, 2000 M Dai et al., “A unified traffic model for MPEG-4 and H.264 video traces”, IEEE Trans. on multimedia, issue 5 2009. L Rezo-Domninggues et al., “Jitter in IP network: A cauchy approach”, IEEE Comm. Letter, Feb 2010 Hongli Zhang et al., “Modeling Internet link delay based on measurement”, International conference on electronic computer technology, 2009. IEEE 802.16m-08/004r5, IEEE 802.16m Evaluation Methodology Document (EMD) Yingpei Lin et al., 11-13-1133-00-0hew-virtual-desktop-infrastructure-vdi Yingpei Lin et al., Yingpei Lin et al., 11-14-0056-01-0hew-traffic-model-on-virtual-desktop-infrastructure Yingpei Lin et al.,
11-13-1334-05-video traffic modeling 11-13-1335-04- video-traffic-modeling-word with details 11-13-1162-01-hew-vide-categories-and-characteristics 11-09-0296-16-00ad-evaluation-methodology.doc Rongduo Liu et al., “An Emperical Traffic Model of M2M Mobile Streaming Services ”, International conference C on Multimedia information networking and security, 2012 JO. Rose, “ Statistical properties of MPEG video traffic and their impact on traffic modeling in ATM systems ”, Tech report, Institute of CS in University of Wurzburg Savery Tanwir., “A survey of VBR traffic models”, IEEE communication surveys and tutorials, Jan 2013 Aggelos Lazaris et al., “A new model for video traffic originating from multiplexed MPEG-4 videoconferencing streams”, International journal on performance evaluation, 2007 A. Golaup et al., “Modeling of MPEG4 traffic at GOP level using autoregressive process”, IEEE VTC, 2002 K. Park et al., “Self-Similar network traffic and performance evaluation”, John Wiley&Son, 2000 M Dai et al., “A unified traffic for MPEG-4 and H.264 video traces”, IEEE Trans. on multimedia, issue 5 2009. L Rezo-Domninggues et al., “Jitter in IP network: A cauchy approach”, IEEE Comm. Letter, Feb 2010 Hongli Zhang et al., “Modeling Internet link delay based on measurement”, International conference on electronic computer technology, 2009. IEEE 802.16m-08/004r5, IEEE 802.16m Evaluation Methodology Document (EMD) Yingpei Lin et al., 11-13-1133-00-0hew-virtual-desktop-infrastructure-vdi Yingpei Lin et al., Yingpei Lin et al., 11-14-0056-01-0hew-traffic-model-on-virtual-desktop-infrastructure Yingpei Lin et al.,
MC1 10425 0.8099 MC2 6Mbps 0.8099 Evaluation metrics MAC throughput, latency Gaming Traffic Model First Person Shooter (FPS) is a typical representative game of Massively Multiplayer Online (MMO) game. The FPS traffic model is considered to be a typical gaming traffic model, as it has additional requirements on, for instance, real time delay with irregular traffic arrivals. Gaming is asymmetric, bi-directional single-hop video traffic. Gaming traffic can be modelled by the Largest Extreme distribution. The starting time of a network gaming mobile is uniformly distributed between 0 and 40 ms to simulate the random timing relationship between client traffic packet arrival and reverse link frame boundary. The parameters of initial packet arrival time, the packet inter arrival time, and the packet sizes are illustrated in the Table 6 [13]: Table 6: Parameters for gaming traffic model Component Distribution Parameters PDF DL UL DL UL Initial packet arrival (ms) Uniform Uniform a=0, b=40 a=0, b=40 Packet arrival time (ms) Largest Extreme Value Largest Extreme Value a=50, b=4.5 a=40, b=6 Packet size (Byte) Largest Extreme Largest Extreme a=330, b=82 a=45, b=5.7 * A compressed UDP header of 2 bytes and a IPv4 header of 20 bytes (if use IPv6 here, the header should be 40bytes) has been accounted for in the packet size. Traffic Model Class Identifier for Gaming is GMG Evaluation metrics
Note, this model results in PSD(infinity) = {-130 dBc/Hz} Note, this impairment is modeled at both transmitter and receiver. IM4 Noise figure Input referred total noise figure from antenna to output of the A/D will be {10dB}. Unchanged from 802.11ac IM5 Antenna The TGn antenna configuration at both ends of the radio link shall be a uniform linear array of isotropic antennas with separation of one-half wavelength, with an antenna coupling coefficient of zero. The TGac antennas can be assumed to either be all vertically polarized or a mix of vertical and horizontal polarizations or dual polarization at ±45 degree, as specified in the TGac channel model addendum document. In TGax, an outdoor channel model is added. The outdoor channel models for AP to STA, STAs to AP, and STA to STA are implemented by choosing different height of antennas [26]. Mix of vertically and horizontally polarized antennas or dual polarization at ±45 degree is also considered for TGax devices. Added information from TGax channel model document on antennas for outdoor channel IM6 Light Effects The fluoroscent light effects specifed in the TGac Channel model shall not be considered for the simulation scenarios. Unchanged from 802.11ac UM7 Timing Uplink Multi-user simulations shall be run using a fixed timing offset selected from the array [N(1) ,N(2),……,N(16) ], where N(j) corresponds to the time offset of the j-th client transmission with respect to a common time reference and is randomly chosen from {[-TBD,TBD] ns} with a uniform distribution Updated for 11ax Comparison criteria PER vs. SNR curves all MCS’s Simulate all of channel models Simulation may include: updated PHY impairments timing acquisition on a per-packet basis
1141 114.01 8.4.2.170q "is one octet in length" - redundant Remove redundant size specifiers from the text in this subclause. Rejected- There are many instances such as ”1 octet in length” in baseline draft too. 1142 114.44 8.4.2.170q I don't see any text on how the "DL Max Data Rate field" is used. Is it a commitment by the AP, or a constraint on the non-AP STA? Add behaviour in clause 9/10 that indicates how the values in this field affect AP and non-AP STA behaviour. Ditto for the other data rate fields of this structure. Revised- Add a behavior description in Relay Discovery Procedure (subclause 9.48.5). TGah editor to make changes shown in 0576r1 under the heading for CID 1139 to 1435 1143 114.58 8.4.2.170q "with value "100" indicating 100% busy level and value "0" indicating idle (value "101" to "255" are reserved)." Typo. Also the double quotes are not needed when indicating values. Change to: 'with value 100 indicating 100% busy level and value 0 indicating idle (values 101 to 255 are reserved).' Accepted- TGah editor to make changes shown in 0576r1 under the heading for CID 1139 to 1435. 1435 113.39 8.4.2.170q There is not any cumulative metric defined for Relay Discovery Procedure, that can be used directly at the STA side Add a cumulative metric to the element Revised- Add a behavior description at STA side about how to choose a Relay among multiples candidates in Relay Discovery Procedure (subclause 9.48.5) TGah editor to make changes shown in 0576r1 under the heading for CIDs 1139 to 1435. CIDs 1139,1140,1141,1142,1143,1435 8.4.2.170q Relay Discovery element TGah editor: Change the figure 8-401dr ( page130 Line 32) by reducing the table cell margin to zero, and choosing a smaller font.
Revisions Revisions of document 13/1001 Revision Comments Date R0 Initial draft template Aug 28th R1 Sept 15th 2013 R2 Made it consistent with document 1000r2 Sept 16th 2013 R3 Included Scenario 1 from 1081r0 Included Scenario 2 from 722r2 Included Scenario 3 and 4 from 1248r0; scenario 3 likely compatible with documents 722 and 1079. Included concept from 1176r0 Added References Updated co-authors Oct 4th 2013 R4 Minor corrections Oct 4th 2013 R5 Added description for scenario 4a (Simone (Qualcomm), Ron (Broadcom)) Tentative addition of contributions related to traffic models; more discussion is needed: Added video traffic models from #1335 (Guoqing Li, Intel) for traffic models (Bill, Sony) Management Traffic profile and % of unassociated users (Reza, Cisco) Application activity intervals (Huai-Rong, Samsung) Indicated that legacy STAs can be present (Various) Indicated that legacy APs can be present in scenario 1(Liwen, Marvell) Indication of antenna height (Wookbong, LG) RTS Thresholds (Liwen, Marvell) Primary channel location (Liwen (Marvell), Klaus (Nokia)) Clarified that all BSSs are either all at 2.4GHz, or all at 5GHz (Liwen, Marvell) Nov 14th 2013
Downlink D1 AP/STA1 to Highly compressed video (streaming) T2 D2 AP/STA11 to AP/STA20 Web browsing T4 D3 AP/STA21 to AP/STA25 Local file transfer T3 … … DN AP/STAN Uplink U1 AP/STA1 to AP/STA10 Highly compressed video (streaming) – UL TCP ACKs… U2 to AP/STA20 Web browsing: – UL TCP ACKs… U3 to STA30/AP Local file transfer T3 … … UN STAN/AP P2P P1 STA1/AP P2 STA2/AP P3 STA3/AP … … PN STAN/AP Idle Management M1 AP1 Beacon TX M2 STA2 Probe Req. TY M3 STA3 … … MN STAN 4a- Outdoor Large BSS + Residential Scenario Parameter Value Topology (A) Figure 10 –Layout of large BSSs with residential buildings Environment description This scenario consists of an overlay of the following
Access protocol parameters Primary channels Aggregation Max # of retries RTS/CTS Threshold Association Traffic model Traffic (Per each apartment) - TBD # Source/Sink Name Traffic definition Flow specific parameters AC Downlink D1 AP/STA1 4k Video T1 VI D2 AP/STA2 Local file transfer T3 BE D3 AP/STA3 … … … DN AP/STAN Uplink U1 STA1/AP U2 STA2/AP U3 STA3/AP … … UN STAN/AP P2P P1 STA1/AP P2 STA2/AP P3 STA3/AP … … PN STAN/AP Idle Management M1 AP1 Beacon TX M2 STA2 Req. TY M3 STA3 … … MN STAN References May 2013 11-13/486, “Evaluation methodology and simulation scenarios” Ron Porat (Broadcom) 11-13/520r1, HEW Scenarios and Evaluation Metrics, Thomas Derham (Orange) 11-13/538 “Dense apartment building use case for HEW” , Klaus Doppler (Nokia)
IEEE P802.11 Wireless LANs LB200 TGah D1.0 MAC Comment Resolutions on Sectorization Part 1 Date: 2014-05-07 Author(s): Name Affiliation Address Phone Email Jae Seung Lee ETRI 161 Gajeong-dong, Yuseong-gu, Daejeon, +82 42 860 1326 Wang MediaTek George Calcev Huawei Young Hoon Kwon Huawei This document provides resolutions for MAC CIDs on Sectorization (Part 1). CID 1070, 1734, 2765, 2922, 2923, 2494 CID Page Clause Assignee Comment Proposed Change Resolution 1070 Adrian Stephens 9.47.5.1 Jae Seung, James, "The sector training is one way to help" - grammar "Sector training is one way to help" Review all 23 instances of "the sector training" and replace with "sector training" where the phrase is expressing the concept of sector training. REVISED. to doc. 14/0638. 1734 David Hunter 9.47.5.2 Jae Seung, James, "In the case that" is a complicated way of saying "when". Replace "In the case that" with "When". REVISED. to doc. 14/0638. 2
Activation Mode subfield CID P.L Clause Comment Proposed Change Resolution 1430 112.43 a network may have a limit on the number of supporting Relays Add a field to Relay Element "No More Relay is allowed" and when it sets by a STA, there cannot be any more Relay enabled or associated to that STA. Revised: TGah editor to make changes shown in 1431 113.18 use of Reachable Address is not efficient enough, time a STA leaves or join the network, all the Addresses should be sent to the parent node. Add a "Add/Remove" field to the Reachable Address frame Revised: TGah editor to make changes shown in 1432 113.18 Initiated Recahable Address MAC address may be required to be added in the Reachable Address frame for some of the features to work fine Add the "initiator MAC Address" field to the Reachable Address Frame Revised: TGah editor to make changes shown in 1433 113.18 A root AP may want to know what are the STAs operating as a Relay in the network. Add a "Relay Indicator" bit for each MAC address in the Reachable Address frame to indicate if that STA is a Relay Capable STA Revised: TGah editor to make changes shown in 1434 113.18 Reachable Address included in Probe Resuest and (RE)Association Request Enable the Reachable Address IE to be included in Probe or (RE)Association Request Accept: TGah editor to include the Reachable Address in Probe Request and (Re)Association Request as indicated in the CID 1434
Figure : Relay Activation element format The Relay Activation Mode subfield is set to 1 to indicate that this element is a Relay Activation Request. The Relay Activation Mode subfield is set to 0 to indicate the Relay Activation Response. The Direction subfield is set to 1 if the Relay Activation element is sent by the AP. The Direction subfield is set to 0 if the Relay Activation is sent by the STA. The Enable Relay Function subfield is set to a value based Direction and Relay Activation Subfield as described in . Table : Enable Relay Function subfield values Relay Activation Mode=1 (Request) Relay Activation Mode=0 (Response) Direction =1 (from AP) If the Enable Function subfield is set to 1, it indicates that the STA can operate as a Relay and if it is set to 0 it indicates AP demands the STA to terminate the Relay function. If the Enable Relay Function subfield is set to 1, it indicates that the STA is allowed to operate as a Relay and if it is set to 0, it indicates the STA cannot operate as a Relay. Direction =0 (from STA) If the Enable Relay Function subfield is set to 1, it indicates that the STA desires to activate its Relay function and if it is set to 0, it indicates that the STA desires to terminate its Relay function. If the Enable Relay Function subfield is set to 1, it indicates that the STA activates its Relay function and if it is set to 0, it indicates that the STA terminates its Relay function. Bits 3-7 of the Relay Activation element are reserved. TGah Editor to add the following as a new row to the Tabel 8-55 (Element IDs): Relay Activation <ANA> 3 Yes TGah editor to add the following row to the Tables 8-29 to 8-34
Straw Poll #1: Do you agree that TGax should support a mode of uplink multi-user transmission? Result: Y/N/A = 36/0/62 Straw Poll #2: Do you agree that any proposal for uplink multi-user transmission protocol for TGax should be a distributed type of protocol? Result: 0/4/83 Recessed at 21:13 AM2 (10:30) tomorrow. Tuesday, May 13th 2014, AM2 Session (10:30-12:30) The meeting called to order by Osama Aboul-Magd (Huawei Technologies), the chairperson of TGax, @10:30 Agenda 11-14/0478r2 is on the server. Rev 3 is working document. There were 180 people in the room at the beginning of the session. More people came in later. Chair reminded that this meeting is operated under the IEEE 802 and IEEE 802.11 P&P. Chair asked people to address himself/herself when speaking for the first time. We have about 30 presentations to hear. The chair asked each presentation to be done in 20 minutes including Q&A. Agenda for this session Tuesday AM2 Call Meeting to order Reminder IEEE 802 and 802.11 IPR Policy and procedure. Attendance. TG Issues – start discussions on following items. Timeline (11-14/649, 11-14/617, Minho) – PM2 TG Documents TG Structure Presentations Recess asked if there are any objections to proceed with this agenda – no objections. agenda approved. TG Issues TG Document – on slide 27 of the agenda file Scenarios (11-14/0621r0) Methodology (11-14/0571r0) Models Requirements Framework (down the road) Channel Model document: Should we have the channel separated from simulation scenarios? The preference of the group is to have a separate documents of channel model. Jianhan will coordinate the channel model document.
Primary Channel Integer 0 - 255 The Primary Channel of the advertised BSS. The Primary Channel is only defined within the indicated Operating Class as shown in Annex E. [CID4633] Do not adopt 6.3.3.3.3 When generated Change as follows: This primitive is generated by the MLME as a result of an MLME-SCAN.request primitive or if dot11FILSActivated is true, by an MLME-SCAN-STOP.request primitive following an MLMESCAN.request primitive to ascertain the operating environment of the STA. If dot11FILSActivated is true, the primitive is invoked to provide a [CID4111] BSS report that matches the setting in the MLMESCAN.request's ReportingOption parameter. 6.3.3.3.4 Effect of receipt Change as follows: The SME is notified of the results of the scan procedure. If dot11FILSActivated is true, these results might may [CID4112] be intermediate results, according to the value of the ResultCode. 6.3.3.4.3 When generated Change as follows: This primitive is generated by the SME in order to stop as means of stopping [CID4113] all ongoing active or passive scan processes in the STA. 6.3.11.2.2 Semantics of the service primitive Instructions to the editor: Add the Known OUIs as shown. [CID5194] The primitive parameters are as follows: … Mesh Configuration, Known OUIs, [CID5194] VendorSpecificInfo … Instructions to the editor: Add the Known OUIs as shown. Name Type Valid range Description ... ... ... ... Known OUIs A set of elements As defined Zero or more elements
in 8.4.2.28 that Specify the OUIs and values known by the AP. [CID5194] VendorSpecificInfo A set of elements As defined in 8.4.2.28 Zero or more elements. 8.3.3.9 Probe Request frame format Instructions to the editor: Modify as shown. Order Information 2019CID4694 AP-CSN The AP-CSN element is optionally present if dot11FILSActivated is true. 8.3.3.10 Probe Response frame format Instructions to the editor: Modify as Order Information Notes Last–n Requested elements Elements requested by the Request element (8.4.2.10) CID4982 of the Probe Request frame are present if dot11MultiDomainCapabilityActivated is true. See 10.1.4.3.4 (Sending a response to probe request). See 10.1.4.3.2 (Active scanning procedure for a non-DMG STA). Added erroneously by mc3.0. 8.4.2.1 General Instructions to the editor: Modify as shown. CID4539: Delete all “see” words from Element column, (the column needs to have just the element reference). The deletion is shown for the below listed elements. CID4002: Delete the length column. Table 8-61— Element IDs Element Element ID Length of indicated element (in octets) CID4002 Extensible FILS Request Parameters (see CID4539 8.4.2.174 (FILS Request Parameters element)) <ANA> 3 to 11 FILS Indication (see CID4539 8.4.2.179 (FILS Indication element)) <ANA> 3 to 257 Differentiated Initial Link <ANA> 6 to 257
For a TVHT STA, the field is structured into subfields as defined in Figure 8-553a. For a TVHT STA, set the TVHT_MODE_2C Support subfield to 1 if it supports TVHT_MODE_2C; otherwise set the subfield to 0. For a TVHT STA, set the TVHT_MODE_2N Support subfield to 1 if it supports TVHT_MODE_2N; otherwise set the subfield to 0. TGmc editor: modify Figure 8-556 Supported VHT-MCS and NSS Set field within subclause 8.4.2.157.3 Supported VHT-MCS and NSS Set field and some of the text in the subclause, as shown: 8.4.2.157.3 Supported VHT-MCS and NSS Set field B0 B15 B16 B28 B B32 B47 B48 B60 B6 Rx Map Rx Highest Long GI Data Rate 80+80 Half NSS Tx Map Tx Highest Long GI Data Rate 160 Half NSS Bits: 16 13 1 3 16 13 1 3 The Supported VHT-MCS and NSS Set subfields are defined in 8-241 (Supported VHT-MCS and NSS Set subfields). 8-241—Supported VHT-MCS and NSS Set subfields Subfield Definition Encoding Rx VHT-MCS Map Indicates the maximum value of the RXVECTOR parameter MCS of a PPDU that can be received at all channel widths supported by this STA for each number of spatial streams. The format and encoding of this subfield are defined in Figure 8-556 (Rx VHT-MCS Map and Tx VHT-MCS Map subfields and Basic VHT-MCS and NSS Set field(11ac)) and the associated description. Tx VHT-MCS Map Indicates the maximum value of the TXVECTOR parameter MCS of a PPDU that can be transmitted at all channel widths supported by this STA for each number of spatial streams. The format and encoding of this subfield are defined in Figure 8-556 (Rx VHT-MCS Map and Tx VHT-MCS Map subfields and Basic VHT-MCS and NSS Set field(11ac)) and the associated description. Support
STATUS current DESCRIPTION "This is a capability variable. Its value is determined by device capabilities. This attribute, when true, indicates that the IEEE 802.11 VHT Half Max NSS Signaling option is implemented." DEFVAL { } ::= { dot11StationConfigEntry <ANA> } References:
Probe Request frame format Add to Table 8-41 – Probe Request frame body as the next to last row: 18 GLK Capabilities The GLK Capabilities element is present if dot11GeneralLinkImplemented is true. Probe Response frame format Add to Table 8-42 – Probe Response frame body as the third to last row: 68 GLK Capabilities The GLK Capabilities element is present if dot11GeneralLinkImplemented is true. frames DMG Beacon Add to Table 8-49 – DMG Beascon frame body as the third to last row: 15 GLK Capabilities The GLK Capabilities element is present if dot11GeneralLinkImplemented is true. Management and Extension frame body components that are not elements Authentication Algorithm Number Authentication Transaction Sequence Number field Beacon Interval field Capability Information field Change Figure 8-65—Capability Information field (non-DMG STA) and Figure Information field (DMG STA) as follows:
Language used for consistency – The MDR report indicates that there is something that not consistent. P2876 L13-14 -- R3: a new proposal for consideration, incorporate the change proposed and remove the text... P3236 L45 – question on the quote that is embedded in the MIB. Discuss the proposal - “A road section identifier might be needed to make an address unique” (this may be a bit different) the text for track changes Review Doc 11-14/922r0 – Dorothy STANLEY (Aruba Networks) CID 3072 (MAC) Review Comment Proposed Resolution: Revised At 721.09 and 721.15, change from “10.8.3” to “10.8.4”. No objection – mark ready for motion CID 3093 (MAC) Review Comment Discussion on the value of “order” Proposed Resolution: Accept No objection – mark ready for motion CID 3096 (GEN) Review comment Proposed resolution: Revised Change from “may use” to “uses” No Objection – mark ready for motion Want to revisit CID 3093 (MAC) The Subelement ID is similar to the Order column, so is this also something that is being used or not Table 8-177 So insert at P892 L11 the “The optional sub-elements are ordered by nondecreasing subelement ID.” Change Proposed Resolution: Revised. Remove the Order column in Table 8-177 and insert the following at 892.11: “The optional are ordered by nondecreasing subelement ID.” More discussion – this would be clearer as the order of the subelement ID. Not unanimous in the discussion Would like to not change the Proposed Resolution as originally proposed. StrawPoll – Which choice would you prefer? Accept - 5 Jounie’s Suggestion (new Resolution) – 2 19 in the room Decision: Leave it as just Accept Mark Ready for Motion CID 3085 (MAC) Review comment Proposed Resolution: Accept No objection – mark ready for motion CID 3059 (GEN) Review comment Proposed Resolution: Accept No objection – mark ready for motion CID 3312 (GEN) Review Comment Proposed Resolution: Accept
5 80MHz channel, with random selection of primary channel per operating channel Aggregation [A-MPDU / 64 MPDU aggregation size / BA window size, No A-MSDU, with immediate BA] Max # of retries Max retries: 10 RTS/CTS Threshold [No RTS/CTS] Association X% of STAs in an apartment are associated to the AP in the apartment; 100-X% of the STAs are not associated [X=100] Management Each AP is independently managed Traffic model For Calibration: Use full buffer traffic Downlink only or Uplink only BE class For performance tests: Traffic model (Per each apartment) - TBD # Source/Sink Name Traffic definition Flow specific parameters AC Downlink D1 AP/STA1 Buffered video streaming 200Mbps/N (4k video 20Mbps for N=10); VI … VI
3224 Qi Wang 1803.64 10.33.2.2 Optional notification is also applicable to FST across channels in the same band. Also a few editorials ("initiator or responder", redundant "as", ...) Before leaving the Setup Completion state, the initiator andor responder that is performing a full FST session transfer may transmit an FST Setup Response frame in the old band/channel with athe Status Code field set to PERFORMING_FST_NOW and with the RA field set to the broadcast address as to notify other STAs in the BSS of thisthe STA's forthcoming full FST session transfer. Revised. Replace “Before leaving the Setup Completion state, the initiator and responder that is performing a full FST session transfer may transmit an FST Setup Response frame in the old band with a Status Code field set to and with the RA field set to the broadcast address as to notify other STAs in the BSS of this STA’s forthcoming full FST session transfer.” With “Before leaving the Setup Completion state, the initiator and/or responder that is performing a full FST session transfer may transmit an FST Setup Response frame in the old band/channel with the Status Code field set to and with the RA field set to the broadcast address as to notify other STAs in the BSS of the STA's forthcoming full FST session transfer.” 3225 Qi Wang 1805.02 10.33.2.2 STT should be set at transmission of individually addressed MPDUs, MMPDUs or use language similar to the one in three paragraphs below in clause c). Change "... at transmission of any individually addressed MPDU to responder..." to either "... at transmission of any individually addressed MPDU, MMPDU or A-MPDU to the responder..." or more preferably, to "... at transmission of any individually addressed PPDU ..." (or whatever standard term the group has settled on; I think it was PPDU) Revised. Change "... at transmission of any individually addressed MPDU to responder..." to either "... at transmission of any individually addressed MPDU, MMPDU or A-MPDU to the responder..."
3296 Matthew Fischer The universally complete set of architectures of 80+80 receivers does not imply support for 160 MHz operation as is already suggeted by the current definitions of the values for 1 and 2. I.e. support for 160 does not imply support for 80+80 and similarly, support for 80+80 does not imply support for 160. I.e. the case for 80+80 only support is missing. Same comment for TVHT (see 8.4.2.170) Change "The of 3 is reserved" to "Set to 3 if the STA supports 80+80 MHz mode and not 160 MHz" Change "Set to 1 if the STA supports 160 MHz" to "Set to 1 if the STA supports 160 MHz and not 80+80 MHz" - similar request for change to TVHT equivalent structures. Revise - generally agree with commenter, TGmc editor to execute proposed changes from found under all headings which include CID3296 Discussion: Description of BW support is not Proposed changes CID 3296 8.3.1.2 RTS frame format
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 video 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 streaming UDP packet transfer/Nothing T8 Gaming Reference traffic profile for Scenario 4 Traffic # Traffic model name Description Application traffic (Forward / Backward) Application Load (Mbps) (Forward / Backward) A-MPDU Size (B) (Forward / Backward) T1 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 T4 4k video streaming T5 Online game server T6 Management: Beacon T7 Management: Probe requests References for traffic models 11-13/486, “HEW video traffic modeling” Guoqing Li et al, (Intel) [1] [2] 11-13-1059-01-hew-video-performance-requirements-and-simulation-parameters [3]11-09-0296-16-00ad-evaluation-methodology.doc
Annex 1 - Reference traffic profiles per scenario Reference traffic profile for Scenario 1 Traffic Model # Traffic 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 video T3 Internet streaming video/audio T4 4k video streaming T5 Online game server T6 Management: Beacon T7 Management: Probe requests T8 Gaming Reference traffic profile for Scenario 2 Traffic Model # Traffic 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: requests T8 Virtual desktop infrastructure
Center frequency, BSS BW and primary channels Operating channel: 2.4GHz: random assignment of 3 20MHz channels 5GHz: random assignment of [3] or 5 80MHz non-overlapping channels, with random selection of primary channel per operating channel Aggregation [A-MPDU / 64 MPDU aggregation size / BA window size, No A-MSDU, with immediate BA] Max # of retries Max retries: 10 RTS/CTS Threshold [No RTS/CTS] Association X% of STAs in an apartment are associated to the AP in the apartment; 100-X% of the STAs are not associated [X=100] Management Each AP is independently managed Traffic model For Calibration: Use full buffer traffic Downlink only or Uplink only BE class For performance tests: overlapping
Traffic model (Per each apartment) - TBD # Source/Sink Name Traffic definition Flow specific parameters AC Downlink D1 AP/STA1 Buffered video streaming 200Mbps/N (4k video 20Mbps for N=10); VI … VI DN AP/STA_N Buffered video streaming 200Mbps/N (4k video 20Mbps for N=10); VI Uplink U1 STA1/AP 1.5Mpbs UN 1.5Mpbs P2P (optional) P1 STA_{N1+1}/STA_{N1+2} Buffered video streaming 10Mbps VI STA_{N-1}/STA_{N} Buffered video streaming 10Mbps Idle Management (optional M1 AP1 Beacon TX 80 octets long Beacon is transmitted every 100ms All unassociated STAs Req TBD 2 – Enterprise Scenario (Initial version form the Wireless Office scenario in 11/722r2) Parameter Value Topology Figure 2 - BSSs within the building
References for traffic models 11-13/486, “HEW video traffic modeling” Guoqing Li et al, (Intel) [1] [2] 11-13-1059-01-hew-video-performance-requirements-and-simulation-parameters [3]11-09-0296-16-00ad-evaluation-methodology.doc [4] Rongduo Liu et al., “An Emperical Traffic Model of M2M Mobile Streaming Services ”, International conference C on Multimedia information networking and security, 2012 [5] JO. Rose, “ Statistical properties of MPEG video traffic and their impact on traffic modeling in ATM systems ”, Tech report, Institute of CS in University of Wurzburg [6] Savery Tanwir., “A survey of VBR traffic models”, IEEE communication surveys and tutorials, Jan 2013 [7] Aggelos Lazaris et al., “A new model for video traffic originating from multiplexed MPEG-4 videoconferencing streams”, International journal on performance evaluation, 2007 [8] A. Golaup et al., “Modeling of traffic at GOP level using autoregressive process”, IEEE VTC, 2002 [9] K. Park et al., “Self-Similar network traffic and performance evaluation”, John Wiley&Son, 2000 [10] M Dai et al., “A unified traffic model for MPEG-4 and H.264 video traces”, IEEE Trans. on multimedia, issue 5 2009. [11] L Rezo-Domninggues et al., “Jitter in IP network: A cauchy approach”, IEEE Comm. Letter, Feb 2010 [12] Hongli Zhang et al., “Modeling Internet link delay based on measurement”, International conference on electronic computer technology, 2009. Annex 3 - Templates Parameter Topology Figures Environment description APs location AP Type STAs location Number of STA and STAs type Channel Model
Revisions Revisions of document 13/1001 Revision Comments Date R0 Initial draft template Aug 28th R1 Sept 15th 2013 R2 Made it consistent with document 1000r2 Sept 16th 2013 R3 Included Scenario 1 from 1081r0 Included Scenario 2 from Included Scenario 3 and 4 from 1248r0; scenario 3 likely compatible with documents 722 and 1079. Included concept from 1176r0 Added References Updated co-authors Oct 4th 2013 R4 Minor corrections Oct 4th 2013 R5 Added description for scenario 4a (Simone (Qualcomm), Ron (Broadcom)) Tentative addition of contributions related to traffic models; more discussion is needed: Added video traffic models from #1335 (Guoqing Li, Intel) for traffic models (Bill, Sony) Management Traffic profile and % of unassociated users (Reza, Cisco) Application activity intervals (Huai-Rong, Samsung) Indicated that legacy STAs can be present (Various) Indicated that legacy APs can be present in scenario 1(Liwen, Marvell) Indication of antenna height (Wookbong, LG) RTS Thresholds (Liwen, Marvell) Primary channel location (Liwen (Marvell), Klaus (Nokia)) Clarified that all BSSs are either all at 2.4GHz, or all at 5GHz (Liwen, Marvell) Some changes on traffic model for Residential Scenario (Klaus, Nokia) Initial indications of channel model (various, Joseph, (InterDigital), Wookbong (LG); needs more discussion) Clarification on non-HEW definition. Nov 14th 2013
Power save polling (PSP) 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 1 - Residential Scenario (Initial version from documents 11-13/1081r0, 786) Topology
# Source/Sink Name Traffic definition Flow specific parameters AC Downlink D1 AP/STA1 4k Video T1 VI D2 AP/STA2 Local file transfer T3 BE D3 AP/STA3 … … … DN AP/STAN Uplink U1 STA1/AP U2 STA2/AP U3 STA3/AP … … UN STAN/AP P2P P1 STA1/AP P2 STA2/AP P3 STA3/AP … … PN STAN/AP Idle Management M1 AP1 Beacon TX M2 STA2 Req. TY M3 STA3 … … MN STAN References May 2013 11-13/486, “Evaluation methodology and simulation scenarios” Ron Porat (Broadcom) HEW Scenarios and Evaluation Metrics, Thomas Derham (Orange) 11-13/538 “Dense apartment building use case for HEW” , Klaus Doppler (Nokia) 11-13/ 542 “Discussion on scenarios and goals for HEW”, Simone Merlin (Qualcomm) July 2013 11-13/0657r6 HEW SG usage models and requirements - Liaison with WFA Laurent Cariou (Orange) 11-13/0722r1, “HEW Evaluation Methodology”, Minyoung Park (Intel) 11-13/0723, “HEW SG evaluation methodology overview” Minyoung Park (Intel) 11-13/757, “Evaluation methodology and simulation scenarios” Ron Porat (Broadcom) 11-13/0786, “HEW SLS methodology”, Tianyu Wu (Huawei) 11-13/0795, “Usage scenarios categorization”, Eldad Perahia (Intel)
Change “ensures that all ” to “allows” and “guaranteed” to “an allocated” Leave the other ensure as is as it is not within our standard anyway. area of review is Style Guide updates Review how References to SAP primitives are identified The was not clear Suggest to remove the proposed change to the Style Guide Deemed unnecessary. Frame vs PPDU vs MPDU 2375.61 Review the identified issue Control PHY Packet? As we are in the DMG section we do not need to say DMG Control PHY Change to “Control PHY PPDU” Style guide 2.1.2 Naming Frames P146.15 Review 3 items Replace “Probe frames with Probe Request frames” Need to Probe request and Probe response for local consistency. Adrian to check offline 3158.32 Review Change “Probe Frame” to “Probe Request frame” No objection to the identified changes. Naming Frames continued: 1340.38 Review - IEEE Std 802.11 frames? OK to leave as is. frame Review issue We found that there was a typo – change ADBBA to ADDBA Action item: Summarize locations of these changes in this document. Dorothy noted that there were 14 occurrences. IEEE MEC comments Normative references that are no longer cited – should be dropped Normative references to standards being added should be checked and adjusted if needed. Copyright We have already adjusted Need a volunteer for a proposal on a updating this information. Dorothy for a volunteer Action: Dorothy To Check References Review 11-14/1041 Dorothy STANLEY (Aruba) 3741 MAC Review comment Proposed Resolution: Rejected; It is true that the text changes from “transmitted” to “received”. The cited sentence is describing the behavior from the receiver’s
PN2 PN3 PN4 PN5 Bits: 8 8 8 8 BPN subfield The Key ID subfield contains the Key ID for the TID included in the CCMP Update field. The TID subfield contains the TID for the BPN and the Key ID subfields apply CID P.L Clause Comment Proposed Change Resolution 3667 9.49.3 Address 2 should be the MAC address of the AP instead of Relay-AP. as comment Revised – Agree with the commenter. Proposed resolution accounts for the suggested change. TGah editor to make the changes showin in under all headings that include CID 3667. 3668 9.49.3 Address 2 should be the MAC address of the AP instead of Relay-AP. as comment Revised – Agree with the commenter. Proposed resolution accounts for the suggested change. TGah editor to make the changes showin in all headings that include CID 3668. 3840 9.49.3 Short frame for relay operation is not complete Add complete short frame here. Revised – Agree in principle with the commenter. Proposed resolution clarifies the missing parts of the relay operation with Short frames. TGah editor to make the changes showin in under all headings that include CID 3840. 3841 9.49.3 The decision of RA for relay operation is missing. add the related rules. Rejected – The comment is very vague. It seems that the comment asks regarding the selection of the relay to which to forward the data for a given destination. Note that the relay learns the RA of the next hop using the Reachable Address element. 4100 9.49.3 Even in case of short frame, A3 may exist. Change "If the frame is Short frame then Address 3 is not present" to "If the frame is Short frame then Adress 3 may not be present". Rejected – Address 3 is not present for Short frames because it is equal to the address identified by Address 1. This is inline with 8.8.3: “The A3 field is present if A3 is not equal to the address identified by A1 and an A3 is not stored at the receiver, or when A3 is not equal to an A3 stored at the receiver (as described in 9.53 (Header Compression procedure)). When the
IEEE P802.11 Wireless LANs LB 203 Comment Resolution for 9.43.2 Date: 2014-08-26 Author(s): Name Affiliation Address Phone email Shoukang Zheng I2R 1 Fusionopolis Way, #21-01 Connexis, Singapore (65) 6408 2000 skzheng@i2r.a-star.edu.sg Zander Lei I2R leizd@i2r.a-star.edu.sg Yuan Zhou I2R yzhou@i2r.a-star.edu.sg 0 Revision Notes R0: First draft CID Commenter Page Clause Comment Proposed Change Resolution Asterjadhi Paragraphs 2-5 basically list different options of the Poll Type setting for a STA that transmits a PS-Poll frame so you can list these options removing redundancy. See suggested change. The same thing can be done for paragraphs 7-10. Replace these paragraphs with: " An S1G STA that transmits a PS-Poll frame may set the Poll Type field in the Frame Control field to: - 0 if it requests to the AP delivery of DL BUs without requesting rescheduling of the cycle - 1 if it solicits information regarding the change sequence of the Beacon and the partial timestamp - 2 if it is not a TWT STA that requests to the AP delivery of the DL BUs and to the next TBTT - 2 if it is a TWT STA that transmits the Revised- Agree in principle for paragraphs 2-6. However, the same way may not be appropriate for paragraphs 7-10 as the text for the different options are difficult to align with the same structure. TGah editor to make changes shown in 1070r0 under the heading for CID 3368.
frame to the TWT AP within the negotiated TWT SP to request delivery of DL BUs and information for the next TWT - 3 if it requests to the AP to reschedule its doze/wake cycle to another service period" Chu 282.30 9.43.2 This paragraph should be in normal power save subclause Move it to normal power save subclause. Revised- Agree in principle. Subclause 9.43.2 is about non-TIM STAs. Please refer to the description of TIM STA (P323L33,D2.0) for Poll Type subfield setting in Subclause 10.2.2.2. TGah editor to make changes shown in 1070r0 under the heading for CID 3813. Chu 282.62 9.43.2 "Upon reception of a PS-Poll with the Type subfield equal to 2 sent by a TWT STA within the negotiated TWT SP, the AP sends a TACK frame in response to a PS-Poll frame as described in 9.42 (Target wake time (TWT))." This sentence use may/should/shall. Change the text by using may/should.shall. Rejected. The text is declarative as the normative behaviour is already specified in the respective clauses (i.e. Subclause10.2.2.6, 9.43.2, and 9.42). Chu 282.56 9.43.2 The behavior of AP doesn't match the STA's behavior of PS-Poll when Poll Type subfield equal to 1, 2, 3. Make them consistent. Revised- Agree in principle. TGah editor to make changes shown in 1070r0 under the heading for CID 3815. Chu 283.18 9.43.2 A control frame can't include a timer. Change to something like "...that include a time duration" Revised- Agree in principle.
Proposed resolution: REVISED Delete “A-MPDU,” and “, or MMPDU” at 1805.23. Identifiers Comment Proposed change CID 3430 Mark RISON 11.3.5.4 1862.56 Having more than one thing (e.g. "KCK || PMK") on the left of an equals sign is somewhat confusing Use L() as in 11.6.1.3 Discussion: By analogy with 1932.14, 1935.10, 1939.51, 1979.59, it seems that the intent is that the KCK is the first KCK_bits bits of the thing on the right. KCK_bits is 256 here (1862.51: “both the KCK and PMK shall be 256-bits in length”). Proposed resolution: REVISED Change “KCK || PMK” to “kck_and_pmk” at 1862.56. Add “KCK = L(kck_and_pmk, 0, 256)” the equation at 1862.56. Add “PMK = L(kck_and_pmk, 256, 256)” after the equation at 1862.56. In all cases, italicise “kck_and_pmk”. Identifiers Comment Proposed change CID 3462 Mark RISON "Alternate Preferred" -- actually it's not a mere preference, it's an override Change to "Overridden" throughout (10 instances in 8.4.2.76, 10.2.2.16.3, 10.2.2.16.4 and 10.24.8) Discussion: The behaviour involving “Alternate Preferred” is the following (after CIDs 3459 and 3460 are resolved per 15/0126r2, but excluding the premature renaming to “Alternate Proposed”); key parts are highlighted in cyan: If the AP selects an alternate delivery interval or alternate maximum delivery interval from the value specified in the FMS Request, the FMS Status subelement shall be set to one of following values “Alternate Preferred, due to existing stream with different delivery interval”, "Alternate Preferred, due to policy limits on AP", "Alternate Preferred, due to AP changed the delivery interval”, and “Alternate Preferred, due to AP changed the maximum delivery interval”. and the FMS subelement shall indicate the AP selected value(s).”