Difference between revisions of "GSOC2015LTECA"
|Line 1:||Line 1:|
= Carrier Aggregation support for the LTE module =
= Carrier Aggregation support for the LTE module =
Revision as of 20:01, 23 June 2015
Return to GSoC 2015 Accepted Projects page.
Carrier Aggregation support for the LTE module
Student: Danilo Abrignani
- 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.
- 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.
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 -- ComponentCarrierComponent --> 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 ComponentCarrierComponent objects
- since ComponentCarrierComponent 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 ComponentCarrierComponent within the LteHelper class for the single carrier simulations
- on the other hand, we propose to implemente a new helper, i.e. CccHelper that return a std::map < ns3::ComponentCarrierComponent>, than with a LteHelper method, i.e. SetEnbCcc (std::map <ns3::ComponentCarrierComponent>) we send the Cc Atributes to the LteNetDevice
- LTE-A HetNets using Carrier Aggregation, Nomor whitepaper 
- 3GPP TS 36.211
- 3GPP TS 36.213
- 3GPP TS 36.331