Difference between revisions of "GSOC2024Projects"

From Nsnam
Jump to: navigation, search
(Created page with "{{TOC}} This page contains 2024 Google Summer of Code project ideas for ns-3. * [https://developers.google.com/open-source/gsoc/faq GSoC Frequently Asked Questions] * GS...")
 
(5G NR module benchmark analysis for different channel models)
 
(61 intermediate revisions by 4 users not shown)
Line 1: Line 1:
 
{{TOC}}
 
{{TOC}}
  
This page contains 2024 Google Summer of Code project ideas for ns-3.
+
This page contains 2024 Google Summer of Code project ideas for ns-3.
  
 
* [https://developers.google.com/open-source/gsoc/faq GSoC Frequently Asked Questions]
 
* [https://developers.google.com/open-source/gsoc/faq GSoC Frequently Asked Questions]
* [[GSOC2023ContributorGuide |ns-3's 2023 GSoC Contributor guide]]
+
* [[GSOC2024ContributorGuide |ns-3's 2024 GSoC Contributor guide]]
 
* [https://developers.google.com/open-source/gsoc/resources/guide GSoC contributor/student guide (not ns-3 specific)]
 
* [https://developers.google.com/open-source/gsoc/resources/guide GSoC contributor/student guide (not ns-3 specific)]
* [[GSOC2023ApplicationTemplate |2023 GSoC Contributor application template]]
+
* [[GSOC2024ApplicationTemplate |2024 GSoC Contributor application template]]
 
* [[GSOCMentorGuide | ns-3's GSoC Mentor guide]]
 
* [[GSOCMentorGuide | ns-3's GSoC Mentor guide]]
 
* [https://archive.flossmanuals.net/gsocmentoring/index.html GSoC Mentor guide (not ns-3 specific)]
 
* [https://archive.flossmanuals.net/gsocmentoring/index.html GSoC Mentor guide (not ns-3 specific)]
Line 26: Line 26:
 
=== Mentors ===
 
=== Mentors ===
  
Mentors will be paired with contributors based on the projects that are selected.  Mentors from companies are welcome, if the employer will permit the mentor sufficient time to perform the mentoring.  Prospective mentors should notify Mohit P. Tahiliani or Tommaso Pecorella of interest.  Mentors familiar with ns-3 development practices will be preferred, to improve the chances of code merge. In 2022, we are going to be seeking two-person or multiple-person mentoring teams for projects, to help with the mentoring workload and bring more expertise.
+
Mentors will be paired with contributors based on the projects that are selected.  Mentors from companies are welcome, if the employer will permit the mentor sufficient time to perform the mentoring.  Prospective mentors should notify Mohit P. Tahiliani or Tommaso Pecorella of interest.  Mentors familiar with ns-3 development practices will be preferred, to improve the chances of code merge. We are going to be seeking two-person or multiple-person mentoring teams for projects, to help with the mentoring workload and bring more expertise.
  
The current list of prospective mentors for 2023 can be found among the ideas listed below.
+
The current list of prospective mentors can be found among the ideas listed below.
  
 
=== How to apply ===
 
=== How to apply ===
Line 34: Line 34:
 
For students or contributors interested in applying to ns-3 for GSoC, please go through the following list to get started:
 
For students or contributors interested in applying to ns-3 for GSoC, please go through the following list to get started:
 
* Read the official [https://developers.google.com/open-source/gsoc/resources/guide GSoC contributor guide].
 
* Read the official [https://developers.google.com/open-source/gsoc/resources/guide GSoC contributor guide].
* Read [[GSOC2023ContributorGuide |ns-3's GSoC contributor guide]]
+
* Read [[GSOC2024ContributorGuide |ns-3's GSoC contributor guide]]
 
* Look through our [[#Project Ideas]] below to see if you find a project that interests you.
 
* Look through our [[#Project Ideas]] below to see if you find a project that interests you.
 
* Review the [https://www.nsnam.org/documentation/development-tree/ tutorial and contributing guide] thoroughly, if you have not already done so.
 
* Review the [https://www.nsnam.org/documentation/development-tree/ tutorial and contributing guide] thoroughly, if you have not already done so.
* Once it is posted, look through the [[GSOC2023ApplicationTemplate |GSoC application template]] to start preparing your proposal.  We will wait to see whether we are actually part of GSoC before posting this.
+
* Once it is posted, look through the [[GSOC2023ApplicationTemplate |GSoC application template]] to start preparing your proposal.  We will wait to see whether we are actually part of GSoC before updating the above link for 2024, but it will be similar to last year's application.
* Next, proceed to get in touch with the developers on the mailing list or chat room and refine your proposal.
+
* Next, proceed to get in touch with the developers on the mailing list or Zulip chat room and refine your proposal.
 
* In parallel, make sure you prepare a patch as per the patch requirement guidelines. Your application to ns-3 will not be considered if you do not fulfill this requirement.
 
* In parallel, make sure you prepare a patch as per the patch requirement guidelines. Your application to ns-3 will not be considered if you do not fulfill this requirement.
  
Below is a list of [[#Project Ideas]] proposed by the ns-3 team for Google Summer of Code 2023.  Please note that these ideas are not limited to GSoC; anyone is welcome to work on them. Please email the [https://groups.google.com/g/ns-developers ns-developers list] if you have a different idea that you'd like to work on, to see if a mentor may be interested.  Applicants are encouraged to look over this list, pick one that especially interests them, think about it, and discuss potential approaches on the [https://groups.google.com/g/ns-developers ns-developers list]. Previous experience with the Google Summer of Code programs suggest that the more you discuss and refine your proposal on the mailing list beforehand, the stronger the proposal it will develop into, and the higher your chances of being accepted into the program.
+
Below is a list of [[#Project Ideas]] proposed by the ns-3 team for Google Summer of Code 2024.  Please note that these ideas are not limited to GSoC; anyone is welcome to work on them. Please email the [https://groups.google.com/g/ns-developers ns-developers list] if you have a different idea that you'd like to work on, to see if a mentor may be interested.  Applicants are encouraged to look over this list, pick one that especially interests them, think about it, and discuss potential approaches on the [https://groups.google.com/g/ns-developers ns-developers list]. Previous experience with the Google Summer of Code programs suggest that the more you discuss and refine your proposal on the mailing list beforehand, the stronger the proposal it will develop into, and the higher your chances of being accepted into the program.
  
 
<blockquote>
 
<blockquote>
Line 56: Line 56:
 
=== Patch requirement guidelines ===
 
=== Patch requirement guidelines ===
  
Each project idea has either a suggested task, or a link to a [[GSOC2023PatchRequirement | generic task]], that a contributor must do to demonstrate some ability to carry out a GSoC project successfully. Performing one task is necessary for a successful application, and performing more than one task is ''not'' necessary.
+
Each project idea has either a suggested task, or a link to a [[GSOC2024PatchRequirement | generic task]], that a contributor must do to demonstrate some ability to carry out a GSoC project successfully. Performing one task is necessary for a successful application, and performing more than one task is ''not'' necessary.
  
 
Contributors that already contributed to the ns-3 codebase with non-trivial bug fixing or features additions might be exempted from performing a task. If you have doubts about if your contributions made you eligible for the task exemption contact the mentors.
 
Contributors that already contributed to the ns-3 codebase with non-trivial bug fixing or features additions might be exempted from performing a task. If you have doubts about if your contributions made you eligible for the task exemption contact the mentors.
Line 70: Line 70:
 
== Project Ideas ==
 
== Project Ideas ==
  
'''Note to contributors:''' These ideas are not listed in any priority order. If an idea doesn't have a mentor yet, it means that if you are interested, you should announce your interest and see if there is a mentor who might pick it up.
+
'''Note to contributors:''' These ideas are not listed in any priority order.
 +
The projects can be grouped depending on their scope and/or their size. Below they are organized according to their scope. Please check each idea for details about its foreseen difficulty level.
  
==== Medium sized projects (175 hours) ====
+
=== Internet models enhancements ===
  
===== ICMP socket and generate/handle ICMP messages (host/net unreachable) =====
+
* [[#ICMP socket and generate/handle ICMP messages (host/net unreachable)]] (medium size project, 175h)
 +
* [[#IPv6 global routing]] (large size project, 350h)
 +
* [[#DHCPv6 (DHCP for IPv6)]] (medium size project, 175h)
 +
* [[#IPv6 support in Ad hoc Routing Protocols]] (large size project, 350h)
 +
 
 +
=== IoT models enhancements ===
 +
 
 +
* [[#6LoWPAN mesh-under routing enhancements]] (medium size project, 175h)
 +
* [[#6LoWPAN neighbor discovery protocol]] (medium size project, 175h)
 +
* [[#Mesh Link Establishment (MLE) protocol ]] (large size project, 350h)
 +
* [[#Lr-WPAN (IEEE 802.15.4) preamble detection support]] (large size project, 350h)
 +
 
 +
=== 5G NR models enhancements ===
 +
 
 +
* [[#Improving 5G NR module usability]] (medium size project, 90h)
 +
* [[#Improving 5G NR module visualizations]] (medium size project, 175h)
 +
* [[#5G NR module benchmark analysis for different channel models]] (medium size project, 175h)
 +
 
 +
== Small sized projects (90 hours) ==
 +
 
 +
===== Improving 5G NR module visualizations =====
 +
 
 +
Mentors: [mailto:gcarvalho@cttc.es Gabriel Ferreira], [mailto:bbojovic@cttc.es Biljana Bojovic] and [mailto:kkoutlia@cttc.es Katerina Koutlia]
 +
 
 +
Note: This could be proposed as either a small- or medium-sized project.
 +
 
 +
The ns-3 5G nr module (aka 5G-LENA) is one of the most highly used and advanced ns-3 modules for simulating the 5G NR network. This project would be to improve the usability and examples of the 5G nr module by adding visualization tools to enrich the end-user experience.
 +
 
 +
The main output will be the creation or porting of one (if small) or more examples from C++ to Python and adding visualization capabilities based on existing traces. The idea is that users can then see how the visualization was generated and better understand how the metrics collection works, and how changing parameters can affect simulation results. For this, the Jupyter notebook will be used, while Python scripts will be implemented for the visualization of the results.
 +
 
 +
Examples to be implemented in Python:
 +
 
 +
* An animated version of the REM map showing gNB beams moving along with a moving UE.
 +
* Resource allocation grid comparison for different resource schedulers.
 +
 
 +
For starters, we would suggest adding the CTTC 5G-LENA (nr module) to ns-3, in the typical way (as a module in the contrib/ directory), then building and running the examples. After getting used to C++, then proceed to use the Python bindings, as described by the documentation: https://www.nsnam.org/docs/manual/html/python.html#using-the-bindings-from-the-ns-3-source.
 +
Documentation is available here: https://5g-lena.cttc.es/. There is an overview tutorial video available here: https://acmse.net/2021/tutorials-offered/#tut-work03. That is the background information. For more specific guidelines, please view this [https://docs.google.com/document/d/1cQLIF1cdft1yj3vyWrjrxN2xDJMx8PuWaa9NP_nKf64/edit?usp=sharing Google document].
 +
 
 +
* Required Experience: C++ and Python programming, understanding of 5G NR, LTE, and wireless networks
 +
* Interests: 5G NR simulations
 +
* Difficulty: Medium.
 +
* Patch requirement: See the [https://www.nsnam.org/wiki/GSOC2024PatchRequirement description]. You can also consider some of the [https://gitlab.com/cttc-lena/nr/-/issues/?label_name%5B%5D=good%20first%20issue nr good to start issues]. Or, you can start writing some APIs for the selected project proposal. Also, if you have some previous MRs to ns-3 or the nr module, you can contact us to check whether it is enough for the patch requirement.
 +
 
 +
== Medium sized projects (175 hours) ==
 +
 
 +
=== ICMP socket and generate/handle ICMP messages (host/net unreachable) ===
  
 
Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], [mailto:manoj24.rana@gmail.com Manoj K. Rana].
 
Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], [mailto:manoj24.rana@gmail.com Manoj K. Rana].
Line 100: Line 146:
  
 
Possible tasks to fulfill the patch requirement:
 
Possible tasks to fulfill the patch requirement:
* [[GSOC2023PatchRequirement]]
+
* [[GSOC2024PatchRequirement]]
  
===== Dynamic device registration for NetAnim simulation animations =====
+
=== 6LoWPAN mesh-under routing enhancements ===
  
Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], [mailto:manoj24.rana@gmail.com Manoj K. Rana].
+
Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], [TBD].
  
NetAnim is a graphical interface based on QT able to visualise nodes movement and messages between nodes either while the simulation is running or when the simulation is ended. It is particularly useful to visualise network dynamics, and to demonstrate scenarios.
+
The 6LoWPAN module offers a simple option to implement a multi-hop topology by using a contolled flooding. However, the implemented controlled flooding is very simple, and is not efficient in complex networks. This is mainly due to the lack of congestion control, or rather its naive implementation.
 +
A better approach would be to borrow some concepts and ideas from RFC 7731 Multicast Protocol for Low-Power and Lossy Networks (MPL), so that messages do not generate network congestions when the network is large.
  
However, it has one severe limitation: it requires events from the nodes and the NetDevices, and to do so it hooks on several callbacks. The problem is that this approach requires that all the NetDevices are compiled along with NetAnim, or the compilation fails. Moreover, if a new NetDevice is added, it is necessary to change the NetAnim code as well.
+
The candidate should outline what parts of code are going to be affected, and how they can be enhanced thanks to RFC 7731.
  
An example of the first limitation is: suppose you want to not compile the WiMAX module, but you want to use NetAnim. You can't.
+
* ''Required Experience:'' Fundamentals of IPv6 addressing, C++ programming.
An example of the second limitation is: suppose you want to make a model for the AppStore - it will not be able to use NetAnim.
+
* ''Bonus Experience:'' Familiarity with mesh routing and 6LoWPAN ns-3
 
+
* ''Interests:'' IPv6 mesh routing
The goal of the idea is to refactor NetAnim so that it uses an approach similar to the Energy module - each module willing to use NetAnim will have a (small) class responsible for the communication between the two modules, enabled only if NetAnim is compiled. This will break the dependencies, and will allow more flexibility for AppStore modules.
+
* ''Difficulty:'' Easy.
 
+
* ''Patch requirement:'' [[GSOC2024PatchRequirement]]
* ''Required Experience:'' C++ programming.
+
* ''Interests:'' Code refactoring.
+
* ''Difficulty:'' Medium.
+
 
* ''Recommended reading:''
 
* ''Recommended reading:''
** [https://www.nsnam.org/wiki/NetAnim_3.108 NetAnim]
+
** [https://www.nsnam.org/docs/models/html/sixlowpan.html#mesh-under-routing Mesh-under in ns-3 6LoWPAN]
** [https://gitlab.com/nsnam/ns-3-dev/-/issues/162 Issue #162]
+
** [https://datatracker.ietf.org/doc/html/rfc7731 RFC 7731]
  
 
Possible tasks to fulfill the patch requirement:
 
Possible tasks to fulfill the patch requirement:
* [[GSOC2023PatchRequirement]]
+
* TBD
  
===== Linux-like Loss Detection Techniques for ns-3 TCP =====
+
=== 6LoWPAN neighbor discovery protocol ===
  
Mentors: [mailto:tahiliani.nitk@gmail.com Mohit P. Tahiliani], [mailto:bhaskar.k7920@gmail.com Bhaskar Kataria]
+
Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], [TBD].
  
Forward Acknowledgement (FACK), Duplicate Selective Acknowledgement (DSACK), Tail Loss Probe (TLP) and Recent Acknowledgement (RACK) are the loss detection techniques implemented in the Linux kernel. These techniques have been already implemented for ns-3 TCP but their code is not yet merged into the mainline. This project has four main goals: (1) update the implementation of these techniques according to the latest ns-3-dev, (2) develop a framework to test the functionality of these techniques, (3) develop example program(s) to demonstrate the usage of these techniques in ns-3 and (4) merge these techniques in the mainline of ns-3.
+
The 6LoWPAN-ND (RFCs 4944, 6775, and 8505) is a replacement for IPv6 DAD and NDP for 6LoWPAN networks, and it is important to ensure address uniquness across a network that can potentially use different MAC/PHY layers.
  
* ''Required Experience:'' Familiarity with TCP and C++ programming.
+
There is a model for 6LoWPAN-ND, but it still not merged in the main ns-3 branch. The goal is to cleanup the implementation, remove an actual limitation due to a questionble assumption, and to add the support for multi-hop operations (EDAR and EDAC messages).
* ''Bonus Experience:'' Familiarity with TCP implementation in Linux kernel.
+
* ''Interests:'' TCP packet loss detection techniques.
+
* ''Difficulty:'' Medium to Hard.
+
* ''Patch requirement:'' [[GSOC2023PatchRequirement]]
+
* ''Recommended Reading:''
+
** Forward Acknowledgement (FACK) [[https://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.41.2559&rep=rep1&type=pdf Paper]] [[https://gitlab.com/nsnam/ns-3-dev/-/merge_requests/34/commits Implementation]]
+
** Duplicate Selective Acknowledgment (DSACK) [[https://tools.ietf.org/html/rfc2883 RFC 2883]] [[https://gitlab.com/nsnam/ns-3-dev/-/merge_requests/34/commits Implementation]]
+
** Tail Loss Probe (TLP) [[https://tools.ietf.org/html/draft-dukkipati-tcpm-tcp-loss-probe-01 Internet Draft]] [[https://gitlab.com/ShikhaBakshi/ns-3-dev/-/commits/TLP Implementation]]
+
** Recent Acknowledgment (RACK) [[https://tools.ietf.org/html/draft-ietf-tcpm-rack-15 Internet Draft]] [[https://gitlab.com/nsnam/ns-3-dev/-/merge_requests/34/commits Implementation]]
+
  
===== Upgrade the AQM Evaluation Suite for ns-3 =====
+
The candidate should outline in the proposal the parts of the code should be modified, and how. The repository for 6LoWPAN-ND is necessary, and the link will be shared upon request.
  
Mentors: [mailto:tahiliani.nitk@gmail.com Mohit P. Tahiliani], [mailto:bhaskar.k7920@gmail.com Bhaskar Kataria]
+
* ''Required Experience:'' Fundamentals of IPv6 addressing, C++ programming.
 +
* ''Bonus Experience:'' Familiarity with 6LoWPAN and 6LoWPAN-ND
 +
* ''Interests:'' IPv6 and IoT networks
 +
* ''Difficulty:'' Easy.
 +
* ''Patch requirement:'' [[GSOC2024PatchRequirement]]
 +
* ''Recommended reading:''
 +
** [https://datatracker.ietf.org/doc/html/rfc8505 RFC 8505]
 +
** [https://datatracker.ietf.org/doc/html/rfc6775 RFC 6775]
 +
** [https://datatracker.ietf.org/doc/html/rfc4944 RFC 4944]
  
AQM (Active Queue Management) evaluation suite for ns-3 helps to quickly study the performance of AQM algorithms based on the guidelines mentioned in RFC 7928. This suite automates simulation setup, topology creation, traffic generation, program execution, results collection and their graphical representation using ns-3 based on the scenarios mentioned in RFC 7928. It was designed and developed in 2017 and actively maintained till 2019. In the past two years, the traffic control model in ns-3 has grown significantly in terms of supporting state-of-the-art packet scheduling and AQM algorithms. This project has four main goals: (1) upgrade the AQM Evaluation Suite according to the latest ns-3-dev, (2) enable support for latest packet scheduling, AQM algorithms and ECN functionality (3) update the examples in AQM Evaluation Suite to better suit the needs of researchers working in this area, and (4) make AQM Evaluation Suite available on the ns-3 app store.
+
Possible tasks to fulfil the patch requirement:
 +
* Patch the actual 6LoWPAN-ND to remove the limitation about concurrent address registrations.
  
* ''Required Experience:'' Familiarity with AQM and C++ programming.
+
=== DHCPv6 (DHCP for IPv6) ===
* ''Bonus Experience:'' Familiarity with traffic control model in ns-3.
+
* ''Interests:'' Packet Scheduling algorithms, AQM algorithms and ECN.
+
* ''Difficulty:'' Medium.
+
* ''Recommended Reading:''
+
** AQM Evaluation Suite [[https://dl.acm.org/doi/abs/10.1145/3067665.3067674 Paper]] [[https://aqm-eval-suite.github.io/ Implementation]]
+
** [https://tools.ietf.org/html/rfc7928 RFC 7928]
+
** [https://www.nsnam.org/docs/models/html/traffic-control-layer.html Traffic Control Model in ns-3]
+
* ''Patch requirement:'' Create a pull request to handle the case when an incorrect Scenario name or number is passed via command line. Examples:
+
** ''./waf --run "aqm-eval-suite-runner --name=<unsupported scenario>"''
+
** ''./waf --run "aqm-eval-suite-runner --number=<unsupported number>"''
+
  
===== Add support for LEDBAT++ in ns-3 =====
+
Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], [TBD].
  
Mentors: [mailto:tahiliani.nitk@gmail.com Mohit P. Tahiliani]
+
DHCP is extremely important for IPv4 networks, because IPv4 lacks the address auto-configuration. Hence, DHCP is practically always used in IPv4.
 +
IPv6 does have the address auto-configuration (SLAAC), but it also does have DHCPv6. The two techniques are equally useful, and each have its pros and cons.
  
LEDBAT++ is a set of enhancements to the LEDBAT (Low Extra Delay Background Transport) congestion control algorithm for background traffic. The LEDBAT congestion control algorithm has several shortcomings that prevent it from working effectively in practice.  LEDBAT++ extends LEDBAT by adding a set of improvements, including reduced congestion window gain, modified slow-start, multiplicative decrease and periodic slowdowns. This set of improvement mitigates the known issues with the LEDBAT algorithm, such as latency drift, latecomer advantage and inter-LEDBAT fairness. This project has five main goals: (1) implement LEDBAT++ in ns-3, (2) test the working of LEDBAT++ (3) develop example program(s) to demonstrate the usage of LEDBAT++ in ns-3 (4) document the working of LEDBAT++ in ns-3 and (5) merge LEDBAT++ in the mainline of ns-3.
+
ns-3 does have a model for DHCP, but it does not have one for DHCPv6. The goal is to add this functionality.
  
* ''Required Experience:'' Familiarity with TCP, and in particular with LEDBAT
+
The candidate should outline in the proposal the approach to the implementation (e.g., new application, extension of the current DHCP model, etc.).
* ''Difficulty:'' Medium
+
 
* ''Patch requirement:'' [[GSOC2023PatchRequirement]]
+
* ''Required Experience:'' Fundamentals of IPv6 addressing, C++ programming.
 +
* ''Bonus Experience:'' Familiarity with DHCP and/or DHCPv6
 +
* ''Interests:'' IPv6
 +
* ''Difficulty:'' Easy.
 +
* ''Patch requirement:'' [[GSOC2024PatchRequirement]]
 
* ''Recommended reading:''
 
* ''Recommended reading:''
** [https://datatracker.ietf.org/doc/html/draft-irtf-iccrg-ledbat-plus-plus-01 LEDBAT++: Internet Draft]
+
** [https://datatracker.ietf.org/doc/html/rfc8415 RFC 8415]
** [https://gitlab.com/nsnam/ns-3-dev/-/blob/master/src/internet/model/tcp-ledbat.cc LEDBAT implementation in ns-3]
+
  
===== Wi-Fi examples and tutorial =====
+
Possible tasks to fulfil the patch requirement:
 +
* TBD
  
Mentor: [mailto:tomh@tomh.org Tom Henderson]
+
=== Improving 5G NR module usability ===
  
'''Note:''' This could be proposed as either a medium- or large-sized project.
+
Mentors: [mailto:bbojovic@cttc.es Biljana Bojovic],[mailto:kkoutlia@cttc.es Katerina Koutlia] and [mailto:gcarvalho@cttc.es Gabriel Ferreira]
  
The ns-3 Wi-Fi model is one of the most highly used and advanced ns-3 model, and it is currently being developed, with industry support. to model the future Wi-Fi standards including [https://www.wired.com/story/what-is-wi-fi-7/ Wi-Fi 7].  There are a large set of examples in the "examples/wireless" directory.  Some of these are duplicative and not as in sync with latest standards.  There isn't any sort of Wi-Fi specific tutorial or well-designed example program that, for instance, traces the lifecycle of a typical packet through the Wi-Fi model and channel.  This project would be to improve the usability and examples of the Wi-Fi module, and write corresponding tutorial documentation.  New helpers and trace sources will likely be introduced, and new ways to visualize the Wi-Fi model operation (visualization of output data) are also of interest.  The main output will be a Wi-Fi specific tutorial that carefully walks the reader through (new) well-designed example programs.  Programs that could be used in academic courses could also be in scope.  Providing programs to reproduce published performance results are another possibility.  Fixing open issues along the way would also be a bonus.
+
Note: This could be proposed as either a medium- or large-sized project.
  
* ''Required Experience:'' C++ programming, understanding of Wi-Fi and wireless networks
+
The ns-3 5G nr module (aka 5G-LENA) is one of the most highly used and advanced ns-3 modules for simulating the 5G NR network. This project would be focused on improving the usability and examples of the 5G nr module. The project consists of the following:  
* ''Interests:'' Wi-Fi simulations
+
* ''Difficulty:'' Medium.
+
* ''Patch requirement:'' See [https://gitlab.com/nsnam/ns-3-dev/-/issues/868 ns-3 issue 868] on supporting Buffer Occupancy metric in the wifi stack. Or else work on the [[GSOC2023PatchRequirement]]
+
* ''Background:''
+
** IEEE P802.11 TGax defined [https://www.ieee802.org/11/Reports/tgax_update.htm simulation scenarios and methodology], which can be a target (such as the residential scenario 1).
+
** MATLAB has [https://www.mathworks.com/help/wlan/ug/802-11ax-multinode-system-level-simulation-of-residential-scenario-using-matlab.html TGax residential scenario support] which can be used as a guide.
+
** check back later for more links
+
  
===== 5G NR examples and tutorial =====
+
* Improving nr helpers support: The outcome would be the implementation of new helpers and the improvement of existing ones, with the final goal of easing the usage of the 5G nr module. For example, some helpers do not have Doxygen documentation, and others require more than 30 lines of code just to specify the required 3GPP scenario. Helpers could be focused on simplifying the setup of nr scenarios, for example,  the internet, the 3GPP scenario, the XR applications, the management of the configuration of many parameters of the scenario, etc. The management of the configuration of many parameters could be simplified by moving all the common parameters to a common class that can be shared between multiple examples, then new example simulations could be much smaller and simpler. All the nr examples should be updated to make use of these new helpers.
  
Mentors: [mailto:tomh@tomh.org Tom Henderson], [mailto:bbojovic@cttc.es Biljana Bojovic], [mailto:kkoutlia@cttc.es Katerina Koutlia]
+
* A completely new example should be created that would be 3GPP compliant and ready for research purposes and collaborative research. The idea is that if a new user is interested in implementing some new MAC scheduler or PHY algorithms, can take this new example as it is and use it to run a simulation campaign for its research on a realistic 5G scenario that is according to a selected 3GPP reference scenario. We could even think of a set of different predefined 3GPP scenarios, e.g. indoor, outdoor, etc. So, the new 5G-LENA user would not have to waste his/her research time in creating a new example but could pick this example and use it as it is to test his/her algorithm. Such examples would allow collaborative research because the users could reference such examples in their publications, and compare these results with the results with other researchers' algorithms.
  
'''Note:''' This could be proposed as either a medium- or large-sized project.
+
* As a final step, to validate the correct configuration through the helpers, it would be useful to have an easy way to generate plots of indicative performance metrics, such as the throughput and/or the delay (other metrics are also welcomed). For this purpose, some plotting scripts should be added to the examples folder.  
  
Readers will note the similarity of this project idea to the previous one.  Likewise, the ns-3 5G NR model is one of the most highly used and advanced ns-3 model.  Unlike Wi-Fi, this code exists as an add-on module to ns-3 at the current time (see [https://apps.nsnam.org/app/nr/ the app store page]). However, this model is very detailed and it is quite difficult for newcomers to understand and follow something as basic as the lifecycle of a packet through the system.  This project would be to improve the usability and examples of the 5G NR module, and write corresponding tutorial documentation. New helpers and trace sources will likely be introduced, and new ways to visualize the 5G NR model operation (visualization of output data) are also of interest.  The main output will be a 5G NR specific tutorial that carefully walks the reader through (new) well-designed example programs. Programs that could be used in academic courses could also be in scope. Providing programs to reproduce published performance results are another possibility. Fixing open issues along the way would also be a bonus.
+
* Additionally, creating an “integration” example could be defined as the final part of the project, in the case of applying for a large project. The integration example is the example that demonstrates to nr users how to combine the nr module with another ns-3 module. See ns-3 Appstore here: https://apps.nsnam.org/app/tag/all/). Alternatively, integration with some external research tools could be proposed. For example, the interesting scenarios would involve the integration example that considers some of the following:
 +
** NetSimulyzer (https://apps.nsnam.org/app/netsimulyzer/),
 +
** Ns-3 gym (https://apps.nsnam.org/app/ns3-gym/)
 +
** NYSIM (https://apps.nsnam.org/app/nyusim/)
  
I would like to focus on developing one well-worked example that can be used as an entry point to performing 5G NR simulations. This example should scale to very small and very large scenarios. Users should have a clear understanding of which features are implemented and which are lacking or heavily abstracted. Users should be able to trace the lifecycle of an arbitrary packet as it traverses the system, understanding what objects it passes through and where it spends its time queued in the stack. Users should be able to easily manage the configuration of the many parameters of the scenario. Plots of performance should be easily generated.
+
For starters, we would suggest adding the CTTC 5G-LENA (nr module) to ns-3, in the typical way (as a module in the contrib/ directory), and building and running the examples. Documentation is available from here: https://5g-lena.cttc.es/. There is an overview tutorial video available here: https://acmse.net/2021/tutorials-offered/#tut-work03. That is the background information.
 +
For more specific guidelines, please view this [https://docs.google.com/document/d/1cQLIF1cdft1yj3vyWrjrxN2xDJMx8PuWaa9NP_nKf64/edit?usp=sharing Google document].
  
For starters, I would suggest to add the CTTC LENA 5G nr module to ns-3, in the typical way (as a module in the contrib/ directory) , and build and run the examples. Documentation is available from here: https://5g-lena.cttc.es/. There is an overview tutorial video available here: https://acmse.net/2021/tutorials-offered/#tut-work03. That is the background information.
+
* Required Experience: C++ programming, understanding of 5G NR, LTE, and wireless networks
 +
* Interests: 5G NR simulations
 +
* Difficulty: Medium.
 +
* Patch requirement: See the [https://www.nsnam.org/wiki/GSOC2024PatchRequirement description]. See the [https://www.nsnam.org/wiki/GSOC2024PatchRequirement description]. You can also consider some of the [https://gitlab.com/cttc-lena/nr/-/issues/?label_name%5B%5D=good%20first%20issue nr good to start issues]. Or, you can start writing some APIs for the selected project proposal. Also, if you have some previous MRs to ns-3 or the nr module, you can contact us to check whether it is enough for the patch requirement.
  
For more specific guidelines, please view [https://docs.google.com/document/d/1-xAt9c_XGcdOvDfcbr22aXM2mB-jK68zmtCIpqrDp_E/edit?usp=sharing this Google document].
+
=== Improving 5G NR module visualizations ===
  
* ''Required Experience:'' C++ programming, understanding of 5G NR, LTE, and wireless networks
+
Mentors: [mailto:gcarvalho@cttc.es Gabriel Ferreira], [mailto:bbojovic@cttc.es Biljana Bojovic] and [mailto:kkoutlia@cttc.es Katerina Koutlia]
* ''Interests:'' 5G NR simulations
+
* ''Difficulty:'' Medium.
+
* ''Patch requirement:'' See the [https://docs.google.com/document/d/1-xAt9c_XGcdOvDfcbr22aXM2mB-jK68zmtCIpqrDp_E/edit?usp=sharing Google document]
+
  
==== Large projects (350 hours) ====
+
Note: This could be proposed as either a small- or medium-sized project.
  
===== IPv6 global routing =====
+
The ns-3 5G nr module (aka 5G-LENA) is one of the most highly used and advanced ns-3 modules for simulating the 5G NR network. This project would be to improve the usability and examples of the 5G nr module by adding visualization tools to enrich the end-user experience.
 +
 
 +
The main output will be the creation or porting of one (if small) or more examples from C++ to Python and adding visualization capabilities based on existing traces. The idea is that users can then see how the visualization was generated and better understand how the metrics collection works, and how changing parameters can affect simulation results. For this, the Jupyter notebook will be used, while Python scripts will be implemented for the visualization of the results.
 +
 
 +
Examples to be implemented in Python:
 +
 
 +
* An animated version of the REM map showing gNB beams moving along with a moving UE.
 +
* Resource allocation grid comparison for different resource schedulers.
 +
 
 +
For starters, we would suggest adding the CTTC 5G-LENA (nr module) to ns-3, in the typical way (as a module in the contrib/ directory), then building and running the examples. After getting used to C++, then proceed to use the Python bindings, as described by the documentation: https://www.nsnam.org/docs/manual/html/python.html#using-the-bindings-from-the-ns-3-source.
 +
Documentation is available here: https://5g-lena.cttc.es/. There is an overview tutorial video available here: https://acmse.net/2021/tutorials-offered/#tut-work03. That is the background information. For more specific guidelines, please view this [https://docs.google.com/document/d/1cQLIF1cdft1yj3vyWrjrxN2xDJMx8PuWaa9NP_nKf64/edit?usp=sharing Google document].
 +
 
 +
* Required Experience: C++ and Python programming, understanding of 5G NR, LTE, and wireless networks
 +
* Interests: 5G NR simulations
 +
* Difficulty: Medium.
 +
* Patch requirement: See the [https://www.nsnam.org/wiki/GSOC2024PatchRequirement description]. You can also consider some of the [https://gitlab.com/cttc-lena/nr/-/issues/?label_name%5B%5D=good%20first%20issue nr good to start issues]. Or, you can start writing some APIs for the selected project proposal. Also, if you have some previous MRs to ns-3 or the nr module, you can contact us to check whether it is enough for the patch requirement.
 +
 
 +
=== 5G NR module benchmark analysis for different channel models ===
 +
 
 +
Mentors:[mailto:aashtari@cttc.es Amir Ashtari Gargari],
 +
[mailto:bbojovic@cttc.es Biljana Bojovic] and [mailto:gcarvalho@cttc.es Gabriel Ferreira]
 +
 
 +
Note: This could be proposed as either a medium- or large-sized project.
 +
The ns-3 5G nr module (aka 5G-LENA) is one of the most highly used and advanced ns-3 modules for simulating the 5G NR network. This project would be focused on improving the usability and examples of the 5G nr module.
 +
 
 +
The ns-3 nr module should be able to make use of different channel models, however, all the currently available examples in the nr module use the ns-3 3GPP channel model. This project should extend the nr module to allow the configuration of additional channel models, such as TwoRaySpectrumPropagationLoss, and NYSim, and create a benchmark example that would allow switching among different channel models. The project should consist of the following steps:
 +
 
 +
* TwoRaySpectrumPropagationLossModel was developed by Matteo Pagin during GSoC 2022: https://www.nsnam.org/wiki/GSOC2022Channel, with a main goal to provide an alternative channel model to ns-3 3GPP channel model that would be less computationally expensive and thus be a good choice for the large-scale 5G NR simulation. Matteo Pagin developed during his GSoC an NR example that uses this model, this example should be ported to the NR module. To allow the configuration of this model Matteo Pagin extended the NrHelper to allow that configuration. Such changes should be ported also to the NR module and used as an example of how to extend the NrHelper to allow the configuration of the NYSim channel model.
 +
 
 +
* Additionally, the student should investigate what are the API changes that should be done in the NR module, mainly NrHelper, to allow the usage of the NYSim channel model. As an example, see how the mmWave module makes use of both 3GPP and NYSim channel models: https://apps.nsnam.org/app/mmwave/. Also, see the NYSim module in the ns-3 App Store:https://apps.nsnam.org/app/nyusim/. See also an additional description in the [https://docs.google.com/document/d/1cQLIF1cdft1yj3vyWrjrxN2xDJMx8PuWaa9NP_nKf64/edit?usp=sharing Google document].
 +
 +
* Finally, a common benchmark scenario example that can make use of these three channel models should be created and used to perform the profiling study. An example could be the extension of Matteo's example or a completely new example. Additionally, the performance evaluation analysis of the NR should be done for the three models, and provide some insights into the assessed differences. 
 +
 
 +
* If during the performance analysis, the student detects the performance bottlenecks in the simulator that could be improved, the project could be extended to be a large-sized project.
 +
 
 +
The project proposal should contain a refactoring plan and should list what changes will be made to the NR module to support the use of the TwoRaySpectrumPropagationLossModel and NYSim channel model. The project plan should also contain some idea of what scenario will be used for the performance evaluation, which frequency, outdoor or indoor, and the number of gNBs and UEs that will be profiled. The project plan should also include a description of the performance analysis with a target performance indicative metrics. There will be benchmark metrics related to the speed of the execution of the simulator, and also the NR performance metrics such as throughput and delay. The project plan should well define the development steps that would result in the often MRs toward the nr module and ns-3 upstream during the whole duration of the project.
 +
 
 +
For starters, we would suggest adding the CTTC 5G-LENA (nr module) to ns-3, in the typical way (as a module in the contrib/ directory), and building and running the examples. Documentation is available from here: https://5g-lena.cttc.es/. There is an overview tutorial video available here: https://acmse.net/2021/tutorials-offered/#tut-work03. That is the background information.
 +
 
 +
For more specific guidelines, please view this [https://docs.google.com/document/d/1cQLIF1cdft1yj3vyWrjrxN2xDJMx8PuWaa9NP_nKf64/edit?usp=sharing Google document].
 +
*Required Experience: C++ programming, understanding of 5G NR, LTE, and wireless networks
 +
*Interests: 5G NR simulations
 +
*Difficulty: Medium-High.
 +
*Patch requirement: See the [https://www.nsnam.org/wiki/GSOC2024PatchRequirement description]. You can also consider some of the [https://gitlab.com/cttc-lena/nr/-/issues/?label_name%5B%5D=good%20first%20issue nr good to start issues]. Or, you can start writing some APIs for the selected project proposal. Also, if you have some previous MRs to ns-3 or the nr module, you can contact us to check whether it is enough for the patch requirement.
 +
 
 +
== Large projects (350 hours) ==
 +
 
 +
=== IPv6 global routing ===
  
 
Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], [TBD].
 
Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], [TBD].
Line 227: Line 310:
 
* ''Interests:'' IPv6 routing
 
* ''Interests:'' IPv6 routing
 
* ''Difficulty:'' Medium.
 
* ''Difficulty:'' Medium.
* ''Patch requirement:'' [[GSOC2023PatchRequirement]]
+
* ''Patch requirement:'' [[GSOC2024PatchRequirement]]
 
* ''Recommended reading:''
 
* ''Recommended reading:''
 
** [https://www.nsnam.org/docs/models/html/ipv6.html IPv6 model in ns-3]
 
** [https://www.nsnam.org/docs/models/html/ipv6.html IPv6 model in ns-3]
Line 235: Line 318:
 
* Add a function to print the path that a packet will use (according to Ipv4GlobalRouting), i.e., given source and destination IP print the IP addresses of the nodes that Ipv4GlobalRouting will use.
 
* Add a function to print the path that a packet will use (according to Ipv4GlobalRouting), i.e., given source and destination IP print the IP addresses of the nodes that Ipv4GlobalRouting will use.
  
===== Enable IPv6 support for Ad hoc Routing Protocols in ns-3 =====
+
=== IPv6 support in Ad hoc Routing Protocols ===
  
 
Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], [TBD].
 
Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], [TBD].
Line 249: Line 332:
 
* ''Interests:'' Ad hoc routing
 
* ''Interests:'' Ad hoc routing
 
* ''Difficulty:'' Medium.
 
* ''Difficulty:'' Medium.
* ''Patch requirement:'' [[GSOC2023PatchRequirement]]
+
* ''Patch requirement:'' [[GSOC2024PatchRequirement]]
 
* ''Recommended reading:''
 
* ''Recommended reading:''
 
** [https://www.nsnam.org/docs/models/html/ipv6.html IPv6 model in ns-3]
 
** [https://www.nsnam.org/docs/models/html/ipv6.html IPv6 model in ns-3]
Line 256: Line 339:
  
 
Possible tasks to fulfill the patch requirement:
 
Possible tasks to fulfill the patch requirement:
 
 
* [https://gitlab.com/nsnam/ns-3-dev/-/issues/271 Issue #271] - olsr header and messages are not printing either their size or their content.
 
* [https://gitlab.com/nsnam/ns-3-dev/-/issues/271 Issue #271] - olsr header and messages are not printing either their size or their content.
 
* [https://gitlab.com/nsnam/ns-3-dev/-/issues/368 Issue #368] - aodv: aodv parameters can be set to "impossible" values
 
* [https://gitlab.com/nsnam/ns-3-dev/-/issues/368 Issue #368] - aodv: aodv parameters can be set to "impossible" values
  
===== Linux-like CAKE queue discipline for ns-3 =====
+
=== Mesh Link Establishment (MLE) protocol ===
  
Mentors: [mailto:tahiliani.nitk@gmail.com Mohit P. Tahiliani], [mailto:bhaskar.k7920@gmail.com Bhaskar Kataria]
+
Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], TBD.
  
Common Applications Kept Enhanced (CAKE) is the most recent queue discipline added in Linux 4.19. It is a comprehensive queue management framework targeted for home Internet gateways, and integrates the following four components: bandwidth shaping, a new Active Queue Management (AQM) algorithm called COBALT (CoDel BLUE Alternate), handling Differentiated Services (DiffServ) and TCP ACK filtering. The main tasks in this project include: implementation, testing and documentation of individual components of CAKE in ns-3, followed by the integration of these components to form CAKE queue discipline in ns-3.
+
The Mesh Link Establishment (MLE) is a proposed IETF protocol for establishing and configuring secure radio links in IoT networks. It was originally proposed for IEEE 802.15.4, and the IETF draft seems to be not progressing.
 +
However, MLE is being used in Thread, and it can be useful to implement it.
  
* ''Required Experience:'' Familiarity with queue disciplines, TCP and C++ programming.
+
The goal of the project is to study the differences between the IETF version of MLE and the one being used in Thread, and propose an implementation that complies with either, or both.
* ''Bonus Experience:'' Familiarity with CAKE framework in Linux 4.19
+
 
* ''Interests:'' Active Queue Management, Packet scheduling and TCP.
+
* ''Required Experience:'' Fundamentals of IPv4 and IPv6 sockets, C++ programming.
* ''Difficulty:'' Medium to Hard
+
* ''Interests:'' Sockets and API interface implementation.
* ''Patch requirement:'' [[GSOC2023PatchRequirement]]
+
* ''Difficulty:'' Hard.
 
* ''Recommended reading:''
 
* ''Recommended reading:''
** [https://arxiv.org/pdf/1804.07617.pdf Piece of CAKE: A Comprehensive Queue Management Solution for Home Gateways]
+
** [https://datatracker.ietf.org/doc/html/draft-ietf-6lo-mesh-link-establishment MLE draft]
** [https://lwn.net/Articles/758353/ Let them run CAKE]
+
** [https://openthread.io/guides/thread-primer/network-discovery Thread primer]
** [https://www.nsnam.org/docs/models/html/queue-discs.html Queue disciplines in ns-3]
+
** [https://www.threadgroup.org/ThreadSpec Thread specifications]
  
===== MinstrelHt improvements =====
+
Possible tasks to fulfill the patch requirement:
 +
* [[GSOC2024PatchRequirement]]
  
Mentor: [mailto:tomh@tomh.org Tom Henderson]
+
=== Lr-WPAN (IEEE 802.15.4) preamble detection support ===
  
[https://lwn.net/Articles/376765/ Minstrel-HT] is a rate adaptation algorithm for Wi-Fi devices that has been added to the Linux kernel and is in wide use.  ns-3 has a [https://www.nsnam.org/docs/release/3.37/models/html/wifi-design.html#minstrelwifimanager model] of MinstrelHt, contributed to the project about 10 years ago.  Since that time, MinstrelHt has evolved in the Linux kernel, while ns-3's Minstrel has stayed mostly the same.  Furthermore, as the above link highlights, there are limited tests and documentation.  We are seeking a student interested in upgrading, testing, and documenting ns-3's MinstrelHt to bring it into alignment with modern Linux kernels.  For a summary of some of the technical issues, please see this [https://gitlab.com/nsnam/ns-3-dev/-/issues/281 ns-3 tracker issue].  Time permitting, some research extensions/features could be considered to be added, such as [https://ieeexplore.ieee.org/document/8548800 Minstrel-CDHT], dynamic use of short guard interval, or [https://ieeexplore.ieee.org/abstract/document/6289295 Minstrel-Piano].
+
Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], [mailto:alramonet@is.tokushima-u.ac.jp Alberto Gallegos Ramonet].
  
* ''Required Experience:'' Familiarity with how Wi-Fi works, and with C++ programming.
+
A preamble is a series of defined bits that signal the data transmission between two or more devices. The current Lr-WPAN module takes into consideration the preamble transmission time but
* ''Interests:'' Wi-Fi, adaptive algorithms.
+
it does not support preamble detection (hence there is no chance of detection failure). Implementing preamble detection would have the added benefit of adding RSSI support to the Lr-WPAN module which
* ''Difficulty:'' Medium
+
itself has many added benefits.
* ''Patch requirement:'' See [https://gitlab.com/nsnam/ns-3-dev/-/issues/868 ns-3 issue 868] on supporting Buffer Occupancy metric in the wifi stack.  Or else work on the [[GSOC2023PatchRequirement]]
+
* ''Recommended reading:''
+
** [https://theses.hal.science/INSA-LYON-THESES/tel-03126953v1 Remy Grunblatt's thesis (especially chapter 5)]
+
* ''Getting started:''
+
** Is [https://gitlab.com/nsnam/ns-3-dev/-/issues/51 this bug] still an issue with our implementation?
+
  
===== ns3-ai improvements =====
+
This project touches on some core PHY functions of the Lr-WPAN module (the detection of packets). Unlike similar ns-3 modules, Lr-WPAN is relatively simple, therefore, it is a good opportunity to learn about Lr-WPAN and how PHYs are handled in ns-3.
  
Mentors: [mailto:haoyin@uw.edu Hao Yin], [mailto:collinbrady1993@gmail.com Collin Brady]
+
As usual, reduction of code duplicity and a flexible scalable design is desired (e.g. Allow the inclusion of different preambles in the future).
  
[https://apps.nsnam.org/app/ns3-ai/ ns3-ai] is an extension for ns-3 that provides fast and flexible interfaces between ns-3 and Python based open-source frameworks such as TensorFlow and PyTorch using shared memory. However, with large-scale networks, some research problems like resource allocation may require frequent interactions between ns-3 and Python, which can lead to 10x time increases in the simulation time.  This proposed project is oriented around performance benchmarking and further optimizing the ns3-ai model and providing more documents and examples.
+
* ''Required Experience:'' Basic understanding of IEEE 802.15.4, C++ programming.
 
+
* ''Bonus Experience:'' PHY process familiarity, Familiarity with ns-3's Lr-WPAN
The project goals are:
+
* ''Interests:'' Lr-WPAN, MAC and PHY designs
# Improvements over the current ns3-ai model to reduce the interaction between C++ and Python: Support more data structures with shared memory like Vector and String.
+
* ''Difficulty:'' Medium.
# Provide examples of using C++ to implement the ML algorithms within ns-3: Compile with the open-source frameworks like TensorFlow and PyTorch in C++ and implement example algorithms like DQN.
+
* ''Patch requirement:'' [[GSOC2024PatchRequirement]]
# Improve the current examples and documentations and integrate new examples like LTE-handover.
+
 
+
* ''Required Experience:'' Familiarity with Python and C++ programming.
+
* ''Bonus Experience:'' Familiarity with Inter Process Communication (IPC, e.g., shared memory) and ML algorithms in communication.
+
* ''Interests:'' ML in wireless communication, IPC programming.
+
* ''Difficulty:'' Medium
+
* ''Patch requirement:'' [[GSOC2023PatchRequirement]]
+
 
* ''Recommended reading:''
 
* ''Recommended reading:''
** The ns3-ai model: [https://dl.acm.org/doi/10.1145/3389400.3389404 Paper], [https://github.com/hust-diangroup/ns3-ai Code]
+
** [https://ieeexplore.ieee.org/document/1700009 IEEE 802.15.4-2006]
** Shared memory blogs: '[https://yyc.solvcon.net/en/latest/writing/2016/resource/index.html Python_C++], [https://www.tutorialspoint.com/inter_process_communication/inter_process_communication_shared_memory.htm IPC shared memory]
+
** [https://ieeexplore.ieee.org/document/7460875 IEEE 802.15.4-2015]
** AI frameworks with C++: [https://pytorch.org/tutorials/advanced/cpp_frontend.html PyTorch], [https://www.tensorflow.org/api_docs/cc TensorFlow]
+
** [https://www.nsnam.org/docs/models/html/lr-wpan.html ns-3 lr-wpan module]
  
===== L4S tests and examples =====
+
Possible tasks to fulfill the patch requirement:
 
+
* [[GSOC2024PatchRequirement]]
Mentor: [mailto:tomh@tomh.org Tom Henderson]
+
 
+
Quoting Jason Livingood recently on the IETF tsvwg mailing list:  "The TSVWG recently finished RFC 9330, 9331, and 9332, related to Low Latency, Low Loss, Scalable Throughput (L4S). As network operators, operating system developers, application developers, and researchers work together to operationalize, test, and measure L4S experiments, this list will serve as a forum for detailed discussions and sharing of experiences. "  Jason was referring to [https://www.ietf.org/mailman/listinfo/l4s-discuss a new mailing list] formation.
+
 
+
In 2020, ns-3 had a GSoC project on [https://deepakkavoor.github.io/gsoc-2020-prague/ TCP Prague], but the code has not yet been merged, mainly due to lack of completion of tests.  Now that the IETF has approved of the L4S RFCs, it would be helpful for ns-3 to have a working model of an L4S-aware TCP.  This project would update TCP Prague to the latest Linux code and ensure that the L4S support in our queue models is working correctly, and work to merge TCP Prague to the  ns-3 mainline.  Then, the project would focus on examples and validations that mirror some of the tests that were conducted in the tsvwg working group and published academic papers on TCP Prague and L4S.
+
 
+
* ''Required Experience:"" Some familiarity with how TCP and AQM work.
+
* ''Bonus Experience:** Understanding of Linux code for TCP and AQM.
+
* ''Interests:'' New congestion control algorithms, IETF standards
+
* ''Difficulty:'' Medium
+
* ''Patch requirement:'' [[GSOC2023PatchRequirement]]
+
* ''Recommended reading:'' [https://datatracker.ietf.org/doc/rfc9330/ RFC 9330], [https://arxiv.org/pdf/2209.01078.pdf paper on dual queue]
+

Latest revision as of 12:42, 19 March 2024

Main Page - Current Development - Developer FAQ - Tools - Related Projects - Project Ideas - Summer Projects

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

This page contains 2024 Google Summer of Code project ideas for ns-3.

About the ns-3 project

ns-3 is a discrete-event network simulator, with a particular emphasis on network research and education.

Users of ns-3 can construct simulations of computer networks using models of traffic generators, protocols such as TCP/IP, and devices and channels such as WiFi, and analyze or visualize the results. Simulation plays a vital role in the research and education process, because of the ability for simulations to obtain reproducible results (particularly for wireless protocol design), scale to large networks, and study systems that have not yet been implemented. A particular emphasis in ns-3 is the high degree of realism in the models (including frameworks for real application and kernel code) and integration of the tool with virtual machine environments and testbeds; we view that researchers need to move more effortlessly between simulation, testbeds, and live experiments, and ns-3 is designed to facilitate that.

ns-3 has participated in past GSoCs during 2008-10, 2012-15, and 2017-23. We seek contributors interested in the intersection of wireless and computer networking, performance analysis, and open source software.

Org admins

Google Summer of Code organizational admins for ns-3 are Tommaso Pecorella, Mohit P. Tahiliani, and Tom Henderson; contact them with any questions. They also hang out on Zulip.

Mentors

Mentors will be paired with contributors based on the projects that are selected. Mentors from companies are welcome, if the employer will permit the mentor sufficient time to perform the mentoring. Prospective mentors should notify Mohit P. Tahiliani or Tommaso Pecorella of interest. Mentors familiar with ns-3 development practices will be preferred, to improve the chances of code merge. We are going to be seeking two-person or multiple-person mentoring teams for projects, to help with the mentoring workload and bring more expertise.

The current list of prospective mentors can be found among the ideas listed below.

How to apply

For students or contributors interested in applying to ns-3 for GSoC, please go through the following list to get started:

  • Read the official GSoC contributor guide.
  • Read ns-3's GSoC contributor guide
  • Look through our #Project Ideas below to see if you find a project that interests you.
  • Review the tutorial and contributing guide thoroughly, if you have not already done so.
  • Once it is posted, look through the GSoC application template to start preparing your proposal. We will wait to see whether we are actually part of GSoC before updating the above link for 2024, but it will be similar to last year's application.
  • Next, proceed to get in touch with the developers on the mailing list or Zulip chat room and refine your proposal.
  • In parallel, make sure you prepare a patch as per the patch requirement guidelines. Your application to ns-3 will not be considered if you do not fulfill this requirement.

Below is a list of #Project Ideas proposed by the ns-3 team for Google Summer of Code 2024. Please note that these ideas are not limited to GSoC; anyone is welcome to work on them. Please email the ns-developers list if you have a different idea that you'd like to work on, to see if a mentor may be interested. Applicants are encouraged to look over this list, pick one that especially interests them, think about it, and discuss potential approaches on the ns-developers list. Previous experience with the Google Summer of Code programs suggest that the more you discuss and refine your proposal on the mailing list beforehand, the stronger the proposal it will develop into, and the higher your chances of being accepted into the program.

Each project idea within a particular priority has been tagged with the following properties:

  • Required Experience: Languages, concepts, or packages with which applicants must be familiar.
  • Bonus Experience: Other experience or familiarity which would be greatly helpful to applicants for this project.
  • Interests: Areas of particular relevance to this project, and an indicator of where successful contributors might apply their experiences coming out of this project.
  • Difficulty: easy, medium or difficult
  • Recommended reading: pointers to documentation, papers, specific bugs, etc.

Note that all of the projects require some experience and comfort with C++. Project ideas for which C++ is noted as a required experience will require more and deeper familiarity with the language. A similar notion applies to computer networking, BSD sockets, etc: Familiarity is strongly preferred, but is not required except where explicitly noted due to the topic being more advanced in that regard. A few projects are more Python-centric.

Patch requirement guidelines

Each project idea has either a suggested task, or a link to a generic task, that a contributor must do to demonstrate some ability to carry out a GSoC project successfully. Performing one task is necessary for a successful application, and performing more than one task is not necessary.

Contributors that already contributed to the ns-3 codebase with non-trivial bug fixing or features additions might be exempted from performing a task. If you have doubts about if your contributions made you eligible for the task exemption contact the mentors.

Mentors: how to participate

The ns-3 project is open to the proposal of new project ideas by developers interested in being a GSoC mentor. For mentors who're adding project ideas to the list below, please ensure that:

  • The projects are sized such that there can be a code merge by the end of the coding period. The scope of the project should be such that it is very difficult to *not* have a code merge by the end of the summer.
  • The proposed projects are not too open-ended. That is, if the deliverables or a clear path to the same are not well understood, it is better kept outside GSOC.
  • There should be a clear merge path to one of the main project code repositories (ns-3-dev, ns-3-dce, bake) by the end of the summer, either because the patches directly apply to these repositories, or because they apply to an ns-3 module that is in the process of being merged with ns-3-dev.

Project Ideas

Note to contributors: These ideas are not listed in any priority order. The projects can be grouped depending on their scope and/or their size. Below they are organized according to their scope. Please check each idea for details about its foreseen difficulty level.

Internet models enhancements

IoT models enhancements

5G NR models enhancements

Small sized projects (90 hours)

Improving 5G NR module visualizations

Mentors: Gabriel Ferreira, Biljana Bojovic and Katerina Koutlia

Note: This could be proposed as either a small- or medium-sized project.

The ns-3 5G nr module (aka 5G-LENA) is one of the most highly used and advanced ns-3 modules for simulating the 5G NR network. This project would be to improve the usability and examples of the 5G nr module by adding visualization tools to enrich the end-user experience.

The main output will be the creation or porting of one (if small) or more examples from C++ to Python and adding visualization capabilities based on existing traces. The idea is that users can then see how the visualization was generated and better understand how the metrics collection works, and how changing parameters can affect simulation results. For this, the Jupyter notebook will be used, while Python scripts will be implemented for the visualization of the results.

Examples to be implemented in Python:

  • An animated version of the REM map showing gNB beams moving along with a moving UE.
  • Resource allocation grid comparison for different resource schedulers.

For starters, we would suggest adding the CTTC 5G-LENA (nr module) to ns-3, in the typical way (as a module in the contrib/ directory), then building and running the examples. After getting used to C++, then proceed to use the Python bindings, as described by the documentation: https://www.nsnam.org/docs/manual/html/python.html#using-the-bindings-from-the-ns-3-source. Documentation is available here: https://5g-lena.cttc.es/. There is an overview tutorial video available here: https://acmse.net/2021/tutorials-offered/#tut-work03. That is the background information. For more specific guidelines, please view this Google document.

  • Required Experience: C++ and Python programming, understanding of 5G NR, LTE, and wireless networks
  • Interests: 5G NR simulations
  • Difficulty: Medium.
  • Patch requirement: See the description. You can also consider some of the nr good to start issues. Or, you can start writing some APIs for the selected project proposal. Also, if you have some previous MRs to ns-3 or the nr module, you can contact us to check whether it is enough for the patch requirement.

Medium sized projects (175 hours)

ICMP socket and generate/handle ICMP messages (host/net unreachable)

Mentors: Tommaso Pecorella, Manoj K. Rana.

The current IP stack in ns-3 does not provide an ICMP socket, and in order to send or receive ICMP packets (either IPV4 or IPv6) it is necessary to use a "RAW" socket. This approach works, but has a severe limitation: it does not work if the packet has been fragmented. Moreover, using a RAW socket is far more complex than a normal socket, as the receiver application must filter the incoming packets according to specific rules.

The goal of the idea is to create, test, and document an ICMP socket that works both for IPv4 and IPv6, mimicking the Linux sockets socket(AF_INET, SOCK_DGRAM, IPPROTO_ICMP) and socket(AF_INET6, SOCK_DGRAM, IPPROTO_ICMPV6). Note that the choice of SOCK_DGRAM or SOCK_RAW (i.e., with or without the IP header) is totally left to the proposal.

The most important point of the implementation should be code duplicate minimization, in order to have the minimize maintenance efforts.

Once the sockets are in place, beside the "normal" tests, it will be necessary to modify the code that is actually made obsolete by the new sockets, e.g.:

  • IPv6 ICMP messages (RA, RS, NA, NS, etc.),
  • IPv4 ICMP messages,
  • ICMP Echo and ICMPv6 Echo messages.

and to handle properly ICMP error messages like Destination Unreachable in the Ping application.

Possible tasks to fulfill the patch requirement:

6LoWPAN mesh-under routing enhancements

Mentors: Tommaso Pecorella, [TBD].

The 6LoWPAN module offers a simple option to implement a multi-hop topology by using a contolled flooding. However, the implemented controlled flooding is very simple, and is not efficient in complex networks. This is mainly due to the lack of congestion control, or rather its naive implementation. A better approach would be to borrow some concepts and ideas from RFC 7731 Multicast Protocol for Low-Power and Lossy Networks (MPL), so that messages do not generate network congestions when the network is large.

The candidate should outline what parts of code are going to be affected, and how they can be enhanced thanks to RFC 7731.

Possible tasks to fulfill the patch requirement:

  • TBD

6LoWPAN neighbor discovery protocol

Mentors: Tommaso Pecorella, [TBD].

The 6LoWPAN-ND (RFCs 4944, 6775, and 8505) is a replacement for IPv6 DAD and NDP for 6LoWPAN networks, and it is important to ensure address uniquness across a network that can potentially use different MAC/PHY layers.

There is a model for 6LoWPAN-ND, but it still not merged in the main ns-3 branch. The goal is to cleanup the implementation, remove an actual limitation due to a questionble assumption, and to add the support for multi-hop operations (EDAR and EDAC messages).

The candidate should outline in the proposal the parts of the code should be modified, and how. The repository for 6LoWPAN-ND is necessary, and the link will be shared upon request.

  • Required Experience: Fundamentals of IPv6 addressing, C++ programming.
  • Bonus Experience: Familiarity with 6LoWPAN and 6LoWPAN-ND
  • Interests: IPv6 and IoT networks
  • Difficulty: Easy.
  • Patch requirement: GSOC2024PatchRequirement
  • Recommended reading:

Possible tasks to fulfil the patch requirement:

  • Patch the actual 6LoWPAN-ND to remove the limitation about concurrent address registrations.

DHCPv6 (DHCP for IPv6)

Mentors: Tommaso Pecorella, [TBD].

DHCP is extremely important for IPv4 networks, because IPv4 lacks the address auto-configuration. Hence, DHCP is practically always used in IPv4. IPv6 does have the address auto-configuration (SLAAC), but it also does have DHCPv6. The two techniques are equally useful, and each have its pros and cons.

ns-3 does have a model for DHCP, but it does not have one for DHCPv6. The goal is to add this functionality.

The candidate should outline in the proposal the approach to the implementation (e.g., new application, extension of the current DHCP model, etc.).

  • Required Experience: Fundamentals of IPv6 addressing, C++ programming.
  • Bonus Experience: Familiarity with DHCP and/or DHCPv6
  • Interests: IPv6
  • Difficulty: Easy.
  • Patch requirement: GSOC2024PatchRequirement
  • Recommended reading:

Possible tasks to fulfil the patch requirement:

  • TBD

Improving 5G NR module usability

Mentors: Biljana Bojovic,Katerina Koutlia and Gabriel Ferreira

Note: This could be proposed as either a medium- or large-sized project.

The ns-3 5G nr module (aka 5G-LENA) is one of the most highly used and advanced ns-3 modules for simulating the 5G NR network. This project would be focused on improving the usability and examples of the 5G nr module. The project consists of the following:

  • Improving nr helpers support: The outcome would be the implementation of new helpers and the improvement of existing ones, with the final goal of easing the usage of the 5G nr module. For example, some helpers do not have Doxygen documentation, and others require more than 30 lines of code just to specify the required 3GPP scenario. Helpers could be focused on simplifying the setup of nr scenarios, for example, the internet, the 3GPP scenario, the XR applications, the management of the configuration of many parameters of the scenario, etc. The management of the configuration of many parameters could be simplified by moving all the common parameters to a common class that can be shared between multiple examples, then new example simulations could be much smaller and simpler. All the nr examples should be updated to make use of these new helpers.
  • A completely new example should be created that would be 3GPP compliant and ready for research purposes and collaborative research. The idea is that if a new user is interested in implementing some new MAC scheduler or PHY algorithms, can take this new example as it is and use it to run a simulation campaign for its research on a realistic 5G scenario that is according to a selected 3GPP reference scenario. We could even think of a set of different predefined 3GPP scenarios, e.g. indoor, outdoor, etc. So, the new 5G-LENA user would not have to waste his/her research time in creating a new example but could pick this example and use it as it is to test his/her algorithm. Such examples would allow collaborative research because the users could reference such examples in their publications, and compare these results with the results with other researchers' algorithms.
  • As a final step, to validate the correct configuration through the helpers, it would be useful to have an easy way to generate plots of indicative performance metrics, such as the throughput and/or the delay (other metrics are also welcomed). For this purpose, some plotting scripts should be added to the examples folder.

For starters, we would suggest adding the CTTC 5G-LENA (nr module) to ns-3, in the typical way (as a module in the contrib/ directory), and building and running the examples. Documentation is available from here: https://5g-lena.cttc.es/. There is an overview tutorial video available here: https://acmse.net/2021/tutorials-offered/#tut-work03. That is the background information. For more specific guidelines, please view this Google document.

  • Required Experience: C++ programming, understanding of 5G NR, LTE, and wireless networks
  • Interests: 5G NR simulations
  • Difficulty: Medium.
  • Patch requirement: See the description. See the description. You can also consider some of the nr good to start issues. Or, you can start writing some APIs for the selected project proposal. Also, if you have some previous MRs to ns-3 or the nr module, you can contact us to check whether it is enough for the patch requirement.

Improving 5G NR module visualizations

Mentors: Gabriel Ferreira, Biljana Bojovic and Katerina Koutlia

Note: This could be proposed as either a small- or medium-sized project.

The ns-3 5G nr module (aka 5G-LENA) is one of the most highly used and advanced ns-3 modules for simulating the 5G NR network. This project would be to improve the usability and examples of the 5G nr module by adding visualization tools to enrich the end-user experience.

The main output will be the creation or porting of one (if small) or more examples from C++ to Python and adding visualization capabilities based on existing traces. The idea is that users can then see how the visualization was generated and better understand how the metrics collection works, and how changing parameters can affect simulation results. For this, the Jupyter notebook will be used, while Python scripts will be implemented for the visualization of the results.

Examples to be implemented in Python:

  • An animated version of the REM map showing gNB beams moving along with a moving UE.
  • Resource allocation grid comparison for different resource schedulers.

For starters, we would suggest adding the CTTC 5G-LENA (nr module) to ns-3, in the typical way (as a module in the contrib/ directory), then building and running the examples. After getting used to C++, then proceed to use the Python bindings, as described by the documentation: https://www.nsnam.org/docs/manual/html/python.html#using-the-bindings-from-the-ns-3-source. Documentation is available here: https://5g-lena.cttc.es/. There is an overview tutorial video available here: https://acmse.net/2021/tutorials-offered/#tut-work03. That is the background information. For more specific guidelines, please view this Google document.

  • Required Experience: C++ and Python programming, understanding of 5G NR, LTE, and wireless networks
  • Interests: 5G NR simulations
  • Difficulty: Medium.
  • Patch requirement: See the description. You can also consider some of the nr good to start issues. Or, you can start writing some APIs for the selected project proposal. Also, if you have some previous MRs to ns-3 or the nr module, you can contact us to check whether it is enough for the patch requirement.

5G NR module benchmark analysis for different channel models

Mentors:Amir Ashtari Gargari, Biljana Bojovic and Gabriel Ferreira

Note: This could be proposed as either a medium- or large-sized project. The ns-3 5G nr module (aka 5G-LENA) is one of the most highly used and advanced ns-3 modules for simulating the 5G NR network. This project would be focused on improving the usability and examples of the 5G nr module.

The ns-3 nr module should be able to make use of different channel models, however, all the currently available examples in the nr module use the ns-3 3GPP channel model. This project should extend the nr module to allow the configuration of additional channel models, such as TwoRaySpectrumPropagationLoss, and NYSim, and create a benchmark example that would allow switching among different channel models. The project should consist of the following steps:

  • TwoRaySpectrumPropagationLossModel was developed by Matteo Pagin during GSoC 2022: https://www.nsnam.org/wiki/GSOC2022Channel, with a main goal to provide an alternative channel model to ns-3 3GPP channel model that would be less computationally expensive and thus be a good choice for the large-scale 5G NR simulation. Matteo Pagin developed during his GSoC an NR example that uses this model, this example should be ported to the NR module. To allow the configuration of this model Matteo Pagin extended the NrHelper to allow that configuration. Such changes should be ported also to the NR module and used as an example of how to extend the NrHelper to allow the configuration of the NYSim channel model.
  • Additionally, the student should investigate what are the API changes that should be done in the NR module, mainly NrHelper, to allow the usage of the NYSim channel model. As an example, see how the mmWave module makes use of both 3GPP and NYSim channel models: https://apps.nsnam.org/app/mmwave/. Also, see the NYSim module in the ns-3 App Store:https://apps.nsnam.org/app/nyusim/. See also an additional description in the Google document.
  • Finally, a common benchmark scenario example that can make use of these three channel models should be created and used to perform the profiling study. An example could be the extension of Matteo's example or a completely new example. Additionally, the performance evaluation analysis of the NR should be done for the three models, and provide some insights into the assessed differences.
  • If during the performance analysis, the student detects the performance bottlenecks in the simulator that could be improved, the project could be extended to be a large-sized project.

The project proposal should contain a refactoring plan and should list what changes will be made to the NR module to support the use of the TwoRaySpectrumPropagationLossModel and NYSim channel model. The project plan should also contain some idea of what scenario will be used for the performance evaluation, which frequency, outdoor or indoor, and the number of gNBs and UEs that will be profiled. The project plan should also include a description of the performance analysis with a target performance indicative metrics. There will be benchmark metrics related to the speed of the execution of the simulator, and also the NR performance metrics such as throughput and delay. The project plan should well define the development steps that would result in the often MRs toward the nr module and ns-3 upstream during the whole duration of the project.

For starters, we would suggest adding the CTTC 5G-LENA (nr module) to ns-3, in the typical way (as a module in the contrib/ directory), and building and running the examples. Documentation is available from here: https://5g-lena.cttc.es/. There is an overview tutorial video available here: https://acmse.net/2021/tutorials-offered/#tut-work03. That is the background information.

For more specific guidelines, please view this Google document.

  • Required Experience: C++ programming, understanding of 5G NR, LTE, and wireless networks
  • Interests: 5G NR simulations
  • Difficulty: Medium-High.
  • Patch requirement: See the description. You can also consider some of the nr good to start issues. Or, you can start writing some APIs for the selected project proposal. Also, if you have some previous MRs to ns-3 or the nr module, you can contact us to check whether it is enough for the patch requirement.

Large projects (350 hours)

IPv6 global routing

Mentors: Tommaso Pecorella, [TBD].

Creating a complex topology can be a problem, and sometimes the user do not want to be (also) concerned about setting up dynamic routing protocols (e.g., RIP, RIPng). For IPv4, ns-3 provides two alternatives: GlobalRouting, and NixRouting, which just "do the trick" - they simply fill the routing tables in intermediate nodes, GlobalRouting using an approach similar to OSPF, NixRouting by leveraging the "abstract" knowledge of the network. Neither actually use any message between the nodes, so they also reduce the network overhead - something that is useful in many cases.

The problem is that GlobalRouting don't work for IPv6 (NixRouting was migrated to IPv6 recently), and that's a huge limitation. The goal of the project is to fix that limitation. Note that the project must cope with different IPv6 address kinds (link-local, global, scoped multicast, etc.).

The most important point of the implementation should be code duplicate minimization, in order to have the minimize maintenance efforts. The proposer is advised to check the approach used for NixRouting, as it might be a starting point.

Possible tasks to fulfill the patch requirement:

  • Add a function to print the path that a packet will use (according to Ipv4GlobalRouting), i.e., given source and destination IP print the IP addresses of the nodes that Ipv4GlobalRouting will use.

IPv6 support in Ad hoc Routing Protocols

Mentors: Tommaso Pecorella, [TBD].

ns-3 contains models for proactive (DSDV and OLSR) and reactive (AODV and DSR) ad hoc routing protocols. However, these models are IPv4-only and do not provide support of IPv6 addressing. This project aims to enable IPv6 support for ad hoc routing protocols in ns-3, mainly for AODV. There are out-of-tree implementations of OLSR and DSDV that provide support for IPv6 addressing, and can be used as references to get started with this project.

The most important point of the implementation should be code duplicate minimization, in order to have the minimize maintenance efforts.

Note: Enabling IPv6 support for these protocols is not a matter of simply changing out an IPv4-formatted address for an IPv6-formatted address. The IPv6 addressing architecture emphasizes scoping much more than does IPv4 (RFC 4007). Please suggest in your application how IPv6 address configuration (and possibly auto-configuration?) and address scopes (e.g. link-local vs. global) should be used in these protocols. Consulting the RFCs is highly recommended.

Possible tasks to fulfill the patch requirement:

  • Issue #271 - olsr header and messages are not printing either their size or their content.
  • Issue #368 - aodv: aodv parameters can be set to "impossible" values

Mesh Link Establishment (MLE) protocol

Mentors: Tommaso Pecorella, TBD.

The Mesh Link Establishment (MLE) is a proposed IETF protocol for establishing and configuring secure radio links in IoT networks. It was originally proposed for IEEE 802.15.4, and the IETF draft seems to be not progressing. However, MLE is being used in Thread, and it can be useful to implement it.

The goal of the project is to study the differences between the IETF version of MLE and the one being used in Thread, and propose an implementation that complies with either, or both.

  • Required Experience: Fundamentals of IPv4 and IPv6 sockets, C++ programming.
  • Interests: Sockets and API interface implementation.
  • Difficulty: Hard.
  • Recommended reading:

Possible tasks to fulfill the patch requirement:

Lr-WPAN (IEEE 802.15.4) preamble detection support

Mentors: Tommaso Pecorella, Alberto Gallegos Ramonet.

A preamble is a series of defined bits that signal the data transmission between two or more devices. The current Lr-WPAN module takes into consideration the preamble transmission time but it does not support preamble detection (hence there is no chance of detection failure). Implementing preamble detection would have the added benefit of adding RSSI support to the Lr-WPAN module which itself has many added benefits.

This project touches on some core PHY functions of the Lr-WPAN module (the detection of packets). Unlike similar ns-3 modules, Lr-WPAN is relatively simple, therefore, it is a good opportunity to learn about Lr-WPAN and how PHYs are handled in ns-3.

As usual, reduction of code duplicity and a flexible scalable design is desired (e.g. Allow the inclusion of different preambles in the future).

Possible tasks to fulfill the patch requirement: