Bug 2980 - Handover with carrier aggregation is failing
Handover with carrier aggregation is failing
Status: RESOLVED FIXED
Product: ns-3
Classification: Unclassified
Component: lte
ns-3-dev
All All
: P3 major
Assigned To: Biljana Bojović
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2018-08-30 06:48 EDT by Zoraze Ali
Modified: 2018-09-07 08:20 EDT (History)
2 users (show)

See Also:


Attachments
example script (14.18 KB, text/x-c++src)
2018-08-30 06:48 EDT, Zoraze Ali
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Zoraze Ali 2018-08-30 06:48:38 EDT
Created attachment 3168 [details]
example script

Hi, 

I am using lena-x2-handover-measures.cc example by adding the code to enable CA. The simulation is failing with the following assert message. 

assert failed. cond="m_lcInfoMap.find (lcId) == m_lcInfoMap.end ()", msg="cannot add channel because LCID 3 is already present", file=../src/lte/model/lte-ue-mac.cc, line=540
terminate called without an active exception

After investigating a bit I found the following reasons for this behavior, 

1. In LteUeRrc::DoRecvRrcConnectionReconfiguration function when msg.haveMobilityControlInfo is true, only the primary component carrier MAC and PHY layers are reset. One can find the following lines of code,

    m_cmacSapProvider.at(0)->Reset ();
    m_cphySapProvider.at(0)->Reset (); 

In general, with the introduction of CA, we should reset the MAC and PHY of all the component carriers, wherever there is a need to reset them. Thus, we should do the following:

for (uint16_t i = 0; i < m_numberOfComponentCarriers; i++)
  {
     m_cmacSapProvider.at(i)->Reset ();
     m_cphySapProvider.at(i)->Reset ();
  }

2. There is no reset function in simple-ue-component-carrier-manager.cc. Once the UE RRC resets the MAC and PHY, it should also reset the logical channels in simple-ue-component-carrier-manager.cc. I suggest implementing a Reset function in LteUeCcmRrcSapProvider, and subsequently in simple-ue-component-carrier-manager.cc class as well. This way the UE RRC would be able to call the Reset function of simple-ue-component-carrier-manager.cc class through already implemented SAP interface. 

3. In LteUeRrc::DoRecvRrcConnectionReconfiguration function when msg.haveMobilityControlInfo is true, we should check if haveNonCriticalExtension is set true. After resetting the MAC and PHY, it is needed to reestablished secondary component carriers as per the target eNB configuration. 

4. In function LteEnbRrc::DoRecvHandoverRequest the line handoverCommand.haveNonCriticalExtension = false; should be removed. This causes UE to ignore NonCriticalExtension message, even it is included. After the CA code addition, it is the responsibility of UeManager::BuildRrcConnectionReconfiguration function to set this flag depending on, if CA is enabled or not. 


I am attaching the example script to reproduce the bug. I will soon provide the patch to solve this issue.

Kind regards,
Zoraze
Comment 1 Alexander Krotov 2018-08-30 07:29:18 EDT
There is some code that remains unmerged in https://bitbucket.org/labdsf/ns-3-dev/src/default/

I think these issues are fixed there, at least the first one.
Comment 2 Alexander Krotov 2018-08-30 07:41:25 EDT
Look into https://www.nsnam.org/wiki/GSOC2017Lte
The first milestone is pushed into ns-3-dev.

The second and third milestone, with all the tests for handover are merged with the mainline in https://bitbucket.org/labdsf/ns-3-dev/

I will merge it again and push another merge into https://bitbucket.org/labdsf/ns-3-dev/, then you can check it and if it works, we can push it into ns-3-dev.
Comment 3 Alexander Krotov 2018-08-30 08:21:57 EDT
I have merged up to the point where LteHelper::SetCcPhyParams is removed. That is related to bug https://www.nsnam.org/bugzilla/show_bug.cgi?id=2840

Some of my tests in https://bitbucket.org/labdsf/ns-3-dev/src use LteHelper::SetCcPhyParams. You can clone https://bitbucket.org/labdsf/ns-3-dev/ and merge it with ns-3-dev if you know how to easily change the test to work after #2840 bugfix. There are no major lte-related commit after this point.
Comment 4 Biljana Bojović 2018-08-30 10:09:33 EDT
Hi Alexander, 

we should look forward to upstream your GSoC code to ns-3-dev. I will open a new bug so that we follow up there on that issue.

Regarding, SetCcPhyParams, thanks for reminding. For personal matters, I could not follow up when the bug 2840 was being resolved, and I do not agree with how is resolved because by removing SetCCPhyParams, it is lost a possibility to provide a custom component carrier map configuration to LteHelper. Because of this, I will reopen it.

Cheers,
Biljana
Comment 5 Zoraze Ali 2018-08-30 10:28:51 EDT
Hi Alexander and Biljana, 

I had look on the code, it does solve the problem mentioned in point 1 and 4 but not 2 and 3. Since the code of milestone 2 and 3 includes other functionalities, for the moment I would just proceed further with my suggested modifications, unless, you do not agree with what I proposed.

Later, we can review the code again and merge.   

Kind regards,
Zoraze
Comment 6 Biljana Bojović 2018-08-30 10:53:14 EDT
Here is the bug to follow up on the Alexanders code https://www.nsnam.org/bugzilla/show_bug.cgi?id=2981.

Zoraze, can you upload the patch?
Comment 7 Zoraze Ali 2018-08-31 06:17:06 EDT
Hi Biljana and Alexander,

Here are my proposed changes: https://github.com/Zoraze/ns-3-dev-git/commit/f1c552b4881e5b8139f33a193184a00649ae3a29
Comment 8 Biljana Bojović 2018-09-05 07:17:17 EDT
Hi again,

I reviewed the patch and I am fine with it. I think that it is important to have this fix pushed as soon as possible to ns-3-dev.

In any case, we should look forward to bringing Alexander's code for CA handover to ns-3-dev soon. There are many important fixes and extensions there.

Cheers,
Biljana
Comment 9 Zoraze Ali 2018-09-07 08:20:32 EDT
Pushed to changeset 13789:5539a0249fbb