Bugzilla – Full Text Bug Listing |
Summary: | random variables and UE positions | ||
---|---|---|---|
Product: | ns-3 | Reporter: | Tom Henderson <tomh> |
Component: | core | Assignee: | Mathieu Lacage <mathieu.lacage> |
Status: | NEEDINFO --- | ||
Severity: | normal | CC: | lucaanchora, ns-bugs |
Priority: | P5 | ||
Version: | pre-release | ||
Hardware: | All | ||
OS: | All | ||
Attachments: |
test case
subset of test program |
Description
Tom Henderson
2012-05-20 00:17:15 EDT
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. |