GSOC2013UeMeasurementActiveIdle

Project overview

• Project name: Improvements to UE Measurements in Active and Idle Mode for the LTE Module

• Student: Budiarto Herman

• Mentors: Nicola Baldo, Marco Miozzo, Manuel Requena, Jaime Ferragut

• Abstract: The LTE module of ns-3 was recently updated (LENA M6) with support for UE measurements and automatic handover. The project aims to improve these models with more advanced features based on 3GPP E-UTRAN specifications and several research publications. The development covers three major features: UE measurements, initial cell selection, and handover algorithms.

• Related links:
  • Code repository
  • Mid-term code review
  • Mid-term evaluation report
  • Final evaluation report

• About me (the student). I'm a Master's student in University of Jyväskylä, Finland. Radio technology is my major subject study and I'm working on simulations of LTE using ns-3.

Approach

The project is divided into three major blocks:

UE measurements

Additional reporting configuration to UE measurement model.

Initial cell selection

UE mechanism to automatically determine the best eNodeB to attach to, based on RSRP.

Handover algorithms

Two additional handover algorithms for automatic handover execution.

The UE measurements block can be said as the core piece of the project, because the other blocks are dependant on it. For instance, initial cell selection utilizes the measurements of RSRP gathered during UE's idle state. While handover algorithms will request certain measurements and consume them during UE's active state.

Code base

The development will be conducted using the latest revision of LENA (Mercurial repository) as the code base. The reason behind this decision is the fact that several important features are not yet available in ns-3-dev repository at the time the project begins. For example, LENA M6 was released with some supports of UE measurements and automatic handover, which are essential for the project.

During the course of the project, updates in LENA repository may be pulled to the project repository on a case-by-case basis.

Methodology

Despite the dependencies, each of the project blocks are designed to be cohesive by itself. Hence the project will focus on one block at a time, and then move on to the next block. The development of each block includes the actual code, test code, documentation, and code review. Progress will be published in frequent basis to the public repository.

The following pseudocode illustrates the procedure outlined above.

 for each project block X
   write design documentation of X
   define test vector of X
   implement X
   write test code for X
   write test documentation for X
   submit X to rietveld for code review
 end for

Standard Deliverables

Each deliverable is labeled with a letter and an integer. The letter corresponds to the block which the deliverable is associated with.

• Deliverables related to UE measurements:
  • D1: Design documentation
  • D2: Test vector definition
  • D3: Event A1 evaluator (serving > threshold)
  • D4: Interface for configuring reporting
  • D5: Piecewise testing framework case 1
  • Milestone-I: Basic serving cell measurement complete
  • D6: Event A3 evaluator (neighbour > serving + offset)
  • D7: Event A5 evaluator (serving < threshold1 AND neighbour > threshold2)
  • D8: Piecewise testing framework case 2
  • D9: Handover testing framework
  • Milestone-II: Neighbouring cell measurement complete
  • D10: Support for time-to-trigger
  • D11: Updated documentation
  • Milestone-III: UE measurements complete

• Deliverables related to initial cell selection:
  • E1: Design documentation
  • E2: Test vector definition
  • E3: SIB1 implementation
  • E4: Cell search implementation
  • E5: Simple initial cell selection
  • E6: Initial cell selection with criteria
  • Milestone-IV: Initial cell selection is verified
  • E7: Test documentation

• Deliverables related to handover algorithms:
  • F1: Handover management SAP interface
  • F2: Event A2 and RSRQ-based handover algorithm
  • F3: Helper function for selecting handover algorithm
  • F4: Updated test suite
  • F5: Updated example program
  • Milestone-V: Basic handover algorithm functionality is ready
  • F6: ANR SAP interface
  • F7: Simple ANR as UE measurements consumer
  • Milestone-VI: Simple ANR is ready
  • F8: Strongest cell handover algorithm
  • F9: Strongest cell handover algorithm test case
  • F10: Handover design documentation
  • F11: Handover testing documentation
  • Milestone-VII: Strongest cell handover algorithm is ready

Schedule

After acceptance notice is announced in the beginning of Week 22 (May 27), the project will enter the community bonding period, which consist of the following activities:

• Setting up a Wiki account
• Setting up access to repository
• Initial meeting with mentors
• Answering questions in ns-3-users
• D1
• D2

Then at Week 25 (June 17) the coding phase will begin. The first half of the project is planned as follow:

• Week 25: D3, D4, D5, Milestone-I
• Week 26: D6, D7, D8, D9, Milestone-II
• Week 27: D10, D11, Milestone-III, E1
• Week 28: E2, E3
• Week 29: E4, E5
• Week 30: E6, Milestone-IV, E7, F1

Week 31 (July 29) will be reserved for mid-term evaluation. After that (August 5), the second half of the project will begin as below:

• Week 32: F1, F2, F3, F4, F5, Milestone-V
• Week 33: F6, F7, Milestone-VI, F8, F9
• Week 34: F10, F11, Milestone-VII
• Week 35: Reserved for future deliverables (TBD)
• Week 36: Reserved for future deliverables (TBD)
• Week 37: Reserved for future deliverables (TBD)

Week 38 (September 16) will be the pencil down week, and Week 39 (September 23) will be allocated for the final evaluation.

Progress Report

Reports on progress are divided into weekly, mid-term, and final reports. The weekly reports will be available in this section after the end of the corresponding week. On the other hand, the other types of reports are available from separate Wiki pages (mid-term evaluation report and final evaluation report).

Community bonding period

The community bonding period has delivered the preliminary design documentation of UE measurements. This is split into design, user, and testing documentation.

Week 25

Trace of RSRP perceived by the UE during the UE measurement piecewise test case 1.

This week is the first week of the first coding phase. It has delivered the following:

• Interface for configuring UE measurements. eNodeB now maintains the list of measurements configuration that will apply to all attached UEs. This list is initially empty (except the definitive measurement object and quantity configuration), and can be populated by calling the new public function LteEnbRrc::AddUeMeasReportConfig. Consequently, the previously predefined Event A2 and A4 in UeManager::BuildMeasConfig have been removed. Other related changes are as follow:
  • LteUeMeasurementsTestCase has been updated accordingly to explicitly add Event A2 and A4 to the simulation.
  • All report intervals are now implemented.
  • Layer 3 filtering (i.e. quantity configuration) is now configurable from new attributes of eNodeB RRC.

• The first test framework for UE measurements (piecewise case 1). It is a simulation of 1 eNodeB and 1 UE without EPC in a flat channel and no layer 3 filtering. The test verifies that the timing and the RSRP content of measurement reports received by the eNodeB are the same as the reference test vector. In the simulation, the UE is moving between 4 different predefined location to vary the perceived RSRP strength (see figure on the right), which will trigger several entering and leaving conditions.
  • Event A1 has been verified by 3 test cases of this type, using 0, 54, and 97 as the threshold, respectively.
  • The figure on the right illustrates the movement of the UE and the resulting RSRP measurements.

• Layer 3 filtering. As shown in the figure on the right, the filtering seems to average the measurements in an expected way. However, it also brings difficulties to the test script because past measurements are disturbing the results. Therefore layer 3 filtering is disabled in the test cases.

Week 26

Trace of RSRP perceived by the UE during the UE measurement piecewise test case 2.

This week is the second week of the first coding phase. It has delivered the following:

• Complete event-based triggering criteria. Implemented Event A3 and A5. Event A1 was implemented last week, while Event A2 and A4 were part of LENA already when the project started. Hence, all the triggering criteria aimed by the project have been implemented.

• Completed the first test framework for UE measurements (piecewise case 1). Event A1 has been tested since last week. This week the remaining events (A2, A3, A4, and A5) have been added to the test suite.

• The second test framework for UE measurements (piecewise case 2). Similar to the first framework from last week, but now considering the effect of a neighbouring cell.
  • This test case is necessary to verify the event-based triggering criteria which are based on reported measurements of neighbouring cell, such as Event A3, A4, and A5.
  • The figure on the right illustrates the movement of the UE and the resulting RSRP measurements.
  • Scenarios in this test case uses longer report interval than in piecewise test case 1 (240 ms, compared to 120 ms) and shorter distance between the predefined teleport spots.
  • Each of event-based triggering criteria has been verified by 3 test cases of this type, using 0, 58, and 97 as the threshold, respectively.

• Initial work on the third test framework for UE measurements (handover case). Verifying that UE measurements configuration works properly with handover in an EPC-enabled simulation.
  • One test scenario using Event A1 has been included in the test suite.

• Updated handover test case and example. As a result of last week's disposal of UeManager::BuildMeasConfig, some existing examples and test cases are no longer working because they depend on predefined Event A2 and A4. One of these test cases is LteUeMeasurementsTestCase, which has been fixed last week. The others are fixed this week, which include LteX2HandoverMeasuresTestCase and lena-x2-handover-measures example.
  • The automatic handover and neighbour relation mechanism, which is located in UeManager::RecvMeasurementReport, still depend on Event A2 and A4, respectively. These two have not been fixed yet, because of the fact that they are planned to be substituted by handover algorithms, which will be developed at the second phase of this project.

Week 27

This week is the third week of the first coding phase. It has delivered the following:

• Completed handover test case. The test case verifies that UE correctly updates its measurements configuration when moving from one cell to another cell with a different measurements configuration. This week, more test scenarios are added to the UE measurements test suite, covering cases where changes of measurement configuration to different report interval, different event type, and different threshold/offset.

• Test scenarios for hysteresis. Hysteresis is used to delay the triggering of reporting events by h dB, i.e. the entering and leaving conditions become h dB more difficult to achieve. The UE measurements test suites now include several scenarios with hysteresis enabled to verify its behaviour.

• Code review. The first code review (Rietveld issue 10742043) with Tom and Nicola as the reviewers. The code has been updated according to the received feedback.

• Detailed design of initial cell selection. The first project block is planned to be completed by the end of this week. The second project block, the initial cell selection, will start next week. New sections have been added to the documentation to describe the idea of initial cell selection. Together with my mentors, we discussed several design issues, and finally have a clear implementation idea for the next 3 weeks.

There is an issue with time-to-trigger implementation this week. The previously planned implementation turns out producing behaviour not in accord with 3GPP specification. Time-to-trigger is supposed to delay the reporting trigger by t ms, but the previous design unexpectedly rounded t to the multiplies of 200 (i.e. the trigger point becomes dependent to the rate of measurement reports from PHY layer). Because of this, I rewrote the idea and then attempted to rebuild it, but did not manage to complete in time. Thus time-to-trigger spills off to the next week.

Week 28

This week is the fourth week of the first coding phase. The second block of project, initial cell selection, is started here. This week has delivered the following:

• Completed time-to-trigger implementation. UE measurements now support time-to-trigger, a parameter to delay measurement reports by certain unit of time. It is a useful parameter to configure in order to reduce occurrences of ping-pong handovers and Radio Link Failures.

• Completed time-to-trigger tests. The UE measurements test suites have been updated to verify time-to-trigger parameter in each of 5 event-based triggering criteria. In each cases, 3 different time-to-trigger values are tested. For example, a longer the time-to-trigger gives the UE more room to cancel a possible trigger, therefore producing more resistance to short-term fluctuation in signal strength.

• Updated documentation. UE measurements model documentation is now up-to-date with the latest implementation. Some works have also been done on improving the initial cell selection, but most part is still waiting for a clear implementation idea.

Hence, the UE measurements block are now ready to be reviewed as a whole.

Regarding initial cell selection, the implementation of System Information Block Type 1 (SIB1) is scheduled this week. The development and discussions with mentors are currently ongoing. While going through the discussions, I have learned that there are several technical assumptions about initial cell selection in LTE and impact to existing code that I was not aware of. Therefore I decided to rearrange the implementation idea before moving further.

Week 29

This week is the fifth week of the first coding phase. It has delivered the following:

• Implementation of SIB1. A system broadcast message with information related to cell access, transmitted by PHY every 20 ms.

• Implementation of cell search procedure. A procedure by UE PHY, typically performed at the beginning of simulation. It basically detects surrounding cells using Primary Synchronization Signal (PSS), synchronize to the one with strongest RSRP, and listen to the broadcast channel looking for system information messages.

• Implementation of simple initial cell selection procedure. After cell search procedure is done and required system information has been received, the UE will camp to the cell indicated by the cell search procedure. Test scenarios have been included to verify this.

The complete form of initial cell selection procedure will perform additional evaluation before camping to the cell. The criteria evaluated are Public Land Mobile Network (PLMN) identity (e.g. in scenarios with multiple network operator), Closed Subscriber Group (CSG) identity (e.g. in scenarios with small cells), minimum level of signal reception level/quality. This feature will be developed next week.

The introduction of cell search and initial cell selection has impacted the existing code in LTE module. Firstly, there has to be new helper functions to control these features, which also have to be included in user documentation. Secondly, at least there are one test suite (lte-pathloss) and one example (buildings-pathloss-profiler) which fail and have to be fixed. These will be taken care of next week.

Week 30

This week is the sixth week of the coding phase, and also the last week of the first coding phase. The second block of the project, initial cell selection, ends here. This week has delivered the following:

• Complete initial cell selection. Added CSG identity and minimum level of RSRP as cell selection criteria. For instance, when a cell is designated as a CSG, only UEs which are members of the CSG can gain access to the cell. This feature can be useful to simulate scenarios with femtocells. New test scenarios are added to test this functionality. The design and user documentation have also been updated.

• Mid-term code review. Started at the beginning of this week, using revision 9928 as the base and 9984 as the head. Several comments have been received and more is expected to come next week.

• Fix to test script. The lte-pathloss test suite, which was found to fail last week, has been fixed. While the buildings-pathloss-profiler has not been fixed yet, but can probably be fixed by pulling new updates from LENA development repository.

Week 31

This week is the mid-term evaluation week. The project progressed as follows:

• Addressing issues identified in mid-term code review. The mid-term code review was started the week before and has received comments from mentors. The comments are mostly aimed at initial cell selection, for example regarding naming of variables/functions, an issue with code duplication in RSRP/RSRQ calculation, and an impact to CQI reporting. Also highlighted here is the importance of layer-by-layer invocation of functions, for example cell search should follow NetDevice → NAS → RRC → PHY call flow. The necessary fixes have been done and committed to the repository. More details can be found in the mid-term's Rietveld issue.

• Mid-term evaluation. The evaluation consists of several multiple-choice and open-ended questions regarding my opinion on the project. The answers were submitted to Google Melange web site. Later I received an email stating that the project successfully passed the mid-term evaluation.

• Finalizing initial cell selection documentation. The initial cell selection block has been a subject of intensive discussion with mentors. The latest discussion has clarified the remaining open issues, such as the removal of PLMN selection criteria, the decision to keep the AttachToClosestEnb helper function (for the sake of LTE-only simulation in lena-dual-stripe example), and the behaviour of Attach helper functions to consistently switch UE to CONNECTED mode. The documentation has been updated to reflect these clarifications.

• Discussion on handover algorithm. The last conversation with mentors also dealt with the next development block of the project, handover algorithm. We broke the block down to several pieces and set the priority on each piece. The development approach can be summarized as follows:
  • The most essential piece to be implemented are the handover management SAP interface (i.e. the communication interface between the eNodeB RRC entity and the handover algorithm entity).
  • The next important pieces are the implementation of two handover algorithms, one based on RSRQ and Event A2 (serving is worse than threshold, therefore mimicking the existing algorithm embedded in LENA M6), and the other one is based in RSRP and Event A3 (neighbour is offset better than serving, which is one of the algorithms commonly cited in research papers).
  • The next pieces are of lower priority and require considerable effort to implement. These are the UE Transmit Power Reduction (UTPR) handover algorithm, three important cases of handover failures, comparison with a published result, and other statistics such as ping-pong handover. These are only to be implemented when the previous pieces have been completed and there is enough time before the project ends.

Week 32

Trace of RSRQ perceived by UE and occurence of handover (using Event A2-based legacy handover algorithm) during lena-x2-handover-measures example program.

This week is the start of the second half of the project. The development of the handover algorithm block is handled during this time. This week in particular has delivered the following:

• Handover management SAP interface. Service Access Point (SAP) is a framework used in the LTE module for handling communication of 2 entities in a modular way. For example, UE RRC and UE PHY exchange messages via UE CPHY SAP. Similarly, handover algorithm and eNodeB RRC exchange message via Handover management SAP. The SAP defines the allowed methods and the expected parameters for both ways of communication. For example:
  • The handover algorithm entity may request a UE measurement configuration from the eNodeB RRC entity.
  • Then the eNodeB RRC entity fulfil it by providing the handover algorithm entity with measurement reports.
  • After reviewing the measurement reports, the handover algorithm may suggest the eNodeB RRC entity that a handover should be performed by a particular UE.

• Event A2 and RSRQ-based handover algorithm. The first working implementation of the handover management SAP interface. The behavior is based on the built-in algorithm from LENA release M5, hence the name "legacy" for the handover algorithm. The related code embedded in eNodeB RRC is simply moved to a separate handover algorithm class. The attributes for configuring the algorithm are also moved to the handover algorithm class itself. In addition, the related test cases and examples have been updated accordingly.

• Helper function for selecting handover algorithm. Within the module architecture, the handover algorithm is an independent entity attached to the eNodeB RRC entity. The attachment is modeled in a similar way as how FF MAC Scheduler entity is attached to the eNodeB MAC entity (e.g. by using Object Factory). This means that user may select the handover algorithm by changing an attribute of the LTE Helper class.

• No-op handover algorithm. An empty handover algorithm to produce simulation without automatic handover. This is set as the default algorithm for the handover algorithm Object Factory of the LTE Helper, and is useful for the existing test scripts and example programs.

As a result of this week's development, the existing Neighbour Relation Table (NRT) functionality has been impacted. This function had utilized the Event A4-based measurement reports which have been shared together with the built-in handover algorithm. This dependency will be sorted out next week, by converting the NRT to a simplified version of Automatic Neighbour Relation (ANR) function.

Week 33

Trace of RSRP perceived by UE and occurence of handover (using Event A3-based strongest cell handover algorithm) during lena-x2-handover-measures example program.

This week is the second week of the second coding phase. It has delivered the following:

• Simple ANR. The function communicates with eNodeB RRC via a new SAP interface. The function provides storage of information related to the eNodeB's neighbouring cells, while the interface provide the methods for querying and manipulating the information. New entry is automatically created when X2 connection is constructed and when new neighbour cell is detected (through Event A4 UE measurements). Advanced ANR features such as automatic setup of X2 connection are not supported.

• Strongest cell handover algorithm. A new implementation of the abstract handover algorithm base class, which works based on RSRP and Event A3 (neighbour cell's RSRP becomes offset better than serving cell's RSRP). The lte-x2-handover-measures test suite is updated to test this new algorithm.

Week 34

This week is the third week of the second coding phase. It has delivered the following:

• Documentation of ANR. Added one section in the design documentation for ANR functionality.

• Documentation of handover algorithm. This covers the design, user, and testing sections of LTE module documentation. The design documentation has some updates regarding handover in general, updated figures, and new sections for the handover algorithms implemented in the project. The user documentation has some updates on the code that users can use to select handover algorithms. And finally testing documentation has been updated with the inclusion of strongest cell handover algorithm in the test suite.

• Merge attempt with lena-dev. In order to prepare a merge with LENA development repository (lena-dev), a new ns-3 repository has been created with the name of ns-3-gsoc-lte-merge. The idea is to keep the standard set of deliverables in this repository, freeze them, and repeatedly review the whole code until it is good enough for merging with lena-dev. The repository is based on the latest revision of lena-dev (revision 10108 as of the time of writing), then changes from the GSoC repository are pulled in and merged. The new repository has successfully passed a full-blown ./test.py. Hence, the merge has also fixed the failure in buildings-pathloss-profiler example that was discovered earlier.

As scheduled, all standard deliverables have been completed by the end of this week. The remaining 3 weeks of development time in the project will be used to develop some selected future deliverables. Development continues as usual in the main GSoC repository.

Week 35

This week is the third week of the second coding phase. It has delivered the following:

• Proposed new UE RRC state model. The new state model has expanded the IDLE_CELL_SELECTION state to several states: IDLE_CELL_SEARCH, IDLE_WAIT_MIB_SIB1, and IDLE_WAIT_SIB1. This has the benefit of

• Detailed design of handover failure scenarios, which may involve the development of several new features, such as RRC Connection Re-establishment and Radio Link Failure.

At the same time, review process will be conducted on the ns-3-gsoc-lte-merge repository created last week.

Future Deliverables

Several other development ideas were proposed in the beginning of the project. However, after several discussions with mentors, these ideas are deferred as low priority. They are listed below for future reference.

They are listed below for future reference and for re-prioritization by the time the standard deliverables are completed. Some of these ideas will be developed on the last 3 weeks of the project's coding phase, while the rest will spill outside the scope of the GSoC project.

Proposed UE RRC state machine

• Deliverables related to general improvement of RRC:
  • Clarification whether MIB is required for decoding SIB1
  • New UE RRC state machine (see figure on the right)

• Deliverables related to UE measurements:
  • Enumerated time-to-trigger values (section 6.3.5 3GPP TS 36.331)

• Deliverables related to initial cell selection:
  • Initial cell selection support for LTE-only simulation
  • Deprecated attachment based on shortest distance

• Deliverables related to realistic handover functionality:
  • RRC connection re-establishment procedure
  • Case of Random Access failure
  • Radio Link Failure
  • Case of handover command failure
  • Handover failure test cases

• Deliverables related to handover towards CSG cell:
  • UE measurements for CGI reporting purpose
  • CSG restriction in handover
  • Test case of handover with CSG cell

• Deliverables related to UTPR handover algorithm:
  • Interface for gathering eNodeB statistics (e.g. Tx power, RIP)
  • Interface for gathering UE statistics (e.g. Tx power, UL channel gain)
  • UTPR handover algorithm
  • UTPR handover algorithm test case
  • UTPR algorithm documentation

• Deliverables related to handover model validation:
  • Choice of reference publication
  • Reference path loss model
  • Topology helper for simulation
  • Ping-pong detector
  • Ping-pong test case
  • Simulation program for model validation
  • Analysis of model validation