2. functional requirements

52
July September November May 2009 March May January 2011 July 2010 doc.: IEEE 802.11- 09/00000451r16 12 15 14 8 8 1 2 3 IEEE P802.11 Wireless LANs TGac Functional Requirements and Evaluation Methodology Rev. 16 15 14 12 8 2 3 1 Date: 2009 11 10 -01 07 05 03 11 0 9 5 7 6 -19 14 20 18 1 7 21 13 0 06 9 Authors and Contributors (s): Name Company Address Phone Email Peter Loc Ralink Technology 20833 Stevens Creek Blvd, Suite 200., Cupertino CA 95014 408 807- 0868 peterloc@gmail. com Minho Cheong ETRI 161 Gajeong- dong, Yuseong- gu, Daejeon, Korea +82 42 860 5635 [email protected] r ABSTRACT This document describes the functional requirements and the evaluation methodology for Tgac. These requirements are derived from the document “11-08-0807-04-0vht-below-6-ghz-par-nescom- form-plus-5cs”. All proposals submitted in response to the IEEE802.11 TGac call for The proposal amendment must address the functional requirements that are shown as mandatory in this document. Contributors This will grow to reflect those providing explicit contributions / review comments of this document. (Please let either Peter or and Minho know if any name we have miss ed any name is conspicuously missing from this list. ) Name Company Address Phon Email Submission page 1 Peter (Ralink) and Minho (ETRI)

Upload: danghuong

Post on 10-Feb-2017

232 views

Category:

Documents


0 download

TRANSCRIPT

Page 1: 2. Functional Requirements

JulySeptemberNovemberMay 2009March May January 2011July 2010 doc.: IEEE 802.11-09/00000451r1612151488123

IEEE P802.11Wireless LANs

TGac Functional Requirements and Evaluation Methodology Rev. 161514128231

Date: 20091110-010705031109576-191420181721130069

Authors and Contributors(s):Name Company Address Phone Email

Peter Loc Ralink Technology20833 Stevens Creek Blvd, Suite 200., Cupertino CA 95014

408 807-0868

[email protected]

Minho Cheong

ETRI 161 Gajeong-dong, Yuseong-gu, Daejeon, Korea

+82 42 860 5635

[email protected]

ABSTRACT

This document describes the functional requirements and the evaluation methodology for Tgac. These requirements are derived from the document “11-08-0807-04-0vht-below-6-ghz-par-nescom-form-plus-5cs”. All proposals submitted in response to the IEEE802.11 TGac call for The proposalamendment must address the functional requirements that are shown as mandatory in this document.

ContributorsThis will grow to reflect those providing explicit contributions / review comments of this document. (Please let either Peter orand Minho know if any name we have missed any name is conspicuously missing from this list.)Name Company Address Phone Email

Eldad Perahia Intel Corporation [email protected]

Robert Stacey Intel Corporation robert 1 tacey [email protected] Michelle X. Gong Intel Corporation [email protected]

Vinko Erceg Broadcom [email protected] Fischer Broadcom [email protected]

VK Jones Qualcomm Inc. [email protected] Abraham Qualcomm Inc. [email protected]

Allan Zhu Samsung [email protected] Shi Atheros Comm. Inc. [email protected]

Yashusi Takadori NTT takatori,[email protected] Asai NTT [email protected]

Sudheer Grandhi InterDigital Comm. [email protected] Morioka Sony [email protected]

Submission page 1 Peter (Ralink) and Minho (ETRI)

Page 2: 2. Functional Requirements

JulySeptemberNovemberMay 2009March May January 2011July 2010 doc.: IEEE 802.11-09/00000451r1612151488123

Brian Hart Cisco Systems [email protected] Myles Cisco Systems [email protected] Engwer Self [email protected]

Revision HistoryRevision Comments Date0304r0 Peter and Minho initial contribution on Functional Requirements 13 March 2009R0 Evaluation Methodology and Simulation Scenario are included 10 April 2009R1 Revised by conference call discussions on April 9 and April 23. 09 May 2009R2 Revised by Montreal Interim discussions on May 11-15. 28 May 2009R3 Revised by conference call discussions on May 28 13 July 2009R4 Revised by San Francisco Plenary discussions on July 14 16 July 2009R5 Shadowing term in PHY channel is TBD for further discussions 16 July 2009R6 Minor editorial changes 16 July 2009R7 Some changes in Abstract (approved) 16 July 2009R8 Added enterprise simulation scenario with OBSS (approved) 17 November 2009R12 Added in-home entertainment scenario with OBSS 18 March 2010R14R15

Revert the scenario #3 to that defined in the R8 of the FREMAdded brief comments on PHY abstraction method

20 May 201014 July 2010

R16 Added wall penetration losses for scenario #4 19 January 2011

Submission page 2 Peter (Ralink) and Minho (ETRI)

Page 3: 2. Functional Requirements

JulySeptemberNovemberMay 2009March May January 2011July 2010 doc.: IEEE 802.11-09/00000451r1612151488123

1. Overview

This document specifies the functional requirements and the evaluation methodology for TGac as stated in the VHT below 6 GHz PAR Plus 5C’s. The emphasis is on the following aspects of TGac devicesThe functional requirements as stated in this document cover the following aspects of TGac

1. System performance2. Backward compatibility with 802.11a/n devices operating in 5 GHz3. Coexistence with 802.11a/n devices operating in 5 GHz4. Support of mobile devices5. Enhanced power saving6. OBSS operation7. Compliance to PAR

This document also specifies the evaluation methodology for TGac devices.

Submission page 3 Peter (Ralink) and Minho (ETRI)

Page 4: 2. Functional Requirements

JulySeptemberNovemberMay 2009March May January 2011July 2010 doc.: IEEE 802.11-09/00000451r1612151488123

2. Functional Requirements

2.1 System Performance

2.1.1 Supporting band

TGac R1 TGac devices operate in 5GHz frequency band.

2.1.1 Multi-STA throughput measured at the MAC SAP to be at least 1 Gbps.

TGac R1 – The TGac amendment shall shall provide at least a mode of operation capable of achieving a maximum Multi-Station aggregate throughput of more than 1 Gbps as measured at the MAC data service access point (SAP), a aggregate throughput of at least 1 Gbps at the top of the MAC data service access points (MAC SAPs) utilizing no more than 80 MHz of channel bandwidth in 5 GHz band.

A typical test scenariomay include multiple STAs that are simultaneously and actively communicating with an AP in 5 GHz band and the measured throughput at the MAC SAP of the AP exceeds 1 Gbps. Note that the PAR gives an example of an AP simultaneously actively-communicating with 3 STAs in the explanatory note. However, the number of STAs may actually be 2 or more in a test set up.

2.1.3 2 Single-STA throughput measured at the MAC SAP to be at least 500 Mbps.

TGac R2 – The TGac amendment shall provide at least a mode of operation capable of achieving a maximum Single-Station throughput of more than 500 Mbps as measured at the MAC data service access point (MAC (SAP), utilizing no more than 80 MHz of channel bandwidth in 5GHz band.

A typical test scenario includes a single STA actively communicating with an AP in 5 GHz band and the measured throughput at the MAC SAP of either the AP or STA exceeds 500 Mbps .

2.1.4 Spectrum efficiency

TGac R4 - The TGac amendment shall demonstrate a mode of operation that achieves a spectral efficiency of at least 12 bps/Hz for the PSDU.

2.1.5 802.11e QoS support

TGac R5 - The proposal shall support the QoS enhancements of the IEEE802.11-2007 within a

Submission page 4 Peter (Ralink) and Minho (ETRI)

Page 5: 2. Functional Requirements

JulySeptemberNovemberMay 2009March May January 2011July 2010 doc.: IEEE 802.11-09/00000451r1612151488123TGac STA.

2.1.6 Control of support for 802.11a/n STA from TGac AP

TGac R6 – TGac AP can be configured to reject or accept associations from 802.11a/n STAs.

2.2 Backward Compatibility with 802.11a/n devices operating in 5 GHz

2.2.1 802.11a backward compatibility

Refer to the IEEE Std . 802.15.2-2003, section 3.1 for the definitions of backward compatible.

TGac R7R3- The TGac devices admendment shall provide some modes of operation that are backward compatibilityle .ensure backward compatibility with IEEE802.11a devices operating in the 5 GHz frequency band.

2.2.2 802.11n backward compatibility

TGac R8R4- The TGac admendment shall provide backward compatibility some modes of operation that are backward compatible .with IEEE802.11n devices operating in the 5 GHz frequency band.TGac devices shall ensure backward compatibility with IEEE802.11n devices operating in the 5 GHz frequency band.

2. 3 Coexistence with 802.11a/n devices operating in 5 GHz

Refer to the IEEE Std. 802.15.2-2003, section 3.1 for the definitions of coexistence.

TGac R9 R5 – The TGac amendment shall provide mechanisms that ensure coexistence and fair spectrum sharing between TGac and legacy IEEE802.11a/n devices.The TGac amendment shall provide a mechanism to enable coexistence and spectrum sharing with IEEE802.11a/n devices operating in the same frequency band.

2. 4 Mobile Devices TGac R10 – TGac mobile devices are not required to support requirement R3 (500 Mbps). However, they shall demonstrate a mode of operation that achieves a minimum throughput of 100 Mbps as measured at their MAC SAPs.

2.5 Enhanced Power Saving

Submission page 5 Peter (Ralink) and Minho (ETRI)

Minho_v3, 19/01/11,
In the 11n functional requirements (03/813r13), we only had backward compatibility requirements. Now with a proposal for separate requirements in TGac, it is needed to ditinguish between the two; backward compatibility and coexistence. In IEEE Std. 802.15.2-2003, the definitions are as follows: 3.1.1 backward compatible: The ability of one “new” system to interwork with another “old” system. In this case the different set of rules implies that the new set of rules is a modification of the old set of rules. A subset of interworking. 3.1.2 coexistence: The ability of one system to perform a task in a given shared environment where other systems have an ability to perform their tasks and may or may not be using the same set of rules. 3.1.3 coexistence mechanism: A method for reducing the interference of one system, which is performing a task, on another different wireless system, that is performing its task. Using 11a and 11n as an example, it is possible to classify a few of the 11n features as follows based on the 802.15.2 definitions 11n, 20.1.1: “In addition to the requirements found in Clause 20, when operating in a 20 MHz channel width in the 5 GHz band, an HT STA shall be capable of transmitting and receiving frames that are compliant with mandatory PHY specifications as defined in Clause 17.”  This can be classified as backward compatibility. 11n,  11.14.5 “Scanning requirements for 40 MHz capable STA.”  This can be classified as coexistence. 11n, 20.3.9.2 “HT-mixed format preamble”.  This can be classified as either backward compatibility or coexistence.
Minho_v3, 19/01/11,
In the 11n functional requirements (03/813r13), we only had backward compatibility requirements. Now with a proposal for separate requirements in TGac, it is needed to ditinguish between the two; backward compatibility and coexistence. In IEEE Std. 802.15.2-2003, the definitions are as follows: 3.1.1 backward compatible: The ability of one “new” system to interwork with another “old” system. In this case the different set of rules implies that the new set of rules is a modification of the old set of rules. A subset of interworking. 3.1.2 coexistence: The ability of one system to perform a task in a given shared environment where other systems have an ability to perform their tasks and may or may not be using the same set of rules. 3.1.3 coexistence mechanism: A method for reducing the interference of one system, which is performing a task, on another different wireless system, that is performing its task. Using 11a and 11n as an example, it is possible to classify a few of the 11n features as follows based on the 802.15.2 definitions 11n, 20.1.1: “In addition to the requirements found in Clause 20, when operating in a 20 MHz channel width in the 5 GHz band, an HT STA shall be capable of transmitting and receiving frames that are compliant with mandatory PHY specifications as defined in Clause 17.”  This can be classified as backward compatibility. 11n,  11.14.5 “Scanning requirements for 40 MHz capable STA.”  This can be classified as coexistence. 11n, 20.3.9.2 “HT-mixed format preamble”.  This can be classified as either backward compatibility or coexistence.
Peter Loc, 19/01/11,
Added after the TGac conference call on May 28th
Minho_v3, 19/01/11,
As the TGn AP could be configured to reject or accept associations from IEEE 802.11a stations (one of TGn functional requirements), the TGac AP can also do that for IEEE802.11a/n stations. Backward compability and coexistence with 802.11a/n are essential for this function. In addition, it is also needed to allow an IT manager to program the TGac devices.
Peter Loc, 19/01/11,
Added after the TGac conference call on May 28th
Page 6: 2. Functional Requirements

JulySeptemberNovemberMay 2009March May January 2011July 2010 doc.: IEEE 802.11-09/00000451r1612151488123TGac R11 – The TGac amendment shall provide an enhanced power saving mechanism that results in a lower power consumption than typical 802.11n devices.

2. 6 OBSS Operation

TGac R1 2 – TGa c devices shall provide a mechanism to enable fair channel access and bandwidth sharing with other devices operating in OBSSFor example, when TGac devices are operating with 802.11a/n and 802.11ac devices in the same, adjacent or overlapping channels, they shall not severely affect the throughput of those devices.

2. 7 4 Compliance to PAR TGac R13 R6 - The proposal complies with the PAR and 5 Criteria [1].

Submission page 6 Peter (Ralink) and Minho (ETRI)

Page 7: 2. Functional Requirements

JulySeptemberNovemberMay 2009March May January 2011July 2010 doc.: IEEE 802.11-09/00000451r1612151488123

3 . Evaluation Methodology

The evaluation methodology defines PHY performance, conditions for PAR compliance and a limited set of simulation scenarios and comparison criteria for TGac evaluatation.

As TGac agreed on the approach outlined in the 802.11/09/0376r1, the evaluation methodology for TGac can be build up based on 802.11n one by some modifications.

Each TGac porposal may use a PHY abstraction method. If a PHY abstraction method is used, the method must be described and disclosed.

3 . 1 PHY Performance

3.1.1 PHY channel model

Channel models defined in 802.11n channel model document [8] shall be used. Some modifications to 802.11n channel model are described in [11]. Channel model G for corridor environments will be newly included and AoA and AoD diversity are also considered for TGac [11].

3.1.2 PHY impairments

PHY impairments are updated from ones desribed in 802.11n comparison criteria document [7].

Table 1. PHY impairmentsNumber Name Definition CommentsIM1 PA non-

linearitySimulation should be run at an oversampling rate of at least 24x. To perform convolution of the 24x oversampled transmit waveform with the channel, the channel may be resampled by rounding each channel tap time value to the nearest integer multiple of a sample interval of the oversampled transmit waveform.Use RAPP power amplifier model as specified in document 00/294 with p = 3. Calculate backoff as the output power backoff from full saturation: PA Backoff = 10 log10(Average TX Power/Psat).

Total TX power shall be limited to no more than 17 dBm.

Disclose: (a) EIRP and how it was calculated, (b) PA Backoff, and (c) Psat per PA.

Note: the intent of this IM is to allow different proposals to choose different output power operating points.

Unchanged fron 802.11nAdded comments for higher sampling rate for channel

Submission page 7 Peter (Ralink) and Minho (ETRI)

정민호, 19/01/11,
In order to clarify the higher sampling rate for the channel. We need to consider both upsampling prior to the PA then downsampling prior to channel and including the PA oversampling rate in the channel model.
Minho_v4, 19/01/11,
In 11-09/0785r0, An investigation of the PA model was done with both 2x and 4x oversampling. Results show that there is some slight differences in PER when the signal is being severely compressed. In those cases the 2x sampling rate is slightly worse from a performance perspective. In normal operating regions, within a few dB of the Lossless level, the difference is negligible. So, It is recommended that the PA model oversampling rate requirement be lowered to 2x.
Minho_v15, 19/01/11,
In MU-MIMO ad-hoc meeting held on 13th July 2010 in San Diego, there was a straw poll to insert this sentence in FR-EM, which was approved by Yes 15/ No 0/ Abstain 25.
Page 8: 2. Functional Requirements

JulySeptemberNovemberMay 2009March May January 2011July 2010 doc.: IEEE 802.11-09/00000451r1612151488123

Note: the value Psat = 25dBm is recommended.

IM2 Carrier frequency offset

Single-user simulations for all comparisons except Offset Compensation shall be run using a fixed carrier frequency offset of –13.675 ppm at the receiver, relative to the transmitter. The symbol clock shall have the same relative offset as the carrier frequency offset. Simulations shall include timing acquisition on a per-packet basis.

Downlink Mmulti-user simulations for all comparisons except offset compensation shall be run using a fixed carrier frequency offset selected from the array [N(1) ,N(2),……,N(16) ], relative to the transmitter, where N(j) corresponds to the frequency offset of the j-th client and is randomly chosen from [-20,20] ppm with a uniform distribution. We can assume that a maximum of 16 clients may be served simultaneously in a multi-user simulation.

Uplink multi-user simulations for all comparisons except offset compensation shall be run using a fixed carrier frequency offset selected from the array [N(1) ,N(2),……,N(16) ], relative to the receiver, where N(j) corresponds to the frequency offset of the j-th client and is randomly chosen from [-2,2] KHz with a uniform distribution.

Added a set of possible offsets to be used for several STAs. 802.11n specified a single offset of -13.67 ppm

IM34 Phase noise

The phase noise will be specified with a pole-zero model.

PSD(0) = -100 dBc/Hzpole frequency fp = 250 kHzzero frequency fz = 7905.7 kHz

Note, this model results in PSD(infinity) = -130 dBc/Hz

Note, this impairment is modeled at both transmitter and receiver.

Unchanged from 802.11n

IM45 Noise figure

Input referred total noise figure from antenna to output of the A/D will be 10dB.

Unchanged from 802.11n

IM56 Antenna Configuration

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.

All antennas shall have the same vertical polarization.The TGac antennas can beare 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 [11]

Mix of vertically and horizontally polarized antennas or dual polarization at ±45 degree is also considered for

Submission page 8 Peter (Ralink) and Minho (ETRI)

정민호, 19/01/11,
Because dual polarization at ±45 degree is one of easy solutions to specify in reality.
정민호, 19/01/11,
There may be some discussion whether similar configuration used in TGn is realistic with 8 or 16 antennas.
Minho_v12, 19/01/11,
These numbers are based on the presentation Richard Van Nee (Qualcomm) did in September 2009, document 11-09-1036r0. In that presentation he showed what the timing and frequency accuracy requirements had to be for uplink MU-MIMO clients. It seems to make sense to use these numbers as impairments for anyone who wants to do PHY level UL-MU-MIMO simulations, because up till now, there were no specific UL impairments mentioned so anyone can just pick arbitrary impairments.
Page 9: 2. Functional Requirements

JulySeptemberNovemberMay 2009March May January 2011July 2010 doc.: IEEE 802.11-09/00000451r1612151488123

TGac devicesIM6 Fluorosc

ent Light Effects

The fluoroscent light effects specifed in the TGn Channel model shall not be considered for the simulation scenarios.

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 [-100,100] ns  with a uniform distribution

3.1.3 Comparison criteria

1. PER vs. SNR curvesa. all MCS’sb. Simulate all of channel modelsc. Simulation must include:

i. updated PHY impairmentsii. timing acquisition on a per-packet basisiii. preamble detection on a per-packet basis

Submission page 9 Peter (Ralink) and Minho (ETRI)

Minho_v12, 19/01/11,
These numbers are based on the presentation Richard Van Nee (Qualcomm) did in September 2009, document 11-09-1036r0. In that presentation he showed what the timing and frequency accuracy requirements had to be for uplink MU-MIMO clients. It seems to make sense to use these numbers as impairments for anyone who wants to do PHY level UL-MU-MIMO simulations, because up till now, there were no specific UL impairments mentioned so anyone can just pick arbitrary impairments.
정민호, 19/01/11,
This is one of important result of channel modelling work in TGac by NTT.
Minho_v8, 19/01/11,
It has been proved in 802.11/09/0943r1, that is, the fluorescent light effect should be kept in mind by implementers yet the effect may not be significant enough to warrant its own channel model or simulation scenario.
Page 10: 2. Functional Requirements

JulySeptemberNovemberMay 2009March May January 2011July 2010 doc.: IEEE 802.11-09/00000451r1612151488123

3 . 2 Traffic Models

TGac evaluation shall consider traffic models defined 802.11n usage model documents [3] including high-quality videos for VHT defined in [12] and high-speed file transfer.

Table 2. Traffic modelsNum. Application Offered

Load (Mbps)

Protocol

MSDU Size (B)

Max. PLR

Max. Delay (ms)

Source[ref]

1 Lightly-compressed video

150 UDP TBD 10^-7 10 Motion JPEG2000

2 Lightly-compressed video

200 UDP TBD 10^-7 / 8 20 H.264

3 Compressed video

50Mbps UDP TBD 10^-7 20 Blu-rayTM

43 Compressed videoDV Audio/video

20Mbps28.8

UDPUDP

15001024, Is this true? All other video/audio (SDTV, HDTV) transfers has this parameter set to 1500.

3x10^-710^-7(corresponds to a rate of 0.5 loss/hour) 1

2

20200 HD-MPEG2SD Specifications of Consumer-Use Digital VCRs

Max PLR: 15-03-276r0

54 VoD control channel

0.06 UDP 64 10^-2 100 Guess

5 SDTV 4-5 UDP 1500 5*10^-7 200 16 HDTV

(Video/Audio)

19.2-24 UDP 1500 10^-7 200 1

7 DVD 9.8 peak UDP 1500 10^-7 200 168 Video Conf 0.128 - 2 UDP 512 10^-4 100 179 Internet

Streaming video/audio

0.1 – 4 UDP 512 10^-4 200 1

810 Internet Streaming audio

0.064~0.256

UDP 418 10^-4 200 Group guess

911 VoIP 0.096 UDP 120 5% 30 ITU-T G.114 300ms round-trip delayG.711 Codec

1012 Reserved

1 Note, this corresponds to a loss of a 1024B MSDU per hour. The TS PDU PLR is higher than this. It is not known what is the effect to the decoder of giving it burst packet losses.2 Note, a PLR of 10^-7 will not be measurable in our simulation technologies.

Submission page 10 Peter (Ralink) and Minho (ETRI)

정민호, 19/01/11,
정민호, 19/01/11,
This traffic model is not used in TGac simulation scenarios which are followed by.
정민호, 19/01/11,
This traffic model is not used in TGac simulation scenarios which are followed by.
정민호, 19/01/11,
This traffic model is not used in TGac simulation scenarios which are followed by.
Page 11: 2. Functional Requirements

JulySeptemberNovemberMay 2009March May January 2011July 2010 doc.: IEEE 802.11-09/00000451r16121514881231113 Reserved1214 MP3 Audio

Other formats are taking over (AAC/MPEG-4, OggVorbis, etc)

0.064 – 0.32

UDP 418 10^-4 200 1

1314.5

Reserved

1415 Content download (photo camera)

minimum 1011Max. 10Mbps

TCP 1500 N/A Corresponds to USB and flash speed

1516 Internet File transfer (email, web, chat)

Minimum 1Max. 10Mbps

TCP 300 N/A

1617 Local File transfer, printing

50minimum 30Max. 1Gbps

TCP 1500 N/A Aps guess

18 Interactive Gaming[Controller to Console x 1]

0.5 UDP 50 10^-4 16 2

19 Interactive Gaming[Console to Display]

100+ UDP 1500 10^-2 10 2video image: 320x240x15 @ 60Hz

20 Interactive Gaming[Console to Internet Access]

*NOTE : Depends on Game Type

1 UDP 512 10^-4 50ms Group consensus

21 Netmeeting application/desktop sharing

0.5 TCP 512 N/A Group guess

1722 Reserved1823 Reserved

1924 Reserved2025 Video phone 0.5 UDP 512 10^-2 100 Aps guess

Submission page 11 Peter (Ralink) and Minho (ETRI)

정민호, 19/01/11,
This traffic model is not used in TGac simulation scenarios which are followed by. This is standard definition, should be changed to HD if we want to include for TGac.
정민호, 19/01/11,
This traffic model is not used in TGac simulation scenarios which are followed by.
정민호, 19/01/11,
This traffic model is not used in TGac simulation scenarios which are followed by.
정민호, 19/01/11,
This traffic model is not used in TGac simulation scenarios which are followed by.
정민호, 19/01/11,
The proposed change is driven by the IEEE 802.11n simulation experience and the observation that the network was empty most of the time during simulation. And file transfer speed can be infinite offered load to saturate the network.
정민호, 19/01/11,
1, 19/01/11,
TCP flows can have ‘infinite’ load or some very large number (say 1Gbps). Matt at Broadcom, Robert and Michelle at Intel suggested that it is more applicable to use a specific number that is known to be larger than the achievable rate rather than just infinite. Then, max. 10Mbps and max. 1Gbps is picked for Internet file transfer and local file transfer, respectively.
정민호, 19/01/11,
to correct original slight mismatch between TGn traffic model and TGn simulation scenarios. And file transfer speed can be infinite offered load to saturate the network.
Page 12: 2. Functional Requirements

JulySeptemberNovemberMay 2009March May January 2011July 2010 doc.: IEEE 802.11-09/00000451r16121514881232126 Remote user

interface (X11, Terminal Server Client)(remote display/keyboard/mouse)

0.5-1.5 (peak)

UDP 700 N/A 100 11-03-0696r0

22 Clicking on web link

0.256 TCP 64 N/A desribed in 11-03-0802r23 (pp. 27)

23 Infinite Source Model

Infinite (transmit buffer always full)

TCP 1500 or 1000 or 300

N/A Popular model in network analysis

Rref.) High-quality video service requirements for VHT [12]

Video Compression

Description Rate, Mbps

Packet Error Rate

Jitter, ms

Delay,ms

Uncompressed 720p (RGB): 1280x720 pixels, 24bits/pixels,60frames/s

1300 10^-8 5 5

1080i (RGB): 1920x1080/2pixels, 24bits/pixels,60frames/s

1300 10^-8

1080p (YCrCb): 1920x1080 pixels, 12bits/pixels,60frames/s

1500 10^-8

1080p (RGB): 1920x1080 pixels, 24bits/pixels,60frames/s

3000 10^-8

Lightly Compressed

Motion JPEG2000H.264

15070 - 200

10^-710^-7 / 8

1020

1020

Compressed Blu-ray™ 50 10^-7 20 20

HD MPEG2 20 3x10^-7 20 20

Submission page 12 Peter (Ralink) and Minho (ETRI)

정민호, 19/01/11,
These match to the contents in the traffic model table on previous page.
1, 19/01/11,
This table is deleted because it is already included in one of references.
1, 19/01/11,
Infinite source models is newly included because there may be some special case to need it.
Page 13: 2. Functional Requirements

JulySeptemberNovemberMay 2009March May January 2011July 2010 doc.: IEEE 802.11-09/00000451r1612151488123

4 . Simulation Scenarios Simulation scenarios for TGac evaluation are summarized as:

Table 3. Simulation scenarios

Scenario Number

Purpose Note

1 Test compliance to PAR. Single STA 500Mbps throughput at the MAC SAP

2 Test compliance to PAR. Multi STA 1Gbps throughput at the MAC SAP

3 Test backward compatibility to 802.11n.

Single 802.11n STA 100Mbps throughput at the MAC SAP

4 Test backward compatibility to 802.11n with mixed 802.11n and TGac STAs.

Single 802.11n STA at 100Mbps throughput at the MAC SAP + Single TGac STA with 250Mbps throughput at the MAC SAP.

35 In-home entertainment application without OBSS.

Multiple flows with varied QoS requirementsIncludes several lightly-compressed video flows.Aligns with Category 1 and Category 2 applications.

4 In-home entertainment application with OBSS

Multiple flows with varied QoS requirementsIncludes several lightly-compressed video flows.Aligns with Category 1 and Category 2 applications.

546 Enterprise network without OBSS

Stress test for TGac operation.Scenario with large number of flows.Aligns with Category 2 and Category 3 applications.

65 Enterprise network with OBSS

Stress test for TGac operation.Scenario with large number of flows.Aligns with Category 2 and Category 3 applications.

4 . 1 Test for Compliance to PAR

4.1.1 Point-to-point link test (scenario #1)

Synthetic test case to demonstrate single STA 500Mbps throughput at the MAC SAP.This scenario is derived from scenario #19 defind in 802.11n usage model document.

Two stationsOne TGac AP is source.One TGac STA is sink.

Traffic from AP to STA

Submission page 13 Peter (Ralink) and Minho (ETRI)

Minho_v8, 19/01/11,
This scenario is newly added to check impact of OBSS in enterprise network simulation. Change edits got prior approval by motion in Hawaii meeting 2009, that is, TGac approves applying the changes in 09/980r1 to 09/451r7 for the purpose of allowing comparability in OBSS behavior.
정민호, 19/01/11,
Because backward compatibility is not a system-level requirements but only PHY-level requirements, then it is better not to include these in simulation scenarios.
Page 14: 2. Functional Requirements

JulySeptemberNovemberMay 2009March May January 2011July 2010 doc.: IEEE 802.11-09/00000451r1612151488123

Protocol: UDPOffered load : infiniteMSDU size: TBD1500

PHY channel model Model BChannel model B

Locations of stationsFixed locations: (0,0) meters for AP and (0,10)(0,5) meters for STA

Meet requirements in [functional requirements Sections 2.1.23]

4.1.2 Point-to-multi-point link test (scenario #2)

Synthetic test case to demonstrate multi STA aggregated 1Gbps throughput at the MAC SAP.This scenario is also derived from scenario #19 defind in 802.11n usage model document.

Number of stations (AP + STAs): at least 23 TBDFive stationsOne TGac AP is sourceNumber of TGac STAs which are sinks : at least 2Four TGac STAs are sinks

Traffic from AP to STAProtocol: UDPOffered load : infinite

MSDU size: 1500TBDPHY channel model

Model DChannel model BLocations of stations

Fixed locationsMeet requirements in [functional requirements Sections 2.1.21]

Table 4. Flows in scenario #2

Flow No. Source

Source Location(meters) Sink

Channel Model

Sink Location(meters) Application

Bit RateApplication Load (Mbps)

Rate Distribution

MSDU Size (B)

                   

  Downlink Flows              

1 AP (0,0) STA1 BD (0,10) Data250.00minimum

1000/nN Mbps

Infinite Backlog , UDP TBD1500

2 AP (0,0) STA2 DB (10,0) Data

minimum 1000/nN

Mbps250.00

Infinite Backlog , UDP TBD1500

: :

: :

: :

: :

: :

: :

: :

: :

nN AP (0,0) STA4N DB (-6,-8) Data

minimum 1000/nN

Mbps250.00

Infinite Backlog , UDP TBD1500

Note) Different bit rate can be offered to each flow.

4 . 2 Test for Backward Compatibility to 802.11n

4.2.1 Test for backward compatibility to 802.11n (scenario #3)

Submission page 14 Peter (Ralink) and Minho (ETRI)

정민호, 19/01/11,
Distances between STAs can be modified because this issue is tightly related to the number of STAs.
정민호, 19/01/11,
Channel model B may be not applicable to multi-user scenario as Vinko at Broadcom suggested. Channel model D seems more adequate at the present.
정민호, 19/01/11,
Offered load need to be infinite, not fixed at 250Mbps to check the network capacity.
정민호, 19/01/11,
Channel model B may be not applicable to multi-user scenario as Vinko at Broadcom suggested. Channel model D seems more adequate at the present.
정민호, 19/01/11,
Offered load need to be infinite, not fixed at 250Mbps to saturate the network capacity.
정민호, 19/01/11,
TGac agreed on need of more discussions about number of stations at conference call on April 09. 5 (AP + stations) seems suitable at the present.
정민호, 19/01/11,
because this is more suitable for this environment as Vinko at Broadcom suggested.
정민호, 19/01/11,
Channel model B seems adequate for this scenario. But, it needs more discussion about this.
Page 15: 2. Functional Requirements

JulySeptemberNovemberMay 2009March May January 2011July 2010 doc.: IEEE 802.11-09/00000451r1612151488123

Synthetic test case to demonstrate 100Mbps throughput to a single 802.11n STA at the MAC SAP. This scenario is derived from scenario #18 defind in 802.11n usage model document.

Two stationsOne TGac AP is sourceOne 802.11n STA is sink

Traffic from AP to STAProtocol: UDPMSDU size: 1500

PHY channel modelChannel model B

Locations of stationsFixed locations

Meet requirements in 802.11n functional requirements No. 1 in Section 2 [2].

Flow No. Source

Source Location(meters) Sink

Channel Model

Sink Location(meters) Application

Bit Rate (Mbps)

Rate Distribution

MSDU Size (B)

Max Delay (ms) PLR

                       

  Downlink Flows                  

1 AP (0,0)STA1 (11n) B (0,10) Data 100.00

Constant, UDP 1500 N/A 0

4.2.2 Test for backward compatibility to 802.11n with mix 802.11n and TGac (scenario #4)

Synthetic test case to demonstrate throughput sharing between a 802.11n STA (100Mbps) and a TGac STA (250Mbps). This scenario is derived from scenario #19 defind in 802.11n usage model document.

Three stationsOne TGac AP is source.One TGac STA is sink.One 802.11n STA is sink

Traffic from AP to STAProtocol: UDPMSDU size: 1500

PHY channel modelChannel model B

Locations of stationsFixed locations

Meet requirements in 802.11n functional requirements No. 1 in Section 2 [2].

Flow No. Source

Source Location(meters) Sink

Channel Model

Sink Location(meters) Application

Bit Rate (Mbps)

Rate Distribution

MSDU Size (B)

Max Delay (ms) PLR

                       

Submission page 15 Peter (Ralink) and Minho (ETRI)

Page 16: 2. Functional Requirements

JulySeptemberNovemberMay 2009March May January 2011July 2010 doc.: IEEE 802.11-09/00000451r1612151488123  Downlink Flows                  

1 AP (0,0) STA1(11n) B (0,10) Data 100.00Constant, UDP 1500 N/A 0

2 AP (0,0) STA2(11ac) B (10,0) Data 250.00Constant, UDP TBD N/A 0

4 . 2 3 In-Home Entertainment Application (scenario #35)

4 . 2 .1 In-Home Entertainment Application without OBSS (scenario #3)

Test case to demonstrate in-home entertainment application with multiple flows with varied QoS requirements including lightly-compressed video.This scenario is derived from scenario #1 defind in 802.11n usage model document and modified in order to consider usage model 2a and 2.b (PVR’s in residential) defined in [12] as well.

141511 stationsOne TGac AP is source and sink.131410 STAs are souces and sinks. (STA2 is reserved)

Traffic from AP to STAsLightly-compressed videoCompressed video, compressed video, Internet file, VoIP, Internet streaming video, MP3 audio, VoIP

Traffic from STAs to APCompressed video, VoD control channel, VoIP, video console, Internet entertainment, VoIPconsole to Internet

Traffic STAs to STAsLocal file transfer, video phone, controller to console, compressed video, contents download

PHY channel for each linkChannel model type applied : TModel CBD

Only channel model B’s or mixing B’s and D’s for more realistic scenario Channel model break point between LOS and NLOS: unchanged from 802.11n(unchanged from 802.11n scenarios)Distance between STAs can be used to select between LOS and NLOS according to the breakpoint distance defined in 802.11n channel model document [8].e.g.) 5 meters for model B and 10 meters for model D

Shadowing term is TBD 0dB (unchanged from 802.11n scenarios)In 802.11n channel model document [8], shadow fading std. dev. is specified for each channel model between 3dB and 6dB at page 7. But, Iinn 802.11n usage model document [3], shadowing term applied to all the 802.11n simulation scenarios is set to 0dB for generating a channel realization at page 22.

Locations of stationsFixed locations (unchagend from 802.11n scenario #1)

Meet requirements specified in PLR and Max. Delay per each flowTotal throughput condition

Submission page 16 Peter (Ralink) and Minho (ETRI)

정민호, 19/01/11,
(unchanged from 802.11n scenarios)l model document [8], shadow fading std. dev. is specified for each channel model between 3dB and 6dB at page 7.
정민호, 19/01/11,
It may be unchanged from the method used in 802.11n scenarios. Distance between STAs can be used to select between LOS and NLOS according to the breakpoint distance defined in 802.11n channel model document [8]. e.g.) 5 meters for model B, 5 meters for model C and 10 meters for model D.
정민호, 19/01/11,
Both channel model type applied and whether mixing of multiple channel models are TBD. Using channel model B seems not realistic for multi-user scenario. So, using channel C or mixing of channel B and C may be selected for this scenario.
정민호, 19/01/11,
This scenario is originally derived from TGn scenario #1. And it can also be thought as the scenario considering usage model 2a and 2b in TGac usage model document (09/ 161r2) into it. Usage model 2a and 2b has PVR connected to TV’s, which has all video going through the AP.
Minho_v3, 19/01/11,
STAs is newly activated n this scenario, which used to be reserved.
Minho_v3, 19/01/11,
Logical link in scenario 3 is supplied.
정민호, 19/01/11,
Because backward compatibility is not a system-level requirements but only PHY-level requirements, then it is better not to include these in simulation scenarios.
Page 17: 2. Functional Requirements

JulySeptemberNovemberMay 2009March May January 2011July 2010 doc.: IEEE 802.11-09/00000451r1612151488123

It is available to offer infinite load for this scenario with TCP flows.Total throughput (about minimum 465386Mbps) is not a heavy burden similarcompared to that of scenario #1 defined in 802.11n usage model document (about 64Mbps).

Table 5. Flows in scenario #3

Flow No.

STAs(Source/Sink)

Source Location(meters)

Sink Location(meters)

Channel Model

Application(Forward Traffice / Backward Traffic)

Application Load (Mbps)(Forward / Backward)

Rate Distribution(Forward / Backward)

MSDU Size (B)(Forward / Backward)

Max. Delay (ms)(Forward / Backward)

Max. PLR(Forward / Backward)

1 AP / STA1 (0,0) (0,5) CLC Video / VoD control channel 150.00 / 0.06

Constant, UDP / Constant UDP 1500 / 64 10 / 100  10^-7 / 10^-2

2note

STA7 / STA2 (7,-7) (-10,-10) CHD MPEG2 / control channel 20.00 / 0.06

Constant UDP / Constant UDP 1500 / 64 20 / 1003x10^-7 / 10^-2

3 note

STA8 / STA3 (-10,0) (5,0) CBlu-rayTM

/ control channel 50.00 / 0.06

Constant, UDP / Constant UDP 1500 / 64 20 / 100  10^-7 / 10^-2

4 note

STA9/ STA 4 (0,-10) (-7,7) CBlu-rayTM

/ control channel 50.00 / 0.06

Constant, UDP / Constant UDP 1500 / 64 20 / 100  10^-7 / 10^-2

5 AP / STA4 (0,0) (-7,7) CInternet file / clicking on web link

Max. 10Mbps /

0.256TCP / TCP 300 / 64 Inf. / Inf.  N/A / N/A

6 AP / STA10 (0,0) (10,10) C

HD MPEG2 / video console + Internet entertainment 20.00 / 1.00

Constant UDP / Constant UDP 1500 / 512 20 / 503x10^-7 / 10^-4

7 AP / STA11 (0,0) (10,5) C MP3 audio 0.13 / UDP 418 200 10^-4

8STA11/STA10 (10,5) (10,10) C Controller to Console 0.50Constant, UDP 50 16 10^-4

9 AP / STA12 (0,0) (20,0) C VoIP / VoIP 0.096 / 0.096UDP / UDP 120 / 120 30 / 305% / 5%10 AP / STA13 (0,0) (0,20) C VoIP / VoIP 0.096 / 0.096UDP / UDP 120 / 120 30 / 305% / 5%11 AP / STA14 (0,0) (0,-20) C VoIP / VoIP 0.096 / 0.096UDP / UDP 120 / 120 30 / 305% / 5%

12STA4 / STA10  (-7,7)  (10,10) C Local file transfer Max. 1Gbps TCP 300 Inf.  N/A

13 STA5 / STA6 (-15,0) (0,-15) CVideo Phone / Video Phone 0.50 / 0.50

Constant, UDP / Constant UDP 512 / 512 100 / 100  10^-2 / 10^-2

Total Throughput Note) Display/video flows are specified as logical links so that they may either be simulated as direct link setup or relay via the AP. Note) Logical link in this scenario can be seen with topology in Support document.

Table 6. Flows in scenario #3

Flow No.

STAs(Source/Sink)Source

Source Location(meters)

Sink Location(meters)

Channel Model

Application(Forward Traffice / Backward TrafficApplication)

Bit Rate Application Load (Mbps)(Forward / Backward)

Rate Distribution(Forward / Backward)

MSDU Size (B)(Forward / Backward)

Max. Delay (ms)(Forward / Backward)

Max. PLR(Forward / Backward)

                       Downlink Flows                

1 AP / STA1 (0,0) (0,5) C

Blu-rayTM

/ control channelLC Video / VoD control channel

50.00 / 0.06150.00 / 0.06

Constant, UDP / Constant UDP

TBD1500 / 64 10 / 100  10^-7 / 10^-2

2note

STA7 / STA2AP (07,0-7) (-10,-10) C

HD MPEG2 / control channel 20.00 / 0.06

Constant UDP / Constant UDP 1500 / 64 20 / 100 3x10^-7 / 10^-2

3 note

2

AP / STA3STA8 / STA3AP

(0,0)(0,0-10,0) (5,0) C

Blu-rayTM

/ control channel LC Video

150.0050.00 / 0.06

Constant, UDP / Constant UDP

TBD1500 / 64 1020 / 100  10^-7 / 10^-2

43

note

STA9/ STA 4AP (0,-100,0) (-7,7) C

Blu-rayTM

/ control channel Blu-rayTM

LC Video

150.0050.00 / 0.06

Constant, UDP / Constant UDP

TBD1500 / 64 1020 / 100  10^-7 / 10^-2

54 AP / STA4 (0,0) (-7,7) CInternet file / clicking on web link

Minimum 1.00Max.

10Mbps / 0.256 TCP / TCP 300 / 64 Inf. / Inf.  N/A / N/A

65 AP / STA10AP

(0,0)(0,0) (10,10)(7,-7)(20,0)

CC HD MPEG2 / VoD control

channelVoIPvideo console + Internet

20.00 / 1.000.100.06

Constant UDP / Constant

UDPConstant, UDP

1500 / 51212064

20 / 5030100

3x10^-7 / 10^-4 5%10^-2

Submission page 17 Peter (Ralink) and Minho (ETRI)

1, 19/01/11,
TCP flows can have ‘infinite’ load or some very large number (say 1Gbps). Matt at Broadcom, Robert and Michelle at Intel suggested that it is more applicable to use a specific number that is known to be larger than the achievable rate rather than just infinite. Then, max. 10Mbps and max. 1Gbps is picked for Internet file transfer and local file transfer, respectively.
정민호, 19/01/11,
It is desirable that TCP file transfer speed can be infinite offered load to check the system capacity.
Minho_v4, 19/01/11,
Minho_v4, 19/01/11,
We added two clauses in 4.4 comparison critera instead of insertion of an additional column specifying the number of antennas of STA in table 5 and table 6. There modifications were suggested by Robert (Intel), VK (Qualcomm) and Hemanth (Qualcomm) after TGac session discussions on July 14.
1, 19/01/11,
TCP flows can have ‘infinite’ load or some very large number (say 1Gbps). Matt at Broadcom, Robert and Michelle at Intel suggested that it is more applicable to use a specific number that is known to be larger than the achievable rate rather than just infinite. Then, max. 10Mbps and max. 1Gbps is picked for Internet file transfer and local file transfer, respectively.
1, 19/01/11,
TCP flows can have ‘infinite’ load or some very large number (say 1Gbps). Matt at Broadcom, Robert and Michelle at Intel suggested that it is more applicable to use a specific number that is known to be larger than the achievable rate rather than just infinite. Then, max. 10Mbps and max. 1Gbps is picked for Internet file transfer and local file transfer, respectively.
정민호, 19/01/11,
It is desirable that TCP file transfer speed can be infinite offered load to check the system capacity.
Minho_v4, 19/01/11,
정민호, 19/01/11,
It is desirable that TCP file transfer speed can be infinite offered load to check the system capacity.
Page 18: 2. Functional Requirements

JulySeptemberNovemberMay 2009March May January 2011July 2010 doc.: IEEE 802.11-09/00000451r1612151488123

entertainment

76AP /

STA11AP (0,0)(0,0)

(10,5)(-10,0)

(0,20) CCMP3 audio VoD

control channelVoIP 0.13 / 0.100.06UDPConstant,

UDP 418 12064 200 30100  10^-4 5%10^-28STA11/STA10 (10,5) (10,10) C Controller to Console 0.50 Constant, UDP 50 16  10^-4

87 AP(0,0)(0,-10)(0,-20) C

VoD control channelVoIP 0.100.06 Constant, UDP 12064 30100  5%10^-2

98 AP(0,0) (10,10) CInternet Streaming video HD MPEG2 2.0020.00

UDPConstant, UDP 5121500 20020

 10^-410^-7

109 AP (0,0) (10,5) C MP3 audio 0.13UDP 418 200 10^-4911 AP / STA12 (0,0) (20,0) C VoIP / VoIP 0.096 / 0.096 UDP / UDP 120 / 120 30 / 30 5% / 5%1012 AP / STA13 (0,0) (0,20) C VoIP / VoIP 0.096 / 0.096 UDP / UDP 120 / 120 30 / 30 5% / 5%1113 AP / STA14 (0,0) (0,-20) C VoIP / VoIP 0.096 / 0.096 UDP / UDP 120 / 120 30 / 30 5% / 5%

 12 STA4 / STA10  (-7,7)  (10,10) C Local file transfer  Max. 1Gbps  TCP  300  Inf.    N/A 

  Uplink Flows              

131410

STA5 / STA6STA1

(-15,0) (0,5)

(0,-15) (0,0) CC

Video Phone / Video PhoneVoD control channel 0.50 / 0.500.06

Constant, UDP / Constant UDPConstant, UDP 512 / 51264

100 / 100100

 10^-2 / 10^-2 10^-2

15 STA2 (-10,-10) (0,0) C control channel 0.06 Constant UDP 64 100 10^-2

1611 STA3 (5,0) (0,0) C VoD control channel 0.06Constant, UDP 64 100 10^-2

17 STA4 (-7,7) (0,0) C control channel 0.06 Constant UDP 64 100 10^-2

1812 STA7(7,-7)(20,0) (0,0) C

HD MPEG2Blu-rayTM

VoIP 0.1050.00 Constant, UDP 1201500 3020  5%10^-7

1913 STA8(-10,0)(0,20) (0,0) C Blu-rayTM

VoIP 0.1050.00 Constant, UDP 1201500 3020  5%10^-7

2014 STA9(0,-10)(0,-20) (0,0) C

Blu-rayTM

HD MPEG2VoIP 0.1020.00 Constant, UDP 1201500 3020  5%3x10^-7

2115 STA10(10,10) (0,0) C

Video console + Internet entertainmentConsole to Internet 1.00 Constant, UDP 512 50 10^-4

22 STA12 (20,0) (0,0) C VoIP 0.096 UDP 120 30 5%

23 STA13 (0,20) (0,0) C VoIP 0.096 UDP 120 30 5%

24 STA14 (0,-20) (0,0) C VoIP 0.096 UDP 120 30 5%                     STA to STA Flows              

2516 STA4 (-7,7) (10,10) C Local file transfer

Minimum 10.00

Max. 1Gbps TCP 300 Inf.  N/A2617 STA5 (-15,0) (0,-15) C Video Phone 0.50Constant, UDP 512 100 10^-22718 STA6 (0,-15) (-15,0) C Video Phone 0.50Constant, UDP 512 100 10^-2

2819 STA11 (10,5) (10,10) C Controller to Console 0.50Constant, UDP 50 16 10^-4Total ThroughputThruput

Minimum 385.93466.35

Note) Display/video flows are specified as logical links so that they may either be simulated as direct link setup or relay via the AP. Note) Logical link in this scenario can be seen with topology in Support document.Note) Limited number of antennas for some devices are exemplary, to allow for proposal comparison.Note) STA2 is reserved.

4.2.2 In-Home Entertainment Application with OBSS (scenario #4)

Test case to demonstrate in-home entertainment application with multiple flows with varied QoS requirements including compressed video and OBSS.

Submission page 18 Peter (Ralink) and Minho (ETRI)

Minho_v9, 19/01/11,
In order to simplify OBSS scenario, 09/1076r0 focused on the following effects; overlapping with 11ac overlapping with 11n effect of hidden terminals in OBSS throughput degradation from isolated in-home entertainment scenario. To qualify the OBSS effect, 09/1076r0 suggested the following evaluation model; BSS A: In-Home entertainment application BSS B: 11ac with 3 STAs BSS C: 11n with 3 STAs room walls are inserted to evaluate effect of hidden terminals
Minho_v4, 19/01/11,
We added two clauses in 4.4 comparison critera instead of insertion of an additional column specifying the number of antennas of STA in table 5 and table 6. There modifications were suggested by Robert (Intel), VK (Qualcomm) and Hemanth (Qualcomm) after TGac session discussions on July 14.
1, 19/01/11,
TCP flows can have ‘infinite’ load or some very large number (say 1Gbps). Matt at Broadcom, Robert and Michelle at Intel suggested that it is more applicable to use a specific number that is known to be larger than the achievable rate rather than just infinite. Then, max. 10Mbps and max. 1Gbps is picked for Internet file transfer and local file transfer, respectively.
1, 19/01/11,
TCP flows can have ‘infinite’ load or some very large number (say 1Gbps). Matt at Broadcom, Robert and Michelle at Intel suggested that it is more applicable to use a specific number that is known to be larger than the achievable rate rather than just infinite. Then, max. 10Mbps and max. 1Gbps is picked for Internet file transfer and local file transfer, respectively.
1, 19/01/11,
There was some mismatch between PVR flows and downlink flows related to them in this table in the previous version (11-09-0451r1), which requires an additional HD MPEG2-quality downlink flow related to HD MPEG2-quality PVR-use uplink flow.
Page 19: 2. Functional Requirements

JulySeptemberNovemberMay 2009March May January 2011July 2010 doc.: IEEE 802.11-09/00000451r1612151488123

3 BSSs: A, B and CBSS A is identical to the BSS in TGac scenario #3 with one AP and 13 associated STAsBSS B is an 802.11ac BSS with one AP and 3 associated STAsBSS C is lower 40MHz 802.11n BSS with one AP and 3 associated STAs

Each AP is source and sink for its associated STAsSpectrum positions for BSSs A, B, and C in Scenario #4 is shown in Fig. 1.

40MHz 40MHz

Spectrum of BSS A (11ac , 80MHz)

Spectrum of BSS B(11ac , 80MHz)Spectrum of

BSS C(11n , 40MHz)

frequency

Primary Channel of BSS C

(lower channel)

80MHz

20MHz

Figure 1: Spectrum positions for BSSs A, B, and C (Case 1).

Traffic from AP to STAsCompressed video, Internet file, Internet streaming video, MP3 audio, VoIP

Traffic from STAs to APCompressed video, VoD control channel, video console, Internet entertainment, VoIP

Traffic STAs to STAsLocal file transfer, video phone, controller to console, compressed video, content download

PHY channel for each link within a BSS or between BSSsChannel model type applied : Model C for BSS A and BSS B. TGn Model C for BSS C.Channel model type for link between different BSSs: Model C between BSS A and BSS B. TGn Model C between BSS C and BSS A.

Channel model break point between LOS and NLOS: unchanged from 802.11nShadowing term is set to TBD dB.

In 802.11n channel model document [8], shadow fading std. dev. is specified for each channel model between 3dB and 6dB at page 7. But, in 802.11n usage model document [3], shadowing term applied to all the 802.11n simulation scenarios is set to 0dB for generating a channel realization at page 22.

PHY channel for each link between BSSChannel model break point between LOS and NLOS: unchanged from 802.11n

Locations of stationsLocations for BSS A are unchagend from TGac scenario #3.Relative locations for BSS B are taken from TGac scenario #3 that all STAs except for STA1, STA4, and STA10 are deleted and re-numbered to STA 15, STA 16 and STA17. Locations of BSS B are translated by (xb, yb) = (40,0) from those of BSS A. Location for BSS B are listed in Table 67. Relative locations for BSS C are taken from TGac scenario #3 that all STAs except for STA1, STA4, and STA10 are deleted and re-numbered to STA 18, STA 19 and STA20. Locations for BSS C are translated by (xc, yc) = (-40,0) from those of BSS A. Location for BSS C are listed in Table 78.

Submission page 19 Peter (Ralink) and Minho (ETRI)

Minho_v11, 19/01/11,
Shadowing term is set to 0dB as in 802.11n simulation to reduce a burden of simulation complexity.
Page 20: 2. Functional Requirements

JulySeptemberNovemberMay 2009March May January 2011July 2010 doc.: IEEE 802.11-09/00000451r1612151488123

Walls: TBD.Room walls are introduced at x= -39 and x= 41. Attenuation factor of each room wall is set to 3 dB.Attenuation factor of each outside wall is set to 10 dB.

Meet requirements specified in PLR and Max. Delay per each flowTotal throughput conditionIt is available to offer infinite load for this scenario with TCP flows.

Table 6. Flows at BSS A in scenario #4

Flow No.

STAs(Source/Sink)

Source Location(meters)

Sink Location(meters)

Channel Model

Application(Forward Traffice / Backward Traffic)

Application Load (Mbps)(Forward / Backward)

Rate Distribution(Forward / Backward)

MSDU Size (B)(Forward / Backward)

Max. Delay (ms)(Forward / Backward)

Max. PLR(Forward / Backward)

1 AP / STA1 (0,0) (0,5) CBlu-rayTM

/ control channel 50.00 / 0.06

Constant, UDP / Constant UDP 1500 / 64 20 / 100  10^-7 / 10^-2

2note

STA7 / STA2 (7,-7) (-10,-10) CHD MPEG2 / control channel 20.00 / 0.06

Constant UDP / Constant UDP 1500 / 64 20 / 1003x10^-7 / 10^-2

3 note

AP / STA3 (0,0) (5,0) CBlu-rayTM

/ control channel 50.00 / 0.06

Constant, UDP / Constant UDP 1500 / 64 20 / 100  10^-7 / 10^-2

4 note

STA9/ STA 4 (0,-10) (-7,7) CBlu-rayTM

/ control channel 50.00 / 0.06

Constant, UDP / Constant UDP 1500 / 64 20 / 100  10^-7 / 10^-2

5 AP / STA4 (0,0) (-7,7) CInternet file / clicking on web link

Max. 10Mbps /

0.256TCP / TCP 300 / 64 Inf. / Inf.  N/A / N/A

6 AP / STA10 (0,0) (10,10) C

HD MPEG2 / video console + Internet entertainment 20.00 / 1.00

Constant UDP / Constant UDP 1500 / 512 20 / 503x10^-7 / 10^-4

7 AP / STA11 (0,0) (10,5) C MP3 audio 0.13 / UDP 418 200 10^-4

8STA11/STA10 (10,5) (10,10) C Controller to Console 0.50Constant, UDP 50 16 10^-4

9 AP / STA12 (0,0) (20,0) C VoIP / VoIP 0.096 / 0.096UDP / UDP 120 / 120 30 / 305% / 5%10 AP / STA13 (0,0) (0,20) C VoIP / VoIP 0.096 / 0.096UDP / UDP 120 / 120 30 / 305% / 5%11 AP / STA14 (0,0) (0,-20) C VoIP / VoIP 0.096 / 0.096UDP / UDP 120 / 120 30 / 305% / 5%

12STA4 / STA10  (-7,7)  (10,10) C Local file transfer Max. 1Gbps TCP 300 Inf.  N/A

13 STA5 / STA6 (-15,0) (0,-15) CVideo Phone / Video Phone 0.50 / 0.50

Constant, UDP / Constant UDP 512 / 512 100 / 100  10^-2 / 10^-2

Total ThroughputNote) Display/video flows are specified as logical links so that they may either be simulated as direct link setup or relay via the AP. Note) Logical link in this scenario can be seen with topology in Support document.

Table 67. Flows at BSS B in scenario #4

Flow No.

STAs(Source/Sink)

Source Location(meters)

Sink Location(meters)

Channel Model

Application(Forward Traffice / Backward Traffic)

Application Load (Mbps)(Forward / Backward)

Rate Distribution(Forward / Backward)

MSDU Size (B)(Forward / Backward)

Max. Delay (ms)(Forward / Backward)

Max. PLR(Forward / Backward)

14AP B / STA15 (xb,yb) (xb,5+yb) C

Blu-rayTM

/ control channel 50.00 / 0.06

Constant, UDP / Constant UDP 1500 / 64 20 / 100  10^-7 / 10^-2

15STA16 / STA17

 (-7+xb, 7+yb)

 (10+xb,10+yb) C Local file transfer Max. 1Gbps TCP 1500 Inf.  N/A

Total Throughput

Table 78. Flows at BSS C in scenario #4 Flow No.

STAs(Source/Sink)

Source Location(meters)

Sink Location(meters)

Channel Model

Application(Forward Traffice / Backward Traffic)

Application Load (Mbps)(Forward /

Rate Distribution(Forward / Backward)

MSDU Size (B)(Forward /

Max. Delay (ms)(Forward /

Max. PLR(Forward /

Submission page 20 Peter (Ralink) and Minho (ETRI)

Minho_v10, 19/01/11,
This flows is changed from LC-video service to Blu-ray service to make this scenario not be saturated by NTT’s suggestion. (2010.01.15)
Minho_v4, 19/01/11,
We added two clauses in 4.4 comparison critera instead of insertion of an additional column specifying the number of antennas of STA in table 5 and table 6. There modifications were suggested by Robert (Intel), VK (Qualcomm) and Hemanth (Qualcomm) after TGac session discussions on July 14.
1, 19/01/11,
TCP flows can have ‘infinite’ load or some very large number (say 1Gbps). Matt at Broadcom, Robert and Michelle at Intel suggested that it is more applicable to use a specific number that is known to be larger than the achievable rate rather than just infinite. Then, max. 10Mbps and max. 1Gbps is picked for Internet file transfer and local file transfer, respectively.
1, 19/01/11,
TCP flows can have ‘infinite’ load or some very large number (say 1Gbps). Matt at Broadcom, Robert and Michelle at Intel suggested that it is more applicable to use a specific number that is known to be larger than the achievable rate rather than just infinite. Then, max. 10Mbps and max. 1Gbps is picked for Internet file transfer and local file transfer, respectively.
정민호, 19/01/11,
It is desirable that TCP file transfer speed can be infinite offered load to check the system capacity.
Minho_v4, 19/01/11,
Minho_v10, 19/01/11,
This value is based on a separate supporting document. (tgac-supporting-document-for-wall-penetration-loss.ppt). I will present this supporting material in detail in COEX adhoc group session during LA meeting (2010.01).
Minho_v16, 19/01/11,
This value is based upon a separate supporting document. (10/0078r1, tgac-supporting-document-for-wall-penetration-loss.ppt)
Minho_v16, 19/01/11,
This value is based upon a separate supporting document. (10/0078r1, tgac-supporting-document-for-wall-penetration-loss.ppt)
Minho_v10, 19/01/11,
This value is based upon a separate supporting document. (tgac-supporting-document-for-wall-penetration-loss.ppt). I will present this supporting material in detail in COEX adhoc group session during LA meeting (2010.01)
Page 21: 2. Functional Requirements

JulySeptemberNovemberMay 2009March May January 2011July 2010 doc.: IEEE 802.11-09/00000451r1612151488123

Backward) Backward) Backward) Backward)

16AP C / STA18 (xc,yc) (xc,5+yc) C

HD-MPEG2 / VoD control channel 20/0.06

Constant UDP / Constant UDP 1500/64 20/100  3x10^-7 / 10^-2

17STA19 / STA20

(-7+xc, 77+yc)

(10+xc, 10+yc) C Content download Max. 10MbpsTCP 1500 Inf. N/A

Total Throughput

0-20-40-60 604020 x-20

20

0

y

BSS A BSS BBSS C

APSTA

STA 18STA 19STA 20

STA 15STA 16

STA 17

room walloutside wall

STA 1

STA 2STA 7

STA 5

STA 4STA 10

STA 11

STA 12

STA 13

STA 9

STA 6

STA 14

AP STA 3

Figure 2: AP and STA locations for scenario #4.

Note) dotted lines and solid lines denote room walls and outside walls, respectively.

4 . 3 4 Enterprise Network (scenario #46)

4.3.1 Enterprise Network without OBSS (scenario #54)

Test case to demonstrate enterprise network application with large number of flows (over 3040).This scenario is derived from scenario #4 defind in 802.11n usage model document.

2131 stationsOne TGac AP is source and sink.2030 STAs are souces and sinks.

Traffic from AP to STAsInternet file, video conferencing, Internet streaming video + MP3, local file transferVoIP

Traffic from STAs to APClicking on web linkClick, file upload, video conferencing, VoIP

PHY channel for each linkChannel model type applied : TBModel DD

Only channel model D’s or mixing D’s and B’s for more realistic scenarioChannel model break point between LOS and NLOS : unchanged from

802.11n(unchanged from 802.11n scenarios)

Submission page 21 Peter (Ralink) and Minho (ETRI)

정민호, 19/01/11,
It may be unchanged from the method used in 802.11n scenarios. Distance between STAs can be used to select between LOS and NLOS according to the breakpoint distance defined in 802.11n channel model document [8]. e.g.) 5 meters for model B, 5 meter for model C and 10 meters for model D.
정민호, 19/01/11,
Both channel model type applied and whether mixing of multiple channel models are TBD. Using channel model D or mixing model C and D seems realistic for this scenario.
정민호, 19/01/11,
Some of the STAs as mobile devices may be chosen later if TGac agrees on it. Such changes would make the scenario an ideal test case for 11ac operation with high throughput demands, large number of STAs and capability to serve mobile clients.
Page 22: 2. Functional Requirements

JulySeptemberNovemberMay 2009March May January 2011July 2010 doc.: IEEE 802.11-09/00000451r1612151488123

Distance between STAs can be used to select between LOS and NLOS according to the breakpoint distance defined in 802.11n channel model document [8].e.g.) 5 meters for model B and 10 meters for model D

Shadowing term is TBD 0dB (unchanged from 802.11n scenarios)In 802.11n channel model document [8], shadow fading std. dev. is specified for each channel model between 3dB and 6dB at page 7.But in 802.11n usage model document [3], shadowing term applied to all the 802.11n simulation scenarios is set to 0dB for generating a channel realization at page 22.

Locations of stationsFixed lLocations are (unchagend from 802.11n scenario #4, excepting that STAs 3, 6, 9, … , 30 are deleted (see Figure 1) and the surviving STAs are not renumbered.)

Meet requirements specified in PLR and Max. Delay per each flowTotal throughput condition

It is available to offer infinite load for this scenario with TCP flows.

-10 -5 0 5 10

-10

-8

-6

-4

-2

0

2

4

6

8

10

1

2

3

4

5

6

7

8

9

10

11 12

13

14 15

16

17

18

19

20 21

22

23

24

25

26

27

28

29 30

11n STA locationsDeleted 11ac STA locations

Figure 13: STA locations for scenario #45.

Total throughput (minimum about 460740Mbps) is not a heavy burden compared to that of scenario #4 defined in 802.11n usage model document (about 460Mbps).

Table 789. Flows in scenario #54

.Flow No. Source

Source Location(meters) Sink

Sink Location(meters) Channel Application

Bit RateApplication Load (Mbps)

Rate Distribution

MSDU Size (B)

Max. Delay (ms)

Max. PLR

                         Downlink Flows                  

Submission page 22 Peter (Ralink) and Minho (ETRI)

정민호, 19/01/11,
It is not available to support 50Mbps for file transfer services for multi-user scenarios with legacy MAC from our TGn experience. Unchanged 30Mbps for each file transfer means that total throughput will be about 460Mbps, which is the same to that of scenario #4 in TGn. In TGn system-level simulations, scenario #4 is not frequently used because it has quite a heavy burden compared to TGn capacity. Now, we can activate these in TGac consideration.
Page 23: 2. Functional Requirements

JulySeptemberNovemberMay 2009March May January 2011July 2010 doc.: IEEE 802.11-09/00000451r1612151488123

 1 AP (0,0) STA1 (5,-9..5) D Internet fileMinimum 1.00Max. 10Mbps TCP 300 Inf.   N/A

 2 AP (0,0) STA2 (3..5,7..5) D Internet fileMinimum 1.00Max. 10Mbps TCP 300 Inf.   N/A

 3 AP (0,0) STA3 (7..5,-9..5) D Internet fileMinimum 1.00Max. 10Mbps TCP 300 Inf.   N/A

 4 AP (0,0) STA4(-4.5-4,0..5) D Internet file

Minimum 1.00Max. 10Mbps TCP 300 Inf.   N/A

 5 AP (0,0) STA5 (-1..5,6) D Internet fileMinimum 1.00Max. 10Mbps TCP 300 Inf.   N/A

 6 AP (0,0) STA6 (-5..5,4..5) D

Internet file, downloading large email attachments

Minimum 10.00Max. 10Mbps TCP 300 Inf.   N/A

 7 AP (0,0) STA7 (-9,-5) D Video conferencing 1.00Constant, UDP 512 100   10^-4

 8 AP (0,0) STA8 (-8..5,8..5) D Video conferencing 1.00Constant, UDP 512 100   10^-4

 9 AP (0,0) STA9 (7,-7..5) DInternet Streaming video + MP3 audio 2.00UDP 512 200 10^-4 

 10 AP (0,0) STA10 (-3,0..5) DInternet Streaming video + MP3 audio 2.00UDP 512 200 10^-4 

 11 AP (0,0) STA11 (-0..5,8) D Local File transfer

Minimum 30Mbps50.00

Max. 1Gbps TCP 1500 Inf.N/A 

 12 AP (0,0) STA12 (7,7) D Local File transfer

Minimum 30Mbps 50.00

Max. 1Gbps TCP 1500 Inf.N/A 

 13 AP (0,0) STA13 (-4,-4) D Local File transfer

Minimum 30Mbps 50.00

Max. 1Gbps TCP 1500 Inf.N/A 

 14 AP (0,0) STA14 (7..5,-1) D Local File transfer

Minimum 30Mbps 50.00

Max. 1Gbps TCP 1500 Inf.N/A 

 15 AP (0,0) STA15 (3,-0..5) D Local File transfer

Minimum 30Mbps 50.00

Max. 1Gbps TCP 1500 Inf.N/A 

 16 AP (0,0) STA16 (8,-6) D Local File transfer

Minimum 30Mbps 50.00

Max. 1Gbps TCP 1500 Inf.N/A 

 17 AP (0,0) STA17 (0,-7..5) D Local File transfer

Minimum 30Mbps 50.00

Max. 1Gbps TCP 1500 Inf.N/A 

 18 AP (0,0) STA18 (10,0..5) D Local File transfer

Minimum 30Mbps 50.00

Max. 1Gbps TCP 1500 Inf.N/A 

 19 AP (0,0) STA19(-2..5,-4..5) D Local File transfer

Minimum 30Mbps 50.00

Max. 1Gbps TCP 1500 Inf.N/A 

 20 AP (0,0) STA20 (0..5,-2) D Local File transfer

M inimum 30Mbps 50.00

Max. 1Gbps TCP 1500 Inf.N/A 

 21 AP (0,0) STA25 (3..5,-5) D VoIP 0.10Constant, UDP 120 305% 

 22 AP (0,0) STA26 (9,9..5) D VoIP 0.10Constant, UDP 120 305% 

 23 AP (0,0) STA27 (-6,2..5) D VoIP 0.10Constant, UDP 120 305% 

 24 AP (0,0) STA28 (-8,-5..5) D VoIP 0.10Constant, UDP 120 305% 

 25 AP (0,0) STA29 (1.5,3..5) D VoIP 0.10Constant, UDP 120 305% 

 26 AP (0,0) STA30 (9..5,3..5) D VoIP 0.10Constant, UDP 120 305% 

Flow No.

Source Source Location

Sink Sink Location

Application Application LoadBit Rate

Rate Distribution

MSDU Size (B)

Max Delay

PLR

Submission page 23 Peter (Ralink) and Minho (ETRI)

1, 19/01/11,
TCP flows can have ‘infinite’ load or some very large number (say 1Gbps). Matt at Broadcom, Robert and Michelle at Intel suggested that it is more applicable to use a specific number that is known to be larger than the achievable rate rather than just infinite. Then, max. 10Mbps and max. 1Gbps is picked for Internet file transfer and local file transfer, respectively.
1, 19/01/11,
TCP flows can have ‘infinite’ load or some very large number (say 1Gbps). Matt at Broadcom, Robert and Michelle at Intel suggested that it is more applicable to use a specific number that is known to be larger than the achievable rate rather than just infinite. Then, max. 10Mbps and max. 1Gbps is picked for Internet file transfer and local file transfer, respectively.
Page 24: 2. Functional Requirements

JulySeptemberNovemberMay 2009March May January 2011July 2010 doc.: IEEE 802.11-09/00000451r1612151488123

(meters) (meters) (Mbps) (ms)  Uplink Flows                

 27 STA1 (5,-9..5) AP (0,0) DClicking on web linkClick 0.256 TCP 64 Inf. N/A 

 28 STA2 (3..5,7..5) AP (0,0) DClicking on web linkClick 0.256 TCP 64 Inf. N/A 

 29 STA3 (7..5,-9..5) AP (0,0) DClicking on web linkClick 0.256 TCP 64 Inf. N/A 

 30 STA4 (-4,.5,0..5) AP (0,0) D File UploadMinimum 5Max. 1Gbps TCP 1000 Inf. N/A 

 31 STA5 (-1..5,6) AP (0,0) D File UploadMinimum 10Max. 1Gbps TCP 1500 Inf. N/A 

 32 STA6 (-5..5,4..5) AP (0,0) DClicking on web linkClick 0.256 TCP 64 Inf. N/A 

 33 STA7 (-9,-5) AP (0,0) D Video conferencing 1.00Constant, UDP 512 100 10^-4 

 34 STA8 (-8..5,8..5) AP (0,0) D Video conferencing 1.00Constant, UDP 512 100 10^-4 

 35 STA21 (-6..5,-3) AP (0,0) D File Upload

Minimum 30Mbps 50.00

Max. 1Gbps TCP 1500 Inf. N/A 

 36 STA22 (0,-4..5) AP (0,0) D File Upload

Minimum 30Mbps 50.00

Max. 1Gbps TCP 1500 Inf. N/A 

 37 STA23 (-1..5,7) AP (0,0) D File Upload

Minimum 30Mbps 50.00

Max. 1Gbps TCP 1500 Inf. N/A 

 38 STA24 (3,2..5) AP (0,0) D File Upload

Minimum 30Mbps 50.00

Max. 1Gbps TCP 1500 Inf. N/A 

 39 STA25 (3..5,-5) AP (0,0) D VoIP 0.10Constant, UDP 120 30 5% 

 40 STA26 (9,9..5) AP (0,0) D VoIP 0.10Constant, UDP 120 30 5% 

41  STA27 (-6,2..5) AP (0,0) D VoIP 0.10Constant, UDP 120 30 5% 

 42 STA28 (-8,-5..5) AP (0,0) D VoIP 0.10Constant, UDP 120 30 5% 

 43 STA29 (1..5,3..5) AP (0,0) D VoIP 0.10Constant, UDP 120 30 5% 

 44 STA30 (9..5,3..5) AP (0,0) D VoIP 0.10Constant, UDP 120 30 5% 

Total Measured ThroughputThruput

Minimum 460.22Mbps 740.2

Note) Limited number of antennas for some devices are exemplary, to allow for proposal comparison.

Flow No. Source

Source Location(meters) Sink

Sink Location(meters) Channel Application

Application Load (Mbps)

Rate Distribution

MSDU Size (B)

Max. Delay (ms)

Max. PLR

                         Downlink Flows                  

 1 AP (0,0) STA1 (5,-9.5) D Internet file Max. 10MbpsTCP 300 Inf.   N/A

 2 AP (0,0) STA2 (3.5,7.5) D Internet file Max. 10MbpsTCP 300 Inf.   N/A

 3 AP (0,0) STA4 (-4.5,0.5) D Internet file Max. 10MbpsTCP 300 Inf.   N/A

 4 AP (0,0) STA5 (-1.5,6) D Internet file Max. 10MbpsTCP 300 Inf.   N/A

Submission page 24 Peter (Ralink) and Minho (ETRI)

Minho_v4, 19/01/11,
We added two clauses in 4.4 comparison critera instead of insertion of an additional column specifying the number of antennas of STA in table 5 and table 6. There modifications were suggested by Robert (Intel), VK (Qualcomm) and Hemanth (Qualcomm) after TGac session discussions on July 14.
1, 19/01/11,
TCP flows can have ‘infinite’ load or some very large number (say 1Gbps). Matt at Broadcom, Robert and Michelle at Intel suggested that it is more applicable to use a specific number that is known to be larger than the achievable rate rather than just infinite. Then, max. 10Mbps and max. 1Gbps is picked for Internet file transfer and local file transfer, respectively.
1, 19/01/11,
TCP flows can have ‘infinite’ load or some very large number (say 1Gbps). Matt at Broadcom, Robert and Michelle at Intel suggested that it is more applicable to use a specific number that is known to be larger than the achievable rate rather than just infinite. Then, max. 10Mbps and max. 1Gbps is picked for Internet file transfer and local file transfer, respectively.
Page 25: 2. Functional Requirements

JulySeptemberNovemberMay 2009March May January 2011July 2010 doc.: IEEE 802.11-09/00000451r1612151488123

 5 AP (0,0) STA7 (-9,-5) DVideo conferencing 1.00

Constant, UDP 512 100   10^-4

 6 AP (0,0) STA8 (-8.5,8.5) DVideo conferencing 1.00

Constant, UDP 512 100   10^-4

 7 AP (0,0) STA10 (-3,0.5) D

Internet Streaming video + MP3 audio 2.00UDP 512 200 10^-4 

 8 AP (0,0) STA11 (-0.5,8) DLocal File transfer Max. 1GbpsTCP 1500 Inf.N/A 

 9 AP (0,0) STA13 (-4,-4) DLocal File transfer Max. 1GbpsTCP 1500 Inf.N/A 

 10 AP (0,0) STA14 (7.5,-1) DLocal File transfer Max. 1GbpsTCP 1500 Inf.N/A 

 11 AP (0,0) STA16 (8,-6) DLocal File transfer Max. 1GbpsTCP 1500 Inf.N/A 

 12 AP (0,0) STA17 (0,-7.5) DLocal File transfer Max. 1GbpsTCP 1500 Inf.N/A 

 13 AP (0,0) STA19 (-2.5,-4.5) DLocal File transfer Max. 1GbpsTCP 1500 Inf.N/A 

 14 AP (0,0) STA20 (0.5,-2) DLocal File transfer Max. 1GbpsTCP 1500 Inf.N/A 

 15 AP (0,0) STA25 (3.5,-5) D VoIP 0.10Constant, UDP 120 305% 

 16 AP (0,0) STA26 (9,9.5) D VoIP 0.10Constant, UDP 120 305% 

 17 AP (0,0) STA28 (-8,-5.5) D VoIP 0.10Constant, UDP 120 305% 

 18 AP (0,0) STA29 (1.5,3.5) D VoIP 0.10Constant, UDP 120 305% 

Flow No. Source

Source Location(meters) Sink

Sink Location(meters) Application

Application Load (Mbps)

Rate Distribution

MSDU Size (B)

Max Delay (ms) PLR

  Uplink Flows                

 19 STA1 (5,-9.5) AP (0,0) DClicking on web link 0.256 TCP 64 Inf. N/A 

 20 STA2 (3.5,7.5) AP (0,0) DClicking on web link 0.256 TCP 64 Inf. N/A 

 21 STA4 (-4.5,0.5) AP (0,0) D File Upload Max. 1Gbps TCP 1000 Inf. N/A 

 22 STA5 (-1.5,6) AP (0,0) D File Upload Max. 1Gbps TCP 1500 Inf. N/A 

 23 STA7 (-9,-5) AP (0,0) DVideo conferencing 1.00

Constant, UDP 512 100 10^-4 

 24 STA8 (-8.5,8.5) AP (0,0) DVideo conferencing 1.00

Constant, UDP 512 100 10^-4 

 25 STA22 (0,-4.5) AP (0,0) D File Upload Max. 1Gbps TCP 1500 Inf. N/A 

 26 STA23 (-1.5,7) AP (0,0) D File Upload Max. 1Gbps TCP 1500 Inf. N/A 

 27 STA25 (3.5,-5) AP (0,0) D VoIP 0.10Constant, UDP 120 30 5% 

 28 STA26 (9,9.5) AP (0,0) D VoIP 0.10Constant, UDP 120 30 5% 

 29 STA28 (-8,-5.5) AP (0,0) D VoIP 0.10Constant, UDP 120 30 5% 

 30 STA29 (1.5,3.5) AP (0,0) D VoIP 0.10Constant, UDP 120 30 5% 

Total Measured Throughput

Submission page 25 Peter (Ralink) and Minho (ETRI)

Page 26: 2. Functional Requirements

JulySeptemberNovemberMay 2009March May January 2011July 2010 doc.: IEEE 802.11-09/00000451r1612151488123

4.3.2 Enterprise Network with OBSS (scenario #56)

Test case to demonstrate enterprise network application with large number of flows and OBSS.This scenario is derived from scenario #4 defined in 802.11n usage model document.

3 BSSs: A, B and CBSS A is identical to the BSS in 802.11ac scenario #4 with one AP and 20 associated STAsBSS B is an 802.11ac BSS using the same bandwidth as BSS A with one AP and 5 associated STAsBSS C is a 20/40MHz 802.11n BSS with one AP and 5 associated STAs

Each AP is source and sink for its associated STAsTraffic from AP to STAs

Internet file, video conferencing, Internet streaming video + MP3, local file transferVoIP

Traffic from STAs to APClicking on web link, file upload, video conferencing, VoIP

PHY channel for each linkChannel model type applied: Model D

Channel model break point between LOS and NLOS : unchanged from 802.11n Shadowing term is TBD dB

In 802.11n channel model document [8], shadow fading std. dev. is specified for each channel model between 3dB and 6dB at page 7.But in 802.11n usage model document [3], shadowing term applied to all the 802.11n simulation scenarios is set to 0dB for generating a channel realization at page 22.

Locations of stations (see Figure )Locations for BSS A are unchanged from 802.11n scenario #4, excepting that STAs 3,6,9, … 30 are deleted (i.e. BSS A is identical to scenario #4)Locations for BSS B are taken from 802.11n scenario #4, with all STAs except 3,9,15,… 27 deleted and the AP and surviving STAs translated by (xb,yb) = (40,20).Locations for BSS C are taken from 802.11n scenario #4, with all STAs except 6,1218, … 30 deleted and the AP and surviving STAs translated by (xc,yc) = (-40,-20).

Bandwidth sensitivityIf BSS A is 40 MHz, then BSS C is deleted, leaving BSSs A and B.If BSS A is 80 MHz, then the scenario includes BSSs A, B and C

Parameters used by STAs within the BSS in 802.11ac scenario #4 should be reused in this scenarioMeet requirements specified in PLR and Max. Delay per each flowTotal throughput condition

It is available to offer infinite load for this scenario with TCP flows.

Submission page 26 Peter (Ralink) and Minho (ETRI)

Page 27: 2. Functional Requirements

JulySeptemberNovemberMay 2009March May January 2011July 2010 doc.: IEEE 802.11-09/00000451r1612151488123

-50 -40 -30 -20 -10 0 10 20 30 40 50-30

-20

-10

0

10

20

30

1

4

7

10

13 16

19 22 25 28

2 5

8 11

14

17

20

23 26

29

3 9

15 21

27

6 12

18 24 30

BSS A STA locationsBSS B STA locations assuming (xb,yb)=(40,20)BSS C STA locations assuming (xb,yb)=(-40,-20)

Figure 24: STA locations for scenario #65.

Table 8910. Flows in scenario #65

Flow No. Source

Source Location(meters) Sink

Sink Location(meters) Channel Application

Application Load (Mbps)

Rate Distribution

MSDU Size (B)

Max. Delay (ms)

Max. PLR

                        Downlink Flows in BSS A

 1 AP A (0,0) STA1 (5,-9.5) D Internet file Max. 10MbpsTCP 300 Inf.   N/A

 2 AP A (0,0) STA2 (3.5,7.5) D Internet file Max. 10MbpsTCP 300 Inf.   N/A

 3 AP A (0,0) STA4 (-4.5,0.5) D Internet file Max. 10MbpsTCP 300 Inf.   N/A

 4 AP A (0,0) STA5 (-1.5,6) D Internet file Max. 10MbpsTCP 300 Inf.   N/A

 5 AP A (0,0) STA7 (-9,-5) DVideo conferencing 1.00

Constant, UDP 512 100   10^-4

 6 AP A (0,0) STA8 (-8.5,8.5) DVideo conferencing 1.00

Constant, UDP 512 100   10^-4

 7 AP A (0,0) STA10 (-3,0.5) D

Internet Streaming video + MP3 audio 2.00UDP 512 200 10^-4 

 8 AP A (0,0) STA11 (-0.5,8) DLocal File transfer Max. 1GbpsTCP 1500 Inf.N/A 

 9 AP A (0,0) STA13 (-4,-4) DLocal File transfer Max. 1GbpsTCP 1500 Inf.N/A 

 10 AP A (0,0) STA14 (7.5,-1) DLocal File transfer Max. 1GbpsTCP 1500 Inf.N/A 

 11 AP A (0,0) STA16 (8,-6) DLocal File transfer Max. 1GbpsTCP 1500 Inf.N/A 

Submission page 27 Peter (Ralink) and Minho (ETRI)

Page 28: 2. Functional Requirements

JulySeptemberNovemberMay 2009March May January 2011July 2010 doc.: IEEE 802.11-09/00000451r1612151488123

 12 AP A (0,0) STA17 (0,-7.5) DLocal File transfer Max. 1GbpsTCP 1500 Inf.N/A 

 13 AP A (0,0) STA19 (-2.5,-4.5) DLocal File transfer Max. 1GbpsTCP 1500 Inf.N/A 

 14 AP A (0,0) STA20 (0.5,-2) DLocal File transfer Max. 1GbpsTCP 1500 Inf.N/A 

 15 AP A (0,0) STA25 (3.5,-5) D VoIP 0.10Constant, UDP 120 305% 

 16 AP A (0,0) STA26 (9,9.5) D VoIP 0.10Constant, UDP 120 305% 

 17 AP A (0,0) STA28 (-8,-5.5) D VoIP 0.10Constant, UDP 120 305% 

 18 AP A (0,0) STA29 (1.5,3.5) D VoIP 0.10Constant, UDP 120 305% 

Flow No. Source

Source Location(meters) Sink

Sink Location(meters) Application

Application Load (Mbps)

Rate Distribution

MSDU Size (B)

Max Delay (ms) PLR

 Uplink Flows in BSS A

 19 STA1 (5,-9.5) AP A (0,0) DClicking on web link 0.256TCP 64 Inf. N/A 

 20 STA2 (3.5,7.5) AP A (0,0) DClicking on web link 0.256TCP 64 Inf. N/A 

 21 STA4 (-4.5,0.5) AP A (0,0) D File Upload Max. 1Gbps TCP 1000 Inf. N/A 

 22 STA5 (-1.5,6) AP A (0,0) D File Upload Max. 1Gbps TCP 1500 Inf. N/A 

 23 STA7 (-9,-5) AP A (0,0) DVideo conferencing 1.00

Constant, UDP 512 100  10^-4 

 24 STA8 (-8.5,8.5) AP A (0,0) DVideo conferencing 1.00

Constant, UDP 512 100  10^-4 

 25 STA22 (0,-4.5) AP A (0,0) D File Upload Max. 1Gbps TCP 1500 Inf. N/A 

 26 STA23 (-1.5,7) AP A (0,0) D File Upload Max. 1Gbps TCP 1500 Inf. N/A 

 27 STA25 (3.5,-5) AP A (0,0) D VoIP 0.10Constant, UDP 120 30  5% 

 28 STA26 (9,9.5) AP A (0,0) D VoIP 0.10Constant, UDP 120 30  5% 

 29 STA28 (-8,-5.5) AP A (0,0) D VoIP 0.10Constant, UDP 120 30  5% 

 30 STA29 (1.5,3.5) AP A (0,0) D VoIP 0.10Constant, UDP 120 30  5% 

 Downlink Flows in BSS B

 31 AP B (xb,xb) STA3 (7.5+xb, -9.5+yb) D Internet file Max. 10Mbps TCP 300 Inf.   N/A

 32 AP B (xb,xb) STA9 (7+xb, -7.5+yb) D

Internet Streaming video + MP3 audio 2.00UDP 512 200  10^-4 

 33 AP B (xb,xb) STA15 (3+xb, -0.5+yb) DLocal File transfer Max. 1Gbps TCP 1500 Inf. N/A 

 34 AP B (xb,xb) STA27 (-6+xb, 2.5+yb) D VoIP 0.10Constant, UDP 120 30 5% 

 Uplink Flows in BSS B

 35 STA3 (7.5+xb, -9.5+yb) AP B (xb,xb) DClicking on web link 0.256TCP 64 Inf. N/A 

Submission page 28 Peter (Ralink) and Minho (ETRI)

Page 29: 2. Functional Requirements

JulySeptemberNovemberMay 2009March May January 2011July 2010 doc.: IEEE 802.11-09/00000451r1612151488123

 36 STA21 (-6.5+xb, -3+yb) AP B (xb,xb) D File Upload Max. 1Gbps TCP 1500 Inf. N/A 

37 STA27 (-6+xb, 2.5+yb) AP B (xb,xb) D VoIP 0.10Constant, UDP 120 30  5% 

 Downlink Flows in BSS C

 38 AP C (xc,yc) STA6 (-5.5+xc,4.5+yc) D

Internet file, downloading large email attachments Max. 10Mbps TCP 300 Inf.   N/A

 39 AP C (xc,yc) STA12 (7+xc,7+yc) DLocal File transfer Max. 1Gbps TCP 1500 Inf. N/A 

 40 AP C (xc,yc) STA18 (10+xc,0.5+yc) DLocal File transfer Max. 1Gbps TCP 1500 Inf. N/A 

 41 AP C (xc,yc) STA30 (9.5+xc,3.5+yc) D VoIP 0.10Constant, UDP 120 30 5% 

 Uplink Flows in BSS C

 42 STA6 (-5.5+xc,4.5+yc) AP C (xc,yc) DClicking on web link 0.256TCP 64 Inf. N/A 

 43 STA24 (3+xc,2.5+yc) AP C (xc,yc) D File Upload Max. 1Gbps TCP 1500 Inf. N/A 

 44 STA30 (9.5+xc,3.5+yc) AP C (xc,yc) D VoIP 0.10Constant, UDP 120 30  5% 

Total Measured Throughput

4 . 5 4 Comparison Criteria

MAC SAP throughput (goodput)Aggregated throughput (downlink + uplink + STA-to-STA)Throughput of each flow in the simulation scenario

Packet Loss Rate for each flow in the simulation scenarioLost packets includePackets that exceed maximum latency requirementPackets that are dropped after exceeding maximum number of re-tries

Specify number of antennas for each STA used in the simulation scenarioSpecify number of 20 MHz channels used in the simulation scenario

Note) It is encouraged that TGac technology proposals describe its impact on OBSS TGac proposals shall explain how it meetssupports OBSS operation. requirement R12 (OBSS operation).

4 . 6 5 Results Presentation Format

e.g.) for scenario #3

Submission page 29 Peter (Ralink) and Minho (ETRI)

정민호, 19/01/11,
This was suggested by Yashusi at NTT during Montreal meeting in May 2009.
Minho_v3, 19/01/11,
This sentence is adopted after conference call discussions held on May 28. There is another example to use the expression 'encouraged' in documents on TGa comparison critera, as follows: In page 2 of TGa comparison criterai, In order to assess the implementation complexity of the proposal, the proposers should bring a description of the receiver structure used for obtaining the data. In case the complexity can be traded for performance, proposers are encouraged to present performance also with simplified receiver structures.
Minho_v8, 19/01/11,
This old statement has been replaced by adding new specific simulation scenatio with OBSS in previous chapter.
Minho_v4, 19/01/11,
We added these two in 4.4 comparison critera instead of insertion of an additional column specifying the number of antennas of STA in table 5 and table 6. There modifications were suggested by Robert (Intel), VK (Qualcomm) and Hemanth (Qualcomm) after TGac session discussions on July 14.
Page 30: 2. Functional Requirements

JulySeptemberNovemberMay 2009March May January 2011July 2010 doc.: IEEE 802.11-09/00000451r1612151488123

Table 9 8101. Results presentation format

Flow No.

STAs(Source/Sink)

Application(Forward Traffice / Backward Traffic)

Application Load (Mbps)(Forward / Backward)

Rate Distribution(Forward / Backward)

Max. Delay (ms)(Forward / Backward)

PLR(Forward / Backward)

Pass or Fail (Forward / Backward)

Latency Compliant (%) (Forward / Backward)

Measured Throughput (Mbps) (Forward / Backward)

1 AP / STA1

LC Video / VoD control channelBlu-rayTM

/ control channelLC Video / VoD control channel

150.00 / 0.0650.00 /

0.06150.00 / 0.06

Constant, UDP / Constant UDP 10 / 100

2note

STA7 / STA2HD MPEG2 / control channel 20.00 / 0.06

Constant UDP / Constant UDP 20 / 100

3 note

AP / STA3STA8 / STA3

Blu-rayTM

/ control channel 50.00 / 0.06

Constant, UDP / Constant UDP 20 / 100

4 note

STA9/ STA 4Blu-rayTM

/ control channel 50.00 / 0.06

Constant, UDP / Constant UDP 20 / 100

5 AP / STA4Internet file / clicking on web link

Max. 10Mbps /

0.256TCP / TCP Inf. / Inf.

6 AP / STA10

HD MPEG2 / video console + Internet entertainment 20.00 / 1.00

Constant UDP / Constant UDP 20 / 50

7 AP / STA11 MP3 audio 0.13 / UDP 2008 STA11/STA10 Controller to Console 0.50Constant, UDP 169 AP / STA12 VoIP / VoIP 0.096 / 0.096 UDP / UDP 30 / 3010 AP / STA13 VoIP / VoIP 0.096 / 0.096 UDP / UDP 30 / 3011 AP / STA14 VoIP / VoIP 0.096 / 0.096 UDP / UDP 30 / 30

12 STA4 / STA10 Local file transfer Max. 1Gbps TCP Inf.

13 STA5 / STA6Video Phone / Video Phone 0.50 / 0.50

Constant, UDP / Constant UDP 100 / 100

Total Given Throughput

Total Measured Throughput

Submission page 30 Peter (Ralink) and Minho (ETRI)

1, 19/01/11,
TCP flows can have ‘infinite’ load or some very large number (say 1Gbps). Matt at Broadcom, Robert and Michelle at Intel suggested that it is more applicable to use a specific number that is known to be larger than the achievable rate rather than just infinite. Then, max. 10Mbps and max. 1Gbps is picked for Internet file transfer and local file transfer, respectively.
1, 19/01/11,
TCP flows can have ‘infinite’ load or some very large number (say 1Gbps). Matt at Broadcom, Robert and Michelle at Intel suggested that it is more applicable to use a specific number that is known to be larger than the achievable rate rather than just infinite. Then, max. 10Mbps and max. 1Gbps is picked for Internet file transfer and local file transfer, respectively.
정민호, 19/01/11,
It is desirable that TCP file transfer speed can be infinite offered load to check the system capacity.
Page 31: 2. Functional Requirements

JulySeptemberNovemberMay 2009March May January 2011July 2010 doc.: IEEE 802.11-09/00000451r1612151488123

Flow No. Source Sink Application

Bit RateApplication Load (Mbps) Rate Distribution

Max Delay (ms) PLR Pass/Fail

Latency Compliant (%)

Measured Throughput (Mbps)

                     Downlink Flows           1 AP STA1 LC Video 150.00Constant, UDP 10      2 AP STA2 HD MPEG-2 20.00 Constant, UDP 2032 AP STA3 Blu-rayTM 50.00Constant, UDP 20      43 AP STA4 Blu-rayTM 50.00Constant, UDP 20      

54 AP STA4 Internet file

Minimum 1.00Max.

10Mbps TCP Inf.      

65 AP STA7VoD control channel 0.06Constant, UDP 100      

76 AP STA8VoD control channel 0.06Constant, UDP 100      

87 AP STA9VoD control channel 0.06Constant, UDP 100      

98 AP STA10

Internet Streaming video HD-MPEG2 2.0020.00 UDPConstant, UDP 20020      

109 AP STA11 MP3 audio 0.13UDP 200      11 AP STA12 VoIP 0.096 UDP 3012 AP STA13 VoIP 0.096 UDP 3013 AP STA14 VoIP 0.096 UDP 30                     Uplink Flows           

1410 STA1 APVoD control channel 0.06Constant, UDP 100      

15 STA2 AP control channel 0.06 Constant, UDP 100

1611 STA3 APVoD control channel 0.06Constant, UDP 100      

17 STA4 AP control channel 0.06 Constant, UDP 1001812 STA7 AP Blu-rayTM 50.00Constant, UDP 20      1913 STA8 AP Blu-rayTM 50.00Constant, UDP 20      2014 STA9 AP HD MPEG2 20.00Constant, UDP 20      

2115 STA10 AP

Video console + Internet entertainment 1.00Constant, UDP 50      

22 STA12 AP VoIP 0.096 UDP 30

23 STA13 AP VoIP 0.096 UDP 30

24 STA14 AP VoIP 0.096 UDP 30                     STA to STA Flows           

2516 STA4 STA10Local file transfer

Minimum 10.00Max.

1Gbps TCP Inf.      2617 STA5 STA6 Video Phone 0.50Constant, UDP 100      2718 STA6 STA5 Video Phone 0.50Constant, UDP 100      

2819 STA11 STA10Controller to Console 0.50Constant, UDP 16      Total Given ThroughputThruput

Minimum 385.93

Total Measured Thruput 0.00

Submission page 31 Peter (Ralink) and Minho (ETRI)

Page 32: 2. Functional Requirements

JulySeptemberNovemberMay 2009March May January 2011July 2010 doc.: IEEE 802.11-09/00000451r1612151488123

5 . Summary of Functional Requirements

Table 10 912. Summary of functional requirementsRequirementNumber

Description Requirement Statement

Status of Requirement

Notes (informative)

R1 Operational in 5 GHz

TGac devices shall operate in 5GHz frequency band.

R21 Maximum multi-STA throughput

Support at least 1 Gbps at the top of the MAC SAP. utilizing no more than 80MHz of channel bandwidth in 5GHz band

R32 Maximum single link throughput

Support 500 Mbps throughput at the top of the MAC SAP utilizing no more than 80MHz of channel bandwidth in 5GHz band

R4 Spectrum efficiency

In the highest throughput mode, TGac devices shall achieve a spectral efficiency of at least 7.5 bps/Hz for the PSDU. The TGac amendment shall demonstrate a mode of operation that achieves a spectral efficiency of at least 12 bps/Hz for the PSDU.

R5 Support 802.11 QoS Enhancements support

The proposal shall support the QoS enhancements of the IEEE802.11-2007 within an TGac STA.

R6 Control of support for legacy STA from TGac AP

A TGac AP can be configured to reject or accept associations from 802.11a/n STAs

Submission page 32 Peter (Ralink) and Minho (ETRI)

Page 33: 2. Functional Requirements

JulySeptemberNovemberMay 2009March May January 2011July 2010 doc.: IEEE 802.11-09/00000451r1612151488123

R73 802.11a backward compatibility

TGac devicesamendment shall provide ensure backward compatibility with IEEE802.11a devices operating in the 5 GHz frequency band. .

R84 802.11n backward compatibility

TGac devicesamendment shall provideensure backward compatibility with IEEE802.11n devices operating in the 5 GHz frequency band

R95 Coexistence with 802.11a/n devices operating in 5GHz

TGac amendmentdevices shall provide provide mechanisms to enable coexistence and spectrum sharing between TGac and legacy IEEE802.11a/n devices. with IEEE802.11a/n devices operating in the same frequency band.

R10 Support of mobile devices

TGac mobile devices are not required to support requirement R3 (500 Mbps). However, they shall demonstrate a mode of operation that achieves a minimum throughput of 100 Mbps as measured at their MAC SAPs

R11 Enhanced power saving

The TGac amendment shall provide an enhanced power saving mechanism that results in a lower

Submission page 33 Peter (Ralink) and Minho (ETRI)

Page 34: 2. Functional Requirements

JulySeptemberNovemberMay 2009March May January 2011July 2010 doc.: IEEE 802.11-09/00000451r1612151488123

power consumption than typical 802.11n devices.

R12 OBSS operation

TGac devices shall provide a mechanism to enable fair channel access and bandwidth sharing with other devices operating in OBSS.

R13610 Compliance to PAR

The proposal complies with the PAR and 5 Criteria [1].

Submission page 34 Peter (Ralink) and Minho (ETRI)

정민호, 19/01/11,
Allan at Samsung suggested “TGac shall provide support for enhanced power saving functionality to help reduce power consumption in mobile devices.”, which is similar to that of 802.16m at conference call on April 23. TGac agrees on need of more discussion about that including applicability of existing TGv standard to TGac.
Page 35: 2. Functional Requirements

JulySeptemberNovemberMay 2009March May January 2011July 2010 doc.: IEEE 802.11-09/00000451r1612151488123

6 . Support Documents

11-09-0838-0012-00ac-tgac-supporting-document-for-tgac-evaluation-methodology.ppt11-10-0078-01-00ac-supporting-document-for-wall-penetration-loss.ppt

Submission page 35 Peter (Ralink) and Minho (ETRI)

Page 36: 2. Functional Requirements

JulySeptemberNovemberMay 2009March May January 2011July 2010 doc.: IEEE 802.11-09/00000451r1612151488123

6 7 . References

1. 11-08-0807-04-0vht-below-6-ghz-par-nescom-form-plus-5cs2. 11-03-0813-13-000n-functional-requirements3. 11-03-0802-23-000n-usage-models4. 11-08-0307-01-0vht-on-the-feasibility-of-1gbps-for-various-mac-phy-architectures5. 11-08-0535-00-0vht-phy-and-mac-throughput-analysis-with-80-mhz-for-vht-below-6-ghz6. 11-09-0071-01-00ac-discussion-on-functional-requirements 7. 11-03-0814-31-000n-comparison-criteria8. 11-03-0940-04-000n-tgn-channel-models9. 11-09-0059-04-00ac-tgac-802.11ac-proposed-selection-procedure10. 11-09-0376-01-00ac-proposal-for-tgac-evaluation-methodology11. 11-09-0308-05812-00ac-tgac-channel-model-addendum-document12. 11-09-0161-02-00ac-802.11ac-usage-model-document13. 11-09-0980-01-00ac-change-edits-for-enterprise-simulation-scenario

Submission page 36 Peter (Ralink) and Minho (ETRI)