From Nsnam
Revision as of 12:32, 4 June 2013 by Nicolabaldo (Talk | contribs) (Project overview)

Jump to: navigation, search

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.


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.


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


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: Periodical reporting criteria
    • D4: Event A1 evaluator
    • D5: Event A3 evaluator
    • D6: Event A5 evaluator
    • Milestone-I: Immediate reporting criteria are complete
    • D7: Support for time-to-trigger
    • Milestone-II: Time-to-trigger support is ready
    • D8: Modular interface for configuring reporting
    • D9: Test case verifying different combinations of configuration
    • Milestone-III: Reporting is configurable
    • D10: Test documentation
  • 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


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, D6, Milestone-I
  • Week 26: D7, Milestone-II, D8
  • Week 27: D9, Milestone-III, D10
  • Week 28: E1, 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).