Difference between revisions of "GSOC2013UeMeasurementActiveIdle"

From Nsnam
Jump to: navigation, search
m (A1 threshold in test)
(Weekly report (week 26))
Line 156: Line 156:
 
[[File:Lte-ue-meas-piecewise-test-case-1-rsrp.png|thumbnail|Trace of RSRP perceived by the UE during the UE measurement piecewise test case 1.]]
 
[[File:Lte-ue-meas-piecewise-test-case-1-rsrp.png|thumbnail|Trace of RSRP perceived by the UE during the UE measurement piecewise test case 1.]]
  
This week is the first week of the coding phase. It delivered the following:
+
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 <code>LteEnbRrc::AddUeMeasReportConfig</code>. Consequently, the previously predefined Event A2 and A4 in <code>UeManager::BuildMeasConfig</code> have been removed. Other related changes are as follow:
 
* ''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 <code>LteEnbRrc::AddUeMeasReportConfig</code>. Consequently, the previously predefined Event A2 and A4 in <code>UeManager::BuildMeasConfig</code> have been removed. Other related changes are as follow:
Line 164: Line 164:
  
 
* ''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.
 
* ''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 with 3 test cases of this type, using 0, 54, and 97 as the threshold, respectively.
+
** 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 ===
 +
 
 +
[[File:Lte-ue-meas-piecewise-test-case-2-rsrp.png|thumbnail|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 <code>UeManager::BuildMeasConfig</code>, 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 <code>LteUeMeasurementsTestCase</code>, which has been fixed last week. The others are fixed this week, which include <code>LteX2HandoverMeasuresTestCase</code> and ''lena-x2-handover-measures'' example.
 +
** The automatic handover and neighbour relation mechanism, which is located in <code>UeManager::RecvMeasurementReport</code>, 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 currently running. The following deliverables are on the plan this week:
 +
 
 +
* Adding more test scenarios to the handover test case.
 +
 
 +
* Implementation of time-to-trigger in every event-based triggering criterion.
 +
 
 +
* New test scenarios with hysteresis and time-to-trigger.
 +
 
 +
* Updating design, testing, and user documentation.

Revision as of 13:36, 28 June 2013

Project overview

  • Project name: Improvements to UE Measurements in Active and Idle Mode for the LTE Module
  • 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.
  • 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


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
    • D4: Interface for configuring reporting
    • D5: Piecewise testing framework case 1
    • Milestone-I: Basic serving cell measurement complete
    • D6: Event A3 evaluator
    • D7: Event A5 evaluator
    • 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: UE measurement during IDLE_CELL_SELECTION
    • E4: UE attachment to the strongest cell
    • E5: RSRP option for REM
    • E6: Test case with fast fading
    • E7: Test case with buildings
    • Milestone-IV: Initial cell selection is verified
    • E8: Test documentation
  • Deliverables related to handover algorithms:
    • F1: Design documentation
    • F2: Choice of reference publication
    • F3: Test vector definition
    • F4: Handover algorithm SAP interface
    • F5: Strongest-cell algorithm
    • F6: Topology helper for test simulation
    • Milestone-V: Ideal handover functionality is ready
    • F7: Ping-pong detector
    • F8: Ping-pong test case
    • F9: Example updated
    • F10: Failure case during Random Access
    • F11: Failure case during RRC Connection Reconfiguration
    • F12: Failure test case
    • Milestone-VI: Realistic handover functionality is ready
    • F13: Test suite for model validation with reference publication
    • F14: Analysis of model validation
    • Milestone-VII: Handover model is validated
    • F15: UTPR algorithm
    • F16: Test case updated
    • Milestone-VIII: Second handover model is validated
    • F17: Test documentation updated


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, E6
  • Week 30: E7, Milestone-IV, E8, 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: F2, F3, F4
  • Week 33: F5, F6, Milestone-V,
  • Week 34: F7, F8, F9, F10
  • Week 35: F11, F12, Milestone-VI, F13
  • Week 36: F14, Milestone-VII, F15
  • Week 37: F16, Milestone-VIII, F17

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 currently running. The following deliverables are on the plan this week:

  • Adding more test scenarios to the handover test case.
  • Implementation of time-to-trigger in every event-based triggering criterion.
  • New test scenarios with hysteresis and time-to-trigger.
  • Updating design, testing, and user documentation.