From Nsnam
Jump to: navigation, search

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

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

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

About the ns-3 project

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

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

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

Org admins

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


Mentors will be paired with students 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 Tom Henderson or Tommaso Pecorella of interest. Mentors familiar with ns-3 development practices will be preferred, to improve the chances of student code merge. In 2019, we are going to be seeking two-person or multiple-person mentoring teams for projects, to help with the mentoring workload and bring more expertise.

The current list of prospective mentors for 2019 (depending on project selection) includes Zoraze Ali, Abhijith Anilkumar, Gabriel Arrobo, Biljana Bojovic, Ankit Deepak, Lorenza Giupponi, Tom Henderson, Pasquale Imputato, Alexander Krotov, Sandra Lagen, Tommaso Pecorella, Natale Patriciello, Manoj Kumar Rana, Mohit Tahiliani, and Dizhi Zhou.

Students: how to participate

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

Below is a list of #Project Ideas proposed by the ns-3 team for Google Summer of Code 2019. Please note that these ideas are not limited to GSoC; anyone is welcome to work on them. Please email the ns-developers list if you have a different idea that you'd like to work on, to see if a mentor may be interested. Applicants are encouraged to look over this list, pick one that especially interests them, think about it, and discuss potential approaches on the ns-developers list. Previous experience with the Google Summer of Code programmes 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 programme.

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

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

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

Mentors: how to participate

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

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

Project Ideas

Note to students: These ideas are not listed in any priority order.

Improvement of usability and maintainability of LTE schedulers

Mentors: Zoraze Ali, Biljana Bojovic

The LTE scheduler is a key RAN feature that allows to analyze many information received at eNB MAC layer and take fundamental decisions in terms of the radio resurces to be allocated. The LTE module offers multiple schedulers, characterized by a high number of lines, many of which are duplicated. This complicates the maintainability of the code, since every time that something needs to be changed in the scheduler, needs to be changed in all the schedulers. And also complicates the usability, since the structure of the code is monolithic, while the user often needs to just get access to some input information, and change the scheduler policy in order to test different scheduler solutions. The proposal of this project is to reorganize the schedulers' structure in a more modular way, in order to overcome the duplication of lines of code and facilitate the usability of this important LTE functionality.

  • Required Experience: C++, Git
  • Interests: LTE cellular networks
  • Difficulty: Medium
  • Recommended reading: LTE ns-3 documentation and FemtoForum MAC Scheduler Interface API

API for UE scheduler

Mentors: Zoraze Ali, Lorenza Giupponi

Similar to the classical LTE networks, the scheduler in the LTE module of ns-3 lies at the eNB, which interacts with its MAC by using a well defined API based on the FemtoForum MAC Scheduler Interface. However, with the advent of new paradigms, e.g., LAA, LTE ProSe, V2X and 5G NR, the concept of autonomous uplink scheduling has became more prominent. To incorporate such capability into the LTE module of ns-3 the MAC layer API of UE needs to be extended in a similar fashion as the eNB by using the FemtoForum MAC Scheduler Interface. This would allow custom implementation of UE schedulers to simulate the scenarios with autonomous uplink scheduling.

  • Required Experience: C++, Git
  • Interests: Cellular networks, LTE
  • Difficulty: Medium
  • Recommended reading: LTE ns-3 documentation and FemtoForum MAC Scheduler Interface API

Usability improvements

Mentors: Tom Henderson, Dizhi Zhou, others TBD

Usability of ns-3 can always be improved, whether it is help with building simulations, running simulation campaigns, using the ns-3 C++ API, improving the Python user experience, visualizing simulations or data, software packaging (e.g. binary packages or Docker containers), or documentation. This project is for a student who has been using ns-3 for a while and has ideas on how to make it better during GSoC. We don't want to limit the scope of proposals here; we will consider any project ideas that improve ns-3 usability in some way (please explain to us why the usability improvement is important to users beyond yourself, and why you would argue for your particular solution, and of course describe how you plan to get it done during the timeframe of GSoC). Some possible project examples:

  • Tools and scripts to conduct and manage data from a large number of simulation runs
  • How to integrate a more Python-centric data flow and tools, such as Jupyter Notebook and bqplot
  • Internal state visualization of Wi-Fi or LTE, such as the kind of plots generated by Yavista

L4/L3 routing improvement

Mentors: Tommaso Pecorella

At the moment, each packet in ns-3 is routed independently. Even though this is a good behaviour for routers, it is not for the source node (expecially for TCP). As a matter of fact, when a TCP connection is established, *all* its packets should be directed to the very same output interface. The same goes for UDP when the source address is forced to be a specific one. The project idea is to modify the TCP and UDP stacks so that they can store the source address after the connection phase, and skip part of the routing process. Other improvements to IPv4 and IPv6 routing are possible in this project as well, including making some IPv4-only routing capabilities also IPv6-capable.

  • Required Experience: C++, TCP, UDP
  • Bonus Experience: IPv4 and IPv6 routing
  • Interests: TCP and UDP
  • Difficulty: medium
  • Recommended reading:

NetDevice up/down consistency and event chain

Mentors: Tommaso Pecorella, Manoj Kumar Rana

There in no actual consistency among the different modules about how to handle Up/Down events (e.g., when a link is lost). This prevents some "normal" behaviours from happening, e.g., the DHCP IP address renegotiation, MIP implementation, etc. As a matter offact, one should expect that an IP interface would be declared as "down" when its NetDevice is down... but it isn't. The goal of this project is to fix this behavior, to update some NetDevices so that they use Up/Down events consistently, to provide the documentation about what is the standard behavior, and what NetDevices are actually implementing it in the right way.

  • Required Experience: C++, NetDevices, Interface behavior
  • Bonus Experience: NetDevice and IP behavior
  • Interests: NetDevice and IP behavior
  • Difficulty: medium

User-friendly internet-apps

Mentors: Tom Henderson

Ping is a ubiquitous application for reachability and latency measurements. ns-3 already has a ping model (the and However, a user-friendly API could still be added. It is not straightforward to configure an ns-3 program to do in a single statement, for example, "Ping the IP address W.X.Y.Z from node 0 between times 5 and 50 seconds in my program, and save the output in traditional format to the file <filename.txt>", or to configure the many options found in the ping man page. This project is therefore not about developing brand new features as much as it is about making ping super-easy to use with a great API. Have a look at how ns-3 programs are written, and tell us what kind of API makes sense to you, and why, and how you would go about prioritizing its implementation. If ping is solved very early, the project can follow the same pattern for one or two more applications (e.g. netperf, iperf, etc.).

  • Required Experience:C++
  • Interests: Network performance management
  • Difficulty: Medium
  • Recommended reading:

nam upgrade and support for ns-3

Mentors: Tom Henderson

nam is a Tcl/Tk-based animator for ns-2. Some example videos are found at YouTube. nam has been functionally replaced in many ways by NetAnim, but it still has some attractive features and might make a complementary animation tool for ns-3. In fact, someone did a proof-of-concept support of nam for ns-3 many years ago: This project would involve upgrading nam support to the latest Tcl/Tk release series (8.6) and then using the existing ns-3 trace system to generate nam output files such as in ns-2, and documenting and testing the results, including some demonstration videos.

  • Required Experience:C++, Tcl/Tk also preferred
  • Interests: Network visualization/animation
  • Difficulty: Medium
  • Recommended reading:
    • the links listed above

NetAnim Python and examples

Mentors: Tom Henderson

NetAnim is an optional animator for ns-3. It has not been actively developed for a few years. It is written using Qt libraries, and works in an offline mode, meaning that the simulation run outputs a detailed animation trace file that is later imported into NetAnim to visualize the simulation. NetAnim is presently underutilized because of lack of documentation on many features and lack of examples/tutorials around its use. Python bindings for the animator are also not supported. We would be interested in a student who would focus a project around improving the usability, documentation, and examples around NetAnim.

TCP testing and alignment

Mentors: Tom Henderson, Mohit P. Tahiliani, Natale Patriciello

ns-3 needs good TCP models that align with real implementations, or that have documented differences. In particular, does ns-3 TCP's slow start and congestion avoidace perform like a real implementation, including common variants found in the field (CUBIC, DCTCP), and ones under development (TCP Prague, BBR). The project should also produce regression tests. We envision that this project will consist of setting up ns-3 in emulation mode to test operation of its implementation against real implementations, in different impairment environments, documenting the results, and figuring out how to take the ns-3 results and generate regression tests.

TCP analysis

Mentors: Tom Henderson, Mohit P. Tahiliani, Natale Patriciello

This project is not about developing new TCP variants, but about developing a TCP analysis capability that is user-friendly and produces output similar to (perhaps integrates with?) tools such as captcp, Wireshark TCP analysis, tcptrace, Tstat, or other similar tools. An important part of your application will be a description of how a user will enable it in a user program, and some description of how it will be implemented.

As an example, consider providing the user with the ability to auto-generate plots of throughput evolution, congestion window evolution, etc. over time, for a pair of 4-tuples where the 4-tuples may contain wild cards or regular expressions. For instance, the user specifies "*" and "", and if there are three connections in the simulation from to that specific IP address and port, then three sets of time-series plots are generated and labelled appropriately.

  • Required Experience:C++, TCP
  • Difficulty: Medium
  • Recommended reading:
    • ns-2 and ns-3 manuals

802.15.4 Bootstrap

Mentors: Tommaso Pecorella

The lr-wpan model is an 802.15.4 PHY and MAC model currently in development. The model is able to simulate an 802.15.4 network in ad-hoc mode, much like Contiki-os nodes do. An useful extension is to fully support the node bootstrap phase, including node association and beacon request/reply. The goal of the project is to enhance the lr-wpan module so to use beacons in the bootstrap phase along with network scanning and pan-id resolution for in-range coordinators.

  • Required Experience: C++, WSN
  • Bonus Experience: 802.15.4 standard
  • Interests: WSN
  • Difficulty: medium
  • Recommended reading:

802.15.4 Beacon-enabled mode

Mentors: Tommaso Pecorella

The lr-wpan model is an 802.15.4 PHY and MAC model currently in development. The model is able to simulate an 802.15.4 network in ad-hoc mode, much like Contiki-os nodes do. Unlike Contiki-os, the model could benefit from supporting beacon-enabled mode of operation. The beacon-enabled mode is a fully slotted transmission mode, with guaranteed slots and bound performances, unlike the ad-hoc mode. This is especially important because the L3 routing protocols might be strongly affected by the lower-layer topology. Hence it is of paramount importance to be able to simulate both in ns-3. The goal of the project is to develop the new beacon-enabled MAC layer for the lr-wpan module.

  • Required Experience: C++, WSN
  • Bonus Experience: 802.15.4 standard
  • Interests: WSN
  • Difficulty: medium/hard
  • Recommended reading:

DSR routing RFC compliance

Mentors: Tommaso Pecorella

The DSR routing module is not compliant with the RFC 4728. This leads to a number of small issues, like simulation imprecision and impossibility to decode the messages with Wireshark. The goal of the project is to enhance the current model and to make it RFC-compliant, eventually doing a code refectory where needed. A possible enhancement over the base protocol could also be to include support for IPv6 in the implementation.

  • Required Experience: C++
  • Bonus Experience: DSR standard
  • Interests: Ad-hoc routing
  • Difficulty: medium
  • Recommended reading:

Enable IPv6 support for Ad hoc Routing Protocols in ns-3

Mentors: Tommaso Pecorella, Mohit P. Tahiliani

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 and DSR. 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. An important point of the implementation should be code duplicate minimization, in order to have the minimize maintenance efforts. Note: Enabling IPv6 support for these protocols is not a matter of simply changing out an IPv4-formatted address for an IPv6-formatted address. The IPv6 addressing architecture emphasizes scoping much more than does IPv4 (RFC 4007). Please suggest in your application how IPv6 address configuration (and possibly auto-configuration?) and address scopes (e.g. link-local vs. global) should be used in these protocols. Consulting the RFCs is highly recommended.'

3GPP Channel model for sub 6-GHz and porting to ns-3 mainline

Mentors: Natale Patriciello, Biljana Bojovic, Sandra Lagen

Among the multiple valuable contributions provided by the mmWave fork, there is the 3GPP channel and the beamforming antenna model. These features are modeled for the mmWave bands (>= 6 GHz), as defined in the reference 3GPP document (3GPP TR 38.900). The purpose of this project would be to extend the mentioned model to frequency bands below 6GHz, i.e., to the model described in TR 38.901. Besides, the project would require a refactoring of the code, in such a way that it can be included in mainline ns-3, with some parts in propagation and others in antenna modules. The objective would be to make these models accessible from other modules (inside or outside mainline), such as LTE, mmWave, and NR. The resulting code will be the foundation of an improved M-MIMO model in LTE.

Other interesting additions, up to the students, are the management of panels and the antenna polarization. The proposal must include documentation and testing code.

Persistent and Semi-Persistent Scheduling inside LTE module

Mentors: Natale Patriciello, Sandra Lagen

If you were thinking on going for this project, please contact the mentors. Right now, the proposal is suspended.

Please get in touch with Natale and Sandra before going straight with this project. The goal of this project is to implement Semi-Persistent Scheduling (SPS) scheme in the ns-3 LTE module. SPS scheme is enabled in 4G LTE, as well as in 5G, in order to save L1/L2 (layer 1/layer 2) control signaling and reduce resource overhead for some periodic and predictable traffic, such as voice over IP (VoIP) and traffic from sensors/IoT devices. Currently, in ns-3 LTE, only Dynamic Scheduling (DS) scheme is implemented, for which the scheduling decisions are dynamically signaled on L1/L2 control to indicate the allocated resources. Differently, in SPS, only the first scheduling assignment is signaled on L1/L2, and the subsequent transmissions use the same resources with a preconfigured interval, thus reducing L1/L2 overhead. In particular, SPS periodicity is configured by RRC, and then activation is signaled through the downlink control information (DCI), both for downlink and uplink SPS. The idea of this project is to extend RRC parameters, and DCI formats, to enable SPS scheme, and to update the MAC scheduler (L2) to enable both SPS and DS schemes for different traffic simultaneously. The later requires, among others, a memory in the scheduler, so as not to allocate resources for DS that are already scheduled for SPS.

  • Required Experience: C++, LTE understanding
  • Bonus Experience: Familiarity with lte module
  • Interests: LTE scheduling (MAC layer)
  • Difficulty: Medium.

Structured logging support

Mentors: Alexander Krotov, ?

Sometimes an experiment with a hard to find bug takes a lot of time to run, so it may be desirable to collect as much information as possible and process it later, without adding traces and running experiment again multiple times.

Existing NS-3 logging framework does not support structured logging. It is only capable of printing text messages, which are hard to process automatically. In fact, NS-3 manual even contains a warning:

The project makes no guarantee about whether logging output will remain the same over time. Users are cautioned against building simulation output frameworks on top of logging code, as the output and the way the output is enabled may change over time.

Currently logs often lack context information, such as MAC addresses, node IDs etc. Even if the required information is present, extracting it from text messages is error-prone, and message format may change from version to version even when the required data is still available. As a result, it is often easier to resort to installing traces and adding conditionals to the NS-3 code, recompiling the code and re-running experiments.

Structured logging, sometimes called semantic logging, is an approach that solves the problem of logs not being machine-readable.

For example, instead of writing

NS_LOG_LOGIC ("Route to " << m_endPoint->GetPeerAddress () << " does not exist");

it will be possible to write something like

NS_LOG_LOGIC ("Route to {peer_address} does not exist",
              "peer_address", m_endPoint->GetPeerAddress (),
              "id", "route_not_exist");

When used in text mode, the logging framework will output messages as usual. In addition, it will be able to store messages as dictionaries, for example in JSON Lines, some binary format or a database.

The message above could be represented as

  "message": "Route to {peer_address} does not exist",
  "peer_address": {"type": "ipv4", ""},
  "id": "route_not_exist"

In addition, messages need to contain some context, extracted from object this, object identifier (its pointer) and timestamp.

The goal of this project is to

  • Add API to serialize NS-3 object to dictionaries.
  • Implement structured logging framework in the core module.
  • Implement at least text and JSON output, extensible to add more output formats later.
  • Add structured logging support to at least some modules, e.g. applications. It should be possible to incrementally switch to structured logging support later.

There are hardly any C++ structured logging frameworks. There is a, which is abandoned and uses Apache 2.0 license, that is incompatible to NS-3 license (GPLv2). As a result, it will probably be required to implement the whole framework from scratch. Structured logging frameworks for other languages, such as, can be used for inspiration.

  • Required Experience: C++
  • Difficulty: medium

IP Traffic Control in LTE networks

Mentors: Natale Patriciello, Pasquale Imputato

The TC layer is in the middle between IP and any Netdevice, and its role is to manage the scheduling, and the queueing, of IP packets. To work, it need cooperation by the NetDevices: they have to inform when they are ready to receive new packets, or when their internal queues are full. The project is centered on developing the cooperation between the LTE module and the TC module. The starting point is the work done by a Ph.D. student and to merge it in ns3 dev.

  • Required Experience: C++, LTE understanding
  • Bonus Experience: Familiarity with LTE, TC, and network module
  • Interests: Reducing latencies
  • Difficulty: Easy to Medium
  • Interested readings:

Linux-like CAKE queue discipline for ns-3

Mentors: Mohit P. Tahiliani

Common Applications Kept Enhanced (CAKE) is the most recent queue discipline added in Linux 4.19. It is a comprehensive queue management framework targeted for home Internet gateways, and integrates the following four components: bandwidth shaping, a new Active Queue Management (AQM) algorithm called COBALT (CoDel BLUE Alternate), handling Differentiated Services (DiffServ) and TCP ACK filtering. The main tasks in this project include: implementation, testing and documentation of individual components of CAKE in ns-3, followed by the integration of these components to form CAKE queue discipline in ns-3.

Improving the ns-3 AppStore and linking with bake

Mentors: Abhijith Anilkumar, Tom Henderson, Ankit Deepak

The ns-3 AppStore organizes information about the availability of extensions to the main ns-3 releases, and is built using Django. The app store has backend extensions to the Bake build system, enabling users to build a module from the bakefile.xml file. The main goal of this project is to link the Bake build system with the ns-3 AppStore. As the end goal, we envision letting the user type a command locally, something like bake install mmwave which automatically fetches the data from the App Store, and does the required installation process. By opening up REST APIs, we send data from the app store in the format that can be processed by bake and then install it.

  • Required Experience: Familiarity with Python, Django.
  • Bonus Experience: Familiarity with Django Rest Framework.
  • Difficulty: Low to Medium

IoT and WSN devices: 6LoWPAN-ND implementation

Mentors: Tommaso Pecorella

The 6LoWPAN protocol is essential to simulate low-power IoT devices. The actual 6LoWPAN implementation follows RFC 4944 and RFC 6282. The current implementation lacks the support for 6LoWPAN-ND, described in RFC 6775 and RFC 8505. 6LoWPAN-ND is important to avoid the use of Neighbor Discovery Protocol, which is a high-overhead protocol, and might not be supported at all in many IoT contest (e.g., multi-hop 802.15.4 networks).

There is a prototype 6LoWPAN-ND implementation, but it is far from finished. The goal of this project is to conclude the development, document, test, and merge the 6LoWPAN-ND protocol into ns-3.

  • Required Experience: IPv6
  • Bonus Experience: Familiarity IPv6 compression.
  • Difficulty: Low to Medium

IoT and WSN devices: RPL implementation

Mentors: Tommaso Pecorella

The RPL protocol is the routing protocol for Wireless Sensor Networks using low-power, contained, multi-hop devices. It is based on IPv6 and, more than a protocol, it could be classified as a routing protocol framework. The actual protocol is defined through a series of RFC that can be found at the ROLL IETF Working Group.

The actual RPL implementation is quite outdated, and suffers from a number of questionable assumptions that, over the time, have shown their limits. This implementation is not public, but it have been used by a restricted number of testers.

The goal of this project is to analyze the current RPL implementation code, and:

  1. Remove some limitations of the actual implementation
  2.  Write the documentation
  3.  Develop the unit test and examples
  4. Merge the code.

A welcome, albeit not strictly necessary, thing would be to implement the recently approved RFC extensions to RPL.

  • Required Experience: Familiarity with routing and IPv6.
  • Bonus Experience: Familiarity RPL.
  • Difficulty: Medium-Hard