Return to GSoC 2015 Accepted Projects page.
- 1 Carrier Aggregation support for the LTE module
- 2 Plan
- 3 Weekly Progress
- 4 Midterm review
- 5 Some References
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 -- 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  and  you can find two code review request that I published during this first 5 weeks of GSoC.  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.  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 , I upload a first draft of the doxygen documentation.
- Error creating thumbnail: Image type not supported
Architecture of LteNetDevice and LtePhy
- Error creating thumbnail: Image type not supported
Sap Connection between each Phy Layer object and the LteEnbRrc
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.
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.
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.
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.
- LTE-A HetNets using Carrier Aggregation, Nomor whitepaper 
- 3GPP TS 36.211
- 3GPP TS 36.213
- 3GPP TS 36.331