Bugzilla – Bug 2861
Uplink scheduled TX opportunities for the non-primary CC are not forwarded to RLC (CA is not used in uplink)
Last modified: 2018-09-07 08:23:26 UTC
Created attachment 3020 [details] Proposed patch A bug in the CA implementation prevents it from working as expected in uplink, because uplink scheduled TX opportunities for the non-primary CC are not forwarded to the RLC layer. Tommaso Zugno (in cc) and I observed that the LteUeMac associated with CC0 (the primary CC) is the only one that handles the BSRs from the RLC, and transmits them to the eNB (as specified in Bojiovic et al. Towards LTE-Advanced and LTE-A Pro Network Simulations: Implementing Carrier Aggregation in LTE Module of ns-3, Fig. 9). Then, when CA is enabled, the eNB allocates the uplink resources for both CC0 and the other CC (e.g., CC1), and sends the DCIs to the two LteUeMac classes. However, in the LteUeMac instance associated to CC1, m_ulBsrReceived is empty, so when DoReceiveLteControlMessage is called, activeLcs is always equal to 0 and NotifyTxOpportunity is never called. The result is that even though the resources are allocated, the UE uses only CC0 to transmit. The CarrierAggregationTestCase does not signal this problem because it checks if the scheduled resources are correctly split among the CC, and not if they are actually used. We tested this on lena-simple with useCa=true and the latest ns-3 cloned from the ns-3 git mirror. Tommaso also prepared a patch that makes sure that the BSR is actually notified to all the LteUeMac instances, but just the primary CC actually sends the BSR to the eNB.
Hi, If you will do the following, if( m_componentCarrierId == 0) //only the Primary CC sends BSRs { SendReportBufferStatus (); } How eNB would know that other carriers have data to send and need resources? Kind regards, Zoraze
(In reply to Zoraze Ali from comment #1) > Hi, > > If you will do the following, > > if( m_componentCarrierId == 0) //only the Primary CC sends BSRs > { > SendReportBufferStatus (); > } > > How eNB would know that other carriers have data to send and need resources? > > Kind regards, > Zoraze Dear Zoraze, The BSRs are "carrier-independent", i.e. their aim is to inform the eNB that the RLCs at the UE side have some packets to send. The UE sends all the BSRs through the primary component carrier (PCC), as specified in [https://dl.acm.org/citation.cfm?id=3067669, section 4.4]. At the eNB side, the PCC forwards all the received BSRs to the Component Carrier Mananager (CCM). The CCM splits each BSR into NCC new BSRs, where NCC is the number of Component Carriers (CCs), and reports them to the CCs. Then, each CC will use its own BSR to schedule the uplink resources. The way the splitting is done depends on the specific CCM implementation, if RrComponentCarrierManager is used each newly created BSR gets bufferSize/NCC. At the UE side, the CCs receive UL-DCIs and split the tx opportunities among the active logical channels, where active means that the associated RLC has some packets to send. To know which are the active channels, the MAC instance of each CC uses the m_ulBsrReceived map, that contains the previously sent BSRs. Figure 9 in the same paper describes this procedure in detail. The bug we found is that m_ulBsrReceived remains empty in all the Secondary Component Carriers (SCCs), preventing the correct computation of the number of active channels. Although the uplink resources are correctly scheduled, they are never used by the SCCs because the number of active channels is wrongly computed. With our fix, the BSRs are reported to all the CCs but sent only by the PCC. In this way each MAC instance stores the BSRs in the m_ulBsrReceived map and then it can correctly compute the number of active channels. Best regards, Tommaso
Thanks for the patch. I took a look into this and I am fine with it. Zoraze is performing some additional tests since he spotted another issue, so once he is done we can push it.
Hi Biljana, I have reworked the code in SimpleUeComponentCarrierManager. You can find the changes here: https://github.com/Zoraze/ns-3-dev-git/commit/8c0d5ab5bcb34c63668090913454fa47b361fdfc Please note that the patch for bug # 2982: https://www.nsnam.org/bugzilla/0 is the prerequisite for the above change to work.
Thanks to Michele and Tommaso for reporting and proposing the patch. I think that we should proceed with Zoraze's patch since after fixing CA architecture on UE side (2982), and giving control to CCM manager, some of the logic for dispatching the calls between RLC and MAC must pass through it.
Thanks all of you for providing the patch and feedback. The final patch is pushed to the changeset 13791:97263479feeb Kind regards, Zoraze