GSOC20235GUsability: Difference between revisions

From Nsnam
Jump to navigation Jump to search
No edit summary
(add link to final report)
 
(26 intermediate revisions by one other user not shown)
Line 11: Line 11:
* '''Project Goals:''' IUNS-3 5G NR is a GSoC '23 medium-size project proposal that offers a general purpose introductory scenario to dive into the 5G New Radio world, unlocking the ability for users, from university students to research scientists and engineers, to know the 5G architecture in detail and enable them to use the simulator for research and development.
* '''Project Goals:''' IUNS-3 5G NR is a GSoC '23 medium-size project proposal that offers a general purpose introductory scenario to dive into the 5G New Radio world, unlocking the ability for users, from university students to research scientists and engineers, to know the 5G architecture in detail and enable them to use the simulator for research and development.
* '''Repositories:'''
* '''Repositories:'''
** https://gitlab.com/ggrieco/ns-3-dev - ns-3 personal fork
** https://gitlab.com/ggrieco/ns-3-dev - ns-3 personal fork. Please clone "ns-3.38-backport" branch to ensure compatibility with NR module
** https://gitlab.com/ggrieco/nr - NR module personal fork
** https://gitlab.com/ggrieco/nr - NR module personal fork
* '''About Me:''' I am a second-year PhD Student in Electrical and Information Engineering at Polytechnic University of Bari, Italy, focused on Telecommunications Engineering and, more specifically, the Internet of Drones. ns-3 orbited so much around my university career, as I have been developing IoD-Sim, a ns-3 module for the Internet of Drones, since my bachelor's final thesis in 2019. ns-3 still remains my primary tool to test out experimental protocols, applications, and communication technologies that would otherwise require very expensive infrastructure to reproduce in the laboratory. This Google Summer of Code project represents a unique opportunity to better know the community, learn from their experiences, and contribute my ideas to upstream!
* '''About Me:''' I am a second-year PhD Student in Electrical and Information Engineering at Polytechnic University of Bari, Italy, focused on Telecommunications Engineering and, more specifically, the Internet of Drones. ns-3 orbited so much around my university career, as I have been developing IoD-Sim, a ns-3 module for the Internet of Drones, since my bachelor's final thesis in 2019. ns-3 still remains my primary tool to test out experimental protocols, applications, and communication technologies that would otherwise require very expensive infrastructure to reproduce in the laboratory. This Google Summer of Code project represents a unique opportunity to better know the community, learn from their experiences, and contribute my ideas to upstream!
* '''[[GSOC20235GUsabilityFinalReport | Final report]]'''


= Milestones =
= Milestones =
== Week 1 ==


# Read [https://portal.3gpp.org/desktopmodules/Specifications/SpecificationDetails.aspx?specificationId=3191 3GPP TR 38.300] as an overview.  In general, we will look to align with 3GPP terminology and specifications.
# Read [https://portal.3gpp.org/desktopmodules/Specifications/SpecificationDetails.aspx?specificationId=3191 3GPP TR 38.300] as an overview.  In general, we will look to align with 3GPP terminology and specifications.
Line 31: Line 30:
== Week 1 [May 29 - Jun 03] ==
== Week 1 [May 29 - Jun 03] ==
* Tracking ns-3 3.38 release and NR 5g-lena-v2.4.y branch
* Tracking ns-3 3.38 release and NR 5g-lena-v2.4.y branch
* Milestone 5 is tracked over MR [https://gitlab.com/cttc-lena/nr/-/merge_requests/52 52]
* Milestone 5 is tracked over MR [https://gitlab.com/cttc-lena/nr/-/merge_requests/52 !52]
* Some compile-time deprecation/warnings were addressed in MRs [https://gitlab.com/cttc-lena/nr/-/merge_requests/48 48] and [https://gitlab.com/cttc-lena/nr/-/merge_requests/49 49]
* Some compile-time deprecation/warnings were addressed in MRs [https://gitlab.com/cttc-lena/nr/-/merge_requests/48 !48] and [https://gitlab.com/cttc-lena/nr/-/merge_requests/49 !49]
* Minor fixes made in MRs [https://gitlab.com/cttc-lena/nr/-/merge_requests/50 50], [https://gitlab.com/cttc-lena/nr/-/merge_requests/51 51], [https://gitlab.com/cttc-lena/nr/-/merge_requests/53 53]
* Minor fixes made in MRs [https://gitlab.com/cttc-lena/nr/-/merge_requests/50 !50], [https://gitlab.com/cttc-lena/nr/-/merge_requests/51 !51], [https://gitlab.com/cttc-lena/nr/-/merge_requests/53 !53]


== Week 2 [Jun 05 - 10] ==
== Week 2 [Jun 05 - 10] ==
Started the analysis of [https://gitlab.com/cttc-lena/nr/-/blob/master/examples/cttc-nr-demo.cc `cttc-nr-demo`] to probe around usability issues and what I can do to solve them.
* Analyzed [[GSOC20235GUsability/Analysis:cttc-nr-demo | cttc-nr-demo]] code for usability issues


=== Initial Doxygen comments - lines: 7-29 ===
== Week 3 [Jun 12 - 17] ==
  This example describes how to setup a simulation using the 3GPP channel model from TR 38.900.
* Fixing pipeline issues with [https://gitlab.com/cttc-lena/nr/-/merge_requests/54 MR !54]
 
* Fixing 'cttc-nr-demo' usability issues with MRs [https://gitlab.com/cttc-lena/nr/-/merge_requests/55 !55], [https://gitlab.com/cttc-lena/nr/-/merge_requests/56 !56], [https://gitlab.com/cttc-lena/nr/-/merge_requests/57 !57], [https://gitlab.com/cttc-lena/nr/-/merge_requests/58 !58], [https://gitlab.com/cttc-lena/nr/-/merge_requests/59 !59]
The 3GPP TR 38.900 is part of Release 15 regarding the ''Study on channel model for frequency spectrum above 6 GHz''. It is freely available at the [https://portal.3gpp.org/desktopmodules/Specifications/SpecificationDetails.aspx?specificationId=2991 3GPP Portal] and on [https://portal.etsi.org/webapp/workprogram/Report_WorkItem.asp?WKI_ID=55982 ETSI] as PDF.
 
First of all, please notice that here we are dealing with a standard that is marked as obsolete, as per comment by John M Meredith make in 2018:
  This spec is not maintained after v15.0.0. It is superseded by 38.901.
which is the ''Study on channel model for frequencies from 0.5 to 100 GHz'' and it is available on the [https://portal.3gpp.org/desktopmodules/Specifications/SpecificationDetails.aspx?specificationId=3173 3GPP Portal].
 
So, first of all, are we sure that we are working on code that provides the latest standard implementation Out of the Box? A quick search
  $ grep -ri 'TR 38.900' contrib/nr | wc -l
  16
  $ grep -ri 'TR 38.901' contrib/nr | wc -l
  9
reveals that the module has been updated to support the more recent [https://portal.3gpp.org/desktopmodules/Specifications/SpecificationDetails.aspx?specificationId=3173 TR 38.901].
 
{| border=1 cellspacing=0 cellpadding=3
|+ Possible Tasks
! ID !! Task
|-
! T1
| Does `cttc-nr-demo` also follows [https://portal.3gpp.org/desktopmodules/Specifications/SpecificationDetails.aspx?specificationId=3173 TR 38.901]?
|-
! T2
| Giving the current state of the code, are we sure to follow 100% TR 38.900, even though there is code that refers to [https://portal.3gpp.org/desktopmodules/Specifications/SpecificationDetails.aspx?specificationId=3173 TR 38.901]?
|-
! T3
| Is this code also compliant to [https://portal.3gpp.org/desktopmodules/Specifications/SpecificationDetails.aspx?specificationId=3173 TR 38.901]? If so, can we explicitly say it?
|-
|}
 
  This example consists of a simple grid topology, in which you can choose the number of gNbs and UEs. Have a look at the possible parameters to know what you can configure through the command line.
 
First of all, there is a small typo on "gNb", as it should be written as '''gNB'''. This term is defined in [https://portal.3gpp.org/desktopmodules/Specifications/SpecificationDetails.aspx?specificationId=3191 TS 38.300]:
'''gNB''': node providing NR user plane and control plane protocol terminations towards the UE, and connected via the NG interface to the 5GC
 
This is not the only part where gNB is spelled wrongly:
  $ grep -r 'gNb' contrib/nr/ | wc -l
  423
 
Furthermore, here we talk about the "command line". There is no reference of how such command line interface works in the [https://cttc-lena.gitlab.io/nr/nrmodule.pdf NR official manual], neither in the repository [https://gitlab.com/cttc-lena/nr/-/blob/master/README.md README.md file]. Only the [https://cttc-lena.gitlab.io/nr/html/cttc-nr-demo_8cc.html doxygen] documentation reports examples of how its syntax, but such information is not readily available for the novel user.


{| border=1 cellspacing=0 cellpadding=3
== Week 4 [Jun 19 - 24] ==
|+ Possible Tasks
* An experimental fix of pipeline with has been made with commit [https://gitlab.com/cttc-lena/nr/-/merge_requests/54/diffs?commit_id=78bdebbed1c383277f08c8913a60b1eb4d1b4614 78bdebbe]
! ID !! Task
* Some advices were made to improve [https://gitlab.com/cttc-lena/nr/-/merge_requests/54 MR !54] even more, by aligning the pipeline configuration with ns-3.
|-
* Fixing compile issues with MR [https://gitlab.com/cttc-lena/nr/-/merge_requests/60 !60]
! T4
| Given that we are writing code that follows consolidated standards, shall we adhere (and thus, fix) the spelling of official terms?
|-
! T5
| Shall we explicitly define how the command line interface works to run a NR module example in the project README and/or manual?
|-
|}


With the default configuration, the example will create two flows that will go through two different subband numerologies (or bandwidth parts). For that, specifically, two bands are created, each with a single Carrier Component (CC), and each CC containing one bandwidth part (BWP).
== Week 5 [Jun 26 - Jul 01] ==
* Alignment of the pipeline with ns-3 has been made in [https://gitlab.com/cttc-lena/nr/-/merge_requests/54 MR !54]
* Presentation of the current state of the project, issues, and difficulties at [https://www.nsnam.org/research/wns3/wns3-2023/program/ WNS3 2023]
* Fixing 'cttc-nr-demo' usability issues with MRs [https://gitlab.com/cttc-lena/nr/-/merge_requests/61 !61]


Here we use some technical terms that are related to specific features of NR. This is aggravate by the fact that we are using technical acronyms, i.e., CC, without writing them in extended form. Unfortunately, a quick search of "subband numerologies", "bandwidth part", and "CC" over the aforementioned TR 38.900 returns no explanation or usage.
== Week 6 [Jul 03 - Jul 08] ==
* All previous merge requests were checked for issues and fixed.
* Started a thorough and high-level description of the 'cttc-nr-demo' scenario at [https://gitlab.com/ggrieco/ns-3-nr-first-steps this repository].


Consequently, this paragraph is hard to understand if the user does not already have a broader understanding of the several standards that characterize NR, or 3GPP Release 16 (and higher) in general.
== Week 7 [Jul 10 - Jul 15] ==
* Discussed about how to convey information in the tutorial, preferably in the form of sequence diagrams. Such draft is still private.
* Added documentation on 'GridScenarioHelper' with MR [https://gitlab.com/cttc-lena/nr/-/merge_requests/62 !62]


{| border=1 cellspacing=0 cellpadding=3
== Week 8 [Jul 17 - Jul 22] ==
|+ Possible Tasks
* Started discussing on possible usability improvements in Packet Tracing - MR [https://gitlab.com/cttc-lena/nr/-/merge_requests/65 !65]
! ID !! Task
* Fixes on past MRs and pipeline configuration
|-
! T6
| Given that `cttc-nr-demo` should be a welcoming demo: a reading of [https://portal.3gpp.org/desktopmodules/Specifications/SpecificationDetails.aspx?specificationId=3191 3GPP TS 38.300] ''"NR; NR and NG-RAN Overall description; Stage-2"'' should be recommended, even before mentioning TR 38.900, as it provides the basic definitions about Carrier Component (CC), sub-band numerologies, and Bandwidth Part (BWP). While CC is mentioned in Section 5.4.1, the remaining twos are defined in Section 5.1.
|-
! T7
| User profile: what is the type of user that we want to address with this example? Does he/she/_ already know all the NR standards? How about ns-3? How about the programming language, i.e., C++? Can he/she/_ may be a student, still learning all of these things, even the basic theory behind mobile communications?
|-
|}


  The example will print on-screen the end-to-end result of one (or two) flows, as well as writing them on a file.
== Week 9 [Jul 24 - Jul 29] ==
* Continuing developments on Packet Tracing usability over MR [https://gitlab.com/cttc-lena/nr/-/merge_requests/65 !65]
* Solving an issue related to MRs [https://gitlab.com/cttc-lena/nr/-/merge_requests/55 !55], [https://gitlab.com/cttc-lena/nr/-/merge_requests/57 !57], and [https://gitlab.com/cttc-lena/nr/-/merge_requests/58 !58]


This output appears to be too strict. As it is quite succinct for an experienced user, who may easily imagine the node positions, its stack configuration, its traffic, and the overall network topology. On the contrary, an inexperienced user may expect some context to fully understand these Key Performance Indices (KPIs) and statistics.
== Week 10 [Jul 31 - Aug 05] ==
* Squash together MRs [https://gitlab.com/cttc-lena/nr/-/merge_requests/55 !55], [https://gitlab.com/cttc-lena/nr/-/merge_requests/57 !57], and [https://gitlab.com/cttc-lena/nr/-/merge_requests/58 !58] in MR [https://gitlab.com/cttc-lena/nr/-/merge_requests/67 !67] after some feedback to better organize inserted URLs.
* Ongoing logging level refactoring and new trace sources on [https://gitlab.com/ggrieco/ns-3-dev/-/tree/enable-lte-traces?ref_type=heads ns-3 LTE module] and [https://gitlab.com/ggrieco/nr/-/tree/enable-traces?ref_type=heads NR one].


{| border=1 cellspacing=0 cellpadding=3
== Week 11 [Aug 07 - Aug 12] ==
|+ Possible Tasks
* Published [https://gitlab.com/cttc-lena/nr/-/merge_requests/68 MR !68] related to the demotion of some Informational logs messages to Function trace messages.
! ID !! Task
* New sequence diagrams are included in the tutorial to better explain the packet lifecycle, especially when it is forwarded through the RAN - [https://gitlab.com/ggrieco/nr/-/tree/tutorial?ref_type=heads ggrieco/nr:tutorial]
|-
! T8
| By default, `cttc-nr-demo` should output additional contextual information to clarify the statistics that are already shown. This can range from the position of the nodes to their stack configuration, traffic in easily accessible PCAP format, and overall network topology.
|-
|}


  With this line, we will be able to see the logs of the file by enabling the component "CttcNrDemo".
== Week 12 [Aug 14 - Aug 19] ==
* Work ongoing to finish the [https://gitlab.com/ggrieco/nr/-/tree/tutorial?ref_type=heads tutorial]


Log components are not explained in the [https://cttc-lena.gitlab.io/nr/nrmodule.pdf), neither in the [README](https://gitlab.com/cttc-lena/nr/-/blob/master/README.md NR official manual].
== Week 13 [Aug 21 - Aug 26] ==
* Work ongoing to finish the [https://gitlab.com/ggrieco/nr/-/tree/tutorial?ref_type=heads tutorial]
* Created MR [https://gitlab.com/cttc-lena/nr/-/merge_requests/71 !71] to review the efforts made for the tutorial.


{| border=1 cellspacing=0 cellpadding=3
== Week 14 [Aug 28 - Sep 02] ==
|+ Possible Tasks
* Work ongoing to finish the [https://gitlab.com/ggrieco/nr/-/tree/tutorial?ref_type=heads tutorial]
! ID !! Task
* Tutorial assessment and review by mentors
|-
* Raised issue [https://gitlab.com/cttc-lena/nr/-/issues/165 #165]
! T9
| Provide some references on how the user can work with log components in NR module, or ns-3 in general. This [https://www.nsnam.org/docs/release/3.38/tutorial/html/tweaking.html#using-the-logging-module tutorial] may be helpful.
|-
|}


=== Code lines 148-153 ===
== Week 15 [Sep 04 - Sep 09] ==
  /*
* Improvement, revision and evaluation of the [https://gitlab.com/ggrieco/nr/-/tree/tutorial?ref_type=heads tutorial]
  * Check if the frequency is in the allowed range.
* Final assessment and submission to GSoC organization
  * If you need to add other checks, here is the best position to put them.
  */
  NS_ABORT_IF(centralFrequencyBand1 > 100e9);
  NS_ABORT_IF(centralFrequencyBand2 > 100e9);
 
According to [https://portal.3gpp.org/desktopmodules/Specifications/SpecificationDetails.aspx?specificationId=3173 TR 38.901], we miss the lower bound limit of 0.5 GHz.
 
{| border=1 cellspacing=0 cellpadding=3
|+ Possible Tasks
! ID !! Task
|-
! T10
| Shall we extend such assertion to include the [https://portal.3gpp.org/desktopmodules/Specifications/SpecificationDetails.aspx?specificationId=3173 TR 38.901] check at its lower bound?
|-
|}
 
=== Code lines 155-170 ===
  /*
  * If the logging variable is set to true, enable the log of some components
  * through the code. The same effect can be obtained through the use
  * of the NS_LOG environment variable:
  *
  * export NS_LOG="UdpClient=level_info|prefix_time|prefix_func|prefix_node:UdpServer=..."
  *
  * Usually, the environment variable way is preferred, as it is more customizable,
  * and more expressive.
  */
  if (logging)
  {
    LogComponentEnable("UdpClient", LOG_LEVEL_INFO);
    LogComponentEnable("UdpServer", LOG_LEVEL_INFO);
    LogComponentEnable("LtePdcp", LOG_LEVEL_INFO);
  }
 
This information would solve `T9` by anticipating such information.
 
{| border=1 cellspacing=0 cellpadding=3
|+ Possible Tasks
! ID !! Task
|-
! T11
| Shall we move this explanation to line ~58? How about repeating it in the [https://cttc-lena.gitlab.io/nr/nrmodule.pdf NR official manual] and/or in the [https://gitlab.com/cttc-lena/nr/-/blob/master/README.md README.md file]?
|-
|}
 
=== Code lines 172-176 ===
  /*
  * Default values for the simulation. We are progressively removing all
  * the instances of SetDefault, but we need it for legacy code (LTE)
  */
  Config::SetDefault("ns3::LteRlcUm::MaxTxBufferSize", UintegerValue(999999999));
 
This does not seem to be entirely related to the example per se, given that it misses key information on why such scenario should have such value to be set. Furthermore, such value is applied across all example scenarios. To this end, it would be better to hide such code from the user eyes, in order to not cause confusion.
 
{| border=1 cellspacing=0 cellpadding=3
|+ Possible Tasks
! ID !! Task
|-
! T12
| What is the role of this line? Shall we move this code to `ns3::NrHelper`? Maybe to a method called `void SetupDefaultNrNsaParameters()`?
|-
|}
 
=== Code lines 178-198 ===
  /*
  * Create the scenario. In our examples, we heavily use helpers that setup
  * the gnbs and ue following a pre-defined pattern. Please have a look at the
  * GridScenarioHelper documentation to see how the nodes will be distributed.
  */
  int64_t randomStream = 1;
  GridScenarioHelper gridScenario;
  gridScenario.SetRows(1);
  gridScenario.SetColumns(gNbNum);
  gridScenario.SetHorizontalBsDistance(5.0);
  gridScenario.SetVerticalBsDistance(5.0);
  gridScenario.SetBsHeight(1.5);
  gridScenario.SetUtHeight(1.5);
  // must be set before BS number
  gridScenario.SetSectorization(GridScenarioHelper::SINGLE);
  gridScenario.SetBsNumber(gNbNum);
  gridScenario.SetUtNumber(ueNumPergNb * gNbNum);
  gridScenario.SetScenarioHeight(3); // Create a 3x3 scenario where the UE will
  gridScenario.SetScenarioLength(3); // be distribuited.
  randomStream += gridScenario.AssignStreams(randomStream);
  gridScenario.CreateScenario();
 
'''`ns3::GridScenarioHelper` documentation is marked as TODO''' in the [https://gitlab.com/cttc-lena/nr/-/blob/master/helper/grid-scenario-helper.h source file].
Furthermore, ''distance'', ''length'', and ''height'' properties do not provide any unit of measurement. This is aggravated by the lack of any sort of unit to be used in both code (we have a generic `double`) and documentation. Intuitively, the user, which may come from any place of Earth, can be confused on using the [https://www.nist.gov/pml/owm/metric-si/si-units International System of Units (SI)], the metric system, or the imperial one.
 
{| border=1 cellspacing=0 cellpadding=3
|+ Possible Tasks
! ID !! Task
|-
! T13
| Shall we document `ns3::GridScenarioHelper`?
|-
! T14
| Is it ok to provide the information over the unit of measurements to be used? Where should we say so? Is it ok to provide macros/helpers to be able to specify measurements in metric and/or imperial? Shall we stick to the SI?
|-
|}
 
== Week 3 [Jun 12 - 17] ==

Latest revision as of 16:31, 11 September 2023

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 2023 projects

Project Overview

  • Project Name: IUNS-3 5G NR: Improving the Usability of ns-3's 5G NR Module
  • Student: Giovanni Grieco
  • Mentors: Tom Henderson, Katerina Koutlia, and Biljana Bojovic
  • Google page: https://summerofcode.withgoogle.com/programs/2023/projects/oeDFknbT
  • Project Goals: IUNS-3 5G NR is a GSoC '23 medium-size project proposal that offers a general purpose introductory scenario to dive into the 5G New Radio world, unlocking the ability for users, from university students to research scientists and engineers, to know the 5G architecture in detail and enable them to use the simulator for research and development.
  • Repositories:
  • About Me: I am a second-year PhD Student in Electrical and Information Engineering at Polytechnic University of Bari, Italy, focused on Telecommunications Engineering and, more specifically, the Internet of Drones. ns-3 orbited so much around my university career, as I have been developing IoD-Sim, a ns-3 module for the Internet of Drones, since my bachelor's final thesis in 2019. ns-3 still remains my primary tool to test out experimental protocols, applications, and communication technologies that would otherwise require very expensive infrastructure to reproduce in the laboratory. This Google Summer of Code project represents a unique opportunity to better know the community, learn from their experiences, and contribute my ideas to upstream!
  • Final report

Milestones

  1. Read 3GPP TR 38.300 as an overview. In general, we will look to align with 3GPP terminology and specifications.
  2. Start to document somewhere (Google doc, or Sphinx) the lifecycle of these UDP packets-- what are the interesting things that happen to each packet to get it through the RAN?
  3. Start to migrate LOG statements so that interesting logs are in NS_LOG_INFO and NS_LOG_WARN. See WifiHelper::EnableLogComponents()-- we should come up with a similar one for NrHelper::EnableLogComponents (level=INFO by default). Alternative is to place dedicated methods in the nr examples, tailored to logs of interest.
  4. Enable traces: //nrHelper->EnableTraces(); perhaps controlled by a command line argument. How can these help the new user?
  5. Line 453 of cttc-nr-demo.cc states: // From here, it is standard NS3. In the future, we will create helpers for this part as well. Start to create such helpers, focusing first on application and TFT configuration.
  6. Start to experiment with the ConfigStore loading and saving of attributes and default values.
  7. Measuring latency within the NR RAN-- new trace sources at ingress and egress of NetDevice? Packet tags?

Weekly Report

Week 1 [May 29 - Jun 03]

  • Tracking ns-3 3.38 release and NR 5g-lena-v2.4.y branch
  • Milestone 5 is tracked over MR !52
  • Some compile-time deprecation/warnings were addressed in MRs !48 and !49
  • Minor fixes made in MRs !50, !51, !53

Week 2 [Jun 05 - 10]

Week 3 [Jun 12 - 17]

  • Fixing pipeline issues with MR !54
  • Fixing 'cttc-nr-demo' usability issues with MRs !55, !56, !57, !58, !59

Week 4 [Jun 19 - 24]

  • An experimental fix of pipeline with has been made with commit 78bdebbe
  • Some advices were made to improve MR !54 even more, by aligning the pipeline configuration with ns-3.
  • Fixing compile issues with MR !60

Week 5 [Jun 26 - Jul 01]

  • Alignment of the pipeline with ns-3 has been made in MR !54
  • Presentation of the current state of the project, issues, and difficulties at WNS3 2023
  • Fixing 'cttc-nr-demo' usability issues with MRs !61

Week 6 [Jul 03 - Jul 08]

  • All previous merge requests were checked for issues and fixed.
  • Started a thorough and high-level description of the 'cttc-nr-demo' scenario at this repository.

Week 7 [Jul 10 - Jul 15]

  • Discussed about how to convey information in the tutorial, preferably in the form of sequence diagrams. Such draft is still private.
  • Added documentation on 'GridScenarioHelper' with MR !62

Week 8 [Jul 17 - Jul 22]

  • Started discussing on possible usability improvements in Packet Tracing - MR !65
  • Fixes on past MRs and pipeline configuration

Week 9 [Jul 24 - Jul 29]

  • Continuing developments on Packet Tracing usability over MR !65
  • Solving an issue related to MRs !55, !57, and !58

Week 10 [Jul 31 - Aug 05]

  • Squash together MRs !55, !57, and !58 in MR !67 after some feedback to better organize inserted URLs.
  • Ongoing logging level refactoring and new trace sources on ns-3 LTE module and NR one.

Week 11 [Aug 07 - Aug 12]

  • Published MR !68 related to the demotion of some Informational logs messages to Function trace messages.
  • New sequence diagrams are included in the tutorial to better explain the packet lifecycle, especially when it is forwarded through the RAN - ggrieco/nr:tutorial

Week 12 [Aug 14 - Aug 19]

Week 13 [Aug 21 - Aug 26]

  • Work ongoing to finish the tutorial
  • Created MR !71 to review the efforts made for the tutorial.

Week 14 [Aug 28 - Sep 02]

  • Work ongoing to finish the tutorial
  • Tutorial assessment and review by mentors
  • Raised issue #165

Week 15 [Sep 04 - Sep 09]

  • Improvement, revision and evaluation of the tutorial
  • Final assessment and submission to GSoC organization
Retrieved from "https://www.nsnam.org/mediawiki/index.php?title=GSOC20235GUsability&oldid=12950"