GSOC2019ThreeGPPChannel

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 Google Summer of Code 2019.

Project Overview

• Project Name: Integration of the 3GPP TR 38.901 channel model in the ns-3 spectrum module
• Student: Tommaso Zugno
• Mentor: Natale Patriciello
• Proposal: link to the document
• Abstract: In recent years, ns-3 has been widely used for the simulation of wireless networks, because it features several built-in and external modules implementing different wireless technologies. The overall performance of this kind of networks are strongly influenced by the characteristics of the signal propagation through the wireless link, thereby, a proper modeling of the channel behavior is of primary importance to obtain reliable results from the simulations. This project aims to tackle this issue by proposing an extension of the spectrum module to model both frequency and spatial-dependent phenomena, and to account for the directional behavior of the signal propagation. This will be achieved by implementing the modeling framework described in 3GPP TR 38.901, which includes the statistical characterization of different propagation environments, supports the modeling of multi-antenna systems, and, thanks to its modularity, can be easily extended with new environments or other additional features. Even if it has been specifically designed for the simulation of cellular networks, it supports frequency bands between 0.5 and 100 GHz, thus can be used even for other wireless technologies.
• Code: GitLab repo
• About Me: I am a first-year PhD student at the University of Padova, Italy, working under the supervision of prof. Michele Zorzi. My research focus on protocols and architectures for 5G cellular systems operating at mmWaves.

Deliverables

Phase 1

• new ChannelConditionModel interface, which can be used to determine the state of the channel between two nodes [1]
• implementation of the channel condition models specified in 3GPP TR 38.901 [2]
• implementation of the pathloss models specified in 3GPP TR 38.901 [3]

Project Timeline

Week 0 (Community Bonding Period)

• discussion with my mentor about project plan, test cases, examples, model validation
• creation of a wiki page for the project
• project introduction in ns-developers
• discussion with ns-developers about the extension of the "SpectrumSignalParameters" structure
• creation of a git repository for the project

Week 1 (May 27 - June 2)

• discussion with my mentor about the following issues:
  • how to apply the pathloss models without the knowledge of the type of the devices
  • computation of the pathloss between UE-UE and BS-BS
  • how to consider the mobility of both the devices for the computation of the Doppler frequency component and the spatial consistent procedure
• design of the ChannelConditionModel abstract class and of the ThreeGppYYYChannelConditionModel subclasses
• design of the ThreeGppYYYPropagationLossModel classes

Week 2 (June 3 - June 9)

• implementation of the abstract class ChannelConditionModel, which provides the base for the implementation of specific channel condition models. The main method is GetChannelCondition (mm a, mm b), which determines the channel condition based on the tx and rx mobility models and returns it as a pointer to an object of type ChannelCondition. At this stage, the ChannelCondition class only contains information about the LOS/NLOS state of the channel, but it will be extended to include other information, e.g., whether the transmission is outdoor to indoor. The reason why we decided ChannelCondition to be a regular class (and not a struct for instance) is to be able to exploit the object aggregation system in case a derived class wants to add some additional information, without having to deal with subclassing. For instance, if we add a channel condition model which determines the condition based on the buildings deployed in the scenario, we can use the aggregation system to provide also the information about the type of the building obstructing the line of sight.

• implementation of the subclasses ThreeGppRMaChannelConditionModel, ThreeGppUMaChannelConditionModel, ThreeGppUMiStreetCanyonChannelConditionModel, ThreeGppIndoorMixedOfficeChannelConditionModel, ThreeGppIndoorOpenOfficeChannelConditionModel, which inherits from ChannelConditionModel and statistically determines the LOS/NLOS state based on the specification in 3GPP TR 38.901.

• addition of the subclass BuildingsChannelConditionModel, which inherits from ChannelConditionModel and determines the LOS/NLOS state based on the buildings deployed in the scenario. It has been adapted from the mmwave module.

• design and implementation of test cases for all the new classes
  • the test cases for the ThreeGppYYYChannelConditionModel classes call the method GetChannelCondition () multiple times, estimate the LOS probability and compare it with the value computed using the baseline formula
  • the test case for the BuildingsChannelConditionModel determines the channel condition between two nodes in multiple cases: (i) there is a building in between the two nodes, (ii) no building in between, (iii) the first node is inside the building and the second is outside, (iv) the two nodes are inside the same building.

• weekly discussion with my mentor about:
  • how to pass the information about the channel condition to the PropagationLossModel and SpectrumPropagationLoss model: we will not modify the existing APIs, the ChannelConditionModel will be used only within the propagation and spectrum implementations that wants to use it
  • where to put the ChannelConditionModel: we decided to put it the propagation module
  • how to implement the spatial consistency procedure described in TR 38.901: we decided to include procedure A, which supports mobility only at the user terminal, while the base station is considered always fixed. We will provide the possibility to enable/disable the spatial consistency procedure and to specify the channel update time through attributes.

MR for the channel condition model: https://gitlab.com/tommasozugno/ns-3-dev/merge_requests/1

Week 3 (June 10 - June 16)

• review of the channel condition model
• development of new classes which extends the PropagationLossModel interface and implements the pathloss models defined in 3GPP TR 38.901 (ThreeGppRmaPropagationLossModel, ThreeGppUmaPropagationLossModel, ThreeGppUmiStreeCanyonPropagationLossModel, ThreeGppIndoorOfficePropagationLossModel). The main method is DoCalcRxPower (txPow, mm a, mm b), which applies the pathloss model taking into account the LOS/NLOS channel state and then returns the received power. To retrieve the channel state, they interface with the class ChannelConditionModel through the method GetChannelCondition (mm a, mm b). Some of the models requires the knowledge of UT and BS heights, which are obtained by comparing the heights of the two nodes with the validity ranges specified by the standard, i.e., if height (a) falls inside the validity range for hUT, then hUT = height (a); else if height (a) falls inside the validity range for hBS, then hBS = height (a); and the same for node b. If hUT or hBS cannot be defined because none of the two nodes has a valid height, the default value is used.
• discussion with my mentor about:
  • review of the channel condition model
  • how to avoid code duplication for the implementation of the pathloss models: we discussed about the possibility to define a common base class for all the ThreeGppYYYPropagationLossModel classes, since the methods DoCalcRxPower () are similar. However, this yields to multiple inheritance, which may worsen the code clarity.
  • deliverable for phase 1: it will include the new channel condition model and the 3GPP pathloss models

Week 4 (June 17 - June 23)

• implementation of the test cases for the ThreeGppYYYPropagationLossModel classes. Each test case computes the propagation loss between two mobility models for different values of the distance and for both LOS and NLOS channel states. The resulting value is compared with the corresponding reference value obtained from the formulas specified in TR 38.901.
• discussion with my mentor about the implementation of the propagation models

MR for the new pathloss models: https://gitlab.com/tommasozugno/ns-3-dev/merge_requests/2

Week 5 (June 24 - June 30)

• change the pathloss models implementation following the discussion I had with my mentor. We decided to use the optional NLOS pathloss formula for the UMa and UMi scenarios. In this way we do not need to retrieve the height of the UT, which is a problem if we want to apply the models with height values different from the default ones.
• write the doc for the new channel condition and pathloss models. I have updated the documentation of the propagation module with the description of all the new classes I have added.
• implementation of the shadowing model. The ThreeGppYYYPropagationLossModel classes have an attribute called "ShadowingEnabled" which enables of disables the addition of the shadowing component. If the attribute is set to true, the shadowing component is computed following the procedure specified in 3GPP TR 38.901 and then added to the total loss. For the moment I have not implemented the spatial consistency procedure for the update of the shadowing component.
• weekly discussion with my mentor about:
  • review of the pathloss models implementation
  • postpone the implementation of the O2I penetration loss model. We decided to add it at the end since it is an additional feature and to start with the development of the small scale fading model.

Week 6 (July 1 - July 7)

• update the ThreeGppYYYPropagationLossModel classes and the related documentation following the review comments. In particular, we decided to remove the fatal error that was prompting when the distance between tx and rx is not within the validity range specified in TR 38.901, instead we print a warning message
• open a MR to ns-3-dev containing the new channel condition and pathloss models (https://gitlab.com/nsnam/ns-3-dev/merge_requests/72)
• start the integration of the fast fading model. I added a new class called ThreeGppSpectrumPropagationLossModel which extends the SpectrumPropagationLossModel interface. It has to generate the channel matrix, apply the small scale fading, apply the beamforming and return the PSD of the received signal following the model described in TR 38.901. For the implementation of this class I started from the MmWave3gppChannel class included in the mmwave module
• discussion with my mentor about:
  • review of the pathloss model classes
  • structure of the ThreeGppSpectrumPropagationLossModel
  • possible usage of external libraries to speed up the channel matrix generation procedure
  • definition of a base class for antenna arrays

Week 7 (July 8 - July 14)

• continue the integration of the fast fading model described in TR 38.901. I introduced a new class called ThreeGppChannel which includes the channel matrix generation procedure. Also, I developed the method DoCalcRxPowerSpectralDensity of the class ThreeGppSpectrumPropagationLossModel which i) makes use of an instance of ThreeGppChannel to retrieve the channel matrix, ii) applies the beamforming and iii) returns the received PSD.
• weekly discussion with my mentor about:
  • how to update the channel matrix. We decided to update the channel matrix periodically and define the update time as attribute. Also, we decided to update the long term component (i.e., the product between the channel matrix and the beamforming vectors) only if tx and/or rx changed its beam.
  • how to define the structure used to save the channel realizations and the long term component
  • whether to apply the doppler component when the channel matrix is generated or at each call to DoCalcRxPowerSpectralDensity ()

Week 8 (July 15 - July 21)

• continue the integration of the fast fading model described in TR 38.901, in particular:
  • development of an example which shows how to configure the channel model classes and computes the beamforming gain
  • debug and testing of the channel generation procedure
  • addition of a map to store the channel realizations in the ThreeGppChannel class

Week 9 (July 22 - July 28)

• updated the ThreeGppSpectrumPropagationLossModel to save the long term component associated to each channel. I added a map to store the long term components. Each entry is identified by a channel ID which is computed using the Cantor function applied to the tx and rx node IDs. At each call of DoCalcRxPowerSpectralDensity (), the method looks for the long term in the map. If found, it checks whether it has to be updated (i.e., the channel matrix was updated or the beamforming vectors has changed). If not found or if it has to be updated, the method computes the long term component and stores it in the map.
• started the implementation of the test cases for the classes ThreeGppChannel and ThreeGppSpectrumPropagationLossModel. The first test case checks:
  • if the dimensions of the channel matrix are consistent with the sizes of the antennas
  • if the expectation of the Frobenius norm of the channel matrix is equal to the product between the number of tx and rx antenna elements
  • if the channel matrix is correctly saved
• Discussion with my mentor about:
  • review of the new classes ThreeGppChannel and ThreeGppSpectrumPropagationLossModel
  • whether to recompute the Doppler term at each transmission or at each channel update
  • comments in the MR submitted to ns-3-dev