Bugzilla – Full Text Bug Listing |
Summary: | REM shows increased SINR when co-located eNBs have same EARFCN | ||
---|---|---|---|
Product: | ns-3 | Reporter: | Nicola Baldo <nicola> |
Component: | lte | Assignee: | Nicola Baldo <nicola> |
Status: | REOPENED --- | ||
Severity: | normal | CC: | hansgarry, ns-bugs |
Priority: | P5 | ||
Version: | ns-3-dev | ||
Hardware: | All | ||
OS: | All | ||
Attachments: |
program that should reproduce the bug
An example that shows the problem |
Description
Nicola Baldo
2012-10-17 12:27:00 EDT
Created attachment 1456 [details]
program that should reproduce the bug
The attached program creates a scenario with co-located enbs that takes the following parameters: --numEnbs: how many eNBs there are --earfcnStep: earfcn difference between successive eNBs I ran it with different parameters parameters: $ ./waf --run scratch/lena-rem-multiple-enbs --command="%s --numEnbs=2 --earfcnStep=0" $ ./waf --run scratch/lena-rem-multiple-enbs --command="%s --numEnbs=2 --earfcnStep=1" $ ./waf --run scratch/lena-rem-multiple-enbs --command="%s --numEnbs=2 --earfcnStep=50" $ ./waf --run scratch/lena-rem-multiple-enbs --command="%s --numEnbs=2 --earfcnStep=100" and here are the results: $ cat 2enbs_0earfcnStep.rem -400 -300 0 0.376573 -400 -100 0 0.47042 -400 100 0 0.47042 -400 300 0 0.376573 -133.333 -300 0 0.583527 -133.333 -100 0 0.844632 -133.333 100 0 0.844632 -133.333 300 0 0.583527 133.333 -300 0 0.583527 133.333 -100 0 0.844632 133.333 100 0 0.844632 133.333 300 0 0.583527 400 -300 0 0.376573 400 -100 0 0.47042 400 100 0 0.47042 400 300 0 0.376573 $ cat 2enbs_1earfcnStep.rem -400 -300 0 0.379751 -400 -100 0 0.47539 -400 100 0 0.47539 -400 300 0 0.379751 -133.333 -300 0 0.591193 -133.333 -100 0 0.860789 -133.333 100 0 0.860789 -133.333 300 0 0.591193 133.333 -300 0 0.591193 133.333 -100 0 0.860789 133.333 100 0 0.860789 133.333 300 0 0.591193 400 -300 0 0.379751 400 -100 0 0.47539 400 100 0 0.47539 400 300 0 0.379751 $ cat 2enbs_50earfcnStep.rem -400 -300 0 0.604037 -400 -100 0 0.888289 -400 100 0 0.888289 -400 300 0 0.604037 -133.333 -300 0 1.40112 -133.333 -100 0 5.43633 -133.333 100 0 5.43633 -133.333 300 0 1.40112 133.333 -300 0 1.40112 133.333 -100 0 5.43633 133.333 100 0 5.43633 133.333 300 0 1.40112 400 -300 0 0.604037 400 -100 0 0.888289 400 100 0 0.888289 400 300 0 0.604037 $ cat 2enbs_100earfcnStep.rem -400 -300 0 0.604037 -400 -100 0 0.888289 -400 100 0 0.888289 -400 300 0 0.604037 -133.333 -300 0 1.40112 -133.333 -100 0 5.43633 -133.333 100 0 5.43633 -133.333 300 0 1.40112 133.333 -300 0 1.40112 133.333 -100 0 5.43633 133.333 100 0 5.43633 133.333 300 0 1.40112 400 -300 0 0.604037 400 -100 0 0.888289 400 100 0 0.888289 400 300 0 0.604037 To me the SINRs in the REMs look reasonable: the value decreases with increasing EARFCN difference, until the two eNBs are in completely orthogonal frequencies, at which point the SINR does not improve any more. Based on the tests that I made, I am closing this bug as invalid. Feel free to reopen it if you can provide a test program that successfully reproduces the supposed buggy behavior. (In reply to comment #2) > the value decreases with increasing EARFCN difference whoops, I meant "the value increases" of course. Created attachment 1457 [details]
An example that shows the problem
I attach a sample code that shows what I mean. If I set the DlEarfcn to 100 (check lines 68/69 in the code), the SINR in the REM increases. Maybe my code is wrong?
Problem is still open. |