Bug 2835

Created attachment 2972 [details]
avoid small mistake

We should check if the first address in the network has been allocated. The network address is never allocated.

I'll update the patch once I figure out how to test if a subnet has been used.

Created attachment 2973 [details]
Update to use IsNetworkAllocated

Created attachment 2975 [details]
still bugs

I added an example and I found several bugs.
I'm stuck on this one:
assert failed. cond="it != m_ueManagerPathByCellIdRnti.end ()", file=../src/lte/helper/radio-bearer-stats-connector.cc, line=249

I suspect that it's due to the way the traces are connected: regardless of the actual UE/EPC pairing.

Created attachment 2982 [details]
still bugs

I'm stuck.

I added some debug lines to LteEnbRrc (where the error is) and the results are driving me crazy.

A normal script (2 UEs, 2 eNBs) works like this:
* RecvRrcConnectionRequest 0x7f8fe0580600 in state INITIAL_RANDOM_ACCESS from 1
* RecvRrcConnectionRequest 0x7f8fe05841e0 in state INITIAL_RANDOM_ACCESS from 2
* RecvRrcConnectionSetupCompleted 0x7f8fe0580600 in state CONNECTION_SETUP
* RecvRrcConnectionSetupCompleted 0x7f8fe05841e0 in state CONNECTION_SETUP

If I use 2 EPCs (2 UEs, 2 eNBs per EPC), the result is:
* RecvRrcConnectionRequest 0x7fb7ad850ba0 in state INITIAL_RANDOM_ACCESS from 1
* RecvRrcConnectionRequest 0x7fb7ad850420 in state INITIAL_RANDOM_ACCESS from 2
* RecvRrcConnectionRequest 0x7fb7ad850ba0 in state CONNECTION_SETUP from 3
msg="method unexpected in state CONNECTION_SETUP", file=../src/lte/model/lte-enb-rrc.cc, line=907

It's like if UE 3 (which belongs to EPC 2) is trying to send a message to an eNB of the "wrong" EPC.

Any help is appreciated.

As a side note, the 2 EPCs are using two completely different spectrum channels, which is kinda stupid. They should use only one channel and different frequencies, but I haven't found any way to set the channel number (or whatever is called in LTE).

Hi Tommaso,

I get the following error: 

"
./src/lte/helper/point-to-point-epc-helper.cc: In constructor ‘ns3::PointToPointEpcHelper::PointToPointEpcHelper()’:
../src/lte/helper/point-to-point-epc-helper.cc:65:11: error: ‘IsNetworkAllocated’ is not a member of ‘ns3::Ipv4AddressGenerator’
   while (!Ipv4AddressGenerator::IsNetworkAllocated (s1uIpv4AddressNet, Ipv4Mask ("255.255.0.0")))
"

Should I apply some additional patch?

Thanks,
Biljana

Hi Biljana,

yes, the patch in https://www.nsnam.org/bugzilla/﷒0﷓
I'll push it soon to the main code.

Cheers,

T


(In reply to Biljana Bojović from comment #5)
> Hi Tommaso,
> 
> I get the following error: 
> 
> "
> ./src/lte/helper/point-to-point-epc-helper.cc: In constructor
> ‘ns3::PointToPointEpcHelper::PointToPointEpcHelper()’:
> ../src/lte/helper/point-to-point-epc-helper.cc:65:11: error:
> ‘IsNetworkAllocated’ is not a member of ‘ns3::Ipv4AddressGenerator’
>    while (!Ipv4AddressGenerator::IsNetworkAllocated (s1uIpv4AddressNet,
> Ipv4Mask ("255.255.0.0")))
> "
> 
> Should I apply some additional patch?
> 
> Thanks,
> Biljana

Hi Tommaso,

I really have no time to generate a proper patch. Here is what shall be done. CellidCounter shall be static since you are using now various LteHelpers.

In LteHelper.h add "static":

  static uint16_t m_cellIdCounter; 

And in LteHelper.cc add the following before constructor:

+ uint16_t ns3::LteHelper::m_cellIdCounter = 1;

and remove from the constructor:

- m_cellIdCounter {1}

With this, your example runs without error.

Cheers,
Biljana

Created attachment 2985 [details]
No bugs, but still an open issue

Thanks to Biljana the patch seems to run without errors.

However, there's still one problem.
I added the ability to sync the Ul and Dl channels in all the EPCs, but the EARFCN is still the same (i.e., expect heavy interference).

We should be able to assign different EARFCN to different EPCs (i.e., operators). This is possible, but...
1) I don't know what's the "right" numbers to set, and
2) I don't know how to set them in case of carrier aggregation.

Any suggestion is more than welcome.
Tests, right now, are useless because the RBs will collide.

Hi Tommaso, 

I think this bug https://www.nsnam.org/bugzilla/﷒0﷓ could limit you what you trying to achieve. Biljana and me are working to solve this. The patch I posted is not working for carrier aggregation, thus, may be we need to tackle the problem another way. 

For you question: 

1) I don't know what's the "right" numbers to set, and

For LTE band 1, Dl and Ul Earfcns have the difference of 18000 such that Dl EARFCN is always lower than Ul one. For example, if DL is 100 then Ul is 18000+100=18100. Alternatively, you can confirm from this handy online source http://niviuk.free.fr/lte_band.php

2) I don't know how to set them in case of carrier aggregation.

As per current design approach, there should not be any difference how you set EARFCN with or without CA. By specifying the number of component carriers tell lteHelper that CA is enabled. I think if you use my patch and your code successfully work for the case without CA then once the above mentioned bug is resolved it should work with CA as well. I guess it is ok take this assumption. 

Kind regards,
Zoraze