GSOC2015LTECA - Revision history

DaniloA at 12:58, 22 August 2015

2015-08-22T12:58:01Z

DaniloA at 12:57, 22 August 2015

2015-08-22T12:57:11Z

← Older revision		Revision as of 12:57, 22 August 2015
Line 274:		Line 274:

	= FinalTerm review =		= 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:
			* RrcConnectionReconfiguration Message - CA support: https://codereview.appspot.com/241320043/
			* GSoC 2015 - MidTerm Milestone - Carrier Aggregation: https://codereview.appspot.com/249960043/
			* GSoC 2015 - Carrier Aggregation - Control Plane: https://codereview.appspot.com/250600043/
			* GSoC 2015 - FinalTerm Milestone - Carrier Aggregation: https://codereview.appspot.com/262000043/
			* moreover, I sent a patch for the core model in the mailing list.

			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 =		= Some References =

DaniloA: /* Midterm review */

2015-08-22T12:06:14Z

Midterm review

← Older revision		Revision as of 12:06, 22 August 2015
Line 272:		Line 272:

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

			= FinalTerm review =

	= Some References =		= Some References =

DaniloA: /* Weekly Progress */

2015-08-22T11:33:41Z

Weekly Progress

← Older revision		Revision as of 11:33, 22 August 2015
Line 246:		Line 246:
	* documents preparation		* documents preparation
	* debug the code		* 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 =		= Midterm review =

DaniloA: /* Weekly Progress */

2015-08-22T11:16:12Z

Weekly Progress

@@ Line 203: / Line 203: @@
 File:Lte-arch-ue-data-carrier-aggregation.png|Carrier Aggregation Lte Ue Data Plane
 </gallery>
 = Midterm review =

DaniloA: /* Week 8 (July 13, 2015 - July 19, 2015) */

2015-07-22T10:42:47Z

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

← Older revision		Revision as of 10:42, 22 July 2015
Line 189:		Line 189:
	In week 8, I delivered the follows:		In week 8, I delivered the follows:

	* renaming the ComponentCarrierSelection to LteComponentCarrierManager. This is not a		* 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.
	merely renaming, on the opposite, the idea is to merge the former		* Since, each component carrier has his on MAC layer, FFR component and scheduler, I 'moved' these objects from LTeEnbDevice to ComponentCarrier
	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.		* Finally, I implemented the new sap for the LteComponentCarrierManager and ran the tests.

Line 202:		Line 198:

	<gallery>		<gallery>
	File:~~SetupRadioBearerCarrierAggregation~~.png\|Carrier Aggregation ~~Setup~~ Data ~~Radio Bearer~~		File:Lte-arch-enb-ctrl-carrier-aggregation.png\|Carrier Aggregation Lte Enb Control Plane
	File:~~CarrierAggregationDownlinkDataPlane~~.png\|Carrier Aggregation - ~~Downlink Scheduling~~		File:Lte-arch-enb-data-carrier-aggregation.png\|Carrier Aggregation Lte Enb Data Plane
			File:Lte-arch-ue-ctrl-carrier-aggregation.png\|Carrier Aggregation Lte Ue Control Plane
			File:Lte-arch-ue-data-carrier-aggregation.png\|Carrier Aggregation Lte Ue Data Plane
	</gallery>		</gallery>

DaniloA: /* Weekly Progress */

2015-07-22T10:39:38Z

Weekly Progress

@@ Line 177: / Line 177: @@
 The latter builds a SDU and sends to the 'CaMac Proxy', which forward to
 the right MAC instance.
 <br />

DaniloA: /* Weekly Progress */

2015-07-22T10:24:20Z

Weekly Progress

@@ Line 144: / Line 144: @@
 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.
 = Midterm review =

DaniloA: /* Weekly Progress */

2015-07-06T17:10:28Z

Weekly Progress

@@ Line 131: / Line 131: @@
 File:Lte-Enb-CPhy-Sap.bmp|Sap Connection between each Phy Layer object and the LteEnbRrc
 </gallery>
 = Midterm review =

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

2015-06-29T20:55:11Z

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

← Older revision		Revision as of 20:55, 29 June 2015
Line 101:		Line 101:
	* 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		* 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		* 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 ~~different~~ is that in this case the LteEnbPhy is replaced by LteUePhy.		* 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.		* finally, I fix minor problem, such as changing the path in the physical layer traces to find the new position of the LTeEnbPhy object.

← Older revision		Revision as of 12:58, 22 August 2015
Line 286:		Line 286:
	* extend the Rrc messages structure to fit the new fields to configure the carrier aggregation. Mainly I worked on RrcConnectionReconfiguration message.		* 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		* 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		* 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.
	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.		* 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.		* 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.
	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		* 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.		* 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		* 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
	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		* 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.		* change the LteHelper in order to maintain backwards compatibility with user script.