Nsnam - User contributions [en]

GSOC2024Channels5G

2024-10-18T11:33:58Z

Albu: /* Weekly Report */

{{TOC}}

Back to [[Summer_Projects#Google_Summer_of_Code_2024 | 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:''' [https://summerofcode.withgoogle.com/programs/2024/projects/OdtVEGnj 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:''' [https://gitlab.com/gsoc2024/ns-3-dev ns-3], [https://gitlab.com/gsoc2024/nr 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: [https://docs.google.com/document/d/14K0tnTJRO1qb2mDguGr4FrFCDMu8VBJ6BZpPow2au2M/edit 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 27 - Jun 02 ] ==

* Finish the milestones
* Start to draft the desired implementation
* Start to study 5G-Lena and the modified [https://github.com/hiteshPoddar/NYUSIM_in_ns3/blob/main/mmwave/helper/mmwave-helper-nyusim.cc MMwave] helper classes

== Week 2 [Jun 03 - Jun 09 ] ==
* Present a slide about BWP configuration and initialization [https://docs.google.com/presentation/d/18QROGyoguLpFE6mddkoVWXTJrMZ_S3GZCTb8GHphjp8/edit?usp=sharing]
* Create the first interface implementation (nr-helper)
** Branch: [https://gitlab.com/Allbu/nr/-/tree/scratch?ref_type=heads 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 [https://docs.google.com/presentation/d/1BGEXbTVMReKGh5ArjglZxAwyePU5ITeq7Y5SyTmq3Os/edit?usp=sharing]

== Week 3 [Jun 10 - Jun 16 ] ==
''' NOTE: ''' We are still discussing the non-su-mimo implementation. For a more detailed explanation, go to [https://docs.google.com/document/d/14K0tnTJRO1qb2mDguGr4FrFCDMu8VBJ6BZpPow2au2M/edit GSoC - Document Plan]
* The first approach for non-su-mimo channel model implementation, back to the 2.6 version
** Commit: [https://gitlab.com/Allbu/nr/-/compare/master...enable-no-su-mimo?from_project_id=9684684 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: [https://gitlab.com/Allbu/nr/-/compare/master...enable-non-su-mimo-second-imp?from_project_id=9684684 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: [https://gitlab.com/Allbu/nr/-/compare/master...interface-implementation?from_project_id=9684684 First interface implementation]
* Explain the NYUSIM channel model and compare it with 3GPP. Also, provide information about the interface implementation [https://docs.google.com/presentation/d/1CI2sj_lnZ7TCp5Iux2spw3ibnm_O5rw-HCh7NeU5JcA/edit?usp=sharing]
** 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 17 - Jun 23 ] ==

* The first Draft MR related to milestone one is created, check:
** [https://gitlab.com/cttc-lena/nr/-/merge_requests/160 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: [https://gitlab.com/Allbu/nr/-/commit/2fbbdbe3cbde2cf53fd2a9a4817bac1d00e9777c cc-bwp-helper - Create ''GetTypeId'' functions for Condition, Channel and Scenario], [https://gitlab.com/Allbu/nr/-/commit/6aec9923648723b7bd6890cc6ea873a886fed36c 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: [https://gitlab.com/Allbu/nr/-/commit/2fbbdbe3cbde2cf53fd2a9a4817bac1d00e9777c Change enum for enum class]
* Aggregate the matrix-based channel, in case it has one:
** Commit: [https://gitlab.com/Allbu/nr/-/commit/81a05b952dd3f50e9817842dc9fae52ed40d2629 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: [https://gitlab.com/Allbu/nr/-/commits/771ddd2065d2418fcc2d2d7f128dc54ff6a14559 Add abort_msg for non-supported combinations]
* Explain how the band configuration in the modified ''InitializeOperationBand'' function works [https://docs.google.com/presentation/d/1LpcJhFx8JXgumQSIgCLXFBHE1oCs4zSazWedE8kpYAo/edit?usp=sharing]
** Channel condition enum should have one more value called "Buildings"
** The mapping function should 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.

== Week 5 [Jun 24 - Jun 30 ] ==

* Start to draft the new interface implementation [milestone 2 continuation]:
** Make ''BandwidthPartInfo'' inherit from Object class
*** Use ''BandwidthPartInfo'' as a class and not a struct
** Create ''GetTypeId()'' function for ''BandwidthPartInfo'' with enum attributes to get enum values using strings
** Refactor ''CreateOperationBandContiguousCc'' to use the modified ''BandwidthPartInfo'' struct
** Move Buildings to channel condition enum class and add 3GPP and NYU
** Move supported combinations to ''BandwidthPartInfo'' struct and add FTR
** Return the TypeId value instead of TypeId string format in Get{condition, channel and propagation}TypeId() function

=== To be done ===

* Implement it into the code; work branch: [https://gitlab.com/Allbu/nr/-/tree/bwp-class-interface-imp?ref_type=heads bwp-class-interface-imp]

== Week 6 [Jul 01 - Jul 07] ==

* '''Band configuration with CcBwpCreator and BandwidthPartInfo:'''
** Commits:
*** [https://gitlab.com/Allbu/nr/-/commit/74f38e2f15a0a6e7eec8a5b1a3da94a0f8f1b409 Convert BandwidthPartInfo from struct to class]
*** [https://gitlab.com/Allbu/nr/-/commits/0e49933f1eb266ef22a6e762654ab661438978d2 Create TypeId to BandwidthPartInfo]
*** [https://gitlab.com/Allbu/nr/-/commits/5ef3e6576954f5e07b12b113bacf4d859c72e809 Set supported spectrum, propagation, and condition models and assert user-selected combination]
*** [https://gitlab.com/Allbu/nr/-/commit/ee1cb4dca3cc50f9b15716ac722d36e20410579a Create Get{propagation,channel, and spectrum}TypeId functions with build conditions and lookUpTables]
**** In GetChannelConditionTypeId(), the Typeid() default value returns when the channel condition is initialized directly in the propagation model. On the other hand, it returns the LOS, NLOS, or Buildings type ID.
**** In GetPropagationTypeId(), it returns the type ID based on the user-selected scenario and channel model (e.g., ThreeGpp + RMa -> ThreeGppRmaPropagationLossModel::GetTypeId())
**** In GetChannelModelTypeId(), it returns the type ID of the user-selected channel model
*** [https://gitlab.com/Allbu/nr/-/commit/4387df24a9970792104c51812cc75ec4072ff8d3 Use strings in SimpleOperationBandInfo struct and CreateCc function instead of enums]
*** [https://gitlab.com/Allbu/nr/-/commit/4387df24a9970792104c51812cc75ec4072ff8d3 Create the BandwidthPartInfo with scenario, channel model, and condition to transform it from string to enum class directly]

* '''Band initialization with nr-helper:'''
** Commits:
*** [https://gitlab.com/Allbu/nr/-/commits/430fd32a44c868c5af4a4fcd8f8a93257c9b8b11 Remove the lookup table to typedef functions and use the band info to set the object factories type id]
*** [https://gitlab.com/Allbu/nr/-/commits/430fd32a44c868c5af4a4fcd8f8a93257c9b8b11 Configure the created spectrum, propagation, and channel condition objects]
*** [https://gitlab.com/Allbu/nr/-/commit/9e0a0f7df65fb8ee205c9dde1ec88bd72e695415 Fix Create{ue,gnb}Phy() BandwidthPartInfo argument]

* '''Update examples and test files to use the current approach:'''
** Commits:
*** [https://gitlab.com/Allbu/nr/-/commit/65006222040da1f9741c0518ce9a4c8c5d0a2800 Update test files]
*** [https://gitlab.com/Allbu/nr/-/commit/19ad656bf28a5c640bcad553c55036187255a292 Update examples]

=== To be done ===

* Create a better interface in which the user can set attributes in the spectrum, channel condition, and propagation without using the band ID
* Extend the API to use different propagation and spectrum models
* Create a draft MR

== Week 7 [Jul 08 - Jul 14] ==

* Present a slide about the possible extension of 5G-Lena to use non-fading simple pathloss models (e.g., LogDistancePropagationLossModel) [https://docs.google.com/presentation/d/1KwFWR9AEgYm1jqONAE2rG1WFMu2ZOijbtTx7J38rYJc/edit?usp=sharing]
** Simulation occurs without errors, using simple pathloss models
** Using (non-phased array) spectrum propagation loss classes (e.g., FriisSpectrumPropagationLossModel), one error related to MIMO communication appears, and we are already dealing with this in the [https://gitlab.com/cttc-lena/nr/-/merge_requests/160 MR(!160) - First Milestone]
* Create the MR related to the second milestone:
** [https://gitlab.com/cttc-lena/nr/-/merge_requests/167 (MR - !167): Refactor band configuration and initialization with a modular approach]

=== To be done ===

* Extend the tests to use antennas present in ns-3 (e.g., ParabolicAntennaModel, CosineAntennaModel, etc.)
* Create an assert message to ensure the correct SISO conversion from PSD to spectrum channel matrix
* Extend the new interface implementation to fit the non-phased array spectrum and propagation loss models

== Week 8 [Jul 15 - Jul 21] ==

* Add an assert message to ensure the correct SISO conversion from PSD to spectrum channel matrix
** Commit: [https://gitlab.com/cttc-lena/nr/-/merge_requests/160/diffs?commit_id=c1231a3b2c337a89c2b4ce0d6fe9289c017a7990 Assert single antenna port for conversion compatibility]
* Present a slide about the BWP interface implementation to fit legacy antenna, spectrum, and propagation models [https://docs.google.com/presentation/d/1XqXvxi3Kex4Z1ZfjKglBKW0NXLTz3wTXXMuVJMtjsk8/edit?usp=sharing]
** '''Considerations''':
*** The supported combinations variable is getting bigger. We may need to rethink the usage of this in this approach
*** Spectrum and propagation can't be the same (e.g., FriisSpectrum + FriisPropagation)
*** Check Tom's approach in: [https://gitlab.com/cttc-lena/nr/-/merge_requests/173 !MR-173]

=== To be done ===

* Check Tom's MR to get insights on how we can do this
* Extend the interface to adapt manual installation of BWPs
* Start to code a draft of it

== Week 9 [Jul 22 - Jul 28] ==
* After checking Tom's MR, present three approaches to fit into our current approach [https://docs.google.com/presentation/d/1tYB2CGfiE6kx4-Z0QqflRklU_5tBAXcm4_Tf7drx6lo/edit?usp=sharing]:
** First approach:
*** Maintain the current state of the code and just create a simple function to set non-phased spectrum models
** Second approach:
*** Commit: [https://gitlab.com/Allbu/nr/-/commit/8b09bfb5ed34bbfca632fcb8d38640a6c59f99df Separate spectrum configuration from band information]
*** Commit: [https://gitlab.com/Allbu/nr/-/commit/b6f6379f911fbfc3b99562c4d0af4563ba66352d Use a unique function to set phased and non-phased channels]
** Third approach:
*** Commit: [https://gitlab.com/Allbu/nr/-/commit/0a77ae77bf0c3e646712db271064d85cb29e7736 Create a unique structure and raw function that returns a simple BWP]
** '''Considerations''':
*** We decided to follow the second approach, which is more aligned with the original draft and the suggested improvements
* Include NYUSIM in the 5G-Lena repository ([https://gitlab.com/Allbu/nr/-/tree/include-nyu?ref_type=heads Branch])
** A new issue [https://gitlab.com/cttc-lena/nr/-/issues/207 #207] appeared when using the "channels/nyu" path in the 5G-lena repository
** We decided to include NYUSIM instead of setting build conditions; see the original repository: [https://github.com/hiteshPoddar/NYUSIM_in_ns3.git]
=== To be done ===
* Create a new MR with the improvements of the second approach
* Create a new MR with the NYUSIM classes (propagation, condition, and spectrum)

== Week 10 [Jul 29 - Aug 04] ==
* Present a slide about the current approach with everything updated [https://docs.google.com/presentation/d/1t4A-gvspCBPRVhbR1pS0kbdacgd1YK7SB0q6qoTHTvw/edit?usp=sharing]
* [https://gitlab.com/cttc-lena/nr/-/merge_requests/174 MR- !174:] Refactor band configuration and initialization with a modular approach (Enhancement)
**Examples: Fit all examples in our current approach [https://gitlab.com/cttc-lena/nr/-/merge_requests/174/diffs?commit_id=81927d3eebbbfce9125b9ac6c453887092d2993d commit: Use channel helper for spectrum channel configuration]
*** '''[specific change]''' cttc-nr-3gpp-calibration-utils-v2: Manual creation of distance-based 3GPP model
**Test: Fit all tests in our current approach [https://gitlab.com/cttc-lena/nr/-/merge_requests/174/diffs?commit_id=1171003038dc611f003c1c3bac1cbac9ea2f4203 commit: Use channel helper for spectrum channel configuration]
** Bug: We checked that all the BWPs share the same ''PhasedArraySpectrum'', ''Propagation'' and ''Channel condition'' pointer. All the BWP features (e.g., frequency, scenario, etc.) override the pre-defined values

=== To be done ===
* Fix the discovered bug
** Separate channel creation from channel configuration
** Fix examples and tests that use more than one channel
* Extend the NR documentation (RELEASE_NOTES.md, CHANGES.md, and nr-module.rst) with our current modifications
* Create a new example that uses a non-standard propagation loss model (e.g., Friis)

== Week 11 [Aug 05 - Aug 11] ==
* Present a slide about the MR improvements [https://docs.google.com/presentation/d/1z1cmg9sMpd7mQSW0ESVs5YycYhxtdRVgyAN4yVSLvNA/edit?usp=sharing]
** Use ObjectFactories for multiple SpectrumChannel creation: [https://gitlab.com/cttc-lena/nr/-/merge_requests/174/diffs?commit_id=a5caa22e6c1463f6bb7825952a68416fcd1b74af Update the create SpectrumChannels for ObjectFactory usage]
** Assign frequency directly in ChannelHelper class: [https://gitlab.com/cttc-lena/nr/-/merge_requests/174/diffs?commit_id=d2267c778a39d46263f43e28929014693037c27b Assign frequency directly in AssignChannelsToBands]
** Create a helper function to override the spectrum TypeId for a specific example (cttc-nr-3gpp-calibration-utils-v2): [https://gitlab.com/cttc-lena/nr/-/merge_requests/174/diffs?commit_id=b8d5c76b0a1e9bdd0547f4da2cd314c40b8c50d9 Create function to override the spectrum TypeId]
** Extend GetPropagationTypeId function to return the associated channel condition: [https://gitlab.com/cttc-lena/nr/-/merge_requests/174/diffs?commit_id=e3e07b031e0b45c2e781e95f9a5f18afcda298d8 Extend function to return the channel condition TypeId]
* Fix examples and tests:
** Examples: [https://gitlab.com/cttc-lena/nr/-/merge_requests/174/diffs?commit_id=4f2b895e267cde64e71f6931958d9aaf0e5979da Update examples to use the updated channel helper API]
** Tests: [https://gitlab.com/cttc-lena/nr/-/merge_requests/174/diffs?commit_id=4f2b895e267cde64e71f6931958d9aaf0e5979da Update tests to use the updated channel helper API]
* Create a new example:
** New example that illustrates how a user can configure 'legacy' propagation models (e.g., Friis) or 'standard' (e.g., 3GPP) using our current approach: [https://gitlab.com/cttc-lena/nr/-/merge_requests/174/diffs?commit_id=fb546dfcbc423b91d66d27c2059a7f626184c13f cttc-nr-channels-example: Add new example]
'''Note:''' I’ve updated most of the code and made several fixes. Documentation updates will be completed by week 12.
=== To be done ===
* Add different configurations for the example in examples_to_run.py - one for non-phased case and another for the phased case.
* nr-module.rst - add the description for the new helper and the example
* CHANGES.md - start a new section for the following release and add the bullet/s describing the main CHANGES due to the created MR
* RELEASE_NOTES.md - start a new one for the following release and add the bullet/s describing the main release notes related to the created MR
* Consider if non-phased could also be configured through the ChannelHelper factories
* Rename ChannelHelper into NrChannelHelper
* Change the topology to use the HexagonalHelper
* Add FlowMonitor to track the statistics - Preparation for the evaluation

== Week 12 [Aug 12 - Aug 18] ==
* Add the newly created example variation to simulate a 'legacy' channel (Friis) in 'examples-to-run'
** Commit: [https://gitlab.com/cttc-lena/nr/-/merge_requests/174/diffs?commit_id=1077ff7ecc3f8a06b82fd54c8cc0793c6f57350d Add variation of cttc-nr-channel-example for non-phased channel usage]
* Add the description for the new helper and the example in the nr-module.rst
** Commits:
*** [https://gitlab.com/cttc-lena/nr/-/merge_requests/174/diffs?commit_id=283d388ccdbc0e6750472568c64b2aeadd9352b9 Extend documentation to include NrChannelHelper API]
*** [https://gitlab.com/cttc-lena/nr/-/merge_requests/174/diffs?commit_id=c4aec1a140f3020d860835a6630dd9256e9f194a Extend documentation to include cttc-nr-channels-example]
* Start a new section for the following release in CHANGES.md and add the bullet/s describing the main CHANGES due to the created MR
** Commit: [https://gitlab.com/cttc-lena/nr/-/merge_requests/174/diffs?commit_id=03bdb5c4ca6fd2330731962610dee694e9812a05 Update changes in the new NR-v3.4 section]
* Update the RELEASE_NOTES.md and add the bullet/s describing the main release notes related to the created MR
** Commit: [https://gitlab.com/cttc-lena/nr/-/merge_requests/174/diffs?commit_id=1bc51c56e03eefa47b5504f476aa5b36963d5f47 Create a new section exposing the modifications and improvements made]
* Rename ChannelHelper into NrChannelHelper
** Commit: [https://gitlab.com/cttc-lena/nr/-/merge_requests/174/diffs?commit_id=6da7492cc643ef0cb6f10f2f9a406509ab872251 Rename ChannelHelper class into NrChannelHelper]
* Change the topology to use the HexagonalHelper
** Commit: [https://gitlab.com/cttc-lena/nr/-/merge_requests/174/diffs?commit_id=4556bc548b56d2b6ff1a19bbc8eaae280b39b013 Use HexagonalGridScenarioHelper for scenario creation]
* Add FlowMonitor to track the statistics
** Commit: [https://gitlab.com/cttc-lena/nr/-/merge_requests/174/diffs?commit_id=08ee30f408e057c6537159503fac18dee7259c90 Extend example to use FlowMonitor]
=== To be done ===
* Define the scenario that fits all the channel models and start measurements
* Solve threads in MR [https://gitlab.com/cttc-lena/nr/-/merge_requests/174/commits !174]

== Week 13 [Aug 19 - Aug 25] ==
* Create a dataset that includes all scenarios that fit all channel models [UMi, UMa, and RMa]
** Work branch: [https://gitlab.com/Allbu/nr/-/tree/traces-results?ref_type=heads trace-results]

* Resolve threads:
** Fix comments and doxygen: [https://gitlab.com/cttc-lena/nr/-/merge_requests/174/diffs?commit_id=716cc2c1c9d2fb1a0eab7a963f1a09a70ab6385f !174 (716cc2c1)], [https://gitlab.com/cttc-lena/nr/-/commit/b00cdf9796cd4a114e7abd11322e20b7d473e989?merge_request_iid=174 !174 (b00cdf97)], and others (check the [https://gitlab.com/cttc-lena/nr/-/merge_requests/174 !MR - 174])
** Fix UMi base station scenario height and add a reference: [https://gitlab.com/cttc-lena/nr/-/merge_requests/174/diffs?commit_id=d688ae3a5416440eab29d0c3d3bce11839f2621d !174 (547d578a)]
** Fix the maximum delay in the CheckForLostPackets FlowMonitor function: [https://gitlab.com/cttc-lena/nr/-/merge_requests/174/diffs?commit_id=7bc58a08cb6f84d580d2d6d8eed8bd963853e677 !174 (7bc58a08)]
=== To be done ===
* Continue solving threads and discussing the approach in the MR
* Start plotting the measured traces

== Week 14 [Aug 26 - Sep 1] ==
* Present some MR improvements and results [https://docs.google.com/presentation/d/178_frl-AkCv8b_N9-3pfVWL7ccYpq09P4vHhorhlHM4/edit?usp=sharing]
** Start plotting the SINR 3D mesh for all channel models
** Start plotting KPIs
** Show achievements/improvements accomplished during the week 12-13

* Resolve threads:
** Fix comments and doxygen:
*** [https://gitlab.com/cttc-lena/nr/-/merge_requests/174/diffs?commit_id=62dbeb281ae3c02c6dd6180447c4b236379e780d nr-module: Add abbreviations and improve the text in 'Nr Channel Helper' section]
*** [https://gitlab.com/cttc-lena/nr/-/merge_requests/174/diffs?commit_id=b58d7588c9da1d799c334da978dc8c0f7328a526 cc-bwp-helper: Fix GetChannel doxy in BWP struct]
** Reuse the SetChannel function for BWP's spectrum channel configuration
*** [https://gitlab.com/cttc-lena/nr/-/merge_requests/174/diffs?commit_id=4f196b19123831b7f01e96321f0f5400f3cf1e19 cc-bwp-helper: Make spectrum channel nonpublic in the BWP struct]
*** [https://gitlab.com/cttc-lena/nr/-/merge_requests/174/diffs?commit_id=8b62cd542b8f346cce0ab330ae14af287b0380ba nr-channel-helper, nr-helper: Use Set/Get functions to interact with BWPs' spectrum channels]

=== To be done ===
* Continue solving the threads
* Fix scenario parameters in cttc-nr-channels-example

== Week 15 [Sep 2 - Sep 8] ==
* Show resolved threads in a presentation [https://docs.google.com/presentation/d/159e9AD1G9IB-npqqiV9844bY0DHjulbptzlOFai-oMk/edit?usp=sharing]
** [https://gitlab.com/cttc-lena/nr/-/merge_requests/174/diffs?commit_id=169341bc9465d0d801eb5bc761ce23d40bc98c55 Fix scenario parameters in 'cttc-nr-channels-example']
** Fix doxygen and documentation
** [https://gitlab.com/cttc-lena/nr/-/merge_requests/174/diffs?commit_id=702430514232c9728e822d1764d15c7e2c9ecf23 Extend NrChannelHelper class to support Distance-based 3GPP]
** [https://gitlab.com/cttc-lena/nr/-/merge_requests/174/diffs?commit_id=65ebea365697cc606f35ace66fef50f8edb66487 Configure distance-based 3GPP channel using standard channelHelper method]

* '''Discussion''':
** The distance-based 3GPP channel model is the 3GPP channel model with a maximum distance attribute. It shouldn't be in the NrChannelHelper scope
** All threads are already addressed; I can now focus on plotting the results

=== To be done ===
* Start plotting the results as discussed in WP2
* Create a Distance-based 3GPP spectrum channel model manually in cttc-nr-3gpp-calibration-utils-v2.cc

== Week 16 [Sep 9 - Sep 15] ==
* Plot results [https://docs.google.com/presentation/d/1kZrTYnL7pzd_cM9dEd7zOxT5TIFTvwXt4DfOrMWOG6c/edit?usp=sharing]
** Plot SINR mesh in the range of 30.5 GHz to 60.5 GHz
** Plot ECDF of the three-channel models
** Plot time resolution for all channel models in terms of real/user/system time
** Plot KPIs (throughput, delay, and jitter)
* Create Distance-Based 3GPP spectrum class manually
** Commit: [https://gitlab.com/cttc-lena/nr/-/commit/164902a3717b8719b176f9af5889afe507e38cdf?merge_request_iid=174 cttc-nr-3gpp-calibration-utils-v2: Create DistanceBased spectrum class manually]

=== To be done ===
* Double-check the created dataset and plot scripts
* Time results:
** Add time results for 2 and 6 UEs
** Increase the bandwidth from 5 MHz to 100 MHz

== Week 17 [Sep 16 - Sep 22] ==

'''Note:''' Week 17 was divided into two parts:
* 17.1) We discussed the evaluated results [https://docs.google.com/presentation/d/1-mE9b6QE3P6S9kwvFGj2bwuvy6MQWe6QANcwXqFDGqo/edit?usp=sharing]:
** The SINR ECDF plots of 3GPP and FTR make total sense after changing the positions
** NYUSIM remains with strange behavior
** Discussion: HexagonalGridScenario randomly positions the UE and the gNB so that the UE is behind the gNB
*** Fix: The UE position to be in front of the gNB since we are working with only LOS
*** Fix: The bearing angle (check cttc-nr-mimo-demo)

* 17.2) We discussed the evaluated results, small issues that may happen during the test code, and NrChannelHelper API's extension to configure legacy models manually [https://docs.google.com/presentation/d/19gSmb4aiG8TnCKcPNp-k8zL_2svV6ENttXVmgNvVj5Q/edit?usp=sharing].

=== To be done ===
* Start the test code
* Plot time results for 3GPP without fading

== Week 18 [Sep 23 - Sep 29] ==

* Present the updates [https://docs.google.com/presentation/d/1Vtgrgxn2A2dnNxtj9nsTVMADOI-cl9OdcXnot8sUuL4/edit?usp=sharing]
* Develop the test code [https://gitlab.com/cttc-lena/nr/-/merge_requests/174/diffs?commit_id=65fabc490829d123bc9d774ee1f90f8e769d97e9 cmakelists, gsoc-channel-combinations-test: Add test to check channel creation via NrChannelHelper API]

=== To be done ===
* Fix minor issues in the test code
* Rebase the MR
* Add NYUSIM files to 'utils/channels/nyu' path

GSOC2024Channels5GFinalReport

2024-10-15T14:39:58Z

Albu: /* Project Overview */

= Project Overview =
* '''Project Name:''' 5G NR Module Benchmark and Analysis for Distinct Channel Models
* '''Student:''' Joao Albuquerque
* '''Mentors:''' Biljana Bojovic, Amir Ashtari, and Gabriel Ferreira

The project aims to integrate the two new channel models, NYUSIM and Fluctuating Two-Ray (FTR), into the NR module in a simplified and user-friendly manner. Additionally, some tasks will be carried out during the implementation process, such as testing the code and creating examples that demonstrate the use of the implemented models.

== Merge Requests and Project Details ==

I maintained two branches to accomplish all the code written during GSoC: [https://gitlab.com/Allbu/nr/-/tree/bwp-interface-enhancement?ref_type=heads bwp-interface-enhancement] and [https://gitlab.com/Allbu/nr/-/tree/enable-non-su-mimo-second-imp?ref_type=heads enable-non-su-mimo].

Project Wiki Page: [https://www.nsnam.org/wiki/GSOC2024Channels5G GSOC2024Channels5G]

Proposal: [https://drive.google.com/file/d/1TSTStwfwm5o1ALHmnphOKejYse69ow-x/view?usp=sharing]

{| class="wikitable"
|+ Merge Requests
|-
! No. || Name || Status
|-
| [1] || [https://gitlab.com/cttc-lena/nr/-/merge_requests/174 Draft: GSoC 2024: Refactor band configuration and initialization with a modular approach (Enhancement)] || Draft
|-
| [2] || [https://gitlab.com/cttc-lena/nr/-/merge_requests/160 Draft: GSoC2024: Enable non-su-mimo channel models] || Draft
|}

== Community Bonding Period ==

During the bonding period, we discussed all the significant parts of the project before the implementation started. Therefore, I began to:

* Understand how the NYUSIM channel model interface was implemented in the mmWave module
* Read papers regarding the implementation of both NYUSIM and FTR
* Plan the user-friendly interface for channel model selection and configuration
* Discuss some issues that this implementation could generate in the code

== Coding Phase and Work Packages ==
As proposed for the coding period, we set some goals divided into work packages.

=== Work Package 1 ===
In the first one, four goals were decided upon:

''' Achieved in week 4''': [https://gitlab.com/Allbu/nr/-/commit/be2afa7d275677c79f58c9717987a9400b60eb4d]
* Prepare 5G-Lena for different channel models that may not have a spectrum channel matrix for SU-MIMO and create a merge request to 5G-Lena. [milestone 1]

''' Achieved in week 6''': [https://gitlab.com/cttc-lena/nr/-/merge_requests/167]
* Implement an interface for selecting the channel model via the NR helper class and create a merge request for 5G-Lena. [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] [https://gitlab.com/cttc-lena/nr/-/merge_requests/174/diffs?commit_id=846330277256bfc0bcd4486b1a231eb2cfa9a03f specific commit]
* Extend the NR helper to allow the configuration of 3GPP NTN channel models and create a merge request for 5G-Lena. [milestone 4] [https://gitlab.com/cttc-lena/nr/-/merge_requests/174/diffs?commit_id=225263e93b2164f6ef9368ba99b5630e0beebdd4 specific commit]

* '''NOTE:''' After discussing some points, we decided to improve our approach [https://gitlab.com/cttc-lena/nr/-/merge_requests/174]

=== Work Package 2 ===
In the second work package, we aim to evaluate the channel models by creating one example, test code, and plotting some physical metrics and key performance indicators (KPIs):

''' Achieved in week 13''': [https://gitlab.com/cttc-lena/nr/-/merge_requests/174/diffs?commit_id=be66c8687c60f6a0feb297824b5645bd88c16044]
* Identify and implement the appropriate scenario for all channel models

''' Achieved in week 17''': [https://docs.google.com/presentation/d/1kZrTYnL7pzd_cM9dEd7zOxT5TIFTvwXt4DfOrMWOG6c/edit?usp=sharing], [https://docs.google.com/presentation/d/1-mE9b6QE3P6S9kwvFGj2bwuvy6MQWe6QANcwXqFDGqo/edit#slide=id.g2e65c1385a2_0_195], [https://docs.google.com/presentation/d/19gSmb4aiG8TnCKcPNp-k8zL_2svV6ENttXVmgNvVj5Q/edit?usp=sharing]
* 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
* Analyze, evaluate, and plot the results of the accomplished example

''' Achieved in week 18''': [https://gitlab.com/cttc-lena/nr/-/merge_requests/174/diffs?commit_id=65fabc490829d123bc9d774ee1f90f8e769d97e9]
* Extend the example to be used as a test and create a merge request of the implemented test to 5G-Lena

== Addditional Features ==
In addition to the proposed activities, I created a new API, NrChannelHelper, which allowed me to redesign how users select and configure channels. This API also enabled the extension to use all the legacy fading and propagation models not previously supported in the 5G-Lena module before my work. Additionally, the NrHelper API has been extended to enable the use of legacy antennas, which will be used in conjunction with the fading and propagation models present in ns-3.

== My Experience ==

=== Acknowledgements ===
I want to thank all my mentors, Biljana Bojovic, Gabriel Ferreira, and Amir Ashtari, for always helping me understand the code architecture and how to work with open source. I would also like to thank Tom Henderson, who, although not one of my mentors, played a crucial role in improving the developed code. Finally, a general thanks to the Google Summer of Code project and the 5G-Lena team.

=== Challenges Faced ===

In the implementation phase, more precisely, I faced challenges in modularizing the code so that the proposed channel models and the legacy models were included. Additionally, understanding the results at the physical and application layer levels for the FTR and NYUSIM models was challenging.

GSOC2024Channels5GFinalReport

2024-10-06T15:26:34Z

GSOC2024Channels5G

2024-09-08T14:33:31Z

Albu: /* Weekly Report */

GSOC2024Channels5G

2024-08-28T17:49:30Z

Albu: /* Weekly Report */

GSOC2024Channels5G

2024-08-20T21:23:45Z

Albu: /* Weekly Report */

GSOC2024Channels5G

GSOC2024Channels5G

2024-05-17T23:04:27Z

Albu: /* WP 2 - Design and implement the benchmark scenario (5 ~ 6 weeks) */

GSOC2024Channels5G

2024-05-17T23:04:11Z

Albu: /* WP 2 - Design and implement the benchmark scenario (5 ~ 6 weeks) */

GSOC2024Channels5G

2024-05-17T23:00:24Z

Albu: /* WP 3 - Test code and improvements (7 weeks) */