1. doc.: IEEE 802.11-09/0364r1 Submission March 11, 2009 JT Chen et al (Ralink Technology Corp.) Slide 1 Comments on AOA and AOD Selection for a Multi-User SDMA Network Date: 2009-3-11 Authors:

2. doc.: IEEE 802.11-09/0364r1 Submission March 11, 2009 JT Chen et al (Ralink Technology Corp.) Slide 2 Outline Problem Description Current Proposal What Need to be Randomized What NOT to be Averaged Over Deterministic AoA and AoD in Test Cases Conclusions Suggestions

3. doc.: IEEE 802.11-09/0364r1 Submission March 11, 2009 JT Chen et al (Ralink Technology Corp.) Slide 3 Problem Description In SDMA systems, multiple STAs are receive/transmit data streams simultaneously. Channel parameters of cluster AoA/AoD of each STA is crucial in deciding its degree of difficulties of effective transmit beam-forming at the AP. On which there is consensus –AoA/AoD should be different for different STAs –Reuse the AS of each transmit/receiver channel path clusters –Reuse the number of clusters and PDP of each cluster On which there is no consensus –Identical AoA/AoD offsets, or not, for different clusters in the channel to the same STA –AoA/AoD should be random, pseudo-random, or deterministic –The distribution of the AoA/AoD offsets, uniform distributed or whatever other distributed over what range –System performance should be averaged, or not, over the distribution of AoA/AoD offsets

4. doc.: IEEE 802.11-09/0364r1 Submission March 11, 2009 JT Chen et al (Ralink Technology Corp.) Slide 4 Identical AoA/AoD offsets, or not, for different clusters in the channel to the same STA Identical AoA/AoD should be random, pseudo-random, or deterministic Pseudo-random The distribution of the AoA/AoD offsets, uniform distributed or whatever other distributed over what range Uniform, over a range of Tx: Rx: System performance should be averaged, or not, over the distribution of AoA/AoD offsets It should Current Proposal

5. doc.: IEEE 802.11-09/0364r1 Submission March 11, 2009 JT Chen et al (Ralink Technology Corp.) Slide 5 Rotation is in sync among clusters of the same users, and/or among users Average over a very small set of network scenarios For example, it cannot test the scheduling algorithm taking advantage of multi-user diversity due to rank deficiency of the channels to some users, since all users enjoy full rank simultaneously Easily open to criticism from outside TGac –An imaginary channel, non-realistic –Lack of in-depth technical consideration Current Proposal, An Example – Channel D

6. doc.: IEEE 802.11-09/0364r1 Submission March 11, 2009 JT Chen et al (Ralink Technology Corp.) Slide 6 A set of parameters with different combinations of practical values will result in very different outcomes For example –Noise time samples in a communication system, Yes –Fading amplitude of multi-paths in a wireless channel, Yes –Error correction codebooks, No, not practical –Pseudo scrambling bits, No, same performance outcome –Raw data bits, Yes In extending from the SU 11n channel model to MU TGac channel model, what needs to randomized? –PDPs among multi-users, Probably Not –ASs among multi-users, Probably Not –Cluster AoAs/AoDs among multi-users, Certainly Yes What Need to be Randomized

7. doc.: IEEE 802.11-09/0364r1 Submission March 11, 2009 JT Chen et al (Ralink Technology Corp.) Slide 7 The control parameters that remain almost unchanged within the time/frequency/distance range defined by whatever user experience For example –Noise time samples in a communication system, Yes –Frequency selectivity or delay spread over a narrow-band communication link, No, not in the frequency range –Different Test-Cases, No –11n channel model A-F, No In extending from the SU 11n channel model to MU TGac channel model, what not to be averaged over? –Multi-user spatial correlation during a time period long enough to cause customer complaints whenever system performance is bad, Certainly No –Cluster AoAs/AoDs among multi-users, Certainly No In conclusion, Cluster AoAs/AoDs are parameters we should randomize, but not average over. What NOT to be Averaged Over

8. doc.: IEEE 802.11-09/0364r1 Submission March 11, 2009 JT Chen et al (Ralink Technology Corp.) Slide 8 Deterministic AoA and AoD in Test Cases We propose to adopt different AoAs/AoDs values in different Test Cases –Initial randomness to reflect the specific purpose of the Test Case to test against some system design gains. –Remain deterministic throughout the test case which a performance outcome is exclusively reported for. The assignment of the AoAs/AoDs should –Be based on the Usage Models so as to remain practical –Covers typically-simple network scenarios to assure its feasibility –Covers typically-tough network scenarios to distinguish the quality of different algorithms, and to assure its robustness

9. doc.: IEEE 802.11-09/0364r1 Submission March 11, 2009 JT Chen et al (Ralink Technology Corp.) Slide 9 Modification in MATLAB Code Parameter definition –In example_MIMO.m, define AoD_Offset(transmitter_index, cluster_index) AoA_Offset(receiver_index, cluster_index) for all the transmitters and all the receivers. Call IEEE_802_11_Cases.m with one row of either matrix each time. –In IEEE_802_11_Cases.m, define AoD_Offset(cluster_index) and AoA_Offset(cluster_index) to obtain the corresponding parameters MATLAB Code Segment in will get MIMO channels

10. doc.: IEEE 802.11-09/0364r1 Submission March 11, 2009 JT Chen et al (Ralink Technology Corp.) Slide 10 Conclusions It is too early for a first-cut document on TGac channel model before –We look into the channel characteristics that can test the merit of outstanding OFDMA/SDMA algorithms on different aspects –We get a clear sense of direction on what we are really doing Reversal of incorrect decisions made in the early stage could suck in a lot of research efforts and is certainly painful

11. doc.: IEEE 802.11-09/0364r1 Submission March 11, 2009 JT Chen et al (Ralink Technology Corp.) Slide 11 Suggestions Before the next session, everyone is welcomed to suggest AoDs/AoAs plus whatever other necessary parameters in test cases which favor the algorithms you are currently developing We then –take the common part getting rid of the redundance, –remove the impractical part, and then –forge them into a document to cover parameters describing all the test cases