1 / 11

Comments on AOA and AOD Selection for a Multi-User SDMA Network

Comments on AOA and AOD Selection for a Multi-User SDMA Network. Date: 2009-3-1 1. Authors:. 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. Problem Description.

luke
Download Presentation

Comments on AOA and AOD Selection for a Multi-User SDMA Network

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. Comments on AOA and AOD Selection for a Multi-User SDMA Network Date: 2009-3-11 Authors:

  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. 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. Current Proposal • 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

  5. Current Proposal, An Example – Channel D • 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

  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. 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. 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. 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. 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. 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

More Related