GSOC2015LTECA

From Nsnam
Jump to: navigation, search

Main Page - Current Development - Developer FAQ - Tools - Related Projects - Project Ideas - Summer Projects

Installation - Troubleshooting - User FAQ - HOWTOs - Samples - Models - Education - Contributed Code - Papers

Return to GSoC 2015 Accepted Projects page.

Carrier Aggregation support for the LTE module

Student: Danilo Abrignani

Mentors: Marco Miozzo Nicola Baldo

  • Abstract: 3GPP standardizes, in release R10, the Carrier Aggregation (CA) technology. This consists of the possibility, for a single user equipment (UE), to aggregate Radio Resources belonging to different carriers, in order to have more bandwidth available, and a higher potential throughput. The idea is to improve the current LENA implementation, with CA functionalities, by implementing a sort of “proxy” between the RLC/RRC layer and MAC/Scheduler layers, associated to the multiple carriers.
  • Code: http://code.nsnam.org/daniloa/ns-3-dev-lte-ca/
  • About me: I'm a Ph.D. candidate at the University of Bologna, Italy. My research interests are in wireless sensor network and mobile network simulation. Something more about me on my Linkedin page.

Plan

  • 1st Week:
 * Implementation of RRC messages for Carrier Aggregation support
 * Writing design documentation 
  • 2nd - 4th Weeks:
 * Implementation of the LTE-A helper, activation of different carriers and synchronization procedure. 
 * Writing test code and debugging.
 * Writing design documentation
  • 5th - 6th Weeks:
 * Write test documentation, submit code for review, consolidate code and documentation. 

  • 7th -8th Weeks:
 * Start writing the CA-Mac module, design documentation.
 * Write test and debugging, writing test documentation, submit code for review.
  • 9th - 10th Weeks:"'
 * Define a basic algorithm that takes into account QoS indicators. Write design documentation
 * Writing test application and debugging. Submit code for review. Update code and documentation.
  • 11th - 12th Weeks:
 * Unified LTE-A and LTE helpers. 
 * Write test applications, update documentation and code. 
 * Possible improvements.

Weekly Progress

Week 1 (May 25, 2015 - May 31, 2015)

First week of coding phase has delivered the following:

  • Implementation of RRC messages for Carrier Aggregation support
  • Implementation of CcsAlgorithm abstract class which will be base class for Carrier Component Selection (CCS) algorithms
  • Implementation of SAPs
  • LteHelper was updated to install CCS entity and SAPs during setting up EnbNetDevice. However, currently no ccs algorithm is implementing.


Week 2 (June 01, 2015 - June 07, 2015)

In summary, this week I delivered the following:

  • Minor error fix on RRC SAP
  • ASN1 - RRC coding implemented:
    • Basically I implemented the serialize and deserialize method for coding the new fields in the rrcConfigurationReconfiguration message.
    • Minor change in ASN1 Header, i.e. adding a function template in order to match a new bit mask, the latter it is used to enable or disable optional fields in RRC headers.
  • Tested carriers aggregation CA enable procedure (messages exchange) when RrcIdeal is false.


Week 3 (June 08, 2015 - June 14, 2015)

I planned to delivered during the third week the following: implementation of a second PHY object that is related to the second carrier component (SCC), and modify accordingly the RRC SAP and LteHelper to handle the SCC.

However, it wasn't possible. The main problem was that I tried to mantain the same code structure used in the current version of the simulator. The drawback is that currently the RRC and PHY attributes are set using the LteHelper on the LteNetDevice (both for Enb and for Ue) and than passed as attribute for the others classes.

Moreover, now attributes are basically integer or boolean variable, in the 'CA version' most of them should be changed in vector, e.g. ulBandwidth now is integer, it has to became a vector where each element is related to a carrier component. So, the first idea was to use std::vector, this generate a problem, in fact NS3 do not allow to pass has Attribute a std::vector. The work around is to create a method for each attribute that we want to set, e.g. SetUlBandwidth (std::vector bwList), but this method has to be called explicit by user.

I discussed with my mentors about the possibile strategies to take. The results, meaning the plan for the 4th week (and further), is as follow:

  • define a new class -- ComponentCarrier --> this object will contain all the attribute of a single carrier component, e.g. ul/dlBandwidth, ul/dlFrequencies
  • modify LteNetDevice accordingly --> in the new the class will contain a map of ComponentCarrier objects
  • since ComponentCarrier is an ns3 Object, it is possible to pass this using the Attribute system
  • this solution could make easier the implementation of traces and statistics
  • others method will be updated accordingly, e.g. ConfigureCell
  • in order to maintain back-compatibility, we decided to leave the current attribute and mask the ComponentCarrier within the LteHelper class for the single carrier simulations
  • on the other hand, we propose to implement a new helper, i.e. CccHelper that return a std::map < ns3::ComponentCarrier>, than with a LteHelper method, i.e. SetEnbCcc (std::map <ns3::ComponentCarrier>) we send the Cc Atributes to the LteNetDevice

Week 4/5 (June 15, 2015 - June 28, 2015)

In summary, I delivered the following:

  • define a new class -- ComponentCarrier --> this object will contain all the attribute of a single carrier component, e.g. ul/dlBandwidth, ul/dlFrequencies and a pointer to LteEnbPhy
  • modify LteNetDevice accordingly --> in the new the class will contain a map of ComponentCarrier objects (see the figures below)
  • others method have been updated accordingly, e.g. ConfigureCell
  • in order to maintain back-compatibility, I decided to leave the current attribute. Even if the last option seems redundant, it is useful to maintain the full compatibility with the current version of user simulation scripts. Basically, in case that Carrier Aggregation is not enable, the ccHelper is invoked within the LteHelper to create a valid ComponentCarrier Map for both the LteEnbNetDevice and LteUeNetDevice. In this case, the only element in ComponentCarrier Map will inherit all the parameters set on the net device.
  • on the other hand, I implemented a new helper, i.e. CcHelper that return a std::map std::map <uint8_t, Ptr<ns3::ComponentCarrier> >, than with a LteHelper method, i.e. SetEnbCcc (std::map <uint8_t, Ptr<ns3::ComponentCarrier> >) we send the Cc Atributes to the LteNetDevice
  • moreover, I modify the method LteHelper::InstallSingleUeDevice
  • I also added a new class -- ComponentCarrierUe --> the latter, basically replicate the ComponentCarrier class for the UE, the only difference is that in this case the LteEnbPhy is replaced by LteUePhy.
  • finally, I fix minor problem, such as changing the path in the physical layer traces to find the new position of the LTeEnbPhy object.

Following the same paradigm of LtePhy/LteEnbPhy/LteUePhy classes, I will reshape the ComponentCarrier class and create: ComponentCarrierUe and ComponentCarrierEnb (both inheriting the ComponentCarrier class)

Suggestions and comments on the proposed scheme are very welcome.

In [3] and [4] you can find two code review request that I published during this first 5 weeks of GSoC. [3] is related to the necessary modification needed at Rrc layer to accomodate the new structures needed to configure the carrier aggregation. Moreover, The ASN1 encoding class was changed accordingly. [4] is related with the new architecture proposed during week 3. Basically, it contains the new classes that I created and the modifications in the LteHelper, Lte[Enb/Ue]NetDevice and few more changes.

During next week, I will consolidate the code, removing redundant part, fixing minor issues and writing some documentation. Moreover, I will reshape the ComponentCarrier class as I wrote above.

In [5], I upload a first draft of the doxygen documentation.


[3] https://codereview.appspot.com/241320043/

[4] https://codereview.appspot.com/249960043/

[5] https://www.nsnam.org/~daniloa/docs/doxygen/



Week 6 (June 29, 2015 - July 5, 2015)

Not so many update this week, I was concentrated more on debugging and documentation. However, in summary, I delivered the following:

  • after defined the new class ComponentCarrier, I changed the code accordingly
  • now a ComponentCarrierEnb class is used for the LteEnbNetDevice
  • and a ComponentCarrierUe class is used for the LteUeNetDevice
  • implementing the comments of the reviewer in my code.

As I anticipated before, I was focus more on debugging since some Lte Test crash. For week 7, I'm going to continue in order to solve each problem before move on and adding new code.

Week 7 (July 6, 2015 - July 12, 2015)

Basically in week 7, I solved (finally) some bugs that cause the tests crash.

In the next week, I am going to conclude the control plan connection. I will convert the cMacSap from object to std::vector (one object per carrier component). Then, I tested the code and start to write some documentation. Regarding the documentation, I define the draft for two sequence diagrams:

1. Radio Bearer setup sequence 2. Data Plane: scheduling between the different carriers


1. The Carrier Aggregation is transparent to each Enb Mac layer instance (one for each CC) and the setup of the Logical Channel is demanded to Rrc layer. The idea is that a specific object (ComponentCarrierManager, the former ComponentCarrierSelection) handles the logical channel setup. Basically, it receives the Ue Measurements and decide when and which logical channel activate on which Mac instance.


2. By the standard specification RLC layer is not aware if and when the CA is enabled. Here, the idea is to have an object in between the LteEnbRlc and the different Mac instances. Each time a new PDU arrive from the PDCP layer, the LteEnbRlc generate a BufferStatusReport (BSR), the entity between the RLC and the MAC ('CaMac Proxy') will decide how split the BSR between the different MAC instances. When a Mac instance notifies a transmission opportunity the 'CaMac Proxy' forwards the transmission opportunity to RLC layer. The latter builds a SDU and sends to the 'CaMac Proxy', which forward to the right MAC instance.


Week 8 (July 13, 2015 - July 19, 2015)

In week 8, I delivered the follows:

  • renaming the ComponentCarrierSelection to LteComponentCarrierManager. This is not a merely renaming, on the opposite, the idea is to merge the former ComponentCarrierSelection and the Ca-Mac proxy following the same principle applied to scheduler, Ffr module and so on.
  • Since, each component carrier has his on MAC layer, FFR component and scheduler, I 'moved' these objects from LTeEnbDevice to ComponentCarrier
  • Finally, I implemented the new sap for the LteComponentCarrierManager and ran the tests.

The new architecture, both for Ue and Enb are shown in the figures below.


Week 9 (July 20, 2015 - July 26, 2015)

Basically in week 9, I delivered the follows:

  • renaming LteComponentCarrierManager to LteEnbComponentCarrierManager
  • create a similar object for the Ue, LteUeComponentCarrierManager
  • conclude the control plane from the ue side
  • create the template classes for LteCcmRrcSap
  • prepared the data plane function
  • code review request for the entire control plane: https://codereview.appspot.com/250600043/

Week 10 (July 27, 2015 - August 2, 2015)

In week 10, I delivered the follows:

  • Duplicated the the template classes for LteCcmRrcSap, now there is a specific implementation for the Ue (LteUeCcmRrcSap)
  • after talking with my mentors, we realized that, to handle the carrier aggregation in uplink, a new set of information are needed to exchange between LteEnbCompomponentCarrierManager and the LteEnbMacLayer.

About this last point, I am preparing the new version of the documentation explain the sequence in details.

  • Added Sequence Diagram in the repository regarding the Uplink carrier aggregation
  • several minor fix and some code was improved
  • implemented the data plane

Due to the many changes, the current version of the code doesn't work with the test suite. I start modifying the test suite in order to fit with the new architecture.

Week 11 (August 2, 2015 - August 9, 2015)

Basically in week 11, I planned to deliver the follows:

  • modify the test suite to fit with the new architecture
  • debug the code
  • write documentation

Since I modified some functions adding few more parameters, the test lte-test-entities was crashing due to the number of parameters. For instance, I changed the NotifyTxOpportunity function. The latter in lte-test-entities is called using Simulator::ScheduleWithContext and Simulator::Scheduler. Both functions have defined templates up to 5 input parameter. I just added a template for 6 parameters. In order to achieve this, I modified simulator.h and make-event.h in the core folder. I sent the patch on ns3-dev mailing list.

By next week, I will continue on:

  • documents preparation
  • debug the code

Week 12/13 (August 10, 2015 - August 21, 2015)

After the implementation of the LteUlCcmRrcSap[User/Provider] between the LteEnbMac of the primary carrier component and the LteEnbComponentCarrierManager, I continued to debug the code, wrote some design documentation and reshape the doxygen. Finally, I posted a code review request: https://codereview.appspot.com/262000043/

Midterm review

Here I want to present the work done until the 4th week for the midterm review.

As general remarks, I'm sorry to be unable to provide a first set of test example in the midterm review.

RRC Messages

The object of this code review request is to introduce in the RRC message structure the new field, added in R10, to support Carrier Aggregation. The main changes are in the RRC Connection Reconfiguration message Consequently, the ASN1 encoding class has to be extended to accomodate the new structures and fields.

https://codereview.appspot.com/241320043/

ComponentCarrier Object and new proposed architecture

Details about this code review request can be found in the 4th weekly report (see above). Basically, I introduced a new object needed to connect each single carrier component to the LteNetDevice. Then, I modify accordingly the LteHelper and the Lte[Enb/Ue]NetDevice classes.

https://codereview.appspot.com/249960043/

FinalTerm review

In this section, I sum up the work I have done in these weeks and what (unfortunately) it is still to be done. In total I published 4 code review request:

Regarding the code structure, I implemented the following:

  • extend the Rrc messages structure to fit the new fields to configure the carrier aggregation. Mainly I worked on RrcConnectionReconfiguration message.
  • add the ASN1 coding for the new messages format
  • implement Carrier Component class and its child for Enb and Ue. More in details, these classes include all the attributes and pointer related to a certain carrier component. Formerly, those attributes were included in Lte[Enb/Ue]Device classes.
  • changing the Lte[Enb/Ue]Device and Lte[Enb/Ue]Mac classes accordingly.
  • Lte[Enb/Ue]ComponentCarrierManager classes were implemented to act as a "proxy" between upper layer and Mac/Phy layers. However, some minor modifications were needed also on Rlc classes.
  • implement Lte[Enb/Ue]CcmRrcSap[User/Provider] to connect the Rrc instance with Lte[Enb/Ue]ComponentCarrierManager
  • Lte[Enb/Ue]ComponentCarrierManager were implemented as 'empty box' in the same way of Scheduler at Mac layer, hence the developer can attach the algorithm he preferred.
  • NoOpComponentCarrierManager and SimpleUeComponentCarrierManager are examples of possible algorithms. Both send all the data only on primary carrier component even if more than one component carrier is defined. These two algorithms are enabled by default
  • installed a new helper, i.e. CcHelper, to create a valid ComponentCarrier Map
  • change the LteHelper in order to maintain backwards compatibility with user script.
  • Implement LteUlCcmMacSap, to deal with the 'special case' of the uplink buffer status report (explained in the documentation)

Hereafter, the part that is still to be done:

  • add one or two specific tests for carrier aggregation
  • verify the complete support of the handover algorithm when carrier aggregation is enabled
  • provide some code examples

Some References

    • LTE-A HetNets using Carrier Aggregation, Nomor whitepaper [1]
    • 3GPP TS 36.211
    • 3GPP TS 36.213
    • 3GPP TS 36.331