Bug 1431

Summary: random variables and UE positions
Product: ns-3 Reporter: Tom Henderson <tomh>
Component: coreAssignee: 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
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.
Comment 1 Tom Henderson 2012-05-20 00:22:02 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.
Comment 2 Tom Henderson 2012-05-28 02:22:35 EDT
Created attachment 1403 [details]
subset of test program

This excerpts portions of multi_op.cc to run against the current ns-3-dev repository.
Comment 3 Tom Henderson 2012-05-28 02:29:11 EDT
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.
Comment 4 Luca 2012-06-07 09:57:32 EDT
(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.