Bug 2835 - lte: add support for multiple EPC
lte: add support for multiple EPC
Status: PATCH PENDING
Product: ns-3
Classification: Unclassified
Component: lte
ns-3-dev
All All
: P1 enhancement
Assigned To: Biljana Bojović
:
Depends on: 2834
Blocks:
  Show dependency treegraph
 
Reported: 2017-12-04 20:04 EST by Tommaso Pecorella
Modified: 2017-12-23 04:47 EST (History)
4 users (show)

See Also:


Attachments
patch (23.15 KB, patch)
2017-12-04 20:04 EST, Tommaso Pecorella
Details | Diff
avoid small mistake (23.15 KB, patch)
2017-12-04 20:54 EST, Tommaso Pecorella
Details | Diff
Update to use IsNetworkAllocated (23.14 KB, patch)
2017-12-05 18:36 EST, Tommaso Pecorella
Details | Diff
still bugs (37.78 KB, patch)
2017-12-09 19:21 EST, Tommaso Pecorella
Details | Diff
still bugs (54.33 KB, patch)
2017-12-14 19:46 EST, Tommaso Pecorella
Details | Diff
No bugs, but still an open issue (56.73 KB, patch)
2017-12-22 19:41 EST, Tommaso Pecorella
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Tommaso Pecorella 2017-12-04 20:04:09 EST
Created attachment 2971 [details]
patch

This is a much-asked feature by the users: to be able to instantiate more than one EPC.
If the code is accepted, the documentation will have to be changed as well (I'd like to discuss the code first).

The idea is: LTE uses a "base" 7.0.0.0/8 network to pick the actual EPC network number from.
The EPC will use the first /16 available network in the pool. As a consequence, the first EPC will use 7.0.0.0/16, the second 7.1.0.0/16 and so on.
Overall, this doesn't seem a big limitation (max. 2^16 UEs or so and 256 EPCs, more than enough for any normal simulation).

The code isn't mine, it's from Manoj Kumar Rana <manoj24.rana@gmail.com>. It has been developed as part of GSoC 2017.
Even though he was focusing on IPv6, I asked him to remove this limitation as well.

As a side note, it would be great to create a lena-simple-two-epc.cc... but honestly, I'm a bit sleepy.
Comment 1 Tommaso Pecorella 2017-12-04 20:54:41 EST
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.
Comment 2 Tommaso Pecorella 2017-12-05 18:36:27 EST
Created attachment 2973 [details]
Update to use IsNetworkAllocated
Comment 3 Tommaso Pecorella 2017-12-09 19:21:47 EST
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.
Comment 4 Tommaso Pecorella 2017-12-14 19:46:48 EST
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).
Comment 5 Biljana Bojović 2017-12-21 20:01:05 EST
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
Comment 6 Tommaso Pecorella 2017-12-22 06:12:58 EST
Hi Biljana,

yes, the patch in https://www.nsnam.org/bugzilla/show_bug.cgi?id=2834
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
Comment 7 Biljana Bojović 2017-12-22 07:00:04 EST
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
Comment 8 Tommaso Pecorella 2017-12-22 19:41:00 EST
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.
Comment 9 Zoraze Ali 2017-12-23 04:47:17 EST
Hi Tommaso, 

I think this bug https://www.nsnam.org/bugzilla/show_bug.cgi?id=2840 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