Nsnam - User contributions [en]

GSOC2026Projects

2026-03-24T23:45:05Z

Biljana: /* 5G NR module integration with ns-3-ai */

{{TOC}}

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

* [https://developers.google.com/open-source/gsoc/faq GSoC Frequently Asked Questions]
* [[GSOC2026ContributorGuide | ns-3's 2026 GSoC Contributor guide]]
* [https://developers.google.com/open-source/gsoc/resources/guide GSoC contributor/student guide (not ns-3 specific)]
* [[GSOC2025ApplicationTemplate | 2026 GSoC Contributor application template]]
* [[GSOCMentorGuide | ns-3's GSoC Mentor guide]]
* [https://archive.flossmanuals.net/gsocmentoring/index.html GSoC Mentor guide (not ns-3 specific)]
* [[GSOCSelectionProcess | GSoC Contributor Selection Process]]
* ''Get in contact with the ns-3 team'': [https://groups.google.com/g/ns-developers 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-25. 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 [mailto:tpecorella@mac.com Tommaso Pecorella] and [mailto:tahiliani.nitk@gmail.com Mohit P. Tahiliani]; contact them with any questions. They also hang out on [https://ns-3.zulipchat.com 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 [https://developers.google.com/open-source/gsoc/resources/guide GSoC contributor guide].
* Read [[GSOC2026ContributorGuide |ns-3's 2026 GSoC contributor guide]]
* 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.
* Once it is posted, look through the [[GSOC2024ApplicationTemplate |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 2026, 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 2026. 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 suggests 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>
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.
</blockquote>

=== Patch requirement guidelines ===

In past years, we have asked applicants to submit a patch related to an open issue or a suggested coding exercise. We are undecided at this time whether we will ask for this in 2026; check back later.

=== 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 ===

* [[#Flent Application API in ns-3]] (small size project, 90h)
* [[#Ping and TraverouteV4 enhancements]] (small size project, 90h)
* [[#Internet routing refactory]] (small size project, 90h)
* [[#AODVv2 Protocol enhancements]] (medium size project, 175h)
* [[#Linux-like CAKE queue discipline for ns-3]] (large size project, 350h)
* [[#Switched Ethernet]] (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)

=== 5G NR models enhancements ===

The general idea is to improve the usability of the 5G NR module by adding new examples that help users start building scenario scripts. Also, an interesting improvement could be integration with other modules, like those for AI or visualizations. Here are some project ideas. Depending on the contributor's interest and skills we can adjust these projects' definitions.

* [[#OLLA Link Adaptation and Spec-Compliant TBS Calculation for 5G-LENA]] (medium size project, 175h)
* [[#Enabling 5G NR examples visualization]] (medium size project, 175h)
* [[#Energy Consumption Modeling and Power-Aware Extensions for 5G-LENA]] (large size project, 250h)
* [[#5G NR module integration with ns-3-ai]] (large size project, 250h)
* [[#Integration of 3GPP Release-19 Features into the ns-3 3GPP Model and 5G-LENA]] (medium size project, 175h)
* [[#Multi-Band Support and Carrier Selection in 5G-LENA for FR3 CA]] (medium size project, 175h)
* [[#Spectrum Sharing Support for 5G-LENA and ns-3]] (medium size project, 175h)

== Small sized projects (90 hours) ==

=== Flent Application API in ns-3 ===

Mentors: [mailto:tahiliani.nitk@gmail.com Mohit P. Tahiliani]

Flexible Network Tester (Flent) is a network benchmarking tool. It is written in Python and wraps well-known network benchmarking tools (such as netperf and iperf) into aggregate, repeatable tests, such as a number of tests for Bufferbloat. A basic structure for Flent Application API in ns-3 has been developed. It is a wrapper around existing ns-3 applications. This project has four main goals: (1) update this implementation to match the current ns-3-dev, (2) integrate a JSON library properly (for Flent-style result handling) (3) validate correctness of Flent results produced by ns-3, and (4) Add more Flent-style test examples useful for ns-3 users. The goal of this project is to merge the Flent Application API into ns-3 mainline, not the app store.

* ''Required Experience:'' Familiarity with Flent and C++ programming.
* ''Bonus Experience:'' Familiarity with applications supported in ns-3.
* ''Interests:'' Bufferbloat, TCP, AQM algorithms and ECN.
* ''Difficulty:'' Medium.
* ''Recommended Reading:''
** Flexible Network Tester [[https://flent.org/flent-the-flexible-network-tester.pdf Paper]] [[https://flent.org/ Tool]]
** [https://www.nsnam.org/doxygen/d9/dc9/group__applications.html#details Existing Applications in ns-3]
** [https://gitlab.com/tomhenderson/ns-3-dev/-/commits/flent?ref_type=heads Prior work on Flent application API in ns-3]

=== Internet routing refactory ===

Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], [TBD].

Traditionally IP routing tables are organized in tuples {Dst, DstMask, GatewayAddr}, e.g., {10.42.66.0, 255.255.255.0, 169.254.10.1}, plus other flags and data, like the interface to be used.
In ns-3 this is accomplished by storing three separate objects, two Ipv[4,6]Address, and one Ipv[4Mask,6Prefix].

While this is quite simple to implement, this has some notable drawbacks, e.g., the Dst address must be a network address (Dst & ~DstMask == 0), it is not efficient (the mask or prefix could be represented by a simple integer), and more.
In order to improve code readability and consistency between IPv4 and IPv6, !2645 introduces two new classes: Ipv[4,6]NetworkAddress.

The goal is to refactor the existing routing classes, along with Ipv[4,6]RotingTable classes, so that they use the new classes.
The candidate should provide a clear and convincing plan to pursue the above mentioned goal, all while keeping backward compatibility. The APIs of the existing classes must be kept as they are (at most the can be deprecated), and new APIs should be introduced only where strictly necessary.
Another very important requirement will be to break down the work in multiple sub-tasks, so that the merge process can be gradual.

It is not required that the candidate will update the code for all the routing schemes, but the choice of which routing algorithms will be considered during the project must be clear and motivated.

* ''Required Experience:'' Fundamentals of IPv6 addressing and routing, C++ programming.
* ''Interests:'' IPv4 and IPv6 routing
* ''Difficulty:'' Easy.
* ''Recommended reading:''
** [https://gitlab.com/nsnam/ns-3-dev/-/issues/1239 Issue #1239]
** [https://gitlab.com/nsnam/ns-3-dev/-/merge_requests/2645 Merge Request !2645]

Possible tasks to fulfill the patch requirement:
* Use !2645 to modify all or in part the `Rip` protocol.

=== Ping and TraverouteV4 enhancements ===

Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], [TBD].

The Ping and TraverouteV4 ns-3 application have some small limitations.

In particular 2 of them are annoying.
1. Neither Ping nor TracerouteV4 reacts to ICMP errors or informative messages.
2. As the name implies, TracerouteV4 is IPv4-only and can't be used on IPv6.

The goal is to remove the above mentioned limitations, all or in part. A proposal should clearly outline the plan and improvements to the existing code (e.g., the list of the ICMP messages that will be considered), and a clear breakdown of the work. For the TracerouteV4 refactoring to use IPv6 as well, the proposal must consider the Ping implementation as a guideline.

* ''Required Experience:'' Fundamentals of IPv4, IPv6, ICMP, and ICMPv6. C++ programming.
* ''Interests:'' IPv4 and IPv6.
* ''Difficulty:'' Easy.
* ''Recommended reading:''
** [https://gitlab.com/nsnam/ns-3-dev/-/issues/825 Issue #825]

Possible tasks to fulfill the patch requirement:
* MR to have Ping react to one ICMP message.

== Medium sized projects (175 hours) ==

=== 6LoWPAN mesh-under routing enhancements ===

Mentors: [mailto:tommaso.pecorella@unifi.it 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.
Better approaches are possible, e.g., by leveraging some concepts from RFC 7731, by using SNR as a guidance, or by measuring the local network activity.

The candidate should outline the proposed approach, what parts of code are going to be affected, and how they can be enhanced.

* ''Required Experience:'' Fundamentals of IPv6 addressing, C++ programming.
* ''Bonus Experience:'' Familiarity with mesh routing and 6LoWPAN ns-3
* ''Interests:'' IPv6 mesh routing
* ''Difficulty:'' Easy.
* ''Recommended reading:''
** [https://www.nsnam.org/docs/models/html/sixlowpan.html#mesh-under-routing Mesh-under in ns-3 6LoWPAN]
** [https://datatracker.ietf.org/doc/html/rfc7731 RFC 7731]
** [https://meshtastic.org/docs/overview/mesh-algo/ Meshtastic controlled flooding]
** [https://ieeexplore.ieee.org/document/91339 Routing by controlled flooding in communication networks] (if the document can not be accessed, PM the mentors)

Possible tasks to fulfill the patch requirement:
* The current code is hardwired, i.e., the mesh-under routing scheme is embedded into the SixLowPanNetDevice. Propose a patch to decouple it, using a SixLowPanMeshUnderRouting class to determine the "next hop". The behavior of the actual protocol should be unchanged.

=== 6LoWPAN neighbor discovery protocol ===

Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], [mailto:adnan.rashid@poliba.it Adnan Rashid].

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 help merging the code (if it's not already merged) and add some features that are not yet considered in the model.

The candidate should outline in the proposal the features that are planned to be added, and a code mockup (or a complete class diagram) for said features.

* ''Required Experience:'' Fundamentals of IPv6 addressing, C++ programming.
* ''Bonus Experience:'' Familiarity with 6LoWPAN and 6LoWPAN-ND
* ''Interests:'' IPv6 and IoT networks
* ''Difficulty:'' Easy.
* ''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]
** https://gitlab.com/jieqiboh5836/ns-3-dev/-/tree/6LoWPAN-ND-P1
** https://gitlab.com/jieqiboh5836/ns-3-dev/-/tree/6LoWPAN-ND-P2

===OLLA Link Adaptation for 5G-LENA===

Mentors: [mailto:bbojovic@cttc.es Biljana Bojovic], [mailto:tomh@tomh.org Tom Henderson], [mailto:gcarvalho@cttc.es Gabriel Ferreira], [mailto:slagen@cttc.es Sandra Lagen]

This project would focus on improving the realism of the CTTC 5G-LENA by implementing Outer Loop Link Adaptation (OLLA) in the scheduling/link adaptation workflow. In the current baseline, MCS selection is driven by CQI (or SINR-to-CQI mapping) without an outer-loop correction. OLLA is commonly used to track a target BLER by updating an SINR (or CQI) offset based on HARQ ACK/NACK feedback, leading to more stable and realistic link adaptation behavior under varying channel conditions. This project should include this adaptation for the DL and for the UL, integrated in a scheduler-agnostic way so multiple NR schedulers can reuse it with minimal duplication.

In addition, the project would include a performance evaluation:

*comparing the new OLLA-enabled behavior against the current baseline and across multiple representative existing NR schedulers.
*the evaluation should consider throughput, latency, and achieved BLER, including how closely the achieved BLER tracks the configured target.
*the evaluation of the responsiveness to channel condition changes (convergence speed, stability/oscillation behavior).
*the sensitivity to the CQI update frequency and to user data rate / traffic load (how ACK/NACK rate affects convergence).

Additional topics/work items that could be considered if feasible:

*More advanced OLLA algorithms.
*Calibration guidance and/or comparison against published OLLA configurations (when reference data is available).
*Extensions beyond MCS selection (e.g., rank adaptation). This should be relatively easy in the uplink, but for the downlink some advanced mechanism could be investigated and potentially, AI-based approach could be considered.

For starters, we would suggest adding the CTTC 5G-LENA (nr module) to ns-3 (as a module in the contrib/ directory), building and running the NR examples, and becoming familiar with the current scheduler, HARQ feedback flow, CQI/MCS selection, and TBS computation. 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.

*Required Experience: C++ programming, understanding of 5G NR MAC concepts (scheduling, CQI/MCS, HARQ), wireless networking fundamentals
*Interests: 5G NR simulations, scheduling, link adaptation, performance evaluation
*Difficulty: Medium
*Project size: 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.

=== Enabling 5G NR examples visualization ===

Mentors: [mailto:aashtari@cttc.es Amir Ashtari Gargari], [mailto:gcarvalho@cttc.es Gabriel Ferreira], [mailto:bbojovic@cttc.es Biljana Bojovic] and [mailto:kkoutlia@cttc.es Katerina Koutlia]

The main idea of this project is to allow easier visualization of 5G NR examples by integrating the NR module with some ns-3 visualization tools like NetAnim, or by implementing a kind of web-based visualization, e.g., through Jupyter notebook. The new feature should allow the visualization of already existing traces, visualization of topology, or even some new relevant simulation aspects could be considered. The idea is that users better understand how the metrics collection works, and how changing parameters can affect simulation results. In this project, we are open to other ideas on how to implement visualizations. An example scenario is to have e.g. the handover scenario and then be able to see while the UEs are moving and performing handover how their performance metrics vary.

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.
* Recommended reading: Please read this thread in the ns-3 developers list: [https://groups.google.com/g/ns-developers/c/xGCOIAuTYs8/m/yhzpGJkYAwAJ?utm_medium=email&utm_source=footer UI "Designer" for NS3 Based Visual Scripting].

=== AODVv2 Protocol enhancements ===

Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], [TBD].

ns-3 contains models for proactive (DSDV and OLSR) and reactive (AODV and DSR) ad hoc routing protocols. AODVv2 is currently an IETF draft, and its implementation in ns-3 is ongoing. This project aims at enhancing the AODVv2 model for ns-3.

In particular the project should address the following points:
# Alignment with the latest drafts,
# Model finalization and testing (in particular for the IPv6 part),
# AODVv2 examples and documentation,
# "External" network routing support.

Collaboration with the draft authors is also highly suggested.

* ''Required Experience:'' Fundamentals of IPv6 addressing, C++ programming.
* ''Bonus Experience:'' Familiarity with AODV implementations in ns-3 and AODVv2
* ''Interests:'' Ad hoc routing
* ''Difficulty:'' Medium.
* ''Recommended reading:''
** [https://www.nsnam.org/docs/models/html/ipv6.html IPv6 model in ns-3]
** [https://www.nsnam.org/docs/models/html/aodv.html AODV model in ns-3]
** [https://gitlab.com/tod97/ns-3-dev/-/tree/aodvv2-icns3-25 AODVv2 model presented at ICNS3-2025]
** [https://datatracker.ietf.org/doc/draft-perkins-manet-aodvv2/05/ Ad Hoc On-demand Distance Vector Version 2 (AODVv2) Routing]

Possible tasks to fulfill the patch requirement:
* [https://gitlab.com/nsnam/ns-3-dev/-/issues/368 Issue #368] - aodv: aodv parameters can be set to "impossible" values

=== Integration of 3GPP Release-19 Features into the ns-3 3GPP Model and 5G-LENA ===

Mentors: [mailto:bbojovic@cttc.es Biljana Bojovic], [mailto:slagen@cttc.es Sandra Lagen]

This project aims to improve the realism and standard alignment of ns-3 3GPP and 5G-LENA by implementing selected 3GPP Release 19 modeling features. The goal is to extend the simulator with updated components reflecting recent 5G-Advanced developments.

Possible contributions include:

* Handheld device antenna placement and orientation models, reflecting realistic UE form-factor constraints and radiation characteristics.
* New channel models introduced in Release-19, such as suburban macro scenarios, including their associated path-loss, shadowing, and spatial consistency characteristics.
* Enhancements to existing propagation or antenna models to better align with recent 3GPP specifications changes.
* Additional Release-19 features relevant to system-level simulation, potentially including improvements to mobility modeling, link abstraction, or scheduler interactions.

The exact feature to be implemented will be selected jointly with the mentors and the contributor based on impact, feasibility, and the contributor's interests. Once the selected feature has been designed and integrated into ns-3 and 5G-LENA, the contributor will also be responsible for:

* develop unit tests
* validation example demonstrating the new capability
* prepare the contribution for integration into ns-3 following coding and review guidelines
* evaluation which may include:
** Validation or calibration against 3GPP reference results.
** Comparison with baseline ns-3 3GPP and 5G-LENA behavior to quantify the impact of the new model.
** Analysis of how the new feature affects system-level metrics, such as throughput, coverage, or interference patterns.

The project will be co-mentored by researchers involved in 3GPP standardization, including industry delegates contributing to the Release 19 process.

* Required Experience: C++ and Python programming, understanding of 5G NR, LTE, and wireless networks
* Interests: 3GPP calibration, 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 work or MRs to ns-3 or the nr module, you can contact us to check whether it is enough for the patch requirement.
* Recommended reading: [https://arxiv.org/pdf/2507.19266 Overview of 3GPP Release 19 Study on Channel Modeling Enhancements to TR 38.901 for 6G]

=== Multi-Band Support and Carrier Selection in 5G-LENA for FR3 CA ===

Mentors: [mailto:bbojovic@cttc.es Biljana Bojovic], [mailto:slagen@cttc.es Sandra Lagen]

This project will extend the CTTC 5G-LENA NR module with initial support for multi-band operation and baseline carrier-selection mechanisms. The implementation is intended to be generic, while the evaluation will focus on FR3 scenarios in the 7-24 GHz range. The work will focus on adding the support needed to configure multiple carriers, implementing baseline UE carrier-selection policies based on simple metrics such as received power, SINR, or load, and on introducing a component carrier manager that enables carrier aggregation across configured carriers.

Expected contributions include:

*support for configuring multiple carriers with band-dependent parameters
*baseline UE carrier-selection policies
*implementation of a component carrier manager to support carrier aggregation
*unit tests for configuration, selection and aggregation, validation scenarios, and example simulations

Example scenarios may include a UE selecting the most suitable carrier as channel conditions change. The evaluation will focus on FR3 use cases, including scenarios relevant to FR3 carrier aggregation.
Evaluation may consider throughput, fairness, coverage, and robustness under different carrier-selection policies.

Possible extensions include load-aware selection strategies and more advanced carrier aggregation policies.

* Required Experience: C++ and Python programming, understanding of 5G NR, LTE, and wireless networks
* Interests: 3GPP calibration, 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 work or MRs to ns-3 or the nr module, you can contact us to check whether it is enough for the patch requirement.
* Recommended reading:
**[https://arxiv.org/pdf/2502.17914 A. Bazzi et al., Upper Mid-Band Spectrum for 6G]
**[https://arxiv.org/pdf/2507.19266 Overview of 3GPP Release 19 Study on Channel Modeling Enhancements to TR 38.901 for 6G]
**[https://arxiv.org/pdf/2310.06425 6G Wireless Communications in 7–24 GHz Band]

=== Spectrum Sharing Support for 5G-LENA and ns-3 ===

Mentors: [mailto:slagen@cttc.es Sandra Lagen], [mailto:bbojovic@cttc.es Biljana Bojovic]

This project will extend the CTTC 5G-LENA NR module with initial support for spectrum sharing mechanisms. The work can build on the existing
[https://gitlab.com/cttc-lena/nr-u NR-U module], upgrading it to the latest 5G-LENA and ns-3 versions and then extending its procedures to better align with 3GPP spectrum-sharing specifications.

Expected steps include:
* upgrade the [https://gitlab.com/cttc-lena/nr-u NR-U module] to the latest 5G-LENA and ns-3
* extend the upgraded module with spectrum sharing support aligned with 3GPP procedures
* update the examples that simulate 5G/Wi-Fi coexistence (by using the new NrChannelHelper)
* write documentation, create an example and tests for spectrum sharing
* prepare the contributions for integration into 5G-LENA and ns-3 following coding and review guidelines

If time permits, we may investigate the integration of the updated module into the 5G-LENA mainline.

* Required Experience: C++ and Python programming, understanding of 5G NR, LTE, and wireless networks
* Interests: spectrum sharing, 3GPP coexistence studies, 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 work or MRs to ns-3 or the nr module, you can contact us to check whether it is enough for the patch requirement.
* Recommended reading:
** [https://arxiv.org/pdf/2211.08956 A Comprehensive Survey on Spectrum Sharing Techniques for 5G/B5G Intelligent Wireless Networks: Opportunities, Challenges and Future Research Directions]
** [https://kar.kent.ac.uk/109199/ NR-U and Wi-Fi Unlicensed Spectrum Sharing: Design Challenges and Solutions]

== Large projects (350 hours) ==

=== Mesh Link Establishment (MLE) protocol ===

Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], [mailto:alramonet@is.tokushima-u.ac.jp Alberto Gallegos Ramonet].

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:''
** [https://datatracker.ietf.org/doc/html/draft-ietf-6lo-mesh-link-establishment MLE draft]
** [https://openthread.io/guides/thread-primer/network-discovery Thread primer]
** [https://www.threadgroup.org/ThreadSpec Thread specifications]

Possible tasks to fulfill the patch requirement:
* TBD, contact the mentors if interested.

===Energy Consumption Modeling and Power-Aware Extensions for 5G-LENA===

Mentors: [mailto:kkoutlia@cttc.es Katerina Koutlia], [mailto:bbojovic@cttc.es Biljana Bojovic], [mailto:mmiozzo@cttc.es Marco Miozzo] and [mailto:aashtari@cttc.es Amir Ashtari Gargari]

This project would add energy consumption modeling to the CTTC 5G-LENA (NR module). While 5G-LENA provides a detailed and validated simulation of the 5G NR protocol stack behavior, it currently lacks energy models for UEs and/or gNBs, limiting research on energy efficiency, green networking, 6G sustainability, and potentially AI-driven power-aware control.
The project would first evaluate reuse of the ns-3 Energy Framework (e.g., EnergySource, DeviceEnergyModel) by defining a clean interface between 5G-LENA and the energy module. If existing models are insufficient, the project would design and implement a 5G-specific device energy model (e.g., NrDeviceEnergyModel) and connect it to relevant 5G-LENA state/procedure events.
For starters, we would suggest adding the CTTC 5G-LENA (nr module) to ns-3 (as a module in the contrib/ directory), building and running the NR examples, and studying the Energy Framework integration patterns. Documentation is available here: https://5g-lena.cttc.es/. Tutorial video: https://acmse.net/2021/tutorials-offered/#tut-work03.

Scope (expected deliverables):
*Energy consumption accounting for UEs and/or gNBs
*Per-state (and if feasible per-procedure) modeling, e.g.
**gNB: idle/active/sleep, TX/RX, processing; dependence on bandwidth/PRBs, TX power, MIMO layers/streams/RF chains, load
**UE: TX/RX, measurements, CSI-RS/SRS activity, beamforming-related processing, handover
*Tracing, example(s), and documentation

Optional (time permitting): a simple energy-aware scheduling extension to explore QoS trade-offs (e.g., energy-per-bit or energy-aware MIMO under GBR)

*Required Experience: C++ programming, wireless networking fundamentals (energy/state-machine modeling is a plus)
*Interests: 5G NR simulations, energy efficiency, green networking, 6G sustainability
*Difficulty: Medium
*Project size: 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 integration with ns-3-ai ===

Mentors: [mailto:kkoutlia@cttc.es Katerina Koutlia], [mailto:gcarvalho@cttc.es Gabriel Ferreira], [mailto:aashtari@cttc.es Amir Ashtari Gargari] and [mailto:bbojovic@cttc.es Biljana Bojovic]

The objective of this project is to integrate the ns-3 5G NR module with [https://apps.nsnam.org/app/ns3-ai/ ns-3-ai]. Please note that the ns-allinone-3.47 release uses DEFIANCE version which is more currently maintained; can be found [https://github.com/DEFIANCE-project/ns3-ai here]. In GSoC 2024 we had a project in which 5G NR was integrated with [https://www.nsnam.org/wiki/GSOC2024RLUsability5G ns-3 gym]. While ns-3 gym is a popular ns-3 module for AI, it is limited to the application of reinforcement learning techniques in networking research. On the other hand, ns-3-ai module provides a more general solution that enables the data interaction between ns-3 and other Python-based AI frameworks, like [https://www.tensorflow.org/api_docs/cc Tensorflow C++ APIs] and [https://pytorch.org/cppdocs/ PyTorch C++ APIs], which opens the door to use different machine learning-based techniques in 5G NR models. The correct functioning of the integration should be tested, and documented, and a fully working example using ns-3-ai should be provided. The contributor can propose a use-case scenario for matching learning. One option is to use it for MAC scheduling, but it could be used for other 5G related research problems, and the contributor is encouraged to propose the use case of his/her interest.

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.
* Project size: Large
* 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.

=== Linux-like CAKE queue discipline for ns-3 ===

Mentors: [mailto:tahiliani.nitk@gmail.com Mohit P. Tahiliani]

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.

* ''Required Experience:'' Familiarity with queue disciplines, TCP and C++ programming.
* ''Bonus Experience:'' Familiarity with CAKE framework in Linux 4.19
* ''Interests:'' Active Queue Management, Packet scheduling and TCP.
* ''Difficulty:'' Medium to Hard
* ''Recommended reading:''
** [https://arxiv.org/pdf/1804.07617.pdf Piece of CAKE: A Comprehensive Queue Management Solution for Home Gateways]
** [https://lwn.net/Articles/758353/ Let them run CAKE]
** [https://www.nsnam.org/docs/models/html/queue-discs.html Queue disciplines in ns-3]

=== Switched Ethernet ===

Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], TBD.

The current ns-3 models for wired connections are fine for simple networks, but the lack of a switched Ethernet model is a limitation in some cases.

The goal of the idea is to create, test, and document a Switched Ethernet model, able to simulate (at least) 1, 10, and 40 GbE links and model for a switch.

The model of the NetDevice and Channel shall take into account the link delays and errors, similarly to what is done by the point-to-point model. Futhermore, it should be able to set the link speed and if it is full-duplex or half-duplex. Additional support for flow control is a bonus, but not strictly required. Link speed auto-negotiation is not considered to be interesting.

The model for the switch should be modular (i.e., allowing the development of different switch types), and include auto-learning of I/O ports based on the MAC address, i.e., have a MAC/port table, and a basic store-and-forward operation. Features like advanced I/O buffer handling and ARP/NDP spoofing detection are not a priority and shall be left for future implementations.

The model should consider the future implementaion of algorithms like VLANs (IEEE 802.1Q, 802.1ad), and the Spanning Tree Protocol (IEEE 802.1D, 802.1w, and 802.1s). Their implementaion is not required, but the model design should allow their development.

* ''Required Experience:'' Fundamentals of Ethernet sitched networking, C++ programming.
* ''Interests:'' Ethernet networks and switched data networks.
* ''Difficulty:'' Medium.
* ''Recommended reading:''
** [https://codereview.appspot.com/5615049/ Basic implementation (very old)]
** [https://gitlab.com/nsnam/ns-3-dev/-/merge_requests/431 Full-duplex CSMA, somehow related]
** [https://tcipg.org/sites/default/files/papers/2010_Jin_Nicol_Caesar.pdf Paper on gigabit Ethernet switch models for simulation]

Possible tasks to fulfill the patch requirement:
* TBD, contact the mentors if interested.

GSOC2026Projects

2026-03-24T14:03:36Z

Biljana: /* 5G NR module integration with ns-3-ai */

{{TOC}}

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

* [https://developers.google.com/open-source/gsoc/faq GSoC Frequently Asked Questions]
* [[GSOC2026ContributorGuide | ns-3's 2026 GSoC Contributor guide]]
* [https://developers.google.com/open-source/gsoc/resources/guide GSoC contributor/student guide (not ns-3 specific)]
* [[GSOC2025ApplicationTemplate | 2026 GSoC Contributor application template]]
* [[GSOCMentorGuide | ns-3's GSoC Mentor guide]]
* [https://archive.flossmanuals.net/gsocmentoring/index.html GSoC Mentor guide (not ns-3 specific)]
* [[GSOCSelectionProcess | GSoC Contributor Selection Process]]
* ''Get in contact with the ns-3 team'': [https://groups.google.com/g/ns-developers 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-25. 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 [mailto:tpecorella@mac.com Tommaso Pecorella] and [mailto:tahiliani.nitk@gmail.com Mohit P. Tahiliani]; contact them with any questions. They also hang out on [https://ns-3.zulipchat.com 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 [https://developers.google.com/open-source/gsoc/resources/guide GSoC contributor guide].
* Read [[GSOC2026ContributorGuide |ns-3's 2026 GSoC contributor guide]]
* 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.
* Once it is posted, look through the [[GSOC2024ApplicationTemplate |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 2026, 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 2026. 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 suggests 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>
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.
</blockquote>

=== Patch requirement guidelines ===

In past years, we have asked applicants to submit a patch related to an open issue or a suggested coding exercise. We are undecided at this time whether we will ask for this in 2026; check back later.

=== 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 ===

* [[#Flent Application API in ns-3]] (small size project, 90h)
* [[#Ping and TraverouteV4 enhancements]] (small size project, 90h)
* [[#Internet routing refactory]] (small size project, 90h)
* [[#AODVv2 Protocol enhancements]] (medium size project, 175h)
* [[#Linux-like CAKE queue discipline for ns-3]] (large size project, 350h)
* [[#Switched Ethernet]] (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)

=== 5G NR models enhancements ===

The general idea is to improve the usability of the 5G NR module by adding new examples that help users start building scenario scripts. Also, an interesting improvement could be integration with other modules, like those for AI or visualizations. Here are some project ideas. Depending on the contributor's interest and skills we can adjust these projects' definitions.

* [[#OLLA Link Adaptation and Spec-Compliant TBS Calculation for 5G-LENA]] (medium size project, 175h)
* [[#Enabling 5G NR examples visualization]] (medium size project, 175h)
* [[#Energy Consumption Modeling and Power-Aware Extensions for 5G-LENA]] (large size project, 250h)
* [[#5G NR module integration with ns-3-ai]] (large size project, 250h)
* [[#Integration of 3GPP Release-19 Features into the ns-3 3GPP Model and 5G-LENA]] (medium size project, 175h)
* [[#Multi-Band Support and Carrier Selection in 5G-LENA for FR3 CA]] (medium size project, 175h)
* [[#Spectrum Sharing Support for 5G-LENA and ns-3]] (medium size project, 175h)

== Small sized projects (90 hours) ==

=== Flent Application API in ns-3 ===

Mentors: [mailto:tahiliani.nitk@gmail.com Mohit P. Tahiliani]

Flexible Network Tester (Flent) is a network benchmarking tool. It is written in Python and wraps well-known network benchmarking tools (such as netperf and iperf) into aggregate, repeatable tests, such as a number of tests for Bufferbloat. A basic structure for Flent Application API in ns-3 has been developed. It is a wrapper around existing ns-3 applications. This project has four main goals: (1) update this implementation to match the current ns-3-dev, (2) integrate a JSON library properly (for Flent-style result handling) (3) validate correctness of Flent results produced by ns-3, and (4) Add more Flent-style test examples useful for ns-3 users. The goal of this project is to merge the Flent Application API into ns-3 mainline, not the app store.

* ''Required Experience:'' Familiarity with Flent and C++ programming.
* ''Bonus Experience:'' Familiarity with applications supported in ns-3.
* ''Interests:'' Bufferbloat, TCP, AQM algorithms and ECN.
* ''Difficulty:'' Medium.
* ''Recommended Reading:''
** Flexible Network Tester [[https://flent.org/flent-the-flexible-network-tester.pdf Paper]] [[https://flent.org/ Tool]]
** [https://www.nsnam.org/doxygen/d9/dc9/group__applications.html#details Existing Applications in ns-3]
** [https://gitlab.com/tomhenderson/ns-3-dev/-/commits/flent?ref_type=heads Prior work on Flent application API in ns-3]

=== Internet routing refactory ===

Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], [TBD].

Traditionally IP routing tables are organized in tuples {Dst, DstMask, GatewayAddr}, e.g., {10.42.66.0, 255.255.255.0, 169.254.10.1}, plus other flags and data, like the interface to be used.
In ns-3 this is accomplished by storing three separate objects, two Ipv[4,6]Address, and one Ipv[4Mask,6Prefix].

While this is quite simple to implement, this has some notable drawbacks, e.g., the Dst address must be a network address (Dst & ~DstMask == 0), it is not efficient (the mask or prefix could be represented by a simple integer), and more.
In order to improve code readability and consistency between IPv4 and IPv6, !2645 introduces two new classes: Ipv[4,6]NetworkAddress.

The goal is to refactor the existing routing classes, along with Ipv[4,6]RotingTable classes, so that they use the new classes.
The candidate should provide a clear and convincing plan to pursue the above mentioned goal, all while keeping backward compatibility. The APIs of the existing classes must be kept as they are (at most the can be deprecated), and new APIs should be introduced only where strictly necessary.
Another very important requirement will be to break down the work in multiple sub-tasks, so that the merge process can be gradual.

It is not required that the candidate will update the code for all the routing schemes, but the choice of which routing algorithms will be considered during the project must be clear and motivated.

* ''Required Experience:'' Fundamentals of IPv6 addressing and routing, C++ programming.
* ''Interests:'' IPv4 and IPv6 routing
* ''Difficulty:'' Easy.
* ''Recommended reading:''
** [https://gitlab.com/nsnam/ns-3-dev/-/issues/1239 Issue #1239]
** [https://gitlab.com/nsnam/ns-3-dev/-/merge_requests/2645 Merge Request !2645]

Possible tasks to fulfill the patch requirement:
* Use !2645 to modify all or in part the `Rip` protocol.

=== Ping and TraverouteV4 enhancements ===

Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], [TBD].

The Ping and TraverouteV4 ns-3 application have some small limitations.

In particular 2 of them are annoying.
1. Neither Ping nor TracerouteV4 reacts to ICMP errors or informative messages.
2. As the name implies, TracerouteV4 is IPv4-only and can't be used on IPv6.

The goal is to remove the above mentioned limitations, all or in part. A proposal should clearly outline the plan and improvements to the existing code (e.g., the list of the ICMP messages that will be considered), and a clear breakdown of the work. For the TracerouteV4 refactoring to use IPv6 as well, the proposal must consider the Ping implementation as a guideline.

* ''Required Experience:'' Fundamentals of IPv4, IPv6, ICMP, and ICMPv6. C++ programming.
* ''Interests:'' IPv4 and IPv6.
* ''Difficulty:'' Easy.
* ''Recommended reading:''
** [https://gitlab.com/nsnam/ns-3-dev/-/issues/825 Issue #825]

Possible tasks to fulfill the patch requirement:
* MR to have Ping react to one ICMP message.

== Medium sized projects (175 hours) ==

=== 6LoWPAN mesh-under routing enhancements ===

Mentors: [mailto:tommaso.pecorella@unifi.it 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.
Better approaches are possible, e.g., by leveraging some concepts from RFC 7731, by using SNR as a guidance, or by measuring the local network activity.

The candidate should outline the proposed approach, what parts of code are going to be affected, and how they can be enhanced.

* ''Required Experience:'' Fundamentals of IPv6 addressing, C++ programming.
* ''Bonus Experience:'' Familiarity with mesh routing and 6LoWPAN ns-3
* ''Interests:'' IPv6 mesh routing
* ''Difficulty:'' Easy.
* ''Recommended reading:''
** [https://www.nsnam.org/docs/models/html/sixlowpan.html#mesh-under-routing Mesh-under in ns-3 6LoWPAN]
** [https://datatracker.ietf.org/doc/html/rfc7731 RFC 7731]
** [https://meshtastic.org/docs/overview/mesh-algo/ Meshtastic controlled flooding]
** [https://ieeexplore.ieee.org/document/91339 Routing by controlled flooding in communication networks] (if the document can not be accessed, PM the mentors)

Possible tasks to fulfill the patch requirement:
* The current code is hardwired, i.e., the mesh-under routing scheme is embedded into the SixLowPanNetDevice. Propose a patch to decouple it, using a SixLowPanMeshUnderRouting class to determine the "next hop". The behavior of the actual protocol should be unchanged.

=== 6LoWPAN neighbor discovery protocol ===

Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], [mailto:adnan.rashid@poliba.it Adnan Rashid].

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 help merging the code (if it's not already merged) and add some features that are not yet considered in the model.

The candidate should outline in the proposal the features that are planned to be added, and a code mockup (or a complete class diagram) for said features.

* ''Required Experience:'' Fundamentals of IPv6 addressing, C++ programming.
* ''Bonus Experience:'' Familiarity with 6LoWPAN and 6LoWPAN-ND
* ''Interests:'' IPv6 and IoT networks
* ''Difficulty:'' Easy.
* ''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]
** https://gitlab.com/jieqiboh5836/ns-3-dev/-/tree/6LoWPAN-ND-P1
** https://gitlab.com/jieqiboh5836/ns-3-dev/-/tree/6LoWPAN-ND-P2

===OLLA Link Adaptation for 5G-LENA===

Mentors: [mailto:bbojovic@cttc.es Biljana Bojovic], [mailto:tomh@tomh.org Tom Henderson], [mailto:gcarvalho@cttc.es Gabriel Ferreira], [mailto:slagen@cttc.es Sandra Lagen]

This project would focus on improving the realism of the CTTC 5G-LENA by implementing Outer Loop Link Adaptation (OLLA) in the scheduling/link adaptation workflow. In the current baseline, MCS selection is driven by CQI (or SINR-to-CQI mapping) without an outer-loop correction. OLLA is commonly used to track a target BLER by updating an SINR (or CQI) offset based on HARQ ACK/NACK feedback, leading to more stable and realistic link adaptation behavior under varying channel conditions. This project should include this adaptation for the DL and for the UL, integrated in a scheduler-agnostic way so multiple NR schedulers can reuse it with minimal duplication.

In addition, the project would include a performance evaluation:

*comparing the new OLLA-enabled behavior against the current baseline and across multiple representative existing NR schedulers.
*the evaluation should consider throughput, latency, and achieved BLER, including how closely the achieved BLER tracks the configured target.
*the evaluation of the responsiveness to channel condition changes (convergence speed, stability/oscillation behavior).
*the sensitivity to the CQI update frequency and to user data rate / traffic load (how ACK/NACK rate affects convergence).

Additional topics/work items that could be considered if feasible:

*More advanced OLLA algorithms.
*Calibration guidance and/or comparison against published OLLA configurations (when reference data is available).
*Extensions beyond MCS selection (e.g., rank adaptation). This should be relatively easy in the uplink, but for the downlink some advanced mechanism could be investigated and potentially, AI-based approach could be considered.

For starters, we would suggest adding the CTTC 5G-LENA (nr module) to ns-3 (as a module in the contrib/ directory), building and running the NR examples, and becoming familiar with the current scheduler, HARQ feedback flow, CQI/MCS selection, and TBS computation. 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.

*Required Experience: C++ programming, understanding of 5G NR MAC concepts (scheduling, CQI/MCS, HARQ), wireless networking fundamentals
*Interests: 5G NR simulations, scheduling, link adaptation, performance evaluation
*Difficulty: Medium
*Project size: 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.

=== Enabling 5G NR examples visualization ===

Mentors: [mailto:aashtari@cttc.es Amir Ashtari Gargari], [mailto:gcarvalho@cttc.es Gabriel Ferreira], [mailto:bbojovic@cttc.es Biljana Bojovic] and [mailto:kkoutlia@cttc.es Katerina Koutlia]

The main idea of this project is to allow easier visualization of 5G NR examples by integrating the NR module with some ns-3 visualization tools like NetAnim, or by implementing a kind of web-based visualization, e.g., through Jupyter notebook. The new feature should allow the visualization of already existing traces, visualization of topology, or even some new relevant simulation aspects could be considered. The idea is that users better understand how the metrics collection works, and how changing parameters can affect simulation results. In this project, we are open to other ideas on how to implement visualizations. An example scenario is to have e.g. the handover scenario and then be able to see while the UEs are moving and performing handover how their performance metrics vary.

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.
* Recommended reading: Please read this thread in the ns-3 developers list: [https://groups.google.com/g/ns-developers/c/xGCOIAuTYs8/m/yhzpGJkYAwAJ?utm_medium=email&utm_source=footer UI "Designer" for NS3 Based Visual Scripting].

=== AODVv2 Protocol enhancements ===

Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], [TBD].

ns-3 contains models for proactive (DSDV and OLSR) and reactive (AODV and DSR) ad hoc routing protocols. AODVv2 is currently an IETF draft, and its implementation in ns-3 is ongoing. This project aims at enhancing the AODVv2 model for ns-3.

In particular the project should address the following points:
# Alignment with the latest drafts,
# Model finalization and testing (in particular for the IPv6 part),
# AODVv2 examples and documentation,
# "External" network routing support.

Collaboration with the draft authors is also highly suggested.

* ''Required Experience:'' Fundamentals of IPv6 addressing, C++ programming.
* ''Bonus Experience:'' Familiarity with AODV implementations in ns-3 and AODVv2
* ''Interests:'' Ad hoc routing
* ''Difficulty:'' Medium.
* ''Recommended reading:''
** [https://www.nsnam.org/docs/models/html/ipv6.html IPv6 model in ns-3]
** [https://www.nsnam.org/docs/models/html/aodv.html AODV model in ns-3]
** [https://gitlab.com/tod97/ns-3-dev/-/tree/aodvv2-icns3-25 AODVv2 model presented at ICNS3-2025]
** [https://datatracker.ietf.org/doc/draft-perkins-manet-aodvv2/05/ Ad Hoc On-demand Distance Vector Version 2 (AODVv2) Routing]

Possible tasks to fulfill the patch requirement:
* [https://gitlab.com/nsnam/ns-3-dev/-/issues/368 Issue #368] - aodv: aodv parameters can be set to "impossible" values

=== Integration of 3GPP Release-19 Features into the ns-3 3GPP Model and 5G-LENA ===

Mentors: [mailto:bbojovic@cttc.es Biljana Bojovic], [mailto:slagen@cttc.es Sandra Lagen]

This project aims to improve the realism and standard alignment of ns-3 3GPP and 5G-LENA by implementing selected 3GPP Release 19 modeling features. The goal is to extend the simulator with updated components reflecting recent 5G-Advanced developments.

Possible contributions include:

* Handheld device antenna placement and orientation models, reflecting realistic UE form-factor constraints and radiation characteristics.
* New channel models introduced in Release-19, such as suburban macro scenarios, including their associated path-loss, shadowing, and spatial consistency characteristics.
* Enhancements to existing propagation or antenna models to better align with recent 3GPP specifications changes.
* Additional Release-19 features relevant to system-level simulation, potentially including improvements to mobility modeling, link abstraction, or scheduler interactions.

The exact feature to be implemented will be selected jointly with the mentors and the contributor based on impact, feasibility, and the contributor's interests. Once the selected feature has been designed and integrated into ns-3 and 5G-LENA, the contributor will also be responsible for:

* develop unit tests
* validation example demonstrating the new capability
* prepare the contribution for integration into ns-3 following coding and review guidelines
* evaluation which may include:
** Validation or calibration against 3GPP reference results.
** Comparison with baseline ns-3 3GPP and 5G-LENA behavior to quantify the impact of the new model.
** Analysis of how the new feature affects system-level metrics, such as throughput, coverage, or interference patterns.

The project will be co-mentored by researchers involved in 3GPP standardization, including industry delegates contributing to the Release 19 process.

* Required Experience: C++ and Python programming, understanding of 5G NR, LTE, and wireless networks
* Interests: 3GPP calibration, 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 work or MRs to ns-3 or the nr module, you can contact us to check whether it is enough for the patch requirement.
* Recommended reading: [https://arxiv.org/pdf/2507.19266 Overview of 3GPP Release 19 Study on Channel Modeling Enhancements to TR 38.901 for 6G]

=== Multi-Band Support and Carrier Selection in 5G-LENA for FR3 CA ===

Mentors: [mailto:bbojovic@cttc.es Biljana Bojovic], [mailto:slagen@cttc.es Sandra Lagen]

This project will extend the CTTC 5G-LENA NR module with initial support for multi-band operation and baseline carrier-selection mechanisms. The implementation is intended to be generic, while the evaluation will focus on FR3 scenarios in the 7-24 GHz range. The work will focus on adding the support needed to configure multiple carriers, implementing baseline UE carrier-selection policies based on simple metrics such as received power, SINR, or load, and on introducing a component carrier manager that enables carrier aggregation across configured carriers.

Expected contributions include:

*support for configuring multiple carriers with band-dependent parameters
*baseline UE carrier-selection policies
*implementation of a component carrier manager to support carrier aggregation
*unit tests for configuration, selection and aggregation, validation scenarios, and example simulations

Example scenarios may include a UE selecting the most suitable carrier as channel conditions change. The evaluation will focus on FR3 use cases, including scenarios relevant to FR3 carrier aggregation.
Evaluation may consider throughput, fairness, coverage, and robustness under different carrier-selection policies.

Possible extensions include load-aware selection strategies and more advanced carrier aggregation policies.

* Required Experience: C++ and Python programming, understanding of 5G NR, LTE, and wireless networks
* Interests: 3GPP calibration, 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 work or MRs to ns-3 or the nr module, you can contact us to check whether it is enough for the patch requirement.
* Recommended reading:
**[https://arxiv.org/pdf/2502.17914 A. Bazzi et al., Upper Mid-Band Spectrum for 6G]
**[https://arxiv.org/pdf/2507.19266 Overview of 3GPP Release 19 Study on Channel Modeling Enhancements to TR 38.901 for 6G]
**[https://arxiv.org/pdf/2310.06425 6G Wireless Communications in 7–24 GHz Band]

=== Spectrum Sharing Support for 5G-LENA and ns-3 ===

Mentors: [mailto:slagen@cttc.es Sandra Lagen], [mailto:bbojovic@cttc.es Biljana Bojovic]

This project will extend the CTTC 5G-LENA NR module with initial support for spectrum sharing mechanisms. The work can build on the existing
[https://gitlab.com/cttc-lena/nr-u NR-U module], upgrading it to the latest 5G-LENA and ns-3 versions and then extending its procedures to better align with 3GPP spectrum-sharing specifications.

Expected steps include:
* upgrade the [https://gitlab.com/cttc-lena/nr-u NR-U module] to the latest 5G-LENA and ns-3
* extend the upgraded module with spectrum sharing support aligned with 3GPP procedures
* update the examples that simulate 5G/Wi-Fi coexistence (by using the new NrChannelHelper)
* write documentation, create an example and tests for spectrum sharing
* prepare the contributions for integration into 5G-LENA and ns-3 following coding and review guidelines

If time permits, we may investigate the integration of the updated module into the 5G-LENA mainline.

* Required Experience: C++ and Python programming, understanding of 5G NR, LTE, and wireless networks
* Interests: spectrum sharing, 3GPP coexistence studies, 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 work or MRs to ns-3 or the nr module, you can contact us to check whether it is enough for the patch requirement.
* Recommended reading:
** [https://arxiv.org/pdf/2211.08956 A Comprehensive Survey on Spectrum Sharing Techniques for 5G/B5G Intelligent Wireless Networks: Opportunities, Challenges and Future Research Directions]
** [https://kar.kent.ac.uk/109199/ NR-U and Wi-Fi Unlicensed Spectrum Sharing: Design Challenges and Solutions]

== Large projects (350 hours) ==

=== Mesh Link Establishment (MLE) protocol ===

Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], [mailto:alramonet@is.tokushima-u.ac.jp Alberto Gallegos Ramonet].

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:''
** [https://datatracker.ietf.org/doc/html/draft-ietf-6lo-mesh-link-establishment MLE draft]
** [https://openthread.io/guides/thread-primer/network-discovery Thread primer]
** [https://www.threadgroup.org/ThreadSpec Thread specifications]

Possible tasks to fulfill the patch requirement:
* TBD, contact the mentors if interested.

===Energy Consumption Modeling and Power-Aware Extensions for 5G-LENA===

Mentors: [mailto:kkoutlia@cttc.es Katerina Koutlia], [mailto:bbojovic@cttc.es Biljana Bojovic], [mailto:mmiozzo@cttc.es Marco Miozzo] and [mailto:aashtari@cttc.es Amir Ashtari Gargari]

This project would add energy consumption modeling to the CTTC 5G-LENA (NR module). While 5G-LENA provides a detailed and validated simulation of the 5G NR protocol stack behavior, it currently lacks energy models for UEs and/or gNBs, limiting research on energy efficiency, green networking, 6G sustainability, and potentially AI-driven power-aware control.
The project would first evaluate reuse of the ns-3 Energy Framework (e.g., EnergySource, DeviceEnergyModel) by defining a clean interface between 5G-LENA and the energy module. If existing models are insufficient, the project would design and implement a 5G-specific device energy model (e.g., NrDeviceEnergyModel) and connect it to relevant 5G-LENA state/procedure events.
For starters, we would suggest adding the CTTC 5G-LENA (nr module) to ns-3 (as a module in the contrib/ directory), building and running the NR examples, and studying the Energy Framework integration patterns. Documentation is available here: https://5g-lena.cttc.es/. Tutorial video: https://acmse.net/2021/tutorials-offered/#tut-work03.

Scope (expected deliverables):
*Energy consumption accounting for UEs and/or gNBs
*Per-state (and if feasible per-procedure) modeling, e.g.
**gNB: idle/active/sleep, TX/RX, processing; dependence on bandwidth/PRBs, TX power, MIMO layers/streams/RF chains, load
**UE: TX/RX, measurements, CSI-RS/SRS activity, beamforming-related processing, handover
*Tracing, example(s), and documentation

Optional (time permitting): a simple energy-aware scheduling extension to explore QoS trade-offs (e.g., energy-per-bit or energy-aware MIMO under GBR)

*Required Experience: C++ programming, wireless networking fundamentals (energy/state-machine modeling is a plus)
*Interests: 5G NR simulations, energy efficiency, green networking, 6G sustainability
*Difficulty: Medium
*Project size: 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 integration with ns-3-ai ===

Mentors: [mailto:kkoutlia@cttc.es Katerina Koutlia], [mailto:gcarvalho@cttc.es Gabriel Ferreira], [mailto:aashtari@cttc.es Amir Ashtari Gargari] and [mailto:bbojovic@cttc.es Biljana Bojovic]

The objective of this project is to integrate the ns-3 5G NR module with [https://apps.nsnam.org/app/ns3-ai/ ns-3-ai]. In GSoC 2024 we had a project in which 5G NR was integrated with [https://www.nsnam.org/wiki/GSOC2024RLUsability5G ns-3 gym]. While ns-3 gym is a popular ns-3 module for AI, it is limited to the application of reinforcement learning techniques in networking research. On the other hand, ns-3-ai module provides a more general solution that enables the data interaction between ns-3 and other Python-based AI frameworks, like [https://www.tensorflow.org/api_docs/cc Tensorflow C++ APIs] and [https://pytorch.org/cppdocs/ PyTorch C++ APIs], which opens the door to use different machine learning-based techniques in 5G NR models. The correct functioning of the integration should be tested, and documented, and a fully working example using ns-3-ai should be provided. The contributor can propose a use-case scenario for matching learning. One option is to use it for MAC scheduling, but it could be used for other 5G related research problems, and the contributor is encouraged to propose the use case of his/her interest.

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.
* Project size: Large
* 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.

=== Linux-like CAKE queue discipline for ns-3 ===

Mentors: [mailto:tahiliani.nitk@gmail.com Mohit P. Tahiliani]

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.

* ''Required Experience:'' Familiarity with queue disciplines, TCP and C++ programming.
* ''Bonus Experience:'' Familiarity with CAKE framework in Linux 4.19
* ''Interests:'' Active Queue Management, Packet scheduling and TCP.
* ''Difficulty:'' Medium to Hard
* ''Recommended reading:''
** [https://arxiv.org/pdf/1804.07617.pdf Piece of CAKE: A Comprehensive Queue Management Solution for Home Gateways]
** [https://lwn.net/Articles/758353/ Let them run CAKE]
** [https://www.nsnam.org/docs/models/html/queue-discs.html Queue disciplines in ns-3]

=== Switched Ethernet ===

Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], TBD.

The current ns-3 models for wired connections are fine for simple networks, but the lack of a switched Ethernet model is a limitation in some cases.

The goal of the idea is to create, test, and document a Switched Ethernet model, able to simulate (at least) 1, 10, and 40 GbE links and model for a switch.

The model of the NetDevice and Channel shall take into account the link delays and errors, similarly to what is done by the point-to-point model. Futhermore, it should be able to set the link speed and if it is full-duplex or half-duplex. Additional support for flow control is a bonus, but not strictly required. Link speed auto-negotiation is not considered to be interesting.

The model for the switch should be modular (i.e., allowing the development of different switch types), and include auto-learning of I/O ports based on the MAC address, i.e., have a MAC/port table, and a basic store-and-forward operation. Features like advanced I/O buffer handling and ARP/NDP spoofing detection are not a priority and shall be left for future implementations.

The model should consider the future implementaion of algorithms like VLANs (IEEE 802.1Q, 802.1ad), and the Spanning Tree Protocol (IEEE 802.1D, 802.1w, and 802.1s). Their implementaion is not required, but the model design should allow their development.

* ''Required Experience:'' Fundamentals of Ethernet sitched networking, C++ programming.
* ''Interests:'' Ethernet networks and switched data networks.
* ''Difficulty:'' Medium.
* ''Recommended reading:''
** [https://codereview.appspot.com/5615049/ Basic implementation (very old)]
** [https://gitlab.com/nsnam/ns-3-dev/-/merge_requests/431 Full-duplex CSMA, somehow related]
** [https://tcipg.org/sites/default/files/papers/2010_Jin_Nicol_Caesar.pdf Paper on gigabit Ethernet switch models for simulation]

Possible tasks to fulfill the patch requirement:
* TBD, contact the mentors if interested.

Roadmap

2026-03-19T09:05:34Z

Biljana: /* ns-3.48 plans */

{{TOC}}

ns-3 is a community-driven project, and as such, we cannot typically make guarantees about the availability of new or improved code; our maintainers work largely on a best-effort basis. However, we use this page to describe our goals (time-permitting) for each release, and where we broadly are trying to steer the project for the future.

== ns-3.48 plans ==

ns-3.48 is scheduled for May 2026.

The most up-to-date listing of items being worked on in this release cycle can be seen by browsing [https://gitlab.com/nsnam/ns-3-dev/-/merge_requests?scope=all&state=opened&milestone_title=ns-3.48 Merge requests] and [https://gitlab.com/nsnam/ns-3-dev/-/issues?scope=all&state=opened&milestone_title=ns-3.48 Issues] in the GitLab.com tracker that are tagged with the 'Milestone ns-3.48' tag.

Besides this, the following [https://www.nsnam.org/about/governance/maintainers/ ns-3 maintainers] announced plans to work on the following topics:

* Tom Henderson is prioritizing:
** Supporting wifi (and eventual ns-3-dev) transition to strongly-typed quantities and units
** Merging GSoC 2025 code [https://gitlab.com/nsnam/ns-3-dev/-/merge_requests/2571 Orbital NTN] and [https://gitlab.com/nsnam/ns-3-dev/-/merge_requests/2482 6LoWPAN ND]
** Seeing if we can revive [https://github.com/direct-code-execution/ns-3-dce/pull/147 ns-3 DCE]
** Working on issue and MR backlog
* Biljana Bojovic from the highest to the lowest priority:
** Reviewing Sionna MR https://gitlab.com/nsnam/ns-3-dev/-/merge_requests/2608
** Try to revive NGMN traffic generators MR: https://gitlab.com/nsnam/ns-3-dev/-/merge_requests/2245
** Help with other ns-3 MR backlog
** Would like to work also on:
*** the precoding matrix conversion modelling options
*** check if feasible to port some 3GPP models calibration scripts to ns-3
*** ns-3 with GPUs
*** LLMs for 5G-LENA doxygen

== Long term ==

== Historical information ==

see the [[Current_Development]] page for some older Roadmap items (many have been abandoned)

Roadmap

2026-03-19T09:05:26Z

Biljana: /* ns-3.48 plans */

{{TOC}}

ns-3 is a community-driven project, and as such, we cannot typically make guarantees about the availability of new or improved code; our maintainers work largely on a best-effort basis. However, we use this page to describe our goals (time-permitting) for each release, and where we broadly are trying to steer the project for the future.

== ns-3.48 plans ==

ns-3.48 is scheduled for May 2026.

The most up-to-date listing of items being worked on in this release cycle can be seen by browsing [https://gitlab.com/nsnam/ns-3-dev/-/merge_requests?scope=all&state=opened&milestone_title=ns-3.48 Merge requests] and [https://gitlab.com/nsnam/ns-3-dev/-/issues?scope=all&state=opened&milestone_title=ns-3.48 Issues] in the GitLab.com tracker that are tagged with the 'Milestone ns-3.48' tag.

Besides this, the following [https://www.nsnam.org/about/governance/maintainers/ ns-3 maintainers] announced plans to work on the following topics:

* Tom Henderson is prioritizing:
** Supporting wifi (and eventual ns-3-dev) transition to strongly-typed quantities and units
** Merging GSoC 2025 code [https://gitlab.com/nsnam/ns-3-dev/-/merge_requests/2571 Orbital NTN] and [https://gitlab.com/nsnam/ns-3-dev/-/merge_requests/2482 6LoWPAN ND]
** Seeing if we can revive [https://github.com/direct-code-execution/ns-3-dce/pull/147 ns-3 DCE]
** Working on issue and MR backlog
* Biljana Bojovic from the highest to the lowest priority:
** Reviewing Sionna MR https://gitlab.com/nsnam/ns-3-dev/-/merge_requests/2608
** Try to revive NGMN traffic generators MR: https://gitlab.com/nsnam/ns-3-dev/-/merge_requests/2245
** Help with other ns-3 MR backlog
** Would like to work also on:
*** the precoding matrix conversion modelling options
*** check if feasible to port some 3GPP models calibration scripts to ns-3
*** ns-3 with GPUs
*** LLM for 5G-LENA doxygen

== Long term ==

== Historical information ==

see the [[Current_Development]] page for some older Roadmap items (many have been abandoned)

Roadmap

2026-03-19T09:04:36Z

Biljana: /* ns-3.48 plans */

{{TOC}}

ns-3 is a community-driven project, and as such, we cannot typically make guarantees about the availability of new or improved code; our maintainers work largely on a best-effort basis. However, we use this page to describe our goals (time-permitting) for each release, and where we broadly are trying to steer the project for the future.

== ns-3.48 plans ==

ns-3.48 is scheduled for May 2026.

The most up-to-date listing of items being worked on in this release cycle can be seen by browsing [https://gitlab.com/nsnam/ns-3-dev/-/merge_requests?scope=all&state=opened&milestone_title=ns-3.48 Merge requests] and [https://gitlab.com/nsnam/ns-3-dev/-/issues?scope=all&state=opened&milestone_title=ns-3.48 Issues] in the GitLab.com tracker that are tagged with the 'Milestone ns-3.48' tag.

Besides this, the following [https://www.nsnam.org/about/governance/maintainers/ ns-3 maintainers] announced plans to work on the following topics:

* Tom Henderson is prioritizing:
** Supporting wifi (and eventual ns-3-dev) transition to strongly-typed quantities and units
** Merging GSoC 2025 code [https://gitlab.com/nsnam/ns-3-dev/-/merge_requests/2571 Orbital NTN] and [https://gitlab.com/nsnam/ns-3-dev/-/merge_requests/2482 6LoWPAN ND]
** Seeing if we can revive [https://github.com/direct-code-execution/ns-3-dce/pull/147 ns-3 DCE]
** Working on issue and MR backlog
* Biljana Bojovic from the highest to the lowest priority:
** Reviewing Sionna MR https://gitlab.com/nsnam/ns-3-dev/-/merge_requests/2608
** Try to revive NGMN traffic generators MR: https://gitlab.com/nsnam/ns-3-dev/-/merge_requests/2245
** Help with other ns-3 MR backlog
** Would like to work also on:
*** the precoding matrix conversion modelling options
*** check if feasible to port some 3GPP models calibration scripts to ns-3
*** ns-3 with GPUs
*** how AI can be used to improve 5G-LENA doxygen

== Long term ==

== Historical information ==

see the [[Current_Development]] page for some older Roadmap items (many have been abandoned)

Roadmap

2026-03-19T09:03:36Z

Biljana: /* ns-3.48 plans */

{{TOC}}

ns-3 is a community-driven project, and as such, we cannot typically make guarantees about the availability of new or improved code; our maintainers work largely on a best-effort basis. However, we use this page to describe our goals (time-permitting) for each release, and where we broadly are trying to steer the project for the future.

== ns-3.48 plans ==

ns-3.48 is scheduled for May 2026.

The most up-to-date listing of items being worked on in this release cycle can be seen by browsing [https://gitlab.com/nsnam/ns-3-dev/-/merge_requests?scope=all&state=opened&milestone_title=ns-3.48 Merge requests] and [https://gitlab.com/nsnam/ns-3-dev/-/issues?scope=all&state=opened&milestone_title=ns-3.48 Issues] in the GitLab.com tracker that are tagged with the 'Milestone ns-3.48' tag.

Besides this, the following [https://www.nsnam.org/about/governance/maintainers/ ns-3 maintainers] announced plans to work on the following topics:

* Tom Henderson is prioritizing:
** Supporting wifi (and eventual ns-3-dev) transition to strongly-typed quantities and units
** Merging GSoC 2025 code [https://gitlab.com/nsnam/ns-3-dev/-/merge_requests/2571 Orbital NTN] and [https://gitlab.com/nsnam/ns-3-dev/-/merge_requests/2482 6LoWPAN ND]
** Seeing if we can revive [https://github.com/direct-code-execution/ns-3-dce/pull/147 ns-3 DCE]
** Working on issue and MR backlog
* Biljana Bojovic from the highest to the lowest priority:
** Reviewing Sionna MR https://gitlab.com/nsnam/ns-3-dev/-/merge_requests/2608
** Try to revive NGMN traffic generators MR: https://gitlab.com/nsnam/ns-3-dev/-/merge_requests/2245
** Help with other ns-3 MR backlog
** Would like to work also on:
*** the precoding matrix conversion modelling options
*** check if feasible to port some 3GPP models calibration scripts to ns-3
*** ns-3 with GPUs

== Long term ==

== Historical information ==

see the [[Current_Development]] page for some older Roadmap items (many have been abandoned)

Roadmap

2026-03-18T12:27:41Z

Biljana: /* ns-3.48 plans */

{{TOC}}

ns-3 is a community-driven project, and as such, we cannot typically make guarantees about the availability of new or improved code; our maintainers work largely on a best-effort basis. However, we use this page to describe our goals (time-permitting) for each release, and where we broadly are trying to steer the project for the future.

== ns-3.48 plans ==

ns-3.48 is scheduled for May 2026.

The most up-to-date listing of items being worked on in this release cycle can be seen by browsing [https://gitlab.com/nsnam/ns-3-dev/-/merge_requests?scope=all&state=opened&milestone_title=ns-3.48 Merge requests] and [https://gitlab.com/nsnam/ns-3-dev/-/issues?scope=all&state=opened&milestone_title=ns-3.48 Issues] in the GitLab.com tracker that are tagged with the 'Milestone ns-3.48' tag.

Besides this, the following [https://www.nsnam.org/about/governance/maintainers/ ns-3 maintainers] announced plans to work on the following topics:

* Tom Henderson is prioritizing:
** Supporting wifi (and eventual ns-3-dev) transition to strongly-typed quantities and units
** Merging GSoC 2025 code [https://gitlab.com/nsnam/ns-3-dev/-/merge_requests/2571 Orbital NTN] and [https://gitlab.com/nsnam/ns-3-dev/-/merge_requests/2482 6LoWPAN ND]
** Seeing if we can revive [https://github.com/direct-code-execution/ns-3-dce/pull/147 ns-3 DCE]
** Working on issue and MR backlog
* Biljana Bojovic from the highest to the lowest priority:
** Reviewing Sionna MR https://gitlab.com/nsnam/ns-3-dev/-/merge_requests/2608
** Try to revive NGMN traffic generators MR: https://gitlab.com/nsnam/ns-3-dev/-/merge_requests/2245
** Help with other ns-3 MR backlog
** Would like to work also on:
*** the precoding matrix conversion modelling options
*** check if feasible to port some 3GPP models calibration scripts to ns-3

== Long term ==

== Historical information ==

see the [[Current_Development]] page for some older Roadmap items (many have been abandoned)

Roadmap

2026-03-18T12:27:22Z

Biljana: /* ns-3.48 plans */

{{TOC}}

ns-3 is a community-driven project, and as such, we cannot typically make guarantees about the availability of new or improved code; our maintainers work largely on a best-effort basis. However, we use this page to describe our goals (time-permitting) for each release, and where we broadly are trying to steer the project for the future.

== ns-3.48 plans ==

ns-3.48 is scheduled for May 2026.

The most up-to-date listing of items being worked on in this release cycle can be seen by browsing [https://gitlab.com/nsnam/ns-3-dev/-/merge_requests?scope=all&state=opened&milestone_title=ns-3.48 Merge requests] and [https://gitlab.com/nsnam/ns-3-dev/-/issues?scope=all&state=opened&milestone_title=ns-3.48 Issues] in the GitLab.com tracker that are tagged with the 'Milestone ns-3.48' tag.

Besides this, the following [https://www.nsnam.org/about/governance/maintainers/ ns-3 maintainers] announced plans to work on the following topics:

* Tom Henderson is prioritizing:
** Supporting wifi (and eventual ns-3-dev) transition to strongly-typed quantities and units
** Merging GSoC 2025 code [https://gitlab.com/nsnam/ns-3-dev/-/merge_requests/2571 Orbital NTN] and [https://gitlab.com/nsnam/ns-3-dev/-/merge_requests/2482 6LoWPAN ND]
** Seeing if we can revive [https://github.com/direct-code-execution/ns-3-dce/pull/147 ns-3 DCE]
** Working on issue and MR backlog
* Biljana Bojovic from the highest to the lowest priority:
** Reviewing Sionna https://gitlab.com/nsnam/ns-3-dev/-/merge_requests/2608
** Try to revive NGMN traffic generators MR: https://gitlab.com/nsnam/ns-3-dev/-/merge_requests/2245
** Help with other ns-3 MR backlog
** Would like to work also on:
*** the precoding matrix conversion modelling options
*** check if feasible to port some 3GPP models calibration scripts to ns-3

== Long term ==

== Historical information ==

see the [[Current_Development]] page for some older Roadmap items (many have been abandoned)

GSOC2026Projects

2026-03-16T15:02:30Z

Biljana: /* 5G NR models enhancements */

{{TOC}}

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

* [https://developers.google.com/open-source/gsoc/faq GSoC Frequently Asked Questions]
* [[GSOC2026ContributorGuide | ns-3's 2026 GSoC Contributor guide]]
* [https://developers.google.com/open-source/gsoc/resources/guide GSoC contributor/student guide (not ns-3 specific)]
* [[GSOC2025ApplicationTemplate | 2026 GSoC Contributor application template]]
* [[GSOCMentorGuide | ns-3's GSoC Mentor guide]]
* [https://archive.flossmanuals.net/gsocmentoring/index.html GSoC Mentor guide (not ns-3 specific)]
* [[GSOCSelectionProcess | GSoC Contributor Selection Process]]
* ''Get in contact with the ns-3 team'': [https://groups.google.com/g/ns-developers 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-25. 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 [mailto:tpecorella@mac.com Tommaso Pecorella] and [mailto:tahiliani.nitk@gmail.com Mohit P. Tahiliani]; contact them with any questions. They also hang out on [https://ns-3.zulipchat.com 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 [https://developers.google.com/open-source/gsoc/resources/guide GSoC contributor guide].
* Read [[GSOC2026ContributorGuide |ns-3's 2026 GSoC contributor guide]]
* 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.
* Once it is posted, look through the [[GSOC2024ApplicationTemplate |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 2026, 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 2026. 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 suggests 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>
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.
</blockquote>

=== Patch requirement guidelines ===

In past years, we have asked applicants to submit a patch related to an open issue or a suggested coding exercise. We are undecided at this time whether we will ask for this in 2026; check back later.

=== 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 ===

* [[#Flent Application API in ns-3]] (small size project, 90h)
* [[#Ping and TraverouteV4 enhancements]] (small size project, 90h)
* [[#Internet routing refactory]] (small size project, 90h)
* [[#AODVv2 Protocol enhancements]] (medium size project, 175h)
* [[#Linux-like CAKE queue discipline for ns-3]] (large size project, 350h)
* [[#Switched Ethernet]] (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)

=== 5G NR models enhancements ===

The general idea is to improve the usability of the 5G NR module by adding new examples that help users start building scenario scripts. Also, an interesting improvement could be integration with other modules, like those for AI or visualizations. Here are some project ideas. Depending on the contributor's interest and skills we can adjust these projects' definitions.

* [[#OLLA Link Adaptation and Spec-Compliant TBS Calculation for 5G-LENA]] (medium size project, 175h)
* [[#Enabling 5G NR examples visualization]] (medium size project, 175h)
* [[#Energy Consumption Modeling and Power-Aware Extensions for 5G-LENA]] (large size project, 250h)
* [[#5G NR module integration with ns-3-ai]] (large size project, 250h)
* [[#Integration of 3GPP Release-19 Features into the ns-3 3GPP Model and 5G-LENA]] (medium size project, 175h)
* [[#Multi-Band Support and Carrier Selection in 5G-LENA for FR3 CA]] (medium size project, 175h)
* [[#Spectrum Sharing Support for 5G-LENA and ns-3]] (medium size project, 175h)

== Small sized projects (90 hours) ==

=== Flent Application API in ns-3 ===

Mentors: [mailto:tahiliani.nitk@gmail.com Mohit P. Tahiliani]

Flexible Network Tester (Flent) is a network benchmarking tool. It is written in Python and wraps well-known network benchmarking tools (such as netperf and iperf) into aggregate, repeatable tests, such as a number of tests for Bufferbloat. A basic structure for Flent Application API in ns-3 has been developed. It is a wrapper around existing ns-3 applications. This project has four main goals: (1) update this implementation to match the current ns-3-dev, (2) integrate a JSON library properly (for Flent-style result handling) (3) validate correctness of Flent results produced by ns-3, and (4) Add more Flent-style test examples useful for ns-3 users. The goal of this project is to merge the Flent Application API into ns-3 mainline, not the app store.

* ''Required Experience:'' Familiarity with Flent and C++ programming.
* ''Bonus Experience:'' Familiarity with applications supported in ns-3.
* ''Interests:'' Bufferbloat, TCP, AQM algorithms and ECN.
* ''Difficulty:'' Medium.
* ''Recommended Reading:''
** Flexible Network Tester [[https://flent.org/flent-the-flexible-network-tester.pdf Paper]] [[https://flent.org/ Tool]]
** [https://www.nsnam.org/doxygen/d9/dc9/group__applications.html#details Existing Applications in ns-3]
** [https://gitlab.com/tomhenderson/ns-3-dev/-/commits/flent?ref_type=heads Prior work on Flent application API in ns-3]

=== Internet routing refactory ===

Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], [TBD].

Traditionally IP routing tables are organized in tuples {Dst, DstMask, GatewayAddr}, e.g., {10.42.66.0, 255.255.255.0, 169.254.10.1}, plus other flags and data, like the interface to be used.
In ns-3 this is accomplished by storing three separate objects, two Ipv[4,6]Address, and one Ipv[4Mask,6Prefix].

While this is quite simple to implement, this has some notable drawbacks, e.g., the Dst address must be a network address (Dst & ~DstMask == 0), it is not efficient (the mask or prefix could be represented by a simple integer), and more.
In order to improve code readability and consistency between IPv4 and IPv6, !2645 introduces two new classes: Ipv[4,6]NetworkAddress.

The goal is to refactor the existing routing classes, along with Ipv[4,6]RotingTable classes, so that they use the new classes.
The candidate should provide a clear and convincing plan to pursue the above mentioned goal, all while keeping backward compatibility. The APIs of the existing classes must be kept as they are (at most the can be deprecated), and new APIs should be introduced only where strictly necessary.
Another very important requirement will be to break down the work in multiple sub-tasks, so that the merge process can be gradual.

It is not required that the candidate will update the code for all the routing schemes, but the choice of which routing algorithms will be considered during the project must be clear and motivated.

* ''Required Experience:'' Fundamentals of IPv6 addressing and routing, C++ programming.
* ''Interests:'' IPv4 and IPv6 routing
* ''Difficulty:'' Easy.
* ''Recommended reading:''
** [https://gitlab.com/nsnam/ns-3-dev/-/issues/1239 Issue #1239]
** [https://gitlab.com/nsnam/ns-3-dev/-/merge_requests/2645 Merge Request !2645]

Possible tasks to fulfill the patch requirement:
* Use !2645 to modify all or in part the `Rip` protocol.

=== Ping and TraverouteV4 enhancements ===

Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], [TBD].

The Ping and TraverouteV4 ns-3 application have some small limitations.

In particular 2 of them are annoying.
1. Neither Ping nor TracerouteV4 reacts to ICMP errors or informative messages.
2. As the name implies, TracerouteV4 is IPv4-only and can't be used on IPv6.

The goal is to remove the above mentioned limitations, all or in part. A proposal should clearly outline the plan and improvements to the existing code (e.g., the list of the ICMP messages that will be considered), and a clear breakdown of the work. For the TracerouteV4 refactoring to use IPv6 as well, the proposal must consider the Ping implementation as a guideline.

* ''Required Experience:'' Fundamentals of IPv4, IPv6, ICMP, and ICMPv6. C++ programming.
* ''Interests:'' IPv4 and IPv6.
* ''Difficulty:'' Easy.
* ''Recommended reading:''
** [https://gitlab.com/nsnam/ns-3-dev/-/issues/825 Issue #825]

Possible tasks to fulfill the patch requirement:
* MR to have Ping react to one ICMP message.

== Medium sized projects (175 hours) ==

=== 6LoWPAN mesh-under routing enhancements ===

Mentors: [mailto:tommaso.pecorella@unifi.it 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.
Better approaches are possible, e.g., by leveraging some concepts from RFC 7731, by using SNR as a guidance, or by measuring the local network activity.

The candidate should outline the proposed approach, what parts of code are going to be affected, and how they can be enhanced.

* ''Required Experience:'' Fundamentals of IPv6 addressing, C++ programming.
* ''Bonus Experience:'' Familiarity with mesh routing and 6LoWPAN ns-3
* ''Interests:'' IPv6 mesh routing
* ''Difficulty:'' Easy.
* ''Recommended reading:''
** [https://www.nsnam.org/docs/models/html/sixlowpan.html#mesh-under-routing Mesh-under in ns-3 6LoWPAN]
** [https://datatracker.ietf.org/doc/html/rfc7731 RFC 7731]
** [https://meshtastic.org/docs/overview/mesh-algo/ Meshtastic controlled flooding]
** [https://ieeexplore.ieee.org/document/91339 Routing by controlled flooding in communication networks] (if the document can not be accessed, PM the mentors)

Possible tasks to fulfill the patch requirement:
* The current code is hardwired, i.e., the mesh-under routing scheme is embedded into the SixLowPanNetDevice. Propose a patch to decouple it, using a SixLowPanMeshUnderRouting class to determine the "next hop". The behavior of the actual protocol should be unchanged.

=== 6LoWPAN neighbor discovery protocol ===

Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], [mailto:adnan.rashid@poliba.it Adnan Rashid].

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 help merging the code (if it's not already merged) and add some features that are not yet considered in the model.

The candidate should outline in the proposal the features that are planned to be added, and a code mockup (or a complete class diagram) for said features.

* ''Required Experience:'' Fundamentals of IPv6 addressing, C++ programming.
* ''Bonus Experience:'' Familiarity with 6LoWPAN and 6LoWPAN-ND
* ''Interests:'' IPv6 and IoT networks
* ''Difficulty:'' Easy.
* ''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]
** https://gitlab.com/jieqiboh5836/ns-3-dev/-/tree/6LoWPAN-ND-P1
** https://gitlab.com/jieqiboh5836/ns-3-dev/-/tree/6LoWPAN-ND-P2

===OLLA Link Adaptation for 5G-LENA===

Mentors: [mailto:bbojovic@cttc.es Biljana Bojovic], [mailto:tomh@tomh.org Tom Henderson], [mailto:gcarvalho@cttc.es Gabriel Ferreira], [mailto:slagen@cttc.es Sandra Lagen]

This project would focus on improving the realism of the CTTC 5G-LENA by implementing Outer Loop Link Adaptation (OLLA) in the scheduling/link adaptation workflow. In the current baseline, MCS selection is driven by CQI (or SINR-to-CQI mapping) without an outer-loop correction. OLLA is commonly used to track a target BLER by updating an SINR (or CQI) offset based on HARQ ACK/NACK feedback, leading to more stable and realistic link adaptation behavior under varying channel conditions. This project should include this adaptation for the DL and for the UL, integrated in a scheduler-agnostic way so multiple NR schedulers can reuse it with minimal duplication.

In addition, the project would include a performance evaluation:

*comparing the new OLLA-enabled behavior against the current baseline and across multiple representative existing NR schedulers.
*the evaluation should consider throughput, latency, and achieved BLER, including how closely the achieved BLER tracks the configured target.
*the evaluation of the responsiveness to channel condition changes (convergence speed, stability/oscillation behavior).
*the sensitivity to the CQI update frequency and to user data rate / traffic load (how ACK/NACK rate affects convergence).

Additional topics/work items that could be considered if feasible:

*More advanced OLLA algorithms.
*Calibration guidance and/or comparison against published OLLA configurations (when reference data is available).
*Extensions beyond MCS selection (e.g., rank adaptation). This should be relatively easy in the uplink, but for the downlink some advanced mechanism could be investigated and potentially, AI-based approach could be considered.

For starters, we would suggest adding the CTTC 5G-LENA (nr module) to ns-3 (as a module in the contrib/ directory), building and running the NR examples, and becoming familiar with the current scheduler, HARQ feedback flow, CQI/MCS selection, and TBS computation. 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.

*Required Experience: C++ programming, understanding of 5G NR MAC concepts (scheduling, CQI/MCS, HARQ), wireless networking fundamentals
*Interests: 5G NR simulations, scheduling, link adaptation, performance evaluation
*Difficulty: Medium
*Project size: 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.

=== Enabling 5G NR examples visualization ===

Mentors: [mailto:aashtari@cttc.es Amir Ashtari Gargari], [mailto:gcarvalho@cttc.es Gabriel Ferreira], [mailto:bbojovic@cttc.es Biljana Bojovic] and [mailto:kkoutlia@cttc.es Katerina Koutlia]

The main idea of this project is to allow easier visualization of 5G NR examples by integrating the NR module with some ns-3 visualization tools like NetAnim, or by implementing a kind of web-based visualization, e.g., through Jupyter notebook. The new feature should allow the visualization of already existing traces, visualization of topology, or even some new relevant simulation aspects could be considered. The idea is that users better understand how the metrics collection works, and how changing parameters can affect simulation results. In this project, we are open to other ideas on how to implement visualizations. An example scenario is to have e.g. the handover scenario and then be able to see while the UEs are moving and performing handover how their performance metrics vary.

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.
* Recommended reading: Please read this thread in the ns-3 developers list: [https://groups.google.com/g/ns-developers/c/xGCOIAuTYs8/m/yhzpGJkYAwAJ?utm_medium=email&utm_source=footer UI "Designer" for NS3 Based Visual Scripting].

=== AODVv2 Protocol enhancements ===

Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], [TBD].

ns-3 contains models for proactive (DSDV and OLSR) and reactive (AODV and DSR) ad hoc routing protocols. AODVv2 is currently an IETF draft, and its implementation in ns-3 is ongoing. This project aims at enhancing the AODVv2 model for ns-3.

In particular the project should address the following points:
# Alignment with the latest drafts,
# Model finalization and testing (in particular for the IPv6 part),
# AODVv2 examples and documentation,
# "External" network routing support.

Collaboration with the draft authors is also highly suggested.

* ''Required Experience:'' Fundamentals of IPv6 addressing, C++ programming.
* ''Bonus Experience:'' Familiarity with AODV implementations in ns-3 and AODVv2
* ''Interests:'' Ad hoc routing
* ''Difficulty:'' Medium.
* ''Recommended reading:''
** [https://www.nsnam.org/docs/models/html/ipv6.html IPv6 model in ns-3]
** [https://www.nsnam.org/docs/models/html/aodv.html AODV model in ns-3]
** [https://gitlab.com/tod97/ns-3-dev/-/tree/aodvv2-icns3-25 AODVv2 model presented at ICNS3-2025]
** [https://datatracker.ietf.org/doc/draft-perkins-manet-aodvv2/05/ Ad Hoc On-demand Distance Vector Version 2 (AODVv2) Routing]

Possible tasks to fulfill the patch requirement:
* [https://gitlab.com/nsnam/ns-3-dev/-/issues/368 Issue #368] - aodv: aodv parameters can be set to "impossible" values

=== Integration of 3GPP Release-19 Features into the ns-3 3GPP Model and 5G-LENA ===

Mentors: [mailto:bbojovic@cttc.es Biljana Bojovic], [mailto:slagen@cttc.es Sandra Lagen]

This project aims to improve the realism and standard alignment of ns-3 3GPP and 5G-LENA by implementing selected 3GPP Release 19 modeling features. The goal is to extend the simulator with updated components reflecting recent 5G-Advanced developments.

Possible contributions include:

* Handheld device antenna placement and orientation models, reflecting realistic UE form-factor constraints and radiation characteristics.
* New channel models introduced in Release-19, such as suburban macro scenarios, including their associated path-loss, shadowing, and spatial consistency characteristics.
* Enhancements to existing propagation or antenna models to better align with recent 3GPP specifications changes.
* Additional Release-19 features relevant to system-level simulation, potentially including improvements to mobility modeling, link abstraction, or scheduler interactions.

The exact feature to be implemented will be selected jointly with the mentors and the contributor based on impact, feasibility, and the contributor's interests. Once the selected feature has been designed and integrated into ns-3 and 5G-LENA, the contributor will also be responsible for:

* develop unit tests
* validation example demonstrating the new capability
* prepare the contribution for integration into ns-3 following coding and review guidelines
* evaluation which may include:
** Validation or calibration against 3GPP reference results.
** Comparison with baseline ns-3 3GPP and 5G-LENA behavior to quantify the impact of the new model.
** Analysis of how the new feature affects system-level metrics, such as throughput, coverage, or interference patterns.

The project will be co-mentored by researchers involved in 3GPP standardization, including industry delegates contributing to the Release 19 process.

* Required Experience: C++ and Python programming, understanding of 5G NR, LTE, and wireless networks
* Interests: 3GPP calibration, 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 work or MRs to ns-3 or the nr module, you can contact us to check whether it is enough for the patch requirement.
* Recommended reading: [https://arxiv.org/pdf/2507.19266 Overview of 3GPP Release 19 Study on Channel Modeling Enhancements to TR 38.901 for 6G]

=== Multi-Band Support and Carrier Selection in 5G-LENA for FR3 CA ===

Mentors: [mailto:bbojovic@cttc.es Biljana Bojovic], [mailto:slagen@cttc.es Sandra Lagen]

This project will extend the CTTC 5G-LENA NR module with initial support for multi-band operation and baseline carrier-selection mechanisms. The implementation is intended to be generic, while the evaluation will focus on FR3 scenarios in the 7-24 GHz range. The work will focus on adding the support needed to configure multiple carriers, implementing baseline UE carrier-selection policies based on simple metrics such as received power, SINR, or load, and on introducing a component carrier manager that enables carrier aggregation across configured carriers.

Expected contributions include:

*support for configuring multiple carriers with band-dependent parameters
*baseline UE carrier-selection policies
*implementation of a component carrier manager to support carrier aggregation
*unit tests for configuration, selection and aggregation, validation scenarios, and example simulations

Example scenarios may include a UE selecting the most suitable carrier as channel conditions change. The evaluation will focus on FR3 use cases, including scenarios relevant to FR3 carrier aggregation.
Evaluation may consider throughput, fairness, coverage, and robustness under different carrier-selection policies.

Possible extensions include load-aware selection strategies and more advanced carrier aggregation policies.

* Required Experience: C++ and Python programming, understanding of 5G NR, LTE, and wireless networks
* Interests: 3GPP calibration, 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 work or MRs to ns-3 or the nr module, you can contact us to check whether it is enough for the patch requirement.
* Recommended reading:
**[https://arxiv.org/pdf/2502.17914 A. Bazzi et al., Upper Mid-Band Spectrum for 6G]
**[https://arxiv.org/pdf/2507.19266 Overview of 3GPP Release 19 Study on Channel Modeling Enhancements to TR 38.901 for 6G]
**[https://arxiv.org/pdf/2310.06425 6G Wireless Communications in 7–24 GHz Band]

=== Spectrum Sharing Support for 5G-LENA and ns-3 ===

Mentors: [mailto:slagen@cttc.es Sandra Lagen], [mailto:bbojovic@cttc.es Biljana Bojovic]

This project will extend the CTTC 5G-LENA NR module with initial support for spectrum sharing mechanisms. The work can build on the existing
[https://gitlab.com/cttc-lena/nr-u NR-U module], upgrading it to the latest 5G-LENA and ns-3 versions and then extending its procedures to better align with 3GPP spectrum-sharing specifications.

Expected steps include:
* upgrade the [https://gitlab.com/cttc-lena/nr-u NR-U module] to the latest 5G-LENA and ns-3
* extend the upgraded module with spectrum sharing support aligned with 3GPP procedures
* update the examples that simulate 5G/Wi-Fi coexistence (by using the new NrChannelHelper)
* write documentation, create an example and tests for spectrum sharing
* prepare the contributions for integration into 5G-LENA and ns-3 following coding and review guidelines

If time permits, we may investigate the integration of the updated module into the 5G-LENA mainline.

* Required Experience: C++ and Python programming, understanding of 5G NR, LTE, and wireless networks
* Interests: spectrum sharing, 3GPP coexistence studies, 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 work or MRs to ns-3 or the nr module, you can contact us to check whether it is enough for the patch requirement.
* Recommended reading:
** [https://arxiv.org/pdf/2211.08956 A Comprehensive Survey on Spectrum Sharing Techniques for 5G/B5G Intelligent Wireless Networks: Opportunities, Challenges and Future Research Directions]
** [https://kar.kent.ac.uk/109199/ NR-U and Wi-Fi Unlicensed Spectrum Sharing: Design Challenges and Solutions]

== Large projects (350 hours) ==

=== Mesh Link Establishment (MLE) protocol ===

Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], [mailto:alramonet@is.tokushima-u.ac.jp Alberto Gallegos Ramonet].

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:''
** [https://datatracker.ietf.org/doc/html/draft-ietf-6lo-mesh-link-establishment MLE draft]
** [https://openthread.io/guides/thread-primer/network-discovery Thread primer]
** [https://www.threadgroup.org/ThreadSpec Thread specifications]

Possible tasks to fulfill the patch requirement:
* TBD, contact the mentors if interested.

===Energy Consumption Modeling and Power-Aware Extensions for 5G-LENA===

Mentors: [mailto:kkoutlia@cttc.es Katerina Koutlia], [mailto:bbojovic@cttc.es Biljana Bojovic], [mailto:mmiozzo@cttc.es Marco Miozzo] and [mailto:aashtari@cttc.es Amir Ashtari Gargari]

This project would add energy consumption modeling to the CTTC 5G-LENA (NR module). While 5G-LENA provides a detailed and validated simulation of the 5G NR protocol stack behavior, it currently lacks energy models for UEs and/or gNBs, limiting research on energy efficiency, green networking, 6G sustainability, and potentially AI-driven power-aware control.
The project would first evaluate reuse of the ns-3 Energy Framework (e.g., EnergySource, DeviceEnergyModel) by defining a clean interface between 5G-LENA and the energy module. If existing models are insufficient, the project would design and implement a 5G-specific device energy model (e.g., NrDeviceEnergyModel) and connect it to relevant 5G-LENA state/procedure events.
For starters, we would suggest adding the CTTC 5G-LENA (nr module) to ns-3 (as a module in the contrib/ directory), building and running the NR examples, and studying the Energy Framework integration patterns. Documentation is available here: https://5g-lena.cttc.es/. Tutorial video: https://acmse.net/2021/tutorials-offered/#tut-work03.

Scope (expected deliverables):
*Energy consumption accounting for UEs and/or gNBs
*Per-state (and if feasible per-procedure) modeling, e.g.
**gNB: idle/active/sleep, TX/RX, processing; dependence on bandwidth/PRBs, TX power, MIMO layers/streams/RF chains, load
**UE: TX/RX, measurements, CSI-RS/SRS activity, beamforming-related processing, handover
*Tracing, example(s), and documentation

Optional (time permitting): a simple energy-aware scheduling extension to explore QoS trade-offs (e.g., energy-per-bit or energy-aware MIMO under GBR)

*Required Experience: C++ programming, wireless networking fundamentals (energy/state-machine modeling is a plus)
*Interests: 5G NR simulations, energy efficiency, green networking, 6G sustainability
*Difficulty: Medium
*Project size: 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 integration with ns-3-ai ===

Mentors: [mailto:kkoutlia@cttc.es Katerina Koutlia], [mailto:gcarvalho@cttc.es Gabriel Ferreira], [mailto:aashtari@cttc.es Amir Ashtari Gargari] and [mailto:bbojovic@cttc.es Biljana Bojovic]

The objective of this project is to integrate the ns-3 5G NR module with [https://apps.nsnam.org/app/ns3-ai/ ns-3-ai]. In GSoC 2024 we had a project in which 5G NR was integrated with [https://www.nsnam.org/wiki/GSOC2024RLUsability5G ns-3 gym]. While ns-3 gym is a popular ns-3 module for AI, it is limited to the application of reinforcement learning techniques in networking research. On the other hand, ns-3-ai module provides a more general solution that enables the data interaction between ns-3 and other Python-based AI frameworks, like [https://www.tensorflow.org/api_docs/cc Tensorflow C++ APIs] and [https://pytorch.org/cppdocs/ PyTorch C++ APIs], which opens the door to use different machine learning-based techniques in 5G NR models. The correct functioning of the integration should be tested, and documented, and a fully working example using ns-3-ai should be provided. The contributor can propose a use-case scenario for matching learning. One option is to use it for MAC scheduling, but it could be used for other 5G related research problems, and the contributor is encouraged to propose the use case of his/her interest.

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.
* 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.

=== Linux-like CAKE queue discipline for ns-3 ===

Mentors: [mailto:tahiliani.nitk@gmail.com Mohit P. Tahiliani]

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.

* ''Required Experience:'' Familiarity with queue disciplines, TCP and C++ programming.
* ''Bonus Experience:'' Familiarity with CAKE framework in Linux 4.19
* ''Interests:'' Active Queue Management, Packet scheduling and TCP.
* ''Difficulty:'' Medium to Hard
* ''Recommended reading:''
** [https://arxiv.org/pdf/1804.07617.pdf Piece of CAKE: A Comprehensive Queue Management Solution for Home Gateways]
** [https://lwn.net/Articles/758353/ Let them run CAKE]
** [https://www.nsnam.org/docs/models/html/queue-discs.html Queue disciplines in ns-3]

=== Switched Ethernet ===

Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], TBD.

The current ns-3 models for wired connections are fine for simple networks, but the lack of a switched Ethernet model is a limitation in some cases.

The goal of the idea is to create, test, and document a Switched Ethernet model, able to simulate (at least) 1, 10, and 40 GbE links and model for a switch.

The model of the NetDevice and Channel shall take into account the link delays and errors, similarly to what is done by the point-to-point model. Futhermore, it should be able to set the link speed and if it is full-duplex or half-duplex. Additional support for flow control is a bonus, but not strictly required. Link speed auto-negotiation is not considered to be interesting.

The model for the switch should be modular (i.e., allowing the development of different switch types), and include auto-learning of I/O ports based on the MAC address, i.e., have a MAC/port table, and a basic store-and-forward operation. Features like advanced I/O buffer handling and ARP/NDP spoofing detection are not a priority and shall be left for future implementations.

The model should consider the future implementaion of algorithms like VLANs (IEEE 802.1Q, 802.1ad), and the Spanning Tree Protocol (IEEE 802.1D, 802.1w, and 802.1s). Their implementaion is not required, but the model design should allow their development.

* ''Required Experience:'' Fundamentals of Ethernet sitched networking, C++ programming.
* ''Interests:'' Ethernet networks and switched data networks.
* ''Difficulty:'' Medium.
* ''Recommended reading:''
** [https://codereview.appspot.com/5615049/ Basic implementation (very old)]
** [https://gitlab.com/nsnam/ns-3-dev/-/merge_requests/431 Full-duplex CSMA, somehow related]
** [https://tcipg.org/sites/default/files/papers/2010_Jin_Nicol_Caesar.pdf Paper on gigabit Ethernet switch models for simulation]

Possible tasks to fulfill the patch requirement:
* TBD, contact the mentors if interested.

GSOC2026Projects

2026-03-16T15:01:08Z

Biljana: /* Medium sized projects (175 hours) */

{{TOC}}

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

* [https://developers.google.com/open-source/gsoc/faq GSoC Frequently Asked Questions]
* [[GSOC2026ContributorGuide | ns-3's 2026 GSoC Contributor guide]]
* [https://developers.google.com/open-source/gsoc/resources/guide GSoC contributor/student guide (not ns-3 specific)]
* [[GSOC2025ApplicationTemplate | 2026 GSoC Contributor application template]]
* [[GSOCMentorGuide | ns-3's GSoC Mentor guide]]
* [https://archive.flossmanuals.net/gsocmentoring/index.html GSoC Mentor guide (not ns-3 specific)]
* [[GSOCSelectionProcess | GSoC Contributor Selection Process]]
* ''Get in contact with the ns-3 team'': [https://groups.google.com/g/ns-developers 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-25. 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 [mailto:tpecorella@mac.com Tommaso Pecorella] and [mailto:tahiliani.nitk@gmail.com Mohit P. Tahiliani]; contact them with any questions. They also hang out on [https://ns-3.zulipchat.com 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 [https://developers.google.com/open-source/gsoc/resources/guide GSoC contributor guide].
* Read [[GSOC2026ContributorGuide |ns-3's 2026 GSoC contributor guide]]
* 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.
* Once it is posted, look through the [[GSOC2024ApplicationTemplate |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 2026, 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 2026. 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 suggests 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>
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.
</blockquote>

=== Patch requirement guidelines ===

In past years, we have asked applicants to submit a patch related to an open issue or a suggested coding exercise. We are undecided at this time whether we will ask for this in 2026; check back later.

=== 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 ===

* [[#Flent Application API in ns-3]] (small size project, 90h)
* [[#Ping and TraverouteV4 enhancements]] (small size project, 90h)
* [[#Internet routing refactory]] (small size project, 90h)
* [[#AODVv2 Protocol enhancements]] (medium size project, 175h)
* [[#Linux-like CAKE queue discipline for ns-3]] (large size project, 350h)
* [[#Switched Ethernet]] (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)

=== 5G NR models enhancements ===

The general idea is to improve the usability of the 5G NR module by adding new examples that help users start building scenario scripts. Also, an interesting improvement could be integration with other modules, like those for AI or visualizations. Here are some project ideas. Depending on the contributor's interest and skills we can adjust these projects' definitions.

* [[#OLLA Link Adaptation and Spec-Compliant TBS Calculation for 5G-LENA]](medium size project, 175h)
* [[#Enabling 5G NR examples visualization]] (medium size project, 175h)
* [[#Energy Consumption Modeling and Power-Aware Extensions for 5G-LENA]](large size project, 250h)
* [[#5G NR module integration with ns-3-ai]] (large size project, 250h)
* [[#Integration of 3GPP Release-19 Features into the ns-3 3GPP Model and 5G-LENA]](medium size project, 175h)
* [[#Multi-Band Support and Carrier Selection in 5G-LENA for FR3 CA]](medium size project, 175h)

== Small sized projects (90 hours) ==

=== Flent Application API in ns-3 ===

Mentors: [mailto:tahiliani.nitk@gmail.com Mohit P. Tahiliani]

Flexible Network Tester (Flent) is a network benchmarking tool. It is written in Python and wraps well-known network benchmarking tools (such as netperf and iperf) into aggregate, repeatable tests, such as a number of tests for Bufferbloat. A basic structure for Flent Application API in ns-3 has been developed. It is a wrapper around existing ns-3 applications. This project has four main goals: (1) update this implementation to match the current ns-3-dev, (2) integrate a JSON library properly (for Flent-style result handling) (3) validate correctness of Flent results produced by ns-3, and (4) Add more Flent-style test examples useful for ns-3 users. The goal of this project is to merge the Flent Application API into ns-3 mainline, not the app store.

* ''Required Experience:'' Familiarity with Flent and C++ programming.
* ''Bonus Experience:'' Familiarity with applications supported in ns-3.
* ''Interests:'' Bufferbloat, TCP, AQM algorithms and ECN.
* ''Difficulty:'' Medium.
* ''Recommended Reading:''
** Flexible Network Tester [[https://flent.org/flent-the-flexible-network-tester.pdf Paper]] [[https://flent.org/ Tool]]
** [https://www.nsnam.org/doxygen/d9/dc9/group__applications.html#details Existing Applications in ns-3]
** [https://gitlab.com/tomhenderson/ns-3-dev/-/commits/flent?ref_type=heads Prior work on Flent application API in ns-3]

=== Internet routing refactory ===

Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], [TBD].

Traditionally IP routing tables are organized in tuples {Dst, DstMask, GatewayAddr}, e.g., {10.42.66.0, 255.255.255.0, 169.254.10.1}, plus other flags and data, like the interface to be used.
In ns-3 this is accomplished by storing three separate objects, two Ipv[4,6]Address, and one Ipv[4Mask,6Prefix].

While this is quite simple to implement, this has some notable drawbacks, e.g., the Dst address must be a network address (Dst & ~DstMask == 0), it is not efficient (the mask or prefix could be represented by a simple integer), and more.
In order to improve code readability and consistency between IPv4 and IPv6, !2645 introduces two new classes: Ipv[4,6]NetworkAddress.

The goal is to refactor the existing routing classes, along with Ipv[4,6]RotingTable classes, so that they use the new classes.
The candidate should provide a clear and convincing plan to pursue the above mentioned goal, all while keeping backward compatibility. The APIs of the existing classes must be kept as they are (at most the can be deprecated), and new APIs should be introduced only where strictly necessary.
Another very important requirement will be to break down the work in multiple sub-tasks, so that the merge process can be gradual.

It is not required that the candidate will update the code for all the routing schemes, but the choice of which routing algorithms will be considered during the project must be clear and motivated.

* ''Required Experience:'' Fundamentals of IPv6 addressing and routing, C++ programming.
* ''Interests:'' IPv4 and IPv6 routing
* ''Difficulty:'' Easy.
* ''Recommended reading:''
** [https://gitlab.com/nsnam/ns-3-dev/-/issues/1239 Issue #1239]
** [https://gitlab.com/nsnam/ns-3-dev/-/merge_requests/2645 Merge Request !2645]

Possible tasks to fulfill the patch requirement:
* Use !2645 to modify all or in part the `Rip` protocol.

=== Ping and TraverouteV4 enhancements ===

Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], [TBD].

The Ping and TraverouteV4 ns-3 application have some small limitations.

In particular 2 of them are annoying.
1. Neither Ping nor TracerouteV4 reacts to ICMP errors or informative messages.
2. As the name implies, TracerouteV4 is IPv4-only and can't be used on IPv6.

The goal is to remove the above mentioned limitations, all or in part. A proposal should clearly outline the plan and improvements to the existing code (e.g., the list of the ICMP messages that will be considered), and a clear breakdown of the work. For the TracerouteV4 refactoring to use IPv6 as well, the proposal must consider the Ping implementation as a guideline.

* ''Required Experience:'' Fundamentals of IPv4, IPv6, ICMP, and ICMPv6. C++ programming.
* ''Interests:'' IPv4 and IPv6.
* ''Difficulty:'' Easy.
* ''Recommended reading:''
** [https://gitlab.com/nsnam/ns-3-dev/-/issues/825 Issue #825]

Possible tasks to fulfill the patch requirement:
* MR to have Ping react to one ICMP message.

== Medium sized projects (175 hours) ==

=== 6LoWPAN mesh-under routing enhancements ===

Mentors: [mailto:tommaso.pecorella@unifi.it 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.
Better approaches are possible, e.g., by leveraging some concepts from RFC 7731, by using SNR as a guidance, or by measuring the local network activity.

The candidate should outline the proposed approach, what parts of code are going to be affected, and how they can be enhanced.

* ''Required Experience:'' Fundamentals of IPv6 addressing, C++ programming.
* ''Bonus Experience:'' Familiarity with mesh routing and 6LoWPAN ns-3
* ''Interests:'' IPv6 mesh routing
* ''Difficulty:'' Easy.
* ''Recommended reading:''
** [https://www.nsnam.org/docs/models/html/sixlowpan.html#mesh-under-routing Mesh-under in ns-3 6LoWPAN]
** [https://datatracker.ietf.org/doc/html/rfc7731 RFC 7731]
** [https://meshtastic.org/docs/overview/mesh-algo/ Meshtastic controlled flooding]
** [https://ieeexplore.ieee.org/document/91339 Routing by controlled flooding in communication networks] (if the document can not be accessed, PM the mentors)

Possible tasks to fulfill the patch requirement:
* The current code is hardwired, i.e., the mesh-under routing scheme is embedded into the SixLowPanNetDevice. Propose a patch to decouple it, using a SixLowPanMeshUnderRouting class to determine the "next hop". The behavior of the actual protocol should be unchanged.

=== 6LoWPAN neighbor discovery protocol ===

Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], [mailto:adnan.rashid@poliba.it Adnan Rashid].

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 help merging the code (if it's not already merged) and add some features that are not yet considered in the model.

The candidate should outline in the proposal the features that are planned to be added, and a code mockup (or a complete class diagram) for said features.

* ''Required Experience:'' Fundamentals of IPv6 addressing, C++ programming.
* ''Bonus Experience:'' Familiarity with 6LoWPAN and 6LoWPAN-ND
* ''Interests:'' IPv6 and IoT networks
* ''Difficulty:'' Easy.
* ''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]
** https://gitlab.com/jieqiboh5836/ns-3-dev/-/tree/6LoWPAN-ND-P1
** https://gitlab.com/jieqiboh5836/ns-3-dev/-/tree/6LoWPAN-ND-P2

===OLLA Link Adaptation for 5G-LENA===

Mentors: [mailto:bbojovic@cttc.es Biljana Bojovic], [mailto:tomh@tomh.org Tom Henderson], [mailto:gcarvalho@cttc.es Gabriel Ferreira], [mailto:slagen@cttc.es Sandra Lagen]

This project would focus on improving the realism of the CTTC 5G-LENA by implementing Outer Loop Link Adaptation (OLLA) in the scheduling/link adaptation workflow. In the current baseline, MCS selection is driven by CQI (or SINR-to-CQI mapping) without an outer-loop correction. OLLA is commonly used to track a target BLER by updating an SINR (or CQI) offset based on HARQ ACK/NACK feedback, leading to more stable and realistic link adaptation behavior under varying channel conditions. This project should include this adaptation for the DL and for the UL, integrated in a scheduler-agnostic way so multiple NR schedulers can reuse it with minimal duplication.

In addition, the project would include a performance evaluation:

*comparing the new OLLA-enabled behavior against the current baseline and across multiple representative existing NR schedulers.
*the evaluation should consider throughput, latency, and achieved BLER, including how closely the achieved BLER tracks the configured target.
*the evaluation of the responsiveness to channel condition changes (convergence speed, stability/oscillation behavior).
*the sensitivity to the CQI update frequency and to user data rate / traffic load (how ACK/NACK rate affects convergence).

Additional topics/work items that could be considered if feasible:

*More advanced OLLA algorithms.
*Calibration guidance and/or comparison against published OLLA configurations (when reference data is available).
*Extensions beyond MCS selection (e.g., rank adaptation). This should be relatively easy in the uplink, but for the downlink some advanced mechanism could be investigated and potentially, AI-based approach could be considered.

For starters, we would suggest adding the CTTC 5G-LENA (nr module) to ns-3 (as a module in the contrib/ directory), building and running the NR examples, and becoming familiar with the current scheduler, HARQ feedback flow, CQI/MCS selection, and TBS computation. 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.

*Required Experience: C++ programming, understanding of 5G NR MAC concepts (scheduling, CQI/MCS, HARQ), wireless networking fundamentals
*Interests: 5G NR simulations, scheduling, link adaptation, performance evaluation
*Difficulty: Medium
*Project size: 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.

=== Enabling 5G NR examples visualization ===

Mentors: [mailto:aashtari@cttc.es Amir Ashtari Gargari], [mailto:gcarvalho@cttc.es Gabriel Ferreira], [mailto:bbojovic@cttc.es Biljana Bojovic] and [mailto:kkoutlia@cttc.es Katerina Koutlia]

The main idea of this project is to allow easier visualization of 5G NR examples by integrating the NR module with some ns-3 visualization tools like NetAnim, or by implementing a kind of web-based visualization, e.g., through Jupyter notebook. The new feature should allow the visualization of already existing traces, visualization of topology, or even some new relevant simulation aspects could be considered. The idea is that users better understand how the metrics collection works, and how changing parameters can affect simulation results. In this project, we are open to other ideas on how to implement visualizations. An example scenario is to have e.g. the handover scenario and then be able to see while the UEs are moving and performing handover how their performance metrics vary.

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.
* Recommended reading: Please read this thread in the ns-3 developers list: [https://groups.google.com/g/ns-developers/c/xGCOIAuTYs8/m/yhzpGJkYAwAJ?utm_medium=email&utm_source=footer UI "Designer" for NS3 Based Visual Scripting].

=== AODVv2 Protocol enhancements ===

Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], [TBD].

ns-3 contains models for proactive (DSDV and OLSR) and reactive (AODV and DSR) ad hoc routing protocols. AODVv2 is currently an IETF draft, and its implementation in ns-3 is ongoing. This project aims at enhancing the AODVv2 model for ns-3.

In particular the project should address the following points:
# Alignment with the latest drafts,
# Model finalization and testing (in particular for the IPv6 part),
# AODVv2 examples and documentation,
# "External" network routing support.

Collaboration with the draft authors is also highly suggested.

* ''Required Experience:'' Fundamentals of IPv6 addressing, C++ programming.
* ''Bonus Experience:'' Familiarity with AODV implementations in ns-3 and AODVv2
* ''Interests:'' Ad hoc routing
* ''Difficulty:'' Medium.
* ''Recommended reading:''
** [https://www.nsnam.org/docs/models/html/ipv6.html IPv6 model in ns-3]
** [https://www.nsnam.org/docs/models/html/aodv.html AODV model in ns-3]
** [https://gitlab.com/tod97/ns-3-dev/-/tree/aodvv2-icns3-25 AODVv2 model presented at ICNS3-2025]
** [https://datatracker.ietf.org/doc/draft-perkins-manet-aodvv2/05/ Ad Hoc On-demand Distance Vector Version 2 (AODVv2) Routing]

Possible tasks to fulfill the patch requirement:
* [https://gitlab.com/nsnam/ns-3-dev/-/issues/368 Issue #368] - aodv: aodv parameters can be set to "impossible" values

=== Integration of 3GPP Release-19 Features into the ns-3 3GPP Model and 5G-LENA ===

Mentors: [mailto:bbojovic@cttc.es Biljana Bojovic], [mailto:slagen@cttc.es Sandra Lagen]

This project aims to improve the realism and standard alignment of ns-3 3GPP and 5G-LENA by implementing selected 3GPP Release 19 modeling features. The goal is to extend the simulator with updated components reflecting recent 5G-Advanced developments.

Possible contributions include:

* Handheld device antenna placement and orientation models, reflecting realistic UE form-factor constraints and radiation characteristics.
* New channel models introduced in Release-19, such as suburban macro scenarios, including their associated path-loss, shadowing, and spatial consistency characteristics.
* Enhancements to existing propagation or antenna models to better align with recent 3GPP specifications changes.
* Additional Release-19 features relevant to system-level simulation, potentially including improvements to mobility modeling, link abstraction, or scheduler interactions.

The exact feature to be implemented will be selected jointly with the mentors and the contributor based on impact, feasibility, and the contributor's interests. Once the selected feature has been designed and integrated into ns-3 and 5G-LENA, the contributor will also be responsible for:

* develop unit tests
* validation example demonstrating the new capability
* prepare the contribution for integration into ns-3 following coding and review guidelines
* evaluation which may include:
** Validation or calibration against 3GPP reference results.
** Comparison with baseline ns-3 3GPP and 5G-LENA behavior to quantify the impact of the new model.
** Analysis of how the new feature affects system-level metrics, such as throughput, coverage, or interference patterns.

The project will be co-mentored by researchers involved in 3GPP standardization, including industry delegates contributing to the Release 19 process.

* Required Experience: C++ and Python programming, understanding of 5G NR, LTE, and wireless networks
* Interests: 3GPP calibration, 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 work or MRs to ns-3 or the nr module, you can contact us to check whether it is enough for the patch requirement.
* Recommended reading: [https://arxiv.org/pdf/2507.19266 Overview of 3GPP Release 19 Study on Channel Modeling Enhancements to TR 38.901 for 6G]

=== Multi-Band Support and Carrier Selection in 5G-LENA for FR3 CA ===

Mentors: [mailto:bbojovic@cttc.es Biljana Bojovic], [mailto:slagen@cttc.es Sandra Lagen]

This project will extend the CTTC 5G-LENA NR module with initial support for multi-band operation and baseline carrier-selection mechanisms. The implementation is intended to be generic, while the evaluation will focus on FR3 scenarios in the 7-24 GHz range. The work will focus on adding the support needed to configure multiple carriers, implementing baseline UE carrier-selection policies based on simple metrics such as received power, SINR, or load, and on introducing a component carrier manager that enables carrier aggregation across configured carriers.

Expected contributions include:

*support for configuring multiple carriers with band-dependent parameters
*baseline UE carrier-selection policies
*implementation of a component carrier manager to support carrier aggregation
*unit tests for configuration, selection and aggregation, validation scenarios, and example simulations

Example scenarios may include a UE selecting the most suitable carrier as channel conditions change. The evaluation will focus on FR3 use cases, including scenarios relevant to FR3 carrier aggregation.
Evaluation may consider throughput, fairness, coverage, and robustness under different carrier-selection policies.

Possible extensions include load-aware selection strategies and more advanced carrier aggregation policies.

* Required Experience: C++ and Python programming, understanding of 5G NR, LTE, and wireless networks
* Interests: 3GPP calibration, 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 work or MRs to ns-3 or the nr module, you can contact us to check whether it is enough for the patch requirement.
* Recommended reading:
**[https://arxiv.org/pdf/2502.17914 A. Bazzi et al., Upper Mid-Band Spectrum for 6G]
**[https://arxiv.org/pdf/2507.19266 Overview of 3GPP Release 19 Study on Channel Modeling Enhancements to TR 38.901 for 6G]
**[https://arxiv.org/pdf/2310.06425 6G Wireless Communications in 7–24 GHz Band]

=== Spectrum Sharing Support for 5G-LENA and ns-3 ===

Mentors: [mailto:slagen@cttc.es Sandra Lagen], [mailto:bbojovic@cttc.es Biljana Bojovic]

This project will extend the CTTC 5G-LENA NR module with initial support for spectrum sharing mechanisms. The work can build on the existing
[https://gitlab.com/cttc-lena/nr-u NR-U module], upgrading it to the latest 5G-LENA and ns-3 versions and then extending its procedures to better align with 3GPP spectrum-sharing specifications.

Expected steps include:
* upgrade the [https://gitlab.com/cttc-lena/nr-u NR-U module] to the latest 5G-LENA and ns-3
* extend the upgraded module with spectrum sharing support aligned with 3GPP procedures
* update the examples that simulate 5G/Wi-Fi coexistence (by using the new NrChannelHelper)
* write documentation, create an example and tests for spectrum sharing
* prepare the contributions for integration into 5G-LENA and ns-3 following coding and review guidelines

If time permits, we may investigate the integration of the updated module into the 5G-LENA mainline.

* Required Experience: C++ and Python programming, understanding of 5G NR, LTE, and wireless networks
* Interests: spectrum sharing, 3GPP coexistence studies, 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 work or MRs to ns-3 or the nr module, you can contact us to check whether it is enough for the patch requirement.
* Recommended reading:
** [https://arxiv.org/pdf/2211.08956 A Comprehensive Survey on Spectrum Sharing Techniques for 5G/B5G Intelligent Wireless Networks: Opportunities, Challenges and Future Research Directions]
** [https://kar.kent.ac.uk/109199/ NR-U and Wi-Fi Unlicensed Spectrum Sharing: Design Challenges and Solutions]

== Large projects (350 hours) ==

=== Mesh Link Establishment (MLE) protocol ===

Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], [mailto:alramonet@is.tokushima-u.ac.jp Alberto Gallegos Ramonet].

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:''
** [https://datatracker.ietf.org/doc/html/draft-ietf-6lo-mesh-link-establishment MLE draft]
** [https://openthread.io/guides/thread-primer/network-discovery Thread primer]
** [https://www.threadgroup.org/ThreadSpec Thread specifications]

Possible tasks to fulfill the patch requirement:
* TBD, contact the mentors if interested.

===Energy Consumption Modeling and Power-Aware Extensions for 5G-LENA===

Mentors: [mailto:kkoutlia@cttc.es Katerina Koutlia], [mailto:bbojovic@cttc.es Biljana Bojovic], [mailto:mmiozzo@cttc.es Marco Miozzo] and [mailto:aashtari@cttc.es Amir Ashtari Gargari]

This project would add energy consumption modeling to the CTTC 5G-LENA (NR module). While 5G-LENA provides a detailed and validated simulation of the 5G NR protocol stack behavior, it currently lacks energy models for UEs and/or gNBs, limiting research on energy efficiency, green networking, 6G sustainability, and potentially AI-driven power-aware control.
The project would first evaluate reuse of the ns-3 Energy Framework (e.g., EnergySource, DeviceEnergyModel) by defining a clean interface between 5G-LENA and the energy module. If existing models are insufficient, the project would design and implement a 5G-specific device energy model (e.g., NrDeviceEnergyModel) and connect it to relevant 5G-LENA state/procedure events.
For starters, we would suggest adding the CTTC 5G-LENA (nr module) to ns-3 (as a module in the contrib/ directory), building and running the NR examples, and studying the Energy Framework integration patterns. Documentation is available here: https://5g-lena.cttc.es/. Tutorial video: https://acmse.net/2021/tutorials-offered/#tut-work03.

Scope (expected deliverables):
*Energy consumption accounting for UEs and/or gNBs
*Per-state (and if feasible per-procedure) modeling, e.g.
**gNB: idle/active/sleep, TX/RX, processing; dependence on bandwidth/PRBs, TX power, MIMO layers/streams/RF chains, load
**UE: TX/RX, measurements, CSI-RS/SRS activity, beamforming-related processing, handover
*Tracing, example(s), and documentation

Optional (time permitting): a simple energy-aware scheduling extension to explore QoS trade-offs (e.g., energy-per-bit or energy-aware MIMO under GBR)

*Required Experience: C++ programming, wireless networking fundamentals (energy/state-machine modeling is a plus)
*Interests: 5G NR simulations, energy efficiency, green networking, 6G sustainability
*Difficulty: Medium
*Project size: 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 integration with ns-3-ai ===

Mentors: [mailto:kkoutlia@cttc.es Katerina Koutlia], [mailto:gcarvalho@cttc.es Gabriel Ferreira], [mailto:aashtari@cttc.es Amir Ashtari Gargari] and [mailto:bbojovic@cttc.es Biljana Bojovic]

The objective of this project is to integrate the ns-3 5G NR module with [https://apps.nsnam.org/app/ns3-ai/ ns-3-ai]. In GSoC 2024 we had a project in which 5G NR was integrated with [https://www.nsnam.org/wiki/GSOC2024RLUsability5G ns-3 gym]. While ns-3 gym is a popular ns-3 module for AI, it is limited to the application of reinforcement learning techniques in networking research. On the other hand, ns-3-ai module provides a more general solution that enables the data interaction between ns-3 and other Python-based AI frameworks, like [https://www.tensorflow.org/api_docs/cc Tensorflow C++ APIs] and [https://pytorch.org/cppdocs/ PyTorch C++ APIs], which opens the door to use different machine learning-based techniques in 5G NR models. The correct functioning of the integration should be tested, and documented, and a fully working example using ns-3-ai should be provided. The contributor can propose a use-case scenario for matching learning. One option is to use it for MAC scheduling, but it could be used for other 5G related research problems, and the contributor is encouraged to propose the use case of his/her interest.

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.
* 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.

=== Linux-like CAKE queue discipline for ns-3 ===

Mentors: [mailto:tahiliani.nitk@gmail.com Mohit P. Tahiliani]

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.

* ''Required Experience:'' Familiarity with queue disciplines, TCP and C++ programming.
* ''Bonus Experience:'' Familiarity with CAKE framework in Linux 4.19
* ''Interests:'' Active Queue Management, Packet scheduling and TCP.
* ''Difficulty:'' Medium to Hard
* ''Recommended reading:''
** [https://arxiv.org/pdf/1804.07617.pdf Piece of CAKE: A Comprehensive Queue Management Solution for Home Gateways]
** [https://lwn.net/Articles/758353/ Let them run CAKE]
** [https://www.nsnam.org/docs/models/html/queue-discs.html Queue disciplines in ns-3]

=== Switched Ethernet ===

Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], TBD.

The current ns-3 models for wired connections are fine for simple networks, but the lack of a switched Ethernet model is a limitation in some cases.

The goal of the idea is to create, test, and document a Switched Ethernet model, able to simulate (at least) 1, 10, and 40 GbE links and model for a switch.

The model of the NetDevice and Channel shall take into account the link delays and errors, similarly to what is done by the point-to-point model. Futhermore, it should be able to set the link speed and if it is full-duplex or half-duplex. Additional support for flow control is a bonus, but not strictly required. Link speed auto-negotiation is not considered to be interesting.

The model for the switch should be modular (i.e., allowing the development of different switch types), and include auto-learning of I/O ports based on the MAC address, i.e., have a MAC/port table, and a basic store-and-forward operation. Features like advanced I/O buffer handling and ARP/NDP spoofing detection are not a priority and shall be left for future implementations.

The model should consider the future implementaion of algorithms like VLANs (IEEE 802.1Q, 802.1ad), and the Spanning Tree Protocol (IEEE 802.1D, 802.1w, and 802.1s). Their implementaion is not required, but the model design should allow their development.

* ''Required Experience:'' Fundamentals of Ethernet sitched networking, C++ programming.
* ''Interests:'' Ethernet networks and switched data networks.
* ''Difficulty:'' Medium.
* ''Recommended reading:''
** [https://codereview.appspot.com/5615049/ Basic implementation (very old)]
** [https://gitlab.com/nsnam/ns-3-dev/-/merge_requests/431 Full-duplex CSMA, somehow related]
** [https://tcipg.org/sites/default/files/papers/2010_Jin_Nicol_Caesar.pdf Paper on gigabit Ethernet switch models for simulation]

Possible tasks to fulfill the patch requirement:
* TBD, contact the mentors if interested.

GSOC2026Projects

2026-03-16T10:32:03Z

Biljana: /* Multi-Band Support and Carrier Selection in 5G-LENA for FR3 CA */

{{TOC}}

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

* [https://developers.google.com/open-source/gsoc/faq GSoC Frequently Asked Questions]
* [[GSOC2026ContributorGuide | ns-3's 2026 GSoC Contributor guide]]
* [https://developers.google.com/open-source/gsoc/resources/guide GSoC contributor/student guide (not ns-3 specific)]
* [[GSOC2025ApplicationTemplate | 2026 GSoC Contributor application template]]
* [[GSOCMentorGuide | ns-3's GSoC Mentor guide]]
* [https://archive.flossmanuals.net/gsocmentoring/index.html GSoC Mentor guide (not ns-3 specific)]
* [[GSOCSelectionProcess | GSoC Contributor Selection Process]]
* ''Get in contact with the ns-3 team'': [https://groups.google.com/g/ns-developers 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-25. 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 [mailto:tpecorella@mac.com Tommaso Pecorella] and [mailto:tahiliani.nitk@gmail.com Mohit P. Tahiliani]; contact them with any questions. They also hang out on [https://ns-3.zulipchat.com 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 [https://developers.google.com/open-source/gsoc/resources/guide GSoC contributor guide].
* Read [[GSOC2026ContributorGuide |ns-3's 2026 GSoC contributor guide]]
* 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.
* Once it is posted, look through the [[GSOC2024ApplicationTemplate |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 2026, 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 2026. 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 suggests 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>
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.
</blockquote>

=== Patch requirement guidelines ===

In past years, we have asked applicants to submit a patch related to an open issue or a suggested coding exercise. We are undecided at this time whether we will ask for this in 2026; check back later.

=== 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 ===

* [[#Flent Application API in ns-3]] (small size project, 90h)
* [[#Ping and TraverouteV4 enhancements]] (small size project, 90h)
* [[#Internet routing refactory]] (small size project, 90h)
* [[#AODVv2 Protocol enhancements]] (medium size project, 175h)
* [[#Linux-like CAKE queue discipline for ns-3]] (large size project, 350h)
* [[#Switched Ethernet]] (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)

=== 5G NR models enhancements ===

The general idea is to improve the usability of the 5G NR module by adding new examples that help users start building scenario scripts. Also, an interesting improvement could be integration with other modules, like those for AI or visualizations. Here are some project ideas. Depending on the contributor's interest and skills we can adjust these projects' definitions.

* [[#OLLA Link Adaptation and Spec-Compliant TBS Calculation for 5G-LENA]](medium size project, 175h)
* [[#Enabling 5G NR examples visualization]] (medium size project, 175h)
* [[#Energy Consumption Modeling and Power-Aware Extensions for 5G-LENA]](large size project, 250h)
* [[#5G NR module integration with ns-3-ai]] (large size project, 250h)
* [[#Integration of 3GPP Release-19 Features into the ns-3 3GPP Model and 5G-LENA]](medium size project, 175h)
* [[#Multi-Band Support and Carrier Selection in 5G-LENA for FR3 CA]](medium size project, 175h)

== Small sized projects (90 hours) ==

=== Flent Application API in ns-3 ===

Mentors: [mailto:tahiliani.nitk@gmail.com Mohit P. Tahiliani]

Flexible Network Tester (Flent) is a network benchmarking tool. It is written in Python and wraps well-known network benchmarking tools (such as netperf and iperf) into aggregate, repeatable tests, such as a number of tests for Bufferbloat. A basic structure for Flent Application API in ns-3 has been developed. It is a wrapper around existing ns-3 applications. This project has four main goals: (1) update this implementation to match the current ns-3-dev, (2) integrate a JSON library properly (for Flent-style result handling) (3) validate correctness of Flent results produced by ns-3, and (4) Add more Flent-style test examples useful for ns-3 users. The goal of this project is to merge the Flent Application API into ns-3 mainline, not the app store.

* ''Required Experience:'' Familiarity with Flent and C++ programming.
* ''Bonus Experience:'' Familiarity with applications supported in ns-3.
* ''Interests:'' Bufferbloat, TCP, AQM algorithms and ECN.
* ''Difficulty:'' Medium.
* ''Recommended Reading:''
** Flexible Network Tester [[https://flent.org/flent-the-flexible-network-tester.pdf Paper]] [[https://flent.org/ Tool]]
** [https://www.nsnam.org/doxygen/d9/dc9/group__applications.html#details Existing Applications in ns-3]
** [https://gitlab.com/tomhenderson/ns-3-dev/-/commits/flent?ref_type=heads Prior work on Flent application API in ns-3]

=== Internet routing refactory ===

Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], [TBD].

Traditionally IP routing tables are organized in tuples {Dst, DstMask, GatewayAddr}, e.g., {10.42.66.0, 255.255.255.0, 169.254.10.1}, plus other flags and data, like the interface to be used.
In ns-3 this is accomplished by storing three separate objects, two Ipv[4,6]Address, and one Ipv[4Mask,6Prefix].

While this is quite simple to implement, this has some notable drawbacks, e.g., the Dst address must be a network address (Dst & ~DstMask == 0), it is not efficient (the mask or prefix could be represented by a simple integer), and more.
In order to improve code readability and consistency between IPv4 and IPv6, !2645 introduces two new classes: Ipv[4,6]NetworkAddress.

The goal is to refactor the existing routing classes, along with Ipv[4,6]RotingTable classes, so that they use the new classes.
The candidate should provide a clear and convincing plan to pursue the above mentioned goal, all while keeping backward compatibility. The APIs of the existing classes must be kept as they are (at most the can be deprecated), and new APIs should be introduced only where strictly necessary.
Another very important requirement will be to break down the work in multiple sub-tasks, so that the merge process can be gradual.

It is not required that the candidate will update the code for all the routing schemes, but the choice of which routing algorithms will be considered during the project must be clear and motivated.

* ''Required Experience:'' Fundamentals of IPv6 addressing and routing, C++ programming.
* ''Interests:'' IPv4 and IPv6 routing
* ''Difficulty:'' Easy.
* ''Recommended reading:''
** [https://gitlab.com/nsnam/ns-3-dev/-/issues/1239 Issue #1239]
** [https://gitlab.com/nsnam/ns-3-dev/-/merge_requests/2645 Merge Request !2645]

Possible tasks to fulfill the patch requirement:
* Use !2645 to modify all or in part the `Rip` protocol.

=== Ping and TraverouteV4 enhancements ===

Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], [TBD].

The Ping and TraverouteV4 ns-3 application have some small limitations.

In particular 2 of them are annoying.
1. Neither Ping nor TracerouteV4 reacts to ICMP errors or informative messages.
2. As the name implies, TracerouteV4 is IPv4-only and can't be used on IPv6.

The goal is to remove the above mentioned limitations, all or in part. A proposal should clearly outline the plan and improvements to the existing code (e.g., the list of the ICMP messages that will be considered), and a clear breakdown of the work. For the TracerouteV4 refactoring to use IPv6 as well, the proposal must consider the Ping implementation as a guideline.

* ''Required Experience:'' Fundamentals of IPv4, IPv6, ICMP, and ICMPv6. C++ programming.
* ''Interests:'' IPv4 and IPv6.
* ''Difficulty:'' Easy.
* ''Recommended reading:''
** [https://gitlab.com/nsnam/ns-3-dev/-/issues/825 Issue #825]

Possible tasks to fulfill the patch requirement:
* MR to have Ping react to one ICMP message.

== Medium sized projects (175 hours) ==

=== 6LoWPAN mesh-under routing enhancements ===

Mentors: [mailto:tommaso.pecorella@unifi.it 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.
Better approaches are possible, e.g., by leveraging some concepts from RFC 7731, by using SNR as a guidance, or by measuring the local network activity.

The candidate should outline the proposed approach, what parts of code are going to be affected, and how they can be enhanced.

* ''Required Experience:'' Fundamentals of IPv6 addressing, C++ programming.
* ''Bonus Experience:'' Familiarity with mesh routing and 6LoWPAN ns-3
* ''Interests:'' IPv6 mesh routing
* ''Difficulty:'' Easy.
* ''Recommended reading:''
** [https://www.nsnam.org/docs/models/html/sixlowpan.html#mesh-under-routing Mesh-under in ns-3 6LoWPAN]
** [https://datatracker.ietf.org/doc/html/rfc7731 RFC 7731]
** [https://meshtastic.org/docs/overview/mesh-algo/ Meshtastic controlled flooding]
** [https://ieeexplore.ieee.org/document/91339 Routing by controlled flooding in communication networks] (if the document can not be accessed, PM the mentors)

Possible tasks to fulfill the patch requirement:
* The current code is hardwired, i.e., the mesh-under routing scheme is embedded into the SixLowPanNetDevice. Propose a patch to decouple it, using a SixLowPanMeshUnderRouting class to determine the "next hop". The behavior of the actual protocol should be unchanged.

=== 6LoWPAN neighbor discovery protocol ===

Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], [mailto:adnan.rashid@poliba.it Adnan Rashid].

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 help merging the code (if it's not already merged) and add some features that are not yet considered in the model.

The candidate should outline in the proposal the features that are planned to be added, and a code mockup (or a complete class diagram) for said features.

* ''Required Experience:'' Fundamentals of IPv6 addressing, C++ programming.
* ''Bonus Experience:'' Familiarity with 6LoWPAN and 6LoWPAN-ND
* ''Interests:'' IPv6 and IoT networks
* ''Difficulty:'' Easy.
* ''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]
** https://gitlab.com/jieqiboh5836/ns-3-dev/-/tree/6LoWPAN-ND-P1
** https://gitlab.com/jieqiboh5836/ns-3-dev/-/tree/6LoWPAN-ND-P2

===OLLA Link Adaptation for 5G-LENA===

Mentors: [mailto:bbojovic@cttc.es Biljana Bojovic], [mailto:tomh@tomh.org Tom Henderson], [mailto:gcarvalho@cttc.es Gabriel Ferreira], [mailto:slagen@cttc.es Sandra Lagen]

This project would focus on improving the realism of the CTTC 5G-LENA by implementing Outer Loop Link Adaptation (OLLA) in the scheduling/link adaptation workflow. In the current baseline, MCS selection is driven by CQI (or SINR-to-CQI mapping) without an outer-loop correction. OLLA is commonly used to track a target BLER by updating an SINR (or CQI) offset based on HARQ ACK/NACK feedback, leading to more stable and realistic link adaptation behavior under varying channel conditions. This project should include this adaptation for the DL and for the UL, integrated in a scheduler-agnostic way so multiple NR schedulers can reuse it with minimal duplication.

In addition, the project would include a performance evaluation:

*comparing the new OLLA-enabled behavior against the current baseline and across multiple representative existing NR schedulers.
*the evaluation should consider throughput, latency, and achieved BLER, including how closely the achieved BLER tracks the configured target.
*the evaluation of the responsiveness to channel condition changes (convergence speed, stability/oscillation behavior).
*the sensitivity to the CQI update frequency and to user data rate / traffic load (how ACK/NACK rate affects convergence).

Additional topics/work items that could be considered if feasible:

*More advanced OLLA algorithms.
*Calibration guidance and/or comparison against published OLLA configurations (when reference data is available).
*Extensions beyond MCS selection (e.g., rank adaptation). This should be relatively easy in the uplink, but for the downlink some advanced mechanism could be investigated and potentially, AI-based approach could be considered.

For starters, we would suggest adding the CTTC 5G-LENA (nr module) to ns-3 (as a module in the contrib/ directory), building and running the NR examples, and becoming familiar with the current scheduler, HARQ feedback flow, CQI/MCS selection, and TBS computation. 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.

*Required Experience: C++ programming, understanding of 5G NR MAC concepts (scheduling, CQI/MCS, HARQ), wireless networking fundamentals
*Interests: 5G NR simulations, scheduling, link adaptation, performance evaluation
*Difficulty: Medium
*Project size: 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.

=== Enabling 5G NR examples visualization ===

Mentors: [mailto:aashtari@cttc.es Amir Ashtari Gargari], [mailto:gcarvalho@cttc.es Gabriel Ferreira], [mailto:bbojovic@cttc.es Biljana Bojovic] and [mailto:kkoutlia@cttc.es Katerina Koutlia]

The main idea of this project is to allow easier visualization of 5G NR examples by integrating the NR module with some ns-3 visualization tools like NetAnim, or by implementing a kind of web-based visualization, e.g., through Jupyter notebook. The new feature should allow the visualization of already existing traces, visualization of topology, or even some new relevant simulation aspects could be considered. The idea is that users better understand how the metrics collection works, and how changing parameters can affect simulation results. In this project, we are open to other ideas on how to implement visualizations. An example scenario is to have e.g. the handover scenario and then be able to see while the UEs are moving and performing handover how their performance metrics vary.

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.
* Recommended reading: Please read this thread in the ns-3 developers list: [https://groups.google.com/g/ns-developers/c/xGCOIAuTYs8/m/yhzpGJkYAwAJ?utm_medium=email&utm_source=footer UI "Designer" for NS3 Based Visual Scripting].

=== AODVv2 Protocol enhancements ===

Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], [TBD].

ns-3 contains models for proactive (DSDV and OLSR) and reactive (AODV and DSR) ad hoc routing protocols. AODVv2 is currently an IETF draft, and its implementation in ns-3 is ongoing. This project aims at enhancing the AODVv2 model for ns-3.

In particular the project should address the following points:
# Alignment with the latest drafts,
# Model finalization and testing (in particular for the IPv6 part),
# AODVv2 examples and documentation,
# "External" network routing support.

Collaboration with the draft authors is also highly suggested.

* ''Required Experience:'' Fundamentals of IPv6 addressing, C++ programming.
* ''Bonus Experience:'' Familiarity with AODV implementations in ns-3 and AODVv2
* ''Interests:'' Ad hoc routing
* ''Difficulty:'' Medium.
* ''Recommended reading:''
** [https://www.nsnam.org/docs/models/html/ipv6.html IPv6 model in ns-3]
** [https://www.nsnam.org/docs/models/html/aodv.html AODV model in ns-3]
** [https://gitlab.com/tod97/ns-3-dev/-/tree/aodvv2-icns3-25 AODVv2 model presented at ICNS3-2025]
** [https://datatracker.ietf.org/doc/draft-perkins-manet-aodvv2/05/ Ad Hoc On-demand Distance Vector Version 2 (AODVv2) Routing]

Possible tasks to fulfill the patch requirement:
* [https://gitlab.com/nsnam/ns-3-dev/-/issues/368 Issue #368] - aodv: aodv parameters can be set to "impossible" values

=== Integration of 3GPP Release-19 Features into the ns-3 3GPP Model and 5G-LENA ===

Mentors: [mailto:bbojovic@cttc.es Biljana Bojovic], [mailto:slagen@cttc.es Sandra Lagen]

This project aims to improve the realism and standard alignment of ns-3 3GPP and 5G-LENA by implementing selected 3GPP Release 19 modeling features. The goal is to extend the simulator with updated components reflecting recent 5G-Advanced developments.

Possible contributions include:

* Handheld device antenna placement and orientation models, reflecting realistic UE form-factor constraints and radiation characteristics.
* New channel models introduced in Release-19, such as suburban macro scenarios, including their associated path-loss, shadowing, and spatial consistency characteristics.
* Enhancements to existing propagation or antenna models to better align with recent 3GPP specifications changes.
* Additional Release-19 features relevant to system-level simulation, potentially including improvements to mobility modeling, link abstraction, or scheduler interactions.

The exact feature to be implemented will be selected jointly with the mentors and the contributor based on impact, feasibility, and the contributor's interests. Once the selected feature has been designed and integrated into ns-3 and 5G-LENA, the contributor will also be responsible for:

* develop unit tests
* validation example demonstrating the new capability
* prepare the contribution for integration into ns-3 following coding and review guidelines
* evaluation which may include:
** Validation or calibration against 3GPP reference results.
** Comparison with baseline ns-3 3GPP and 5G-LENA behavior to quantify the impact of the new model.
** Analysis of how the new feature affects system-level metrics, such as throughput, coverage, or interference patterns.

The project will be co-mentored by researchers involved in 3GPP standardization, including industry delegates contributing to the Release 19 process.

* Required Experience: C++ and Python programming, understanding of 5G NR, LTE, and wireless networks
* Interests: 3GPP calibration, 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 work or MRs to ns-3 or the nr module, you can contact us to check whether it is enough for the patch requirement.
* Recommended reading: [https://arxiv.org/pdf/2507.19266 Overview of 3GPP Release 19 Study on Channel Modeling Enhancements to TR 38.901 for 6G]

=== Multi-Band Support and Carrier Selection in 5G-LENA for FR3 CA ===

Mentors: [mailto:bbojovic@cttc.es Biljana Bojovic], [mailto:slagen@cttc.es Sandra Lagen]

This project will extend the CTTC 5G-LENA NR module with initial support for multi-band operation and baseline carrier-selection mechanisms. The implementation is intended to be generic, while the evaluation will focus on FR3 scenarios in the 7-24 GHz range. The work will focus on adding the support needed to configure multiple carriers, implementing baseline UE carrier-selection policies based on simple metrics such as received power, SINR, or load, and on introducing a component carrier manager that enables carrier aggregation across configured carriers.

Expected contributions include:

*support for configuring multiple carriers with band-dependent parameters
*baseline UE carrier-selection policies
*implementation of a component carrier manager to support carrier aggregation
*unit tests for configuration, selection and aggregation, validation scenarios, and example simulations

Example scenarios may include a UE selecting the most suitable carrier as channel conditions change. The evaluation will focus on FR3 use cases, including scenarios relevant to FR3 carrier aggregation.
Evaluation may consider throughput, fairness, coverage, and robustness under different carrier-selection policies.

Possible extensions include load-aware selection strategies and more advanced carrier aggregation policies.

* Required Experience: C++ and Python programming, understanding of 5G NR, LTE, and wireless networks
* Interests: 3GPP calibration, 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 work or MRs to ns-3 or the nr module, you can contact us to check whether it is enough for the patch requirement.
* Recommended reading:
**[https://arxiv.org/pdf/2502.17914 A. Bazzi et al., Upper Mid-Band Spectrum for 6G]
**[https://arxiv.org/pdf/2507.19266 Overview of 3GPP Release 19 Study on Channel Modeling Enhancements to TR 38.901 for 6G]
**[https://arxiv.org/pdf/2310.06425 6G Wireless Communications in 7–24 GHz Band]

== Large projects (350 hours) ==

=== Mesh Link Establishment (MLE) protocol ===

Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], [mailto:alramonet@is.tokushima-u.ac.jp Alberto Gallegos Ramonet].

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:''
** [https://datatracker.ietf.org/doc/html/draft-ietf-6lo-mesh-link-establishment MLE draft]
** [https://openthread.io/guides/thread-primer/network-discovery Thread primer]
** [https://www.threadgroup.org/ThreadSpec Thread specifications]

Possible tasks to fulfill the patch requirement:
* TBD, contact the mentors if interested.

===Energy Consumption Modeling and Power-Aware Extensions for 5G-LENA===

Mentors: [mailto:kkoutlia@cttc.es Katerina Koutlia], [mailto:bbojovic@cttc.es Biljana Bojovic], [mailto:mmiozzo@cttc.es Marco Miozzo] and [mailto:aashtari@cttc.es Amir Ashtari Gargari]

This project would add energy consumption modeling to the CTTC 5G-LENA (NR module). While 5G-LENA provides a detailed and validated simulation of the 5G NR protocol stack behavior, it currently lacks energy models for UEs and/or gNBs, limiting research on energy efficiency, green networking, 6G sustainability, and potentially AI-driven power-aware control.
The project would first evaluate reuse of the ns-3 Energy Framework (e.g., EnergySource, DeviceEnergyModel) by defining a clean interface between 5G-LENA and the energy module. If existing models are insufficient, the project would design and implement a 5G-specific device energy model (e.g., NrDeviceEnergyModel) and connect it to relevant 5G-LENA state/procedure events.
For starters, we would suggest adding the CTTC 5G-LENA (nr module) to ns-3 (as a module in the contrib/ directory), building and running the NR examples, and studying the Energy Framework integration patterns. Documentation is available here: https://5g-lena.cttc.es/. Tutorial video: https://acmse.net/2021/tutorials-offered/#tut-work03.

Scope (expected deliverables):
*Energy consumption accounting for UEs and/or gNBs
*Per-state (and if feasible per-procedure) modeling, e.g.
**gNB: idle/active/sleep, TX/RX, processing; dependence on bandwidth/PRBs, TX power, MIMO layers/streams/RF chains, load
**UE: TX/RX, measurements, CSI-RS/SRS activity, beamforming-related processing, handover
*Tracing, example(s), and documentation

Optional (time permitting): a simple energy-aware scheduling extension to explore QoS trade-offs (e.g., energy-per-bit or energy-aware MIMO under GBR)

*Required Experience: C++ programming, wireless networking fundamentals (energy/state-machine modeling is a plus)
*Interests: 5G NR simulations, energy efficiency, green networking, 6G sustainability
*Difficulty: Medium
*Project size: 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 integration with ns-3-ai ===

Mentors: [mailto:kkoutlia@cttc.es Katerina Koutlia], [mailto:gcarvalho@cttc.es Gabriel Ferreira], [mailto:aashtari@cttc.es Amir Ashtari Gargari] and [mailto:bbojovic@cttc.es Biljana Bojovic]

The objective of this project is to integrate the ns-3 5G NR module with [https://apps.nsnam.org/app/ns3-ai/ ns-3-ai]. In GSoC 2024 we had a project in which 5G NR was integrated with [https://www.nsnam.org/wiki/GSOC2024RLUsability5G ns-3 gym]. While ns-3 gym is a popular ns-3 module for AI, it is limited to the application of reinforcement learning techniques in networking research. On the other hand, ns-3-ai module provides a more general solution that enables the data interaction between ns-3 and other Python-based AI frameworks, like [https://www.tensorflow.org/api_docs/cc Tensorflow C++ APIs] and [https://pytorch.org/cppdocs/ PyTorch C++ APIs], which opens the door to use different machine learning-based techniques in 5G NR models. The correct functioning of the integration should be tested, and documented, and a fully working example using ns-3-ai should be provided. The contributor can propose a use-case scenario for matching learning. One option is to use it for MAC scheduling, but it could be used for other 5G related research problems, and the contributor is encouraged to propose the use case of his/her interest.

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.
* 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.

=== Linux-like CAKE queue discipline for ns-3 ===

Mentors: [mailto:tahiliani.nitk@gmail.com Mohit P. Tahiliani]

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.

* ''Required Experience:'' Familiarity with queue disciplines, TCP and C++ programming.
* ''Bonus Experience:'' Familiarity with CAKE framework in Linux 4.19
* ''Interests:'' Active Queue Management, Packet scheduling and TCP.
* ''Difficulty:'' Medium to Hard
* ''Recommended reading:''
** [https://arxiv.org/pdf/1804.07617.pdf Piece of CAKE: A Comprehensive Queue Management Solution for Home Gateways]
** [https://lwn.net/Articles/758353/ Let them run CAKE]
** [https://www.nsnam.org/docs/models/html/queue-discs.html Queue disciplines in ns-3]

=== Switched Ethernet ===

Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], TBD.

The current ns-3 models for wired connections are fine for simple networks, but the lack of a switched Ethernet model is a limitation in some cases.

The goal of the idea is to create, test, and document a Switched Ethernet model, able to simulate (at least) 1, 10, and 40 GbE links and model for a switch.

The model of the NetDevice and Channel shall take into account the link delays and errors, similarly to what is done by the point-to-point model. Futhermore, it should be able to set the link speed and if it is full-duplex or half-duplex. Additional support for flow control is a bonus, but not strictly required. Link speed auto-negotiation is not considered to be interesting.

The model for the switch should be modular (i.e., allowing the development of different switch types), and include auto-learning of I/O ports based on the MAC address, i.e., have a MAC/port table, and a basic store-and-forward operation. Features like advanced I/O buffer handling and ARP/NDP spoofing detection are not a priority and shall be left for future implementations.

The model should consider the future implementaion of algorithms like VLANs (IEEE 802.1Q, 802.1ad), and the Spanning Tree Protocol (IEEE 802.1D, 802.1w, and 802.1s). Their implementaion is not required, but the model design should allow their development.

* ''Required Experience:'' Fundamentals of Ethernet sitched networking, C++ programming.
* ''Interests:'' Ethernet networks and switched data networks.
* ''Difficulty:'' Medium.
* ''Recommended reading:''
** [https://codereview.appspot.com/5615049/ Basic implementation (very old)]
** [https://gitlab.com/nsnam/ns-3-dev/-/merge_requests/431 Full-duplex CSMA, somehow related]
** [https://tcipg.org/sites/default/files/papers/2010_Jin_Nicol_Caesar.pdf Paper on gigabit Ethernet switch models for simulation]

Possible tasks to fulfill the patch requirement:
* TBD, contact the mentors if interested.

GSOC2026Projects

2026-03-16T10:30:10Z

Biljana: /* Initial Multi-Band Support and Carrier Selection in 5G-LENA: An FR3 Carrier Aggregation Use Case */

{{TOC}}

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

* [https://developers.google.com/open-source/gsoc/faq GSoC Frequently Asked Questions]
* [[GSOC2026ContributorGuide | ns-3's 2026 GSoC Contributor guide]]
* [https://developers.google.com/open-source/gsoc/resources/guide GSoC contributor/student guide (not ns-3 specific)]
* [[GSOC2025ApplicationTemplate | 2026 GSoC Contributor application template]]
* [[GSOCMentorGuide | ns-3's GSoC Mentor guide]]
* [https://archive.flossmanuals.net/gsocmentoring/index.html GSoC Mentor guide (not ns-3 specific)]
* [[GSOCSelectionProcess | GSoC Contributor Selection Process]]
* ''Get in contact with the ns-3 team'': [https://groups.google.com/g/ns-developers 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-25. 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 [mailto:tpecorella@mac.com Tommaso Pecorella] and [mailto:tahiliani.nitk@gmail.com Mohit P. Tahiliani]; contact them with any questions. They also hang out on [https://ns-3.zulipchat.com 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 [https://developers.google.com/open-source/gsoc/resources/guide GSoC contributor guide].
* Read [[GSOC2026ContributorGuide |ns-3's 2026 GSoC contributor guide]]
* 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.
* Once it is posted, look through the [[GSOC2024ApplicationTemplate |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 2026, 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 2026. 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 suggests 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>
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.
</blockquote>

=== Patch requirement guidelines ===

In past years, we have asked applicants to submit a patch related to an open issue or a suggested coding exercise. We are undecided at this time whether we will ask for this in 2026; check back later.

=== 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 ===

* [[#Flent Application API in ns-3]] (small size project, 90h)
* [[#Ping and TraverouteV4 enhancements]] (small size project, 90h)
* [[#Internet routing refactory]] (small size project, 90h)
* [[#AODVv2 Protocol enhancements]] (medium size project, 175h)
* [[#Linux-like CAKE queue discipline for ns-3]] (large size project, 350h)
* [[#Switched Ethernet]] (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)

=== 5G NR models enhancements ===

The general idea is to improve the usability of the 5G NR module by adding new examples that help users start building scenario scripts. Also, an interesting improvement could be integration with other modules, like those for AI or visualizations. Here are some project ideas. Depending on the contributor's interest and skills we can adjust these projects' definitions.

* [[#OLLA Link Adaptation and Spec-Compliant TBS Calculation for 5G-LENA]](medium size project, 175h)
* [[#Enabling 5G NR examples visualization]] (medium size project, 175h)
* [[#Energy Consumption Modeling and Power-Aware Extensions for 5G-LENA]](large size project, 250h)
* [[#5G NR module integration with ns-3-ai]] (large size project, 250h)
* [[#Integration of 3GPP Release-19 Features into the ns-3 3GPP Model and 5G-LENA]](medium size project, 175h)
* [[#Multi-Band Support and Carrier Selection in 5G-LENA for FR3 CA]](medium size project, 175h)

== Small sized projects (90 hours) ==

=== Flent Application API in ns-3 ===

Mentors: [mailto:tahiliani.nitk@gmail.com Mohit P. Tahiliani]

Flexible Network Tester (Flent) is a network benchmarking tool. It is written in Python and wraps well-known network benchmarking tools (such as netperf and iperf) into aggregate, repeatable tests, such as a number of tests for Bufferbloat. A basic structure for Flent Application API in ns-3 has been developed. It is a wrapper around existing ns-3 applications. This project has four main goals: (1) update this implementation to match the current ns-3-dev, (2) integrate a JSON library properly (for Flent-style result handling) (3) validate correctness of Flent results produced by ns-3, and (4) Add more Flent-style test examples useful for ns-3 users. The goal of this project is to merge the Flent Application API into ns-3 mainline, not the app store.

* ''Required Experience:'' Familiarity with Flent and C++ programming.
* ''Bonus Experience:'' Familiarity with applications supported in ns-3.
* ''Interests:'' Bufferbloat, TCP, AQM algorithms and ECN.
* ''Difficulty:'' Medium.
* ''Recommended Reading:''
** Flexible Network Tester [[https://flent.org/flent-the-flexible-network-tester.pdf Paper]] [[https://flent.org/ Tool]]
** [https://www.nsnam.org/doxygen/d9/dc9/group__applications.html#details Existing Applications in ns-3]
** [https://gitlab.com/tomhenderson/ns-3-dev/-/commits/flent?ref_type=heads Prior work on Flent application API in ns-3]

=== Internet routing refactory ===

Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], [TBD].

Traditionally IP routing tables are organized in tuples {Dst, DstMask, GatewayAddr}, e.g., {10.42.66.0, 255.255.255.0, 169.254.10.1}, plus other flags and data, like the interface to be used.
In ns-3 this is accomplished by storing three separate objects, two Ipv[4,6]Address, and one Ipv[4Mask,6Prefix].

While this is quite simple to implement, this has some notable drawbacks, e.g., the Dst address must be a network address (Dst & ~DstMask == 0), it is not efficient (the mask or prefix could be represented by a simple integer), and more.
In order to improve code readability and consistency between IPv4 and IPv6, !2645 introduces two new classes: Ipv[4,6]NetworkAddress.

The goal is to refactor the existing routing classes, along with Ipv[4,6]RotingTable classes, so that they use the new classes.
The candidate should provide a clear and convincing plan to pursue the above mentioned goal, all while keeping backward compatibility. The APIs of the existing classes must be kept as they are (at most the can be deprecated), and new APIs should be introduced only where strictly necessary.
Another very important requirement will be to break down the work in multiple sub-tasks, so that the merge process can be gradual.

It is not required that the candidate will update the code for all the routing schemes, but the choice of which routing algorithms will be considered during the project must be clear and motivated.

* ''Required Experience:'' Fundamentals of IPv6 addressing and routing, C++ programming.
* ''Interests:'' IPv4 and IPv6 routing
* ''Difficulty:'' Easy.
* ''Recommended reading:''
** [https://gitlab.com/nsnam/ns-3-dev/-/issues/1239 Issue #1239]
** [https://gitlab.com/nsnam/ns-3-dev/-/merge_requests/2645 Merge Request !2645]

Possible tasks to fulfill the patch requirement:
* Use !2645 to modify all or in part the `Rip` protocol.

=== Ping and TraverouteV4 enhancements ===

Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], [TBD].

The Ping and TraverouteV4 ns-3 application have some small limitations.

In particular 2 of them are annoying.
1. Neither Ping nor TracerouteV4 reacts to ICMP errors or informative messages.
2. As the name implies, TracerouteV4 is IPv4-only and can't be used on IPv6.

The goal is to remove the above mentioned limitations, all or in part. A proposal should clearly outline the plan and improvements to the existing code (e.g., the list of the ICMP messages that will be considered), and a clear breakdown of the work. For the TracerouteV4 refactoring to use IPv6 as well, the proposal must consider the Ping implementation as a guideline.

* ''Required Experience:'' Fundamentals of IPv4, IPv6, ICMP, and ICMPv6. C++ programming.
* ''Interests:'' IPv4 and IPv6.
* ''Difficulty:'' Easy.
* ''Recommended reading:''
** [https://gitlab.com/nsnam/ns-3-dev/-/issues/825 Issue #825]

Possible tasks to fulfill the patch requirement:
* MR to have Ping react to one ICMP message.

== Medium sized projects (175 hours) ==

=== 6LoWPAN mesh-under routing enhancements ===

Mentors: [mailto:tommaso.pecorella@unifi.it 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.
Better approaches are possible, e.g., by leveraging some concepts from RFC 7731, by using SNR as a guidance, or by measuring the local network activity.

The candidate should outline the proposed approach, what parts of code are going to be affected, and how they can be enhanced.

* ''Required Experience:'' Fundamentals of IPv6 addressing, C++ programming.
* ''Bonus Experience:'' Familiarity with mesh routing and 6LoWPAN ns-3
* ''Interests:'' IPv6 mesh routing
* ''Difficulty:'' Easy.
* ''Recommended reading:''
** [https://www.nsnam.org/docs/models/html/sixlowpan.html#mesh-under-routing Mesh-under in ns-3 6LoWPAN]
** [https://datatracker.ietf.org/doc/html/rfc7731 RFC 7731]
** [https://meshtastic.org/docs/overview/mesh-algo/ Meshtastic controlled flooding]
** [https://ieeexplore.ieee.org/document/91339 Routing by controlled flooding in communication networks] (if the document can not be accessed, PM the mentors)

Possible tasks to fulfill the patch requirement:
* The current code is hardwired, i.e., the mesh-under routing scheme is embedded into the SixLowPanNetDevice. Propose a patch to decouple it, using a SixLowPanMeshUnderRouting class to determine the "next hop". The behavior of the actual protocol should be unchanged.

=== 6LoWPAN neighbor discovery protocol ===

Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], [mailto:adnan.rashid@poliba.it Adnan Rashid].

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 help merging the code (if it's not already merged) and add some features that are not yet considered in the model.

The candidate should outline in the proposal the features that are planned to be added, and a code mockup (or a complete class diagram) for said features.

* ''Required Experience:'' Fundamentals of IPv6 addressing, C++ programming.
* ''Bonus Experience:'' Familiarity with 6LoWPAN and 6LoWPAN-ND
* ''Interests:'' IPv6 and IoT networks
* ''Difficulty:'' Easy.
* ''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]
** https://gitlab.com/jieqiboh5836/ns-3-dev/-/tree/6LoWPAN-ND-P1
** https://gitlab.com/jieqiboh5836/ns-3-dev/-/tree/6LoWPAN-ND-P2

===OLLA Link Adaptation for 5G-LENA===

Mentors: [mailto:bbojovic@cttc.es Biljana Bojovic], [mailto:tomh@tomh.org Tom Henderson], [mailto:gcarvalho@cttc.es Gabriel Ferreira], [mailto:slagen@cttc.es Sandra Lagen]

This project would focus on improving the realism of the CTTC 5G-LENA by implementing Outer Loop Link Adaptation (OLLA) in the scheduling/link adaptation workflow. In the current baseline, MCS selection is driven by CQI (or SINR-to-CQI mapping) without an outer-loop correction. OLLA is commonly used to track a target BLER by updating an SINR (or CQI) offset based on HARQ ACK/NACK feedback, leading to more stable and realistic link adaptation behavior under varying channel conditions. This project should include this adaptation for the DL and for the UL, integrated in a scheduler-agnostic way so multiple NR schedulers can reuse it with minimal duplication.

In addition, the project would include a performance evaluation:

*comparing the new OLLA-enabled behavior against the current baseline and across multiple representative existing NR schedulers.
*the evaluation should consider throughput, latency, and achieved BLER, including how closely the achieved BLER tracks the configured target.
*the evaluation of the responsiveness to channel condition changes (convergence speed, stability/oscillation behavior).
*the sensitivity to the CQI update frequency and to user data rate / traffic load (how ACK/NACK rate affects convergence).

Additional topics/work items that could be considered if feasible:

*More advanced OLLA algorithms.
*Calibration guidance and/or comparison against published OLLA configurations (when reference data is available).
*Extensions beyond MCS selection (e.g., rank adaptation). This should be relatively easy in the uplink, but for the downlink some advanced mechanism could be investigated and potentially, AI-based approach could be considered.

For starters, we would suggest adding the CTTC 5G-LENA (nr module) to ns-3 (as a module in the contrib/ directory), building and running the NR examples, and becoming familiar with the current scheduler, HARQ feedback flow, CQI/MCS selection, and TBS computation. 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.

*Required Experience: C++ programming, understanding of 5G NR MAC concepts (scheduling, CQI/MCS, HARQ), wireless networking fundamentals
*Interests: 5G NR simulations, scheduling, link adaptation, performance evaluation
*Difficulty: Medium
*Project size: 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.

=== Enabling 5G NR examples visualization ===

Mentors: [mailto:aashtari@cttc.es Amir Ashtari Gargari], [mailto:gcarvalho@cttc.es Gabriel Ferreira], [mailto:bbojovic@cttc.es Biljana Bojovic] and [mailto:kkoutlia@cttc.es Katerina Koutlia]

The main idea of this project is to allow easier visualization of 5G NR examples by integrating the NR module with some ns-3 visualization tools like NetAnim, or by implementing a kind of web-based visualization, e.g., through Jupyter notebook. The new feature should allow the visualization of already existing traces, visualization of topology, or even some new relevant simulation aspects could be considered. The idea is that users better understand how the metrics collection works, and how changing parameters can affect simulation results. In this project, we are open to other ideas on how to implement visualizations. An example scenario is to have e.g. the handover scenario and then be able to see while the UEs are moving and performing handover how their performance metrics vary.

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.
* Recommended reading: Please read this thread in the ns-3 developers list: [https://groups.google.com/g/ns-developers/c/xGCOIAuTYs8/m/yhzpGJkYAwAJ?utm_medium=email&utm_source=footer UI "Designer" for NS3 Based Visual Scripting].

=== AODVv2 Protocol enhancements ===

Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], [TBD].

ns-3 contains models for proactive (DSDV and OLSR) and reactive (AODV and DSR) ad hoc routing protocols. AODVv2 is currently an IETF draft, and its implementation in ns-3 is ongoing. This project aims at enhancing the AODVv2 model for ns-3.

In particular the project should address the following points:
# Alignment with the latest drafts,
# Model finalization and testing (in particular for the IPv6 part),
# AODVv2 examples and documentation,
# "External" network routing support.

Collaboration with the draft authors is also highly suggested.

* ''Required Experience:'' Fundamentals of IPv6 addressing, C++ programming.
* ''Bonus Experience:'' Familiarity with AODV implementations in ns-3 and AODVv2
* ''Interests:'' Ad hoc routing
* ''Difficulty:'' Medium.
* ''Recommended reading:''
** [https://www.nsnam.org/docs/models/html/ipv6.html IPv6 model in ns-3]
** [https://www.nsnam.org/docs/models/html/aodv.html AODV model in ns-3]
** [https://gitlab.com/tod97/ns-3-dev/-/tree/aodvv2-icns3-25 AODVv2 model presented at ICNS3-2025]
** [https://datatracker.ietf.org/doc/draft-perkins-manet-aodvv2/05/ Ad Hoc On-demand Distance Vector Version 2 (AODVv2) Routing]

Possible tasks to fulfill the patch requirement:
* [https://gitlab.com/nsnam/ns-3-dev/-/issues/368 Issue #368] - aodv: aodv parameters can be set to "impossible" values

=== Integration of 3GPP Release-19 Features into the ns-3 3GPP Model and 5G-LENA ===

Mentors: [mailto:bbojovic@cttc.es Biljana Bojovic], [mailto:slagen@cttc.es Sandra Lagen]

This project aims to improve the realism and standard alignment of ns-3 3GPP and 5G-LENA by implementing selected 3GPP Release 19 modeling features. The goal is to extend the simulator with updated components reflecting recent 5G-Advanced developments.

Possible contributions include:

* Handheld device antenna placement and orientation models, reflecting realistic UE form-factor constraints and radiation characteristics.
* New channel models introduced in Release-19, such as suburban macro scenarios, including their associated path-loss, shadowing, and spatial consistency characteristics.
* Enhancements to existing propagation or antenna models to better align with recent 3GPP specifications changes.
* Additional Release-19 features relevant to system-level simulation, potentially including improvements to mobility modeling, link abstraction, or scheduler interactions.

The exact feature to be implemented will be selected jointly with the mentors and the contributor based on impact, feasibility, and the contributor's interests. Once the selected feature has been designed and integrated into ns-3 and 5G-LENA, the contributor will also be responsible for:

* develop unit tests
* validation example demonstrating the new capability
* prepare the contribution for integration into ns-3 following coding and review guidelines
* evaluation which may include:
** Validation or calibration against 3GPP reference results.
** Comparison with baseline ns-3 3GPP and 5G-LENA behavior to quantify the impact of the new model.
** Analysis of how the new feature affects system-level metrics, such as throughput, coverage, or interference patterns.

The project will be co-mentored by researchers involved in 3GPP standardization, including industry delegates contributing to the Release 19 process.

* Required Experience: C++ and Python programming, understanding of 5G NR, LTE, and wireless networks
* Interests: 3GPP calibration, 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 work or MRs to ns-3 or the nr module, you can contact us to check whether it is enough for the patch requirement.
* Recommended reading: [https://arxiv.org/pdf/2507.19266 Overview of 3GPP Release 19 Study on Channel Modeling Enhancements to TR 38.901 for 6G]

=== Multi-Band Support and Carrier Selection in 5G-LENA for FR3 CA ===

Mentors: [mailto:bbojovic@cttc.es Biljana Bojovic], [mailto:slagen@cttc.es Sandra Lagen]

This project will extend the CTTC 5G-LENA NR module with initial support for multi-band operation and baseline carrier-selection mechanisms. The implementation is intended to be generic, while the evaluation will focus on FR3 scenarios in the 7-24 GHz range. The work will focus on adding the support needed to configure multiple carriers, implementing baseline UE carrier-selection policies based on simple metrics such as received power, SINR, or load, and on introducing a component carrier manager that enables carrier aggregation across configured carriers.

Expected contributions include:

*support for configuring multiple carriers with band-dependent parameters
*baseline UE carrier-selection policies
*implementation of a component carrier manager to support carrier aggregation
*unit tests for configuration, selection and aggregation, validation scenarios, and example simulations

Example scenarios may include a UE selecting the most suitable carrier as channel conditions change. The evaluation will focus on FR3 use cases, including scenarios relevant to FR3 carrier aggregation.
Evaluation may consider throughput, fairness, coverage, and robustness under different carrier-selection policies.

Possible extensions include load-aware selection strategies and more advanced carrier aggregation policies.

* Required Experience: C++ and Python programming, understanding of 5G NR, LTE, and wireless networks
* Interests: 3GPP calibration, 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 work or MRs to ns-3 or the nr module, you can contact us to check whether it is enough for the patch requirement.
* Recommended reading:
**[https://arxiv.org/pdf/2502.17914 A. Bazzi et al., Upper Mid-Band Spectrum for 6G]
**[https://arxiv.org/pdf/2507.19266 Overview of 3GPP Release 19 Study on Channel Modeling Enhancements to TR 38.901 for 6G]
**[https://arxiv.org/abs/2310.06425 6G Wireless Communications in 7–24 GHz Band]

== Large projects (350 hours) ==

=== Mesh Link Establishment (MLE) protocol ===

Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], [mailto:alramonet@is.tokushima-u.ac.jp Alberto Gallegos Ramonet].

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:''
** [https://datatracker.ietf.org/doc/html/draft-ietf-6lo-mesh-link-establishment MLE draft]
** [https://openthread.io/guides/thread-primer/network-discovery Thread primer]
** [https://www.threadgroup.org/ThreadSpec Thread specifications]

Possible tasks to fulfill the patch requirement:
* TBD, contact the mentors if interested.

===Energy Consumption Modeling and Power-Aware Extensions for 5G-LENA===

Mentors: [mailto:kkoutlia@cttc.es Katerina Koutlia], [mailto:bbojovic@cttc.es Biljana Bojovic], [mailto:mmiozzo@cttc.es Marco Miozzo] and [mailto:aashtari@cttc.es Amir Ashtari Gargari]

This project would add energy consumption modeling to the CTTC 5G-LENA (NR module). While 5G-LENA provides a detailed and validated simulation of the 5G NR protocol stack behavior, it currently lacks energy models for UEs and/or gNBs, limiting research on energy efficiency, green networking, 6G sustainability, and potentially AI-driven power-aware control.
The project would first evaluate reuse of the ns-3 Energy Framework (e.g., EnergySource, DeviceEnergyModel) by defining a clean interface between 5G-LENA and the energy module. If existing models are insufficient, the project would design and implement a 5G-specific device energy model (e.g., NrDeviceEnergyModel) and connect it to relevant 5G-LENA state/procedure events.
For starters, we would suggest adding the CTTC 5G-LENA (nr module) to ns-3 (as a module in the contrib/ directory), building and running the NR examples, and studying the Energy Framework integration patterns. Documentation is available here: https://5g-lena.cttc.es/. Tutorial video: https://acmse.net/2021/tutorials-offered/#tut-work03.

Scope (expected deliverables):
*Energy consumption accounting for UEs and/or gNBs
*Per-state (and if feasible per-procedure) modeling, e.g.
**gNB: idle/active/sleep, TX/RX, processing; dependence on bandwidth/PRBs, TX power, MIMO layers/streams/RF chains, load
**UE: TX/RX, measurements, CSI-RS/SRS activity, beamforming-related processing, handover
*Tracing, example(s), and documentation

Optional (time permitting): a simple energy-aware scheduling extension to explore QoS trade-offs (e.g., energy-per-bit or energy-aware MIMO under GBR)

*Required Experience: C++ programming, wireless networking fundamentals (energy/state-machine modeling is a plus)
*Interests: 5G NR simulations, energy efficiency, green networking, 6G sustainability
*Difficulty: Medium
*Project size: 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 integration with ns-3-ai ===

Mentors: [mailto:kkoutlia@cttc.es Katerina Koutlia], [mailto:gcarvalho@cttc.es Gabriel Ferreira], [mailto:aashtari@cttc.es Amir Ashtari Gargari] and [mailto:bbojovic@cttc.es Biljana Bojovic]

The objective of this project is to integrate the ns-3 5G NR module with [https://apps.nsnam.org/app/ns3-ai/ ns-3-ai]. In GSoC 2024 we had a project in which 5G NR was integrated with [https://www.nsnam.org/wiki/GSOC2024RLUsability5G ns-3 gym]. While ns-3 gym is a popular ns-3 module for AI, it is limited to the application of reinforcement learning techniques in networking research. On the other hand, ns-3-ai module provides a more general solution that enables the data interaction between ns-3 and other Python-based AI frameworks, like [https://www.tensorflow.org/api_docs/cc Tensorflow C++ APIs] and [https://pytorch.org/cppdocs/ PyTorch C++ APIs], which opens the door to use different machine learning-based techniques in 5G NR models. The correct functioning of the integration should be tested, and documented, and a fully working example using ns-3-ai should be provided. The contributor can propose a use-case scenario for matching learning. One option is to use it for MAC scheduling, but it could be used for other 5G related research problems, and the contributor is encouraged to propose the use case of his/her interest.

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.
* 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.

=== Linux-like CAKE queue discipline for ns-3 ===

Mentors: [mailto:tahiliani.nitk@gmail.com Mohit P. Tahiliani]

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.

* ''Required Experience:'' Familiarity with queue disciplines, TCP and C++ programming.
* ''Bonus Experience:'' Familiarity with CAKE framework in Linux 4.19
* ''Interests:'' Active Queue Management, Packet scheduling and TCP.
* ''Difficulty:'' Medium to Hard
* ''Recommended reading:''
** [https://arxiv.org/pdf/1804.07617.pdf Piece of CAKE: A Comprehensive Queue Management Solution for Home Gateways]
** [https://lwn.net/Articles/758353/ Let them run CAKE]
** [https://www.nsnam.org/docs/models/html/queue-discs.html Queue disciplines in ns-3]

=== Switched Ethernet ===

Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], TBD.

The current ns-3 models for wired connections are fine for simple networks, but the lack of a switched Ethernet model is a limitation in some cases.

The goal of the idea is to create, test, and document a Switched Ethernet model, able to simulate (at least) 1, 10, and 40 GbE links and model for a switch.

The model of the NetDevice and Channel shall take into account the link delays and errors, similarly to what is done by the point-to-point model. Futhermore, it should be able to set the link speed and if it is full-duplex or half-duplex. Additional support for flow control is a bonus, but not strictly required. Link speed auto-negotiation is not considered to be interesting.

The model for the switch should be modular (i.e., allowing the development of different switch types), and include auto-learning of I/O ports based on the MAC address, i.e., have a MAC/port table, and a basic store-and-forward operation. Features like advanced I/O buffer handling and ARP/NDP spoofing detection are not a priority and shall be left for future implementations.

The model should consider the future implementaion of algorithms like VLANs (IEEE 802.1Q, 802.1ad), and the Spanning Tree Protocol (IEEE 802.1D, 802.1w, and 802.1s). Their implementaion is not required, but the model design should allow their development.

* ''Required Experience:'' Fundamentals of Ethernet sitched networking, C++ programming.
* ''Interests:'' Ethernet networks and switched data networks.
* ''Difficulty:'' Medium.
* ''Recommended reading:''
** [https://codereview.appspot.com/5615049/ Basic implementation (very old)]
** [https://gitlab.com/nsnam/ns-3-dev/-/merge_requests/431 Full-duplex CSMA, somehow related]
** [https://tcipg.org/sites/default/files/papers/2010_Jin_Nicol_Caesar.pdf Paper on gigabit Ethernet switch models for simulation]

Possible tasks to fulfill the patch requirement:
* TBD, contact the mentors if interested.

GSOC2026Projects

2026-03-16T10:29:48Z

Biljana: /* 5G NR models enhancements */

{{TOC}}

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

* [https://developers.google.com/open-source/gsoc/faq GSoC Frequently Asked Questions]
* [[GSOC2026ContributorGuide | ns-3's 2026 GSoC Contributor guide]]
* [https://developers.google.com/open-source/gsoc/resources/guide GSoC contributor/student guide (not ns-3 specific)]
* [[GSOC2025ApplicationTemplate | 2026 GSoC Contributor application template]]
* [[GSOCMentorGuide | ns-3's GSoC Mentor guide]]
* [https://archive.flossmanuals.net/gsocmentoring/index.html GSoC Mentor guide (not ns-3 specific)]
* [[GSOCSelectionProcess | GSoC Contributor Selection Process]]
* ''Get in contact with the ns-3 team'': [https://groups.google.com/g/ns-developers 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-25. 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 [mailto:tpecorella@mac.com Tommaso Pecorella] and [mailto:tahiliani.nitk@gmail.com Mohit P. Tahiliani]; contact them with any questions. They also hang out on [https://ns-3.zulipchat.com 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 [https://developers.google.com/open-source/gsoc/resources/guide GSoC contributor guide].
* Read [[GSOC2026ContributorGuide |ns-3's 2026 GSoC contributor guide]]
* 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.
* Once it is posted, look through the [[GSOC2024ApplicationTemplate |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 2026, 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 2026. 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 suggests 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>
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.
</blockquote>

=== Patch requirement guidelines ===

In past years, we have asked applicants to submit a patch related to an open issue or a suggested coding exercise. We are undecided at this time whether we will ask for this in 2026; check back later.

=== 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 ===

* [[#Flent Application API in ns-3]] (small size project, 90h)
* [[#Ping and TraverouteV4 enhancements]] (small size project, 90h)
* [[#Internet routing refactory]] (small size project, 90h)
* [[#AODVv2 Protocol enhancements]] (medium size project, 175h)
* [[#Linux-like CAKE queue discipline for ns-3]] (large size project, 350h)
* [[#Switched Ethernet]] (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)

=== 5G NR models enhancements ===

The general idea is to improve the usability of the 5G NR module by adding new examples that help users start building scenario scripts. Also, an interesting improvement could be integration with other modules, like those for AI or visualizations. Here are some project ideas. Depending on the contributor's interest and skills we can adjust these projects' definitions.

* [[#OLLA Link Adaptation and Spec-Compliant TBS Calculation for 5G-LENA]](medium size project, 175h)
* [[#Enabling 5G NR examples visualization]] (medium size project, 175h)
* [[#Energy Consumption Modeling and Power-Aware Extensions for 5G-LENA]](large size project, 250h)
* [[#5G NR module integration with ns-3-ai]] (large size project, 250h)
* [[#Integration of 3GPP Release-19 Features into the ns-3 3GPP Model and 5G-LENA]](medium size project, 175h)
* [[#Multi-Band Support and Carrier Selection in 5G-LENA for FR3 CA]](medium size project, 175h)

== Small sized projects (90 hours) ==

=== Flent Application API in ns-3 ===

Mentors: [mailto:tahiliani.nitk@gmail.com Mohit P. Tahiliani]

Flexible Network Tester (Flent) is a network benchmarking tool. It is written in Python and wraps well-known network benchmarking tools (such as netperf and iperf) into aggregate, repeatable tests, such as a number of tests for Bufferbloat. A basic structure for Flent Application API in ns-3 has been developed. It is a wrapper around existing ns-3 applications. This project has four main goals: (1) update this implementation to match the current ns-3-dev, (2) integrate a JSON library properly (for Flent-style result handling) (3) validate correctness of Flent results produced by ns-3, and (4) Add more Flent-style test examples useful for ns-3 users. The goal of this project is to merge the Flent Application API into ns-3 mainline, not the app store.

* ''Required Experience:'' Familiarity with Flent and C++ programming.
* ''Bonus Experience:'' Familiarity with applications supported in ns-3.
* ''Interests:'' Bufferbloat, TCP, AQM algorithms and ECN.
* ''Difficulty:'' Medium.
* ''Recommended Reading:''
** Flexible Network Tester [[https://flent.org/flent-the-flexible-network-tester.pdf Paper]] [[https://flent.org/ Tool]]
** [https://www.nsnam.org/doxygen/d9/dc9/group__applications.html#details Existing Applications in ns-3]
** [https://gitlab.com/tomhenderson/ns-3-dev/-/commits/flent?ref_type=heads Prior work on Flent application API in ns-3]

=== Internet routing refactory ===

Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], [TBD].

Traditionally IP routing tables are organized in tuples {Dst, DstMask, GatewayAddr}, e.g., {10.42.66.0, 255.255.255.0, 169.254.10.1}, plus other flags and data, like the interface to be used.
In ns-3 this is accomplished by storing three separate objects, two Ipv[4,6]Address, and one Ipv[4Mask,6Prefix].

While this is quite simple to implement, this has some notable drawbacks, e.g., the Dst address must be a network address (Dst & ~DstMask == 0), it is not efficient (the mask or prefix could be represented by a simple integer), and more.
In order to improve code readability and consistency between IPv4 and IPv6, !2645 introduces two new classes: Ipv[4,6]NetworkAddress.

The goal is to refactor the existing routing classes, along with Ipv[4,6]RotingTable classes, so that they use the new classes.
The candidate should provide a clear and convincing plan to pursue the above mentioned goal, all while keeping backward compatibility. The APIs of the existing classes must be kept as they are (at most the can be deprecated), and new APIs should be introduced only where strictly necessary.
Another very important requirement will be to break down the work in multiple sub-tasks, so that the merge process can be gradual.

It is not required that the candidate will update the code for all the routing schemes, but the choice of which routing algorithms will be considered during the project must be clear and motivated.

* ''Required Experience:'' Fundamentals of IPv6 addressing and routing, C++ programming.
* ''Interests:'' IPv4 and IPv6 routing
* ''Difficulty:'' Easy.
* ''Recommended reading:''
** [https://gitlab.com/nsnam/ns-3-dev/-/issues/1239 Issue #1239]
** [https://gitlab.com/nsnam/ns-3-dev/-/merge_requests/2645 Merge Request !2645]

Possible tasks to fulfill the patch requirement:
* Use !2645 to modify all or in part the `Rip` protocol.

=== Ping and TraverouteV4 enhancements ===

Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], [TBD].

The Ping and TraverouteV4 ns-3 application have some small limitations.

In particular 2 of them are annoying.
1. Neither Ping nor TracerouteV4 reacts to ICMP errors or informative messages.
2. As the name implies, TracerouteV4 is IPv4-only and can't be used on IPv6.

The goal is to remove the above mentioned limitations, all or in part. A proposal should clearly outline the plan and improvements to the existing code (e.g., the list of the ICMP messages that will be considered), and a clear breakdown of the work. For the TracerouteV4 refactoring to use IPv6 as well, the proposal must consider the Ping implementation as a guideline.

* ''Required Experience:'' Fundamentals of IPv4, IPv6, ICMP, and ICMPv6. C++ programming.
* ''Interests:'' IPv4 and IPv6.
* ''Difficulty:'' Easy.
* ''Recommended reading:''
** [https://gitlab.com/nsnam/ns-3-dev/-/issues/825 Issue #825]

Possible tasks to fulfill the patch requirement:
* MR to have Ping react to one ICMP message.

== Medium sized projects (175 hours) ==

=== 6LoWPAN mesh-under routing enhancements ===

Mentors: [mailto:tommaso.pecorella@unifi.it 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.
Better approaches are possible, e.g., by leveraging some concepts from RFC 7731, by using SNR as a guidance, or by measuring the local network activity.

The candidate should outline the proposed approach, what parts of code are going to be affected, and how they can be enhanced.

* ''Required Experience:'' Fundamentals of IPv6 addressing, C++ programming.
* ''Bonus Experience:'' Familiarity with mesh routing and 6LoWPAN ns-3
* ''Interests:'' IPv6 mesh routing
* ''Difficulty:'' Easy.
* ''Recommended reading:''
** [https://www.nsnam.org/docs/models/html/sixlowpan.html#mesh-under-routing Mesh-under in ns-3 6LoWPAN]
** [https://datatracker.ietf.org/doc/html/rfc7731 RFC 7731]
** [https://meshtastic.org/docs/overview/mesh-algo/ Meshtastic controlled flooding]
** [https://ieeexplore.ieee.org/document/91339 Routing by controlled flooding in communication networks] (if the document can not be accessed, PM the mentors)

Possible tasks to fulfill the patch requirement:
* The current code is hardwired, i.e., the mesh-under routing scheme is embedded into the SixLowPanNetDevice. Propose a patch to decouple it, using a SixLowPanMeshUnderRouting class to determine the "next hop". The behavior of the actual protocol should be unchanged.

=== 6LoWPAN neighbor discovery protocol ===

Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], [mailto:adnan.rashid@poliba.it Adnan Rashid].

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 help merging the code (if it's not already merged) and add some features that are not yet considered in the model.

The candidate should outline in the proposal the features that are planned to be added, and a code mockup (or a complete class diagram) for said features.

* ''Required Experience:'' Fundamentals of IPv6 addressing, C++ programming.
* ''Bonus Experience:'' Familiarity with 6LoWPAN and 6LoWPAN-ND
* ''Interests:'' IPv6 and IoT networks
* ''Difficulty:'' Easy.
* ''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]
** https://gitlab.com/jieqiboh5836/ns-3-dev/-/tree/6LoWPAN-ND-P1
** https://gitlab.com/jieqiboh5836/ns-3-dev/-/tree/6LoWPAN-ND-P2

===OLLA Link Adaptation for 5G-LENA===

Mentors: [mailto:bbojovic@cttc.es Biljana Bojovic], [mailto:tomh@tomh.org Tom Henderson], [mailto:gcarvalho@cttc.es Gabriel Ferreira], [mailto:slagen@cttc.es Sandra Lagen]

This project would focus on improving the realism of the CTTC 5G-LENA by implementing Outer Loop Link Adaptation (OLLA) in the scheduling/link adaptation workflow. In the current baseline, MCS selection is driven by CQI (or SINR-to-CQI mapping) without an outer-loop correction. OLLA is commonly used to track a target BLER by updating an SINR (or CQI) offset based on HARQ ACK/NACK feedback, leading to more stable and realistic link adaptation behavior under varying channel conditions. This project should include this adaptation for the DL and for the UL, integrated in a scheduler-agnostic way so multiple NR schedulers can reuse it with minimal duplication.

In addition, the project would include a performance evaluation:

*comparing the new OLLA-enabled behavior against the current baseline and across multiple representative existing NR schedulers.
*the evaluation should consider throughput, latency, and achieved BLER, including how closely the achieved BLER tracks the configured target.
*the evaluation of the responsiveness to channel condition changes (convergence speed, stability/oscillation behavior).
*the sensitivity to the CQI update frequency and to user data rate / traffic load (how ACK/NACK rate affects convergence).

Additional topics/work items that could be considered if feasible:

*More advanced OLLA algorithms.
*Calibration guidance and/or comparison against published OLLA configurations (when reference data is available).
*Extensions beyond MCS selection (e.g., rank adaptation). This should be relatively easy in the uplink, but for the downlink some advanced mechanism could be investigated and potentially, AI-based approach could be considered.

For starters, we would suggest adding the CTTC 5G-LENA (nr module) to ns-3 (as a module in the contrib/ directory), building and running the NR examples, and becoming familiar with the current scheduler, HARQ feedback flow, CQI/MCS selection, and TBS computation. 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.

*Required Experience: C++ programming, understanding of 5G NR MAC concepts (scheduling, CQI/MCS, HARQ), wireless networking fundamentals
*Interests: 5G NR simulations, scheduling, link adaptation, performance evaluation
*Difficulty: Medium
*Project size: 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.

=== Enabling 5G NR examples visualization ===

Mentors: [mailto:aashtari@cttc.es Amir Ashtari Gargari], [mailto:gcarvalho@cttc.es Gabriel Ferreira], [mailto:bbojovic@cttc.es Biljana Bojovic] and [mailto:kkoutlia@cttc.es Katerina Koutlia]

The main idea of this project is to allow easier visualization of 5G NR examples by integrating the NR module with some ns-3 visualization tools like NetAnim, or by implementing a kind of web-based visualization, e.g., through Jupyter notebook. The new feature should allow the visualization of already existing traces, visualization of topology, or even some new relevant simulation aspects could be considered. The idea is that users better understand how the metrics collection works, and how changing parameters can affect simulation results. In this project, we are open to other ideas on how to implement visualizations. An example scenario is to have e.g. the handover scenario and then be able to see while the UEs are moving and performing handover how their performance metrics vary.

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.
* Recommended reading: Please read this thread in the ns-3 developers list: [https://groups.google.com/g/ns-developers/c/xGCOIAuTYs8/m/yhzpGJkYAwAJ?utm_medium=email&utm_source=footer UI "Designer" for NS3 Based Visual Scripting].

=== AODVv2 Protocol enhancements ===

Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], [TBD].

ns-3 contains models for proactive (DSDV and OLSR) and reactive (AODV and DSR) ad hoc routing protocols. AODVv2 is currently an IETF draft, and its implementation in ns-3 is ongoing. This project aims at enhancing the AODVv2 model for ns-3.

In particular the project should address the following points:
# Alignment with the latest drafts,
# Model finalization and testing (in particular for the IPv6 part),
# AODVv2 examples and documentation,
# "External" network routing support.

Collaboration with the draft authors is also highly suggested.

* ''Required Experience:'' Fundamentals of IPv6 addressing, C++ programming.
* ''Bonus Experience:'' Familiarity with AODV implementations in ns-3 and AODVv2
* ''Interests:'' Ad hoc routing
* ''Difficulty:'' Medium.
* ''Recommended reading:''
** [https://www.nsnam.org/docs/models/html/ipv6.html IPv6 model in ns-3]
** [https://www.nsnam.org/docs/models/html/aodv.html AODV model in ns-3]
** [https://gitlab.com/tod97/ns-3-dev/-/tree/aodvv2-icns3-25 AODVv2 model presented at ICNS3-2025]
** [https://datatracker.ietf.org/doc/draft-perkins-manet-aodvv2/05/ Ad Hoc On-demand Distance Vector Version 2 (AODVv2) Routing]

Possible tasks to fulfill the patch requirement:
* [https://gitlab.com/nsnam/ns-3-dev/-/issues/368 Issue #368] - aodv: aodv parameters can be set to "impossible" values

=== Integration of 3GPP Release-19 Features into the ns-3 3GPP Model and 5G-LENA ===

Mentors: [mailto:bbojovic@cttc.es Biljana Bojovic], [mailto:slagen@cttc.es Sandra Lagen]

This project aims to improve the realism and standard alignment of ns-3 3GPP and 5G-LENA by implementing selected 3GPP Release 19 modeling features. The goal is to extend the simulator with updated components reflecting recent 5G-Advanced developments.

Possible contributions include:

* Handheld device antenna placement and orientation models, reflecting realistic UE form-factor constraints and radiation characteristics.
* New channel models introduced in Release-19, such as suburban macro scenarios, including their associated path-loss, shadowing, and spatial consistency characteristics.
* Enhancements to existing propagation or antenna models to better align with recent 3GPP specifications changes.
* Additional Release-19 features relevant to system-level simulation, potentially including improvements to mobility modeling, link abstraction, or scheduler interactions.

The exact feature to be implemented will be selected jointly with the mentors and the contributor based on impact, feasibility, and the contributor's interests. Once the selected feature has been designed and integrated into ns-3 and 5G-LENA, the contributor will also be responsible for:

* develop unit tests
* validation example demonstrating the new capability
* prepare the contribution for integration into ns-3 following coding and review guidelines
* evaluation which may include:
** Validation or calibration against 3GPP reference results.
** Comparison with baseline ns-3 3GPP and 5G-LENA behavior to quantify the impact of the new model.
** Analysis of how the new feature affects system-level metrics, such as throughput, coverage, or interference patterns.

The project will be co-mentored by researchers involved in 3GPP standardization, including industry delegates contributing to the Release 19 process.

* Required Experience: C++ and Python programming, understanding of 5G NR, LTE, and wireless networks
* Interests: 3GPP calibration, 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 work or MRs to ns-3 or the nr module, you can contact us to check whether it is enough for the patch requirement.
* Recommended reading: [https://arxiv.org/pdf/2507.19266 Overview of 3GPP Release 19 Study on Channel Modeling Enhancements to TR 38.901 for 6G]

=== Initial Multi-Band Support and Carrier Selection in 5G-LENA: An FR3 Carrier Aggregation Use Case ===

Mentors: [mailto:bbojovic@cttc.es Biljana Bojovic], [mailto:slagen@cttc.es Sandra Lagen]

This project will extend the CTTC 5G-LENA NR module with initial support for multi-band operation and baseline carrier-selection mechanisms. The implementation is intended to be generic, while the evaluation will focus on FR3 scenarios in the 7-24 GHz range. The work will focus on adding the support needed to configure multiple carriers, implementing baseline UE carrier-selection policies based on simple metrics such as received power, SINR, or load, and on introducing a component carrier manager that enables carrier aggregation across configured carriers.

Expected contributions include:

*support for configuring multiple carriers with band-dependent parameters
*baseline UE carrier-selection policies
*implementation of a component carrier manager to support carrier aggregation
*unit tests for configuration, selection and aggregation, validation scenarios, and example simulations

Example scenarios may include a UE selecting the most suitable carrier as channel conditions change. The evaluation will focus on FR3 use cases, including scenarios relevant to FR3 carrier aggregation.
Evaluation may consider throughput, fairness, coverage, and robustness under different carrier-selection policies.

Possible extensions include load-aware selection strategies and more advanced carrier aggregation policies.

* Required Experience: C++ and Python programming, understanding of 5G NR, LTE, and wireless networks
* Interests: 3GPP calibration, 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 work or MRs to ns-3 or the nr module, you can contact us to check whether it is enough for the patch requirement.
* Recommended reading:
**[https://arxiv.org/pdf/2502.17914 A. Bazzi et al., Upper Mid-Band Spectrum for 6G]
**[https://arxiv.org/pdf/2507.19266 Overview of 3GPP Release 19 Study on Channel Modeling Enhancements to TR 38.901 for 6G]
**[https://arxiv.org/abs/2310.06425 6G Wireless Communications in 7–24 GHz Band]

== Large projects (350 hours) ==

=== Mesh Link Establishment (MLE) protocol ===

Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], [mailto:alramonet@is.tokushima-u.ac.jp Alberto Gallegos Ramonet].

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:''
** [https://datatracker.ietf.org/doc/html/draft-ietf-6lo-mesh-link-establishment MLE draft]
** [https://openthread.io/guides/thread-primer/network-discovery Thread primer]
** [https://www.threadgroup.org/ThreadSpec Thread specifications]

Possible tasks to fulfill the patch requirement:
* TBD, contact the mentors if interested.

===Energy Consumption Modeling and Power-Aware Extensions for 5G-LENA===

Mentors: [mailto:kkoutlia@cttc.es Katerina Koutlia], [mailto:bbojovic@cttc.es Biljana Bojovic], [mailto:mmiozzo@cttc.es Marco Miozzo] and [mailto:aashtari@cttc.es Amir Ashtari Gargari]

This project would add energy consumption modeling to the CTTC 5G-LENA (NR module). While 5G-LENA provides a detailed and validated simulation of the 5G NR protocol stack behavior, it currently lacks energy models for UEs and/or gNBs, limiting research on energy efficiency, green networking, 6G sustainability, and potentially AI-driven power-aware control.
The project would first evaluate reuse of the ns-3 Energy Framework (e.g., EnergySource, DeviceEnergyModel) by defining a clean interface between 5G-LENA and the energy module. If existing models are insufficient, the project would design and implement a 5G-specific device energy model (e.g., NrDeviceEnergyModel) and connect it to relevant 5G-LENA state/procedure events.
For starters, we would suggest adding the CTTC 5G-LENA (nr module) to ns-3 (as a module in the contrib/ directory), building and running the NR examples, and studying the Energy Framework integration patterns. Documentation is available here: https://5g-lena.cttc.es/. Tutorial video: https://acmse.net/2021/tutorials-offered/#tut-work03.

Scope (expected deliverables):
*Energy consumption accounting for UEs and/or gNBs
*Per-state (and if feasible per-procedure) modeling, e.g.
**gNB: idle/active/sleep, TX/RX, processing; dependence on bandwidth/PRBs, TX power, MIMO layers/streams/RF chains, load
**UE: TX/RX, measurements, CSI-RS/SRS activity, beamforming-related processing, handover
*Tracing, example(s), and documentation

Optional (time permitting): a simple energy-aware scheduling extension to explore QoS trade-offs (e.g., energy-per-bit or energy-aware MIMO under GBR)

*Required Experience: C++ programming, wireless networking fundamentals (energy/state-machine modeling is a plus)
*Interests: 5G NR simulations, energy efficiency, green networking, 6G sustainability
*Difficulty: Medium
*Project size: 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 integration with ns-3-ai ===

Mentors: [mailto:kkoutlia@cttc.es Katerina Koutlia], [mailto:gcarvalho@cttc.es Gabriel Ferreira], [mailto:aashtari@cttc.es Amir Ashtari Gargari] and [mailto:bbojovic@cttc.es Biljana Bojovic]

The objective of this project is to integrate the ns-3 5G NR module with [https://apps.nsnam.org/app/ns3-ai/ ns-3-ai]. In GSoC 2024 we had a project in which 5G NR was integrated with [https://www.nsnam.org/wiki/GSOC2024RLUsability5G ns-3 gym]. While ns-3 gym is a popular ns-3 module for AI, it is limited to the application of reinforcement learning techniques in networking research. On the other hand, ns-3-ai module provides a more general solution that enables the data interaction between ns-3 and other Python-based AI frameworks, like [https://www.tensorflow.org/api_docs/cc Tensorflow C++ APIs] and [https://pytorch.org/cppdocs/ PyTorch C++ APIs], which opens the door to use different machine learning-based techniques in 5G NR models. The correct functioning of the integration should be tested, and documented, and a fully working example using ns-3-ai should be provided. The contributor can propose a use-case scenario for matching learning. One option is to use it for MAC scheduling, but it could be used for other 5G related research problems, and the contributor is encouraged to propose the use case of his/her interest.

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.
* 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.

=== Linux-like CAKE queue discipline for ns-3 ===

Mentors: [mailto:tahiliani.nitk@gmail.com Mohit P. Tahiliani]

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.

* ''Required Experience:'' Familiarity with queue disciplines, TCP and C++ programming.
* ''Bonus Experience:'' Familiarity with CAKE framework in Linux 4.19
* ''Interests:'' Active Queue Management, Packet scheduling and TCP.
* ''Difficulty:'' Medium to Hard
* ''Recommended reading:''
** [https://arxiv.org/pdf/1804.07617.pdf Piece of CAKE: A Comprehensive Queue Management Solution for Home Gateways]
** [https://lwn.net/Articles/758353/ Let them run CAKE]
** [https://www.nsnam.org/docs/models/html/queue-discs.html Queue disciplines in ns-3]

=== Switched Ethernet ===

Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], TBD.

The current ns-3 models for wired connections are fine for simple networks, but the lack of a switched Ethernet model is a limitation in some cases.

The goal of the idea is to create, test, and document a Switched Ethernet model, able to simulate (at least) 1, 10, and 40 GbE links and model for a switch.

The model of the NetDevice and Channel shall take into account the link delays and errors, similarly to what is done by the point-to-point model. Futhermore, it should be able to set the link speed and if it is full-duplex or half-duplex. Additional support for flow control is a bonus, but not strictly required. Link speed auto-negotiation is not considered to be interesting.

The model for the switch should be modular (i.e., allowing the development of different switch types), and include auto-learning of I/O ports based on the MAC address, i.e., have a MAC/port table, and a basic store-and-forward operation. Features like advanced I/O buffer handling and ARP/NDP spoofing detection are not a priority and shall be left for future implementations.

The model should consider the future implementaion of algorithms like VLANs (IEEE 802.1Q, 802.1ad), and the Spanning Tree Protocol (IEEE 802.1D, 802.1w, and 802.1s). Their implementaion is not required, but the model design should allow their development.

* ''Required Experience:'' Fundamentals of Ethernet sitched networking, C++ programming.
* ''Interests:'' Ethernet networks and switched data networks.
* ''Difficulty:'' Medium.
* ''Recommended reading:''
** [https://codereview.appspot.com/5615049/ Basic implementation (very old)]
** [https://gitlab.com/nsnam/ns-3-dev/-/merge_requests/431 Full-duplex CSMA, somehow related]
** [https://tcipg.org/sites/default/files/papers/2010_Jin_Nicol_Caesar.pdf Paper on gigabit Ethernet switch models for simulation]

Possible tasks to fulfill the patch requirement:
* TBD, contact the mentors if interested.

GSOC2026Projects

2026-03-16T10:25:56Z

Biljana: /* Implementing 3GPP Release 19 Modeling Features in ns-3 3GPP and 5G-LENA */

{{TOC}}

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

* [https://developers.google.com/open-source/gsoc/faq GSoC Frequently Asked Questions]
* [[GSOC2026ContributorGuide | ns-3's 2026 GSoC Contributor guide]]
* [https://developers.google.com/open-source/gsoc/resources/guide GSoC contributor/student guide (not ns-3 specific)]
* [[GSOC2025ApplicationTemplate | 2026 GSoC Contributor application template]]
* [[GSOCMentorGuide | ns-3's GSoC Mentor guide]]
* [https://archive.flossmanuals.net/gsocmentoring/index.html GSoC Mentor guide (not ns-3 specific)]
* [[GSOCSelectionProcess | GSoC Contributor Selection Process]]
* ''Get in contact with the ns-3 team'': [https://groups.google.com/g/ns-developers 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-25. 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 [mailto:tpecorella@mac.com Tommaso Pecorella] and [mailto:tahiliani.nitk@gmail.com Mohit P. Tahiliani]; contact them with any questions. They also hang out on [https://ns-3.zulipchat.com 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 [https://developers.google.com/open-source/gsoc/resources/guide GSoC contributor guide].
* Read [[GSOC2026ContributorGuide |ns-3's 2026 GSoC contributor guide]]
* 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.
* Once it is posted, look through the [[GSOC2024ApplicationTemplate |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 2026, 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 2026. 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 suggests 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>
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.
</blockquote>

=== Patch requirement guidelines ===

In past years, we have asked applicants to submit a patch related to an open issue or a suggested coding exercise. We are undecided at this time whether we will ask for this in 2026; check back later.

=== 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 ===

* [[#Flent Application API in ns-3]] (small size project, 90h)
* [[#Ping and TraverouteV4 enhancements]] (small size project, 90h)
* [[#Internet routing refactory]] (small size project, 90h)
* [[#AODVv2 Protocol enhancements]] (medium size project, 175h)
* [[#Linux-like CAKE queue discipline for ns-3]] (large size project, 350h)
* [[#Switched Ethernet]] (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)

=== 5G NR models enhancements ===

The general idea is to improve the usability of the 5G NR module by adding new examples that help users start building scenario scripts. Also, an interesting improvement could be integration with other modules, like those for AI or visualizations. Here are some project ideas. Depending on the contributor's interest and skills we can adjust these projects' definitions.

* [[#OLLA Link Adaptation and Spec-Compliant TBS Calculation for 5G-LENA]](medium size project, 175h)
* [[#Enabling 5G NR examples visualization]] (medium size project, 175h)
* [[#Energy Consumption Modeling and Power-Aware Extensions for 5G-LENA]](large size project, 250h)
* [[#5G NR module integration with ns-3-ai]] (large size project, 250h)
* [[#Integration of 3GPP Release-19 Features into the ns-3 3GPP Model and 5G-LENA]](medium size project, 175h)

== Small sized projects (90 hours) ==

=== Flent Application API in ns-3 ===

Mentors: [mailto:tahiliani.nitk@gmail.com Mohit P. Tahiliani]

Flexible Network Tester (Flent) is a network benchmarking tool. It is written in Python and wraps well-known network benchmarking tools (such as netperf and iperf) into aggregate, repeatable tests, such as a number of tests for Bufferbloat. A basic structure for Flent Application API in ns-3 has been developed. It is a wrapper around existing ns-3 applications. This project has four main goals: (1) update this implementation to match the current ns-3-dev, (2) integrate a JSON library properly (for Flent-style result handling) (3) validate correctness of Flent results produced by ns-3, and (4) Add more Flent-style test examples useful for ns-3 users. The goal of this project is to merge the Flent Application API into ns-3 mainline, not the app store.

* ''Required Experience:'' Familiarity with Flent and C++ programming.
* ''Bonus Experience:'' Familiarity with applications supported in ns-3.
* ''Interests:'' Bufferbloat, TCP, AQM algorithms and ECN.
* ''Difficulty:'' Medium.
* ''Recommended Reading:''
** Flexible Network Tester [[https://flent.org/flent-the-flexible-network-tester.pdf Paper]] [[https://flent.org/ Tool]]
** [https://www.nsnam.org/doxygen/d9/dc9/group__applications.html#details Existing Applications in ns-3]
** [https://gitlab.com/tomhenderson/ns-3-dev/-/commits/flent?ref_type=heads Prior work on Flent application API in ns-3]

=== Internet routing refactory ===

Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], [TBD].

Traditionally IP routing tables are organized in tuples {Dst, DstMask, GatewayAddr}, e.g., {10.42.66.0, 255.255.255.0, 169.254.10.1}, plus other flags and data, like the interface to be used.
In ns-3 this is accomplished by storing three separate objects, two Ipv[4,6]Address, and one Ipv[4Mask,6Prefix].

While this is quite simple to implement, this has some notable drawbacks, e.g., the Dst address must be a network address (Dst & ~DstMask == 0), it is not efficient (the mask or prefix could be represented by a simple integer), and more.
In order to improve code readability and consistency between IPv4 and IPv6, !2645 introduces two new classes: Ipv[4,6]NetworkAddress.

The goal is to refactor the existing routing classes, along with Ipv[4,6]RotingTable classes, so that they use the new classes.
The candidate should provide a clear and convincing plan to pursue the above mentioned goal, all while keeping backward compatibility. The APIs of the existing classes must be kept as they are (at most the can be deprecated), and new APIs should be introduced only where strictly necessary.
Another very important requirement will be to break down the work in multiple sub-tasks, so that the merge process can be gradual.

It is not required that the candidate will update the code for all the routing schemes, but the choice of which routing algorithms will be considered during the project must be clear and motivated.

* ''Required Experience:'' Fundamentals of IPv6 addressing and routing, C++ programming.
* ''Interests:'' IPv4 and IPv6 routing
* ''Difficulty:'' Easy.
* ''Recommended reading:''
** [https://gitlab.com/nsnam/ns-3-dev/-/issues/1239 Issue #1239]
** [https://gitlab.com/nsnam/ns-3-dev/-/merge_requests/2645 Merge Request !2645]

Possible tasks to fulfill the patch requirement:
* Use !2645 to modify all or in part the `Rip` protocol.

=== Ping and TraverouteV4 enhancements ===

Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], [TBD].

The Ping and TraverouteV4 ns-3 application have some small limitations.

In particular 2 of them are annoying.
1. Neither Ping nor TracerouteV4 reacts to ICMP errors or informative messages.
2. As the name implies, TracerouteV4 is IPv4-only and can't be used on IPv6.

The goal is to remove the above mentioned limitations, all or in part. A proposal should clearly outline the plan and improvements to the existing code (e.g., the list of the ICMP messages that will be considered), and a clear breakdown of the work. For the TracerouteV4 refactoring to use IPv6 as well, the proposal must consider the Ping implementation as a guideline.

* ''Required Experience:'' Fundamentals of IPv4, IPv6, ICMP, and ICMPv6. C++ programming.
* ''Interests:'' IPv4 and IPv6.
* ''Difficulty:'' Easy.
* ''Recommended reading:''
** [https://gitlab.com/nsnam/ns-3-dev/-/issues/825 Issue #825]

Possible tasks to fulfill the patch requirement:
* MR to have Ping react to one ICMP message.

== Medium sized projects (175 hours) ==

=== 6LoWPAN mesh-under routing enhancements ===

Mentors: [mailto:tommaso.pecorella@unifi.it 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.
Better approaches are possible, e.g., by leveraging some concepts from RFC 7731, by using SNR as a guidance, or by measuring the local network activity.

The candidate should outline the proposed approach, what parts of code are going to be affected, and how they can be enhanced.

* ''Required Experience:'' Fundamentals of IPv6 addressing, C++ programming.
* ''Bonus Experience:'' Familiarity with mesh routing and 6LoWPAN ns-3
* ''Interests:'' IPv6 mesh routing
* ''Difficulty:'' Easy.
* ''Recommended reading:''
** [https://www.nsnam.org/docs/models/html/sixlowpan.html#mesh-under-routing Mesh-under in ns-3 6LoWPAN]
** [https://datatracker.ietf.org/doc/html/rfc7731 RFC 7731]
** [https://meshtastic.org/docs/overview/mesh-algo/ Meshtastic controlled flooding]
** [https://ieeexplore.ieee.org/document/91339 Routing by controlled flooding in communication networks] (if the document can not be accessed, PM the mentors)

Possible tasks to fulfill the patch requirement:
* The current code is hardwired, i.e., the mesh-under routing scheme is embedded into the SixLowPanNetDevice. Propose a patch to decouple it, using a SixLowPanMeshUnderRouting class to determine the "next hop". The behavior of the actual protocol should be unchanged.

=== 6LoWPAN neighbor discovery protocol ===

Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], [mailto:adnan.rashid@poliba.it Adnan Rashid].

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 help merging the code (if it's not already merged) and add some features that are not yet considered in the model.

The candidate should outline in the proposal the features that are planned to be added, and a code mockup (or a complete class diagram) for said features.

* ''Required Experience:'' Fundamentals of IPv6 addressing, C++ programming.
* ''Bonus Experience:'' Familiarity with 6LoWPAN and 6LoWPAN-ND
* ''Interests:'' IPv6 and IoT networks
* ''Difficulty:'' Easy.
* ''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]
** https://gitlab.com/jieqiboh5836/ns-3-dev/-/tree/6LoWPAN-ND-P1
** https://gitlab.com/jieqiboh5836/ns-3-dev/-/tree/6LoWPAN-ND-P2

===OLLA Link Adaptation for 5G-LENA===

Mentors: [mailto:bbojovic@cttc.es Biljana Bojovic], [mailto:tomh@tomh.org Tom Henderson], [mailto:gcarvalho@cttc.es Gabriel Ferreira], [mailto:slagen@cttc.es Sandra Lagen]

This project would focus on improving the realism of the CTTC 5G-LENA by implementing Outer Loop Link Adaptation (OLLA) in the scheduling/link adaptation workflow. In the current baseline, MCS selection is driven by CQI (or SINR-to-CQI mapping) without an outer-loop correction. OLLA is commonly used to track a target BLER by updating an SINR (or CQI) offset based on HARQ ACK/NACK feedback, leading to more stable and realistic link adaptation behavior under varying channel conditions. This project should include this adaptation for the DL and for the UL, integrated in a scheduler-agnostic way so multiple NR schedulers can reuse it with minimal duplication.

In addition, the project would include a performance evaluation:

*comparing the new OLLA-enabled behavior against the current baseline and across multiple representative existing NR schedulers.
*the evaluation should consider throughput, latency, and achieved BLER, including how closely the achieved BLER tracks the configured target.
*the evaluation of the responsiveness to channel condition changes (convergence speed, stability/oscillation behavior).
*the sensitivity to the CQI update frequency and to user data rate / traffic load (how ACK/NACK rate affects convergence).

Additional topics/work items that could be considered if feasible:

*More advanced OLLA algorithms.
*Calibration guidance and/or comparison against published OLLA configurations (when reference data is available).
*Extensions beyond MCS selection (e.g., rank adaptation). This should be relatively easy in the uplink, but for the downlink some advanced mechanism could be investigated and potentially, AI-based approach could be considered.

For starters, we would suggest adding the CTTC 5G-LENA (nr module) to ns-3 (as a module in the contrib/ directory), building and running the NR examples, and becoming familiar with the current scheduler, HARQ feedback flow, CQI/MCS selection, and TBS computation. 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.

*Required Experience: C++ programming, understanding of 5G NR MAC concepts (scheduling, CQI/MCS, HARQ), wireless networking fundamentals
*Interests: 5G NR simulations, scheduling, link adaptation, performance evaluation
*Difficulty: Medium
*Project size: 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.

=== Enabling 5G NR examples visualization ===

Mentors: [mailto:aashtari@cttc.es Amir Ashtari Gargari], [mailto:gcarvalho@cttc.es Gabriel Ferreira], [mailto:bbojovic@cttc.es Biljana Bojovic] and [mailto:kkoutlia@cttc.es Katerina Koutlia]

The main idea of this project is to allow easier visualization of 5G NR examples by integrating the NR module with some ns-3 visualization tools like NetAnim, or by implementing a kind of web-based visualization, e.g., through Jupyter notebook. The new feature should allow the visualization of already existing traces, visualization of topology, or even some new relevant simulation aspects could be considered. The idea is that users better understand how the metrics collection works, and how changing parameters can affect simulation results. In this project, we are open to other ideas on how to implement visualizations. An example scenario is to have e.g. the handover scenario and then be able to see while the UEs are moving and performing handover how their performance metrics vary.

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.
* Recommended reading: Please read this thread in the ns-3 developers list: [https://groups.google.com/g/ns-developers/c/xGCOIAuTYs8/m/yhzpGJkYAwAJ?utm_medium=email&utm_source=footer UI "Designer" for NS3 Based Visual Scripting].

=== AODVv2 Protocol enhancements ===

Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], [TBD].

ns-3 contains models for proactive (DSDV and OLSR) and reactive (AODV and DSR) ad hoc routing protocols. AODVv2 is currently an IETF draft, and its implementation in ns-3 is ongoing. This project aims at enhancing the AODVv2 model for ns-3.

In particular the project should address the following points:
# Alignment with the latest drafts,
# Model finalization and testing (in particular for the IPv6 part),
# AODVv2 examples and documentation,
# "External" network routing support.

Collaboration with the draft authors is also highly suggested.

* ''Required Experience:'' Fundamentals of IPv6 addressing, C++ programming.
* ''Bonus Experience:'' Familiarity with AODV implementations in ns-3 and AODVv2
* ''Interests:'' Ad hoc routing
* ''Difficulty:'' Medium.
* ''Recommended reading:''
** [https://www.nsnam.org/docs/models/html/ipv6.html IPv6 model in ns-3]
** [https://www.nsnam.org/docs/models/html/aodv.html AODV model in ns-3]
** [https://gitlab.com/tod97/ns-3-dev/-/tree/aodvv2-icns3-25 AODVv2 model presented at ICNS3-2025]
** [https://datatracker.ietf.org/doc/draft-perkins-manet-aodvv2/05/ Ad Hoc On-demand Distance Vector Version 2 (AODVv2) Routing]

Possible tasks to fulfill the patch requirement:
* [https://gitlab.com/nsnam/ns-3-dev/-/issues/368 Issue #368] - aodv: aodv parameters can be set to "impossible" values

=== Integration of 3GPP Release-19 Features into the ns-3 3GPP Model and 5G-LENA ===

Mentors: [mailto:bbojovic@cttc.es Biljana Bojovic], [mailto:slagen@cttc.es Sandra Lagen]

This project aims to improve the realism and standard alignment of ns-3 3GPP and 5G-LENA by implementing selected 3GPP Release 19 modeling features. The goal is to extend the simulator with updated components reflecting recent 5G-Advanced developments.

Possible contributions include:

* Handheld device antenna placement and orientation models, reflecting realistic UE form-factor constraints and radiation characteristics.
* New channel models introduced in Release-19, such as suburban macro scenarios, including their associated path-loss, shadowing, and spatial consistency characteristics.
* Enhancements to existing propagation or antenna models to better align with recent 3GPP specifications changes.
* Additional Release-19 features relevant to system-level simulation, potentially including improvements to mobility modeling, link abstraction, or scheduler interactions.

The exact feature to be implemented will be selected jointly with the mentors and the contributor based on impact, feasibility, and the contributor's interests. Once the selected feature has been designed and integrated into ns-3 and 5G-LENA, the contributor will also be responsible for:

* develop unit tests
* validation example demonstrating the new capability
* prepare the contribution for integration into ns-3 following coding and review guidelines
* evaluation which may include:
** Validation or calibration against 3GPP reference results.
** Comparison with baseline ns-3 3GPP and 5G-LENA behavior to quantify the impact of the new model.
** Analysis of how the new feature affects system-level metrics, such as throughput, coverage, or interference patterns.

The project will be co-mentored by researchers involved in 3GPP standardization, including industry delegates contributing to the Release 19 process.

* Required Experience: C++ and Python programming, understanding of 5G NR, LTE, and wireless networks
* Interests: 3GPP calibration, 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 work or MRs to ns-3 or the nr module, you can contact us to check whether it is enough for the patch requirement.
* Recommended reading: [https://arxiv.org/pdf/2507.19266 Overview of 3GPP Release 19 Study on Channel Modeling Enhancements to TR 38.901 for 6G]

=== Initial Multi-Band Support and Carrier Selection in 5G-LENA: An FR3 Carrier Aggregation Use Case ===

Mentors: [mailto:bbojovic@cttc.es Biljana Bojovic], [mailto:slagen@cttc.es Sandra Lagen]

This project will extend the CTTC 5G-LENA NR module with initial support for multi-band operation and baseline carrier-selection mechanisms. The implementation is intended to be generic, while the evaluation will focus on FR3 scenarios in the 7-24 GHz range. The work will focus on adding the support needed to configure multiple carriers, implementing baseline UE carrier-selection policies based on simple metrics such as received power, SINR, or load, and on introducing a component carrier manager that enables carrier aggregation across configured carriers.

Expected contributions include:

*support for configuring multiple carriers with band-dependent parameters
*baseline UE carrier-selection policies
*implementation of a component carrier manager to support carrier aggregation
*unit tests for configuration, selection and aggregation, validation scenarios, and example simulations

Example scenarios may include a UE selecting the most suitable carrier as channel conditions change. The evaluation will focus on FR3 use cases, including scenarios relevant to FR3 carrier aggregation.
Evaluation may consider throughput, fairness, coverage, and robustness under different carrier-selection policies.

Possible extensions include load-aware selection strategies and more advanced carrier aggregation policies.

* Required Experience: C++ and Python programming, understanding of 5G NR, LTE, and wireless networks
* Interests: 3GPP calibration, 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 work or MRs to ns-3 or the nr module, you can contact us to check whether it is enough for the patch requirement.
* Recommended reading:
**[https://arxiv.org/pdf/2502.17914 A. Bazzi et al., Upper Mid-Band Spectrum for 6G]
**[https://arxiv.org/pdf/2507.19266 Overview of 3GPP Release 19 Study on Channel Modeling Enhancements to TR 38.901 for 6G]
**[https://arxiv.org/abs/2310.06425 6G Wireless Communications in 7–24 GHz Band]

== Large projects (350 hours) ==

=== Mesh Link Establishment (MLE) protocol ===

Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], [mailto:alramonet@is.tokushima-u.ac.jp Alberto Gallegos Ramonet].

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:''
** [https://datatracker.ietf.org/doc/html/draft-ietf-6lo-mesh-link-establishment MLE draft]
** [https://openthread.io/guides/thread-primer/network-discovery Thread primer]
** [https://www.threadgroup.org/ThreadSpec Thread specifications]

Possible tasks to fulfill the patch requirement:
* TBD, contact the mentors if interested.

===Energy Consumption Modeling and Power-Aware Extensions for 5G-LENA===

Mentors: [mailto:kkoutlia@cttc.es Katerina Koutlia], [mailto:bbojovic@cttc.es Biljana Bojovic], [mailto:mmiozzo@cttc.es Marco Miozzo] and [mailto:aashtari@cttc.es Amir Ashtari Gargari]

This project would add energy consumption modeling to the CTTC 5G-LENA (NR module). While 5G-LENA provides a detailed and validated simulation of the 5G NR protocol stack behavior, it currently lacks energy models for UEs and/or gNBs, limiting research on energy efficiency, green networking, 6G sustainability, and potentially AI-driven power-aware control.
The project would first evaluate reuse of the ns-3 Energy Framework (e.g., EnergySource, DeviceEnergyModel) by defining a clean interface between 5G-LENA and the energy module. If existing models are insufficient, the project would design and implement a 5G-specific device energy model (e.g., NrDeviceEnergyModel) and connect it to relevant 5G-LENA state/procedure events.
For starters, we would suggest adding the CTTC 5G-LENA (nr module) to ns-3 (as a module in the contrib/ directory), building and running the NR examples, and studying the Energy Framework integration patterns. Documentation is available here: https://5g-lena.cttc.es/. Tutorial video: https://acmse.net/2021/tutorials-offered/#tut-work03.

Scope (expected deliverables):
*Energy consumption accounting for UEs and/or gNBs
*Per-state (and if feasible per-procedure) modeling, e.g.
**gNB: idle/active/sleep, TX/RX, processing; dependence on bandwidth/PRBs, TX power, MIMO layers/streams/RF chains, load
**UE: TX/RX, measurements, CSI-RS/SRS activity, beamforming-related processing, handover
*Tracing, example(s), and documentation

Optional (time permitting): a simple energy-aware scheduling extension to explore QoS trade-offs (e.g., energy-per-bit or energy-aware MIMO under GBR)

*Required Experience: C++ programming, wireless networking fundamentals (energy/state-machine modeling is a plus)
*Interests: 5G NR simulations, energy efficiency, green networking, 6G sustainability
*Difficulty: Medium
*Project size: 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 integration with ns-3-ai ===

Mentors: [mailto:kkoutlia@cttc.es Katerina Koutlia], [mailto:gcarvalho@cttc.es Gabriel Ferreira], [mailto:aashtari@cttc.es Amir Ashtari Gargari] and [mailto:bbojovic@cttc.es Biljana Bojovic]

The objective of this project is to integrate the ns-3 5G NR module with [https://apps.nsnam.org/app/ns3-ai/ ns-3-ai]. In GSoC 2024 we had a project in which 5G NR was integrated with [https://www.nsnam.org/wiki/GSOC2024RLUsability5G ns-3 gym]. While ns-3 gym is a popular ns-3 module for AI, it is limited to the application of reinforcement learning techniques in networking research. On the other hand, ns-3-ai module provides a more general solution that enables the data interaction between ns-3 and other Python-based AI frameworks, like [https://www.tensorflow.org/api_docs/cc Tensorflow C++ APIs] and [https://pytorch.org/cppdocs/ PyTorch C++ APIs], which opens the door to use different machine learning-based techniques in 5G NR models. The correct functioning of the integration should be tested, and documented, and a fully working example using ns-3-ai should be provided. The contributor can propose a use-case scenario for matching learning. One option is to use it for MAC scheduling, but it could be used for other 5G related research problems, and the contributor is encouraged to propose the use case of his/her interest.

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.
* 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.

=== Linux-like CAKE queue discipline for ns-3 ===

Mentors: [mailto:tahiliani.nitk@gmail.com Mohit P. Tahiliani]

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.

* ''Required Experience:'' Familiarity with queue disciplines, TCP and C++ programming.
* ''Bonus Experience:'' Familiarity with CAKE framework in Linux 4.19
* ''Interests:'' Active Queue Management, Packet scheduling and TCP.
* ''Difficulty:'' Medium to Hard
* ''Recommended reading:''
** [https://arxiv.org/pdf/1804.07617.pdf Piece of CAKE: A Comprehensive Queue Management Solution for Home Gateways]
** [https://lwn.net/Articles/758353/ Let them run CAKE]
** [https://www.nsnam.org/docs/models/html/queue-discs.html Queue disciplines in ns-3]

=== Switched Ethernet ===

Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], TBD.

The current ns-3 models for wired connections are fine for simple networks, but the lack of a switched Ethernet model is a limitation in some cases.

The goal of the idea is to create, test, and document a Switched Ethernet model, able to simulate (at least) 1, 10, and 40 GbE links and model for a switch.

The model of the NetDevice and Channel shall take into account the link delays and errors, similarly to what is done by the point-to-point model. Futhermore, it should be able to set the link speed and if it is full-duplex or half-duplex. Additional support for flow control is a bonus, but not strictly required. Link speed auto-negotiation is not considered to be interesting.

The model for the switch should be modular (i.e., allowing the development of different switch types), and include auto-learning of I/O ports based on the MAC address, i.e., have a MAC/port table, and a basic store-and-forward operation. Features like advanced I/O buffer handling and ARP/NDP spoofing detection are not a priority and shall be left for future implementations.

The model should consider the future implementaion of algorithms like VLANs (IEEE 802.1Q, 802.1ad), and the Spanning Tree Protocol (IEEE 802.1D, 802.1w, and 802.1s). Their implementaion is not required, but the model design should allow their development.

* ''Required Experience:'' Fundamentals of Ethernet sitched networking, C++ programming.
* ''Interests:'' Ethernet networks and switched data networks.
* ''Difficulty:'' Medium.
* ''Recommended reading:''
** [https://codereview.appspot.com/5615049/ Basic implementation (very old)]
** [https://gitlab.com/nsnam/ns-3-dev/-/merge_requests/431 Full-duplex CSMA, somehow related]
** [https://tcipg.org/sites/default/files/papers/2010_Jin_Nicol_Caesar.pdf Paper on gigabit Ethernet switch models for simulation]

Possible tasks to fulfill the patch requirement:
* TBD, contact the mentors if interested.

GSOC2026Projects

2026-03-16T10:25:35Z

Biljana: /* 5G NR models enhancements */

{{TOC}}

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

* [https://developers.google.com/open-source/gsoc/faq GSoC Frequently Asked Questions]
* [[GSOC2026ContributorGuide | ns-3's 2026 GSoC Contributor guide]]
* [https://developers.google.com/open-source/gsoc/resources/guide GSoC contributor/student guide (not ns-3 specific)]
* [[GSOC2025ApplicationTemplate | 2026 GSoC Contributor application template]]
* [[GSOCMentorGuide | ns-3's GSoC Mentor guide]]
* [https://archive.flossmanuals.net/gsocmentoring/index.html GSoC Mentor guide (not ns-3 specific)]
* [[GSOCSelectionProcess | GSoC Contributor Selection Process]]
* ''Get in contact with the ns-3 team'': [https://groups.google.com/g/ns-developers 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-25. 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 [mailto:tpecorella@mac.com Tommaso Pecorella] and [mailto:tahiliani.nitk@gmail.com Mohit P. Tahiliani]; contact them with any questions. They also hang out on [https://ns-3.zulipchat.com 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 [https://developers.google.com/open-source/gsoc/resources/guide GSoC contributor guide].
* Read [[GSOC2026ContributorGuide |ns-3's 2026 GSoC contributor guide]]
* 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.
* Once it is posted, look through the [[GSOC2024ApplicationTemplate |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 2026, 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 2026. 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 suggests 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>
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.
</blockquote>

=== Patch requirement guidelines ===

In past years, we have asked applicants to submit a patch related to an open issue or a suggested coding exercise. We are undecided at this time whether we will ask for this in 2026; check back later.

=== 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 ===

* [[#Flent Application API in ns-3]] (small size project, 90h)
* [[#Ping and TraverouteV4 enhancements]] (small size project, 90h)
* [[#Internet routing refactory]] (small size project, 90h)
* [[#AODVv2 Protocol enhancements]] (medium size project, 175h)
* [[#Linux-like CAKE queue discipline for ns-3]] (large size project, 350h)
* [[#Switched Ethernet]] (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)

=== 5G NR models enhancements ===

The general idea is to improve the usability of the 5G NR module by adding new examples that help users start building scenario scripts. Also, an interesting improvement could be integration with other modules, like those for AI or visualizations. Here are some project ideas. Depending on the contributor's interest and skills we can adjust these projects' definitions.

* [[#OLLA Link Adaptation and Spec-Compliant TBS Calculation for 5G-LENA]](medium size project, 175h)
* [[#Enabling 5G NR examples visualization]] (medium size project, 175h)
* [[#Energy Consumption Modeling and Power-Aware Extensions for 5G-LENA]](large size project, 250h)
* [[#5G NR module integration with ns-3-ai]] (large size project, 250h)
* [[#Integration of 3GPP Release-19 Features into the ns-3 3GPP Model and 5G-LENA]](medium size project, 175h)

== Small sized projects (90 hours) ==

=== Flent Application API in ns-3 ===

Mentors: [mailto:tahiliani.nitk@gmail.com Mohit P. Tahiliani]

Flexible Network Tester (Flent) is a network benchmarking tool. It is written in Python and wraps well-known network benchmarking tools (such as netperf and iperf) into aggregate, repeatable tests, such as a number of tests for Bufferbloat. A basic structure for Flent Application API in ns-3 has been developed. It is a wrapper around existing ns-3 applications. This project has four main goals: (1) update this implementation to match the current ns-3-dev, (2) integrate a JSON library properly (for Flent-style result handling) (3) validate correctness of Flent results produced by ns-3, and (4) Add more Flent-style test examples useful for ns-3 users. The goal of this project is to merge the Flent Application API into ns-3 mainline, not the app store.

* ''Required Experience:'' Familiarity with Flent and C++ programming.
* ''Bonus Experience:'' Familiarity with applications supported in ns-3.
* ''Interests:'' Bufferbloat, TCP, AQM algorithms and ECN.
* ''Difficulty:'' Medium.
* ''Recommended Reading:''
** Flexible Network Tester [[https://flent.org/flent-the-flexible-network-tester.pdf Paper]] [[https://flent.org/ Tool]]
** [https://www.nsnam.org/doxygen/d9/dc9/group__applications.html#details Existing Applications in ns-3]
** [https://gitlab.com/tomhenderson/ns-3-dev/-/commits/flent?ref_type=heads Prior work on Flent application API in ns-3]

=== Internet routing refactory ===

Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], [TBD].

Traditionally IP routing tables are organized in tuples {Dst, DstMask, GatewayAddr}, e.g., {10.42.66.0, 255.255.255.0, 169.254.10.1}, plus other flags and data, like the interface to be used.
In ns-3 this is accomplished by storing three separate objects, two Ipv[4,6]Address, and one Ipv[4Mask,6Prefix].

While this is quite simple to implement, this has some notable drawbacks, e.g., the Dst address must be a network address (Dst & ~DstMask == 0), it is not efficient (the mask or prefix could be represented by a simple integer), and more.
In order to improve code readability and consistency between IPv4 and IPv6, !2645 introduces two new classes: Ipv[4,6]NetworkAddress.

The goal is to refactor the existing routing classes, along with Ipv[4,6]RotingTable classes, so that they use the new classes.
The candidate should provide a clear and convincing plan to pursue the above mentioned goal, all while keeping backward compatibility. The APIs of the existing classes must be kept as they are (at most the can be deprecated), and new APIs should be introduced only where strictly necessary.
Another very important requirement will be to break down the work in multiple sub-tasks, so that the merge process can be gradual.

It is not required that the candidate will update the code for all the routing schemes, but the choice of which routing algorithms will be considered during the project must be clear and motivated.

* ''Required Experience:'' Fundamentals of IPv6 addressing and routing, C++ programming.
* ''Interests:'' IPv4 and IPv6 routing
* ''Difficulty:'' Easy.
* ''Recommended reading:''
** [https://gitlab.com/nsnam/ns-3-dev/-/issues/1239 Issue #1239]
** [https://gitlab.com/nsnam/ns-3-dev/-/merge_requests/2645 Merge Request !2645]

Possible tasks to fulfill the patch requirement:
* Use !2645 to modify all or in part the `Rip` protocol.

=== Ping and TraverouteV4 enhancements ===

Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], [TBD].

The Ping and TraverouteV4 ns-3 application have some small limitations.

In particular 2 of them are annoying.
1. Neither Ping nor TracerouteV4 reacts to ICMP errors or informative messages.
2. As the name implies, TracerouteV4 is IPv4-only and can't be used on IPv6.

The goal is to remove the above mentioned limitations, all or in part. A proposal should clearly outline the plan and improvements to the existing code (e.g., the list of the ICMP messages that will be considered), and a clear breakdown of the work. For the TracerouteV4 refactoring to use IPv6 as well, the proposal must consider the Ping implementation as a guideline.

* ''Required Experience:'' Fundamentals of IPv4, IPv6, ICMP, and ICMPv6. C++ programming.
* ''Interests:'' IPv4 and IPv6.
* ''Difficulty:'' Easy.
* ''Recommended reading:''
** [https://gitlab.com/nsnam/ns-3-dev/-/issues/825 Issue #825]

Possible tasks to fulfill the patch requirement:
* MR to have Ping react to one ICMP message.

== Medium sized projects (175 hours) ==

=== 6LoWPAN mesh-under routing enhancements ===

Mentors: [mailto:tommaso.pecorella@unifi.it 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.
Better approaches are possible, e.g., by leveraging some concepts from RFC 7731, by using SNR as a guidance, or by measuring the local network activity.

The candidate should outline the proposed approach, what parts of code are going to be affected, and how they can be enhanced.

* ''Required Experience:'' Fundamentals of IPv6 addressing, C++ programming.
* ''Bonus Experience:'' Familiarity with mesh routing and 6LoWPAN ns-3
* ''Interests:'' IPv6 mesh routing
* ''Difficulty:'' Easy.
* ''Recommended reading:''
** [https://www.nsnam.org/docs/models/html/sixlowpan.html#mesh-under-routing Mesh-under in ns-3 6LoWPAN]
** [https://datatracker.ietf.org/doc/html/rfc7731 RFC 7731]
** [https://meshtastic.org/docs/overview/mesh-algo/ Meshtastic controlled flooding]
** [https://ieeexplore.ieee.org/document/91339 Routing by controlled flooding in communication networks] (if the document can not be accessed, PM the mentors)

Possible tasks to fulfill the patch requirement:
* The current code is hardwired, i.e., the mesh-under routing scheme is embedded into the SixLowPanNetDevice. Propose a patch to decouple it, using a SixLowPanMeshUnderRouting class to determine the "next hop". The behavior of the actual protocol should be unchanged.

=== 6LoWPAN neighbor discovery protocol ===

Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], [mailto:adnan.rashid@poliba.it Adnan Rashid].

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 help merging the code (if it's not already merged) and add some features that are not yet considered in the model.

The candidate should outline in the proposal the features that are planned to be added, and a code mockup (or a complete class diagram) for said features.

* ''Required Experience:'' Fundamentals of IPv6 addressing, C++ programming.
* ''Bonus Experience:'' Familiarity with 6LoWPAN and 6LoWPAN-ND
* ''Interests:'' IPv6 and IoT networks
* ''Difficulty:'' Easy.
* ''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]
** https://gitlab.com/jieqiboh5836/ns-3-dev/-/tree/6LoWPAN-ND-P1
** https://gitlab.com/jieqiboh5836/ns-3-dev/-/tree/6LoWPAN-ND-P2

===OLLA Link Adaptation for 5G-LENA===

Mentors: [mailto:bbojovic@cttc.es Biljana Bojovic], [mailto:tomh@tomh.org Tom Henderson], [mailto:gcarvalho@cttc.es Gabriel Ferreira], [mailto:slagen@cttc.es Sandra Lagen]

This project would focus on improving the realism of the CTTC 5G-LENA by implementing Outer Loop Link Adaptation (OLLA) in the scheduling/link adaptation workflow. In the current baseline, MCS selection is driven by CQI (or SINR-to-CQI mapping) without an outer-loop correction. OLLA is commonly used to track a target BLER by updating an SINR (or CQI) offset based on HARQ ACK/NACK feedback, leading to more stable and realistic link adaptation behavior under varying channel conditions. This project should include this adaptation for the DL and for the UL, integrated in a scheduler-agnostic way so multiple NR schedulers can reuse it with minimal duplication.

In addition, the project would include a performance evaluation:

*comparing the new OLLA-enabled behavior against the current baseline and across multiple representative existing NR schedulers.
*the evaluation should consider throughput, latency, and achieved BLER, including how closely the achieved BLER tracks the configured target.
*the evaluation of the responsiveness to channel condition changes (convergence speed, stability/oscillation behavior).
*the sensitivity to the CQI update frequency and to user data rate / traffic load (how ACK/NACK rate affects convergence).

Additional topics/work items that could be considered if feasible:

*More advanced OLLA algorithms.
*Calibration guidance and/or comparison against published OLLA configurations (when reference data is available).
*Extensions beyond MCS selection (e.g., rank adaptation). This should be relatively easy in the uplink, but for the downlink some advanced mechanism could be investigated and potentially, AI-based approach could be considered.

For starters, we would suggest adding the CTTC 5G-LENA (nr module) to ns-3 (as a module in the contrib/ directory), building and running the NR examples, and becoming familiar with the current scheduler, HARQ feedback flow, CQI/MCS selection, and TBS computation. 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.

*Required Experience: C++ programming, understanding of 5G NR MAC concepts (scheduling, CQI/MCS, HARQ), wireless networking fundamentals
*Interests: 5G NR simulations, scheduling, link adaptation, performance evaluation
*Difficulty: Medium
*Project size: 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.

=== Enabling 5G NR examples visualization ===

Mentors: [mailto:aashtari@cttc.es Amir Ashtari Gargari], [mailto:gcarvalho@cttc.es Gabriel Ferreira], [mailto:bbojovic@cttc.es Biljana Bojovic] and [mailto:kkoutlia@cttc.es Katerina Koutlia]

The main idea of this project is to allow easier visualization of 5G NR examples by integrating the NR module with some ns-3 visualization tools like NetAnim, or by implementing a kind of web-based visualization, e.g., through Jupyter notebook. The new feature should allow the visualization of already existing traces, visualization of topology, or even some new relevant simulation aspects could be considered. The idea is that users better understand how the metrics collection works, and how changing parameters can affect simulation results. In this project, we are open to other ideas on how to implement visualizations. An example scenario is to have e.g. the handover scenario and then be able to see while the UEs are moving and performing handover how their performance metrics vary.

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.
* Recommended reading: Please read this thread in the ns-3 developers list: [https://groups.google.com/g/ns-developers/c/xGCOIAuTYs8/m/yhzpGJkYAwAJ?utm_medium=email&utm_source=footer UI "Designer" for NS3 Based Visual Scripting].

=== AODVv2 Protocol enhancements ===

Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], [TBD].

ns-3 contains models for proactive (DSDV and OLSR) and reactive (AODV and DSR) ad hoc routing protocols. AODVv2 is currently an IETF draft, and its implementation in ns-3 is ongoing. This project aims at enhancing the AODVv2 model for ns-3.

In particular the project should address the following points:
# Alignment with the latest drafts,
# Model finalization and testing (in particular for the IPv6 part),
# AODVv2 examples and documentation,
# "External" network routing support.

Collaboration with the draft authors is also highly suggested.

* ''Required Experience:'' Fundamentals of IPv6 addressing, C++ programming.
* ''Bonus Experience:'' Familiarity with AODV implementations in ns-3 and AODVv2
* ''Interests:'' Ad hoc routing
* ''Difficulty:'' Medium.
* ''Recommended reading:''
** [https://www.nsnam.org/docs/models/html/ipv6.html IPv6 model in ns-3]
** [https://www.nsnam.org/docs/models/html/aodv.html AODV model in ns-3]
** [https://gitlab.com/tod97/ns-3-dev/-/tree/aodvv2-icns3-25 AODVv2 model presented at ICNS3-2025]
** [https://datatracker.ietf.org/doc/draft-perkins-manet-aodvv2/05/ Ad Hoc On-demand Distance Vector Version 2 (AODVv2) Routing]

Possible tasks to fulfill the patch requirement:
* [https://gitlab.com/nsnam/ns-3-dev/-/issues/368 Issue #368] - aodv: aodv parameters can be set to "impossible" values

=== Implementing 3GPP Release 19 Modeling Features in ns-3 3GPP and 5G-LENA ===

Mentors: [mailto:bbojovic@cttc.es Biljana Bojovic], [mailto:slagen@cttc.es Sandra Lagen]

This project aims to improve the realism and standard alignment of ns-3 3GPP and 5G-LENA by implementing selected 3GPP Release 19 modeling features. The goal is to extend the simulator with updated components reflecting recent 5G-Advanced developments.

Possible contributions include:

* Handheld device antenna placement and orientation models, reflecting realistic UE form-factor constraints and radiation characteristics.
* New channel models introduced in Release-19, such as suburban macro scenarios, including their associated path-loss, shadowing, and spatial consistency characteristics.
* Enhancements to existing propagation or antenna models to better align with recent 3GPP specifications changes.
* Additional Release-19 features relevant to system-level simulation, potentially including improvements to mobility modeling, link abstraction, or scheduler interactions.

The exact feature to be implemented will be selected jointly with the mentors and the contributor based on impact, feasibility, and the contributor's interests. Once the selected feature has been designed and integrated into ns-3 and 5G-LENA, the contributor will also be responsible for:

* develop unit tests
* validation example demonstrating the new capability
* prepare the contribution for integration into ns-3 following coding and review guidelines
* evaluation which may include:
** Validation or calibration against 3GPP reference results.
** Comparison with baseline ns-3 3GPP and 5G-LENA behavior to quantify the impact of the new model.
** Analysis of how the new feature affects system-level metrics, such as throughput, coverage, or interference patterns.

The project will be co-mentored by researchers involved in 3GPP standardization, including industry delegates contributing to the Release 19 process.

* Required Experience: C++ and Python programming, understanding of 5G NR, LTE, and wireless networks
* Interests: 3GPP calibration, 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 work or MRs to ns-3 or the nr module, you can contact us to check whether it is enough for the patch requirement.
* Recommended reading: [https://arxiv.org/pdf/2507.19266 Overview of 3GPP Release 19 Study on Channel Modeling Enhancements to TR 38.901 for 6G]

=== Initial Multi-Band Support and Carrier Selection in 5G-LENA: An FR3 Carrier Aggregation Use Case ===

Mentors: [mailto:bbojovic@cttc.es Biljana Bojovic], [mailto:slagen@cttc.es Sandra Lagen]

This project will extend the CTTC 5G-LENA NR module with initial support for multi-band operation and baseline carrier-selection mechanisms. The implementation is intended to be generic, while the evaluation will focus on FR3 scenarios in the 7-24 GHz range. The work will focus on adding the support needed to configure multiple carriers, implementing baseline UE carrier-selection policies based on simple metrics such as received power, SINR, or load, and on introducing a component carrier manager that enables carrier aggregation across configured carriers.

Expected contributions include:

*support for configuring multiple carriers with band-dependent parameters
*baseline UE carrier-selection policies
*implementation of a component carrier manager to support carrier aggregation
*unit tests for configuration, selection and aggregation, validation scenarios, and example simulations

Example scenarios may include a UE selecting the most suitable carrier as channel conditions change. The evaluation will focus on FR3 use cases, including scenarios relevant to FR3 carrier aggregation.
Evaluation may consider throughput, fairness, coverage, and robustness under different carrier-selection policies.

Possible extensions include load-aware selection strategies and more advanced carrier aggregation policies.

* Required Experience: C++ and Python programming, understanding of 5G NR, LTE, and wireless networks
* Interests: 3GPP calibration, 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 work or MRs to ns-3 or the nr module, you can contact us to check whether it is enough for the patch requirement.
* Recommended reading:
**[https://arxiv.org/pdf/2502.17914 A. Bazzi et al., Upper Mid-Band Spectrum for 6G]
**[https://arxiv.org/pdf/2507.19266 Overview of 3GPP Release 19 Study on Channel Modeling Enhancements to TR 38.901 for 6G]
**[https://arxiv.org/abs/2310.06425 6G Wireless Communications in 7–24 GHz Band]

== Large projects (350 hours) ==

=== Mesh Link Establishment (MLE) protocol ===

Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], [mailto:alramonet@is.tokushima-u.ac.jp Alberto Gallegos Ramonet].

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:''
** [https://datatracker.ietf.org/doc/html/draft-ietf-6lo-mesh-link-establishment MLE draft]
** [https://openthread.io/guides/thread-primer/network-discovery Thread primer]
** [https://www.threadgroup.org/ThreadSpec Thread specifications]

Possible tasks to fulfill the patch requirement:
* TBD, contact the mentors if interested.

===Energy Consumption Modeling and Power-Aware Extensions for 5G-LENA===

Mentors: [mailto:kkoutlia@cttc.es Katerina Koutlia], [mailto:bbojovic@cttc.es Biljana Bojovic], [mailto:mmiozzo@cttc.es Marco Miozzo] and [mailto:aashtari@cttc.es Amir Ashtari Gargari]

This project would add energy consumption modeling to the CTTC 5G-LENA (NR module). While 5G-LENA provides a detailed and validated simulation of the 5G NR protocol stack behavior, it currently lacks energy models for UEs and/or gNBs, limiting research on energy efficiency, green networking, 6G sustainability, and potentially AI-driven power-aware control.
The project would first evaluate reuse of the ns-3 Energy Framework (e.g., EnergySource, DeviceEnergyModel) by defining a clean interface between 5G-LENA and the energy module. If existing models are insufficient, the project would design and implement a 5G-specific device energy model (e.g., NrDeviceEnergyModel) and connect it to relevant 5G-LENA state/procedure events.
For starters, we would suggest adding the CTTC 5G-LENA (nr module) to ns-3 (as a module in the contrib/ directory), building and running the NR examples, and studying the Energy Framework integration patterns. Documentation is available here: https://5g-lena.cttc.es/. Tutorial video: https://acmse.net/2021/tutorials-offered/#tut-work03.

Scope (expected deliverables):
*Energy consumption accounting for UEs and/or gNBs
*Per-state (and if feasible per-procedure) modeling, e.g.
**gNB: idle/active/sleep, TX/RX, processing; dependence on bandwidth/PRBs, TX power, MIMO layers/streams/RF chains, load
**UE: TX/RX, measurements, CSI-RS/SRS activity, beamforming-related processing, handover
*Tracing, example(s), and documentation

Optional (time permitting): a simple energy-aware scheduling extension to explore QoS trade-offs (e.g., energy-per-bit or energy-aware MIMO under GBR)

*Required Experience: C++ programming, wireless networking fundamentals (energy/state-machine modeling is a plus)
*Interests: 5G NR simulations, energy efficiency, green networking, 6G sustainability
*Difficulty: Medium
*Project size: 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 integration with ns-3-ai ===

Mentors: [mailto:kkoutlia@cttc.es Katerina Koutlia], [mailto:gcarvalho@cttc.es Gabriel Ferreira], [mailto:aashtari@cttc.es Amir Ashtari Gargari] and [mailto:bbojovic@cttc.es Biljana Bojovic]

The objective of this project is to integrate the ns-3 5G NR module with [https://apps.nsnam.org/app/ns3-ai/ ns-3-ai]. In GSoC 2024 we had a project in which 5G NR was integrated with [https://www.nsnam.org/wiki/GSOC2024RLUsability5G ns-3 gym]. While ns-3 gym is a popular ns-3 module for AI, it is limited to the application of reinforcement learning techniques in networking research. On the other hand, ns-3-ai module provides a more general solution that enables the data interaction between ns-3 and other Python-based AI frameworks, like [https://www.tensorflow.org/api_docs/cc Tensorflow C++ APIs] and [https://pytorch.org/cppdocs/ PyTorch C++ APIs], which opens the door to use different machine learning-based techniques in 5G NR models. The correct functioning of the integration should be tested, and documented, and a fully working example using ns-3-ai should be provided. The contributor can propose a use-case scenario for matching learning. One option is to use it for MAC scheduling, but it could be used for other 5G related research problems, and the contributor is encouraged to propose the use case of his/her interest.

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.
* 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.

=== Linux-like CAKE queue discipline for ns-3 ===

Mentors: [mailto:tahiliani.nitk@gmail.com Mohit P. Tahiliani]

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.

* ''Required Experience:'' Familiarity with queue disciplines, TCP and C++ programming.
* ''Bonus Experience:'' Familiarity with CAKE framework in Linux 4.19
* ''Interests:'' Active Queue Management, Packet scheduling and TCP.
* ''Difficulty:'' Medium to Hard
* ''Recommended reading:''
** [https://arxiv.org/pdf/1804.07617.pdf Piece of CAKE: A Comprehensive Queue Management Solution for Home Gateways]
** [https://lwn.net/Articles/758353/ Let them run CAKE]
** [https://www.nsnam.org/docs/models/html/queue-discs.html Queue disciplines in ns-3]

=== Switched Ethernet ===

Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], TBD.

The current ns-3 models for wired connections are fine for simple networks, but the lack of a switched Ethernet model is a limitation in some cases.

The goal of the idea is to create, test, and document a Switched Ethernet model, able to simulate (at least) 1, 10, and 40 GbE links and model for a switch.

The model of the NetDevice and Channel shall take into account the link delays and errors, similarly to what is done by the point-to-point model. Futhermore, it should be able to set the link speed and if it is full-duplex or half-duplex. Additional support for flow control is a bonus, but not strictly required. Link speed auto-negotiation is not considered to be interesting.

The model for the switch should be modular (i.e., allowing the development of different switch types), and include auto-learning of I/O ports based on the MAC address, i.e., have a MAC/port table, and a basic store-and-forward operation. Features like advanced I/O buffer handling and ARP/NDP spoofing detection are not a priority and shall be left for future implementations.

The model should consider the future implementaion of algorithms like VLANs (IEEE 802.1Q, 802.1ad), and the Spanning Tree Protocol (IEEE 802.1D, 802.1w, and 802.1s). Their implementaion is not required, but the model design should allow their development.

* ''Required Experience:'' Fundamentals of Ethernet sitched networking, C++ programming.
* ''Interests:'' Ethernet networks and switched data networks.
* ''Difficulty:'' Medium.
* ''Recommended reading:''
** [https://codereview.appspot.com/5615049/ Basic implementation (very old)]
** [https://gitlab.com/nsnam/ns-3-dev/-/merge_requests/431 Full-duplex CSMA, somehow related]
** [https://tcipg.org/sites/default/files/papers/2010_Jin_Nicol_Caesar.pdf Paper on gigabit Ethernet switch models for simulation]

Possible tasks to fulfill the patch requirement:
* TBD, contact the mentors if interested.

GSOC2026Projects

2026-03-16T10:22:29Z

Biljana: /* Medium sized projects (175 hours) */

{{TOC}}

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

* [https://developers.google.com/open-source/gsoc/faq GSoC Frequently Asked Questions]
* [[GSOC2026ContributorGuide | ns-3's 2026 GSoC Contributor guide]]
* [https://developers.google.com/open-source/gsoc/resources/guide GSoC contributor/student guide (not ns-3 specific)]
* [[GSOC2025ApplicationTemplate | 2026 GSoC Contributor application template]]
* [[GSOCMentorGuide | ns-3's GSoC Mentor guide]]
* [https://archive.flossmanuals.net/gsocmentoring/index.html GSoC Mentor guide (not ns-3 specific)]
* [[GSOCSelectionProcess | GSoC Contributor Selection Process]]
* ''Get in contact with the ns-3 team'': [https://groups.google.com/g/ns-developers 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-25. 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 [mailto:tpecorella@mac.com Tommaso Pecorella] and [mailto:tahiliani.nitk@gmail.com Mohit P. Tahiliani]; contact them with any questions. They also hang out on [https://ns-3.zulipchat.com 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 [https://developers.google.com/open-source/gsoc/resources/guide GSoC contributor guide].
* Read [[GSOC2026ContributorGuide |ns-3's 2026 GSoC contributor guide]]
* 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.
* Once it is posted, look through the [[GSOC2024ApplicationTemplate |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 2026, 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 2026. 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 suggests 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>
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.
</blockquote>

=== Patch requirement guidelines ===

In past years, we have asked applicants to submit a patch related to an open issue or a suggested coding exercise. We are undecided at this time whether we will ask for this in 2026; check back later.

=== 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 ===

* [[#Flent Application API in ns-3]] (small size project, 90h)
* [[#Ping and TraverouteV4 enhancements]] (small size project, 90h)
* [[#Internet routing refactory]] (small size project, 90h)
* [[#AODVv2 Protocol enhancements]] (medium size project, 175h)
* [[#Linux-like CAKE queue discipline for ns-3]] (large size project, 350h)
* [[#Switched Ethernet]] (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)

=== 5G NR models enhancements ===

The general idea is to improve the usability of the 5G NR module by adding new examples that help users start building scenario scripts. Also, an interesting improvement could be integration with other modules, like those for AI or visualizations. Here are some project ideas. Depending on the contributor's interest and skills we can adjust these projects' definitions.

* [[#OLLA Link Adaptation and Spec-Compliant TBS Calculation for 5G-LENA]](medium size project, 175h)
* [[#Enabling 5G NR examples visualization]] (medium size project, 175h)
* [[#Energy Consumption Modeling and Power-Aware Extensions for 5G-LENA]](large size project, 250h)
* [[#5G NR module integration with ns-3-ai]] (large size project, 250h)
* [[#3GPP Release-19 features integration into ns-3 3GPP model and 5G-LENA]](medium size project, 175h)

== Small sized projects (90 hours) ==

=== Flent Application API in ns-3 ===

Mentors: [mailto:tahiliani.nitk@gmail.com Mohit P. Tahiliani]

Flexible Network Tester (Flent) is a network benchmarking tool. It is written in Python and wraps well-known network benchmarking tools (such as netperf and iperf) into aggregate, repeatable tests, such as a number of tests for Bufferbloat. A basic structure for Flent Application API in ns-3 has been developed. It is a wrapper around existing ns-3 applications. This project has four main goals: (1) update this implementation to match the current ns-3-dev, (2) integrate a JSON library properly (for Flent-style result handling) (3) validate correctness of Flent results produced by ns-3, and (4) Add more Flent-style test examples useful for ns-3 users. The goal of this project is to merge the Flent Application API into ns-3 mainline, not the app store.

* ''Required Experience:'' Familiarity with Flent and C++ programming.
* ''Bonus Experience:'' Familiarity with applications supported in ns-3.
* ''Interests:'' Bufferbloat, TCP, AQM algorithms and ECN.
* ''Difficulty:'' Medium.
* ''Recommended Reading:''
** Flexible Network Tester [[https://flent.org/flent-the-flexible-network-tester.pdf Paper]] [[https://flent.org/ Tool]]
** [https://www.nsnam.org/doxygen/d9/dc9/group__applications.html#details Existing Applications in ns-3]
** [https://gitlab.com/tomhenderson/ns-3-dev/-/commits/flent?ref_type=heads Prior work on Flent application API in ns-3]

=== Internet routing refactory ===

Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], [TBD].

Traditionally IP routing tables are organized in tuples {Dst, DstMask, GatewayAddr}, e.g., {10.42.66.0, 255.255.255.0, 169.254.10.1}, plus other flags and data, like the interface to be used.
In ns-3 this is accomplished by storing three separate objects, two Ipv[4,6]Address, and one Ipv[4Mask,6Prefix].

While this is quite simple to implement, this has some notable drawbacks, e.g., the Dst address must be a network address (Dst & ~DstMask == 0), it is not efficient (the mask or prefix could be represented by a simple integer), and more.
In order to improve code readability and consistency between IPv4 and IPv6, !2645 introduces two new classes: Ipv[4,6]NetworkAddress.

The goal is to refactor the existing routing classes, along with Ipv[4,6]RotingTable classes, so that they use the new classes.
The candidate should provide a clear and convincing plan to pursue the above mentioned goal, all while keeping backward compatibility. The APIs of the existing classes must be kept as they are (at most the can be deprecated), and new APIs should be introduced only where strictly necessary.
Another very important requirement will be to break down the work in multiple sub-tasks, so that the merge process can be gradual.

It is not required that the candidate will update the code for all the routing schemes, but the choice of which routing algorithms will be considered during the project must be clear and motivated.

* ''Required Experience:'' Fundamentals of IPv6 addressing and routing, C++ programming.
* ''Interests:'' IPv4 and IPv6 routing
* ''Difficulty:'' Easy.
* ''Recommended reading:''
** [https://gitlab.com/nsnam/ns-3-dev/-/issues/1239 Issue #1239]
** [https://gitlab.com/nsnam/ns-3-dev/-/merge_requests/2645 Merge Request !2645]

Possible tasks to fulfill the patch requirement:
* Use !2645 to modify all or in part the `Rip` protocol.

=== Ping and TraverouteV4 enhancements ===

Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], [TBD].

The Ping and TraverouteV4 ns-3 application have some small limitations.

In particular 2 of them are annoying.
1. Neither Ping nor TracerouteV4 reacts to ICMP errors or informative messages.
2. As the name implies, TracerouteV4 is IPv4-only and can't be used on IPv6.

The goal is to remove the above mentioned limitations, all or in part. A proposal should clearly outline the plan and improvements to the existing code (e.g., the list of the ICMP messages that will be considered), and a clear breakdown of the work. For the TracerouteV4 refactoring to use IPv6 as well, the proposal must consider the Ping implementation as a guideline.

* ''Required Experience:'' Fundamentals of IPv4, IPv6, ICMP, and ICMPv6. C++ programming.
* ''Interests:'' IPv4 and IPv6.
* ''Difficulty:'' Easy.
* ''Recommended reading:''
** [https://gitlab.com/nsnam/ns-3-dev/-/issues/825 Issue #825]

Possible tasks to fulfill the patch requirement:
* MR to have Ping react to one ICMP message.

== Medium sized projects (175 hours) ==

=== 6LoWPAN mesh-under routing enhancements ===

Mentors: [mailto:tommaso.pecorella@unifi.it 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.
Better approaches are possible, e.g., by leveraging some concepts from RFC 7731, by using SNR as a guidance, or by measuring the local network activity.

The candidate should outline the proposed approach, what parts of code are going to be affected, and how they can be enhanced.

* ''Required Experience:'' Fundamentals of IPv6 addressing, C++ programming.
* ''Bonus Experience:'' Familiarity with mesh routing and 6LoWPAN ns-3
* ''Interests:'' IPv6 mesh routing
* ''Difficulty:'' Easy.
* ''Recommended reading:''
** [https://www.nsnam.org/docs/models/html/sixlowpan.html#mesh-under-routing Mesh-under in ns-3 6LoWPAN]
** [https://datatracker.ietf.org/doc/html/rfc7731 RFC 7731]
** [https://meshtastic.org/docs/overview/mesh-algo/ Meshtastic controlled flooding]
** [https://ieeexplore.ieee.org/document/91339 Routing by controlled flooding in communication networks] (if the document can not be accessed, PM the mentors)

Possible tasks to fulfill the patch requirement:
* The current code is hardwired, i.e., the mesh-under routing scheme is embedded into the SixLowPanNetDevice. Propose a patch to decouple it, using a SixLowPanMeshUnderRouting class to determine the "next hop". The behavior of the actual protocol should be unchanged.

=== 6LoWPAN neighbor discovery protocol ===

Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], [mailto:adnan.rashid@poliba.it Adnan Rashid].

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 help merging the code (if it's not already merged) and add some features that are not yet considered in the model.

The candidate should outline in the proposal the features that are planned to be added, and a code mockup (or a complete class diagram) for said features.

* ''Required Experience:'' Fundamentals of IPv6 addressing, C++ programming.
* ''Bonus Experience:'' Familiarity with 6LoWPAN and 6LoWPAN-ND
* ''Interests:'' IPv6 and IoT networks
* ''Difficulty:'' Easy.
* ''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]
** https://gitlab.com/jieqiboh5836/ns-3-dev/-/tree/6LoWPAN-ND-P1
** https://gitlab.com/jieqiboh5836/ns-3-dev/-/tree/6LoWPAN-ND-P2

===OLLA Link Adaptation for 5G-LENA===

Mentors: [mailto:bbojovic@cttc.es Biljana Bojovic], [mailto:tomh@tomh.org Tom Henderson], [mailto:gcarvalho@cttc.es Gabriel Ferreira], [mailto:slagen@cttc.es Sandra Lagen]

This project would focus on improving the realism of the CTTC 5G-LENA by implementing Outer Loop Link Adaptation (OLLA) in the scheduling/link adaptation workflow. In the current baseline, MCS selection is driven by CQI (or SINR-to-CQI mapping) without an outer-loop correction. OLLA is commonly used to track a target BLER by updating an SINR (or CQI) offset based on HARQ ACK/NACK feedback, leading to more stable and realistic link adaptation behavior under varying channel conditions. This project should include this adaptation for the DL and for the UL, integrated in a scheduler-agnostic way so multiple NR schedulers can reuse it with minimal duplication.

In addition, the project would include a performance evaluation:

*comparing the new OLLA-enabled behavior against the current baseline and across multiple representative existing NR schedulers.
*the evaluation should consider throughput, latency, and achieved BLER, including how closely the achieved BLER tracks the configured target.
*the evaluation of the responsiveness to channel condition changes (convergence speed, stability/oscillation behavior).
*the sensitivity to the CQI update frequency and to user data rate / traffic load (how ACK/NACK rate affects convergence).

Additional topics/work items that could be considered if feasible:

*More advanced OLLA algorithms.
*Calibration guidance and/or comparison against published OLLA configurations (when reference data is available).
*Extensions beyond MCS selection (e.g., rank adaptation). This should be relatively easy in the uplink, but for the downlink some advanced mechanism could be investigated and potentially, AI-based approach could be considered.

For starters, we would suggest adding the CTTC 5G-LENA (nr module) to ns-3 (as a module in the contrib/ directory), building and running the NR examples, and becoming familiar with the current scheduler, HARQ feedback flow, CQI/MCS selection, and TBS computation. 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.

*Required Experience: C++ programming, understanding of 5G NR MAC concepts (scheduling, CQI/MCS, HARQ), wireless networking fundamentals
*Interests: 5G NR simulations, scheduling, link adaptation, performance evaluation
*Difficulty: Medium
*Project size: 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.

=== Enabling 5G NR examples visualization ===

Mentors: [mailto:aashtari@cttc.es Amir Ashtari Gargari], [mailto:gcarvalho@cttc.es Gabriel Ferreira], [mailto:bbojovic@cttc.es Biljana Bojovic] and [mailto:kkoutlia@cttc.es Katerina Koutlia]

The main idea of this project is to allow easier visualization of 5G NR examples by integrating the NR module with some ns-3 visualization tools like NetAnim, or by implementing a kind of web-based visualization, e.g., through Jupyter notebook. The new feature should allow the visualization of already existing traces, visualization of topology, or even some new relevant simulation aspects could be considered. The idea is that users better understand how the metrics collection works, and how changing parameters can affect simulation results. In this project, we are open to other ideas on how to implement visualizations. An example scenario is to have e.g. the handover scenario and then be able to see while the UEs are moving and performing handover how their performance metrics vary.

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.
* Recommended reading: Please read this thread in the ns-3 developers list: [https://groups.google.com/g/ns-developers/c/xGCOIAuTYs8/m/yhzpGJkYAwAJ?utm_medium=email&utm_source=footer UI "Designer" for NS3 Based Visual Scripting].

=== AODVv2 Protocol enhancements ===

Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], [TBD].

ns-3 contains models for proactive (DSDV and OLSR) and reactive (AODV and DSR) ad hoc routing protocols. AODVv2 is currently an IETF draft, and its implementation in ns-3 is ongoing. This project aims at enhancing the AODVv2 model for ns-3.

In particular the project should address the following points:
# Alignment with the latest drafts,
# Model finalization and testing (in particular for the IPv6 part),
# AODVv2 examples and documentation,
# "External" network routing support.

Collaboration with the draft authors is also highly suggested.

* ''Required Experience:'' Fundamentals of IPv6 addressing, C++ programming.
* ''Bonus Experience:'' Familiarity with AODV implementations in ns-3 and AODVv2
* ''Interests:'' Ad hoc routing
* ''Difficulty:'' Medium.
* ''Recommended reading:''
** [https://www.nsnam.org/docs/models/html/ipv6.html IPv6 model in ns-3]
** [https://www.nsnam.org/docs/models/html/aodv.html AODV model in ns-3]
** [https://gitlab.com/tod97/ns-3-dev/-/tree/aodvv2-icns3-25 AODVv2 model presented at ICNS3-2025]
** [https://datatracker.ietf.org/doc/draft-perkins-manet-aodvv2/05/ Ad Hoc On-demand Distance Vector Version 2 (AODVv2) Routing]

Possible tasks to fulfill the patch requirement:
* [https://gitlab.com/nsnam/ns-3-dev/-/issues/368 Issue #368] - aodv: aodv parameters can be set to "impossible" values

=== Implementing 3GPP Release 19 Modeling Features in ns-3 3GPP and 5G-LENA ===

Mentors: [mailto:bbojovic@cttc.es Biljana Bojovic], [mailto:slagen@cttc.es Sandra Lagen]

This project aims to improve the realism and standard alignment of ns-3 3GPP and 5G-LENA by implementing selected 3GPP Release 19 modeling features. The goal is to extend the simulator with updated components reflecting recent 5G-Advanced developments.

Possible contributions include:

* Handheld device antenna placement and orientation models, reflecting realistic UE form-factor constraints and radiation characteristics.
* New channel models introduced in Release-19, such as suburban macro scenarios, including their associated path-loss, shadowing, and spatial consistency characteristics.
* Enhancements to existing propagation or antenna models to better align with recent 3GPP specifications changes.
* Additional Release-19 features relevant to system-level simulation, potentially including improvements to mobility modeling, link abstraction, or scheduler interactions.

The exact feature to be implemented will be selected jointly with the mentors and the contributor based on impact, feasibility, and the contributor's interests. Once the selected feature has been designed and integrated into ns-3 and 5G-LENA, the contributor will also be responsible for:

* develop unit tests
* validation example demonstrating the new capability
* prepare the contribution for integration into ns-3 following coding and review guidelines
* evaluation which may include:
** Validation or calibration against 3GPP reference results.
** Comparison with baseline ns-3 3GPP and 5G-LENA behavior to quantify the impact of the new model.
** Analysis of how the new feature affects system-level metrics, such as throughput, coverage, or interference patterns.

The project will be co-mentored by researchers involved in 3GPP standardization, including industry delegates contributing to the Release 19 process.

* Required Experience: C++ and Python programming, understanding of 5G NR, LTE, and wireless networks
* Interests: 3GPP calibration, 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 work or MRs to ns-3 or the nr module, you can contact us to check whether it is enough for the patch requirement.
* Recommended reading: [https://arxiv.org/pdf/2507.19266 Overview of 3GPP Release 19 Study on Channel Modeling Enhancements to TR 38.901 for 6G]

=== Initial Multi-Band Support and Carrier Selection in 5G-LENA: An FR3 Carrier Aggregation Use Case ===

Mentors: [mailto:bbojovic@cttc.es Biljana Bojovic], [mailto:slagen@cttc.es Sandra Lagen]

This project will extend the CTTC 5G-LENA NR module with initial support for multi-band operation and baseline carrier-selection mechanisms. The implementation is intended to be generic, while the evaluation will focus on FR3 scenarios in the 7-24 GHz range. The work will focus on adding the support needed to configure multiple carriers, implementing baseline UE carrier-selection policies based on simple metrics such as received power, SINR, or load, and on introducing a component carrier manager that enables carrier aggregation across configured carriers.

Expected contributions include:

*support for configuring multiple carriers with band-dependent parameters
*baseline UE carrier-selection policies
*implementation of a component carrier manager to support carrier aggregation
*unit tests for configuration, selection and aggregation, validation scenarios, and example simulations

Example scenarios may include a UE selecting the most suitable carrier as channel conditions change. The evaluation will focus on FR3 use cases, including scenarios relevant to FR3 carrier aggregation.
Evaluation may consider throughput, fairness, coverage, and robustness under different carrier-selection policies.

Possible extensions include load-aware selection strategies and more advanced carrier aggregation policies.

* Required Experience: C++ and Python programming, understanding of 5G NR, LTE, and wireless networks
* Interests: 3GPP calibration, 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 work or MRs to ns-3 or the nr module, you can contact us to check whether it is enough for the patch requirement.
* Recommended reading:
**[https://arxiv.org/pdf/2502.17914 A. Bazzi et al., Upper Mid-Band Spectrum for 6G]
**[https://arxiv.org/pdf/2507.19266 Overview of 3GPP Release 19 Study on Channel Modeling Enhancements to TR 38.901 for 6G]
**[https://arxiv.org/abs/2310.06425 6G Wireless Communications in 7–24 GHz Band]

== Large projects (350 hours) ==

=== Mesh Link Establishment (MLE) protocol ===

Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], [mailto:alramonet@is.tokushima-u.ac.jp Alberto Gallegos Ramonet].

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:''
** [https://datatracker.ietf.org/doc/html/draft-ietf-6lo-mesh-link-establishment MLE draft]
** [https://openthread.io/guides/thread-primer/network-discovery Thread primer]
** [https://www.threadgroup.org/ThreadSpec Thread specifications]

Possible tasks to fulfill the patch requirement:
* TBD, contact the mentors if interested.

===Energy Consumption Modeling and Power-Aware Extensions for 5G-LENA===

Mentors: [mailto:kkoutlia@cttc.es Katerina Koutlia], [mailto:bbojovic@cttc.es Biljana Bojovic], [mailto:mmiozzo@cttc.es Marco Miozzo] and [mailto:aashtari@cttc.es Amir Ashtari Gargari]

This project would add energy consumption modeling to the CTTC 5G-LENA (NR module). While 5G-LENA provides a detailed and validated simulation of the 5G NR protocol stack behavior, it currently lacks energy models for UEs and/or gNBs, limiting research on energy efficiency, green networking, 6G sustainability, and potentially AI-driven power-aware control.
The project would first evaluate reuse of the ns-3 Energy Framework (e.g., EnergySource, DeviceEnergyModel) by defining a clean interface between 5G-LENA and the energy module. If existing models are insufficient, the project would design and implement a 5G-specific device energy model (e.g., NrDeviceEnergyModel) and connect it to relevant 5G-LENA state/procedure events.
For starters, we would suggest adding the CTTC 5G-LENA (nr module) to ns-3 (as a module in the contrib/ directory), building and running the NR examples, and studying the Energy Framework integration patterns. Documentation is available here: https://5g-lena.cttc.es/. Tutorial video: https://acmse.net/2021/tutorials-offered/#tut-work03.

Scope (expected deliverables):
*Energy consumption accounting for UEs and/or gNBs
*Per-state (and if feasible per-procedure) modeling, e.g.
**gNB: idle/active/sleep, TX/RX, processing; dependence on bandwidth/PRBs, TX power, MIMO layers/streams/RF chains, load
**UE: TX/RX, measurements, CSI-RS/SRS activity, beamforming-related processing, handover
*Tracing, example(s), and documentation

Optional (time permitting): a simple energy-aware scheduling extension to explore QoS trade-offs (e.g., energy-per-bit or energy-aware MIMO under GBR)

*Required Experience: C++ programming, wireless networking fundamentals (energy/state-machine modeling is a plus)
*Interests: 5G NR simulations, energy efficiency, green networking, 6G sustainability
*Difficulty: Medium
*Project size: 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 integration with ns-3-ai ===

Mentors: [mailto:kkoutlia@cttc.es Katerina Koutlia], [mailto:gcarvalho@cttc.es Gabriel Ferreira], [mailto:aashtari@cttc.es Amir Ashtari Gargari] and [mailto:bbojovic@cttc.es Biljana Bojovic]

The objective of this project is to integrate the ns-3 5G NR module with [https://apps.nsnam.org/app/ns3-ai/ ns-3-ai]. In GSoC 2024 we had a project in which 5G NR was integrated with [https://www.nsnam.org/wiki/GSOC2024RLUsability5G ns-3 gym]. While ns-3 gym is a popular ns-3 module for AI, it is limited to the application of reinforcement learning techniques in networking research. On the other hand, ns-3-ai module provides a more general solution that enables the data interaction between ns-3 and other Python-based AI frameworks, like [https://www.tensorflow.org/api_docs/cc Tensorflow C++ APIs] and [https://pytorch.org/cppdocs/ PyTorch C++ APIs], which opens the door to use different machine learning-based techniques in 5G NR models. The correct functioning of the integration should be tested, and documented, and a fully working example using ns-3-ai should be provided. The contributor can propose a use-case scenario for matching learning. One option is to use it for MAC scheduling, but it could be used for other 5G related research problems, and the contributor is encouraged to propose the use case of his/her interest.

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.
* 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.

=== Linux-like CAKE queue discipline for ns-3 ===

Mentors: [mailto:tahiliani.nitk@gmail.com Mohit P. Tahiliani]

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.

* ''Required Experience:'' Familiarity with queue disciplines, TCP and C++ programming.
* ''Bonus Experience:'' Familiarity with CAKE framework in Linux 4.19
* ''Interests:'' Active Queue Management, Packet scheduling and TCP.
* ''Difficulty:'' Medium to Hard
* ''Recommended reading:''
** [https://arxiv.org/pdf/1804.07617.pdf Piece of CAKE: A Comprehensive Queue Management Solution for Home Gateways]
** [https://lwn.net/Articles/758353/ Let them run CAKE]
** [https://www.nsnam.org/docs/models/html/queue-discs.html Queue disciplines in ns-3]

=== Switched Ethernet ===

Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], TBD.

The current ns-3 models for wired connections are fine for simple networks, but the lack of a switched Ethernet model is a limitation in some cases.

The goal of the idea is to create, test, and document a Switched Ethernet model, able to simulate (at least) 1, 10, and 40 GbE links and model for a switch.

The model of the NetDevice and Channel shall take into account the link delays and errors, similarly to what is done by the point-to-point model. Futhermore, it should be able to set the link speed and if it is full-duplex or half-duplex. Additional support for flow control is a bonus, but not strictly required. Link speed auto-negotiation is not considered to be interesting.

The model for the switch should be modular (i.e., allowing the development of different switch types), and include auto-learning of I/O ports based on the MAC address, i.e., have a MAC/port table, and a basic store-and-forward operation. Features like advanced I/O buffer handling and ARP/NDP spoofing detection are not a priority and shall be left for future implementations.

The model should consider the future implementaion of algorithms like VLANs (IEEE 802.1Q, 802.1ad), and the Spanning Tree Protocol (IEEE 802.1D, 802.1w, and 802.1s). Their implementaion is not required, but the model design should allow their development.

* ''Required Experience:'' Fundamentals of Ethernet sitched networking, C++ programming.
* ''Interests:'' Ethernet networks and switched data networks.
* ''Difficulty:'' Medium.
* ''Recommended reading:''
** [https://codereview.appspot.com/5615049/ Basic implementation (very old)]
** [https://gitlab.com/nsnam/ns-3-dev/-/merge_requests/431 Full-duplex CSMA, somehow related]
** [https://tcipg.org/sites/default/files/papers/2010_Jin_Nicol_Caesar.pdf Paper on gigabit Ethernet switch models for simulation]

Possible tasks to fulfill the patch requirement:
* TBD, contact the mentors if interested.

GSOC2026Projects

2026-03-13T12:36:32Z

Biljana: /* 5G NR models enhancements */

{{TOC}}

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

* [https://developers.google.com/open-source/gsoc/faq GSoC Frequently Asked Questions]
* [[GSOC2026ContributorGuide | ns-3's 2026 GSoC Contributor guide]]
* [https://developers.google.com/open-source/gsoc/resources/guide GSoC contributor/student guide (not ns-3 specific)]
* [[GSOC2025ApplicationTemplate | 2026 GSoC Contributor application template]]
* [[GSOCMentorGuide | ns-3's GSoC Mentor guide]]
* [https://archive.flossmanuals.net/gsocmentoring/index.html GSoC Mentor guide (not ns-3 specific)]
* [[GSOCSelectionProcess | GSoC Contributor Selection Process]]
* ''Get in contact with the ns-3 team'': [https://groups.google.com/g/ns-developers 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-25. 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 [mailto:tpecorella@mac.com Tommaso Pecorella] and [mailto:tahiliani.nitk@gmail.com Mohit P. Tahiliani]; contact them with any questions. They also hang out on [https://ns-3.zulipchat.com 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 [https://developers.google.com/open-source/gsoc/resources/guide GSoC contributor guide].
* Read [[GSOC2026ContributorGuide |ns-3's 2026 GSoC contributor guide]]
* 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.
* Once it is posted, look through the [[GSOC2024ApplicationTemplate |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 2026, 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 2026. 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 suggests 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>
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.
</blockquote>

=== Patch requirement guidelines ===

In past years, we have asked applicants to submit a patch related to an open issue or a suggested coding exercise. We are undecided at this time whether we will ask for this in 2026; check back later.

=== 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 ===

* [[#Flent Application API in ns-3]] (small size project, 90h)
* [[#Ping and TraverouteV4 enhancements]] (small size project, 90h)
* [[#Internet routing refactory]] (small size project, 90h)
* [[#AODVv2 Protocol enhancements]] (medium size project, 175h)
* [[#Linux-like CAKE queue discipline for ns-3]] (large size project, 350h)
* [[#Switched Ethernet]] (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)

=== 5G NR models enhancements ===

The general idea is to improve the usability of the 5G NR module by adding new examples that help users start building scenario scripts. Also, an interesting improvement could be integration with other modules, like those for AI or visualizations. Here are some project ideas. Depending on the contributor's interest and skills we can adjust these projects' definitions.

* [[#OLLA Link Adaptation and Spec-Compliant TBS Calculation for 5G-LENA]](medium size project, 175h)
* [[#Enabling 5G NR examples visualization]] (medium size project, 175h)
* [[#Energy Consumption Modeling and Power-Aware Extensions for 5G-LENA]](large size project, 250h)
* [[#5G NR module integration with ns-3-ai]] (large size project, 250h)
* [[#3GPP Release-19 features integration into ns-3 3GPP model and 5G-LENA]](medium size project, 175h)

== Small sized projects (90 hours) ==

=== Flent Application API in ns-3 ===

Mentors: [mailto:tahiliani.nitk@gmail.com Mohit P. Tahiliani]

Flexible Network Tester (Flent) is a network benchmarking tool. It is written in Python and wraps well-known network benchmarking tools (such as netperf and iperf) into aggregate, repeatable tests, such as a number of tests for Bufferbloat. A basic structure for Flent Application API in ns-3 has been developed. It is a wrapper around existing ns-3 applications. This project has four main goals: (1) update this implementation to match the current ns-3-dev, (2) integrate a JSON library properly (for Flent-style result handling) (3) validate correctness of Flent results produced by ns-3, and (4) Add more Flent-style test examples useful for ns-3 users. The goal of this project is to merge the Flent Application API into ns-3 mainline, not the app store.

* ''Required Experience:'' Familiarity with Flent and C++ programming.
* ''Bonus Experience:'' Familiarity with applications supported in ns-3.
* ''Interests:'' Bufferbloat, TCP, AQM algorithms and ECN.
* ''Difficulty:'' Medium.
* ''Recommended Reading:''
** Flexible Network Tester [[https://flent.org/flent-the-flexible-network-tester.pdf Paper]] [[https://flent.org/ Tool]]
** [https://www.nsnam.org/doxygen/d9/dc9/group__applications.html#details Existing Applications in ns-3]
** [https://gitlab.com/tomhenderson/ns-3-dev/-/commits/flent?ref_type=heads Prior work on Flent application API in ns-3]

=== Internet routing refactory ===

Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], [TBD].

Traditionally IP routing tables are organized in tuples {Dst, DstMask, GatewayAddr}, e.g., {10.42.66.0, 255.255.255.0, 169.254.10.1}, plus other flags and data, like the interface to be used.
In ns-3 this is accomplished by storing three separate objects, two Ipv[4,6]Address, and one Ipv[4Mask,6Prefix].

While this is quite simple to implement, this has some notable drawbacks, e.g., the Dst address must be a network address (Dst & ~DstMask == 0), it is not efficient (the mask or prefix could be represented by a simple integer), and more.
In order to improve code readability and consistency between IPv4 and IPv6, !2645 introduces two new classes: Ipv[4,6]NetworkAddress.

The goal is to refactor the existing routing classes, along with Ipv[4,6]RotingTable classes, so that they use the new classes.
The candidate should provide a clear and convincing plan to pursue the above mentioned goal, all while keeping backward compatibility. The APIs of the existing classes must be kept as they are (at most the can be deprecated), and new APIs should be introduced only where strictly necessary.
Another very important requirement will be to break down the work in multiple sub-tasks, so that the merge process can be gradual.

It is not required that the candidate will update the code for all the routing schemes, but the choice of which routing algorithms will be considered during the project must be clear and motivated.

* ''Required Experience:'' Fundamentals of IPv6 addressing and routing, C++ programming.
* ''Interests:'' IPv4 and IPv6 routing
* ''Difficulty:'' Easy.
* ''Recommended reading:''
** [https://gitlab.com/nsnam/ns-3-dev/-/issues/1239 Issue #1239]
** [https://gitlab.com/nsnam/ns-3-dev/-/merge_requests/2645 Merge Request !2645]

Possible tasks to fulfill the patch requirement:
* Use !2645 to modify all or in part the `Rip` protocol.

=== Ping and TraverouteV4 enhancements ===

Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], [TBD].

The Ping and TraverouteV4 ns-3 application have some small limitations.

In particular 2 of them are annoying.
1. Neither Ping nor TracerouteV4 reacts to ICMP errors or informative messages.
2. As the name implies, TracerouteV4 is IPv4-only and can't be used on IPv6.

The goal is to remove the above mentioned limitations, all or in part. A proposal should clearly outline the plan and improvements to the existing code (e.g., the list of the ICMP messages that will be considered), and a clear breakdown of the work. For the TracerouteV4 refactoring to use IPv6 as well, the proposal must consider the Ping implementation as a guideline.

* ''Required Experience:'' Fundamentals of IPv4, IPv6, ICMP, and ICMPv6. C++ programming.
* ''Interests:'' IPv4 and IPv6.
* ''Difficulty:'' Easy.
* ''Recommended reading:''
** [https://gitlab.com/nsnam/ns-3-dev/-/issues/825 Issue #825]

Possible tasks to fulfill the patch requirement:
* MR to have Ping react to one ICMP message.

== Medium sized projects (175 hours) ==

=== 6LoWPAN mesh-under routing enhancements ===

Mentors: [mailto:tommaso.pecorella@unifi.it 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.
Better approaches are possible, e.g., by leveraging some concepts from RFC 7731, by using SNR as a guidance, or by measuring the local network activity.

The candidate should outline the proposed approach, what parts of code are going to be affected, and how they can be enhanced.

* ''Required Experience:'' Fundamentals of IPv6 addressing, C++ programming.
* ''Bonus Experience:'' Familiarity with mesh routing and 6LoWPAN ns-3
* ''Interests:'' IPv6 mesh routing
* ''Difficulty:'' Easy.
* ''Recommended reading:''
** [https://www.nsnam.org/docs/models/html/sixlowpan.html#mesh-under-routing Mesh-under in ns-3 6LoWPAN]
** [https://datatracker.ietf.org/doc/html/rfc7731 RFC 7731]
** [https://meshtastic.org/docs/overview/mesh-algo/ Meshtastic controlled flooding]
** [https://ieeexplore.ieee.org/document/91339 Routing by controlled flooding in communication networks] (if the document can not be accessed, PM the mentors)

Possible tasks to fulfill the patch requirement:
* The current code is hardwired, i.e., the mesh-under routing scheme is embedded into the SixLowPanNetDevice. Propose a patch to decouple it, using a SixLowPanMeshUnderRouting class to determine the "next hop". The behavior of the actual protocol should be unchanged.

=== 6LoWPAN neighbor discovery protocol ===

Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], [mailto:adnan.rashid@poliba.it Adnan Rashid].

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 help merging the code (if it's not already merged) and add some features that are not yet considered in the model.

The candidate should outline in the proposal the features that are planned to be added, and a code mockup (or a complete class diagram) for said features.

* ''Required Experience:'' Fundamentals of IPv6 addressing, C++ programming.
* ''Bonus Experience:'' Familiarity with 6LoWPAN and 6LoWPAN-ND
* ''Interests:'' IPv6 and IoT networks
* ''Difficulty:'' Easy.
* ''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]
** https://gitlab.com/jieqiboh5836/ns-3-dev/-/tree/6LoWPAN-ND-P1
** https://gitlab.com/jieqiboh5836/ns-3-dev/-/tree/6LoWPAN-ND-P2

===OLLA Link Adaptation for 5G-LENA===

Mentors: [mailto:bbojovic@cttc.es Biljana Bojovic], [mailto:tomh@tomh.org Tom Henderson], [mailto:gcarvalho@cttc.es Gabriel Ferreira], [mailto:slagen@cttc.es Sandra Lagen]

This project would focus on improving the realism of the CTTC 5G-LENA by implementing Outer Loop Link Adaptation (OLLA) in the scheduling/link adaptation workflow. In the current baseline, MCS selection is driven by CQI (or SINR-to-CQI mapping) without an outer-loop correction. OLLA is commonly used to track a target BLER by updating an SINR (or CQI) offset based on HARQ ACK/NACK feedback, leading to more stable and realistic link adaptation behavior under varying channel conditions. This project should include this adaptation for the DL and for the UL, integrated in a scheduler-agnostic way so multiple NR schedulers can reuse it with minimal duplication.

In addition, the project would include a performance evaluation:

*comparing the new OLLA-enabled behavior against the current baseline and across multiple representative existing NR schedulers.
*the evaluation should consider throughput, latency, and achieved BLER, including how closely the achieved BLER tracks the configured target.
*the evaluation of the responsiveness to channel condition changes (convergence speed, stability/oscillation behavior).
*the sensitivity to the CQI update frequency and to user data rate / traffic load (how ACK/NACK rate affects convergence).

Additional topics/work items that could be considered if feasible:

*More advanced OLLA algorithms.
*Calibration guidance and/or comparison against published OLLA configurations (when reference data is available).
*Extensions beyond MCS selection (e.g., rank adaptation). This should be relatively easy in the uplink, but for the downlink some advanced mechanism could be investigated and potentially, AI-based approach could be considered.

For starters, we would suggest adding the CTTC 5G-LENA (nr module) to ns-3 (as a module in the contrib/ directory), building and running the NR examples, and becoming familiar with the current scheduler, HARQ feedback flow, CQI/MCS selection, and TBS computation. 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.

*Required Experience: C++ programming, understanding of 5G NR MAC concepts (scheduling, CQI/MCS, HARQ), wireless networking fundamentals
*Interests: 5G NR simulations, scheduling, link adaptation, performance evaluation
*Difficulty: Medium
*Project size: 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.

=== Enabling 5G NR examples visualization ===

Mentors: [mailto:aashtari@cttc.es Amir Ashtari Gargari], [mailto:gcarvalho@cttc.es Gabriel Ferreira], [mailto:bbojovic@cttc.es Biljana Bojovic] and [mailto:kkoutlia@cttc.es Katerina Koutlia]

The main idea of this project is to allow easier visualization of 5G NR examples by integrating the NR module with some ns-3 visualization tools like NetAnim, or by implementing a kind of web-based visualization, e.g., through Jupyter notebook. The new feature should allow the visualization of already existing traces, visualization of topology, or even some new relevant simulation aspects could be considered. The idea is that users better understand how the metrics collection works, and how changing parameters can affect simulation results. In this project, we are open to other ideas on how to implement visualizations. An example scenario is to have e.g. the handover scenario and then be able to see while the UEs are moving and performing handover how their performance metrics vary.

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.
* Recommended reading: Please read this thread in the ns-3 developers list: [https://groups.google.com/g/ns-developers/c/xGCOIAuTYs8/m/yhzpGJkYAwAJ?utm_medium=email&utm_source=footer UI "Designer" for NS3 Based Visual Scripting].

=== AODVv2 Protocol enhancements ===

Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], [TBD].

ns-3 contains models for proactive (DSDV and OLSR) and reactive (AODV and DSR) ad hoc routing protocols. AODVv2 is currently an IETF draft, and its implementation in ns-3 is ongoing. This project aims at enhancing the AODVv2 model for ns-3.

In particular the project should address the following points:
# Alignment with the latest drafts,
# Model finalization and testing (in particular for the IPv6 part),
# AODVv2 examples and documentation,
# "External" network routing support.

Collaboration with the draft authors is also highly suggested.

* ''Required Experience:'' Fundamentals of IPv6 addressing, C++ programming.
* ''Bonus Experience:'' Familiarity with AODV implementations in ns-3 and AODVv2
* ''Interests:'' Ad hoc routing
* ''Difficulty:'' Medium.
* ''Recommended reading:''
** [https://www.nsnam.org/docs/models/html/ipv6.html IPv6 model in ns-3]
** [https://www.nsnam.org/docs/models/html/aodv.html AODV model in ns-3]
** [https://gitlab.com/tod97/ns-3-dev/-/tree/aodvv2-icns3-25 AODVv2 model presented at ICNS3-2025]
** [https://datatracker.ietf.org/doc/draft-perkins-manet-aodvv2/05/ Ad Hoc On-demand Distance Vector Version 2 (AODVv2) Routing]

Possible tasks to fulfill the patch requirement:
* [https://gitlab.com/nsnam/ns-3-dev/-/issues/368 Issue #368] - aodv: aodv parameters can be set to "impossible" values

=== 3GPP Release-19 features integration into ns-3 3GPP model and 5G-LENA ===

Mentors: [mailto:bbojovic@cttc.es Biljana Bojovic], [mailto:slagen@cttc.es Sandra Lagen]

This project focuses on improving the realism and standard-alignment of the ns-3 3GPP and 5G-LENA models by integrating new features introduced in 3GPP Release-19. The goal is to extend the current simulator capabilities with updated modeling components that reflect the latest developments in 5G-Advanced standardization. Potential contributions may include the implementation of new modeling capabilities such as:

* Handheld device antenna placement and orientation models, reflecting realistic UE form-factor constraints and radiation characteristics.
* New channel models introduced in Release-19, such as suburban macro scenarios, including their associated path-loss, shadowing, and spatial consistency characteristics.
* Enhancements to existing propagation or antenna models to better align with recent 3GPP specifications changes.
* Additional Release-19 features relevant to system-level simulation, potentially including improvements to mobility modeling, link abstraction, or scheduler interactions.

The exact feature to be implemented will be selected jointly with the mentors and the contributor based on impact, feasibility, and the contributor's interests. Once the selected feature has been designed and integrated into ns-3 and 5G-LENA, the contributor will also be responsible for:

* Developing unit tests and validation test suites to verify the correctness of the implementation.
* Creating example simulation scenarios demonstrating the new capability.
* Performing performance validation and calibration against reference assumptions or published models when available.
* Preparing the contribution for integration into the main ns-3 codebase, following the project’s coding and review guidelines.

Possible evaluation aspects:

* Validation of the new feature against 3GPP reference parameters or calibration results.
* Comparison with baseline ns-3 3GPP and 5G-LENA behavior to quantify the impact of the new model.
* Analysis of how the new feature affects system-level metrics, such as throughput, coverage, or interference patterns.

Additional topics that could be considered if time permits include:
* Extending the implemented model to support multiple deployment scenarios (e.g., urban vs suburban).
* Improving configurability of the feature to support research experimentation.
* Investigating how the new modeling capability interacts with other NR components such as scheduling, beamforming, or mobility.

The project will be co-mentored by researchers involved in 3GPP standardization activities, including industry delegates participating in the Release-19 process, ensuring alignment with the latest technical discussions and specifications.

* Required Experience: C++ and Python programming, understanding of 5G NR, LTE, and wireless networks
* Interests: 3GPP calibration, 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 work or MRs to ns-3 or the nr module, you can contact us to check whether it is enough for the patch requirement.
* Recommended reading: [https://arxiv.org/pdf/2507.19266 Overview of 3GPP Release 19 Study on Channel Modeling Enhancements to TR 38.901 for 6G]

== Large projects (350 hours) ==

=== Mesh Link Establishment (MLE) protocol ===

Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], [mailto:alramonet@is.tokushima-u.ac.jp Alberto Gallegos Ramonet].

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:''
** [https://datatracker.ietf.org/doc/html/draft-ietf-6lo-mesh-link-establishment MLE draft]
** [https://openthread.io/guides/thread-primer/network-discovery Thread primer]
** [https://www.threadgroup.org/ThreadSpec Thread specifications]

Possible tasks to fulfill the patch requirement:
* TBD, contact the mentors if interested.

===Energy Consumption Modeling and Power-Aware Extensions for 5G-LENA===

Mentors: [mailto:kkoutlia@cttc.es Katerina Koutlia], [mailto:bbojovic@cttc.es Biljana Bojovic], [mailto:mmiozzo@cttc.es Marco Miozzo] and [mailto:aashtari@cttc.es Amir Ashtari Gargari]

This project would add energy consumption modeling to the CTTC 5G-LENA (NR module). While 5G-LENA provides a detailed and validated simulation of the 5G NR protocol stack behavior, it currently lacks energy models for UEs and/or gNBs, limiting research on energy efficiency, green networking, 6G sustainability, and potentially AI-driven power-aware control.
The project would first evaluate reuse of the ns-3 Energy Framework (e.g., EnergySource, DeviceEnergyModel) by defining a clean interface between 5G-LENA and the energy module. If existing models are insufficient, the project would design and implement a 5G-specific device energy model (e.g., NrDeviceEnergyModel) and connect it to relevant 5G-LENA state/procedure events.
For starters, we would suggest adding the CTTC 5G-LENA (nr module) to ns-3 (as a module in the contrib/ directory), building and running the NR examples, and studying the Energy Framework integration patterns. Documentation is available here: https://5g-lena.cttc.es/. Tutorial video: https://acmse.net/2021/tutorials-offered/#tut-work03.

Scope (expected deliverables):
*Energy consumption accounting for UEs and/or gNBs
*Per-state (and if feasible per-procedure) modeling, e.g.
**gNB: idle/active/sleep, TX/RX, processing; dependence on bandwidth/PRBs, TX power, MIMO layers/streams/RF chains, load
**UE: TX/RX, measurements, CSI-RS/SRS activity, beamforming-related processing, handover
*Tracing, example(s), and documentation

Optional (time permitting): a simple energy-aware scheduling extension to explore QoS trade-offs (e.g., energy-per-bit or energy-aware MIMO under GBR)

*Required Experience: C++ programming, wireless networking fundamentals (energy/state-machine modeling is a plus)
*Interests: 5G NR simulations, energy efficiency, green networking, 6G sustainability
*Difficulty: Medium
*Project size: 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 integration with ns-3-ai ===

Mentors: [mailto:kkoutlia@cttc.es Katerina Koutlia], [mailto:gcarvalho@cttc.es Gabriel Ferreira], [mailto:aashtari@cttc.es Amir Ashtari Gargari] and [mailto:bbojovic@cttc.es Biljana Bojovic]

The objective of this project is to integrate the ns-3 5G NR module with [https://apps.nsnam.org/app/ns3-ai/ ns-3-ai]. In GSoC 2024 we had a project in which 5G NR was integrated with [https://www.nsnam.org/wiki/GSOC2024RLUsability5G ns-3 gym]. While ns-3 gym is a popular ns-3 module for AI, it is limited to the application of reinforcement learning techniques in networking research. On the other hand, ns-3-ai module provides a more general solution that enables the data interaction between ns-3 and other Python-based AI frameworks, like [https://www.tensorflow.org/api_docs/cc Tensorflow C++ APIs] and [https://pytorch.org/cppdocs/ PyTorch C++ APIs], which opens the door to use different machine learning-based techniques in 5G NR models. The correct functioning of the integration should be tested, and documented, and a fully working example using ns-3-ai should be provided. The contributor can propose a use-case scenario for matching learning. One option is to use it for MAC scheduling, but it could be used for other 5G related research problems, and the contributor is encouraged to propose the use case of his/her interest.

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.
* 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.

=== Linux-like CAKE queue discipline for ns-3 ===

Mentors: [mailto:tahiliani.nitk@gmail.com Mohit P. Tahiliani]

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.

* ''Required Experience:'' Familiarity with queue disciplines, TCP and C++ programming.
* ''Bonus Experience:'' Familiarity with CAKE framework in Linux 4.19
* ''Interests:'' Active Queue Management, Packet scheduling and TCP.
* ''Difficulty:'' Medium to Hard
* ''Recommended reading:''
** [https://arxiv.org/pdf/1804.07617.pdf Piece of CAKE: A Comprehensive Queue Management Solution for Home Gateways]
** [https://lwn.net/Articles/758353/ Let them run CAKE]
** [https://www.nsnam.org/docs/models/html/queue-discs.html Queue disciplines in ns-3]

=== Switched Ethernet ===

Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], TBD.

The current ns-3 models for wired connections are fine for simple networks, but the lack of a switched Ethernet model is a limitation in some cases.

The goal of the idea is to create, test, and document a Switched Ethernet model, able to simulate (at least) 1, 10, and 40 GbE links and model for a switch.

The model of the NetDevice and Channel shall take into account the link delays and errors, similarly to what is done by the point-to-point model. Futhermore, it should be able to set the link speed and if it is full-duplex or half-duplex. Additional support for flow control is a bonus, but not strictly required. Link speed auto-negotiation is not considered to be interesting.

The model for the switch should be modular (i.e., allowing the development of different switch types), and include auto-learning of I/O ports based on the MAC address, i.e., have a MAC/port table, and a basic store-and-forward operation. Features like advanced I/O buffer handling and ARP/NDP spoofing detection are not a priority and shall be left for future implementations.

The model should consider the future implementaion of algorithms like VLANs (IEEE 802.1Q, 802.1ad), and the Spanning Tree Protocol (IEEE 802.1D, 802.1w, and 802.1s). Their implementaion is not required, but the model design should allow their development.

* ''Required Experience:'' Fundamentals of Ethernet sitched networking, C++ programming.
* ''Interests:'' Ethernet networks and switched data networks.
* ''Difficulty:'' Medium.
* ''Recommended reading:''
** [https://codereview.appspot.com/5615049/ Basic implementation (very old)]
** [https://gitlab.com/nsnam/ns-3-dev/-/merge_requests/431 Full-duplex CSMA, somehow related]
** [https://tcipg.org/sites/default/files/papers/2010_Jin_Nicol_Caesar.pdf Paper on gigabit Ethernet switch models for simulation]

Possible tasks to fulfill the patch requirement:
* TBD, contact the mentors if interested.

GSOC2026Projects

2026-03-13T12:36:11Z

Biljana: /* 3GPP Release-19 Feature Integration into ns-3 3GPP model and 5G-LENA */

{{TOC}}

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

* [https://developers.google.com/open-source/gsoc/faq GSoC Frequently Asked Questions]
* [[GSOC2026ContributorGuide | ns-3's 2026 GSoC Contributor guide]]
* [https://developers.google.com/open-source/gsoc/resources/guide GSoC contributor/student guide (not ns-3 specific)]
* [[GSOC2025ApplicationTemplate | 2026 GSoC Contributor application template]]
* [[GSOCMentorGuide | ns-3's GSoC Mentor guide]]
* [https://archive.flossmanuals.net/gsocmentoring/index.html GSoC Mentor guide (not ns-3 specific)]
* [[GSOCSelectionProcess | GSoC Contributor Selection Process]]
* ''Get in contact with the ns-3 team'': [https://groups.google.com/g/ns-developers 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-25. 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 [mailto:tpecorella@mac.com Tommaso Pecorella] and [mailto:tahiliani.nitk@gmail.com Mohit P. Tahiliani]; contact them with any questions. They also hang out on [https://ns-3.zulipchat.com 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 [https://developers.google.com/open-source/gsoc/resources/guide GSoC contributor guide].
* Read [[GSOC2026ContributorGuide |ns-3's 2026 GSoC contributor guide]]
* 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.
* Once it is posted, look through the [[GSOC2024ApplicationTemplate |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 2026, 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 2026. 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 suggests 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>
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.
</blockquote>

=== Patch requirement guidelines ===

In past years, we have asked applicants to submit a patch related to an open issue or a suggested coding exercise. We are undecided at this time whether we will ask for this in 2026; check back later.

=== 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 ===

* [[#Flent Application API in ns-3]] (small size project, 90h)
* [[#Ping and TraverouteV4 enhancements]] (small size project, 90h)
* [[#Internet routing refactory]] (small size project, 90h)
* [[#AODVv2 Protocol enhancements]] (medium size project, 175h)
* [[#Linux-like CAKE queue discipline for ns-3]] (large size project, 350h)
* [[#Switched Ethernet]] (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)

=== 5G NR models enhancements ===

The general idea is to improve the usability of the 5G NR module by adding new examples that help users start building scenario scripts. Also, an interesting improvement could be integration with other modules, like those for AI or visualizations. Here are some project ideas. Depending on the contributor's interest and skills we can adjust these projects' definitions.

* [[#OLLA Link Adaptation and Spec-Compliant TBS Calculation for 5G-LENA]](medium size project, 175h)
* [[#Enabling 5G NR examples visualization]] (medium size project, 175h)
* [[#Energy Consumption Modeling and Power-Aware Extensions for 5G-LENA]](large size project, 250h)
* [[#5G NR module integration with ns-3-ai]] (large size project, 250h)
* [[#3GPP Release-19 Feature Integration into ns-3 3GPP model and 5G-LENA]](medium size project, 175h)

== Small sized projects (90 hours) ==

=== Flent Application API in ns-3 ===

Mentors: [mailto:tahiliani.nitk@gmail.com Mohit P. Tahiliani]

Flexible Network Tester (Flent) is a network benchmarking tool. It is written in Python and wraps well-known network benchmarking tools (such as netperf and iperf) into aggregate, repeatable tests, such as a number of tests for Bufferbloat. A basic structure for Flent Application API in ns-3 has been developed. It is a wrapper around existing ns-3 applications. This project has four main goals: (1) update this implementation to match the current ns-3-dev, (2) integrate a JSON library properly (for Flent-style result handling) (3) validate correctness of Flent results produced by ns-3, and (4) Add more Flent-style test examples useful for ns-3 users. The goal of this project is to merge the Flent Application API into ns-3 mainline, not the app store.

* ''Required Experience:'' Familiarity with Flent and C++ programming.
* ''Bonus Experience:'' Familiarity with applications supported in ns-3.
* ''Interests:'' Bufferbloat, TCP, AQM algorithms and ECN.
* ''Difficulty:'' Medium.
* ''Recommended Reading:''
** Flexible Network Tester [[https://flent.org/flent-the-flexible-network-tester.pdf Paper]] [[https://flent.org/ Tool]]
** [https://www.nsnam.org/doxygen/d9/dc9/group__applications.html#details Existing Applications in ns-3]
** [https://gitlab.com/tomhenderson/ns-3-dev/-/commits/flent?ref_type=heads Prior work on Flent application API in ns-3]

=== Internet routing refactory ===

Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], [TBD].

Traditionally IP routing tables are organized in tuples {Dst, DstMask, GatewayAddr}, e.g., {10.42.66.0, 255.255.255.0, 169.254.10.1}, plus other flags and data, like the interface to be used.
In ns-3 this is accomplished by storing three separate objects, two Ipv[4,6]Address, and one Ipv[4Mask,6Prefix].

While this is quite simple to implement, this has some notable drawbacks, e.g., the Dst address must be a network address (Dst & ~DstMask == 0), it is not efficient (the mask or prefix could be represented by a simple integer), and more.
In order to improve code readability and consistency between IPv4 and IPv6, !2645 introduces two new classes: Ipv[4,6]NetworkAddress.

The goal is to refactor the existing routing classes, along with Ipv[4,6]RotingTable classes, so that they use the new classes.
The candidate should provide a clear and convincing plan to pursue the above mentioned goal, all while keeping backward compatibility. The APIs of the existing classes must be kept as they are (at most the can be deprecated), and new APIs should be introduced only where strictly necessary.
Another very important requirement will be to break down the work in multiple sub-tasks, so that the merge process can be gradual.

It is not required that the candidate will update the code for all the routing schemes, but the choice of which routing algorithms will be considered during the project must be clear and motivated.

* ''Required Experience:'' Fundamentals of IPv6 addressing and routing, C++ programming.
* ''Interests:'' IPv4 and IPv6 routing
* ''Difficulty:'' Easy.
* ''Recommended reading:''
** [https://gitlab.com/nsnam/ns-3-dev/-/issues/1239 Issue #1239]
** [https://gitlab.com/nsnam/ns-3-dev/-/merge_requests/2645 Merge Request !2645]

Possible tasks to fulfill the patch requirement:
* Use !2645 to modify all or in part the `Rip` protocol.

=== Ping and TraverouteV4 enhancements ===

Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], [TBD].

The Ping and TraverouteV4 ns-3 application have some small limitations.

In particular 2 of them are annoying.
1. Neither Ping nor TracerouteV4 reacts to ICMP errors or informative messages.
2. As the name implies, TracerouteV4 is IPv4-only and can't be used on IPv6.

The goal is to remove the above mentioned limitations, all or in part. A proposal should clearly outline the plan and improvements to the existing code (e.g., the list of the ICMP messages that will be considered), and a clear breakdown of the work. For the TracerouteV4 refactoring to use IPv6 as well, the proposal must consider the Ping implementation as a guideline.

* ''Required Experience:'' Fundamentals of IPv4, IPv6, ICMP, and ICMPv6. C++ programming.
* ''Interests:'' IPv4 and IPv6.
* ''Difficulty:'' Easy.
* ''Recommended reading:''
** [https://gitlab.com/nsnam/ns-3-dev/-/issues/825 Issue #825]

Possible tasks to fulfill the patch requirement:
* MR to have Ping react to one ICMP message.

== Medium sized projects (175 hours) ==

=== 6LoWPAN mesh-under routing enhancements ===

Mentors: [mailto:tommaso.pecorella@unifi.it 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.
Better approaches are possible, e.g., by leveraging some concepts from RFC 7731, by using SNR as a guidance, or by measuring the local network activity.

The candidate should outline the proposed approach, what parts of code are going to be affected, and how they can be enhanced.

* ''Required Experience:'' Fundamentals of IPv6 addressing, C++ programming.
* ''Bonus Experience:'' Familiarity with mesh routing and 6LoWPAN ns-3
* ''Interests:'' IPv6 mesh routing
* ''Difficulty:'' Easy.
* ''Recommended reading:''
** [https://www.nsnam.org/docs/models/html/sixlowpan.html#mesh-under-routing Mesh-under in ns-3 6LoWPAN]
** [https://datatracker.ietf.org/doc/html/rfc7731 RFC 7731]
** [https://meshtastic.org/docs/overview/mesh-algo/ Meshtastic controlled flooding]
** [https://ieeexplore.ieee.org/document/91339 Routing by controlled flooding in communication networks] (if the document can not be accessed, PM the mentors)

Possible tasks to fulfill the patch requirement:
* The current code is hardwired, i.e., the mesh-under routing scheme is embedded into the SixLowPanNetDevice. Propose a patch to decouple it, using a SixLowPanMeshUnderRouting class to determine the "next hop". The behavior of the actual protocol should be unchanged.

=== 6LoWPAN neighbor discovery protocol ===

Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], [mailto:adnan.rashid@poliba.it Adnan Rashid].

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 help merging the code (if it's not already merged) and add some features that are not yet considered in the model.

The candidate should outline in the proposal the features that are planned to be added, and a code mockup (or a complete class diagram) for said features.

* ''Required Experience:'' Fundamentals of IPv6 addressing, C++ programming.
* ''Bonus Experience:'' Familiarity with 6LoWPAN and 6LoWPAN-ND
* ''Interests:'' IPv6 and IoT networks
* ''Difficulty:'' Easy.
* ''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]
** https://gitlab.com/jieqiboh5836/ns-3-dev/-/tree/6LoWPAN-ND-P1
** https://gitlab.com/jieqiboh5836/ns-3-dev/-/tree/6LoWPAN-ND-P2

===OLLA Link Adaptation for 5G-LENA===

Mentors: [mailto:bbojovic@cttc.es Biljana Bojovic], [mailto:tomh@tomh.org Tom Henderson], [mailto:gcarvalho@cttc.es Gabriel Ferreira], [mailto:slagen@cttc.es Sandra Lagen]

This project would focus on improving the realism of the CTTC 5G-LENA by implementing Outer Loop Link Adaptation (OLLA) in the scheduling/link adaptation workflow. In the current baseline, MCS selection is driven by CQI (or SINR-to-CQI mapping) without an outer-loop correction. OLLA is commonly used to track a target BLER by updating an SINR (or CQI) offset based on HARQ ACK/NACK feedback, leading to more stable and realistic link adaptation behavior under varying channel conditions. This project should include this adaptation for the DL and for the UL, integrated in a scheduler-agnostic way so multiple NR schedulers can reuse it with minimal duplication.

In addition, the project would include a performance evaluation:

*comparing the new OLLA-enabled behavior against the current baseline and across multiple representative existing NR schedulers.
*the evaluation should consider throughput, latency, and achieved BLER, including how closely the achieved BLER tracks the configured target.
*the evaluation of the responsiveness to channel condition changes (convergence speed, stability/oscillation behavior).
*the sensitivity to the CQI update frequency and to user data rate / traffic load (how ACK/NACK rate affects convergence).

Additional topics/work items that could be considered if feasible:

*More advanced OLLA algorithms.
*Calibration guidance and/or comparison against published OLLA configurations (when reference data is available).
*Extensions beyond MCS selection (e.g., rank adaptation). This should be relatively easy in the uplink, but for the downlink some advanced mechanism could be investigated and potentially, AI-based approach could be considered.

For starters, we would suggest adding the CTTC 5G-LENA (nr module) to ns-3 (as a module in the contrib/ directory), building and running the NR examples, and becoming familiar with the current scheduler, HARQ feedback flow, CQI/MCS selection, and TBS computation. 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.

*Required Experience: C++ programming, understanding of 5G NR MAC concepts (scheduling, CQI/MCS, HARQ), wireless networking fundamentals
*Interests: 5G NR simulations, scheduling, link adaptation, performance evaluation
*Difficulty: Medium
*Project size: 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.

=== Enabling 5G NR examples visualization ===

Mentors: [mailto:aashtari@cttc.es Amir Ashtari Gargari], [mailto:gcarvalho@cttc.es Gabriel Ferreira], [mailto:bbojovic@cttc.es Biljana Bojovic] and [mailto:kkoutlia@cttc.es Katerina Koutlia]

The main idea of this project is to allow easier visualization of 5G NR examples by integrating the NR module with some ns-3 visualization tools like NetAnim, or by implementing a kind of web-based visualization, e.g., through Jupyter notebook. The new feature should allow the visualization of already existing traces, visualization of topology, or even some new relevant simulation aspects could be considered. The idea is that users better understand how the metrics collection works, and how changing parameters can affect simulation results. In this project, we are open to other ideas on how to implement visualizations. An example scenario is to have e.g. the handover scenario and then be able to see while the UEs are moving and performing handover how their performance metrics vary.

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.
* Recommended reading: Please read this thread in the ns-3 developers list: [https://groups.google.com/g/ns-developers/c/xGCOIAuTYs8/m/yhzpGJkYAwAJ?utm_medium=email&utm_source=footer UI "Designer" for NS3 Based Visual Scripting].

=== AODVv2 Protocol enhancements ===

Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], [TBD].

ns-3 contains models for proactive (DSDV and OLSR) and reactive (AODV and DSR) ad hoc routing protocols. AODVv2 is currently an IETF draft, and its implementation in ns-3 is ongoing. This project aims at enhancing the AODVv2 model for ns-3.

In particular the project should address the following points:
# Alignment with the latest drafts,
# Model finalization and testing (in particular for the IPv6 part),
# AODVv2 examples and documentation,
# "External" network routing support.

Collaboration with the draft authors is also highly suggested.

* ''Required Experience:'' Fundamentals of IPv6 addressing, C++ programming.
* ''Bonus Experience:'' Familiarity with AODV implementations in ns-3 and AODVv2
* ''Interests:'' Ad hoc routing
* ''Difficulty:'' Medium.
* ''Recommended reading:''
** [https://www.nsnam.org/docs/models/html/ipv6.html IPv6 model in ns-3]
** [https://www.nsnam.org/docs/models/html/aodv.html AODV model in ns-3]
** [https://gitlab.com/tod97/ns-3-dev/-/tree/aodvv2-icns3-25 AODVv2 model presented at ICNS3-2025]
** [https://datatracker.ietf.org/doc/draft-perkins-manet-aodvv2/05/ Ad Hoc On-demand Distance Vector Version 2 (AODVv2) Routing]

Possible tasks to fulfill the patch requirement:
* [https://gitlab.com/nsnam/ns-3-dev/-/issues/368 Issue #368] - aodv: aodv parameters can be set to "impossible" values

=== 3GPP Release-19 features integration into ns-3 3GPP model and 5G-LENA ===

Mentors: [mailto:bbojovic@cttc.es Biljana Bojovic], [mailto:slagen@cttc.es Sandra Lagen]

This project focuses on improving the realism and standard-alignment of the ns-3 3GPP and 5G-LENA models by integrating new features introduced in 3GPP Release-19. The goal is to extend the current simulator capabilities with updated modeling components that reflect the latest developments in 5G-Advanced standardization. Potential contributions may include the implementation of new modeling capabilities such as:

* Handheld device antenna placement and orientation models, reflecting realistic UE form-factor constraints and radiation characteristics.
* New channel models introduced in Release-19, such as suburban macro scenarios, including their associated path-loss, shadowing, and spatial consistency characteristics.
* Enhancements to existing propagation or antenna models to better align with recent 3GPP specifications changes.
* Additional Release-19 features relevant to system-level simulation, potentially including improvements to mobility modeling, link abstraction, or scheduler interactions.

The exact feature to be implemented will be selected jointly with the mentors and the contributor based on impact, feasibility, and the contributor's interests. Once the selected feature has been designed and integrated into ns-3 and 5G-LENA, the contributor will also be responsible for:

* Developing unit tests and validation test suites to verify the correctness of the implementation.
* Creating example simulation scenarios demonstrating the new capability.
* Performing performance validation and calibration against reference assumptions or published models when available.
* Preparing the contribution for integration into the main ns-3 codebase, following the project’s coding and review guidelines.

Possible evaluation aspects:

* Validation of the new feature against 3GPP reference parameters or calibration results.
* Comparison with baseline ns-3 3GPP and 5G-LENA behavior to quantify the impact of the new model.
* Analysis of how the new feature affects system-level metrics, such as throughput, coverage, or interference patterns.

Additional topics that could be considered if time permits include:
* Extending the implemented model to support multiple deployment scenarios (e.g., urban vs suburban).
* Improving configurability of the feature to support research experimentation.
* Investigating how the new modeling capability interacts with other NR components such as scheduling, beamforming, or mobility.

The project will be co-mentored by researchers involved in 3GPP standardization activities, including industry delegates participating in the Release-19 process, ensuring alignment with the latest technical discussions and specifications.

* Required Experience: C++ and Python programming, understanding of 5G NR, LTE, and wireless networks
* Interests: 3GPP calibration, 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 work or MRs to ns-3 or the nr module, you can contact us to check whether it is enough for the patch requirement.
* Recommended reading: [https://arxiv.org/pdf/2507.19266 Overview of 3GPP Release 19 Study on Channel Modeling Enhancements to TR 38.901 for 6G]

== Large projects (350 hours) ==

=== Mesh Link Establishment (MLE) protocol ===

Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], [mailto:alramonet@is.tokushima-u.ac.jp Alberto Gallegos Ramonet].

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:''
** [https://datatracker.ietf.org/doc/html/draft-ietf-6lo-mesh-link-establishment MLE draft]
** [https://openthread.io/guides/thread-primer/network-discovery Thread primer]
** [https://www.threadgroup.org/ThreadSpec Thread specifications]

Possible tasks to fulfill the patch requirement:
* TBD, contact the mentors if interested.

===Energy Consumption Modeling and Power-Aware Extensions for 5G-LENA===

Mentors: [mailto:kkoutlia@cttc.es Katerina Koutlia], [mailto:bbojovic@cttc.es Biljana Bojovic], [mailto:mmiozzo@cttc.es Marco Miozzo] and [mailto:aashtari@cttc.es Amir Ashtari Gargari]

This project would add energy consumption modeling to the CTTC 5G-LENA (NR module). While 5G-LENA provides a detailed and validated simulation of the 5G NR protocol stack behavior, it currently lacks energy models for UEs and/or gNBs, limiting research on energy efficiency, green networking, 6G sustainability, and potentially AI-driven power-aware control.
The project would first evaluate reuse of the ns-3 Energy Framework (e.g., EnergySource, DeviceEnergyModel) by defining a clean interface between 5G-LENA and the energy module. If existing models are insufficient, the project would design and implement a 5G-specific device energy model (e.g., NrDeviceEnergyModel) and connect it to relevant 5G-LENA state/procedure events.
For starters, we would suggest adding the CTTC 5G-LENA (nr module) to ns-3 (as a module in the contrib/ directory), building and running the NR examples, and studying the Energy Framework integration patterns. Documentation is available here: https://5g-lena.cttc.es/. Tutorial video: https://acmse.net/2021/tutorials-offered/#tut-work03.

Scope (expected deliverables):
*Energy consumption accounting for UEs and/or gNBs
*Per-state (and if feasible per-procedure) modeling, e.g.
**gNB: idle/active/sleep, TX/RX, processing; dependence on bandwidth/PRBs, TX power, MIMO layers/streams/RF chains, load
**UE: TX/RX, measurements, CSI-RS/SRS activity, beamforming-related processing, handover
*Tracing, example(s), and documentation

Optional (time permitting): a simple energy-aware scheduling extension to explore QoS trade-offs (e.g., energy-per-bit or energy-aware MIMO under GBR)

*Required Experience: C++ programming, wireless networking fundamentals (energy/state-machine modeling is a plus)
*Interests: 5G NR simulations, energy efficiency, green networking, 6G sustainability
*Difficulty: Medium
*Project size: 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 integration with ns-3-ai ===

Mentors: [mailto:kkoutlia@cttc.es Katerina Koutlia], [mailto:gcarvalho@cttc.es Gabriel Ferreira], [mailto:aashtari@cttc.es Amir Ashtari Gargari] and [mailto:bbojovic@cttc.es Biljana Bojovic]

The objective of this project is to integrate the ns-3 5G NR module with [https://apps.nsnam.org/app/ns3-ai/ ns-3-ai]. In GSoC 2024 we had a project in which 5G NR was integrated with [https://www.nsnam.org/wiki/GSOC2024RLUsability5G ns-3 gym]. While ns-3 gym is a popular ns-3 module for AI, it is limited to the application of reinforcement learning techniques in networking research. On the other hand, ns-3-ai module provides a more general solution that enables the data interaction between ns-3 and other Python-based AI frameworks, like [https://www.tensorflow.org/api_docs/cc Tensorflow C++ APIs] and [https://pytorch.org/cppdocs/ PyTorch C++ APIs], which opens the door to use different machine learning-based techniques in 5G NR models. The correct functioning of the integration should be tested, and documented, and a fully working example using ns-3-ai should be provided. The contributor can propose a use-case scenario for matching learning. One option is to use it for MAC scheduling, but it could be used for other 5G related research problems, and the contributor is encouraged to propose the use case of his/her interest.

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.
* 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.

=== Linux-like CAKE queue discipline for ns-3 ===

Mentors: [mailto:tahiliani.nitk@gmail.com Mohit P. Tahiliani]

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.

* ''Required Experience:'' Familiarity with queue disciplines, TCP and C++ programming.
* ''Bonus Experience:'' Familiarity with CAKE framework in Linux 4.19
* ''Interests:'' Active Queue Management, Packet scheduling and TCP.
* ''Difficulty:'' Medium to Hard
* ''Recommended reading:''
** [https://arxiv.org/pdf/1804.07617.pdf Piece of CAKE: A Comprehensive Queue Management Solution for Home Gateways]
** [https://lwn.net/Articles/758353/ Let them run CAKE]
** [https://www.nsnam.org/docs/models/html/queue-discs.html Queue disciplines in ns-3]

=== Switched Ethernet ===

Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], TBD.

The current ns-3 models for wired connections are fine for simple networks, but the lack of a switched Ethernet model is a limitation in some cases.

The goal of the idea is to create, test, and document a Switched Ethernet model, able to simulate (at least) 1, 10, and 40 GbE links and model for a switch.

The model of the NetDevice and Channel shall take into account the link delays and errors, similarly to what is done by the point-to-point model. Futhermore, it should be able to set the link speed and if it is full-duplex or half-duplex. Additional support for flow control is a bonus, but not strictly required. Link speed auto-negotiation is not considered to be interesting.

The model for the switch should be modular (i.e., allowing the development of different switch types), and include auto-learning of I/O ports based on the MAC address, i.e., have a MAC/port table, and a basic store-and-forward operation. Features like advanced I/O buffer handling and ARP/NDP spoofing detection are not a priority and shall be left for future implementations.

The model should consider the future implementaion of algorithms like VLANs (IEEE 802.1Q, 802.1ad), and the Spanning Tree Protocol (IEEE 802.1D, 802.1w, and 802.1s). Their implementaion is not required, but the model design should allow their development.

* ''Required Experience:'' Fundamentals of Ethernet sitched networking, C++ programming.
* ''Interests:'' Ethernet networks and switched data networks.
* ''Difficulty:'' Medium.
* ''Recommended reading:''
** [https://codereview.appspot.com/5615049/ Basic implementation (very old)]
** [https://gitlab.com/nsnam/ns-3-dev/-/merge_requests/431 Full-duplex CSMA, somehow related]
** [https://tcipg.org/sites/default/files/papers/2010_Jin_Nicol_Caesar.pdf Paper on gigabit Ethernet switch models for simulation]

Possible tasks to fulfill the patch requirement:
* TBD, contact the mentors if interested.

GSOC2026Projects

2026-03-13T12:35:18Z

Biljana: /* 3GPP Release-19 Feature Integration into ns-3 3GPP model and 5G-LENA */

{{TOC}}

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

* [https://developers.google.com/open-source/gsoc/faq GSoC Frequently Asked Questions]
* [[GSOC2026ContributorGuide | ns-3's 2026 GSoC Contributor guide]]
* [https://developers.google.com/open-source/gsoc/resources/guide GSoC contributor/student guide (not ns-3 specific)]
* [[GSOC2025ApplicationTemplate | 2026 GSoC Contributor application template]]
* [[GSOCMentorGuide | ns-3's GSoC Mentor guide]]
* [https://archive.flossmanuals.net/gsocmentoring/index.html GSoC Mentor guide (not ns-3 specific)]
* [[GSOCSelectionProcess | GSoC Contributor Selection Process]]
* ''Get in contact with the ns-3 team'': [https://groups.google.com/g/ns-developers 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-25. 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 [mailto:tpecorella@mac.com Tommaso Pecorella] and [mailto:tahiliani.nitk@gmail.com Mohit P. Tahiliani]; contact them with any questions. They also hang out on [https://ns-3.zulipchat.com 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 [https://developers.google.com/open-source/gsoc/resources/guide GSoC contributor guide].
* Read [[GSOC2026ContributorGuide |ns-3's 2026 GSoC contributor guide]]
* 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.
* Once it is posted, look through the [[GSOC2024ApplicationTemplate |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 2026, 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 2026. 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 suggests 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>
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.
</blockquote>

=== Patch requirement guidelines ===

In past years, we have asked applicants to submit a patch related to an open issue or a suggested coding exercise. We are undecided at this time whether we will ask for this in 2026; check back later.

=== 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 ===

* [[#Flent Application API in ns-3]] (small size project, 90h)
* [[#Ping and TraverouteV4 enhancements]] (small size project, 90h)
* [[#Internet routing refactory]] (small size project, 90h)
* [[#AODVv2 Protocol enhancements]] (medium size project, 175h)
* [[#Linux-like CAKE queue discipline for ns-3]] (large size project, 350h)
* [[#Switched Ethernet]] (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)

=== 5G NR models enhancements ===

The general idea is to improve the usability of the 5G NR module by adding new examples that help users start building scenario scripts. Also, an interesting improvement could be integration with other modules, like those for AI or visualizations. Here are some project ideas. Depending on the contributor's interest and skills we can adjust these projects' definitions.

* [[#OLLA Link Adaptation and Spec-Compliant TBS Calculation for 5G-LENA]](medium size project, 175h)
* [[#Enabling 5G NR examples visualization]] (medium size project, 175h)
* [[#Energy Consumption Modeling and Power-Aware Extensions for 5G-LENA]](large size project, 250h)
* [[#5G NR module integration with ns-3-ai]] (large size project, 250h)
* [[#3GPP Release-19 Feature Integration into ns-3 3GPP model and 5G-LENA]](medium size project, 175h)

== Small sized projects (90 hours) ==

=== Flent Application API in ns-3 ===

Mentors: [mailto:tahiliani.nitk@gmail.com Mohit P. Tahiliani]

Flexible Network Tester (Flent) is a network benchmarking tool. It is written in Python and wraps well-known network benchmarking tools (such as netperf and iperf) into aggregate, repeatable tests, such as a number of tests for Bufferbloat. A basic structure for Flent Application API in ns-3 has been developed. It is a wrapper around existing ns-3 applications. This project has four main goals: (1) update this implementation to match the current ns-3-dev, (2) integrate a JSON library properly (for Flent-style result handling) (3) validate correctness of Flent results produced by ns-3, and (4) Add more Flent-style test examples useful for ns-3 users. The goal of this project is to merge the Flent Application API into ns-3 mainline, not the app store.

* ''Required Experience:'' Familiarity with Flent and C++ programming.
* ''Bonus Experience:'' Familiarity with applications supported in ns-3.
* ''Interests:'' Bufferbloat, TCP, AQM algorithms and ECN.
* ''Difficulty:'' Medium.
* ''Recommended Reading:''
** Flexible Network Tester [[https://flent.org/flent-the-flexible-network-tester.pdf Paper]] [[https://flent.org/ Tool]]
** [https://www.nsnam.org/doxygen/d9/dc9/group__applications.html#details Existing Applications in ns-3]
** [https://gitlab.com/tomhenderson/ns-3-dev/-/commits/flent?ref_type=heads Prior work on Flent application API in ns-3]

=== Internet routing refactory ===

Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], [TBD].

Traditionally IP routing tables are organized in tuples {Dst, DstMask, GatewayAddr}, e.g., {10.42.66.0, 255.255.255.0, 169.254.10.1}, plus other flags and data, like the interface to be used.
In ns-3 this is accomplished by storing three separate objects, two Ipv[4,6]Address, and one Ipv[4Mask,6Prefix].

While this is quite simple to implement, this has some notable drawbacks, e.g., the Dst address must be a network address (Dst & ~DstMask == 0), it is not efficient (the mask or prefix could be represented by a simple integer), and more.
In order to improve code readability and consistency between IPv4 and IPv6, !2645 introduces two new classes: Ipv[4,6]NetworkAddress.

The goal is to refactor the existing routing classes, along with Ipv[4,6]RotingTable classes, so that they use the new classes.
The candidate should provide a clear and convincing plan to pursue the above mentioned goal, all while keeping backward compatibility. The APIs of the existing classes must be kept as they are (at most the can be deprecated), and new APIs should be introduced only where strictly necessary.
Another very important requirement will be to break down the work in multiple sub-tasks, so that the merge process can be gradual.

It is not required that the candidate will update the code for all the routing schemes, but the choice of which routing algorithms will be considered during the project must be clear and motivated.

* ''Required Experience:'' Fundamentals of IPv6 addressing and routing, C++ programming.
* ''Interests:'' IPv4 and IPv6 routing
* ''Difficulty:'' Easy.
* ''Recommended reading:''
** [https://gitlab.com/nsnam/ns-3-dev/-/issues/1239 Issue #1239]
** [https://gitlab.com/nsnam/ns-3-dev/-/merge_requests/2645 Merge Request !2645]

Possible tasks to fulfill the patch requirement:
* Use !2645 to modify all or in part the `Rip` protocol.

=== Ping and TraverouteV4 enhancements ===

Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], [TBD].

The Ping and TraverouteV4 ns-3 application have some small limitations.

In particular 2 of them are annoying.
1. Neither Ping nor TracerouteV4 reacts to ICMP errors or informative messages.
2. As the name implies, TracerouteV4 is IPv4-only and can't be used on IPv6.

The goal is to remove the above mentioned limitations, all or in part. A proposal should clearly outline the plan and improvements to the existing code (e.g., the list of the ICMP messages that will be considered), and a clear breakdown of the work. For the TracerouteV4 refactoring to use IPv6 as well, the proposal must consider the Ping implementation as a guideline.

* ''Required Experience:'' Fundamentals of IPv4, IPv6, ICMP, and ICMPv6. C++ programming.
* ''Interests:'' IPv4 and IPv6.
* ''Difficulty:'' Easy.
* ''Recommended reading:''
** [https://gitlab.com/nsnam/ns-3-dev/-/issues/825 Issue #825]

Possible tasks to fulfill the patch requirement:
* MR to have Ping react to one ICMP message.

== Medium sized projects (175 hours) ==

=== 6LoWPAN mesh-under routing enhancements ===

Mentors: [mailto:tommaso.pecorella@unifi.it 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.
Better approaches are possible, e.g., by leveraging some concepts from RFC 7731, by using SNR as a guidance, or by measuring the local network activity.

The candidate should outline the proposed approach, what parts of code are going to be affected, and how they can be enhanced.

* ''Required Experience:'' Fundamentals of IPv6 addressing, C++ programming.
* ''Bonus Experience:'' Familiarity with mesh routing and 6LoWPAN ns-3
* ''Interests:'' IPv6 mesh routing
* ''Difficulty:'' Easy.
* ''Recommended reading:''
** [https://www.nsnam.org/docs/models/html/sixlowpan.html#mesh-under-routing Mesh-under in ns-3 6LoWPAN]
** [https://datatracker.ietf.org/doc/html/rfc7731 RFC 7731]
** [https://meshtastic.org/docs/overview/mesh-algo/ Meshtastic controlled flooding]
** [https://ieeexplore.ieee.org/document/91339 Routing by controlled flooding in communication networks] (if the document can not be accessed, PM the mentors)

Possible tasks to fulfill the patch requirement:
* The current code is hardwired, i.e., the mesh-under routing scheme is embedded into the SixLowPanNetDevice. Propose a patch to decouple it, using a SixLowPanMeshUnderRouting class to determine the "next hop". The behavior of the actual protocol should be unchanged.

=== 6LoWPAN neighbor discovery protocol ===

Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], [mailto:adnan.rashid@poliba.it Adnan Rashid].

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 help merging the code (if it's not already merged) and add some features that are not yet considered in the model.

The candidate should outline in the proposal the features that are planned to be added, and a code mockup (or a complete class diagram) for said features.

* ''Required Experience:'' Fundamentals of IPv6 addressing, C++ programming.
* ''Bonus Experience:'' Familiarity with 6LoWPAN and 6LoWPAN-ND
* ''Interests:'' IPv6 and IoT networks
* ''Difficulty:'' Easy.
* ''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]
** https://gitlab.com/jieqiboh5836/ns-3-dev/-/tree/6LoWPAN-ND-P1
** https://gitlab.com/jieqiboh5836/ns-3-dev/-/tree/6LoWPAN-ND-P2

===OLLA Link Adaptation for 5G-LENA===

Mentors: [mailto:bbojovic@cttc.es Biljana Bojovic], [mailto:tomh@tomh.org Tom Henderson], [mailto:gcarvalho@cttc.es Gabriel Ferreira], [mailto:slagen@cttc.es Sandra Lagen]

This project would focus on improving the realism of the CTTC 5G-LENA by implementing Outer Loop Link Adaptation (OLLA) in the scheduling/link adaptation workflow. In the current baseline, MCS selection is driven by CQI (or SINR-to-CQI mapping) without an outer-loop correction. OLLA is commonly used to track a target BLER by updating an SINR (or CQI) offset based on HARQ ACK/NACK feedback, leading to more stable and realistic link adaptation behavior under varying channel conditions. This project should include this adaptation for the DL and for the UL, integrated in a scheduler-agnostic way so multiple NR schedulers can reuse it with minimal duplication.

In addition, the project would include a performance evaluation:

*comparing the new OLLA-enabled behavior against the current baseline and across multiple representative existing NR schedulers.
*the evaluation should consider throughput, latency, and achieved BLER, including how closely the achieved BLER tracks the configured target.
*the evaluation of the responsiveness to channel condition changes (convergence speed, stability/oscillation behavior).
*the sensitivity to the CQI update frequency and to user data rate / traffic load (how ACK/NACK rate affects convergence).

Additional topics/work items that could be considered if feasible:

*More advanced OLLA algorithms.
*Calibration guidance and/or comparison against published OLLA configurations (when reference data is available).
*Extensions beyond MCS selection (e.g., rank adaptation). This should be relatively easy in the uplink, but for the downlink some advanced mechanism could be investigated and potentially, AI-based approach could be considered.

For starters, we would suggest adding the CTTC 5G-LENA (nr module) to ns-3 (as a module in the contrib/ directory), building and running the NR examples, and becoming familiar with the current scheduler, HARQ feedback flow, CQI/MCS selection, and TBS computation. 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.

*Required Experience: C++ programming, understanding of 5G NR MAC concepts (scheduling, CQI/MCS, HARQ), wireless networking fundamentals
*Interests: 5G NR simulations, scheduling, link adaptation, performance evaluation
*Difficulty: Medium
*Project size: 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.

=== Enabling 5G NR examples visualization ===

Mentors: [mailto:aashtari@cttc.es Amir Ashtari Gargari], [mailto:gcarvalho@cttc.es Gabriel Ferreira], [mailto:bbojovic@cttc.es Biljana Bojovic] and [mailto:kkoutlia@cttc.es Katerina Koutlia]

The main idea of this project is to allow easier visualization of 5G NR examples by integrating the NR module with some ns-3 visualization tools like NetAnim, or by implementing a kind of web-based visualization, e.g., through Jupyter notebook. The new feature should allow the visualization of already existing traces, visualization of topology, or even some new relevant simulation aspects could be considered. The idea is that users better understand how the metrics collection works, and how changing parameters can affect simulation results. In this project, we are open to other ideas on how to implement visualizations. An example scenario is to have e.g. the handover scenario and then be able to see while the UEs are moving and performing handover how their performance metrics vary.

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.
* Recommended reading: Please read this thread in the ns-3 developers list: [https://groups.google.com/g/ns-developers/c/xGCOIAuTYs8/m/yhzpGJkYAwAJ?utm_medium=email&utm_source=footer UI "Designer" for NS3 Based Visual Scripting].

=== AODVv2 Protocol enhancements ===

Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], [TBD].

ns-3 contains models for proactive (DSDV and OLSR) and reactive (AODV and DSR) ad hoc routing protocols. AODVv2 is currently an IETF draft, and its implementation in ns-3 is ongoing. This project aims at enhancing the AODVv2 model for ns-3.

In particular the project should address the following points:
# Alignment with the latest drafts,
# Model finalization and testing (in particular for the IPv6 part),
# AODVv2 examples and documentation,
# "External" network routing support.

Collaboration with the draft authors is also highly suggested.

* ''Required Experience:'' Fundamentals of IPv6 addressing, C++ programming.
* ''Bonus Experience:'' Familiarity with AODV implementations in ns-3 and AODVv2
* ''Interests:'' Ad hoc routing
* ''Difficulty:'' Medium.
* ''Recommended reading:''
** [https://www.nsnam.org/docs/models/html/ipv6.html IPv6 model in ns-3]
** [https://www.nsnam.org/docs/models/html/aodv.html AODV model in ns-3]
** [https://gitlab.com/tod97/ns-3-dev/-/tree/aodvv2-icns3-25 AODVv2 model presented at ICNS3-2025]
** [https://datatracker.ietf.org/doc/draft-perkins-manet-aodvv2/05/ Ad Hoc On-demand Distance Vector Version 2 (AODVv2) Routing]

Possible tasks to fulfill the patch requirement:
* [https://gitlab.com/nsnam/ns-3-dev/-/issues/368 Issue #368] - aodv: aodv parameters can be set to "impossible" values

=== 3GPP Release-19 Feature Integration into ns-3 3GPP model and 5G-LENA ===

Mentors: [mailto:bbojovic@cttc.es Biljana Bojovic], [mailto:slagen@cttc.es Sandra Lagen]

This project focuses on improving the realism and standard-alignment of the ns-3 3GPP and 5G-LENA models by integrating new features introduced in 3GPP Release-19. The goal is to extend the current simulator capabilities with updated modeling components that reflect the latest developments in 5G-Advanced standardization. Potential contributions may include the implementation of new modeling capabilities such as:

* Handheld device antenna placement and orientation models, reflecting realistic UE form-factor constraints and radiation characteristics.
* New channel models introduced in Release-19, such as suburban macro scenarios, including their associated path-loss, shadowing, and spatial consistency characteristics.
* Enhancements to existing propagation or antenna models to better align with recent 3GPP specifications changes.
* Additional Release-19 features relevant to system-level simulation, potentially including improvements to mobility modeling, link abstraction, or scheduler interactions.

The exact feature to be implemented will be selected jointly with the mentors and the contributor based on impact, feasibility, and the contributor's interests. Once the selected feature has been designed and integrated into ns-3 and 5G-LENA, the contributor will also be responsible for:

* Developing unit tests and validation test suites to verify the correctness of the implementation.
* Creating example simulation scenarios demonstrating the new capability.
* Performing performance validation and calibration against reference assumptions or published models when available.
* Preparing the contribution for integration into the main ns-3 codebase, following the project’s coding and review guidelines.

Possible evaluation aspects:

* Validation of the new feature against 3GPP reference parameters or calibration results.
* Comparison with baseline ns-3 3GPP and 5G-LENA behavior to quantify the impact of the new model.
* Analysis of how the new feature affects system-level metrics, such as throughput, coverage, or interference patterns.

Additional topics that could be considered if time permits include:
* Extending the implemented model to support multiple deployment scenarios (e.g., urban vs suburban).
* Improving configurability of the feature to support research experimentation.
* Investigating how the new modeling capability interacts with other NR components such as scheduling, beamforming, or mobility.

The project will be co-mentored by researchers involved in 3GPP standardization activities, including industry delegates participating in the Release-19 process, ensuring alignment with the latest technical discussions and specifications.

* Required Experience: C++ and Python programming, understanding of 5G NR, LTE, and wireless networks
* Interests: 3GPP calibration, 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 work or MRs to ns-3 or the nr module, you can contact us to check whether it is enough for the patch requirement.
* Recommended reading: [https://arxiv.org/pdf/2507.19266 Overview of 3GPP Release 19 Study on Channel Modeling Enhancements to TR 38.901 for 6G]

== Large projects (350 hours) ==

=== Mesh Link Establishment (MLE) protocol ===

Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], [mailto:alramonet@is.tokushima-u.ac.jp Alberto Gallegos Ramonet].

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:''
** [https://datatracker.ietf.org/doc/html/draft-ietf-6lo-mesh-link-establishment MLE draft]
** [https://openthread.io/guides/thread-primer/network-discovery Thread primer]
** [https://www.threadgroup.org/ThreadSpec Thread specifications]

Possible tasks to fulfill the patch requirement:
* TBD, contact the mentors if interested.

===Energy Consumption Modeling and Power-Aware Extensions for 5G-LENA===

Mentors: [mailto:kkoutlia@cttc.es Katerina Koutlia], [mailto:bbojovic@cttc.es Biljana Bojovic], [mailto:mmiozzo@cttc.es Marco Miozzo] and [mailto:aashtari@cttc.es Amir Ashtari Gargari]

This project would add energy consumption modeling to the CTTC 5G-LENA (NR module). While 5G-LENA provides a detailed and validated simulation of the 5G NR protocol stack behavior, it currently lacks energy models for UEs and/or gNBs, limiting research on energy efficiency, green networking, 6G sustainability, and potentially AI-driven power-aware control.
The project would first evaluate reuse of the ns-3 Energy Framework (e.g., EnergySource, DeviceEnergyModel) by defining a clean interface between 5G-LENA and the energy module. If existing models are insufficient, the project would design and implement a 5G-specific device energy model (e.g., NrDeviceEnergyModel) and connect it to relevant 5G-LENA state/procedure events.
For starters, we would suggest adding the CTTC 5G-LENA (nr module) to ns-3 (as a module in the contrib/ directory), building and running the NR examples, and studying the Energy Framework integration patterns. Documentation is available here: https://5g-lena.cttc.es/. Tutorial video: https://acmse.net/2021/tutorials-offered/#tut-work03.

Scope (expected deliverables):
*Energy consumption accounting for UEs and/or gNBs
*Per-state (and if feasible per-procedure) modeling, e.g.
**gNB: idle/active/sleep, TX/RX, processing; dependence on bandwidth/PRBs, TX power, MIMO layers/streams/RF chains, load
**UE: TX/RX, measurements, CSI-RS/SRS activity, beamforming-related processing, handover
*Tracing, example(s), and documentation

Optional (time permitting): a simple energy-aware scheduling extension to explore QoS trade-offs (e.g., energy-per-bit or energy-aware MIMO under GBR)

*Required Experience: C++ programming, wireless networking fundamentals (energy/state-machine modeling is a plus)
*Interests: 5G NR simulations, energy efficiency, green networking, 6G sustainability
*Difficulty: Medium
*Project size: 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 integration with ns-3-ai ===

Mentors: [mailto:kkoutlia@cttc.es Katerina Koutlia], [mailto:gcarvalho@cttc.es Gabriel Ferreira], [mailto:aashtari@cttc.es Amir Ashtari Gargari] and [mailto:bbojovic@cttc.es Biljana Bojovic]

The objective of this project is to integrate the ns-3 5G NR module with [https://apps.nsnam.org/app/ns3-ai/ ns-3-ai]. In GSoC 2024 we had a project in which 5G NR was integrated with [https://www.nsnam.org/wiki/GSOC2024RLUsability5G ns-3 gym]. While ns-3 gym is a popular ns-3 module for AI, it is limited to the application of reinforcement learning techniques in networking research. On the other hand, ns-3-ai module provides a more general solution that enables the data interaction between ns-3 and other Python-based AI frameworks, like [https://www.tensorflow.org/api_docs/cc Tensorflow C++ APIs] and [https://pytorch.org/cppdocs/ PyTorch C++ APIs], which opens the door to use different machine learning-based techniques in 5G NR models. The correct functioning of the integration should be tested, and documented, and a fully working example using ns-3-ai should be provided. The contributor can propose a use-case scenario for matching learning. One option is to use it for MAC scheduling, but it could be used for other 5G related research problems, and the contributor is encouraged to propose the use case of his/her interest.

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.
* 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.

=== Linux-like CAKE queue discipline for ns-3 ===

Mentors: [mailto:tahiliani.nitk@gmail.com Mohit P. Tahiliani]

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.

* ''Required Experience:'' Familiarity with queue disciplines, TCP and C++ programming.
* ''Bonus Experience:'' Familiarity with CAKE framework in Linux 4.19
* ''Interests:'' Active Queue Management, Packet scheduling and TCP.
* ''Difficulty:'' Medium to Hard
* ''Recommended reading:''
** [https://arxiv.org/pdf/1804.07617.pdf Piece of CAKE: A Comprehensive Queue Management Solution for Home Gateways]
** [https://lwn.net/Articles/758353/ Let them run CAKE]
** [https://www.nsnam.org/docs/models/html/queue-discs.html Queue disciplines in ns-3]

=== Switched Ethernet ===

Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], TBD.

The current ns-3 models for wired connections are fine for simple networks, but the lack of a switched Ethernet model is a limitation in some cases.

The goal of the idea is to create, test, and document a Switched Ethernet model, able to simulate (at least) 1, 10, and 40 GbE links and model for a switch.

The model of the NetDevice and Channel shall take into account the link delays and errors, similarly to what is done by the point-to-point model. Futhermore, it should be able to set the link speed and if it is full-duplex or half-duplex. Additional support for flow control is a bonus, but not strictly required. Link speed auto-negotiation is not considered to be interesting.

The model for the switch should be modular (i.e., allowing the development of different switch types), and include auto-learning of I/O ports based on the MAC address, i.e., have a MAC/port table, and a basic store-and-forward operation. Features like advanced I/O buffer handling and ARP/NDP spoofing detection are not a priority and shall be left for future implementations.

The model should consider the future implementaion of algorithms like VLANs (IEEE 802.1Q, 802.1ad), and the Spanning Tree Protocol (IEEE 802.1D, 802.1w, and 802.1s). Their implementaion is not required, but the model design should allow their development.

* ''Required Experience:'' Fundamentals of Ethernet sitched networking, C++ programming.
* ''Interests:'' Ethernet networks and switched data networks.
* ''Difficulty:'' Medium.
* ''Recommended reading:''
** [https://codereview.appspot.com/5615049/ Basic implementation (very old)]
** [https://gitlab.com/nsnam/ns-3-dev/-/merge_requests/431 Full-duplex CSMA, somehow related]
** [https://tcipg.org/sites/default/files/papers/2010_Jin_Nicol_Caesar.pdf Paper on gigabit Ethernet switch models for simulation]

Possible tasks to fulfill the patch requirement:
* TBD, contact the mentors if interested.

GSOC2026Projects

2026-03-13T09:53:50Z

Biljana: /* 5G NR models enhancements */

{{TOC}}

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

* [https://developers.google.com/open-source/gsoc/faq GSoC Frequently Asked Questions]
* [[GSOC2026ContributorGuide | ns-3's 2026 GSoC Contributor guide]]
* [https://developers.google.com/open-source/gsoc/resources/guide GSoC contributor/student guide (not ns-3 specific)]
* [[GSOC2025ApplicationTemplate | 2026 GSoC Contributor application template]]
* [[GSOCMentorGuide | ns-3's GSoC Mentor guide]]
* [https://archive.flossmanuals.net/gsocmentoring/index.html GSoC Mentor guide (not ns-3 specific)]
* [[GSOCSelectionProcess | GSoC Contributor Selection Process]]
* ''Get in contact with the ns-3 team'': [https://groups.google.com/g/ns-developers 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-25. 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 [mailto:tpecorella@mac.com Tommaso Pecorella] and [mailto:tahiliani.nitk@gmail.com Mohit P. Tahiliani]; contact them with any questions. They also hang out on [https://ns-3.zulipchat.com 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 [https://developers.google.com/open-source/gsoc/resources/guide GSoC contributor guide].
* Read [[GSOC2026ContributorGuide |ns-3's 2026 GSoC contributor guide]]
* 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.
* Once it is posted, look through the [[GSOC2024ApplicationTemplate |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 2026, 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 2026. 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 suggests 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>
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.
</blockquote>

=== Patch requirement guidelines ===

In past years, we have asked applicants to submit a patch related to an open issue or a suggested coding exercise. We are undecided at this time whether we will ask for this in 2026; check back later.

=== 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 ===

* [[#Flent Application API in ns-3]] (small size project, 90h)
* [[#Ping and TraverouteV4 enhancements]] (small size project, 90h)
* [[#Internet routing refactory]] (small size project, 90h)
* [[#AODVv2 Protocol enhancements]] (medium size project, 175h)
* [[#Linux-like CAKE queue discipline for ns-3]] (large size project, 350h)
* [[#Switched Ethernet]] (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)

=== 5G NR models enhancements ===

The general idea is to improve the usability of the 5G NR module by adding new examples that help users start building scenario scripts. Also, an interesting improvement could be integration with other modules, like those for AI or visualizations. Here are some project ideas. Depending on the contributor's interest and skills we can adjust these projects' definitions.

* [[#OLLA Link Adaptation and Spec-Compliant TBS Calculation for 5G-LENA]](medium size project, 175h)
* [[#Enabling 5G NR examples visualization]] (medium size project, 175h)
* [[#Energy Consumption Modeling and Power-Aware Extensions for 5G-LENA]](large size project, 250h)
* [[#5G NR module integration with ns-3-ai]] (large size project, 250h)
* [[#3GPP Release-19 Feature Integration into ns-3 3GPP model and 5G-LENA]](medium size project, 175h)

== Small sized projects (90 hours) ==

=== Flent Application API in ns-3 ===

Mentors: [mailto:tahiliani.nitk@gmail.com Mohit P. Tahiliani]

Flexible Network Tester (Flent) is a network benchmarking tool. It is written in Python and wraps well-known network benchmarking tools (such as netperf and iperf) into aggregate, repeatable tests, such as a number of tests for Bufferbloat. A basic structure for Flent Application API in ns-3 has been developed. It is a wrapper around existing ns-3 applications. This project has four main goals: (1) update this implementation to match the current ns-3-dev, (2) integrate a JSON library properly (for Flent-style result handling) (3) validate correctness of Flent results produced by ns-3, and (4) Add more Flent-style test examples useful for ns-3 users. The goal of this project is to merge the Flent Application API into ns-3 mainline, not the app store.

* ''Required Experience:'' Familiarity with Flent and C++ programming.
* ''Bonus Experience:'' Familiarity with applications supported in ns-3.
* ''Interests:'' Bufferbloat, TCP, AQM algorithms and ECN.
* ''Difficulty:'' Medium.
* ''Recommended Reading:''
** Flexible Network Tester [[https://flent.org/flent-the-flexible-network-tester.pdf Paper]] [[https://flent.org/ Tool]]
** [https://www.nsnam.org/doxygen/d9/dc9/group__applications.html#details Existing Applications in ns-3]
** [https://gitlab.com/tomhenderson/ns-3-dev/-/commits/flent?ref_type=heads Prior work on Flent application API in ns-3]

=== Internet routing refactory ===

Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], [TBD].

Traditionally IP routing tables are organized in tuples {Dst, DstMask, GatewayAddr}, e.g., {10.42.66.0, 255.255.255.0, 169.254.10.1}, plus other flags and data, like the interface to be used.
In ns-3 this is accomplished by storing three separate objects, two Ipv[4,6]Address, and one Ipv[4Mask,6Prefix].

While this is quite simple to implement, this has some notable drawbacks, e.g., the Dst address must be a network address (Dst & ~DstMask == 0), it is not efficient (the mask or prefix could be represented by a simple integer), and more.
In order to improve code readability and consistency between IPv4 and IPv6, !2645 introduces two new classes: Ipv[4,6]NetworkAddress.

The goal is to refactor the existing routing classes, along with Ipv[4,6]RotingTable classes, so that they use the new classes.
The candidate should provide a clear and convincing plan to pursue the above mentioned goal, all while keeping backward compatibility. The APIs of the existing classes must be kept as they are (at most the can be deprecated), and new APIs should be introduced only where strictly necessary.
Another very important requirement will be to break down the work in multiple sub-tasks, so that the merge process can be gradual.

It is not required that the candidate will update the code for all the routing schemes, but the choice of which routing algorithms will be considered during the project must be clear and motivated.

* ''Required Experience:'' Fundamentals of IPv6 addressing and routing, C++ programming.
* ''Interests:'' IPv4 and IPv6 routing
* ''Difficulty:'' Easy.
* ''Recommended reading:''
** [https://gitlab.com/nsnam/ns-3-dev/-/issues/1239 Issue #1239]
** [https://gitlab.com/nsnam/ns-3-dev/-/merge_requests/2645 Merge Request !2645]

Possible tasks to fulfill the patch requirement:
* Use !2645 to modify all or in part the `Rip` protocol.

=== Ping and TraverouteV4 enhancements ===

Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], [TBD].

The Ping and TraverouteV4 ns-3 application have some small limitations.

In particular 2 of them are annoying.
1. Neither Ping nor TracerouteV4 reacts to ICMP errors or informative messages.
2. As the name implies, TracerouteV4 is IPv4-only and can't be used on IPv6.

The goal is to remove the above mentioned limitations, all or in part. A proposal should clearly outline the plan and improvements to the existing code (e.g., the list of the ICMP messages that will be considered), and a clear breakdown of the work. For the TracerouteV4 refactoring to use IPv6 as well, the proposal must consider the Ping implementation as a guideline.

* ''Required Experience:'' Fundamentals of IPv4, IPv6, ICMP, and ICMPv6. C++ programming.
* ''Interests:'' IPv4 and IPv6.
* ''Difficulty:'' Easy.
* ''Recommended reading:''
** [https://gitlab.com/nsnam/ns-3-dev/-/issues/825 Issue #825]

Possible tasks to fulfill the patch requirement:
* MR to have Ping react to one ICMP message.

== Medium sized projects (175 hours) ==

=== 6LoWPAN mesh-under routing enhancements ===

Mentors: [mailto:tommaso.pecorella@unifi.it 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.
Better approaches are possible, e.g., by leveraging some concepts from RFC 7731, by using SNR as a guidance, or by measuring the local network activity.

The candidate should outline the proposed approach, what parts of code are going to be affected, and how they can be enhanced.

* ''Required Experience:'' Fundamentals of IPv6 addressing, C++ programming.
* ''Bonus Experience:'' Familiarity with mesh routing and 6LoWPAN ns-3
* ''Interests:'' IPv6 mesh routing
* ''Difficulty:'' Easy.
* ''Recommended reading:''
** [https://www.nsnam.org/docs/models/html/sixlowpan.html#mesh-under-routing Mesh-under in ns-3 6LoWPAN]
** [https://datatracker.ietf.org/doc/html/rfc7731 RFC 7731]
** [https://meshtastic.org/docs/overview/mesh-algo/ Meshtastic controlled flooding]
** [https://ieeexplore.ieee.org/document/91339 Routing by controlled flooding in communication networks] (if the document can not be accessed, PM the mentors)

Possible tasks to fulfill the patch requirement:
* The current code is hardwired, i.e., the mesh-under routing scheme is embedded into the SixLowPanNetDevice. Propose a patch to decouple it, using a SixLowPanMeshUnderRouting class to determine the "next hop". The behavior of the actual protocol should be unchanged.

=== 6LoWPAN neighbor discovery protocol ===

Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], [mailto:adnan.rashid@poliba.it Adnan Rashid].

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 help merging the code (if it's not already merged) and add some features that are not yet considered in the model.

The candidate should outline in the proposal the features that are planned to be added, and a code mockup (or a complete class diagram) for said features.

* ''Required Experience:'' Fundamentals of IPv6 addressing, C++ programming.
* ''Bonus Experience:'' Familiarity with 6LoWPAN and 6LoWPAN-ND
* ''Interests:'' IPv6 and IoT networks
* ''Difficulty:'' Easy.
* ''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]
** https://gitlab.com/jieqiboh5836/ns-3-dev/-/tree/6LoWPAN-ND-P1
** https://gitlab.com/jieqiboh5836/ns-3-dev/-/tree/6LoWPAN-ND-P2

===OLLA Link Adaptation for 5G-LENA===

Mentors: [mailto:bbojovic@cttc.es Biljana Bojovic], [mailto:tomh@tomh.org Tom Henderson], [mailto:gcarvalho@cttc.es Gabriel Ferreira], [mailto:slagen@cttc.es Sandra Lagen]

This project would focus on improving the realism of the CTTC 5G-LENA by implementing Outer Loop Link Adaptation (OLLA) in the scheduling/link adaptation workflow. In the current baseline, MCS selection is driven by CQI (or SINR-to-CQI mapping) without an outer-loop correction. OLLA is commonly used to track a target BLER by updating an SINR (or CQI) offset based on HARQ ACK/NACK feedback, leading to more stable and realistic link adaptation behavior under varying channel conditions. This project should include this adaptation for the DL and for the UL, integrated in a scheduler-agnostic way so multiple NR schedulers can reuse it with minimal duplication.

In addition, the project would include a performance evaluation:

*comparing the new OLLA-enabled behavior against the current baseline and across multiple representative existing NR schedulers.
*the evaluation should consider throughput, latency, and achieved BLER, including how closely the achieved BLER tracks the configured target.
*the evaluation of the responsiveness to channel condition changes (convergence speed, stability/oscillation behavior).
*the sensitivity to the CQI update frequency and to user data rate / traffic load (how ACK/NACK rate affects convergence).

Additional topics/work items that could be considered if feasible:

*More advanced OLLA algorithms.
*Calibration guidance and/or comparison against published OLLA configurations (when reference data is available).
*Extensions beyond MCS selection (e.g., rank adaptation). This should be relatively easy in the uplink, but for the downlink some advanced mechanism could be investigated and potentially, AI-based approach could be considered.

For starters, we would suggest adding the CTTC 5G-LENA (nr module) to ns-3 (as a module in the contrib/ directory), building and running the NR examples, and becoming familiar with the current scheduler, HARQ feedback flow, CQI/MCS selection, and TBS computation. 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.

*Required Experience: C++ programming, understanding of 5G NR MAC concepts (scheduling, CQI/MCS, HARQ), wireless networking fundamentals
*Interests: 5G NR simulations, scheduling, link adaptation, performance evaluation
*Difficulty: Medium
*Project size: 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.

=== Enabling 5G NR examples visualization ===

Mentors: [mailto:aashtari@cttc.es Amir Ashtari Gargari], [mailto:gcarvalho@cttc.es Gabriel Ferreira], [mailto:bbojovic@cttc.es Biljana Bojovic] and [mailto:kkoutlia@cttc.es Katerina Koutlia]

The main idea of this project is to allow easier visualization of 5G NR examples by integrating the NR module with some ns-3 visualization tools like NetAnim, or by implementing a kind of web-based visualization, e.g., through Jupyter notebook. The new feature should allow the visualization of already existing traces, visualization of topology, or even some new relevant simulation aspects could be considered. The idea is that users better understand how the metrics collection works, and how changing parameters can affect simulation results. In this project, we are open to other ideas on how to implement visualizations. An example scenario is to have e.g. the handover scenario and then be able to see while the UEs are moving and performing handover how their performance metrics vary.

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.
* Recommended reading: Please read this thread in the ns-3 developers list: [https://groups.google.com/g/ns-developers/c/xGCOIAuTYs8/m/yhzpGJkYAwAJ?utm_medium=email&utm_source=footer UI "Designer" for NS3 Based Visual Scripting].

=== AODVv2 Protocol enhancements ===

Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], [TBD].

ns-3 contains models for proactive (DSDV and OLSR) and reactive (AODV and DSR) ad hoc routing protocols. AODVv2 is currently an IETF draft, and its implementation in ns-3 is ongoing. This project aims at enhancing the AODVv2 model for ns-3.

In particular the project should address the following points:
# Alignment with the latest drafts,
# Model finalization and testing (in particular for the IPv6 part),
# AODVv2 examples and documentation,
# "External" network routing support.

Collaboration with the draft authors is also highly suggested.

* ''Required Experience:'' Fundamentals of IPv6 addressing, C++ programming.
* ''Bonus Experience:'' Familiarity with AODV implementations in ns-3 and AODVv2
* ''Interests:'' Ad hoc routing
* ''Difficulty:'' Medium.
* ''Recommended reading:''
** [https://www.nsnam.org/docs/models/html/ipv6.html IPv6 model in ns-3]
** [https://www.nsnam.org/docs/models/html/aodv.html AODV model in ns-3]
** [https://gitlab.com/tod97/ns-3-dev/-/tree/aodvv2-icns3-25 AODVv2 model presented at ICNS3-2025]
** [https://datatracker.ietf.org/doc/draft-perkins-manet-aodvv2/05/ Ad Hoc On-demand Distance Vector Version 2 (AODVv2) Routing]

Possible tasks to fulfill the patch requirement:
* [https://gitlab.com/nsnam/ns-3-dev/-/issues/368 Issue #368] - aodv: aodv parameters can be set to "impossible" values

=== 3GPP Release-19 Feature Integration into ns-3 3GPP model and 5G-LENA ===

Mentors: [mailto:bbojovic@cttc.es Biljana Bojovic], [mailto:slagen@cttc.es Sandra Lagen]

This project focuses on improving the realism and standard-alignment of the ns-3 3GPP and 5G-LENA models by integrating new features introduced in 3GPP Release-19. The goal is to extend the current simulator capabilities with updated modeling components that reflect the latest developments in 5G-Advanced standardization.

Potential contributions may include the implementation of new modeling capabilities such as:

* Handheld device antenna placement and orientation models, reflecting realistic UE form-factor constraints and radiation characteristics.
* New channel models introduced or refined in Release-19, such as suburban macro scenarios, including their associated path-loss, shadowing, and spatial consistency characteristics.
* Enhancements to existing propagation or antenna models to better align with recent 3GPP specifications.
* Additional Release-19 features relevant to system-level simulation, potentially including improvements to mobility modeling, link abstraction, or scheduler interactions.

The exact feature to be implemented will be selected jointly with the mentors and the student based on impact, feasibility, and the student's interests.

Once the selected feature has been designed and integrated into ns-3 and 5G-LENA, the student will also be responsible for:

* Developing unit tests and validation test suites to verify the correctness of the implementation.
* Creating example simulation scenarios demonstrating the new capability.
* Performing basic performance validation and calibration against reference assumptions or published models when available.
* Preparing the contribution for integration into the main ns-3 codebase, following the project’s coding and review guidelines.

Possible evaluation aspects:

* Validation of the new feature against 3GPP reference parameters or calibration results.
* Comparison with baseline ns-3 3GPP and 5G-LENA behavior to quantify the impact of the new model.
* Analysis of how the new feature affects system-level metrics, such as throughput, coverage, or interference patterns.

Additional topics that could be considered if time permits include:
* Extending the implemented model to support multiple deployment scenarios (e.g., urban vs suburban).
* Improving configurability of the feature to support research experimentation.
* Investigating how the new modeling capability interacts with other NR components such as scheduling, beamforming, or mobility.

The project will be co-mentored by researchers involved in 3GPP standardization activities, including industry delegates participating in the Release-19 process, ensuring alignment with the latest technical discussions and specifications.

* Required Experience: C++ and Python programming, understanding of 5G NR, LTE, and wireless networks
* Interests: 3GPP calibration, 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 work or MRs to ns-3 or the nr module, you can contact us to check whether it is enough for the patch requirement.
* Recommended reading: [https://arxiv.org/pdf/2507.19266 Overview of 3GPP Release 19 Study on Channel Modeling Enhancements to TR 38.901 for 6G]

== Large projects (350 hours) ==

=== Mesh Link Establishment (MLE) protocol ===

Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], [mailto:alramonet@is.tokushima-u.ac.jp Alberto Gallegos Ramonet].

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:''
** [https://datatracker.ietf.org/doc/html/draft-ietf-6lo-mesh-link-establishment MLE draft]
** [https://openthread.io/guides/thread-primer/network-discovery Thread primer]
** [https://www.threadgroup.org/ThreadSpec Thread specifications]

Possible tasks to fulfill the patch requirement:
* TBD, contact the mentors if interested.

===Energy Consumption Modeling and Power-Aware Extensions for 5G-LENA===

Mentors: [mailto:kkoutlia@cttc.es Katerina Koutlia], [mailto:bbojovic@cttc.es Biljana Bojovic], [mailto:mmiozzo@cttc.es Marco Miozzo] and [mailto:aashtari@cttc.es Amir Ashtari Gargari]

This project would add energy consumption modeling to the CTTC 5G-LENA (NR module). While 5G-LENA provides a detailed and validated simulation of the 5G NR protocol stack behavior, it currently lacks energy models for UEs and/or gNBs, limiting research on energy efficiency, green networking, 6G sustainability, and potentially AI-driven power-aware control.
The project would first evaluate reuse of the ns-3 Energy Framework (e.g., EnergySource, DeviceEnergyModel) by defining a clean interface between 5G-LENA and the energy module. If existing models are insufficient, the project would design and implement a 5G-specific device energy model (e.g., NrDeviceEnergyModel) and connect it to relevant 5G-LENA state/procedure events.
For starters, we would suggest adding the CTTC 5G-LENA (nr module) to ns-3 (as a module in the contrib/ directory), building and running the NR examples, and studying the Energy Framework integration patterns. Documentation is available here: https://5g-lena.cttc.es/. Tutorial video: https://acmse.net/2021/tutorials-offered/#tut-work03.

Scope (expected deliverables):
*Energy consumption accounting for UEs and/or gNBs
*Per-state (and if feasible per-procedure) modeling, e.g.
**gNB: idle/active/sleep, TX/RX, processing; dependence on bandwidth/PRBs, TX power, MIMO layers/streams/RF chains, load
**UE: TX/RX, measurements, CSI-RS/SRS activity, beamforming-related processing, handover
*Tracing, example(s), and documentation

Optional (time permitting): a simple energy-aware scheduling extension to explore QoS trade-offs (e.g., energy-per-bit or energy-aware MIMO under GBR)

*Required Experience: C++ programming, wireless networking fundamentals (energy/state-machine modeling is a plus)
*Interests: 5G NR simulations, energy efficiency, green networking, 6G sustainability
*Difficulty: Medium
*Project size: 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 integration with ns-3-ai ===

Mentors: [mailto:kkoutlia@cttc.es Katerina Koutlia], [mailto:gcarvalho@cttc.es Gabriel Ferreira], [mailto:aashtari@cttc.es Amir Ashtari Gargari] and [mailto:bbojovic@cttc.es Biljana Bojovic]

The objective of this project is to integrate the ns-3 5G NR module with [https://apps.nsnam.org/app/ns3-ai/ ns-3-ai]. In GSoC 2024 we had a project in which 5G NR was integrated with [https://www.nsnam.org/wiki/GSOC2024RLUsability5G ns-3 gym]. While ns-3 gym is a popular ns-3 module for AI, it is limited to the application of reinforcement learning techniques in networking research. On the other hand, ns-3-ai module provides a more general solution that enables the data interaction between ns-3 and other Python-based AI frameworks, like [https://www.tensorflow.org/api_docs/cc Tensorflow C++ APIs] and [https://pytorch.org/cppdocs/ PyTorch C++ APIs], which opens the door to use different machine learning-based techniques in 5G NR models. The correct functioning of the integration should be tested, and documented, and a fully working example using ns-3-ai should be provided. The contributor can propose a use-case scenario for matching learning. One option is to use it for MAC scheduling, but it could be used for other 5G related research problems, and the contributor is encouraged to propose the use case of his/her interest.

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.
* 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.

=== Linux-like CAKE queue discipline for ns-3 ===

Mentors: [mailto:tahiliani.nitk@gmail.com Mohit P. Tahiliani]

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.

* ''Required Experience:'' Familiarity with queue disciplines, TCP and C++ programming.
* ''Bonus Experience:'' Familiarity with CAKE framework in Linux 4.19
* ''Interests:'' Active Queue Management, Packet scheduling and TCP.
* ''Difficulty:'' Medium to Hard
* ''Recommended reading:''
** [https://arxiv.org/pdf/1804.07617.pdf Piece of CAKE: A Comprehensive Queue Management Solution for Home Gateways]
** [https://lwn.net/Articles/758353/ Let them run CAKE]
** [https://www.nsnam.org/docs/models/html/queue-discs.html Queue disciplines in ns-3]

=== Switched Ethernet ===

Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], TBD.

The current ns-3 models for wired connections are fine for simple networks, but the lack of a switched Ethernet model is a limitation in some cases.

The goal of the idea is to create, test, and document a Switched Ethernet model, able to simulate (at least) 1, 10, and 40 GbE links and model for a switch.

The model of the NetDevice and Channel shall take into account the link delays and errors, similarly to what is done by the point-to-point model. Futhermore, it should be able to set the link speed and if it is full-duplex or half-duplex. Additional support for flow control is a bonus, but not strictly required. Link speed auto-negotiation is not considered to be interesting.

The model for the switch should be modular (i.e., allowing the development of different switch types), and include auto-learning of I/O ports based on the MAC address, i.e., have a MAC/port table, and a basic store-and-forward operation. Features like advanced I/O buffer handling and ARP/NDP spoofing detection are not a priority and shall be left for future implementations.

The model should consider the future implementaion of algorithms like VLANs (IEEE 802.1Q, 802.1ad), and the Spanning Tree Protocol (IEEE 802.1D, 802.1w, and 802.1s). Their implementaion is not required, but the model design should allow their development.

* ''Required Experience:'' Fundamentals of Ethernet sitched networking, C++ programming.
* ''Interests:'' Ethernet networks and switched data networks.
* ''Difficulty:'' Medium.
* ''Recommended reading:''
** [https://codereview.appspot.com/5615049/ Basic implementation (very old)]
** [https://gitlab.com/nsnam/ns-3-dev/-/merge_requests/431 Full-duplex CSMA, somehow related]
** [https://tcipg.org/sites/default/files/papers/2010_Jin_Nicol_Caesar.pdf Paper on gigabit Ethernet switch models for simulation]

Possible tasks to fulfill the patch requirement:
* TBD, contact the mentors if interested.

GSOC2026Projects

2026-03-13T09:51:57Z

Biljana: /* 3GPP Release-19 Feature Integration */

{{TOC}}

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

* [https://developers.google.com/open-source/gsoc/faq GSoC Frequently Asked Questions]
* [[GSOC2026ContributorGuide | ns-3's 2026 GSoC Contributor guide]]
* [https://developers.google.com/open-source/gsoc/resources/guide GSoC contributor/student guide (not ns-3 specific)]
* [[GSOC2025ApplicationTemplate | 2026 GSoC Contributor application template]]
* [[GSOCMentorGuide | ns-3's GSoC Mentor guide]]
* [https://archive.flossmanuals.net/gsocmentoring/index.html GSoC Mentor guide (not ns-3 specific)]
* [[GSOCSelectionProcess | GSoC Contributor Selection Process]]
* ''Get in contact with the ns-3 team'': [https://groups.google.com/g/ns-developers 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-25. 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 [mailto:tpecorella@mac.com Tommaso Pecorella] and [mailto:tahiliani.nitk@gmail.com Mohit P. Tahiliani]; contact them with any questions. They also hang out on [https://ns-3.zulipchat.com 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 [https://developers.google.com/open-source/gsoc/resources/guide GSoC contributor guide].
* Read [[GSOC2026ContributorGuide |ns-3's 2026 GSoC contributor guide]]
* 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.
* Once it is posted, look through the [[GSOC2024ApplicationTemplate |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 2026, 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 2026. 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 suggests 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>
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.
</blockquote>

=== Patch requirement guidelines ===

In past years, we have asked applicants to submit a patch related to an open issue or a suggested coding exercise. We are undecided at this time whether we will ask for this in 2026; check back later.

=== 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 ===

* [[#Flent Application API in ns-3]] (small size project, 90h)
* [[#Ping and TraverouteV4 enhancements]] (small size project, 90h)
* [[#Internet routing refactory]] (small size project, 90h)
* [[#AODVv2 Protocol enhancements]] (medium size project, 175h)
* [[#Linux-like CAKE queue discipline for ns-3]] (large size project, 350h)
* [[#Switched Ethernet]] (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)

=== 5G NR models enhancements ===

The general idea is to improve the usability of the 5G NR module by adding new examples that help users start building scenario scripts. Also, an interesting improvement could be integration with other modules, like those for AI or visualizations. Here are some project ideas. Depending on the contributor's interest and skills we can adjust these projects' definitions.

* [[#OLLA Link Adaptation and Spec-Compliant TBS Calculation for 5G-LENA]](medium size project, 175h)
* [[#Enabling 5G NR examples visualization]] (medium size project, 175h)
* [[#Energy Consumption Modeling and Power-Aware Extensions for 5G-LENA]](medium size project, 250h)
* [[#5G NR module integration with ns-3-ai]] (large size project, 250h)

== Small sized projects (90 hours) ==

=== Flent Application API in ns-3 ===

Mentors: [mailto:tahiliani.nitk@gmail.com Mohit P. Tahiliani]

Flexible Network Tester (Flent) is a network benchmarking tool. It is written in Python and wraps well-known network benchmarking tools (such as netperf and iperf) into aggregate, repeatable tests, such as a number of tests for Bufferbloat. A basic structure for Flent Application API in ns-3 has been developed. It is a wrapper around existing ns-3 applications. This project has four main goals: (1) update this implementation to match the current ns-3-dev, (2) integrate a JSON library properly (for Flent-style result handling) (3) validate correctness of Flent results produced by ns-3, and (4) Add more Flent-style test examples useful for ns-3 users. The goal of this project is to merge the Flent Application API into ns-3 mainline, not the app store.

* ''Required Experience:'' Familiarity with Flent and C++ programming.
* ''Bonus Experience:'' Familiarity with applications supported in ns-3.
* ''Interests:'' Bufferbloat, TCP, AQM algorithms and ECN.
* ''Difficulty:'' Medium.
* ''Recommended Reading:''
** Flexible Network Tester [[https://flent.org/flent-the-flexible-network-tester.pdf Paper]] [[https://flent.org/ Tool]]
** [https://www.nsnam.org/doxygen/d9/dc9/group__applications.html#details Existing Applications in ns-3]
** [https://gitlab.com/tomhenderson/ns-3-dev/-/commits/flent?ref_type=heads Prior work on Flent application API in ns-3]

=== Internet routing refactory ===

Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], [TBD].

Traditionally IP routing tables are organized in tuples {Dst, DstMask, GatewayAddr}, e.g., {10.42.66.0, 255.255.255.0, 169.254.10.1}, plus other flags and data, like the interface to be used.
In ns-3 this is accomplished by storing three separate objects, two Ipv[4,6]Address, and one Ipv[4Mask,6Prefix].

While this is quite simple to implement, this has some notable drawbacks, e.g., the Dst address must be a network address (Dst & ~DstMask == 0), it is not efficient (the mask or prefix could be represented by a simple integer), and more.
In order to improve code readability and consistency between IPv4 and IPv6, !2645 introduces two new classes: Ipv[4,6]NetworkAddress.

The goal is to refactor the existing routing classes, along with Ipv[4,6]RotingTable classes, so that they use the new classes.
The candidate should provide a clear and convincing plan to pursue the above mentioned goal, all while keeping backward compatibility. The APIs of the existing classes must be kept as they are (at most the can be deprecated), and new APIs should be introduced only where strictly necessary.
Another very important requirement will be to break down the work in multiple sub-tasks, so that the merge process can be gradual.

It is not required that the candidate will update the code for all the routing schemes, but the choice of which routing algorithms will be considered during the project must be clear and motivated.

* ''Required Experience:'' Fundamentals of IPv6 addressing and routing, C++ programming.
* ''Interests:'' IPv4 and IPv6 routing
* ''Difficulty:'' Easy.
* ''Recommended reading:''
** [https://gitlab.com/nsnam/ns-3-dev/-/issues/1239 Issue #1239]
** [https://gitlab.com/nsnam/ns-3-dev/-/merge_requests/2645 Merge Request !2645]

Possible tasks to fulfill the patch requirement:
* Use !2645 to modify all or in part the `Rip` protocol.

=== Ping and TraverouteV4 enhancements ===

Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], [TBD].

The Ping and TraverouteV4 ns-3 application have some small limitations.

In particular 2 of them are annoying.
1. Neither Ping nor TracerouteV4 reacts to ICMP errors or informative messages.
2. As the name implies, TracerouteV4 is IPv4-only and can't be used on IPv6.

The goal is to remove the above mentioned limitations, all or in part. A proposal should clearly outline the plan and improvements to the existing code (e.g., the list of the ICMP messages that will be considered), and a clear breakdown of the work. For the TracerouteV4 refactoring to use IPv6 as well, the proposal must consider the Ping implementation as a guideline.

* ''Required Experience:'' Fundamentals of IPv4, IPv6, ICMP, and ICMPv6. C++ programming.
* ''Interests:'' IPv4 and IPv6.
* ''Difficulty:'' Easy.
* ''Recommended reading:''
** [https://gitlab.com/nsnam/ns-3-dev/-/issues/825 Issue #825]

Possible tasks to fulfill the patch requirement:
* MR to have Ping react to one ICMP message.

== Medium sized projects (175 hours) ==

=== 6LoWPAN mesh-under routing enhancements ===

Mentors: [mailto:tommaso.pecorella@unifi.it 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.
Better approaches are possible, e.g., by leveraging some concepts from RFC 7731, by using SNR as a guidance, or by measuring the local network activity.

The candidate should outline the proposed approach, what parts of code are going to be affected, and how they can be enhanced.

* ''Required Experience:'' Fundamentals of IPv6 addressing, C++ programming.
* ''Bonus Experience:'' Familiarity with mesh routing and 6LoWPAN ns-3
* ''Interests:'' IPv6 mesh routing
* ''Difficulty:'' Easy.
* ''Recommended reading:''
** [https://www.nsnam.org/docs/models/html/sixlowpan.html#mesh-under-routing Mesh-under in ns-3 6LoWPAN]
** [https://datatracker.ietf.org/doc/html/rfc7731 RFC 7731]
** [https://meshtastic.org/docs/overview/mesh-algo/ Meshtastic controlled flooding]
** [https://ieeexplore.ieee.org/document/91339 Routing by controlled flooding in communication networks] (if the document can not be accessed, PM the mentors)

Possible tasks to fulfill the patch requirement:
* The current code is hardwired, i.e., the mesh-under routing scheme is embedded into the SixLowPanNetDevice. Propose a patch to decouple it, using a SixLowPanMeshUnderRouting class to determine the "next hop". The behavior of the actual protocol should be unchanged.

=== 6LoWPAN neighbor discovery protocol ===

Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], [mailto:adnan.rashid@poliba.it Adnan Rashid].

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 help merging the code (if it's not already merged) and add some features that are not yet considered in the model.

The candidate should outline in the proposal the features that are planned to be added, and a code mockup (or a complete class diagram) for said features.

* ''Required Experience:'' Fundamentals of IPv6 addressing, C++ programming.
* ''Bonus Experience:'' Familiarity with 6LoWPAN and 6LoWPAN-ND
* ''Interests:'' IPv6 and IoT networks
* ''Difficulty:'' Easy.
* ''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]
** https://gitlab.com/jieqiboh5836/ns-3-dev/-/tree/6LoWPAN-ND-P1
** https://gitlab.com/jieqiboh5836/ns-3-dev/-/tree/6LoWPAN-ND-P2

===OLLA Link Adaptation for 5G-LENA===

Mentors: [mailto:bbojovic@cttc.es Biljana Bojovic], [mailto:tomh@tomh.org Tom Henderson], [mailto:gcarvalho@cttc.es Gabriel Ferreira], [mailto:slagen@cttc.es Sandra Lagen]

This project would focus on improving the realism of the CTTC 5G-LENA by implementing Outer Loop Link Adaptation (OLLA) in the scheduling/link adaptation workflow. In the current baseline, MCS selection is driven by CQI (or SINR-to-CQI mapping) without an outer-loop correction. OLLA is commonly used to track a target BLER by updating an SINR (or CQI) offset based on HARQ ACK/NACK feedback, leading to more stable and realistic link adaptation behavior under varying channel conditions. This project should include this adaptation for the DL and for the UL, integrated in a scheduler-agnostic way so multiple NR schedulers can reuse it with minimal duplication.

In addition, the project would include a performance evaluation:

*comparing the new OLLA-enabled behavior against the current baseline and across multiple representative existing NR schedulers.
*the evaluation should consider throughput, latency, and achieved BLER, including how closely the achieved BLER tracks the configured target.
*the evaluation of the responsiveness to channel condition changes (convergence speed, stability/oscillation behavior).
*the sensitivity to the CQI update frequency and to user data rate / traffic load (how ACK/NACK rate affects convergence).

Additional topics/work items that could be considered if feasible:

*More advanced OLLA algorithms.
*Calibration guidance and/or comparison against published OLLA configurations (when reference data is available).
*Extensions beyond MCS selection (e.g., rank adaptation). This should be relatively easy in the uplink, but for the downlink some advanced mechanism could be investigated and potentially, AI-based approach could be considered.

For starters, we would suggest adding the CTTC 5G-LENA (nr module) to ns-3 (as a module in the contrib/ directory), building and running the NR examples, and becoming familiar with the current scheduler, HARQ feedback flow, CQI/MCS selection, and TBS computation. 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.

*Required Experience: C++ programming, understanding of 5G NR MAC concepts (scheduling, CQI/MCS, HARQ), wireless networking fundamentals
*Interests: 5G NR simulations, scheduling, link adaptation, performance evaluation
*Difficulty: Medium
*Project size: 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.

=== Enabling 5G NR examples visualization ===

Mentors: [mailto:aashtari@cttc.es Amir Ashtari Gargari], [mailto:gcarvalho@cttc.es Gabriel Ferreira], [mailto:bbojovic@cttc.es Biljana Bojovic] and [mailto:kkoutlia@cttc.es Katerina Koutlia]

The main idea of this project is to allow easier visualization of 5G NR examples by integrating the NR module with some ns-3 visualization tools like NetAnim, or by implementing a kind of web-based visualization, e.g., through Jupyter notebook. The new feature should allow the visualization of already existing traces, visualization of topology, or even some new relevant simulation aspects could be considered. The idea is that users better understand how the metrics collection works, and how changing parameters can affect simulation results. In this project, we are open to other ideas on how to implement visualizations. An example scenario is to have e.g. the handover scenario and then be able to see while the UEs are moving and performing handover how their performance metrics vary.

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.
* Recommended reading: Please read this thread in the ns-3 developers list: [https://groups.google.com/g/ns-developers/c/xGCOIAuTYs8/m/yhzpGJkYAwAJ?utm_medium=email&utm_source=footer UI "Designer" for NS3 Based Visual Scripting].

=== AODVv2 Protocol enhancements ===

Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], [TBD].

ns-3 contains models for proactive (DSDV and OLSR) and reactive (AODV and DSR) ad hoc routing protocols. AODVv2 is currently an IETF draft, and its implementation in ns-3 is ongoing. This project aims at enhancing the AODVv2 model for ns-3.

In particular the project should address the following points:
# Alignment with the latest drafts,
# Model finalization and testing (in particular for the IPv6 part),
# AODVv2 examples and documentation,
# "External" network routing support.

Collaboration with the draft authors is also highly suggested.

* ''Required Experience:'' Fundamentals of IPv6 addressing, C++ programming.
* ''Bonus Experience:'' Familiarity with AODV implementations in ns-3 and AODVv2
* ''Interests:'' Ad hoc routing
* ''Difficulty:'' Medium.
* ''Recommended reading:''
** [https://www.nsnam.org/docs/models/html/ipv6.html IPv6 model in ns-3]
** [https://www.nsnam.org/docs/models/html/aodv.html AODV model in ns-3]
** [https://gitlab.com/tod97/ns-3-dev/-/tree/aodvv2-icns3-25 AODVv2 model presented at ICNS3-2025]
** [https://datatracker.ietf.org/doc/draft-perkins-manet-aodvv2/05/ Ad Hoc On-demand Distance Vector Version 2 (AODVv2) Routing]

Possible tasks to fulfill the patch requirement:
* [https://gitlab.com/nsnam/ns-3-dev/-/issues/368 Issue #368] - aodv: aodv parameters can be set to "impossible" values

=== 3GPP Release-19 Feature Integration into ns-3 3GPP model and 5G-LENA ===

Mentors: [mailto:bbojovic@cttc.es Biljana Bojovic], [mailto:slagen@cttc.es Sandra Lagen]

This project focuses on improving the realism and standard-alignment of the ns-3 3GPP and 5G-LENA models by integrating new features introduced in 3GPP Release-19. The goal is to extend the current simulator capabilities with updated modeling components that reflect the latest developments in 5G-Advanced standardization.

Potential contributions may include the implementation of new modeling capabilities such as:

* Handheld device antenna placement and orientation models, reflecting realistic UE form-factor constraints and radiation characteristics.
* New channel models introduced or refined in Release-19, such as suburban macro scenarios, including their associated path-loss, shadowing, and spatial consistency characteristics.
* Enhancements to existing propagation or antenna models to better align with recent 3GPP specifications.
* Additional Release-19 features relevant to system-level simulation, potentially including improvements to mobility modeling, link abstraction, or scheduler interactions.

The exact feature to be implemented will be selected jointly with the mentors and the student based on impact, feasibility, and the student's interests.

Once the selected feature has been designed and integrated into ns-3 and 5G-LENA, the student will also be responsible for:

* Developing unit tests and validation test suites to verify the correctness of the implementation.
* Creating example simulation scenarios demonstrating the new capability.
* Performing basic performance validation and calibration against reference assumptions or published models when available.
* Preparing the contribution for integration into the main ns-3 codebase, following the project’s coding and review guidelines.

Possible evaluation aspects:

* Validation of the new feature against 3GPP reference parameters or calibration results.
* Comparison with baseline ns-3 3GPP and 5G-LENA behavior to quantify the impact of the new model.
* Analysis of how the new feature affects system-level metrics, such as throughput, coverage, or interference patterns.

Additional topics that could be considered if time permits include:
* Extending the implemented model to support multiple deployment scenarios (e.g., urban vs suburban).
* Improving configurability of the feature to support research experimentation.
* Investigating how the new modeling capability interacts with other NR components such as scheduling, beamforming, or mobility.

The project will be co-mentored by researchers involved in 3GPP standardization activities, including industry delegates participating in the Release-19 process, ensuring alignment with the latest technical discussions and specifications.

* Required Experience: C++ and Python programming, understanding of 5G NR, LTE, and wireless networks
* Interests: 3GPP calibration, 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 work or MRs to ns-3 or the nr module, you can contact us to check whether it is enough for the patch requirement.
* Recommended reading: [https://arxiv.org/pdf/2507.19266 Overview of 3GPP Release 19 Study on Channel Modeling Enhancements to TR 38.901 for 6G]

== Large projects (350 hours) ==

=== Mesh Link Establishment (MLE) protocol ===

Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], [mailto:alramonet@is.tokushima-u.ac.jp Alberto Gallegos Ramonet].

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:''
** [https://datatracker.ietf.org/doc/html/draft-ietf-6lo-mesh-link-establishment MLE draft]
** [https://openthread.io/guides/thread-primer/network-discovery Thread primer]
** [https://www.threadgroup.org/ThreadSpec Thread specifications]

Possible tasks to fulfill the patch requirement:
* TBD, contact the mentors if interested.

===Energy Consumption Modeling and Power-Aware Extensions for 5G-LENA===

Mentors: [mailto:kkoutlia@cttc.es Katerina Koutlia], [mailto:bbojovic@cttc.es Biljana Bojovic], [mailto:mmiozzo@cttc.es Marco Miozzo] and [mailto:aashtari@cttc.es Amir Ashtari Gargari]

This project would add energy consumption modeling to the CTTC 5G-LENA (NR module). While 5G-LENA provides a detailed and validated simulation of the 5G NR protocol stack behavior, it currently lacks energy models for UEs and/or gNBs, limiting research on energy efficiency, green networking, 6G sustainability, and potentially AI-driven power-aware control.
The project would first evaluate reuse of the ns-3 Energy Framework (e.g., EnergySource, DeviceEnergyModel) by defining a clean interface between 5G-LENA and the energy module. If existing models are insufficient, the project would design and implement a 5G-specific device energy model (e.g., NrDeviceEnergyModel) and connect it to relevant 5G-LENA state/procedure events.
For starters, we would suggest adding the CTTC 5G-LENA (nr module) to ns-3 (as a module in the contrib/ directory), building and running the NR examples, and studying the Energy Framework integration patterns. Documentation is available here: https://5g-lena.cttc.es/. Tutorial video: https://acmse.net/2021/tutorials-offered/#tut-work03.

Scope (expected deliverables):
*Energy consumption accounting for UEs and/or gNBs
*Per-state (and if feasible per-procedure) modeling, e.g.
**gNB: idle/active/sleep, TX/RX, processing; dependence on bandwidth/PRBs, TX power, MIMO layers/streams/RF chains, load
**UE: TX/RX, measurements, CSI-RS/SRS activity, beamforming-related processing, handover
*Tracing, example(s), and documentation

Optional (time permitting): a simple energy-aware scheduling extension to explore QoS trade-offs (e.g., energy-per-bit or energy-aware MIMO under GBR)

*Required Experience: C++ programming, wireless networking fundamentals (energy/state-machine modeling is a plus)
*Interests: 5G NR simulations, energy efficiency, green networking, 6G sustainability
*Difficulty: Medium
*Project size: 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 integration with ns-3-ai ===

Mentors: [mailto:kkoutlia@cttc.es Katerina Koutlia], [mailto:gcarvalho@cttc.es Gabriel Ferreira], [mailto:aashtari@cttc.es Amir Ashtari Gargari] and [mailto:bbojovic@cttc.es Biljana Bojovic]

The objective of this project is to integrate the ns-3 5G NR module with [https://apps.nsnam.org/app/ns3-ai/ ns-3-ai]. In GSoC 2024 we had a project in which 5G NR was integrated with [https://www.nsnam.org/wiki/GSOC2024RLUsability5G ns-3 gym]. While ns-3 gym is a popular ns-3 module for AI, it is limited to the application of reinforcement learning techniques in networking research. On the other hand, ns-3-ai module provides a more general solution that enables the data interaction between ns-3 and other Python-based AI frameworks, like [https://www.tensorflow.org/api_docs/cc Tensorflow C++ APIs] and [https://pytorch.org/cppdocs/ PyTorch C++ APIs], which opens the door to use different machine learning-based techniques in 5G NR models. The correct functioning of the integration should be tested, and documented, and a fully working example using ns-3-ai should be provided. The contributor can propose a use-case scenario for matching learning. One option is to use it for MAC scheduling, but it could be used for other 5G related research problems, and the contributor is encouraged to propose the use case of his/her interest.

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.
* 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.

=== Linux-like CAKE queue discipline for ns-3 ===

Mentors: [mailto:tahiliani.nitk@gmail.com Mohit P. Tahiliani]

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.

* ''Required Experience:'' Familiarity with queue disciplines, TCP and C++ programming.
* ''Bonus Experience:'' Familiarity with CAKE framework in Linux 4.19
* ''Interests:'' Active Queue Management, Packet scheduling and TCP.
* ''Difficulty:'' Medium to Hard
* ''Recommended reading:''
** [https://arxiv.org/pdf/1804.07617.pdf Piece of CAKE: A Comprehensive Queue Management Solution for Home Gateways]
** [https://lwn.net/Articles/758353/ Let them run CAKE]
** [https://www.nsnam.org/docs/models/html/queue-discs.html Queue disciplines in ns-3]

=== Switched Ethernet ===

Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], TBD.

The current ns-3 models for wired connections are fine for simple networks, but the lack of a switched Ethernet model is a limitation in some cases.

The goal of the idea is to create, test, and document a Switched Ethernet model, able to simulate (at least) 1, 10, and 40 GbE links and model for a switch.

The model of the NetDevice and Channel shall take into account the link delays and errors, similarly to what is done by the point-to-point model. Futhermore, it should be able to set the link speed and if it is full-duplex or half-duplex. Additional support for flow control is a bonus, but not strictly required. Link speed auto-negotiation is not considered to be interesting.

The model for the switch should be modular (i.e., allowing the development of different switch types), and include auto-learning of I/O ports based on the MAC address, i.e., have a MAC/port table, and a basic store-and-forward operation. Features like advanced I/O buffer handling and ARP/NDP spoofing detection are not a priority and shall be left for future implementations.

The model should consider the future implementaion of algorithms like VLANs (IEEE 802.1Q, 802.1ad), and the Spanning Tree Protocol (IEEE 802.1D, 802.1w, and 802.1s). Their implementaion is not required, but the model design should allow their development.

* ''Required Experience:'' Fundamentals of Ethernet sitched networking, C++ programming.
* ''Interests:'' Ethernet networks and switched data networks.
* ''Difficulty:'' Medium.
* ''Recommended reading:''
** [https://codereview.appspot.com/5615049/ Basic implementation (very old)]
** [https://gitlab.com/nsnam/ns-3-dev/-/merge_requests/431 Full-duplex CSMA, somehow related]
** [https://tcipg.org/sites/default/files/papers/2010_Jin_Nicol_Caesar.pdf Paper on gigabit Ethernet switch models for simulation]

Possible tasks to fulfill the patch requirement:
* TBD, contact the mentors if interested.

GSOC2026Projects

2026-03-13T09:51:12Z

Biljana: /* Medium sized projects (175 hours) */

{{TOC}}

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

* [https://developers.google.com/open-source/gsoc/faq GSoC Frequently Asked Questions]
* [[GSOC2026ContributorGuide | ns-3's 2026 GSoC Contributor guide]]
* [https://developers.google.com/open-source/gsoc/resources/guide GSoC contributor/student guide (not ns-3 specific)]
* [[GSOC2025ApplicationTemplate | 2026 GSoC Contributor application template]]
* [[GSOCMentorGuide | ns-3's GSoC Mentor guide]]
* [https://archive.flossmanuals.net/gsocmentoring/index.html GSoC Mentor guide (not ns-3 specific)]
* [[GSOCSelectionProcess | GSoC Contributor Selection Process]]
* ''Get in contact with the ns-3 team'': [https://groups.google.com/g/ns-developers 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-25. 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 [mailto:tpecorella@mac.com Tommaso Pecorella] and [mailto:tahiliani.nitk@gmail.com Mohit P. Tahiliani]; contact them with any questions. They also hang out on [https://ns-3.zulipchat.com 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 [https://developers.google.com/open-source/gsoc/resources/guide GSoC contributor guide].
* Read [[GSOC2026ContributorGuide |ns-3's 2026 GSoC contributor guide]]
* 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.
* Once it is posted, look through the [[GSOC2024ApplicationTemplate |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 2026, 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 2026. 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 suggests 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>
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.
</blockquote>

=== Patch requirement guidelines ===

In past years, we have asked applicants to submit a patch related to an open issue or a suggested coding exercise. We are undecided at this time whether we will ask for this in 2026; check back later.

=== 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 ===

* [[#Flent Application API in ns-3]] (small size project, 90h)
* [[#Ping and TraverouteV4 enhancements]] (small size project, 90h)
* [[#Internet routing refactory]] (small size project, 90h)
* [[#AODVv2 Protocol enhancements]] (medium size project, 175h)
* [[#Linux-like CAKE queue discipline for ns-3]] (large size project, 350h)
* [[#Switched Ethernet]] (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)

=== 5G NR models enhancements ===

The general idea is to improve the usability of the 5G NR module by adding new examples that help users start building scenario scripts. Also, an interesting improvement could be integration with other modules, like those for AI or visualizations. Here are some project ideas. Depending on the contributor's interest and skills we can adjust these projects' definitions.

* [[#OLLA Link Adaptation and Spec-Compliant TBS Calculation for 5G-LENA]](medium size project, 175h)
* [[#Enabling 5G NR examples visualization]] (medium size project, 175h)
* [[#Energy Consumption Modeling and Power-Aware Extensions for 5G-LENA]](medium size project, 250h)
* [[#5G NR module integration with ns-3-ai]] (large size project, 250h)

== Small sized projects (90 hours) ==

=== Flent Application API in ns-3 ===

Mentors: [mailto:tahiliani.nitk@gmail.com Mohit P. Tahiliani]

Flexible Network Tester (Flent) is a network benchmarking tool. It is written in Python and wraps well-known network benchmarking tools (such as netperf and iperf) into aggregate, repeatable tests, such as a number of tests for Bufferbloat. A basic structure for Flent Application API in ns-3 has been developed. It is a wrapper around existing ns-3 applications. This project has four main goals: (1) update this implementation to match the current ns-3-dev, (2) integrate a JSON library properly (for Flent-style result handling) (3) validate correctness of Flent results produced by ns-3, and (4) Add more Flent-style test examples useful for ns-3 users. The goal of this project is to merge the Flent Application API into ns-3 mainline, not the app store.

* ''Required Experience:'' Familiarity with Flent and C++ programming.
* ''Bonus Experience:'' Familiarity with applications supported in ns-3.
* ''Interests:'' Bufferbloat, TCP, AQM algorithms and ECN.
* ''Difficulty:'' Medium.
* ''Recommended Reading:''
** Flexible Network Tester [[https://flent.org/flent-the-flexible-network-tester.pdf Paper]] [[https://flent.org/ Tool]]
** [https://www.nsnam.org/doxygen/d9/dc9/group__applications.html#details Existing Applications in ns-3]
** [https://gitlab.com/tomhenderson/ns-3-dev/-/commits/flent?ref_type=heads Prior work on Flent application API in ns-3]

=== Internet routing refactory ===

Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], [TBD].

Traditionally IP routing tables are organized in tuples {Dst, DstMask, GatewayAddr}, e.g., {10.42.66.0, 255.255.255.0, 169.254.10.1}, plus other flags and data, like the interface to be used.
In ns-3 this is accomplished by storing three separate objects, two Ipv[4,6]Address, and one Ipv[4Mask,6Prefix].

While this is quite simple to implement, this has some notable drawbacks, e.g., the Dst address must be a network address (Dst & ~DstMask == 0), it is not efficient (the mask or prefix could be represented by a simple integer), and more.
In order to improve code readability and consistency between IPv4 and IPv6, !2645 introduces two new classes: Ipv[4,6]NetworkAddress.

The goal is to refactor the existing routing classes, along with Ipv[4,6]RotingTable classes, so that they use the new classes.
The candidate should provide a clear and convincing plan to pursue the above mentioned goal, all while keeping backward compatibility. The APIs of the existing classes must be kept as they are (at most the can be deprecated), and new APIs should be introduced only where strictly necessary.
Another very important requirement will be to break down the work in multiple sub-tasks, so that the merge process can be gradual.

It is not required that the candidate will update the code for all the routing schemes, but the choice of which routing algorithms will be considered during the project must be clear and motivated.

* ''Required Experience:'' Fundamentals of IPv6 addressing and routing, C++ programming.
* ''Interests:'' IPv4 and IPv6 routing
* ''Difficulty:'' Easy.
* ''Recommended reading:''
** [https://gitlab.com/nsnam/ns-3-dev/-/issues/1239 Issue #1239]
** [https://gitlab.com/nsnam/ns-3-dev/-/merge_requests/2645 Merge Request !2645]

Possible tasks to fulfill the patch requirement:
* Use !2645 to modify all or in part the `Rip` protocol.

=== Ping and TraverouteV4 enhancements ===

Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], [TBD].

The Ping and TraverouteV4 ns-3 application have some small limitations.

In particular 2 of them are annoying.
1. Neither Ping nor TracerouteV4 reacts to ICMP errors or informative messages.
2. As the name implies, TracerouteV4 is IPv4-only and can't be used on IPv6.

The goal is to remove the above mentioned limitations, all or in part. A proposal should clearly outline the plan and improvements to the existing code (e.g., the list of the ICMP messages that will be considered), and a clear breakdown of the work. For the TracerouteV4 refactoring to use IPv6 as well, the proposal must consider the Ping implementation as a guideline.

* ''Required Experience:'' Fundamentals of IPv4, IPv6, ICMP, and ICMPv6. C++ programming.
* ''Interests:'' IPv4 and IPv6.
* ''Difficulty:'' Easy.
* ''Recommended reading:''
** [https://gitlab.com/nsnam/ns-3-dev/-/issues/825 Issue #825]

Possible tasks to fulfill the patch requirement:
* MR to have Ping react to one ICMP message.

== Medium sized projects (175 hours) ==

=== 6LoWPAN mesh-under routing enhancements ===

Mentors: [mailto:tommaso.pecorella@unifi.it 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.
Better approaches are possible, e.g., by leveraging some concepts from RFC 7731, by using SNR as a guidance, or by measuring the local network activity.

The candidate should outline the proposed approach, what parts of code are going to be affected, and how they can be enhanced.

* ''Required Experience:'' Fundamentals of IPv6 addressing, C++ programming.
* ''Bonus Experience:'' Familiarity with mesh routing and 6LoWPAN ns-3
* ''Interests:'' IPv6 mesh routing
* ''Difficulty:'' Easy.
* ''Recommended reading:''
** [https://www.nsnam.org/docs/models/html/sixlowpan.html#mesh-under-routing Mesh-under in ns-3 6LoWPAN]
** [https://datatracker.ietf.org/doc/html/rfc7731 RFC 7731]
** [https://meshtastic.org/docs/overview/mesh-algo/ Meshtastic controlled flooding]
** [https://ieeexplore.ieee.org/document/91339 Routing by controlled flooding in communication networks] (if the document can not be accessed, PM the mentors)

Possible tasks to fulfill the patch requirement:
* The current code is hardwired, i.e., the mesh-under routing scheme is embedded into the SixLowPanNetDevice. Propose a patch to decouple it, using a SixLowPanMeshUnderRouting class to determine the "next hop". The behavior of the actual protocol should be unchanged.

=== 6LoWPAN neighbor discovery protocol ===

Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], [mailto:adnan.rashid@poliba.it Adnan Rashid].

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 help merging the code (if it's not already merged) and add some features that are not yet considered in the model.

The candidate should outline in the proposal the features that are planned to be added, and a code mockup (or a complete class diagram) for said features.

* ''Required Experience:'' Fundamentals of IPv6 addressing, C++ programming.
* ''Bonus Experience:'' Familiarity with 6LoWPAN and 6LoWPAN-ND
* ''Interests:'' IPv6 and IoT networks
* ''Difficulty:'' Easy.
* ''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]
** https://gitlab.com/jieqiboh5836/ns-3-dev/-/tree/6LoWPAN-ND-P1
** https://gitlab.com/jieqiboh5836/ns-3-dev/-/tree/6LoWPAN-ND-P2

===OLLA Link Adaptation for 5G-LENA===

Mentors: [mailto:bbojovic@cttc.es Biljana Bojovic], [mailto:tomh@tomh.org Tom Henderson], [mailto:gcarvalho@cttc.es Gabriel Ferreira], [mailto:slagen@cttc.es Sandra Lagen]

This project would focus on improving the realism of the CTTC 5G-LENA by implementing Outer Loop Link Adaptation (OLLA) in the scheduling/link adaptation workflow. In the current baseline, MCS selection is driven by CQI (or SINR-to-CQI mapping) without an outer-loop correction. OLLA is commonly used to track a target BLER by updating an SINR (or CQI) offset based on HARQ ACK/NACK feedback, leading to more stable and realistic link adaptation behavior under varying channel conditions. This project should include this adaptation for the DL and for the UL, integrated in a scheduler-agnostic way so multiple NR schedulers can reuse it with minimal duplication.

In addition, the project would include a performance evaluation:

*comparing the new OLLA-enabled behavior against the current baseline and across multiple representative existing NR schedulers.
*the evaluation should consider throughput, latency, and achieved BLER, including how closely the achieved BLER tracks the configured target.
*the evaluation of the responsiveness to channel condition changes (convergence speed, stability/oscillation behavior).
*the sensitivity to the CQI update frequency and to user data rate / traffic load (how ACK/NACK rate affects convergence).

Additional topics/work items that could be considered if feasible:

*More advanced OLLA algorithms.
*Calibration guidance and/or comparison against published OLLA configurations (when reference data is available).
*Extensions beyond MCS selection (e.g., rank adaptation). This should be relatively easy in the uplink, but for the downlink some advanced mechanism could be investigated and potentially, AI-based approach could be considered.

For starters, we would suggest adding the CTTC 5G-LENA (nr module) to ns-3 (as a module in the contrib/ directory), building and running the NR examples, and becoming familiar with the current scheduler, HARQ feedback flow, CQI/MCS selection, and TBS computation. 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.

*Required Experience: C++ programming, understanding of 5G NR MAC concepts (scheduling, CQI/MCS, HARQ), wireless networking fundamentals
*Interests: 5G NR simulations, scheduling, link adaptation, performance evaluation
*Difficulty: Medium
*Project size: 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.

=== Enabling 5G NR examples visualization ===

Mentors: [mailto:aashtari@cttc.es Amir Ashtari Gargari], [mailto:gcarvalho@cttc.es Gabriel Ferreira], [mailto:bbojovic@cttc.es Biljana Bojovic] and [mailto:kkoutlia@cttc.es Katerina Koutlia]

The main idea of this project is to allow easier visualization of 5G NR examples by integrating the NR module with some ns-3 visualization tools like NetAnim, or by implementing a kind of web-based visualization, e.g., through Jupyter notebook. The new feature should allow the visualization of already existing traces, visualization of topology, or even some new relevant simulation aspects could be considered. The idea is that users better understand how the metrics collection works, and how changing parameters can affect simulation results. In this project, we are open to other ideas on how to implement visualizations. An example scenario is to have e.g. the handover scenario and then be able to see while the UEs are moving and performing handover how their performance metrics vary.

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.
* Recommended reading: Please read this thread in the ns-3 developers list: [https://groups.google.com/g/ns-developers/c/xGCOIAuTYs8/m/yhzpGJkYAwAJ?utm_medium=email&utm_source=footer UI "Designer" for NS3 Based Visual Scripting].

=== AODVv2 Protocol enhancements ===

Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], [TBD].

ns-3 contains models for proactive (DSDV and OLSR) and reactive (AODV and DSR) ad hoc routing protocols. AODVv2 is currently an IETF draft, and its implementation in ns-3 is ongoing. This project aims at enhancing the AODVv2 model for ns-3.

In particular the project should address the following points:
# Alignment with the latest drafts,
# Model finalization and testing (in particular for the IPv6 part),
# AODVv2 examples and documentation,
# "External" network routing support.

Collaboration with the draft authors is also highly suggested.

* ''Required Experience:'' Fundamentals of IPv6 addressing, C++ programming.
* ''Bonus Experience:'' Familiarity with AODV implementations in ns-3 and AODVv2
* ''Interests:'' Ad hoc routing
* ''Difficulty:'' Medium.
* ''Recommended reading:''
** [https://www.nsnam.org/docs/models/html/ipv6.html IPv6 model in ns-3]
** [https://www.nsnam.org/docs/models/html/aodv.html AODV model in ns-3]
** [https://gitlab.com/tod97/ns-3-dev/-/tree/aodvv2-icns3-25 AODVv2 model presented at ICNS3-2025]
** [https://datatracker.ietf.org/doc/draft-perkins-manet-aodvv2/05/ Ad Hoc On-demand Distance Vector Version 2 (AODVv2) Routing]

Possible tasks to fulfill the patch requirement:
* [https://gitlab.com/nsnam/ns-3-dev/-/issues/368 Issue #368] - aodv: aodv parameters can be set to "impossible" values

=== 3GPP Release-19 Feature Integration ===

Mentors: [mailto:bbojovic@cttc.es Biljana Bojovic], [mailto:slagen@cttc.es Sandra Lagen]

This project focuses on improving the realism and standard-alignment of the ns-3 3GPP and 5G-LENA models by integrating new features introduced in 3GPP Release-19. The goal is to extend the current simulator capabilities with updated modeling components that reflect the latest developments in 5G-Advanced standardization.

Potential contributions may include the implementation of new modeling capabilities such as:

* Handheld device antenna placement and orientation models, reflecting realistic UE form-factor constraints and radiation characteristics.
* New channel models introduced or refined in Release-19, such as suburban macro scenarios, including their associated path-loss, shadowing, and spatial consistency characteristics.
* Enhancements to existing propagation or antenna models to better align with recent 3GPP specifications.
* Additional Release-19 features relevant to system-level simulation, potentially including improvements to mobility modeling, link abstraction, or scheduler interactions.

The exact feature to be implemented will be selected jointly with the mentors and the student based on impact, feasibility, and the student's interests.

Once the selected feature has been designed and integrated into ns-3 and 5G-LENA, the student will also be responsible for:

* Developing unit tests and validation test suites to verify the correctness of the implementation.
* Creating example simulation scenarios demonstrating the new capability.
* Performing basic performance validation and calibration against reference assumptions or published models when available.
* Preparing the contribution for integration into the main ns-3 codebase, following the project’s coding and review guidelines.

Possible evaluation aspects:

* Validation of the new feature against 3GPP reference parameters or calibration results.
* Comparison with baseline ns-3 3GPP and 5G-LENA behavior to quantify the impact of the new model.
* Analysis of how the new feature affects system-level metrics, such as throughput, coverage, or interference patterns.

Additional topics that could be considered if time permits include:
* Extending the implemented model to support multiple deployment scenarios (e.g., urban vs suburban).
* Improving configurability of the feature to support research experimentation.
* Investigating how the new modeling capability interacts with other NR components such as scheduling, beamforming, or mobility.

The project will be co-mentored by researchers involved in 3GPP standardization activities, including industry delegates participating in the Release-19 process, ensuring alignment with the latest technical discussions and specifications.

* Required Experience: C++ and Python programming, understanding of 5G NR, LTE, and wireless networks
* Interests: 3GPP calibration, 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 work or MRs to ns-3 or the nr module, you can contact us to check whether it is enough for the patch requirement.
* Recommended reading: [https://arxiv.org/pdf/2507.19266 Overview of 3GPP Release 19 Study on Channel Modeling Enhancements to TR 38.901 for 6G]

== Large projects (350 hours) ==

=== Mesh Link Establishment (MLE) protocol ===

Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], [mailto:alramonet@is.tokushima-u.ac.jp Alberto Gallegos Ramonet].

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:''
** [https://datatracker.ietf.org/doc/html/draft-ietf-6lo-mesh-link-establishment MLE draft]
** [https://openthread.io/guides/thread-primer/network-discovery Thread primer]
** [https://www.threadgroup.org/ThreadSpec Thread specifications]

Possible tasks to fulfill the patch requirement:
* TBD, contact the mentors if interested.

===Energy Consumption Modeling and Power-Aware Extensions for 5G-LENA===

Mentors: [mailto:kkoutlia@cttc.es Katerina Koutlia], [mailto:bbojovic@cttc.es Biljana Bojovic], [mailto:mmiozzo@cttc.es Marco Miozzo] and [mailto:aashtari@cttc.es Amir Ashtari Gargari]

This project would add energy consumption modeling to the CTTC 5G-LENA (NR module). While 5G-LENA provides a detailed and validated simulation of the 5G NR protocol stack behavior, it currently lacks energy models for UEs and/or gNBs, limiting research on energy efficiency, green networking, 6G sustainability, and potentially AI-driven power-aware control.
The project would first evaluate reuse of the ns-3 Energy Framework (e.g., EnergySource, DeviceEnergyModel) by defining a clean interface between 5G-LENA and the energy module. If existing models are insufficient, the project would design and implement a 5G-specific device energy model (e.g., NrDeviceEnergyModel) and connect it to relevant 5G-LENA state/procedure events.
For starters, we would suggest adding the CTTC 5G-LENA (nr module) to ns-3 (as a module in the contrib/ directory), building and running the NR examples, and studying the Energy Framework integration patterns. Documentation is available here: https://5g-lena.cttc.es/. Tutorial video: https://acmse.net/2021/tutorials-offered/#tut-work03.

Scope (expected deliverables):
*Energy consumption accounting for UEs and/or gNBs
*Per-state (and if feasible per-procedure) modeling, e.g.
**gNB: idle/active/sleep, TX/RX, processing; dependence on bandwidth/PRBs, TX power, MIMO layers/streams/RF chains, load
**UE: TX/RX, measurements, CSI-RS/SRS activity, beamforming-related processing, handover
*Tracing, example(s), and documentation

Optional (time permitting): a simple energy-aware scheduling extension to explore QoS trade-offs (e.g., energy-per-bit or energy-aware MIMO under GBR)

*Required Experience: C++ programming, wireless networking fundamentals (energy/state-machine modeling is a plus)
*Interests: 5G NR simulations, energy efficiency, green networking, 6G sustainability
*Difficulty: Medium
*Project size: 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 integration with ns-3-ai ===

Mentors: [mailto:kkoutlia@cttc.es Katerina Koutlia], [mailto:gcarvalho@cttc.es Gabriel Ferreira], [mailto:aashtari@cttc.es Amir Ashtari Gargari] and [mailto:bbojovic@cttc.es Biljana Bojovic]

The objective of this project is to integrate the ns-3 5G NR module with [https://apps.nsnam.org/app/ns3-ai/ ns-3-ai]. In GSoC 2024 we had a project in which 5G NR was integrated with [https://www.nsnam.org/wiki/GSOC2024RLUsability5G ns-3 gym]. While ns-3 gym is a popular ns-3 module for AI, it is limited to the application of reinforcement learning techniques in networking research. On the other hand, ns-3-ai module provides a more general solution that enables the data interaction between ns-3 and other Python-based AI frameworks, like [https://www.tensorflow.org/api_docs/cc Tensorflow C++ APIs] and [https://pytorch.org/cppdocs/ PyTorch C++ APIs], which opens the door to use different machine learning-based techniques in 5G NR models. The correct functioning of the integration should be tested, and documented, and a fully working example using ns-3-ai should be provided. The contributor can propose a use-case scenario for matching learning. One option is to use it for MAC scheduling, but it could be used for other 5G related research problems, and the contributor is encouraged to propose the use case of his/her interest.

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.
* 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.

=== Linux-like CAKE queue discipline for ns-3 ===

Mentors: [mailto:tahiliani.nitk@gmail.com Mohit P. Tahiliani]

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.

* ''Required Experience:'' Familiarity with queue disciplines, TCP and C++ programming.
* ''Bonus Experience:'' Familiarity with CAKE framework in Linux 4.19
* ''Interests:'' Active Queue Management, Packet scheduling and TCP.
* ''Difficulty:'' Medium to Hard
* ''Recommended reading:''
** [https://arxiv.org/pdf/1804.07617.pdf Piece of CAKE: A Comprehensive Queue Management Solution for Home Gateways]
** [https://lwn.net/Articles/758353/ Let them run CAKE]
** [https://www.nsnam.org/docs/models/html/queue-discs.html Queue disciplines in ns-3]

=== Switched Ethernet ===

Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], TBD.

The current ns-3 models for wired connections are fine for simple networks, but the lack of a switched Ethernet model is a limitation in some cases.

The goal of the idea is to create, test, and document a Switched Ethernet model, able to simulate (at least) 1, 10, and 40 GbE links and model for a switch.

The model of the NetDevice and Channel shall take into account the link delays and errors, similarly to what is done by the point-to-point model. Futhermore, it should be able to set the link speed and if it is full-duplex or half-duplex. Additional support for flow control is a bonus, but not strictly required. Link speed auto-negotiation is not considered to be interesting.

The model for the switch should be modular (i.e., allowing the development of different switch types), and include auto-learning of I/O ports based on the MAC address, i.e., have a MAC/port table, and a basic store-and-forward operation. Features like advanced I/O buffer handling and ARP/NDP spoofing detection are not a priority and shall be left for future implementations.

The model should consider the future implementaion of algorithms like VLANs (IEEE 802.1Q, 802.1ad), and the Spanning Tree Protocol (IEEE 802.1D, 802.1w, and 802.1s). Their implementaion is not required, but the model design should allow their development.

* ''Required Experience:'' Fundamentals of Ethernet sitched networking, C++ programming.
* ''Interests:'' Ethernet networks and switched data networks.
* ''Difficulty:'' Medium.
* ''Recommended reading:''
** [https://codereview.appspot.com/5615049/ Basic implementation (very old)]
** [https://gitlab.com/nsnam/ns-3-dev/-/merge_requests/431 Full-duplex CSMA, somehow related]
** [https://tcipg.org/sites/default/files/papers/2010_Jin_Nicol_Caesar.pdf Paper on gigabit Ethernet switch models for simulation]

Possible tasks to fulfill the patch requirement:
* TBD, contact the mentors if interested.

GSOC2026Projects

2026-03-13T09:50:11Z

Biljana: /* Medium sized projects (175 hours) */

{{TOC}}

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

* [https://developers.google.com/open-source/gsoc/faq GSoC Frequently Asked Questions]
* [[GSOC2026ContributorGuide | ns-3's 2026 GSoC Contributor guide]]
* [https://developers.google.com/open-source/gsoc/resources/guide GSoC contributor/student guide (not ns-3 specific)]
* [[GSOC2025ApplicationTemplate | 2026 GSoC Contributor application template]]
* [[GSOCMentorGuide | ns-3's GSoC Mentor guide]]
* [https://archive.flossmanuals.net/gsocmentoring/index.html GSoC Mentor guide (not ns-3 specific)]
* [[GSOCSelectionProcess | GSoC Contributor Selection Process]]
* ''Get in contact with the ns-3 team'': [https://groups.google.com/g/ns-developers 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-25. 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 [mailto:tpecorella@mac.com Tommaso Pecorella] and [mailto:tahiliani.nitk@gmail.com Mohit P. Tahiliani]; contact them with any questions. They also hang out on [https://ns-3.zulipchat.com 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 [https://developers.google.com/open-source/gsoc/resources/guide GSoC contributor guide].
* Read [[GSOC2026ContributorGuide |ns-3's 2026 GSoC contributor guide]]
* 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.
* Once it is posted, look through the [[GSOC2024ApplicationTemplate |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 2026, 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 2026. 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 suggests 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>
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.
</blockquote>

=== Patch requirement guidelines ===

In past years, we have asked applicants to submit a patch related to an open issue or a suggested coding exercise. We are undecided at this time whether we will ask for this in 2026; check back later.

=== 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 ===

* [[#Flent Application API in ns-3]] (small size project, 90h)
* [[#Ping and TraverouteV4 enhancements]] (small size project, 90h)
* [[#Internet routing refactory]] (small size project, 90h)
* [[#AODVv2 Protocol enhancements]] (medium size project, 175h)
* [[#Linux-like CAKE queue discipline for ns-3]] (large size project, 350h)
* [[#Switched Ethernet]] (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)

=== 5G NR models enhancements ===

The general idea is to improve the usability of the 5G NR module by adding new examples that help users start building scenario scripts. Also, an interesting improvement could be integration with other modules, like those for AI or visualizations. Here are some project ideas. Depending on the contributor's interest and skills we can adjust these projects' definitions.

* [[#OLLA Link Adaptation and Spec-Compliant TBS Calculation for 5G-LENA]](medium size project, 175h)
* [[#Enabling 5G NR examples visualization]] (medium size project, 175h)
* [[#Energy Consumption Modeling and Power-Aware Extensions for 5G-LENA]](medium size project, 250h)
* [[#5G NR module integration with ns-3-ai]] (large size project, 250h)

== Small sized projects (90 hours) ==

=== Flent Application API in ns-3 ===

Mentors: [mailto:tahiliani.nitk@gmail.com Mohit P. Tahiliani]

Flexible Network Tester (Flent) is a network benchmarking tool. It is written in Python and wraps well-known network benchmarking tools (such as netperf and iperf) into aggregate, repeatable tests, such as a number of tests for Bufferbloat. A basic structure for Flent Application API in ns-3 has been developed. It is a wrapper around existing ns-3 applications. This project has four main goals: (1) update this implementation to match the current ns-3-dev, (2) integrate a JSON library properly (for Flent-style result handling) (3) validate correctness of Flent results produced by ns-3, and (4) Add more Flent-style test examples useful for ns-3 users. The goal of this project is to merge the Flent Application API into ns-3 mainline, not the app store.

* ''Required Experience:'' Familiarity with Flent and C++ programming.
* ''Bonus Experience:'' Familiarity with applications supported in ns-3.
* ''Interests:'' Bufferbloat, TCP, AQM algorithms and ECN.
* ''Difficulty:'' Medium.
* ''Recommended Reading:''
** Flexible Network Tester [[https://flent.org/flent-the-flexible-network-tester.pdf Paper]] [[https://flent.org/ Tool]]
** [https://www.nsnam.org/doxygen/d9/dc9/group__applications.html#details Existing Applications in ns-3]
** [https://gitlab.com/tomhenderson/ns-3-dev/-/commits/flent?ref_type=heads Prior work on Flent application API in ns-3]

=== Internet routing refactory ===

Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], [TBD].

Traditionally IP routing tables are organized in tuples {Dst, DstMask, GatewayAddr}, e.g., {10.42.66.0, 255.255.255.0, 169.254.10.1}, plus other flags and data, like the interface to be used.
In ns-3 this is accomplished by storing three separate objects, two Ipv[4,6]Address, and one Ipv[4Mask,6Prefix].

While this is quite simple to implement, this has some notable drawbacks, e.g., the Dst address must be a network address (Dst & ~DstMask == 0), it is not efficient (the mask or prefix could be represented by a simple integer), and more.
In order to improve code readability and consistency between IPv4 and IPv6, !2645 introduces two new classes: Ipv[4,6]NetworkAddress.

The goal is to refactor the existing routing classes, along with Ipv[4,6]RotingTable classes, so that they use the new classes.
The candidate should provide a clear and convincing plan to pursue the above mentioned goal, all while keeping backward compatibility. The APIs of the existing classes must be kept as they are (at most the can be deprecated), and new APIs should be introduced only where strictly necessary.
Another very important requirement will be to break down the work in multiple sub-tasks, so that the merge process can be gradual.

It is not required that the candidate will update the code for all the routing schemes, but the choice of which routing algorithms will be considered during the project must be clear and motivated.

* ''Required Experience:'' Fundamentals of IPv6 addressing and routing, C++ programming.
* ''Interests:'' IPv4 and IPv6 routing
* ''Difficulty:'' Easy.
* ''Recommended reading:''
** [https://gitlab.com/nsnam/ns-3-dev/-/issues/1239 Issue #1239]
** [https://gitlab.com/nsnam/ns-3-dev/-/merge_requests/2645 Merge Request !2645]

Possible tasks to fulfill the patch requirement:
* Use !2645 to modify all or in part the `Rip` protocol.

=== Ping and TraverouteV4 enhancements ===

Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], [TBD].

The Ping and TraverouteV4 ns-3 application have some small limitations.

In particular 2 of them are annoying.
1. Neither Ping nor TracerouteV4 reacts to ICMP errors or informative messages.
2. As the name implies, TracerouteV4 is IPv4-only and can't be used on IPv6.

The goal is to remove the above mentioned limitations, all or in part. A proposal should clearly outline the plan and improvements to the existing code (e.g., the list of the ICMP messages that will be considered), and a clear breakdown of the work. For the TracerouteV4 refactoring to use IPv6 as well, the proposal must consider the Ping implementation as a guideline.

* ''Required Experience:'' Fundamentals of IPv4, IPv6, ICMP, and ICMPv6. C++ programming.
* ''Interests:'' IPv4 and IPv6.
* ''Difficulty:'' Easy.
* ''Recommended reading:''
** [https://gitlab.com/nsnam/ns-3-dev/-/issues/825 Issue #825]

Possible tasks to fulfill the patch requirement:
* MR to have Ping react to one ICMP message.

== Medium sized projects (175 hours) ==

=== 6LoWPAN mesh-under routing enhancements ===

Mentors: [mailto:tommaso.pecorella@unifi.it 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.
Better approaches are possible, e.g., by leveraging some concepts from RFC 7731, by using SNR as a guidance, or by measuring the local network activity.

The candidate should outline the proposed approach, what parts of code are going to be affected, and how they can be enhanced.

* ''Required Experience:'' Fundamentals of IPv6 addressing, C++ programming.
* ''Bonus Experience:'' Familiarity with mesh routing and 6LoWPAN ns-3
* ''Interests:'' IPv6 mesh routing
* ''Difficulty:'' Easy.
* ''Recommended reading:''
** [https://www.nsnam.org/docs/models/html/sixlowpan.html#mesh-under-routing Mesh-under in ns-3 6LoWPAN]
** [https://datatracker.ietf.org/doc/html/rfc7731 RFC 7731]
** [https://meshtastic.org/docs/overview/mesh-algo/ Meshtastic controlled flooding]
** [https://ieeexplore.ieee.org/document/91339 Routing by controlled flooding in communication networks] (if the document can not be accessed, PM the mentors)

Possible tasks to fulfill the patch requirement:
* The current code is hardwired, i.e., the mesh-under routing scheme is embedded into the SixLowPanNetDevice. Propose a patch to decouple it, using a SixLowPanMeshUnderRouting class to determine the "next hop". The behavior of the actual protocol should be unchanged.

=== 6LoWPAN neighbor discovery protocol ===

Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], [mailto:adnan.rashid@poliba.it Adnan Rashid].

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 help merging the code (if it's not already merged) and add some features that are not yet considered in the model.

The candidate should outline in the proposal the features that are planned to be added, and a code mockup (or a complete class diagram) for said features.

* ''Required Experience:'' Fundamentals of IPv6 addressing, C++ programming.
* ''Bonus Experience:'' Familiarity with 6LoWPAN and 6LoWPAN-ND
* ''Interests:'' IPv6 and IoT networks
* ''Difficulty:'' Easy.
* ''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]
** https://gitlab.com/jieqiboh5836/ns-3-dev/-/tree/6LoWPAN-ND-P1
** https://gitlab.com/jieqiboh5836/ns-3-dev/-/tree/6LoWPAN-ND-P2

===OLLA Link Adaptation for 5G-LENA===

Mentors: [mailto:bbojovic@cttc.es Biljana Bojovic], [mailto:tomh@tomh.org Tom Henderson], [mailto:gcarvalho@cttc.es Gabriel Ferreira], [mailto:slagen@cttc.es Sandra Lagen]

This project would focus on improving the realism of the CTTC 5G-LENA by implementing Outer Loop Link Adaptation (OLLA) in the scheduling/link adaptation workflow. In the current baseline, MCS selection is driven by CQI (or SINR-to-CQI mapping) without an outer-loop correction. OLLA is commonly used to track a target BLER by updating an SINR (or CQI) offset based on HARQ ACK/NACK feedback, leading to more stable and realistic link adaptation behavior under varying channel conditions. This project should include this adaptation for the DL and for the UL, integrated in a scheduler-agnostic way so multiple NR schedulers can reuse it with minimal duplication.

In addition, the project would include a performance evaluation:

*comparing the new OLLA-enabled behavior against the current baseline and across multiple representative existing NR schedulers.
*the evaluation should consider throughput, latency, and achieved BLER, including how closely the achieved BLER tracks the configured target.
*the evaluation of the responsiveness to channel condition changes (convergence speed, stability/oscillation behavior).
*the sensitivity to the CQI update frequency and to user data rate / traffic load (how ACK/NACK rate affects convergence).

Additional topics/work items that could be considered if feasible:

*More advanced OLLA algorithms.
*Calibration guidance and/or comparison against published OLLA configurations (when reference data is available).
*Extensions beyond MCS selection (e.g., rank adaptation). This should be relatively easy in the uplink, but for the downlink some advanced mechanism could be investigated and potentially, AI-based approach could be considered.

For starters, we would suggest adding the CTTC 5G-LENA (nr module) to ns-3 (as a module in the contrib/ directory), building and running the NR examples, and becoming familiar with the current scheduler, HARQ feedback flow, CQI/MCS selection, and TBS computation. 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.

*Required Experience: C++ programming, understanding of 5G NR MAC concepts (scheduling, CQI/MCS, HARQ), wireless networking fundamentals
*Interests: 5G NR simulations, scheduling, link adaptation, performance evaluation
*Difficulty: Medium
*Project size: 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.

=== Enabling 5G NR examples visualization ===

Mentors: [mailto:aashtari@cttc.es Amir Ashtari Gargari], [mailto:gcarvalho@cttc.es Gabriel Ferreira], [mailto:bbojovic@cttc.es Biljana Bojovic] and [mailto:kkoutlia@cttc.es Katerina Koutlia]

The main idea of this project is to allow easier visualization of 5G NR examples by integrating the NR module with some ns-3 visualization tools like NetAnim, or by implementing a kind of web-based visualization, e.g., through Jupyter notebook. The new feature should allow the visualization of already existing traces, visualization of topology, or even some new relevant simulation aspects could be considered. The idea is that users better understand how the metrics collection works, and how changing parameters can affect simulation results. In this project, we are open to other ideas on how to implement visualizations. An example scenario is to have e.g. the handover scenario and then be able to see while the UEs are moving and performing handover how their performance metrics vary.

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.
* Recommended reading: Please read this thread in the ns-3 developers list: [https://groups.google.com/g/ns-developers/c/xGCOIAuTYs8/m/yhzpGJkYAwAJ?utm_medium=email&utm_source=footer UI "Designer" for NS3 Based Visual Scripting].

=== AODVv2 Protocol enhancements ===

Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], [TBD].

ns-3 contains models for proactive (DSDV and OLSR) and reactive (AODV and DSR) ad hoc routing protocols. AODVv2 is currently an IETF draft, and its implementation in ns-3 is ongoing. This project aims at enhancing the AODVv2 model for ns-3.

In particular the project should address the following points:
# Alignment with the latest drafts,
# Model finalization and testing (in particular for the IPv6 part),
# AODVv2 examples and documentation,
# "External" network routing support.

Collaboration with the draft authors is also highly suggested.

* ''Required Experience:'' Fundamentals of IPv6 addressing, C++ programming.
* ''Bonus Experience:'' Familiarity with AODV implementations in ns-3 and AODVv2
* ''Interests:'' Ad hoc routing
* ''Difficulty:'' Medium.
* ''Recommended reading:''
** [https://www.nsnam.org/docs/models/html/ipv6.html IPv6 model in ns-3]
** [https://www.nsnam.org/docs/models/html/aodv.html AODV model in ns-3]
** [https://gitlab.com/tod97/ns-3-dev/-/tree/aodvv2-icns3-25 AODVv2 model presented at ICNS3-2025]
** [https://datatracker.ietf.org/doc/draft-perkins-manet-aodvv2/05/ Ad Hoc On-demand Distance Vector Version 2 (AODVv2) Routing]

Possible tasks to fulfill the patch requirement:
* [https://gitlab.com/nsnam/ns-3-dev/-/issues/368 Issue #368] - aodv: aodv parameters can be set to "impossible" values

=== 3GPP Release-19 Feature Integration ===

Mentors: [mailto:bbojovic@cttc.es Biljana Bojovic], [mailto:slagen@cttc.es Sandra Lagen]

This project focuses on improving the realism and standard-alignment of the ns-3 3GPP and 5G-LENA models by integrating new features introduced in 3GPP Release-19. The goal is to extend the current simulator capabilities with updated modeling components that reflect the latest developments in 5G-Advanced standardization.

Potential contributions may include the implementation of new modeling capabilities such as:

* Handheld device antenna placement and orientation models, reflecting realistic UE form-factor constraints and radiation characteristics.
* New channel models introduced or refined in Release-19, such as suburban macro scenarios, including their associated path-loss, shadowing, and spatial consistency characteristics.
* Enhancements to existing propagation or antenna models to better align with recent 3GPP specifications.
* Additional Release-19 features relevant to system-level simulation, potentially including improvements to mobility modeling, link abstraction, or scheduler interactions.

The exact feature to be implemented will be selected jointly with the mentors and the student based on impact, feasibility, and the student's interests.

Once the selected feature has been designed and integrated into ns-3 and 5G-LENA, the student will also be responsible for:

* Developing unit tests and validation test suites to verify the correctness of the implementation.
* Creating example simulation scenarios demonstrating the new capability.
* Performing basic performance validation and calibration against reference assumptions or published models when available.
* Preparing the contribution for integration into the main ns-3 codebase, following the project’s coding and review guidelines.

Possible evaluation aspects:

* Validation of the new feature against 3GPP reference parameters or calibration results.
* Comparison with baseline ns-3 3GPP and 5G-LENA behavior to quantify the impact of the new model.
* Analysis of how the new feature affects system-level metrics, such as throughput, coverage, or interference patterns.

Additional topics that could be considered if time permits include:
* Extending the implemented model to support multiple deployment scenarios (e.g., urban vs suburban).
* Improving configurability of the feature to support research experimentation.
* Investigating how the new modeling capability interacts with other NR components such as scheduling, beamforming, or mobility.

The project will be co-mentored by researchers involved in 3GPP standardization activities, including industry delegates participating in the Release-19 process, ensuring alignment with the latest technical discussions and specifications.

* Required Experience: C++ and Python programming, understanding of 5G NR, LTE, and wireless networks
* Interests: 3GPP calibration, 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 work or MRs to ns-3 or the nr module, you can contact us to check whether it is enough for the patch requirement.
* Recommended reading: [https://arxiv.org/pdf/2507.19266 Overview of 3GPP Release 19 Study on Channel Modeling Enhancements to TR 38.901 for 6G]

== Large projects (350 hours) ==

=== Mesh Link Establishment (MLE) protocol ===

Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], [mailto:alramonet@is.tokushima-u.ac.jp Alberto Gallegos Ramonet].

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:''
** [https://datatracker.ietf.org/doc/html/draft-ietf-6lo-mesh-link-establishment MLE draft]
** [https://openthread.io/guides/thread-primer/network-discovery Thread primer]
** [https://www.threadgroup.org/ThreadSpec Thread specifications]

Possible tasks to fulfill the patch requirement:
* TBD, contact the mentors if interested.

===Energy Consumption Modeling and Power-Aware Extensions for 5G-LENA===

Mentors: [mailto:kkoutlia@cttc.es Katerina Koutlia], [mailto:bbojovic@cttc.es Biljana Bojovic], [mailto:mmiozzo@cttc.es Marco Miozzo] and [mailto:aashtari@cttc.es Amir Ashtari Gargari]

This project would add energy consumption modeling to the CTTC 5G-LENA (NR module). While 5G-LENA provides a detailed and validated simulation of the 5G NR protocol stack behavior, it currently lacks energy models for UEs and/or gNBs, limiting research on energy efficiency, green networking, 6G sustainability, and potentially AI-driven power-aware control.
The project would first evaluate reuse of the ns-3 Energy Framework (e.g., EnergySource, DeviceEnergyModel) by defining a clean interface between 5G-LENA and the energy module. If existing models are insufficient, the project would design and implement a 5G-specific device energy model (e.g., NrDeviceEnergyModel) and connect it to relevant 5G-LENA state/procedure events.
For starters, we would suggest adding the CTTC 5G-LENA (nr module) to ns-3 (as a module in the contrib/ directory), building and running the NR examples, and studying the Energy Framework integration patterns. Documentation is available here: https://5g-lena.cttc.es/. Tutorial video: https://acmse.net/2021/tutorials-offered/#tut-work03.

Scope (expected deliverables):
*Energy consumption accounting for UEs and/or gNBs
*Per-state (and if feasible per-procedure) modeling, e.g.
**gNB: idle/active/sleep, TX/RX, processing; dependence on bandwidth/PRBs, TX power, MIMO layers/streams/RF chains, load
**UE: TX/RX, measurements, CSI-RS/SRS activity, beamforming-related processing, handover
*Tracing, example(s), and documentation

Optional (time permitting): a simple energy-aware scheduling extension to explore QoS trade-offs (e.g., energy-per-bit or energy-aware MIMO under GBR)

*Required Experience: C++ programming, wireless networking fundamentals (energy/state-machine modeling is a plus)
*Interests: 5G NR simulations, energy efficiency, green networking, 6G sustainability
*Difficulty: Medium
*Project size: 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 integration with ns-3-ai ===

Mentors: [mailto:kkoutlia@cttc.es Katerina Koutlia], [mailto:gcarvalho@cttc.es Gabriel Ferreira], [mailto:aashtari@cttc.es Amir Ashtari Gargari] and [mailto:bbojovic@cttc.es Biljana Bojovic]

The objective of this project is to integrate the ns-3 5G NR module with [https://apps.nsnam.org/app/ns3-ai/ ns-3-ai]. In GSoC 2024 we had a project in which 5G NR was integrated with [https://www.nsnam.org/wiki/GSOC2024RLUsability5G ns-3 gym]. While ns-3 gym is a popular ns-3 module for AI, it is limited to the application of reinforcement learning techniques in networking research. On the other hand, ns-3-ai module provides a more general solution that enables the data interaction between ns-3 and other Python-based AI frameworks, like [https://www.tensorflow.org/api_docs/cc Tensorflow C++ APIs] and [https://pytorch.org/cppdocs/ PyTorch C++ APIs], which opens the door to use different machine learning-based techniques in 5G NR models. The correct functioning of the integration should be tested, and documented, and a fully working example using ns-3-ai should be provided. The contributor can propose a use-case scenario for matching learning. One option is to use it for MAC scheduling, but it could be used for other 5G related research problems, and the contributor is encouraged to propose the use case of his/her interest.

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.
* 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.

=== Linux-like CAKE queue discipline for ns-3 ===

Mentors: [mailto:tahiliani.nitk@gmail.com Mohit P. Tahiliani]

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.

* ''Required Experience:'' Familiarity with queue disciplines, TCP and C++ programming.
* ''Bonus Experience:'' Familiarity with CAKE framework in Linux 4.19
* ''Interests:'' Active Queue Management, Packet scheduling and TCP.
* ''Difficulty:'' Medium to Hard
* ''Recommended reading:''
** [https://arxiv.org/pdf/1804.07617.pdf Piece of CAKE: A Comprehensive Queue Management Solution for Home Gateways]
** [https://lwn.net/Articles/758353/ Let them run CAKE]
** [https://www.nsnam.org/docs/models/html/queue-discs.html Queue disciplines in ns-3]

=== Switched Ethernet ===

Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], TBD.

The current ns-3 models for wired connections are fine for simple networks, but the lack of a switched Ethernet model is a limitation in some cases.

The goal of the idea is to create, test, and document a Switched Ethernet model, able to simulate (at least) 1, 10, and 40 GbE links and model for a switch.

The model of the NetDevice and Channel shall take into account the link delays and errors, similarly to what is done by the point-to-point model. Futhermore, it should be able to set the link speed and if it is full-duplex or half-duplex. Additional support for flow control is a bonus, but not strictly required. Link speed auto-negotiation is not considered to be interesting.

The model for the switch should be modular (i.e., allowing the development of different switch types), and include auto-learning of I/O ports based on the MAC address, i.e., have a MAC/port table, and a basic store-and-forward operation. Features like advanced I/O buffer handling and ARP/NDP spoofing detection are not a priority and shall be left for future implementations.

The model should consider the future implementaion of algorithms like VLANs (IEEE 802.1Q, 802.1ad), and the Spanning Tree Protocol (IEEE 802.1D, 802.1w, and 802.1s). Their implementaion is not required, but the model design should allow their development.

* ''Required Experience:'' Fundamentals of Ethernet sitched networking, C++ programming.
* ''Interests:'' Ethernet networks and switched data networks.
* ''Difficulty:'' Medium.
* ''Recommended reading:''
** [https://codereview.appspot.com/5615049/ Basic implementation (very old)]
** [https://gitlab.com/nsnam/ns-3-dev/-/merge_requests/431 Full-duplex CSMA, somehow related]
** [https://tcipg.org/sites/default/files/papers/2010_Jin_Nicol_Caesar.pdf Paper on gigabit Ethernet switch models for simulation]

Possible tasks to fulfill the patch requirement:
* TBD, contact the mentors if interested.

GSOC2026Projects

2026-03-12T11:55:45Z

Biljana: /* Enabling 5G NR examples visualization */

{{TOC}}

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

* [https://developers.google.com/open-source/gsoc/faq GSoC Frequently Asked Questions]
* [[GSOC2026ContributorGuide | ns-3's 2026 GSoC Contributor guide]]
* [https://developers.google.com/open-source/gsoc/resources/guide GSoC contributor/student guide (not ns-3 specific)]
* [[GSOC2025ApplicationTemplate | 2026 GSoC Contributor application template]]
* [[GSOCMentorGuide | ns-3's GSoC Mentor guide]]
* [https://archive.flossmanuals.net/gsocmentoring/index.html GSoC Mentor guide (not ns-3 specific)]
* [[GSOCSelectionProcess | GSoC Contributor Selection Process]]
* ''Get in contact with the ns-3 team'': [https://groups.google.com/g/ns-developers 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-25. 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 [mailto:tpecorella@mac.com Tommaso Pecorella] and [mailto:tahiliani.nitk@gmail.com Mohit P. Tahiliani]; contact them with any questions. They also hang out on [https://ns-3.zulipchat.com 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 [https://developers.google.com/open-source/gsoc/resources/guide GSoC contributor guide].
* Read [[GSOC2026ContributorGuide |ns-3's 2026 GSoC contributor guide]]
* 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.
* Once it is posted, look through the [[GSOC2024ApplicationTemplate |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 2026, 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 2026. 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 suggests 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>
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.
</blockquote>

=== Patch requirement guidelines ===

In past years, we have asked applicants to submit a patch related to an open issue or a suggested coding exercise. We are undecided at this time whether we will ask for this in 2026; check back later.

=== 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 ===

* [[#Flent Application API in ns-3]] (small size project, 90h)
* [[#Ping and TraverouteV4 enhancements]] (small size project, 90h)
* [[#Internet routing refactory]] (small size project, 90h)
* [[#AODVv2 Protocol enhancements]] (medium size project, 175h)
* [[#Linux-like CAKE queue discipline for ns-3]] (large size project, 350h)
* [[#Switched Ethernet]] (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)

=== 5G NR models enhancements ===

The general idea is to improve the usability of the 5G NR module by adding new examples that help users start building scenario scripts. Also, an interesting improvement could be integration with other modules, like those for AI or visualizations. Here are some project ideas. Depending on the contributor's interest and skills we can adjust these projects' definitions.

* [[#OLLA Link Adaptation and Spec-Compliant TBS Calculation for 5G-LENA]](medium size project, 175h)
* [[#Enabling 5G NR examples visualization]] (medium size project, 175h)
* [[#Energy Consumption Modeling and Power-Aware Extensions for 5G-LENA]](medium size project, 250h)
* [[#5G NR module integration with ns-3-ai]] (large size project, 250h)

== Small sized projects (90 hours) ==

=== Flent Application API in ns-3 ===

Mentors: [mailto:tahiliani.nitk@gmail.com Mohit P. Tahiliani]

Flexible Network Tester (Flent) is a network benchmarking tool. It is written in Python and wraps well-known network benchmarking tools (such as netperf and iperf) into aggregate, repeatable tests, such as a number of tests for Bufferbloat. A basic structure for Flent Application API in ns-3 has been developed. It is a wrapper around existing ns-3 applications. This project has four main goals: (1) update this implementation to match the current ns-3-dev, (2) integrate a JSON library properly (for Flent-style result handling) (3) validate correctness of Flent results produced by ns-3, and (4) Add more Flent-style test examples useful for ns-3 users. The goal of this project is to merge the Flent Application API into ns-3 mainline, not the app store.

* ''Required Experience:'' Familiarity with Flent and C++ programming.
* ''Bonus Experience:'' Familiarity with applications supported in ns-3.
* ''Interests:'' Bufferbloat, TCP, AQM algorithms and ECN.
* ''Difficulty:'' Medium.
* ''Recommended Reading:''
** Flexible Network Tester [[https://flent.org/flent-the-flexible-network-tester.pdf Paper]] [[https://flent.org/ Tool]]
** [https://www.nsnam.org/doxygen/d9/dc9/group__applications.html#details Existing Applications in ns-3]
** [https://gitlab.com/tomhenderson/ns-3-dev/-/commits/flent?ref_type=heads Prior work on Flent application API in ns-3]

=== Internet routing refactory ===

Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], [TBD].

Traditionally IP routing tables are organized in tuples {Dst, DstMask, GatewayAddr}, e.g., {10.42.66.0, 255.255.255.0, 169.254.10.1}, plus other flags and data, like the interface to be used.
In ns-3 this is accomplished by storing three separate objects, two Ipv[4,6]Address, and one Ipv[4Mask,6Prefix].

While this is quite simple to implement, this has some notable drawbacks, e.g., the Dst address must be a network address (Dst & ~DstMask == 0), it is not efficient (the mask or prefix could be represented by a simple integer), and more.
In order to improve code readability and consistency between IPv4 and IPv6, !2645 introduces two new classes: Ipv[4,6]NetworkAddress.

The goal is to refactor the existing routing classes, along with Ipv[4,6]RotingTable classes, so that they use the new classes.
The candidate should provide a clear and convincing plan to pursue the above mentioned goal, all while keeping backward compatibility. The APIs of the existing classes must be kept as they are (at most the can be deprecated), and new APIs should be introduced only where strictly necessary.
Another very important requirement will be to break down the work in multiple sub-tasks, so that the merge process can be gradual.

It is not required that the candidate will update the code for all the routing schemes, but the choice of which routing algorithms will be considered during the project must be clear and motivated.

* ''Required Experience:'' Fundamentals of IPv6 addressing and routing, C++ programming.
* ''Interests:'' IPv4 and IPv6 routing
* ''Difficulty:'' Easy.
* ''Recommended reading:''
** [https://gitlab.com/nsnam/ns-3-dev/-/issues/1239 Issue #1239]
** [https://gitlab.com/nsnam/ns-3-dev/-/merge_requests/2645 Merge Request !2645]

Possible tasks to fulfill the patch requirement:
* Use !2645 to modify all or in part the `Rip` protocol.

=== Ping and TraverouteV4 enhancements ===

Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], [TBD].

The Ping and TraverouteV4 ns-3 application have some small limitations.

In particular 2 of them are annoying.
1. Neither Ping nor TracerouteV4 reacts to ICMP errors or informative messages.
2. As the name implies, TracerouteV4 is IPv4-only and can't be used on IPv6.

The goal is to remove the above mentioned limitations, all or in part. A proposal should clearly outline the plan and improvements to the existing code (e.g., the list of the ICMP messages that will be considered), and a clear breakdown of the work. For the TracerouteV4 refactoring to use IPv6 as well, the proposal must consider the Ping implementation as a guideline.

* ''Required Experience:'' Fundamentals of IPv4, IPv6, ICMP, and ICMPv6. C++ programming.
* ''Interests:'' IPv4 and IPv6.
* ''Difficulty:'' Easy.
* ''Recommended reading:''
** [https://gitlab.com/nsnam/ns-3-dev/-/issues/825 Issue #825]

Possible tasks to fulfill the patch requirement:
* MR to have Ping react to one ICMP message.

== Medium sized projects (175 hours) ==

=== 6LoWPAN mesh-under routing enhancements ===

Mentors: [mailto:tommaso.pecorella@unifi.it 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.
Better approaches are possible, e.g., by leveraging some concepts from RFC 7731, by using SNR as a guidance, or by measuring the local network activity.

The candidate should outline the proposed approach, what parts of code are going to be affected, and how they can be enhanced.

* ''Required Experience:'' Fundamentals of IPv6 addressing, C++ programming.
* ''Bonus Experience:'' Familiarity with mesh routing and 6LoWPAN ns-3
* ''Interests:'' IPv6 mesh routing
* ''Difficulty:'' Easy.
* ''Recommended reading:''
** [https://www.nsnam.org/docs/models/html/sixlowpan.html#mesh-under-routing Mesh-under in ns-3 6LoWPAN]
** [https://datatracker.ietf.org/doc/html/rfc7731 RFC 7731]
** [https://meshtastic.org/docs/overview/mesh-algo/ Meshtastic controlled flooding]
** [https://ieeexplore.ieee.org/document/91339 Routing by controlled flooding in communication networks] (if the document can not be accessed, PM the mentors)

Possible tasks to fulfill the patch requirement:
* The current code is hardwired, i.e., the mesh-under routing scheme is embedded into the SixLowPanNetDevice. Propose a patch to decouple it, using a SixLowPanMeshUnderRouting class to determine the "next hop". The behavior of the actual protocol should be unchanged.

=== 6LoWPAN neighbor discovery protocol ===

Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], [mailto:adnan.rashid@poliba.it Adnan Rashid].

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 help merging the code (if it's not already merged) and add some features that are not yet considered in the model.

The candidate should outline in the proposal the features that are planned to be added, and a code mockup (or a complete class diagram) for said features.

* ''Required Experience:'' Fundamentals of IPv6 addressing, C++ programming.
* ''Bonus Experience:'' Familiarity with 6LoWPAN and 6LoWPAN-ND
* ''Interests:'' IPv6 and IoT networks
* ''Difficulty:'' Easy.
* ''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]
** https://gitlab.com/jieqiboh5836/ns-3-dev/-/tree/6LoWPAN-ND-P1
** https://gitlab.com/jieqiboh5836/ns-3-dev/-/tree/6LoWPAN-ND-P2

===OLLA Link Adaptation for 5G-LENA===

Mentors: [mailto:bbojovic@cttc.es Biljana Bojovic], [mailto:tomh@tomh.org Tom Henderson], [mailto:gcarvalho@cttc.es Gabriel Ferreira], [mailto:slagen@cttc.es Sandra Lagen]

This project would focus on improving the realism of the CTTC 5G-LENA by implementing Outer Loop Link Adaptation (OLLA) in the scheduling/link adaptation workflow. In the current baseline, MCS selection is driven by CQI (or SINR-to-CQI mapping) without an outer-loop correction. OLLA is commonly used to track a target BLER by updating an SINR (or CQI) offset based on HARQ ACK/NACK feedback, leading to more stable and realistic link adaptation behavior under varying channel conditions. This project should include this adaptation for the DL and for the UL, integrated in a scheduler-agnostic way so multiple NR schedulers can reuse it with minimal duplication.

In addition, the project would include a performance evaluation:

*comparing the new OLLA-enabled behavior against the current baseline and across multiple representative existing NR schedulers.
*the evaluation should consider throughput, latency, and achieved BLER, including how closely the achieved BLER tracks the configured target.
*the evaluation of the responsiveness to channel condition changes (convergence speed, stability/oscillation behavior).
*the sensitivity to the CQI update frequency and to user data rate / traffic load (how ACK/NACK rate affects convergence).

Additional topics/work items that could be considered if feasible:

*More advanced OLLA algorithms.
*Calibration guidance and/or comparison against published OLLA configurations (when reference data is available).
*Extensions beyond MCS selection (e.g., rank adaptation). This should be relatively easy in the uplink, but for the downlink some advanced mechanism could be investigated and potentially, AI-based approach could be considered.

For starters, we would suggest adding the CTTC 5G-LENA (nr module) to ns-3 (as a module in the contrib/ directory), building and running the NR examples, and becoming familiar with the current scheduler, HARQ feedback flow, CQI/MCS selection, and TBS computation. 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.

*Required Experience: C++ programming, understanding of 5G NR MAC concepts (scheduling, CQI/MCS, HARQ), wireless networking fundamentals
*Interests: 5G NR simulations, scheduling, link adaptation, performance evaluation
*Difficulty: Medium
*Project size: 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.

=== Enabling 5G NR examples visualization ===

Mentors: [mailto:aashtari@cttc.es Amir Ashtari Gargari], [mailto:gcarvalho@cttc.es Gabriel Ferreira], [mailto:bbojovic@cttc.es Biljana Bojovic] and [mailto:kkoutlia@cttc.es Katerina Koutlia]

The main idea of this project is to allow easier visualization of 5G NR examples by integrating the NR module with some ns-3 visualization tools like NetAnim, or by implementing a kind of web-based visualization, e.g., through Jupyter notebook. The new feature should allow the visualization of already existing traces, visualization of topology, or even some new relevant simulation aspects could be considered. The idea is that users better understand how the metrics collection works, and how changing parameters can affect simulation results. In this project, we are open to other ideas on how to implement visualizations. An example scenario is to have e.g. the handover scenario and then be able to see while the UEs are moving and performing handover how their performance metrics vary.

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.
* Recommended reading: Please read this thread in the ns-3 developers list: [https://groups.google.com/g/ns-developers/c/xGCOIAuTYs8/m/yhzpGJkYAwAJ?utm_medium=email&utm_source=footer UI "Designer" for NS3 Based Visual Scripting].

=== AODVv2 Protocol enhancements ===

Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], [TBD].

ns-3 contains models for proactive (DSDV and OLSR) and reactive (AODV and DSR) ad hoc routing protocols. AODVv2 is currently an IETF draft, and its implementation in ns-3 is ongoing. This project aims at enhancing the AODVv2 model for ns-3.

In particular the project should address the following points:
# Alignment with the latest drafts,
# Model finalization and testing (in particular for the IPv6 part),
# AODVv2 examples and documentation,
# "External" network routing support.

Collaboration with the draft authors is also highly suggested.

* ''Required Experience:'' Fundamentals of IPv6 addressing, C++ programming.
* ''Bonus Experience:'' Familiarity with AODV implementations in ns-3 and AODVv2
* ''Interests:'' Ad hoc routing
* ''Difficulty:'' Medium.
* ''Recommended reading:''
** [https://www.nsnam.org/docs/models/html/ipv6.html IPv6 model in ns-3]
** [https://www.nsnam.org/docs/models/html/aodv.html AODV model in ns-3]
** [https://gitlab.com/tod97/ns-3-dev/-/tree/aodvv2-icns3-25 AODVv2 model presented at ICNS3-2025]
** [https://datatracker.ietf.org/doc/draft-perkins-manet-aodvv2/05/ Ad Hoc On-demand Distance Vector Version 2 (AODVv2) Routing]

Possible tasks to fulfill the patch requirement:
* [https://gitlab.com/nsnam/ns-3-dev/-/issues/368 Issue #368] - aodv: aodv parameters can be set to "impossible" values

== Large projects (350 hours) ==

=== Mesh Link Establishment (MLE) protocol ===

Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], [mailto:alramonet@is.tokushima-u.ac.jp Alberto Gallegos Ramonet].

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:''
** [https://datatracker.ietf.org/doc/html/draft-ietf-6lo-mesh-link-establishment MLE draft]
** [https://openthread.io/guides/thread-primer/network-discovery Thread primer]
** [https://www.threadgroup.org/ThreadSpec Thread specifications]

Possible tasks to fulfill the patch requirement:
* TBD, contact the mentors if interested.

===Energy Consumption Modeling and Power-Aware Extensions for 5G-LENA===

Mentors: [mailto:kkoutlia@cttc.es Katerina Koutlia], [mailto:bbojovic@cttc.es Biljana Bojovic], [mailto:mmiozzo@cttc.es Marco Miozzo] and [mailto:aashtari@cttc.es Amir Ashtari Gargari]

This project would add energy consumption modeling to the CTTC 5G-LENA (NR module). While 5G-LENA provides a detailed and validated simulation of the 5G NR protocol stack behavior, it currently lacks energy models for UEs and/or gNBs, limiting research on energy efficiency, green networking, 6G sustainability, and potentially AI-driven power-aware control.
The project would first evaluate reuse of the ns-3 Energy Framework (e.g., EnergySource, DeviceEnergyModel) by defining a clean interface between 5G-LENA and the energy module. If existing models are insufficient, the project would design and implement a 5G-specific device energy model (e.g., NrDeviceEnergyModel) and connect it to relevant 5G-LENA state/procedure events.
For starters, we would suggest adding the CTTC 5G-LENA (nr module) to ns-3 (as a module in the contrib/ directory), building and running the NR examples, and studying the Energy Framework integration patterns. Documentation is available here: https://5g-lena.cttc.es/. Tutorial video: https://acmse.net/2021/tutorials-offered/#tut-work03.

Scope (expected deliverables):
*Energy consumption accounting for UEs and/or gNBs
*Per-state (and if feasible per-procedure) modeling, e.g.
**gNB: idle/active/sleep, TX/RX, processing; dependence on bandwidth/PRBs, TX power, MIMO layers/streams/RF chains, load
**UE: TX/RX, measurements, CSI-RS/SRS activity, beamforming-related processing, handover
*Tracing, example(s), and documentation

Optional (time permitting): a simple energy-aware scheduling extension to explore QoS trade-offs (e.g., energy-per-bit or energy-aware MIMO under GBR)

*Required Experience: C++ programming, wireless networking fundamentals (energy/state-machine modeling is a plus)
*Interests: 5G NR simulations, energy efficiency, green networking, 6G sustainability
*Difficulty: Medium
*Project size: 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 integration with ns-3-ai ===

Mentors: [mailto:kkoutlia@cttc.es Katerina Koutlia], [mailto:gcarvalho@cttc.es Gabriel Ferreira], [mailto:aashtari@cttc.es Amir Ashtari Gargari] and [mailto:bbojovic@cttc.es Biljana Bojovic]

The objective of this project is to integrate the ns-3 5G NR module with [https://apps.nsnam.org/app/ns3-ai/ ns-3-ai]. In GSoC 2024 we had a project in which 5G NR was integrated with [https://www.nsnam.org/wiki/GSOC2024RLUsability5G ns-3 gym]. While ns-3 gym is a popular ns-3 module for AI, it is limited to the application of reinforcement learning techniques in networking research. On the other hand, ns-3-ai module provides a more general solution that enables the data interaction between ns-3 and other Python-based AI frameworks, like [https://www.tensorflow.org/api_docs/cc Tensorflow C++ APIs] and [https://pytorch.org/cppdocs/ PyTorch C++ APIs], which opens the door to use different machine learning-based techniques in 5G NR models. The correct functioning of the integration should be tested, and documented, and a fully working example using ns-3-ai should be provided. The contributor can propose a use-case scenario for matching learning. One option is to use it for MAC scheduling, but it could be used for other 5G related research problems, and the contributor is encouraged to propose the use case of his/her interest.

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.
* 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.

=== Linux-like CAKE queue discipline for ns-3 ===

Mentors: [mailto:tahiliani.nitk@gmail.com Mohit P. Tahiliani]

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.

* ''Required Experience:'' Familiarity with queue disciplines, TCP and C++ programming.
* ''Bonus Experience:'' Familiarity with CAKE framework in Linux 4.19
* ''Interests:'' Active Queue Management, Packet scheduling and TCP.
* ''Difficulty:'' Medium to Hard
* ''Recommended reading:''
** [https://arxiv.org/pdf/1804.07617.pdf Piece of CAKE: A Comprehensive Queue Management Solution for Home Gateways]
** [https://lwn.net/Articles/758353/ Let them run CAKE]
** [https://www.nsnam.org/docs/models/html/queue-discs.html Queue disciplines in ns-3]

=== Switched Ethernet ===

Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], TBD.

The current ns-3 models for wired connections are fine for simple networks, but the lack of a switched Ethernet model is a limitation in some cases.

The goal of the idea is to create, test, and document a Switched Ethernet model, able to simulate (at least) 1, 10, and 40 GbE links and model for a switch.

The model of the NetDevice and Channel shall take into account the link delays and errors, similarly to what is done by the point-to-point model. Futhermore, it should be able to set the link speed and if it is full-duplex or half-duplex. Additional support for flow control is a bonus, but not strictly required. Link speed auto-negotiation is not considered to be interesting.

The model for the switch should be modular (i.e., allowing the development of different switch types), and include auto-learning of I/O ports based on the MAC address, i.e., have a MAC/port table, and a basic store-and-forward operation. Features like advanced I/O buffer handling and ARP/NDP spoofing detection are not a priority and shall be left for future implementations.

The model should consider the future implementaion of algorithms like VLANs (IEEE 802.1Q, 802.1ad), and the Spanning Tree Protocol (IEEE 802.1D, 802.1w, and 802.1s). Their implementaion is not required, but the model design should allow their development.

* ''Required Experience:'' Fundamentals of Ethernet sitched networking, C++ programming.
* ''Interests:'' Ethernet networks and switched data networks.
* ''Difficulty:'' Medium.
* ''Recommended reading:''
** [https://codereview.appspot.com/5615049/ Basic implementation (very old)]
** [https://gitlab.com/nsnam/ns-3-dev/-/merge_requests/431 Full-duplex CSMA, somehow related]
** [https://tcipg.org/sites/default/files/papers/2010_Jin_Nicol_Caesar.pdf Paper on gigabit Ethernet switch models for simulation]

Possible tasks to fulfill the patch requirement:
* TBD, contact the mentors if interested.

GSOC2026Projects

2026-03-12T11:54:10Z

Biljana: /* Enabling 5G NR examples visualization */

{{TOC}}

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

* [https://developers.google.com/open-source/gsoc/faq GSoC Frequently Asked Questions]
* [[GSOC2026ContributorGuide | ns-3's 2026 GSoC Contributor guide]]
* [https://developers.google.com/open-source/gsoc/resources/guide GSoC contributor/student guide (not ns-3 specific)]
* [[GSOC2025ApplicationTemplate | 2026 GSoC Contributor application template]]
* [[GSOCMentorGuide | ns-3's GSoC Mentor guide]]
* [https://archive.flossmanuals.net/gsocmentoring/index.html GSoC Mentor guide (not ns-3 specific)]
* [[GSOCSelectionProcess | GSoC Contributor Selection Process]]
* ''Get in contact with the ns-3 team'': [https://groups.google.com/g/ns-developers 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-25. 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 [mailto:tpecorella@mac.com Tommaso Pecorella] and [mailto:tahiliani.nitk@gmail.com Mohit P. Tahiliani]; contact them with any questions. They also hang out on [https://ns-3.zulipchat.com 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 [https://developers.google.com/open-source/gsoc/resources/guide GSoC contributor guide].
* Read [[GSOC2026ContributorGuide |ns-3's 2026 GSoC contributor guide]]
* 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.
* Once it is posted, look through the [[GSOC2024ApplicationTemplate |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 2026, 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 2026. 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 suggests 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>
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.
</blockquote>

=== Patch requirement guidelines ===

In past years, we have asked applicants to submit a patch related to an open issue or a suggested coding exercise. We are undecided at this time whether we will ask for this in 2026; check back later.

=== 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 ===

* [[#Flent Application API in ns-3]] (small size project, 90h)
* [[#Ping and TraverouteV4 enhancements]] (small size project, 90h)
* [[#Internet routing refactory]] (small size project, 90h)
* [[#AODVv2 Protocol enhancements]] (medium size project, 175h)
* [[#Linux-like CAKE queue discipline for ns-3]] (large size project, 350h)
* [[#Switched Ethernet]] (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)

=== 5G NR models enhancements ===

The general idea is to improve the usability of the 5G NR module by adding new examples that help users start building scenario scripts. Also, an interesting improvement could be integration with other modules, like those for AI or visualizations. Here are some project ideas. Depending on the contributor's interest and skills we can adjust these projects' definitions.

* [[#OLLA Link Adaptation and Spec-Compliant TBS Calculation for 5G-LENA]](medium size project, 175h)
* [[#Enabling 5G NR examples visualization]] (medium size project, 175h)
* [[#Energy Consumption Modeling and Power-Aware Extensions for 5G-LENA]](medium size project, 250h)
* [[#5G NR module integration with ns-3-ai]] (large size project, 250h)

== Small sized projects (90 hours) ==

=== Flent Application API in ns-3 ===

Mentors: [mailto:tahiliani.nitk@gmail.com Mohit P. Tahiliani]

Flexible Network Tester (Flent) is a network benchmarking tool. It is written in Python and wraps well-known network benchmarking tools (such as netperf and iperf) into aggregate, repeatable tests, such as a number of tests for Bufferbloat. A basic structure for Flent Application API in ns-3 has been developed. It is a wrapper around existing ns-3 applications. This project has four main goals: (1) update this implementation to match the current ns-3-dev, (2) integrate a JSON library properly (for Flent-style result handling) (3) validate correctness of Flent results produced by ns-3, and (4) Add more Flent-style test examples useful for ns-3 users. The goal of this project is to merge the Flent Application API into ns-3 mainline, not the app store.

* ''Required Experience:'' Familiarity with Flent and C++ programming.
* ''Bonus Experience:'' Familiarity with applications supported in ns-3.
* ''Interests:'' Bufferbloat, TCP, AQM algorithms and ECN.
* ''Difficulty:'' Medium.
* ''Recommended Reading:''
** Flexible Network Tester [[https://flent.org/flent-the-flexible-network-tester.pdf Paper]] [[https://flent.org/ Tool]]
** [https://www.nsnam.org/doxygen/d9/dc9/group__applications.html#details Existing Applications in ns-3]
** [https://gitlab.com/tomhenderson/ns-3-dev/-/commits/flent?ref_type=heads Prior work on Flent application API in ns-3]

=== Internet routing refactory ===

Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], [TBD].

Traditionally IP routing tables are organized in tuples {Dst, DstMask, GatewayAddr}, e.g., {10.42.66.0, 255.255.255.0, 169.254.10.1}, plus other flags and data, like the interface to be used.
In ns-3 this is accomplished by storing three separate objects, two Ipv[4,6]Address, and one Ipv[4Mask,6Prefix].

While this is quite simple to implement, this has some notable drawbacks, e.g., the Dst address must be a network address (Dst & ~DstMask == 0), it is not efficient (the mask or prefix could be represented by a simple integer), and more.
In order to improve code readability and consistency between IPv4 and IPv6, !2645 introduces two new classes: Ipv[4,6]NetworkAddress.

The goal is to refactor the existing routing classes, along with Ipv[4,6]RotingTable classes, so that they use the new classes.
The candidate should provide a clear and convincing plan to pursue the above mentioned goal, all while keeping backward compatibility. The APIs of the existing classes must be kept as they are (at most the can be deprecated), and new APIs should be introduced only where strictly necessary.
Another very important requirement will be to break down the work in multiple sub-tasks, so that the merge process can be gradual.

It is not required that the candidate will update the code for all the routing schemes, but the choice of which routing algorithms will be considered during the project must be clear and motivated.

* ''Required Experience:'' Fundamentals of IPv6 addressing and routing, C++ programming.
* ''Interests:'' IPv4 and IPv6 routing
* ''Difficulty:'' Easy.
* ''Recommended reading:''
** [https://gitlab.com/nsnam/ns-3-dev/-/issues/1239 Issue #1239]
** [https://gitlab.com/nsnam/ns-3-dev/-/merge_requests/2645 Merge Request !2645]

Possible tasks to fulfill the patch requirement:
* Use !2645 to modify all or in part the `Rip` protocol.

=== Ping and TraverouteV4 enhancements ===

Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], [TBD].

The Ping and TraverouteV4 ns-3 application have some small limitations.

In particular 2 of them are annoying.
1. Neither Ping nor TracerouteV4 reacts to ICMP errors or informative messages.
2. As the name implies, TracerouteV4 is IPv4-only and can't be used on IPv6.

The goal is to remove the above mentioned limitations, all or in part. A proposal should clearly outline the plan and improvements to the existing code (e.g., the list of the ICMP messages that will be considered), and a clear breakdown of the work. For the TracerouteV4 refactoring to use IPv6 as well, the proposal must consider the Ping implementation as a guideline.

* ''Required Experience:'' Fundamentals of IPv4, IPv6, ICMP, and ICMPv6. C++ programming.
* ''Interests:'' IPv4 and IPv6.
* ''Difficulty:'' Easy.
* ''Recommended reading:''
** [https://gitlab.com/nsnam/ns-3-dev/-/issues/825 Issue #825]

Possible tasks to fulfill the patch requirement:
* MR to have Ping react to one ICMP message.

== Medium sized projects (175 hours) ==

=== 6LoWPAN mesh-under routing enhancements ===

Mentors: [mailto:tommaso.pecorella@unifi.it 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.
Better approaches are possible, e.g., by leveraging some concepts from RFC 7731, by using SNR as a guidance, or by measuring the local network activity.

The candidate should outline the proposed approach, what parts of code are going to be affected, and how they can be enhanced.

* ''Required Experience:'' Fundamentals of IPv6 addressing, C++ programming.
* ''Bonus Experience:'' Familiarity with mesh routing and 6LoWPAN ns-3
* ''Interests:'' IPv6 mesh routing
* ''Difficulty:'' Easy.
* ''Recommended reading:''
** [https://www.nsnam.org/docs/models/html/sixlowpan.html#mesh-under-routing Mesh-under in ns-3 6LoWPAN]
** [https://datatracker.ietf.org/doc/html/rfc7731 RFC 7731]
** [https://meshtastic.org/docs/overview/mesh-algo/ Meshtastic controlled flooding]
** [https://ieeexplore.ieee.org/document/91339 Routing by controlled flooding in communication networks] (if the document can not be accessed, PM the mentors)

Possible tasks to fulfill the patch requirement:
* The current code is hardwired, i.e., the mesh-under routing scheme is embedded into the SixLowPanNetDevice. Propose a patch to decouple it, using a SixLowPanMeshUnderRouting class to determine the "next hop". The behavior of the actual protocol should be unchanged.

=== 6LoWPAN neighbor discovery protocol ===

Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], [mailto:adnan.rashid@poliba.it Adnan Rashid].

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 help merging the code (if it's not already merged) and add some features that are not yet considered in the model.

The candidate should outline in the proposal the features that are planned to be added, and a code mockup (or a complete class diagram) for said features.

* ''Required Experience:'' Fundamentals of IPv6 addressing, C++ programming.
* ''Bonus Experience:'' Familiarity with 6LoWPAN and 6LoWPAN-ND
* ''Interests:'' IPv6 and IoT networks
* ''Difficulty:'' Easy.
* ''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]
** https://gitlab.com/jieqiboh5836/ns-3-dev/-/tree/6LoWPAN-ND-P1
** https://gitlab.com/jieqiboh5836/ns-3-dev/-/tree/6LoWPAN-ND-P2

===OLLA Link Adaptation for 5G-LENA===

Mentors: [mailto:bbojovic@cttc.es Biljana Bojovic], [mailto:tomh@tomh.org Tom Henderson], [mailto:gcarvalho@cttc.es Gabriel Ferreira], [mailto:slagen@cttc.es Sandra Lagen]

This project would focus on improving the realism of the CTTC 5G-LENA by implementing Outer Loop Link Adaptation (OLLA) in the scheduling/link adaptation workflow. In the current baseline, MCS selection is driven by CQI (or SINR-to-CQI mapping) without an outer-loop correction. OLLA is commonly used to track a target BLER by updating an SINR (or CQI) offset based on HARQ ACK/NACK feedback, leading to more stable and realistic link adaptation behavior under varying channel conditions. This project should include this adaptation for the DL and for the UL, integrated in a scheduler-agnostic way so multiple NR schedulers can reuse it with minimal duplication.

In addition, the project would include a performance evaluation:

*comparing the new OLLA-enabled behavior against the current baseline and across multiple representative existing NR schedulers.
*the evaluation should consider throughput, latency, and achieved BLER, including how closely the achieved BLER tracks the configured target.
*the evaluation of the responsiveness to channel condition changes (convergence speed, stability/oscillation behavior).
*the sensitivity to the CQI update frequency and to user data rate / traffic load (how ACK/NACK rate affects convergence).

Additional topics/work items that could be considered if feasible:

*More advanced OLLA algorithms.
*Calibration guidance and/or comparison against published OLLA configurations (when reference data is available).
*Extensions beyond MCS selection (e.g., rank adaptation). This should be relatively easy in the uplink, but for the downlink some advanced mechanism could be investigated and potentially, AI-based approach could be considered.

For starters, we would suggest adding the CTTC 5G-LENA (nr module) to ns-3 (as a module in the contrib/ directory), building and running the NR examples, and becoming familiar with the current scheduler, HARQ feedback flow, CQI/MCS selection, and TBS computation. 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.

*Required Experience: C++ programming, understanding of 5G NR MAC concepts (scheduling, CQI/MCS, HARQ), wireless networking fundamentals
*Interests: 5G NR simulations, scheduling, link adaptation, performance evaluation
*Difficulty: Medium
*Project size: 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.

=== Enabling 5G NR examples visualization ===

Mentors: [mailto:aashtari@cttc.es Amir Ashtari Gargari], [mailto:gcarvalho@cttc.es Gabriel Ferreira], [mailto:bbojovic@cttc.es Biljana Bojovic] and [mailto:kkoutlia@cttc.es Katerina Koutlia]

The main idea of this project is to allow easier visualization of 5G NR examples by integrating the NR module with some ns-3 visualization tools like NetAnim, or by implementing a kind of web-based visualization, e.g., through Jupyter notebook. The new feature should allow the visualization of already existing traces, visualization of topology, or even some new relevant simulation aspects could be considered. The idea is that users better understand how the metrics collection works, and how changing parameters can affect simulation results. In this project, we are open to other ideas on how to implement visualizations. An example scenario is to have e.g. the handover scenario and then be able to see while the UEs are moving and performing handover how their performance metrics vary.

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.
* Recommended reading: Please read this thread in the ns-3 developers list: https://groups.google.com/g/ns-developers/c/xGCOIAuTYs8/m/yhzpGJkYAwAJ?utm_medium=email&utm_source=footer.

=== AODVv2 Protocol enhancements ===

Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], [TBD].

ns-3 contains models for proactive (DSDV and OLSR) and reactive (AODV and DSR) ad hoc routing protocols. AODVv2 is currently an IETF draft, and its implementation in ns-3 is ongoing. This project aims at enhancing the AODVv2 model for ns-3.

In particular the project should address the following points:
# Alignment with the latest drafts,
# Model finalization and testing (in particular for the IPv6 part),
# AODVv2 examples and documentation,
# "External" network routing support.

Collaboration with the draft authors is also highly suggested.

* ''Required Experience:'' Fundamentals of IPv6 addressing, C++ programming.
* ''Bonus Experience:'' Familiarity with AODV implementations in ns-3 and AODVv2
* ''Interests:'' Ad hoc routing
* ''Difficulty:'' Medium.
* ''Recommended reading:''
** [https://www.nsnam.org/docs/models/html/ipv6.html IPv6 model in ns-3]
** [https://www.nsnam.org/docs/models/html/aodv.html AODV model in ns-3]
** [https://gitlab.com/tod97/ns-3-dev/-/tree/aodvv2-icns3-25 AODVv2 model presented at ICNS3-2025]
** [https://datatracker.ietf.org/doc/draft-perkins-manet-aodvv2/05/ Ad Hoc On-demand Distance Vector Version 2 (AODVv2) Routing]

Possible tasks to fulfill the patch requirement:
* [https://gitlab.com/nsnam/ns-3-dev/-/issues/368 Issue #368] - aodv: aodv parameters can be set to "impossible" values

== Large projects (350 hours) ==

=== Mesh Link Establishment (MLE) protocol ===

Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], [mailto:alramonet@is.tokushima-u.ac.jp Alberto Gallegos Ramonet].

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:''
** [https://datatracker.ietf.org/doc/html/draft-ietf-6lo-mesh-link-establishment MLE draft]
** [https://openthread.io/guides/thread-primer/network-discovery Thread primer]
** [https://www.threadgroup.org/ThreadSpec Thread specifications]

Possible tasks to fulfill the patch requirement:
* TBD, contact the mentors if interested.

===Energy Consumption Modeling and Power-Aware Extensions for 5G-LENA===

Mentors: [mailto:kkoutlia@cttc.es Katerina Koutlia], [mailto:bbojovic@cttc.es Biljana Bojovic], [mailto:mmiozzo@cttc.es Marco Miozzo] and [mailto:aashtari@cttc.es Amir Ashtari Gargari]

This project would add energy consumption modeling to the CTTC 5G-LENA (NR module). While 5G-LENA provides a detailed and validated simulation of the 5G NR protocol stack behavior, it currently lacks energy models for UEs and/or gNBs, limiting research on energy efficiency, green networking, 6G sustainability, and potentially AI-driven power-aware control.
The project would first evaluate reuse of the ns-3 Energy Framework (e.g., EnergySource, DeviceEnergyModel) by defining a clean interface between 5G-LENA and the energy module. If existing models are insufficient, the project would design and implement a 5G-specific device energy model (e.g., NrDeviceEnergyModel) and connect it to relevant 5G-LENA state/procedure events.
For starters, we would suggest adding the CTTC 5G-LENA (nr module) to ns-3 (as a module in the contrib/ directory), building and running the NR examples, and studying the Energy Framework integration patterns. Documentation is available here: https://5g-lena.cttc.es/. Tutorial video: https://acmse.net/2021/tutorials-offered/#tut-work03.

Scope (expected deliverables):
*Energy consumption accounting for UEs and/or gNBs
*Per-state (and if feasible per-procedure) modeling, e.g.
**gNB: idle/active/sleep, TX/RX, processing; dependence on bandwidth/PRBs, TX power, MIMO layers/streams/RF chains, load
**UE: TX/RX, measurements, CSI-RS/SRS activity, beamforming-related processing, handover
*Tracing, example(s), and documentation

Optional (time permitting): a simple energy-aware scheduling extension to explore QoS trade-offs (e.g., energy-per-bit or energy-aware MIMO under GBR)

*Required Experience: C++ programming, wireless networking fundamentals (energy/state-machine modeling is a plus)
*Interests: 5G NR simulations, energy efficiency, green networking, 6G sustainability
*Difficulty: Medium
*Project size: 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 integration with ns-3-ai ===

Mentors: [mailto:kkoutlia@cttc.es Katerina Koutlia], [mailto:gcarvalho@cttc.es Gabriel Ferreira], [mailto:aashtari@cttc.es Amir Ashtari Gargari] and [mailto:bbojovic@cttc.es Biljana Bojovic]

The objective of this project is to integrate the ns-3 5G NR module with [https://apps.nsnam.org/app/ns3-ai/ ns-3-ai]. In GSoC 2024 we had a project in which 5G NR was integrated with [https://www.nsnam.org/wiki/GSOC2024RLUsability5G ns-3 gym]. While ns-3 gym is a popular ns-3 module for AI, it is limited to the application of reinforcement learning techniques in networking research. On the other hand, ns-3-ai module provides a more general solution that enables the data interaction between ns-3 and other Python-based AI frameworks, like [https://www.tensorflow.org/api_docs/cc Tensorflow C++ APIs] and [https://pytorch.org/cppdocs/ PyTorch C++ APIs], which opens the door to use different machine learning-based techniques in 5G NR models. The correct functioning of the integration should be tested, and documented, and a fully working example using ns-3-ai should be provided. The contributor can propose a use-case scenario for matching learning. One option is to use it for MAC scheduling, but it could be used for other 5G related research problems, and the contributor is encouraged to propose the use case of his/her interest.

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.
* 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.

=== Linux-like CAKE queue discipline for ns-3 ===

Mentors: [mailto:tahiliani.nitk@gmail.com Mohit P. Tahiliani]

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.

* ''Required Experience:'' Familiarity with queue disciplines, TCP and C++ programming.
* ''Bonus Experience:'' Familiarity with CAKE framework in Linux 4.19
* ''Interests:'' Active Queue Management, Packet scheduling and TCP.
* ''Difficulty:'' Medium to Hard
* ''Recommended reading:''
** [https://arxiv.org/pdf/1804.07617.pdf Piece of CAKE: A Comprehensive Queue Management Solution for Home Gateways]
** [https://lwn.net/Articles/758353/ Let them run CAKE]
** [https://www.nsnam.org/docs/models/html/queue-discs.html Queue disciplines in ns-3]

=== Switched Ethernet ===

Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], TBD.

The current ns-3 models for wired connections are fine for simple networks, but the lack of a switched Ethernet model is a limitation in some cases.

The goal of the idea is to create, test, and document a Switched Ethernet model, able to simulate (at least) 1, 10, and 40 GbE links and model for a switch.

The model of the NetDevice and Channel shall take into account the link delays and errors, similarly to what is done by the point-to-point model. Futhermore, it should be able to set the link speed and if it is full-duplex or half-duplex. Additional support for flow control is a bonus, but not strictly required. Link speed auto-negotiation is not considered to be interesting.

The model for the switch should be modular (i.e., allowing the development of different switch types), and include auto-learning of I/O ports based on the MAC address, i.e., have a MAC/port table, and a basic store-and-forward operation. Features like advanced I/O buffer handling and ARP/NDP spoofing detection are not a priority and shall be left for future implementations.

The model should consider the future implementaion of algorithms like VLANs (IEEE 802.1Q, 802.1ad), and the Spanning Tree Protocol (IEEE 802.1D, 802.1w, and 802.1s). Their implementaion is not required, but the model design should allow their development.

* ''Required Experience:'' Fundamentals of Ethernet sitched networking, C++ programming.
* ''Interests:'' Ethernet networks and switched data networks.
* ''Difficulty:'' Medium.
* ''Recommended reading:''
** [https://codereview.appspot.com/5615049/ Basic implementation (very old)]
** [https://gitlab.com/nsnam/ns-3-dev/-/merge_requests/431 Full-duplex CSMA, somehow related]
** [https://tcipg.org/sites/default/files/papers/2010_Jin_Nicol_Caesar.pdf Paper on gigabit Ethernet switch models for simulation]

Possible tasks to fulfill the patch requirement:
* TBD, contact the mentors if interested.

GSOC2026Projects

2026-03-12T11:52:28Z

Biljana: /* Enabling 5G NR examples visualization */

{{TOC}}

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

* [https://developers.google.com/open-source/gsoc/faq GSoC Frequently Asked Questions]
* [[GSOC2026ContributorGuide | ns-3's 2026 GSoC Contributor guide]]
* [https://developers.google.com/open-source/gsoc/resources/guide GSoC contributor/student guide (not ns-3 specific)]
* [[GSOC2025ApplicationTemplate | 2026 GSoC Contributor application template]]
* [[GSOCMentorGuide | ns-3's GSoC Mentor guide]]
* [https://archive.flossmanuals.net/gsocmentoring/index.html GSoC Mentor guide (not ns-3 specific)]
* [[GSOCSelectionProcess | GSoC Contributor Selection Process]]
* ''Get in contact with the ns-3 team'': [https://groups.google.com/g/ns-developers 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-25. 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 [mailto:tpecorella@mac.com Tommaso Pecorella] and [mailto:tahiliani.nitk@gmail.com Mohit P. Tahiliani]; contact them with any questions. They also hang out on [https://ns-3.zulipchat.com 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 [https://developers.google.com/open-source/gsoc/resources/guide GSoC contributor guide].
* Read [[GSOC2026ContributorGuide |ns-3's 2026 GSoC contributor guide]]
* 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.
* Once it is posted, look through the [[GSOC2024ApplicationTemplate |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 2026, 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 2026. 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 suggests 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>
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.
</blockquote>

=== Patch requirement guidelines ===

In past years, we have asked applicants to submit a patch related to an open issue or a suggested coding exercise. We are undecided at this time whether we will ask for this in 2026; check back later.

=== 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 ===

* [[#Flent Application API in ns-3]] (small size project, 90h)
* [[#Ping and TraverouteV4 enhancements]] (small size project, 90h)
* [[#Internet routing refactory]] (small size project, 90h)
* [[#AODVv2 Protocol enhancements]] (medium size project, 175h)
* [[#Linux-like CAKE queue discipline for ns-3]] (large size project, 350h)
* [[#Switched Ethernet]] (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)

=== 5G NR models enhancements ===

The general idea is to improve the usability of the 5G NR module by adding new examples that help users start building scenario scripts. Also, an interesting improvement could be integration with other modules, like those for AI or visualizations. Here are some project ideas. Depending on the contributor's interest and skills we can adjust these projects' definitions.

* [[#OLLA Link Adaptation and Spec-Compliant TBS Calculation for 5G-LENA]](medium size project, 175h)
* [[#Enabling 5G NR examples visualization]] (medium size project, 175h)
* [[#Energy Consumption Modeling and Power-Aware Extensions for 5G-LENA]](medium size project, 250h)
* [[#5G NR module integration with ns-3-ai]] (large size project, 250h)

== Small sized projects (90 hours) ==

=== Flent Application API in ns-3 ===

Mentors: [mailto:tahiliani.nitk@gmail.com Mohit P. Tahiliani]

Flexible Network Tester (Flent) is a network benchmarking tool. It is written in Python and wraps well-known network benchmarking tools (such as netperf and iperf) into aggregate, repeatable tests, such as a number of tests for Bufferbloat. A basic structure for Flent Application API in ns-3 has been developed. It is a wrapper around existing ns-3 applications. This project has four main goals: (1) update this implementation to match the current ns-3-dev, (2) integrate a JSON library properly (for Flent-style result handling) (3) validate correctness of Flent results produced by ns-3, and (4) Add more Flent-style test examples useful for ns-3 users. The goal of this project is to merge the Flent Application API into ns-3 mainline, not the app store.

* ''Required Experience:'' Familiarity with Flent and C++ programming.
* ''Bonus Experience:'' Familiarity with applications supported in ns-3.
* ''Interests:'' Bufferbloat, TCP, AQM algorithms and ECN.
* ''Difficulty:'' Medium.
* ''Recommended Reading:''
** Flexible Network Tester [[https://flent.org/flent-the-flexible-network-tester.pdf Paper]] [[https://flent.org/ Tool]]
** [https://www.nsnam.org/doxygen/d9/dc9/group__applications.html#details Existing Applications in ns-3]
** [https://gitlab.com/tomhenderson/ns-3-dev/-/commits/flent?ref_type=heads Prior work on Flent application API in ns-3]

=== Internet routing refactory ===

Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], [TBD].

Traditionally IP routing tables are organized in tuples {Dst, DstMask, GatewayAddr}, e.g., {10.42.66.0, 255.255.255.0, 169.254.10.1}, plus other flags and data, like the interface to be used.
In ns-3 this is accomplished by storing three separate objects, two Ipv[4,6]Address, and one Ipv[4Mask,6Prefix].

While this is quite simple to implement, this has some notable drawbacks, e.g., the Dst address must be a network address (Dst & ~DstMask == 0), it is not efficient (the mask or prefix could be represented by a simple integer), and more.
In order to improve code readability and consistency between IPv4 and IPv6, !2645 introduces two new classes: Ipv[4,6]NetworkAddress.

The goal is to refactor the existing routing classes, along with Ipv[4,6]RotingTable classes, so that they use the new classes.
The candidate should provide a clear and convincing plan to pursue the above mentioned goal, all while keeping backward compatibility. The APIs of the existing classes must be kept as they are (at most the can be deprecated), and new APIs should be introduced only where strictly necessary.
Another very important requirement will be to break down the work in multiple sub-tasks, so that the merge process can be gradual.

It is not required that the candidate will update the code for all the routing schemes, but the choice of which routing algorithms will be considered during the project must be clear and motivated.

* ''Required Experience:'' Fundamentals of IPv6 addressing and routing, C++ programming.
* ''Interests:'' IPv4 and IPv6 routing
* ''Difficulty:'' Easy.
* ''Recommended reading:''
** [https://gitlab.com/nsnam/ns-3-dev/-/issues/1239 Issue #1239]
** [https://gitlab.com/nsnam/ns-3-dev/-/merge_requests/2645 Merge Request !2645]

Possible tasks to fulfill the patch requirement:
* Use !2645 to modify all or in part the `Rip` protocol.

=== Ping and TraverouteV4 enhancements ===

Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], [TBD].

The Ping and TraverouteV4 ns-3 application have some small limitations.

In particular 2 of them are annoying.
1. Neither Ping nor TracerouteV4 reacts to ICMP errors or informative messages.
2. As the name implies, TracerouteV4 is IPv4-only and can't be used on IPv6.

The goal is to remove the above mentioned limitations, all or in part. A proposal should clearly outline the plan and improvements to the existing code (e.g., the list of the ICMP messages that will be considered), and a clear breakdown of the work. For the TracerouteV4 refactoring to use IPv6 as well, the proposal must consider the Ping implementation as a guideline.

* ''Required Experience:'' Fundamentals of IPv4, IPv6, ICMP, and ICMPv6. C++ programming.
* ''Interests:'' IPv4 and IPv6.
* ''Difficulty:'' Easy.
* ''Recommended reading:''
** [https://gitlab.com/nsnam/ns-3-dev/-/issues/825 Issue #825]

Possible tasks to fulfill the patch requirement:
* MR to have Ping react to one ICMP message.

== Medium sized projects (175 hours) ==

=== 6LoWPAN mesh-under routing enhancements ===

Mentors: [mailto:tommaso.pecorella@unifi.it 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.
Better approaches are possible, e.g., by leveraging some concepts from RFC 7731, by using SNR as a guidance, or by measuring the local network activity.

The candidate should outline the proposed approach, what parts of code are going to be affected, and how they can be enhanced.

* ''Required Experience:'' Fundamentals of IPv6 addressing, C++ programming.
* ''Bonus Experience:'' Familiarity with mesh routing and 6LoWPAN ns-3
* ''Interests:'' IPv6 mesh routing
* ''Difficulty:'' Easy.
* ''Recommended reading:''
** [https://www.nsnam.org/docs/models/html/sixlowpan.html#mesh-under-routing Mesh-under in ns-3 6LoWPAN]
** [https://datatracker.ietf.org/doc/html/rfc7731 RFC 7731]
** [https://meshtastic.org/docs/overview/mesh-algo/ Meshtastic controlled flooding]
** [https://ieeexplore.ieee.org/document/91339 Routing by controlled flooding in communication networks] (if the document can not be accessed, PM the mentors)

Possible tasks to fulfill the patch requirement:
* The current code is hardwired, i.e., the mesh-under routing scheme is embedded into the SixLowPanNetDevice. Propose a patch to decouple it, using a SixLowPanMeshUnderRouting class to determine the "next hop". The behavior of the actual protocol should be unchanged.

=== 6LoWPAN neighbor discovery protocol ===

Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], [mailto:adnan.rashid@poliba.it Adnan Rashid].

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 help merging the code (if it's not already merged) and add some features that are not yet considered in the model.

The candidate should outline in the proposal the features that are planned to be added, and a code mockup (or a complete class diagram) for said features.

* ''Required Experience:'' Fundamentals of IPv6 addressing, C++ programming.
* ''Bonus Experience:'' Familiarity with 6LoWPAN and 6LoWPAN-ND
* ''Interests:'' IPv6 and IoT networks
* ''Difficulty:'' Easy.
* ''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]
** https://gitlab.com/jieqiboh5836/ns-3-dev/-/tree/6LoWPAN-ND-P1
** https://gitlab.com/jieqiboh5836/ns-3-dev/-/tree/6LoWPAN-ND-P2

===OLLA Link Adaptation for 5G-LENA===

Mentors: [mailto:bbojovic@cttc.es Biljana Bojovic], [mailto:tomh@tomh.org Tom Henderson], [mailto:gcarvalho@cttc.es Gabriel Ferreira], [mailto:slagen@cttc.es Sandra Lagen]

This project would focus on improving the realism of the CTTC 5G-LENA by implementing Outer Loop Link Adaptation (OLLA) in the scheduling/link adaptation workflow. In the current baseline, MCS selection is driven by CQI (or SINR-to-CQI mapping) without an outer-loop correction. OLLA is commonly used to track a target BLER by updating an SINR (or CQI) offset based on HARQ ACK/NACK feedback, leading to more stable and realistic link adaptation behavior under varying channel conditions. This project should include this adaptation for the DL and for the UL, integrated in a scheduler-agnostic way so multiple NR schedulers can reuse it with minimal duplication.

In addition, the project would include a performance evaluation:

*comparing the new OLLA-enabled behavior against the current baseline and across multiple representative existing NR schedulers.
*the evaluation should consider throughput, latency, and achieved BLER, including how closely the achieved BLER tracks the configured target.
*the evaluation of the responsiveness to channel condition changes (convergence speed, stability/oscillation behavior).
*the sensitivity to the CQI update frequency and to user data rate / traffic load (how ACK/NACK rate affects convergence).

Additional topics/work items that could be considered if feasible:

*More advanced OLLA algorithms.
*Calibration guidance and/or comparison against published OLLA configurations (when reference data is available).
*Extensions beyond MCS selection (e.g., rank adaptation). This should be relatively easy in the uplink, but for the downlink some advanced mechanism could be investigated and potentially, AI-based approach could be considered.

For starters, we would suggest adding the CTTC 5G-LENA (nr module) to ns-3 (as a module in the contrib/ directory), building and running the NR examples, and becoming familiar with the current scheduler, HARQ feedback flow, CQI/MCS selection, and TBS computation. 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.

*Required Experience: C++ programming, understanding of 5G NR MAC concepts (scheduling, CQI/MCS, HARQ), wireless networking fundamentals
*Interests: 5G NR simulations, scheduling, link adaptation, performance evaluation
*Difficulty: Medium
*Project size: 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.

=== Enabling 5G NR examples visualization ===

Mentors: [mailto:aashtari@cttc.es Amir Ashtari Gargari], [mailto:gcarvalho@cttc.es Gabriel Ferreira], [mailto:bbojovic@cttc.es Biljana Bojovic] and [mailto:kkoutlia@cttc.es Katerina Koutlia]

The main idea of this project is to allow easier visualization of 5G NR examples by integrating the NR module with some ns-3 visualization tools like NetAnim, or by implementing a kind of web-based visualization, e.g., through Jupyter notebook. The new feature should allow the visualization of already existing traces, visualization of topology, or even some new relevant simulation aspects could be considered. The idea is that users better understand how the metrics collection works, and how changing parameters can affect simulation results. In this project, we are open to other ideas on how to implement visualizations. An example scenario is to have e.g. the handover scenario and then be able to see while the UEs are moving and performing handover how their performance metrics vary.

Also, please read this recent thread in the ns-3 developers list: https://groups.google.com/g/ns-developers/c/xGCOIAuTYs8/m/yhzpGJkYAwAJ?utm_medium=email&utm_source=footer.

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.

=== AODVv2 Protocol enhancements ===

Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], [TBD].

ns-3 contains models for proactive (DSDV and OLSR) and reactive (AODV and DSR) ad hoc routing protocols. AODVv2 is currently an IETF draft, and its implementation in ns-3 is ongoing. This project aims at enhancing the AODVv2 model for ns-3.

In particular the project should address the following points:
# Alignment with the latest drafts,
# Model finalization and testing (in particular for the IPv6 part),
# AODVv2 examples and documentation,
# "External" network routing support.

Collaboration with the draft authors is also highly suggested.

* ''Required Experience:'' Fundamentals of IPv6 addressing, C++ programming.
* ''Bonus Experience:'' Familiarity with AODV implementations in ns-3 and AODVv2
* ''Interests:'' Ad hoc routing
* ''Difficulty:'' Medium.
* ''Recommended reading:''
** [https://www.nsnam.org/docs/models/html/ipv6.html IPv6 model in ns-3]
** [https://www.nsnam.org/docs/models/html/aodv.html AODV model in ns-3]
** [https://gitlab.com/tod97/ns-3-dev/-/tree/aodvv2-icns3-25 AODVv2 model presented at ICNS3-2025]
** [https://datatracker.ietf.org/doc/draft-perkins-manet-aodvv2/05/ Ad Hoc On-demand Distance Vector Version 2 (AODVv2) Routing]

Possible tasks to fulfill the patch requirement:
* [https://gitlab.com/nsnam/ns-3-dev/-/issues/368 Issue #368] - aodv: aodv parameters can be set to "impossible" values

== Large projects (350 hours) ==

=== Mesh Link Establishment (MLE) protocol ===

Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], [mailto:alramonet@is.tokushima-u.ac.jp Alberto Gallegos Ramonet].

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:''
** [https://datatracker.ietf.org/doc/html/draft-ietf-6lo-mesh-link-establishment MLE draft]
** [https://openthread.io/guides/thread-primer/network-discovery Thread primer]
** [https://www.threadgroup.org/ThreadSpec Thread specifications]

Possible tasks to fulfill the patch requirement:
* TBD, contact the mentors if interested.

===Energy Consumption Modeling and Power-Aware Extensions for 5G-LENA===

Mentors: [mailto:kkoutlia@cttc.es Katerina Koutlia], [mailto:bbojovic@cttc.es Biljana Bojovic], [mailto:mmiozzo@cttc.es Marco Miozzo] and [mailto:aashtari@cttc.es Amir Ashtari Gargari]

This project would add energy consumption modeling to the CTTC 5G-LENA (NR module). While 5G-LENA provides a detailed and validated simulation of the 5G NR protocol stack behavior, it currently lacks energy models for UEs and/or gNBs, limiting research on energy efficiency, green networking, 6G sustainability, and potentially AI-driven power-aware control.
The project would first evaluate reuse of the ns-3 Energy Framework (e.g., EnergySource, DeviceEnergyModel) by defining a clean interface between 5G-LENA and the energy module. If existing models are insufficient, the project would design and implement a 5G-specific device energy model (e.g., NrDeviceEnergyModel) and connect it to relevant 5G-LENA state/procedure events.
For starters, we would suggest adding the CTTC 5G-LENA (nr module) to ns-3 (as a module in the contrib/ directory), building and running the NR examples, and studying the Energy Framework integration patterns. Documentation is available here: https://5g-lena.cttc.es/. Tutorial video: https://acmse.net/2021/tutorials-offered/#tut-work03.

Scope (expected deliverables):
*Energy consumption accounting for UEs and/or gNBs
*Per-state (and if feasible per-procedure) modeling, e.g.
**gNB: idle/active/sleep, TX/RX, processing; dependence on bandwidth/PRBs, TX power, MIMO layers/streams/RF chains, load
**UE: TX/RX, measurements, CSI-RS/SRS activity, beamforming-related processing, handover
*Tracing, example(s), and documentation

Optional (time permitting): a simple energy-aware scheduling extension to explore QoS trade-offs (e.g., energy-per-bit or energy-aware MIMO under GBR)

*Required Experience: C++ programming, wireless networking fundamentals (energy/state-machine modeling is a plus)
*Interests: 5G NR simulations, energy efficiency, green networking, 6G sustainability
*Difficulty: Medium
*Project size: 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 integration with ns-3-ai ===

Mentors: [mailto:kkoutlia@cttc.es Katerina Koutlia], [mailto:gcarvalho@cttc.es Gabriel Ferreira], [mailto:aashtari@cttc.es Amir Ashtari Gargari] and [mailto:bbojovic@cttc.es Biljana Bojovic]

The objective of this project is to integrate the ns-3 5G NR module with [https://apps.nsnam.org/app/ns3-ai/ ns-3-ai]. In GSoC 2024 we had a project in which 5G NR was integrated with [https://www.nsnam.org/wiki/GSOC2024RLUsability5G ns-3 gym]. While ns-3 gym is a popular ns-3 module for AI, it is limited to the application of reinforcement learning techniques in networking research. On the other hand, ns-3-ai module provides a more general solution that enables the data interaction between ns-3 and other Python-based AI frameworks, like [https://www.tensorflow.org/api_docs/cc Tensorflow C++ APIs] and [https://pytorch.org/cppdocs/ PyTorch C++ APIs], which opens the door to use different machine learning-based techniques in 5G NR models. The correct functioning of the integration should be tested, and documented, and a fully working example using ns-3-ai should be provided. The contributor can propose a use-case scenario for matching learning. One option is to use it for MAC scheduling, but it could be used for other 5G related research problems, and the contributor is encouraged to propose the use case of his/her interest.

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.
* 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.

=== Linux-like CAKE queue discipline for ns-3 ===

Mentors: [mailto:tahiliani.nitk@gmail.com Mohit P. Tahiliani]

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.

* ''Required Experience:'' Familiarity with queue disciplines, TCP and C++ programming.
* ''Bonus Experience:'' Familiarity with CAKE framework in Linux 4.19
* ''Interests:'' Active Queue Management, Packet scheduling and TCP.
* ''Difficulty:'' Medium to Hard
* ''Recommended reading:''
** [https://arxiv.org/pdf/1804.07617.pdf Piece of CAKE: A Comprehensive Queue Management Solution for Home Gateways]
** [https://lwn.net/Articles/758353/ Let them run CAKE]
** [https://www.nsnam.org/docs/models/html/queue-discs.html Queue disciplines in ns-3]

=== Switched Ethernet ===

Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], TBD.

The current ns-3 models for wired connections are fine for simple networks, but the lack of a switched Ethernet model is a limitation in some cases.

The goal of the idea is to create, test, and document a Switched Ethernet model, able to simulate (at least) 1, 10, and 40 GbE links and model for a switch.

The model of the NetDevice and Channel shall take into account the link delays and errors, similarly to what is done by the point-to-point model. Futhermore, it should be able to set the link speed and if it is full-duplex or half-duplex. Additional support for flow control is a bonus, but not strictly required. Link speed auto-negotiation is not considered to be interesting.

The model for the switch should be modular (i.e., allowing the development of different switch types), and include auto-learning of I/O ports based on the MAC address, i.e., have a MAC/port table, and a basic store-and-forward operation. Features like advanced I/O buffer handling and ARP/NDP spoofing detection are not a priority and shall be left for future implementations.

The model should consider the future implementaion of algorithms like VLANs (IEEE 802.1Q, 802.1ad), and the Spanning Tree Protocol (IEEE 802.1D, 802.1w, and 802.1s). Their implementaion is not required, but the model design should allow their development.

* ''Required Experience:'' Fundamentals of Ethernet sitched networking, C++ programming.
* ''Interests:'' Ethernet networks and switched data networks.
* ''Difficulty:'' Medium.
* ''Recommended reading:''
** [https://codereview.appspot.com/5615049/ Basic implementation (very old)]
** [https://gitlab.com/nsnam/ns-3-dev/-/merge_requests/431 Full-duplex CSMA, somehow related]
** [https://tcipg.org/sites/default/files/papers/2010_Jin_Nicol_Caesar.pdf Paper on gigabit Ethernet switch models for simulation]

Possible tasks to fulfill the patch requirement:
* TBD, contact the mentors if interested.

GSOC2026Projects

2026-03-05T11:54:20Z

Biljana: /* OLLA Link Adaptation for 5G-LENA */

{{TOC}}

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

* [https://developers.google.com/open-source/gsoc/faq GSoC Frequently Asked Questions]
* [[GSOC2026ContributorGuide | ns-3's 2026 GSoC Contributor guide]]
* [https://developers.google.com/open-source/gsoc/resources/guide GSoC contributor/student guide (not ns-3 specific)]
* [[GSOC2025ApplicationTemplate | 2026 GSoC Contributor application template]]
* [[GSOCMentorGuide | ns-3's GSoC Mentor guide]]
* [https://archive.flossmanuals.net/gsocmentoring/index.html GSoC Mentor guide (not ns-3 specific)]
* [[GSOCSelectionProcess | GSoC Contributor Selection Process]]
* ''Get in contact with the ns-3 team'': [https://groups.google.com/g/ns-developers 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-25. 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 [mailto:tpecorella@mac.com Tommaso Pecorella] and [mailto:tahiliani.nitk@gmail.com Mohit P. Tahiliani]; contact them with any questions. They also hang out on [https://ns-3.zulipchat.com 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 [https://developers.google.com/open-source/gsoc/resources/guide GSoC contributor guide].
* Read [[GSOC2026ContributorGuide |ns-3's 2026 GSoC contributor guide]]
* 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.
* Once it is posted, look through the [[GSOC2024ApplicationTemplate |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 2026, 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 2026. 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 suggests 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>
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.
</blockquote>

=== Patch requirement guidelines ===

In past years, we have asked applicants to submit a patch related to an open issue or a suggested coding exercise. We are undecided at this time whether we will ask for this in 2026; check back later.

=== 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 ===

* [[#Flent Application API in ns-3]] (small size project, 90h)
* [[#Ping and TraverouteV4 enhancements]] (small size project, 90h)
* [[#Internet routing refactory]] (small size project, 90h)
* [[#AODVv2 Protocol enhancements]] (medium size project, 175h)
* [[#Linux-like CAKE queue discipline for ns-3]] (large size project, 350h)
* [[#Switched Ethernet]] (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)

=== 5G NR models enhancements ===

The general idea is to improve the usability of the 5G NR module by adding new examples that help users start building scenario scripts. Also, an interesting improvement could be integration with other modules, like those for AI or visualizations. Here are some project ideas. Depending on the contributor's interest and skills we can adjust these projects' definitions.

* [[#OLLA Link Adaptation and Spec-Compliant TBS Calculation for 5G-LENA]](medium size project, 175h)
* [[#Enabling 5G NR examples visualization]] (medium size project, 175h)
* [[#Energy Consumption Modeling and Power-Aware Extensions for 5G-LENA]](medium size project, 250h)
* [[#5G NR module integration with ns-3-ai]] (large size project, 250h)

== Small sized projects (90 hours) ==

=== Flent Application API in ns-3 ===

Mentors: [mailto:tahiliani.nitk@gmail.com Mohit P. Tahiliani]

Flexible Network Tester (Flent) is a network benchmarking tool. It is written in Python and wraps well-known network benchmarking tools (such as netperf and iperf) into aggregate, repeatable tests, such as a number of tests for Bufferbloat. A basic structure for Flent Application API in ns-3 has been developed. It is a wrapper around existing ns-3 applications. This project has four main goals: (1) update this implementation to match the current ns-3-dev, (2) integrate a JSON library properly (for Flent-style result handling) (3) validate correctness of Flent results produced by ns-3, and (4) Add more Flent-style test examples useful for ns-3 users. The goal of this project is to merge the Flent Application API into ns-3 mainline, not the app store.

* ''Required Experience:'' Familiarity with Flent and C++ programming.
* ''Bonus Experience:'' Familiarity with applications supported in ns-3.
* ''Interests:'' Bufferbloat, TCP, AQM algorithms and ECN.
* ''Difficulty:'' Medium.
* ''Recommended Reading:''
** Flexible Network Tester [[https://flent.org/flent-the-flexible-network-tester.pdf Paper]] [[https://flent.org/ Tool]]
** [https://www.nsnam.org/doxygen/d9/dc9/group__applications.html#details Existing Applications in ns-3]
** [https://gitlab.com/tomhenderson/ns-3-dev/-/commits/flent?ref_type=heads Prior work on Flent application API in ns-3]

=== Internet routing refactory ===

Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], [TBD].

Traditionally IP routing tables are organized in tuples {Dst, DstMask, GatewayAddr}, e.g., {10.42.66.0, 255.255.255.0, 169.254.10.1}, plus other flags and data, like the interface to be used.
In ns-3 this is accomplished by storing three separate objects, two Ipv[4,6]Address, and one Ipv[4Mask,6Prefix].

While this is quite simple to implement, this has some notable drawbacks, e.g., the Dst address must be a network address (Dst & ~DstMask == 0), it is not efficient (the mask or prefix could be represented by a simple integer), and more.
In order to improve code readability and consistency between IPv4 and IPv6, !2645 introduces two new classes: Ipv[4,6]NetworkAddress.

The goal is to refactor the existing routing classes, along with Ipv[4,6]RotingTable classes, so that they use the new classes.
The candidate should provide a clear and convincing plan to pursue the above mentioned goal, all while keeping backward compatibility. The APIs of the existing classes must be kept as they are (at most the can be deprecated), and new APIs should be introduced only where strictly necessary.
Another very important requirement will be to break down the work in multiple sub-tasks, so that the merge process can be gradual.

It is not required that the candidate will update the code for all the routing schemes, but the choice of which routing algorithms will be considered during the project must be clear and motivated.

* ''Required Experience:'' Fundamentals of IPv6 addressing and routing, C++ programming.
* ''Interests:'' IPv4 and IPv6 routing
* ''Difficulty:'' Easy.
* ''Recommended reading:''
** [https://gitlab.com/nsnam/ns-3-dev/-/issues/1239 Issue #1239]
** [https://gitlab.com/nsnam/ns-3-dev/-/merge_requests/2645 Merge Request !2645]

Possible tasks to fulfill the patch requirement:
* Use !2645 to modify all or in part the `Rip` protocol.

=== Ping and TraverouteV4 enhancements ===

Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], [TBD].

The Ping and TraverouteV4 ns-3 application have some small limitations.

In particular 2 of them are annoying.
1. Neither Ping nor TracerouteV4 reacts to ICMP errors or informative messages.
2. As the name implies, TracerouteV4 is IPv4-only and can't be used on IPv6.

The goal is to remove the above mentioned limitations, all or in part. A proposal should clearly outline the plan and improvements to the existing code (e.g., the list of the ICMP messages that will be considered), and a clear breakdown of the work. For the TracerouteV4 refactoring to use IPv6 as well, the proposal must consider the Ping implementation as a guideline.

* ''Required Experience:'' Fundamentals of IPv4, IPv6, ICMP, and ICMPv6. C++ programming.
* ''Interests:'' IPv4 and IPv6.
* ''Difficulty:'' Easy.
* ''Recommended reading:''
** [https://gitlab.com/nsnam/ns-3-dev/-/issues/825 Issue #825]

Possible tasks to fulfill the patch requirement:
* MR to have Ping react to one ICMP message.

== Medium sized projects (175 hours) ==

=== 6LoWPAN mesh-under routing enhancements ===

Mentors: [mailto:tommaso.pecorella@unifi.it 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.
Better approaches are possible, e.g., by leveraging some concepts from RFC 7731, by using SNR as a guidance, or by measuring the local network activity.

The candidate should outline the proposed approach, what parts of code are going to be affected, and how they can be enhanced.

* ''Required Experience:'' Fundamentals of IPv6 addressing, C++ programming.
* ''Bonus Experience:'' Familiarity with mesh routing and 6LoWPAN ns-3
* ''Interests:'' IPv6 mesh routing
* ''Difficulty:'' Easy.
* ''Recommended reading:''
** [https://www.nsnam.org/docs/models/html/sixlowpan.html#mesh-under-routing Mesh-under in ns-3 6LoWPAN]
** [https://datatracker.ietf.org/doc/html/rfc7731 RFC 7731]
** [https://meshtastic.org/docs/overview/mesh-algo/ Meshtastic controlled flooding]
** [https://ieeexplore.ieee.org/document/91339 Routing by controlled flooding in communication networks] (if the document can not be accessed, PM the mentors)

Possible tasks to fulfill the patch requirement:
* The current code is hardwired, i.e., the mesh-under routing scheme is embedded into the SixLowPanNetDevice. Propose a patch to decouple it, using a SixLowPanMeshUnderRouting class to determine the "next hop". The behavior of the actual protocol should be unchanged.

=== 6LoWPAN neighbor discovery protocol ===

Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], [mailto:adnan.rashid@poliba.it Adnan Rashid].

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 help merging the code (if it's not already merged) and add some features that are not yet considered in the model.

The candidate should outline in the proposal the features that are planned to be added, and a code mockup (or a complete class diagram) for said features.

* ''Required Experience:'' Fundamentals of IPv6 addressing, C++ programming.
* ''Bonus Experience:'' Familiarity with 6LoWPAN and 6LoWPAN-ND
* ''Interests:'' IPv6 and IoT networks
* ''Difficulty:'' Easy.
* ''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]
** https://gitlab.com/jieqiboh5836/ns-3-dev/-/tree/6LoWPAN-ND-P1
** https://gitlab.com/jieqiboh5836/ns-3-dev/-/tree/6LoWPAN-ND-P2

===OLLA Link Adaptation for 5G-LENA===

Mentors: [mailto:bbojovic@cttc.es Biljana Bojovic], [mailto:tomh@tomh.org Tom Henderson], [mailto:gcarvalho@cttc.es Gabriel Ferreira], [mailto:slagen@cttc.es Sandra Lagen]

This project would focus on improving the realism of the CTTC 5G-LENA by implementing Outer Loop Link Adaptation (OLLA) in the scheduling/link adaptation workflow. In the current baseline, MCS selection is driven by CQI (or SINR-to-CQI mapping) without an outer-loop correction. OLLA is commonly used to track a target BLER by updating an SINR (or CQI) offset based on HARQ ACK/NACK feedback, leading to more stable and realistic link adaptation behavior under varying channel conditions. This project should include this adaptation for the DL and for the UL, integrated in a scheduler-agnostic way so multiple NR schedulers can reuse it with minimal duplication.

In addition, the project would include a performance evaluation:

*comparing the new OLLA-enabled behavior against the current baseline and across multiple representative existing NR schedulers.
*the evaluation should consider throughput, latency, and achieved BLER, including how closely the achieved BLER tracks the configured target.
*the evaluation of the responsiveness to channel condition changes (convergence speed, stability/oscillation behavior).
*the sensitivity to the CQI update frequency and to user data rate / traffic load (how ACK/NACK rate affects convergence).

Additional topics/work items that could be considered if feasible:

*More advanced OLLA algorithms.
*Calibration guidance and/or comparison against published OLLA configurations (when reference data is available).
*Extensions beyond MCS selection (e.g., rank adaptation). This should be relatively easy in the uplink, but for the downlink some advanced mechanism could be investigated and potentially, AI-based approach could be considered.

For starters, we would suggest adding the CTTC 5G-LENA (nr module) to ns-3 (as a module in the contrib/ directory), building and running the NR examples, and becoming familiar with the current scheduler, HARQ feedback flow, CQI/MCS selection, and TBS computation. 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.

*Required Experience: C++ programming, understanding of 5G NR MAC concepts (scheduling, CQI/MCS, HARQ), wireless networking fundamentals
*Interests: 5G NR simulations, scheduling, link adaptation, performance evaluation
*Difficulty: Medium
*Project size: 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.

=== Enabling 5G NR examples visualization ===

Mentors: [mailto:aashtari@cttc.es Amir Ashtari Gargari], [mailto:gcarvalho@cttc.es Gabriel Ferreira], [mailto:bbojovic@cttc.es Biljana Bojovic] and [mailto:kkoutlia@cttc.es Katerina Koutlia]

The main idea of this project is to allow easier visualization of 5G NR examples by integrating the NR module with some ns-3 visualization tools like NetAnim, or by implementing a kind of web-based visualization, e.g., through Jupyter notebook. The new feature should allow the visualization of already existing traces, visualization of topology, or even some new relevant simulation aspects could be considered. The idea is that users better understand how the metrics collection works, and how changing parameters can affect simulation results. In this project, we are open to other ideas on how to implement visualizations.

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.

=== AODVv2 Protocol enhancements ===

Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], [TBD].

ns-3 contains models for proactive (DSDV and OLSR) and reactive (AODV and DSR) ad hoc routing protocols. AODVv2 is currently an IETF draft, and its implementation in ns-3 is ongoing. This project aims at enhancing the AODVv2 model for ns-3.

In particular the project should address the following points:
# Alignment with the latest drafts,
# Model finalization and testing (in particular for the IPv6 part),
# AODVv2 examples and documentation,
# "External" network routing support.

Collaboration with the draft authors is also highly suggested.

* ''Required Experience:'' Fundamentals of IPv6 addressing, C++ programming.
* ''Bonus Experience:'' Familiarity with AODV implementations in ns-3 and AODVv2
* ''Interests:'' Ad hoc routing
* ''Difficulty:'' Medium.
* ''Recommended reading:''
** [https://www.nsnam.org/docs/models/html/ipv6.html IPv6 model in ns-3]
** [https://www.nsnam.org/docs/models/html/aodv.html AODV model in ns-3]
** [https://gitlab.com/tod97/ns-3-dev/-/tree/aodvv2-icns3-25 AODVv2 model presented at ICNS3-2025]
** [https://datatracker.ietf.org/doc/draft-perkins-manet-aodvv2/05/ Ad Hoc On-demand Distance Vector Version 2 (AODVv2) Routing]

Possible tasks to fulfill the patch requirement:
* [https://gitlab.com/nsnam/ns-3-dev/-/issues/368 Issue #368] - aodv: aodv parameters can be set to "impossible" values

== Large projects (350 hours) ==

=== Mesh Link Establishment (MLE) protocol ===

Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], [mailto:alramonet@is.tokushima-u.ac.jp Alberto Gallegos Ramonet].

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:''
** [https://datatracker.ietf.org/doc/html/draft-ietf-6lo-mesh-link-establishment MLE draft]
** [https://openthread.io/guides/thread-primer/network-discovery Thread primer]
** [https://www.threadgroup.org/ThreadSpec Thread specifications]

Possible tasks to fulfill the patch requirement:
* TBD, contact the mentors if interested.

===Energy Consumption Modeling and Power-Aware Extensions for 5G-LENA===

Mentors: [mailto:kkoutlia@cttc.es Katerina Koutlia], [mailto:bbojovic@cttc.es Biljana Bojovic], [mailto:mmiozzo@cttc.es Marco Miozzo] and [mailto:aashtari@cttc.es Amir Ashtari Gargari]

This project would add energy consumption modeling to the CTTC 5G-LENA (NR module). While 5G-LENA provides a detailed and validated simulation of the 5G NR protocol stack behavior, it currently lacks energy models for UEs and/or gNBs, limiting research on energy efficiency, green networking, 6G sustainability, and potentially AI-driven power-aware control.
The project would first evaluate reuse of the ns-3 Energy Framework (e.g., EnergySource, DeviceEnergyModel) by defining a clean interface between 5G-LENA and the energy module. If existing models are insufficient, the project would design and implement a 5G-specific device energy model (e.g., NrDeviceEnergyModel) and connect it to relevant 5G-LENA state/procedure events.
For starters, we would suggest adding the CTTC 5G-LENA (nr module) to ns-3 (as a module in the contrib/ directory), building and running the NR examples, and studying the Energy Framework integration patterns. Documentation is available here: https://5g-lena.cttc.es/. Tutorial video: https://acmse.net/2021/tutorials-offered/#tut-work03.

Scope (expected deliverables):
*Energy consumption accounting for UEs and/or gNBs
*Per-state (and if feasible per-procedure) modeling, e.g.
**gNB: idle/active/sleep, TX/RX, processing; dependence on bandwidth/PRBs, TX power, MIMO layers/streams/RF chains, load
**UE: TX/RX, measurements, CSI-RS/SRS activity, beamforming-related processing, handover
*Tracing, example(s), and documentation

Optional (time permitting): a simple energy-aware scheduling extension to explore QoS trade-offs (e.g., energy-per-bit or energy-aware MIMO under GBR)

*Required Experience: C++ programming, wireless networking fundamentals (energy/state-machine modeling is a plus)
*Interests: 5G NR simulations, energy efficiency, green networking, 6G sustainability
*Difficulty: Medium
*Project size: 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 integration with ns-3-ai ===

Mentors: [mailto:kkoutlia@cttc.es Katerina Koutlia], [mailto:gcarvalho@cttc.es Gabriel Ferreira], [mailto:aashtari@cttc.es Amir Ashtari Gargari] and [mailto:bbojovic@cttc.es Biljana Bojovic]

The objective of this project is to integrate the ns-3 5G NR module with [https://apps.nsnam.org/app/ns3-ai/ ns-3-ai]. In GSoC 2024 we had a project in which 5G NR was integrated with [https://www.nsnam.org/wiki/GSOC2024RLUsability5G ns-3 gym]. While ns-3 gym is a popular ns-3 module for AI, it is limited to the application of reinforcement learning techniques in networking research. On the other hand, ns-3-ai module provides a more general solution that enables the data interaction between ns-3 and other Python-based AI frameworks, like [https://www.tensorflow.org/api_docs/cc Tensorflow C++ APIs] and [https://pytorch.org/cppdocs/ PyTorch C++ APIs], which opens the door to use different machine learning-based techniques in 5G NR models. The correct functioning of the integration should be tested, and documented, and a fully working example using ns-3-ai should be provided. The contributor can propose a use-case scenario for matching learning. One option is to use it for MAC scheduling, but it could be used for other 5G related research problems, and the contributor is encouraged to propose the use case of his/her interest.

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.
* 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.

=== Linux-like CAKE queue discipline for ns-3 ===

Mentors: [mailto:tahiliani.nitk@gmail.com Mohit P. Tahiliani]

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.

* ''Required Experience:'' Familiarity with queue disciplines, TCP and C++ programming.
* ''Bonus Experience:'' Familiarity with CAKE framework in Linux 4.19
* ''Interests:'' Active Queue Management, Packet scheduling and TCP.
* ''Difficulty:'' Medium to Hard
* ''Recommended reading:''
** [https://arxiv.org/pdf/1804.07617.pdf Piece of CAKE: A Comprehensive Queue Management Solution for Home Gateways]
** [https://lwn.net/Articles/758353/ Let them run CAKE]
** [https://www.nsnam.org/docs/models/html/queue-discs.html Queue disciplines in ns-3]

=== Switched Ethernet ===

Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], TBD.

The current ns-3 models for wired connections are fine for simple networks, but the lack of a switched Ethernet model is a limitation in some cases.

The goal of the idea is to create, test, and document a Switched Ethernet model, able to simulate (at least) 1, 10, and 40 GbE links and model for a switch.

The model of the NetDevice and Channel shall take into account the link delays and errors, similarly to what is done by the point-to-point model. Futhermore, it should be able to set the link speed and if it is full-duplex or half-duplex. Additional support for flow control is a bonus, but not strictly required. Link speed auto-negotiation is not considered to be interesting.

The model for the switch should be modular (i.e., allowing the development of different switch types), and include auto-learning of I/O ports based on the MAC address, i.e., have a MAC/port table, and a basic store-and-forward operation. Features like advanced I/O buffer handling and ARP/NDP spoofing detection are not a priority and shall be left for future implementations.

The model should consider the future implementaion of algorithms like VLANs (IEEE 802.1Q, 802.1ad), and the Spanning Tree Protocol (IEEE 802.1D, 802.1w, and 802.1s). Their implementaion is not required, but the model design should allow their development.

* ''Required Experience:'' Fundamentals of Ethernet sitched networking, C++ programming.
* ''Interests:'' Ethernet networks and switched data networks.
* ''Difficulty:'' Medium.
* ''Recommended reading:''
** [https://codereview.appspot.com/5615049/ Basic implementation (very old)]
** [https://gitlab.com/nsnam/ns-3-dev/-/merge_requests/431 Full-duplex CSMA, somehow related]
** [https://tcipg.org/sites/default/files/papers/2010_Jin_Nicol_Caesar.pdf Paper on gigabit Ethernet switch models for simulation]

Possible tasks to fulfill the patch requirement:
* TBD, contact the mentors if interested.

GSOC2026Projects

2026-03-05T11:53:15Z

Biljana: /* OLLA Link Adaptation for 5G-LENA */

{{TOC}}

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

* [https://developers.google.com/open-source/gsoc/faq GSoC Frequently Asked Questions]
* [[GSOC2026ContributorGuide | ns-3's 2026 GSoC Contributor guide]]
* [https://developers.google.com/open-source/gsoc/resources/guide GSoC contributor/student guide (not ns-3 specific)]
* [[GSOC2025ApplicationTemplate | 2026 GSoC Contributor application template]]
* [[GSOCMentorGuide | ns-3's GSoC Mentor guide]]
* [https://archive.flossmanuals.net/gsocmentoring/index.html GSoC Mentor guide (not ns-3 specific)]
* [[GSOCSelectionProcess | GSoC Contributor Selection Process]]
* ''Get in contact with the ns-3 team'': [https://groups.google.com/g/ns-developers 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-25. 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 [mailto:tpecorella@mac.com Tommaso Pecorella] and [mailto:tahiliani.nitk@gmail.com Mohit P. Tahiliani]; contact them with any questions. They also hang out on [https://ns-3.zulipchat.com 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 [https://developers.google.com/open-source/gsoc/resources/guide GSoC contributor guide].
* Read [[GSOC2026ContributorGuide |ns-3's 2026 GSoC contributor guide]]
* 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.
* Once it is posted, look through the [[GSOC2024ApplicationTemplate |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 2026, 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 2026. 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 suggests 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>
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.
</blockquote>

=== Patch requirement guidelines ===

In past years, we have asked applicants to submit a patch related to an open issue or a suggested coding exercise. We are undecided at this time whether we will ask for this in 2026; check back later.

=== 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 ===

* [[#Flent Application API in ns-3]] (small size project, 90h)
* [[#Ping and TraverouteV4 enhancements]] (small size project, 90h)
* [[#Internet routing refactory]] (small size project, 90h)
* [[#AODVv2 Protocol enhancements]] (medium size project, 175h)
* [[#Linux-like CAKE queue discipline for ns-3]] (large size project, 350h)
* [[#Switched Ethernet]] (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)

=== 5G NR models enhancements ===

The general idea is to improve the usability of the 5G NR module by adding new examples that help users start building scenario scripts. Also, an interesting improvement could be integration with other modules, like those for AI or visualizations. Here are some project ideas. Depending on the contributor's interest and skills we can adjust these projects' definitions.

* [[#OLLA Link Adaptation and Spec-Compliant TBS Calculation for 5G-LENA]](medium size project, 175h)
* [[#Enabling 5G NR examples visualization]] (medium size project, 175h)
* [[#Energy Consumption Modeling and Power-Aware Extensions for 5G-LENA]](medium size project, 250h)
* [[#5G NR module integration with ns-3-ai]] (large size project, 250h)

== Small sized projects (90 hours) ==

=== Flent Application API in ns-3 ===

Mentors: [mailto:tahiliani.nitk@gmail.com Mohit P. Tahiliani]

Flexible Network Tester (Flent) is a network benchmarking tool. It is written in Python and wraps well-known network benchmarking tools (such as netperf and iperf) into aggregate, repeatable tests, such as a number of tests for Bufferbloat. A basic structure for Flent Application API in ns-3 has been developed. It is a wrapper around existing ns-3 applications. This project has four main goals: (1) update this implementation to match the current ns-3-dev, (2) integrate a JSON library properly (for Flent-style result handling) (3) validate correctness of Flent results produced by ns-3, and (4) Add more Flent-style test examples useful for ns-3 users. The goal of this project is to merge the Flent Application API into ns-3 mainline, not the app store.

* ''Required Experience:'' Familiarity with Flent and C++ programming.
* ''Bonus Experience:'' Familiarity with applications supported in ns-3.
* ''Interests:'' Bufferbloat, TCP, AQM algorithms and ECN.
* ''Difficulty:'' Medium.
* ''Recommended Reading:''
** Flexible Network Tester [[https://flent.org/flent-the-flexible-network-tester.pdf Paper]] [[https://flent.org/ Tool]]
** [https://www.nsnam.org/doxygen/d9/dc9/group__applications.html#details Existing Applications in ns-3]
** [https://gitlab.com/tomhenderson/ns-3-dev/-/commits/flent?ref_type=heads Prior work on Flent application API in ns-3]

=== Internet routing refactory ===

Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], [TBD].

Traditionally IP routing tables are organized in tuples {Dst, DstMask, GatewayAddr}, e.g., {10.42.66.0, 255.255.255.0, 169.254.10.1}, plus other flags and data, like the interface to be used.
In ns-3 this is accomplished by storing three separate objects, two Ipv[4,6]Address, and one Ipv[4Mask,6Prefix].

While this is quite simple to implement, this has some notable drawbacks, e.g., the Dst address must be a network address (Dst & ~DstMask == 0), it is not efficient (the mask or prefix could be represented by a simple integer), and more.
In order to improve code readability and consistency between IPv4 and IPv6, !2645 introduces two new classes: Ipv[4,6]NetworkAddress.

The goal is to refactor the existing routing classes, along with Ipv[4,6]RotingTable classes, so that they use the new classes.
The candidate should provide a clear and convincing plan to pursue the above mentioned goal, all while keeping backward compatibility. The APIs of the existing classes must be kept as they are (at most the can be deprecated), and new APIs should be introduced only where strictly necessary.
Another very important requirement will be to break down the work in multiple sub-tasks, so that the merge process can be gradual.

It is not required that the candidate will update the code for all the routing schemes, but the choice of which routing algorithms will be considered during the project must be clear and motivated.

* ''Required Experience:'' Fundamentals of IPv6 addressing and routing, C++ programming.
* ''Interests:'' IPv4 and IPv6 routing
* ''Difficulty:'' Easy.
* ''Recommended reading:''
** [https://gitlab.com/nsnam/ns-3-dev/-/issues/1239 Issue #1239]
** [https://gitlab.com/nsnam/ns-3-dev/-/merge_requests/2645 Merge Request !2645]

Possible tasks to fulfill the patch requirement:
* Use !2645 to modify all or in part the `Rip` protocol.

=== Ping and TraverouteV4 enhancements ===

Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], [TBD].

The Ping and TraverouteV4 ns-3 application have some small limitations.

In particular 2 of them are annoying.
1. Neither Ping nor TracerouteV4 reacts to ICMP errors or informative messages.
2. As the name implies, TracerouteV4 is IPv4-only and can't be used on IPv6.

The goal is to remove the above mentioned limitations, all or in part. A proposal should clearly outline the plan and improvements to the existing code (e.g., the list of the ICMP messages that will be considered), and a clear breakdown of the work. For the TracerouteV4 refactoring to use IPv6 as well, the proposal must consider the Ping implementation as a guideline.

* ''Required Experience:'' Fundamentals of IPv4, IPv6, ICMP, and ICMPv6. C++ programming.
* ''Interests:'' IPv4 and IPv6.
* ''Difficulty:'' Easy.
* ''Recommended reading:''
** [https://gitlab.com/nsnam/ns-3-dev/-/issues/825 Issue #825]

Possible tasks to fulfill the patch requirement:
* MR to have Ping react to one ICMP message.

== Medium sized projects (175 hours) ==

=== 6LoWPAN mesh-under routing enhancements ===

Mentors: [mailto:tommaso.pecorella@unifi.it 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.
Better approaches are possible, e.g., by leveraging some concepts from RFC 7731, by using SNR as a guidance, or by measuring the local network activity.

The candidate should outline the proposed approach, what parts of code are going to be affected, and how they can be enhanced.

* ''Required Experience:'' Fundamentals of IPv6 addressing, C++ programming.
* ''Bonus Experience:'' Familiarity with mesh routing and 6LoWPAN ns-3
* ''Interests:'' IPv6 mesh routing
* ''Difficulty:'' Easy.
* ''Recommended reading:''
** [https://www.nsnam.org/docs/models/html/sixlowpan.html#mesh-under-routing Mesh-under in ns-3 6LoWPAN]
** [https://datatracker.ietf.org/doc/html/rfc7731 RFC 7731]
** [https://meshtastic.org/docs/overview/mesh-algo/ Meshtastic controlled flooding]
** [https://ieeexplore.ieee.org/document/91339 Routing by controlled flooding in communication networks] (if the document can not be accessed, PM the mentors)

Possible tasks to fulfill the patch requirement:
* The current code is hardwired, i.e., the mesh-under routing scheme is embedded into the SixLowPanNetDevice. Propose a patch to decouple it, using a SixLowPanMeshUnderRouting class to determine the "next hop". The behavior of the actual protocol should be unchanged.

=== 6LoWPAN neighbor discovery protocol ===

Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], [mailto:adnan.rashid@poliba.it Adnan Rashid].

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 help merging the code (if it's not already merged) and add some features that are not yet considered in the model.

The candidate should outline in the proposal the features that are planned to be added, and a code mockup (or a complete class diagram) for said features.

* ''Required Experience:'' Fundamentals of IPv6 addressing, C++ programming.
* ''Bonus Experience:'' Familiarity with 6LoWPAN and 6LoWPAN-ND
* ''Interests:'' IPv6 and IoT networks
* ''Difficulty:'' Easy.
* ''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]
** https://gitlab.com/jieqiboh5836/ns-3-dev/-/tree/6LoWPAN-ND-P1
** https://gitlab.com/jieqiboh5836/ns-3-dev/-/tree/6LoWPAN-ND-P2

===OLLA Link Adaptation for 5G-LENA===

Mentors: [mailto:bbojovic@cttc.es Biljana Bojovic], [mailto:tomh@tomh.org Tom Henderson], [mailto:gcarvalho@cttc.es Gabriel Ferreira], [mailto:slagen@cttc.es Sandra Lagen]

This project would focus on improving the realism of the CTTC 5G-LENA by implementing Outer Loop Link Adaptation (OLLA) in the scheduling/link adaptation workflow. In the current baseline, MCS selection is driven by CQI (or SINR-to-CQI mapping) without an outer-loop correction. OLLA is commonly used to track a target BLER by updating an SINR (or CQI) offset based on HARQ ACK/NACK feedback, leading to more stable and realistic link adaptation behavior under varying channel conditions. This project should include this adaptation for the DL and for the UL, integrated in a scheduler-agnostic way so multiple NR schedulers can reuse it with minimal duplication.

In addition, the project would include a performance evaluation:

*comparing the new OLLA-enabled behavior against the current baseline and across multiple representative existing NR schedulers.
*the evaluation should consider throughput, latency, and achieved BLER, including how closely the achieved BLER tracks the configured target.
*the evaluation of the responsiveness to channel condition changes (convergence speed, stability/oscillation behavior).
*the sensitivity to the CQI update frequency and to user data rate / traffic load (how ACK/NACK rate affects convergence).

Additional topics/work items that could be considered if feasible:

*More advanced OLLA algorithms.
*Calibration guidance and/or comparison against published OLLA configurations (when reference data is available).
*Extensions beyond MCS selection (e.g., rank adaptation). This should be relatively easy in the uplink, but for the downlink some advanced mechanism could be investigate and potentially, AI-based approach would be interesting to consider.

For starters, we would suggest adding the CTTC 5G-LENA (nr module) to ns-3 (as a module in the contrib/ directory), building and running the NR examples, and becoming familiar with the current scheduler, HARQ feedback flow, CQI/MCS selection, and TBS computation. 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.

*Required Experience: C++ programming, understanding of 5G NR MAC concepts (scheduling, CQI/MCS, HARQ), wireless networking fundamentals
*Interests: 5G NR simulations, scheduling, link adaptation, performance evaluation
*Difficulty: Medium
*Project size: 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.

=== Enabling 5G NR examples visualization ===

Mentors: [mailto:aashtari@cttc.es Amir Ashtari Gargari], [mailto:gcarvalho@cttc.es Gabriel Ferreira], [mailto:bbojovic@cttc.es Biljana Bojovic] and [mailto:kkoutlia@cttc.es Katerina Koutlia]

The main idea of this project is to allow easier visualization of 5G NR examples by integrating the NR module with some ns-3 visualization tools like NetAnim, or by implementing a kind of web-based visualization, e.g., through Jupyter notebook. The new feature should allow the visualization of already existing traces, visualization of topology, or even some new relevant simulation aspects could be considered. The idea is that users better understand how the metrics collection works, and how changing parameters can affect simulation results. In this project, we are open to other ideas on how to implement visualizations.

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.

=== AODVv2 Protocol enhancements ===

Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], [TBD].

ns-3 contains models for proactive (DSDV and OLSR) and reactive (AODV and DSR) ad hoc routing protocols. AODVv2 is currently an IETF draft, and its implementation in ns-3 is ongoing. This project aims at enhancing the AODVv2 model for ns-3.

In particular the project should address the following points:
# Alignment with the latest drafts,
# Model finalization and testing (in particular for the IPv6 part),
# AODVv2 examples and documentation,
# "External" network routing support.

Collaboration with the draft authors is also highly suggested.

* ''Required Experience:'' Fundamentals of IPv6 addressing, C++ programming.
* ''Bonus Experience:'' Familiarity with AODV implementations in ns-3 and AODVv2
* ''Interests:'' Ad hoc routing
* ''Difficulty:'' Medium.
* ''Recommended reading:''
** [https://www.nsnam.org/docs/models/html/ipv6.html IPv6 model in ns-3]
** [https://www.nsnam.org/docs/models/html/aodv.html AODV model in ns-3]
** [https://gitlab.com/tod97/ns-3-dev/-/tree/aodvv2-icns3-25 AODVv2 model presented at ICNS3-2025]
** [https://datatracker.ietf.org/doc/draft-perkins-manet-aodvv2/05/ Ad Hoc On-demand Distance Vector Version 2 (AODVv2) Routing]

Possible tasks to fulfill the patch requirement:
* [https://gitlab.com/nsnam/ns-3-dev/-/issues/368 Issue #368] - aodv: aodv parameters can be set to "impossible" values

== Large projects (350 hours) ==

=== Mesh Link Establishment (MLE) protocol ===

Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], [mailto:alramonet@is.tokushima-u.ac.jp Alberto Gallegos Ramonet].

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:''
** [https://datatracker.ietf.org/doc/html/draft-ietf-6lo-mesh-link-establishment MLE draft]
** [https://openthread.io/guides/thread-primer/network-discovery Thread primer]
** [https://www.threadgroup.org/ThreadSpec Thread specifications]

Possible tasks to fulfill the patch requirement:
* TBD, contact the mentors if interested.

===Energy Consumption Modeling and Power-Aware Extensions for 5G-LENA===

Mentors: [mailto:kkoutlia@cttc.es Katerina Koutlia], [mailto:bbojovic@cttc.es Biljana Bojovic], [mailto:mmiozzo@cttc.es Marco Miozzo] and [mailto:aashtari@cttc.es Amir Ashtari Gargari]

This project would add energy consumption modeling to the CTTC 5G-LENA (NR module). While 5G-LENA provides a detailed and validated simulation of the 5G NR protocol stack behavior, it currently lacks energy models for UEs and/or gNBs, limiting research on energy efficiency, green networking, 6G sustainability, and potentially AI-driven power-aware control.
The project would first evaluate reuse of the ns-3 Energy Framework (e.g., EnergySource, DeviceEnergyModel) by defining a clean interface between 5G-LENA and the energy module. If existing models are insufficient, the project would design and implement a 5G-specific device energy model (e.g., NrDeviceEnergyModel) and connect it to relevant 5G-LENA state/procedure events.
For starters, we would suggest adding the CTTC 5G-LENA (nr module) to ns-3 (as a module in the contrib/ directory), building and running the NR examples, and studying the Energy Framework integration patterns. Documentation is available here: https://5g-lena.cttc.es/. Tutorial video: https://acmse.net/2021/tutorials-offered/#tut-work03.

Scope (expected deliverables):
*Energy consumption accounting for UEs and/or gNBs
*Per-state (and if feasible per-procedure) modeling, e.g.
**gNB: idle/active/sleep, TX/RX, processing; dependence on bandwidth/PRBs, TX power, MIMO layers/streams/RF chains, load
**UE: TX/RX, measurements, CSI-RS/SRS activity, beamforming-related processing, handover
*Tracing, example(s), and documentation

Optional (time permitting): a simple energy-aware scheduling extension to explore QoS trade-offs (e.g., energy-per-bit or energy-aware MIMO under GBR)

*Required Experience: C++ programming, wireless networking fundamentals (energy/state-machine modeling is a plus)
*Interests: 5G NR simulations, energy efficiency, green networking, 6G sustainability
*Difficulty: Medium
*Project size: 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 integration with ns-3-ai ===

Mentors: [mailto:kkoutlia@cttc.es Katerina Koutlia], [mailto:gcarvalho@cttc.es Gabriel Ferreira], [mailto:aashtari@cttc.es Amir Ashtari Gargari] and [mailto:bbojovic@cttc.es Biljana Bojovic]

The objective of this project is to integrate the ns-3 5G NR module with [https://apps.nsnam.org/app/ns3-ai/ ns-3-ai]. In GSoC 2024 we had a project in which 5G NR was integrated with [https://www.nsnam.org/wiki/GSOC2024RLUsability5G ns-3 gym]. While ns-3 gym is a popular ns-3 module for AI, it is limited to the application of reinforcement learning techniques in networking research. On the other hand, ns-3-ai module provides a more general solution that enables the data interaction between ns-3 and other Python-based AI frameworks, like [https://www.tensorflow.org/api_docs/cc Tensorflow C++ APIs] and [https://pytorch.org/cppdocs/ PyTorch C++ APIs], which opens the door to use different machine learning-based techniques in 5G NR models. The correct functioning of the integration should be tested, and documented, and a fully working example using ns-3-ai should be provided. The contributor can propose a use-case scenario for matching learning. One option is to use it for MAC scheduling, but it could be used for other 5G related research problems, and the contributor is encouraged to propose the use case of his/her interest.

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.
* 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.

=== Linux-like CAKE queue discipline for ns-3 ===

Mentors: [mailto:tahiliani.nitk@gmail.com Mohit P. Tahiliani]

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.

* ''Required Experience:'' Familiarity with queue disciplines, TCP and C++ programming.
* ''Bonus Experience:'' Familiarity with CAKE framework in Linux 4.19
* ''Interests:'' Active Queue Management, Packet scheduling and TCP.
* ''Difficulty:'' Medium to Hard
* ''Recommended reading:''
** [https://arxiv.org/pdf/1804.07617.pdf Piece of CAKE: A Comprehensive Queue Management Solution for Home Gateways]
** [https://lwn.net/Articles/758353/ Let them run CAKE]
** [https://www.nsnam.org/docs/models/html/queue-discs.html Queue disciplines in ns-3]

=== Switched Ethernet ===

Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], TBD.

The current ns-3 models for wired connections are fine for simple networks, but the lack of a switched Ethernet model is a limitation in some cases.

The goal of the idea is to create, test, and document a Switched Ethernet model, able to simulate (at least) 1, 10, and 40 GbE links and model for a switch.

The model of the NetDevice and Channel shall take into account the link delays and errors, similarly to what is done by the point-to-point model. Futhermore, it should be able to set the link speed and if it is full-duplex or half-duplex. Additional support for flow control is a bonus, but not strictly required. Link speed auto-negotiation is not considered to be interesting.

The model for the switch should be modular (i.e., allowing the development of different switch types), and include auto-learning of I/O ports based on the MAC address, i.e., have a MAC/port table, and a basic store-and-forward operation. Features like advanced I/O buffer handling and ARP/NDP spoofing detection are not a priority and shall be left for future implementations.

The model should consider the future implementaion of algorithms like VLANs (IEEE 802.1Q, 802.1ad), and the Spanning Tree Protocol (IEEE 802.1D, 802.1w, and 802.1s). Their implementaion is not required, but the model design should allow their development.

* ''Required Experience:'' Fundamentals of Ethernet sitched networking, C++ programming.
* ''Interests:'' Ethernet networks and switched data networks.
* ''Difficulty:'' Medium.
* ''Recommended reading:''
** [https://codereview.appspot.com/5615049/ Basic implementation (very old)]
** [https://gitlab.com/nsnam/ns-3-dev/-/merge_requests/431 Full-duplex CSMA, somehow related]
** [https://tcipg.org/sites/default/files/papers/2010_Jin_Nicol_Caesar.pdf Paper on gigabit Ethernet switch models for simulation]

Possible tasks to fulfill the patch requirement:
* TBD, contact the mentors if interested.

GSOC2026Projects

2026-03-05T11:49:59Z

Biljana: /* OLLA Link Adaptation for 5G-LENA */

{{TOC}}

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

* [https://developers.google.com/open-source/gsoc/faq GSoC Frequently Asked Questions]
* [[GSOC2026ContributorGuide | ns-3's 2026 GSoC Contributor guide]]
* [https://developers.google.com/open-source/gsoc/resources/guide GSoC contributor/student guide (not ns-3 specific)]
* [[GSOC2025ApplicationTemplate | 2026 GSoC Contributor application template]]
* [[GSOCMentorGuide | ns-3's GSoC Mentor guide]]
* [https://archive.flossmanuals.net/gsocmentoring/index.html GSoC Mentor guide (not ns-3 specific)]
* [[GSOCSelectionProcess | GSoC Contributor Selection Process]]
* ''Get in contact with the ns-3 team'': [https://groups.google.com/g/ns-developers 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-25. 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 [mailto:tpecorella@mac.com Tommaso Pecorella] and [mailto:tahiliani.nitk@gmail.com Mohit P. Tahiliani]; contact them with any questions. They also hang out on [https://ns-3.zulipchat.com 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 [https://developers.google.com/open-source/gsoc/resources/guide GSoC contributor guide].
* Read [[GSOC2026ContributorGuide |ns-3's 2026 GSoC contributor guide]]
* 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.
* Once it is posted, look through the [[GSOC2024ApplicationTemplate |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 2026, 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 2026. 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 suggests 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>
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.
</blockquote>

=== Patch requirement guidelines ===

In past years, we have asked applicants to submit a patch related to an open issue or a suggested coding exercise. We are undecided at this time whether we will ask for this in 2026; check back later.

=== 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 ===

* [[#Flent Application API in ns-3]] (small size project, 90h)
* [[#Ping and TraverouteV4 enhancements]] (small size project, 90h)
* [[#Internet routing refactory]] (small size project, 90h)
* [[#AODVv2 Protocol enhancements]] (medium size project, 175h)
* [[#Linux-like CAKE queue discipline for ns-3]] (large size project, 350h)
* [[#Switched Ethernet]] (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)

=== 5G NR models enhancements ===

The general idea is to improve the usability of the 5G NR module by adding new examples that help users start building scenario scripts. Also, an interesting improvement could be integration with other modules, like those for AI or visualizations. Here are some project ideas. Depending on the contributor's interest and skills we can adjust these projects' definitions.

* [[#OLLA Link Adaptation and Spec-Compliant TBS Calculation for 5G-LENA]](medium size project, 175h)
* [[#Enabling 5G NR examples visualization]] (medium size project, 175h)
* [[#Energy Consumption Modeling and Power-Aware Extensions for 5G-LENA]](medium size project, 250h)
* [[#5G NR module integration with ns-3-ai]] (large size project, 250h)

== Small sized projects (90 hours) ==

=== Flent Application API in ns-3 ===

Mentors: [mailto:tahiliani.nitk@gmail.com Mohit P. Tahiliani]

Flexible Network Tester (Flent) is a network benchmarking tool. It is written in Python and wraps well-known network benchmarking tools (such as netperf and iperf) into aggregate, repeatable tests, such as a number of tests for Bufferbloat. A basic structure for Flent Application API in ns-3 has been developed. It is a wrapper around existing ns-3 applications. This project has four main goals: (1) update this implementation to match the current ns-3-dev, (2) integrate a JSON library properly (for Flent-style result handling) (3) validate correctness of Flent results produced by ns-3, and (4) Add more Flent-style test examples useful for ns-3 users. The goal of this project is to merge the Flent Application API into ns-3 mainline, not the app store.

* ''Required Experience:'' Familiarity with Flent and C++ programming.
* ''Bonus Experience:'' Familiarity with applications supported in ns-3.
* ''Interests:'' Bufferbloat, TCP, AQM algorithms and ECN.
* ''Difficulty:'' Medium.
* ''Recommended Reading:''
** Flexible Network Tester [[https://flent.org/flent-the-flexible-network-tester.pdf Paper]] [[https://flent.org/ Tool]]
** [https://www.nsnam.org/doxygen/d9/dc9/group__applications.html#details Existing Applications in ns-3]
** [https://gitlab.com/tomhenderson/ns-3-dev/-/commits/flent?ref_type=heads Prior work on Flent application API in ns-3]

=== Internet routing refactory ===

Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], [TBD].

Traditionally IP routing tables are organized in tuples {Dst, DstMask, GatewayAddr}, e.g., {10.42.66.0, 255.255.255.0, 169.254.10.1}, plus other flags and data, like the interface to be used.
In ns-3 this is accomplished by storing three separate objects, two Ipv[4,6]Address, and one Ipv[4Mask,6Prefix].

While this is quite simple to implement, this has some notable drawbacks, e.g., the Dst address must be a network address (Dst & ~DstMask == 0), it is not efficient (the mask or prefix could be represented by a simple integer), and more.
In order to improve code readability and consistency between IPv4 and IPv6, !2645 introduces two new classes: Ipv[4,6]NetworkAddress.

The goal is to refactor the existing routing classes, along with Ipv[4,6]RotingTable classes, so that they use the new classes.
The candidate should provide a clear and convincing plan to pursue the above mentioned goal, all while keeping backward compatibility. The APIs of the existing classes must be kept as they are (at most the can be deprecated), and new APIs should be introduced only where strictly necessary.
Another very important requirement will be to break down the work in multiple sub-tasks, so that the merge process can be gradual.

It is not required that the candidate will update the code for all the routing schemes, but the choice of which routing algorithms will be considered during the project must be clear and motivated.

* ''Required Experience:'' Fundamentals of IPv6 addressing and routing, C++ programming.
* ''Interests:'' IPv4 and IPv6 routing
* ''Difficulty:'' Easy.
* ''Recommended reading:''
** [https://gitlab.com/nsnam/ns-3-dev/-/issues/1239 Issue #1239]
** [https://gitlab.com/nsnam/ns-3-dev/-/merge_requests/2645 Merge Request !2645]

Possible tasks to fulfill the patch requirement:
* Use !2645 to modify all or in part the `Rip` protocol.

=== Ping and TraverouteV4 enhancements ===

Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], [TBD].

The Ping and TraverouteV4 ns-3 application have some small limitations.

In particular 2 of them are annoying.
1. Neither Ping nor TracerouteV4 reacts to ICMP errors or informative messages.
2. As the name implies, TracerouteV4 is IPv4-only and can't be used on IPv6.

The goal is to remove the above mentioned limitations, all or in part. A proposal should clearly outline the plan and improvements to the existing code (e.g., the list of the ICMP messages that will be considered), and a clear breakdown of the work. For the TracerouteV4 refactoring to use IPv6 as well, the proposal must consider the Ping implementation as a guideline.

* ''Required Experience:'' Fundamentals of IPv4, IPv6, ICMP, and ICMPv6. C++ programming.
* ''Interests:'' IPv4 and IPv6.
* ''Difficulty:'' Easy.
* ''Recommended reading:''
** [https://gitlab.com/nsnam/ns-3-dev/-/issues/825 Issue #825]

Possible tasks to fulfill the patch requirement:
* MR to have Ping react to one ICMP message.

== Medium sized projects (175 hours) ==

=== 6LoWPAN mesh-under routing enhancements ===

Mentors: [mailto:tommaso.pecorella@unifi.it 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.
Better approaches are possible, e.g., by leveraging some concepts from RFC 7731, by using SNR as a guidance, or by measuring the local network activity.

The candidate should outline the proposed approach, what parts of code are going to be affected, and how they can be enhanced.

* ''Required Experience:'' Fundamentals of IPv6 addressing, C++ programming.
* ''Bonus Experience:'' Familiarity with mesh routing and 6LoWPAN ns-3
* ''Interests:'' IPv6 mesh routing
* ''Difficulty:'' Easy.
* ''Recommended reading:''
** [https://www.nsnam.org/docs/models/html/sixlowpan.html#mesh-under-routing Mesh-under in ns-3 6LoWPAN]
** [https://datatracker.ietf.org/doc/html/rfc7731 RFC 7731]
** [https://meshtastic.org/docs/overview/mesh-algo/ Meshtastic controlled flooding]
** [https://ieeexplore.ieee.org/document/91339 Routing by controlled flooding in communication networks] (if the document can not be accessed, PM the mentors)

Possible tasks to fulfill the patch requirement:
* The current code is hardwired, i.e., the mesh-under routing scheme is embedded into the SixLowPanNetDevice. Propose a patch to decouple it, using a SixLowPanMeshUnderRouting class to determine the "next hop". The behavior of the actual protocol should be unchanged.

=== 6LoWPAN neighbor discovery protocol ===

Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], [mailto:adnan.rashid@poliba.it Adnan Rashid].

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 help merging the code (if it's not already merged) and add some features that are not yet considered in the model.

The candidate should outline in the proposal the features that are planned to be added, and a code mockup (or a complete class diagram) for said features.

* ''Required Experience:'' Fundamentals of IPv6 addressing, C++ programming.
* ''Bonus Experience:'' Familiarity with 6LoWPAN and 6LoWPAN-ND
* ''Interests:'' IPv6 and IoT networks
* ''Difficulty:'' Easy.
* ''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]
** https://gitlab.com/jieqiboh5836/ns-3-dev/-/tree/6LoWPAN-ND-P1
** https://gitlab.com/jieqiboh5836/ns-3-dev/-/tree/6LoWPAN-ND-P2

===OLLA Link Adaptation for 5G-LENA===

Mentors: [mailto:bbojovic@cttc.es Biljana Bojovic], [mailto:tomh@tomh.org Tom Henderson], [mailto:gcarvalho@cttc.es Gabriel Ferreira], [mailto:slagen@cttc.es Sandra Lagen]

This project would focus on improving the realism of the CTTC 5G-LENA by implementing Outer Loop Link Adaptation (OLLA) in the scheduling/link adaptation workflow. In the current baseline, MCS selection is driven by CQI (or SINR-to-CQI mapping) without an outer-loop correction. OLLA is commonly used to track a target BLER by updating an SINR (or CQI) offset based on HARQ ACK/NACK feedback, leading to more stable and realistic link adaptation behavior under varying channel conditions. This project should include this adaptation for the DL and for the UL, integrated in a scheduler-agnostic way so multiple NR schedulers can reuse it with minimal duplication.

In addition, the project would include a performance evaluation:

*comparing the new OLLA-enabled behavior against the current baseline and across multiple representative existing NR schedulers.
*the evaluation should consider throughput, latency, and achieved BLER, including how closely the achieved BLER tracks the configured target.
*the evaluation of the responsiveness to channel condition changes (convergence speed, stability/oscillation behavior).
*the sensitivity to the CQI update frequency and to user data rate / traffic load (how ACK/NACK rate affects convergence).

Additional topics/work items that could be considered if feasible:

*More advanced OLLA algorithms.
*Calibration guidance and/or comparison against published OLLA configurations (when reference data is available).
*Extensions beyond MCS selection (e.g., rank adaptation). This should be relatively easy in the uplink, but for the downlink it should be considered only if the underlying APIs and modeling assumptions are well-defined. Any AI-based approach would be exploratory and out of scope unless the core deliverables are completed early.

For starters, we would suggest adding the CTTC 5G-LENA (nr module) to ns-3 (as a module in the contrib/ directory), building and running the NR examples, and becoming familiar with the current scheduler, HARQ feedback flow, CQI/MCS selection, and TBS computation. 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.

*Required Experience: C++ programming, understanding of 5G NR MAC concepts (scheduling, CQI/MCS, HARQ), wireless networking fundamentals
*Interests: 5G NR simulations, scheduling, link adaptation, performance evaluation
*Difficulty: Medium
*Project size: 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.

=== Enabling 5G NR examples visualization ===

Mentors: [mailto:aashtari@cttc.es Amir Ashtari Gargari], [mailto:gcarvalho@cttc.es Gabriel Ferreira], [mailto:bbojovic@cttc.es Biljana Bojovic] and [mailto:kkoutlia@cttc.es Katerina Koutlia]

The main idea of this project is to allow easier visualization of 5G NR examples by integrating the NR module with some ns-3 visualization tools like NetAnim, or by implementing a kind of web-based visualization, e.g., through Jupyter notebook. The new feature should allow the visualization of already existing traces, visualization of topology, or even some new relevant simulation aspects could be considered. The idea is that users better understand how the metrics collection works, and how changing parameters can affect simulation results. In this project, we are open to other ideas on how to implement visualizations.

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.

=== AODVv2 Protocol enhancements ===

Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], [TBD].

ns-3 contains models for proactive (DSDV and OLSR) and reactive (AODV and DSR) ad hoc routing protocols. AODVv2 is currently an IETF draft, and its implementation in ns-3 is ongoing. This project aims at enhancing the AODVv2 model for ns-3.

In particular the project should address the following points:
# Alignment with the latest drafts,
# Model finalization and testing (in particular for the IPv6 part),
# AODVv2 examples and documentation,
# "External" network routing support.

Collaboration with the draft authors is also highly suggested.

* ''Required Experience:'' Fundamentals of IPv6 addressing, C++ programming.
* ''Bonus Experience:'' Familiarity with AODV implementations in ns-3 and AODVv2
* ''Interests:'' Ad hoc routing
* ''Difficulty:'' Medium.
* ''Recommended reading:''
** [https://www.nsnam.org/docs/models/html/ipv6.html IPv6 model in ns-3]
** [https://www.nsnam.org/docs/models/html/aodv.html AODV model in ns-3]
** [https://gitlab.com/tod97/ns-3-dev/-/tree/aodvv2-icns3-25 AODVv2 model presented at ICNS3-2025]
** [https://datatracker.ietf.org/doc/draft-perkins-manet-aodvv2/05/ Ad Hoc On-demand Distance Vector Version 2 (AODVv2) Routing]

Possible tasks to fulfill the patch requirement:
* [https://gitlab.com/nsnam/ns-3-dev/-/issues/368 Issue #368] - aodv: aodv parameters can be set to "impossible" values

== Large projects (350 hours) ==

=== Mesh Link Establishment (MLE) protocol ===

Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], [mailto:alramonet@is.tokushima-u.ac.jp Alberto Gallegos Ramonet].

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:''
** [https://datatracker.ietf.org/doc/html/draft-ietf-6lo-mesh-link-establishment MLE draft]
** [https://openthread.io/guides/thread-primer/network-discovery Thread primer]
** [https://www.threadgroup.org/ThreadSpec Thread specifications]

Possible tasks to fulfill the patch requirement:
* TBD, contact the mentors if interested.

===Energy Consumption Modeling and Power-Aware Extensions for 5G-LENA===

Mentors: [mailto:kkoutlia@cttc.es Katerina Koutlia], [mailto:bbojovic@cttc.es Biljana Bojovic], [mailto:mmiozzo@cttc.es Marco Miozzo] and [mailto:aashtari@cttc.es Amir Ashtari Gargari]

This project would add energy consumption modeling to the CTTC 5G-LENA (NR module). While 5G-LENA provides a detailed and validated simulation of the 5G NR protocol stack behavior, it currently lacks energy models for UEs and/or gNBs, limiting research on energy efficiency, green networking, 6G sustainability, and potentially AI-driven power-aware control.
The project would first evaluate reuse of the ns-3 Energy Framework (e.g., EnergySource, DeviceEnergyModel) by defining a clean interface between 5G-LENA and the energy module. If existing models are insufficient, the project would design and implement a 5G-specific device energy model (e.g., NrDeviceEnergyModel) and connect it to relevant 5G-LENA state/procedure events.
For starters, we would suggest adding the CTTC 5G-LENA (nr module) to ns-3 (as a module in the contrib/ directory), building and running the NR examples, and studying the Energy Framework integration patterns. Documentation is available here: https://5g-lena.cttc.es/. Tutorial video: https://acmse.net/2021/tutorials-offered/#tut-work03.

Scope (expected deliverables):
*Energy consumption accounting for UEs and/or gNBs
*Per-state (and if feasible per-procedure) modeling, e.g.
**gNB: idle/active/sleep, TX/RX, processing; dependence on bandwidth/PRBs, TX power, MIMO layers/streams/RF chains, load
**UE: TX/RX, measurements, CSI-RS/SRS activity, beamforming-related processing, handover
*Tracing, example(s), and documentation

Optional (time permitting): a simple energy-aware scheduling extension to explore QoS trade-offs (e.g., energy-per-bit or energy-aware MIMO under GBR)

*Required Experience: C++ programming, wireless networking fundamentals (energy/state-machine modeling is a plus)
*Interests: 5G NR simulations, energy efficiency, green networking, 6G sustainability
*Difficulty: Medium
*Project size: 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 integration with ns-3-ai ===

Mentors: [mailto:kkoutlia@cttc.es Katerina Koutlia], [mailto:gcarvalho@cttc.es Gabriel Ferreira], [mailto:aashtari@cttc.es Amir Ashtari Gargari] and [mailto:bbojovic@cttc.es Biljana Bojovic]

The objective of this project is to integrate the ns-3 5G NR module with [https://apps.nsnam.org/app/ns3-ai/ ns-3-ai]. In GSoC 2024 we had a project in which 5G NR was integrated with [https://www.nsnam.org/wiki/GSOC2024RLUsability5G ns-3 gym]. While ns-3 gym is a popular ns-3 module for AI, it is limited to the application of reinforcement learning techniques in networking research. On the other hand, ns-3-ai module provides a more general solution that enables the data interaction between ns-3 and other Python-based AI frameworks, like [https://www.tensorflow.org/api_docs/cc Tensorflow C++ APIs] and [https://pytorch.org/cppdocs/ PyTorch C++ APIs], which opens the door to use different machine learning-based techniques in 5G NR models. The correct functioning of the integration should be tested, and documented, and a fully working example using ns-3-ai should be provided. The contributor can propose a use-case scenario for matching learning. One option is to use it for MAC scheduling, but it could be used for other 5G related research problems, and the contributor is encouraged to propose the use case of his/her interest.

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.
* 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.

=== Linux-like CAKE queue discipline for ns-3 ===

Mentors: [mailto:tahiliani.nitk@gmail.com Mohit P. Tahiliani]

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.

* ''Required Experience:'' Familiarity with queue disciplines, TCP and C++ programming.
* ''Bonus Experience:'' Familiarity with CAKE framework in Linux 4.19
* ''Interests:'' Active Queue Management, Packet scheduling and TCP.
* ''Difficulty:'' Medium to Hard
* ''Recommended reading:''
** [https://arxiv.org/pdf/1804.07617.pdf Piece of CAKE: A Comprehensive Queue Management Solution for Home Gateways]
** [https://lwn.net/Articles/758353/ Let them run CAKE]
** [https://www.nsnam.org/docs/models/html/queue-discs.html Queue disciplines in ns-3]

=== Switched Ethernet ===

Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], TBD.

The current ns-3 models for wired connections are fine for simple networks, but the lack of a switched Ethernet model is a limitation in some cases.

The goal of the idea is to create, test, and document a Switched Ethernet model, able to simulate (at least) 1, 10, and 40 GbE links and model for a switch.

The model of the NetDevice and Channel shall take into account the link delays and errors, similarly to what is done by the point-to-point model. Futhermore, it should be able to set the link speed and if it is full-duplex or half-duplex. Additional support for flow control is a bonus, but not strictly required. Link speed auto-negotiation is not considered to be interesting.

The model for the switch should be modular (i.e., allowing the development of different switch types), and include auto-learning of I/O ports based on the MAC address, i.e., have a MAC/port table, and a basic store-and-forward operation. Features like advanced I/O buffer handling and ARP/NDP spoofing detection are not a priority and shall be left for future implementations.

The model should consider the future implementaion of algorithms like VLANs (IEEE 802.1Q, 802.1ad), and the Spanning Tree Protocol (IEEE 802.1D, 802.1w, and 802.1s). Their implementaion is not required, but the model design should allow their development.

* ''Required Experience:'' Fundamentals of Ethernet sitched networking, C++ programming.
* ''Interests:'' Ethernet networks and switched data networks.
* ''Difficulty:'' Medium.
* ''Recommended reading:''
** [https://codereview.appspot.com/5615049/ Basic implementation (very old)]
** [https://gitlab.com/nsnam/ns-3-dev/-/merge_requests/431 Full-duplex CSMA, somehow related]
** [https://tcipg.org/sites/default/files/papers/2010_Jin_Nicol_Caesar.pdf Paper on gigabit Ethernet switch models for simulation]

Possible tasks to fulfill the patch requirement:
* TBD, contact the mentors if interested.

GSOC2026Projects

2026-03-05T11:49:05Z

Biljana: /* OLLA Link Adaptation and Spec-Compliant TBS Calculation for 5G-LENA */

{{TOC}}

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

* [https://developers.google.com/open-source/gsoc/faq GSoC Frequently Asked Questions]
* [[GSOC2026ContributorGuide | ns-3's 2026 GSoC Contributor guide]]
* [https://developers.google.com/open-source/gsoc/resources/guide GSoC contributor/student guide (not ns-3 specific)]
* [[GSOC2025ApplicationTemplate | 2026 GSoC Contributor application template]]
* [[GSOCMentorGuide | ns-3's GSoC Mentor guide]]
* [https://archive.flossmanuals.net/gsocmentoring/index.html GSoC Mentor guide (not ns-3 specific)]
* [[GSOCSelectionProcess | GSoC Contributor Selection Process]]
* ''Get in contact with the ns-3 team'': [https://groups.google.com/g/ns-developers 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-25. 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 [mailto:tpecorella@mac.com Tommaso Pecorella] and [mailto:tahiliani.nitk@gmail.com Mohit P. Tahiliani]; contact them with any questions. They also hang out on [https://ns-3.zulipchat.com 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 [https://developers.google.com/open-source/gsoc/resources/guide GSoC contributor guide].
* Read [[GSOC2026ContributorGuide |ns-3's 2026 GSoC contributor guide]]
* 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.
* Once it is posted, look through the [[GSOC2024ApplicationTemplate |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 2026, 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 2026. 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 suggests 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>
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.
</blockquote>

=== Patch requirement guidelines ===

In past years, we have asked applicants to submit a patch related to an open issue or a suggested coding exercise. We are undecided at this time whether we will ask for this in 2026; check back later.

=== 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 ===

* [[#Flent Application API in ns-3]] (small size project, 90h)
* [[#Ping and TraverouteV4 enhancements]] (small size project, 90h)
* [[#Internet routing refactory]] (small size project, 90h)
* [[#AODVv2 Protocol enhancements]] (medium size project, 175h)
* [[#Linux-like CAKE queue discipline for ns-3]] (large size project, 350h)
* [[#Switched Ethernet]] (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)

=== 5G NR models enhancements ===

The general idea is to improve the usability of the 5G NR module by adding new examples that help users start building scenario scripts. Also, an interesting improvement could be integration with other modules, like those for AI or visualizations. Here are some project ideas. Depending on the contributor's interest and skills we can adjust these projects' definitions.

* [[#OLLA Link Adaptation and Spec-Compliant TBS Calculation for 5G-LENA]](medium size project, 175h)
* [[#Enabling 5G NR examples visualization]] (medium size project, 175h)
* [[#Energy Consumption Modeling and Power-Aware Extensions for 5G-LENA]](medium size project, 250h)
* [[#5G NR module integration with ns-3-ai]] (large size project, 250h)

== Small sized projects (90 hours) ==

=== Flent Application API in ns-3 ===

Mentors: [mailto:tahiliani.nitk@gmail.com Mohit P. Tahiliani]

Flexible Network Tester (Flent) is a network benchmarking tool. It is written in Python and wraps well-known network benchmarking tools (such as netperf and iperf) into aggregate, repeatable tests, such as a number of tests for Bufferbloat. A basic structure for Flent Application API in ns-3 has been developed. It is a wrapper around existing ns-3 applications. This project has four main goals: (1) update this implementation to match the current ns-3-dev, (2) integrate a JSON library properly (for Flent-style result handling) (3) validate correctness of Flent results produced by ns-3, and (4) Add more Flent-style test examples useful for ns-3 users. The goal of this project is to merge the Flent Application API into ns-3 mainline, not the app store.

* ''Required Experience:'' Familiarity with Flent and C++ programming.
* ''Bonus Experience:'' Familiarity with applications supported in ns-3.
* ''Interests:'' Bufferbloat, TCP, AQM algorithms and ECN.
* ''Difficulty:'' Medium.
* ''Recommended Reading:''
** Flexible Network Tester [[https://flent.org/flent-the-flexible-network-tester.pdf Paper]] [[https://flent.org/ Tool]]
** [https://www.nsnam.org/doxygen/d9/dc9/group__applications.html#details Existing Applications in ns-3]
** [https://gitlab.com/tomhenderson/ns-3-dev/-/commits/flent?ref_type=heads Prior work on Flent application API in ns-3]

=== Internet routing refactory ===

Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], [TBD].

Traditionally IP routing tables are organized in tuples {Dst, DstMask, GatewayAddr}, e.g., {10.42.66.0, 255.255.255.0, 169.254.10.1}, plus other flags and data, like the interface to be used.
In ns-3 this is accomplished by storing three separate objects, two Ipv[4,6]Address, and one Ipv[4Mask,6Prefix].

While this is quite simple to implement, this has some notable drawbacks, e.g., the Dst address must be a network address (Dst & ~DstMask == 0), it is not efficient (the mask or prefix could be represented by a simple integer), and more.
In order to improve code readability and consistency between IPv4 and IPv6, !2645 introduces two new classes: Ipv[4,6]NetworkAddress.

The goal is to refactor the existing routing classes, along with Ipv[4,6]RotingTable classes, so that they use the new classes.
The candidate should provide a clear and convincing plan to pursue the above mentioned goal, all while keeping backward compatibility. The APIs of the existing classes must be kept as they are (at most the can be deprecated), and new APIs should be introduced only where strictly necessary.
Another very important requirement will be to break down the work in multiple sub-tasks, so that the merge process can be gradual.

It is not required that the candidate will update the code for all the routing schemes, but the choice of which routing algorithms will be considered during the project must be clear and motivated.

* ''Required Experience:'' Fundamentals of IPv6 addressing and routing, C++ programming.
* ''Interests:'' IPv4 and IPv6 routing
* ''Difficulty:'' Easy.
* ''Recommended reading:''
** [https://gitlab.com/nsnam/ns-3-dev/-/issues/1239 Issue #1239]
** [https://gitlab.com/nsnam/ns-3-dev/-/merge_requests/2645 Merge Request !2645]

Possible tasks to fulfill the patch requirement:
* Use !2645 to modify all or in part the `Rip` protocol.

=== Ping and TraverouteV4 enhancements ===

Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], [TBD].

The Ping and TraverouteV4 ns-3 application have some small limitations.

In particular 2 of them are annoying.
1. Neither Ping nor TracerouteV4 reacts to ICMP errors or informative messages.
2. As the name implies, TracerouteV4 is IPv4-only and can't be used on IPv6.

The goal is to remove the above mentioned limitations, all or in part. A proposal should clearly outline the plan and improvements to the existing code (e.g., the list of the ICMP messages that will be considered), and a clear breakdown of the work. For the TracerouteV4 refactoring to use IPv6 as well, the proposal must consider the Ping implementation as a guideline.

* ''Required Experience:'' Fundamentals of IPv4, IPv6, ICMP, and ICMPv6. C++ programming.
* ''Interests:'' IPv4 and IPv6.
* ''Difficulty:'' Easy.
* ''Recommended reading:''
** [https://gitlab.com/nsnam/ns-3-dev/-/issues/825 Issue #825]

Possible tasks to fulfill the patch requirement:
* MR to have Ping react to one ICMP message.

== Medium sized projects (175 hours) ==

=== 6LoWPAN mesh-under routing enhancements ===

Mentors: [mailto:tommaso.pecorella@unifi.it 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.
Better approaches are possible, e.g., by leveraging some concepts from RFC 7731, by using SNR as a guidance, or by measuring the local network activity.

The candidate should outline the proposed approach, what parts of code are going to be affected, and how they can be enhanced.

* ''Required Experience:'' Fundamentals of IPv6 addressing, C++ programming.
* ''Bonus Experience:'' Familiarity with mesh routing and 6LoWPAN ns-3
* ''Interests:'' IPv6 mesh routing
* ''Difficulty:'' Easy.
* ''Recommended reading:''
** [https://www.nsnam.org/docs/models/html/sixlowpan.html#mesh-under-routing Mesh-under in ns-3 6LoWPAN]
** [https://datatracker.ietf.org/doc/html/rfc7731 RFC 7731]
** [https://meshtastic.org/docs/overview/mesh-algo/ Meshtastic controlled flooding]
** [https://ieeexplore.ieee.org/document/91339 Routing by controlled flooding in communication networks] (if the document can not be accessed, PM the mentors)

Possible tasks to fulfill the patch requirement:
* The current code is hardwired, i.e., the mesh-under routing scheme is embedded into the SixLowPanNetDevice. Propose a patch to decouple it, using a SixLowPanMeshUnderRouting class to determine the "next hop". The behavior of the actual protocol should be unchanged.

=== 6LoWPAN neighbor discovery protocol ===

Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], [mailto:adnan.rashid@poliba.it Adnan Rashid].

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 help merging the code (if it's not already merged) and add some features that are not yet considered in the model.

The candidate should outline in the proposal the features that are planned to be added, and a code mockup (or a complete class diagram) for said features.

* ''Required Experience:'' Fundamentals of IPv6 addressing, C++ programming.
* ''Bonus Experience:'' Familiarity with 6LoWPAN and 6LoWPAN-ND
* ''Interests:'' IPv6 and IoT networks
* ''Difficulty:'' Easy.
* ''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]
** https://gitlab.com/jieqiboh5836/ns-3-dev/-/tree/6LoWPAN-ND-P1
** https://gitlab.com/jieqiboh5836/ns-3-dev/-/tree/6LoWPAN-ND-P2

===OLLA Link Adaptation for 5G-LENA===

Mentors: [mailto:bbojovic@cttc.es Biljana Bojovic], [mailto:tomh@tomh.org Tom Henderson], [mailto:gcarvalho@cttc.es Gabriel Ferreira], [mailto:slagen@cttc.es Sandra Lagen]

This project would focus on improving the realism of the CTTC 5G-LENA by implementing Outer Loop Link Adaptation (OLLA) in the scheduling/link adaptation workflow. In the current baseline, MCS selection is driven by CQI (or SINR-to-CQI mapping) without an outer-loop correction. OLLA is commonly used to track a target BLER by updating an SINR (or CQI) offset based on HARQ ACK/NACK feedback, leading to more stable and realistic link adaptation behavior under varying channel conditions. This project should include this adaptation for the DL and for the UL, integrated in a scheduler-agnostic way so multiple NR schedulers can reuse it with minimal duplication.

In addition, the project would include a performance evaluation:

*comparing the new OLLA-enabled behavior against the current baseline and across multiple representative existing NR schedulers.
*the evaluation should consider throughput, latency, and achieved BLER, including how closely the achieved BLER tracks the configured target.
*the evaluation of the responsiveness to channel condition changes (convergence speed, stability/oscillation behavior).
*the sensitivity to the CQI update frequency and to user data rate / traffic load (how ACK/NACK rate affects convergence).

Additional topics/work items that could be considered if feasible (stretch goals):

*More advanced OLLA algorithms.
*Calibration guidance and/or comparison against published OLLA configurations (when reference data is available).
*Extensions beyond MCS selection (e.g., rank adaptation). This should be relatively easy in the uplink, but for the downlink it should be considered only if the underlying APIs and modeling assumptions are well-defined. Any AI-based approach would be exploratory and out of scope unless the core deliverables are completed early.

For starters, we would suggest adding the CTTC 5G-LENA (nr module) to ns-3 (as a module in the contrib/ directory), building and running the NR examples, and becoming familiar with the current scheduler, HARQ feedback flow, CQI/MCS selection, and TBS computation. 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.

*Required Experience: C++ programming, understanding of 5G NR MAC concepts (scheduling, CQI/MCS, HARQ), wireless networking fundamentals
*Interests: 5G NR simulations, scheduling, link adaptation, performance evaluation
*Difficulty: Medium
*Project size: 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.

=== Enabling 5G NR examples visualization ===

Mentors: [mailto:aashtari@cttc.es Amir Ashtari Gargari], [mailto:gcarvalho@cttc.es Gabriel Ferreira], [mailto:bbojovic@cttc.es Biljana Bojovic] and [mailto:kkoutlia@cttc.es Katerina Koutlia]

The main idea of this project is to allow easier visualization of 5G NR examples by integrating the NR module with some ns-3 visualization tools like NetAnim, or by implementing a kind of web-based visualization, e.g., through Jupyter notebook. The new feature should allow the visualization of already existing traces, visualization of topology, or even some new relevant simulation aspects could be considered. The idea is that users better understand how the metrics collection works, and how changing parameters can affect simulation results. In this project, we are open to other ideas on how to implement visualizations.

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.

=== AODVv2 Protocol enhancements ===

Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], [TBD].

ns-3 contains models for proactive (DSDV and OLSR) and reactive (AODV and DSR) ad hoc routing protocols. AODVv2 is currently an IETF draft, and its implementation in ns-3 is ongoing. This project aims at enhancing the AODVv2 model for ns-3.

In particular the project should address the following points:
# Alignment with the latest drafts,
# Model finalization and testing (in particular for the IPv6 part),
# AODVv2 examples and documentation,
# "External" network routing support.

Collaboration with the draft authors is also highly suggested.

* ''Required Experience:'' Fundamentals of IPv6 addressing, C++ programming.
* ''Bonus Experience:'' Familiarity with AODV implementations in ns-3 and AODVv2
* ''Interests:'' Ad hoc routing
* ''Difficulty:'' Medium.
* ''Recommended reading:''
** [https://www.nsnam.org/docs/models/html/ipv6.html IPv6 model in ns-3]
** [https://www.nsnam.org/docs/models/html/aodv.html AODV model in ns-3]
** [https://gitlab.com/tod97/ns-3-dev/-/tree/aodvv2-icns3-25 AODVv2 model presented at ICNS3-2025]
** [https://datatracker.ietf.org/doc/draft-perkins-manet-aodvv2/05/ Ad Hoc On-demand Distance Vector Version 2 (AODVv2) Routing]

Possible tasks to fulfill the patch requirement:
* [https://gitlab.com/nsnam/ns-3-dev/-/issues/368 Issue #368] - aodv: aodv parameters can be set to "impossible" values

== Large projects (350 hours) ==

=== Mesh Link Establishment (MLE) protocol ===

Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], [mailto:alramonet@is.tokushima-u.ac.jp Alberto Gallegos Ramonet].

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:''
** [https://datatracker.ietf.org/doc/html/draft-ietf-6lo-mesh-link-establishment MLE draft]
** [https://openthread.io/guides/thread-primer/network-discovery Thread primer]
** [https://www.threadgroup.org/ThreadSpec Thread specifications]

Possible tasks to fulfill the patch requirement:
* TBD, contact the mentors if interested.

===Energy Consumption Modeling and Power-Aware Extensions for 5G-LENA===

Mentors: [mailto:kkoutlia@cttc.es Katerina Koutlia], [mailto:bbojovic@cttc.es Biljana Bojovic], [mailto:mmiozzo@cttc.es Marco Miozzo] and [mailto:aashtari@cttc.es Amir Ashtari Gargari]

This project would add energy consumption modeling to the CTTC 5G-LENA (NR module). While 5G-LENA provides a detailed and validated simulation of the 5G NR protocol stack behavior, it currently lacks energy models for UEs and/or gNBs, limiting research on energy efficiency, green networking, 6G sustainability, and potentially AI-driven power-aware control.
The project would first evaluate reuse of the ns-3 Energy Framework (e.g., EnergySource, DeviceEnergyModel) by defining a clean interface between 5G-LENA and the energy module. If existing models are insufficient, the project would design and implement a 5G-specific device energy model (e.g., NrDeviceEnergyModel) and connect it to relevant 5G-LENA state/procedure events.
For starters, we would suggest adding the CTTC 5G-LENA (nr module) to ns-3 (as a module in the contrib/ directory), building and running the NR examples, and studying the Energy Framework integration patterns. Documentation is available here: https://5g-lena.cttc.es/. Tutorial video: https://acmse.net/2021/tutorials-offered/#tut-work03.

Scope (expected deliverables):
*Energy consumption accounting for UEs and/or gNBs
*Per-state (and if feasible per-procedure) modeling, e.g.
**gNB: idle/active/sleep, TX/RX, processing; dependence on bandwidth/PRBs, TX power, MIMO layers/streams/RF chains, load
**UE: TX/RX, measurements, CSI-RS/SRS activity, beamforming-related processing, handover
*Tracing, example(s), and documentation

Optional (time permitting): a simple energy-aware scheduling extension to explore QoS trade-offs (e.g., energy-per-bit or energy-aware MIMO under GBR)

*Required Experience: C++ programming, wireless networking fundamentals (energy/state-machine modeling is a plus)
*Interests: 5G NR simulations, energy efficiency, green networking, 6G sustainability
*Difficulty: Medium
*Project size: 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 integration with ns-3-ai ===

Mentors: [mailto:kkoutlia@cttc.es Katerina Koutlia], [mailto:gcarvalho@cttc.es Gabriel Ferreira], [mailto:aashtari@cttc.es Amir Ashtari Gargari] and [mailto:bbojovic@cttc.es Biljana Bojovic]

The objective of this project is to integrate the ns-3 5G NR module with [https://apps.nsnam.org/app/ns3-ai/ ns-3-ai]. In GSoC 2024 we had a project in which 5G NR was integrated with [https://www.nsnam.org/wiki/GSOC2024RLUsability5G ns-3 gym]. While ns-3 gym is a popular ns-3 module for AI, it is limited to the application of reinforcement learning techniques in networking research. On the other hand, ns-3-ai module provides a more general solution that enables the data interaction between ns-3 and other Python-based AI frameworks, like [https://www.tensorflow.org/api_docs/cc Tensorflow C++ APIs] and [https://pytorch.org/cppdocs/ PyTorch C++ APIs], which opens the door to use different machine learning-based techniques in 5G NR models. The correct functioning of the integration should be tested, and documented, and a fully working example using ns-3-ai should be provided. The contributor can propose a use-case scenario for matching learning. One option is to use it for MAC scheduling, but it could be used for other 5G related research problems, and the contributor is encouraged to propose the use case of his/her interest.

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.
* 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.

=== Linux-like CAKE queue discipline for ns-3 ===

Mentors: [mailto:tahiliani.nitk@gmail.com Mohit P. Tahiliani]

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.

* ''Required Experience:'' Familiarity with queue disciplines, TCP and C++ programming.
* ''Bonus Experience:'' Familiarity with CAKE framework in Linux 4.19
* ''Interests:'' Active Queue Management, Packet scheduling and TCP.
* ''Difficulty:'' Medium to Hard
* ''Recommended reading:''
** [https://arxiv.org/pdf/1804.07617.pdf Piece of CAKE: A Comprehensive Queue Management Solution for Home Gateways]
** [https://lwn.net/Articles/758353/ Let them run CAKE]
** [https://www.nsnam.org/docs/models/html/queue-discs.html Queue disciplines in ns-3]

=== Switched Ethernet ===

Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], TBD.

The current ns-3 models for wired connections are fine for simple networks, but the lack of a switched Ethernet model is a limitation in some cases.

The goal of the idea is to create, test, and document a Switched Ethernet model, able to simulate (at least) 1, 10, and 40 GbE links and model for a switch.

The model of the NetDevice and Channel shall take into account the link delays and errors, similarly to what is done by the point-to-point model. Futhermore, it should be able to set the link speed and if it is full-duplex or half-duplex. Additional support for flow control is a bonus, but not strictly required. Link speed auto-negotiation is not considered to be interesting.

The model for the switch should be modular (i.e., allowing the development of different switch types), and include auto-learning of I/O ports based on the MAC address, i.e., have a MAC/port table, and a basic store-and-forward operation. Features like advanced I/O buffer handling and ARP/NDP spoofing detection are not a priority and shall be left for future implementations.

The model should consider the future implementaion of algorithms like VLANs (IEEE 802.1Q, 802.1ad), and the Spanning Tree Protocol (IEEE 802.1D, 802.1w, and 802.1s). Their implementaion is not required, but the model design should allow their development.

* ''Required Experience:'' Fundamentals of Ethernet sitched networking, C++ programming.
* ''Interests:'' Ethernet networks and switched data networks.
* ''Difficulty:'' Medium.
* ''Recommended reading:''
** [https://codereview.appspot.com/5615049/ Basic implementation (very old)]
** [https://gitlab.com/nsnam/ns-3-dev/-/merge_requests/431 Full-duplex CSMA, somehow related]
** [https://tcipg.org/sites/default/files/papers/2010_Jin_Nicol_Caesar.pdf Paper on gigabit Ethernet switch models for simulation]

Possible tasks to fulfill the patch requirement:
* TBD, contact the mentors if interested.

GSOC2026Projects

2026-02-20T15:12:52Z

Biljana: /* OLLA Link Adaptation and Spec-Compliant TBS Calculation for 5G-LENA */

{{TOC}}

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

* [https://developers.google.com/open-source/gsoc/faq GSoC Frequently Asked Questions]
* [[GSOC2026ContributorGuide | ns-3's 2026 GSoC Contributor guide]]
* [https://developers.google.com/open-source/gsoc/resources/guide GSoC contributor/student guide (not ns-3 specific)]
* [[GSOC2025ApplicationTemplate | 2026 GSoC Contributor application template]]
* [[GSOCMentorGuide | ns-3's GSoC Mentor guide]]
* [https://archive.flossmanuals.net/gsocmentoring/index.html GSoC Mentor guide (not ns-3 specific)]
* [[GSOCSelectionProcess | GSoC Contributor Selection Process]]
* ''Get in contact with the ns-3 team'': [https://groups.google.com/g/ns-developers 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-25. 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 [mailto:tpecorella@mac.com Tommaso Pecorella] and [mailto:tahiliani.nitk@gmail.com Mohit P. Tahiliani]; contact them with any questions. They also hang out on [https://ns-3.zulipchat.com 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 [https://developers.google.com/open-source/gsoc/resources/guide GSoC contributor guide].
* Read [[GSOC2026ContributorGuide |ns-3's 2026 GSoC contributor guide]]
* 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.
* Once it is posted, look through the [[GSOC2024ApplicationTemplate |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 2026, 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 2026. 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 suggests 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>
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.
</blockquote>

=== Patch requirement guidelines ===

In past years, we have asked applicants to submit a patch related to an open issue or a suggested coding exercise. We are undecided at this time whether we will ask for this in 2026; check back later.

=== 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 ===

* [[#Flent Application API in ns-3]] (small size project, 90h)
* [[#Ping and TraverouteV4 enhancements]] (small size project, 90h)
* [[#Internet routing refactory]] (small size project, 90h)
* [[#AODVv2 Protocol enhancements]] (medium size project, 175h)
* [[#Linux-like CAKE queue discipline for ns-3]] (large size project, 350h)
* [[#Switched Ethernet]] (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)

=== 5G NR models enhancements ===

The general idea is to improve the usability of the 5G NR module by adding new examples that help users start building scenario scripts. Also, an interesting improvement could be integration with other modules, like those for AI or visualizations. Here are some project ideas. Depending on the contributor's interest and skills we can adjust these projects' definitions.

* [[#OLLA Link Adaptation and Spec-Compliant TBS Calculation for 5G-LENA]](medium size project, 175h)
* [[#Enabling 5G NR examples visualization]] (medium size project, 175h)
* [[#Energy Consumption Modeling and Power-Aware Extensions for 5G-LENA]](medium size project, 250h)
* [[#5G NR module integration with ns-3-ai]] (large size project, 250h)

== Small sized projects (90 hours) ==

=== Flent Application API in ns-3 ===

Mentors: [mailto:tahiliani.nitk@gmail.com Mohit P. Tahiliani]

Flexible Network Tester (Flent) is a network benchmarking tool. It is written in Python and wraps well-known network benchmarking tools (such as netperf and iperf) into aggregate, repeatable tests, such as a number of tests for Bufferbloat. A basic structure for Flent Application API in ns-3 has been developed. It is a wrapper around existing ns-3 applications. This project has four main goals: (1) update this implementation to match the current ns-3-dev, (2) integrate a JSON library properly (for Flent-style result handling) (3) validate correctness of Flent results produced by ns-3, and (4) Add more Flent-style test examples useful for ns-3 users. The goal of this project is to merge the Flent Application API into ns-3 mainline, not the app store.

* ''Required Experience:'' Familiarity with Flent and C++ programming.
* ''Bonus Experience:'' Familiarity with applications supported in ns-3.
* ''Interests:'' Bufferbloat, TCP, AQM algorithms and ECN.
* ''Difficulty:'' Medium.
* ''Recommended Reading:''
** Flexible Network Tester [[https://flent.org/flent-the-flexible-network-tester.pdf Paper]] [[https://flent.org/ Tool]]
** [https://www.nsnam.org/doxygen/d9/dc9/group__applications.html#details Existing Applications in ns-3]
** [https://gitlab.com/tomhenderson/ns-3-dev/-/commits/flent?ref_type=heads Prior work on Flent application API in ns-3]

=== Internet routing refactory ===

Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], [TBD].

Traditionally IP routing tables are organized in tuples {Dst, DstMask, GatewayAddr}, e.g., {10.42.66.0, 255.255.255.0, 169.254.10.1}, plus other flags and data, like the interface to be used.
In ns-3 this is accomplished by storing three separate objects, two Ipv[4,6]Address, and one Ipv[4Mask,6Prefix].

While this is quite simple to implement, this has some notable drawbacks, e.g., the Dst address must be a network address (Dst & ~DstMask == 0), it is not efficient (the mask or prefix could be represented by a simple integer), and more.
In order to improve code readability and consistency between IPv4 and IPv6, !2645 introduces two new classes: Ipv[4,6]NetworkAddress.

The goal is to refactor the existing routing classes, along with Ipv[4,6]RotingTable classes, so that they use the new classes.
The candidate should provide a clear and convincing plan to pursue the above mentioned goal, all while keeping backward compatibility. The APIs of the existing classes must be kept as they are (at most the can be deprecated), and new APIs should be introduced only where strictly necessary.
Another very important requirement will be to break down the work in multiple sub-tasks, so that the merge process can be gradual.

It is not required that the candidate will update the code for all the routing schemes, but the choice of which routing algorithms will be considered during the project must be clear and motivated.

* ''Required Experience:'' Fundamentals of IPv6 addressing and routing, C++ programming.
* ''Interests:'' IPv4 and IPv6 routing
* ''Difficulty:'' Easy.
* ''Recommended reading:''
** [https://gitlab.com/nsnam/ns-3-dev/-/issues/1239 Issue #1239]
** [https://gitlab.com/nsnam/ns-3-dev/-/merge_requests/2645 Merge Request !2645]

Possible tasks to fulfill the patch requirement:
* Use !2645 to modify all or in part the `Rip` protocol.

=== Ping and TraverouteV4 enhancements ===

Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], [TBD].

The Ping and TraverouteV4 ns-3 application have some small limitations.

In particular 2 of them are annoying.
1. Neither Ping nor TracerouteV4 reacts to ICMP errors or informative messages.
2. As the name implies, TracerouteV4 is IPv4-only and can't be used on IPv6.

The goal is to remove the above mentioned limitations, all or in part. A proposal should clearly outline the plan and improvements to the existing code (e.g., the list of the ICMP messages that will be considered), and a clear breakdown of the work. For the TracerouteV4 refactoring to use IPv6 as well, the proposal must consider the Ping implementation as a guideline.

* ''Required Experience:'' Fundamentals of IPv4, IPv6, ICMP, and ICMPv6. C++ programming.
* ''Interests:'' IPv4 and IPv6.
* ''Difficulty:'' Easy.
* ''Recommended reading:''
** [https://gitlab.com/nsnam/ns-3-dev/-/issues/825 Issue #825]

Possible tasks to fulfill the patch requirement:
* MR to have Ping react to one ICMP message.

== Medium sized projects (175 hours) ==

=== 6LoWPAN mesh-under routing enhancements ===

Mentors: [mailto:tommaso.pecorella@unifi.it 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.
Better approaches are possible, e.g., by leveraging some concepts from RFC 7731, by using SNR as a guidance, or by measuring the local network activity.

The candidate should outline the proposed approach, what parts of code are going to be affected, and how they can be enhanced.

* ''Required Experience:'' Fundamentals of IPv6 addressing, C++ programming.
* ''Bonus Experience:'' Familiarity with mesh routing and 6LoWPAN ns-3
* ''Interests:'' IPv6 mesh routing
* ''Difficulty:'' Easy.
* ''Recommended reading:''
** [https://www.nsnam.org/docs/models/html/sixlowpan.html#mesh-under-routing Mesh-under in ns-3 6LoWPAN]
** [https://datatracker.ietf.org/doc/html/rfc7731 RFC 7731]
** [https://meshtastic.org/docs/overview/mesh-algo/ Meshtastic controlled flooding]
** [https://ieeexplore.ieee.org/document/91339 Routing by controlled flooding in communication networks] (if the document can not be accessed, PM the mentors)

Possible tasks to fulfill the patch requirement:
* The current code is hardwired, i.e., the mesh-under routing scheme is embedded into the SixLowPanNetDevice. Propose a patch to decouple it, using a SixLowPanMeshUnderRouting class to determine the "next hop". The behavior of the actual protocol should be unchanged.

=== 6LoWPAN neighbor discovery protocol ===

Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], [mailto:adnan.rashid@poliba.it Adnan Rashid].

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 help merging the code (if it's not already merged) and add some features that are not yet considered in the model.

The candidate should outline in the proposal the features that are planned to be added, and a code mockup (or a complete class diagram) for said features.

* ''Required Experience:'' Fundamentals of IPv6 addressing, C++ programming.
* ''Bonus Experience:'' Familiarity with 6LoWPAN and 6LoWPAN-ND
* ''Interests:'' IPv6 and IoT networks
* ''Difficulty:'' Easy.
* ''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]
** https://gitlab.com/jieqiboh5836/ns-3-dev/-/tree/6LoWPAN-ND-P1
** https://gitlab.com/jieqiboh5836/ns-3-dev/-/tree/6LoWPAN-ND-P2

===OLLA Link Adaptation and Spec-Compliant TBS Calculation for 5G-LENA===

Mentors: [mailto:slagen@cttc.es Sandra Lagen], [mailto:tomh@tomh.org Tom Henderson], [mailto:bbojovic@cttc.es Biljana Bojovic], [mailto:gcarvalho@cttc.es Gabriel Ferreira], [mailto:kkoutlia@cttc.es Katerina Koutlia]

This project would focus on improving the realism and correctness of the CTTC 5G-LENA (NR module) by implementing Outer Loop Link Adaptation (OLLA) in the scheduling/link adaptation workflow, and by improving the Transport Block Size (TBS) calculation to be aligned with the 5G NR specification. OLLA is commonly used to track a target BLER by updating an SINR (or CQI) offset based on HARQ ACK/NACK feedback, leading to more stable and realistic link adaptation behavior.
In addition, the project would include a performance evaluation comparing the new OLLA-enabled behavior against the current baseline and across multiple existing NR schedulers. The evaluation should consider throughput, latency, achieved BLER, convergence behavior, and fairness.

For starters, we would suggest adding the CTTC 5G-LENA (nr module) to ns-3 (as a module in the contrib/ directory), building and running the NR examples, and becoming familiar with the current scheduler, HARQ feedback flow, CQI/MCS selection, and TBS computation. 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.

*Required Experience: C++ programming, understanding of 5G NR MAC concepts (scheduling, CQI/MCS, HARQ), wireless networking fundamentals
*Interests: 5G NR simulations, scheduling, link adaptation, performance evaluation
*Difficulty: Medium
*Project size: 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.

=== Enabling 5G NR examples visualization ===

Mentors: [mailto:aashtari@cttc.es Amir Ashtari Gargari], [mailto:gcarvalho@cttc.es Gabriel Ferreira], [mailto:bbojovic@cttc.es Biljana Bojovic] and [mailto:kkoutlia@cttc.es Katerina Koutlia]

The main idea of this project is to allow easier visualization of 5G NR examples by integrating the NR module with some ns-3 visualization tools like NetAnim, or by implementing a kind of web-based visualization, e.g., through Jupyter notebook. The new feature should allow the visualization of already existing traces, visualization of topology, or even some new relevant simulation aspects could be considered. The idea is that users better understand how the metrics collection works, and how changing parameters can affect simulation results. In this project, we are open to other ideas on how to implement visualizations.

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.

=== AODVv2 Protocol enhancements ===

Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], [TBD].

ns-3 contains models for proactive (DSDV and OLSR) and reactive (AODV and DSR) ad hoc routing protocols. AODVv2 is currently an IETF draft, and its implementation in ns-3 is ongoing. This project aims at enhancing the AODVv2 model for ns-3.

In particular the project should address the following points:
# Alignment with the latest drafts,
# Model finalization and testing (in particular for the IPv6 part),
# AODVv2 examples and documentation,
# "External" network routing support.

Collaboration with the draft authors is also highly suggested.

* ''Required Experience:'' Fundamentals of IPv6 addressing, C++ programming.
* ''Bonus Experience:'' Familiarity with AODV implementations in ns-3 and AODVv2
* ''Interests:'' Ad hoc routing
* ''Difficulty:'' Medium.
* ''Recommended reading:''
** [https://www.nsnam.org/docs/models/html/ipv6.html IPv6 model in ns-3]
** [https://www.nsnam.org/docs/models/html/aodv.html AODV model in ns-3]
** [https://gitlab.com/tod97/ns-3-dev/-/tree/aodvv2-icns3-25 AODVv2 model presented at ICNS3-2025]
** [https://datatracker.ietf.org/doc/draft-perkins-manet-aodvv2/05/ Ad Hoc On-demand Distance Vector Version 2 (AODVv2) Routing]

Possible tasks to fulfill the patch requirement:
* [https://gitlab.com/nsnam/ns-3-dev/-/issues/368 Issue #368] - aodv: aodv parameters can be set to "impossible" values

== Large projects (350 hours) ==

=== Mesh Link Establishment (MLE) protocol ===

Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], [mailto:alramonet@is.tokushima-u.ac.jp Alberto Gallegos Ramonet].

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:''
** [https://datatracker.ietf.org/doc/html/draft-ietf-6lo-mesh-link-establishment MLE draft]
** [https://openthread.io/guides/thread-primer/network-discovery Thread primer]
** [https://www.threadgroup.org/ThreadSpec Thread specifications]

Possible tasks to fulfill the patch requirement:
* TBD, contact the mentors if interested.

===Energy Consumption Modeling and Power-Aware Extensions for 5G-LENA===

Mentors: [mailto:kkoutlia@cttc.es Katerina Koutlia], [mailto:bbojovic@cttc.es Biljana Bojovic], [mailto:mmiozzo@cttc.es Marco Miozzo] and [mailto:aashtari@cttc.es Amir Ashtari Gargari]

This project would add energy consumption modeling to the CTTC 5G-LENA (NR module). While 5G-LENA provides a detailed and validated simulation of the 5G NR protocol stack behavior, it currently lacks energy models for UEs and/or gNBs, limiting research on energy efficiency, green networking, 6G sustainability, and potentially AI-driven power-aware control.
The project would first evaluate reuse of the ns-3 Energy Framework (e.g., EnergySource, DeviceEnergyModel) by defining a clean interface between 5G-LENA and the energy module. If existing models are insufficient, the project would design and implement a 5G-specific device energy model (e.g., NrDeviceEnergyModel) and connect it to relevant 5G-LENA state/procedure events.
For starters, we would suggest adding the CTTC 5G-LENA (nr module) to ns-3 (as a module in the contrib/ directory), building and running the NR examples, and studying the Energy Framework integration patterns. Documentation is available here: https://5g-lena.cttc.es/. Tutorial video: https://acmse.net/2021/tutorials-offered/#tut-work03.

Scope (expected deliverables):
*Energy consumption accounting for UEs and/or gNBs
*Per-state (and if feasible per-procedure) modeling, e.g.
**gNB: idle/active/sleep, TX/RX, processing; dependence on bandwidth/PRBs, TX power, MIMO layers/streams/RF chains, load
**UE: TX/RX, measurements, CSI-RS/SRS activity, beamforming-related processing, handover
*Tracing, example(s), and documentation

Optional (time permitting): a simple energy-aware scheduling extension to explore QoS trade-offs (e.g., energy-per-bit or energy-aware MIMO under GBR)

*Required Experience: C++ programming, wireless networking fundamentals (energy/state-machine modeling is a plus)
*Interests: 5G NR simulations, energy efficiency, green networking, 6G sustainability
*Difficulty: Medium
*Project size: 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 integration with ns-3-ai ===

Mentors: [mailto:kkoutlia@cttc.es Katerina Koutlia], [mailto:gcarvalho@cttc.es Gabriel Ferreira], [mailto:aashtari@cttc.es Amir Ashtari Gargari] and [mailto:bbojovic@cttc.es Biljana Bojovic]

The objective of this project is to integrate the ns-3 5G NR module with [https://apps.nsnam.org/app/ns3-ai/ ns-3-ai]. In GSoC 2024 we had a project in which 5G NR was integrated with [https://www.nsnam.org/wiki/GSOC2024RLUsability5G ns-3 gym]. While ns-3 gym is a popular ns-3 module for AI, it is limited to the application of reinforcement learning techniques in networking research. On the other hand, ns-3-ai module provides a more general solution that enables the data interaction between ns-3 and other Python-based AI frameworks, like [https://www.tensorflow.org/api_docs/cc Tensorflow C++ APIs] and [https://pytorch.org/cppdocs/ PyTorch C++ APIs], which opens the door to use different machine learning-based techniques in 5G NR models. The correct functioning of the integration should be tested, and documented, and a fully working example using ns-3-ai should be provided. The contributor can propose a use-case scenario for matching learning. One option is to use it for MAC scheduling, but it could be used for other 5G related research problems, and the contributor is encouraged to propose the use case of his/her interest.

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.
* 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.

=== Linux-like CAKE queue discipline for ns-3 ===

Mentors: [mailto:tahiliani.nitk@gmail.com Mohit P. Tahiliani]

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.

* ''Required Experience:'' Familiarity with queue disciplines, TCP and C++ programming.
* ''Bonus Experience:'' Familiarity with CAKE framework in Linux 4.19
* ''Interests:'' Active Queue Management, Packet scheduling and TCP.
* ''Difficulty:'' Medium to Hard
* ''Recommended reading:''
** [https://arxiv.org/pdf/1804.07617.pdf Piece of CAKE: A Comprehensive Queue Management Solution for Home Gateways]
** [https://lwn.net/Articles/758353/ Let them run CAKE]
** [https://www.nsnam.org/docs/models/html/queue-discs.html Queue disciplines in ns-3]

=== Switched Ethernet ===

Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], TBD.

The current ns-3 models for wired connections are fine for simple networks, but the lack of a switched Ethernet model is a limitation in some cases.

The goal of the idea is to create, test, and document a Switched Ethernet model, able to simulate (at least) 1, 10, and 40 GbE links and model for a switch.

The model of the NetDevice and Channel shall take into account the link delays and errors, similarly to what is done by the point-to-point model. Futhermore, it should be able to set the link speed and if it is full-duplex or half-duplex. Additional support for flow control is a bonus, but not strictly required. Link speed auto-negotiation is not considered to be interesting.

The model for the switch should be modular (i.e., allowing the development of different switch types), and include auto-learning of I/O ports based on the MAC address, i.e., have a MAC/port table, and a basic store-and-forward operation. Features like advanced I/O buffer handling and ARP/NDP spoofing detection are not a priority and shall be left for future implementations.

The model should consider the future implementaion of algorithms like VLANs (IEEE 802.1Q, 802.1ad), and the Spanning Tree Protocol (IEEE 802.1D, 802.1w, and 802.1s). Their implementaion is not required, but the model design should allow their development.

* ''Required Experience:'' Fundamentals of Ethernet sitched networking, C++ programming.
* ''Interests:'' Ethernet networks and switched data networks.
* ''Difficulty:'' Medium.
* ''Recommended reading:''
** [https://www2.nsnam.org/bugzilla/show_bug.cgi?id=2602 Basic implementation (very old)]
** [https://gitlab.com/nsnam/ns-3-dev/-/merge_requests/431 Full-duplex CSMA, somehow related]
** [https://tcipg.org/sites/default/files/papers/2010_Jin_Nicol_Caesar.pdf Paper on gigabit Ethernet switch models for simulation]

Possible tasks to fulfill the patch requirement:
* TBD, contact the mentors if interested.

GSOC2026Projects

2026-02-04T21:37:58Z

Biljana:

GSOC2026Projects

2026-02-04T21:36:05Z

Biljana:

GSOC2026Projects

2026-02-04T16:31:53Z

Biljana: /* OLLA Link Adaptation and Spec-Compliant TBS Calculation for 5G-LENA */

{{TOC}}

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

* [https://developers.google.com/open-source/gsoc/faq GSoC Frequently Asked Questions]
* [[GSOC2026ContributorGuide | ns-3's 2026 GSoC Contributor guide]]
* [https://developers.google.com/open-source/gsoc/resources/guide GSoC contributor/student guide (not ns-3 specific)]
* [[GSOC2025ApplicationTemplate | 2026 GSoC Contributor application template]]
* [[GSOCMentorGuide | ns-3's GSoC Mentor guide]]
* [https://archive.flossmanuals.net/gsocmentoring/index.html GSoC Mentor guide (not ns-3 specific)]
* [[GSOCSelectionProcess | GSoC Contributor Selection Process]]
* ''Get in contact with the ns-3 team'': [https://groups.google.com/g/ns-developers 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-25. 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 [mailto:tpecorella@mac.com Tommaso Pecorella] and [mailto:tahiliani.nitk@gmail.com Mohit P. Tahiliani]; contact them with any questions. They also hang out on [https://ns-3.zulipchat.com 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 [https://developers.google.com/open-source/gsoc/resources/guide GSoC contributor guide].
* Read [[GSOC2026ContributorGuide |ns-3's 2026 GSoC contributor guide]]
* 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.
* Once it is posted, look through the [[GSOC2024ApplicationTemplate |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 2026, 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 2026. 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 suggests 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>
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.
</blockquote>

=== Patch requirement guidelines ===

In past years, we have asked applicants to submit a patch related to an open issue or a suggested coding exercise. We are undecided at this time whether we will ask for this in 2026; check back later.

=== 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 ===

* [[#AODVv2 Protocol enhancements]] (medium size project, 175h)
* [[#Linux-like CAKE queue discipline for ns-3]] (large size project, 350h)
* [[#Switched Ethernet]] (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)

=== 5G NR models enhancements ===

The general idea is to improve the usability of the 5G NR module by adding new examples that help users start building scenario scripts. Also, an interesting improvement could be integration with other modules, like those for AI or visualizations. Here are some project ideas. Depending on the contributor's interest and skills we can adjust these projects' definitions.

* [[#OLLA Link Adaptation and Spec-Compliant TBS Calculation for 5G-LENA]](medium size project, 175h)
* [[#Energy Consumption Modeling and Power-Aware Extensions for 5G-LENA]](medium size project, 175h)
* [[#Enabling 5G NR examples visualization]] (medium size project, 175h)
* [[#5G NR module integration with ns-3-ai]] (large size project, 250h)

== Small sized projects (90 hours) ==

== Medium sized projects (175 hours) ==

=== 6LoWPAN mesh-under routing enhancements ===

Mentors: [mailto:tommaso.pecorella@unifi.it 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.
Better approaches are possible, e.g., by leveraging some concepts from RFC 7731, by using SNR as a guidance, or by measuring the local network activity.

The candidate should outline the proposed approach, what parts of code are going to be affected, and how they can be enhanced.

* ''Required Experience:'' Fundamentals of IPv6 addressing, C++ programming.
* ''Bonus Experience:'' Familiarity with mesh routing and 6LoWPAN ns-3
* ''Interests:'' IPv6 mesh routing
* ''Difficulty:'' Easy.
* ''Recommended reading:''
** [https://www.nsnam.org/docs/models/html/sixlowpan.html#mesh-under-routing Mesh-under in ns-3 6LoWPAN]
** [https://datatracker.ietf.org/doc/html/rfc7731 RFC 7731]
** [https://meshtastic.org/docs/overview/mesh-algo/ Meshtastic controlled flooding]
** [https://ieeexplore.ieee.org/document/91339 Routing by controlled flooding in communication networks] (if the document can not be accessed, PM the mentors)

Possible tasks to fulfill the patch requirement:
* The current code is hardwired, i.e., the mesh-under routing scheme is embedded into the SixLowPanNetDevice. Propose a patch to decouple it, using a SixLowPanMeshUnderRouting class to determine the "next hop". The behavior of the actual protocol should be unchanged.

=== 6LoWPAN neighbor discovery protocol ===

Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], [mailto:adnan.rashid@poliba.it Adnan Rashid].

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 help merging the code (if it's not already merged) and add some features that are not yet considered in the model.

The candidate should outline in the proposal the features that are planned to be added, and a code mockup (or a complete class diagram) for said features.

* ''Required Experience:'' Fundamentals of IPv6 addressing, C++ programming.
* ''Bonus Experience:'' Familiarity with 6LoWPAN and 6LoWPAN-ND
* ''Interests:'' IPv6 and IoT networks
* ''Difficulty:'' Easy.
* ''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]
** https://gitlab.com/jieqiboh5836/ns-3-dev/-/tree/6LoWPAN-ND-P1
** https://gitlab.com/jieqiboh5836/ns-3-dev/-/tree/6LoWPAN-ND-P2

===OLLA Link Adaptation and Spec-Compliant TBS Calculation for 5G-LENA===

Mentors: [mailto:slagen@cttc.es Sandra Lagen], [mailto:bbojovic@cttc.es Biljana Bojovic], [mailto:gcarvalho@cttc.es Gabriel Ferreira], [mailto:kkoutlia@cttc.es Katerina Koutlia]

This project would focus on improving the realism and correctness of the CTTC 5G-LENA (NR module) by implementing Outer Loop Link Adaptation (OLLA) in the scheduling/link adaptation workflow, and by improving the Transport Block Size (TBS) calculation to be aligned with the 5G NR specification. OLLA is commonly used to track a target BLER by updating an SINR (or CQI) offset based on HARQ ACK/NACK feedback, leading to more stable and realistic link adaptation behavior.
In addition, the project would include a performance evaluation comparing the new OLLA-enabled behavior against the current baseline and across multiple existing NR schedulers. The evaluation should consider throughput, latency, achieved BLER, convergence behavior, and fairness.

For starters, we would suggest adding the CTTC 5G-LENA (nr module) to ns-3 (as a module in the contrib/ directory), building and running the NR examples, and becoming familiar with the current scheduler, HARQ feedback flow, CQI/MCS selection, and TBS computation. 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.

*Required Experience: C++ programming, understanding of 5G NR MAC concepts (scheduling, CQI/MCS, HARQ), wireless networking fundamentals
*Interests: 5G NR simulations, scheduling, link adaptation, performance evaluation
*Difficulty: Medium
*Project size: 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.

===Energy Consumption Modeling and Power-Aware Extensions for 5G-LENA===

Mentors: Katerina Koutlia, Biljana Bojovic and Amir Ashtari.

This project would add energy consumption modeling to the CTTC 5G-LENA (NR module). While 5G-LENA provides a detailed and validated simulation of the 5G NR protocol stack behavior, it currently lacks energy models for UEs and/or gNBs, limiting research on energy efficiency, green networking, 6G sustainability, and potentially AI-driven power-aware control.
The project would first evaluate reuse of the ns-3 Energy Framework (e.g., EnergySource, DeviceEnergyModel) by defining a clean interface between 5G-LENA and the energy module. If existing models are insufficient, the project would design and implement a 5G-specific device energy model (e.g., NrDeviceEnergyModel) and connect it to relevant 5G-LENA state/procedure events.
For starters, we would suggest adding the CTTC 5G-LENA (nr module) to ns-3 (as a module in the contrib/ directory), building and running the NR examples, and studying the Energy Framework integration patterns. Documentation is available here: https://5g-lena.cttc.es/. Tutorial video: https://acmse.net/2021/tutorials-offered/#tut-work03.

Scope (expected deliverables):
*Energy consumption accounting for UEs and/or gNBs
*Per-state (and if feasible per-procedure) modeling, e.g.
**gNB: idle/active/sleep, TX/RX, processing; dependence on bandwidth/PRBs, TX power, MIMO layers/streams/RF chains, load
**UE: TX/RX, measurements, CSI-RS/SRS activity, beamforming-related processing, handover
*Tracing, example(s), and documentation

Optional (time permitting): a simple energy-aware scheduling extension to explore QoS trade-offs (e.g., energy-per-bit or energy-aware MIMO under GBR)

*Required Experience: C++ programming, wireless networking fundamentals (energy/state-machine modeling is a plus)
*Interests: 5G NR simulations, energy efficiency, green networking, 6G sustainability
*Difficulty: Medium
*Project size: 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.

=== Improving 5G NR module usability through helpers ===

Mentors: [mailto:bbojovic@cttc.es Biljana Bojovic],[mailto:gcarvalho@cttc.es Gabriel Ferreira], [mailto:kkoutlia@cttc.es Katerina Koutlia] and [mailto:aashtari@cttc.es Amir Ashtari Gargari]

This project would be focused on improving the usability of the 5G nr module by enabling new helper support. The new helpers should allow for simplifying the setup of NR applications, XR applications, scenarios, the management of the configuration of many parameters of the scenario, etc. All the NR examples should be updated to make use of these new helpers. The use of such helpers would help reduce significantly the code duplication in 5G NR examples.

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.

* 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]. 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.

=== Enabling 5G NR examples visualization ===

Mentors: [mailto:aashtari@cttc.es Amir Ashtari Gargari], [mailto:gcarvalho@cttc.es Gabriel Ferreira], [mailto:bbojovic@cttc.es Biljana Bojovic] and [mailto:kkoutlia@cttc.es Katerina Koutlia]

The main idea of this project is to allow easier visualization of 5G NR examples by integrating the NR module with some ns-3 visualization tools like NetAnim, or by implementing a kind of web-based visualization, e.g., through Jupyter notebook. The new feature should allow the visualization of already existing traces, visualization of topology, or even some new relevant simulation aspects could be considered. The idea is that users better understand how the metrics collection works, and how changing parameters can affect simulation results. In this project, we are open to other ideas on how to implement visualizations.

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.

=== AODVv2 Protocol enhancements ===

Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], [TBD].

ns-3 contains models for proactive (DSDV and OLSR) and reactive (AODV and DSR) ad hoc routing protocols. AODVv2 is currently an IETF draft, and its implementation in ns-3 is ongoing. This project aims at enhancing the AODVv2 model for ns-3.

In particular the project should address the following points:
# Alignment with the latest drafts,
# Model finalization and testing (in particular for the IPv6 part),
# AODVv2 examples and documentation,
# "External" network routing support.

Collaboration with the draft authors is also highly suggested.

* ''Required Experience:'' Fundamentals of IPv6 addressing, C++ programming.
* ''Bonus Experience:'' Familiarity with AODV implementations in ns-3 and AODVv2
* ''Interests:'' Ad hoc routing
* ''Difficulty:'' Medium.
* ''Recommended reading:''
** [https://www.nsnam.org/docs/models/html/ipv6.html IPv6 model in ns-3]
** [https://www.nsnam.org/docs/models/html/aodv.html AODV model in ns-3]
** [https://gitlab.com/tod97/ns-3-dev/-/tree/aodvv2-icns3-25 AODVv2 model presented at ICNS3-2025]
** [https://datatracker.ietf.org/doc/draft-perkins-manet-aodvv2/05/ Ad Hoc On-demand Distance Vector Version 2 (AODVv2) Routing]

Possible tasks to fulfill the patch requirement:
* [https://gitlab.com/nsnam/ns-3-dev/-/issues/368 Issue #368] - aodv: aodv parameters can be set to "impossible" values

== Large projects (350 hours) ==

=== Mesh Link Establishment (MLE) protocol ===

Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], [mailto:alramonet@is.tokushima-u.ac.jp Alberto Gallegos Ramonet].

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:''
** [https://datatracker.ietf.org/doc/html/draft-ietf-6lo-mesh-link-establishment MLE draft]
** [https://openthread.io/guides/thread-primer/network-discovery Thread primer]
** [https://www.threadgroup.org/ThreadSpec Thread specifications]

Possible tasks to fulfill the patch requirement:
* TBD, contact the mentors if interested.

=== 5G NR module integration with ns-3-ai ===

Mentors: [mailto:kkoutlia@cttc.es Katerina Koutlia], [mailto:gcarvalho@cttc.es Gabriel Ferreira], [mailto:aashtari@cttc.es Amir Ashtari Gargari] and [mailto:bbojovic@cttc.es Biljana Bojovic]

The objective of this project is to integrate the ns-3 5G NR module with [https://apps.nsnam.org/app/ns3-ai/ ns-3-ai]. In GSoC 2024 we had a project in which 5G NR was integrated with [https://www.nsnam.org/wiki/GSOC2024RLUsability5G ns-3 gym]. While ns-3 gym is a popular ns-3 module for AI, it is limited to the application of reinforcement learning techniques in networking research. On the other hand, ns-3-ai module provides a more general solution that enables the data interaction between ns-3 and other Python-based AI frameworks, like [https://www.tensorflow.org/api_docs/cc Tensorflow C++ APIs] and [https://pytorch.org/cppdocs/ PyTorch C++ APIs], which opens the door to use different machine learning-based techniques in 5G NR models. The correct functioning of the integration should be tested, and documented, and a fully working example using ns-3-ai should be provided. The contributor can propose a use-case scenario for matching learning. One option is to use it for MAC scheduling, but it could be used for other 5G related research problems, and the contributor is encouraged to propose the use case of his/her interest.

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.
* 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.

=== Linux-like CAKE queue discipline for ns-3 ===

Mentors: [mailto:tahiliani.nitk@gmail.com Mohit P. Tahiliani]

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.

* ''Required Experience:'' Familiarity with queue disciplines, TCP and C++ programming.
* ''Bonus Experience:'' Familiarity with CAKE framework in Linux 4.19
* ''Interests:'' Active Queue Management, Packet scheduling and TCP.
* ''Difficulty:'' Medium to Hard
* ''Recommended reading:''
** [https://arxiv.org/pdf/1804.07617.pdf Piece of CAKE: A Comprehensive Queue Management Solution for Home Gateways]
** [https://lwn.net/Articles/758353/ Let them run CAKE]
** [https://www.nsnam.org/docs/models/html/queue-discs.html Queue disciplines in ns-3]

=== Switched Ethernet ===

Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], TBD.

The current ns-3 models for wired connections are fine for simple networks, but the lack of a switched Ethernet model is a limitation in some cases.

The goal of the idea is to create, test, and document a Switched Ethernet model, able to simulate (at least) 1, 10, and 40 GbE links and model for a switch.

The model of the NetDevice and Channel shall take into account the link delays and errors, similarly to what is done by the point-to-point model. Futhermore, it should be able to set the link speed and if it is full-duplex or half-duplex. Additional support for flow control is a bonus, but not strictly required. Link speed auto-negotiation is not considered to be interesting.

The model for the switch should be modular (i.e., allowing the development of different switch types), and include auto-learning of I/O ports based on the MAC address, i.e., have a MAC/port table, and a basic store-and-forward operation. Features like advanced I/O buffer handling and ARP/NDP spoofing detection are not a priority and shall be left for future implementations.

The model should consider the future implementaion of algorithms like VLANs (IEEE 802.1Q, 802.1ad), and the Spanning Tree Protocol (IEEE 802.1D, 802.1w, and 802.1s). Their implementaion is not required, but the model design should allow their development.

* ''Required Experience:'' Fundamentals of Ethernet sitched networking, C++ programming.
* ''Interests:'' Ethernet networks and switched data networks.
* ''Difficulty:'' Medium.
* ''Recommended reading:''
** [https://www2.nsnam.org/bugzilla/show_bug.cgi?id=2602 Basic implementation (very old)]
** [https://gitlab.com/nsnam/ns-3-dev/-/merge_requests/431 Full-duplex CSMA, somehow related]
** [https://tcipg.org/sites/default/files/papers/2010_Jin_Nicol_Caesar.pdf Paper on gigabit Ethernet switch models for simulation]

Possible tasks to fulfill the patch requirement:
* TBD, contact the mentors if interested.

GSOC2026Projects

2026-02-04T16:31:33Z

Biljana: /* Medium sized projects (175 hours) */

{{TOC}}

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

* [https://developers.google.com/open-source/gsoc/faq GSoC Frequently Asked Questions]
* [[GSOC2026ContributorGuide | ns-3's 2026 GSoC Contributor guide]]
* [https://developers.google.com/open-source/gsoc/resources/guide GSoC contributor/student guide (not ns-3 specific)]
* [[GSOC2025ApplicationTemplate | 2026 GSoC Contributor application template]]
* [[GSOCMentorGuide | ns-3's GSoC Mentor guide]]
* [https://archive.flossmanuals.net/gsocmentoring/index.html GSoC Mentor guide (not ns-3 specific)]
* [[GSOCSelectionProcess | GSoC Contributor Selection Process]]
* ''Get in contact with the ns-3 team'': [https://groups.google.com/g/ns-developers 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-25. 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 [mailto:tpecorella@mac.com Tommaso Pecorella] and [mailto:tahiliani.nitk@gmail.com Mohit P. Tahiliani]; contact them with any questions. They also hang out on [https://ns-3.zulipchat.com 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 [https://developers.google.com/open-source/gsoc/resources/guide GSoC contributor guide].
* Read [[GSOC2026ContributorGuide |ns-3's 2026 GSoC contributor guide]]
* 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.
* Once it is posted, look through the [[GSOC2024ApplicationTemplate |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 2026, 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 2026. 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 suggests 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>
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.
</blockquote>

=== Patch requirement guidelines ===

In past years, we have asked applicants to submit a patch related to an open issue or a suggested coding exercise. We are undecided at this time whether we will ask for this in 2026; check back later.

=== 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 ===

* [[#AODVv2 Protocol enhancements]] (medium size project, 175h)
* [[#Linux-like CAKE queue discipline for ns-3]] (large size project, 350h)
* [[#Switched Ethernet]] (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)

=== 5G NR models enhancements ===

The general idea is to improve the usability of the 5G NR module by adding new examples that help users start building scenario scripts. Also, an interesting improvement could be integration with other modules, like those for AI or visualizations. Here are some project ideas. Depending on the contributor's interest and skills we can adjust these projects' definitions.

* [[#OLLA Link Adaptation and Spec-Compliant TBS Calculation for 5G-LENA]](medium size project, 175h)
* [[#Energy Consumption Modeling and Power-Aware Extensions for 5G-LENA]](medium size project, 175h)
* [[#Enabling 5G NR examples visualization]] (medium size project, 175h)
* [[#5G NR module integration with ns-3-ai]] (large size project, 250h)

== Small sized projects (90 hours) ==

== Medium sized projects (175 hours) ==

=== 6LoWPAN mesh-under routing enhancements ===

Mentors: [mailto:tommaso.pecorella@unifi.it 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.
Better approaches are possible, e.g., by leveraging some concepts from RFC 7731, by using SNR as a guidance, or by measuring the local network activity.

The candidate should outline the proposed approach, what parts of code are going to be affected, and how they can be enhanced.

* ''Required Experience:'' Fundamentals of IPv6 addressing, C++ programming.
* ''Bonus Experience:'' Familiarity with mesh routing and 6LoWPAN ns-3
* ''Interests:'' IPv6 mesh routing
* ''Difficulty:'' Easy.
* ''Recommended reading:''
** [https://www.nsnam.org/docs/models/html/sixlowpan.html#mesh-under-routing Mesh-under in ns-3 6LoWPAN]
** [https://datatracker.ietf.org/doc/html/rfc7731 RFC 7731]
** [https://meshtastic.org/docs/overview/mesh-algo/ Meshtastic controlled flooding]
** [https://ieeexplore.ieee.org/document/91339 Routing by controlled flooding in communication networks] (if the document can not be accessed, PM the mentors)

Possible tasks to fulfill the patch requirement:
* The current code is hardwired, i.e., the mesh-under routing scheme is embedded into the SixLowPanNetDevice. Propose a patch to decouple it, using a SixLowPanMeshUnderRouting class to determine the "next hop". The behavior of the actual protocol should be unchanged.

=== 6LoWPAN neighbor discovery protocol ===

Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], [mailto:adnan.rashid@poliba.it Adnan Rashid].

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 help merging the code (if it's not already merged) and add some features that are not yet considered in the model.

The candidate should outline in the proposal the features that are planned to be added, and a code mockup (or a complete class diagram) for said features.

* ''Required Experience:'' Fundamentals of IPv6 addressing, C++ programming.
* ''Bonus Experience:'' Familiarity with 6LoWPAN and 6LoWPAN-ND
* ''Interests:'' IPv6 and IoT networks
* ''Difficulty:'' Easy.
* ''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]
** https://gitlab.com/jieqiboh5836/ns-3-dev/-/tree/6LoWPAN-ND-P1
** https://gitlab.com/jieqiboh5836/ns-3-dev/-/tree/6LoWPAN-ND-P2

===OLLA Link Adaptation and Spec-Compliant TBS Calculation for 5G-LENA===

Mentors: [mailto:slagen@cttc.es Sandra Lagen], [mailto:bbojovic@cttc.es Biljana Bojovic], [mailto:gcarvalho@cttc.es Gabriel Ferreira], [mailto:kkoutlia@cttc.es Katerina Koutlia]

This project would focus on improving the realism and correctness of the CTTC 5G-LENA (NR module) by implementing Outer Loop Link Adaptation (OLLA) in the scheduling/link adaptation workflow, and by improving the Transport Block Size (TBS) calculation to be aligned with the 5G NR specification. OLLA is commonly used to track a target BLER by updating an SINR (or CQI) offset based on HARQ ACK/NACK feedback, leading to more stable and realistic link adaptation behavior.
In addition, the project would include a performance evaluation comparing the new OLLA-enabled behavior against the current baseline and across multiple existing NR schedulers. The evaluation should consider throughput, latency, achieved BLER, convergence behavior, and fairness.

For starters, we would suggest adding the CTTC 5G-LENA (nr module) to ns-3 (as a module in the contrib/ directory), building and running the NR examples, and becoming familiar with the current scheduler, HARQ feedback flow, CQI/MCS selection, and TBS computation. 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.

*Required Experience: C++ programming, understanding of 5G NR MAC concepts (scheduling, CQI/MCS, HARQ), wireless networking fundamentals
*Interests: 5G NR simulations, scheduling, link adaptation, performance evaluation
*Difficulty: Medium
*Project size: 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.

===Energy Consumption Modeling and Power-Aware Extensions for 5G-LENA===

Mentors: Katerina Koutlia, Biljana Bojovic and Amir Ashtari.

This project would add energy consumption modeling to the CTTC 5G-LENA (NR module). While 5G-LENA provides a detailed and validated simulation of the 5G NR protocol stack behavior, it currently lacks energy models for UEs and/or gNBs, limiting research on energy efficiency, green networking, 6G sustainability, and potentially AI-driven power-aware control.
The project would first evaluate reuse of the ns-3 Energy Framework (e.g., EnergySource, DeviceEnergyModel) by defining a clean interface between 5G-LENA and the energy module. If existing models are insufficient, the project would design and implement a 5G-specific device energy model (e.g., NrDeviceEnergyModel) and connect it to relevant 5G-LENA state/procedure events.
For starters, we would suggest adding the CTTC 5G-LENA (nr module) to ns-3 (as a module in the contrib/ directory), building and running the NR examples, and studying the Energy Framework integration patterns. Documentation is available here: https://5g-lena.cttc.es/. Tutorial video: https://acmse.net/2021/tutorials-offered/#tut-work03.

Scope (expected deliverables):
*Energy consumption accounting for UEs and/or gNBs
*Per-state (and if feasible per-procedure) modeling, e.g.
**gNB: idle/active/sleep, TX/RX, processing; dependence on bandwidth/PRBs, TX power, MIMO layers/streams/RF chains, load
**UE: TX/RX, measurements, CSI-RS/SRS activity, beamforming-related processing, handover
*Tracing, example(s), and documentation

Optional (time permitting): a simple energy-aware scheduling extension to explore QoS trade-offs (e.g., energy-per-bit or energy-aware MIMO under GBR)

*Required Experience: C++ programming, wireless networking fundamentals (energy/state-machine modeling is a plus)
*Interests: 5G NR simulations, energy efficiency, green networking, 6G sustainability
*Difficulty: Medium
*Project size: 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.

=== Improving 5G NR module usability through helpers ===

Mentors: [mailto:bbojovic@cttc.es Biljana Bojovic],[mailto:gcarvalho@cttc.es Gabriel Ferreira], [mailto:kkoutlia@cttc.es Katerina Koutlia] and [mailto:aashtari@cttc.es Amir Ashtari Gargari]

This project would be focused on improving the usability of the 5G nr module by enabling new helper support. The new helpers should allow for simplifying the setup of NR applications, XR applications, scenarios, the management of the configuration of many parameters of the scenario, etc. All the NR examples should be updated to make use of these new helpers. The use of such helpers would help reduce significantly the code duplication in 5G NR examples.

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.

* 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]. 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.

=== Enabling 5G NR examples visualization ===

Mentors: [mailto:aashtari@cttc.es Amir Ashtari Gargari], [mailto:gcarvalho@cttc.es Gabriel Ferreira], [mailto:bbojovic@cttc.es Biljana Bojovic] and [mailto:kkoutlia@cttc.es Katerina Koutlia]

The main idea of this project is to allow easier visualization of 5G NR examples by integrating the NR module with some ns-3 visualization tools like NetAnim, or by implementing a kind of web-based visualization, e.g., through Jupyter notebook. The new feature should allow the visualization of already existing traces, visualization of topology, or even some new relevant simulation aspects could be considered. The idea is that users better understand how the metrics collection works, and how changing parameters can affect simulation results. In this project, we are open to other ideas on how to implement visualizations.

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.

=== AODVv2 Protocol enhancements ===

Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], [TBD].

ns-3 contains models for proactive (DSDV and OLSR) and reactive (AODV and DSR) ad hoc routing protocols. AODVv2 is currently an IETF draft, and its implementation in ns-3 is ongoing. This project aims at enhancing the AODVv2 model for ns-3.

In particular the project should address the following points:
# Alignment with the latest drafts,
# Model finalization and testing (in particular for the IPv6 part),
# AODVv2 examples and documentation,
# "External" network routing support.

Collaboration with the draft authors is also highly suggested.

* ''Required Experience:'' Fundamentals of IPv6 addressing, C++ programming.
* ''Bonus Experience:'' Familiarity with AODV implementations in ns-3 and AODVv2
* ''Interests:'' Ad hoc routing
* ''Difficulty:'' Medium.
* ''Recommended reading:''
** [https://www.nsnam.org/docs/models/html/ipv6.html IPv6 model in ns-3]
** [https://www.nsnam.org/docs/models/html/aodv.html AODV model in ns-3]
** [https://gitlab.com/tod97/ns-3-dev/-/tree/aodvv2-icns3-25 AODVv2 model presented at ICNS3-2025]
** [https://datatracker.ietf.org/doc/draft-perkins-manet-aodvv2/05/ Ad Hoc On-demand Distance Vector Version 2 (AODVv2) Routing]

Possible tasks to fulfill the patch requirement:
* [https://gitlab.com/nsnam/ns-3-dev/-/issues/368 Issue #368] - aodv: aodv parameters can be set to "impossible" values

== Large projects (350 hours) ==

=== Mesh Link Establishment (MLE) protocol ===

Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], [mailto:alramonet@is.tokushima-u.ac.jp Alberto Gallegos Ramonet].

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:''
** [https://datatracker.ietf.org/doc/html/draft-ietf-6lo-mesh-link-establishment MLE draft]
** [https://openthread.io/guides/thread-primer/network-discovery Thread primer]
** [https://www.threadgroup.org/ThreadSpec Thread specifications]

Possible tasks to fulfill the patch requirement:
* TBD, contact the mentors if interested.

=== 5G NR module integration with ns-3-ai ===

Mentors: [mailto:kkoutlia@cttc.es Katerina Koutlia], [mailto:gcarvalho@cttc.es Gabriel Ferreira], [mailto:aashtari@cttc.es Amir Ashtari Gargari] and [mailto:bbojovic@cttc.es Biljana Bojovic]

The objective of this project is to integrate the ns-3 5G NR module with [https://apps.nsnam.org/app/ns3-ai/ ns-3-ai]. In GSoC 2024 we had a project in which 5G NR was integrated with [https://www.nsnam.org/wiki/GSOC2024RLUsability5G ns-3 gym]. While ns-3 gym is a popular ns-3 module for AI, it is limited to the application of reinforcement learning techniques in networking research. On the other hand, ns-3-ai module provides a more general solution that enables the data interaction between ns-3 and other Python-based AI frameworks, like [https://www.tensorflow.org/api_docs/cc Tensorflow C++ APIs] and [https://pytorch.org/cppdocs/ PyTorch C++ APIs], which opens the door to use different machine learning-based techniques in 5G NR models. The correct functioning of the integration should be tested, and documented, and a fully working example using ns-3-ai should be provided. The contributor can propose a use-case scenario for matching learning. One option is to use it for MAC scheduling, but it could be used for other 5G related research problems, and the contributor is encouraged to propose the use case of his/her interest.

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.
* 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.

=== Linux-like CAKE queue discipline for ns-3 ===

Mentors: [mailto:tahiliani.nitk@gmail.com Mohit P. Tahiliani]

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.

* ''Required Experience:'' Familiarity with queue disciplines, TCP and C++ programming.
* ''Bonus Experience:'' Familiarity with CAKE framework in Linux 4.19
* ''Interests:'' Active Queue Management, Packet scheduling and TCP.
* ''Difficulty:'' Medium to Hard
* ''Recommended reading:''
** [https://arxiv.org/pdf/1804.07617.pdf Piece of CAKE: A Comprehensive Queue Management Solution for Home Gateways]
** [https://lwn.net/Articles/758353/ Let them run CAKE]
** [https://www.nsnam.org/docs/models/html/queue-discs.html Queue disciplines in ns-3]

=== Switched Ethernet ===

Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], TBD.

The current ns-3 models for wired connections are fine for simple networks, but the lack of a switched Ethernet model is a limitation in some cases.

The goal of the idea is to create, test, and document a Switched Ethernet model, able to simulate (at least) 1, 10, and 40 GbE links and model for a switch.

The model of the NetDevice and Channel shall take into account the link delays and errors, similarly to what is done by the point-to-point model. Futhermore, it should be able to set the link speed and if it is full-duplex or half-duplex. Additional support for flow control is a bonus, but not strictly required. Link speed auto-negotiation is not considered to be interesting.

The model for the switch should be modular (i.e., allowing the development of different switch types), and include auto-learning of I/O ports based on the MAC address, i.e., have a MAC/port table, and a basic store-and-forward operation. Features like advanced I/O buffer handling and ARP/NDP spoofing detection are not a priority and shall be left for future implementations.

The model should consider the future implementaion of algorithms like VLANs (IEEE 802.1Q, 802.1ad), and the Spanning Tree Protocol (IEEE 802.1D, 802.1w, and 802.1s). Their implementaion is not required, but the model design should allow their development.

* ''Required Experience:'' Fundamentals of Ethernet sitched networking, C++ programming.
* ''Interests:'' Ethernet networks and switched data networks.
* ''Difficulty:'' Medium.
* ''Recommended reading:''
** [https://www2.nsnam.org/bugzilla/show_bug.cgi?id=2602 Basic implementation (very old)]
** [https://gitlab.com/nsnam/ns-3-dev/-/merge_requests/431 Full-duplex CSMA, somehow related]
** [https://tcipg.org/sites/default/files/papers/2010_Jin_Nicol_Caesar.pdf Paper on gigabit Ethernet switch models for simulation]

Possible tasks to fulfill the patch requirement:
* TBD, contact the mentors if interested.

GSOC2026Projects

2026-02-04T16:27:48Z

Biljana: /* Medium sized projects (175 hours) */

GSOC2026Projects

2026-02-04T16:27:05Z

Biljana: /* Medium sized projects (175 hours) */

GSOC2026Projects

2026-02-04T16:26:41Z

Biljana: /* OLLA Link Adaptation and Spec-Compliant TBS Calculation for 5G-LENA */

GSOC2026Projects

2026-02-04T16:26:22Z

Biljana: /* OLLA Link Adaptation and Spec-Compliant TBS Calculation for 5G-LENA= */

GSOC2026Projects

2026-02-04T16:26:01Z

Biljana: /* Medium sized projects (175 hours) */

GSOC2026Projects

2026-02-04T08:58:26Z

Biljana:

GSOC2025Projects

2025-03-07T14:45:32Z

Biljana: /* 5G NR module integration with ns-3-ai */

{{TOC}}

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

* [https://developers.google.com/open-source/gsoc/faq GSoC Frequently Asked Questions]
* [[GSOC2025ContributorGuide | ns-3's 2025 GSoC Contributor guide]]
* [https://developers.google.com/open-source/gsoc/resources/guide GSoC contributor/student guide (not ns-3 specific)]
* [[GSOC2025ApplicationTemplate | 2025 GSoC Contributor application template]]
* [[GSOCMentorGuide | ns-3's GSoC Mentor guide]]
* [https://archive.flossmanuals.net/gsocmentoring/index.html GSoC Mentor guide (not ns-3 specific)]
* [[GSOCSelectionProcess | GSoC Contributor Selection Process]]
* ''Get in contact with the ns-3 team'': [https://groups.google.com/g/ns-developers 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-24. 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 [mailto:tpecorella@mac.com Tommaso Pecorella] and [mailto:tahiliani.nitk@gmail.com Mohit P. Tahiliani]; contact them with any questions. They also hang out on [https://ns-3.zulipchat.com 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 [https://developers.google.com/open-source/gsoc/resources/guide GSoC contributor guide].
* Read [[GSOC2025ContributorGuide |ns-3's 2025 GSoC contributor guide]]
* 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.
* Once it is posted, look through the [[GSOC2024ApplicationTemplate |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 2025, 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 2025. 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 suggests 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>
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.
</blockquote>

=== Patch requirement guidelines ===

In past years, we have asked applicants to submit a patch related to an open issue or a suggested coding exercise. We are undecided at this time whether we will ask for this in 2025; check back later.

=== 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 ===

* [[#Upgrade the AQM Evaluation Suite for ns-3]] (small size project, 90h)
* [[#Implementation of Alternative Backoff with ECN (ABE)]] (small size project, 90h)
* [[#ICMP socket and generate/handle ICMP messages (host/net unreachable)]] (medium size project, 175h)
* [[#Linux-like Loss Detection Techniques for ns-3 TCP]] (medium size project, 175h)
* [[#AODVv2 Protocol enhancements]] (medium size project, 175h)
* [[#IPv6 global routing]] (large size project, 350h)
* [[#Linux-like CAKE queue discipline for ns-3]] (large size project, 350h)
* [[#Switched Ethernet]] (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 ===

The general idea is to improve the usability of the 5G NR module by adding new examples that help users start building scenario scripts, such as an example for the NTN use case. Another way is to create new helpers that simplify the creation of new simulation scripts. Also, an interesting improvement could be integration with other modules, like those for AI or visualizations. Here are some project ideas. Depending on the contributor's interest and skills we can adjust these projects' definitions.

* [[#NTN example for 5G NR]] (small size project, 90h)
* [[#Enabling 5G NR examples visualization]] (medium size project, 175h)
* [[#Improving 5G NR module usability through helpers]] (medium size project, 175h)
* [[#5G NR module integration with ns-3-ai]] (large size project, 250h)

== Small sized projects (90 hours) ==

=== NTN example for 5G NR ===

Mentors: [mailto:gcarvalho@cttc.es Gabriel Ferreira], [mailto:aashtari@cttc.es Amir Ashtari Gargari], [mailto:bbojovic@cttc.es Biljana Bojovic] and [mailto:kkoutlia@cttc.es Katerina Koutlia]

The objective of this project is the creation of a 5G NR example for the NTN use case. The example should provide a typical NTN topology, with a set of cells served by Low-Earth Orbit (LEO) satellites (e.g. Starlink, Kuiper), hence maybe an NTN topology helper could be created as a part of this project. The example should use the ns-3 3GPP NTN channel model. If handover is already functional, satellites should move at orbital speeds in their orbital planes, handing off users to the upcoming cell with LOS. We could explore scenarios (dense urban and urban).

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.

* 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]. 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.

=== Upgrade the AQM Evaluation Suite for ns-3 ===

Mentors: [mailto:tahiliani.nitk@gmail.com Mohit P. Tahiliani]

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 few years, the traffic control model in ns-3 has grown significantly in terms of supporting state-of-the-art packet scheduling and AQM algorithms, and the ns-3 build system has changed from waf to cmake. 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.

* ''Required Experience:'' Familiarity with AQM and C++ programming.
* ''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.

=== Implementation of Alternative Backoff with ECN (ABE) ===

Mentors: [mailto:tahiliani.nitk@gmail.com Mohit P. Tahiliani]

Alternative Backoff with ECN (ABE) is a newly proposed feature to enhance the performance of TCP when ECN is deployed. The main idea of ABE is to make the TCP sender respond differently to an ECN signal than it does for a packet loss. This project intends to implement, test and document this feature in ns-3. Additonally, an example program must be developed to demonstrate the usage of ABE in ns-3.

* ''Required Experience:'' Familiarity with ECN and C++ programming.
* ''Bonus Experience:'' Familiarity with traffic control model in ns-3.
* ''Interests:'' Packet Scheduling algorithms, AQM algorithms and ECN.
* ''Difficulty:'' Medium.
* ''Recommended Reading:''
** Alternative Backoff with ECN [[https://datatracker.ietf.org/doc/rfc8511 RFC 8511]] [[http://heim.ifi.uio.no/~naeemk/research/ABE/Networking2017ABE.pdf Paper]]
** [https://www.nsnam.org/docs/models/html/tcp.html#support-for-explicit-congestion-notification-ecn ECN support in ns-3]
** [https://www.nsnam.org/docs/models/html/traffic-control-layer.html Traffic Control Model in ns-3]

== 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].

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:''
** [https://man7.org/linux/man-pages/man2/socket.2.html Linux socket]
** [https://courses.cs.vt.edu/cs4254/fall04/slides/raw_1.pdf Raw Sockets and ICMP, Srinidhi Varadarajan]
** [https://gitlab.com/nsnam/ns-3-dev/-/issues/810 Issue #810]

Possible tasks to fulfill the patch requirement:
* Submit a patch to fix [https://gitlab.com/nsnam/ns-3-dev/-/issues/809 Issue #809]

=== 6LoWPAN mesh-under routing enhancements ===

Mentors: [mailto:tommaso.pecorella@unifi.it 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.
* ''Recommended reading:''
** [https://www.nsnam.org/docs/models/html/sixlowpan.html#mesh-under-routing Mesh-under in ns-3 6LoWPAN]
** [https://datatracker.ietf.org/doc/html/rfc7731 RFC 7731]

Possible tasks to fulfill the patch requirement:
* TBD

=== 6LoWPAN neighbor discovery protocol ===

Mentors: [mailto:tommaso.pecorella@unifi.it 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.
* ''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]

Possible tasks to fulfil the patch requirement:
* Patch the actual 6LoWPAN-ND to remove the limitation about concurrent address registrations.

=== Improving 5G NR module usability through helpers ===

Mentors: [mailto:bbojovic@cttc.es Biljana Bojovic],[mailto:gcarvalho@cttc.es Gabriel Ferreira], [mailto:kkoutlia@cttc.es Katerina Koutlia] and [mailto:aashtari@cttc.es Amir Ashtari Gargari]

This project would be focused on improving the usability of the 5G nr module by enabling new helper support. The new helpers should allow for simplifying the setup of NR applications, XR applications, scenarios, the management of the configuration of many parameters of the scenario, etc. All the NR examples should be updated to make use of these new helpers. The use of such helpers would help reduce significantly the code duplication in 5G NR examples.

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.

* 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]. 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.

=== Enabling 5G NR examples visualization ===

Mentors: [mailto:aashtari@cttc.es Amir Ashtari Gargari], [mailto:gcarvalho@cttc.es Gabriel Ferreira], [mailto:bbojovic@cttc.es Biljana Bojovic] and [mailto:kkoutlia@cttc.es Katerina Koutlia]

The main idea of this project is to allow easier visualization of 5G NR examples by integrating the NR module with some ns-3 visualization tools like NetAnim, or by implementing a kind of web-based visualization, e.g., through Jupyter notebook. The new feature should allow the visualization of already existing traces, visualization of topology, or even some new relevant simulation aspects could be considered. The idea is that users better understand how the metrics collection works, and how changing parameters can affect simulation results. In this project, we are open to other ideas on how to implement visualizations.

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.

=== Linux-like Loss Detection Techniques for ns-3 TCP ===

Mentors: [mailto:tahiliani.nitk@gmail.com Mohit P. Tahiliani]

Forward Acknowledgement (FACK), Duplicate Selective Acknowledgement (DSACK), and Recent Acknowledgement (RACK) Tail Loss Probe (TLP) 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.

* ''Required Experience:'' Familiarity with TCP and C++ programming.
* ''Bonus Experience:'' Familiarity with TCP implementation in Linux kernel.
* ''Interests:'' TCP packet loss detection techniques.
* ''Difficulty:'' Medium to Hard.
* ''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]]
** RACK-TLP [[https://datatracker.ietf.org/doc/html/rfc8985 RFC 8985]] [[https://gitlab.com/nsnam/ns-3-dev/-/merge_requests/34/commits Implementation]]

=== AODVv2 Protocol enhancements ===

Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], [TBD].

ns-3 contains models for proactive (DSDV and OLSR) and reactive (AODV and DSR) ad hoc routing protocols. AODVv2 is currently an IETF draft, and its implementation in ns-3 is ongoing. This project aims at enhancing the AODVv2 model for ns-3.

In particular the project should address the following points: 1) AODVv2 performances, 2) AODV address compression, 3) "external" network routing support, 4) general model validation against the latest draft.
Collaboration with the draft authors is also highly suggested.

* ''Required Experience:'' Fundamentals of IPv6 addressing, C++ programming.
* ''Bonus Experience:'' Familiarity with AODV implementations in ns-3 and AODVv2
* ''Interests:'' Ad hoc routing
* ''Difficulty:'' Medium.
* ''Recommended reading:''
** [https://www.nsnam.org/docs/models/html/ipv6.html IPv6 model in ns-3]
** [https://www.nsnam.org/docs/models/html/aodv.html AODV model in ns-3]
** [https://datatracker.ietf.org/doc/draft-perkins-manet-aodvv2/05/ Ad Hoc On-demand Distance Vector Version 2 (AODVv2) Routing]

Possible tasks to fulfill the patch requirement:
* [https://gitlab.com/nsnam/ns-3-dev/-/issues/368 Issue #368] - aodv: aodv parameters can be set to "impossible" values

== Large projects (350 hours) ==

=== IPv6 global routing ===

Mentors: [mailto:tommaso.pecorella@unifi.it 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.
* ''Recommended reading:''
** [https://www.nsnam.org/docs/models/html/ipv6.html IPv6 model in ns-3]
** [https://www.nsnam.org/docs/models/html/routing-overview.html#global-centralized-routing GlobalRouting model in ns-3]

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.

=== Mesh Link Establishment (MLE) protocol ===

Mentors: [mailto:tommaso.pecorella@unifi.it 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:''
** [https://datatracker.ietf.org/doc/html/draft-ietf-6lo-mesh-link-establishment MLE draft]
** [https://openthread.io/guides/thread-primer/network-discovery Thread primer]
** [https://www.threadgroup.org/ThreadSpec Thread specifications]

Possible tasks to fulfill the patch requirement:
* TBD, contact the mentors if interested.

=== Lr-WPAN (IEEE 802.15.4) preamble detection support ===

Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], [mailto:alramonet@is.tokushima-u.ac.jp 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.
* ''Recommended reading:''
** [https://ieeexplore.ieee.org/document/1700009 IEEE 802.15.4-2006]
** [https://ieeexplore.ieee.org/document/7460875 IEEE 802.15.4-2015]
** [https://www.nsnam.org/docs/models/html/lr-wpan.html ns-3 lr-wpan module]

Possible tasks to fulfill the patch requirement:
* TBD, contact the mentors if interested.

=== 5G NR module integration with ns-3-ai ===

Mentors: [mailto:kkoutlia@cttc.es Katerina Koutlia], [mailto:gcarvalho@cttc.es Gabriel Ferreira], [mailto:aashtari@cttc.es Amir Ashtari Gargari] and [mailto:bbojovic@cttc.es Biljana Bojovic]

The objective of this project is to integrate the ns-3 5G NR module with [https://apps.nsnam.org/app/ns3-ai/ ns-3-ai]. In GSoC 2024 we had a project in which 5G NR was integrated with [https://www.nsnam.org/wiki/GSOC2024RLUsability5G ns-3 gym]. While ns-3 gym is a popular ns-3 module for AI, it is limited to the application of reinforcement learning techniques in networking research. On the other hand, ns-3-ai module provides a more general solution that enables the data interaction between ns-3 and other Python-based AI frameworks, like [https://www.tensorflow.org/api_docs/cc Tensorflow C++ APIs] and [https://pytorch.org/cppdocs/ PyTorch C++ APIs], which opens the door to use different machine learning-based techniques in 5G NR models. The correct functioning of the integration should be tested, and documented, and a fully working example using ns-3-ai should be provided. The contributor can propose a use-case scenario for matching learning. One option is to use it for MAC scheduling, but it could be used for other 5G related research problems, and the contributor is encouraged to propose the use case of his/her interest.

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.
* 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.

=== Linux-like CAKE queue discipline for ns-3 ===

Mentors: [mailto:tahiliani.nitk@gmail.com Mohit P. Tahiliani]

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.

* ''Required Experience:'' Familiarity with queue disciplines, TCP and C++ programming.
* ''Bonus Experience:'' Familiarity with CAKE framework in Linux 4.19
* ''Interests:'' Active Queue Management, Packet scheduling and TCP.
* ''Difficulty:'' Medium to Hard
* ''Recommended reading:''
** [https://arxiv.org/pdf/1804.07617.pdf Piece of CAKE: A Comprehensive Queue Management Solution for Home Gateways]
** [https://lwn.net/Articles/758353/ Let them run CAKE]
** [https://www.nsnam.org/docs/models/html/queue-discs.html Queue disciplines in ns-3]

=== Switched Ethernet ===

Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], TBD.

The current ns-3 models for wired connections are fine for simple networks, but the lack of a switched Ethernet model is a limitation in some cases.

The goal of the idea is to create, test, and document a Switched Ethernet model, able to simulate (at least) 1, 10, and 40 GbE links and model for a switch.

The model of the NetDevice and Channel shall take into account the link delays and errors, similarly to what is done by the point-to-point model. Futhermore, it should be able to set the link speed and if it is full-duplex or half-duplex. Additional support for flow control is a bonus, but not strictly required. Link speed auto-negotiation is not considered to be interesting.

The model for the switch should be modular (i.e., allowing the development of different switch types), and include auto-learning of I/O ports based on the MAC address, i.e., have a MAC/port table, and a basic store-and-forward operation. Features like advanced I/O buffer handling and ARP/NDP spoofing detection are not a priority and shall be left for future implementations.

The model should consider the future implementaion of algorithms like VLANs (IEEE 802.1Q, 802.1ad), and the Spanning Tree Protocol (IEEE 802.1D, 802.1w, and 802.1s). Their implementaion is not required, but the model design should allow their development.

* ''Required Experience:'' Fundamentals of Ethernet sitched networking, C++ programming.
* ''Interests:'' Ethernet networks and switched data networks.
* ''Difficulty:'' Medium.
* ''Recommended reading:''
** [https://www2.nsnam.org/bugzilla/show_bug.cgi?id=2602 Basic implementation (very old)]
** [https://gitlab.com/nsnam/ns-3-dev/-/merge_requests/431 Full-duplex CSMA, somehow related]
** [https://tcipg.org/sites/default/files/papers/2010_Jin_Nicol_Caesar.pdf Paper on gigabit Ethernet switch models for simulation]

Possible tasks to fulfill the patch requirement:
* TBD, contact the mentors if interested.

GSOC2025Projects

2025-02-11T14:46:29Z

Biljana: /* Improving 5G NR module usability through helpers */

{{TOC}}

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

* [https://developers.google.com/open-source/gsoc/faq GSoC Frequently Asked Questions]
* [[GSOC2024ContributorGuide |ns-3's 2024 GSoC Contributor guide (to be updated for 2025 at a later date)]]
* [https://developers.google.com/open-source/gsoc/resources/guide GSoC contributor/student guide (not ns-3 specific)]
* [[GSOC2024ApplicationTemplate |2024 GSoC Contributor application template (to be updated for 2025 at a later date)]]
* [[GSOCMentorGuide | ns-3's GSoC Mentor guide]]
* [https://archive.flossmanuals.net/gsocmentoring/index.html GSoC Mentor guide (not ns-3 specific)]
* [[GSOCSelectionProcess | GSoC Contributor Selection Process]]
* ''Get in contact with the ns-3 team'': [https://groups.google.com/g/ns-developers 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-24. 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 [mailto:tpecorella@mac.com Tommaso Pecorella] and[mailto:tahiliani.nitk@gmail.com Mohit P. Tahiliani]; contact them with any questions. They also hang out on [https://ns-3.zulipchat.com 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 [https://developers.google.com/open-source/gsoc/resources/guide GSoC contributor guide].
* Read [[GSOC2024ContributorGuide |ns-3's 2024 GSoC contributor guide]]
* 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.
* Once it is posted, look through the [[GSOC2024ApplicationTemplate |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 2025, 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 2025. 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 suggests 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>
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.
</blockquote>

=== Patch requirement guidelines ===

In past years, we have asked applicants to submit a patch related to an open issue or a suggested coding exercise. We are undecided at this time whether we will ask for this in 2025; check back later.

=== 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)
* [[#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 ===

The general idea is to improve the usability of the 5G NR module by adding new examples that help users start building scenario scripts, such as an example for the NTN use case. Another way is to create new helpers that simplify the creation of new simulation scripts. Also, an interesting improvement could be integration with other modules, like those for AI or visualizations. Here are some project ideas. Depending on the contributor's interest and skills we can adjust these projects' definitions.

* [[#NTN example for 5G NR]] (small size project, 90h)
* [[#5G NR module integration with ns-3-ai]] (large size project, 250h)
* [[#Enabling 5G NR examples visualization]] (large size project, 175h)
* [[#Improving 5G NR module usability through helpers]] (medium size project, 175h)

== Small sized projects (90 hours) ==

=== NTN example for 5G NR ===

Mentors: [mailto:gcarvalho@cttc.es Gabriel Ferreira], [mailto:aashtari@cttc.es Amir Ashtari Gargari], [mailto:bbojovic@cttc.es Biljana Bojovic] and [mailto:kkoutlia@cttc.es Katerina Koutlia]

The objective of this project is the creation of a 5G NR example for the NTN use case. The example should provide a typical NTN topology, with a set of cells served by Low-Earth Orbit (LEO) satellites (e.g. Starlink, Kuiper), hence maybe an NTN topology helper could be created as a part of this project. The example should use the ns-3 3GPP NTN channel model. If handover is already functional, satellites should move at orbital speeds in their orbital planes, handing off users to the upcoming cell with LOS. We could explore scenarios (dense urban and urban).

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.

* 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]. 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].

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:''
** [https://man7.org/linux/man-pages/man2/socket.2.html Linux socket]
** [https://courses.cs.vt.edu/cs4254/fall04/slides/raw_1.pdf Raw Sockets and ICMP, Srinidhi Varadarajan]
** [https://gitlab.com/nsnam/ns-3-dev/-/issues/810 Issue #810]

Possible tasks to fulfill the patch requirement:
* [[GSOC2024PatchRequirement]]

=== 6LoWPAN mesh-under routing enhancements ===

Mentors: [mailto:tommaso.pecorella@unifi.it 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:''
** [https://www.nsnam.org/docs/models/html/sixlowpan.html#mesh-under-routing Mesh-under in ns-3 6LoWPAN]
** [https://datatracker.ietf.org/doc/html/rfc7731 RFC 7731]

Possible tasks to fulfill the patch requirement:
* TBD

=== 6LoWPAN neighbor discovery protocol ===

Mentors: [mailto:tommaso.pecorella@unifi.it 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:''
** [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]

Possible tasks to fulfil the patch requirement:
* Patch the actual 6LoWPAN-ND to remove the limitation about concurrent address registrations.

=== Improving 5G NR module usability through helpers ===

Mentors: [mailto:bbojovic@cttc.es Biljana Bojovic],[mailto:gcarvalho@cttc.es Gabriel Ferreira], [mailto:kkoutlia@cttc.es Katerina Koutlia] and [mailto:aashtari@cttc.es Amir Ashtari Gargari]

This project would be focused on improving the usability of the 5G nr module by enabling new helper support. The new helpers should allow for simplifying the setup of NR applications, XR applications, scenarios, the management of the configuration of many parameters of the scenario, etc. All the NR examples should be updated to make use of these new helpers. The use of such helpers would help reduce significantly the code duplication in 5G NR examples.

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.

* 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]. 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.

=== Enabling 5G NR examples visualization ===

Mentors: [mailto:aashtari@cttc.es Amir Ashtari Gargari], [mailto:gcarvalho@cttc.es Gabriel Ferreira], [mailto:bbojovic@cttc.es Biljana Bojovic] and [mailto:kkoutlia@cttc.es Katerina Koutlia]

The main idea of this project is to allow easier visualization of 5G NR examples by integrating the NR module with some ns-3 visualization tools like NetAnim, or by implementing a kind of web-based visualization, e.g., through Jupyter notebook. The new feature should allow the visualization of already existing traces, visualization of topology, or even some new relevant simulation aspects could be considered. The idea is that users better understand how the metrics collection works, and how changing parameters can affect simulation results. In this project, we are open to other ideas on how to implement visualizations.

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.

== Large projects (350 hours) ==

=== IPv6 global routing ===

Mentors: [mailto:tommaso.pecorella@unifi.it 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:''
** [https://www.nsnam.org/docs/models/html/ipv6.html IPv6 model in ns-3]
** [https://www.nsnam.org/docs/models/html/routing-overview.html#global-centralized-routing GlobalRouting model in ns-3]

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.

=== AODVv2 Protocol enhancements ===

Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], [TBD].

ns-3 contains models for proactive (DSDV and OLSR) and reactive (AODV and DSR) ad hoc routing protocols. AODVv2 is currently an IETF draft, and its implementation in ns-3 is ongoing. This project aims at enhancing the AODVv2 model for ns-3.

In particular the project should address the following points: 1) AODVv2 performances, 2) AODV address compression, 3) "external" network routing support, 4) general model validation against the latest draft.
Collaboration with the draft authors is also highly suggested.

* ''Required Experience:'' Fundamentals of IPv6 addressing, C++ programming.
* ''Bonus Experience:'' Familiarity with AODV implementations in ns-3 and AODVv2
* ''Interests:'' Ad hoc routing
* ''Difficulty:'' Medium.
* ''Patch requirement:'' [[GSOC2024PatchRequirement]]
* ''Recommended reading:''
** [https://www.nsnam.org/docs/models/html/ipv6.html IPv6 model in ns-3]
** [https://www.nsnam.org/docs/models/html/aodv.html AODV model in ns-3]
** [https://datatracker.ietf.org/doc/draft-perkins-manet-aodvv2/05/ Ad Hoc On-demand Distance Vector Version 2 (AODVv2) Routing]

Possible tasks to fulfill the patch requirement:
* [https://gitlab.com/nsnam/ns-3-dev/-/issues/368 Issue #368] - aodv: aodv parameters can be set to "impossible" values

=== Mesh Link Establishment (MLE) protocol ===

Mentors: [mailto:tommaso.pecorella@unifi.it 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:''
** [https://datatracker.ietf.org/doc/html/draft-ietf-6lo-mesh-link-establishment MLE draft]
** [https://openthread.io/guides/thread-primer/network-discovery Thread primer]
** [https://www.threadgroup.org/ThreadSpec Thread specifications]

Possible tasks to fulfill the patch requirement:
* [[GSOC2024PatchRequirement]]

=== Lr-WPAN (IEEE 802.15.4) preamble detection support ===

Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], [mailto:alramonet@is.tokushima-u.ac.jp 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:''
** [https://ieeexplore.ieee.org/document/1700009 IEEE 802.15.4-2006]
** [https://ieeexplore.ieee.org/document/7460875 IEEE 802.15.4-2015]
** [https://www.nsnam.org/docs/models/html/lr-wpan.html ns-3 lr-wpan module]

Possible tasks to fulfill the patch requirement:
* [[GSOC2024PatchRequirement]]

=== 5G NR module integration with ns-3-ai ===

Mentors: [mailto:kkoutlia@cttc.es Katerina Koutlia], [mailto:gcarvalho@cttc.es Gabriel Ferreira], [mailto:aashtari@cttc.es Amir Ashtari Gargari] and [mailto:bbojovic@cttc.es Biljana Bojovic]

The objective of this project is to integrate the ns-3 5G NR module with [https://apps.nsnam.org/app/ns3-ai/ ns-3-ai]. In GSoC 2024 we had a project in which 5G NR was integrated with [https://www.nsnam.org/wiki/GSOC2024RLUsability5G ns-3 gym]. While ns-3 gym is a popular ns-3 module for AI, it is limited to the application of reinforcement learning machine learning techniques in networking research. On the other hand, ns-3-ai module provides a more general solution that enables the data interaction between ns-3 and other Python-based AI frameworks, like [https://www.tensorflow.org/api_docs/cc Tensorflow C++ APIs] and [https://pytorch.org/cppdocs/ PyTorch C++ APIs], which opens the door to the use different machine learning-based techniques in 5G NR models. The correct functioning of the integration should be tested, and documented, and a fully working example using ns-3-ai should be provided. The contributor can propose a use-case scenario for matching learning. One option is to use it for MAC scheduling, but it could be used for other research problems, and the contributor is encouraged to propose the use case of his/her interest.

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.
* 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.

GSOC2025Projects

2025-02-11T14:45:27Z

Biljana: /* Improving 5G NR module usability through helpers */

{{TOC}}

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

* [https://developers.google.com/open-source/gsoc/faq GSoC Frequently Asked Questions]
* [[GSOC2024ContributorGuide |ns-3's 2024 GSoC Contributor guide (to be updated for 2025 at a later date)]]
* [https://developers.google.com/open-source/gsoc/resources/guide GSoC contributor/student guide (not ns-3 specific)]
* [[GSOC2024ApplicationTemplate |2024 GSoC Contributor application template (to be updated for 2025 at a later date)]]
* [[GSOCMentorGuide | ns-3's GSoC Mentor guide]]
* [https://archive.flossmanuals.net/gsocmentoring/index.html GSoC Mentor guide (not ns-3 specific)]
* [[GSOCSelectionProcess | GSoC Contributor Selection Process]]
* ''Get in contact with the ns-3 team'': [https://groups.google.com/g/ns-developers 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-24. 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 [mailto:tpecorella@mac.com Tommaso Pecorella] and[mailto:tahiliani.nitk@gmail.com Mohit P. Tahiliani]; contact them with any questions. They also hang out on [https://ns-3.zulipchat.com 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 [https://developers.google.com/open-source/gsoc/resources/guide GSoC contributor guide].
* Read [[GSOC2024ContributorGuide |ns-3's 2024 GSoC contributor guide]]
* 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.
* Once it is posted, look through the [[GSOC2024ApplicationTemplate |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 2025, 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 2025. 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 suggests 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>
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.
</blockquote>

=== Patch requirement guidelines ===

In past years, we have asked applicants to submit a patch related to an open issue or a suggested coding exercise. We are undecided at this time whether we will ask for this in 2025; check back later.

=== 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)
* [[#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 ===

The general idea is to improve the usability of the 5G NR module by adding new examples that help users start building scenario scripts, such as an example for the NTN use case. Another way is to create new helpers that simplify the creation of new simulation scripts. Also, an interesting improvement could be integration with other modules, like those for AI or visualizations. Here are some project ideas. Depending on the contributor's interest and skills we can adjust these projects' definitions.

* [[#NTN example for 5G NR]] (small size project, 90h)
* [[#5G NR module integration with ns-3-ai]] (large size project, 250h)
* [[#Enabling 5G NR examples visualization]] (large size project, 175h)
* [[#Improving 5G NR module usability through helpers]] (medium size project, 175h)

== Small sized projects (90 hours) ==

=== NTN example for 5G NR ===

Mentors: [mailto:gcarvalho@cttc.es Gabriel Ferreira], [mailto:aashtari@cttc.es Amir Ashtari Gargari], [mailto:bbojovic@cttc.es Biljana Bojovic] and [mailto:kkoutlia@cttc.es Katerina Koutlia]

The objective of this project is the creation of a 5G NR example for the NTN use case. The example should provide a typical NTN topology, with a set of cells served by Low-Earth Orbit (LEO) satellites (e.g. Starlink, Kuiper), hence maybe an NTN topology helper could be created as a part of this project. The example should use the ns-3 3GPP NTN channel model. If handover is already functional, satellites should move at orbital speeds in their orbital planes, handing off users to the upcoming cell with LOS. We could explore scenarios (dense urban and urban).

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.

* 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]. 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].

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:''
** [https://man7.org/linux/man-pages/man2/socket.2.html Linux socket]
** [https://courses.cs.vt.edu/cs4254/fall04/slides/raw_1.pdf Raw Sockets and ICMP, Srinidhi Varadarajan]
** [https://gitlab.com/nsnam/ns-3-dev/-/issues/810 Issue #810]

Possible tasks to fulfill the patch requirement:
* [[GSOC2024PatchRequirement]]

=== 6LoWPAN mesh-under routing enhancements ===

Mentors: [mailto:tommaso.pecorella@unifi.it 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:''
** [https://www.nsnam.org/docs/models/html/sixlowpan.html#mesh-under-routing Mesh-under in ns-3 6LoWPAN]
** [https://datatracker.ietf.org/doc/html/rfc7731 RFC 7731]

Possible tasks to fulfill the patch requirement:
* TBD

=== 6LoWPAN neighbor discovery protocol ===

Mentors: [mailto:tommaso.pecorella@unifi.it 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:''
** [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]

Possible tasks to fulfil the patch requirement:
* Patch the actual 6LoWPAN-ND to remove the limitation about concurrent address registrations.

=== Improving 5G NR module usability through helpers ===

Mentors: [mailto:bbojovic@cttc.es Biljana Bojovic],[mailto:gcarvalho@cttc.es Gabriel Ferreira], [mailto:kkoutlia@cttc.es Katerina Koutlia] and [mailto:aashtari@cttc.es Amir Ashtari Gargari]

This project would be focused on improving the usability of the 5G nr module by enabling new helper support. The new helpers should allow for simplifying the setup of NR applications, XR applications, scenarios, the management of the configuration of many parameters of the scenario, etc. All the NR examples should be updated to make use of these new helpers.

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.

* 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]. 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.

=== Enabling 5G NR examples visualization ===

Mentors: [mailto:aashtari@cttc.es Amir Ashtari Gargari], [mailto:gcarvalho@cttc.es Gabriel Ferreira], [mailto:bbojovic@cttc.es Biljana Bojovic] and [mailto:kkoutlia@cttc.es Katerina Koutlia]

The main idea of this project is to allow easier visualization of 5G NR examples by integrating the NR module with some ns-3 visualization tools like NetAnim, or by implementing a kind of web-based visualization, e.g., through Jupyter notebook. The new feature should allow the visualization of already existing traces, visualization of topology, or even some new relevant simulation aspects could be considered. The idea is that users better understand how the metrics collection works, and how changing parameters can affect simulation results. In this project, we are open to other ideas on how to implement visualizations.

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.

== Large projects (350 hours) ==

=== IPv6 global routing ===

Mentors: [mailto:tommaso.pecorella@unifi.it 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:''
** [https://www.nsnam.org/docs/models/html/ipv6.html IPv6 model in ns-3]
** [https://www.nsnam.org/docs/models/html/routing-overview.html#global-centralized-routing GlobalRouting model in ns-3]

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.

=== AODVv2 Protocol enhancements ===

Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], [TBD].

ns-3 contains models for proactive (DSDV and OLSR) and reactive (AODV and DSR) ad hoc routing protocols. AODVv2 is currently an IETF draft, and its implementation in ns-3 is ongoing. This project aims at enhancing the AODVv2 model for ns-3.

In particular the project should address the following points: 1) AODVv2 performances, 2) AODV address compression, 3) "external" network routing support, 4) general model validation against the latest draft.
Collaboration with the draft authors is also highly suggested.

* ''Required Experience:'' Fundamentals of IPv6 addressing, C++ programming.
* ''Bonus Experience:'' Familiarity with AODV implementations in ns-3 and AODVv2
* ''Interests:'' Ad hoc routing
* ''Difficulty:'' Medium.
* ''Patch requirement:'' [[GSOC2024PatchRequirement]]
* ''Recommended reading:''
** [https://www.nsnam.org/docs/models/html/ipv6.html IPv6 model in ns-3]
** [https://www.nsnam.org/docs/models/html/aodv.html AODV model in ns-3]
** [https://datatracker.ietf.org/doc/draft-perkins-manet-aodvv2/05/ Ad Hoc On-demand Distance Vector Version 2 (AODVv2) Routing]

Possible tasks to fulfill the patch requirement:
* [https://gitlab.com/nsnam/ns-3-dev/-/issues/368 Issue #368] - aodv: aodv parameters can be set to "impossible" values

=== Mesh Link Establishment (MLE) protocol ===

Mentors: [mailto:tommaso.pecorella@unifi.it 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:''
** [https://datatracker.ietf.org/doc/html/draft-ietf-6lo-mesh-link-establishment MLE draft]
** [https://openthread.io/guides/thread-primer/network-discovery Thread primer]
** [https://www.threadgroup.org/ThreadSpec Thread specifications]

Possible tasks to fulfill the patch requirement:
* [[GSOC2024PatchRequirement]]

=== Lr-WPAN (IEEE 802.15.4) preamble detection support ===

Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], [mailto:alramonet@is.tokushima-u.ac.jp 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:''
** [https://ieeexplore.ieee.org/document/1700009 IEEE 802.15.4-2006]
** [https://ieeexplore.ieee.org/document/7460875 IEEE 802.15.4-2015]
** [https://www.nsnam.org/docs/models/html/lr-wpan.html ns-3 lr-wpan module]

Possible tasks to fulfill the patch requirement:
* [[GSOC2024PatchRequirement]]

=== 5G NR module integration with ns-3-ai ===

Mentors: [mailto:kkoutlia@cttc.es Katerina Koutlia], [mailto:gcarvalho@cttc.es Gabriel Ferreira], [mailto:aashtari@cttc.es Amir Ashtari Gargari] and [mailto:bbojovic@cttc.es Biljana Bojovic]

The objective of this project is to integrate the ns-3 5G NR module with [https://apps.nsnam.org/app/ns3-ai/ ns-3-ai]. In GSoC 2024 we had a project in which 5G NR was integrated with [https://www.nsnam.org/wiki/GSOC2024RLUsability5G ns-3 gym]. While ns-3 gym is a popular ns-3 module for AI, it is limited to the application of reinforcement learning machine learning techniques in networking research. On the other hand, ns-3-ai module provides a more general solution that enables the data interaction between ns-3 and other Python-based AI frameworks, like [https://www.tensorflow.org/api_docs/cc Tensorflow C++ APIs] and [https://pytorch.org/cppdocs/ PyTorch C++ APIs], which opens the door to the use different machine learning-based techniques in 5G NR models. The correct functioning of the integration should be tested, and documented, and a fully working example using ns-3-ai should be provided. The contributor can propose a use-case scenario for matching learning. One option is to use it for MAC scheduling, but it could be used for other research problems, and the contributor is encouraged to propose the use case of his/her interest.

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.
* 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.

GSOC2025Projects

2025-02-11T14:44:06Z

Biljana: /* Enabling 5G NR examples visualization */

{{TOC}}

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

* [https://developers.google.com/open-source/gsoc/faq GSoC Frequently Asked Questions]
* [[GSOC2024ContributorGuide |ns-3's 2024 GSoC Contributor guide (to be updated for 2025 at a later date)]]
* [https://developers.google.com/open-source/gsoc/resources/guide GSoC contributor/student guide (not ns-3 specific)]
* [[GSOC2024ApplicationTemplate |2024 GSoC Contributor application template (to be updated for 2025 at a later date)]]
* [[GSOCMentorGuide | ns-3's GSoC Mentor guide]]
* [https://archive.flossmanuals.net/gsocmentoring/index.html GSoC Mentor guide (not ns-3 specific)]
* [[GSOCSelectionProcess | GSoC Contributor Selection Process]]
* ''Get in contact with the ns-3 team'': [https://groups.google.com/g/ns-developers 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-24. 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 [mailto:tpecorella@mac.com Tommaso Pecorella] and[mailto:tahiliani.nitk@gmail.com Mohit P. Tahiliani]; contact them with any questions. They also hang out on [https://ns-3.zulipchat.com 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 [https://developers.google.com/open-source/gsoc/resources/guide GSoC contributor guide].
* Read [[GSOC2024ContributorGuide |ns-3's 2024 GSoC contributor guide]]
* 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.
* Once it is posted, look through the [[GSOC2024ApplicationTemplate |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 2025, 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 2025. 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 suggests 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>
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.
</blockquote>

=== Patch requirement guidelines ===

In past years, we have asked applicants to submit a patch related to an open issue or a suggested coding exercise. We are undecided at this time whether we will ask for this in 2025; check back later.

=== 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)
* [[#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 ===

The general idea is to improve the usability of the 5G NR module by adding new examples that help users start building scenario scripts, such as an example for the NTN use case. Another way is to create new helpers that simplify the creation of new simulation scripts. Also, an interesting improvement could be integration with other modules, like those for AI or visualizations. Here are some project ideas. Depending on the contributor's interest and skills we can adjust these projects' definitions.

* [[#NTN example for 5G NR]] (small size project, 90h)
* [[#5G NR module integration with ns-3-ai]] (large size project, 250h)
* [[#Enabling 5G NR examples visualization]] (large size project, 175h)
* [[#Improving 5G NR module usability through helpers]] (medium size project, 175h)

== Small sized projects (90 hours) ==

=== NTN example for 5G NR ===

Mentors: [mailto:gcarvalho@cttc.es Gabriel Ferreira], [mailto:aashtari@cttc.es Amir Ashtari Gargari], [mailto:bbojovic@cttc.es Biljana Bojovic] and [mailto:kkoutlia@cttc.es Katerina Koutlia]

The objective of this project is the creation of a 5G NR example for the NTN use case. The example should provide a typical NTN topology, with a set of cells served by Low-Earth Orbit (LEO) satellites (e.g. Starlink, Kuiper), hence maybe an NTN topology helper could be created as a part of this project. The example should use the ns-3 3GPP NTN channel model. If handover is already functional, satellites should move at orbital speeds in their orbital planes, handing off users to the upcoming cell with LOS. We could explore scenarios (dense urban and urban).

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.

* 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]. 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].

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:''
** [https://man7.org/linux/man-pages/man2/socket.2.html Linux socket]
** [https://courses.cs.vt.edu/cs4254/fall04/slides/raw_1.pdf Raw Sockets and ICMP, Srinidhi Varadarajan]
** [https://gitlab.com/nsnam/ns-3-dev/-/issues/810 Issue #810]

Possible tasks to fulfill the patch requirement:
* [[GSOC2024PatchRequirement]]

=== 6LoWPAN mesh-under routing enhancements ===

Mentors: [mailto:tommaso.pecorella@unifi.it 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:''
** [https://www.nsnam.org/docs/models/html/sixlowpan.html#mesh-under-routing Mesh-under in ns-3 6LoWPAN]
** [https://datatracker.ietf.org/doc/html/rfc7731 RFC 7731]

Possible tasks to fulfill the patch requirement:
* TBD

=== 6LoWPAN neighbor discovery protocol ===

Mentors: [mailto:tommaso.pecorella@unifi.it 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:''
** [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]

Possible tasks to fulfil the patch requirement:
* Patch the actual 6LoWPAN-ND to remove the limitation about concurrent address registrations.

=== Improving 5G NR module usability through helpers ===

Mentors: [mailto:bbojovic@cttc.es Biljana Bojovic],[mailto:gcarvalho@cttc.es Gabriel Ferreira], [mailto:kkoutlia@cttc.es Katerina Koutlia] and [mailto:aashtari@cttc.es Amir Ashtari Gargari]

This project would be focused on improving the usability of the 5G nr module by enabling new helper support. The implementation of new helpers and the improvement of existing ones, with the final goal of easing the usage of the 5G nr module. The helpers would allow simplifying the setup of NR applications, XR applications, scenarios, the management of the configuration of many parameters of the scenario, etc. All the NR examples should be updated to make use of these new helpers.

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.

* 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]. 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.

=== Enabling 5G NR examples visualization ===

Mentors: [mailto:aashtari@cttc.es Amir Ashtari Gargari], [mailto:gcarvalho@cttc.es Gabriel Ferreira], [mailto:bbojovic@cttc.es Biljana Bojovic] and [mailto:kkoutlia@cttc.es Katerina Koutlia]

The main idea of this project is to allow easier visualization of 5G NR examples by integrating the NR module with some ns-3 visualization tools like NetAnim, or by implementing a kind of web-based visualization, e.g., through Jupyter notebook. The new feature should allow the visualization of already existing traces, visualization of topology, or even some new relevant simulation aspects could be considered. The idea is that users better understand how the metrics collection works, and how changing parameters can affect simulation results. In this project, we are open to other ideas on how to implement visualizations.

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.

== Large projects (350 hours) ==

=== IPv6 global routing ===

Mentors: [mailto:tommaso.pecorella@unifi.it 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:''
** [https://www.nsnam.org/docs/models/html/ipv6.html IPv6 model in ns-3]
** [https://www.nsnam.org/docs/models/html/routing-overview.html#global-centralized-routing GlobalRouting model in ns-3]

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.

=== AODVv2 Protocol enhancements ===

Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], [TBD].

ns-3 contains models for proactive (DSDV and OLSR) and reactive (AODV and DSR) ad hoc routing protocols. AODVv2 is currently an IETF draft, and its implementation in ns-3 is ongoing. This project aims at enhancing the AODVv2 model for ns-3.

In particular the project should address the following points: 1) AODVv2 performances, 2) AODV address compression, 3) "external" network routing support, 4) general model validation against the latest draft.
Collaboration with the draft authors is also highly suggested.

* ''Required Experience:'' Fundamentals of IPv6 addressing, C++ programming.
* ''Bonus Experience:'' Familiarity with AODV implementations in ns-3 and AODVv2
* ''Interests:'' Ad hoc routing
* ''Difficulty:'' Medium.
* ''Patch requirement:'' [[GSOC2024PatchRequirement]]
* ''Recommended reading:''
** [https://www.nsnam.org/docs/models/html/ipv6.html IPv6 model in ns-3]
** [https://www.nsnam.org/docs/models/html/aodv.html AODV model in ns-3]
** [https://datatracker.ietf.org/doc/draft-perkins-manet-aodvv2/05/ Ad Hoc On-demand Distance Vector Version 2 (AODVv2) Routing]

Possible tasks to fulfill the patch requirement:
* [https://gitlab.com/nsnam/ns-3-dev/-/issues/368 Issue #368] - aodv: aodv parameters can be set to "impossible" values

=== Mesh Link Establishment (MLE) protocol ===

Mentors: [mailto:tommaso.pecorella@unifi.it 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:''
** [https://datatracker.ietf.org/doc/html/draft-ietf-6lo-mesh-link-establishment MLE draft]
** [https://openthread.io/guides/thread-primer/network-discovery Thread primer]
** [https://www.threadgroup.org/ThreadSpec Thread specifications]

Possible tasks to fulfill the patch requirement:
* [[GSOC2024PatchRequirement]]

=== Lr-WPAN (IEEE 802.15.4) preamble detection support ===

Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], [mailto:alramonet@is.tokushima-u.ac.jp 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:''
** [https://ieeexplore.ieee.org/document/1700009 IEEE 802.15.4-2006]
** [https://ieeexplore.ieee.org/document/7460875 IEEE 802.15.4-2015]
** [https://www.nsnam.org/docs/models/html/lr-wpan.html ns-3 lr-wpan module]

Possible tasks to fulfill the patch requirement:
* [[GSOC2024PatchRequirement]]

=== 5G NR module integration with ns-3-ai ===

Mentors: [mailto:kkoutlia@cttc.es Katerina Koutlia], [mailto:gcarvalho@cttc.es Gabriel Ferreira], [mailto:aashtari@cttc.es Amir Ashtari Gargari] and [mailto:bbojovic@cttc.es Biljana Bojovic]

The objective of this project is to integrate the ns-3 5G NR module with [https://apps.nsnam.org/app/ns3-ai/ ns-3-ai]. In GSoC 2024 we had a project in which 5G NR was integrated with [https://www.nsnam.org/wiki/GSOC2024RLUsability5G ns-3 gym]. While ns-3 gym is a popular ns-3 module for AI, it is limited to the application of reinforcement learning machine learning techniques in networking research. On the other hand, ns-3-ai module provides a more general solution that enables the data interaction between ns-3 and other Python-based AI frameworks, like [https://www.tensorflow.org/api_docs/cc Tensorflow C++ APIs] and [https://pytorch.org/cppdocs/ PyTorch C++ APIs], which opens the door to the use different machine learning-based techniques in 5G NR models. The correct functioning of the integration should be tested, and documented, and a fully working example using ns-3-ai should be provided. The contributor can propose a use-case scenario for matching learning. One option is to use it for MAC scheduling, but it could be used for other research problems, and the contributor is encouraged to propose the use case of his/her interest.

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.
* 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.

GSOC2025Projects

2025-02-11T13:27:08Z

Biljana: /* #5G NR module integration with ns-3-ai */

{{TOC}}

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

* [https://developers.google.com/open-source/gsoc/faq GSoC Frequently Asked Questions]
* [[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)]
* [[GSOC2024ApplicationTemplate |2024 GSoC Contributor application template]]
* [[GSOCMentorGuide | ns-3's GSoC Mentor guide]]
* [https://archive.flossmanuals.net/gsocmentoring/index.html GSoC Mentor guide (not ns-3 specific)]
* [[GSOCSelectionProcess | GSoC Contributor Selection Process]]
* ''Get in contact with the ns-3 team'': [https://groups.google.com/g/ns-developers 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-24. 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 [mailto:tpecorella@mac.com Tommaso Pecorella], [mailto:tahiliani.nitk@gmail.com Mohit P. Tahiliani], and [mailto:tomh@tomh.org Tom Henderson]; contact them with any questions. They also hang out on [https://ns-3.zulipchat.com 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 [https://developers.google.com/open-source/gsoc/resources/guide 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.
* 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 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 [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>
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.
</blockquote>

=== Patch requirement guidelines ===

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.

=== 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)
* [[#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 ===

The general idea is to improve the usability of the 5G NR module by adding new examples that help users start building scenario scripts, such as an example for the NTN use case. Another way is to create new helpers that simplify the creation of new simulation scripts. Also, an interesting improvement could be integration with other modules, like those for AI or visualizations. Here are some project ideas. Depending on the contributor's interest and skills we can adjust these projects' definitions.

* [[#NTN example for 5G NR]] (small size project, 90h)
* [[#5G NR module integration with ns-3-ai]] (large size project, 250h)
* [[#Enabling 5G NR examples visualization]] (large size project, 175h)
* [[#Improving 5G NR module usability through helpers]] (medium size project, 175h)

== Small sized projects (90 hours) ==

=== NTN example for 5G NR ===

Mentors: [mailto:gcarvalho@cttc.es Gabriel Ferreira], [mailto:aashtari@cttc.es Amir Ashtari Gargari], [mailto:bbojovic@cttc.es Biljana Bojovic] and [mailto:kkoutlia@cttc.es Katerina Koutlia]

The objective of this project is the creation of a 5G NR example for the NTN use case. The example should provide a typical NTN topology, with a set of cells served by Low-Earth Orbit (LEO) satellites (e.g. Starlink, Kuiper), hence maybe an NTN topology helper could be created as a part of this project. The example should use the ns-3 3GPP NTN channel model. If handover is already functional, satellites should move at orbital speeds in their orbital planes, handing off users to the upcoming cell with LOS. We could explore scenarios (dense urban and urban).

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.

* 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]. 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].

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:''
** [https://man7.org/linux/man-pages/man2/socket.2.html Linux socket]
** [https://courses.cs.vt.edu/cs4254/fall04/slides/raw_1.pdf Raw Sockets and ICMP, Srinidhi Varadarajan]
** [https://gitlab.com/nsnam/ns-3-dev/-/issues/810 Issue #810]

Possible tasks to fulfill the patch requirement:
* [[GSOC2024PatchRequirement]]

=== 6LoWPAN mesh-under routing enhancements ===

Mentors: [mailto:tommaso.pecorella@unifi.it 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:''
** [https://www.nsnam.org/docs/models/html/sixlowpan.html#mesh-under-routing Mesh-under in ns-3 6LoWPAN]
** [https://datatracker.ietf.org/doc/html/rfc7731 RFC 7731]

Possible tasks to fulfill the patch requirement:
* TBD

=== 6LoWPAN neighbor discovery protocol ===

Mentors: [mailto:tommaso.pecorella@unifi.it 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:''
** [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]

Possible tasks to fulfil the patch requirement:
* Patch the actual 6LoWPAN-ND to remove the limitation about concurrent address registrations.

=== Improving 5G NR module usability through helpers ===

Mentors: [mailto:bbojovic@cttc.es Biljana Bojovic],[mailto:gcarvalho@cttc.es Gabriel Ferreira], [mailto:kkoutlia@cttc.es Katerina Koutlia] and [mailto:aashtari@cttc.es Amir Ashtari Gargari]

This project would be focused on improving the usability of the 5G nr module by enabling new helper support. The implementation of new helpers and the improvement of existing ones, with the final goal of easing the usage of the 5G nr module. The helpers would allow simplifying the setup of NR applications, XR applications, scenarios, the management of the configuration of many parameters of the scenario, etc. All the NR examples should be updated to make use of these new helpers.

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.

* 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]. 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.

=== Enabling 5G NR examples visualization ===

Mentors: [mailto:aashtari@cttc.es Amir Ashtari Gargari], [mailto:gcarvalho@cttc.es Gabriel Ferreira], [mailto:bbojovic@cttc.es Biljana Bojovic] and [mailto:kkoutlia@cttc.es Katerina Koutlia]

The main idea of this project is to allow easier visualization of 5G NR examples by integrating the NR module with some ns-3 visualization tools like NetAnim, or by implementing a kind of web-based visualization, e.g., through Jupyter notebook. The new feature should allow the visualisation of already existing traces, visualization of topology, or even some new relevant simulation aspects that could be considered. The idea is that users better understand how the metrics collection works, and how changing parameters can affect simulation results. In this project, we are open for other ideas on how to implement visualizations.

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.

== Large projects (350 hours) ==

=== IPv6 global routing ===

Mentors: [mailto:tommaso.pecorella@unifi.it 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:''
** [https://www.nsnam.org/docs/models/html/ipv6.html IPv6 model in ns-3]
** [https://www.nsnam.org/docs/models/html/routing-overview.html#global-centralized-routing GlobalRouting model in ns-3]

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.

=== AODVv2 Protocol enhancements ===

Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], [TBD].

ns-3 contains models for proactive (DSDV and OLSR) and reactive (AODV and DSR) ad hoc routing protocols. AODVv2 is currently an IETF draft, and its implementation in ns-3 is ongoing. This project aims at enhancing the AODVv2 model for ns-3.

In particular the project should address the following points: 1) AODVv2 performances, 2) AODV address compression, 3) "external" network routing support, 4) general model validation against the latest draft.
Collaboration with the draft authors is also highly suggested.

* ''Required Experience:'' Fundamentals of IPv6 addressing, C++ programming.
* ''Bonus Experience:'' Familiarity with AODV implementations in ns-3 and AODVv2
* ''Interests:'' Ad hoc routing
* ''Difficulty:'' Medium.
* ''Patch requirement:'' [[GSOC2024PatchRequirement]]
* ''Recommended reading:''
** [https://www.nsnam.org/docs/models/html/ipv6.html IPv6 model in ns-3]
** [https://www.nsnam.org/docs/models/html/aodv.html AODV model in ns-3]
** [https://datatracker.ietf.org/doc/draft-perkins-manet-aodvv2/05/ Ad Hoc On-demand Distance Vector Version 2 (AODVv2) Routing]

Possible tasks to fulfill the patch requirement:
* [https://gitlab.com/nsnam/ns-3-dev/-/issues/368 Issue #368] - aodv: aodv parameters can be set to "impossible" values

=== Mesh Link Establishment (MLE) protocol ===

Mentors: [mailto:tommaso.pecorella@unifi.it 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:''
** [https://datatracker.ietf.org/doc/html/draft-ietf-6lo-mesh-link-establishment MLE draft]
** [https://openthread.io/guides/thread-primer/network-discovery Thread primer]
** [https://www.threadgroup.org/ThreadSpec Thread specifications]

Possible tasks to fulfill the patch requirement:
* [[GSOC2024PatchRequirement]]

=== Lr-WPAN (IEEE 802.15.4) preamble detection support ===

Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], [mailto:alramonet@is.tokushima-u.ac.jp 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:''
** [https://ieeexplore.ieee.org/document/1700009 IEEE 802.15.4-2006]
** [https://ieeexplore.ieee.org/document/7460875 IEEE 802.15.4-2015]
** [https://www.nsnam.org/docs/models/html/lr-wpan.html ns-3 lr-wpan module]

Possible tasks to fulfill the patch requirement:
* [[GSOC2024PatchRequirement]]

=== 5G NR module integration with ns-3-ai ===

Mentors: [mailto:kkoutlia@cttc.es Katerina Koutlia], [mailto:gcarvalho@cttc.es Gabriel Ferreira], [mailto:aashtari@cttc.es Amir Ashtari Gargari] and [mailto:bbojovic@cttc.es Biljana Bojovic]

The objective of this project is to integrate the ns-3 5G NR module with [https://apps.nsnam.org/app/ns3-ai/ ns-3-ai]. In GSoC 2024 we had a project in which 5G NR was integrated with [https://www.nsnam.org/wiki/GSOC2024RLUsability5G ns-3 gym]. While ns-3 gym is a popular ns-3 module for AI, it is limited to the application of reinforcement learning machine learning techniques in networking research. On the other hand, ns-3-ai module provides a more general solution that enables the data interaction between ns-3 and other Python-based AI frameworks, like [https://www.tensorflow.org/api_docs/cc Tensorflow C++ APIs] and [https://pytorch.org/cppdocs/ PyTorch C++ APIs], which opens the door to the use different machine learning-based techniques in 5G NR models. The correct functioning of the integration should be tested, and documented, and a fully working example using ns-3-ai should be provided. The contributor can propose a use-case scenario for matching learning. One option is to use it for MAC scheduling, but it could be used for other research problems, and the contributor is encouraged to propose the use case of his/her interest.

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.
* 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.

GSOC2025Projects

2025-02-11T13:21:17Z

Biljana: /* #5G NR module integration with ns-3-ai */

{{TOC}}

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

* [https://developers.google.com/open-source/gsoc/faq GSoC Frequently Asked Questions]
* [[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)]
* [[GSOC2024ApplicationTemplate |2024 GSoC Contributor application template]]
* [[GSOCMentorGuide | ns-3's GSoC Mentor guide]]
* [https://archive.flossmanuals.net/gsocmentoring/index.html GSoC Mentor guide (not ns-3 specific)]
* [[GSOCSelectionProcess | GSoC Contributor Selection Process]]
* ''Get in contact with the ns-3 team'': [https://groups.google.com/g/ns-developers 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-24. 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 [mailto:tpecorella@mac.com Tommaso Pecorella], [mailto:tahiliani.nitk@gmail.com Mohit P. Tahiliani], and [mailto:tomh@tomh.org Tom Henderson]; contact them with any questions. They also hang out on [https://ns-3.zulipchat.com 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 [https://developers.google.com/open-source/gsoc/resources/guide 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.
* 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 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 [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>
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.
</blockquote>

=== Patch requirement guidelines ===

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.

=== 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)
* [[#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 ===

The general idea is to improve the usability of the 5G NR module by adding new examples that help users start building scenario scripts, such as an example for the NTN use case. Another way is to create new helpers that simplify the creation of new simulation scripts. Also, an interesting improvement could be integration with other modules, like those for AI or visualizations. Here are some project ideas. Depending on the contributor's interest and skills we can adjust these projects' definitions.

* [[#NTN example for 5G NR]] (small size project, 90h)
* [[#5G NR module integration with ns-3-ai]] (large size project, 250h)
* [[#Enabling 5G NR examples visualization]] (large size project, 175h)
* [[#Improving 5G NR module usability through helpers]] (medium size project, 175h)

== Small sized projects (90 hours) ==

=== NTN example for 5G NR ===

Mentors: [mailto:gcarvalho@cttc.es Gabriel Ferreira], [mailto:aashtari@cttc.es Amir Ashtari Gargari], [mailto:bbojovic@cttc.es Biljana Bojovic] and [mailto:kkoutlia@cttc.es Katerina Koutlia]

The objective of this project is the creation of a 5G NR example for the NTN use case. The example should provide a typical NTN topology, with a set of cells served by Low-Earth Orbit (LEO) satellites (e.g. Starlink, Kuiper), hence maybe an NTN topology helper could be created as a part of this project. The example should use the ns-3 3GPP NTN channel model. If handover is already functional, satellites should move at orbital speeds in their orbital planes, handing off users to the upcoming cell with LOS. We could explore scenarios (dense urban and urban).

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.

* 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]. 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].

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:''
** [https://man7.org/linux/man-pages/man2/socket.2.html Linux socket]
** [https://courses.cs.vt.edu/cs4254/fall04/slides/raw_1.pdf Raw Sockets and ICMP, Srinidhi Varadarajan]
** [https://gitlab.com/nsnam/ns-3-dev/-/issues/810 Issue #810]

Possible tasks to fulfill the patch requirement:
* [[GSOC2024PatchRequirement]]

=== 6LoWPAN mesh-under routing enhancements ===

Mentors: [mailto:tommaso.pecorella@unifi.it 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:''
** [https://www.nsnam.org/docs/models/html/sixlowpan.html#mesh-under-routing Mesh-under in ns-3 6LoWPAN]
** [https://datatracker.ietf.org/doc/html/rfc7731 RFC 7731]

Possible tasks to fulfill the patch requirement:
* TBD

=== 6LoWPAN neighbor discovery protocol ===

Mentors: [mailto:tommaso.pecorella@unifi.it 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:''
** [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]

Possible tasks to fulfil the patch requirement:
* Patch the actual 6LoWPAN-ND to remove the limitation about concurrent address registrations.

=== Improving 5G NR module usability through helpers ===

Mentors: [mailto:bbojovic@cttc.es Biljana Bojovic],[mailto:gcarvalho@cttc.es Gabriel Ferreira], [mailto:kkoutlia@cttc.es Katerina Koutlia] and [mailto:aashtari@cttc.es Amir Ashtari Gargari]

This project would be focused on improving the usability of the 5G nr module by enabling new helper support. The implementation of new helpers and the improvement of existing ones, with the final goal of easing the usage of the 5G nr module. The helpers would allow simplifying the setup of NR applications, XR applications, scenarios, the management of the configuration of many parameters of the scenario, etc. All the NR examples should be updated to make use of these new helpers.

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.

* 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]. 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.

=== Enabling 5G NR examples visualization ===

Mentors: [mailto:aashtari@cttc.es Amir Ashtari Gargari], [mailto:gcarvalho@cttc.es Gabriel Ferreira], [mailto:bbojovic@cttc.es Biljana Bojovic] and [mailto:kkoutlia@cttc.es Katerina Koutlia]

The main idea of this project is to allow easier visualization of 5G NR examples by integrating the NR module with some ns-3 visualization tools like NetAnim, or by implementing a kind of web-based visualization, e.g., through Jupyter notebook. The new feature should allow the visualisation of already existing traces, visualization of topology, or even some new relevant simulation aspects that could be considered. The idea is that users better understand how the metrics collection works, and how changing parameters can affect simulation results. In this project, we are open for other ideas on how to implement visualizations.

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.

== Large projects (350 hours) ==

=== IPv6 global routing ===

Mentors: [mailto:tommaso.pecorella@unifi.it 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:''
** [https://www.nsnam.org/docs/models/html/ipv6.html IPv6 model in ns-3]
** [https://www.nsnam.org/docs/models/html/routing-overview.html#global-centralized-routing GlobalRouting model in ns-3]

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.

=== AODVv2 Protocol enhancements ===

Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], [TBD].

ns-3 contains models for proactive (DSDV and OLSR) and reactive (AODV and DSR) ad hoc routing protocols. AODVv2 is currently an IETF draft, and its implementation in ns-3 is ongoing. This project aims at enhancing the AODVv2 model for ns-3.

In particular the project should address the following points: 1) AODVv2 performances, 2) AODV address compression, 3) "external" network routing support, 4) general model validation against the latest draft.
Collaboration with the draft authors is also highly suggested.

* ''Required Experience:'' Fundamentals of IPv6 addressing, C++ programming.
* ''Bonus Experience:'' Familiarity with AODV implementations in ns-3 and AODVv2
* ''Interests:'' Ad hoc routing
* ''Difficulty:'' Medium.
* ''Patch requirement:'' [[GSOC2024PatchRequirement]]
* ''Recommended reading:''
** [https://www.nsnam.org/docs/models/html/ipv6.html IPv6 model in ns-3]
** [https://www.nsnam.org/docs/models/html/aodv.html AODV model in ns-3]
** [https://datatracker.ietf.org/doc/draft-perkins-manet-aodvv2/05/ Ad Hoc On-demand Distance Vector Version 2 (AODVv2) Routing]

Possible tasks to fulfill the patch requirement:
* [https://gitlab.com/nsnam/ns-3-dev/-/issues/368 Issue #368] - aodv: aodv parameters can be set to "impossible" values

=== Mesh Link Establishment (MLE) protocol ===

Mentors: [mailto:tommaso.pecorella@unifi.it 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:''
** [https://datatracker.ietf.org/doc/html/draft-ietf-6lo-mesh-link-establishment MLE draft]
** [https://openthread.io/guides/thread-primer/network-discovery Thread primer]
** [https://www.threadgroup.org/ThreadSpec Thread specifications]

Possible tasks to fulfill the patch requirement:
* [[GSOC2024PatchRequirement]]

=== Lr-WPAN (IEEE 802.15.4) preamble detection support ===

Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], [mailto:alramonet@is.tokushima-u.ac.jp 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:''
** [https://ieeexplore.ieee.org/document/1700009 IEEE 802.15.4-2006]
** [https://ieeexplore.ieee.org/document/7460875 IEEE 802.15.4-2015]
** [https://www.nsnam.org/docs/models/html/lr-wpan.html ns-3 lr-wpan module]

Possible tasks to fulfill the patch requirement:
* [[GSOC2024PatchRequirement]]

=== #5G NR module integration with ns-3-ai ===

Mentors: [mailto:kkoutlia@cttc.es Katerina Koutlia], [mailto:gcarvalho@cttc.es Gabriel Ferreira], [mailto:aashtari@cttc.es Amir Ashtari Gargari] and [mailto:bbojovic@cttc.es Biljana Bojovic]

The objective of this project is to integrate the ns-3 5G NR module with [https://apps.nsnam.org/app/ns3-ai/ ns-3-ai]. In GSoC 2024 we had a project in which 5G NR was integrated with [https://www.nsnam.org/wiki/GSOC2024RLUsability5G ns-3 gym]. While ns-3 gym is a popular ns-3 module for AI, it is limited to the application of reinforcement learning machine learning techniques in networking research. On the other hand, ns-3-ai module provides a more general solution that enables the data interaction between ns-3 and other Python-based AI frameworks, like [https://www.tensorflow.org/api_docs/cc Tensorflow C++ APIs] and [https://pytorch.org/cppdocs/ PyTorch C++ APIs], which opens the door to the use different machine learning-based techniques in 5G NR models. The correct functioning of the integration should be tested, and documented, and a fully working example using ns-3-ai should be provided. The contributor can propose a use-case scenario for matching learning. One option is to use it for MAC scheduling, but it could be used for other research problems, and the contributor is encouraged to propose the use case of his/her interest.

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.
* 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.

GSOC2025Projects

2025-02-11T13:15:54Z

Biljana: /* #5G NR module integration with ns-3-ai */

{{TOC}}

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

* [https://developers.google.com/open-source/gsoc/faq GSoC Frequently Asked Questions]
* [[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)]
* [[GSOC2024ApplicationTemplate |2024 GSoC Contributor application template]]
* [[GSOCMentorGuide | ns-3's GSoC Mentor guide]]
* [https://archive.flossmanuals.net/gsocmentoring/index.html GSoC Mentor guide (not ns-3 specific)]
* [[GSOCSelectionProcess | GSoC Contributor Selection Process]]
* ''Get in contact with the ns-3 team'': [https://groups.google.com/g/ns-developers 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-24. 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 [mailto:tpecorella@mac.com Tommaso Pecorella], [mailto:tahiliani.nitk@gmail.com Mohit P. Tahiliani], and [mailto:tomh@tomh.org Tom Henderson]; contact them with any questions. They also hang out on [https://ns-3.zulipchat.com 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 [https://developers.google.com/open-source/gsoc/resources/guide 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.
* 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 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 [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>
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.
</blockquote>

=== Patch requirement guidelines ===

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.

=== 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)
* [[#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 ===

The general idea is to improve the usability of the 5G NR module by adding new examples that help users start building scenario scripts, such as an example for the NTN use case. Another way is to create new helpers that simplify the creation of new simulation scripts. Also, an interesting improvement could be integration with other modules, like those for AI or visualizations. Here are some project ideas. Depending on the contributor's interest and skills we can adjust these projects' definitions.

* [[#NTN example for 5G NR]] (small size project, 90h)
* [[#5G NR module integration with ns-3-ai]] (large size project, 250h)
* [[#Enabling 5G NR examples visualization]] (large size project, 175h)
* [[#Improving 5G NR module usability through helpers]] (medium size project, 175h)

== Small sized projects (90 hours) ==

=== NTN example for 5G NR ===

Mentors: [mailto:gcarvalho@cttc.es Gabriel Ferreira], [mailto:aashtari@cttc.es Amir Ashtari Gargari], [mailto:bbojovic@cttc.es Biljana Bojovic] and [mailto:kkoutlia@cttc.es Katerina Koutlia]

The objective of this project is the creation of a 5G NR example for the NTN use case. The example should provide a typical NTN topology, with a set of cells served by Low-Earth Orbit (LEO) satellites (e.g. Starlink, Kuiper), hence maybe an NTN topology helper could be created as a part of this project. The example should use the ns-3 3GPP NTN channel model. If handover is already functional, satellites should move at orbital speeds in their orbital planes, handing off users to the upcoming cell with LOS. We could explore scenarios (dense urban and urban).

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.

* 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]. 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].

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:''
** [https://man7.org/linux/man-pages/man2/socket.2.html Linux socket]
** [https://courses.cs.vt.edu/cs4254/fall04/slides/raw_1.pdf Raw Sockets and ICMP, Srinidhi Varadarajan]
** [https://gitlab.com/nsnam/ns-3-dev/-/issues/810 Issue #810]

Possible tasks to fulfill the patch requirement:
* [[GSOC2024PatchRequirement]]

=== 6LoWPAN mesh-under routing enhancements ===

Mentors: [mailto:tommaso.pecorella@unifi.it 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:''
** [https://www.nsnam.org/docs/models/html/sixlowpan.html#mesh-under-routing Mesh-under in ns-3 6LoWPAN]
** [https://datatracker.ietf.org/doc/html/rfc7731 RFC 7731]

Possible tasks to fulfill the patch requirement:
* TBD

=== 6LoWPAN neighbor discovery protocol ===

Mentors: [mailto:tommaso.pecorella@unifi.it 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:''
** [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]

Possible tasks to fulfil the patch requirement:
* Patch the actual 6LoWPAN-ND to remove the limitation about concurrent address registrations.

=== Improving 5G NR module usability through helpers ===

Mentors: [mailto:bbojovic@cttc.es Biljana Bojovic],[mailto:gcarvalho@cttc.es Gabriel Ferreira], [mailto:kkoutlia@cttc.es Katerina Koutlia] and [mailto:aashtari@cttc.es Amir Ashtari Gargari]

This project would be focused on improving the usability of the 5G nr module by enabling new helper support. The implementation of new helpers and the improvement of existing ones, with the final goal of easing the usage of the 5G nr module. The helpers would allow simplifying the setup of NR applications, XR applications, scenarios, the management of the configuration of many parameters of the scenario, etc. All the NR examples should be updated to make use of these new helpers.

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.

* 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]. 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.

=== Enabling 5G NR examples visualization ===

Mentors: [mailto:aashtari@cttc.es Amir Ashtari Gargari], [mailto:gcarvalho@cttc.es Gabriel Ferreira], [mailto:bbojovic@cttc.es Biljana Bojovic] and [mailto:kkoutlia@cttc.es Katerina Koutlia]

The main idea of this project is to allow easier visualization of 5G NR examples by integrating the NR module with some ns-3 visualization tools like NetAnim, or by implementing a kind of web-based visualization, e.g., through Jupyter notebook. The new feature should allow the visualisation of already existing traces, visualization of topology, or even some new relevant simulation aspects that could be considered. The idea is that users better understand how the metrics collection works, and how changing parameters can affect simulation results. In this project, we are open for other ideas on how to implement visualizations.

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.

== Large projects (350 hours) ==

=== IPv6 global routing ===

Mentors: [mailto:tommaso.pecorella@unifi.it 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:''
** [https://www.nsnam.org/docs/models/html/ipv6.html IPv6 model in ns-3]
** [https://www.nsnam.org/docs/models/html/routing-overview.html#global-centralized-routing GlobalRouting model in ns-3]

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.

=== AODVv2 Protocol enhancements ===

Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], [TBD].

ns-3 contains models for proactive (DSDV and OLSR) and reactive (AODV and DSR) ad hoc routing protocols. AODVv2 is currently an IETF draft, and its implementation in ns-3 is ongoing. This project aims at enhancing the AODVv2 model for ns-3.

In particular the project should address the following points: 1) AODVv2 performances, 2) AODV address compression, 3) "external" network routing support, 4) general model validation against the latest draft.
Collaboration with the draft authors is also highly suggested.

* ''Required Experience:'' Fundamentals of IPv6 addressing, C++ programming.
* ''Bonus Experience:'' Familiarity with AODV implementations in ns-3 and AODVv2
* ''Interests:'' Ad hoc routing
* ''Difficulty:'' Medium.
* ''Patch requirement:'' [[GSOC2024PatchRequirement]]
* ''Recommended reading:''
** [https://www.nsnam.org/docs/models/html/ipv6.html IPv6 model in ns-3]
** [https://www.nsnam.org/docs/models/html/aodv.html AODV model in ns-3]
** [https://datatracker.ietf.org/doc/draft-perkins-manet-aodvv2/05/ Ad Hoc On-demand Distance Vector Version 2 (AODVv2) Routing]

Possible tasks to fulfill the patch requirement:
* [https://gitlab.com/nsnam/ns-3-dev/-/issues/368 Issue #368] - aodv: aodv parameters can be set to "impossible" values

=== Mesh Link Establishment (MLE) protocol ===

Mentors: [mailto:tommaso.pecorella@unifi.it 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:''
** [https://datatracker.ietf.org/doc/html/draft-ietf-6lo-mesh-link-establishment MLE draft]
** [https://openthread.io/guides/thread-primer/network-discovery Thread primer]
** [https://www.threadgroup.org/ThreadSpec Thread specifications]

Possible tasks to fulfill the patch requirement:
* [[GSOC2024PatchRequirement]]

=== Lr-WPAN (IEEE 802.15.4) preamble detection support ===

Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], [mailto:alramonet@is.tokushima-u.ac.jp 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:''
** [https://ieeexplore.ieee.org/document/1700009 IEEE 802.15.4-2006]
** [https://ieeexplore.ieee.org/document/7460875 IEEE 802.15.4-2015]
** [https://www.nsnam.org/docs/models/html/lr-wpan.html ns-3 lr-wpan module]

Possible tasks to fulfill the patch requirement:
* [[GSOC2024PatchRequirement]]

=== #5G NR module integration with ns-3-ai ===

Mentors: [mailto:kkoutlia@cttc.es Katerina Koutlia], [mailto:gcarvalho@cttc.es Gabriel Ferreira], [mailto:bbojovic@cttc.es Biljana Bojovic] and

The objective of this project is to integrate ns-3 5G NR module with [https://apps.nsnam.org/app/ns3-ai/ ns-3-ai]. In GSoC 2024 we had a project in which 5G NR was integrated with [https://www.nsnam.org/wiki/GSOC2024RLUsability5G ns-3 gym]. While ns-3 gym is a popular ns-3 module for AI, it is limited to the application of reinforcement learning machine learning techniques in networking research. On the other hand, ns-3-ai module provides a more general solution that enables the data interaction between ns-3 and other Python-based AI frameworks, like [https://www.tensorflow.org/api_docs/cc Tensorflow C++ APIs] and [https://pytorch.org/cppdocs/ PyTorch C++ APIs], which opens the door to the use different machine learning-based techniques in 5G NR models.

The integration should provide all the necessary interfaces needed for a specific AI use case.

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.
* 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.

GSOC2025Projects

2025-02-11T13:15:24Z

Biljana: /* #5G NR module integration with ns-3-ai */

{{TOC}}

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

* [https://developers.google.com/open-source/gsoc/faq GSoC Frequently Asked Questions]
* [[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)]
* [[GSOC2024ApplicationTemplate |2024 GSoC Contributor application template]]
* [[GSOCMentorGuide | ns-3's GSoC Mentor guide]]
* [https://archive.flossmanuals.net/gsocmentoring/index.html GSoC Mentor guide (not ns-3 specific)]
* [[GSOCSelectionProcess | GSoC Contributor Selection Process]]
* ''Get in contact with the ns-3 team'': [https://groups.google.com/g/ns-developers 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-24. 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 [mailto:tpecorella@mac.com Tommaso Pecorella], [mailto:tahiliani.nitk@gmail.com Mohit P. Tahiliani], and [mailto:tomh@tomh.org Tom Henderson]; contact them with any questions. They also hang out on [https://ns-3.zulipchat.com 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 [https://developers.google.com/open-source/gsoc/resources/guide 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.
* 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 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 [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>
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.
</blockquote>

=== Patch requirement guidelines ===

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.

=== 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)
* [[#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 ===

The general idea is to improve the usability of the 5G NR module by adding new examples that help users start building scenario scripts, such as an example for the NTN use case. Another way is to create new helpers that simplify the creation of new simulation scripts. Also, an interesting improvement could be integration with other modules, like those for AI or visualizations. Here are some project ideas. Depending on the contributor's interest and skills we can adjust these projects' definitions.

* [[#NTN example for 5G NR]] (small size project, 90h)
* [[#5G NR module integration with ns-3-ai]] (large size project, 250h)
* [[#Enabling 5G NR examples visualization]] (large size project, 175h)
* [[#Improving 5G NR module usability through helpers]] (medium size project, 175h)

== Small sized projects (90 hours) ==

=== NTN example for 5G NR ===

Mentors: [mailto:gcarvalho@cttc.es Gabriel Ferreira], [mailto:aashtari@cttc.es Amir Ashtari Gargari], [mailto:bbojovic@cttc.es Biljana Bojovic] and [mailto:kkoutlia@cttc.es Katerina Koutlia]

The objective of this project is the creation of a 5G NR example for the NTN use case. The example should provide a typical NTN topology, with a set of cells served by Low-Earth Orbit (LEO) satellites (e.g. Starlink, Kuiper), hence maybe an NTN topology helper could be created as a part of this project. The example should use the ns-3 3GPP NTN channel model. If handover is already functional, satellites should move at orbital speeds in their orbital planes, handing off users to the upcoming cell with LOS. We could explore scenarios (dense urban and urban).

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.

* 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]. 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].

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:''
** [https://man7.org/linux/man-pages/man2/socket.2.html Linux socket]
** [https://courses.cs.vt.edu/cs4254/fall04/slides/raw_1.pdf Raw Sockets and ICMP, Srinidhi Varadarajan]
** [https://gitlab.com/nsnam/ns-3-dev/-/issues/810 Issue #810]

Possible tasks to fulfill the patch requirement:
* [[GSOC2024PatchRequirement]]

=== 6LoWPAN mesh-under routing enhancements ===

Mentors: [mailto:tommaso.pecorella@unifi.it 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:''
** [https://www.nsnam.org/docs/models/html/sixlowpan.html#mesh-under-routing Mesh-under in ns-3 6LoWPAN]
** [https://datatracker.ietf.org/doc/html/rfc7731 RFC 7731]

Possible tasks to fulfill the patch requirement:
* TBD

=== 6LoWPAN neighbor discovery protocol ===

Mentors: [mailto:tommaso.pecorella@unifi.it 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:''
** [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]

Possible tasks to fulfil the patch requirement:
* Patch the actual 6LoWPAN-ND to remove the limitation about concurrent address registrations.

=== Improving 5G NR module usability through helpers ===

Mentors: [mailto:bbojovic@cttc.es Biljana Bojovic],[mailto:gcarvalho@cttc.es Gabriel Ferreira], [mailto:kkoutlia@cttc.es Katerina Koutlia] and [mailto:aashtari@cttc.es Amir Ashtari Gargari]

This project would be focused on improving the usability of the 5G nr module by enabling new helper support. The implementation of new helpers and the improvement of existing ones, with the final goal of easing the usage of the 5G nr module. The helpers would allow simplifying the setup of NR applications, XR applications, scenarios, the management of the configuration of many parameters of the scenario, etc. All the NR examples should be updated to make use of these new helpers.

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.

* 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]. 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.

=== Enabling 5G NR examples visualization ===

Mentors: [mailto:aashtari@cttc.es Amir Ashtari Gargari], [mailto:gcarvalho@cttc.es Gabriel Ferreira], [mailto:bbojovic@cttc.es Biljana Bojovic] and [mailto:kkoutlia@cttc.es Katerina Koutlia]

The main idea of this project is to allow easier visualization of 5G NR examples by integrating the NR module with some ns-3 visualization tools like NetAnim, or by implementing a kind of web-based visualization, e.g., through Jupyter notebook. The new feature should allow the visualisation of already existing traces, visualization of topology, or even some new relevant simulation aspects that could be considered. The idea is that users better understand how the metrics collection works, and how changing parameters can affect simulation results. In this project, we are open for other ideas on how to implement visualizations.

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.

== Large projects (350 hours) ==

=== IPv6 global routing ===

Mentors: [mailto:tommaso.pecorella@unifi.it 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:''
** [https://www.nsnam.org/docs/models/html/ipv6.html IPv6 model in ns-3]
** [https://www.nsnam.org/docs/models/html/routing-overview.html#global-centralized-routing GlobalRouting model in ns-3]

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.

=== AODVv2 Protocol enhancements ===

Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], [TBD].

ns-3 contains models for proactive (DSDV and OLSR) and reactive (AODV and DSR) ad hoc routing protocols. AODVv2 is currently an IETF draft, and its implementation in ns-3 is ongoing. This project aims at enhancing the AODVv2 model for ns-3.

In particular the project should address the following points: 1) AODVv2 performances, 2) AODV address compression, 3) "external" network routing support, 4) general model validation against the latest draft.
Collaboration with the draft authors is also highly suggested.

* ''Required Experience:'' Fundamentals of IPv6 addressing, C++ programming.
* ''Bonus Experience:'' Familiarity with AODV implementations in ns-3 and AODVv2
* ''Interests:'' Ad hoc routing
* ''Difficulty:'' Medium.
* ''Patch requirement:'' [[GSOC2024PatchRequirement]]
* ''Recommended reading:''
** [https://www.nsnam.org/docs/models/html/ipv6.html IPv6 model in ns-3]
** [https://www.nsnam.org/docs/models/html/aodv.html AODV model in ns-3]
** [https://datatracker.ietf.org/doc/draft-perkins-manet-aodvv2/05/ Ad Hoc On-demand Distance Vector Version 2 (AODVv2) Routing]

Possible tasks to fulfill the patch requirement:
* [https://gitlab.com/nsnam/ns-3-dev/-/issues/368 Issue #368] - aodv: aodv parameters can be set to "impossible" values

=== Mesh Link Establishment (MLE) protocol ===

Mentors: [mailto:tommaso.pecorella@unifi.it 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:''
** [https://datatracker.ietf.org/doc/html/draft-ietf-6lo-mesh-link-establishment MLE draft]
** [https://openthread.io/guides/thread-primer/network-discovery Thread primer]
** [https://www.threadgroup.org/ThreadSpec Thread specifications]

Possible tasks to fulfill the patch requirement:
* [[GSOC2024PatchRequirement]]

=== Lr-WPAN (IEEE 802.15.4) preamble detection support ===

Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], [mailto:alramonet@is.tokushima-u.ac.jp 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:''
** [https://ieeexplore.ieee.org/document/1700009 IEEE 802.15.4-2006]
** [https://ieeexplore.ieee.org/document/7460875 IEEE 802.15.4-2015]
** [https://www.nsnam.org/docs/models/html/lr-wpan.html ns-3 lr-wpan module]

Possible tasks to fulfill the patch requirement:
* [[GSOC2024PatchRequirement]]

=== #5G NR module integration with ns-3-ai ===

[mailto:gcarvalho@cttc.es Gabriel Ferreira], [mailto:bbojovic@cttc.es Biljana Bojovic] and [mailto:kkoutlia@cttc.es Katerina Koutlia]

The objective of this project is to integrate ns-3 5G NR module with [https://apps.nsnam.org/app/ns3-ai/ ns-3-ai]. In GSoC 2024 we had a project in which 5G NR was integrated with [https://www.nsnam.org/wiki/GSOC2024RLUsability5G ns-3 gym]. While ns-3 gym is a popular ns-3 module for AI, it is limited to the application of reinforcement learning machine learning techniques in networking research. On the other hand, ns-3-ai module provides a more general solution that enables the data interaction between ns-3 and other Python-based AI frameworks, like [https://www.tensorflow.org/api_docs/cc Tensorflow C++ APIs] and [https://pytorch.org/cppdocs/ PyTorch C++ APIs], which opens the door to the use different machine learning-based techniques in 5G NR models.

The integration should provide all the necessary interfaces needed for a specific AI use case.

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.
* 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.

GSOC2025Projects

2025-02-11T13:14:25Z

Biljana: /* #5G NR module integration with ns-3-ai */

{{TOC}}

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

* [https://developers.google.com/open-source/gsoc/faq GSoC Frequently Asked Questions]
* [[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)]
* [[GSOC2024ApplicationTemplate |2024 GSoC Contributor application template]]
* [[GSOCMentorGuide | ns-3's GSoC Mentor guide]]
* [https://archive.flossmanuals.net/gsocmentoring/index.html GSoC Mentor guide (not ns-3 specific)]
* [[GSOCSelectionProcess | GSoC Contributor Selection Process]]
* ''Get in contact with the ns-3 team'': [https://groups.google.com/g/ns-developers 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-24. 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 [mailto:tpecorella@mac.com Tommaso Pecorella], [mailto:tahiliani.nitk@gmail.com Mohit P. Tahiliani], and [mailto:tomh@tomh.org Tom Henderson]; contact them with any questions. They also hang out on [https://ns-3.zulipchat.com 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 [https://developers.google.com/open-source/gsoc/resources/guide 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.
* 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 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 [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>
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.
</blockquote>

=== Patch requirement guidelines ===

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.

=== 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)
* [[#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 ===

The general idea is to improve the usability of the 5G NR module by adding new examples that help users start building scenario scripts, such as an example for the NTN use case. Another way is to create new helpers that simplify the creation of new simulation scripts. Also, an interesting improvement could be integration with other modules, like those for AI or visualizations. Here are some project ideas. Depending on the contributor's interest and skills we can adjust these projects' definitions.

* [[#NTN example for 5G NR]] (small size project, 90h)
* [[#5G NR module integration with ns-3-ai]] (large size project, 250h)
* [[#Enabling 5G NR examples visualization]] (large size project, 175h)
* [[#Improving 5G NR module usability through helpers]] (medium size project, 175h)

== Small sized projects (90 hours) ==

=== NTN example for 5G NR ===

Mentors: [mailto:gcarvalho@cttc.es Gabriel Ferreira], [mailto:aashtari@cttc.es Amir Ashtari Gargari], [mailto:bbojovic@cttc.es Biljana Bojovic] and [mailto:kkoutlia@cttc.es Katerina Koutlia]

The objective of this project is the creation of a 5G NR example for the NTN use case. The example should provide a typical NTN topology, with a set of cells served by Low-Earth Orbit (LEO) satellites (e.g. Starlink, Kuiper), hence maybe an NTN topology helper could be created as a part of this project. The example should use the ns-3 3GPP NTN channel model. If handover is already functional, satellites should move at orbital speeds in their orbital planes, handing off users to the upcoming cell with LOS. We could explore scenarios (dense urban and urban).

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.

* 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]. 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].

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:''
** [https://man7.org/linux/man-pages/man2/socket.2.html Linux socket]
** [https://courses.cs.vt.edu/cs4254/fall04/slides/raw_1.pdf Raw Sockets and ICMP, Srinidhi Varadarajan]
** [https://gitlab.com/nsnam/ns-3-dev/-/issues/810 Issue #810]

Possible tasks to fulfill the patch requirement:
* [[GSOC2024PatchRequirement]]

=== 6LoWPAN mesh-under routing enhancements ===

Mentors: [mailto:tommaso.pecorella@unifi.it 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:''
** [https://www.nsnam.org/docs/models/html/sixlowpan.html#mesh-under-routing Mesh-under in ns-3 6LoWPAN]
** [https://datatracker.ietf.org/doc/html/rfc7731 RFC 7731]

Possible tasks to fulfill the patch requirement:
* TBD

=== 6LoWPAN neighbor discovery protocol ===

Mentors: [mailto:tommaso.pecorella@unifi.it 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:''
** [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]

Possible tasks to fulfil the patch requirement:
* Patch the actual 6LoWPAN-ND to remove the limitation about concurrent address registrations.

=== Improving 5G NR module usability through helpers ===

Mentors: [mailto:bbojovic@cttc.es Biljana Bojovic],[mailto:gcarvalho@cttc.es Gabriel Ferreira], [mailto:kkoutlia@cttc.es Katerina Koutlia] and [mailto:aashtari@cttc.es Amir Ashtari Gargari]

This project would be focused on improving the usability of the 5G nr module by enabling new helper support. The implementation of new helpers and the improvement of existing ones, with the final goal of easing the usage of the 5G nr module. The helpers would allow simplifying the setup of NR applications, XR applications, scenarios, the management of the configuration of many parameters of the scenario, etc. All the NR examples should be updated to make use of these new helpers.

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.

* 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]. 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.

=== Enabling 5G NR examples visualization ===

Mentors: [mailto:aashtari@cttc.es Amir Ashtari Gargari], [mailto:gcarvalho@cttc.es Gabriel Ferreira], [mailto:bbojovic@cttc.es Biljana Bojovic] and [mailto:kkoutlia@cttc.es Katerina Koutlia]

The main idea of this project is to allow easier visualization of 5G NR examples by integrating the NR module with some ns-3 visualization tools like NetAnim, or by implementing a kind of web-based visualization, e.g., through Jupyter notebook. The new feature should allow the visualisation of already existing traces, visualization of topology, or even some new relevant simulation aspects that could be considered. The idea is that users better understand how the metrics collection works, and how changing parameters can affect simulation results. In this project, we are open for other ideas on how to implement visualizations.

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.

== Large projects (350 hours) ==

=== IPv6 global routing ===

Mentors: [mailto:tommaso.pecorella@unifi.it 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:''
** [https://www.nsnam.org/docs/models/html/ipv6.html IPv6 model in ns-3]
** [https://www.nsnam.org/docs/models/html/routing-overview.html#global-centralized-routing GlobalRouting model in ns-3]

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.

=== AODVv2 Protocol enhancements ===

Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], [TBD].

ns-3 contains models for proactive (DSDV and OLSR) and reactive (AODV and DSR) ad hoc routing protocols. AODVv2 is currently an IETF draft, and its implementation in ns-3 is ongoing. This project aims at enhancing the AODVv2 model for ns-3.

In particular the project should address the following points: 1) AODVv2 performances, 2) AODV address compression, 3) "external" network routing support, 4) general model validation against the latest draft.
Collaboration with the draft authors is also highly suggested.

* ''Required Experience:'' Fundamentals of IPv6 addressing, C++ programming.
* ''Bonus Experience:'' Familiarity with AODV implementations in ns-3 and AODVv2
* ''Interests:'' Ad hoc routing
* ''Difficulty:'' Medium.
* ''Patch requirement:'' [[GSOC2024PatchRequirement]]
* ''Recommended reading:''
** [https://www.nsnam.org/docs/models/html/ipv6.html IPv6 model in ns-3]
** [https://www.nsnam.org/docs/models/html/aodv.html AODV model in ns-3]
** [https://datatracker.ietf.org/doc/draft-perkins-manet-aodvv2/05/ Ad Hoc On-demand Distance Vector Version 2 (AODVv2) Routing]

Possible tasks to fulfill the patch requirement:
* [https://gitlab.com/nsnam/ns-3-dev/-/issues/368 Issue #368] - aodv: aodv parameters can be set to "impossible" values

=== Mesh Link Establishment (MLE) protocol ===

Mentors: [mailto:tommaso.pecorella@unifi.it 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:''
** [https://datatracker.ietf.org/doc/html/draft-ietf-6lo-mesh-link-establishment MLE draft]
** [https://openthread.io/guides/thread-primer/network-discovery Thread primer]
** [https://www.threadgroup.org/ThreadSpec Thread specifications]

Possible tasks to fulfill the patch requirement:
* [[GSOC2024PatchRequirement]]

=== Lr-WPAN (IEEE 802.15.4) preamble detection support ===

Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], [mailto:alramonet@is.tokushima-u.ac.jp 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:''
** [https://ieeexplore.ieee.org/document/1700009 IEEE 802.15.4-2006]
** [https://ieeexplore.ieee.org/document/7460875 IEEE 802.15.4-2015]
** [https://www.nsnam.org/docs/models/html/lr-wpan.html ns-3 lr-wpan module]

Possible tasks to fulfill the patch requirement:
* [[GSOC2024PatchRequirement]]

=== #5G NR module integration with ns-3-ai ===

The objective of this project is to integrate ns-3 5G NR module with [https://apps.nsnam.org/app/ns3-ai/ ns-3-ai]. In GSoC 2024 we had a project in which 5G NR was integrated with [https://www.nsnam.org/wiki/GSOC2024RLUsability5G ns-3 gym]. While ns-3 gym is a popular ns-3 module for AI, it is limited to the application of reinforcement learning machine learning techniques in networking research. On the other hand, ns-3-ai module provides a more general solution that enables the data interaction between ns-3 and other Python-based AI frameworks, like [https://www.tensorflow.org/api_docs/cc Tensorflow C++ APIs] and [https://pytorch.org/cppdocs/ PyTorch C++ APIs], which opens the door to the use different machine learning-based techniques in 5G NR models.

The integration should provide all the necessary interfaces needed for a specific AI use case.

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.
* 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.