https://www.nsnam.org/mediawiki/api.php?action=feedcontributions&feedformat=atom&user=Tommaso 2026-05-06T10:34:59Z User contributions MediaWiki 1.39.8 https://www.nsnam.org/mediawiki/index.php?title=GSOC2026ContributorGuide&diff=13770 2026-02-21T11:00:06Z

<p>Tommaso: </p> <hr /> <div>{{TOC}}<br /> &lt;blockquote style=&quot;padding: 2em &quot;&gt;<br /> <br /> * [[GSOC2026ContributorGuide |ns-3's GSoC contributor guide]]<br /> * [[GSOC2026Projects |GSoC 2026 project ideas page]]<br /> * [[GSOC2026ApplicationTemplate | GSoC contributor application template]]<br /> * [[Summer_Projects | List of past summer projects]]<br /> * ''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<br /> &lt;/blockquote&gt;<br /> <br /> = Guidelines =<br /> <br /> This webpage highlights the expectations and requirements for applicants for ns-3's Google Summer of Code (GSoC) 2026 effort.&lt;br/&gt;<br /> <br /> == Project Expectations ==<br /> <br /> The ns-3 team is looking for three things from every successful GSoC project:<br /> * Developing code that can be incorporated back into the main codebase, useful to future users.<br /> * Mentoring contributors that will remain part of the team and contribute to the ns-3 effort even *after* GSoC ends. That is, we're looking for long-term contributors and maintainers for the project.<br /> * Providing GSOC contributors with experience and ideas that will be useful to them in their careers.<br /> <br /> == Contributor Expectations ==<br /> <br /> * At the beginning of the program, the contributor will be required to provide a detailed plan of work covering the duration of GSoC. This should be developed with the help of the mentor. Contributors will have to setup a wiki page for their project, and cover important aspects of their proposal's design, the strategy to implement it, a list of deliverables, and lastly, update the wiki page as and when each milestone is achieved. This page along with the code repository allows the community to keep track of the contributor's efforts.<br /> * The contributor will be expected to produce mergeable code (either merged completely at the end of the project, partially at the end of the project, or not merged yet but with no major roadblocks foreseen to merge shortly after the program ends).<br /> * The contributor will be expected to follow ns-3 design guidelines (follow coding style, write tests, documentation).<br /> * Contributors are required to submit weekly reports on the mailing list, covering the progress they've made or the obstacles they've run into. This will help the community keep track of the contributor's efforts, and help as needed.<br /> * The contributor will have his or her code reviewed by the ns-3 community. The reviews will be taken prior to the Google evaluations and will look at issues such as scope, public API, test plan, and open issues. All contributors will be briefed on a checklist of things to prepare for these reviews. Between these reviews, mentors will periodically (at least weekly) review the contributor's output and will provide guidance where needed, and track this progress in a public place such as a wiki entry or the mailing list.<br /> * If a contributor drops the project before the GSoC program ends, is under-performing, or isn't communicating enough with the mentor and development team, he or she will not be passed (will not receive final payment from Google).<br /> <br /> == Expected Background ==<br /> <br /> ns-3 development typically requires proficiency in C++ and a debugger such as gdb or ddd.<br /> It is also required that the contributor knows how to use Git (at least forks, branches, merge requests), as ns-3 uses git for most of its development.<br /> The valgrind suite of tools, and a system profiler such as oprofile, are typically useful. Python may be necessary for some projects, but is generally an optional component. Domain knowledge of the components pertaining to the project is also expected.<br /> <br /> == Application Development ==<br /> <br /> In years past, many prospective applicants have tried to work privately with a mentor to develop their applications, sending many private PMs and emails. This is understandable because GSoC is a competitive process, but by working this way, the rest of the mentors and the ns-3 community do not have an opportunity to learn about the applicant, and private communication can be considered as possibly an unfair advantage. In an open source project, it is more preferable to work in public as much as possible. Therefore, some mentors may decline to help applicants in private with their application, and only respond to requests in public forums such as Zulip chat or the developers mailing list.<br /> <br /> == AI use ==<br /> <br /> The use of AI tools to draft the proposals is neither suggested, nor discouraged. However, the candidate must use the tools responsibly and:<br /> * Be the principal driver of the proposal,<br /> * Disclose the use of AI tools in the proposal submission (how the AI has been used, and to generate what).<br /> In other words, using an AI as a tool to validate or improve a proposal is acceptable, using an AI to write a proposal without fully understanding the proposal itself is not acceptable, and will result in a rejection.<br /> <br /> == The Selection Process ==<br /> <br /> Selection of contributors for GSoC will be competitive. Acceptance ratios are low (typically in the range of 10-25%) and the applications that are selected are very well developed. <br /> <br /> The contributors will be selected by a selection committee which will consist of the candidate mentors (listed on the Project Ideas page). Other mentors can participate in the application development phase and provide input to the final evaluations. Applications will be evaluated and scored according to the following criteria: &lt;br/&gt;<br /> <br /> *1) Overall technical quality of application, including whether the project seems feasible and properly scoped, whether the contributor appears knowledgeable about ns-3, C++, the models that are being proposed, sample code submitted, and the project plan including proposed milestones.<br /> *2) Availability of a mentor for the suggested project.<br /> *3) Impact and relevance to future users of ns-3? (e.g. does the proposed project support an active field of research? Are results of the project broadly applicable? Does it bring unique capabilities to ns-3?)<br /> *4) Participation and involvement in the community and with prospective mentors.<br /> <br /> High scoring applicants may be asked to discuss their project details over email, chat, or online meetings. When the evaluation process concludes, the organization administrator will determine the highest ranking applicants and if there are close rankings or concerns, hold a meeting among selection committee members to resolve tiebreakers.<br /> <br /> The ns-3 project will then rank and recommend a set of students for GSoC slots, and Google will then decide how many slots to fund for ns-3.<br /> <br /> == Where to begin ==<br /> <br /> Contributors are expected to have worked through [https://www.nsnam.org/docs/tutorial/html/index.html the ns-3 tutorial] and to have read through and executed the code in their areas of interest.<br /> <br /> If you need help with ns-3, you can contact the ns-3 community (either through email or Zulip). You can, and indeed you are encouraged to, interact with the ns-3 community as soon as you can, even before the GSoC period,<br /> <br /> The [[GSOC2026Projects | project ideas]] that we list are starting points for contributors to develop further, with help from mentors, but we are not going to provide a specific checklist or plan; that is for applicants to develop. We are also open to ideas not found on the list; if you are excited to work on something specific, let us know and we will give you some feedback on it, and check whether there is someone available to mentor the project.<br /> <br /> The best applications are provided by contributors who have a desire to accomplish specific goals in the project (usually aligned with their own research or interests outside of GSoC), who can articulate an understanding of the issues involved, who get involved with mentors during the application process to help refine the application, and who provide some evidence that they have a reasonable plan and the coding skills to make progress on the goals.<br /> <br /> After you decide which ideas you would like to explore, join the [https://groups.google.com/g/ns-developers development mailing list] or enter the ns-3 room on Zulip chat to discuss ideas with us.<br /> <br /> You are more likely to get help if you ask specific questions that demonstrate that you have tried to make progress on a topic. A question such as &quot;I am interested in ns-3; can you tell me how to begin?&quot;, or one that just asks generically about a project idea (e.g. &quot;I am interested in the project idea 'DSR RFC compliance' on the wiki; can you please guide me as to how to begin?&quot;) is not likely to generate helpful guidance. A better example of a question more likely to generate good feedback would be something like: &quot;I have read the code in the DSR module, and run the examples, and I have reviewed the RFC. It seems to me that sections X, Y, and Z of the RFC are not aligned with the ns-3 model, and I also found some comments in the code that state that something is not supported yet. Can you give me some feedback about which of these features might be the most useful to prioritize?&quot;<br /> <br /> Please note that all first-time posters to the ns-developers list are moderated to filter out inappropriate posts, so don't be alarmed if your email does not immediately post to the list; it will within 24 hours.<br /> <br /> == How to apply ==<br /> <br /> Contributors apply directly to Google; for more information on how to apply, please look at the [https://summerofcode.withgoogle.com/ Google program site].<br /> <br /> While contributors are encouraged to discuss their technical plans with potential mentors on the ns-developers list, they are under no obligation to share their application details on the list.<br /> <br /> The application format is not fixed. However, we warmly suggest to follow this [https://www.nsnam.org/wiki/GSOC2026ApplicationTemplate Application Template], as it will make it easier to evaluate your proposals.<br /> <br /> == Contributor benefits ==<br /> * GSoC is an excellent opportunity to gain experience working on an open source project.<br /> * Working with the ns-3 project will allow you to improve your networking knowledge, C++ skills and to be in contact with a highly skilled team of developers and user group.<br /> * This is a great opportunity to contribute to our open source community.<br /> <br /> == A piece of advice ==<br /> <br /> Based on the ns-3 team's experiences in the previous Google Summer of Code programs, the most important factor in the success of an application and project is communication. That process begins in the application phase. Without joining the [https://groups.google.com/g/ns-developers mailing list] or the [https://ns-3.zulipchat.com Zulip chat] and initiating a discussion of your ideas, it is unlikely that your application will be complete or rich enough to be competitive. Please feel free to discuss your proposed technical approach, plan, and other factors on the mailing list or in the GSoC thread on Zulip while developing your application. In addition to helping you develop the necessary details, focus, and priorities to write a good application, this will also demonstrate your commitment and willingness to dedicate time to the effort. During the program, every contributor is expected to communicate regularly with their mentor, announce weekly updates of their projects and participate on the [http://mailman.isi.edu/mailman/listinfo/ns-developers development mailing list] and discuss their work over chat.<br /> <br /> = Contributor guidelines =<br /> <br /> These guidelines are for contributors working on ns-3 summer of code projects.<br /> <br /> == Goals ==<br /> <br /> This is a program for you to develop and merge code to ns-3. Your mentors will help guide you through the many steps required to position yourself for a successful final review and merge. While writing code is the main activity, it must be supported by good documentation, good examples, tests, and good communications with the rest of the project.<br /> <br /> == Guidelines for accepted contributors ==<br /> <br /> Here is a brief checklist of things you should try to familiarize yourself with.<br /> <br /> * '''Contributing.''' [https://www.nsnam.org/docs/contributing/html/index.html Documentation about contributing to ns-3 in general].<br /> * '''Coding style.''' Do you know how to format your code properly? Do you know how to run the auto-formatting program check-style-clang-format.py? Have you added Doxygen properly? Please read [https://www.nsnam.org/docs/contributing/html/coding-style.html here].<br /> * ''' Zulip chat room.''' [https://ns-3.zulipchat.com Zulip chat] is where most of the day-to-day project discussion now occurs. We will ask contributors to hang out there during their working hours.<br /> * '''ns-3-users forum.''' Please plan to read [https://groups.google.com/g/ns-3-users this list] daily during your project. Please also try, from time to time, to answer questions that you feel comfortable answering. Soon you will have more expertise than many of the people posting questions to this list, and you can start to help share the load of answering questions for new users.<br /> * '''ns-developers mailing list.''' Please plan to read [https://groups.google.com/g/ns-developers this list] daily during your project. This will be the list where you communicate with the developers to get your code reviewed and merged.<br /> * '''wiki.''' Please read through the [https://www.nsnam.org/wiki wiki]. Contributions and edits are welcome, to fix stale information or to create new topics.<br /> * '''Test framework.''' Do you know how the test framework works? Can you write your own test code? Please read [https://www.nsnam.org/docs/release/3.37/manual/html/tests.html this documentation].<br /> * '''gdb and valgrind.''' Can you run your code through gdb and valgrind? Can you run your tests through that?<br /> * '''AI tools.''' AI tools are neither suggested nor discouraged. However, their eventual use should be discussed with the mentors and acknowledged. In any case, the developer must take full responsibility for the correctness of the code.<br /> <br /> == Planning ==<br /> <br /> Some advice:<br /> * Refine your plan of what you want to accomplish. The plan should start out slow with some low-risk, easy to accomplish milestones, and work towards harder milestones. It is really important to think and revisit these three issues:<br /> ** '''Scope.''' What use cases should your code support, and what is specifically out of scope, when you are done with your project?<br /> ** '''Usability.''' How do you expect users to use your code? What kind of API would users find the most natural and easiest to work with? Is it extensible by future developers?<br /> ** '''Testing.''' How can you test that your code works as expected? What tests should your code pass when it is done? <br /> * Decompose your project into small mergeable chunks. A good workflow would be to code something new, test it, document it, post for review, and iterate. If you don't accomplish all of your technical goals because you run out of time, make sure that what you have done is mergeable (i.e. it is better to accomplish 50% of your goals, with documentation and testing completed, than 80% or 100% of your goals that does not have good documentation and testing. The latter will not be merged.)<br /> * Commit early, commit often. This will make it easier for your mentors to track your progress.<br /> <br /> [[Category:GSoC]]</div>

Tommaso https://www.nsnam.org/mediawiki/index.php?title=GSOC2026ContributorGuide&diff=13769 2026-02-21T10:51:28Z

<p>Tommaso: </p> <hr /> <div>{{TOC}}<br /> &lt;blockquote style=&quot;padding: 2em &quot;&gt;<br /> <br /> * [[GSOC2026ContributorGuide |ns-3's GSoC contributor guide]]<br /> * [[GSOC2026Projects |GSoC 2026 project ideas page]]<br /> * [[GSOC2026ApplicationTemplate | GSoC contributor application template]]<br /> * [[Summer_Projects | List of past summer projects]]<br /> * ''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<br /> &lt;/blockquote&gt;<br /> <br /> = Guidelines =<br /> <br /> This webpage highlights the expectations and requirements for applicants for ns-3's Google Summer of Code (GSoC) 2026 effort.&lt;br/&gt;<br /> <br /> == Project Expectations ==<br /> <br /> The ns-3 team is looking for three things from every successful GSoC project:<br /> * Developing code that can be incorporated back into the main codebase, useful to future users.<br /> * Mentoring contributors that will remain part of the team and contribute to the ns-3 effort even *after* GSoC ends. That is, we're looking for long-term contributors and maintainers for the project.<br /> * Providing GSOC contributors with experience and ideas that will be useful to them in their careers.<br /> <br /> == Contributor Expectations ==<br /> <br /> * At the beginning of the program, the contributor will be required to provide a detailed plan of work covering the duration of GSoC. This should be developed with the help of the mentor. Contributors will have to setup a wiki page for their project, and cover important aspects of their proposal's design, the strategy to implement it, a list of deliverables, and lastly, update the wiki page as and when each milestone is achieved. This page along with the code repository allows the community to keep track of the contributor's efforts.<br /> * The contributor will be expected to produce mergeable code (either merged completely at the end of the project, partially at the end of the project, or not merged yet but with no major roadblocks foreseen to merge shortly after the program ends).<br /> * The contributor will be expected to follow ns-3 design guidelines (follow coding style, write tests, documentation).<br /> * Contributors are required to submit weekly reports on the mailing list, covering the progress they've made or the obstacles they've run into. This will help the community keep track of the contributor's efforts, and help as needed.<br /> * The contributor will have his or her code reviewed by the ns-3 community. The reviews will be taken prior to the Google evaluations and will look at issues such as scope, public API, test plan, and open issues. All contributors will be briefed on a checklist of things to prepare for these reviews. Between these reviews, mentors will periodically (at least weekly) review the contributor's output and will provide guidance where needed, and track this progress in a public place such as a wiki entry or the mailing list.<br /> * If a contributor drops the project before the GSoC program ends, is under-performing, or isn't communicating enough with the mentor and development team, he or she will not be passed (will not receive final payment from Google).<br /> <br /> == Expected Background ==<br /> <br /> ns-3 development typically requires proficiency in C++ and a debugger such as gdb or ddd.<br /> It is also required that the contributor knows how to use Git (at least forks, branches, merge requests), as ns-3 uses git for most of its development.<br /> The valgrind suite of tools, and a system profiler such as oprofile, are typically useful. Python may be necessary for some projects, but is generally an optional component. Domain knowledge of the components pertaining to the project is also expected.<br /> <br /> == Application Development ==<br /> <br /> In years past, many prospective applicants have tried to work privately with a mentor to develop their applications, sending many private PMs and emails. This is understandable because GSoC is a competitive process, but by working this way, the rest of the mentors and the ns-3 community do not have an opportunity to learn about the applicant, and private communication can be considered as possibly an unfair advantage. In an open source project, it is more preferable to work in public as much as possible. Therefore, some mentors may decline to help applicants in private with their application, and only respond to requests in public forums such as Zulip chat or the developers mailing list.<br /> <br /> == The Selection Process ==<br /> <br /> Selection of contributors for GSoC will be competitive. Acceptance ratios are low (typically in the range of 10-25%) and the applications that are selected are very well developed. <br /> <br /> The contributors will be selected by a selection committee which will consist of the candidate mentors (listed on the Project Ideas page). Other mentors can participate in the application development phase and provide input to the final evaluations. Applications will be evaluated and scored according to the following criteria: &lt;br/&gt;<br /> <br /> *1) Overall technical quality of application, including whether the project seems feasible and properly scoped, whether the contributor appears knowledgeable about ns-3, C++, the models that are being proposed, sample code submitted, and the project plan including proposed milestones.<br /> *2) Availability of a mentor for the suggested project.<br /> *3) Impact and relevance to future users of ns-3? (e.g. does the proposed project support an active field of research? Are results of the project broadly applicable? Does it bring unique capabilities to ns-3?)<br /> *4) Participation and involvement in the community and with prospective mentors.<br /> <br /> High scoring applicants may be asked to discuss their project details over email or chat. When the evaluation process concludes, the organization administrator will determine the highest ranking applicants and if there are close rankings or concerns, hold a meeting among selection committee members to resolve tiebreakers.<br /> <br /> The ns-3 project will then rank and recommend a set of students for GSoC slots, and Google will then decide how many slots to fund for ns-3.<br /> <br /> == Where to begin ==<br /> <br /> Contributors are expected to have worked through [https://www.nsnam.org/docs/tutorial/html/index.html the ns-3 tutorial] and to have read through and executed the code in their areas of interest.<br /> <br /> If you need help with ns-3, you can contact the ns-3 community (either through email or Zulip). You can, and indeed you are encouraged to, interact with the ns-3 community as soon as you can, even before the GSoC period,<br /> <br /> The [[GSOC2026Projects | project ideas]] that we list are starting points for contributors to develop further, with help from mentors, but we are not going to provide a specific checklist or plan; that is for applicants to develop. We are also open to ideas not found on the list; if you are excited to work on something specific, let us know and we will give you some feedback on it, and check whether there is someone available to mentor the project.<br /> <br /> The best applications are provided by contributors who have a desire to accomplish specific goals in the project (usually aligned with their own research or interests outside of GSoC), who can articulate an understanding of the issues involved, who get involved with mentors during the application process to help refine the application, and who provide some evidence that they have a reasonable plan and the coding skills to make progress on the goals.<br /> <br /> After you decide which ideas you would like to explore, join the [https://groups.google.com/g/ns-developers development mailing list] or enter the ns-3 room on Zulip chat to discuss ideas with us.<br /> <br /> You are more likely to get help if you ask specific questions that demonstrate that you have tried to make progress on a topic. A question such as &quot;I am interested in ns-3; can you tell me how to begin?&quot;, or one that just asks generically about a project idea (e.g. &quot;I am interested in the project idea 'DSR RFC compliance' on the wiki; can you please guide me as to how to begin?&quot;) is not likely to generate helpful guidance. A better example of a question more likely to generate good feedback would be something like: &quot;I have read the code in the DSR module, and run the examples, and I have reviewed the RFC. It seems to me that sections X, Y, and Z of the RFC are not aligned with the ns-3 model, and I also found some comments in the code that state that something is not supported yet. Can you give me some feedback about which of these features might be the most useful to prioritize?&quot;<br /> <br /> Please note that all first-time posters to the ns-developers list are moderated to filter out inappropriate posts, so don't be alarmed if your email does not immediately post to the list; it will within 24 hours.<br /> <br /> == How to apply ==<br /> <br /> Contributors apply directly to Google; for more information on how to apply, please look at the [https://summerofcode.withgoogle.com/ Google program site].<br /> <br /> While contributors are encouraged to discuss their technical plans with potential mentors on the ns-developers list, they are under no obligation to share their application details on the list.<br /> <br /> The application format is not fixed. However, we warmly suggest to follow this [https://www.nsnam.org/wiki/GSOC2025ApplicationTemplate Application Template], as it will make it easier to evaluate your proposals.<br /> <br /> == Contributor benefits ==<br /> * GSoC is an excellent opportunity to gain experience working on an open source project.<br /> * Working with the ns-3 project will allow you to improve your networking knowledge, C++ skills and to be in contact with a highly skilled team of developers and user group.<br /> * This is a great opportunity to contribute to our open source community.<br /> <br /> == A piece of advice ==<br /> <br /> Based on the ns-3 team's experiences in the previous Google Summer of Code programs, the most important factor in the success of an application and project is communication. That process begins in the application phase. Without joining the [https://groups.google.com/g/ns-developers mailing list] or the [https://ns-3.zulipchat.com Zulip chat] and initiating a discussion of your ideas, it is unlikely that your application will be complete or rich enough to be competitive. Please feel free to discuss your proposed technical approach, plan, and other factors on the mailing list or in the GSoC thread on Zulip while developing your application. In addition to helping you develop the necessary details, focus, and priorities to write a good application, this will also demonstrate your commitment and willingness to dedicate time to the effort. During the program, every contributor is expected to communicate regularly with their mentor, announce weekly updates of their projects and participate on the [http://mailman.isi.edu/mailman/listinfo/ns-developers development mailing list] and discuss their work over chat.<br /> <br /> = Contributor guidelines =<br /> <br /> These guidelines are for contributors working on ns-3 summer of code projects.<br /> <br /> == Goals ==<br /> <br /> This is a program for you to develop and merge code to ns-3. Your mentors will help guide you through the many steps required to position yourself for a successful final review and merge. While writing code is the main activity, it must be supported by good documentation, good examples, tests, and good communications with the rest of the project.<br /> <br /> == Guidelines for accepted contributors ==<br /> <br /> Here is a brief checklist of things you should try to familiarize yourself with.<br /> <br /> * '''Contributing.''' [https://www.nsnam.org/docs/contributing/html/index.html Documentation about contributing to ns-3 in general].<br /> * '''Coding style.''' Do you know how to format your code properly? Do you know how to run the auto-formatting program check-style-clang-format.py? Have you added Doxygen properly? Please read [https://www.nsnam.org/docs/contributing/html/coding-style.html here].<br /> * ''' Zulip chat room.''' [https://ns-3.zulipchat.com Zulip chat] is where most of the day-to-day project discussion now occurs. We will ask contributors to hang out there during their working hours.<br /> * '''ns-3-users forum.''' Please plan to read [https://groups.google.com/g/ns-3-users this list] daily during your project. Please also try, from time to time, to answer questions that you feel comfortable answering. Soon you will have more expertise than many of the people posting questions to this list, and you can start to help share the load of answering questions for new users.<br /> * '''ns-developers mailing list.''' Please plan to read [https://groups.google.com/g/ns-developers this list] daily during your project. This will be the list where you communicate with the developers to get your code reviewed and merged.<br /> * '''wiki.''' Please read through the [https://www.nsnam.org/wiki wiki]. Contributions and edits are welcome, to fix stale information or to create new topics.<br /> * '''Test framework.''' Do you know how the test framework works? Can you write your own test code? Please read [https://www.nsnam.org/docs/release/3.37/manual/html/tests.html this documentation].<br /> * '''gdb and valgrind.''' Can you run your code through gdb and valgrind? Can you run your tests through that?<br /> <br /> == Planning ==<br /> <br /> Some advice:<br /> * Refine your plan of what you want to accomplish. The plan should start out slow with some low-risk, easy to accomplish milestones, and work towards harder milestones. It is really important to think and revisit these three issues:<br /> ** '''Scope.''' What use cases should your code support, and what is specifically out of scope, when you are done with your project?<br /> ** '''Usability.''' How do you expect users to use your code? What kind of API would users find the most natural and easiest to work with? Is it extensible by future developers?<br /> ** '''Testing.''' How can you test that your code works as expected? What tests should your code pass when it is done? <br /> * Decompose your project into small mergeable chunks. A good workflow would be to code something new, test it, document it, post for review, and iterate. If you don't accomplish all of your technical goals because you run out of time, make sure that what you have done is mergeable (i.e. it is better to accomplish 50% of your goals, with documentation and testing completed, than 80% or 100% of your goals that does not have good documentation and testing. The latter will not be merged.)<br /> * Commit early, commit often. This will make it easier for your mentors to track your progress.<br /> <br /> [[Category:GSoC]]</div>

Tommaso https://www.nsnam.org/mediawiki/index.php?title=GSOC2026ApplicationTemplate&diff=13768 2026-02-21T10:51:13Z

<p>Tommaso: </p> <hr /> <div>{{TOC}}<br /> <br /> &lt;blockquote&gt;<br /> * [[GSOC2026ContributorGuide | ns-3's GSoC Contributor guide]]<br /> * [[GSOCMentorGuide | ns-3's GSoC Mentor guide]]<br /> * ''Get in contact with the ns-3 team'': [https://groups.google.com/g/ns-developers Google group] | ''Zulip'' https://ns-3.zulipchat.com<br /> &lt;/blockquote&gt;<br /> <br /> = Student Application Template =<br /> <br /> The following are specific items that the ns-3 team requests GSoC applicants to include in their proposal that is submitted to Google.<br /> <br /> When you apply to Google, you will upload a PDF document with your proposal. This document is what the ns-3 committee will review. Please follow the outline below. We recommend that you create a Google doc and share it privately with your mentors '''throughout the application development''' so that mentors can provide comments and feedback to improve it.<br /> <br /> == About You ==<br /> <br /> &lt;blockquote&gt;<br /> === Identity Information ===<br /> * ''Name''. Your name<br /> * ''Email''. Your contact email<br /> * ''Country''. Your country of citizenship<br /> * ''Institution''. Accredited institution where you are enrolled as student (college, university, master program, PhD program, undergraduate program, etc), if applicable.<br /> * ''Advisor''. (if applicable). Is your research work supervised by a professor or research group? <br /> <br /> === Patch Requirement ===<br /> <br /> Provide a URL to a repository (or pointer to publicly available commits, or a GitLab snippet, or email one of the org admins, with a patch that satisfies your patch requirement for your application to ns-3. Completion of either the [[GSOC2025PatchRequirement | suggested patch assignment]] or a comparable code submission is *mandatory*. Some project ideas have project-specific patch requirements (check with the mentor about it).<br /> <br /> '''Note:''' If you opt to provide a patch to the problem described in the patch requirement, keep your solution private by pasting the link to your code in your application to Google, not posting it on the mailing list or submitting a GitLab.com merge request.<br /> <br /> === Background ===<br /> <br /> ==== Education and Skills ====<br /> Include your academic background and skills related to data networking, as well as any software experience with C++ and/or Python.&lt;br/&gt;<br /> <br /> ==== Work ====<br /> Be sure to denote any work experience you have in relevant areas.&lt;br/&gt;<br /> Your past work experience does not need to be a job where you got paid, you can mention any projects you have participated in.&lt;br/&gt;<br /> <br /> ==== Experience with ns-3 ====<br /> Do you have any experience with ns-3? Do you have any experience working on the ns-3 source code? If you have published code on GitHub or GitLab, link to it here.<br /> <br /> ==== Open-source experience ====<br /> Do you have any prior experience working on open-source software? If you have published code on GitHub or GitLab, link to it here.<br /> <br /> ==== Research ====<br /> Make sure to denote any research experience you have in relevant areas.<br /> <br /> === Why you? ===<br /> Why are you the best candidate for the project you're applying for? Why are you interested in it? How does it align with your future plans?<br /> <br /> &lt;/blockquote&gt;<br /> <br /> == About The Project ==<br /> <br /> &lt;blockquote&gt;<br /> === Project Title, Size, and Summary ===<br /> <br /> Pick an appropriate project title, and try to summarize in one sentence what the project plans to accomplish.<br /> <br /> Highlight if you are applying for a small sized project (90 hours), medium sized project (175 hours) or a large project (350 hours).<br /> <br /> === User-visible changes ===<br /> <br /> Explain what new or repaired capability will be available to users once the project is completed. Be as specific as possible, and describe in terms of what the user will see-- not how it will be implemented. Both a qualitative description of the enhancement and sample C++ or Python API that users would use would be appropriate here.&lt;br/&gt; <br /> What kind of working examples would be provided?&lt;br/&gt;<br /> What documentation will need to be written?&lt;br/&gt;<br /> <br /> === Test plan ===<br /> <br /> How will any new code be tested?&lt;br/&gt;<br /> What test cases could be written now that would fail (produce incorrect output) but would succeed at the completion of the project?&lt;br/&gt;<br /> Are there any performance concerns that must be tested, and how?&lt;br/&gt;<br /> How will you guard against user error (misconfiguration)?&lt;br/&gt;<br /> How will you convince a skeptic that the implementation works correctly?<br /> <br /> === Approach ===<br /> What is your technical plan for achieving the goals of the project?&lt;br/&gt;<br /> What components and functionality will have to be developed, integrated etc.?&lt;br/&gt;<br /> Which development methodology or strategy would you use?&lt;br/&gt;<br /> <br /> === Plan ===<br /> Provide a plan of how the project will be completed within the timeframe of GSoC (175 hours for medium project, 350 hours for large project). It may be useful to break this down into two phases. Try to isolate the project's main features, group them into coherent units, and list them as 'milestones' or 'deliverables'. Make sure you consider the time you will need to document, test, write examples, respond to reviewers comments, and fix your code after every deliverable is finished.<br /> <br /> === Commitments ===<br /> Do you have any other commitments over the summer that would impair your ability to participate in the project, e.g., classes, thesis defense, existing work commitments, etc? <br /> &lt;/blockquote&gt;<br /> <br /> == Code of conduit ==<br /> <br /> &lt;blockquote&gt;<br /> === General ===<br /> Acknowledge that, during the project, you will follow the general ns-3 policies, available at https://www.nsnam.org/about/governance/policies/<br /> <br /> === AI use ===<br /> Disclose if you did you use any AI tools to draft the proposal, and if you did, explain for what parts and to what extent.<br /> <br /> &lt;/blockquote&gt;<br /> <br /> Of these, the Approach and Plan elements will require significant thought, development, and discussion. Applicants are advised to bring their ideas to the ns-developers list or Zulip chat and open up a discussion with the ns-3 team or with one of the listed mentors to develop these portions of their application prior to submission. Only applications that have well refined and developed technical objectives and plans are likely to be competitive. The ns-3 team will provide comments and help refine proposals somewhat after they are initially submitted, but obviously the stronger they start the stronger they will be. Also understand that the better you plan your project by discussing it on the list, the more clearer your path will seem through the summer. In all our previous editions of GSoC, our strongest and most successful proposals were those which had been discussed at length beforehand on the mailing list and on Zulip.<br /> <br /> In addition, once GSoC proposals have been accepted and reviewed, promising candidates may be invited to virtually meet some of the ns-3 team and discuss their project further in a chat or other online meeting.<br /> <br /> [[Category:GSoC]]</div>

Tommaso https://www.nsnam.org/mediawiki/index.php?title=GSOC2026ApplicationTemplate&diff=13767 2026-02-21T10:50:50Z

<p>Tommaso: Created page with &quot;{{TOC}} &lt;blockquote&gt; * ns-3's GSoC Contributor guide * ns-3's GSoC Mentor guide * ''Get in contact with the ns-3 team'': [https://groups.google.com/g/ns-developers Google group] | ''Zulip'' https://ns-3.zulipchat.com &lt;/blockquote&gt; = Student Application Template = The following are specific items that the ns-3 team requests GSoC applicants to include in their proposal that is submitted to Google. When you apply to G...&quot;</p> <hr /> <div>{{TOC}}<br /> <br /> &lt;blockquote&gt;<br /> * [[GSOC2025ContributorGuide | ns-3's GSoC Contributor guide]]<br /> * [[GSOCMentorGuide | ns-3's GSoC Mentor guide]]<br /> * ''Get in contact with the ns-3 team'': [https://groups.google.com/g/ns-developers Google group] | ''Zulip'' https://ns-3.zulipchat.com<br /> &lt;/blockquote&gt;<br /> <br /> = Student Application Template =<br /> <br /> The following are specific items that the ns-3 team requests GSoC applicants to include in their proposal that is submitted to Google.<br /> <br /> When you apply to Google, you will upload a PDF document with your proposal. This document is what the ns-3 committee will review. Please follow the outline below. We recommend that you create a Google doc and share it privately with your mentors '''throughout the application development''' so that mentors can provide comments and feedback to improve it.<br /> <br /> == About You ==<br /> <br /> &lt;blockquote&gt;<br /> === Identity Information ===<br /> * ''Name''. Your name<br /> * ''Email''. Your contact email<br /> * ''Country''. Your country of citizenship<br /> * ''Institution''. Accredited institution where you are enrolled as student (college, university, master program, PhD program, undergraduate program, etc), if applicable.<br /> * ''Advisor''. (if applicable). Is your research work supervised by a professor or research group? <br /> <br /> === Patch Requirement ===<br /> <br /> Provide a URL to a repository (or pointer to publicly available commits, or a GitLab snippet, or email one of the org admins, with a patch that satisfies your patch requirement for your application to ns-3. Completion of either the [[GSOC2025PatchRequirement | suggested patch assignment]] or a comparable code submission is *mandatory*. Some project ideas have project-specific patch requirements (check with the mentor about it).<br /> <br /> '''Note:''' If you opt to provide a patch to the problem described in the patch requirement, keep your solution private by pasting the link to your code in your application to Google, not posting it on the mailing list or submitting a GitLab.com merge request.<br /> <br /> === Background ===<br /> <br /> ==== Education and Skills ====<br /> Include your academic background and skills related to data networking, as well as any software experience with C++ and/or Python.&lt;br/&gt;<br /> <br /> ==== Work ====<br /> Be sure to denote any work experience you have in relevant areas.&lt;br/&gt;<br /> Your past work experience does not need to be a job where you got paid, you can mention any projects you have participated in.&lt;br/&gt;<br /> <br /> ==== Experience with ns-3 ====<br /> Do you have any experience with ns-3? Do you have any experience working on the ns-3 source code? If you have published code on GitHub or GitLab, link to it here.<br /> <br /> ==== Open-source experience ====<br /> Do you have any prior experience working on open-source software? If you have published code on GitHub or GitLab, link to it here.<br /> <br /> ==== Research ====<br /> Make sure to denote any research experience you have in relevant areas.<br /> <br /> === Why you? ===<br /> Why are you the best candidate for the project you're applying for? Why are you interested in it? How does it align with your future plans?<br /> <br /> &lt;/blockquote&gt;<br /> <br /> == About The Project ==<br /> <br /> &lt;blockquote&gt;<br /> === Project Title, Size, and Summary ===<br /> <br /> Pick an appropriate project title, and try to summarize in one sentence what the project plans to accomplish.<br /> <br /> Highlight if you are applying for a small sized project (90 hours), medium sized project (175 hours) or a large project (350 hours).<br /> <br /> === User-visible changes ===<br /> <br /> Explain what new or repaired capability will be available to users once the project is completed. Be as specific as possible, and describe in terms of what the user will see-- not how it will be implemented. Both a qualitative description of the enhancement and sample C++ or Python API that users would use would be appropriate here.&lt;br/&gt; <br /> What kind of working examples would be provided?&lt;br/&gt;<br /> What documentation will need to be written?&lt;br/&gt;<br /> <br /> === Test plan ===<br /> <br /> How will any new code be tested?&lt;br/&gt;<br /> What test cases could be written now that would fail (produce incorrect output) but would succeed at the completion of the project?&lt;br/&gt;<br /> Are there any performance concerns that must be tested, and how?&lt;br/&gt;<br /> How will you guard against user error (misconfiguration)?&lt;br/&gt;<br /> How will you convince a skeptic that the implementation works correctly?<br /> <br /> === Approach ===<br /> What is your technical plan for achieving the goals of the project?&lt;br/&gt;<br /> What components and functionality will have to be developed, integrated etc.?&lt;br/&gt;<br /> Which development methodology or strategy would you use?&lt;br/&gt;<br /> <br /> === Plan ===<br /> Provide a plan of how the project will be completed within the timeframe of GSoC (175 hours for medium project, 350 hours for large project). It may be useful to break this down into two phases. Try to isolate the project's main features, group them into coherent units, and list them as 'milestones' or 'deliverables'. Make sure you consider the time you will need to document, test, write examples, respond to reviewers comments, and fix your code after every deliverable is finished.<br /> <br /> === Commitments ===<br /> Do you have any other commitments over the summer that would impair your ability to participate in the project, e.g., classes, thesis defense, existing work commitments, etc? <br /> &lt;/blockquote&gt;<br /> <br /> == Code of conduit ==<br /> <br /> &lt;blockquote&gt;<br /> === General ===<br /> Acknowledge that, during the project, you will follow the general ns-3 policies, available at https://www.nsnam.org/about/governance/policies/<br /> <br /> === AI use ===<br /> Disclose if you did you use any AI tools to draft the proposal, and if you did, explain for what parts and to what extent.<br /> <br /> &lt;/blockquote&gt;<br /> <br /> Of these, the Approach and Plan elements will require significant thought, development, and discussion. Applicants are advised to bring their ideas to the ns-developers list or Zulip chat and open up a discussion with the ns-3 team or with one of the listed mentors to develop these portions of their application prior to submission. Only applications that have well refined and developed technical objectives and plans are likely to be competitive. The ns-3 team will provide comments and help refine proposals somewhat after they are initially submitted, but obviously the stronger they start the stronger they will be. Also understand that the better you plan your project by discussing it on the list, the more clearer your path will seem through the summer. In all our previous editions of GSoC, our strongest and most successful proposals were those which had been discussed at length beforehand on the mailing list and on Zulip.<br /> <br /> In addition, once GSoC proposals have been accepted and reviewed, promising candidates may be invited to virtually meet some of the ns-3 team and discuss their project further in a chat or other online meeting.<br /> <br /> [[Category:GSoC]]</div>

Tommaso https://www.nsnam.org/mediawiki/index.php?title=Summer_Projects&diff=13758 2026-02-19T09:29:47Z

<p>Tommaso: /* Google Summer of Code 2025 */</p> <hr /> <div>{{TOC}}<br /> <br /> The project coordinates a few summer coding programs in which student developers are paired with mentors to produce code over the summer.<br /> <br /> = Google Summer of Code 2026 =<br /> <br /> The organizational admins are Tommaso Pecorella, and Mohit Tahiliani.<br /> <br /> * [[GSOC2026Projects | Project Ideas Page]]<br /> * [[GSOC2026ContributorGuide | ns-3's GSoC Contributor Guide]]<br /> <br /> = Google Summer of Code 2025 =<br /> <br /> We are happy to announce that the following five projects have been accepted:<br /> <br /> * '''David Lin''', [[GSOC2025AqmEvaluation | Upgrade the AQM Evaluation Suite for ns-3]], mentored by Mohit P. Tahiliani, Aniket Singh and Tom Henderson<br /> * '''Aditya Ruhela''', [[GSOC2025IcmpSocket | ICMP socket and generate/handle ICMP messages (host/net unreachable)]], mentored by Tommaso Pecorella and Alberto Gallegos Ramonet<br /> * '''Boh Jie Qi''', [[GSOC20256LoWPAN | 6LoWPAN Neighbor Discovery Protocol]], mentored by Tommaso Pecorella and Adnan Rashid<br /> * '''Shashwat Patni''', [[GSOC2025Ipv6GlobalRouting | IPv6 Global Routing]], mentored by Tommaso Pecorella and Manoj Kumar Rana<br /> * '''Thiago Miyazaki''', [[GSOC2025Ntn | NTN Helper and a LEO example for 5G NR]], mentored by Gabriel Ferreira and Amir Ashtari Gargari<br /> <br /> * [[GSOC2025Projects | Project Ideas Page]]<br /> * [[GSOC2025ContributorGuide | ns-3's GSoC Contributor Guide]]<br /> <br /> = Google Summer of Code 2024 =<br /> <br /> The organizational admins were Tommaso Pecorella, Mohit Tahiliani, and Tom Henderson.<br /> <br /> We had three successful student projects, summarized on the pages linked below:<br /> <br /> * '''Joao Albuquerque''', [[GSOC2024Channels5G | 5G NR Module Benchmark and Analysis for Distinct Channel Models]], mentored by Biljana Bojovic, Amir Ashtari, and Gabriel Ferreira: '''''[[GSOC2024Channels5GFinalReport | Final report]]'''''<br /> * '''Kavya Bhat''', [[GSOC2024DHCPv6 | DHCPv6]], mentored by Tommaso Pecorella, Alberto Gallegos Ramonet, and Manoj Kumar Rana: '''''[[GSOC2024DHCPv6FinalReport | Final report]]'''''<br /> * '''Hyerin Kim''', [[GSOC2024RLUsability5G | Enhancement of RL Approach Accessibility in NR]], mentored by Katerina Koutlia, Amir Ashtari, Biljana Bojovic, and Gabriel Ferreira: '''''[[GSOC2024RLUsability5GFinalReport | Final report]]'''''<br /> <br /> * [[GSOC2024Projects | Project Ideas Page]]<br /> * [[GSOC2024ContributorGuide | ns-3's GSoC Contributor Guide]]<br /> <br /> = Google Summer of Code 2023 =<br /> <br /> The organizational admins were Tommaso Pecorella, Mohit Tahiliani, and Tom Henderson.<br /> <br /> We had three successful student projects for 2023; you can read their final reports below:<br /> <br /> * '''Giovanni Grieco''', [[GSOC20235GUsability | IUNS-3 5G NR: Improving the Usability of ns-3's 5G NR Module]], mentored by Tom Henderson, Katerina Koutlia, and Biljana Bojovic: '''''[[GSOC20235GUsabilityFinalReport | Final report]]'''''<br /> * '''Raghuram Kannan''', [[GSOC2023NetAnim | Dynamic device registration for NetAnim simulation animations]], mentored by Tommaso Pecorella and Manoj Kumar Rana: '''''[[GSOC2023NetAnimFinalReport | Final report]]'''''<br /> * '''Muyuan Shen''', [[GSOC2023ns3-ai | ns3-ai enhancements]], mentored by Collin Brady and Hao Yin: '''''[[GSOC2023ns3-aiFinalReport | Final report]]'''''<br /> <br /> We reviewed seven proposals, which were evaluated by a committee that includes most of the mentors listed on the Project Ideas page. For future reference, below is our ideas page and contributor's guide.<br /> <br /> * [[GSOC2023Projects | Project Ideas Page]]<br /> * [[GSOC2023ContributorGuide | ns-3's GSoC Contributor Guide]]<br /> <br /> = Google Summer of Code 2022 =<br /> <br /> The organizational admins were Tommaso Pecorella, Mohit Tahiliani, and Tom Henderson.<br /> <br /> Two contributors completed projects with ns-3 in the 2022 Google Summer of Code.<br /> <br /> * '''Matteo Pagin''', [[GSOC2022Channel | A simplified channel and beamforming model for ns-3]], mentored by Sandra Lagen, Biljana Bojovic, and Michele Polese '''''[https://pagmatt.github.io/blog/2022/gsoc2022 Final Report]'''''<br /> * '''Zhiheng Dong''', [[GSOC2022PerfectArp | Perfect ARP and NDP]], mentored by Tommaso Pecorella, Ameya Deshpande,and Manoj Kumar Rana '''''[[GSOC2022NeighborCacheFinalReport | Final Report]]'''''<br /> <br /> One additional project was started but did not progress past the midterm evaluation:<br /> <br /> * '''Akash Mondal''', [[GSOC2022TCPMaximumSegmentSize | TCP maximum segment size (MSS) improvements]], mentored by Mohit Tahiliani, Bhaskar Kataria, and Vivek Jain<br /> <br /> We received seven proposals, which were evaluated by a committee that includes most of the mentors listed on the Project Ideas page. For future reference, below is our ideas page and contributor's guide.<br /> <br /> * [[GSOC2022Projects | Project Ideas Page]]<br /> * [[GSOC2022ContributorGuide | ns-3's GSoC Contributor Guide]]<br /> <br /> = ns-3 Summer of Code 2022 =<br /> <br /> ns-3 Summer of Code (NSoC) is a program that runs in parallel to Google Summer of Code. Unlike GSoC, it is not funded, but we aim to operate it similarly to GSoC. <br /> <br /> * '''Chandrakant Jena,''' ''Ping and Ping6 Enhancements for ns-3:'' '''''[[NSOC2022Ping | project wiki page ]]''''' mentored by Tommaso Pecorella and Tom Henderson<br /> <br /> The project by Chandrakant was completed successfully in December 2022, with six commits made to ns-3-dev starting with [https://gitlab.com/nsnam/ns-3-dev/-/commit/da107e04eeb0c12631eadda6a30ad1a33b7f0931 commit da107e04]. The project added a '''[https://www.nsnam.org/docs/doxygen/d6/dbe/classns3_1_1_ping.html new Ping application]''', helper class, example program, unit test, and [https://www.nsnam.org/docs/models/html/internet-apps.html#ping documentation].<br /> <br /> = Google Summer of Code 2021 =<br /> <br /> Three students successfully completed projects in [https://summerofcode.withgoogle.com/organizations/4672908493848576/ Google Summer of Code 2021].<br /> <br /> * '''Parth Pratim Chatterjee,''' ''Direct Code Execution Modernization:'' '''''[[GSOC2021DCE | project wiki page]]''''' '''--''' '''''[https://ns-3-dce-linux-upgrade.github.io/ Final report]'''''<br /> * '''Ameya Deshpande,''' ''IPv6 Nix-Vector Routing:'' '''''[[GSOC2021NixVector | project wiki page]]''''' '''--''' '''''[https://www.nsnam.org/wiki/GSOC2021NixVectorFinalReport Final report]'''''<br /> * '''Akshit Patel,''' ''Add logging support to Simulation Execution Manager (SEM):'' '''''[[GSOC2021SEM | project wiki page]]''''' '''--''' '''''[https://akshitpatel01.github.io/GSoC-2021-Report/ Final report]'''''<br /> <br /> For reference, below were the 2021 project ideas and the 2021 student guide:<br /> <br /> * [[GSOC2021StudentGuide | Student Guide]]<br /> * [[GSOC2021Projects | Project Ideas Page]]<br /> <br /> = ns-3 Summer of Code 2021 =<br /> <br /> ns-3 Summer of Code (NSoC) is a program that runs in parallel to Google Summer of Code. Unlike GSoC, it is not funded, but we aim to operate it similarly to GSoC. The commitments are similar; students and mentors are expected to define and work towards a mergeable project goal by the end of the summer. The program is offered to 'honorable mention' GSoC proposals (i.e., proposals that we would have selected had we received more student slots from Google) and for other reasons such as a contributor's ineligibility for GSoC.<br /> <br /> * '''Nitya Chandra,''' ''Enable IPv6 support for ad-hoc routing protocols in ns-3:'' '''''[[NSOC2021Ipv6 | project wiki page ]]''''' '''Note: project did not complete'''<br /> <br /> = Google Summer of Code 2020 =<br /> <br /> Four students successfully completed [https://summerofcode.withgoogle.com/ Google Summer of Code 2020] projects:<br /> <br /> * '''Shivamani Patil,''' ''App Store Improvements:'' '''''[https://shivamanipatil.github.io/gsoc-2020-report/ final report], [[GSOC2020AppStore | project wiki page]]'''''<br /> * '''Ananthakrishan S,''' ''NetDevice up/down consistency and event chain:'' '''''[https://ananthu-dev.github.io/net-device-consistency-gsoc-2020/ final report], [[GSOC2020NetDevice | project wiki page]]'''''<br /> * '''Bhaskar Kataria,''' ''SCE AQMs and TCP along with CNQ-CodelAF and LFQ'' '''''[https://bhaskar792.github.io/GSoC-2020-Report/ final report], [[GSOC2020AQM | project wiki page]]'''''<br /> * '''Deepak K,''' ''TCP Prague model for ns-3'', '''''[https://deepakkavoor.github.io/gsoc-2020-prague/ final report], [[GSOC2020Prague | project wiki page]]'''''<br /> <br /> For reference, below were the 2020 project ideas and the 2020 student guide:<br /> <br /> * [[GSOC2020StudentGuide | Student Guide]]<br /> * [[GSOC2020Projects | Project Ideas Page]]<br /> <br /> = ns-3 Summer of Code 2020 =<br /> <br /> These projects are unfunded but are mentored in a manner similar to GSoC, at a lesser pace than the 12-week GSoC program.<br /> <br /> * Muhammad Iqbal Rochman, [[NSOC2020WifiPHY | Wi-Fi PHY Restructure]] '''Note:''' This project successfully completed.<br /> * Harsha Sharma, [[NSOC2020L4SEvaluation | L4S evaluation framework]] '''Note:''' This project continued through fall 2020 but did not yet merge.<br /> * Rahul Bothra, [[NSOC2020Routing | Routing for community wireless networks]] '''Note:''' Project discontinued in August 2020.<br /> <br /> = Google Summer of Code 2019 =<br /> <br /> ns-3 participated in Google Summer of Code 2019 with four student projects:<br /> <br /> * Apoorva Bhargava, [[GSOC2019TCPTestingAndAlignment | Testing and Alignment of ns-3 TCP with Linux TCP]]<br /> * Mishal Shah, [[GSOC2019AppStore | Improving the ns-3 AppStore and linking with bake]]<br /> * Tommaso Zugno, [[GSOC2019ThreeGPPChannel | Integration of the 3GPP TR 38.901 channel model in the ns-3 spectrum module]]<br /> * Liangcheng Yu, [[GSOC2019DCN | Framework of Studying Flow Completion Time Minimization for Data Center Networks in ns-3]]<br /> <br /> Below are project ideas and the 2019 student guide:<br /> <br /> * [[GSOC2019StudentGuide | ns-3 GSoC student guide]]<br /> * [[GSOC2019Projects | Project Ideas Page]]<br /> <br /> = European Space Agency Summer of Code in Space (SOCIS) 2019 =<br /> <br /> ns-3 ultimately was not selected for funding for SOCIS 2019. Below is an archive of our student guide, for future reference.<br /> <br /> * [[SOCIS2019 | ns-3 SOCIS student guide]]<br /> <br /> = Google Summer of Code 2018 =<br /> <br /> ns-3 participated in the 2018 edition of Google Summer of Code, with five students:<br /> <br /> * WenYing Dai, [[GSOC2018AccECN_ECN++ | Implementation of AccECN and ECN++ in ns-3]]<br /> * Muhammad Iqbal CR, [[GSOC2018Coexistence | Merging and Improvement of LTE and Wi-Fi Coexistence Module]]<br /> * Sourabh Jain, [[GSoC2018_DCE_Upgrade | Direct Code Execution upgrade]]<br /> * Davide Magrin, [[GSoC2018:_A_Simulation_Execution_Manager_for_ns-3 | A simulation execution manager for ns-3]]<br /> * Jude Niroshan, [[GSoC2018:Trust-based_routing_protocols_framework | Trust-based routing protocols framework]]<br /> <br /> * [[GSOC2018Projects | Project Ideas Page]]<br /> * [[GSOC2018StudentGuide | Student Application Guide]]<br /> <br /> = European Space Agency Summer of Code in Space (SOCIS) 2017 =<br /> <br /> ns-3 has been accepted to the 2017 ESA Summer of Code in Space, with student Pasquale Imputato (mentored by Tommaso Pecorella). The project successfully completed in October 2017 (details in the below wiki project page).<br /> <br /> * [[SOCIS2017 | project page]]<br /> * [https://codereview.appspot.com/330220043/ Final code review]<br /> <br /> The original project ideas page is posted below.<br /> <br /> * [[SOCIS2017Projects#Project_Ideas | Project Ideas page]]<br /> <br /> = Google Summer of Code 2017 =<br /> <br /> ns-3 was fortunate to mentor five outstanding students for the 2017 edition of [https://developers.google.com/open-source/gsoc/ Google Summer of Code].<br /> <br /> * [[GSOC2017AcceptedProjects | Accepted Projects]]<br /> == Final reports ==<br /> * [http://mailman.isi.edu/pipermail/ns-developers/2017-August/013916.html ns-3 App Store] by Abhijith Anilkumar<br /> * [https://www.nsnam.org/wiki/GSOC2017Lte#Project_summary Enabling LTE CA handover to secondary cell] by Alexander Krotov<br /> * [http://mailman.isi.edu/pipermail/ns-developers/2017-September/013929.html TCP Prague] by Shravya Ks<br /> * [http://mailman.isi.edu/pipermail/ns-developers/2017-September/013918.html LTE and IPv6 support] by Manoj Kumar Rana<br /> * [http://mailman.isi.edu/pipermail/ns-developers/2017-September/013921.html TBF and HHF] by Surya Seetharaman<br /> <br /> == Phase 2 reports ==<br /> * [http://mailman.isi.edu/pipermail/ns-developers/2017-July/014038.html BCube and FatTree topology helpers (component of TCP Prague project)]<br /> * [http://mailman.isi.edu/pipermail/ns-developers/2017-August/014054.html Implementation of TBF and HHF]<br /> * [http://mailman.isi.edu/pipermail/ns-developers/2017-July/014047.html Enabling LTE CA handover to secondary cell, Phase 2]<br /> * [http://mailman.isi.edu/pipermail/ns-developers/2017-July/014042.html ns-3 App Store]<br /> * [http://mailman.isi.edu/pipermail/ns-developers/2017-July/014049.html Mobile IPv6 implementation with LTE support (report)]<br /> * [http://mailman.isi.edu/pipermail/ns-developers/2017-August/014058.html Mobile IPv6 implementation with LTE support (review request)]<br /> == Phase 1 reports ==<br /> * [http://mailman.isi.edu/pipermail/ns-developers/2017-June/013980.html Data Center TCP (component of TCP Prague project)]<br /> * [http://mailman.isi.edu/pipermail/ns-developers/2017-June/013982.html Implementation of TBF and HHF traffic control]<br /> * [http://mailman.isi.edu/pipermail/ns-developers/2017-June/013983.html Enabling LTE CA handover to secondary cell, Phase 1]<br /> * [http://mailman.isi.edu/pipermail/ns-developers/2017-June/013985.html ns-3 App Store]<br /> * [http://mailman.isi.edu/pipermail/ns-developers/2017-June/013987.html Mobile IPv6 implementation with LTE support]<br /> == Background ==<br /> Below is some information that was used during the application phase.<br /> <br /> * [[GSOC2017Projects | Project Ideas Page]]<br /> * [[GSOC2017StudentGuide | Student Application Guide]]<br /> <br /> = European Space Agency Summer of Code in Space (SOCIS) 2016 =<br /> <br /> ns-3 had one student (Michael Di Perna) successfully complete the 2016 [http://sophia.estec.esa.int/socis/ ESA Summer of Code in Space]. <br /> <br /> * [[SOCIS2016 | Project page]] for Optical Satellite Systems project<br /> * [[SOCIS2016Projects#Project_Ideas | Project Ideas page]]<br /> <br /> = Mentored summer projects 2016 =<br /> <br /> ns-3 maintainers will mentor additional summer projects (that students will work on using their own sources of funding) on a best-effort basis. Students interested in this option should review the GSoC or SOCIS ideas page, or propose their own.<br /> <br /> * See [[MentoredProjects2016]]<br /> <br /> = Google Summer of Code 2016 =<br /> <br /> ns-3 was not selected for the 2016 [https://developers.google.com/open-source/gsoc/ Google Summer of Code]. We mentored two summer projects outside of GSoC. Below were our materials prepared for our GSoC organizational application.<br /> * [[GSOC2016Projects | Project ideas page]]<br /> * [[GSOCStudentGuide | Student guide]]<br /> <br /> = Google Summer of Code 2015 =<br /> <br /> ns-3 was selected to participate in the 2015 [http://www.google-melange.com/gsoc/homepage/google/gsoc2015 Google Summer of Code]. More information can be found on our Project Ideas page and our Student Guide.<br /> <br /> * [[GSOC2015AcceptedProjects | Accepted projects]]<br /> * [[GSOC2015Projects | Project ideas page]]<br /> * [[GSOC2015StudentGuide | Student guide]]<br /> <br /> This year's students were announced on April 27, and all four successfully completed the program:<br /> <br /> * Melchiorre Danilo Abrignani, [[GSOC2015LTECA | Carrier Aggregation support for the LTE module]]<br /> * Matthieu Coudron, [[GSOC2015MpTcpImplementation | Implementing multipath TCP (MPTCP) in ns3]]<br /> * Natale Patriciello, [[GSOC2015TCPTest | TCP layer refactoring with automated test on RFC compliance and validation]]<br /> * Vishwesh Rege, [[GSOC2015LrWpanMac | 802.15.4 realistic MAC and Energy Model]]<br /> <br /> = European Space Agency Summer of Code in Space (SOCIS) 2015 =<br /> <br /> ns-3 has been accepted to the 2015 [http://sophia.estec.esa.int/socis2015/ ESA Summer of Code in Space]. The ns-3 project had one student in SOCIS in each of 2013, 2014 and 2015. However, the satellite channel models project for 2015 [[SOCIS2015 | Satellite channel models]] did not successfully complete.<br /> <br /> * [[SOCIS2015Projects | Project ideas page]] (for reference)<br /> <br /> = Mentored summer projects =<br /> <br /> ns-3 maintainers will mentor additional summer projects (that students will work on using their own sources of funding) on a best-effort basis. Students interested in this option should review the GSoC or SOCIS ideas page, or propose their own.<br /> <br /> We have one such mentored project in 2015:<br /> <br /> * Saswat Mishra, [[NeighborDiscoveryProject | Neighbor Discovery enhancements]]<br /> <br /> = Past summer projects =<br /> <br /> * [[GSOC2014AcceptedProjects | GSoC 2014 Accepted Projects]]<br /> * [[SOCIS2014TCP | SOCIS 2014 Accepted Project]]<br /> * [[MentoredProjects2014 | 2014 Mentored Projects]]<br /> * [[SOCIS2013BundleProtocolProject | SOCIS 2013 Accepted Project]]<br /> * [[GSOC2013AcceptedProjects | GSoC 2013 Accepted Projects]]<br /> * [[GSOC2012AcceptedProjects |GSoC 2012 Accepted Projects]]<br /> * [[NSOC2011AcceptedProjects |NSoC 2011 Accepted Projects]]<br /> * [[GSOC2010AcceptedProjects |GSoC 2010 Accepted Projects]]<br /> * [[GSOC2009AcceptedProjects |GSoC 2009 Accepted Projects]]<br /> * [https://developers.google.com/open-source/soc/2008/?csw=1#ns3 GSoC 2008 Accepted Projects]</div>

Tommaso https://www.nsnam.org/mediawiki/index.php?title=GSOC2026Projects&diff=13755 2026-02-12T02:12:41Z

<p>Tommaso: /* Internet models enhancements */</p> <hr /> <div>{{TOC}}<br /> <br /> This page contains 2026 Google Summer of Code project ideas for ns-3.<br /> <br /> * [https://developers.google.com/open-source/gsoc/faq GSoC Frequently Asked Questions]<br /> * [[GSOC2026ContributorGuide | ns-3's 2026 GSoC Contributor guide]]<br /> * [https://developers.google.com/open-source/gsoc/resources/guide GSoC contributor/student guide (not ns-3 specific)]<br /> * [[GSOC2025ApplicationTemplate | 2026 GSoC Contributor application template]]<br /> * [[GSOCMentorGuide | ns-3's GSoC Mentor guide]]<br /> * [https://archive.flossmanuals.net/gsocmentoring/index.html GSoC Mentor guide (not ns-3 specific)]<br /> * [[GSOCSelectionProcess | GSoC Contributor Selection Process]]<br /> * ''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/<br /> <br /> === About the ns-3 project ===<br /> <br /> ns-3 is a discrete-event network simulator, with a particular emphasis on network research and education.<br /> <br /> 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.<br /> <br /> 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.<br /> <br /> === Org admins ===<br /> <br /> 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].<br /> <br /> === Mentors ===<br /> <br /> 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.<br /> <br /> The current list of prospective mentors can be found among the ideas listed below.<br /> <br /> === How to apply ===<br /> <br /> For students or contributors interested in applying to ns-3 for GSoC, please go through the following list to get started:<br /> * Read the official [https://developers.google.com/open-source/gsoc/resources/guide GSoC contributor guide].<br /> * Read [[GSOC2026ContributorGuide |ns-3's 2026 GSoC contributor guide]]<br /> * Look through our [[#Project Ideas]] below to see if you find a project that interests you.<br /> * Review the [https://www.nsnam.org/documentation/development-tree/ tutorial and contributing guide] thoroughly, if you have not already done so.<br /> * 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.<br /> * Next, proceed to get in touch with the developers on the mailing list or Zulip chat room and refine your proposal.<br /> * 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.<br /> <br /> 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.<br /> <br /> &lt;blockquote&gt;<br /> Each project idea within a particular priority has been tagged with the following properties:<br /> * ''Required Experience:'' Languages, concepts, or packages with which applicants must be familiar.<br /> * ''Bonus Experience:'' Other experience or familiarity which would be greatly helpful to applicants for this project.<br /> * ''Interests:'' Areas of particular relevance to this project, and an indicator of where successful contributors might apply their experiences coming out of this project.<br /> * ''Difficulty:'' easy, medium or difficult<br /> * ''Recommended reading:'' pointers to documentation, papers, specific bugs, etc.<br /> <br /> 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.<br /> &lt;/blockquote&gt;<br /> <br /> === Patch requirement guidelines ===<br /> <br /> 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.<br /> <br /> === Mentors: how to participate ===<br /> <br /> 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:<br /> <br /> * 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.<br /> * 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.<br /> * 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.<br /> <br /> == Project Ideas ==<br /> <br /> '''Note to contributors:''' These ideas are not listed in any priority order.<br /> 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.<br /> <br /> === Internet models enhancements ===<br /> <br /> * [[#Flent Application API in ns-3]] (small size project, 90h)<br /> * [[#Ping and TraverouteV4 enhancements]] (small size project, 90h)<br /> * [[#Internet routing refactory]] (small size project, 90h)<br /> * [[#AODVv2 Protocol enhancements]] (medium size project, 175h)<br /> * [[#Linux-like CAKE queue discipline for ns-3]] (large size project, 350h)<br /> * [[#Switched Ethernet]] (large size project, 350h)<br /> <br /> === IoT models enhancements ===<br /> <br /> * [[#6LoWPAN mesh-under routing enhancements]] (medium size project, 175h)<br /> * [[#6LoWPAN neighbor discovery protocol]] (medium size project, 175h)<br /> * [[#Mesh Link Establishment (MLE) protocol ]] (large size project, 350h)<br /> <br /> === 5G NR models enhancements ===<br /> <br /> 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.<br /> <br /> * [[#OLLA Link Adaptation and Spec-Compliant TBS Calculation for 5G-LENA]](medium size project, 175h)<br /> * [[#Enabling 5G NR examples visualization]] (medium size project, 175h)<br /> * [[#Energy Consumption Modeling and Power-Aware Extensions for 5G-LENA]](medium size project, 250h)<br /> * [[#5G NR module integration with ns-3-ai]] (large size project, 250h)<br /> <br /> == Small sized projects (90 hours) ==<br /> <br /> === Flent Application API in ns-3 ===<br /> <br /> Mentors: [mailto:tahiliani.nitk@gmail.com Mohit P. Tahiliani]<br /> <br /> 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.<br /> <br /> * ''Required Experience:'' Familiarity with Flent and C++ programming.<br /> * ''Bonus Experience:'' Familiarity with applications supported in ns-3.<br /> * ''Interests:'' Bufferbloat, TCP, AQM algorithms and ECN.<br /> * ''Difficulty:'' Medium.<br /> * ''Recommended Reading:''<br /> ** Flexible Network Tester [[https://flent.org/flent-the-flexible-network-tester.pdf Paper]] [[https://flent.org/ Tool]]<br /> ** [https://www.nsnam.org/doxygen/d9/dc9/group__applications.html#details Existing Applications in ns-3]<br /> ** [https://gitlab.com/tomhenderson/ns-3-dev/-/commits/flent?ref_type=heads Prior work on Flent application API in ns-3]<br /> <br /> === Internet routing refactory ===<br /> <br /> Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], [TBD].<br /> <br /> 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.<br /> In ns-3 this is accomplished by storing three separate objects, two Ipv[4,6]Address, and one Ipv[4Mask,6Prefix].<br /> <br /> While this is quite simple to implement, this has some notable drawbacks, e.g., the Dst address must be a network address (Dst &amp; ~DstMask == 0), it is not efficient (the mask or prefix could be represented by a simple integer), and more.<br /> In order to improve code readability and consistency between IPv4 and IPv6, !2645 introduces two new classes: Ipv[4,6]NetworkAddress.<br /> <br /> The goal is to refactor the existing routing classes, along with Ipv[4,6]RotingTable classes, so that they use the new classes.<br /> 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.<br /> Another very important requirement will be to break down the work in multiple sub-tasks, so that the merge process can be gradual.<br /> <br /> 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.<br /> <br /> * ''Required Experience:'' Fundamentals of IPv6 addressing and routing, C++ programming.<br /> * ''Interests:'' IPv4 and IPv6 routing<br /> * ''Difficulty:'' Easy.<br /> * ''Recommended reading:''<br /> ** [https://gitlab.com/nsnam/ns-3-dev/-/issues/1239 Issue #1239]<br /> ** [https://gitlab.com/nsnam/ns-3-dev/-/merge_requests/2645 Merge Request !2645]<br /> <br /> Possible tasks to fulfill the patch requirement:<br /> * Use !2645 to modify all or in part the `Rip` protocol.<br /> <br /> === Ping and TraverouteV4 enhancements ===<br /> <br /> Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], [TBD].<br /> <br /> The Ping and TraverouteV4 ns-3 application have some small limitations. <br /> <br /> In particular 2 of them are annoying.<br /> 1. Neither Ping nor TracerouteV4 reacts to ICMP errors or informative messages.<br /> 2. As the name implies, TracerouteV4 is IPv4-only and can't be used on IPv6.<br /> <br /> 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.<br /> <br /> * ''Required Experience:'' Fundamentals of IPv4, IPv6, ICMP, and ICMPv6. C++ programming.<br /> * ''Interests:'' IPv4 and IPv6.<br /> * ''Difficulty:'' Easy.<br /> * ''Recommended reading:''<br /> ** [https://gitlab.com/nsnam/ns-3-dev/-/issues/825 Issue #825]<br /> <br /> Possible tasks to fulfill the patch requirement:<br /> * MR to have Ping react to one ICMP message.<br /> <br /> == Medium sized projects (175 hours) ==<br /> <br /> === 6LoWPAN mesh-under routing enhancements ===<br /> <br /> Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], [TBD].<br /> <br /> 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.<br /> 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.<br /> <br /> The candidate should outline the proposed approach, what parts of code are going to be affected, and how they can be enhanced.<br /> <br /> * ''Required Experience:'' Fundamentals of IPv6 addressing, C++ programming.<br /> * ''Bonus Experience:'' Familiarity with mesh routing and 6LoWPAN ns-3<br /> * ''Interests:'' IPv6 mesh routing<br /> * ''Difficulty:'' Easy.<br /> * ''Recommended reading:''<br /> ** [https://www.nsnam.org/docs/models/html/sixlowpan.html#mesh-under-routing Mesh-under in ns-3 6LoWPAN]<br /> ** [https://datatracker.ietf.org/doc/html/rfc7731 RFC 7731]<br /> ** [https://meshtastic.org/docs/overview/mesh-algo/ Meshtastic controlled flooding]<br /> ** [https://ieeexplore.ieee.org/document/91339 Routing by controlled flooding in communication networks] (if the document can not be accessed, PM the mentors)<br /> <br /> Possible tasks to fulfill the patch requirement:<br /> * 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 &quot;next hop&quot;. The behavior of the actual protocol should be unchanged.<br /> <br /> === 6LoWPAN neighbor discovery protocol ===<br /> <br /> Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], [mailto:adnan.rashid@poliba.it Adnan Rashid].<br /> <br /> 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.<br /> <br /> 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.<br /> <br /> 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.<br /> <br /> * ''Required Experience:'' Fundamentals of IPv6 addressing, C++ programming.<br /> * ''Bonus Experience:'' Familiarity with 6LoWPAN and 6LoWPAN-ND<br /> * ''Interests:'' IPv6 and IoT networks<br /> * ''Difficulty:'' Easy.<br /> * ''Recommended reading:''<br /> ** [https://datatracker.ietf.org/doc/html/rfc8505 RFC 8505]<br /> ** [https://datatracker.ietf.org/doc/html/rfc6775 RFC 6775]<br /> ** [https://datatracker.ietf.org/doc/html/rfc4944 RFC 4944]<br /> ** https://gitlab.com/jieqiboh5836/ns-3-dev/-/tree/6LoWPAN-ND-P1<br /> ** https://gitlab.com/jieqiboh5836/ns-3-dev/-/tree/6LoWPAN-ND-P2<br /> <br /> ===OLLA Link Adaptation and Spec-Compliant TBS Calculation for 5G-LENA===<br /> <br /> 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]<br /> <br /> 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.<br /> 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.<br /> <br /> 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.<br /> <br /> *Required Experience: C++ programming, understanding of 5G NR MAC concepts (scheduling, CQI/MCS, HARQ), wireless networking fundamentals<br /> *Interests: 5G NR simulations, scheduling, link adaptation, performance evaluation<br /> *Difficulty: Medium<br /> *Project size: Medium<br /> *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.<br /> <br /> === Enabling 5G NR examples visualization ===<br /> <br /> 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]<br /> <br /> 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.<br /> <br /> 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.<br /> 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].<br /> <br /> * Required Experience: C++ and Python programming, understanding of 5G NR, LTE, and wireless networks<br /> * Interests: 5G NR simulations<br /> * Difficulty: Medium.<br /> * 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.<br /> <br /> === AODVv2 Protocol enhancements ===<br /> <br /> Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], [TBD].<br /> <br /> 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.<br /> <br /> In particular the project should address the following points:<br /> # Alignment with the latest drafts,<br /> # Model finalization and testing (in particular for the IPv6 part),<br /> # AODVv2 examples and documentation,<br /> # &quot;External&quot; network routing support.<br /> <br /> Collaboration with the draft authors is also highly suggested.<br /> <br /> * ''Required Experience:'' Fundamentals of IPv6 addressing, C++ programming.<br /> * ''Bonus Experience:'' Familiarity with AODV implementations in ns-3 and AODVv2<br /> * ''Interests:'' Ad hoc routing<br /> * ''Difficulty:'' Medium.<br /> * ''Recommended reading:''<br /> ** [https://www.nsnam.org/docs/models/html/ipv6.html IPv6 model in ns-3]<br /> ** [https://www.nsnam.org/docs/models/html/aodv.html AODV model in ns-3]<br /> ** [https://gitlab.com/tod97/ns-3-dev/-/tree/aodvv2-icns3-25 AODVv2 model presented at ICNS3-2025] <br /> ** [https://datatracker.ietf.org/doc/draft-perkins-manet-aodvv2/05/ Ad Hoc On-demand Distance Vector Version 2 (AODVv2) Routing]<br /> <br /> Possible tasks to fulfill the patch requirement:<br /> * [https://gitlab.com/nsnam/ns-3-dev/-/issues/368 Issue #368] - aodv: aodv parameters can be set to &quot;impossible&quot; values<br /> <br /> == Large projects (350 hours) ==<br /> <br /> === Mesh Link Establishment (MLE) protocol ===<br /> <br /> Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], [mailto:alramonet@is.tokushima-u.ac.jp Alberto Gallegos Ramonet].<br /> <br /> 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.<br /> However, MLE is being used in Thread, and it can be useful to implement it.<br /> <br /> 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.<br /> <br /> * ''Required Experience:'' Fundamentals of IPv4 and IPv6 sockets, C++ programming.<br /> * ''Interests:'' Sockets and API interface implementation.<br /> * ''Difficulty:'' Hard.<br /> * ''Recommended reading:''<br /> ** [https://datatracker.ietf.org/doc/html/draft-ietf-6lo-mesh-link-establishment MLE draft]<br /> ** [https://openthread.io/guides/thread-primer/network-discovery Thread primer]<br /> ** [https://www.threadgroup.org/ThreadSpec Thread specifications]<br /> <br /> Possible tasks to fulfill the patch requirement:<br /> * TBD, contact the mentors if interested.<br /> <br /> ===Energy Consumption Modeling and Power-Aware Extensions for 5G-LENA===<br /> <br /> 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]<br /> <br /> 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.<br /> 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.<br /> 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.<br /> <br /> Scope (expected deliverables):<br /> *Energy consumption accounting for UEs and/or gNBs<br /> *Per-state (and if feasible per-procedure) modeling, e.g.<br /> **gNB: idle/active/sleep, TX/RX, processing; dependence on bandwidth/PRBs, TX power, MIMO layers/streams/RF chains, load<br /> **UE: TX/RX, measurements, CSI-RS/SRS activity, beamforming-related processing, handover<br /> *Tracing, example(s), and documentation<br /> <br /> 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)<br /> <br /> *Required Experience: C++ programming, wireless networking fundamentals (energy/state-machine modeling is a plus)<br /> *Interests: 5G NR simulations, energy efficiency, green networking, 6G sustainability<br /> *Difficulty: Medium<br /> *Project size: Medium<br /> *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.<br /> <br /> === 5G NR module integration with ns-3-ai ===<br /> <br /> 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]<br /> <br /> 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.<br /> <br /> 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.<br /> For more specific guidelines, please view this [https://docs.google.com/document/d/1cQLIF1cdft1yj3vyWrjrxN2xDJMx8PuWaa9NP_nKf64/edit?usp=sharing Google document].<br /> <br /> * Required Experience: C++ programming, understanding of 5G NR, LTE, and wireless networks<br /> * Interests: 5G NR simulations<br /> * Difficulty: Medium.<br /> * 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.<br /> <br /> === Linux-like CAKE queue discipline for ns-3 ===<br /> <br /> Mentors: [mailto:tahiliani.nitk@gmail.com Mohit P. Tahiliani]<br /> <br /> 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.<br /> <br /> * ''Required Experience:'' Familiarity with queue disciplines, TCP and C++ programming.<br /> * ''Bonus Experience:'' Familiarity with CAKE framework in Linux 4.19<br /> * ''Interests:'' Active Queue Management, Packet scheduling and TCP.<br /> * ''Difficulty:'' Medium to Hard<br /> * ''Recommended reading:''<br /> ** [https://arxiv.org/pdf/1804.07617.pdf Piece of CAKE: A Comprehensive Queue Management Solution for Home Gateways]<br /> ** [https://lwn.net/Articles/758353/ Let them run CAKE]<br /> ** [https://www.nsnam.org/docs/models/html/queue-discs.html Queue disciplines in ns-3]<br /> <br /> === Switched Ethernet ===<br /> <br /> Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], TBD.<br /> <br /> 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.<br /> <br /> 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.<br /> <br /> 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.<br /> <br /> 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.<br /> <br /> 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.<br /> <br /> * ''Required Experience:'' Fundamentals of Ethernet sitched networking, C++ programming.<br /> * ''Interests:'' Ethernet networks and switched data networks.<br /> * ''Difficulty:'' Medium.<br /> * ''Recommended reading:''<br /> ** [https://www2.nsnam.org/bugzilla/show_bug.cgi?id=2602 Basic implementation (very old)]<br /> ** [https://gitlab.com/nsnam/ns-3-dev/-/merge_requests/431 Full-duplex CSMA, somehow related]<br /> ** [https://tcipg.org/sites/default/files/papers/2010_Jin_Nicol_Caesar.pdf Paper on gigabit Ethernet switch models for simulation]<br /> <br /> Possible tasks to fulfill the patch requirement:<br /> * TBD, contact the mentors if interested.</div>

Tommaso https://www.nsnam.org/mediawiki/index.php?title=GSOC2026Projects&diff=13754 2026-02-12T02:12:16Z

<p>Tommaso: /* Internet routing refactory */</p> <hr /> <div>{{TOC}}<br /> <br /> This page contains 2026 Google Summer of Code project ideas for ns-3.<br /> <br /> * [https://developers.google.com/open-source/gsoc/faq GSoC Frequently Asked Questions]<br /> * [[GSOC2026ContributorGuide | ns-3's 2026 GSoC Contributor guide]]<br /> * [https://developers.google.com/open-source/gsoc/resources/guide GSoC contributor/student guide (not ns-3 specific)]<br /> * [[GSOC2025ApplicationTemplate | 2026 GSoC Contributor application template]]<br /> * [[GSOCMentorGuide | ns-3's GSoC Mentor guide]]<br /> * [https://archive.flossmanuals.net/gsocmentoring/index.html GSoC Mentor guide (not ns-3 specific)]<br /> * [[GSOCSelectionProcess | GSoC Contributor Selection Process]]<br /> * ''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/<br /> <br /> === About the ns-3 project ===<br /> <br /> ns-3 is a discrete-event network simulator, with a particular emphasis on network research and education.<br /> <br /> 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.<br /> <br /> 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.<br /> <br /> === Org admins ===<br /> <br /> 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].<br /> <br /> === Mentors ===<br /> <br /> 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.<br /> <br /> The current list of prospective mentors can be found among the ideas listed below.<br /> <br /> === How to apply ===<br /> <br /> For students or contributors interested in applying to ns-3 for GSoC, please go through the following list to get started:<br /> * Read the official [https://developers.google.com/open-source/gsoc/resources/guide GSoC contributor guide].<br /> * Read [[GSOC2026ContributorGuide |ns-3's 2026 GSoC contributor guide]]<br /> * Look through our [[#Project Ideas]] below to see if you find a project that interests you.<br /> * Review the [https://www.nsnam.org/documentation/development-tree/ tutorial and contributing guide] thoroughly, if you have not already done so.<br /> * 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.<br /> * Next, proceed to get in touch with the developers on the mailing list or Zulip chat room and refine your proposal.<br /> * 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.<br /> <br /> 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.<br /> <br /> &lt;blockquote&gt;<br /> Each project idea within a particular priority has been tagged with the following properties:<br /> * ''Required Experience:'' Languages, concepts, or packages with which applicants must be familiar.<br /> * ''Bonus Experience:'' Other experience or familiarity which would be greatly helpful to applicants for this project.<br /> * ''Interests:'' Areas of particular relevance to this project, and an indicator of where successful contributors might apply their experiences coming out of this project.<br /> * ''Difficulty:'' easy, medium or difficult<br /> * ''Recommended reading:'' pointers to documentation, papers, specific bugs, etc.<br /> <br /> 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.<br /> &lt;/blockquote&gt;<br /> <br /> === Patch requirement guidelines ===<br /> <br /> 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.<br /> <br /> === Mentors: how to participate ===<br /> <br /> 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:<br /> <br /> * 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.<br /> * 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.<br /> * 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.<br /> <br /> == Project Ideas ==<br /> <br /> '''Note to contributors:''' These ideas are not listed in any priority order.<br /> 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.<br /> <br /> === Internet models enhancements ===<br /> <br /> * [[#Flent Application API in ns-3]] (small size project, 90h)<br /> * [[#Internet routing refactory]] (small size project, 90h)<br /> * [[#AODVv2 Protocol enhancements]] (medium size project, 175h)<br /> * [[#Linux-like CAKE queue discipline for ns-3]] (large size project, 350h)<br /> * [[#Switched Ethernet]] (large size project, 350h)<br /> <br /> === IoT models enhancements ===<br /> <br /> * [[#6LoWPAN mesh-under routing enhancements]] (medium size project, 175h)<br /> * [[#6LoWPAN neighbor discovery protocol]] (medium size project, 175h)<br /> * [[#Mesh Link Establishment (MLE) protocol ]] (large size project, 350h)<br /> <br /> === 5G NR models enhancements ===<br /> <br /> 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.<br /> <br /> * [[#OLLA Link Adaptation and Spec-Compliant TBS Calculation for 5G-LENA]](medium size project, 175h)<br /> * [[#Enabling 5G NR examples visualization]] (medium size project, 175h)<br /> * [[#Energy Consumption Modeling and Power-Aware Extensions for 5G-LENA]](medium size project, 250h)<br /> * [[#5G NR module integration with ns-3-ai]] (large size project, 250h)<br /> <br /> == Small sized projects (90 hours) ==<br /> <br /> === Flent Application API in ns-3 ===<br /> <br /> Mentors: [mailto:tahiliani.nitk@gmail.com Mohit P. Tahiliani]<br /> <br /> 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.<br /> <br /> * ''Required Experience:'' Familiarity with Flent and C++ programming.<br /> * ''Bonus Experience:'' Familiarity with applications supported in ns-3.<br /> * ''Interests:'' Bufferbloat, TCP, AQM algorithms and ECN.<br /> * ''Difficulty:'' Medium.<br /> * ''Recommended Reading:''<br /> ** Flexible Network Tester [[https://flent.org/flent-the-flexible-network-tester.pdf Paper]] [[https://flent.org/ Tool]]<br /> ** [https://www.nsnam.org/doxygen/d9/dc9/group__applications.html#details Existing Applications in ns-3]<br /> ** [https://gitlab.com/tomhenderson/ns-3-dev/-/commits/flent?ref_type=heads Prior work on Flent application API in ns-3]<br /> <br /> === Internet routing refactory ===<br /> <br /> Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], [TBD].<br /> <br /> 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.<br /> In ns-3 this is accomplished by storing three separate objects, two Ipv[4,6]Address, and one Ipv[4Mask,6Prefix].<br /> <br /> While this is quite simple to implement, this has some notable drawbacks, e.g., the Dst address must be a network address (Dst &amp; ~DstMask == 0), it is not efficient (the mask or prefix could be represented by a simple integer), and more.<br /> In order to improve code readability and consistency between IPv4 and IPv6, !2645 introduces two new classes: Ipv[4,6]NetworkAddress.<br /> <br /> The goal is to refactor the existing routing classes, along with Ipv[4,6]RotingTable classes, so that they use the new classes.<br /> 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.<br /> Another very important requirement will be to break down the work in multiple sub-tasks, so that the merge process can be gradual.<br /> <br /> 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.<br /> <br /> * ''Required Experience:'' Fundamentals of IPv6 addressing and routing, C++ programming.<br /> * ''Interests:'' IPv4 and IPv6 routing<br /> * ''Difficulty:'' Easy.<br /> * ''Recommended reading:''<br /> ** [https://gitlab.com/nsnam/ns-3-dev/-/issues/1239 Issue #1239]<br /> ** [https://gitlab.com/nsnam/ns-3-dev/-/merge_requests/2645 Merge Request !2645]<br /> <br /> Possible tasks to fulfill the patch requirement:<br /> * Use !2645 to modify all or in part the `Rip` protocol.<br /> <br /> === Ping and TraverouteV4 enhancements ===<br /> <br /> Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], [TBD].<br /> <br /> The Ping and TraverouteV4 ns-3 application have some small limitations. <br /> <br /> In particular 2 of them are annoying.<br /> 1. Neither Ping nor TracerouteV4 reacts to ICMP errors or informative messages.<br /> 2. As the name implies, TracerouteV4 is IPv4-only and can't be used on IPv6.<br /> <br /> 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.<br /> <br /> * ''Required Experience:'' Fundamentals of IPv4, IPv6, ICMP, and ICMPv6. C++ programming.<br /> * ''Interests:'' IPv4 and IPv6.<br /> * ''Difficulty:'' Easy.<br /> * ''Recommended reading:''<br /> ** [https://gitlab.com/nsnam/ns-3-dev/-/issues/825 Issue #825]<br /> <br /> Possible tasks to fulfill the patch requirement:<br /> * MR to have Ping react to one ICMP message.<br /> <br /> == Medium sized projects (175 hours) ==<br /> <br /> === 6LoWPAN mesh-under routing enhancements ===<br /> <br /> Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], [TBD].<br /> <br /> 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.<br /> 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.<br /> <br /> The candidate should outline the proposed approach, what parts of code are going to be affected, and how they can be enhanced.<br /> <br /> * ''Required Experience:'' Fundamentals of IPv6 addressing, C++ programming.<br /> * ''Bonus Experience:'' Familiarity with mesh routing and 6LoWPAN ns-3<br /> * ''Interests:'' IPv6 mesh routing<br /> * ''Difficulty:'' Easy.<br /> * ''Recommended reading:''<br /> ** [https://www.nsnam.org/docs/models/html/sixlowpan.html#mesh-under-routing Mesh-under in ns-3 6LoWPAN]<br /> ** [https://datatracker.ietf.org/doc/html/rfc7731 RFC 7731]<br /> ** [https://meshtastic.org/docs/overview/mesh-algo/ Meshtastic controlled flooding]<br /> ** [https://ieeexplore.ieee.org/document/91339 Routing by controlled flooding in communication networks] (if the document can not be accessed, PM the mentors)<br /> <br /> Possible tasks to fulfill the patch requirement:<br /> * 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 &quot;next hop&quot;. The behavior of the actual protocol should be unchanged.<br /> <br /> === 6LoWPAN neighbor discovery protocol ===<br /> <br /> Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], [mailto:adnan.rashid@poliba.it Adnan Rashid].<br /> <br /> 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.<br /> <br /> 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.<br /> <br /> 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.<br /> <br /> * ''Required Experience:'' Fundamentals of IPv6 addressing, C++ programming.<br /> * ''Bonus Experience:'' Familiarity with 6LoWPAN and 6LoWPAN-ND<br /> * ''Interests:'' IPv6 and IoT networks<br /> * ''Difficulty:'' Easy.<br /> * ''Recommended reading:''<br /> ** [https://datatracker.ietf.org/doc/html/rfc8505 RFC 8505]<br /> ** [https://datatracker.ietf.org/doc/html/rfc6775 RFC 6775]<br /> ** [https://datatracker.ietf.org/doc/html/rfc4944 RFC 4944]<br /> ** https://gitlab.com/jieqiboh5836/ns-3-dev/-/tree/6LoWPAN-ND-P1<br /> ** https://gitlab.com/jieqiboh5836/ns-3-dev/-/tree/6LoWPAN-ND-P2<br /> <br /> ===OLLA Link Adaptation and Spec-Compliant TBS Calculation for 5G-LENA===<br /> <br /> 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]<br /> <br /> 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.<br /> 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.<br /> <br /> 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.<br /> <br /> *Required Experience: C++ programming, understanding of 5G NR MAC concepts (scheduling, CQI/MCS, HARQ), wireless networking fundamentals<br /> *Interests: 5G NR simulations, scheduling, link adaptation, performance evaluation<br /> *Difficulty: Medium<br /> *Project size: Medium<br /> *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.<br /> <br /> === Enabling 5G NR examples visualization ===<br /> <br /> 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]<br /> <br /> 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.<br /> <br /> 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.<br /> 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].<br /> <br /> * Required Experience: C++ and Python programming, understanding of 5G NR, LTE, and wireless networks<br /> * Interests: 5G NR simulations<br /> * Difficulty: Medium.<br /> * 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.<br /> <br /> === AODVv2 Protocol enhancements ===<br /> <br /> Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], [TBD].<br /> <br /> 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.<br /> <br /> In particular the project should address the following points:<br /> # Alignment with the latest drafts,<br /> # Model finalization and testing (in particular for the IPv6 part),<br /> # AODVv2 examples and documentation,<br /> # &quot;External&quot; network routing support.<br /> <br /> Collaboration with the draft authors is also highly suggested.<br /> <br /> * ''Required Experience:'' Fundamentals of IPv6 addressing, C++ programming.<br /> * ''Bonus Experience:'' Familiarity with AODV implementations in ns-3 and AODVv2<br /> * ''Interests:'' Ad hoc routing<br /> * ''Difficulty:'' Medium.<br /> * ''Recommended reading:''<br /> ** [https://www.nsnam.org/docs/models/html/ipv6.html IPv6 model in ns-3]<br /> ** [https://www.nsnam.org/docs/models/html/aodv.html AODV model in ns-3]<br /> ** [https://gitlab.com/tod97/ns-3-dev/-/tree/aodvv2-icns3-25 AODVv2 model presented at ICNS3-2025] <br /> ** [https://datatracker.ietf.org/doc/draft-perkins-manet-aodvv2/05/ Ad Hoc On-demand Distance Vector Version 2 (AODVv2) Routing]<br /> <br /> Possible tasks to fulfill the patch requirement:<br /> * [https://gitlab.com/nsnam/ns-3-dev/-/issues/368 Issue #368] - aodv: aodv parameters can be set to &quot;impossible&quot; values<br /> <br /> == Large projects (350 hours) ==<br /> <br /> === Mesh Link Establishment (MLE) protocol ===<br /> <br /> Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], [mailto:alramonet@is.tokushima-u.ac.jp Alberto Gallegos Ramonet].<br /> <br /> 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.<br /> However, MLE is being used in Thread, and it can be useful to implement it.<br /> <br /> 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.<br /> <br /> * ''Required Experience:'' Fundamentals of IPv4 and IPv6 sockets, C++ programming.<br /> * ''Interests:'' Sockets and API interface implementation.<br /> * ''Difficulty:'' Hard.<br /> * ''Recommended reading:''<br /> ** [https://datatracker.ietf.org/doc/html/draft-ietf-6lo-mesh-link-establishment MLE draft]<br /> ** [https://openthread.io/guides/thread-primer/network-discovery Thread primer]<br /> ** [https://www.threadgroup.org/ThreadSpec Thread specifications]<br /> <br /> Possible tasks to fulfill the patch requirement:<br /> * TBD, contact the mentors if interested.<br /> <br /> ===Energy Consumption Modeling and Power-Aware Extensions for 5G-LENA===<br /> <br /> 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]<br /> <br /> 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.<br /> 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.<br /> 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.<br /> <br /> Scope (expected deliverables):<br /> *Energy consumption accounting for UEs and/or gNBs<br /> *Per-state (and if feasible per-procedure) modeling, e.g.<br /> **gNB: idle/active/sleep, TX/RX, processing; dependence on bandwidth/PRBs, TX power, MIMO layers/streams/RF chains, load<br /> **UE: TX/RX, measurements, CSI-RS/SRS activity, beamforming-related processing, handover<br /> *Tracing, example(s), and documentation<br /> <br /> 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)<br /> <br /> *Required Experience: C++ programming, wireless networking fundamentals (energy/state-machine modeling is a plus)<br /> *Interests: 5G NR simulations, energy efficiency, green networking, 6G sustainability<br /> *Difficulty: Medium<br /> *Project size: Medium<br /> *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.<br /> <br /> === 5G NR module integration with ns-3-ai ===<br /> <br /> 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]<br /> <br /> 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.<br /> <br /> 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.<br /> For more specific guidelines, please view this [https://docs.google.com/document/d/1cQLIF1cdft1yj3vyWrjrxN2xDJMx8PuWaa9NP_nKf64/edit?usp=sharing Google document].<br /> <br /> * Required Experience: C++ programming, understanding of 5G NR, LTE, and wireless networks<br /> * Interests: 5G NR simulations<br /> * Difficulty: Medium.<br /> * 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.<br /> <br /> === Linux-like CAKE queue discipline for ns-3 ===<br /> <br /> Mentors: [mailto:tahiliani.nitk@gmail.com Mohit P. Tahiliani]<br /> <br /> 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.<br /> <br /> * ''Required Experience:'' Familiarity with queue disciplines, TCP and C++ programming.<br /> * ''Bonus Experience:'' Familiarity with CAKE framework in Linux 4.19<br /> * ''Interests:'' Active Queue Management, Packet scheduling and TCP.<br /> * ''Difficulty:'' Medium to Hard<br /> * ''Recommended reading:''<br /> ** [https://arxiv.org/pdf/1804.07617.pdf Piece of CAKE: A Comprehensive Queue Management Solution for Home Gateways]<br /> ** [https://lwn.net/Articles/758353/ Let them run CAKE]<br /> ** [https://www.nsnam.org/docs/models/html/queue-discs.html Queue disciplines in ns-3]<br /> <br /> === Switched Ethernet ===<br /> <br /> Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], TBD.<br /> <br /> 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.<br /> <br /> 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.<br /> <br /> 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.<br /> <br /> 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.<br /> <br /> 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.<br /> <br /> * ''Required Experience:'' Fundamentals of Ethernet sitched networking, C++ programming.<br /> * ''Interests:'' Ethernet networks and switched data networks.<br /> * ''Difficulty:'' Medium.<br /> * ''Recommended reading:''<br /> ** [https://www2.nsnam.org/bugzilla/show_bug.cgi?id=2602 Basic implementation (very old)]<br /> ** [https://gitlab.com/nsnam/ns-3-dev/-/merge_requests/431 Full-duplex CSMA, somehow related]<br /> ** [https://tcipg.org/sites/default/files/papers/2010_Jin_Nicol_Caesar.pdf Paper on gigabit Ethernet switch models for simulation]<br /> <br /> Possible tasks to fulfill the patch requirement:<br /> * TBD, contact the mentors if interested.</div>

Tommaso https://www.nsnam.org/mediawiki/index.php?title=GSOC2026Projects&diff=13752 2026-02-09T22:31:10Z

<p>Tommaso: /* Internet routing refactory */</p> <hr /> <div>{{TOC}}<br /> <br /> This page contains 2026 Google Summer of Code project ideas for ns-3.<br /> <br /> * [https://developers.google.com/open-source/gsoc/faq GSoC Frequently Asked Questions]<br /> * [[GSOC2026ContributorGuide | ns-3's 2026 GSoC Contributor guide]]<br /> * [https://developers.google.com/open-source/gsoc/resources/guide GSoC contributor/student guide (not ns-3 specific)]<br /> * [[GSOC2025ApplicationTemplate | 2026 GSoC Contributor application template]]<br /> * [[GSOCMentorGuide | ns-3's GSoC Mentor guide]]<br /> * [https://archive.flossmanuals.net/gsocmentoring/index.html GSoC Mentor guide (not ns-3 specific)]<br /> * [[GSOCSelectionProcess | GSoC Contributor Selection Process]]<br /> * ''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/<br /> <br /> === About the ns-3 project ===<br /> <br /> ns-3 is a discrete-event network simulator, with a particular emphasis on network research and education.<br /> <br /> 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.<br /> <br /> 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.<br /> <br /> === Org admins ===<br /> <br /> 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].<br /> <br /> === Mentors ===<br /> <br /> 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.<br /> <br /> The current list of prospective mentors can be found among the ideas listed below.<br /> <br /> === How to apply ===<br /> <br /> For students or contributors interested in applying to ns-3 for GSoC, please go through the following list to get started:<br /> * Read the official [https://developers.google.com/open-source/gsoc/resources/guide GSoC contributor guide].<br /> * Read [[GSOC2026ContributorGuide |ns-3's 2026 GSoC contributor guide]]<br /> * Look through our [[#Project Ideas]] below to see if you find a project that interests you.<br /> * Review the [https://www.nsnam.org/documentation/development-tree/ tutorial and contributing guide] thoroughly, if you have not already done so.<br /> * 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.<br /> * Next, proceed to get in touch with the developers on the mailing list or Zulip chat room and refine your proposal.<br /> * 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.<br /> <br /> 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.<br /> <br /> &lt;blockquote&gt;<br /> Each project idea within a particular priority has been tagged with the following properties:<br /> * ''Required Experience:'' Languages, concepts, or packages with which applicants must be familiar.<br /> * ''Bonus Experience:'' Other experience or familiarity which would be greatly helpful to applicants for this project.<br /> * ''Interests:'' Areas of particular relevance to this project, and an indicator of where successful contributors might apply their experiences coming out of this project.<br /> * ''Difficulty:'' easy, medium or difficult<br /> * ''Recommended reading:'' pointers to documentation, papers, specific bugs, etc.<br /> <br /> 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.<br /> &lt;/blockquote&gt;<br /> <br /> === Patch requirement guidelines ===<br /> <br /> 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.<br /> <br /> === Mentors: how to participate ===<br /> <br /> 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:<br /> <br /> * 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.<br /> * 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.<br /> * 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.<br /> <br /> == Project Ideas ==<br /> <br /> '''Note to contributors:''' These ideas are not listed in any priority order.<br /> 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.<br /> <br /> === Internet models enhancements ===<br /> <br /> * [[#Flent Application API in ns-3]] (small size project, 90h)<br /> * [[#Internet routing refactory]] (small size project, 90h)<br /> * [[#AODVv2 Protocol enhancements]] (medium size project, 175h)<br /> * [[#Linux-like CAKE queue discipline for ns-3]] (large size project, 350h)<br /> * [[#Switched Ethernet]] (large size project, 350h)<br /> <br /> === IoT models enhancements ===<br /> <br /> * [[#6LoWPAN mesh-under routing enhancements]] (medium size project, 175h)<br /> * [[#6LoWPAN neighbor discovery protocol]] (medium size project, 175h)<br /> * [[#Mesh Link Establishment (MLE) protocol ]] (large size project, 350h)<br /> <br /> === 5G NR models enhancements ===<br /> <br /> 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.<br /> <br /> * [[#OLLA Link Adaptation and Spec-Compliant TBS Calculation for 5G-LENA]](medium size project, 175h)<br /> * [[#Enabling 5G NR examples visualization]] (medium size project, 175h)<br /> * [[#Energy Consumption Modeling and Power-Aware Extensions for 5G-LENA]](medium size project, 250h)<br /> * [[#5G NR module integration with ns-3-ai]] (large size project, 250h)<br /> <br /> == Small sized projects (90 hours) ==<br /> <br /> === Flent Application API in ns-3 ===<br /> <br /> Mentors: [mailto:tahiliani.nitk@gmail.com Mohit P. Tahiliani]<br /> <br /> 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) complete the implementation of Flent application API in ns-3 based on the latest ns-3-dev, (2) enable support for multiple ns-3 applications in the Flent application API (3) add more examples (i.e., Flent tests) in ns-3 to better suit the needs of researchers working in this area, and (4) merge Flent application API in the mainline of ns-3.<br /> <br /> * ''Required Experience:'' Familiarity with Flent and C++ programming.<br /> * ''Bonus Experience:'' Familiarity with applications supported in ns-3.<br /> * ''Interests:'' Bufferbloat, TCP, AQM algorithms and ECN.<br /> * ''Difficulty:'' Medium.<br /> * ''Recommended Reading:''<br /> ** Flexible Network Tester [[https://flent.org/flent-the-flexible-network-tester.pdf Paper]] [[https://flent.org/ Tool]]<br /> ** [https://www.nsnam.org/doxygen/d9/dc9/group__applications.html#details Existing Applications in ns-3]<br /> ** [https://gitlab.com/tomhenderson/ns-3-dev/-/commits/flent?ref_type=heads Prior work on Flent application API in ns-3]<br /> <br /> === Internet routing refactory ===<br /> <br /> Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], [TBD].<br /> <br /> 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.<br /> In ns-3 this is accomplished by storing three separate objects, two Ipv[4,6]Address, and one Ipv[4Mask,6Prefix].<br /> <br /> While this is quite simple to implement, this has some notable drawbacks, e.g., the Dst address must be a network address (Dst &amp; ~DstMask == 0), it is not efficient (the mask or prefix could be represented by a simple integer), and more.<br /> In order to improve code readability and consistency between IPv4 and IPv6, !2645 introduces two new classes: Ipv[4,6]NetworkAddress.<br /> <br /> The goal is to refactor the existing routing classes, along with Ipv[4,6]RotingTable classes, so that they use the new classes.<br /> 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.<br /> Another very important requirement will be to break down the work in multiple sub-tasks, so that the merge process can be gradual.<br /> <br /> 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 clearr and motivated.<br /> <br /> * ''Required Experience:'' Fundamentals of IPv6 addressing and routing, C++ programming.<br /> * ''Interests:'' IPv4 and IPv6 routing<br /> * ''Difficulty:'' Easy.<br /> * ''Recommended reading:''<br /> ** [https://gitlab.com/nsnam/ns-3-dev/-/issues/1239 Issue #1239]<br /> ** [https://gitlab.com/nsnam/ns-3-dev/-/merge_requests/2645 Merge Request !2645]<br /> <br /> Possible tasks to fulfill the patch requirement:<br /> * Use !2645 to modify all or in part the `Rip` protocol.<br /> <br /> == Medium sized projects (175 hours) ==<br /> <br /> === 6LoWPAN mesh-under routing enhancements ===<br /> <br /> Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], [TBD].<br /> <br /> 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.<br /> 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.<br /> <br /> The candidate should outline the proposed approach, what parts of code are going to be affected, and how they can be enhanced.<br /> <br /> * ''Required Experience:'' Fundamentals of IPv6 addressing, C++ programming.<br /> * ''Bonus Experience:'' Familiarity with mesh routing and 6LoWPAN ns-3<br /> * ''Interests:'' IPv6 mesh routing<br /> * ''Difficulty:'' Easy.<br /> * ''Recommended reading:''<br /> ** [https://www.nsnam.org/docs/models/html/sixlowpan.html#mesh-under-routing Mesh-under in ns-3 6LoWPAN]<br /> ** [https://datatracker.ietf.org/doc/html/rfc7731 RFC 7731]<br /> ** [https://meshtastic.org/docs/overview/mesh-algo/ Meshtastic controlled flooding]<br /> ** [https://ieeexplore.ieee.org/document/91339 Routing by controlled flooding in communication networks] (if the document can not be accessed, PM the mentors)<br /> <br /> Possible tasks to fulfill the patch requirement:<br /> * 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 &quot;next hop&quot;. The behavior of the actual protocol should be unchanged.<br /> <br /> === 6LoWPAN neighbor discovery protocol ===<br /> <br /> Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], [mailto:adnan.rashid@poliba.it Adnan Rashid].<br /> <br /> 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.<br /> <br /> 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.<br /> <br /> 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.<br /> <br /> * ''Required Experience:'' Fundamentals of IPv6 addressing, C++ programming.<br /> * ''Bonus Experience:'' Familiarity with 6LoWPAN and 6LoWPAN-ND<br /> * ''Interests:'' IPv6 and IoT networks<br /> * ''Difficulty:'' Easy.<br /> * ''Recommended reading:''<br /> ** [https://datatracker.ietf.org/doc/html/rfc8505 RFC 8505]<br /> ** [https://datatracker.ietf.org/doc/html/rfc6775 RFC 6775]<br /> ** [https://datatracker.ietf.org/doc/html/rfc4944 RFC 4944]<br /> ** https://gitlab.com/jieqiboh5836/ns-3-dev/-/tree/6LoWPAN-ND-P1<br /> ** https://gitlab.com/jieqiboh5836/ns-3-dev/-/tree/6LoWPAN-ND-P2<br /> <br /> ===OLLA Link Adaptation and Spec-Compliant TBS Calculation for 5G-LENA===<br /> <br /> 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]<br /> <br /> 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.<br /> 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.<br /> <br /> 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.<br /> <br /> *Required Experience: C++ programming, understanding of 5G NR MAC concepts (scheduling, CQI/MCS, HARQ), wireless networking fundamentals<br /> *Interests: 5G NR simulations, scheduling, link adaptation, performance evaluation<br /> *Difficulty: Medium<br /> *Project size: Medium<br /> *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.<br /> <br /> === Enabling 5G NR examples visualization ===<br /> <br /> 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]<br /> <br /> 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.<br /> <br /> 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.<br /> 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].<br /> <br /> * Required Experience: C++ and Python programming, understanding of 5G NR, LTE, and wireless networks<br /> * Interests: 5G NR simulations<br /> * Difficulty: Medium.<br /> * 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.<br /> <br /> === AODVv2 Protocol enhancements ===<br /> <br /> Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], [TBD].<br /> <br /> 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.<br /> <br /> In particular the project should address the following points:<br /> # Alignment with the latest drafts,<br /> # Model finalization and testing (in particular for the IPv6 part),<br /> # AODVv2 examples and documentation,<br /> # &quot;External&quot; network routing support.<br /> <br /> Collaboration with the draft authors is also highly suggested.<br /> <br /> * ''Required Experience:'' Fundamentals of IPv6 addressing, C++ programming.<br /> * ''Bonus Experience:'' Familiarity with AODV implementations in ns-3 and AODVv2<br /> * ''Interests:'' Ad hoc routing<br /> * ''Difficulty:'' Medium.<br /> * ''Recommended reading:''<br /> ** [https://www.nsnam.org/docs/models/html/ipv6.html IPv6 model in ns-3]<br /> ** [https://www.nsnam.org/docs/models/html/aodv.html AODV model in ns-3]<br /> ** [https://gitlab.com/tod97/ns-3-dev/-/tree/aodvv2-icns3-25 AODVv2 model presented at ICNS3-2025] <br /> ** [https://datatracker.ietf.org/doc/draft-perkins-manet-aodvv2/05/ Ad Hoc On-demand Distance Vector Version 2 (AODVv2) Routing]<br /> <br /> Possible tasks to fulfill the patch requirement:<br /> * [https://gitlab.com/nsnam/ns-3-dev/-/issues/368 Issue #368] - aodv: aodv parameters can be set to &quot;impossible&quot; values<br /> <br /> == Large projects (350 hours) ==<br /> <br /> === Mesh Link Establishment (MLE) protocol ===<br /> <br /> Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], [mailto:alramonet@is.tokushima-u.ac.jp Alberto Gallegos Ramonet].<br /> <br /> 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.<br /> However, MLE is being used in Thread, and it can be useful to implement it.<br /> <br /> 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.<br /> <br /> * ''Required Experience:'' Fundamentals of IPv4 and IPv6 sockets, C++ programming.<br /> * ''Interests:'' Sockets and API interface implementation.<br /> * ''Difficulty:'' Hard.<br /> * ''Recommended reading:''<br /> ** [https://datatracker.ietf.org/doc/html/draft-ietf-6lo-mesh-link-establishment MLE draft]<br /> ** [https://openthread.io/guides/thread-primer/network-discovery Thread primer]<br /> ** [https://www.threadgroup.org/ThreadSpec Thread specifications]<br /> <br /> Possible tasks to fulfill the patch requirement:<br /> * TBD, contact the mentors if interested.<br /> <br /> ===Energy Consumption Modeling and Power-Aware Extensions for 5G-LENA===<br /> <br /> 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]<br /> <br /> 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.<br /> 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.<br /> 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.<br /> <br /> Scope (expected deliverables):<br /> *Energy consumption accounting for UEs and/or gNBs<br /> *Per-state (and if feasible per-procedure) modeling, e.g.<br /> **gNB: idle/active/sleep, TX/RX, processing; dependence on bandwidth/PRBs, TX power, MIMO layers/streams/RF chains, load<br /> **UE: TX/RX, measurements, CSI-RS/SRS activity, beamforming-related processing, handover<br /> *Tracing, example(s), and documentation<br /> <br /> 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)<br /> <br /> *Required Experience: C++ programming, wireless networking fundamentals (energy/state-machine modeling is a plus)<br /> *Interests: 5G NR simulations, energy efficiency, green networking, 6G sustainability<br /> *Difficulty: Medium<br /> *Project size: Medium<br /> *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.<br /> <br /> === 5G NR module integration with ns-3-ai ===<br /> <br /> 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]<br /> <br /> 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.<br /> <br /> 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.<br /> For more specific guidelines, please view this [https://docs.google.com/document/d/1cQLIF1cdft1yj3vyWrjrxN2xDJMx8PuWaa9NP_nKf64/edit?usp=sharing Google document].<br /> <br /> * Required Experience: C++ programming, understanding of 5G NR, LTE, and wireless networks<br /> * Interests: 5G NR simulations<br /> * Difficulty: Medium.<br /> * 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.<br /> <br /> === Linux-like CAKE queue discipline for ns-3 ===<br /> <br /> Mentors: [mailto:tahiliani.nitk@gmail.com Mohit P. Tahiliani]<br /> <br /> 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.<br /> <br /> * ''Required Experience:'' Familiarity with queue disciplines, TCP and C++ programming.<br /> * ''Bonus Experience:'' Familiarity with CAKE framework in Linux 4.19<br /> * ''Interests:'' Active Queue Management, Packet scheduling and TCP.<br /> * ''Difficulty:'' Medium to Hard<br /> * ''Recommended reading:''<br /> ** [https://arxiv.org/pdf/1804.07617.pdf Piece of CAKE: A Comprehensive Queue Management Solution for Home Gateways]<br /> ** [https://lwn.net/Articles/758353/ Let them run CAKE]<br /> ** [https://www.nsnam.org/docs/models/html/queue-discs.html Queue disciplines in ns-3]<br /> <br /> === Switched Ethernet ===<br /> <br /> Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], TBD.<br /> <br /> 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.<br /> <br /> 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.<br /> <br /> 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.<br /> <br /> 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.<br /> <br /> 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.<br /> <br /> * ''Required Experience:'' Fundamentals of Ethernet sitched networking, C++ programming.<br /> * ''Interests:'' Ethernet networks and switched data networks.<br /> * ''Difficulty:'' Medium.<br /> * ''Recommended reading:''<br /> ** [https://www2.nsnam.org/bugzilla/show_bug.cgi?id=2602 Basic implementation (very old)]<br /> ** [https://gitlab.com/nsnam/ns-3-dev/-/merge_requests/431 Full-duplex CSMA, somehow related]<br /> ** [https://tcipg.org/sites/default/files/papers/2010_Jin_Nicol_Caesar.pdf Paper on gigabit Ethernet switch models for simulation]<br /> <br /> Possible tasks to fulfill the patch requirement:<br /> * TBD, contact the mentors if interested.</div>

Tommaso https://www.nsnam.org/mediawiki/index.php?title=GSOC2026Projects&diff=13751 2026-02-09T22:30:36Z

<p>Tommaso: /* Internet models enhancements */</p> <hr /> <div>{{TOC}}<br /> <br /> This page contains 2026 Google Summer of Code project ideas for ns-3.<br /> <br /> * [https://developers.google.com/open-source/gsoc/faq GSoC Frequently Asked Questions]<br /> * [[GSOC2026ContributorGuide | ns-3's 2026 GSoC Contributor guide]]<br /> * [https://developers.google.com/open-source/gsoc/resources/guide GSoC contributor/student guide (not ns-3 specific)]<br /> * [[GSOC2025ApplicationTemplate | 2026 GSoC Contributor application template]]<br /> * [[GSOCMentorGuide | ns-3's GSoC Mentor guide]]<br /> * [https://archive.flossmanuals.net/gsocmentoring/index.html GSoC Mentor guide (not ns-3 specific)]<br /> * [[GSOCSelectionProcess | GSoC Contributor Selection Process]]<br /> * ''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/<br /> <br /> === About the ns-3 project ===<br /> <br /> ns-3 is a discrete-event network simulator, with a particular emphasis on network research and education.<br /> <br /> 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.<br /> <br /> 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.<br /> <br /> === Org admins ===<br /> <br /> 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].<br /> <br /> === Mentors ===<br /> <br /> 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.<br /> <br /> The current list of prospective mentors can be found among the ideas listed below.<br /> <br /> === How to apply ===<br /> <br /> For students or contributors interested in applying to ns-3 for GSoC, please go through the following list to get started:<br /> * Read the official [https://developers.google.com/open-source/gsoc/resources/guide GSoC contributor guide].<br /> * Read [[GSOC2026ContributorGuide |ns-3's 2026 GSoC contributor guide]]<br /> * Look through our [[#Project Ideas]] below to see if you find a project that interests you.<br /> * Review the [https://www.nsnam.org/documentation/development-tree/ tutorial and contributing guide] thoroughly, if you have not already done so.<br /> * 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.<br /> * Next, proceed to get in touch with the developers on the mailing list or Zulip chat room and refine your proposal.<br /> * 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.<br /> <br /> 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.<br /> <br /> &lt;blockquote&gt;<br /> Each project idea within a particular priority has been tagged with the following properties:<br /> * ''Required Experience:'' Languages, concepts, or packages with which applicants must be familiar.<br /> * ''Bonus Experience:'' Other experience or familiarity which would be greatly helpful to applicants for this project.<br /> * ''Interests:'' Areas of particular relevance to this project, and an indicator of where successful contributors might apply their experiences coming out of this project.<br /> * ''Difficulty:'' easy, medium or difficult<br /> * ''Recommended reading:'' pointers to documentation, papers, specific bugs, etc.<br /> <br /> 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.<br /> &lt;/blockquote&gt;<br /> <br /> === Patch requirement guidelines ===<br /> <br /> 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.<br /> <br /> === Mentors: how to participate ===<br /> <br /> 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:<br /> <br /> * 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.<br /> * 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.<br /> * 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.<br /> <br /> == Project Ideas ==<br /> <br /> '''Note to contributors:''' These ideas are not listed in any priority order.<br /> 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.<br /> <br /> === Internet models enhancements ===<br /> <br /> * [[#Flent Application API in ns-3]] (small size project, 90h)<br /> * [[#Internet routing refactory]] (small size project, 90h)<br /> * [[#AODVv2 Protocol enhancements]] (medium size project, 175h)<br /> * [[#Linux-like CAKE queue discipline for ns-3]] (large size project, 350h)<br /> * [[#Switched Ethernet]] (large size project, 350h)<br /> <br /> === IoT models enhancements ===<br /> <br /> * [[#6LoWPAN mesh-under routing enhancements]] (medium size project, 175h)<br /> * [[#6LoWPAN neighbor discovery protocol]] (medium size project, 175h)<br /> * [[#Mesh Link Establishment (MLE) protocol ]] (large size project, 350h)<br /> <br /> === 5G NR models enhancements ===<br /> <br /> 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.<br /> <br /> * [[#OLLA Link Adaptation and Spec-Compliant TBS Calculation for 5G-LENA]](medium size project, 175h)<br /> * [[#Enabling 5G NR examples visualization]] (medium size project, 175h)<br /> * [[#Energy Consumption Modeling and Power-Aware Extensions for 5G-LENA]](medium size project, 250h)<br /> * [[#5G NR module integration with ns-3-ai]] (large size project, 250h)<br /> <br /> == Small sized projects (90 hours) ==<br /> <br /> === Flent Application API in ns-3 ===<br /> <br /> Mentors: [mailto:tahiliani.nitk@gmail.com Mohit P. Tahiliani]<br /> <br /> 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) complete the implementation of Flent application API in ns-3 based on the latest ns-3-dev, (2) enable support for multiple ns-3 applications in the Flent application API (3) add more examples (i.e., Flent tests) in ns-3 to better suit the needs of researchers working in this area, and (4) merge Flent application API in the mainline of ns-3.<br /> <br /> * ''Required Experience:'' Familiarity with Flent and C++ programming.<br /> * ''Bonus Experience:'' Familiarity with applications supported in ns-3.<br /> * ''Interests:'' Bufferbloat, TCP, AQM algorithms and ECN.<br /> * ''Difficulty:'' Medium.<br /> * ''Recommended Reading:''<br /> ** Flexible Network Tester [[https://flent.org/flent-the-flexible-network-tester.pdf Paper]] [[https://flent.org/ Tool]]<br /> ** [https://www.nsnam.org/doxygen/d9/dc9/group__applications.html#details Existing Applications in ns-3]<br /> ** [https://gitlab.com/tomhenderson/ns-3-dev/-/commits/flent?ref_type=heads Prior work on Flent application API in ns-3]<br /> <br /> === Internet routing refactory ===<br /> <br /> Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], [TBD].<br /> <br /> 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.<br /> <br /> In ns-3 this is accomplished by storing three separate objects, two Ipv[4,6]Address, and one Ipv[4Mask,6Prefix].<br /> <br /> While this is quite simple to implement, this has some notable drawbacks, e.g., the Dst address must be a network address (Dst &amp; ~DstMask == 0), it is not efficient (the mask or prefix could be represented by a simple integer), and more.<br /> <br /> In order to improve code readability and consistency between IPv4 and IPv6, !2645 introduces two new classes: Ipv[4,6]NetworkAddress.<br /> <br /> The goal is to refactor the existing routing classes, along with Ipv[4,6]RotingTable classes, so that they use the new classes.<br /> <br /> 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.<br /> <br /> Another very important requirement will be to break down the work in multiple sub-tasks, so that the merge process can be gradual.<br /> <br /> 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 clearr and motivated.<br /> <br /> * ''Required Experience:'' Fundamentals of IPv6 addressing and routing, C++ programming.<br /> * ''Interests:'' IPv4 and IPv6 routing<br /> * ''Difficulty:'' Easy.<br /> * ''Recommended reading:''<br /> ** [https://gitlab.com/nsnam/ns-3-dev/-/issues/1239 Issue #1239]<br /> ** [https://gitlab.com/nsnam/ns-3-dev/-/merge_requests/2645 Merge Request !2645]<br /> <br /> Possible tasks to fulfill the patch requirement:<br /> * Use !2645 to modify all or in part the `Rip` protocol.<br /> <br /> == Medium sized projects (175 hours) ==<br /> <br /> === 6LoWPAN mesh-under routing enhancements ===<br /> <br /> Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], [TBD].<br /> <br /> 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.<br /> 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.<br /> <br /> The candidate should outline the proposed approach, what parts of code are going to be affected, and how they can be enhanced.<br /> <br /> * ''Required Experience:'' Fundamentals of IPv6 addressing, C++ programming.<br /> * ''Bonus Experience:'' Familiarity with mesh routing and 6LoWPAN ns-3<br /> * ''Interests:'' IPv6 mesh routing<br /> * ''Difficulty:'' Easy.<br /> * ''Recommended reading:''<br /> ** [https://www.nsnam.org/docs/models/html/sixlowpan.html#mesh-under-routing Mesh-under in ns-3 6LoWPAN]<br /> ** [https://datatracker.ietf.org/doc/html/rfc7731 RFC 7731]<br /> ** [https://meshtastic.org/docs/overview/mesh-algo/ Meshtastic controlled flooding]<br /> ** [https://ieeexplore.ieee.org/document/91339 Routing by controlled flooding in communication networks] (if the document can not be accessed, PM the mentors)<br /> <br /> Possible tasks to fulfill the patch requirement:<br /> * 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 &quot;next hop&quot;. The behavior of the actual protocol should be unchanged.<br /> <br /> === 6LoWPAN neighbor discovery protocol ===<br /> <br /> Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], [mailto:adnan.rashid@poliba.it Adnan Rashid].<br /> <br /> 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.<br /> <br /> 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.<br /> <br /> 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.<br /> <br /> * ''Required Experience:'' Fundamentals of IPv6 addressing, C++ programming.<br /> * ''Bonus Experience:'' Familiarity with 6LoWPAN and 6LoWPAN-ND<br /> * ''Interests:'' IPv6 and IoT networks<br /> * ''Difficulty:'' Easy.<br /> * ''Recommended reading:''<br /> ** [https://datatracker.ietf.org/doc/html/rfc8505 RFC 8505]<br /> ** [https://datatracker.ietf.org/doc/html/rfc6775 RFC 6775]<br /> ** [https://datatracker.ietf.org/doc/html/rfc4944 RFC 4944]<br /> ** https://gitlab.com/jieqiboh5836/ns-3-dev/-/tree/6LoWPAN-ND-P1<br /> ** https://gitlab.com/jieqiboh5836/ns-3-dev/-/tree/6LoWPAN-ND-P2<br /> <br /> ===OLLA Link Adaptation and Spec-Compliant TBS Calculation for 5G-LENA===<br /> <br /> 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]<br /> <br /> 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.<br /> 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.<br /> <br /> 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.<br /> <br /> *Required Experience: C++ programming, understanding of 5G NR MAC concepts (scheduling, CQI/MCS, HARQ), wireless networking fundamentals<br /> *Interests: 5G NR simulations, scheduling, link adaptation, performance evaluation<br /> *Difficulty: Medium<br /> *Project size: Medium<br /> *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.<br /> <br /> === Enabling 5G NR examples visualization ===<br /> <br /> 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]<br /> <br /> 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.<br /> <br /> 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.<br /> 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].<br /> <br /> * Required Experience: C++ and Python programming, understanding of 5G NR, LTE, and wireless networks<br /> * Interests: 5G NR simulations<br /> * Difficulty: Medium.<br /> * 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.<br /> <br /> === AODVv2 Protocol enhancements ===<br /> <br /> Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], [TBD].<br /> <br /> 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.<br /> <br /> In particular the project should address the following points:<br /> # Alignment with the latest drafts,<br /> # Model finalization and testing (in particular for the IPv6 part),<br /> # AODVv2 examples and documentation,<br /> # &quot;External&quot; network routing support.<br /> <br /> Collaboration with the draft authors is also highly suggested.<br /> <br /> * ''Required Experience:'' Fundamentals of IPv6 addressing, C++ programming.<br /> * ''Bonus Experience:'' Familiarity with AODV implementations in ns-3 and AODVv2<br /> * ''Interests:'' Ad hoc routing<br /> * ''Difficulty:'' Medium.<br /> * ''Recommended reading:''<br /> ** [https://www.nsnam.org/docs/models/html/ipv6.html IPv6 model in ns-3]<br /> ** [https://www.nsnam.org/docs/models/html/aodv.html AODV model in ns-3]<br /> ** [https://gitlab.com/tod97/ns-3-dev/-/tree/aodvv2-icns3-25 AODVv2 model presented at ICNS3-2025] <br /> ** [https://datatracker.ietf.org/doc/draft-perkins-manet-aodvv2/05/ Ad Hoc On-demand Distance Vector Version 2 (AODVv2) Routing]<br /> <br /> Possible tasks to fulfill the patch requirement:<br /> * [https://gitlab.com/nsnam/ns-3-dev/-/issues/368 Issue #368] - aodv: aodv parameters can be set to &quot;impossible&quot; values<br /> <br /> == Large projects (350 hours) ==<br /> <br /> === Mesh Link Establishment (MLE) protocol ===<br /> <br /> Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], [mailto:alramonet@is.tokushima-u.ac.jp Alberto Gallegos Ramonet].<br /> <br /> 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.<br /> However, MLE is being used in Thread, and it can be useful to implement it.<br /> <br /> 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.<br /> <br /> * ''Required Experience:'' Fundamentals of IPv4 and IPv6 sockets, C++ programming.<br /> * ''Interests:'' Sockets and API interface implementation.<br /> * ''Difficulty:'' Hard.<br /> * ''Recommended reading:''<br /> ** [https://datatracker.ietf.org/doc/html/draft-ietf-6lo-mesh-link-establishment MLE draft]<br /> ** [https://openthread.io/guides/thread-primer/network-discovery Thread primer]<br /> ** [https://www.threadgroup.org/ThreadSpec Thread specifications]<br /> <br /> Possible tasks to fulfill the patch requirement:<br /> * TBD, contact the mentors if interested.<br /> <br /> ===Energy Consumption Modeling and Power-Aware Extensions for 5G-LENA===<br /> <br /> 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]<br /> <br /> 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.<br /> 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.<br /> 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.<br /> <br /> Scope (expected deliverables):<br /> *Energy consumption accounting for UEs and/or gNBs<br /> *Per-state (and if feasible per-procedure) modeling, e.g.<br /> **gNB: idle/active/sleep, TX/RX, processing; dependence on bandwidth/PRBs, TX power, MIMO layers/streams/RF chains, load<br /> **UE: TX/RX, measurements, CSI-RS/SRS activity, beamforming-related processing, handover<br /> *Tracing, example(s), and documentation<br /> <br /> 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)<br /> <br /> *Required Experience: C++ programming, wireless networking fundamentals (energy/state-machine modeling is a plus)<br /> *Interests: 5G NR simulations, energy efficiency, green networking, 6G sustainability<br /> *Difficulty: Medium<br /> *Project size: Medium<br /> *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.<br /> <br /> === 5G NR module integration with ns-3-ai ===<br /> <br /> 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]<br /> <br /> 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.<br /> <br /> 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.<br /> For more specific guidelines, please view this [https://docs.google.com/document/d/1cQLIF1cdft1yj3vyWrjrxN2xDJMx8PuWaa9NP_nKf64/edit?usp=sharing Google document].<br /> <br /> * Required Experience: C++ programming, understanding of 5G NR, LTE, and wireless networks<br /> * Interests: 5G NR simulations<br /> * Difficulty: Medium.<br /> * 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.<br /> <br /> === Linux-like CAKE queue discipline for ns-3 ===<br /> <br /> Mentors: [mailto:tahiliani.nitk@gmail.com Mohit P. Tahiliani]<br /> <br /> 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.<br /> <br /> * ''Required Experience:'' Familiarity with queue disciplines, TCP and C++ programming.<br /> * ''Bonus Experience:'' Familiarity with CAKE framework in Linux 4.19<br /> * ''Interests:'' Active Queue Management, Packet scheduling and TCP.<br /> * ''Difficulty:'' Medium to Hard<br /> * ''Recommended reading:''<br /> ** [https://arxiv.org/pdf/1804.07617.pdf Piece of CAKE: A Comprehensive Queue Management Solution for Home Gateways]<br /> ** [https://lwn.net/Articles/758353/ Let them run CAKE]<br /> ** [https://www.nsnam.org/docs/models/html/queue-discs.html Queue disciplines in ns-3]<br /> <br /> === Switched Ethernet ===<br /> <br /> Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], TBD.<br /> <br /> 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.<br /> <br /> 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.<br /> <br /> 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.<br /> <br /> 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.<br /> <br /> 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.<br /> <br /> * ''Required Experience:'' Fundamentals of Ethernet sitched networking, C++ programming.<br /> * ''Interests:'' Ethernet networks and switched data networks.<br /> * ''Difficulty:'' Medium.<br /> * ''Recommended reading:''<br /> ** [https://www2.nsnam.org/bugzilla/show_bug.cgi?id=2602 Basic implementation (very old)]<br /> ** [https://gitlab.com/nsnam/ns-3-dev/-/merge_requests/431 Full-duplex CSMA, somehow related]<br /> ** [https://tcipg.org/sites/default/files/papers/2010_Jin_Nicol_Caesar.pdf Paper on gigabit Ethernet switch models for simulation]<br /> <br /> Possible tasks to fulfill the patch requirement:<br /> * TBD, contact the mentors if interested.</div>

Tommaso https://www.nsnam.org/mediawiki/index.php?title=GSOC2026Projects&diff=13750 2026-02-09T22:29:48Z

<p>Tommaso: /* Internet models enhancements */</p> <hr /> <div>{{TOC}}<br /> <br /> This page contains 2026 Google Summer of Code project ideas for ns-3.<br /> <br /> * [https://developers.google.com/open-source/gsoc/faq GSoC Frequently Asked Questions]<br /> * [[GSOC2026ContributorGuide | ns-3's 2026 GSoC Contributor guide]]<br /> * [https://developers.google.com/open-source/gsoc/resources/guide GSoC contributor/student guide (not ns-3 specific)]<br /> * [[GSOC2025ApplicationTemplate | 2026 GSoC Contributor application template]]<br /> * [[GSOCMentorGuide | ns-3's GSoC Mentor guide]]<br /> * [https://archive.flossmanuals.net/gsocmentoring/index.html GSoC Mentor guide (not ns-3 specific)]<br /> * [[GSOCSelectionProcess | GSoC Contributor Selection Process]]<br /> * ''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/<br /> <br /> === About the ns-3 project ===<br /> <br /> ns-3 is a discrete-event network simulator, with a particular emphasis on network research and education.<br /> <br /> 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.<br /> <br /> 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.<br /> <br /> === Org admins ===<br /> <br /> 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].<br /> <br /> === Mentors ===<br /> <br /> 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.<br /> <br /> The current list of prospective mentors can be found among the ideas listed below.<br /> <br /> === How to apply ===<br /> <br /> For students or contributors interested in applying to ns-3 for GSoC, please go through the following list to get started:<br /> * Read the official [https://developers.google.com/open-source/gsoc/resources/guide GSoC contributor guide].<br /> * Read [[GSOC2026ContributorGuide |ns-3's 2026 GSoC contributor guide]]<br /> * Look through our [[#Project Ideas]] below to see if you find a project that interests you.<br /> * Review the [https://www.nsnam.org/documentation/development-tree/ tutorial and contributing guide] thoroughly, if you have not already done so.<br /> * 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.<br /> * Next, proceed to get in touch with the developers on the mailing list or Zulip chat room and refine your proposal.<br /> * 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.<br /> <br /> 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.<br /> <br /> &lt;blockquote&gt;<br /> Each project idea within a particular priority has been tagged with the following properties:<br /> * ''Required Experience:'' Languages, concepts, or packages with which applicants must be familiar.<br /> * ''Bonus Experience:'' Other experience or familiarity which would be greatly helpful to applicants for this project.<br /> * ''Interests:'' Areas of particular relevance to this project, and an indicator of where successful contributors might apply their experiences coming out of this project.<br /> * ''Difficulty:'' easy, medium or difficult<br /> * ''Recommended reading:'' pointers to documentation, papers, specific bugs, etc.<br /> <br /> 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.<br /> &lt;/blockquote&gt;<br /> <br /> === Patch requirement guidelines ===<br /> <br /> 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.<br /> <br /> === Mentors: how to participate ===<br /> <br /> 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:<br /> <br /> * 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.<br /> * 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.<br /> * 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.<br /> <br /> == Project Ideas ==<br /> <br /> '''Note to contributors:''' These ideas are not listed in any priority order.<br /> 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.<br /> <br /> === Internet models enhancements ===<br /> <br /> * [[#Internet routing refactory]] (small size project, 90h)<br /> * [[#AODVv2 Protocol enhancements]] (medium size project, 175h)<br /> * [[#Linux-like CAKE queue discipline for ns-3]] (large size project, 350h)<br /> * [[#Switched Ethernet]] (large size project, 350h)<br /> <br /> === IoT models enhancements ===<br /> <br /> * [[#6LoWPAN mesh-under routing enhancements]] (medium size project, 175h)<br /> * [[#6LoWPAN neighbor discovery protocol]] (medium size project, 175h)<br /> * [[#Mesh Link Establishment (MLE) protocol ]] (large size project, 350h)<br /> <br /> === 5G NR models enhancements ===<br /> <br /> 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.<br /> <br /> * [[#OLLA Link Adaptation and Spec-Compliant TBS Calculation for 5G-LENA]](medium size project, 175h)<br /> * [[#Enabling 5G NR examples visualization]] (medium size project, 175h)<br /> * [[#Energy Consumption Modeling and Power-Aware Extensions for 5G-LENA]](medium size project, 250h)<br /> * [[#5G NR module integration with ns-3-ai]] (large size project, 250h)<br /> <br /> == Small sized projects (90 hours) ==<br /> <br /> === Flent Application API in ns-3 ===<br /> <br /> Mentors: [mailto:tahiliani.nitk@gmail.com Mohit P. Tahiliani]<br /> <br /> 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) complete the implementation of Flent application API in ns-3 based on the latest ns-3-dev, (2) enable support for multiple ns-3 applications in the Flent application API (3) add more examples (i.e., Flent tests) in ns-3 to better suit the needs of researchers working in this area, and (4) merge Flent application API in the mainline of ns-3.<br /> <br /> * ''Required Experience:'' Familiarity with Flent and C++ programming.<br /> * ''Bonus Experience:'' Familiarity with applications supported in ns-3.<br /> * ''Interests:'' Bufferbloat, TCP, AQM algorithms and ECN.<br /> * ''Difficulty:'' Medium.<br /> * ''Recommended Reading:''<br /> ** Flexible Network Tester [[https://flent.org/flent-the-flexible-network-tester.pdf Paper]] [[https://flent.org/ Tool]]<br /> ** [https://www.nsnam.org/doxygen/d9/dc9/group__applications.html#details Existing Applications in ns-3]<br /> ** [https://gitlab.com/tomhenderson/ns-3-dev/-/commits/flent?ref_type=heads Prior work on Flent application API in ns-3]<br /> <br /> === Internet routing refactory ===<br /> <br /> Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], [TBD].<br /> <br /> 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.<br /> <br /> In ns-3 this is accomplished by storing three separate objects, two Ipv[4,6]Address, and one Ipv[4Mask,6Prefix].<br /> <br /> While this is quite simple to implement, this has some notable drawbacks, e.g., the Dst address must be a network address (Dst &amp; ~DstMask == 0), it is not efficient (the mask or prefix could be represented by a simple integer), and more.<br /> <br /> In order to improve code readability and consistency between IPv4 and IPv6, !2645 introduces two new classes: Ipv[4,6]NetworkAddress.<br /> <br /> The goal is to refactor the existing routing classes, along with Ipv[4,6]RotingTable classes, so that they use the new classes.<br /> <br /> 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.<br /> <br /> Another very important requirement will be to break down the work in multiple sub-tasks, so that the merge process can be gradual.<br /> <br /> 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 clearr and motivated.<br /> <br /> * ''Required Experience:'' Fundamentals of IPv6 addressing and routing, C++ programming.<br /> * ''Interests:'' IPv4 and IPv6 routing<br /> * ''Difficulty:'' Easy.<br /> * ''Recommended reading:''<br /> ** [https://gitlab.com/nsnam/ns-3-dev/-/issues/1239 Issue #1239]<br /> ** [https://gitlab.com/nsnam/ns-3-dev/-/merge_requests/2645 Merge Request !2645]<br /> <br /> Possible tasks to fulfill the patch requirement:<br /> * Use !2645 to modify all or in part the `Rip` protocol.<br /> <br /> == Medium sized projects (175 hours) ==<br /> <br /> === 6LoWPAN mesh-under routing enhancements ===<br /> <br /> Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], [TBD].<br /> <br /> 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.<br /> 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.<br /> <br /> The candidate should outline the proposed approach, what parts of code are going to be affected, and how they can be enhanced.<br /> <br /> * ''Required Experience:'' Fundamentals of IPv6 addressing, C++ programming.<br /> * ''Bonus Experience:'' Familiarity with mesh routing and 6LoWPAN ns-3<br /> * ''Interests:'' IPv6 mesh routing<br /> * ''Difficulty:'' Easy.<br /> * ''Recommended reading:''<br /> ** [https://www.nsnam.org/docs/models/html/sixlowpan.html#mesh-under-routing Mesh-under in ns-3 6LoWPAN]<br /> ** [https://datatracker.ietf.org/doc/html/rfc7731 RFC 7731]<br /> ** [https://meshtastic.org/docs/overview/mesh-algo/ Meshtastic controlled flooding]<br /> ** [https://ieeexplore.ieee.org/document/91339 Routing by controlled flooding in communication networks] (if the document can not be accessed, PM the mentors)<br /> <br /> Possible tasks to fulfill the patch requirement:<br /> * 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 &quot;next hop&quot;. The behavior of the actual protocol should be unchanged.<br /> <br /> === 6LoWPAN neighbor discovery protocol ===<br /> <br /> Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], [mailto:adnan.rashid@poliba.it Adnan Rashid].<br /> <br /> 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.<br /> <br /> 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.<br /> <br /> 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.<br /> <br /> * ''Required Experience:'' Fundamentals of IPv6 addressing, C++ programming.<br /> * ''Bonus Experience:'' Familiarity with 6LoWPAN and 6LoWPAN-ND<br /> * ''Interests:'' IPv6 and IoT networks<br /> * ''Difficulty:'' Easy.<br /> * ''Recommended reading:''<br /> ** [https://datatracker.ietf.org/doc/html/rfc8505 RFC 8505]<br /> ** [https://datatracker.ietf.org/doc/html/rfc6775 RFC 6775]<br /> ** [https://datatracker.ietf.org/doc/html/rfc4944 RFC 4944]<br /> ** https://gitlab.com/jieqiboh5836/ns-3-dev/-/tree/6LoWPAN-ND-P1<br /> ** https://gitlab.com/jieqiboh5836/ns-3-dev/-/tree/6LoWPAN-ND-P2<br /> <br /> ===OLLA Link Adaptation and Spec-Compliant TBS Calculation for 5G-LENA===<br /> <br /> 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]<br /> <br /> 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.<br /> 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.<br /> <br /> 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.<br /> <br /> *Required Experience: C++ programming, understanding of 5G NR MAC concepts (scheduling, CQI/MCS, HARQ), wireless networking fundamentals<br /> *Interests: 5G NR simulations, scheduling, link adaptation, performance evaluation<br /> *Difficulty: Medium<br /> *Project size: Medium<br /> *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.<br /> <br /> === Enabling 5G NR examples visualization ===<br /> <br /> 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]<br /> <br /> 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.<br /> <br /> 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.<br /> 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].<br /> <br /> * Required Experience: C++ and Python programming, understanding of 5G NR, LTE, and wireless networks<br /> * Interests: 5G NR simulations<br /> * Difficulty: Medium.<br /> * 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.<br /> <br /> === AODVv2 Protocol enhancements ===<br /> <br /> Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], [TBD].<br /> <br /> 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.<br /> <br /> In particular the project should address the following points:<br /> # Alignment with the latest drafts,<br /> # Model finalization and testing (in particular for the IPv6 part),<br /> # AODVv2 examples and documentation,<br /> # &quot;External&quot; network routing support.<br /> <br /> Collaboration with the draft authors is also highly suggested.<br /> <br /> * ''Required Experience:'' Fundamentals of IPv6 addressing, C++ programming.<br /> * ''Bonus Experience:'' Familiarity with AODV implementations in ns-3 and AODVv2<br /> * ''Interests:'' Ad hoc routing<br /> * ''Difficulty:'' Medium.<br /> * ''Recommended reading:''<br /> ** [https://www.nsnam.org/docs/models/html/ipv6.html IPv6 model in ns-3]<br /> ** [https://www.nsnam.org/docs/models/html/aodv.html AODV model in ns-3]<br /> ** [https://gitlab.com/tod97/ns-3-dev/-/tree/aodvv2-icns3-25 AODVv2 model presented at ICNS3-2025] <br /> ** [https://datatracker.ietf.org/doc/draft-perkins-manet-aodvv2/05/ Ad Hoc On-demand Distance Vector Version 2 (AODVv2) Routing]<br /> <br /> Possible tasks to fulfill the patch requirement:<br /> * [https://gitlab.com/nsnam/ns-3-dev/-/issues/368 Issue #368] - aodv: aodv parameters can be set to &quot;impossible&quot; values<br /> <br /> == Large projects (350 hours) ==<br /> <br /> === Mesh Link Establishment (MLE) protocol ===<br /> <br /> Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], [mailto:alramonet@is.tokushima-u.ac.jp Alberto Gallegos Ramonet].<br /> <br /> 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.<br /> However, MLE is being used in Thread, and it can be useful to implement it.<br /> <br /> 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.<br /> <br /> * ''Required Experience:'' Fundamentals of IPv4 and IPv6 sockets, C++ programming.<br /> * ''Interests:'' Sockets and API interface implementation.<br /> * ''Difficulty:'' Hard.<br /> * ''Recommended reading:''<br /> ** [https://datatracker.ietf.org/doc/html/draft-ietf-6lo-mesh-link-establishment MLE draft]<br /> ** [https://openthread.io/guides/thread-primer/network-discovery Thread primer]<br /> ** [https://www.threadgroup.org/ThreadSpec Thread specifications]<br /> <br /> Possible tasks to fulfill the patch requirement:<br /> * TBD, contact the mentors if interested.<br /> <br /> ===Energy Consumption Modeling and Power-Aware Extensions for 5G-LENA===<br /> <br /> 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]<br /> <br /> 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.<br /> 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.<br /> 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.<br /> <br /> Scope (expected deliverables):<br /> *Energy consumption accounting for UEs and/or gNBs<br /> *Per-state (and if feasible per-procedure) modeling, e.g.<br /> **gNB: idle/active/sleep, TX/RX, processing; dependence on bandwidth/PRBs, TX power, MIMO layers/streams/RF chains, load<br /> **UE: TX/RX, measurements, CSI-RS/SRS activity, beamforming-related processing, handover<br /> *Tracing, example(s), and documentation<br /> <br /> 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)<br /> <br /> *Required Experience: C++ programming, wireless networking fundamentals (energy/state-machine modeling is a plus)<br /> *Interests: 5G NR simulations, energy efficiency, green networking, 6G sustainability<br /> *Difficulty: Medium<br /> *Project size: Medium<br /> *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.<br /> <br /> === 5G NR module integration with ns-3-ai ===<br /> <br /> 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]<br /> <br /> 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.<br /> <br /> 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.<br /> For more specific guidelines, please view this [https://docs.google.com/document/d/1cQLIF1cdft1yj3vyWrjrxN2xDJMx8PuWaa9NP_nKf64/edit?usp=sharing Google document].<br /> <br /> * Required Experience: C++ programming, understanding of 5G NR, LTE, and wireless networks<br /> * Interests: 5G NR simulations<br /> * Difficulty: Medium.<br /> * 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.<br /> <br /> === Linux-like CAKE queue discipline for ns-3 ===<br /> <br /> Mentors: [mailto:tahiliani.nitk@gmail.com Mohit P. Tahiliani]<br /> <br /> 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.<br /> <br /> * ''Required Experience:'' Familiarity with queue disciplines, TCP and C++ programming.<br /> * ''Bonus Experience:'' Familiarity with CAKE framework in Linux 4.19<br /> * ''Interests:'' Active Queue Management, Packet scheduling and TCP.<br /> * ''Difficulty:'' Medium to Hard<br /> * ''Recommended reading:''<br /> ** [https://arxiv.org/pdf/1804.07617.pdf Piece of CAKE: A Comprehensive Queue Management Solution for Home Gateways]<br /> ** [https://lwn.net/Articles/758353/ Let them run CAKE]<br /> ** [https://www.nsnam.org/docs/models/html/queue-discs.html Queue disciplines in ns-3]<br /> <br /> === Switched Ethernet ===<br /> <br /> Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], TBD.<br /> <br /> 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.<br /> <br /> 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.<br /> <br /> 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.<br /> <br /> 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.<br /> <br /> 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.<br /> <br /> * ''Required Experience:'' Fundamentals of Ethernet sitched networking, C++ programming.<br /> * ''Interests:'' Ethernet networks and switched data networks.<br /> * ''Difficulty:'' Medium.<br /> * ''Recommended reading:''<br /> ** [https://www2.nsnam.org/bugzilla/show_bug.cgi?id=2602 Basic implementation (very old)]<br /> ** [https://gitlab.com/nsnam/ns-3-dev/-/merge_requests/431 Full-duplex CSMA, somehow related]<br /> ** [https://tcipg.org/sites/default/files/papers/2010_Jin_Nicol_Caesar.pdf Paper on gigabit Ethernet switch models for simulation]<br /> <br /> Possible tasks to fulfill the patch requirement:<br /> * TBD, contact the mentors if interested.</div>

Tommaso https://www.nsnam.org/mediawiki/index.php?title=GSOC2026Projects&diff=13749 2026-02-09T22:29:08Z

<p>Tommaso: /* Small sized projects (90 hours) */</p> <hr /> <div>{{TOC}}<br /> <br /> This page contains 2026 Google Summer of Code project ideas for ns-3.<br /> <br /> * [https://developers.google.com/open-source/gsoc/faq GSoC Frequently Asked Questions]<br /> * [[GSOC2026ContributorGuide | ns-3's 2026 GSoC Contributor guide]]<br /> * [https://developers.google.com/open-source/gsoc/resources/guide GSoC contributor/student guide (not ns-3 specific)]<br /> * [[GSOC2025ApplicationTemplate | 2026 GSoC Contributor application template]]<br /> * [[GSOCMentorGuide | ns-3's GSoC Mentor guide]]<br /> * [https://archive.flossmanuals.net/gsocmentoring/index.html GSoC Mentor guide (not ns-3 specific)]<br /> * [[GSOCSelectionProcess | GSoC Contributor Selection Process]]<br /> * ''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/<br /> <br /> === About the ns-3 project ===<br /> <br /> ns-3 is a discrete-event network simulator, with a particular emphasis on network research and education.<br /> <br /> 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.<br /> <br /> 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.<br /> <br /> === Org admins ===<br /> <br /> 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].<br /> <br /> === Mentors ===<br /> <br /> 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.<br /> <br /> The current list of prospective mentors can be found among the ideas listed below.<br /> <br /> === How to apply ===<br /> <br /> For students or contributors interested in applying to ns-3 for GSoC, please go through the following list to get started:<br /> * Read the official [https://developers.google.com/open-source/gsoc/resources/guide GSoC contributor guide].<br /> * Read [[GSOC2026ContributorGuide |ns-3's 2026 GSoC contributor guide]]<br /> * Look through our [[#Project Ideas]] below to see if you find a project that interests you.<br /> * Review the [https://www.nsnam.org/documentation/development-tree/ tutorial and contributing guide] thoroughly, if you have not already done so.<br /> * 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.<br /> * Next, proceed to get in touch with the developers on the mailing list or Zulip chat room and refine your proposal.<br /> * 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.<br /> <br /> 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.<br /> <br /> &lt;blockquote&gt;<br /> Each project idea within a particular priority has been tagged with the following properties:<br /> * ''Required Experience:'' Languages, concepts, or packages with which applicants must be familiar.<br /> * ''Bonus Experience:'' Other experience or familiarity which would be greatly helpful to applicants for this project.<br /> * ''Interests:'' Areas of particular relevance to this project, and an indicator of where successful contributors might apply their experiences coming out of this project.<br /> * ''Difficulty:'' easy, medium or difficult<br /> * ''Recommended reading:'' pointers to documentation, papers, specific bugs, etc.<br /> <br /> 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.<br /> &lt;/blockquote&gt;<br /> <br /> === Patch requirement guidelines ===<br /> <br /> 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.<br /> <br /> === Mentors: how to participate ===<br /> <br /> 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:<br /> <br /> * 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.<br /> * 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.<br /> * 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.<br /> <br /> == Project Ideas ==<br /> <br /> '''Note to contributors:''' These ideas are not listed in any priority order.<br /> 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.<br /> <br /> === Internet models enhancements ===<br /> <br /> * [[#AODVv2 Protocol enhancements]] (medium size project, 175h)<br /> * [[#Linux-like CAKE queue discipline for ns-3]] (large size project, 350h)<br /> * [[#Switched Ethernet]] (large size project, 350h)<br /> <br /> === IoT models enhancements ===<br /> <br /> * [[#6LoWPAN mesh-under routing enhancements]] (medium size project, 175h)<br /> * [[#6LoWPAN neighbor discovery protocol]] (medium size project, 175h)<br /> * [[#Mesh Link Establishment (MLE) protocol ]] (large size project, 350h)<br /> <br /> === 5G NR models enhancements ===<br /> <br /> 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.<br /> <br /> * [[#OLLA Link Adaptation and Spec-Compliant TBS Calculation for 5G-LENA]](medium size project, 175h)<br /> * [[#Enabling 5G NR examples visualization]] (medium size project, 175h)<br /> * [[#Energy Consumption Modeling and Power-Aware Extensions for 5G-LENA]](medium size project, 250h)<br /> * [[#5G NR module integration with ns-3-ai]] (large size project, 250h)<br /> <br /> == Small sized projects (90 hours) ==<br /> <br /> === Flent Application API in ns-3 ===<br /> <br /> Mentors: [mailto:tahiliani.nitk@gmail.com Mohit P. Tahiliani]<br /> <br /> 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) complete the implementation of Flent application API in ns-3 based on the latest ns-3-dev, (2) enable support for multiple ns-3 applications in the Flent application API (3) add more examples (i.e., Flent tests) in ns-3 to better suit the needs of researchers working in this area, and (4) merge Flent application API in the mainline of ns-3.<br /> <br /> * ''Required Experience:'' Familiarity with Flent and C++ programming.<br /> * ''Bonus Experience:'' Familiarity with applications supported in ns-3.<br /> * ''Interests:'' Bufferbloat, TCP, AQM algorithms and ECN.<br /> * ''Difficulty:'' Medium.<br /> * ''Recommended Reading:''<br /> ** Flexible Network Tester [[https://flent.org/flent-the-flexible-network-tester.pdf Paper]] [[https://flent.org/ Tool]]<br /> ** [https://www.nsnam.org/doxygen/d9/dc9/group__applications.html#details Existing Applications in ns-3]<br /> ** [https://gitlab.com/tomhenderson/ns-3-dev/-/commits/flent?ref_type=heads Prior work on Flent application API in ns-3]<br /> <br /> === Internet routing refactory ===<br /> <br /> Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], [TBD].<br /> <br /> 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.<br /> <br /> In ns-3 this is accomplished by storing three separate objects, two Ipv[4,6]Address, and one Ipv[4Mask,6Prefix].<br /> <br /> While this is quite simple to implement, this has some notable drawbacks, e.g., the Dst address must be a network address (Dst &amp; ~DstMask == 0), it is not efficient (the mask or prefix could be represented by a simple integer), and more.<br /> <br /> In order to improve code readability and consistency between IPv4 and IPv6, !2645 introduces two new classes: Ipv[4,6]NetworkAddress.<br /> <br /> The goal is to refactor the existing routing classes, along with Ipv[4,6]RotingTable classes, so that they use the new classes.<br /> <br /> 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.<br /> <br /> Another very important requirement will be to break down the work in multiple sub-tasks, so that the merge process can be gradual.<br /> <br /> 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 clearr and motivated.<br /> <br /> * ''Required Experience:'' Fundamentals of IPv6 addressing and routing, C++ programming.<br /> * ''Interests:'' IPv4 and IPv6 routing<br /> * ''Difficulty:'' Easy.<br /> * ''Recommended reading:''<br /> ** [https://gitlab.com/nsnam/ns-3-dev/-/issues/1239 Issue #1239]<br /> ** [https://gitlab.com/nsnam/ns-3-dev/-/merge_requests/2645 Merge Request !2645]<br /> <br /> Possible tasks to fulfill the patch requirement:<br /> * Use !2645 to modify all or in part the `Rip` protocol.<br /> <br /> == Medium sized projects (175 hours) ==<br /> <br /> === 6LoWPAN mesh-under routing enhancements ===<br /> <br /> Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], [TBD].<br /> <br /> 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.<br /> 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.<br /> <br /> The candidate should outline the proposed approach, what parts of code are going to be affected, and how they can be enhanced.<br /> <br /> * ''Required Experience:'' Fundamentals of IPv6 addressing, C++ programming.<br /> * ''Bonus Experience:'' Familiarity with mesh routing and 6LoWPAN ns-3<br /> * ''Interests:'' IPv6 mesh routing<br /> * ''Difficulty:'' Easy.<br /> * ''Recommended reading:''<br /> ** [https://www.nsnam.org/docs/models/html/sixlowpan.html#mesh-under-routing Mesh-under in ns-3 6LoWPAN]<br /> ** [https://datatracker.ietf.org/doc/html/rfc7731 RFC 7731]<br /> ** [https://meshtastic.org/docs/overview/mesh-algo/ Meshtastic controlled flooding]<br /> ** [https://ieeexplore.ieee.org/document/91339 Routing by controlled flooding in communication networks] (if the document can not be accessed, PM the mentors)<br /> <br /> Possible tasks to fulfill the patch requirement:<br /> * 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 &quot;next hop&quot;. The behavior of the actual protocol should be unchanged.<br /> <br /> === 6LoWPAN neighbor discovery protocol ===<br /> <br /> Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], [mailto:adnan.rashid@poliba.it Adnan Rashid].<br /> <br /> 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.<br /> <br /> 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.<br /> <br /> 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.<br /> <br /> * ''Required Experience:'' Fundamentals of IPv6 addressing, C++ programming.<br /> * ''Bonus Experience:'' Familiarity with 6LoWPAN and 6LoWPAN-ND<br /> * ''Interests:'' IPv6 and IoT networks<br /> * ''Difficulty:'' Easy.<br /> * ''Recommended reading:''<br /> ** [https://datatracker.ietf.org/doc/html/rfc8505 RFC 8505]<br /> ** [https://datatracker.ietf.org/doc/html/rfc6775 RFC 6775]<br /> ** [https://datatracker.ietf.org/doc/html/rfc4944 RFC 4944]<br /> ** https://gitlab.com/jieqiboh5836/ns-3-dev/-/tree/6LoWPAN-ND-P1<br /> ** https://gitlab.com/jieqiboh5836/ns-3-dev/-/tree/6LoWPAN-ND-P2<br /> <br /> ===OLLA Link Adaptation and Spec-Compliant TBS Calculation for 5G-LENA===<br /> <br /> 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]<br /> <br /> 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.<br /> 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.<br /> <br /> 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.<br /> <br /> *Required Experience: C++ programming, understanding of 5G NR MAC concepts (scheduling, CQI/MCS, HARQ), wireless networking fundamentals<br /> *Interests: 5G NR simulations, scheduling, link adaptation, performance evaluation<br /> *Difficulty: Medium<br /> *Project size: Medium<br /> *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.<br /> <br /> === Enabling 5G NR examples visualization ===<br /> <br /> 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]<br /> <br /> 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.<br /> <br /> 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.<br /> 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].<br /> <br /> * Required Experience: C++ and Python programming, understanding of 5G NR, LTE, and wireless networks<br /> * Interests: 5G NR simulations<br /> * Difficulty: Medium.<br /> * 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.<br /> <br /> === AODVv2 Protocol enhancements ===<br /> <br /> Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], [TBD].<br /> <br /> 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.<br /> <br /> In particular the project should address the following points:<br /> # Alignment with the latest drafts,<br /> # Model finalization and testing (in particular for the IPv6 part),<br /> # AODVv2 examples and documentation,<br /> # &quot;External&quot; network routing support.<br /> <br /> Collaboration with the draft authors is also highly suggested.<br /> <br /> * ''Required Experience:'' Fundamentals of IPv6 addressing, C++ programming.<br /> * ''Bonus Experience:'' Familiarity with AODV implementations in ns-3 and AODVv2<br /> * ''Interests:'' Ad hoc routing<br /> * ''Difficulty:'' Medium.<br /> * ''Recommended reading:''<br /> ** [https://www.nsnam.org/docs/models/html/ipv6.html IPv6 model in ns-3]<br /> ** [https://www.nsnam.org/docs/models/html/aodv.html AODV model in ns-3]<br /> ** [https://gitlab.com/tod97/ns-3-dev/-/tree/aodvv2-icns3-25 AODVv2 model presented at ICNS3-2025] <br /> ** [https://datatracker.ietf.org/doc/draft-perkins-manet-aodvv2/05/ Ad Hoc On-demand Distance Vector Version 2 (AODVv2) Routing]<br /> <br /> Possible tasks to fulfill the patch requirement:<br /> * [https://gitlab.com/nsnam/ns-3-dev/-/issues/368 Issue #368] - aodv: aodv parameters can be set to &quot;impossible&quot; values<br /> <br /> == Large projects (350 hours) ==<br /> <br /> === Mesh Link Establishment (MLE) protocol ===<br /> <br /> Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], [mailto:alramonet@is.tokushima-u.ac.jp Alberto Gallegos Ramonet].<br /> <br /> 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.<br /> However, MLE is being used in Thread, and it can be useful to implement it.<br /> <br /> 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.<br /> <br /> * ''Required Experience:'' Fundamentals of IPv4 and IPv6 sockets, C++ programming.<br /> * ''Interests:'' Sockets and API interface implementation.<br /> * ''Difficulty:'' Hard.<br /> * ''Recommended reading:''<br /> ** [https://datatracker.ietf.org/doc/html/draft-ietf-6lo-mesh-link-establishment MLE draft]<br /> ** [https://openthread.io/guides/thread-primer/network-discovery Thread primer]<br /> ** [https://www.threadgroup.org/ThreadSpec Thread specifications]<br /> <br /> Possible tasks to fulfill the patch requirement:<br /> * TBD, contact the mentors if interested.<br /> <br /> ===Energy Consumption Modeling and Power-Aware Extensions for 5G-LENA===<br /> <br /> 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]<br /> <br /> 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.<br /> 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.<br /> 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.<br /> <br /> Scope (expected deliverables):<br /> *Energy consumption accounting for UEs and/or gNBs<br /> *Per-state (and if feasible per-procedure) modeling, e.g.<br /> **gNB: idle/active/sleep, TX/RX, processing; dependence on bandwidth/PRBs, TX power, MIMO layers/streams/RF chains, load<br /> **UE: TX/RX, measurements, CSI-RS/SRS activity, beamforming-related processing, handover<br /> *Tracing, example(s), and documentation<br /> <br /> 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)<br /> <br /> *Required Experience: C++ programming, wireless networking fundamentals (energy/state-machine modeling is a plus)<br /> *Interests: 5G NR simulations, energy efficiency, green networking, 6G sustainability<br /> *Difficulty: Medium<br /> *Project size: Medium<br /> *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.<br /> <br /> === 5G NR module integration with ns-3-ai ===<br /> <br /> 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]<br /> <br /> 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.<br /> <br /> 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.<br /> For more specific guidelines, please view this [https://docs.google.com/document/d/1cQLIF1cdft1yj3vyWrjrxN2xDJMx8PuWaa9NP_nKf64/edit?usp=sharing Google document].<br /> <br /> * Required Experience: C++ programming, understanding of 5G NR, LTE, and wireless networks<br /> * Interests: 5G NR simulations<br /> * Difficulty: Medium.<br /> * 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.<br /> <br /> === Linux-like CAKE queue discipline for ns-3 ===<br /> <br /> Mentors: [mailto:tahiliani.nitk@gmail.com Mohit P. Tahiliani]<br /> <br /> 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.<br /> <br /> * ''Required Experience:'' Familiarity with queue disciplines, TCP and C++ programming.<br /> * ''Bonus Experience:'' Familiarity with CAKE framework in Linux 4.19<br /> * ''Interests:'' Active Queue Management, Packet scheduling and TCP.<br /> * ''Difficulty:'' Medium to Hard<br /> * ''Recommended reading:''<br /> ** [https://arxiv.org/pdf/1804.07617.pdf Piece of CAKE: A Comprehensive Queue Management Solution for Home Gateways]<br /> ** [https://lwn.net/Articles/758353/ Let them run CAKE]<br /> ** [https://www.nsnam.org/docs/models/html/queue-discs.html Queue disciplines in ns-3]<br /> <br /> === Switched Ethernet ===<br /> <br /> Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], TBD.<br /> <br /> 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.<br /> <br /> 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.<br /> <br /> 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.<br /> <br /> 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.<br /> <br /> 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.<br /> <br /> * ''Required Experience:'' Fundamentals of Ethernet sitched networking, C++ programming.<br /> * ''Interests:'' Ethernet networks and switched data networks.<br /> * ''Difficulty:'' Medium.<br /> * ''Recommended reading:''<br /> ** [https://www2.nsnam.org/bugzilla/show_bug.cgi?id=2602 Basic implementation (very old)]<br /> ** [https://gitlab.com/nsnam/ns-3-dev/-/merge_requests/431 Full-duplex CSMA, somehow related]<br /> ** [https://tcipg.org/sites/default/files/papers/2010_Jin_Nicol_Caesar.pdf Paper on gigabit Ethernet switch models for simulation]<br /> <br /> Possible tasks to fulfill the patch requirement:<br /> * TBD, contact the mentors if interested.</div>

Tommaso https://www.nsnam.org/mediawiki/index.php?title=GSOC2026Projects&diff=13748 2026-02-09T22:28:54Z

<p>Tommaso: /* Flent Application API in ns-3 */</p> <hr /> <div>{{TOC}}<br /> <br /> This page contains 2026 Google Summer of Code project ideas for ns-3.<br /> <br /> * [https://developers.google.com/open-source/gsoc/faq GSoC Frequently Asked Questions]<br /> * [[GSOC2026ContributorGuide | ns-3's 2026 GSoC Contributor guide]]<br /> * [https://developers.google.com/open-source/gsoc/resources/guide GSoC contributor/student guide (not ns-3 specific)]<br /> * [[GSOC2025ApplicationTemplate | 2026 GSoC Contributor application template]]<br /> * [[GSOCMentorGuide | ns-3's GSoC Mentor guide]]<br /> * [https://archive.flossmanuals.net/gsocmentoring/index.html GSoC Mentor guide (not ns-3 specific)]<br /> * [[GSOCSelectionProcess | GSoC Contributor Selection Process]]<br /> * ''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/<br /> <br /> === About the ns-3 project ===<br /> <br /> ns-3 is a discrete-event network simulator, with a particular emphasis on network research and education.<br /> <br /> 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.<br /> <br /> 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.<br /> <br /> === Org admins ===<br /> <br /> 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].<br /> <br /> === Mentors ===<br /> <br /> 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.<br /> <br /> The current list of prospective mentors can be found among the ideas listed below.<br /> <br /> === How to apply ===<br /> <br /> For students or contributors interested in applying to ns-3 for GSoC, please go through the following list to get started:<br /> * Read the official [https://developers.google.com/open-source/gsoc/resources/guide GSoC contributor guide].<br /> * Read [[GSOC2026ContributorGuide |ns-3's 2026 GSoC contributor guide]]<br /> * Look through our [[#Project Ideas]] below to see if you find a project that interests you.<br /> * Review the [https://www.nsnam.org/documentation/development-tree/ tutorial and contributing guide] thoroughly, if you have not already done so.<br /> * 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.<br /> * Next, proceed to get in touch with the developers on the mailing list or Zulip chat room and refine your proposal.<br /> * 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.<br /> <br /> 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.<br /> <br /> &lt;blockquote&gt;<br /> Each project idea within a particular priority has been tagged with the following properties:<br /> * ''Required Experience:'' Languages, concepts, or packages with which applicants must be familiar.<br /> * ''Bonus Experience:'' Other experience or familiarity which would be greatly helpful to applicants for this project.<br /> * ''Interests:'' Areas of particular relevance to this project, and an indicator of where successful contributors might apply their experiences coming out of this project.<br /> * ''Difficulty:'' easy, medium or difficult<br /> * ''Recommended reading:'' pointers to documentation, papers, specific bugs, etc.<br /> <br /> 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.<br /> &lt;/blockquote&gt;<br /> <br /> === Patch requirement guidelines ===<br /> <br /> 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.<br /> <br /> === Mentors: how to participate ===<br /> <br /> 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:<br /> <br /> * 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.<br /> * 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.<br /> * 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.<br /> <br /> == Project Ideas ==<br /> <br /> '''Note to contributors:''' These ideas are not listed in any priority order.<br /> 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.<br /> <br /> === Internet models enhancements ===<br /> <br /> * [[#AODVv2 Protocol enhancements]] (medium size project, 175h)<br /> * [[#Linux-like CAKE queue discipline for ns-3]] (large size project, 350h)<br /> * [[#Switched Ethernet]] (large size project, 350h)<br /> <br /> === IoT models enhancements ===<br /> <br /> * [[#6LoWPAN mesh-under routing enhancements]] (medium size project, 175h)<br /> * [[#6LoWPAN neighbor discovery protocol]] (medium size project, 175h)<br /> * [[#Mesh Link Establishment (MLE) protocol ]] (large size project, 350h)<br /> <br /> === 5G NR models enhancements ===<br /> <br /> 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.<br /> <br /> * [[#OLLA Link Adaptation and Spec-Compliant TBS Calculation for 5G-LENA]](medium size project, 175h)<br /> * [[#Enabling 5G NR examples visualization]] (medium size project, 175h)<br /> * [[#Energy Consumption Modeling and Power-Aware Extensions for 5G-LENA]](medium size project, 250h)<br /> * [[#5G NR module integration with ns-3-ai]] (large size project, 250h)<br /> <br /> == Small sized projects (90 hours) ==<br /> <br /> === Flent Application API in ns-3 ===<br /> <br /> Mentors: [mailto:tahiliani.nitk@gmail.com Mohit P. Tahiliani]<br /> <br /> 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) complete the implementation of Flent application API in ns-3 based on the latest ns-3-dev, (2) enable support for multiple ns-3 applications in the Flent application API (3) add more examples (i.e., Flent tests) in ns-3 to better suit the needs of researchers working in this area, and (4) merge Flent application API in the mainline of ns-3.<br /> <br /> * ''Required Experience:'' Familiarity with Flent and C++ programming.<br /> * ''Bonus Experience:'' Familiarity with applications supported in ns-3.<br /> * ''Interests:'' Bufferbloat, TCP, AQM algorithms and ECN.<br /> * ''Difficulty:'' Medium.<br /> * ''Recommended Reading:''<br /> ** Flexible Network Tester [[https://flent.org/flent-the-flexible-network-tester.pdf Paper]] [[https://flent.org/ Tool]]<br /> ** [https://www.nsnam.org/doxygen/d9/dc9/group__applications.html#details Existing Applications in ns-3]<br /> ** [https://gitlab.com/tomhenderson/ns-3-dev/-/commits/flent?ref_type=heads Prior work on Flent application API in ns-3]<br /> <br /> <br /> === Internet routing refactory ===<br /> <br /> Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], [TBD].<br /> <br /> 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.<br /> <br /> In ns-3 this is accomplished by storing three separate objects, two Ipv[4,6]Address, and one Ipv[4Mask,6Prefix].<br /> <br /> While this is quite simple to implement, this has some notable drawbacks, e.g., the Dst address must be a network address (Dst &amp; ~DstMask == 0), it is not efficient (the mask or prefix could be represented by a simple integer), and more.<br /> <br /> In order to improve code readability and consistency between IPv4 and IPv6, !2645 introduces two new classes: Ipv[4,6]NetworkAddress.<br /> <br /> The goal is to refactor the existing routing classes, along with Ipv[4,6]RotingTable classes, so that they use the new classes.<br /> <br /> 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.<br /> <br /> Another very important requirement will be to break down the work in multiple sub-tasks, so that the merge process can be gradual.<br /> <br /> 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 clearr and motivated.<br /> <br /> * ''Required Experience:'' Fundamentals of IPv6 addressing and routing, C++ programming.<br /> * ''Interests:'' IPv4 and IPv6 routing<br /> * ''Difficulty:'' Easy.<br /> * ''Recommended reading:''<br /> ** [https://gitlab.com/nsnam/ns-3-dev/-/issues/1239 Issue #1239]<br /> ** [https://gitlab.com/nsnam/ns-3-dev/-/merge_requests/2645 Merge Request !2645]<br /> <br /> Possible tasks to fulfill the patch requirement:<br /> * Use !2645 to modify all or in part the `Rip` protocol.<br /> <br /> == Medium sized projects (175 hours) ==<br /> <br /> === 6LoWPAN mesh-under routing enhancements ===<br /> <br /> Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], [TBD].<br /> <br /> 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.<br /> 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.<br /> <br /> The candidate should outline the proposed approach, what parts of code are going to be affected, and how they can be enhanced.<br /> <br /> * ''Required Experience:'' Fundamentals of IPv6 addressing, C++ programming.<br /> * ''Bonus Experience:'' Familiarity with mesh routing and 6LoWPAN ns-3<br /> * ''Interests:'' IPv6 mesh routing<br /> * ''Difficulty:'' Easy.<br /> * ''Recommended reading:''<br /> ** [https://www.nsnam.org/docs/models/html/sixlowpan.html#mesh-under-routing Mesh-under in ns-3 6LoWPAN]<br /> ** [https://datatracker.ietf.org/doc/html/rfc7731 RFC 7731]<br /> ** [https://meshtastic.org/docs/overview/mesh-algo/ Meshtastic controlled flooding]<br /> ** [https://ieeexplore.ieee.org/document/91339 Routing by controlled flooding in communication networks] (if the document can not be accessed, PM the mentors)<br /> <br /> Possible tasks to fulfill the patch requirement:<br /> * 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 &quot;next hop&quot;. The behavior of the actual protocol should be unchanged.<br /> <br /> === 6LoWPAN neighbor discovery protocol ===<br /> <br /> Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], [mailto:adnan.rashid@poliba.it Adnan Rashid].<br /> <br /> 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.<br /> <br /> 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.<br /> <br /> 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.<br /> <br /> * ''Required Experience:'' Fundamentals of IPv6 addressing, C++ programming.<br /> * ''Bonus Experience:'' Familiarity with 6LoWPAN and 6LoWPAN-ND<br /> * ''Interests:'' IPv6 and IoT networks<br /> * ''Difficulty:'' Easy.<br /> * ''Recommended reading:''<br /> ** [https://datatracker.ietf.org/doc/html/rfc8505 RFC 8505]<br /> ** [https://datatracker.ietf.org/doc/html/rfc6775 RFC 6775]<br /> ** [https://datatracker.ietf.org/doc/html/rfc4944 RFC 4944]<br /> ** https://gitlab.com/jieqiboh5836/ns-3-dev/-/tree/6LoWPAN-ND-P1<br /> ** https://gitlab.com/jieqiboh5836/ns-3-dev/-/tree/6LoWPAN-ND-P2<br /> <br /> ===OLLA Link Adaptation and Spec-Compliant TBS Calculation for 5G-LENA===<br /> <br /> 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]<br /> <br /> 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.<br /> 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.<br /> <br /> 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.<br /> <br /> *Required Experience: C++ programming, understanding of 5G NR MAC concepts (scheduling, CQI/MCS, HARQ), wireless networking fundamentals<br /> *Interests: 5G NR simulations, scheduling, link adaptation, performance evaluation<br /> *Difficulty: Medium<br /> *Project size: Medium<br /> *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.<br /> <br /> === Enabling 5G NR examples visualization ===<br /> <br /> 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]<br /> <br /> 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.<br /> <br /> 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.<br /> 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].<br /> <br /> * Required Experience: C++ and Python programming, understanding of 5G NR, LTE, and wireless networks<br /> * Interests: 5G NR simulations<br /> * Difficulty: Medium.<br /> * 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.<br /> <br /> === AODVv2 Protocol enhancements ===<br /> <br /> Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], [TBD].<br /> <br /> 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.<br /> <br /> In particular the project should address the following points:<br /> # Alignment with the latest drafts,<br /> # Model finalization and testing (in particular for the IPv6 part),<br /> # AODVv2 examples and documentation,<br /> # &quot;External&quot; network routing support.<br /> <br /> Collaboration with the draft authors is also highly suggested.<br /> <br /> * ''Required Experience:'' Fundamentals of IPv6 addressing, C++ programming.<br /> * ''Bonus Experience:'' Familiarity with AODV implementations in ns-3 and AODVv2<br /> * ''Interests:'' Ad hoc routing<br /> * ''Difficulty:'' Medium.<br /> * ''Recommended reading:''<br /> ** [https://www.nsnam.org/docs/models/html/ipv6.html IPv6 model in ns-3]<br /> ** [https://www.nsnam.org/docs/models/html/aodv.html AODV model in ns-3]<br /> ** [https://gitlab.com/tod97/ns-3-dev/-/tree/aodvv2-icns3-25 AODVv2 model presented at ICNS3-2025] <br /> ** [https://datatracker.ietf.org/doc/draft-perkins-manet-aodvv2/05/ Ad Hoc On-demand Distance Vector Version 2 (AODVv2) Routing]<br /> <br /> Possible tasks to fulfill the patch requirement:<br /> * [https://gitlab.com/nsnam/ns-3-dev/-/issues/368 Issue #368] - aodv: aodv parameters can be set to &quot;impossible&quot; values<br /> <br /> == Large projects (350 hours) ==<br /> <br /> === Mesh Link Establishment (MLE) protocol ===<br /> <br /> Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], [mailto:alramonet@is.tokushima-u.ac.jp Alberto Gallegos Ramonet].<br /> <br /> 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.<br /> However, MLE is being used in Thread, and it can be useful to implement it.<br /> <br /> 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.<br /> <br /> * ''Required Experience:'' Fundamentals of IPv4 and IPv6 sockets, C++ programming.<br /> * ''Interests:'' Sockets and API interface implementation.<br /> * ''Difficulty:'' Hard.<br /> * ''Recommended reading:''<br /> ** [https://datatracker.ietf.org/doc/html/draft-ietf-6lo-mesh-link-establishment MLE draft]<br /> ** [https://openthread.io/guides/thread-primer/network-discovery Thread primer]<br /> ** [https://www.threadgroup.org/ThreadSpec Thread specifications]<br /> <br /> Possible tasks to fulfill the patch requirement:<br /> * TBD, contact the mentors if interested.<br /> <br /> ===Energy Consumption Modeling and Power-Aware Extensions for 5G-LENA===<br /> <br /> 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]<br /> <br /> 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.<br /> 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.<br /> 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.<br /> <br /> Scope (expected deliverables):<br /> *Energy consumption accounting for UEs and/or gNBs<br /> *Per-state (and if feasible per-procedure) modeling, e.g.<br /> **gNB: idle/active/sleep, TX/RX, processing; dependence on bandwidth/PRBs, TX power, MIMO layers/streams/RF chains, load<br /> **UE: TX/RX, measurements, CSI-RS/SRS activity, beamforming-related processing, handover<br /> *Tracing, example(s), and documentation<br /> <br /> 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)<br /> <br /> *Required Experience: C++ programming, wireless networking fundamentals (energy/state-machine modeling is a plus)<br /> *Interests: 5G NR simulations, energy efficiency, green networking, 6G sustainability<br /> *Difficulty: Medium<br /> *Project size: Medium<br /> *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.<br /> <br /> === 5G NR module integration with ns-3-ai ===<br /> <br /> 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]<br /> <br /> 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.<br /> <br /> 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.<br /> For more specific guidelines, please view this [https://docs.google.com/document/d/1cQLIF1cdft1yj3vyWrjrxN2xDJMx8PuWaa9NP_nKf64/edit?usp=sharing Google document].<br /> <br /> * Required Experience: C++ programming, understanding of 5G NR, LTE, and wireless networks<br /> * Interests: 5G NR simulations<br /> * Difficulty: Medium.<br /> * 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.<br /> <br /> === Linux-like CAKE queue discipline for ns-3 ===<br /> <br /> Mentors: [mailto:tahiliani.nitk@gmail.com Mohit P. Tahiliani]<br /> <br /> 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.<br /> <br /> * ''Required Experience:'' Familiarity with queue disciplines, TCP and C++ programming.<br /> * ''Bonus Experience:'' Familiarity with CAKE framework in Linux 4.19<br /> * ''Interests:'' Active Queue Management, Packet scheduling and TCP.<br /> * ''Difficulty:'' Medium to Hard<br /> * ''Recommended reading:''<br /> ** [https://arxiv.org/pdf/1804.07617.pdf Piece of CAKE: A Comprehensive Queue Management Solution for Home Gateways]<br /> ** [https://lwn.net/Articles/758353/ Let them run CAKE]<br /> ** [https://www.nsnam.org/docs/models/html/queue-discs.html Queue disciplines in ns-3]<br /> <br /> === Switched Ethernet ===<br /> <br /> Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], TBD.<br /> <br /> 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.<br /> <br /> 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.<br /> <br /> 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.<br /> <br /> 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.<br /> <br /> 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.<br /> <br /> * ''Required Experience:'' Fundamentals of Ethernet sitched networking, C++ programming.<br /> * ''Interests:'' Ethernet networks and switched data networks.<br /> * ''Difficulty:'' Medium.<br /> * ''Recommended reading:''<br /> ** [https://www2.nsnam.org/bugzilla/show_bug.cgi?id=2602 Basic implementation (very old)]<br /> ** [https://gitlab.com/nsnam/ns-3-dev/-/merge_requests/431 Full-duplex CSMA, somehow related]<br /> ** [https://tcipg.org/sites/default/files/papers/2010_Jin_Nicol_Caesar.pdf Paper on gigabit Ethernet switch models for simulation]<br /> <br /> Possible tasks to fulfill the patch requirement:<br /> * TBD, contact the mentors if interested.</div>

Tommaso https://www.nsnam.org/mediawiki/index.php?title=GSOC2026Projects&diff=13729 2026-02-04T02:56:48Z

<p>Tommaso: /* Medium sized projects (175 hours) */</p> <hr /> <div>{{TOC}}<br /> <br /> This page contains 2026 Google Summer of Code project ideas for ns-3.<br /> <br /> * [https://developers.google.com/open-source/gsoc/faq GSoC Frequently Asked Questions]<br /> * [[GSOC2026ContributorGuide | ns-3's 2026 GSoC Contributor guide]]<br /> * [https://developers.google.com/open-source/gsoc/resources/guide GSoC contributor/student guide (not ns-3 specific)]<br /> * [[GSOC2025ApplicationTemplate | 2026 GSoC Contributor application template]]<br /> * [[GSOCMentorGuide | ns-3's GSoC Mentor guide]]<br /> * [https://archive.flossmanuals.net/gsocmentoring/index.html GSoC Mentor guide (not ns-3 specific)]<br /> * [[GSOCSelectionProcess | GSoC Contributor Selection Process]]<br /> * ''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/<br /> <br /> === About the ns-3 project ===<br /> <br /> ns-3 is a discrete-event network simulator, with a particular emphasis on network research and education.<br /> <br /> 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.<br /> <br /> 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.<br /> <br /> === Org admins ===<br /> <br /> 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].<br /> <br /> === Mentors ===<br /> <br /> 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.<br /> <br /> The current list of prospective mentors can be found among the ideas listed below.<br /> <br /> === How to apply ===<br /> <br /> For students or contributors interested in applying to ns-3 for GSoC, please go through the following list to get started:<br /> * Read the official [https://developers.google.com/open-source/gsoc/resources/guide GSoC contributor guide].<br /> * Read [[GSOC2026ContributorGuide |ns-3's 2026 GSoC contributor guide]]<br /> * Look through our [[#Project Ideas]] below to see if you find a project that interests you.<br /> * Review the [https://www.nsnam.org/documentation/development-tree/ tutorial and contributing guide] thoroughly, if you have not already done so.<br /> * 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.<br /> * Next, proceed to get in touch with the developers on the mailing list or Zulip chat room and refine your proposal.<br /> * 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.<br /> <br /> 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.<br /> <br /> &lt;blockquote&gt;<br /> Each project idea within a particular priority has been tagged with the following properties:<br /> * ''Required Experience:'' Languages, concepts, or packages with which applicants must be familiar.<br /> * ''Bonus Experience:'' Other experience or familiarity which would be greatly helpful to applicants for this project.<br /> * ''Interests:'' Areas of particular relevance to this project, and an indicator of where successful contributors might apply their experiences coming out of this project.<br /> * ''Difficulty:'' easy, medium or difficult<br /> * ''Recommended reading:'' pointers to documentation, papers, specific bugs, etc.<br /> <br /> 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.<br /> &lt;/blockquote&gt;<br /> <br /> === Patch requirement guidelines ===<br /> <br /> 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.<br /> <br /> === Mentors: how to participate ===<br /> <br /> 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:<br /> <br /> * 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.<br /> * 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.<br /> * 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.<br /> <br /> == Project Ideas ==<br /> <br /> '''Note to contributors:''' These ideas are not listed in any priority order.<br /> 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.<br /> <br /> === Internet models enhancements ===<br /> <br /> * [[#AODVv2 Protocol enhancements]] (medium size project, 175h)<br /> * [[#Linux-like CAKE queue discipline for ns-3]] (large size project, 350h)<br /> * [[#Switched Ethernet]] (large size project, 350h)<br /> <br /> === IoT models enhancements ===<br /> <br /> * [[#6LoWPAN mesh-under routing enhancements]] (medium size project, 175h)<br /> * [[#6LoWPAN neighbor discovery protocol]] (medium size project, 175h)<br /> * [[#Mesh Link Establishment (MLE) protocol ]] (large size project, 350h)<br /> <br /> === 5G NR models enhancements ===<br /> <br /> 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.<br /> <br /> * [[#NTN example for 5G NR]] (small size project, 90h)<br /> * [[#Enabling 5G NR examples visualization]] (medium size project, 175h)<br /> * [[#Improving 5G NR module usability through helpers]] (medium size project, 175h)<br /> * [[#5G NR module integration with ns-3-ai]] (large size project, 250h)<br /> <br /> == Small sized projects (90 hours) ==<br /> <br /> <br /> === NTN example for 5G NR ===<br /> <br /> 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]<br /> <br /> 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).<br /> <br /> 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.<br /> <br /> * Required Experience: C++ programming, understanding of 5G NR, LTE, and wireless networks<br /> * Interests: 5G NR simulations<br /> * Difficulty: Medium.<br /> * 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.<br /> <br /> == Medium sized projects (175 hours) ==<br /> <br /> === 6LoWPAN mesh-under routing enhancements ===<br /> <br /> Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], [TBD].<br /> <br /> 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.<br /> 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.<br /> <br /> The candidate should outline the proposed approach, what parts of code are going to be affected, and how they can be enhanced.<br /> <br /> * ''Required Experience:'' Fundamentals of IPv6 addressing, C++ programming.<br /> * ''Bonus Experience:'' Familiarity with mesh routing and 6LoWPAN ns-3<br /> * ''Interests:'' IPv6 mesh routing<br /> * ''Difficulty:'' Easy.<br /> * ''Recommended reading:''<br /> ** [https://www.nsnam.org/docs/models/html/sixlowpan.html#mesh-under-routing Mesh-under in ns-3 6LoWPAN]<br /> ** [https://datatracker.ietf.org/doc/html/rfc7731 RFC 7731]<br /> ** [https://meshtastic.org/docs/overview/mesh-algo/ Meshtastic controlled flooding]<br /> ** [https://ieeexplore.ieee.org/document/91339 Routing by controlled flooding in communication networks] (if the document can not be accessed, PM the mentors)<br /> <br /> Possible tasks to fulfill the patch requirement:<br /> * 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 &quot;next hop&quot;. The behavior of the actual protocol should be unchanged.<br /> <br /> === 6LoWPAN neighbor discovery protocol ===<br /> <br /> Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], [mailto:adnan.rashid@poliba.it Adnan Rashid].<br /> <br /> 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.<br /> <br /> 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.<br /> <br /> 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.<br /> <br /> * ''Required Experience:'' Fundamentals of IPv6 addressing, C++ programming.<br /> * ''Bonus Experience:'' Familiarity with 6LoWPAN and 6LoWPAN-ND<br /> * ''Interests:'' IPv6 and IoT networks<br /> * ''Difficulty:'' Easy.<br /> * ''Recommended reading:''<br /> ** [https://datatracker.ietf.org/doc/html/rfc8505 RFC 8505]<br /> ** [https://datatracker.ietf.org/doc/html/rfc6775 RFC 6775]<br /> ** [https://datatracker.ietf.org/doc/html/rfc4944 RFC 4944]<br /> ** https://gitlab.com/jieqiboh5836/ns-3-dev/-/tree/6LoWPAN-ND-P1<br /> ** https://gitlab.com/jieqiboh5836/ns-3-dev/-/tree/6LoWPAN-ND-P2<br /> <br /> === Improving 5G NR module usability through helpers ===<br /> <br /> 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]<br /> <br /> 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.<br /> <br /> 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.<br /> <br /> * Required Experience: C++ programming, understanding of 5G NR, LTE, and wireless networks<br /> * Interests: 5G NR simulations<br /> * Difficulty: Medium.<br /> * 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.<br /> <br /> === Enabling 5G NR examples visualization ===<br /> <br /> 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]<br /> <br /> 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.<br /> <br /> 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.<br /> 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].<br /> <br /> * Required Experience: C++ and Python programming, understanding of 5G NR, LTE, and wireless networks<br /> * Interests: 5G NR simulations<br /> * Difficulty: Medium.<br /> * 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.<br /> <br /> === AODVv2 Protocol enhancements ===<br /> <br /> Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], [TBD].<br /> <br /> 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.<br /> <br /> In particular the project should address the following points:<br /> # Alignment with the latest drafts,<br /> # Model finalization and testing (in particular for the IPv6 part),<br /> # AODVv2 examples and documentation,<br /> # &quot;External&quot; network routing support.<br /> <br /> Collaboration with the draft authors is also highly suggested.<br /> <br /> * ''Required Experience:'' Fundamentals of IPv6 addressing, C++ programming.<br /> * ''Bonus Experience:'' Familiarity with AODV implementations in ns-3 and AODVv2<br /> * ''Interests:'' Ad hoc routing<br /> * ''Difficulty:'' Medium.<br /> * ''Recommended reading:''<br /> ** [https://www.nsnam.org/docs/models/html/ipv6.html IPv6 model in ns-3]<br /> ** [https://www.nsnam.org/docs/models/html/aodv.html AODV model in ns-3]<br /> ** [https://gitlab.com/tod97/ns-3-dev/-/tree/aodvv2-icns3-25 AODVv2 model presented at ICNS3-2025] <br /> ** [https://datatracker.ietf.org/doc/draft-perkins-manet-aodvv2/05/ Ad Hoc On-demand Distance Vector Version 2 (AODVv2) Routing]<br /> <br /> Possible tasks to fulfill the patch requirement:<br /> * [https://gitlab.com/nsnam/ns-3-dev/-/issues/368 Issue #368] - aodv: aodv parameters can be set to &quot;impossible&quot; values<br /> <br /> == Large projects (350 hours) ==<br /> <br /> === Mesh Link Establishment (MLE) protocol ===<br /> <br /> Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], [mailto:alramonet@is.tokushima-u.ac.jp Alberto Gallegos Ramonet].<br /> <br /> 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.<br /> However, MLE is being used in Thread, and it can be useful to implement it.<br /> <br /> 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.<br /> <br /> * ''Required Experience:'' Fundamentals of IPv4 and IPv6 sockets, C++ programming.<br /> * ''Interests:'' Sockets and API interface implementation.<br /> * ''Difficulty:'' Hard.<br /> * ''Recommended reading:''<br /> ** [https://datatracker.ietf.org/doc/html/draft-ietf-6lo-mesh-link-establishment MLE draft]<br /> ** [https://openthread.io/guides/thread-primer/network-discovery Thread primer]<br /> ** [https://www.threadgroup.org/ThreadSpec Thread specifications]<br /> <br /> Possible tasks to fulfill the patch requirement:<br /> * TBD, contact the mentors if interested.<br /> <br /> === 5G NR module integration with ns-3-ai ===<br /> <br /> 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]<br /> <br /> 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.<br /> <br /> 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.<br /> For more specific guidelines, please view this [https://docs.google.com/document/d/1cQLIF1cdft1yj3vyWrjrxN2xDJMx8PuWaa9NP_nKf64/edit?usp=sharing Google document].<br /> <br /> * Required Experience: C++ programming, understanding of 5G NR, LTE, and wireless networks<br /> * Interests: 5G NR simulations<br /> * Difficulty: Medium.<br /> * 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.<br /> <br /> === Linux-like CAKE queue discipline for ns-3 ===<br /> <br /> Mentors: [mailto:tahiliani.nitk@gmail.com Mohit P. Tahiliani]<br /> <br /> 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.<br /> <br /> * ''Required Experience:'' Familiarity with queue disciplines, TCP and C++ programming.<br /> * ''Bonus Experience:'' Familiarity with CAKE framework in Linux 4.19<br /> * ''Interests:'' Active Queue Management, Packet scheduling and TCP.<br /> * ''Difficulty:'' Medium to Hard<br /> * ''Recommended reading:''<br /> ** [https://arxiv.org/pdf/1804.07617.pdf Piece of CAKE: A Comprehensive Queue Management Solution for Home Gateways]<br /> ** [https://lwn.net/Articles/758353/ Let them run CAKE]<br /> ** [https://www.nsnam.org/docs/models/html/queue-discs.html Queue disciplines in ns-3]<br /> <br /> === Switched Ethernet ===<br /> <br /> Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], TBD.<br /> <br /> 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.<br /> <br /> 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.<br /> <br /> 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.<br /> <br /> 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.<br /> <br /> 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.<br /> <br /> * ''Required Experience:'' Fundamentals of Ethernet sitched networking, C++ programming.<br /> * ''Interests:'' Ethernet networks and switched data networks.<br /> * ''Difficulty:'' Medium.<br /> * ''Recommended reading:''<br /> ** [https://www2.nsnam.org/bugzilla/show_bug.cgi?id=2602 Basic implementation (very old)]<br /> ** [https://gitlab.com/nsnam/ns-3-dev/-/merge_requests/431 Full-duplex CSMA, somehow related]<br /> ** [https://tcipg.org/sites/default/files/papers/2010_Jin_Nicol_Caesar.pdf Paper on gigabit Ethernet switch models for simulation]<br /> <br /> Possible tasks to fulfill the patch requirement:<br /> * TBD, contact the mentors if interested.</div>

Tommaso https://www.nsnam.org/mediawiki/index.php?title=GSOC2026Projects&diff=13728 2026-02-04T02:55:23Z

<p>Tommaso: /* 6LoWPAN mesh-under routing enhancements */</p> <hr /> <div>{{TOC}}<br /> <br /> This page contains 2026 Google Summer of Code project ideas for ns-3.<br /> <br /> * [https://developers.google.com/open-source/gsoc/faq GSoC Frequently Asked Questions]<br /> * [[GSOC2026ContributorGuide | ns-3's 2026 GSoC Contributor guide]]<br /> * [https://developers.google.com/open-source/gsoc/resources/guide GSoC contributor/student guide (not ns-3 specific)]<br /> * [[GSOC2025ApplicationTemplate | 2026 GSoC Contributor application template]]<br /> * [[GSOCMentorGuide | ns-3's GSoC Mentor guide]]<br /> * [https://archive.flossmanuals.net/gsocmentoring/index.html GSoC Mentor guide (not ns-3 specific)]<br /> * [[GSOCSelectionProcess | GSoC Contributor Selection Process]]<br /> * ''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/<br /> <br /> === About the ns-3 project ===<br /> <br /> ns-3 is a discrete-event network simulator, with a particular emphasis on network research and education.<br /> <br /> 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.<br /> <br /> 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.<br /> <br /> === Org admins ===<br /> <br /> 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].<br /> <br /> === Mentors ===<br /> <br /> 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.<br /> <br /> The current list of prospective mentors can be found among the ideas listed below.<br /> <br /> === How to apply ===<br /> <br /> For students or contributors interested in applying to ns-3 for GSoC, please go through the following list to get started:<br /> * Read the official [https://developers.google.com/open-source/gsoc/resources/guide GSoC contributor guide].<br /> * Read [[GSOC2026ContributorGuide |ns-3's 2026 GSoC contributor guide]]<br /> * Look through our [[#Project Ideas]] below to see if you find a project that interests you.<br /> * Review the [https://www.nsnam.org/documentation/development-tree/ tutorial and contributing guide] thoroughly, if you have not already done so.<br /> * 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.<br /> * Next, proceed to get in touch with the developers on the mailing list or Zulip chat room and refine your proposal.<br /> * 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.<br /> <br /> 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.<br /> <br /> &lt;blockquote&gt;<br /> Each project idea within a particular priority has been tagged with the following properties:<br /> * ''Required Experience:'' Languages, concepts, or packages with which applicants must be familiar.<br /> * ''Bonus Experience:'' Other experience or familiarity which would be greatly helpful to applicants for this project.<br /> * ''Interests:'' Areas of particular relevance to this project, and an indicator of where successful contributors might apply their experiences coming out of this project.<br /> * ''Difficulty:'' easy, medium or difficult<br /> * ''Recommended reading:'' pointers to documentation, papers, specific bugs, etc.<br /> <br /> 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.<br /> &lt;/blockquote&gt;<br /> <br /> === Patch requirement guidelines ===<br /> <br /> 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.<br /> <br /> === Mentors: how to participate ===<br /> <br /> 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:<br /> <br /> * 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.<br /> * 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.<br /> * 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.<br /> <br /> == Project Ideas ==<br /> <br /> '''Note to contributors:''' These ideas are not listed in any priority order.<br /> 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.<br /> <br /> === Internet models enhancements ===<br /> <br /> * [[#AODVv2 Protocol enhancements]] (medium size project, 175h)<br /> * [[#Linux-like CAKE queue discipline for ns-3]] (large size project, 350h)<br /> * [[#Switched Ethernet]] (large size project, 350h)<br /> <br /> === IoT models enhancements ===<br /> <br /> * [[#6LoWPAN mesh-under routing enhancements]] (medium size project, 175h)<br /> * [[#6LoWPAN neighbor discovery protocol]] (medium size project, 175h)<br /> * [[#Mesh Link Establishment (MLE) protocol ]] (large size project, 350h)<br /> <br /> === 5G NR models enhancements ===<br /> <br /> 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.<br /> <br /> * [[#NTN example for 5G NR]] (small size project, 90h)<br /> * [[#Enabling 5G NR examples visualization]] (medium size project, 175h)<br /> * [[#Improving 5G NR module usability through helpers]] (medium size project, 175h)<br /> * [[#5G NR module integration with ns-3-ai]] (large size project, 250h)<br /> <br /> == Small sized projects (90 hours) ==<br /> <br /> <br /> === NTN example for 5G NR ===<br /> <br /> 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]<br /> <br /> 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).<br /> <br /> 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.<br /> <br /> * Required Experience: C++ programming, understanding of 5G NR, LTE, and wireless networks<br /> * Interests: 5G NR simulations<br /> * Difficulty: Medium.<br /> * 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.<br /> <br /> == Medium sized projects (175 hours) ==<br /> <br /> === 6LoWPAN mesh-under routing enhancements ===<br /> <br /> Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], [TBD].<br /> <br /> 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.<br /> 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.<br /> <br /> The candidate should outline the proposed approach, what parts of code are going to be affected, and how they can be enhanced.<br /> <br /> * ''Required Experience:'' Fundamentals of IPv6 addressing, C++ programming.<br /> * ''Bonus Experience:'' Familiarity with mesh routing and 6LoWPAN ns-3<br /> * ''Interests:'' IPv6 mesh routing<br /> * ''Difficulty:'' Easy.<br /> * ''Recommended reading:''<br /> ** [https://www.nsnam.org/docs/models/html/sixlowpan.html#mesh-under-routing Mesh-under in ns-3 6LoWPAN]<br /> ** [https://datatracker.ietf.org/doc/html/rfc7731 RFC 7731]<br /> ** [https://meshtastic.org/docs/overview/mesh-algo/ Meshtastic controlled flooding]<br /> ** [https://ieeexplore.ieee.org/document/91339 Routing by controlled flooding in communication networks]<br /> <br /> Possible tasks to fulfill the patch requirement:<br /> * 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 &quot;next hop&quot;. The behavior of the actual protocol should be unchanged.<br /> <br /> === 6LoWPAN neighbor discovery protocol ===<br /> <br /> Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], [mailto:adnan.rashid@poliba.it Adnan Rashid].<br /> <br /> 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.<br /> <br /> 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.<br /> <br /> 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.<br /> <br /> * ''Required Experience:'' Fundamentals of IPv6 addressing, C++ programming.<br /> * ''Bonus Experience:'' Familiarity with 6LoWPAN and 6LoWPAN-ND<br /> * ''Interests:'' IPv6 and IoT networks<br /> * ''Difficulty:'' Easy.<br /> * ''Recommended reading:''<br /> ** [https://datatracker.ietf.org/doc/html/rfc8505 RFC 8505]<br /> ** [https://datatracker.ietf.org/doc/html/rfc6775 RFC 6775]<br /> ** [https://datatracker.ietf.org/doc/html/rfc4944 RFC 4944]<br /> ** https://gitlab.com/jieqiboh5836/ns-3-dev/-/tree/6LoWPAN-ND-P1<br /> ** https://gitlab.com/jieqiboh5836/ns-3-dev/-/tree/6LoWPAN-ND-P2<br /> <br /> === Improving 5G NR module usability through helpers ===<br /> <br /> 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]<br /> <br /> 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.<br /> <br /> 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.<br /> <br /> * Required Experience: C++ programming, understanding of 5G NR, LTE, and wireless networks<br /> * Interests: 5G NR simulations<br /> * Difficulty: Medium.<br /> * 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.<br /> <br /> === Enabling 5G NR examples visualization ===<br /> <br /> 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]<br /> <br /> 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.<br /> <br /> 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.<br /> 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].<br /> <br /> * Required Experience: C++ and Python programming, understanding of 5G NR, LTE, and wireless networks<br /> * Interests: 5G NR simulations<br /> * Difficulty: Medium.<br /> * 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.<br /> <br /> === AODVv2 Protocol enhancements ===<br /> <br /> Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], [TBD].<br /> <br /> 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.<br /> <br /> In particular the project should address the following points:<br /> # Alignment with the latest drafts,<br /> # Model finalization and testing (in particular for the IPv6 part),<br /> # AODVv2 examples and documentation,<br /> # &quot;External&quot; network routing support.<br /> <br /> Collaboration with the draft authors is also highly suggested.<br /> <br /> * ''Required Experience:'' Fundamentals of IPv6 addressing, C++ programming.<br /> * ''Bonus Experience:'' Familiarity with AODV implementations in ns-3 and AODVv2<br /> * ''Interests:'' Ad hoc routing<br /> * ''Difficulty:'' Medium.<br /> * ''Recommended reading:''<br /> ** [https://www.nsnam.org/docs/models/html/ipv6.html IPv6 model in ns-3]<br /> ** [https://www.nsnam.org/docs/models/html/aodv.html AODV model in ns-3]<br /> ** [https://gitlab.com/tod97/ns-3-dev/-/tree/aodvv2-icns3-25 AODVv2 model presented at ICNS3-2025] <br /> ** [https://datatracker.ietf.org/doc/draft-perkins-manet-aodvv2/05/ Ad Hoc On-demand Distance Vector Version 2 (AODVv2) Routing]<br /> <br /> Possible tasks to fulfill the patch requirement:<br /> * [https://gitlab.com/nsnam/ns-3-dev/-/issues/368 Issue #368] - aodv: aodv parameters can be set to &quot;impossible&quot; values<br /> <br /> == Large projects (350 hours) ==<br /> <br /> === Mesh Link Establishment (MLE) protocol ===<br /> <br /> Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], [mailto:alramonet@is.tokushima-u.ac.jp Alberto Gallegos Ramonet].<br /> <br /> 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.<br /> However, MLE is being used in Thread, and it can be useful to implement it.<br /> <br /> 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.<br /> <br /> * ''Required Experience:'' Fundamentals of IPv4 and IPv6 sockets, C++ programming.<br /> * ''Interests:'' Sockets and API interface implementation.<br /> * ''Difficulty:'' Hard.<br /> * ''Recommended reading:''<br /> ** [https://datatracker.ietf.org/doc/html/draft-ietf-6lo-mesh-link-establishment MLE draft]<br /> ** [https://openthread.io/guides/thread-primer/network-discovery Thread primer]<br /> ** [https://www.threadgroup.org/ThreadSpec Thread specifications]<br /> <br /> Possible tasks to fulfill the patch requirement:<br /> * TBD, contact the mentors if interested.<br /> <br /> === 5G NR module integration with ns-3-ai ===<br /> <br /> 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]<br /> <br /> 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.<br /> <br /> 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.<br /> For more specific guidelines, please view this [https://docs.google.com/document/d/1cQLIF1cdft1yj3vyWrjrxN2xDJMx8PuWaa9NP_nKf64/edit?usp=sharing Google document].<br /> <br /> * Required Experience: C++ programming, understanding of 5G NR, LTE, and wireless networks<br /> * Interests: 5G NR simulations<br /> * Difficulty: Medium.<br /> * 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.<br /> <br /> === Linux-like CAKE queue discipline for ns-3 ===<br /> <br /> Mentors: [mailto:tahiliani.nitk@gmail.com Mohit P. Tahiliani]<br /> <br /> 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.<br /> <br /> * ''Required Experience:'' Familiarity with queue disciplines, TCP and C++ programming.<br /> * ''Bonus Experience:'' Familiarity with CAKE framework in Linux 4.19<br /> * ''Interests:'' Active Queue Management, Packet scheduling and TCP.<br /> * ''Difficulty:'' Medium to Hard<br /> * ''Recommended reading:''<br /> ** [https://arxiv.org/pdf/1804.07617.pdf Piece of CAKE: A Comprehensive Queue Management Solution for Home Gateways]<br /> ** [https://lwn.net/Articles/758353/ Let them run CAKE]<br /> ** [https://www.nsnam.org/docs/models/html/queue-discs.html Queue disciplines in ns-3]<br /> <br /> === Switched Ethernet ===<br /> <br /> Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], TBD.<br /> <br /> 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.<br /> <br /> 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.<br /> <br /> 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.<br /> <br /> 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.<br /> <br /> 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.<br /> <br /> * ''Required Experience:'' Fundamentals of Ethernet sitched networking, C++ programming.<br /> * ''Interests:'' Ethernet networks and switched data networks.<br /> * ''Difficulty:'' Medium.<br /> * ''Recommended reading:''<br /> ** [https://www2.nsnam.org/bugzilla/show_bug.cgi?id=2602 Basic implementation (very old)]<br /> ** [https://gitlab.com/nsnam/ns-3-dev/-/merge_requests/431 Full-duplex CSMA, somehow related]<br /> ** [https://tcipg.org/sites/default/files/papers/2010_Jin_Nicol_Caesar.pdf Paper on gigabit Ethernet switch models for simulation]<br /> <br /> Possible tasks to fulfill the patch requirement:<br /> * TBD, contact the mentors if interested.</div>

Tommaso https://www.nsnam.org/mediawiki/index.php?title=GSOC2026Projects&diff=13727 2026-02-04T02:54:16Z

<p>Tommaso: /* 6LoWPAN mesh-under routing enhancements */</p> <hr /> <div>{{TOC}}<br /> <br /> This page contains 2026 Google Summer of Code project ideas for ns-3.<br /> <br /> * [https://developers.google.com/open-source/gsoc/faq GSoC Frequently Asked Questions]<br /> * [[GSOC2026ContributorGuide | ns-3's 2026 GSoC Contributor guide]]<br /> * [https://developers.google.com/open-source/gsoc/resources/guide GSoC contributor/student guide (not ns-3 specific)]<br /> * [[GSOC2025ApplicationTemplate | 2026 GSoC Contributor application template]]<br /> * [[GSOCMentorGuide | ns-3's GSoC Mentor guide]]<br /> * [https://archive.flossmanuals.net/gsocmentoring/index.html GSoC Mentor guide (not ns-3 specific)]<br /> * [[GSOCSelectionProcess | GSoC Contributor Selection Process]]<br /> * ''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/<br /> <br /> === About the ns-3 project ===<br /> <br /> ns-3 is a discrete-event network simulator, with a particular emphasis on network research and education.<br /> <br /> 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.<br /> <br /> 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.<br /> <br /> === Org admins ===<br /> <br /> 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].<br /> <br /> === Mentors ===<br /> <br /> 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.<br /> <br /> The current list of prospective mentors can be found among the ideas listed below.<br /> <br /> === How to apply ===<br /> <br /> For students or contributors interested in applying to ns-3 for GSoC, please go through the following list to get started:<br /> * Read the official [https://developers.google.com/open-source/gsoc/resources/guide GSoC contributor guide].<br /> * Read [[GSOC2026ContributorGuide |ns-3's 2026 GSoC contributor guide]]<br /> * Look through our [[#Project Ideas]] below to see if you find a project that interests you.<br /> * Review the [https://www.nsnam.org/documentation/development-tree/ tutorial and contributing guide] thoroughly, if you have not already done so.<br /> * 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.<br /> * Next, proceed to get in touch with the developers on the mailing list or Zulip chat room and refine your proposal.<br /> * 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.<br /> <br /> 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.<br /> <br /> &lt;blockquote&gt;<br /> Each project idea within a particular priority has been tagged with the following properties:<br /> * ''Required Experience:'' Languages, concepts, or packages with which applicants must be familiar.<br /> * ''Bonus Experience:'' Other experience or familiarity which would be greatly helpful to applicants for this project.<br /> * ''Interests:'' Areas of particular relevance to this project, and an indicator of where successful contributors might apply their experiences coming out of this project.<br /> * ''Difficulty:'' easy, medium or difficult<br /> * ''Recommended reading:'' pointers to documentation, papers, specific bugs, etc.<br /> <br /> 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.<br /> &lt;/blockquote&gt;<br /> <br /> === Patch requirement guidelines ===<br /> <br /> 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.<br /> <br /> === Mentors: how to participate ===<br /> <br /> 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:<br /> <br /> * 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.<br /> * 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.<br /> * 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.<br /> <br /> == Project Ideas ==<br /> <br /> '''Note to contributors:''' These ideas are not listed in any priority order.<br /> 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.<br /> <br /> === Internet models enhancements ===<br /> <br /> * [[#AODVv2 Protocol enhancements]] (medium size project, 175h)<br /> * [[#Linux-like CAKE queue discipline for ns-3]] (large size project, 350h)<br /> * [[#Switched Ethernet]] (large size project, 350h)<br /> <br /> === IoT models enhancements ===<br /> <br /> * [[#6LoWPAN mesh-under routing enhancements]] (medium size project, 175h)<br /> * [[#6LoWPAN neighbor discovery protocol]] (medium size project, 175h)<br /> * [[#Mesh Link Establishment (MLE) protocol ]] (large size project, 350h)<br /> <br /> === 5G NR models enhancements ===<br /> <br /> 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.<br /> <br /> * [[#NTN example for 5G NR]] (small size project, 90h)<br /> * [[#Enabling 5G NR examples visualization]] (medium size project, 175h)<br /> * [[#Improving 5G NR module usability through helpers]] (medium size project, 175h)<br /> * [[#5G NR module integration with ns-3-ai]] (large size project, 250h)<br /> <br /> == Small sized projects (90 hours) ==<br /> <br /> <br /> === NTN example for 5G NR ===<br /> <br /> 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]<br /> <br /> 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).<br /> <br /> 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.<br /> <br /> * Required Experience: C++ programming, understanding of 5G NR, LTE, and wireless networks<br /> * Interests: 5G NR simulations<br /> * Difficulty: Medium.<br /> * 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.<br /> <br /> == Medium sized projects (175 hours) ==<br /> <br /> === 6LoWPAN mesh-under routing enhancements ===<br /> <br /> Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], [TBD].<br /> <br /> 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.<br /> 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.<br /> <br /> <br /> The candidate should outline what parts of code are going to be affected, and how they can be enhanced thanks to RFC 7731.<br /> <br /> * ''Required Experience:'' Fundamentals of IPv6 addressing, C++ programming.<br /> * ''Bonus Experience:'' Familiarity with mesh routing and 6LoWPAN ns-3<br /> * ''Interests:'' IPv6 mesh routing<br /> * ''Difficulty:'' Easy.<br /> * ''Recommended reading:''<br /> ** [https://www.nsnam.org/docs/models/html/sixlowpan.html#mesh-under-routing Mesh-under in ns-3 6LoWPAN]<br /> ** [https://datatracker.ietf.org/doc/html/rfc7731 RFC 7731]<br /> ** [https://meshtastic.org/docs/overview/mesh-algo/ Meshtastic controlled flooding]<br /> ** [https://ieeexplore.ieee.org/document/91339 Routing by controlled flooding in communication networks]<br /> <br /> Possible tasks to fulfill the patch requirement:<br /> * 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 &quot;next hop&quot;. The behavior of the actual protocol should be unchanged.<br /> <br /> === 6LoWPAN neighbor discovery protocol ===<br /> <br /> Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], [mailto:adnan.rashid@poliba.it Adnan Rashid].<br /> <br /> 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.<br /> <br /> 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.<br /> <br /> 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.<br /> <br /> * ''Required Experience:'' Fundamentals of IPv6 addressing, C++ programming.<br /> * ''Bonus Experience:'' Familiarity with 6LoWPAN and 6LoWPAN-ND<br /> * ''Interests:'' IPv6 and IoT networks<br /> * ''Difficulty:'' Easy.<br /> * ''Recommended reading:''<br /> ** [https://datatracker.ietf.org/doc/html/rfc8505 RFC 8505]<br /> ** [https://datatracker.ietf.org/doc/html/rfc6775 RFC 6775]<br /> ** [https://datatracker.ietf.org/doc/html/rfc4944 RFC 4944]<br /> ** https://gitlab.com/jieqiboh5836/ns-3-dev/-/tree/6LoWPAN-ND-P1<br /> ** https://gitlab.com/jieqiboh5836/ns-3-dev/-/tree/6LoWPAN-ND-P2<br /> <br /> === Improving 5G NR module usability through helpers ===<br /> <br /> 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]<br /> <br /> 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.<br /> <br /> 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.<br /> <br /> * Required Experience: C++ programming, understanding of 5G NR, LTE, and wireless networks<br /> * Interests: 5G NR simulations<br /> * Difficulty: Medium.<br /> * 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.<br /> <br /> === Enabling 5G NR examples visualization ===<br /> <br /> 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]<br /> <br /> 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.<br /> <br /> 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.<br /> 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].<br /> <br /> * Required Experience: C++ and Python programming, understanding of 5G NR, LTE, and wireless networks<br /> * Interests: 5G NR simulations<br /> * Difficulty: Medium.<br /> * 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.<br /> <br /> === AODVv2 Protocol enhancements ===<br /> <br /> Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], [TBD].<br /> <br /> 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.<br /> <br /> In particular the project should address the following points:<br /> # Alignment with the latest drafts,<br /> # Model finalization and testing (in particular for the IPv6 part),<br /> # AODVv2 examples and documentation,<br /> # &quot;External&quot; network routing support.<br /> <br /> Collaboration with the draft authors is also highly suggested.<br /> <br /> * ''Required Experience:'' Fundamentals of IPv6 addressing, C++ programming.<br /> * ''Bonus Experience:'' Familiarity with AODV implementations in ns-3 and AODVv2<br /> * ''Interests:'' Ad hoc routing<br /> * ''Difficulty:'' Medium.<br /> * ''Recommended reading:''<br /> ** [https://www.nsnam.org/docs/models/html/ipv6.html IPv6 model in ns-3]<br /> ** [https://www.nsnam.org/docs/models/html/aodv.html AODV model in ns-3]<br /> ** [https://gitlab.com/tod97/ns-3-dev/-/tree/aodvv2-icns3-25 AODVv2 model presented at ICNS3-2025] <br /> ** [https://datatracker.ietf.org/doc/draft-perkins-manet-aodvv2/05/ Ad Hoc On-demand Distance Vector Version 2 (AODVv2) Routing]<br /> <br /> Possible tasks to fulfill the patch requirement:<br /> * [https://gitlab.com/nsnam/ns-3-dev/-/issues/368 Issue #368] - aodv: aodv parameters can be set to &quot;impossible&quot; values<br /> <br /> == Large projects (350 hours) ==<br /> <br /> === Mesh Link Establishment (MLE) protocol ===<br /> <br /> Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], [mailto:alramonet@is.tokushima-u.ac.jp Alberto Gallegos Ramonet].<br /> <br /> 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.<br /> However, MLE is being used in Thread, and it can be useful to implement it.<br /> <br /> 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.<br /> <br /> * ''Required Experience:'' Fundamentals of IPv4 and IPv6 sockets, C++ programming.<br /> * ''Interests:'' Sockets and API interface implementation.<br /> * ''Difficulty:'' Hard.<br /> * ''Recommended reading:''<br /> ** [https://datatracker.ietf.org/doc/html/draft-ietf-6lo-mesh-link-establishment MLE draft]<br /> ** [https://openthread.io/guides/thread-primer/network-discovery Thread primer]<br /> ** [https://www.threadgroup.org/ThreadSpec Thread specifications]<br /> <br /> Possible tasks to fulfill the patch requirement:<br /> * TBD, contact the mentors if interested.<br /> <br /> === 5G NR module integration with ns-3-ai ===<br /> <br /> 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]<br /> <br /> 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.<br /> <br /> 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.<br /> For more specific guidelines, please view this [https://docs.google.com/document/d/1cQLIF1cdft1yj3vyWrjrxN2xDJMx8PuWaa9NP_nKf64/edit?usp=sharing Google document].<br /> <br /> * Required Experience: C++ programming, understanding of 5G NR, LTE, and wireless networks<br /> * Interests: 5G NR simulations<br /> * Difficulty: Medium.<br /> * 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.<br /> <br /> === Linux-like CAKE queue discipline for ns-3 ===<br /> <br /> Mentors: [mailto:tahiliani.nitk@gmail.com Mohit P. Tahiliani]<br /> <br /> 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.<br /> <br /> * ''Required Experience:'' Familiarity with queue disciplines, TCP and C++ programming.<br /> * ''Bonus Experience:'' Familiarity with CAKE framework in Linux 4.19<br /> * ''Interests:'' Active Queue Management, Packet scheduling and TCP.<br /> * ''Difficulty:'' Medium to Hard<br /> * ''Recommended reading:''<br /> ** [https://arxiv.org/pdf/1804.07617.pdf Piece of CAKE: A Comprehensive Queue Management Solution for Home Gateways]<br /> ** [https://lwn.net/Articles/758353/ Let them run CAKE]<br /> ** [https://www.nsnam.org/docs/models/html/queue-discs.html Queue disciplines in ns-3]<br /> <br /> === Switched Ethernet ===<br /> <br /> Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], TBD.<br /> <br /> 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.<br /> <br /> 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.<br /> <br /> 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.<br /> <br /> 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.<br /> <br /> 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.<br /> <br /> * ''Required Experience:'' Fundamentals of Ethernet sitched networking, C++ programming.<br /> * ''Interests:'' Ethernet networks and switched data networks.<br /> * ''Difficulty:'' Medium.<br /> * ''Recommended reading:''<br /> ** [https://www2.nsnam.org/bugzilla/show_bug.cgi?id=2602 Basic implementation (very old)]<br /> ** [https://gitlab.com/nsnam/ns-3-dev/-/merge_requests/431 Full-duplex CSMA, somehow related]<br /> ** [https://tcipg.org/sites/default/files/papers/2010_Jin_Nicol_Caesar.pdf Paper on gigabit Ethernet switch models for simulation]<br /> <br /> Possible tasks to fulfill the patch requirement:<br /> * TBD, contact the mentors if interested.</div>

Tommaso https://www.nsnam.org/mediawiki/index.php?title=GSOC2026Projects&diff=13726 2026-02-04T02:24:56Z

<p>Tommaso: /* 6LoWPAN neighbor discovery protocol */</p> <hr /> <div>{{TOC}}<br /> <br /> This page contains 2026 Google Summer of Code project ideas for ns-3.<br /> <br /> * [https://developers.google.com/open-source/gsoc/faq GSoC Frequently Asked Questions]<br /> * [[GSOC2026ContributorGuide | ns-3's 2026 GSoC Contributor guide]]<br /> * [https://developers.google.com/open-source/gsoc/resources/guide GSoC contributor/student guide (not ns-3 specific)]<br /> * [[GSOC2025ApplicationTemplate | 2026 GSoC Contributor application template]]<br /> * [[GSOCMentorGuide | ns-3's GSoC Mentor guide]]<br /> * [https://archive.flossmanuals.net/gsocmentoring/index.html GSoC Mentor guide (not ns-3 specific)]<br /> * [[GSOCSelectionProcess | GSoC Contributor Selection Process]]<br /> * ''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/<br /> <br /> === About the ns-3 project ===<br /> <br /> ns-3 is a discrete-event network simulator, with a particular emphasis on network research and education.<br /> <br /> 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.<br /> <br /> 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.<br /> <br /> === Org admins ===<br /> <br /> 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].<br /> <br /> === Mentors ===<br /> <br /> 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.<br /> <br /> The current list of prospective mentors can be found among the ideas listed below.<br /> <br /> === How to apply ===<br /> <br /> For students or contributors interested in applying to ns-3 for GSoC, please go through the following list to get started:<br /> * Read the official [https://developers.google.com/open-source/gsoc/resources/guide GSoC contributor guide].<br /> * Read [[GSOC2026ContributorGuide |ns-3's 2026 GSoC contributor guide]]<br /> * Look through our [[#Project Ideas]] below to see if you find a project that interests you.<br /> * Review the [https://www.nsnam.org/documentation/development-tree/ tutorial and contributing guide] thoroughly, if you have not already done so.<br /> * 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.<br /> * Next, proceed to get in touch with the developers on the mailing list or Zulip chat room and refine your proposal.<br /> * 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.<br /> <br /> 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.<br /> <br /> &lt;blockquote&gt;<br /> Each project idea within a particular priority has been tagged with the following properties:<br /> * ''Required Experience:'' Languages, concepts, or packages with which applicants must be familiar.<br /> * ''Bonus Experience:'' Other experience or familiarity which would be greatly helpful to applicants for this project.<br /> * ''Interests:'' Areas of particular relevance to this project, and an indicator of where successful contributors might apply their experiences coming out of this project.<br /> * ''Difficulty:'' easy, medium or difficult<br /> * ''Recommended reading:'' pointers to documentation, papers, specific bugs, etc.<br /> <br /> 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.<br /> &lt;/blockquote&gt;<br /> <br /> === Patch requirement guidelines ===<br /> <br /> 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.<br /> <br /> === Mentors: how to participate ===<br /> <br /> 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:<br /> <br /> * 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.<br /> * 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.<br /> * 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.<br /> <br /> == Project Ideas ==<br /> <br /> '''Note to contributors:''' These ideas are not listed in any priority order.<br /> 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.<br /> <br /> === Internet models enhancements ===<br /> <br /> * [[#AODVv2 Protocol enhancements]] (medium size project, 175h)<br /> * [[#Linux-like CAKE queue discipline for ns-3]] (large size project, 350h)<br /> * [[#Switched Ethernet]] (large size project, 350h)<br /> <br /> === IoT models enhancements ===<br /> <br /> * [[#6LoWPAN mesh-under routing enhancements]] (medium size project, 175h)<br /> * [[#6LoWPAN neighbor discovery protocol]] (medium size project, 175h)<br /> * [[#Mesh Link Establishment (MLE) protocol ]] (large size project, 350h)<br /> <br /> === 5G NR models enhancements ===<br /> <br /> 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.<br /> <br /> * [[#NTN example for 5G NR]] (small size project, 90h)<br /> * [[#Enabling 5G NR examples visualization]] (medium size project, 175h)<br /> * [[#Improving 5G NR module usability through helpers]] (medium size project, 175h)<br /> * [[#5G NR module integration with ns-3-ai]] (large size project, 250h)<br /> <br /> == Small sized projects (90 hours) ==<br /> <br /> <br /> === NTN example for 5G NR ===<br /> <br /> 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]<br /> <br /> 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).<br /> <br /> 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.<br /> <br /> * Required Experience: C++ programming, understanding of 5G NR, LTE, and wireless networks<br /> * Interests: 5G NR simulations<br /> * Difficulty: Medium.<br /> * 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.<br /> <br /> == Medium sized projects (175 hours) ==<br /> <br /> === 6LoWPAN mesh-under routing enhancements ===<br /> <br /> Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], [TBD].<br /> <br /> 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.<br /> 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.<br /> <br /> The candidate should outline what parts of code are going to be affected, and how they can be enhanced thanks to RFC 7731.<br /> <br /> * ''Required Experience:'' Fundamentals of IPv6 addressing, C++ programming.<br /> * ''Bonus Experience:'' Familiarity with mesh routing and 6LoWPAN ns-3<br /> * ''Interests:'' IPv6 mesh routing<br /> * ''Difficulty:'' Easy.<br /> * ''Recommended reading:''<br /> ** [https://www.nsnam.org/docs/models/html/sixlowpan.html#mesh-under-routing Mesh-under in ns-3 6LoWPAN]<br /> ** [https://datatracker.ietf.org/doc/html/rfc7731 RFC 7731]<br /> <br /> Possible tasks to fulfill the patch requirement:<br /> * 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 &quot;next hop&quot;. The behavior of the actual protocol should be unchanged.<br /> <br /> === 6LoWPAN neighbor discovery protocol ===<br /> <br /> Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], [mailto:adnan.rashid@poliba.it Adnan Rashid].<br /> <br /> 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.<br /> <br /> 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.<br /> <br /> 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.<br /> <br /> * ''Required Experience:'' Fundamentals of IPv6 addressing, C++ programming.<br /> * ''Bonus Experience:'' Familiarity with 6LoWPAN and 6LoWPAN-ND<br /> * ''Interests:'' IPv6 and IoT networks<br /> * ''Difficulty:'' Easy.<br /> * ''Recommended reading:''<br /> ** [https://datatracker.ietf.org/doc/html/rfc8505 RFC 8505]<br /> ** [https://datatracker.ietf.org/doc/html/rfc6775 RFC 6775]<br /> ** [https://datatracker.ietf.org/doc/html/rfc4944 RFC 4944]<br /> ** https://gitlab.com/jieqiboh5836/ns-3-dev/-/tree/6LoWPAN-ND-P1<br /> ** https://gitlab.com/jieqiboh5836/ns-3-dev/-/tree/6LoWPAN-ND-P2<br /> <br /> === Improving 5G NR module usability through helpers ===<br /> <br /> 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]<br /> <br /> 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.<br /> <br /> 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.<br /> <br /> * Required Experience: C++ programming, understanding of 5G NR, LTE, and wireless networks<br /> * Interests: 5G NR simulations<br /> * Difficulty: Medium.<br /> * 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.<br /> <br /> === Enabling 5G NR examples visualization ===<br /> <br /> 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]<br /> <br /> 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.<br /> <br /> 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.<br /> 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].<br /> <br /> * Required Experience: C++ and Python programming, understanding of 5G NR, LTE, and wireless networks<br /> * Interests: 5G NR simulations<br /> * Difficulty: Medium.<br /> * 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.<br /> <br /> === AODVv2 Protocol enhancements ===<br /> <br /> Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], [TBD].<br /> <br /> 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.<br /> <br /> In particular the project should address the following points:<br /> # Alignment with the latest drafts,<br /> # Model finalization and testing (in particular for the IPv6 part),<br /> # AODVv2 examples and documentation,<br /> # &quot;External&quot; network routing support.<br /> <br /> Collaboration with the draft authors is also highly suggested.<br /> <br /> * ''Required Experience:'' Fundamentals of IPv6 addressing, C++ programming.<br /> * ''Bonus Experience:'' Familiarity with AODV implementations in ns-3 and AODVv2<br /> * ''Interests:'' Ad hoc routing<br /> * ''Difficulty:'' Medium.<br /> * ''Recommended reading:''<br /> ** [https://www.nsnam.org/docs/models/html/ipv6.html IPv6 model in ns-3]<br /> ** [https://www.nsnam.org/docs/models/html/aodv.html AODV model in ns-3]<br /> ** [https://gitlab.com/tod97/ns-3-dev/-/tree/aodvv2-icns3-25 AODVv2 model presented at ICNS3-2025] <br /> ** [https://datatracker.ietf.org/doc/draft-perkins-manet-aodvv2/05/ Ad Hoc On-demand Distance Vector Version 2 (AODVv2) Routing]<br /> <br /> Possible tasks to fulfill the patch requirement:<br /> * [https://gitlab.com/nsnam/ns-3-dev/-/issues/368 Issue #368] - aodv: aodv parameters can be set to &quot;impossible&quot; values<br /> <br /> == Large projects (350 hours) ==<br /> <br /> === Mesh Link Establishment (MLE) protocol ===<br /> <br /> Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], [mailto:alramonet@is.tokushima-u.ac.jp Alberto Gallegos Ramonet].<br /> <br /> 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.<br /> However, MLE is being used in Thread, and it can be useful to implement it.<br /> <br /> 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.<br /> <br /> * ''Required Experience:'' Fundamentals of IPv4 and IPv6 sockets, C++ programming.<br /> * ''Interests:'' Sockets and API interface implementation.<br /> * ''Difficulty:'' Hard.<br /> * ''Recommended reading:''<br /> ** [https://datatracker.ietf.org/doc/html/draft-ietf-6lo-mesh-link-establishment MLE draft]<br /> ** [https://openthread.io/guides/thread-primer/network-discovery Thread primer]<br /> ** [https://www.threadgroup.org/ThreadSpec Thread specifications]<br /> <br /> Possible tasks to fulfill the patch requirement:<br /> * TBD, contact the mentors if interested.<br /> <br /> === 5G NR module integration with ns-3-ai ===<br /> <br /> 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]<br /> <br /> 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.<br /> <br /> 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.<br /> For more specific guidelines, please view this [https://docs.google.com/document/d/1cQLIF1cdft1yj3vyWrjrxN2xDJMx8PuWaa9NP_nKf64/edit?usp=sharing Google document].<br /> <br /> * Required Experience: C++ programming, understanding of 5G NR, LTE, and wireless networks<br /> * Interests: 5G NR simulations<br /> * Difficulty: Medium.<br /> * 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.<br /> <br /> === Linux-like CAKE queue discipline for ns-3 ===<br /> <br /> Mentors: [mailto:tahiliani.nitk@gmail.com Mohit P. Tahiliani]<br /> <br /> 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.<br /> <br /> * ''Required Experience:'' Familiarity with queue disciplines, TCP and C++ programming.<br /> * ''Bonus Experience:'' Familiarity with CAKE framework in Linux 4.19<br /> * ''Interests:'' Active Queue Management, Packet scheduling and TCP.<br /> * ''Difficulty:'' Medium to Hard<br /> * ''Recommended reading:''<br /> ** [https://arxiv.org/pdf/1804.07617.pdf Piece of CAKE: A Comprehensive Queue Management Solution for Home Gateways]<br /> ** [https://lwn.net/Articles/758353/ Let them run CAKE]<br /> ** [https://www.nsnam.org/docs/models/html/queue-discs.html Queue disciplines in ns-3]<br /> <br /> === Switched Ethernet ===<br /> <br /> Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], TBD.<br /> <br /> 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.<br /> <br /> 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.<br /> <br /> 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.<br /> <br /> 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.<br /> <br /> 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.<br /> <br /> * ''Required Experience:'' Fundamentals of Ethernet sitched networking, C++ programming.<br /> * ''Interests:'' Ethernet networks and switched data networks.<br /> * ''Difficulty:'' Medium.<br /> * ''Recommended reading:''<br /> ** [https://www2.nsnam.org/bugzilla/show_bug.cgi?id=2602 Basic implementation (very old)]<br /> ** [https://gitlab.com/nsnam/ns-3-dev/-/merge_requests/431 Full-duplex CSMA, somehow related]<br /> ** [https://tcipg.org/sites/default/files/papers/2010_Jin_Nicol_Caesar.pdf Paper on gigabit Ethernet switch models for simulation]<br /> <br /> Possible tasks to fulfill the patch requirement:<br /> * TBD, contact the mentors if interested.</div>

Tommaso https://www.nsnam.org/mediawiki/index.php?title=GSOC2026Projects&diff=13725 2026-02-04T02:16:13Z

<p>Tommaso: /* Mesh Link Establishment (MLE) protocol */</p> <hr /> <div>{{TOC}}<br /> <br /> This page contains 2026 Google Summer of Code project ideas for ns-3.<br /> <br /> * [https://developers.google.com/open-source/gsoc/faq GSoC Frequently Asked Questions]<br /> * [[GSOC2026ContributorGuide | ns-3's 2026 GSoC Contributor guide]]<br /> * [https://developers.google.com/open-source/gsoc/resources/guide GSoC contributor/student guide (not ns-3 specific)]<br /> * [[GSOC2025ApplicationTemplate | 2026 GSoC Contributor application template]]<br /> * [[GSOCMentorGuide | ns-3's GSoC Mentor guide]]<br /> * [https://archive.flossmanuals.net/gsocmentoring/index.html GSoC Mentor guide (not ns-3 specific)]<br /> * [[GSOCSelectionProcess | GSoC Contributor Selection Process]]<br /> * ''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/<br /> <br /> === About the ns-3 project ===<br /> <br /> ns-3 is a discrete-event network simulator, with a particular emphasis on network research and education.<br /> <br /> 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.<br /> <br /> 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.<br /> <br /> === Org admins ===<br /> <br /> 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].<br /> <br /> === Mentors ===<br /> <br /> 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.<br /> <br /> The current list of prospective mentors can be found among the ideas listed below.<br /> <br /> === How to apply ===<br /> <br /> For students or contributors interested in applying to ns-3 for GSoC, please go through the following list to get started:<br /> * Read the official [https://developers.google.com/open-source/gsoc/resources/guide GSoC contributor guide].<br /> * Read [[GSOC2026ContributorGuide |ns-3's 2026 GSoC contributor guide]]<br /> * Look through our [[#Project Ideas]] below to see if you find a project that interests you.<br /> * Review the [https://www.nsnam.org/documentation/development-tree/ tutorial and contributing guide] thoroughly, if you have not already done so.<br /> * 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.<br /> * Next, proceed to get in touch with the developers on the mailing list or Zulip chat room and refine your proposal.<br /> * 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.<br /> <br /> 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.<br /> <br /> &lt;blockquote&gt;<br /> Each project idea within a particular priority has been tagged with the following properties:<br /> * ''Required Experience:'' Languages, concepts, or packages with which applicants must be familiar.<br /> * ''Bonus Experience:'' Other experience or familiarity which would be greatly helpful to applicants for this project.<br /> * ''Interests:'' Areas of particular relevance to this project, and an indicator of where successful contributors might apply their experiences coming out of this project.<br /> * ''Difficulty:'' easy, medium or difficult<br /> * ''Recommended reading:'' pointers to documentation, papers, specific bugs, etc.<br /> <br /> 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.<br /> &lt;/blockquote&gt;<br /> <br /> === Patch requirement guidelines ===<br /> <br /> 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.<br /> <br /> === Mentors: how to participate ===<br /> <br /> 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:<br /> <br /> * 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.<br /> * 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.<br /> * 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.<br /> <br /> == Project Ideas ==<br /> <br /> '''Note to contributors:''' These ideas are not listed in any priority order.<br /> 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.<br /> <br /> === Internet models enhancements ===<br /> <br /> * [[#AODVv2 Protocol enhancements]] (medium size project, 175h)<br /> * [[#Linux-like CAKE queue discipline for ns-3]] (large size project, 350h)<br /> * [[#Switched Ethernet]] (large size project, 350h)<br /> <br /> === IoT models enhancements ===<br /> <br /> * [[#6LoWPAN mesh-under routing enhancements]] (medium size project, 175h)<br /> * [[#6LoWPAN neighbor discovery protocol]] (medium size project, 175h)<br /> * [[#Mesh Link Establishment (MLE) protocol ]] (large size project, 350h)<br /> <br /> === 5G NR models enhancements ===<br /> <br /> 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.<br /> <br /> * [[#NTN example for 5G NR]] (small size project, 90h)<br /> * [[#Enabling 5G NR examples visualization]] (medium size project, 175h)<br /> * [[#Improving 5G NR module usability through helpers]] (medium size project, 175h)<br /> * [[#5G NR module integration with ns-3-ai]] (large size project, 250h)<br /> <br /> == Small sized projects (90 hours) ==<br /> <br /> <br /> === NTN example for 5G NR ===<br /> <br /> 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]<br /> <br /> 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).<br /> <br /> 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.<br /> <br /> * Required Experience: C++ programming, understanding of 5G NR, LTE, and wireless networks<br /> * Interests: 5G NR simulations<br /> * Difficulty: Medium.<br /> * 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.<br /> <br /> == Medium sized projects (175 hours) ==<br /> <br /> === 6LoWPAN mesh-under routing enhancements ===<br /> <br /> Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], [TBD].<br /> <br /> 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.<br /> 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.<br /> <br /> The candidate should outline what parts of code are going to be affected, and how they can be enhanced thanks to RFC 7731.<br /> <br /> * ''Required Experience:'' Fundamentals of IPv6 addressing, C++ programming.<br /> * ''Bonus Experience:'' Familiarity with mesh routing and 6LoWPAN ns-3<br /> * ''Interests:'' IPv6 mesh routing<br /> * ''Difficulty:'' Easy.<br /> * ''Recommended reading:''<br /> ** [https://www.nsnam.org/docs/models/html/sixlowpan.html#mesh-under-routing Mesh-under in ns-3 6LoWPAN]<br /> ** [https://datatracker.ietf.org/doc/html/rfc7731 RFC 7731]<br /> <br /> Possible tasks to fulfill the patch requirement:<br /> * 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 &quot;next hop&quot;. The behavior of the actual protocol should be unchanged.<br /> <br /> === 6LoWPAN neighbor discovery protocol ===<br /> <br /> Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], [mailto:adnan.rashid@poliba.it Adnan Rashid].<br /> <br /> 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.<br /> <br /> 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).<br /> <br /> 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.<br /> <br /> * ''Required Experience:'' Fundamentals of IPv6 addressing, C++ programming.<br /> * ''Bonus Experience:'' Familiarity with 6LoWPAN and 6LoWPAN-ND<br /> * ''Interests:'' IPv6 and IoT networks<br /> * ''Difficulty:'' Easy.<br /> * ''Recommended reading:''<br /> ** [https://datatracker.ietf.org/doc/html/rfc8505 RFC 8505]<br /> ** [https://datatracker.ietf.org/doc/html/rfc6775 RFC 6775]<br /> ** [https://datatracker.ietf.org/doc/html/rfc4944 RFC 4944]<br /> <br /> Possible tasks to fulfil the patch requirement:<br /> * Patch the actual 6LoWPAN-ND to remove the limitation about concurrent address registrations.<br /> <br /> === Improving 5G NR module usability through helpers ===<br /> <br /> 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]<br /> <br /> 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.<br /> <br /> 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.<br /> <br /> * Required Experience: C++ programming, understanding of 5G NR, LTE, and wireless networks<br /> * Interests: 5G NR simulations<br /> * Difficulty: Medium.<br /> * 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.<br /> <br /> === Enabling 5G NR examples visualization ===<br /> <br /> 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]<br /> <br /> 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.<br /> <br /> 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.<br /> 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].<br /> <br /> * Required Experience: C++ and Python programming, understanding of 5G NR, LTE, and wireless networks<br /> * Interests: 5G NR simulations<br /> * Difficulty: Medium.<br /> * 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.<br /> <br /> === AODVv2 Protocol enhancements ===<br /> <br /> Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], [TBD].<br /> <br /> 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.<br /> <br /> In particular the project should address the following points:<br /> # Alignment with the latest drafts,<br /> # Model finalization and testing (in particular for the IPv6 part),<br /> # AODVv2 examples and documentation,<br /> # &quot;External&quot; network routing support.<br /> <br /> Collaboration with the draft authors is also highly suggested.<br /> <br /> * ''Required Experience:'' Fundamentals of IPv6 addressing, C++ programming.<br /> * ''Bonus Experience:'' Familiarity with AODV implementations in ns-3 and AODVv2<br /> * ''Interests:'' Ad hoc routing<br /> * ''Difficulty:'' Medium.<br /> * ''Recommended reading:''<br /> ** [https://www.nsnam.org/docs/models/html/ipv6.html IPv6 model in ns-3]<br /> ** [https://www.nsnam.org/docs/models/html/aodv.html AODV model in ns-3]<br /> ** [https://gitlab.com/tod97/ns-3-dev/-/tree/aodvv2-icns3-25 AODVv2 model presented at ICNS3-2025] <br /> ** [https://datatracker.ietf.org/doc/draft-perkins-manet-aodvv2/05/ Ad Hoc On-demand Distance Vector Version 2 (AODVv2) Routing]<br /> <br /> Possible tasks to fulfill the patch requirement:<br /> * [https://gitlab.com/nsnam/ns-3-dev/-/issues/368 Issue #368] - aodv: aodv parameters can be set to &quot;impossible&quot; values<br /> <br /> == Large projects (350 hours) ==<br /> <br /> === Mesh Link Establishment (MLE) protocol ===<br /> <br /> Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], [mailto:alramonet@is.tokushima-u.ac.jp Alberto Gallegos Ramonet].<br /> <br /> 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.<br /> However, MLE is being used in Thread, and it can be useful to implement it.<br /> <br /> 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.<br /> <br /> * ''Required Experience:'' Fundamentals of IPv4 and IPv6 sockets, C++ programming.<br /> * ''Interests:'' Sockets and API interface implementation.<br /> * ''Difficulty:'' Hard.<br /> * ''Recommended reading:''<br /> ** [https://datatracker.ietf.org/doc/html/draft-ietf-6lo-mesh-link-establishment MLE draft]<br /> ** [https://openthread.io/guides/thread-primer/network-discovery Thread primer]<br /> ** [https://www.threadgroup.org/ThreadSpec Thread specifications]<br /> <br /> Possible tasks to fulfill the patch requirement:<br /> * TBD, contact the mentors if interested.<br /> <br /> === 5G NR module integration with ns-3-ai ===<br /> <br /> 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]<br /> <br /> 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.<br /> <br /> 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.<br /> For more specific guidelines, please view this [https://docs.google.com/document/d/1cQLIF1cdft1yj3vyWrjrxN2xDJMx8PuWaa9NP_nKf64/edit?usp=sharing Google document].<br /> <br /> * Required Experience: C++ programming, understanding of 5G NR, LTE, and wireless networks<br /> * Interests: 5G NR simulations<br /> * Difficulty: Medium.<br /> * 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.<br /> <br /> === Linux-like CAKE queue discipline for ns-3 ===<br /> <br /> Mentors: [mailto:tahiliani.nitk@gmail.com Mohit P. Tahiliani]<br /> <br /> 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.<br /> <br /> * ''Required Experience:'' Familiarity with queue disciplines, TCP and C++ programming.<br /> * ''Bonus Experience:'' Familiarity with CAKE framework in Linux 4.19<br /> * ''Interests:'' Active Queue Management, Packet scheduling and TCP.<br /> * ''Difficulty:'' Medium to Hard<br /> * ''Recommended reading:''<br /> ** [https://arxiv.org/pdf/1804.07617.pdf Piece of CAKE: A Comprehensive Queue Management Solution for Home Gateways]<br /> ** [https://lwn.net/Articles/758353/ Let them run CAKE]<br /> ** [https://www.nsnam.org/docs/models/html/queue-discs.html Queue disciplines in ns-3]<br /> <br /> === Switched Ethernet ===<br /> <br /> Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], TBD.<br /> <br /> 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.<br /> <br /> 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.<br /> <br /> 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.<br /> <br /> 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.<br /> <br /> 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.<br /> <br /> * ''Required Experience:'' Fundamentals of Ethernet sitched networking, C++ programming.<br /> * ''Interests:'' Ethernet networks and switched data networks.<br /> * ''Difficulty:'' Medium.<br /> * ''Recommended reading:''<br /> ** [https://www2.nsnam.org/bugzilla/show_bug.cgi?id=2602 Basic implementation (very old)]<br /> ** [https://gitlab.com/nsnam/ns-3-dev/-/merge_requests/431 Full-duplex CSMA, somehow related]<br /> ** [https://tcipg.org/sites/default/files/papers/2010_Jin_Nicol_Caesar.pdf Paper on gigabit Ethernet switch models for simulation]<br /> <br /> Possible tasks to fulfill the patch requirement:<br /> * TBD, contact the mentors if interested.</div>

Tommaso https://www.nsnam.org/mediawiki/index.php?title=GSOC2026Projects&diff=13724 2026-01-27T02:10:42Z

<p>Tommaso: /* IoT models enhancements */</p> <hr /> <div>{{TOC}}<br /> <br /> This page contains 2026 Google Summer of Code project ideas for ns-3.<br /> <br /> * [https://developers.google.com/open-source/gsoc/faq GSoC Frequently Asked Questions]<br /> * [[GSOC2026ContributorGuide | ns-3's 2026 GSoC Contributor guide]]<br /> * [https://developers.google.com/open-source/gsoc/resources/guide GSoC contributor/student guide (not ns-3 specific)]<br /> * [[GSOC2025ApplicationTemplate | 2026 GSoC Contributor application template]]<br /> * [[GSOCMentorGuide | ns-3's GSoC Mentor guide]]<br /> * [https://archive.flossmanuals.net/gsocmentoring/index.html GSoC Mentor guide (not ns-3 specific)]<br /> * [[GSOCSelectionProcess | GSoC Contributor Selection Process]]<br /> * ''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/<br /> <br /> === About the ns-3 project ===<br /> <br /> ns-3 is a discrete-event network simulator, with a particular emphasis on network research and education.<br /> <br /> 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.<br /> <br /> 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.<br /> <br /> === Org admins ===<br /> <br /> 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].<br /> <br /> === Mentors ===<br /> <br /> 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.<br /> <br /> The current list of prospective mentors can be found among the ideas listed below.<br /> <br /> === How to apply ===<br /> <br /> For students or contributors interested in applying to ns-3 for GSoC, please go through the following list to get started:<br /> * Read the official [https://developers.google.com/open-source/gsoc/resources/guide GSoC contributor guide].<br /> * Read [[GSOC2026ContributorGuide |ns-3's 2026 GSoC contributor guide]]<br /> * Look through our [[#Project Ideas]] below to see if you find a project that interests you.<br /> * Review the [https://www.nsnam.org/documentation/development-tree/ tutorial and contributing guide] thoroughly, if you have not already done so.<br /> * 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.<br /> * Next, proceed to get in touch with the developers on the mailing list or Zulip chat room and refine your proposal.<br /> * 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.<br /> <br /> 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.<br /> <br /> &lt;blockquote&gt;<br /> Each project idea within a particular priority has been tagged with the following properties:<br /> * ''Required Experience:'' Languages, concepts, or packages with which applicants must be familiar.<br /> * ''Bonus Experience:'' Other experience or familiarity which would be greatly helpful to applicants for this project.<br /> * ''Interests:'' Areas of particular relevance to this project, and an indicator of where successful contributors might apply their experiences coming out of this project.<br /> * ''Difficulty:'' easy, medium or difficult<br /> * ''Recommended reading:'' pointers to documentation, papers, specific bugs, etc.<br /> <br /> 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.<br /> &lt;/blockquote&gt;<br /> <br /> === Patch requirement guidelines ===<br /> <br /> 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.<br /> <br /> === Mentors: how to participate ===<br /> <br /> 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:<br /> <br /> * 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.<br /> * 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.<br /> * 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.<br /> <br /> == Project Ideas ==<br /> <br /> '''Note to contributors:''' These ideas are not listed in any priority order.<br /> 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.<br /> <br /> === Internet models enhancements ===<br /> <br /> * [[#AODVv2 Protocol enhancements]] (medium size project, 175h)<br /> * [[#Linux-like CAKE queue discipline for ns-3]] (large size project, 350h)<br /> * [[#Switched Ethernet]] (large size project, 350h)<br /> <br /> === IoT models enhancements ===<br /> <br /> * [[#6LoWPAN mesh-under routing enhancements]] (medium size project, 175h)<br /> * [[#6LoWPAN neighbor discovery protocol]] (medium size project, 175h)<br /> * [[#Mesh Link Establishment (MLE) protocol ]] (large size project, 350h)<br /> <br /> === 5G NR models enhancements ===<br /> <br /> 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.<br /> <br /> * [[#NTN example for 5G NR]] (small size project, 90h)<br /> * [[#Enabling 5G NR examples visualization]] (medium size project, 175h)<br /> * [[#Improving 5G NR module usability through helpers]] (medium size project, 175h)<br /> * [[#5G NR module integration with ns-3-ai]] (large size project, 250h)<br /> <br /> == Small sized projects (90 hours) ==<br /> <br /> <br /> === NTN example for 5G NR ===<br /> <br /> 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]<br /> <br /> 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).<br /> <br /> 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.<br /> <br /> * Required Experience: C++ programming, understanding of 5G NR, LTE, and wireless networks<br /> * Interests: 5G NR simulations<br /> * Difficulty: Medium.<br /> * 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.<br /> <br /> == Medium sized projects (175 hours) ==<br /> <br /> === 6LoWPAN mesh-under routing enhancements ===<br /> <br /> Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], [TBD].<br /> <br /> 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.<br /> 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.<br /> <br /> The candidate should outline what parts of code are going to be affected, and how they can be enhanced thanks to RFC 7731.<br /> <br /> * ''Required Experience:'' Fundamentals of IPv6 addressing, C++ programming.<br /> * ''Bonus Experience:'' Familiarity with mesh routing and 6LoWPAN ns-3<br /> * ''Interests:'' IPv6 mesh routing<br /> * ''Difficulty:'' Easy.<br /> * ''Recommended reading:''<br /> ** [https://www.nsnam.org/docs/models/html/sixlowpan.html#mesh-under-routing Mesh-under in ns-3 6LoWPAN]<br /> ** [https://datatracker.ietf.org/doc/html/rfc7731 RFC 7731]<br /> <br /> Possible tasks to fulfill the patch requirement:<br /> * 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 &quot;next hop&quot;. The behavior of the actual protocol should be unchanged.<br /> <br /> === 6LoWPAN neighbor discovery protocol ===<br /> <br /> Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], [mailto:adnan.rashid@poliba.it Adnan Rashid].<br /> <br /> 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.<br /> <br /> 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).<br /> <br /> 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.<br /> <br /> * ''Required Experience:'' Fundamentals of IPv6 addressing, C++ programming.<br /> * ''Bonus Experience:'' Familiarity with 6LoWPAN and 6LoWPAN-ND<br /> * ''Interests:'' IPv6 and IoT networks<br /> * ''Difficulty:'' Easy.<br /> * ''Recommended reading:''<br /> ** [https://datatracker.ietf.org/doc/html/rfc8505 RFC 8505]<br /> ** [https://datatracker.ietf.org/doc/html/rfc6775 RFC 6775]<br /> ** [https://datatracker.ietf.org/doc/html/rfc4944 RFC 4944]<br /> <br /> Possible tasks to fulfil the patch requirement:<br /> * Patch the actual 6LoWPAN-ND to remove the limitation about concurrent address registrations.<br /> <br /> === Improving 5G NR module usability through helpers ===<br /> <br /> 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]<br /> <br /> 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.<br /> <br /> 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.<br /> <br /> * Required Experience: C++ programming, understanding of 5G NR, LTE, and wireless networks<br /> * Interests: 5G NR simulations<br /> * Difficulty: Medium.<br /> * 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.<br /> <br /> === Enabling 5G NR examples visualization ===<br /> <br /> 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]<br /> <br /> 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.<br /> <br /> 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.<br /> 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].<br /> <br /> * Required Experience: C++ and Python programming, understanding of 5G NR, LTE, and wireless networks<br /> * Interests: 5G NR simulations<br /> * Difficulty: Medium.<br /> * 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.<br /> <br /> === AODVv2 Protocol enhancements ===<br /> <br /> Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], [TBD].<br /> <br /> 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.<br /> <br /> In particular the project should address the following points:<br /> # Alignment with the latest drafts,<br /> # Model finalization and testing (in particular for the IPv6 part),<br /> # AODVv2 examples and documentation,<br /> # &quot;External&quot; network routing support.<br /> <br /> Collaboration with the draft authors is also highly suggested.<br /> <br /> * ''Required Experience:'' Fundamentals of IPv6 addressing, C++ programming.<br /> * ''Bonus Experience:'' Familiarity with AODV implementations in ns-3 and AODVv2<br /> * ''Interests:'' Ad hoc routing<br /> * ''Difficulty:'' Medium.<br /> * ''Recommended reading:''<br /> ** [https://www.nsnam.org/docs/models/html/ipv6.html IPv6 model in ns-3]<br /> ** [https://www.nsnam.org/docs/models/html/aodv.html AODV model in ns-3]<br /> ** [https://gitlab.com/tod97/ns-3-dev/-/tree/aodvv2-icns3-25 AODVv2 model presented at ICNS3-2025] <br /> ** [https://datatracker.ietf.org/doc/draft-perkins-manet-aodvv2/05/ Ad Hoc On-demand Distance Vector Version 2 (AODVv2) Routing]<br /> <br /> Possible tasks to fulfill the patch requirement:<br /> * [https://gitlab.com/nsnam/ns-3-dev/-/issues/368 Issue #368] - aodv: aodv parameters can be set to &quot;impossible&quot; values<br /> <br /> == Large projects (350 hours) ==<br /> <br /> === Mesh Link Establishment (MLE) protocol ===<br /> <br /> Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], TBD.<br /> <br /> 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.<br /> However, MLE is being used in Thread, and it can be useful to implement it.<br /> <br /> 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.<br /> <br /> * ''Required Experience:'' Fundamentals of IPv4 and IPv6 sockets, C++ programming.<br /> * ''Interests:'' Sockets and API interface implementation.<br /> * ''Difficulty:'' Hard.<br /> * ''Recommended reading:''<br /> ** [https://datatracker.ietf.org/doc/html/draft-ietf-6lo-mesh-link-establishment MLE draft]<br /> ** [https://openthread.io/guides/thread-primer/network-discovery Thread primer]<br /> ** [https://www.threadgroup.org/ThreadSpec Thread specifications]<br /> <br /> Possible tasks to fulfill the patch requirement:<br /> * TBD, contact the mentors if interested.<br /> <br /> === 5G NR module integration with ns-3-ai ===<br /> <br /> 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]<br /> <br /> 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.<br /> <br /> 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.<br /> For more specific guidelines, please view this [https://docs.google.com/document/d/1cQLIF1cdft1yj3vyWrjrxN2xDJMx8PuWaa9NP_nKf64/edit?usp=sharing Google document].<br /> <br /> * Required Experience: C++ programming, understanding of 5G NR, LTE, and wireless networks<br /> * Interests: 5G NR simulations<br /> * Difficulty: Medium.<br /> * 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.<br /> <br /> === Linux-like CAKE queue discipline for ns-3 ===<br /> <br /> Mentors: [mailto:tahiliani.nitk@gmail.com Mohit P. Tahiliani]<br /> <br /> 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.<br /> <br /> * ''Required Experience:'' Familiarity with queue disciplines, TCP and C++ programming.<br /> * ''Bonus Experience:'' Familiarity with CAKE framework in Linux 4.19<br /> * ''Interests:'' Active Queue Management, Packet scheduling and TCP.<br /> * ''Difficulty:'' Medium to Hard<br /> * ''Recommended reading:''<br /> ** [https://arxiv.org/pdf/1804.07617.pdf Piece of CAKE: A Comprehensive Queue Management Solution for Home Gateways]<br /> ** [https://lwn.net/Articles/758353/ Let them run CAKE]<br /> ** [https://www.nsnam.org/docs/models/html/queue-discs.html Queue disciplines in ns-3]<br /> <br /> === Switched Ethernet ===<br /> <br /> Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], TBD.<br /> <br /> 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.<br /> <br /> 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.<br /> <br /> 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.<br /> <br /> 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.<br /> <br /> 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.<br /> <br /> * ''Required Experience:'' Fundamentals of Ethernet sitched networking, C++ programming.<br /> * ''Interests:'' Ethernet networks and switched data networks.<br /> * ''Difficulty:'' Medium.<br /> * ''Recommended reading:''<br /> ** [https://www2.nsnam.org/bugzilla/show_bug.cgi?id=2602 Basic implementation (very old)]<br /> ** [https://gitlab.com/nsnam/ns-3-dev/-/merge_requests/431 Full-duplex CSMA, somehow related]<br /> ** [https://tcipg.org/sites/default/files/papers/2010_Jin_Nicol_Caesar.pdf Paper on gigabit Ethernet switch models for simulation]<br /> <br /> Possible tasks to fulfill the patch requirement:<br /> * TBD, contact the mentors if interested.</div>

Tommaso https://www.nsnam.org/mediawiki/index.php?title=GSOC2026Projects&diff=13723 2026-01-27T02:10:10Z

<p>Tommaso: /* Lr-WPAN (IEEE 802.15.4) preamble detection support */</p> <hr /> <div>{{TOC}}<br /> <br /> This page contains 2026 Google Summer of Code project ideas for ns-3.<br /> <br /> * [https://developers.google.com/open-source/gsoc/faq GSoC Frequently Asked Questions]<br /> * [[GSOC2026ContributorGuide | ns-3's 2026 GSoC Contributor guide]]<br /> * [https://developers.google.com/open-source/gsoc/resources/guide GSoC contributor/student guide (not ns-3 specific)]<br /> * [[GSOC2025ApplicationTemplate | 2026 GSoC Contributor application template]]<br /> * [[GSOCMentorGuide | ns-3's GSoC Mentor guide]]<br /> * [https://archive.flossmanuals.net/gsocmentoring/index.html GSoC Mentor guide (not ns-3 specific)]<br /> * [[GSOCSelectionProcess | GSoC Contributor Selection Process]]<br /> * ''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/<br /> <br /> === About the ns-3 project ===<br /> <br /> ns-3 is a discrete-event network simulator, with a particular emphasis on network research and education.<br /> <br /> 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.<br /> <br /> 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.<br /> <br /> === Org admins ===<br /> <br /> 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].<br /> <br /> === Mentors ===<br /> <br /> 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.<br /> <br /> The current list of prospective mentors can be found among the ideas listed below.<br /> <br /> === How to apply ===<br /> <br /> For students or contributors interested in applying to ns-3 for GSoC, please go through the following list to get started:<br /> * Read the official [https://developers.google.com/open-source/gsoc/resources/guide GSoC contributor guide].<br /> * Read [[GSOC2026ContributorGuide |ns-3's 2026 GSoC contributor guide]]<br /> * Look through our [[#Project Ideas]] below to see if you find a project that interests you.<br /> * Review the [https://www.nsnam.org/documentation/development-tree/ tutorial and contributing guide] thoroughly, if you have not already done so.<br /> * 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.<br /> * Next, proceed to get in touch with the developers on the mailing list or Zulip chat room and refine your proposal.<br /> * 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.<br /> <br /> 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.<br /> <br /> &lt;blockquote&gt;<br /> Each project idea within a particular priority has been tagged with the following properties:<br /> * ''Required Experience:'' Languages, concepts, or packages with which applicants must be familiar.<br /> * ''Bonus Experience:'' Other experience or familiarity which would be greatly helpful to applicants for this project.<br /> * ''Interests:'' Areas of particular relevance to this project, and an indicator of where successful contributors might apply their experiences coming out of this project.<br /> * ''Difficulty:'' easy, medium or difficult<br /> * ''Recommended reading:'' pointers to documentation, papers, specific bugs, etc.<br /> <br /> 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.<br /> &lt;/blockquote&gt;<br /> <br /> === Patch requirement guidelines ===<br /> <br /> 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.<br /> <br /> === Mentors: how to participate ===<br /> <br /> 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:<br /> <br /> * 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.<br /> * 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.<br /> * 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.<br /> <br /> == Project Ideas ==<br /> <br /> '''Note to contributors:''' These ideas are not listed in any priority order.<br /> 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.<br /> <br /> === Internet models enhancements ===<br /> <br /> * [[#AODVv2 Protocol enhancements]] (medium size project, 175h)<br /> * [[#Linux-like CAKE queue discipline for ns-3]] (large size project, 350h)<br /> * [[#Switched Ethernet]] (large size project, 350h)<br /> <br /> === IoT models enhancements ===<br /> <br /> * [[#6LoWPAN mesh-under routing enhancements]] (medium size project, 175h)<br /> * [[#6LoWPAN neighbor discovery protocol]] (medium size project, 175h)<br /> * [[#Mesh Link Establishment (MLE) protocol ]] (large size project, 350h)<br /> * [[#Lr-WPAN (IEEE 802.15.4) preamble detection support]] (large size project, 350h)<br /> <br /> === 5G NR models enhancements ===<br /> <br /> 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.<br /> <br /> * [[#NTN example for 5G NR]] (small size project, 90h)<br /> * [[#Enabling 5G NR examples visualization]] (medium size project, 175h)<br /> * [[#Improving 5G NR module usability through helpers]] (medium size project, 175h)<br /> * [[#5G NR module integration with ns-3-ai]] (large size project, 250h)<br /> <br /> == Small sized projects (90 hours) ==<br /> <br /> <br /> === NTN example for 5G NR ===<br /> <br /> 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]<br /> <br /> 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).<br /> <br /> 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.<br /> <br /> * Required Experience: C++ programming, understanding of 5G NR, LTE, and wireless networks<br /> * Interests: 5G NR simulations<br /> * Difficulty: Medium.<br /> * 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.<br /> <br /> == Medium sized projects (175 hours) ==<br /> <br /> === 6LoWPAN mesh-under routing enhancements ===<br /> <br /> Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], [TBD].<br /> <br /> 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.<br /> 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.<br /> <br /> The candidate should outline what parts of code are going to be affected, and how they can be enhanced thanks to RFC 7731.<br /> <br /> * ''Required Experience:'' Fundamentals of IPv6 addressing, C++ programming.<br /> * ''Bonus Experience:'' Familiarity with mesh routing and 6LoWPAN ns-3<br /> * ''Interests:'' IPv6 mesh routing<br /> * ''Difficulty:'' Easy.<br /> * ''Recommended reading:''<br /> ** [https://www.nsnam.org/docs/models/html/sixlowpan.html#mesh-under-routing Mesh-under in ns-3 6LoWPAN]<br /> ** [https://datatracker.ietf.org/doc/html/rfc7731 RFC 7731]<br /> <br /> Possible tasks to fulfill the patch requirement:<br /> * 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 &quot;next hop&quot;. The behavior of the actual protocol should be unchanged.<br /> <br /> === 6LoWPAN neighbor discovery protocol ===<br /> <br /> Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], [mailto:adnan.rashid@poliba.it Adnan Rashid].<br /> <br /> 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.<br /> <br /> 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).<br /> <br /> 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.<br /> <br /> * ''Required Experience:'' Fundamentals of IPv6 addressing, C++ programming.<br /> * ''Bonus Experience:'' Familiarity with 6LoWPAN and 6LoWPAN-ND<br /> * ''Interests:'' IPv6 and IoT networks<br /> * ''Difficulty:'' Easy.<br /> * ''Recommended reading:''<br /> ** [https://datatracker.ietf.org/doc/html/rfc8505 RFC 8505]<br /> ** [https://datatracker.ietf.org/doc/html/rfc6775 RFC 6775]<br /> ** [https://datatracker.ietf.org/doc/html/rfc4944 RFC 4944]<br /> <br /> Possible tasks to fulfil the patch requirement:<br /> * Patch the actual 6LoWPAN-ND to remove the limitation about concurrent address registrations.<br /> <br /> === Improving 5G NR module usability through helpers ===<br /> <br /> 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]<br /> <br /> 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.<br /> <br /> 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.<br /> <br /> * Required Experience: C++ programming, understanding of 5G NR, LTE, and wireless networks<br /> * Interests: 5G NR simulations<br /> * Difficulty: Medium.<br /> * 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.<br /> <br /> === Enabling 5G NR examples visualization ===<br /> <br /> 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]<br /> <br /> 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.<br /> <br /> 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.<br /> 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].<br /> <br /> * Required Experience: C++ and Python programming, understanding of 5G NR, LTE, and wireless networks<br /> * Interests: 5G NR simulations<br /> * Difficulty: Medium.<br /> * 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.<br /> <br /> === AODVv2 Protocol enhancements ===<br /> <br /> Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], [TBD].<br /> <br /> 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.<br /> <br /> In particular the project should address the following points:<br /> # Alignment with the latest drafts,<br /> # Model finalization and testing (in particular for the IPv6 part),<br /> # AODVv2 examples and documentation,<br /> # &quot;External&quot; network routing support.<br /> <br /> Collaboration with the draft authors is also highly suggested.<br /> <br /> * ''Required Experience:'' Fundamentals of IPv6 addressing, C++ programming.<br /> * ''Bonus Experience:'' Familiarity with AODV implementations in ns-3 and AODVv2<br /> * ''Interests:'' Ad hoc routing<br /> * ''Difficulty:'' Medium.<br /> * ''Recommended reading:''<br /> ** [https://www.nsnam.org/docs/models/html/ipv6.html IPv6 model in ns-3]<br /> ** [https://www.nsnam.org/docs/models/html/aodv.html AODV model in ns-3]<br /> ** [https://gitlab.com/tod97/ns-3-dev/-/tree/aodvv2-icns3-25 AODVv2 model presented at ICNS3-2025] <br /> ** [https://datatracker.ietf.org/doc/draft-perkins-manet-aodvv2/05/ Ad Hoc On-demand Distance Vector Version 2 (AODVv2) Routing]<br /> <br /> Possible tasks to fulfill the patch requirement:<br /> * [https://gitlab.com/nsnam/ns-3-dev/-/issues/368 Issue #368] - aodv: aodv parameters can be set to &quot;impossible&quot; values<br /> <br /> == Large projects (350 hours) ==<br /> <br /> === Mesh Link Establishment (MLE) protocol ===<br /> <br /> Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], TBD.<br /> <br /> 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.<br /> However, MLE is being used in Thread, and it can be useful to implement it.<br /> <br /> 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.<br /> <br /> * ''Required Experience:'' Fundamentals of IPv4 and IPv6 sockets, C++ programming.<br /> * ''Interests:'' Sockets and API interface implementation.<br /> * ''Difficulty:'' Hard.<br /> * ''Recommended reading:''<br /> ** [https://datatracker.ietf.org/doc/html/draft-ietf-6lo-mesh-link-establishment MLE draft]<br /> ** [https://openthread.io/guides/thread-primer/network-discovery Thread primer]<br /> ** [https://www.threadgroup.org/ThreadSpec Thread specifications]<br /> <br /> Possible tasks to fulfill the patch requirement:<br /> * TBD, contact the mentors if interested.<br /> <br /> === 5G NR module integration with ns-3-ai ===<br /> <br /> 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]<br /> <br /> 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.<br /> <br /> 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.<br /> For more specific guidelines, please view this [https://docs.google.com/document/d/1cQLIF1cdft1yj3vyWrjrxN2xDJMx8PuWaa9NP_nKf64/edit?usp=sharing Google document].<br /> <br /> * Required Experience: C++ programming, understanding of 5G NR, LTE, and wireless networks<br /> * Interests: 5G NR simulations<br /> * Difficulty: Medium.<br /> * 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.<br /> <br /> === Linux-like CAKE queue discipline for ns-3 ===<br /> <br /> Mentors: [mailto:tahiliani.nitk@gmail.com Mohit P. Tahiliani]<br /> <br /> 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.<br /> <br /> * ''Required Experience:'' Familiarity with queue disciplines, TCP and C++ programming.<br /> * ''Bonus Experience:'' Familiarity with CAKE framework in Linux 4.19<br /> * ''Interests:'' Active Queue Management, Packet scheduling and TCP.<br /> * ''Difficulty:'' Medium to Hard<br /> * ''Recommended reading:''<br /> ** [https://arxiv.org/pdf/1804.07617.pdf Piece of CAKE: A Comprehensive Queue Management Solution for Home Gateways]<br /> ** [https://lwn.net/Articles/758353/ Let them run CAKE]<br /> ** [https://www.nsnam.org/docs/models/html/queue-discs.html Queue disciplines in ns-3]<br /> <br /> === Switched Ethernet ===<br /> <br /> Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], TBD.<br /> <br /> 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.<br /> <br /> 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.<br /> <br /> 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.<br /> <br /> 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.<br /> <br /> 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.<br /> <br /> * ''Required Experience:'' Fundamentals of Ethernet sitched networking, C++ programming.<br /> * ''Interests:'' Ethernet networks and switched data networks.<br /> * ''Difficulty:'' Medium.<br /> * ''Recommended reading:''<br /> ** [https://www2.nsnam.org/bugzilla/show_bug.cgi?id=2602 Basic implementation (very old)]<br /> ** [https://gitlab.com/nsnam/ns-3-dev/-/merge_requests/431 Full-duplex CSMA, somehow related]<br /> ** [https://tcipg.org/sites/default/files/papers/2010_Jin_Nicol_Caesar.pdf Paper on gigabit Ethernet switch models for simulation]<br /> <br /> Possible tasks to fulfill the patch requirement:<br /> * TBD, contact the mentors if interested.</div>

Tommaso https://www.nsnam.org/mediawiki/index.php?title=GSOC2026Projects&diff=13722 2026-01-26T19:44:07Z

<p>Tommaso: /* IPv6 global routing */</p> <hr /> <div>{{TOC}}<br /> <br /> This page contains 2026 Google Summer of Code project ideas for ns-3.<br /> <br /> * [https://developers.google.com/open-source/gsoc/faq GSoC Frequently Asked Questions]<br /> * [[GSOC2026ContributorGuide | ns-3's 2026 GSoC Contributor guide]]<br /> * [https://developers.google.com/open-source/gsoc/resources/guide GSoC contributor/student guide (not ns-3 specific)]<br /> * [[GSOC2025ApplicationTemplate | 2026 GSoC Contributor application template]]<br /> * [[GSOCMentorGuide | ns-3's GSoC Mentor guide]]<br /> * [https://archive.flossmanuals.net/gsocmentoring/index.html GSoC Mentor guide (not ns-3 specific)]<br /> * [[GSOCSelectionProcess | GSoC Contributor Selection Process]]<br /> * ''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/<br /> <br /> === About the ns-3 project ===<br /> <br /> ns-3 is a discrete-event network simulator, with a particular emphasis on network research and education.<br /> <br /> 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.<br /> <br /> 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.<br /> <br /> === Org admins ===<br /> <br /> 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].<br /> <br /> === Mentors ===<br /> <br /> 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.<br /> <br /> The current list of prospective mentors can be found among the ideas listed below.<br /> <br /> === How to apply ===<br /> <br /> For students or contributors interested in applying to ns-3 for GSoC, please go through the following list to get started:<br /> * Read the official [https://developers.google.com/open-source/gsoc/resources/guide GSoC contributor guide].<br /> * Read [[GSOC2026ContributorGuide |ns-3's 2026 GSoC contributor guide]]<br /> * Look through our [[#Project Ideas]] below to see if you find a project that interests you.<br /> * Review the [https://www.nsnam.org/documentation/development-tree/ tutorial and contributing guide] thoroughly, if you have not already done so.<br /> * 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.<br /> * Next, proceed to get in touch with the developers on the mailing list or Zulip chat room and refine your proposal.<br /> * 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.<br /> <br /> 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.<br /> <br /> &lt;blockquote&gt;<br /> Each project idea within a particular priority has been tagged with the following properties:<br /> * ''Required Experience:'' Languages, concepts, or packages with which applicants must be familiar.<br /> * ''Bonus Experience:'' Other experience or familiarity which would be greatly helpful to applicants for this project.<br /> * ''Interests:'' Areas of particular relevance to this project, and an indicator of where successful contributors might apply their experiences coming out of this project.<br /> * ''Difficulty:'' easy, medium or difficult<br /> * ''Recommended reading:'' pointers to documentation, papers, specific bugs, etc.<br /> <br /> 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.<br /> &lt;/blockquote&gt;<br /> <br /> === Patch requirement guidelines ===<br /> <br /> 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.<br /> <br /> === Mentors: how to participate ===<br /> <br /> 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:<br /> <br /> * 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.<br /> * 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.<br /> * 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.<br /> <br /> == Project Ideas ==<br /> <br /> '''Note to contributors:''' These ideas are not listed in any priority order.<br /> 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.<br /> <br /> === Internet models enhancements ===<br /> <br /> * [[#AODVv2 Protocol enhancements]] (medium size project, 175h)<br /> * [[#Linux-like CAKE queue discipline for ns-3]] (large size project, 350h)<br /> * [[#Switched Ethernet]] (large size project, 350h)<br /> <br /> === IoT models enhancements ===<br /> <br /> * [[#6LoWPAN mesh-under routing enhancements]] (medium size project, 175h)<br /> * [[#6LoWPAN neighbor discovery protocol]] (medium size project, 175h)<br /> * [[#Mesh Link Establishment (MLE) protocol ]] (large size project, 350h)<br /> * [[#Lr-WPAN (IEEE 802.15.4) preamble detection support]] (large size project, 350h)<br /> <br /> === 5G NR models enhancements ===<br /> <br /> 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.<br /> <br /> * [[#NTN example for 5G NR]] (small size project, 90h)<br /> * [[#Enabling 5G NR examples visualization]] (medium size project, 175h)<br /> * [[#Improving 5G NR module usability through helpers]] (medium size project, 175h)<br /> * [[#5G NR module integration with ns-3-ai]] (large size project, 250h)<br /> <br /> == Small sized projects (90 hours) ==<br /> <br /> <br /> === NTN example for 5G NR ===<br /> <br /> 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]<br /> <br /> 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).<br /> <br /> 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.<br /> <br /> * Required Experience: C++ programming, understanding of 5G NR, LTE, and wireless networks<br /> * Interests: 5G NR simulations<br /> * Difficulty: Medium.<br /> * 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.<br /> <br /> == Medium sized projects (175 hours) ==<br /> <br /> === 6LoWPAN mesh-under routing enhancements ===<br /> <br /> Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], [TBD].<br /> <br /> 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.<br /> 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.<br /> <br /> The candidate should outline what parts of code are going to be affected, and how they can be enhanced thanks to RFC 7731.<br /> <br /> * ''Required Experience:'' Fundamentals of IPv6 addressing, C++ programming.<br /> * ''Bonus Experience:'' Familiarity with mesh routing and 6LoWPAN ns-3<br /> * ''Interests:'' IPv6 mesh routing<br /> * ''Difficulty:'' Easy.<br /> * ''Recommended reading:''<br /> ** [https://www.nsnam.org/docs/models/html/sixlowpan.html#mesh-under-routing Mesh-under in ns-3 6LoWPAN]<br /> ** [https://datatracker.ietf.org/doc/html/rfc7731 RFC 7731]<br /> <br /> Possible tasks to fulfill the patch requirement:<br /> * 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 &quot;next hop&quot;. The behavior of the actual protocol should be unchanged.<br /> <br /> === 6LoWPAN neighbor discovery protocol ===<br /> <br /> Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], [mailto:adnan.rashid@poliba.it Adnan Rashid].<br /> <br /> 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.<br /> <br /> 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).<br /> <br /> 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.<br /> <br /> * ''Required Experience:'' Fundamentals of IPv6 addressing, C++ programming.<br /> * ''Bonus Experience:'' Familiarity with 6LoWPAN and 6LoWPAN-ND<br /> * ''Interests:'' IPv6 and IoT networks<br /> * ''Difficulty:'' Easy.<br /> * ''Recommended reading:''<br /> ** [https://datatracker.ietf.org/doc/html/rfc8505 RFC 8505]<br /> ** [https://datatracker.ietf.org/doc/html/rfc6775 RFC 6775]<br /> ** [https://datatracker.ietf.org/doc/html/rfc4944 RFC 4944]<br /> <br /> Possible tasks to fulfil the patch requirement:<br /> * Patch the actual 6LoWPAN-ND to remove the limitation about concurrent address registrations.<br /> <br /> === Improving 5G NR module usability through helpers ===<br /> <br /> 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]<br /> <br /> 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.<br /> <br /> 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.<br /> <br /> * Required Experience: C++ programming, understanding of 5G NR, LTE, and wireless networks<br /> * Interests: 5G NR simulations<br /> * Difficulty: Medium.<br /> * 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.<br /> <br /> === Enabling 5G NR examples visualization ===<br /> <br /> 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]<br /> <br /> 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.<br /> <br /> 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.<br /> 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].<br /> <br /> * Required Experience: C++ and Python programming, understanding of 5G NR, LTE, and wireless networks<br /> * Interests: 5G NR simulations<br /> * Difficulty: Medium.<br /> * 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.<br /> <br /> === AODVv2 Protocol enhancements ===<br /> <br /> Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], [TBD].<br /> <br /> 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.<br /> <br /> In particular the project should address the following points:<br /> # Alignment with the latest drafts,<br /> # Model finalization and testing (in particular for the IPv6 part),<br /> # AODVv2 examples and documentation,<br /> # &quot;External&quot; network routing support.<br /> <br /> Collaboration with the draft authors is also highly suggested.<br /> <br /> * ''Required Experience:'' Fundamentals of IPv6 addressing, C++ programming.<br /> * ''Bonus Experience:'' Familiarity with AODV implementations in ns-3 and AODVv2<br /> * ''Interests:'' Ad hoc routing<br /> * ''Difficulty:'' Medium.<br /> * ''Recommended reading:''<br /> ** [https://www.nsnam.org/docs/models/html/ipv6.html IPv6 model in ns-3]<br /> ** [https://www.nsnam.org/docs/models/html/aodv.html AODV model in ns-3]<br /> ** [https://gitlab.com/tod97/ns-3-dev/-/tree/aodvv2-icns3-25 AODVv2 model presented at ICNS3-2025] <br /> ** [https://datatracker.ietf.org/doc/draft-perkins-manet-aodvv2/05/ Ad Hoc On-demand Distance Vector Version 2 (AODVv2) Routing]<br /> <br /> Possible tasks to fulfill the patch requirement:<br /> * [https://gitlab.com/nsnam/ns-3-dev/-/issues/368 Issue #368] - aodv: aodv parameters can be set to &quot;impossible&quot; values<br /> <br /> == Large projects (350 hours) ==<br /> <br /> === Mesh Link Establishment (MLE) protocol ===<br /> <br /> Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], TBD.<br /> <br /> 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.<br /> However, MLE is being used in Thread, and it can be useful to implement it.<br /> <br /> 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.<br /> <br /> * ''Required Experience:'' Fundamentals of IPv4 and IPv6 sockets, C++ programming.<br /> * ''Interests:'' Sockets and API interface implementation.<br /> * ''Difficulty:'' Hard.<br /> * ''Recommended reading:''<br /> ** [https://datatracker.ietf.org/doc/html/draft-ietf-6lo-mesh-link-establishment MLE draft]<br /> ** [https://openthread.io/guides/thread-primer/network-discovery Thread primer]<br /> ** [https://www.threadgroup.org/ThreadSpec Thread specifications]<br /> <br /> Possible tasks to fulfill the patch requirement:<br /> * TBD, contact the mentors if interested.<br /> <br /> === Lr-WPAN (IEEE 802.15.4) preamble detection support ===<br /> <br /> Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], [mailto:alramonet@is.tokushima-u.ac.jp Alberto Gallegos Ramonet].<br /> <br /> 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<br /> 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<br /> itself has many added benefits.<br /> <br /> 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.<br /> <br /> As usual, reduction of code duplicity and a flexible scalable design is desired (e.g. Allow the inclusion of different preambles in the future).<br /> <br /> * ''Required Experience:'' Basic understanding of IEEE 802.15.4, C++ programming.<br /> * ''Bonus Experience:'' PHY process familiarity, Familiarity with ns-3's Lr-WPAN<br /> * ''Interests:'' Lr-WPAN, MAC and PHY designs<br /> * ''Difficulty:'' Medium.<br /> * ''Recommended reading:''<br /> ** [https://ieeexplore.ieee.org/document/1700009 IEEE 802.15.4-2006]<br /> ** [https://ieeexplore.ieee.org/document/7460875 IEEE 802.15.4-2015]<br /> ** [https://www.nsnam.org/docs/models/html/lr-wpan.html ns-3 lr-wpan module]<br /> <br /> Possible tasks to fulfill the patch requirement:<br /> * TBD, contact the mentors if interested.<br /> <br /> === 5G NR module integration with ns-3-ai ===<br /> <br /> 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]<br /> <br /> 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.<br /> <br /> 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.<br /> For more specific guidelines, please view this [https://docs.google.com/document/d/1cQLIF1cdft1yj3vyWrjrxN2xDJMx8PuWaa9NP_nKf64/edit?usp=sharing Google document].<br /> <br /> * Required Experience: C++ programming, understanding of 5G NR, LTE, and wireless networks<br /> * Interests: 5G NR simulations<br /> * Difficulty: Medium.<br /> * 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.<br /> <br /> === Linux-like CAKE queue discipline for ns-3 ===<br /> <br /> Mentors: [mailto:tahiliani.nitk@gmail.com Mohit P. Tahiliani]<br /> <br /> 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.<br /> <br /> * ''Required Experience:'' Familiarity with queue disciplines, TCP and C++ programming.<br /> * ''Bonus Experience:'' Familiarity with CAKE framework in Linux 4.19<br /> * ''Interests:'' Active Queue Management, Packet scheduling and TCP.<br /> * ''Difficulty:'' Medium to Hard<br /> * ''Recommended reading:''<br /> ** [https://arxiv.org/pdf/1804.07617.pdf Piece of CAKE: A Comprehensive Queue Management Solution for Home Gateways]<br /> ** [https://lwn.net/Articles/758353/ Let them run CAKE]<br /> ** [https://www.nsnam.org/docs/models/html/queue-discs.html Queue disciplines in ns-3]<br /> <br /> === Switched Ethernet ===<br /> <br /> Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], TBD.<br /> <br /> 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.<br /> <br /> 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.<br /> <br /> 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.<br /> <br /> 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.<br /> <br /> 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.<br /> <br /> * ''Required Experience:'' Fundamentals of Ethernet sitched networking, C++ programming.<br /> * ''Interests:'' Ethernet networks and switched data networks.<br /> * ''Difficulty:'' Medium.<br /> * ''Recommended reading:''<br /> ** [https://www2.nsnam.org/bugzilla/show_bug.cgi?id=2602 Basic implementation (very old)]<br /> ** [https://gitlab.com/nsnam/ns-3-dev/-/merge_requests/431 Full-duplex CSMA, somehow related]<br /> ** [https://tcipg.org/sites/default/files/papers/2010_Jin_Nicol_Caesar.pdf Paper on gigabit Ethernet switch models for simulation]<br /> <br /> Possible tasks to fulfill the patch requirement:<br /> * TBD, contact the mentors if interested.</div>

Tommaso https://www.nsnam.org/mediawiki/index.php?title=GSOC2026Projects&diff=13721 2026-01-26T19:43:47Z

<p>Tommaso: /* Internet models enhancements */</p> <hr /> <div>{{TOC}}<br /> <br /> This page contains 2026 Google Summer of Code project ideas for ns-3.<br /> <br /> * [https://developers.google.com/open-source/gsoc/faq GSoC Frequently Asked Questions]<br /> * [[GSOC2026ContributorGuide | ns-3's 2026 GSoC Contributor guide]]<br /> * [https://developers.google.com/open-source/gsoc/resources/guide GSoC contributor/student guide (not ns-3 specific)]<br /> * [[GSOC2025ApplicationTemplate | 2026 GSoC Contributor application template]]<br /> * [[GSOCMentorGuide | ns-3's GSoC Mentor guide]]<br /> * [https://archive.flossmanuals.net/gsocmentoring/index.html GSoC Mentor guide (not ns-3 specific)]<br /> * [[GSOCSelectionProcess | GSoC Contributor Selection Process]]<br /> * ''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/<br /> <br /> === About the ns-3 project ===<br /> <br /> ns-3 is a discrete-event network simulator, with a particular emphasis on network research and education.<br /> <br /> 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.<br /> <br /> 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.<br /> <br /> === Org admins ===<br /> <br /> 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].<br /> <br /> === Mentors ===<br /> <br /> 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.<br /> <br /> The current list of prospective mentors can be found among the ideas listed below.<br /> <br /> === How to apply ===<br /> <br /> For students or contributors interested in applying to ns-3 for GSoC, please go through the following list to get started:<br /> * Read the official [https://developers.google.com/open-source/gsoc/resources/guide GSoC contributor guide].<br /> * Read [[GSOC2026ContributorGuide |ns-3's 2026 GSoC contributor guide]]<br /> * Look through our [[#Project Ideas]] below to see if you find a project that interests you.<br /> * Review the [https://www.nsnam.org/documentation/development-tree/ tutorial and contributing guide] thoroughly, if you have not already done so.<br /> * 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.<br /> * Next, proceed to get in touch with the developers on the mailing list or Zulip chat room and refine your proposal.<br /> * 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.<br /> <br /> 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.<br /> <br /> &lt;blockquote&gt;<br /> Each project idea within a particular priority has been tagged with the following properties:<br /> * ''Required Experience:'' Languages, concepts, or packages with which applicants must be familiar.<br /> * ''Bonus Experience:'' Other experience or familiarity which would be greatly helpful to applicants for this project.<br /> * ''Interests:'' Areas of particular relevance to this project, and an indicator of where successful contributors might apply their experiences coming out of this project.<br /> * ''Difficulty:'' easy, medium or difficult<br /> * ''Recommended reading:'' pointers to documentation, papers, specific bugs, etc.<br /> <br /> 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.<br /> &lt;/blockquote&gt;<br /> <br /> === Patch requirement guidelines ===<br /> <br /> 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.<br /> <br /> === Mentors: how to participate ===<br /> <br /> 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:<br /> <br /> * 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.<br /> * 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.<br /> * 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.<br /> <br /> == Project Ideas ==<br /> <br /> '''Note to contributors:''' These ideas are not listed in any priority order.<br /> 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.<br /> <br /> === Internet models enhancements ===<br /> <br /> * [[#AODVv2 Protocol enhancements]] (medium size project, 175h)<br /> * [[#Linux-like CAKE queue discipline for ns-3]] (large size project, 350h)<br /> * [[#Switched Ethernet]] (large size project, 350h)<br /> <br /> === IoT models enhancements ===<br /> <br /> * [[#6LoWPAN mesh-under routing enhancements]] (medium size project, 175h)<br /> * [[#6LoWPAN neighbor discovery protocol]] (medium size project, 175h)<br /> * [[#Mesh Link Establishment (MLE) protocol ]] (large size project, 350h)<br /> * [[#Lr-WPAN (IEEE 802.15.4) preamble detection support]] (large size project, 350h)<br /> <br /> === 5G NR models enhancements ===<br /> <br /> 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.<br /> <br /> * [[#NTN example for 5G NR]] (small size project, 90h)<br /> * [[#Enabling 5G NR examples visualization]] (medium size project, 175h)<br /> * [[#Improving 5G NR module usability through helpers]] (medium size project, 175h)<br /> * [[#5G NR module integration with ns-3-ai]] (large size project, 250h)<br /> <br /> == Small sized projects (90 hours) ==<br /> <br /> <br /> === NTN example for 5G NR ===<br /> <br /> 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]<br /> <br /> 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).<br /> <br /> 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.<br /> <br /> * Required Experience: C++ programming, understanding of 5G NR, LTE, and wireless networks<br /> * Interests: 5G NR simulations<br /> * Difficulty: Medium.<br /> * 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.<br /> <br /> == Medium sized projects (175 hours) ==<br /> <br /> === 6LoWPAN mesh-under routing enhancements ===<br /> <br /> Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], [TBD].<br /> <br /> 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.<br /> 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.<br /> <br /> The candidate should outline what parts of code are going to be affected, and how they can be enhanced thanks to RFC 7731.<br /> <br /> * ''Required Experience:'' Fundamentals of IPv6 addressing, C++ programming.<br /> * ''Bonus Experience:'' Familiarity with mesh routing and 6LoWPAN ns-3<br /> * ''Interests:'' IPv6 mesh routing<br /> * ''Difficulty:'' Easy.<br /> * ''Recommended reading:''<br /> ** [https://www.nsnam.org/docs/models/html/sixlowpan.html#mesh-under-routing Mesh-under in ns-3 6LoWPAN]<br /> ** [https://datatracker.ietf.org/doc/html/rfc7731 RFC 7731]<br /> <br /> Possible tasks to fulfill the patch requirement:<br /> * 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 &quot;next hop&quot;. The behavior of the actual protocol should be unchanged.<br /> <br /> === 6LoWPAN neighbor discovery protocol ===<br /> <br /> Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], [mailto:adnan.rashid@poliba.it Adnan Rashid].<br /> <br /> 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.<br /> <br /> 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).<br /> <br /> 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.<br /> <br /> * ''Required Experience:'' Fundamentals of IPv6 addressing, C++ programming.<br /> * ''Bonus Experience:'' Familiarity with 6LoWPAN and 6LoWPAN-ND<br /> * ''Interests:'' IPv6 and IoT networks<br /> * ''Difficulty:'' Easy.<br /> * ''Recommended reading:''<br /> ** [https://datatracker.ietf.org/doc/html/rfc8505 RFC 8505]<br /> ** [https://datatracker.ietf.org/doc/html/rfc6775 RFC 6775]<br /> ** [https://datatracker.ietf.org/doc/html/rfc4944 RFC 4944]<br /> <br /> Possible tasks to fulfil the patch requirement:<br /> * Patch the actual 6LoWPAN-ND to remove the limitation about concurrent address registrations.<br /> <br /> === Improving 5G NR module usability through helpers ===<br /> <br /> 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]<br /> <br /> 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.<br /> <br /> 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.<br /> <br /> * Required Experience: C++ programming, understanding of 5G NR, LTE, and wireless networks<br /> * Interests: 5G NR simulations<br /> * Difficulty: Medium.<br /> * 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.<br /> <br /> === Enabling 5G NR examples visualization ===<br /> <br /> 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]<br /> <br /> 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.<br /> <br /> 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.<br /> 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].<br /> <br /> * Required Experience: C++ and Python programming, understanding of 5G NR, LTE, and wireless networks<br /> * Interests: 5G NR simulations<br /> * Difficulty: Medium.<br /> * 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.<br /> <br /> === AODVv2 Protocol enhancements ===<br /> <br /> Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], [TBD].<br /> <br /> 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.<br /> <br /> In particular the project should address the following points:<br /> # Alignment with the latest drafts,<br /> # Model finalization and testing (in particular for the IPv6 part),<br /> # AODVv2 examples and documentation,<br /> # &quot;External&quot; network routing support.<br /> <br /> Collaboration with the draft authors is also highly suggested.<br /> <br /> * ''Required Experience:'' Fundamentals of IPv6 addressing, C++ programming.<br /> * ''Bonus Experience:'' Familiarity with AODV implementations in ns-3 and AODVv2<br /> * ''Interests:'' Ad hoc routing<br /> * ''Difficulty:'' Medium.<br /> * ''Recommended reading:''<br /> ** [https://www.nsnam.org/docs/models/html/ipv6.html IPv6 model in ns-3]<br /> ** [https://www.nsnam.org/docs/models/html/aodv.html AODV model in ns-3]<br /> ** [https://gitlab.com/tod97/ns-3-dev/-/tree/aodvv2-icns3-25 AODVv2 model presented at ICNS3-2025] <br /> ** [https://datatracker.ietf.org/doc/draft-perkins-manet-aodvv2/05/ Ad Hoc On-demand Distance Vector Version 2 (AODVv2) Routing]<br /> <br /> Possible tasks to fulfill the patch requirement:<br /> * [https://gitlab.com/nsnam/ns-3-dev/-/issues/368 Issue #368] - aodv: aodv parameters can be set to &quot;impossible&quot; values<br /> <br /> == Large projects (350 hours) ==<br /> <br /> === IPv6 global routing ===<br /> <br /> Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], [mailto:manoj24.rana@gmail.com Manoj K. Rana].<br /> <br /> 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).<br /> For IPv4, ns-3 provides two alternatives: GlobalRouting, and NixRouting, which just &quot;do the trick&quot; - they simply fill the routing tables in intermediate nodes, GlobalRouting using an approach similar to OSPF, NixRouting by leveraging the &quot;abstract&quot; knowledge of the network.<br /> Neither actually use any message between the nodes, so they also reduce the network overhead - something that is useful in many cases.<br /> <br /> 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.).<br /> <br /> 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.<br /> <br /> * ''Required Experience:'' Fundamentals of IPv6 addressing, C++ programming.<br /> * ''Bonus Experience:'' Familiarity with GlobalRouting implementations in ns-3<br /> * ''Interests:'' IPv6 routing<br /> * ''Difficulty:'' Medium.<br /> * ''Recommended reading:''<br /> ** [https://www.nsnam.org/docs/models/html/ipv6.html IPv6 model in ns-3]<br /> ** [https://www.nsnam.org/docs/models/html/routing-overview.html#global-centralized-routing GlobalRouting model in ns-3]<br /> <br /> Possible tasks to fulfill the patch requirement:<br /> * 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.<br /> <br /> === Mesh Link Establishment (MLE) protocol ===<br /> <br /> Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], TBD.<br /> <br /> 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.<br /> However, MLE is being used in Thread, and it can be useful to implement it.<br /> <br /> 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.<br /> <br /> * ''Required Experience:'' Fundamentals of IPv4 and IPv6 sockets, C++ programming.<br /> * ''Interests:'' Sockets and API interface implementation.<br /> * ''Difficulty:'' Hard.<br /> * ''Recommended reading:''<br /> ** [https://datatracker.ietf.org/doc/html/draft-ietf-6lo-mesh-link-establishment MLE draft]<br /> ** [https://openthread.io/guides/thread-primer/network-discovery Thread primer]<br /> ** [https://www.threadgroup.org/ThreadSpec Thread specifications]<br /> <br /> Possible tasks to fulfill the patch requirement:<br /> * TBD, contact the mentors if interested.<br /> <br /> === Lr-WPAN (IEEE 802.15.4) preamble detection support ===<br /> <br /> Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], [mailto:alramonet@is.tokushima-u.ac.jp Alberto Gallegos Ramonet].<br /> <br /> 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<br /> 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<br /> itself has many added benefits.<br /> <br /> 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.<br /> <br /> As usual, reduction of code duplicity and a flexible scalable design is desired (e.g. Allow the inclusion of different preambles in the future).<br /> <br /> * ''Required Experience:'' Basic understanding of IEEE 802.15.4, C++ programming.<br /> * ''Bonus Experience:'' PHY process familiarity, Familiarity with ns-3's Lr-WPAN<br /> * ''Interests:'' Lr-WPAN, MAC and PHY designs<br /> * ''Difficulty:'' Medium.<br /> * ''Recommended reading:''<br /> ** [https://ieeexplore.ieee.org/document/1700009 IEEE 802.15.4-2006]<br /> ** [https://ieeexplore.ieee.org/document/7460875 IEEE 802.15.4-2015]<br /> ** [https://www.nsnam.org/docs/models/html/lr-wpan.html ns-3 lr-wpan module]<br /> <br /> Possible tasks to fulfill the patch requirement:<br /> * TBD, contact the mentors if interested.<br /> <br /> === 5G NR module integration with ns-3-ai ===<br /> <br /> 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]<br /> <br /> 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.<br /> <br /> 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.<br /> For more specific guidelines, please view this [https://docs.google.com/document/d/1cQLIF1cdft1yj3vyWrjrxN2xDJMx8PuWaa9NP_nKf64/edit?usp=sharing Google document].<br /> <br /> * Required Experience: C++ programming, understanding of 5G NR, LTE, and wireless networks<br /> * Interests: 5G NR simulations<br /> * Difficulty: Medium.<br /> * 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.<br /> <br /> === Linux-like CAKE queue discipline for ns-3 ===<br /> <br /> Mentors: [mailto:tahiliani.nitk@gmail.com Mohit P. Tahiliani]<br /> <br /> 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.<br /> <br /> * ''Required Experience:'' Familiarity with queue disciplines, TCP and C++ programming.<br /> * ''Bonus Experience:'' Familiarity with CAKE framework in Linux 4.19<br /> * ''Interests:'' Active Queue Management, Packet scheduling and TCP.<br /> * ''Difficulty:'' Medium to Hard<br /> * ''Recommended reading:''<br /> ** [https://arxiv.org/pdf/1804.07617.pdf Piece of CAKE: A Comprehensive Queue Management Solution for Home Gateways]<br /> ** [https://lwn.net/Articles/758353/ Let them run CAKE]<br /> ** [https://www.nsnam.org/docs/models/html/queue-discs.html Queue disciplines in ns-3]<br /> <br /> === Switched Ethernet ===<br /> <br /> Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], TBD.<br /> <br /> 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.<br /> <br /> 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.<br /> <br /> 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.<br /> <br /> 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.<br /> <br /> 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.<br /> <br /> * ''Required Experience:'' Fundamentals of Ethernet sitched networking, C++ programming.<br /> * ''Interests:'' Ethernet networks and switched data networks.<br /> * ''Difficulty:'' Medium.<br /> * ''Recommended reading:''<br /> ** [https://www2.nsnam.org/bugzilla/show_bug.cgi?id=2602 Basic implementation (very old)]<br /> ** [https://gitlab.com/nsnam/ns-3-dev/-/merge_requests/431 Full-duplex CSMA, somehow related]<br /> ** [https://tcipg.org/sites/default/files/papers/2010_Jin_Nicol_Caesar.pdf Paper on gigabit Ethernet switch models for simulation]<br /> <br /> Possible tasks to fulfill the patch requirement:<br /> * TBD, contact the mentors if interested.</div>

Tommaso https://www.nsnam.org/mediawiki/index.php?title=GSOC2026Projects&diff=13720 2026-01-26T19:43:22Z

<p>Tommaso: /* ICMP socket and generate/handle ICMP messages (host/net unreachable) */</p> <hr /> <div>{{TOC}}<br /> <br /> This page contains 2026 Google Summer of Code project ideas for ns-3.<br /> <br /> * [https://developers.google.com/open-source/gsoc/faq GSoC Frequently Asked Questions]<br /> * [[GSOC2026ContributorGuide | ns-3's 2026 GSoC Contributor guide]]<br /> * [https://developers.google.com/open-source/gsoc/resources/guide GSoC contributor/student guide (not ns-3 specific)]<br /> * [[GSOC2025ApplicationTemplate | 2026 GSoC Contributor application template]]<br /> * [[GSOCMentorGuide | ns-3's GSoC Mentor guide]]<br /> * [https://archive.flossmanuals.net/gsocmentoring/index.html GSoC Mentor guide (not ns-3 specific)]<br /> * [[GSOCSelectionProcess | GSoC Contributor Selection Process]]<br /> * ''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/<br /> <br /> === About the ns-3 project ===<br /> <br /> ns-3 is a discrete-event network simulator, with a particular emphasis on network research and education.<br /> <br /> 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.<br /> <br /> 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.<br /> <br /> === Org admins ===<br /> <br /> 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].<br /> <br /> === Mentors ===<br /> <br /> 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.<br /> <br /> The current list of prospective mentors can be found among the ideas listed below.<br /> <br /> === How to apply ===<br /> <br /> For students or contributors interested in applying to ns-3 for GSoC, please go through the following list to get started:<br /> * Read the official [https://developers.google.com/open-source/gsoc/resources/guide GSoC contributor guide].<br /> * Read [[GSOC2026ContributorGuide |ns-3's 2026 GSoC contributor guide]]<br /> * Look through our [[#Project Ideas]] below to see if you find a project that interests you.<br /> * Review the [https://www.nsnam.org/documentation/development-tree/ tutorial and contributing guide] thoroughly, if you have not already done so.<br /> * 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.<br /> * Next, proceed to get in touch with the developers on the mailing list or Zulip chat room and refine your proposal.<br /> * 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.<br /> <br /> 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.<br /> <br /> &lt;blockquote&gt;<br /> Each project idea within a particular priority has been tagged with the following properties:<br /> * ''Required Experience:'' Languages, concepts, or packages with which applicants must be familiar.<br /> * ''Bonus Experience:'' Other experience or familiarity which would be greatly helpful to applicants for this project.<br /> * ''Interests:'' Areas of particular relevance to this project, and an indicator of where successful contributors might apply their experiences coming out of this project.<br /> * ''Difficulty:'' easy, medium or difficult<br /> * ''Recommended reading:'' pointers to documentation, papers, specific bugs, etc.<br /> <br /> 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.<br /> &lt;/blockquote&gt;<br /> <br /> === Patch requirement guidelines ===<br /> <br /> 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.<br /> <br /> === Mentors: how to participate ===<br /> <br /> 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:<br /> <br /> * 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.<br /> * 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.<br /> * 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.<br /> <br /> == Project Ideas ==<br /> <br /> '''Note to contributors:''' These ideas are not listed in any priority order.<br /> 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.<br /> <br /> === Internet models enhancements ===<br /> <br /> * [[#ICMP socket and generate/handle ICMP messages (host/net unreachable)]] (medium size project, 175h)<br /> * [[#AODVv2 Protocol enhancements]] (medium size project, 175h)<br /> * [[#IPv6 global routing]] (large size project, 350h)<br /> * [[#Linux-like CAKE queue discipline for ns-3]] (large size project, 350h)<br /> * [[#Switched Ethernet]] (large size project, 350h)<br /> <br /> === IoT models enhancements ===<br /> <br /> * [[#6LoWPAN mesh-under routing enhancements]] (medium size project, 175h)<br /> * [[#6LoWPAN neighbor discovery protocol]] (medium size project, 175h)<br /> * [[#Mesh Link Establishment (MLE) protocol ]] (large size project, 350h)<br /> * [[#Lr-WPAN (IEEE 802.15.4) preamble detection support]] (large size project, 350h)<br /> <br /> === 5G NR models enhancements ===<br /> <br /> 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.<br /> <br /> * [[#NTN example for 5G NR]] (small size project, 90h)<br /> * [[#Enabling 5G NR examples visualization]] (medium size project, 175h)<br /> * [[#Improving 5G NR module usability through helpers]] (medium size project, 175h)<br /> * [[#5G NR module integration with ns-3-ai]] (large size project, 250h)<br /> <br /> == Small sized projects (90 hours) ==<br /> <br /> <br /> === NTN example for 5G NR ===<br /> <br /> 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]<br /> <br /> 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).<br /> <br /> 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.<br /> <br /> * Required Experience: C++ programming, understanding of 5G NR, LTE, and wireless networks<br /> * Interests: 5G NR simulations<br /> * Difficulty: Medium.<br /> * 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.<br /> <br /> == Medium sized projects (175 hours) ==<br /> <br /> === 6LoWPAN mesh-under routing enhancements ===<br /> <br /> Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], [TBD].<br /> <br /> 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.<br /> 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.<br /> <br /> The candidate should outline what parts of code are going to be affected, and how they can be enhanced thanks to RFC 7731.<br /> <br /> * ''Required Experience:'' Fundamentals of IPv6 addressing, C++ programming.<br /> * ''Bonus Experience:'' Familiarity with mesh routing and 6LoWPAN ns-3<br /> * ''Interests:'' IPv6 mesh routing<br /> * ''Difficulty:'' Easy.<br /> * ''Recommended reading:''<br /> ** [https://www.nsnam.org/docs/models/html/sixlowpan.html#mesh-under-routing Mesh-under in ns-3 6LoWPAN]<br /> ** [https://datatracker.ietf.org/doc/html/rfc7731 RFC 7731]<br /> <br /> Possible tasks to fulfill the patch requirement:<br /> * 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 &quot;next hop&quot;. The behavior of the actual protocol should be unchanged.<br /> <br /> === 6LoWPAN neighbor discovery protocol ===<br /> <br /> Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], [mailto:adnan.rashid@poliba.it Adnan Rashid].<br /> <br /> 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.<br /> <br /> 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).<br /> <br /> 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.<br /> <br /> * ''Required Experience:'' Fundamentals of IPv6 addressing, C++ programming.<br /> * ''Bonus Experience:'' Familiarity with 6LoWPAN and 6LoWPAN-ND<br /> * ''Interests:'' IPv6 and IoT networks<br /> * ''Difficulty:'' Easy.<br /> * ''Recommended reading:''<br /> ** [https://datatracker.ietf.org/doc/html/rfc8505 RFC 8505]<br /> ** [https://datatracker.ietf.org/doc/html/rfc6775 RFC 6775]<br /> ** [https://datatracker.ietf.org/doc/html/rfc4944 RFC 4944]<br /> <br /> Possible tasks to fulfil the patch requirement:<br /> * Patch the actual 6LoWPAN-ND to remove the limitation about concurrent address registrations.<br /> <br /> === Improving 5G NR module usability through helpers ===<br /> <br /> 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]<br /> <br /> 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.<br /> <br /> 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.<br /> <br /> * Required Experience: C++ programming, understanding of 5G NR, LTE, and wireless networks<br /> * Interests: 5G NR simulations<br /> * Difficulty: Medium.<br /> * 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.<br /> <br /> === Enabling 5G NR examples visualization ===<br /> <br /> 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]<br /> <br /> 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.<br /> <br /> 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.<br /> 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].<br /> <br /> * Required Experience: C++ and Python programming, understanding of 5G NR, LTE, and wireless networks<br /> * Interests: 5G NR simulations<br /> * Difficulty: Medium.<br /> * 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.<br /> <br /> === AODVv2 Protocol enhancements ===<br /> <br /> Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], [TBD].<br /> <br /> 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.<br /> <br /> In particular the project should address the following points:<br /> # Alignment with the latest drafts,<br /> # Model finalization and testing (in particular for the IPv6 part),<br /> # AODVv2 examples and documentation,<br /> # &quot;External&quot; network routing support.<br /> <br /> Collaboration with the draft authors is also highly suggested.<br /> <br /> * ''Required Experience:'' Fundamentals of IPv6 addressing, C++ programming.<br /> * ''Bonus Experience:'' Familiarity with AODV implementations in ns-3 and AODVv2<br /> * ''Interests:'' Ad hoc routing<br /> * ''Difficulty:'' Medium.<br /> * ''Recommended reading:''<br /> ** [https://www.nsnam.org/docs/models/html/ipv6.html IPv6 model in ns-3]<br /> ** [https://www.nsnam.org/docs/models/html/aodv.html AODV model in ns-3]<br /> ** [https://gitlab.com/tod97/ns-3-dev/-/tree/aodvv2-icns3-25 AODVv2 model presented at ICNS3-2025] <br /> ** [https://datatracker.ietf.org/doc/draft-perkins-manet-aodvv2/05/ Ad Hoc On-demand Distance Vector Version 2 (AODVv2) Routing]<br /> <br /> Possible tasks to fulfill the patch requirement:<br /> * [https://gitlab.com/nsnam/ns-3-dev/-/issues/368 Issue #368] - aodv: aodv parameters can be set to &quot;impossible&quot; values<br /> <br /> == Large projects (350 hours) ==<br /> <br /> === IPv6 global routing ===<br /> <br /> Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], [mailto:manoj24.rana@gmail.com Manoj K. Rana].<br /> <br /> 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).<br /> For IPv4, ns-3 provides two alternatives: GlobalRouting, and NixRouting, which just &quot;do the trick&quot; - they simply fill the routing tables in intermediate nodes, GlobalRouting using an approach similar to OSPF, NixRouting by leveraging the &quot;abstract&quot; knowledge of the network.<br /> Neither actually use any message between the nodes, so they also reduce the network overhead - something that is useful in many cases.<br /> <br /> 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.).<br /> <br /> 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.<br /> <br /> * ''Required Experience:'' Fundamentals of IPv6 addressing, C++ programming.<br /> * ''Bonus Experience:'' Familiarity with GlobalRouting implementations in ns-3<br /> * ''Interests:'' IPv6 routing<br /> * ''Difficulty:'' Medium.<br /> * ''Recommended reading:''<br /> ** [https://www.nsnam.org/docs/models/html/ipv6.html IPv6 model in ns-3]<br /> ** [https://www.nsnam.org/docs/models/html/routing-overview.html#global-centralized-routing GlobalRouting model in ns-3]<br /> <br /> Possible tasks to fulfill the patch requirement:<br /> * 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.<br /> <br /> === Mesh Link Establishment (MLE) protocol ===<br /> <br /> Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], TBD.<br /> <br /> 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.<br /> However, MLE is being used in Thread, and it can be useful to implement it.<br /> <br /> 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.<br /> <br /> * ''Required Experience:'' Fundamentals of IPv4 and IPv6 sockets, C++ programming.<br /> * ''Interests:'' Sockets and API interface implementation.<br /> * ''Difficulty:'' Hard.<br /> * ''Recommended reading:''<br /> ** [https://datatracker.ietf.org/doc/html/draft-ietf-6lo-mesh-link-establishment MLE draft]<br /> ** [https://openthread.io/guides/thread-primer/network-discovery Thread primer]<br /> ** [https://www.threadgroup.org/ThreadSpec Thread specifications]<br /> <br /> Possible tasks to fulfill the patch requirement:<br /> * TBD, contact the mentors if interested.<br /> <br /> === Lr-WPAN (IEEE 802.15.4) preamble detection support ===<br /> <br /> Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], [mailto:alramonet@is.tokushima-u.ac.jp Alberto Gallegos Ramonet].<br /> <br /> 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<br /> 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<br /> itself has many added benefits.<br /> <br /> 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.<br /> <br /> As usual, reduction of code duplicity and a flexible scalable design is desired (e.g. Allow the inclusion of different preambles in the future).<br /> <br /> * ''Required Experience:'' Basic understanding of IEEE 802.15.4, C++ programming.<br /> * ''Bonus Experience:'' PHY process familiarity, Familiarity with ns-3's Lr-WPAN<br /> * ''Interests:'' Lr-WPAN, MAC and PHY designs<br /> * ''Difficulty:'' Medium.<br /> * ''Recommended reading:''<br /> ** [https://ieeexplore.ieee.org/document/1700009 IEEE 802.15.4-2006]<br /> ** [https://ieeexplore.ieee.org/document/7460875 IEEE 802.15.4-2015]<br /> ** [https://www.nsnam.org/docs/models/html/lr-wpan.html ns-3 lr-wpan module]<br /> <br /> Possible tasks to fulfill the patch requirement:<br /> * TBD, contact the mentors if interested.<br /> <br /> === 5G NR module integration with ns-3-ai ===<br /> <br /> 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]<br /> <br /> 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.<br /> <br /> 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.<br /> For more specific guidelines, please view this [https://docs.google.com/document/d/1cQLIF1cdft1yj3vyWrjrxN2xDJMx8PuWaa9NP_nKf64/edit?usp=sharing Google document].<br /> <br /> * Required Experience: C++ programming, understanding of 5G NR, LTE, and wireless networks<br /> * Interests: 5G NR simulations<br /> * Difficulty: Medium.<br /> * 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.<br /> <br /> === Linux-like CAKE queue discipline for ns-3 ===<br /> <br /> Mentors: [mailto:tahiliani.nitk@gmail.com Mohit P. Tahiliani]<br /> <br /> 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.<br /> <br /> * ''Required Experience:'' Familiarity with queue disciplines, TCP and C++ programming.<br /> * ''Bonus Experience:'' Familiarity with CAKE framework in Linux 4.19<br /> * ''Interests:'' Active Queue Management, Packet scheduling and TCP.<br /> * ''Difficulty:'' Medium to Hard<br /> * ''Recommended reading:''<br /> ** [https://arxiv.org/pdf/1804.07617.pdf Piece of CAKE: A Comprehensive Queue Management Solution for Home Gateways]<br /> ** [https://lwn.net/Articles/758353/ Let them run CAKE]<br /> ** [https://www.nsnam.org/docs/models/html/queue-discs.html Queue disciplines in ns-3]<br /> <br /> === Switched Ethernet ===<br /> <br /> Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], TBD.<br /> <br /> 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.<br /> <br /> 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.<br /> <br /> 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.<br /> <br /> 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.<br /> <br /> 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.<br /> <br /> * ''Required Experience:'' Fundamentals of Ethernet sitched networking, C++ programming.<br /> * ''Interests:'' Ethernet networks and switched data networks.<br /> * ''Difficulty:'' Medium.<br /> * ''Recommended reading:''<br /> ** [https://www2.nsnam.org/bugzilla/show_bug.cgi?id=2602 Basic implementation (very old)]<br /> ** [https://gitlab.com/nsnam/ns-3-dev/-/merge_requests/431 Full-duplex CSMA, somehow related]<br /> ** [https://tcipg.org/sites/default/files/papers/2010_Jin_Nicol_Caesar.pdf Paper on gigabit Ethernet switch models for simulation]<br /> <br /> Possible tasks to fulfill the patch requirement:<br /> * TBD, contact the mentors if interested.</div>

Tommaso https://www.nsnam.org/mediawiki/index.php?title=GSOC2026Projects&diff=13719 2026-01-26T19:42:57Z

<p>Tommaso: /* AODVv2 Protocol finalization and enhancements */</p> <hr /> <div>{{TOC}}<br /> <br /> This page contains 2026 Google Summer of Code project ideas for ns-3.<br /> <br /> * [https://developers.google.com/open-source/gsoc/faq GSoC Frequently Asked Questions]<br /> * [[GSOC2026ContributorGuide | ns-3's 2026 GSoC Contributor guide]]<br /> * [https://developers.google.com/open-source/gsoc/resources/guide GSoC contributor/student guide (not ns-3 specific)]<br /> * [[GSOC2025ApplicationTemplate | 2026 GSoC Contributor application template]]<br /> * [[GSOCMentorGuide | ns-3's GSoC Mentor guide]]<br /> * [https://archive.flossmanuals.net/gsocmentoring/index.html GSoC Mentor guide (not ns-3 specific)]<br /> * [[GSOCSelectionProcess | GSoC Contributor Selection Process]]<br /> * ''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/<br /> <br /> === About the ns-3 project ===<br /> <br /> ns-3 is a discrete-event network simulator, with a particular emphasis on network research and education.<br /> <br /> 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.<br /> <br /> 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.<br /> <br /> === Org admins ===<br /> <br /> 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].<br /> <br /> === Mentors ===<br /> <br /> 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.<br /> <br /> The current list of prospective mentors can be found among the ideas listed below.<br /> <br /> === How to apply ===<br /> <br /> For students or contributors interested in applying to ns-3 for GSoC, please go through the following list to get started:<br /> * Read the official [https://developers.google.com/open-source/gsoc/resources/guide GSoC contributor guide].<br /> * Read [[GSOC2026ContributorGuide |ns-3's 2026 GSoC contributor guide]]<br /> * Look through our [[#Project Ideas]] below to see if you find a project that interests you.<br /> * Review the [https://www.nsnam.org/documentation/development-tree/ tutorial and contributing guide] thoroughly, if you have not already done so.<br /> * 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.<br /> * Next, proceed to get in touch with the developers on the mailing list or Zulip chat room and refine your proposal.<br /> * 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.<br /> <br /> 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.<br /> <br /> &lt;blockquote&gt;<br /> Each project idea within a particular priority has been tagged with the following properties:<br /> * ''Required Experience:'' Languages, concepts, or packages with which applicants must be familiar.<br /> * ''Bonus Experience:'' Other experience or familiarity which would be greatly helpful to applicants for this project.<br /> * ''Interests:'' Areas of particular relevance to this project, and an indicator of where successful contributors might apply their experiences coming out of this project.<br /> * ''Difficulty:'' easy, medium or difficult<br /> * ''Recommended reading:'' pointers to documentation, papers, specific bugs, etc.<br /> <br /> 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.<br /> &lt;/blockquote&gt;<br /> <br /> === Patch requirement guidelines ===<br /> <br /> 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.<br /> <br /> === Mentors: how to participate ===<br /> <br /> 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:<br /> <br /> * 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.<br /> * 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.<br /> * 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.<br /> <br /> == Project Ideas ==<br /> <br /> '''Note to contributors:''' These ideas are not listed in any priority order.<br /> 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.<br /> <br /> === Internet models enhancements ===<br /> <br /> * [[#ICMP socket and generate/handle ICMP messages (host/net unreachable)]] (medium size project, 175h)<br /> * [[#AODVv2 Protocol enhancements]] (medium size project, 175h)<br /> * [[#IPv6 global routing]] (large size project, 350h)<br /> * [[#Linux-like CAKE queue discipline for ns-3]] (large size project, 350h)<br /> * [[#Switched Ethernet]] (large size project, 350h)<br /> <br /> === IoT models enhancements ===<br /> <br /> * [[#6LoWPAN mesh-under routing enhancements]] (medium size project, 175h)<br /> * [[#6LoWPAN neighbor discovery protocol]] (medium size project, 175h)<br /> * [[#Mesh Link Establishment (MLE) protocol ]] (large size project, 350h)<br /> * [[#Lr-WPAN (IEEE 802.15.4) preamble detection support]] (large size project, 350h)<br /> <br /> === 5G NR models enhancements ===<br /> <br /> 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.<br /> <br /> * [[#NTN example for 5G NR]] (small size project, 90h)<br /> * [[#Enabling 5G NR examples visualization]] (medium size project, 175h)<br /> * [[#Improving 5G NR module usability through helpers]] (medium size project, 175h)<br /> * [[#5G NR module integration with ns-3-ai]] (large size project, 250h)<br /> <br /> == Small sized projects (90 hours) ==<br /> <br /> <br /> === NTN example for 5G NR ===<br /> <br /> 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]<br /> <br /> 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).<br /> <br /> 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.<br /> <br /> * Required Experience: C++ programming, understanding of 5G NR, LTE, and wireless networks<br /> * Interests: 5G NR simulations<br /> * Difficulty: Medium.<br /> * 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.<br /> <br /> == Medium sized projects (175 hours) ==<br /> <br /> === ICMP socket and generate/handle ICMP messages (host/net unreachable) ===<br /> <br /> Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], [mailto:manoj24.rana@gmail.com Manoj K. Rana].<br /> <br /> 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 &quot;RAW&quot; socket.<br /> 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.<br /> <br /> 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.<br /> <br /> The most important point of the implementation should be code duplicate minimization, in order to have the minimize maintenance efforts.<br /> <br /> Once the sockets are in place, beside the &quot;normal&quot; tests, it will be necessary to modify the code that is actually made obsolete by the new sockets, e.g.:<br /> * IPv6 ICMP messages (RA, RS, NA, NS, etc.),<br /> * IPv4 ICMP messages,<br /> * ICMP Echo and ICMPv6 Echo messages.<br /> and to handle properly ICMP error messages like Destination Unreachable in the Ping application.<br /> <br /> * ''Required Experience:'' Fundamentals of IPv4 and IPv6 sockets, C++ programming.<br /> * ''Interests:'' Sockets and API interface implementation.<br /> * ''Difficulty:'' Medium.<br /> * ''Recommended reading:''<br /> ** [https://man7.org/linux/man-pages/man2/socket.2.html Linux socket]<br /> ** [https://courses.cs.vt.edu/cs4254/fall04/slides/raw_1.pdf Raw Sockets and ICMP, Srinidhi Varadarajan]<br /> ** [https://gitlab.com/nsnam/ns-3-dev/-/issues/810 Issue #810]<br /> <br /> Possible tasks to fulfill the patch requirement:<br /> * Submit a patch to fix [https://gitlab.com/nsnam/ns-3-dev/-/issues/809 Issue #809]<br /> <br /> === 6LoWPAN mesh-under routing enhancements ===<br /> <br /> Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], [TBD].<br /> <br /> 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.<br /> 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.<br /> <br /> The candidate should outline what parts of code are going to be affected, and how they can be enhanced thanks to RFC 7731.<br /> <br /> * ''Required Experience:'' Fundamentals of IPv6 addressing, C++ programming.<br /> * ''Bonus Experience:'' Familiarity with mesh routing and 6LoWPAN ns-3<br /> * ''Interests:'' IPv6 mesh routing<br /> * ''Difficulty:'' Easy.<br /> * ''Recommended reading:''<br /> ** [https://www.nsnam.org/docs/models/html/sixlowpan.html#mesh-under-routing Mesh-under in ns-3 6LoWPAN]<br /> ** [https://datatracker.ietf.org/doc/html/rfc7731 RFC 7731]<br /> <br /> Possible tasks to fulfill the patch requirement:<br /> * 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 &quot;next hop&quot;. The behavior of the actual protocol should be unchanged.<br /> <br /> === 6LoWPAN neighbor discovery protocol ===<br /> <br /> Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], [mailto:adnan.rashid@poliba.it Adnan Rashid].<br /> <br /> 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.<br /> <br /> 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).<br /> <br /> 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.<br /> <br /> * ''Required Experience:'' Fundamentals of IPv6 addressing, C++ programming.<br /> * ''Bonus Experience:'' Familiarity with 6LoWPAN and 6LoWPAN-ND<br /> * ''Interests:'' IPv6 and IoT networks<br /> * ''Difficulty:'' Easy.<br /> * ''Recommended reading:''<br /> ** [https://datatracker.ietf.org/doc/html/rfc8505 RFC 8505]<br /> ** [https://datatracker.ietf.org/doc/html/rfc6775 RFC 6775]<br /> ** [https://datatracker.ietf.org/doc/html/rfc4944 RFC 4944]<br /> <br /> Possible tasks to fulfil the patch requirement:<br /> * Patch the actual 6LoWPAN-ND to remove the limitation about concurrent address registrations.<br /> <br /> === Improving 5G NR module usability through helpers ===<br /> <br /> 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]<br /> <br /> 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.<br /> <br /> 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.<br /> <br /> * Required Experience: C++ programming, understanding of 5G NR, LTE, and wireless networks<br /> * Interests: 5G NR simulations<br /> * Difficulty: Medium.<br /> * 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.<br /> <br /> === Enabling 5G NR examples visualization ===<br /> <br /> 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]<br /> <br /> 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.<br /> <br /> 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.<br /> 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].<br /> <br /> * Required Experience: C++ and Python programming, understanding of 5G NR, LTE, and wireless networks<br /> * Interests: 5G NR simulations<br /> * Difficulty: Medium.<br /> * 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.<br /> <br /> === AODVv2 Protocol enhancements ===<br /> <br /> Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], [TBD].<br /> <br /> 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.<br /> <br /> In particular the project should address the following points:<br /> # Alignment with the latest drafts,<br /> # Model finalization and testing (in particular for the IPv6 part),<br /> # AODVv2 examples and documentation,<br /> # &quot;External&quot; network routing support.<br /> <br /> Collaboration with the draft authors is also highly suggested.<br /> <br /> * ''Required Experience:'' Fundamentals of IPv6 addressing, C++ programming.<br /> * ''Bonus Experience:'' Familiarity with AODV implementations in ns-3 and AODVv2<br /> * ''Interests:'' Ad hoc routing<br /> * ''Difficulty:'' Medium.<br /> * ''Recommended reading:''<br /> ** [https://www.nsnam.org/docs/models/html/ipv6.html IPv6 model in ns-3]<br /> ** [https://www.nsnam.org/docs/models/html/aodv.html AODV model in ns-3]<br /> ** [https://gitlab.com/tod97/ns-3-dev/-/tree/aodvv2-icns3-25 AODVv2 model presented at ICNS3-2025] <br /> ** [https://datatracker.ietf.org/doc/draft-perkins-manet-aodvv2/05/ Ad Hoc On-demand Distance Vector Version 2 (AODVv2) Routing]<br /> <br /> Possible tasks to fulfill the patch requirement:<br /> * [https://gitlab.com/nsnam/ns-3-dev/-/issues/368 Issue #368] - aodv: aodv parameters can be set to &quot;impossible&quot; values<br /> <br /> == Large projects (350 hours) ==<br /> <br /> === IPv6 global routing ===<br /> <br /> Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], [mailto:manoj24.rana@gmail.com Manoj K. Rana].<br /> <br /> 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).<br /> For IPv4, ns-3 provides two alternatives: GlobalRouting, and NixRouting, which just &quot;do the trick&quot; - they simply fill the routing tables in intermediate nodes, GlobalRouting using an approach similar to OSPF, NixRouting by leveraging the &quot;abstract&quot; knowledge of the network.<br /> Neither actually use any message between the nodes, so they also reduce the network overhead - something that is useful in many cases.<br /> <br /> 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.).<br /> <br /> 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.<br /> <br /> * ''Required Experience:'' Fundamentals of IPv6 addressing, C++ programming.<br /> * ''Bonus Experience:'' Familiarity with GlobalRouting implementations in ns-3<br /> * ''Interests:'' IPv6 routing<br /> * ''Difficulty:'' Medium.<br /> * ''Recommended reading:''<br /> ** [https://www.nsnam.org/docs/models/html/ipv6.html IPv6 model in ns-3]<br /> ** [https://www.nsnam.org/docs/models/html/routing-overview.html#global-centralized-routing GlobalRouting model in ns-3]<br /> <br /> Possible tasks to fulfill the patch requirement:<br /> * 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.<br /> <br /> === Mesh Link Establishment (MLE) protocol ===<br /> <br /> Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], TBD.<br /> <br /> 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.<br /> However, MLE is being used in Thread, and it can be useful to implement it.<br /> <br /> 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.<br /> <br /> * ''Required Experience:'' Fundamentals of IPv4 and IPv6 sockets, C++ programming.<br /> * ''Interests:'' Sockets and API interface implementation.<br /> * ''Difficulty:'' Hard.<br /> * ''Recommended reading:''<br /> ** [https://datatracker.ietf.org/doc/html/draft-ietf-6lo-mesh-link-establishment MLE draft]<br /> ** [https://openthread.io/guides/thread-primer/network-discovery Thread primer]<br /> ** [https://www.threadgroup.org/ThreadSpec Thread specifications]<br /> <br /> Possible tasks to fulfill the patch requirement:<br /> * TBD, contact the mentors if interested.<br /> <br /> === Lr-WPAN (IEEE 802.15.4) preamble detection support ===<br /> <br /> Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], [mailto:alramonet@is.tokushima-u.ac.jp Alberto Gallegos Ramonet].<br /> <br /> 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<br /> 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<br /> itself has many added benefits.<br /> <br /> 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.<br /> <br /> As usual, reduction of code duplicity and a flexible scalable design is desired (e.g. Allow the inclusion of different preambles in the future).<br /> <br /> * ''Required Experience:'' Basic understanding of IEEE 802.15.4, C++ programming.<br /> * ''Bonus Experience:'' PHY process familiarity, Familiarity with ns-3's Lr-WPAN<br /> * ''Interests:'' Lr-WPAN, MAC and PHY designs<br /> * ''Difficulty:'' Medium.<br /> * ''Recommended reading:''<br /> ** [https://ieeexplore.ieee.org/document/1700009 IEEE 802.15.4-2006]<br /> ** [https://ieeexplore.ieee.org/document/7460875 IEEE 802.15.4-2015]<br /> ** [https://www.nsnam.org/docs/models/html/lr-wpan.html ns-3 lr-wpan module]<br /> <br /> Possible tasks to fulfill the patch requirement:<br /> * TBD, contact the mentors if interested.<br /> <br /> === 5G NR module integration with ns-3-ai ===<br /> <br /> 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]<br /> <br /> 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.<br /> <br /> 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.<br /> For more specific guidelines, please view this [https://docs.google.com/document/d/1cQLIF1cdft1yj3vyWrjrxN2xDJMx8PuWaa9NP_nKf64/edit?usp=sharing Google document].<br /> <br /> * Required Experience: C++ programming, understanding of 5G NR, LTE, and wireless networks<br /> * Interests: 5G NR simulations<br /> * Difficulty: Medium.<br /> * 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.<br /> <br /> === Linux-like CAKE queue discipline for ns-3 ===<br /> <br /> Mentors: [mailto:tahiliani.nitk@gmail.com Mohit P. Tahiliani]<br /> <br /> 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.<br /> <br /> * ''Required Experience:'' Familiarity with queue disciplines, TCP and C++ programming.<br /> * ''Bonus Experience:'' Familiarity with CAKE framework in Linux 4.19<br /> * ''Interests:'' Active Queue Management, Packet scheduling and TCP.<br /> * ''Difficulty:'' Medium to Hard<br /> * ''Recommended reading:''<br /> ** [https://arxiv.org/pdf/1804.07617.pdf Piece of CAKE: A Comprehensive Queue Management Solution for Home Gateways]<br /> ** [https://lwn.net/Articles/758353/ Let them run CAKE]<br /> ** [https://www.nsnam.org/docs/models/html/queue-discs.html Queue disciplines in ns-3]<br /> <br /> === Switched Ethernet ===<br /> <br /> Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], TBD.<br /> <br /> 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.<br /> <br /> 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.<br /> <br /> 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.<br /> <br /> 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.<br /> <br /> 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.<br /> <br /> * ''Required Experience:'' Fundamentals of Ethernet sitched networking, C++ programming.<br /> * ''Interests:'' Ethernet networks and switched data networks.<br /> * ''Difficulty:'' Medium.<br /> * ''Recommended reading:''<br /> ** [https://www2.nsnam.org/bugzilla/show_bug.cgi?id=2602 Basic implementation (very old)]<br /> ** [https://gitlab.com/nsnam/ns-3-dev/-/merge_requests/431 Full-duplex CSMA, somehow related]<br /> ** [https://tcipg.org/sites/default/files/papers/2010_Jin_Nicol_Caesar.pdf Paper on gigabit Ethernet switch models for simulation]<br /> <br /> Possible tasks to fulfill the patch requirement:<br /> * TBD, contact the mentors if interested.</div>

Tommaso https://www.nsnam.org/mediawiki/index.php?title=GSOC2026Projects&diff=13718 2026-01-26T19:39:00Z

<p>Tommaso: /* AODVv2 Protocol enhancements */</p> <hr /> <div>{{TOC}}<br /> <br /> This page contains 2026 Google Summer of Code project ideas for ns-3.<br /> <br /> * [https://developers.google.com/open-source/gsoc/faq GSoC Frequently Asked Questions]<br /> * [[GSOC2026ContributorGuide | ns-3's 2026 GSoC Contributor guide]]<br /> * [https://developers.google.com/open-source/gsoc/resources/guide GSoC contributor/student guide (not ns-3 specific)]<br /> * [[GSOC2025ApplicationTemplate | 2026 GSoC Contributor application template]]<br /> * [[GSOCMentorGuide | ns-3's GSoC Mentor guide]]<br /> * [https://archive.flossmanuals.net/gsocmentoring/index.html GSoC Mentor guide (not ns-3 specific)]<br /> * [[GSOCSelectionProcess | GSoC Contributor Selection Process]]<br /> * ''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/<br /> <br /> === About the ns-3 project ===<br /> <br /> ns-3 is a discrete-event network simulator, with a particular emphasis on network research and education.<br /> <br /> 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.<br /> <br /> 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.<br /> <br /> === Org admins ===<br /> <br /> 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].<br /> <br /> === Mentors ===<br /> <br /> 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.<br /> <br /> The current list of prospective mentors can be found among the ideas listed below.<br /> <br /> === How to apply ===<br /> <br /> For students or contributors interested in applying to ns-3 for GSoC, please go through the following list to get started:<br /> * Read the official [https://developers.google.com/open-source/gsoc/resources/guide GSoC contributor guide].<br /> * Read [[GSOC2026ContributorGuide |ns-3's 2026 GSoC contributor guide]]<br /> * Look through our [[#Project Ideas]] below to see if you find a project that interests you.<br /> * Review the [https://www.nsnam.org/documentation/development-tree/ tutorial and contributing guide] thoroughly, if you have not already done so.<br /> * 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.<br /> * Next, proceed to get in touch with the developers on the mailing list or Zulip chat room and refine your proposal.<br /> * 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.<br /> <br /> 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.<br /> <br /> &lt;blockquote&gt;<br /> Each project idea within a particular priority has been tagged with the following properties:<br /> * ''Required Experience:'' Languages, concepts, or packages with which applicants must be familiar.<br /> * ''Bonus Experience:'' Other experience or familiarity which would be greatly helpful to applicants for this project.<br /> * ''Interests:'' Areas of particular relevance to this project, and an indicator of where successful contributors might apply their experiences coming out of this project.<br /> * ''Difficulty:'' easy, medium or difficult<br /> * ''Recommended reading:'' pointers to documentation, papers, specific bugs, etc.<br /> <br /> 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.<br /> &lt;/blockquote&gt;<br /> <br /> === Patch requirement guidelines ===<br /> <br /> 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.<br /> <br /> === Mentors: how to participate ===<br /> <br /> 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:<br /> <br /> * 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.<br /> * 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.<br /> * 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.<br /> <br /> == Project Ideas ==<br /> <br /> '''Note to contributors:''' These ideas are not listed in any priority order.<br /> 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.<br /> <br /> === Internet models enhancements ===<br /> <br /> * [[#ICMP socket and generate/handle ICMP messages (host/net unreachable)]] (medium size project, 175h)<br /> * [[#AODVv2 Protocol enhancements]] (medium size project, 175h)<br /> * [[#IPv6 global routing]] (large size project, 350h)<br /> * [[#Linux-like CAKE queue discipline for ns-3]] (large size project, 350h)<br /> * [[#Switched Ethernet]] (large size project, 350h)<br /> <br /> === IoT models enhancements ===<br /> <br /> * [[#6LoWPAN mesh-under routing enhancements]] (medium size project, 175h)<br /> * [[#6LoWPAN neighbor discovery protocol]] (medium size project, 175h)<br /> * [[#Mesh Link Establishment (MLE) protocol ]] (large size project, 350h)<br /> * [[#Lr-WPAN (IEEE 802.15.4) preamble detection support]] (large size project, 350h)<br /> <br /> === 5G NR models enhancements ===<br /> <br /> 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.<br /> <br /> * [[#NTN example for 5G NR]] (small size project, 90h)<br /> * [[#Enabling 5G NR examples visualization]] (medium size project, 175h)<br /> * [[#Improving 5G NR module usability through helpers]] (medium size project, 175h)<br /> * [[#5G NR module integration with ns-3-ai]] (large size project, 250h)<br /> <br /> == Small sized projects (90 hours) ==<br /> <br /> <br /> === NTN example for 5G NR ===<br /> <br /> 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]<br /> <br /> 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).<br /> <br /> 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.<br /> <br /> * Required Experience: C++ programming, understanding of 5G NR, LTE, and wireless networks<br /> * Interests: 5G NR simulations<br /> * Difficulty: Medium.<br /> * 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.<br /> <br /> == Medium sized projects (175 hours) ==<br /> <br /> === ICMP socket and generate/handle ICMP messages (host/net unreachable) ===<br /> <br /> Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], [mailto:manoj24.rana@gmail.com Manoj K. Rana].<br /> <br /> 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 &quot;RAW&quot; socket.<br /> 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.<br /> <br /> 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.<br /> <br /> The most important point of the implementation should be code duplicate minimization, in order to have the minimize maintenance efforts.<br /> <br /> Once the sockets are in place, beside the &quot;normal&quot; tests, it will be necessary to modify the code that is actually made obsolete by the new sockets, e.g.:<br /> * IPv6 ICMP messages (RA, RS, NA, NS, etc.),<br /> * IPv4 ICMP messages,<br /> * ICMP Echo and ICMPv6 Echo messages.<br /> and to handle properly ICMP error messages like Destination Unreachable in the Ping application.<br /> <br /> * ''Required Experience:'' Fundamentals of IPv4 and IPv6 sockets, C++ programming.<br /> * ''Interests:'' Sockets and API interface implementation.<br /> * ''Difficulty:'' Medium.<br /> * ''Recommended reading:''<br /> ** [https://man7.org/linux/man-pages/man2/socket.2.html Linux socket]<br /> ** [https://courses.cs.vt.edu/cs4254/fall04/slides/raw_1.pdf Raw Sockets and ICMP, Srinidhi Varadarajan]<br /> ** [https://gitlab.com/nsnam/ns-3-dev/-/issues/810 Issue #810]<br /> <br /> Possible tasks to fulfill the patch requirement:<br /> * Submit a patch to fix [https://gitlab.com/nsnam/ns-3-dev/-/issues/809 Issue #809]<br /> <br /> === 6LoWPAN mesh-under routing enhancements ===<br /> <br /> Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], [TBD].<br /> <br /> 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.<br /> 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.<br /> <br /> The candidate should outline what parts of code are going to be affected, and how they can be enhanced thanks to RFC 7731.<br /> <br /> * ''Required Experience:'' Fundamentals of IPv6 addressing, C++ programming.<br /> * ''Bonus Experience:'' Familiarity with mesh routing and 6LoWPAN ns-3<br /> * ''Interests:'' IPv6 mesh routing<br /> * ''Difficulty:'' Easy.<br /> * ''Recommended reading:''<br /> ** [https://www.nsnam.org/docs/models/html/sixlowpan.html#mesh-under-routing Mesh-under in ns-3 6LoWPAN]<br /> ** [https://datatracker.ietf.org/doc/html/rfc7731 RFC 7731]<br /> <br /> Possible tasks to fulfill the patch requirement:<br /> * 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 &quot;next hop&quot;. The behavior of the actual protocol should be unchanged.<br /> <br /> === 6LoWPAN neighbor discovery protocol ===<br /> <br /> Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], [mailto:adnan.rashid@poliba.it Adnan Rashid].<br /> <br /> 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.<br /> <br /> 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).<br /> <br /> 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.<br /> <br /> * ''Required Experience:'' Fundamentals of IPv6 addressing, C++ programming.<br /> * ''Bonus Experience:'' Familiarity with 6LoWPAN and 6LoWPAN-ND<br /> * ''Interests:'' IPv6 and IoT networks<br /> * ''Difficulty:'' Easy.<br /> * ''Recommended reading:''<br /> ** [https://datatracker.ietf.org/doc/html/rfc8505 RFC 8505]<br /> ** [https://datatracker.ietf.org/doc/html/rfc6775 RFC 6775]<br /> ** [https://datatracker.ietf.org/doc/html/rfc4944 RFC 4944]<br /> <br /> Possible tasks to fulfil the patch requirement:<br /> * Patch the actual 6LoWPAN-ND to remove the limitation about concurrent address registrations.<br /> <br /> === Improving 5G NR module usability through helpers ===<br /> <br /> 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]<br /> <br /> 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.<br /> <br /> 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.<br /> <br /> * Required Experience: C++ programming, understanding of 5G NR, LTE, and wireless networks<br /> * Interests: 5G NR simulations<br /> * Difficulty: Medium.<br /> * 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.<br /> <br /> === Enabling 5G NR examples visualization ===<br /> <br /> 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]<br /> <br /> 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.<br /> <br /> 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.<br /> 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].<br /> <br /> * Required Experience: C++ and Python programming, understanding of 5G NR, LTE, and wireless networks<br /> * Interests: 5G NR simulations<br /> * Difficulty: Medium.<br /> * 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.<br /> <br /> === AODVv2 Protocol enhancements ===<br /> <br /> Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], [TBD].<br /> <br /> 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.<br /> <br /> In particular the project should address the following points: 1) AODVv2 performances, 2) AODV address compression, 3) &quot;external&quot; network routing support, 4) general model validation against the latest draft.<br /> Collaboration with the draft authors is also highly suggested.<br /> <br /> * ''Required Experience:'' Fundamentals of IPv6 addressing, C++ programming.<br /> * ''Bonus Experience:'' Familiarity with AODV implementations in ns-3 and AODVv2<br /> * ''Interests:'' Ad hoc routing<br /> * ''Difficulty:'' Medium.<br /> * ''Recommended reading:''<br /> ** [https://www.nsnam.org/docs/models/html/ipv6.html IPv6 model in ns-3]<br /> ** [https://www.nsnam.org/docs/models/html/aodv.html AODV model in ns-3]<br /> ** [https://gitlab.com/tod97/ns-3-dev/-/tree/aodvv2-icns3-25 AODVv2 model presented at ICNS3-2025] <br /> ** [https://datatracker.ietf.org/doc/draft-perkins-manet-aodvv2/05/ Ad Hoc On-demand Distance Vector Version 2 (AODVv2) Routing]<br /> <br /> Possible tasks to fulfill the patch requirement:<br /> * [https://gitlab.com/nsnam/ns-3-dev/-/issues/368 Issue #368] - aodv: aodv parameters can be set to &quot;impossible&quot; values<br /> <br /> == Large projects (350 hours) ==<br /> <br /> === IPv6 global routing ===<br /> <br /> Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], [mailto:manoj24.rana@gmail.com Manoj K. Rana].<br /> <br /> 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).<br /> For IPv4, ns-3 provides two alternatives: GlobalRouting, and NixRouting, which just &quot;do the trick&quot; - they simply fill the routing tables in intermediate nodes, GlobalRouting using an approach similar to OSPF, NixRouting by leveraging the &quot;abstract&quot; knowledge of the network.<br /> Neither actually use any message between the nodes, so they also reduce the network overhead - something that is useful in many cases.<br /> <br /> 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.).<br /> <br /> 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.<br /> <br /> * ''Required Experience:'' Fundamentals of IPv6 addressing, C++ programming.<br /> * ''Bonus Experience:'' Familiarity with GlobalRouting implementations in ns-3<br /> * ''Interests:'' IPv6 routing<br /> * ''Difficulty:'' Medium.<br /> * ''Recommended reading:''<br /> ** [https://www.nsnam.org/docs/models/html/ipv6.html IPv6 model in ns-3]<br /> ** [https://www.nsnam.org/docs/models/html/routing-overview.html#global-centralized-routing GlobalRouting model in ns-3]<br /> <br /> Possible tasks to fulfill the patch requirement:<br /> * 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.<br /> <br /> === Mesh Link Establishment (MLE) protocol ===<br /> <br /> Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], TBD.<br /> <br /> 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.<br /> However, MLE is being used in Thread, and it can be useful to implement it.<br /> <br /> 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.<br /> <br /> * ''Required Experience:'' Fundamentals of IPv4 and IPv6 sockets, C++ programming.<br /> * ''Interests:'' Sockets and API interface implementation.<br /> * ''Difficulty:'' Hard.<br /> * ''Recommended reading:''<br /> ** [https://datatracker.ietf.org/doc/html/draft-ietf-6lo-mesh-link-establishment MLE draft]<br /> ** [https://openthread.io/guides/thread-primer/network-discovery Thread primer]<br /> ** [https://www.threadgroup.org/ThreadSpec Thread specifications]<br /> <br /> Possible tasks to fulfill the patch requirement:<br /> * TBD, contact the mentors if interested.<br /> <br /> === Lr-WPAN (IEEE 802.15.4) preamble detection support ===<br /> <br /> Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], [mailto:alramonet@is.tokushima-u.ac.jp Alberto Gallegos Ramonet].<br /> <br /> 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<br /> 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<br /> itself has many added benefits.<br /> <br /> 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.<br /> <br /> As usual, reduction of code duplicity and a flexible scalable design is desired (e.g. Allow the inclusion of different preambles in the future).<br /> <br /> * ''Required Experience:'' Basic understanding of IEEE 802.15.4, C++ programming.<br /> * ''Bonus Experience:'' PHY process familiarity, Familiarity with ns-3's Lr-WPAN<br /> * ''Interests:'' Lr-WPAN, MAC and PHY designs<br /> * ''Difficulty:'' Medium.<br /> * ''Recommended reading:''<br /> ** [https://ieeexplore.ieee.org/document/1700009 IEEE 802.15.4-2006]<br /> ** [https://ieeexplore.ieee.org/document/7460875 IEEE 802.15.4-2015]<br /> ** [https://www.nsnam.org/docs/models/html/lr-wpan.html ns-3 lr-wpan module]<br /> <br /> Possible tasks to fulfill the patch requirement:<br /> * TBD, contact the mentors if interested.<br /> <br /> === 5G NR module integration with ns-3-ai ===<br /> <br /> 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]<br /> <br /> 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.<br /> <br /> 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.<br /> For more specific guidelines, please view this [https://docs.google.com/document/d/1cQLIF1cdft1yj3vyWrjrxN2xDJMx8PuWaa9NP_nKf64/edit?usp=sharing Google document].<br /> <br /> * Required Experience: C++ programming, understanding of 5G NR, LTE, and wireless networks<br /> * Interests: 5G NR simulations<br /> * Difficulty: Medium.<br /> * 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.<br /> <br /> === Linux-like CAKE queue discipline for ns-3 ===<br /> <br /> Mentors: [mailto:tahiliani.nitk@gmail.com Mohit P. Tahiliani]<br /> <br /> 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.<br /> <br /> * ''Required Experience:'' Familiarity with queue disciplines, TCP and C++ programming.<br /> * ''Bonus Experience:'' Familiarity with CAKE framework in Linux 4.19<br /> * ''Interests:'' Active Queue Management, Packet scheduling and TCP.<br /> * ''Difficulty:'' Medium to Hard<br /> * ''Recommended reading:''<br /> ** [https://arxiv.org/pdf/1804.07617.pdf Piece of CAKE: A Comprehensive Queue Management Solution for Home Gateways]<br /> ** [https://lwn.net/Articles/758353/ Let them run CAKE]<br /> ** [https://www.nsnam.org/docs/models/html/queue-discs.html Queue disciplines in ns-3]<br /> <br /> === Switched Ethernet ===<br /> <br /> Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], TBD.<br /> <br /> 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.<br /> <br /> 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.<br /> <br /> 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.<br /> <br /> 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.<br /> <br /> 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.<br /> <br /> * ''Required Experience:'' Fundamentals of Ethernet sitched networking, C++ programming.<br /> * ''Interests:'' Ethernet networks and switched data networks.<br /> * ''Difficulty:'' Medium.<br /> * ''Recommended reading:''<br /> ** [https://www2.nsnam.org/bugzilla/show_bug.cgi?id=2602 Basic implementation (very old)]<br /> ** [https://gitlab.com/nsnam/ns-3-dev/-/merge_requests/431 Full-duplex CSMA, somehow related]<br /> ** [https://tcipg.org/sites/default/files/papers/2010_Jin_Nicol_Caesar.pdf Paper on gigabit Ethernet switch models for simulation]<br /> <br /> Possible tasks to fulfill the patch requirement:<br /> * TBD, contact the mentors if interested.</div>

Tommaso https://www.nsnam.org/mediawiki/index.php?title=GSOC2025Projects&diff=13469 2025-04-19T15:56:46Z

<p>Tommaso: /* IPv6 global routing */</p> <hr /> <div>{{TOC}}<br /> <br /> This page contains 2025 Google Summer of Code project ideas for ns-3.<br /> <br /> * [https://developers.google.com/open-source/gsoc/faq GSoC Frequently Asked Questions]<br /> * [[GSOC2025ContributorGuide | ns-3's 2025 GSoC Contributor guide]]<br /> * [https://developers.google.com/open-source/gsoc/resources/guide GSoC contributor/student guide (not ns-3 specific)]<br /> * [[GSOC2025ApplicationTemplate | 2025 GSoC Contributor application template]]<br /> * [[GSOCMentorGuide | ns-3's GSoC Mentor guide]]<br /> * [https://archive.flossmanuals.net/gsocmentoring/index.html GSoC Mentor guide (not ns-3 specific)]<br /> * [[GSOCSelectionProcess | GSoC Contributor Selection Process]]<br /> * ''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/<br /> <br /> === About the ns-3 project ===<br /> <br /> ns-3 is a discrete-event network simulator, with a particular emphasis on network research and education.<br /> <br /> 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.<br /> <br /> 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.<br /> <br /> === Org admins ===<br /> <br /> 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].<br /> <br /> === Mentors ===<br /> <br /> 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.<br /> <br /> The current list of prospective mentors can be found among the ideas listed below.<br /> <br /> === How to apply ===<br /> <br /> For students or contributors interested in applying to ns-3 for GSoC, please go through the following list to get started:<br /> * Read the official [https://developers.google.com/open-source/gsoc/resources/guide GSoC contributor guide].<br /> * Read [[GSOC2025ContributorGuide |ns-3's 2025 GSoC contributor guide]]<br /> * Look through our [[#Project Ideas]] below to see if you find a project that interests you.<br /> * Review the [https://www.nsnam.org/documentation/development-tree/ tutorial and contributing guide] thoroughly, if you have not already done so.<br /> * 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.<br /> * Next, proceed to get in touch with the developers on the mailing list or Zulip chat room and refine your proposal.<br /> * 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.<br /> <br /> 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.<br /> <br /> &lt;blockquote&gt;<br /> Each project idea within a particular priority has been tagged with the following properties:<br /> * ''Required Experience:'' Languages, concepts, or packages with which applicants must be familiar.<br /> * ''Bonus Experience:'' Other experience or familiarity which would be greatly helpful to applicants for this project.<br /> * ''Interests:'' Areas of particular relevance to this project, and an indicator of where successful contributors might apply their experiences coming out of this project.<br /> * ''Difficulty:'' easy, medium or difficult<br /> * ''Recommended reading:'' pointers to documentation, papers, specific bugs, etc.<br /> <br /> 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.<br /> &lt;/blockquote&gt;<br /> <br /> === Patch requirement guidelines ===<br /> <br /> 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.<br /> <br /> === Mentors: how to participate ===<br /> <br /> 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:<br /> <br /> * 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.<br /> * 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.<br /> * 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.<br /> <br /> == Project Ideas ==<br /> <br /> '''Note to contributors:''' These ideas are not listed in any priority order.<br /> 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.<br /> <br /> === Internet models enhancements ===<br /> <br /> * [[#Upgrade the AQM Evaluation Suite for ns-3]] (small size project, 90h)<br /> * [[#Implementation of Alternative Backoff with ECN (ABE)]] (small size project, 90h)<br /> * [[#ICMP socket and generate/handle ICMP messages (host/net unreachable)]] (medium size project, 175h)<br /> * [[#Linux-like Loss Detection Techniques for ns-3 TCP]] (medium size project, 175h)<br /> * [[#AODVv2 Protocol enhancements]] (medium size project, 175h)<br /> * [[#IPv6 global routing]] (large size project, 350h)<br /> * [[#Linux-like CAKE queue discipline for ns-3]] (large size project, 350h)<br /> * [[#Switched Ethernet]] (large size project, 350h)<br /> <br /> === IoT models enhancements ===<br /> <br /> * [[#6LoWPAN mesh-under routing enhancements]] (medium size project, 175h)<br /> * [[#6LoWPAN neighbor discovery protocol]] (medium size project, 175h)<br /> * [[#Mesh Link Establishment (MLE) protocol ]] (large size project, 350h)<br /> * [[#Lr-WPAN (IEEE 802.15.4) preamble detection support]] (large size project, 350h)<br /> <br /> === 5G NR models enhancements ===<br /> <br /> 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.<br /> <br /> * [[#NTN example for 5G NR]] (small size project, 90h)<br /> * [[#Enabling 5G NR examples visualization]] (medium size project, 175h)<br /> * [[#Improving 5G NR module usability through helpers]] (medium size project, 175h)<br /> * [[#5G NR module integration with ns-3-ai]] (large size project, 250h)<br /> <br /> == Small sized projects (90 hours) ==<br /> <br /> <br /> === NTN example for 5G NR ===<br /> <br /> 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]<br /> <br /> 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).<br /> <br /> 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.<br /> <br /> * Required Experience: C++ programming, understanding of 5G NR, LTE, and wireless networks<br /> * Interests: 5G NR simulations<br /> * Difficulty: Medium.<br /> * 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.<br /> <br /> === Upgrade the AQM Evaluation Suite for ns-3 ===<br /> <br /> Mentors: [mailto:tahiliani.nitk@gmail.com Mohit P. Tahiliani]<br /> <br /> 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.<br /> <br /> * ''Required Experience:'' Familiarity with AQM and C++ programming.<br /> * ''Bonus Experience:'' Familiarity with traffic control model in ns-3.<br /> * ''Interests:'' Packet Scheduling algorithms, AQM algorithms and ECN.<br /> * ''Difficulty:'' Medium.<br /> * ''Recommended Reading:''<br /> ** AQM Evaluation Suite [[https://dl.acm.org/doi/abs/10.1145/3067665.3067674 Paper]] [[https://aqm-eval-suite.github.io/ Implementation]]<br /> ** [https://tools.ietf.org/html/rfc7928 RFC 7928]<br /> ** [https://www.nsnam.org/docs/models/html/traffic-control-layer.html Traffic Control Model in ns-3]<br /> * ''Patch requirement:'' Create a pull request to handle the case when an incorrect Scenario name or number is passed via command line.<br /> <br /> === Implementation of Alternative Backoff with ECN (ABE) ===<br /> <br /> Mentors: [mailto:tahiliani.nitk@gmail.com Mohit P. Tahiliani]<br /> <br /> 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.<br /> <br /> * ''Required Experience:'' Familiarity with ECN and C++ programming.<br /> * ''Bonus Experience:'' Familiarity with traffic control model in ns-3.<br /> * ''Interests:'' Packet Scheduling algorithms, AQM algorithms and ECN.<br /> * ''Difficulty:'' Medium.<br /> * ''Recommended Reading:''<br /> ** Alternative Backoff with ECN [[https://datatracker.ietf.org/doc/rfc8511 RFC 8511]] [[http://heim.ifi.uio.no/~naeemk/research/ABE/Networking2017ABE.pdf Paper]]<br /> ** [https://www.nsnam.org/docs/models/html/tcp.html#support-for-explicit-congestion-notification-ecn ECN support in ns-3]<br /> ** [https://www.nsnam.org/docs/models/html/traffic-control-layer.html Traffic Control Model in ns-3]<br /> <br /> == Medium sized projects (175 hours) ==<br /> <br /> === ICMP socket and generate/handle ICMP messages (host/net unreachable) ===<br /> <br /> Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], [mailto:manoj24.rana@gmail.com Manoj K. Rana].<br /> <br /> 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 &quot;RAW&quot; socket.<br /> 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.<br /> <br /> 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.<br /> <br /> The most important point of the implementation should be code duplicate minimization, in order to have the minimize maintenance efforts.<br /> <br /> Once the sockets are in place, beside the &quot;normal&quot; tests, it will be necessary to modify the code that is actually made obsolete by the new sockets, e.g.:<br /> * IPv6 ICMP messages (RA, RS, NA, NS, etc.),<br /> * IPv4 ICMP messages,<br /> * ICMP Echo and ICMPv6 Echo messages.<br /> and to handle properly ICMP error messages like Destination Unreachable in the Ping application.<br /> <br /> * ''Required Experience:'' Fundamentals of IPv4 and IPv6 sockets, C++ programming.<br /> * ''Interests:'' Sockets and API interface implementation.<br /> * ''Difficulty:'' Medium.<br /> * ''Recommended reading:''<br /> ** [https://man7.org/linux/man-pages/man2/socket.2.html Linux socket]<br /> ** [https://courses.cs.vt.edu/cs4254/fall04/slides/raw_1.pdf Raw Sockets and ICMP, Srinidhi Varadarajan]<br /> ** [https://gitlab.com/nsnam/ns-3-dev/-/issues/810 Issue #810]<br /> <br /> Possible tasks to fulfill the patch requirement:<br /> * Submit a patch to fix [https://gitlab.com/nsnam/ns-3-dev/-/issues/809 Issue #809]<br /> <br /> === 6LoWPAN mesh-under routing enhancements ===<br /> <br /> Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], [TBD].<br /> <br /> 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.<br /> 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.<br /> <br /> The candidate should outline what parts of code are going to be affected, and how they can be enhanced thanks to RFC 7731.<br /> <br /> * ''Required Experience:'' Fundamentals of IPv6 addressing, C++ programming.<br /> * ''Bonus Experience:'' Familiarity with mesh routing and 6LoWPAN ns-3<br /> * ''Interests:'' IPv6 mesh routing<br /> * ''Difficulty:'' Easy.<br /> * ''Recommended reading:''<br /> ** [https://www.nsnam.org/docs/models/html/sixlowpan.html#mesh-under-routing Mesh-under in ns-3 6LoWPAN]<br /> ** [https://datatracker.ietf.org/doc/html/rfc7731 RFC 7731]<br /> <br /> Possible tasks to fulfill the patch requirement:<br /> * 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 &quot;next hop&quot;. The behavior of the actual protocol should be unchanged.<br /> <br /> === 6LoWPAN neighbor discovery protocol ===<br /> <br /> Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], [mailto:adnan.rashid@poliba.it Adnan Rashid].<br /> <br /> 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.<br /> <br /> 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).<br /> <br /> 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.<br /> <br /> * ''Required Experience:'' Fundamentals of IPv6 addressing, C++ programming.<br /> * ''Bonus Experience:'' Familiarity with 6LoWPAN and 6LoWPAN-ND<br /> * ''Interests:'' IPv6 and IoT networks<br /> * ''Difficulty:'' Easy.<br /> * ''Recommended reading:''<br /> ** [https://datatracker.ietf.org/doc/html/rfc8505 RFC 8505]<br /> ** [https://datatracker.ietf.org/doc/html/rfc6775 RFC 6775]<br /> ** [https://datatracker.ietf.org/doc/html/rfc4944 RFC 4944]<br /> <br /> Possible tasks to fulfil the patch requirement:<br /> * Patch the actual 6LoWPAN-ND to remove the limitation about concurrent address registrations.<br /> <br /> === Improving 5G NR module usability through helpers ===<br /> <br /> 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]<br /> <br /> 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.<br /> <br /> 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.<br /> <br /> * Required Experience: C++ programming, understanding of 5G NR, LTE, and wireless networks<br /> * Interests: 5G NR simulations<br /> * Difficulty: Medium.<br /> * 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.<br /> <br /> === Enabling 5G NR examples visualization ===<br /> <br /> 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]<br /> <br /> 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.<br /> <br /> 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.<br /> 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].<br /> <br /> * Required Experience: C++ and Python programming, understanding of 5G NR, LTE, and wireless networks<br /> * Interests: 5G NR simulations<br /> * Difficulty: Medium.<br /> * 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.<br /> <br /> === Linux-like Loss Detection Techniques for ns-3 TCP ===<br /> <br /> Mentors: [mailto:tahiliani.nitk@gmail.com Mohit P. Tahiliani]<br /> <br /> 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.<br /> <br /> * ''Required Experience:'' Familiarity with TCP and C++ programming.<br /> * ''Bonus Experience:'' Familiarity with TCP implementation in Linux kernel.<br /> * ''Interests:'' TCP packet loss detection techniques.<br /> * ''Difficulty:'' Medium to Hard.<br /> * ''Recommended Reading:''<br /> ** Forward Acknowledgement (FACK) [[https://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.41.2559&amp;rep=rep1&amp;type=pdf Paper]] [[https://gitlab.com/nsnam/ns-3-dev/-/merge_requests/34/commits Implementation]]<br /> ** Duplicate Selective Acknowledgment (DSACK) [[https://tools.ietf.org/html/rfc2883 RFC 2883]] [[https://gitlab.com/nsnam/ns-3-dev/-/merge_requests/34/commits Implementation]]<br /> ** RACK-TLP [[https://datatracker.ietf.org/doc/html/rfc8985 RFC 8985]] [[https://gitlab.com/nsnam/ns-3-dev/-/merge_requests/34/commits Implementation]]<br /> <br /> === AODVv2 Protocol enhancements ===<br /> <br /> Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], [TBD].<br /> <br /> 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.<br /> <br /> In particular the project should address the following points: 1) AODVv2 performances, 2) AODV address compression, 3) &quot;external&quot; network routing support, 4) general model validation against the latest draft.<br /> Collaboration with the draft authors is also highly suggested.<br /> <br /> * ''Required Experience:'' Fundamentals of IPv6 addressing, C++ programming.<br /> * ''Bonus Experience:'' Familiarity with AODV implementations in ns-3 and AODVv2<br /> * ''Interests:'' Ad hoc routing<br /> * ''Difficulty:'' Medium.<br /> * ''Recommended reading:''<br /> ** [https://www.nsnam.org/docs/models/html/ipv6.html IPv6 model in ns-3]<br /> ** [https://www.nsnam.org/docs/models/html/aodv.html AODV model in ns-3]<br /> ** [https://datatracker.ietf.org/doc/draft-perkins-manet-aodvv2/05/ Ad Hoc On-demand Distance Vector Version 2 (AODVv2) Routing]<br /> <br /> Possible tasks to fulfill the patch requirement:<br /> * [https://gitlab.com/nsnam/ns-3-dev/-/issues/368 Issue #368] - aodv: aodv parameters can be set to &quot;impossible&quot; values<br /> <br /> == Large projects (350 hours) ==<br /> <br /> === IPv6 global routing ===<br /> <br /> Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], [mailto:manoj24.rana@gmail.com Manoj K. Rana].<br /> <br /> 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).<br /> For IPv4, ns-3 provides two alternatives: GlobalRouting, and NixRouting, which just &quot;do the trick&quot; - they simply fill the routing tables in intermediate nodes, GlobalRouting using an approach similar to OSPF, NixRouting by leveraging the &quot;abstract&quot; knowledge of the network.<br /> Neither actually use any message between the nodes, so they also reduce the network overhead - something that is useful in many cases.<br /> <br /> 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.).<br /> <br /> 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.<br /> <br /> * ''Required Experience:'' Fundamentals of IPv6 addressing, C++ programming.<br /> * ''Bonus Experience:'' Familiarity with GlobalRouting implementations in ns-3<br /> * ''Interests:'' IPv6 routing<br /> * ''Difficulty:'' Medium.<br /> * ''Recommended reading:''<br /> ** [https://www.nsnam.org/docs/models/html/ipv6.html IPv6 model in ns-3]<br /> ** [https://www.nsnam.org/docs/models/html/routing-overview.html#global-centralized-routing GlobalRouting model in ns-3]<br /> <br /> Possible tasks to fulfill the patch requirement:<br /> * 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.<br /> <br /> === Mesh Link Establishment (MLE) protocol ===<br /> <br /> Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], TBD.<br /> <br /> 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.<br /> However, MLE is being used in Thread, and it can be useful to implement it.<br /> <br /> 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.<br /> <br /> * ''Required Experience:'' Fundamentals of IPv4 and IPv6 sockets, C++ programming.<br /> * ''Interests:'' Sockets and API interface implementation.<br /> * ''Difficulty:'' Hard.<br /> * ''Recommended reading:''<br /> ** [https://datatracker.ietf.org/doc/html/draft-ietf-6lo-mesh-link-establishment MLE draft]<br /> ** [https://openthread.io/guides/thread-primer/network-discovery Thread primer]<br /> ** [https://www.threadgroup.org/ThreadSpec Thread specifications]<br /> <br /> Possible tasks to fulfill the patch requirement:<br /> * TBD, contact the mentors if interested.<br /> <br /> === Lr-WPAN (IEEE 802.15.4) preamble detection support ===<br /> <br /> Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], [mailto:alramonet@is.tokushima-u.ac.jp Alberto Gallegos Ramonet].<br /> <br /> 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<br /> 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<br /> itself has many added benefits.<br /> <br /> 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.<br /> <br /> As usual, reduction of code duplicity and a flexible scalable design is desired (e.g. Allow the inclusion of different preambles in the future).<br /> <br /> * ''Required Experience:'' Basic understanding of IEEE 802.15.4, C++ programming.<br /> * ''Bonus Experience:'' PHY process familiarity, Familiarity with ns-3's Lr-WPAN<br /> * ''Interests:'' Lr-WPAN, MAC and PHY designs<br /> * ''Difficulty:'' Medium.<br /> * ''Recommended reading:''<br /> ** [https://ieeexplore.ieee.org/document/1700009 IEEE 802.15.4-2006]<br /> ** [https://ieeexplore.ieee.org/document/7460875 IEEE 802.15.4-2015]<br /> ** [https://www.nsnam.org/docs/models/html/lr-wpan.html ns-3 lr-wpan module]<br /> <br /> Possible tasks to fulfill the patch requirement:<br /> * TBD, contact the mentors if interested.<br /> <br /> === 5G NR module integration with ns-3-ai ===<br /> <br /> 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]<br /> <br /> 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.<br /> <br /> 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.<br /> For more specific guidelines, please view this [https://docs.google.com/document/d/1cQLIF1cdft1yj3vyWrjrxN2xDJMx8PuWaa9NP_nKf64/edit?usp=sharing Google document].<br /> <br /> * Required Experience: C++ programming, understanding of 5G NR, LTE, and wireless networks<br /> * Interests: 5G NR simulations<br /> * Difficulty: Medium.<br /> * 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.<br /> <br /> === Linux-like CAKE queue discipline for ns-3 ===<br /> <br /> Mentors: [mailto:tahiliani.nitk@gmail.com Mohit P. Tahiliani]<br /> <br /> 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.<br /> <br /> * ''Required Experience:'' Familiarity with queue disciplines, TCP and C++ programming.<br /> * ''Bonus Experience:'' Familiarity with CAKE framework in Linux 4.19<br /> * ''Interests:'' Active Queue Management, Packet scheduling and TCP.<br /> * ''Difficulty:'' Medium to Hard<br /> * ''Recommended reading:''<br /> ** [https://arxiv.org/pdf/1804.07617.pdf Piece of CAKE: A Comprehensive Queue Management Solution for Home Gateways]<br /> ** [https://lwn.net/Articles/758353/ Let them run CAKE]<br /> ** [https://www.nsnam.org/docs/models/html/queue-discs.html Queue disciplines in ns-3]<br /> <br /> === Switched Ethernet ===<br /> <br /> Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], TBD.<br /> <br /> 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.<br /> <br /> 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.<br /> <br /> 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.<br /> <br /> 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.<br /> <br /> 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.<br /> <br /> * ''Required Experience:'' Fundamentals of Ethernet sitched networking, C++ programming.<br /> * ''Interests:'' Ethernet networks and switched data networks.<br /> * ''Difficulty:'' Medium.<br /> * ''Recommended reading:''<br /> ** [https://www2.nsnam.org/bugzilla/show_bug.cgi?id=2602 Basic implementation (very old)]<br /> ** [https://gitlab.com/nsnam/ns-3-dev/-/merge_requests/431 Full-duplex CSMA, somehow related]<br /> ** [https://tcipg.org/sites/default/files/papers/2010_Jin_Nicol_Caesar.pdf Paper on gigabit Ethernet switch models for simulation]<br /> <br /> Possible tasks to fulfill the patch requirement:<br /> * TBD, contact the mentors if interested.</div>

Tommaso https://www.nsnam.org/mediawiki/index.php?title=GSOC2025Projects&diff=13468 2025-04-19T15:55:40Z

<p>Tommaso: /* 6LoWPAN neighbor discovery protocol */</p> <hr /> <div>{{TOC}}<br /> <br /> This page contains 2025 Google Summer of Code project ideas for ns-3.<br /> <br /> * [https://developers.google.com/open-source/gsoc/faq GSoC Frequently Asked Questions]<br /> * [[GSOC2025ContributorGuide | ns-3's 2025 GSoC Contributor guide]]<br /> * [https://developers.google.com/open-source/gsoc/resources/guide GSoC contributor/student guide (not ns-3 specific)]<br /> * [[GSOC2025ApplicationTemplate | 2025 GSoC Contributor application template]]<br /> * [[GSOCMentorGuide | ns-3's GSoC Mentor guide]]<br /> * [https://archive.flossmanuals.net/gsocmentoring/index.html GSoC Mentor guide (not ns-3 specific)]<br /> * [[GSOCSelectionProcess | GSoC Contributor Selection Process]]<br /> * ''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/<br /> <br /> === About the ns-3 project ===<br /> <br /> ns-3 is a discrete-event network simulator, with a particular emphasis on network research and education.<br /> <br /> 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.<br /> <br /> 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.<br /> <br /> === Org admins ===<br /> <br /> 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].<br /> <br /> === Mentors ===<br /> <br /> 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.<br /> <br /> The current list of prospective mentors can be found among the ideas listed below.<br /> <br /> === How to apply ===<br /> <br /> For students or contributors interested in applying to ns-3 for GSoC, please go through the following list to get started:<br /> * Read the official [https://developers.google.com/open-source/gsoc/resources/guide GSoC contributor guide].<br /> * Read [[GSOC2025ContributorGuide |ns-3's 2025 GSoC contributor guide]]<br /> * Look through our [[#Project Ideas]] below to see if you find a project that interests you.<br /> * Review the [https://www.nsnam.org/documentation/development-tree/ tutorial and contributing guide] thoroughly, if you have not already done so.<br /> * 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.<br /> * Next, proceed to get in touch with the developers on the mailing list or Zulip chat room and refine your proposal.<br /> * 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.<br /> <br /> 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.<br /> <br /> &lt;blockquote&gt;<br /> Each project idea within a particular priority has been tagged with the following properties:<br /> * ''Required Experience:'' Languages, concepts, or packages with which applicants must be familiar.<br /> * ''Bonus Experience:'' Other experience or familiarity which would be greatly helpful to applicants for this project.<br /> * ''Interests:'' Areas of particular relevance to this project, and an indicator of where successful contributors might apply their experiences coming out of this project.<br /> * ''Difficulty:'' easy, medium or difficult<br /> * ''Recommended reading:'' pointers to documentation, papers, specific bugs, etc.<br /> <br /> 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.<br /> &lt;/blockquote&gt;<br /> <br /> === Patch requirement guidelines ===<br /> <br /> 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.<br /> <br /> === Mentors: how to participate ===<br /> <br /> 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:<br /> <br /> * 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.<br /> * 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.<br /> * 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.<br /> <br /> == Project Ideas ==<br /> <br /> '''Note to contributors:''' These ideas are not listed in any priority order.<br /> 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.<br /> <br /> === Internet models enhancements ===<br /> <br /> * [[#Upgrade the AQM Evaluation Suite for ns-3]] (small size project, 90h)<br /> * [[#Implementation of Alternative Backoff with ECN (ABE)]] (small size project, 90h)<br /> * [[#ICMP socket and generate/handle ICMP messages (host/net unreachable)]] (medium size project, 175h)<br /> * [[#Linux-like Loss Detection Techniques for ns-3 TCP]] (medium size project, 175h)<br /> * [[#AODVv2 Protocol enhancements]] (medium size project, 175h)<br /> * [[#IPv6 global routing]] (large size project, 350h)<br /> * [[#Linux-like CAKE queue discipline for ns-3]] (large size project, 350h)<br /> * [[#Switched Ethernet]] (large size project, 350h)<br /> <br /> === IoT models enhancements ===<br /> <br /> * [[#6LoWPAN mesh-under routing enhancements]] (medium size project, 175h)<br /> * [[#6LoWPAN neighbor discovery protocol]] (medium size project, 175h)<br /> * [[#Mesh Link Establishment (MLE) protocol ]] (large size project, 350h)<br /> * [[#Lr-WPAN (IEEE 802.15.4) preamble detection support]] (large size project, 350h)<br /> <br /> === 5G NR models enhancements ===<br /> <br /> 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.<br /> <br /> * [[#NTN example for 5G NR]] (small size project, 90h)<br /> * [[#Enabling 5G NR examples visualization]] (medium size project, 175h)<br /> * [[#Improving 5G NR module usability through helpers]] (medium size project, 175h)<br /> * [[#5G NR module integration with ns-3-ai]] (large size project, 250h)<br /> <br /> == Small sized projects (90 hours) ==<br /> <br /> <br /> === NTN example for 5G NR ===<br /> <br /> 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]<br /> <br /> 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).<br /> <br /> 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.<br /> <br /> * Required Experience: C++ programming, understanding of 5G NR, LTE, and wireless networks<br /> * Interests: 5G NR simulations<br /> * Difficulty: Medium.<br /> * 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.<br /> <br /> === Upgrade the AQM Evaluation Suite for ns-3 ===<br /> <br /> Mentors: [mailto:tahiliani.nitk@gmail.com Mohit P. Tahiliani]<br /> <br /> 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.<br /> <br /> * ''Required Experience:'' Familiarity with AQM and C++ programming.<br /> * ''Bonus Experience:'' Familiarity with traffic control model in ns-3.<br /> * ''Interests:'' Packet Scheduling algorithms, AQM algorithms and ECN.<br /> * ''Difficulty:'' Medium.<br /> * ''Recommended Reading:''<br /> ** AQM Evaluation Suite [[https://dl.acm.org/doi/abs/10.1145/3067665.3067674 Paper]] [[https://aqm-eval-suite.github.io/ Implementation]]<br /> ** [https://tools.ietf.org/html/rfc7928 RFC 7928]<br /> ** [https://www.nsnam.org/docs/models/html/traffic-control-layer.html Traffic Control Model in ns-3]<br /> * ''Patch requirement:'' Create a pull request to handle the case when an incorrect Scenario name or number is passed via command line.<br /> <br /> === Implementation of Alternative Backoff with ECN (ABE) ===<br /> <br /> Mentors: [mailto:tahiliani.nitk@gmail.com Mohit P. Tahiliani]<br /> <br /> 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.<br /> <br /> * ''Required Experience:'' Familiarity with ECN and C++ programming.<br /> * ''Bonus Experience:'' Familiarity with traffic control model in ns-3.<br /> * ''Interests:'' Packet Scheduling algorithms, AQM algorithms and ECN.<br /> * ''Difficulty:'' Medium.<br /> * ''Recommended Reading:''<br /> ** Alternative Backoff with ECN [[https://datatracker.ietf.org/doc/rfc8511 RFC 8511]] [[http://heim.ifi.uio.no/~naeemk/research/ABE/Networking2017ABE.pdf Paper]]<br /> ** [https://www.nsnam.org/docs/models/html/tcp.html#support-for-explicit-congestion-notification-ecn ECN support in ns-3]<br /> ** [https://www.nsnam.org/docs/models/html/traffic-control-layer.html Traffic Control Model in ns-3]<br /> <br /> == Medium sized projects (175 hours) ==<br /> <br /> === ICMP socket and generate/handle ICMP messages (host/net unreachable) ===<br /> <br /> Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], [mailto:manoj24.rana@gmail.com Manoj K. Rana].<br /> <br /> 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 &quot;RAW&quot; socket.<br /> 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.<br /> <br /> 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.<br /> <br /> The most important point of the implementation should be code duplicate minimization, in order to have the minimize maintenance efforts.<br /> <br /> Once the sockets are in place, beside the &quot;normal&quot; tests, it will be necessary to modify the code that is actually made obsolete by the new sockets, e.g.:<br /> * IPv6 ICMP messages (RA, RS, NA, NS, etc.),<br /> * IPv4 ICMP messages,<br /> * ICMP Echo and ICMPv6 Echo messages.<br /> and to handle properly ICMP error messages like Destination Unreachable in the Ping application.<br /> <br /> * ''Required Experience:'' Fundamentals of IPv4 and IPv6 sockets, C++ programming.<br /> * ''Interests:'' Sockets and API interface implementation.<br /> * ''Difficulty:'' Medium.<br /> * ''Recommended reading:''<br /> ** [https://man7.org/linux/man-pages/man2/socket.2.html Linux socket]<br /> ** [https://courses.cs.vt.edu/cs4254/fall04/slides/raw_1.pdf Raw Sockets and ICMP, Srinidhi Varadarajan]<br /> ** [https://gitlab.com/nsnam/ns-3-dev/-/issues/810 Issue #810]<br /> <br /> Possible tasks to fulfill the patch requirement:<br /> * Submit a patch to fix [https://gitlab.com/nsnam/ns-3-dev/-/issues/809 Issue #809]<br /> <br /> === 6LoWPAN mesh-under routing enhancements ===<br /> <br /> Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], [TBD].<br /> <br /> 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.<br /> 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.<br /> <br /> The candidate should outline what parts of code are going to be affected, and how they can be enhanced thanks to RFC 7731.<br /> <br /> * ''Required Experience:'' Fundamentals of IPv6 addressing, C++ programming.<br /> * ''Bonus Experience:'' Familiarity with mesh routing and 6LoWPAN ns-3<br /> * ''Interests:'' IPv6 mesh routing<br /> * ''Difficulty:'' Easy.<br /> * ''Recommended reading:''<br /> ** [https://www.nsnam.org/docs/models/html/sixlowpan.html#mesh-under-routing Mesh-under in ns-3 6LoWPAN]<br /> ** [https://datatracker.ietf.org/doc/html/rfc7731 RFC 7731]<br /> <br /> Possible tasks to fulfill the patch requirement:<br /> * 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 &quot;next hop&quot;. The behavior of the actual protocol should be unchanged.<br /> <br /> === 6LoWPAN neighbor discovery protocol ===<br /> <br /> Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], [mailto:adnan.rashid@poliba.it Adnan Rashid].<br /> <br /> 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.<br /> <br /> 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).<br /> <br /> 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.<br /> <br /> * ''Required Experience:'' Fundamentals of IPv6 addressing, C++ programming.<br /> * ''Bonus Experience:'' Familiarity with 6LoWPAN and 6LoWPAN-ND<br /> * ''Interests:'' IPv6 and IoT networks<br /> * ''Difficulty:'' Easy.<br /> * ''Recommended reading:''<br /> ** [https://datatracker.ietf.org/doc/html/rfc8505 RFC 8505]<br /> ** [https://datatracker.ietf.org/doc/html/rfc6775 RFC 6775]<br /> ** [https://datatracker.ietf.org/doc/html/rfc4944 RFC 4944]<br /> <br /> Possible tasks to fulfil the patch requirement:<br /> * Patch the actual 6LoWPAN-ND to remove the limitation about concurrent address registrations.<br /> <br /> === Improving 5G NR module usability through helpers ===<br /> <br /> 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]<br /> <br /> 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.<br /> <br /> 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.<br /> <br /> * Required Experience: C++ programming, understanding of 5G NR, LTE, and wireless networks<br /> * Interests: 5G NR simulations<br /> * Difficulty: Medium.<br /> * 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.<br /> <br /> === Enabling 5G NR examples visualization ===<br /> <br /> 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]<br /> <br /> 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.<br /> <br /> 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.<br /> 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].<br /> <br /> * Required Experience: C++ and Python programming, understanding of 5G NR, LTE, and wireless networks<br /> * Interests: 5G NR simulations<br /> * Difficulty: Medium.<br /> * 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.<br /> <br /> === Linux-like Loss Detection Techniques for ns-3 TCP ===<br /> <br /> Mentors: [mailto:tahiliani.nitk@gmail.com Mohit P. Tahiliani]<br /> <br /> 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.<br /> <br /> * ''Required Experience:'' Familiarity with TCP and C++ programming.<br /> * ''Bonus Experience:'' Familiarity with TCP implementation in Linux kernel.<br /> * ''Interests:'' TCP packet loss detection techniques.<br /> * ''Difficulty:'' Medium to Hard.<br /> * ''Recommended Reading:''<br /> ** Forward Acknowledgement (FACK) [[https://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.41.2559&amp;rep=rep1&amp;type=pdf Paper]] [[https://gitlab.com/nsnam/ns-3-dev/-/merge_requests/34/commits Implementation]]<br /> ** Duplicate Selective Acknowledgment (DSACK) [[https://tools.ietf.org/html/rfc2883 RFC 2883]] [[https://gitlab.com/nsnam/ns-3-dev/-/merge_requests/34/commits Implementation]]<br /> ** RACK-TLP [[https://datatracker.ietf.org/doc/html/rfc8985 RFC 8985]] [[https://gitlab.com/nsnam/ns-3-dev/-/merge_requests/34/commits Implementation]]<br /> <br /> === AODVv2 Protocol enhancements ===<br /> <br /> Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], [TBD].<br /> <br /> 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.<br /> <br /> In particular the project should address the following points: 1) AODVv2 performances, 2) AODV address compression, 3) &quot;external&quot; network routing support, 4) general model validation against the latest draft.<br /> Collaboration with the draft authors is also highly suggested.<br /> <br /> * ''Required Experience:'' Fundamentals of IPv6 addressing, C++ programming.<br /> * ''Bonus Experience:'' Familiarity with AODV implementations in ns-3 and AODVv2<br /> * ''Interests:'' Ad hoc routing<br /> * ''Difficulty:'' Medium.<br /> * ''Recommended reading:''<br /> ** [https://www.nsnam.org/docs/models/html/ipv6.html IPv6 model in ns-3]<br /> ** [https://www.nsnam.org/docs/models/html/aodv.html AODV model in ns-3]<br /> ** [https://datatracker.ietf.org/doc/draft-perkins-manet-aodvv2/05/ Ad Hoc On-demand Distance Vector Version 2 (AODVv2) Routing]<br /> <br /> Possible tasks to fulfill the patch requirement:<br /> * [https://gitlab.com/nsnam/ns-3-dev/-/issues/368 Issue #368] - aodv: aodv parameters can be set to &quot;impossible&quot; values<br /> <br /> == Large projects (350 hours) ==<br /> <br /> === IPv6 global routing ===<br /> <br /> Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], [TBD].<br /> <br /> 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).<br /> For IPv4, ns-3 provides two alternatives: GlobalRouting, and NixRouting, which just &quot;do the trick&quot; - they simply fill the routing tables in intermediate nodes, GlobalRouting using an approach similar to OSPF, NixRouting by leveraging the &quot;abstract&quot; knowledge of the network.<br /> Neither actually use any message between the nodes, so they also reduce the network overhead - something that is useful in many cases.<br /> <br /> 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.).<br /> <br /> 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.<br /> <br /> * ''Required Experience:'' Fundamentals of IPv6 addressing, C++ programming.<br /> * ''Bonus Experience:'' Familiarity with GlobalRouting implementations in ns-3<br /> * ''Interests:'' IPv6 routing<br /> * ''Difficulty:'' Medium.<br /> * ''Recommended reading:''<br /> ** [https://www.nsnam.org/docs/models/html/ipv6.html IPv6 model in ns-3]<br /> ** [https://www.nsnam.org/docs/models/html/routing-overview.html#global-centralized-routing GlobalRouting model in ns-3]<br /> <br /> Possible tasks to fulfill the patch requirement:<br /> * 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.<br /> <br /> === Mesh Link Establishment (MLE) protocol ===<br /> <br /> Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], TBD.<br /> <br /> 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.<br /> However, MLE is being used in Thread, and it can be useful to implement it.<br /> <br /> 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.<br /> <br /> * ''Required Experience:'' Fundamentals of IPv4 and IPv6 sockets, C++ programming.<br /> * ''Interests:'' Sockets and API interface implementation.<br /> * ''Difficulty:'' Hard.<br /> * ''Recommended reading:''<br /> ** [https://datatracker.ietf.org/doc/html/draft-ietf-6lo-mesh-link-establishment MLE draft]<br /> ** [https://openthread.io/guides/thread-primer/network-discovery Thread primer]<br /> ** [https://www.threadgroup.org/ThreadSpec Thread specifications]<br /> <br /> Possible tasks to fulfill the patch requirement:<br /> * TBD, contact the mentors if interested.<br /> <br /> === Lr-WPAN (IEEE 802.15.4) preamble detection support ===<br /> <br /> Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], [mailto:alramonet@is.tokushima-u.ac.jp Alberto Gallegos Ramonet].<br /> <br /> 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<br /> 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<br /> itself has many added benefits.<br /> <br /> 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.<br /> <br /> As usual, reduction of code duplicity and a flexible scalable design is desired (e.g. Allow the inclusion of different preambles in the future).<br /> <br /> * ''Required Experience:'' Basic understanding of IEEE 802.15.4, C++ programming.<br /> * ''Bonus Experience:'' PHY process familiarity, Familiarity with ns-3's Lr-WPAN<br /> * ''Interests:'' Lr-WPAN, MAC and PHY designs<br /> * ''Difficulty:'' Medium.<br /> * ''Recommended reading:''<br /> ** [https://ieeexplore.ieee.org/document/1700009 IEEE 802.15.4-2006]<br /> ** [https://ieeexplore.ieee.org/document/7460875 IEEE 802.15.4-2015]<br /> ** [https://www.nsnam.org/docs/models/html/lr-wpan.html ns-3 lr-wpan module]<br /> <br /> Possible tasks to fulfill the patch requirement:<br /> * TBD, contact the mentors if interested.<br /> <br /> === 5G NR module integration with ns-3-ai ===<br /> <br /> 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]<br /> <br /> 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.<br /> <br /> 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.<br /> For more specific guidelines, please view this [https://docs.google.com/document/d/1cQLIF1cdft1yj3vyWrjrxN2xDJMx8PuWaa9NP_nKf64/edit?usp=sharing Google document].<br /> <br /> * Required Experience: C++ programming, understanding of 5G NR, LTE, and wireless networks<br /> * Interests: 5G NR simulations<br /> * Difficulty: Medium.<br /> * 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.<br /> <br /> === Linux-like CAKE queue discipline for ns-3 ===<br /> <br /> Mentors: [mailto:tahiliani.nitk@gmail.com Mohit P. Tahiliani]<br /> <br /> 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.<br /> <br /> * ''Required Experience:'' Familiarity with queue disciplines, TCP and C++ programming.<br /> * ''Bonus Experience:'' Familiarity with CAKE framework in Linux 4.19<br /> * ''Interests:'' Active Queue Management, Packet scheduling and TCP.<br /> * ''Difficulty:'' Medium to Hard<br /> * ''Recommended reading:''<br /> ** [https://arxiv.org/pdf/1804.07617.pdf Piece of CAKE: A Comprehensive Queue Management Solution for Home Gateways]<br /> ** [https://lwn.net/Articles/758353/ Let them run CAKE]<br /> ** [https://www.nsnam.org/docs/models/html/queue-discs.html Queue disciplines in ns-3]<br /> <br /> === Switched Ethernet ===<br /> <br /> Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], TBD.<br /> <br /> 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.<br /> <br /> 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.<br /> <br /> 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.<br /> <br /> 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.<br /> <br /> 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.<br /> <br /> * ''Required Experience:'' Fundamentals of Ethernet sitched networking, C++ programming.<br /> * ''Interests:'' Ethernet networks and switched data networks.<br /> * ''Difficulty:'' Medium.<br /> * ''Recommended reading:''<br /> ** [https://www2.nsnam.org/bugzilla/show_bug.cgi?id=2602 Basic implementation (very old)]<br /> ** [https://gitlab.com/nsnam/ns-3-dev/-/merge_requests/431 Full-duplex CSMA, somehow related]<br /> ** [https://tcipg.org/sites/default/files/papers/2010_Jin_Nicol_Caesar.pdf Paper on gigabit Ethernet switch models for simulation]<br /> <br /> Possible tasks to fulfill the patch requirement:<br /> * TBD, contact the mentors if interested.</div>

Tommaso https://www.nsnam.org/mediawiki/index.php?title=GSOC2025Projects&diff=13465 2025-03-17T17:22:25Z

<p>Tommaso: /* 6LoWPAN mesh-under routing enhancements */</p> <hr /> <div>{{TOC}}<br /> <br /> This page contains 2025 Google Summer of Code project ideas for ns-3.<br /> <br /> * [https://developers.google.com/open-source/gsoc/faq GSoC Frequently Asked Questions]<br /> * [[GSOC2025ContributorGuide | ns-3's 2025 GSoC Contributor guide]]<br /> * [https://developers.google.com/open-source/gsoc/resources/guide GSoC contributor/student guide (not ns-3 specific)]<br /> * [[GSOC2025ApplicationTemplate | 2025 GSoC Contributor application template]]<br /> * [[GSOCMentorGuide | ns-3's GSoC Mentor guide]]<br /> * [https://archive.flossmanuals.net/gsocmentoring/index.html GSoC Mentor guide (not ns-3 specific)]<br /> * [[GSOCSelectionProcess | GSoC Contributor Selection Process]]<br /> * ''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/<br /> <br /> === About the ns-3 project ===<br /> <br /> ns-3 is a discrete-event network simulator, with a particular emphasis on network research and education.<br /> <br /> 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.<br /> <br /> 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.<br /> <br /> === Org admins ===<br /> <br /> 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].<br /> <br /> === Mentors ===<br /> <br /> 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.<br /> <br /> The current list of prospective mentors can be found among the ideas listed below.<br /> <br /> === How to apply ===<br /> <br /> For students or contributors interested in applying to ns-3 for GSoC, please go through the following list to get started:<br /> * Read the official [https://developers.google.com/open-source/gsoc/resources/guide GSoC contributor guide].<br /> * Read [[GSOC2025ContributorGuide |ns-3's 2025 GSoC contributor guide]]<br /> * Look through our [[#Project Ideas]] below to see if you find a project that interests you.<br /> * Review the [https://www.nsnam.org/documentation/development-tree/ tutorial and contributing guide] thoroughly, if you have not already done so.<br /> * 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.<br /> * Next, proceed to get in touch with the developers on the mailing list or Zulip chat room and refine your proposal.<br /> * 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.<br /> <br /> 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.<br /> <br /> &lt;blockquote&gt;<br /> Each project idea within a particular priority has been tagged with the following properties:<br /> * ''Required Experience:'' Languages, concepts, or packages with which applicants must be familiar.<br /> * ''Bonus Experience:'' Other experience or familiarity which would be greatly helpful to applicants for this project.<br /> * ''Interests:'' Areas of particular relevance to this project, and an indicator of where successful contributors might apply their experiences coming out of this project.<br /> * ''Difficulty:'' easy, medium or difficult<br /> * ''Recommended reading:'' pointers to documentation, papers, specific bugs, etc.<br /> <br /> 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.<br /> &lt;/blockquote&gt;<br /> <br /> === Patch requirement guidelines ===<br /> <br /> 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.<br /> <br /> === Mentors: how to participate ===<br /> <br /> 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:<br /> <br /> * 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.<br /> * 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.<br /> * 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.<br /> <br /> == Project Ideas ==<br /> <br /> '''Note to contributors:''' These ideas are not listed in any priority order.<br /> 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.<br /> <br /> === Internet models enhancements ===<br /> <br /> * [[#Upgrade the AQM Evaluation Suite for ns-3]] (small size project, 90h)<br /> * [[#Implementation of Alternative Backoff with ECN (ABE)]] (small size project, 90h)<br /> * [[#ICMP socket and generate/handle ICMP messages (host/net unreachable)]] (medium size project, 175h)<br /> * [[#Linux-like Loss Detection Techniques for ns-3 TCP]] (medium size project, 175h)<br /> * [[#AODVv2 Protocol enhancements]] (medium size project, 175h)<br /> * [[#IPv6 global routing]] (large size project, 350h)<br /> * [[#Linux-like CAKE queue discipline for ns-3]] (large size project, 350h)<br /> * [[#Switched Ethernet]] (large size project, 350h)<br /> <br /> === IoT models enhancements ===<br /> <br /> * [[#6LoWPAN mesh-under routing enhancements]] (medium size project, 175h)<br /> * [[#6LoWPAN neighbor discovery protocol]] (medium size project, 175h)<br /> * [[#Mesh Link Establishment (MLE) protocol ]] (large size project, 350h)<br /> * [[#Lr-WPAN (IEEE 802.15.4) preamble detection support]] (large size project, 350h)<br /> <br /> === 5G NR models enhancements ===<br /> <br /> 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.<br /> <br /> * [[#NTN example for 5G NR]] (small size project, 90h)<br /> * [[#Enabling 5G NR examples visualization]] (medium size project, 175h)<br /> * [[#Improving 5G NR module usability through helpers]] (medium size project, 175h)<br /> * [[#5G NR module integration with ns-3-ai]] (large size project, 250h)<br /> <br /> == Small sized projects (90 hours) ==<br /> <br /> <br /> === NTN example for 5G NR ===<br /> <br /> 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]<br /> <br /> 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).<br /> <br /> 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.<br /> <br /> * Required Experience: C++ programming, understanding of 5G NR, LTE, and wireless networks<br /> * Interests: 5G NR simulations<br /> * Difficulty: Medium.<br /> * 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.<br /> <br /> === Upgrade the AQM Evaluation Suite for ns-3 ===<br /> <br /> Mentors: [mailto:tahiliani.nitk@gmail.com Mohit P. Tahiliani]<br /> <br /> 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.<br /> <br /> * ''Required Experience:'' Familiarity with AQM and C++ programming.<br /> * ''Bonus Experience:'' Familiarity with traffic control model in ns-3.<br /> * ''Interests:'' Packet Scheduling algorithms, AQM algorithms and ECN.<br /> * ''Difficulty:'' Medium.<br /> * ''Recommended Reading:''<br /> ** AQM Evaluation Suite [[https://dl.acm.org/doi/abs/10.1145/3067665.3067674 Paper]] [[https://aqm-eval-suite.github.io/ Implementation]]<br /> ** [https://tools.ietf.org/html/rfc7928 RFC 7928]<br /> ** [https://www.nsnam.org/docs/models/html/traffic-control-layer.html Traffic Control Model in ns-3]<br /> * ''Patch requirement:'' Create a pull request to handle the case when an incorrect Scenario name or number is passed via command line.<br /> <br /> === Implementation of Alternative Backoff with ECN (ABE) ===<br /> <br /> Mentors: [mailto:tahiliani.nitk@gmail.com Mohit P. Tahiliani]<br /> <br /> 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.<br /> <br /> * ''Required Experience:'' Familiarity with ECN and C++ programming.<br /> * ''Bonus Experience:'' Familiarity with traffic control model in ns-3.<br /> * ''Interests:'' Packet Scheduling algorithms, AQM algorithms and ECN.<br /> * ''Difficulty:'' Medium.<br /> * ''Recommended Reading:''<br /> ** Alternative Backoff with ECN [[https://datatracker.ietf.org/doc/rfc8511 RFC 8511]] [[http://heim.ifi.uio.no/~naeemk/research/ABE/Networking2017ABE.pdf Paper]]<br /> ** [https://www.nsnam.org/docs/models/html/tcp.html#support-for-explicit-congestion-notification-ecn ECN support in ns-3]<br /> ** [https://www.nsnam.org/docs/models/html/traffic-control-layer.html Traffic Control Model in ns-3]<br /> <br /> == Medium sized projects (175 hours) ==<br /> <br /> === ICMP socket and generate/handle ICMP messages (host/net unreachable) ===<br /> <br /> Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], [mailto:manoj24.rana@gmail.com Manoj K. Rana].<br /> <br /> 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 &quot;RAW&quot; socket.<br /> 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.<br /> <br /> 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.<br /> <br /> The most important point of the implementation should be code duplicate minimization, in order to have the minimize maintenance efforts.<br /> <br /> Once the sockets are in place, beside the &quot;normal&quot; tests, it will be necessary to modify the code that is actually made obsolete by the new sockets, e.g.:<br /> * IPv6 ICMP messages (RA, RS, NA, NS, etc.),<br /> * IPv4 ICMP messages,<br /> * ICMP Echo and ICMPv6 Echo messages.<br /> and to handle properly ICMP error messages like Destination Unreachable in the Ping application.<br /> <br /> * ''Required Experience:'' Fundamentals of IPv4 and IPv6 sockets, C++ programming.<br /> * ''Interests:'' Sockets and API interface implementation.<br /> * ''Difficulty:'' Medium.<br /> * ''Recommended reading:''<br /> ** [https://man7.org/linux/man-pages/man2/socket.2.html Linux socket]<br /> ** [https://courses.cs.vt.edu/cs4254/fall04/slides/raw_1.pdf Raw Sockets and ICMP, Srinidhi Varadarajan]<br /> ** [https://gitlab.com/nsnam/ns-3-dev/-/issues/810 Issue #810]<br /> <br /> Possible tasks to fulfill the patch requirement:<br /> * Submit a patch to fix [https://gitlab.com/nsnam/ns-3-dev/-/issues/809 Issue #809]<br /> <br /> === 6LoWPAN mesh-under routing enhancements ===<br /> <br /> Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], [TBD].<br /> <br /> 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.<br /> 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.<br /> <br /> The candidate should outline what parts of code are going to be affected, and how they can be enhanced thanks to RFC 7731.<br /> <br /> * ''Required Experience:'' Fundamentals of IPv6 addressing, C++ programming.<br /> * ''Bonus Experience:'' Familiarity with mesh routing and 6LoWPAN ns-3<br /> * ''Interests:'' IPv6 mesh routing<br /> * ''Difficulty:'' Easy.<br /> * ''Recommended reading:''<br /> ** [https://www.nsnam.org/docs/models/html/sixlowpan.html#mesh-under-routing Mesh-under in ns-3 6LoWPAN]<br /> ** [https://datatracker.ietf.org/doc/html/rfc7731 RFC 7731]<br /> <br /> Possible tasks to fulfill the patch requirement:<br /> * 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 &quot;next hop&quot;. The behavior of the actual protocol should be unchanged.<br /> <br /> === 6LoWPAN neighbor discovery protocol ===<br /> <br /> Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], [TBD].<br /> <br /> 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.<br /> <br /> 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).<br /> <br /> 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.<br /> <br /> * ''Required Experience:'' Fundamentals of IPv6 addressing, C++ programming.<br /> * ''Bonus Experience:'' Familiarity with 6LoWPAN and 6LoWPAN-ND<br /> * ''Interests:'' IPv6 and IoT networks<br /> * ''Difficulty:'' Easy.<br /> * ''Recommended reading:''<br /> ** [https://datatracker.ietf.org/doc/html/rfc8505 RFC 8505]<br /> ** [https://datatracker.ietf.org/doc/html/rfc6775 RFC 6775]<br /> ** [https://datatracker.ietf.org/doc/html/rfc4944 RFC 4944]<br /> <br /> Possible tasks to fulfil the patch requirement:<br /> * Patch the actual 6LoWPAN-ND to remove the limitation about concurrent address registrations.<br /> <br /> === Improving 5G NR module usability through helpers ===<br /> <br /> 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]<br /> <br /> 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.<br /> <br /> 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.<br /> <br /> * Required Experience: C++ programming, understanding of 5G NR, LTE, and wireless networks<br /> * Interests: 5G NR simulations<br /> * Difficulty: Medium.<br /> * 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.<br /> <br /> === Enabling 5G NR examples visualization ===<br /> <br /> 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]<br /> <br /> 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.<br /> <br /> 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.<br /> 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].<br /> <br /> * Required Experience: C++ and Python programming, understanding of 5G NR, LTE, and wireless networks<br /> * Interests: 5G NR simulations<br /> * Difficulty: Medium.<br /> * 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.<br /> <br /> === Linux-like Loss Detection Techniques for ns-3 TCP ===<br /> <br /> Mentors: [mailto:tahiliani.nitk@gmail.com Mohit P. Tahiliani]<br /> <br /> 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.<br /> <br /> * ''Required Experience:'' Familiarity with TCP and C++ programming.<br /> * ''Bonus Experience:'' Familiarity with TCP implementation in Linux kernel.<br /> * ''Interests:'' TCP packet loss detection techniques.<br /> * ''Difficulty:'' Medium to Hard.<br /> * ''Recommended Reading:''<br /> ** Forward Acknowledgement (FACK) [[https://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.41.2559&amp;rep=rep1&amp;type=pdf Paper]] [[https://gitlab.com/nsnam/ns-3-dev/-/merge_requests/34/commits Implementation]]<br /> ** Duplicate Selective Acknowledgment (DSACK) [[https://tools.ietf.org/html/rfc2883 RFC 2883]] [[https://gitlab.com/nsnam/ns-3-dev/-/merge_requests/34/commits Implementation]]<br /> ** RACK-TLP [[https://datatracker.ietf.org/doc/html/rfc8985 RFC 8985]] [[https://gitlab.com/nsnam/ns-3-dev/-/merge_requests/34/commits Implementation]]<br /> <br /> === AODVv2 Protocol enhancements ===<br /> <br /> Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], [TBD].<br /> <br /> 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.<br /> <br /> In particular the project should address the following points: 1) AODVv2 performances, 2) AODV address compression, 3) &quot;external&quot; network routing support, 4) general model validation against the latest draft.<br /> Collaboration with the draft authors is also highly suggested.<br /> <br /> * ''Required Experience:'' Fundamentals of IPv6 addressing, C++ programming.<br /> * ''Bonus Experience:'' Familiarity with AODV implementations in ns-3 and AODVv2<br /> * ''Interests:'' Ad hoc routing<br /> * ''Difficulty:'' Medium.<br /> * ''Recommended reading:''<br /> ** [https://www.nsnam.org/docs/models/html/ipv6.html IPv6 model in ns-3]<br /> ** [https://www.nsnam.org/docs/models/html/aodv.html AODV model in ns-3]<br /> ** [https://datatracker.ietf.org/doc/draft-perkins-manet-aodvv2/05/ Ad Hoc On-demand Distance Vector Version 2 (AODVv2) Routing]<br /> <br /> Possible tasks to fulfill the patch requirement:<br /> * [https://gitlab.com/nsnam/ns-3-dev/-/issues/368 Issue #368] - aodv: aodv parameters can be set to &quot;impossible&quot; values<br /> <br /> == Large projects (350 hours) ==<br /> <br /> === IPv6 global routing ===<br /> <br /> Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], [TBD].<br /> <br /> 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).<br /> For IPv4, ns-3 provides two alternatives: GlobalRouting, and NixRouting, which just &quot;do the trick&quot; - they simply fill the routing tables in intermediate nodes, GlobalRouting using an approach similar to OSPF, NixRouting by leveraging the &quot;abstract&quot; knowledge of the network.<br /> Neither actually use any message between the nodes, so they also reduce the network overhead - something that is useful in many cases.<br /> <br /> 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.).<br /> <br /> 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.<br /> <br /> * ''Required Experience:'' Fundamentals of IPv6 addressing, C++ programming.<br /> * ''Bonus Experience:'' Familiarity with GlobalRouting implementations in ns-3<br /> * ''Interests:'' IPv6 routing<br /> * ''Difficulty:'' Medium.<br /> * ''Recommended reading:''<br /> ** [https://www.nsnam.org/docs/models/html/ipv6.html IPv6 model in ns-3]<br /> ** [https://www.nsnam.org/docs/models/html/routing-overview.html#global-centralized-routing GlobalRouting model in ns-3]<br /> <br /> Possible tasks to fulfill the patch requirement:<br /> * 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.<br /> <br /> === Mesh Link Establishment (MLE) protocol ===<br /> <br /> Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], TBD.<br /> <br /> 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.<br /> However, MLE is being used in Thread, and it can be useful to implement it.<br /> <br /> 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.<br /> <br /> * ''Required Experience:'' Fundamentals of IPv4 and IPv6 sockets, C++ programming.<br /> * ''Interests:'' Sockets and API interface implementation.<br /> * ''Difficulty:'' Hard.<br /> * ''Recommended reading:''<br /> ** [https://datatracker.ietf.org/doc/html/draft-ietf-6lo-mesh-link-establishment MLE draft]<br /> ** [https://openthread.io/guides/thread-primer/network-discovery Thread primer]<br /> ** [https://www.threadgroup.org/ThreadSpec Thread specifications]<br /> <br /> Possible tasks to fulfill the patch requirement:<br /> * TBD, contact the mentors if interested.<br /> <br /> === Lr-WPAN (IEEE 802.15.4) preamble detection support ===<br /> <br /> Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], [mailto:alramonet@is.tokushima-u.ac.jp Alberto Gallegos Ramonet].<br /> <br /> 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<br /> 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<br /> itself has many added benefits.<br /> <br /> 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.<br /> <br /> As usual, reduction of code duplicity and a flexible scalable design is desired (e.g. Allow the inclusion of different preambles in the future).<br /> <br /> * ''Required Experience:'' Basic understanding of IEEE 802.15.4, C++ programming.<br /> * ''Bonus Experience:'' PHY process familiarity, Familiarity with ns-3's Lr-WPAN<br /> * ''Interests:'' Lr-WPAN, MAC and PHY designs<br /> * ''Difficulty:'' Medium.<br /> * ''Recommended reading:''<br /> ** [https://ieeexplore.ieee.org/document/1700009 IEEE 802.15.4-2006]<br /> ** [https://ieeexplore.ieee.org/document/7460875 IEEE 802.15.4-2015]<br /> ** [https://www.nsnam.org/docs/models/html/lr-wpan.html ns-3 lr-wpan module]<br /> <br /> Possible tasks to fulfill the patch requirement:<br /> * TBD, contact the mentors if interested.<br /> <br /> === 5G NR module integration with ns-3-ai ===<br /> <br /> 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]<br /> <br /> 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.<br /> <br /> 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.<br /> For more specific guidelines, please view this [https://docs.google.com/document/d/1cQLIF1cdft1yj3vyWrjrxN2xDJMx8PuWaa9NP_nKf64/edit?usp=sharing Google document].<br /> <br /> * Required Experience: C++ programming, understanding of 5G NR, LTE, and wireless networks<br /> * Interests: 5G NR simulations<br /> * Difficulty: Medium.<br /> * 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.<br /> <br /> === Linux-like CAKE queue discipline for ns-3 ===<br /> <br /> Mentors: [mailto:tahiliani.nitk@gmail.com Mohit P. Tahiliani]<br /> <br /> 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.<br /> <br /> * ''Required Experience:'' Familiarity with queue disciplines, TCP and C++ programming.<br /> * ''Bonus Experience:'' Familiarity with CAKE framework in Linux 4.19<br /> * ''Interests:'' Active Queue Management, Packet scheduling and TCP.<br /> * ''Difficulty:'' Medium to Hard<br /> * ''Recommended reading:''<br /> ** [https://arxiv.org/pdf/1804.07617.pdf Piece of CAKE: A Comprehensive Queue Management Solution for Home Gateways]<br /> ** [https://lwn.net/Articles/758353/ Let them run CAKE]<br /> ** [https://www.nsnam.org/docs/models/html/queue-discs.html Queue disciplines in ns-3]<br /> <br /> === Switched Ethernet ===<br /> <br /> Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], TBD.<br /> <br /> 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.<br /> <br /> 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.<br /> <br /> 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.<br /> <br /> 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.<br /> <br /> 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.<br /> <br /> * ''Required Experience:'' Fundamentals of Ethernet sitched networking, C++ programming.<br /> * ''Interests:'' Ethernet networks and switched data networks.<br /> * ''Difficulty:'' Medium.<br /> * ''Recommended reading:''<br /> ** [https://www2.nsnam.org/bugzilla/show_bug.cgi?id=2602 Basic implementation (very old)]<br /> ** [https://gitlab.com/nsnam/ns-3-dev/-/merge_requests/431 Full-duplex CSMA, somehow related]<br /> ** [https://tcipg.org/sites/default/files/papers/2010_Jin_Nicol_Caesar.pdf Paper on gigabit Ethernet switch models for simulation]<br /> <br /> Possible tasks to fulfill the patch requirement:<br /> * TBD, contact the mentors if interested.</div>

Tommaso https://www.nsnam.org/mediawiki/index.php?title=GSOC2025Projects&diff=13458 2025-02-28T19:39:45Z

<p>Tommaso: /* Internet models enhancements */</p> <hr /> <div>{{TOC}}<br /> <br /> This page contains 2025 Google Summer of Code project ideas for ns-3.<br /> <br /> * [https://developers.google.com/open-source/gsoc/faq GSoC Frequently Asked Questions]<br /> * [[GSOC2025ContributorGuide | ns-3's 2025 GSoC Contributor guide]]<br /> * [https://developers.google.com/open-source/gsoc/resources/guide GSoC contributor/student guide (not ns-3 specific)]<br /> * [[GSOC2025ApplicationTemplate | 2025 GSoC Contributor application template]]<br /> * [[GSOCMentorGuide | ns-3's GSoC Mentor guide]]<br /> * [https://archive.flossmanuals.net/gsocmentoring/index.html GSoC Mentor guide (not ns-3 specific)]<br /> * [[GSOCSelectionProcess | GSoC Contributor Selection Process]]<br /> * ''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/<br /> <br /> === About the ns-3 project ===<br /> <br /> ns-3 is a discrete-event network simulator, with a particular emphasis on network research and education.<br /> <br /> 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.<br /> <br /> 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.<br /> <br /> === Org admins ===<br /> <br /> 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].<br /> <br /> === Mentors ===<br /> <br /> 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.<br /> <br /> The current list of prospective mentors can be found among the ideas listed below.<br /> <br /> === How to apply ===<br /> <br /> For students or contributors interested in applying to ns-3 for GSoC, please go through the following list to get started:<br /> * Read the official [https://developers.google.com/open-source/gsoc/resources/guide GSoC contributor guide].<br /> * Read [[GSOC2025ContributorGuide |ns-3's 2025 GSoC contributor guide]]<br /> * Look through our [[#Project Ideas]] below to see if you find a project that interests you.<br /> * Review the [https://www.nsnam.org/documentation/development-tree/ tutorial and contributing guide] thoroughly, if you have not already done so.<br /> * 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.<br /> * Next, proceed to get in touch with the developers on the mailing list or Zulip chat room and refine your proposal.<br /> * 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.<br /> <br /> 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.<br /> <br /> &lt;blockquote&gt;<br /> Each project idea within a particular priority has been tagged with the following properties:<br /> * ''Required Experience:'' Languages, concepts, or packages with which applicants must be familiar.<br /> * ''Bonus Experience:'' Other experience or familiarity which would be greatly helpful to applicants for this project.<br /> * ''Interests:'' Areas of particular relevance to this project, and an indicator of where successful contributors might apply their experiences coming out of this project.<br /> * ''Difficulty:'' easy, medium or difficult<br /> * ''Recommended reading:'' pointers to documentation, papers, specific bugs, etc.<br /> <br /> 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.<br /> &lt;/blockquote&gt;<br /> <br /> === Patch requirement guidelines ===<br /> <br /> 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.<br /> <br /> === Mentors: how to participate ===<br /> <br /> 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:<br /> <br /> * 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.<br /> * 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.<br /> * 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.<br /> <br /> == Project Ideas ==<br /> <br /> '''Note to contributors:''' These ideas are not listed in any priority order.<br /> 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.<br /> <br /> === Internet models enhancements ===<br /> <br /> * [[#Upgrade the AQM Evaluation Suite for ns-3]] (small size project, 90h)<br /> * [[#Implementation of Alternative Backoff with ECN (ABE)]] (small size project, 90h)<br /> * [[#ICMP socket and generate/handle ICMP messages (host/net unreachable)]] (medium size project, 175h)<br /> * [[#Linux-like Loss Detection Techniques for ns-3 TCP]] (medium size project, 175h)<br /> * [[#AODVv2 Protocol enhancements]] (medium size project, 175h)<br /> * [[#IPv6 global routing]] (large size project, 350h)<br /> * [[#Linux-like CAKE queue discipline for ns-3]] (large size project, 350h)<br /> * [[#Switched Ethernet]] (large size project, 350h)<br /> <br /> === IoT models enhancements ===<br /> <br /> * [[#6LoWPAN mesh-under routing enhancements]] (medium size project, 175h)<br /> * [[#6LoWPAN neighbor discovery protocol]] (medium size project, 175h)<br /> * [[#Mesh Link Establishment (MLE) protocol ]] (large size project, 350h)<br /> * [[#Lr-WPAN (IEEE 802.15.4) preamble detection support]] (large size project, 350h)<br /> <br /> === 5G NR models enhancements ===<br /> <br /> 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.<br /> <br /> * [[#NTN example for 5G NR]] (small size project, 90h)<br /> * [[#Enabling 5G NR examples visualization]] (medium size project, 175h)<br /> * [[#Improving 5G NR module usability through helpers]] (medium size project, 175h)<br /> * [[#5G NR module integration with ns-3-ai]] (large size project, 250h)<br /> <br /> == Small sized projects (90 hours) ==<br /> <br /> <br /> === NTN example for 5G NR ===<br /> <br /> 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]<br /> <br /> 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).<br /> <br /> 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.<br /> <br /> * Required Experience: C++ programming, understanding of 5G NR, LTE, and wireless networks<br /> * Interests: 5G NR simulations<br /> * Difficulty: Medium.<br /> * 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.<br /> <br /> === Upgrade the AQM Evaluation Suite for ns-3 ===<br /> <br /> Mentors: [mailto:tahiliani.nitk@gmail.com Mohit P. Tahiliani]<br /> <br /> 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.<br /> <br /> * ''Required Experience:'' Familiarity with AQM and C++ programming.<br /> * ''Bonus Experience:'' Familiarity with traffic control model in ns-3.<br /> * ''Interests:'' Packet Scheduling algorithms, AQM algorithms and ECN.<br /> * ''Difficulty:'' Medium.<br /> * ''Recommended Reading:''<br /> ** AQM Evaluation Suite [[https://dl.acm.org/doi/abs/10.1145/3067665.3067674 Paper]] [[https://aqm-eval-suite.github.io/ Implementation]]<br /> ** [https://tools.ietf.org/html/rfc7928 RFC 7928]<br /> ** [https://www.nsnam.org/docs/models/html/traffic-control-layer.html Traffic Control Model in ns-3]<br /> * ''Patch requirement:'' Create a pull request to handle the case when an incorrect Scenario name or number is passed via command line.<br /> <br /> === Implementation of Alternative Backoff with ECN (ABE) ===<br /> <br /> Mentors: [mailto:tahiliani.nitk@gmail.com Mohit P. Tahiliani]<br /> <br /> 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.<br /> <br /> * ''Required Experience:'' Familiarity with ECN and C++ programming.<br /> * ''Bonus Experience:'' Familiarity with traffic control model in ns-3.<br /> * ''Interests:'' Packet Scheduling algorithms, AQM algorithms and ECN.<br /> * ''Difficulty:'' Medium.<br /> * ''Recommended Reading:''<br /> ** Alternative Backoff with ECN [[https://datatracker.ietf.org/doc/rfc8511 RFC 8511]] [[http://heim.ifi.uio.no/~naeemk/research/ABE/Networking2017ABE.pdf Paper]]<br /> ** [https://www.nsnam.org/docs/models/html/tcp.html#support-for-explicit-congestion-notification-ecn ECN support in ns-3]<br /> ** [https://www.nsnam.org/docs/models/html/traffic-control-layer.html Traffic Control Model in ns-3]<br /> <br /> == Medium sized projects (175 hours) ==<br /> <br /> === ICMP socket and generate/handle ICMP messages (host/net unreachable) ===<br /> <br /> Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], [mailto:manoj24.rana@gmail.com Manoj K. Rana].<br /> <br /> 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 &quot;RAW&quot; socket.<br /> 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.<br /> <br /> 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.<br /> <br /> The most important point of the implementation should be code duplicate minimization, in order to have the minimize maintenance efforts.<br /> <br /> Once the sockets are in place, beside the &quot;normal&quot; tests, it will be necessary to modify the code that is actually made obsolete by the new sockets, e.g.:<br /> * IPv6 ICMP messages (RA, RS, NA, NS, etc.),<br /> * IPv4 ICMP messages,<br /> * ICMP Echo and ICMPv6 Echo messages.<br /> and to handle properly ICMP error messages like Destination Unreachable in the Ping application.<br /> <br /> * ''Required Experience:'' Fundamentals of IPv4 and IPv6 sockets, C++ programming.<br /> * ''Interests:'' Sockets and API interface implementation.<br /> * ''Difficulty:'' Medium.<br /> * ''Recommended reading:''<br /> ** [https://man7.org/linux/man-pages/man2/socket.2.html Linux socket]<br /> ** [https://courses.cs.vt.edu/cs4254/fall04/slides/raw_1.pdf Raw Sockets and ICMP, Srinidhi Varadarajan]<br /> ** [https://gitlab.com/nsnam/ns-3-dev/-/issues/810 Issue #810]<br /> <br /> Possible tasks to fulfill the patch requirement:<br /> * Submit a patch to fix [https://gitlab.com/nsnam/ns-3-dev/-/issues/809 Issue #809]<br /> <br /> === 6LoWPAN mesh-under routing enhancements ===<br /> <br /> Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], [TBD].<br /> <br /> 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.<br /> 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.<br /> <br /> The candidate should outline what parts of code are going to be affected, and how they can be enhanced thanks to RFC 7731.<br /> <br /> * ''Required Experience:'' Fundamentals of IPv6 addressing, C++ programming.<br /> * ''Bonus Experience:'' Familiarity with mesh routing and 6LoWPAN ns-3<br /> * ''Interests:'' IPv6 mesh routing<br /> * ''Difficulty:'' Easy.<br /> * ''Recommended reading:''<br /> ** [https://www.nsnam.org/docs/models/html/sixlowpan.html#mesh-under-routing Mesh-under in ns-3 6LoWPAN]<br /> ** [https://datatracker.ietf.org/doc/html/rfc7731 RFC 7731]<br /> <br /> Possible tasks to fulfill the patch requirement:<br /> * TBD<br /> <br /> === 6LoWPAN neighbor discovery protocol ===<br /> <br /> Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], [TBD].<br /> <br /> 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.<br /> <br /> 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).<br /> <br /> 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.<br /> <br /> * ''Required Experience:'' Fundamentals of IPv6 addressing, C++ programming.<br /> * ''Bonus Experience:'' Familiarity with 6LoWPAN and 6LoWPAN-ND<br /> * ''Interests:'' IPv6 and IoT networks<br /> * ''Difficulty:'' Easy.<br /> * ''Recommended reading:''<br /> ** [https://datatracker.ietf.org/doc/html/rfc8505 RFC 8505]<br /> ** [https://datatracker.ietf.org/doc/html/rfc6775 RFC 6775]<br /> ** [https://datatracker.ietf.org/doc/html/rfc4944 RFC 4944]<br /> <br /> Possible tasks to fulfil the patch requirement:<br /> * Patch the actual 6LoWPAN-ND to remove the limitation about concurrent address registrations.<br /> <br /> === Improving 5G NR module usability through helpers ===<br /> <br /> 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]<br /> <br /> 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.<br /> <br /> 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.<br /> <br /> * Required Experience: C++ programming, understanding of 5G NR, LTE, and wireless networks<br /> * Interests: 5G NR simulations<br /> * Difficulty: Medium.<br /> * 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.<br /> <br /> === Enabling 5G NR examples visualization ===<br /> <br /> 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]<br /> <br /> 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.<br /> <br /> 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.<br /> 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].<br /> <br /> * Required Experience: C++ and Python programming, understanding of 5G NR, LTE, and wireless networks<br /> * Interests: 5G NR simulations<br /> * Difficulty: Medium.<br /> * 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.<br /> <br /> === Linux-like Loss Detection Techniques for ns-3 TCP ===<br /> <br /> Mentors: [mailto:tahiliani.nitk@gmail.com Mohit P. Tahiliani]<br /> <br /> 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.<br /> <br /> * ''Required Experience:'' Familiarity with TCP and C++ programming.<br /> * ''Bonus Experience:'' Familiarity with TCP implementation in Linux kernel.<br /> * ''Interests:'' TCP packet loss detection techniques.<br /> * ''Difficulty:'' Medium to Hard.<br /> * ''Recommended Reading:''<br /> ** Forward Acknowledgement (FACK) [[https://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.41.2559&amp;rep=rep1&amp;type=pdf Paper]] [[https://gitlab.com/nsnam/ns-3-dev/-/merge_requests/34/commits Implementation]]<br /> ** Duplicate Selective Acknowledgment (DSACK) [[https://tools.ietf.org/html/rfc2883 RFC 2883]] [[https://gitlab.com/nsnam/ns-3-dev/-/merge_requests/34/commits Implementation]]<br /> ** RACK-TLP [[https://datatracker.ietf.org/doc/html/rfc8985 RFC 8985]] [[https://gitlab.com/nsnam/ns-3-dev/-/merge_requests/34/commits Implementation]]<br /> <br /> === AODVv2 Protocol enhancements ===<br /> <br /> Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], [TBD].<br /> <br /> 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.<br /> <br /> In particular the project should address the following points: 1) AODVv2 performances, 2) AODV address compression, 3) &quot;external&quot; network routing support, 4) general model validation against the latest draft.<br /> Collaboration with the draft authors is also highly suggested.<br /> <br /> * ''Required Experience:'' Fundamentals of IPv6 addressing, C++ programming.<br /> * ''Bonus Experience:'' Familiarity with AODV implementations in ns-3 and AODVv2<br /> * ''Interests:'' Ad hoc routing<br /> * ''Difficulty:'' Medium.<br /> * ''Recommended reading:''<br /> ** [https://www.nsnam.org/docs/models/html/ipv6.html IPv6 model in ns-3]<br /> ** [https://www.nsnam.org/docs/models/html/aodv.html AODV model in ns-3]<br /> ** [https://datatracker.ietf.org/doc/draft-perkins-manet-aodvv2/05/ Ad Hoc On-demand Distance Vector Version 2 (AODVv2) Routing]<br /> <br /> Possible tasks to fulfill the patch requirement:<br /> * [https://gitlab.com/nsnam/ns-3-dev/-/issues/368 Issue #368] - aodv: aodv parameters can be set to &quot;impossible&quot; values<br /> <br /> == Large projects (350 hours) ==<br /> <br /> === IPv6 global routing ===<br /> <br /> Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], [TBD].<br /> <br /> 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).<br /> For IPv4, ns-3 provides two alternatives: GlobalRouting, and NixRouting, which just &quot;do the trick&quot; - they simply fill the routing tables in intermediate nodes, GlobalRouting using an approach similar to OSPF, NixRouting by leveraging the &quot;abstract&quot; knowledge of the network.<br /> Neither actually use any message between the nodes, so they also reduce the network overhead - something that is useful in many cases.<br /> <br /> 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.).<br /> <br /> 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.<br /> <br /> * ''Required Experience:'' Fundamentals of IPv6 addressing, C++ programming.<br /> * ''Bonus Experience:'' Familiarity with GlobalRouting implementations in ns-3<br /> * ''Interests:'' IPv6 routing<br /> * ''Difficulty:'' Medium.<br /> * ''Recommended reading:''<br /> ** [https://www.nsnam.org/docs/models/html/ipv6.html IPv6 model in ns-3]<br /> ** [https://www.nsnam.org/docs/models/html/routing-overview.html#global-centralized-routing GlobalRouting model in ns-3]<br /> <br /> Possible tasks to fulfill the patch requirement:<br /> * 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.<br /> <br /> === Mesh Link Establishment (MLE) protocol ===<br /> <br /> Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], TBD.<br /> <br /> 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.<br /> However, MLE is being used in Thread, and it can be useful to implement it.<br /> <br /> 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.<br /> <br /> * ''Required Experience:'' Fundamentals of IPv4 and IPv6 sockets, C++ programming.<br /> * ''Interests:'' Sockets and API interface implementation.<br /> * ''Difficulty:'' Hard.<br /> * ''Recommended reading:''<br /> ** [https://datatracker.ietf.org/doc/html/draft-ietf-6lo-mesh-link-establishment MLE draft]<br /> ** [https://openthread.io/guides/thread-primer/network-discovery Thread primer]<br /> ** [https://www.threadgroup.org/ThreadSpec Thread specifications]<br /> <br /> Possible tasks to fulfill the patch requirement:<br /> * TBD, contact the mentors if interested.<br /> <br /> === Lr-WPAN (IEEE 802.15.4) preamble detection support ===<br /> <br /> Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], [mailto:alramonet@is.tokushima-u.ac.jp Alberto Gallegos Ramonet].<br /> <br /> 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<br /> 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<br /> itself has many added benefits.<br /> <br /> 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.<br /> <br /> As usual, reduction of code duplicity and a flexible scalable design is desired (e.g. Allow the inclusion of different preambles in the future).<br /> <br /> * ''Required Experience:'' Basic understanding of IEEE 802.15.4, C++ programming.<br /> * ''Bonus Experience:'' PHY process familiarity, Familiarity with ns-3's Lr-WPAN<br /> * ''Interests:'' Lr-WPAN, MAC and PHY designs<br /> * ''Difficulty:'' Medium.<br /> * ''Recommended reading:''<br /> ** [https://ieeexplore.ieee.org/document/1700009 IEEE 802.15.4-2006]<br /> ** [https://ieeexplore.ieee.org/document/7460875 IEEE 802.15.4-2015]<br /> ** [https://www.nsnam.org/docs/models/html/lr-wpan.html ns-3 lr-wpan module]<br /> <br /> Possible tasks to fulfill the patch requirement:<br /> * TBD, contact the mentors if interested.<br /> <br /> === 5G NR module integration with ns-3-ai ===<br /> <br /> 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]<br /> <br /> 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.<br /> <br /> 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.<br /> For more specific guidelines, please view this [https://docs.google.com/document/d/1cQLIF1cdft1yj3vyWrjrxN2xDJMx8PuWaa9NP_nKf64/edit?usp=sharing Google document].<br /> <br /> * Required Experience: C++ programming, understanding of 5G NR, LTE, and wireless networks<br /> * Interests: 5G NR simulations<br /> * Difficulty: Medium.<br /> * 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.<br /> <br /> === Linux-like CAKE queue discipline for ns-3 ===<br /> <br /> Mentors: [mailto:tahiliani.nitk@gmail.com Mohit P. Tahiliani]<br /> <br /> 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.<br /> <br /> * ''Required Experience:'' Familiarity with queue disciplines, TCP and C++ programming.<br /> * ''Bonus Experience:'' Familiarity with CAKE framework in Linux 4.19<br /> * ''Interests:'' Active Queue Management, Packet scheduling and TCP.<br /> * ''Difficulty:'' Medium to Hard<br /> * ''Recommended reading:''<br /> ** [https://arxiv.org/pdf/1804.07617.pdf Piece of CAKE: A Comprehensive Queue Management Solution for Home Gateways]<br /> ** [https://lwn.net/Articles/758353/ Let them run CAKE]<br /> ** [https://www.nsnam.org/docs/models/html/queue-discs.html Queue disciplines in ns-3]<br /> <br /> === Switched Ethernet ===<br /> <br /> Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], TBD.<br /> <br /> 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.<br /> <br /> 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.<br /> <br /> 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.<br /> <br /> 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.<br /> <br /> 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.<br /> <br /> * ''Required Experience:'' Fundamentals of Ethernet sitched networking, C++ programming.<br /> * ''Interests:'' Ethernet networks and switched data networks.<br /> * ''Difficulty:'' Medium.<br /> * ''Recommended reading:''<br /> ** [https://www2.nsnam.org/bugzilla/show_bug.cgi?id=2602 Basic implementation (very old)]<br /> ** [https://gitlab.com/nsnam/ns-3-dev/-/merge_requests/431 Full-duplex CSMA, somehow related]<br /> <br /> Possible tasks to fulfill the patch requirement:<br /> * TBD, contact the mentors if interested.</div>

Tommaso https://www.nsnam.org/mediawiki/index.php?title=GSOC2025Projects&diff=13452 2025-02-16T16:48:07Z

<p>Tommaso: /* Internet models enhancements */</p> <hr /> <div>{{TOC}}<br /> <br /> This page contains 2025 Google Summer of Code project ideas for ns-3.<br /> <br /> * [https://developers.google.com/open-source/gsoc/faq GSoC Frequently Asked Questions]<br /> * [[GSOC2025ContributorGuide | ns-3's 2025 GSoC Contributor guide]]<br /> * [https://developers.google.com/open-source/gsoc/resources/guide GSoC contributor/student guide (not ns-3 specific)]<br /> * [[GSOC2025ApplicationTemplate | 2025 GSoC Contributor application template]]<br /> * [[GSOCMentorGuide | ns-3's GSoC Mentor guide]]<br /> * [https://archive.flossmanuals.net/gsocmentoring/index.html GSoC Mentor guide (not ns-3 specific)]<br /> * [[GSOCSelectionProcess | GSoC Contributor Selection Process]]<br /> * ''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/<br /> <br /> === About the ns-3 project ===<br /> <br /> ns-3 is a discrete-event network simulator, with a particular emphasis on network research and education.<br /> <br /> 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.<br /> <br /> 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.<br /> <br /> === Org admins ===<br /> <br /> 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].<br /> <br /> === Mentors ===<br /> <br /> 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.<br /> <br /> The current list of prospective mentors can be found among the ideas listed below.<br /> <br /> === How to apply ===<br /> <br /> For students or contributors interested in applying to ns-3 for GSoC, please go through the following list to get started:<br /> * Read the official [https://developers.google.com/open-source/gsoc/resources/guide GSoC contributor guide].<br /> * Read [[GSOC2025ContributorGuide |ns-3's 2025 GSoC contributor guide]]<br /> * Look through our [[#Project Ideas]] below to see if you find a project that interests you.<br /> * Review the [https://www.nsnam.org/documentation/development-tree/ tutorial and contributing guide] thoroughly, if you have not already done so.<br /> * 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.<br /> * Next, proceed to get in touch with the developers on the mailing list or Zulip chat room and refine your proposal.<br /> * 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.<br /> <br /> 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.<br /> <br /> &lt;blockquote&gt;<br /> Each project idea within a particular priority has been tagged with the following properties:<br /> * ''Required Experience:'' Languages, concepts, or packages with which applicants must be familiar.<br /> * ''Bonus Experience:'' Other experience or familiarity which would be greatly helpful to applicants for this project.<br /> * ''Interests:'' Areas of particular relevance to this project, and an indicator of where successful contributors might apply their experiences coming out of this project.<br /> * ''Difficulty:'' easy, medium or difficult<br /> * ''Recommended reading:'' pointers to documentation, papers, specific bugs, etc.<br /> <br /> 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.<br /> &lt;/blockquote&gt;<br /> <br /> === Patch requirement guidelines ===<br /> <br /> 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.<br /> <br /> === Mentors: how to participate ===<br /> <br /> 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:<br /> <br /> * 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.<br /> * 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.<br /> * 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.<br /> <br /> == Project Ideas ==<br /> <br /> '''Note to contributors:''' These ideas are not listed in any priority order.<br /> 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.<br /> <br /> === Internet models enhancements ===<br /> <br /> * [[#Upgrade the AQM Evaluation Suite for ns-3]] (small size project, 90h)<br /> * [[#Implementation of Alternative Backoff with ECN (ABE)]] (small size project, 90h)<br /> * [[#ICMP socket and generate/handle ICMP messages (host/net unreachable)]] (medium size project, 175h)<br /> * [[#Linux-like Loss Detection Techniques for ns-3 TCP]] (medium size project, 175h)<br /> * [[#AODVv2 Protocol enhancements]] (medium size project, 175h)<br /> * [[#IPv6 global routing]] (large size project, 350h)<br /> * [[#IPv6 support in Ad hoc Routing Protocols]] (large size project, 350h)<br /> * [[#Linux-like CAKE queue discipline for ns-3]] (large size project, 350h)<br /> * [[#Switched Ethernet]] (large size project, 350h)<br /> <br /> === IoT models enhancements ===<br /> <br /> * [[#6LoWPAN mesh-under routing enhancements]] (medium size project, 175h)<br /> * [[#6LoWPAN neighbor discovery protocol]] (medium size project, 175h)<br /> * [[#Mesh Link Establishment (MLE) protocol ]] (large size project, 350h)<br /> * [[#Lr-WPAN (IEEE 802.15.4) preamble detection support]] (large size project, 350h)<br /> <br /> === 5G NR models enhancements ===<br /> <br /> 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.<br /> <br /> * [[#NTN example for 5G NR]] (small size project, 90h)<br /> * [[#Enabling 5G NR examples visualization]] (medium size project, 175h)<br /> * [[#Improving 5G NR module usability through helpers]] (medium size project, 175h)<br /> * [[#5G NR module integration with ns-3-ai]] (large size project, 250h)<br /> <br /> == Small sized projects (90 hours) ==<br /> <br /> <br /> === NTN example for 5G NR ===<br /> <br /> 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]<br /> <br /> 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).<br /> <br /> 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.<br /> <br /> * Required Experience: C++ programming, understanding of 5G NR, LTE, and wireless networks<br /> * Interests: 5G NR simulations<br /> * Difficulty: Medium.<br /> * 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.<br /> <br /> === Upgrade the AQM Evaluation Suite for ns-3 ===<br /> <br /> Mentors: [mailto:tahiliani.nitk@gmail.com Mohit P. Tahiliani]<br /> <br /> 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.<br /> <br /> * ''Required Experience:'' Familiarity with AQM and C++ programming.<br /> * ''Bonus Experience:'' Familiarity with traffic control model in ns-3.<br /> * ''Interests:'' Packet Scheduling algorithms, AQM algorithms and ECN.<br /> * ''Difficulty:'' Medium.<br /> * ''Recommended Reading:''<br /> ** AQM Evaluation Suite [[https://dl.acm.org/doi/abs/10.1145/3067665.3067674 Paper]] [[https://aqm-eval-suite.github.io/ Implementation]]<br /> ** [https://tools.ietf.org/html/rfc7928 RFC 7928]<br /> ** [https://www.nsnam.org/docs/models/html/traffic-control-layer.html Traffic Control Model in ns-3]<br /> * ''Patch requirement:'' Create a pull request to handle the case when an incorrect Scenario name or number is passed via command line.<br /> <br /> === Implementation of Alternative Backoff with ECN (ABE) ===<br /> <br /> Mentors: [mailto:tahiliani.nitk@gmail.com Mohit P. Tahiliani]<br /> <br /> 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.<br /> <br /> * ''Required Experience:'' Familiarity with ECN and C++ programming.<br /> * ''Bonus Experience:'' Familiarity with traffic control model in ns-3.<br /> * ''Interests:'' Packet Scheduling algorithms, AQM algorithms and ECN.<br /> * ''Difficulty:'' Medium.<br /> * ''Recommended Reading:''<br /> ** Alternative Backoff with ECN [[https://datatracker.ietf.org/doc/rfc8511 RFC 8511]] [[http://heim.ifi.uio.no/~naeemk/research/ABE/Networking2017ABE.pdf Paper]]<br /> ** [https://www.nsnam.org/docs/models/html/tcp.html#support-for-explicit-congestion-notification-ecn ECN support in ns-3]<br /> ** [https://www.nsnam.org/docs/models/html/traffic-control-layer.html Traffic Control Model in ns-3]<br /> <br /> == Medium sized projects (175 hours) ==<br /> <br /> === ICMP socket and generate/handle ICMP messages (host/net unreachable) ===<br /> <br /> Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], [mailto:manoj24.rana@gmail.com Manoj K. Rana].<br /> <br /> 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 &quot;RAW&quot; socket.<br /> 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.<br /> <br /> 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.<br /> <br /> The most important point of the implementation should be code duplicate minimization, in order to have the minimize maintenance efforts.<br /> <br /> Once the sockets are in place, beside the &quot;normal&quot; tests, it will be necessary to modify the code that is actually made obsolete by the new sockets, e.g.:<br /> * IPv6 ICMP messages (RA, RS, NA, NS, etc.),<br /> * IPv4 ICMP messages,<br /> * ICMP Echo and ICMPv6 Echo messages.<br /> and to handle properly ICMP error messages like Destination Unreachable in the Ping application.<br /> <br /> * ''Required Experience:'' Fundamentals of IPv4 and IPv6 sockets, C++ programming.<br /> * ''Interests:'' Sockets and API interface implementation.<br /> * ''Difficulty:'' Medium.<br /> * ''Recommended reading:''<br /> ** [https://man7.org/linux/man-pages/man2/socket.2.html Linux socket]<br /> ** [https://courses.cs.vt.edu/cs4254/fall04/slides/raw_1.pdf Raw Sockets and ICMP, Srinidhi Varadarajan]<br /> ** [https://gitlab.com/nsnam/ns-3-dev/-/issues/810 Issue #810]<br /> <br /> Possible tasks to fulfill the patch requirement:<br /> * Submit a patch to fix [https://gitlab.com/nsnam/ns-3-dev/-/issues/809 Issue #809]<br /> <br /> === 6LoWPAN mesh-under routing enhancements ===<br /> <br /> Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], [TBD].<br /> <br /> 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.<br /> 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.<br /> <br /> The candidate should outline what parts of code are going to be affected, and how they can be enhanced thanks to RFC 7731.<br /> <br /> * ''Required Experience:'' Fundamentals of IPv6 addressing, C++ programming.<br /> * ''Bonus Experience:'' Familiarity with mesh routing and 6LoWPAN ns-3<br /> * ''Interests:'' IPv6 mesh routing<br /> * ''Difficulty:'' Easy.<br /> * ''Recommended reading:''<br /> ** [https://www.nsnam.org/docs/models/html/sixlowpan.html#mesh-under-routing Mesh-under in ns-3 6LoWPAN]<br /> ** [https://datatracker.ietf.org/doc/html/rfc7731 RFC 7731]<br /> <br /> Possible tasks to fulfill the patch requirement:<br /> * TBD<br /> <br /> === 6LoWPAN neighbor discovery protocol ===<br /> <br /> Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], [TBD].<br /> <br /> 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.<br /> <br /> 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).<br /> <br /> 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.<br /> <br /> * ''Required Experience:'' Fundamentals of IPv6 addressing, C++ programming.<br /> * ''Bonus Experience:'' Familiarity with 6LoWPAN and 6LoWPAN-ND<br /> * ''Interests:'' IPv6 and IoT networks<br /> * ''Difficulty:'' Easy.<br /> * ''Recommended reading:''<br /> ** [https://datatracker.ietf.org/doc/html/rfc8505 RFC 8505]<br /> ** [https://datatracker.ietf.org/doc/html/rfc6775 RFC 6775]<br /> ** [https://datatracker.ietf.org/doc/html/rfc4944 RFC 4944]<br /> <br /> Possible tasks to fulfil the patch requirement:<br /> * Patch the actual 6LoWPAN-ND to remove the limitation about concurrent address registrations.<br /> <br /> === Improving 5G NR module usability through helpers ===<br /> <br /> 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]<br /> <br /> 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.<br /> <br /> 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.<br /> <br /> * Required Experience: C++ programming, understanding of 5G NR, LTE, and wireless networks<br /> * Interests: 5G NR simulations<br /> * Difficulty: Medium.<br /> * 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.<br /> <br /> === Enabling 5G NR examples visualization ===<br /> <br /> 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]<br /> <br /> 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.<br /> <br /> 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.<br /> 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].<br /> <br /> * Required Experience: C++ and Python programming, understanding of 5G NR, LTE, and wireless networks<br /> * Interests: 5G NR simulations<br /> * Difficulty: Medium.<br /> * 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.<br /> <br /> === Linux-like Loss Detection Techniques for ns-3 TCP ===<br /> <br /> Mentors: [mailto:tahiliani.nitk@gmail.com Mohit P. Tahiliani]<br /> <br /> 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.<br /> <br /> * ''Required Experience:'' Familiarity with TCP and C++ programming.<br /> * ''Bonus Experience:'' Familiarity with TCP implementation in Linux kernel.<br /> * ''Interests:'' TCP packet loss detection techniques.<br /> * ''Difficulty:'' Medium to Hard.<br /> * ''Recommended Reading:''<br /> ** Forward Acknowledgement (FACK) [[https://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.41.2559&amp;rep=rep1&amp;type=pdf Paper]] [[https://gitlab.com/nsnam/ns-3-dev/-/merge_requests/34/commits Implementation]]<br /> ** Duplicate Selective Acknowledgment (DSACK) [[https://tools.ietf.org/html/rfc2883 RFC 2883]] [[https://gitlab.com/nsnam/ns-3-dev/-/merge_requests/34/commits Implementation]]<br /> ** RACK-TLP [[https://datatracker.ietf.org/doc/html/rfc8985 RFC 8985]] [[https://gitlab.com/nsnam/ns-3-dev/-/merge_requests/34/commits Implementation]]<br /> <br /> === AODVv2 Protocol enhancements ===<br /> <br /> Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], [TBD].<br /> <br /> 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.<br /> <br /> In particular the project should address the following points: 1) AODVv2 performances, 2) AODV address compression, 3) &quot;external&quot; network routing support, 4) general model validation against the latest draft.<br /> Collaboration with the draft authors is also highly suggested.<br /> <br /> * ''Required Experience:'' Fundamentals of IPv6 addressing, C++ programming.<br /> * ''Bonus Experience:'' Familiarity with AODV implementations in ns-3 and AODVv2<br /> * ''Interests:'' Ad hoc routing<br /> * ''Difficulty:'' Medium.<br /> * ''Recommended reading:''<br /> ** [https://www.nsnam.org/docs/models/html/ipv6.html IPv6 model in ns-3]<br /> ** [https://www.nsnam.org/docs/models/html/aodv.html AODV model in ns-3]<br /> ** [https://datatracker.ietf.org/doc/draft-perkins-manet-aodvv2/05/ Ad Hoc On-demand Distance Vector Version 2 (AODVv2) Routing]<br /> <br /> Possible tasks to fulfill the patch requirement:<br /> * [https://gitlab.com/nsnam/ns-3-dev/-/issues/368 Issue #368] - aodv: aodv parameters can be set to &quot;impossible&quot; values<br /> <br /> == Large projects (350 hours) ==<br /> <br /> === IPv6 global routing ===<br /> <br /> Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], [TBD].<br /> <br /> 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).<br /> For IPv4, ns-3 provides two alternatives: GlobalRouting, and NixRouting, which just &quot;do the trick&quot; - they simply fill the routing tables in intermediate nodes, GlobalRouting using an approach similar to OSPF, NixRouting by leveraging the &quot;abstract&quot; knowledge of the network.<br /> Neither actually use any message between the nodes, so they also reduce the network overhead - something that is useful in many cases.<br /> <br /> 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.).<br /> <br /> 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.<br /> <br /> * ''Required Experience:'' Fundamentals of IPv6 addressing, C++ programming.<br /> * ''Bonus Experience:'' Familiarity with GlobalRouting implementations in ns-3<br /> * ''Interests:'' IPv6 routing<br /> * ''Difficulty:'' Medium.<br /> * ''Recommended reading:''<br /> ** [https://www.nsnam.org/docs/models/html/ipv6.html IPv6 model in ns-3]<br /> ** [https://www.nsnam.org/docs/models/html/routing-overview.html#global-centralized-routing GlobalRouting model in ns-3]<br /> <br /> Possible tasks to fulfill the patch requirement:<br /> * 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.<br /> <br /> === Mesh Link Establishment (MLE) protocol ===<br /> <br /> Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], TBD.<br /> <br /> 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.<br /> However, MLE is being used in Thread, and it can be useful to implement it.<br /> <br /> 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.<br /> <br /> * ''Required Experience:'' Fundamentals of IPv4 and IPv6 sockets, C++ programming.<br /> * ''Interests:'' Sockets and API interface implementation.<br /> * ''Difficulty:'' Hard.<br /> * ''Recommended reading:''<br /> ** [https://datatracker.ietf.org/doc/html/draft-ietf-6lo-mesh-link-establishment MLE draft]<br /> ** [https://openthread.io/guides/thread-primer/network-discovery Thread primer]<br /> ** [https://www.threadgroup.org/ThreadSpec Thread specifications]<br /> <br /> Possible tasks to fulfill the patch requirement:<br /> * TBD, contact the mentors if interested.<br /> <br /> === Lr-WPAN (IEEE 802.15.4) preamble detection support ===<br /> <br /> Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], [mailto:alramonet@is.tokushima-u.ac.jp Alberto Gallegos Ramonet].<br /> <br /> 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<br /> 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<br /> itself has many added benefits.<br /> <br /> 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.<br /> <br /> As usual, reduction of code duplicity and a flexible scalable design is desired (e.g. Allow the inclusion of different preambles in the future).<br /> <br /> * ''Required Experience:'' Basic understanding of IEEE 802.15.4, C++ programming.<br /> * ''Bonus Experience:'' PHY process familiarity, Familiarity with ns-3's Lr-WPAN<br /> * ''Interests:'' Lr-WPAN, MAC and PHY designs<br /> * ''Difficulty:'' Medium.<br /> * ''Recommended reading:''<br /> ** [https://ieeexplore.ieee.org/document/1700009 IEEE 802.15.4-2006]<br /> ** [https://ieeexplore.ieee.org/document/7460875 IEEE 802.15.4-2015]<br /> ** [https://www.nsnam.org/docs/models/html/lr-wpan.html ns-3 lr-wpan module]<br /> <br /> Possible tasks to fulfill the patch requirement:<br /> * TBD, contact the mentors if interested.<br /> <br /> === 5G NR module integration with ns-3-ai ===<br /> <br /> 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]<br /> <br /> 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.<br /> <br /> 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.<br /> For more specific guidelines, please view this [https://docs.google.com/document/d/1cQLIF1cdft1yj3vyWrjrxN2xDJMx8PuWaa9NP_nKf64/edit?usp=sharing Google document].<br /> <br /> * Required Experience: C++ programming, understanding of 5G NR, LTE, and wireless networks<br /> * Interests: 5G NR simulations<br /> * Difficulty: Medium.<br /> * 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.<br /> <br /> === Linux-like CAKE queue discipline for ns-3 ===<br /> <br /> Mentors: [mailto:tahiliani.nitk@gmail.com Mohit P. Tahiliani]<br /> <br /> 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.<br /> <br /> * ''Required Experience:'' Familiarity with queue disciplines, TCP and C++ programming.<br /> * ''Bonus Experience:'' Familiarity with CAKE framework in Linux 4.19<br /> * ''Interests:'' Active Queue Management, Packet scheduling and TCP.<br /> * ''Difficulty:'' Medium to Hard<br /> * ''Recommended reading:''<br /> ** [https://arxiv.org/pdf/1804.07617.pdf Piece of CAKE: A Comprehensive Queue Management Solution for Home Gateways]<br /> ** [https://lwn.net/Articles/758353/ Let them run CAKE]<br /> ** [https://www.nsnam.org/docs/models/html/queue-discs.html Queue disciplines in ns-3]<br /> <br /> === Switched Ethernet ===<br /> <br /> Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], TBD.<br /> <br /> 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.<br /> <br /> 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.<br /> <br /> 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.<br /> <br /> 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.<br /> <br /> 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.<br /> <br /> * ''Required Experience:'' Fundamentals of Ethernet sitched networking, C++ programming.<br /> * ''Interests:'' Ethernet networks and switched data networks.<br /> * ''Difficulty:'' Medium.<br /> * ''Recommended reading:''<br /> ** [https://www2.nsnam.org/bugzilla/show_bug.cgi?id=2602 Basic implementation (very old)]<br /> ** [https://gitlab.com/nsnam/ns-3-dev/-/merge_requests/431 Full-duplex CSMA, somehow related]<br /> <br /> Possible tasks to fulfill the patch requirement:<br /> * TBD, contact the mentors if interested.</div>

Tommaso https://www.nsnam.org/mediawiki/index.php?title=GSOC2025Projects&diff=13451 2025-02-16T16:47:12Z

<p>Tommaso: /* Large projects (350 hours) */</p> <hr /> <div>{{TOC}}<br /> <br /> This page contains 2025 Google Summer of Code project ideas for ns-3.<br /> <br /> * [https://developers.google.com/open-source/gsoc/faq GSoC Frequently Asked Questions]<br /> * [[GSOC2025ContributorGuide | ns-3's 2025 GSoC Contributor guide]]<br /> * [https://developers.google.com/open-source/gsoc/resources/guide GSoC contributor/student guide (not ns-3 specific)]<br /> * [[GSOC2025ApplicationTemplate | 2025 GSoC Contributor application template]]<br /> * [[GSOCMentorGuide | ns-3's GSoC Mentor guide]]<br /> * [https://archive.flossmanuals.net/gsocmentoring/index.html GSoC Mentor guide (not ns-3 specific)]<br /> * [[GSOCSelectionProcess | GSoC Contributor Selection Process]]<br /> * ''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/<br /> <br /> === About the ns-3 project ===<br /> <br /> ns-3 is a discrete-event network simulator, with a particular emphasis on network research and education.<br /> <br /> 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.<br /> <br /> 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.<br /> <br /> === Org admins ===<br /> <br /> 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].<br /> <br /> === Mentors ===<br /> <br /> 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.<br /> <br /> The current list of prospective mentors can be found among the ideas listed below.<br /> <br /> === How to apply ===<br /> <br /> For students or contributors interested in applying to ns-3 for GSoC, please go through the following list to get started:<br /> * Read the official [https://developers.google.com/open-source/gsoc/resources/guide GSoC contributor guide].<br /> * Read [[GSOC2025ContributorGuide |ns-3's 2025 GSoC contributor guide]]<br /> * Look through our [[#Project Ideas]] below to see if you find a project that interests you.<br /> * Review the [https://www.nsnam.org/documentation/development-tree/ tutorial and contributing guide] thoroughly, if you have not already done so.<br /> * 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.<br /> * Next, proceed to get in touch with the developers on the mailing list or Zulip chat room and refine your proposal.<br /> * 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.<br /> <br /> 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.<br /> <br /> &lt;blockquote&gt;<br /> Each project idea within a particular priority has been tagged with the following properties:<br /> * ''Required Experience:'' Languages, concepts, or packages with which applicants must be familiar.<br /> * ''Bonus Experience:'' Other experience or familiarity which would be greatly helpful to applicants for this project.<br /> * ''Interests:'' Areas of particular relevance to this project, and an indicator of where successful contributors might apply their experiences coming out of this project.<br /> * ''Difficulty:'' easy, medium or difficult<br /> * ''Recommended reading:'' pointers to documentation, papers, specific bugs, etc.<br /> <br /> 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.<br /> &lt;/blockquote&gt;<br /> <br /> === Patch requirement guidelines ===<br /> <br /> 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.<br /> <br /> === Mentors: how to participate ===<br /> <br /> 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:<br /> <br /> * 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.<br /> * 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.<br /> * 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.<br /> <br /> == Project Ideas ==<br /> <br /> '''Note to contributors:''' These ideas are not listed in any priority order.<br /> 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.<br /> <br /> === Internet models enhancements ===<br /> <br /> * [[#Upgrade the AQM Evaluation Suite for ns-3]] (small size project, 90h)<br /> * [[#Implementation of Alternative Backoff with ECN (ABE)]] (small size project, 90h)<br /> * [[#ICMP socket and generate/handle ICMP messages (host/net unreachable)]] (medium size project, 175h)<br /> * [[#Linux-like Loss Detection Techniques for ns-3 TCP]] (medium size project, 175h)<br /> * [[#AODVv2 Protocol enhancements]] (medium size project, 175h)<br /> * [[#IPv6 global routing]] (large size project, 350h)<br /> * [[#IPv6 support in Ad hoc Routing Protocols]] (large size project, 350h)<br /> * [[#Linux-like CAKE queue discipline for ns-3]] (large size project, 350h)<br /> <br /> === IoT models enhancements ===<br /> <br /> * [[#6LoWPAN mesh-under routing enhancements]] (medium size project, 175h)<br /> * [[#6LoWPAN neighbor discovery protocol]] (medium size project, 175h)<br /> * [[#Mesh Link Establishment (MLE) protocol ]] (large size project, 350h)<br /> * [[#Lr-WPAN (IEEE 802.15.4) preamble detection support]] (large size project, 350h)<br /> <br /> === 5G NR models enhancements ===<br /> <br /> 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.<br /> <br /> * [[#NTN example for 5G NR]] (small size project, 90h)<br /> * [[#Enabling 5G NR examples visualization]] (medium size project, 175h)<br /> * [[#Improving 5G NR module usability through helpers]] (medium size project, 175h)<br /> * [[#5G NR module integration with ns-3-ai]] (large size project, 250h)<br /> <br /> == Small sized projects (90 hours) ==<br /> <br /> <br /> === NTN example for 5G NR ===<br /> <br /> 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]<br /> <br /> 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).<br /> <br /> 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.<br /> <br /> * Required Experience: C++ programming, understanding of 5G NR, LTE, and wireless networks<br /> * Interests: 5G NR simulations<br /> * Difficulty: Medium.<br /> * 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.<br /> <br /> === Upgrade the AQM Evaluation Suite for ns-3 ===<br /> <br /> Mentors: [mailto:tahiliani.nitk@gmail.com Mohit P. Tahiliani]<br /> <br /> 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.<br /> <br /> * ''Required Experience:'' Familiarity with AQM and C++ programming.<br /> * ''Bonus Experience:'' Familiarity with traffic control model in ns-3.<br /> * ''Interests:'' Packet Scheduling algorithms, AQM algorithms and ECN.<br /> * ''Difficulty:'' Medium.<br /> * ''Recommended Reading:''<br /> ** AQM Evaluation Suite [[https://dl.acm.org/doi/abs/10.1145/3067665.3067674 Paper]] [[https://aqm-eval-suite.github.io/ Implementation]]<br /> ** [https://tools.ietf.org/html/rfc7928 RFC 7928]<br /> ** [https://www.nsnam.org/docs/models/html/traffic-control-layer.html Traffic Control Model in ns-3]<br /> * ''Patch requirement:'' Create a pull request to handle the case when an incorrect Scenario name or number is passed via command line.<br /> <br /> === Implementation of Alternative Backoff with ECN (ABE) ===<br /> <br /> Mentors: [mailto:tahiliani.nitk@gmail.com Mohit P. Tahiliani]<br /> <br /> 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.<br /> <br /> * ''Required Experience:'' Familiarity with ECN and C++ programming.<br /> * ''Bonus Experience:'' Familiarity with traffic control model in ns-3.<br /> * ''Interests:'' Packet Scheduling algorithms, AQM algorithms and ECN.<br /> * ''Difficulty:'' Medium.<br /> * ''Recommended Reading:''<br /> ** Alternative Backoff with ECN [[https://datatracker.ietf.org/doc/rfc8511 RFC 8511]] [[http://heim.ifi.uio.no/~naeemk/research/ABE/Networking2017ABE.pdf Paper]]<br /> ** [https://www.nsnam.org/docs/models/html/tcp.html#support-for-explicit-congestion-notification-ecn ECN support in ns-3]<br /> ** [https://www.nsnam.org/docs/models/html/traffic-control-layer.html Traffic Control Model in ns-3]<br /> <br /> == Medium sized projects (175 hours) ==<br /> <br /> === ICMP socket and generate/handle ICMP messages (host/net unreachable) ===<br /> <br /> Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], [mailto:manoj24.rana@gmail.com Manoj K. Rana].<br /> <br /> 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 &quot;RAW&quot; socket.<br /> 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.<br /> <br /> 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.<br /> <br /> The most important point of the implementation should be code duplicate minimization, in order to have the minimize maintenance efforts.<br /> <br /> Once the sockets are in place, beside the &quot;normal&quot; tests, it will be necessary to modify the code that is actually made obsolete by the new sockets, e.g.:<br /> * IPv6 ICMP messages (RA, RS, NA, NS, etc.),<br /> * IPv4 ICMP messages,<br /> * ICMP Echo and ICMPv6 Echo messages.<br /> and to handle properly ICMP error messages like Destination Unreachable in the Ping application.<br /> <br /> * ''Required Experience:'' Fundamentals of IPv4 and IPv6 sockets, C++ programming.<br /> * ''Interests:'' Sockets and API interface implementation.<br /> * ''Difficulty:'' Medium.<br /> * ''Recommended reading:''<br /> ** [https://man7.org/linux/man-pages/man2/socket.2.html Linux socket]<br /> ** [https://courses.cs.vt.edu/cs4254/fall04/slides/raw_1.pdf Raw Sockets and ICMP, Srinidhi Varadarajan]<br /> ** [https://gitlab.com/nsnam/ns-3-dev/-/issues/810 Issue #810]<br /> <br /> Possible tasks to fulfill the patch requirement:<br /> * Submit a patch to fix [https://gitlab.com/nsnam/ns-3-dev/-/issues/809 Issue #809]<br /> <br /> === 6LoWPAN mesh-under routing enhancements ===<br /> <br /> Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], [TBD].<br /> <br /> 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.<br /> 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.<br /> <br /> The candidate should outline what parts of code are going to be affected, and how they can be enhanced thanks to RFC 7731.<br /> <br /> * ''Required Experience:'' Fundamentals of IPv6 addressing, C++ programming.<br /> * ''Bonus Experience:'' Familiarity with mesh routing and 6LoWPAN ns-3<br /> * ''Interests:'' IPv6 mesh routing<br /> * ''Difficulty:'' Easy.<br /> * ''Recommended reading:''<br /> ** [https://www.nsnam.org/docs/models/html/sixlowpan.html#mesh-under-routing Mesh-under in ns-3 6LoWPAN]<br /> ** [https://datatracker.ietf.org/doc/html/rfc7731 RFC 7731]<br /> <br /> Possible tasks to fulfill the patch requirement:<br /> * TBD<br /> <br /> === 6LoWPAN neighbor discovery protocol ===<br /> <br /> Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], [TBD].<br /> <br /> 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.<br /> <br /> 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).<br /> <br /> 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.<br /> <br /> * ''Required Experience:'' Fundamentals of IPv6 addressing, C++ programming.<br /> * ''Bonus Experience:'' Familiarity with 6LoWPAN and 6LoWPAN-ND<br /> * ''Interests:'' IPv6 and IoT networks<br /> * ''Difficulty:'' Easy.<br /> * ''Recommended reading:''<br /> ** [https://datatracker.ietf.org/doc/html/rfc8505 RFC 8505]<br /> ** [https://datatracker.ietf.org/doc/html/rfc6775 RFC 6775]<br /> ** [https://datatracker.ietf.org/doc/html/rfc4944 RFC 4944]<br /> <br /> Possible tasks to fulfil the patch requirement:<br /> * Patch the actual 6LoWPAN-ND to remove the limitation about concurrent address registrations.<br /> <br /> === Improving 5G NR module usability through helpers ===<br /> <br /> 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]<br /> <br /> 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.<br /> <br /> 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.<br /> <br /> * Required Experience: C++ programming, understanding of 5G NR, LTE, and wireless networks<br /> * Interests: 5G NR simulations<br /> * Difficulty: Medium.<br /> * 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.<br /> <br /> === Enabling 5G NR examples visualization ===<br /> <br /> 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]<br /> <br /> 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.<br /> <br /> 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.<br /> 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].<br /> <br /> * Required Experience: C++ and Python programming, understanding of 5G NR, LTE, and wireless networks<br /> * Interests: 5G NR simulations<br /> * Difficulty: Medium.<br /> * 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.<br /> <br /> === Linux-like Loss Detection Techniques for ns-3 TCP ===<br /> <br /> Mentors: [mailto:tahiliani.nitk@gmail.com Mohit P. Tahiliani]<br /> <br /> 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.<br /> <br /> * ''Required Experience:'' Familiarity with TCP and C++ programming.<br /> * ''Bonus Experience:'' Familiarity with TCP implementation in Linux kernel.<br /> * ''Interests:'' TCP packet loss detection techniques.<br /> * ''Difficulty:'' Medium to Hard.<br /> * ''Recommended Reading:''<br /> ** Forward Acknowledgement (FACK) [[https://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.41.2559&amp;rep=rep1&amp;type=pdf Paper]] [[https://gitlab.com/nsnam/ns-3-dev/-/merge_requests/34/commits Implementation]]<br /> ** Duplicate Selective Acknowledgment (DSACK) [[https://tools.ietf.org/html/rfc2883 RFC 2883]] [[https://gitlab.com/nsnam/ns-3-dev/-/merge_requests/34/commits Implementation]]<br /> ** RACK-TLP [[https://datatracker.ietf.org/doc/html/rfc8985 RFC 8985]] [[https://gitlab.com/nsnam/ns-3-dev/-/merge_requests/34/commits Implementation]]<br /> <br /> === AODVv2 Protocol enhancements ===<br /> <br /> Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], [TBD].<br /> <br /> 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.<br /> <br /> In particular the project should address the following points: 1) AODVv2 performances, 2) AODV address compression, 3) &quot;external&quot; network routing support, 4) general model validation against the latest draft.<br /> Collaboration with the draft authors is also highly suggested.<br /> <br /> * ''Required Experience:'' Fundamentals of IPv6 addressing, C++ programming.<br /> * ''Bonus Experience:'' Familiarity with AODV implementations in ns-3 and AODVv2<br /> * ''Interests:'' Ad hoc routing<br /> * ''Difficulty:'' Medium.<br /> * ''Recommended reading:''<br /> ** [https://www.nsnam.org/docs/models/html/ipv6.html IPv6 model in ns-3]<br /> ** [https://www.nsnam.org/docs/models/html/aodv.html AODV model in ns-3]<br /> ** [https://datatracker.ietf.org/doc/draft-perkins-manet-aodvv2/05/ Ad Hoc On-demand Distance Vector Version 2 (AODVv2) Routing]<br /> <br /> Possible tasks to fulfill the patch requirement:<br /> * [https://gitlab.com/nsnam/ns-3-dev/-/issues/368 Issue #368] - aodv: aodv parameters can be set to &quot;impossible&quot; values<br /> <br /> == Large projects (350 hours) ==<br /> <br /> === IPv6 global routing ===<br /> <br /> Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], [TBD].<br /> <br /> 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).<br /> For IPv4, ns-3 provides two alternatives: GlobalRouting, and NixRouting, which just &quot;do the trick&quot; - they simply fill the routing tables in intermediate nodes, GlobalRouting using an approach similar to OSPF, NixRouting by leveraging the &quot;abstract&quot; knowledge of the network.<br /> Neither actually use any message between the nodes, so they also reduce the network overhead - something that is useful in many cases.<br /> <br /> 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.).<br /> <br /> 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.<br /> <br /> * ''Required Experience:'' Fundamentals of IPv6 addressing, C++ programming.<br /> * ''Bonus Experience:'' Familiarity with GlobalRouting implementations in ns-3<br /> * ''Interests:'' IPv6 routing<br /> * ''Difficulty:'' Medium.<br /> * ''Recommended reading:''<br /> ** [https://www.nsnam.org/docs/models/html/ipv6.html IPv6 model in ns-3]<br /> ** [https://www.nsnam.org/docs/models/html/routing-overview.html#global-centralized-routing GlobalRouting model in ns-3]<br /> <br /> Possible tasks to fulfill the patch requirement:<br /> * 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.<br /> <br /> === Mesh Link Establishment (MLE) protocol ===<br /> <br /> Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], TBD.<br /> <br /> 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.<br /> However, MLE is being used in Thread, and it can be useful to implement it.<br /> <br /> 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.<br /> <br /> * ''Required Experience:'' Fundamentals of IPv4 and IPv6 sockets, C++ programming.<br /> * ''Interests:'' Sockets and API interface implementation.<br /> * ''Difficulty:'' Hard.<br /> * ''Recommended reading:''<br /> ** [https://datatracker.ietf.org/doc/html/draft-ietf-6lo-mesh-link-establishment MLE draft]<br /> ** [https://openthread.io/guides/thread-primer/network-discovery Thread primer]<br /> ** [https://www.threadgroup.org/ThreadSpec Thread specifications]<br /> <br /> Possible tasks to fulfill the patch requirement:<br /> * TBD, contact the mentors if interested.<br /> <br /> === Lr-WPAN (IEEE 802.15.4) preamble detection support ===<br /> <br /> Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], [mailto:alramonet@is.tokushima-u.ac.jp Alberto Gallegos Ramonet].<br /> <br /> 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<br /> 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<br /> itself has many added benefits.<br /> <br /> 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.<br /> <br /> As usual, reduction of code duplicity and a flexible scalable design is desired (e.g. Allow the inclusion of different preambles in the future).<br /> <br /> * ''Required Experience:'' Basic understanding of IEEE 802.15.4, C++ programming.<br /> * ''Bonus Experience:'' PHY process familiarity, Familiarity with ns-3's Lr-WPAN<br /> * ''Interests:'' Lr-WPAN, MAC and PHY designs<br /> * ''Difficulty:'' Medium.<br /> * ''Recommended reading:''<br /> ** [https://ieeexplore.ieee.org/document/1700009 IEEE 802.15.4-2006]<br /> ** [https://ieeexplore.ieee.org/document/7460875 IEEE 802.15.4-2015]<br /> ** [https://www.nsnam.org/docs/models/html/lr-wpan.html ns-3 lr-wpan module]<br /> <br /> Possible tasks to fulfill the patch requirement:<br /> * TBD, contact the mentors if interested.<br /> <br /> === 5G NR module integration with ns-3-ai ===<br /> <br /> 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]<br /> <br /> 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.<br /> <br /> 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.<br /> For more specific guidelines, please view this [https://docs.google.com/document/d/1cQLIF1cdft1yj3vyWrjrxN2xDJMx8PuWaa9NP_nKf64/edit?usp=sharing Google document].<br /> <br /> * Required Experience: C++ programming, understanding of 5G NR, LTE, and wireless networks<br /> * Interests: 5G NR simulations<br /> * Difficulty: Medium.<br /> * 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.<br /> <br /> === Linux-like CAKE queue discipline for ns-3 ===<br /> <br /> Mentors: [mailto:tahiliani.nitk@gmail.com Mohit P. Tahiliani]<br /> <br /> 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.<br /> <br /> * ''Required Experience:'' Familiarity with queue disciplines, TCP and C++ programming.<br /> * ''Bonus Experience:'' Familiarity with CAKE framework in Linux 4.19<br /> * ''Interests:'' Active Queue Management, Packet scheduling and TCP.<br /> * ''Difficulty:'' Medium to Hard<br /> * ''Recommended reading:''<br /> ** [https://arxiv.org/pdf/1804.07617.pdf Piece of CAKE: A Comprehensive Queue Management Solution for Home Gateways]<br /> ** [https://lwn.net/Articles/758353/ Let them run CAKE]<br /> ** [https://www.nsnam.org/docs/models/html/queue-discs.html Queue disciplines in ns-3]<br /> <br /> === Switched Ethernet ===<br /> <br /> Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], TBD.<br /> <br /> 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.<br /> <br /> 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.<br /> <br /> 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.<br /> <br /> 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.<br /> <br /> 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.<br /> <br /> * ''Required Experience:'' Fundamentals of Ethernet sitched networking, C++ programming.<br /> * ''Interests:'' Ethernet networks and switched data networks.<br /> * ''Difficulty:'' Medium.<br /> * ''Recommended reading:''<br /> ** [https://www2.nsnam.org/bugzilla/show_bug.cgi?id=2602 Basic implementation (very old)]<br /> ** [https://gitlab.com/nsnam/ns-3-dev/-/merge_requests/431 Full-duplex CSMA, somehow related]<br /> <br /> Possible tasks to fulfill the patch requirement:<br /> * TBD, contact the mentors if interested.</div>

Tommaso https://www.nsnam.org/mediawiki/index.php?title=GSOC2025Projects&diff=13450 2025-02-16T16:06:49Z

<p>Tommaso: /* Medium sized projects (175 hours) */</p> <hr /> <div>{{TOC}}<br /> <br /> This page contains 2025 Google Summer of Code project ideas for ns-3.<br /> <br /> * [https://developers.google.com/open-source/gsoc/faq GSoC Frequently Asked Questions]<br /> * [[GSOC2025ContributorGuide | ns-3's 2025 GSoC Contributor guide]]<br /> * [https://developers.google.com/open-source/gsoc/resources/guide GSoC contributor/student guide (not ns-3 specific)]<br /> * [[GSOC2025ApplicationTemplate | 2025 GSoC Contributor application template]]<br /> * [[GSOCMentorGuide | ns-3's GSoC Mentor guide]]<br /> * [https://archive.flossmanuals.net/gsocmentoring/index.html GSoC Mentor guide (not ns-3 specific)]<br /> * [[GSOCSelectionProcess | GSoC Contributor Selection Process]]<br /> * ''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/<br /> <br /> === About the ns-3 project ===<br /> <br /> ns-3 is a discrete-event network simulator, with a particular emphasis on network research and education.<br /> <br /> 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.<br /> <br /> 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.<br /> <br /> === Org admins ===<br /> <br /> 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].<br /> <br /> === Mentors ===<br /> <br /> 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.<br /> <br /> The current list of prospective mentors can be found among the ideas listed below.<br /> <br /> === How to apply ===<br /> <br /> For students or contributors interested in applying to ns-3 for GSoC, please go through the following list to get started:<br /> * Read the official [https://developers.google.com/open-source/gsoc/resources/guide GSoC contributor guide].<br /> * Read [[GSOC2025ContributorGuide |ns-3's 2025 GSoC contributor guide]]<br /> * Look through our [[#Project Ideas]] below to see if you find a project that interests you.<br /> * Review the [https://www.nsnam.org/documentation/development-tree/ tutorial and contributing guide] thoroughly, if you have not already done so.<br /> * 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.<br /> * Next, proceed to get in touch with the developers on the mailing list or Zulip chat room and refine your proposal.<br /> * 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.<br /> <br /> 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.<br /> <br /> &lt;blockquote&gt;<br /> Each project idea within a particular priority has been tagged with the following properties:<br /> * ''Required Experience:'' Languages, concepts, or packages with which applicants must be familiar.<br /> * ''Bonus Experience:'' Other experience or familiarity which would be greatly helpful to applicants for this project.<br /> * ''Interests:'' Areas of particular relevance to this project, and an indicator of where successful contributors might apply their experiences coming out of this project.<br /> * ''Difficulty:'' easy, medium or difficult<br /> * ''Recommended reading:'' pointers to documentation, papers, specific bugs, etc.<br /> <br /> 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.<br /> &lt;/blockquote&gt;<br /> <br /> === Patch requirement guidelines ===<br /> <br /> 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.<br /> <br /> === Mentors: how to participate ===<br /> <br /> 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:<br /> <br /> * 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.<br /> * 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.<br /> * 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.<br /> <br /> == Project Ideas ==<br /> <br /> '''Note to contributors:''' These ideas are not listed in any priority order.<br /> 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.<br /> <br /> === Internet models enhancements ===<br /> <br /> * [[#Upgrade the AQM Evaluation Suite for ns-3]] (small size project, 90h)<br /> * [[#Implementation of Alternative Backoff with ECN (ABE)]] (small size project, 90h)<br /> * [[#ICMP socket and generate/handle ICMP messages (host/net unreachable)]] (medium size project, 175h)<br /> * [[#Linux-like Loss Detection Techniques for ns-3 TCP]] (medium size project, 175h)<br /> * [[#AODVv2 Protocol enhancements]] (medium size project, 175h)<br /> * [[#IPv6 global routing]] (large size project, 350h)<br /> * [[#IPv6 support in Ad hoc Routing Protocols]] (large size project, 350h)<br /> * [[#Linux-like CAKE queue discipline for ns-3]] (large size project, 350h)<br /> <br /> === IoT models enhancements ===<br /> <br /> * [[#6LoWPAN mesh-under routing enhancements]] (medium size project, 175h)<br /> * [[#6LoWPAN neighbor discovery protocol]] (medium size project, 175h)<br /> * [[#Mesh Link Establishment (MLE) protocol ]] (large size project, 350h)<br /> * [[#Lr-WPAN (IEEE 802.15.4) preamble detection support]] (large size project, 350h)<br /> <br /> === 5G NR models enhancements ===<br /> <br /> 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.<br /> <br /> * [[#NTN example for 5G NR]] (small size project, 90h)<br /> * [[#Enabling 5G NR examples visualization]] (medium size project, 175h)<br /> * [[#Improving 5G NR module usability through helpers]] (medium size project, 175h)<br /> * [[#5G NR module integration with ns-3-ai]] (large size project, 250h)<br /> <br /> == Small sized projects (90 hours) ==<br /> <br /> <br /> === NTN example for 5G NR ===<br /> <br /> 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]<br /> <br /> 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).<br /> <br /> 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.<br /> <br /> * Required Experience: C++ programming, understanding of 5G NR, LTE, and wireless networks<br /> * Interests: 5G NR simulations<br /> * Difficulty: Medium.<br /> * 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.<br /> <br /> === Upgrade the AQM Evaluation Suite for ns-3 ===<br /> <br /> Mentors: [mailto:tahiliani.nitk@gmail.com Mohit P. Tahiliani]<br /> <br /> 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.<br /> <br /> * ''Required Experience:'' Familiarity with AQM and C++ programming.<br /> * ''Bonus Experience:'' Familiarity with traffic control model in ns-3.<br /> * ''Interests:'' Packet Scheduling algorithms, AQM algorithms and ECN.<br /> * ''Difficulty:'' Medium.<br /> * ''Recommended Reading:''<br /> ** AQM Evaluation Suite [[https://dl.acm.org/doi/abs/10.1145/3067665.3067674 Paper]] [[https://aqm-eval-suite.github.io/ Implementation]]<br /> ** [https://tools.ietf.org/html/rfc7928 RFC 7928]<br /> ** [https://www.nsnam.org/docs/models/html/traffic-control-layer.html Traffic Control Model in ns-3]<br /> * ''Patch requirement:'' Create a pull request to handle the case when an incorrect Scenario name or number is passed via command line.<br /> <br /> === Implementation of Alternative Backoff with ECN (ABE) ===<br /> <br /> Mentors: [mailto:tahiliani.nitk@gmail.com Mohit P. Tahiliani]<br /> <br /> 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.<br /> <br /> * ''Required Experience:'' Familiarity with ECN and C++ programming.<br /> * ''Bonus Experience:'' Familiarity with traffic control model in ns-3.<br /> * ''Interests:'' Packet Scheduling algorithms, AQM algorithms and ECN.<br /> * ''Difficulty:'' Medium.<br /> * ''Recommended Reading:''<br /> ** Alternative Backoff with ECN [[https://datatracker.ietf.org/doc/rfc8511 RFC 8511]] [[http://heim.ifi.uio.no/~naeemk/research/ABE/Networking2017ABE.pdf Paper]]<br /> ** [https://www.nsnam.org/docs/models/html/tcp.html#support-for-explicit-congestion-notification-ecn ECN support in ns-3]<br /> ** [https://www.nsnam.org/docs/models/html/traffic-control-layer.html Traffic Control Model in ns-3]<br /> <br /> == Medium sized projects (175 hours) ==<br /> <br /> === ICMP socket and generate/handle ICMP messages (host/net unreachable) ===<br /> <br /> Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], [mailto:manoj24.rana@gmail.com Manoj K. Rana].<br /> <br /> 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 &quot;RAW&quot; socket.<br /> 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.<br /> <br /> 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.<br /> <br /> The most important point of the implementation should be code duplicate minimization, in order to have the minimize maintenance efforts.<br /> <br /> Once the sockets are in place, beside the &quot;normal&quot; tests, it will be necessary to modify the code that is actually made obsolete by the new sockets, e.g.:<br /> * IPv6 ICMP messages (RA, RS, NA, NS, etc.),<br /> * IPv4 ICMP messages,<br /> * ICMP Echo and ICMPv6 Echo messages.<br /> and to handle properly ICMP error messages like Destination Unreachable in the Ping application.<br /> <br /> * ''Required Experience:'' Fundamentals of IPv4 and IPv6 sockets, C++ programming.<br /> * ''Interests:'' Sockets and API interface implementation.<br /> * ''Difficulty:'' Medium.<br /> * ''Recommended reading:''<br /> ** [https://man7.org/linux/man-pages/man2/socket.2.html Linux socket]<br /> ** [https://courses.cs.vt.edu/cs4254/fall04/slides/raw_1.pdf Raw Sockets and ICMP, Srinidhi Varadarajan]<br /> ** [https://gitlab.com/nsnam/ns-3-dev/-/issues/810 Issue #810]<br /> <br /> Possible tasks to fulfill the patch requirement:<br /> * Submit a patch to fix [https://gitlab.com/nsnam/ns-3-dev/-/issues/809 Issue #809]<br /> <br /> === 6LoWPAN mesh-under routing enhancements ===<br /> <br /> Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], [TBD].<br /> <br /> 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.<br /> 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.<br /> <br /> The candidate should outline what parts of code are going to be affected, and how they can be enhanced thanks to RFC 7731.<br /> <br /> * ''Required Experience:'' Fundamentals of IPv6 addressing, C++ programming.<br /> * ''Bonus Experience:'' Familiarity with mesh routing and 6LoWPAN ns-3<br /> * ''Interests:'' IPv6 mesh routing<br /> * ''Difficulty:'' Easy.<br /> * ''Recommended reading:''<br /> ** [https://www.nsnam.org/docs/models/html/sixlowpan.html#mesh-under-routing Mesh-under in ns-3 6LoWPAN]<br /> ** [https://datatracker.ietf.org/doc/html/rfc7731 RFC 7731]<br /> <br /> Possible tasks to fulfill the patch requirement:<br /> * TBD<br /> <br /> === 6LoWPAN neighbor discovery protocol ===<br /> <br /> Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], [TBD].<br /> <br /> 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.<br /> <br /> 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).<br /> <br /> 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.<br /> <br /> * ''Required Experience:'' Fundamentals of IPv6 addressing, C++ programming.<br /> * ''Bonus Experience:'' Familiarity with 6LoWPAN and 6LoWPAN-ND<br /> * ''Interests:'' IPv6 and IoT networks<br /> * ''Difficulty:'' Easy.<br /> * ''Recommended reading:''<br /> ** [https://datatracker.ietf.org/doc/html/rfc8505 RFC 8505]<br /> ** [https://datatracker.ietf.org/doc/html/rfc6775 RFC 6775]<br /> ** [https://datatracker.ietf.org/doc/html/rfc4944 RFC 4944]<br /> <br /> Possible tasks to fulfil the patch requirement:<br /> * Patch the actual 6LoWPAN-ND to remove the limitation about concurrent address registrations.<br /> <br /> === Improving 5G NR module usability through helpers ===<br /> <br /> 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]<br /> <br /> 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.<br /> <br /> 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.<br /> <br /> * Required Experience: C++ programming, understanding of 5G NR, LTE, and wireless networks<br /> * Interests: 5G NR simulations<br /> * Difficulty: Medium.<br /> * 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.<br /> <br /> === Enabling 5G NR examples visualization ===<br /> <br /> 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]<br /> <br /> 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.<br /> <br /> 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.<br /> 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].<br /> <br /> * Required Experience: C++ and Python programming, understanding of 5G NR, LTE, and wireless networks<br /> * Interests: 5G NR simulations<br /> * Difficulty: Medium.<br /> * 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.<br /> <br /> === Linux-like Loss Detection Techniques for ns-3 TCP ===<br /> <br /> Mentors: [mailto:tahiliani.nitk@gmail.com Mohit P. Tahiliani]<br /> <br /> 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.<br /> <br /> * ''Required Experience:'' Familiarity with TCP and C++ programming.<br /> * ''Bonus Experience:'' Familiarity with TCP implementation in Linux kernel.<br /> * ''Interests:'' TCP packet loss detection techniques.<br /> * ''Difficulty:'' Medium to Hard.<br /> * ''Recommended Reading:''<br /> ** Forward Acknowledgement (FACK) [[https://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.41.2559&amp;rep=rep1&amp;type=pdf Paper]] [[https://gitlab.com/nsnam/ns-3-dev/-/merge_requests/34/commits Implementation]]<br /> ** Duplicate Selective Acknowledgment (DSACK) [[https://tools.ietf.org/html/rfc2883 RFC 2883]] [[https://gitlab.com/nsnam/ns-3-dev/-/merge_requests/34/commits Implementation]]<br /> ** RACK-TLP [[https://datatracker.ietf.org/doc/html/rfc8985 RFC 8985]] [[https://gitlab.com/nsnam/ns-3-dev/-/merge_requests/34/commits Implementation]]<br /> <br /> === AODVv2 Protocol enhancements ===<br /> <br /> Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], [TBD].<br /> <br /> 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.<br /> <br /> In particular the project should address the following points: 1) AODVv2 performances, 2) AODV address compression, 3) &quot;external&quot; network routing support, 4) general model validation against the latest draft.<br /> Collaboration with the draft authors is also highly suggested.<br /> <br /> * ''Required Experience:'' Fundamentals of IPv6 addressing, C++ programming.<br /> * ''Bonus Experience:'' Familiarity with AODV implementations in ns-3 and AODVv2<br /> * ''Interests:'' Ad hoc routing<br /> * ''Difficulty:'' Medium.<br /> * ''Recommended reading:''<br /> ** [https://www.nsnam.org/docs/models/html/ipv6.html IPv6 model in ns-3]<br /> ** [https://www.nsnam.org/docs/models/html/aodv.html AODV model in ns-3]<br /> ** [https://datatracker.ietf.org/doc/draft-perkins-manet-aodvv2/05/ Ad Hoc On-demand Distance Vector Version 2 (AODVv2) Routing]<br /> <br /> Possible tasks to fulfill the patch requirement:<br /> * [https://gitlab.com/nsnam/ns-3-dev/-/issues/368 Issue #368] - aodv: aodv parameters can be set to &quot;impossible&quot; values<br /> <br /> == Large projects (350 hours) ==<br /> <br /> === IPv6 global routing ===<br /> <br /> Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], [TBD].<br /> <br /> 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).<br /> For IPv4, ns-3 provides two alternatives: GlobalRouting, and NixRouting, which just &quot;do the trick&quot; - they simply fill the routing tables in intermediate nodes, GlobalRouting using an approach similar to OSPF, NixRouting by leveraging the &quot;abstract&quot; knowledge of the network.<br /> Neither actually use any message between the nodes, so they also reduce the network overhead - something that is useful in many cases.<br /> <br /> 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.).<br /> <br /> 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.<br /> <br /> * ''Required Experience:'' Fundamentals of IPv6 addressing, C++ programming.<br /> * ''Bonus Experience:'' Familiarity with GlobalRouting implementations in ns-3<br /> * ''Interests:'' IPv6 routing<br /> * ''Difficulty:'' Medium.<br /> * ''Recommended reading:''<br /> ** [https://www.nsnam.org/docs/models/html/ipv6.html IPv6 model in ns-3]<br /> ** [https://www.nsnam.org/docs/models/html/routing-overview.html#global-centralized-routing GlobalRouting model in ns-3]<br /> <br /> Possible tasks to fulfill the patch requirement:<br /> * 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.<br /> <br /> === Mesh Link Establishment (MLE) protocol ===<br /> <br /> Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], TBD.<br /> <br /> 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.<br /> However, MLE is being used in Thread, and it can be useful to implement it.<br /> <br /> 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.<br /> <br /> * ''Required Experience:'' Fundamentals of IPv4 and IPv6 sockets, C++ programming.<br /> * ''Interests:'' Sockets and API interface implementation.<br /> * ''Difficulty:'' Hard.<br /> * ''Recommended reading:''<br /> ** [https://datatracker.ietf.org/doc/html/draft-ietf-6lo-mesh-link-establishment MLE draft]<br /> ** [https://openthread.io/guides/thread-primer/network-discovery Thread primer]<br /> ** [https://www.threadgroup.org/ThreadSpec Thread specifications]<br /> <br /> Possible tasks to fulfill the patch requirement:<br /> * TBD, contact the mentors if interested.<br /> <br /> === Lr-WPAN (IEEE 802.15.4) preamble detection support ===<br /> <br /> Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], [mailto:alramonet@is.tokushima-u.ac.jp Alberto Gallegos Ramonet].<br /> <br /> 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<br /> 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<br /> itself has many added benefits.<br /> <br /> 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.<br /> <br /> As usual, reduction of code duplicity and a flexible scalable design is desired (e.g. Allow the inclusion of different preambles in the future).<br /> <br /> * ''Required Experience:'' Basic understanding of IEEE 802.15.4, C++ programming.<br /> * ''Bonus Experience:'' PHY process familiarity, Familiarity with ns-3's Lr-WPAN<br /> * ''Interests:'' Lr-WPAN, MAC and PHY designs<br /> * ''Difficulty:'' Medium.<br /> * ''Recommended reading:''<br /> ** [https://ieeexplore.ieee.org/document/1700009 IEEE 802.15.4-2006]<br /> ** [https://ieeexplore.ieee.org/document/7460875 IEEE 802.15.4-2015]<br /> ** [https://www.nsnam.org/docs/models/html/lr-wpan.html ns-3 lr-wpan module]<br /> <br /> Possible tasks to fulfill the patch requirement:<br /> * TBD, contact the mentors if interested.<br /> <br /> === 5G NR module integration with ns-3-ai ===<br /> <br /> 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]<br /> <br /> 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.<br /> <br /> 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.<br /> For more specific guidelines, please view this [https://docs.google.com/document/d/1cQLIF1cdft1yj3vyWrjrxN2xDJMx8PuWaa9NP_nKf64/edit?usp=sharing Google document].<br /> <br /> * Required Experience: C++ programming, understanding of 5G NR, LTE, and wireless networks<br /> * Interests: 5G NR simulations<br /> * Difficulty: Medium.<br /> * 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.<br /> <br /> === Linux-like CAKE queue discipline for ns-3 ===<br /> <br /> Mentors: [mailto:tahiliani.nitk@gmail.com Mohit P. Tahiliani]<br /> <br /> 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.<br /> <br /> * ''Required Experience:'' Familiarity with queue disciplines, TCP and C++ programming.<br /> * ''Bonus Experience:'' Familiarity with CAKE framework in Linux 4.19<br /> * ''Interests:'' Active Queue Management, Packet scheduling and TCP.<br /> * ''Difficulty:'' Medium to Hard<br /> * ''Recommended reading:''<br /> ** [https://arxiv.org/pdf/1804.07617.pdf Piece of CAKE: A Comprehensive Queue Management Solution for Home Gateways]<br /> ** [https://lwn.net/Articles/758353/ Let them run CAKE]<br /> ** [https://www.nsnam.org/docs/models/html/queue-discs.html Queue disciplines in ns-3]</div>

Tommaso https://www.nsnam.org/mediawiki/index.php?title=GSOC2025Projects&diff=13449 2025-02-16T16:06:35Z

<p>Tommaso: /* Large projects (350 hours) */</p> <hr /> <div>{{TOC}}<br /> <br /> This page contains 2025 Google Summer of Code project ideas for ns-3.<br /> <br /> * [https://developers.google.com/open-source/gsoc/faq GSoC Frequently Asked Questions]<br /> * [[GSOC2025ContributorGuide | ns-3's 2025 GSoC Contributor guide]]<br /> * [https://developers.google.com/open-source/gsoc/resources/guide GSoC contributor/student guide (not ns-3 specific)]<br /> * [[GSOC2025ApplicationTemplate | 2025 GSoC Contributor application template]]<br /> * [[GSOCMentorGuide | ns-3's GSoC Mentor guide]]<br /> * [https://archive.flossmanuals.net/gsocmentoring/index.html GSoC Mentor guide (not ns-3 specific)]<br /> * [[GSOCSelectionProcess | GSoC Contributor Selection Process]]<br /> * ''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/<br /> <br /> === About the ns-3 project ===<br /> <br /> ns-3 is a discrete-event network simulator, with a particular emphasis on network research and education.<br /> <br /> 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.<br /> <br /> 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.<br /> <br /> === Org admins ===<br /> <br /> 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].<br /> <br /> === Mentors ===<br /> <br /> 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.<br /> <br /> The current list of prospective mentors can be found among the ideas listed below.<br /> <br /> === How to apply ===<br /> <br /> For students or contributors interested in applying to ns-3 for GSoC, please go through the following list to get started:<br /> * Read the official [https://developers.google.com/open-source/gsoc/resources/guide GSoC contributor guide].<br /> * Read [[GSOC2025ContributorGuide |ns-3's 2025 GSoC contributor guide]]<br /> * Look through our [[#Project Ideas]] below to see if you find a project that interests you.<br /> * Review the [https://www.nsnam.org/documentation/development-tree/ tutorial and contributing guide] thoroughly, if you have not already done so.<br /> * 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.<br /> * Next, proceed to get in touch with the developers on the mailing list or Zulip chat room and refine your proposal.<br /> * 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.<br /> <br /> 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.<br /> <br /> &lt;blockquote&gt;<br /> Each project idea within a particular priority has been tagged with the following properties:<br /> * ''Required Experience:'' Languages, concepts, or packages with which applicants must be familiar.<br /> * ''Bonus Experience:'' Other experience or familiarity which would be greatly helpful to applicants for this project.<br /> * ''Interests:'' Areas of particular relevance to this project, and an indicator of where successful contributors might apply their experiences coming out of this project.<br /> * ''Difficulty:'' easy, medium or difficult<br /> * ''Recommended reading:'' pointers to documentation, papers, specific bugs, etc.<br /> <br /> 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.<br /> &lt;/blockquote&gt;<br /> <br /> === Patch requirement guidelines ===<br /> <br /> 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.<br /> <br /> === Mentors: how to participate ===<br /> <br /> 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:<br /> <br /> * 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.<br /> * 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.<br /> * 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.<br /> <br /> == Project Ideas ==<br /> <br /> '''Note to contributors:''' These ideas are not listed in any priority order.<br /> 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.<br /> <br /> === Internet models enhancements ===<br /> <br /> * [[#Upgrade the AQM Evaluation Suite for ns-3]] (small size project, 90h)<br /> * [[#Implementation of Alternative Backoff with ECN (ABE)]] (small size project, 90h)<br /> * [[#ICMP socket and generate/handle ICMP messages (host/net unreachable)]] (medium size project, 175h)<br /> * [[#Linux-like Loss Detection Techniques for ns-3 TCP]] (medium size project, 175h)<br /> * [[#AODVv2 Protocol enhancements]] (medium size project, 175h)<br /> * [[#IPv6 global routing]] (large size project, 350h)<br /> * [[#IPv6 support in Ad hoc Routing Protocols]] (large size project, 350h)<br /> * [[#Linux-like CAKE queue discipline for ns-3]] (large size project, 350h)<br /> <br /> === IoT models enhancements ===<br /> <br /> * [[#6LoWPAN mesh-under routing enhancements]] (medium size project, 175h)<br /> * [[#6LoWPAN neighbor discovery protocol]] (medium size project, 175h)<br /> * [[#Mesh Link Establishment (MLE) protocol ]] (large size project, 350h)<br /> * [[#Lr-WPAN (IEEE 802.15.4) preamble detection support]] (large size project, 350h)<br /> <br /> === 5G NR models enhancements ===<br /> <br /> 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.<br /> <br /> * [[#NTN example for 5G NR]] (small size project, 90h)<br /> * [[#Enabling 5G NR examples visualization]] (medium size project, 175h)<br /> * [[#Improving 5G NR module usability through helpers]] (medium size project, 175h)<br /> * [[#5G NR module integration with ns-3-ai]] (large size project, 250h)<br /> <br /> == Small sized projects (90 hours) ==<br /> <br /> <br /> === NTN example for 5G NR ===<br /> <br /> 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]<br /> <br /> 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).<br /> <br /> 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.<br /> <br /> * Required Experience: C++ programming, understanding of 5G NR, LTE, and wireless networks<br /> * Interests: 5G NR simulations<br /> * Difficulty: Medium.<br /> * 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.<br /> <br /> === Upgrade the AQM Evaluation Suite for ns-3 ===<br /> <br /> Mentors: [mailto:tahiliani.nitk@gmail.com Mohit P. Tahiliani]<br /> <br /> 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.<br /> <br /> * ''Required Experience:'' Familiarity with AQM and C++ programming.<br /> * ''Bonus Experience:'' Familiarity with traffic control model in ns-3.<br /> * ''Interests:'' Packet Scheduling algorithms, AQM algorithms and ECN.<br /> * ''Difficulty:'' Medium.<br /> * ''Recommended Reading:''<br /> ** AQM Evaluation Suite [[https://dl.acm.org/doi/abs/10.1145/3067665.3067674 Paper]] [[https://aqm-eval-suite.github.io/ Implementation]]<br /> ** [https://tools.ietf.org/html/rfc7928 RFC 7928]<br /> ** [https://www.nsnam.org/docs/models/html/traffic-control-layer.html Traffic Control Model in ns-3]<br /> * ''Patch requirement:'' Create a pull request to handle the case when an incorrect Scenario name or number is passed via command line.<br /> <br /> === Implementation of Alternative Backoff with ECN (ABE) ===<br /> <br /> Mentors: [mailto:tahiliani.nitk@gmail.com Mohit P. Tahiliani]<br /> <br /> 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.<br /> <br /> * ''Required Experience:'' Familiarity with ECN and C++ programming.<br /> * ''Bonus Experience:'' Familiarity with traffic control model in ns-3.<br /> * ''Interests:'' Packet Scheduling algorithms, AQM algorithms and ECN.<br /> * ''Difficulty:'' Medium.<br /> * ''Recommended Reading:''<br /> ** Alternative Backoff with ECN [[https://datatracker.ietf.org/doc/rfc8511 RFC 8511]] [[http://heim.ifi.uio.no/~naeemk/research/ABE/Networking2017ABE.pdf Paper]]<br /> ** [https://www.nsnam.org/docs/models/html/tcp.html#support-for-explicit-congestion-notification-ecn ECN support in ns-3]<br /> ** [https://www.nsnam.org/docs/models/html/traffic-control-layer.html Traffic Control Model in ns-3]<br /> <br /> == Medium sized projects (175 hours) ==<br /> <br /> === ICMP socket and generate/handle ICMP messages (host/net unreachable) ===<br /> <br /> Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], [mailto:manoj24.rana@gmail.com Manoj K. Rana].<br /> <br /> 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 &quot;RAW&quot; socket.<br /> 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.<br /> <br /> 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.<br /> <br /> The most important point of the implementation should be code duplicate minimization, in order to have the minimize maintenance efforts.<br /> <br /> Once the sockets are in place, beside the &quot;normal&quot; tests, it will be necessary to modify the code that is actually made obsolete by the new sockets, e.g.:<br /> * IPv6 ICMP messages (RA, RS, NA, NS, etc.),<br /> * IPv4 ICMP messages,<br /> * ICMP Echo and ICMPv6 Echo messages.<br /> and to handle properly ICMP error messages like Destination Unreachable in the Ping application.<br /> <br /> * ''Required Experience:'' Fundamentals of IPv4 and IPv6 sockets, C++ programming.<br /> * ''Interests:'' Sockets and API interface implementation.<br /> * ''Difficulty:'' Medium.<br /> * ''Recommended reading:''<br /> ** [https://man7.org/linux/man-pages/man2/socket.2.html Linux socket]<br /> ** [https://courses.cs.vt.edu/cs4254/fall04/slides/raw_1.pdf Raw Sockets and ICMP, Srinidhi Varadarajan]<br /> ** [https://gitlab.com/nsnam/ns-3-dev/-/issues/810 Issue #810]<br /> <br /> Possible tasks to fulfill the patch requirement:<br /> * Submit a patch to fix [https://gitlab.com/nsnam/ns-3-dev/-/issues/809 Issue #809]<br /> <br /> === 6LoWPAN mesh-under routing enhancements ===<br /> <br /> Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], [TBD].<br /> <br /> 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.<br /> 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.<br /> <br /> The candidate should outline what parts of code are going to be affected, and how they can be enhanced thanks to RFC 7731.<br /> <br /> * ''Required Experience:'' Fundamentals of IPv6 addressing, C++ programming.<br /> * ''Bonus Experience:'' Familiarity with mesh routing and 6LoWPAN ns-3<br /> * ''Interests:'' IPv6 mesh routing<br /> * ''Difficulty:'' Easy.<br /> * ''Recommended reading:''<br /> ** [https://www.nsnam.org/docs/models/html/sixlowpan.html#mesh-under-routing Mesh-under in ns-3 6LoWPAN]<br /> ** [https://datatracker.ietf.org/doc/html/rfc7731 RFC 7731]<br /> <br /> Possible tasks to fulfill the patch requirement:<br /> * TBD<br /> <br /> === 6LoWPAN neighbor discovery protocol ===<br /> <br /> Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], [TBD].<br /> <br /> 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.<br /> <br /> 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).<br /> <br /> 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.<br /> <br /> * ''Required Experience:'' Fundamentals of IPv6 addressing, C++ programming.<br /> * ''Bonus Experience:'' Familiarity with 6LoWPAN and 6LoWPAN-ND<br /> * ''Interests:'' IPv6 and IoT networks<br /> * ''Difficulty:'' Easy.<br /> * ''Recommended reading:''<br /> ** [https://datatracker.ietf.org/doc/html/rfc8505 RFC 8505]<br /> ** [https://datatracker.ietf.org/doc/html/rfc6775 RFC 6775]<br /> ** [https://datatracker.ietf.org/doc/html/rfc4944 RFC 4944]<br /> <br /> Possible tasks to fulfil the patch requirement:<br /> * Patch the actual 6LoWPAN-ND to remove the limitation about concurrent address registrations.<br /> <br /> === Improving 5G NR module usability through helpers ===<br /> <br /> 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]<br /> <br /> 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.<br /> <br /> 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.<br /> <br /> * Required Experience: C++ programming, understanding of 5G NR, LTE, and wireless networks<br /> * Interests: 5G NR simulations<br /> * Difficulty: Medium.<br /> * 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.<br /> <br /> === Enabling 5G NR examples visualization ===<br /> <br /> 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]<br /> <br /> 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.<br /> <br /> 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.<br /> 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].<br /> <br /> * Required Experience: C++ and Python programming, understanding of 5G NR, LTE, and wireless networks<br /> * Interests: 5G NR simulations<br /> * Difficulty: Medium.<br /> * 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.<br /> <br /> === Linux-like Loss Detection Techniques for ns-3 TCP ===<br /> <br /> Mentors: [mailto:tahiliani.nitk@gmail.com Mohit P. Tahiliani]<br /> <br /> 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.<br /> <br /> * ''Required Experience:'' Familiarity with TCP and C++ programming.<br /> * ''Bonus Experience:'' Familiarity with TCP implementation in Linux kernel.<br /> * ''Interests:'' TCP packet loss detection techniques.<br /> * ''Difficulty:'' Medium to Hard.<br /> * ''Recommended Reading:''<br /> ** Forward Acknowledgement (FACK) [[https://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.41.2559&amp;rep=rep1&amp;type=pdf Paper]] [[https://gitlab.com/nsnam/ns-3-dev/-/merge_requests/34/commits Implementation]]<br /> ** Duplicate Selective Acknowledgment (DSACK) [[https://tools.ietf.org/html/rfc2883 RFC 2883]] [[https://gitlab.com/nsnam/ns-3-dev/-/merge_requests/34/commits Implementation]]<br /> ** RACK-TLP [[https://datatracker.ietf.org/doc/html/rfc8985 RFC 8985]] [[https://gitlab.com/nsnam/ns-3-dev/-/merge_requests/34/commits Implementation]]<br /> <br /> == Large projects (350 hours) ==<br /> <br /> === IPv6 global routing ===<br /> <br /> Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], [TBD].<br /> <br /> 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).<br /> For IPv4, ns-3 provides two alternatives: GlobalRouting, and NixRouting, which just &quot;do the trick&quot; - they simply fill the routing tables in intermediate nodes, GlobalRouting using an approach similar to OSPF, NixRouting by leveraging the &quot;abstract&quot; knowledge of the network.<br /> Neither actually use any message between the nodes, so they also reduce the network overhead - something that is useful in many cases.<br /> <br /> 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.).<br /> <br /> 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.<br /> <br /> * ''Required Experience:'' Fundamentals of IPv6 addressing, C++ programming.<br /> * ''Bonus Experience:'' Familiarity with GlobalRouting implementations in ns-3<br /> * ''Interests:'' IPv6 routing<br /> * ''Difficulty:'' Medium.<br /> * ''Recommended reading:''<br /> ** [https://www.nsnam.org/docs/models/html/ipv6.html IPv6 model in ns-3]<br /> ** [https://www.nsnam.org/docs/models/html/routing-overview.html#global-centralized-routing GlobalRouting model in ns-3]<br /> <br /> Possible tasks to fulfill the patch requirement:<br /> * 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.<br /> <br /> === Mesh Link Establishment (MLE) protocol ===<br /> <br /> Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], TBD.<br /> <br /> 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.<br /> However, MLE is being used in Thread, and it can be useful to implement it.<br /> <br /> 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.<br /> <br /> * ''Required Experience:'' Fundamentals of IPv4 and IPv6 sockets, C++ programming.<br /> * ''Interests:'' Sockets and API interface implementation.<br /> * ''Difficulty:'' Hard.<br /> * ''Recommended reading:''<br /> ** [https://datatracker.ietf.org/doc/html/draft-ietf-6lo-mesh-link-establishment MLE draft]<br /> ** [https://openthread.io/guides/thread-primer/network-discovery Thread primer]<br /> ** [https://www.threadgroup.org/ThreadSpec Thread specifications]<br /> <br /> Possible tasks to fulfill the patch requirement:<br /> * TBD, contact the mentors if interested.<br /> <br /> === Lr-WPAN (IEEE 802.15.4) preamble detection support ===<br /> <br /> Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], [mailto:alramonet@is.tokushima-u.ac.jp Alberto Gallegos Ramonet].<br /> <br /> 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<br /> 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<br /> itself has many added benefits.<br /> <br /> 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.<br /> <br /> As usual, reduction of code duplicity and a flexible scalable design is desired (e.g. Allow the inclusion of different preambles in the future).<br /> <br /> * ''Required Experience:'' Basic understanding of IEEE 802.15.4, C++ programming.<br /> * ''Bonus Experience:'' PHY process familiarity, Familiarity with ns-3's Lr-WPAN<br /> * ''Interests:'' Lr-WPAN, MAC and PHY designs<br /> * ''Difficulty:'' Medium.<br /> * ''Recommended reading:''<br /> ** [https://ieeexplore.ieee.org/document/1700009 IEEE 802.15.4-2006]<br /> ** [https://ieeexplore.ieee.org/document/7460875 IEEE 802.15.4-2015]<br /> ** [https://www.nsnam.org/docs/models/html/lr-wpan.html ns-3 lr-wpan module]<br /> <br /> Possible tasks to fulfill the patch requirement:<br /> * TBD, contact the mentors if interested.<br /> <br /> === 5G NR module integration with ns-3-ai ===<br /> <br /> 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]<br /> <br /> 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.<br /> <br /> 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.<br /> For more specific guidelines, please view this [https://docs.google.com/document/d/1cQLIF1cdft1yj3vyWrjrxN2xDJMx8PuWaa9NP_nKf64/edit?usp=sharing Google document].<br /> <br /> * Required Experience: C++ programming, understanding of 5G NR, LTE, and wireless networks<br /> * Interests: 5G NR simulations<br /> * Difficulty: Medium.<br /> * 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.<br /> <br /> === Linux-like CAKE queue discipline for ns-3 ===<br /> <br /> Mentors: [mailto:tahiliani.nitk@gmail.com Mohit P. Tahiliani]<br /> <br /> 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.<br /> <br /> * ''Required Experience:'' Familiarity with queue disciplines, TCP and C++ programming.<br /> * ''Bonus Experience:'' Familiarity with CAKE framework in Linux 4.19<br /> * ''Interests:'' Active Queue Management, Packet scheduling and TCP.<br /> * ''Difficulty:'' Medium to Hard<br /> * ''Recommended reading:''<br /> ** [https://arxiv.org/pdf/1804.07617.pdf Piece of CAKE: A Comprehensive Queue Management Solution for Home Gateways]<br /> ** [https://lwn.net/Articles/758353/ Let them run CAKE]<br /> ** [https://www.nsnam.org/docs/models/html/queue-discs.html Queue disciplines in ns-3]</div>

Tommaso https://www.nsnam.org/mediawiki/index.php?title=GSOC2025Projects&diff=13448 2025-02-16T16:05:13Z

<p>Tommaso: /* Project Ideas */</p> <hr /> <div>{{TOC}}<br /> <br /> This page contains 2025 Google Summer of Code project ideas for ns-3.<br /> <br /> * [https://developers.google.com/open-source/gsoc/faq GSoC Frequently Asked Questions]<br /> * [[GSOC2025ContributorGuide | ns-3's 2025 GSoC Contributor guide]]<br /> * [https://developers.google.com/open-source/gsoc/resources/guide GSoC contributor/student guide (not ns-3 specific)]<br /> * [[GSOC2025ApplicationTemplate | 2025 GSoC Contributor application template]]<br /> * [[GSOCMentorGuide | ns-3's GSoC Mentor guide]]<br /> * [https://archive.flossmanuals.net/gsocmentoring/index.html GSoC Mentor guide (not ns-3 specific)]<br /> * [[GSOCSelectionProcess | GSoC Contributor Selection Process]]<br /> * ''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/<br /> <br /> === About the ns-3 project ===<br /> <br /> ns-3 is a discrete-event network simulator, with a particular emphasis on network research and education.<br /> <br /> 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.<br /> <br /> 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.<br /> <br /> === Org admins ===<br /> <br /> 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].<br /> <br /> === Mentors ===<br /> <br /> 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.<br /> <br /> The current list of prospective mentors can be found among the ideas listed below.<br /> <br /> === How to apply ===<br /> <br /> For students or contributors interested in applying to ns-3 for GSoC, please go through the following list to get started:<br /> * Read the official [https://developers.google.com/open-source/gsoc/resources/guide GSoC contributor guide].<br /> * Read [[GSOC2025ContributorGuide |ns-3's 2025 GSoC contributor guide]]<br /> * Look through our [[#Project Ideas]] below to see if you find a project that interests you.<br /> * Review the [https://www.nsnam.org/documentation/development-tree/ tutorial and contributing guide] thoroughly, if you have not already done so.<br /> * 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.<br /> * Next, proceed to get in touch with the developers on the mailing list or Zulip chat room and refine your proposal.<br /> * 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.<br /> <br /> 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.<br /> <br /> &lt;blockquote&gt;<br /> Each project idea within a particular priority has been tagged with the following properties:<br /> * ''Required Experience:'' Languages, concepts, or packages with which applicants must be familiar.<br /> * ''Bonus Experience:'' Other experience or familiarity which would be greatly helpful to applicants for this project.<br /> * ''Interests:'' Areas of particular relevance to this project, and an indicator of where successful contributors might apply their experiences coming out of this project.<br /> * ''Difficulty:'' easy, medium or difficult<br /> * ''Recommended reading:'' pointers to documentation, papers, specific bugs, etc.<br /> <br /> 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.<br /> &lt;/blockquote&gt;<br /> <br /> === Patch requirement guidelines ===<br /> <br /> 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.<br /> <br /> === Mentors: how to participate ===<br /> <br /> 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:<br /> <br /> * 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.<br /> * 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.<br /> * 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.<br /> <br /> == Project Ideas ==<br /> <br /> '''Note to contributors:''' These ideas are not listed in any priority order.<br /> 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.<br /> <br /> === Internet models enhancements ===<br /> <br /> * [[#Upgrade the AQM Evaluation Suite for ns-3]] (small size project, 90h)<br /> * [[#Implementation of Alternative Backoff with ECN (ABE)]] (small size project, 90h)<br /> * [[#ICMP socket and generate/handle ICMP messages (host/net unreachable)]] (medium size project, 175h)<br /> * [[#Linux-like Loss Detection Techniques for ns-3 TCP]] (medium size project, 175h)<br /> * [[#AODVv2 Protocol enhancements]] (medium size project, 175h)<br /> * [[#IPv6 global routing]] (large size project, 350h)<br /> * [[#IPv6 support in Ad hoc Routing Protocols]] (large size project, 350h)<br /> * [[#Linux-like CAKE queue discipline for ns-3]] (large size project, 350h)<br /> <br /> === IoT models enhancements ===<br /> <br /> * [[#6LoWPAN mesh-under routing enhancements]] (medium size project, 175h)<br /> * [[#6LoWPAN neighbor discovery protocol]] (medium size project, 175h)<br /> * [[#Mesh Link Establishment (MLE) protocol ]] (large size project, 350h)<br /> * [[#Lr-WPAN (IEEE 802.15.4) preamble detection support]] (large size project, 350h)<br /> <br /> === 5G NR models enhancements ===<br /> <br /> 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.<br /> <br /> * [[#NTN example for 5G NR]] (small size project, 90h)<br /> * [[#Enabling 5G NR examples visualization]] (medium size project, 175h)<br /> * [[#Improving 5G NR module usability through helpers]] (medium size project, 175h)<br /> * [[#5G NR module integration with ns-3-ai]] (large size project, 250h)<br /> <br /> == Small sized projects (90 hours) ==<br /> <br /> <br /> === NTN example for 5G NR ===<br /> <br /> 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]<br /> <br /> 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).<br /> <br /> 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.<br /> <br /> * Required Experience: C++ programming, understanding of 5G NR, LTE, and wireless networks<br /> * Interests: 5G NR simulations<br /> * Difficulty: Medium.<br /> * 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.<br /> <br /> === Upgrade the AQM Evaluation Suite for ns-3 ===<br /> <br /> Mentors: [mailto:tahiliani.nitk@gmail.com Mohit P. Tahiliani]<br /> <br /> 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.<br /> <br /> * ''Required Experience:'' Familiarity with AQM and C++ programming.<br /> * ''Bonus Experience:'' Familiarity with traffic control model in ns-3.<br /> * ''Interests:'' Packet Scheduling algorithms, AQM algorithms and ECN.<br /> * ''Difficulty:'' Medium.<br /> * ''Recommended Reading:''<br /> ** AQM Evaluation Suite [[https://dl.acm.org/doi/abs/10.1145/3067665.3067674 Paper]] [[https://aqm-eval-suite.github.io/ Implementation]]<br /> ** [https://tools.ietf.org/html/rfc7928 RFC 7928]<br /> ** [https://www.nsnam.org/docs/models/html/traffic-control-layer.html Traffic Control Model in ns-3]<br /> * ''Patch requirement:'' Create a pull request to handle the case when an incorrect Scenario name or number is passed via command line.<br /> <br /> === Implementation of Alternative Backoff with ECN (ABE) ===<br /> <br /> Mentors: [mailto:tahiliani.nitk@gmail.com Mohit P. Tahiliani]<br /> <br /> 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.<br /> <br /> * ''Required Experience:'' Familiarity with ECN and C++ programming.<br /> * ''Bonus Experience:'' Familiarity with traffic control model in ns-3.<br /> * ''Interests:'' Packet Scheduling algorithms, AQM algorithms and ECN.<br /> * ''Difficulty:'' Medium.<br /> * ''Recommended Reading:''<br /> ** Alternative Backoff with ECN [[https://datatracker.ietf.org/doc/rfc8511 RFC 8511]] [[http://heim.ifi.uio.no/~naeemk/research/ABE/Networking2017ABE.pdf Paper]]<br /> ** [https://www.nsnam.org/docs/models/html/tcp.html#support-for-explicit-congestion-notification-ecn ECN support in ns-3]<br /> ** [https://www.nsnam.org/docs/models/html/traffic-control-layer.html Traffic Control Model in ns-3]<br /> <br /> == Medium sized projects (175 hours) ==<br /> <br /> === ICMP socket and generate/handle ICMP messages (host/net unreachable) ===<br /> <br /> Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], [mailto:manoj24.rana@gmail.com Manoj K. Rana].<br /> <br /> 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 &quot;RAW&quot; socket.<br /> 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.<br /> <br /> 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.<br /> <br /> The most important point of the implementation should be code duplicate minimization, in order to have the minimize maintenance efforts.<br /> <br /> Once the sockets are in place, beside the &quot;normal&quot; tests, it will be necessary to modify the code that is actually made obsolete by the new sockets, e.g.:<br /> * IPv6 ICMP messages (RA, RS, NA, NS, etc.),<br /> * IPv4 ICMP messages,<br /> * ICMP Echo and ICMPv6 Echo messages.<br /> and to handle properly ICMP error messages like Destination Unreachable in the Ping application.<br /> <br /> * ''Required Experience:'' Fundamentals of IPv4 and IPv6 sockets, C++ programming.<br /> * ''Interests:'' Sockets and API interface implementation.<br /> * ''Difficulty:'' Medium.<br /> * ''Recommended reading:''<br /> ** [https://man7.org/linux/man-pages/man2/socket.2.html Linux socket]<br /> ** [https://courses.cs.vt.edu/cs4254/fall04/slides/raw_1.pdf Raw Sockets and ICMP, Srinidhi Varadarajan]<br /> ** [https://gitlab.com/nsnam/ns-3-dev/-/issues/810 Issue #810]<br /> <br /> Possible tasks to fulfill the patch requirement:<br /> * Submit a patch to fix [https://gitlab.com/nsnam/ns-3-dev/-/issues/809 Issue #809]<br /> <br /> === 6LoWPAN mesh-under routing enhancements ===<br /> <br /> Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], [TBD].<br /> <br /> 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.<br /> 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.<br /> <br /> The candidate should outline what parts of code are going to be affected, and how they can be enhanced thanks to RFC 7731.<br /> <br /> * ''Required Experience:'' Fundamentals of IPv6 addressing, C++ programming.<br /> * ''Bonus Experience:'' Familiarity with mesh routing and 6LoWPAN ns-3<br /> * ''Interests:'' IPv6 mesh routing<br /> * ''Difficulty:'' Easy.<br /> * ''Recommended reading:''<br /> ** [https://www.nsnam.org/docs/models/html/sixlowpan.html#mesh-under-routing Mesh-under in ns-3 6LoWPAN]<br /> ** [https://datatracker.ietf.org/doc/html/rfc7731 RFC 7731]<br /> <br /> Possible tasks to fulfill the patch requirement:<br /> * TBD<br /> <br /> === 6LoWPAN neighbor discovery protocol ===<br /> <br /> Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], [TBD].<br /> <br /> 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.<br /> <br /> 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).<br /> <br /> 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.<br /> <br /> * ''Required Experience:'' Fundamentals of IPv6 addressing, C++ programming.<br /> * ''Bonus Experience:'' Familiarity with 6LoWPAN and 6LoWPAN-ND<br /> * ''Interests:'' IPv6 and IoT networks<br /> * ''Difficulty:'' Easy.<br /> * ''Recommended reading:''<br /> ** [https://datatracker.ietf.org/doc/html/rfc8505 RFC 8505]<br /> ** [https://datatracker.ietf.org/doc/html/rfc6775 RFC 6775]<br /> ** [https://datatracker.ietf.org/doc/html/rfc4944 RFC 4944]<br /> <br /> Possible tasks to fulfil the patch requirement:<br /> * Patch the actual 6LoWPAN-ND to remove the limitation about concurrent address registrations.<br /> <br /> === Improving 5G NR module usability through helpers ===<br /> <br /> 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]<br /> <br /> 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.<br /> <br /> 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.<br /> <br /> * Required Experience: C++ programming, understanding of 5G NR, LTE, and wireless networks<br /> * Interests: 5G NR simulations<br /> * Difficulty: Medium.<br /> * 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.<br /> <br /> === Enabling 5G NR examples visualization ===<br /> <br /> 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]<br /> <br /> 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.<br /> <br /> 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.<br /> 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].<br /> <br /> * Required Experience: C++ and Python programming, understanding of 5G NR, LTE, and wireless networks<br /> * Interests: 5G NR simulations<br /> * Difficulty: Medium.<br /> * 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.<br /> <br /> === Linux-like Loss Detection Techniques for ns-3 TCP ===<br /> <br /> Mentors: [mailto:tahiliani.nitk@gmail.com Mohit P. Tahiliani]<br /> <br /> 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.<br /> <br /> * ''Required Experience:'' Familiarity with TCP and C++ programming.<br /> * ''Bonus Experience:'' Familiarity with TCP implementation in Linux kernel.<br /> * ''Interests:'' TCP packet loss detection techniques.<br /> * ''Difficulty:'' Medium to Hard.<br /> * ''Recommended Reading:''<br /> ** Forward Acknowledgement (FACK) [[https://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.41.2559&amp;rep=rep1&amp;type=pdf Paper]] [[https://gitlab.com/nsnam/ns-3-dev/-/merge_requests/34/commits Implementation]]<br /> ** Duplicate Selective Acknowledgment (DSACK) [[https://tools.ietf.org/html/rfc2883 RFC 2883]] [[https://gitlab.com/nsnam/ns-3-dev/-/merge_requests/34/commits Implementation]]<br /> ** RACK-TLP [[https://datatracker.ietf.org/doc/html/rfc8985 RFC 8985]] [[https://gitlab.com/nsnam/ns-3-dev/-/merge_requests/34/commits Implementation]]<br /> <br /> == Large projects (350 hours) ==<br /> <br /> === IPv6 global routing ===<br /> <br /> Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], [TBD].<br /> <br /> 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).<br /> For IPv4, ns-3 provides two alternatives: GlobalRouting, and NixRouting, which just &quot;do the trick&quot; - they simply fill the routing tables in intermediate nodes, GlobalRouting using an approach similar to OSPF, NixRouting by leveraging the &quot;abstract&quot; knowledge of the network.<br /> Neither actually use any message between the nodes, so they also reduce the network overhead - something that is useful in many cases.<br /> <br /> 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.).<br /> <br /> 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.<br /> <br /> * ''Required Experience:'' Fundamentals of IPv6 addressing, C++ programming.<br /> * ''Bonus Experience:'' Familiarity with GlobalRouting implementations in ns-3<br /> * ''Interests:'' IPv6 routing<br /> * ''Difficulty:'' Medium.<br /> * ''Recommended reading:''<br /> ** [https://www.nsnam.org/docs/models/html/ipv6.html IPv6 model in ns-3]<br /> ** [https://www.nsnam.org/docs/models/html/routing-overview.html#global-centralized-routing GlobalRouting model in ns-3]<br /> <br /> Possible tasks to fulfill the patch requirement:<br /> * 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.<br /> <br /> === AODVv2 Protocol enhancements ===<br /> <br /> Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], [TBD].<br /> <br /> 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.<br /> <br /> In particular the project should address the following points: 1) AODVv2 performances, 2) AODV address compression, 3) &quot;external&quot; network routing support, 4) general model validation against the latest draft.<br /> Collaboration with the draft authors is also highly suggested.<br /> <br /> * ''Required Experience:'' Fundamentals of IPv6 addressing, C++ programming.<br /> * ''Bonus Experience:'' Familiarity with AODV implementations in ns-3 and AODVv2<br /> * ''Interests:'' Ad hoc routing<br /> * ''Difficulty:'' Medium.<br /> * ''Recommended reading:''<br /> ** [https://www.nsnam.org/docs/models/html/ipv6.html IPv6 model in ns-3]<br /> ** [https://www.nsnam.org/docs/models/html/aodv.html AODV model in ns-3]<br /> ** [https://datatracker.ietf.org/doc/draft-perkins-manet-aodvv2/05/ Ad Hoc On-demand Distance Vector Version 2 (AODVv2) Routing]<br /> <br /> Possible tasks to fulfill the patch requirement:<br /> * [https://gitlab.com/nsnam/ns-3-dev/-/issues/368 Issue #368] - aodv: aodv parameters can be set to &quot;impossible&quot; values<br /> <br /> === Mesh Link Establishment (MLE) protocol ===<br /> <br /> Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], TBD.<br /> <br /> 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.<br /> However, MLE is being used in Thread, and it can be useful to implement it.<br /> <br /> 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.<br /> <br /> * ''Required Experience:'' Fundamentals of IPv4 and IPv6 sockets, C++ programming.<br /> * ''Interests:'' Sockets and API interface implementation.<br /> * ''Difficulty:'' Hard.<br /> * ''Recommended reading:''<br /> ** [https://datatracker.ietf.org/doc/html/draft-ietf-6lo-mesh-link-establishment MLE draft]<br /> ** [https://openthread.io/guides/thread-primer/network-discovery Thread primer]<br /> ** [https://www.threadgroup.org/ThreadSpec Thread specifications]<br /> <br /> Possible tasks to fulfill the patch requirement:<br /> * TBD, contact the mentors if interested.<br /> <br /> === Lr-WPAN (IEEE 802.15.4) preamble detection support ===<br /> <br /> Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], [mailto:alramonet@is.tokushima-u.ac.jp Alberto Gallegos Ramonet].<br /> <br /> 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<br /> 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<br /> itself has many added benefits.<br /> <br /> 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.<br /> <br /> As usual, reduction of code duplicity and a flexible scalable design is desired (e.g. Allow the inclusion of different preambles in the future).<br /> <br /> * ''Required Experience:'' Basic understanding of IEEE 802.15.4, C++ programming.<br /> * ''Bonus Experience:'' PHY process familiarity, Familiarity with ns-3's Lr-WPAN<br /> * ''Interests:'' Lr-WPAN, MAC and PHY designs<br /> * ''Difficulty:'' Medium.<br /> * ''Recommended reading:''<br /> ** [https://ieeexplore.ieee.org/document/1700009 IEEE 802.15.4-2006]<br /> ** [https://ieeexplore.ieee.org/document/7460875 IEEE 802.15.4-2015]<br /> ** [https://www.nsnam.org/docs/models/html/lr-wpan.html ns-3 lr-wpan module]<br /> <br /> Possible tasks to fulfill the patch requirement:<br /> * TBD, contact the mentors if interested.<br /> <br /> === 5G NR module integration with ns-3-ai ===<br /> <br /> 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]<br /> <br /> 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.<br /> <br /> 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.<br /> For more specific guidelines, please view this [https://docs.google.com/document/d/1cQLIF1cdft1yj3vyWrjrxN2xDJMx8PuWaa9NP_nKf64/edit?usp=sharing Google document].<br /> <br /> * Required Experience: C++ programming, understanding of 5G NR, LTE, and wireless networks<br /> * Interests: 5G NR simulations<br /> * Difficulty: Medium.<br /> * 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.<br /> <br /> === Linux-like CAKE queue discipline for ns-3 ===<br /> <br /> Mentors: [mailto:tahiliani.nitk@gmail.com Mohit P. Tahiliani]<br /> <br /> 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.<br /> <br /> * ''Required Experience:'' Familiarity with queue disciplines, TCP and C++ programming.<br /> * ''Bonus Experience:'' Familiarity with CAKE framework in Linux 4.19<br /> * ''Interests:'' Active Queue Management, Packet scheduling and TCP.<br /> * ''Difficulty:'' Medium to Hard<br /> * ''Recommended reading:''<br /> ** [https://arxiv.org/pdf/1804.07617.pdf Piece of CAKE: A Comprehensive Queue Management Solution for Home Gateways]<br /> ** [https://lwn.net/Articles/758353/ Let them run CAKE]<br /> ** [https://www.nsnam.org/docs/models/html/queue-discs.html Queue disciplines in ns-3]</div>

Tommaso https://www.nsnam.org/mediawiki/index.php?title=GSOC2025Projects&diff=13447 2025-02-16T16:00:47Z

<p>Tommaso: /* Internet models enhancements */</p> <hr /> <div>{{TOC}}<br /> <br /> This page contains 2025 Google Summer of Code project ideas for ns-3.<br /> <br /> * [https://developers.google.com/open-source/gsoc/faq GSoC Frequently Asked Questions]<br /> * [[GSOC2025ContributorGuide | ns-3's 2025 GSoC Contributor guide]]<br /> * [https://developers.google.com/open-source/gsoc/resources/guide GSoC contributor/student guide (not ns-3 specific)]<br /> * [[GSOC2025ApplicationTemplate | 2025 GSoC Contributor application template]]<br /> * [[GSOCMentorGuide | ns-3's GSoC Mentor guide]]<br /> * [https://archive.flossmanuals.net/gsocmentoring/index.html GSoC Mentor guide (not ns-3 specific)]<br /> * [[GSOCSelectionProcess | GSoC Contributor Selection Process]]<br /> * ''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/<br /> <br /> === About the ns-3 project ===<br /> <br /> ns-3 is a discrete-event network simulator, with a particular emphasis on network research and education.<br /> <br /> 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.<br /> <br /> 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.<br /> <br /> === Org admins ===<br /> <br /> 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].<br /> <br /> === Mentors ===<br /> <br /> 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.<br /> <br /> The current list of prospective mentors can be found among the ideas listed below.<br /> <br /> === How to apply ===<br /> <br /> For students or contributors interested in applying to ns-3 for GSoC, please go through the following list to get started:<br /> * Read the official [https://developers.google.com/open-source/gsoc/resources/guide GSoC contributor guide].<br /> * Read [[GSOC2025ContributorGuide |ns-3's 2025 GSoC contributor guide]]<br /> * Look through our [[#Project Ideas]] below to see if you find a project that interests you.<br /> * Review the [https://www.nsnam.org/documentation/development-tree/ tutorial and contributing guide] thoroughly, if you have not already done so.<br /> * 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.<br /> * Next, proceed to get in touch with the developers on the mailing list or Zulip chat room and refine your proposal.<br /> * 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.<br /> <br /> 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.<br /> <br /> &lt;blockquote&gt;<br /> Each project idea within a particular priority has been tagged with the following properties:<br /> * ''Required Experience:'' Languages, concepts, or packages with which applicants must be familiar.<br /> * ''Bonus Experience:'' Other experience or familiarity which would be greatly helpful to applicants for this project.<br /> * ''Interests:'' Areas of particular relevance to this project, and an indicator of where successful contributors might apply their experiences coming out of this project.<br /> * ''Difficulty:'' easy, medium or difficult<br /> * ''Recommended reading:'' pointers to documentation, papers, specific bugs, etc.<br /> <br /> 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.<br /> &lt;/blockquote&gt;<br /> <br /> === Patch requirement guidelines ===<br /> <br /> 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.<br /> <br /> === Mentors: how to participate ===<br /> <br /> 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:<br /> <br /> * 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.<br /> * 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.<br /> * 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.<br /> <br /> == Project Ideas ==<br /> <br /> '''Note to contributors:''' These ideas are not listed in any priority order.<br /> 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.<br /> <br /> === Internet models enhancements ===<br /> <br /> * [[#Upgrade the AQM Evaluation Suite for ns-3]] (small size project, 90h)<br /> * [[#Implementation of Alternative Backoff with ECN (ABE)]] (small size project, 90h)<br /> * [[#ICMP socket and generate/handle ICMP messages (host/net unreachable)]] (medium size project, 175h)<br /> * [[#IPv6 global routing]] (large size project, 350h)<br /> * [[#IPv6 support in Ad hoc Routing Protocols]] (large size project, 350h)<br /> <br /> === IoT models enhancements ===<br /> <br /> * [[#6LoWPAN mesh-under routing enhancements]] (medium size project, 175h)<br /> * [[#6LoWPAN neighbor discovery protocol]] (medium size project, 175h)<br /> * [[#Mesh Link Establishment (MLE) protocol ]] (large size project, 350h)<br /> * [[#Lr-WPAN (IEEE 802.15.4) preamble detection support]] (large size project, 350h)<br /> <br /> === 5G NR models enhancements ===<br /> <br /> 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.<br /> <br /> * [[#NTN example for 5G NR]] (small size project, 90h)<br /> * [[#5G NR module integration with ns-3-ai]] (large size project, 250h)<br /> * [[#Enabling 5G NR examples visualization]] (large size project, 175h)<br /> * [[#Improving 5G NR module usability through helpers]] (medium size project, 175h)<br /> <br /> == Small sized projects (90 hours) ==<br /> <br /> <br /> === NTN example for 5G NR ===<br /> <br /> 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]<br /> <br /> 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).<br /> <br /> 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.<br /> <br /> * Required Experience: C++ programming, understanding of 5G NR, LTE, and wireless networks<br /> * Interests: 5G NR simulations<br /> * Difficulty: Medium.<br /> * 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.<br /> <br /> === Upgrade the AQM Evaluation Suite for ns-3 ===<br /> <br /> Mentors: [mailto:tahiliani.nitk@gmail.com Mohit P. Tahiliani]<br /> <br /> 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.<br /> <br /> * ''Required Experience:'' Familiarity with AQM and C++ programming.<br /> * ''Bonus Experience:'' Familiarity with traffic control model in ns-3.<br /> * ''Interests:'' Packet Scheduling algorithms, AQM algorithms and ECN.<br /> * ''Difficulty:'' Medium.<br /> * ''Recommended Reading:''<br /> ** AQM Evaluation Suite [[https://dl.acm.org/doi/abs/10.1145/3067665.3067674 Paper]] [[https://aqm-eval-suite.github.io/ Implementation]]<br /> ** [https://tools.ietf.org/html/rfc7928 RFC 7928]<br /> ** [https://www.nsnam.org/docs/models/html/traffic-control-layer.html Traffic Control Model in ns-3]<br /> * ''Patch requirement:'' Create a pull request to handle the case when an incorrect Scenario name or number is passed via command line.<br /> <br /> === Implementation of Alternative Backoff with ECN (ABE) ===<br /> <br /> Mentors: [mailto:tahiliani.nitk@gmail.com Mohit P. Tahiliani]<br /> <br /> 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.<br /> <br /> * ''Required Experience:'' Familiarity with ECN and C++ programming.<br /> * ''Bonus Experience:'' Familiarity with traffic control model in ns-3.<br /> * ''Interests:'' Packet Scheduling algorithms, AQM algorithms and ECN.<br /> * ''Difficulty:'' Medium.<br /> * ''Recommended Reading:''<br /> ** Alternative Backoff with ECN [[https://datatracker.ietf.org/doc/rfc8511 RFC 8511]] [[http://heim.ifi.uio.no/~naeemk/research/ABE/Networking2017ABE.pdf Paper]]<br /> ** [https://www.nsnam.org/docs/models/html/tcp.html#support-for-explicit-congestion-notification-ecn ECN support in ns-3]<br /> ** [https://www.nsnam.org/docs/models/html/traffic-control-layer.html Traffic Control Model in ns-3]<br /> <br /> == Medium sized projects (175 hours) ==<br /> <br /> === ICMP socket and generate/handle ICMP messages (host/net unreachable) ===<br /> <br /> Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], [mailto:manoj24.rana@gmail.com Manoj K. Rana].<br /> <br /> 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 &quot;RAW&quot; socket.<br /> 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.<br /> <br /> 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.<br /> <br /> The most important point of the implementation should be code duplicate minimization, in order to have the minimize maintenance efforts.<br /> <br /> Once the sockets are in place, beside the &quot;normal&quot; tests, it will be necessary to modify the code that is actually made obsolete by the new sockets, e.g.:<br /> * IPv6 ICMP messages (RA, RS, NA, NS, etc.),<br /> * IPv4 ICMP messages,<br /> * ICMP Echo and ICMPv6 Echo messages.<br /> and to handle properly ICMP error messages like Destination Unreachable in the Ping application.<br /> <br /> * ''Required Experience:'' Fundamentals of IPv4 and IPv6 sockets, C++ programming.<br /> * ''Interests:'' Sockets and API interface implementation.<br /> * ''Difficulty:'' Medium.<br /> * ''Recommended reading:''<br /> ** [https://man7.org/linux/man-pages/man2/socket.2.html Linux socket]<br /> ** [https://courses.cs.vt.edu/cs4254/fall04/slides/raw_1.pdf Raw Sockets and ICMP, Srinidhi Varadarajan]<br /> ** [https://gitlab.com/nsnam/ns-3-dev/-/issues/810 Issue #810]<br /> <br /> Possible tasks to fulfill the patch requirement:<br /> * Submit a patch to fix [https://gitlab.com/nsnam/ns-3-dev/-/issues/809 Issue #809]<br /> <br /> === 6LoWPAN mesh-under routing enhancements ===<br /> <br /> Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], [TBD].<br /> <br /> 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.<br /> 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.<br /> <br /> The candidate should outline what parts of code are going to be affected, and how they can be enhanced thanks to RFC 7731.<br /> <br /> * ''Required Experience:'' Fundamentals of IPv6 addressing, C++ programming.<br /> * ''Bonus Experience:'' Familiarity with mesh routing and 6LoWPAN ns-3<br /> * ''Interests:'' IPv6 mesh routing<br /> * ''Difficulty:'' Easy.<br /> * ''Recommended reading:''<br /> ** [https://www.nsnam.org/docs/models/html/sixlowpan.html#mesh-under-routing Mesh-under in ns-3 6LoWPAN]<br /> ** [https://datatracker.ietf.org/doc/html/rfc7731 RFC 7731]<br /> <br /> Possible tasks to fulfill the patch requirement:<br /> * TBD<br /> <br /> === 6LoWPAN neighbor discovery protocol ===<br /> <br /> Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], [TBD].<br /> <br /> 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.<br /> <br /> 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).<br /> <br /> 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.<br /> <br /> * ''Required Experience:'' Fundamentals of IPv6 addressing, C++ programming.<br /> * ''Bonus Experience:'' Familiarity with 6LoWPAN and 6LoWPAN-ND<br /> * ''Interests:'' IPv6 and IoT networks<br /> * ''Difficulty:'' Easy.<br /> * ''Recommended reading:''<br /> ** [https://datatracker.ietf.org/doc/html/rfc8505 RFC 8505]<br /> ** [https://datatracker.ietf.org/doc/html/rfc6775 RFC 6775]<br /> ** [https://datatracker.ietf.org/doc/html/rfc4944 RFC 4944]<br /> <br /> Possible tasks to fulfil the patch requirement:<br /> * Patch the actual 6LoWPAN-ND to remove the limitation about concurrent address registrations.<br /> <br /> === Improving 5G NR module usability through helpers ===<br /> <br /> 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]<br /> <br /> 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.<br /> <br /> 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.<br /> <br /> * Required Experience: C++ programming, understanding of 5G NR, LTE, and wireless networks<br /> * Interests: 5G NR simulations<br /> * Difficulty: Medium.<br /> * 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.<br /> <br /> === Enabling 5G NR examples visualization ===<br /> <br /> 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]<br /> <br /> 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.<br /> <br /> 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.<br /> 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].<br /> <br /> * Required Experience: C++ and Python programming, understanding of 5G NR, LTE, and wireless networks<br /> * Interests: 5G NR simulations<br /> * Difficulty: Medium.<br /> * 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.<br /> <br /> === Linux-like Loss Detection Techniques for ns-3 TCP ===<br /> <br /> Mentors: [mailto:tahiliani.nitk@gmail.com Mohit P. Tahiliani]<br /> <br /> 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.<br /> <br /> * ''Required Experience:'' Familiarity with TCP and C++ programming.<br /> * ''Bonus Experience:'' Familiarity with TCP implementation in Linux kernel.<br /> * ''Interests:'' TCP packet loss detection techniques.<br /> * ''Difficulty:'' Medium to Hard.<br /> * ''Recommended Reading:''<br /> ** Forward Acknowledgement (FACK) [[https://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.41.2559&amp;rep=rep1&amp;type=pdf Paper]] [[https://gitlab.com/nsnam/ns-3-dev/-/merge_requests/34/commits Implementation]]<br /> ** Duplicate Selective Acknowledgment (DSACK) [[https://tools.ietf.org/html/rfc2883 RFC 2883]] [[https://gitlab.com/nsnam/ns-3-dev/-/merge_requests/34/commits Implementation]]<br /> ** RACK-TLP [[https://datatracker.ietf.org/doc/html/rfc8985 RFC 8985]] [[https://gitlab.com/nsnam/ns-3-dev/-/merge_requests/34/commits Implementation]]<br /> <br /> == Large projects (350 hours) ==<br /> <br /> === IPv6 global routing ===<br /> <br /> Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], [TBD].<br /> <br /> 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).<br /> For IPv4, ns-3 provides two alternatives: GlobalRouting, and NixRouting, which just &quot;do the trick&quot; - they simply fill the routing tables in intermediate nodes, GlobalRouting using an approach similar to OSPF, NixRouting by leveraging the &quot;abstract&quot; knowledge of the network.<br /> Neither actually use any message between the nodes, so they also reduce the network overhead - something that is useful in many cases.<br /> <br /> 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.).<br /> <br /> 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.<br /> <br /> * ''Required Experience:'' Fundamentals of IPv6 addressing, C++ programming.<br /> * ''Bonus Experience:'' Familiarity with GlobalRouting implementations in ns-3<br /> * ''Interests:'' IPv6 routing<br /> * ''Difficulty:'' Medium.<br /> * ''Recommended reading:''<br /> ** [https://www.nsnam.org/docs/models/html/ipv6.html IPv6 model in ns-3]<br /> ** [https://www.nsnam.org/docs/models/html/routing-overview.html#global-centralized-routing GlobalRouting model in ns-3]<br /> <br /> Possible tasks to fulfill the patch requirement:<br /> * 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.<br /> <br /> === AODVv2 Protocol enhancements ===<br /> <br /> Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], [TBD].<br /> <br /> 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.<br /> <br /> In particular the project should address the following points: 1) AODVv2 performances, 2) AODV address compression, 3) &quot;external&quot; network routing support, 4) general model validation against the latest draft.<br /> Collaboration with the draft authors is also highly suggested.<br /> <br /> * ''Required Experience:'' Fundamentals of IPv6 addressing, C++ programming.<br /> * ''Bonus Experience:'' Familiarity with AODV implementations in ns-3 and AODVv2<br /> * ''Interests:'' Ad hoc routing<br /> * ''Difficulty:'' Medium.<br /> * ''Recommended reading:''<br /> ** [https://www.nsnam.org/docs/models/html/ipv6.html IPv6 model in ns-3]<br /> ** [https://www.nsnam.org/docs/models/html/aodv.html AODV model in ns-3]<br /> ** [https://datatracker.ietf.org/doc/draft-perkins-manet-aodvv2/05/ Ad Hoc On-demand Distance Vector Version 2 (AODVv2) Routing]<br /> <br /> Possible tasks to fulfill the patch requirement:<br /> * [https://gitlab.com/nsnam/ns-3-dev/-/issues/368 Issue #368] - aodv: aodv parameters can be set to &quot;impossible&quot; values<br /> <br /> === Mesh Link Establishment (MLE) protocol ===<br /> <br /> Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], TBD.<br /> <br /> 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.<br /> However, MLE is being used in Thread, and it can be useful to implement it.<br /> <br /> 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.<br /> <br /> * ''Required Experience:'' Fundamentals of IPv4 and IPv6 sockets, C++ programming.<br /> * ''Interests:'' Sockets and API interface implementation.<br /> * ''Difficulty:'' Hard.<br /> * ''Recommended reading:''<br /> ** [https://datatracker.ietf.org/doc/html/draft-ietf-6lo-mesh-link-establishment MLE draft]<br /> ** [https://openthread.io/guides/thread-primer/network-discovery Thread primer]<br /> ** [https://www.threadgroup.org/ThreadSpec Thread specifications]<br /> <br /> Possible tasks to fulfill the patch requirement:<br /> * TBD, contact the mentors if interested.<br /> <br /> === Lr-WPAN (IEEE 802.15.4) preamble detection support ===<br /> <br /> Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], [mailto:alramonet@is.tokushima-u.ac.jp Alberto Gallegos Ramonet].<br /> <br /> 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<br /> 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<br /> itself has many added benefits.<br /> <br /> 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.<br /> <br /> As usual, reduction of code duplicity and a flexible scalable design is desired (e.g. Allow the inclusion of different preambles in the future).<br /> <br /> * ''Required Experience:'' Basic understanding of IEEE 802.15.4, C++ programming.<br /> * ''Bonus Experience:'' PHY process familiarity, Familiarity with ns-3's Lr-WPAN<br /> * ''Interests:'' Lr-WPAN, MAC and PHY designs<br /> * ''Difficulty:'' Medium.<br /> * ''Recommended reading:''<br /> ** [https://ieeexplore.ieee.org/document/1700009 IEEE 802.15.4-2006]<br /> ** [https://ieeexplore.ieee.org/document/7460875 IEEE 802.15.4-2015]<br /> ** [https://www.nsnam.org/docs/models/html/lr-wpan.html ns-3 lr-wpan module]<br /> <br /> Possible tasks to fulfill the patch requirement:<br /> * TBD, contact the mentors if interested.<br /> <br /> === 5G NR module integration with ns-3-ai ===<br /> <br /> 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]<br /> <br /> 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.<br /> <br /> 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.<br /> For more specific guidelines, please view this [https://docs.google.com/document/d/1cQLIF1cdft1yj3vyWrjrxN2xDJMx8PuWaa9NP_nKf64/edit?usp=sharing Google document].<br /> <br /> * Required Experience: C++ programming, understanding of 5G NR, LTE, and wireless networks<br /> * Interests: 5G NR simulations<br /> * Difficulty: Medium.<br /> * 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.<br /> <br /> === Linux-like CAKE queue discipline for ns-3 ===<br /> <br /> Mentors: [mailto:tahiliani.nitk@gmail.com Mohit P. Tahiliani]<br /> <br /> 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.<br /> <br /> * ''Required Experience:'' Familiarity with queue disciplines, TCP and C++ programming.<br /> * ''Bonus Experience:'' Familiarity with CAKE framework in Linux 4.19<br /> * ''Interests:'' Active Queue Management, Packet scheduling and TCP.<br /> * ''Difficulty:'' Medium to Hard<br /> * ''Recommended reading:''<br /> ** [https://arxiv.org/pdf/1804.07617.pdf Piece of CAKE: A Comprehensive Queue Management Solution for Home Gateways]<br /> ** [https://lwn.net/Articles/758353/ Let them run CAKE]<br /> ** [https://www.nsnam.org/docs/models/html/queue-discs.html Queue disciplines in ns-3]</div>

Tommaso https://www.nsnam.org/mediawiki/index.php?title=GSOC2025Projects&diff=13446 2025-02-16T16:00:16Z

<p>Tommaso: /* Internet models enhancements */</p> <hr /> <div>{{TOC}}<br /> <br /> This page contains 2025 Google Summer of Code project ideas for ns-3.<br /> <br /> * [https://developers.google.com/open-source/gsoc/faq GSoC Frequently Asked Questions]<br /> * [[GSOC2025ContributorGuide | ns-3's 2025 GSoC Contributor guide]]<br /> * [https://developers.google.com/open-source/gsoc/resources/guide GSoC contributor/student guide (not ns-3 specific)]<br /> * [[GSOC2025ApplicationTemplate | 2025 GSoC Contributor application template]]<br /> * [[GSOCMentorGuide | ns-3's GSoC Mentor guide]]<br /> * [https://archive.flossmanuals.net/gsocmentoring/index.html GSoC Mentor guide (not ns-3 specific)]<br /> * [[GSOCSelectionProcess | GSoC Contributor Selection Process]]<br /> * ''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/<br /> <br /> === About the ns-3 project ===<br /> <br /> ns-3 is a discrete-event network simulator, with a particular emphasis on network research and education.<br /> <br /> 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.<br /> <br /> 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.<br /> <br /> === Org admins ===<br /> <br /> 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].<br /> <br /> === Mentors ===<br /> <br /> 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.<br /> <br /> The current list of prospective mentors can be found among the ideas listed below.<br /> <br /> === How to apply ===<br /> <br /> For students or contributors interested in applying to ns-3 for GSoC, please go through the following list to get started:<br /> * Read the official [https://developers.google.com/open-source/gsoc/resources/guide GSoC contributor guide].<br /> * Read [[GSOC2025ContributorGuide |ns-3's 2025 GSoC contributor guide]]<br /> * Look through our [[#Project Ideas]] below to see if you find a project that interests you.<br /> * Review the [https://www.nsnam.org/documentation/development-tree/ tutorial and contributing guide] thoroughly, if you have not already done so.<br /> * 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.<br /> * Next, proceed to get in touch with the developers on the mailing list or Zulip chat room and refine your proposal.<br /> * 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.<br /> <br /> 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.<br /> <br /> &lt;blockquote&gt;<br /> Each project idea within a particular priority has been tagged with the following properties:<br /> * ''Required Experience:'' Languages, concepts, or packages with which applicants must be familiar.<br /> * ''Bonus Experience:'' Other experience or familiarity which would be greatly helpful to applicants for this project.<br /> * ''Interests:'' Areas of particular relevance to this project, and an indicator of where successful contributors might apply their experiences coming out of this project.<br /> * ''Difficulty:'' easy, medium or difficult<br /> * ''Recommended reading:'' pointers to documentation, papers, specific bugs, etc.<br /> <br /> 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.<br /> &lt;/blockquote&gt;<br /> <br /> === Patch requirement guidelines ===<br /> <br /> 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.<br /> <br /> === Mentors: how to participate ===<br /> <br /> 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:<br /> <br /> * 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.<br /> * 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.<br /> * 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.<br /> <br /> == Project Ideas ==<br /> <br /> '''Note to contributors:''' These ideas are not listed in any priority order.<br /> 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.<br /> <br /> === Internet models enhancements ===<br /> <br /> * [[#Upgrade the AQM Evaluation Suite for ns-3]] (small size project, 90h)<br /> * [[#Implementation_of_Alternative_Backoff_with_ECN_(ABE)]] (small size project, 90h)<br /> * [[#ICMP socket and generate/handle ICMP messages (host/net unreachable)]] (medium size project, 175h)<br /> * [[#IPv6 global routing]] (large size project, 350h)<br /> * [[#IPv6 support in Ad hoc Routing Protocols]] (large size project, 350h)<br /> <br /> === IoT models enhancements ===<br /> <br /> * [[#6LoWPAN mesh-under routing enhancements]] (medium size project, 175h)<br /> * [[#6LoWPAN neighbor discovery protocol]] (medium size project, 175h)<br /> * [[#Mesh Link Establishment (MLE) protocol ]] (large size project, 350h)<br /> * [[#Lr-WPAN (IEEE 802.15.4) preamble detection support]] (large size project, 350h)<br /> <br /> === 5G NR models enhancements ===<br /> <br /> 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.<br /> <br /> * [[#NTN example for 5G NR]] (small size project, 90h)<br /> * [[#5G NR module integration with ns-3-ai]] (large size project, 250h)<br /> * [[#Enabling 5G NR examples visualization]] (large size project, 175h)<br /> * [[#Improving 5G NR module usability through helpers]] (medium size project, 175h)<br /> <br /> == Small sized projects (90 hours) ==<br /> <br /> <br /> === NTN example for 5G NR ===<br /> <br /> 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]<br /> <br /> 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).<br /> <br /> 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.<br /> <br /> * Required Experience: C++ programming, understanding of 5G NR, LTE, and wireless networks<br /> * Interests: 5G NR simulations<br /> * Difficulty: Medium.<br /> * 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.<br /> <br /> === Upgrade the AQM Evaluation Suite for ns-3 ===<br /> <br /> Mentors: [mailto:tahiliani.nitk@gmail.com Mohit P. Tahiliani]<br /> <br /> 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.<br /> <br /> * ''Required Experience:'' Familiarity with AQM and C++ programming.<br /> * ''Bonus Experience:'' Familiarity with traffic control model in ns-3.<br /> * ''Interests:'' Packet Scheduling algorithms, AQM algorithms and ECN.<br /> * ''Difficulty:'' Medium.<br /> * ''Recommended Reading:''<br /> ** AQM Evaluation Suite [[https://dl.acm.org/doi/abs/10.1145/3067665.3067674 Paper]] [[https://aqm-eval-suite.github.io/ Implementation]]<br /> ** [https://tools.ietf.org/html/rfc7928 RFC 7928]<br /> ** [https://www.nsnam.org/docs/models/html/traffic-control-layer.html Traffic Control Model in ns-3]<br /> * ''Patch requirement:'' Create a pull request to handle the case when an incorrect Scenario name or number is passed via command line.<br /> <br /> === Implementation of Alternative Backoff with ECN (ABE) ===<br /> <br /> Mentors: [mailto:tahiliani.nitk@gmail.com Mohit P. Tahiliani]<br /> <br /> 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.<br /> <br /> * ''Required Experience:'' Familiarity with ECN and C++ programming.<br /> * ''Bonus Experience:'' Familiarity with traffic control model in ns-3.<br /> * ''Interests:'' Packet Scheduling algorithms, AQM algorithms and ECN.<br /> * ''Difficulty:'' Medium.<br /> * ''Recommended Reading:''<br /> ** Alternative Backoff with ECN [[https://datatracker.ietf.org/doc/rfc8511 RFC 8511]] [[http://heim.ifi.uio.no/~naeemk/research/ABE/Networking2017ABE.pdf Paper]]<br /> ** [https://www.nsnam.org/docs/models/html/tcp.html#support-for-explicit-congestion-notification-ecn ECN support in ns-3]<br /> ** [https://www.nsnam.org/docs/models/html/traffic-control-layer.html Traffic Control Model in ns-3]<br /> <br /> == Medium sized projects (175 hours) ==<br /> <br /> === ICMP socket and generate/handle ICMP messages (host/net unreachable) ===<br /> <br /> Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], [mailto:manoj24.rana@gmail.com Manoj K. Rana].<br /> <br /> 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 &quot;RAW&quot; socket.<br /> 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.<br /> <br /> 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.<br /> <br /> The most important point of the implementation should be code duplicate minimization, in order to have the minimize maintenance efforts.<br /> <br /> Once the sockets are in place, beside the &quot;normal&quot; tests, it will be necessary to modify the code that is actually made obsolete by the new sockets, e.g.:<br /> * IPv6 ICMP messages (RA, RS, NA, NS, etc.),<br /> * IPv4 ICMP messages,<br /> * ICMP Echo and ICMPv6 Echo messages.<br /> and to handle properly ICMP error messages like Destination Unreachable in the Ping application.<br /> <br /> * ''Required Experience:'' Fundamentals of IPv4 and IPv6 sockets, C++ programming.<br /> * ''Interests:'' Sockets and API interface implementation.<br /> * ''Difficulty:'' Medium.<br /> * ''Recommended reading:''<br /> ** [https://man7.org/linux/man-pages/man2/socket.2.html Linux socket]<br /> ** [https://courses.cs.vt.edu/cs4254/fall04/slides/raw_1.pdf Raw Sockets and ICMP, Srinidhi Varadarajan]<br /> ** [https://gitlab.com/nsnam/ns-3-dev/-/issues/810 Issue #810]<br /> <br /> Possible tasks to fulfill the patch requirement:<br /> * Submit a patch to fix [https://gitlab.com/nsnam/ns-3-dev/-/issues/809 Issue #809]<br /> <br /> === 6LoWPAN mesh-under routing enhancements ===<br /> <br /> Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], [TBD].<br /> <br /> 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.<br /> 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.<br /> <br /> The candidate should outline what parts of code are going to be affected, and how they can be enhanced thanks to RFC 7731.<br /> <br /> * ''Required Experience:'' Fundamentals of IPv6 addressing, C++ programming.<br /> * ''Bonus Experience:'' Familiarity with mesh routing and 6LoWPAN ns-3<br /> * ''Interests:'' IPv6 mesh routing<br /> * ''Difficulty:'' Easy.<br /> * ''Recommended reading:''<br /> ** [https://www.nsnam.org/docs/models/html/sixlowpan.html#mesh-under-routing Mesh-under in ns-3 6LoWPAN]<br /> ** [https://datatracker.ietf.org/doc/html/rfc7731 RFC 7731]<br /> <br /> Possible tasks to fulfill the patch requirement:<br /> * TBD<br /> <br /> === 6LoWPAN neighbor discovery protocol ===<br /> <br /> Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], [TBD].<br /> <br /> 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.<br /> <br /> 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).<br /> <br /> 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.<br /> <br /> * ''Required Experience:'' Fundamentals of IPv6 addressing, C++ programming.<br /> * ''Bonus Experience:'' Familiarity with 6LoWPAN and 6LoWPAN-ND<br /> * ''Interests:'' IPv6 and IoT networks<br /> * ''Difficulty:'' Easy.<br /> * ''Recommended reading:''<br /> ** [https://datatracker.ietf.org/doc/html/rfc8505 RFC 8505]<br /> ** [https://datatracker.ietf.org/doc/html/rfc6775 RFC 6775]<br /> ** [https://datatracker.ietf.org/doc/html/rfc4944 RFC 4944]<br /> <br /> Possible tasks to fulfil the patch requirement:<br /> * Patch the actual 6LoWPAN-ND to remove the limitation about concurrent address registrations.<br /> <br /> === Improving 5G NR module usability through helpers ===<br /> <br /> 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]<br /> <br /> 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.<br /> <br /> 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.<br /> <br /> * Required Experience: C++ programming, understanding of 5G NR, LTE, and wireless networks<br /> * Interests: 5G NR simulations<br /> * Difficulty: Medium.<br /> * 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.<br /> <br /> === Enabling 5G NR examples visualization ===<br /> <br /> 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]<br /> <br /> 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.<br /> <br /> 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.<br /> 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].<br /> <br /> * Required Experience: C++ and Python programming, understanding of 5G NR, LTE, and wireless networks<br /> * Interests: 5G NR simulations<br /> * Difficulty: Medium.<br /> * 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.<br /> <br /> === Linux-like Loss Detection Techniques for ns-3 TCP ===<br /> <br /> Mentors: [mailto:tahiliani.nitk@gmail.com Mohit P. Tahiliani]<br /> <br /> 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.<br /> <br /> * ''Required Experience:'' Familiarity with TCP and C++ programming.<br /> * ''Bonus Experience:'' Familiarity with TCP implementation in Linux kernel.<br /> * ''Interests:'' TCP packet loss detection techniques.<br /> * ''Difficulty:'' Medium to Hard.<br /> * ''Recommended Reading:''<br /> ** Forward Acknowledgement (FACK) [[https://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.41.2559&amp;rep=rep1&amp;type=pdf Paper]] [[https://gitlab.com/nsnam/ns-3-dev/-/merge_requests/34/commits Implementation]]<br /> ** Duplicate Selective Acknowledgment (DSACK) [[https://tools.ietf.org/html/rfc2883 RFC 2883]] [[https://gitlab.com/nsnam/ns-3-dev/-/merge_requests/34/commits Implementation]]<br /> ** RACK-TLP [[https://datatracker.ietf.org/doc/html/rfc8985 RFC 8985]] [[https://gitlab.com/nsnam/ns-3-dev/-/merge_requests/34/commits Implementation]]<br /> <br /> == Large projects (350 hours) ==<br /> <br /> === IPv6 global routing ===<br /> <br /> Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], [TBD].<br /> <br /> 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).<br /> For IPv4, ns-3 provides two alternatives: GlobalRouting, and NixRouting, which just &quot;do the trick&quot; - they simply fill the routing tables in intermediate nodes, GlobalRouting using an approach similar to OSPF, NixRouting by leveraging the &quot;abstract&quot; knowledge of the network.<br /> Neither actually use any message between the nodes, so they also reduce the network overhead - something that is useful in many cases.<br /> <br /> 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.).<br /> <br /> 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.<br /> <br /> * ''Required Experience:'' Fundamentals of IPv6 addressing, C++ programming.<br /> * ''Bonus Experience:'' Familiarity with GlobalRouting implementations in ns-3<br /> * ''Interests:'' IPv6 routing<br /> * ''Difficulty:'' Medium.<br /> * ''Recommended reading:''<br /> ** [https://www.nsnam.org/docs/models/html/ipv6.html IPv6 model in ns-3]<br /> ** [https://www.nsnam.org/docs/models/html/routing-overview.html#global-centralized-routing GlobalRouting model in ns-3]<br /> <br /> Possible tasks to fulfill the patch requirement:<br /> * 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.<br /> <br /> === AODVv2 Protocol enhancements ===<br /> <br /> Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], [TBD].<br /> <br /> 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.<br /> <br /> In particular the project should address the following points: 1) AODVv2 performances, 2) AODV address compression, 3) &quot;external&quot; network routing support, 4) general model validation against the latest draft.<br /> Collaboration with the draft authors is also highly suggested.<br /> <br /> * ''Required Experience:'' Fundamentals of IPv6 addressing, C++ programming.<br /> * ''Bonus Experience:'' Familiarity with AODV implementations in ns-3 and AODVv2<br /> * ''Interests:'' Ad hoc routing<br /> * ''Difficulty:'' Medium.<br /> * ''Recommended reading:''<br /> ** [https://www.nsnam.org/docs/models/html/ipv6.html IPv6 model in ns-3]<br /> ** [https://www.nsnam.org/docs/models/html/aodv.html AODV model in ns-3]<br /> ** [https://datatracker.ietf.org/doc/draft-perkins-manet-aodvv2/05/ Ad Hoc On-demand Distance Vector Version 2 (AODVv2) Routing]<br /> <br /> Possible tasks to fulfill the patch requirement:<br /> * [https://gitlab.com/nsnam/ns-3-dev/-/issues/368 Issue #368] - aodv: aodv parameters can be set to &quot;impossible&quot; values<br /> <br /> === Mesh Link Establishment (MLE) protocol ===<br /> <br /> Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], TBD.<br /> <br /> 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.<br /> However, MLE is being used in Thread, and it can be useful to implement it.<br /> <br /> 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.<br /> <br /> * ''Required Experience:'' Fundamentals of IPv4 and IPv6 sockets, C++ programming.<br /> * ''Interests:'' Sockets and API interface implementation.<br /> * ''Difficulty:'' Hard.<br /> * ''Recommended reading:''<br /> ** [https://datatracker.ietf.org/doc/html/draft-ietf-6lo-mesh-link-establishment MLE draft]<br /> ** [https://openthread.io/guides/thread-primer/network-discovery Thread primer]<br /> ** [https://www.threadgroup.org/ThreadSpec Thread specifications]<br /> <br /> Possible tasks to fulfill the patch requirement:<br /> * TBD, contact the mentors if interested.<br /> <br /> === Lr-WPAN (IEEE 802.15.4) preamble detection support ===<br /> <br /> Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], [mailto:alramonet@is.tokushima-u.ac.jp Alberto Gallegos Ramonet].<br /> <br /> 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<br /> 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<br /> itself has many added benefits.<br /> <br /> 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.<br /> <br /> As usual, reduction of code duplicity and a flexible scalable design is desired (e.g. Allow the inclusion of different preambles in the future).<br /> <br /> * ''Required Experience:'' Basic understanding of IEEE 802.15.4, C++ programming.<br /> * ''Bonus Experience:'' PHY process familiarity, Familiarity with ns-3's Lr-WPAN<br /> * ''Interests:'' Lr-WPAN, MAC and PHY designs<br /> * ''Difficulty:'' Medium.<br /> * ''Recommended reading:''<br /> ** [https://ieeexplore.ieee.org/document/1700009 IEEE 802.15.4-2006]<br /> ** [https://ieeexplore.ieee.org/document/7460875 IEEE 802.15.4-2015]<br /> ** [https://www.nsnam.org/docs/models/html/lr-wpan.html ns-3 lr-wpan module]<br /> <br /> Possible tasks to fulfill the patch requirement:<br /> * TBD, contact the mentors if interested.<br /> <br /> === 5G NR module integration with ns-3-ai ===<br /> <br /> 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]<br /> <br /> 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.<br /> <br /> 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.<br /> For more specific guidelines, please view this [https://docs.google.com/document/d/1cQLIF1cdft1yj3vyWrjrxN2xDJMx8PuWaa9NP_nKf64/edit?usp=sharing Google document].<br /> <br /> * Required Experience: C++ programming, understanding of 5G NR, LTE, and wireless networks<br /> * Interests: 5G NR simulations<br /> * Difficulty: Medium.<br /> * 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.<br /> <br /> === Linux-like CAKE queue discipline for ns-3 ===<br /> <br /> Mentors: [mailto:tahiliani.nitk@gmail.com Mohit P. Tahiliani]<br /> <br /> 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.<br /> <br /> * ''Required Experience:'' Familiarity with queue disciplines, TCP and C++ programming.<br /> * ''Bonus Experience:'' Familiarity with CAKE framework in Linux 4.19<br /> * ''Interests:'' Active Queue Management, Packet scheduling and TCP.<br /> * ''Difficulty:'' Medium to Hard<br /> * ''Recommended reading:''<br /> ** [https://arxiv.org/pdf/1804.07617.pdf Piece of CAKE: A Comprehensive Queue Management Solution for Home Gateways]<br /> ** [https://lwn.net/Articles/758353/ Let them run CAKE]<br /> ** [https://www.nsnam.org/docs/models/html/queue-discs.html Queue disciplines in ns-3]</div>

Tommaso https://www.nsnam.org/mediawiki/index.php?title=GSOC2025Projects&diff=13445 2025-02-16T15:59:50Z

<p>Tommaso: /* Project Ideas */</p> <hr /> <div>{{TOC}}<br /> <br /> This page contains 2025 Google Summer of Code project ideas for ns-3.<br /> <br /> * [https://developers.google.com/open-source/gsoc/faq GSoC Frequently Asked Questions]<br /> * [[GSOC2025ContributorGuide | ns-3's 2025 GSoC Contributor guide]]<br /> * [https://developers.google.com/open-source/gsoc/resources/guide GSoC contributor/student guide (not ns-3 specific)]<br /> * [[GSOC2025ApplicationTemplate | 2025 GSoC Contributor application template]]<br /> * [[GSOCMentorGuide | ns-3's GSoC Mentor guide]]<br /> * [https://archive.flossmanuals.net/gsocmentoring/index.html GSoC Mentor guide (not ns-3 specific)]<br /> * [[GSOCSelectionProcess | GSoC Contributor Selection Process]]<br /> * ''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/<br /> <br /> === About the ns-3 project ===<br /> <br /> ns-3 is a discrete-event network simulator, with a particular emphasis on network research and education.<br /> <br /> 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.<br /> <br /> 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.<br /> <br /> === Org admins ===<br /> <br /> 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].<br /> <br /> === Mentors ===<br /> <br /> 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.<br /> <br /> The current list of prospective mentors can be found among the ideas listed below.<br /> <br /> === How to apply ===<br /> <br /> For students or contributors interested in applying to ns-3 for GSoC, please go through the following list to get started:<br /> * Read the official [https://developers.google.com/open-source/gsoc/resources/guide GSoC contributor guide].<br /> * Read [[GSOC2025ContributorGuide |ns-3's 2025 GSoC contributor guide]]<br /> * Look through our [[#Project Ideas]] below to see if you find a project that interests you.<br /> * Review the [https://www.nsnam.org/documentation/development-tree/ tutorial and contributing guide] thoroughly, if you have not already done so.<br /> * 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.<br /> * Next, proceed to get in touch with the developers on the mailing list or Zulip chat room and refine your proposal.<br /> * 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.<br /> <br /> 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.<br /> <br /> &lt;blockquote&gt;<br /> Each project idea within a particular priority has been tagged with the following properties:<br /> * ''Required Experience:'' Languages, concepts, or packages with which applicants must be familiar.<br /> * ''Bonus Experience:'' Other experience or familiarity which would be greatly helpful to applicants for this project.<br /> * ''Interests:'' Areas of particular relevance to this project, and an indicator of where successful contributors might apply their experiences coming out of this project.<br /> * ''Difficulty:'' easy, medium or difficult<br /> * ''Recommended reading:'' pointers to documentation, papers, specific bugs, etc.<br /> <br /> 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.<br /> &lt;/blockquote&gt;<br /> <br /> === Patch requirement guidelines ===<br /> <br /> 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.<br /> <br /> === Mentors: how to participate ===<br /> <br /> 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:<br /> <br /> * 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.<br /> * 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.<br /> * 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.<br /> <br /> == Project Ideas ==<br /> <br /> '''Note to contributors:''' These ideas are not listed in any priority order.<br /> 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.<br /> <br /> === Internet models enhancements ===<br /> <br /> * [[#Upgrade_the_AQM_Evaluation_Suite_for_ns-3]] (small size project, 90h)<br /> * [[#Implementation_of_Alternative_Backoff_with_ECN_(ABE)]] (small size project, 90h)<br /> * [[#ICMP socket and generate/handle ICMP messages (host/net unreachable)]] (medium size project, 175h)<br /> * [[#IPv6 global routing]] (large size project, 350h)<br /> * [[#IPv6 support in Ad hoc Routing Protocols]] (large size project, 350h)<br /> <br /> === IoT models enhancements ===<br /> <br /> * [[#6LoWPAN mesh-under routing enhancements]] (medium size project, 175h)<br /> * [[#6LoWPAN neighbor discovery protocol]] (medium size project, 175h)<br /> * [[#Mesh Link Establishment (MLE) protocol ]] (large size project, 350h)<br /> * [[#Lr-WPAN (IEEE 802.15.4) preamble detection support]] (large size project, 350h)<br /> <br /> === 5G NR models enhancements ===<br /> <br /> 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.<br /> <br /> * [[#NTN example for 5G NR]] (small size project, 90h)<br /> * [[#5G NR module integration with ns-3-ai]] (large size project, 250h)<br /> * [[#Enabling 5G NR examples visualization]] (large size project, 175h)<br /> * [[#Improving 5G NR module usability through helpers]] (medium size project, 175h)<br /> <br /> == Small sized projects (90 hours) ==<br /> <br /> <br /> === NTN example for 5G NR ===<br /> <br /> 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]<br /> <br /> 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).<br /> <br /> 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.<br /> <br /> * Required Experience: C++ programming, understanding of 5G NR, LTE, and wireless networks<br /> * Interests: 5G NR simulations<br /> * Difficulty: Medium.<br /> * 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.<br /> <br /> === Upgrade the AQM Evaluation Suite for ns-3 ===<br /> <br /> Mentors: [mailto:tahiliani.nitk@gmail.com Mohit P. Tahiliani]<br /> <br /> 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.<br /> <br /> * ''Required Experience:'' Familiarity with AQM and C++ programming.<br /> * ''Bonus Experience:'' Familiarity with traffic control model in ns-3.<br /> * ''Interests:'' Packet Scheduling algorithms, AQM algorithms and ECN.<br /> * ''Difficulty:'' Medium.<br /> * ''Recommended Reading:''<br /> ** AQM Evaluation Suite [[https://dl.acm.org/doi/abs/10.1145/3067665.3067674 Paper]] [[https://aqm-eval-suite.github.io/ Implementation]]<br /> ** [https://tools.ietf.org/html/rfc7928 RFC 7928]<br /> ** [https://www.nsnam.org/docs/models/html/traffic-control-layer.html Traffic Control Model in ns-3]<br /> * ''Patch requirement:'' Create a pull request to handle the case when an incorrect Scenario name or number is passed via command line.<br /> <br /> === Implementation of Alternative Backoff with ECN (ABE) ===<br /> <br /> Mentors: [mailto:tahiliani.nitk@gmail.com Mohit P. Tahiliani]<br /> <br /> 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.<br /> <br /> * ''Required Experience:'' Familiarity with ECN and C++ programming.<br /> * ''Bonus Experience:'' Familiarity with traffic control model in ns-3.<br /> * ''Interests:'' Packet Scheduling algorithms, AQM algorithms and ECN.<br /> * ''Difficulty:'' Medium.<br /> * ''Recommended Reading:''<br /> ** Alternative Backoff with ECN [[https://datatracker.ietf.org/doc/rfc8511 RFC 8511]] [[http://heim.ifi.uio.no/~naeemk/research/ABE/Networking2017ABE.pdf Paper]]<br /> ** [https://www.nsnam.org/docs/models/html/tcp.html#support-for-explicit-congestion-notification-ecn ECN support in ns-3]<br /> ** [https://www.nsnam.org/docs/models/html/traffic-control-layer.html Traffic Control Model in ns-3]<br /> <br /> == Medium sized projects (175 hours) ==<br /> <br /> === ICMP socket and generate/handle ICMP messages (host/net unreachable) ===<br /> <br /> Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], [mailto:manoj24.rana@gmail.com Manoj K. Rana].<br /> <br /> 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 &quot;RAW&quot; socket.<br /> 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.<br /> <br /> 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.<br /> <br /> The most important point of the implementation should be code duplicate minimization, in order to have the minimize maintenance efforts.<br /> <br /> Once the sockets are in place, beside the &quot;normal&quot; tests, it will be necessary to modify the code that is actually made obsolete by the new sockets, e.g.:<br /> * IPv6 ICMP messages (RA, RS, NA, NS, etc.),<br /> * IPv4 ICMP messages,<br /> * ICMP Echo and ICMPv6 Echo messages.<br /> and to handle properly ICMP error messages like Destination Unreachable in the Ping application.<br /> <br /> * ''Required Experience:'' Fundamentals of IPv4 and IPv6 sockets, C++ programming.<br /> * ''Interests:'' Sockets and API interface implementation.<br /> * ''Difficulty:'' Medium.<br /> * ''Recommended reading:''<br /> ** [https://man7.org/linux/man-pages/man2/socket.2.html Linux socket]<br /> ** [https://courses.cs.vt.edu/cs4254/fall04/slides/raw_1.pdf Raw Sockets and ICMP, Srinidhi Varadarajan]<br /> ** [https://gitlab.com/nsnam/ns-3-dev/-/issues/810 Issue #810]<br /> <br /> Possible tasks to fulfill the patch requirement:<br /> * Submit a patch to fix [https://gitlab.com/nsnam/ns-3-dev/-/issues/809 Issue #809]<br /> <br /> === 6LoWPAN mesh-under routing enhancements ===<br /> <br /> Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], [TBD].<br /> <br /> 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.<br /> 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.<br /> <br /> The candidate should outline what parts of code are going to be affected, and how they can be enhanced thanks to RFC 7731.<br /> <br /> * ''Required Experience:'' Fundamentals of IPv6 addressing, C++ programming.<br /> * ''Bonus Experience:'' Familiarity with mesh routing and 6LoWPAN ns-3<br /> * ''Interests:'' IPv6 mesh routing<br /> * ''Difficulty:'' Easy.<br /> * ''Recommended reading:''<br /> ** [https://www.nsnam.org/docs/models/html/sixlowpan.html#mesh-under-routing Mesh-under in ns-3 6LoWPAN]<br /> ** [https://datatracker.ietf.org/doc/html/rfc7731 RFC 7731]<br /> <br /> Possible tasks to fulfill the patch requirement:<br /> * TBD<br /> <br /> === 6LoWPAN neighbor discovery protocol ===<br /> <br /> Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], [TBD].<br /> <br /> 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.<br /> <br /> 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).<br /> <br /> 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.<br /> <br /> * ''Required Experience:'' Fundamentals of IPv6 addressing, C++ programming.<br /> * ''Bonus Experience:'' Familiarity with 6LoWPAN and 6LoWPAN-ND<br /> * ''Interests:'' IPv6 and IoT networks<br /> * ''Difficulty:'' Easy.<br /> * ''Recommended reading:''<br /> ** [https://datatracker.ietf.org/doc/html/rfc8505 RFC 8505]<br /> ** [https://datatracker.ietf.org/doc/html/rfc6775 RFC 6775]<br /> ** [https://datatracker.ietf.org/doc/html/rfc4944 RFC 4944]<br /> <br /> Possible tasks to fulfil the patch requirement:<br /> * Patch the actual 6LoWPAN-ND to remove the limitation about concurrent address registrations.<br /> <br /> === Improving 5G NR module usability through helpers ===<br /> <br /> 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]<br /> <br /> 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.<br /> <br /> 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.<br /> <br /> * Required Experience: C++ programming, understanding of 5G NR, LTE, and wireless networks<br /> * Interests: 5G NR simulations<br /> * Difficulty: Medium.<br /> * 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.<br /> <br /> === Enabling 5G NR examples visualization ===<br /> <br /> 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]<br /> <br /> 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.<br /> <br /> 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.<br /> 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].<br /> <br /> * Required Experience: C++ and Python programming, understanding of 5G NR, LTE, and wireless networks<br /> * Interests: 5G NR simulations<br /> * Difficulty: Medium.<br /> * 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.<br /> <br /> === Linux-like Loss Detection Techniques for ns-3 TCP ===<br /> <br /> Mentors: [mailto:tahiliani.nitk@gmail.com Mohit P. Tahiliani]<br /> <br /> 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.<br /> <br /> * ''Required Experience:'' Familiarity with TCP and C++ programming.<br /> * ''Bonus Experience:'' Familiarity with TCP implementation in Linux kernel.<br /> * ''Interests:'' TCP packet loss detection techniques.<br /> * ''Difficulty:'' Medium to Hard.<br /> * ''Recommended Reading:''<br /> ** Forward Acknowledgement (FACK) [[https://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.41.2559&amp;rep=rep1&amp;type=pdf Paper]] [[https://gitlab.com/nsnam/ns-3-dev/-/merge_requests/34/commits Implementation]]<br /> ** Duplicate Selective Acknowledgment (DSACK) [[https://tools.ietf.org/html/rfc2883 RFC 2883]] [[https://gitlab.com/nsnam/ns-3-dev/-/merge_requests/34/commits Implementation]]<br /> ** RACK-TLP [[https://datatracker.ietf.org/doc/html/rfc8985 RFC 8985]] [[https://gitlab.com/nsnam/ns-3-dev/-/merge_requests/34/commits Implementation]]<br /> <br /> == Large projects (350 hours) ==<br /> <br /> === IPv6 global routing ===<br /> <br /> Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], [TBD].<br /> <br /> 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).<br /> For IPv4, ns-3 provides two alternatives: GlobalRouting, and NixRouting, which just &quot;do the trick&quot; - they simply fill the routing tables in intermediate nodes, GlobalRouting using an approach similar to OSPF, NixRouting by leveraging the &quot;abstract&quot; knowledge of the network.<br /> Neither actually use any message between the nodes, so they also reduce the network overhead - something that is useful in many cases.<br /> <br /> 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.).<br /> <br /> 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.<br /> <br /> * ''Required Experience:'' Fundamentals of IPv6 addressing, C++ programming.<br /> * ''Bonus Experience:'' Familiarity with GlobalRouting implementations in ns-3<br /> * ''Interests:'' IPv6 routing<br /> * ''Difficulty:'' Medium.<br /> * ''Recommended reading:''<br /> ** [https://www.nsnam.org/docs/models/html/ipv6.html IPv6 model in ns-3]<br /> ** [https://www.nsnam.org/docs/models/html/routing-overview.html#global-centralized-routing GlobalRouting model in ns-3]<br /> <br /> Possible tasks to fulfill the patch requirement:<br /> * 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.<br /> <br /> === AODVv2 Protocol enhancements ===<br /> <br /> Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], [TBD].<br /> <br /> 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.<br /> <br /> In particular the project should address the following points: 1) AODVv2 performances, 2) AODV address compression, 3) &quot;external&quot; network routing support, 4) general model validation against the latest draft.<br /> Collaboration with the draft authors is also highly suggested.<br /> <br /> * ''Required Experience:'' Fundamentals of IPv6 addressing, C++ programming.<br /> * ''Bonus Experience:'' Familiarity with AODV implementations in ns-3 and AODVv2<br /> * ''Interests:'' Ad hoc routing<br /> * ''Difficulty:'' Medium.<br /> * ''Recommended reading:''<br /> ** [https://www.nsnam.org/docs/models/html/ipv6.html IPv6 model in ns-3]<br /> ** [https://www.nsnam.org/docs/models/html/aodv.html AODV model in ns-3]<br /> ** [https://datatracker.ietf.org/doc/draft-perkins-manet-aodvv2/05/ Ad Hoc On-demand Distance Vector Version 2 (AODVv2) Routing]<br /> <br /> Possible tasks to fulfill the patch requirement:<br /> * [https://gitlab.com/nsnam/ns-3-dev/-/issues/368 Issue #368] - aodv: aodv parameters can be set to &quot;impossible&quot; values<br /> <br /> === Mesh Link Establishment (MLE) protocol ===<br /> <br /> Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], TBD.<br /> <br /> 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.<br /> However, MLE is being used in Thread, and it can be useful to implement it.<br /> <br /> 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.<br /> <br /> * ''Required Experience:'' Fundamentals of IPv4 and IPv6 sockets, C++ programming.<br /> * ''Interests:'' Sockets and API interface implementation.<br /> * ''Difficulty:'' Hard.<br /> * ''Recommended reading:''<br /> ** [https://datatracker.ietf.org/doc/html/draft-ietf-6lo-mesh-link-establishment MLE draft]<br /> ** [https://openthread.io/guides/thread-primer/network-discovery Thread primer]<br /> ** [https://www.threadgroup.org/ThreadSpec Thread specifications]<br /> <br /> Possible tasks to fulfill the patch requirement:<br /> * TBD, contact the mentors if interested.<br /> <br /> === Lr-WPAN (IEEE 802.15.4) preamble detection support ===<br /> <br /> Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], [mailto:alramonet@is.tokushima-u.ac.jp Alberto Gallegos Ramonet].<br /> <br /> 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<br /> 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<br /> itself has many added benefits.<br /> <br /> 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.<br /> <br /> As usual, reduction of code duplicity and a flexible scalable design is desired (e.g. Allow the inclusion of different preambles in the future).<br /> <br /> * ''Required Experience:'' Basic understanding of IEEE 802.15.4, C++ programming.<br /> * ''Bonus Experience:'' PHY process familiarity, Familiarity with ns-3's Lr-WPAN<br /> * ''Interests:'' Lr-WPAN, MAC and PHY designs<br /> * ''Difficulty:'' Medium.<br /> * ''Recommended reading:''<br /> ** [https://ieeexplore.ieee.org/document/1700009 IEEE 802.15.4-2006]<br /> ** [https://ieeexplore.ieee.org/document/7460875 IEEE 802.15.4-2015]<br /> ** [https://www.nsnam.org/docs/models/html/lr-wpan.html ns-3 lr-wpan module]<br /> <br /> Possible tasks to fulfill the patch requirement:<br /> * TBD, contact the mentors if interested.<br /> <br /> === 5G NR module integration with ns-3-ai ===<br /> <br /> 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]<br /> <br /> 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.<br /> <br /> 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.<br /> For more specific guidelines, please view this [https://docs.google.com/document/d/1cQLIF1cdft1yj3vyWrjrxN2xDJMx8PuWaa9NP_nKf64/edit?usp=sharing Google document].<br /> <br /> * Required Experience: C++ programming, understanding of 5G NR, LTE, and wireless networks<br /> * Interests: 5G NR simulations<br /> * Difficulty: Medium.<br /> * 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.<br /> <br /> === Linux-like CAKE queue discipline for ns-3 ===<br /> <br /> Mentors: [mailto:tahiliani.nitk@gmail.com Mohit P. Tahiliani]<br /> <br /> 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.<br /> <br /> * ''Required Experience:'' Familiarity with queue disciplines, TCP and C++ programming.<br /> * ''Bonus Experience:'' Familiarity with CAKE framework in Linux 4.19<br /> * ''Interests:'' Active Queue Management, Packet scheduling and TCP.<br /> * ''Difficulty:'' Medium to Hard<br /> * ''Recommended reading:''<br /> ** [https://arxiv.org/pdf/1804.07617.pdf Piece of CAKE: A Comprehensive Queue Management Solution for Home Gateways]<br /> ** [https://lwn.net/Articles/758353/ Let them run CAKE]<br /> ** [https://www.nsnam.org/docs/models/html/queue-discs.html Queue disciplines in ns-3]</div>

Tommaso https://www.nsnam.org/mediawiki/index.php?title=GSOC2025Projects&diff=13444 2025-02-14T19:22:32Z

<p>Tommaso: /* Lr-WPAN (IEEE 802.15.4) preamble detection support */</p> <hr /> <div>{{TOC}}<br /> <br /> This page contains 2025 Google Summer of Code project ideas for ns-3.<br /> <br /> * [https://developers.google.com/open-source/gsoc/faq GSoC Frequently Asked Questions]<br /> * [[GSOC2025ContributorGuide | ns-3's 2025 GSoC Contributor guide]]<br /> * [https://developers.google.com/open-source/gsoc/resources/guide GSoC contributor/student guide (not ns-3 specific)]<br /> * [[GSOC2025ApplicationTemplate | 2025 GSoC Contributor application template]]<br /> * [[GSOCMentorGuide | ns-3's GSoC Mentor guide]]<br /> * [https://archive.flossmanuals.net/gsocmentoring/index.html GSoC Mentor guide (not ns-3 specific)]<br /> * [[GSOCSelectionProcess | GSoC Contributor Selection Process]]<br /> * ''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/<br /> <br /> === About the ns-3 project ===<br /> <br /> ns-3 is a discrete-event network simulator, with a particular emphasis on network research and education.<br /> <br /> 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.<br /> <br /> 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.<br /> <br /> === Org admins ===<br /> <br /> 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].<br /> <br /> === Mentors ===<br /> <br /> 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.<br /> <br /> The current list of prospective mentors can be found among the ideas listed below.<br /> <br /> === How to apply ===<br /> <br /> For students or contributors interested in applying to ns-3 for GSoC, please go through the following list to get started:<br /> * Read the official [https://developers.google.com/open-source/gsoc/resources/guide GSoC contributor guide].<br /> * Read [[GSOC2025ContributorGuide |ns-3's 2025 GSoC contributor guide]]<br /> * Look through our [[#Project Ideas]] below to see if you find a project that interests you.<br /> * Review the [https://www.nsnam.org/documentation/development-tree/ tutorial and contributing guide] thoroughly, if you have not already done so.<br /> * 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.<br /> * Next, proceed to get in touch with the developers on the mailing list or Zulip chat room and refine your proposal.<br /> * 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.<br /> <br /> 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.<br /> <br /> &lt;blockquote&gt;<br /> Each project idea within a particular priority has been tagged with the following properties:<br /> * ''Required Experience:'' Languages, concepts, or packages with which applicants must be familiar.<br /> * ''Bonus Experience:'' Other experience or familiarity which would be greatly helpful to applicants for this project.<br /> * ''Interests:'' Areas of particular relevance to this project, and an indicator of where successful contributors might apply their experiences coming out of this project.<br /> * ''Difficulty:'' easy, medium or difficult<br /> * ''Recommended reading:'' pointers to documentation, papers, specific bugs, etc.<br /> <br /> 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.<br /> &lt;/blockquote&gt;<br /> <br /> === Patch requirement guidelines ===<br /> <br /> 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.<br /> <br /> === Mentors: how to participate ===<br /> <br /> 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:<br /> <br /> * 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.<br /> * 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.<br /> * 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.<br /> <br /> == Project Ideas ==<br /> <br /> '''Note to contributors:''' These ideas are not listed in any priority order.<br /> 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.<br /> <br /> === Internet models enhancements ===<br /> <br /> * [[#ICMP socket and generate/handle ICMP messages (host/net unreachable)]] (medium size project, 175h)<br /> * [[#IPv6 global routing]] (large size project, 350h)<br /> * [[#IPv6 support in Ad hoc Routing Protocols]] (large size project, 350h)<br /> <br /> === IoT models enhancements ===<br /> <br /> * [[#6LoWPAN mesh-under routing enhancements]] (medium size project, 175h)<br /> * [[#6LoWPAN neighbor discovery protocol]] (medium size project, 175h)<br /> * [[#Mesh Link Establishment (MLE) protocol ]] (large size project, 350h)<br /> * [[#Lr-WPAN (IEEE 802.15.4) preamble detection support]] (large size project, 350h)<br /> <br /> === 5G NR models enhancements ===<br /> <br /> 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.<br /> <br /> * [[#NTN example for 5G NR]] (small size project, 90h)<br /> * [[#5G NR module integration with ns-3-ai]] (large size project, 250h)<br /> * [[#Enabling 5G NR examples visualization]] (large size project, 175h)<br /> * [[#Improving 5G NR module usability through helpers]] (medium size project, 175h)<br /> <br /> == Small sized projects (90 hours) ==<br /> <br /> <br /> === NTN example for 5G NR ===<br /> <br /> 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]<br /> <br /> 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).<br /> <br /> 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.<br /> <br /> * Required Experience: C++ programming, understanding of 5G NR, LTE, and wireless networks<br /> * Interests: 5G NR simulations<br /> * Difficulty: Medium.<br /> * 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.<br /> <br /> === Upgrade the AQM Evaluation Suite for ns-3 ===<br /> <br /> Mentors: [mailto:tahiliani.nitk@gmail.com Mohit P. Tahiliani]<br /> <br /> 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.<br /> <br /> * ''Required Experience:'' Familiarity with AQM and C++ programming.<br /> * ''Bonus Experience:'' Familiarity with traffic control model in ns-3.<br /> * ''Interests:'' Packet Scheduling algorithms, AQM algorithms and ECN.<br /> * ''Difficulty:'' Medium.<br /> * ''Recommended Reading:''<br /> ** AQM Evaluation Suite [[https://dl.acm.org/doi/abs/10.1145/3067665.3067674 Paper]] [[https://aqm-eval-suite.github.io/ Implementation]]<br /> ** [https://tools.ietf.org/html/rfc7928 RFC 7928]<br /> ** [https://www.nsnam.org/docs/models/html/traffic-control-layer.html Traffic Control Model in ns-3]<br /> * ''Patch requirement:'' Create a pull request to handle the case when an incorrect Scenario name or number is passed via command line.<br /> <br /> === Implementation of Alternative Backoff with ECN (ABE) ===<br /> <br /> Mentors: [mailto:tahiliani.nitk@gmail.com Mohit P. Tahiliani]<br /> <br /> 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.<br /> <br /> * ''Required Experience:'' Familiarity with ECN and C++ programming.<br /> * ''Bonus Experience:'' Familiarity with traffic control model in ns-3.<br /> * ''Interests:'' Packet Scheduling algorithms, AQM algorithms and ECN.<br /> * ''Difficulty:'' Medium.<br /> * ''Recommended Reading:''<br /> ** Alternative Backoff with ECN [[https://datatracker.ietf.org/doc/rfc8511 RFC 8511]] [[http://heim.ifi.uio.no/~naeemk/research/ABE/Networking2017ABE.pdf Paper]]<br /> ** [https://www.nsnam.org/docs/models/html/tcp.html#support-for-explicit-congestion-notification-ecn ECN support in ns-3]<br /> ** [https://www.nsnam.org/docs/models/html/traffic-control-layer.html Traffic Control Model in ns-3]<br /> <br /> == Medium sized projects (175 hours) ==<br /> <br /> === ICMP socket and generate/handle ICMP messages (host/net unreachable) ===<br /> <br /> Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], [mailto:manoj24.rana@gmail.com Manoj K. Rana].<br /> <br /> 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 &quot;RAW&quot; socket.<br /> 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.<br /> <br /> 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.<br /> <br /> The most important point of the implementation should be code duplicate minimization, in order to have the minimize maintenance efforts.<br /> <br /> Once the sockets are in place, beside the &quot;normal&quot; tests, it will be necessary to modify the code that is actually made obsolete by the new sockets, e.g.:<br /> * IPv6 ICMP messages (RA, RS, NA, NS, etc.),<br /> * IPv4 ICMP messages,<br /> * ICMP Echo and ICMPv6 Echo messages.<br /> and to handle properly ICMP error messages like Destination Unreachable in the Ping application.<br /> <br /> * ''Required Experience:'' Fundamentals of IPv4 and IPv6 sockets, C++ programming.<br /> * ''Interests:'' Sockets and API interface implementation.<br /> * ''Difficulty:'' Medium.<br /> * ''Recommended reading:''<br /> ** [https://man7.org/linux/man-pages/man2/socket.2.html Linux socket]<br /> ** [https://courses.cs.vt.edu/cs4254/fall04/slides/raw_1.pdf Raw Sockets and ICMP, Srinidhi Varadarajan]<br /> ** [https://gitlab.com/nsnam/ns-3-dev/-/issues/810 Issue #810]<br /> <br /> Possible tasks to fulfill the patch requirement:<br /> * Submit a patch to fix [https://gitlab.com/nsnam/ns-3-dev/-/issues/809 Issue #809]<br /> <br /> === 6LoWPAN mesh-under routing enhancements ===<br /> <br /> Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], [TBD].<br /> <br /> 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.<br /> 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.<br /> <br /> The candidate should outline what parts of code are going to be affected, and how they can be enhanced thanks to RFC 7731.<br /> <br /> * ''Required Experience:'' Fundamentals of IPv6 addressing, C++ programming.<br /> * ''Bonus Experience:'' Familiarity with mesh routing and 6LoWPAN ns-3<br /> * ''Interests:'' IPv6 mesh routing<br /> * ''Difficulty:'' Easy.<br /> * ''Recommended reading:''<br /> ** [https://www.nsnam.org/docs/models/html/sixlowpan.html#mesh-under-routing Mesh-under in ns-3 6LoWPAN]<br /> ** [https://datatracker.ietf.org/doc/html/rfc7731 RFC 7731]<br /> <br /> Possible tasks to fulfill the patch requirement:<br /> * TBD<br /> <br /> === 6LoWPAN neighbor discovery protocol ===<br /> <br /> Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], [TBD].<br /> <br /> 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.<br /> <br /> 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).<br /> <br /> 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.<br /> <br /> * ''Required Experience:'' Fundamentals of IPv6 addressing, C++ programming.<br /> * ''Bonus Experience:'' Familiarity with 6LoWPAN and 6LoWPAN-ND<br /> * ''Interests:'' IPv6 and IoT networks<br /> * ''Difficulty:'' Easy.<br /> * ''Recommended reading:''<br /> ** [https://datatracker.ietf.org/doc/html/rfc8505 RFC 8505]<br /> ** [https://datatracker.ietf.org/doc/html/rfc6775 RFC 6775]<br /> ** [https://datatracker.ietf.org/doc/html/rfc4944 RFC 4944]<br /> <br /> Possible tasks to fulfil the patch requirement:<br /> * Patch the actual 6LoWPAN-ND to remove the limitation about concurrent address registrations.<br /> <br /> === Improving 5G NR module usability through helpers ===<br /> <br /> 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]<br /> <br /> 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.<br /> <br /> 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.<br /> <br /> * Required Experience: C++ programming, understanding of 5G NR, LTE, and wireless networks<br /> * Interests: 5G NR simulations<br /> * Difficulty: Medium.<br /> * 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.<br /> <br /> === Enabling 5G NR examples visualization ===<br /> <br /> 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]<br /> <br /> 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.<br /> <br /> 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.<br /> 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].<br /> <br /> * Required Experience: C++ and Python programming, understanding of 5G NR, LTE, and wireless networks<br /> * Interests: 5G NR simulations<br /> * Difficulty: Medium.<br /> * 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.<br /> <br /> === Linux-like Loss Detection Techniques for ns-3 TCP ===<br /> <br /> Mentors: [mailto:tahiliani.nitk@gmail.com Mohit P. Tahiliani]<br /> <br /> 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.<br /> <br /> * ''Required Experience:'' Familiarity with TCP and C++ programming.<br /> * ''Bonus Experience:'' Familiarity with TCP implementation in Linux kernel.<br /> * ''Interests:'' TCP packet loss detection techniques.<br /> * ''Difficulty:'' Medium to Hard.<br /> * ''Recommended Reading:''<br /> ** Forward Acknowledgement (FACK) [[https://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.41.2559&amp;rep=rep1&amp;type=pdf Paper]] [[https://gitlab.com/nsnam/ns-3-dev/-/merge_requests/34/commits Implementation]]<br /> ** Duplicate Selective Acknowledgment (DSACK) [[https://tools.ietf.org/html/rfc2883 RFC 2883]] [[https://gitlab.com/nsnam/ns-3-dev/-/merge_requests/34/commits Implementation]]<br /> ** RACK-TLP [[https://datatracker.ietf.org/doc/html/rfc8985 RFC 8985]] [[https://gitlab.com/nsnam/ns-3-dev/-/merge_requests/34/commits Implementation]]<br /> <br /> == Large projects (350 hours) ==<br /> <br /> === IPv6 global routing ===<br /> <br /> Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], [TBD].<br /> <br /> 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).<br /> For IPv4, ns-3 provides two alternatives: GlobalRouting, and NixRouting, which just &quot;do the trick&quot; - they simply fill the routing tables in intermediate nodes, GlobalRouting using an approach similar to OSPF, NixRouting by leveraging the &quot;abstract&quot; knowledge of the network.<br /> Neither actually use any message between the nodes, so they also reduce the network overhead - something that is useful in many cases.<br /> <br /> 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.).<br /> <br /> 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.<br /> <br /> * ''Required Experience:'' Fundamentals of IPv6 addressing, C++ programming.<br /> * ''Bonus Experience:'' Familiarity with GlobalRouting implementations in ns-3<br /> * ''Interests:'' IPv6 routing<br /> * ''Difficulty:'' Medium.<br /> * ''Recommended reading:''<br /> ** [https://www.nsnam.org/docs/models/html/ipv6.html IPv6 model in ns-3]<br /> ** [https://www.nsnam.org/docs/models/html/routing-overview.html#global-centralized-routing GlobalRouting model in ns-3]<br /> <br /> Possible tasks to fulfill the patch requirement:<br /> * 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.<br /> <br /> === AODVv2 Protocol enhancements ===<br /> <br /> Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], [TBD].<br /> <br /> 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.<br /> <br /> In particular the project should address the following points: 1) AODVv2 performances, 2) AODV address compression, 3) &quot;external&quot; network routing support, 4) general model validation against the latest draft.<br /> Collaboration with the draft authors is also highly suggested.<br /> <br /> * ''Required Experience:'' Fundamentals of IPv6 addressing, C++ programming.<br /> * ''Bonus Experience:'' Familiarity with AODV implementations in ns-3 and AODVv2<br /> * ''Interests:'' Ad hoc routing<br /> * ''Difficulty:'' Medium.<br /> * ''Recommended reading:''<br /> ** [https://www.nsnam.org/docs/models/html/ipv6.html IPv6 model in ns-3]<br /> ** [https://www.nsnam.org/docs/models/html/aodv.html AODV model in ns-3]<br /> ** [https://datatracker.ietf.org/doc/draft-perkins-manet-aodvv2/05/ Ad Hoc On-demand Distance Vector Version 2 (AODVv2) Routing]<br /> <br /> Possible tasks to fulfill the patch requirement:<br /> * [https://gitlab.com/nsnam/ns-3-dev/-/issues/368 Issue #368] - aodv: aodv parameters can be set to &quot;impossible&quot; values<br /> <br /> === Mesh Link Establishment (MLE) protocol ===<br /> <br /> Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], TBD.<br /> <br /> 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.<br /> However, MLE is being used in Thread, and it can be useful to implement it.<br /> <br /> 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.<br /> <br /> * ''Required Experience:'' Fundamentals of IPv4 and IPv6 sockets, C++ programming.<br /> * ''Interests:'' Sockets and API interface implementation.<br /> * ''Difficulty:'' Hard.<br /> * ''Recommended reading:''<br /> ** [https://datatracker.ietf.org/doc/html/draft-ietf-6lo-mesh-link-establishment MLE draft]<br /> ** [https://openthread.io/guides/thread-primer/network-discovery Thread primer]<br /> ** [https://www.threadgroup.org/ThreadSpec Thread specifications]<br /> <br /> Possible tasks to fulfill the patch requirement:<br /> * TBD, contact the mentors if interested.<br /> <br /> === Lr-WPAN (IEEE 802.15.4) preamble detection support ===<br /> <br /> Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], [mailto:alramonet@is.tokushima-u.ac.jp Alberto Gallegos Ramonet].<br /> <br /> 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<br /> 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<br /> itself has many added benefits.<br /> <br /> 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.<br /> <br /> As usual, reduction of code duplicity and a flexible scalable design is desired (e.g. Allow the inclusion of different preambles in the future).<br /> <br /> * ''Required Experience:'' Basic understanding of IEEE 802.15.4, C++ programming.<br /> * ''Bonus Experience:'' PHY process familiarity, Familiarity with ns-3's Lr-WPAN<br /> * ''Interests:'' Lr-WPAN, MAC and PHY designs<br /> * ''Difficulty:'' Medium.<br /> * ''Recommended reading:''<br /> ** [https://ieeexplore.ieee.org/document/1700009 IEEE 802.15.4-2006]<br /> ** [https://ieeexplore.ieee.org/document/7460875 IEEE 802.15.4-2015]<br /> ** [https://www.nsnam.org/docs/models/html/lr-wpan.html ns-3 lr-wpan module]<br /> <br /> Possible tasks to fulfill the patch requirement:<br /> * TBD, contact the mentors if interested.<br /> <br /> === 5G NR module integration with ns-3-ai ===<br /> <br /> 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]<br /> <br /> 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.<br /> <br /> 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.<br /> For more specific guidelines, please view this [https://docs.google.com/document/d/1cQLIF1cdft1yj3vyWrjrxN2xDJMx8PuWaa9NP_nKf64/edit?usp=sharing Google document].<br /> <br /> * Required Experience: C++ programming, understanding of 5G NR, LTE, and wireless networks<br /> * Interests: 5G NR simulations<br /> * Difficulty: Medium.<br /> * 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.<br /> <br /> === Linux-like CAKE queue discipline for ns-3 ===<br /> <br /> Mentors: [mailto:tahiliani.nitk@gmail.com Mohit P. Tahiliani]<br /> <br /> 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.<br /> <br /> * ''Required Experience:'' Familiarity with queue disciplines, TCP and C++ programming.<br /> * ''Bonus Experience:'' Familiarity with CAKE framework in Linux 4.19<br /> * ''Interests:'' Active Queue Management, Packet scheduling and TCP.<br /> * ''Difficulty:'' Medium to Hard<br /> * ''Recommended reading:''<br /> ** [https://arxiv.org/pdf/1804.07617.pdf Piece of CAKE: A Comprehensive Queue Management Solution for Home Gateways]<br /> ** [https://lwn.net/Articles/758353/ Let them run CAKE]<br /> ** [https://www.nsnam.org/docs/models/html/queue-discs.html Queue disciplines in ns-3]</div>

Tommaso https://www.nsnam.org/mediawiki/index.php?title=GSOC2025Projects&diff=13442 2025-02-14T19:22:23Z

<p>Tommaso: /* AODVv2 Protocol enhancements */</p> <hr /> <div>{{TOC}}<br /> <br /> This page contains 2025 Google Summer of Code project ideas for ns-3.<br /> <br /> * [https://developers.google.com/open-source/gsoc/faq GSoC Frequently Asked Questions]<br /> * [[GSOC2025ContributorGuide | ns-3's 2025 GSoC Contributor guide]]<br /> * [https://developers.google.com/open-source/gsoc/resources/guide GSoC contributor/student guide (not ns-3 specific)]<br /> * [[GSOC2025ApplicationTemplate | 2025 GSoC Contributor application template]]<br /> * [[GSOCMentorGuide | ns-3's GSoC Mentor guide]]<br /> * [https://archive.flossmanuals.net/gsocmentoring/index.html GSoC Mentor guide (not ns-3 specific)]<br /> * [[GSOCSelectionProcess | GSoC Contributor Selection Process]]<br /> * ''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/<br /> <br /> === About the ns-3 project ===<br /> <br /> ns-3 is a discrete-event network simulator, with a particular emphasis on network research and education.<br /> <br /> 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.<br /> <br /> 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.<br /> <br /> === Org admins ===<br /> <br /> 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].<br /> <br /> === Mentors ===<br /> <br /> 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.<br /> <br /> The current list of prospective mentors can be found among the ideas listed below.<br /> <br /> === How to apply ===<br /> <br /> For students or contributors interested in applying to ns-3 for GSoC, please go through the following list to get started:<br /> * Read the official [https://developers.google.com/open-source/gsoc/resources/guide GSoC contributor guide].<br /> * Read [[GSOC2025ContributorGuide |ns-3's 2025 GSoC contributor guide]]<br /> * Look through our [[#Project Ideas]] below to see if you find a project that interests you.<br /> * Review the [https://www.nsnam.org/documentation/development-tree/ tutorial and contributing guide] thoroughly, if you have not already done so.<br /> * 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.<br /> * Next, proceed to get in touch with the developers on the mailing list or Zulip chat room and refine your proposal.<br /> * 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.<br /> <br /> 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.<br /> <br /> &lt;blockquote&gt;<br /> Each project idea within a particular priority has been tagged with the following properties:<br /> * ''Required Experience:'' Languages, concepts, or packages with which applicants must be familiar.<br /> * ''Bonus Experience:'' Other experience or familiarity which would be greatly helpful to applicants for this project.<br /> * ''Interests:'' Areas of particular relevance to this project, and an indicator of where successful contributors might apply their experiences coming out of this project.<br /> * ''Difficulty:'' easy, medium or difficult<br /> * ''Recommended reading:'' pointers to documentation, papers, specific bugs, etc.<br /> <br /> 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.<br /> &lt;/blockquote&gt;<br /> <br /> === Patch requirement guidelines ===<br /> <br /> 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.<br /> <br /> === Mentors: how to participate ===<br /> <br /> 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:<br /> <br /> * 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.<br /> * 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.<br /> * 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.<br /> <br /> == Project Ideas ==<br /> <br /> '''Note to contributors:''' These ideas are not listed in any priority order.<br /> 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.<br /> <br /> === Internet models enhancements ===<br /> <br /> * [[#ICMP socket and generate/handle ICMP messages (host/net unreachable)]] (medium size project, 175h)<br /> * [[#IPv6 global routing]] (large size project, 350h)<br /> * [[#IPv6 support in Ad hoc Routing Protocols]] (large size project, 350h)<br /> <br /> === IoT models enhancements ===<br /> <br /> * [[#6LoWPAN mesh-under routing enhancements]] (medium size project, 175h)<br /> * [[#6LoWPAN neighbor discovery protocol]] (medium size project, 175h)<br /> * [[#Mesh Link Establishment (MLE) protocol ]] (large size project, 350h)<br /> * [[#Lr-WPAN (IEEE 802.15.4) preamble detection support]] (large size project, 350h)<br /> <br /> === 5G NR models enhancements ===<br /> <br /> 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.<br /> <br /> * [[#NTN example for 5G NR]] (small size project, 90h)<br /> * [[#5G NR module integration with ns-3-ai]] (large size project, 250h)<br /> * [[#Enabling 5G NR examples visualization]] (large size project, 175h)<br /> * [[#Improving 5G NR module usability through helpers]] (medium size project, 175h)<br /> <br /> == Small sized projects (90 hours) ==<br /> <br /> <br /> === NTN example for 5G NR ===<br /> <br /> 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]<br /> <br /> 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).<br /> <br /> 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.<br /> <br /> * Required Experience: C++ programming, understanding of 5G NR, LTE, and wireless networks<br /> * Interests: 5G NR simulations<br /> * Difficulty: Medium.<br /> * 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.<br /> <br /> === Upgrade the AQM Evaluation Suite for ns-3 ===<br /> <br /> Mentors: [mailto:tahiliani.nitk@gmail.com Mohit P. Tahiliani]<br /> <br /> 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.<br /> <br /> * ''Required Experience:'' Familiarity with AQM and C++ programming.<br /> * ''Bonus Experience:'' Familiarity with traffic control model in ns-3.<br /> * ''Interests:'' Packet Scheduling algorithms, AQM algorithms and ECN.<br /> * ''Difficulty:'' Medium.<br /> * ''Recommended Reading:''<br /> ** AQM Evaluation Suite [[https://dl.acm.org/doi/abs/10.1145/3067665.3067674 Paper]] [[https://aqm-eval-suite.github.io/ Implementation]]<br /> ** [https://tools.ietf.org/html/rfc7928 RFC 7928]<br /> ** [https://www.nsnam.org/docs/models/html/traffic-control-layer.html Traffic Control Model in ns-3]<br /> * ''Patch requirement:'' Create a pull request to handle the case when an incorrect Scenario name or number is passed via command line.<br /> <br /> == Medium sized projects (175 hours) ==<br /> <br /> === ICMP socket and generate/handle ICMP messages (host/net unreachable) ===<br /> <br /> Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], [mailto:manoj24.rana@gmail.com Manoj K. Rana].<br /> <br /> 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 &quot;RAW&quot; socket.<br /> 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.<br /> <br /> 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.<br /> <br /> The most important point of the implementation should be code duplicate minimization, in order to have the minimize maintenance efforts.<br /> <br /> Once the sockets are in place, beside the &quot;normal&quot; tests, it will be necessary to modify the code that is actually made obsolete by the new sockets, e.g.:<br /> * IPv6 ICMP messages (RA, RS, NA, NS, etc.),<br /> * IPv4 ICMP messages,<br /> * ICMP Echo and ICMPv6 Echo messages.<br /> and to handle properly ICMP error messages like Destination Unreachable in the Ping application.<br /> <br /> * ''Required Experience:'' Fundamentals of IPv4 and IPv6 sockets, C++ programming.<br /> * ''Interests:'' Sockets and API interface implementation.<br /> * ''Difficulty:'' Medium.<br /> * ''Recommended reading:''<br /> ** [https://man7.org/linux/man-pages/man2/socket.2.html Linux socket]<br /> ** [https://courses.cs.vt.edu/cs4254/fall04/slides/raw_1.pdf Raw Sockets and ICMP, Srinidhi Varadarajan]<br /> ** [https://gitlab.com/nsnam/ns-3-dev/-/issues/810 Issue #810]<br /> <br /> Possible tasks to fulfill the patch requirement:<br /> * Submit a patch to fix [https://gitlab.com/nsnam/ns-3-dev/-/issues/809 Issue #809]<br /> <br /> === 6LoWPAN mesh-under routing enhancements ===<br /> <br /> Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], [TBD].<br /> <br /> 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.<br /> 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.<br /> <br /> The candidate should outline what parts of code are going to be affected, and how they can be enhanced thanks to RFC 7731.<br /> <br /> * ''Required Experience:'' Fundamentals of IPv6 addressing, C++ programming.<br /> * ''Bonus Experience:'' Familiarity with mesh routing and 6LoWPAN ns-3<br /> * ''Interests:'' IPv6 mesh routing<br /> * ''Difficulty:'' Easy.<br /> * ''Recommended reading:''<br /> ** [https://www.nsnam.org/docs/models/html/sixlowpan.html#mesh-under-routing Mesh-under in ns-3 6LoWPAN]<br /> ** [https://datatracker.ietf.org/doc/html/rfc7731 RFC 7731]<br /> <br /> Possible tasks to fulfill the patch requirement:<br /> * TBD<br /> <br /> === 6LoWPAN neighbor discovery protocol ===<br /> <br /> Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], [TBD].<br /> <br /> 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.<br /> <br /> 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).<br /> <br /> 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.<br /> <br /> * ''Required Experience:'' Fundamentals of IPv6 addressing, C++ programming.<br /> * ''Bonus Experience:'' Familiarity with 6LoWPAN and 6LoWPAN-ND<br /> * ''Interests:'' IPv6 and IoT networks<br /> * ''Difficulty:'' Easy.<br /> * ''Recommended reading:''<br /> ** [https://datatracker.ietf.org/doc/html/rfc8505 RFC 8505]<br /> ** [https://datatracker.ietf.org/doc/html/rfc6775 RFC 6775]<br /> ** [https://datatracker.ietf.org/doc/html/rfc4944 RFC 4944]<br /> <br /> Possible tasks to fulfil the patch requirement:<br /> * Patch the actual 6LoWPAN-ND to remove the limitation about concurrent address registrations.<br /> <br /> === Improving 5G NR module usability through helpers ===<br /> <br /> 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]<br /> <br /> 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.<br /> <br /> 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.<br /> <br /> * Required Experience: C++ programming, understanding of 5G NR, LTE, and wireless networks<br /> * Interests: 5G NR simulations<br /> * Difficulty: Medium.<br /> * 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.<br /> <br /> === Enabling 5G NR examples visualization ===<br /> <br /> 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]<br /> <br /> 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.<br /> <br /> 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.<br /> 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].<br /> <br /> * Required Experience: C++ and Python programming, understanding of 5G NR, LTE, and wireless networks<br /> * Interests: 5G NR simulations<br /> * Difficulty: Medium.<br /> * 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.<br /> <br /> === Linux-like Loss Detection Techniques for ns-3 TCP ===<br /> <br /> Mentors: [mailto:tahiliani.nitk@gmail.com Mohit P. Tahiliani]<br /> <br /> 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.<br /> <br /> * ''Required Experience:'' Familiarity with TCP and C++ programming.<br /> * ''Bonus Experience:'' Familiarity with TCP implementation in Linux kernel.<br /> * ''Interests:'' TCP packet loss detection techniques.<br /> * ''Difficulty:'' Medium to Hard.<br /> * ''Recommended Reading:''<br /> ** Forward Acknowledgement (FACK) [[https://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.41.2559&amp;rep=rep1&amp;type=pdf Paper]] [[https://gitlab.com/nsnam/ns-3-dev/-/merge_requests/34/commits Implementation]]<br /> ** Duplicate Selective Acknowledgment (DSACK) [[https://tools.ietf.org/html/rfc2883 RFC 2883]] [[https://gitlab.com/nsnam/ns-3-dev/-/merge_requests/34/commits Implementation]]<br /> ** RACK-TLP [[https://datatracker.ietf.org/doc/html/rfc8985 RFC 8985]] [[https://gitlab.com/nsnam/ns-3-dev/-/merge_requests/34/commits Implementation]]<br /> <br /> == Large projects (350 hours) ==<br /> <br /> === IPv6 global routing ===<br /> <br /> Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], [TBD].<br /> <br /> 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).<br /> For IPv4, ns-3 provides two alternatives: GlobalRouting, and NixRouting, which just &quot;do the trick&quot; - they simply fill the routing tables in intermediate nodes, GlobalRouting using an approach similar to OSPF, NixRouting by leveraging the &quot;abstract&quot; knowledge of the network.<br /> Neither actually use any message between the nodes, so they also reduce the network overhead - something that is useful in many cases.<br /> <br /> 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.).<br /> <br /> 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.<br /> <br /> * ''Required Experience:'' Fundamentals of IPv6 addressing, C++ programming.<br /> * ''Bonus Experience:'' Familiarity with GlobalRouting implementations in ns-3<br /> * ''Interests:'' IPv6 routing<br /> * ''Difficulty:'' Medium.<br /> * ''Recommended reading:''<br /> ** [https://www.nsnam.org/docs/models/html/ipv6.html IPv6 model in ns-3]<br /> ** [https://www.nsnam.org/docs/models/html/routing-overview.html#global-centralized-routing GlobalRouting model in ns-3]<br /> <br /> Possible tasks to fulfill the patch requirement:<br /> * 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.<br /> <br /> === AODVv2 Protocol enhancements ===<br /> <br /> Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], [TBD].<br /> <br /> 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.<br /> <br /> In particular the project should address the following points: 1) AODVv2 performances, 2) AODV address compression, 3) &quot;external&quot; network routing support, 4) general model validation against the latest draft.<br /> Collaboration with the draft authors is also highly suggested.<br /> <br /> * ''Required Experience:'' Fundamentals of IPv6 addressing, C++ programming.<br /> * ''Bonus Experience:'' Familiarity with AODV implementations in ns-3 and AODVv2<br /> * ''Interests:'' Ad hoc routing<br /> * ''Difficulty:'' Medium.<br /> * ''Recommended reading:''<br /> ** [https://www.nsnam.org/docs/models/html/ipv6.html IPv6 model in ns-3]<br /> ** [https://www.nsnam.org/docs/models/html/aodv.html AODV model in ns-3]<br /> ** [https://datatracker.ietf.org/doc/draft-perkins-manet-aodvv2/05/ Ad Hoc On-demand Distance Vector Version 2 (AODVv2) Routing]<br /> <br /> Possible tasks to fulfill the patch requirement:<br /> * [https://gitlab.com/nsnam/ns-3-dev/-/issues/368 Issue #368] - aodv: aodv parameters can be set to &quot;impossible&quot; values<br /> <br /> === Mesh Link Establishment (MLE) protocol ===<br /> <br /> Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], TBD.<br /> <br /> 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.<br /> However, MLE is being used in Thread, and it can be useful to implement it.<br /> <br /> 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.<br /> <br /> * ''Required Experience:'' Fundamentals of IPv4 and IPv6 sockets, C++ programming.<br /> * ''Interests:'' Sockets and API interface implementation.<br /> * ''Difficulty:'' Hard.<br /> * ''Recommended reading:''<br /> ** [https://datatracker.ietf.org/doc/html/draft-ietf-6lo-mesh-link-establishment MLE draft]<br /> ** [https://openthread.io/guides/thread-primer/network-discovery Thread primer]<br /> ** [https://www.threadgroup.org/ThreadSpec Thread specifications]<br /> <br /> Possible tasks to fulfill the patch requirement:<br /> * TBD, contact the mentors if interested.<br /> <br /> === Lr-WPAN (IEEE 802.15.4) preamble detection support ===<br /> <br /> Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], [mailto:alramonet@is.tokushima-u.ac.jp Alberto Gallegos Ramonet].<br /> <br /> 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<br /> 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<br /> itself has many added benefits.<br /> <br /> 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.<br /> <br /> As usual, reduction of code duplicity and a flexible scalable design is desired (e.g. Allow the inclusion of different preambles in the future).<br /> <br /> * ''Required Experience:'' Basic understanding of IEEE 802.15.4, C++ programming.<br /> * ''Bonus Experience:'' PHY process familiarity, Familiarity with ns-3's Lr-WPAN<br /> * ''Interests:'' Lr-WPAN, MAC and PHY designs<br /> * ''Difficulty:'' Medium.<br /> * ''Patch requirement:'' [[GSOC2024PatchRequirement]]<br /> * ''Recommended reading:''<br /> ** [https://ieeexplore.ieee.org/document/1700009 IEEE 802.15.4-2006]<br /> ** [https://ieeexplore.ieee.org/document/7460875 IEEE 802.15.4-2015]<br /> ** [https://www.nsnam.org/docs/models/html/lr-wpan.html ns-3 lr-wpan module]<br /> <br /> Possible tasks to fulfill the patch requirement:<br /> * TBD, contact the mentors if interested.<br /> <br /> === 5G NR module integration with ns-3-ai ===<br /> <br /> 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]<br /> <br /> 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.<br /> <br /> 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.<br /> For more specific guidelines, please view this [https://docs.google.com/document/d/1cQLIF1cdft1yj3vyWrjrxN2xDJMx8PuWaa9NP_nKf64/edit?usp=sharing Google document].<br /> <br /> * Required Experience: C++ programming, understanding of 5G NR, LTE, and wireless networks<br /> * Interests: 5G NR simulations<br /> * Difficulty: Medium.<br /> * 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.<br /> <br /> === Linux-like CAKE queue discipline for ns-3 ===<br /> <br /> Mentors: [mailto:tahiliani.nitk@gmail.com Mohit P. Tahiliani]<br /> <br /> 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.<br /> <br /> * ''Required Experience:'' Familiarity with queue disciplines, TCP and C++ programming.<br /> * ''Bonus Experience:'' Familiarity with CAKE framework in Linux 4.19<br /> * ''Interests:'' Active Queue Management, Packet scheduling and TCP.<br /> * ''Difficulty:'' Medium to Hard<br /> * ''Recommended reading:''<br /> ** [https://arxiv.org/pdf/1804.07617.pdf Piece of CAKE: A Comprehensive Queue Management Solution for Home Gateways]<br /> ** [https://lwn.net/Articles/758353/ Let them run CAKE]<br /> ** [https://www.nsnam.org/docs/models/html/queue-discs.html Queue disciplines in ns-3]</div>

Tommaso https://www.nsnam.org/mediawiki/index.php?title=GSOC2025Projects&diff=13441 2025-02-14T19:22:15Z

<p>Tommaso: /* IPv6 global routing */</p> <hr /> <div>{{TOC}}<br /> <br /> This page contains 2025 Google Summer of Code project ideas for ns-3.<br /> <br /> * [https://developers.google.com/open-source/gsoc/faq GSoC Frequently Asked Questions]<br /> * [[GSOC2025ContributorGuide | ns-3's 2025 GSoC Contributor guide]]<br /> * [https://developers.google.com/open-source/gsoc/resources/guide GSoC contributor/student guide (not ns-3 specific)]<br /> * [[GSOC2025ApplicationTemplate | 2025 GSoC Contributor application template]]<br /> * [[GSOCMentorGuide | ns-3's GSoC Mentor guide]]<br /> * [https://archive.flossmanuals.net/gsocmentoring/index.html GSoC Mentor guide (not ns-3 specific)]<br /> * [[GSOCSelectionProcess | GSoC Contributor Selection Process]]<br /> * ''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/<br /> <br /> === About the ns-3 project ===<br /> <br /> ns-3 is a discrete-event network simulator, with a particular emphasis on network research and education.<br /> <br /> 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.<br /> <br /> 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.<br /> <br /> === Org admins ===<br /> <br /> 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].<br /> <br /> === Mentors ===<br /> <br /> 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.<br /> <br /> The current list of prospective mentors can be found among the ideas listed below.<br /> <br /> === How to apply ===<br /> <br /> For students or contributors interested in applying to ns-3 for GSoC, please go through the following list to get started:<br /> * Read the official [https://developers.google.com/open-source/gsoc/resources/guide GSoC contributor guide].<br /> * Read [[GSOC2025ContributorGuide |ns-3's 2025 GSoC contributor guide]]<br /> * Look through our [[#Project Ideas]] below to see if you find a project that interests you.<br /> * Review the [https://www.nsnam.org/documentation/development-tree/ tutorial and contributing guide] thoroughly, if you have not already done so.<br /> * 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.<br /> * Next, proceed to get in touch with the developers on the mailing list or Zulip chat room and refine your proposal.<br /> * 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.<br /> <br /> 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.<br /> <br /> &lt;blockquote&gt;<br /> Each project idea within a particular priority has been tagged with the following properties:<br /> * ''Required Experience:'' Languages, concepts, or packages with which applicants must be familiar.<br /> * ''Bonus Experience:'' Other experience or familiarity which would be greatly helpful to applicants for this project.<br /> * ''Interests:'' Areas of particular relevance to this project, and an indicator of where successful contributors might apply their experiences coming out of this project.<br /> * ''Difficulty:'' easy, medium or difficult<br /> * ''Recommended reading:'' pointers to documentation, papers, specific bugs, etc.<br /> <br /> 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.<br /> &lt;/blockquote&gt;<br /> <br /> === Patch requirement guidelines ===<br /> <br /> 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.<br /> <br /> === Mentors: how to participate ===<br /> <br /> 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:<br /> <br /> * 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.<br /> * 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.<br /> * 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.<br /> <br /> == Project Ideas ==<br /> <br /> '''Note to contributors:''' These ideas are not listed in any priority order.<br /> 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.<br /> <br /> === Internet models enhancements ===<br /> <br /> * [[#ICMP socket and generate/handle ICMP messages (host/net unreachable)]] (medium size project, 175h)<br /> * [[#IPv6 global routing]] (large size project, 350h)<br /> * [[#IPv6 support in Ad hoc Routing Protocols]] (large size project, 350h)<br /> <br /> === IoT models enhancements ===<br /> <br /> * [[#6LoWPAN mesh-under routing enhancements]] (medium size project, 175h)<br /> * [[#6LoWPAN neighbor discovery protocol]] (medium size project, 175h)<br /> * [[#Mesh Link Establishment (MLE) protocol ]] (large size project, 350h)<br /> * [[#Lr-WPAN (IEEE 802.15.4) preamble detection support]] (large size project, 350h)<br /> <br /> === 5G NR models enhancements ===<br /> <br /> 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.<br /> <br /> * [[#NTN example for 5G NR]] (small size project, 90h)<br /> * [[#5G NR module integration with ns-3-ai]] (large size project, 250h)<br /> * [[#Enabling 5G NR examples visualization]] (large size project, 175h)<br /> * [[#Improving 5G NR module usability through helpers]] (medium size project, 175h)<br /> <br /> == Small sized projects (90 hours) ==<br /> <br /> <br /> === NTN example for 5G NR ===<br /> <br /> 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]<br /> <br /> 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).<br /> <br /> 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.<br /> <br /> * Required Experience: C++ programming, understanding of 5G NR, LTE, and wireless networks<br /> * Interests: 5G NR simulations<br /> * Difficulty: Medium.<br /> * 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.<br /> <br /> === Upgrade the AQM Evaluation Suite for ns-3 ===<br /> <br /> Mentors: [mailto:tahiliani.nitk@gmail.com Mohit P. Tahiliani]<br /> <br /> 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.<br /> <br /> * ''Required Experience:'' Familiarity with AQM and C++ programming.<br /> * ''Bonus Experience:'' Familiarity with traffic control model in ns-3.<br /> * ''Interests:'' Packet Scheduling algorithms, AQM algorithms and ECN.<br /> * ''Difficulty:'' Medium.<br /> * ''Recommended Reading:''<br /> ** AQM Evaluation Suite [[https://dl.acm.org/doi/abs/10.1145/3067665.3067674 Paper]] [[https://aqm-eval-suite.github.io/ Implementation]]<br /> ** [https://tools.ietf.org/html/rfc7928 RFC 7928]<br /> ** [https://www.nsnam.org/docs/models/html/traffic-control-layer.html Traffic Control Model in ns-3]<br /> * ''Patch requirement:'' Create a pull request to handle the case when an incorrect Scenario name or number is passed via command line.<br /> <br /> == Medium sized projects (175 hours) ==<br /> <br /> === ICMP socket and generate/handle ICMP messages (host/net unreachable) ===<br /> <br /> Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], [mailto:manoj24.rana@gmail.com Manoj K. Rana].<br /> <br /> 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 &quot;RAW&quot; socket.<br /> 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.<br /> <br /> 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.<br /> <br /> The most important point of the implementation should be code duplicate minimization, in order to have the minimize maintenance efforts.<br /> <br /> Once the sockets are in place, beside the &quot;normal&quot; tests, it will be necessary to modify the code that is actually made obsolete by the new sockets, e.g.:<br /> * IPv6 ICMP messages (RA, RS, NA, NS, etc.),<br /> * IPv4 ICMP messages,<br /> * ICMP Echo and ICMPv6 Echo messages.<br /> and to handle properly ICMP error messages like Destination Unreachable in the Ping application.<br /> <br /> * ''Required Experience:'' Fundamentals of IPv4 and IPv6 sockets, C++ programming.<br /> * ''Interests:'' Sockets and API interface implementation.<br /> * ''Difficulty:'' Medium.<br /> * ''Recommended reading:''<br /> ** [https://man7.org/linux/man-pages/man2/socket.2.html Linux socket]<br /> ** [https://courses.cs.vt.edu/cs4254/fall04/slides/raw_1.pdf Raw Sockets and ICMP, Srinidhi Varadarajan]<br /> ** [https://gitlab.com/nsnam/ns-3-dev/-/issues/810 Issue #810]<br /> <br /> Possible tasks to fulfill the patch requirement:<br /> * Submit a patch to fix [https://gitlab.com/nsnam/ns-3-dev/-/issues/809 Issue #809]<br /> <br /> === 6LoWPAN mesh-under routing enhancements ===<br /> <br /> Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], [TBD].<br /> <br /> 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.<br /> 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.<br /> <br /> The candidate should outline what parts of code are going to be affected, and how they can be enhanced thanks to RFC 7731.<br /> <br /> * ''Required Experience:'' Fundamentals of IPv6 addressing, C++ programming.<br /> * ''Bonus Experience:'' Familiarity with mesh routing and 6LoWPAN ns-3<br /> * ''Interests:'' IPv6 mesh routing<br /> * ''Difficulty:'' Easy.<br /> * ''Recommended reading:''<br /> ** [https://www.nsnam.org/docs/models/html/sixlowpan.html#mesh-under-routing Mesh-under in ns-3 6LoWPAN]<br /> ** [https://datatracker.ietf.org/doc/html/rfc7731 RFC 7731]<br /> <br /> Possible tasks to fulfill the patch requirement:<br /> * TBD<br /> <br /> === 6LoWPAN neighbor discovery protocol ===<br /> <br /> Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], [TBD].<br /> <br /> 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.<br /> <br /> 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).<br /> <br /> 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.<br /> <br /> * ''Required Experience:'' Fundamentals of IPv6 addressing, C++ programming.<br /> * ''Bonus Experience:'' Familiarity with 6LoWPAN and 6LoWPAN-ND<br /> * ''Interests:'' IPv6 and IoT networks<br /> * ''Difficulty:'' Easy.<br /> * ''Recommended reading:''<br /> ** [https://datatracker.ietf.org/doc/html/rfc8505 RFC 8505]<br /> ** [https://datatracker.ietf.org/doc/html/rfc6775 RFC 6775]<br /> ** [https://datatracker.ietf.org/doc/html/rfc4944 RFC 4944]<br /> <br /> Possible tasks to fulfil the patch requirement:<br /> * Patch the actual 6LoWPAN-ND to remove the limitation about concurrent address registrations.<br /> <br /> === Improving 5G NR module usability through helpers ===<br /> <br /> 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]<br /> <br /> 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.<br /> <br /> 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.<br /> <br /> * Required Experience: C++ programming, understanding of 5G NR, LTE, and wireless networks<br /> * Interests: 5G NR simulations<br /> * Difficulty: Medium.<br /> * 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.<br /> <br /> === Enabling 5G NR examples visualization ===<br /> <br /> 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]<br /> <br /> 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.<br /> <br /> 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.<br /> 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].<br /> <br /> * Required Experience: C++ and Python programming, understanding of 5G NR, LTE, and wireless networks<br /> * Interests: 5G NR simulations<br /> * Difficulty: Medium.<br /> * 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.<br /> <br /> === Linux-like Loss Detection Techniques for ns-3 TCP ===<br /> <br /> Mentors: [mailto:tahiliani.nitk@gmail.com Mohit P. Tahiliani]<br /> <br /> 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.<br /> <br /> * ''Required Experience:'' Familiarity with TCP and C++ programming.<br /> * ''Bonus Experience:'' Familiarity with TCP implementation in Linux kernel.<br /> * ''Interests:'' TCP packet loss detection techniques.<br /> * ''Difficulty:'' Medium to Hard.<br /> * ''Recommended Reading:''<br /> ** Forward Acknowledgement (FACK) [[https://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.41.2559&amp;rep=rep1&amp;type=pdf Paper]] [[https://gitlab.com/nsnam/ns-3-dev/-/merge_requests/34/commits Implementation]]<br /> ** Duplicate Selective Acknowledgment (DSACK) [[https://tools.ietf.org/html/rfc2883 RFC 2883]] [[https://gitlab.com/nsnam/ns-3-dev/-/merge_requests/34/commits Implementation]]<br /> ** RACK-TLP [[https://datatracker.ietf.org/doc/html/rfc8985 RFC 8985]] [[https://gitlab.com/nsnam/ns-3-dev/-/merge_requests/34/commits Implementation]]<br /> <br /> == Large projects (350 hours) ==<br /> <br /> === IPv6 global routing ===<br /> <br /> Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], [TBD].<br /> <br /> 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).<br /> For IPv4, ns-3 provides two alternatives: GlobalRouting, and NixRouting, which just &quot;do the trick&quot; - they simply fill the routing tables in intermediate nodes, GlobalRouting using an approach similar to OSPF, NixRouting by leveraging the &quot;abstract&quot; knowledge of the network.<br /> Neither actually use any message between the nodes, so they also reduce the network overhead - something that is useful in many cases.<br /> <br /> 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.).<br /> <br /> 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.<br /> <br /> * ''Required Experience:'' Fundamentals of IPv6 addressing, C++ programming.<br /> * ''Bonus Experience:'' Familiarity with GlobalRouting implementations in ns-3<br /> * ''Interests:'' IPv6 routing<br /> * ''Difficulty:'' Medium.<br /> * ''Recommended reading:''<br /> ** [https://www.nsnam.org/docs/models/html/ipv6.html IPv6 model in ns-3]<br /> ** [https://www.nsnam.org/docs/models/html/routing-overview.html#global-centralized-routing GlobalRouting model in ns-3]<br /> <br /> Possible tasks to fulfill the patch requirement:<br /> * 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.<br /> <br /> === AODVv2 Protocol enhancements ===<br /> <br /> Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], [TBD].<br /> <br /> 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.<br /> <br /> In particular the project should address the following points: 1) AODVv2 performances, 2) AODV address compression, 3) &quot;external&quot; network routing support, 4) general model validation against the latest draft.<br /> Collaboration with the draft authors is also highly suggested.<br /> <br /> * ''Required Experience:'' Fundamentals of IPv6 addressing, C++ programming.<br /> * ''Bonus Experience:'' Familiarity with AODV implementations in ns-3 and AODVv2<br /> * ''Interests:'' Ad hoc routing<br /> * ''Difficulty:'' Medium.<br /> * ''Patch requirement:'' [[GSOC2024PatchRequirement]]<br /> * ''Recommended reading:''<br /> ** [https://www.nsnam.org/docs/models/html/ipv6.html IPv6 model in ns-3]<br /> ** [https://www.nsnam.org/docs/models/html/aodv.html AODV model in ns-3]<br /> ** [https://datatracker.ietf.org/doc/draft-perkins-manet-aodvv2/05/ Ad Hoc On-demand Distance Vector Version 2 (AODVv2) Routing]<br /> <br /> Possible tasks to fulfill the patch requirement:<br /> * [https://gitlab.com/nsnam/ns-3-dev/-/issues/368 Issue #368] - aodv: aodv parameters can be set to &quot;impossible&quot; values<br /> <br /> === Mesh Link Establishment (MLE) protocol ===<br /> <br /> Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], TBD.<br /> <br /> 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.<br /> However, MLE is being used in Thread, and it can be useful to implement it.<br /> <br /> 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.<br /> <br /> * ''Required Experience:'' Fundamentals of IPv4 and IPv6 sockets, C++ programming.<br /> * ''Interests:'' Sockets and API interface implementation.<br /> * ''Difficulty:'' Hard.<br /> * ''Recommended reading:''<br /> ** [https://datatracker.ietf.org/doc/html/draft-ietf-6lo-mesh-link-establishment MLE draft]<br /> ** [https://openthread.io/guides/thread-primer/network-discovery Thread primer]<br /> ** [https://www.threadgroup.org/ThreadSpec Thread specifications]<br /> <br /> Possible tasks to fulfill the patch requirement:<br /> * TBD, contact the mentors if interested.<br /> <br /> === Lr-WPAN (IEEE 802.15.4) preamble detection support ===<br /> <br /> Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], [mailto:alramonet@is.tokushima-u.ac.jp Alberto Gallegos Ramonet].<br /> <br /> 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<br /> 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<br /> itself has many added benefits.<br /> <br /> 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.<br /> <br /> As usual, reduction of code duplicity and a flexible scalable design is desired (e.g. Allow the inclusion of different preambles in the future).<br /> <br /> * ''Required Experience:'' Basic understanding of IEEE 802.15.4, C++ programming.<br /> * ''Bonus Experience:'' PHY process familiarity, Familiarity with ns-3's Lr-WPAN<br /> * ''Interests:'' Lr-WPAN, MAC and PHY designs<br /> * ''Difficulty:'' Medium.<br /> * ''Patch requirement:'' [[GSOC2024PatchRequirement]]<br /> * ''Recommended reading:''<br /> ** [https://ieeexplore.ieee.org/document/1700009 IEEE 802.15.4-2006]<br /> ** [https://ieeexplore.ieee.org/document/7460875 IEEE 802.15.4-2015]<br /> ** [https://www.nsnam.org/docs/models/html/lr-wpan.html ns-3 lr-wpan module]<br /> <br /> Possible tasks to fulfill the patch requirement:<br /> * TBD, contact the mentors if interested.<br /> <br /> === 5G NR module integration with ns-3-ai ===<br /> <br /> 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]<br /> <br /> 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.<br /> <br /> 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.<br /> For more specific guidelines, please view this [https://docs.google.com/document/d/1cQLIF1cdft1yj3vyWrjrxN2xDJMx8PuWaa9NP_nKf64/edit?usp=sharing Google document].<br /> <br /> * Required Experience: C++ programming, understanding of 5G NR, LTE, and wireless networks<br /> * Interests: 5G NR simulations<br /> * Difficulty: Medium.<br /> * 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.<br /> <br /> === Linux-like CAKE queue discipline for ns-3 ===<br /> <br /> Mentors: [mailto:tahiliani.nitk@gmail.com Mohit P. Tahiliani]<br /> <br /> 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.<br /> <br /> * ''Required Experience:'' Familiarity with queue disciplines, TCP and C++ programming.<br /> * ''Bonus Experience:'' Familiarity with CAKE framework in Linux 4.19<br /> * ''Interests:'' Active Queue Management, Packet scheduling and TCP.<br /> * ''Difficulty:'' Medium to Hard<br /> * ''Recommended reading:''<br /> ** [https://arxiv.org/pdf/1804.07617.pdf Piece of CAKE: A Comprehensive Queue Management Solution for Home Gateways]<br /> ** [https://lwn.net/Articles/758353/ Let them run CAKE]<br /> ** [https://www.nsnam.org/docs/models/html/queue-discs.html Queue disciplines in ns-3]</div>

Tommaso https://www.nsnam.org/mediawiki/index.php?title=GSOC2025Projects&diff=13440 2025-02-14T19:22:03Z

<p>Tommaso: /* 6LoWPAN neighbor discovery protocol */</p> <hr /> <div>{{TOC}}<br /> <br /> This page contains 2025 Google Summer of Code project ideas for ns-3.<br /> <br /> * [https://developers.google.com/open-source/gsoc/faq GSoC Frequently Asked Questions]<br /> * [[GSOC2025ContributorGuide | ns-3's 2025 GSoC Contributor guide]]<br /> * [https://developers.google.com/open-source/gsoc/resources/guide GSoC contributor/student guide (not ns-3 specific)]<br /> * [[GSOC2025ApplicationTemplate | 2025 GSoC Contributor application template]]<br /> * [[GSOCMentorGuide | ns-3's GSoC Mentor guide]]<br /> * [https://archive.flossmanuals.net/gsocmentoring/index.html GSoC Mentor guide (not ns-3 specific)]<br /> * [[GSOCSelectionProcess | GSoC Contributor Selection Process]]<br /> * ''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/<br /> <br /> === About the ns-3 project ===<br /> <br /> ns-3 is a discrete-event network simulator, with a particular emphasis on network research and education.<br /> <br /> 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.<br /> <br /> 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.<br /> <br /> === Org admins ===<br /> <br /> 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].<br /> <br /> === Mentors ===<br /> <br /> 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.<br /> <br /> The current list of prospective mentors can be found among the ideas listed below.<br /> <br /> === How to apply ===<br /> <br /> For students or contributors interested in applying to ns-3 for GSoC, please go through the following list to get started:<br /> * Read the official [https://developers.google.com/open-source/gsoc/resources/guide GSoC contributor guide].<br /> * Read [[GSOC2025ContributorGuide |ns-3's 2025 GSoC contributor guide]]<br /> * Look through our [[#Project Ideas]] below to see if you find a project that interests you.<br /> * Review the [https://www.nsnam.org/documentation/development-tree/ tutorial and contributing guide] thoroughly, if you have not already done so.<br /> * 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.<br /> * Next, proceed to get in touch with the developers on the mailing list or Zulip chat room and refine your proposal.<br /> * 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.<br /> <br /> 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.<br /> <br /> &lt;blockquote&gt;<br /> Each project idea within a particular priority has been tagged with the following properties:<br /> * ''Required Experience:'' Languages, concepts, or packages with which applicants must be familiar.<br /> * ''Bonus Experience:'' Other experience or familiarity which would be greatly helpful to applicants for this project.<br /> * ''Interests:'' Areas of particular relevance to this project, and an indicator of where successful contributors might apply their experiences coming out of this project.<br /> * ''Difficulty:'' easy, medium or difficult<br /> * ''Recommended reading:'' pointers to documentation, papers, specific bugs, etc.<br /> <br /> 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.<br /> &lt;/blockquote&gt;<br /> <br /> === Patch requirement guidelines ===<br /> <br /> 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.<br /> <br /> === Mentors: how to participate ===<br /> <br /> 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:<br /> <br /> * 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.<br /> * 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.<br /> * 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.<br /> <br /> == Project Ideas ==<br /> <br /> '''Note to contributors:''' These ideas are not listed in any priority order.<br /> 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.<br /> <br /> === Internet models enhancements ===<br /> <br /> * [[#ICMP socket and generate/handle ICMP messages (host/net unreachable)]] (medium size project, 175h)<br /> * [[#IPv6 global routing]] (large size project, 350h)<br /> * [[#IPv6 support in Ad hoc Routing Protocols]] (large size project, 350h)<br /> <br /> === IoT models enhancements ===<br /> <br /> * [[#6LoWPAN mesh-under routing enhancements]] (medium size project, 175h)<br /> * [[#6LoWPAN neighbor discovery protocol]] (medium size project, 175h)<br /> * [[#Mesh Link Establishment (MLE) protocol ]] (large size project, 350h)<br /> * [[#Lr-WPAN (IEEE 802.15.4) preamble detection support]] (large size project, 350h)<br /> <br /> === 5G NR models enhancements ===<br /> <br /> 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.<br /> <br /> * [[#NTN example for 5G NR]] (small size project, 90h)<br /> * [[#5G NR module integration with ns-3-ai]] (large size project, 250h)<br /> * [[#Enabling 5G NR examples visualization]] (large size project, 175h)<br /> * [[#Improving 5G NR module usability through helpers]] (medium size project, 175h)<br /> <br /> == Small sized projects (90 hours) ==<br /> <br /> <br /> === NTN example for 5G NR ===<br /> <br /> 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]<br /> <br /> 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).<br /> <br /> 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.<br /> <br /> * Required Experience: C++ programming, understanding of 5G NR, LTE, and wireless networks<br /> * Interests: 5G NR simulations<br /> * Difficulty: Medium.<br /> * 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.<br /> <br /> === Upgrade the AQM Evaluation Suite for ns-3 ===<br /> <br /> Mentors: [mailto:tahiliani.nitk@gmail.com Mohit P. Tahiliani]<br /> <br /> 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.<br /> <br /> * ''Required Experience:'' Familiarity with AQM and C++ programming.<br /> * ''Bonus Experience:'' Familiarity with traffic control model in ns-3.<br /> * ''Interests:'' Packet Scheduling algorithms, AQM algorithms and ECN.<br /> * ''Difficulty:'' Medium.<br /> * ''Recommended Reading:''<br /> ** AQM Evaluation Suite [[https://dl.acm.org/doi/abs/10.1145/3067665.3067674 Paper]] [[https://aqm-eval-suite.github.io/ Implementation]]<br /> ** [https://tools.ietf.org/html/rfc7928 RFC 7928]<br /> ** [https://www.nsnam.org/docs/models/html/traffic-control-layer.html Traffic Control Model in ns-3]<br /> * ''Patch requirement:'' Create a pull request to handle the case when an incorrect Scenario name or number is passed via command line.<br /> <br /> == Medium sized projects (175 hours) ==<br /> <br /> === ICMP socket and generate/handle ICMP messages (host/net unreachable) ===<br /> <br /> Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], [mailto:manoj24.rana@gmail.com Manoj K. Rana].<br /> <br /> 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 &quot;RAW&quot; socket.<br /> 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.<br /> <br /> 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.<br /> <br /> The most important point of the implementation should be code duplicate minimization, in order to have the minimize maintenance efforts.<br /> <br /> Once the sockets are in place, beside the &quot;normal&quot; tests, it will be necessary to modify the code that is actually made obsolete by the new sockets, e.g.:<br /> * IPv6 ICMP messages (RA, RS, NA, NS, etc.),<br /> * IPv4 ICMP messages,<br /> * ICMP Echo and ICMPv6 Echo messages.<br /> and to handle properly ICMP error messages like Destination Unreachable in the Ping application.<br /> <br /> * ''Required Experience:'' Fundamentals of IPv4 and IPv6 sockets, C++ programming.<br /> * ''Interests:'' Sockets and API interface implementation.<br /> * ''Difficulty:'' Medium.<br /> * ''Recommended reading:''<br /> ** [https://man7.org/linux/man-pages/man2/socket.2.html Linux socket]<br /> ** [https://courses.cs.vt.edu/cs4254/fall04/slides/raw_1.pdf Raw Sockets and ICMP, Srinidhi Varadarajan]<br /> ** [https://gitlab.com/nsnam/ns-3-dev/-/issues/810 Issue #810]<br /> <br /> Possible tasks to fulfill the patch requirement:<br /> * Submit a patch to fix [https://gitlab.com/nsnam/ns-3-dev/-/issues/809 Issue #809]<br /> <br /> === 6LoWPAN mesh-under routing enhancements ===<br /> <br /> Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], [TBD].<br /> <br /> 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.<br /> 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.<br /> <br /> The candidate should outline what parts of code are going to be affected, and how they can be enhanced thanks to RFC 7731.<br /> <br /> * ''Required Experience:'' Fundamentals of IPv6 addressing, C++ programming.<br /> * ''Bonus Experience:'' Familiarity with mesh routing and 6LoWPAN ns-3<br /> * ''Interests:'' IPv6 mesh routing<br /> * ''Difficulty:'' Easy.<br /> * ''Recommended reading:''<br /> ** [https://www.nsnam.org/docs/models/html/sixlowpan.html#mesh-under-routing Mesh-under in ns-3 6LoWPAN]<br /> ** [https://datatracker.ietf.org/doc/html/rfc7731 RFC 7731]<br /> <br /> Possible tasks to fulfill the patch requirement:<br /> * TBD<br /> <br /> === 6LoWPAN neighbor discovery protocol ===<br /> <br /> Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], [TBD].<br /> <br /> 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.<br /> <br /> 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).<br /> <br /> 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.<br /> <br /> * ''Required Experience:'' Fundamentals of IPv6 addressing, C++ programming.<br /> * ''Bonus Experience:'' Familiarity with 6LoWPAN and 6LoWPAN-ND<br /> * ''Interests:'' IPv6 and IoT networks<br /> * ''Difficulty:'' Easy.<br /> * ''Recommended reading:''<br /> ** [https://datatracker.ietf.org/doc/html/rfc8505 RFC 8505]<br /> ** [https://datatracker.ietf.org/doc/html/rfc6775 RFC 6775]<br /> ** [https://datatracker.ietf.org/doc/html/rfc4944 RFC 4944]<br /> <br /> Possible tasks to fulfil the patch requirement:<br /> * Patch the actual 6LoWPAN-ND to remove the limitation about concurrent address registrations.<br /> <br /> === Improving 5G NR module usability through helpers ===<br /> <br /> 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]<br /> <br /> 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.<br /> <br /> 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.<br /> <br /> * Required Experience: C++ programming, understanding of 5G NR, LTE, and wireless networks<br /> * Interests: 5G NR simulations<br /> * Difficulty: Medium.<br /> * 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.<br /> <br /> === Enabling 5G NR examples visualization ===<br /> <br /> 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]<br /> <br /> 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.<br /> <br /> 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.<br /> 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].<br /> <br /> * Required Experience: C++ and Python programming, understanding of 5G NR, LTE, and wireless networks<br /> * Interests: 5G NR simulations<br /> * Difficulty: Medium.<br /> * 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.<br /> <br /> === Linux-like Loss Detection Techniques for ns-3 TCP ===<br /> <br /> Mentors: [mailto:tahiliani.nitk@gmail.com Mohit P. Tahiliani]<br /> <br /> 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.<br /> <br /> * ''Required Experience:'' Familiarity with TCP and C++ programming.<br /> * ''Bonus Experience:'' Familiarity with TCP implementation in Linux kernel.<br /> * ''Interests:'' TCP packet loss detection techniques.<br /> * ''Difficulty:'' Medium to Hard.<br /> * ''Recommended Reading:''<br /> ** Forward Acknowledgement (FACK) [[https://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.41.2559&amp;rep=rep1&amp;type=pdf Paper]] [[https://gitlab.com/nsnam/ns-3-dev/-/merge_requests/34/commits Implementation]]<br /> ** Duplicate Selective Acknowledgment (DSACK) [[https://tools.ietf.org/html/rfc2883 RFC 2883]] [[https://gitlab.com/nsnam/ns-3-dev/-/merge_requests/34/commits Implementation]]<br /> ** RACK-TLP [[https://datatracker.ietf.org/doc/html/rfc8985 RFC 8985]] [[https://gitlab.com/nsnam/ns-3-dev/-/merge_requests/34/commits Implementation]]<br /> <br /> == Large projects (350 hours) ==<br /> <br /> === IPv6 global routing ===<br /> <br /> Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], [TBD].<br /> <br /> 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).<br /> For IPv4, ns-3 provides two alternatives: GlobalRouting, and NixRouting, which just &quot;do the trick&quot; - they simply fill the routing tables in intermediate nodes, GlobalRouting using an approach similar to OSPF, NixRouting by leveraging the &quot;abstract&quot; knowledge of the network.<br /> Neither actually use any message between the nodes, so they also reduce the network overhead - something that is useful in many cases.<br /> <br /> 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.).<br /> <br /> 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.<br /> <br /> * ''Required Experience:'' Fundamentals of IPv6 addressing, C++ programming.<br /> * ''Bonus Experience:'' Familiarity with GlobalRouting implementations in ns-3<br /> * ''Interests:'' IPv6 routing<br /> * ''Difficulty:'' Medium.<br /> * ''Patch requirement:'' [[GSOC2024PatchRequirement]]<br /> * ''Recommended reading:''<br /> ** [https://www.nsnam.org/docs/models/html/ipv6.html IPv6 model in ns-3]<br /> ** [https://www.nsnam.org/docs/models/html/routing-overview.html#global-centralized-routing GlobalRouting model in ns-3]<br /> <br /> Possible tasks to fulfill the patch requirement:<br /> * 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.<br /> <br /> === AODVv2 Protocol enhancements ===<br /> <br /> Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], [TBD].<br /> <br /> 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.<br /> <br /> In particular the project should address the following points: 1) AODVv2 performances, 2) AODV address compression, 3) &quot;external&quot; network routing support, 4) general model validation against the latest draft.<br /> Collaboration with the draft authors is also highly suggested.<br /> <br /> * ''Required Experience:'' Fundamentals of IPv6 addressing, C++ programming.<br /> * ''Bonus Experience:'' Familiarity with AODV implementations in ns-3 and AODVv2<br /> * ''Interests:'' Ad hoc routing<br /> * ''Difficulty:'' Medium.<br /> * ''Patch requirement:'' [[GSOC2024PatchRequirement]]<br /> * ''Recommended reading:''<br /> ** [https://www.nsnam.org/docs/models/html/ipv6.html IPv6 model in ns-3]<br /> ** [https://www.nsnam.org/docs/models/html/aodv.html AODV model in ns-3]<br /> ** [https://datatracker.ietf.org/doc/draft-perkins-manet-aodvv2/05/ Ad Hoc On-demand Distance Vector Version 2 (AODVv2) Routing]<br /> <br /> Possible tasks to fulfill the patch requirement:<br /> * [https://gitlab.com/nsnam/ns-3-dev/-/issues/368 Issue #368] - aodv: aodv parameters can be set to &quot;impossible&quot; values<br /> <br /> === Mesh Link Establishment (MLE) protocol ===<br /> <br /> Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], TBD.<br /> <br /> 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.<br /> However, MLE is being used in Thread, and it can be useful to implement it.<br /> <br /> 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.<br /> <br /> * ''Required Experience:'' Fundamentals of IPv4 and IPv6 sockets, C++ programming.<br /> * ''Interests:'' Sockets and API interface implementation.<br /> * ''Difficulty:'' Hard.<br /> * ''Recommended reading:''<br /> ** [https://datatracker.ietf.org/doc/html/draft-ietf-6lo-mesh-link-establishment MLE draft]<br /> ** [https://openthread.io/guides/thread-primer/network-discovery Thread primer]<br /> ** [https://www.threadgroup.org/ThreadSpec Thread specifications]<br /> <br /> Possible tasks to fulfill the patch requirement:<br /> * TBD, contact the mentors if interested.<br /> <br /> === Lr-WPAN (IEEE 802.15.4) preamble detection support ===<br /> <br /> Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], [mailto:alramonet@is.tokushima-u.ac.jp Alberto Gallegos Ramonet].<br /> <br /> 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<br /> 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<br /> itself has many added benefits.<br /> <br /> 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.<br /> <br /> As usual, reduction of code duplicity and a flexible scalable design is desired (e.g. Allow the inclusion of different preambles in the future).<br /> <br /> * ''Required Experience:'' Basic understanding of IEEE 802.15.4, C++ programming.<br /> * ''Bonus Experience:'' PHY process familiarity, Familiarity with ns-3's Lr-WPAN<br /> * ''Interests:'' Lr-WPAN, MAC and PHY designs<br /> * ''Difficulty:'' Medium.<br /> * ''Patch requirement:'' [[GSOC2024PatchRequirement]]<br /> * ''Recommended reading:''<br /> ** [https://ieeexplore.ieee.org/document/1700009 IEEE 802.15.4-2006]<br /> ** [https://ieeexplore.ieee.org/document/7460875 IEEE 802.15.4-2015]<br /> ** [https://www.nsnam.org/docs/models/html/lr-wpan.html ns-3 lr-wpan module]<br /> <br /> Possible tasks to fulfill the patch requirement:<br /> * TBD, contact the mentors if interested.<br /> <br /> === 5G NR module integration with ns-3-ai ===<br /> <br /> 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]<br /> <br /> 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.<br /> <br /> 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.<br /> For more specific guidelines, please view this [https://docs.google.com/document/d/1cQLIF1cdft1yj3vyWrjrxN2xDJMx8PuWaa9NP_nKf64/edit?usp=sharing Google document].<br /> <br /> * Required Experience: C++ programming, understanding of 5G NR, LTE, and wireless networks<br /> * Interests: 5G NR simulations<br /> * Difficulty: Medium.<br /> * 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.<br /> <br /> === Linux-like CAKE queue discipline for ns-3 ===<br /> <br /> Mentors: [mailto:tahiliani.nitk@gmail.com Mohit P. Tahiliani]<br /> <br /> 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.<br /> <br /> * ''Required Experience:'' Familiarity with queue disciplines, TCP and C++ programming.<br /> * ''Bonus Experience:'' Familiarity with CAKE framework in Linux 4.19<br /> * ''Interests:'' Active Queue Management, Packet scheduling and TCP.<br /> * ''Difficulty:'' Medium to Hard<br /> * ''Recommended reading:''<br /> ** [https://arxiv.org/pdf/1804.07617.pdf Piece of CAKE: A Comprehensive Queue Management Solution for Home Gateways]<br /> ** [https://lwn.net/Articles/758353/ Let them run CAKE]<br /> ** [https://www.nsnam.org/docs/models/html/queue-discs.html Queue disciplines in ns-3]</div>

Tommaso https://www.nsnam.org/mediawiki/index.php?title=GSOC2025Projects&diff=13439 2025-02-14T19:21:52Z

<p>Tommaso: /* 6LoWPAN mesh-under routing enhancements */</p> <hr /> <div>{{TOC}}<br /> <br /> This page contains 2025 Google Summer of Code project ideas for ns-3.<br /> <br /> * [https://developers.google.com/open-source/gsoc/faq GSoC Frequently Asked Questions]<br /> * [[GSOC2025ContributorGuide | ns-3's 2025 GSoC Contributor guide]]<br /> * [https://developers.google.com/open-source/gsoc/resources/guide GSoC contributor/student guide (not ns-3 specific)]<br /> * [[GSOC2025ApplicationTemplate | 2025 GSoC Contributor application template]]<br /> * [[GSOCMentorGuide | ns-3's GSoC Mentor guide]]<br /> * [https://archive.flossmanuals.net/gsocmentoring/index.html GSoC Mentor guide (not ns-3 specific)]<br /> * [[GSOCSelectionProcess | GSoC Contributor Selection Process]]<br /> * ''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/<br /> <br /> === About the ns-3 project ===<br /> <br /> ns-3 is a discrete-event network simulator, with a particular emphasis on network research and education.<br /> <br /> 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.<br /> <br /> 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.<br /> <br /> === Org admins ===<br /> <br /> 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].<br /> <br /> === Mentors ===<br /> <br /> 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.<br /> <br /> The current list of prospective mentors can be found among the ideas listed below.<br /> <br /> === How to apply ===<br /> <br /> For students or contributors interested in applying to ns-3 for GSoC, please go through the following list to get started:<br /> * Read the official [https://developers.google.com/open-source/gsoc/resources/guide GSoC contributor guide].<br /> * Read [[GSOC2025ContributorGuide |ns-3's 2025 GSoC contributor guide]]<br /> * Look through our [[#Project Ideas]] below to see if you find a project that interests you.<br /> * Review the [https://www.nsnam.org/documentation/development-tree/ tutorial and contributing guide] thoroughly, if you have not already done so.<br /> * 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.<br /> * Next, proceed to get in touch with the developers on the mailing list or Zulip chat room and refine your proposal.<br /> * 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.<br /> <br /> 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.<br /> <br /> &lt;blockquote&gt;<br /> Each project idea within a particular priority has been tagged with the following properties:<br /> * ''Required Experience:'' Languages, concepts, or packages with which applicants must be familiar.<br /> * ''Bonus Experience:'' Other experience or familiarity which would be greatly helpful to applicants for this project.<br /> * ''Interests:'' Areas of particular relevance to this project, and an indicator of where successful contributors might apply their experiences coming out of this project.<br /> * ''Difficulty:'' easy, medium or difficult<br /> * ''Recommended reading:'' pointers to documentation, papers, specific bugs, etc.<br /> <br /> 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.<br /> &lt;/blockquote&gt;<br /> <br /> === Patch requirement guidelines ===<br /> <br /> 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.<br /> <br /> === Mentors: how to participate ===<br /> <br /> 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:<br /> <br /> * 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.<br /> * 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.<br /> * 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.<br /> <br /> == Project Ideas ==<br /> <br /> '''Note to contributors:''' These ideas are not listed in any priority order.<br /> 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.<br /> <br /> === Internet models enhancements ===<br /> <br /> * [[#ICMP socket and generate/handle ICMP messages (host/net unreachable)]] (medium size project, 175h)<br /> * [[#IPv6 global routing]] (large size project, 350h)<br /> * [[#IPv6 support in Ad hoc Routing Protocols]] (large size project, 350h)<br /> <br /> === IoT models enhancements ===<br /> <br /> * [[#6LoWPAN mesh-under routing enhancements]] (medium size project, 175h)<br /> * [[#6LoWPAN neighbor discovery protocol]] (medium size project, 175h)<br /> * [[#Mesh Link Establishment (MLE) protocol ]] (large size project, 350h)<br /> * [[#Lr-WPAN (IEEE 802.15.4) preamble detection support]] (large size project, 350h)<br /> <br /> === 5G NR models enhancements ===<br /> <br /> 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.<br /> <br /> * [[#NTN example for 5G NR]] (small size project, 90h)<br /> * [[#5G NR module integration with ns-3-ai]] (large size project, 250h)<br /> * [[#Enabling 5G NR examples visualization]] (large size project, 175h)<br /> * [[#Improving 5G NR module usability through helpers]] (medium size project, 175h)<br /> <br /> == Small sized projects (90 hours) ==<br /> <br /> <br /> === NTN example for 5G NR ===<br /> <br /> 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]<br /> <br /> 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).<br /> <br /> 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.<br /> <br /> * Required Experience: C++ programming, understanding of 5G NR, LTE, and wireless networks<br /> * Interests: 5G NR simulations<br /> * Difficulty: Medium.<br /> * 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.<br /> <br /> === Upgrade the AQM Evaluation Suite for ns-3 ===<br /> <br /> Mentors: [mailto:tahiliani.nitk@gmail.com Mohit P. Tahiliani]<br /> <br /> 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.<br /> <br /> * ''Required Experience:'' Familiarity with AQM and C++ programming.<br /> * ''Bonus Experience:'' Familiarity with traffic control model in ns-3.<br /> * ''Interests:'' Packet Scheduling algorithms, AQM algorithms and ECN.<br /> * ''Difficulty:'' Medium.<br /> * ''Recommended Reading:''<br /> ** AQM Evaluation Suite [[https://dl.acm.org/doi/abs/10.1145/3067665.3067674 Paper]] [[https://aqm-eval-suite.github.io/ Implementation]]<br /> ** [https://tools.ietf.org/html/rfc7928 RFC 7928]<br /> ** [https://www.nsnam.org/docs/models/html/traffic-control-layer.html Traffic Control Model in ns-3]<br /> * ''Patch requirement:'' Create a pull request to handle the case when an incorrect Scenario name or number is passed via command line.<br /> <br /> == Medium sized projects (175 hours) ==<br /> <br /> === ICMP socket and generate/handle ICMP messages (host/net unreachable) ===<br /> <br /> Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], [mailto:manoj24.rana@gmail.com Manoj K. Rana].<br /> <br /> 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 &quot;RAW&quot; socket.<br /> 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.<br /> <br /> 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.<br /> <br /> The most important point of the implementation should be code duplicate minimization, in order to have the minimize maintenance efforts.<br /> <br /> Once the sockets are in place, beside the &quot;normal&quot; tests, it will be necessary to modify the code that is actually made obsolete by the new sockets, e.g.:<br /> * IPv6 ICMP messages (RA, RS, NA, NS, etc.),<br /> * IPv4 ICMP messages,<br /> * ICMP Echo and ICMPv6 Echo messages.<br /> and to handle properly ICMP error messages like Destination Unreachable in the Ping application.<br /> <br /> * ''Required Experience:'' Fundamentals of IPv4 and IPv6 sockets, C++ programming.<br /> * ''Interests:'' Sockets and API interface implementation.<br /> * ''Difficulty:'' Medium.<br /> * ''Recommended reading:''<br /> ** [https://man7.org/linux/man-pages/man2/socket.2.html Linux socket]<br /> ** [https://courses.cs.vt.edu/cs4254/fall04/slides/raw_1.pdf Raw Sockets and ICMP, Srinidhi Varadarajan]<br /> ** [https://gitlab.com/nsnam/ns-3-dev/-/issues/810 Issue #810]<br /> <br /> Possible tasks to fulfill the patch requirement:<br /> * Submit a patch to fix [https://gitlab.com/nsnam/ns-3-dev/-/issues/809 Issue #809]<br /> <br /> === 6LoWPAN mesh-under routing enhancements ===<br /> <br /> Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], [TBD].<br /> <br /> 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.<br /> 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.<br /> <br /> The candidate should outline what parts of code are going to be affected, and how they can be enhanced thanks to RFC 7731.<br /> <br /> * ''Required Experience:'' Fundamentals of IPv6 addressing, C++ programming.<br /> * ''Bonus Experience:'' Familiarity with mesh routing and 6LoWPAN ns-3<br /> * ''Interests:'' IPv6 mesh routing<br /> * ''Difficulty:'' Easy.<br /> * ''Recommended reading:''<br /> ** [https://www.nsnam.org/docs/models/html/sixlowpan.html#mesh-under-routing Mesh-under in ns-3 6LoWPAN]<br /> ** [https://datatracker.ietf.org/doc/html/rfc7731 RFC 7731]<br /> <br /> Possible tasks to fulfill the patch requirement:<br /> * TBD<br /> <br /> === 6LoWPAN neighbor discovery protocol ===<br /> <br /> Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], [TBD].<br /> <br /> 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.<br /> <br /> 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).<br /> <br /> 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.<br /> <br /> * ''Required Experience:'' Fundamentals of IPv6 addressing, C++ programming.<br /> * ''Bonus Experience:'' Familiarity with 6LoWPAN and 6LoWPAN-ND<br /> * ''Interests:'' IPv6 and IoT networks<br /> * ''Difficulty:'' Easy.<br /> * ''Patch requirement:'' [[GSOC2024PatchRequirement]]<br /> * ''Recommended reading:''<br /> ** [https://datatracker.ietf.org/doc/html/rfc8505 RFC 8505]<br /> ** [https://datatracker.ietf.org/doc/html/rfc6775 RFC 6775]<br /> ** [https://datatracker.ietf.org/doc/html/rfc4944 RFC 4944]<br /> <br /> Possible tasks to fulfil the patch requirement:<br /> * Patch the actual 6LoWPAN-ND to remove the limitation about concurrent address registrations.<br /> <br /> === Improving 5G NR module usability through helpers ===<br /> <br /> 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]<br /> <br /> 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.<br /> <br /> 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.<br /> <br /> * Required Experience: C++ programming, understanding of 5G NR, LTE, and wireless networks<br /> * Interests: 5G NR simulations<br /> * Difficulty: Medium.<br /> * 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.<br /> <br /> === Enabling 5G NR examples visualization ===<br /> <br /> 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]<br /> <br /> 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.<br /> <br /> 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.<br /> 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].<br /> <br /> * Required Experience: C++ and Python programming, understanding of 5G NR, LTE, and wireless networks<br /> * Interests: 5G NR simulations<br /> * Difficulty: Medium.<br /> * 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.<br /> <br /> === Linux-like Loss Detection Techniques for ns-3 TCP ===<br /> <br /> Mentors: [mailto:tahiliani.nitk@gmail.com Mohit P. Tahiliani]<br /> <br /> 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.<br /> <br /> * ''Required Experience:'' Familiarity with TCP and C++ programming.<br /> * ''Bonus Experience:'' Familiarity with TCP implementation in Linux kernel.<br /> * ''Interests:'' TCP packet loss detection techniques.<br /> * ''Difficulty:'' Medium to Hard.<br /> * ''Recommended Reading:''<br /> ** Forward Acknowledgement (FACK) [[https://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.41.2559&amp;rep=rep1&amp;type=pdf Paper]] [[https://gitlab.com/nsnam/ns-3-dev/-/merge_requests/34/commits Implementation]]<br /> ** Duplicate Selective Acknowledgment (DSACK) [[https://tools.ietf.org/html/rfc2883 RFC 2883]] [[https://gitlab.com/nsnam/ns-3-dev/-/merge_requests/34/commits Implementation]]<br /> ** RACK-TLP [[https://datatracker.ietf.org/doc/html/rfc8985 RFC 8985]] [[https://gitlab.com/nsnam/ns-3-dev/-/merge_requests/34/commits Implementation]]<br /> <br /> == Large projects (350 hours) ==<br /> <br /> === IPv6 global routing ===<br /> <br /> Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], [TBD].<br /> <br /> 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).<br /> For IPv4, ns-3 provides two alternatives: GlobalRouting, and NixRouting, which just &quot;do the trick&quot; - they simply fill the routing tables in intermediate nodes, GlobalRouting using an approach similar to OSPF, NixRouting by leveraging the &quot;abstract&quot; knowledge of the network.<br /> Neither actually use any message between the nodes, so they also reduce the network overhead - something that is useful in many cases.<br /> <br /> 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.).<br /> <br /> 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.<br /> <br /> * ''Required Experience:'' Fundamentals of IPv6 addressing, C++ programming.<br /> * ''Bonus Experience:'' Familiarity with GlobalRouting implementations in ns-3<br /> * ''Interests:'' IPv6 routing<br /> * ''Difficulty:'' Medium.<br /> * ''Patch requirement:'' [[GSOC2024PatchRequirement]]<br /> * ''Recommended reading:''<br /> ** [https://www.nsnam.org/docs/models/html/ipv6.html IPv6 model in ns-3]<br /> ** [https://www.nsnam.org/docs/models/html/routing-overview.html#global-centralized-routing GlobalRouting model in ns-3]<br /> <br /> Possible tasks to fulfill the patch requirement:<br /> * 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.<br /> <br /> === AODVv2 Protocol enhancements ===<br /> <br /> Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], [TBD].<br /> <br /> 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.<br /> <br /> In particular the project should address the following points: 1) AODVv2 performances, 2) AODV address compression, 3) &quot;external&quot; network routing support, 4) general model validation against the latest draft.<br /> Collaboration with the draft authors is also highly suggested.<br /> <br /> * ''Required Experience:'' Fundamentals of IPv6 addressing, C++ programming.<br /> * ''Bonus Experience:'' Familiarity with AODV implementations in ns-3 and AODVv2<br /> * ''Interests:'' Ad hoc routing<br /> * ''Difficulty:'' Medium.<br /> * ''Patch requirement:'' [[GSOC2024PatchRequirement]]<br /> * ''Recommended reading:''<br /> ** [https://www.nsnam.org/docs/models/html/ipv6.html IPv6 model in ns-3]<br /> ** [https://www.nsnam.org/docs/models/html/aodv.html AODV model in ns-3]<br /> ** [https://datatracker.ietf.org/doc/draft-perkins-manet-aodvv2/05/ Ad Hoc On-demand Distance Vector Version 2 (AODVv2) Routing]<br /> <br /> Possible tasks to fulfill the patch requirement:<br /> * [https://gitlab.com/nsnam/ns-3-dev/-/issues/368 Issue #368] - aodv: aodv parameters can be set to &quot;impossible&quot; values<br /> <br /> === Mesh Link Establishment (MLE) protocol ===<br /> <br /> Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], TBD.<br /> <br /> 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.<br /> However, MLE is being used in Thread, and it can be useful to implement it.<br /> <br /> 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.<br /> <br /> * ''Required Experience:'' Fundamentals of IPv4 and IPv6 sockets, C++ programming.<br /> * ''Interests:'' Sockets and API interface implementation.<br /> * ''Difficulty:'' Hard.<br /> * ''Recommended reading:''<br /> ** [https://datatracker.ietf.org/doc/html/draft-ietf-6lo-mesh-link-establishment MLE draft]<br /> ** [https://openthread.io/guides/thread-primer/network-discovery Thread primer]<br /> ** [https://www.threadgroup.org/ThreadSpec Thread specifications]<br /> <br /> Possible tasks to fulfill the patch requirement:<br /> * TBD, contact the mentors if interested.<br /> <br /> === Lr-WPAN (IEEE 802.15.4) preamble detection support ===<br /> <br /> Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], [mailto:alramonet@is.tokushima-u.ac.jp Alberto Gallegos Ramonet].<br /> <br /> 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<br /> 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<br /> itself has many added benefits.<br /> <br /> 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.<br /> <br /> As usual, reduction of code duplicity and a flexible scalable design is desired (e.g. Allow the inclusion of different preambles in the future).<br /> <br /> * ''Required Experience:'' Basic understanding of IEEE 802.15.4, C++ programming.<br /> * ''Bonus Experience:'' PHY process familiarity, Familiarity with ns-3's Lr-WPAN<br /> * ''Interests:'' Lr-WPAN, MAC and PHY designs<br /> * ''Difficulty:'' Medium.<br /> * ''Patch requirement:'' [[GSOC2024PatchRequirement]]<br /> * ''Recommended reading:''<br /> ** [https://ieeexplore.ieee.org/document/1700009 IEEE 802.15.4-2006]<br /> ** [https://ieeexplore.ieee.org/document/7460875 IEEE 802.15.4-2015]<br /> ** [https://www.nsnam.org/docs/models/html/lr-wpan.html ns-3 lr-wpan module]<br /> <br /> Possible tasks to fulfill the patch requirement:<br /> * TBD, contact the mentors if interested.<br /> <br /> === 5G NR module integration with ns-3-ai ===<br /> <br /> 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]<br /> <br /> 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.<br /> <br /> 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.<br /> For more specific guidelines, please view this [https://docs.google.com/document/d/1cQLIF1cdft1yj3vyWrjrxN2xDJMx8PuWaa9NP_nKf64/edit?usp=sharing Google document].<br /> <br /> * Required Experience: C++ programming, understanding of 5G NR, LTE, and wireless networks<br /> * Interests: 5G NR simulations<br /> * Difficulty: Medium.<br /> * 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.<br /> <br /> === Linux-like CAKE queue discipline for ns-3 ===<br /> <br /> Mentors: [mailto:tahiliani.nitk@gmail.com Mohit P. Tahiliani]<br /> <br /> 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.<br /> <br /> * ''Required Experience:'' Familiarity with queue disciplines, TCP and C++ programming.<br /> * ''Bonus Experience:'' Familiarity with CAKE framework in Linux 4.19<br /> * ''Interests:'' Active Queue Management, Packet scheduling and TCP.<br /> * ''Difficulty:'' Medium to Hard<br /> * ''Recommended reading:''<br /> ** [https://arxiv.org/pdf/1804.07617.pdf Piece of CAKE: A Comprehensive Queue Management Solution for Home Gateways]<br /> ** [https://lwn.net/Articles/758353/ Let them run CAKE]<br /> ** [https://www.nsnam.org/docs/models/html/queue-discs.html Queue disciplines in ns-3]</div>

Tommaso https://www.nsnam.org/mediawiki/index.php?title=GSOC2025Projects&diff=13438 2025-02-14T19:21:35Z

<p>Tommaso: /* Lr-WPAN (IEEE 802.15.4) preamble detection support */</p> <hr /> <div>{{TOC}}<br /> <br /> This page contains 2025 Google Summer of Code project ideas for ns-3.<br /> <br /> * [https://developers.google.com/open-source/gsoc/faq GSoC Frequently Asked Questions]<br /> * [[GSOC2025ContributorGuide | ns-3's 2025 GSoC Contributor guide]]<br /> * [https://developers.google.com/open-source/gsoc/resources/guide GSoC contributor/student guide (not ns-3 specific)]<br /> * [[GSOC2025ApplicationTemplate | 2025 GSoC Contributor application template]]<br /> * [[GSOCMentorGuide | ns-3's GSoC Mentor guide]]<br /> * [https://archive.flossmanuals.net/gsocmentoring/index.html GSoC Mentor guide (not ns-3 specific)]<br /> * [[GSOCSelectionProcess | GSoC Contributor Selection Process]]<br /> * ''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/<br /> <br /> === About the ns-3 project ===<br /> <br /> ns-3 is a discrete-event network simulator, with a particular emphasis on network research and education.<br /> <br /> 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.<br /> <br /> 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.<br /> <br /> === Org admins ===<br /> <br /> 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].<br /> <br /> === Mentors ===<br /> <br /> 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.<br /> <br /> The current list of prospective mentors can be found among the ideas listed below.<br /> <br /> === How to apply ===<br /> <br /> For students or contributors interested in applying to ns-3 for GSoC, please go through the following list to get started:<br /> * Read the official [https://developers.google.com/open-source/gsoc/resources/guide GSoC contributor guide].<br /> * Read [[GSOC2025ContributorGuide |ns-3's 2025 GSoC contributor guide]]<br /> * Look through our [[#Project Ideas]] below to see if you find a project that interests you.<br /> * Review the [https://www.nsnam.org/documentation/development-tree/ tutorial and contributing guide] thoroughly, if you have not already done so.<br /> * 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.<br /> * Next, proceed to get in touch with the developers on the mailing list or Zulip chat room and refine your proposal.<br /> * 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.<br /> <br /> 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.<br /> <br /> &lt;blockquote&gt;<br /> Each project idea within a particular priority has been tagged with the following properties:<br /> * ''Required Experience:'' Languages, concepts, or packages with which applicants must be familiar.<br /> * ''Bonus Experience:'' Other experience or familiarity which would be greatly helpful to applicants for this project.<br /> * ''Interests:'' Areas of particular relevance to this project, and an indicator of where successful contributors might apply their experiences coming out of this project.<br /> * ''Difficulty:'' easy, medium or difficult<br /> * ''Recommended reading:'' pointers to documentation, papers, specific bugs, etc.<br /> <br /> 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.<br /> &lt;/blockquote&gt;<br /> <br /> === Patch requirement guidelines ===<br /> <br /> 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.<br /> <br /> === Mentors: how to participate ===<br /> <br /> 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:<br /> <br /> * 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.<br /> * 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.<br /> * 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.<br /> <br /> == Project Ideas ==<br /> <br /> '''Note to contributors:''' These ideas are not listed in any priority order.<br /> 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.<br /> <br /> === Internet models enhancements ===<br /> <br /> * [[#ICMP socket and generate/handle ICMP messages (host/net unreachable)]] (medium size project, 175h)<br /> * [[#IPv6 global routing]] (large size project, 350h)<br /> * [[#IPv6 support in Ad hoc Routing Protocols]] (large size project, 350h)<br /> <br /> === IoT models enhancements ===<br /> <br /> * [[#6LoWPAN mesh-under routing enhancements]] (medium size project, 175h)<br /> * [[#6LoWPAN neighbor discovery protocol]] (medium size project, 175h)<br /> * [[#Mesh Link Establishment (MLE) protocol ]] (large size project, 350h)<br /> * [[#Lr-WPAN (IEEE 802.15.4) preamble detection support]] (large size project, 350h)<br /> <br /> === 5G NR models enhancements ===<br /> <br /> 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.<br /> <br /> * [[#NTN example for 5G NR]] (small size project, 90h)<br /> * [[#5G NR module integration with ns-3-ai]] (large size project, 250h)<br /> * [[#Enabling 5G NR examples visualization]] (large size project, 175h)<br /> * [[#Improving 5G NR module usability through helpers]] (medium size project, 175h)<br /> <br /> == Small sized projects (90 hours) ==<br /> <br /> <br /> === NTN example for 5G NR ===<br /> <br /> 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]<br /> <br /> 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).<br /> <br /> 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.<br /> <br /> * Required Experience: C++ programming, understanding of 5G NR, LTE, and wireless networks<br /> * Interests: 5G NR simulations<br /> * Difficulty: Medium.<br /> * 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.<br /> <br /> === Upgrade the AQM Evaluation Suite for ns-3 ===<br /> <br /> Mentors: [mailto:tahiliani.nitk@gmail.com Mohit P. Tahiliani]<br /> <br /> 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.<br /> <br /> * ''Required Experience:'' Familiarity with AQM and C++ programming.<br /> * ''Bonus Experience:'' Familiarity with traffic control model in ns-3.<br /> * ''Interests:'' Packet Scheduling algorithms, AQM algorithms and ECN.<br /> * ''Difficulty:'' Medium.<br /> * ''Recommended Reading:''<br /> ** AQM Evaluation Suite [[https://dl.acm.org/doi/abs/10.1145/3067665.3067674 Paper]] [[https://aqm-eval-suite.github.io/ Implementation]]<br /> ** [https://tools.ietf.org/html/rfc7928 RFC 7928]<br /> ** [https://www.nsnam.org/docs/models/html/traffic-control-layer.html Traffic Control Model in ns-3]<br /> * ''Patch requirement:'' Create a pull request to handle the case when an incorrect Scenario name or number is passed via command line.<br /> <br /> == Medium sized projects (175 hours) ==<br /> <br /> === ICMP socket and generate/handle ICMP messages (host/net unreachable) ===<br /> <br /> Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], [mailto:manoj24.rana@gmail.com Manoj K. Rana].<br /> <br /> 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 &quot;RAW&quot; socket.<br /> 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.<br /> <br /> 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.<br /> <br /> The most important point of the implementation should be code duplicate minimization, in order to have the minimize maintenance efforts.<br /> <br /> Once the sockets are in place, beside the &quot;normal&quot; tests, it will be necessary to modify the code that is actually made obsolete by the new sockets, e.g.:<br /> * IPv6 ICMP messages (RA, RS, NA, NS, etc.),<br /> * IPv4 ICMP messages,<br /> * ICMP Echo and ICMPv6 Echo messages.<br /> and to handle properly ICMP error messages like Destination Unreachable in the Ping application.<br /> <br /> * ''Required Experience:'' Fundamentals of IPv4 and IPv6 sockets, C++ programming.<br /> * ''Interests:'' Sockets and API interface implementation.<br /> * ''Difficulty:'' Medium.<br /> * ''Recommended reading:''<br /> ** [https://man7.org/linux/man-pages/man2/socket.2.html Linux socket]<br /> ** [https://courses.cs.vt.edu/cs4254/fall04/slides/raw_1.pdf Raw Sockets and ICMP, Srinidhi Varadarajan]<br /> ** [https://gitlab.com/nsnam/ns-3-dev/-/issues/810 Issue #810]<br /> <br /> Possible tasks to fulfill the patch requirement:<br /> * Submit a patch to fix [https://gitlab.com/nsnam/ns-3-dev/-/issues/809 Issue #809]<br /> <br /> === 6LoWPAN mesh-under routing enhancements ===<br /> <br /> Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], [TBD].<br /> <br /> 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.<br /> 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.<br /> <br /> The candidate should outline what parts of code are going to be affected, and how they can be enhanced thanks to RFC 7731.<br /> <br /> * ''Required Experience:'' Fundamentals of IPv6 addressing, C++ programming.<br /> * ''Bonus Experience:'' Familiarity with mesh routing and 6LoWPAN ns-3<br /> * ''Interests:'' IPv6 mesh routing<br /> * ''Difficulty:'' Easy.<br /> * ''Patch requirement:'' [[GSOC2024PatchRequirement]]<br /> * ''Recommended reading:''<br /> ** [https://www.nsnam.org/docs/models/html/sixlowpan.html#mesh-under-routing Mesh-under in ns-3 6LoWPAN]<br /> ** [https://datatracker.ietf.org/doc/html/rfc7731 RFC 7731]<br /> <br /> Possible tasks to fulfill the patch requirement:<br /> * TBD<br /> <br /> === 6LoWPAN neighbor discovery protocol ===<br /> <br /> Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], [TBD].<br /> <br /> 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.<br /> <br /> 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).<br /> <br /> 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.<br /> <br /> * ''Required Experience:'' Fundamentals of IPv6 addressing, C++ programming.<br /> * ''Bonus Experience:'' Familiarity with 6LoWPAN and 6LoWPAN-ND<br /> * ''Interests:'' IPv6 and IoT networks<br /> * ''Difficulty:'' Easy.<br /> * ''Patch requirement:'' [[GSOC2024PatchRequirement]]<br /> * ''Recommended reading:''<br /> ** [https://datatracker.ietf.org/doc/html/rfc8505 RFC 8505]<br /> ** [https://datatracker.ietf.org/doc/html/rfc6775 RFC 6775]<br /> ** [https://datatracker.ietf.org/doc/html/rfc4944 RFC 4944]<br /> <br /> Possible tasks to fulfil the patch requirement:<br /> * Patch the actual 6LoWPAN-ND to remove the limitation about concurrent address registrations.<br /> <br /> === Improving 5G NR module usability through helpers ===<br /> <br /> 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]<br /> <br /> 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.<br /> <br /> 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.<br /> <br /> * Required Experience: C++ programming, understanding of 5G NR, LTE, and wireless networks<br /> * Interests: 5G NR simulations<br /> * Difficulty: Medium.<br /> * 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.<br /> <br /> === Enabling 5G NR examples visualization ===<br /> <br /> 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]<br /> <br /> 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.<br /> <br /> 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.<br /> 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].<br /> <br /> * Required Experience: C++ and Python programming, understanding of 5G NR, LTE, and wireless networks<br /> * Interests: 5G NR simulations<br /> * Difficulty: Medium.<br /> * 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.<br /> <br /> === Linux-like Loss Detection Techniques for ns-3 TCP ===<br /> <br /> Mentors: [mailto:tahiliani.nitk@gmail.com Mohit P. Tahiliani]<br /> <br /> 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.<br /> <br /> * ''Required Experience:'' Familiarity with TCP and C++ programming.<br /> * ''Bonus Experience:'' Familiarity with TCP implementation in Linux kernel.<br /> * ''Interests:'' TCP packet loss detection techniques.<br /> * ''Difficulty:'' Medium to Hard.<br /> * ''Recommended Reading:''<br /> ** Forward Acknowledgement (FACK) [[https://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.41.2559&amp;rep=rep1&amp;type=pdf Paper]] [[https://gitlab.com/nsnam/ns-3-dev/-/merge_requests/34/commits Implementation]]<br /> ** Duplicate Selective Acknowledgment (DSACK) [[https://tools.ietf.org/html/rfc2883 RFC 2883]] [[https://gitlab.com/nsnam/ns-3-dev/-/merge_requests/34/commits Implementation]]<br /> ** RACK-TLP [[https://datatracker.ietf.org/doc/html/rfc8985 RFC 8985]] [[https://gitlab.com/nsnam/ns-3-dev/-/merge_requests/34/commits Implementation]]<br /> <br /> == Large projects (350 hours) ==<br /> <br /> === IPv6 global routing ===<br /> <br /> Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], [TBD].<br /> <br /> 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).<br /> For IPv4, ns-3 provides two alternatives: GlobalRouting, and NixRouting, which just &quot;do the trick&quot; - they simply fill the routing tables in intermediate nodes, GlobalRouting using an approach similar to OSPF, NixRouting by leveraging the &quot;abstract&quot; knowledge of the network.<br /> Neither actually use any message between the nodes, so they also reduce the network overhead - something that is useful in many cases.<br /> <br /> 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.).<br /> <br /> 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.<br /> <br /> * ''Required Experience:'' Fundamentals of IPv6 addressing, C++ programming.<br /> * ''Bonus Experience:'' Familiarity with GlobalRouting implementations in ns-3<br /> * ''Interests:'' IPv6 routing<br /> * ''Difficulty:'' Medium.<br /> * ''Patch requirement:'' [[GSOC2024PatchRequirement]]<br /> * ''Recommended reading:''<br /> ** [https://www.nsnam.org/docs/models/html/ipv6.html IPv6 model in ns-3]<br /> ** [https://www.nsnam.org/docs/models/html/routing-overview.html#global-centralized-routing GlobalRouting model in ns-3]<br /> <br /> Possible tasks to fulfill the patch requirement:<br /> * 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.<br /> <br /> === AODVv2 Protocol enhancements ===<br /> <br /> Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], [TBD].<br /> <br /> 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.<br /> <br /> In particular the project should address the following points: 1) AODVv2 performances, 2) AODV address compression, 3) &quot;external&quot; network routing support, 4) general model validation against the latest draft.<br /> Collaboration with the draft authors is also highly suggested.<br /> <br /> * ''Required Experience:'' Fundamentals of IPv6 addressing, C++ programming.<br /> * ''Bonus Experience:'' Familiarity with AODV implementations in ns-3 and AODVv2<br /> * ''Interests:'' Ad hoc routing<br /> * ''Difficulty:'' Medium.<br /> * ''Patch requirement:'' [[GSOC2024PatchRequirement]]<br /> * ''Recommended reading:''<br /> ** [https://www.nsnam.org/docs/models/html/ipv6.html IPv6 model in ns-3]<br /> ** [https://www.nsnam.org/docs/models/html/aodv.html AODV model in ns-3]<br /> ** [https://datatracker.ietf.org/doc/draft-perkins-manet-aodvv2/05/ Ad Hoc On-demand Distance Vector Version 2 (AODVv2) Routing]<br /> <br /> Possible tasks to fulfill the patch requirement:<br /> * [https://gitlab.com/nsnam/ns-3-dev/-/issues/368 Issue #368] - aodv: aodv parameters can be set to &quot;impossible&quot; values<br /> <br /> === Mesh Link Establishment (MLE) protocol ===<br /> <br /> Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], TBD.<br /> <br /> 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.<br /> However, MLE is being used in Thread, and it can be useful to implement it.<br /> <br /> 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.<br /> <br /> * ''Required Experience:'' Fundamentals of IPv4 and IPv6 sockets, C++ programming.<br /> * ''Interests:'' Sockets and API interface implementation.<br /> * ''Difficulty:'' Hard.<br /> * ''Recommended reading:''<br /> ** [https://datatracker.ietf.org/doc/html/draft-ietf-6lo-mesh-link-establishment MLE draft]<br /> ** [https://openthread.io/guides/thread-primer/network-discovery Thread primer]<br /> ** [https://www.threadgroup.org/ThreadSpec Thread specifications]<br /> <br /> Possible tasks to fulfill the patch requirement:<br /> * TBD, contact the mentors if interested.<br /> <br /> === Lr-WPAN (IEEE 802.15.4) preamble detection support ===<br /> <br /> Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], [mailto:alramonet@is.tokushima-u.ac.jp Alberto Gallegos Ramonet].<br /> <br /> 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<br /> 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<br /> itself has many added benefits.<br /> <br /> 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.<br /> <br /> As usual, reduction of code duplicity and a flexible scalable design is desired (e.g. Allow the inclusion of different preambles in the future).<br /> <br /> * ''Required Experience:'' Basic understanding of IEEE 802.15.4, C++ programming.<br /> * ''Bonus Experience:'' PHY process familiarity, Familiarity with ns-3's Lr-WPAN<br /> * ''Interests:'' Lr-WPAN, MAC and PHY designs<br /> * ''Difficulty:'' Medium.<br /> * ''Patch requirement:'' [[GSOC2024PatchRequirement]]<br /> * ''Recommended reading:''<br /> ** [https://ieeexplore.ieee.org/document/1700009 IEEE 802.15.4-2006]<br /> ** [https://ieeexplore.ieee.org/document/7460875 IEEE 802.15.4-2015]<br /> ** [https://www.nsnam.org/docs/models/html/lr-wpan.html ns-3 lr-wpan module]<br /> <br /> Possible tasks to fulfill the patch requirement:<br /> * TBD, contact the mentors if interested.<br /> <br /> === 5G NR module integration with ns-3-ai ===<br /> <br /> 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]<br /> <br /> 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.<br /> <br /> 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.<br /> For more specific guidelines, please view this [https://docs.google.com/document/d/1cQLIF1cdft1yj3vyWrjrxN2xDJMx8PuWaa9NP_nKf64/edit?usp=sharing Google document].<br /> <br /> * Required Experience: C++ programming, understanding of 5G NR, LTE, and wireless networks<br /> * Interests: 5G NR simulations<br /> * Difficulty: Medium.<br /> * 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.<br /> <br /> === Linux-like CAKE queue discipline for ns-3 ===<br /> <br /> Mentors: [mailto:tahiliani.nitk@gmail.com Mohit P. Tahiliani]<br /> <br /> 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.<br /> <br /> * ''Required Experience:'' Familiarity with queue disciplines, TCP and C++ programming.<br /> * ''Bonus Experience:'' Familiarity with CAKE framework in Linux 4.19<br /> * ''Interests:'' Active Queue Management, Packet scheduling and TCP.<br /> * ''Difficulty:'' Medium to Hard<br /> * ''Recommended reading:''<br /> ** [https://arxiv.org/pdf/1804.07617.pdf Piece of CAKE: A Comprehensive Queue Management Solution for Home Gateways]<br /> ** [https://lwn.net/Articles/758353/ Let them run CAKE]<br /> ** [https://www.nsnam.org/docs/models/html/queue-discs.html Queue disciplines in ns-3]</div>

Tommaso https://www.nsnam.org/mediawiki/index.php?title=GSOC2025Projects&diff=13437 2025-02-14T19:21:04Z

<p>Tommaso: /* 5G NR module integration with ns-3-ai */</p> <hr /> <div>{{TOC}}<br /> <br /> This page contains 2025 Google Summer of Code project ideas for ns-3.<br /> <br /> * [https://developers.google.com/open-source/gsoc/faq GSoC Frequently Asked Questions]<br /> * [[GSOC2025ContributorGuide | ns-3's 2025 GSoC Contributor guide]]<br /> * [https://developers.google.com/open-source/gsoc/resources/guide GSoC contributor/student guide (not ns-3 specific)]<br /> * [[GSOC2025ApplicationTemplate | 2025 GSoC Contributor application template]]<br /> * [[GSOCMentorGuide | ns-3's GSoC Mentor guide]]<br /> * [https://archive.flossmanuals.net/gsocmentoring/index.html GSoC Mentor guide (not ns-3 specific)]<br /> * [[GSOCSelectionProcess | GSoC Contributor Selection Process]]<br /> * ''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/<br /> <br /> === About the ns-3 project ===<br /> <br /> ns-3 is a discrete-event network simulator, with a particular emphasis on network research and education.<br /> <br /> 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.<br /> <br /> 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.<br /> <br /> === Org admins ===<br /> <br /> 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].<br /> <br /> === Mentors ===<br /> <br /> 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.<br /> <br /> The current list of prospective mentors can be found among the ideas listed below.<br /> <br /> === How to apply ===<br /> <br /> For students or contributors interested in applying to ns-3 for GSoC, please go through the following list to get started:<br /> * Read the official [https://developers.google.com/open-source/gsoc/resources/guide GSoC contributor guide].<br /> * Read [[GSOC2025ContributorGuide |ns-3's 2025 GSoC contributor guide]]<br /> * Look through our [[#Project Ideas]] below to see if you find a project that interests you.<br /> * Review the [https://www.nsnam.org/documentation/development-tree/ tutorial and contributing guide] thoroughly, if you have not already done so.<br /> * 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.<br /> * Next, proceed to get in touch with the developers on the mailing list or Zulip chat room and refine your proposal.<br /> * 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.<br /> <br /> 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.<br /> <br /> &lt;blockquote&gt;<br /> Each project idea within a particular priority has been tagged with the following properties:<br /> * ''Required Experience:'' Languages, concepts, or packages with which applicants must be familiar.<br /> * ''Bonus Experience:'' Other experience or familiarity which would be greatly helpful to applicants for this project.<br /> * ''Interests:'' Areas of particular relevance to this project, and an indicator of where successful contributors might apply their experiences coming out of this project.<br /> * ''Difficulty:'' easy, medium or difficult<br /> * ''Recommended reading:'' pointers to documentation, papers, specific bugs, etc.<br /> <br /> 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.<br /> &lt;/blockquote&gt;<br /> <br /> === Patch requirement guidelines ===<br /> <br /> 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.<br /> <br /> === Mentors: how to participate ===<br /> <br /> 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:<br /> <br /> * 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.<br /> * 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.<br /> * 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.<br /> <br /> == Project Ideas ==<br /> <br /> '''Note to contributors:''' These ideas are not listed in any priority order.<br /> 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.<br /> <br /> === Internet models enhancements ===<br /> <br /> * [[#ICMP socket and generate/handle ICMP messages (host/net unreachable)]] (medium size project, 175h)<br /> * [[#IPv6 global routing]] (large size project, 350h)<br /> * [[#IPv6 support in Ad hoc Routing Protocols]] (large size project, 350h)<br /> <br /> === IoT models enhancements ===<br /> <br /> * [[#6LoWPAN mesh-under routing enhancements]] (medium size project, 175h)<br /> * [[#6LoWPAN neighbor discovery protocol]] (medium size project, 175h)<br /> * [[#Mesh Link Establishment (MLE) protocol ]] (large size project, 350h)<br /> * [[#Lr-WPAN (IEEE 802.15.4) preamble detection support]] (large size project, 350h)<br /> <br /> === 5G NR models enhancements ===<br /> <br /> 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.<br /> <br /> * [[#NTN example for 5G NR]] (small size project, 90h)<br /> * [[#5G NR module integration with ns-3-ai]] (large size project, 250h)<br /> * [[#Enabling 5G NR examples visualization]] (large size project, 175h)<br /> * [[#Improving 5G NR module usability through helpers]] (medium size project, 175h)<br /> <br /> == Small sized projects (90 hours) ==<br /> <br /> <br /> === NTN example for 5G NR ===<br /> <br /> 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]<br /> <br /> 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).<br /> <br /> 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.<br /> <br /> * Required Experience: C++ programming, understanding of 5G NR, LTE, and wireless networks<br /> * Interests: 5G NR simulations<br /> * Difficulty: Medium.<br /> * 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.<br /> <br /> === Upgrade the AQM Evaluation Suite for ns-3 ===<br /> <br /> Mentors: [mailto:tahiliani.nitk@gmail.com Mohit P. Tahiliani]<br /> <br /> 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.<br /> <br /> * ''Required Experience:'' Familiarity with AQM and C++ programming.<br /> * ''Bonus Experience:'' Familiarity with traffic control model in ns-3.<br /> * ''Interests:'' Packet Scheduling algorithms, AQM algorithms and ECN.<br /> * ''Difficulty:'' Medium.<br /> * ''Recommended Reading:''<br /> ** AQM Evaluation Suite [[https://dl.acm.org/doi/abs/10.1145/3067665.3067674 Paper]] [[https://aqm-eval-suite.github.io/ Implementation]]<br /> ** [https://tools.ietf.org/html/rfc7928 RFC 7928]<br /> ** [https://www.nsnam.org/docs/models/html/traffic-control-layer.html Traffic Control Model in ns-3]<br /> * ''Patch requirement:'' Create a pull request to handle the case when an incorrect Scenario name or number is passed via command line.<br /> <br /> == Medium sized projects (175 hours) ==<br /> <br /> === ICMP socket and generate/handle ICMP messages (host/net unreachable) ===<br /> <br /> Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], [mailto:manoj24.rana@gmail.com Manoj K. Rana].<br /> <br /> 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 &quot;RAW&quot; socket.<br /> 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.<br /> <br /> 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.<br /> <br /> The most important point of the implementation should be code duplicate minimization, in order to have the minimize maintenance efforts.<br /> <br /> Once the sockets are in place, beside the &quot;normal&quot; tests, it will be necessary to modify the code that is actually made obsolete by the new sockets, e.g.:<br /> * IPv6 ICMP messages (RA, RS, NA, NS, etc.),<br /> * IPv4 ICMP messages,<br /> * ICMP Echo and ICMPv6 Echo messages.<br /> and to handle properly ICMP error messages like Destination Unreachable in the Ping application.<br /> <br /> * ''Required Experience:'' Fundamentals of IPv4 and IPv6 sockets, C++ programming.<br /> * ''Interests:'' Sockets and API interface implementation.<br /> * ''Difficulty:'' Medium.<br /> * ''Recommended reading:''<br /> ** [https://man7.org/linux/man-pages/man2/socket.2.html Linux socket]<br /> ** [https://courses.cs.vt.edu/cs4254/fall04/slides/raw_1.pdf Raw Sockets and ICMP, Srinidhi Varadarajan]<br /> ** [https://gitlab.com/nsnam/ns-3-dev/-/issues/810 Issue #810]<br /> <br /> Possible tasks to fulfill the patch requirement:<br /> * Submit a patch to fix [https://gitlab.com/nsnam/ns-3-dev/-/issues/809 Issue #809]<br /> <br /> === 6LoWPAN mesh-under routing enhancements ===<br /> <br /> Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], [TBD].<br /> <br /> 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.<br /> 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.<br /> <br /> The candidate should outline what parts of code are going to be affected, and how they can be enhanced thanks to RFC 7731.<br /> <br /> * ''Required Experience:'' Fundamentals of IPv6 addressing, C++ programming.<br /> * ''Bonus Experience:'' Familiarity with mesh routing and 6LoWPAN ns-3<br /> * ''Interests:'' IPv6 mesh routing<br /> * ''Difficulty:'' Easy.<br /> * ''Patch requirement:'' [[GSOC2024PatchRequirement]]<br /> * ''Recommended reading:''<br /> ** [https://www.nsnam.org/docs/models/html/sixlowpan.html#mesh-under-routing Mesh-under in ns-3 6LoWPAN]<br /> ** [https://datatracker.ietf.org/doc/html/rfc7731 RFC 7731]<br /> <br /> Possible tasks to fulfill the patch requirement:<br /> * TBD<br /> <br /> === 6LoWPAN neighbor discovery protocol ===<br /> <br /> Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], [TBD].<br /> <br /> 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.<br /> <br /> 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).<br /> <br /> 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.<br /> <br /> * ''Required Experience:'' Fundamentals of IPv6 addressing, C++ programming.<br /> * ''Bonus Experience:'' Familiarity with 6LoWPAN and 6LoWPAN-ND<br /> * ''Interests:'' IPv6 and IoT networks<br /> * ''Difficulty:'' Easy.<br /> * ''Patch requirement:'' [[GSOC2024PatchRequirement]]<br /> * ''Recommended reading:''<br /> ** [https://datatracker.ietf.org/doc/html/rfc8505 RFC 8505]<br /> ** [https://datatracker.ietf.org/doc/html/rfc6775 RFC 6775]<br /> ** [https://datatracker.ietf.org/doc/html/rfc4944 RFC 4944]<br /> <br /> Possible tasks to fulfil the patch requirement:<br /> * Patch the actual 6LoWPAN-ND to remove the limitation about concurrent address registrations.<br /> <br /> === Improving 5G NR module usability through helpers ===<br /> <br /> 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]<br /> <br /> 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.<br /> <br /> 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.<br /> <br /> * Required Experience: C++ programming, understanding of 5G NR, LTE, and wireless networks<br /> * Interests: 5G NR simulations<br /> * Difficulty: Medium.<br /> * 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.<br /> <br /> === Enabling 5G NR examples visualization ===<br /> <br /> 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]<br /> <br /> 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.<br /> <br /> 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.<br /> 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].<br /> <br /> * Required Experience: C++ and Python programming, understanding of 5G NR, LTE, and wireless networks<br /> * Interests: 5G NR simulations<br /> * Difficulty: Medium.<br /> * 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.<br /> <br /> === Linux-like Loss Detection Techniques for ns-3 TCP ===<br /> <br /> Mentors: [mailto:tahiliani.nitk@gmail.com Mohit P. Tahiliani]<br /> <br /> 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.<br /> <br /> * ''Required Experience:'' Familiarity with TCP and C++ programming.<br /> * ''Bonus Experience:'' Familiarity with TCP implementation in Linux kernel.<br /> * ''Interests:'' TCP packet loss detection techniques.<br /> * ''Difficulty:'' Medium to Hard.<br /> * ''Recommended Reading:''<br /> ** Forward Acknowledgement (FACK) [[https://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.41.2559&amp;rep=rep1&amp;type=pdf Paper]] [[https://gitlab.com/nsnam/ns-3-dev/-/merge_requests/34/commits Implementation]]<br /> ** Duplicate Selective Acknowledgment (DSACK) [[https://tools.ietf.org/html/rfc2883 RFC 2883]] [[https://gitlab.com/nsnam/ns-3-dev/-/merge_requests/34/commits Implementation]]<br /> ** RACK-TLP [[https://datatracker.ietf.org/doc/html/rfc8985 RFC 8985]] [[https://gitlab.com/nsnam/ns-3-dev/-/merge_requests/34/commits Implementation]]<br /> <br /> == Large projects (350 hours) ==<br /> <br /> === IPv6 global routing ===<br /> <br /> Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], [TBD].<br /> <br /> 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).<br /> For IPv4, ns-3 provides two alternatives: GlobalRouting, and NixRouting, which just &quot;do the trick&quot; - they simply fill the routing tables in intermediate nodes, GlobalRouting using an approach similar to OSPF, NixRouting by leveraging the &quot;abstract&quot; knowledge of the network.<br /> Neither actually use any message between the nodes, so they also reduce the network overhead - something that is useful in many cases.<br /> <br /> 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.).<br /> <br /> 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.<br /> <br /> * ''Required Experience:'' Fundamentals of IPv6 addressing, C++ programming.<br /> * ''Bonus Experience:'' Familiarity with GlobalRouting implementations in ns-3<br /> * ''Interests:'' IPv6 routing<br /> * ''Difficulty:'' Medium.<br /> * ''Patch requirement:'' [[GSOC2024PatchRequirement]]<br /> * ''Recommended reading:''<br /> ** [https://www.nsnam.org/docs/models/html/ipv6.html IPv6 model in ns-3]<br /> ** [https://www.nsnam.org/docs/models/html/routing-overview.html#global-centralized-routing GlobalRouting model in ns-3]<br /> <br /> Possible tasks to fulfill the patch requirement:<br /> * 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.<br /> <br /> === AODVv2 Protocol enhancements ===<br /> <br /> Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], [TBD].<br /> <br /> 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.<br /> <br /> In particular the project should address the following points: 1) AODVv2 performances, 2) AODV address compression, 3) &quot;external&quot; network routing support, 4) general model validation against the latest draft.<br /> Collaboration with the draft authors is also highly suggested.<br /> <br /> * ''Required Experience:'' Fundamentals of IPv6 addressing, C++ programming.<br /> * ''Bonus Experience:'' Familiarity with AODV implementations in ns-3 and AODVv2<br /> * ''Interests:'' Ad hoc routing<br /> * ''Difficulty:'' Medium.<br /> * ''Patch requirement:'' [[GSOC2024PatchRequirement]]<br /> * ''Recommended reading:''<br /> ** [https://www.nsnam.org/docs/models/html/ipv6.html IPv6 model in ns-3]<br /> ** [https://www.nsnam.org/docs/models/html/aodv.html AODV model in ns-3]<br /> ** [https://datatracker.ietf.org/doc/draft-perkins-manet-aodvv2/05/ Ad Hoc On-demand Distance Vector Version 2 (AODVv2) Routing]<br /> <br /> Possible tasks to fulfill the patch requirement:<br /> * [https://gitlab.com/nsnam/ns-3-dev/-/issues/368 Issue #368] - aodv: aodv parameters can be set to &quot;impossible&quot; values<br /> <br /> === Mesh Link Establishment (MLE) protocol ===<br /> <br /> Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], TBD.<br /> <br /> 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.<br /> However, MLE is being used in Thread, and it can be useful to implement it.<br /> <br /> 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.<br /> <br /> * ''Required Experience:'' Fundamentals of IPv4 and IPv6 sockets, C++ programming.<br /> * ''Interests:'' Sockets and API interface implementation.<br /> * ''Difficulty:'' Hard.<br /> * ''Recommended reading:''<br /> ** [https://datatracker.ietf.org/doc/html/draft-ietf-6lo-mesh-link-establishment MLE draft]<br /> ** [https://openthread.io/guides/thread-primer/network-discovery Thread primer]<br /> ** [https://www.threadgroup.org/ThreadSpec Thread specifications]<br /> <br /> Possible tasks to fulfill the patch requirement:<br /> * TBD, contact the mentors if interested.<br /> <br /> === Lr-WPAN (IEEE 802.15.4) preamble detection support ===<br /> <br /> Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], [mailto:alramonet@is.tokushima-u.ac.jp Alberto Gallegos Ramonet].<br /> <br /> 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<br /> 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<br /> itself has many added benefits.<br /> <br /> 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.<br /> <br /> As usual, reduction of code duplicity and a flexible scalable design is desired (e.g. Allow the inclusion of different preambles in the future).<br /> <br /> * ''Required Experience:'' Basic understanding of IEEE 802.15.4, C++ programming.<br /> * ''Bonus Experience:'' PHY process familiarity, Familiarity with ns-3's Lr-WPAN<br /> * ''Interests:'' Lr-WPAN, MAC and PHY designs<br /> * ''Difficulty:'' Medium.<br /> * ''Patch requirement:'' [[GSOC2024PatchRequirement]]<br /> * ''Recommended reading:''<br /> ** [https://ieeexplore.ieee.org/document/1700009 IEEE 802.15.4-2006]<br /> ** [https://ieeexplore.ieee.org/document/7460875 IEEE 802.15.4-2015]<br /> ** [https://www.nsnam.org/docs/models/html/lr-wpan.html ns-3 lr-wpan module]<br /> <br /> Possible tasks to fulfill the patch requirement:<br /> * [[GSOC2024PatchRequirement]]<br /> <br /> === 5G NR module integration with ns-3-ai ===<br /> <br /> 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]<br /> <br /> 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.<br /> <br /> 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.<br /> For more specific guidelines, please view this [https://docs.google.com/document/d/1cQLIF1cdft1yj3vyWrjrxN2xDJMx8PuWaa9NP_nKf64/edit?usp=sharing Google document].<br /> <br /> * Required Experience: C++ programming, understanding of 5G NR, LTE, and wireless networks<br /> * Interests: 5G NR simulations<br /> * Difficulty: Medium.<br /> * 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.<br /> <br /> === Linux-like CAKE queue discipline for ns-3 ===<br /> <br /> Mentors: [mailto:tahiliani.nitk@gmail.com Mohit P. Tahiliani]<br /> <br /> 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.<br /> <br /> * ''Required Experience:'' Familiarity with queue disciplines, TCP and C++ programming.<br /> * ''Bonus Experience:'' Familiarity with CAKE framework in Linux 4.19<br /> * ''Interests:'' Active Queue Management, Packet scheduling and TCP.<br /> * ''Difficulty:'' Medium to Hard<br /> * ''Recommended reading:''<br /> ** [https://arxiv.org/pdf/1804.07617.pdf Piece of CAKE: A Comprehensive Queue Management Solution for Home Gateways]<br /> ** [https://lwn.net/Articles/758353/ Let them run CAKE]<br /> ** [https://www.nsnam.org/docs/models/html/queue-discs.html Queue disciplines in ns-3]</div>

Tommaso https://www.nsnam.org/mediawiki/index.php?title=GSOC2025Projects&diff=13436 2025-02-14T19:19:45Z

<p>Tommaso: /* Mesh Link Establishment (MLE) protocol */</p> <hr /> <div>{{TOC}}<br /> <br /> This page contains 2025 Google Summer of Code project ideas for ns-3.<br /> <br /> * [https://developers.google.com/open-source/gsoc/faq GSoC Frequently Asked Questions]<br /> * [[GSOC2025ContributorGuide | ns-3's 2025 GSoC Contributor guide]]<br /> * [https://developers.google.com/open-source/gsoc/resources/guide GSoC contributor/student guide (not ns-3 specific)]<br /> * [[GSOC2025ApplicationTemplate | 2025 GSoC Contributor application template]]<br /> * [[GSOCMentorGuide | ns-3's GSoC Mentor guide]]<br /> * [https://archive.flossmanuals.net/gsocmentoring/index.html GSoC Mentor guide (not ns-3 specific)]<br /> * [[GSOCSelectionProcess | GSoC Contributor Selection Process]]<br /> * ''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/<br /> <br /> === About the ns-3 project ===<br /> <br /> ns-3 is a discrete-event network simulator, with a particular emphasis on network research and education.<br /> <br /> 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.<br /> <br /> 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.<br /> <br /> === Org admins ===<br /> <br /> 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].<br /> <br /> === Mentors ===<br /> <br /> 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.<br /> <br /> The current list of prospective mentors can be found among the ideas listed below.<br /> <br /> === How to apply ===<br /> <br /> For students or contributors interested in applying to ns-3 for GSoC, please go through the following list to get started:<br /> * Read the official [https://developers.google.com/open-source/gsoc/resources/guide GSoC contributor guide].<br /> * Read [[GSOC2025ContributorGuide |ns-3's 2025 GSoC contributor guide]]<br /> * Look through our [[#Project Ideas]] below to see if you find a project that interests you.<br /> * Review the [https://www.nsnam.org/documentation/development-tree/ tutorial and contributing guide] thoroughly, if you have not already done so.<br /> * 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.<br /> * Next, proceed to get in touch with the developers on the mailing list or Zulip chat room and refine your proposal.<br /> * 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.<br /> <br /> 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.<br /> <br /> &lt;blockquote&gt;<br /> Each project idea within a particular priority has been tagged with the following properties:<br /> * ''Required Experience:'' Languages, concepts, or packages with which applicants must be familiar.<br /> * ''Bonus Experience:'' Other experience or familiarity which would be greatly helpful to applicants for this project.<br /> * ''Interests:'' Areas of particular relevance to this project, and an indicator of where successful contributors might apply their experiences coming out of this project.<br /> * ''Difficulty:'' easy, medium or difficult<br /> * ''Recommended reading:'' pointers to documentation, papers, specific bugs, etc.<br /> <br /> 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.<br /> &lt;/blockquote&gt;<br /> <br /> === Patch requirement guidelines ===<br /> <br /> 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.<br /> <br /> === Mentors: how to participate ===<br /> <br /> 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:<br /> <br /> * 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.<br /> * 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.<br /> * 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.<br /> <br /> == Project Ideas ==<br /> <br /> '''Note to contributors:''' These ideas are not listed in any priority order.<br /> 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.<br /> <br /> === Internet models enhancements ===<br /> <br /> * [[#ICMP socket and generate/handle ICMP messages (host/net unreachable)]] (medium size project, 175h)<br /> * [[#IPv6 global routing]] (large size project, 350h)<br /> * [[#IPv6 support in Ad hoc Routing Protocols]] (large size project, 350h)<br /> <br /> === IoT models enhancements ===<br /> <br /> * [[#6LoWPAN mesh-under routing enhancements]] (medium size project, 175h)<br /> * [[#6LoWPAN neighbor discovery protocol]] (medium size project, 175h)<br /> * [[#Mesh Link Establishment (MLE) protocol ]] (large size project, 350h)<br /> * [[#Lr-WPAN (IEEE 802.15.4) preamble detection support]] (large size project, 350h)<br /> <br /> === 5G NR models enhancements ===<br /> <br /> 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.<br /> <br /> * [[#NTN example for 5G NR]] (small size project, 90h)<br /> * [[#5G NR module integration with ns-3-ai]] (large size project, 250h)<br /> * [[#Enabling 5G NR examples visualization]] (large size project, 175h)<br /> * [[#Improving 5G NR module usability through helpers]] (medium size project, 175h)<br /> <br /> == Small sized projects (90 hours) ==<br /> <br /> <br /> === NTN example for 5G NR ===<br /> <br /> 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]<br /> <br /> 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).<br /> <br /> 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.<br /> <br /> * Required Experience: C++ programming, understanding of 5G NR, LTE, and wireless networks<br /> * Interests: 5G NR simulations<br /> * Difficulty: Medium.<br /> * 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.<br /> <br /> === Upgrade the AQM Evaluation Suite for ns-3 ===<br /> <br /> Mentors: [mailto:tahiliani.nitk@gmail.com Mohit P. Tahiliani]<br /> <br /> 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.<br /> <br /> * ''Required Experience:'' Familiarity with AQM and C++ programming.<br /> * ''Bonus Experience:'' Familiarity with traffic control model in ns-3.<br /> * ''Interests:'' Packet Scheduling algorithms, AQM algorithms and ECN.<br /> * ''Difficulty:'' Medium.<br /> * ''Recommended Reading:''<br /> ** AQM Evaluation Suite [[https://dl.acm.org/doi/abs/10.1145/3067665.3067674 Paper]] [[https://aqm-eval-suite.github.io/ Implementation]]<br /> ** [https://tools.ietf.org/html/rfc7928 RFC 7928]<br /> ** [https://www.nsnam.org/docs/models/html/traffic-control-layer.html Traffic Control Model in ns-3]<br /> * ''Patch requirement:'' Create a pull request to handle the case when an incorrect Scenario name or number is passed via command line.<br /> <br /> == Medium sized projects (175 hours) ==<br /> <br /> === ICMP socket and generate/handle ICMP messages (host/net unreachable) ===<br /> <br /> Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], [mailto:manoj24.rana@gmail.com Manoj K. Rana].<br /> <br /> 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 &quot;RAW&quot; socket.<br /> 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.<br /> <br /> 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.<br /> <br /> The most important point of the implementation should be code duplicate minimization, in order to have the minimize maintenance efforts.<br /> <br /> Once the sockets are in place, beside the &quot;normal&quot; tests, it will be necessary to modify the code that is actually made obsolete by the new sockets, e.g.:<br /> * IPv6 ICMP messages (RA, RS, NA, NS, etc.),<br /> * IPv4 ICMP messages,<br /> * ICMP Echo and ICMPv6 Echo messages.<br /> and to handle properly ICMP error messages like Destination Unreachable in the Ping application.<br /> <br /> * ''Required Experience:'' Fundamentals of IPv4 and IPv6 sockets, C++ programming.<br /> * ''Interests:'' Sockets and API interface implementation.<br /> * ''Difficulty:'' Medium.<br /> * ''Recommended reading:''<br /> ** [https://man7.org/linux/man-pages/man2/socket.2.html Linux socket]<br /> ** [https://courses.cs.vt.edu/cs4254/fall04/slides/raw_1.pdf Raw Sockets and ICMP, Srinidhi Varadarajan]<br /> ** [https://gitlab.com/nsnam/ns-3-dev/-/issues/810 Issue #810]<br /> <br /> Possible tasks to fulfill the patch requirement:<br /> * Submit a patch to fix [https://gitlab.com/nsnam/ns-3-dev/-/issues/809 Issue #809]<br /> <br /> === 6LoWPAN mesh-under routing enhancements ===<br /> <br /> Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], [TBD].<br /> <br /> 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.<br /> 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.<br /> <br /> The candidate should outline what parts of code are going to be affected, and how they can be enhanced thanks to RFC 7731.<br /> <br /> * ''Required Experience:'' Fundamentals of IPv6 addressing, C++ programming.<br /> * ''Bonus Experience:'' Familiarity with mesh routing and 6LoWPAN ns-3<br /> * ''Interests:'' IPv6 mesh routing<br /> * ''Difficulty:'' Easy.<br /> * ''Patch requirement:'' [[GSOC2024PatchRequirement]]<br /> * ''Recommended reading:''<br /> ** [https://www.nsnam.org/docs/models/html/sixlowpan.html#mesh-under-routing Mesh-under in ns-3 6LoWPAN]<br /> ** [https://datatracker.ietf.org/doc/html/rfc7731 RFC 7731]<br /> <br /> Possible tasks to fulfill the patch requirement:<br /> * TBD<br /> <br /> === 6LoWPAN neighbor discovery protocol ===<br /> <br /> Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], [TBD].<br /> <br /> 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.<br /> <br /> 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).<br /> <br /> 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.<br /> <br /> * ''Required Experience:'' Fundamentals of IPv6 addressing, C++ programming.<br /> * ''Bonus Experience:'' Familiarity with 6LoWPAN and 6LoWPAN-ND<br /> * ''Interests:'' IPv6 and IoT networks<br /> * ''Difficulty:'' Easy.<br /> * ''Patch requirement:'' [[GSOC2024PatchRequirement]]<br /> * ''Recommended reading:''<br /> ** [https://datatracker.ietf.org/doc/html/rfc8505 RFC 8505]<br /> ** [https://datatracker.ietf.org/doc/html/rfc6775 RFC 6775]<br /> ** [https://datatracker.ietf.org/doc/html/rfc4944 RFC 4944]<br /> <br /> Possible tasks to fulfil the patch requirement:<br /> * Patch the actual 6LoWPAN-ND to remove the limitation about concurrent address registrations.<br /> <br /> === Improving 5G NR module usability through helpers ===<br /> <br /> 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]<br /> <br /> 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.<br /> <br /> 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.<br /> <br /> * Required Experience: C++ programming, understanding of 5G NR, LTE, and wireless networks<br /> * Interests: 5G NR simulations<br /> * Difficulty: Medium.<br /> * 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.<br /> <br /> === Enabling 5G NR examples visualization ===<br /> <br /> 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]<br /> <br /> 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.<br /> <br /> 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.<br /> 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].<br /> <br /> * Required Experience: C++ and Python programming, understanding of 5G NR, LTE, and wireless networks<br /> * Interests: 5G NR simulations<br /> * Difficulty: Medium.<br /> * 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.<br /> <br /> === Linux-like Loss Detection Techniques for ns-3 TCP ===<br /> <br /> Mentors: [mailto:tahiliani.nitk@gmail.com Mohit P. Tahiliani]<br /> <br /> 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.<br /> <br /> * ''Required Experience:'' Familiarity with TCP and C++ programming.<br /> * ''Bonus Experience:'' Familiarity with TCP implementation in Linux kernel.<br /> * ''Interests:'' TCP packet loss detection techniques.<br /> * ''Difficulty:'' Medium to Hard.<br /> * ''Recommended Reading:''<br /> ** Forward Acknowledgement (FACK) [[https://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.41.2559&amp;rep=rep1&amp;type=pdf Paper]] [[https://gitlab.com/nsnam/ns-3-dev/-/merge_requests/34/commits Implementation]]<br /> ** Duplicate Selective Acknowledgment (DSACK) [[https://tools.ietf.org/html/rfc2883 RFC 2883]] [[https://gitlab.com/nsnam/ns-3-dev/-/merge_requests/34/commits Implementation]]<br /> ** RACK-TLP [[https://datatracker.ietf.org/doc/html/rfc8985 RFC 8985]] [[https://gitlab.com/nsnam/ns-3-dev/-/merge_requests/34/commits Implementation]]<br /> <br /> == Large projects (350 hours) ==<br /> <br /> === IPv6 global routing ===<br /> <br /> Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], [TBD].<br /> <br /> 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).<br /> For IPv4, ns-3 provides two alternatives: GlobalRouting, and NixRouting, which just &quot;do the trick&quot; - they simply fill the routing tables in intermediate nodes, GlobalRouting using an approach similar to OSPF, NixRouting by leveraging the &quot;abstract&quot; knowledge of the network.<br /> Neither actually use any message between the nodes, so they also reduce the network overhead - something that is useful in many cases.<br /> <br /> 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.).<br /> <br /> 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.<br /> <br /> * ''Required Experience:'' Fundamentals of IPv6 addressing, C++ programming.<br /> * ''Bonus Experience:'' Familiarity with GlobalRouting implementations in ns-3<br /> * ''Interests:'' IPv6 routing<br /> * ''Difficulty:'' Medium.<br /> * ''Patch requirement:'' [[GSOC2024PatchRequirement]]<br /> * ''Recommended reading:''<br /> ** [https://www.nsnam.org/docs/models/html/ipv6.html IPv6 model in ns-3]<br /> ** [https://www.nsnam.org/docs/models/html/routing-overview.html#global-centralized-routing GlobalRouting model in ns-3]<br /> <br /> Possible tasks to fulfill the patch requirement:<br /> * 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.<br /> <br /> === AODVv2 Protocol enhancements ===<br /> <br /> Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], [TBD].<br /> <br /> 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.<br /> <br /> In particular the project should address the following points: 1) AODVv2 performances, 2) AODV address compression, 3) &quot;external&quot; network routing support, 4) general model validation against the latest draft.<br /> Collaboration with the draft authors is also highly suggested.<br /> <br /> * ''Required Experience:'' Fundamentals of IPv6 addressing, C++ programming.<br /> * ''Bonus Experience:'' Familiarity with AODV implementations in ns-3 and AODVv2<br /> * ''Interests:'' Ad hoc routing<br /> * ''Difficulty:'' Medium.<br /> * ''Patch requirement:'' [[GSOC2024PatchRequirement]]<br /> * ''Recommended reading:''<br /> ** [https://www.nsnam.org/docs/models/html/ipv6.html IPv6 model in ns-3]<br /> ** [https://www.nsnam.org/docs/models/html/aodv.html AODV model in ns-3]<br /> ** [https://datatracker.ietf.org/doc/draft-perkins-manet-aodvv2/05/ Ad Hoc On-demand Distance Vector Version 2 (AODVv2) Routing]<br /> <br /> Possible tasks to fulfill the patch requirement:<br /> * [https://gitlab.com/nsnam/ns-3-dev/-/issues/368 Issue #368] - aodv: aodv parameters can be set to &quot;impossible&quot; values<br /> <br /> === Mesh Link Establishment (MLE) protocol ===<br /> <br /> Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], TBD.<br /> <br /> 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.<br /> However, MLE is being used in Thread, and it can be useful to implement it.<br /> <br /> 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.<br /> <br /> * ''Required Experience:'' Fundamentals of IPv4 and IPv6 sockets, C++ programming.<br /> * ''Interests:'' Sockets and API interface implementation.<br /> * ''Difficulty:'' Hard.<br /> * ''Recommended reading:''<br /> ** [https://datatracker.ietf.org/doc/html/draft-ietf-6lo-mesh-link-establishment MLE draft]<br /> ** [https://openthread.io/guides/thread-primer/network-discovery Thread primer]<br /> ** [https://www.threadgroup.org/ThreadSpec Thread specifications]<br /> <br /> Possible tasks to fulfill the patch requirement:<br /> * TBD, contact the mentors if interested.<br /> <br /> === Lr-WPAN (IEEE 802.15.4) preamble detection support ===<br /> <br /> Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], [mailto:alramonet@is.tokushima-u.ac.jp Alberto Gallegos Ramonet].<br /> <br /> 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<br /> 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<br /> itself has many added benefits.<br /> <br /> 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.<br /> <br /> As usual, reduction of code duplicity and a flexible scalable design is desired (e.g. Allow the inclusion of different preambles in the future).<br /> <br /> * ''Required Experience:'' Basic understanding of IEEE 802.15.4, C++ programming.<br /> * ''Bonus Experience:'' PHY process familiarity, Familiarity with ns-3's Lr-WPAN<br /> * ''Interests:'' Lr-WPAN, MAC and PHY designs<br /> * ''Difficulty:'' Medium.<br /> * ''Patch requirement:'' [[GSOC2024PatchRequirement]]<br /> * ''Recommended reading:''<br /> ** [https://ieeexplore.ieee.org/document/1700009 IEEE 802.15.4-2006]<br /> ** [https://ieeexplore.ieee.org/document/7460875 IEEE 802.15.4-2015]<br /> ** [https://www.nsnam.org/docs/models/html/lr-wpan.html ns-3 lr-wpan module]<br /> <br /> Possible tasks to fulfill the patch requirement:<br /> * [[GSOC2024PatchRequirement]]<br /> <br /> === 5G NR module integration with ns-3-ai ===<br /> <br /> 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]<br /> <br /> 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.<br /> <br /> 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.<br /> For more specific guidelines, please view this [https://docs.google.com/document/d/1cQLIF1cdft1yj3vyWrjrxN2xDJMx8PuWaa9NP_nKf64/edit?usp=sharing Google document].<br /> <br /> * Required Experience: C++ programming, understanding of 5G NR, LTE, and wireless networks<br /> * Interests: 5G NR simulations<br /> * Difficulty: Medium.<br /> * 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.<br /> <br /> === Linux-like CAKE queue discipline for ns-3 ===<br /> <br /> Mentors: [mailto:tahiliani.nitk@gmail.com Mohit P. Tahiliani]<br /> <br /> 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.<br /> <br /> * ''Required Experience:'' Familiarity with queue disciplines, TCP and C++ programming.<br /> * ''Bonus Experience:'' Familiarity with CAKE framework in Linux 4.19<br /> * ''Interests:'' Active Queue Management, Packet scheduling and TCP.<br /> * ''Difficulty:'' Medium to Hard<br /> * ''Recommended reading:''<br /> ** [https://arxiv.org/pdf/1804.07617.pdf Piece of CAKE: A Comprehensive Queue Management Solution for Home Gateways]<br /> ** [https://lwn.net/Articles/758353/ Let them run CAKE]<br /> ** [https://www.nsnam.org/docs/models/html/queue-discs.html Queue disciplines in ns-3]</div>

Tommaso https://www.nsnam.org/mediawiki/index.php?title=GSOC2025Projects&diff=13435 2025-02-14T19:18:31Z

<p>Tommaso: /* ICMP socket and generate/handle ICMP messages (host/net unreachable) */</p> <hr /> <div>{{TOC}}<br /> <br /> This page contains 2025 Google Summer of Code project ideas for ns-3.<br /> <br /> * [https://developers.google.com/open-source/gsoc/faq GSoC Frequently Asked Questions]<br /> * [[GSOC2025ContributorGuide | ns-3's 2025 GSoC Contributor guide]]<br /> * [https://developers.google.com/open-source/gsoc/resources/guide GSoC contributor/student guide (not ns-3 specific)]<br /> * [[GSOC2025ApplicationTemplate | 2025 GSoC Contributor application template]]<br /> * [[GSOCMentorGuide | ns-3's GSoC Mentor guide]]<br /> * [https://archive.flossmanuals.net/gsocmentoring/index.html GSoC Mentor guide (not ns-3 specific)]<br /> * [[GSOCSelectionProcess | GSoC Contributor Selection Process]]<br /> * ''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/<br /> <br /> === About the ns-3 project ===<br /> <br /> ns-3 is a discrete-event network simulator, with a particular emphasis on network research and education.<br /> <br /> 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.<br /> <br /> 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.<br /> <br /> === Org admins ===<br /> <br /> 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].<br /> <br /> === Mentors ===<br /> <br /> 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.<br /> <br /> The current list of prospective mentors can be found among the ideas listed below.<br /> <br /> === How to apply ===<br /> <br /> For students or contributors interested in applying to ns-3 for GSoC, please go through the following list to get started:<br /> * Read the official [https://developers.google.com/open-source/gsoc/resources/guide GSoC contributor guide].<br /> * Read [[GSOC2025ContributorGuide |ns-3's 2025 GSoC contributor guide]]<br /> * Look through our [[#Project Ideas]] below to see if you find a project that interests you.<br /> * Review the [https://www.nsnam.org/documentation/development-tree/ tutorial and contributing guide] thoroughly, if you have not already done so.<br /> * 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.<br /> * Next, proceed to get in touch with the developers on the mailing list or Zulip chat room and refine your proposal.<br /> * 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.<br /> <br /> 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.<br /> <br /> &lt;blockquote&gt;<br /> Each project idea within a particular priority has been tagged with the following properties:<br /> * ''Required Experience:'' Languages, concepts, or packages with which applicants must be familiar.<br /> * ''Bonus Experience:'' Other experience or familiarity which would be greatly helpful to applicants for this project.<br /> * ''Interests:'' Areas of particular relevance to this project, and an indicator of where successful contributors might apply their experiences coming out of this project.<br /> * ''Difficulty:'' easy, medium or difficult<br /> * ''Recommended reading:'' pointers to documentation, papers, specific bugs, etc.<br /> <br /> 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.<br /> &lt;/blockquote&gt;<br /> <br /> === Patch requirement guidelines ===<br /> <br /> 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.<br /> <br /> === Mentors: how to participate ===<br /> <br /> 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:<br /> <br /> * 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.<br /> * 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.<br /> * 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.<br /> <br /> == Project Ideas ==<br /> <br /> '''Note to contributors:''' These ideas are not listed in any priority order.<br /> 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.<br /> <br /> === Internet models enhancements ===<br /> <br /> * [[#ICMP socket and generate/handle ICMP messages (host/net unreachable)]] (medium size project, 175h)<br /> * [[#IPv6 global routing]] (large size project, 350h)<br /> * [[#IPv6 support in Ad hoc Routing Protocols]] (large size project, 350h)<br /> <br /> === IoT models enhancements ===<br /> <br /> * [[#6LoWPAN mesh-under routing enhancements]] (medium size project, 175h)<br /> * [[#6LoWPAN neighbor discovery protocol]] (medium size project, 175h)<br /> * [[#Mesh Link Establishment (MLE) protocol ]] (large size project, 350h)<br /> * [[#Lr-WPAN (IEEE 802.15.4) preamble detection support]] (large size project, 350h)<br /> <br /> === 5G NR models enhancements ===<br /> <br /> 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.<br /> <br /> * [[#NTN example for 5G NR]] (small size project, 90h)<br /> * [[#5G NR module integration with ns-3-ai]] (large size project, 250h)<br /> * [[#Enabling 5G NR examples visualization]] (large size project, 175h)<br /> * [[#Improving 5G NR module usability through helpers]] (medium size project, 175h)<br /> <br /> == Small sized projects (90 hours) ==<br /> <br /> <br /> === NTN example for 5G NR ===<br /> <br /> 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]<br /> <br /> 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).<br /> <br /> 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.<br /> <br /> * Required Experience: C++ programming, understanding of 5G NR, LTE, and wireless networks<br /> * Interests: 5G NR simulations<br /> * Difficulty: Medium.<br /> * 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.<br /> <br /> === Upgrade the AQM Evaluation Suite for ns-3 ===<br /> <br /> Mentors: [mailto:tahiliani.nitk@gmail.com Mohit P. Tahiliani]<br /> <br /> 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.<br /> <br /> * ''Required Experience:'' Familiarity with AQM and C++ programming.<br /> * ''Bonus Experience:'' Familiarity with traffic control model in ns-3.<br /> * ''Interests:'' Packet Scheduling algorithms, AQM algorithms and ECN.<br /> * ''Difficulty:'' Medium.<br /> * ''Recommended Reading:''<br /> ** AQM Evaluation Suite [[https://dl.acm.org/doi/abs/10.1145/3067665.3067674 Paper]] [[https://aqm-eval-suite.github.io/ Implementation]]<br /> ** [https://tools.ietf.org/html/rfc7928 RFC 7928]<br /> ** [https://www.nsnam.org/docs/models/html/traffic-control-layer.html Traffic Control Model in ns-3]<br /> * ''Patch requirement:'' Create a pull request to handle the case when an incorrect Scenario name or number is passed via command line.<br /> <br /> == Medium sized projects (175 hours) ==<br /> <br /> === ICMP socket and generate/handle ICMP messages (host/net unreachable) ===<br /> <br /> Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], [mailto:manoj24.rana@gmail.com Manoj K. Rana].<br /> <br /> 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 &quot;RAW&quot; socket.<br /> 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.<br /> <br /> 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.<br /> <br /> The most important point of the implementation should be code duplicate minimization, in order to have the minimize maintenance efforts.<br /> <br /> Once the sockets are in place, beside the &quot;normal&quot; tests, it will be necessary to modify the code that is actually made obsolete by the new sockets, e.g.:<br /> * IPv6 ICMP messages (RA, RS, NA, NS, etc.),<br /> * IPv4 ICMP messages,<br /> * ICMP Echo and ICMPv6 Echo messages.<br /> and to handle properly ICMP error messages like Destination Unreachable in the Ping application.<br /> <br /> * ''Required Experience:'' Fundamentals of IPv4 and IPv6 sockets, C++ programming.<br /> * ''Interests:'' Sockets and API interface implementation.<br /> * ''Difficulty:'' Medium.<br /> * ''Recommended reading:''<br /> ** [https://man7.org/linux/man-pages/man2/socket.2.html Linux socket]<br /> ** [https://courses.cs.vt.edu/cs4254/fall04/slides/raw_1.pdf Raw Sockets and ICMP, Srinidhi Varadarajan]<br /> ** [https://gitlab.com/nsnam/ns-3-dev/-/issues/810 Issue #810]<br /> <br /> Possible tasks to fulfill the patch requirement:<br /> * Submit a patch to fix [https://gitlab.com/nsnam/ns-3-dev/-/issues/809 Issue #809]<br /> <br /> === 6LoWPAN mesh-under routing enhancements ===<br /> <br /> Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], [TBD].<br /> <br /> 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.<br /> 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.<br /> <br /> The candidate should outline what parts of code are going to be affected, and how they can be enhanced thanks to RFC 7731.<br /> <br /> * ''Required Experience:'' Fundamentals of IPv6 addressing, C++ programming.<br /> * ''Bonus Experience:'' Familiarity with mesh routing and 6LoWPAN ns-3<br /> * ''Interests:'' IPv6 mesh routing<br /> * ''Difficulty:'' Easy.<br /> * ''Patch requirement:'' [[GSOC2024PatchRequirement]]<br /> * ''Recommended reading:''<br /> ** [https://www.nsnam.org/docs/models/html/sixlowpan.html#mesh-under-routing Mesh-under in ns-3 6LoWPAN]<br /> ** [https://datatracker.ietf.org/doc/html/rfc7731 RFC 7731]<br /> <br /> Possible tasks to fulfill the patch requirement:<br /> * TBD<br /> <br /> === 6LoWPAN neighbor discovery protocol ===<br /> <br /> Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], [TBD].<br /> <br /> 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.<br /> <br /> 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).<br /> <br /> 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.<br /> <br /> * ''Required Experience:'' Fundamentals of IPv6 addressing, C++ programming.<br /> * ''Bonus Experience:'' Familiarity with 6LoWPAN and 6LoWPAN-ND<br /> * ''Interests:'' IPv6 and IoT networks<br /> * ''Difficulty:'' Easy.<br /> * ''Patch requirement:'' [[GSOC2024PatchRequirement]]<br /> * ''Recommended reading:''<br /> ** [https://datatracker.ietf.org/doc/html/rfc8505 RFC 8505]<br /> ** [https://datatracker.ietf.org/doc/html/rfc6775 RFC 6775]<br /> ** [https://datatracker.ietf.org/doc/html/rfc4944 RFC 4944]<br /> <br /> Possible tasks to fulfil the patch requirement:<br /> * Patch the actual 6LoWPAN-ND to remove the limitation about concurrent address registrations.<br /> <br /> === Improving 5G NR module usability through helpers ===<br /> <br /> 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]<br /> <br /> 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.<br /> <br /> 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.<br /> <br /> * Required Experience: C++ programming, understanding of 5G NR, LTE, and wireless networks<br /> * Interests: 5G NR simulations<br /> * Difficulty: Medium.<br /> * 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.<br /> <br /> === Enabling 5G NR examples visualization ===<br /> <br /> 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]<br /> <br /> 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.<br /> <br /> 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.<br /> 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].<br /> <br /> * Required Experience: C++ and Python programming, understanding of 5G NR, LTE, and wireless networks<br /> * Interests: 5G NR simulations<br /> * Difficulty: Medium.<br /> * 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.<br /> <br /> === Linux-like Loss Detection Techniques for ns-3 TCP ===<br /> <br /> Mentors: [mailto:tahiliani.nitk@gmail.com Mohit P. Tahiliani]<br /> <br /> 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.<br /> <br /> * ''Required Experience:'' Familiarity with TCP and C++ programming.<br /> * ''Bonus Experience:'' Familiarity with TCP implementation in Linux kernel.<br /> * ''Interests:'' TCP packet loss detection techniques.<br /> * ''Difficulty:'' Medium to Hard.<br /> * ''Recommended Reading:''<br /> ** Forward Acknowledgement (FACK) [[https://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.41.2559&amp;rep=rep1&amp;type=pdf Paper]] [[https://gitlab.com/nsnam/ns-3-dev/-/merge_requests/34/commits Implementation]]<br /> ** Duplicate Selective Acknowledgment (DSACK) [[https://tools.ietf.org/html/rfc2883 RFC 2883]] [[https://gitlab.com/nsnam/ns-3-dev/-/merge_requests/34/commits Implementation]]<br /> ** RACK-TLP [[https://datatracker.ietf.org/doc/html/rfc8985 RFC 8985]] [[https://gitlab.com/nsnam/ns-3-dev/-/merge_requests/34/commits Implementation]]<br /> <br /> == Large projects (350 hours) ==<br /> <br /> === IPv6 global routing ===<br /> <br /> Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], [TBD].<br /> <br /> 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).<br /> For IPv4, ns-3 provides two alternatives: GlobalRouting, and NixRouting, which just &quot;do the trick&quot; - they simply fill the routing tables in intermediate nodes, GlobalRouting using an approach similar to OSPF, NixRouting by leveraging the &quot;abstract&quot; knowledge of the network.<br /> Neither actually use any message between the nodes, so they also reduce the network overhead - something that is useful in many cases.<br /> <br /> 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.).<br /> <br /> 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.<br /> <br /> * ''Required Experience:'' Fundamentals of IPv6 addressing, C++ programming.<br /> * ''Bonus Experience:'' Familiarity with GlobalRouting implementations in ns-3<br /> * ''Interests:'' IPv6 routing<br /> * ''Difficulty:'' Medium.<br /> * ''Patch requirement:'' [[GSOC2024PatchRequirement]]<br /> * ''Recommended reading:''<br /> ** [https://www.nsnam.org/docs/models/html/ipv6.html IPv6 model in ns-3]<br /> ** [https://www.nsnam.org/docs/models/html/routing-overview.html#global-centralized-routing GlobalRouting model in ns-3]<br /> <br /> Possible tasks to fulfill the patch requirement:<br /> * 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.<br /> <br /> === AODVv2 Protocol enhancements ===<br /> <br /> Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], [TBD].<br /> <br /> 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.<br /> <br /> In particular the project should address the following points: 1) AODVv2 performances, 2) AODV address compression, 3) &quot;external&quot; network routing support, 4) general model validation against the latest draft.<br /> Collaboration with the draft authors is also highly suggested.<br /> <br /> * ''Required Experience:'' Fundamentals of IPv6 addressing, C++ programming.<br /> * ''Bonus Experience:'' Familiarity with AODV implementations in ns-3 and AODVv2<br /> * ''Interests:'' Ad hoc routing<br /> * ''Difficulty:'' Medium.<br /> * ''Patch requirement:'' [[GSOC2024PatchRequirement]]<br /> * ''Recommended reading:''<br /> ** [https://www.nsnam.org/docs/models/html/ipv6.html IPv6 model in ns-3]<br /> ** [https://www.nsnam.org/docs/models/html/aodv.html AODV model in ns-3]<br /> ** [https://datatracker.ietf.org/doc/draft-perkins-manet-aodvv2/05/ Ad Hoc On-demand Distance Vector Version 2 (AODVv2) Routing]<br /> <br /> Possible tasks to fulfill the patch requirement:<br /> * [https://gitlab.com/nsnam/ns-3-dev/-/issues/368 Issue #368] - aodv: aodv parameters can be set to &quot;impossible&quot; values<br /> <br /> === Mesh Link Establishment (MLE) protocol ===<br /> <br /> Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], TBD.<br /> <br /> 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.<br /> However, MLE is being used in Thread, and it can be useful to implement it.<br /> <br /> 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.<br /> <br /> * ''Required Experience:'' Fundamentals of IPv4 and IPv6 sockets, C++ programming.<br /> * ''Interests:'' Sockets and API interface implementation.<br /> * ''Difficulty:'' Hard.<br /> * ''Recommended reading:''<br /> ** [https://datatracker.ietf.org/doc/html/draft-ietf-6lo-mesh-link-establishment MLE draft]<br /> ** [https://openthread.io/guides/thread-primer/network-discovery Thread primer]<br /> ** [https://www.threadgroup.org/ThreadSpec Thread specifications]<br /> <br /> Possible tasks to fulfill the patch requirement:<br /> * [[GSOC2024PatchRequirement]]<br /> <br /> === Lr-WPAN (IEEE 802.15.4) preamble detection support ===<br /> <br /> Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], [mailto:alramonet@is.tokushima-u.ac.jp Alberto Gallegos Ramonet].<br /> <br /> 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<br /> 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<br /> itself has many added benefits.<br /> <br /> 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.<br /> <br /> As usual, reduction of code duplicity and a flexible scalable design is desired (e.g. Allow the inclusion of different preambles in the future).<br /> <br /> * ''Required Experience:'' Basic understanding of IEEE 802.15.4, C++ programming.<br /> * ''Bonus Experience:'' PHY process familiarity, Familiarity with ns-3's Lr-WPAN<br /> * ''Interests:'' Lr-WPAN, MAC and PHY designs<br /> * ''Difficulty:'' Medium.<br /> * ''Patch requirement:'' [[GSOC2024PatchRequirement]]<br /> * ''Recommended reading:''<br /> ** [https://ieeexplore.ieee.org/document/1700009 IEEE 802.15.4-2006]<br /> ** [https://ieeexplore.ieee.org/document/7460875 IEEE 802.15.4-2015]<br /> ** [https://www.nsnam.org/docs/models/html/lr-wpan.html ns-3 lr-wpan module]<br /> <br /> Possible tasks to fulfill the patch requirement:<br /> * [[GSOC2024PatchRequirement]]<br /> <br /> === 5G NR module integration with ns-3-ai ===<br /> <br /> 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]<br /> <br /> 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.<br /> <br /> 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.<br /> For more specific guidelines, please view this [https://docs.google.com/document/d/1cQLIF1cdft1yj3vyWrjrxN2xDJMx8PuWaa9NP_nKf64/edit?usp=sharing Google document].<br /> <br /> * Required Experience: C++ programming, understanding of 5G NR, LTE, and wireless networks<br /> * Interests: 5G NR simulations<br /> * Difficulty: Medium.<br /> * 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.<br /> <br /> === Linux-like CAKE queue discipline for ns-3 ===<br /> <br /> Mentors: [mailto:tahiliani.nitk@gmail.com Mohit P. Tahiliani]<br /> <br /> 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.<br /> <br /> * ''Required Experience:'' Familiarity with queue disciplines, TCP and C++ programming.<br /> * ''Bonus Experience:'' Familiarity with CAKE framework in Linux 4.19<br /> * ''Interests:'' Active Queue Management, Packet scheduling and TCP.<br /> * ''Difficulty:'' Medium to Hard<br /> * ''Recommended reading:''<br /> ** [https://arxiv.org/pdf/1804.07617.pdf Piece of CAKE: A Comprehensive Queue Management Solution for Home Gateways]<br /> ** [https://lwn.net/Articles/758353/ Let them run CAKE]<br /> ** [https://www.nsnam.org/docs/models/html/queue-discs.html Queue disciplines in ns-3]</div>

Tommaso https://www.nsnam.org/mediawiki/index.php?title=GSOC2025Projects&diff=13374 2025-02-10T08:39:52Z

<p>Tommaso: /* Internet models enhancements */</p> <hr /> <div>{{TOC}}<br /> <br /> This page contains 2025 Google Summer of Code project ideas for ns-3.<br /> <br /> * [https://developers.google.com/open-source/gsoc/faq GSoC Frequently Asked Questions]<br /> * [[GSOC2024ContributorGuide |ns-3's 2024 GSoC Contributor guide]]<br /> * [https://developers.google.com/open-source/gsoc/resources/guide GSoC contributor/student guide (not ns-3 specific)]<br /> * [[GSOC2024ApplicationTemplate |2024 GSoC Contributor application template]]<br /> * [[GSOCMentorGuide | ns-3's GSoC Mentor guide]]<br /> * [https://archive.flossmanuals.net/gsocmentoring/index.html GSoC Mentor guide (not ns-3 specific)]<br /> * [[GSOCSelectionProcess | GSoC Contributor Selection Process]]<br /> * ''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/<br /> <br /> === About the ns-3 project ===<br /> <br /> ns-3 is a discrete-event network simulator, with a particular emphasis on network research and education.<br /> <br /> 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.<br /> <br /> 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.<br /> <br /> === Org admins ===<br /> <br /> 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].<br /> <br /> === Mentors ===<br /> <br /> 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.<br /> <br /> The current list of prospective mentors can be found among the ideas listed below.<br /> <br /> === How to apply ===<br /> <br /> For students or contributors interested in applying to ns-3 for GSoC, please go through the following list to get started:<br /> * Read the official [https://developers.google.com/open-source/gsoc/resources/guide GSoC contributor guide].<br /> * Read [[GSOC2024ContributorGuide |ns-3's GSoC contributor guide]]<br /> * Look through our [[#Project Ideas]] below to see if you find a project that interests you.<br /> * Review the [https://www.nsnam.org/documentation/development-tree/ tutorial and contributing guide] thoroughly, if you have not already done so.<br /> * 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.<br /> * Next, proceed to get in touch with the developers on the mailing list or Zulip chat room and refine your proposal.<br /> * 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.<br /> <br /> 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.<br /> <br /> &lt;blockquote&gt;<br /> Each project idea within a particular priority has been tagged with the following properties:<br /> * ''Required Experience:'' Languages, concepts, or packages with which applicants must be familiar.<br /> * ''Bonus Experience:'' Other experience or familiarity which would be greatly helpful to applicants for this project.<br /> * ''Interests:'' Areas of particular relevance to this project, and an indicator of where successful contributors might apply their experiences coming out of this project.<br /> * ''Difficulty:'' easy, medium or difficult<br /> * ''Recommended reading:'' pointers to documentation, papers, specific bugs, etc.<br /> <br /> 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.<br /> &lt;/blockquote&gt;<br /> <br /> === Patch requirement guidelines ===<br /> <br /> 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.<br /> <br /> 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.<br /> <br /> === Mentors: how to participate ===<br /> <br /> 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:<br /> <br /> * 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.<br /> * 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.<br /> * 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.<br /> <br /> == Project Ideas ==<br /> <br /> '''Note to contributors:''' These ideas are not listed in any priority order.<br /> 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.<br /> <br /> === Internet models enhancements ===<br /> <br /> * [[#ICMP socket and generate/handle ICMP messages (host/net unreachable)]] (medium size project, 175h)<br /> * [[#IPv6 global routing]] (large size project, 350h)<br /> * [[#IPv6 support in Ad hoc Routing Protocols]] (large size project, 350h)<br /> <br /> === IoT models enhancements ===<br /> <br /> * [[#6LoWPAN mesh-under routing enhancements]] (medium size project, 175h)<br /> * [[#6LoWPAN neighbor discovery protocol]] (medium size project, 175h)<br /> * [[#Mesh Link Establishment (MLE) protocol ]] (large size project, 350h)<br /> * [[#Lr-WPAN (IEEE 802.15.4) preamble detection support]] (large size project, 350h)<br /> <br /> === 5G NR models enhancements ===<br /> <br /> * [[#Improving 5G NR module usability]] (medium size project, 90h)<br /> * [[#Improving 5G NR module visualizations]] (medium size project, 175h)<br /> * [[#5G NR module benchmark analysis for different channel models]] (medium size project, 175h)<br /> <br /> == Small sized projects (90 hours) ==<br /> <br /> ===== Improving 5G NR module visualizations =====<br /> <br /> Mentors: [mailto:gcarvalho@cttc.es Gabriel Ferreira], [mailto:bbojovic@cttc.es Biljana Bojovic] and [mailto:kkoutlia@cttc.es Katerina Koutlia]<br /> <br /> Note: This could be proposed as either a small- or medium-sized project.<br /> <br /> The ns-3 5G nr module (aka 5G-LENA) is one of the most highly used and advanced ns-3 modules for simulating the 5G NR network. This project would be to improve the usability and examples of the 5G nr module by adding visualization tools to enrich the end-user experience.<br /> <br /> The main output will be the creation or porting of one (if small) or more examples from C++ to Python and adding visualization capabilities based on existing traces. The idea is that users can then see how the visualization was generated and better understand how the metrics collection works, and how changing parameters can affect simulation results. For this, the Jupyter notebook will be used, while Python scripts will be implemented for the visualization of the results. <br /> <br /> Examples to be implemented in Python:<br /> <br /> * An animated version of the REM map showing gNB beams moving along with a moving UE.<br /> * Resource allocation grid comparison for different resource schedulers.<br /> <br /> 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.<br /> 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].<br /> <br /> * Required Experience: C++ and Python programming, understanding of 5G NR, LTE, and wireless networks<br /> * Interests: 5G NR simulations<br /> * Difficulty: Medium.<br /> * 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.<br /> <br /> == Medium sized projects (175 hours) ==<br /> <br /> === ICMP socket and generate/handle ICMP messages (host/net unreachable) ===<br /> <br /> Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], [mailto:manoj24.rana@gmail.com Manoj K. Rana].<br /> <br /> 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 &quot;RAW&quot; socket.<br /> 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.<br /> <br /> 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.<br /> <br /> The most important point of the implementation should be code duplicate minimization, in order to have the minimize maintenance efforts.<br /> <br /> Once the sockets are in place, beside the &quot;normal&quot; tests, it will be necessary to modify the code that is actually made obsolete by the new sockets, e.g.:<br /> * IPv6 ICMP messages (RA, RS, NA, NS, etc.),<br /> * IPv4 ICMP messages,<br /> * ICMP Echo and ICMPv6 Echo messages.<br /> and to handle properly ICMP error messages like Destination Unreachable in the Ping application.<br /> <br /> * ''Required Experience:'' Fundamentals of IPv4 and IPv6 sockets, C++ programming.<br /> * ''Interests:'' Sockets and API interface implementation.<br /> * ''Difficulty:'' Medium.<br /> * ''Recommended reading:''<br /> ** [https://man7.org/linux/man-pages/man2/socket.2.html Linux socket]<br /> ** [https://courses.cs.vt.edu/cs4254/fall04/slides/raw_1.pdf Raw Sockets and ICMP, Srinidhi Varadarajan]<br /> ** [https://gitlab.com/nsnam/ns-3-dev/-/issues/810 Issue #810]<br /> <br /> Possible tasks to fulfill the patch requirement:<br /> * [[GSOC2024PatchRequirement]]<br /> <br /> === 6LoWPAN mesh-under routing enhancements ===<br /> <br /> Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], [TBD].<br /> <br /> 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.<br /> 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.<br /> <br /> The candidate should outline what parts of code are going to be affected, and how they can be enhanced thanks to RFC 7731.<br /> <br /> * ''Required Experience:'' Fundamentals of IPv6 addressing, C++ programming.<br /> * ''Bonus Experience:'' Familiarity with mesh routing and 6LoWPAN ns-3<br /> * ''Interests:'' IPv6 mesh routing<br /> * ''Difficulty:'' Easy.<br /> * ''Patch requirement:'' [[GSOC2024PatchRequirement]]<br /> * ''Recommended reading:''<br /> ** [https://www.nsnam.org/docs/models/html/sixlowpan.html#mesh-under-routing Mesh-under in ns-3 6LoWPAN]<br /> ** [https://datatracker.ietf.org/doc/html/rfc7731 RFC 7731]<br /> <br /> Possible tasks to fulfill the patch requirement:<br /> * TBD<br /> <br /> === 6LoWPAN neighbor discovery protocol ===<br /> <br /> Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], [TBD].<br /> <br /> 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.<br /> <br /> 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).<br /> <br /> 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.<br /> <br /> * ''Required Experience:'' Fundamentals of IPv6 addressing, C++ programming.<br /> * ''Bonus Experience:'' Familiarity with 6LoWPAN and 6LoWPAN-ND<br /> * ''Interests:'' IPv6 and IoT networks<br /> * ''Difficulty:'' Easy.<br /> * ''Patch requirement:'' [[GSOC2024PatchRequirement]]<br /> * ''Recommended reading:''<br /> ** [https://datatracker.ietf.org/doc/html/rfc8505 RFC 8505]<br /> ** [https://datatracker.ietf.org/doc/html/rfc6775 RFC 6775]<br /> ** [https://datatracker.ietf.org/doc/html/rfc4944 RFC 4944]<br /> <br /> Possible tasks to fulfil the patch requirement:<br /> * Patch the actual 6LoWPAN-ND to remove the limitation about concurrent address registrations.<br /> <br /> === Improving 5G NR module usability ===<br /> <br /> Mentors: [mailto:bbojovic@cttc.es Biljana Bojovic],[mailto:kkoutlia@cttc.es Katerina Koutlia] and [mailto:gcarvalho@cttc.es Gabriel Ferreira]<br /> <br /> Note: This could be proposed as either a medium- or large-sized project.<br /> <br /> The ns-3 5G nr module (aka 5G-LENA) is one of the most highly used and advanced ns-3 modules for simulating the 5G NR network. This project would be focused on improving the usability and examples of the 5G nr module. The project consists of the following: <br /> <br /> * Improving nr helpers support: The outcome would be the implementation of new helpers and the improvement of existing ones, with the final goal of easing the usage of the 5G nr module. For example, some helpers do not have Doxygen documentation, and others require more than 30 lines of code just to specify the required 3GPP scenario. Helpers could be focused on simplifying the setup of nr scenarios, for example, the internet, the 3GPP scenario, the XR applications, the management of the configuration of many parameters of the scenario, etc. The management of the configuration of many parameters could be simplified by moving all the common parameters to a common class that can be shared between multiple examples, then new example simulations could be much smaller and simpler. All the nr examples should be updated to make use of these new helpers.<br /> <br /> * A completely new example should be created that would be 3GPP compliant and ready for research purposes and collaborative research. The idea is that if a new user is interested in implementing some new MAC scheduler or PHY algorithms, can take this new example as it is and use it to run a simulation campaign for its research on a realistic 5G scenario that is according to a selected 3GPP reference scenario. We could even think of a set of different predefined 3GPP scenarios, e.g. indoor, outdoor, etc. So, the new 5G-LENA user would not have to waste his/her research time in creating a new example but could pick this example and use it as it is to test his/her algorithm. Such examples would allow collaborative research because the users could reference such examples in their publications, and compare these results with the results with other researchers' algorithms.<br /> <br /> * As a final step, to validate the correct configuration through the helpers, it would be useful to have an easy way to generate plots of indicative performance metrics, such as the throughput and/or the delay (other metrics are also welcomed). For this purpose, some plotting scripts should be added to the examples folder. <br /> <br /> * Additionally, creating an “integration” example could be defined as the final part of the project, in the case of applying for a large project. The integration example is the example that demonstrates to nr users how to combine the nr module with another ns-3 module. See ns-3 Appstore here: https://apps.nsnam.org/app/tag/all/). Alternatively, integration with some external research tools could be proposed. For example, the interesting scenarios would involve the integration example that considers some of the following:<br /> ** NetSimulyzer (https://apps.nsnam.org/app/netsimulyzer/),<br /> ** Ns-3 gym (https://apps.nsnam.org/app/ns3-gym/) <br /> ** NYSIM (https://apps.nsnam.org/app/nyusim/)<br /> <br /> 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.<br /> For more specific guidelines, please view this [https://docs.google.com/document/d/1cQLIF1cdft1yj3vyWrjrxN2xDJMx8PuWaa9NP_nKf64/edit?usp=sharing Google document].<br /> <br /> * Required Experience: C++ programming, understanding of 5G NR, LTE, and wireless networks<br /> * Interests: 5G NR simulations<br /> * Difficulty: Medium.<br /> * 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.<br /> <br /> === Improving 5G NR module visualizations ===<br /> <br /> Mentors: [mailto:gcarvalho@cttc.es Gabriel Ferreira], [mailto:bbojovic@cttc.es Biljana Bojovic] and [mailto:kkoutlia@cttc.es Katerina Koutlia]<br /> <br /> Note: This could be proposed as either a small- or medium-sized project.<br /> <br /> The ns-3 5G nr module (aka 5G-LENA) is one of the most highly used and advanced ns-3 modules for simulating the 5G NR network. This project would be to improve the usability and examples of the 5G nr module by adding visualization tools to enrich the end-user experience.<br /> <br /> The main output will be the creation or porting of one (if small) or more examples from C++ to Python and adding visualization capabilities based on existing traces. The idea is that users can then see how the visualization was generated and better understand how the metrics collection works, and how changing parameters can affect simulation results. For this, the Jupyter notebook will be used, while Python scripts will be implemented for the visualization of the results. <br /> <br /> Examples to be implemented in Python:<br /> <br /> * An animated version of the REM map showing gNB beams moving along with a moving UE.<br /> * Resource allocation grid comparison for different resource schedulers.<br /> <br /> 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.<br /> 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].<br /> <br /> * Required Experience: C++ and Python programming, understanding of 5G NR, LTE, and wireless networks<br /> * Interests: 5G NR simulations<br /> * Difficulty: Medium.<br /> * 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.<br /> <br /> === 5G NR module benchmark analysis for different channel models ===<br /> <br /> Mentors:[mailto:aashtari@cttc.es Amir Ashtari Gargari], <br /> [mailto:bbojovic@cttc.es Biljana Bojovic] and [mailto:gcarvalho@cttc.es Gabriel Ferreira]<br /> <br /> Note: This could be proposed as either a medium- or large-sized project.<br /> The ns-3 5G nr module (aka 5G-LENA) is one of the most highly used and advanced ns-3 modules for simulating the 5G NR network. This project would be focused on improving the usability and examples of the 5G nr module. <br /> <br /> The ns-3 nr module should be able to make use of different channel models, however, all the currently available examples in the nr module use the ns-3 3GPP channel model. This project should extend the nr module to allow the configuration of additional channel models, such as TwoRaySpectrumPropagationLoss, and NYSim, and create a benchmark example that would allow switching among different channel models. The project should consist of the following steps:<br /> <br /> * TwoRaySpectrumPropagationLossModel was developed by Matteo Pagin during GSoC 2022: https://www.nsnam.org/wiki/GSOC2022Channel, with a main goal to provide an alternative channel model to ns-3 3GPP channel model that would be less computationally expensive and thus be a good choice for the large-scale 5G NR simulation. Matteo Pagin developed during his GSoC an NR example that uses this model, this example should be ported to the NR module. To allow the configuration of this model Matteo Pagin extended the NrHelper to allow that configuration. Such changes should be ported also to the NR module and used as an example of how to extend the NrHelper to allow the configuration of the NYSim channel model.<br /> <br /> * Additionally, the student should investigate what are the API changes that should be done in the NR module, mainly NrHelper, to allow the usage of the NYSim channel model. As an example, see how the mmWave module makes use of both 3GPP and NYSim channel models: https://apps.nsnam.org/app/mmwave/. Also, see the NYSim module in the ns-3 App Store:https://apps.nsnam.org/app/nyusim/. See also an additional description in the [https://docs.google.com/document/d/1cQLIF1cdft1yj3vyWrjrxN2xDJMx8PuWaa9NP_nKf64/edit?usp=sharing Google document].<br /> <br /> * Finally, a common benchmark scenario example that can make use of these three channel models should be created and used to perform the profiling study. An example could be the extension of Matteo's example or a completely new example. Additionally, the performance evaluation analysis of the NR should be done for the three models, and provide some insights into the assessed differences. <br /> <br /> * If during the performance analysis, the student detects the performance bottlenecks in the simulator that could be improved, the project could be extended to be a large-sized project.<br /> <br /> The project proposal should contain a refactoring plan and should list what changes will be made to the NR module to support the use of the TwoRaySpectrumPropagationLossModel and NYSim channel model. The project plan should also contain some idea of what scenario will be used for the performance evaluation, which frequency, outdoor or indoor, and the number of gNBs and UEs that will be profiled. The project plan should also include a description of the performance analysis with a target performance indicative metrics. There will be benchmark metrics related to the speed of the execution of the simulator, and also the NR performance metrics such as throughput and delay. The project plan should well define the development steps that would result in the often MRs toward the nr module and ns-3 upstream during the whole duration of the project. <br /> <br /> 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.<br /> <br /> For more specific guidelines, please view this [https://docs.google.com/document/d/1cQLIF1cdft1yj3vyWrjrxN2xDJMx8PuWaa9NP_nKf64/edit?usp=sharing Google document].<br /> *Required Experience: C++ programming, understanding of 5G NR, LTE, and wireless networks<br /> *Interests: 5G NR simulations<br /> *Difficulty: Medium-High.<br /> *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.<br /> <br /> == Large projects (350 hours) ==<br /> <br /> === IPv6 global routing ===<br /> <br /> Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], [TBD].<br /> <br /> 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).<br /> For IPv4, ns-3 provides two alternatives: GlobalRouting, and NixRouting, which just &quot;do the trick&quot; - they simply fill the routing tables in intermediate nodes, GlobalRouting using an approach similar to OSPF, NixRouting by leveraging the &quot;abstract&quot; knowledge of the network.<br /> Neither actually use any message between the nodes, so they also reduce the network overhead - something that is useful in many cases.<br /> <br /> 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.).<br /> <br /> 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.<br /> <br /> * ''Required Experience:'' Fundamentals of IPv6 addressing, C++ programming.<br /> * ''Bonus Experience:'' Familiarity with GlobalRouting implementations in ns-3<br /> * ''Interests:'' IPv6 routing<br /> * ''Difficulty:'' Medium.<br /> * ''Patch requirement:'' [[GSOC2024PatchRequirement]]<br /> * ''Recommended reading:''<br /> ** [https://www.nsnam.org/docs/models/html/ipv6.html IPv6 model in ns-3]<br /> ** [https://www.nsnam.org/docs/models/html/routing-overview.html#global-centralized-routing GlobalRouting model in ns-3]<br /> <br /> Possible tasks to fulfill the patch requirement:<br /> * 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.<br /> <br /> === AODVv2 Protocol enhancements ===<br /> <br /> Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], [TBD].<br /> <br /> 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.<br /> <br /> In particular the project should address the following points: 1) AODVv2 performances, 2) AODV address compression, 3) &quot;external&quot; network routing support, 4) general model validation against the latest draft.<br /> Collaboration with the draft authors is also highly suggested.<br /> <br /> * ''Required Experience:'' Fundamentals of IPv6 addressing, C++ programming.<br /> * ''Bonus Experience:'' Familiarity with AODV implementations in ns-3 and AODVv2<br /> * ''Interests:'' Ad hoc routing<br /> * ''Difficulty:'' Medium.<br /> * ''Patch requirement:'' [[GSOC2024PatchRequirement]]<br /> * ''Recommended reading:''<br /> ** [https://www.nsnam.org/docs/models/html/ipv6.html IPv6 model in ns-3]<br /> ** [https://www.nsnam.org/docs/models/html/aodv.html AODV model in ns-3]<br /> ** [https://datatracker.ietf.org/doc/draft-perkins-manet-aodvv2/05/ Ad Hoc On-demand Distance Vector Version 2 (AODVv2) Routing]<br /> <br /> Possible tasks to fulfill the patch requirement:<br /> * [https://gitlab.com/nsnam/ns-3-dev/-/issues/368 Issue #368] - aodv: aodv parameters can be set to &quot;impossible&quot; values<br /> <br /> === Mesh Link Establishment (MLE) protocol ===<br /> <br /> Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], TBD.<br /> <br /> 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.<br /> However, MLE is being used in Thread, and it can be useful to implement it.<br /> <br /> 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.<br /> <br /> * ''Required Experience:'' Fundamentals of IPv4 and IPv6 sockets, C++ programming.<br /> * ''Interests:'' Sockets and API interface implementation.<br /> * ''Difficulty:'' Hard.<br /> * ''Recommended reading:''<br /> ** [https://datatracker.ietf.org/doc/html/draft-ietf-6lo-mesh-link-establishment MLE draft]<br /> ** [https://openthread.io/guides/thread-primer/network-discovery Thread primer]<br /> ** [https://www.threadgroup.org/ThreadSpec Thread specifications]<br /> <br /> Possible tasks to fulfill the patch requirement:<br /> * [[GSOC2024PatchRequirement]]<br /> <br /> === Lr-WPAN (IEEE 802.15.4) preamble detection support ===<br /> <br /> Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], [mailto:alramonet@is.tokushima-u.ac.jp Alberto Gallegos Ramonet].<br /> <br /> 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<br /> 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<br /> itself has many added benefits.<br /> <br /> 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.<br /> <br /> As usual, reduction of code duplicity and a flexible scalable design is desired (e.g. Allow the inclusion of different preambles in the future).<br /> <br /> * ''Required Experience:'' Basic understanding of IEEE 802.15.4, C++ programming.<br /> * ''Bonus Experience:'' PHY process familiarity, Familiarity with ns-3's Lr-WPAN<br /> * ''Interests:'' Lr-WPAN, MAC and PHY designs<br /> * ''Difficulty:'' Medium.<br /> * ''Patch requirement:'' [[GSOC2024PatchRequirement]]<br /> * ''Recommended reading:''<br /> ** [https://ieeexplore.ieee.org/document/1700009 IEEE 802.15.4-2006]<br /> ** [https://ieeexplore.ieee.org/document/7460875 IEEE 802.15.4-2015]<br /> ** [https://www.nsnam.org/docs/models/html/lr-wpan.html ns-3 lr-wpan module]<br /> <br /> Possible tasks to fulfill the patch requirement:<br /> * [[GSOC2024PatchRequirement]]</div>

Tommaso https://www.nsnam.org/mediawiki/index.php?title=GSOC2025Projects&diff=13373 2025-02-08T14:07:06Z

<p>Tommaso: /* IPv6 support in Ad hoc Routing Protocols */</p> <hr /> <div>{{TOC}}<br /> <br /> This page contains 2025 Google Summer of Code project ideas for ns-3.<br /> <br /> * [https://developers.google.com/open-source/gsoc/faq GSoC Frequently Asked Questions]<br /> * [[GSOC2024ContributorGuide |ns-3's 2024 GSoC Contributor guide]]<br /> * [https://developers.google.com/open-source/gsoc/resources/guide GSoC contributor/student guide (not ns-3 specific)]<br /> * [[GSOC2024ApplicationTemplate |2024 GSoC Contributor application template]]<br /> * [[GSOCMentorGuide | ns-3's GSoC Mentor guide]]<br /> * [https://archive.flossmanuals.net/gsocmentoring/index.html GSoC Mentor guide (not ns-3 specific)]<br /> * [[GSOCSelectionProcess | GSoC Contributor Selection Process]]<br /> * ''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/<br /> <br /> === About the ns-3 project ===<br /> <br /> ns-3 is a discrete-event network simulator, with a particular emphasis on network research and education.<br /> <br /> 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.<br /> <br /> 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.<br /> <br /> === Org admins ===<br /> <br /> 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].<br /> <br /> === Mentors ===<br /> <br /> 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.<br /> <br /> The current list of prospective mentors can be found among the ideas listed below.<br /> <br /> === How to apply ===<br /> <br /> For students or contributors interested in applying to ns-3 for GSoC, please go through the following list to get started:<br /> * Read the official [https://developers.google.com/open-source/gsoc/resources/guide GSoC contributor guide].<br /> * Read [[GSOC2024ContributorGuide |ns-3's GSoC contributor guide]]<br /> * Look through our [[#Project Ideas]] below to see if you find a project that interests you.<br /> * Review the [https://www.nsnam.org/documentation/development-tree/ tutorial and contributing guide] thoroughly, if you have not already done so.<br /> * 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.<br /> * Next, proceed to get in touch with the developers on the mailing list or Zulip chat room and refine your proposal.<br /> * 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.<br /> <br /> 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.<br /> <br /> &lt;blockquote&gt;<br /> Each project idea within a particular priority has been tagged with the following properties:<br /> * ''Required Experience:'' Languages, concepts, or packages with which applicants must be familiar.<br /> * ''Bonus Experience:'' Other experience or familiarity which would be greatly helpful to applicants for this project.<br /> * ''Interests:'' Areas of particular relevance to this project, and an indicator of where successful contributors might apply their experiences coming out of this project.<br /> * ''Difficulty:'' easy, medium or difficult<br /> * ''Recommended reading:'' pointers to documentation, papers, specific bugs, etc.<br /> <br /> 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.<br /> &lt;/blockquote&gt;<br /> <br /> === Patch requirement guidelines ===<br /> <br /> 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.<br /> <br /> 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.<br /> <br /> === Mentors: how to participate ===<br /> <br /> 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:<br /> <br /> * 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.<br /> * 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.<br /> * 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.<br /> <br /> == Project Ideas ==<br /> <br /> '''Note to contributors:''' These ideas are not listed in any priority order.<br /> 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.<br /> <br /> === Internet models enhancements ===<br /> <br /> * [[#ICMP socket and generate/handle ICMP messages (host/net unreachable)]] (medium size project, 175h)<br /> * [[#IPv6 global routing]] (large size project, 350h)<br /> * [[#DHCPv6 (DHCP for IPv6)]] (medium size project, 175h)<br /> * [[#IPv6 support in Ad hoc Routing Protocols]] (large size project, 350h)<br /> <br /> === IoT models enhancements ===<br /> <br /> * [[#6LoWPAN mesh-under routing enhancements]] (medium size project, 175h)<br /> * [[#6LoWPAN neighbor discovery protocol]] (medium size project, 175h)<br /> * [[#Mesh Link Establishment (MLE) protocol ]] (large size project, 350h)<br /> * [[#Lr-WPAN (IEEE 802.15.4) preamble detection support]] (large size project, 350h)<br /> <br /> === 5G NR models enhancements ===<br /> <br /> * [[#Improving 5G NR module usability]] (medium size project, 90h)<br /> * [[#Improving 5G NR module visualizations]] (medium size project, 175h)<br /> * [[#5G NR module benchmark analysis for different channel models]] (medium size project, 175h)<br /> <br /> == Small sized projects (90 hours) ==<br /> <br /> ===== Improving 5G NR module visualizations =====<br /> <br /> Mentors: [mailto:gcarvalho@cttc.es Gabriel Ferreira], [mailto:bbojovic@cttc.es Biljana Bojovic] and [mailto:kkoutlia@cttc.es Katerina Koutlia]<br /> <br /> Note: This could be proposed as either a small- or medium-sized project.<br /> <br /> The ns-3 5G nr module (aka 5G-LENA) is one of the most highly used and advanced ns-3 modules for simulating the 5G NR network. This project would be to improve the usability and examples of the 5G nr module by adding visualization tools to enrich the end-user experience.<br /> <br /> The main output will be the creation or porting of one (if small) or more examples from C++ to Python and adding visualization capabilities based on existing traces. The idea is that users can then see how the visualization was generated and better understand how the metrics collection works, and how changing parameters can affect simulation results. For this, the Jupyter notebook will be used, while Python scripts will be implemented for the visualization of the results. <br /> <br /> Examples to be implemented in Python:<br /> <br /> * An animated version of the REM map showing gNB beams moving along with a moving UE.<br /> * Resource allocation grid comparison for different resource schedulers.<br /> <br /> 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.<br /> 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].<br /> <br /> * Required Experience: C++ and Python programming, understanding of 5G NR, LTE, and wireless networks<br /> * Interests: 5G NR simulations<br /> * Difficulty: Medium.<br /> * 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.<br /> <br /> == Medium sized projects (175 hours) ==<br /> <br /> === ICMP socket and generate/handle ICMP messages (host/net unreachable) ===<br /> <br /> Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], [mailto:manoj24.rana@gmail.com Manoj K. Rana].<br /> <br /> 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 &quot;RAW&quot; socket.<br /> 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.<br /> <br /> 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.<br /> <br /> The most important point of the implementation should be code duplicate minimization, in order to have the minimize maintenance efforts.<br /> <br /> Once the sockets are in place, beside the &quot;normal&quot; tests, it will be necessary to modify the code that is actually made obsolete by the new sockets, e.g.:<br /> * IPv6 ICMP messages (RA, RS, NA, NS, etc.),<br /> * IPv4 ICMP messages,<br /> * ICMP Echo and ICMPv6 Echo messages.<br /> and to handle properly ICMP error messages like Destination Unreachable in the Ping application.<br /> <br /> * ''Required Experience:'' Fundamentals of IPv4 and IPv6 sockets, C++ programming.<br /> * ''Interests:'' Sockets and API interface implementation.<br /> * ''Difficulty:'' Medium.<br /> * ''Recommended reading:''<br /> ** [https://man7.org/linux/man-pages/man2/socket.2.html Linux socket]<br /> ** [https://courses.cs.vt.edu/cs4254/fall04/slides/raw_1.pdf Raw Sockets and ICMP, Srinidhi Varadarajan]<br /> ** [https://gitlab.com/nsnam/ns-3-dev/-/issues/810 Issue #810]<br /> <br /> Possible tasks to fulfill the patch requirement:<br /> * [[GSOC2024PatchRequirement]]<br /> <br /> === 6LoWPAN mesh-under routing enhancements ===<br /> <br /> Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], [TBD].<br /> <br /> 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.<br /> 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.<br /> <br /> The candidate should outline what parts of code are going to be affected, and how they can be enhanced thanks to RFC 7731.<br /> <br /> * ''Required Experience:'' Fundamentals of IPv6 addressing, C++ programming.<br /> * ''Bonus Experience:'' Familiarity with mesh routing and 6LoWPAN ns-3<br /> * ''Interests:'' IPv6 mesh routing<br /> * ''Difficulty:'' Easy.<br /> * ''Patch requirement:'' [[GSOC2024PatchRequirement]]<br /> * ''Recommended reading:''<br /> ** [https://www.nsnam.org/docs/models/html/sixlowpan.html#mesh-under-routing Mesh-under in ns-3 6LoWPAN]<br /> ** [https://datatracker.ietf.org/doc/html/rfc7731 RFC 7731]<br /> <br /> Possible tasks to fulfill the patch requirement:<br /> * TBD<br /> <br /> === 6LoWPAN neighbor discovery protocol ===<br /> <br /> Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], [TBD].<br /> <br /> 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.<br /> <br /> 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).<br /> <br /> 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.<br /> <br /> * ''Required Experience:'' Fundamentals of IPv6 addressing, C++ programming.<br /> * ''Bonus Experience:'' Familiarity with 6LoWPAN and 6LoWPAN-ND<br /> * ''Interests:'' IPv6 and IoT networks<br /> * ''Difficulty:'' Easy.<br /> * ''Patch requirement:'' [[GSOC2024PatchRequirement]]<br /> * ''Recommended reading:''<br /> ** [https://datatracker.ietf.org/doc/html/rfc8505 RFC 8505]<br /> ** [https://datatracker.ietf.org/doc/html/rfc6775 RFC 6775]<br /> ** [https://datatracker.ietf.org/doc/html/rfc4944 RFC 4944]<br /> <br /> Possible tasks to fulfil the patch requirement:<br /> * Patch the actual 6LoWPAN-ND to remove the limitation about concurrent address registrations.<br /> <br /> === Improving 5G NR module usability ===<br /> <br /> Mentors: [mailto:bbojovic@cttc.es Biljana Bojovic],[mailto:kkoutlia@cttc.es Katerina Koutlia] and [mailto:gcarvalho@cttc.es Gabriel Ferreira]<br /> <br /> Note: This could be proposed as either a medium- or large-sized project.<br /> <br /> The ns-3 5G nr module (aka 5G-LENA) is one of the most highly used and advanced ns-3 modules for simulating the 5G NR network. This project would be focused on improving the usability and examples of the 5G nr module. The project consists of the following: <br /> <br /> * Improving nr helpers support: The outcome would be the implementation of new helpers and the improvement of existing ones, with the final goal of easing the usage of the 5G nr module. For example, some helpers do not have Doxygen documentation, and others require more than 30 lines of code just to specify the required 3GPP scenario. Helpers could be focused on simplifying the setup of nr scenarios, for example, the internet, the 3GPP scenario, the XR applications, the management of the configuration of many parameters of the scenario, etc. The management of the configuration of many parameters could be simplified by moving all the common parameters to a common class that can be shared between multiple examples, then new example simulations could be much smaller and simpler. All the nr examples should be updated to make use of these new helpers.<br /> <br /> * A completely new example should be created that would be 3GPP compliant and ready for research purposes and collaborative research. The idea is that if a new user is interested in implementing some new MAC scheduler or PHY algorithms, can take this new example as it is and use it to run a simulation campaign for its research on a realistic 5G scenario that is according to a selected 3GPP reference scenario. We could even think of a set of different predefined 3GPP scenarios, e.g. indoor, outdoor, etc. So, the new 5G-LENA user would not have to waste his/her research time in creating a new example but could pick this example and use it as it is to test his/her algorithm. Such examples would allow collaborative research because the users could reference such examples in their publications, and compare these results with the results with other researchers' algorithms.<br /> <br /> * As a final step, to validate the correct configuration through the helpers, it would be useful to have an easy way to generate plots of indicative performance metrics, such as the throughput and/or the delay (other metrics are also welcomed). For this purpose, some plotting scripts should be added to the examples folder. <br /> <br /> * Additionally, creating an “integration” example could be defined as the final part of the project, in the case of applying for a large project. The integration example is the example that demonstrates to nr users how to combine the nr module with another ns-3 module. See ns-3 Appstore here: https://apps.nsnam.org/app/tag/all/). Alternatively, integration with some external research tools could be proposed. For example, the interesting scenarios would involve the integration example that considers some of the following:<br /> ** NetSimulyzer (https://apps.nsnam.org/app/netsimulyzer/),<br /> ** Ns-3 gym (https://apps.nsnam.org/app/ns3-gym/) <br /> ** NYSIM (https://apps.nsnam.org/app/nyusim/)<br /> <br /> 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.<br /> For more specific guidelines, please view this [https://docs.google.com/document/d/1cQLIF1cdft1yj3vyWrjrxN2xDJMx8PuWaa9NP_nKf64/edit?usp=sharing Google document].<br /> <br /> * Required Experience: C++ programming, understanding of 5G NR, LTE, and wireless networks<br /> * Interests: 5G NR simulations<br /> * Difficulty: Medium.<br /> * 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.<br /> <br /> === Improving 5G NR module visualizations ===<br /> <br /> Mentors: [mailto:gcarvalho@cttc.es Gabriel Ferreira], [mailto:bbojovic@cttc.es Biljana Bojovic] and [mailto:kkoutlia@cttc.es Katerina Koutlia]<br /> <br /> Note: This could be proposed as either a small- or medium-sized project.<br /> <br /> The ns-3 5G nr module (aka 5G-LENA) is one of the most highly used and advanced ns-3 modules for simulating the 5G NR network. This project would be to improve the usability and examples of the 5G nr module by adding visualization tools to enrich the end-user experience.<br /> <br /> The main output will be the creation or porting of one (if small) or more examples from C++ to Python and adding visualization capabilities based on existing traces. The idea is that users can then see how the visualization was generated and better understand how the metrics collection works, and how changing parameters can affect simulation results. For this, the Jupyter notebook will be used, while Python scripts will be implemented for the visualization of the results. <br /> <br /> Examples to be implemented in Python:<br /> <br /> * An animated version of the REM map showing gNB beams moving along with a moving UE.<br /> * Resource allocation grid comparison for different resource schedulers.<br /> <br /> 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.<br /> 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].<br /> <br /> * Required Experience: C++ and Python programming, understanding of 5G NR, LTE, and wireless networks<br /> * Interests: 5G NR simulations<br /> * Difficulty: Medium.<br /> * 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.<br /> <br /> === 5G NR module benchmark analysis for different channel models ===<br /> <br /> Mentors:[mailto:aashtari@cttc.es Amir Ashtari Gargari], <br /> [mailto:bbojovic@cttc.es Biljana Bojovic] and [mailto:gcarvalho@cttc.es Gabriel Ferreira]<br /> <br /> Note: This could be proposed as either a medium- or large-sized project.<br /> The ns-3 5G nr module (aka 5G-LENA) is one of the most highly used and advanced ns-3 modules for simulating the 5G NR network. This project would be focused on improving the usability and examples of the 5G nr module. <br /> <br /> The ns-3 nr module should be able to make use of different channel models, however, all the currently available examples in the nr module use the ns-3 3GPP channel model. This project should extend the nr module to allow the configuration of additional channel models, such as TwoRaySpectrumPropagationLoss, and NYSim, and create a benchmark example that would allow switching among different channel models. The project should consist of the following steps:<br /> <br /> * TwoRaySpectrumPropagationLossModel was developed by Matteo Pagin during GSoC 2022: https://www.nsnam.org/wiki/GSOC2022Channel, with a main goal to provide an alternative channel model to ns-3 3GPP channel model that would be less computationally expensive and thus be a good choice for the large-scale 5G NR simulation. Matteo Pagin developed during his GSoC an NR example that uses this model, this example should be ported to the NR module. To allow the configuration of this model Matteo Pagin extended the NrHelper to allow that configuration. Such changes should be ported also to the NR module and used as an example of how to extend the NrHelper to allow the configuration of the NYSim channel model.<br /> <br /> * Additionally, the student should investigate what are the API changes that should be done in the NR module, mainly NrHelper, to allow the usage of the NYSim channel model. As an example, see how the mmWave module makes use of both 3GPP and NYSim channel models: https://apps.nsnam.org/app/mmwave/. Also, see the NYSim module in the ns-3 App Store:https://apps.nsnam.org/app/nyusim/. See also an additional description in the [https://docs.google.com/document/d/1cQLIF1cdft1yj3vyWrjrxN2xDJMx8PuWaa9NP_nKf64/edit?usp=sharing Google document].<br /> <br /> * Finally, a common benchmark scenario example that can make use of these three channel models should be created and used to perform the profiling study. An example could be the extension of Matteo's example or a completely new example. Additionally, the performance evaluation analysis of the NR should be done for the three models, and provide some insights into the assessed differences. <br /> <br /> * If during the performance analysis, the student detects the performance bottlenecks in the simulator that could be improved, the project could be extended to be a large-sized project.<br /> <br /> The project proposal should contain a refactoring plan and should list what changes will be made to the NR module to support the use of the TwoRaySpectrumPropagationLossModel and NYSim channel model. The project plan should also contain some idea of what scenario will be used for the performance evaluation, which frequency, outdoor or indoor, and the number of gNBs and UEs that will be profiled. The project plan should also include a description of the performance analysis with a target performance indicative metrics. There will be benchmark metrics related to the speed of the execution of the simulator, and also the NR performance metrics such as throughput and delay. The project plan should well define the development steps that would result in the often MRs toward the nr module and ns-3 upstream during the whole duration of the project. <br /> <br /> 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.<br /> <br /> For more specific guidelines, please view this [https://docs.google.com/document/d/1cQLIF1cdft1yj3vyWrjrxN2xDJMx8PuWaa9NP_nKf64/edit?usp=sharing Google document].<br /> *Required Experience: C++ programming, understanding of 5G NR, LTE, and wireless networks<br /> *Interests: 5G NR simulations<br /> *Difficulty: Medium-High.<br /> *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.<br /> <br /> == Large projects (350 hours) ==<br /> <br /> === IPv6 global routing ===<br /> <br /> Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], [TBD].<br /> <br /> 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).<br /> For IPv4, ns-3 provides two alternatives: GlobalRouting, and NixRouting, which just &quot;do the trick&quot; - they simply fill the routing tables in intermediate nodes, GlobalRouting using an approach similar to OSPF, NixRouting by leveraging the &quot;abstract&quot; knowledge of the network.<br /> Neither actually use any message between the nodes, so they also reduce the network overhead - something that is useful in many cases.<br /> <br /> 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.).<br /> <br /> 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.<br /> <br /> * ''Required Experience:'' Fundamentals of IPv6 addressing, C++ programming.<br /> * ''Bonus Experience:'' Familiarity with GlobalRouting implementations in ns-3<br /> * ''Interests:'' IPv6 routing<br /> * ''Difficulty:'' Medium.<br /> * ''Patch requirement:'' [[GSOC2024PatchRequirement]]<br /> * ''Recommended reading:''<br /> ** [https://www.nsnam.org/docs/models/html/ipv6.html IPv6 model in ns-3]<br /> ** [https://www.nsnam.org/docs/models/html/routing-overview.html#global-centralized-routing GlobalRouting model in ns-3]<br /> <br /> Possible tasks to fulfill the patch requirement:<br /> * 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.<br /> <br /> === AODVv2 Protocol enhancements ===<br /> <br /> Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], [TBD].<br /> <br /> 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.<br /> <br /> In particular the project should address the following points: 1) AODVv2 performances, 2) AODV address compression, 3) &quot;external&quot; network routing support, 4) general model validation against the latest draft.<br /> Collaboration with the draft authors is also highly suggested.<br /> <br /> * ''Required Experience:'' Fundamentals of IPv6 addressing, C++ programming.<br /> * ''Bonus Experience:'' Familiarity with AODV implementations in ns-3 and AODVv2<br /> * ''Interests:'' Ad hoc routing<br /> * ''Difficulty:'' Medium.<br /> * ''Patch requirement:'' [[GSOC2024PatchRequirement]]<br /> * ''Recommended reading:''<br /> ** [https://www.nsnam.org/docs/models/html/ipv6.html IPv6 model in ns-3]<br /> ** [https://www.nsnam.org/docs/models/html/aodv.html AODV model in ns-3]<br /> ** [https://datatracker.ietf.org/doc/draft-perkins-manet-aodvv2/05/ Ad Hoc On-demand Distance Vector Version 2 (AODVv2) Routing]<br /> <br /> Possible tasks to fulfill the patch requirement:<br /> * [https://gitlab.com/nsnam/ns-3-dev/-/issues/368 Issue #368] - aodv: aodv parameters can be set to &quot;impossible&quot; values<br /> <br /> === Mesh Link Establishment (MLE) protocol ===<br /> <br /> Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], TBD.<br /> <br /> 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.<br /> However, MLE is being used in Thread, and it can be useful to implement it.<br /> <br /> 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.<br /> <br /> * ''Required Experience:'' Fundamentals of IPv4 and IPv6 sockets, C++ programming.<br /> * ''Interests:'' Sockets and API interface implementation.<br /> * ''Difficulty:'' Hard.<br /> * ''Recommended reading:''<br /> ** [https://datatracker.ietf.org/doc/html/draft-ietf-6lo-mesh-link-establishment MLE draft]<br /> ** [https://openthread.io/guides/thread-primer/network-discovery Thread primer]<br /> ** [https://www.threadgroup.org/ThreadSpec Thread specifications]<br /> <br /> Possible tasks to fulfill the patch requirement:<br /> * [[GSOC2024PatchRequirement]]<br /> <br /> === Lr-WPAN (IEEE 802.15.4) preamble detection support ===<br /> <br /> Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], [mailto:alramonet@is.tokushima-u.ac.jp Alberto Gallegos Ramonet].<br /> <br /> 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<br /> 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<br /> itself has many added benefits.<br /> <br /> 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.<br /> <br /> As usual, reduction of code duplicity and a flexible scalable design is desired (e.g. Allow the inclusion of different preambles in the future).<br /> <br /> * ''Required Experience:'' Basic understanding of IEEE 802.15.4, C++ programming.<br /> * ''Bonus Experience:'' PHY process familiarity, Familiarity with ns-3's Lr-WPAN<br /> * ''Interests:'' Lr-WPAN, MAC and PHY designs<br /> * ''Difficulty:'' Medium.<br /> * ''Patch requirement:'' [[GSOC2024PatchRequirement]]<br /> * ''Recommended reading:''<br /> ** [https://ieeexplore.ieee.org/document/1700009 IEEE 802.15.4-2006]<br /> ** [https://ieeexplore.ieee.org/document/7460875 IEEE 802.15.4-2015]<br /> ** [https://www.nsnam.org/docs/models/html/lr-wpan.html ns-3 lr-wpan module]<br /> <br /> Possible tasks to fulfill the patch requirement:<br /> * [[GSOC2024PatchRequirement]]</div>

Tommaso https://www.nsnam.org/mediawiki/index.php?title=Summer_Projects&diff=13372 2025-02-06T08:11:52Z

<p>Tommaso: /* Google Summer of Code 2025 */</p> <hr /> <div>{{TOC}}<br /> <br /> The project coordinates a few summer coding programs in which student developers are paired with mentors to produce code over the summer.<br /> <br /> = Google Summer of Code 2025 =<br /> <br /> The ns-3 project plans to apply to become a mentoring organization for 2025. We are determining who is interested and available to mentor, and then prospective mentors will post some project ideas before the 11 February application deadline. Please note that the student application and project ideas list will likely change from what it was in 2024. If you are interested to get started, the best way for the time being is to read the [https://www.nsnam.org/docs/contributing/html/index.html project contributing guide] and start to interact with maintainers in the issue/merge request trackers or on Zulip chat.<br /> <br /> * [[GSOC2025Projects | Project Ideas Page]]<br /> * [[GSOC2024ContributorGuide | ns-3's GSoC Contributor Guide]]<br /> <br /> = Google Summer of Code 2024 =<br /> <br /> The organizational admins were Tommaso Pecorella, Mohit Tahiliani, and Tom Henderson.<br /> <br /> We had three successful student projects, summarized on the pages linked below:<br /> <br /> * '''Joao Albuquerque''', [[GSOC2024Channels5G | 5G NR Module Benchmark and Analysis for Distinct Channel Models]], mentored by Biljana Bojovic, Amir Ashtari, and Gabriel Ferreira: '''''[[GSOC2024Channels5GFinalReport | Final report]]'''''<br /> * '''Kavya Bhat''', [[GSOC2024DHCPv6 | DHCPv6]], mentored by Tommaso Pecorella, Alberto Gallegos Ramonet, and Manoj Kumar Rana: '''''[[GSOC2024DHCPv6FinalReport | Final report]]'''''<br /> * '''Hyerin Kim''', [[GSOC2024RLUsability5G | Enhancement of RL Approach Accessibility in NR]], mentored by Katerina Koutlia, Amir Ashtari, Biljana Bojovic, and Gabriel Ferreira: '''''[[GSOC2024RLUsability5GFinalReport | Final report]]'''''<br /> <br /> * [[GSOC2024Projects | Project Ideas Page]]<br /> * [[GSOC2024ContributorGuide | ns-3's GSoC Contributor Guide]]<br /> <br /> = Google Summer of Code 2023 =<br /> <br /> The organizational admins were Tommaso Pecorella, Mohit Tahiliani, and Tom Henderson.<br /> <br /> We had three successful student projects for 2023; you can read their final reports below:<br /> <br /> * '''Giovanni Grieco''', [[GSOC20235GUsability | IUNS-3 5G NR: Improving the Usability of ns-3's 5G NR Module]], mentored by Tom Henderson, Katerina Koutlia, and Biljana Bojovic: '''''[[GSOC20235GUsabilityFinalReport | Final report]]'''''<br /> * '''Raghuram Kannan''', [[GSOC2023NetAnim | Dynamic device registration for NetAnim simulation animations]], mentored by Tommaso Pecorella and Manoj Kumar Rana: '''''[[GSOC2023NetAnimFinalReport | Final report]]'''''<br /> * '''Muyuan Shen''', [[GSOC2023ns3-ai | ns3-ai enhancements]], mentored by Collin Brady and Hao Yin: '''''[[GSOC2023ns3-aiFinalReport | Final report]]'''''<br /> <br /> We reviewed seven proposals, which were evaluated by a committee that includes most of the mentors listed on the Project Ideas page. For future reference, below is our ideas page and contributor's guide.<br /> <br /> * [[GSOC2023Projects | Project Ideas Page]]<br /> * [[GSOC2023ContributorGuide | ns-3's GSoC Contributor Guide]]<br /> <br /> = Google Summer of Code 2022 =<br /> <br /> The organizational admins were Tommaso Pecorella, Mohit Tahiliani, and Tom Henderson.<br /> <br /> Two contributors completed projects with ns-3 in the 2022 Google Summer of Code.<br /> <br /> * '''Matteo Pagin''', [[GSOC2022Channel | A simplified channel and beamforming model for ns-3]], mentored by Sandra Lagen, Biljana Bojovic, and Michele Polese '''''[https://pagmatt.github.io/blog/2022/gsoc2022 Final Report]'''''<br /> * '''Zhiheng Dong''', [[GSOC2022PerfectArp | Perfect ARP and NDP]], mentored by Tommaso Pecorella, Ameya Deshpande,and Manoj Kumar Rana '''''[[GSOC2022NeighborCacheFinalReport | Final Report]]'''''<br /> <br /> One additional project was started but did not progress past the midterm evaluation:<br /> <br /> * '''Akash Mondal''', [[GSOC2022TCPMaximumSegmentSize | TCP maximum segment size (MSS) improvements]], mentored by Mohit Tahiliani, Bhaskar Kataria, and Vivek Jain<br /> <br /> We received seven proposals, which were evaluated by a committee that includes most of the mentors listed on the Project Ideas page. For future reference, below is our ideas page and contributor's guide.<br /> <br /> * [[GSOC2022Projects | Project Ideas Page]]<br /> * [[GSOC2022ContributorGuide | ns-3's GSoC Contributor Guide]]<br /> <br /> = ns-3 Summer of Code 2022 =<br /> <br /> ns-3 Summer of Code (NSoC) is a program that runs in parallel to Google Summer of Code. Unlike GSoC, it is not funded, but we aim to operate it similarly to GSoC. <br /> <br /> * '''Chandrakant Jena,''' ''Ping and Ping6 Enhancements for ns-3:'' '''''[[NSOC2022Ping | project wiki page ]]''''' mentored by Tommaso Pecorella and Tom Henderson<br /> <br /> The project by Chandrakant was completed successfully in December 2022, with six commits made to ns-3-dev starting with [https://gitlab.com/nsnam/ns-3-dev/-/commit/da107e04eeb0c12631eadda6a30ad1a33b7f0931 commit da107e04]. The project added a '''[https://www.nsnam.org/docs/doxygen/d6/dbe/classns3_1_1_ping.html new Ping application]''', helper class, example program, unit test, and [https://www.nsnam.org/docs/models/html/internet-apps.html#ping documentation].<br /> <br /> = Google Summer of Code 2021 =<br /> <br /> Three students successfully completed projects in [https://summerofcode.withgoogle.com/organizations/4672908493848576/ Google Summer of Code 2021].<br /> <br /> * '''Parth Pratim Chatterjee,''' ''Direct Code Execution Modernization:'' '''''[[GSOC2021DCE | project wiki page]]''''' '''--''' '''''[https://ns-3-dce-linux-upgrade.github.io/ Final report]'''''<br /> * '''Ameya Deshpande,''' ''IPv6 Nix-Vector Routing:'' '''''[[GSOC2021NixVector | project wiki page]]''''' '''--''' '''''[https://www.nsnam.org/wiki/GSOC2021NixVectorFinalReport Final report]'''''<br /> * '''Akshit Patel,''' ''Add logging support to Simulation Execution Manager (SEM):'' '''''[[GSOC2021SEM | project wiki page]]''''' '''--''' '''''[https://akshitpatel01.github.io/GSoC-2021-Report/ Final report]'''''<br /> <br /> For reference, below were the 2021 project ideas and the 2021 student guide:<br /> <br /> * [[GSOC2021StudentGuide | Student Guide]]<br /> * [[GSOC2021Projects | Project Ideas Page]]<br /> <br /> = ns-3 Summer of Code 2021 =<br /> <br /> ns-3 Summer of Code (NSoC) is a program that runs in parallel to Google Summer of Code. Unlike GSoC, it is not funded, but we aim to operate it similarly to GSoC. The commitments are similar; students and mentors are expected to define and work towards a mergeable project goal by the end of the summer. The program is offered to 'honorable mention' GSoC proposals (i.e., proposals that we would have selected had we received more student slots from Google) and for other reasons such as a contributor's ineligibility for GSoC.<br /> <br /> * '''Nitya Chandra,''' ''Enable IPv6 support for ad-hoc routing protocols in ns-3:'' '''''[[NSOC2021Ipv6 | project wiki page ]]''''' '''Note: project did not complete'''<br /> <br /> = Google Summer of Code 2020 =<br /> <br /> Four students successfully completed [https://summerofcode.withgoogle.com/ Google Summer of Code 2020] projects:<br /> <br /> * '''Shivamani Patil,''' ''App Store Improvements:'' '''''[https://shivamanipatil.github.io/gsoc-2020-report/ final report], [[GSOC2020AppStore | project wiki page]]'''''<br /> * '''Ananthakrishan S,''' ''NetDevice up/down consistency and event chain:'' '''''[https://ananthu-dev.github.io/net-device-consistency-gsoc-2020/ final report], [[GSOC2020NetDevice | project wiki page]]'''''<br /> * '''Bhaskar Kataria,''' ''SCE AQMs and TCP along with CNQ-CodelAF and LFQ'' '''''[https://bhaskar792.github.io/GSoC-2020-Report/ final report], [[GSOC2020AQM | project wiki page]]'''''<br /> * '''Deepak K,''' ''TCP Prague model for ns-3'', '''''[https://deepakkavoor.github.io/gsoc-2020-prague/ final report], [[GSOC2020Prague | project wiki page]]'''''<br /> <br /> For reference, below were the 2020 project ideas and the 2020 student guide:<br /> <br /> * [[GSOC2020StudentGuide | Student Guide]]<br /> * [[GSOC2020Projects | Project Ideas Page]]<br /> <br /> = ns-3 Summer of Code 2020 =<br /> <br /> These projects are unfunded but are mentored in a manner similar to GSoC, at a lesser pace than the 12-week GSoC program.<br /> <br /> * Muhammad Iqbal Rochman, [[NSOC2020WifiPHY | Wi-Fi PHY Restructure]] '''Note:''' This project successfully completed.<br /> * Harsha Sharma, [[NSOC2020L4SEvaluation | L4S evaluation framework]] '''Note:''' This project continued through fall 2020 but did not yet merge.<br /> * Rahul Bothra, [[NSOC2020Routing | Routing for community wireless networks]] '''Note:''' Project discontinued in August 2020.<br /> <br /> = Google Summer of Code 2019 =<br /> <br /> ns-3 participated in Google Summer of Code 2019 with four student projects:<br /> <br /> * Apoorva Bhargava, [[GSOC2019TCPTestingAndAlignment | Testing and Alignment of ns-3 TCP with Linux TCP]]<br /> * Mishal Shah, [[GSOC2019AppStore | Improving the ns-3 AppStore and linking with bake]]<br /> * Tommaso Zugno, [[GSOC2019ThreeGPPChannel | Integration of the 3GPP TR 38.901 channel model in the ns-3 spectrum module]]<br /> * Liangcheng Yu, [[GSOC2019DCN | Framework of Studying Flow Completion Time Minimization for Data Center Networks in ns-3]]<br /> <br /> Below are project ideas and the 2019 student guide:<br /> <br /> * [[GSOC2019StudentGuide | ns-3 GSoC student guide]]<br /> * [[GSOC2019Projects | Project Ideas Page]]<br /> <br /> = European Space Agency Summer of Code in Space (SOCIS) 2019 =<br /> <br /> ns-3 ultimately was not selected for funding for SOCIS 2019. Below is an archive of our student guide, for future reference.<br /> <br /> * [[SOCIS2019 | ns-3 SOCIS student guide]]<br /> <br /> = Google Summer of Code 2018 =<br /> <br /> ns-3 participated in the 2018 edition of Google Summer of Code, with five students:<br /> <br /> * WenYing Dai, [[GSOC2018AccECN_ECN++ | Implementation of AccECN and ECN++ in ns-3]]<br /> * Muhammad Iqbal CR, [[GSOC2018Coexistence | Merging and Improvement of LTE and Wi-Fi Coexistence Module]]<br /> * Sourabh Jain, [[GSoC2018_DCE_Upgrade | Direct Code Execution upgrade]]<br /> * Davide Magrin, [[GSoC2018:_A_Simulation_Execution_Manager_for_ns-3 | A simulation execution manager for ns-3]]<br /> * Jude Niroshan, [[GSoC2018:Trust-based_routing_protocols_framework | Trust-based routing protocols framework]]<br /> <br /> * [[GSOC2018Projects | Project Ideas Page]]<br /> * [[GSOC2018StudentGuide | Student Application Guide]]<br /> <br /> = European Space Agency Summer of Code in Space (SOCIS) 2017 =<br /> <br /> ns-3 has been accepted to the 2017 ESA Summer of Code in Space, with student Pasquale Imputato (mentored by Tommaso Pecorella). The project successfully completed in October 2017 (details in the below wiki project page).<br /> <br /> * [[SOCIS2017 | project page]]<br /> * [https://codereview.appspot.com/330220043/ Final code review]<br /> <br /> The original project ideas page is posted below.<br /> <br /> * [[SOCIS2017Projects#Project_Ideas | Project Ideas page]]<br /> <br /> = Google Summer of Code 2017 =<br /> <br /> ns-3 was fortunate to mentor five outstanding students for the 2017 edition of [https://developers.google.com/open-source/gsoc/ Google Summer of Code].<br /> <br /> * [[GSOC2017AcceptedProjects | Accepted Projects]]<br /> == Final reports ==<br /> * [http://mailman.isi.edu/pipermail/ns-developers/2017-August/013916.html ns-3 App Store] by Abhijith Anilkumar<br /> * [https://www.nsnam.org/wiki/GSOC2017Lte#Project_summary Enabling LTE CA handover to secondary cell] by Alexander Krotov<br /> * [http://mailman.isi.edu/pipermail/ns-developers/2017-September/013929.html TCP Prague] by Shravya Ks<br /> * [http://mailman.isi.edu/pipermail/ns-developers/2017-September/013918.html LTE and IPv6 support] by Manoj Kumar Rana<br /> * [http://mailman.isi.edu/pipermail/ns-developers/2017-September/013921.html TBF and HHF] by Surya Seetharaman<br /> <br /> == Phase 2 reports ==<br /> * [http://mailman.isi.edu/pipermail/ns-developers/2017-July/014038.html BCube and FatTree topology helpers (component of TCP Prague project)]<br /> * [http://mailman.isi.edu/pipermail/ns-developers/2017-August/014054.html Implementation of TBF and HHF]<br /> * [http://mailman.isi.edu/pipermail/ns-developers/2017-July/014047.html Enabling LTE CA handover to secondary cell, Phase 2]<br /> * [http://mailman.isi.edu/pipermail/ns-developers/2017-July/014042.html ns-3 App Store]<br /> * [http://mailman.isi.edu/pipermail/ns-developers/2017-July/014049.html Mobile IPv6 implementation with LTE support (report)]<br /> * [http://mailman.isi.edu/pipermail/ns-developers/2017-August/014058.html Mobile IPv6 implementation with LTE support (review request)]<br /> == Phase 1 reports ==<br /> * [http://mailman.isi.edu/pipermail/ns-developers/2017-June/013980.html Data Center TCP (component of TCP Prague project)]<br /> * [http://mailman.isi.edu/pipermail/ns-developers/2017-June/013982.html Implementation of TBF and HHF traffic control]<br /> * [http://mailman.isi.edu/pipermail/ns-developers/2017-June/013983.html Enabling LTE CA handover to secondary cell, Phase 1]<br /> * [http://mailman.isi.edu/pipermail/ns-developers/2017-June/013985.html ns-3 App Store]<br /> * [http://mailman.isi.edu/pipermail/ns-developers/2017-June/013987.html Mobile IPv6 implementation with LTE support]<br /> == Background ==<br /> Below is some information that was used during the application phase.<br /> <br /> * [[GSOC2017Projects | Project Ideas Page]]<br /> * [[GSOC2017StudentGuide | Student Application Guide]]<br /> <br /> = European Space Agency Summer of Code in Space (SOCIS) 2016 =<br /> <br /> ns-3 had one student (Michael Di Perna) successfully complete the 2016 [http://sophia.estec.esa.int/socis/ ESA Summer of Code in Space]. <br /> <br /> * [[SOCIS2016 | Project page]] for Optical Satellite Systems project<br /> * [[SOCIS2016Projects#Project_Ideas | Project Ideas page]]<br /> <br /> = Mentored summer projects 2016 =<br /> <br /> ns-3 maintainers will mentor additional summer projects (that students will work on using their own sources of funding) on a best-effort basis. Students interested in this option should review the GSoC or SOCIS ideas page, or propose their own.<br /> <br /> * See [[MentoredProjects2016]]<br /> <br /> = Google Summer of Code 2016 =<br /> <br /> ns-3 was not selected for the 2016 [https://developers.google.com/open-source/gsoc/ Google Summer of Code]. We mentored two summer projects outside of GSoC. Below were our materials prepared for our GSoC organizational application.<br /> * [[GSOC2016Projects | Project ideas page]]<br /> * [[GSOCStudentGuide | Student guide]]<br /> <br /> = Google Summer of Code 2015 =<br /> <br /> ns-3 was selected to participate in the 2015 [http://www.google-melange.com/gsoc/homepage/google/gsoc2015 Google Summer of Code]. More information can be found on our Project Ideas page and our Student Guide.<br /> <br /> * [[GSOC2015AcceptedProjects | Accepted projects]]<br /> * [[GSOC2015Projects | Project ideas page]]<br /> * [[GSOC2015StudentGuide | Student guide]]<br /> <br /> This year's students were announced on April 27, and all four successfully completed the program:<br /> <br /> * Melchiorre Danilo Abrignani, [[GSOC2015LTECA | Carrier Aggregation support for the LTE module]]<br /> * Matthieu Coudron, [[GSOC2015MpTcpImplementation | Implementing multipath TCP (MPTCP) in ns3]]<br /> * Natale Patriciello, [[GSOC2015TCPTest | TCP layer refactoring with automated test on RFC compliance and validation]]<br /> * Vishwesh Rege, [[GSOC2015LrWpanMac | 802.15.4 realistic MAC and Energy Model]]<br /> <br /> = European Space Agency Summer of Code in Space (SOCIS) 2015 =<br /> <br /> ns-3 has been accepted to the 2015 [http://sophia.estec.esa.int/socis2015/ ESA Summer of Code in Space]. The ns-3 project had one student in SOCIS in each of 2013, 2014 and 2015. However, the satellite channel models project for 2015 [[SOCIS2015 | Satellite channel models]] did not successfully complete.<br /> <br /> * [[SOCIS2015Projects | Project ideas page]] (for reference)<br /> <br /> = Mentored summer projects =<br /> <br /> ns-3 maintainers will mentor additional summer projects (that students will work on using their own sources of funding) on a best-effort basis. Students interested in this option should review the GSoC or SOCIS ideas page, or propose their own.<br /> <br /> We have one such mentored project in 2015:<br /> <br /> * Saswat Mishra, [[NeighborDiscoveryProject | Neighbor Discovery enhancements]]<br /> <br /> = Past summer projects =<br /> <br /> * [[GSOC2014AcceptedProjects | GSoC 2014 Accepted Projects]]<br /> * [[SOCIS2014TCP | SOCIS 2014 Accepted Project]]<br /> * [[MentoredProjects2014 | 2014 Mentored Projects]]<br /> * [[SOCIS2013BundleProtocolProject | SOCIS 2013 Accepted Project]]<br /> * [[GSOC2013AcceptedProjects | GSoC 2013 Accepted Projects]]<br /> * [[GSOC2012AcceptedProjects |GSoC 2012 Accepted Projects]]<br /> * [[NSOC2011AcceptedProjects |NSoC 2011 Accepted Projects]]<br /> * [[GSOC2010AcceptedProjects |GSoC 2010 Accepted Projects]]<br /> * [[GSOC2009AcceptedProjects |GSoC 2009 Accepted Projects]]<br /> * [https://developers.google.com/open-source/soc/2008/?csw=1#ns3 GSoC 2008 Accepted Projects]</div>

Tommaso https://www.nsnam.org/mediawiki/index.php?title=GSOC2025Projects&diff=13371 2025-02-05T16:16:26Z

<p>Tommaso: /* DHCPv6 (DHCP for IPv6) */</p> <hr /> <div>{{TOC}}<br /> <br /> This page contains 2025 Google Summer of Code project ideas for ns-3.<br /> <br /> * [https://developers.google.com/open-source/gsoc/faq GSoC Frequently Asked Questions]<br /> * [[GSOC2024ContributorGuide |ns-3's 2024 GSoC Contributor guide]]<br /> * [https://developers.google.com/open-source/gsoc/resources/guide GSoC contributor/student guide (not ns-3 specific)]<br /> * [[GSOC2024ApplicationTemplate |2024 GSoC Contributor application template]]<br /> * [[GSOCMentorGuide | ns-3's GSoC Mentor guide]]<br /> * [https://archive.flossmanuals.net/gsocmentoring/index.html GSoC Mentor guide (not ns-3 specific)]<br /> * [[GSOCSelectionProcess | GSoC Contributor Selection Process]]<br /> * ''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/<br /> <br /> === About the ns-3 project ===<br /> <br /> ns-3 is a discrete-event network simulator, with a particular emphasis on network research and education.<br /> <br /> 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.<br /> <br /> 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.<br /> <br /> === Org admins ===<br /> <br /> 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].<br /> <br /> === Mentors ===<br /> <br /> 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.<br /> <br /> The current list of prospective mentors can be found among the ideas listed below.<br /> <br /> === How to apply ===<br /> <br /> For students or contributors interested in applying to ns-3 for GSoC, please go through the following list to get started:<br /> * Read the official [https://developers.google.com/open-source/gsoc/resources/guide GSoC contributor guide].<br /> * Read [[GSOC2024ContributorGuide |ns-3's GSoC contributor guide]]<br /> * Look through our [[#Project Ideas]] below to see if you find a project that interests you.<br /> * Review the [https://www.nsnam.org/documentation/development-tree/ tutorial and contributing guide] thoroughly, if you have not already done so.<br /> * 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.<br /> * Next, proceed to get in touch with the developers on the mailing list or Zulip chat room and refine your proposal.<br /> * 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.<br /> <br /> 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.<br /> <br /> &lt;blockquote&gt;<br /> Each project idea within a particular priority has been tagged with the following properties:<br /> * ''Required Experience:'' Languages, concepts, or packages with which applicants must be familiar.<br /> * ''Bonus Experience:'' Other experience or familiarity which would be greatly helpful to applicants for this project.<br /> * ''Interests:'' Areas of particular relevance to this project, and an indicator of where successful contributors might apply their experiences coming out of this project.<br /> * ''Difficulty:'' easy, medium or difficult<br /> * ''Recommended reading:'' pointers to documentation, papers, specific bugs, etc.<br /> <br /> 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.<br /> &lt;/blockquote&gt;<br /> <br /> === Patch requirement guidelines ===<br /> <br /> 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.<br /> <br /> 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.<br /> <br /> === Mentors: how to participate ===<br /> <br /> 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:<br /> <br /> * 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.<br /> * 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.<br /> * 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.<br /> <br /> == Project Ideas ==<br /> <br /> '''Note to contributors:''' These ideas are not listed in any priority order.<br /> 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.<br /> <br /> === Internet models enhancements ===<br /> <br /> * [[#ICMP socket and generate/handle ICMP messages (host/net unreachable)]] (medium size project, 175h)<br /> * [[#IPv6 global routing]] (large size project, 350h)<br /> * [[#DHCPv6 (DHCP for IPv6)]] (medium size project, 175h)<br /> * [[#IPv6 support in Ad hoc Routing Protocols]] (large size project, 350h)<br /> <br /> === IoT models enhancements ===<br /> <br /> * [[#6LoWPAN mesh-under routing enhancements]] (medium size project, 175h)<br /> * [[#6LoWPAN neighbor discovery protocol]] (medium size project, 175h)<br /> * [[#Mesh Link Establishment (MLE) protocol ]] (large size project, 350h)<br /> * [[#Lr-WPAN (IEEE 802.15.4) preamble detection support]] (large size project, 350h)<br /> <br /> === 5G NR models enhancements ===<br /> <br /> * [[#Improving 5G NR module usability]] (medium size project, 90h)<br /> * [[#Improving 5G NR module visualizations]] (medium size project, 175h)<br /> * [[#5G NR module benchmark analysis for different channel models]] (medium size project, 175h)<br /> <br /> == Small sized projects (90 hours) ==<br /> <br /> ===== Improving 5G NR module visualizations =====<br /> <br /> Mentors: [mailto:gcarvalho@cttc.es Gabriel Ferreira], [mailto:bbojovic@cttc.es Biljana Bojovic] and [mailto:kkoutlia@cttc.es Katerina Koutlia]<br /> <br /> Note: This could be proposed as either a small- or medium-sized project.<br /> <br /> The ns-3 5G nr module (aka 5G-LENA) is one of the most highly used and advanced ns-3 modules for simulating the 5G NR network. This project would be to improve the usability and examples of the 5G nr module by adding visualization tools to enrich the end-user experience.<br /> <br /> The main output will be the creation or porting of one (if small) or more examples from C++ to Python and adding visualization capabilities based on existing traces. The idea is that users can then see how the visualization was generated and better understand how the metrics collection works, and how changing parameters can affect simulation results. For this, the Jupyter notebook will be used, while Python scripts will be implemented for the visualization of the results. <br /> <br /> Examples to be implemented in Python:<br /> <br /> * An animated version of the REM map showing gNB beams moving along with a moving UE.<br /> * Resource allocation grid comparison for different resource schedulers.<br /> <br /> 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.<br /> 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].<br /> <br /> * Required Experience: C++ and Python programming, understanding of 5G NR, LTE, and wireless networks<br /> * Interests: 5G NR simulations<br /> * Difficulty: Medium.<br /> * 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.<br /> <br /> == Medium sized projects (175 hours) ==<br /> <br /> === ICMP socket and generate/handle ICMP messages (host/net unreachable) ===<br /> <br /> Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], [mailto:manoj24.rana@gmail.com Manoj K. Rana].<br /> <br /> 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 &quot;RAW&quot; socket.<br /> 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.<br /> <br /> 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.<br /> <br /> The most important point of the implementation should be code duplicate minimization, in order to have the minimize maintenance efforts.<br /> <br /> Once the sockets are in place, beside the &quot;normal&quot; tests, it will be necessary to modify the code that is actually made obsolete by the new sockets, e.g.:<br /> * IPv6 ICMP messages (RA, RS, NA, NS, etc.),<br /> * IPv4 ICMP messages,<br /> * ICMP Echo and ICMPv6 Echo messages.<br /> and to handle properly ICMP error messages like Destination Unreachable in the Ping application.<br /> <br /> * ''Required Experience:'' Fundamentals of IPv4 and IPv6 sockets, C++ programming.<br /> * ''Interests:'' Sockets and API interface implementation.<br /> * ''Difficulty:'' Medium.<br /> * ''Recommended reading:''<br /> ** [https://man7.org/linux/man-pages/man2/socket.2.html Linux socket]<br /> ** [https://courses.cs.vt.edu/cs4254/fall04/slides/raw_1.pdf Raw Sockets and ICMP, Srinidhi Varadarajan]<br /> ** [https://gitlab.com/nsnam/ns-3-dev/-/issues/810 Issue #810]<br /> <br /> Possible tasks to fulfill the patch requirement:<br /> * [[GSOC2024PatchRequirement]]<br /> <br /> === 6LoWPAN mesh-under routing enhancements ===<br /> <br /> Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], [TBD].<br /> <br /> 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.<br /> 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.<br /> <br /> The candidate should outline what parts of code are going to be affected, and how they can be enhanced thanks to RFC 7731.<br /> <br /> * ''Required Experience:'' Fundamentals of IPv6 addressing, C++ programming.<br /> * ''Bonus Experience:'' Familiarity with mesh routing and 6LoWPAN ns-3<br /> * ''Interests:'' IPv6 mesh routing<br /> * ''Difficulty:'' Easy.<br /> * ''Patch requirement:'' [[GSOC2024PatchRequirement]]<br /> * ''Recommended reading:''<br /> ** [https://www.nsnam.org/docs/models/html/sixlowpan.html#mesh-under-routing Mesh-under in ns-3 6LoWPAN]<br /> ** [https://datatracker.ietf.org/doc/html/rfc7731 RFC 7731]<br /> <br /> Possible tasks to fulfill the patch requirement:<br /> * TBD<br /> <br /> === 6LoWPAN neighbor discovery protocol ===<br /> <br /> Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], [TBD].<br /> <br /> 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.<br /> <br /> 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).<br /> <br /> 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.<br /> <br /> * ''Required Experience:'' Fundamentals of IPv6 addressing, C++ programming.<br /> * ''Bonus Experience:'' Familiarity with 6LoWPAN and 6LoWPAN-ND<br /> * ''Interests:'' IPv6 and IoT networks<br /> * ''Difficulty:'' Easy.<br /> * ''Patch requirement:'' [[GSOC2024PatchRequirement]]<br /> * ''Recommended reading:''<br /> ** [https://datatracker.ietf.org/doc/html/rfc8505 RFC 8505]<br /> ** [https://datatracker.ietf.org/doc/html/rfc6775 RFC 6775]<br /> ** [https://datatracker.ietf.org/doc/html/rfc4944 RFC 4944]<br /> <br /> Possible tasks to fulfil the patch requirement:<br /> * Patch the actual 6LoWPAN-ND to remove the limitation about concurrent address registrations.<br /> <br /> === Improving 5G NR module usability ===<br /> <br /> Mentors: [mailto:bbojovic@cttc.es Biljana Bojovic],[mailto:kkoutlia@cttc.es Katerina Koutlia] and [mailto:gcarvalho@cttc.es Gabriel Ferreira]<br /> <br /> Note: This could be proposed as either a medium- or large-sized project.<br /> <br /> The ns-3 5G nr module (aka 5G-LENA) is one of the most highly used and advanced ns-3 modules for simulating the 5G NR network. This project would be focused on improving the usability and examples of the 5G nr module. The project consists of the following: <br /> <br /> * Improving nr helpers support: The outcome would be the implementation of new helpers and the improvement of existing ones, with the final goal of easing the usage of the 5G nr module. For example, some helpers do not have Doxygen documentation, and others require more than 30 lines of code just to specify the required 3GPP scenario. Helpers could be focused on simplifying the setup of nr scenarios, for example, the internet, the 3GPP scenario, the XR applications, the management of the configuration of many parameters of the scenario, etc. The management of the configuration of many parameters could be simplified by moving all the common parameters to a common class that can be shared between multiple examples, then new example simulations could be much smaller and simpler. All the nr examples should be updated to make use of these new helpers.<br /> <br /> * A completely new example should be created that would be 3GPP compliant and ready for research purposes and collaborative research. The idea is that if a new user is interested in implementing some new MAC scheduler or PHY algorithms, can take this new example as it is and use it to run a simulation campaign for its research on a realistic 5G scenario that is according to a selected 3GPP reference scenario. We could even think of a set of different predefined 3GPP scenarios, e.g. indoor, outdoor, etc. So, the new 5G-LENA user would not have to waste his/her research time in creating a new example but could pick this example and use it as it is to test his/her algorithm. Such examples would allow collaborative research because the users could reference such examples in their publications, and compare these results with the results with other researchers' algorithms.<br /> <br /> * As a final step, to validate the correct configuration through the helpers, it would be useful to have an easy way to generate plots of indicative performance metrics, such as the throughput and/or the delay (other metrics are also welcomed). For this purpose, some plotting scripts should be added to the examples folder. <br /> <br /> * Additionally, creating an “integration” example could be defined as the final part of the project, in the case of applying for a large project. The integration example is the example that demonstrates to nr users how to combine the nr module with another ns-3 module. See ns-3 Appstore here: https://apps.nsnam.org/app/tag/all/). Alternatively, integration with some external research tools could be proposed. For example, the interesting scenarios would involve the integration example that considers some of the following:<br /> ** NetSimulyzer (https://apps.nsnam.org/app/netsimulyzer/),<br /> ** Ns-3 gym (https://apps.nsnam.org/app/ns3-gym/) <br /> ** NYSIM (https://apps.nsnam.org/app/nyusim/)<br /> <br /> 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.<br /> For more specific guidelines, please view this [https://docs.google.com/document/d/1cQLIF1cdft1yj3vyWrjrxN2xDJMx8PuWaa9NP_nKf64/edit?usp=sharing Google document].<br /> <br /> * Required Experience: C++ programming, understanding of 5G NR, LTE, and wireless networks<br /> * Interests: 5G NR simulations<br /> * Difficulty: Medium.<br /> * 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.<br /> <br /> === Improving 5G NR module visualizations ===<br /> <br /> Mentors: [mailto:gcarvalho@cttc.es Gabriel Ferreira], [mailto:bbojovic@cttc.es Biljana Bojovic] and [mailto:kkoutlia@cttc.es Katerina Koutlia]<br /> <br /> Note: This could be proposed as either a small- or medium-sized project.<br /> <br /> The ns-3 5G nr module (aka 5G-LENA) is one of the most highly used and advanced ns-3 modules for simulating the 5G NR network. This project would be to improve the usability and examples of the 5G nr module by adding visualization tools to enrich the end-user experience.<br /> <br /> The main output will be the creation or porting of one (if small) or more examples from C++ to Python and adding visualization capabilities based on existing traces. The idea is that users can then see how the visualization was generated and better understand how the metrics collection works, and how changing parameters can affect simulation results. For this, the Jupyter notebook will be used, while Python scripts will be implemented for the visualization of the results. <br /> <br /> Examples to be implemented in Python:<br /> <br /> * An animated version of the REM map showing gNB beams moving along with a moving UE.<br /> * Resource allocation grid comparison for different resource schedulers.<br /> <br /> 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.<br /> 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].<br /> <br /> * Required Experience: C++ and Python programming, understanding of 5G NR, LTE, and wireless networks<br /> * Interests: 5G NR simulations<br /> * Difficulty: Medium.<br /> * 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.<br /> <br /> === 5G NR module benchmark analysis for different channel models ===<br /> <br /> Mentors:[mailto:aashtari@cttc.es Amir Ashtari Gargari], <br /> [mailto:bbojovic@cttc.es Biljana Bojovic] and [mailto:gcarvalho@cttc.es Gabriel Ferreira]<br /> <br /> Note: This could be proposed as either a medium- or large-sized project.<br /> The ns-3 5G nr module (aka 5G-LENA) is one of the most highly used and advanced ns-3 modules for simulating the 5G NR network. This project would be focused on improving the usability and examples of the 5G nr module. <br /> <br /> The ns-3 nr module should be able to make use of different channel models, however, all the currently available examples in the nr module use the ns-3 3GPP channel model. This project should extend the nr module to allow the configuration of additional channel models, such as TwoRaySpectrumPropagationLoss, and NYSim, and create a benchmark example that would allow switching among different channel models. The project should consist of the following steps:<br /> <br /> * TwoRaySpectrumPropagationLossModel was developed by Matteo Pagin during GSoC 2022: https://www.nsnam.org/wiki/GSOC2022Channel, with a main goal to provide an alternative channel model to ns-3 3GPP channel model that would be less computationally expensive and thus be a good choice for the large-scale 5G NR simulation. Matteo Pagin developed during his GSoC an NR example that uses this model, this example should be ported to the NR module. To allow the configuration of this model Matteo Pagin extended the NrHelper to allow that configuration. Such changes should be ported also to the NR module and used as an example of how to extend the NrHelper to allow the configuration of the NYSim channel model.<br /> <br /> * Additionally, the student should investigate what are the API changes that should be done in the NR module, mainly NrHelper, to allow the usage of the NYSim channel model. As an example, see how the mmWave module makes use of both 3GPP and NYSim channel models: https://apps.nsnam.org/app/mmwave/. Also, see the NYSim module in the ns-3 App Store:https://apps.nsnam.org/app/nyusim/. See also an additional description in the [https://docs.google.com/document/d/1cQLIF1cdft1yj3vyWrjrxN2xDJMx8PuWaa9NP_nKf64/edit?usp=sharing Google document].<br /> <br /> * Finally, a common benchmark scenario example that can make use of these three channel models should be created and used to perform the profiling study. An example could be the extension of Matteo's example or a completely new example. Additionally, the performance evaluation analysis of the NR should be done for the three models, and provide some insights into the assessed differences. <br /> <br /> * If during the performance analysis, the student detects the performance bottlenecks in the simulator that could be improved, the project could be extended to be a large-sized project.<br /> <br /> The project proposal should contain a refactoring plan and should list what changes will be made to the NR module to support the use of the TwoRaySpectrumPropagationLossModel and NYSim channel model. The project plan should also contain some idea of what scenario will be used for the performance evaluation, which frequency, outdoor or indoor, and the number of gNBs and UEs that will be profiled. The project plan should also include a description of the performance analysis with a target performance indicative metrics. There will be benchmark metrics related to the speed of the execution of the simulator, and also the NR performance metrics such as throughput and delay. The project plan should well define the development steps that would result in the often MRs toward the nr module and ns-3 upstream during the whole duration of the project. <br /> <br /> 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.<br /> <br /> For more specific guidelines, please view this [https://docs.google.com/document/d/1cQLIF1cdft1yj3vyWrjrxN2xDJMx8PuWaa9NP_nKf64/edit?usp=sharing Google document].<br /> *Required Experience: C++ programming, understanding of 5G NR, LTE, and wireless networks<br /> *Interests: 5G NR simulations<br /> *Difficulty: Medium-High.<br /> *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.<br /> <br /> == Large projects (350 hours) ==<br /> <br /> === IPv6 global routing ===<br /> <br /> Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], [TBD].<br /> <br /> 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).<br /> For IPv4, ns-3 provides two alternatives: GlobalRouting, and NixRouting, which just &quot;do the trick&quot; - they simply fill the routing tables in intermediate nodes, GlobalRouting using an approach similar to OSPF, NixRouting by leveraging the &quot;abstract&quot; knowledge of the network.<br /> Neither actually use any message between the nodes, so they also reduce the network overhead - something that is useful in many cases.<br /> <br /> 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.).<br /> <br /> 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.<br /> <br /> * ''Required Experience:'' Fundamentals of IPv6 addressing, C++ programming.<br /> * ''Bonus Experience:'' Familiarity with GlobalRouting implementations in ns-3<br /> * ''Interests:'' IPv6 routing<br /> * ''Difficulty:'' Medium.<br /> * ''Patch requirement:'' [[GSOC2024PatchRequirement]]<br /> * ''Recommended reading:''<br /> ** [https://www.nsnam.org/docs/models/html/ipv6.html IPv6 model in ns-3]<br /> ** [https://www.nsnam.org/docs/models/html/routing-overview.html#global-centralized-routing GlobalRouting model in ns-3]<br /> <br /> Possible tasks to fulfill the patch requirement:<br /> * 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.<br /> <br /> === IPv6 support in Ad hoc Routing Protocols ===<br /> <br /> Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], [TBD].<br /> <br /> ns-3 contains models for proactive (DSDV and OLSR) and reactive (AODV and DSR) ad hoc routing protocols. However, these models are IPv4-only and do not provide support of IPv6 addressing. This project aims to enable IPv6 support for ad hoc routing protocols in ns-3, mainly for AODV. There are out-of-tree implementations of OLSR and DSDV that provide support for IPv6 addressing, and can be used as references to get started with this project.<br /> <br /> The most important point of the implementation should be code duplicate minimization, in order to have the minimize maintenance efforts.<br /> <br /> Note: Enabling IPv6 support for these protocols is not a matter of simply changing out an IPv4-formatted address for an IPv6-formatted address. The IPv6 addressing architecture emphasizes scoping much more than does IPv4 (RFC 4007). Please suggest in your application how IPv6 address configuration (and possibly auto-configuration?) and address scopes (e.g. link-local vs. global) should be used in these protocols. Consulting the RFCs is highly recommended.<br /> <br /> * ''Required Experience:'' Fundamentals of IPv6 addressing, C++ programming.<br /> * ''Bonus Experience:'' Familiarity with AODV implementations in ns-3<br /> * ''Interests:'' Ad hoc routing<br /> * ''Difficulty:'' Medium.<br /> * ''Patch requirement:'' [[GSOC2024PatchRequirement]]<br /> * ''Recommended reading:''<br /> ** [https://www.nsnam.org/docs/models/html/ipv6.html IPv6 model in ns-3]<br /> ** [https://www.nsnam.org/docs/models/html/aodv.html AODV model in ns-3]<br /> ** [https://www.nsnam.org/workshops/wns3-2016/posters/IPv6-support-for-OLSR.pdf IPv6 Support for OLSR in ns-3]<br /> <br /> Possible tasks to fulfill the patch requirement:<br /> * [https://gitlab.com/nsnam/ns-3-dev/-/issues/271 Issue #271] - olsr header and messages are not printing either their size or their content.<br /> * [https://gitlab.com/nsnam/ns-3-dev/-/issues/368 Issue #368] - aodv: aodv parameters can be set to &quot;impossible&quot; values<br /> <br /> === Mesh Link Establishment (MLE) protocol ===<br /> <br /> Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], TBD.<br /> <br /> 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.<br /> However, MLE is being used in Thread, and it can be useful to implement it.<br /> <br /> 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.<br /> <br /> * ''Required Experience:'' Fundamentals of IPv4 and IPv6 sockets, C++ programming.<br /> * ''Interests:'' Sockets and API interface implementation.<br /> * ''Difficulty:'' Hard.<br /> * ''Recommended reading:''<br /> ** [https://datatracker.ietf.org/doc/html/draft-ietf-6lo-mesh-link-establishment MLE draft]<br /> ** [https://openthread.io/guides/thread-primer/network-discovery Thread primer]<br /> ** [https://www.threadgroup.org/ThreadSpec Thread specifications]<br /> <br /> Possible tasks to fulfill the patch requirement:<br /> * [[GSOC2024PatchRequirement]]<br /> <br /> === Lr-WPAN (IEEE 802.15.4) preamble detection support ===<br /> <br /> Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], [mailto:alramonet@is.tokushima-u.ac.jp Alberto Gallegos Ramonet].<br /> <br /> 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<br /> 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<br /> itself has many added benefits.<br /> <br /> 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.<br /> <br /> As usual, reduction of code duplicity and a flexible scalable design is desired (e.g. Allow the inclusion of different preambles in the future).<br /> <br /> * ''Required Experience:'' Basic understanding of IEEE 802.15.4, C++ programming.<br /> * ''Bonus Experience:'' PHY process familiarity, Familiarity with ns-3's Lr-WPAN<br /> * ''Interests:'' Lr-WPAN, MAC and PHY designs<br /> * ''Difficulty:'' Medium.<br /> * ''Patch requirement:'' [[GSOC2024PatchRequirement]]<br /> * ''Recommended reading:''<br /> ** [https://ieeexplore.ieee.org/document/1700009 IEEE 802.15.4-2006]<br /> ** [https://ieeexplore.ieee.org/document/7460875 IEEE 802.15.4-2015]<br /> ** [https://www.nsnam.org/docs/models/html/lr-wpan.html ns-3 lr-wpan module]<br /> <br /> Possible tasks to fulfill the patch requirement:<br /> * [[GSOC2024PatchRequirement]]</div>

Tommaso https://www.nsnam.org/mediawiki/index.php?title=GSOC2025Projects&diff=13370 2025-02-05T13:46:52Z

<p>Tommaso: </p> <hr /> <div>{{TOC}}<br /> <br /> This page contains 2025 Google Summer of Code project ideas for ns-3.<br /> <br /> * [https://developers.google.com/open-source/gsoc/faq GSoC Frequently Asked Questions]<br /> * [[GSOC2024ContributorGuide |ns-3's 2024 GSoC Contributor guide]]<br /> * [https://developers.google.com/open-source/gsoc/resources/guide GSoC contributor/student guide (not ns-3 specific)]<br /> * [[GSOC2024ApplicationTemplate |2024 GSoC Contributor application template]]<br /> * [[GSOCMentorGuide | ns-3's GSoC Mentor guide]]<br /> * [https://archive.flossmanuals.net/gsocmentoring/index.html GSoC Mentor guide (not ns-3 specific)]<br /> * [[GSOCSelectionProcess | GSoC Contributor Selection Process]]<br /> * ''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/<br /> <br /> === About the ns-3 project ===<br /> <br /> ns-3 is a discrete-event network simulator, with a particular emphasis on network research and education.<br /> <br /> 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.<br /> <br /> 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.<br /> <br /> === Org admins ===<br /> <br /> 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].<br /> <br /> === Mentors ===<br /> <br /> 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.<br /> <br /> The current list of prospective mentors can be found among the ideas listed below.<br /> <br /> === How to apply ===<br /> <br /> For students or contributors interested in applying to ns-3 for GSoC, please go through the following list to get started:<br /> * Read the official [https://developers.google.com/open-source/gsoc/resources/guide GSoC contributor guide].<br /> * Read [[GSOC2024ContributorGuide |ns-3's GSoC contributor guide]]<br /> * Look through our [[#Project Ideas]] below to see if you find a project that interests you.<br /> * Review the [https://www.nsnam.org/documentation/development-tree/ tutorial and contributing guide] thoroughly, if you have not already done so.<br /> * 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.<br /> * Next, proceed to get in touch with the developers on the mailing list or Zulip chat room and refine your proposal.<br /> * 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.<br /> <br /> 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.<br /> <br /> &lt;blockquote&gt;<br /> Each project idea within a particular priority has been tagged with the following properties:<br /> * ''Required Experience:'' Languages, concepts, or packages with which applicants must be familiar.<br /> * ''Bonus Experience:'' Other experience or familiarity which would be greatly helpful to applicants for this project.<br /> * ''Interests:'' Areas of particular relevance to this project, and an indicator of where successful contributors might apply their experiences coming out of this project.<br /> * ''Difficulty:'' easy, medium or difficult<br /> * ''Recommended reading:'' pointers to documentation, papers, specific bugs, etc.<br /> <br /> 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.<br /> &lt;/blockquote&gt;<br /> <br /> === Patch requirement guidelines ===<br /> <br /> 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.<br /> <br /> 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.<br /> <br /> === Mentors: how to participate ===<br /> <br /> 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:<br /> <br /> * 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.<br /> * 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.<br /> * 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.<br /> <br /> == Project Ideas ==<br /> <br /> '''Note to contributors:''' These ideas are not listed in any priority order.<br /> 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.<br /> <br /> === Internet models enhancements ===<br /> <br /> * [[#ICMP socket and generate/handle ICMP messages (host/net unreachable)]] (medium size project, 175h)<br /> * [[#IPv6 global routing]] (large size project, 350h)<br /> * [[#DHCPv6 (DHCP for IPv6)]] (medium size project, 175h)<br /> * [[#IPv6 support in Ad hoc Routing Protocols]] (large size project, 350h)<br /> <br /> === IoT models enhancements ===<br /> <br /> * [[#6LoWPAN mesh-under routing enhancements]] (medium size project, 175h)<br /> * [[#6LoWPAN neighbor discovery protocol]] (medium size project, 175h)<br /> * [[#Mesh Link Establishment (MLE) protocol ]] (large size project, 350h)<br /> * [[#Lr-WPAN (IEEE 802.15.4) preamble detection support]] (large size project, 350h)<br /> <br /> === 5G NR models enhancements ===<br /> <br /> * [[#Improving 5G NR module usability]] (medium size project, 90h)<br /> * [[#Improving 5G NR module visualizations]] (medium size project, 175h)<br /> * [[#5G NR module benchmark analysis for different channel models]] (medium size project, 175h)<br /> <br /> == Small sized projects (90 hours) ==<br /> <br /> ===== Improving 5G NR module visualizations =====<br /> <br /> Mentors: [mailto:gcarvalho@cttc.es Gabriel Ferreira], [mailto:bbojovic@cttc.es Biljana Bojovic] and [mailto:kkoutlia@cttc.es Katerina Koutlia]<br /> <br /> Note: This could be proposed as either a small- or medium-sized project.<br /> <br /> The ns-3 5G nr module (aka 5G-LENA) is one of the most highly used and advanced ns-3 modules for simulating the 5G NR network. This project would be to improve the usability and examples of the 5G nr module by adding visualization tools to enrich the end-user experience.<br /> <br /> The main output will be the creation or porting of one (if small) or more examples from C++ to Python and adding visualization capabilities based on existing traces. The idea is that users can then see how the visualization was generated and better understand how the metrics collection works, and how changing parameters can affect simulation results. For this, the Jupyter notebook will be used, while Python scripts will be implemented for the visualization of the results. <br /> <br /> Examples to be implemented in Python:<br /> <br /> * An animated version of the REM map showing gNB beams moving along with a moving UE.<br /> * Resource allocation grid comparison for different resource schedulers.<br /> <br /> 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.<br /> 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].<br /> <br /> * Required Experience: C++ and Python programming, understanding of 5G NR, LTE, and wireless networks<br /> * Interests: 5G NR simulations<br /> * Difficulty: Medium.<br /> * 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.<br /> <br /> == Medium sized projects (175 hours) ==<br /> <br /> === ICMP socket and generate/handle ICMP messages (host/net unreachable) ===<br /> <br /> Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], [mailto:manoj24.rana@gmail.com Manoj K. Rana].<br /> <br /> 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 &quot;RAW&quot; socket.<br /> 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.<br /> <br /> 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.<br /> <br /> The most important point of the implementation should be code duplicate minimization, in order to have the minimize maintenance efforts.<br /> <br /> Once the sockets are in place, beside the &quot;normal&quot; tests, it will be necessary to modify the code that is actually made obsolete by the new sockets, e.g.:<br /> * IPv6 ICMP messages (RA, RS, NA, NS, etc.),<br /> * IPv4 ICMP messages,<br /> * ICMP Echo and ICMPv6 Echo messages.<br /> and to handle properly ICMP error messages like Destination Unreachable in the Ping application.<br /> <br /> * ''Required Experience:'' Fundamentals of IPv4 and IPv6 sockets, C++ programming.<br /> * ''Interests:'' Sockets and API interface implementation.<br /> * ''Difficulty:'' Medium.<br /> * ''Recommended reading:''<br /> ** [https://man7.org/linux/man-pages/man2/socket.2.html Linux socket]<br /> ** [https://courses.cs.vt.edu/cs4254/fall04/slides/raw_1.pdf Raw Sockets and ICMP, Srinidhi Varadarajan]<br /> ** [https://gitlab.com/nsnam/ns-3-dev/-/issues/810 Issue #810]<br /> <br /> Possible tasks to fulfill the patch requirement:<br /> * [[GSOC2024PatchRequirement]]<br /> <br /> === 6LoWPAN mesh-under routing enhancements ===<br /> <br /> Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], [TBD].<br /> <br /> 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.<br /> 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.<br /> <br /> The candidate should outline what parts of code are going to be affected, and how they can be enhanced thanks to RFC 7731.<br /> <br /> * ''Required Experience:'' Fundamentals of IPv6 addressing, C++ programming.<br /> * ''Bonus Experience:'' Familiarity with mesh routing and 6LoWPAN ns-3<br /> * ''Interests:'' IPv6 mesh routing<br /> * ''Difficulty:'' Easy.<br /> * ''Patch requirement:'' [[GSOC2024PatchRequirement]]<br /> * ''Recommended reading:''<br /> ** [https://www.nsnam.org/docs/models/html/sixlowpan.html#mesh-under-routing Mesh-under in ns-3 6LoWPAN]<br /> ** [https://datatracker.ietf.org/doc/html/rfc7731 RFC 7731]<br /> <br /> Possible tasks to fulfill the patch requirement:<br /> * TBD<br /> <br /> === 6LoWPAN neighbor discovery protocol ===<br /> <br /> Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], [TBD].<br /> <br /> 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.<br /> <br /> 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).<br /> <br /> 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.<br /> <br /> * ''Required Experience:'' Fundamentals of IPv6 addressing, C++ programming.<br /> * ''Bonus Experience:'' Familiarity with 6LoWPAN and 6LoWPAN-ND<br /> * ''Interests:'' IPv6 and IoT networks<br /> * ''Difficulty:'' Easy.<br /> * ''Patch requirement:'' [[GSOC2024PatchRequirement]]<br /> * ''Recommended reading:''<br /> ** [https://datatracker.ietf.org/doc/html/rfc8505 RFC 8505]<br /> ** [https://datatracker.ietf.org/doc/html/rfc6775 RFC 6775]<br /> ** [https://datatracker.ietf.org/doc/html/rfc4944 RFC 4944]<br /> <br /> Possible tasks to fulfil the patch requirement:<br /> * Patch the actual 6LoWPAN-ND to remove the limitation about concurrent address registrations.<br /> <br /> === DHCPv6 (DHCP for IPv6) ===<br /> <br /> Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], [TBD].<br /> <br /> DHCP is extremely important for IPv4 networks, because IPv4 lacks the address auto-configuration. Hence, DHCP is practically always used in IPv4.<br /> IPv6 does have the address auto-configuration (SLAAC), but it also does have DHCPv6. The two techniques are equally useful, and each have its pros and cons.<br /> <br /> ns-3 does have a model for DHCP, but it does not have one for DHCPv6. The goal is to add this functionality.<br /> <br /> The candidate should outline in the proposal the approach to the implementation (e.g., new application, extension of the current DHCP model, etc.).<br /> <br /> * ''Required Experience:'' Fundamentals of IPv6 addressing, C++ programming.<br /> * ''Bonus Experience:'' Familiarity with DHCP and/or DHCPv6<br /> * ''Interests:'' IPv6<br /> * ''Difficulty:'' Easy.<br /> * ''Patch requirement:'' [[GSOC2024PatchRequirement]]<br /> * ''Recommended reading:''<br /> ** [https://datatracker.ietf.org/doc/html/rfc8415 RFC 8415]<br /> <br /> Possible tasks to fulfil the patch requirement:<br /> * TBD<br /> <br /> === Improving 5G NR module usability ===<br /> <br /> Mentors: [mailto:bbojovic@cttc.es Biljana Bojovic],[mailto:kkoutlia@cttc.es Katerina Koutlia] and [mailto:gcarvalho@cttc.es Gabriel Ferreira]<br /> <br /> Note: This could be proposed as either a medium- or large-sized project.<br /> <br /> The ns-3 5G nr module (aka 5G-LENA) is one of the most highly used and advanced ns-3 modules for simulating the 5G NR network. This project would be focused on improving the usability and examples of the 5G nr module. The project consists of the following: <br /> <br /> * Improving nr helpers support: The outcome would be the implementation of new helpers and the improvement of existing ones, with the final goal of easing the usage of the 5G nr module. For example, some helpers do not have Doxygen documentation, and others require more than 30 lines of code just to specify the required 3GPP scenario. Helpers could be focused on simplifying the setup of nr scenarios, for example, the internet, the 3GPP scenario, the XR applications, the management of the configuration of many parameters of the scenario, etc. The management of the configuration of many parameters could be simplified by moving all the common parameters to a common class that can be shared between multiple examples, then new example simulations could be much smaller and simpler. All the nr examples should be updated to make use of these new helpers.<br /> <br /> * A completely new example should be created that would be 3GPP compliant and ready for research purposes and collaborative research. The idea is that if a new user is interested in implementing some new MAC scheduler or PHY algorithms, can take this new example as it is and use it to run a simulation campaign for its research on a realistic 5G scenario that is according to a selected 3GPP reference scenario. We could even think of a set of different predefined 3GPP scenarios, e.g. indoor, outdoor, etc. So, the new 5G-LENA user would not have to waste his/her research time in creating a new example but could pick this example and use it as it is to test his/her algorithm. Such examples would allow collaborative research because the users could reference such examples in their publications, and compare these results with the results with other researchers' algorithms.<br /> <br /> * As a final step, to validate the correct configuration through the helpers, it would be useful to have an easy way to generate plots of indicative performance metrics, such as the throughput and/or the delay (other metrics are also welcomed). For this purpose, some plotting scripts should be added to the examples folder. <br /> <br /> * Additionally, creating an “integration” example could be defined as the final part of the project, in the case of applying for a large project. The integration example is the example that demonstrates to nr users how to combine the nr module with another ns-3 module. See ns-3 Appstore here: https://apps.nsnam.org/app/tag/all/). Alternatively, integration with some external research tools could be proposed. For example, the interesting scenarios would involve the integration example that considers some of the following:<br /> ** NetSimulyzer (https://apps.nsnam.org/app/netsimulyzer/),<br /> ** Ns-3 gym (https://apps.nsnam.org/app/ns3-gym/) <br /> ** NYSIM (https://apps.nsnam.org/app/nyusim/)<br /> <br /> 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.<br /> For more specific guidelines, please view this [https://docs.google.com/document/d/1cQLIF1cdft1yj3vyWrjrxN2xDJMx8PuWaa9NP_nKf64/edit?usp=sharing Google document].<br /> <br /> * Required Experience: C++ programming, understanding of 5G NR, LTE, and wireless networks<br /> * Interests: 5G NR simulations<br /> * Difficulty: Medium.<br /> * 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.<br /> <br /> === Improving 5G NR module visualizations ===<br /> <br /> Mentors: [mailto:gcarvalho@cttc.es Gabriel Ferreira], [mailto:bbojovic@cttc.es Biljana Bojovic] and [mailto:kkoutlia@cttc.es Katerina Koutlia]<br /> <br /> Note: This could be proposed as either a small- or medium-sized project.<br /> <br /> The ns-3 5G nr module (aka 5G-LENA) is one of the most highly used and advanced ns-3 modules for simulating the 5G NR network. This project would be to improve the usability and examples of the 5G nr module by adding visualization tools to enrich the end-user experience.<br /> <br /> The main output will be the creation or porting of one (if small) or more examples from C++ to Python and adding visualization capabilities based on existing traces. The idea is that users can then see how the visualization was generated and better understand how the metrics collection works, and how changing parameters can affect simulation results. For this, the Jupyter notebook will be used, while Python scripts will be implemented for the visualization of the results. <br /> <br /> Examples to be implemented in Python:<br /> <br /> * An animated version of the REM map showing gNB beams moving along with a moving UE.<br /> * Resource allocation grid comparison for different resource schedulers.<br /> <br /> 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.<br /> 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].<br /> <br /> * Required Experience: C++ and Python programming, understanding of 5G NR, LTE, and wireless networks<br /> * Interests: 5G NR simulations<br /> * Difficulty: Medium.<br /> * 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.<br /> <br /> === 5G NR module benchmark analysis for different channel models ===<br /> <br /> Mentors:[mailto:aashtari@cttc.es Amir Ashtari Gargari], <br /> [mailto:bbojovic@cttc.es Biljana Bojovic] and [mailto:gcarvalho@cttc.es Gabriel Ferreira]<br /> <br /> Note: This could be proposed as either a medium- or large-sized project.<br /> The ns-3 5G nr module (aka 5G-LENA) is one of the most highly used and advanced ns-3 modules for simulating the 5G NR network. This project would be focused on improving the usability and examples of the 5G nr module. <br /> <br /> The ns-3 nr module should be able to make use of different channel models, however, all the currently available examples in the nr module use the ns-3 3GPP channel model. This project should extend the nr module to allow the configuration of additional channel models, such as TwoRaySpectrumPropagationLoss, and NYSim, and create a benchmark example that would allow switching among different channel models. The project should consist of the following steps:<br /> <br /> * TwoRaySpectrumPropagationLossModel was developed by Matteo Pagin during GSoC 2022: https://www.nsnam.org/wiki/GSOC2022Channel, with a main goal to provide an alternative channel model to ns-3 3GPP channel model that would be less computationally expensive and thus be a good choice for the large-scale 5G NR simulation. Matteo Pagin developed during his GSoC an NR example that uses this model, this example should be ported to the NR module. To allow the configuration of this model Matteo Pagin extended the NrHelper to allow that configuration. Such changes should be ported also to the NR module and used as an example of how to extend the NrHelper to allow the configuration of the NYSim channel model.<br /> <br /> * Additionally, the student should investigate what are the API changes that should be done in the NR module, mainly NrHelper, to allow the usage of the NYSim channel model. As an example, see how the mmWave module makes use of both 3GPP and NYSim channel models: https://apps.nsnam.org/app/mmwave/. Also, see the NYSim module in the ns-3 App Store:https://apps.nsnam.org/app/nyusim/. See also an additional description in the [https://docs.google.com/document/d/1cQLIF1cdft1yj3vyWrjrxN2xDJMx8PuWaa9NP_nKf64/edit?usp=sharing Google document].<br /> <br /> * Finally, a common benchmark scenario example that can make use of these three channel models should be created and used to perform the profiling study. An example could be the extension of Matteo's example or a completely new example. Additionally, the performance evaluation analysis of the NR should be done for the three models, and provide some insights into the assessed differences. <br /> <br /> * If during the performance analysis, the student detects the performance bottlenecks in the simulator that could be improved, the project could be extended to be a large-sized project.<br /> <br /> The project proposal should contain a refactoring plan and should list what changes will be made to the NR module to support the use of the TwoRaySpectrumPropagationLossModel and NYSim channel model. The project plan should also contain some idea of what scenario will be used for the performance evaluation, which frequency, outdoor or indoor, and the number of gNBs and UEs that will be profiled. The project plan should also include a description of the performance analysis with a target performance indicative metrics. There will be benchmark metrics related to the speed of the execution of the simulator, and also the NR performance metrics such as throughput and delay. The project plan should well define the development steps that would result in the often MRs toward the nr module and ns-3 upstream during the whole duration of the project. <br /> <br /> 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.<br /> <br /> For more specific guidelines, please view this [https://docs.google.com/document/d/1cQLIF1cdft1yj3vyWrjrxN2xDJMx8PuWaa9NP_nKf64/edit?usp=sharing Google document].<br /> *Required Experience: C++ programming, understanding of 5G NR, LTE, and wireless networks<br /> *Interests: 5G NR simulations<br /> *Difficulty: Medium-High.<br /> *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.<br /> <br /> == Large projects (350 hours) ==<br /> <br /> === IPv6 global routing ===<br /> <br /> Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], [TBD].<br /> <br /> 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).<br /> For IPv4, ns-3 provides two alternatives: GlobalRouting, and NixRouting, which just &quot;do the trick&quot; - they simply fill the routing tables in intermediate nodes, GlobalRouting using an approach similar to OSPF, NixRouting by leveraging the &quot;abstract&quot; knowledge of the network.<br /> Neither actually use any message between the nodes, so they also reduce the network overhead - something that is useful in many cases.<br /> <br /> 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.).<br /> <br /> 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.<br /> <br /> * ''Required Experience:'' Fundamentals of IPv6 addressing, C++ programming.<br /> * ''Bonus Experience:'' Familiarity with GlobalRouting implementations in ns-3<br /> * ''Interests:'' IPv6 routing<br /> * ''Difficulty:'' Medium.<br /> * ''Patch requirement:'' [[GSOC2024PatchRequirement]]<br /> * ''Recommended reading:''<br /> ** [https://www.nsnam.org/docs/models/html/ipv6.html IPv6 model in ns-3]<br /> ** [https://www.nsnam.org/docs/models/html/routing-overview.html#global-centralized-routing GlobalRouting model in ns-3]<br /> <br /> Possible tasks to fulfill the patch requirement:<br /> * 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.<br /> <br /> === IPv6 support in Ad hoc Routing Protocols ===<br /> <br /> Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], [TBD].<br /> <br /> ns-3 contains models for proactive (DSDV and OLSR) and reactive (AODV and DSR) ad hoc routing protocols. However, these models are IPv4-only and do not provide support of IPv6 addressing. This project aims to enable IPv6 support for ad hoc routing protocols in ns-3, mainly for AODV. There are out-of-tree implementations of OLSR and DSDV that provide support for IPv6 addressing, and can be used as references to get started with this project.<br /> <br /> The most important point of the implementation should be code duplicate minimization, in order to have the minimize maintenance efforts.<br /> <br /> Note: Enabling IPv6 support for these protocols is not a matter of simply changing out an IPv4-formatted address for an IPv6-formatted address. The IPv6 addressing architecture emphasizes scoping much more than does IPv4 (RFC 4007). Please suggest in your application how IPv6 address configuration (and possibly auto-configuration?) and address scopes (e.g. link-local vs. global) should be used in these protocols. Consulting the RFCs is highly recommended.<br /> <br /> * ''Required Experience:'' Fundamentals of IPv6 addressing, C++ programming.<br /> * ''Bonus Experience:'' Familiarity with AODV implementations in ns-3<br /> * ''Interests:'' Ad hoc routing<br /> * ''Difficulty:'' Medium.<br /> * ''Patch requirement:'' [[GSOC2024PatchRequirement]]<br /> * ''Recommended reading:''<br /> ** [https://www.nsnam.org/docs/models/html/ipv6.html IPv6 model in ns-3]<br /> ** [https://www.nsnam.org/docs/models/html/aodv.html AODV model in ns-3]<br /> ** [https://www.nsnam.org/workshops/wns3-2016/posters/IPv6-support-for-OLSR.pdf IPv6 Support for OLSR in ns-3]<br /> <br /> Possible tasks to fulfill the patch requirement:<br /> * [https://gitlab.com/nsnam/ns-3-dev/-/issues/271 Issue #271] - olsr header and messages are not printing either their size or their content.<br /> * [https://gitlab.com/nsnam/ns-3-dev/-/issues/368 Issue #368] - aodv: aodv parameters can be set to &quot;impossible&quot; values<br /> <br /> === Mesh Link Establishment (MLE) protocol ===<br /> <br /> Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], TBD.<br /> <br /> 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.<br /> However, MLE is being used in Thread, and it can be useful to implement it.<br /> <br /> 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.<br /> <br /> * ''Required Experience:'' Fundamentals of IPv4 and IPv6 sockets, C++ programming.<br /> * ''Interests:'' Sockets and API interface implementation.<br /> * ''Difficulty:'' Hard.<br /> * ''Recommended reading:''<br /> ** [https://datatracker.ietf.org/doc/html/draft-ietf-6lo-mesh-link-establishment MLE draft]<br /> ** [https://openthread.io/guides/thread-primer/network-discovery Thread primer]<br /> ** [https://www.threadgroup.org/ThreadSpec Thread specifications]<br /> <br /> Possible tasks to fulfill the patch requirement:<br /> * [[GSOC2024PatchRequirement]]<br /> <br /> === Lr-WPAN (IEEE 802.15.4) preamble detection support ===<br /> <br /> Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], [mailto:alramonet@is.tokushima-u.ac.jp Alberto Gallegos Ramonet].<br /> <br /> 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<br /> 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<br /> itself has many added benefits.<br /> <br /> 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.<br /> <br /> As usual, reduction of code duplicity and a flexible scalable design is desired (e.g. Allow the inclusion of different preambles in the future).<br /> <br /> * ''Required Experience:'' Basic understanding of IEEE 802.15.4, C++ programming.<br /> * ''Bonus Experience:'' PHY process familiarity, Familiarity with ns-3's Lr-WPAN<br /> * ''Interests:'' Lr-WPAN, MAC and PHY designs<br /> * ''Difficulty:'' Medium.<br /> * ''Patch requirement:'' [[GSOC2024PatchRequirement]]<br /> * ''Recommended reading:''<br /> ** [https://ieeexplore.ieee.org/document/1700009 IEEE 802.15.4-2006]<br /> ** [https://ieeexplore.ieee.org/document/7460875 IEEE 802.15.4-2015]<br /> ** [https://www.nsnam.org/docs/models/html/lr-wpan.html ns-3 lr-wpan module]<br /> <br /> Possible tasks to fulfill the patch requirement:<br /> * [[GSOC2024PatchRequirement]]</div>

Tommaso