GSOC2014LteFFR

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 2014 Accepted Projects page.

Project overview

  • Project name: LTE Fractional Frequency Reuse algorithms
  • Abstract: The main goal of the project is to extend LTE module to support Fractional Frequency Reuse. I will develop few FFR algorithms. Since power adjustment is the main part of most of FFR schemes, it will be implemented too.
  • About me: I am currently a Master's Degree student in Telecommunication at AGH University of Science and Technology in Cracow, Poland. My interests include network simulations. I have been using ns-2, ns-3 in research projects at my university. I did internship in R&D Center, where I was working and developing ns-3 LTE module.

Approach

Project will be developed incrementally. I will start with simple FFR schemes which require less functionalities to be added. For example, Hard FR and Strict FR divide bandwith into sub-bands, so only functionalities to mute some sub-bands in eNBs and to distinguish in which sub-band UE operates is needed. Then I will develop more complicated FFR schemes, like Soft Frequency Reuse and Enhanced Fractional Frequency Reuse, which require also power adjustment in uplink and downlink. Finally, I will create distributed FFR algorithm, which needs communication between eNBs.

Deliverables

  • FFR algorithms: Hard FR, Strict FFR, Soft Frequency Reuse, Enhanced Fractional Frequency Reuse, Multi-sector Gradient
  • Power adaptation in downlink and power control in uplink
  • methods to support X2-C SON messages (required to implement distributed FFR algorithm Multi-sector Gradient)
  • updating helpers
  • tests and examples
  • documentation

Weekly Reports

Community bonding period

Design phase started during community bonding period.
It was decided that abstract class FfrAlgorithm will be base class for all FFR algorithms implementations. Also three SAPs were defined : FFR-Scheduler-SAP, FFR-MAC-SAP and FFR-RRC-SAP.
In current implementation, scheduler contains vector indicating if RBG is used or not. This vector is filled with "false" values in the begining of scheduling process, so all RBG are available. Proposed idea is that instead of filling this vector with false, scheduler should ask FFR for this map. If FFR set TRUE on some RBG, scheduler will not use it, because it will asses it is already used. This solution is sufficient for simple FFR scheme as Hard Frequency Reuse, where each eNB has only one subband. For other more advanded FFR algorithms, scheduler needs to ask FFR entity if user can be served with this RBG.
Downlink Power Control is needed. RRC-FFR-SAP will have a method to allow the FFR to set the P_A parameter to the RRC. When this method is called, the EnbRRc will trigger an RRC connection reconfiguration, and then call a new CphySap Method to set the per-user transmission power offset (P_A).

Week 1 (May 19, 2014 - May 25, 2014)

First week of coding phase has delivered the following:

  • Implementation of FfrAlgorithm abstract class which will be base class for FFR algorithms
  • Implementation of SAPs: FfrSchedulerSap, FfrMacSap and FfrRrcSap.
  • LteHelper was updated to install FFR entity and SAPs during setting up EnbNetDevice. Now, only PF scheduler is supported
  • Downlink Power Control is almost finished, last thing is to implement RrcConnectionReconfiguration function to inform UE about new P_A value
  • Trivial FFR algorithm which returns always true (so act as without FFR) was created


Week 2 (May 26, 2014 - June 1, 2014)

In summary, this week has delivered the following:

  • Updating FfMacScheduler with FFR SAP -> updating all Schedulers to support FFR SAP
  • Implemented Hard FFR and Strict FFR algorithm, started working on Soft FFR
  • Created simple simulation script based on lena-simple.cc to show how FFR algorithms should be used
  • Updated LteRrcSap with PdschConfigDedicated which contains P_A values (according to TS 36.331 6.3.2 PDSCH-Config)
  • RrcAsn1Header was updated to serialize and deserialize PdschConfigDedicated, it is needed to work LteUeRrcProtocolReal
  • Finished Downlink Power Control, updated RrcConnectionReconfiguration function to inform UE about new P_A value


I have met one problem. FFR algorithms work well in downlink, but in uplink if some RBG is not free (because FFR mutes them), no resources will be assigned. Probably uplink scheduling function needs to be modified a bit more. For example in PF scheduler, we have :

         ...
         uint16_t rbPerFlow = (m_cschedCellConfig.m_ulBandwidth) / (nflows + rntiAllocated.size ());
         ...

When only 1 UE is transmitting, it will get full uplink bandwidth. And nextly:

         ...
         // check availability
         bool free = true;
         for (uint16_t j = rbAllocated; j < rbAllocated + rbPerFlow; j++)
           {
             if (rbMap.at (j) == true)
               {
                 free = false;
                 break;
               }
           }
         if (free)
           {
             uldci.m_rbStart = rbAllocated;
             for (uint16_t j = rbAllocated; j < rbAllocated + rbPerFlow; j++)
               {
                 rbMap.at (j) = true;
                 // store info on allocation for managing ul-cqi interpretation
                 rbgAllocationMap.at (j) = (*it).first;
               }
             rbAllocated += rbPerFlow;
             allocated = true;
             break;
           }
         rbAllocated++;
         if (rbAllocated + rbPerFlow - 1 > m_cschedCellConfig.m_ulBandwidth)
           {
             // limit to physical resources last resource assignment
             rbPerFlow = m_cschedCellConfig.m_ulBandwidth - rbAllocated;
             // at least 3 rbg per flow to ensure TxOpportunity >= 7 bytes
             if (rbPerFlow < 3)
               {
                 // terminate allocation
                 rbPerFlow = 0;                 
               }
             }
         }
         if (!allocated)
         {
           // unable to allocate new resource: finish scheduling
           m_nextRntiUl = (*it).first;
           if (ret.m_dciList.size () > 0)
           {
             m_schedSapUser->SchedUlConfigInd (ret);
           }
           m_allocationMaps.insert (std::pair <uint16_t, std::vector <uint16_t> > (params.m_sfnSf, rbgAllocationMap));
           return;
         }
         ...

If only one RBG from UL Bandwidth is not free, no resources will be allocate to this UE. This code needs to be updated to support UL FFR algorithms and probably in other schedulers also.


During next week I will work on documentation, it will be available here. I am going to finish unit test to check downlink power control. I will desing, discuss with mentors and implement system test to verify downlink power control, and fix problem with uplink scheduling function in PF scheduler. If there will be enough time, I will finish Soft FFR algorithm.

Week 3 (June 2, 2014 - June 8, 2014)

In summary, this week has delivered the following:

  • Implemented test suite lte-downlink-control to check correctness of Downlink Power Control. Three test cases are included in this test suite:
    • LteDownlinkPowerControlSpectrumValue test case checks if LteSpectrumValueHelper::CreateTxPowerSpectralDensity is creating correct spectrum value for PSD for downlink transmission with power control
    • LteDownlinkPowerControlTestCase test case check if TX power difference between data and control channel is equal to configured PdschConfigDedicated::P_A value
    • LteDownlinkPowerControlRrcConnectionReconfiguration test case check if RrcConnectionReconfiguration is performed correctly, when FFR algorithm change P_A value for UE.
  • Implemented test suite lte-downlink-ffr, which checks if RBGs are used correct according to FFR algorithm policy (i.e. if scheduler is not using forbidden RBGs)
  • Implemented test suite lte-interference-ffr, which is similar to lte-interference and checks interference level. The difference is that, in this test case Frequency Reuse algorithms are enabled and interference level is checked on different RBGs (not only on one)
  • Updated test-asn1-encoding to check if PdschConfigDedicated is encoded and decoded correctly
  • Created Downlink Power Control and FFR design and test documentation


I have a problem with documentation generation, because output is broken. Especially figures and equations. Probably configuration or some libs are missing.


I have tried to fix problem with scheduling in uplink, but I did not manage it. I have changed my schedule during last week. I was supposed to finish Soft Frequency Reuse algorithm. Instead of this, I have created a two tests suites to check frequency reuse algorithms in downlink.


During next week I am planing to:

  • finish Soft Frequency Reuse algorithm (on Monday)
  • fix problem with scheduling in uplink (firstly in PF scheduler)
  • create tests to check if frequency reuse algorithms work correctly also in uplink
  • create test to check if Soft Frequency Reuse algorithm is serving UE with proper power and RBGs, based on UE measurement

Week 4 (June 9, 2014 - June 15, 2014)

In summary, this week has delivered the following:

  • Finished Soft Frequency Reuse algorithm -Implemented Sofr Fractional Frequency Reuse algorithm
  • Created figures to design documentation
  • Created interface to automatically configure Frequency Reuse Algorithm with only 1 attribute
  • Fixed problem with uplink scheduling with frequency reuse algorithm
  • Updated tests to chceck if muted RBs are not used in uplink; also updated tests with new attributes in downlink, because they crashed
  • Updated test of Strict FR algorithm, to chceck if UEs are served in different subbands according to its UE Measurements

Moreover, during discussion with my mentors, we agreed solution for UL scheduling with FR problem. Second thing we discussed is CQI generation. In current implementation CQI messages are generated based on control channels measurements. Frequency reuse algorithms are used only for data channels and control channels are transmitted over entire cell bandwidth, o SINR value is lower for them and UE is served with lower MSC scheme. We have to find solution for that, otherwise the only one thing, which will be improved is BER for data channels, it means that UE will be served with low MSC and very high SINR, what is inefficient.

During next week I will look for solution for UL scheduling problem. I will create user and update test documentation. I will create test to check if Soft Frequency Reuse algorithm is serving UE with proper power and RBGs, based on UE measurement. If we will find solution for CQI generation and there will be enough time, I will work on it.

Week 5 (June 16, 2014 - June 22, 2014)

In summary, this week has delivered the following:

  • Fix for uplink scheduling problem, now also RAR is performed with Frequency Reuse policy
  • Updated automatic FR configuration to work also in UL
  • Created new tests, which check if UE is served with proper power level and RBGs in downlink
  • Created user documentation
  • Updated test documentation
  • Preparation code to mid-term review

During next week I will work with my mentors on mid-term code review. We will also try to agree solution for CQI generation and I will implement it. I will start implementation of Enhanced Fractional Frequency Reuse algorithm and tests.

Mid-term Code Review (June 23, 2014 - June 27, 2014)

Mid-term code review starts at the beginning of this week.

The code to be reviewed can be found in Rietveld issue 110020049. https://codereview.appspot.com/110020049/ The review covers all the changes from the beginning of the project, so patch contains:

  • FfrAlgorithm abstract class
  • Two SAPs FfrSchedulerSap and FfrRrcSap
  • Updated all schedulers and eNB RRC with new SAPs
  • Updated LteHelper
  • Downlink Power Control
  • Updated RrcAsn1Header with PdschConfigDedicated structure
  • Frequency Reuse Algorithms:
    • Trivial FR algorithm
    • Hard FR algorithm
    • Strict FR algorithm
    • Soft FR algorithm
    • Soft FFR algorithm
  • Tests:
    • lte-downlink-power-control to check correctness of Downlink Power Control
    • lte-frequency-reuse to check if scheduler is not using forbidden RBGs, and if UE is served with proper power and RBGs in downlink according to FFR algorithm policy
    • lte-interference-fr checks interference level with Hard and Strict FR algorithms
  • Design and test documentation
  • Automatic Frequency Reuse configuration in DL and UL (cell can be configured with only 1 attribute)
  • Fixed problem with uplink scheduling with frequency reuse algorithm
  • Examples (in scratch directory) show how FR algorithms can be configured:
    • lena-fr-simple
    • lena-hard-fr
    • lena-strict-fr
    • lena-soft-fr
    • lena-soft-ffr

There are 3 test suites of interest, which can be run as follows:

  • ./test.py -s lte-downlink-power-control
  • ./test.py -s lte-frequency-reuse
  • ./test.py -s lte-interference-fr

Week 6 (June 23, 2014 - June 29, 2014)

In summary, this week has delivered the following:

  • Addressed the comments on the mid-term code review
  • Removed additional bandwidth configuration in FR algorithms, now it is configured durign cell configuraiton
  • Added Doxygen descriptions
  • Added automatic configuration for 15 RB bandwidth
  • During last discussion with my mentors, we agreed solution for CQI generation and I started to implement it
  • Started implementing Enhanced Fractional Frequency Reuse algorithm

During next week I will:

  • review Krishna Teja Mid-Term code
  • finish CQI implementation and write test for it
  • finish EFFR algorithm and write test for it
  • update design and user documentation

Week 7 (June 30, 2014 - July 6, 2014)

In summary, this week has delivered the following:

  • Review Krishna Teja Mid-Term code
  • Extended SAP to pass CQI from scheduler to FR algorithm
  • Implementation of new CQI generation approach
  • Implementation of EFFR algorithm
  • Code refactoring of LteSinrChunkProcessor (renamed to LteChunkProcessor, removed Lte***ChunkProcessors classes, added callback list)

I did not created tests during last week, because I spend more time on CQI generation. I implemented one solution, but after discussion with my mentors, we decided it should be changed and I spend more time to implement it once again in different way. Moreover, I refactored code of LteSinrChunkProcessor (which was not planned), but there was bug and some LTE test were crushing. Fortunately I fixed this.

During next week I will:

  • write test for EFFR
  • write test for new CQI generation
  • update design and user documentation
  • start working on distributed FR schemes


Week 8 (July 7, 2014 - July 13, 2014)

In summary, this week has delivered the following:

  • Created tests for EFFR
  • Created tests for CQI generation
  • Updated design and user documentation
  • Tried to fix HARQ bug, which appeard when EFFR algorithm is used
  • Started working on distributed frequency reuse algorithm (checked X2 communication between two FR entities)

During last discussion with my mentors we were talking on distributed frequency reuse algorithm. It turned out, that algorithm (Multi-Sector Gradient, MGR [4]) I have planned to implement needs X2-interface to be expanded. I was afraid that it can not be simply expanded, because current LTE standards do not provide description on this topic. We agreed that firstly we will try to find different distributed FR algorithm which is using messages available in X2-Interface (i.e. Relative Narrowband Transmit Power, RNTP), and if we will not manage this, we will expand X2-interface with VendorSpecific fields and implement MGR algorithm.

During next week I will:

  • try to fix HARQ bug
  • connect FR algorithms with different MAC Schedulers (at least with PSS, CQA, TBFQ)
  • implement distributed frequency reuse algorithm (MGR or different)
  • write test (if there will be enough time)
  • update design and user documentation (if there will be enough time)


Week 9 (July 14, 2014 - July 20, 2014)

In summary, this week has delivered the following:

  • Implemented distributed frequency reuse algorithm (finally we decided to implement algorithm described in [4], which fits LTE standards more)
  • Updated design and user documentation
  • Connected FR algorithms with PSS, CQA, TBFQ Schedulers

Firstly, I wanted to implement Multi-Sector Gradient FR algorithm, but it turned out, that it does not fit LTE standards, (expanded X2-interface is needed, moreover MGR requires downlink power allocation to be continous but there are only 8 quantized P_a values). On Thursday, I found distributed FFR algorithm [4], that utilizes available X2-interface messages (i.e. RNTP). I have tried to fix bug with HARQ, which occurs with EFFR algorithm, but I did not manage to it. It needs more investigation, as this problem do not appear always.

During next week I will:

  • try to fix HARQ bug
  • write test for distributed FFR scheme
  • write tests for all supported schedulers
  • start working on UL POWER CONTROL

Week 10 (July 21, 2014 - July 27, 2014)

In summary, this week has delivered the following:

  • Found and fixed HARQ bug in all schedulers
  • Implemented test for distributed FFR scheme
  • Implemented tests for all supported schedulers
  • Implemented Uplink Power Control + tests

I planned to only start implementation of Uplink Power Control, but I manage to finish it. During this week, I will post my current code repo to start process of final code review and I will connect Uplink Power Control to FR algorithms. I think this week will be the last one of implementation of new features.

During next week I will:

  • send code to start final code review
  • connect Uplink Power Control with Frequency Reuse schemes
  • write test documentation for distributed FFR scheme
  • write design, user and test documentation for Uplink Power Control

Week 11 (July 28, 2014 - August 10, 2014)

In summary, this week has delivered the following:

  • Started process of final code review
  • Connected Uplink Power Control with Frequency Reuse schemes
  • Created tests for FR algorithms with PF, PSS, CQA, TD-TBFQ, FD-TBFQ
  • Created test documentation for distributed FFR scheme
  • Created design, user and test documentation for Uplink Power Control
  • Found and fixed next HARQ bug
  • Fixed errors and warnings occured in documentation generation
  • Fixed valgring errors

During next week I will:

  • create test for FR algorithms with Uplink Power Control + test documentation
  • create example scenario to show FR algorithms functionality (probably dual-stripe scenario will be extended) + user documentation
  • create Radio Environment Maps for different FR schemes, RadioEnvironmentMapHelper needs to be updated, to collect values only for 1 RB
  • create traces with Spectrum Analyzer for different FR schemes
  • apply comments from code review

Week 12 (August 11, 2014 - August 17, 2014)

In summary, this week has delivered the following:

  • applied comments form code review
  • created tests for FR schemes with Uplink Power Control
  • created test for FR algorithms with Uplink Power Control + test documentation
  • created examples to show FR algorithms functionality (extended lena-dual-stripe, one simple example for Hard FR, Strict FR, Soft FR, Soft FFR and Enhanced FFR schemes, one simple example for Distributed FFR)
  • updated RadioEnvironmentMapHelper to collect values from Data/Control channel and from specified RbId
  • added RadioEnvironmentMapHelper to example
  • added Spectrum Analyzer to example
  • refactored FfrCellId -> FrCellTypeId
  • made Uplink Power Control in Accumulated Mode enabled by default
  • extended SIB2 with referenceSignalPower and removed attribute to configure it manually in UePowerControl

During next week I will:

  • create/update user documentation about FR examples
  • update RELEASE NOTES and CHANGES.html
  • make FR to be reconfigurable at any time (now is configured once before simulation start)