GSOC2014LteFFR

From Nsnam
Revision as of 21:58, 1 June 2014 by Pgawlowicz (Talk | contribs) (week 2)

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.