Bugzilla – Bug 1431
random variables and UE positions
Last modified: 2012-06-07 09:57:32 UTC
copy/pasted from Luca's post on 5/8/12: Dear all developers, I am experiencing a strange problem with the ns-3-lte. I am working on a multicell scenario, where each cell is represented by a different object of class LteHelper and is made of 1 eNB and several UEs registered to it. The UEs are randomly placed around the respective eNB, in a circle of radius 1500 m. I execute several runs and for each run I select a different seed, where the seeds are not correlated among themselves. I am observing a strange thing regarding the position of the UEs: those belonging to the first eNB (say eNB0) are ALWAYS closer to their eNB with respect to those belonging to the other eNB (say eNB1). Of course, this results in a much smaller path loss and thus a higher CQI for each UE of the former eNB on each frequency subchannel. This looks very very strange, because I am executing around 1000 runs and the situation is more or less always the same. It seems there is a systematic error either in the generation of random numbers or in the management of UEs' positions and the respective channel realizations.
Created attachment 1399 [details] test case From Luca's mail: What I am simulating in this case is a network with two cells: the former has a variable number of UEs specified by the user as a command line argument; the latter has a fixed number of UEs, i.e. 40. They also share a part of their spectrum (I modified the spectrum management). I introduced a couple of uniform variables to generate some randomness: I randomly exchange eNB0 and eNB1 to make them statistically equivalent. In this way, after a certain number of runs (a few hundreds) their performance in terms of total cell capacity is the same.
Created attachment 1403 [details] subset of test program This excerpts portions of multi_op.cc to run against the current ns-3-dev repository.
Luca, I wasn't able to run your test program against any LTE variants that I had; it had a central-authority.h that I didn't know anything about. Anyway, I created a subset of your program that I think results in a similar nodal placement (initial node conditions). This new program runs against ns-3-dev and I added it to this tracker. I noticed that the program increments the x_bs value by 50 for each new eNB. However, it seems that the ue are uniformly drawn from a range (-radius, radius) in both X and Y dimensions. While eNB is at the origin, each subsequent eNB is further away from the origin, and hence will be further away from the population of UEs. Do you think that this may account for what you observed? Note that my version of the test program seems to be limited to two eNBs; if I add a third eNB, all of the UEs assigned to it seem to be at the same place as the eNB. What I wrote above is based on looking at the two eNB case.
(In reply to comment #3) > Luca, I wasn't able to run your test program against any LTE variants that I > had; it had a central-authority.h that I didn't know anything about. > > Anyway, I created a subset of your program that I think results in a similar > nodal placement (initial node conditions). This new program runs against > ns-3-dev and I added it to this tracker. > > I noticed that the program increments the x_bs value by 50 for each new eNB. > However, it seems that the ue are uniformly drawn from a range (-radius, > radius) in both X and Y dimensions. While eNB is at the origin, each > subsequent eNB is further away from the origin, and hence will be further away > from the population of UEs. > > Do you think that this may account for what you observed? > > Note that my version of the test program seems to be limited to two eNBs; if I > add a third eNB, all of the UEs assigned to it seem to be at the same place as > the eNB. What I wrote above is based on looking at the two eNB case. Tom, the scenario description file that I sent you before used some classes that are not included in the standard version of ns-3. Sorry for the mistake. My code is publicly available at code.nsnam.org/lanchora/ns-3-lte-SpectrumSharing/ However, the test file that you created is fine as well. Actually, what I simulate are two cells where the eNBs have a distance of 50 m on the x-axis. If you have a look at the file, all the UEs belonging to the second eNB are uniformly distributed within a circle centered in the eNB. This is done by first drawing the X and Y coordinates of each UE from (-radius, radius), where radius is the cell range, and then adding 50 m to the X value. Therefore, there is no systematic unbalance in UEs' positioning.