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 2015

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

The thirteen week coding period for projects runs from 25 May to 21 August, 2015. 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 and 2012-14.

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 of interest. Mentors familiar with ns-3 development practices will be preferred, to improve the chances of student code merge.

ns-3 and other GSoC mentoring organisations

Students interested in ns-3 and GSoC are also encouraged to explore whether other organizations might be a suitable mentoring organization for their project idea. Please keep in mind, though, that the ns-3 project is not involved in the selection process for these other mentoring organizations, and you will have to apply there instead.

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

Decouple traffic generators from sockets

Mentors: Tom Henderson Vedran Miletić

  • ns-3 uses applications that are part traffic generator, part socket-based application. The traffic generation part is not decoupled from the sockets API, making it hard to use applications over non-socket APIs such as future sensor networks. This project would work on a cleaner separation between traffic generator (OnOffApplication) and sockets. This is not necessarily restricted to OnOffApplication; maybe the new generator is something like MGEN:

Here is an example problem to consider answering in your application. How would you change the proposed Poisson Pareto Burst Process code to make it run either over IP sockets or over a NetDevice model?

ARP and NDisc cache visibility and neighbor table changes

Mentors: Tom Henderson Vedran Miletić

There is no user-friendly API for reading and manipulating the IPv4 ARP and IPv6 Neighbor Discovery caches. IPv4 and IPv6 neighbor caches can be printed, but the interactions is still very limited. Some simulations may want to disable ARP and start with pre-populated ARP tables (because the ARP request/reply introduces a latency that is not desired in the program). Moreover, some protocols (e.g., 6LoWPAN-ND) may need to modify radically how the caches are accessed and populated. There is presently no way to add static neighbor table entries; all added entries will timeout unless refreshed. There is a way to manually inject dynamic table entries to the ArpCache, if one can obtain a pointer to this object, but this is cumbersome. Finally, there are some neighbor caches improvements to be considered, e.g., the ones described in Bug 2057: ARP and NDisc caches should be updated by L4.

A good application for this type of project would be to list some desired functional requirements from a usability perspective, and describe (perhaps by sketching out some sample API) how the functions would be provided by ns-3. For instance, is a new helper object needed, or can existing helper objects be extended? A good application would also outline how real systems access and manipulate the ARP and neighbor discovery caches, and draw parallels between the tools in use on a real system (such as the 'iproute2' program) and how the ns-3 API would be designed. Additional work on this project could focus on IP address handling for interfaces (bugs 757 and 760), and bug 187 (enabling perfect ARP). Another related bug is Bug 652.

  • Required Experience: C++
  • Interests: IPv4 and Ipv6
  • Difficulty: easy/medium
  • Recommended reading:
    • source code in src/internet, and the bugs mentioned above
    • the Linux iproute2 tool
  • Design suggestion: An iproute2 helper could be created to support strings that are commonly passed to the iproute2 tool on a real system. The basic idea is to create a string parser that could parse strings that one would commonly issue on a system that supports iproute2. If presented with a string that was unsupported, it would have to handle this some way-- what would be a good suggestion for handling this case?

Example API:

Iproute2Helper i;
Ptr<Node> n;
NodeContainer nc;

i.SetOutput (file);
i.Verbose ();  // output also goes to std::out even if 'file' specified
i.Quiet () ; // no output goes to std::out
i.Cmd (n,"ip neighbor show");
i.CmdAt (Seconds (10), n, "ip neighbor show dev eth0");
i.CmdEvery (Seconds (10), nc, "ip neighbor show");
i.Cmd (n, "ip neighbor flush dev eth3");
bool ok = i.Cmd (n, "ip neighbor add lladdr 00:80:c8:27:69:2d dev eth3");

Doing this would require some additional work in assigning human-friendly names like eth0 to interfaces.

Inter-frequency measurement support for the LTE module

Mentors: Nicola Baldo Marco Miozzo

  • The ns-3 LTE module already allows to simulate LTE deployments where the base stations are placed at different carrier frequency; however, this is currently limited to static scenarios with no mobility, because only intra-frequency UE measurement are supported, and hence handover can only occur among cells at the same carrier frequency. The aim of this project is to develop supports for inter-frequency UE measurements, so that it can be leveraged both for idle and connected node mobility.

GPU acceleration for vector arithmetics in the spectrum module

Mentors: Nicola Baldo Marco Miozzo

  • The ns-3 spectrum module does a lot of vector arithmetics which in the current ns-3 version are just run on the CPU. The aim of this project is to develop the necessary code to offload these calculations to a GPU in order to achieve a hopefully significant speedup in the simulation of scenarios relying on the spectrum model (e.g., including LTE scenarios).
  • Required Experience: C++
  • Bonus Experience: CUDA, OpenCL...
  • Interests: GPU acceleration
  • Difficulty: hard
  • Recommended reading:

Carrier Aggregation support for the LTE module

Mentors: Marco Miozzo Nicola Baldo

  • The aim of this project is to bring the ns-3 LTE module closer to the LTE-A paradigm and, more in detail, consists of the introduction of the Carrier Aggregation (CA) functionality. The student will have to collect information from the 3GPP specification for what concerns the relevant EUTRA aspects. The implementation will involve mainly the physical, MAC and RRC layers.
  • Required Experience: C++, LTE
  • Interests: LTE-A, HetNet
  • Difficulty: hard
  • Recommended reading:
    • LTE-A HetNets using Carrier Aggregation, Nomor whitepaper [1]
    • [2]
    • 3GPP TS 36.211
    • 3GPP TS 36.213
    • 3GPP TS 36.331

Support of RRC IDLE mode procedures for the LTE module

Mentors: Nicola Baldo Marco Miozzo

  • The ns-3 LTE module currently supports a vast number of RRC CONNECTED mode procedures (e.g., handover, measurement reporting, etc), but has very limited support for RRC IDLE mode procedures (basically, only cell selection). The aim of this project is to 'close the circle' and provide full support for critical RRC IDLE mode procedures, such as PLMN selection, cell reselection, Tracking Area Update, Paging, etc.
  • Required Experience: C++, LTE
  • Interests: Mobility Management in LTE systems
  • Difficulty: hard
  • Recommended reading:
    • 3GPP TS 36.304 [3]
    • 3GPP TS 23.401, Section 5.3.3 ("Tracking Area Update Procedures") [4]
    • 3GPP TS 36.331

802.15.4 realistic MAC and Energy Model

Mentors: Tommaso Pecorella

802.15.4 realistic MAC and Energy Model: The lr-wpan model is an 802.15.4 PHY and MAC model currently in development. The model is not actually linked with the energy model. Moreover it does not model the radio interface sleep status. The current model assumes that the radio is always active. As a consequence, the MAC layer is quite simple, since it does not needs to guess when the receiver's radio interface is active. The goal of the project are:

  1. Model the 4-state radio model (Sleep, Tx, Rx, Transitioning)
  2. Develop one 'realistic' MAC model (the choice is left to the student)
  3. Link the 4-state model with the Energy module.

802.15.4 Bootstrap

Mentors: Tommaso Pecorella

802.15.4 Bootstrap: 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

802.15.4 Beacon-enabled mode: 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:

Neighbor Discovery Optimization for Low Power and Lossy Networks (6LoWPAN-nd)

Mentors: Tommaso Pecorella

6LoWPAN-nd implementation and testing: 6LoWPAN-nd is novel protocol from IETF's LoWPAN WG. The protocol aims at defining new and optimized methods to perform Neighbor Discovery and Node Bootstrap for Wireless Sensor Networks and it will be the counterpart of the 6LoWPAN IPv6 header compression strandard. 6LoWPAN-nd is not currently implemented in ns-3, while 6LoWPAN compression and 802.15.4 stacks are in advanced development status. In order to simulate a real Wireless Sensor Network 6LoWPAN-nd should be developed and tested.

  • Required Experience: C++, IPv6
  • Bonus Experience: WSN networking
  • Interests: WSN, IPv6, node bootstrap, efficient packet compression
  • Difficulty: hard
  • Recommended reading:
    • RFC 4919 IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs): Overview, Assumptions, Problem Statement, and Goals
    • RFC 6775 Neighbor Discovery Optimization for Low Power and Lossy Networks

TCP validation

Mentors: Tom Henderson, Tommaso Pecorella

This project concerns the verification (checking that TCP is correctly implemented) and validation (checking that TCP models provide results similar to those of real systems) of ns-3 native TCP models. TCP is one of the most widely used and widely studied protocols in the Internet. ns-3 has a number of TCP (congestion control) variants. Recently, RFC 5681 was published, documenting recommended TCP behavior. This project would consist of reviewing the ns-3 TCP implementations and testing them for conformance to RFC 5681 (and fixing any issues that were found to arise). One outcome of this project would be a test suite that will ensure that ns-3's TCP implementation is accurate and does not regress over time. We also have some new TCP variants coming available in ns-3 (Cubic, SACK, Compound) that need testing.

Are you interested in this project? In your application, please tell us how you plan to test ns-3 TCP. Be as specific as possible, to convey that you know enough about ns-3 to make good progress. Tell us how you would create conditions (packet losses, reordering) to test TCP. What strategies can you use to test ns-3 TCP against a real implementation? How are you going to specifically verify that a value for a TCP state variable is the proper value at the right time? The most successful application would actually write a few working TCP tests (that run in the ns-3 regression test suite) and point us to the code (perhaps on github or some other site), and would go on to outline what additional tests would be prioritized in the GSoC program.

Modular build system

Mentor: Tom Henderson

This is a project that requires no networking experience, and is for students with Python skills who are interested in build systems. ns-3 is in the midst of a transition to a modular build system, managed by a tool called bake that is similar to GNOME JHBuild or other dependency managers. A student for this project would work on a daily basis with Tom Henderson (who is already working on this project) to perform tasks such as the following: 1) Port bake to Python 3, 2) Ensure that bake is documented so that automated tools can build API documentation, 3) Test bake on a number of platforms, 4) allow for wildcard expressions in bake dependencies, 5) consider configuration file move from XML to JSON, 6) convert our Doxygen and Sphinx infrastructure to operate on a per-module basis, 7) consider whether Linux package manager database formats and tools can be reused to manage ns-3 package dependencies, 8) help us write a manual for bake, etc. The interested student is encouraged to start discussing possible application preparation with Tom prior to the application deadline. A good grasp of Python and how Linux systems (libraries, package managers) are organized is essential. Because this is intended to be cross-platform, experience with other systems (FreeBSD, OS X, Windows) would also be a plus.

  • Required Experience: Python, Linux systems
  • Bonus Experience: FreeBSD, OS X, Windows Visual Studio
  • Interests: Build systems
  • Difficulty: depends on student's Python and Linux proficiency, can range from easy to difficult

TMix and DelayBox integration

Mentor: [mailto: Tom Henderson]

Tmix is a popular ns-2 utility for generating synthetic TCP traffic load. DelayBox is another ns-2 testing tool, part of TMix; DelayBox allows to introduce per-flow delay and loss on the traffic streams. Some initial ports of these capabilities are found at a Google code site. In this project, we want to finish these off (test, documentation, example scripts) and make more broadly available as part of ns-3 releases.

DelayBox is presently implemented as a standalone node in the network (it is literally a node into which packets are sent, and the packets emerge on another link after going through loss and delay modules). A successful application to this project will look at the existing DelayBox code and sketch out how it could instead be supported as a plugin on a network interface card (ns3::NetDevice model), without introducing a new node in the simulation topology (hint: see how error models are handled by ns-3 NetDevices). This would then be similar to the Linux netem capability or FreeBSD dummynet capability. This begs the question; could the ns-3 DelayBox model, instantiated on a ns3::NetDevice, be configured by an API that resembles the netem or dummynet configuration commands?

The successful application to this project will also tell us what additional traffic models he or she might work on once Tmix and DelayBox are finished. Finish up and test the Poisson Pareto Burst Process traffic model? Something else that interests you?

  • Required Experience: some TCP background, knowledge of FreeBSD dummynet or Linux netem tools
  • Interests: Internet traffic models, testing of network simulation scenarios
  • Difficulty: easy to medium