GSOC2024Projects
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.
- GSoC Frequently Asked Questions
- ns-3's 2024 GSoC Contributor guide
- GSoC contributor/student guide (not ns-3 specific)
- 2024 GSoC Contributor application template
- ns-3's GSoC Mentor guide
- GSoC Mentor guide (not ns-3 specific)
- GSoC Contributor Selection Process
- Get in contact with the ns-3 team: ns-developers mailing list | chat https://ns-3.zulipchat.com/
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
- #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: 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.
- Required Experience: Fundamentals of IPv4 and IPv6 sockets, C++ programming.
- Interests: Sockets and API interface implementation.
- Difficulty: Medium.
- Recommended reading:
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.
- Required Experience: Fundamentals of IPv6 addressing, C++ programming.
- Bonus Experience: Familiarity with mesh routing and 6LoWPAN ns-3
- Interests: IPv6 mesh routing
- Difficulty: Easy.
- Patch requirement: GSOC2024PatchRequirement
- Recommended reading:
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.
- 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/)
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.
- Required Experience: Fundamentals of IPv6 addressing, C++ programming.
- Bonus Experience: Familiarity with GlobalRouting implementations in ns-3
- Interests: IPv6 routing
- Difficulty: Medium.
- Patch requirement: GSOC2024PatchRequirement
- Recommended reading:
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.
- Required Experience: Fundamentals of IPv6 addressing, C++ programming.
- Bonus Experience: Familiarity with AODV implementations in ns-3
- Interests: Ad hoc routing
- Difficulty: Medium.
- Patch requirement: GSOC2024PatchRequirement
- Recommended reading:
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).
- Required Experience: Basic understanding of IEEE 802.15.4, C++ programming.
- Bonus Experience: PHY process familiarity, Familiarity with ns-3's Lr-WPAN
- Interests: Lr-WPAN, MAC and PHY designs
- Difficulty: Medium.
- Patch requirement: GSOC2024PatchRequirement
- Recommended reading:
Possible tasks to fulfill the patch requirement: