GSOC2024Channels5G

Main Page - Roadmap - Summer Projects - Project Ideas - Developer FAQ - Tools - Related Projects

HOWTOs - Installation - Troubleshooting - User FAQ - Samples - Models - Education - Contributed Code - Papers

Back to GSoC 2024 projects

Project Overview

• Project Name: 5G NR Module Benchmark and Analysis for Distinct Channel Models
• Student: Joao Albuquerque
• Mentors: Biljana Bojovic, Amir Ashtari, Gabriel Ferreira
• Google page: GSoC - Project
• Project Goals: Currently, ns-3 and the NR module provide an interface for using a channel model (3GPP). However, two other models have also been developed using the ns-3 environment: Two-ray and NYUSim. The project aims to integrate these two new models into NR module in a simplified and user-friendly manner. Furthermore, I will undertake additional tasks, such as testing the implemented code and creating an example that utilizes these implemented models.
• Repository: ns-3, NR
• About Me: I am an undergraduate student working at LASSE-UFPA, a telecommunications research laboratory, where I have been engaged in various projects using the ns-3 and nr. I have over a year and four months of experience working with ns-3 and the nr module, during which I developed applications, including a new ray-tracing module compatible with NR and the latest versions of ns-3. With this opportunity, I aim to make significant and definitive contributions to ns-3 and the NR module.

Milestones

You can track the project's plan by referring to this document: GSoC — Document Plan. The document will be constantly updated until the final submission.

Milestones for this project include updating the existing channel models in the ns-3, implementing a user-friendly interface via the nr module, and creating an example that utilizes all the added channel models within ns-3. The outline of these implementations will be separated into work packages (WPs) as follows:

WP 1 - NR interface for channel model usage (10 weeks)

• Task 1: Get familiar with BWP configuration, focusing on the channel model and how this configuration could be used from the NR helper class to initialize the BWPs. (0.5 week)
• Task 2: Get familiar with how the NYU channel model is being configured for the mmWave module in the NYU custom mmWave helper class. (0.5 week)
• Task 3: Prepare a refactoring plan for NR classes and check if the design will work for the three-channel models. (2 weeks)
• Task 4: Prepare 5G-Lena for different channel models that may not have spectrum channel matrix for su-MIMO and create a merge request to 5G-Lena. (4 weeks) [milestone 1]
• Task 5: Interface implementation for selecting the channel model via the NR helper class and creating a merge request for 5G-Lena. (3 weeks) [milestone 2]
  • Create a conditional build depending on the NYU channel model available in ns-3 and create a merge request to 5G-Lena. [milestone 3]
  • Extend NR helper to allow the configuration of 3GPP NTN channel models and create a merge request for 5G-Lena. [milestone 4]

WP 2 - Design and implement the benchmark scenario (8 weeks)

• Task 1: Identify and implement the appropriate scenario for all channel models. (1 week)
• Task 2: Prepare traces to be measured (e.g., entire simulation time, SINR, throughput, latency, etc.) and scripts for running and plotting based on the implemented example. (2 weeks)
• Task 3: Analyze, evaluate, and plot the results of the accomplished example. (3 weeks)
• Task 4: Extend the example to be used as a test and create a merge request of the implemented test to 5G-Lena; Write what was done in a blog post. [milestone 5] (2 weeks)

Weekly Report

Week 1 [May 31 - Jun 06 ]

• Finish the milestones
• Start to draft the desired implementation
• Start to study 5G-Lena and the modified MMwave helper classes

Week 2 [Jun 07 - Jun 13 ]

• Present a slide about BWP configuration and initialization [1]
• Create the first interface implementation (nr-helper)
  • Branch: scratch
• Present a slide about the mmwave-helper class (modified to support nyu); start to define a plan for the first milestone and solve some doubts [2]

Week 3 [Jun 14 - Jun 20 ]

NOTE: We are still discussing the non-su-mimo implementation. For a more detailed explanation, go to GSoC - Document Plan

• The first approach for non-su-mimo channel model implementation, back to the 2.6 version
  • Commit: Add condition to support non-SU-MIMO channel models
• The second approach for implementing the non-su-mimo channel model involves creating a spectrum channel matrix for those without it
  • Commits: Add a function to create a channel matrix if needed
• Start the interface implementation to enable the user to select distinct channel models using bandConf and initialization with nr-helper
  • Commits: First interface implementation
• Explain the NYUSIM channel model and compare it with 3GPP. Also, provide information about the interface implementation [3]
  • Many functions are used to set the TypeId (e.g., Init3GPPUma) that are all similar and could be removed. Instead, all the initialization would happen inside the main function based on the TypeIds
  • Separate the scenario from the condition when configuring the BWPs
  • Propose: Create independent enums for all channel conditions, scenarios, and channel models using enum classes.

To be done

• Check whether the channel model can be aggregated to PhasedArraySpectrumPropagationLossModel, so to obtain it with GetObject, Note: see how MobilityModel is aggregated to Node, and obtained, read in ns-3 documentation about object aggregation and usage
• Explain configuring channel, pathloss, and condition using the band ID
• Fix examples that break when trying to set parameters to AlwaysLos and Always NLos channel condition models instead of using warns
• Create initial draft MR/MRs
• Propose: Change the spectrum or the nr module if some interfaces, methods, or other things were not implemented best. Also, change or remove duplicated code and improve the design

Week 4 [Jun 21 - Jun 27 ]

• The first Draft MR related to milestone one is created, check:
  • MR(!160): Enable non-su-mimo channel models
• Update the document with a more detailed approach regarding the milestones
• Create a different way to get the type IDs in InitializeOperationBand for object factories type id configuration, using:
  • Strings: Reduce most parts of the code using the correct Type Id in string-format
    • Commits: cc-bwp-helper - Create GetTypeId functions for Condition, Channel and Scenario, nr-helper - Use band information to set the type ids
• Create a new enum for channel conditions and replace the enum for the enum class
  • Commit: Change enum for enum class
• Aggregate the matrix-based channel, in case it has one:
  •  Commit: Aggregate the matrix-based channel in the spectrum
• Assert the user's correct combination to avoid errors or wrong usage of propagation, condition, and spectrum (i.e., if the user selects NYU + V2V_Highway + LOS, we need to abort the simulation because NYU does not have V2V_Highway scenario)
  • Commit: Add abort_msg for non-supported combinations
• Explain how the current band configuration occurs in InitializeOperationBand function [4]
  • Channel condition enum should have one more value called "Buildings"
  • The mapping function used to check if the would call another mapping function that maps each enum into corresponding TypeIds
  • Check how attributes of the enum type work in ns-3 and how it can be implemented in our context
  • Add the Two-ray channel model to the supported combinations

To be done

• First task: Refactor BandwidthPartInfo to allow the user to configure it with three independent strings instead of enums:
  • BandwidthPartInfo needs to be a class
  • Pass these three string arguments directly to attributes of bwp that are of enum type, so at least one conversion is done "automatically"
  • Move Buildings to the channel condition enum class
  • Add the Two-ray channel model to the supported combinations

• Second task: Translation from enum to TypeId
  • Check if the user-selected combination works (I think it is better to call it here before we make a conversion from enum to TypeIDs, but I can also do this later. I just have to ensure that the user selected a correct combination)
  • Convert from enum to TypeID using the functions I already created (instead of returning a string, return the right TypeId)
  • Improve the GetConditionTypeId() function and define it to set only the LOS, NLOS, and Buildings.