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

ns-3's GSoC 2018

This webpage highlights project ideas for ns-3's Google Summer of Code 2018 effort.

The thirteen week coding period for projects runs from 14 May to 14 August, 2018. The full project timeline is here:

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.

Our GSoC organizational admin is Tom Henderson and our backup org admin is Tommaso Pecorella. The project has participated in past GSoCs during 2008-10, 2012-15, and 2017.

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.

Students: how to participate

For students interested in applying to ns-3 for GSOC, first wait to see if ns-3 will be selected. If so, then 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 2018. 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. The list of mentors for 2018: Tom Henderson, Tommaso Pecorella, Mohit Tahiliani, Dizhi Zhou, Matthieu Coudron, and Natale Patriciello.

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

LTE and Wi-Fi Coexistence

Mentors: Tom Henderson

Since 2016, the License-Assisted Access (LAA) variant of LTE has been a popular off-tree repository, but this fork has never been merged to ns-3-dev and has fallen behind. In addition, features beyond the Release 13 LAA (such as Release 14 eLAA) are desired. The main focus of this project would be to work with the LTE and Wi-Fi maintainers to integrate the LAA-based changes to those repositories, and to move the laa-wifi-coexistence module to a released 'app' on the new ns-3 App Store. A similar job of porting LTE-U CSAT models to ns-3-dev is also of interest.

  • Required Experience:C++, LTE and Wi-Fi understanding
  • Interests: wireless networking and coexistence
  • Difficulty: Medium
  • Recommended reading: the code found in the above, and this arXiv paper

Wi-Fi mesh module upgrade

Mentors: Tom Henderson

ns-3 Wi-Fi mesh module was written about 8 years ago, and is not completely up to date with the standard, nor does it work with newer Wi-Fi variants (802.11n/ac/ax). This project would prioritize making mesh module compatible with all variants of Wi-Fi and would align with the latest standard. Going further, some scenarios and scripts that align ns-3 simulations with how community networks are set up and configured would be helpful, such as guidance on how to configure rate controls and routing protocols (e.g. how to run OLSR on top of mesh).

  • Required Experience:C++, Wi-Fi and mesh understanding
  • Interests: mesh networking
  • Difficulty: Medium
  • Recommended reading: mesh issues in the tracker, and the mesh module documentation, and IEEE 802.11 standard

Direct Code Execution upgrade

Mentor: Matthieu Coudron

ns-3 has an extension known as Direct Code Execution, which allows users to build C or C++-based applications, and open source (Linux, FreeBSD) kernels, into ns-3. However, support for the latest kernels (e.g. Linux kernel 4 series) and latest gcc versions has languished. We also could better integrate DCE with the main ns-3 tree. This project seeks a student interested in DCE, improving usability, and making it current with latest kernels and toolchains. The payoff of this type of project is very high since DCE makes available a lot of real-world models for use in ns-3. If you select this project idea, please engage with us on the developers list, and consider to take a look at solving one of the open DCE issues in our tracker, for starters.

Freshen ns-3/Click integration

Mentors: Tom Henderson

ns-3 and Click modular routing were first integrated in an ns-3 GSoC project from 2010. We seek a student interested in the following tasks:

  • Since 2010, Ipv4L3Protocol has continued to evolve, but Ipv4L3ClickProtocol has not kept pace with the changes. Also, IPv6 is not supported. Refactor Ipv4L3Protocol and Ipv4L3ClickProtocol (or delete Ipv4L3ClickProtocol altogether) so that the click-specific pieces are limited and can be maintained more easily.
    • Current thoughts on this are that we would like to modify the approach. It would be nice for Click to run on ns-3 in a manner that is as close as possible to its working outside simulation (raw sockets + tun/tap devices). This will hopefully allow us to delete IPv4L3ClickProtocol and avoid needed ns-3 code to expect Click to provide a routing table. ns-3 traffic generators should then be able to send packets to an ns-3 equivalent of a tun/tap device (which doesn't presently exist), have packets show up in Click, and then get Click to push those packets directly to an interface using raw sockets from inside ns-3.
  • There was an ns-3 2011 summer project (not part of GSoC, but a follow-on project) to try to finish the integration with ClickMac. We'd like to update it, finish it off, and merge it with ns-3-dev. Some brief discussion was here:
    • The blocking issue at the time was in the Wi-Fi module; the changes in radiotap and frame injection over monitor mode, which Click needed, were not finished (accepted).
  • Anything else that a student thinks would be useful to support regarding click and ns-3 integration. Consider to review in the recent literature (see Google Scholar) how Click is now being used for research, and think about then what might be research-driven priorities for support in ns-3. Provide evidence (citations) in your application.

The list is not exhaustive and not limiting. I.e., the candidate can propose other points and/or concentrate on a specific subset.

  • Required Experience: C++
  • Bonus Experience: IPv4, IPv6, Click.
  • Interests: Software integration.
  • 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

ns-2 ports to ns-3

Mentors: Tom Henderson, Mohit P. Tahiliani

ns-2 is the predecessor to ns-3, but some popular models still exist in ns-2 and are not yet ported to ns-3. Google Scholar can be used to find topics for which people still are publishing papers using ns-2. This project idea is for someone who is fond of some feature or model found in ns-2 but not in ns-3. A successful application of this type will make a good case that the port is still relevant to network research, that people are using ns-2 due to this model, and will describe the technical approach that is planned to make the port (e.g. how OTcl default variables will be ported to ns-3). Please note that the networking relevance is very important part of the application; if you propose to port some feature of ns-2 that is dated or unlikely to be of much interest because its applicability is very narrow, your proposal will not be selected.

  • Required Experience:C++, ns-2 also preferred
  • Difficulty: Low to medium
  • Recommended reading:
    • ns-2 and ns-3 manuals

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:

Implementation of AccECN and ECN++ in ns-3

Mentors: Mohit P. Tahiliani

Reducing Internet Transport Latency is an interesting research topic and has gained significant attention in the recent past. Some of the promising new solutions rely on Explicit Congestion Notification (ECN) (RFC 3168) to notify TCP endpoints of congestion that may be developing in a bottleneck queue, without resorting to packet drops. As a result, there have been attempts at Internet Engineering Task Force (IETF) to extend the functionality of ECN and provide rich feedback to TCP endpoints. In this regard, Accurate ECN feedback (AccECN) and ECN++ are two active topics of discussion at IETF. This project proposal is to: extend the ECN implementation in ns-3 to support AccECN and ECN++, test the correctness of implementation and provide examples.

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

Trust-based routing protocols framework

Mentors: Tommaso Pecorella

ns-3 contains different routing modules, both for IPv4 and for IPv6. None of them is trust-based. Given the increasing interest on trust-based routing schemes to increase and improve the network resilience Vs routing attacks, it would be useful to have a general approach for Trust-based schemes. As a matter of fact, there are multiple trust-based extensions for well known protocold (e.g., AODV), but each one modifies in a particular way the single routing protocol, making it difficult to export the solution to other routing schemes. On the opposite, it would be extremely useful to have an architectural approach where the next hop trust calculation is independent from the actual routing protocol or communication scheme, and the protocol(s) can use the next hop trust independently from the actual scheme used to calculate the trust value. This should allow a greater flexibility in studying differet trust evaluation schemes and their effect on different routing policies. The project aims at defining and develop a Trust-based framework, at least one (or more) trust evluation methods, and apply them to at least one (or more) routing protocols.

Data collection and statistics framework extension

Mentors: Dizhi Zhou

The goal of this project is to extend and add more functionalities on ns-3 data collection and statistics framework (source code:ns-3.27/src/stats/) which was added in ns-3.18. The model was implemented based on the ns-3 tracing system. It has two major functions. 1) retrieve data from multiple ns-3 trace sources and then recalculate/transform the data into a user-defined format. However, not all the trace source types are supported. 2) use a data collector to calculate some useful statistics from a ns-3 trace source (e.g. max and min of the trace value). However, only supports counter and min/max data collectors are supported today. In order to make the model more useful, more trace source types, output formats and collectors need to be added.

A parallel project of ns-3, named sns3, proposed an enhancement on this model in 2016. But the patch was not merged to the official release yet. Student may use this patch as a reference for their proposals. Some sample ideas are listed below.

  • Help to merge sns3 statistic enhancement to ns-3.
  • Add more trace types
  • Add more collectors. Ideally, the statistic calculation method should be configurable in the script so that people don’t need to add new collectors when they have any new requirement.
  • More output format types: excel, MySql, matplotlib, R, Matlab, more picture formats, etc.
  • Improve documentation and add more example scripts.

The list is not exhaustive and not limiting. Any new ideas in this area are welcome.

Persistent and Semi-Persistent Scheduling inside LTE module

Mentors: Natale Patriciello, Sandra Lagen

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.